지식 노동을 위한 Codex

게시일: 2026년 6월 26일 | 원문 작성일: 2026년 6월 | 저자: Katie Parrott | 원문 보기

• • •

Codex는 과소평가하기 쉬워요. 언뜻 보면 또 하나의 AI 코딩 도구처럼 보이고, 엔지니어가 아니라면 ‘나하고는 상관없는 도구’라는 결론에 자연스럽게 도달하게 되죠.

하지만 그렇게 보면 Codex가 가능하게 해 주는 것들을 놓치게 돼요.

월요일 아침을 떠올려 볼게요. 출시 계획을 짜 달라는 요청이 받은편지함에 도착해요. 맞는 Codex 프로젝트를 열어 브리프를 건네고, Codex가 클라우드에서 일하는 동안 노트북을 덮어요. 사무실로 출근하는 길에 휴대폰으로 알림이 와요. Codex가 관련된 Slack 스레드를 읽고, Google Drive에서 고객 노트를 끌어오고, PostHog에서 지난 분기 수치를 확인하고, 공유된 Notion 문서에 시장 진입 계획(go-to-market plan)1 초안을 시작했다는 알림이죠. 이제 타이밍에 관한 세부 사항 하나만 확인해 주면 되는데, 좋아요 버튼 하나로 처리해요. 책상에 도착할 무렵이면 검토할 초안이 기다리고 있죠.

이게 바로 에이전트 네이티브 지식 노동의 모습이에요. 이 모든 게 OpenAI의 에이전트인 Codex, 그리고 Codex 데스크톱 앱 위에서 돌아가요. 이 가이드에서 ‘Codex’라고 하면 이 앱을 가리켜요.

Codex는 여러분과 여러분의 AI 에이전트를 위한 작업 공간이에요. Codex에 필요한 파일과 앱, 도구에 대한 접근 권한을 주면, Codex는 필요한 맥락을 모으고, 연결해 둔 도구를 쓰고, 작업을 끝까지 처리해요. 코드 작업에 유용하게 쓰이는 바로 그 능력이 폭넓은 지식 노동에도 그대로 적용돼요.

Codex에서 에이전트와 일하는 방식은 두 가지예요. 위임(delegate)하거나 협업(collaborate)하거나죠.

• 위임은 예측 가능하고, 반복적이며, 위험이 낮은 작업에 어울려요. 명확하고 구체적인 지시만 있으면 에이전트가 알아서 실행하고, 완성된 결과물을 가져와 검토받게 해요.
• 협업은 판단이 많이 필요하거나, 탐색적이거나, 반복적으로 다듬어야 하는 작업에 어울려요. 모델과 나란히 일하면서 여러분이 그리는 결과물을 향해 나아가는 거죠.

이제 AI는 한때 전문성이 있어야 했던 작업들을 해낼 수 있고, 그만큼 기회도 늘고 잡음도 늘어요. AI와 가장 잘 일하는 사람들은 무엇을 위임하고 무엇을 직접 결정해야 하는지를 알아요. 이들은 모델에 압도당하는 대신 모델을 올라타고 다뤄요2.

Codex를 능숙하게 쓰는 사람들이 그게 실제로 어떤 모습인지 잘 보여 주는 사례죠.

이 가이드는 바로 그런 사람이 되는 법을 다뤄요. 작업 공간을 세팅하는 법, 레버리지가 큰 지식 노동을 돌리는 법, 그리고 반복되는 일을 시간이 갈수록 더 좋아지는 지속 가능한 시스템으로 바꾸는 법을 담았어요. 일을 일회성 작업이 아닌 사이클로 바라볼 준비가 됐다면, 이 가이드가 딱이에요.

Codex의 모든 기능을 한꺼번에 익힐 필요는 없어요. 어떤 기능이 있는지 먼저 파악하고, 그다음 여러분의 편안함과 신뢰, 그리고 결과를 검토할 수 있는 능력에 맞는 위임·커스터마이즈·자동화 수준을 고르세요. 더 높은 수준이 자동으로 더 나은 건 아니에요. Every3의 ‘AI 도입의 여덟 단계’ 가이드4가 말하듯, 능숙한 사용자는 작업에 따라 단계를 오르내려요.

• • •

1부: Codex 이해하기

Codex란 무엇인가

Codex는 에이전트형 작업 공간이에요. 목표를 주면 Codex가 작업을 계획하고, 사용할 수 있는 도구와 맥락을 활용해서 여러분이 검토할 결과물을 내놔요. 열어 둔 프로젝트 폴더 안의 파일을 읽고 쓸 수 있고, 플러그인(Plugins)과 앱을 통해 외부 서비스와 연동하며, 여러 단계로 이뤄진 워크플로우를 돌리고, 작업에 필요하면 코드와 스크립트를 만들고, 문서·스프레드시트·프레젠테이션·PDF·웹사이트까지 만들어요.

Codex가 할 수 있는 일은 이래요.

• 여러 작업을 동시에 진행하며 여러분과 나란히 일해요
• 연결해 둔 앱과 파일에서 맥락을 끌어와요
• 화면 위 조작이 필요한 작업에서는 지원되는 브라우저와 데스크톱 워크플로우를 활용해요
• 필요한 맥락과 도구, 권한이 갖춰지면 스스로 결과를 점검하면서 정해진 목표를 향해 다듬어 나가요
• 각 메시지를 일회성 요청으로 취급하는 대신, 오래 이어지는 세션 내내 하나의 목표를 꾸준히 붙들고 있어요
• 반복 가능한 작업을 주기적으로 도는 워크플로우로 바꿔요
• 재사용 가능한 지시를 스킬이나 설치 가능한 플러그인으로 묶어요
• 계획서·보고서·작업 자료를 호스팅되는 사이트(Sites)로 바꿔요
• Codex가 연결된 컴퓨터에서 돌아가는 동안, 여러분이 휴대폰으로 작업을 시작하고 방향을 잡고 검토하게 해 줘요

이런 능력 덕분에 Codex는 구체적으로 정의된 작업을 위임할 때도, 사람과 에이전트가 협업하는 공유 작업 공간으로 쓸 때도 유용해요. 핵심 판단은 어떤 모드가 그 작업에 맞는지를 정하는 거예요.

알아 둬야 할 기능들

Codex의 다섯 가지 기능이 이 가이드에서 조직화 작업의 대부분을 담당해요. 서로 헷갈리기 쉽지만, 각각은 다른 문제를 풀어요. 프로젝트(Projects)는 공유 맥락을 담고, 스레드(Threads)는 개별 과제를 따로 떼어 관리하고, 목표(Goals)는 더 긴 목적을 붙들고, 플러그인은 재사용 가능한 기능을 더해 주고, 사이트는 작업을 공유 인터페이스로 바꿔 줘요.

프로젝트

프로젝트는 특정 폴더와 그 지시 사항을 하나 이상의 스레드를 위한 작업 맥락으로 Codex에 제공해요. 제품 출시, 주간 보고, 채용처럼 계속 진행되는 작업 영역마다 프로젝트를 하나씩 두면, 그 안의 스레드들이 같은 원본 자료와 규칙을 끌어다 쓸 수 있어요. 어떤 한 대화가 기억해 주길 바라는 대신, 오래 유지할 결정과 현재 상태, 출처 링크는 프로젝트 파일에 담아 두세요.

스레드

스레드는 프로젝트 안에서 하나의 과제나 하나의 생각 줄기를 다루는 대화예요. 과제가 바뀌거나 대화가 따라가기 어려워지면 새 스레드를 여세요. 긴 스레드에는 잡음이 쌓이고, Codex가 관련 정보를 요약해서 스레드를 압축할 수도 있어요. 대화와 대화 사이에 중요한 정보를 보존해 주는 건 프로젝트 파일이에요.

서로 다른 스레드는 대화 기록을 자동으로 공유하거나 서로에게 보고하지 않아요. 그래도 몇 가지 방법으로 협력하게 할 수 있어요.

• 다이렉트 메시지: 스레드 관리 도구를 쓸 수 있을 때는, Codex에게 이름이 있는 스레드를 찾아 후속 프롬프트를 보내 달라고 하세요. 결정 내용, 출처 링크, 기대하는 응답, 그리고 받는 스레드가 결과를 어디에 둬야 하는지를 함께 담으세요. 받는 스레드는 그 메시지와 자기 프로젝트 맥락이 주는 정보만 알게 돼요.
• 공유 프로젝트 파일: 한 스레드가 브리프나 상태 업데이트, 소스 맵을 프로젝트에 적어 두면 다른 스레드가 그 파일을 읽어요. 무엇이 공유됐는지 정확히 들여다볼 수 있기 때문에, 스레드 사이에 정보를 넘기는 가장 믿을 만한 방법이에요.
• 포크: 새로운 작업 줄기가 그 시점까지의 완성된 대화 기록을 그대로 물려받아야 한다면 스레드를 포크하세요. 포크된 스레드는 그다음부터 독립적으로 발전해요.
• 서브에이전트: 하나의 상위 작업이 경계가 분명한 조각들로 나뉘고, 그 조각들이 다시 하나의 종합으로 모여야 할 때는 서브에이전트를 쓰세요. 상위 작업이 후속 지시를 나눠 보내고, 결과를 기다렸다가 합칠 수 있어요.
• 자동화: 같은 대화가 정해진 일정에 깨어나 진행 중인 루프를 이어 가야 한다면 스레드 자동화를 붙이세요

유용한 핸드오프 프롬프트는 이런 식이에요. “[이름]이라는 스레드를 찾아 줘. 이 업데이트를 전해 줘: [결정과 출처]. 그 스레드한테 [범위가 정해진 작업]을 시키고, 결과를 [위치]에 저장한 다음, 검토할 준비가 되면 다시 보고해 줘.” 중요한 작업이라면 핸드오프가 잘됐다고 넘겨짚지 말고, 상대 스레드나 공유 파일을 직접 검토하세요.

목표

Codex의 목표는 /goal 명령으로 시작하며, 더 긴 작업을 위한 지속적인 목적이에요. ‘완료’가 어떤 모습인지, 성공을 어떻게 확인하는지, 어떤 제약을 지켜야 하는지를 알려 주면 돼요. Codex는 그 결과에 도달하거나, 잠시 멈추거나, 여러분의 입력이 필요해질 때까지 그 목표를 향해 일해요. 작업이 바뀌면 목표를 멈추거나 다시 시작하거나 수정하거나 지울 수 있어요. /goal을 쓸 수 없다면 목표 기능을 활성화해야 할 수도 있어요.

