🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Codex가 최고라는 소문은 “설치·설정 → 문서 기반 설계 → 실전 앱 개발 → 배포·검증”까지 직접 돌려 봤을 때, 강점은 분명하지만 초기 세팅과 배포·API 검증까지 사람이 감독해야 완성도가 올라간다는 쪽에 가깝다.

📌 핵심 요점

1. Codex는 단순 코드 생성 도구가 아니라 CLI, 모델 설정, 권한 모드, 플러그인, 스킬, goal 기능을 조합해 앱 개발과 디자인·문서 작업까지 이어 가는 작업 환경으로 소개된다.
2. 비개발자에게는 터미널 기반 실행, npm 설치, 슬래시 메뉴 설정, 권한 승인 흐름이 진입 장벽이 될 수 있으며, 초기 세팅 품질이 전체 사용 경험을 크게 좌우한다.
3. ERP 휴가 시스템 개발에서는 PRD, 설계 문서, design.md, AGENTS.md 같은 문서 하네스를 먼저 만든 뒤 구현에 들어가는 방식이 더 안정적인 바이브 코딩 원칙으로 제시된다.
4. 피그마, 이미지 생성, 프레젠테이션, 비킷 플러그인과 스킬을 함께 쓰면 개발자뿐 아니라 디자이너·기획자도 랜딩 페이지, 문서, 카드뉴스, PPT 같은 산출물을 만들 수 있는 확장성이 확인된다.
5. 실시간 회의록 앱과 ERP 배포 과정에서는 Vercel, Supabase, GitHub, OpenAI API, 인증 토큰, DNS·Docker 제한, API 경로 오류 같은 현실적 장애가 발생했고, 최종적으로는 기능 검증과 재배포를 반복해야 했다.

🧩 배경과 문제 정의

• 코덱스는 토큰 효율, CLI 기능, 최근 추가된 기능 흐름을 바탕으로 바이브 코딩 도구로 주목받고 있다.
• 비개발자에게 터미널 기반 코딩 도구는 첫 화면부터 낯설 수 있으며, 설치·권한·모델·플러그인 등 초기 설정이 사용 경험을 크게 좌우한다.
• 따라서 단순 코드 생성이 아니라 ERP, 회의록 서비스, 배포, 데이터베이스 세팅까지 이어지는 실전 앱 개발 흐름을 검증하는 것이 핵심이다.
• 여기에 이미지 생성, 피그마 연동, 프레젠테이션 제작 같은 확장 기능까지 연결되면 개발자뿐 아니라 디자이너와 기획자에게도 활용 범위가 넓어진다.

🕒 시간순 섹션별 상세정리

1. 실전 앱 개발 검증으로 출발한 코덱스 사용 맥락

• 회사 ERP의 휴가 신청·승인 대기 화면 구현부터 배포와 데이터베이스 세팅까지 이어지며, 코덱스가 업무형 앱 개발 흐름에 투입된다 [01:18]
• 실시간 회의록 서비스 역시 구현과 배포를 목표로 삼고, 코덱스의 실전 자동화 역량을 검증 대상으로 설정한다 [01:33]

2. 설치·모델·스킬·자동화까지 이어지는 전체 실습 설계

• 실습은 코덱스 CLI 설치, 모드 설정, 설정이 필요한 이유, 모델 변경, 플러그인과 코덱스 앱 탐색 순서로 구성된다 [01:44]
• 이미지 2.0 모델이 코덱스 안에서 기본 지원되며, 이미지 생성 성능과 디자인 작업 확장성이 주요 장점으로 묶인다 [02:12]

3. CLI 설치와 터미널 실행의 진입 장벽

• 코덱스 CLI는 터미널에서 실행하는 코딩 도구로, 코덱스 앱과는 별도로 설치하고 실행해야 하는 구조다 [03:25]
• 맥에서는 터미널 앱을 열어 검은 화면에서 코덱스를 호출하는데, 개발자에게는 익숙하지만 비개발자에게는 낯선 진입 환경이다 [03:41]

