장시간 실행 에이전트가 왜 작동하는지, 어디서 한계에 부딪히는지, 그리고 더 나은 워크플로를 어떻게 설계할 수 있는지에 대한 실전 관찰과 제안.
지난 몇 달 동안, 저는 다음을 포함한 여러 사이드 퀘스트에서 장시간 실행 에이전트를 실험해 왔습니다.
.
저는 "장시간 실행 에이전트"가 작동하는 이유가 문자 그대로 더 많은 토큰을 쓰기 때문이라는 것을 알게 되었습니다... 또는 연구자라면, 이들이 "테스트 시점 계산량을 스케일링한다"고 말하겠죠.
이 말은 어리석게 들릴 수 있지만, 실제로 효과가 있습니다. 예를 들어 BrowseComp 벤치마크에서는 Sonnet 4.6이 10배 더 많은 토큰을 사용했을 때 점수가 약 10퍼센트포인트 더 높아졌습니다.
45페이지 -
하지만 작업이 에이전트의 컨텍스트 윈도우가 감당할 수 있는 것보다 훨씬 더 많은 문맥을 요구하기 시작하면, 이런 방식은 무너지기 시작합니다...
이 문제를 해결하기 위해, 올해 초 우리는 ralph wiggum loop 같은 것들의 등장을 보았습니다. 원래 형태에서 이것은 같은 프롬프트를 반복문으로 계속 실행하는 것에 불과합니다.
지난주 Codex 팀은 goals를 출시했습니다. 이는 원하는 목표를 달성하기 위해 며칠 동안 실행될 수 있는 장시간 실행 에이전트를 위한 내장 시스템입니다.
Felipe Coury 
@fcoury
/goal도 Codex CLI 0.128.0에 추가되었습니다. Ralph loop에 대한 우리의 접근은 목표를 턴 간에 살아 있게 유지하는 것입니다. 달성될 때까지 멈추지 않습니다. 제 동료이자 OpenAI 멘토인 Eric Traut, 일명 Pyright guy가 만들었습니다. 제가 매일 함께 일할 수 있는 최고의 인물 중 한 명입니다.
저는 이 소식에 정말 신이 났지만, GPT 5.5를 아주 좋아함에도 불구하고 실제 결과는 꽤 실망스러웠습니다!
Codex는 완전한 오픈소스이기 때문에 내부에서 정확히 어떻게 작동하는지 확인할 수 있습니다. 저는 실제로 그렇게 해봤고, 그 결과 무엇을 배웠는지, 그리고 왜 제 장시간 실행 에이전트 워크플로가 더 낫다고 생각하는지 여기서 설명하겠습니다.
아직 시도해 보지 않았다면, goal은 Codex CLI에 "/goal <your goal>"를 입력해 몇 시간 혹은 며칠 동안 실행함으로써 더 야심찬 작업을 원샷으로 해결하려고 시도합니다.
내부적으로 goals 기능은 단순한 SQLite 구성을 사용합니다. Codex는 새 목표를 만들 때마다 한 행으로 저장하기 위해 "thread_goals" 테이블을 생성하고, 각 행에는 목표의 objective, id, status, 그리고 선택적인 token budget이 들어 있습니다.
Codex가 목표 달성을 위해 작업을 시작하면, 진행 상황을 반영하고 데이터베이스 안의 목표 상태를 갱신하기 위해 "get_goal and "update_goal" 같은 새 도구를 사용합니다.
그 다음 Codex는 아래 프롬프트를 사용해 꽤 표준적인 ralph loop를 사용합니다. 즉, 같은 내용을 반복해서 프롬프트하는 방식입니다.
plaintext
Continue working toward the active thread goal.
<untrusted_objective>
Ship the benchmark article with real Goal-mode evidence.
</untrusted_objective>
Budget:
- Time spent pursuing goal: XX seconds
- Tokens used: XX
- Token budget: XX
- Tokens remaining: XX
Before deciding that the goal is achieved, perform a completion audit against the actual current state.
이 방식은 Codex가 15분 후마다 계속 진행해도 되는지 물어보며 멈추는 짜증 나는 문제를 해결해 줍니다 🥺👉👈. 하지만 저는 이것이 에이전트를 장시간 실행시키는 효과적인 방법이라고는 생각하지 않습니다.
저는 장시간 실행 에이전트라는 아이디어를 정말 좋아합니다. 이것은 우리가 에이전트에게 실제로 "1M MRR B2B SaaS를 만들고, 실수는 전혀 하지 마라"라고 시킬 수 있는 목표에 가장 현실적으로 가까운 개념입니다.
하지만 지금까지 Codex의 /goal 기능을 사용해 본 경험은 꽤 실망스러웠고, 제가 직접 수많은 실패한 장시간 실행 에이전트 워크플로를 만들며 발견한 것과 같은 결함을 가지고 있습니다.
제가 그렇게 느끼는 이유는 크게 세 가지입니다.
모호성은 누적된다
멀티 에이전트가 압도한다
컨텍스트 간 메모리는 작동한다
저는 지난 몇 달 동안 이런 교훈을 배웠고, 아래에서 그 세부 내용과 함께 제가 실제로 마음에 들어 하게 된 워크플로를 공유하겠습니다.
LLM을 반복문 안에서 실행한다는 것은 각 반복의 출력이 다음 반복의 입력이 된다는 뜻이며, 이는 이후 반복마다 누적 효과를 만듭니다.
모델에게 어떤 것을 처음부터 끝까지 만들라고 하면 수없이 많은 결정을 내리게 되는데, 어느 시점이 되면 대개 당신이라면 하지 않았을 결정을 하게 됩니다. 그리고 그 이후의 모든 작업은 방향 자체가 어긋나 있을 수 있습니다.
이것은 현실과도 다르지 않습니다. 누군가에게 모호한 요구사항으로 무언가를 만들라고 하면, 충분한 상호 대화의 기회가 없을 때 당신이 머릿속에 그렸던 결과물을 받지 못할 가능성이 큽니다.
AI는 아직 취향을 가지고 있지 않은 듯하기 때문에, 가능한 한 오류의 여지를 없애는 아주 상세한 프롬프트를 작성하지 않는 한 이런 일을 피하기는 매우 어렵습니다.
제 장시간 실행 에이전트 전략에서는 이런 "/interview" 스킬의 변형을 사용해 모호성을 최대한 낮춥니다. 이는 다음과 매우 유사합니다.
.
Jarrod Watts
@jarrodwatts
저는 bulletproof specs를 만들기 위해 /interview라는 커스텀 Claude Code 명령어를 만들었습니다. • plan mode로 계획 수립 • /interview 명령 실행 • Claude가 20~50개의 명확화 질문 제시 • 당신의 답변에 따라 계획 파일 업데이트 모호성을 제거하는 데 아주 좋습니다!
저는 에이전트가 어떤 코드도 실행하기 전에 이 작업을 "setup phase"에서 수행합니다. 즉, 자율 에이전트 루프가 시작되기 전에 사용자 상호작용이 실제로 일어나는 단계에 처음부터 큰 투자를 합니다.
이 상당히 엄격한 과정을 거치고 나면, 이제 실제로 꽤 구체적이고 상세해진 목표를 개별 작업으로 이루어진 마일스톤으로 분해합니다.
"setup phase" 프롬프트 일부"
제 경험상 이 단계는 매우, 매우, 매우 중요합니다. 이 단계는 "여기서 내가 정확히 무엇을 원하는가?"를 에이전트만이 아니라 바로 당신 자신이 생각하도록 강제합니다.
거의 매번 이 단계를 실행할 때마다, Codex는 제가 전혀 고려하지 않았지만 놀라울 정도로 중요해서 미리 생각하고 결정해야 하는 질문과 가정을 제기합니다.
왜 이것이 유용한지를 저는 가능한 결과들의 트리로 시각화합니다. 각 가지는 최종 결과에 도달하기 위해 내려야 하는 하나의 결정입니다.
사전 명확화가 전혀 없으면, 이런 결정은 에이전트가 대신 내리게 되며, 그 결과 거의 무한한 가능성 중 하나만 얻게 됩니다. 그것은 당신이 요청한 것과 어느 정도 비슷해 보일 수는 있어도 아주 느슨하게 닮아 있을 뿐입니다.
반면에, 시작 전에 더 많은 시간을 들이면 장시간 실행 에이전트 프로세스가 시작되기 전에 당신이 구상하는 것과 멀리 떨어진 가지들을 잘라내며 방향을 수정할 기회를 얻게 됩니다.
연구와 제 개인적인 경험은 또한 orchestrator <> subagent 관계로 여러 에이전트를 사용하는 것이, 단순히 좋은 단일 에이전트 하나를 사용하는 것보다 훨씬 낫다는 점을 보여줍니다.
39페이지 -
물론 이것은 훨씬 더 많은 토큰을 태웁니다. 하지만 그것이 당신에게 문제가 아니라면 결과를 개선해 줍니다.
사실상 이것은 토큰 소비를 스케일링하는 "수평적" 방법일 뿐입니다. 즉, 똑똑한 개별 에이전트 하나가 더 많은 토큰을 써서 생각하게 하는 대신, 여러 똑똑한 에이전트가 함께 더 많은 시간을 들여 생각하게 하는 것입니다.
저는 이를 설명하기 위해 Patrick Star를 사용한 이 다이어그램을 만들었습니다.
아쉽게도, 스폰서받은 것은 아닙니다
제 장시간 실행 에이전트 워크플로에서 이것을 구현하는 방식은, 메인 장시간 실행 에이전트가 orchestrator 역할을 하며 각 개별 작업마다 subagent 팀을 자유롭게 만들 수 있게 하는 것입니다.
이 작은 팀들은 함께 일하면서 개별 에이전트 하나로는 내기 어려운 더 높은 품질의 결과를 만들어 냅니다. 보통 저는 한 에이전트는 구현 담당으로, 다른 하나는 리뷰어 역할로 둡니다.
이 방식은 에이전트가 자신에게 주어진 작업을 구현하고, 그 작업을 reviewer subagent에게 넘기면서 작동합니다. 이 작업은 계획 단계에서 달성 가능한 작은 작업 조각들로 이미 분해되어 있습니다.
리뷰어는, 말 그대로... 그것을 리뷰합니다. 그리고 이 두 에이전트는 코드 품질에 둘 다 만족할 때까지 수정과 개선을 주고받습니다. 그 시점이 되면 메인 orchestrator에게 작업이 완료되었다고 보고합니다.
Boris(Claude Code의 제작자)는 이를 여기서 우아하게 표현합니다.
Boris Cherny
@bcherny
Replying to
대략적으로 말해, 코딩 문제에 더 많은 토큰을 던질수록 결과는 더 좋아집니다. 우리는 이것을 test time compute라고 부릅니다. 결과를 더 좋게 만드는 한 가지 방법은 별도의 컨텍스트 윈도우를 사용하는 것입니다. 이것이 subagents가 작동하는 이유이며, 또한 한 에이전트는 버그를 만들고 다른 하나는
저는 이것이 매우 유익하다고 느꼈습니다. 에이전트가 이전 편향 없이 새로운 관점에서 사물을 볼 수 있게 해주기 때문입니다. 예를 들어 리뷰 에이전트는 이 코드를 처음 보는 것이기 때문에 더 객관적이고 편향 없는 리뷰를 할 수 있습니다.
이 점은 중요합니다. 에이전트, 특히 Claude는 컨텍스트 윈도우가 어수선해지면 명백히 틀린 것조차 사실이라고 스스로 착각하는 경우가 자주 있기 때문입니다.
저는 원래 이것을 위해
을 만들었습니다. 즉, Codex가 Claude의 작업을 리뷰하게 하려는 목적이었습니다. 하지만 GPT 5.5 이후로는 프런트엔드 인터페이스 설계가 아닌 모든 것에 GPT 5.5를 xHigh로 강하게 사용합니다. 그 용도에는 Claude Design을 사용합니다.
컨텍스트 윈도우를 넘어 기억을 저장할 장소를 에이전트에게 주고, 새로운 컨텍스트 윈도우가 시작될 때마다 그것을 읽도록 강제하는 것은, 에이전트에게도 사람에게도 현재 어디까지 왔는지 이해하는 데 효과적입니다.
제 장시간 실행 에이전트 워크플로에서는 계획 단계 이후, 에이전트에게 세 개의 파일을 만들고 읽고 유지하도록 요청합니다.
GOAL.md: 우리가 달성하고자 하는 최상위 목표
STANDARDS.md: 반드시 지켜야 하는 타협 불가능한 코드 품질 기준
IMPLEMENT.md: 워크플로 지침(리뷰에 여러 에이전트 사용, 테스트 작성, 작업 검증 등)
PROGRESS.md: 어떤 결정이 내려졌고 어떤 작업이 수행되었는지 계속 갱신되는 로그
저는 새 에이전트에게 이 파일들을 모두 읽게 해서, 이전 에이전트들이 내린 모든 결정과 진행 상황을 즉시 이해하고 그 흐름에 맞는 방식으로 행동하도록 합니다.
물론 에이전트는 너무 많은 것을 말해주면 항상 잘 따르지는 않기 때문에, 이것들은 반드시 지켜지는 규칙이라기보다 가이드라인에 가깝습니다. 그래도 전반적으로는 과정에 도움이 됩니다.
저는 장시간 실행 에이전트에 정말 큰 기대를 걸고 있습니다. 모델이 시간이 갈수록 더 좋아짐에 따라, 우리가 정말로 무엇인가를 원샷으로 존재하게 만들 수 있을지도 모른다는 생각은 믿기 어려울 정도로 대단합니다.
저는 지난 몇 달 동안 이것이 작동하게 만들기 위해 실험해 왔고, 그 과정에서 배운 점들을 여기에 기록해 왔습니다... 제 현재 장기 실행 설정이 궁금하고 직접 시도해 보고 싶다면, 여기 링크가 있습니다.
이것은 Claude/Codex에 쉽게 꽂아 넣을 수 있는 SKILL.md로 패키징되어 있지만, subagent 워크플로를 훌륭하게 시각화해 주는 Codex App 안의 GPT 5.5 xHigh와 함께 사용하는 것을 추천합니다.
이 스킬에는 git worktrees를 사용해 subagent의 작은 팀들 사이에서 작업을 병렬화하는 멋진 기능도 포함되어 있습니다. 저는 이것을 긴 실행에 사용해, 다듬기만 하면 되는 아주 탄탄한 프로젝트 기반 조각들을 만들어 냈습니다.
마음에 드셨으면 좋겠습니다!
