스레드 라이프사이클

Codex를 깊게 쓰기 시작하면 프롬프트보다 더 중요한 것이 스레드 관리입니다. 최근 릴리스는 thread/start, thread/resume, fork, steering, approval 복원 흐름을 계속 강화하고 있습니다.

왜 중요한가

• 장시간 작업을 중단/재개할 때 맥락 유실을 줄여줍니다
• 멀티에이전트와 Cloud Tasks를 하나의 운영 모델로 묶을 수 있습니다
• 승인 대기, 추가 입력, 모델 전환 상태를 추적하기 쉬워집니다

핵심 흐름

재오픈 스레드 상태 복원 (0.114.0)

0.114.0 이전에는, 작업 도중 세션을 강제 종료(Ctrl+C 등)한 뒤 스레드를 다시 열면 in-progress 상태에 갇혀 resume이 불가능한 문제가 있었습니다.

0.114.0에서 이 버그가 수정되어, 중간 종료된 스레드를 재오픈하면 올바른 상태(pending 또는 idle)로 자동 복원됩니다. 장시간 멀티에이전트 작업 중 예기치 않은 종료가 발생해도 스레드를 안전하게 이어갈 수 있습니다.

Handoff transcript 컨텍스트 (0.114.0)

에이전트 간 handoff 시 실시간 transcript 컨텍스트가 함께 전달됩니다. 이전에는 handoff를 받은 에이전트가 역할과 지시만 받았지만, 이제는 직전까지의 대화 맥락을 함께 인수받아 연속성이 크게 좋아졌습니다.

이로 인해 resume/fork/steer 시나리오에서도 “이전에 무슨 이야기가 오갔는지”를 에이전트가 스스로 파악할 수 있어, 사람이 반복 설명할 필요가 줄어듭니다.

Realtime 세션 컨텍스트 개선 (0.116.0)

0.116.0에서 Realtime 세션이 최근 스레드 컨텍스트를 포함하여 시작되도록 개선되었습니다. 이전에는 실시간 세션이 빈 상태에서 시작됐지만, 이제는 직전 대화 맥락을 자동으로 인수받아 연속성이 향상됩니다. 또한 오디오 재생 중 자기중단(self-interruption) 빈도가 줄어 실시간 음성 워크플로우가 안정화되었습니다.

원격 resume/fork 대화 히스토리 복원 (0.116.0)

원격 환경에서 resume 또는 fork를 수행할 때 대화 히스토리가 올바르게 복원되지 않던 문제가 수정되었습니다. 이제 원격 세션에서도 이전 대화 내용이 정확하게 이어지므로, Cloud Tasks나 원격 연결 기반 워크플로우에서 스레드 재개가 더 안정적입니다.

/resume 직접 점프 + picker 안정화 (0.119.0)

0.119.0부터 /resume은 TUI에서 session ID 또는 이름으로 바로 점프할 수 있습니다. 단순히 목록을 스크롤해서 고르는 방식보다 운영성이 좋아져, 병렬 세션이 많은 팀에서 특히 유용합니다.

같은 릴리즈에서 resume picker도 함께 안정화됐습니다.

• false empty state가 번쩍이며 나타나는 문제 완화
• thread 이름과 timestamp 라벨 신선도 개선
• zero-token 종료 뒤 resume 힌트 보존
• 현재 스레드를 다시 resume할 때의 크래시 회피

즉, 최근의 resume은 "중단된 세션 복원"을 넘어서 큰 세션 카탈로그를 빠르게 탐색하는 진입점에 더 가까워졌습니다.

Realtime V2 백그라운드 진행률 스트리밍 (0.120.0)

0.120.0에서 Realtime V2는 백그라운드 에이전트 진행률을 작업 중간에도 스트리밍하고, active response가 끝나기 전 follow-up response를 큐잉할 수 있게 됐습니다.

이 변화는 thread lifecycle 관점에서 중요합니다.

• 사용자는 "멈춘 것처럼 보이는 긴 작업"과 "실제로 진행 중인 작업"을 더 쉽게 구분할 수 있음
• 후속 입력이 즉시 처리되지 않더라도 queue 상태를 전제로 운영할 수 있음
• guardian/approval/workflow UI는 running, queued, follow-up pending 상태를 구분해 노출하는 편이 좋아짐

queued slash command와 side 질문 (0.121.0~0.122.0)

0.121.0~0.122.0에서는 "작업이 도는 동안 사람이 어떻게 개입하느냐"가 더 좋아졌습니다.

• composer가 Ctrl+R reverse search를 지원해, 장시간 세션에서도 이전 지시를 빠르게 재사용할 수 있음
• accepted slash command가 로컬에서 다시 recall되어 반복 운영 명령을 덜 다시 타이핑하게 됨
• 0.122.0부터 queued input이 slash command와 ! shell prompt를 받아, 실행 중인 작업을 끊지 않고도 보조 지시를 넣을 수 있음
• /side가 공식 slash commands 문서에 등재되어, 부모 thread를 보존한 짧은 보조 질문을 표준 운영 명령으로 다룰 수 있음

즉, 최근의 thread lifecycle은 resume/fork/steer만이 아니라 running thread에 안전하게 개입하는 UX까지 포함해서 봐야 합니다.

persisted /goal과 큰 thread pagination (0.128.0~0.130.0)

