개념
도메인 공부와 리스크 추출은 다른 일이다
새 프로젝트에 배정된 첫 주의 흔한 행동은 도메인을 "공부"하는 것이다. 업무 매뉴얼을 읽고 용어집을 외우고 규정을 훑는다. 2주가 지나면 용어는 알게 되지만 무엇을 먼저 테스트해야 하는지는 여전히 모른다.
이유는 단순하다. 도메인 문서는 정상 흐름을 설명하기 위해 쓰여 있고, 리스크는 정상 흐름에 안 적혀 있기 때문이다. 리스크는 사고 기록·컴플레인·벌칙 조항·손대기 무서운 코드에 들어 있다.
이 레슨은 도메인 지식을 가르치지 않는다. 깊이는 다른 모듈에 있다 — 금융은 모듈 41, 공공·기업 업무는 모듈 64, 의료기기는 모듈 40, 게임은 모듈 47, 기능 안전은 모듈 35다. 여기서 다루는 것은 낯선 도메인에 들어갔을 때 리스크 목록 초안을 만드는 절차 이고, 세 도메인은 그 절차를 보여주는 재료다.
리스크 패턴 추출 5단계
① 손실의 형태를 먼저 정한다 무엇이 실패하면 누가 무엇을 잃는가
↓
② 읽는다 — 순서가 정해져 있다 사고 기록 → 컴플레인 → 벌칙 조항 → 데이터 모델 → 기능 명세
↓
③ 묻는다 — 문형이 정해져 있다 역할마다 다른 질문을 쓴다
↓
④ 유형으로 분류해 좁힌다 정합성·시점·자격·상태·외부 의존·증빙
↓
⑤ 케이스 패턴으로 내린다 리스크 하나 → 재사용 가능한 케이스 틀①이 나머지 전부의 방향을 정한다. "이 제품이 실패하면 누가 무엇을 잃는가" 를 한 문장으로 쓸 수 있으면 리스크의 무게가 정해진다. 돈을 잃는가(금융·커머스), 자격을 잃는가(공공), 건강을 잃는가(의료), 시간을 잃는가(업무 도구). 손실의 형태가 다르면 같은 결함의 심각도가 달라진다.
② 읽을 것 — 순서가 신호 대 잡음비 순서다
| 순서 | 자료 | 여기서 나오는 것 | 왜 이 순서인가 |
|---|---|---|---|
| 1 | 장애·인시던트 기록, 포스트모템 | 이미 터진 리스크. 재발 가능성 높음 | 신호가 가장 진하다 |
| 2 | CS 문의 분류, VoC 상위 항목 | 사용자가 실제로 겪는 실패 | 빈도 정보가 붙어 있다 |
| 3 | 규제·계약의 벌칙·위반 조항 | 절대 넘으면 안 되는 선 | 심각도 정보가 붙어 있다 |
| 4 | 데이터 모델, 상태 전이도 | 정합성이 깨질 수 있는 지점 | 구조적 리스크가 보인다 |
| 5 | 기능 명세·화면 설계 | 정상 흐름 | 신호가 가장 옅다 |
대부분이 5번부터 읽기 시작한다. 5번은 정상 흐름이라 리스크가 안 보이고 분량은 가장 많다. 1~3번은 분량이 적고 신호가 진하다. 1번을 구할 수 없으면 "장애 기록이 관리되지 않는다"는 것 자체가 첫 리스크다.
3번을 읽는 요령이 하나 있다. 규제·계약 문서를 처음부터 읽지 말고 벌칙·제재·위반·손해배상·해지 조항을 먼저 찾는다. 그 조항이 가리키는 의무가 그 도메인에서 실제로 무게가 있는 요건이다.
③ 물을 것 — 역할별 문형 카탈로그
인터뷰는 "이 도메인에 대해 알려주세요"로 시작하면 실패한다. 역할마다 다른 문형을 쓴다. 아래 질문은 도메인과 무관하게 재사용된다.
| 상대 | 질문 문형 | 나오는 것 |
|---|---|---|
| CS·운영 담당 | "가장 자주 오는 문의 세 개는?" / "설명하기 가장 어려운 건?" | 빈발 결함, 사용자 오해 지점 |
| CS·운영 담당 | "수동으로 데이터를 고쳐 주는 경우가 있나요?" | 시스템이 못 막는 정합성 구멍 |
| 도메인 전문가 | "이 업무에 새로 온 사람이 꼭 틀리는 것은?" | 규칙의 예외와 함정 |
| 도메인 전문가 | "월말·연말·개편 때 달라지는 게 있나요?" | 시점 리스크 |
| 개발자 | "손대기 무서운 코드나 모듈은?" | 복잡도·변경 리스크 |
| 개발자 | "여기서 장애가 나면 어디부터 봅니까?" | 단일 장애점, 관측 공백 |
| 기획·영업 | "계약·약관에서 절대 안 되는 건?" | 심각도 최상단 |
| 기획·영업 | "경쟁사 사고로 우리 쪽에 문의가 온 적 있나요?" | 업계 단골 리스크 |
"새로 온 사람이 꼭 틀리는 것"이 단일 질문으로는 수확이 가장 크다. 도메인 전문가는 리스크를 리스크로 인식하지 못한다 — 그들에게는 당연한 규칙이라서다. 하지만 "신입이 틀리는 것"으로 물으면 암묵 규칙이 말로 나온다.
④ 유형으로 좁히기 — 리스크 유형 격자
수집한 후보를 그대로 목록으로 두면 30~50개가 되고 우선순위가 안 잡힌다. 여섯 유형으로 분류하면 도메인별 편중이 드러난다.
| 유형 | 묻는 것 | 대표 케이스 기법 |
|---|---|---|
| 정합성 | 두 곳의 값이 어긋날 수 있는가 | 불변식, 대사, 왕복 검증 |
| 시점 | 언제 계산·판정하는가, 경계가 어디인가 | 경계값, 시각 이동 시험 |
| 자격·권한 | 누가 무엇을 할 수 있는가 | 결정표, 권한 조합 매트릭스 |
| 상태 | 어떤 순서·조합이 가능한가 | 상태 전이, 페어와이즈 |
| 외부 의존 | 상대가 느리거나 틀리면 | 목 서버 장애 주입(레슨 3 ③층) |
| 기록·증빙 | 나중에 증명할 수 있는가 | 감사 로그 확인, 재계산 |
분류가 끝나면 어느 유형에 후보가 몰려 있는지 를 본다. 몰린 유형이 그 도메인의 성격이고, 비어 있는 유형은 아직 안 물어본 곳이다.
⑤ 케이스 패턴으로 내리기 — 리스크 카드
리스크 하나를 다음 형식으로 적는다. 이것이 이 레슨의 산출물 단위다.
[리스크 카드]
리스크 : 프로모션 기간 경계에서 할인율이 잘못 적용된다
유형 : 시점
손실의 형태 : 금전 손실(과다 할인) 또는 고객 신뢰(누락 할인)
근거 : 인시던트 #412, CS 분류 3위
케이스 패턴 : 시작 시각 -1초 / 정각 / +1초 × 결제 완료 시점 vs 주문 생성 시점
판정 기준 : 주문 생성 시각 기준 정책(운영 확인 필요 — 명세 공백)"판정 기준" 칸이 비면 레슨 1의 오라클 공백이고, 그건 결함이 아니라 질문 이다.
적용 1 — 금융
①의 답이 명확하다. 돈과 규제 제재 다. 손실이 즉시 금액으로 환산되고 감독 규정이 벌칙을 갖고 있어서, 유형 격자가 정합성·시점·증빙 쪽으로 강하게 몰린다.
| 단골 리스크 | 유형 | 케이스 패턴 |
|---|---|---|
| 금액 정합성이 두 장부에서 어긋난다 | 정합성 | 불변식(차변=대변) 검증, 건별·합계 대사 |
| 결과를 알 수 없는 거래가 남는다 | 정합성 | 타임아웃 후 성공 응답, 재시도 중복 |
| 단수 처리·소수 자릿수가 규정과 다르다 | 정합성 | 반올림·절사 경계값, 처리 순서 |
| 기준 시각·영업일 정의가 갈린다 | 시점 | 마감 직전·직후, 공휴일, 월말·연말 |
| 한도·자격이 시점에 따라 달라진다 | 자격 | 한도 경계, 기준일 변경 |
| 처리 근거를 나중에 증명 못 한다 | 증빙 | 감사 로그, 재계산 일치 |
깊이는 모듈 41에 있다. 원장 정합성과 금액 계산은 레슨 2, 감독 규정을 시험 요건으로 읽는 법은 레슨 1, 차세대 전환은 레슨 3, PCI DSS는 레슨 4다. 여기서 볼 것은 내용이 아니라 왜 이 여섯 줄이 먼저 나오는가 다. 답은 ②의 3번 — 감독 규정과 계약의 벌칙 조항이 원장·기록·기한을 가리키기 때문이다. 벌칙 조항을 먼저 읽으면 금융의 단골 리스크 목록이 거의 자동으로 나온다.
적용 2 — 커머스
①의 답이 둘로 갈린다. 매출 손실과 고객 신뢰 다. 금융과 달리 규제 벌칙이 리스크를 정해주지 않으므로, ②의 1·2번(인시던트·CS 문의)이 주 자료가 된다. 유형 격자는 상태와 정합성, 그리고 동시성 으로 몰린다.
| 단골 리스크 | 유형 | 케이스 패턴 |
|---|---|---|
| 재고가 실물과 어긋난다(초과 판매) | 정합성 | 동시 2인 이상 경합, 차감 시점(주문 vs 결제) |
| 할인·쿠폰·포인트가 중첩되며 금액이 틀린다 | 정합성 | 적용 순서 결정표, 중복 사용 가능 여부 조합 |
| 프로모션 기간·수량 경계에서 잘못 적용된다 | 시점 | 시작·종료 정각 ±1초, 마지막 1개 |
| 부분 취소·부분 반품·교환 조합이 깨진다 | 상태 | 상태 전이도 기반 조합, 부분 상태 재조합 |
| 정산 금액이 판매자 화면과 다르다 | 정합성 | 수수료·프로모션 부담 주체별 재계산 |
| 외부 결제·배송사 응답이 늦거나 틀리다 | 외부 의존 | 목 서버 지연·오류(레슨 3 ③층) |
커머스에서 분석을 잘못하는 전형은 규칙을 하나씩만 보는 것 이다. 쿠폰 하나, 포인트 하나, 등급 할인 하나는 대개 맞게 동작한다. 틀리는 것은 셋이 겹칠 때의 적용 순서와 반올림 지점 이고, 취소·반품이 그 위에 올라갈 때다. 커머스의 케이스 패턴이 거의 항상 중첩과 역방향 두 축을 갖는 이유다.
[중첩·역방향 조합 틀]
축 1 적용할 혜택 조합 쿠폰 / 포인트 / 등급 / 프로모션 (겹침 허용 여부 표 필요)
축 2 역방향 이벤트 전체 취소 / 부분 취소 / 반품 / 교환 / 재결제
확인 혜택 환원 금액, 재고 복원, 정산 재계산, 세금계산서 상태축 2를 빼놓으면 정방향만 통과하는 케이스 세트가 된다. 운영 사고는 대부분 축 2에서 난다.
적용 3 — 공공
①의 답은 자격과 기한, 그리고 형평성 이다. 돈이 오가더라도 손실의 형태가 다르다 — 받아야 할 사람이 못 받는 것이 가장 큰 실패다. ②의 3번 자료가 법령·고시·지침이고, 여기가 리스크의 원천이다. 유형 격자는 자격과 시점으로 강하게 몰린다.
| 단골 리스크 | 유형 | 케이스 패턴 |
|---|---|---|
| 자격 판정이 요건 조합에서 틀린다 | 자격 | 결정표(요건 AND/OR), 경계 소득·연령 |
| 기준일 정의가 조문과 다르다 | 시점 | 신청일·접수일·처리일·기준일 각각으로 판정 |
| 기한 계산이 공휴일·말일에서 틀린다 | 시점 | 기한 마지막 날 마감 시각, 공휴일 순연 |
| 법령 개정 전후 적용이 뒤섞인다 | 시점 | 경과 규정, 개정 전 신청·개정 후 처리 |
| 이력·증빙을 보존 기간만큼 못 낸다 | 증빙 | 이력 조회, 보존 기간 경과 데이터 |
| 신청 개시 시각에 접속이 몰린다 | 외부 의존 | 개시 정각 부하, 대기열 동작 |
공공 분석의 특징은 판정 기준의 출처가 조문이라는 것 이다. 명세서가 아니라 법령·고시가 오라클이고, 명세서와 조문이 어긋나면 조문이 이긴다. 그래서 공공에서는 ⑤ 카드의 "판정 기준" 칸에 조문 번호를 적는다. 조문을 특정할 수 없는 규칙은 그 자체로 질문 항목이다.
깊이는 모듈 64에 있다 — 전자정부 표준프레임워크는 레슨 1, 웹 접근성 의무는 레슨 2, ERP 마감·전표·권한 결정표는 레슨 3, 망분리 환경과 피크 부하는 레슨 5다.
세 도메인을 나란히 놓으면 절차가 보인다
| 금융 | 커머스 | 공공 | |
|---|---|---|---|
| 손실의 형태 | 금액·제재 | 매출·신뢰 | 자격 박탈·형평성 |
| 리스크의 주 원천 | 규정의 벌칙 조항 | 인시던트·CS 문의 | 법령·고시 조문 |
| 몰리는 유형 | 정합성·증빙 | 상태·동시성 | 자격·시점 |
| 판정 기준의 출처 | 규정·계약·업무 규칙 | 기획 의도·운영 정책 | 조문 |
| 특유의 함정 | 결과 불명 거래 | 혜택 중첩과 역방향 | 기준일·경과 규정 |
같은 5단계 절차인데 ②에서 어느 자료가 주 자료가 되는지가 도메인마다 다르다. 낯선 도메인에 들어갔을 때 먼저 판단할 것은 그것이다 — 이 도메인의 리스크는 규정에 적혀 있는가, 사고 기록에 적혀 있는가, 조문에 적혀 있는가.
실무에서 왜 필요한가
경력 QA가 새 도메인으로 옮길 때 평가받는 것은 도메인 지식이 아니다. 지식은 어차피 도메인 전문가보다 깊어질 수 없다. 평가받는 것은 얼마나 빨리 "여기서 위험한 곳"을 짚어내는가 이고, 그 속도가 절차의 유무에서 갈린다.
조직 관점에서도 이 절차는 이전 가능한 자산이 된다. 리스크 카드 형식이 팀에 정착되면 신규 인원 온보딩이 "매뉴얼 읽기"에서 "카드 20장 읽기"로 바뀌고, 모듈 4 레슨 2의 리스크 기반 테스팅에 들어갈 입력이 매번 처음부터 만들어지지 않는다. 리스크 우선순위화와 대응 결정은 그쪽 레슨의 일이고, 이 레슨은 그 앞단에서 후보를 만드는 일 을 맡는다.
면접에서도 "커머스 경험이 있습니다"보다 "낯선 도메인에 들어가면 인시던트 기록·CS 분류·계약의 벌칙 조항 순으로 읽고, 운영 담당에게 '수동으로 데이터를 고쳐 주는 경우'를 묻습니다. 지난 프로젝트에서 그 질문 하나로 정합성 결함 유형 두 개를 찾았습니다"가 훨씬 강하다.