Long-Horizon Agent 설계: Codex와 Claude가 몇 시간·며칠짜리 작업을 끝까지 이어가는 방법

이경규·2026년 8월 1일

Long-Horizon Agent 설계: Codex와 Claude가 몇 시간·며칠짜리 작업을 끝까지 이어가는 방법

AI 코딩 Agent를 사용할 때 대부분의 작업은 짧다.

파일 하나 수정
→ 테스트
→ 완료

또는

Bug 분석
→ 코드 수정
→ PR

정도로 끝난다.

이런 작업은 Agent가 한 번 실행되는 동안 필요한 Context를 읽고 바로 끝내면 된다.

하지만 최근 Agent 모델은 그보다 훨씬 긴 작업을 겨냥하고 있다.

Repository 전체 Migration

대규모 Refactoring

며칠에 걸친 Research

수십 개 Issue 정리

여러 Module 동시 개선

Design → 구현 → 검증 반복

대규모 Test Failure 수정

이런 작업은 단순히 Prompt를 길게 쓴다고 해결되지 않는다.

작업 시간이 길어질수록 새로운 문제가 생긴다.

어디까지 했는가?

무엇이 실제로 완료됐는가?

중간에 실패하면 어디서 다시 시작할까?

이미 한 Tool 호출을 다시 실행하지 않을까?

Agent가 목표에서 벗어나지 않았는가?

예산이 얼마나 남았는가?

결과를 무엇으로 검증할까?

그래서 Long-Horizon Agent는 일반 Agent와 Runtime 구조 자체가 달라져야 한다.

최근 OpenAI는 Codex를 한 번의 Prompt를 넘어 장기 작업을 계속 이어가는 persistent workspace로 사용하는 패턴을 별도로 소개했고, Claude Fable 5 역시 공식적으로 며칠에 걸친 장시간 Agent 작업을 주요 사용처로 내세우고 있다.

이번 글에서는 Codex를 기준으로 긴 개발 작업을 어떻게 구성하고, Claude Fable 5 같은 Long-Horizon 모델과 어떤 공통 구조를 갖는지 정리한다.

1. Long-Horizon Agent가 뭔가

단순히 실행 시간이 긴 Agent를 뜻하지 않는다.

예를 들어 Build가 40분 걸린다고 해서 무조건 Long-Horizon Agent는 아니다.

Long-Horizon Agent의 핵심은 여러 단계의 판단과 실행이 긴 시간 동안 이어진다는 것이다.

Goal

↓

조사

↓

Plan

↓

구현

↓

검증

↓

문제 발견

↓

계획 수정

↓

추가 구현

↓

재검증

↓

완료

이 과정이 수십 분에서 몇 시간, 경우에 따라 며칠까지 이어질 수 있다.

그래서 일반 Agent의

Prompt
→ Tool
→ Result

구조로는 부족하다.

2. 장시간 Agent의 기본 구조

가장 단순화하면 이렇게 볼 수 있다.

Goal

↓

Plan

↓

Step

↓

Checkpoint

↓

Step

↓

Artifact

↓

Checkpoint

↓

Verification

↓

Done

여기서 중요한 단어는 세 가지다.

Checkpoint

Artifact

Resume

이 세 가지가 없으면 Agent는 오래 실행될수록 불안정해진다.

3. 왜 Checkpoint가 필요한가

다음과 같은 작업을 Codex에 맡겼다고 하자.

이 프로젝트를 Swift 6 strict concurrency에 맞게
전체 Migration해줘.

Agent가 작업을 시작한다.

1. Warning 조사

2. Actor isolation 문제 분류

3. Network Module 수정

4. Camera Module 수정

5. Test 수정

6. 전체 Build

그런데 4단계에서 Agent 실행이 중단됐다.

Checkpoint가 없다면 다시 시작한 Agent는 이런 상태다.

어디까지 했지?

Network는 끝났나?

Camera는 일부만 고쳤나?

테스트는 실행했나?

결국 Repository를 다시 조사한다.

시간과 Token을 다시 사용한다.

4. Checkpoint는 생각이 아니라 실행 상태다

앞 글에서 Persisted Reasoning을 다뤘다.

Checkpoint와 Reasoning은 다르다.

Persisted Reasoning
→ 이전 판단을 이어가는 것

Checkpoint
→ 실제 작업이 어디까지 완료됐는지 저장

예를 들어

{
  "taskId": "MIGRATION-2026-01",

  "status": "running",

  "completedSteps": [
    "scan-concurrency-warnings",
    "network-module"
  ],

  "currentStep": "camera-module",

  "remainingSteps": [
    "tests",
    "full-build"
  ]
}

이것이 Checkpoint다.

Agent 내부 reasoning이 없어도 Runtime이 현재 위치를 알 수 있다.

5. Codex에서는 Goal부터 명확하게 잡는 것이 좋다

최근 Codex에는 Goal Mode가 들어왔다.

