프로젝트마다 만들던 기능을 함께 쓰기까지

같은 기능을 다른 방법으로 만들고 있었다

개발자가 새로 들어올 때마다 프로젝트에서 쓰는 기술도 늘었다. 화면의 상태를 다루는 방법, 서버와 통신하는 방법, 스타일과 컴포넌트를 나누는 방법이 제각각이었다. 회원가입이나 파일 업로드처럼 비슷한 기능도 프로젝트가 바뀌면 다시 만들었다. 인프라와 데이터베이스를 매번 준비하는 일도 늘어났다.

기술을 통일하자고 말할 수는 있었지만, 결정하려면 허락을 받아야 했다. 직급이 더 높은 사람들에게 모든 기술을 한 방향으로 맞추자고 강하게 주장하기는 어려웠다. 반발이 걱정됐고, 내 선택이 더 낫다고 말할 만큼 확신도 없었다. 당시의 여러 기술을 모두 써 보고 비교할 수도 없었다.

이미 운영하거나 개발 중인 프로젝트도 많았다. 한꺼번에 바꾸기보다 기존 프로젝트와 호환되는 공통 기능을 만들고, 조금씩 적용하는 쪽으로 움직였다.

코드와 함께 쓰는 방법을 전했다

인증, 파일 저장, 캐시, 다국어 처리, 인프라 구성을 공통 패키지로 묶었다. 패키지는 다른 프로젝트가 가져다 쓸 수 있게 코드를 나눈 단위다. 같은 기능을 복사해 각각 고치는 대신, 공통 부분을 관리하고 프로젝트에서 불러다 쓰려는 생각이었다.

모든 것을 공통으로 옮기지는 않았다. 화면과 각 서비스의 업무 규칙은 프로젝트에 남겼다. 로그인에 필요한 연결을 공통으로 만들더라도, 로그인한 회원에게 무엇을 보여주고 어떤 일을 허용할지는 서비스마다 달랐다. 파일을 저장하는 기능과 그 파일을 서비스에서 어떻게 사용하는지도 나눴다.

코드를 만들고 나서는 쓰는 방법을 문서로 적었다. 사내에서 발표하고 설문을 받고, 새로 들어온 사람에게 사용법을 교육했다. 이 일도 직접 맡았다. 반응은 좋았고, 뒤로 갈수록 회원가입·로그인·파일 업로드 같은 부분에 쓰는 공수가 줄었다. 비슷한 서비스를 반복해서 만들 때 공통 기반을 가져다 쓰는 일이 가능해졌다.

얼마나 줄었는지는 수치로 재지 않았다. 쓰는 사람이 늘면서 교육해야 할 일도 생겼고, 새 기술을 적용할 때는 다시 맞춰야 했다. 공통 코드를 한 번 만드는 것으로 끝나는 일은 아니었다.

함께 쓰기 시작하니 바꾸는 일이 남았다

공통 패키지의 버전을 올렸다가 기존 프로젝트의 동작이 깨진 적도 있었다. 처음에는 사용하는 프로젝트를 함께 올리는 방식으로 대응했다. 사내에서 쓰는 패키지라 가능한 방법이었다. 하지만 프로젝트가 늘어나자 모두를 같은 시점에 바꾸기는 어려워졌다.

그 뒤에는 하위 호환을 지키는 쪽으로 신경 썼다. 하위 호환은 새 버전으로 바꿔도 기존에 쓰던 방법이 계속 동작하도록 하는 것이다. 호환을 깨야 하는 큰 변경은 메이저 버전을 나눠, 어느 버전부터 사용법이 달라지는지 구분했다.

설명을 위한 예를 들어보자. 파일을 올리면 저장된 주소를 문자열로 돌려주던 함수가 있다고 하자. 새 기능을 넣으면서 주소와 파일 정보를 묶은 객체를 돌려주게 바꾸면, 주소를 바로 화면에 넣던 기존 코드는 수정이 필요하다. 패키지 안에서는 작은 변경이어도 쓰는 프로젝트에는 작업이 생긴다. 당시 코드가 아니라, 호환이 깨진다는 뜻을 설명하기 위한 예다.

SemVer라는 버전 규칙은 이런 차이를 번호로 알리는 방법이다. 호환되지 않는 변경에는 메이저 버전을 올린다. 다만 번호를 올리는 것만으로 기존 프로젝트가 새 사용법에 맞춰지지는 않는다. 무엇이 바뀌었는지 알리고, 사용하는 쪽에서 확인하고 옮기는 일은 여전히 필요하다. SemVer 명세

더 강하게 말했으면 달랐을까

통일을 더 강하게 말하지 못한 아쉬움은 남아 있다. 범용으로 넓게 만들기보다 적용할 범위를 먼저 정하고, 함께 쓰면서 고쳤다면 어땠을까. 특히 여러 사람이 함께 개발하던 때에는 그런 방식이 나았을 것 같다.

그렇다고 지금 와서 모든 기술을 맞추는 것이 답이었다고 말하기는 어렵다. 당시에도 운영 중인 프로젝트가 있었고, 각자 익숙한 방식이 달랐다. 한 사람이 더 좋은 코드를 만들면 해결될 일이라고만 보기에는, 함께 바꾸고 익히는 일이 많이 남아 있었다.

요즘은 AI가 코드를 작성하는 상황에서 이런 공통 규칙을 어떻게 전달하고 함께 맞춰야 할지도 고민이다. 다시 비슷한 일을 맡는다면 공통으로 쓸 기능을 정할 때, 그 기능을 바꾸는 조건도 함께 이야기해보고 싶다. 기존 사용법을 언제까지 유지할지, 다른 방식이 필요한 서비스는 어디까지 다르게 갈 수 있을지 같은 문제다. 규칙을 적는다고 모두가 같은 판단을 하게 되지는 않겠지만, 코드가 바뀐 뒤에야 서로의 사정을 알게 되는 일은 줄일 수 있지 않을까.

이후 회사의 일이 달라지면서 이 공통 플랫폼은 더 키우지 못했다. 소규모로 서비스를 직접 운영할 때는 한 저장소 안의 내부 패키지를 쓰는 쪽으로 옮겨 갔다. 같은 기능을 나눠 쓰려는 생각은 이어졌지만, 관리하는 방식까지 그대로 유지할 이유는 없었다.

새 기술을 볼 때는 지금 만드는 서비스에 필요한지, 어느 일이 수익을 만들고 어디에 비용이 드는지도 함께 살피고 싶다. 이 공통 기반도 새로운 기술 자체보다 반복해서 하던 일을 줄이려는 데서 시작했다. 다음 방법을 살펴볼 여유를 남기면서, 지금 함께 쓰는 것을 계속 고칠 수 있는 쪽을 찾고 싶다.