캐리버스에서 선배 개발자로 재직 중이신 동료분께서 전달해주신 Git Submodules를 알게되고 토이프로젝트 “o11y”에서 사용하면서 느낀 경험과 의견에 대한 정리입니다.
개요
가장 기본적인 Git 사용과 그 한계를 알아보고 Git Submodules를 소개하고자 합니다.
또한 느낀 바를 기준으로 각 언어군 Golang, Python, Node에서 어떻게 사용하면 좋을지에 대한 생각입니다.
기본적인 Git
대표적인 형상관리 툴인 Git은 일반적으로 모놀리식(Monolithic) 프로젝트에서 매우 편리하게 사용할 수 있습니다.
하지만 Frontend, Backend가 “같은 타입”을 공유해야 한다고 했을 때, 이 문제를 어떻게 해결할 수 있을까요?
타입 공유의 문제?
가장 대표적인 해결 방법은 각 진영에 존재하는 Package Manager를 사용하는 것일 겁니다.
go get
pip/pip3 install
npm install
하지만 이 방법은 코드가 공개되는 치명적인 단점이 존재합니다.
Git Submodules
이 기능을 사용하면 한 Git Repository를 다른 Git Repository 하위로 종속시킬 수 있습니다. 이를 통해 Client, Server가 같은 타입을 공유할 수 있습니다.
가장 대표적인 타입 공유 예시는 RESTful API의 Request Type, Response Type이 있을 수 있을 것 같습니다.
장점
말 그대로 위와 같이 타입 공유를 할 수 있다는 점은 큰 매력인 것 같습니다.
특히 패키지 매니저와 달리 전문적인 지식이 거의 없이도 타입을 공유할 수 있습니다.
단점과 극복 방안
말 그대로 같은 파일을 공유하기 때문에 누군가 common파일을 수정했을 때의 여파가 멀리 퍼지게 됩니다. 따라서 common파일을 수정하지 못하도록 강제하는 테스트코드가 필요해 보입니다.
이를 기반으로 common 이 수정되었을 때를 세개의 Git Repository에서 테스트할 필요가 있어 보입니다.
Client : common test code
Server : common test code
Common : common test code
또한 common 코드의 테스트 케이스 전체의 md5 값을 캐싱하고 이 값이 달라지만 알림을 발송하여 Client, Server 단을 갱신하도록 하는 것도 좋아 보입니다.
하지만 궁극적으로 common이 잦은 변경을 하지 않도록 RESTful API 명세서를 작성하는데에 많은 시간을 들이는 것이 합리적일 것 같습니다.
결론
몇 가지 단점이 있는 것 같지만 “세상에 완벽한 기술”이 없듯, 전체적으로 좋은 기술인 것 같습니다. 특히 요즘에는 마이크로서비스가 많아지면서, 다 언어에 호환되는 라이브러리들이 많습니다.
예를 들어, PrismaORM은 Node.js와 Python에서 동시에 호환됩니다.
따라서 이런 라이브러리에 대한 코드를 submodules로 관리하면 Node.js + Python으로 구성된 마이크로서비스가 구성 가능해 보입니다.
