앱·API·어드민을 한 저장소에 두면 무엇이 쉬워지고 어려워질까

21앤에서는 사용자 앱, API, 관리자 웹이 같은 계약 도메인을 다뤘다. 모노레포를 선택한 이유도 여기에 있었다. 계약 상태와 공통 타입을 제품마다 따로 적으면 같은 변경을 여러 번 반영해야 하고, 조금씩 다른 정의가 생기기 쉽다.

공유가 줄여 준 반복

한 저장소에서 앱과 서버의 변경을 함께 볼 수 있다는 점은 풀스택으로 일할 때 도움이 됐다. API 응답 타입이 바뀌었을 때 어떤 화면이 영향을 받는지 찾기 쉬웠다. 로컬 환경도 관리자·API·데이터베이스를 함께 실행하는 흐름으로 정리했다.

하지만 타입을 가져다 쓸 수 있다는 사실과 각 앱이 같은 시점에 배포된다는 사실은 다르다. 특히 모바일 앱은 사용자가 업데이트하지 않을 수 있다. 저장소에서 한 번에 수정했다고 운영 중인 모든 클라이언트가 새 규칙을 이해하는 것은 아니다.

공유 패키지가 커질수록 생기는 질문

공유할 수 있다는 이유로 서버 전용 코드까지 섞으면 앱의 의존성이 불필요하게 넓어진다. 지금이라면 도메인 타입과 런타임 구현을 구별하겠다. 모두가 알아야 하는 상태 이름과 서버만 알아야 하는 외부 서비스 설정을 같은 편의 패키지에 넣지 않겠다.

또한 공유 타입 변경은 컴파일 오류를 보여 줄 수 있지만, 오래된 앱과의 호환성을 대신 검증하지는 못한다. 필드를 지우기 전에 기존 클라이언트가 무엇을 보내고 무엇을 기대하는지 확인해야 한다. 모노레포의 장점이 이 배포 시간 차이를 가려서는 안 된다.

다시 점검할 세 가지

첫째, 바뀐 공유 패키지를 실제로 사용하는 앱 목록을 확인하겠다. 둘째, 타입 검사뿐 아니라 요청과 응답의 의미가 유지되는지 보겠다. 셋째, 서버가 먼저 나가도 기존 앱이 동작하는지 검토하겠다. 이 세 가지는 같은 변경을 다른 층위에서 확인하는 작업이다.

모노레포는 내게 잘 맞는 도구였지만 자동으로 좋은 구조를 만들어 주지는 않았다. 공유 변경을 한눈에 볼 수 있는 장점을 얻는 대신 영향 범위를 더 책임 있게 다뤄야 했다. 다음 프로젝트에서도 저장소의 개수보다 공유할 계약과 독립적으로 배포할 경계를 먼저 정하겠다.

관련 기록: 21앤 플랫폼의 모노레포 구성