내가 생각하는 좋은 코드에 대하여

 

“어떤 것이 좋은 코드라고 생각하세요?”

 

개발자라면 한 번쯤은 들어봤을 만한 이 질문은,

내가 개발을 시작할 때부터 지금까지 계속 이어져온 고민이기도 하다.

 

우리는 항상 더 나은 코드를 작성하려 애쓰지만, 무엇이 “좋은 코드”인지 쉽게 단정 짓기 어렵다.

흔히 “좋은 코드”라고 하면 깔끔한 구조, 뛰어난 가독성, 높은 재사용성 등을 떠올리기도 한다.

 

이 글 작성까지 2년이 넘는 시간이...

 

사실 “좋음”이라는 것은 상황과 가치 판단에 따라 다르게 해석될 수 있는 상대적인 개념이 아닐까 싶다.

이 글은 오랜 시간 동안 고민해왔던 바로 그 지점에서 시작되었다.

 

 

나는 좋은 코드가 맥락에 따라 달라질 수 있는 개념이라 생각하고,

그 맥락에는 팀 내 멘탈 모델 공유가 큰 영향을 끼친다고 본다.

 

 

이 글에서는 좋은 코드의 맥락 의존성(상대성)과,

좋은 코드를 향해가기 위한 팀원 간 멘탈 모델 일치의 중요성에 대해 이야기해보고자 한다.

 

좋은 코드의 상대성, 그리고 비즈니스 맥락

 

우리가 좋은 코드를 “왜” 작성해야하는가  부터 생각해 보자

 

왜 우리가 개발자로서 클린 코드를 지향해야 하는지에 대한 …. ~ 중략

이는 더 나은 생산성과 더 안정적인 제품을 만들기 위해 필요합니다.
그렇다면 왜 제품이 안정적이어야 할까요? → 그것은 고객의 불편함을 줄이기 위함입니다.

고객의 불편함을 덜면 어떤 좋은 점이 있을까요? → 이는 고객이 제품을 떠날 요인을 줄일 수 있습니다.
고객 이탈이 줄어들면 어떤 이점이 있을까요? → 그것은 기업의 성장과 매출로 이어질 확률을 높입니다.

- 내가 작성한 모 프로그램 지원서 중

 

소프트웨어 개발에서 코드는 궁극적으로 비즈니스 목표를 달성하기 위한 수단이라고 생각한다.

 

아무리 우아한 설계와 최신 기술을 적용했다 해도, 실제 프로젝트의 목적에 부합하지 않으면

그 코드를 “좋다”라고 부를 수 있을까?

 

 

예를 들어, 극도로 빠른 MVP 출시가 필요한 상황에서는

일정 수준의 단순하고 직관적인 코드가 더 효과적이라고 생각한다.

 

반면, 안정성과 확장성이 중요한 프로젝트에서는

충분한 논의와 시간 투자를 통해 견고하게 설계된 코드가 필요한 경우가 많다.

 

 

결국 “코드가 어느 상황에서 쓰이느냐”를 고려하지 않고서는,

그 코드가 정말 좋은지 판단하기 쉽지 않다.

 

그래서 나는 “좋은 코드”라는 것이 “특정 평가지표가 존재하는 것” 라기보다,

“해당 프로젝트와 팀이 처해 있는 맥락에 따라 달라지는 상대적인 가치"라고 본다.

 

멘탈 모델 → 코드를 바라보는 서로 다른 시선

또한 팀원 각자가 지닌 멘탈 모델이 코드에 대한 이해와 해석을 얼마나 달라지게 하는 지를 주목하고 싶다.

 

멘탈 모델이란 개인이 세상을 이해하고 해석하는 내면적 틀이라고 할 수 있다.

프로그래밍에서 멘탈 모델의 다양성은 개발자 개인의 학습 경로, 기술적 배경, 경험에 영향을 받는다.

 

각 개발자는 자신만의 렌즈를 통해 코드를 이해하고 문제를 해결하려 한다.

 

 

예를 들면

• 개발자 A는 객체지향 설계 패턴에 익숙해, 복잡한 구조도 직관적으로 이해
• 개발자 B는 함수형 프로그래밍 스타일을 선호하며, 람다나 고차 함수가 낯설지 않음
• 개발자 C는 복잡한 패턴보다는 간단한 절차지향적 흐름이 익숙

이들은 똑같은 코드를 두고도 전혀 다른 반응을 보일 수 있다.

 

 

이처럼 멘탈 모델이 다르면 누군가에게 “좋은 코드”로 보이는 것이

다른 누군가에게는 난해하고 복잡하게 느껴질 수 있다.

 

 

협업이 원활하기 위해서는 팀원들의 멘탈 모델 차이를 어느 정도 줄여가는 노력이 필수적이라는 생각이 든다.

 

멘탈 모델을 좁히기 위한 교육과 스터디의 중요성

팀원들의 멘탈 모델이 어느 정도 비슷해지면, 자연스럽게 좋은 코드에 대한 합의도 쉬워진다고 본다.

 

