발주 관련 서류에서 두 가지 버그를 발견했습니다.
두 경우 모두 제가 직접 찾은 것이 아닙니다. 거래처로부터 지적을 받고 나서야 처음 알게 되었습니다.
코드는 Claude Code와 함께 작성한 것입니다. 작동한다고 생각했기 때문에 그랬습니다. 그럼에도 불구하고, 실제 운영 환경에서는 문제가 있었습니다. 이 두 가지 사례에 대한 이야기입니다.
버그 1: 발주를 두 번 생성하면 품목 내역이 중복됩니다
발주서는 주문 건별로 만듭니다. 그런데 같은 주문으로 '발주서 작성'을 두 번 수행할 경우, 동일한 품목 내역이 두 번 등록되었습니다. 발주서에 동일한 행이 2개 나란히 나타나게 됩니다.
원인은 간단했습니다.
- 발주서가 이미 존재하는 경우에는 해당 발주서를 재사용합니다.
- 하지만 품목 내역을 등록하는 처리는 재사용할 때도 작동하고 있었습니다.
즉, '발주서는 재활용하고, 품목 내역은 다시 넣는다'는 식으로 절반만 멱등성(Idempotency)이 확보된 구조였습니다.
수정 방법은 재사용했는지 여부를 기억해 두고, 재사용할 때는 품목 내역 등록 처리를 건너뛰는 것입니다.
$reuseExistingPo = false;
if ($existingPoId > 0 && !$isRecreate) {
$poId = $existingPoId;
...
버그 2: 주소를 '건물명'으로 오인하여 줄 바꿈을 합니다
발주서에는 납품처의 주소가 인쇄됩니다. 건물명 직전에서 줄 바꿈하는 처리를 주소 2번째 글자부터 판별하여 만들고 있었습니다.
판별 규칙은 다음과 같았습니다.
- 주소 2에 '번지'로 보이는 숫자가 없으면, 주소 2 전체를 건물명으로 간주합니다.
그런데 주소 2에 '◯◯동 27'과 같이 동네 이름(町名)과 번지만 들어오는 경우가 있었습니다. 숫자 부분에 '초메', '번', '호', '하이픈' 같은 것이 없기 때문에, '번호 없음 = 건물명'으로 판별되어 주소 중간에서 줄 바꿈이 발생해 버립니다.
수정 방법은 '번호 없음'일 때뿐만 아니라, 건물명처럼 보이는 단어가 포함되었을 경우에만 건물명으로 간주하는 것입니다.
- 빌딩, 맨션, 하이츠, 코포, 아파트, 레지던스, 메종, 타워, 팰리스
- '호실', '◯층'
이렇게 함으로써, 동네 이름과 번지만 있는 주소는 분리되지 않게 되었습니다.
왜 테스트에서 발견하지 못했나
두 경우 모두 제가 예상한 사용 시나리오로만 확인했기 때문입니다.
- 발주서 작성은 1회 수행하는 것을 전제로 만들었습니다.
- 주소는 건물명이 깔끔하게 분리되어 들어오는 경우를 상정했습니다.
AI가 작성한 코드는 예상된 사용 시나리오에서는 제대로 작동합니다. 하지만 '두 번 누르기', '다른 방식으로 입력하기'와 같은 예상치 못한 움직임에는, 제가 먼저 요청하지 않으면 확인되지 않습니다.
앞으로 확인할 것들
동일한 작업을 2회 수행해 본다. 결과가 1회 때와 동일한지 여부.
- 자유 입력 문자를 규칙으로 판별하고 있지는 않은지. 주소, 이름, 비고 등. 판별한다면 '적합한 것'을 나열하는 형태로 변경 (불일치하는 것을 제외하는 형태가 아님).
- '거래처가 먼저 발견하게 하는' 상황 자체를 없앤다. 외부로 나가는 서류는 실물을 보고 확인해야 합니다.
요약
- 중복 등록은 '재사용'과 '신규 작성'이 혼합되는 처리에서 발생하기 쉽습니다.
- 문자 규칙 판별은 '적합한 것'을 제시하는 형태가 안전합니다.
- AI가 작성한 코드는 예상치 못한 조작에 대해, 우리가 직접 시도해 봐야 합니다.
거래처에게 지적받았을 때, 부끄러움보다는 빨리 발견해서 다행이었다는 기분이 더 컸습니다. 외부에 나가기 전에 막는 시스템을 다음 글의 소재로 삼고 싶습니다.
지난 글에서는 AI에게 맡길 범위의 정하는 방법을 작성했습니다.
→ 『「맡길 범위를」먼저 정하니, AI가 멈추지 않게 되었다』
Discussion