우리는 왜 항상 같은 설명에 도착하는가
문제가 생기면
대부분 같은 말로 정리된다.
“결과는 나쁘지 않았다”
“일단 돌아가고 있다”
“다시 손보면 된다”
이 말들은 모두 사실이다.
그리고 동시에 아무것도 설명하지 않는다.
결과는 관리하기 쉽다.
숫자로 남고
비교할 수 있고
보고서에 넣기 좋다
그래서 구조는 점점
결과를 기준으로 설계된다.
문제는 이때부터다.
결과 중심 구조에서는 질문이 바뀐다.
왜 이렇게 판단했는가 ❌
왜 이 방식이었는가 ❌
대신 이런 질문만 남는다.
결과가 괜찮은가
문제는 없는가
이 질문들은 실행을 점검하지만,
사고를 복원하지는 못한다.
결과만 남는 구조에서는 문제가 해결된 것처럼 보인다.
하지만 다음 상황이 오면
똑같은 판단을 다시 해야 한다.
왜냐하면
그때의 기준이 남아 있지 않기 때문이다.
그래서 우리는 자주 이렇게 말한다.
“그때도 비슷한 문제가 있었던 것 같은데…”
결과는 산출물로 남는다.
하지만 선택은 기록되지 않는다.
왜 이 안을 골랐는지
왜 다른 안을 버렸는지
무엇을 더 중요하게 봤는지
이 선택들이 남지 않으면,
결과는 맥락 없는 데이터가 된다.
결과만 남는 구조의 가장 큰 함정은
성공 이후에 드러난다.
잘 돌아가고
문제 없고
굳이 건드릴 이유가 없을 때
그 구조는 고정된다.
그리고 기준 없는 결과만
계속 쌓이기 시작한다.
여기서 관점이 바뀐다.
보존해야 할 것은
결과가 아니라 기준이다.
기준이 남아 있어야
결과를 다시 해석할 수 있고,
상황이 바뀌어도
판단을 이어갈 수 있다.
그래서 다음 질문이 생긴다.
그 기준은
어디에, 어떻게 남겨야 할까?
다음 글에서는
결과보다 먼저 설계해야 했던 것,
즉,
사고를 고정하는 최소 조건을 다룬다.