1
Codex 사용법 1강. 작업 관점 잡기
Lesson 01

Codex는 코드 생성기가 아니라
작업 파트너에 가깝습니다.

AI 코딩 입문자가 가장 먼저 버려야 할 생각은 “코드를 대신 쳐주는 도구”라는 인식입니다. Codex는 작업을 받아 초안을 만들고, 사람이 범위를 잡고, 검증 명령으로 확인하는 흐름에서 가장 잘 작동합니다.

기준 날짜 2026-04-13

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

이번 강의 핵심 문장 AI 코딩의 핵심은 많이 생성하는 것이 아니라, 제대로 맡기고 제대로 검토하는 것입니다.
공통 예시 문제: 로그인 실패 시 에러 메시지가 화면에서 사라집니다.
범위: auth/LoginForm.tsx, auth/useLogin.ts, auth/LoginForm.test.tsx
제약: UI 문구 유지, API 스펙 유지, auth 범위 안에서만 수정, npm test -- auth로 검증합니다.
auth/useLogin.ts — 버그 있는 상태
// 문제: 에러 상태가 setLoading(true) 시점에 초기화됨
export function useLogin() {
  const [error, setError] = useState<string | null>(null);
  const [isLoading, setIsLoading] = useState(false);

  const login = async (email: string, password: string) => {
    setError(null);      // ← 여기서 지워짐
    setIsLoading(true);  // ← 화면이 다시 그려지면서 에러가 사라짐
    try {
      await authApi.login(email, password);
    } catch (err) {
      setError('로그인에 실패했습니다.');
    } finally {
      setIsLoading(false);
    }
  };

  return { login, error, isLoading };
}
Core Messages

먼저 고정하면 좋은 다섯 문장

사람이 더 명확해야 합니다AI에게 맡길수록 작업 범위와 목표는 사람이 더 또렷하게 정리해야 합니다.
테스트 없는 AI 코딩은 위험합니다검증 명령이 없으면 결과가 맞는지 빠르게 확인하기 어렵습니다.
좋은 개발자는 틀릴 지점을 먼저 봅니다AI가 잘할 일과 잘못 건드릴 수 있는 범위를 미리 구분하는 것이 중요합니다.
반복되는 요청은 구조화해야 합니다같은 설명을 계속 반복하지 않도록 나중에 AGENTS.md와 Skill로 올리는 편이 좋습니다.
최종 책임은 사람에게 있습니다리뷰, merge, 배포 책임은 여전히 사람이 갖고 가야 합니다.
Good First Tasks

입문자가 먼저 맡기기 좋은 작업

  • 현재 로그인 흐름을 설명하게 합니다.
  • 에러 메시지가 사라지는 원인을 추정하게 합니다.
  • auth 범위 안에서만 국소 수정하게 합니다.
  • 관련 테스트를 추가하거나 보강하게 합니다.
Avoid For Now

처음부터 크게 맡기면 어려운 작업

  • 로그인 UX 전체를 다시 설계해 달라고 한 번에 요청합니다.
  • 검증 명령 없이 “전반적으로 더 좋게” 바꿔 달라고 요청합니다.
  • auth 밖의 API, 디자인 시스템, 배포 설정까지 함께 건드리게 합니다.
  • 민감정보나 실제 운영 데이터가 섞인 작업을 바로 넘깁니다.
Working Flow

처음에는 이 흐름으로 가는 편이 가장 안정적입니다

1
설명 먼저 원인 파악, 흐름 이해부터 시작합니다
2
작은 수정 auth 범위 안에서만 UI·API 스펙 유지 조건으로 수정합니다
3
테스트 추가 npm test -- auth 기준으로 회귀 여부를 확인합니다
4
결과 리뷰 사람이 diff와 테스트 결과를 보고 merge 여부를 결정합니다
1. 설명 먼저현재 로그인 실패 흐름과 에러 상태가 어디서 사라지는지 먼저 설명하게 합니다.
2. 작은 수정UI 문구와 API 스펙은 유지한 채, auth 범위 안에서만 수정하게 합니다.
3. 테스트 추가npm test -- auth 기준으로 회귀 여부를 확인하게 합니다.
4. 결과 리뷰사람이 diff와 테스트 결과를 보고 merge 여부를 결정합니다.
Works Well

잘 되는 방식

범위를 고정합니다
auth 범위만 수정하고, UI 문구와 API 스펙은 유지하도록 명확히 적습니다.
검증 명령을 함께 줍니다
npm test -- auth 같은 검증 기준을 함께 주면 결과 리뷰가 쉬워집니다.
Fails Easily

실패하기 쉬운 방식

범위를 넓게 둡니다
“로그인 경험을 전반적으로 고쳐줘”처럼 크고 모호한 요청은 실패하기 쉽습니다.
검증 없이 믿습니다
결과 설명만 보고 merge하면 회귀나 범위 초과 수정이 숨어 있을 수 있습니다.
Interactive: Task Router

이 로그인 문제, 어떤 순서로 접근할까요?

단계를 선택하면 어느 채널에서 어떤 요청을 하면 좋은지 볼 수 있습니다.

단계
추천 채널
이 채널을 쓰는 이유
주의
첫 번째 요청 예시

                    
Workshop

실습

실습 1

로그인 에러 메시지가 사라지는 문제를 보고, 왜 이 문제가 입문자가 맡기기 좋은 작업인지 적어보세요.

실습 2

설명 먼저 → 작은 수정 → 테스트 추가 흐름으로 Codex에게 어떤 순서로 요청할지 정리해보세요.

References

공식 문서