Codex가 최고라는 소문 직접 검증합니다, 세팅부터 실전 앱 개발까지 전 과정 공개 (feat. OpenAI)

한 줄 요약

빌더 조쉬가 약 2시간 30분짜리 라이브에서 OpenAI의 코딩 도구 Codex를 설치부터 플러그인·스킬, 문서 네 장으로 짜는 하네스 세팅, 'goal' 기능까지 직접 써 보며 휴가 관리 ERP와 회의록 전사 앱을 Vercel에 배포했어요. 소문대로 쓸 만한지, 어디서 막히는지까지 그대로 보여 주는 실습 기록입니다.

전체 내용 정리

설치는 한 줄이면 끝나고 처음엔 모델·추론 수준·권한부터 맞춥니다

조쉬는 요즘 주변에서 Codex 얘기를 정말 많이 듣는다고 해요. 토큰 면에서 강점이 크고 최근 Codex CLI에 'goal'이라는 기능이 나왔는데 다른 회사가 이를 참고해 비슷한 걸 내놓을 정도로 화제가 됐다는 거죠. 이날 라이브는 기본 세팅 → 스킬과 자동화 → 하네스를 갖춘 바이브 코딩 순서로 진행됐습니다.

조쉬는 Codex를 OpenAI가 만든 코딩 도구라고 소개해요. Codex에는 데스크톱 앱과 CLI(터미널에서 돌아가는 명령줄 도구)가 따로 있어요. 맥에서는 터미널 앱을 열면 되는데, 개발자에게는 익숙한 그 검은 화면에서 Codex를 불러 쓰는 구조예요. CLI는 검색창에 'Codex CLI'를 찾아 들어가면 설치 방법이 나오는데, npm과 Homebrew 두 가지가 있습니다. 조쉬는 npm을 추천하는데요, 업데이트가 아주 매끄럽지는 않다고 알고 있지만 명령어 한 줄을 복사해 붙여 넣으면 끝날 만큼 쉽고 윈도우에서도 잘 통하기 때문이에요. 설치 뒤 터미널에 codex를 입력하면 바로 실행되고 '안녕'이라고 치면 무엇을 도와줄지 되묻습니다.

비개발자에게는 이 검은 화면부터가 막막하죠. 그래서 조쉬는 슬래시(/)를 눌러 메뉴를 먼저 둘러보라고 권해요. 모델 변경, 패스트 모드, 권한(permission) 모드처럼 기본 지원 항목이 생각보다 많거든요. 다만 goal 기능은 기본 메뉴에 없고 따로 켜야 한다고 미리 짚어 둡니다.

조쉬가 쓰는 설정은 GPT 5.5 + 추론 수준 하이(high) + 패스트 모드예요. 추론 수준은 하이를 써도 토큰이 크게 더 나간다고 느끼지 않았고 결과가 괜찮았다고 해요. 패스트 모드는 토큰을 1.5배 더 쓰는 대신 결과를 더 빨리 받는 옵션입니다.

권한 메뉴에는 '오토 리뷰(auto review)'와 '풀 액세스(full access)'가 있어요. Codex가 권하는 쪽은 오토 리뷰이고 풀 액세스는 매번 승인을 묻지 않고 한 번에 밀고 나가는 스킵 모드에 해당합니다. 조쉬는 이날 풀 액세스로 진행했지만 오토 리뷰도 나쁘지 않아 보였다고 해요. 재밌는 건 Codex가 승인을 요청할 때 '띵' 하는 효과음을 낸다는 점이에요. 다른 도구에서는 잘 못 겪어 본 방식이라 알림 신호로 쓸 만했다고 합니다.

플러그인은 MCP와 스킬을 한 번에 묶은 패키지예요

CLI에서도 플러그인 목록을 볼 수 있지만 한눈에 들어오지 않아요. 그래서 조쉬는 Codex 앱 화면으로 설명합니다. 앱에서는 플러그인을 둘러보며 직관적으로 설치할 수 있거든요. Gmail을 연결하면 받은편지함 요약이 되고 Figma를 연결하면 Codex로 Figma 안에서 디자인을 하는 식이에요. Slack, Notion처럼 기존에 연동하던 서비스도 다 들어와 있어서 활용 범위가 꽤 넓습니다.