4. 슬래시 메뉴에서 모델·리저닝·패스트 모드 설정

• 슬래시 메뉴에는 모델 변경, 패스트 모드, 퍼미션 모드 등 기본 설정이 모여 있으며, 기본 지원 항목만으로도 선택지가 많다 [05:29]
• ‘콜’ 기능은 기본 디폴트 모드에 포함되지 않아 별도 설정이 필요하며, 추가 활성화가 필요한 개발자용 기능처럼 다뤄진다 [05:45]

5. 권한 모드와 플러그인·코덱스 앱 탐색

• 로우 모드는 바이브 코딩 중 반복 승인 요청을 줄이고, 작업을 한 번에 이어가도록 돕는 설정으로 묶인다 [07:25]
• 퍼미션에는 오토 리뷰와 풀 액세스가 있으며, 권장 선택은 오토 리뷰에 가깝지만 실습에서는 승인 절차를 줄이기 위해 풀 액세스가 선택된다 [07:54]

6. 코덱스와 피그마 플러그인으로 확장되는 디자인·문서 작업

• 피그마 플러그인 연동을 통해 코덱스 안에서도 디자인 작업과 문서 작성이 가능해진다 [10:02]
• 코덱스를 활용한 디자인·문서 제작은 토큰 절약 측면에서 유리하다고 판단되며, 일상 업무에도 피그마 플러그인 조합을 적용할 수 있다 [10:26]

7. 플러그인은 MCP와 스킬을 묶어 설치 부담을 줄이는 패키지다

• 플러그인은 MCP와 스킬을 함께 담은 패키지에 가깝고, MCP는 앱과 소통하는 도구, 스킬은 MCP 활용을 돕는 설정된 프롬프트 모음에 가깝다 [11:16]
• 컴퓨터 유즈 플러그인에는 MCP 서버와 관련 스킬이 함께 포함되어 있어, 개별 스킬을 따로 세팅하는 방식보다 플러그인 전체를 내려받는 방식이 편하다 [11:39]

8. 피그마 세부 기능과 자동화, 비킷 플러그인의 문서화 활용

• 피그마에는 베리어블 같은 세부 개념까지 다듬는 기능이 있으며, 코덱스 앱에서는 이런 요소도 작업 범위에 포함된다 [12:52]
• 코덱스 앱의 오토메이션은 매일 아침 9시 뉴스 브리핑이나 피그마 디자인 실행처럼 시간 기반 반복 작업을 맡길 수 있다 [13:04]

9. 스킬은 반복 워크플로우를 재사용하고 토큰 효율을 높인다

• 스킬은 skill.md 파일에 별도 워크플로우를 모아 둔, 재사용 가능한 워크플로우 모음집에 가깝다 [14:50]
• 스킬은 반복 작업을 계속 재사용하게 해 주며, 서브 에이전트나 별도 MD 세팅 파일을 매번 해석하는 방식보다 토큰 소모가 적다 [15:22]

10. 이미지·피그마·프레젠테이션 스킬을 멀티 창으로 호출하는 실전 흐름

• 코덱스 CLI에서 달러 명령어로 이미지젠 스킬을 불러와 이미지 생성을 요청하면, 이미지 2.0 모델이 호출되어 바로 품질 좋은 이미지가 생성된다 [17:23]
• 플러그인을 여러 개 설치하면 피그마, PDF, 독스, 프레젠테이션 같은 기본·확장 스킬을 탐색할 수 있고, 저렴한 비용으로 다양한 산출물을 만들 수 있다 [17:57]

11. 코덱스 스킬로 랜딩 페이지와 디자인 참조 문서 활용

• 코덱스는 작업 중 사용자 확인이 필요한 지점에서 알림음을 내고, 진행 허용 여부를 묻는 방식으로 동작한다 [20:03]
• 간단한 랜딩 페이지 요청만으로도 피그마 기반 디자인 파일을 만들 수 있지만, 결과 품질을 높이려면 별도의 참조 문서가 필요하다 [20:34]

