#acl +All:read = 성공이 만든 덫: 현재 현실 나무로 찾는 진짜 문제 = "천 개의 증상을 고치는 것보다, 하나의 원인을 제거하는 것이 낫다." ---- == 정호의 미니 게임 카페 == 정호는 동네에서 작은 보드게임 카페를 운영한다. 처음에는 단순했다. 테이블 다섯 개, 인기 게임 열 개, 혼자서 주문 받고 커피 내리고 게임 설명하고. 손님들이 "여기 분위기 좋네요"라며 친구들을 데려왔다. 반년 만에 입소문이 났다. 주말엔 대기가 생겼다. 정호는 기뻤다. "확장할 때가 됐어!" 그는 옆 가게를 빌려 테이블을 열 개로 늘렸다. 손님들이 "이 게임도 있었으면 좋겠어요"라고 할 때마다 게임을 샀다. 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