긴 작업에서는 단순 명령보다 완료 상태를 먼저 정의하는 것이 중요하다.

예를 들어

Swift 6 Migration해줘.

보다 다음이 낫다.

Goal:

프로젝트를 Swift 6 strict concurrency 기준으로
빌드 가능하게 만든다.

Success Criteria:

- concurrency warning 0
- compile error 0
- 기존 public API 유지
- 기존 unit test 실행
- 실행하지 않은 test는 passed라고 보고하지 않음
- 변경 파일 목록과 미해결 항목 보고

Agent가 긴 시간 작업해도 무엇을 향해 가는지가 명확하다.

6. Goal과 Task를 구분한다

큰 Goal 하나를 작은 Task로 나눈다.

Goal

Swift 6 Migration

↓

Task 1

Concurrency warning inventory

Task 2

Network module migration

Task 3

Camera module migration

Task 4

UI isolation fixes

Task 5

Test migration

Task 6

Final verification

Long-Horizon Agent에서 가장 위험한 형태는 이것이다.

큰 Goal 하나

↓

Agent가 알아서 끝날 때까지 작업

진행 상태를 검증하기 어렵다.

7. Step은 검증 가능해야 한다

좋은 Step은 완료 여부를 확인할 수 있다.

나쁜 예:

Architecture 개선

완료 기준이 없다.

좋은 예:

Network module에서 Swift concurrency warning을 0으로 만든다.

검증:
xcodebuild 실행 결과 warning 0

또는

Auth module 테스트를 수정한다.

검증:
AuthTests 실행 성공

즉

Step

+

Verification

을 하나의 단위로 보는 편이 좋다.

8. Long-Horizon Agent는 Plan을 고정하면 안 된다

처음 계획이 항상 맞지는 않는다.

예를 들어

Plan

1. Network
2. Camera
3. UI

로 시작했다.

Camera Module을 조사했더니 실제 문제의 중심이 Shared Core에 있었다.

기존 계획을 그대로 밀어붙이면 좋지 않다.

그래서 Plan은 Version을 가진다.

{
  "planVersion": 3,

  "steps": [
    "shared-core",
    "network",
    "camera",
    "ui"
  ]
}

변경 이유도 남긴다.

Plan v2 → v3

Reason:
Camera의 concurrency 문제 대부분이
SharedStateStore에서 시작되는 것을 확인.

9. Plan 변경에도 경계가 필요하다

Agent가 마음대로 Goal까지 바꾸면 안 된다.

구분한다.

Goal
→ 되도록 고정

Plan
→ 상황에 따라 수정 가능

Step
→ 실행 중 세부 조정 가능

예:

Goal

Swift 6 Migration 완료

는 유지한다.

하지만

Network부터 수정한다.

는 변경 가능하다.

10. Artifact가 중요한 이유

장시간 Agent는 자연어 Conversation만 남기면 안 된다.

실제 결과를 파일로 남긴다.

예:

.artifacts/

├── migration-inventory.json
├── network-result.json
├── camera-result.json
├── test-result.json
├── final-diff.patch
└── final-report.md

각 Stage가 끝날 때 Artifact를 만든다.

11. Artifact가 Agent의 기억보다 신뢰할 수 있다

Agent가

Network Module 수정 완료했습니다.

라고 말하는 것과

{
  "module": "Network",
  "modifiedFiles": [
    "APIClient.swift",
    "RequestExecutor.swift"
  ],
  "build": {
    "status": "passed"
  }
}

를 남기는 것은 다르다.

후자는 Runtime과 사람이 검증할 수 있다.

Long-Horizon Agent는 말보다 Artifact를 중심으로 운영하는 편이 좋다.

12. Step Result Contract를 만들어보자

예:

type StepResult = {
  stepId: string;

  status:
    | "completed"
    | "failed"
    | "blocked";

  modifiedFiles: string[];

  artifacts: string[];

  verification: {
    command?: string;
    status:
      | "passed"
      | "failed"
      | "not_run";
  };

  remainingIssues: string[];
};

Agent가 매 Step마다 이 구조를 남긴다.

13. not_run은 passed가 아니다

장시간 Agent에서 특히 중요한 규칙이다.

Agent가

테스트도 문제없을 것입니다.

라고 판단하면 안 된다.

반드시 구분한다.

passed

failed

not_run

예:

{
  "verification": {
    "command": null,
    "status": "not_run"
  }
}

이 상태에서 Final Task는 완료되지 않는다.

14. Resume는 Checkpoint에서 시작해야 한다

작업이 중단됐다.

다시 실행할 때 Repository 전체를 처음부터 조사하지 않는다.

먼저 읽는다.

Goal

Current Plan

Checkpoint

Artifacts

Current Git Diff

구조는

Resume

↓

Checkpoint Load

↓

Repository 현재 상태 비교

↓

Artifacts 확인

↓

다음 Step 결정

↓

계속 실행

이 된다.

