본문 바로가기

Backend/질문 시리즈

[Five Lines of Code] 코드 삭제의 미학을 읽고 나서

[Five Lines of Code] 코드 삭제의 미학을 읽고 나서

🔖 주제                                                            

Five Lines of Code는 TypeScript를 기반으로 코드를 어떻게 리펙토링 하는지 A to Z 형식으로 소개하는 책입니다.

사내 스터디에서 총 13챕터로 나누어 소개하고 있으며, 이번 주제는 코드 삭제의 미학 9 챕터입니다.

책에서는 리펙토링의 과정에 코드 삭제가 왜 필연적이고 지속적으로 발생해야 하는지 이야기하고 있습니다.

📓 설명                                                            

매몰 비용의 오류

매몰 비용(Sunk Cost Fallacy)“과거에 이미 소비되거나 투자된 비용으로 현재 및 미래의 의사결정에 관여되는 것”을 말하며 “경제학 및 의사결정 이론”에서 사용되는 개념입니다

책에서는 이를 “의사결정을 왜곡하는 오류”라고 표현합니다.

다양한 관점에서 부연설명이 필요하겠지만, 책에서 이와 같이 표현한 이유는 “코드 자체를 비용”으로 바라보기 때문입니다.

즉, 작성된 코드는 모두 매몰 비용이며, “작성된 스크립트가 많을수록 비용이 커지며 현재 및 미래의 유지보수, 기능개발에 관여되는 것”이라 생각한 표현입니다.


복잡성 제거

애플리케이션은 다양한 요구사항을 복합적으로 처리하며 확장하게 되며 책에서는 이를 “복합 경계 조건”이라 표현합니다.

“복잡성”이라는 것은 어떤 방식이던 개발 비용을 증가시키는 일로 이어지기 때문에, 단순히 “제거”를 목표하는 것보다 어떤 “유형”에서 발생하는지 알아야 합니다.

일반적으로 복잡성이 만들어지는 것에 가장 큰 지분을 차지하는 것은 “도메인 설계”입니다.

요구 기능 파악이 잘못될 경우 추상적으로 그려낸 멘탈모델(인식모형) 구축에 영향이 미치고, 이는 곧 도메인으로 구분하는 과정에 문제를 야기합니다.

두 번째는 ”부수적 복잡성”입니다.

도메인에서 요구하지 않았음에도 “우연히(아니면 미래를 생각하며) 추가된 모든 기능”은 곧 “복잡성”으로 판단됩니다.

이 모든 것은 “기술부채”이며 장기적으로 팀 전체에게 영향이 발생합니다.


부족으로 인한 기술적 무지

앞선 설명에 “어떤 유형에서 발생하는지”를 이야기했습니다.

제거라는 핵심 주제와 거리가 있을 수 있겠지만, 결국 이 또한 미래에 발생할 비용에 대한 제거라 생각하며 어떻게 해야 발생을 줄일 수 있을지 고민해 보았습니다.

 

“경험” 부족

다양한 레퍼런스 (책, 블로그 서적, 유튜브), 협업 프로그래밍, 컨퍼런스 참여"경험"부족을 줄일 수 있는 수단은 계속 늘어나고 있으며, 꾸준한 노력을 통해 해결할 수 있습니다. 

 

“시간” 부족

요구사항을 이해할 수 있는 충분한 시간이 주어지지 않았다면, 이는 곧 “멘탈모델” 구축에 영향이 생깁니다.

일반적으로 이러한 상황에서 “테스트, 리팩토링”은 무시되어 버립니다.

기한을 맞추기 위해 “프로세스를 우회”하는 경우도 있습니다.

해당 경우는 다양한 관계에 영향을 받을 수 있고 절대적인 "시간"부족은 단순히 개발 역량을 높이는 것으로는 해결이 어렵다 생각합니다.

 

“환경” 부족

사업 방향이 “단기적 이익”만 바라본다면, 개발 속도가 강제로 조절되는 경우가 발생합니다.

“경쟁사 존재 여부, 시장 확장, 민원 대응” 등 대처가 시급한 요구사항이 발생할 수 있으며 거부하기 힘들 수 있습니다.

"만료일”에 맞추어 대응하는 것은 어려운 일이며, 종종 앞서 설명한 “시간 부족”으로 이어지는 경우가 존재합니다.

“환경이 퀄리티가 낮춘다” 또는 "역량이 부족했다"라는 생각을 할 수 있지만, 매번 모든 상황이 좋을 수 없습니다.

여기서 생각할 것은, “시간 부족”으로 인해 결국 “부채가 발생할 것” 이며 이자가 불어나기 전에 갚아야 합니다.

 

결과적으로 어떠한 상황이든 “경험”, “시간”, “환경”에 대한 부족을 매번 피할 수 없습니다.

우리는 발생할 문제에 대해 걱정하고 스트레스 받는 것 보다 이를 유연하게 피해갈 수 있는(또는 해결하는) 방법이 필요합니다.

이를 위해 각 기능 간의 결합을 줄여나가고 “비슷한 기능”이더라도 본질을 파악하여 “동일한 요구사항” 인지 알아내는 것이 중요합니다.

📚 정리                                                            

매몰 비용의 오류

  • 작성된 코드는 전부 비용으로 계산된다.
  • 단순하게 계산하면 적은 코드를 작성하는 것이 곧, 비용 감소로 이어진다.

기술부채

  • 부채는 돈을 빌려 생긴 빚을 의미합니다.
  • 일반적으로 부채는 시간이 지날 수록 이자가 늘어나는 구조입니다.
  • "복잡성"을 장기간 해결하지 않으면, 이해하는 사람이 줄어들어 "해결"에 많은 비용이 발생할 것을 표현했다 생각합니다.
  • “기술 부채”는 선형적으로 오르는 것이 아닌 지수 그래프를 표현하듯 상승합니다.

📦 공유 자료