3
Codex 사용법 3강. 채널 선택
Lesson 03

같은 문제라도
어느 채널에서 처리하느냐에 따라
속도와 안정성이 달라집니다.

이번 강의는 로그인 실패 시 에러 메시지가 사라지는 문제를 기준으로, IDE, CLI, Cloud/Web, PR 흐름 중 어디에서 다루는 것이 가장 자연스러운지 비교합니다.

기준 날짜 2026-04-13

이 가이드는 OpenAI Codex 제품, 정책, 표준 변경에 따라 이후 달라질 수 있습니다.

공통 예시 — 로그인 에러 메시지 사라지는 문제 (펼치기)
문제: 로그인 실패 시 에러 메시지가 화면에서 사라집니다.
범위: auth/LoginForm.tsx, auth/useLogin.ts, auth/LoginForm.test.tsx
제약: UI 문구 유지, API 스펙 유지, auth 범위 안에서만 수정, npm test -- auth로 검증합니다.
Channel Map

같은 로그인 문제라도 잘 맞는 채널이 다릅니다

IDE현재 auth 코드 구조를 읽고, 원인을 파악하고, 작은 수정 방향을 잡을 때 가장 빠릅니다.
CLI실제 수정과 npm test -- auth 같은 검증을 이어서 수행하기 좋습니다.
Cloud/Web긴 분석, 비동기 조사, 오래 걸리는 작업 초안에 적합합니다.
PR 흐름리뷰 포인트 정리, 회귀 위험 점검, 후속 수정 제안에 잘 맞습니다.
Channel Decision Flow
지금 하려는 작업이 무엇인가요?
코드 탐색·원인 파악
설명 요청
↓
IDE
파일 수정 +
검증 명령 실행
↓
CLI
긴 분석·비동기
작업 초안 작성
↓
Cloud / Web
리뷰·회귀 점검
후속 수정 제안
↓
PR 흐름
Good Routing

채널을 잘 고른 경우

  • 로그인 실패 원인 파악은 IDE에서 시작합니다.
  • 수정과 테스트 실행은 CLI에서 묶어 처리합니다.
  • 긴 인증 흐름 분석은 Cloud/Web로 넘깁니다.
  • PR 단계에서는 회귀 위험과 리뷰 포인트를 정리합니다.
Bad Routing

채널을 잘못 고른 경우

  • 작은 수정인데 Cloud/Web부터 열어 과하게 크게 시작합니다.
  • 로컬 검증이 필요한데 PR 코멘트만 남기고 끝냅니다.
  • 긴 분석이 필요한데 IDE 한 화면 안에서만 해결하려고 합니다.
  • 검증 없이 단일 채널에서 끝내려고 합니다.
Harness Engineering

하네스 엔지니어링이란 무엇인가요

간단하게

AI에게 일을 잘 시키기 위해, 모델 바깥의 작업 환경을 설계하는 것입니다. 프롬프트만 잘 쓰는 게 아니라, 어떤 파일을 읽게 할지, 어떤 도구를 쓰게 할지, 어떤 테스트를 돌리게 할지, 어디까지 수정 가능하게 할지, 실패하면 어떻게 다시 검증할지까지 묶어서 설계하는 일입니다.

프롬프트 엔지니어링과 비교하면
프롬프트 엔지니어링 — 무슨 말을 할까
컨텍스트 엔지니어링 — 어떤 배경 정보를 줄까
하네스 엔지니어링 — AI가 어떤 환경에서, 어떤 규칙으로, 어떻게 검증받으며 일하게 만들까
하네스에 포함되는 것들 AGENTS.md · Skill · Approval 정책 · Sandbox 범위 · 검증 명령 · 평가 기준 · 재시도 규칙 · 사람 리뷰 지점. 이 강의에서는 그중 approval, sandbox, reasoning effort, config.toml부터 다룹니다.
Controls

approval, sandbox, reasoning effort는 이렇게 이해하면 됩니다

approval위험한 실행 전 사람 확인을 거치는 장치입니다. 범위가 커질수록 더 중요해집니다.
sandbox수정 범위와 실행 범위를 제한하는 장치입니다. 입문자는 기본 제한 모드가 안전합니다.
reasoning effort단순 수정과 복잡한 판단의 두뇌 강도를 나누는 개념입니다. 작업 복잡도에 맞게 고릅니다.

Reasoning Effort 5단계

레벨언제 쓰나auth 예시
minimal단순 조회, 짧은 수정변수명·문자열 변경
low범위가 명확한 작업auth 버그 수정
medium일반 구현새 기능 추가
high복잡한 디버깅·설계인증 흐름 재설계
xhigh긴 agentic 작업멀티파일 리팩터
Harness Config

config.toml로 기본값을 고정할 수 있습니다

매번 플래그로 지정하는 대신 설정 파일에 기본값을 저장하면 팀 전체에 일관된 환경을 유지할 수 있습니다.

개인 설정
# ~/.codex/config.toml
model = "gpt-5.4"
model_reasoning_effort = "medium"
approval_policy = "on-request"
sandbox_mode = "workspace-write"

나 혼자 쓰는 기본값입니다. 팀 저장소에 커밋하지 않습니다.