15. Resume 전에 Reality Check를 한다

Checkpoint가 있다고 무조건 믿으면 안 된다.

왜냐하면 Agent가 멈춘 사이 사람이 Repository를 수정했을 수 있다.

예를 들어

Checkpoint SHA

abc123

인데 현재 Repository는

Current SHA

def991

일 수 있다.

그러면 이전 Plan이 유효한지 확인해야 한다.

16. Base Revision을 기록한다

{
  "checkpointId": "cp-18",
  "baseRevision": "abc123",
  "currentStep": "camera-migration"
}

Resume 시

현재 SHA == baseRevision

→ 정상 Resume

현재 SHA != baseRevision

→ 변경 범위 확인

한다.

큰 변경이면 Plan을 다시 평가한다.

17. 파일 Hash를 함께 쓸 수도 있다

중요 파일은 Hash를 저장한다.

{
  "files": {
    "Sources/Camera/FramePublisher.swift": "sha256:..."
  }
}

Resume할 때 파일이 달라졌다면

STALE_CHECKPOINT

로 판단할 수 있다.

18. Long-Horizon Agent에는 Lease가 유용하다

같은 Task를 Agent 두 개가 동시에 Resume하면 문제가 된다.

예:

Agent A

Task 142 Resume

동시에

Agent B

Task 142 Resume

둘 다 같은 파일을 수정한다.

그래서 Task에 Lease를 둔다.

{
  "taskId": "PAP-142",
  "leaseOwner": "agent-run-98",
  "leaseExpiresAt": 1785504000
}

Task를 실행 중인 Agent만 Lease를 가진다.

19. Heartbeat로 Lease를 갱신한다

Agent가 정상 실행 중이면 주기적으로 갱신한다.

Agent

↓

Heartbeat

↓

Lease Extend

Agent가 Crash하면 Heartbeat가 끊긴다.

일정 시간이 지나면 Lease가 만료된다.

다른 Agent가 Resume할 수 있다.

20. Paperclip의 Heartbeat와 비슷한 개념이다

앞서 Paperclip 글에서 Agent가 항상 실행되는 Process가 아니라

idle

↓

Heartbeat

↓

작업

↓

idle

형태로 움직인다고 다뤘다.

Long-Horizon Runtime에서도 Heartbeat는 중요하다.

다만 여기서는

Agent가 살아 있는가?

Lease를 계속 유지해야 하는가?

현재 Step이 진행 중인가?

를 확인하는 용도로 볼 수 있다.

21. Timeout은 하나가 아니라 여러 층에 둔다

장시간 작업이라고 Timeout을 없애면 안 된다.

다음처럼 나눈다.

Tool Timeout

Step Timeout

Agent Run Timeout

Task Timeout

예:

timeouts:

  tool: 60

  step: 1800

  run: 7200

  task: 86400

단위는 서비스 상황에 맞게 설정한다.

22. Tool Timeout과 Task Timeout은 다르다

예를 들어

xcodebuild

가 멈췄다.

Task 전체를 실패시킬 필요는 없다.

Tool Timeout

↓

Step Retry 또는 Blocked

가 될 수 있다.

반대로 전체 Task가 하루를 넘기면

Task Deadline

을 확인해야 한다.

23. Deadline도 전파한다

Root Task Deadline이

오늘 18:00

이라면 Subtask가

19:00까지 실행

되면 안 된다.

그래서 Worker에게 남은 시간을 전달한다.

{
  "deadline": "2026-07-31T18:00:00+09:00",
  "remainingSeconds": 6200
}

Subagent까지 Deadline이 전파되어야 한다.

24. Budget도 같이 줄여나간다

Long-Horizon Agent는 비용 관리가 중요하다.

예:

Task Budget

$20

Agent가 $6을 사용했다.

remainingBudget

$14

를 다음 Step에 전달한다.

25. Budget 종류를 나눌 수도 있다

type AgentBudget = {
  maxCostUsd: number;

  maxModelCalls: number;

  maxToolCalls: number;

  maxSubagents: number;

  maxWallTimeSeconds: number;
};

장시간 작업에서 Token 하나만 제한하는 것으로는 부족하다.

26. 예산이 줄어들면 전략도 바뀐다

처음에는

Sol high

로 분석한다.

Budget이 부족해지면

Terra medium

으로 Worker를 낮출 수 있다.

앞에서 다룬 Model Router와 연결된다.

Remaining Budget

↓

Model Router

↓

Sol / Terra / Luna

27. Long-Horizon Agent와 Multi-Agent는 자연스럽게 연결된다

대형 Migration이라면 하나의 Agent가 모든 것을 순차 처리하지 않는다.

Coordinator

├── Network Worker
├── Camera Worker
├── Auth Worker
└── Test Worker

병렬 처리한다.

하지만 여기서 중요한 것이 있다.

각 Worker도 자신의 Checkpoint를 가져야 한다.

