[AI 이론 공부] 하네스 엔지니어링

모델이 아니라 마구가 진짜다

Claude에게 "메일 발송해줘"라고 했습니다. 돌아온 것은 SMTP 설정, 템플릿 엔진, 첨부파일 처리, 발송 큐, 재시도 로직, 발송 이력 관리까지 포함된 메일 발송 시스템 전체였습니다. 동작은 했습니다. 그러나 제가 원한 것은 한 통의 메일을 보내는 함수였습니다.

50개가 넘는 프로젝트를 바이브 코딩으로 수행하면서, 이런 경험은 반복되었습니다. AI는 매번 강력했습니다. 그리고 매번 방향을 벗어났습니다. 처음에는 모델의 한계라고 생각했습니다. 더 좋은 프롬프트를 쓰면, 더 정교한 컨텍스트를 주면 해결될 것이라고. 그러나 모델을 바꿔도 같은 문제가 반복되었습니다.결국 깨달은 것이 있습니다. 문제는 모델이 아니었습니다. 모델을 감싸는 구조가 없었던 것입니다.2026년, AI 업계가 정확히 같은 결론에 도달했습니다. 그리고 그것에 이름을 붙였습니다. 하네스 엔지니어링(Harness Engineering).

Agent = Model + Harness

하네스(harness)는 원래 말에게 씌우는 마구를 뜻합니다. 강력한 힘을 가진 말이 마차를 끌려면, 그 힘을 올바른 방향으로 전달하는 마구가 필요합니다. 마구가 없으면 말의 힘은 쓸모없는 원시 에너지에 불과합니다.

AI 에이전트도 마찬가지입니다. OpenAI는 2026년 초, Codex를 운영하면서 이 개념을 정립했습니다. 그들의 핵심 통찰은 단순하면서도 강력합니다.

"에이전트를 만드는 것은 쉬운 부분이다. 신뢰할 수 있게 만드는 것이 진짜 엔지니어링이다."

Agent = Model + Harness. 에이전트는 모델과 하네스의 합입니다. 모델이 지능을 제공한다면, 하네스는 제어를 제공합니다. 하네스란 모델을 제외한 모든 것 — 도구 접근 제어, 가드레일, 피드백 루프, 메모리, 오케스트레이션 로직, 그리고 CLAUDE.md 같은 프로젝트 지침 파일까지. 모델이 아닌 모든 것이 하네스입니다.

OpenAI Codex 팀은 이 원칙으로 100만 줄이 넘는 프로덕션 코드를 생성했습니다. 인간이 직접 작성한 코드는 0줄이었습니다. 이것이 가능했던 이유는 더 좋은 모델을 사용했기 때문이 아닙니다. 맞춤형 린터, 구조 테스트, 계층화된 아키텍처 강제, 정기적 드리프트 스캔 — 그들이 만든 것은 코드가 아니라 하네스였습니다.

가이드와 센서 — 마틴 파울러의 프레임워크

하네스 엔지니어링을 체계적으로 정리한 것은 마틴 파울러입니다. 그는 하네스의 핵심 구성 요소를 두 가지로 나누었습니다.

가이드(Feedforward Controls) — 에이전트가 행동하기 전에 올바른 방향으로 유도하는 메커니즘.

CLAUDE.md가 대표적입니다. 프로젝트의 기술 스택, 코딩 컨벤션, 금지 규칙을 파일로 고정해두면, 에이전트는 매 세션 시작 시 이것을 읽고 시작합니다. "요청하지 않은 리팩토링 금지", "snake_case 사용", "새 패키지 추가 전 사용자 확인 필수" — 이런 규칙들이 에이전트의 첫 번째 행동부터 방향을 잡아줍니다. 스킬 문서, 부트스트랩 스크립트, 아키텍처 가이드라인도 모두 가이드입니다.

가이드의 목적은 단순합니다. 첫 시도부터 좋은 결과를 생성할 확률을 높이는 것.

센서(Feedback Controls) — 에이전트가 행동한 후에 자동으로 수정을 돕는 메커니즘.

린터(ruff), 타입 체커(mypy), 테스트(pytest)가 대표적 센서입니다. 에이전트가 코드를 생성하면, 센서가 즉시 검증합니다. "이 함수의 반환 타입이 선언과 다릅니다." "이 테스트가 실패합니다." 에이전트는 이 피드백을 받아 스스로 수정합니다. 문제가 인간의 눈에 도달하기 전에 자동으로 교정되는 것입니다.

마틴 파울러는 센서를 다시 두 종류로 구분합니다.

