Go 시니어 시스템 설계 면접

미들웨어 체인 패턴으로 각 기능을 독립적인 레이어로 분리하고, net/http의 ReverseProxy를 커스터마이징하여 라우팅을 구현합니다. 인증은 JWT 검증을 goroutine pool에서 병렬 처리하고, rate limiting은 로컬 메모리 기반 token bucket과 Redis 기반 분산 limiter를 조합하여 Redis 장애 시에도 동작하도록 합니다. Circuit breaker는 각 백엔드 서비스별로 독립적인 상태 머신을 유지하며, half-open 상태에서 health check를 수행합니다. Request transformation은 sync.Pool로 버퍼를 재사용하여 GC 압력을 줄이고, response caching은 TTL 기반 in-memory cache를 적용합니다. 백엔드 서비스별로 별도의 connection pool을 유지하며, timeout과 deadline을 계층별로 설정하여 cascading failure를 방지합니다. 모니터링을 위해 각 미들웨어에서 메트릭을 수집하고 distributed tracing으로 요청 흐름을 추적합니다.

이벤트 저장소로 PostgreSQL의 append-only 테이블을 사용하며, aggregate_id와 version으로 파티셔닝하여 특정 aggregate의 이벤트를 빠르게 조회합니다. 이벤트는 JSON 형태로 직렬화하되, event_type과 schema_version을 함께 저장하여 버전 관리를 수행하고, 이전 버전 이벤트는 upcasting으로 변환합니다. 스냅샷은 이벤트 100개마다 생성하며, 별도 테이블에 저장하여 재구성 시 최근 스냅샷부터 이후 이벤트만 replay합니다. CQRS 패턴으로 write model과 read model을 분리하고, 이벤트 발행 시 Kafka로 전송하여 read model을 비동기로 업데이트합니다. Temporal query는 특정 timestamp 이전 이벤트만 필터링하여 재구성하며, 자주 조회되는 시점은 별도 스냅샷으로 캐싱합니다. 이벤트 replay 시 goroutine pool로 여러 aggregate를 병렬 처리하고, 메모리 사용량 제어를 위해 배치 단위로 처리합니다.

Elasticsearch에 상품 인덱스를 생성하며, 샤딩은 상품 ID 기반으로 하고 replica를 3개 유지하여 읽기 성능을 확보합니다. 검색 쿼리는 multi_match로 상품명/설명을 검색하고, bool query로 필터를 조합하며, function_score로 인기도/재고 상태를 반영한 랭킹을 적용합니다. 자주 사용되는 검색 조합(키워드+필터)은 Redis에 캐싱하되, TTL을 짧게(1-5분) 설정하여 실시간성을 유지합니다. 페이징은 search_after를 사용하여 deep pagination 성능 문제를 해결하고, 첫 페이지는 더 공격적으로 캐싱합니다. 상품 업데이트는 Kafka로 이벤트를 받아 Go consumer가 bulk API로 배치 인덱싱하며, partial update로 변경된 필드만 갱신합니다. 검색 성능 모니터링을 위해 slow query log를 분석하고, 자주 사용되는 필터 조합은 aggregation으로 미리 계산합니다. Auto-completion은 completion suggester를 사용하고, 오타 교정은 fuzzy query로 처리합니다.

데이터를 ID 범위 기반으로 청크(예: 10만 건)로 분할하고, 각 청크를 독립적인 작업 단위로 처리합니다. Worker pool은 GOMAXPROCS의 2배 크기로 생성하며, buffered channel로 작업 큐를 구현하고, semaphore 패턴으로 동시 실행 수를 제어합니다. 각 청크 처리 전후로 상태를 DB에 기록(pending, processing, completed, failed)하여 체크포인팅하고, 재시작 시 미완료 청크만 재처리합니다. Extract 단계는 DB cursor를 사용하여 메모리 효율적으로 읽고, Transform 단계는 CPU-bound이므로 goroutine으로 병렬화하며, Load 단계는 bulk insert로 배치 처리합니다. 에러는 재시도 가능한 에러(네트워크 등)와 불가능한 에러(데이터 오류)를 구분하여, 전자는 exponential backoff로 재시도하고 후자는 dead letter queue에 저장합니다. 처리 진행률은 Redis에 실시간으로 업데이트하고, Prometheus 메트릭으로 처리 속도와 에러율을 모니터링합니다. 성능 최적화를 위해 DB connection pool을 충분히 확보하고, 네트워크 I/O는 비동기로 처리하며, 메모리 사용량은 pprof로 프로파일링합니다.

