Multi-repo AI Native 자동화 실습 02. Codex 완료 Slack 알림

1편에서는 AI와의 관계를 파트너가 아니라 위임자로 다시 정의했습니다.

그 관점에서 보면, 다음 질문은 자연스럽습니다.

위임자가 가장 먼저 만들어야 하는 운영 장치는 무엇일까?

처음에는 회귀 테스트 실패 분석 봇이나 PR summary 고도화처럼 더 커 보이는 작업을 먼저 해야 할 것 같았습니다. 실제로 둘 다 중요합니다. 하지만 중장기계획을 sprint sheet처럼 관리하고, 하루에 2~3개 작업을 병렬로 돌리려면 더 앞에 필요한 것이 있었습니다.

작업이 끝났다는 신호.

그래서 Codex 완료 Slack 알림 설정을 최우선 P0로 올렸습니다.

완료 신호가 없으면 위임은 다시 감시가 됩니다

한 작업만 할 때는 알림이 없어도 괜찮습니다.

Codex가 끝날 때까지 기다리면 되고, 결과를 읽고 다음 일을 하면 됩니다. 하지만 병렬 작업을 시작하면 상황이 달라집니다. 문서 초안을 만들고, 로컬 설정을 바꾸고, 다른 repository의 계획을 읽는 일이 동시에 열립니다.

이때 완료 신호가 없으면 위임은 다시 감시가 됩니다.

• 어떤 작업이 끝났는지 계속 확인해야 합니다.
• 어떤 작업이 dry-run까지만 됐는지 기억해야 합니다.
• 어떤 작업은 secret이 없어서 실제 전송을 못 했는지 따로 추적해야 합니다.
• 어떤 작업은 중장기계획에 반영해야 하는지 다시 찾아야 합니다.

이건 위임이 아닙니다.

그냥 대화창과 터미널을 계속 지켜보는 일에 가깝습니다.

위임자가 되려면 결과를 기다리는 구조가 필요합니다. 그래서 완료 신호는 사소한 편의 기능이 아니라 운영 조건이 됐습니다.

작은 알림에도 좋은 작업 지시의 조건이 다 들어 있었습니다

Slack 알림 작업은 프롬프트 작성 실습으로도 좋았습니다.

단순한 요청은 이렇게 쓸 수 있습니다.

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

하지만 실제 작업으로 바꾸면 곧바로 질문이 늘어납니다.

• Codex의 어떤 lifecycle 표면을 쓸 것인가?
• Slack webhook secret은 어디에 둘 것인가?
• 회사 repository에서도 같은 알림을 받을 것인가?
• Slack payload에 assistant 답변 본문을 넣을 것인가?
• webhook이 없을 때 검증은 어떻게 할 것인가?

이 질문들은 프롬프트가 부실해서 생긴 문제가 아닙니다. 작업 자체가 가진 경계입니다.

그래서 codex prompt writing study plan의 Codex task brief 구조가 필요했습니다.

목표:
- Codex 작업 완료 이벤트를 Slack으로 알립니다.

대상:
- ai-survival-log
- ai-survival-log-site
- shared-agent-harness
- company* repository

제약:
- 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 payload는 작아야 보고 체계로 오래 쓸 수 있습니다

처음에는 Slack에 많은 정보를 보내고 싶어집니다.

마지막 assistant 답변, 변경 파일 목록, 실패 로그, 상세 요약까지 보내면 편해 보입니다. 하지만 기본값은 작아야 합니다.

이번 설계의 기본 payload는 프로젝트명, 상대 디렉터리, 이벤트, 모델, 짧은 session/turn ID 정도로 제한했습니다. 사용자 프롬프트와 assistant 답변 본문은 기본으로 보내지 않습니다. 회사 원문, source trace, DB 정보, review/test evidence도 보내지 않습니다.

이 선택은 보수적이지만 오래 갑니다.

Slack은 source-of-truth가 아닙니다. Slack은 상태 신호입니다. 상세 내용은 각 repository와 wiki, PR, 검증 기록에 남아야 합니다.

알림은 "끝났다"를 알려 주고, 판단과 기록은 원래 있어야 할 곳에 남깁니다. 이 분리가 있어야 개인 프로젝트와 회사 도메인을 같은 운영 루프 안에서 다룰 수 있습니다.

dry-run과 실제 전송을 나누면 외부 서비스가 작업을 막지 않습니다

외부 서비스가 들어오면 검증이 애매해집니다.

webhook secret이 없으면 실제 Slack 전송은 검증할 수 없습니다. 그렇다고 작업 전체를 멈추면 문서, 스크립트, config 검증까지 모두 막힙니다.

그래서 검증을 둘로 나눴습니다.

1. script syntax check
2. dry-run payload 확인
3. secret pattern scan
4. Codex config notify 설정 확인
5. webhook secret이 준비된 뒤 실제 Slack 전송

실제 전송은 마지막 단계입니다.

그 전에도 확인할 수 있는 것이 많습니다. dry-run payload가 맞고, secret이 파일에 남지 않았고, config에 notify가 들어갔다면 대부분의 설계는 검증된 것입니다.

이 방식은 앞으로 다른 외부 action에도 그대로 쓸 수 있습니다. 먼저 dry-run으로 구조를 확인하고, 실제 write나 send는 마지막 human gate 뒤에 둡니다.

중장기계획은 알림을 운영 규칙으로 받아들였습니다

Slack 알림을 붙이면서 장기 운영 계획 문서도 바뀌었습니다.

이 문서는 단순한 할 일 목록이 아닙니다. 매일 작업 시작 전에 읽고, 작업 종료 후 업데이트하는 프로젝트 생명주기 문서입니다. 그래서 알림 작업도 "있으면 좋은 기능"이 아니라 daily loop의 일부가 됐습니다.

현재 운영 규칙은 단순합니다.

• 작업 시작 전 long-term-plan-review로 오늘 병렬 실행 가능한 2~3개 작업을 고릅니다.
• 작업 종료 후 long-term-plan-update로 완료, 진행, 차단, 블로그 기록 포인트를 업데이트합니다.
• Codex가 끝나면 Slack 알림으로 완료 신호를 받습니다.
• 중요한 구조 변경은 사람용 계획서와 Codex용 compact brief에 함께 반영합니다.

이렇게 보면 Slack 알림은 자동화 기능이라기보다 운영 리듬의 한 부분입니다.

작은 완료 신호가 다음 자동화를 가능하게 합니다

Slack 알림 자체가 대단한 자동화는 아닙니다.

하지만 이 알림이 있어야 다음 자동화가 편해집니다. 회귀 테스트 실패 분석 봇을 돌려도, PR summary 고도화 작업을 맡겨도, context budget과 Git safety guard를 다듬어도, 먼저 알아야 하는 것은 같습니다.

끝났는가.

끝났다면 무엇을 검수해야 하는가.

막혔다면 어디서 막혔는가.

위임자는 모든 일을 직접 붙잡고 있지 않습니다. 대신 결과가 돌아오는 길을 만듭니다. Codex Slack notify는 그 길의 첫 번째 표지판입니다.

다음 글에서는 이 완료 신호를 만든 뒤, 프롬프트 작성 레인이 왜 Codex task brief로 정리되어야 했는지로 넘어갑니다.