성공이 만든 덫: 현재 현실 나무로 찾는 진짜 문제

정호의 미니 게임 카페

정호는 동네에서 작은 보드게임 카페를 운영한다. 처음에는 단순했다. 테이블 다섯 개, 인기 게임 열 개, 혼자서 주문 받고 커피 내리고 게임 설명하고. 손님들이 "여기 분위기 좋네요"라며 친구들을 데려왔다.

반년 만에 입소문이 났다. 주말엔 대기가 생겼다. 정호는 기뻤다. "확장할 때가 됐어!"

그는 옆 가게를 빌려 테이블을 열 개로 늘렸다. 손님들이 "이 게임도 있었으면 좋겠어요"라고 할 때마다 게임을 샀다. 50개, 100개... 어느새 게임 목록이 200개를 넘었다. 예약 문의가 많아지자 예약 시스템을 만들었다. 단체 손님이 늘자 파티룸을 추가했다. 팀을 꾸렸다—알바 세 명.

1년 후, 정호는 하루 종일 뛰어다녔다.

"저기요, 이 게임 설명서 어디 있어요?" "정호 씨, 이 게임 말이 부족한데요?" "예약이 겹쳤어요. 어떻게 하죠?"

새 알바들은 게임 설명을 못 했다. 200개나 되는 게임을 어떻게 다 외워? 정호만 모든 게임을 알았다. 게임 정리도 엉망이었다. 전략 게임과 파티 게임이 뒤섞여 있었다. 부품이 빠진 게임도 많았다. 새 게임을 사도 정리할 시간이 없었다.

더 큰 문제는 다음이었다: 손님들이 "예전보다 게임 추천이 별로예요"라고 했다. 정호는 늘 뭔가를 고치거나 찾는 데 바빴다. 정작 손님과 이야기할 시간이 없었다. 예전 단골들이 "여기 분위기 변했어요"라며 발길을 끊기 시작했다.

어느 저녁, 정호는 노트를 펼쳤다. "도대체 뭐가 잘못된 거지?"

그는 불만 사항들을 적기 시작했다:

"이걸 다 해결하려면... 어디서부터?"

정호는 한숨을 쉬었다. 각 문제를 하나씩 고치려니 끝이 없어 보였다. 알바 교육을 강화할까? 게임을 줄일까? 아니면 더 고용할까?

그런데 문득 이런 생각이 들었다. 이 문제들이 독립적인 게 아니라 서로 연결되어 있다면? 하나를 해결하면 여러 개가 동시에 나아질 수도 있지 않을까?

문제의 지도를 그려보자

정호가 겪는 상황은 스타트업에서 흔히 발생하는 패턴이다. 초기 성공 → 급성장 → 복잡도 폭발 → 속도 저하. 이런 얽힌 문제들을 풀어내는 강력한 도구가 있다. 바로 현재 현실 나무(Current Reality Tree, CRT)다.

CRT는 제약이론(Theory of Constraints)의 사고 프로세스 도구 중 하나로, 복잡한 문제 상황에서 "무엇을 바꿔야 하는가"를 찾아낸다. 핵심 아이디어는 이것이다: 겉으로 보이는 여러 문제들은 사실 하나 또는 소수의 근본 원인에서 파생된다.

브레인스토밍이 문제를 나열한다면, CRT는 문제들 사이의 인과관계 지도를 그린다. 5 Whys가 한 문제를 선형적으로 파고든다면, CRT는 여러 문제가 어떻게 그물망처럼 엮여있는지 보여준다.

CRT의 구성 요소

CRT를 이해하려면 네 가지 핵심 개념을 알아야 한다.

1. UDE (Undesirable Effect, 바람직하지 않은 결과)

시스템에서 관찰되는 부정적 현상이다. 중요한 건, UDE는 증상이지 원인이 아니라는 점이다.

정호의 예:

스타트업의 전형적 UDE:

2. 인과관계 (Causality)

CRT의 엣지(화살표)는 "If A, then B" 형태의 충분조건 논리다. 이게 핵심이다.

예시:

AND 조건(여러 원인이 동시에 필요)을 표시할 때는 화살표들을 동그라미나 타원으로 묶는다.

3. 중간 효과 (Intermediate Effects)

UDE와 근본 원인 사이를 이어주는 노드다. 이게 없으면 논리적 도약이 커서 "정말 그런가?" 의문이 생긴다.

예를 들어:

중간 효과를 채워가는 과정이 바로 "왜?"를 반복하며 인과 사슬을 완성하는 것이다.

