숏캐시는 앱 하나가 아닙니다. 사용자 앱, 미션 웹, 관리자 대시보드, 마케팅몰, 백엔드, 크롤링 서버까지 여러 개가 같이 굴러갑니다. 이걸 하나의 저장소에 묶어서 관리하고 있습니다.
나눠서 관리하면 생기는 문제
처음에는 서비스마다 저장소를 따로 두는 게 자연스러워 보입니다. 그런데 규모가 커지면 문제가 생깁니다.
규격이 어긋납니다. 백엔드에서 응답 형식을 바꿨는데 앱이 모릅니다. 배포하고 나서야 앱이 깨진 걸 발견합니다.
같은 코드가 여러 벌이 됩니다. 날짜 처리, 금액 표시, 오류 메시지 같은 게 서비스마다 조금씩 다르게 복사됩니다. 하나를 고쳐도 나머지는 그대로 남습니다.
어디를 같이 고쳐야 하는지 모릅니다. 기능 하나를 바꿀 때 영향을 받는 곳을 사람이 기억해야 합니다. 기억은 반드시 틀립니다.
묶고 나서 달라진 것
하나의 저장소에 묶으니 이런 게 됩니다.
- API 응답 형식을 한 곳에 정의하고 앱과 웹이 같이 씁니다. 형식이 바뀌면 바뀐 곳이 바로 표시됩니다.
- 공통 함수는 한 벌만 있습니다. 고치면 전부 반영됩니다.
- 기능 하나를 바꾸는 작업이 하나의 변경으로 묶입니다. 나중에 되돌리기도 쉽습니다.
나눠 두면 독립적일 것 같지만, 실제로는 서로 모른 채 어긋납니다.
대신 챙겨야 하는 것
물론 공짜는 아닙니다.
빌드가 느려질 수 있습니다. 전부 한 번에 빌드하면 오래 걸립니다. 바뀐 부분만 빌드하도록 설정해야 합니다.
권한 관리가 필요합니다. 모든 사람이 모든 코드를 볼 필요는 없는 경우가 있습니다. 팀이 커지면 고민해야 할 부분입니다.
규칙이 있어야 합니다. 어디에 무엇을 두는지 정해두지 않으면 금방 뒤죽박죽이 됩니다. 공통 코드와 각 서비스 코드의 경계를 명확히 해야 합니다.
어떤 경우에 권하나
작은 프로젝트에는 굳이 필요 없습니다. 이런 경우에 유리합니다.
- 앱과 웹이 같은 백엔드를 씁니다.
- 관리자 페이지가 따로 있습니다.
- 서비스가 여러 개인데 데이터가 서로 얽혀 있습니다.
- 사람이 적어서 한 명이 여러 부분을 봐야 합니다.
마지막이 특히 큽니다. 규모가 크지 않은 팀에서는 저장소를 오가는 것만으로도 시간이 새어 나갑니다.
정리
- 규격을 한 곳에서 공유하니 어긋남이 줄었습니다.
- 공통 코드가 한 벌이라 고칠 때 빠집니다.
- 대신 빌드 설정과 폴더 규칙을 처음에 잡아야 합니다.
여러 서비스를 오래 굴릴 계획이라면, 처음에 이 구조를 잡아두는 게 나중에 크게 아낍니다.