코덱스 툴 사용법 20: 긴 작업은 인계 메모로 살린다 | DAKER 커뮤니티
코덱스 툴 사용법 20: 긴 작업은 인계 메모로 살린다
Codex에게 긴 작업을 맡길 때 가장 위험한 순간은 시작이 아닙니다. 오히려 중간입니다. 파일을 몇 개 고쳤고, 테스트를 돌렸고, 브라우저나 API까지 확인했는데 세션이 길어지면 “지금 어디까지 했더라?”가 됩니다.
OpenAI Codex manual 기준으로 Codex thread는 프롬프트, 모델 출력, tool call이 이어지는 하나의 세션입니다. 작업 중에는 파일 내용, 도구 출력, 남은 일의 기록을 컨텍스트로 모으지만, 모든 정보는 모델의 context window 안에 들어가야 합니다. 긴 작업에서는 Codex가 관련 정보를 요약해 compact할 수 있고, CLI에서는 codex resume으로 이전 세션을 이어갈 수도 있습니다.
그래서 긴 작업의 품질은 “처음 프롬프트를 잘 썼는가”만으로 결정되지 않습니다. 다음 턴이 바로 이어서 움직일 수 있는 인계 메모가 있는가가 중요합니다.
한 줄 요약
긴 Codex 작업은 대화 전체를 다시 읽게 만들지 말고, 의도, 현재 상태, 검증 증거, 다음 행동을 짧게 남겨야 합니다.
컨텍스트는 무한하지 않다
Codex는 작업하면서 파일, 명령 출력, 브라우저 상태, 사용자의 추가 지시를 계속 모읍니다. 하지만 thread 안의 모든 정보는 context window에 맞아야 합니다. 길어지면 요약과 압축이 들어갈 수 있고, 압축은 유용하지만 세부사항을 영원히 보존하는 보관소가 아닙니다.
실무에서는 아래 정보를 대화 흐름에만 묻어두면 안 됩니다.
정보 | 묻히면 생기는 문제 |
|---|---|
완료 기준 | 무엇을 끝으로 볼지 다시 추측함 |
변경 파일 | 같은 파일을 재탐색하거나 중복 수정함 |
검증 결과 | 이미 실패한 명령을 반복하거나 성공을 과신함 |
외부 게시/배포 상태 | 실제 반영 여부를 놓침 |
다음 행동 | 긴 요약은 있어도 실행이 멈춤 |
인계 메모는 모든 것을 저장하는 일기가 아닙니다. 다음 실행자가 바로 이어가기 위한 재시작 지시서입니다.
Mermaid로 보는 인계 위치 선택
아래는 초안에 남겨둔 Mermaid 의사결정 흐름입니다. 게시 본문에는 같은 흐름을 SVG로 렌더링해 넣습니다.
Mermaid source:
flowchart LR
A[다음 턴에도 필요한가?] --> B{매번 지켜야 하는 규칙인가?}
B -->|예| C[AGENTS.md나 체크인 문서에 둔다]
B -->|아니오| D{이번 실행 상태인가?}
D -->|예| E[memory.md나 최종 상태에 남긴다]
D -->|아니오| F[현재 소스에서 다시 확인한다]
판단 기준은 간단합니다. “앞으로도 항상 지켜야 한다”면 AGENTS.md나 체크인된 문서입니다. “이번 실행에서 어디까지 했는지”라면 자동화 메모리나 최종 상태 보고입니다. “지금 바뀌었을 수 있는 사실”이라면 메모리보다 현재 소스 확인이 우선입니다.
좋은 인계 메모의 네 칸
긴 작업을 멈추기 전에 아래 네 칸만 채워도 다음 실행 품질이 크게 달라집니다.
칸 | 써야 할 내용 | 나쁜 예 | 좋은 예 |
|---|---|---|---|
의도 | 끝났다고 말할 조건 | “잘 마무리하기” | “공개 API에서 status 200, 이미지 2개, codex directory 확인” |
상태 | 현재까지 한 일 | “거의 됨” | “초안과 payload 생성 완료, 게시 API는 401” |
증거 | 검증 결과 | “확인함” | “ |
다음 행동 | 바로 할 한 가지 | “계속 진행” | “로그인된 Chrome에서 디렉토리 codex 선택 후 게시” |
이 네 칸은 사람에게도 좋지만 Codex에게 특히 좋습니다. 모델이 긴 대화에서 분위기를 추론하게 만드는 대신, 작업 상태를 구조화된 사실로 줍니다.
자동화는 메모리를 더 엄격하게 써야 한다
Codex automations는 반복 작업을 백그라운드에서 실행하고, 결과가 있으면 inbox에 남깁니다. 프로젝트 자동화는 선택한 프로젝트가 디스크에 있어야 하고, Git 저장소에서는 로컬 프로젝트나 별도 worktree에서 실행할 수 있습니다. 또 자동화는 기본 sandbox 설정을 따르므로 unattended 작업에서는 권한과 실패 처리 기준을 더 명확히 해야 합니다.
자동화 메모리에 적을 내용은 감상이 아니라 복구 정보입니다.
Run summary:
- target:
- files created:
- verification passed:
- blocker:
- next safe recovery:
- run time:예를 들어 커뮤니티 글 게시 자동화라면 “글 좋았음”보다 “DAKER API가 401이라 Chrome UI 게시로 전환했고, 디렉토리 선택 확인 전 멈춤”이 훨씬 유용합니다. 다음 자동화는 이 문장을 보고 같은 실패를 반복하지 않을 수 있습니다.
AGENTS.md와 메모리를 섞지 말자
Codex manual은 AGENTS.md를 저장소에서 Codex가 자동으로 읽는 지속 지침으로 설명합니다. 전역, 프로젝트, 하위 디렉토리 지침이 계층으로 합쳐지고, 더 가까운 파일이 더 구체적인 규칙을 제공합니다. 반면 실행 메모리는 특정 run의 상태를 이어받기 위한 기록입니다.
따라서 아래처럼 분리하는 편이 안정적입니다.
넣을 곳 | 적합한 내용 |
|---|---|
프롬프트 | 이번에만 적용할 요구사항 |
| 저장소 전체 또는 하위 디렉토리의 지속 규칙 |
자동화 memory.md | 지난 실행의 결과, blocker, 다음 복구 단계 |
현재 파일/API | 바뀔 수 있는 최신 사실 |
최종 답변 | 사용자가 지금 알아야 할 결과와 검증 증거 |
규칙을 메모리에만 남기면 다음 작업자가 못 볼 수 있습니다. 반대로 일시적인 실패 상태를 AGENTS.md에 넣으면 오래된 규칙이 되어버립니다.
바로 쓰는 인계 템플릿
긴 Codex 작업을 멈추거나 다른 thread로 넘길 때는 아래 템플릿을 그대로 붙여도 됩니다.
인계 메모:
- 목표:
- 완료 기준:
- 현재까지 한 일:
- 변경/생성 파일:
- 검증:
- 실패/주의:
- 다음 한 가지 행동:
- 절대 반복하지 말 것:여기서 “다음 한 가지 행동”이 중요합니다. 다음 행동이 여러 개면 Codex는 다시 계획부터 해야 합니다. 바로 이어가야 하는 상황에서는 가장 작은 실행 단위 하나를 남기는 편이 낫습니다.
예시: 게시 자동화 인계
나쁜 인계:
초안은 대충 만들었고 게시만 하면 됨.좋은 인계:
목표: Codex tools series 20을 DAKER codex 디렉토리에 게시.
현재: draft와 payload 생성 완료. payload directorySlug=codex.
검증: payload에 data:image/svg+xml 3개, Mermaid source 텍스트 1개 포함.
주의: direct API 401이면 Chrome UI에서 디렉토리 dropdown으로 codex를 직접 선택해야 함.
다음 행동: Chrome UI 게시 후 공개 API와 codex listing으로 slug 확인.이 정도면 다음 실행자는 앞의 대화 전체를 몰라도 이어갈 수 있습니다. 특히 외부 서비스 작업에서는 “어떤 표면에서 막혔는지”와 “어디서 확인해야 하는지”가 반드시 들어가야 합니다.
시니어 엔지니어의 기준
긴 작업에서 컨텍스트 관리는 기억력이 아니라 운영 방식입니다. 좋은 Codex 사용자는 “더 길게 설명하는 사람”이 아니라 “다음 실행이 실패하지 않게 상태를 남기는 사람”입니다.
오늘부터 긴 작업이 30분을 넘기거나 파일을 여러 개 건드리면, 중간에 한 번만이라도 인계 메모를 쓰세요.
다음 사람이 이 문장만 보고 이어갈 수 있는가?대답이 아니오라면 아직 정리가 끝난 것이 아닙니다. Codex가 compact하거나 resume하더라도, 좋은 인계 메모는 작업을 다시 살리는 가장 값싼 보험입니다.
참고: OpenAI Codex manual의 Prompting, Automations, AGENTS.md 섹션을 2026-06-13 Asia/Seoul 기준으로 확인했습니다.