Automations로 반복 개발 업무 자동화하기

자동화는 "Codex에게 매일 시키는 일"을 없애는 기능이다

앱을 만드는 동안 Codex는 아주 든든한 페어 프로그래머가 되어 준다. "이 버그 고쳐줘", "이 컴포넌트 리팩터링해줘", "테스트 추가해줘"처럼 요청하면 코드를 읽고, 수정하고, 설명까지 해 준다. 그런데 앱을 만든 뒤에도 개발자의 일은 끝나지 않는다. 오히려 그때부터 반복 업무가 시작된다.

아침마다 최근 커밋을 훑어보며 실수한 부분이 없는지 확인해야 한다. 누군가 console.log를 남긴 채 PR을 머지했는지 봐야 한다. 의존성 취약점이 새로 나왔는지 점검해야 한다. 테스트가 깨졌는지, 커버리지가 떨어졌는지, 지난주 PR과 이슈에서 중요한 변경이 무엇이었는지도 정리해야 한다.

이런 일은 중요하지만 재미있지는 않다. 더 큰 문제는 "잊기 쉽다"는 점이다. 금요일 오후에는 의존성 점검을 건너뛰고 싶고, 월요일 아침에는 지난주 PR을 다시 읽을 기운이 없다. Codex Automations는 바로 이 지점을 해결한다. 매번 사용자가 채팅창을 열고 같은 프롬프트를 입력하는 대신, 정해진 일정에 따라 Codex가 새 작업을 시작하고 결과를 Triage 또는 Review Queue에 모아 둔다.¹

여기서 중요한 말은 "자동으로 실행된다"가 아니라 "검토할 수 있는 결과로 돌아온다"이다. Automations는 코드를 몰래 바꾸고 배포하는 마법 버튼이 아니다. 좋은 자동화는 마치 잘 정리된 개발 inbox처럼 동작한다. 아침에 Codex App을 열면 "이 PR에서 잠재 버그 2개 발견", "결제 모듈 테스트 커버리지 하락", "의존성 취약점 1개 높음" 같은 결과가 우선순위와 함께 도착해 있다.

이 장에서는 초보자도 바로 적용할 수 있는 자동화부터 시작한다. 목표는 거창한 완전 자율 개발이 아니다. 반복되는 점검, 요약, 리뷰, 리포트 업무를 Codex에게 맡기고, 사람은 Review Queue에서 판단과 승인을 담당하는 안전한 운영 흐름을 만드는 것이다.

일반 채팅과 Automations는 무엇이 다를까

일반 채팅에서는 사용자가 대화를 이어 간다. 예를 들어 "최근 커밋 확인해줘"라고 말하면 Codex가 답하고, 사용자는 다시 "그중 위험한 것만 고쳐줘"라고 요청한다. 맥락이 같은 스레드 안에 쌓이고, 사용자는 실행 흐름을 계속 지켜본다.

Automations는 다르다. 정해진 시간마다 독립적인 실행이 시작된다. 특히 standalone automation은 매번 새 작업으로 출발해서 결과를 Triage에 보고하는 구조다. 매 실행이 서로 강하게 이어져야 하는 대화형 작업보다는, 매일 또는 매주 같은 기준으로 검사하는 정기 점검에 잘 맞는다.¹

초보자에게는 이렇게 구분하면 쉽다.

Automations의 장점은 일관성이다. 사람이 매번 같은 프롬프트를 기억해서 입력하지 않아도 된다. 한 번 잘 만들어 둔 프롬프트가 정해진 주기에 따라 실행되므로, 팀의 반복 점검 품질이 일정해진다.

또 하나의 장점은 결과가 흩어지지 않는다는 것이다. 자동화 실행 결과는 Triage 또는 Review Queue에 쌓인다. 결과가 있으면 확인하고, 별일이 없으면 자동으로 보관되거나 조용히 지나가도록 설계할 수 있다.² 이 구조 덕분에 Automations는 "알림"보다 한 단계 더 똑똑하다. 단순히 "무언가 발생했습니다"라고 알려 주는 것이 아니라, Codex가 직접 살펴보고, 분류하고, 원인을 추정하고, 필요한 경우 최소 수정안까지 준비해 온다.

첫 번째 Automation을 만들기 전에 정해야 할 것

처음부터 복잡한 자동화를 만들려고 하면 실패하기 쉽다. 좋은 자동화는 범위가 좁고, 반복 가능하며, 결과 형식이 분명하다. "우리 프로젝트를 매일 좋게 만들어줘"는 나쁜 자동화 프롬프트다. 너무 넓고, 무엇을 해야 완료인지 알 수 없다.