과제에 분명한 도착지가 있지만 여러 단계를 거쳐야 한다면 /goal을 쓰세요. ‘모든 사실 주장에 출처를 달아라’, ‘하우스 스타일에 맞춰라’, ‘내 검토 없이는 절대 보내지 마라’ 같은 상시 지시는 목표가 아니라 프로젝트 파일이나 재사용 가능한 스킬에 두는 게 맞아요.

목표와 스킬의 차이를 볼까요. 스킬은 반복되는 종류의 작업을 어떻게 처리할지 Codex에게 가르쳐 줘요. 목표는 한 번의 긴 작업에서 무엇을 이루려 하는지를 가리키죠. 그 목적이 충족되면 목표는 완료돼요.

플러그인

플러그인은 재사용 가능한 워크플로우를 중심으로 스킬과 앱, MCP5 서버를 묶어 설치할 수 있게 만든 꾸러미예요. 흔한 워크플로우를 맨바닥부터 만들기 전에 먼저 Codex 플러그인 디렉터리를 둘러보세요. 절차가 아직 바뀌고 있는 동안에는 로컬 스킬을 쓰고, 워크플로우가 안정되어 공유하고 싶어지면 플러그인으로 패키징하세요. 워크플로우가 함께 묶인 앱이나 MCP 서버에 의존할 때도 플러그인이 유용해요.

플러그인을 설치한다고 그 플러그인에 무제한 접근 권한이 주어지는 건 아니에요. 플러그인에 딸린 앱과 MCP 서버는 여전히 각자의 인증과 권한, 개인정보 규칙, 그리고 워크스페이스 정책을 따라요. 설치할 수 있는 플러그인은 요금제와 지역, 워크스페이스 설정에 따라 달라질 수 있어요.

사이트

사이트는 계획서·보고서·대시보드를 비롯한 작업 자료를 호스팅되는 웹페이지나 웹 앱으로 바꿔 줘요. 사람들이 진행 상황을 기억하고 주기적인 작업을 뒷받침해 주는 공유 작업 공간이 필요할 때 사이트를 쓰세요. 그냥 읽기만 하면 된다면 문서로 두면 돼요. 지속 저장소를 설정해 두면 사이트가 진행 상황을 기억할 수 있어요.

먼저 바탕이 되는 워크플로우를 손으로 직접 돌려 보세요. 사이트를 만들 만하다고 판단되면, 배포하기 전에 검토용 버전을 저장하세요. 모든 배포 URL은 프로덕션 배포예요. 그러니 접근 범위를 넓히기 전에 내용과 데이터 처리 방식, 접근 설정, 대상 독자를 확인하세요. 사이트는 워크스페이스 관리자에게만, 워크스페이스 전체 구성원에게, 또는 특정 구성원과 그룹에게만 공개하도록 제한할 수 있어요.

모바일에서 쓰는 Codex

Codex 모바일 접속을 쓰면 ChatGPT 모바일 앱으로 호스트 컴퓨터의 Codex 앱을 원격 제어할 수 있어요. 모바일 앱은 워크플로우의 가벼운 부분에 잘 맞아요. 어디서든 작업을 시작하거나, 질문에 답하거나, 동작을 승인하거나, 초안을 검토할 수 있죠. 연결된 호스트는 깨어 있고, 온라인 상태이며, 최신 Codex 앱이 실행 중이고, 같은 계정과 워크스페이스에 로그인되어 있어야 해요. 더 무거운 검토는 큰 화면에서 하는 게 좋아요. 셋업에 필요한 조건은 OpenAI의 원격 연결 가이드를 참고하세요.

Codex가 아닌 것

쓸모 있는 규칙들

어떤 작업이 다음 특징 중 두 가지 이상을 갖췄다면, Codex에 맡기기 좋은 후보예요.

• 여러 출처에서 데이터를 끌어와야 하는 일
• 정기적으로 반복하는 단계가 들어가는 일
• 객관적인 기준에 비춰 확인할 수 있는 일
• 지속 가능한 산출물(문서, 계획서, 보고서, 스크립트)을 만들어 내는 일
• 여러 입력을 종합할 때 효과가 커지는 일
• 충분히 성가셔서 늘 미루거나 피하게 되는 일

위임하기 좋은 작업은 이래요.

• 반복 가능
• 객관적
• 검증이 쉬움
• 위험이 낮음

협업이 어울리는 작업은 이래요.

• 모호함
• 판단이 많이 필요함
• 탐색적
• 반복적으로 다듬어야 함

Codex 지식 노동 루프

지속 가능한 Codex 워크플로우는 모두 똑같은 다섯 단계 패턴을 따라요.

연결(Connect) → 맥락 부여(Contextualize) → 위임/협업(Delegate/collaborate) → 검토(Review) → 복리로 쌓기(Compound)

연결: 일에 쓰는 시스템들(Gmail, Slack, Notion, Google Drive, 캘린더, 분석 도구, 고객 지원 플랫폼, 또는 로컬 파일)에 Codex가 접근할 수 있게 해 주세요. 연결된 앱이나 원본 접근이 없으면 Codex는 접근 가능한 로컬·프로젝트 파일과 업로드하거나 링크한 자료, 그리고 스레드에서 직접 준 맥락에만 묶여요. 연결이 되어 있으면, 여러분이 프롬프트에 붙여 넣은 것에만 기대지 않고 승인된 출처를 직접 검색할 수 있어요.

맥락 부여: 여러분의 목표와 선호, 프로젝트 세부 사항, 출처 링크, 검토 기준, 상시 규칙을 Codex가 접근할 수 있는 파일에 담고, 그 파일들을 Codex의 AGENTS.md 파일에서 인용해 바로 불러올 수 있게 하세요. 이게 매번 다시 브리핑해 줘야 하는 에이전트와, 여러분이 누구인지·무슨 일을 하는지·어떻게 일하길 좋아하는지를 이미 이해하고 있는 에이전트의 차이예요.

위임/협업: 그 작업이 긴밀한 협업이 필요한지, 아니면 알아서 돌게 둬도 되는지를 정하세요. 어느 쪽이든 입력과 산출물 형식, 그리고 합격 기준을 명시한 다음 일을 맡기세요.

검토: 산출물은 결과물이 도착하는 앱(destination app)에서 확인하세요. Codex가 Slack 메시지를 초안으로 썼다면 Slack에서 검토하고, 전략 문서를 썼다면 Google Docs나 Notion, Proof처럼 평소에 쓰는 워드 프로세서에서 검토하세요. 터미널이나 Codex 앱에서는 괜찮아 보이던 내용도 막상 실제로 쓰일 공간에서는 다르게 읽힐 수 있어요.

복리로 쌓기: 잘되는 건 재사용할 수 있는 것으로 바꾸세요. 프롬프트를 저장하고, 워크플로우를 문서로 남기세요. 실수는 검토 체크리스트에 추가하고, 맥락 파일은 늘 최신으로 유지하세요. 매 세션이 다음 세션을 더 빠르게 만들어야 해요.

• • •

2부: 셋업

시스템 연결하기

Codex가 접근하길 원하는 도구들을 연결하세요. Gmail, Slack, Notion, Google Drive, 캘린더, 분석 도구, 고객 지원 플랫폼 등 Codex가 연동을 지원하는 것이라면 무엇이든 포함돼요. 관련 도구를 연결하고 나면 Codex는 실제 업무 맥락을 살펴보고, 여러분의 메시지·파일·회의·반복 작업을 바탕으로 워크플로우를 제안할 수 있어요.

도구를 연결하는 것과, 그 도구로 무엇이든 할 수 있는 무제한 권한을 Codex에 주는 것은 다른 얘기예요. 실제 워크플로우를 굴릴 수 있는 가장 좁은 권한부터 시작하세요. 연결된 도구의 데이터를 Codex가 변경하기 전에는 반드시 승인을 거치게 하세요. 플러그인과 앱은 각자의 인증, 프라이버시, 데이터 공유, 워크스페이스 정책의 적용을 그대로 받아요.

Codex가 도구에 접근하는 방식

Codex는 같은 도구라도 여러 경로로 접근할 수 있는데, 어떤 접근 경로가 무엇인지 알아 두면 혼란을 크게 줄일 수 있어요:

• 로컬 파일은 열어 둔 프로젝트 안의 자료에 Codex가 직접 접근하게 해 줘요
• 앱은 Slack, Gmail, Notion, Google Drive 같은 외부 서비스에 Codex를 연결해요
• 스킬은 특정 종류의 작업에 쓰는 재사용 가능한 지시, 참고 자료, 때로는 스크립트까지 묶어 줘요
• MCP 서버는 추가 도구나 공유 정보를 노출해 줘요
• 플러그인은 스킬, 앱, MCP 서버를 설치 가능한 워크플로우로 묶어요
• 브라우저 사용은 인앱 브라우저에서 로컬 미리보기, 파일 기반 페이지, 허용된 웹사이트를 다뤄요. 로그인이 필요한 사이트는 Chrome 확장 프로그램이나 다른 인증된 화면이 있어야 해요.
• 컴퓨터 사용은 가능한 경우 데스크톱 인터페이스 안에서 직접 클릭하고 입력해요. 프로젝트 폴더 밖의 파일과 설정에까지 영향을 줄 수 있으니, 이런 작업은 범위를 좁게 유지하세요

경험칙은 이래요. 쓸 수 있는 것 중 가장 구조화된 경로를 쓰세요. 로컬 파일이나 앱 연결부터 시작하세요. 브라우저나 컴퓨터 제어는 정말로 그 인터페이스에 의존해야 하는 작업일 때만 쓰세요.

시작 프롬프트 — 연동을 모두 설정한 뒤에 사용하세요.

프롬프트

