한 줄 요약

이 페이지에서 배우는 것

  • Automations(자동화)가 정확히 무엇인지, 왜 필요한지
  • Triage의 역할과 결과 확인 방법
  • Local 실행과 Worktree 실행의 차이 (비유로 쉽게 이해)
  • 실무에서 바로 쓸 수 있는 자동화 시나리오 6가지 이상
  • 자동화를 처음부터 만드는 단계별 가이드
  • Skills와 Automations를 결합하는 실전 사례
  • 자주 묻는 질문 (FAQ) 5가지

Automations가 뭔가요?

한 줄 요약: 캘린더에 반복 일정을 등록하는 것과 똑같습니다. 한 번 설정하면 Codex가 정해진 시간마다 알아서 작업을 수행합니다.

회사에서 비서에게 "매주 월요일 아침에 보안 체크 결과 보고서 만들어줘"라고 부탁한다고 상상해 보세요. 비서는 매주 월요일마다 알아서 보안 체크를 하고, 문제가 있으면 보고서를 여러분 책상 위에 올려두고, 문제가 없으면 "이상 없음"이라고 간단히 메모만 남깁니다.

Automations가 바로 이 비서 역할을 합니다. 여러분이 해야 할 일은 딱 하나 — "무엇을, 얼마나 자주 할지"를 한 번 설정하는 것뿐입니다. 그 이후에는 Codex app이 백그라운드에서 자동으로 실행하고, 결과를 Triage에 정리해 줍니다.

예를 들어 이런 식으로 프롬프트를 작성할 수 있습니다:

"프로젝트의 모든 테스트를 실행하고, 실패한 테스트가 있으면 원인과 수정 방법을 알려줘."

이 프롬프트를 "매일 오전 9시"로 설정해두면, 매일 출근했을 때 Triage에서 테스트 결과를 바로 확인할 수 있습니다. 직접 터미널을 열고 테스트를 돌릴 필요가 없어지는 거죠.

Triage란? (자동화 결과함)

Triage는 Codex 앱의 공식 UI 라벨로, 자동화 실행 결과가 도착하는 영역입니다 — 공식 문서: "The 'Triage' section acts as your inbox." 이메일 받은편지함처럼 동작하므로 본 가이드에서도 "인박스 역할의 자동화 결과함"으로 부르며, UI에서 찾을 때는 Triage를 기준으로 검색하세요.

결과 있음 보고할 내용이 있으면 Triage에 새 항목으로 표시됩니다. 읽지 않은 항목만 필터링해서 볼 수도 있습니다.
결과 없음 특별히 보고할 것이 없으면 자동으로 보관(archive)됩니다. 스팸 필터가 불필요한 메일을 걸러주는 것과 비슷합니다.

덕분에 Triage를 열었을 때 정말 중요한 내용만 남아 있게 됩니다. "테스트 전부 통과, 문제 없음" 같은 결과는 자동으로 치워지고, "3개 테스트 실패, 보안 취약점 발견" 같은 중요한 내용만 눈에 띄게 남는 것이죠.

자동화 생성 흐름

1
자동화 생성
프로젝트에 자동화를 추가하고, "무엇을 해줘"라는 프롬프트를 작성합니다
2
주기 설정
실행 간격(매시간, 매일, 매주 등)과 실행 환경(Local/Worktree)을 선택합니다
3
백그라운드 실행
앱이 실행 중일 때 예약된 시점에 자동으로 작업을 수행합니다. 여러분은 다른 작업을 하고 있어도 됩니다
4
Triage 확인
중요한 결과만 Triage에 남기고, 특별한 내용이 없으면 자동 보관합니다

업무 생산성을 높이는 자동화 예시

"자동화로 뭘 할 수 있는데?"라는 질문에 답하기 위해, 실제 개발팀에서 바로 적용할 수 있는 시나리오 6가지를 소개합니다.