반대로 "매일 오전 9시에 최근 24시간 커밋을 확인하고, 런타임 오류 가능성이 있는 변경만 우선순위 순서로 요약해줘. 직접 수정하지 말고 필요한 경우 최소 수정 PR 초안을 제안해줘"는 훨씬 좋다.

자동화를 만들기 전에는 네 가지를 정해야 한다.

여기서 가장 중요한 것은 "행동"이다. 초보자는 처음부터 Codex에게 자동 수정 권한을 많이 주지 않는 편이 좋다. 처음에는 읽기 중심 자동화로 시작하자. 보고서를 잘 만드는지, 엉뚱한 파일을 건드리지 않는지, 같은 문제를 매일 반복 보고하지 않는지 확인한 뒤에 수정 권한을 조금씩 넓히면 된다.

일정은 어떻게 표현할까: cron을 겁내지 말자

Codex Automations에서는 기본 제공 일정뿐 아니라 custom schedule을 선택해 cron 문법으로 실행 주기를 직접 지정할 수 있다.¹ cron은 서버에서 오래전부터 쓰이던 일정 표현 방식이다. 처음 보면 암호처럼 보이지만, 자주 쓰는 패턴 몇 개만 알면 충분하다.

cron은 보통 다음 순서로 읽는다.

분 시 일 월 요일

예를 들어 0 9 * * 1-5는 "월요일부터 금요일까지 매일 오전 9시 0분"이라는 뜻이다. 0 2 * * 1은 "매주 월요일 새벽 2시"다. */30 * * * *는 "30분마다"다.

실전에서 자주 쓰는 일정은 다음과 같다.

초보자에게 권하는 첫 주기는 하루 한 번이다. 자동화가 너무 자주 돌면 결과가 쌓여서 오히려 피곤해진다. 처음에는 "매일 아침 한 번" 또는 "매주 월요일 한 번"처럼 사람이 실제로 검토할 수 있는 리듬에 맞추는 것이 좋다.

만들기 전에 반드시 수동으로 테스트한다

자동화에서 가장 흔한 실수는 프롬프트를 한 번도 검증하지 않고 바로 스케줄에 걸어 두는 것이다. 자동화는 사용자가 보지 않는 동안 실행된다. 그래서 프롬프트가 애매하면 Codex가 엉뚱한 파일을 수정하거나, 매번 너무 긴 보고서를 만들거나, 중요하지 않은 문제를 계속 크게 보고할 수 있다.

좋은 습관은 간단하다. 먼저 같은 프로젝트에서 일반 스레드를 만들고, 가능하면 worktree 모드로 실행한다. Automations도 Git 저장소에서는 격리된 작업 공간을 사용해 실행하는 경우가 많으므로, 실제 자동화와 비슷한 조건에서 시험하는 것이다.²

예를 들어 첫 자동화 프롬프트를 이렇게 테스트해 볼 수 있다.

최근 24시간 동안 main 브랜치에 들어온 커밋을 확인해줘.

목표:
- 런타임 오류 가능성이 있는 변경을 찾는다.
- console.log, 임시 TODO, 테스트 누락처럼 배포 전에 확인해야 할 실수를 찾는다.
- 직접 수정하지 말고 보고서만 작성한다.

출력 형식:
1. 가장 위험한 항목 3개 이하
2. 각 항목의 파일 경로와 근거
3. 권장 조치
4. 사람이 지금 확인해야 하는지 여부

제약:
- 코드 변경 금지
- 의존성 설치 금지
- 네트워크 접근 금지
- 추측이면 추측이라고 표시

이 프롬프트를 일반 스레드에서 실행한 뒤 결과를 본다. Codex가 너무 많은 항목을 보고한다면 "확실한 문제만"이라고 좁힌다. 반대로 중요한 버그를 놓쳤다면 "최근 수정된 API, 인증, 결제, 데이터 저장 로직을 우선 확인"처럼 관심 영역을 더해 준다.

프롬프트가 안정되면 그때 Automation으로 옮긴다. 자동화는 "처음부터 완벽하게 만드는 것"이 아니라 "수동으로 검증한 일을 일정에 올리는 것"에 가깝다.

초보자가 바로 쓰는 자동화 1: 매일 아침 최근 커밋 버그 스캔

가장 추천하는 첫 자동화는 최근 커밋 버그 스캔이다. 앱을 만들다 보면 어제는 멀쩡했던 코드가 오늘 아침 갑자기 이상해질 때가 있다. 대부분은 작은 실수다. null 체크를 빠뜨렸거나, API 응답 구조가 바뀌었는데 화면 코드를 함께 고치지 않았거나, 리팩터링 중 이름 하나를 덜 바꿨을 수 있다.

