IDE 안에서 Codex와 페어 프로그래밍하기

에디터 옆자리에 앉은 동료

지난 장에서는 터미널에서 Codex CLI를 사용하는 법을 익혔습니다. CLI는 빠르고 강력합니다. 특히 명령어 실행, 테스트, 파일 수정처럼 개발자의 손이 자주 가는 작업을 한 번에 이어가기 좋습니다. 하지만 코드를 한 줄씩 읽고, 특정 함수만 고치고, 방금 선택한 컴포넌트의 문제를 묻는 순간에는 이야기가 조금 달라집니다.

이때 가장 자연스러운 작업 공간은 IDE입니다. IDE는 코드를 쓰는 자리이자, 파일을 훑어보는 자리이고, 터미널과 Git 변경 사항을 동시에 확인하는 자리입니다. Codex가 이 안으로 들어오면 역할이 더 분명해집니다. 더 이상 "저쪽 채팅창에 코드를 복사해 붙여넣고 답을 다시 가져오는 도구"가 아니라, 지금 열어 둔 파일과 선택한 코드를 함께 보며 대화하는 페어 프로그래머가 됩니다.

OpenAI의 Codex IDE 확장은 VS Code에서 사용할 수 있고, Cursor와 Windsurf 같은 VS Code 계열 에디터에서도 동작합니다. 또한 IDE 안에서 바로 Codex와 나란히 작업하거나, 더 큰 작업을 Codex Cloud로 위임할 수 있습니다.¹ JetBrains 계열 IDE에서는 별도 독립 사이드바가 아니라 JetBrains AI Chat 안에서 Codex를 선택해 사용하는 방식으로 통합되어 있습니다.²

초보자에게는 이 차이가 중요합니다. Codex App은 프로젝트와 작업을 큰 흐름으로 관리하기 좋고, CLI는 터미널 중심의 자동화에 좋습니다. 반면 IDE 안의 Codex는 "이 파일의 이 부분"을 가장 쉽게 가리킬 수 있습니다. 사람이 옆자리 동료에게 모니터를 보여 주며 "여기 봐봐"라고 말하는 것과 비슷합니다.

설치부터 첫 질문까지

먼저 VS Code 계열 IDE부터 보겠습니다. VS Code, Cursor, Windsurf를 사용한다면 기본 흐름은 비슷합니다. 확장 마켓플레이스에서 OpenAI의 Codex 확장을 설치하고, ChatGPT 계정으로 로그인한 뒤, Codex 패널을 열어 간단한 질문으로 연결 상태를 확인하면 됩니다.

처음에는 큰 프로젝트를 맡기지 마세요. 설치 직후에 "전체 앱을 개선해줘" 같은 요청을 보내면, 설정 문제인지 컨텍스트 문제인지 프롬프트 문제인지 구분하기 어렵습니다. 첫 질문은 작고 안전해야 합니다.

이 프로젝트에서 현재 열린 파일의 역할을 5줄로 설명해줘.
코드는 수정하지 말고 설명만 해줘.

이 질문에 Codex가 정상적으로 답한다면 로그인과 패널 연결은 일단 성공입니다. 다음으로 파일을 하나 열고 더 구체적인 질문을 해봅니다.

현재 열린 파일에서 가장 중요한 함수 2개를 찾아서,
각 함수가 하는 일을 초보자도 이해할 수 있게 설명해줘.
아직 코드는 수정하지 마.

여기서 핵심은 "수정하지 마"입니다. 초보자는 설치 확인 단계에서 Codex가 파일을 바꿔 버리면 당황하기 쉽습니다. 처음에는 읽기와 설명만 시켜 보세요. Codex가 내 프로젝트를 어떻게 이해하는지 확인한 뒤에 수정 권한을 주는 편이 안전합니다.

