문제를 보는 눈: 퍼실리테이터 가이드

"빠른 응답"        → 얼마나 빠른? 200ms? 2초?
"사용하기 편리한"   → 누구에게? 어떤 상황에서?
"안전한"           → 어떤 위협으로부터? 어떤 수준으로?
"더 좋게"          → 무엇 기준으로?

"알림 강화"
  BizDev가 상상한 것:    고객사 팀장 PC에 팝업
  백엔드 개발자:          이메일 / 슬랙 webhook
  프론트엔드 개발자:      인앱 뱃지, 빨간 점
  사용자(팀원):           카톡 오면 안 되나?

"지금처럼 동작해야 해요"     → 지금이 어떻게 동작하는지 아는가?
"당연히 그건 안 되겠죠"      → 무엇이 당연한가?
"기존 방식을 유지하면서"     → 기존 방식이 무엇인가?
"빠르게 만들어주세요"        → 얼마나 빠르게? 무엇을 포기하고?

           Functions
           (무엇을 하는가)
               △
              / \
             /   \
            /     \
           /       \
Attributes ─────── Constraints
(어떻게 해야 하는가)  (건드릴 수 없는 것)

비교 포인트
────────────
"같은 칸에 다른 것을 적은 경우가 있는가?"
  → 그 차이 자체가 해석자 간 모호함의 실례입니다.

"누군가 Attribute를 Function으로 적은 경우가 있는가?"
  → 왜 그렇게 분류했는지 이야기해보게 합니다.

"Constraints 칸이 가장 비어있는 경향이 있는가?"
  → 대부분 그렇습니다. Constraint는 가장 캐내기 어렵습니다.
     "왜 이건 생각이 안 났을까?"를 메타적으로 물어보세요.

"지금 이 문제를 어떻게 해결하고 있나요?"
"이 작업을 하는 사람이 누구인가요? 몇 명인가요?"
"이 문제가 가장 심각하게 느껴지는 순간은 언제인가요?"
"이게 해결되지 않으면 어떤 일이 생기나요?"
"지금 임시방편으로 쓰고 있는 방법이 있나요?"

"이 시스템이 반드시 해야 하는 것은 무엇인가요?"
"절대 해서는 안 되는 것은 무엇인가요?"
"어떤 상태가 되면 '잘 됐다'고 할 수 있나요?"
"지금 없는 것 중, 있으면 가장 좋겠다는 것은?"
"누가 이것의 성공 여부를 판단하나요?"

"제가 이런 질문을 해도 괜찮겠습니까?"
"제가 놓친 것이 있을까요?"
"제가 이해한 것이 맞는지 확인해도 될까요?"
"이 주제에 대해 더 잘 아는 사람을 연결해주실 수 있나요?"
"제 질문 중 잘못된 방향으로 가고 있는 것이 있나요?"

┌─────────────────────────────────────────────┐
│                                             │
│  Trigger ──→ [   Black Box   ] ──→ Output   │
│                                             │
│                  ↕ 예외 조건                 │
│                                             │
└─────────────────────────────────────────────┘

비교 포인트
────────────
"같은 인터뷰 대상인데 Black Box가 얼마나 다른가?"
  → 질문의 방향이 달랐기 때문입니다.
    어떤 질문이 어떤 발견을 만들었는지 역추적해보세요.

"예외 케이스를 가장 많이 찾은 팀은 어떤 질문을 했는가?"
  → "절대 해서는 안 되는 것"과 "이 기능이 실패하는 조건"을
    물어본 팀이 예외를 더 많이 발견합니다.

"Meta-Question을 쓴 팀에서 어떤 일이 생겼는가?"
  → '제가 놓친 게 있나요?'가 가장 새로운 정보를 끌어냅니다.
    이 경험을 전체 공유에서 꺼내세요.

┌─────────────────────────────────────────────────────────────┐


==== 디브리프 가이드

=== 5. 디브리프 (10분)

_퍼실리테이터 가이드 — 예상 저항과 대응_

'''



'''


== 지도를 그리기 전에 — 문제의 구조와 Domain Model

=== 시간 배분

[cols="1,1,1", options="header"]
|===
| 순서 | 내용 | 시간
|  | 0. 전강 연결 | 5분
|  | 1. 오프닝 도발 — 두통약 비유 | 10분
|  | 2. 개념 설명 (레이어 3개, Problem Framing, Domain Model) | 20분
|  | 3. 고정 케이스 실습 — 워크시트 A-4 | 30분
|  | 4. 현업 케이스 슬롯 — 워크시트 B-4 | 20분
|  | 5. 디브리프 | 10분
|  | 6. 과제 카드 #4 배포 | 5분
|  | *합계* | *100분*
|===

