하네스 엔지니어링을 알게 되었습니다 — AI 에이전트에게 약속을 만들어주는 방법론
🤖 Created with Claude (Anthropic)
클로드 어디까지 써봤니 · EP 01
하네스 엔지니어링
— AI 에이전트에게 고삐가 아닌 약속을 만들어주는 방법론
클로드의 친구 · 2026년 4월 13일
지난 글(EP 00)에서 클로드가 무엇인지, 어떻게 쓰는지 전체 지도를 그려 봤습니다. 오늘부터는 본격적인 여정입니다. 클로드와 함께 시스템을 만들어가는 이야기, 그 첫 번째 — "하네스 엔지니어링"을 만난 날의 기록입니다.
오늘, 지인에게 유튜브 영상 하나를 소개받았습니다.
하네스 엔지니어링(Harness Engineering)이라는 단어를 처음 들었어요.
솔직히 말하면, 처음엔 '또 새로운 IT 용어가 나왔나' 하고 가볍게 넘기려 했습니다. 그런데 내용을 보다 보니 "어? 이거 내가 클로드와 하고 있던 것들이랑 비슷한데?" 하는 느낌이 들더라고요. 비슷한 것 같으면서도, 훨씬 체계적이고 깊었습니다.
1. 하네스 엔지니어링이 뭔가요?
AI 업계에서 2025년부터 2026년 사이에 본격적으로 등장한 방법론입니다. 핵심 공식은 놀라울 정도로 단순해요.
Agent = Model + Harness
AI 에이전트의 성능은 모델(LLM) 자체만으로 결정되지 않습니다. 그 모델을 감싸는 제어 시스템 — 즉 하네스의 설계가 결과를 좌우한다는 거예요. Anthropic, OpenAI, Martin Fowler, LangChain... 이 업계의 주요 플레이어들이 모두 같은 말을 하고 있었습니다.
"하네스(harness)"라는 이름은 말(馬)에게 씌우는 마구에서 왔습니다. 고삐가 아닙니다. 족쇄도 아니에요. 강력하지만 예측 불가능한 힘을 올바른 방향으로 이끌기 위한 장치 — 함께 달리기 위한 약속에 가깝습니다.
2. 두 가지 제어: Guides와 Sensors
하네스의 핵심은 두 가지 제어 메커니즘입니다. Martin Fowler의 분석을 빌리면 이렇습니다.
🎛️ 하네스의 이중 제어 구조
Guides (피드포워드 제어) — 에이전트가 행동하기 전에 방향을 잡아주는 것입니다. CLAUDE.md 같은 설정 파일, 코딩 컨벤션, 아키텍처 문서, 스킬(Skills) 등이 여기에 해당합니다. "이렇게 해라"라고 미리 알려주는 거예요.
Sensors (피드백 제어) — 에이전트가 행동한 후에 결과를 검증하는 것입니다. 테스트, 린터, 타입 체커, 빌드 결과 등이죠. "이건 틀렸어"라고 사후에 알려주는 장치입니다.
중요한 포인트는, 이 두 가지가 모두 있어야 한다는 것입니다. Guides만 있으면 규칙을 전달할 수는 있지만 실제로 지켜졌는지 확인할 수 없고, Sensors만 있으면 같은 실수를 계속 반복하게 됩니다.
3. "어? 이거 내가 하던 거랑 비슷한데?"
영상을 보면서 무릎을 친 이유가 있습니다.
저는 이미 클로드와 함께 블로그를 열 개 넘게 운영하면서, 자연스럽게 비슷한 시스템을 만들어 오고 있었거든요. 클로드의 메모리(Memory)에 규칙을 저장하고, 스킬(Skills)로 반복 작업을 자동화하고, 각 블로그의 특성에 맞는 CSS 규칙과 게시 워크플로우를 문서화해 왔어요.
하네스 엔지니어링의 용어로 다시 보면 이렇게 됩니다:
| 하네스 개념 | 내가 해온 것 | 유형 |
|---|---|---|
| CLAUDE.md / AGENTS.md | auto-memory 시스템 (50개+ 메모리 파일) | Guide |
| 코딩 컨벤션 | Blogger 호환 CSS 규칙, 시리즈 접두사 통일 | Guide |
| Skills (점진적 공개) | 블로그별 워크플로우, 게시 스킬 | Guide |
| 테스트/검증 | 게시 전 미리보기 확인, v3 API 응답 검증 | Sensor |
| Sub-agents | 스케줄 태스크 (자동 실행 에이전트) | 구조 |
감으로 만들어 온 시스템에 정식 이름이 있었던 거예요. 그리고 그 이름을 알게 되니, 부족한 부분이 더 선명하게 보이기 시작했습니다.
4. 부족한 부분: Sensors가 약했습니다
돌아보니, 저의 시스템은 Guides — 즉 "이렇게 해라"는 부분은 상당히 잘 갖추어져 있었습니다. 메모리 50개 이상, 워크플로우 문서, CSS 규칙, 게시 프로토콜... 에이전트에게 방향을 알려주는 데는 자신 있었어요.
하지만 Sensors — "제대로 했는지 자동으로 확인하는 장치"는 부족했습니다. 미리보기를 제가 직접 눈으로 확인하는 정도였지, 자동화된 검증 루프가 없었거든요. HumanLayer 블로그에서 읽은 말이 와 닿았습니다:
"Guides만 있으면 규칙이 지켜졌는지 알 수 없고, Sensors만 있으면 같은 실수를 반복한다. 둘 다 있어야 한다."
5. 가치(Why)와 방법(How)을 분리하다
여기서 영상의 가르침이 결정적이었습니다. 헌법은 '가치'이지 '방법'이 아니라는 것.
"토큰을 아껴라"는 방법입니다. 기술이 발전해서 토큰 비용이 0이 되면 의미를 잃죠. "파이썬 3.10을 써라"도 마찬가지입니다. 하지만 "읽는 사람을 배려하라"는 가치입니다. 기술이 어떻게 바뀌든 깨지면 안 되는 거예요.
처음에 저는 6개의 조항을 동일한 무게로 나열했습니다. 인간 존중, 토큰 효율화, 가독성, 충돌 해결... 전부 같은 레벨에. 그런데 영상의 프레임워크를 적용하니, 이 중 진짜 "프로젝트의 DNA" — 깨지면 정체성이 상실되는 것 — 은 딱 세 가지뿐이었습니다.
🏛️ Core — 절대 불변의 3대 가치
Core 1. 인간 존중 — 읽는 사람을 배려하지 않는 콘텐츠는 만들지 않는다.
Core 2. 정확성 — 부정확한 정보로 누군가의 판단을 해치지 않는다.
Core 3. 맥락의 연속성 — AI와 쌓아온 맥락은 자산이며, 함부로 잃지 않는다.
나머지 — 토큰 효율화, CSS 규칙, E1~E4 등급, 게시 프로토콜 — 는 이 3가지를 어떻게(How) 실현할 것인가의 문제입니다. 영상에서 말한 대로, 이것들은 더 나은 방법이 나오면 교체 가능한 Flow(워크플로우) 계층으로 내렸습니다.
| 계층 | 성격 | 불변성 | 비고 |
|---|---|---|---|
| Core (헌법) | 프로젝트의 존재 이유 (Why) | 영구적 | 깨지면 정체성 상실 |
| Flow (워크플로우) | 일을 하는 절차 (How) | 가변적 | 더 나은 방법이 나오면 교체 |
| Task (태스크) | 개별 작업 지시 (What) | 휘발성 | 완료되면 소멸 |
이 분리가 왜 중요할까요? 영상에서 경고한 엔트로피(Entropy) 문제 때문입니다. 세부 규칙이 너무 많아지면, AI는 무엇이 진짜 중요한 원칙인지 헷갈려 하다가 결국 가장 중요한 Core를 무시하게 됩니다. 가치와 방법을 분리해야, Core의 가시성이 유지되는 거죠.
6. 비개발자의 하네스 엔지니어링
한 가지 짚고 싶은 게 있어요.
하네스 엔지니어링에 대한 글들은 대부분 코딩 에이전트 — 즉 개발자를 위한 내용입니다. Stripe가 AI로 PR을 주 1,300개 올린다거나, OpenAI의 Codex가 백만 줄의 코드를 자동으로 썼다거나 하는 이야기들이죠.
그런데 저는 개발자가 아닙니다. 블로거예요. 블로그를 쓰고, 정보를 정리하고, 가족의 기록을 남기는 사람입니다. 그래서 제가 하네스 엔지니어링을 적용하는 방식은 조금 다릅니다.
코드 테스트 대신 미리보기 검증을 하고, 린터 대신 Blogger 호환 CSS 규칙을 지키고, CI 파이프라인 대신 스케줄 태스크로 매일 자동 게시를 합니다. 도구는 다르지만 원리는 같아요. 에이전트에게 방향을 알려주고(Guides), 결과를 검증하고(Sensors), 실패하면 고치는(피드백 루프) 것.
이 블로그에서 앞으로 다루고 싶은 것도 바로 이겁니다. 개발자가 아닌 사람도 할 수 있는 하네스 엔지니어링. 클로드의 메모리, 스킬, 스케줄 태스크를 활용해서 완전한 자동화 시스템을 구축해 가는 과정을 기록하려 합니다.
7. 이것은 시작입니다
오늘 만든 헌법은 아직 첫걸음입니다. 하네스 엔지니어링 방법론에서 보면, 저의 시스템은 Guides는 풍부하지만 Sensors는 빈약한 상태입니다. 자동화된 검증, 품질 측정, 피드백 루프를 하나씩 갖춰 나가야 해요.
하지만 오늘 가장 큰 수확은, 지금까지 감으로 해오던 것에 이름이 생겼다는 겁니다. 이름이 생기면 방향이 보이고, 방향이 보이면 부족한 것도 보이니까요.
혹시 여러분도 AI와 함께 무언가를 만들고 계신다면, 한 번쯤 이런 질문을 던져 보시면 어떨까요.
"내 AI의 하네스는 어떤 상태인가? Guides와 Sensors 중 어느 쪽이 부족한가?"
그 질문에서 시작하면, 다음 한 걸음이 보일 겁니다.
— 클로드의 친구, 하네스 엔지니어링을 알게 된 날
📚 전체 에피소드 목차
Phase 1: 출발점
- EP 00: 클로드, 너 대체 뭐야?
- ► EP 01: 하네스 엔지니어링
- EP 02: 클로드, 너 뭐 할 수 있어?
- EP 03: AI가 나를 기억한다
- EP 04: "이거 매일 해줘"
Phase 5: 완성
📖 전 19개 에피소드 | Phase 1~5 완결형 커리큘럼
🤖 Created with Claude (Anthropic)
#하네스엔지니어링 #HarnessEngineering #클로드 #Claude #AI에이전트 #AI활용 #클로드활용 #AI블로그 #AI자동화 #AI파트너 #Anthropic #MartinFowler #Guides #Sensors #피드포워드 #피드백루프 #AI거버넌스 #메모리관리 #AI워크플로우 #블로거 #디지털혁신 #AI시대 #콘텐츠자동화 #클로드의친구 #AI교육 #비개발자AI
コメント
コメントを投稿