AI 코딩 도구를 쓰는 것과 다루는 것은 다르다

oh-my-opencode를 쓰던 시절, 하네스의 위력을 체감하고 있었다. hashline 편집 포맷 덕분에 파일 수정이 거의 실패하지 않았고, 비동기 서브에이전트가 작업을 병렬로 처리했다. GitHub 스타 47,000개를 넘긴 이 플러그인은 OpenCode라는 AI 코딩 도구를 완전히 다른 물건으로 만들어줬다. 도구 자체의 능력보다, 도구를 감싸는 하네스의 설계가 실무 성능을 결정한다는 것을 매일 경험하고 있었다.

2026년 3월, Anthropic이 OpenCode에 법적 요청을 보냈다. Claude 구독 인증을 서드파티 도구에서 사용하는 것은 이용약관 위반이라는 내용이었다. 3월 19일, OpenCode는 Claude 연동을 완전히 제거했다. oh-my-opencode가 작동을 멈췄다. 쓰던 하네스가 사라진 것이다. 두 가지 선택지가 있었다. Claude Code를 날것 그대로 쓰거나, 새 하네스를 직접 만들거나. 나는 후자를 택했고, 다음 날 oh-my-hwclaude의 첫 커밋을 찍었다.

멀티에이전트 오케스트레이션을 담당하는 oh-my-claudecode, 편집 정밀도를 보장하는 oh-my-hwclaude, 도메인 전문성을 구조화한 business-ai-team. 이 시리즈는 세 레이어를 점층적으로 구축한 과정의 기록이다. 같은 모델을 쓰면서도 결과가 달라지는 이유, 그것은 하네스에 있다.

하네스는 도구를 다루는 도구다

하네스(harness)는 원래 말에 씌우는 마구(馬具)를 뜻한다. 말의 힘을 인간의 의도대로 전달하기 위한 장치다. AI 코딩에서의 하네스도 같은 역할을 한다. 모델의 능력을 코드베이스에 정확하게 전달하기 위한 중간 레이어다. Claude Code, Cursor, Windsurf 같은 AI 코딩 도구는 그 자체로 하네스이지만, 단일 레이어로는 충분하지 않다.

Can Bölük의 실험이 이것을 증명했다. 그는 전통적인 str_replace 편집 포맷 대신 hashline이라는 새로운 포맷을 15개 모델에 적용했다. Grok Code Fast 1은 6.7%에서 68.3%로 뛰었다. Gemini 3 Flash는 78.3%를 기록해 벤더 자체 최고 성능을 5포인트 넘었다. 출력 토큰도 20% 줄었는데, 실패한 편집을 재시도하는 루프가 사라졌기 때문이다. 같은 모델이 하네스만 바꿔도 성능이 10배 올라간다는 것은, 모델 선택보다 하네스 설계가 실무 성능에 더 큰 영향을 미친다는 뜻이다.

이 발견이 의미하는 바는 명확하다. 더 강한 모델을 기다리기보다, 지금 가진 모델의 출력을 정확하게 코드에 반영하는 구조를 만드는 것이 먼저다. AI 빌더들이 각자의 하네스를 다듬는 데 시간을 쓰는 이유가 여기에 있다. 하네스는 모델의 잠재력과 실제 결과물 사이의 간극을 좁히는 유일한 지점이다.

서드파티 차단이 만든 동기

서론에서 언급한 대로, 나는 oh-my-opencode라는 하네스를 쓰고 있었다. 현재 oh-my-openagent로 이름을 바꾼 이 프로젝트는 GitHub 스타 47,000개를 넘긴, AI 하네스 생태계에서 가장 큰 프로젝트 중 하나다. OpenCode라는 터미널 기반 AI 코딩 에이전트 위에 비동기 서브에이전트, LSP/AST 도구, hashline 편집을 얹은 플러그인이었다. 잘 작동했고, 작업 방식에 깊이 통합되어 있었다.

Anthropic은 2026년 1월부터 서드파티 도구의 Claude 구독 인증을 단계적으로 제한했다. 2월에는 이것을 공식 이용약관으로 문서화했다. 그리고 3월, OpenCode에 직접 법적 요청을 보냈다. 3월 19일, OpenCode 메인테이너는 "anthropic legal requests"라는 커밋 메시지와 함께 Claude 연동 코드를 전부 삭제했다. 서드파티 하네스에서 Claude를 쓸 수 있는 길이 공식적으로 닫혔다.