JetBrains 사용자는 흐름이 조금 다릅니다. IntelliJ IDEA, PyCharm, WebStorm, GoLand, Rider 같은 JetBrains IDE에서는 AI Assistant 플러그인을 최신 상태로 두고, AI Chat의 에이전트 선택 메뉴에서 Codex를 선택합니다. JetBrains 공식 안내에 따르면 Codex는 2025.3 버전부터 JetBrains IDE의 AI Chat에서 사용할 수 있으며, JetBrains AI 구독, ChatGPT 계정, OpenAI API 키 방식 중 하나로 인증할 수 있습니다.²

JetBrains에서도 첫 질문은 똑같이 작게 시작합니다.

현재 파일의 구조를 설명해줘.
클래스, 주요 메서드, 외부 의존성을 구분해서 알려줘.
코드는 수정하지 마.

IDE마다 버튼 이름과 패널 위치는 조금씩 다를 수 있습니다. 하지만 성공 기준은 같습니다. Codex가 현재 프로젝트와 파일에 대해 답할 수 있고, 사용자가 원할 때만 수정 작업으로 넘어갈 수 있으면 됩니다.

모드 선택: 설명만 할지, 직접 고칠지 정하기

IDE 안의 Codex를 사용할 때 가장 먼저 익혀야 할 것은 모드입니다. 모드는 Codex에게 어느 정도의 자율성을 줄지 정하는 스위치입니다. JetBrains 문서에서는 Codex가 Read-only, Agent, Agent full access 같은 모드를 제공한다고 설명합니다. Read-only에서는 코드베이스를 둘러보고 설명할 수 있지만 파일 수정이나 명령 실행은 제한됩니다. Agent 모드에서는 프로젝트 작업 공간 안에서 파일을 수정할 수 있고, 필요한 경우 승인을 요청합니다. Agent full access는 훨씬 넓은 권한을 주므로 신중하게 사용해야 합니다.³

초보자에게 추천하는 기본값은 간단합니다. 이해와 분석은 읽기 전용에 가깝게, 작은 수정은 Agent 모드로, Full Access는 정말 필요한 순간에만 사용하세요. 특히 아직 프로젝트 구조를 잘 모르는 상태라면 Full Access로 시작하지 않는 편이 좋습니다. AI가 나쁘기 때문이 아니라, 좋은 동료에게도 처음부터 집 열쇠와 회사 서버 비밀번호를 모두 맡기지는 않기 때문입니다.

실전에서는 이렇게 생각하면 쉽습니다.

승인 요청이 나오면 귀찮다고 바로 누르지 말고, 명령어를 읽어보세요. 예를 들어 npm install은 패키지를 설치하는 명령이고, npm run test는 테스트를 실행하는 명령입니다. 모르는 명령이 나오면 Codex에게 먼저 물어보면 됩니다.

방금 실행하려는 명령이 무슨 일을 하는지 설명해줘.
내 프로젝트 파일을 변경하는 명령인지도 알려줘.

이 습관 하나만으로도 사고를 많이 줄일 수 있습니다.

열린 파일, 선택 코드, @file로 컨텍스트 주기

IDE에서 Codex를 쓰는 가장 큰 이유는 컨텍스트 전달이 쉽기 때문입니다. 컨텍스트란 Codex가 답을 만들 때 참고하는 정보입니다. 사람에게 질문할 때도 "이 함수 봐봐", "이 파일 기준으로", "아까 만든 API와 연결해서"라고 말하듯이 Codex에게도 무엇을 봐야 하는지 알려줘야 합니다.

가장 기본은 열린 파일입니다. 관련 파일을 IDE 탭에 열어 두면 Codex가 현재 작업 흐름을 이해하는 데 도움이 됩니다. 예를 들어 React 컴포넌트를 고치고 싶다면 컴포넌트 파일만 열어 두는 것보다, 그 컴포넌트가 호출하는 API 함수 파일도 함께 열어 두면 좋습니다.

