4장. 지식은 네 영역으로 자란다

판단력은 네 가지 지식 축에서 만들어진다

앞선 글에서 기획자의 PKM이 관리해야 할 대상은 네 가지라고 말했다.
Evidence, Decision, Knowledge, Result다.

Evidence는 판단의 근거, Decision은 선택과 이유,
Knowledge는 다시 꺼내 쓸 수 있는 지식, Result는 실행 뒤에 남는 결과다.

그렇다면 다음 질문이 생긴다.

이 네 가지는 어디에서 자라는가.

나는 기획자의 지식이 네 영역에서 자란다고 본다.
맥락, 도메인, 기술이해, 관계다.

이 네 영역은 저장 폴더의 분류가 아니다.

기획자가 판단을 만들 때 계속 참조하게 되는 지식의 성장 축에 가깝다.

같은 Evidence라도 어느 영역에서 읽느냐에 따라 의미가 달라진다.
같은 Decision이라도 이 네 영역이 비어 있으면 설명이 약해진다.

그래서 PKM은 단순히 자료를 저장하는 일이 아니다.
이 네 영역의 지식을 함께 키우는 일에 더 가깝다.

맥락: 지금 왜 이 문제가 중요한가를 설명하는 지식

맥락은 과거부터 지금까지 이어지는 판단의 흐름이다.
왜 이 이슈가 지금 다시 올라왔는지, 어떤 논의가 이미 있었는지, 무엇이 바뀌었는지, 이번 결정이 어떤 연속선 위에 있는지를 설명해 준다.

맥락 지식이 약하면 기획은 늘 현재 시점에 갇히기 쉽다.

지금 눈앞에 보이는 요구사항만 보고 판단하고, 이전 논의를 잊고, 같은 질문을 반복하게 된다.

맥락 지식이 쌓이면 기획자는 이렇게 말할 수 있다.

이 이슈는 처음 나온 것이 아니라 지난 분기에도 검토했다.

그때는 기술 제약 때문에 보류했고, 지금은 조건이 달라졌다.

비슷한 논의가 이미 있었고, 그때의 결정 기준은 이랬다.

이때 중요한 것은 “무슨 일이 있었는가”를 아는 데 그치지 않는다는 점이다.
맥락은 “왜 이 문제가 지금 다시 중요해졌는가”를 설명하게 해 준다.

즉 맥락은 판단을 시간축 위에 올려놓는 지식이다.
기획자에게 맥락 지식이 있다는 것은 과거를 기억하는 사람이 된다는 뜻이 아니라,

현재의 판단이 왜 필요한지 설명할 수 있다는 뜻이다.

도메인: 무엇을 위해 판단하는가를 설명하는 지식

도메인은 사용자가 누구인지, 시장이 어떻게 움직이는지, 비즈니스 모델이 무엇인지, 이 서비스가 어떤 문제를 풀고 있는지를 이해하게 해주는 지식이다.

도메인 지식이 없으면 기획은 표면에 머물기 쉽다.
사용자가 왜 이런 행동을 하는지, 어떤 용어가 현업에서 어떤 의미를 가지는지, 무엇이 진짜 중요한 문제인지 판단하기 어렵다.

도메인 지식이 쌓이면 같은 VOC를 읽는 방식부터 달라진다.
같은 불만이라도 단순한 불편 제기로 끝나지 않는다.
어떤 고객군에서 나왔는지, 시장 구조 안에서 어떤 의미를 가지는지, 이 서비스의 핵심 문제와 어떻게 연결되는지를 함께 보게 된다.

같은 경쟁사 기능도 마찬가지다.
겉으로 보이는 기능 비교에서 멈추지 않고, 비즈니스 전략의 일부로 읽히기 시작한다.

그래서 도메인 지식은 많이 안다는 문제가 아니다.
기획자가 근거를 해석할 때 무엇을 더 중요하게 봐야 하는지 정해주는 배경 지식의 층에 가깝다.

기술이해: 무엇이 가능하고 무엇이 비싼가를 설명하는 지식

기획자의 기술이해는 개발자가 되기 위한 지식이 아니다.
구현 가능성과 제약을 현실적으로 판단하기 위한 지식이다.

