임시 PHP 코드가 필수 의존성이 됐다면, 유지보수는 누구 몫일까요

핵심 요약

• 임시로 만든 코드도 다른 프로젝트에 들어가면 오래 쓰이는 의존성이 될 수 있습니다.
• 약 2천만 회라는 설치 횟수를 실제 사용자나 서비스 수로 해석해서는 안 됩니다.
• 사용 중단 권고가 곧바로 작동 중단이나 보안 결함을 뜻하지는 않습니다.
• 외부 패키지를 쓰기로 한 조직에는 유지보수 상태를 확인하고 교체를 준비할 책임이 있습니다.

12년 전 만든 임시 PHP 코드가 약 2천만 번 설치됐다는 이야기는 놀라우면서도 어딘가 불편합니다. 제이크 스미스(Jake Smith)의 http-build-url 패키지와 사용 중단 권고를 두고도 같은 고민이 생깁니다. 누군가 잠깐 쓰려고 공개한 코드가 우리 서비스에 꼭 필요한 부품이 됐다면, 그다음부터는 누가 돌봐야 할까요?

설치 횟수와 유지보수 약속은 별개입니다

숫자가 무엇을 뜻하는지부터 살펴보겠습니다. 이 사례의 ‘12년’과 ‘약 2천만 회’를 정확한 기간과 집계 기준까지 검증된 수치라고 단정하기는 어렵습니다. 특히 설치 횟수는 사용자 수와 다릅니다.

패키지는 프로그램에 가져다 쓰는 코드 묶음입니다. 개발자 한 명도 개발 환경을 새로 만들거나 자동 테스트를 실행할 때 같은 패키지를 여러 번 설치할 수 있습니다. 직접 고른 패키지가 아니어도 다른 패키지에서 필요로 해 함께 설치되기도 합니다.

따라서 누적 설치가 약 2천만 회라고 해도, 2천만 명이 사용했다거나 2천만 개 서비스가 의존한다고 말할 수는 없습니다. 다운로드가 많다고 해서 전담 관리자가 있거나 장기 지원을 보장하는 것도 아닙니다.

얼마나 많이 쓰이는지와 누가 어떻게 관리하는지는 따로 확인해야 합니다.

임시 코드라고 저절로 사라지지는 않습니다

임시 코드는 대개 눈앞의 문제를 해결하려고 만듭니다. 필요한 기능이 없거나 기존 환경에서 제대로 작동하지 않을 때, 작은 코드를 덧붙여 부족한 부분을 메우는 식입니다.

그런데 코드가 잘 작동하면 굳이 바꿀 이유를 찾기 어렵습니다. 새 기능 개발은 일정표에 올라가지만, 문제없이 돌아가는 의존성을 점검하는 일은 뒤로 밀리기 쉽습니다.

예를 들어 한 팀이 편의를 위해 패키지 A를 가져다 썼다고 해보겠습니다. A가 내부적으로 작은 패키지 B를 사용한다면, 팀은 B가 있는 줄도 모른 채 거기에 의존하게 됩니다. 이런 관계를 간접 의존성이라고 합니다.

처음 작성한 사람에게는 임시방편이었던 코드가 사용하는 조직에는 쉽게 빼낼 수 없는 부품이 될 수 있습니다. 잠깐 쓸 생각으로 만든 코드라도 가져다 쓰는 쪽의 사정은 달라질 수 있습니다.

그래서 ‘임시’라고 불러두는 것만으로는 부족합니다. 무엇으로 대체할지, 언제 다시 검토할지 정해두어야 필요할 때 쓰고 걷어낼 수 있습니다.

사용 중단 권고는 무엇을 뜻할까요?

사용 중단 권고, 즉 deprecation은 일반적으로 앞으로 사용을 피하거나 다른 방식으로 옮겨가라는 뜻입니다. 이미 설치한 코드가 그 순간 작동을 멈춘다는 말은 아닙니다.

유지보수 종료, 저장소 보관 처리, 배포 중단도 각각 다른 상태를 가리킵니다. 실제로 어떤 영향을 받는지는 관리자의 공지 내용을 살펴야 알 수 있습니다. http-build-url 역시 구체적인 공지 없이 보안 문제가 생겼다거나 즉시 교체해야 한다고 확대해석해서는 안 됩니다.

물론 지금 잘 돌아간다고 해서 앞으로도 누군가 계속 관리해준다는 보장은 없습니다.

실행 환경이 바뀌면 호환성 문제가 드러날 수 있고, 결함을 발견해도 고칠 사람이 없을 수 있습니다. 사용 중단 권고를 받았다면 당장 오류가 나는지 확인하는 데서 그치지 않고, 앞으로 문제가 생겼을 때 누가 대응할 수 있는지도 살펴야 합니다.

만든 사람의 책임과 사용하는 조직의 책임

저는 코드를 공개했다는 이유만으로 작성자에게 끝없이 지원을 기대하는 건 무리라고 봅니다. 별도로 약속한 지원 범위가 있다면 그 약속을 살펴야겠지만, 설치 횟수가 늘었다고 새로운 지원 계약이 생기는 것은 아닙니다.

물론 유지보수를 어떻게 끝내느냐도 중요합니다. 어디까지 지원하는지, 알려진 한계는 무엇인지 분명히 알리면 사용자도 계속 쓸지 판단하기 쉽습니다. 대안이 있다면 함께 안내해주는 것도 도움이 됩니다.

서비스를 운영하는 조직에서도 다음 내용을 확인하고 방향을 정해야 합니다.

• 해당 패키지를 직접 쓰는지, 다른 패키지를 통해 쓰는지 확인합니다.
• 패키지가 맡은 기능과 문제가 생겼을 때 서비스에 미칠 영향을 살펴봅니다.
• 대체 패키지 도입, 자체 관리, 기존 프로젝트 지원 중 가능한 방법을 정합니다.

특히 자체 관리는 코드를 복사해두는 것으로 끝나지 않습니다. 이후에 드러나는 결함을 고치고 호환성을 확인할 사람이 필요합니다. 외부 개발자에게 맡겨두었던 일을 이제 조직 안에서 직접 해야 하기 때문입니다.

중요한 패키지라면 개발 시간이나 비용을 보태는 방법도 생각해볼 수 있습니다. 서비스가 그 패키지에서 얻는 가치와 유지보수에 들이는 자원을 함께 놓고 따져볼 만합니다.

임시 코드가 오래 쓰인다고 해서 실패라고 볼 수는 없습니다. 다만 오래 쓸수록 누가 어떤 상태로 관리하고 있는지 다시 확인해야 합니다. 서비스가 의존하는 작은 패키지 하나가 내일 유지보수를 끝낸다면, 팀 안에서 그다음 관리를 맡을 사람이 누구인지도 알아두어야 합니다.