Codex를 더 잘 사용하는 법: OpenAI 공식 문서 기반 사례 소개

들어가며

Codex는 더 이상 일부 "고수"들만의 전유물이 아닙니다. 한동안은 모델을 다루는 감각이 있는 사람만 제대로 써먹는 도구처럼 보였지만, 지금은 진입 장벽이 많이 낮아졌습니다. 셋업만 한 번 잘 해두면, 평소에 "이건 사람이 직접 해야지" 싶던 작업까지 Codex에게 상당 부분 넘길 수 있습니다. 정말로 "딸깍"의 시대가 가까워지고 있음을 느낍니다.

이 글에서는 두 가지를 다룹니다. 먼저 필자가 실제로 쓰고 있는 Codex 셋업과, 그 위에서 돌려본 몇 가지 작업 사례를 정리합니다. 그다음 최근 오픈AI(OpenAI)가 공개한 장기 작업용 활용 가이드 "Codex-maxxing for long-running work" 백서의 핵심 원칙을 짚고, 마지막으로 필자가 보안 실무에서 이 원칙들을 어떻게 "하네스(harness)"로 엮어 쓰고 있는지를 소개합니다.

이 글에서 다루는 보안 자동화 사례는 모두 교육·연구 목적이며, 권한이 부여된 환경에서의 진단 업무를 전제로 합니다. 제3자 시스템에 대한 무단 점검은 어떤 경우에도 정당화되지 않습니다.

 

1. 필자의 Codex 셋업

거창한 환경은 아닙니다. 핵심은 "이미 손에 익은 작업 공간 안에서 Codex를 굴린다"는 점입니다.

• 터미널 안에서 Codex CLI 실행: 별도 창을 띄우지 않고, 평소 코드를 보던 에디터의 통합 터미널이나 콘솔에서 바로 Codex CLI를 띄웁니다. 파일·프로젝트 맥락이 그대로 이어지는 게 가장 큰 장점입니다.
• Pro 계정 사용량 기반으로 동작하도록 설정: API 종량제 대신 Pro 계정의 Codex 사용량으로 돌아가도록 잡아두면, 토큰 단가를 매번 신경 쓰지 않고 장기 작업을 돌리기 편합니다. API 보다 예약요금제가 토큰당 요금이 훨씬 저렴합니다.
• bkit 플러그인 설치: 이 플러그인은 PDCA(Plan-Do-Check-Act) 사이클 패턴으로 작업을 점검하도록 유도합니다. "계획 → 실행 → 검토 → 반영"을 강제하는 흐름이 들어가면, 모델이 한 번에 다 처리하려다 길을 잃는 문제가 확실히 줄어듭니다.

여기서 핵심은 도구 그 자체가 아니라 "검토 단계가 루프 안에 박혀 있다"는 점입니다. 이 감각은 뒤에서 소개할 오픈AI 백서의 메시지와도 일치합니다.

 

2. Codex로 해본 작업들

같은 셋업 위에서 성격이 전혀 다른 작업 네 가지를 돌려봤습니다. 보안 리서치, 취약점 진단 목적으로만 사용한 것이 아닌 외부 AI 활용 강의의 보조강사, 교육 강좌를 진행하면서 다양한 영역에서 직접 활용하면서 체득하였습니다.

2-1. 기업 조사 후 프레젠테이션(PPT) 생성

Presentation 플러그인을 활용해, 특정 기업을 조사하고 그 결과를 슬라이드로 정리하는 흐름을 만들었습니다. 자료 수집과 구조 잡기, 슬라이드 초안 생성까지를 하나의 작업으로 묶으니, "리서치 → 문서화"의 왕복 비용이 크게 줄었습니다.

2-2. Figma 랜딩 페이지 제작

Figma use 스킬을 적용하고, 디자인 규칙을 담은 Design.md까지 함께 물려 랜딩 페이지를 제작해봤습니다. 솔직히 큰 기대는 안 했는데, 생각보다 결과물이 잘 나왔습니다. 디자인 의도를 문서로 명확히 전달할수록 산출물 품질이 올라간다는 걸 다시 확인했습니다.