이 자동화는 매일 아침 최근 변경만 훑는다. 전체 코드베이스를 매번 깊게 분석하게 하면 느리고 시끄럽다. "최근 24시간"처럼 범위를 좁히면 결과가 훨씬 실용적이다.

이 저장소의 최신 main 브랜치를 기준으로 최근 24시간 커밋을 검토해줘.

목표:
최근 변경에서 실제 버그로 이어질 가능성이 높은 항목만 찾는다.

확인할 것:
- 함수 시그니처가 바뀌었는데 호출부가 덜 수정된 곳
- null 또는 undefined 가능성이 새로 생긴 곳
- API 응답 타입과 UI 사용 방식이 어긋난 곳
- 인증, 결제, 저장, 삭제 로직에서 권한 검사가 빠진 곳
- 테스트가 실패할 가능성이 높은 변경

하지 말 것:
- 스타일 취향 지적 금지
- 대규모 리팩터링 제안 금지
- 직접 파일 수정 금지

출력:
위험도 High/Medium/Low로 나누고, High가 없으면 "긴급 수정 없음"이라고 말해줘.
각 항목에는 파일 경로, 의심 이유, 최소 수정 방향을 포함해줘.

이 자동화의 결과는 매일 아침 standup 전에 보면 좋다. "오늘 해야 할 일"이 아니라 "오늘 놓치면 곤란한 일"만 보여 달라고 설계하는 것이 핵심이다.

자동화 2: console.log와 임시 코드 탐지

초보 프로젝트에서 의외로 자주 생기는 문제가 임시 코드다. 개발 중에는 console.log, debugger, TODO: 나중에, mockUser, fakePayment 같은 흔적을 남긴다. 문제는 배포 전에 지우는 것을 잊는다는 점이다.

이 자동화는 가볍고 안전하다. 처음에는 읽기 전용으로 만들기 좋다.

최근 변경 파일에서 배포 전에 제거해야 할 임시 코드를 찾아줘.

대상:
- console.log, console.warn 중 디버깅 목적으로 보이는 것
- debugger 문
- TODO, FIXME 중 배포 차단 가능성이 있는 것
- mock, fake, dummy 데이터가 production 경로에 남은 경우
- 임시로 비활성화한 테스트 또는 주석 처리된 핵심 로직

규칙:
- 테스트 파일 안의 의도적인 로그는 낮은 우선순위로 표시
- 문서 예제의 console.log는 무시
- 자동 수정하지 말고 보고서만 작성

출력:
우선순위 순서로 최대 10개만 보여줘.
각 항목에 "삭제", "유지 가능", "사람 확인 필요" 중 하나를 표시해줘.

이 프롬프트에서 중요한 부분은 무조건 console.log를 나쁘다고 하지 않는 것이다. 테스트나 문서 예제에서는 로그가 필요할 수 있다. Codex에게 "문맥을 보고 분류하라"고 알려 주면 쓸데없는 경고가 줄어든다.

자동화 3: 의존성 취약점과 오래된 패키지 점검

웹 앱은 대부분 외부 패키지 위에 만들어진다. React, Next.js, Express, Prisma, Supabase 클라이언트, 결제 SDK, 날짜 라이브러리 등 수많은 의존성이 있다. 이 패키지들에서 취약점이 발견되면 앱 코드가 그대로여도 위험해질 수 있다.

의존성 점검 자동화는 매일보다 매주가 적당하다. 단, 보안이 중요한 서비스라면 매일 새벽에 실행할 수도 있다. npm audit처럼 네트워크가 필요한 명령은 샌드박스 규칙에서 명시적으로 허용해야 할 수 있다. Automations는 기본 샌드박스 설정을 따르므로, unattended background task에서는 어떤 명령을 허용할지 신중하게 정해야 한다.²

의존성 보안 점검을 실행해줘.

작업:
1. package.json과 lock 파일을 확인한다.
2. npm audit 또는 프로젝트에 맞는 보안 점검 명령을 실행한다.
3. 취약점을 severity 기준으로 분류한다.
4. 자동 업그레이드가 안전한 항목과 사람이 확인해야 하는 항목을 구분한다.

제약:
- 직접 npm install 또는 npm update를 실행하지 말 것
- lock 파일을 수정하지 말 것
- major version 업그레이드는 항상 사람 확인 필요로 표시

출력:
- Critical/High 항목 먼저 요약
- 영향을 받는 패키지와 현재 버전
- 가능한 해결 버전
- 깨질 수 있는 부분
- 추천 다음 행동

나중에 자동화가 안정되면 "수정 PR 초안까지 준비"하도록 넓힐 수 있다. 하지만 처음부터 자동 업데이트와 자동 머지를 맡기지는 말자. 패키지 업데이트는 테스트가 통과해도 런타임에서 문제가 생길 수 있다.