플러그인이 어렵게 느껴진다면 이렇게 정리하면 돼요. MCP(앱과 소통하게 해 주는 도구)와 스킬(그 MCP를 잘 쓰도록 미리 짜 둔 프롬프트 모음)이 같이 들어 있는 패키지라는 거죠. 예컨대 Computer Use 플러그인에는 같은 이름의 MCP 서버와 스킬이 함께 포함돼 있어요. MCP 명령어를 따로 쓰지 않아도 플러그인 하나만 깔면 스킬까지 자동으로 내려받아지니 세팅이 훨씬 편하다는 게 조쉬의 설명입니다.

디자이너 출신인 조쉬는 Figma 플러그인을 특히 자주 써요. 디자인 스킬 외에도 디자인 시스템(자주 쓰는 버튼·폰트 등을 정리한 문서)을 만드는 스킬, 변수(variable) 같은 세부 요소를 다듬는 스킬이 들어 있다고 해요. 조쉬는 Codex로 디자인이나 문서를 만드는 쪽이 토큰 효율 면에서 낫다고 봅니다. 그래서 바이브 코딩이 아니어도 일상 업무에 Figma 플러그인을 써 보라고 권해요. Figma로 문서를 쓰는 사람들에게도 Codex가 꽤 괜찮은 수단이 될 거라는 게 조쉬의 개인적인 생각이에요. Codex 앱에는 자동화(automation) 기능도 있습니다. 매일 아침 9시마다 뉴스 브리핑을 만들게 하거나, 같은 시간에 Figma 디자인 작업을 돌리게 하는 식이에요.

조쉬가 바이브 코딩에 늘 쓰는 커스텀 플러그인도 하나 소개해요. 깃허브에서 '비킷 코덱스'로 검색하면 나오는 비킷이에요. 홍보가 아니라 매일 쓰는 도구라고 선을 긋는데, 쓰는 이유는 문서화입니다. Codex 자체 플랜 모드도 강력하지만 PRD(제품 요구사항 문서)나 구현(implementation) 문서처럼 사전 계획 문서를 상세하게 쓸수록 결과가 좋다고 판단했거든요. 설치는 깃허브 주소를 복사해 Codex에 붙여 넣고 플러그인을 설치해 달라고 하면 끝나요.

스킬로 이미지·Figma 시안·PPT를 동시에 뽑아 봤어요

조쉬가 이해하는 스킬은 skill.md 파일 하나에 담긴, 다시 쓸 수 있는 워크플로우 모음이에요. 흔히 단순한 프롬프트 모음으로 여기지만 장점이 더 있다고 해요. 서브에이전트 파일 같은 하네스용 MD 파일은 AI가 매번 새로 해석하느라 토큰을 많이 쓰는데, 스킬은 규격이 정해져 있어 AI가 그 내용만 따라가면 되거든요. 그래서 반복 작업에 재사용하기 좋고 토큰도 덜 먹는다는 게 조쉬의 설명입니다.

실습은 Cursor에서 Codex CLI를 열어 진행했어요. VS Code나 Antigravity도 쓰지만 디자인 편집이 편해서 Cursor를 고른 것뿐이라고 해요. Codex에서 스킬을 부르는 명령어는 달러($)예요. $를 입력해 imagegen 스킬을 고르고 "20대 여성 한국인 이미지 생성"이라고만 쳤는데, 이미지 2.0 모델이 품질 좋은 사진을 바로 만들어 냈습니다. 조쉬는 요즘 성능이 가장 압도적이라는 이 이미지 모델을 Codex 안에서 기본으로 쓸 수 있다는 점을 큰 강점으로 꼽아요. 기본 제공 스킬에는 PDF, 문서, 프레젠테이션 등도 있는데, 이런 스킬을 저렴하게 많이 쓸 수 있다는 점도 장점으로 봅니다.

이어서 Figma 사용 스킬로 디자인 샘플 랜딩 페이지를 요청했어요. 이 스킬은 Figma 플러그인을 깔면 쓸 수 있는데, 새 Figma 파일을 생성해 디자인·랜딩 페이지·문서까지 만들어 줍니다. 그리고 그 사이 터미널 창을 하나 더 열어 프레젠테이션 스킬도 돌렸어요. 창을 여러 개 띄우면 작업을 동시에 시킬 수 있거든요. 요청은 "빌더 조쉬에 대해 열 장 정도 조사한 PPT를 하나 만들어 줘"에 Pretendard 폰트와 모노톤을 지정한 정도였습니다. 결과물을 본 조쉬는 다른 서비스와 달리 도형을 꽤 잘 설계해 준다는 점이 특이하다고 평가해요. 이미지 스킬로 만든 그림을 PPT에 바로 넣어 쓸 수 있다는 점도 중요하다고 짚습니다.

