두 방식 모두 실제로 사용해 본 결과…
Multirepo
프론트엔드와 백엔드를 각각 별도의 저장소에서 관리한다.
저장소별 설정이 독립적이기 때문에 초기 구조는 비교적 단순하고, 각 서비스의 배포와 운영도 분리하기 쉽다. 하지만 저장소가 분리되니 API 계약과 타입을 동기화하는 별도의 방식이 필요하다:
- OpenAPI 스키마 기반 클라이언트 코드 생성
- 공유 타입 패키지 배포
- 계약 전용 레포지토리 운영
- CI/CD를 통한 스키마와 자동 타입 동기화
이 중 OpenAPI 스키마 기반 코드 생성을 직접 사용해봤는데, 실제 개발 과정은:
- 백엔드에서 로직을 작성하고
- OpenAPI 스키마 기반의 문서도 작성하고
- 프론트엔드에서 Orval로 API 클라이언트를 생성해서 사용한다.
문서만 잘 관리하면 안정적으로 사용할 수 있는데, 문서를 작성하고 계약이 변경될 때 마다 클라이언트를 다시 생성해야 하는 과정이 번거롭다. 외부에 공개되는 API라면 이런 문서화 과정이 반드시 필요하기 때문에 감수해야 하지만, 굳이 외부 공개 API가 아니라면 1인 개발자가 이 정도의 계약 관리 비용을 감수할 필요가 있는지 고민하게 된다. (나머지 선택지들도 너무 과한게 아닌가 싶다.)
Monorepo
가장 큰 장점은 프론트엔드와 백엔드 사이의 타입을 쉽게 공유할 수 있다는 점이다. RPC를 사용하면 API 타입과 호출 방식이 자연스럽게 연결되기 때문에, 별도의 스키마를 작성하거나 클라이언트를 생성하는 과정 없이 빠르게 개발할 수 있다. 특히 백엔드를 별도의 서비스로 분리하면서도 프론트엔드와 백엔드를 한 사람이 함께 개발하는 상황에서는 효율적이라고 느꼈다. (두 영역에서 동시에 변경이 발생해도 하나의 저장소 안에서 함께 수정하고 검증할 수 있기 때문)
반면 설정과 구조는 더 복잡하다. 워크스페이스, 빌드, 의존성, 배포 설정 등을 이해해야 하고, AI의 도움으로 설정을 완료하더라도 그 구성이 실제 의도에 맞는지 확인하려면 결국 관련 개념을 학습해야 한다. 즉, 초기 학습 비용은 있지만 이후 개발 과정에서는 Multirepo보다 극도로 편하다.
직접 사용해본 결과, 1인 개발에서 백엔드와 프론트엔드를 분리해야 한다면 Monorepo 쪽이 더 잘 맞았다. 별도의 API 문서와 클라이언트 생성 과정을 관리하는 비용보다 하나의 저장소에서 함께 변경하고 타입을 공유하는 비용이 더 작았기 때문에, 앞으로도 팀이 나눠진 상황이 아니라면 모노레포로 프로젝트를 구성할 것 같다.