자동화 4: 테스트 실패와 커버리지 하락 요약

테스트는 앱의 안전벨트다. 하지만 테스트 결과를 매번 읽는 일은 지루하다. 특히 CI 로그가 길면 어디서 실패했는지 찾는 데 시간이 오래 걸린다. Codex에게 테스트 실패를 요약하게 하면 "무슨 일이 일어났는지"를 빠르게 파악할 수 있다.

커버리지 자동화는 단순히 전체 퍼센트만 보는 것이 아니라 "어느 모듈이 떨어졌는지"를 보는 것이 중요하다. 전체 커버리지가 82%에서 81%로 내려간 것은 큰 문제가 아닐 수 있다. 하지만 결제 모듈이 85%에서 72%로 떨어졌다면 바로 확인해야 한다. 실제 반복 개발 업무에서도 테스트 커버리지 하락, 취약점, 임시 로그 같은 문제가 아침 standup 전에 우선순위 inbox로 도착하도록 설계하는 패턴이 많이 사용된다.³

테스트와 커버리지 상태를 점검해줘.

실행:
- 프로젝트의 AGENTS.md 또는 package.json을 보고 테스트 명령을 찾는다.
- 테스트를 실행한다.
- 커버리지 리포트가 있으면 이전 기준과 비교한다.

분석:
- 실패한 테스트를 원인별로 묶는다.
- 최근 변경과 관련 있는 실패를 먼저 표시한다.
- 커버리지가 하락한 파일이나 모듈을 찾는다.
- 새로 추가된 코드 중 테스트가 없는 경로를 표시한다.

제약:
- 테스트 코드를 자동 생성하지 말고 제안만 한다.
- 스냅샷 업데이트 금지
- 실패 원인을 확신할 수 없으면 "추정"이라고 표시

출력:
1. 오늘 사람이 봐야 할 실패 요약
2. 가장 가능성 높은 원인
3. 최소 수정 방향
4. 추가하면 좋은 테스트 케이스

이 자동화는 팀에서 특히 유용하다. 누군가 CI 실패를 발견하고 "이거 누구 때문이죠?"라고 묻기 전에, Codex가 실패를 원인별로 묶어 둔다. 사람은 로그 전체를 읽는 대신 요약을 검토하면 된다.

자동화 5: 주간 PR/이슈 요약

팀 프로젝트에서는 코드보다 정보가 더 빨리 쌓인다. PR이 열리고 닫히고, 이슈가 생기고, 댓글이 달리고, 릴리스가 미뤄진다. 주간 회의 전에 이 흐름을 사람이 직접 정리하면 꽤 많은 시간이 든다.

주간 PR/이슈 요약 자동화는 금요일 오후나 월요일 오전에 실행하면 좋다. 이 자동화의 목적은 감시가 아니라 정리다. 지난주 팀이 무엇을 했고, 아직 막힌 것은 무엇이며, 다음 주에 위험한 일은 무엇인지 알려 준다.

이번 주 GitHub PR과 이슈를 요약해줘.

범위:
- 이번 주 생성, 머지, 닫힘, 재오픈된 PR
- 이번 주 생성되거나 업데이트된 이슈
- 라벨이 bug, security, regression, release, blocked인 항목 우선

요약 기준:
- 기능 개발
- 버그 수정
- 리팩터링
- 테스트/문서
- 배포/운영
- 위험 또는 미해결 이슈

출력:
- 팀 회의에서 바로 읽을 수 있는 한국어 요약
- 중요한 PR 링크
- 지연 중인 리뷰
- 다음 주에 먼저 처리할 추천 항목 3개

제약:
- 사람을 비난하는 표현 금지
- 확실하지 않은 원인 단정 금지
- 단순 활동량 순위 만들지 말 것

이 자동화는 Gmail이나 Google Drive와 연결하면 더 강력해진다. 예를 들어 결과를 주간 회의 문서 초안으로 저장하거나, 팀 메일로 보내거나, Linear 이슈에 연결할 수 있다. 핵심은 "정보를 모으는 일"은 Codex가 하고, "우선순위를 결정하는 일"은 사람이 하는 것이다.

Review Queue를 안전장치로 사용하기

Automations를 제대로 쓰려면 Review Queue를 귀찮은 절차가 아니라 안전장치로 봐야 한다. 자동화가 끝나면 결과가 검토 대기열에 들어온다. 여기서 사람은 전체 대화, 실행 로그, 변경 diff를 확인하고 승인, 수정 요청, 폐기 중 하나를 선택한다. 여러 Codex App 워크플로에서는 worktree에서 만들어진 변경을 Review Queue로 모아 사람이 승인한 뒤 커밋이나 PR로 연결하는 패턴을 사용한다.⁴