내가 업무에 쓰는 도구들에 연결해 줘: [내 도구 나열 — Gmail, Slack, Notion, Drive 등]. 그런 다음 그 도구들 전반에서 내 업무 패턴을 살펴보고, 내가 가장 먼저 설정해야 할 워크플로우 세 가지를 제안해 줘. 각각에 대해 입력 소스, 산출물, 실행 주기, 승인 방식, 그리고 그 워크플로우를 장기적으로 유지할 만한 가치가 무엇인지 설명해 줘.

도구를 연결해 두면 Codex는 여러분의 실제 업무를 살펴보고 쓸 만한 워크플로우를 제안할 수 있어요. 단지 반복된다고 해서 그 작업을 자동화해야 한다는 뜻은 아니에요.

Codex 작업 공간 만들기

워크플로우를 돌리기 전에 Codex 작업 공간부터 만드세요. 이 단계를 건너뛰면 십중팔구 막히게 돼요.

Codex 작업 공간은 하나의 폴더예요. 여러분의 컴퓨터에 로컬로 두되, 버전 관리를 원하면 GitHub에 동기화할 수도 있어요. 이 폴더 안에는 Codex가 필요로 하는 지시, 맥락 파일, 워크플로우 문서, 소스, 검토 기준이 담겨요. 여러분과 에이전트 둘 다 둘러볼 수 있는 온보딩 매뉴얼이자 업무용 서류함이라고 생각하면 돼요.

전체 정리 체계를 처음부터 혼자 설계하려 들지 마세요. 먼저 Codex에게 여러분을 인터뷰해 달라고 하세요.

프롬프트

내 지식 노동을 위한 작업 공간을 만드는 걸 도와줘.

내 직무, 담당 업무, 진행 중인 프로젝트, 반복 업무, 소스 시스템, 협업자, 산출물 형식, 업무 선호, 검토 기준, 안전 경계에 대해 한 번에 한 가지씩 질문해 줘.

인터뷰가 끝나면 알게 된 내용을 정리하고, 우리 둘 다 둘러보기 쉬운 작업 공간 구조를 제안해 줘. 최상위 파일과 폴더 각각의 용도를 설명해 줘. 내가 그 계획을 승인하기 전에는 아무것도 만들거나 옮기거나 이름을 바꾸거나 보관하거나 삭제하지 마.

이미 정리 체계가 있다면, Codex에게 그걸 살펴보게 한 뒤 꼭 필요한 최소한의 추가만 제안하게 하세요. 모든 업무를 새 ‘AI’ 폴더로 옮길 필요는 없어요. 신뢰 기준 원본(source of truth)6은 지금 있는 자리에 그대로 두고, Codex에게 그곳으로 가는 명확한 지도를 쥐여 주세요.

작업 공간 구조 예시

your-workspace/
├── README.md                  # Start here—orientation
├── identity/                  # About you
│   ├── context.md
│   ├── preferences.md
│   └── rules.md
├── playbooks/                 # Process—repeatable workflows
│   ├── workflows/
│   ├── inbox-sweep.md
│   └── research-brief.md
├── sources/                   # Source shelf—inputs
│   ├── sources/
│   ├── key-links.md
│   └── recurring-docs.md
├── outputs/                   # Finished work
│   ├── outputs/
│   ├── drafts/
│   └── reports/
└── reviews/                   # Quality checks—guardrails
    ├── data-checklist.md
    └── writing-checklist.md

여기서 하고 있는 일에는 이름이 있어요. 바로 맥락 엔지니어링(context engineering)이에요. Codex가 적절한 순간에 적절한 정보를 찾을 수 있도록 지시와 소스 자료를 배치하는 일이죠.

Codex는 작업을 시작하기 전에 AGENTS.md를 읽어요. 루트 파일은 짧게 유지하세요. 에이전트의 방향을 잡아 주고, 권위 있는 파일들을 가리키고, 작업 공간 전체에 적용되는 규칙을 적어 두세요. 상세하거나 프로젝트별로 다른 지시는, 그 지시가 적용되는 폴더 안에 더 가까이 둔 AGENTS.md에 넣으세요. Codex는 해당되는 파일들을 결합하되, 더 구체적인 지시가 우선해요.

보조 파일은 제 몫을 할 때만 쓰세요. context.md는 여러분이 누구이고 무슨 일을 하고 있는지 설명할 수 있고, preferences.md는 일을 어떻게 처리하길 원하는지 적을 수 있고, rules.md는 승인 경계를 정의할 수 있고, STATUS.md는 현재 우선순위와 아직 결정되지 않은 사안을 기록할 수 있어요. 최신 상태로 유지되는 작은 작업 공간이, 아무도 관리하지 않는 거창한 작업 공간보다 나아요.

맥락 파일에 무엇을 담을까

context.md에 담을 내용:

• 여러분의 직무와 책임지는 기능
• 진행 중인 프로젝트와 현재 상태
• 매일 쓰는 도구와 각각의 용도
• 가장 긴밀하게 함께 일하는 사람이나 팀
• 여러분의 환경에서 보통 어떻게 결정이 내려지는지

preferences.md에 담을 내용:

• 글쓰기 스타일과 톤(격식체냐 대화체냐, 간결하냐 자세하냐)
• 커뮤니케이션 선호(나가기 전에 검토하고 싶은 것과, 내 관여 없이 초안을 만들어 대기열에 넣어도 되는 것)
• 의사 결정 선호(행동하기 전에 물어봐야 할 때와, 그냥 진행한 뒤 보고하면 되는 때)

rules.md에 담을 내용:

• 명시적 승인 없이는 Codex가 절대 해서는 안 되는 일: 전송, 게시, 보관, 삭제, 신뢰 기준 원본 수정, 송금
• 물어보지 않고 해도 되는 일: 초안 작성, 요약, 리서치, 개요 작성, 정리
• 여러분의 업무에 특정한 상시 제약(예: 고객 기밀 유지 규칙, 브랜드 기준, 데이터 처리 요건)

시작 프롬프트 — Codex가 작업 공간 구조를 만들게 하려면 이걸 쓰세요.

프롬프트

이 폴더를 지식 노동용 간단한 Codex 작업 공간으로 설정해 줘. 먼저 짧은 루트 AGENTS.md부터 만들고, 거기에 이 작업 공간이 무엇을 위한 것인지, 어떤 파일이 권위 있는지, 중요한 작업을 어떻게 검증하는지, 어떤 행동에 내 승인이 필요한지를 적어 줘. 승인된 계획에 필요한 보조 파일 — 맥락, 선호, 상태, 소스 맵, 워크플로우, 검토 파일만 만들어 줘.

끝내기 전에, 내 직무, 현재 우선순위, 신뢰 기준 원본, 승인 규칙을 나에게 다시 설명하는 방식으로 설정을 점검해 줘. 빠졌거나 모순되거나 찾기 어려운 게 있으면 표시해 줘.

• • •

3부: Codex 활용의 다섯 단계

Codex 파워 유저가 한 번에 그 자리에 도달하는 건 아니에요. 단계를 밟아 가며 거기에 이르고, 각 단계마다 Codex가 무엇을 하고 있고 무엇에 능한지를 다르게 생각해야 해요. 너무 빨리 앞서가면 좌절하게 돼요. 아직 Codex를 믿지 못하거나, 더 자율적인 작업을 위한 기반을 아직 갖추지 못했기 때문이죠. 어느 단계에서든, 언제 Codex에게 일을 넘기고 언제 협업자로서 루프 안에 머무를지를 알아야 해요.

이 단계들을 지위가 아니라 복잡도의 사다리로 받아들이세요. 1단계와 2단계는 초보자에게 알맞은 범위이고, 3단계는 중급, 4단계와 5단계는 고급이에요. 노련한 운영자라도 위험이 큰 작업은 1단계에 그대로 둘 수 있어요. 꼼꼼한 검토가 올바른 설계이기 때문이죠.

1단계: 일회성 지식 노동

멘탈 모델: 유능하고 꼼꼼한 리서치·초안 작성 도우미로서의 Codex.

모드: 협업. 이 단계에서는 자동화된 게 하나도 없어요. 단일 세션 작업을 돌리고, 손을 떠나기 전에 모든 걸 검토하며, Codex가 다양한 유형의 작업을 어떻게 다루는지 익숙해져 가요.

처음 해 보기 좋은 작업:

• 회의록을 요약하고 결정 사항, 미해결 질문, 후속 조치를 뽑아내기
• 흩어진 메모를 구조화된 개요로 정리하기
• 링크와 문서 묶음으로 리서치 브리프 만들기
• 스타일 가이드에 맞춰 초안 다시 쓰기
• 문서, 출시 계획, 전략 메모를 위한 검토 체크리스트 만들기
• 이동 중에 편집할 수 있도록 글 초안을 오디오 파일로 변환하기

프롬프트 패턴:

프롬프트

첨부한 [문서/링크/메모]를 이용해 [특정 산출물]을 만들어 줘. 우아함보다 정확성을 우선해 줘. 사실에 관한 주장에는 출처 링크를 달아 줘. 불확실하거나 내 확인이 필요한 건 표시해 줘. 마지막에는 이 산출물을 쓸 수 있게 되기 전에 내가 답해야 할 질문 세 가지로 마무리해 줘.

검토 습관: 결과물을 다듬기 전에, Codex에게 자신이 세운 가정과 가장 자신 없는 부분을 나열해 달라고 하세요. 그러면 다듬는 데 시간을 들이기 전에 문제가 드러나요.

다음 단계로 넘어갈 때(2단계로): 지난번에 말해 준 걸 Codex가 기억해 줬으면 하는 바람이 자꾸 들 때예요.

2단계: 다중 소스 워크플로우

멘탈 모델: 직접 손으로는 적절한 시간 안에 도저히 모을 수 없는 정보를 엮어 내는, 시스템을 가로지르는 분석가로서의 Codex.

모드: 협업. 이 단계에서 Codex는 Slack 스레드, Notion 페이지, 이메일 아카이브, 분석 대시보드, Google Drive 문서처럼 여러 연결된 시스템의 결과를 종합할 수 있지만, 여전히 안내와 피드백이 필요해요.

다중 소스 작업 예시:

• 내부 회의록, Slack 논의, 고객 노트, 전략 템플릿을 바탕으로 만든 시장 진입 계획(go-to-market plan)
• 분석 데이터, 매출 데이터, 고객 지원 처리량, 소셜 지표로 만든 주간 KPI 리포트
• Slack, Notion, Drive 링크, 과거 초안을 종합한 요약
• 팀 스탠드업, 지표, 미해결 결정 사항을 모아 만든 주간 리더십 브리프

