Codex에 기능을 맡기기 전 범위 정하기: 입력·출력·완료 조건 예시

Codex 기능 요청의 완료 기준

STEP 1	사용자 행동 정의
STEP 2	입력 범위 결정
STEP 3	출력 형식 결정
STEP 4	변경 경계 기록
STEP 5	정상·경계·실패 검증

읽는 순서를 정리한 설명 도해입니다. 실제 프로그램 화면이나 측정 결과가 아닙니다.

Codex에 “내 앱에 다운로드 기능을 넣어 줘”라고 요청하면 목표는 전달되지만, 어떤 데이터를 어떤 형식으로 받을지와 어디까지 바꿀지는 남아 있습니다. 이 빈칸이 많으면 결과를 본 뒤 다시 수정해야 할 부분이 늘어납니다. 긴 지시문을 무조건 쓰는 것보다 입력·출력·완료 조건을 구체적으로 정하는 것이 작업을 맡길 때 도움이 됩니다.

이 글은 간단한 CSV 내보내기 기능을 가상 예시로 사용해 요청 범위를 정리하는 방법을 설명합니다. 실제 프로젝트를 수정하거나 프로그램을 실행한 기록이 아닙니다. 예시의 파일명과 화면 이름은 설명용이며, 자신의 코드 구조와 요구에 맞춰 바꿔 사용해야 합니다.

1. 작업 목표를 사용자의 행동으로 표현하기

“내보내기 구현” 대신 “사용자가 목록 화면에서 현재 조회 결과를 CSV 파일로 받을 수 있게 한다”처럼 적습니다. 결과를 사용할 사람과 행동이 들어가면 구현의 목적이 분명해집니다. 내부 코드 구조를 먼저 지정하기보다 사용자가 해야 할 일을 설명하고, 이미 정해진 구조가 있다면 관련 파일과 기존 동작을 추가로 알려 주세요.

OpenAI의 공식 프롬프트 안내는 목표, 문맥, 출력, 경계를 필요한 만큼 제공하도록 설명하며, Codex 요청에는 원하는 동작과 관련 코드 또는 재현 단계, 중요한 제약과 검증 방법을 포함하도록 안내합니다. 이 글의 요청 양식은 그 원칙을 CSV 예시에 적용한 것입니다. 고정된 주문이나 특별한 키워드를 반드시 넣어야 하는 양식은 아닙니다.

목표를 정할 때 기능이 필요한 이유도 한 문장으로 적습니다. 예를 들어 “운영 담당자가 조회 결과를 다른 표로 검토하려고 한다”는 설명이 있으면 열 이름과 날짜 표시가 왜 중요한지 드러납니다. 다만 이유만 주고 결과 형식을 생략하면 검토 기준은 남지 않습니다. 목적과 실제 출력 조건을 함께 정해야 합니다.

2. 입력 범위를 먼저 정하기

CSV 기능의 입력은 전체 데이터인지, 현재 필터 결과인지, 화면에 보이는 한 페이지인지 결정합니다. 이 세 가지는 결과가 크게 다릅니다. 사용자가 “조회 결과”라고 생각하는 범위를 문장으로 정하고, 정렬과 필터를 반영할지도 적습니다. 화면에서는 20개만 보이는데 1,000개를 내려받게 할지 여부를 Codex가 임의로 추정하게 두지 않는 것이 좋습니다.

가상 요구사항을 “현재 선택한 검색 조건을 반영한 결과 전체, 현재 정렬 순서 유지”로 정해 보겠습니다. 이 경우 데이터가 페이지별로 불러와지는 구조라면 화면의 배열만 복사하는 구현으로 충분하지 않을 수 있습니다. 관련 데이터 요청과 페이지 처리 방식도 확인해야 하므로, Codex에 기존 조회 경로를 조사하고 변경 범위를 제안하도록 요청할 수 있습니다.

입력의 예외도 적습니다. 결과가 비어 있을 때 빈 파일을 만들지, 열 제목만 만들지, 안내를 보여 줄지 정합니다. 선택한 항목만 내보내는 기능이라면 선택 항목이 0개일 때 동작도 필요합니다. 이러한 조건을 미리 적어 두면 개발 후 “이 경우에는 어떻게 되지?”라고 다시 질문하는 일을 줄일 수 있습니다.

