개념
정의와 실측 사이의 빈칸
모듈 25 레슨 3에서 25023의 측정량을 다뤘다. 품질 특성을 공식·단위·데이터 출처를 갖춘 지표로 바꾸는 일이었고, 지표 하나를 직접 정의하는 연습까지 했다. 모듈 31에서는 그 반대쪽 끝을 다뤘다 — 측정이 끝난 뒤 결과를 성적서에 어떻게 적는지.
그 사이가 비어 있다. 정의된 측정량을 실제로 재는 절차 다.
25023 측정량 정의 → [ 이 레슨 ] → 성적서·제품설명서 수치
(모듈 25 레슨 3) 측정 절차 (모듈 31, 이 모듈 레슨 3)
빈칸에 들어가는 것
무엇을 대상으로 · 어느 환경에서 · 어떤 도구로 · 몇 번 · 어떤 서식에이 빈칸을 채워 두는 이유는 인증 때문만이 아니다. 채워 두지 않으면 기관이 잰 값과 우리가 잰 값이 달라도 왜 다른지 설명할 수 없다. 그 상황이 결함 라운드에서 가장 소모적인 장면이다(레슨 5).
측정 절차서의 일곱 칸
측정량 하나에 대해 채워야 할 칸은 정해져 있다. 서식으로 만들어 두면 측정량이 늘어도 같은 틀로 확장된다.
| 칸 | 무엇을 적나 | 비우면 생기는 일 |
|---|---|---|
| 1. 측정 대상 | 어느 기능·화면·API·트랜잭션 | 시험원과 다른 지점을 잰다 |
| 2. 측정 환경 | 다섯 축(하드웨어·소프트웨어·네트워크·데이터·시점) | 값이 재현되지 않는다 |
| 3. 도구·방법 | 도구와 버전, 설정, 측정 지점 | 도구 차이가 값 차이로 온다 |
| 4. 절차 단계 | 준비 → 실행 → 수집 → 정리 | 사람마다 다르게 잰다 |
| 5. 반복·표본 | 반복 횟수, 워밍업, 제외 구간 | 하루치 운을 능력으로 착각한다 |
| 6. 기록 서식 | 원자료와 집계표의 형태 | 사후 검증이 불가능하다 |
| 7. 판정 | 기준값과 결정 규칙 | "적합"이 의견이 된다 |
2번은 모듈 31 레슨 2의 다섯 축을 그대로 쓴다. 5번은 모듈 32 레슨 3의 반복성·재현성 구분이 그대로 적용된다. 7번은 모듈 31 레슨 3의 결정 규칙이다. 이 레슨의 일은 그 조각들을 하나의 절차서로 묶는 것 이다.
8대 특성을 실제로 어떻게 재는가
GS 시험의 품질평가는 8대 특성으로 구성된다. 특성마다 측정의 성격이 달라서, 같은 절차서 틀에 넣어도 채워지는 내용이 크게 다르다.
| 특성 | 실무에서 재는 형태 | 주의할 점 |
|---|---|---|
| 기능적합성 | 기능 목록 대비 케이스 통과율, 기능 구현 완전성 | 기능 목록이 곧 분모다(레슨 3) |
| 성능효율성 | 응답시간·처리량·자원 사용률 | 백분위로. 평균만 적으면 안 된다 |
| 호환성 | 환경 조합별 동작, 타 시스템 연동 | 조합 폭발 관리가 핵심 |
| 사용성 | 문서·UI 일관성, 도움말·오류 메시지의 적절성 | 주관 평가로 흐르기 쉬워 근거를 남긴다 |
| 신뢰성 | 장시간 안정성, 장애 복구, 결함 밀도 | 측정 기간을 미리 못 박는다 |
| 보안성 | 인증·권한·암호화·로그 | 보유 인증으로 면제 경로가 있다(레슨 1·2) |
| 유지보수성 | 모듈 구조, 로그·설정의 분리, 변경 용이성 | 코드 지표는 도구 버전에 민감하다 |
| 이식성 | 설치·제거·환경 이관, 지원 환경 범위 | 설명서 절차와 일치해야 한다(레슨 3) |
두 줄만 따로 보자.
성능효율성 은 모듈 31 레슨 4가 이미 상세히 다뤘다 — 백분위, 분포, coordinated omission. 여기서 더할 것은 부하 모델을 제품설명서 문장과 맞추는 일 이다. 설명서에 "동시 사용자 500명"이라고 적었다면, 그것이 동시 접속 세션 500인지, 초당 요청 500인지, 활성 사용자 500인지가 정해져야 같은 것을 재게 된다. 이 정의가 없으면 우리 측정과 기관 측정이 3배 차이가 나기도 한다.
사용성 은 가장 많이 흔들리는 항목이다. 주관이 개입하는 만큼 근거를 남기는 방식으로 재야 한다 — 오류 메시지 일람과 각 메시지가 원인·조치를 담고 있는지의 체크, 용어 일관성 목록, 도움말 접근 경로의 존재 여부처럼 세어 셀 수 있는 형태 로 바꾸는 것이다.
호환성 — 조합 폭발을 줄이는 것이 절차 설계다
호환성 측정에서 실무자가 가장 먼저 만나는 벽은 환경 조합이다.
OS 3 × DB 3 × 웹서버 2 × 브라우저 4 = 72 조합
→ 기능 30개를 72 조합에서 다 돌리면 2,160회전부 재는 것은 현실적이지 않고, 필요하지도 않다. 두 가지 수단이 있다.
첫째, 지원 범위를 문서에서 닫는다. 레슨 3의 규칙이 여기서 값을 낸다. "모든 브라우저 지원"을 "Chrome·Edge 최신 2개 버전"으로 바꾸면 조합이 절반 이하로 줄어든다. 측정 비용을 줄이는 가장 싼 방법은 약속을 좁히는 것 이다.
둘째, 조합을 설계한다. 모듈 3에서 다룬 페어와이즈(pairwise)가 그대로 쓰인다. 모든 조합이 아니라 모든 쌍 을 덮는 조합 집합을 뽑으면 72개가 10여 개로 줄어든다. 그리고 전 기능을 전 조합에서 돌리는 대신 계층을 나눈다.
전 기능 × 기준 환경 1개 ← 기능적합성의 본체
핵심 기능 × 페어와이즈 조합 ← 호환성 확인
설치·기동 × 전 지원 환경 ← 이식성 (가장 값싸고 자주 깨진다)세 번째 줄이 실전 감각이다. 기능은 대개 환경에 둔감한데 설치와 기동은 환경에 아주 민감 하다. 지원 환경 전부에서 설치만 돌려 보는 것이 비용 대비 발견율이 가장 높다.
반복 횟수와 워밍업 — 몇 번 재야 하는가
성능 측정에서 "몇 번 재야 하나"는 답이 있는 질문이 아니지만, 결정 규칙은 만들 수 있다.
워밍업 JIT·캐시·커넥션 풀이 안정되기 전 구간은 제외한다
(제외한다는 사실과 구간을 기록에 남긴다)
반복 같은 조건에서 최소 3회. 값의 산포를 보고 늘린다
조건 간 반복 날짜·재배포를 바꿔 최소 1회 더 ★
채택값 평균이 아니라 백분위. 조건 간 차이는 별도로 기록별표가 모듈 32 레슨 3의 재현성이다. 하루에 30번 재서 얻은 좁은 산포를 근거로 제품설명서에 수치를 적으면, 기관이 다른 날 다른 환경에서 잰 값이 그 수치를 넘는 일이 생긴다. 제품설명서 숫자는 우리 최고 기록이 아니라 재현되는 하한 이어야 한다.
자체 측정값을 제품설명서 수치로 환산하기
레슨 3에서 "실측값보다 보수적으로 적는다"고 했다. 그 보수성을 감으로 정하지 않는 방법이 있다.
설명서 기재값 = 재현되는 값에서 안전 마진만큼 물러난 값
재현되는 값 조건을 바꿔 반복했을 때도 만족한 값 (최악 조건 기준)
안전 마진 조건 간 산포 + 시험 환경 차이 + 제품 변경 여지구체적인 예로 보자.
| 단계 | 값 |
|---|---|
| 기준 환경 반복 측정 p95 | 1.12 s |
| 날짜·재배포를 바꾼 조건의 p95 | 1.38 s ← 재현되는 값 |
| 시험 환경 차이 여지(공유 인프라·데이터량) | +20% 가정 |
| 설명서 기재 후보 | 약 1.7 s |
| 설명서 기재값 | 2.0 s 이내 (권장 사양·동시 500 기준) |
마지막 줄이 방어된 문장이다. 1.12를 근거로 "1.2초 이내"라고 적었다면 결함 라운드가 한 번 더 돌아간다. 마진 하나가 한 달을 만든다.
마진을 크게 잡는 것이 손해처럼 느껴진다면, 영업용 자료와 사양서를 분리하는 것이 답이다(레슨 3의 규칙 ④). "보증은 2초, 실측은 1.1초" 라는 두 숫자를 함께 관리하면 양쪽이 다 산다.
기관 측정과 우리 측정이 다를 때
다를 수 있고, 실제로 다르다. 중요한 것은 차이를 설명할 수 있는가 다. 설명 가능한 상태를 만드는 것이 이 레슨의 최종 목적이다.
차이가 났을 때 순서대로 대조할 항목은 이미 정해져 있다.
1. 측정 대상이 같은가 같은 API·트랜잭션·시나리오인가
2. 부하 모델 정의가 같은가 '동시 사용자'의 정의
3. 환경 다섯 축이 같은가 특히 데이터량과 네트워크
4. 측정 지점이 같은가 클라이언트 측정인가 서버 측정인가
5. 집계 방식이 같은가 백분위 산출, 오류 포함 여부, 워밍업 제외이 목록으로 대조하려면 우리 쪽 절차서와 원자료가 남아 있어야 한다. 남아 있지 않으면 협의는 "우리 환경에서는 잘 나왔습니다"로 끝나고, 그 문장은 아무것도 바꾸지 못한다. 모듈 31 레슨 6의 클레임 대응과 모듈 32 레슨 4의 원자료 보관이 여기서 합쳐진다.
실무에서 왜 필요한가
측정 절차서는 인증을 한 번 받고 버리는 문서가 아니다. 두 곳에서 계속 쓰인다.
첫째, 변경인증 이다(레슨 6). 다음 버전에서 같은 측정량을 다시 재야 할 때, 절차서가 있으면 같은 방식으로 재고 비교할 수 있다. 없으면 매번 새로 재는 셈이라 값의 변화가 제품 변화인지 측정 변화인지 알 수 없다.
둘째, 평소의 성능 회귀 감시 다. 인증용으로 만든 절차를 CI에 얹으면 릴리스마다 같은 지표가 쌓인다. 이 데이터가 있으면 제품설명서 수치를 올릴 근거도, 성능 저하를 조기에 잡을 근거도 생긴다. 모듈 14의 지속적 테스팅과 모듈 16의 비기능 테스트가 인증 작업과 만나는 지점이다.
그리고 이 작업은 QA가 개발과 대화하는 언어를 바꾼다. "느린 것 같다"가 아니라 "기준 환경 p95가 1.12초에서 1.51초로 올랐고 조건 간 산포는 변하지 않았다"고 말할 수 있게 된다.
채용시장에서의 위치
성능·비기능 측정을 절차로 설계할 수 있는 사람은 도구를 쓸 수 있는 사람보다 훨씬 적다. 공고에는 "성능 테스트 경험", "비기능 요구사항 검증" 으로 적히지만, 면접에서 갈리는 지점은 도구 사용 경험이 아니라 반복 설계와 값의 재현성 을 설명할 수 있는지다.
인증 맥락에서는 이 역량이 곧 일정 단축으로 환산된다. 자체 측정으로 설명서 수치를 방어해 둔 회사는 성능 항목에서 결함이 나오지 않고, 그 차이가 분기 일정을 만든다.
면접에서 힘 있는 답변의 형태는 이렇다. "제품설명서 수치를 개발 환경 최고 기록으로 적어 두었던 것을 바꿨습니다. 날짜와 재배포를 바꿔 세 조건에서 반복 측정하고, 최악 조건 p95에 20% 마진을 얹어 기재값을 정했습니다. 같은 절차를 CI 주간 작업으로 옮겨서, 이후에는 릴리스마다 같은 지표가 쌓입니다."