다중 소스 작업을 위임하는 법:

프롬프트

[특정 산출물]이 필요해.

사용할 소스:

• [도구 1]: [거기서 찾을 것]
• [도구 2]: [거기서 찾을 것]
• [도구 3]: [거기서 찾을 것]

출력 형식: [원하는 구조를 설명]

시작하기 전에 짧은 계획부터 줘. 살펴볼 소스, 만들 산출물, 예상되는 빈틈이나 불확실한 점, 그리고 완료라고 부르기 전에 돌릴 점검을 짚어 줘. 전송, 게시, 보관, 또는 신뢰 기준 원본 수정이 필요한 일이 있으면 먼저 물어봐 줘.

데이터에 관한 경고: 여러 시스템에서 데이터를 한 번에 끌어오는 시도는 오래된 데이터, 정의 불일치, 권한 공백, 조인 오류 때문에 틀릴 수 있어요. 비즈니스 의사 결정이나 에이전트의 행동에 영향을 주는 지표라면, 주요 소스와 한 열씩 대조해 검증하세요. 어떤 수치가 신뢰 기준 원본에 가까울수록 더 신중하게 확인해야 해요.

산출물을 에이전트가 읽을 수 있게 만드세요: Codex로 만든 계획과 리포트는 다른 사람들이 읽지만, 점점 그들의 에이전트도 읽게 돼요. 사람이 훑어볼 수 있고 에이전트가 질의할 수 있는, 평이하고 구조화된 언어로 쓰세요. 명확한 섹션 제목, 명시적인 결정 사항, 라벨이 붙은 액션 아이템이 그 산출물을 양쪽 모두에게 유용하게 만들어요.

다음 단계로 넘어갈 때(3단계로): 같은 다중 소스 워크플로우를 일주일에 한 번 넘게 돌리면서, 이게 자동으로 일어났으면 하는 바람이 자꾸 들 때예요.

3단계: 반복 워크플로우

멘탈 모델: 예측 가능한 반복 업무를 여러분 대신 처리해 주는 자동화된 운영 계층으로서의 Codex.

모드: 하이브리드. 어떤 작업은 완전히 예측 가능해서 주고받기 없이 돌릴 수 있어요. 이런 작업은 위임하기에 딱 좋아요. 판단, 전략, 창의적 결정이 필요한 작업은 협업에 어울려요.

쓸모 있는 경험칙: 체크리스트가 대부분의 경우를 커버한다면 실행을 위임하세요. 매번 그 작업을 다르게 생각해야 한다면 협업하세요.

어느 쪽이든 ‘컴퓨터 잡일’을 찾아보세요. 시간과 주의를 잡아먹지만, 모든 접점마다 사람의 판단이 필요하지는 않은 반복 작업 말이에요.

흔한 잡일 후보:

• 답장 초안까지 곁들인, 하루 끝의 미응답 Slack 메시지·이메일 점검
• 분석, 매출, 고객 지원 데이터로 만드는 주간 지표 브리프
• 녹화된 통화가 끝날 때마다 하는 회의 노트 정리와 액션 아이템 추출
• 고객 지원 패턴 탐지와 이슈 분류
• 편집자에게 넘기기 좋게 글을 다듬어 주는 초안-검토 패키지
• 공석에 대한 채용 리서치

워크플로우:

지속적인 워크플로우를 만들기 전에, 이 템플릿을 채우세요. 워크플로우를 돌릴 때마다 Codex가 읽어야 할 지시 파일로 저장하세요. (4부의 워크플로우들은 각각 이 캔버스를 적용한 예시예요.)

워크플로우 이름:

트리거 또는 주기:

입력 소스:

산출물:

승인 규칙:

Codex가 물어보지 않고 해도 되는 일:

Codex가 하기 전에 반드시 물어봐야 하는 일:

검증 단계:

최종 산출물이 있는 위치:

이 워크플로우를 폐기하거나 수정해야 할 때:

자동화된 워크플로우를 위한 검토 원칙: 자동화된 결과물을 Codex 안에서만 검토하지 마세요. 결과물이 도착하는 앱에서 검토하세요. Slack 메시지는 Slack에서, 이메일 초안은 Gmail에서, 문서는 워드 프로세서에서요. 결과물은 실제로 쓰일 도구에서는 다르게 보일 수 있고, 맥락이 바뀌면 종종 문제가 드러나요.

다음 단계로 넘어갈 때(4단계로): 프롬프트 기반 워크플로우가 한계에 부딪힐 때예요. 작업이 너무 복잡하거나 너무 맞춤형이라 텍스트만으로는 감당이 안 되고, 작은 스크립트나 로컬 도구가 있어야 안정적으로 돌아갈 때죠.

4단계: 맞춤 도구

멘탈 모델: 워크플로우를 더 안정적이고 빠르고 반복 가능하게 만드는 가벼운 인프라를 짓는 빌더로서의 Codex.

때로는 Codex가 내놓는 최고의 결과물이 순수한 텍스트가 아니라, 반복 워크플로우를 더 쉽게 만들어 주는 작은 스크립트, 로컬 앱, 맞춤 대시보드, 또는 검토 화면일 수 있어요.

모드: 하이브리드. 어떤 경우엔 Codex가 산출물을 독립적으로 만들어 내고, 여러분은 그걸 검토한 뒤 넘어가면 돼요. 다른 경우엔 그 산출물이 여러분과 에이전트가 함께 다듬어 가는 공간이 되기도 해요.

작은 도구가 도움이 되는 경우의 예:

• Codex 연동이 없는 API에서 데이터를 끌어와야 하는 반복 워크플로우. 짧은 스크립트가 그 연결을 안정적으로 처리해 줘요.
• 형식이 입혀진 결과물을 소스와 나란히 봐야 하는 검토 과정. 간단한 로컬 앱이 그런 화면을 제공해 줘요.
• 정해진 일정에 돌아가야 하는 작업. 프롬프트를 수동으로 테스트하고 권한, 검토, 실패 시 동작을 정의해 두면 Codex 자동화가 처리해 줘요.
• 시간이 지나며 구조화된 데이터가 쌓이는 워크플로우. 가벼운 데이터베이스나 구조화된 파일이 그걸 지속적으로 추적해 줘요.
• 문서로 감당하기엔 너무 커진 리포트나 검토 대기열. 사이트는 사람들에게 작업을 함께 볼 수 있는 공간을 주고, 작은 앱은 진행 상황을 기억하면서 사람들이 항목을 승인하거나 거부하게 해 줘요.

비개발자를 위한 실용적 접근:

1. Codex에서 작업을 수동으로 한 번 돌려서 결과물이 원하는 대로 나오는지 확인하세요
2. Codex에게 물어보세요: “이 워크플로우에서 어떤 단계를 작은 스크립트나 도구로 더 안정적으로 만들 수 있을까?”
3. Codex에게 그 도구의 시제품을 만들고 무엇을 하는지 평이한 말로 설명하게 하세요
4. 여러분의 데이터로 돌려 보고, 결과물이 수동 과정에서 나온 것과 일치하는지 검증하세요
5. 마찰을 줄여 주는 부분만 남기세요. 이득 없이 복잡함만 더하는 건 버리세요.

Codex가 만든 도구를 쓰기 위해 코드 한 줄 한 줄을 다 이해할 필요는 없어요. 하지만 무엇이 들어가고, 무엇이 나오고, 사람이 어디에서 결과를 확인하는지는 설명할 수 있어야 해요. 그러지 못한다면 그 도구는 아직 자율적으로 돌릴 준비가 안 된 거예요.

문서나 스프레드시트로 일이 되면 그걸 우선하세요. 사이트를 쓴다면, 배포하기 전에 Codex에게 검토용 버전을 저장하게 하세요. 모든 배포 URL은 곧 프로덕션 배포예요. 접근을 넓히기 전에 콘텐츠, 데이터 처리, 접근 설정, 대상 독자를 확인하세요.

다음 단계로 넘어갈 때(5단계로): Codex에게 같은 피드백을 반복해서 주고 있고, 스스로 알아서 적용해 줬으면 하는 상시 선호가 생겼을 때예요.

5단계: 복리로 쌓이는 시스템

멘탈 모델: 유용한 워크플로우를 저장하고 검토 규칙을 유지하며, 가능한 경우 메모리나 스킬로 선호를 명문화할 때 시간이 갈수록 나아질 수 있는 시스템으로서의 Codex.

모드: 하이브리드. 어떤 지시는 에이전트가 자율 작업에 어떻게 접근할지를 좌우하고, 어떤 지시는 협업 모드에서 모델이 여러분과 어떻게 상호작용할지를 안내해요.

‘복리처럼 쌓이는’ 작업이라는 발상은 컴파운드 엔지니어링(Compound Engineering)7에서 왔어요. Kieran Klaassen과 Nityesh Agarwal이 Every의 이메일 클라이언트 Cora를 만들면서 고안한 AI 네이티브 코딩 방법론이죠. 대표적인 예는 다음번 제품 요구사항 문서(PRD)8의 뼈대를 써 주는 PRD예요. 여러분이 만든 산출물이 다음 라운드를 빠르게 해 주는 도구가 되는 거죠. 아래의 네 가지 습관은, 단지 엔지니어가 아니라 지식 노동자로서 이걸 실천하는 방법이에요.

유용한 세션 하나하나가 이후의 세션을 더 빠르고 더 안정적으로 만들어야 해요. 실제로 그렇게 하려면, 의미 있는 작업을 끝낼 때마다 네 가지를 꾸준히 해야 해요:

1. 성공한 프롬프트를 워크플로우 파일로 저장하세요. 어떤 프롬프트가 딱 맞는 결과물을 만들어 내면, 그걸 문서로 남기세요. 입력 소스, 정확한 프롬프트, 출력 형식, 검토 단계를 적어 두세요. workflows/ 폴더에 저장하세요. 다음에 같은 결과물이 필요할 때, 에이전트가 참고할 그 자료가 생기는 거예요.
2. 실수를 검토 체크리스트에 추가하세요. Codex가 뭔가 틀리면 — 어긋난 수치, 핀트가 빗나간 톤, 하지 말았어야 할 가정 — 관련 검토 파일에 구체적인 점검 항목을 추가하고, Codex에게 그 가드레일에 비춰 자기 작업을 점검하라고 지시하세요.
3. 큰 프로젝트가 끝나면 맥락 파일을 업데이트하세요. 프로젝트가 마무리되면, 무엇이 바뀌었는지 — 새 우선순위, 새 도구, 잘된 것과 안된 것 — context.md에 반영하세요. 그 파일을 가리키거나 재사용 가능한 스킬이나 워크플로우로 만들어 두면, Codex가 그 패턴을 활용할 수 있어요.
4. Codex에게 복리로 쌓을 기회를 찾아 달라고 하세요. 뭔가 유용한 일을 한 세션이 끝날 때, 이 프롬프트를 돌려 보세요:

프롬프트

방금 우리가 한 걸 바탕으로, 이 워크플로우에서 어떤 부분을 재사용 가능한 스킬이나 자동화, 작은 도구로 만들면 좋을까? 다음번에 이걸 다시 세우지 않아도 되도록, 내 프로젝트 파일에 어떤 맥락을 추가하면 좋을까?

워크플로우가 공유할 만큼 안정되면, 플러그인 디렉터리에 이미 있는 게 아닐 때만 패키징하세요. Every의 컴파운드 엔지니어링 가이드는, 잘 관리된 플러그인이 단일 프롬프트가 아니라 완결된 작업 방식 하나를 통째로 패키징하는 방법을 보여 줘요.

• • •

4부: 워크플로우 라이브러리

여기 소개하는 워크플로우는 시작을 돕기 위한 영감으로 봐 주세요. 입력과 산출물, 승인 규칙은 여러분이 쓰는 도구와 기준에 맞게 바꿔서 활용하세요.

맡은 일을 해결할 수 있는 가장 단순한 워크플로우를 고르세요. 추가 예시는 Every 내부에서 직접 테스트해 본 것들이고, 저희 비공개 시스템에 의존하지 않도록 손봐 두었어요. 이 라이브러리가 만들어진 운영 맥락이 더 궁금하다면 “모든 지식 노동을 지배하는 하나의 앱”과 “Codex 네이티브 앱의 여명”을 읽어 보세요.

1. 인박스 제로 검토 큐

추천 대상: 밀린 이메일이 늘 불안의 원천이거나, 자꾸 일을 놓치곤 하는 분.

입력 소스: Gmail이나 즐겨 쓰는 이메일 클라이언트.

산출물: 답장 초안과 제안된 처리(보관, 위임, 표시), 그리고 초안만으로는 부족해서 직접 챙겨야 한다고 표시된 이메일까지 정리한 구조화된 목록.

댄 십퍼(Dan Shipper)9는 Codex로 10일 연속 인박스 제로10를 유지했어요. 이 워크플로우를 쓰려면 Codex가 다음을 하게 하세요:

1. 앱 내 브라우저에서 실행되는 Cora로 이메일을 모아요.
2. 이메일 큐를 한 페이지로 렌더링해요.
3. 각 항목을 함께 훑어 가면서, AI가 취할 행동을 받아 적게 해요(예: “이거 조사해 줘”, “저거 초안 써 줘”, “변호사들이 요청한 문서 가져와 줘”). 채팅으로 하거나 Monologue 같은 받아쓰기 도구로 음성으로 할 수 있는데, 음성 쪽을 추천해요.

첫 프롬프트:

프롬프트

지난 [기간] 동안의 내 인박스를 쭉 훑어봐 줘.

답장이나 처리가 필요한 메일마다:

1. 분류해 줘: 답장 필요 / 처리 필요 / 보관 가능 / 이미 처리됨
2. 답장이 필요하면 preferences.md의 스타일을 참고해 내 말투로 초안을 써 줘
3. 처리가 필요하면 무슨 처리인지 분명하게 설명해 줘
4. 답장 초안만으로는 부족한 메일, 그러니까 답하기 전에 내가 직접 고민해야 하는 메일은 따로 표시해 줘

아무것도 보내지 마. 초안만 만들어 줘. 검토는 내가 Gmail에서 할게.

검토 단계: 보내기 전에 모든 초안을 Gmail에서 검토하세요. Codex 안에서 승인하지 마세요.

복리로 쌓는 법: 몇 번 돌려 본 뒤에는 분류 기준을 적은 규칙 파일을 추가하세요. 어떤 발신자를 항상 우선할지, 어떤 주제는 답장 없이 보관해도 되는지, 어떤 종류의 요청에는 사람이 직접 쓴 답장이 필요한지 같은 내용을요.

2. 매일 미응답 메시지 모아 보기

추천 대상: Slack, 이메일 등 여러 채널로 소통하다 보니 아직 답해야 할 게 무엇인지 놓치곤 하는 분.

입력 소스: Slack, Gmail, 그 밖에 쓰는 모든 소통 도구.

산출물: 답장 초안이나 제안된 반응을 곁들이고 긴급도순으로 정리한 미응답 항목 목록.

첫 프롬프트:

프롬프트

지난 24시간 동안의 내 Slack과 Gmail을 살펴봐 줘. 나한테 온 것 중에 아직 답하지 않은 걸 전부 찾아 줘.

항목마다:

1. 짧게 확인만 해도 되는 거면 답장 초안을 쓰거나 반응(엄지척 등)을 제안해 줘
2. 좀 더 신중한 답이 필요한 항목은 표시해 줘
3. 시간에 민감한 건 전부 표시해 줘

긴급도순으로 정리해서 목록을 보여 줘. 아무것도 보내지 마.

검토 단계: Slack과 Gmail에서 검토하세요.

복리로 쌓는 법: 몇 번 돌려 본 뒤에는 규칙 파일을 저장하세요. 어떤 Slack 채널이 우선순위가 높은지, 어떤 발신자에게는 항상 사람이 직접 답해야 하는지, 어떤 종류의 메시지는 답장 대신 반응만으로 처리해도 되는지를 명시해 두면 돼요.

3. 리서치 브리프

추천 대상: 회의나 피치, 콘텐츠, 전략적 의사결정을 준비하면서 어떤 주제에 대해 출처가 달린 꼼꼼한 요약이 필요한 분.

입력 소스: 제공한 링크, Notion, Drive, 웹 검색.

산출물: 배경, 핵심 사실, 미해결 질문, 출처 링크를 담은 구조화된 브리프.

첫 프롬프트:

프롬프트

[주제]에 대한 리서치 브리프를 만들어 줘.

우선할 출처: [구체적인 링크, 문서, 데이터베이스를 적어 줘].

브리프는 이렇게 구성해 줘:

• 배경: 이 주제로 똑똑하게 대화하려면 알아야 할 것
• 핵심 사실과 데이터, 각각 출처 링크를 달아서
• 이 분야의 상반된 관점이나 중요한 의견 차이
• [회의/결정/마감] 전에 내가 답할 수 있어야 하는 미해결 질문
• 더 깊이 파고들고 싶을 때 다음으로 읽을 만한 세 가지

조금이라도 확신이 안 서는 주장은 표시해 줘.

검토 단계: 출처 링크를 확인하세요. 통계는 쓰기 전에 원래 출처와 대조해 검증하세요.

복리로 쌓는 법: 브리프 템플릿을 workflows/ 폴더에 저장하세요. 브리프를 만들 때마다 자주 쓰는 출처(뉴스레터, 데이터베이스, 주요 저자)를 sources/key-links.md에 추가해 두면, Codex가 기본적으로 그 출처들을 확인해요.

4. 글쓰기 검토 루프

추천 대상: 글을 쓰는 동안 Codex가 옆에서 함께 돌아가며 작업을 점검하고, 문제를 짚어 주고, 글쓰기 흐름을 끊지 않으면서 나란히 반응해 주길 바라는 작가.

입력 소스: 파일 형태이거나 지원되는 검토 화면에 올린 초안, 그리고 작업 공간에 있는 관련 스타일 가이드, 원본 문서, 검토 기준.

산출물: 인라인 피드백과 표시된 문제, 수정 제안이 달린 주석 초안. 마지막에 한 번에 몰아서가 아니라, 글을 쓰는 내내 이어서 만들어져요.

셋업:

초안을 Proof에서 열거나 프로젝트에 파일로 올려 두세요. 작업 공간 맥락을 불러온 상태로 Codex 세션을 시작하세요. 무엇을 지켜보고 어떻게 반응할지 Codex에 상시 지침을 주세요.

첫 프롬프트:

나는 지금 [글에 대한 설명—유형, 독자, 목적]을 쓰고 있어.

프롬프트

글을 써 나가는 동안, 끊기지 않는 검토 루프를 돌려 줘. 다음을 점검해 줘:

• 출처가 필요하거나, 근거가 뒷받침하는 것보다 더 확신에 차서 단정한 주장
• 논지가 흐려지거나 논리에 빈틈이 생기는 대목
• preferences.md의 스타일 선호를 어기는 문장
• 군더더기, 뜸 들이는 말, AI가 쓴 듯한 표현으로 읽히는 부분

요청하지 않으면 아무것도 고쳐 쓰지 마. 진행하면서 문제를 표시하되, 무엇이 문제이고 어떻게 고치면 되는지 짧게 메모를 붙여 줘. [X분 / X문단]마다, 아니면 내가 요청할 때 확인해 줘.

검토 단계: 표시된 문제는 자연스럽게 멈추는 지점—섹션이나 세션이 끝날 때—에 읽으세요. 어떤 걸 반영하고 어떤 걸 넘길지 정하세요. 피드백 루프가 글쓰기 흐름을 끊게 두지 마세요. 가치는 표시가 쌓이는 데 있지, 매번 실시간으로 반응하는 데 있지 않아요.

복리로 쌓는 법: 글쓰기 세션이 끝날 때마다 반복되는 표시를 reviews/writing-checklist.md에 추가하세요. 거듭 나타나는 패턴은 선호 파일에 넣을 상시 규칙 후보예요. 그러면 Codex가 다음번에 그 부분을 점검해요.

5. 리서치를 위한 출처 관리

추천 대상: 초안을 쓰기 전에 출처 자료를 정리해야 하는 작가와 리서처.

