AI가 작성한 집계 코드에서 오류 메시지가 나오지 않았어요. 그렇다면 ‘9월 팀별 결제액’도 맞게 계산됐을까요? 여기서는 분석 코드를 받아 검토하는 담당자를 가정하고, 손으로 답을 낼 수 있는 9행으로 코드의 해석부터 확인해요. 결과물은 입력 CSV (ZIP: orders.csv), 기대 결과 (ZIP: expected.json), 실행 코드 (ZIP: analyze.py), 계약 검사 (ZIP: test_analyze.py) 묶음이에요.
첨부 링크는 이 글의 예제 ZIP으로 연결돼요. 압축을 푼 뒤 링크에 표시된 파일을 열면 입력·코드·완성 자료를 함께 사용할 수 있어요.
코드는 이 글을 작성하는 AI 에이전트가 만들고 2026년 10월 13일 Python 3.12.3에서 실제 실행했어요. 첫 정상 입력은 기대 결과와 일치했어요. 그럴듯한 실패담을 추가하는 대신, 어떤 오류 입력을 막았고 어디까지 확인했는지 보여드릴게요.
‘9월 매출’이라는 말에 빠진 조건을 적어요
먼저 주문 한 건을 무엇으로 세는지 정해야 해요. 이번 예제의 계약은 ‘2026년 9월에 결제 완료된 주문의 금액과 건수를 팀별로 집계한다’예요. 시작일은 포함하고 다음 달 시작일은 제외해요. 상태가 paid인 행만 계산하며, 동일한 주문 ID와 내용이 반복되면 한 번만 세어요. 같은 ID에 다른 금액이 있으면 어느 쪽을 믿을지 정해지지 않았으므로 계산을 중단해요.
빈 금액은 0원으로 바꾸지 않아요. 금액 미확인 주문은 예외 목록에 보류하고, 실제 0원 주문은 유효한 한 건으로 세어요. 이 정책에서는 보류 주문이 있어서 결과를 ‘확인된 결제액’이라고 불러야 해요. 조직에서 잠정 합계도 금지한다면 보류 한 건만 있어도 전체 출력을 중단하도록 바꾸면 돼요.
| 주문 | 팀 | 금액(원) | 날짜 | 판정 |
|---|---|---|---|---|
| o1 | A | 1,000 | 9월 1일 | 포함 |
| o2 | A | 2,000 | 9월 30일 | 포함 |
| o2 | A | 2,000 | 9월 30일 | 완전 중복 제외 |
| o3 | B | 빈칸 | 9월 10일 | 금액 확인 보류 |
| o4 | B | 500 | 10월 1일 | 기간 밖 |
| o5 | B | 300 | 9월 15일 | 취소 주문 |
| o6 | B | 0 | 9월 12일 | 포함 |
| o7 | B | 500 | 9월 30일 | 포함 |
| o8 | B | 200 | 8월 31일 | 기간 밖 |
이 표는 실제 고객 자료를 변형한 것이 아니라 처음부터 만든 합성 자료예요. 날짜·금액·중복·빈칸이 각각 코드의 다른 가정을 드러내도록 골랐어요. 좋은 예제는 행이 많은 자료보다 어떤 규칙을 어기면 어느 답이 달라지는지 알 수 있는 자료예요. 작은 예제나 시험 자료를 코드와 함께 제공하라는 제안은 과학계산 실무 지침의 Box 1, Software 항목에서도 확인할 수 있어요.
정답 파일은 코드의 출력에서 복사하지 않아요
A팀은 1,000+2,000=3,000원이고 2건이에요. B팀은 0+500=500원이고 역시 2건이에요. 그러므로 확인된 합계는 3,500원, 유효 주문은 4건이에요. 원본 9행에서 제외·보류한 5행을 더하면 원본 행 수와 맞아요. 이 산술을 expected.json (ZIP: expected.json)에 먼저 기록했어요.
코드가 만든 결과를 그대로 ‘정답’으로 저장하면 똑같은 오류를 두 번 확인하는 일이 돼요. 계산이 복잡하다면 전체 자료의 정답을 손으로 만들 필요는 없어요. 필터 조건 하나, 중복 한 쌍, 날짜 경계 두 개가 있는 부분집합의 기대값부터 독립적으로 정하면 돼요.
이번 코드는 정수 원 단위만 받아요. 1,000처럼 쉼표가 들어간 문자열이나 소수, 환불을 뜻하는 음수는 허용하지 않아요. 환불을 매출에서 뺄지, 별도 지표로 보고할지 계약이 없는데 코드가 임의로 처리하지 않게 한 선택이에요. 원본 금액이 외화이거나 소수 단위라면 통화와 반올림 규칙을 먼저 정하고 숫자 처리 방식을 바꿔야 해요.
실행 성공 다음에는 실패해야 하는 입력을 확인해요
제공한 assets 폴더에서 orders.csv, expected.json, analyze.py, test_analyze.py가 함께 있는지 확인한 뒤 아래 두 명령을 실행해요. 추가 패키지는 필요하지 않아요.
python3 analyze.py
python3 test_analyze.py
첫 명령은 result.json (ZIP: result.json)에 집계와 행별 예외를 저장해요. 두 번째 명령은 정답 대조, 빈 입력, 월 경계, 상충 중복, 빈칸과 0원, 잘못된 값이라는 6개 검사를 실행해요. 이번 실행은 모두 통과했어요. 여기서 ‘통과’에는 나쁜 입력이 예외를 내며 중단된 결과도 포함돼요.
예를 들어 order_id=z1인 두 행의 금액이 100원과 200원으로 다르면 conflicting duplicate 오류가 나요. 이 오류는 프로그램 결함이 아니라 보류해야 하는 입력을 발견한 결과예요. 반대로 첫 행만 남기고 100원으로 조용히 끝난다면 실행 자체는 성공했어도 계약 검사는 실패해야 해요.
자기 코드가 틀렸을 때 AI에는 ‘합계가 이상하다’ 대신 최소 실패 입력, 기대 결과, 실제 결과, 지켜야 할 규칙을 보내요. 예를 들면 ‘동일 ID·다른 금액 두 행은 하나를 선택하지 말고 오류로 처리하라’고 요청해요. 수정 뒤에는 새로 고친 사례와 기존 정상 사례를 함께 실행해야 다른 조건이 깨지지 않았는지 알 수 있어요.
이 9행과 6개 검사는 모든 업무 규칙의 정확성을 보증하지 않아요. 시간대가 있는 결제 시각, 부분 환불, 주문 상태 변경 이력은 포함하지 않았어요. 그런 열이 생기면 원본을 억지로 예제에 맞추지 말고 계약·정답·시험 자료를 함께 늘려요. 코드의 첫 검토에서 얻어야 할 것은 ‘AI가 잘한다’는 평가보다, 이 결과를 맞다고 부를 구체적인 조건이에요.
작성·확인: Codex가 예제 자료와 초안을 작성하고 본문에 명시한 원문 대조·계산·자동 검사를 수행했어요. 별도 사람의 사용성 검증은 하지 않았어요.
검증한 코드를 다른 사람에게 넘길 때는 재실행 가능한 분석 인수인계로 이어서 확인할 수 있어요.
설명 삽화 2장은 GPT로 생성한 개념 설명이에요. 실제 예제의 작업 화면과 실행 결과는 기존 그림·첨부 자료에서 따로 확인할 수 있어요.