다음은 선택한 코드입니다. IDE에서 특정 함수나 코드 블록을 드래그해 선택한 뒤 Codex에게 질문하면, "전체 프로젝트"가 아니라 "이 부분"에 집중시킬 수 있습니다.

선택한 함수가 너무 길어졌어.
동작은 바꾸지 말고 읽기 쉽게 나누는 방법을 제안해줘.
먼저 계획만 보여주고, 아직 수정하지 마.

이 요청은 초보자에게 매우 안전합니다. 바로 고치지 않고 계획을 먼저 받기 때문입니다. 계획이 마음에 들면 다음 단계에서 실행을 요청합니다.

좋아. 제안한 계획 중 1번 방식으로만 수정해줘.
공개 함수 이름과 반환값은 바꾸지 마.
수정 후 어떤 파일이 바뀌었는지 요약해줘.

또 하나 강력한 방법은 @file 참조입니다. Codex 확장에서는 프롬프트 안에서 파일을 직접 태그해 "이 파일을 참고해"라고 말할 수 있습니다. 예를 들어 @example.tsx를 참고해 새 페이지를 만들거나, @resources.ts에 정의된 데이터를 사용하라고 지시하는 식입니다.⁴

@src/pages/Home.tsx 의 레이아웃 스타일을 참고해서
@src/pages/Resources.tsx 페이지를 만들어줘.
데이터는 @src/data/resources.ts 에 있는 배열을 사용해줘.
새로운 CSS 프레임워크는 추가하지 마.

이렇게 쓰면 Codex가 엉뚱한 파일을 추측할 가능성이 줄어듭니다. 특히 파일명이 비슷한 프로젝트에서는 @file이 큰 차이를 만듭니다. user.ts, users.ts, UserPage.tsx, useUsers.ts가 함께 있는 프로젝트에서 "사용자 파일 봐줘"라고 말하면 애매합니다. 반면 @src/hooks/useUsers.ts라고 쓰면 방향이 분명합니다.

컨텍스트를 줄 때는 많이 주는 것보다 정확히 주는 것이 중요합니다. 초보자는 불안해서 프로젝트 전체를 설명하려고 하지만, 실제로는 다음처럼 좁히는 편이 더 좋습니다.

문제 상황: 할 일 추가 버튼을 눌러도 목록이 갱신되지 않음
볼 파일: @src/components/TodoForm.tsx, @src/hooks/useTodos.ts
원하는 결과: 원인 후보 3개와 확인 순서 제안
제한: 아직 코드는 수정하지 말 것

이 정도면 Codex가 탐정처럼 움직일 수 있습니다. 사건 장소, 참고 파일, 원하는 결과, 금지 조건이 모두 들어 있기 때문입니다.

IDE 패널에서 바로 써먹는 요청 예시

이제 실제로 어떤 일을 맡길 수 있는지 보겠습니다. IDE 안의 Codex는 "지금 눈앞의 코드"를 다루는 작업에 특히 강합니다. 설명, 버그 분석, 테스트 생성, 보안 리뷰처럼 개발 중 자주 마주치는 일을 바로 요청할 수 있습니다.

함수 설명 요청

처음 보는 함수는 겁부터 납니다. 이름도 길고, 인자도 많고, 조건문도 겹겹이 쌓여 있으면 어디서부터 읽어야 할지 막막합니다. 이때는 선택한 함수만 대상으로 설명을 요청합니다.

선택한 함수를 초보자 기준으로 설명해줘.
다음 순서로 알려줘.
1. 이 함수의 목적
2. 입력값과 반환값
3. 중요한 조건문
4. 실수하기 쉬운 부분
코드는 수정하지 마.

좋은 설명은 단순 번역이 아닙니다. map, filter, reduce가 무엇인지 모르는 사람에게도 흐름이 보이도록 풀어주는 설명이어야 합니다. Codex 답변이 너무 어렵다면 다시 요청하세요.

방금 설명이 아직 어려워.
중학생도 이해할 수 있게 비유를 들어 다시 설명해줘.