매일 아침 코드 품질 체크
설정: "매일 오전 8시에 린트와 테스트를 실행해줘"
결과: 출근하면 Triage에서 코드 품질 리포트를 바로 확인. 어제 밤 팀원이 커밋한 코드에 문제가 있는지 한눈에 파악할 수 있습니다.
주간 보안 취약점 스캔
설정: "매주 월요일에 의존성 패키지의 보안 취약점을 검사해줘"
결과: 취약점이 발견되면 Triage에 상세 리포트가 도착합니다. 문제가 없으면 자동 보관되어 신경 쓸 필요가 없습니다.
PR 머지 후 자동 문서 업데이트
설정: "코드 변경 후 API 문서와 README가 최신 상태인지 확인하고, 불일치가 있으면 수정해줘"
결과: 코드와 문서가 항상 동기화됩니다. 문서 업데이트를 깜빡하는 일이 사라집니다.
이슈 자동 분류 및 우선순위 지정
설정: "새로 등록된 이슈를 분석해서 버그/기능 요청/개선으로 분류하고 우선순위를 태깅해줘"
결과: 이슈 트래커가 항상 정리된 상태로 유지됩니다. PM이 매번 수동으로 분류할 필요가 없습니다.
정기 의존성 업데이트 체크
설정: "매주 사용 중인 패키지의 새 버전이 있는지 확인하고, 주요 변경사항을 요약해줘"
결과: 오래된 패키지를 방치하는 일 없이, 업데이트 타이밍을 놓치지 않습니다.
테스트 커버리지 모니터링
설정: "테스트 커버리지가 80% 이하로 떨어지면 알려줘"
결과: 커버리지가 떨어질 때만 Triage에 경고가 도착합니다. 기준 이상이면 자동 보관되어 불필요한 알림이 없습니다.

Local 실행 vs Worktree 실행

자동화를 실행할 때 두 가지 환경을 선택할 수 있습니다. 비유로 쉽게 이해해 봅시다.

Local = 내 책상에서 직접 작업하는 것
여러분이 지금 사용하고 있는 그 프로젝트 폴더에서 바로 실행합니다. 빠르고 간편하지만, 여러분이 작업 중인 코드와 충돌할 수 있습니다. 마치 내가 책상에서 문서 작업을 하고 있는데, 비서가 같은 책상에서 다른 서류를 정리하는 상황과 비슷합니다.

Worktree = 옆 책상에서 별도로 작업하는 것
프로젝트의 복사본을 별도 공간에 만들어서 거기서 실행합니다. 내 작업과 전혀 충돌하지 않지만, 별도 환경을 준비해야 합니다. 마치 비서가 옆 방에서 독립적으로 일하는 것과 같습니다.

항목 Local 실행 (내 책상) Worktree 실행 (옆 책상)
작업 디렉터리 현재 프로젝트 디렉터리 직접 사용 별도 worktree 디렉터리에서 실행
코드 수정 작업 디렉터리를 직접 수정 격리된 환경에서 수정 (내 코드에 영향 없음)
충돌 위험 미완료 로컬 작업과 충돌 가능 로컬 작업과 충돌 없음
속도 빠름 (별도 준비 불필요) 약간 느림 (환경 복제 필요)
권장 시나리오 읽기 전용 점검, 상태 보고, 코드 분석 코드 수정 가능성이 있는 모든 작업
환경 설정 기존 환경 그대로 사용 setup script로 별도 초기화 필요
비유 내 책상에서 비서가 같이 일함 비서가 옆 방에서 독립적으로 일함
초보자 팁: 잘 모르겠으면 Worktree를 선택하세요. 코드를 읽기만 하는 자동화(테스트 실행, 분석 등)는 Local이 편하고, 코드를 수정할 수 있는 자동화(문서 업데이트, 코드 포맷팅 등)는 Worktree가 안전합니다.

자동화 만들기: 단계별 가이드

처음 자동화를 만드는 분을 위한 단계별 안내입니다. 천천히 따라해 보세요.