4. 근본 원인 (Root Cause / Core Problem)

대부분의 UDE로 연결되는 가장 밑바닥의 원인이다. CRT의 최종 목표는 이걸 찾는 것이다.

좋은 근본 원인의 조건:

정호의 게임 카페 CRT

정호가 화이트보드에 그린 CRT는 이렇게 생겼다: 

                 [손님들이 게임 추천에 불만]
                            ↑
                 [정호가 손님 응대할 시간 없음]
                            ↑
                 [항상 뭔가를 고치거나 찾음]
                            ↑
              [알바들이 독립적으로 일하지 못함]
                     ↗              ↖
    [알바들이 게임 설명 못 함]    [게임 관리가 체계적이지 않음]
              ↑                           ↑
    [게임이 200개나 됨]          [분류/수납 시스템 없음]
              ↑                           ↑
         [무분별한 확장]          [시스템화 없이 성장]
              ↑___________________________↑
                          |
               [핵심 원인: 초기 성공에 도취되어
                규모만 키우고 운영 구조는 안 만듦]

정호는 이 그림을 보는 순간 깨달았다. 문제는 알바가 부족하거나 게임이 많은 게 아니었다. 정호의 머릿속에만 있는 정보(어떤 게임이 어디 있고, 어떤 손님에게 어떤 걸 추천할지)를 시스템으로 만들지 않았기 때문이었다.

IT 비즈니스로 옮겨보자

이제 같은 패턴을 소프트웨어 회사에 적용해보자.

스타트업의 전형적 시나리오

시작: POC 제품 출시 → 시장 반응 좋음 → 빠른 성장

확장:

결과:

스타트업 CRT 예시

[제품 개선 속도가 느려짐] ← [신규 기능 추가가 어려움]
                                     ↑
                         [코드베이스가 복잡함]
                                     ↑
         [초기 POC 코드 위에 계속 덧붙임] + [리팩토링 시간 없음]
                      ↑                              ↑
          [빠른 시장 출시 압박]              [항상 새 기능 요청]
                      ↑                              ↑
               [PMF 발견] + [기술 부채 관리 프로세스 부재]
                      ↑________________________________↑
                                    |
                      [핵심 원인: 제품-시장 적합성 발견 후
                       기술적 토대 개선 없이 기능만 추가]

근본 원인을 다르게 표현하면: "정보(코드 구조, 설계 의도)를 개발자 머리에서 코드/문서로 이동시키지 않았다."

정호의 게임 카페와 동일한 패턴이다.

CRT 그리는 법: 실전 가이드

이론은 간단해 보이지만, 실제로 그려보면 어렵다. 이건 정상이다. 첫 CRT는 엉망일 수 있고, 여러 번 그려야 패턴이 보인다.

준비물

단계 1: UDE 나열하기 (20분)

팀 미팅에서 불편한 점을 모두 적는다.

규칙:

이 단계에서 많은 팀이 놀란다. "우리가 이렇게 많은 문제를 안고 있었어?"

단계 2: 인과관계 찾기 (40-60분)

포스트잇들을 벽에 붙이고 연결하기 시작한다.

방법: 1. 두 UDE를 골라 "A가 있으면 B가 발생한다"고 말할 수 있는지 확인 2. 논리가 명확하면 화살표로 연결 3. "왜?"를 계속 물으며 깊이 파고들기

주의사항:

예시:

단계 3: 중간 효과 채우기 (30-40분)

논리적 도약이 큰 곳을 찾아 빈칸을 채운다.

신호:

예시:

이 단계에서 진짜 이해가 깊어진다. 우리가 "왜 이런 일이 벌어지는지" 정확히 알게 된다.

단계 4: 근본 원인 식별 (20-30분)

이제 나무의 뿌리를 찾는다.

방법: 1. 가장 아래에 있는 노드들(더 이상 화살표가 들어오지 않음) 확인 2. 각 노드에서 출발하는 경로가 몇 개의 UDE로 연결되는지 세기 3. 가장 많은 UDE로 연결되는 것이 후보

검증 질문:

여러 근본 원인이 나올 수 있다. 보통 1-3개로 수렴한다. 모든 UDE를 설명할 수 있어야 한다는 강박은 버리자. 80%를 설명하는 것만으로도 충분히 가치 있다.

단계 5: 논리 검증 (20-30분)

완성된 CRT를 다시 검토한다.

검증 체크리스트:

TOC에는 "Categories of Legitimate Reservation"이라는 더 엄격한 검증 기법도 있지만, 처음엔 팀이 납득하면 충분하다.

팀 리뷰:

흔한 실수와 함정

CRT를 처음 그릴 때 빠지기 쉬운 덫들이 있다.

1. 증상을 근본 원인으로 착각하기

잘못된 예:

개선:

2. 통제 불가능한 원인에 집착하기

잘못된 예:

개선:

3. 너무 많은 근본 원인 찾기

잘못된 예:

개선:

4. 완벽주의

잘못된 예:

개선:

5. 혼자 그리기

잘못된 예:

개선:

CRT의 진짜 가치: 무엇이 다른가?

다른 문제 해결 기법과의 비교

5 Whys vs CRT

예시: "배포가 왜 느린가?"

피쉬본 다이어그램 vs CRT

예시: 피쉬본은 "사람: 교육 부족, 프로세스: 리뷰 없음"으로 나열. CRT는 "교육 부족 → 코드 품질 낮음 → 리뷰 시간 증가 → 리뷰 포기"의 인과 사슬 발견.

브레인스토밍 vs CRT

CRT의 독특한 강점은 "왜 이 문제들이 동시에 발생하는가?"에 답한다는 것이다.

실무에서의 시간 투자

초기 CRT 작성: 2-4시간

반복 개선: 매주 30분

ROI:

한 스타트업 CTO의 말: "CRT에 반나절 썼는데, 6개월치 우선순위가 명확해졌어요."

실전 사례: 정호와 스타트업은 무엇을 했나

정호의 게임 카페 (6개월 후)

CRT로 발견한 핵심 원인: "정보가 정호의 머리에만 있고, 시스템화되지 않음"

해결책: 1. 게임 카테고리 시스템: 난이도/인원수/시간별 색깔 라벨 2. 추천 가이드 북: "이런 손님에게는 이 게임" 플로우차트 3. 신규 알바 온보딩 체크리스트: 1주일 커리큘럼 4. 게임 부품 관리 시스템: 매일 마감 전 체크

결과:

스타트업 X사 (1년 후)

CRT로 발견한 핵심 원인: "MVP 코드를 production 코드로 착각하고 계속 덧붙임"

해결책: 1. 기술 부채 타임박스: 매 스프린트 20% 시간 할당 2. 핵심 모듈 리팩토링 로드맵: 6개월 계획 3. 아키텍처 의사결정 기록(ADR): 왜 이렇게 설계했는지 문서화 4. 코드 리뷰 가이드라인: 복잡도 임계값 설정

중간 과정 (3개월차):

결과 (12개월차):

완벽한 성공담이 아니다. 여전히 기술 부채는 있다. 하지만 이제는 통제할 수 있다. 어디가 아픈지, 왜 아픈지, 무엇부터 고쳐야 하는지 안다.

CRT를 시작하며: 당신의 문제는 무엇인가?

지금 당신의 조직에서 반복적으로 들리는 불만은 무엇인가?

이 불만들을 화이트보드에 적어보라. 그리고 물어보라: "이것들이 서로 연결되어 있다면?"

CRT는 복잡함 속에서 명료함을 찾는 도구다. 완벽할 필요는 없다. 틀릴 수도 있다. 하지만 팀과 함께 첫 번째 버전을 그리고, 토론하고, 개선하는 과정 자체가 가치다.

증상을 고치지 말고, 원인을 제거하라.

모든 문제를 동시에 해결하려 하지 마라. 하나의 핵심 원인을 찾아 제거하라. 그러면 얽혀있던 여러 문제가 한 번에 풀린다.

정호의 게임 카페도, 당신의 스타트업도, 그 시작은 한 장의 화이트보드에서 시작된다.

다음 단계: CRT 너머

CRT는 "What to Change(무엇을 바꿀 것인가)"만 답한다. TOC-TP는 여기서 멈추지 않는다:

하지만 그건 다음 이야기다. 일단 오늘은 당신의 첫 CRT를 그려보자.

실습 과제: 1. 다음 주 팀 미팅에 2시간 할애 2. 화이트보드와 포스트잇 준비 3. 팀원들에게 이 글 공유 (선택) 4. "우리 조직의 UDE 10개" 리스트 만들기 5. 그 UDE들을 연결하기 시작하기

당신의 CRT는 어떤 모습일까? 근본 원인은 무엇일까?

알아내는 것 자체가 이미 절반의 해결이다.