28. Root Checkpoint와 Child Checkpoint

구조는 이렇게 된다.

Root Task

checkpoint-root.json

├── Worker A
│   └── checkpoint-a.json
│
├── Worker B
│   └── checkpoint-b.json
│
└── Worker C
    └── checkpoint-c.json

Coordinator는 각 Worker 상태를 본다.

A
completed

B
working

C
blocked

Root Task는 아직 완료되지 않는다.

29. Worker 실패가 전체 실패일 필요는 없다

예:

Worker A

Network Migration
→ completed

Worker B

Camera Migration
→ failed

Worker C

Test Update
→ completed

전체를 다시 실행하면 낭비다.

실패한 Worker만 Resume한다.

Camera Worker

checkpoint-b

↓

Resume

30. Retry는 반드시 Bounded Retry로 만든다

Agent에게

실패하면 다시 해.

라고만 하면 위험하다.

무한 반복 가능성이 있다.

Test 실패

↓

Retry

↓

Test 실패

↓

Retry

↓

...

횟수를 제한한다.

retry:

  tool: 2

  step: 1

  worker: 1

31. 실패 이유에 따라 Retry 여부도 다르다

Retry 가능한 오류:

Temporary Network Error

Rate Limit

Transient Tool Failure

Retry하면 안 되는 오류:

Compile Error

Invalid Schema

Permission Denied

Policy Denied

후자는 수정하거나 사람이 봐야 한다.

32. Error Contract를 만든다

type AgentFailure = {
  code:
    | "TOOL_TIMEOUT"
    | "RATE_LIMIT"
    | "COMPILE_FAILED"
    | "POLICY_DENIED"
    | "BLOCKED";

  retryable: boolean;

  evidence?: string[];

  suggestedNextAction?: string;
};

자연어 오류보다 Runtime이 처리하기 쉽다.

33. Codex에서는 Goal Mode를 활용할 만하다

최근 Codex는 앱, IDE Extension, CLI 전반에 Goal Mode를 제공한다.

Long-Horizon 작업에서는 특히 잘 맞는다.

단순히

여기 고쳐줘.

가 아니라

Goal

이 Module을 Swift 6 strict concurrency 기준으로
완전히 Migration한다.

Success Criteria

- Build success
- concurrency warning 0
- 기존 public API 유지
- 관련 test 실행

처럼 결과 중심으로 작업을 줄 수 있다.

34. Codex를 persistent workspace처럼 사용한다

OpenAI가 최근 공개한 Long-running work 가이드의 핵심도 이 부분이다.

Codex를 한 번의 Prompt에 답하는 도구가 아니라

Goal

↓

진행

↓

중간 결과

↓

검토

↓

다시 진행

을 이어가는 작업 공간처럼 사용한다.

Conversation 자체보다

현재 Goal

현재 Plan

현재 Diff

현재 Artifact

현재 Verification

이 중요한 상태가 된다.

35. 같은 Conversation을 다시 이어가는 Automations도 있다

Codex Automations는 반복 작업을 Schedule로 실행할 수 있다.

예를 들어

매일 아침

어제 실패한 CI를 확인하고
열려 있는 Issue를 업데이트해.

같은 작업이다.

중요한 점은 일부 Automation이 같은 Conversation으로 돌아와 기존 Context를 이어갈 수 있다는 점이다.

장시간 업무의 연속성을 만드는 데 활용할 수 있다.

36. 다만 Local Codex에는 현실적인 제한도 있다

Local Automation은 Mac이 꺼져 있으면 실행할 수 없다.

실제 운영에서는

Laptop awake

Codex running

같은 조건을 고려해야 한다.

정말 Always-on Agent가 필요하면 Cloud 또는 Server Runtime이 더 적합할 수 있다.

37. Codex에서 처음 테스트할 좋은 Long-Horizon Task

예를 들어 iOS 프로젝트라면 다음 정도가 좋다.

Goal:

현재 프로젝트의 Swift 6 concurrency 문제를
점진적으로 수정한다.

먼저 전체 문제를 조사하고
Module 단위 작업 계획을 만들어.

각 Module 완료 시

- 변경 파일
- 해결한 문제
- 실행한 검증
- 남은 문제

를 Artifact로 남겨.

Module 하나가 끝날 때마다
Checkpoint를 갱신하고
다음 Module로 진행해.

공통 파일 수정은 마지막 Integration 단계에서만 해.

전체 작업이 끝나면
전체 Build와 관련 Test를 실행해.

실행하지 않은 Test는
Passed라고 보고하지 마.

이 Prompt의 핵심은

Goal

Plan

Artifact

Checkpoint

Verification

을 명시했다는 것이다.

38. Repository에 작업 상태 파일을 둘 수도 있다

간단한 개인 프로젝트라면 복잡한 Database가 없어도 된다.

.ai/
└── tasks/
    └── swift6-migration/
        ├── goal.md
        ├── plan.json
        ├── checkpoint.json
        ├── decisions.md
        └── artifacts/

