러스트 개발자가 자기 유틸 코드를 crates.io에 안 올리는 이유

자주 쓰는 코드, 다들 어떻게 관리하세요?

개발하다 보면 프로젝트마다 똑같이 복붙하게 되는 코드가 꼭 생기거든요. 문자열을 다듬는 헬퍼 함수라든가, 에러를 깔끔하게 처리하는 패턴 같은 거요. 보통은 이런 걸 모아서 라이브러리로 만들고, 패키지 저장소에 올려둔 다음, 새 프로젝트에서 한 줄로 가져다 쓰는 게 정석처럼 여겨져요. 러스트(Rust)에서는 그 저장소가 바로 crates.io인데요. npm으로 치면 npm install, 파이썬으로 치면 PyPI 같은 공식 패키지 창고라고 보면 돼요.

그런데 러스트 생태계에서 글을 많이 쓰는 실뱅 케르쿠르(Sylvain Kerkour)라는 개발자는, 자기가 만든 표준 확장 유틸리티 모음을 일부러 crates.io에 안 올린다고 해요. 이걸 stdx라고 부르는데요, "standard extensions", 즉 러스트 표준 라이브러리가 살짝 부족한 부분을 채워주는 자기만의 코드 묶음이라는 뜻이에요. 보통 사람 같으면 "이거 유용하니까 공개해서 다 같이 쓰자" 할 텐데, 왜 굳이 안 올릴까요?

패키지 저장소에 올린다는 것의 진짜 무게

첫 번째 이유는 crates.io는 한 번 올리면 사실상 못 지운다는 점이에요. 정확히 말하면 'yank(양크)'라고 해서 "새 프로젝트는 이걸 못 쓰게 막는" 기능은 있지만, 이미 올라간 코드 자체를 영구 삭제하는 건 안 되거든요. 왜 이렇게 만들었냐면, 예전에 npm에서 'left-pad' 사건이라는 게 있었어요. 어떤 개발자가 자기가 올린 작은 라이브러리를 홧김에 삭제했더니, 그걸 깊숙이 의존하던 수많은 서비스들이 한꺼번에 빌드가 깨져버린 일이었죠. 그 교훈 때문에 crates.io는 아예 삭제를 막아둔 거예요. 좋은 정책이긴 한데, 올리는 사람 입장에서는 "한 번 공개하면 평생 책임져야 한다"는 부담이 되는 거죠.

두 번째는 버전 약속(semver)에 묶인다는 점이에요. 공개 라이브러리를 만들면 다른 사람들이 그걸 갖다 쓰니까, 함수 이름 하나 마음대로 못 바꿔요. 바꾸는 순간 그걸 쓰던 사람들 코드가 다 깨지거든요. 그래서 "메이저 버전을 올린다", "호환성을 유지한다" 같은 규칙을 신경 써야 하고, 이게 은근히 큰 유지보수 부담이에요. 반면에 자기 프로젝트 안에 그냥 코드로 넣어두면(이걸 '벤더링', 코드를 직접 품고 다닌다는 뜻이에요) 언제든 마음대로 고칠 수 있어요.

세 번째이자 요즘 가장 중요한 이유는 공급망 보안(supply chain security)이에요. 외부 의존성이 하나 늘어난다는 건, 내가 통제할 수 없는 코드가 내 프로그램 안으로 들어온다는 뜻이거든요. 작년에 있었던 'xz 백도어' 사건처럼, 오랫동안 신뢰받던 오픈소스에 누군가 몰래 악성 코드를 심어둔 사례도 있어요. 의존성이 수백 개로 늘어나면, 그중 하나만 뚫려도 내 서비스 전체가 위험해지죠. 케르쿠르는 "차라리 필요한 코드를 직접 들고 다니면서 내가 다 읽고 이해한 상태로 쓰자"는 쪽을 택한 거예요.

이게 혼자만의 유별난 취향은 아니에요

사실 이런 '의존성 최소주의'는 한 사람만의 고집이 아니라, 업계에 흐르는 하나의 철학이에요. 대표적으로 Go 언어 커뮤니티에는 "A little copying is better than a little dependency(약간의 복붙이 약간의 의존성보다 낫다)"라는 유명한 격언이 있거든요. 작은 기능 하나 때문에 통째로 외부 패키지를 끌어오느니, 필요한 부분만 직접 적는 게 낫다는 거죠. Go의 표준 라이브러리가 유난히 풍부한 것도 이런 사상과 맞닿아 있어요.

물론 반대 진영도 있어요. npm 생태계처럼 "작은 패키지를 잘게 쪼개서 마음껏 조합하자"는 문화도 분명한 장점이 있죠. 바퀴를 다시 발명하지 않아도 되고, 검증된 코드를 빠르게 재사용할 수 있으니까요. 결국 정답이 하나인 문제가 아니라, '재사용의 편리함'과 '통제 가능성·보안' 사이의 균형을 어디에 둘 거냐의 문제예요.

한국 개발자에게 주는 시사점

우리가 당장 모든 의존성을 끊고 코드를 복붙하자는 얘기는 아니에요. 다만 npm install이나 cargo add를 습관처럼 누르기 전에, "이 패키지가 정말 필요한가, 함수 몇 줄이면 될 일을 거대한 라이브러리로 해결하려는 건 아닌가" 한 번쯤 멈춰서 생각해볼 가치는 충분해요. 특히 보안이 중요한 서비스나, 오래 유지보수해야 하는 사내 프로젝트라면 더더욱요. 의존성 하나하나가 다 '미래의 나'가 관리해야 할 짐이 될 수 있거든요.

그리고 회사에서 공통 유틸 라이브러리를 만들어 사내에 배포해본 분들은 공감하실 거예요. 한 번 만들어두면 그걸 쓰는 팀들 눈치 보느라 함부로 못 바꾸잖아요. 케르쿠르가 말하는 부담이 딱 그거예요.

마무리

핵심은 이거예요. "공개 패키지로 올리는 순간, 편리함을 얻는 대신 영속성·호환성·보안이라는 책임을 떠안게 된다"는 것. 그래서 어떤 코드는 일부러 공개하지 않고 곁에 두는 선택도 합리적일 수 있다는 거죠.

여러분은 어떠세요? 자주 쓰는 유틸 코드, 라이브러리로 만들어 공유하는 편인가요, 아니면 프로젝트마다 필요한 만큼만 가져다 쓰는 편인가요? 그 선택의 기준이 궁금하네요.