12. 프레젠테이션 스킬과 피그마 결과물 비교

• 코덱스가 만든 프레젠테이션은 도형 구성이 비교적 안정적이며, 다른 서비스들이 약한 도형 요소를 다양한 방식으로 설계하는 강점이 드러난다 [22:56]
• 조사 결과를 곧바로 프레젠테이션으로 전환하는 흐름에 이미지 생성 스킬을 결합하면, 생성 이미지를 슬라이드에 바로 첨부해 활용할 수 있다 [23:22]

13. 일상 작업 사례에서 실제 바이브 코딩 세션으로 전환

• 앞부분은 본격적인 바이브 코딩보다 코덱스로 비개발자가 수행할 수 있는 일상 작업 사례에 가깝고, 이후 실제 앱 개발 세션으로 넘어간다 [24:47]
• 후보 앱으로 유튜브 요약 앱, 실시간 미팅 기록 앱, 라이브 번역 앱이 거론되지만, 시간상 하나 또는 두 개로 범위를 줄이기로 한다 [25:12]

14. 휴가 ERP 개발을 위한 PDCA 플랜 모드 시작

• 목표는 휴가 등록을 처리하는 ERP 서비스이며, 비키시 플러그인을 사용해 플랫 모드와 PDCA 방법론을 적용한다 [26:35]
• $ 명령으로 PDCA를 불러오고, 회사 ERP의 휴가 시스템을 먼저 구현하겠다는 요구를 입력한 뒤 플랜 시작을 요청한다 [26:52]

15. PRD·디자인 문서 중심의 안정적인 바이브 코딩 원칙

• 비키시의 PBC 설계서 흐름에서는 플랜 문서와 디자인 문서를 분리하며, 여기서 디자인 문서는 시각 디자인보다 개발 문서를 정확히 만들기 위한 하네스 세팅에 가깝다 [28:14]
• 단순 플랜 문서만으로 개발하는 것보다 실행 문서와 구현 단위를 더 촘촘히 쪼개면 성공률이 높아지고, 에러가 적은 산출물을 만들 가능성이 커진다 [28:32]

16. 플랜 이후 상세 설계 문서를 분리해 구조를 잡는 단계

• 플랜 다음 단계는 PDCA의 디자인 단계이며, 여기서 디자인은 화면 시안이 아니라 설계 문서와 상세 기획서를 만드는 과정이다 [30:29]
• 플랜 문서는 상위 기획서, 디자인 문서는 상세 기획서 역할을 하며, 서버나 구현에 들어가기 전에 설계 문서 파일을 먼저 추가해 구조를 잡는다 [30:52]

17. 네 가지 문서로 구현 전 하네스를 구성하는 방식

• 플랜 문서와 설계 문서 다음에는 스타일 기준을 담는 디자인.md를 만들고, 마지막으로 에이전트.md를 만든 뒤 개발을 시작한다 [32:30]
• 시연 기준 문서는 플랜 문서, 상세 기획서 성격의 구현·설계 문서, 스타일 디자인 문서, 에이전트.md까지 네 가지로 압축된다 [32:56]

18. 디자인.md로 외부 디자인 시스템을 스타일 기준에 반영

• getdesign.md 같은 사이트에서 원하는 스타일을 둘러볼 수 있고, 한국 사용자는 오마이디자인 KI 같은 사이트에서 국내 서비스 디자인 시스템을 참고할 수 있다 [33:41]
• 배달의민족, 토스, 당근 등 여러 회사의 디자인 시스템을 브라우즈 화면에서 확인하며, 문서화된 디자인 기준을 가져올 수 있다 [34:16]

19. 에이전트.md로 프로젝트 규칙과 AI 작업 맥락을 고정

• 에이전트.md는 제작 과정에서 항상 지켜야 할 원칙, 반복 실수 방지, 서브 에이전트나 스킬 사용 기준을 명시하는 시스템 가이드라인 문서다 [35:38]
• 유지보수 과정에서 에이전트.md가 있으면 AI가 프로젝트 맥락과 규칙을 더 일관되게 따라가며 작업 품질 차이가 커진다 [36:06]

