문서가 한 번 열렸다는 사실만으로 교체를 결정할 수는 없었습니다. 인터넷뱅킹 문서 뷰어 N사의 HTML5 전환에서 브라우저·운영체제별 주요 흐름을 점검하고 확인한 범위와 남은 위험을 출시 판단 문서로 정리했습니다.
문서를 보는 기능은 단순해 보입니다. 파일이 열리고 내용이 보이면 끝난 것처럼 느껴집니다. 하지만 실제 업무에서는 화면으로 읽는 것에 이어 인쇄하거나 저장하는 흐름도 필요합니다.
인터넷뱅킹 문서 뷰어 N사는 기존 뷰어를 HTML5 기반으로 교체하고 출시를 준비하고 있었습니다. 브라우저와 운영체제 조합이 달라지면 문서 표시와 후속 동작도 달라질 수 있어 어느 환경에서 무엇을 확인했는지 설명할 근거가 필요했습니다.
2025년에 진행한 이 검수의 목표는 막연한 안심을 제공하는 것이 아니었습니다. 출시 회의에서 확인된 사실과 아직 확인되지 않은 조건을 함께 검토할 수 있도록 만드는 것이었습니다.
테스트를 시작하기 전에 출시할 대상을 고정했습니다
개발이 이어지는 동안에는 검증 대상도 바뀌기 쉽습니다. 처음 확인한 파일과 실제 공개할 파일이 다르면 이전 결과를 그대로 적용할 수 있는지부터 다시 판단해야 합니다.
이 프로젝트는 릴리스 후보 빌드 하나를 대상으로 범위를 서면 합의한 뒤 시작했습니다. 검수 결과가 어떤 대상에 대한 판단인지 분명하게 두는 방식입니다.
범위를 고정하는 것은 변경을 금지한다는 뜻이 아닙니다. 결과가 어떤 조건에서 적용되는지를 설명하기 위해서입니다. 대상이 바뀌면 이전에 확인한 내용과 새로 확인해야 할 내용을 구분할 수 있어야 합니다.
출시 전 검수에서 대상의 명확성은 일정만큼 중요합니다. “검사했다”는 말에 어떤 빌드를 확인했다는 정보가 빠지면 정작 출시할 결과물과 검증 기록의 관계가 흐려집니다.
문서 표시·인쇄·저장을 환경 조합과 함께 봤습니다
핵심 흐름은 문서 표시, 인쇄, 저장으로 정했습니다. 각 흐름을 합의한 브라우저와 운영체제 조합에서 실행했습니다.
기능 목록과 환경 목록을 따로 두는 것만으로는 충분하지 않습니다. 어떤 기능을 어떤 환경에서 실행했는지 연결해야 빠진 조합을 찾을 수 있습니다.
예를 들어 한 환경에서 문서가 잘 열린다는 사실이 다른 환경의 인쇄 결과까지 설명해 주지는 않습니다. 반대로 환경을 많이 준비했더라도 실제로 확인한 동작이 문서 열기뿐이라면 검수의 깊이는 제한적입니다. 기능과 환경을 함께 보는 이유가 여기에 있습니다.
이 프로젝트에서도 조합별 시나리오 실행 결과를 기준으로 결함을 기록했습니다. 문제의 심각도와 발생한 조건을 함께 남겨 수정 순서를 논의할 수 있도록 했습니다.
제외한 범위도 결과의 일부로 남겼습니다
모든 환경을 같은 깊이로 확인할 수는 없습니다. 제한된 일정에서 어떤 조합과 동작을 우선 검증할지 결정해야 합니다.
프로젝트에서는 확인하지 않은 환경과 흐름을 제외 범위로 기록했습니다. 결과 문서에 통과한 항목만 보여주는 대신 판단이 닿지 않는 부분도 함께 남겼습니다.
확인하지 못했다는 사실은 실패했다는 뜻이 아닙니다. 동시에 문제가 없다고 확인한 것도 아닙니다. 이 둘을 구분해야 검증 결과를 읽는 사람이 자신의 전제를 덧붙이지 않게 됩니다.
검수 범위가 명확하면 운영팀도 결과를 더 정확하게 해석할 수 있습니다. 출시 뒤 문의가 들어왔을 때 이미 살펴본 환경인지, 당시 검증 대상 밖이었는지 확인할 출발점이 생깁니다.
수정 요청과 수정 확인을 구분했습니다
결함을 전달한 다음 수정되었다는 답을 받는 것과 수정 결과를 직접 실행해 확인하는 것은 다른 단계입니다.
N사 프로젝트에서는 수정분에 대해 한 차례 재검증을 진행했습니다. 최초 확인 내용에 더해 수정 후의 결과를 검토하는 과정이 있었습니다.
재검증 역시 확인한 수정 범위와 조건 안에서 해석해야 합니다. 한 문제의 개선을 확인했다고 해서 다른 모든 환경이나 후속 변경까지 확인한 것으로 볼 수는 없습니다.
기록이 마지막 검수 상태를 설명하는지가 중요합니다. 최초 결함 목록만 남아 있거나 수정 요청만 남아 있으면 출시 시점에 무엇이 해결됐고 무엇이 남았는지 다시 추적해야 합니다.
마지막 결과물은 판단의 근거를 모은 릴리스 메모였습니다
검증 결과, 제외 범위, 판정의 전제와 잔여 위험을 릴리스 메모로 정리했습니다. 출시 가능, 조건부 가능, 보류로 구분하는 판단 체계 안에서 결과를 검토하고 담당자가 서명하는 절차를 거쳤습니다.
이 사례에서 강조하는 것은 특정 판정의 이름이 아니라 판정을 설명할 수 있는 구조입니다. 어떤 환경을 살폈고 무엇은 확인하지 않았는지, 어떤 조건을 전제로 판단했는지가 같은 문서에 있어야 합니다.
문서 뷰어 검수는 금융 서비스 전체의 보안성이나 모든 운영 조건을 인증하는 작업과도 구분됩니다. 합의한 대상과 범위 안에서 실행한 결과를 전달하는 일입니다.
HTML5로 기술을 바꾼 것만큼 중요한 것은 그 변경을 공개할 근거를 마련하는 일이었습니다. 이 프로젝트는 “잘 된다”는 보고를 어디까지 확인했고 어떤 전제에서 판단했는지 설명할 수 있는 기록으로 바꿨습니다.