Step 1: 프로젝트 선택
Codex app을 열고, 자동화를 적용할 프로젝트를 선택합니다. 아직 프로젝트가 없다면 먼저 프로젝트를 추가해야 합니다. (2. 프로젝트와 멀티태스킹 페이지 참고)
Step 2: 자동화 추가 버튼 클릭
프로젝트 설정 화면에서 "Add Automation" 또는 자동화 추가 버튼을 클릭합니다. 새로운 자동화 설정 화면이 나타납니다.
Step 3: 프롬프트 작성
Codex에게 시킬 작업을 자연어로 작성합니다. 예: "모든 테스트를 실행하고, 실패한 테스트가 있으면 원인과 해결 방법을 설명해줘." 구체적으로 쓸수록 좋은 결과를 얻을 수 있습니다.
Step 4: 실행 주기 설정
얼마나 자주 실행할지 선택합니다. 매시간, 매일, 매주 등 다양한 옵션이 있습니다. 작업의 성격에 맞게 선택하세요. 보안 스캔은 매주, 테스트 실행은 매일이 적당합니다.
Step 5: 실행 환경 선택
Local(내 책상)과 Worktree(옆 책상) 중 하나를 선택합니다. 코드를 읽기만 하면 Local, 코드를 수정할 수 있으면 Worktree를 선택하세요.
Step 6: 모델과 옵션 설정 (선택사항)
사용할 AI 모델과 reasoning effort(사고 깊이)를 지정할 수 있습니다. 잘 모르겠으면 기본값 그대로 두면 됩니다. 나중에 언제든 변경할 수 있습니다.
Step 7: 저장 및 확인
설정을 저장하면 자동화가 활성화됩니다. 다음 예약 시점에 자동으로 실행됩니다. Triage에서 결과를 확인하세요. 같은 자동화를 여러 프로젝트에 걸어 둘 수도 있습니다.

자동화 실행 라이프사이클

자동화가 한 번 설정되면, 아래 과정이 계속 반복됩니다.

등록
자동화 프롬프트, 실행 주기, 대상 프로젝트, 실행 환경(Local/Worktree)을 설정합니다.
대기
앱이 실행 중이고 프로젝트가 디스크에 존재하면 다음 실행 시점까지 대기합니다. 알람 시계가 울리기를 기다리는 것과 같습니다.
실행
예약된 시점에 백그라운드에서 작업을 수행합니다. 여러분이 다른 작업을 하고 있어도 괜찮습니다. Model과 reasoning effort는 기본값 또는 수동 지정이 가능합니다.
결과 분류
의미 있는 결과가 있으면 Triage에 남기고, 특별한 내용이 없으면 자동으로 보관합니다. 이메일 스팸 필터처럼 중요한 것만 남겨줍니다.
반복
다음 주기까지 대기 상태로 돌아갑니다. 이 과정이 무한 반복됩니다. 자동화를 끄기 전까지 계속 동작합니다.

핵심 포인트

  • 1 자동화는 앱이 실행 중이어야 하며, 선택된 프로젝트가 디스크에 존재해야 합니다. 앱을 종료하면 자동화도 일시 정지됩니다.
  • 2 Git 저장소에서는 로컬 또는 새 worktree에서 실행을 선택할 수 있습니다. 코드 수정이 포함되면 worktree를 추천합니다.
  • 3 Triage에 결과가 쌓이므로, 매일 한 번 Triage를 확인하는 습관을 들이면 좋습니다.
  • 4 같은 자동화를 여러 프로젝트에 걸어 둘 수도 있습니다. 예: 보안 스캔 자동화를 5개 프로젝트에 동시 적용.
  • 5 model과 reasoning effort는 기본값 또는 수동 지정이 가능합니다. 간단한 작업은 기본값, 복잡한 분석은 높은 reasoning effort를 추천합니다.

Skills + Automations 결합 사례

Skills는 Codex에 특정 능력을 추가하는 플러그인입니다. Skills와 Automations를 결합하면 훨씬 강력한 자동화를 만들 수 있습니다. 마치 비서에게 전문 자격증을 따게 해서 더 전문적인 업무를 맡기는 것과 같습니다.

