요구사항을 모델로 옮기는 워크숍과 유지보수 비용

개념

모델을 혼자 그리면 반드시 틀린다

레슨 1에서 모델 품질이 테스트 품질이라고 했다. 그런데 모델의 오류는 대부분 표기법 실수가 아니라 업무 이해의 공백 에서 나온다. "배송준비 상태에서 취소가 되는가" 는 그래프 지식으로 답할 수 없다. 기획자·개발자·운영이 각자 다르게 알고 있고, 명세에는 안 적혀 있는 경우가 흔하다.

그래서 모델링은 문서 작업이 아니라 회의체 로 설계한다. 전반부는 그 회의를 어떻게 돌리는지, 후반부는 만든 모델을 얼마의 비용으로 유지하는지, 그리고 언제 아예 하지 말아야 하는지 다.

워크숍 참석자 — 네 자리

인원은 넷에서 다섯이 상한이다. 더 들어오면 그림을 보며 합의하는 속도가 무너진다. 시간은 90분으로 잡고, 한 번에 기능 하나 만 다룬다. 끝나지 않으면 회차를 늘린다 — 모델을 한 번에 완성하려는 시도가 가장 흔한 실패다.

무엇을 먼저 그리는가 — 여섯 단계

순서가 중요하다. 상태를 전부 나열하려 들면 회의가 멈춘다. 정상 경로 한 줄부터 그린다.

[1] 종료 상태를 먼저 적는다        "이 업무가 끝났다" 는 상태는 무엇인가 (2~3개)
[2] 정상 경로를 한 줄로 긋는다      시작 -> ... -> 종료. 분기 없이 직선
[3] 종료 상태의 역방향을 확인한다    각 종료 상태에 들어오는 전이가 있는가
[4] 분기와 실패 경로를 붙인다        "여기서 잘못되면 어디로 가는가"
[5] 가드를 적는다                   같은 이벤트가 갈라지는 지점에만
[6] 금지 전이를 표시한다            "이건 되면 안 된다" 를 부정 전이로

[1]을 먼저 하는 이유가 있다. 종료 상태를 먼저 고정하면 데드엔드가 의도된 것인지 아닌지 가 회의 중에 자동으로 판정된다(레슨 1의 두 번째 기준). [4]에서 새로 생긴 상태에 나가는 전이가 없으면, 그 자리에서 "이것도 종료인가, 빠뜨린 건가" 를 물을 수 있다.

[5]를 [4] 뒤에 두는 것도 의도다. 가드를 먼저 논의하면 세부 조건 토론으로 90분이 전부 소비된다. 구조를 먼저 고정하고 가드는 갈라지는 지점에만 붙인다.

명세에서 상태 후보를 뽑는 신호어

워크숍 전에 진행자가 혼자 하는 준비 작업이 있다. 요구사항·화면 설계를 읽으며 상태를 가리키는 표현 을 표시해 두는 것이다. 한국어 명세에서는 패턴이 꽤 일정하다.

다섯째 줄이 실무에서 가장 유용하다. 버튼 활성·비활성 조건 표는 사실상 이미 작성된 가드 명세다. 워크숍에 그 표를 인쇄해 들어가면 [5]단계가 절반으로 줄어든다.

워크숍의 두 번째 산출물 — 미해결 질문 목록

모델 초안보다 중요한 산출물이 있다. 그 자리에서 아무도 답하지 못한 질문의 목록 이다.

Q1  배송준비에서 취소 가능한 시간 기준의 시작점은 결제 승인 시각인가 입금 확인 시각인가
Q2  부분 환불이 진행 중일 때 추가 반품 접수가 되는가
Q3  정산 실패 상태에서 재시도 횟수 상한이 있는가 — 상한 도달 후 상태는?

이 목록이 테스트 산출물이 아니라 명세 결함 리포트 다. 투자 회수가 가장 빠른 지점이고, MBT 를 도입하지 않기로 해도 남는 가치다. "MBT 는 보류했지만 워크숍은 계속한다" 도 합리적인 결론이다.

모델이 틀렸을 때 드러나는 신호

모델은 조용히 낡는다. 그래서 증상을 미리 알아 두고 주기적으로 확인 해야 한다.

마지막 줄을 주기적으로 보는 것이 좋다. 어댑터 코드의 분기문 수 는 모델 품질의 간접 지표다. 모델이 정확하면 어댑터는 호출과 단언만 있는 평평한 코드가 된다.

