패키지를 최신 버전으로 맞추려는 시범 실험

24일 밤 11시 반을 넘긴 시각, 더배러 대화방에 개발 현장의 오랜 습관을 뒤집자는 글이 올라왔다. 한 참가자는 이렇게 물으며 이야기를 열었다.

원래, IT 개발 프로젝트는, 릴리즈 되고 나서는 패키지 업데이트를 최대한 안하는게 당연한 관례였지 않습니까?

릴리즈는 프로그램을 내놓는 일이고, 패키지는 프로그램이 가져다 쓰는 외부 부품 묶음이다. 이 참가자의 설명은 이랬다. 최근에는 패키지의 취약점을 노리는 공격이 잇따르는 시기가 되어서, 이제는 업데이트를 계속하며 프로젝트를 고쳐 나가는 쪽이 미덕이 될 수 있다는 것이다. 공격이 잇따른다는 진단과 일본이 총리까지 나서서 PHP 긴급 업데이트를 요청했다는 이야기는 이 참가자가 대화에서 전한 내용이고, 방 안에서 따로 확인된 것은 아니다.

열두 개 프로젝트를 한 버전으로

이 참가자는 이 구상을 자신의 로컬 프로젝트에 직접 적용하고 있다고 했다. 본인이 개발해 돌리는 프로그램이 열두 개인데, 지금은 프로젝트마다 패키지가 따로 설치되고 버전도 제각각이라는 것이다. 이를 공통 저장소에 한 번 설치하고 각 프로젝트가 연결해 쓰는 방식으로 바꾸는 중이라고 했다. 방법은 AI 코딩 도구에게 물어 얻었다.

pnpm 공통 저장소와 중앙 버전 목록 방식을 사용하면 된다고, Codex 가 말해줘서, 따라가보고 있습니다.

편집자가 덧붙이면, pnpm은 자바스크립트 패키지를 관리하는 도구다. 목표는 두 줄로 요약됐다. 모든 프로젝트가 같은 최신 버전을 쓰고, 호환성 문제가 생기면 라이브러리를 붙들지 않고 프로젝트 쪽 코드를 고친다는 것이다.

호환성 문제가 생기면 프로젝트 코드를 수정해서 따라가자

이 참가자 스스로도 이를 기존의 상식을 정면으로 깨는 행위라고 불렀다. 같은 도구가 구글도 비슷한 방식을 쓴다고 알려 줬다는 전언이 이어졌지만, 이것 역시 AI의 답을 옮긴 것이어서 대화 안에서 검증되지는 않았다.

시범 전환에서 드러난 것

반응은 짧았다. 다른 참가자는 비용 전망 이야기에는 유지보수의 가치가 올랐으면 좋겠다고 적었고, 상식을 정면으로 깨겠다는 말에는 슬프지만 두근거린다고 적었다. 제안한 참가자는 곧 한 프로젝트를 먼저 바꿔 본 결과를 알렸다. 열두 개 전체가 아니라 하나를 시험 삼아 옮긴 것이다.

대충 만든 코드들이 드러나네요 :)

바로 이어 같은 참가자는 기존 라이브러리에 딱 붙어 있던 코드가 분리되며 정리되고 있다고도 했다. 버전을 맞추는 일이 코드 품질을 비추는 거울처럼 작동했다는 보고인 셈이다. 또 다른 참가자는 자신도 올해 3월부터 작은 프로젝트를 만들고 고쳐 가며 비슷한 점을 느끼고 있다고 했다. 다만 무엇을 느꼈는지는 대화에 풀리지 않았다.

비용과 인식에 대한 전망

제안한 참가자는 이 흐름이 비용에도 닿는다고 봤다. AI가 들어오면 IT 비용이 줄 줄 알았지만, 쓰는 동안 계속 업데이트해야 한다는 인식이 퍼지면 도로 늘 수 있다는 것이다. 세탁기가 생긴 뒤 빨래가 매일의 일이 되어 사람이 하는 일의 총량이 줄지 않았다는 비유를 들었다. 한편 유지보수 비용이 늘지 않도록 자동화하는 방향으로 갈 것이라고도 했다.

다만 기존에 유지보수 안하던 것도, 유지보수를 계속 하는 것으로 인식이 전환될 가능성이 높습니다.

읽을 점

이 대화에서 새로운 것은 업데이트가 필요하다는 주장 자체보다 순서를 바꾸자는 제안이다. 호환이 깨질까 봐 버전을 묶어 두던 방식 대신, 최신에 맞추고 코드를 따라가게 하겠다는 것이다. 시범 전환에서 대충 만든 코드가 먼저 드러났다는 보고는 이 방식이 의존성 문제와 함께 코드의 빚도 드러낸다는 사례로 읽힌다.

다만 근거는 한 사람이 열두 개 중 한 개를 바꿔 본 경험에 한정된다. 전체 전환의 결과, 호환성 충돌이 얼마나 나왔는지, 자동화가 실제로 비용을 막았는지는 이번 대화에 나오지 않았다. 구글의 방식과 일본이 총리까지 나서서 요청했다는 이야기도 전해 들은 이야기로 남아 있다.