AI 코딩 도구가 마음에 들지 않을 때 가장 먼저 하는 일은 모델을 바꾸는 것입니다.
Luna가 아쉽다 → Sol
Sol이 아쉽다 → Astra
Astra가 아쉽다 → Claude
물론 모델 교체가 답일 때도 있습니다.
하지만 같은 모델을 쓰는데도 프로젝트마다 결과가 크게 달라진다면 모델 밖을 볼 필요가 있습니다.
모델은 혼자 일하지 않습니다
에이전트형 코딩 도구에서는 모델이 실제 작업의 한 부분일 뿐입니다.
대략 이런 구조로 움직입니다.
User request
↓
Project instructions
↓
Model
↓
Tools
↓
Files / Terminal / Browser
↓
Tests / Checks
↓
Retry / Repair
이 주변 구조를 넓게 harness라고 볼 수 있습니다.
좋은 모델이 있어도:
- 프로젝트 규칙을 모른다
- 테스트 명령을 모른다
- 어느 파일을 건드리면 안 되는지 모른다
- 실패를 확인하지 않는다
- 한 번 답하고 끝낸다
면 결과가 쉽게 흔들립니다.
실제 벤치마크도 모델과 agent를 함께 봅니다
최근 코딩 벤치마크는 모델 이름만 적지 않는 경우가 많습니다.
Artificial Analysis의 Coding Agent Index는 모델을 특정 agent/harness에서 실행해 평가합니다. OpenAI 모델은 Codex harness와 결합해서 측정되는 식입니다.
Terminal-Bench도 같은 이유로 단순 코드 생성이 아니라 실제 터미널 환경에서 에이전트가 어떻게 행동하는지를 봅니다.
이 관점이 중요한 이유는 간단합니다.
Model capability
≠
End-to-end agent performance
입니다.
같은 모델로 두 환경을 만들어봅시다
CodeBridge Mini Lab으로 아주 작은 실험을 할 수 있습니다.
A. 최소 환경
AI에게 이렇게만 요청합니다.
이 프로젝트의 로그인 버그를 수정해줘.
B. 하네스를 조금 보강한 환경
같은 모델에게 다음 조건을 제공합니다.
목표:
로그인 validation bug를 수정한다.
규칙:
- src/auth 외 파일은 필요할 때만 수정
- public API signature 변경 금지
검증:
- npm test 실행
- npm run lint 실행
- 실패하면 원인을 확인하고 한 번 수정
완료 조건:
- 모든 테스트 통과
- 새 regression test 추가
- 변경 파일과 이유 요약
모델은 동일합니다.
달라진 것은 일할 환경입니다.
무엇을 비교해야 할까?
각 조건을 3번씩 실행해 다음을 적어봅니다.
Tests passed
Retries
Files changed
Unexpected changes
Human correction needed
Time
만약 B가 더 안정적이라면 그 차이는 모델 업그레이드가 아니라 하네스 개선에서 나온 것입니다.
물론 이것이 항상 B가 더 좋다는 뜻은 아닙니다. 규칙을 너무 많이 넣으면 모델을 오히려 방해할 수도 있습니다.
그래서 중요한 것은 “지시를 많이 쓰기”가 아니라 실패 지점을 찾아 필요한 구조만 추가하는 것입니다.
가장 먼저 추가할 세 가지
복잡한 agent framework가 없어도 다음 세 가지부터 시작할 수 있습니다.
1. 프로젝트 규칙
어떤 디렉터리가 핵심인가?
어떤 API는 바꾸면 안 되는가?
코딩 스타일은 무엇인가?
2. 검증 명령
npm test
pytest
cargo test
npm run lint
3. 완료 조건
테스트 통과
불필요한 파일 변경 없음
기존 기능 회귀 없음
이 세 가지만 있어도 AI가 “코드를 생성하는 도구”에서 “작업을 완료하는 도구”로 조금씩 바뀝니다.
모델 업그레이드와 하네스 개선을 구분해야 하는 이유
문제가 생겼을 때 원인을 분리하기 쉽기 때문입니다.
모델을 바꿨더니 해결
→ capability 문제 가능성
검증 루프를 넣었더니 해결
→ process 문제 가능성
프로젝트 규칙을 넣었더니 해결
→ context 문제 가능성
이렇게 원인을 나눌 수 있어야 비용도 줄일 수 있습니다.
하네스가 잘 잡혀 있다면 모든 작업에 최고급 모델을 쓸 필요가 줄어들 수도 있습니다.
OpenAI Agents API가 보여주는 방향
OpenAI가 2026년 9월 공개한 Agents API도 비슷한 흐름을 보여줍니다.
OpenAI는 장기 실행 에이전트에 필요한 요소로 context 관리, tool 사용, subagent coordination, durable session과 sandbox 같은 구조를 강조합니다.
즉 모델 호출 하나를 제공하는 것에서 더 나아가 모델이 오래 일할 수 있는 실행 환경 자체를 API로 제공하는 방향입니다.
결론: 모델을 바꾸기 전에 실패 구조를 먼저 보세요
AI 코딩이 잘 안 될 때 항상 “더 좋은 모델”이 필요한 것은 아닙니다.
한 번은 이렇게 질문해보세요.
이 모델이 일을 못하는 걸까, 아니면 일을 잘할 환경을 주지 않은 걸까?
프로젝트가 커질수록 이 질문의 가치가 커집니다.
그리고 하네스 엔지니어링의 출발점도 거창한 framework가 아니라 반복되는 실패를 환경 설계로 줄이는 것에 가깝습니다.