이 흐름이 중요한 이유는 간단하다. Codex는 빠르지만 완벽하지 않다. 특히 자동화는 사람이 화면 앞에서 지켜보지 않는 동안 실행된다. 따라서 좋은 운영 원칙은 "Codex가 준비하고, 사람이 결정한다"이다.

예를 들어 버그 스캔 자동화가 다음 결과를 가져왔다고 하자.

High: src/app/api/projects/[id]/route.ts
최근 수정에서 ownerId 검사가 빠진 것으로 보입니다.
다른 사용자의 projectId를 알고 있으면 상세 조회가 가능할 수 있습니다.

권장 조치:
- 조회 조건에 ownerId를 추가
- 권한 없는 접근 테스트 추가
- 기존 CRUD 라우트와 동일한 패턴으로 정리

여기서 자동화가 바로 main에 커밋하면 위험하다. 대신 Codex에게 이어서 이렇게 요청하는 편이 안전하다.

좋아. 이 항목만 최소 변경으로 수정 PR 초안을 준비해줘.
범위는 src/app/api/projects/[id]/route.ts와 관련 테스트 파일로 제한해.
다른 리팩터링은 하지 마.
완료 후 diff와 테스트 결과를 요약해줘.

그 다음 Review Queue에서 diff를 확인한다. 수정 범위가 맞는지, 테스트가 충분한지, 기존 코드 스타일을 따르는지 본다. 괜찮으면 PR을 만들고, 애매하면 추가 수정을 요청하고, 틀렸으면 폐기한다.

이 방식은 느려 보이지만 실제로는 빠르다. 사람이 처음부터 로그를 뒤지고 원인을 찾는 시간은 줄어든다. 대신 마지막 판단에 집중한다. AI 자동화의 생산성은 "사람을 제거하는 것"이 아니라 "사람이 봐야 할 것을 정리해 주는 것"에서 나온다.

권한은 작게, 작업 공간은 분리해서 시작한다

자동화는 권한 설정이 특히 중요하다. 일반 채팅에서는 Codex가 위험한 명령을 실행하려고 할 때 사용자가 바로 눈치챌 수 있다. 하지만 자동화는 백그라운드에서 실행된다. 그래서 기본값은 보수적으로 잡는 것이 좋다.

초보자에게 권하는 시작점은 workspace-write 또는 읽기 중심 설정이다. workspace-write는 프로젝트 작업 공간 안에서만 파일을 읽고 쓸 수 있게 제한하는 방식으로 이해하면 된다. 외부 디렉터리 접근, 네트워크 접근, 앱 상호작용 같은 작업은 별도 허용이 필요할 수 있다.²

처음부터 full access로 자동화를 돌리는 것은 피하자. full access는 Codex가 훨씬 많은 일을 할 수 있다는 뜻이지만, 그만큼 잘못된 프롬프트가 만들 수 있는 피해도 커진다. 특히 배포 명령, 데이터베이스 마이그레이션, 결제 API 호출, 대량 파일 삭제처럼 되돌리기 어려운 작업은 사람이 승인하도록 남겨 두는 편이 안전하다.

Git 저장소에서는 worktree 격리를 적극적으로 사용하자. worktree는 같은 저장소의 별도 작업 공간이다. Codex가 자동화 실행 중 파일을 바꾸더라도 내가 작업 중인 폴더를 바로 건드리지 않는다. 이 덕분에 여러 자동화나 여러 Codex 작업이 동시에 돌아도 충돌이 줄어든다. 다만 worktree는 쌓일 수 있으므로, 처리한 실행 결과는 archive하고 정말 필요한 것만 pin해야 한다.²

실전 구성: 미니 SaaS 프로젝트의 자동화 세트

이제 앞 장에서 만들었던 로그인과 CRUD가 있는 미니 SaaS를 운영한다고 생각해 보자. 이 프로젝트에는 사용자 인증, 프로젝트 CRUD, 메모 CRUD, 배포, 테스트가 있다. 사람이 매일 확인해야 할 일이 꽤 많다.

처음부터 거창한 자동화 플랫폼을 만들 필요는 없다. 아래처럼 다섯 개만 설정해도 운영 품질이 크게 좋아진다.

여기서 Auth & Owner Check는 SaaS 앱에 특히 중요하다. 로그인 기능이 있는 앱에서는 "내 데이터만 볼 수 있는가?"가 핵심이다. Codex에게 이 규칙을 자동으로 점검하게 만들 수 있다.

SaaS API 보안 점검을 해줘.

범위:
- app/api 아래의 route.ts 파일
- 프로젝트, 메모, 사용자 관련 CRUD 엔드포인트

