46. 테스트 계획, 시나리오, 결과서 (단위, 통합, 시스템, 인수 테스트) 완결성 대조 확인

핵심 인사이트 (3줄 요약)

본질: 정보시스템 감리에서 테스트 완결성 점검은, 발주기관이 요구한 모든 기능(요구사항)이 'V-모델'의 원칙에 따라 "단위 → 통합 → 시스템 → 인수" 테스트 생명주기(SDLC)를 거치며 계획(Plan), 시나리오(Test Case), 그리고 최종 결과(Result) 간에 100% 빈틈없이 양방향 추적(Traceability)되는지 대조하는 감사 활동이다.

가치: "우리끼리 테스트 다 돌려서 녹색불(Pass) 떴어요"라는 개발사의 구두 보고나 허술한 자동화 툴 캡처본을 무효화시키고, 실제 결함(Bug)이 조치(Remediation)되어 요구사항을 온전히 충족했는지를 객관적인 문서(증적) 기반으로 증명하여 프로젝트 오픈(Go-Live)의 타당성을 보증한다.

융합: 감리원은 이 3종 세트(계획-시나리오-결과)를 단순 워드/엑셀 포맷으로만 검증하지 않는다. 요구사항 추적 매트릭스(RTM)를 척추로 삼아, Jira, SonarQube, Selenium 같은 최신 CI/CD 기반 DevOps 파이프라인의 자동화 결함 트래킹 대시보드와 대조하는 융합적 품질 보증(QA) 거버넌스를 수행한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 테스트 활동은 머릿속으로 코드를 돌려보는 것이 아니라, 1) 어떻게 칠 것인가(테스트 계획서), 2) 어떤 버튼을 순서대로 누를 것인가(테스트 시나리오/TC), 3) 진짜로 눌러보니 성공했는가(테스트 결과서)라는 3단계 공식 산출물로 귀결된다. 감리원은 이 세 문서 간의 '숫자'와 '로직'이 완벽히 아귀가 맞는지(완결성)를 돋보기로 확인하는 법의학자다.
필요성: 프로젝트 막바지에는 개발자들이 밤을 새우며 오픈 일정에 쫓긴다. 이때 가장 먼저 포기하는 것이 "제대로 된 테스트"다. 엑셀에 적어둔 1,000개의 시나리오를 복사+붙여넣기로 전부 "PASS"라고 조작하여 감리단에 제출하는 식의 '가라(거짓) 문서'가 판을 친다. 만약 결제 버튼을 눌렀을 때 오류가 나는데도 결과서에 PASS라고 적힌 채 시스템이 오픈되면 수억 원의 횡령이나 고객 이탈이 발생한다. 감리원의 깐깐한 3종 문서 대조는 이 재앙을 막는 유일한 최후의 브레이크(Safety Gate)다.
💡 비유: 이것은 제약 회사의 "신약 임상 시험 검증"과 똑같다. 제약사가 "100명한테 약을 먹일 계획(계획서)"을 세웠고, "아침저녁으로 두 알씩 먹인 기록(시나리오)"이 있는데, "병이 다 나았다는 최종 건강검진 표(결과서)"를 제출했다. 식약처(감리원)는 이 3개 문서의 환자 이름과 날짜, 복용량이 한 글자도 빠짐없이 100% 일치하는지 돋보기로 대조해서 약의 판매(시스템 오픈)를 승인하는 것이다.
📢 섹션 요약 비유: 요리사가 "스테이크를 굽겠다(계획)"고 해놓고, "레시피에는 닭고기를 삶고(시나리오 불일치)", 최종 테이블에는 "라면이 올라왔다면(결과 엉망)" 그 식당은 망합니다. 감리원은 메뉴판-레시피-완성된 요리가 정확히 일치하는지 주방 문턱에서 철저히 검사하는 미슐랭 암행어사입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

V-모델 기반의 테스트 산출물 대조 아키텍처 (Traceability)

