이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 멀티 모듈 안드로이드 앱 구조를 처음 설계했습니다. 초기에 모듈 분리를 과도하게 세분화했더니 순환 의존성 문제가 여러 곳에서 생겼습니다. 각 모듈이 공통 유틸리티가 없어 서로를 참조하는 구조가 원인이었고, core 모듈을 최하위에 두고 공통 인터페이스·유틸리티를 여기에만 집중시켜 의존성 방향을 단방향으로 고정했습니다. 이후 Gradle 빌드 시간이 병렬 컴파일 덕분에 21% 감소했고, 기능 모듈 하나만 수정할 때 전체 재빌드가 필요 없어졌습니다. 이 경험으로 모듈 설계는 분리 기준보다 의존성 방향을 먼저 정의하는 것이 핵심이라는 것을 배웠습니다.
팀 프로젝트에서 기능이 늘면서 하나의 모듈이 너무 많은 역할을 맡게 되는 문제를 겪었습니다. 처음에는 그냥 클래스 파일만 늘었는데, 어느 순간 어디를 고치면 어디가 깨지는지 예측이 안 됐습니다. 저는 코드베이스를 도메인 경계로 나눠 각 모듈이 한 가지 책임만 갖도록 구조를 정리했습니다. 모듈 간 통신은 인터페이스만 노출하고 구현은 감추도록 패키지 접근 제어를 설정했습니다. 그 뒤로 한 모듈을 수정해도 다른 모듈 테스트가 깨지는 일이 눈에 띄게 줄었습니다. 처음에는 모듈을 나누는 게 오버엔지니어링처럼 느껴졌는데, 경계가 명확할수록 변경이 쉬워진다는 걸 직접 경험했습니다. 지금도 새 기능을 설계할 때 '이 코드가 어느 경계 안에 속하는가'를 먼저 따집니다.
인턴 기간에 레거시 모듈이 테스트하기 어려운 이유를 분석하다가, 외부 서비스 호출이 비즈니스 로직 안에 직접 박혀 있는 구조임을 발견했습니다. 테스트를 돌리려면 실제 API를 호출해야 해서 단위 테스트 자체가 불가능했습니다. 저는 외부 호출 부분을 인터페이스로 추출하고, 비즈니스 로직은 그 인터페이스에만 의존하도록 리팩터링했습니다. 테스트에서는 Mock 구현체를 주입해 실제 API 없이도 검증할 수 있게 됐습니다. 이 과정에서 모듈 경계를 제대로 나누면 테스트 가능성이 자연스럽게 올라온다는 걸 배웠습니다. 리팩터링 후 단위 테스트 커버리지가 15%에서 62%로 올랐고, 그 수치가 구조 변경의 효과를 잘 보여줬습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.