출제기준 세세항목: 설계 산출물 · 인터페이스 명세서
인터페이스를 만들고 연계 테스트까지 마쳤다면, 마지막으로 '처음에 약속한 대로 만들어졌는가'를 정리해 확인합니다. 이것이 인터페이스 구현 검증입니다. 연계 테스트가 연결이 이어지는지를 직접 시험해 보는 일이라면, 구현 검증은 그 결과를 설계 산출물과 하나하나 대조해 빠진 것이나 어긋난 것이 없는지 판정하고 기록하는 일에 가깝습니다.
검증 기준은 언제나 문서입니다. 정의서에 '5초 안에 응답'이라고 적혀 있으면 실제로 5초 안에 응답하는지, '필수 항목이 빠지면 오류 코드 E01을 돌려준다'고 적혀 있으면 정말 그 코드가 오는지를 봅니다. 기준 문서가 없거나 모호하면 검증도 할 수 없으므로, 앞 단계에서 설계를 확인하고 검증 가능한 문장으로 적어 두는 일이 여기서 빛을 봅니다.
인터페이스는 수가 많고 같은 확인을 여러 번 반복해야 하므로, 사람이 일일이 손으로 하기보다 도구의 도움을 받습니다. 도구는 크게 테스트를 자동으로 돌려 주는 검증 도구와, 운영 중 상태를 계속 지켜보는 감시 도구로 나뉩니다.
검증 도구는 테스트를 자동으로 실행하고 결과를 모아 주는 테스트 자동화 프레임워크입니다. 시험에는 이름과 특징을 짝지어 묻는 경우가 많으니, '무엇을, 어떤 방식으로 테스트하는가'를 기준으로 구분해 두면 좋습니다.
xUnit은 함수나 클래스 같은 작은 단위를 테스트하는 프레임워크 묶음을 부르는 이름입니다. 자바용 JUnit, C++용 CppUnit, .NET용 NUnit처럼 언어마다 이름 앞부분만 바뀝니다. 인터페이스에서는 변환 함수나 입력값 검사 같은 구성 요소를 하나씩 확인할 때 씁니다.
STAF는 여러 서버와 환경에 흩어져 있는 테스트 대상을 한꺼번에 다루는 데 강한 프레임워크입니다. 각 대상 환경에 에이전트 역할을 하는 데몬을 두고, 그 데몬을 통해 테스트를 실행하고 결과를 모읍니다. 송신·중계·수신 시스템이 서로 다른 서버에 있는 인터페이스 테스트에 잘 맞습니다.
FitNesse는 웹 화면에서 위키처럼 표를 작성해 테스트 케이스를 만들고, 실행하고, 결과를 확인할 수 있는 웹 기반 프레임워크입니다. 입력값과 기대값을 표로 적으면 되므로, 개발자가 아닌 업무 담당자도 테스트 작성에 참여하기 쉽습니다. NTAF는 국내 기업(NHN)이 만든 테스트 자동화 프레임워크로, STAF의 분산 실행 능력과 FitNesse의 쉬운 테스트 작성 방식을 합친 것입니다.
Selenium과 watir는 웹 애플리케이션을 브라우저에서 사람이 쓰듯 자동으로 조작해 보는 도구입니다. Selenium은 여러 브라우저와 여러 프로그래밍 언어를 지원하고, watir는 Ruby 언어로 테스트를 작성합니다. 화면에서 요청을 보내 인터페이스를 거쳐 결과가 화면에 돌아오기까지를 확인할 때 쓸 수 있습니다.
검증 도구가 '만든 직후에 맞는지'를 본다면, 감시 도구는 '운영하는 동안 계속 잘 돌아가는지'를 봅니다. 대표적인 것이 APM(Application Performance Management 또는 Monitoring, 애플리케이션 성능 관리)이며, 스카우터(Scouter), 제니퍼(Jennifer), 핀포인트(Pinpoint) 같은 제품이 국내에서 많이 쓰입니다.
APM은 애플리케이션이 실제로 요청을 처리하는 모습을 계속 수집해, 응답 시간, 처리량, 오류 발생 수, 서버 자원 사용량 등을 보여 줍니다. 인터페이스 쪽에서는 어느 구간에서 처리가 느려졌는지, 어떤 인터페이스에서 오류가 갑자기 늘었는지, 데이터베이스 요청이 어디서 지연되는지를 추적하는 데 씁니다. 문제가 생기면 담당자에게 알림을 보내 사용자가 불편을 신고하기 전에 대응할 수 있게 해 줍니다.
APM은 테스트에서 미리 찾지 못한 문제를 운영 중에 잡아내는 마지막 그물 역할을 합니다. 또 측정한 수치는 앞에서 배운 애플리케이션 성능 개선의 출발점, 즉 '추측하지 말고 측정하라'의 근거 자료가 됩니다.
구현 검증에서는 인터페이스마다 몇 가지를 빠짐없이 확인합니다. 송신한 데이터가 정의된 항목과 형식대로 만들어졌는지, 수신 쪽에 기대한 값으로 반영되었는지, 송수신 건수가 맞는지, 정해진 주기와 응답 시간을 지키는지, 오류가 났을 때 정해진 처리가 일어나는지, 그리고 암호화나 인증 같은 보안 조건이 실제로 적용되었는지입니다.
오류가 났는지는 여러 경로로 확인할 수 있습니다. 사용자가 직접 쓰는 화면이라면 오류 메시지로 바로 알 수 있습니다. 배치처럼 화면이 없는 인터페이스는 오류 로그를 남기도록 만들어 두고, 로그를 보고 확인합니다. 연계 테이블을 쓰는 방식이라면 테이블에 처리 상태(대기, 성공, 실패)와 오류 코드를 적는 칸을 두어, 그 값을 조회해 어떤 건이 왜 실패했는지 확인합니다.
확인한 결과는 기대 결과와 실제 결과를 나란히 적고 통과 여부를 판정해 기록합니다. 통과하지 못한 항목은 원인과 조치 내용, 재검증 결과까지 함께 남겨야 나중에 같은 문제가 생겼을 때 참고할 수 있습니다.
설계 산출물은 설계 과정에서 만들어진 문서들을 말합니다. 인터페이스와 관련해서는 인터페이스 요구사항 명세서, 인터페이스 목록, 인터페이스 정의서, 데이터 표준과 코드 매핑표, 연계 테스트 케이스 등이 해당합니다. 이 문서들은 소프트웨어 설계 과목의 인터페이스 단계들에서 하나씩 만들어진 것입니다.
구현 검증에서 설계 산출물은 두 가지 역할을 합니다. 하나는 기준입니다. 무엇이 맞고 틀린지는 산출물에 적힌 내용으로 판정합니다. 다른 하나는 결과를 담는 그릇입니다. 검증 중에 설계와 다르게 구현해야 했던 부분이 생겼다면, 합의를 거쳐 산출물을 고쳐 실제 구현과 문서가 같아지도록 합니다.
산출물이 실제와 달라진 채로 남으면 나중에 큰 비용이 듭니다. 운영 담당자나 다음 개발자는 문서를 믿고 일하는데, 문서가 틀리면 잘못된 판단으로 이어지기 때문입니다. 그래서 요구사항, 설계, 구현, 테스트 결과가 서로 이어져 있도록(추적성) 관리합니다. 요구사항 하나를 골랐을 때 그것을 구현한 인터페이스와 검증한 테스트까지 따라갈 수 있어야 합니다.
인터페이스 명세서는 인터페이스 하나하나가 어떻게 동작하는지를 정리한 기준 문서입니다. 설계 단계의 정의서와 이름을 섞어 쓰는 경우가 많은데, 구현 검증 단계에서는 검증 중 바뀐 구현 내용을 반영해 실제 동작과 같도록 최신으로 유지한다는 점이 중요합니다.
담기는 내용은 크게 네 묶음으로 볼 수 있습니다. 첫째, 식별 정보입니다. 인터페이스 ID와 이름, 관련 업무, 담당자를 적습니다. 둘째, 송수신 정보입니다. 송신 시스템과 수신 시스템의 이름과 처리 프로그램, 실시간·배치 같은 송수신 방식, 주기, 전송을 시작시키는 조건을 적습니다. 셋째, 데이터 정보입니다. 주고받는 항목마다 이름, 자료형, 길이, 필수 여부, 허용 값, 송신 항목과 수신 항목의 매핑, 변환 규칙을 적습니다. 넷째, 처리 조건입니다. 오류 코드와 처리 방법, 성능 조건, 암호화·인증 같은 보안 조건을 적습니다.
명세서는 검증할 때 기준으로 삼는 문서이고, 검증과 오류 처리 결과는 따로 검증 결과 보고서에 정리합니다. 실무에서는 명세서에 그 보고서를 연결해 두면 쓸모가 커집니다. 연계 단위 테스트와 통합 테스트를 언제 어떤 케이스로 수행했고 결과가 어땠는지를 연결해 두면, 보고서를 연결해 둔 명세서를 따라가면 '무엇을 약속했고, 그대로 만들었으며, 확인까지 마쳤다'는 것을 한 번에 보여 줄 수 있습니다.
변환 함수는 JUnit으로 단위 테스트하고, 서로 다른 서버에 있는 송신·중계·수신 구간은 STAF로 묶어 자동 실행했습니다. 업무 담당자는 FitNesse 표에 '입력 주문 → 기대 정산 금액'을 적어 업무 규칙을 확인했고, 운영을 시작한 뒤에는 APM으로 인터페이스 응답 시간과 오류 수를 지켜봤습니다.
검증 중 상대 시스템이 한 번에 최대 500건까지만 받을 수 있다는 것이 드러나, 배치 전송을 500건씩 나눠 보내도록 고쳤습니다. 이 내용을 인터페이스 명세서의 송수신 정보에 추가해 문서와 실제 구현을 일치시키고, 다시 수행한 통합 테스트 결과는 검증 결과 보고서에 정리했습니다.
밤사이 배치 인터페이스 몇 건이 수신 쪽에 반영되지 않았습니다. 연계 테이블에서 처리 상태가 '실패'인 행을 조회하자 오류 코드가 '코드 매핑 없음'으로 남아 있었고, 매핑표에 새 코드값을 추가한 뒤 해당 건만 다시 처리했습니다.