제품이 바뀔 때 무엇을 고치는가

MBT 의 유지보수 대상은 세 층이다. 변경 유형별로 어느 층을 건드리는지 정해 두면 영향 분석이 회의 중에 끝난다.

층 1  모델 파일          상태·전이·가드·액션
층 2  생성 설정          생성기·정지 조건·커버리지 기준
층 3  어댑터 코드        정점·간선 이름에 대응하는 함수

표에서 읽어야 할 두 줄이 있다.

세 번째 줄 — 정책 값만 바뀌는 변경은 모델 한 글자 수정으로 끝난다. 수동 케이스였다면 "24시간" 이 적힌 케이스를 전부 찾아 고쳐야 했다. 여기가 MBT 의 이득이 가장 선명하게 나오는 자리다.

네 번째 줄 — UI 가 바뀌어도 모델은 그대로다. 모델과 어댑터를 분리해 둔 덕이고, 모듈 11(레슨 6)의 페이지 객체 계층과 같은 원리다. 반대로 둘을 섞어 놓으면 UI 변경마다 모델을 고치게 되고, 그 순간 MBT 의 장점이 사라진다.

마지막 줄이 도입 판단의 핵심이다. 업무 절차가 전면 개편되면 모델을 다시 그려야 하고, 그 비용은 수동 케이스를 다시 쓰는 비용과 비슷하거나 더 크다.

비용 구조와 손익분기

모듈 11(레슨 3)에서 자동화 ROI 의 손익분기 계산을 다뤘다. MBT 는 같은 계산에 항을 하나 더 넣는다 — 변경 빈도 다. 초기 비용이 수동보다 크므로, 변경이 누적되면서 회수된다. 변경이 거의 없는 기능에서는 영원히 회수되지 않는다.

그리고 네 번째 줄의 위험이 ROI 표에는 안 나타난다. 모델 소유자가 떠나면 모델이 그날부터 낡는다. 완화 장치는 세 가지다.

• 모델 파일을 제품 저장소 에 둔다(QA 개인 폴더나 별도 위키가 아니다)
• check·methods 검사를 CI 에 넣어 모델 오류가 리뷰에서 걸리게 한다
• 모델 리뷰를 기능 리뷰 체크리스트에 넣어 기획 변경이 모델을 거치게 한다

MBT 를 언제 쓰지 말아야 하나

여기가 이 모듈의 결론이다. MBT 는 적용 범위가 좁은 기법이고, 안 쓰는 판단을 정확히 내리는 것이 쓰는 것보다 자주 필요하다.

(1) 상태가 적다. 상태 5개 이하, 전이 10개 이하라면 모듈 3(레슨 3)의 상태 전이표를 손으로 쓰는 것이 더 빠르고 더 읽기 쉽다. 도구와 어댑터를 들여올 이유가 없다.

(2) 본질이 값 조합이다. 상태 이력이 아니라 입력 조합이 결과를 정하면 그건 페어와이즈(모듈 3 레슨 5)나 결정 표의 영역이다. 억지로 상태기계로 옮기면 레슨 1에서 본 최악의 모델이 나온다.

(3) 구조 자체가 자주 바뀐다. 이 항목은 조심해서 읽어야 한다. 모듈 3(레슨 11) 에서 "변경이 잦을수록 MBT 의 이득이 커진다" 고 했는데, 모순이 아니다. 무엇이 바뀌는지가 다르다.

세 번째·네 번째 줄이 "명세가 자주 바뀌면 손해" 의 정확한 내용이다. 탐색적으로 제품을 만들어 가는 초기 단계, 디스커버리 중인 기능에는 쓰지 않는다.

(4) 모델을 유지할 사람이 없다. 실무에서 가장 흔한 실패 원인이다. 도입을 주도한 사람이 혼자 모델을 들고 있다가 이동하면, 모델은 그 시점에 멈추고 생성된 케이스는 틀린 것을 꼼꼼하게 검증하기 시작한다. 최소 두 명이 모델을 고칠 수 있는 상태 가 아니면 도입을 미루는 것이 맞다.

