코덱스 툴 사용법 19: 메모리와 규칙을 분리하기 | DAKER 커뮤니티
코덱스 툴 사용법 19: 메모리와 규칙을 분리하기
Codex를 오래 쓰다 보면 “이건 다음에도 기억해줘”라고 말하고 싶어집니다. 반복되는 프로젝트 맥락, 선호하는 보고 방식, 매번 쓰는 게시 절차가 생기기 때문입니다. 하지만 여기서 한 가지를 구분해야 합니다. 기억하면 좋은 맥락과 반드시 지켜야 하는 규칙은 다릅니다.
OpenAI Codex manual 기준으로 Memories는 안정적인 선호, 반복 워크플로우, 기술 스택, 프로젝트 관례, 알려진 함정을 다음 작업에 활용하기 위한 기능입니다. 반면 팀이 반드시 지켜야 하는 명령, 검증 단계, 코드 스타일은 AGENTS.md나 체크인된 문서에 두는 것이 맞고, 기계적으로 막아야 하는 것은 hooks나 rules에 가깝습니다.
한 줄 요약
메모리는 “다음에 빨리 떠올리기 위한 힌트”이고, AGENTS.md와 hooks는 “매번 지켜야 하는 운영 계약”입니다. 잊으면 문제가 생기는 것은 메모리에만 맡기지 마세요.
메모리에 넣어도 되는 것
메모리는 반복될수록 가치가 커지는 짧고 안정적인 사실에 맞습니다.
넣어도 되는 정보 | 예시 |
|---|---|
선호하는 출력 방식 | “최종 답변은 짧게, 검증 결과를 함께 적는다” |
반복 워크플로우 | “DAKER 글은 초안, payload, 공개 API 검증 순서로 처리한다” |
기술 스택 맥락 | “이 저장소의 게시 payload는 |
알려진 함정 | “DAKER rich editor는 HTML paste 때 SVG img를 제거할 수 있다” |
자주 쓰는 용어 | “이 커뮤니티 시리즈는 codex 디렉토리에 올린다” |
좋은 메모리는 짧고 재사용 가능합니다. “어제 3시간 동안 어떤 대화를 했는지”보다 “이 프로젝트에서 반복되는 의사결정 기준은 무엇인지”가 더 좋습니다.
메모리에만 넣으면 안 되는 것
반대로, 아래 정보는 메모리에만 두면 안 됩니다.
정보 | 더 나은 위치 |
|---|---|
빌드/테스트 필수 명령 |
|
게시 전 필수 검증 | 자동화 프롬프트, script, checklist |
보안 금지 규칙 | hooks, rules, policy 문서 |
비밀값, 쿠키, 토큰 | 절대 프롬프트/메모리에 저장하지 않음 |
오늘만 유효한 상태 | 현재 파일, 이슈, API 응답, 로그 |
특히 비밀값은 “기억해줘”가 아니라 “출력하지 말고 인증 표면에만 둬”가 맞습니다. Codex manual도 memories를 팀 필수 규칙의 유일한 저장소로 보지 말고, 필요한 팀 가이드는 AGENTS.md나 체크인된 문서에 두라고 설명합니다.
Mermaid로 보는 판단 흐름
아래는 같은 흐름을 SVG로 렌더링한 의사결정 흐름입니다.
이 흐름에서 중요한 질문은 “안 지키면 실패하는가?”입니다. 실패한다면 기억이 아니라 규칙입니다. 기억은 도움말이고, 규칙은 운영 계약입니다.
자동화에는 메모리보다 프롬프트 계약이 먼저다
Codex automations는 반복 작업을 백그라운드에서 실행하고, 결과가 있으면 inbox에 남깁니다. 프로젝트 자동화는 선택한 프로젝트가 디스크에 있어야 하고, Git 저장소에서는 로컬 프로젝트 또는 별도 worktree에서 실행할 수 있습니다. 또 자동화는 기본 sandbox 설정을 따르므로, unattended 작업일수록 prompt와 권한 경계가 명확해야 합니다.
그래서 자동화 프롬프트에는 메모리에 기대는 문장보다 아래 같은 계약이 들어가야 합니다.
매 실행마다:
- 기존 번호와 slug를 현재 drafts에서 확인한다.
- codex directoryId/directorySlug를 frontmatter와 payload에 저장한다.
- 게시 후 public API와 directory listing으로 검증한다.
- 실패하면 blocker 원인과 수동 복구 절차를 memory.md에 기록한다.메모리는 “지난번에 어디까지 했는지”를 떠올리는 데 유용합니다. 하지만 자동화가 반드시 따라야 할 순서와 실패 처리 기준은 매 실행 프롬프트와 스크립트에 있어야 합니다.
Hooks는 기억이 아니라 안전장치다
OpenAI Codex manual은 hooks를 agentic loop에 스크립트를 주입하는 확장 프레임워크로 설명합니다. 예를 들어 프롬프트에 API key가 붙어 들어오는 것을 막거나, turn stop 시 검증 조건을 강제하거나, 특정 디렉토리에서 추가 지침을 넣을 수 있습니다.
따라서 “항상 비밀값을 출력하지 마”는 메모리보다 hook이나 rule에 더 가깝습니다. 메모리는 “사용자가 짧은 최종 보고를 선호한다”처럼 실패 비용이 낮은 반복 맥락에 좋습니다. 반대로 보안, 배포, 게시, 결제, 삭제처럼 실패 비용이 큰 행동은 hook, rule, approval, script 검증으로 닫아야 합니다.
바로 쓰는 메모리 정리 템플릿
반복 업무가 끝났을 때는 아래 형식으로 정리하면 다음 실행이 훨씬 안정적입니다.
메모리 후보:
- 반복될 사실:
- 적용 범위: 개인 / 프로젝트 / 자동화 / 특정 사이트
- 출처: 파일, 공식 문서, 공개 API, 사용자 지시
- 저장해도 안전한가: 예 / 아니오
- 규칙으로 승격해야 하는가: 예 / 아니오여기서 “규칙으로 승격해야 하는가”가 예라면 메모리에만 저장하지 마세요. AGENTS.md, 자동화 프롬프트, 스크립트, CI, hook 중 하나로 옮겨야 합니다.
나쁜 예와 좋은 예
나쁜 예:
앞으로 DAKER에 글 올릴 때 알아서 잘 해줘.이 문장은 너무 넓습니다. 다음 실행에서 디렉토리, 번호, slug, 이미지, 검증 기준을 놓칠 수 있습니다.
좋은 예:
DAKER Codex 시리즈는 codex 디렉토리에 게시한다.
directoryId는 695add24-271f-4727-bef5-77db6b6bf0b7이고, directorySlug는 codex다.
게시 전 payload에 directoryId가 있는지 확인하고, 게시 후 public API와 codex listing으로 검증한다.이 문장은 메모리로도 유용하지만, 게시 실패 비용이 있으므로 자동화 프롬프트와 frontmatter에도 반복해서 들어가야 합니다.
시니어 엔지니어의 기준
메모리는 편합니다. 하지만 편하다는 이유로 규칙을 메모리에 숨기면 팀 운영이 불안정해집니다. 새 사람이 들어와도, 새 세션에서 시작해도, 자동화가 밤에 돌아도 지켜져야 하는 것은 파일과 스크립트에 남겨야 합니다.
오늘 Codex에 “기억해줘”라고 말하기 전에 이 질문을 먼저 하세요.
이 정보는 잊어도 조금 느려질 뿐인가, 아니면 실패하는가?조금 느려질 뿐이면 메모리 후보입니다. 실패한다면 규칙, hook, script, CI로 옮기세요. 이 구분이 Codex를 개인 비서에서 운영 가능한 개발 도구로 바꾸는 기준선입니다.
참고: OpenAI Codex manual의 Automations, Hooks, Memories 섹션을 2026-06-12 Asia/Seoul 기준으로 확인했습니다.