하네스를 처음부터 다시 만들었습니다

Pogl에서는 AI가 사람들과 대화하며 경험을 만들고 고칩니다. 이 일을 하는 작업 틀을 저희는 하네스라고 부릅니다. 11월 9일, 이 하네스를 처음부터 다시 만들기로 했습니다.

처음에는 OpenCode로 시작했습니다

OpenCode는 많은 개발자가 쓰는 오픈소스 코딩 에이전트입니다. 이미 많이 쓰이며 검증된 도구였고, 파일을 읽고 고치는 기능, 모델을 바꾸는 기능, 다른 도구를 연결하는 기능이 갖춰져 있었습니다. 그래서 에이전트는 OpenCode를 그대로 쓰고, 저희는 그 위에 게임을 띄워 확인하는 도구와 배포 전 검사를 붙였습니다. 이것이 Pogl Builder입니다.

쓰다 보니 세 가지가 맞지 않았습니다

결국 저희 기능을 많이 넣게 됐습니다. 모델 고르기, 비용 계산, 공급자 장애 때 다른 곳으로 넘기기는 저희가 만든 중간 계층이 맡게 됐고, 도구와 검사도 저희 것이었습니다. 11월에는 OpenCode가 맡은 일이 파일을 읽고 고치는 반복 정도만 남아 있었습니다.

개인 컴퓨터가 아니라 가상 샌드박스에서 돌아야 했습니다. OpenCode는 개발자의 컴퓨터에서 쓰는 도구입니다. Pogl에서는 작업마다 가상 컴퓨터를 켜고 그 안에 OpenCode 서버(약 0.63GB)를 설치했고, 워커는 결과가 나올 때까지 계속 물어보며 기다렸습니다. 매 요청 앞에 붙는 고정 부분도 약 1만 4천 토큰이었습니다. 크기와 성능을 이 환경에 맞게 줄일 필요가 있었습니다.

레거시 기능이 많이 쌓여 비효율적이었습니다. 새 기능은 OpenCode 바깥에 길을 하나씩 더하는 방식으로 붙었습니다. 11월 9일 기준으로 요청 종류에 따라 갈라지는 길이 16개, 작업이 끝났는지 판정하는 방식이 3가지, AI에게 주는 계약 문서가 6~7가지였고, 화면에서 걷은 기능의 엔진도 하네스에 남아 있었습니다. 같은 문제를 길마다 따로 고쳐야 했고, 워커를 다시 시작하면 돌던 작업이 끊겼습니다.

모델이 좋아질수록 하네스는 단순해야 했습니다

최근 다른 회사들의 글과 연구도 같은 방향이었습니다. 모델이 강해질수록 하네스에 쌓은 복잡한 구조는 도움이 되기보다 방해가 된다는 것입니다.

• Lovable은 하위 에이전트에 일을 나눠 맡기는 복잡한 구조를 만들었다가 에이전트 코드를 거의 모두 지웠습니다. (How we built Lovable, 2026년 11월)
• Replit은 새 모델이 나올 때마다 하네스에 넣은 가정이 낡는다며, 판단은 모델에 맡기고 하네스는 선택지와 안전장치만 둡니다. (Free the models, 2026년 9월)
• Cursor는 에이전트 루프, 가상 컴퓨터 상태, 대화 기록을 서로 분리했습니다. (What we’ve learned building cloud agents, 2026년 6월)
• Apple 연구진은 같은 모델과 같은 시간이면 복잡한 하네스가 단순한 에이전트보다 낫지 않았다고 발표했습니다. (How Much of a Harness Does a Strong Agent Need?, 2026년 10월)

그래서 AI가 일하는 구조인 루프 · 도구 · 계약 · 대화 기록은 처음부터 새로 만들었습니다. 다만 돈 · 환급 · 검사 규칙은 실제 사고를 겪으며 생긴 것이라 이전 코드에서 그대로 옮겼습니다.

새 하네스 Pogl Agent는 루프 하나로 돕니다

새 하네스의 이름은 Pogl Agent입니다. 상담 · 기획 · 만들기 · 고치기 · 오류 고치기 · 외부 AI 도구의 요청이 모두 같은 루프로 들어옵니다. 루프는 모델에게 묻고, 모델이 고른 도구를 실행하고, 그 결과를 기록하는 일을 반복합니다. 핵심 루프는 715줄입니다.

바뀐 것은 다섯 가지입니다.

