4. 기록되지 않은 사고의 문제

프로젝트가 중단될 때, 가장 먼저 사라지는 것

프로젝트가 멈출 때

가장 먼저 사라지는 것은 코드도, 문서도 아니다.

사고다.

파일은 남아 있고,

구조도 남아 있고,

기록도 남아 있다.

그런데 다시 시작하려고 하면

어디서부터 판단해야 할지 알 수 없다.

---

기록은 존재하지만, 사고의 중심이 비어 있는 상태. 형태는 남아 있으나, 다시 시작할 기준점이 사라진 구조.

기록은 있는데, 사고는 없다

우리는 종종 이렇게 말한다.

문서는 남아 있다

로그도 있다

히스토리도 있다

그런데도

왜 이 결정을 했는지는 알 수 없다.

기록은 남아 있지만,

그 기록을 해석할

사고의 기준이 없다.

사고는 결과가 아니라 판단의 연쇄다

사고를 결과로 착각하면

기록은 충분해 보인다.

하지만 사고는

어떤 선택지를 검토했고,

어떤 기준으로 하나를 버렸는지의 연쇄다.

이 연쇄가 기록되지 않으면,

결과만으로는 사고를 복원할 수 없다.

기록되지 않은 사고는 왜 사라지는가

사고는 눈에 보이지 않는다.

그래서 기록되지 않으면

존재하지 않았던 것처럼 취급된다.

회의에서 했던 말

머릿속으로 정리한 판단

“당연해서” 적지 않았던 기준

이것들은 실행으로 옮겨지는 순간

기록 밖으로 밀려난다.

다시 시작할 수 없는 이유

그래서 이런 상태가 된다.

무엇을 해야 하는지는 알겠는데

왜 그렇게 해야 하는지는 모른다

이때 프로젝트는

처음부터 다시 시작하는 것처럼 느껴진다.

실제로는 처음이 아니다.

다만, 사고가 사라졌을 뿐이다.

사고가 존재한다는 증거

이 지점에서

하나의 기준이 생긴다.

다시 설명할 수 없는 사고는
다시 사용할 수 없다.

그리고

다시 사용할 수 없는 사고는

존재하지 않는 것과 같다.

다음으로 이어지는 질문

그래서 다음 질문이 생긴다.

우리는 왜
사고를 보존하지 못하는 구조를
반복해서 만들게 될까?

다음 글에서는

사고를 보존하지 못하는 구조가

어떤 공통된 형태를 가지는지를 살펴본다.