20. 한글 지침 정리와 PDCA Do 단계로 개발 시작

• 에이전트.md가 영어로 생성되면 이후 직접 관리하기 어렵기 때문에 한글 기준으로 다시 작성해 프로젝트 맥락, 제품 범위, 운영 규칙을 읽기 쉽게 유지한다 [37:40]
• 영어 문서가 토큰을 덜 쓴다는 주장과 약 1.7배 차이가 있다는 이야기가 있지만, 관리성과 이해도를 우선하면 한글 지침도 충분히 실용적이다 [37:57]

21. 휴가 관리 ERP 화면 검증과 로컬 앱 완성 확인

• 퍼미션이 모두 허용된 상태에서 비킷 도구가 완성 단계까지 계속 작업하며, 대시보드·휴가·직원·휴가 신청 화면이 실제로 나타난다 [40:00]
• 김민지 사용자로 연차와 오후 반차를 입력하고 사유까지 작성하자, 신청 내역에 승인 대기 상태로 등록되며 기본 업무 흐름이 작동한다 [40:29]

22. 로컬 실행과 실제 배포의 차이, Supabase·Vercel·GitHub 역할

• 현재 앱은 로컬호스트에서만 실행 중이며, 외부 사용자가 접근하려면 별도 배포 과정이 필요하다 [41:37]
• npm run으로 미리보기 주소가 열려도 로컬호스트 주소는 배포된 서비스가 아니며, 그대로 공유하면 실제 운영 환경이 성립하지 않는다 [41:59]

23. CLI 기반 마무리와 배포 과정의 장애 처리

• 개발자들은 보통 터미널에서 Vercel 프로덕션 배포나 도메인 연결 같은 작업을 CLI 명령으로 처리하지만, 이 흐름에서는 Codex에게 Supabase CLI, Vercel CLI, GitHub CLI 작업을 한꺼번에 맡긴다 [42:57]
• “배포랑 데이터베이스 세팅 등 마무리”라는 요청만으로도 에이전트가 필요한 명령과 후속 작업을 시도하며, 최종 배포까지 자동화된 흐름으로 계속된다 [43:27]

24. ERP 예제 리캡과 API 연동 과제로의 전환

• 앞선 작업 흐름은 플랜 문서, 디자인 문서, 에이전트 문서, 백엔드 기본 세팅으로 구성됐고, 앱의 뼈대와 화면 구현까지 완료된 상태다 [45:19]
• 빠진 부분은 API 연동이며, 외부 서비스와 데이터를 붙여야 실제 운영 서비스와 연결되는 앱이 된다 [45:29]

25. 실시간 회의록 앱 생성과 모델·문서 품질 문제

• 새 폴더에서 Codex를 다시 열고 비킷을 시작한 뒤, 실시간으로 미팅 회의록을 기록할 수 있는 서비스를 만들기 위한 플랜 문서 생성이 시작된다 [46:31]
• 플랜 문서, 디자인 문서, 스타일 디자인 문서, 에이전트 문서를 차례로 만든 뒤 앱 구현으로 넘어가는 절차가 다시 적용된다 [46:54]

26. 프로젝트 맥락 문서 정리와 goal 기능 준비

• 디자인 문서에서 네블랩스 스타일을 가져와 붙여 넣고 저장한 뒤, AGENTS.md를 만들어 현재 프로젝트의 맥락을 정리한다 [50:02]
• 생성된 디자인 분석과 프로젝트 맥락을 바탕으로 구현 준비를 마치고, 이후 Codex의 goal 기능으로 배포까지 맡기는 흐름으로 전환된다 [50:23]

27. goal 기능 활성화와 실행 조건 설정