감리원이 3종 문서를 검토할 때는 무작정 읽는 것이 아니라, 소프트웨어 공학의 바이블인 'V-모델'의 계층 구조에 산출물을 1:1로 맵핑(Mapping)시켜 누락을 추적한다.

  ┌───────────────────────────────────────────────────────────────────┐
  │                 V-모델 기반 감리 테스트 완결성 검증 맵핑              │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │  [개발/설계 산출물]                                  [테스트 산출물]     │
  │                                                                   │
  │   요구사항 정의서 ────────────────(추적)────────────────▶ 인수 테스트 │
  │          │                                                ▲        │
  │          ▼                                                │        │
  │   시스템/기본 설계서 ──────────────(추적)────────────────▶ 시스템 테스트│
  │          │                                                ▲        │
  │          ▼                                                │        │
  │   상세 설계서 (클래스/DB) ──────────(추적)────────────────▶ 통합 테스트 │
  │          │                                                ▲        │
  │          ▼                                                │        │
  │   소스 코드 (구현) ─────────────────(추적)────────────────▶ 단위 테스트 │
  │                                                                   │
  │  ===============================================================  │
  │  [ 감리원의 문서 3종 대조 검증 (Cross-Check Logic) ]                  │
  │                                                                   │
  │   (문서 1) 테스트 계획서 : "총 500개의 요구사항을 4단계로 테스트하겠다."   │
  │              ↕  [대조 1: 범위가 100% 맵핑되었는가?]                   │
  │   (문서 2) 테스트 시나리오 (TC) : "그래서 1,200개의 클릭 순서를 짰다."     │
  │              ↕  [대조 2: 수행 누락 및 에러 조치(Retest) 증적이 있는가?] │
  │   (문서 3) 테스트 결과서 : "1,200개 돌려보니 결함 30개 발생, 전부 고쳐서   │
  │                           재테스트 후 최종 PASS 완료!" (화면 캡처 첨부)   │
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 감리의 핵심 무기는 요구사항 추적 매트릭스(RTM) 이다. 감리원은 V-모델의 왼쪽(요구사항)과 오른쪽(테스트)을 RTM이라는 투명한 실로 연결한다. 만약 요구사항 정의서에 "REQ-001: 관리자는 회원 정보를 엑셀로 다운받을 수 있다"라고 적혀 있는데, 제출받은 통합 테스트 시나리오(TC) 목록에 REQ-001을 찌르는 액션이 한 줄도 없다면? 감리원은 즉시 부적합(시나리오 누락) 판정을 때리고 "해당 기능을 테스트하는 문서를 다시 만들고 진짜로 버튼을 눌러 결과 캡처를 가져오라"고 시정 조치를 강제한다. 이것이 완결성 대조의 핵심 매커니즘이다.

단계별 감리 중점 점검 포인트

테스트 단계(단위/통합/시스템/인수)에 따라 감리원이 돋보기를 들이대는 타겟이 완전히 다르다.

테스트 단계	주관 주체	감리원 3종 문서 대조 시 중점 점검 핵심 (Audit Point)
단위 테스트 (Unit)	개발자	- 계획/결과서 대비 소스코드 커버리지(예: 구문 80% 이상) 충족 여부 증적 - Dummy/Mock 데이터를 이용한 예외/오류 처리(Null 등) 로직 TC 포함 여부
통합 테스트 (Integration)	리드 개발자, QA	- 화면(Front) ↔ WAS ↔ DB 간의 데이터 정합성 및 인터페이스 파라미터 대조 - 외부 타 기관망 연계(EAI/API) 구간의 타임아웃, 전문 송수신 실패 시나리오 존재 확인
시스템 테스트 (System)	QA 팀, PM	- 기능(Function)뿐 아니라 비기능(성능, 보안, 대용량 부하, 페일오버) 시나리오/결과 검증 - 동시 접속자 1만 명 부하(JMeter) 시 응답속도 3초 이내 PASS 화면 캡처 대조
인수 테스트 (Acceptance)	발주자(고객)	- 실제 시스템을 운영할 현업 담당자의 최종 합격(Sign-off) 서명 누락 대조 - 알파/베타 테스트 중 나온 헬프데스크(VOC) 불만 사항이 결함(Bug)으로 등록되어 조치되었는가

