코드 가독성의 딜레마: 쪼갤 것인가, 흘려보낼 것인가? - Part 3. 추상화와 선형코드 사이에서 균형 잡기

2025.12.13 - [잡다한 지식] - 코드 가독성의 딜레마: 쪼갤 것인가, 흘려보낼 것인가? - Part 1. 추상화 수준 일치

2025.12.13 - [잡다한 지식] - 코드 가독성의 딜레마: 쪼갤 것인가, 흘려보낼 것인가? - Part 2. 선형 코드

Part 3. 추상화와 선형성 사이에서 균형 잡기

 

지난 두 번의 포스팅에서 두 가지 관점을 살펴보았습니다.

1. 추상화 수준을 맞춰야 한다.
2. 선형적(전체적 맥락을 포함한) 으로 작성해야한다.

두 글 모두 수긍이 갑니다. 그래서 더 혼란스럽습니다.

내 코드에 어떤것을 적용해야하나요?

이것이 소프트웨어를 공부할 때 상황에 따라 매버 다르다라는 말이 나오게 하는 이유 중 하나입니다.

우리는 단순히 이렇게 하라는 것을 따르는 것을 넘어 두 가지 관점의 철학 사이에서 균형을 잡아야합니다.

 

글의 가독성은 고정된 것이 아닙니다. 읽는 사람의 목적에 따라 변합니다.

어떻게 코드를 구성되었는지 알고 싶은 사람은 추상화 수준이 된 코드가 가독성이 좋을 것입니다.

하지만 특정에러를 파헤치려고 할 때는 여러 로직을 볼 필요없는 선형 코드를 가독성이 좋다고 할 수 있습니다.

 

결국, 가독성은 관점에 따라 다양하게 달라질 수 있으며,

우리는 프로젝트의 미래에 더 적은 비용을 초래하는 쪽을 선택해야 합니다.

 

 

언제 추상화를 선택하고 선형성을 선택할지 판단하는 기준

 

• 추상화 선택: 도메인의 핵심 비즈니스 로직이나 여러 곳에서 재사용될 가능성이 높은 코드처럼, 잦은 변경이 예상되는 부분은 추상화를 통해 격리하는 것이 미래의 비용을 줄여줍니다.
• 선형성 선택: 단순한 데이터 변환이나 단일 진입점을 가진 유틸리티성 코드처럼, 변경 가능성이 낮고 맥락 파악이 한 곳에서 중요한 부분은 선형적으로 작성하여 디버깅 비용을 낮추는 것이 합리적입니다.

스스로 각 개념의 철학을 이해하도록 노력해야 합니다.

 

처음에는 어렵습니다.

어떻게 짤지 애매한 부분은 일단 선형적으로 작성후 나중에 수정하면 됩니다.

동료 검토 등을 프로세스를 구축하시는 것을 추천합니다.

리팩토링해야지... 했을 때 실제로 하는 사람을 많이 못 본것 같습니다.

모두 업무에 바쁘기 떄문이라고 생각하빈다.

그러므로 동료 검토 등의 피드백을 받을 수 있는 프로세스를 구축하여 시스템 안에 들어가세요.

 

이러한 과정을 거치다 보면 자신만의 기준이 생기게 됩니다.

비즈니스와 도메인을 이해하게 되면서 생긴 기준일 수도 있고,

팀이나 개인의 스타일에 맞춰진 기준일 수도 있습니다.

 

규칙을 맹신하지 말고, 한번쯤 "왜 이렇게 해야 하는가"를 깊이 생각해보고,

내가 사용하는 개념이 가진 철학을 이해하도록 노력할 때, 우리는 더 좋은 개발자로 성장할 수 있을 것입니다.