=== 강의 운영 주의사항

- ★ 레이어 분류에서 정답을 주지 마세요. '우리가 어느 레이어를 고치려는가'의 합의가 목표입니다.
- ★ Domain Model 스케치 시 State(상태) 설계가 가장 많이 갈립니다. '배정됨'과 '확인됨'의 차이를 팀마다 다르게 그렸다면 전체 비교로 꺼내세요.
- ★ '근본 원인까지 항상 해결해야 하나?'는 중요한 질문입니다. '의식적 선택'임을 강조하세요. 5강 Spike와 7강 Risk의 복선입니다.
- ★ Domain Model이 '문서'가 아니라 '팀 어휘 정렬 과정'임을 반복해서 짚어주세요.

=== 강의 진행 상세

=== 0. 전강 연결 (5분)

'''

=== 1. 오프닝 도발 (10분)

_"두통약 비유"_

슬라이드나 말로 짧게 씁니다.

[quote]
____
_어떤 사람이 매일 아침 두통을 호소합니다._
____
[quote]
____
_병원에 갔더니 의사가 두통약을 처방해줬습니다._
____
[quote]
____
_약을 먹으면 두통이 가라앉습니다._
____
[quote]
____
_그런데 다음 날 아침, 두통이 또 옵니다._
____

[quote]
____
_두통은 증상입니다._
____
[quote]
____
_알고 보니 원인은 — 매일 아침 수면 부족과 카페인 과다였습니다._
____

[quote]
____
_두통약은 증상을 해결했지만, 문제를 해결하지 않았습니다._
____

잠시 후 묻습니다.

[quote]
____
"소프트웨어 개발에서 이런 일을 해본 적 있나요?
____
[quote]
____
요청받은 것을 만들었는데, 얼마 후 비슷한 요청이 또 왔던 경험."
____

손을 들게 합니다. 대부분 들 것입니다.

[quote]
____
"그것이 증상을 고쳤기 때문입니다.
____
[quote]
____
이번 강은 — 증상과 문제와 근본원인을 구분하는 방법,
____
[quote]
____
그리고 문제를 충분히 이해했다는 것을 어떻게 아는가입니다."
____

'''

=== 2. 개념 설명 (20분)

==== 개념 1 — 문제의 세 레이어 (10분)

모든 문제 상황에는 세 개의 레이어가 있습니다.

왜 구분이 중요한가?

하지만 항상 근본 원인까지 파야 한다는 뜻은 아닙니다. _어느 레이어에서 해결할 것인지는 의식적인 선택_이어야 합니다. 지금 당장의 데모를 위해 증상 레이어에서 해결하기로 결정하는 것은 괜찮습니다 — 그것이 결정인 줄 알고 있다면.

'''

_Problem Framing — 어떻게 보느냐에 따라 해결책이 달라진다_

같은 현상을 어떻게 프레임하느냐에 따라 Problem Space의 모양이 달라집니다.

이 중 어떤 프레임이 "맞는가"는 지금은 모릅니다. 하지만 _한 가지 프레임만 있다는 것이 가장 위험합니다._ 여러 프레임이 가능하다는 것을 인식하는 것이 첫 번째 훈련입니다.

'''

==== 개념 2 — Domain Model vs Design Model (Fairbanks) (10분)

Fairbanks는 소프트웨어를 둘러싼 모델을 세 가지로 구분합니다.

_Domain Model — 현실 세계의 개념들_

이 시스템이 다루는 _실세계의 사람, 행위, 규칙, 상태_입니다.

팀오더 케이스에서 Domain Model의 요소들:

_Design Model — 만들 소프트웨어의 구조_

ERD, API 설계, 시스템 다이어그램. 여기서부터 Solution Space입니다.

대부분의 엔지니어가 하는 실수:

Domain Model을 건너뛰면 무슨 일이 생기는가?

설계한 것이 현실의 개념과 어긋납니다. 개발 중에 "이 케이스는 어떻게 처리하죠?"라는 질문이 반복됩니다. 그 질문들은 대부분 Domain Model 레이어에 있는 것들입니다.

_Domain Model이 충분히 안정됐을 때가 Design Model로 넘어갈 시점입니다._