하이브리드 격리 전략을 적용하여, 대형 고객(월 매출 상위 5%)은 전용 DB 인스턴스를, 중형 고객은 schema per tenant를, 소형 고객은 row-level 격리(tenant_id 컬럼)를 사용합니다. 요청 시 JWT 또는 API key에서 tenant_id를 추출하고, 미들웨어에서 context.Context에 테넌트 정보를 주입하여 모든 하위 레이어로 전파합니다. 데이터 접근 레이어는 tenant_id를 자동으로 모든 쿼리에 추가하는 wrapper를 제공하며, 잘못된 테넌트 데이터 접근을 방지합니다. 테넌트별 설정(feature flag, rate limit, 스토리지 quota)은 Redis에 캐싱하고, 변경 시 pub/sub으로 모든 인스턴스에 전파합니다. 리소스 할당은 테넌트별 goroutine pool과 connection pool을 분리하여 noisy neighbor 문제를 방지하고, cgroup으로 CPU/메모리 제한을 설정합니다. 테넌트 마이그레이션(소형→중형, 중형→대형)은 blue-green 방식으로 수행하며, 마이그레이션 중에도 서비스 중단 없이 처리합니다. 모니터링은 테넌트별 메트릭을 수집하고, 이상 패턴 감지 시 자동으로 리소스를 조정합니다.

gqlgen 라이브러리로 schema-first 방식으로 GraphQL 서버를 구현하고, resolver에서 DataLoader 패턴을 적용하여 N+1 문제를 해결합니다. DataLoader는 요청 단위로 생성되며, 동일 엔티티의 여러 요청을 배치로 모아 한 번의 DB 쿼리로 처리합니다. 각 resolver는 context에서 DataLoader를 가져와 사용하고, 10ms의 배치 윈도우 내에서 요청을 수집합니다. 쿼리 복잡도는 각 필드에 가중치를 부여하고, 중첩 깊이와 배열 크기를 곱하여 계산하며, 임계값 초과 시 요청을 거부합니다. 깊은 중첩 쿼리는 최대 depth를 5로 제한하고, pagination을 강제하여 대량 데이터 조회를 방지합니다. 자주 사용되는 쿼리 패턴은 Redis에 캐싱하되, 쿼리 변수를 키에 포함하여 정확한 캐시 히트를 보장합니다. REST 대비 장점은 클라이언트가 필요한 데이터만 요청하여 over-fetching을 방지하지만, 캐싱이 어렵고 쿼리 복잡도 관리가 필요한 트레이드오프가 있습니다. 실무에서는 public API보다는 internal API나 BFF(Backend for Frontend) 패턴에 적합합니다.

세션 저장소로 Redis Cluster를 사용하며, 각 리전에 replica를 배치하고 비동기 복제로 크로스 리전 동기화를 수행합니다. 세션 ID는 crypto/rand로 생성한 32바이트 무작위 값을 base64 인코딩하여 사용하고, httponly와 secure 플래그가 설정된 쿠키로 전송합니다. 세션 데이터는 민감 정보(비밀번호 등)를 제외하고 저장하며, 필요 시 AES로 암호화합니다. 세션 만료는 Redis TTL로 관리하고, sliding window 방식으로 활동 시마다 TTL을 갱신하여 사용자 경험을 개선합니다. 로그아웃 시 해당 세션을 즉시 삭제하고, 블랙리스트를 별도로 관리하여 탈취된 세션 ID의 재사용을 방지합니다. CSRF 방지를 위해 각 세션에 CSRF 토큰을 포함하고, SameSite 쿠키 속성을 설정합니다. 대안으로 JWT 기반 stateless 세션도 고려할 수 있으나, 즉시 무효화가 어려운 단점이 있어 민감한 작업에는 서버 세션이 적합합니다. 세션 접근 패턴을 모니터링하여 이상 징후(동시 다중 지역 접근)를 감지하고 자동으로 세션을 무효화합니다.

