이미 해결된 문제를 풀지 말자: 중복 코드의 순환에서 벗어나기

Source: Dev.to

It’s a scenario that plays out in countless offices and home offices every day: a software developer stares at a tricky problem, cracks their knuckles, and begins architecting a solution in their mind. They envision the modules, the APIs, and the elegant lines of code that will slay the dragon. Days, or even weeks, later they emerge with a working solution, proud of their creation, only to discover (or have a colleague point out) that an open‑source library or internal tool already does the exact same thing.

Sometimes the existing tool is even better than what the developer built.

This phenomenon is the source of a well‑worn joke in the industry: “Every time a developer encounters a problem, they start building a solution, completely missing that it already exists.” While it’s funny, the reality behind it is a costly and frustrating cycle of duplicated effort. It’s a multifaceted issue rooted in psychology, corporate culture, and sometimes a lack of training. It’s often summarized by the pejorative term “Not Invented Here” (NIH) syndrome.

“Proudly Found Elsewhere”에 대한 주장

이 중복의 비용은 충격적입니다. 이는 단순히 낭비된 개발 시간만이 아니라, 동일한 것을 약간씩 다른 여러 구현을 유지하는 복합적인 비용입니다.
버그 수정은 모두 여러 곳에 적용해야 합니다.
새로운 개발자는 여러 시스템을 배워야 합니다.
시간이 지나면서 소프트웨어 생태계는 비대해지고 취약해집니다.

**“Proudly Found Elsewhere”**에 대한 문화적 전환은 필수적입니다. 이 사고방식은 모든 코드를 직접 작성하는 개인적 만족보다 비즈니스 문제 해결을 우선시합니다. 이는 오픈‑소스 유지보수자이든 옆 건물의 팀이든, 거인의 어깨에 올라서는 것이 더 빠른 전달, 높은 품질, 그리고 보다 지속 가능한 소프트웨어를 만든다는 것을 인식합니다.

“다른 곳에서 자랑스럽게 찾음” 문화를 구축하는 방법

NIH 증후군을 극복하려면 개인과 조직 모두의 의식적인 노력이 필요합니다.

조직을 위한 전략: 블랙홀 대신 마켓플레이스를 만들자

• 코드를 찾기 쉽고 사용하기 쉽게 만들기.
• 팀이 명확한 문서, 사용 예시, 버전 관리를 갖춘 라이브러리를 게시할 수 있는 내부 컴포넌트 마켓플레이스에 투자하기.
• 팀이 기술적 과제를 논의하고 솔루션을 공유하도록 장려하는 협업 문화를 조성하기.

조직을 위한 전략: 재사용을 장려하기

• 측정 지표를 바꾸기.
• 내부 라이브러리에 기여하는 엔지니어와 이를 재사용하는 엔지니어에게 보상하기.
• 기존 컴포넌트를 활용해 더 빠르게, 버그를 적게 만든 프로젝트를 축하하기.

개발자를 위한 전략: “어떻게”보다 “왜 안 되는가?”를 먼저 묻기

• 로깅, 인증, 데이터 검증 등 흔히 발생하는 문제에 대해 코드를 한 줄이라도 쓰기 전에, 기존 솔루션을 습관적으로 찾아보기.
• 팀원에게 물어보고, 회사 위키를 확인하고, 오픈소스 라이브러리를 찾아보기.
• 반증할 수 있을 때까지 해결책이 이미 존재한다고 가정하기.

개발자를 위한 전략: 포크하지 말고 기여하기

• 기존 라이브러리가 80 % 정도의 요구를 충족한다면, 남은 20 % 를 처음부터 새로 만들지 않기.
• 누락된 기능을 원 프로젝트에 기여하거나 플러그인 형태로 확장하는 방안을 고려하기.
• 기존 도구를 개선하는 것이 영원히 유지보수해야 할 새로운 도구를 만드는 것보다 거의 항상 더 좋다.

미묘함: 재창조가 올바른 선택일 때

바퀴를 다시 만드는 것이 항상 나쁜 것만은 아니다; 때때로 혁신으로 이어지기도 한다. 개발자 Lea Verou가 주장했듯이, 전체 기능 중 아주 작은 부분만 사용할 때 거대한, 부풀린 라이브러리를 사용하는 것은 상당한 성능 오버헤드와 장기적인 유지보수 비용을 초래할 수 있다. 라이브러리 기능의 **5 %**만 필요하다면, 작고 목적에 맞게 만든 함수를 직접 작성하는 것이 실제로 더 현명한 선택일 수 있다.

예를 들어, 굵은 텍스트와 링크를 위한 간단한 마크다운 몇 줄을 파싱하는 데 1,700줄짜리 라이브러리가 반드시 필요한 것은 아니다. 작은 커스텀 함수가 더 효율적으로, 그리고 훨씬 적은 복잡도로 작업을 수행할 수 있다.

핵심은 의도성이다. 목표는 개발자가 살펴보지 않거나, 물어보지 않거나, 신경 쓰지 않아 발생하는 우연하거나 오만한 바퀴 재창조를 방지하는 것이다. 창조의 자부심에서 실제 문제를 효율적으로 해결하는 만족감으로 초점을 옮김으로써, 우리는 이 비용이 많이 드는 악순환을 탈피할 수 있다.

새로운 것을 처음부터 만드는 것을 축하하듯, 완벽한 기존 솔루션을 찾는 것도 똑같이 축하해야 한다.