입력 소스: 링크, PDF, 지난 초안, 메모, 회의록.

산출물: 핵심 논지, 주장별로 정리한 뒷받침 근거, 반론, 그리고 빈틈 분석(아직 빠진 것)이 담긴 구조화된 문서.

첫 프롬프트:

프롬프트

나는 [주제]에 대한 글을 쓰고 있어. 내가 펼치려는 핵심 논지는 [논지]야.

내 출처 자료는 이거야: [링크/문서].

다음과 같은 ‘근거 자료실’을 만들어 줘:

1. 핵심 논지를 분명하게 정리해 줘
2. 각 핵심 포인트마다 가장 강력한 뒷받침 근거를 출처 링크와 함께 나열해 줘
3. 가장 강력한 반론과, 내가 그걸 어떻게 받아칠 수 있을지 나열해 줘
4. 빈틈을 짚어 줘—내가 펼치는 주장 중에 강력한 근거가 없는 것
5. 서로 충돌하는 출처가 있으면 표시해 줘

검토 단계: 초안을 쓰기 전에 근거 자료실을 읽으세요. 직접 인용할 통계나 문구는 검증하세요.

복리로 쌓는 법: 이 근거 정리 형식을 워크플로우 템플릿으로 저장하세요. 맥락 파일에 자신의 글쓰기 말투와 반복되는 주제에 대한 상시 메모를 추가해 두면, Codex가 그에 맞게 틀을 잡아요.

6. 오디오 브리핑

추천 대상: 읽기보다 듣기로 정보를 더 잘 받아들이는 분, 또는 화면에서 잠시 벗어나면서도 일을 놓치고 싶지 않은 분.

입력 소스: 모든 글—초안, 리서치 브리프, 회의 요약, 전략 문서, 보고서, 긴 이메일, 기사 등.

산출물: 휴대폰에서 접근할 수 있는 위치(Dropbox, Drive 등)에 저장된 오디오 파일.

첫 프롬프트:

프롬프트

첨부한 [문서/초안/보고서]를 또렷한 오디오 파일로 변환해 줘. 너무 빠르지도, 느리지도 않게 자연스러운 속도로 읽어 줘. [Dropbox/Drive 위치]에 [파일명]으로 저장해 줘.

검토 단계: 출퇴근길이나 산책 중, 화면에서 벗어나 시간이 나는 곳 어디서든 들어 보세요. 떠오르는 게 있으면 휴대폰에 메모하세요. 알아챈 내용을 들고 원본 자료로 다시 돌아오세요.

복리로 쌓는 법: 속도, 파일 형식, 이름 규칙, 선호하는 저장 위치 같은 오디오 선호 사항을 맥락 파일에 상시 지침으로 추가해 두세요. 그러면 매번 일일이 지정하지 않아도 돼요. 특정 워크플로우가 끝날 때 Codex가 콘텐츠를 자동으로 변환하도록 시킬 수도 있어요: “주간 지표 보고서를 만든 뒤에는 오디오로 변환해서 [위치]에 저장해 줘.”

7. 시장 진입 계획(go-to-market plan)

추천 대상: 제품이나 기능, 이니셔티브를 출시하는 일을 맡고 있고, 회의와 Slack에서 고민은 다 해 놓았지만 그걸 정리할 시간이 없었던 분.

입력 소스: 회의록, Slack 스레드, 고객 노트, 선호하는 전략 템플릿.

산출물: 사람이 검토하고 에이전트가 질의할 수 있도록 구성한 완성된 시장 진입 계획.

첫 프롬프트:

프롬프트

[제품/이니셔티브]에 대한 시장 진입 계획을 만들어 줘.

가져올 출처:

• 회의록: [Notion 위치나 링크]
• Slack 논의: [채널이나 검색어]
• 고객 리서치: [문서나 위치]
• 따를 템플릿: [링크나 템플릿 붙여넣기]

이 계획은 사람이 5분 안에 읽을 수 있어야 하고, 에이전트가 구체적인 질문에 답할 수 있도록 구성돼야 해(예: “타깃 ICP11가 뭐야?”, “출시 일정이 어떻게 돼?”).

컴파운드 엔지니어링(Compound Engineering) 브레인스토밍 단계부터 시작해 줘. 초안은 Proof나 Notion으로 줘. 계획에서 원본 자료에 없던 내용을 네가 추가했다면 전부 표시해 줘—나는 우리가 이미 정한 걸 종합한 것만 원하지, 새 제안이 슬쩍 섞여 들어가는 건 원하지 않아.

검토 단계: Notion이나 Proof에서 검토하세요. 모든 주요 주장이 원본 자료의 무언가로 거슬러 올라가는지 확인하세요. 모델이 출처에 없던 내용을 추가했다면, 여러분이 판단할 수 있도록 표시되어 있어야 해요.

복리로 쌓는 법: 템플릿과 프롬프트를 저장하세요. 출시할 때마다 그 계획이 무엇을 맞혔고 무엇을 틀렸는지 회고 메모를 맥락 파일에 추가하세요. 앞으로의 계획은 지난 계획들에 맞춰 다듬어져요.

8. KPI 보고서

추천 대상: 지표를 추적하는 일을 맡고 있고, 여러 데이터 소스를 아우르는 정기적이고 믿을 만한 현황이 필요한 분.

입력 소스: 분석 도구(PostHog, Mixpanel, Amplitude), 매출 데이터(Stripe), 고객 지원 건수, 소셜 지표, 저장해 둔 지난 보고서.

산출물: 핵심 요약, 사용 지표, 시스템 상태, 후속 항목을 다루는 한 페이지 보고서.

첫 프롬프트:

프롬프트

[기간]에 대한 제품 펄스 보고서를 만들어 줘.

데이터 소스:

• 제품 분석: [도구와 가져올 내용]
• 매출: [도구와 가져올 내용]
• 고객 지원: [도구와 가져올 내용]
• 소셜: [도구와 가져올 내용]

구성:

1. 핵심 요약 (가장 중요한 것을 정리한 3~5개 불릿)
2. 사용 (핵심 인게이지먼트 지표, 가치 실현 지표, 전환, 이전 기간 대비 증감)
3. 시스템 상태 (오류율, 지연 시간, 주요 오류 시그니처)
4. 후속 항목 (살펴볼 만한 1~5가지, 바로 실행할 수 있을 만큼 구체적으로)

이전 보고서와 크게 다른 수치는 전부 표시해 줘. 이상한 게 있으면 포함하기 전에 한 단계 더 깊이 들여다봐 줘.

검토 단계: 보고서의 모든 수치를 출처와 대조해 검증하세요. 열 단위로 정확성을 확인하기 전까지는 이 보고서를 비즈니스의 신뢰 기준 원본(source of truth)으로 쓰지 마세요. 정의가 다르거나 레코드가 잘못 매칭되면, 실제로는 틀렸는데도 보고서가 맞아 보일 수 있어요.

복리로 쌓는 법: 보고서를 각각 날짜가 붙은 파일로 outputs/reports/ 폴더에 저장하세요. 시간이 쌓이면 Codex가 보고서들을 비교하고, 추세를 파악하고, 무언가 달라졌을 때 표시할 수 있어요. 그 폴더가 여러분 제품의 작업 기억이 돼요.

9. 고객 지원 이슈 큐

추천 대상: 지원 과정에서 드러나는 패턴이 제품 결정과 소소한 수정으로 이어져야 하는 팀.

입력 소스: 지원 플랫폼(Intercom, Zendesk), 이슈 트래커(Linear, GitHub Issues).

산출물: 중복을 제거하고 우선순위를 제안한 이슈 목록, 그리고 바로 수정 작업으로 넘길 수 있는 소소한 이슈들.

첫 프롬프트:

프롬프트

지난 [기간] 동안의 지원 큐를 훑어봐 줘.

각 지원 스레드마다:

1. 밑바탕에 깔린 문제나 요청이 뭔지 파악해 줘.
2. [Linear/GitHub Issues]에 비슷한 이슈가 이미 있는지 확인해 줘.
3. 있으면 서로 연결하고, 없으면 새 이슈를 작성해 줘.
4. [기준치]번 넘게 나타나는 이슈는 표시해 줘. 이런 게 우선순위야.
5. 고치기 간단해 보이는 이슈는 바로 구현할 후보라고 메모해 줘.

아직 트래커에 이슈를 만들지는 마. 먼저 검토할 수 있게 목록부터 줘.

검토 단계: 무엇이든 트래커에 들어가기 전에 이슈 목록을 검토하세요. 중복 제거가 정확한지 확인하세요. 지원 티켓은 같은 근본 문제를 서로 다른 표현으로 설명하는 경우가 많아요.

복리로 쌓는 법: 세션이 끝날 때마다 반복되는 이슈 유형에 대한 메모를 남겨, 다음번에 Codex가 더 빠르게 분류하게 하세요. 이미 알려진 이슈 목록을 꾸준히 쌓아 두면 중복 제거가 점점 더 정확해져요.

10. 비개발자를 위한 풀 리퀘스트

추천 대상: 깊은 엔지니어링 지식 없이도 코드베이스에 작고 범위가 명확한 변경(문구 수정, 설정 변경, 콘텐츠 편집 등)을 해야 하는 사람.

입력 소스: 관련 파일이나 저장소, 그리고 변경 내용에 대한 명확한 설명.

산출물: 리뷰어가 보기 편하고 의도한 범위 밖은 건드리지 않는 풀 리퀘스트(PR).

첫 프롬프트:

프롬프트

다음 변경을 하려고 해: [변경 내용을 명확하게 설명].

변경을 시작하기 전에:

1. 어떤 파일이 영향을 받는지 보여줘.
2. 변경 범위를 확인해 줘. 이 파일들 밖은 아무것도 건드리면 안 돼.
3. 실제로 하기 전에 무엇을 할 건지 쉬운 말로 설명해 줘.

변경을 마친 뒤에는:

1. 무엇을 왜 바꿨는지 요약해 줘.
2. 손댄 파일을 전부 나열해 줘.
3. 변경이 올바른지 어떻게 확인했는지 설명해 줘.
4. 리뷰어가 주의 깊게 봐야 할 부분이 있으면 표시해 줘.