2-3. ERP 대시보드 바이브 코딩

bkit 플러그인을 활용해 ERP 대시보드 서비스의 1차 초안을 바이브 코딩(vibe coding)으로 제작했습니다. PDCA 루프가 들어가 있으니, 한 번에 완성을 노리기보다 "초안 → 검토 → 보강"으로 단계를 쪼개서 진행하기 수월했습니다.

2-4. 20개 프롬프트로 이미지 동시 생성

ImageGen 스킬에 프롬프트 20개를 한꺼번에 넣어, 이미지를 다중 생성했습니다. 한 장씩 돌리던 작업을 배치로 묶는 것만으로도 체감 생산성이 확 달라집니다.

이 네 가지의 공통점은 분명합니다. Codex를 "코드 생성기"가 아니라 "작업이 머무는 공간"으로 쓰면, 다룰 수 있는 일의 범위가 넓어진다는 것입니다. 이 관점이 바로 다음에 소개할 백서의 출발점입니다.

 

 

3. OpenAI 공식 가이드: "Codex-maxxing for long-running work"

최근 오픈AI에서 장기 작업을 위한 Codex 활용 가이드를 공개했습니다. "코덱스-맥싱"이라고도 불리는 문서의 제목은 "Codex-maxxing for long-running work", 부제는 "How Codex helps work continue beyond a single prompt"입니다. 즉, 하나의 프롬프트를 넘어 작업이 계속 굴러가게 만드는 법에 관한 문서입니다.

특별한 테크닉이나 대단한 신기술을 써놓은 글은 아닙니다. 오히려 기본 원칙을 정리한 문서에 가깝습니다. 눈에 띄는 점은, 처음부터 완벽한 지시문을 만들기보다 작업 도중에 방향 수정·추가 지시·승인·다음 작업 지정 같은 개입을 계속 흘려보내는 방식을 권장한다는 것입니다. 백서는 이를 "단일 프롬프트를 작업을 굴리는 운영 루프(operating loop)로 바꾸는 일"이라고 표현합니다. 사례의 주인공은 발표 자료, 트랜스크립트, 스프레드시트, 브라우저 작업, 반복 업무까지 Codex를 일상 워크플로우에 녹여 쓰는 제이슨 리우(Jason Liu)입니다.

문서는 열 개의 섹션으로 구성돼 있습니다. 핵심만 추려 정리하면 다음과 같습니다.

(1) Durable threads — 작업이 머무를 공간을 준다

중요한 작업 흐름에는 고정(pin)된 스레드 하나를 "작업의 집"으로 삼으라는 제안입니다. 맥락, 선호, 과거 결정, 아직 닫히지 않은 일들이 그 스레드에 시간을 두고 쌓입니다. 다만 트레이드오프가 있습니다. 오래된 스레드는 맥락을 많이 안고 가기 때문에, 새로 시작하는 짧은 스레드보다 실행 비용이 더 들 수 있습니다. 그럼에도 중요한 워크스트림이라면 연속성이 그 비용을 상쇄한다고 봅니다.

 

 

(2) Voice input — 정제되지 않은 생각을 그대로 넣는다

음성 입력의 가치는 속도만이 아닙니다. 말로 하면 "정리되기 전의 날것 그대로의 맥락"이 들어간다는 점이 핵심입니다. 반쯤만 기억나는 이름, 막연한 방향, 불확실함처럼 타이핑하기엔 어색하지만 말로는 자연스러운 것들 말입니다. 백서의 예시는 인상적입니다. "슬랙에 Ben이라는 사람이 이 얘기를 한 것 같은데, 정확히 뭔지는 기억 안 나니까 그냥 가서 찾아봐." 실제 업무는 보통 이렇게 시작되니까요. 통화·회의·복도 대화·러프한 음성 메모 같은 트랜스크립트도 그대로 출발 재료가 됩니다.

 

 