예:

{
  "version": 5,

  "completed": [
    "network",
    "auth"
  ],

  "working": "camera",

  "remaining": [
    "ui",
    "tests",
    "final-build"
  ]
}

다음 Codex Session에서도 이 파일부터 읽게 한다.

39. Resume Prompt도 미리 만들어두면 좋다

이 작업은 이전 Session에서 이어지는 작업이다.

먼저 다음 파일만 읽어.

- .ai/tasks/swift6-migration/goal.md
- plan.json
- checkpoint.json
- decisions.md

그다음 현재 Git diff와 HEAD를 확인해.

Checkpoint 내용과 현재 Repository 상태가 맞으면
current step부터 이어서 작업해.

Repository 상태가 달라졌다면
코드를 수정하지 말고 차이부터 보고해.

완료된 Step은 다시 실행하지 마.

상당히 실용적이다.

40. Decision Log도 남긴다

긴 작업에서는

왜 이렇게 바꿨지?

를 잊기 쉽다.

## Decision 014

CameraSession을 @MainActor로 올리지 않았다.

Reason:
Frame delivery가 Main Thread에 종속되면
Preview pipeline latency가 증가할 가능성이 있음.

Selected:
Frame state만 actor isolation 적용.

이런 식으로 남긴다.

다음 Agent도 같은 결정을 반복해서 고민하지 않는다.

41. Decision Log와 Reasoning은 다르다

Reasoning

→ 모델 내부 판단 연속성

Decision Log

→ 사람이 읽을 수 있는 확정된 결정 기록

중요한 Architecture 결정은 Decision Log에 남기는 편이 좋다.

42. Claude Fable 5도 같은 방향이다

Anthropic은 Fable 5를 가장 야심찬 long-running project용 모델로 소개한다.

공식 설명에서는 Agent Harness에서 Fable 5가

여러 Stage 계획

Subagent Delegation

자체 검증

장시간 작업

을 수행하며 며칠에 걸쳐 일할 수 있다고 설명한다.

예:

대규모 Migration

복잡한 Implementation

Multi-day Autonomous Session

이 대표적인 사용처다.

43. 하지만 Fable이 알아서 모든 상태를 안전하게 관리한다는 뜻은 아니다

모델이 오래 작업할 수 있다는 것과 Runtime이 견고하다는 것은 별개의 문제다.

여전히 필요하다.

Checkpoint

Artifact

Task State

Budget

Timeout

Verification

Human Approval

좋은 모델이 Runtime 설계를 대체하지 않는다.

44. Codex와 Fable의 공통점

두 방향 모두 결국 같은 문제를 해결한다.

짧은 Prompt 응답

↓

장시간 목표 지향 작업

그래서 개발자 입장에서는 특정 모델 이름보다 구조를 알아두는 것이 중요하다.

Goal

Plan

Workstream

Checkpoint

Artifact

Resume

Verification

이 패턴은 모델이 바뀌어도 남는다.

45. Long-Horizon Agent에서 사람이 개입할 지점

완전 자동으로 모든 것을 맡길 필요는 없다.

좋은 Human Gate는 다음과 같다.

Goal 승인

↓

Plan 승인

↓

Agent 실행

↓

고위험 변경 승인

↓

Final Review

↓

Merge / Deploy

특히

Production Deploy

DB Migration

Signing

Secret

Payment

외부 API 계약 변경

같은 작업은 Agent가 오래 일한다고 해서 자동 승인할 이유가 없다.

46. 사람에게 매 Step을 확인시키면 안 된다

반대로 모든 Step마다 승인받으면 Long-Horizon Agent의 장점이 사라진다.

파일 읽어도 될까요?

수정해도 될까요?

Test 돌릴까요?

다음 파일 볼까요?

가 된다.

Human Gate는 위험도 기준으로 둔다.

47. 위험도를 분류한다

LOW

파일 읽기
Test
Local Build

자동 실행.

MEDIUM

코드 수정
Branch Commit

정책에 따라 자동.

HIGH

Dependency 추가
Schema Migration
공용 API 변경

Approval.

CRITICAL

Production Deploy
Secret 변경
삭제 작업

반드시 사람 승인.

48. Long-Horizon Agent의 완료 조건도 중요하다

Agent가

대충 끝난 것 같습니다.

라고 판단하게 하지 않는다.

Completion Gate를 만든다.

type CompletionGate = {
  allRequiredStepsCompleted: boolean;
  verificationPassed: boolean;
  unresolvedCriticalIssues: number;
  requiredArtifactsPresent: boolean;
};

모두 충족해야 Done이다.

49. Done과 Blocked를 구분한다

Task 상태:

pending

running

blocked

failed

completed

blocked는 중요하다.

예:

Signing Certificate가 필요함

외부 API Credential 필요

사람의 Architecture 결정 필요

이건 실패가 아니다.