프로젝트 설정
# .codex/config.toml (프로젝트 루트)
model = "gpt-5.4-mini"
model_reasoning_effort = "low"
approval_policy = "untrusted"
sandbox_mode = "workspace-write"

팀 전체에 적용됩니다. 저장소에 커밋해 공유합니다.

일회성 오버라이드 설정 파일을 바꾸지 않고 한 번만 다르게 실행할 때는 CLI 플래그를 씁니다.
codex -m gpt-5.4 --model-reasoning-effort high "auth 흐름 전체 분석해줘"
Shortcuts & Commands

자주 쓰는 단축키와 슬래시 커맨드

키보드 단축키
단축키기능
Shift+TabPlan 모드 전환
Cmd/Ctrl+K커맨드 팔레트 열기
Ctrl+L화면 클리어
Ctrl+G외부 에디터 열기
Cmd+J (App)통합 터미널 토글
주요 슬래시 커맨드
/planPlan 모드 전환
/model모델·effort 변경
/permissionsapproval 모드 변경
/compact컨텍스트 요약
/diffGit diff 표시
/reviewworking tree 리뷰
/initAGENTS.md 생성
/fork대화 분기
Interactive: Channel Router

이 로그인 문제, 어느 채널에서 처리할까요?

채널을 선택하면 해당 채널에서 무엇을 하기 좋은지와 첫 번째 요청 예시를 볼 수 있습니다.

채널
이 채널에서 하기 좋은 일
이 채널이 유리한 이유
주의
첫 번째 요청 예시 

                    

                

            

        


        

            
CLI vs IDE: 실질적 차이

            
CLI는 불편한 게 아니라 역할이 다릅니다

            

                IDE가 편하다고 느끼는 건 자연스럽습니다. 하지만 CLI를 불편하다고 피하다 보면, 정작 버그 수정과 검증이 가장 안정적으로 이뤄지는 채널을 놓치게 됩니다.
            

            

                

                    CLI가 IDE보다 유리한 상황
                    
    
                        
  • npm test -- auth 같은 검증 명령을 수정 직후 자동 실행합니다.
    • 
                        
  • 파일 수정, lint, 테스트를 한 세션에서 순서대로 처리합니다.
    • 
                        
  • sandbox 설정으로 수정 범위를 더 엄격하게 제한합니다.
    • 
                        
  • 터미널 출력을 바로 컨텍스트로 활용해 다음 단계에 넘깁니다.
    • 
                        
  • CI 파이프라인에서 동일한 명령으로 재현 가능합니다.
    • 
                    

                

                

                    CLI가 불편하다고 느낄 때의 진짜 이유
                    
    
                        
  • 파일 미리보기와 코드 탐색이 IDE보다 느립니다. → 탐색은 IDE에서 먼저 하세요.
    • 
                        
  • 첫 요청 결과를 바로 보기 어렵습니다. → 설명 단계는 IDE, 수정 단계는 CLI로 분리하세요.
    • 
                        
  • approval 확인 창이 자주 뜹니다. → 이건 불편함이 아니라 안전 장치입니다.
    • 
                    

                

            

            

                권장 패턴
                IDE로 원인 파악 → CLI로 수정 + npm test -- auth 검증 → PR로 리뷰 포인트 정리.
                각 채널이 가장 잘하는 일에 집중하면 전체 흐름이 안정됩니다.
            

        


        

            

                
IDE 요청 예시

                
IDE에서 먼저 할 일

                
auth/LoginForm.tsx와 auth/useLogin.ts를 읽고
로그인 실패 시 에러 메시지가 어디서 사라지는지 설명해주세요.
수정은 아직 하지 말고 원인 후보만 정리해주세요.

                

                    
예상 출력 요약

                    
원인 후보:
1. useLogin.ts의 login() 진입 시 setError(null) 호출
   → 로딩 시작과 동시에 에러 state 초기화
2. LoginForm.tsx 렌더링 조건: isLoading이 true면
   에러 영역을 조건부로 숨김

권장 다음 단계: CLI에서 국소 수정

                

            

            

                
CLI 요청 예시

                
CLI에서 이어서 할 일

                
로그인 실패 시 에러 메시지가 사라지는 문제를 수정해주세요.
범위는 auth/LoginForm.tsx, auth/useLogin.ts로 제한합니다.
UI 문구와 API 스펙은 유지하고 npm test -- auth 로 검증해주세요.

                

                    
CLI가 자동으로 실행하는 것

                    
$ npm test -- auth

PASS auth/LoginForm.test.tsx
  ✓ 로그인 실패 시 에러 메시지가 유지됨 (42ms)
  ✓ 로딩 중에도 이전 에러가 표시됨 (18ms)

Tests: 2 passed, 2 total

                

            

        


        

            
Workshop

            
실습

            

                
실습 1
로그인 문제의 각 단계를 설명, 수정, 검증, 리뷰로 나누고 어디에서 처리할지 적어보세요.

                
실습 2
같은 문제를 IDE용 요청과 CLI용 요청으로 각각 다르게 써보세요.

            

        


        

            
References

            
공식 문서

            

                OpenAI Codex IDE Extension
                Codex approvals & security
                Codex GitHub integration