이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
멀티 모듈 구조는 안드로이드 앱 학부 프로젝트에서 처음 적용해봤습니다. 기능 도메인 단위로 모듈을 나누고, 공통 유틸리티는 별도 모듈로 분리해 여러 기능 모듈에서 참조하는 구조를 만들었습니다. 모듈 간 의존성 방향을 단방향으로 유지하려고 신경 썼는데, 순환 의존이 생기면 빌드 오류와 함께 설계 결함을 의미한다는 것을 배웠습니다.
각 모듈이 자신의 책임 범위만 노출하도록 인터페이스를 설계하면 다른 모듈이 내부 구현에 의존하는 상황을 막을 수 있었습니다. 초기에 모듈 경계를 잘못 나누면 나중에 재구성 비용이 크기 때문에, 기능 단위를 먼저 명확히 정의하는 것이 중요했습니다. 멀티 모듈 구조가 빌드 시간 단축과 팀 병렬 개발에 실질적으로 도움이 된다는 것을 경험했습니다.
멀티 모듈 구조를 적용하다가 두 feature 모듈이 서로 참조하는 순환 의존성이 생겼습니다. 빌드가 실패해서 처음에는 혼자 원인을 찾다가 의존성 그래프를 그려봤는데, 두 모듈이 공통으로 쓰는 데이터 모델을 각자 정의하고 서로 가져오는 구조가 원인이었습니다. 팀원에게 공유했더니 '공통 모델은 core 모듈로 올려야 한다'는 방향을 잡아줬습니다.
공통 데이터 모델을 core로 분리하고 feature 모듈은 core에만 의존하도록 방향을 수정하니 순환 의존이 사라졌습니다. 이 경험 이후 새 모듈을 추가할 때는 의존성 방향을 먼저 그린 뒤 코드를 작성하는 순서가 됐습니다. 순환 의존성은 빌드 오류로 드러나지만, 그 전에 설계에서 잡는 것이 비용이 낮다는 걸 배웠습니다.
처음 멀티 모듈 구조를 설계할 때 '기능 단위로 나누면 된다'는 생각으로 접근했는데, 모듈 수가 늘면서 어디에 뭘 넣어야 하는지 팀원마다 판단이 달라지는 문제가 생겼습니다. 같은 기능이 두 군데 모듈에 나뉘어 구현된 것도 발견했습니다. 팀과 함께 모듈 분리 기준을 '변경 빈도'와 '소유권' 두 축으로 정리했습니다. 자주 바뀌지 않는 공통 유틸·네트워크는 core, 팀별로 독립 개발하는 화면 단위는 feature, 앱 전체 진입점은 app으로 정의했습니다. 이 기준을 MODULE_GUIDE.md로 정리해 새 모듈 추가 시 참고하도록 했습니다. 기준이 생기고 나서 신규 기능이 어느 모듈로 가야 할지 논의가 줄었고, 변경이 적은 core 모듈 덕분에 빌드 시간도 단축됐습니다.
설계 기준을 문서로 남기는 것이 팀 일관성을 만드는 방법이라는 걸 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 트립비토즈 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.