정기 보안 점검
조합: 보안 분석 Skill + 매주 실행 자동화
보안 관련 skill과 자동화를 결합해 매주 의존성 취약점을 스캔합니다. 발견 시 CVE 번호, 심각도, 수정 방법까지 포함된 리포트가 Triage에 도착합니다.
릴리스 문서 업데이트
조합: 문서화 Skill + 매일 실행 자동화
문서화 skill과 자동화를 결합해 코드 변경 후 CHANGELOG와 API 문서를 자동으로 갱신합니다. 코드와 문서의 불일치를 자동으로 감지하고 수정합니다.
테스트 커버리지 모니터링
조합: 테스트 분석 Skill + 매일 실행 자동화
테스트 skill과 자동화를 결합해 커버리지가 임계값(예: 80%) 이하로 떨어지면 Triage에 경고를 남깁니다. 어떤 파일의 커버리지가 부족한지도 알려줍니다.
코드 스타일 정리
조합: 린트/포맷팅 Skill + 매일 실행 자동화
린트 skill과 자동화를 결합해 주기적으로 코드 포맷과 스타일 규칙 준수 여부를 점검합니다. 위반 사항을 발견하면 자동으로 수정 PR을 생성할 수도 있습니다.
API 호환성 체크
조합: API 분석 Skill + 매주 실행 자동화
API 엔드포인트의 요청/응답 스키마가 변경되었는지 자동으로 감지합니다. 클라이언트에 영향을 줄 수 있는 breaking change를 미리 발견해 줍니다.
성능 벤치마크 추적
조합: 성능 측정 Skill + 매일 실행 자동화
주요 함수의 실행 시간을 매일 측정하고, 이전 대비 성능이 저하되면 Triage에 경고합니다. 성능 회귀를 조기에 발견할 수 있습니다.

실전 팁

코드를 수정할 가능성이 있는 자동화는 worktree를 기본으로 두는 편이 안전합니다. 로컬 작업과의 충돌을 방지할 수 있습니다.
프롬프트를 구체적으로 작성하세요. "테스트 돌려줘"보다 "Jest로 모든 단위 테스트를 실행하고, 실패한 테스트의 파일명, 테스트명, 에러 메시지를 정리해줘"가 훨씬 좋은 결과를 줍니다.
처음에는 간단한 자동화부터 시작하세요. 예를 들어 "매일 git status를 확인하고 커밋되지 않은 변경 사항이 있으면 알려줘" 같은 가벼운 작업으로 시작해서 점점 복잡한 자동화로 발전시키는 것을 추천합니다.

자동화로 절약되는 작업 시간 (예시)

아래는 자동화 도입 전후를 비교한 예시입니다. 수동으로 하던 반복 작업을 자동화하면 이만큼의 시간을 절약할 수 있습니다.

정기 QA
85%
이슈 Triage
70%
문서 점검
60%
보안 스캔
75%
코드 스타일
50%

자주 묻는 질문 (FAQ)

Q: 자동화는 앱을 항상 켜놓아야 하나요?

A: 네, Codex app이 실행 중일 때만 자동화가 동작합니다. 앱을 종료하면 자동화도 일시 정지되고, 다시 앱을 켜면 자동으로 재개됩니다. 컴퓨터를 끄면 당연히 실행되지 않습니다. 다만, 다시 앱을 켜면 밀린 작업이 곧바로 실행됩니다.

Q: 자동화가 코드를 잘못 수정하면 어떡하나요?

A: 걱정하지 마세요. Worktree로 실행하면 별도 공간에서 작업하므로 원본 코드에 영향이 없습니다. 또한 Git을 사용하고 있다면 언제든 이전 상태로 되돌릴 수 있습니다. 처음에는 "읽기 전용" 작업(분석, 보고)부터 시작하고, 익숙해진 후에 코드 수정 자동화를 도입하는 것을 추천합니다.

Q: 자동화 실행 빈도를 어떻게 설정하나요?

A: 자동화 설정 화면에서 실행 주기를 선택할 수 있습니다. 매시간, 매일, 매주 등의 옵션이 제공됩니다. 작업의 특성에 따라 적절한 주기를 선택하세요. 예를 들어, 테스트 실행은 매일, 보안 스캔은 매주, 의존성 체크는 매주 또는 격주가 적당합니다.

Q: 무료 플랜에서도 자동화를 사용할 수 있나요?

A: 자동화 기능의 사용 가능 여부와 실행 횟수 제한은 플랜에 따라 다를 수 있습니다. 최신 플랜별 제한 사항은 공식 문서에서 확인해 주세요. 일반적으로 유료 플랜에서 더 많은 자동화 실행 횟수와 고급 옵션을 제공합니다.

Q: 자동화 결과를 Slack으로 받을 수 있나요?

A: 자동화 결과는 기본적으로 Codex app의 Triage에 도착합니다. 추가로 Settings의 Integrations에서 GitHub / Slack / Linear 플러그인을 연결해 두면 자동화 안에서 동일한 도구를 호출할 수 있어, 결과를 Slack 채널에 게시하거나 Linear 이슈를 만드는 흐름을 구성할 수 있습니다.

