결과만 남고 '왜'가 사라지는 조직

ERP는 '무엇'만 기록하고 '왜'는 버린다

ERP, 문서함, 메신저에는 무엇을 했는지가 빼곡히 남습니다. 어떤 자재를 어떤 단가로 발주했고, 어떤 설계로 확정했는지는 추적됩니다. 그러나 '왜 그 단가를 받아들였는지', '어떤 대안을 검토했다가 버렸는지'는 어디에도 없습니다. 시스템은 결과를 저장하도록 설계됐지, 판단을 저장하도록 설계되지 않았기 때문입니다.

이렇게 맥락이 빠진 기록을 '저맥락(low-context) 기록'이라 부를 수 있습니다. 정보는 많은데 정작 판단에 필요한 배경은 빠져 있어, 나중에 보면 '왜 이렇게 했는지' 알 수 없는 상태죠.

기록되지 않은 결정은 잊히고 반복된다

소프트웨어 엔지니어링 분야에는 '의사결정 기록(Architecture Decision Record, ADR)'이라는 오래된 관행이 있습니다. 구글 클라우드의 가이드는 그 이유를 명확히 합니다. 내려졌지만 기록되지 않은 결정은 잊히고, 같은 논쟁을 반복하게 만들며, 원래 의도와 모순되는 변경을 무심코 하게 만든다는 것입니다.

현장도 똑같습니다. 3년 전 같은 하자를 겪고 내린 판단이 기록되지 않으면, 새 담당자는 그 교훈 없이 같은 함정에 다시 빠집니다. 조직은 학습하지 못하고 매번 처음으로 돌아갑니다. 더 나쁜 경우는 결과만 보고 과거의 의도와 정반대되는 변경을 하는 것입니다. 왜 그 공법을 채택했는지 모른 채 '비효율적'이라며 바꿨다가, 원래 그 공법이 막아주던 문제가 다시 터지는 식이죠.

의사결정 기록이 만드는 차이

ADR 같은 의사결정 기록의 가치는 분명합니다. 새 구성원을 빠르게 적응시키고, 과거의 논쟁을 다시 벌이지 않게 하며, 문제가 생겼을 때 '왜 이렇게 됐는지'를 추적할 근거가 됩니다. 핵심은 결정 자체가 아니라 그 결정을 둘러싼 선택지와 근거를 함께 남기는 것입니다.

• 무엇을 결정했는가 (결과)
• 어떤 상황에서 (맥락)
• 어떤 대안이 있었는가 (선택지)
• 왜 그것을 골랐는가 (근거)

결과 옆에 '왜'를 붙여두기

모든 일을 ADR처럼 길게 쓸 필요는 없습니다. 중요한 판단의 순간에만, 결과 옆에 '왜'를 짧게 붙여두면 됩니다. 그 한 줄이 6개월 뒤 같은 회의를 막고, 후임자의 재작업을 막습니다.

관건은 '쓰는 부담'입니다. 현장 담당자에게 결정마다 ADR 양식을 채우라고 하면 며칠 못 가 멈춥니다. 그래서 기록은 업무의 흐름 안에서 자연스럽게 남아야 합니다. 이미 오간 대화와 결정에서 다시 쓸 판단만 골라 구조화해 두면, 의사결정 기록은 별도의 일이 아니라 업무의 부산물이 됩니다. 그렇게 쌓인 '왜'는 나중에 검색해 다시 꺼내 쓸 수 있는 조직의 자산이 됩니다.