(5) 오라클이 없다. 레슨 2에서 본 문제다. 추천 결과·랭킹·생성형 출력처럼 "무엇이 올바른 결과인지" 를 상태 불변식으로 적을 수 없는 영역에서는, 경로를 아무리 많이 뽑아도 충돌 감지밖에 못 한다. 그 비용으로는 스모크 테스트를 짜는 것이 낫다.

(6) 시스템을 프로그램적으로 제어할 수 없다. 외부 기관 승인, 물리적 장비 조작, 수동 배치처럼 전이를 코드로 일으킬 수 없는 단계가 경로 중간에 있으면 자동 실행이 끊긴다. 그 단계를 모델에서 분리할 수 없다면 적용 대상이 아니다.

도입 판단 체크리스트

여섯 질문에 네 개 이상 "예" 가 나오면 시범 적용을 검토한다. (4)번이 "아니오" 면 다른 답에 관계없이 미룬다 — 유지할 사람이 없는 모델은 자산이 아니라 부채다.

[ ] 1  대상 기능의 상태가 6개 이상이고 전이가 12개 이상인가
[ ] 2  결과를 가르는 것이 입력 조합이 아니라 상태 이력인가
[ ] 3  상태 구조는 안정적이고, 바뀌는 것은 주로 가드의 값·파라미터인가
[ ] 4  모델을 고칠 수 있는 사람이 팀에 두 명 이상인가          ← 필수 조건
[ ] 5  각 상태의 불변식을 명세에서 받아 적을 수 있는가(오라클)
[ ] 6  모든 전이를 테스트 코드로 일으킬 수 있는가

시범 적용은 기능 하나, 상태 10개 내외, 전이 커버리지 100% 로 시작한다. 2-스위치나 요구사항 커버리지는 운영이 안정된 뒤에 올린다.

실무에서 왜 필요한가

MBT 도입 제안서에서 가장 자주 비는 칸이 유지보수 비용 이다. "케이스를 자동 생성합니다" 만 적으면 결정권자는 초기 비용만 보고 판단한다. 세 층 영향 분석 표가 있으면 대화가 달라진다 — "UI 가 바뀌어도 모델은 안 고칩니다. 정책 값 변경은 모델 한 줄입니다. 대신 업무 절차 개편 때는 모델을 다시 그립니다" 가 구체적인 약속이 된다.

그리고 "쓰지 않겠다" 는 결론을 근거와 함께 내는 것이 실무에서 더 자주 필요하다. 경영진이나 도구 영업이 가져온 MBT 제안에 여섯 항목으로 답할 수 있는 QA 와 "저희 상황엔 안 맞는 것 같습니다" 라고 하는 QA 는 신뢰도가 다르다. 특히 (4)번을 근거로 미루는 판단은 조직의 현실을 보는 능력으로 읽힌다.

워크숍 자체도 독립적인 가치가 있다. 미해결 질문 목록은 MBT 를 도입하지 않아도 남는 산출물이고, 요구사항 리뷰로서는 가장 비용이 낮은 형태다. 모델을 그리다 손이 멈추는 자리가 곧 명세가 비어 있는 자리라는 원리는 모듈 3(레슨 3)의 상태-이벤트 매트릭스에서 이미 봤던 것이다.

실습 과제

과제 1 — 명세에서 상태 후보 표시하기 (20분)

담당 제품의 요구사항 문서나 화면 설계 중 2~3쪽을 골라, 본문의 신호어 표를 들고 읽으며 표시한다.

1. 상태를 가리키는 표현에 밑줄을 긋고 상태 이름 후보를 옆에 적는다
2. 금지 조건("~중에는 ~할 수 없다")을 따로 모아 부정 전이 목록을 만든다
3. 버튼 활성·비활성 조건 표가 있으면 가드 목록으로 옮긴다
4. 읽으면서 생긴 질문을 미해결 질문 목록 으로 정리한다

4번의 질문 개수를 센다. 다섯 개 이상 나왔다면 그 기능의 명세는 모델링 워크숍이 필요한 상태라는 뜻이다.

과제 2 — 모델링 워크숍 돌려보기 (90분)

과제 1의 기능으로 본문의 여섯 단계를 순서대로 진행한다. 혼자 연습한다면 기획자· 개발자 역할을 가정하고, 답을 모르는 질문은 추측하지 말고 질문 목록에 적는다.

