안드레이 카파시 4원칙과 한네스 v2.1: 폭주하는 AI 에이전트를 길들이는 실전 전략
2026년 현재, 우리는 단순히 인공지능과 대화하는 시대를 넘어 AI가 스스로 도구를 사용하고 코드를 수정하는 '에이전트의 시대' 한복판에 서 있습니다. 클로드(Claude)나 제미나이(Gemini) 같은 거대 언어 모델들은 이제 단순한 텍스트 생성을 넘어 복잡한 소프트웨어 아키텍처를 이해하고 직접 패치를 제안할 만큼 영리해졌죠. 하지만 실무 현장에서 이러한 에이전트들을 무턱대고 투입했다가는 오히려 해결해야 할 버그보다 더 큰 시스템 장애를 마주하게 되는 경우가 허다합니다.
저 역시 지난 몇 달간 다양한 멀티 에이전트 프레임워크를 실험하며 비슷한 고통을 겪었습니다. 에이전트가 사용자의 의도를 자의적으로 해석해 멀쩡한 코드를 '개선'이라며 망가뜨리거나, 과거의 대화 맥락을 잊어버려 같은 실수를 반복하는 모습은 개발자의 생산성을 높이기는커녕 오히려 검토 업무만 가중시키는 결과를 초래했습니다. 오늘 다룰 내용은 이러한 '폭주하는 AI'를 통제하기 위한 안드레이 카파시의 철학적 가이드라인과, 이를 기술적으로 구현한 한네스(Harness) v2.1 시스템에 대한 분석입니다.
위 이미지는 개념 연출을 위한 AI 생성 일러스트로, 실제 구동 화면이나 실측 캡처가 아닙니다.
에이전트 제어 터미널의 핵심 아이디어는, 에이전트가 코드를 수정하기 전 자신의 논리적 근거를 먼저 제시하고 사용자의 승인을 기다리게 만드는 것입니다. 단순히 명령을 수행하는 것이 아니라, 인간과 AI가 명확한 프로토콜 위에서 협업하는 구조를 만드는 것이 이 시스템의 핵심입니다. 이제 이 무적의 조합이 어떻게 작동하는지 구체적인 원리와 구현 방식을 살펴보겠습니다.
1. AI 코딩 에이전트의 치명적 결함: 왜 지능이 높아져도 사고는 치는가
우리가 흔히 마주하는 AI 에이전트의 실패는 모델의 파라미터가 부족해서 발생하는 지능의 문제가 아닙니다. 오히려 너무 많은 학습 데이터를 보유하고 있어서 발생하는 '과잉 의욕'과 '맥락 결여'가 원인인 경우가 많습니다. 안드레이 카파시는 이를 두고 AI에게 적절한 행동 지침(Guardrails)이 결여되어 있다고 지적했습니다. 에이전트가 자율적으로 판단하고 실행하는 과정에서 발생하는 세 가지 치명적인 실수는 다음과 같습니다.
첫째는 근거 없는 가정입니다. 사용자의 요청이 조금이라도 모호하면, AI는 질문을 통해 의도를 명확히 하기보다는 통계적으로 가장 확률이 높은 답변을 선택해 코드를 짜버립니다. 둘째는 코드 비대화(Code Bloat)입니다. 10줄이면 충분한 로직을 불필요한 디자인 패턴과 확장성을 고려한다며 100줄로 늘려놓는 경향이 있습니다. 마지막은 무단 수정 및 서식 파괴입니다. 특정 함수만 고치라고 했음에도 불구하고 파일 전체의 들여쓰기를 바꾸거나 주석을 삭제하여 깃(Git) 차분(Diff)을 엉망으로 만듭니다.
저는 한네스 시스템을 v1에서 v2.1로 업그레이드하며 이러한 문제를 해결하기 위해 '제약 조건의 프로그래밍'에 집중했습니다. AI의 지능을 높이는 것보다, AI가 넘지 말아야 할 선을 명확히 긋는 것이 실무에서는 훨씬 더 중요하다는 사실을 깨달았기 때문입니다. 이를 위해 도입한 것이 바로 안드레이 카파시의 4원칙입니다.
2. 안드레이 카파시의 4원칙: 에이전트 행동 교정을 위한 헌법
전 테슬라 AI 디렉터이자 OpenAI 창립 멤버인 안드레이 카파시는 최근 에이전트 활용의 핵심으로 '지침의 구체화'를 강조했습니다. 그의 아이디어를 바탕으로 깃허브(GitHub)의 claude.md 지침들을 우리 시스템에 맞게 최적화한 것이 바로 아래의 4원칙입니다.
2-1. 선(先) 사고 후(後) 실행과 단순함의 미학
제1원칙은 '코딩하기 전에 반드시 생각하고 질문하라'는 것입니다. 모호한 명령이 들어오면 AI는 즉시 코드를 작성하는 대신, 자신이 이해한 바를 요약하고 사용자에게 질문을 던져 의도를 명확히 해야 합니다. 예를 들어 "검색 기능을 추가해줘"라는 요청에 대해 필터링 기준은 무엇인지, 페이징 처리가 필요한지 먼저 확인하는 절차를 강제하는 것이죠. 본인이 직접 이 원칙을 적용해본 결과, 초기 기획 단계에서 발생하는 커뮤니케이션 오류가 약 40% 이상 감소하는 것을 체감했습니다.
제2원칙은 '단순함을 최우선으로(KISS 원칙)' 하는 것입니다. AI는 학습 데이터의 영향으로 거대한 엔터프라이즈급 코드를 흉내 내려는 경향이 강합니다. 이를 억제하고 200줄의 코드를 50줄로 줄일 수 있다면 기꺼이 다시 쓰게 만드는 지침입니다. 불필요한 외부 라이브러리 도입을 지양하고 순수 함수 위주의 간결한 코드를 유지하게 함으로써 시스템의 복잡도를 낮춥니다.
2-2. 수술적 수정과 테스트 기반 검증
제3원칙은 '수술하듯 꼭 필요한 지점만 수정하라'는 규칙입니다. 버그 하나를 잡기 위해 파일 전체의 스타일을 바꾸는 행위를 엄격히 금지합니다. 개선할 점이 보이더라도 먼저 보고하고 승인을 얻게 함으로써, 토큰 낭비와 불필요한 코드 변경으로 인한 혼란을 원천 봉쇄합니다. 대규모 리팩토링 프로젝트에서 이 원칙은 기존의 안정적인 로직이 파괴되는 사고를 막아주는 가장 강력한 안전장치가 됩니다.
제4원칙은 '목표 지향적 실행 및 검증'입니다. 단순히 "고쳐줘"가 아니라, 해당 버그를 재현하는 테스트 코드를 먼저 작성하고 이를 통과할 때까지 반복 수정하게 합니다. 성공 기준을 명확히 제시하면 AI는 스스로 검증 루프를 돌게 되며, 결과물의 신뢰도는 비약적으로 상승합니다. 이는 개발자가 일일이 코드를 검수해야 하는 부담을 획기적으로 덜어줍니다.
3. NOT(Network of Thoughts) 시스템: 파편화된 기억을 하나로 묶는 지식 그물
에이전트의 행동을 교정했다면, 다음은 '기억'의 문제입니다. 기존의 RAG(검색 증강 생성) 방식은 질문할 때마다 관련 문서를 조각조각 찾아 읽기 때문에 전체적인 맥락을 놓치기 쉽습니다. 또한 오늘 대화한 내용을 내일의 에이전트가 기억하지 못하는 휘발성 문제도 심각하죠. 이를 해결하기 위해 한네스 v2.1에 도입한 것이 바로 NOT(Network of Thoughts) 시스템입니다.
위 이미지는 개념 연출을 위한 AI 생성 일러스트로, 실측 데이터를 시각화한 그래프가 아닙니다.
NOT 시스템의 지향점은 에이전트가 새로운 정보를 접하면 이를 단순히 데이터베이스에 저장하는 것이 아니라, 사람이 읽을 수 있는 마크다운 형태의 '위키(Wiki)'로 컴파일하도록 설계했습니다. 이 방식의 가장 큰 장점은 벤더 중립성입니다. 클로드가 정리한 지식을 제미나이나 다른 로컬 LLM이 그대로 읽고 활용할 수 있기 때문입니다.
3-1. RAG를 넘어 위키 방식으로 진화하는 메모리
전통적인 벡터 DB 기반의 RAG는 대규모 데이터 처리에 유리하지만, 개인의 프로젝트 지식 관리에는 오버헤드가 큽니다. 반면 NOT 시스템은 평문 마크다운 폴더를 사용하므로 데이터가 온전히 사용자의 로컬 환경에 남습니다. 이는 프라이버시 측면에서도 유리할 뿐만 아니라, 사용자가 직접 옵시디언(Obsidian) 같은 툴로 지식을 수정하고 보완할 수 있는 '인간-AI 협업' 구조를 만들어냅니다.
3-2. 지식의 순도를 유지하는 린트(Lint) 프로세스
지식 그물이 커질수록 정보의 충돌이나 노후화가 발생하기 마련입니다. NOT 시스템은 이를 방지하기 위해 정기적인 '지식 린트' 과정을 거칩니다. AI 에이전트가 유휴 시간에 지식 창고를 훑으며 모순되는 정보가 있는지, 더 효율적인 해결책이 나왔는지 검사하고 업데이트를 제안합니다. 이러한 자가 치유 프로세스는 지식의 신뢰도를 일정하게 유지하는 핵심 동력입니다.
💡 원스의 인사이트: 도구의 노예가 아닌 설계자가 되는 법
한네스 멀티 에이전트 v2.1을 구축하고 운영하며 제가 얻은 가장 큰 깨달음은, 우리가 집중해야 할 것은 '어떤 AI 모델이 더 똑똑한가'가 아니라 '어떻게 AI들을 조화롭게 통제할 것인가'라는 점입니다. 많은 사용자가 특정 벤더의 유료 구독 서비스에 종속되어 그들이 제공하는 기능만을 수동적으로 소비하곤 합니다. 하지만 기술 환경은 언제든 변할 수 있습니다. 특정 기업의 정책 변화로 인해 어제까지 잘 쓰던 도구의 성능이 갑자기 떨어지거나 유료화될 수도 있죠.
제가 벤더 중립적인 멀티 에이전트 시스템과 마크다운 기반의 지식 체계를 고집하는 이유는 바로 이 '기술적 주권' 때문입니다. 클로드의 코딩 능력이 필요하면 클로드를 지휘자로 세우고, 제미나이의 넓은 컨텍스트 창이 필요하면 제미나이를 기록관으로 부릴 수 있어야 합니다. 모든 데이터와 지침이 특정 서비스의 데이터베이스에 갇히는 순간, 그것은 더 이상 온전한 내 자산이 아니게 됩니다.
또한 안드레이 카파시의 4원칙을 적용해보며 느낀 점은, AI에게 자유를 주는 것보다 명확한 제약을 주는 것이 훨씬 더 창의적이고 정확한 결과물을 만들어낸다는 사실입니다. 규제 없는 지능은 혼돈을 야기하지만, 엄격한 규칙 속의 지능은 정교한 결과물을 도출합니다. 여러분도 단순히 AI에게 일을 시키는 단계를 넘어, 그들의 사고 과정을 설계하는 '시스템 아키텍트'의 관점을 가져보시길 권합니다. 그것이 AI 시대에 대체 불가능한 인간의 영역으로 남는 유일한 길이라고 저는 믿습니다.
5. 한네스 v2.1 실전 구축 가이드 및 운영 팁
실제로 이 시스템을 자신의 워크플로우에 이식하려는 분들을 위해 몇 가지 기술적 권장 사항을 정리합니다. v2.1은 이전 버전보다 설치가 간편해졌지만, 세부 설정에 따라 성능 차이가 크게 발생합니다.
첫째, 오케스트레이터(지휘자) 모델의 선정입니다. 2026년 7월 현재 코딩 작업의 지휘에는 페이블 5(Fable 5)나 소넷 5(Sonnet 5)가 뛰어난 설계·조율 능력을 보여줍니다. 실제 코드를 작성하는 워커로는 오푸스 4.8(Opus 4.8)을 결합하고, 단순 반복 작업이나 지식 정리 같은 경량 태스크에는 하이쿠 4.5(Haiku 4.5) 같은 저비용 모델을 연결하여 하이브리드 방식으로 운영하는 것이 경제적입니다.
둘째, 지식 입력(Inbox)의 질 관리입니다. 모든 자료를 무분별하게 NOT 시스템에 던져넣기보다는, 공식 문서나 본인이 직접 해결한 트러블슈팅 내역 위주로 구성하는 것이 좋습니다. AI가 요약하는 과정에서 발생할 수 있는 '환각(Hallucination)'을 최소화하기 위해, 원본 자료의 출처 링크를 반드시 포함시키는 습관이 중요합니다.
시스템 구축이 완료되면 위 화면과 같이 각 에이전트가 서로의 작업을 모니터링하고 지식을 교환하는 로그를 실시간으로 확인할 수 있습니다. 이는 단순한 자동화를 넘어 하나의 가상 팀이 내 PC 안에서 유기적으로 움직이는 것과 같습니다. 초기 설정에 약간의 시간이 소요될 수 있지만, 한 번 구축해두면 복잡한 프로젝트를 수행할 때 비교할 수 없는 생산성을 제공할 것입니다.
관련 글
- AI 코딩 성능을 바꾸는 하네스 엔지니어링의 4가지 핵심 원칙
- AI 에이전트로 일하는 법이 바뀝니다: 클로드 코드와 하네스 엔지니어링 실무 메모
- 클로드 Fable 5 비용 아끼는 법 | Advisor Strategy