7장.실행 결과는 끝이 아니라 다음 근거와 지식의 시작

기획의 결과를 다시 근거와 지식으로 돌려보내는 법

배포는 끝났다.

이슈는 정리됐고, 태스크도 닫혔다.
팀은 곧바로 다음 일정으로 넘어간다.

그런데 며칠이나 몇 주 뒤, 비슷한 질문이 다시 돌아온다.
왜 예상과 다른 반응이 나왔는지,무엇이 실제로 효과가 있었는지,
처음 세운 가정 중 무엇이 맞고 무엇이 틀렸는지는 남아 있지 않다.

기획에서 실행은 종종 마지막처럼 다뤄진다.
기능이 배포되고, 문서가 완료되고, 태스크가 닫히면 일이 끝난 것처럼 느껴진다.

하지만 PKM, 즉 개인지식관리의 관점에서는 다르다.

실행 결과는 끝이 아니라 다음 판단의 시작이다.

실제로 해본 뒤에 무엇이 작동했고 무엇이 실패했는지,
어떤 가정이 맞았고 어떤 가정이 틀렸는지가 다시 근거와 지식으로 돌아와야
PKM은 살아 있는 시스템이 된다.

그래서 Result는 단순한 완료 표시가 아니다.

실행 이후에 남는 관찰, 피드백, 학습을 다음 순환으로 돌려보내는 장치다.

왜 많은 시스템이 실행 결과에서 끊기는가

많은 팀이 계획과 결정까지는 기록한다.
무엇을 하기로 했는지, 왜 그렇게 했는지까지는 남긴다.

그런데 실행 이후에는 기록이 급격히 줄어든다.

이유는 단순하다.
이미 일이 끝났다고 느끼고, 다음 일정이 바로 들어오고,

결과를 정리하는 일은 부가 작업처럼 보이기 때문이다.

이 상태가 반복되면 계획은 계속 남는데 학습은 남지 않는다.
결정은 쌓이는데 검증 결과는 축적되지 않는다.

결국 다음 프로젝트에서도 비슷한 가정을 다시 하고,
비슷한 실수를 다시 겪게 된다.

PKM이 메모 저장소로 끝나는 순간도 바로 여기다.
실행 이후의 결과가 다시 시스템 안으로 돌아오지 않을 때다.

Result는 실행의 피드백을 남기는 영역이다

Result가 다루는 것은 단순한 완료 여부가 아니다.
실행해 본 뒤 확인된 변화와 차이다.

예를 들면 이런 것들이다.

배포 후 예상했던 사용자 반응과 실제 반응의 차이

특정 정책 변경이 운영에 미친 영향

PRD에서 가정한 플로우와 실제 개발 구현 사이의 차이

실행해보니 효과가 있었던 체크리스트나 방법

예상하지 못했던 예외 케이스와 후속 조치

즉 Result는 실행의 증거다.

판단이 현실과 만났을 때 실제로 어떤 일이 벌어졌는지를 보여주는 영역이다.

이 기록이 있어야 기획은 과거를 설명하는 데서 멈추지 않고,
미래의 판단을 개선할 수 있다.

Action과 Result는 다르다

여기서 중요한 것은 Action과 Result를 구분하는 일이다.

Action은 지금 해야 할 일이다.
담당자, 기한, 후속 요청처럼 실행 자체를 관리하는 항목이다.
말 그대로 할 일 체크에 가깝다.

반면 Result는 그 Action을 해본 뒤 남는 의미 있는 결과다.
다음 판단에 남는 발견이라고 보는 편이 더 정확하다.

예를 들어,

Action: 가격 비교표 초안 작성

Result: 실제 리뷰에서는 비교표보다 요약 카드가 더 빠르게 이해되었음

Action: 승인 플로우 순서도 정리

Result: 순서도 정리 과정에서 기존 예외 처리 누락이 발견됨

첫 번째는 일을 진행하기 위한 관리 항목이고,
두 번째는 일을 해본 뒤 새롭게 확인된 사실이다.

이 차이를 구분해야 실행 관리와 학습 관리가 섞이지 않는다.

좋은 Result는 다시 Evidence나 Knowledge로 올라간다

Result가 중요한 이유는 그 자체로 끝나지 않기 때문이다.
의미 있는 Result는 다시 두 방향으로 올라간다.

하나는 이번 실행에서 새로 확인된 사실이다.
이 경우 Result는 Evidence로 올라간다.

실행 이후 확인된 사용자 반응, 운영 수치, 장애 패턴, 협업 이슈는
다음 판단의 근거가 되기 때문이다.

다른 하나는 다음에도 다시 쓸 수 있는 기준이다.
이 경우 Result는 Knowledge 로 올라간다.

예를 들어 특정 산출물 형식이 반복해서 잘 작동한다든지,
어떤 체크 순서가 계속 실수를 줄여준다든지,
특정 의사결정 방식이 여러 번 효과적이었다면
그것은 더 이상 일회성 결과가 아니라 재사용 지식이 된다.

즉 Result는 종착지가 아니라 분기점이다.
실행 이후 생긴 것이 이번에 확인된 사실인지,
다음에도 쓸 기준인지 판단하는 지점이다.

이 승격이 일어나지 않으면 실행 경험은 개인 기억으로만 남고,
시간이 지나며 사라진다.

Result가 있어야 PKM이 학습 시스템이 된다

Evidence,Decision,Knowledge만 있고 Result가 없으면

PKM은 잘 정리된 계획 시스템이 될 수는 있다.

하지만 학습 시스템이 되기는 어렵다.

학습 시스템이 되려면 적어도 이런 질문에 답할 수 있어야 한다.

우리가 세운 가정은 맞았는가

이 결정은 실제로 어떤 결과를 만들었는가

다음에도 같은 방식으로 해도 되는가

이번 실행에서 얻은 교훈은 무엇인가

이 질문에 답하기 시작하면 PKM은 과거 기록의 저장소를 넘어
실험과 피드백의 시스템이 된다.

계획을 잘 세우는 것에서 끝나지 않고,
실행의 결과에서 다시 배우는 기획자가 바로 이 지점에서 차이를 만든다.

여기서 Result를 다루는 방식

여기서는 실행 결과의 모든 데이터를 다 펼쳐놓으려는 것이 아니다.
대신 몇 가지 원칙을 분명히 보려 한다.

어떤 실행 결과가 단순 완료로 끝나고, 어떤 결과가 승격 대상이 되는가

언제 Result를 Evidence로 올리고, 언제 Knowledge로 올리는가

어떤 최소 기록이 있어야 다음 판단에 다시 활용할 수 있는가

Daily와 Review 루틴에서 이 환류를 어떻게 운영하는가

즉 Result도 실제 로그 전체보다 운영 방법과 샘플 중심으로 보는 편이 더 중요하다.

마무리

실행 결과는 PKM의 끝이 아니다.
다음 근거와 다음 지식의 시작이다.

Action은 Daily에서 관리하고, 의미 있는 Result는 다시 Evidence나 Knowledge로 승격되어야 한다.

그래야 PKM은 기록 보관함이 아니라
판단과 학습이 순환하는 시스템이 된다.

다음 글에서는 그 순환의 입구를 본다.
기획자의 개인지식관리는 하루의 입력을 어떻게 받아들여야 하는가.