# 아.. Codex 그렇게 쓰는거 아닌데... Codex 다들 잘 쓰는 줄 알았는데, 완전 반대로 쓰고 있습니다. 기능만 보고 쓰면 그냥 코...
Canonical: https://social-archive.org/babyz79/lUQNKiEEX6
Original URL: https://www.threads.com/@choi.openai/post/DWaYjyhiH8M
Author: CHOI
Platform: threads
## Content
아.. Codex 그렇게 쓰는거 아닌데... Codex 다들 잘 쓰는 줄 알았는데, 완전 반대로 쓰고 있습니다. 기능만 보고 쓰면 그냥 코드 생성기고, 제대로 쓰는 사람은 “workflow”로 씁니다. 이 차이 하나로 생산성 격차 벌어지는 오픈AI에서 직접 공유한 사례 정리했습니다🧵 --- 1/ Codex를 가장 실무적으로 잘 활용하는 방법 중 하나는 GitHub의 코드 리뷰어로 투입하는 것입니다. Pull Request(PR)가 올라올 때마다 누락된 테스트, 보안 취약점, 문서화 부족 등을 사람이 확인하기 전에 자동으로 먼저 걸러내는 1차 방어선 역할을 수행하게 만들 수 있습니다. 특히 AGENTS.md 파일에 "오타는 P0, 누락된 문서는 P1으로 분류해라"와 같이 팀의 리뷰 규칙을 명시해 두면, Codex는 프로젝트의 기준에 맞춰 깐깐하게 리뷰를 진행합니다. 리뷰 중 발견된 문제가 있다면 PR 댓글에 @codex fix it이라고 남기는 것만으로 문제 수정부터 PR 업데이트까지 원스톱으로 처리할 수 있습니다. --- 2/ 프론트엔드 작업 시나리오에서 Codex의 진가는 Playwright 스킬과 결합될 때 나타납니다. 스크린샷이나 Figma 디자인 링크를 던져주고 "코드로 만들어 줘"라고만 하면 흔한 기본 UI가 나오기 십상입니다. 올바른 워크플로우는 기존 프로젝트의 디자인 시스템과 컴포넌트를 재사용하도록 강제한 뒤, Codex가 코드를 작성하게 하는 것입니다. 그리고 여기서 끝나는 것이 아니라, Playwright를 통해 Codex가 자신이 짠 코드를 실제 브라우저(모바일, 데스크톱 등 다양한 해상도)에서 띄우고, 원본 이미지와 시각적으로 비교하며 완벽해질 때까지 스스로 레이아웃을 반복 수정(Iterate)하게 만들어야 합니다. --- 3/ 데이터 분석 시 Codex를 단순히 Python 코드를 짜주는 도구로 쓰면 나중에 재사용하기 어려운 지저분한 코드가 남습니다. 오픈AI는 [데이터 불러오기 -> 병합(Merge) 전 검증 -> 독립된 환경(Worktree)에서 탐색적 분석 -> 해석 가능한 모델링 -> 결과 보고서 작성]이라는 명확한 루프를 제안합니다. 특히 데이터를 병합하기 전에 먼저 결측치와 키 값을 프로파일링하도록 지시하고, 시각화나 가설 검증은 별도의 'Git Worktree'를 파서 작업하게 함으로써 메인 코드가 오염되지 않게 해야 합니다. 최종 결과물도 일회성 노트북 뷰가 아니라, 경영진이 볼 수 있는 PDF나 .docx 리포트, 혹은 배포 가능한 대시보드 형태로 패키징하도록 지시하는 것이 핵심입니다. --- 4/ ChatGPT용 앱이나 MCP 서버를 만들 때 흔히 하는 실수는 "내 서비스 전체를 채팅창으로 옮겨줘"라고 거대한 프롬프트를 던지는 것입니다. 올바른 접근은 3~5개의 핵심 도구(Tools)로 구성된 좁고 명확한 한 가지 사용자 목표(User outcome)에서 출발하는 것입니다. 한 번에 구현하려 하지 말고, [기획 -> 뼈대(Scaffold) 코드 작성 -> 익명/읽기 전용 테스트 -> 꼭 필요한 곳에만 OAuth 추가 -> 배포 및 검토]의 단계별로 작업을 잘게 쪼개어 지시해야 합니다. 또한 $openai-docs 스킬을 연결해 Codex가 최신 OpenAI API 문서를 먼저 읽고 코드를 짜도록 강제해야 낡은 문법으로 코드를 작성하는 실수를 막을 수 있습니다. --- 5/ 단번에 정답이 나오지 않는 어려운 최적화 문제나 주관적인 품질 평가가 필요한 작업(예: 이미지 생성, 복잡한 로직)은 '평가 기반 반복 루프(Eval-Driven Loop)'로 해결해야 합니다. Codex에게 스코어를 측정할 수 있는 평가 스크립트(Deterministic checks)와 LLM 기반의 채점 기준(LLM-as-a-judge)을 주고, "이 두 점수가 모두 90점을 넘을 때까지 계속 코드를 고치고 테스트해라"라고 '명확한 종료 조건(Stopping rule)'을 부여합니다. 이 과정에서 Codex가 각 반복마다 무엇이 변했고 점수가 어떻게 달라졌는지 로그를 남기게 하면, 작업이 오래 걸려도 방향을 잃지 않고 신뢰할 수 있는 결과물에 도달하게 됩니다. --- 6/ 위의 모든 워크플로우를 관통하는 가장 중요한 비밀 무기는 프로젝트 최상단에 위치하는 AGENTS.md 파일입니다. 팀의 파이썬 환경(예: uv 사용), 데이터 저장 폴더 규칙("절대 원본 데이터를 덮어쓰지 말 것"), 코드 리뷰 기준("보안 위협은 P0로 분류") 등 프로젝트의 헌법과 같은 규칙들을 이 파일에 적어두면 됩니다. Codex는 매번 프롬프트로 지시하지 않아도 이 파일을 읽고 프로젝트의 맥락과 팀의 컨벤션을 정확히 따르며 자율적으로 움직이는 똑똑한 실무자로 변모하게 됩니다. --- 전체 유스케이스 : https://developers.openai.com/codex/use-cases