• goal 명령을 사용하려면 CLI 설치 후 config.toml에서 기능을 활성화해야 하며, features 아래에 goals = true 설정이 필요하다 [51:06]
• 이미 업데이트된 환경에서는 기능이 켜져 있지만, 해당 기능이 보이지 않는 경우 설정 파일을 수정해 goal 기능을 활성화해야 한다 [51:18]

28. OpenAI API 키 준비와 Vercel 배포 목표 실행

• 미팅 앱에는 OpenAI에서 제공하는 별도 API가 필요하므로, OpenAI 플랫폼에서 API 키를 발급받고 크레딧도 충전해야 한다 [52:33]
• 프로젝트에는 .env 파일을 만들고 OPENAI_API_KEY 값을 넣어 API 키를 저장한다 [53:26]

29. 배포된 앱 확인과 음성 기능 미완성 문제

• Vercel 배포 URL로 접속한 앱은 화면상으로 열리지만, 기록 추가와 음성 기록 기능이 기대대로 작동하지 않아 추가 검토가 필요해진다 [54:34]
• 앱의 핵심은 음성 API로 회의 내용을 기록하는 기능이므로, UI와 기능을 다시 추가하고 검증한 뒤 제시하라는 수정 목표가 주어진다 [55:07]

30. 재배포 실패와 녹음·전사 검증

• Vercel 프로덕션 환경에 OpenAI 관련 배포가 진행되고, Codex가 직접 테스트 후 보고하도록 설정되지만 실제 배포 화면에서는 HTML이 깨지는 문제가 나타난다 [56:40]
• 라이브 환경의 불안정성이 확인되자, 깨진 화면을 다시 제작·재배포한 뒤 결과를 알려 달라는 추가 목표가 입력된다 [57:21]

31. 음성 전사 앱 완성과 코덱스 기능 평가

• 음성 녹음을 종료한 뒤 전사 기능을 실행하자 텍스트 변환이 완료되고, 전사 품질도 양호한 상태로 확인된다 [1:00:21]
• 회사 내부 회의 전사 앱을 직접 만들 수 있는 흐름이 확인되며, 회의록 앱에 데이터를 쌓은 뒤 별도 에이전트로 확장하는 활용 가능성이 드러난다 [1:00:35]

32. 프로젝트 배포 완료와 조직적 AI 도입 수요

• 남아 있던 1번 프로젝트의 인증 코드 입력과 배포까지 마무리하기로 하며, 2번 프로젝트는 이미 결과가 나온 상태라 1번 프로젝트 배포 여부가 마지막 확인 대상이 된다 [1:02:46]
• 1번 프로젝트도 Vercel URL로 배포가 완료되면서, 처음 만들고자 했던 ERP 형태의 결과물까지 Codex로 구현·배포할 수 있음을 확인하며 마무리된다 [1:03:03]

🧾 결론

• 영상의 핵심은 Codex가 “코드를 잘 짜는가”만이 아니라, 실제 업무형 앱을 끝까지 만들고 배포하는 흐름에서 얼마나 유용한지를 검증하는 데 있다.
• ERP 휴가 시스템과 실시간 회의록 앱 사례를 보면, Codex는 화면 구현, 문서 작성, 배포 시도, 오류 수정까지 넓은 범위를 처리할 수 있지만 결과물을 그대로 신뢰하기보다는 사용자가 직접 기능을 눌러 보고 검증해야 한다.
• 특히 바이브 코딩에서는 “바로 만들어 줘”보다 PRD, 상세 설계, 스타일 기준, 에이전트 지침을 먼저 정리하는 방식이 결과물 품질을 높이는 핵심 준비 단계로 강조된다.
• Codex의 강점은 넉넉한 토큰 사용량, 스킬 재사용, 이미지 생성, 플러그인 기반 확장, goal을 통한 장시간 자동화 작업에 있고, 약점은 설정 이관 문제, 배포 환경 의존성, API 연동 누락, 실제 검증 전까지 드러나지 않는 기능 결함에 있다.
• 검증이 필요한 부분으로는 영상에서 언급된 토큰 절약 효과, 특정 모델·설정의 우월성, 외부 ERP 구독 대체 가능성, 조직 단위 AX 도입 효과 등이 있으며, 이는 각 조직의 업무 복잡도와 운영 환경에 따라 별도 확인이 필요하다.