버그 분석 요청

버그가 났을 때 초보자가 가장 많이 하는 실수는 에러 메시지 일부만 보고 바로 코드를 고치는 것입니다. 그러면 원인이 아니라 증상만 건드릴 수 있습니다. 먼저 분석을 시키세요.

브라우저 콘솔에 다음 에러가 나와.

Cannot read properties of undefined (reading 'map')

관련 파일은 @src/components/TodoList.tsx 와 @src/hooks/useTodos.ts 야.
원인 후보를 가능성 높은 순서로 3개만 제시해줘.
아직 수정하지 말고, 확인해야 할 코드 위치를 알려줘.

여기서 "가능성 높은 순서"와 "3개만"이 중요합니다. Codex가 너무 많은 가능성을 늘어놓지 않게 해줍니다. 원인 후보를 확인한 뒤에는 하나만 골라 고치게 합니다.

1번 원인이 맞는 것 같아.
최소 변경으로 수정해줘.
기존 컴포넌트 props 이름은 바꾸지 마.
수정 후 왜 해결되는지 설명해줘.

테스트 생성 요청

테스트는 초보자에게 어렵지만, Codex와 함께하면 시작 장벽이 낮아집니다. 이미 있는 테스트 스타일을 참고하게 하면 더 좋습니다.

@src/utils/formatDate.ts 에 대한 테스트를 추가해줘.
@src/utils/formatCurrency.test.ts 의 스타일을 참고해줘.
다음 경우를 포함해줘.
- 정상 날짜
- 잘못된 날짜 문자열
- 빈 값
새 테스트 라이브러리는 추가하지 마.

테스트를 생성한 뒤에는 바로 통과한다고 믿지 말고 실행해야 합니다.

방금 추가한 테스트를 실행하려면 어떤 명령을 쓰면 돼?
명령을 실행하기 전에 무엇을 확인해야 하는지도 알려줘.

Codex가 테스트 명령 실행을 제안하면 승인하기 전에 명령어를 확인합니다. 실행 후 실패하면 실패 메시지를 다시 Codex에게 보여 주세요.

테스트가 실패했어. 실패 메시지는 아래와 같아.

[실패 메시지 붙여넣기]

테스트 기대값이 잘못된 건지, 구현 코드가 잘못된 건지 구분해서 설명해줘.

이렇게 하면 테스트가 "AI가 만들어 준 장식품"이 아니라 실제 검증 도구가 됩니다.

보안 리뷰 요청

로그인, 결제, 개인정보, 관리자 기능처럼 민감한 부분은 Codex에게 보안 관점 리뷰를 요청해 볼 수 있습니다. 다만 보안 리뷰는 최종 판단이 아니라 1차 점검이라고 생각해야 합니다.

선택한 로그인 API 코드를 보안 관점에서 리뷰해줘.
특히 다음을 확인해줘.
1. 비밀번호 처리
2. 에러 메시지로 정보가 새는지
3. 토큰 생성과 만료 처리
4. 입력값 검증
코드는 수정하지 말고 위험도와 개선안을 먼저 알려줘.

보안 리뷰에서는 "바로 고쳐줘"보다 "위험도와 개선안"을 먼저 받는 편이 좋습니다. 보안 수정은 작은 변경처럼 보여도 사용자 경험이나 기존 테스트에 영향을 줄 수 있기 때문입니다.

작은 수정은 IDE, 큰 리팩토링은 Cloud

IDE 안의 Codex는 가까운 동료입니다. 바로 옆에서 질문하고, 작은 코드를 고치고, 테스트를 추가하는 데 좋습니다. 하지만 모든 일을 IDE에서 붙잡고 있을 필요는 없습니다. 큰 리팩토링, 여러 파일에 걸친 기능 추가, 오래 걸리는 테스트와 설치가 필요한 작업은 Cloud로 위임하는 편이 더 나을 수 있습니다. OpenAI의 IDE 안내에서도 IDE 안에서 Codex를 사용하면서 Codex Cloud에 작업을 위임할 수 있다고 설명합니다.¹