어떻게 아는가? 팀이 같은 도메인 어휘를 쓰고 있을 때. "업무"와 "태스크"를 혼용하지 않을 때. "배정됨"과 "확인됨"이 구분될 때.

'''

=== 3. 고정 케이스 실습 (30분)


==== 소그룹 공유 가이드

_소그룹 공유 (7분)_

각 그룹의 Domain Model을 칠판에 나란히 붙이거나 그립니다.

퍼실리테이터 가이드:

'''

=== 4. 현업 케이스 슬롯 (20분)

==== 워크시트 B-4 | 내 현업 케이스: 레이어 분석 + Domain Model

┌─────────────────────────────────────────────────────────┐
│  Resolvable Ambiguity (해소 가능한 모호함)               │
│                                                         │
│  • 누군가는 알고 있다                                    │
│  • 질문하면, 조사하면 답이 나온다                         │
│  • 1-4강의 도구가 유효하다                               │
│                                                         │
│  예: "알림 응답 속도 기준이 뭔가요?"                     │
│      "야간 운영이 있나요?"                               │
│      "예산 한도가 어떻게 되나요?"                        │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│  Essential Ambiguity (본질적 모호함)                     │
│                                                         │
│  • 아무도 아직 모른다                                    │
│  • 질문해도 답이 없다 — 현실이 아직 결정되지 않았다       │
│  • 해봐야, 만들어봐야, 시장에 내놓아봐야 안다             │
│                                                         │
│  예: "사용자가 이 기능을 실제로 쓸까요?"                 │
│      "이 방식이 우리 팀의 워크플로우에 맞을까요?"         │
│      "어떤 알림 형식이 이 환경에서 효과적일까요?"        │
└─────────────────────────────────────────────────────────┘

목적:  이 기술이 이 요구사항을 충족하는가?
       이 방식이 이 환경에서 동작하는가?

방법:  최대한 단순하게, 빠르게, 버릴 것을 알고 만든다
       프로덕션 품질 불필요

결과:  Yes/No 또는 새로운 질문
       코드가 아니라 학습이 산출물

이 모호함 앞에서 나는 어떻게 할 것인가?

질문 1: 이것을 알기 위해 내가 할 수 있는 행동이 있는가?
         있다면 → Resolvable → Weinberg 전략 (질문, 인터뷰)

질문 2: 행동해도 여전히 불확실하다면?
         → Essential → Cunningham 전략 (Spike, 최소 행동)

질문 3: 지금 이 결정이 꼭 필요한가?
         필요하지 않다면 → 결정을 미루는 것이 전략
         (Fairbanks의 "Just Enough" 정신)

비교 포인트
────────────
"같은 모호함을 R로 분류한 팀과 E로 분류한 팀이 있는가?"
  → 왜 다르게 봤는지가 핵심입니다.
    실제로 행동이 가능한데 E로 분류한 것은 없는가?
    반대로, 아무도 모르는데 R로 분류한 것은 없는가?

"Spike를 설계할 때 가장 막힌 것은 무엇인가?"
  → '가장 단순한'의 기준을 잡는 것.
    "이것보다 더 단순하게 할 수 있는가?"를
    반복해서 묻도록 유도합니다.

"'지금 결정 안 해도 된다'는 칸을 활용했는가?"
  → 이 판단 자체가 중요한 역량입니다.
    모든 모호함을 지금 해소해야 한다는 강박에서 벗어나는 것.

1단계: 구조 추출
  이 문제의 핵심 구조는 무엇인가?
  (인물, 행위, 관계, 제약을 추상화)

2단계: 유사 문제 탐색
  이 구조와 닮은 문제가 다른 도메인에 있는가?

3단계: 원리 역수입
  유사 문제의 해결 원리를 이 문제에 적용한다
  (해결책 자체가 아니라 원리를)

1단계 구조 추출:
  "여러 수신자에게 메시지를 전달하는데,
   수신자의 상태(온라인/오프라인/절전)가 불확실하고,
   메시지의 긴급도가 다르다"

2단계 유사 문제 탐색:
  • 병원 응급실 트리아지 — 환자 긴급도에 따른 순서
  • 항공 관제 — 여러 항공기의 우선순위 통신
  • 이메일 스팸 필터 — 중요도에 따른 분류
  • TCP 재전송 — 패킷 미수신 시 재시도 메커니즘
  • 트위터 알림 배치 — 중요 알림은 즉시, 나머지는 묶음

