1. 업무 분장이 잘 되어 있지 않으면 특정 인원들에게만 일이 지속적으로 몰린다(어쩌면 같은 말). 이들이 결국 지쳐서 나가떨어지게 된다. 거기에 자꾸 일을 밀어 넣으면서 과부하를 만들어내면 어떻게든 돌아는 가게 되는데, 생산적으로 일하는 것과는 거리가 멀어진다. 밀어 넣는 사람은 큰 고민 없이 밀어 넣지만, 당장 쳐내기 바빠 장기적으로 효율성을 고민하기보다 단기적으로 땜빵 위주로 돌아가기 때문이다. 근무 환경의 악화가 지속되다 보면 퇴사를 결심하는 요인이 된다. 당연히 인수/인계 과정에서 정보 손실이 많이 발생한다. 문서화나 프로세스화가 잘 되어 있을 리 만무하다 -- 그럴 시간이 있었으면 애초에 퇴사각도 안 잡혔겠지.
2. 잘 정돈된 코드와 데이터는 중요하다. 완벽한건 존재할 수 없으나 엉터리 코드는 너무나도 당연하게 존재한다. 데이터를 가공하고 분석하는 전 과정이 부실하고, 잘 작동하지 않고, 유지보수에 비용이 많이 들어가는 형태로 되어 있으면 후속 단계로 나아갈 수 없다. 이런 상황이면 거기서 뭔가 해보려는 마음도 잘 생기지 않게 된다. 코드는 어떠한가? 거의 똑같지만 약간씩 다른 복붙 형태의 A, A', A'', A''' 등등은 얼핏 보면 열심히 한 것 같지만 각각 사이드 이펙트를 안고 있어서 일을 N배로 하게 된다. 실제로 고치는 사람은 각각 비교하면서 해야 하니까 적어도 N^2의 업무를 해야 한다. 공통부분을 뽑아내고, 외부에 영향을 미치는 내용들은 별도로 분리되어 있었으면 좋았을 듯. 기술적으로 어려운 일은 아니라고 생각한다.
예전 모 회사에서 일할 때 한 cpp 파일에 5000~10000라인 가까이 되는 코드들이 있었는데, 버그를 하나를 고치면 다른 버그가 나올수밖에 없는 전형적인 스파게티 코드. 원인을 찾아서 고치기보다는 clear 함수를 부르는 식으로 해결을 했다고 하는데, 당장은 해결은 될지 몰라도 예상하지 못한 버그가 또 생기길 것은 너무나도 당연하다. 참고로 그 팀은 워낙 야근이 심해서 업무 쳐내기 바쁜 악순환의 고리에 진입을 했었다. 그래도 약간은 의욕적인 사람들이 있는지라 나름대로 고쳐보고 생산성을 개선해보려고 하는데, 그런 사람들마저도 손절각을 잡게 되면 패배주의가 급속도로 확산된다. 결국 그 회사는 망했다.
3. 코드를 고쳐도 될까? 이 엑셀 파일을 고쳐도 될까? 이런 현상은 이해 부족에서 일어나는 경우가 많은 것 같다. 괜히 고쳤다가 문제를 심각하게 만들거나 그럴까봐 두려운 것이다. 코드가 도대체 어떤 식으로 돌아가는지 테스트도 전혀 없는 상태에서 코드를 고쳐도 되는지 안되는지 확신을 할 수가 없기 때문에, 잘 돌아가는 것들은 일단 놔두고 안 돌아가는 것들, 새로 구현해야 하는 코드들은 A'로 만드는 것. 사이드이펙트가 즐비한 소스코드기 때문에 본질을 고치려면 A를 손을 대지 않을 수가 없다. 그것보다 A', A'' 등을 추가하면서 기술 부채를 지수함수적으로 늘려나가는 선택들을 하게 된다. 마찬가지로 엑셀 파일도 수식 따라가고 그런 게 좀 불편해서 그렇지 계산 과정 자체가 복잡한 경우는 드물다. 여기서도 유사한 현상을 보게 되는데, 기존 데이터 테이블에 병합하는 것이 아니라 테이블 밑에 합쳐놓는 게 아니고 자꾸 주석처럼 따로따로 노는 것이다.