oh-my-opencode의 개발자는 프로젝트를 oh-my-openagent로 개명하고 Claude 이외의 모델로 피벗했다. George Hotz는 "Anthropic is making a huge mistake"라는 글을 발표했다. 커뮤니티는 분열됐다. 나에게 이 사건은 두 가지를 분명히 했다. 하나, 특정 벤더의 정책에 하네스 전체가 의존하는 구조는 위험하다. 둘, 쓰던 도구가 막히면 직접 만들면 된다.

Claude Code의 하네스 시스템(MCP 서버, 훅, 스킬) 안에서 작동하는 나만의 하네스를 만들기로 했다. oh-my-opencode의 hashline 개념을 가져왔고, Can Bölük이 검증한 편집 포맷을 MCP 서버로 구현했다. 이것이 oh-my-hwclaude의 출발점이다.

세 개의 레이어

가장 먼저 도입한 것은 oh-my-claudecode(OMC)다. Yeachan Heo가 만든 오픈소스 멀티에이전트 오케스트레이션 플러그인으로, GitHub 스타 22,700개를 넘긴 검증된 도구다. 19개의 전문 에이전트(탐색, 실행, 디버깅, 아키텍처, 검증 등)를 관리하고, 모델 라우팅(Haiku로 경량 작업, Opus로 복잡한 추론)으로 토큰을 30-50% 절감한다. autopilot, ultrawork, ralph 같은 자율 실행 모드와 팀 파이프라인(plan → PRD → exec → verify → fix)을 제공한다. 이 도구를 직접 만들 이유가 없었다. 이미 커뮤니티에서 충분히 검증되었고, 나의 필요와 정확히 맞았다.

그 위에 oh-my-hwclaude를 쌓았다. 직접 만든 편집 정밀도 하네스다. 핵심은 hashline 시스템으로, 파일을 읽을 때 각 줄에 xxHash32 기반 해시 태그를 붙인다. "4#WS|const count = 0" 같은 형식이다. 편집할 때는 정확한 문자열 대신 해시 위치로 참조한다. 여기에 자동 복구 훅을 더했다. 해시 불일치가 발생하면 자동으로 재읽기를 안내하고, JSON 파싱 에러가 나면 수정 방법을 주입한다. 실패를 가정하고 설계한 시스템이다. 그리고 5계층 게이트키핑(대화 보정 → 지식 참조 → 규칙 적용 → 훅 강제 → 도구 설계)을 통해 같은 실수가 반복되면 자동으로 상위 레이어로 에스컬레이션된다.

마지막으로 business-ai-team을 만들었다. 16개 도메인 전문가 에이전트(제품, 마케팅, 법무, 재무, 영업, 디자인 등)와 17개 플러그인, 110개 이상의 스킬로 구성된 비즈니스 AI 팀이다. 모든 비즈니스 요청은 8단계 라우팅 파이프라인을 거쳐 적합한 전문가에게 전달된다. RLVR(Reinforcement Learning from Verification)로 사용자 피드백을 자동 감지해서 지식에 축적하고, 3건 이상 쌓이면 스킬 문서에 반영한다. 도메인 전문성이 사용할수록 깊어지는 구조다.

이 세 레이어가 각각 존재하는 이유는 책임이 다르기 때문이다. OMC는 "누가 할 것인가"를, hwclaude는 "어떻게 정확하게 실행할 것인가"를, business-ai-team은 "무엇을 알아야 하는가"를 담당한다. 하나로 합치면 책임이 뒤엉키고, 각 레이어를 독립적으로 교체하거나 개선할 수 없게 된다. OMC를 다른 오케스트레이션 도구로 바꿔도 hwclaude와 business-ai-team은 그대로 작동한다. 이 독립성이 세 레이어로 분리한 이유다.

하네스에 집중하는 이유

6주간 세 레이어를 쌓으면서 분명해진 것이 있다. AI 코딩 도구의 실제 성능은 모델이 아니라 하네스에서 결정된다. 모델은 모두가 같은 것을 쓴다. 하네스는 각자 다르다. 이 차이가 같은 도구를 쓰면서도 완전히 다른 결과를 만든다.

하네스 최적화는 눈에 띄지 않는 작업이다. 편집 성공률을 1% 올리면 자율 실행의 안정성이 올라가고, 라우팅 정확도를 높이면 전문가 응답의 품질이 올라가고, 실패 복구 메커니즘을 하나 추가하면 사람의 개입이 한 건 줄어든다. 이 개선들은 하나하나가 작지만 누적되면 작업 방식 자체를 바꾼다. 나는 지금 이 작업에 집중하고 있다.

다음 편에서는 oh-my-hwclaude의 hashline 시스템과 oh-my-claudecode의 오케스트레이션이 결합하여 자율 실행을 가능하게 만드는 과정을 다룬다. 편집이 안 되면 자율도 없다. 이것이 두 번째 레이어의 이야기다.