Codex에 테스트를 추가해 달라고 요청했는데 정상 입력 하나만 확인하는 코드가 생길 수 있습니다. 필요한 것은 테스트 파일 수보다 어떤 동작을 보장하려는지입니다. 입력, 기대 결과와 실패 때의 처리를 먼저 정하면 AI가 구현을 그대로 따라 쓴 테스트인지 판단하기도 쉬워집니다.
이 글에서는 가상의 예약 수량 검증 함수를 예로 사용합니다. 제품의 실제 이용 한도나 Codex의 사용량을 설명하는 숫자가 아닙니다. 작성한 요청서와 사례표는 독자가 자기 프로젝트에 맞게 바꾸어 쓰는 예시이며, 이 글에서 해당 프로젝트의 테스트를 실행했다는 의미는 아닙니다.
한눈에 보는 수량 검증의 정상·경계·실패 사례
설명용 도해 — 실제 화면·시험 결과가 아닙니다.
1. 함수의 입력·출력 계약 정의
2. 정상 입력과 기대 결과 작성
3. 경계 안쪽과 바깥쪽 구분
4. 다른 타입·누락·실패 결과 명시
5. 실제 실행 결과와 미실행 항목 분리
1. 테스트 전에 함수의 약속부터 적기
예시 함수 validate_quantity는 정수 1부터 5까지를 허용하고 그 밖의 입력에는 검증 오류를 반환한다고 정하겠습니다. 성공 결과와 오류 결과가 어떤 형식인지는 프로젝트의 실제 계약을 따라야 합니다. 구현을 읽고 나온 결과를 그대로 기대값으로 적는 대신 독자가 원하는 동작을 먼저 정의하는 단계입니다.
이 예시에서는 0, 6, 음수, 소수, 문자열과 누락 입력을 허용하지 않는다고 정합니다. 숫자로 보이는 문자열을 자동 변환할 것인지도 별도 결정입니다. “적절한 수량이면 성공”이라는 표현으로 남기면 Codex가 그 적절함을 추정해야 하므로 허용 범위를 문장과 표로 고정하세요.
OpenAI의 Codex 코드 현대화 예제는 정상 흐름과 경계 사례를 계획하고 각 시나리오의 입력·출력을 정리하는 과정을 보여 줍니다. 공식 프롬프트 안내도 테스트 대상 함수를 지정하고 정상 사례와 경계 사례를 다루도록 요청하는 방법을 설명합니다. 아래 양식은 그 원리를 작은 기능에 적용해 직접 만든 예입니다.
2. 정상 사례는 사용 목적을 대표하도록 고르기
가상의 함수에 3을 넣어 성공 결과를 기대하는 것은 정상 사례입니다. 다만 같은 중간값을 여러 번 다른 이름으로 검사한다고 중요한 조건이 늘어나는 것은 아닙니다. 반환값의 종류, 정규화된 수량과 호출 뒤 필요한 상태처럼 실제 사용자가 의존하는 결과를 확인하도록 정합니다.
함수가 단순 검증만 담당한다면 저장소 변경까지 검사할 이유가 없습니다. 반대로 예약 API의 계약이 성공한 요청을 한 번 저장하는 것이라면 저장된 수량과 응답을 함께 확인할 수 있습니다. 함수 단위 테스트와 API를 통과하는 테스트의 대상 범위를 섞지 않으면 실패 원인을 찾기 쉽습니다.
구분
설명용 입력
계약에 따른 기대
정상 중간값
3
성공, 수량 3 유지
최소 허용값
1
성공
최대 허용값
5
성공
최소보다 작음
0
검증 오류
최대보다 큼
6
검증 오류
타입이 다름
문자열 3, 소수 3.5
변환 없이 검증 오류
표의 결과는 예시 계약을 정했기 때문에 나옵니다. 다른 서비스가 문자열을 허용한다면 그 서비스의 표는 달라져야 합니다. 테스트를 작성하기 전에 계약을 확정하지 않은 부분은 질문 또는 미정 항목으로 남기고, AI가 선택한 결과를 제품 요구사항으로 자동 채택하지 않습니다.
3. 경계에서는 바로 안쪽과 바깥쪽을 함께 보기
최댓값이 5라는 조건을 검사하려면 5의 성공과 6의 실패를 함께 봅니다. 4의 성공만 확인하면 구현이 5도 거부하는 실수를 놓칠 수 있습니다. 최솟값도 1의 성공과 0의 실패를 연결해야 조건의 양쪽이 드러납니다. 경계의 이유를 테스트 이름이나 짧은 설명에 남기세요.
개수 조건과 날짜 조건은 경계의 단위가 다릅니다. 개수는 정수 한 칸을 비교하지만 예약 시각은 시간대, 포함 여부와 입력 정밀도를 정해야 합니다. 날짜 기능에서 “마감 직전”을 검사하려면 어떤 시각을 마감으로 보는지부터 명시합니다. 이 예시 수량표를 모든 시간 조건에 그대로 옮기지는 않습니다.
소수 입력을 거부하는 계약에서는 1.5도 별도 실패 조건입니다. 최솟값 이상이고 최댓값 이하라는 비교만 하면 타입 계약의 위반이 빠질 수 있기 때문입니다. 사용하는 언어가 참·거짓 값과 정수를 어떻게 다루는지도 확인하고, 제품이 불리언을 수량으로 받아들일지 독립적으로 결정하세요.
4. 실패 조건은 오류의 내용과 뒤의 상태를 정하기
입력이 잘못됐을 때 “실패하면 됨”이라고만 쓰기보다 어떤 오류 형식이 필요한지 정합니다. 예외를 던지는 함수인지, 오류 객체를 반환하는 함수인지, API가 특정 응답을 만드는지에 따라 테스트가 달라집니다. 실제 프로젝트의 기존 오류 처리 관례를 읽도록 Codex에 요청하세요.
실패한 입력을 저장하지 않아야 한다는 계약이 있다면 그 조건도 확인합니다. 예를 들어 가상의 예약 API에서는 검증 오류 뒤 예약 개수가 늘어나지 않아야 한다고 정할 수 있습니다. 이 경우 오류 문구만 확인하고 저장 상태를 놓치면 독자가 기대한 결과의 일부만 검사한 셈입니다.
오류 메시지의 문장 전체를 고정할 필요가 있는지도 판단하세요. 사용자에게 반드시 보장할 오류 코드가 있다면 그것을 검사하고, 표시 문구가 자주 바뀌는 제품이라면 문장 전체 비교가 유지보수 부담이 될 수 있습니다. 무엇을 계약으로 정했는지에 따라 검사의 강도를 선택합니다.
5. Codex에 전달할 요청서 만들기
요청에는 함수와 관련 파일, 허용 입력, 기대 결과, 기존 테스트의 위치와 실행 방법을 넣습니다. 파일 경로는 실제 저장소에서 확인한 것으로 바꾸세요. 새로운 테스트 도구 설치가 필요한지까지 추정하게 하기보다 이미 쓰는 도구와 명령을 먼저 읽도록 범위를 정할 수 있습니다.
개념 설명 그림
대상 함수 validate_quantity와 기존 테스트를 읽고 같은 관례로 테스트를 추가해 주세요. 계약은 정수 1~5만 성공이며 문자열 자동 변환은 하지 않는 것입니다. 3, 1, 5의 성공과 0, 6, 음수, 소수, 문자열, 누락 입력의 실패를 구분하세요. 불리언 처리와 오류 형식은 기존 계약을 확인하고 불명확하면 먼저 알려 주세요. 구현을 바꾸어 테스트에 맞추기 전에 계약과 차이를 보고해 주세요. 관련 테스트를 실행하고 명령·결과·실행하지 못한 조건을 적어 주세요.
본문의 핵심 항목을 살펴보는 설명 그림
이 요청서가 모든 프로젝트에 맞는 것은 아닙니다. 실제로 없는 함수명이나 명령을 넣으면 검증이 시작되지 못할 수 있습니다. 함수가 받는 인수와 호출 경로, 기존 의존성의 준비 방법을 함께 확인하고 필요 없는 배포 작업까지 요청 범위에 넣지 않습니다.
6. 구현을 따라 쓰기만 한 테스트 찾아내기
Codex가 만든 테스트를 읽을 때에는 기대값을 어디서 얻었는지 확인합니다. 검사할 함수로 기대값도 계산하면 같은 오류를 두 번 계산해 통과할 수 있습니다. 예시의 허용 범위는 독립적인 계약표에서 가져오고, 출력의 중요한 부분을 직접 확인하도록 해야 합니다.
가상의 잘못된 구현이 5를 거부하도록 바뀌었다고 생각해 보세요. 최대 허용값을 검사하는 테스트가 실패해야 범위 계약을 지키는 검사입니다. 반대로 테스트가 3만 확인한다면 이 실수는 드러나지 않을 수 있습니다. 이런 사고 실험은 무엇을 잡아내는지 점검하는 방법이며 실제 코드를 변경해 시험한 결과는 아닙니다.
모의 객체를 썼다면 무엇을 대신했는지도 읽습니다. 저장소를 대신한 모의 객체는 외부 서버의 실제 저장 여부를 증명하지 않습니다. 함수가 올바른 입력으로 저장 동작을 요청했는지 확인하는 목적과 외부 시스템까지 실제로 작동했는지 확인하는 목적을 나누세요.
7. 실행 결과는 파일 존재와 구분해서 읽기
보고된 상태
확인할 근거
의미
테스트 작성
추가한 코드와 조건표
검사 준비
테스트 발견
실행기가 선택한 테스트 목록
대상 포함 여부
실행 통과
명령·종료 결과·통과 수
실행한 범위의 결과
건너뜀
조건과 건너뛴 항목
미검증 범위
실행 불가
환경 오류와 원인
검증이 남아 있음
명령이 성공 종료했어도 테스트가 하나도 선택되지 않았다면 확인하려던 조건을 검사한 결과가 아닙니다. 필터와 실행 위치, 실제 발견된 테스트 수를 읽으세요. 의존성이 없어 실행이 막힌 경우에는 제품 코드의 실패와 환경 준비 실패를 구분해 보고해야 합니다.
공식 프롬프트 안내는 수정 뒤 관련된 작은 테스트와 검사 명령을 실행하고 결과를 보고하는 방식을 설명합니다. 보고서에 성공이라는 단어만 남기기보다 어떤 명령으로 무엇을 확인했는지 남기면 검토자가 범위를 이해할 수 있습니다. 실행하지 않은 조건은 완료 수에 더하지 않습니다.
8. 실패를 만났을 때 계약·테스트·구현을 함께 대조하기
실패가 나면 실제 입력, 기대값, 나온 값과 계약표를 대조합니다. 테스트가 잘못된 기대를 사용했을 수도 있고 구현이 계약을 어겼을 수도 있습니다. 통과시키기 위해 기대값만 현재 결과로 고치면 원래 의도한 동작이 사라질 수 있으므로 어떤 근거로 바꾸는지 설명해야 합니다.
계약이 바뀌는 제품 결정이라면 그 이유와 영향을 받은 조건을 먼저 기록하고 테스트를 갱신합니다. 단순 구현 오류라면 관련 동작을 수정한 뒤 같은 실패 사례가 해결되는지와 주변 조건이 유지되는지 확인합니다. 기존에 통과하던 검사에서 새 실패가 생기면 그 차이를 함께 살펴봅니다.
마지막 점검은 “정상 사용을 대표하는가, 경계 양쪽을 확인하는가, 실패 결과와 상태를 확인하는가, 실제 실행 범위가 드러나는가”입니다. 독자가 원하는 동작을 계약으로 적고 그 계약을 독립적으로 확인하도록 요청하면 테스트의 목적과 Codex의 작업 결과가 연결됩니다.