판단 기준은 "내가 옆에서 계속 봐야 하는가?"입니다. 계속 봐야 한다면 IDE가 좋습니다. 맡겨 두고 다른 일을 해도 된다면 Cloud가 좋습니다.

예를 들어 버튼 컴포넌트의 disabled 스타일이 이상하다면 IDE에서 바로 해결하면 됩니다.

선택한 Button 컴포넌트에서 disabled 상태의 스타일만 수정해줘.
기존 props와 파일 구조는 바꾸지 마.
변경은 이 파일 안에서 끝내줘.

반대로 앱 전체를 JavaScript에서 TypeScript로 옮기는 작업이라면 IDE 패널에서 계속 지켜보기에는 부담이 큽니다. 이때는 먼저 IDE에서 계획을 세우고, Cloud로 넘기는 방식이 좋습니다.

이 프로젝트를 TypeScript로 전환하려고 해.
먼저 변경 범위와 위험 요소를 분석해줘.
코드는 수정하지 말고 단계별 계획만 작성해줘.

계획을 확인한 뒤에는 Cloud 작업으로 위임합니다.

방금 계획 중 1단계만 Cloud에서 진행해줘.
목표는 TypeScript 설정 추가와 최소 파일 변환이야.
동작 변경은 하지 말고, 빌드가 통과하는 상태를 목표로 해줘.

큰 작업을 나누는 이유는 간단합니다. AI도 한 번에 너무 많은 결정을 하게 되면 의도와 다른 방향으로 갈 수 있습니다. "전체를 멋지게 바꿔줘"는 위험하고, "1단계만, 설정 추가와 최소 변환만"은 안전합니다.

App과 IDE를 함께 쓰는 흐름

Codex App과 IDE는 서로 경쟁하는 도구가 아닙니다. App은 작업의 큰 단위와 히스토리를 관리하기 좋고, IDE는 코드의 세부 맥락을 확인하기 좋습니다. 같은 프로젝트를 두 화면에서 보는 흐름에 익숙해지면 훨씬 안정적으로 작업할 수 있습니다.

예를 들어 App에서 "날씨 대시보드의 오류 상태 개선"이라는 작업을 만들었다고 해봅시다. Codex가 Cloud에서 변경을 만들고 diff를 제안합니다. 이때 App 화면에서 전체 변경 요약을 먼저 봅니다. 어떤 파일이 바뀌었는지, 테스트는 무엇을 실행했는지, 실패한 부분은 없는지 확인합니다.

그다음 IDE에서 같은 브랜치나 같은 작업 결과를 열어 실제 코드를 봅니다. App에서는 "변경된 파일 목록"이 잘 보이고, IDE에서는 "이 변경이 주변 코드와 어울리는지"가 잘 보입니다. 특히 초보자는 diff만 보고 넘어가지 말고, IDE에서 실제 파일을 열어 흐름을 확인하는 습관을 들이는 것이 좋습니다.

실전 흐름은 다음처럼 가져갈 수 있습니다.

1. App에서 작업 생성: 목표, 범위, 완료 기준을 적습니다.

2. Cloud가 변경 생성: 큰 작업을 백그라운드에서 처리합니다.

3. App에서 요약 검토: 파일 목록, 테스트 결과, 주요 결정을 확인합니다.

4. IDE에서 세부 검토: 변경된 파일을 열고 Codex에게 설명과 위험 요소를 묻습니다.

5. IDE에서 작은 후속 수정: 문구, 스타일, 테스트 이름처럼 세밀한 부분을 다듬습니다.

IDE에서 검토할 때는 이런 프롬프트가 유용합니다.

