코드를 적게 쓰는 것도 책임감이다 — 오픈소스 메인테이너의 이야기

코드를 많이 쓰는 게 항상 좋은 걸까?

개발자라면 누구나 한 번쯤 고민해봤을 거예요. 기능을 더 추가하고, 라이브러리를 더 키우고, 더 많은 코드를 작성하는 게 정말 '잘하는' 건지 말이에요. Rust 생태계에서 활발하게 활동하는 오픈소스 메인테이너 orhun이 자신의 경험을 바탕으로 "코드를 적게 쓰되, 더 책임감 있게 쓰자"는 주제로 글을 썼는데요, 개발자로서의 태도에 대해 깊이 생각하게 만드는 내용이에요.

의존성(dependency)이라는 무게

이 글에서 가장 핵심적으로 다루는 건 '의존성의 무게'예요. 이게 뭐냐면, 내가 만든 라이브러리를 다른 사람이 자신의 프로젝트에 가져다 쓸 때 — 그러니까 내 라이브러리가 누군가의 '의존성'이 될 때 — 나는 그 사람의 프로젝트에 대해 일종의 책임을 지게 되는 거예요.

예를 들어, 내가 만든 작은 유틸리티 라이브러리가 인기를 얻어서 수백 개의 프로젝트에서 쓰이고 있다고 해볼게요. 어느 날 내가 API를 확 바꾸거나, 보안 취약점을 방치하거나, 관리를 포기하면, 그 영향은 나 한 사람이 아니라 수백 개 프로젝트와 그 뒤에 있는 수많은 개발자들에게 퍼지는 거죠. 2016년의 left-pad 사건이 대표적인 예시예요. 11줄짜리 작은 패키지가 npm에서 삭제되면서 수많은 프로젝트의 빌드가 깨졌거든요.

"더 적게, 더 신중하게"

orhun은 코드를 작성할 때 몇 가지 원칙을 제안해요. 먼저, 새로운 의존성을 추가하기 전에 정말 필요한지 한 번 더 생각하라는 거예요. 작은 기능 하나를 위해 거대한 라이브러리를 통째로 가져오는 건 배보다 배꼽이 큰 격이니까요.

그다음으로, 라이브러리를 만드는 입장에서는 기능을 무한정 늘리기보다 핵심 기능에 집중하고, 그 범위 안에서 품질을 높이는 데 에너지를 써야 한다고 말해요. feature creep이라고 하죠 — 기능이 계속 추가되면서 프로젝트가 점점 비대해지고 관리가 어려워지는 현상이요. 이걸 의식적으로 막아야 한다는 거예요.

또 하나 인상적인 건, 코드를 삭제하는 것도 기여라는 관점이에요. 불필요한 코드를 걷어내고, 의존성을 줄이고, 인터페이스를 단순하게 만드는 작업이 새 기능을 추가하는 것만큼이나 — 때로는 그 이상으로 — 가치 있다는 거죠.

업계 전체의 흐름과 맞닿아 있는 이야기

이 글은 최근 소프트웨어 업계에서 점점 강해지고 있는 '공급망 보안(supply chain security)' 논의와 맞닿아 있어요. xz-utils 백도어 사건(2024년)이 보여줬듯이, 오픈소스 의존성 하나가 전체 시스템의 보안을 위협할 수 있거든요. 그래서 의존성을 줄이고, 각 의존성의 신뢰성을 검증하는 게 점점 중요해지고 있어요.

Rust 생태계에서는 cargo-audit이나 cargo-deny 같은 도구로 의존성을 관리하고, Go는 아예 언어 설계 단계부터 의존성을 최소화하는 철학을 갖고 있죠. JavaScript/Node.js 생태계는 의존성이 폭발적으로 많은 것으로 유명한데, 이 때문에 번들 사이즈나 보안 문제가 자주 이슈가 되기도 해요.

주니어 개발자에게 특히 와닿는 이야기

사실 이 글의 메시지는 경력과 관계없이 모든 개발자에게 유효하지만, 주니어 개발자라면 더 일찍 이런 마인드셋을 갖추는 게 좋아요. 처음에는 '많이 만드는 것'에 집중하게 되는데, 어느 순간 '잘 만드는 것'과 '유지보수 가능하게 만드는 것'의 가치를 알게 되거든요.

실무에서도 새로운 npm 패키지나 pip 패키지를 설치하기 전에 "이걸 직접 구현하면 몇 줄이지?", "이 라이브러리의 메인테이너는 활발하게 활동하나?", "의존성이 얼마나 깊은가?" 같은 질문을 던져보는 습관을 들이면 좋아요.

마무리

핵심은 간단해요. 코드를 쓸 때 양보다 질, 그리고 내가 쓴 코드가 다른 사람에게 미치는 영향까지 생각하자는 거예요.

여러분은 새로운 의존성을 추가할 때 어떤 기준을 세우고 있나요? 혹시 의존성 때문에 곤란했던 경험이 있다면 나눠주세요!