AI 코딩에서 인간을 배제하는 것은 모델의 문제가 아니라 하네스(harness)의 문제다
Removing the human from AI coding is a harness problem, not a model problem
핵심 요약
AI 코딩의 신뢰성은 모델 성능보다 자동화된 검증 시스템인 '하네스' 구축에 달려 있습니다.
- 하네스 중심 접근 — AI의 결과물을 무조건 신뢰하지 말고 코드 기반으로 자동 검증해야 함
- 기계적 엄격함 — 인간의 개입을 최소화하고 자동화된 감사 추적과 검증 프로세스를 도입해야 함
- 컨텍스트 분리 — 코드 작성 에이전트와 검증 에이전트의 컨텍스트를 분리하여 독립성을 확보해야 함
- 역할 재정의 — 에이전트가 스스로 판단하게 하지 말고, 구체적인 실패 모드를 확인하도록 강제해야 함
세 줄 요약: 더 좋은 모델 쓴다고 AI 코딩이 믿을만해지는 거 아니다. 더 좋은 '안전장치'가 필요함. 에이전트가 하는 말 믿지 말고, 코드로 직접 검증해라.
일리노이 대학교랑 메타, 스탠퍼드에서 최근에 낸 논문(댓글에 링크 있음)이 있는데, 앞으로 몇 년간 핵심이 될 내용을 담고 있음. 코드는 이제 에이전트가 뱉어내는 결과물일 뿐만 아니라, 에이전트가 사고하고 행동하고 조율하는 '안전장치(harness)' 그 자체가 된다는 거임. 이거 읽어보니까 내가 지난 몇 달간 고민하던 거랑 딱 맞아떨어져서 흥미롭더라.
지금 시점에서 에이전트 코딩의 핵심은 결국 '결과물을 얼마나 믿을 수 있느냐'임. 에이전트가 코드를 얼마나 많이 뽑아내느냐, 동시에 몇 개를 돌리느냐는 중요하지 않음. 다이내믹한 워크플로우나 루프, 서브 에이전트 100개 돌리는 것도 마찬가지임. 진짜 중요한 건, 전체 시스템이 조용히 박살 나지 않게 하면서 내가 얼마나 개입을 줄일 수 있느냐임.
그럼 어떻게 해야 할까? 답은 간단함. 인간의 개입을 한 단계씩 줄여나가는 거임. 가장 안전한 방법은 엄격함을 기계적으로 강제하고, 과정을 최대한 자동화해서 항상 감사 추적(audit trail)이 남게 하는 거임. 에이전트를 믿지 말고, 가능한 한 프로그래밍 방식으로 검증하고, 도저히 자동화가 안 되는 부분에만 인간이 개입해라. 마지막으로, 어디서 문제가 터지는지 계속 추적해야 함.
아래 내용은 특정 툴이나 프로젝트에 종속된 게 아님. 뭐 엄청나게 새로운 것도 아님. 그냥 안 하고 있었다면 유용한 것들 골라 쓰면 됨.
일단 기본부터: 스펙 기반 프레임워크를 써라. superpowers, spec kit, OpenSpec 같은 거 안 써봤으면 당장 시작해라. 이게 가장 가성비 좋은 안전장치임. 아래 내용은 다 이게 깔려있다는 전제하에 쓴 거다.
그다음은 이거임:
에이전트가 명령어(command)로 할 수 있는 일을 굳이 시키지 마라. "테스트 통과했나?", "스키마에 맞나?" 같은 건 그냥 0이 아닌 종료 코드를 뱉는 명령어로 만들 수 있음. 에이전트가 "다 잘 됐어요"라고 구구절절 떠드는 것보다, 제대로 된 종료 코드 하나가 훨씬 믿음직함.
에이전트가 머리 굴려서 사실을 파악하게 하지 말고, 그냥 명령어를 실행하게 해라. 명령어 하나로 진실(현재 스택, 테스트 위치, 의존성 등)을 바로 꽂아줄 수 있으면 그렇게 해라. 매번 새로 찾게 하지 말고. Anthropic의 cc용 빌트인 툴들이 아주 좋은 예시임. 모델들이 find, sed, tail 같은 거 써서 안전장치를 다루는 데 도가 텄거든. 그래서 다들 이제 더 만들 게 없다고 생각하는데, 천만에. 에이전트가 필요한 걸 딱딱 짚어주는 결정론적 명령어를 직접 만드는 게 훨씬 나음. 기계적으로 확실하고 파이프라인에 넘기기도 좋으니까. 토큰 아끼는 건 덤이고.
신경 써야 할 규칙들을 컨텍스트 윈도우 밖으로 빼서 아예 실행을 막아버려라. 스킬이나 claude md, 에이전트 템플릿에 적어둔 규칙은 컨텍스트 꽉 차면 에이전트가 언제든 까먹을 수 있는 제안일 뿐임. git pre-commit 훅만 써도 웬만한 건 다 막힘. 0이 아닌 코드가 나오면 커밋 자체가 안 되니까. git으로 실시간 대응이 안 되면 CC 훅을 써라. 테스트가 빨간불인데 에이전트가 지 맘대로 끝내려고 하면 막아버리는 Stop 훅이나, rm -rf 실행하기 전에 컷하는 PreToolUse 훅 같은 거 말임. CI가 최후의 보루긴 한데, 이건 빌드 에이전트가 다 끝난 뒤에 작동하니까 실패하면 결국 내 책임이 됨. 체크를 빨리 할수록(훅 > 명령어 > CI) 에이전트가 사고 치기 전에 지가 알아서 수습할 확률이 높음.
컨텍스트를 다이내믹하게 주입해라. 낡아빠진 정적 컨텍스트를 계속 들고 있지 마라. 스킬이나 슬래시 커맨드로 명령어를 실행해서 결과를 바로 꽂아넣을 수 있음. !git diff HEAD 같은 건 Claude가 파일을 읽기도 전에 먼저 실행됨. claude md나 에이전트 템플릿은 정적이라 이게 안 되지만, SessionStart 훅으로 세션 시작할 때 컨텍스트 주입하는 사람들도 있더라. 어쨌든 핵심은 이거임: 에이전트한테 옛날 정보 주지 말고, 지금 당장 진짜인 정보를 줘라.
역할을 분리하고 컨텍스트를 깔끔하게 유지해라. SDD 쓰라고 한 거랑 같은 맥락인데, 코드를 짜는 에이전트랑 검증하는 에이전트는 컨텍스트 윈도우를 공유하면 안 됨. 독립성이 보장되어야 '검증'이라는 단어에 의미가 생기는 거임. 빌더의 생각을 읽는 검증기는 그냥 아부나 떨면서 지가 짠 코드에 동조만 할 뿐임.