(3) Steering — 작업이 도는 동안 큐(queue)를 다듬는다

스티어링은 Codex가 이미 일하는 중에 다음 지시를 끼워 넣는 것입니다. 방향을 바로잡고, 맥락을 더하고, 다음 단계를 승인하고, 도구 호출 뒤에 이어질 작업을 미리 큐에 넣어둘 수 있습니다. 사이트를 리뷰하는 상황이라면 이런 식입니다. "이거 더 작게.", "이 카피는 틀렸어.", "다 되면 PR 열어줘.", "프리뷰 배포를 기다려.", "뭔가 올리기 전에 프리뷰 링크부터 보여줘." 처음부터 완벽한 한 방을 노리지 말라는 메시지가 여기서 가장 뚜렷합니다.

 

 

(4) Memory — 검토할 수 있는 메모리를 만든다

스레드가 길어지면 대화 밖의 메모리가 필요해집니다. 백서는 메모리를 "열고, 편집하고, diff로 비교하고, 재사용할 수 있는 것"으로 만들라고 강조합니다. 여기서 중요한 구분이 나옵니다. "저장소(repository)는 코드를 담고, 볼트(vault)는 작업 주변의 굴러가는 맥락을 담는다." 사람·결정·열린 루프·일일 메모·프로젝트 상태가 볼트에 들어갑니다. 볼트를 깃허브에 두면 diff 자체가 메모리 리뷰 화면이 됩니다. 사람이 언급될 때 사람 노트를 갱신하고, 프로젝트가 진전되면 프로젝트 페이지를 갱신하고, 루프가 닫히면 닫혔다고 표시하고, 결정이 내려지면 그 결정과 이유를 적어 두는 식입니다.

 

 

(5) Computer and browser use — 스레드가 무엇을 만질 수 있는지 정한다

메모리가 생기면 다음 질문은 현실적인 것이 됩니다. "이 스레드가 무엇을 쓸 수 있는가?" 백서는 표면(surface)을 구분하라고 합니다. 로컬 앱을 다듬는 중이면 브라우저 surface, 로그인 상태나 여러 인증 탭이 필요하면 Chrome, 데스크톱 앱을 통해서만 가능한 일이면 권한과 검토를 명확히 한 채로 컴퓨터 사용(computer use)을 씁니다. 여기에 슬랙·지메일·캘린더·깃허브 같은 커넥터, 그리고 반복 워크플로우를 묶은 스킬(skills)이 더해집니다.

 

 

(6) Remote control — 긴 루프를 들고 다닐 수 있게 한다

원격 제어는 파일·권한·로컬 설정이 이미 갖춰진 그 머신에서 Codex가 계속 일하게 두고, 다른 기기로 들여다보는 방식입니다. 책상에서 작업을 시작하고, 자리를 비우고, 휴대폰으로 다음 결정 지점을 확인하고, 승인·방향 전환·다른 방식 요청을 던집니다. 다만 백서는 못을 박습니다. "원격 제어는 리뷰를 건너뛰는 핑계가 아니다." 다음 수를 막힘없이 풀어주기 위해 루프에 충분한 주의를 유지하는 수단일 뿐입니다.

 

 

(7) Thread automations — Codex가 다시 돌아오도록 예약한다

스레드 자동화는 현재 스레드에 붙는 "심장박동(heartbeat) 같은 주기적 깨우기"입니다. 맥락을 잃지 않은 채, 같은 대화로 일정 주기마다 돌아오게 만듭니다. "지금 이걸 해(Do this now)"라는 일반 프롬프트와 달리, "이걸 계속 지켜보다가 뭔가 바뀌면 진전시켜(Keep checking this and move it forward when something changes)"에 가깝습니다. 예시 자동화는 이렇습니다. "30분마다 슬랙과 지메일에서 답이 필요한 메시지를 확인하고, 맥락을 조사해 답장 초안을 만들되, 승인 없이는 아무것도 보내지 마라."

 

 