확인할 것:
- 로그인 사용자 확인이 있는가
- 조회/수정/삭제에서 ownerId 또는 소유권 검사를 하는가
- 다른 사용자의 id를 알고 있을 때 접근 가능한 경로가 있는가
- 에러 메시지가 민감한 정보를 노출하지 않는가

제약:
- 파일 수정 금지
- 새 라이브러리 설치 금지
- 의심 항목은 재현 가능한 요청 예시와 함께 보고

출력:
High/Medium/Low로 분류하고, High는 PR 초안으로 만들 수 있는 최소 수정 방향을 제안해줘.

이런 자동화는 초보자에게도 큰 도움이 된다. 보안 전문 지식이 부족해도 "어떤 질문을 반복해서 던져야 하는지"를 Codex에게 맡길 수 있기 때문이다. 물론 최종 보안 판단은 사람이 해야 한다. 하지만 매일 같은 실수를 찾는 눈이 하나 더 생긴다는 것만으로도 프로젝트는 훨씬 안전해진다.

GitHub, Linear, Gmail, Drive, 배포 플랫폼을 연결하는 흐름

Automations의 진짜 힘은 여러 도구를 연결할 때 나온다. 앱 개발 업무는 보통 한 도구 안에서 끝나지 않는다. 버그는 GitHub PR에서 발견되고, 작업 관리는 Linear 이슈로 이어지고, 회의 요약은 Google Drive 문서에 저장되고, 담당자에게는 Gmail이나 Slack으로 알려야 한다. 배포 플랫폼에서는 Preview URL이나 실패 로그를 확인해야 한다.

초보자는 처음부터 모든 도구를 연결하려 하지 말고, 한 줄 흐름으로 설계해 보자.

문제 발견 → 요약 리포트 작성 → 이슈/PR 생성 → 담당자 알림 → 사람이 승인 후 병합·배포

예를 들어 배포 전 점검 자동화는 이렇게 구성할 수 있다.

릴리스 후보 점검을 실행해줘.

입력:
- GitHub의 이번 릴리스 대상 PR
- 열린 P0/P1 Linear 이슈
- 최근 CI 결과
- 배포 플랫폼의 최신 Preview 배포 상태

작업:
1. 머지된 PR 중 릴리스 노트에 들어갈 항목을 정리한다.
2. 아직 닫히지 않은 P0/P1 이슈가 릴리스를 막는지 판단한다.
3. CI 실패 또는 flaky test가 있는지 요약한다.
4. Preview 배포 URL이 있으면 수동 확인 체크리스트를 만든다.
5. 결과를 docs/release-brief-YYYY-MM-DD.md 초안으로 작성한다.

제약:
- production 배포 실행 금지
- main 브랜치 직접 push 금지
- 외부 알림은 초안만 작성하고 발송은 사람 승인 필요

출력:
- 릴리스 가능 / 보류 추천 / 사람 판단 필요 중 하나
- 근거
- 담당자가 확인할 링크 목록

여기서 Codex가 할 일은 배포 버튼을 누르는 것이 아니다. 릴리스 판단에 필요한 자료를 모으고, 위험을 정리하고, 사람이 확인할 체크리스트를 만드는 것이다. 배포는 여전히 사람이 승인한다. 이 선을 지키면 자동화는 팀의 부담을 줄이면서도 사고 가능성을 키우지 않는다.

MCP나 Skills를 이미 설정했다면 이 흐름을 더 안정적으로 만들 수 있다. 예를 들어 $issue-triage, $test-coverage-report, $release-brief 같은 Skill을 만들어 두고 Automation 프롬프트에서 호출하면 된다. Skills는 반복 절차를 이름 붙여 재사용하는 방식이고, Automations는 그 절차를 일정에 따라 실행하는 방식이다. 즉, Skill은 "어떻게 할지", Automation은 "언제 할지"를 담당한다고 생각하면 쉽다.⁵

자동화 결과가 너무 시끄러울 때

처음 만든 자동화는 대체로 말이 많다. Codex는 친절하려고 많은 것을 보고하지만, 매일 아침 30개 경고가 쌓이면 아무도 읽지 않는다. 자동화는 많이 찾는 것보다 "볼 만한 것만 찾는 것"이 중요하다.

이럴 때는 프롬프트에 세 가지 제한을 넣는다.

보고 기준:
- 실제 사용자 오류, 보안 문제, 배포 실패로 이어질 가능성이 있는 항목만 보고
- 단순 스타일 문제는 제외
- 최대 5개까지만 보고
- 이미 .automation-ignore.json에 등록된 항목은 제외
- 새로 발생한 문제와 기존 문제를 구분