그냥 만든 랜딩 페이지는 밋밋했어요. 여기서 조쉬가 꺼낸 게 design.md입니다. getdesign.md 사이트에 가면 전 세계 여러 기업의 디자인 시스템을 design.md 파일로 받을 수 있어요. 조쉬는 Framer의 design.md를 복사해 프로젝트에 붙여 넣고 이 파일을 참조해 랜딩 페이지를 다시 만들라고 시켰어요. 비교해 보니 그림은 여전히 잘 못 그리지만 폰트와 전체적인 도형 감각은 확실히 나아졌다고 해요. 같은 방식으로 카드 뉴스나 프레젠테이션도 만들 수 있다고 덧붙입니다.

바로 코딩하지 않고 문서 네 장부터 만들어요

2부는 바이브 코딩이에요. 후보는 유튜브 요약 앱, 실시간 미팅 기록 앱, 라이브 번역 앱, 회사 ERP였고 먼저 ERP의 휴가 시스템부터 만들었습니다. 조쉬는 Cursor를 유료로 쓰지도 않고 무료 플랜이라며 어떤 편집기를 써도 상관없다고 강조해요.

새 폴더에서 Codex를 연 뒤 $로 비킷의 PDCA를 부르고 "우리 회사 ERP를 만들고 싶어"라며 휴가 시스템부터 구현하자고 요청했어요. PDCA는 계획(Plan)과 설계(Design)를 거쳐 실행(Do), 점검(Check), 개선(Act)으로 이어지는 방법론이에요. 바이브 코딩은 '휴가 시스템 만들어 줘'로 시작하는 게 아니라, 문서와 하네스를 초반에 깎고 또 깎은 뒤 마지막에 한 번에 실행하는 것이라는 게 조쉬의 지론입니다.

플랜 단계가 끝나자 docs 폴더에 휴가 시스템 PRD가 생겼어요. 이어서 디자인 단계를 돌리는데, 여기서 '디자인'은 화면 디자인이 아니라 설계 문서를 뜻해요. 조쉬는 플랜을 상위 기획서, 디자인 문서를 상세 기획서로 구분합니다. 실제로 플랜 문서는 143줄, 디자인 문서는 360줄 정도였어요. 상위 기획서를 바탕으로 상세 기획서를 한 번 더 쓰면 훨씬 밀도 있는 결과가 나온다고 해요. 디자인 문서에는 기술 스택, 데이터 모델, 데이터베이스 구조도까지 들어가 있었습니다. 다만 처음부터 너무 개발적인 지시를 먼저 넣지는 않는 편이 좋다고 봐요.

조쉬가 이날 만든 문서는 모두 네 장이에요.

① 플랜 문서(상위 기획서) ② 설계 문서(상세 기획서) ③ 스타일을 정하는 design.md ④ AI 작업 원칙을 담은 agents.md

design.md는 이번엔 국내 사이트에서 가져왔어요. 배달의민족, 토스, 당근 같은 한국 회사의 디자인 시스템을 모아 둔 곳인데, 조쉬는 당근 스타일을 복사해 붙여 넣었습니다. agents.md는 AI가 반복하는 실수를 막고 지켜야 할 원칙이나 쓸 서브에이전트·스킬을 명시해 두는 시스템 가이드 문서예요. OpenCode, Gemini, Codex 등 여러 도구가 공통으로 쓰는 규약이라 이걸 만드느냐 마느냐에 따라 품질 차이가 크다고 해요. 빈 파일을 만든 뒤 Codex에게 현재 프로젝트를 읽고 맥락을 채워 달라고 하면 됩니다.

처음엔 영어로 채워져서 조쉬는 "영어로 쓰지 마. 한글로 써 줘."라고 다시 시켰어요. 앞으로 직접 관리해야 하니까요. 영어로 쓰면 토큰이 1.7배 정도 덜 든다는 얘기도 들었지만 조쉬는 그게 크게 신경 쓸 부분인지 모르겠다는 입장입니다.

휴가 ERP를 만들고 배포는 CLI 세 개에 맡겼어요

