대규모 언어 모델 하나에 긴 프롬프트를 쏟아붓는 대신, 여러 개의 작은 모델을 역할별로 나눠 협업시키는 접근이 코딩 자동화 쪽에서 다시 주목받고 있다. Memdoor는 하나의 CLI 바이너리로 동작하는 경량 코딩·자동화 에이전트로, 로컬이나 SSH 환경에서 실행하고 토큰 사용을 줄이며 CI와 크론 작업을 지속적 워크플로로 묶어 자동화하는 것을 지향한다. 이번에 공개된 team-solve 예제는 그 Memdoor 워크플로 형식으로 작성된 프로그래밍 문제 해결 하네스로, 알고리즘 난제를 여러 에이전트가 분담해 푸는 구조를 보여준다.
역할을 나누고 디스크로만 대화한다
이 하네스는 플래너, 두 명의 아이디어 담당(ideator), 솔버, 매니저라는 다섯 역할과 별도의 수선(repair) 워커로 구성된다. 핵심은 각 역할이 매번 비어 있는 컨텍스트에서 시작하고, 서로 대화 로그가 아니라 디스크 위의 파일을 통해서만 소통한다는 점이다. 모든 에이전트 프롬프트에는 "새 컨텍스트에서 시작하고, 파일을 읽고, 채팅에 의존하지 말라"는 지시가 들어 있다. 성공 여부를 판단하는 것도 모델이 아니라 샘플 테스트를 실행하는 셸 스크립트다. 판정 주체를 모델에서 결정론적 스크립트로 옮긴 설계가 이 방식의 성격을 가장 잘 드러낸다.
이 구조는 Lee(2026)의 GVS5H 방법에서 왔다. Qwen3.8-27B 모델 다섯 개를 묶으면 LiveCodeBench Hard에서 Fable 5에 필적한다는 연구다. 흥미로운 점은 이 예제의 워크플로 파일들을 사람이 손으로 짠 것이 아니라, 2026년 10월 25일 방법 설명만 보고 코더가 직접 작성했다는 사실이다.
재현 결과와 조건
저자들의 프롬프트를 그대로 Qwen3.8-27B에 적용해 돌린 이 루프는 LiveCodeBench Hard의 앞 열 문제를 다섯 번 통과시킨 평균 점수가 10점 만점에 9.8이었다. 저자들 자신의 하네스를 같은 모델로 재현한 결과는 9.6, Fable 5 단독 호출은 8.0이었다. 재현은 128K 응답 상한, 최대 10라운드, plan 0.3·ideation 0.4·manager와 worker 0.2의 온도, top_p 0.95, top_k 20 같은 설정까지 저자들과 동일하게 맞췄고, 공개·히든 테스트 전부를 보정된 채점기로 평가했다. 루프는 공개 샘플만 보고 점수는 히든 테스트에서 나온다. 50개 실행 중 49개가 풀렸고, 전체 비용은 15.3M 출력 토큰에 35.79달러, 중간에 시계에 걸려 잘리거나 멈춘 16개 시도까지 더하면 38.77달러였다. 한 번 실행에 모델 시간 중앙값 40분(최장 4시간)과 0.39달러가 들었다.
재현 과정에서 저자들과 다른 부분은 추론을 돌린 호스트였다. 저자들은 FP8 정밀도의 자체 vLLM을 썼지만, 이쪽은 OpenRouter를 통해 Modal, CoreWeave, Parasail, Wafer 순으로 호출하다가 Modal이 초당 14토큰까지 느려지자 FP8 호스트들로 전환했다. 메시지 단위 패리티는 저자들의 구현과 바이트 단위까지 일치하도록 lib/test_parity.py로 검증했다. 가장 까다로웠던 부분은 문제 지문 자체였다. 초기 버전은 문제마다 자체 작업 파일을 만들었는데, 27B 모델은 LiveCodeBench 원문보다 그 변형본에서 더 나쁜 계획을 세웠다. 결국 저자들의 하네스와 똑같은 질문을 던지도록 Memdoor에 네 가지 변경을 가해야 했다.
실무자가 가져갈 것과 남는 한계
실무 관점에서 눈여겨볼 지점은 두 가지다. 하나는 컨텍스트를 길게 끌고 가는 대신 매번 초기화하고 파일이라는 공유 장부로만 소통하게 하는 '장부 규율'이다. 저자 논문은 이 규율을 성능 향상의 공으로 돌린다. 다른 하나는 정답 판정을 셸 스크립트에 맡겨 모델의 자기 판단을 배제한 점으로, 수선 라운드는 한 번뿐이고 사람이 개입하는 게이트는 없다. 각 단계는 steps/ 폴더의 YAML 파일 하나이며 requires 항목이 실행 순서를 정하는 DAG가 된다. 역할을 바꾸려면 해당 프롬프트만 고치면 된다. 자신의 문제에 적용하려면 task.md를 교체하고 tests/N.in과 tests/N.out 쌍을 놓으면 되며, 프로그램은 표준입력을 읽는 solution.py로 샘플과 diff로 비교된다. Python 3와 bash만 있으면 되고, 단계들은 특정 모델을 명시하지 않아 /model에 고정된 모델이 응답한다.
다만 한계도 분명하다. 이 결과는 저자들의 100문제가 아니라 열 문제를 다섯 번씩 돌린 수치다. 대상 콘테스트가 2025년 3월 29일부터 4월 6일 사이여서 모델이 학습 과정에서 문제를 봤을 가능성, 즉 오염을 배제할 수 없다. Fable 5 열은 저자들 파일에서 문제당 단일 호출을 가져온 것으로 이 하네스에서 직접 돌린 값이 아니다. 루프가 두 번 놓친 지점은 저자들 루프의 같은 두 결함에서 비롯됐는데, 매니저의 반례를 작은 입력에 대한 완전 탐색으로 검증하고 샘플을 통과한 마지막 프로그램을 보존하는 식으로 방법 자체를 바꾸지 않고도 고칠 수 있다고 한다. 두 보완책은 위 수치에는 반영돼 있지 않다. 작은 모델 여러 개를 규율 있게 엮으면 큰 모델 하나에 근접할 수 있다는 가능성과, 그 수치를 곧바로 일반화해 받아들이기 어렵다는 조심스러움을 함께 보여주는 사례다.