요구를 쓰는 기술 - 입력·출력·완료 조건

이 장에서 배우는 것

모호한 기능 요청을 검증 가능한 명세로 바꾸고 작업 계획·제외 범위·실패 조건을 연결한다.

짧은 요청보다 빠진 결정을 찾는다

대출 CSV를 보기 좋게 정리해 달라는 요청에는 결정되지 않은 부분이 많다. 첫 행이 제목인지, 금액 같은 숫자에 빈칸이 있으면 어떻게 하는지, 행 순서를 유지하는지, 결과 파일을 덮어쓰는지 알 수 없다. 요청이 길어져야만 좋은 것은 아니다. 결과를 바꾸는 결정을 골라 명시하는 것이 목적이다.

이 장의 명세는 입력, 출력, 완료 조건, 제외 범위 네 칸으로 구성한다. 입력은 UTF-8의 가상 CSV이고 열은 book_id와 days다. 출력은 유효 행 수와 days의 평균이며 유효 행이 없으면 평균 없음으로 표시한다. 음수·빈 값·숫자가 아닌 days는 오류로 거부한다. 파일을 덮어쓰거나 네트워크로 보내는 기능은 제외한다.

계획은 빠진 연결을 발견하는 기회다

수정 전에 어떤 파일을 읽고 무엇을 바꾸며 어떤 검사를 실행할지 계획을 받는다. 이는 모든 작업에 긴 문서를 먼저 만들라는 규칙이 아니다. 작은 변경의 경우 세 줄로도 충분하다. 계획이 명세와 연결되는지 확인하면 그럴듯하지만 다른 문제를 푸는 작업을 일찍 발견할 수 있다.

예를 들어 계획에 잘못된 숫자는 0으로 바꾼다고 적혔다면 명세와 충돌한다. 이때 코드를 끝까지 만든 뒤 고치기보다 오류 처리 규칙부터 바로잡는다. 계획을 읽었다는 사실이 결과 검증을 대신하지는 않는다. 구현 중 새로운 제약이 발견되면 변경한 결정과 이유를 계획 옆에 남긴다.

상시 규칙과 이번 요구를 나누기

프로젝트 지침에는 반복해서 필요한 실행 명령·인코딩·데이터 취급 규칙을 둔다. 이번 요청에는 새 출력 문구나 새 옵션 같은 변경 내용을 둔다. 특정 버그의 임시 맥락을 전역 지침에 계속 쌓으면 다음 작업에서 관계없는 규칙이 끼어들 수 있다. 완료된 요구는 작업 기록으로 남기고 상시 규칙의 필요성을 다시 판단한다.

이 네 칸 형식은 교재의 편집 제안이며 성공률을 높이는 비율을 주장하지 않는다. 다른 팀의 양식도 입력과 기대 동작을 재현할 수 있다면 쓸 수 있다. 기준은 양식 이름이 아니라 다른 사람이 같은 사례를 실행해 같은 판정을 내릴 수 있는가다.

요청문 예시

다음 예시는 실행 프로그램이 아니라 작업 계약이다. 팀의 실제 입력 형식에 맞춰 빈 필드와 오류 처리 규칙을 고정한다.

입력: UTF-8 CSV, book_id·days 열
출력: 유효 행 수·평균. 행이 없으면 평균 없음
완료: days=0 허용, -1·빈값·abc 거부, 빈 CSV 건수 0
제외: 파일 덮어쓰기·외부 전송
계획: 읽을 파일·변경할 함수·검사 사례를 먼저 설명

직접 해 보기

연체 일수 평균을 추가해 달라는 문장을 네 칸 명세로 고친다. days=0, days=-1, 빈 CSV, days=abc의 기대 결과를 각각 적고 파일을 덮어쓰지 않는 조건을 포함한다.

해설과 확인 기준

0은 음수가 아니므로 유효하고, -1과 abc는 오류다. 빈 CSV에서는 건수 0·평균 없음이다. 값이 하나도 없는데 평균 0이라고 표시하면 실제 평균이 0인 경우와 구분되지 않는다. 오류 행을 조용히 버리는 구현도 이번 명세와 다르므로 거부하거나 명세 변경을 먼저 합의한다.

근거와 기준일

제품·자료 확인일: 2026-11-08. 설명 틀·대출 도구·연습·해설은 교재의 자체 구성이다. 제품별 세부 조건은 아래 공식 문서에서 해당 실행 방식과 계정 범위를 다시 확인한다.

• Codex 프로젝트 지침
• Kiro Steering