0.128.0부터는 장시간 작업에 **지속 목표(goal)**를 붙이는 흐름이 들어왔습니다. /goal <objective>로 목표를 설정하고, /goal pause, /goal resume, /goal clear로 실행 중 목표를 다룰 수 있습니다.

운영 관점에서는 goal을 "프롬프트 한 줄"이 아니라 thread metadata처럼 취급하는 편이 좋습니다.

• 큰 migration, 정리 작업, 반복 검증처럼 하루 이상 이어질 수 있는 작업에만 goal을 붙임
• goal에는 결과물과 중단 조건을 함께 적음
• pause 상태로 resume된 thread를 다시 열 때는 /goal로 현재 goal을 먼저 확인
• 사람이 범위를 바꾸면 기존 goal을 수정하기보다 clear 후 새 goal로 시작

0.130.0에서는 app-server client가 큰 thread를 unloaded, summary, full turn item view로 page 처리할 수 있어, 장기 작업을 "전체 transcript 로드"가 아니라 "요약/필요 turn 중심 탐색"으로 다루기 쉬워졌습니다. goal과 pagination을 함께 쓰면 긴 thread를 무작정 compact하기보다, 목표·요약·필요 turn만 남기는 방식으로 운영할 수 있습니다.

resume hinting + 대형 스레드 카탈로그 대응 (0.123.0~0.125.0)

0.123.0~0.125.0에서는 "어떤 스레드를 다시 열어야 하는지"와 "많은 스레드를 어떻게 탐색할지"가 더 좋아졌습니다.

• current vs archived thread 구분: 0.123.0부터 resume hinting이 현재 스레드와 archived thread를 더 잘 구분합니다
• heading-only lookup: plain #가 heading-only context lookup을 열어, 긴 문맥에서 필요한 지점을 더 빨리 찾을 수 있습니다
• cursor-based pagination: 0.125.0에서 app-server thread/resume/fork가 cursor pagination을 지원해 1,000개 이상 task도 안정적으로 다룹니다
• multi-environment persistence: thread에 여러 environment name이 더 안정적으로 유지되어, resume 후 환경 문맥이 덜 어긋납니다

즉, 최근 resume은 단순 복원 기능이 아니라 큰 task 카탈로그를 운영하는 탐색 레이어에 더 가까워졌습니다.

resume 전략

최근 릴리스에서 thread/resume은 단순 대화 복원이 아니라, pending approval과 pending input도 함께 복원하는 방향으로 개선됐습니다. 그래서 재개 시 가장 먼저 확인할 것은 “맥락이 이어졌는가”가 아니라 “무엇 때문에 멈췄는가”입니다.

재개 체크리스트

1. 마지막 turn이 완료 상태인지 확인
2. 승인 대기인지, 추가 입력 대기인지 분리
3. 현재 모델/권한/작업 루트가 바뀌지 않았는지 확인
4. 장시간 작업이면 steer 또는 fork가 더 적절한지 판단

steering을 언제 쓰나

steering은 새 프롬프트를 다시 쓰는 기능이 아니라, 이미 진행 중인 작업의 방향을 조정하는 기능에 가깝습니다.

적합한 상황:

• 탐색 범위를 더 좁히고 싶을 때
• 우선순위를 바꾸고 싶을 때
• “수정은 하지 말고 원인 분석만”처럼 목표를 축소할 때
• 승인 대기 이후 후속 지시를 짧게 넣고 싶을 때

부적합한 상황:

• 요구사항이 완전히 바뀌는 경우
• 결과물을 서로 비교해야 하는 경우
• 모델/권한 정책이 크게 달라지는 경우

이때는 steer보다 fork가 더 안전합니다.

fork 전략

fork는 “현재 컨텍스트를 유지한 채 다른 접근을 병렬 실험”하는 데 유리합니다.

예시:

• 한 스레드는 원인 분석
• 다른 스레드는 최소 수정안 작성
• 또 다른 스레드는 리스크/롤백 플랜 정리

최종적으로 부모 스레드에서 하나만 채택하면 됩니다.

멀티에이전트와의 관계

멀티에이전트는 thread lifecycle을 더 촘촘하게 씁니다.

• 부모 스레드: 목표/검증 기준 관리
• 자식 스레드: 역할별 실행
• child-thread approval: 위험 작업에서 사람이 개입
• resume/fork/steer: 장시간 병렬 작업을 통제하는 장치

즉, 멀티에이전트는 별도 기능이 아니라 스레드 라이프사이클을 병렬화한 운영 방식으로 보는 편이 정확합니다.

앱/클라이언트 구현 포인트

앱 서버를 붙이는 팀이라면 다음 항목을 UI/로그에 꼭 노출하는 편이 좋습니다.

• 현재 turn 상태
• background agent progress / queued follow-up 여부
• pending approval / pending input 여부
• 현재 모델과 reroute 여부
• steer 개입 시점
• resume 시 복원된 상태

이 정보를 숨기면 장시간 세션에서 “왜 멈췄는지”를 사람이 추적하기 어려워집니다.

참고 문서

• Changelog: https://developers.openai.com/codex/changelog (영어)
• Multi-agent: https://developers.openai.com/codex/multi-agent (영어)
• Codex App: https://developers.openai.com/codex/app (영어)
• GitHub Releases: https://github.com/openai/codex/releases (영어)