Agent가 할 수 있는 범위를 다 했지만 외부 입력이 필요한 상태다.

50. Blocked 상태에는 정확한 요청을 남긴다

나쁜 예:

진행할 수 없습니다.

좋은 예:

{
  "status": "blocked",

  "reason": "SIGNING_REQUIRED",

  "requiredInput": "Development Team ID",

  "completedSteps": [
    "code-migration",
    "unit-tests"
  ],

  "resumeFrom": "archive-build"
}

사람이 필요한 정보만 제공하고 다시 Resume할 수 있다.

51. Final Report는 작업 로그가 아니다

장시간 Agent가 한 일을 전부 나열하면 읽기 어렵다.

Final Report는 요약한다.

Goal

Result

Changed Areas

Verification

Remaining Risks

Artifacts

Next Action

예:

# Migration Result

## Result
Completed

## Changed
- Network
- Auth
- Camera

## Verification
- Build: Passed
- Unit Tests: Passed
- UI Tests: Not Run

## Remaining
- Deprecated API 2건

이 정도가 좋다.

52. Trace도 남겨야 한다

장시간 Agent에서 문제가 생겼을 때 알아야 한다.

어느 Step에서

어떤 Model이

어떤 Tool을

몇 번 호출했고

얼마나 걸렸는가

예:

{
  "traceId": "trace-1902",
  "taskId": "swift6-migration",
  "stepId": "camera",

  "durationSec": 921,

  "toolCalls": 18,

  "retries": 1
}

53. Trace와 Final Report를 분리한다

Trace
→ 시스템 운영용

Final Report
→ 개발자 검토용

둘은 목적이 다르다.

54. Eval도 짧은 Agent와 다르게 잡는다

Long-Horizon Agent를 평가할 때 단순 최종 답변 품질만 보면 안 된다.

다음 항목을 본다.

Task Completion Rate

Time to Completion

Resume Success Rate

Repeated Work

Tool Retry Rate

Checkpoint Accuracy

Budget

Human Intervention Count

Regression Rate

특히

Resume 후 이미 완료한 작업을 다시 하지 않았는가?

는 중요한 지표다.

55. Resume Eval을 만들어볼 수 있다

일부러 작업 중간에 Agent를 끊는다.

Step 1 완료

Step 2 완료

Step 3 진행 중

↓

Kill

다시 시작한다.

정상이라면

Step 3 확인

↓

필요한 부분부터 Resume

해야 한다.

잘못된 Agent는

Step 1부터 다시 시작

한다.

56. Repository 변경 상황도 테스트한다

Agent를 멈춘 뒤 사람이 파일 하나를 바꾼다.

Resume시

Checkpoint와 Repository가 다름

을 감지하는지 테스트한다.

Long-Horizon Eval에는 이런 현실적인 상황이 필요하다.

57. 처음부터 거대한 Runtime을 만들 필요는 없다

개인 개발자라면 다음 정도부터 시작하면 충분하다.

goal.md

plan.json

checkpoint.json

artifacts/

decisions.md

그리고 Codex에

시작할 때 읽어라.

Step 끝나면 갱신해라.

Resume시 다시 확인해라.

라고 준다.

복잡한 Database나 Queue가 없어도 Long-Horizon 패턴을 상당 부분 사용할 수 있다.

58. 제가 Codex에서 실제로 시작한다면

폴더:

.ai/
└── long-tasks/
    └── concurrency-migration/
        ├── goal.md
        ├── plan.json
        ├── checkpoint.json
        ├── decisions.md
        └── artifacts/

goal.md

# Goal

Swift 6 strict concurrency migration.

## Success Criteria

- project builds
- concurrency warnings resolved
- public API preserved
- relevant tests executed

checkpoint.json

{
  "status": "running",
  "completed": [],
  "current": "inventory",
  "remaining": [
    "network",
    "camera",
    "ui",
    "tests",
    "final-verification"
  ]
}

이 정도면 시작할 수 있다.

59. Codex Prompt

이 작업은 장시간 작업으로 진행해.

먼저

.ai/long-tasks/concurrency-migration/

폴더의

goal.md
plan.json
checkpoint.json
decisions.md

를 읽어.

Goal은 임의로 변경하지 마.

작업을 검증 가능한 Step으로 진행하고
각 Step이 끝날 때 checkpoint.json을 갱신해.

중요한 Architecture 판단은 decisions.md에 기록해.

각 Step 결과는 artifacts/에 구조화해서 저장해.

실행하지 않은 Test를 passed라고 보고하지 마.

Repository 상태가 checkpoint와 맞지 않으면
코드를 수정하기 전에 먼저 보고해.

전체 Success Criteria가 만족될 때만
completed로 변경해.

이 정도만으로도 일반적인

끝날 때까지 알아서 해줘.

보다 훨씬 안전하다.

60. Multi-Agent까지 붙인다면

큰 Migration에서는

Coordinator