문서가 갖춰진 뒤에야 PDCA의 실행(Do) 단계로 개발을 시작했어요. 화면에는 대시보드, 휴가, 직원 메뉴가 나왔고 연차·오후 반차를 골라 휴가를 신청하자 내역에 등록되면서 승인 대기 상태로 바뀌었습니다. 모바일 화면도 바로 대응돼 있었어요. 조쉬는 이렇게 문서를 갖춰 두고 원하는 대로 바로 만들어 쓸 수 있으니, 굳이 다른 회사의 ERP를 구독할 필요가 클까 싶다고 말해요.

다음은 배포예요. npm run dev로 띄운 로컬 호스트 화면은 내 컴퓨터에서만 보이는 거예요. 조쉬는 "절대 로컬 호스트 주소를 다른 분들에게 그냥 이대로 공유하시면 바보 소리 듣습니다"라고 웃으며 경고해요. 실제 서비스로 쓰려면 세 가지가 필요하다고 정리합니다.

• Supabase: 데이터베이스를 저장하고 관리하는 곳
• Vercel: URL을 붙여 배포하는 곳
• GitHub: 구글 드라이브처럼 버전을 관리하는 곳

간단한 서비스라면 이 세 가지면 거의 다 된다고 해요. 조쉬는 명령어를 직접 치지 않고 Codex에게 Supabase CLI, Vercel CLI, GitHub CLI로 "배포랑 데이터베이스 세팅 등 마무리해 줘"라고 한꺼번에 던집니다. 이 과정에서 CLI 토큰 만료, 샌드박스 DNS 제한, Docker 차단 같은 문제가 줄줄이 떴어요. 조쉬는 해결 방법을 AI가 다 알려 주니 하나씩 처리하면 된다고 말합니다. 라이브 막바지에 인증 코드를 입력해 마무리하자 ERP도 Vercel URL로 배포가 끝났어요.

조쉬는 여기까지를 한 번 정리해요. 플랜 문서, design.md, agents.md를 만들고 백엔드 기본 세팅까지 했지만 외부 서비스를 붙이는 API 연동은 아직 안 했다는 거죠. 휴가 ERP에는 외부 API가 필요 없었기 때문이에요. 그래서 다음 앱에서는 API 연동과 URL 배포까지 한 번에 해 보기로 합니다.

goal 기능은 목표를 주면 검증까지 끝내고 보고해요

두 번째 앱은 실시간 회의록 앱이에요. 새 폴더에서 다시 PDCA를 부르고 "실시간으로 미팅 회의록을 기록할 수 있는 서비스를 만들어 보자"라고 시작했어요. 그런데 모델이 미디엄·패스트로 잡혀 있던 탓인지 계획 문서도 없이 HTML부터 만들어 버렸고 화면이 깨졌습니다. 조쉬는 작업을 취소하고 GPT 5.5 하이로 바꿔 다시 진행해요. 이때 다른 창에서 모델을 바꾸면 GPT 5.5는 유지되는데 하이 같은 추론 수준 설정은 잘 연동되지 않는 경우가 있었다며 Codex 쪽에서 고쳐 주면 좋겠다고 짚어요. 문서는 다소 빈약했지만 다시 만들기엔 시간이 아까워서 그대로 진행했고 design.md는 getdesign.md에서 ElevenLabs 스타일을, agents.md는 프로젝트 맥락 정리로 채웠습니다.

이제 goal 차례예요. 조쉬는 이 기능을 "목표만 설정하면 끝까지 간다"고 요약해요. 원하는 기능을 던지면 끝까지 구현하고 검증까지 마친 뒤 결과를 보고하는 방식이에요. 기본으로는 꺼져 있어서 Codex 설정 파일인 config.toml의 features 항목에 goals = true를 넣어야 하는데요, 이것도 Codex에게 config.toml을 수정해 goal 기능을 켜 달라고 하면 알아서 넣어 줍니다.

회의록 앱은 음성을 받아 적어야 하니 OpenAI API가 필요해요. platform.openai.com에서 API 키를 발급받으면 되는데, 크레딧을 어느 정도 충전해 둬야 합니다. 키는 프로젝트에 .env 파일을 만들어 붙여 넣으면 Codex가 알아서 읽어요. 그다음 goal로 "모든 기능 구현을 시작하고 버셀의 배포까지 하면 나에게 보고해 줘"라고 목표를 통째로 맡겼습니다.