(8) Three examples of loops — 세 가지 루프 예시

진짜 힘은 개별 기능이 아니라 맥락·도구·메모리·반복·검토를 가로지르는 "루프"에서 나옵니다.

• Loop 1 [Chief of Staff]: 슬랙·지메일을 주기적으로 확인해 주의가 필요한 메시지를 찾고, 배경을 조사해 답장 초안을 준비합니다. 무엇을 보낼지는 사람이 결정합니다.
• Loop 2 [Monitor for feedback]: 슬랙 스레드에서 피드백을 지켜보다가 Remotion 프로젝트를 갱신하고, 다시 렌더링해 리뷰용 수정본을 준비합니다. 슬랙·렌더링 도구·GUI 작업을 가로지르는 루프입니다.
• Loop 3 [Get a refund]: 고객지원 상담원이 합류했는지 확인하고, 대화가 바뀌면 다음 응답을 준비합니다. 사용자가 자리를 비워도 진행되지만, 돌이킬 수 없는 행동은 사람의 동의·승인 영역으로 묶어 둡니다.

세 루프 모두 "Codex가 준비하는 것"과 "사람이 결정하는 것"을 명확히 나눕니다. 판단·승인·되돌릴 수 없는 행동은 끝까지 사람의 몫입니다.

 

 

(9) Goals — 검증 가능한 목표를 준다

약한 목표는 Codex에게 "계획을 구현해 줘"라고 말합니다. 강한 목표는 테스트할 기준을 줍니다. 기대 동작, 리뷰 기준, 제약 조건, 명확한 "완료의 정의(definition of done)" 같은 것들입니다. 백서의 예시가 명쾌합니다. 약한 목표는 "이 마크다운 파일의 계획을 구현해 줘", 강한 목표는 "이 라이브러리를 포팅하되 공개 API 호환성을 유지하고, 원본 단위 테스트를 성공 기준으로 삼아라. 동일한 테스트가 통과하고 차이가 문서화됐을 때 리뷰 준비가 된 것이다." 실제로 Rich 라이브러리를 Rust로 포팅한 사례에서, 목표는 "포팅"이 아니라 "원본 단위 테스트를 통과하는 방식의 포팅"이었습니다. 그 테스트 스위트가 작업에 진짜 기준선을 줬습니다.

 

 

(10) Side panel — 산출물을 루프의 일부로 만든다

사이드 패널을 단순한 "미리보기 화면"으로만 보면 절반만 이해한 것입니다. 백서는 여기서 Codex가 채팅 인터페이스 이상이 된다고 말합니다. Codex가 다루는 바로 그 객체를 같이 들여다보고, 코멘트를 남기고, 변경을 리뷰하고, 산출물을 스레드 안에 그대로 둘 수 있습니다. 마크다운·스프레드시트·CSV·PDF·슬라이드가 모두 여기서 살 수 있고, 인앱 브라우저로 index.html·Storybook·Streamlit·Jupyter 같은 작은 웹 산출물도 살아 있는 surface가 됩니다. 코멘트가 곧 지시가 되고, 산출물이 곧 맥락이 됩니다.

정리하면, 백서가 일관되게 던지는 메시지는 하나입니다. Codex를 "한 번의 응답"이 아니라 "맥락·메모리·반복·검토가 도는 루프"로 운영하라. 그리고 그 루프 안에서 판단과 승인은 끝까지 사람이 쥐고 있어야 합니다.

 

 

4. 실무 적용: 진단 업무를 "하네스"로 만들기

필자는 이 원칙들을 실제 업무에 다양한 하네스(harness) 형태로 적용하고 있습니다. 특히 기존에 반복하던 취약점 진단 업무를 재사용 가능한 하네스로 정리해 동료들과 많이 공유했습니다. 백서의 개념과 1:1로 맞춰 보면 왜 이게 효과적인지가 분명해집니다.

