결함을 고치는 일보다 어려운 것은, 고친 결과가 다른 곳을 깨뜨리지 않았음을 증명하는 일입니다. 소프트웨어에서 한 줄의 수정은 언제든 새로운 문제를 부를 수 있으니까요. XGEN Agentic AI Platform이 패치 이후 일주일간 거친 회귀시험 이야기입니다.
시리즈 · GS 인증 여정 — 전 5부
- 문서만 잘 내면 될 줄 알았습니다
- 시험 첫날, 문서와 제품이 다른 말을 하고 있었습니다
- "이 답변, 근거가 뭐죠?" — AI라서 받은 질문들
- 고치고 나서가 진짜 시작이었습니다 (지금 읽는 글)
- 아직 "획득했다"고 말하지 않는 이유
패치, 그리고 일주일의 회귀시험
GS 인증은 결함을 수정한 뒤 회귀시험을 요구합니다. 같은 기능을 다시 확인해, 수정이 전체를 흔들지 않았는지 검증하는 절차입니다.
- 6월 15일 — 결함리포트로 요청된 수정사항을 서버에 배포했습니다(제품 패치, 09:00~18:00)
- 6월 15일 ~ 6월 22일 — 일주일간 회귀시험을 진행했습니다
- 6월 18일 — 2차 수정사항을 배포하고 최종 매뉴얼을 송부했습니다
- 6월 19일 — 매뉴얼 관련 추가 결함에 회신하고 수정사항을 다시 반영했습니다
같은 수정을 반영하고 또 확인하는 과정이 반복됐습니다. 지루하지만, 신뢰성은 이 반복에서 만들어집니다.
보안성은 규제 산업의 최소 조건입니다
금융과 공공을 전제로 하는 제품에게 보안성은 선택이 아닙니다.
6월 17일 — 보안성 관련 회귀 결함리포트에 대해 코드를 수정하고 답변을 회신했습니다.
정상 동작을 보여주는 일은 어렵지 않습니다. 어려운 것은 예외 상황입니다. 외부 도구 호출이 실패하면 어떻게 되는가, 응답이 지연되면 어떻게 되는가 — 저희는 이런 실패 경로 하나하나가 안전하게 멈추고 복구되는지를 증명해야 했습니다. 정상 케이스 시연보다 실패 케이스 설계에 더 많은 시간이 들어간 이유입니다.
성능은 느낌이 아니라 데이터로
성능은 주장으로 통과되지 않습니다. 시험은 실제 서버 사양 정보와 함께 성능 로우데이터를 요구했습니다.
- 6월 4일 — 서버 세부사양 정보와 성능테스트 로우데이터를 수집했습니다(13:10~16:40)
- 6월 19일 — 제품 패치 이후 동일한 조건으로 성능시험을 다시 수행했습니다(13:10~16:40)
같은 조건에서 패치 전후를 측정해, 수정이 성능을 떨어뜨리지 않았음을 데이터로 남겼습니다.
정리하며
패치(6/15) → 회귀시험(6/15~6/22) → 시험 완료 및 보고서 작성(6/22)으로 이어지는 동안, 저희가 확인하려 한 것은 하나였습니다. 고친 뒤에도 제품 전체가 여전히 약속대로 동작하는가.
시험은 6월 22일 마무리되고 보고서 작성 단계로 넘어갔습니다. 이제 남은 것은 최종 시험품 제출과 인증위원회 심사입니다. 마지막 편에서 정리하겠습니다.
이전 편 → "이 답변, 근거가 뭐죠?" — AI라서 받은 질문들 다음 편 → 아직 "획득했다"고 말하지 않는 이유