결과는 순탄하지 않았어요. 배포된 앱에서 기록 추가는 됐지만 정작 음성 기록 기능이 빠져 있었거든요. 조쉬는 음성 API로 회의를 기록하는 앱이라는 점을 다시 알려 주고 UI와 기능을 보강해 검증하라고 goal을 한 번 더 걸었어요. goal은 '목표 처리 시간'을 따로 기록해 보여 주는데, 이번엔 482초가 걸렸습니다. 그런데 배포가 제대로 안 돼 있었고 녹음 후 전사를 누르자 'Failed to fetch' 오류가 났어요. 조쉬는 이를 '시연의 저주'라 부르며 재배포와 녹음 기능 테스트를 다시 맡겼습니다. 결국 녹음한 인사말이 제대로 전사되면서 앱이 완성됐어요. 조쉬는 회사에서 쓸 회의록 전사 앱도 이런 식으로 직접 만들 수 있고 여기에 쌓인 데이터를 따로 에이전트로 바꿔 쓸 수도 있다고 덧붙입니다.

조쉬는 실패 원인도 솔직하게 짚어요. 기획서에 음성 전사 API가 제대로 들어갔는지 확인하지 않고 라이브로 바로 넘어간 게 문제였다는 거죠. goal이 끝까지 밀어붙여 주더라도, 기획서에 핵심 기능이 들어갔는지는 사람이 먼저 확인해야 한다는 교훈이 남습니다.

마무리하며 조쉬는 앞으로 Codex를 더 많이 쓸 것 같다고 말해요. 이미지 생성 기능이 너무 좋고 토큰 면에서 우월해 하루 종일 써도 문제가 없을 것 같으며 goal 기능과 기본 내장 스킬도 마음에 들었다는 이유예요. 특히 내장 스킬 중에서는 imagegen이 가장 좋았다고 꼽습니다. 회사 Slack에 연결한 에이전트를 만들 때도 OpenAI 요금제가 워낙 유리해 활용 폭이 넓어질 거라고 봐요. 여러 AI 엔진이 경쟁할수록 사용자에게 돌아오는 혜택이 커진다는 점도 반긴다고 합니다.

핵심 인사이트

• 설정 세 가지가 체감 성능을 가릅니다: 조쉬는 GPT 5.5 + 추론 하이 + 패스트 모드를 씁니다. 미디엄·패스트 상태에서는 계획 없이 HTML부터 만들어 화면이 깨졌어요. 모델과 추론 수준을 먼저 확인하는 습관이 시행착오를 줄여 줘요.
• 플러그인 하나가 MCP와 스킬을 한꺼번에 해결해요: MCP 명령어를 따로 다룰 필요 없이 플러그인을 깔면 스킬까지 따라옵니다. 비개발자가 Gmail·Figma·Slack 연동을 시작하기에 가장 쉬운 입구예요.
• 문서 네 장이 바이브 코딩의 하네스예요: 플랜(143줄) → 설계(360줄) → design.md → agents.md 순으로 깎은 뒤에야 개발을 시작합니다. 조쉬는 만들고 안 만들고의 차이가 너무 크다며 꼭 해 보라고 권해요.
• goal은 '끝까지 가는' 기능이지 기획을 대신하진 않아요: 목표를 주면 구현·배포·검증까지 스스로 돌지만 기획서에서 음성 전사가 빠지자 결과물에서도 빠졌습니다. 자동화 강도가 높을수록 입력 문서 점검이 더 중요해져요.

오늘 당장 해볼 것

1. npm으로 Codex CLI를 설치하고 / 메뉴부터 둘러보세요. 모델을 GPT 5.5, 추론 수준을 하이로 맞춰 두면 조쉬가 쓰는 설정 그대로 출발할 수 있어요.
2. getdesign.md에서 마음에 드는 회사의 design.md를 하나 받아 보세요. 프로젝트 폴더에 붙여 넣고 이 파일을 참조해 랜딩 페이지를 만들어 달라고 시키면, design.md 없이 만든 결과와 얼마나 다른지 바로 비교할 수 있어요.
3. 다음 프로젝트에서는 agents.md부터 만들어 보세요. 빈 파일을 만든 뒤 Codex에게 현재 프로젝트 맥락을 한글로 채워 달라고 하면 됩니다. 직접 관리할 문서라서 한글로 두는 편이 나중에 고치기 편해요.
4. 반복 업무가 있다면 config.toml에서 goal을 켜고 목표를 통째로 맡겨 보세요. 단, 맡기기 전에 기획서에 핵심 기능이 들어 있는지 먼저 확인하세요. 조쉬의 회의록 앱처럼 빠진 기능은 끝까지 빠진 채로 돌아오거든요.