데이터 수집은 Kafka를 통해 수행하며, Go consumer가 배치로 읽어 TimescaleDB에 저장합니다. TimescaleDB는 시간 기반 자동 파티셔닝(hypertable)과 압축을 지원하여 선택했습니다. 원본 데이터는 1분 단위로 파티션을 생성하고, 7일 후 압축하여 스토리지를 절감합니다. 실시간 집계는 Go 애플리케이션 메모리에서 1분/5분/1시간 단위로 수행하고, continuous aggregates로 DB에도 저장합니다. 다운샘플링은 시간이 지날수록 해상도를 낮추어(1초→1분→1시간→1일) 저장 공간을 최적화하며, retention policy로 오래된 고해상도 데이터는 자동 삭제합니다. 이상 탐지는 sliding window 기반 통계(평균, 표준편차)를 실시간 계산하고, z-score가 임계값을 초과하면 알림을 발송합니다. 실시간 쿼리는 최근 데이터만 조회하므로 인덱스를 활용하여 빠르게 처리하고, 장기 트렌드 분석은 다운샘플링된 데이터를 사용합니다. 대량 쓰기 성능을 위해 batch insert를 사용하고, connection pool을 충분히 확보하며, WAL 설정을 최적화합니다. 장기 보관이 필요한 데이터는 S3로 아카이빙하고, Parquet 포맷으로 변환하여 저장합니다.

Blue(현재 버전)와 Green(새 버전) 환경을 독립적으로 구성하고, 로드 밸런서(ALB, Nginx)로 트래픽을 제어합니다. Green 환경 배포 후 헬스 체크 엔드포인트(/health, /ready)로 서비스 준비 상태를 확인하고, smoke test로 핵심 기능을 검증합니다. 검증 완료 후 로드 밸런서 설정을 변경하여 트래픽을 Blue→Green으로 전환하며, 전환은 즉시 이루어지므로 일부 요청만 새 버전으로 보내는 Canary 배포보다 단순합니다. 롤백은 로드 밸런서 설정을 되돌려 Blue로 트래픽을 재전환하면 되므로 빠르게 수행됩니다. DB 마이그레이션은 backward compatible하게 수행하여 Blue, Green 모두 동작하도록 하며, 컬럼 추가는 nullable로 하고 삭제는 다음 배포에서 수행합니다. 배포 자동화는 CI/CD 파이프라인에서 Green 환경 빌드→배포→헬스 체크→트래픽 전환→Blue 환경 종료 순서로 진행합니다. Canary 배포 대비 장점은 구현이 단순하고 롤백이 빠르지만, 단점은 인프라 비용이 2배이고 문제 발생 시 전체 사용자에게 영향을 준다는 점입니다. 실무에서는 안정성이 검증된 서비스는 Blue-Green, 새로운 기능은 Canary를 사용합니다.

PostgreSQL의 PostGIS 확장을 사용하여 지리공간 데이터를 저장하고, GIST 인덱스로 공간 쿼리를 최적화합니다. 매장 위치는 GEOGRAPHY 타입으로 저장하여 지구 곡률을 반영한 정확한 거리 계산을 수행합니다. 검색 쿼리는 먼저 ST_DWithin 함수로 반경 내 매장을 필터링하고, ST_Distance로 정확한 거리를 계산하여 정렬합니다. Bounding box 기반 초기 필터링으로 계산량을 줄이고, 인덱스 스캔을 활용합니다. 자주 검색되는 지역(핫스팟)은 Redis Geospatial 자료구조로 캐싱하며, GEORADIUS 명령으로 빠르게 조회합니다. 캐시 무효화는 매장 정보 변경 시 해당 매장 주변 캐시를 삭제하는 방식으로 처리합니다. API는 위도, 경도, 반경을 파라미터로 받고, 페이징을 지원하며, 응답에는 매장 정보와 거리를 포함합니다. 거리 계산은 Haversine 공식보다 정확한 Vincenty 공식을 사용하되, 성능이 중요한 경우 근사값으로 Haversine을 사용합니다. 대용량 데이터 처리를 위해 매장을 지역별로 파티셔닝하고, 검색 시 관련 파티션만 조회하여 성능을 개선합니다.