요구 항목	가상 예시	명확하지 않으면 생기는 문제
대상 데이터	필터에 맞는 결과 전체	한 페이지와 전체 결과 혼동
순서	현재 선택한 정렬 유지	화면과 파일의 순서 차이
열	이름·상태·생성일	필요 없는 내부 식별 정보 포함
빈 결과	안내를 표시하고 파일 생성 안 함	빈 파일이 오류로 보임
시점	내보내기 요청 시점의 조회 조건	필터 변경 중 결과가 섞임

3. 출력 형식은 독자가 확인할 수준으로 정하기

출력 파일명, 문자 인코딩, 열 이름과 순서, 날짜 형식, 빈값 표시를 정합니다. CSV에는 쉼표, 따옴표, 줄바꿈이 포함된 값이 있을 수 있으므로 단순한 문자열 연결만으로 모든 값을 올바르게 저장한다고 가정하지 않습니다. 어떤 프로그램에서 파일을 열지 알려 주면 호환성을 확인할 기준을 마련할 수 있습니다.

가상 출력 조건은 “첫 행에 한국어 열 이름, 날짜는 YYYY-MM-DD, 없는 값은 빈칸, 쉼표·따옴표·줄바꿈을 포함한 값 보존”처럼 적을 수 있습니다. 이러한 내용은 검증 가능한 조건입니다. 특정 라이브러리를 꼭 써야 한다는 제약이 없다면 기존 프로젝트의 방식과 의존성 정책을 조사한 뒤 구현을 선택하도록 맡기는 것이 자연스럽습니다.

파일에서 숫자처럼 보이는 식별자는 주의해서 다룹니다. “0012” 같은 코드가 숫자로 변환되어 앞의 0을 잃지 않도록 요구사항을 정합니다. CSV를 연 프로그램의 자동 해석도 결과에 영향을 줄 수 있으므로, 파일의 원래 문자열과 프로그램이 표시한 결과를 구분해 확인해야 합니다. 실제 필요한 식별자 보존 방법은 사용하는 프로그램과 형식에 맞춰 결정합니다.

4. 바꿀 곳과 유지할 곳을 따로 기록하기

변경 범위는 관련 화면, 데이터 처리, 내보내기 함수처럼 기능에 필요한 부분으로 정합니다. 유지해야 할 것은 기존 조회 동작, 화면 디자인의 큰 구조, 다른 파일 형식, 접근 권한 등으로 구체적으로 적습니다. “기존 기능을 유지”라는 표현만으로는 어떤 동작이 중요한지 충분히 전달되지 않을 수 있습니다.

가상 요청에서 “목록의 검색·정렬·페이지 이동 동작은 유지하고, CSV 버튼과 필요한 내보내기 처리만 추가한다”라고 적으면 변경을 검토할 기준이 생깁니다. 성능이나 권한에 영향을 주는 서버 변경이 필요하다면 해당 변경의 이유와 범위를 확인하도록 요청할 수 있습니다. 기존 파일이 있다는 사실과 기존 요구사항을 만족한다는 사실은 다르므로 실제 코드 문맥을 조사해야 합니다.

공동 작업 중인 프로젝트라면 이미 수정 중인 파일과 담당 범위를 알려 줍니다. Codex가 다른 사람이 만든 변경을 원래대로 돌리지 않도록 현재 작업 상태를 확인하고 필요한 부분만 수정하도록 요청하세요. 하나의 기능을 맡겼다는 이유로 관련 없는 정리, 전체 형식 변경, 의존성 업데이트까지 동시에 수행해야 하는 것은 아닙니다.

5. 완료 조건을 정상·경계·실패 사례로 나누기

정상 사례는 예상대로 처리되는 입력입니다. 경계 사례는 빈 결과, 하나의 항목, 큰 결과 묶음, 특수 문자가 있는 값처럼 범위의 끝에 가까운 상황입니다. 실패 사례는 데이터 요청 실패나 파일 생성 실패 등입니다. 테스트를 많이 쓰는 것보다 사용자의 기능이 실제로 깨질 수 있는 조건을 고르는 것이 중요합니다.

CSV 예시에서는 “필터 결과와 파일 행이 일치한다”, “쉼표와 줄바꿈이 포함된 이름이 보존된다”, “빈 결과에 정해 둔 안내가 나온다”, “기존 목록의 검색이 유지된다”를 확인할 수 있습니다. 네 조건은 결과를 눈으로 검토하거나 관련 테스트로 확인할 수 있습니다. 테스트 파일이 생겼다는 것만으로 이 조건이 모두 확인되었다고 결론 내리지 않습니다.

