코딩 에이전트를 '스스로 개선하는 루프'로 만드는 법: 하네스 설계의 원리

코딩 에이전트에게 자율성을 주는 초기 방식은 대개 단순했다. 계획과 테스트를 건네고, 테스트가 통과할 때까지 작업을 반복시키는 식이다. 작업의 정의가 테스트로 온전히 표현될 수 있을 때는 잘 작동한다. 문제는 우리가 아직 제대로 이해하지 못한 제품 역량을 '키워야' 하는 경우다. 이때 에이전트는 계속 움직이지만, 움직임 자체가 성과를 보장하지 않는다. 테스트는 이미 아는 것만 지켜줄 뿐이고, 정작 중요한 실패는 테스트 바깥에 숨어 있다. 화면은 완성된 것처럼 보이지만 아무것도 저장하지 않을 수 있고, 에이전트는 잘못된 근거로 정답을 낼 수 있으며, 채점기는 아무도 원치 않는 행동에 보상을 줄 수 있다. 반복 횟수를 늘리면 이런 실패는 더 싸고 빠르게 양산될 뿐이다.

원문 저자는 앞선 글 'The Convergence Problem'에서 '에이전트는 턴(turn)을 소유하고 사람은 라운드(round)를 소유한다'는 구분을 제시했다. 이번 글의 핵심은 그 경계 사이에서 에이전트가 무엇을 필요로 하는가에 대한 답이다. 그것은 재시도 프롬프트를 붙인 에이전트가 아니라, 세 가지를 해내는 하네스(harness)다. 실제 실패를 드러내고, 빠진 역량을 정확히 짚어내며, 세션이 끝난 뒤에도 그 교훈을 보존하는 것. 여기서 흥미로운 점은 우리가 만들어야 할 시스템이 둘이라는 것이다. 하나는 눈에 보이는 '기능(feature)'이고, 다른 하나는 에이전트가 다음에 무엇을 바꿔야 할지 결정하는 '프로세스'다.

개발 에이전트와 제품 에이전트를 분리하라

하네스를 구성하는 역할은 명확히 나뉜다. 개발 에이전트는 코드를 바꾸고, 드라이버(driver)는 실제 사용자와 똑같은 표면을 통해 기능에 접근하며, 채점기는 무슨 일이 벌어졌는지 읽고, 컨트롤러는 그 증거로부터 다음에 메울 간극을 고른다. 특히 제품 자체가 에이전트를 품고 있는 경우, 개발 에이전트와 제품 에이전트는 반드시 분리되어야 한다. 개발 에이전트는 코드와 기대 결과를 알지만, 제품 에이전트는 새로운 대화 세션에서 제품이 노출하는 도구만 쥔 채 시작해야 한다. 둘이 컨텍스트를 공유하는 순간 테스트는 무의미해진다. 실제 사용자는 결코 제공하지 않을 지식으로 제품 에이전트가 '성공'해버리기 때문이다. 같은 하네스는 제품 에이전트 없이도 작동한다. 드라이버는 브라우저, API, 커맨드, 하드웨어 시뮬레이터 무엇이든 될 수 있다.

프롬프트보다 '세계'가 중요하다

사람들은 프롬프트에 관심을 쏟는다. 눈에 보이기 때문이다. 그러나 루프의 성패는 그 주변 '세계'에 더 크게 달려 있다. 우선 하네스에는 재현 가능한 출발점이 필요하다. 데이터, 서비스, 모델, 환경, 실제로 서빙되는 코드가 기록된 실행과 일치해야 하고, 리셋은 그 지점으로 되돌려야 하며, 프리플라이트(preflight)가 그 사실을 증명해야 한다. 세계가 건강하지 않으면 하네스는 점수를 기록하지 않는다. 인프라 문제는 기능이 실패했다는 증거가 아니기 때문이다. 이 구분은 대규모의 잘못된 수리를 예방한다. 누락된 데이터는 빈약한 추론처럼 보이고, 낡은 코드는 깨진 계약처럼 보이기 쉽다.

