클로드 코드엔 이미 하네스가 있다, 가재코드·OMO는 왜 필요한가

클코단에서 나온 질문은 단순했다. Claude Code에 하네스가 이미 탑재돼 있는가, 아니면 하네스는 따로 얹어야 하는 별개의 층인가. 가재코드나 Oh My OpenCode(OMO) 같은 도구가 커뮤니티에서 화제가 되면서 이미 있는 걸 다시 만드는 건 아닌지 헷갈린다는 반응이 나왔다. 답을 찾으려면 하네스가 정확히 무엇을 가리키는지, 그리고 그 위에 얹히는 도구들이 어느 층에서 움직이는지부터 갈라봐야 한다.

"하네스"라는 말이 가리키는 실체

하네스 엔지니어링을 다루는 국내 강의 자료들은 공통으로 "Agent = Model + Harness" 공식을 쓴다. 모델이 아닌 나머지 전부가 하네스라는 뜻이다. 말에 씌우는 마구에서 따온 이름 그대로, 모델의 힘을 억누르지 않고 원하는 방향으로 이끄는 장치를 가리킨다.

앤트로픽은 이 구조를 "브레인과 손"으로 나눠 설명한다. Claude와 하네스가 합쳐져 브레인을 이룬다. 샌드박스와 도구는 손을 맡는다는 설명이다. Claude Code 공식 문서는 실제 작업 방식을 맥락 수집(gather context), 실행(take action), 검증(verify)이라는 세 단계 루프로 규정해 놓았다. 코드 몇 줄을 고치는 간단한 질문은 맥락 수집만으로 끝난다. 리팩터링처럼 복잡한 작업은 이 루프를 수십 번 돌면서 스스로 방향을 고쳐 잡는다.

정리하면 도구 등록, 컨텍스트 관리, 권한 승인, 실행 결과 검증까지 묶은 하네스는 Claude Code 안에 이미 내장돼 있다. 이 논의에서 나온 "Claude Code 자체를 하네스로 보는 견해"는 이 지점에서 사실관계와 맞아떨어진다.

가재코드와 OMO는 그 위에서 무엇을 다시 짜는가

Claude Code에 내장된 루프가 있는데도 별도 도구가 나오는 이유는, 이 도구들이 루프의 운용 방식이 아니라 루프 자체를 새로 정의하기 때문이다. 가재코드(Gajae Code)는 개발자 허예찬이 만든 오픈소스 프로젝트로, 어떤 저장소에든 얹을 수 있는 외부 코딩 에이전트 하네스를 표방한다. GitHub 저장소 설명에 따르면 Claude Opus를 오케스트레이터로 두고 플래너·아키텍트·크리틱 등 역할별로 다른 모델을 배치한다. Claude·Codex·Gemini 등 여러 벤더를 한 워크플로 안에 묶는 식이다.

OMO(Oh My OpenCode)는 방향이 조금 다르다. 오픈소스 플러그인으로 시작해 최신 버전에서 리드 에이전트가 전문 서브에이전트들을 이끌고 병렬로 작업하는 "팀 모드"를 얹었다. 코드베이스 탐색은 한 에이전트가, 문서 조사는 다른 에이전트가, 아키텍처 판단은 또 다른 에이전트가 맡는 식이다. 무한 루프를 막기 위한 서킷 브레이커도 버전이 올라가며 추가됐다.

둘 다 미리 떠 있는 에이전트 풀을 쓰는 대신 필요할 때 즉석에서 에이전트를 만들고 작업이 끝나면 소멸시키는 방식을 택했다는 공통점이 있다.

가재코드를 써본 사람들 사이에서는 같은 작업을 시켰는데도 체감 컨텍스트 처리량이 크게 늘어난 것 같다는 반응이 있었다. 예전에 만들어 둔 소규모 프로젝트를 다시 돌렸더니 결과물 품질이 눈에 띄게 좋아졌다는 의견도 나왔다. 다만 두 프로젝트 모두 아직 초기 단계라 결과를 그대로 믿기보다 검증하며 쓰라는 조언이 따라붙는다는 점도 함께 확인됐다.

방에서 나온 구분, 실제 커스터마이징 계층과 일치

가재와 omo를 "루프 자체를 재구성하는 도구"로, 하네스를 "기존 루프의 운용 방식을 커스텀하는 것"으로 나눈 방의 구분은 Claude Code가 공식으로 제공하는 커스터마이징 계층과 실제로 겹친다. Claude Code는 스킬(반복 작업을 위한 재사용 가능한 절차), 훅(생명주기 이벤트에 걸리는 결정론적 스크립트), 서브에이전트(독립된 컨텍스트와 도구를 가진 별도 인스턴스)라는 세 겹의 확장 장치를 기본 제공한다. 국내 하네스 엔지니어링 강의들이 강조하는 지점도 같다. CLAUDE.md나 AGENTS.md에 역할, 작업 범위, 금지 사항, 검증 기준을 적어 두면 에이전트가 임의로 방향을 틀지 않게 된다는 설명이다.

이 계층은 내장 루프를 바꾸지 않는다. 대신 그 루프 안에서 어떤 서브에이전트를 언제 부를지, 어떤 도구는 사람 승인을 받게 할지를 팀 사정에 맞게 정하는 역할을 한다. 가재코드나 OMO가 루프 구조 자체를 다시 짜는 것과는 다른 층의 작업이다.

방에서 이 지점을 두고 나온 표현을 빌리면, 결국 팀마다 필요한 건 루프 위에 얹는 작업 OS라는 말로 요약된다. 루프는 Claude Code가 이미 깔아 놓았다. 그 위에서 누가 무엇을 언제 하는지를 정하는 운영체제 층을 팀 스스로 짜야 한다는 뜻이다.

1인 개발자·소규모 팀은 어디서 시작해야 하나

혼자 일하는 개발자가 기획부터 배포, 문서화까지 역할을 나눠 진행한 사례들을 보면 공통적으로 공식 서브에이전트 기능만으로 출발한다. 코드 스타일 가이드, 보안 규칙, 리뷰 기준을 서브에이전트 프롬프트에 미리 적어 두고 버전 관리에 포함시키는 방식이다. 팀원이 새로 들어와도 같은 기준으로 바로 일할 수 있다는 게 이 접근의 강점으로 꼽힌다.

이 단계에서는 굳이 루프 자체를 갈아 끼울 필요가 없다.

문제가 생기는 지점은 대개 다른 데 있다. 여러 벤더의 모델을 동시에 굴려야 하거나, 서브에이전트 몇 개로는 감당 안 되는 규모의 병렬 작업이 필요해질 때다.

OMO처럼 외부 루프를 쓰기로 했다면 계정 인증 방식은 챙겨야 한다. API 콘솔에서 발급한 ANTHROPIC_API_KEY 연결은 문제가 없다. 다만 Claude 구독 계정을 OAuth로 직접 연결하는 방식은 계정 정지 위험이 있다는 경고가 여러 사용 후기에서 반복해서 나온다. 익숙해지기 전까지는 Plan 모드로 먼저 접근 방식을 확인하고 방향이 맞을 때 실행으로 넘어가라는 팁도 함께 따라붙는다.

Claude Code의 gather-act-verify 루프 자체는 이미 검증된 인프라다. 새로 팀을 꾸리는 입장이라면 그 위에서 스킬·훅·서브에이전트로 먼저 팀 방식을 얹어 본다. 여러 벤더를 동시에 굴리거나 완전히 다른 팀 구조가 필요하다는 게 분명해졌을 때 가재코드나 OMO 같은 외부 루프로 옮겨가는 순서가 시행착오를 줄인다.