📢 섹션 요약 비유: 단위 테스트 감리가 "나사 하나하나가 안 부러지는지 당겨보는 도면 검사"라면, 통합 테스트 감리는 "바퀴와 핸들이 연결되어 잘 꺾이는지 보는 검사"이고, 시스템 테스트 감리는 "사막과 빙판(악조건)에서 차가 안 퍼지는지 보는 검사"이며, 인수 테스트 감리는 "진짜 돈을 낸 손님이 차 키를 받아보고 만족해서 싸인을 했는지" 서류를 대조하는 빈틈없는 그물망입니다.

Ⅲ. 융합 비교 및 다각도 분석

정형(문서) 테스팅 감리 vs 애자일(Agile/DevOps) 자동화 테스팅 감리

과거 종이(엑셀) 문서로만 제출되던 산출물들이, 현대의 SI 프로젝트에서는 형상 관리(Git)와 묶여 완전히 디지털 대시보드(Dashboard) 형태로 진화했다. 감리원도 이에 맞춰 검증 방식(Audit Tool)을 융합해야 한다.

비교 항목	전통적 워터폴 (Waterfall) 감리 환경	최신 애자일/DevOps (CI/CD) 감리 환경
산출물 형태	수천 줄의 Excel 스프레드시트 (수작업 조작 쉬움)	Jira ↔ Zephyr ↔ GitLab 통합 대시보드 (조작 불가)
결과서 증명	개발자가 일일이 화면을 뜬 캡처(Screenshot) 문서	Jenkins/SonarQube가 뽑아낸 자동화된 Test Report 및 커버리지(%) 리포트 URL
결함 추적 (Bug)	엑셀 시트의 "이슈 로그(Issue Log)" 탭 대조 확인	Jira/Redmine 티켓의 Status(Open ➔ Resolved ➔ Closed) 변경 이력 실시간 대조
감리원 업무	문서 복붙 오타, 캡처 날짜 위조, 누락 번호 눈알 스캐닝	시스템(API)에 직접 로그인하여 대시보드의 Pass/Fail 비율 및 결함 조치 시간 쿼리 추출

감리원이 "엑셀 파일 하나 주시면 도장 찍어줄게요" 하던 시대는 끝났다. 훌륭한 감리원은 "Jira 결함 티켓 권한을 열어달라. 내가 직접 JQL을 짜서, 1주일 넘게 '진행 중'으로 방치된 크리티컬 버그 50개가 오픈 전날 갑자기 한 번에 '조치 완료'로 억지 세팅되었는지 로그를 감사하겠다"며 시스템적 무결성을 파고들어야 한다.

