|
Size: 10558
Comment:
|
← Revision 4 as of 2026-01-28 08:43:02 ⇥
Size: 20844
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
| = 현상문제 나무 예제로 배우기 (Current Reality Tree by Example) = "문제의 뿌리를 찾는 가장 강력한 방법은 증상들 사이의 인과관계를 그려보는 것이다." ---- == 수민이의 번아웃 == 수민이는 2년차 개발자다. 요즘 월요일 아침마다 출근하기가 두렵다. 주말에도 일 생각을 하면 속이 답답하다. 무엇보다 답답한 건, 왜 이렇게 힘든지 명확하지 않다는 것이다. "나는 왜 이렇게 힘들까?" 수민이가 떠올린 문제들은 이렇다: * '''밤 10시까지 야근'''이 잦다 * '''업무가 자꾸 끊긴다''' - 회의와 긴급 요청 때문에 집중할 수 없다 * '''내 코드가 자주 롤백'''된다 - 버그가 발견되어 되돌려진다 * '''기획이 자주 바뀐다''' - 다 만들어놓으면 "이건 아닌 것 같아요"라는 말을 듣는다 * '''문서화할 시간이 없다''' - 급하게 만들고 넘어가니 나중에 또 물어본다 이 문제들은 각각 독립적일까, 아니면 연결되어 있을까? ---- == Current Reality Tree (CRT)란? == '''현상문제 나무(Current Reality Tree, CRT)'''는 Theory of Constraints의 핵심 도구로, '''지금 겪고 있는 여러 문제들(UDE: Undesirable Effects) 사이의 인과관계를 시각화'''하여 '''근본 원인(Root Cause)'''을 찾는 방법이다. === 왜 필요한가? === 우리가 겪는 문제들은 대부분 독립적이지 않다. 하나의 근본 원인이 여러 증상을 만들어낸다. 하지만 우리는 보이는 증상만 보고 각각을 해결하려다 지친다. CRT는 이렇게 질문한다: * "이 문제들은 왜 일어나는가?" * "이 문제들 사이에 어떤 관계가 있는가?" * "만약 하나의 근본 원인을 해결하면, 여러 문제가 동시에 해결될 수 있지 않을까?" ---- == CRT 구성 요소 == === 1. UDE (Undesirable Effect) - 바람직하지 않은 결과 === '''"지금 내가 겪고 있는, 바꾸고 싶은 현상"''' |
= 성공이 만든 덫: 현재 현실 나무로 찾는 진짜 문제 = "천 개의 증상을 고치는 것보다, 하나의 원인을 제거하는 것이 낫다." ---- == 정호의 미니 게임 카페 == 정호는 동네에서 작은 보드게임 카페를 운영한다. 처음에는 단순했다. 테이블 다섯 개, 인기 게임 열 개, 혼자서 주문 받고 커피 내리고 게임 설명하고. 손님들이 "여기 분위기 좋네요"라며 친구들을 데려왔다. 반년 만에 입소문이 났다. 주말엔 대기가 생겼다. 정호는 기뻤다. "확장할 때가 됐어!" 그는 옆 가게를 빌려 테이블을 열 개로 늘렸다. 손님들이 "이 게임도 있었으면 좋겠어요"라고 할 때마다 게임을 샀다. 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에 기여한다"가 아님 * 이 엄격함 덕분에 개입 포인트가 명확해진다 |
| Line 48: | Line 83: |
| * 밤 10시까지 야근한다 * 업무가 자꾸 끊긴다 * 코드가 자주 롤백된다 === 2. 인과관계 화살표 (If-Then) === '''"만약 A가 일어나면, 그래서 B가 일어난다"''' |
* "If 알바들이 게임 설명을 못 한다 AND 정호만 게임을 안다, then 알바들이 독립적으로 일하지 못한다" AND 조건(여러 원인이 동시에 필요)을 표시할 때는 화살표들을 동그라미나 타원으로 묶는다. === 3. 중간 효과 (Intermediate Effects) === UDE와 근본 원인 사이를 이어주는 노드다. 이게 없으면 논리적 도약이 커서 "정말 그런가?" 의문이 생긴다. 예를 들어: * (잘못된 도약) "게임이 많다" → "손님이 불만족" * (중간 효과 추가) "게임이 많다" → "알바가 설명 못 함" → "정호만 응대" → "손님이 불만족" 중간 효과를 채워가는 과정이 바로 '''"왜?"를 반복하며 인과 사슬을 완성하는 것'''이다. === 4. 근본 원인 (Root Cause / Core Problem) === 대부분의 UDE로 연결되는 가장 밑바닥의 원인이다. CRT의 최종 목표는 이걸 찾는 것이다. '''좋은 근본 원인의 조건:''' * 많은 UDE와 연결됨 * 통제 가능함 (우리가 바꿀 수 있음) * 구체적임 (추상적 개념이 아님) ---- == 정호의 게임 카페 CRT == 정호가 화이트보드에 그린 CRT는 이렇게 생겼다: |
| Line 57: | Line 113: |
| A → B | [손님들이 게임 추천에 불만] ↑ [정호가 손님 응대할 시간 없음] ↑ [항상 뭔가를 고치거나 찾음] ↑ [알바들이 독립적으로 일하지 못함] ↗ ↖ [알바들이 게임 설명 못 함] [게임 관리가 체계적이지 않음] ↑ ↑ [게임이 200개나 됨] [분류/수납 시스템 없음] ↑ ↑ [무분별한 확장] [시스템화 없이 성장] ↑___________________________↑ | [핵심 원인: 초기 성공에 도취되어 규모만 키우고 운영 구조는 안 만듦] |
| Line 60: | Line 132: |
| "만약 A라면, 그래서(Therefore) B다" === 3. 근본 원인 (Root Cause) === '''"화살표를 따라 올라갔을 때, 가장 아래에 있는 원인"''' 여러 증상을 만들어내는 뿌리가 되는 문제. ---- == 예제: 수민이의 CRT 만들기 == === Step 1: UDE 나열하기 === 먼저 바꾸고 싶은 현상들을 있는 그대로 적는다. 판단하지 말고, 지금 겪고 있는 것들을 나열한다. '''수민이의 UDE 목록:''' 1. 밤 10시까지 야근한다 2. 업무가 자주 끊긴다 (회의, 긴급 요청) 3. 내 코드가 자주 롤백된다 4. 기획이 자주 바뀐다 5. 문서화할 시간이 없다 6. 번아웃 느낌이 든다 === Step 2: 인과관계 찾기 - "왜?"를 반복하라 === 각 UDE에 대해 "왜 이런 일이 일어나는가?"를 질문한다. '''UDE: 밤 10시까지 야근한다''' * 왜? → 작업이 예상보다 오래 걸린다 * 왜? → 업무가 자주 끊긴다 (UDE #2) * 왜? → 긴급 요청과 회의가 많다 '''UDE: 내 코드가 자주 롤백된다''' * 왜? → 버그가 발견된다 * 왜? → 충분히 테스트할 시간이 없다 * 왜? → 빨리 배포하라는 압박이 있다 '''UDE: 기획이 자주 바뀐다''' * 왜? → 초기에 충분히 검증되지 않았다 * 왜? → 빨리 만들어서 보여달라는 요구가 있다 === Step 3: 연결하기 - 나무 그리기 === 이제 인과관계를 화살표로 연결한다. 아래에서 위로 읽으면 "만약 A라면, 그래서 B다"가 된다. |
정호는 이 그림을 보는 순간 깨달았다. 문제는 알바가 부족하거나 게임이 많은 게 아니었다. '''정호의 머릿속에만 있는 정보(어떤 게임이 어디 있고, 어떤 손님에게 어떤 걸 추천할지)를 시스템으로 만들지 않았기 때문'''이었다. ---- == IT 비즈니스로 옮겨보자 == 이제 같은 패턴을 소프트웨어 회사에 적용해보자. === 스타트업의 전형적 시나리오 === '''시작''': POC 제품 출시 → 시장 반응 좋음 → 빠른 성장 '''확장''': * 이 기능 필요, 저 기능 필요 * 컨셉 충돌로 spin-off 제품 생김 * 관리 포인트 증가 '''결과''': * 제품 개선 속도 느려짐 * 버그 증가 * 팀 사기 저하 * 성장 둔화 === 스타트업 CRT 예시 === |
| Line 107: | Line 158: |
| [번아웃 느낌] ↑ | +----------+----------+ | | [야근이 잦다] [성취감이 없다] ↑ ↑ | | +---------+---------+ [코드가 자주 롤백] | | ↑ [업무가 끊긴다] [재작업이 많다] | ↑ ↑ [테스트 시간 부족] | | ↑ | [기획이 바뀐다] | | ↑ | | | | +-------------------+-----------+ | [빨리 결과를 내야 한다는 압박] |
[제품 개선 속도가 느려짐] ← [신규 기능 추가가 어려움] ↑ [코드베이스가 복잡함] ↑ [초기 POC 코드 위에 계속 덧붙임] + [리팩토링 시간 없음] ↑ ↑ [빠른 시장 출시 압박] [항상 새 기능 요청] ↑ ↑ [PMF 발견] + [기술 부채 관리 프로세스 부재] ↑________________________________↑ | [핵심 원인: 제품-시장 적합성 발견 후 기술적 토대 개선 없이 기능만 추가] |
| Line 128: | Line 173: |
| === Step 4: 근본 원인 찾기 === 나무의 가장 아래를 보라. 여러 가지들로 화살표가 나가지만, 들어오는 화살표가 없거나 적은 것이 '''근본 원인'''이다. '''수민이의 근본 원인:''' {{{ "빨리 결과를 내야 한다는 압박" }}} 이 하나의 원인이: * 충분한 검증 없이 기획을 시작하게 만들고 (→ 기획 변경) * 테스트 시간을 줄이게 만들고 (→ 버그 → 롤백) * 긴급 요청을 만들어내고 (→ 업무 단절) * 결과적으로 야근과 번아웃으로 이어진다 ---- == CRT의 힘: 증상이 아닌 원인을 다루라 == === Before CRT: 증상 치료 === 수민이가 CRT 없이 문제를 해결하려 했다면: * 야근을 줄이자 → 일찍 퇴근하면 눈치가 보인다 * 업무 끊김을 줄이자 → 회의를 거부할 수 없다 * 버그를 줄이자 → 테스트할 시간이 없는데? * 기획 변경을 막자 → 기획자를 설득할 근거가 없다 각 증상을 개별적으로 해결하려 하면 '''힘들고, 효과도 적다'''. === After CRT: 근본 원인 해결 === 근본 원인을 알면 대화가 달라진다: '''수민이 → 팀장님:''' "팀장님, 요즘 야근이 잦고 번아웃이 느껴집니다. 제가 생각해봤는데, 근본적인 문제는 '빨리 결과를 내야 한다는 압박' 같습니다. > 이 압박 때문에: - 기획 검증이 부족해서 나중에 변경이 생기고 - 테스트를 제대로 못 해서 롤백이 생기고 - 긴급 요청이 생겨서 집중이 안 됩니다 > 만약 초기에 2-3일만 더 기획 검증 시간을 주신다면, 전체 일정은 오히려 단축될 것 같습니다." '''근본 원인 하나를 해결하면, 여러 증상이 동시에 개선된다.''' ---- == CRT 작성 실전 가이드 == === 1. UDE는 구체적으로 === ❌ "스트레스가 많다" ✅ "주 3회 이상 밤 10시 넘게 야근한다" ❌ "팀 분위기가 안 좋다" ✅ "회의에서 서로 비난하는 말이 나온다" === 2. 인과관계는 명확하게 === 화살표를 그릴 때는 항상 읽어보라: "만약 [하위 박스]라면, 그래서 [상위 박스]다" 만약 이 문장이 자연스럽지 않다면, 중간 단계가 빠졌거나 관계가 잘못된 것이다. === 3. 가정(Assumption)을 적어라 === 때로는 명확하지 않은 연결이 있다. 그럴 때는 옆에 가정을 적는다. {{{ [기획이 바뀐다] ↑ | (가정: 초기 검증이 부족하면 나중에 문제가 발견된다) | [빨리 결과를 내야 한다는 압박] }}} === 4. 여러 원인이 합쳐질 때 (AND) === 때로는 A와 B가 동시에 있어야 C가 일어난다: {{{ [테스트 시간 부족] ─┐ ├─→ [버그 발생] [복잡한 코드베이스] ─┘ }}} === 5. 순환 구조 조심 === 가끔 A → B → C → A처럼 순환이 생긴다. 이것은 '''악순환(Vicious Cycle)'''이다. 이런 경우 순환을 끊을 지점을 찾아야 한다. {{{ [야근] → [피로] → [버그 증가] → [재작업] → [야근] ↑__________________________| }}} ---- == 실전 연습: 당신의 문제로 CRT 그리기 == === Exercise 1: 개인 문제 === '''1단계:''' 지금 당신이 겪고 있는 바람직하지 않은 현상 5-7개를 적으세요. '''2단계:''' 각 현상에 대해 "왜?"를 3번 이상 물어보세요. '''3단계:''' 인과관계를 화살표로 연결하세요. '''4단계:''' 가장 아래에 있는 근본 원인을 찾으세요. === Exercise 2: 팀 문제 === 팀에서 겪는 반복적인 문제들을 나열하고, CRT를 그려보세요: * 배포가 자주 실패한다 * 코드 리뷰가 형식적이다 * 기술 부채가 쌓인다 * 일정이 항상 밀린다 * 팀원들이 자주 퇴사한다 이 문제들의 근본 원인은 무엇일까요? ---- == CRT 이후: Future Reality Tree == CRT로 근본 원인을 찾았다면, 다음 단계는 '''미래현실 나무(Future Reality Tree, FRT)'''입니다. FRT는 질문합니다: '''"만약 이 근본 원인을 해결하면, 어떤 긍정적 결과들이 나타날까?"''' CRT와 FRT를 함께 사용하면: 1. '''CRT''': 지금의 문제들이 왜 일어나는지 이해 2. '''FRT''': 해결책이 어떤 변화를 가져올지 예측 이것이 Theory of Constraints의 핵심 사고 프로세스입니다. ---- == 핵심 통찰 == '''"증상을 치료하지 말고, 원인을 다루라."''' 우리는 보이는 문제들을 하나씩 해결하려다 지친다. 하지만 문제들은 독립적이지 않다. 하나의 뿌리에서 여러 증상이 나온다. CRT는 이렇게 말한다: * 문제들 사이의 관계를 보라 * 근본 원인을 찾아라 * 하나를 바꿔서 여러 개를 해결하라 '''"레버리지를 찾는 것이 TOC의 본질이다."''' ---- == 참고 자료 == === TOC 핵심 도구들 === '''분석 도구 (현재):''' * '''Current Reality Tree (CRT)''' - 현재 문제의 근본 원인 찾기 * '''Evaporating Cloud''' - 대립하는 요구사항 해소하기 '''설계 도구 (미래):''' * '''Future Reality Tree (FRT)''' - 해결책의 효과 예측하기 * '''Prerequisite Tree (PRT)''' - 장애물 제거 계획 * '''Transition Tree (TRT)''' - 실행 단계별 계획 === 더 배우기 === * [[TheoryOfConstraints]] - TOC 전체 개요 * [[EvaporatingCloud]] - 대립 해소 기법 * [[책/ItsNotLuck]] - TOC 사고 프로세스를 소설로 배우기 ---- '''"문제를 해결하는 가장 좋은 방법은, 문제를 이해하는 것이다."''' ---- CategoryThinking CategoryProblemSolving |
근본 원인을 다르게 표현하면: '''"정보(코드 구조, 설계 의도)를 개발자 머리에서 코드/문서로 이동시키지 않았다."''' 정호의 게임 카페와 동일한 패턴이다. ---- == 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 |
성공이 만든 덫: 현재 현실 나무로 찾는 진짜 문제
- "천 개의 증상을 고치는 것보다, 하나의 원인을 제거하는 것이 낫다."
정호의 미니 게임 카페
정호는 동네에서 작은 보드게임 카페를 운영한다. 처음에는 단순했다. 테이블 다섯 개, 인기 게임 열 개, 혼자서 주문 받고 커피 내리고 게임 설명하고. 손님들이 "여기 분위기 좋네요"라며 친구들을 데려왔다.
반년 만에 입소문이 났다. 주말엔 대기가 생겼다. 정호는 기뻤다. "확장할 때가 됐어!"
그는 옆 가게를 빌려 테이블을 열 개로 늘렸다. 손님들이 "이 게임도 있었으면 좋겠어요"라고 할 때마다 게임을 샀다. 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분)
포스트잇들을 벽에 붙이고 연결하기 시작한다.
방법:
- 두 UDE를 골라 "A가 있으면 B가 발생한다"고 말할 수 있는지 확인
- 논리가 명확하면 화살표로 연결
- "왜?"를 계속 물으며 깊이 파고들기
주의사항:
- 시간 순서(A 다음에 B)와 인과관계(A 때문에 B)를 혼동하지 말 것
- "항상 그런가?"를 스스로에게 물어보기
- 반론이 있으면 인과관계를 재검토
예시:
- "배포가 느리다" → "고객 피드백 반영이 늦다" (OK, 명확한 인과)
- "팀원이 피곤하다" → "버그가 많다" (애매함, 다른 중간 효과 필요할 수도)
단계 3: 중간 효과 채우기 (30-40분)
논리적 도약이 큰 곳을 찾아 빈칸을 채운다.
신호:
- "정말 A면 B야?"라고 의심될 때
- 화살표가 너무 길 때
- 팀원이 "그 사이에 뭔가 있지 않아?"라고 할 때
예시:
- "코드가 복잡하다" → "신규 기능 추가 어렵다"
- 중간에 추가: "코드가 복잡하다" → "변경 영향 범위 예측 불가" → "신규 기능 추가 어렵다"
이 단계에서 진짜 이해가 깊어진다. 우리가 "왜 이런 일이 벌어지는지" 정확히 알게 된다.
단계 4: 근본 원인 식별 (20-30분)
이제 나무의 뿌리를 찾는다.
방법:
- 가장 아래에 있는 노드들(더 이상 화살표가 들어오지 않음) 확인
- 각 노드에서 출발하는 경로가 몇 개의 UDE로 연결되는지 세기
- 가장 많은 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 코드로 착각하고 계속 덧붙임"
해결책:
기술 부채 타임박스: 매 스프린트 20% 시간 할당
핵심 모듈 리팩토링 로드맵: 6개월 계획
아키텍처 의사결정 기록(ADR): 왜 이렇게 설계했는지 문서화
코드 리뷰 가이드라인: 복잡도 임계값 설정
중간 과정 (3개월차):
- 초기 저항: "이거 할 시간에 기능 하나 더 만들지"
- PM과 갈등: "고객은 기다려주지 않아요"
- 전환점: 한 팀원이 "이제 배포가 무섭지 않아요"라고 함
결과 (12개월차):
- 배포 속도 2배 증가
- 버그 발생률 40% 감소
- 신규 개발자 온보딩 시간 절반으로
- 팀 만족도 크게 상승
완벽한 성공담이 아니다. 여전히 기술 부채는 있다. 하지만 이제는 통제할 수 있다. 어디가 아픈지, 왜 아픈지, 무엇부터 고쳐야 하는지 안다.
CRT를 시작하며: 당신의 문제는 무엇인가?
지금 당신의 조직에서 반복적으로 들리는 불만은 무엇인가?
- "왜 이렇게 배포가 느린 거야?"
- "또 버그야?"
- "이 기능 언제 나와요?"
- "문서가 어디 있죠?"
이 불만들을 화이트보드에 적어보라. 그리고 물어보라: "이것들이 서로 연결되어 있다면?"
CRT는 복잡함 속에서 명료함을 찾는 도구다. 완벽할 필요는 없다. 틀릴 수도 있다. 하지만 팀과 함께 첫 번째 버전을 그리고, 토론하고, 개선하는 과정 자체가 가치다.
증상을 고치지 말고, 원인을 제거하라.
모든 문제를 동시에 해결하려 하지 마라. 하나의 핵심 원인을 찾아 제거하라. 그러면 얽혀있던 여러 문제가 한 번에 풀린다.
정호의 게임 카페도, 당신의 스타트업도, 그 시작은 한 장의 화이트보드에서 시작된다.
다음 단계: CRT 너머
CRT는 "What to Change(무엇을 바꿀 것인가)"만 답한다. TOC-TP는 여기서 멈추지 않는다:
Future Reality Tree: 바꾼 후 어떤 모습인가?
Negative Branch: 새로운 문제가 생기지 않을까?
Transition Tree: 어떻게 실행할 것인가?
하지만 그건 다음 이야기다. 일단 오늘은 당신의 첫 CRT를 그려보자.
실습 과제:
- 다음 주 팀 미팅에 2시간 할애
- 화이트보드와 포스트잇 준비
- 팀원들에게 이 글 공유 (선택)
- "우리 조직의 UDE 10개" 리스트 만들기
- 그 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 5강 - 야심찬 목표
TheoryOfConstraints/TOCfE Seoul 6강 - 논리 비약 제거
TheoryOfConstraints/TOCfE Seoul 7강 - 긍정적/부정적 가지
TheoryOfConstraints/TOCfE Seoul 8강 - 가정에 도전하기
TheoryOfConstraints/TOCfE Seoul 9강 - 증발구름(Evaporating Cloud)
TheoryOfConstraints/TOCfE Seoul 11강 - 구름 활용 프로세스
TheoryOfConstraints/TOCfE Seoul 12강 - 문제 해결 리더십
추천 도서
책/ItsNotLuck - Eli Goldratt의 TOC 사고 프로세스를 소설로 배우기
CategoryThinking CategoryProblemSolving CategoryTOC