자동으로 돌리기 전에 할 일부터 정했습니다

9월 6일 16시 43분, 오토파일럿의 순서를 바꿨습니다. 어떤 작업을 할지 미리 정하고 시작하자는 요청이었습니다. 작업이 돌아간다는 사실보다 무엇을 하고 있는지 알 수 있어야 했습니다.

제 작업 환경에는 컴퓨터가 세 대 있습니다. 아테나, 헤르메스, 볼칸이라고 부릅니다. 각 컴퓨터에서 쓸 수 있는 에이전트도 여럿입니다. 창이 늘어날수록 어느 창이 지시를 정하고, 어느 창이 배정된 일을 하는지 구분해야 했습니다.

이번에는 헤르메스의 Codex를 총괄로 정했습니다. 아테나와 볼칸의 Codex 두 개, 세 컴퓨터의 Cursor 세 개는 워커로 뒀습니다. 총괄 하나와 사용할 수 있는 워커 다섯 개입니다.

역할을 먼저 정했습니다

워커가 다섯 개 있다고 매번 다섯 작업을 동시에 돌릴 필요는 없었습니다. 같은 컴퓨터의 에이전트는 메모리와 CPU를 함께 씁니다. 서로 다른 창에서 같은 저장소 파일을 고치면 충돌도 납니다.

그래서 역할을 이름에만 붙이지 않았습니다. 총괄은 목표를 정리하고 일을 나눠 맡기고, 결과를 확인해 합칩니다. 워커는 받은 범위 안에서 구현과 검증을 진행합니다. 추가로 일을 쪼개거나 다른 워커에게 다시 넘기는 판단은 총괄에서 합니다.

컴퓨터 이름과 실행 프로그램도 구분했습니다. 헤르메스에서 돌아가는 Cursor가 있다는 이유로 그 Cursor까지 총괄이 되는 것은 아닙니다. 같은 기기 안에서도 맡은 역할은 달랐습니다.

정한 순서는 네 단계입니다.

이미 구체적인 작업을 정하고 시작하라고 했으면 다시 묻지 않도록 했습니다. 반대로 시간만 정해 주었다고 해서 아무 일이나 꺼내 계속하는 방식으로 해석하지 않도록 했습니다.

작업 도중 필요한 세부 구현은 맡깁니다. 하지만 다른 제품을 고치거나 새로운 목표를 더하는 일은 목록 밖입니다. 실행 과정의 판단과 목표를 늘리는 판단을 구분한 것입니다.

이 원칙과 배정 경로를 세 컴퓨터에 반영했습니다. 한 번 설명하고 기억해 주기를 기대하는 대신, 다음 작업을 받을 때 읽을 수 있는 안내에 남겼습니다.

저녁에는 중간보고 마지막에 진행률을 적기로 했습니다. 시간이 절반 흘렀다는 이유로 50%라고 부르면 쓸모가 없습니다. 어떤 결과물이 나왔고 무엇을 검증했는지를 기준으로 추정해야 했습니다.

예를 들어 수정안이 PR에 올라와도 공개 사이트 배포가 남아 있을 수 있습니다. 앱 빌드가 끝나도 스토어 심사는 남습니다. 워커가 맡은 구현을 마친 시점과 전체 요청이 끝나는 시점이 다릅니다.

전체 진행률 하나만 보기보다 구현, 검증, 반영 상태를 함께 적는 편이 다음 행동을 고르기 쉬웠습니다. 숫자를 정교하게 보이게 만드는 것보다 그 숫자가 무엇을 세는지 설명하는 일이 먼저였습니다.

같은 날 Cursor에는 대기 중 컨텍스트 사용량이 기준을 넘으면 새 대화를 여는 가드가 적용됐습니다. 컨텍스트는 모델이 현재 대화에서 참고하는 기록의 범위입니다.

그런데 대화를 비우는 기능이 있다고 작업 재개도 완성된 것은 아니었습니다. 다음 세션이 무엇을 승인받았고 어디까지 끝냈는지 다시 읽을 수 있어야 합니다. 이번에 확인한 가드는 자동 초기화까지였고, 승인된 작업을 다시 넣어 이어가는 연결은 후속으로 남았습니다.

이 부분을 구현된 것처럼 보고하지 않는 것도 운영 규칙의 일부였습니다. 계획서에 적힌 기능과 실제로 실행되는 기능은 대조해야 했습니다.

에이전트를 여러 개 쓰면서 먼저 정리할 것은 창의 개수보다 책임이었습니다. 누가 목표를 정하고, 누가 결과를 합치고, 어떤 상태를 완료라고 부를지 말입니다.

오토파일럿의 시작점도 분명해졌습니다. 할 일을 정하고 나면 세부 실행을 맡길 수 있습니다. 무엇을 할지 모르는 상태로 돌아가는 시간을 늘릴 이유는 없었습니다.

다음 과제는 승인된 목록과 완료 기록을 다음 세션까지 이어 주는 일입니다. 새 대화를 열더라도 같은 작업의 다음 줄에서 시작할 수 있도록요.

— 강대종 / @ssamssae