쓸모 있는 최소한의 변경만 해 줘. 주변 코드를 리팩터링하거나 개선하지는 마.

검토 단계: PR을 열기 전에 Codex 미리보기를 검토하세요. PR 자체는 GitHub나 사용하는 코드 리뷰 도구에서 검토하세요. 확신이 서지 않으면 병합하기 전에 기술을 잘 아는 동료에게 승인을 받으세요.

복리로 쌓는 법: 선호하는 PR 양식을 템플릿으로 저장하세요. PR을 마칠 때마다 바로잡아야 했던 부분을 메모해 두면, 앞으로의 PR이 같은 문제를 피할 수 있어요.

11. 채용 숏리스트

추천 대상: 특정 배경 조건을 갖춘 사람을 직접 찾아 나서는 아웃바운드 채용을 하는 사람.

입력 소스: LinkedIn, Twitter/X, 회사 웹사이트, 동문 데이터베이스, 공개된 전문가 네트워크.

산출물: 배경 요약과 연락처 또는 접점이 정리된 후보 목록.

첫 프롬프트:

프롬프트

[직무]를 채용하려고 해. 이상적인 후보는 [배경 조건 — 경력, 이전 회사, 역량, 커리어 경로]을(를) 갖추고 있어.

이 조건에 맞는 후보를 찾아 줘. 후보마다:

1. 배경을 두세 문장으로 요약해 줘.
2. 왜 조건에 맞는지 적어 줘.
3. 접점(공통 인맥, 팔로우 관계, 공통 소속)이 있으면 찾아 줘.
4. 공개 프로필 링크를 달아 줘.

조건에 얼마나 잘 맞는지를 기준으로 상위 [숫자]명의 후보를 순위대로 정리해 줘.

검토 단계: 연락을 취하기 전에 후보를 한 명씩 검토하세요. 링크된 프로필을 확인해 배경 요약이 정확한지 검증하세요. Codex를 통해 직접 연락을 보내지는 마세요.

복리로 쌓는 법: 직무 조건을 템플릿으로 저장하세요. 채용에 성공한 뒤에는 실제 합격자의 배경이 처음 세운 조건과 어떻게 달랐는지 기록해 두면, 앞으로의 탐색을 더 정교하게 다듬을 수 있어요.

12. 전략 계획

추천 대상: OKR 수립, 분기 계획, 전략 리뷰에 들이는 시간을 며칠에서 몇 시간으로 줄여야 하는 리더와 실무 운영자.

입력 소스: 과거 기획 문서, 회의록, 리더십 맥락 메모, 관련 지표.

산출물: 검토와 반복 수정에 맞게 구조화된 계획 초안 또는 OKR 세트.

첫 프롬프트:

프롬프트

[범위]에 대한 [분기 계획 / OKR 세트 / 전략 리뷰] 초안을 만들어야 해.

다음 자료에서 가져와 줘:

• 과거 계획: [위치]
• 최근 회의록: [위치]
• 현재 지표: [위치 또는 설명]
• 리더십 맥락: [문서 또는 설명]

결과물은 [원하는 형식]으로 구성해 줘.

원본 자료에 명확한 근거가 없는데도 추천하는 목표나 과제가 있으면 표시해 줘. 나는 이미 결정된 내용을 종합한 결과를 원하지, 내 검토 없이 슬쩍 끼워 넣은 새 제안을 원하는 게 아니야.

검토 단계: Notion이나 Proof에서 검토하세요. 리더십이나 팀과 공유하기 전에, 모든 주요 약속이 실제로 내려진 결정에서 비롯됐는지 확인하세요.

복리로 쌓는 법: 기획 사이클이 끝날 때마다 맥락 파일에 회고를 남기세요. 목표가 실제로 달성 가능했나요? 처음 계획에서 빠졌던 건 무엇이었나요? 앞으로의 기획은 지난 사이클의 경험을 바탕으로 더 나아져요.

13. 개인 학습 도구

추천 대상: Codex를 활용해 역량을 키우거나 연습하거나 스스로 주도하는 학습을 하고 싶은 사람.

입력 소스: 외부 API, 파일, 구조화된 연습 자료, 본인의 메모.

산출물: 학습 목표에 맞춰 만든 맞춤형 인터랙티브 도구 — 예를 들면 튜터, 퀴즈, 연습 환경 같은 것.

예시:

어떤 음악가가 화음 알아맞히기를 연습하고 싶어 해요. MIDI 키보드를 연결하고 원하는 바를 설명하면, Codex가 연주를 듣고 화음을 식별하며 시간에 따른 진척을 추적하는 작은 앱을 만들어 줘요.

첫 프롬프트:

프롬프트

[기술이나 주제]를 위한 개인 학습 도구를 만들고 싶어.

지금 내 수준: [초급/중급/이미 알고 있는 것].

연습하고 싶은 것: [그 기술의 구체적인 부분].

원하는 피드백 방식: [즉시/세션마다/점수로].

로컬에서 쓸 수 있는 프로토타입을 만들어 줘. 시작하기 전에 그게 뭘 하는지, 어떻게 쓰는지 설명해 줘.

검토 단계: 본격적으로 쓰기 전에 실제 연습 자료로 도구를 시험해 보세요. 의도한 바를 제대로 테스트하고 있는지 확인하세요.

복리로 쌓는 법: 연습 세션이 끝날 때마다 가장 도움이 됐던 점과 가장 도움이 안 됐던 점을 바탕으로 도구를 개선해 달라고 Codex에 요청하세요. 필요가 분명해질수록 도구도 점점 나아져요.

14. 살아 있는 아이디어 뱅크

추천 대상: 편집 기획, 제품 아이디어, 고객 요청, 리서치 단서처럼 쓸 만한 신호가 조금씩 쌓이는 모든 영역.

입력 소스: 승인된 채널과 문서, 공개 자료, 기존 콘텐츠, 그리고 점수 평가 기준(루브릭).

산출물: 근거, 상태, 중복 여부, 그리고 가장 작은 다음 행동까지 관리되는 백로그.

첫 프롬프트:

프롬프트

[분야]를 위한 아이디어 뱅크를 만들어 줘. 후보마다 문제나 기회, 출처 링크, 이미 존재하는 것, 그 아이디어가 독자에게 어떻게 도움이 되는지, 상태, 그리고 가장 작은 다음 행동을 기록해 줘.

후보를 추가하기 전에 항상 기존 뱅크와 비교해 줘. 약한 신호 하나만 보고 항목을 끌어올리지는 마. 탈락한 아이디어와 탈락 사유는 그대로 보존해 줘.

검토 단계: 출처의 품질, 아이디어 중복, 그리고 시간이 지나며 기준이 흔들리지 않는지 확인하세요. 쓸 만한 게 하나도 없는 스캔이라면 뱅크를 억지로 채우지 말고 그렇다고 솔직하게 말하게 하세요.

복리로 쌓는 법: 처음에는 수집을 직접 손으로 돌려 보세요. 데이터 항목, 선별 규칙, 검토 과정이 충분히 안정적으로 자리 잡은 뒤에야 이를 스킬이나 예약 스캔으로 만드세요.

15. 공유 검토 사이트

추천 대상: 문서로 운영하기엔 불편해진 리포트, 로드맵, 소스 자료실, 대시보드, 검토 큐.

입력 소스: 이미 검증된 수동 워크플로우, 현재 산출물과 원본 데이터, 사용 대상자, 필요한 동작, 접근 규칙, 그리고 담당자.

산출물: 검토용으로 저장한 사이트 버전, 그리고 승인을 받은 뒤에야 진행하는 배포.

첫 프롬프트:

프롬프트

이 작업을 문서로 유지하는 경우, 스프레드시트로 옮기는 경우, 그리고 사이트로 만드는 경우를 비교해 줘. 누가 사용할지, 무엇을 보거나 해야 하는지, 어떤 상태를 기억해야 하는지, 정보가 얼마나 자주 바뀌는지, 누가 유지·관리할지를 바탕으로 추천해 줘.

사이트로 만들 만하다고 판단되면, 검토용 버전을 만들어 저장해 줘. 내가 콘텐츠, 데이터 처리 방식, 접근 모드, 사용 대상을 승인하기 전까지는 배포하지 마.

검토 단계: 실제 데이터와 실제 작업으로 시험해 보세요. 배포 전에 원본 변경 사항, 저장된 데이터, 접근 설정, 선택한 저장 버전을 확인하세요.

복리로 쌓는 법: 반복되는 동작을 뒷받침할 때만 기능(컨트롤)을 추가하세요. 담당자, 데이터 출처, 장애 시 동작, 그리고 언제 사이트를 정리할지에 대한 계획을 기록해 두세요.

16. 콘텐츠 업데이트 큐

추천 대상: 정기적인 업데이트가 필요하지만 절대 자동으로 바뀌어서는 안 되는 공개 페이지, 지식 베이스, 정기 리포트, 자료 목록.

입력 소스: 현재 산출물, 승인된 출처, 어떤 경우에 변경이 정당한지에 대한 명확한 규칙, 그리고 날짜가 기록된 과거 결정 내역.

산출물: 제안된 변경 사항과 그것을 뒷받침하는 근거 목록.

첫 프롬프트:

프롬프트

[산출물]을 [승인된 출처]와 대조해 검토할 만한 변경 사항을 찾아 줘. 추천 항목마다 현재 내용, 제안하는 변경, 뒷받침하는 근거, 그리고 그 업데이트가 기준(루브릭)을 통과하는 이유를 보여줘.

아무것도 편집하거나 게시하지 마. 모든 추천 항목은 검토 큐에 넣어 줘. 바꿀 만한 게 없으면 그렇다고 분명하게 알려줘.

검토 단계: 각 제안을 산출물이 도착하는 곳에서 직접 수락하거나 거절하세요. 게시 전에 링크, 날짜, 주장, 그리고 실제 렌더링된 모습을 확인하세요.

복리로 쌓는 법: 무엇을 수락하고 무엇을 거절했는지 기록하세요. 시스템은 이런 선택에서 배울 수 있지만, 승인 없이는 절대 게시해서는 안 돼요.

• • •

5부: Codex를 잘 운영하기

Codex를 이끄는 법