진행 후 각 단계에 쓴 시간, 최종 상태·전이·가드·부정 전이 수, 미해결 질문 수, 그리고 레슨 1의 여섯 품질 기준으로 자기 모델을 린트한 결과를 기록한다. [5]단계(가드)가 전체 시간의 절반을 넘었다면 구조를 먼저 고정하지 않은 것이다.

과제 3 — 도입 판단서 쓰기 (25분)

과제 2의 기능에 대해 한 쪽 분량의 판단서를 쓴다. 들어갈 항목은 다섯 개다.

1. 도입 판단 체크리스트 여섯 항목의 예/아니오와 그 근거 한 줄씩
2. 세 층 영향 분석 — 지난 6개월간 그 기능에 있었던 변경 세 건을 골라 각각 어느 층을 고쳐야 했을지 표로
3. 초기 비용 추정(워크숍 시간 + 어댑터 구현 시간)
4. 모델 소유자 후보 두 명의 이름
5. 결론 한 줄 — 시범 적용 / 보류 / 적용하지 않음 중 하나와 그 이유

4번을 적을 수 없으면 결론은 자동으로 "보류" 다. 그 사실을 판단서에 그대로 쓰는 연습이 이 과제의 목적이다.

자가 체크리스트

• 모델링 워크숍의 네 역할과 각 역할이 없을 때 생기는 결함을 설명할 수 있다
• 종료 상태를 가장 먼저 그리는 이유를 데드엔드 판정과 연결해 설명할 수 있다
• 가드를 구조 확정 뒤에 붙이는 이유를 안다
• 명세의 표현에서 상태·가드·부정 전이 후보를 뽑아낼 수 있다
• 미해결 질문 목록이 명세 결함 리포트라는 점을 설명할 수 있다
• 모델이 낡았음을 알리는 신호를 세 가지 이상 들 수 있다
• 제품 변경 유형별로 모델·생성 설정·어댑터 중 어디를 고칠지 판정할 수 있다
• "변경이 잦으면 유리" 와 "구조가 자주 바뀌면 불리" 를 구분해 설명할 수 있다
• MBT 를 쓰지 말아야 하는 여섯 상황을 들 수 있다
• 도입 판단에서 모델 유지 인원이 필수 조건인 이유를 설명할 수 있다

흔한 실수

• 모델을 QA 혼자 그려 와서 리뷰만 받는다. 그 자리에서 나와야 할 질문이 나오지 않고, 모델에 추측이 들어간 채 굳는다.
• 한 번의 워크숍으로 모델을 완성하려 한다. 상태를 전부 나열하려다 시간이 끝난다. 정상 경로부터 긋고 회차를 늘린다.
• 가드부터 논의한다. 세부 조건 토론으로 90분이 사라지고 구조는 비어 있다.
• 모델 파일을 QA 개인 폴더나 위키에 둔다. 제품 저장소에 없으면 코드 변경과 함께 리뷰되지 않고, 담당자가 바뀌는 순간 사라진다.
• UI 로케이터를 모델에 적는다. 화면이 바뀔 때마다 모델을 고치게 된다.
• "변경이 잦으니 MBT 가 맞다" 로 단순하게 판단한다. 바뀌는 것이 가드의 값인지 상태 구조인지를 먼저 구분한다. 후자면 손해다.
• 모델 소유자를 정하지 않고 도입한다. 도입 6개월 뒤 모델이 낡고, 아무도 고치지 않으며, 커버리지 리포트만 100% 로 남는다.

참고 자료

• ISTQB — Certified Tester Model-Based Tester (CT-MBT) — 실러버스의 "Evaluating and Deploying an MBT Approach" 장이 MBT 도입 평가와 운영 모니터링을 다룬다. 세부 학습 목표는 실러버스 원문 확인
• 모듈 11 레슨 3 — 자동화 ROI 와 손익분기 계산. 이 레슨의 비용 구조 표는 거기에 변경 빈도 항을 더한 것이다
• 모듈 11 레슨 4 — 자동화 기술 부채. 모델이 낡는 과정은 스크립트가 부채가 되는 과정과 같은 구조다
• 모듈 3 레슨 3·레슨 5 — 상태 전이 표와 페어와이즈. MBT 를 쓰지 않을 때 돌아갈 기법이 여기 있다
• 레슨 1~3 — 모델 품질 기준, 커버리지와 생성 알고리즘, GraphWalker 운영. 이 레슨의 판단은 그 셋을 전제로 한다