소프트웨어 공학 100 주제 시리즈의 20번째 글이다. (카테고리: 요구사항 공학)

한 줄 요약

프로토타입은 “작은 제품” 이 아니라 질문 하나에 답하기 위한 실험 도구다. 무엇을 확인할지(역할·외형·구현), 얼마나 정교하게 만들지, 끝나면 버릴지를 먼저 정하고 만든다. 그래야 요구사항을 문서 리뷰가 아니라 사용자의 실제 반응으로 확인할 수 있다.

왜 필요한가

요구사항 문서를 아무리 잘 써도 이해관계자가 그것을 읽고 머릿속에 그리는 시스템은 사람마다 다르다. 결과물을 보고 나서야 “이게 아닌데” 가 나온다. 그 시점이 출시 후라면 비싸다.

SE100 #011 에서 본 것처럼, Nuseibeh 와 Easterbrook 는 인스펙션이 요구사항 기술의 일관성을 확인하는 반면, 프로토타이핑·시나리오는 현실 문제와의 대응을 시험한다고 구분했다. 문서가 제대로 쓰였는지(검증)와 맞는 것을 쓰였는지(확인)는 다른 질문이고, 뒤의 질문에는 사람이 실제로 만져 볼 무언가가 필요하다.

그런데 프로토타이핑은 자주 이렇게 실패한다.

  • 고객에게 보여 준 그럴듯한 시연용 화면이 “거의 다 됐네요” 라는 반응을 낳고, 그대로 제품 코드가 된다.
  • 정교하게 만든 시안에 대해 사용자가 버튼 색 이야기만 한다. 정작 확인하려던 업무 흐름은 검증되지 않는다.
  • “사용자 반응이 좋았다” 는 결론만 남는다. 무엇을 확인하려 했고 무엇이 확인됐는지 기록이 없다.

핵심 개념

프로토타이핑의 세 목적

Christiane Floyd 는 1984년 A Systematic Look at Prototyping에서 프로토타이핑을 목적에 따라 셋으로 나눴다.

종류 질문 수명 예
탐색적(exploratory) 무엇이 필요한가? 요구를 명확히 버린다 종이 화면으로 주문 흐름 시험
실험적(experimental) 이 해법이 통하는가? 대개 버린다 결제 대행사 API 로 타임아웃 처리 가능성 확인
진화적(evolutionary) 점진적으로 시스템을 키운다 제품이 된다 얇은 기능 조각을 계속 확장

요구사항 확인에 쓰는 것은 주로 탐색적 프로토타입이다. 문제는 탐색적으로 만든 것을 진화적으로 쓰는 것이다. 탐색용 코드는 빨리 만들려고 품질을 포기한 코드라 제품의 기초로는 맞지 않는다.

Fred Brooks 는 The Mythical Man-Month (Addison-Wesley, 1975)의 “Plan to Throw One Away” 장에서 첫 시스템은 어차피 버리게 되니 버릴 계획을 세우라고 했다. 프로토타입에 그대로 적용된다. 탐색적 프로토타입은 만들기 전에 “이건 버린다” 를 합의한다.

무엇을 프로토타이핑하는가: 세 차원

Stephanie Houde 와 Charles Hill 의 What do Prototypes Prototype? (Handbook of Human-Computer Interaction, 1997)는 프로토타입이 탐색하는 대상을 세 차원으로 나눈다.

                역할(role)
            제품이 사용자의 삶에서
             어떤 쓸모를 가지나
                  ▲
                 ╱ ╲
                ╱   ╲
               ╱     ╲
  외형과 느낌 ◀───────▶ 구현(implementation)
 (look and feel)        기술적으로 어떻게
 보이고 만져지는 감각     동작하게 만들까
질문 차원 적합한 프로토타입
단골은 정말 “다시 담기” 를 쓸까? 역할 종이 스케치, 시나리오 카드
주문 버튼 위치가 한 손 조작에 맞나? 외형과 느낌 클릭 가능한 화면 시안
매장 단말로 1초 안에 알림이 가나? 구현 기술 스파이크 코드

요구사항 확인은 주로 역할 차원이다. 그런데 팀은 습관적으로 외형(디자인 시안)이나 구현(동작하는 코드)을 만든다. 질문과 프로토타입의 차원이 어긋나면 엉뚱한 답을 얻는다.

정밀도(fidelity)