실무에서는 자주 이런 순간이 나온다.
보기에는 작은 수정처럼 보이는데 개발팀에서는 예상보다 훨씬 오래 걸린다고 말한다.
왜 3일이면 될 것 같은 일이 3주가 되는가.
이 질문을 이해하려면 기술이해가 필요하다.

어떤 요구사항이 왜 오래 걸리는지,
어떤 개선안은 보기보다 위험한지,
어떤 선택은 장기적으로 기술부채를 키우는지,
어떤 API나 데이터 구조가 특정 경험을 어렵게 만드는지

이해하려면 기술이해가 있어야 한다.

기술이해가 부족하면 기획은 대개 두 방향 중 하나로 흐른다.
과도하게 낙관적이 되거나, 설명을 충분히 이해하지 못한 채 수동적으로 받아들이게 된다.

반대로 기술이해가 있으면 질문이 달라진다.

이 제약은 구조적인가, 일시적인가?

더 작은 범위로 풀 수 있는가?

지금의 선택이 다음 스프린트나 다음 분기 비용에 어떤 영향을 주는가?

즉 기술이해는 개발의 세부를 외우는 일이 아니다.
판단의 현실성을 높이는 지식이다.

관계: 좋은 안 인데도 실행이 느려지는 이유를 설명하는 지식

관계는 이해관계자, 팀의 일하는 방식, 조직의 합의 구조, 커뮤니케이션 패턴에 대한 지식이다.

실무에서는 좋은 안이 늘 빠르게 실행되지는 않는다.
논리는 충분한데도 진행이 더디고, 설계는 괜찮은데도 합의가 늦어지는 일이 자주 생긴다.

이유는 대개 판단 자체보다 판단이 움직이는 방식에 있다.

누가 이 결정을 지지하는지, 누가 우려를 갖는지, 어떤 순서로 설명해야 하는지, 어디에서 합의가 멈출 수 있는지를 모르면 설계는 좋아도 실행은 느려진다.

관계 지식이 있으면 기획자는 판단만 만드는 데서 멈추지 않는다.
판단을 어떻게 전달해야 실제로 움직일지도 함께 설계할 수 있다.

누구와 먼저 합의해야 하는가

누가 어떤 표현에 민감한가

어떤 형식의 문서와 어떤 근거를 제시해야 신뢰를 얻는가

즉 관계 지식은 사람을 외우는 것이 아니다.
판단이 조직 안에서 실제로 움직이게 만드는 실행 지식이다.

네 영역은 따로 떨어져 있지 않다

이 네 영역은 각각 따로 존재하지 않는다.
실제 기획에서는 계속 겹친다.

사용자의 요구를 해석할 때도 도메인 지식이 필요하고,
왜 지금 이 요구가 중요한지 보려면 맥락 지식이 필요하다.
어디까지 구현 가능한지 판단하려면 기술이해가 필요하고,
누구를 어떻게 설득할지 보려면 관계 지식이 필요하다.

그래서 기획자의 판단력은 특정 한 영역만 강해서는 충분하지 않다.
네 영역을 연결해 볼 수 있을 때 비로소 단단해진다.

이때 PKM의 역할이 중요해진다.
메모는 흩어져 들어오지만, PKM은 그 메모가 어느 영역의 지식을 키우는지 연결해 준다.

그 연결이 반복되면 메모가 경험이 되고,
경험이 패턴이 되고,
패턴이 쌓이면 판단력이 된다.

이번 글의 결론

여기서 중요한 것은 저장이 아니라 성장 축이다

기획자의 지식은 맥락, 도메인, 기술이해, 관계의 네 영역에서 자란다.

이 네 영역은 저장 분류보다 더 중요한 판단의 성장 축이다.

Evidence, Decision, Knowledge, Result를 잘 관리한다는 것은 결국 이 네 영역의 지식을 함께 키운다는 뜻이기도 하다.
네 영역이 연결될수록 근거 해석은 더 정확해지고, 결정 설명은 더 설득력을 얻고,

실행 가능성은 더 높아진다.

다음 글에서는 이 네 가지 관리 대상 가운데 먼저 근거와 결정을 어떻게 다룰 것인지 살펴보려 한다.
Decision OS는 무엇을 저장하는 곳이 아니라, 근거와 결정을 연결해 다루는 방법이다.