현재 Git 변경 사항을 기준으로 리뷰해줘.
의도와 무관해 보이는 변경이 있는지 확인하고,
초보자가 놓치기 쉬운 위험 요소를 알려줘.
아직 추가 수정은 하지 마.

또는 특정 파일을 열고 이렇게 물을 수 있습니다.

이 파일은 Cloud 작업 결과로 변경됐어.
변경 전후 동작 차이를 설명해줘.
기존 기능이 깨질 가능성이 있는 부분도 알려줘.

이 흐름의 핵심은 "큰 일은 맡기고, 중요한 판단은 사람이 한다"입니다. Codex가 작업을 빠르게 진행하더라도, 최종적으로 어떤 변경을 받아들일지는 개발자가 결정해야 합니다.

Cursor, Windsurf, JetBrains에서의 감각 차이

Codex가 VS Code 계열 확장으로 동작한다는 말은 VS Code만 의미하지 않습니다. Cursor와 Windsurf처럼 VS Code 기반의 에디터에서도 사용할 수 있습니다.¹ 다만 각 에디터는 자체 AI 기능을 함께 제공하기 때문에, 처음에는 기능이 겹쳐 보일 수 있습니다.

초보자라면 한 번에 여러 AI 패널을 모두 켜고 쓰기보다, 작업마다 역할을 나누는 편이 좋습니다. 예를 들어 Cursor의 자동완성은 빠른 타이핑 보조로 쓰고, Codex는 명시적인 작업 지시와 Cloud 위임에 쓰는 식입니다. Windsurf에서도 마찬가지입니다. "지금 이 줄을 빨리 완성하기"와 "이 버그를 분석하고 테스트까지 추가하기"는 다른 작업입니다.

JetBrains는 구조가 또 다릅니다. Codex가 JetBrains AI Chat 안에 들어와 있기 때문에, 기존 JetBrains 단축키와 프로젝트 탐색, 리팩터링 도구를 함께 쓰기 좋습니다. JetBrains 공식 문서에 따르면 Codex는 기능 설계와 구현, 버그 수정, 질문 답변, 코드 리뷰 같은 개발 작업을 도울 수 있으며, 모델과 추론 수준도 선택할 수 있습니다.³

어떤 IDE가 더 좋으냐보다 중요한 질문은 이것입니다.

"내가 지금 코드를 어디서 가장 편하게 읽고 고칠 수 있는가?"

이미 VS Code에 익숙하다면 VS Code에서 시작하세요. Cursor를 매일 쓴다면 Cursor에 Codex를 붙이면 됩니다. PyCharm이나 IntelliJ 단축키에 익숙하다면 JetBrains AI Chat의 Codex가 자연스럽습니다. 도구를 바꾸느라 힘을 빼기보다, 이미 손에 익은 환경 안으로 Codex를 들여오는 것이 좋습니다.

실전 미니 시나리오: 할 일 앱의 버그 잡기

간단한 상황을 하나 가정해 보겠습니다. 할 일 관리 앱에서 새 할 일을 추가하면 서버에는 저장되지만 화면 목록은 바로 갱신되지 않습니다. 초보자는 이럴 때 어디부터 봐야 할지 막막합니다. IDE 안의 Codex를 사용하면 문제를 좁혀갈 수 있습니다.

먼저 관련 파일을 엽니다.

TodoForm.tsx는 입력창과 추가 버튼을 담당합니다. TodoList.tsx는 목록을 보여줍니다. useTodos.ts는 할 일 목록을 불러오고 추가하는 훅입니다. 이 세 파일을 열어 둔 뒤 Codex에게 묻습니다.

문제: 새 할 일을 추가하면 서버에는 저장되지만 화면 목록이 바로 갱신되지 않아.
관련 파일은 @src/components/TodoForm.tsx, @src/components/TodoList.tsx, @src/hooks/useTodos.ts 야.
먼저 데이터 흐름을 설명하고, 원인 후보를 3개만 제시해줘.
코드는 수정하지 마.