Marc Rettig 의 Prototyping for Tiny Fingers (CACM, 1994)는 종이로 만든 저정밀 프로토타입을 적극 옹호한 대표적인 글이다. Jakob Nielsen 도 Paper Prototyping (2003)에서 종이 프로토타입으로 초기 설계 아이디어를 극히 낮은 비용으로 사용자 테스트할 수 있다고 썼다.

정밀도 장점 단점
낮음(종이, 화이트보드) 몇 분 만에 고친다. 사용자가 “미완성” 이라 느껴 구조에 대해 솔직히 말한다 세밀한 상호작용·성능은 확인 불가
중간(클릭 가능한 와이어프레임) 흐름과 화면 전환 확인 색·문구에 대한 피드백이 섞이기 시작
높음(실제 같은 시안·동작 코드) 실제 감각, 이해관계자 설득 비싸고, 사용자가 표면만 평하며, “거의 다 됐다” 는 오해를 낳는다

사람이 시스템을 연기한다: 오즈의 마법사

아직 만들 수 없는 기능(자연어 처리, 추천 등)의 요구를 확인하고 싶을 때는 사람이 뒤에서 시스템의 응답을 대신하는 방법이 있다. J. F. Kelley 의 An iterative design methodology for user-friendly natural language office information applications (ACM TOIS, 1984)는 이런 실험 단계로 시작해 시스템을 반복 설계한 연구로, 흔히 “오즈의 마법사(Wizard of Oz)” 기법의 초기 문헌으로 인용된다. 요구 관점에서 이 방법의 가치는 “사용자가 실제로 무엇을 묻는가” 를 만들기 전에 수집한다는 데 있다.

프로토타입과 위험: 나선형 모델

Barry Boehm 의 A Spiral Model of Software Development and Enhancement (IEEE Computer, 1988)는 각 주기에서 가장 큰 위험을 먼저 확인하고 줄이는 위험 주도 프로세스를 제안했고, 프로토타이핑은 그 위험 해소의 주된 수단이다. 실무로 옮기면 이렇다. 프로토타이핑할 대상은 “가장 불확실하고, 틀리면 가장 비싼 요구” 다. 확실한 요구에 프로토타입을 만드는 것은 낭비다.

몇 명에게 보여 줄까

Nielsen 은 Why You Only Need to Test with 5 Users (2000)에서 Landauer 와 함께 만든 모형을 소개한다. 사용자 n 명으로 찾는 문제 수는 \(N(1-(1-L)^n)\) 이고, 사용자 한 명이 찾는 문제 비율 L 은 그들이 연구한 프로젝트 평균 31% 였다.

# Nielsen & Landauer 모형: 사용자 n 명으로 찾는 문제 비율 = 1 - (1 - L)^n
def found(n, L):
    return 1 - (1 - L) ** n

print(" n   L=0.31  L=0.15")
for n in (1, 2, 3, 5, 10, 15):
    print(f"{n:2}   {found(n, 0.31):5.0%}   {found(n, 0.15):5.0%}")

 n   L=0.31  L=0.15
 1     31%     15%
 2     52%     28%
 3     67%     39%
 5     84%     56%
10     98%     80%
15    100%     91%

L=0.15 열은 문제가 덜 드러나는 경우를 가정한 비교값이다. Nielsen 의 결론은 “5명이면 충분하다” 가 아니라 “큰 테스트 한 번보다 5명짜리 작은 테스트를 여러 번” 이다. 첫 테스트에서 찾은 문제를 고치고 다시 테스트해야 고친 설계가 정말 나아졌는지, 더 깊은 문제가 있는지 알 수 있기 때문이다. 같은 글은 사용자 집단이 뚜렷이 다르면 집단마다 3~4명씩 테스트하라고 권한다. 그리고 L 이 낮은 상황(복잡한 업무 시스템 등)이면 같은 인원으로 찾는 비율이 크게 떨어진다는 것도 위 표가 보여 준다.

실무 적용

프로토타입 계획서 (한 장)

prototype: P-05 지난 주문 다시 담기
question: 단골 고객은 '다시 담기' 를 첫 화면에서 찾고, 실제로 쓰려 하는가?
dimension: 역할                      # 역할 / 외형과 느낌 / 구현
linked_requirements: [REQ-ORD-021]   # 추적성(SE100 #019)
fidelity: 낮음 — 종이 화면 6장
participants: 단골 5명, 신규 고객 3명   # 집단별
tasks:
  - "지난주에 마신 음료를 다시 주문해 보세요"
