이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
모노레포 환경을 처음 쓴 것은 4인 팀 풀스택 프로젝트에서였습니다. 프론트와 백엔드를 별도로 레포로 나눠 쓰다가 공통 타입 정의를 중복으로 관리하는 문제가 발생하여 모노레포로 전환하였습니다.
Turborepo를 사용하여 공통 유틸·타입을 패키지로 분리하고, 두 앱에서 가져다 쓰는 구조를 만들었습니다. 한 곳에서 수정하면 양쪽에 반영되므로 동기화 비용이 크게 줄었습니다. 빌드 캐시 덕분에 변경이 없는 패키지는 다시 빌드하지 않아도 되어 배포 시간도 짧아졌습니다. 실패는 패키지 의존성 사이클이 발생했을 때 어디서 문제가 생겼는지 파악하는 데 하루가 걸린 것이었습니다.
모노레포는 팀이 공유하는 코드가 많을수록 이득이고, 레포 수가 많아질수록 의존성 관리 비용이 커진다는 것을 직접 경험하였습니다.
모노레포의 장점은 공유 코드 관리가 쉽다는 건데, 직접 써보면서 CI 파이프라인 설정이 생각보다 복잡하다는 걸 느꼈습니다. 변경된 패키지만 빌드·테스트하도록 필터링하는 게 처음엔 잘 안 됐거든요.
팀 프로젝트에서 워크스페이스 구조로 프론트·백·공통 패키지를 나눴는데, PR이 들어올 때마다 전체 빌드가 돌아서 검증 시간이 7분이 넘었습니다. 영향받은 패키지만 빌드하도록 설정을 바꿨더니 2분대로 줄었어요. 그 설정을 만드는 데 이틀이 걸렸는데, 실패는 처음에 공식 문서만 보고 적용하다가 워크스페이스 경로가 맞지 않아서 계속 전체 빌드가 돌았던 것이었습니다.
모노레포는 처음 셋업 비용이 단일 레포보다 크고, 그 투자가 팀 규모와 공유 코드 양에 따라 회수될 수 있습니다.
모노레포를 쓰면서 예상 못 했던 장점이 하나 있었는데, 서로 어떤 코드를 쓰는지 바로 볼 수 있다는 것이었습니다. 별도 레포일 때는 다른 팀 코드를 보려면 레포를 새로 클론해야 했거든요.
팀 프로젝트에서 백엔드 팀원이 공통 패키지에 함수를 추가한 걸 제가 우연히 보고, 제가 따로 만들려던 중복 코드를 만들지 않아도 됐어요. 이런 식의 자연스러운 코드 재사용이 생각보다 자주 일어났습니다. 한 레포에서 작업하다 보니 코드 리뷰도 맥락이 풍부해서 피드백의 질이 높아지는 느낌이었어요. 실패는 공통 패키지를 수정했을 때 다른 앱에 어떤 영향이 생기는지 충분히 확인하지 않아서 한 앱이 런타임에서 오류를 냈던 것이었습니다.
모노레포는 코드 공유 이상으로 팀 전체의 코드 가시성을 높이는 효과가 있다는 걸 경험해봐야 실감합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스뱅크 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.