Go 주니어 시스템 설계 기술면접
새 면접Q. 예약 시스템에서 특정 날짜의 예약 가능한 시간대를 조회하는 API를 설계한다고 가정합니다. 하루를 30분 단위로 나눈 시간대별로 예약 가능 여부를 반환해야 할 때, API의 엔드포인트 구조와 응답 데이터 포맷을 어떻게 설계하시겠습니까? 또한 여러 시설이나 자원을 구분해야 한다면 어떻게 처리하시겠습니까?
GET /api/v1/reservations/availability 엔드포인트에 날짜(date)와 자원ID(resource_id)를 쿼리 파라미터로 받습니다. 응답은 시간대 배열로 각 슬롯마다 시작시간, 종료시간, 예약가능여부, 현재예약자정보를 포함합니다. 자원 구분은 resource_id 파라미터로 처리하며, 여러 자원을 한번에 조회하려면 쉼표로 구분된 ID 목록이나 별도의 POST 엔드포인트를 사용합니다. 응답 구조는 availability 배열 내에 time_slot, is_available, reserved_by 필드를 포함하여 프론트엔드에서 캘린더 UI를 쉽게 구성할 수 있도록 설계합니다.
- • RESTful한 URL 구조 사용 (GET /api/v1/reservations/availability)
- • 날짜와 자원ID를 쿼리 파라미터로 전달
- • 시간대별 예약 가능 여부를 배열 형태로 반환
- • 각 시간 슬롯에 시작/종료 시간, 가능 여부, 예약 정보 포함
- • 여러 자원 조회 시 쉼표 구분 또는 POST 방식 고려
만약 예약 가능 시간대를 조회하는 요청이 매우 빈번하다면 데이터베이스 쿼리 최적화를 위해 어떤 인덱스를 설정하시겠습니까?
Q. 소셜 미디어 플랫폼에서 사용자 간 팔로우 관계를 데이터베이스에 모델링하려고 합니다. 양방향 팔로우가 가능하고(A가 B를 팔로우, B가 A를 팔로우), 팔로워 목록과 팔로잉 목록을 효율적으로 조회해야 할 때 테이블 구조를 어떻게 설계하시겠습니까? 필요한 인덱스와 쿼리 성능 고려사항도 함께 설명해주세요.
follows 테이블을 생성하여 follower_id와 following_id 두 개의 외래키 컬럼으로 관계를 표현합니다. follower_id는 팔로우를 하는 사람, following_id는 팔로우를 받는 사람입니다. created_at 컬럼으로 팔로우 시점을 기록하고, (follower_id, following_id)에 유니크 제약조건을 설정하여 중복 팔로우를 방지합니다. 조회 성능을 위해 follower_id와 following_id 각각에 인덱스를 생성하며, 특정 사용자의 팔로워를 조회할 때는 following_id로, 팔로잉 목록을 조회할 때는 follower_id로 필터링합니다. 팔로워 수와 팔로잉 수가 많은 경우를 대비해 카운트는 별도 캐싱을 고려합니다.
- • follows 테이블에 follower_id와 following_id로 관계 표현
- • (follower_id, following_id)에 유니크 제약조건으로 중복 방지
- • 양방향 조회를 위해 각 컬럼에 개별 인덱스 생성
- • created_at으로 팔로우 시점 기록
- • 팔로워/팔로잉 카운트는 별도 캐싱 고려
팔로워가 수백만 명인 유명인의 팔로워 목록을 페이지네이션으로 조회할 때 성능을 개선하기 위한 방법은 무엇이 있을까요?
Q. 알림 발송 시스템을 개발할 때 사용자에게 이메일, SMS, 푸시 알림을 보내야 합니다. 초기에는 동기적으로 처리했지만 사용자가 증가하면서 응답 시간이 길어지고 있습니다. Go에서 이를 비동기로 처리하는 아키텍처를 어떻게 설계하시겠습니까? 메시지 큐를 사용한다면 어떤 방식으로 구현할 수 있는지 설명해주세요.
알림 요청을 받으면 즉시 응답을 반환하고 실제 발송은 백그라운드에서 처리하도록 메시지 큐를 도입합니다. RabbitMQ나 Redis의 List를 큐로 사용하여 알림 정보를 큐에 넣고, 별도의 워커 goroutine들이 큐에서 메시지를 가져와 처리합니다. API 서버는 알림 데이터를 큐에 푸시만 하고 즉시 200 응답을 반환하며, 워커는 여러 개를 실행하여 동시 처리량을 높입니다. 발송 실패 시 재시도 로직과 Dead Letter Queue를 구현하여 신뢰성을 확보하고, 알림 상태는 데이터베이스에 기록하여 사용자가 발송 상태를 확인할 수 있도록 합니다.
- • 메시지 큐(RabbitMQ, Redis)를 사용한 비동기 처리
- • API는 큐에 메시지만 넣고 즉시 응답 반환
- • 별도 워커 goroutine들이 큐에서 메시지를 소비
- • 여러 워커를 실행하여 동시 처리량 증가
- • 재시도 로직과 DLQ로 신뢰성 확보, 상태는 DB에 기록
워커 프로세스가 갑자기 종료되었을 때 처리 중이던 메시지를 잃어버리지 않으려면 어떻게 해야 할까요?
Q. 뉴스 기사 상세 조회 API에서 조회수를 증가시키고 표시해야 합니다. 매 요청마다 데이터베이스를 업데이트하면 부하가 크고, 캐시만 사용하면 정확도가 떨어집니다. Go에서 조회수를 효율적으로 처리하면서도 어느 정도 정확성을 유지하는 방법을 어떻게 설계하시겠습니까?
Redis를 사용하여 조회수를 인메모리에서 증가시키고, 일정 주기마다 배치로 데이터베이스에 반영하는 Write-Behind 패턴을 사용합니다. 기사 조회 시 Redis의 INCR 명령으로 즉시 카운트를 증가시키고, 사용자에게는 Redis의 값을 보여줍니다. 백그라운드 goroutine이 1분마다 또는 일정 개수가 쌓이면 Redis의 증가분을 모아서 데이터베이스에 배치 업데이트합니다. 이를 통해 데이터베이스 쓰기 부하를 크게 줄이면서도 실시간에 가까운 조회수를 제공할 수 있습니다. 시스템 장애 대비를 위해 주기적으로 Redis 데이터를 영속화하거나 RDB 스냅샷을 활용합니다.
- • Redis INCR로 조회수를 인메모리에서 증가
- • 사용자에게는 Redis의 실시간 값 제공
- • 백그라운드 goroutine이 주기적으로 DB에 배치 업데이트
- • Write-Behind 패턴으로 DB 쓰기 부하 감소
- • Redis 영속화로 장애 시 데이터 손실 최소화
만약 Redis가 다운되었을 때 조회수 데이터를 어떻게 복구하거나 대응하시겠습니까?
Q. REST API에서 JWT 토큰 기반 인증을 구현할 때 Access Token과 Refresh Token을 함께 사용하는 이유는 무엇이며, Go에서 이를 어떻게 구현하고 관리하시겠습니까? 토큰 저장 위치와 보안 고려사항도 함께 설명해주세요.
Access Token은 짧은 만료 시간(15분~1시간)으로 API 요청 시 인증에 사용하고, Refresh Token은 긴 만료 시간(7일~30일)으로 Access Token 재발급에만 사용합니다. 이렇게 분리하면 Access Token이 탈취되어도 피해 기간이 짧고, Refresh Token은 재발급 엔드포인트에서만 사용되므로 노출 위험이 낮습니다. Go에서는 jwt-go 라이브러리로 토큰을 생성하며, Access Token은 HTTP 헤더로 전달하고 Refresh Token은 HttpOnly 쿠키에 저장하여 XSS 공격을 방지합니다. Refresh Token은 데이터베이스나 Redis에도 저장하여 강제 로그아웃 시 무효화할 수 있도록 하고, 토큰 재발급 시 Refresh Token도 함께 갱신하는 Rotation 정책을 적용합니다.
- • Access Token은 짧은 만료시간, Refresh Token은 긴 만료시간
- • Access Token 탈취 시 피해 기간 최소화
- • Refresh Token은 HttpOnly 쿠키에 저장하여 XSS 방지
- • Refresh Token을 DB/Redis에 저장하여 무효화 가능
- • 토큰 재발급 시 Refresh Token도 갱신(Rotation)
사용자가 여러 디바이스에서 동시에 로그인할 수 있도록 하면서도 각 디바이스별로 로그아웃을 관리하려면 어떻게 설계해야 할까요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!