결정이 너무 많고, 전략은 부족
Source: Dev.to
개요
많은 프로젝트, 특히 마감 압박이 있을 때 우리는 기술 부채를 의식적으로 감수하는 선택을 합니다. 이것은 현실의 일부입니다. Clean Code와 Clean Architecture에는 비용이 들며, 항상 적절한 시점에 그 비용을 지불할 시간이나 상황이 있는 것은 아닙니다.
문제는 이러한 결정이 전략적 의미를 잃고 단순히 반응적인 선택이 될 때 시작됩니다.
최근 프로젝트와 PR을 검토하면서 반복되는 패턴을 발견했습니다: if/else 혹은 switch/case가 길게 이어지는 로직. 대부분은 부주의에서 비롯된 것이 아니라, 즉각적인 문제를 해결하기 위해 누적된 작은 결정들의 결과입니다.
항상 Clean Code나 Clean Architecture를 이상적인 형태로 적용할 수 있는 것은 아닐지도 모릅니다.
그럼에도 불구하고 데이터 구조를 이해하고 이를 지원할 간단한 로직을 설계하는 것이 코드를 급격히 악화시키는 것을 방지하는 최소한의 방법입니다.
여기서 중요한 점은 모든 개선이 대규모 refactor나 완전한 아키텍처 재구성을 요구하는 것은 아니라는 것입니다. 종종 로직을 단순화하고, 전략을 개선하며, 데이터 구조를 더 적절히 선택함으로써 복잡성을 낮추고 프로젝트에 큰 위험을 도입하지 않을 수 있습니다.
완벽한 코드를 추구하는 것이 아니라, 오늘의 작은 결정이 내일의 고비용 유지보수로 이어지는 것을 방지하는 것이 목표입니다. 잘 정의된 지도, 책임의 명확한 분리, 혹은 더 선언적인 로직만으로도 코드를 더 예측 가능하고 덜 취약하게 만들 수 있는 충분한 단계가 됩니다.
이러한 고민이 저를 논리와 전략에 초점을 맞춘 일련의 글을 쓰게 만들었습니다. 목표는 결정을 없애는 것이 아니라, 상황이 이상적이지 않더라도 더 나은 결정을 내리는 것입니다.
왜냐하면 결국 기술 부채는 우리가 하지 않은 일만을 의미하지 않습니다. 문제를 해결하는 방식 자체가 부채가 되기도 합니다.