소프트웨어 개발 업계에서는 "코드는 비즈니스를 위한 수단이다"라는 말이 있습니다. 이는 비즈니스 목표 달성이 코드 품질보다 우선시되어야 한다는 주장으로 해석될 수 있는데요. 이러한 관점에서, 개발자는 코드 품질에 얼마나 신경을 써야 하는지 고민하게 됩니다.

그러나 현실적으로, 좋지 않은 코드는 장기적으로 비즈니스에 부정적 영향을 미칠 수 있습니다. 예를 들어, 겉으로 보기엔 무해해 보이는 함수가 예기치 않게 동작하여 사이드 이펙트를 일으키고, 이로 인해 버그가 발생할 수 있습니다. 이러한 버그는 문제를 해결하는 데 추가적인 시간을 소모하게 만들고, 결과적으로 예상 일정을 초과하게 되는데요. 버그발생 확률이 증가하고, 개발 생산성이 저하되며, 기술 부채가 축적되는 악순환이 반복될수 있습니다.

따라서, 코드의 품질은 비즈니스 목표와 마찬가지로 매우 중요합니다. 그리고 품질이 높은 코드는 아래와 같은 특성을 갖습니다.

1. 추상화: 도메인 로직을 제외한 순수 함수로 구성된 재사용 가능한 컴포넌트(리유저블 컴포넌트) 작성

2. 가독성: 누구나 쉽게 읽고 이해할 수 있는 코드를 작성

3. 심미적 및 아키텍처적 관점: 코드의 역할과 책임이 명확하게 분리되어 있어야 하며, 이해하기 쉬운 구조

그렇다면 촉박한 개발 일정으로 바쁜 와중에, 코드 품질은 언제 챙겨야 할까요?

켄트 벡의 "Tidy First"에서 언급된 것처럼, 리팩토링에 적절한 타이밍을 찾아 자주 리팩토링을 적용하는 것이 좋습니다. 주니어 개발자는 종종 촉박한 일정산정으로 인해 리팩토링이나 아키텍처에 대한 고민 없이 코드를 작성하게 되는데요. 이는 장기적으로 보았을때, 낮은 코드퀄리티와 버그 발생 의 악순환에 빠지게 될 수 있습니다.

결론적으로, 코드 품질과 비즈니스 목표는 상호 보완적인 관계에 있는데요. 토스의 모닥불 이라는 코너에서는 위와 같은 실제 개발 과정에서의 고민들과 그 해결 방안을 다루어서 유익하고 재미있게 보았습니다. 비슷한 고민을 하고 있는 분들이라면 이 영상을 보시는것을 추천드립니다.

https://toss.tech/article/firesidechat_frontend_1