이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
모바일 환경을 고려한 API 설계에서 가장 주의했던 것은 불필요한 데이터를 응답에 포함하지 않는 것이었습니다. 모바일은 네트워크 상태가 불안정하고 대역폭이 제한되는 경우가 많아, 같은 정보라도 응답 크기가 클수록 사용자 경험에 직접 영향을 줍니다. 팀 프로젝트에서 필드 필터링 파라미터를 지원해 클라이언트가 필요한 필드만 요청할 수 있게 했더니 페이로드 크기가 눈에 띄게 줄었습니다.
페이지네이션 방식도 신경 썼는데, 오프셋 방식은 데이터가 변경되면 중복이나 누락이 생겨 커서 기반 방식으로 변경했습니다. 네트워크 오류 재시도도 모바일에서는 중요한 고려 사항인데, API가 멱등성을 보장하면 재시도 로직을 클라이언트가 안전하게 구현할 수 있습니다. 모바일 API는 서버 편의보다 클라이언트 환경의 제약을 먼저 고려하는 것이 결임을 배웠습니다.
모바일 API에서 응답 크기를 줄이는 작업을 하면서 수치로 효과를 확인한 경험이 있습니다. 응답에서 클라이언트가 실제로 사용하지 않는 필드를 분석했는데, 전체 응답의 40% 이상이 화면에 표시되지 않는 데이터였습니다.
불필요한 필드를 제거하고 gzip 압축을 추가한 뒤 응답 크기를 측정했습니다. 압축 전에 비해 전송 크기가 절반 이하로 줄었고, 느린 네트워크 환경을 시뮬레이션한 테스트에서 첫 화면 표시까지 걸리는 시간이 의미 있게 개선됐습니다.
ETag 기반 캐싱을 추가로 적용했을 때 가장 효과가 컸습니다. 데이터가 변경되지 않은 경우 서버가 304 응답만 돌려주니 재접속 시 전송량이 거의 없어졌고, 클라이언트가 캐시된 응답을 즉시 표시하는 속도가 빨라졌습니다. 모바일 API 최적화는 네트워크 환경 제약을 실제 수치로 먼저 파악하는 것에서 시작한다는 생각이 이 경험에서 자리 잡혔습니다.
모바일 API를 개발하면서 버전 관리가 왜 중요한지를 직접 겪었습니다. API 응답 구조를 변경했을 때 이미 배포된 이전 버전 앱이 업데이트되지 않은 사용자 환경에서 오류가 나는 상황이 생겼습니다.
웹 앱은 배포하면 모든 사용자가 즉시 새 버전을 받지만, 모바일 앱은 사용자가 직접 업데이트해야 합니다. 이 차이를 처음 경험하고 나서 API를 변경할 때 기존 클라이언트가 정상 동작하는지를 명시적으로 확인하는 단계를 추가했습니다.
신규 필드를 추가하는 것은 하위 호환성이 유지되지만, 기존 필드를 제거하거나 타입을 바꾸는 것은 이전 클라이언트를 깨뜨릴 수 있습니다. 이후 API 변경 시 영향받는 클라이언트 버전 범위를 먼저 파악하고, 제거가 필요한 경우 deprecated 처리 후 일정 기간이 지난 뒤 제거하는 방식으로 접근했습니다. 모바일 API는 변경 비용이 웹보다 크다는 것이 이 경험에서 남은 결입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.