개념
분쟁은 숫자가 아니라 범위에서 터진다
시험성적서를 둘러싼 갈등을 몇 건 지켜보면 패턴이 보인다. 측정값이 틀렸다고 다투는 경우는 의외로 드물다. 장비는 정확하고 시험원은 성실하다. 갈등은 거의 항상 같은 문장에서 시작한다.
"우리가 요구한 건 이게 아닌데요."
발주처는 "로그인 기능 시험"을 의뢰했다고 생각했고, 시험기관은 "로그인 화면의 정상 인증 흐름"을 시험했다. 소셜 로그인, 비밀번호 재설정, 계정 잠금, 동시 로그인 제한은 시험되지 않았다. 성적서에는 "로그인 기능 — 적합"이라고 적혀 있다. 양쪽 다 거짓말을 하지 않았는데 결과는 분쟁이다.
이 실패는 시험 단계에서 생긴 것이 아니다. 시험을 시작하기 전, 범위를 합의하는 단계에서 이미 결정되어 있었다. 그래서 이 모듈의 첫 레슨이 문서 작성법이 아니라 범위 정의인 것이다.
포함 범위보다 제외 범위가 어렵다
시험 계획서를 처음 써 보는 사람은 대개 "무엇을 시험할 것인가"를 열심히 적는다. 그 목록은 길고 구체적이다. 그런데 정작 분쟁을 막는 것은 그 목록이 아니라 그 옆에 있어야 할 짧은 목록이다.
[포함 범위] [제외 범위]
- 이메일/비밀번호 정상 인증 - 소셜 로그인(카카오·네이버) 연동
- 비밀번호 5회 오입력 시 계정 잠금 - 비밀번호 재설정 메일 발송 경로
- 동시 세션 1개 제한 - 외부 SMS 인증 사업자 구간
- 모바일 앱 클라이언트왼쪽만 있는 계획서와 양쪽이 다 있는 계획서의 차이는 크다. 왼쪽만 있으면 "목록에 없으니 안 한 것"이라는 해석과 "당연히 포함되는 줄 알았다"는 해석이 충돌한다. 오른쪽이 있으면 충돌할 여지가 없다. 제외 범위는 시험기관을 보호하는 장치처럼 보이지만, 실제로는 의뢰인을 더 많이 보호한다. 의뢰인은 그 목록을 보고 "어, 소셜 로그인도 필요한데"라고 말할 기회를 시험 전에 갖게 되기 때문이다.
제외 범위를 적을 때 흔히 나오는 저항이 있다. "제외를 많이 적으면 성적서가 빈약해 보이지 않나?" 정반대다. 제외가 명시된 성적서는 시험자가 대상의 경계를 이해하고 있었다는 증거 로 읽힌다. 제외가 하나도 없는 성적서가 오히려 "무엇을 안 봤는지 본인도 모른다"는 인상을 준다.
제외 범위를 뽑아내는 네 가지 질문
막상 앉으면 제외 범위가 잘 떠오르지 않는다. 다음 네 질문을 순서대로 던지면 대개 목록이 채워진다.
| 질문 | 전형적인 제외 항목 |
|---|---|
| 경계 밖에 무엇이 붙어 있는가 | 외부 결제 PG, SMS·메일 발송 사업자, 소셜 로그인 제공자, 공공 API |
| 어떤 구성을 못 갖췄는가 | 이중화 구성, 실 운영 규모 데이터, 특정 OS·브라우저 버전, 실제 결제 승인 |
| 어떤 품질 특성을 안 보는가 | 보안성, 접근성, 장기 신뢰성(내구 시험), 이식성 |
| 어떤 조건을 재현 못 하는가 | 실제 트래픽 패턴, 장애 상황, 네트워크 열화, 다국어 환경 |
특히 첫 줄이 중요하다. 소프트웨어 시험에서 시스템 경계(boundary)를 어디로 그을 것인가 는 거의 모든 제외 범위의 출발점이다. 외부 PG사가 느려서 결제 응답이 3초 걸렸다면 그것은 시험 대상 제품의 결함인가? 경계를 미리 긋지 않으면 이 질문에 답할 근거가 없다.
범위를 좁게 적는 것이 정직하고 동시에 유리하다
제외 범위가 익숙해지면 다음 단계가 보인다. 포함 범위 자체를 좁게 적는 것 이다. 넓게 적은 성적서가 더 많은 일을 한 것처럼 보이므로 처음에는 이것이 소극적으로 느껴진다. 읽는 쪽의 시선으로 보면 반대다.
| 범위 칸에 적힌 것 | 읽는 쪽이 받아들이는 주장 | 사고가 났을 때 |
|---|---|---|
| 로그인 기능 | 로그인에 관한 모든 것 | 소셜 로그인 장애도 범위 안으로 끌려온다 |
| 이메일·비밀번호 정상 인증, 5회 실패 시 잠금 | 그 두 흐름 | 나머지가 범위 밖임을 문서로 보일 수 있다 |
성적서는 주장하는 문서 이고, 주장의 면적이 그대로 방어할 면적이 된다. 넓게 적으면 보지 않은 것까지 봤다고 말한 셈이므로, 넓은 범위는 능력의 증명이 아니라 거짓의 가능성과 책임의 확대 다. 의뢰인에게도 좁은 기술이 낫다 — 경계가 선명하면 "그럼 업로드 쪽은 누가 보나" 라는 질문이 검수장이 아니라 시험 전에 나온다.
ISO/IEC 17025:2017 의 결과 보고 조항(7.8)에는 보고서가 담아야 할 정보 목록이 있고, 2차 자료들이 공통으로 가리키는 항목 중 셋이 이 레슨과 맞닿는다 — 대상의 모호하지 않은 식별, 사용한 방법과 그 방법에서의 추가·이탈·제외, 결과는 시험된 대상에만 적용된다는 문구 다. 셋째가 이 레슨의 주제를 표준의 언어로 되풀이한 것이다. 조항 번호와 문구는 원문과 소관 인정기구 규정으로 확인한다.
시험 계획서는 의뢰서와 다른 문서다
여기서 용어를 정리하고 가자. 실무에서 세 문서가 자주 뒤섞인다.
| 문서 | 누가 쓰는가 | 무엇을 담는가 |
|---|---|---|
| 시험의뢰서 | 의뢰인 | 시험받고 싶은 대상과 목적, 희망 항목, 납기 |
| 시험 계획서 | 시험기관(QA) | 실제로 수행할 범위·방법·환경·판정 기준·일정 |
| 시험성적서 | 시험기관 | 계획대로 수행한 결과와 판정 |
셋 중 힘이 가장 센 문서는 가운데다. 의뢰서는 희망이고, 성적서는 결과이며, 계획서만이 "무엇을 하기로 합의했는가"를 담는다. 그래서 분쟁이 나면 법무팀이 가장 먼저 찾는 문서도 계획서다. 계획서를 생략하고 의뢰서에서 바로 시험으로 넘어가는 관행이 위험한 이유가 여기에 있다.
ISO/IEC 17025는 이 단계를 절차로 요구한다
공인시험기관이 되려면 통과해야 하는 ISO/IEC 17025:2017에는 이 활동이 독립된 조항으로 들어가 있다. 7.1 의뢰·입찰·계약의 검토(Review of requests, tenders and contracts) 다. 요구 내용은 대략 이렇다.
- 요구사항이 정의되고 문서화되고 이해되었는가
- 시험소가 그 요구를 충족할 역량과 자원 을 갖고 있는가
- 선택한 시험 방법이 적절하고 고객의 필요를 만족시킬 수 있는가
- 요구와 계약 사이에 차이가 있으면 시험 시작 전에 해소 되었는가
세 번째 줄을 눈여겨볼 만하다. 의뢰인이 "이 방법으로 해 달라"고 지정해도, 그 방법이 목적에 부적절하면 시험소는 그 사실을 알려야 한다. 요청을 그대로 수행하고 나중에 "시키는 대로 했다"고 말하는 것은 이 조항 아래서는 허용되지 않는다. 시험소도 판단 주체라는 뜻이다.
ISO/IEC 17025 인정을 받지 않은 조직이라도 이 네 줄은 그대로 쓸 값이 있다. 사내 QA가 다른 팀의 검증 요청을 받을 때 던져야 할 질문과 정확히 같기 때문이다.
성적서를 전제로 한 계획서에는 추가로 들어가는 것
일반적인 테스트 계획서(모듈 4에서 다룬 그것)와 성적서 발급을 전제로 한 시험 계획서는 겹치지만 같지 않다. ISO/IEC/IEEE 29119-3의 시험 계획 항목을 기준으로 보면, 성적서 맥락에서 비중이 크게 달라지는 항목 이 있다.
| 항목 | 사내 테스트 계획 | 성적서용 시험 계획 |
|---|---|---|
| 시험 대상 식별 | 빌드 번호 정도 | 제품명·버전·빌드 해시·수령일까지 고유 식별 |
| 제외 범위 | 있으면 좋음 | 필수. 계약 문서 성격을 갖는다 |
| 시험 방법 | 팀이 아는 방식 | 근거 규격 또는 합의된 절차를 명시 |
| 판정 기준 | 회의에서 구두 합의 | 수치와 판정 규칙을 사전 문서화 |
| 환경 | "스테이징" | 재현 가능한 수준의 구성 기재 |
| 종료 조건 | 스프린트 종료 | 시험 항목 전수 수행 또는 중단 조건 |
| 변경 관리 | 슬랙에서 조정 | 계획 변경 시 의뢰인 승인 이력 |
가장 큰 차이는 마지막 줄이다. 사내 테스트는 상황에 맞춰 범위를 줄이거나 늘려도 문제가 없다. 성적서용 시험은 계획을 바꾸는 순간 그 사실이 기록에 남아야 한다. 시험 도중 "이 항목은 환경이 안 되어 못 하겠다"는 상황은 흔한데, 그때 조용히 빼는 것과 의뢰인 확인을 받고 계획서를 개정하는 것의 차이가 나중에 전부다.
대상 식별 — 같은 제품이 아닐 수 있다
범위 정의에서 빠뜨리기 쉬운 것이 "무엇을" 쪽이다. 항목 목록에 집중하다 보면 정작 시험 대상 자체의 식별이 허술해진다.
나쁜 예: 대상 — OO페이 v2.1
좋은 예: 대상 — OO페이 서버 v2.1.4 (빌드 2026-08-30, 커밋 a3f91c2)
클라이언트 Android 2.1.0 (버전코드 214)
수령일 2026-09-01 / 전달 방식 인수인계 USB왜 이렇게까지 적는가? 시험이 끝난 뒤 의뢰인이 제품을 고치기 때문이다. 두 달 뒤 문제가 생겨 "성적서에는 적합이라고 되어 있는데요"라는 말이 나올 때, 위쪽 기재로는 그것이 같은 물건인지 증명할 수 없다. 아래쪽 기재로는 30초면 끝난다. 성적서는 시점을 박제한 문서 이고, 박제 대상이 무엇이었는지가 흐릿하면 문서 전체가 흐릿해진다.
범위 협의를 기록으로 남기는 실무
범위는 한 번에 정해지지 않는다. 대개 이런 흐름을 탄다.
의뢰 접수
↓
1차 범위 초안 (시험기관 작성)
↓
의뢰인 검토 → "소셜 로그인도 넣어주세요"
↓
역량·일정·비용 재검토 → 가능/불가 회신
↓
범위 확정 → 계획서 서명 또는 메일 승인
↓
시험 착수이 과정에서 반드시 남겨야 할 것은 거절한 항목과 그 이유 다. "소셜 로그인은 외부 제공자 구간이라 재현이 불가해 제외하기로 협의함(2026-09-03 메일)"이라는 한 줄이 계획서에 있으면, 나중에 그 항목이 문제가 되어도 논의는 "왜 안 했느냐"가 아니라 "그때 그렇게 합의했다"에서 시작한다.
말로 한 합의는 기억으로만 남고, 기억은 분쟁에서 항상 두 갈래로 갈린다.
범위는 견적이다 — 그래서 확장 요청에는 가격표로 답한다
범위 협의가 길어지는 이유는 기술적 난이도가 아니다. 범위가 곧 금액과 날짜 라서다. 문장으로 적은 범위("성능 전반을 시험한다")는 공수가 계산되지 않아 견적이 감으로 나가고, 조합으로 적은 범위는 견적이 저절로 나온다.
트랜잭션 4종 × 부하 3단 × 반복 3회 = 36회
환경 2구성(단일·이중화) = 72회 × 30분 = 36시간
+ 환경 구축 8시간 + 보고서 16시간 = 60시간조합으로 적으면 견적과 일정의 근거가 생기고, 더 자주 쓰이는 세 번째가 남는다 — 범위가 바뀔 때 차액을 계산할 단위 다.
그 단위가 있으면 시험 중반의 "이것도 좀 같이 봐 주세요" 에 답할 수 있다. 여기서 가장 비싼 선택은 구두로 수락하는 것 이다. 구두로 받은 항목은 계획서에도 견적에도 없어 성적서 안에서 근거 없는 줄이 된다. 거절도 답이 아니다. 쓸 수 있는 답은 하나뿐이다 — 가능하다고 말하고 조건을 문서로 보낸다.
요청 항목 50MB 첨부 업로드 응답시간 측정
가능 여부 가능
추가 범위 1종 × 3단 × 3회 = 9회 (측정 4시간 + 보고 2시간)
추가 일정 납기 +1 영업일 / 추가 비용 변경 견적서 별첨
처리 방법 승인 회신 시 계획서 rev.2 로 반영하고 변경 이력에 기재
미승인 시 제외 범위에 "의뢰인 미요청" 사유로 기재이 회신의 효과는 금액보다 기준선 에 있다. 가격표가 붙는다는 사실이 한 번 확인되면 그 뒤의 요청은 처음부터 일정과 함께 들어온다. 무상으로 끼워 넣으면 그것이 다음 의뢰의 출발점이 된다. 마지막 줄도 버리지 않는다 — 승인되지 않은 요청도 기록으로 남긴다. 기관에 맡기는 구간이 있으면 범위 확정일이 일정의 기점이 되고, 그 역산은 모듈 28 레슨 1에서 다룬다.
범위가 중간에 바뀌면 — 변경을 기록하는 모양
범위는 시험이 시작된 뒤에도 바뀐다. 필요한 것은 판단력이 아니라 계획서 앞장에 고정해 둔 표 한 개 다. 아래는 초판 뒤의 발췌다.
| rev | 일자 | 변경 내용 | 사유 | 요청·승인 | 반영 위치 |
|---|---|---|---|---|---|
| 2 | 09-11 | 업로드 응답시간 1종 추가 | 의뢰인 요청 | 메일 승인 09-12 | 3항 포함 범위 |
| 3 | 09-18 | 이중화 구성 측정 미수행 | 장비 미확보 | 시험기관 통보·확인 09-18 | 7항·결과 표 |
마지막 행이 가장 조심할 유형이다. 환경이 안 되어 못 한 항목을 제외 범위로 옮기는 것 이 흔한데, 이는 사실과 다른 문서를 만든다. 제외는 시험 전에 합의한 경계이고, 미수행은 시험 중에 생긴 사실 이다. 미수행으로 남긴 성적서는 덜 깔끔해 보이지만 그 한 줄이 "계획대로 수행했다" 는 전제를 지킨다.
사례 — 제외 칸을 비워 둔 성적서가 검수에서 반려된 일
전자문서 유통 솔루션의 성능 시험이었다. 의뢰서에는 "동시사용자 300명에서 응답시간 2초 이내임을 증명" 한 줄이 있었다. 계획서의 포함 범위에는 "문서 조회·등록 2개 트랜잭션" 이 적혔고 제외 범위 칸은 비어 있었다. 대상은 "DocHub v3.2" 로만 적혔다.
시험은 순조로웠다. 조회 0.8초, 등록 1.4초, 판정 적합. 문제는 성적서를 제출한 2주 뒤 발주처 검수에서 세 가지로 왔다.
| 지적 | 왜 막지 못했는가 |
|---|---|
| 50MB 첨부 업로드가 시험되지 않았다 | 제외 칸이 비어 있어 포함된 것으로 읽혔다 |
| 납품 빌드는 v3.2.7인데 대상은 v3.2 | 버전만 적어 같은 물건임을 증명할 수 없었다 |
| 검수자는 300을 동시 요청으로 계산했다 | 용어 정의가 없었다. 그 기준이면 2.9초다 |
재시험에 2주, 약 50시간이 다시 들었다. 세 가지 모두 시험 기술이 아니라 계획서에서 비워 둔 칸의 문제였다. 그 뒤로 1페이지 양식에 네 칸을 고정했다.
제외 범위 항목 + 사유. 없으면 "없음" 을 적고 함께 서명한다
대상 식별 제품명·버전·빌드·커밋·수령일·전달 방식
용어 정의 동시사용자 = 세션을 유지한 사용자 수(요청 수가 아니다) 등
변경 이력 rev·일자·사유·요청자·승인이후 같은 조직의 성적서 3건에 범위 관련 보완 요청은 없었다. 접수부터 계획서 서명까지는 평균 4일에서 6일로 늘었다 — 2일을 더 쓰고 2주를 사지 않은 것 이다.
- 빈 칸과 "없음" 은 다른 문서다. 비워 두면 읽는 쪽이 자기 기대로 채운다
- 버전은 범위가 아니다. 빌드가 범위다. 박제 대상이 특정되지 않으면 그 성적서는 어느 것에도 적용되지 않는다
- 정의 없는 숫자는 두 값으로 읽힌다. 분모와 단위를 같은 문서에 적는다(모듈 30 레슨 5)
실무에서 왜 필요한가
범위 정의가 실무에서 돈으로 환산되는 지점은 세 군데다.
첫째, 재시험 비용이다. 범위가 모호한 채로 시험이 끝나면 의뢰인이 빠진 항목을 발견하는 시점은 대개 시험 종료 후다. 추가 시험은 새 의뢰이고, 새 비용과 새 일정이 붙는다. 계획서 단계에서 30분 더 쓰는 것과 2주를 다시 쓰는 것 사이의 교환이다.
둘째, 성적서의 활용 가능성이다. 발주처가 요구하는 증빙 조건과 성적서의 범위가 어긋나면 그 성적서는 목적을 달성하지 못한다. 모듈 25에서 봤듯이 공고문은 "성능 증빙"이라고만 적혀 있고, 그 안에서 무엇을 어떻게 재야 하는지는 읽는 사람이 해석해야 한다. 의뢰 단계에서 "이 성적서를 어디에 제출하실 겁니까"를 묻지 않으면 범위가 목적과 어긋날 확률이 높다.
셋째, 시험기관의 책임 한계다. 제품이 나중에 사고를 냈을 때 "공인시험을 통과한 제품인데 왜 문제가 생겼느냐"는 질문이 시험기관으로 향할 수 있다. 이때 방어선은 성적서에 적힌 범위 문구 하나다. 범위 밖의 사건이었음을 문서로 보일 수 있느냐가 전부다.
사내 QA에게도 그대로 적용된다. 다른 팀이 "이 기능 검증 좀 해주세요"라고 요청할 때 범위를 문서로 좁혀두는 습관은, 나중에 "QA가 봤는데 왜 못 잡았냐"는 질문 앞에서 QA를 지킨다. 이것은 방어적 태도가 아니라 검증 범위를 서로 알고 있어야 리스크를 관리할 수 있다 는 원칙의 실행이다.
채용시장에서의 위치
시험기관 시험원 채용에서 실제로 평가되는 것은 "테스트를 잘하는가"보다 "의뢰인과 범위를 합의해본 적이 있는가"다. 시험 수행 자체는 절차서가 있으면 따라갈 수 있지만, 의뢰인의 모호한 요구를 시험 가능한 항목으로 번역하고 못 하는 것을 못 한다고 말하는 일은 경험이 필요하다.
면접에서 힘을 갖는 답변은 대개 이런 형태다. "의뢰서에 '결제 성능 시험' 이라고만 적혀 있어, 외부 PG 구간이 포함되는지부터 확인했습니다. PG사 응답을 제외한 자사 서버 구간만 측정하기로 범위를 좁히고 그 근거를 계획서에 명시했습니다. 시험 후 PG 지연으로 민원이 들어왔을 때 그 문구가 경계를 설명해줬습니다."
발주처·SI 쪽 품질 담당 자리에서는 반대 방향의 능력이 평가된다. 받은 성적서를 보고 그 범위가 우리가 필요한 증빙을 덮는지 판정하는 능력 이다. 성적서를 읽을 때 결과 칸이 아니라 범위 칸부터 보는 사람은 그 자체로 경력자의 표시다.
| 질문 | 약한 답 | 강한 답 |
|---|---|---|
| "시험 범위는 누가 정하나요?" | "의뢰인이 요청한 대로 합니다" | "의뢰인은 목적을 주고 범위는 제가 적습니다. 요청을 시험 가능한 항목으로 번역하고, 못 하는 것은 사유와 함께 제외에 적습니다" |
| "제외를 많이 적으면 성적서가 빈약해 보이지 않나요?" | "그래서 보통 포함만 적습니다" | "제외가 없으면 전부 봤다고 읽힙니다. 좁게 적는 쪽이 정직하고 책임 면적도 좁습니다" |
| "시험 대상은 어떻게 적으세요?" | "제품명과 버전을 적습니다" | "빌드·커밋·수령일까지 적습니다. 버전만 적으면 납품 빌드와 같은 물건인지 증명할 수 없습니다" |
| "항목 하나만 더 봐 달라는 요청이 오면요?" | "범위 밖이라 거절합니다" | "가능하다고 답하고 추가 조합 수·일정·비용을 메일로 보냅니다. 승인 뒤 계획서를 개정합니다. 거절이 아니라 가격표입니다" |
| "환경이 안 되어 못 한 항목은요?" | "제외 범위로 옮깁니다" | "제외는 사전 합의고 미수행은 사후 사실입니다. 사유와 함께 미수행으로 남기고, 제외로 옮기려면 승인 이력이 필요합니다" |
다섯 번째가 가장 변별력이 크다. 제외와 미수행을 구분하는 답은 성적서를 한 번이라도 방어해 본 사람 에게서만 나온다. 이어지는 질문도 정해져 있다 — "그러면 성적서에는 어떻게 적습니까." 결과 표의 미수행 표기와 범위 칸의 제외 목록을 따로 말할 수 있으면 대화가 끝난다.
네 번째도 좋다. 거절과 수락 사이에 조건 이라는 세 번째 답이 있음을 아는지가 보이고, 이것은 발주처 쪽 면접에서도 값이 매겨진다. 공고 표현으로는 "시험성적서 작성", "검수 대응" 이 이 레슨에 걸린다.