3단계 원리 역수입:
  TCP 재전송 원리:
    "전달 확인이 안 오면 재전송한다"
    → 팀원 알림 확인(acknowledgement)이 없으면 재알림
  트리아지 원리:
    "긴급도에 따라 채널을 다르게 쓴다"
    → 야간 긴급은 별도 채널(SMS/전화), 일반은 앱 푸시

"이건 결국 어떤 종류의 문제인가?"

비즈니스 리서치 질문 프레임:

"이 서비스는 무엇을 최우선으로 했는가?"
"무엇을 포기했는가?"
"왜 이 방식을 선택했을까?"
"어떤 사용자/환경에 최적화되어 있는가?"
"어떤 상황에서 이 설계가 실패하는가?"

비교 포인트
────────────
"팀마다 다른 유사 사례를 찾았는가?"
  → 같은 문제에서 전혀 다른 도메인의 유사 사례가 나올 수 있습니다.
    병원 트리아지를 찾은 팀과 TCP 재전송을 찾은 팀이 있다면
    둘 다 맞습니다. 그리고 둘에서 끌어낸 원리가 다를 것입니다.
    그 차이를 칠판에 나열해보세요.

"원리를 역수입할 때 막힌 부분은?"
  → "해결책을 복사하려 했는가, 원리를 가져오려 했는가?"를
    확인합니다. 전자는 대부분 "우리 상황에 안 맞아요"로 끝납니다.

"비즈니스 리서치에서 Trade-off를 읽는 것이
 단순한 기능 비교와 어떻게 달랐는가?"
  → 이 질문을 꺼내서 리서치 관점의 차이를 언어화하게 합니다.

Functionality (기능)
────────────────────
"시스템이 무엇을 하는가"
예: 알림을 보낸다, 업무를 배정한다, 목록을 보여준다

→ 스프린트마다 쌓을 수 있습니다
→ 나중에 추가하기 상대적으로 쉽습니다


Quality Attributes (품질 속성, the "-ilities")
────────────────────────────────────────────────
"시스템이 얼마나 잘 하는가"
예: 성능(Performance), 가용성(Availability), 보안(Security),
    확장성(Scalability), 변경용이성(Modifiability)

→ 아키텍처 결정으로 확보됩니다
→ 나중에 바꾸면 재작업이 매우 비쌉니다
→ 기능과 달리 서로 Trade-off 관계입니다

기능을 나중에 추가하는 비용:   선형적
Quality Attribute를 나중에 추가하는 비용: 기하급수적

Risk-Driven Model — 3단계 루프

┌─────────────────────────────────────────────────┐
│                                                 │
│  1. 실패 리스크 식별                             │
│     "이것이 실패하면 프로젝트가 죽는가?"         │
│                                                 │
│           ↓                                     │
│                                                 │
│  2. 리스크에 맞는 기법 선택                      │
│     Engineering risk → Engineering 기법만 유효  │
│                                                 │
│           ↓                                     │
│                                                 │
│  3. 리스크가 충분히 낮아지면 중단                │
│     "Just Enough" — 설계는 수단, 완성이 목적    │
│     아님                                        │
│                                                 │
└─────────────────────────────────────────────────┘

Engineering Risk               Project Management Risk
────────────────────────────   ──────────────────────────────
시스템 분석/설계/구현의 문제   일정, 팀 규모, 우선순위의 문제

"성능이 요구사항을 못 맞춘다"  "3주 안에 못 끝낼 것 같다"
"데이터 일관성을 보장 못 한다" "팀원이 이 기술을 모른다"
"보안 취약점이 있다"           "요구사항이 계속 바뀐다"

→ Engineering 기법으로 해소    → PM 기법으로 해소
  (프로토타입, 부하 테스트,      (일정 조정, 교육,
   threat modeling 등)           프로세스 개선 등)

아래 항목 중 "YES"가 있으면 Engineering Risk로 간주

□ 이 시스템의 응답 시간 요구사항이 까다로운가?
□ 데이터 일관성이 중요한 시스템인가?
□ 보안 민감 데이터를 다루는가?
□ 트래픽이 급격히 증가할 가능성이 있는가?
□ 여러 팀이 같은 컴포넌트를 건드리는가?
□ 특정 컴포넌트 장애가 전체 장애로 이어지는가?
□ 나중에 기능 추가/변경이 많이 예상되는가?
□ 외부 시스템/서비스와의 통합이 복잡한가?

리스크가 낮은 영역:
  정교한 설계를 하는 것이 오히려 낭비
  → Cunningham: Simplest Thing
  → Fairbanks: 설계 중단