.automation-ignore.json 같은 파일을 두는 것도 좋은 방법이다. 오래된 lint 경고처럼 당장 고치지 않기로 한 항목을 매일 반복해서 보고하면 피로가 쌓인다. 무시 목록을 두면 Codex가 "새로운 문제"에 더 집중할 수 있다.

예시는 다음과 같다.

{
  "ignoredFindings": [
    {
      "id": "legacy-eslint-any-in-admin-page",
      "path": "src/app/admin/legacy.tsx",
      "reason": "관리자 레거시 화면. 2026-Q3 리팩터링 때 처리 예정"
    }
  ]
}

그리고 자동화 프롬프트에 이렇게 덧붙인다.

.automation-ignore.json 파일이 있으면 먼저 읽어줘.
그 목록에 있는 기존 이슈는 다시 보고하지 마.
단, 같은 파일에서 새로운 보안 문제나 런타임 오류 가능성이 발견되면 별도 항목으로 보고해줘.

이 작은 장치만으로도 자동화의 품질이 크게 좋아진다. 좋은 자동화는 매일 큰 소리로 떠드는 봇이 아니라, 정말 볼 일이 있을 때만 조용히 손을 드는 동료에 가깝다.

자동화가 만든 PR은 어떻게 검토할까

자동화가 안정되면 Codex가 수정 PR 초안까지 만들게 하고 싶어진다. 이때도 원칙은 같다. 자동 머지는 금지하고, 최소 변경 PR을 만들게 한다.

좋은 PR 생성 프롬프트는 다음처럼 범위를 강하게 제한한다.

위에서 발견한 High 항목 1개만 수정하는 PR 초안을 만들어줘.

범위:
- 관련 파일과 테스트 파일만 수정
- 포맷팅 전체 변경 금지
- 리팩터링 금지
- 공개 API 변경 금지

완료 기준:
- 실패를 재현하는 테스트 추가
- 최소 수정으로 테스트 통과
- 변경 이유를 PR 설명에 요약
- 위험한 사이드 이펙트가 있으면 명시

PR 설명 형식:
## 문제
## 원인
## 수정 내용
## 테스트
## 리뷰어가 볼 부분

Review Queue에서 이 PR 초안을 볼 때는 diff 크기부터 확인한다. 버그 하나를 고치라고 했는데 수십 개 파일이 바뀌었다면 바로 수정 요청을 해야 한다. 자동화 PR은 작을수록 좋다. 작아야 리뷰가 빠르고, 문제가 생겨도 되돌리기 쉽다.

검토할 때는 다음 기준을 마음속으로 확인하면 된다. 변경 범위가 프롬프트와 맞는지, 테스트가 실제 버그를 잡는지, 기존 스타일을 따르는지, 권한이나 보안 조건을 깨뜨리지 않았는지, 배포에 영향을 줄 설정 변경이 숨어 있지 않은지 본다. 이 다섯 가지를 확인한 뒤에만 승인한다.

App Automations와 CLI 자동화는 언제 나눠 쓸까

이 장의 중심은 Codex App의 Automations다. App Automations는 결과가 Review Queue에 모이고, worktree 기반 검토 흐름과 잘 어울린다. 사람이 아침에 inbox를 열어 확인하는 방식이라 초보자와 팀 운영에 특히 좋다.

반면 서버, CI, cron, GitHub Actions 같은 환경에서는 codex exec가 더 잘 맞을 수 있다. codex exec는 비대화형으로 한 번 실행하고 stdout, JSONL, exit code 같은 결과를 자동화 파이프라인에 넘기기 좋다.⁶ 예를 들어 GitHub Actions에서 매일 이슈를 요약하거나, CI 실패를 JSON으로 만들어 Slack 봇에 전달하는 식이다.

간단히 구분하면 이렇다.

초보자는 먼저 App Automations로 시작하자. 눈에 보이는 Review Queue가 있기 때문에 자동화가 무엇을 했는지 이해하기 쉽다. 나중에 팀의 CI/CD 파이프라인이 커지면 codex exec 기반 자동화를 추가하면 된다.

실패했을 때 확인하는 순서

자동화는 반드시 실패한다. 이것은 나쁜 일이 아니다. 스케줄, 권한, 외부 서비스 인증, 네트워크, 테스트 명령 중 하나만 바뀌어도 실패할 수 있다. 중요한 것은 실패를 빠르게 좁히는 순서다.

먼저 Triage 결과를 본다. Codex가 무엇을 하려다가 멈췄는지, 어느 단계까지 진행했는지 확인한다. 그다음 실행 로그를 본다. 명령이 실패했는지, 파일을 찾지 못했는지, 권한이 막혔는지, 인증 토큰이 없었는지 확인한다.