다음으로 필요한 것은 '실제 수요'다. 사람이 작성했거나 승인한 소규모 요청 코퍼스를 두고, 드라이버는 그 요청 하나를 변형 없이 새 세션에 흘려보낸다. 그리고 답변, 도구 호출, 거부된 행동, 눈에 보이는 결과, 그리고 지속적 효과를 모두 기록한다. 이 중 가장 중요한 것은 효과다. 소프트웨어는 올바른 행동을 '서술'하면서도 실제로는 수행하지 않을 수 있고, 그럴듯한 화면을 렌더링하면서 그 아래 시스템은 전혀 바꾸지 않을 수 있다. 그래서 프롬프트는 여러 입력 중 하나일 뿐이며, 픽스처·코드 리비전·모델·계약·채점기가 그 옆에 나란히 놓여야 한다. 이런 입력이 빠진 점수는 그저 숫자에 불과하다.

하나의 간극은 하나의 파일이 아니라 하나의 인과 사슬

모든 루프에는 결정론적 바닥이 필요하다. 테스트·검증기·스키마·효과 검사는 기능이 이미 획득한 행동을 붙잡아 둔다. 바닥은 녹색에서 시작하고, 붉게 변하면 그 회귀가 다음 작업이 된다. 다만 바닥은 다음에 무엇을 만들어야 할지는 말해주지 못한다. 그 방향은 실제 요청을 구동하고 부족분을 들여다봐야 정해진다. 한 라운드가 메우는 '하나의 간극'은 하나의 파일이 아니라 하나의 인과적 주장이다. 빠진 역량은 데이터 모델, 도구 계약, 런타임, 에이전트 지시, 인터페이스, 효과 검사를 가로지를 수 있으며, 라운드는 그 경로 전체를 닫아야 한다. 인터페이스는 있는데 데이터를 만드는 것이 없거나, 도구는 성공을 반환하는데 상태는 바뀌지 않는 '부분 경로'가 가장 그럴듯한 실패를 만든다. 요청에서 효과까지 관통하는 좁은 경로 하나가, 다섯 겹의 미완성 가능성보다 낫다. 이때 증상을 세계·도메인·계약·런타임·조종·표면·하네스 중 어디에 속하는지 분류하는 단계가 무작위 수리를 막아준다. 이 단계가 없으면 모든 에이전트 실패는 프롬프트 문제가, 모든 시각적 실패는 프론트엔드 문제가 되어버린다.

권한 모델과 세 개의 루프

자율 루프는 도달할 수 있는 측정치라면 나쁜 것이라도 최적화하려 든다. 그래서 하네스에는 권한 모델이 필요하다. 자유 파일은 정상적인 구현 레버로, 루프가 자유롭게 바꾸고 측정한다. 제안 파일은 경계를 넘는 것으로, 루프는 증거를 남기고 변경을 제안하되 결정은 사람이 한다. 동결 파일은 시험지 자체로, 승인된 코퍼스·픽스처·기존 단계·채점 규칙·판정 루브릭을 포함한다. 루프는 관찰한 실패에 대한 회귀 검사를 추가할 수는 있어도, 기존 검사를 약화하거나 임계값을 낮출 수는 없다. 무엇보다 제품 레버와 그 레버의 측정치를 같은 라운드에서 함께 바꿀 수 없다. 그렇지 않으면 자기 수리를 스스로 채점하는 꼴이 된다. 학습된 시각 판정기 역시 반복된 인간 순위와 일치하기 전까지는 증거로만 취급된다.

결국 서로 다른 속도로 도는 세 개의 루프가 있다. 제품 루프는 매 라운드 하나의 역량을 닫고, 하네스 루프는 반복된 증거가 개발 과정의 결함을 드러낼 때 바뀌며, 방향 루프는 그 바깥에서 사람이 증거 묶음을 읽고 계속할지·방향을 틀지·멈출지를 정한다. 이 모든 것은 현재 대화에만 머물 수 없다. 세션은 끝나고 컨텍스트는 압축되기 때문이다. 그래서 goals/ 아래에 작은 꾸러미를 둔다. LOOP.md는 프로세스가 바뀔 때만, STATE.md는 매 라운드 뒤에 갱신된다. 덕분에 세션은 버려도 되지만 작업은 기억을 잃지 않는다. 실무자에게 남는 조언은 절제되어 있다. 완결된 테스트로 작업을 서술할 수 있다면 이 모든 장치는 필요 없다. 세 개의 요청, 하나의 픽스처, 하나의 채점 커맨드, 하나의 루프 파일과 상태 파일, 세 라운드 예산으로 시작하고, 실패가 정당화할 때만 새 통제를 더하라. 좋은 라운드가 남기는 것은 작동하는 역량, 그것이 작동한다는 증거, 그리고 같은 교훈에 두 번 비용을 치르지 않을 하네스다.