📢 섹션 요약 비유: 옛날 감리원이 서류 다발에 적힌 도장의 잉크 번짐을 보고 가짜를 찾아내는 셜록 홈스였다면, 현대의 감리원은 해커처럼 K8s와 Jira 파이프라인 백엔드에 접속해 디지털 로그(Log)의 모순을 찾아내는 사이버 수사대로 융합 진화했습니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 요구사항 대비 단위/통합 테스트 시나리오 누락 적발: 수백억짜리 국세청 차세대 시스템 감리 현장. 개발팀이 5,000개의 '통합 테스트 결과서' 엑셀 파일을 제출하며 100% PASS라고 자신만만해했다. 하지만 감리원이 요구사항 추적 매트릭스(RTM)를 크로스체크(V-LookUP) 해보니, 전체 300개의 요구사항 중 "비정상 세금 환급 시 관리자 알람 발송"이라는 15개 요구사항에 대한 테스트 시나리오 ID가 아예 존재하지 않는 빵꾸(누락)를 찾아냈다.
- 기술사적 판단: 개발팀이 "기능은 개발했는데 시간이 없어 엑셀에 시나리오만 안 적었을 뿐"이라고 변명하더라도, 감리인은 이를 절대 수용해선 안 된다. 산출물(증적)이 없는 기능은 개발되지 않은 것으로 간주하는 것이 감리 원칙이다. 감리인은 해당 요구사항 15건을 "결함(결과물 불일치)"으로 공식 시정 조치 요구하고, 해당 기능을 즉시 테스팅 환경에서 감리인 입회하에 직접 시연(Demonstration)하여 증거 캡처를 결과서에 편철하도록 강제하여 시스템의 구멍을 틀어막았다.
시나리오 — 결함(Defect) 재테스트(Retest) 미조치 상태로 오픈 강행: 대형 은행 앱 오픈 1주 전, 시스템 테스트 결과서에 치명적(Critical) 버그 5건이 '오픈 이슈(조치 중)' 상태로 기재되어 있었다. 사업 총괄 PM은 "디자인 UI가 1픽셀 틀어진 사소한 버그니 나중에 고치고 일단 오픈 승인(적합) 판정을 내달라"고 감리단을 압박했다.
- 기술사적 판단: 감리인은 테스트 계획서에 명시된 '결함 등급 분류 기준(Severity)' 과 '오픈 이행(Go-Live) 조건' 을 법전처럼 대조해야 한다. 만약 ওই 5건의 버그가 진짜 UI 픽셀 문제(Low 등급)라면 '조건부 적합(우회 반영)'으로 넘어갈 수 있다. 그러나 확인 결과 "이체 버튼 연타 시 중복 결제"라는 치명적 돈 계산 오류였다. 아키텍트는 어떠한 압박에도 굴하지 않고, "해당 결함 조치 후 회귀 테스트(Regression Test) 100% PASS 결과서가 나오기 전까지는 감리 최종 보고서를 '부적합'으로 발행하겠다"고 강경하게 통제(Gatekeeping)하여 대국민 금융 사고를 막아야 한다.

테스트 3종 문서 대조 완결성 체크리스트 (감리인 시각)

입력값/결과값의 구체성: 시나리오에 "A 버튼을 누르면 정상 처리된다"라고 모호하게 적혔는가? (X) ──▶ "금액 칸에 -10,000을 넣고 결제 누르면, '음수 불가' 팝업이 뜬다"처럼 입력값과 기대 결과가 초등학생도 따라 할 수 있게 명확히 적혀 있는가? (O)
결함 조치율 (Defect Resolution Rate): 발견된 100개의 버그 중 99개가 고쳐졌다고(조치 완료) 적혀 있을 때, 개발자가 고쳤다고 우기는 것인지, QA가 다시 버튼을 눌러 확인(Retest)하고 닫아준(Closed) 완벽한 서명 상태인지 더블 체크했는가?
📢 섹션 요약 비유: 건물을 다 짓고 벽지를 예쁘게 발랐다고(PASS) 입주 승인을 내주는 것이 아닙니다. 감리인은 설계도(계획)에 시멘트를 10톤 넣으라고 했는데, 자재 반입 장부(시나리오)에 5톤만 들어온 기록을 잡아내고, 현장을 부숴서 철근(결과)이 제대로 박혔는지 엑스레이로 찍어내는 깐깐한 안전 진단관입니다.

Ⅴ. 기대효과 및 결론

기대효과

대규모 운영 장애(장애 패닉) 원천 차단: 테스트도 안 해놓고 한 척 위조된 '가라(거짓) 산출물'을 잡아냄으로써, 사용자가 몰리는 오픈 첫날 서버가 내려앉고 데이터가 엉키는 대재앙적 리스크를 물리적으로 필터링한다.
프로젝트 품질의 투명성 확보: 발주자(고객)는 감리원이 쪼개어 분석한 RTM 추적표와 결함 조치율 그래프를 보고, 막연한 짐작이 아니라 "우리 시스템이 99% 안전하구나"라는 객관적 수치(데이터)를 믿고 런타임 버튼을 누를 수 있다.
법적/계약적 책임 기준점(Baseline) 확립: 시스템 오픈 후 예상치 못한 오류가 터졌을 때, 이 3종 세트 산출물은 "개발사가 계약대로 개발/테스트 의무를 다했는지"를 가르는 법적 면책 또는 배상의 핵심 증거 서류가 된다.

