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

• "천 개의 증상을 고치는 것보다, 하나의 원인을 제거하는 것이 낫다."

정호의 미니 게임 카페

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

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

그는 옆 가게를 빌려 테이블을 열 개로 늘렸다. 손님들이 "이 게임도 있었으면 좋겠어요"라고 할 때마다 게임을 샀다. 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" 형태의 충분조건 논리다. 이게 핵심이다.

• "If A, then B"는 "A가 있으면 B가 반드시 발생한다"는 뜻
• 단순한 상관관계나 "A가 B에 기여한다"가 아님
• 이 엄격함 덕분에 개입 포인트가 명확해진다

예시:

• "If 알바들이 게임 설명을 못 한다 AND 정호만 게임을 안다, then 알바들이 독립적으로 일하지 못한다"

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

3. 중간 효과 (Intermediate Effects)

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

예를 들어:

• (잘못된 도약) "게임이 많다" → "손님이 불만족"
• (중간 효과 추가) "게임이 많다" → "알바가 설명 못 함" → "정호만 응대" → "손님이 불만족"

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

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

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

좋은 근본 원인의 조건:

• 많은 UDE와 연결됨
• 통제 가능함 (우리가 바꿀 수 있음)
• 구체적임 (추상적 개념이 아님)

정호의 게임 카페 CRT

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

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

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

IT 비즈니스로 옮겨보자

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

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

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

확장:

• 이 기능 필요, 저 기능 필요
• 컨셉 충돌로 spin-off 제품 생김
• 관리 포인트 증가

결과:

• 제품 개선 속도 느려짐
• 버그 증가
• 팀 사기 저하
• 성장 둔화

스타트업 CRT 예시

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

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

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

CRT 그리는 법: 실전 가이드

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

준비물

• 화이트보드나 큰 종이
• 포스트잇 (노드를 옮기며 실험하기 좋음)
• 팀원 2-5명 (혼자보다 팀이 훨씬 효과적)
• 2-3시간의 집중 시간

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

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

규칙:

• 비난 금지. "철수 때문에"가 아니라 "배포가 느리다"
• 사실만 기록. "느낌"이 아닌 관찰
• 판단 보류. "이건 중요해, 저건 별로"하지 말고 일단 다 적기
• 최소 5-10개 이상

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

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

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

방법:

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

주의사항:

• 시간 순서(A 다음에 B)와 인과관계(A 때문에 B)를 혼동하지 말 것
• "항상 그런가?"를 스스로에게 물어보기
• 반론이 있으면 인과관계를 재검토

예시:

• "배포가 느리다" → "고객 피드백 반영이 늦다" (OK, 명확한 인과)
• "팀원이 피곤하다" → "버그가 많다" (애매함, 다른 중간 효과 필요할 수도)

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

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

신호:

• "정말 A면 B야?"라고 의심될 때
• 화살표가 너무 길 때
• 팀원이 "그 사이에 뭔가 있지 않아?"라고 할 때

예시:

• "코드가 복잡하다" → "신규 기능 추가 어렵다"
• 중간에 추가: "코드가 복잡하다" → "변경 영향 범위 예측 불가" → "신규 기능 추가 어렵다"

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

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

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

방법:

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

검증 질문:

• "이것을 해결하면 여러 UDE가 사라지는가?"
• "우리가 통제할 수 있는가?"
• "구체적으로 무엇을 바꾸면 되는지 알 수 있는가?"

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

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

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

검증 체크리스트:

• 각 화살표: "정말 A면 B인가?"
• AND 조건: "정말 두 조건이 동시에 필요한가?"
• 빠진 중간 효과는 없나?
• 다른 설명도 가능한가?

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

팀 리뷰:

• CRT를 다른 팀원에게 설명해보기
• "이해 안 돼"라는 반응이 나오면 그 부분 수정
• 다양한 관점을 듣기 (개발자, PM, 디자이너 모두)

흔한 실수와 함정

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

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

잘못된 예:

• 근본 원인: "팀원들의 동기가 낮다"
• 문제: 이것도 결과일 가능성이 높음. 더 깊이 파야 함.

개선:

• "왜 동기가 낮은가?" → "성과가 안 보여서" → "왜?" → "배포가 느려서"...

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

잘못된 예:

• 근본 원인: "경쟁사가 공격적으로 마케팅함"
• 문제: 우리가 바꿀 수 없음

개선:

• "경쟁사 마케팅에 왜 우리가 대응 못 하는가?" → 이건 우리가 통제 가능

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

잘못된 예:

• 근본 원인 7개 발견
• 문제: 집중도 분산, 실행력 저하

개선:

• 진짜 레버리지 높은 1-2개에 집중
• 나머지는 "2차 원인"으로 분류

4. 완벽주의

잘못된 예:

• "이 CRT가 틀릴까봐 못 그리겠어요"
• 문제: 첫 CRT는 항상 불완전함. 시작이 중요.

개선:

• Version 1.0으로 시작
• 일주일 후 다시 보고 수정
• 실행하면서 배우기

5. 혼자 그리기

잘못된 예:

• CTO 혼자 방에 틀어박혀 CRT 완성
• 문제: 다른 관점 놓침, 팀 동의 부족

개선:

• 워크샵 형태로 팀과 함께
• 다양한 역할의 사람들 참여

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

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

5 Whys vs CRT

• 5 Whys: 선형적, 한 문제만 추적
• CRT: 그물망 구조, 여러 문제의 상호작용 파악

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

• 5 Whys: 배포 느림 → 테스트 느림 → 테스트 자동화 없음 → 시간 없음 → 우선순위 낮음
• CRT: 배포 느림 + 버그 많음 + 팀 사기 저하... 이 모두가 "코드 복잡도"에 연결됨을 발견

피쉬본 다이어그램 vs CRT

• 피쉬본: 원인을 범주로 분류 (사람, 프로세스, 도구...)
• CRT: 원인들 사이의 인과관계 추적

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

브레인스토밍 vs CRT

• 브레인스토밍: 가능한 원인 모두 나열
• CRT: 원인들의 관계와 우선순위 파악

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

실무에서의 시간 투자

초기 CRT 작성: 2-4시간

• 팀 워크샵 형태 추천
• 준비 시간 포함

반복 개선: 매주 30분

• 실행하며 새로 발견한 인과관계 추가
• 잘못된 연결 수정

ROI:

• 잘못된 해결책에 쓸 시간 절약: 수주-수개월
• 팀 정렬로 얻는 효율: 지속적

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

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

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

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

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

결과:

• 알바들이 정호 없이도 손님 응대 (3주 후)
• 정호가 손님과 대화할 시간 회복
• 단골 복귀
• 새 게임 큐레이션에 집중 가능

스타트업 X사 (1년 후)

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

해결책:

1. 기술 부채 타임박스: 매 스프린트 20% 시간 할당

2. 핵심 모듈 리팩토링 로드맵: 6개월 계획

3. 아키텍처 의사결정 기록(ADR): 왜 이렇게 설계했는지 문서화

4. 코드 리뷰 가이드라인: 복잡도 임계값 설정

중간 과정 (3개월차):

• 초기 저항: "이거 할 시간에 기능 하나 더 만들지"
• PM과 갈등: "고객은 기다려주지 않아요"
• 전환점: 한 팀원이 "이제 배포가 무섭지 않아요"라고 함

결과 (12개월차):

• 배포 속도 2배 증가
• 버그 발생률 40% 감소
• 신규 개발자 온보딩 시간 절반으로
• 팀 만족도 크게 상승

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

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

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

• "왜 이렇게 배포가 느린 거야?"
• "또 버그야?"
• "이 기능 언제 나와요?"
• "문서가 어디 있죠?"

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

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

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

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

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

다음 단계: CRT 너머

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

• Future Reality Tree: 바꾼 후 어떤 모습인가?

• Negative Branch: 새로운 문제가 생기지 않을까?

• Transition Tree: 어떻게 실행할 것인가?

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

실습 과제:

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

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

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

관련 페이지

TOC 핵심 개념

• TheoryOfConstraints - 제약이론 전체 개요

• TheTheoryOfConstraintsAndSystemsDynamics - TOC와 시스템 다이내믹스 관계

TOC 사고 프로세스 도구

현재 현실 나무(CRT)는 TOC의 5가지 사고 프로세스 도구 중 하나입니다:

• Current Reality Tree (CRT) - 무엇을 바꿀 것인가? (이 페이지)

• Evaporating Cloud - 대립을 어떻게 해소할 것인가?

• Future Reality Tree (FRT) - 무엇으로 바꿀 것인가?

• Negative Branch - 새로운 문제가 생기지 않을까?

• Prerequisite Tree & Transition Tree - 어떻게 변화를 일으킬 것인가?

TOCfE (TOC for Education) 강의 시리즈

정남기 박사님의 TOCfE Seoul 7기 강의:

• TheoryOfConstraints/TOCfE Seoul 1강 - 사고능력과 문제 해결

• TheoryOfConstraints/TOCfE Seoul 2강 - 나의 문제 발굴하기

• TheoryOfConstraints/TOCfE Seoul 3강 - 가지(Branch) 도구

• TheoryOfConstraints/TOCfE Seoul 4강 - 목표 설정

• TheoryOfConstraints/TOCfE Seoul 5강 - 야심찬 목표

• TheoryOfConstraints/TOCfE Seoul 6강 - 논리 비약 제거

• TheoryOfConstraints/TOCfE Seoul 7강 - 긍정적/부정적 가지

• TheoryOfConstraints/TOCfE Seoul 8강 - 가정에 도전하기

• TheoryOfConstraints/TOCfE Seoul 9강 - 증발구름(Evaporating Cloud)

• TheoryOfConstraints/TOCfE Seoul 10강 - 가정 찾기

• TheoryOfConstraints/TOCfE Seoul 11강 - 구름 활용 프로세스

• TheoryOfConstraints/TOCfE Seoul 12강 - 문제 해결 리더십

추천 도서

• 책/ItsNotLuck - Eli Goldratt의 TOC 사고 프로세스를 소설로 배우기

CategoryThinking CategoryProblemSolving CategoryTOC