개념
변동 폭은 한 군데서 나온다
레슨 1의 총 기간 산정식을 다시 보자.
총 기간 = 접수 대기 + 시험 수행 + (보완 기간 × 결함 라운드 수) + 심의·발급
└──────── 변동 폭의 거의 전부 ────────┘대기와 시험 기간은 기관이 산정해 알려 준다. 심의 주기도 정해져 있다. 예측이 안 되는 항은 결함 라운드뿐 이고, 그래서 인증 일정을 지키는 일은 사실상 "라운드를 몇 번에 끝낼 것인가"의 문제다.
라운드 한 번의 비용을 감각으로 잡아 두면 판단이 쉬워진다. 결함 리포트를 받아 분석하고, 수정하고, 검증하고, 다시 제출하고, 회귀시험을 기다리는 왕복이다. 수정이 하루에 끝나는 결함이라도 이 왕복 자체가 2~4주를 만든다. 라운드 두 번이면 한 달 이상 이라는 계산이 여기서 나온다.
시험 기간 중 발견된 결함에는 보완 기회가 주어지고, 수정본에 대해 회귀시험이 수행된다. 제도는 라운드를 전제로 설계되어 있다는 뜻이다. 문제는 그 라운드가 몇 번 도느냐다.
결함 리포트를 받은 첫날 — 분류가 먼저다
리포트를 받으면 바로 고치기 시작하는 것이 가장 흔한 실수다. 지적 사항은 성격이 서로 다르고, 성격에 따라 대응 경로가 완전히 다르다.
| 유형 | 무엇인가 | 대응 |
|---|---|---|
| A. 실제 결함 | 사양대로 동작하지 않는다 | 수정 |
| B. 사양 문제 | 제품설명서 문장이 과했다 | 문서 수정을 협의 |
| C. 해석 차이 | 문장을 다르게 읽었다 | 근거를 들어 협의 |
| D. 환경 문제 | 시험 환경 구성에서 비롯됐다 | 환경 조건 확인·재현 요청 |
| E. 사실 확인 필요 | 우리 쪽에서 재현되지 않는다 | 재현 조건 요청 |
B가 가장 자주 과소평가된다. 레슨 3에서 "적은 수치가 합격 기준으로 돌아온다" 고 한 그 결과가 여기서 나타난다. 이때 선택지는 둘이다 — 제품을 설명서에 맞추거나, 설명서를 제품에 맞추거나. 후자가 가능한 경우가 있고, 그 협의를 놓치면 불필요한 개발이 들어간다.
다만 설명서 수정은 공짜가 아니다. 문서를 고치면 그 문서를 기준으로 이미 수행된 시험 항목이 영향을 받고, 변경 범위가 크면 일정이 되돌아간다. "줄이는 방향"의 수정이 협의 가능성이 높고, 조건을 붙이는 수정이 그다음 이다.
C는 감정적으로 다루기 쉬운 유형이다. 원칙은 하나다 — 문장을 근거로 말한다. "그런 의도가 아니었다"는 통하지 않고, "제품설명서 3.2절에 이렇게 적혀 있고, 그 문장의 범위는 이러하다"는 통한다. 그래서 레슨 3의 문서 작업이 이 협의의 탄약이 된다.
E는 반드시 짚어야 한다. 재현되지 않는 지적을 추측으로 고치면, 고치지 않아도 될 곳을 건드려 새 결함을 만든다. 재현 조건을 요청하는 것은 정당한 절차이며, 모듈 6에서 다룬 결함 리포트의 재현성 요구가 방향만 바뀐 것이다.
수정 범위 통제 — 라운드를 늘리는 진짜 원인
라운드가 두 번, 세 번으로 늘어나는 회사에는 공통점이 있다. 결함을 고치는 김에 다른 것도 고친다.
지적된 결함 3건
+ 코드를 열어 보니 눈에 걸리는 리팩터링 2건
+ 마침 대기 중이던 기능 개선 1건
+ 라이브러리 버전 업 1건
= 재시험 범위가 지적 3건이 아니라 제품 전반이 된다이 유혹은 강하다. 어차피 재시험을 받으니 함께 넣는 것이 효율적으로 보인다. 결과는 반대다. 변경 범위가 넓어지면 회귀시험 범위도 넓어지고, 새 변경에서 새 결함이 나와 라운드가 한 번 더 돈다. 그리고 그 변경은 변경인증 판단에도 영향을 준다(레슨 6).
그래서 인증 기간에는 규칙을 못 박아 두는 편이 낫다.
| 허용 | 금지 |
|---|---|
| 지적된 결함의 최소 수정 | 리팩터링 |
| 문서 수정(협의된 범위) | 기능 추가·개선 |
| 지적과 같은 원인의 다른 건(전수) | 의존성 버전 업 |
| 협의된 환경 설정 변경 | UI 개편 |
세 번째 줄은 예외적으로 허용해야 한다. 같은 원인의 다른 건을 남겨 두면 다음 라운드에서 같은 유형이 다시 지적된다 — 모듈 32 레슨 5의 전수 조사와 같은 원리다. 지적된 것만 고치는 것도, 눈에 보이는 것을 다 고치는 것도 답이 아니고, 원인 단위로 고치는 것 이 답이다.
버전을 고정하는 것
인증 기간 중 제품 버전 관리는 별도의 규율이 필요하다. 개발이 평소처럼 main 브랜치로 계속 흘러가면, 재시험에 제출할 빌드를 특정할 수 없게 된다.
인증용 브랜치를 끊는다 cert/1.4.0 ← 신청 시점 고정
지적 수정만 이 브랜치에 cherry-pick 로 최소 반영
빌드 산출물에 해시 기록 어느 커밋의 빌드인지 남긴다
제출 이력 대장에 버전 표기 라운드별로 어느 빌드를 냈는가
개발 본류는 따로 흐른다 인증 후 병합이 작업이 귀찮아 보이면, 반대 상황을 떠올려 보면 된다. 재시험에서 "제출된 빌드가 이전과 무엇이 다른지 설명해 주십시오"라는 요청을 받았을 때, 커밋 범위를 답할 수 없는 상태. 모듈 9에서 다룬 Git 활용(브랜치 전략, 태그 diff로 회귀 범위 확인)이 여기서 그대로 쓰인다.
재시험 범위는 협의 대상이다
회귀시험 범위는 자동으로 정해지는 것이 아니라 수정의 영향 범위 를 보고 정해진다. 그리고 그 영향 범위를 가장 잘 아는 쪽은 우리다.
그래서 수정본을 낼 때 함께 제출하면 좋은 것이 영향 분석서 다.
| 지적 ID | 수정 내용 | 변경 파일·모듈 | 영향 가능 기능 | 자체 회귀 결과 |
| D-014 | 권한 검사 누락 보완 | auth/policy | 사용자 관리 전반, 감사 로그 | 42건 통과 |
| D-015 | CSV 인코딩 고정 | export/csv | 내보내기 3종 | 9건 통과 |이 문서가 있으면 협의가 "전체를 다시 봐야 하나"에서 "이 범위면 되겠다"로 바뀐다. 없으면 보수적으로 넓게 잡히고, 넓어진 범위는 기간으로 돌아온다. 자체 회귀 결과를 붙이는 것 이 특히 효과가 크다 — 우리가 이미 확인했다는 증거가 되기 때문이다.
기한 관리 — 못 맞출 것 같으면 먼저 말한다
서류 보완에는 고시상 기한이 있다(15일, 1회 최대 15일 연장). 시험 중 결함 보완 기간은 기관과의 협의로 정해지는데, 어느 쪽이든 원칙은 같다.
기한을 넘기는 것보다 넘길 것 같다고 미리 알리는 것 이 언제나 낫다.
모듈 32 레슨 5에서 KOLAS 부적합의 시정조치 결과를 기한 내 미보고하는 것이 원래 지적보다 무거운 '중대한 사항'으로 분류된다고 했다. 인증 절차도 성격이 같다. 침묵은 상대의 선택지를 없애고, 사전 통지는 일정 재협의라는 선택지를 남긴다.
수정에 시간이 걸리는 유형은 대개 예측 가능하다.
| 유형 | 예상 소요 | 미리 알릴 것 |
|---|---|---|
| 표시·문구·문서 | 1~2일 | – |
| 로직 오류 | 3~5일 | – |
| 권한·인증 구조 | 1~2주 | 알린다 |
| 성능 미달 | 2주 이상 | 반드시 알린다. 설명서 수정 협의도 함께 |
| 아키텍처 변경이 필요한 사항 | 예측 불가 | 즉시. 라운드 포기·재신청 판단까지 |
마지막 줄은 드물지만 존재한다. 이때 손실을 줄이는 판단은 "이번 라운드에 어떻게든 끼워 넣는 것"이 아니라 일정과 등급을 다시 검토하는 것이다.
라운드 0 — 신청 전에 우리가 먼저 찾는다
라운드를 한 번에 끝내는 유일한 방법은 기관이 찾을 것을 우리가 먼저 찾는 것 이다. 인증 준비의 자체 시험을 '라운드 0'으로 부르면 위치가 분명해진다.
신청 전 자체 시험에서 발견율이 높은 영역은 반복된다.
1. 문서 불일치 제품설명서·사용자설명서·실제 동작의 삼자 대조 (레슨 3)
2. 설치·제거 깨끗한 환경에서 문서만 보고 (레슨 3 과제 3)
3. 권한 경계 역할별로 접근 가능/불가 전수
4. 경계값·입력 검증 길이·형식·특수문자·빈값 (모듈 3)
5. 오류 처리 실패 시 메시지·복구·로그
6. 환경 조합 지원 환경에서 기동과 핵심 흐름 (레슨 4)
7. 성능 수치 설명서 기재값 대비 마진 확인 (레슨 4)1번과 2번이 비용 대비 발견율이 가장 높다. 도구도 필요 없고, 하루면 된다. 그런데 이 둘을 건너뛴 상태로 신청해 결함 라운드에서 문서 지적을 받는 경우가 실제로 가장 많다.
한 라운드의 표준 작업 순서
라운드를 운영하는 순서를 정해 두면 사람이 바뀌어도 같은 속도가 나온다.
1. 접수 리포트를 결함 대장에 등재. 기관 ID ↔ 우리 이슈 ID 연결
2. 분류 A~E 유형 판정. C·E는 즉시 협의·질의
3. 영향 분석 수정 범위와 영향 기능 식별
4. 일정 회신 언제까지 무엇을 낼지 회신 (못 맞추면 이 단계에서 알린다)
5. 수정 인증 브랜치에 최소 수정. 원인 단위 전수 반영
6. 자체 회귀 영향 기능 재시험. 결과를 기록
7. 제출 수정본 + 영향 분석서 + 자체 회귀 결과
8. 정리 결함 대장 마감. 유형별 원인을 다음 제품에 남긴다8번이 조직의 학습이 일어나는 자리다. 결함 유형을 남겨 두면 다음 제품, 다음 변경인증에서 라운드 0의 체크리스트가 두꺼워진다.
실무에서 왜 필요한가
이 레슨의 내용은 인증 밖으로 그대로 옮겨진다. 외부 감사, 고객사 수락 테스트(UAT), 플랫폼 심사, 보안 점검 — 전부 외부가 지적하고 우리가 고치고 다시 보는 왕복 구조다. 왕복 횟수가 일정을 결정하고, 왕복을 줄이는 수단은 항상 같다. 미리 찾고, 범위를 통제하고, 근거를 붙여 낸다.
특히 수정 범위 통제는 조직 문화와 부딪히는 지점이라 미리 합의가 필요하다. 개발자에게 "이것만 고치고 나머지는 참으라"고 말하는 근거가 "회귀 범위가 넓어지면 라운드가 늘고, 라운드 하나가 2~4주"라는 계산이다. 계산 없이 말하면 통하지 않는다.
발주처·SI 쪽에서 인증서를 검토하는 사람에게도 쓸모가 있다. 인증 과정에서 결함이 있었는지, 어떤 버전으로 최종 통과했는지를 물을 수 있다. 인증서에 적힌 버전과 납품 버전이 다르면 그 사이 변경이 변경인증 대상이었는지가 질문이 된다(레슨 6).
채용시장에서의 위치
라운드 운영은 인증 담당 QA의 실질적인 업무 시간 대부분을 차지한다. 공고에 "인증 대응"으로 뭉개져 적히지만, 실제로 평가되는 것은 일정을 지켰는가 다. 그리고 일정을 지킨 사람은 거의 항상 라운드를 적게 돈 사람이다.
이 경험은 릴리스 관리·품질 게이트 운영으로도 이어진다. 영향 분석서를 쓸 수 있고, 버전을 고정해 관리할 수 있고, 회귀 범위를 근거로 협의할 수 있는 사람은 사내 릴리스에서도 같은 일을 한다.
면접에서 힘 있는 답변의 형태는 이렇다. "결함 리포트 11건을 유형으로 나눴더니 실제 결함은 4건이고, 5건은 설명서 문장이 과한 것, 2건은 재현 불가였습니다. 설명서 수정으로 5건을 협의 처리하고 재현 조건을 받아 2건을 정리했습니다. 수정은 인증 브랜치에 4건만 반영하고 영향 분석서와 자체 회귀 결과를 함께 냈습니다. 회귀 범위가 좁게 잡혀 라운드가 한 번에 끝났습니다."