다음 단계

자동화의 기본을 이해했다면, 아래 페이지를 통해 더 깊이 활용해 보세요.

자동화의 기본 모델, reasoning effort 등 세부 설정을 조정하는 방법을 배웁니다.
Automations와 결합해서 사용할 수 있는 Skills를 만들고 관리하는 방법을 알아봅니다.
자동화에서 사용하는 Worktree의 개념과 활용법을 더 깊이 이해합니다.

Automation 종류 (Standalone / Project / Thread)

공식 features 문서 기준으로 자동화는 attach 대상에 따라 Standalone, Project, Thread 형태로 구분됩니다(Worktree 자동화는 worktree에 attach된 변형으로 사용됩니다). 결과는 모두 Triage(인박스 역할을 하는 자동화 결과함)에 도착합니다.

Standalone Automations
스레드/프로젝트와 분리된 독립 자동화. 매번 깨끗한 컨텍스트로 실행되며 정기 점검·리포트에 적합합니다.
Project Automations
특정 프로젝트에 attach된 자동화. 새 스레드를 생성해 프로젝트 단위 작업(린트, 의존성 점검, 주간 리포트 등)을 정기 실행합니다.
Thread Automations (heartbeat)
현재 스레드에 attach되어 일정 간격으로 깨어나는 heartbeat 방식. 이전 메시지 맥락을 유지한 채 후속 작업을 이어 갑니다. 원하면 worktree에 묶어 long-running 작업으로 운영할 수 있습니다.

스케줄 · 샌드박스 · 승인 정책

  • 스케줄 3가지 — 공식 문서는 ① 사전 정의(Predefined): 매일/매주의 정해진 시각, ② 분 단위 cadence(Custom cadences): 짧은 주기로 깨어나 후속 작업을 이어가는 heartbeat용, ③ cron 문법: 임의 주기(예: 0 9 * * 1-5) — 세 가지를 구분합니다.
  • 샌드박스 모드read-only / workspace-write / full access 중 선택. 자동화 권한을 최소화하면 사고 위험을 줄일 수 있습니다.
  • 승인 정책 — 무인 실행에는 approval_policy = "never"가 권장됩니다(default 아님). 자동화는 프로파일/프로젝트 설정을 상속하므로, never가 아니면 승인 프롬프트가 떠 자동 실행이 막힐 수 있습니다. 결과 검토는 Triage에서 수행합니다.
  • 관리자 정책 (requirements.toml) — 관리자는 requirements.toml로 자동화의 sandbox 모드와 승인 정책을 조직 단위로 강제할 수 있습니다(공식 Automations 문서). 본인이 설정해도 적용되지 않으면 조직 정책이 우선될 가능성을 의심하세요.
  • 플러그인 연동 — 일반 Codex와 동일하게 GitHub / Slack / Linear 등 연결된 플러그인 도구를 자동화 안에서 호출할 수 있습니다.

장점 / 단점 / 한계점

✅ 장점

  • PR 이벤트, 이슈 할당 등에 자동 반응하여 수동 작업 감소
  • 반복적인 코드 리뷰/테스트 작업을 24시간 자동 처리
  • 팀 전체에 일관된 코드 품질 기준 적용 가능
  • 규칙 기반으로 설정이 직관적

❌ 단점

  • 복잡한 조건 분기가 필요한 경우 규칙 설정이 어려움
  • 자동화 규칙이 많아지면 관리와 디버깅이 복잡해짐
  • 의도치 않은 트리거로 불필요한 작업이 실행될 수 있음

⚠️ 한계점

  • 트리거는 기본적으로 시간 스케줄(cron 포함) 기반입니다. Git push·이슈 코멘트 같은 외부 이벤트는 GitHub / Slack / Linear 통합과 결합해 간접적으로 처리할 수 있지만, "push가 발생한 순간 즉시 실행"되는 진짜 이벤트 트리거는 자동화 자체에 내장되어 있지 않습니다.
  • 자동화된 변경도 반드시 사람의 리뷰를 거쳐야 병합 가능
  • 자동화 실행 환경은 Codex의 sandbox 정책을 그대로 따름(권한이 좁으면 일부 작업 실패 가능)

공식 출처