📈 투자·시사 포인트

• AI 코딩 도구 시장은 단순 코드 자동완성에서 CLI 에이전트, 플러그인, 스킬, 자동화, 배포 지원까지 포함하는 “작업 운영체제” 경쟁으로 확장되고 있다.
• Codex 같은 도구가 실전 앱 개발과 배포까지 관여할수록 Vercel, Supabase, GitHub, OpenAI API처럼 개발 인프라와 연결되는 생태계의 중요성이 더 커질 수 있다.
• 기업 입장에서는 내부 ERP, 회의록, 업무 자동화처럼 작지만 반복적인 사내 도구를 빠르게 시도할 수 있어, 외주·SaaS 구독·내부 개발 리소스 배분 방식에 영향을 줄 가능성이 있다.
• 다만 실제 운영 서비스로 쓰려면 보안, 권한, 데이터베이스, API 키 관리, 배포 환경, 장애 대응, 로그 관리 같은 영역은 여전히 사람이 책임지고 검토해야 한다.
• 비개발자 활용 측면에서는 피그마·문서·프레젠테이션 스킬이 중요한 진입점이 될 수 있으며, AI 코딩 도구의 수요가 개발자 중심에서 기획자·디자이너·운영 담당자까지 넓어질 수 있다.
• 투자 관점에서는 “AI가 코드를 만든다”보다 “AI가 문서화, 설계, 구현, 배포, 검증 루프를 얼마나 안정적으로 묶어 주는가”가 장기 경쟁력 판단 기준이 될 수 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• 영상에서 언급된 GPT 5.5, 이미지 2.0, goal 기능, 플러그인 구조 등은 시연 환경 기준 설명이므로, 실제 사용 가능 여부는 현재 Codex CLI 버전·계정 권한·설정 파일 상태에 따라 별도 확인이 필요하다.
• 패스트 모드가 토큰을 약 1.5배 더 사용한다는 설명은 영상 내 체감·설명에 기반한 내용으로 보이며, 공식 문서나 실제 과금 로그로 검증된 수치인지는 확인이 필요하다.
• 피그마·프레젠테이션·이미지 생성 스킬의 결과 품질은 영상 시연 사례에서는 긍정적으로 다뤄지지만, 입력 문서 품질, 참조 디자인 문서, 모델 설정, 플러그인 상태에 따라 달라질 수 있다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Codex CLI를 설치한 뒤 codex 실행, 슬래시 메뉴, 모델 선택, 리저닝 레벨, 패스트 모드, 퍼미션 모드가 현재 환경에서 동일하게 제공되는지 확인한다.
• config.toml에서 goals = true 설정이 필요한지 확인하고, 현재 CLI 버전에서 goal 명령이 정상 동작하는지 짧은 테스트 목표로 검증한다.
• 풀 액세스 권한을 사용하기 전, 개인 프로젝트 폴더처럼 안전한 샌드박스 환경을 만들고 민감 파일·실서비스 계정에 접근하지 않도록 범위를 제한한다.
• 앱 개발을 바로 시작하지 말고 PRD, 상세 설계 문서, design.md, AGENTS.md를 먼저 만든 뒤 구현을 요청하는 방식으로 실험한다.

❓ 열린 질문

• Codex의 플러그인·스킬·MCP 통합 방식은 현재 공식적으로 어느 범위까지 지원되며, 영상 속 기능들이 모든 사용자에게 동일하게 제공되는가?
• goal 기능은 긴 자동화 작업에서 어느 정도까지 자체 검증을 신뢰할 수 있고, 사람이 반드시 확인해야 하는 단계는 어디인가?
• 풀 액세스 권한을 켰을 때 생산성은 높아지지만, 파일 삭제·비용 발생·외부 배포 같은 위험을 어떻게 통제하는 것이 적절한가?