에이전트를 하루 동안 풀어 놓으려면 — 장기실행 코딩 에이전트 운영 인프라

어떤 문제인가

코딩 에이전트를 쓰는 방식은 오랫동안 짧은 왕복이었다. 함수 고쳐 줘, 테스트 봐 줘, 몇 분 단위로 사람이 키를 잡았다 놓았다. 그런데 OpenAI Codex가 빈 저장소에 디자인 툴을 처음부터 짜는 실험에서 약 25시간을 사람 개입 없이 돌았다. 1,300만 토큰을 태우고 3만 줄을 만들었다. 이제 에이전트를 분 단위가 아니라 시간·하루 단위로 풀어 놓는 게 가능해졌다. 문제는 그렇게 오래 풀어 놓는 순간 짧은 작업에서는 보이지 않던 것들이 한꺼번에 터진다는 데 있다. 컨텍스트 윈도가 몇 번씩 가득 차며 압축되고, 그 과정에서 에이전트가 초기 명세에서 슬금슬금 표류한다. 토큰 비용은 통제 장치 없이 선형으로 쌓이는데, 한 실무자는 장기실행 모드가 “터무니없는 양의 토큰을 소비한다”고 경고한다. 5시간 한도 요금제는 큰 작업을 끝내기도 전에 만료된다. 무엇보다, 새벽 3시에 돌던 25시간짜리 런이 조용히 무너져도 아침까지 아무도 모른다. 에이전트를 띄울 수는 있는데, 그게 제대로 돌고 있는지 들여다보고, 비용이 새면 멈추고, 표류하면 잡아채고, 막히면 사람을 부르는 — 그 운영 계층이 통째로 비어 있다.

왜 지금인가

장기실행이 실험실 데모가 아니라 실제 워크플로로 넘어오는 신호가 동시에 여럿 떴다. OpenAI는 GPT-5.1-Codex-Max에서 컴팩션을 내놨다. 컨텍스트 한계에 가까워지면 히스토리를 가지치기하되 핵심 상태는 보존한 새 윈도를 만들어 실행을 이어 가는 방식이고, 내부 평가에서는 24시간 넘게 단일 작업을 혼자 돌렸다고 보고한다. Codex CLI는 v0.128.0+에서 /goal 명령을 추가해, 중단·세션 단절·토큰 한계를 넘어 살아남는 지속 목표를 다룬다. 한 번에 한 지시가 아니라, 검증 가능한 종료 조건을 가진 목표를 주고 에이전트가 여러 턴에 걸쳐 추구하게 한다. 모델 쪽 효율도 따라왔다. 같은 추론 강도에서 사고 토큰을 30% 적게 쓰면서 더 높은 정확도를 낸다는 보고는, 하루짜리 자율을 경제적으로 가능하게 만드는 조건이다. 즉 모델과 런타임은 이미 장기실행 쪽으로 빠르게 움직이고 있다. 그런데 정작 그 위에서 여러 런을 동시에 관제하고, 비용과 표류를 실시간으로 보고, 막힌 지점에서 사람을 호출하는 계기판은 각 팀이 마크다운 파일과 셸 스크립트로 매번 손수 짜고 있다. 표준화된 운영 도구가 없는, 전형적인 공백이다.

어떻게 만들 수 있나

진입로는 크게 셋이다. 하나, 체크포인트·복구 계층. 25시간 실험에서 에이전트를 길들인 건 저장소에 박힌 명세·계획·상태 마크다운 파일이었다. 이 외부화된 상태 패턴을 손수 짜는 파일에서 제품으로 끌어올린다. 런을 스냅샷으로 떠 두고, 무너지면 마지막 검증 통과 지점에서 되살리고, 어떤 결정으로 어디까지 갔는지 감사 추적을 자동으로 남긴다. 둘, 표류·비용 관제 대시보드. 여러 에이전트 런을 한 화면에서 본다. 지금 어떤 마일스톤에 있고, 토큰을 얼마나 태웠고, 명세에서 얼마나 벗어났고(예: 바꾸지 말라던 파일을 건드렸나), 어디서 검증이 깨졌는지. 예산 한도를 걸어 새벽에 토큰이 폭주하면 자동으로 멈춘다. 셋, 사람-개입 지점 설계. 에이전트가 판단이 갈리는 지점에서 멈춰 사람을 부르고, 답을 받으면 그 자리에서 다시 이어 가는 흐름이다. 검증 가능한 종료 조건과 “바꾸지 말 것” 제약을 한곳에서 관리하는 정책 계층이 여기 붙는다. 수익은 팀 단위 구독으로 건다 — 동시 런 수, 보존된 체크포인트 용량, 관제하는 에이전트 대수. 처음부터 모든 모델·런타임을 노리지 말고, Codex /goal처럼 장기실행을 먼저 미는 한 런타임에 깊이 붙어 그 생태계의 관제탑이 되는 게 현실적이다.

flowchart LR
  A[장기실행 에이전트] -->|진행 상태| B[체크포인트 계층]
  A -->|토큰·표류 지표| C[관제 대시보드]
  C -->|예산 초과| D[자동 중단]
  C -->|판단 필요| E[사람 개입]
  E -->|답변| A
  B -->|무너지면 복구| A

성공 조건

이 시장은 ‘얼마나 빨리 신뢰를 주느냐’에서 갈린다. 첫째, 운영 계층 자체가 에이전트보다 더 안정적이어야 한다. 관제탑이 흔들리면 그 아래 모든 런이 같이 흔들린다. 체크포인트 복구가 한 번이라도 어긋나 멀쩡한 작업을 날리면 도입처는 바로 등을 돌린다. 둘째, 비용 가드레일은 사후 청구서가 아니라 실시간 차단이어야 한다. “어제 토큰을 이만큼 썼습니다”는 이미 늦었고, 한도를 넘기 직전에 멈추는 게 가치다. 셋째, 표류 감지는 데이터 락인의 핵심이다. 어떤 신호가 진짜 표류로 이어지는지(어떤 파일 수정, 어떤 검증 실패 패턴)는 런이 쌓일수록 정확해지고, 그게 후발 주자가 못 따라오는 격차가 된다. 처음부터 모든 런타임을 받치려다 어느 것도 깊이 못 붙는 게 가장 흔한 실패다.