단원 — 4 요소 ① 시간 (한입씩 도는 시대)
별칭: 4 요소 시간 단원 · one bite 단원 · 한입 단원
한 줄 명제
에이전트의 시간은 쿼리 루프의 시간이다. 한 턴이 한입(One Bite) 이어야 수렴한다. 한입이 아니면 시간은 빙빙 돈다.
강의 흐름 (12 분)
① 함수에서 루프로 (2 분)
LLM 한 번 호출은 함수 다. 들여보내는 프롬프트가 있고 받아 보는 텍스트가 있다. 변수가 둘. 두 개로 사고하면 충분했다 — 그게 concept/prompt-engineering 함수 시대 의 사고방식.
에이전트는 다르다. 함수가 아니라 루프. 프롬프트가 들어가면 모델이 도구를 부르고, 도구가 결과를 돌려주고, 그 결과가 다시 모델 입력에 합쳐지고, 모델이 또 도구를 부르고. 그렇게 도구 호출 없는 응답이 나올 때까지 돈다. 한 번 도는 것을 한 턴 이라 부른다.
이게 시간 요소 의 본질. 그리고 흥미로운 건 — 종래의 SE 에서는 이런 루프가 사실상 불가능했다. 사람이 한 사이클을 돌리는 비용이 너무 컸다. AI 가 한 사이클을 분 단위로 돌려 주는 시대 가 되어서야 — 이 루프가 처음으로 가능해졌다.
② 한입 (One Bite) 의 미학 (3 분)
쿼리 루프가 수렴하려면 — 한 턴에 처리하는 작업이 한입 크기 여야 한다.
한입이 아니면 시간은 빙빙 돈다.
큰 작업은 — 도구를 5번, 10번, 100번 호출해도 안 끝난다. 한 턴 안에서 max_turns 에 닿거나, Compaction 이 너무 자주 발동하거나, 도구 결과 토큰이 컨텍스트를 부풀려 부패가 시작된다.
한입의 3 가지 표시:
| 표시 | 값 |
|---|---|
| 명확한 시작과 끝 | "X 파일의 Y 함수에 Z 검증을 추가하라" → 한입 ✅ "이 프로젝트를 리팩토링하라" → 한입 ❌ (큰 덩어리) |
| 3~5 턴 안에 수렴 | 도구 호출이 그 이상 길어지면 한입 ❌ |
| 검증 가능한 산출 | 한입 끝에 통과/실패가 명확 해야 함 |
③ 한입을 만드는 3 도구 (2 분)
| 도구 | 역할 |
|---|---|
| Plan Mode | 큰 작업을 받기 전에 한입 N 개로 분해 |
| TodoWrite | 분해된 한입을 순서대로 박제 |
| Subagent | 한 한입을 격리된 컨텍스트 에서 처리 (Task tool) |
시간 요소의 모든 도구 는 한입을 만들기 위한 도구 다.
→ concept/subagent-driven-development · term/plan-mode ·
④ 7 transition site — 명시적 상태 머신 (2 분)
Claude Code 의 query.ts 에는 continue 지점이 정확히 7 개 있다. 각각 다른 transition.reason 을 갖는다 — next_turn, reactive_compact_retry, max_output_tokens_escalate, max_output_tokens_recovery, stop_hook_blocking, token_budget_continuation, collapse_drain_retry.
쿼리 루프는 단순 while 이 아니라 명시적 상태 머신. 7 개 분기가 다 기록되어 있고, 각 분기는 한입이 깨졌을 때 어떻게 다시 돌까 를 결정한다.
한입이 깨졌다는 신호: Reactive compact, max output 4 배 escalate, collapse drain — 이런 transition 이 빈번해지면 — 그 한 턴이 한입이 아니었다는 증거. 작업 단위 설계가 잘못된 것.
⑤ 5 recovery 전략 — 실패에서 다시 도는 분기 (1.5 분)
흥미로운 점 — 7 transition 中 5 개가 recovery 분기. 즉 시간 요소의 절반이 한입 깨진 뒤 다시 돌기 위한 코드. 정상 흐름의 코드보다 실패 처리의 코드가 더 무겁다.
기록 통계: 한때 1,279 개 세션 이 50 회 이상 연속 compaction 실패를 경험. 하루 25 만 API 호출이 그것 때문에 낭비됐다. 그 사건 후 circuit breaker 가 도입됐다. → Claude Code 도 실패를 통해 학습한 시스템. v1 에 없던 recovery 분기가 매 메이저 릴리스마다 추가됐다.
→ 우리 자신의 워크플로우도 동일하게 recovery 분기를 기록하는 진화 가 필요. 내 워크플로우의 recovery 분기는 몇 개인가.
⑥ 워크플로우 패턴 (1.5 분)
사용자 요청 (큰 덩어리)
↓
Plan Mode → 한입 N 개로 분해
↓
TodoWrite → N 개 한입 박제
↓
한입 1 ─ 쿼리 루프 3~5 턴 → 검증 ─→ 다음 한입
↓
한입 2 ─ 쿼리 루프 3~5 턴 → 검증 ─→ 다음 한입
↓
... 모든 한입 완료 → 종료
시간은 한입과 명시적 게이트로만 안전해진다.
한입이 아니면 빙빙 돌고, 게이트가 없으면 첫 실패에 무너진다. 이게 시간 요소의 한 줄 정리.
4 엔지니어링 통합 기록
본 단원은 시간 = 에이전틱 엔지니어링 + α 를 기록:
- 에이전틱 엔지니어링: 루프 결정 흐름의 주 무대. Plan/TodoWrite/Subagent
- 하네스 엔지니어링: 7 transition site + 5 recovery 분기 = 모델 바깥 인프라 의 시간 차원
- 컨텍스트 엔지니어링: 한입이 깨지면 공간이 부패 (다음 단원과 연결)
- 프롬프트 엔지니어링: 한 한입의 입력 설계 가 프롬프트 임 (한입을 명확히 기록하는 일)
→ 4 분야 모두 시간 요소 위에서 기록됨. concept/4-engineering-disciplines 통합 기록 규칙 정합.
다음 단원으로
한입이 한입씩 잘 돌아도 — 한 한입이 부패하면 같은 한입을 또 돌리게 된다. 다음 단원은 부패를 막는 일 — lesson/4elements-space-context-rot (공간 요소).
출처
60_service/6006 booklet-vibe-coding-4-elements/_combined_book.md §272~322 (3 장 — 시간 — 한입씩 도는 시대).