리스크가 높은 영역:
  설계를 충분히 하지 않는 것이 실패의 원인
  → Fairbanks: 리스크에 맞는 기법 선택
  → Cunningham: Spike로 빠르게 탐색

비교 포인트
────────────
"팀마다 상위 3개 리스크가 다른가?"
  → 같은 시스템인데 리스크 우선순위가 다르다면
    어떤 맥락 차이가 그 판단을 만들었는가?
    데모 관점 vs 실서비스 관점의 차이일 수 있습니다.

"PM Risk와 Engineering Risk를 혼동한 경우가 있는가?"
  → 가장 자주 섞이는 것:
    "1개월 안에 못 만들 것 같다" → PM Risk
    "야간 알림 전달을 보장 못 할 것 같다" → Engineering Risk
    이 둘에 대응하는 기법이 완전히 다름을 짚어줍니다.

"PART 4 — '지금 안 해도 된다'는 결정이 어려웠는가?"
  → 어려웠다면 — 왜 어려웠는가?
    "완벽하게 설계해야 한다"는 압박과 어떻게 타협하는가?
    이것이 이 강의 핵심 인식 전환입니다.

Problem-Solution Fit 체크:

┌──────────────────────────────────────────────────┐
│ 문제 정의 (Problem Space 탐색 결과)               │
│                                                  │
│  - 누가 고통받는가?                               │
│  - 어떤 상황에서?                                 │
│  - 현재 어떻게 임시방편을 쓰는가?                 │
│  - 이것이 해결되지 않으면 어떤 비용이 발생하는가? │
│                                                  │
│           ↕  대응이 되는가?                       │
│                                                  │
│ 해결책 (Solution Space 탐색 결과)                 │
│                                                  │
│  - 이 기능은 누구의 고통을 덜어주는가?            │
│  - 어떤 상황에서 작동하는가?                      │
│  - 임시방편을 대체하는가?                         │
│  - 해결되지 않는 부분은 무엇인가?                 │
└──────────────────────────────────────────────────┘

문제: "팀원이 업무를 놓쳐서 라인이 멈춘다"
해결책: "예쁜 알림 UI + 읽음 표시 + 알림 히스토리 페이지"

→ 읽음 표시와 히스토리 페이지가 라인 스탑을 막는가?
  문제의 핵심(전달 보장)이 빠져 있다.

일반 리뷰                    Pre-mortem
────────────────────────     ─────────────────────────────
성공 편향이 생긴다            실패를 상상하므로 편향이 줄어든다
"잘 될 거야"                  "실패했다면 왜?"
약점을 찾기 어렵다            약점이 자연스럽게 나온다
팀 분위기상 비판하기 어렵다   가상의 실패이므로 심리적 안전

1. "이 해결책을 실제로 도입했다고 가정하세요."
2. "6개월이 지났습니다."
3. "실패했습니다. 어떤 이유로?"
4. 개인별로 3가지 이상 적기 (2분)
5. 소그룹 공유 → 가장 많이 나온 실패 이유 상위 3개 추출
6. 그 이유를 미리 대응할 수 있는가?

"6개월 후 팀오더 알림 기능이 실패한 이유들"

• 야간 긴급 SMS 비용이 예상보다 많이 나와서 기능을 끔
• 팀원들이 알림을 너무 많이 받아서 끄기 시작함
• iOS 업데이트 후 백그라운드 알림 정책이 바뀜
• 팀장이 수신 확인 안 한 팀원에게 어떻게 해야 할지 몰라 안 씀
• 공장 시스템 방화벽이 FCM 차단함 (나중에 발견)

이 강의 핵심 비교 포인트
────────────────────────
"PART 3에서 '만들지 않아도 되는 것이 생겼다'에
 체크한 사람이 있는가?"
  → 이것이 이 강의, 그리고 워크샵 전체의 핵심 결론입니다.
    그들에게 물어보세요:
    "무엇이 사라졌나요? 왜 사라져도 된다고 알게 됐나요?"

"해결책이 더 단순해졌는가?"
  → 더 단순해진 팀: 어느 강에서 그 단순화가 생겼는가?
    (2강 FAC? 4강 레이어 선택? 5강 Spike? 7강 Risk?)

"Pre-mortem에서 나온 실패 이유 중
 2강-4강의 도구로 미리 잡을 수 있는 것이 있는가?"
  → 이 연결이 보이면 워크샵 전체의 학습이 통합된 것입니다.