예시 답변 1
약 102초
패키지 버전 충돌 문제 발견 후 워크스페이스 설정 정리 중심으로 푸는 결
사이드 프로젝트에서 프론트엔드와 백엔드를 한 저장소에서 관리하는 구조를 처음 써봤습니다. ERR_PNPM_NO_IMPORTER_MANIFEST_FOUND No package.json (or package.yaml, or package.json5) was found in "/Users/seong-in/Desktop/Git/interview_question_project".를 사용했는데, 초기에는 공통 유틸리티 패키지를 각 앱에서 가져다 쓰는 게 편했습니다. 문제는 특정 패키지의 버전이 앱마다 다르게 설치돼 있을 때 빌드 결과가 달라지는 경우였습니다. 한쪽에서는 4.x를 쓰는데 다른 앱에서는 3.x가 설치돼 있어서, 같은 함수를 호출했는데 동작이 달랐습니다. 이걸 파악하는 데 생각보다 오래 걸렸고, 이후에는 루트 에서 공통 의존성 버전을 고정하고, 앱별로 버전을 따로 명시하지 않는 방식으로 통일했습니다. 빌드 도구는 를 도입해 변경이 없는 패키지는 캐시를 재사용하도록 설정했습니다. 덕분에 전체 빌드 시간이 약 40% 줄었습니다. 모노레포의 장점은 공통 코드를 한 번만 관리할 수 있다는 점이고, 단점은 초기 설정이 복잡하고 의존성 충돌이 생겼을 때 원인을 추적하기 어렵다는 점입니다. 설정 문서를 팀 내에 남기지 않으면 나중에 합류한 팀원이 구조를 파악하기 어렵다는 것도 직접 느꼈습니다.
이 결의 특징
의존성 버전 충돌로 빌드 결과가 달라지는 문제를 루트에서 공통 버전을 고정하고, 변경 없는 패키지는 캐시 재사용으로 전체 빌드 시간을 40% 단축한 흔적이 있습니다. Turborepo의 dependsOn 설정으로 변경된 패키지에 의존하는 앱만 선택적으로 재빌드한 경험도 포함됩니다.
이 결이 통하는 자리
빌드 캐시 전략과 의존성 그래프를 명확히 정의한 개입이 눈에 띄고, CI 소요 시간이 줄었다는 결과가 구체적으로 살아 있을 때 통합니다. 멀티레포 합치기에서 re-export를 임시 허용하고 점진적으로 참조를 교체한 현실적 접근이 드러나면 면접관의 꼬리질문이 줄어드는 자리가 보입니다.