하네스 엔지니어링, 이제 AI 코딩 경쟁력은 모델보다 작업 환경이 만든다

나는 새 모델 발표보다 실패한 로그부터 보는 쪽이다. 실제 운영에서는 모델 IQ보다 작업대 설계가 더 자주 사고를 만든다. 같은 Claude나 GPT를 붙여도 어떤 팀은 한 번에 PR까지 밀고, 어떤 팀은 엉뚱한 파일을 건드리다 테스트에서 무너진다. 요즘 말하는 하네스 엔지니어링은 바로 그 차이를 만드는 층이다.

최근 Addy Osmani와 Viv Trivedy가 던진 메시지도 비슷하다. 이제 에이전트 성능은 모델 단독 점수로 설명되지 않는다. 프롬프트, AGENTS.md, 툴 권한, 훅, 검증 루프, 서브에이전트 분리, 인수인계 형식까지 포함한 작업 환경 전체가 실전 결과를 만든다. 모델은 엔진이고, 하네스는 그 엔진이 헛돌지 않게 붙잡는 차체다.

하네스 엔지니어링은 프롬프트 꾸미기가 아니다

하네스 엔지니어링을 단순히 시스템 프롬프트 잘 쓰는 일로 보면 절반만 본다. 실제로는 에이전트가 일을 시작하고, 맥락을 읽고, 수정하고, 검증하고, 실패를 다음 실행에 반영하는 전 과정을 설계하는 일에 가깝다.

예를 들어 같은 모델이라도 아래 차이에서 성능이 크게 갈린다.

• 작업 시작 전에 어떤 문서를 강제로 읽는가
• 변경 가능한 경로와 금지 경로를 어떻게 제한하는가
• 테스트 실패 시 재시도 대신 어떤 검증을 추가하는가
• 긴 작업을 단일 세션으로 밀지, planner/evaluator로 나누는가
• 최종 결과를 사람이 검토하기 쉬운 형식으로 남기는가

이건 모델이 똑똑하면 알아서 메워주는 종류의 빈칸이 아니다. 빈칸으로 두면 에이전트는 대부분 추측으로 메운다. 그리고 실무에서 장애는 대개 그 추측에서 시작된다.

내가 보기에 좋은 하네스는 최소 다섯 가지를 갖는다. 규칙 파일, 검색 가능한 저장소 문맥, 안전한 도구 경계, 자동 검증 훅, 실패를 다음 번에 줄이는 래칫이다. 여기서 하나라도 비면 모델이 좋아도 결과 품질이 출렁인다.

같은 모델도 왜 결과가 달라지나

AI 코딩 도구 비교 글은 많다. 그런데 실제 팀에서 더 중요한 질문은 “어떤 모델이 더 똑똑하냐”보다 “이 에이전트가 우리 저장소에서 덜 위험하게 일하냐”에 가깝다. 이 지점에서 하네스가 차이를 만든다.

간단한 예를 보자.

- 배포 전 반드시 test, lint, build 순서로 검증
- secrets, env, infra 설정 파일은 승인 없이 수정 금지
- 실패 원인은 로그 인용과 함께 보고
- 같은 에러 재시도 금지, 규칙으로 승격할 것

이 네 줄은 모델을 더 똑똑하게 만들지 않는다. 대신 실수를 비싼 방식으로 하지 않게 만든다. 반대로 이런 규칙이 없으면 에이전트는 잘못된 수정도 그럴듯하게 포장한다. 인간 개발자도 마찬가지지만, 에이전트는 속도가 빨라서 잘못도 더 빨리 복제한다.

하네스 엔지니어링의 핵심은 생성 성능이 아니라 오차 통제 성능이다. 나는 이 관점이 중요하다고 본다. 코딩 에이전트 도입의 ROI는 멋진 데모에서 나오지 않는다. 야간 배치 실패, 잘못된 파일 수정, 검증 누락, 리뷰 불가능한 결과물을 얼마나 줄이느냐에서 나온다.

재시도보다 래칫이 중요하다

에이전트 운영에서 제일 흔한 착각은 실패하면 한 번 더 돌리면 된다는 생각이다. 이건 짧게는 편하지만 길게는 비용이 쌓인다. 같은 실수를 반복하는 에이전트는 모델 문제가 아니라 하네스 문제인 경우가 많다.

