개발 기록
Codex 작업 규칙을 명령마다 찾아 붙이게 만든 기록
Codex에 작업을 맡기다 보면 같은 규칙을 여러 번 설명했는데도 실행 단계에서 빠지는 일이 있습니다. 이 글은 그 문제를 줄이려고, 명령을 보낼 때 관련 규칙을 먼저 찾아 함께 전달하도록 바꾼 과정을 기록한 것입니다.
위 그림은 실제 화면이나 자료가 아니라, 흐름을 설명하려고 그린 도해입니다.
겪은 문제
작업 규칙은 AGENTS.md 파일에 모아 두고 있습니다. 어떤 작업에서 무엇을 확인해야 하는지, 어떤 출처를 따라야 하는지 같은 내용입니다. 이 파일은 지금도 공통 규칙의 원본입니다.
문제는 규칙이 쌓일수록 지금 하는 작업에 꼭 필요한 조항이 실행에서 빠지는 일이 생겼다는 점입니다. 다시 설명하면 그때는 지켜졌지만, 다음 작업에서는 또 같은 설명이 필요했습니다. 정확한 원인까지 확인한 것은 아닙니다. 다만 사람이 매번 규칙을 상기시키는 방식에는 한계가 있다고 판단했습니다.
RAG를 운영 지침에 적용하기
RAG는 필요한 자료를 검색해서 답변이나 작업의 문맥에 보태는 방식입니다. 보통은 문서나 지식 자료를 대상으로 쓰는데, 이번에는 검색 대상을 제 운영 지침으로 잡았습니다.
바뀐 흐름은 이렇습니다.
- 명령을 보냅니다.
- 명령의 작업 종류와 키워드로 관련 규칙을 검색합니다.
- 필요한 조항과 그 출처 위치를 고릅니다.
- 고른 내용을 명령에 자동으로 붙입니다.
- Codex가 그 내용을 보고 작업을 실행하고, 결과를 확인합니다.
Codex에는 UserPromptSubmit이라는 공식 훅 이벤트가 있습니다. 사용자의 명령을 받았을 때 추가 문맥을 전달할 수 있는 기능이고, 이 연결 지점을 사용했습니다. 훅은 hooks.json 파일로 설정합니다.
의미검색이 아니라 로컬 검색입니다
이름이 RAG라서 임베딩이나 벡터 DB를 쓰는 의미검색을 떠올리기 쉽습니다. 이번 구현은 그렇지 않습니다. 내 컴퓨터에서 작업 종류, 키워드, 관련 조항을 찾는 단순한 방식이고, 별도의 유료 API도 쓰지 않습니다.
이 방식은 이해하기 쉽고 왜 그 조항이 골라졌는지 따라가기 쉽습니다. 대신 낯선 표현으로 명령하면 관련 규칙을 놓칠 수 있습니다.
원본은 그대로 두고, 붙이는 양만 줄였습니다
AGENTS.md는 없애거나 다른 것으로 바꾸지 않았습니다. 기본으로 적용되는 공통 규칙은 그대로 유지됩니다. 바뀐 것은 명령마다 새로 덧붙이는 문맥입니다. 전체 규칙을 다시 붙이는 대신 관련 있는 원문 조항과 출처 위치만 붙입니다.
그래서 "기본 프롬프트 전체가 줄었다"고 말할 수는 없습니다. 줄어든 것은 명령마다 추가로 붙이는 부분뿐입니다.
붙이는 양에는 상한을 두었습니다. 조항은 최대 8개, 추가 문맥은 총 4,800자까지입니다. 필수 조항이 길어서 상한 안에 들어가지 못하면, 빠졌다는 사실과 원문을 직접 볼 수 있는 참조 목록을 함께 연결합니다. 조용히 잘려 나가는 일이 없게 하려는 장치입니다.
후속 지시와 상태 질문
사람은 매번 완전한 문장으로 명령하지 않습니다. "계속해", "그 방식으로 구현해" 같은 말은 그 자체로는 어떤 작업인지 알 수 없습니다. 그래서 이런 후속 지시는 바로 앞 작업의 종류를 이어받게 했습니다.
반대로 "지금 어디까지 됐어?" 같은 상태 질문은 기존 작업의 검색 문맥을 지우지 않습니다. 질문 하나 때문에 진행 중이던 작업의 규칙이 사라지면 곤란하기 때문입니다.
우선순위
규칙 원본이 바뀌면 다음 검색에서 새 내용을 읽습니다. 따로 갱신 작업을 하지 않아도 됩니다.
또 검색에서 뽑히지 않은 기존 지침이 효력을 잃는 것은 아닙니다. 붙어 온 조항은 보강입니다. 상위 지침과 권한 통제 안에서 최신 사용자 직접 지시를 우선합니다.
기록에 남기는 것
이 검색기가 따로 남기는 기록에는 명령 원문을 저장하지 않습니다. 어떤 조항이 선택되었는지 위치와 식별자, 길이 같은 확인용 정보만 남깁니다. 이것은 이번 검색기의 기록에 대한 설명입니다. Codex 제품 전체가 대화를 저장하지 않는다는 뜻은 아닙니다.
오탐과 예외 처리
만들면서 점검한 문제도 있습니다. 영문 단어의 일부분이 겹쳐서 관련 없는 규칙이 선택되는 오탐, 상태 파일이 손상된 경우, 첨부 길이가 상한을 넘는 경우, 출처 경계와 문맥이 서로 섞이는 문제입니다. 이런 경우를 검토하고 보완했습니다.
어디까지 확인했나
두 단계로 확인했습니다.
첫째, 앱에 포함된 실행 프로그램으로 홈페이지 작업 예시, 후속 명령, 조사 작업 예시를 보냈습니다. 규칙 검색, 첨부, 모델이 원문을 인용해 답하는 것까지 이어지는 것을 보았습니다. 다만 실제 홈페이지를 고치거나 배포한 검증은 아닙니다.
둘째, 2026년 10월 28일 앱을 다시 시작한 뒤 제가 보낸 실제 확인 명령에 6개 조항, 1,629자가 자동으로 붙었습니다. 모델이 받은 내용과 실행 기록을 맞춰 보아, 실제 Codex 앱의 입력 경로에서도 동작하는 것을 확인했습니다.
한계
- 모든 종류의 명령에서 완벽하게 검색되고 지켜진다고 보장할 수 없습니다. 작업 유형과 키워드를 기준으로 하기 때문에 낯선 표현에서는 관련 규칙을 놓칠 수 있습니다.
- 규칙을 붙여 주는 것과 끝까지 지키는 것은 다른 문제입니다. 권한과 승인 통제, 최종 결과 확인은 여전히 필요합니다.
- 오류가 얼마나 줄었는지, 속도가 얼마나 빨라졌는지, 토큰이 얼마나 절감되었는지는 측정하지 않았습니다.