빠른 해결책의 숨겨진 비용

Source: Dev.to

배경

오늘 나는 코드에서 빠른 수정이 가져오는 진정한 비용에 대한 가혹한 교훈을 얻었다. 프로덕션 이슈를 디버깅하던 중, 6개월 전에 구현한 겉보기에 무해한 “임시” 해결책이 얽힌 의존성의 복잡한 웹을 만들었고, 이 때문에 현재의 수정이 기하급수적으로 어려워졌다는 사실을 발견했다. 원래의 빠른 수정은 마감일을 맞추기 위해 적절한 검증 체크를 우회하는 것이었으며, 당시에는 “지금만 쓰는 것”이라서 해가 없을 것처럼 보였다.

결과

내가 예상하지 못한 것은 이 임시 해결책이 코드베이스 전체에 퍼져 나간 방식이었다. 다른 개발자들이 이 동작 방식을 보고 그대로 사용하면서, 원래의 우회 방법 위에 또 다른 여러 층의 우회 로직이 쌓였다. 근본적인 문제가 결국 프로덕션에서 드러났을 때, 단순히 해결할 수 있었던 문제가 여러 상호 연결된 컴포넌트를 리팩토링해야 하는 3일간의 디버깅 마라톤으로 변해버렸다.

교훈

이 경험을 통해 나는 “임시 코드 해결책”이라는 것은 존재하지 않는다는 것을 배웠다. 우리가 작성하는 모든 한 줄의 코드는 시스템의 영구적인 DNA의 일부가 되어, 현재 기능뿐 아니라 미래의 유지보수성에도 영향을 미친다. 이제 나는 코드가 얼마나 작고 사소해 보여도 핵심 시스템 아키텍처에 적용하는 것과 같은 엄격함으로 접근한다. 적절하고 유지보수 가능한 코드를 작성하는 데 몇 분을 더 투자하는 것이, 나중에 빠른 수정을 풀어내는 데 소요되는 시간이나 일수보다 항상 큰 가치를 만든다.