그다음 GitHub 권한을 확인한다. 저장소 읽기 권한만 있는데 PR을 만들려고 했거나, 이슈 라벨을 수정할 권한이 없을 수 있다. 외부 서비스 인증도 자주 문제를 일으킨다. Linear, Gmail, Google Drive, 배포 플랫폼 토큰이 만료되었거나, MCP 서버 연결이 끊겼을 수 있다.

네트워크 접근도 확인해야 한다. 샌드박스가 네트워크를 막고 있는데 npm audit, GitHub API, 배포 플랫폼 API를 호출하려 하면 실패한다. 이 경우 무작정 full access로 열지 말고, 필요한 명령이나 도메인만 허용하는 방향으로 조정한다.

마지막으로 cron 스케줄을 본다. 시간대가 UTC인지 로컬 시간인지 착각하면 "자동화가 안 돈다"고 느낄 수 있다. 0 9 * * *가 내 오전 9시가 아닐 수도 있다. 너무 자주 실행되도록 설정해서 이전 실행이 끝나기 전에 다음 실행이 시작되는 문제도 있다.

문제 해결 순서는 이렇게 기억하면 된다.

Triage 결과 → 실행 로그 → GitHub 권한 → 외부 서비스 인증 → 네트워크 접근 → cron 스케줄

이 순서대로 보면 대부분의 문제를 찾을 수 있다.

첫 주 운영 루틴

자동화는 만든 날보다 첫 주가 중요하다. 처음 만든 자동화는 아직 팀의 실제 리듬을 모른다. 너무 많은 것을 보고할 수도 있고, 중요한 항목을 놓칠 수도 있다. 그래서 첫 주에는 매일 Review Queue를 열어 결과를 적극적으로 다듬어야 한다.

첫날에는 읽기 전용 자동화 하나만 만든다. 예를 들어 Daily Bug Scan을 평일 오전 9시에 실행하도록 설정한다. 둘째 날에는 결과가 너무 길거나 짧지 않은지 확인하고 프롬프트를 조정한다. 셋째 날에는 .automation-ignore.json 같은 무시 목록을 도입한다. 넷째 날에는 Test Coverage Brief나 Dependency Security처럼 두 번째 자동화를 추가한다. 다섯째 날에는 한 주 동안 쌓인 결과를 보고 "계속 유지할 자동화"와 "너무 시끄러운 자동화"를 나눈다.

처음부터 자동화 10개를 켜지 말자. 자동화도 코드와 같다. 작게 시작하고, 관찰하고, 개선해야 한다.

자동화를 잘 쓰는 팀의 공통점

Codex Automations를 잘 쓰는 팀은 AI에게 모든 것을 맡기지 않는다. 대신 반복되는 관찰과 정리를 맡긴다. 사람은 결정에 집중한다. 이 차이가 매우 중요하다.

나쁜 자동화는 이렇게 말한다.

매일 알아서 버그를 고치고 main에 머지하고 배포해줘.

좋은 자동화는 이렇게 말한다.

매일 최근 변경에서 배포 위험을 찾아줘.
위험도와 근거를 정리하고, High 항목은 최소 수정 PR 초안을 제안해줘.
머지와 배포는 사람이 Review Queue에서 승인할 때만 진행해.

둘의 차이는 통제권이다. 좋은 자동화는 속도를 높이지만, 책임의 위치를 흐리지 않는다. Codex는 지치지 않는 관찰자이자 초안 작성자다. 사람은 제품의 맥락, 비즈니스 판단, 최종 승인권을 가진다.

이제 여러분의 앱은 "만드는 단계"를 넘어 "계속 관리되는 단계"로 들어간다. Automations를 잘 설정해 두면 Codex의 생산성 효과는 한 번의 코드 생성으로 끝나지 않는다. 매일 아침 버그 후보를 정리해 주고, 매주 의존성 위험을 알려 주고, 릴리스 전에 빠뜨린 문서를 찾아 준다. 작은 자동화들이 쌓이면, 프로젝트는 점점 더 관리하기 쉬운 상태가 된다.

다음 장에서는 여기서 한 걸음 더 나아가 Browser Use와 Computer Use로 실제 앱을 검증하는 방법을 다룬다. Automations가 "무엇을 점검할지"를 정기적으로 알려 준다면, Browser Use와 Computer Use는 실제 브라우저와 컴퓨터 환경에서 "정말 동작하는지" 확인하는 눈과 손이 되어 줄 것이다.

참고

¹Automations - Codex app | OpenAI Developers

²Scheduled Task Automation with Codex

³Awesome Codex Automations

⁴Mastering the Codex Desktop App: Automations, Triggers and the Review Queue

⁵Understanding Skills Plugins and Automations in Codex Workflows

⁶Codex CLI Automations and Scheduled Tasks: Background Agent Workflows