구현 완료와 연계 검증 완료는 다른 상태입니다
유럽 Oligo 배송에 필요한 통관정보를 추가하면서 본사·유럽의 COMS와 LIMS, Outsourcing API까지 데이터가 이어져야 했습니다. 다룬 값은 EORI, HS Code, Commodity와 서명정보였고, 주문 화면에서 받은 값이 운송장과 Commercial Invoice에 반영되는 흐름이었습니다.
코드 변경은 각 시스템에 들어갔지만 모든 연계 구간을 같은 환경에서 실행할 수 있는 것은 아니었습니다. 특히 Outsourcing API는 구현 범위에 포함됐지만 QAS에서 실제 호출 결과를 검증할 수 없었습니다. 이때 코드를 작성했다와 통합테스트를 마쳤다를 같은 완료 상태로 기록하면 확인하지 못한 구간이 사라집니다.
통관정보가 지나는 시스템을 펼쳤습니다
검증 대상을 시스템 이름만 나열하지 않고 입력부터 문서까지 데이터가 이동하는 순서로 정리했습니다.
본사 주문 화면 ─▶ 본사 LIMS ─▶ 운송장·Invoice
유럽 주문 화면 ─▶ 유럽 LIMS ─▶ 운송장·Invoice
│
└──────── Outsourcing API 연계 경로본사와 유럽은 서로 다른 주문 화면과 LIMS를 사용했기 때문에 한쪽에서 값이 보인다는 사실로 다른 쪽까지 통과했다고 볼 수 없었습니다. 주문 등록, LIMS 조회와 문서 생성에서 같은 통관정보가 유지되는지 각각 확인했습니다.
Outsourcing API도 도식에는 포함했지만 실제 호출을 검증한 것은 아닙니다. 구현한 구간과 실행 가능한 테스트 구간을 별도로 표시했습니다.
시스템별 증거 상태를 따로 기록했습니다
최종 범위를 공개 가능한 수준으로 정리하면 다음과 같습니다.
| 구간 | 구현 | QAS 데이터 흐름 확인 | 완료 범위에 포함 |
|---|---|---|---|
| 본사 COMS | 완료 | 확인 | 포함 |
| 본사 LIMS | 완료 | 확인 | 포함 |
| 유럽 COMS | 완료 | 확인 | 포함 |
| 유럽 LIMS | 완료 | 확인 | 포함 |
| Outsourcing API | 완료 | 확인하지 못함 | QAS 통합테스트에서는 제외 |
Outsourcing API를 포함한 5개 구성요소를 모두 검증했다고 기록하지 않았습니다. 결과는 본사·유럽 COMS·LIMS 4개 시스템 QAS 검증 완료, Outsourcing API QAS 미검증으로 남겼습니다. 미검증은 실행해 실패한 것이 아니라 해당 환경에서 검증할 수 없었던 상태입니다.
완료 기준을 한 문장으로 합치지 않았습니다
연계 작업에는 최소한 다음 상태가 있습니다.
- 요청 필드와 저장 구조를 구현했습니다.
- 개별 시스템에서 값이 저장·조회되는지 확인했습니다.
- QAS에서 앞뒤 시스템을 연결해 같은 값이 전달되는지 확인했습니다.
- 사용자가 실제 업무 시나리오를 확인했습니다.
- 운영에 반영했습니다.
각 단계는 이전 단계를 포함할 수 있지만 자동으로 다음 단계가 되지는 않습니다. 이번 작업에서는 네 시스템의 QAS 데이터 흐름과 사용자 확인을 확보했습니다. Outsourcing API는 1단계 구현 범위에는 있었지만 3단계 증거가 없었으므로 같은 통합테스트 완료 묶음에 넣지 않았습니다.
이 구분은 보고 문구를 보수적으로 만드는 데서 끝나지 않습니다. 나중에 문제가 생겼을 때 QAS에서 통과했던 구간과 운영에서 처음 실행되는 구간의 점검 우선순위를 다르게 잡을 수 있습니다.
정상값과 입력 제한을 함께 확인했습니다
초기 구축과 배포 뒤 일부 주문에서 EORI가 기존 입력 한도를 넘자 오류가 발생했습니다. 14자를 넘는 값이 들어오는 실제 사례가 있었고, 후속 작업에서 문자와 숫자를 최대 30자까지 받을 수 있도록 범위를 넓혔습니다.
이 후속 변경을 최초 구축의 통합테스트에 소급해 포함하지 않았습니다. 시점을 다음처럼 나눠 기록했습니다.
- 2023년 9~10월: 통관정보 연계 구현·QAS 검증과 배포
- 2023년 11월: 구축 범위 최종 확인
- 2023년 12월: 실제 입력 오류에 따른 EORI 길이 후속 개선
정상적인 예시값이 네 시스템을 통과했다는 사실과 현실의 최대 입력 범위를 충분히 검증했다는 사실은 다릅니다. 후속 오류는 별도 개선으로 남겨야 원래 테스트가 보장했던 범위를 정확히 알 수 있습니다.
미검증 구간을 다루는 실무 기준
비슷한 연계에서 테스트 환경 제약이 있다면 전체 완료 대신 다음 정보를 함께 남기는 편이 좋습니다.
- 어느 시스템까지 실제 요청을 보냈는지
- 각 구간에서 어떤 값과 상태를 관찰했는지
- Mock이나 정적 검토로만 확인한 구간은 어디인지
- 운영에서 처음 실행되는 구간과 복구 방법은 무엇인지
- 후속 검증의 담당자와 조건은 무엇인지
이번 사례에서는 Outsourcing API의 구현 사실까지만 확인했고 QAS 호출 성공을 주장하지 않았습니다. 반대로 네 시스템에서 실제로 확인한 데이터 흐름은 일부만 테스트했다고 축소하지 않고 검증 완료 범위로 명확히 남겼습니다.
직접 수행 범위
제가 맡은 일은 통관정보 요구사항 분석과 본사·유럽 주문·LIMS 경로 개발, 네 시스템 QAS 데이터 흐름 검증, 배포와 EORI 입력 범위 후속 개선입니다. Outsourcing API 경로도 구현했지만 QAS에서 검증하지 못한 한계를 분리했습니다.
이 글은 확인한 네 시스템과 QAS에서 검증하지 못한 API 구간을 완료 표시로 구분하고, 운영 이후 입력 길이 개선을 별도 단계로 추적한 기록입니다.