├── Network
├── Auth
├── Camera
└── Test

로 나눈다.

각 Worker에게 별도 Artifact와 Checkpoint를 준다.

최종 Integration은 Coordinator만 담당한다.

Workers

↓

Artifacts

↓

Coordinator

↓

Integration

↓

Full Verification

61. Automations는 유지보수형 Long-Horizon 작업에 잘 맞는다

한 번에 10시간 실행하지 않아도 된다.

예를 들어

매일 오전

Migration 진행 상태 확인

↓

다음 Module 하나 처리

↓

Checkpoint 갱신

처럼 여러 날에 나눌 수 있다.

Codex Automation이 같은 Conversation Context로 돌아올 수 있다는 점도 이런 Workflow에 활용할 수 있다.

62. "오래 실행"보다 "계속 이어갈 수 있음"이 중요하다

Long-Horizon Agent를

24시간 계속 실행되는 Agent

라고만 생각하면 안 된다.

더 중요한 것은

중단

↓

상태 저장

↓

나중에 다시 시작

↓

정확한 위치에서 계속

할 수 있는가다.

실제 개발 작업에서는 이쪽이 훨씬 현실적이다.

63. 좋은 Long-Horizon Agent의 특징

정리하면 다음과 같다.

Goal이 명확하다.

Plan을 가지고 있다.

Step이 검증 가능하다.

Checkpoint가 있다.

Artifact를 남긴다.

Resume 가능하다.

Retry가 제한돼 있다.

Budget이 있다.

Timeout이 있다.

Human Gate가 있다.

Completion Gate가 있다.

Trace가 있다.

모델이 아무리 좋아도 이 구조가 없으면 장시간 작업은 쉽게 흔들린다.

64. 마무리

최신 Coding Agent의 변화는

코드를 한 번 잘 생성한다.

에서 끝나지 않는다.

Codex와 Claude 모두 이제

큰 Goal을 받고

오래 작업하고

중간 결과를 남기고

다시 이어서 작업하고

스스로 검증하는

방향으로 가고 있다.

하지만 Long-Horizon Agent를 단순히

더 오래 생각하는 모델

로 보면 중요한 부분을 놓친다.

실제로 필요한 것은 Runtime 구조다.

Goal

↓

Plan

↓

Step

↓

Checkpoint

↓

Artifact

↓

Resume

↓

Verification

↓

Done

그리고 작업이 커지면

Coordinator

↓

Parallel Workers

↓

Worker Checkpoints

↓

Artifacts

↓

Integration

↓

Final Verification

으로 확장한다.

한 줄로 정리하면 이렇다.

Long-Horizon Agent의 핵심은
오래 실행하는 것이 아니라,

중간에 멈춰도
어디까지 했는지 알고
정확하게 다시 이어갈 수 있게 만드는 것이다.

앞으로 Coding Agent가 몇 시간, 며칠짜리 작업을 맡게 될수록 개발자가 설계해야 하는 것은 Prompt보다 점점

Checkpoint, Artifact, Resume, Budget, Verification 같은 Agent Runtime의 운영 구조가 될 가능성이 크다.

참고 자료

OpenAI — Codex-maxxing for long-running work
Codex를 단발 Prompt가 아니라 장기 프로젝트를 이어가는 persistent workspace로 사용하는 방법과, 큰 목표를 검증 가능한 단계로 분해하는 운영 방식을 설명하는 공식 자료.
OpenAI — Codex
Codex의 Worktree, Cloud Environment, Multi-Agent Workflow, Background/Recurring 작업 등 실제 Coding Agent 운영 방향을 확인할 수 있는 공식 페이지.
OpenAI — Codex Goal Mode
결과와 Success Criteria를 먼저 정의하고 Codex가 장시간 목표를 향해 작업하도록 만드는 Goal Mode 관련 공식 업데이트.
OpenAI — Codex Automations
반복 작업을 Schedule로 실행하고, 일부 Automation이 기존 Conversation Context를 이어받아 지속적인 작업을 수행하는 방법을 설명하는 공식 자료.
Anthropic — Claude Fable 5
Claude Fable 5가 multi-stage planning, subagent delegation, self-verification을 포함한 며칠 단위 Long-Horizon Agent 작업을 주요 사용처로 두고 있음을 확인할 수 있는 공식 자료.

핵심 참고 포인트

최근 OpenAI는 Codex를 단발성 코드 생성 도구보다 복잡한 Workflow를 장기간 유지하는 작업 공간으로 사용하는 패턴을 별도로 소개하고 있다.

Codex의 Goal Mode는 앱, IDE Extension, CLI에서 사용할 수 있으며, 결과와 Success Criteria를 중심으로 Agent가 작업을 지속하도록 하는 데 적합하다.

Codex Automations는 반복 작업을 Schedule로 실행할 수 있고 일부 작업은 기존 Conversation Context를 이어서 수행할 수 있다. 단, 로컬 실행에서는 Mac이 깨어 있고 Codex가 실행 중이어야 하는 등의 운영 조건을 고려해야 한다.