계산적(Computational) 센서는 결정론적이고 빠릅니다. 린터, 타입 체커, 구조 테스트 — 밀리초 단위로 실행되고, 결과가 항상 같습니다. 저비용이라 모든 변경마다 실행할 수 있습니다.

추론적(Inferential) 센서는 AI 기반입니다. 코드 리뷰 에이전트, 의미론적 분석 — 느리고 비싸지만, "이 코드가 프로젝트의 설계 의도에 맞는가?"처럼 계산적 센서가 잡지 못하는 것을 잡습니다.

좋은 하네스는 이 둘을 계층적으로 배치합니다. 빠르고 싼 계산적 센서로 기본 품질을 확보하고, 느리지만 깊은 추론적 센서로 의미적 일관성을 검증합니다.

왜 지금인가

2025년은 AI 에이전트가 코드를 쓸 수 있다는 것을 증명한 해였습니다. 2026년은 에이전트가 아니라 하네스가 진짜 어려운 부분이라는 것을 깨달은 해입니다.

가장 극적인 사례는 LangChain입니다. 그들은 코딩 에이전트 벤치마크인 Terminal Bench 2.0에서 모델을 바꾸지 않고 하네스만 개선하여 30위권에서 5위권으로 25단계를 뛰어올랐습니다. 점수는 52.8에서 66.5로. 같은 모델, 같은 에이전트. 달라진 것은 오직 하네스뿐이었습니다.

이것이 시사하는 바는 명확합니다. 진짜 레버는 모델이 아니라 하네스에 있습니다.

Stripe의 Minions 팀도 같은 결론에 도달했습니다. 그들은 pre-push 훅으로 휴리스틱 기반 린터를 실행하고, "피드백을 왼쪽으로 이동"시키는 전략을 채택했습니다. 가능한 한 빨리, 가능한 한 자동으로, 에이전트의 출력을 검증하는 것. 이것이 Stripe가 에이전트 코딩을 프로덕션에 도입할 수 있었던 이유입니다.

50개가 넘는 프로젝트를 바이브 코딩으로 수행한 저의 경험도 같은 맥락입니다. 초기에는 프롬프트를 다듬는 데 시간을 썼습니다. 그 다음에는 컨텍스트를 정교하게 구성하는 데 집중했습니다. 그러나 프로젝트의 품질이 일관되게 올라간 것은, CLAUDE.md를 작성하고, SDD 체계(SPEC → PLAN → TASK)를 도입하고, ruff와 mypy와 pytest를 자동 검증 파이프라인으로 묶은 이후였습니다.

돌이켜보면, 저는 이름을 몰랐을 뿐 하네스를 만들고 있었던 것입니다.

모델의 지능은 이미 충분하다

"Harness"라는 단어에는 두 가지 의미가 있습니다. 명사로는 마구(馬具). 동사로는 "힘을 유용하게 활용하다". Harness solar energy — 태양 에너지를 활용하다. 이 동사의 의미가 하네스 엔지니어링의 본질을 정확히 담고 있습니다.

전기 하네스(wire harness)는 수백 개의 전선을 묶어 올바른 신호가 올바른 장치에 전달되도록 경로를 구조화합니다. 안전 하네스(safety harness)는 작업자가 자유롭게 움직이되, 치명적 영역에 진입하면 잡아줍니다. 테스트 하네스(test harness)는 코드를 격리된 환경에서 실행하고, 입력을 넣고, 출력을 검증합니다.

모든 하네스의 공통점이 있습니다. 어떤 하네스도 힘 자체를 만들어내지 않는다는 것. 힘은 이미 존재합니다. 말의 근력, 전기 신호, 중력, 그리고 AI의 지능. 하네스는 그것을 유용하게 만드는 구조일 뿐입니다.

AI 모델의 지능은 이미 충분합니다. GPT-4든, Claude든, Gemini든 — 코드를 생성하는 능력은 놀라울 정도로 강력합니다. 그러나 그 지능이 프로젝트의 목적지에 도달하려면, 방향을 잡아주는 가이드와 이탈을 교정하는 센서가 필요합니다.

30년간 코드를 짜온 개발자로서, 모델 경쟁의 시대는 이미 지나고 있다고 느낍니다. 다음 경쟁은 하네스에서 벌어질 것입니다. 같은 모델을 사용하더라도, 더 좋은 하네스를 가진 팀이 더 신뢰할 수 있는 결과를 만들어낼 것입니다.

모델을 바꾸기 전에, 하네스를 바꿔 보십시오.