• 도구는 13개이고 한 곳에 등록합니다. 파일 읽기, 고치기, 브라우저로 직접 눌러 보기, 그림과 소리 만들기, 이전 버전 보기 같은 도구가 한 목록에 있습니다. 고치기 도구는 바꿀 자리가 정확히 한 곳일 때만 고칩니다. 도구 설명은 모두 합쳐 3천 토큰 안으로 줄였고, 목소리 목록처럼 긴 자료는 필요할 때 읽는 문서로 뺐습니다.
• 계약 문서는 하나의 생성기가 만듭니다. 혼자 하는 게임인지, 여럿이 하는 게임인지, 2D인지 3D인지를 보고 AI에게 줄 문서를 그때 만듭니다.
• 대화 기록은 경험마다 하나입니다. 상담에서 오래 이야기한 뒤 고치기를 보내도 앞에서 정한 내용이 같은 기록 안에 남아 있습니다. 작업이 도는 중에 보낸 말도 같은 기록에 들어갑니다.
• 걸음마다 기록을 한 줄씩 남깁니다. 워커가 다시 시작되면 이 기록으로 대화를 다시 세워 이어서 진행합니다. 처음부터 다시 돌리지 않습니다.
• 모델은 루프가 직접 부릅니다. 중간 서버를 거치지 않고, 어느 모델을 쓸지와 장애 때 다른 공급자로 넘기는 규칙도 루프 안 한 곳에 있습니다.

가상 컴퓨터 안에 OpenCode 서버를 설치하는 단계도 없어졌습니다. 가상 컴퓨터는 게임을 띄우고 확인하는 데만 씁니다.

가장 무거운 작업이 줄었습니다

매 요청 앞에 붙는 고정 부분은 1만 4천 토큰에서 6천 토큰 안으로 줄였습니다. 목소리 목록처럼 가끔만 필요한 자료는 문서로 빼고, 필요할 때만 읽게 했습니다.

11월 11일 0시 59분부터 같은 시간대에 반영된 고치기를 비교했습니다. 한 판에서 모델이 캐시 없이 새로 읽은 입력은 평균 19만 5천 토큰에서 6만 9천 토큰으로, 모델이 쓴 출력은 평균 2만 1천 토큰에서 1만 토큰으로 줄었습니다.

이 차이는 대부분 이전 하네스의 아주 큰 작업에서 났습니다. 이전에는 작업 몇 건이 수십만 토큰을 새로 읽고 40분 넘게 돌았고, 새 하네스에서는 그런 작업이 없었습니다. 보통 크기의 작업만 보면 새 하네스가 새로 읽는 입력은 적었지만, 캐시에서 다시 읽은 양과 출력은 더 많았고 시간도 더 걸렸습니다.

같은 요청으로 다시 돌려 봤습니다

11월 10일, 실제 경험의 사본 60개에 예전에 들어온 고치기 요청을 그대로 다시 보냈습니다. 그리고 두 하네스의 결과를 같은 판정기로 다시 채점했습니다. 두 하네스의 판정 기준이 달라서, 각자 낸 판정을 그대로 비교할 수는 없었기 때문입니다. 판정까지 끝난 54쌍을 비교했습니다.

전체 비율은 비슷했습니다. 요청 단위로 보면 차이가 있었습니다. 이전 하네스가 «안 됨»이나 «확인 필요»로 남긴 항목을 새 하네스가 모두 해결한 요청이 8개였고, 반대인 요청이 5개였습니다.

달라진 것은 결과를 알리는 방식이었습니다. 제작자 문의로 들어온 고치기 하나를 같은 요청으로 다시 돌렸습니다. 이전 하네스는 고치지 못한 항목에 «됨»을 표시하고 크레딧을 차감했던 작업입니다. 새 하네스는 이전 버전 기록을 열어 원인이 된 버전을 찾았고, 되돌릴 방법이 없다고 판단해 «안 됨»으로 적은 뒤 크레딧을 모두 돌려줬습니다.

사용자 절반에게 적용했습니다

11월 11일 0시 59분, 사용자 절반에게 Pogl Agent를 적용했습니다. 한 사람이 상담과 고치기에서 서로 다른 하네스를 만나지 않도록, 사람 단위로 나눴습니다. 문제가 생기면 설정값 하나로 1분 안에 모두 Pogl Builder로 돌아갑니다.

처음 2시간 동안 고치기 20건 중 17건이 반영됐습니다. 1건은 AI가 고치지 못했다고 판단해 크레딧을 돌려줬고, 1건은 바꿀 것이 없었고, 1건은 사용자가 중단했습니다. 실패로 끝난 작업은 없었습니다. 상담은 44건이 정상적으로 처리됐습니다.

걸린 시간은 분포가 달랐습니다.

이전 하네스는 절반이 6분 안에 끝났지만 25분, 27분, 42분, 53분이 걸린 작업도 있었습니다. 새 하네스는 모든 작업이 7~31분 사이에 끝났습니다. 작은 요청도 7분 넘게 걸리는 것은 AI가 확인을 너무 자주 돌린 탓이어서, 11일 새벽 확인 횟수를 줄이도록 고치고 효과를 재고 있습니다.

고칠 곳이 한 곳이 됐습니다

이번 작업에서 가장 크게 바뀐 것은 고칠 곳의 수입니다. 이전에는 같은 문제를 길마다 따로 고쳐야 했지만, 지금은 루프와 도구, 계약, 판정이 한 곳에 있습니다. 비교 시험과 절반 적용에서 찾은 문제도 대부분 그날 안에 한 곳을 고쳐 해결했습니다.

나머지 절반에도 차례로 적용한 뒤, Pogl Builder와 OpenCode 코드를 지울 예정입니다.