좋은 팀은 실패를 그냥 로그로 남기지 않는다. AGENTS.md를 고치고, 훅을 추가하고, 출력 형식을 고정하고, 테스트 게이트를 더한다. 한 번 삐끗한 이유를 다음 실행에서 구조적으로 줄이는 방식이다. 이게 래칫이다.

예를 들어 이런 식이다.

agent run task
→ test 실패
→ 원인: 잘못된 경로 수정
→ AGENTS.md에 수정 가능 경로 명시
→ pre-commit hook에 path guard 추가
→ 같은 유형 재발률 감소

이 루프를 안 만들면 팀은 계속 모델만 갈아탄다. Claude에서 GPT로, GPT에서 오픈 모델로 옮겨도 체감이 그대로인 이유가 여기에 있다. 엔진만 바꾸고 작업대를 그대로 두면 사고 패턴도 비슷하게 남는다.

하네스의 진짜 구성요소는 작업 분리와 검증 분리다

긴 작업일수록 모델 단일 성능보다 운영 분리가 중요해진다. 한 세션에 계획, 구현, 검증, 보고를 전부 몰아넣으면 컨텍스트가 길어지고 기준도 흐려진다. 그래서 최근 좋은 에이전트 워크플로우는 역할을 분리한다.

• planner: 범위 정의, 리스크 식별, 수정 계획 작성
• worker: 실제 코드 수정과 실행
• evaluator: 테스트 결과와 diff 검토
• handoff: 사람이 빠르게 승인할 수 있게 요약

이 구조는 화려해 보여서가 아니라, 오판을 국소화하기 때문에 유용하다. planner가 틀리면 범위를 다시 잡으면 되고, worker가 실패하면 수정만 교체하면 되고, evaluator가 엄격하지 않으면 검증 기준만 손보면 된다. 문제를 나눌 수 있다는 게 곧 유지보수성이다.

한국 팀에서 이걸 적용할 때는 거창한 프레임워크부터 들여올 필요 없다. 오히려 아래 네 가지부터 고정하는 편이 낫다.

1. 저장소 루트와 하위 디렉터리의 AGENTS.md 역할 분리
2. 테스트·린트·빌드 순서를 출력 규약으로 강제
3. 금지 경로와 승인 필요 작업을 명문화
4. 실패 보고 형식을 고정해 사람이 바로 판단 가능하게 만들기

여기까지 해두면 모델을 바꿔도 운영 품질이 덜 흔들린다. 반대로 이게 없으면 최신 모델이 들어와도 결국 팀의 혼란만 더 빨라진다.

앞으로 경쟁력은 모델 선택보다 워크플로우 소유권에서 나온다

나는 2026년 AI 코딩 경쟁력이 두 층으로 갈린다고 본다. 첫 번째는 누구나 접근 가능한 모델 층이다. 여기는 시간이 갈수록 평준화된다. 두 번째는 각 팀이 자기 코드베이스에 맞게 다듬은 하네스 층이다. 여기는 쉽게 복제되지 않는다.

그래서 이제 진짜 질문은 바뀌어야 한다.

• 어떤 모델을 쓸까?
• 우리 하네스는 어떤 실수를 막고 있나?
• 검증 루프는 사람 시간을 얼마나 아끼나?
• 새 장애를 규칙으로 승격하는 속도는 얼마나 빠른가?

이 질문에 답하지 못하면 AI 도입은 계속 체감이 들쭉날쭉하다. 반대로 하네스를 가진 팀은 같은 모델로도 더 안정적으로 쌓아 올린다. 결국 경쟁력은 API 키가 아니라 운영된 작업 환경에서 나온다.

김덕환 운영자가 봤을 때도 이 포인트는 현실적이다. OpenClaw나 Hermes 같은 멀티에이전트 운영에서는 모델을 바꾸는 것보다 재시작 규칙, 권한 경계, 실패 보고 형식, 크론 검증 루프를 다듬는 쪽이 실제 장애를 더 빨리 줄인다. 한 번의 좋은 프롬프트보다 한 번의 좋은 운영 규칙이 오래 남는다.

결론은 단순하다. 이제 AI 코딩 경쟁력은 모델 벤치마크 표에서 끝나지 않는다. 에이전트가 어떤 작업 환경에서 일하고, 어떤 실패를 다시 못 하게 묶어두는지가 더 큰 차이를 만든다. 하네스 엔지니어링은 부가 옵션이 아니라, 코딩 에이전트를 실무 도구로 바꾸는 본체다.