Codex를 잘 다루는 일은 곧 매니지먼트 업무예요. 어떤 프롬프트와 에이전트, 워크플로우를 믿을지 가려내며 인재를 평가하고, Codex를 어디에 겨눌지 그리고 “완료”가 어떤 모습이어야 하는지 비전을 세우고, 기술적으로는 맞지만 지금 이 순간에는 어울리지 않는 산출물을 잡아내는 안목을 발휘하고, 언제 내버려 둘지 언제 직접 운전대를 잡을지 아는 일이에요.

Codex에게는 결과를 주세요. 거기까지 가는 방법이 아니라, 최종적으로 무엇을 원하는지를 설명하세요. “이 소스들과 이 구조로 [주제]에 대한 리서치 브리프를 만들어 줘”가 “먼저 Slack을 검색하고, 그다음 Notion을 검색하고, 그다음…”보다 더 나은 결과를 내요.

오래 걸리는 작업 전에는 계획을 요청하세요. 몇 분 이상 걸리거나 여러 시스템을 건드리는 작업이라면, 시작하기 전에 무엇을 할 것인지 설명해 달라고 Codex에게 요청하세요. 이렇게 하면 오해를 일찍 잡아내고, 너무 멀리 가기 전에 방향을 바로잡을 기회를 얻어요.

시작하기 전에 무엇이 필요한지 Codex에게 물어보세요. 복잡한 작업에서는 짧은 브리핑 프롬프트 하나가 시간을 아껴줘요.

프롬프트

시작하기 전에, 이걸 더 잘 해내는 데 어떤 추가 맥락이 도움이 될지 알려줘. 네가 가장 알고 싶은 건 뭐야?

중요한 주장에는 인용과 감사 추적(audit trail)을 요구하세요. 공유되거나 의사결정에 쓰일 문서라면 사실 주장에 출처 링크가 있어야 해요. 이걸 선호 파일에 상시 규칙으로 정해두세요.

계획이 탄탄하다면 모든 단계를 일일이 간섭하지 마세요. 접근 방식이 틀렸거나, 전제가 바뀌었거나, 여러분이 승인하지 않은 경계에 Codex가 닿았을 때 끼어드세요. 그렇지 않으면, 검토하기 전에 하나의 일관된 패스를 끝까지 마치게 두세요.

결과물이 도착하는 앱에서 검토하세요. 항상요.

규칙 파일에 명시적인 전송 금지, 게시 금지, 보관 금지, 수정 금지 규칙을 정하세요. 이 규칙들은 민감한 워크플로우라면 기본으로 적용돼야 해요. 쉽게 되돌릴 수 없는 행동을 하기 전에는 Codex가 반드시 묻게 하세요.

어떤 의미 있는 산출물이든 승인하기 전에 던질 세 가지 질문이에요.

이걸 만들면서 내린 가장 어려운 결정은 뭐였어?

고려했다가 버린 대안은 뭐가 있었어?

어디가 제일 자신 없어?

이 질문들은 모델이 내린 판단, 모델이 버린 선택지, 그리고 오류가 들어 있을 가능성이 가장 높은 지점을 드러내 줘요.

안전, 신뢰, 그리고 리스크

흔한 실패 양상과 그 대처법이에요.

팀 워크플로우: 개인용 Codex에서 공유 운영체제로

개인의 Codex 워크플로우는 시간이 지나며 복리처럼 쌓여요. 팀 워크플로우는 더 빠르게 쌓이지만, 그만큼 조율이 필요해요.

팀이 Codex를 쓸 때 달라지는 것

팀은 에이전트를 운영하는 사람을 통해 에이전트에 대한 신뢰를 쌓아요. 동료가 Codex가 작성한 문서나 계획을 받으면, 그걸 공유한 사람을 신뢰하는 만큼만 그 결과물을 신뢰해요.

팀 단위 Codex가 작동하게 하는 인프라

공유 검토 화면. 공유 문서 검토 도구(Proof, Notion, Google Docs)를 쓰면, Codex 안에서만 검토하는 결과물보다 에이전트가 생성한 문서를 훨씬 쉽게 살펴보고 코멘트를 달 수 있어요.

명시적인 핸드오프. 서브에이전트는 자신을 만든 작업으로 결과를 보고하고, 예약된 스레드 작업은 자기 대화 안에 머물러요. 서로 다른 스레드는 업데이트를 자동으로 공유하지 않아요. 한 스레드가 다른 스레드의 작업물이 필요하면, 명확한 핸드오프를 보내고 그 결과를 공유 파일이나 검토 도구에 저장하세요. 워크플로우마다 담당자와 승인 규칙을 정해두세요.

공유 스킬과 플러그인. 잘 관리된 스킬 하나로 팀의 검토 기준을 묶어낼 수 있고, 플러그인 하나로 워크플로우를 거기에 필요한 앱이나 MCP 연결과 함께 배포할 수 있어요. 모두에게 같은 구성을 설치하라고 하기 전에, 팀은 그 의존성과 권한을 먼저 점검해야 해요.

공유되는, 에이전트가 읽을 수 있는 문서. 사람과 에이전트 양쪽 독자를 염두에 두고 쓴 계획서, 전략 문서, 운영 가이드는 공유 인프라가 돼요. 어떤 팀원이든 — 또는 팀원의 어떤 에이전트든 — 작성자를 방해하지 않고도 거기서 필요한 정보를 조회할 수 있어요.

명확한 소유권. 지속적으로 돌아가는 모든 워크플로우에는 이름이 명시된 담당자가 필요해요. 그 사람이 산출물 품질을 모니터링하고, 워크플로우가 망가지면 고치고, 더 이상 쓸모없어지면 폐기하는 책임을 져요. 자동화는 소유자가 없으면 점점 망가져요.

팀이 Codex를 쓰게 만드는 간단한 방법

모두를 한꺼번에 바꾸려 하지 마세요. 한 직무의, 누구나 알아보는 문제 하나에서 시작하세요. 산출물, 검토 단계, 그리고 사람이 여전히 책임지는 부분을 보여주세요. 세 가지를 함께 하면 쓸 만한 워크플로우가 퍼져나가요.

1. AI 사용을 있으면 좋은 것이 아니라 당연한 기대치로 만드는 리더의 메시지
2. 누구든 자기가 만든 프롬프트나 워크플로우를 보여줄 수 있는 주간 미팅
3. 유난히 돋보인 사람들의 이름을 짚어주는 정기 메시지

기대치를 세우고, 잘 되는 걸 공유할 자리를 마련하고, 그에 대해 인정해 주세요 — 그게 싸움의 대부분이에요.

• • •

6부: 시작하기

7일 Codex 파워 유저 플랜

1일 차: 연결하고 살펴보기

Codex 데스크톱 앱을 설치하고, 프로젝트로 써도 편한 폴더 하나를 여세요. 이미 실제로 하는 일을 뒷받침하는 소스를 한두 개 연결하세요. 2부의 워크플로우 발굴 프롬프트를 실행하세요. 아직 아무것도 만들거나 자동화하지 마세요.

2일 차: Codex가 여러분을 인터뷰하게 하기

작업 공간 구조와 짧은 루트 AGENTS.md, 그리고 꼭 필요한 맥락·선호·상태·소스 맵·워크플로우·검토 파일만 제안하게 하세요. 폴더를 바꾸기 전에 그 계획을 승인하세요.

3일 차: 일회성 작업 세 개 돌리기

요약 작업 하나, 리서치 브리프 하나, 초안이나 계획 하나를 고르세요. 1단계의 프롬프트 패턴을 쓰세요. 각 산출물을 꼼꼼히 검토하고, Codex가 잘한 부분과 수정이 필요했던 부분을 기록해 두세요.

4일 차: 첫 반복 가능한 워크플로우 만들기

3일 차에서 가장 쓸모 있었던 작업을 골라 3단계의 워크플로우 캔버스를 채우세요. 작업 공간의 workflows/ 폴더에 저장하세요. 다른 입력으로 다시 돌려보고, 스케줄링을 고려하기 전에 결과물을 확인하세요.

5일 차: 검토 규칙 추가하기

reviews/data-checklist.md, reviews/writing-checklist.md, reviews/comms-checklist.md를 만드세요. 3일 차와 4일 차에 알아챈 것을 바탕으로 각각 다섯 개의 점검 항목으로 시작하세요. 이 목록들은 시간이 지나며 늘어날 거예요.

6일 차: 워크플로우 하나를 재사용 가능한 산출물로 만들기

프롬프트, 입력, 산출물 형식, 검토 단계, 알려진 예외 상황을 문서로 정리하세요. 절차가 아직 바뀌는 동안에는 워크플로우 파일로 두고, 재사용할 만큼 절차가 안정되면 스킬로 바꾸세요. 흔한 워크플로우를 처음부터 패키징하기 전에 플러그인 디렉터리를 먼저 살펴보세요.

7일 차: 복리로 쌓기

Codex 세션 끝에 복리 프롬프트를 실행하세요.

프롬프트

이번 주에 우리가 한 모든 것을 바탕으로, 어떤 부분이 재사용 가능한 스킬이나 자동화, 또는 작은 도구가 되어야 할까? 앞으로의 세션이 더 나은 출발점에서 시작하도록 내 프로젝트 파일에 어떤 맥락을 추가하면 좋을까?

Codex의 제안을 검토하고, 앞으로 한 달간 시간을 가장 많이 아껴줄 한 가지를 실행에 옮기세요.

30일 확장판

• 1주 차: 안정적으로 돌아가는 개인 워크플로우 하나
• 2주 차: 최소 세 개의 연결된 도구에서 정보를 끌어오는 멀티소스 워크플로우 하나
• 3주 차: 워크플로우나 스킬로 패키징되고 명확한 검토 규칙을 갖춘 안정적인 프로세스 하나
• 4주 차: 작업이 그럴 만한 가치가 있을 때만 — 사이트, 플러그인, 작은 도구, 또는 자동화 같은 고급 기능 하나

오늘 시작하세요: Codex에서 안전한 폴더 하나를 여세요. 이미 할 줄 아는 일 하나를 고르세요. 에이전트에게 소스를 주고, 산출물을 정의하고, 작업을 어떻게 확인할지 알려주세요. 한 번만 제대로 돌려보세요. 나머지는 거기서부터 자라나게 두세요.