Codex가 원인 후보로 "추가 후 목록 재조회가 없음", "상태 업데이트가 누락됨", "캐시 무효화가 안 됨" 같은 답을 줄 수 있습니다. 그다음 가장 가능성 높은 원인을 확인합니다.

추가 성공 후 목록 상태가 갱신되는지 확인해줘.
필요한 코드 위치를 짚어주고,
최소 수정으로 해결하는 계획을 제안해줘.
아직 수정하지 마.

계획이 납득되면 수정합니다.

제안한 최소 수정 방식으로 고쳐줘.
수정 범위는 @src/hooks/useTodos.ts 안으로 제한해줘.
기존 컴포넌트 props는 바꾸지 마.
수정 후 테스트하거나 수동 확인할 방법을 알려줘.

수정이 끝났다고 끝이 아닙니다. IDE에서 Git diff를 열어 변경된 줄을 확인합니다. 그리고 Codex에게 다시 검토를 요청합니다.

방금 변경된 diff를 리뷰해줘.
불필요한 변경이 있는지,
동시에 두 번 추가 버튼을 눌렀을 때 문제가 생길 수 있는지 확인해줘.

이 시나리오의 핵심은 한 번에 "버그 고쳐줘"라고 던지지 않았다는 점입니다. 설명, 원인 후보, 계획, 수정, 리뷰로 나누었습니다. IDE 안에서 Codex를 쓸 때는 이 작은 단계들이 작업 품질을 크게 높입니다.

초보자가 자주 하는 실수

IDE 안의 Codex는 편리해서 오히려 실수하기 쉽습니다. 버튼 하나로 코드가 바뀌고, 그럴듯한 설명이 나오기 때문입니다. 다음 실수만 피해도 훨씬 안전해집니다.

첫째, 선택한 코드 없이 너무 넓게 요청하는 것입니다.

이 프로젝트 개선해줘.

이 요청은 위험합니다. Codex가 무엇을 개선해야 하는지, 어디까지 바꿔도 되는지 알 수 없습니다. 대신 범위를 좁히세요.

@src/components/TodoList.tsx 만 대상으로 읽기 쉬운지 리뷰해줘.
코드는 수정하지 말고 개선 후보 3개만 알려줘.

둘째, 계획 없이 바로 대규모 수정을 맡기는 것입니다. 리팩토링은 멋진 단어지만, 초보자에게는 "어디가 왜 바뀌었는지 모르는 상태"가 되기 쉽습니다. 항상 계획을 먼저 받으세요.

코드는 아직 수정하지 말고,
이 파일을 리팩토링한다면 어떤 순서로 나누는 게 안전한지 알려줘.

셋째, diff를 확인하지 않는 것입니다. Codex가 만든 변경은 반드시 사람이 읽어야 합니다. IDE의 Source Control 패널이나 Git diff 화면을 열고, 바뀐 파일을 하나씩 확인하세요. 이해가 안 되는 변경이 있으면 Codex에게 물어보면 됩니다.

이 변경이 왜 필요한지 설명해줘.
만약 제거해도 된다면 제거해줘.

넷째, 테스트 없이 "잘 됐겠지"라고 믿는 것입니다. AI가 만든 코드도 실행 전에는 가설입니다. 테스트가 있으면 테스트를 실행하고, 없으면 최소한 수동 확인 절차를 적게 하세요.

이 변경을 확인하기 위한 수동 테스트 절차를 작성해줘.
브라우저에서 어떤 순서로 클릭해야 하는지 알려줘.

다섯째, 민감한 파일을 무심코 컨텍스트에 넣는 것입니다. .env, 비밀 키, 실제 사용자 데이터, 토큰이 들어 있는 파일은 Codex에게 넘기지 않는 것이 원칙입니다. 필요한 경우 값은 가리고 구조만 설명하세요.

환경 변수 이름만 기준으로 설정 문제를 봐줘.
실제 키 값은 공유하지 않을게.

