모델 선택은 이미 상품화됐다
팀에서 AI 에이전트를 처음 프로덕션에 올릴 때 가장 많은 시간을 쓰는 논쟁이 있다. GPT-4o냐, Claude 3.5냐, Gemini 1.5냐. 벤치마크를 비교하고, 컨텍스트 윈도우를 재고, 비용 계산기를 돌린다. 그런데 솔직하게 말하면, 이 논쟁에서 이기는 팀과 지는 팀의 격차는 갈수록 좁아지고 있다. 프론티어 모델들의 실용적 능력 차이가 대부분의 유스케이스에서 이미 무의미한 수준으로 수렴했기 때문이다.
진짜 격차는 다른 곳에서 벌어진다. dev.to에 올라온 Harness Engineering 아티클이 정확히 짚는 지점이다: 모델은 병목이 아니다. 병목은 모델 주변의 모든 것이다. 이걸 하네스 엔지니어링(Harness Engineering)이라고 부른다. 에이전트를 감싸고, 통제하고, 관찰하고, 제약하는 인프라 전체를 말한다. 엔진이 모델이라면 하네스는 섀시, 대시보드, 안전벨트, 정비사의 진단 툴을 동시에 겸한다.
하네스는 다섯 레이어로 쌓인다
하네스 엔지니어링을 추상적 개념으로 남겨두면 팀에 아무 도움이 안 된다. 실제 설계 결정이 필요한 레이어를 분리해서 봐야 한다.
실행 오케스트레이션은 에이전트가 툴을 호출할 때 라우팅, 재시도, 타임아웃, 결과 컨텍스트 복귀를 담당한다. LangGraph나 CrewAI 같은 프레임워크가 여기 속한다. 핵심은 툴 호출을 멱등(idempotent) 연산으로 만드는 것—재시도가 같은 이메일을 두 번 보내는 사고를 막는 기본 설계다.
평가 하네스는 에이전트가 실제로 잘 작동하는지 측정한다. LangSmith나 Braintrust 같은 툴로 정의된 태스크 셋을 돌리고 점수를 낸다. 이 레이어를 건너뛰면 프롬프트 한 줄 바꿨을 때 어떤 능력이 조용히 퇴보했는지 알 방법이 없다. 소프트웨어 팀이 테스트를 먼저 쓰듯, 에이전트 팀은 eval을 먼저 써야 한다.
관찰성 하네스는 에이전트가 무슨 툴을 어떤 순서로 어떤 인자로 호출했는지 추적한다. OpenTelemetry, LangSmith 트레이스, PostHog 같은 통합이 여기 들어온다. 에이전트는 미묘하게 실패한다—3번째 추론 단계에서 틀린 파라미터로 옳은 툴을 부를 수 있다. 관찰성 없이는 추측으로 디버깅한다.
안전·제약 하네스는 실행 레이어와 분리해서 설계해야 한다. 실행 로직은 에이전트가 어떻게 행동하는지를 결정하고, 안전 로직은 에이전트가 행동해도 되는지를 결정한다. 두 관심사를 같은 코드에 섞으면 양쪽 모두 감사하기 어려워진다.
메모리 하네스는 단순 로그 누적이 아니다. 무엇을 유지하고, 무엇을 압축하고, 무엇을 잊을지를 결정하는 설계다. 컨텍스트를 무한정 쌓으면 오히려 모델 집중도가 떨어지고 비용은 올라간다.
사전 검증보다 사후 재현이 먼저다
하네스 설계에서 가장 과소평가되는 레이어를 하나 꼽으라면 사후 디버깅 인프라다. SafeRun 팀이 dev.to에 공유한 빌드 스토리가 이 지점을 날카롭게 건드린다.
팀이 AI 에이전트를 프로덕션에 올리고 첫 번째 사고를 맞닥뜨렸을 때 공통적으로 겪는 패턴이 있다. 에이전트가 하면 안 되는 행동을 했다. 조사에 착수한다. 그런데 재현이 안 된다. 트레이스는 납작하다. 툴 호출 사이의 모델 추론이 기록되어 있지 않다. 실패한 호출의 인자가 완전히 캡처되지 않았다. 의사결정을 이끈 컨텍스트가 없다. 에이전트는 비결정론적이라 재실행해도 같은 실패를 만들기 어렵다. 결국 주말을 통째로 날린다.
SafeRun이 첫 번째로 만든 것이 바로 이 문제를 푸는 Replay 레이어다. 관찰성 툴이 무슨 일이 일어났는지를 설명한다면, Replay는 그 순간으로 돌아가 프레임 단위로 다시 실행할 수 있게 한다. 각 툴 호출의 정확한 인자, 호출 사이의 모델 추론, 각 의사결정 시점의 검색 컨텍스트, 해당 시점에 적용된 정책 버전—이 모든 것을 결정 시점에 스냅샷으로 캡처한다.
이 팀이 드는 사례가 구체적이다. 에이전트가 청구(charge) 대신 환불(refund)을 실행했다. $4,500. 트레이스에는 "Stripe 환불 완료"만 남아 있다. Replay가 있었다면 에이전트의 플래닝 단계에서 is_refund: false였던 boolean이 툴 호출 직전 어디서 뒤집혔는지—모델 할루시네이션인지, 프롬프트 인젝션인지, 코드 버그인지, 컨텍스트 오해석인지—정확히 특정할 수 있다. 원인을 알아야 방지 규칙을 만들 수 있다. 원인 없이 만든 규칙은 증상 패치다.
팀이 반복하는 실수들
하네스 엔지니어링의 실수는 대부분 잘못된 툴 선택이 아니라 잘못된 순서에서 온다.
가장 흔한 실수는 에이전트를 먼저 만들고 관찰성을 나중에 붙이려는 것이다. "일단 돌아가게 하고 모니터링은 나중에"—이 결정이 첫 번째 프로덕션 사고 때 얼마나 비싸게 돌아오는지는 경험해본 팀은 안다. 관찰성과 eval 인프라는 처음부터 함께 설계해야 한다. 나중에 역으로 끼워 넣는 게 훨씬 어렵다.
두 번째는 고위험 액션에 대한 human-in-the-loop를 생략하는 것이다. 초기에 속도를 위해 승인 게이트를 건너뛰는 건 저위험 툴에서는 합리적 트레이드오프다. 그런데 금융 시스템을 건드리거나, 외부 커뮤니케이션을 발송하거나, 공유 상태를 수정하는 에이전트는 다르다. 이건 영구 설계가 아니라 시스템이 자율성을 신뢰받기 전까지의 신뢰 구축 메커니즘이다.
테크 리드가 지금 해야 할 설계 결정
두 아티클이 수렴하는 결론은 하나다: 프로덕션 에이전트의 차별화는 모델이 아니라 하네스에서 온다. 그리고 그 하네스에서 가장 먼저 투자해야 할 레이어는 화려한 안전 필터가 아니라 실패를 재현하고 이해할 수 있는 능력이다.
내일 팀에 당장 적용할 수 있는 체크리스트를 정리하면 이렇다:
- 에이전트 설계와 eval 하네스는 동시에 시작한다. 나중은 없다.
- 툴 호출은 기본적으로 멱등 연산으로 설계한다.
- 실행 레이어와 안전 레이어는 코드 레벨에서 분리한다.
- 메모리는 로그가 아니다. 무엇을 버릴지를 명시적으로 설계한다.
- 첫 번째 프로덕션 사고 전에 Replay 인프라를 확보한다.
전망: 하네스가 모델보다 오래 산다
모델은 교체된다. 6개월마다 더 나은 버전이 나오고, 누구든 API 키 하나로 갈아탈 수 있다. 하지만 몇 년간 정제된 충돌 감지 로직, 의사결정 히스토리 탐색 아키텍처, eval 파이프라인은 복사하기 어렵다. 경쟁자가 더 좋은 모델을 써도 당신 팀의 하네스가 더 잘 만들어져 있다면—더 빠르게 실패를 진단하고, 더 정확하게 방지 규칙을 만들고, 더 안전하게 에이전트를 운용할 수 있다면—그게 지속 가능한 기술 우위다.
데모를 만드는 팀은 모델을 고른다. 프로덕트를 만드는 팀은 하네스를 쌓는다.