미래 전망 (AI 기반 자동화 감리)

미래의 테스트 감리 환경에서는 감리원이 수만 줄의 엑셀 시나리오를 눈알이 빠지도록 읽을 필요가 없어진다. LLM(거대 언어 모델) 기반의 AI 감리 봇(Bot) 이 요구사항 명세서(Word)와 테스트 시나리오(Excel/Jira)를 스스로 읽어 들이고 의미를 비교(Semantic Matching)하여, "요구사항 31번을 찌르는 시나리오가 뉘앙스 상 누락된 것 같다"거나 "결과서의 화면 캡처가 조작된 이미지(Photoshop)로 의심된다"라고 1분 만에 AI 리포트를 찍어내는 스마트 자동화 감사 체계로 진화할 것이다.

결론

테스트 계획서, 시나리오, 결과서의 완결성 대조는 감리인이 발휘할 수 있는 가장 고단하고 피 말리는 텍스트 분석 노동이자, 동시에 시스템의 생명줄을 살려내는 가장 신성한 품질 수호(QA Guard) 행위다. 코드는 거짓말을 하지 않지만, 사람이 적어낸 엑셀(결과서)은 일정에 쫓기면 무한한 거짓말을 만들어낸다. 감리 및 IT 품질 아키텍트는 겉으로 보이는 화려한 PASS 화면에 속지 말고, 요구사항(RTM)이라는 거미줄을 당겨 테스트 시나리오의 빈 구멍을 샅샅이 파헤치며 "검증되지 않은 코드는 결코 운영(Live) 밭에 나설 수 없다"는 차가운 소프트웨어 공학의 헌법을 끝까지 집행해야 한다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
요구사항 추적 매트릭스 (RTM)	기획(요구사항)부터 개발, 설계, 그리고 최종 테스트 시나리오(TC)까지 1:1로 번호를 매핑하여 누락된 기능이나 테스트가 없는지 한눈에 파악하는 감리의 만능 치트키 문서다.
V-모델 (V-Model)	테스트는 코딩 끝나고 몰아서 하는 것이 아니라, 요구사항 분석 때 인수테스트를 짜고 기본 설계 때 시스템 테스트를 짜는 등 '개발 단계와 테스트 단계를 대칭'으로 묶는 아키텍처 철학이다.
리그레션 테스트 (Regression Test)	결함을 발견해 고쳤을 때(결과서 작성 중), 고친 코드 때문에 멀쩡하던 다른 기능이 망가지지 않았는지 예전 시나리오를 다시 몽땅 돌려보는 확인 사살 절차다.
블랙박스 테스팅 (Black-box)	시스템 내부 소스 코드를 몰라도, 감리원이나 현업 사용자가 "입력값을 넣었을 때 기획서대로 정답이 나오나" 화면과 기능(명세서)만 보고 때려보는 시나리오 중심 테스트다.
테스트 커버리지 (Test Coverage)	개발자가 "단위 테스트 다 돌렸어요"라고 우길 때, "진짜로 if/else 문 100줄 중 80줄 이상을 코드가 핥고 지나갔는지" 기계적으로 퍼센트(%)를 뽑아 거짓말을 막는 정량 지표다.

👶 어린이를 위한 3줄 비유 설명

감리원이 테스트 3종 세트를 검사하는 건 선생님이 꼼꼼하게 "방학 숙제 진짜로 했는지 3단 콤보로 검사" 하는 것과 같아요.
1단계: "일기 30일 치 쓴다고 계획표에 적었지? (계획서)", 2단계: "그럼 언제 뭐 할 건지 날짜별로 스케줄 짜왔지? (시나리오)"
3단계: "자, 그럼 30일 치 진짜로 쓴 일기장(결과서) 가져와 봐. 날짜랑 내용이 딱 맞는지 돋보기로 다 읽어볼 거야!" 라고 검사해서, 엄마 몰래 가짜로 적은 핑계를 완벽하게 쏙쏙 잡아내는 거랍니다!