Anthropic 역시 Fable 5를 장시간 비동기 작업과 며칠짜리 Coding Project에 적합한 모델로 설명하며, Agent Harness에서 planning, subagent delegation, self-verification을 장시간 이어가는 것을 주요 특징으로 제시하고 있다.

따라서 Long-Horizon Agent의 핵심은 모델이 오래 추론할 수 있다는 사실 하나가 아니라 Goal·Checkpoint·Artifact·Resume·Verification을 Runtime 수준에서 분리해 관리하는 것이다.

이경규

iOS 앱 개발자

이전 포스트

Codex로 규격에 맞는 EPUB 만들기: 설치부터 EPUBCheck·공모전까지

다음 포스트

Long-Horizon Agent 설계: Codex와 Claude가 몇 시간·며칠짜리 작업을 끝까지 이어가는 방법

Long-Horizon Agent 설계: Codex와 Claude가 몇 시간·며칠짜리 작업을 끝까지 이어가는 방법

1. Long-Horizon Agent가 뭔가

2. 장시간 Agent의 기본 구조

3. 왜 Checkpoint가 필요한가

4. Checkpoint는 생각이 아니라 실행 상태다

5. Codex에서는 Goal부터 명확하게 잡는 것이 좋다

6. Goal과 Task를 구분한다

7. Step은 검증 가능해야 한다

8. Long-Horizon Agent는 Plan을 고정하면 안 된다

9. Plan 변경에도 경계가 필요하다

10. Artifact가 중요한 이유

11. Artifact가 Agent의 기억보다 신뢰할 수 있다

12. Step Result Contract를 만들어보자

13. not_run은 passed가 아니다

14. Resume는 Checkpoint에서 시작해야 한다

15. Resume 전에 Reality Check를 한다

16. Base Revision을 기록한다

17. 파일 Hash를 함께 쓸 수도 있다

18. Long-Horizon Agent에는 Lease가 유용하다

19. Heartbeat로 Lease를 갱신한다

20. Paperclip의 Heartbeat와 비슷한 개념이다

21. Timeout은 하나가 아니라 여러 층에 둔다

22. Tool Timeout과 Task Timeout은 다르다

23. Deadline도 전파한다

24. Budget도 같이 줄여나간다

25. Budget 종류를 나눌 수도 있다

26. 예산이 줄어들면 전략도 바뀐다

27. Long-Horizon Agent와 Multi-Agent는 자연스럽게 연결된다

28. Root Checkpoint와 Child Checkpoint

29. Worker 실패가 전체 실패일 필요는 없다

30. Retry는 반드시 Bounded Retry로 만든다

31. 실패 이유에 따라 Retry 여부도 다르다

32. Error Contract를 만든다

33. Codex에서는 Goal Mode를 활용할 만하다

34. Codex를 persistent workspace처럼 사용한다

35. 같은 Conversation을 다시 이어가는 Automations도 있다

36. 다만 Local Codex에는 현실적인 제한도 있다

37. Codex에서 처음 테스트할 좋은 Long-Horizon Task

38. Repository에 작업 상태 파일을 둘 수도 있다

39. Resume Prompt도 미리 만들어두면 좋다

40. Decision Log도 남긴다

41. Decision Log와 Reasoning은 다르다

42. Claude Fable 5도 같은 방향이다

43. 하지만 Fable이 알아서 모든 상태를 안전하게 관리한다는 뜻은 아니다

44. Codex와 Fable의 공통점

45. Long-Horizon Agent에서 사람이 개입할 지점

46. 사람에게 매 Step을 확인시키면 안 된다

47. 위험도를 분류한다

48. Long-Horizon Agent의 완료 조건도 중요하다

49. Done과 Blocked를 구분한다

50. Blocked 상태에는 정확한 요청을 남긴다

51. Final Report는 작업 로그가 아니다

52. Trace도 남겨야 한다

53. Trace와 Final Report를 분리한다

54. Eval도 짧은 Agent와 다르게 잡는다

55. Resume Eval을 만들어볼 수 있다

56. Repository 변경 상황도 테스트한다

57. 처음부터 거대한 Runtime을 만들 필요는 없다

58. 제가 Codex에서 실제로 시작한다면

59. Codex Prompt

60. Multi-Agent까지 붙인다면

61. Automations는 유지보수형 Long-Horizon 작업에 잘 맞는다

62. "오래 실행"보다 "계속 이어갈 수 있음"이 중요하다

63. 좋은 Long-Horizon Agent의 특징

64. 마무리

참고 자료

핵심 참고 포인트

Codex로 규격에 맞는 EPUB 만들기: 설치부터 EPUBCheck·공모전까지

AI 코딩 에이전트도 Policy as Code가 필요하다: managed-settings.json으로 권한·플러그인·모델 통제하기

0개의 댓글