2
Codex 사용법 2강. Context 설계
Lesson 02

좋은 결과는 좋은 문장보다
좋은 Context에서 나옵니다.

입문자가 흔히 빠지는 오해는 Prompt를 더 예쁘게 쓰면 된다는 생각입니다. 실제로는 무엇을 해야 하는지, 어디까지 바꿔도 되는지, 무엇으로 검증할지가 먼저 고정되어야 합니다.

기준 날짜 2026-04-13

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

이번 강의 핵심 문장 좋은 결과는 좋은 문장보다, 좋은 Context에서 나옵니다.
공통 예시 — 로그인 에러 메시지 사라지는 문제 (펼치기)
문제: 로그인 실패 시 에러 메시지가 화면에서 사라집니다.
범위: auth/LoginForm.tsx, auth/useLogin.ts, auth/LoginForm.test.tsx
제약: UI 문구 유지, API 스펙 유지, auth 범위 안에서만 수정, npm test -- auth로 검증합니다.
Prompt vs Context

Prompt만 다듬어서는 부족합니다

막연한 요청
“이거 좀 고쳐줘.”
  • 무엇이 문제인지 빠져 있습니다.
  • 수정 범위가 없습니다.
  • 검증 명령이 없습니다.
  • 완료 조건이 없습니다.
Better Context

필요한 재료를 구조적으로 줍니다

구조화된 요청
목표, 범위, 금지사항, 검증 명령, 완료 조건을 함께 적으면 결과와 리뷰가 모두 안정적입니다.
  • 무엇을 바꿀지 분명합니다.
  • 어디까지 바꿔도 되는지 보입니다.
  • 테스트와 리뷰 기준이 생깁니다.
  • 같은 요청을 다시 쓰기도 쉬워집니다.
Minimal Structure

좋은 요청의 최소 구조

목표로그인 실패 시 에러 메시지가 사라지는 문제를 수정합니다.
수정 범위auth/LoginForm.tsx, auth/useLogin.ts 안에서만 수정합니다.
금지사항UI 문구, API 스펙, auth 밖의 코드는 건드리지 않습니다.
검증 명령npm test -- auth를 실행합니다.
완료 조건실패 시 메시지가 유지되고 관련 테스트가 통과해야 합니다.
참고 파일auth/LoginForm.test.tsx의 기대 동작을 같이 확인합니다.
Bad Request

나쁜 요청

로그인 쪽 이상한 것 같은데 고쳐줘.

이 요청은 어디가 문제인지, 어디까지 바꿔도 되는지, 무엇으로 검증할지가 빠져 있습니다.

Good Request

좋은 요청

로그인 실패 시 에러 메시지가 화면에서 사라지는 문제를 수정해주세요.

수정 범위는 auth/LoginForm.tsx, auth/useLogin.ts로 제한합니다.
UI 문구와 API 스펙은 유지하고 auth 바깥 코드는 건드리지 마세요.
관련 테스트는 auth/LoginForm.test.tsx를 기준으로 확인하고
npm test -- auth 로 검증해주세요.

완료 조건은 로그인 실패 시 에러 메시지가 유지되고,
관련 테스트가 통과하는 것입니다.
Team Context

개인 요청에서 Team Context로 넘어가야 하는 이유

지금 단계에서는 좋은 요청을 직접 쓰는 연습이 먼저입니다. 다만 같은 설명을 여러 번 반복하기 시작하면 개인 Prompt만으로는 한계가 생깁니다. 그때부터는 Team Context가 필요합니다.

AGENTS.md팀의 공통 규칙과 build, lint, test, 리뷰 기준을 모아둡니다. 5강에서 다룹니다.
Skill반복 요청을 재사용 가능한 workflow로 구조화합니다. 6강에서 다룹니다.
Subagent긴 작업이나 병렬 작업을 나눠 처리하는 고급 운영 패턴입니다. 8강에서 다룹니다.
Context Management

컨텍스트가 길어지면 어떻게 하나요

대화가 길어질수록 관련 없는 내용이 쌓여 응답 품질이 떨어집니다. 핵심은 같은 피처 안에서는 /compact, 피처가 바뀌면 /clear입니다.

/compact — 요약하고 이어가기

같은 피처 안에서 대화가 길어질 때

  • auth 버그 수정 중 요청이 10회를 넘길 때
  • 이전 맥락(범위·제약·수정 이력)을 유지해야 할 때
  • 토큰은 줄이되 흐름은 끊기면 안 될 때
/compact
→ 이전 대화를 요약해 토큰을 확보하되
  범위·제약·수정 이력은 유지됩니다.
/clear — 완전히 새로 시작

피처가 바뀌거나 작업이 끝났을 때

  • auth 버그가 끝나고 다른 기능으로 넘어갈 때
  • 이전 대화가 새 작업에 오히려 방해가 될 때
  • 처음부터 깨끗한 컨텍스트가 필요할 때
/clear  또는  /new
→ 컨텍스트를 완전히 비우고
  새 스레드로 시작합니다.
/status현재 토큰 사용량과 세션 설정을 확인합니다. 컨텍스트가 얼마나 쌓였는지 볼 때 씁니다.
/fork현재 대화를 새 스레드로 복제합니다. 다른 접근을 시도하면서 원래 대화도 남기고 싶을 때 씁니다.
/resume이전에 저장된 세션을 다시 엽니다. 어제 하던 작업을 이어갈 때 씁니다.
원칙 — 피처 단위로 스레드를 끊으세요 로그인 버그 = 하나의 스레드. 버그가 끝나면 /clear로 새 스레드를 시작하세요. 같은 스레드에 무관한 작업을 쌓으면 이전 피처의 범위·제약이 새 작업에 간섭합니다.
Token & Quality Impact

관리 전략에 따라 토큰과 품질이 이렇게 달라집니다

방치하면 토큰이 기하급수로 쌓이고, /compact만 쓰면 줄어들지만 한계가 있습니다. 피처 단위로 /clear를 병행하면 가장 효율적입니다.

Quality Degradation

컨텍스트를 방치하면 응답 품질이 내려갑니다

요청이 쌓일수록 초반에 설정한 범위·제약이 희석됩니다. 피처 전환 시 /clear하면 품질이 다시 최고점으로 복원됩니다.

Interactive: Context Builder

어떤 컨텍스트를 포함하면 요청이 달라질까요?

항목을 켜고 끄면서 요청 구조가 어떻게 변하는지 직접 확인해보세요.

현재 요청 구조 

                    

                    

                        빠진 항목
                        
                    

                    

                        
                    

                

            

        


        

            
Context Quality

            
막연한 요청 vs. 컨텍스트 설계된 요청

            
같은 로그인 버그를 맡겨도 어떻게 요청하느냐에 따라 결과 품질이 크게 달라집니다.

            

                
            

        


        

            
Workshop

            
실습

            

                
실습 1
위의 나쁜 요청을 보고, 무엇이 빠져 있는지 항목별로 체크해보세요.

                
실습 2
로그인 에러 메시지 문제를 기준으로, 목표, 범위, 금지사항, 검증 명령, 완료 조건을 직접 적어보세요.

            

        


        

            
References

            
공식 문서

            

                Prompt engineering
                Codex approvals & security
                OpenAI Codex IDE Extension