개념
읽는 쪽에서 쓰는 쪽으로
모듈 25 레슨 3에서 25051 계열의 발상을 봤다. 검증 대상이 셋 — 제품 설명서, 사용자 문서, 프로그램과 데이터 — 이고 규격은 이 셋 사이의 일치 를 요구한다는 것. 그래서 카탈로그에 "엑셀 내보내기 지원"이라고 적혀 있으면 시험원은 그 문장을 근거로 엑셀 내보내기를 시도한다는 것.
그 레슨은 이 발상을 테스트 설계의 입력 으로 썼다. 문서를 읽고 테스트 케이스를 만드는 관점이다. 이 레슨은 반대쪽에 선다. 그 문서를 직접 쓰는 사람이 무엇을 조심해야 하는가.
두 관점의 차이는 생각보다 크다. 검증할 때는 "이 문장이 사실인가"를 묻지만, 쓸 때는 "이 문장을 적으면 무엇을 증명해야 하는가" 를 먼저 계산해야 한다. 후자를 못 하면 스스로 시험 범위를 넓혀 놓고 결함 라운드를 두 번 돌게 된다.
제출물 세 종류와 각각의 역할
고시가 신청 시 첨부를 요구하는 문서는 셋이다.
| 문서 | 누구를 향한 문서인가 | 시험에서의 역할 |
|---|---|---|
| 제품설명서 | 구매자·도입 검토자 | 사양서. 여기 적힌 것이 합격 기준이 된다 |
| 사용자취급설명서 | 실제 사용자·운영자 | 설치·운영·사용 절차의 재현 가능성 |
| 업무적합성 기술서 | 공공 업무 담당자 | 2등급만. 업무 적합성 평가(40%)의 근거 |
세 문서의 독자가 다르다는 점이 작성 규칙을 가른다. 제품설명서는 "무엇을 하는 제품인가"에 답하고, 사용자취급설명서는 "어떻게 쓰는가"에 답한다. 이 둘을 한 문서로 합쳐 제출하려는 시도는 대개 실패한다 — 사양은 모호해지고 절차는 빠진다.
여기에 실무에서 함께 준비하는 문서가 둘 더 있다. 기능 목록 과 시험 요구사항 이다. 고시가 첨부로 요구하는 것은 아니지만, 시험 준비·협의 단계(레슨 1의 4단계)에서 사실상 필수로 오간다.
제품설명서 — 적은 수치가 기준으로 돌아온다
모듈 25 레슨 3이 경고한 함정이 이것이다. "최대 동시 사용자 수 1,000명" 이라고 낙관적으로 적으면 시험은 실제로 1,000명을 걸어 본다. 이 경고를 작성 규칙으로 바꾸면 네 줄이 된다.
① 실측 없는 수치는 적지 않는다
② 적어야 한다면 실측값보다 보수적으로 적는다
③ 조건을 함께 적는다 — 어느 환경에서, 어떤 부하 모델로
④ 마케팅 문서와 제품설명서를 분리한다④가 조직 문제라 가장 어렵다. 홈페이지와 브로슈어는 마케팅이 쓰고, 그 문장이 그대로 제품설명서에 복사되면서 사고가 난다. 제품설명서는 판촉 문서가 아니라 사양서 라는 것을 관계자에게 설명하는 일이 QA의 몫이 된다.
③은 방어의 핵심이다. 수치를 조건 없이 적으면 최악의 조건에서 검증될 여지가 생긴다.
| 위험한 문장 | 방어된 문장 |
|---|---|
| 최대 동시 사용자 1,000명 | 권장 사양(4코어/8GB, 단일 인스턴스) 기준 동시 사용자 500명에서 평균 응답 2초 이내 |
| 대용량 데이터 처리 지원 | 100만 행 CSV 가져오기 지원(파일 1건 최대 200MB) |
| 모든 브라우저 지원 | Chrome·Edge 최신 2개 버전, Safari 17 이상 지원 |
| 실시간 알림 | 이벤트 발생 후 5초 이내 알림 발송(메일·웹훅) |
오른쪽 열이 좋은 문서인 이유는 자랑이 작아서가 아니다. 검증 가능하고, 검증 범위가 닫혀 있어서 다. "모든 브라우저"는 닫히지 않는 약속이고, "Chrome·Edge 최신 2개 버전"은 닫힌 약속이다.
기능 서술은 동작 단위로, 화면 단위가 아니라
제품설명서의 기능 서술은 그대로 시험 항목의 뼈대가 된다. 그래서 서술 단위가 중요하다.
화면 단위 (나쁨)
- 관리자 페이지: 사용자, 권한, 로그를 관리할 수 있습니다
동작 단위 (좋음)
- 사용자 계정 생성·수정·비활성화
- 역할 기반 권한 부여 및 회수 (역할 5종 사전 정의, 커스텀 역할 생성 가능)
- 로그인·권한 변경 이력 조회 (기간·사용자·행위 유형으로 필터)
- 감사 로그 내보내기 (CSV, 최대 10만 행)동작 단위로 쓰면 문장 수가 늘어난다. 그 점이 부담스러워 화면 단위로 뭉개는 유혹이 생기는데, 뭉갠 문장은 시험 단계에서 시험원이 대신 쪼갠다. 그때의 해석이 우리 의도와 다를 수 있고, 협의 왕복이 늘어난다. 직접 쪼개 두는 편이 언제나 싸다.
반대 방향의 실수도 있다. 구현되지 않은 기능을 로드맵째로 적는 것 이다. "향후 지원 예정"이라고 써 두면 안전하다고 생각하기 쉬운데, 사양서에서 미래 시제는 위험하다. 지금 되는 것만 적고, 로드맵은 다른 문서에 둔다.
사용자취급설명서 — 적힌 대로 따라갈 수 있어야 한다
사용자취급설명서에서 평가되는 것은 문장의 아름다움이 아니라 재현 가능성 이다. 시험원은 이 문서를 들고 설치부터 해 본다. 그래서 자주 걸리는 곳이 정해져 있다.
| 자주 걸리는 곳 | 구체적인 증상 |
|---|---|
| 설치 절차의 생략 | 사전 준비(런타임·권한·포트)가 빠져 그대로 따라가면 실패한다 |
| 화면 이름 불일치 | 메뉴명이 개편됐는데 문서는 구 명칭 |
| 오래된 스크린샷 | 버튼 위치·색이 달라 사용자가 찾지 못한다 |
| 오류 대응 누락 | 실패했을 때 무엇을 보라는 안내가 없다 |
| 관리자·사용자 혼재 | 권한이 다른 작업이 한 절에 섞여 있다 |
| 운영 환경 범위 불명 | 문서가 전제하는 OS·DB 버전이 제품설명서와 다르다 |
마지막 줄이 특히 잦다. 제품설명서에는 "PostgreSQL 14 이상"인데 사용자취급설명서의 설치 절차는 13 기준으로 쓰여 있는 식이다. 세 문서 사이의 일치 를 요구하는 규격에서 이런 불일치는 곧 결함이다.
실무에서 가장 효과가 큰 대비책은 단순하다. 새 장비에서 문서만 보고 설치해 보는 것. 개발 환경이 이미 깔려 있는 노트북에서는 빠진 단계가 드러나지 않는다.
업무적합성 기술서 — 2등급의 40%
2등급을 신청하면 문서가 하나 늘어난다. 업무적합성 기술서는 제품 사양이 아니라 이 제품이 공공 업무에 쓰일 수 있는 형태로 준비되어 있는가 를 설명하는 문서다. 평가 비중이 40%이므로 가볍게 다룰 문서가 아니다.
기술서에서 다루게 되는 축은 대체로 이렇다.
- 업무 적용 범위 어떤 업무에 어떻게 쓰이는가
- 유지보수 체계 계약 형태, 대응 시간, 창구, 버전 지원 정책
- 운영 지원 설치·이관·장애 대응을 누가 어떻게 하는가
- 교육 훈련 도입 기관 담당자 교육 과정과 자료
- 참조 사례 유사 업무에 적용된 이력이 목록을 보면 왜 2등급이 "쉬운 등급"이 아닌지 드러난다. 제품을 잘 만든 것과 유지보수·교육 체계를 문서로 증명하는 것 은 다른 일이다. 회사에 그 체계가 실제로 없으면 문서를 쓸 수 없다.
여기서 QA가 기여할 수 있는 부분은 명확하다. 유지보수 대응 시간과 버전 지원 정책을 적을 때 지킬 수 있는 숫자 를 넣는 것이다. 제품설명서의 성능 수치와 같은 원리다 — 적힌 숫자는 나중에 요구된다.
기능 목록과 시험 요구사항 — 1:1로 맞춘다
제출물은 아니지만 시험 준비 단계에서 반드시 오가는 두 문서다. 관계는 단순하다.
제품설명서의 기능 서술 ─┐
├→ 기능 목록 ─→ 시험 요구사항 ─→ 테스트케이스(기관 작성)
사용자취급설명서의 절차 ─┘여기서 QA가 확보해야 하는 것은 누락 없음 이다. 기능 목록에 없는 기능이 제품에 있으면 시험되지 않은 채 넘어가고(좋은 일이 아니다 — 나중에 변경인증 판단이 어려워진다), 기능 목록에 있는데 제품에 없으면 그대로 결함이 된다.
대조 방법은 모듈 2의 요구사항 추적표와 같다.
| 기능 ID | 제품설명서 문장 | 사용자설명서 절 | 구현 여부 | 자체 시험 결과 | 비고 |이 표를 신청 전에 채워 두는 것이 이 모듈에서 가장 비용 대비 효과가 큰 작업이다. 레슨 1의 총 기간 산정식에서 우리가 통제할 수 있는 유일한 항이 보완 기간과 라운드 수였고, 그 두 항을 줄이는 실질적인 수단이 이 표다.
반송·보완의 대표적 사유
서류 보완은 기한이 정해져 있고(15일, 1회 15일 연장), 일정의 앞을 잡아먹는다. 사유는 대개 몇 가지로 반복된다.
- 제품설명서가 판촉 문서 형태다 — 사양이 아니라 강조 문구로 채워져 있다
- 기능 서술이 화면 단위로 뭉개져 있어 시험 항목으로 쪼갤 수 없다
- 수치에 조건이 없다 — 어떤 환경·부하에서의 값인지 불명
- 제품설명서와 사용자취급설명서의 운영 환경 범위가 다르다
- 사용자취급설명서에 설치 절차가 없거나 사전 준비가 빠져 있다
- 2등급인데 업무적합성 기술서가 사실상 회사 소개서다
전부 신청 전에 자체 점검으로 걸러낼 수 있는 것들이다. 그리고 전부 문서를 읽는 사람의 눈 이 있어야 발견된다 — 쓴 사람은 자기 문서에서 빠진 단계를 보지 못한다.
실무에서 왜 필요한가
인증 준비에서 문서 작업은 "나중에 하면 되는 일"로 밀리기 쉽다. 실제로는 반대다. 모듈 25 레슨 3이 "문서 점검을 마지막이 아니라 가장 먼저 시작하는 편이 낫다" 고 한 이유가 여기서 구체화된다. 제품설명서가 확정되지 않으면 시험 범위가 확정되지 않고, 시험 범위가 확정되지 않으면 견적도 일정도 나오지 않는다.
문서를 먼저 쓰면 부수 효과도 생긴다. 동작 단위로 기능을 나열하는 작업 자체가 제품의 빈틈을 드러낸다. "이 기능은 관리자만 쓸 수 있다고 적어야 하나?"라는 질문에 답이 안 나오는 지점이 곧 권한 설계가 모호한 지점이다.
인증과 무관한 맥락으로 옮겨도 이 작업은 값을 갖는다. 릴리스 노트, 기능 명세, 고객 제안서에 적는 수치가 모두 같은 위험을 갖기 때문이다. 적은 숫자는 언젠가 요구된다 — SLA 협의, 도입 검토, 장애 후 책임 논의에서 그 문장이 돌아온다. 모듈 31 레슨 1의 범위 정의와 레슨 5의 계약 문구가 같은 원리 위에 있다.
채용시장에서의 위치
기술문서 작성 역량은 QA 공고에 잘 드러나지 않지만, 인증·조달 대응 직무에서는 실질적인 선발 기준 이다. 제품설명서를 사양서로 쓸 수 있는 사람은 드물고, 그 역량은 제안서·SLA·계약 부속 문서로 곧 확장된다.
테크니컬 라이터 직군과 겹치지만 방향이 다르다. 라이터는 읽기 쉬움을 최적화하고, 여기서 요구되는 것은 검증 가능성과 범위 통제 다. 두 관점을 모두 갖춘 사람이 인증 문서를 가장 잘 쓴다.
면접에서 힘 있는 답변의 형태는 이렇다. "제품설명서에 '대용량 처리 지원' 같은 문장이 12개 있었습니다. 실측 없이 쓰인 수치도 4개였습니다. 전부 조건이 붙은 검증 가능한 문장으로 바꾸고, 실측값보다 20% 보수적으로 적었습니다. 시험에서 성능 항목 결함이 0건이었고, 영업에는 '설명서 숫자는 보증선이고 실측은 더 높다'는 자료를 따로 만들어 줬습니다."