이런 습관은 나중에 보안 장에서 더 자세히 다루겠지만, IDE에서 매일 Codex를 쓸 때부터 몸에 익혀야 합니다.

나만의 IDE 페어 프로그래밍 루틴

이 장의 내용을 하루 작업 루틴으로 정리해 보겠습니다. 아침에 프로젝트를 열면 먼저 오늘 고칠 파일을 IDE에 열어 둡니다. Codex에게 전체 프로젝트가 아니라 오늘의 작업 범위를 알려줍니다.

오늘 작업 범위는 @src/components/TodoForm.tsx 와 @src/hooks/useTodos.ts 야.
목표는 할 일 추가 UX 개선이야.
먼저 현재 구조와 위험 요소를 요약해줘.
코드는 수정하지 마.

그다음 작은 단위로 하나씩 진행합니다. 버튼 문구 수정, 로딩 상태 추가, 에러 메시지 표시, 테스트 추가처럼 눈에 보이는 단위로 쪼갭니다.

할 일 추가 중에는 버튼을 비활성화하고 "추가 중..." 문구를 보여줘.
수정 범위는 TodoForm 컴포넌트로 제한해줘.
스타일 구조는 유지해줘.

변경 후에는 바로 검토합니다.

방금 변경에서 접근성 문제가 없는지 확인해줘.
키보드 사용이나 스크린리더 관점에서 놓친 부분이 있으면 알려줘.

작업이 커지면 Cloud로 넘깁니다.

이제 남은 작업은 에러 처리 UX를 앱 전체에 통일하는 거야.
범위가 여러 파일이라 Cloud 작업으로 진행하고 싶어.
먼저 작업 계획과 예상 변경 파일을 정리해줘.

마지막에는 App이나 IDE에서 같은 변경 사항을 다시 확인합니다.

오늘 변경된 전체 diff를 요약해줘.
사용자에게 보이는 변화, 내부 코드 정리, 테스트 변경을 나눠서 설명해줘.

이 루틴을 반복하면 Codex를 쓰는 감각이 달라집니다. 처음에는 "AI에게 시키는 느낌"이지만, 점점 "작업을 함께 나누는 느낌"에 가까워집니다. 좋은 페어 프로그래밍은 한 사람이 모든 것을 대신해주는 것이 아닙니다. 한 사람이 방향을 잡고, 다른 사람이 빠르게 시도하고, 다시 함께 검토하는 과정입니다.

마무리: IDE Codex는 가장 가까운 동료다

IDE 안의 Codex는 코드를 직접 읽고 고쳐야 할 때 가장 자연스럽습니다. 열린 파일을 보고, 선택한 코드에 대해 답하고, @file로 지정한 파일을 참고하며, 작은 수정과 리뷰를 빠르게 반복할 수 있기 때문입니다.

다만 가까운 동료일수록 역할을 분명히 해야 합니다. 설명만 필요한지, 계획이 필요한지, 직접 수정해도 되는지, Cloud로 넘길 만큼 큰 작업인지 먼저 정하세요. 그리고 어떤 경우에도 diff와 테스트를 확인하세요.

이제 여러분은 Codex를 세 가지 거리에서 다룰 수 있게 되었습니다. App에서는 프로젝트와 작업을 관리하고, CLI에서는 터미널 중심으로 자동화하고, IDE에서는 코드 바로 옆에서 함께 읽고 고칩니다. 다음 장에서는 이 흐름을 Git과 worktree로 더 안전하게 만들겠습니다. 같은 프로젝트 안에서 여러 시도를 분리하고, 마음에 드는 변경만 남기는 방법을 배우게 됩니다.

참고

¹OpenAI Developers - Codex IDE extension

²JetBrains AI Blog - Codex Is Now Integrated Into JetBrains IDEs

³JetBrains AI Assistant Documentation - Codex

⁴Codex로 시작하는 개발 환경 가이드