success_criteria:
  - 단골 5명 중 4명 이상이 안내 없이 1분 안에 기능을 찾는다
decision_rule:
  - 성공 → REQ-ORD-021 을 Should 로 확정(SE100 #017)
  - 실패 → 진입 위치 변경 후 재시험, 2회 실패 시 범위에서 제외
disposal: 종료 후 폐기 (제품 코드로 쓰지 않음)

핵심은 결정 규칙을 미리 적는 것이다. 결과를 본 뒤에 해석 기준을 정하면 거의 언제나 “반응이 좋았다” 로 결론 난다.

진행할 때의 원칙

  • 기능을 설명하지 말고 과제를 준다. “이 버튼은 다시 담기예요” 라고 말하는 순간 검증할 것이 사라진다.
  • 생각을 소리 내어 말하게 하고, 관찰자는 개입하지 않는다.
  • “마음에 드세요?” 대신 “지금 무엇을 하려고 하셨어요?” 를 묻는다. 선호가 아니라 행동을 본다.
  • 결과는 요구 ID 별로 기록한다. 확인됨 / 수정 필요 / 기각.

큰 질문에는 타임박스

여러 요구가 얽힌 큰 질문이라면 GV 의 디자인 스프린트처럼 기간을 고정하는 방법이 있다. 월요일에 문제를 지도로 그리고 목표를 정하고, 화요일에 해법을 스케치하고, 수요일에 결정하고, 목요일에 프로토타입을 만들고, 금요일에 실제 사람에게 테스트하는 5일 과정이다. 핵심은 만들기 전에 배우는 데 있다.

흔한 오해와 함정

  • 프로토타입이 제품이 된다. 탐색용 코드를 진화시키면 품질을 포기한 코드가 기초가 된다. 버릴 계획을 먼저 합의하고, 화면에도 “시안” 표시를 남긴다.
  • 정밀도를 너무 높인다. 고정밀 시안은 색과 문구에 대한 피드백을 부르고, 이해관계자에게 일정에 대한 착각을 준다. 질문이 허락하는 가장 낮은 정밀도로 만든다.
  • 질문 없이 만든다. “일단 만들어서 보여 주자” 는 무엇을 확인했는지 남기지 못한다. 질문·차원·성공 기준을 한 장에 먼저 적는다.
  • “5명이면 충분” 을 한 번의 테스트로 읽는다. Nielsen 의 요지는 작은 테스트의 반복이다. 집단이 다르면 집단별로 본다.
  • 사용자 의견을 요구로 그대로 옮긴다. 사용자가 “버튼을 하나 더 주세요” 라고 하면 그것은 해법 제안이다. 그 뒤의 문제(무엇을 못 찾았나)를 요구로 적는다.

확인 문제

  1. Floyd 의 세 가지 프로토타이핑 중 요구사항 확인에 주로 쓰는 것은 무엇이고, 그것을 제품으로 키우면 왜 위험한가?
  2. Houde 와 Hill 의 세 차원 중 “단골이 다시 담기를 정말 쓸까?” 는 어느 차원의 질문인가? 그에 맞는 정밀도는?
  3. 오즈의 마법사 방식이 요구 도출에 주는 이점은?
  4. Nielsen 이 15명 한 번보다 5명씩 세 번을 권하는 이유는?
  5. 프로토타입 계획서에 결정 규칙을 미리 적어야 하는 이유는?

풀이

  1. 탐색적 프로토타입. 빨리 배우려고 품질을 포기하고 만든 것이라 제품의 기초로 쓰면 구조적 부채를 안고 시작한다.
  2. 역할 차원. 낮은 정밀도(종이 화면, 시나리오)로 충분하고, 오히려 그래야 사용자가 표면이 아닌 쓸모에 대해 반응한다.
  3. 아직 만들 수 없는 기능에 대해 사용자가 실제로 무엇을 요청하고 어떻게 말하는지를 개발 전에 수집할 수 있다.
  4. 첫 테스트에서 찾은 문제를 고친 뒤 다시 테스트해야 수정이 효과가 있었는지, 가려져 있던 더 깊은 문제가 무엇인지 알 수 있다. 같은 예산을 여러 번의 반복에 나누는 것이 설계를 더 많이 개선한다.
  5. 결과를 본 뒤 기준을 정하면 확증 편향으로 거의 늘 긍정적 결론이 나온다. 미리 정한 기준이 있어야 요구를 확정·수정·기각할 수 있다.

더 읽을거리 (References)