실행 가능한 환경인지도 점검합니다. 테스트 명령과 필요한 의존성을 Codex가 확인하도록 하고, 실제 실행한 명령과 결과를 보고하도록 요청합니다. 환경 제한으로 실행하지 못한 검증은 미실행으로 표시해야 합니다. 코드만 읽고 추론한 내용, 테스트를 실행한 내용, 실제 화면에서 확인한 내용을 분리하면 결과의 신뢰 범위를 알 수 있습니다.

검증 종류	가상 입력	완료 판단
정상	일반 텍스트 항목 여러 개	열과 행이 요구조건에 일치
경계	빈 결과·한 항목	사전에 정한 안내와 출력
특수값	쉼표·따옴표·줄바꿈·앞자리 0	값이 손실되거나 행이 분리되지 않음
실패	조회 요청 실패	혼동되는 파일 대신 명확한 상태 안내
회귀	기존 검색·정렬·페이지 이동	원래 동작이 유지되는지 확인

6. 바로 수정해서 쓰는 요청 예시

설명용 요청 문장은 다음과 같습니다. “목록 화면에 CSV 내보내기를 추가해 줘. 현재 필터의 결과 전체를 현재 정렬 순서로 내보낸다. 열은 이름·상태·생성일이고, 빈 결과는 안내만 보여 준다. 쉼표·따옴표·줄바꿈이 있는 값과 식별자의 앞자리 0을 보존한다. 기존 검색과 페이지 이동은 유지한다. 관련 코드부터 확인하고, 필요한 변경과 검증을 수행한 뒤 실제 확인 결과를 알려 줘.”

실제 프로젝트에서는 관련 화면이나 파일 경로, 이용하는 데이터 구조, 이미 정해진 테스트 명령을 추가합니다. 모르는 경로를 만들어 적을 필요는 없습니다. “관련 경로를 찾아 구조를 설명한 뒤 변경해 줘”처럼 조사를 맡길 수 있습니다. 출력은 변경 이유, 핵심 파일, 검증 결과와 남은 제한을 짧게 보고하도록 요청하면 검토가 쉽습니다.

요청 후 새로운 조건이 생기면 기존 조건과 함께 유지되는지 알려 줍니다. “파일 이름에 날짜를 넣어 줘”라는 추가 요구는 앞서 정한 열, 빈 결과, 특수값 보존 조건을 대체하는 것이 아닙니다. 반대로 요구를 바꾸는 경우에는 어떤 조건을 폐기하는지 명확히 말해야 합니다. 작은 수정이 누적될수록 최종 기준을 한곳에 정리해 두는 편이 좋습니다.

7. 결과를 받을 때 확인할 점

변경 설명이 요구한 동작과 연결되는지 확인합니다. 구현이 전체 데이터를 내보낸다고 주장하면 실제로 페이지를 넘어선 결과를 처리하는지, 정렬 조건을 어디서 보존하는지 살펴볼 수 있습니다. 모든 내부 코드를 이해할 필요는 없지만 요구사항별로 확인 위치와 검증 결과가 연결되어 있어야 합니다.

작업 전과 후에 중요한 예시를 같은 조건으로 비교하면 도움이 됩니다. 가상 CSV를 열어 행 수와 열 순서를 확인하고 특수값을 읽습니다. 실제 데이터로 검증할 때는 공개되면 안 되는 정보를 시험 파일에 넣지 않도록 자료를 고릅니다. 검토가 끝나면 요청의 완료 조건 중 충족한 항목과 남은 항목을 구분하여 다음 수정을 결정하세요.

좋은 요청은 긴 문장을 쓰는 경쟁이 아닙니다. 입력의 범위, 결과의 형태, 보존할 동작, 확인할 사례가 서로 연결되면 작업을 맡기고 결과를 검토하기가 쉬워집니다. Codex가 실제 프로젝트를 조사할 여지를 남기면서 독자가 필요한 결과를 구체적으로 정하는 것이 핵심입니다.

공식 자료와 확인 범위

• OpenAI: Prompting Codex
• OpenAI: Codex Cloud

자료 확인일: 2026년 10월 5일. AI가 공식 자료를 확인하여 작성했습니다. 본문의 가상 사례와 계산 예시는 실제 사용자 기록이나 실험 결과가 아닙니다. 서비스 조건·메뉴 및 공개 자료는 변경될 수 있으며, 필요한 조건은 현재 공식 안내에서 확인합니다.