Codex task brief로 프롬프트 작업 인수인계서 만들기

1편에서는 AI와의 관계를 위임자 관점으로 다시 잡았다.

2편에서는 그 첫 번째 운영 장치로 Codex 완료 Slack 알림을 붙였다. 위임자가 모든 작업 옆에 붙어 있지 않으려면, 먼저 완료 신호와 보고 체계가 필요했기 때문이다.

그다음 질문은 프롬프트였다.

AI에게 일을 맡기려면 결국 요청을 해야 한다. 그런데 여러 repository를 오가며 작업하다 보니, 좋은 프롬프트는 멋진 문장 문제가 아니었다. 더 정확히는 작업 인수인계 문제였다.

그래서 프롬프트를 Codex task brief로 바꾸기 시작했다.

좋은 프롬프트는 부탁문이 아니라 작업 인수인계서였다

처음에는 Codex에게 일을 더 잘 시키는 문장을 찾고 있었다.

어떤 역할을 주면 좋을까. 어떤 식으로 요구하면 더 정확할까. 어떤 skill catalog를 참고하면 좋을까. 이런 질문에서 시작했다.

하지만 codex prompt writing study plan을 정리하면서 방향이 바뀌었다.

Codex가 실패하는 지점은 대개 문장이 덜 예뻐서가 아니었다. 읽어야 할 문서가 빠졌거나, source-of-truth 경계가 불분명했거나, 검증 기준이 없거나, 회사 도메인에서 보내면 안 되는 정보가 명시되지 않은 경우가 더 위험했다.

그래서 프롬프트는 부탁문이 아니라 작업 인수인계서가 되어야 했다.

목표:
도메인:
source-of-truth:
먼저 읽을 파일:
제약:
작업 방식:
검증:
최종 산출물:

이 구조가 Codex task brief의 시작이었다.

위임에는 목표보다 경계가 먼저 필요했다

목표만 있으면 Codex는 움직일 수 있다.

하지만 위임하려면 목표만으로는 부족하다. 목표는 어디로 가야 하는지 알려 주지만, 경계는 어디로 가면 안 되는지 알려 준다.

내 작업에서는 이 경계가 특히 중요했다.

• ai-survival-log에서는 wiki/가 source-of-truth다.
• raw/는 원본 계층이고, 해설은 wiki/에서 해야 한다.
• output/은 재생성 가능한 artifact다.
• 회사 원문, source trace, DB 정보, credential은 개인 wiki에 들어오면 안 된다.
• 외부 write action은 dry-run과 실제 실행을 분리해야 한다.

이런 규칙은 매번 대화 중간에 떠올리면 늦다.

처음부터 task brief에 들어가야 한다. 그래야 Codex가 "잘하는 것"보다 "안전하게 하는 것"을 먼저 맞춘다.

Slack notify는 task brief가 왜 필요한지 보여준 사례였다

Slack notify 작업은 좋은 테스트 케이스였다.

짧게 말하면 이렇게 요청할 수 있다.

Codex 작업이 끝나면 Slack으로 알려줘.

하지만 실제 작업으로 바꾸면 질문이 많아진다.

• Codex의 notify를 쓸 것인가, hook을 쓸 것인가?
• Slack webhook URL은 어디에 둘 것인가?
• 회사 repository도 알림 대상에 포함할 것인가?
• Slack payload에 assistant 답변 본문을 넣어도 되는가?
• webhook secret이 없으면 무엇까지 검증할 수 있는가?

이 질문들은 세부 구현이 아니라 위임의 조건이다.

그래서 Slack notify task brief에는 목표보다 제약과 검증이 중요했다.

제약:
- Slack webhook URL, token, credential은 repo 파일에 저장하지 않는다.
- 회사 원문, source trace, DB 정보, 검수 증적, assistant 답변 본문은 Slack payload에 넣지 않는다.
- 실제 전송은 webhook secret이 준비된 뒤에만 검증한다.

검증:
- syntax check
- dry-run payload 확인
- secret pattern scan
- Codex config notify 설정 확인

이렇게 적고 나니 작업이 달라졌다.

Slack 알림을 붙이는 일이 아니라, 외부 서비스와 회사 경계가 있는 작업을 Codex에게 어떻게 위임할지 정리하는 실습이 됐다.

task brief는 매번 설명하던 것을 재사용 가능한 레인으로 바꾼다

좋은 요청을 한 번 쓰는 것은 어렵지 않다.

문제는 반복이다. 같은 설명을 매번 다시 해야 한다면, 그것은 아직 시스템이 아니다.

task brief는 반복되는 설명을 양식으로 바꾼다.

• 먼저 읽을 파일
• 건드리면 안 되는 경계
• 검증 명령
• 최종 답변에 포함할 항목
• 실패했을 때 남길 리스크

이 항목들이 고정되면, 요청 품질이 내 컨디션에 덜 흔들린다.

더 나아가 같은 task brief 패턴이 여러 번 반복되면 skill 후보가 된다. 실제로 long-term-plan-review와 long-term-plan-update는 그렇게 생겼다. 매일 시작할 때 계획을 읽고, 매일 끝날 때 완료와 차단과 블로그 기록을 업데이트하는 일이 반복되었기 때문이다.

프롬프트 작성 레인은 AI Native 작업의 입구가 된다

이제 내게 프롬프트 작성 레인은 문장 연습장이 아니다.

AI에게 일을 맡기기 전 통과하는 입구다.

좋은 task brief를 통과한 작업은 다르게 시작한다. Codex는 먼저 어떤 repository인지 확인하고, 어떤 문서를 읽어야 하는지 알고, 어디까지 고쳐도 되는지 이해하고, 마지막에 어떤 검증을 해야 하는지 안다.

이 입구가 생기면 뒤쪽 자동화도 안정된다.

PR summary 고도화도, 회귀 테스트 실패 분석 봇도, deploy checklist도 결국 같은 질문을 통과해야 한다.

무엇을 맡기는가?
어디까지 맡기는가?
무엇을 보내면 안 되는가?
어떻게 검증하는가?
무엇이 완료인가?

이 질문들이 task brief에 들어가면, AI에게 일을 맡기는 방식이 조금씩 바뀐다.

프롬프트는 대화의 시작이 아니라 위임 계약의 시작이 된다.

다음 글은 PR summary를 리뷰 라우터로 보는 이야기다

1편의 핵심은 위임자가 되기 위한 시스템이었다.

2편의 핵심은 완료 신호와 보고 체계였다.

3편의 핵심은 작업을 맡기기 전의 인수인계 양식이다.

다음 글에서는 이 흐름을 PR로 가져간다. PR summary를 단순 요약이나 평가가 아니라, reviewer가 어디를 먼저 봐야 하는지 알려 주는 routing 장치로 보는 이야기다.

AI에게 일을 맡겼다면, 그 결과를 사람이 검토할 수 있는 형태로 돌려받아야 한다. PR summary는 그 다음 단계의 입구다.