JavaScript 미드레벨 시스템 설계 면접

검색 API는 데이터 조회이므로 GET 메서드를 사용하는 것이 RESTful 원칙에 부합하며, Query Parameter 방식을 선택하는 것이 적절합니다. 이 방식은 URL이 북마크 가능하고 브라우저 캐싱을 활용할 수 있다는 장점이 있지만, URL 길이 제한(약 2048자)이 있어 복잡한 필터는 제한될 수 있습니다. 응답 데이터는 pagination 메타데이터(total, page, pageSize, hasNext)와 실제 items 배열을 분리하여 구조화하고, 각 상품 객체는 필요한 필드만 선택적으로 반환하는 Sparse Fieldsets 패턴을 적용합니다. 매우 복잡한 검색 조건이 필요한 경우 POST /search 엔드포인트를 별도로 제공하되, 이는 예외적인 경우로 한정하고 문서화에 명시합니다. 검색 결과는 캐시 키로 쿼리 파라미터 조합을 해싱하여 Redis에 저장하고, TTL을 짧게(5-10분) 설정하여 실시간성과 성능의 균형을 맞춥니다.

실시간 채팅은 양방향 통신이 필수이므로 WebSocket이 가장 적합하며, 단일 TCP 연결로 낮은 레이턴시와 오버헤드를 제공합니다. Long Polling은 구현이 간단하지만 요청마다 HTTP 오버헤드가 있고, SSE는 서버에서 클라이언트로만 단방향 통신이 가능하므로 채팅에는 부적합합니다. 수평 확장 시에는 Redis Pub/Sub을 활용하여 각 서버 인스턴스가 채팅방별 채널을 구독하고, 메시지를 받으면 해당 채널로 publish하여 모든 인스턴스에 브로드캐스팅합니다. Sticky Session 대신 Redis를 메시지 버스로 사용하면 사용자가 어느 서버에 연결되어 있어도 메시지를 받을 수 있습니다. 재연결 전략은 Exponential Backoff 알고리즘을 적용하고, 클라이언트는 마지막으로 받은 메시지 ID를 저장하여 재연결 시 누락된 메시지를 요청하는 방식으로 유실을 방지합니다. 메시지는 MongoDB나 PostgreSQL에 영구 저장하여 히스토리 조회와 복구를 지원합니다.

사용자 피드는 읽기가 압도적으로 많고 개인화되어 있으므로 Cache-Aside 패턴이 적합하며, 각 사용자 ID를 캐시 키에 포함시켜 user:feed:{userId} 형태로 구성합니다. Write-Through는 모든 쓰기 시 캐시를 업데이트해야 하므로 피드처럼 복잡한 집계 데이터에는 비효율적입니다. 캐시 무효화는 Time-based Expiration(TTL 5-10분)을 기본으로 하고, 새 게시물 작성 시에는 팔로워들의 피드 캐시를 즉시 삭제하는 대신 다음 요청 시 재생성하는 Lazy Invalidation 방식을 적용합니다. 좋아요/댓글 수는 Eventually Consistent 방식으로 처리하되, 실시간성이 중요하면 해당 게시물 부분만 별도 캐시 키로 분리합니다. Thundering Herd 방지를 위해서는 캐시 재생성 시 분산 락(Redis SETNX)을 획득한 첫 번째 요청만 DB 조회를 수행하고, 나머지는 짧은 시간 대기 후 캐시를 읽도록 구현합니다. 추가로 Probabilistic Early Expiration을 적용하여 TTL의 90% 시점부터 확률적으로 캐시를 갱신하면 만료 시점이 분산됩니다.

URL Path 방식(/v1/users)이 가장 명확하고 직관적이며, API 문서화와 클라이언트 구현이 쉽고 CDN 캐싱도 용이하여 실무에서 가장 많이 사용됩니다. Header 방식은 RESTful 원칙에 더 부합하지만 가시성이 떨어지고 디버깅이 어렵습니다. Query Parameter 방식은 선택적 버전 지정이 가능하지만 URL이 복잡해지고 캐싱 키 관리가 어렵습니다. 하위 호환성 유지를 위해서는 Breaking Change가 없는 변경(필드 추가, 선택적 파라미터 추가)은 같은 버전 내에서 처리하고, 필드 삭제나 타입 변경 같은 Breaking Change만 새 버전을 만듭니다. 점진적 마이그레이션은 새 버전 출시 후 최소 6개월의 유예 기간을 두고, 구버전 API 응답 헤더에 Deprecation과 Sunset 헤더를 포함시켜 클라이언트에게 경고합니다. API Gateway나 프록시 레이어에서 버전별 라우팅을 처리하면 백엔드 코드 중복을 최소화할 수 있으며, 구버전 요청을 내부적으로 신버전으로 변환하는 어댑터 패턴을 적용할 수 있습니다.

작은 이미지는 일반 Multipart Form Data로 서버를 거쳐 S3에 업로드하는 방식이 구현이 간단하고 적합하지만, 대용량 파일은 서버 메모리와 대역폭을 소진하므로 클라이언트가 S3 Presigned URL을 받아 직접 업로드하는 방식을 적용해야 합니다. Presigned URL 방식은 서버 부하를 제거하고 업로드 속도를 높이며, S3 Multipart Upload API와 결합하면 파일을 청크 단위로 나눠 병렬 업로드할 수 있습니다. Resumable Upload를 위해서는 각 청크의 ETag를 클라이언트에 저장하고, 업로드 중단 시 이미 완료된 청크는 건너뛰고 나머지만 재개합니다. 서버는 업로드 세션 정보를 Redis에 저장하여 서버 재시작 시에도 복구 가능하도록 하고, 일정 시간 동안 완료되지 않은 Multipart Upload는 S3 Lifecycle Policy로 자동 삭제하여 스토리지 비용을 방지합니다. 업로드 완료 후에는 Lambda나 백그라운드 작업으로 이미지 리사이징, 비디오 트랜스코딩 같은 후처리를 비동기로 수행하며, 상태는 데이터베이스에 기록하여 클라이언트가 폴링하거나 WebSocket으로 알림을 받을 수 있도록 합니다.