서브에이전트에 '기억'을 붙인 런타임

코덱스(Codex)와 클로드(Claude)로 서브에이전트를 여러 개 돌려 본 사람이라면 같은 벽에 부딪힌다. 부모 에이전트가 자식을 띄워 놓고 끝났는지를 반복해 묻고, 누가 무슨 일을 맡았는지는 대화 기록을 되짚어 복원하며, 터미널이 닫히거나 공급자 세션이 끊기면 유일한 작업 기록까지 함께 사라진다. 깃허브에 공개된 오픈소스 오 마이 서브에이전트(Oh My Subagents)는 이 조율 과정을 채팅이 아니라 런타임 상태로 옮긴 로컬 실행기다.

무슨 일인가 / 배경

링로키드(ringlochid)라는 계정이 올린 이 프로젝트는 MIT 라이선스로 공개됐고, 확인 시점 기준 별 96개·포크 7개·커밋 142건 규모의 초기 단계 도구다. 소개 문구는 간명하다. 즉흥적으로 띄우던 서브에이전트를 책임 소재가 분명한 AI 팀으로 바꾼다는 것.

문제의식은 구체적이다. 지금의 위임 방식은 시작은 쉽지만 운영이 어렵다. 작업마다 역할과 프롬프트를 새로 쓰고, 자식이 끝났는지 계속 확인해야 하며, 공급자 쪽에서 응답이 돌아왔다는 사실만으로 성공 처리해 버린다. 거대한 결과물을 대화창으로 그대로 흘려보내다 맥락이 넘치는 것도 흔한 일이다. 문제는 모델의 성능이 아니라, 위임 상태를 담아 둘 저장소가 없다는 데 있다.

핵심 짚어보기

구조는 세 개의 개념으로 돌아간다. 관리자 격 에이전트가 한 묶음의 일을 웨이브(Wave) 단위로 위임하면, 자식에게 배정된 작업과 부모의 대기 상태가 하나의 기록으로 함께 확정된다. 자식들은 각자 독립적으로 종료 체크포인트(Checkpoint)를 남기고, 컨트롤러가 완성된 웨이브를 모아 부모를 이어서 재개시킨다. 부모는 폴링 루프에 갇혀 있지 않으며, 중간에 끊겨도 확정된 기록에서 다시 이어진다.

성공 판정 기준도 바뀐다. 공급자가 응답을 돌려줬다는 사실이 아니라, 작업 책임자가 완료 또는 차단 중 하나로 명시한 결과만 인정한다. 결과 전달은 짧은 체크포인트와 작업 폴더의 실제 파일 경로를 주고받는 방식이라 대화창 부담이 작다. 워크플로 정의는 누가 무엇을 책임지는지만 규정하고 실행 순서를 못 박지 않는다. 순차로 갈지 병렬로 펼칠지, 구현·검수·수리를 반복할지는 실행 시점의 증거를 보고 관리자가 고른다. 관리자는 재귀적으로 다시 위임할 수 있고, 계층이 깊어져도 전체를 감시하는 숨은 루프는 필요 없다.

1인기업 실전 적용 포인트

• 에이전트를 여러 개 굴리는 작업이라면 역할 트리부터 파일로 고정하라. 매번 프롬프트를 새로 쓰는 대신 구현·검수·수리처럼 이름 붙은 책임을 재사용하면 결과 편차가 눈에 띄게 줄어든다.
• 자식 작업의 산출물은 대화가 아니라 파일 경로로 넘기는 규칙을 세워라. 요약 한 단락에 경로 한 줄이면 같은 정보를 넘기면서 컨텍스트 소모는 수십분의 일로 떨어진다.
• 완료 판정 문장을 미리 정하라. 테스트 통과 로그 또는 차단 사유 중 하나를 반드시 남기게 하면, 응답만 돌아오고 실제로는 아무것도 끝나지 않은 상태를 걸러낼 수 있다.
• 밤새 도는 자동화에는 재시작 지점을 반드시 두라. 절전이나 세션 만료로 끊겼을 때 처음부터 다시 도는 파이프라인은 시간과 비용을 두 번 태운다.

전망 / 주의점

커밋 142건, 별 100개 안팎의 신생 프로젝트다. 실서비스에 바로 얹기보다 설계 아이디어를 먼저 빌려 오는 쪽이 현실적이다. 그럼에도 겨냥한 지점은 정확하다 — 에이전트 수를 늘리는 일보다 어렵고 중요한 것은 끊긴 다음을 설계하는 일이다. 로컬 실행기라 상태가 내 기기에만 남는다는 점은 장점이자 제약이다. 팀 단위 공유나 원격 실행이 필요하다면 기록 저장소를 따로 설계해야 한다.

출처: GitHub (https://github.com/ringlochid/oh-my-subagents)