Claude에서 막혀버린 프롬프트

 

먼저 진단 절차 자체를 스킬(skill)로 묶었습니다. 점검 항목, 참고 기준서, 실행 스크립트, 결과 정리 양식을 하나의 워크플로우로 패키징하면, 매번 Codex에게 절차를 다시 가르칠 필요가 없습니다. 백서의 "한 번 성공한 워크플로우는 스킬로 패키징하라"는 권고를 그대로 따른 셈입니다. 이 접근은 앞서 소개했던 글에서 다룬 "AI에게 개발 프로세스를 가르친다"는 발상과도 결이 같습니다.

 

 

다음으로 검증 가능한 목표(strong goal)를 설정했습니다. "이 시스템을 점검해 줘"가 아니라, "이 점검 항목 목록을 기준으로, 각 항목의 판정 근거와 증적을 남기고, 누락·오탐 가능성을 별도로 표시하라. 모든 항목에 근거가 붙고 기준서와 매핑됐을 때 리뷰 준비가 된 것이다"처럼 완료 조건을 박아 둡니다. 백서의 Rich-to-Rust 사례가 "원본 테스트 통과"를 기준선으로 삼았듯, 진단에서는 점검 기준서가 그 테스트 스위트 역할을 합니다.

 

 

볼트(vault)와 메모리 개념도 유용합니다. 대상 시스템별 특이사항, 지난 점검에서 내린 판단, 아직 닫지 않은 확인 항목을 diff로 검토 가능한 메모리에 쌓아 두면, 다음 점검이 처음부터 다시 시작되지 않습니다. "코드는 저장소에, 굴러가는 맥락은 볼트에"라는 구분이 보안 진단에서도 그대로 들어맞습니다.

 

 

마지막으로, 가장 중요한 원칙은 사람의 검토를 루프에서 빼지 않는 것입니다. 자동화는 근거 수집·격리 검증·영향 범위 점검 같은 반복을 빠르게 처리해 주지만, 정책 위반 가능성·예외 처리 누락·운영 영향도 같은 최종 판단은 사람이 가져갑니다. 이는 필자가 최근 작성해오고 있는 글에서 반복해 강조했던 "AI가 작성하고, 사람이 검증하며, 테스트가 증명하는 구조"와 정확히 같은 결론입니다. 백서가 "원격 제어는 리뷰를 건너뛰는 핑계가 아니다"라고 못 박은 것과도 통합니다.

 

 

마치며

Codex를 잘 쓰는 비결은 화려한 프롬프트 한 줄이 아니라, 루프를 어떻게 설계하느냐에 있습니다. 작업이 머무를 스레드를 만들고, 날것의 맥락을 음성·트랜스크립트로 넣고, 작업 도중에 방향을 잡아 주고, 검토 가능한 메모리를 쌓고, 무엇을 만질 수 있는지 권한을 정하고, 검증 가능한 목표를 주는 것. 그리고 그 모든 단계에서 승인과 판단은 사람이 쥐고 있는 것. 오픈AI의 백서가 정리한 원칙도, 필자가 보안 실무에서 체감한 결론도 결국 여기로 모입니다.

도구는 충분히 좋아졌습니다. 이제 남은 건 그 도구를 "한 번의 응답"이 아니라 "계속 굴러가는 작업 공간"으로 다루는 습관입니다. 다양한 활용 속에서 생산성은 분명히 올라갑니다.

 

References

• OpenAI White Paper, "Codex-maxxing for long-running work: How Codex helps work continue beyond a single prompt" https://cdn.openai.com/pdf/8a9f00cf-d379-4e20-b06f-dd7ba5196a11/OAI_WhitePaper_Codex-maxxing26.pdf
• OpenAI Codex 공식 문서: https://platform.openai.com/docs/codex
• bkit (PDCA 기반 Codex 플러그인)

Web – Codex | OpenAI Developers