이를 위해 팀 내부에서 스터디나 세미나, 정기적인 코드 리뷰 등의 활동을 통해

지식과 이해를 공유하는 과정이 꼭 필요하고 생각보다 더 중요하게 다뤄야 한다.

 

 

이렇게 교육과 스터디가 활발해지면 팀 내 공통된 “공용어”가 마련되고,

특정 패턴이나 설계가 낯설지 않게 되어 코드에 대한 눈높이도 점차 맞춰진다.

 

 

가끔 기업들이 채용 과정에서 “기술 허들”을 높게 책정하는 이유도,

어쩌면 기존 팀이 공유하고 있는 멘탈 모델 수준에 부합하는 인재를 찾으려는 목적이 크지 않을까 추측한다.

 

해당 역량을 갖춘 사람을 뽑으면,

이후 교육이나 스터디에 투입되는 에너지를 상대적으로 줄일 수 있다고 여기는 것 같다는 생각이 든다.

 

 

 

여기서 더 나아가, 이러한 멘탈 모델 공유의 중요성과 역량의 수준을 맞추는 교육의 필요성을

회사나 팀 차원에서 적극적으로 인식하고 지원해야 한다고 생각한다.

 

개인 개발자들이 자발적으로 스터디를 운영하고 학습을 진행하는 것에 더해

조직차원에서 스터디 문화를 장려하고 관련 자원을 투자하는 움직임이 필요하다는 것이다.

 

예를 들어 사내에서 정기적으로 교육 프로그램을 마련하거나,

코드 리뷰 정책을 강화하거나,

지식 공유를 장려하는 문화가 자리 잡히면

 

팀 전체가 일관된 방향으로 성장하기 훨씬 수월해진다고 본다.

 

 

이때 주의 해야 할 점은

이 과정을 단순히 기술적 지식을 넘어 팀의 문화와 가치관을 공유하는 과정으로 여기는 것과

구성원들의 다양성을 인정하면서도 동시에 차이를 좁히기 위한 일관성 있는 접근이 필요하다는 것이다.

 

 

결국 이러한 노력이 모여야 “좋은 코드”에 대한 팀의 합의점이 자연스럽게 형성되고,

더욱 효율적인 협업이 가능해질 것이라 기대할 수 있다.

 

쉬움(Easy)과 단순함(Simple)

코드를 읽으면서 ‘쉬운 것(Easy)’과 ‘단순한 것(Simple)’을 동일하게 취급하는 혼동이 종종 생긴다.

 

Easy 한 코드는 지금 당장 익숙하고 이해하기 편한 코드일 수 있다.

하지만 때로는 내부 설계가 복잡한데도,

익숙한 문법이나 관습에 기대어 상대적으로 쉽게 느껴질 뿐인 경우가 있다.

 

 

Simple한 코드는 불필요한 추상화나 복잡함을 제거하여 논리를 간결화한 코드다.

그러나 오히려 낯선 개념이나 패턴이 도입될 수 있어,

처음에는 일부 개발자에게 쉽지 않게 느껴지기도 한다.

 

이처럼 Easy와 Simple은 겉보기엔 비슷해 보여도 서로 다른 개념이다.

 

 

팀의 역량과 문화, 그리고 학습 의지에 따라

언제는 “지금 바로 쓰기 편한(Easy)” 접근을 취하는 것이 현명할 수도 있고,

반대로 “장기적으로 유지보수가 용이한(Simple)” 방식을 우선해야 할 때도 있다.

 

결국 이상적인 상태는 “단순함(Simple)이 곧 쉬움(Easy)으로 이어지는” 단계가 아닐까?

 

이를 위해서는 역시나 팀 차원에서 꾸준한 학습과 경험 공유가 필수적이며,

 

공통된 이해 수준을 끌어올림으로써 익숙지 않은 ‘Simple한 코드’마저도

자연스럽고 편안하게 다룰 수 있게 되는 환경을 만들어가는 노력이 필요하다.

 

마무리

“좋은 코드”의 기준은 절대적이지 않으며, 프로젝트의 맥락과 팀의 역량에 따라 달라질 수 있다.

 

또한, 팀원들의 멘탈 모델 차이를 좁혀가며 함께 성장하는 과정이야말로

좋은 코드를 향해가는 핵심이라고 생각한다.

 

이를 위해 팀 내부의 교육, 세미나, 스터디, 코드 리뷰 등을 적극적으로 활용해야 한다.

 

 

코드는 혼자 쓰는 것이 아니라, 팀과 함께 만들어가는 결과물이다.

비즈니스 목표를 이해하고, 팀의 멘탈 모델을 공유하는 협업 문화는 더 나은 코드를 만드는 힘이 된다.

 

 

결국, 좋은 코드란 완벽한 코드가 아니라,

팀이 함께 고민하고 성장하며 만들어가는 여정이라고도 볼 수 있겠다.