Go 미드레벨 기술면접
새 면접Q. Go에서 database/sql 패키지를 사용할 때 Connection Pool의 주요 설정 파라미터(MaxOpenConns, MaxIdleConns, ConnMaxLifetime)의 역할을 설명하고, 각 파라미터를 적절하게 튜닝하지 않았을 때 발생할 수 있는 실무 문제와 권장 설정 전략을 제시해주세요.
각 파라미터가 연결 생성, 재사용, 폐기에 어떤 영향을 주는지 생각해보세요.
MaxOpenConns는 동시에 열 수 있는 최대 연결 수를 제한하며, 너무 높으면 데이터베이스 서버에 부하를 주고 너무 낮으면 요청이 대기하게 됩니다. MaxIdleConns는 연결 풀에 유지할 유휴 연결 수로, 너무 낮으면 매번 새 연결을 생성하는 오버헤드가 발생하고 너무 높으면 불필요한 리소스를 점유합니다. ConnMaxLifetime은 연결의 최대 수명으로, 설정하지 않으면 오래된 연결이 방화벽이나 로드밸런서 타임아웃에 걸려 끊어질 수 있습니다. 일반적으로 MaxOpenConns는 데이터베이스 최대 연결 수의 70-80%, MaxIdleConns는 평균 동시 쿼리 수, ConnMaxLifetime은 5-10분으로 설정하는 것이 권장됩니다. 모니터링을 통해 대기 시간과 연결 생성 빈도를 확인하며 조정해야 합니다.
- • MaxOpenConns는 최대 연결 수 제한
- • MaxIdleConns는 유휴 연결 풀 크기
- • ConnMaxLifetime은 연결 수명 관리
- • 부적절한 설정 시 성능 저하 또는 리소스 낭비
- • 모니터링 기반 튜닝 필요
높은 트래픽 환경에서 DB 연결 풀을 적절히 설정하지 않으면 응답 지연이나 연결 고갈 문제가 발생합니다.
DB 연결이 부족해서 요청이 대기 중인 상황을 어떻게 모니터링하고 진단할 수 있나요?
Q. 마이크로서비스 아키텍처에서 여러 Go 서비스 간 통신을 구현할 때 REST API와 gRPC의 장단점을 비교하고, 각각을 선택해야 하는 시나리오를 제시해주세요. 또한 gRPC를 사용할 때 HTTP/2의 특성이 가져오는 이점과 주의사항을 설명해주세요.
프로토콜의 성능, 타입 안정성, 스트리밍 지원, 디버깅 용이성 등을 비교해보세요.
REST API는 JSON 기반으로 가독성이 높고 디버깅이 쉬우며 브라우저와 호환성이 좋지만, 텍스트 기반 직렬화로 인해 성능이 상대적으로 낮습니다. gRPC는 Protocol Buffers를 사용해 바이너리 직렬화로 빠르고 효율적이며, 강타입 스키마로 타입 안정성이 보장되고 양방향 스트리밍을 지원합니다. 내부 서비스 간 고성능 통신이나 실시간 스트리밍이 필요한 경우 gRPC가 적합하고, 외부 API나 디버깅이 중요한 경우 REST가 유리합니다. gRPC는 HTTP/2의 멀티플렉싱으로 하나의 연결에서 여러 요청을 동시 처리하고 헤더 압축으로 오버헤드를 줄이지만, 로드밸런서나 프록시가 HTTP/2를 지원해야 하고 연결 수가 적어 부하 분산이 어려울 수 있습니다. 클라이언트 사이드 로드밸런싱이나 서비스 메시를 고려해야 합니다.
- • REST는 가독성과 호환성이 좋지만 성능이 낮음
- • gRPC는 고성능, 강타입, 스트리밍 지원
- • 내부 통신은 gRPC, 외부 API는 REST 권장
- • HTTP/2 멀티플렉싱과 헤더 압축의 이점
- • 로드밸런싱 전략 고려 필요
마이크로서비스 간 고성능 통신이 필요한 대규모 시스템에서 gRPC를 사용해 지연 시간을 줄입니다.
gRPC에서 클라이언트 사이드 로드밸런싱을 구현하는 방법은 무엇인가요?
Q. 프로덕션 환경에서 Go 애플리케이션의 메모리 사용량이 계속 증가하는 메모리 누수 현상이 발견되었습니다. pprof를 활용해 메모리 프로파일링을 수행하고 원인을 분석하는 구체적인 절차와, 실무에서 자주 발생하는 메모리 누수 패턴들을 설명해주세요.
힙 프로파일 수집, 차이 분석, 그리고 흔한 누수 원인들을 생각해보세요.
먼저 import _ "net/http/pprof"로 pprof를 활성화하고 /debug/pprof/heap 엔드포인트에서 힙 프로파일을 주기적으로 수집합니다. go tool pprof로 프로파일을 분석하고 top, list 명령으로 메모리를 많이 사용하는 함수와 할당 지점을 확인합니다. 시간 간격을 두고 수집한 두 프로파일의 차이를 분석하면 증가 추세를 파악할 수 있습니다. 흔한 메모리 누수 패턴으로는 종료되지 않는 Goroutine, 닫히지 않은 채널로 인한 Goroutine Leak, 타이머나 Ticker를 Stop하지 않은 경우, 전역 맵이나 슬라이스에 계속 데이터가 쌓이는 경우, HTTP 클라이언트의 Response Body를 Close하지 않은 경우 등이 있습니다. runtime.NumGoroutine()으로 고루틴 수를 모니터링하고, 메모리 프로파일과 함께 고루틴 프로파일도 확인해야 합니다.
- • pprof로 힙 프로파일 수집 및 분석
- • 시간 간격 프로파일 차이 분석
- • Goroutine Leak이 주요 원인
- • 타이머, 채널, HTTP Body 미처리
- • 고루틴 수 모니터링
장시간 운영되는 서비스에서 메모리 누수는 OOM Kill로 이어질 수 있어 조기 발견과 대응이 중요합니다.
Goroutine Leak을 사전에 방지하기 위한 코드 작성 패턴은 무엇인가요?
Q. Go 애플리케이션에서 CPU 바운드 작업의 성능을 최적화할 때 고려해야 할 요소들을 설명하고, runtime.GOMAXPROCS 설정이 성능에 미치는 영향과 적절한 설정 방법을 제시해주세요. 또한 CPU 프로파일링을 통해 병목 지점을 찾고 개선하는 실무 프로세스를 설명해주세요.
병렬 처리, CPU 코어 활용, 프로파일링 도구 사용을 생각해보세요.
GOMAXPROCS는 동시에 실행 가능한 OS 스레드 수를 제한하며, 기본값은 CPU 코어 수입니다. CPU 바운드 작업에서는 기본값이 적절하지만, 컨테이너 환경에서는 CPU 쿼터를 고려해 조정해야 합니다. CPU 프로파일링은 import _ "net/http/pprof" 후 /debug/pprof/profile 엔드포인트에서 30초간 프로파일을 수집하고, go tool pprof로 분석해 top, list 명령으로 CPU 사용이 높은 함수를 식별합니다. 병목 지점 개선 방법으로는 불필요한 반복문 제거, 메모리 할당 최소화, 데이터 구조 최적화, 병렬 처리 도입 등이 있습니다. sync.Pool로 객체 재사용, 슬라이스 사전 할당, strings.Builder 사용 등으로 할당을 줄이고, 작업을 여러 Goroutine으로 분산해 멀티코어를 활용합니다. 벤치마크 테스트로 최적화 효과를 검증해야 합니다.
- • GOMAXPROCS는 OS 스레드 수 제한
- • 컨테이너 환경에서 CPU 쿼터 고려
- • CPU 프로파일로 병목 지점 식별
- • 메모리 할당 최소화와 병렬 처리
- • 벤치마크로 검증
대량 데이터 처리나 이미지 변환 같은 CPU 집약적 작업에서 프로파일링 기반 최적화가 필수입니다.
컨테이너 환경에서 CPU 쿼터가 1.5 코어로 제한된 경우 GOMAXPROCS를 어떻게 설정해야 하나요?
Q. Go 웹 애플리케이션에서 JWT(JSON Web Token) 기반 인증을 구현할 때 보안상 고려해야 할 사항들을 설명하고, Access Token과 Refresh Token을 사용하는 이유와 각각의 적절한 만료 시간 설정 전략을 제시해주세요.
토큰 저장 위치, 만료 시간, 갱신 메커니즘, 서명 알고리즘을 생각해보세요.
JWT는 서명을 통해 위변조를 방지하지만 탈취되면 만료 전까지 사용 가능하므로 HTTPS 사용이 필수이고, 민감 정보를 페이로드에 넣지 않아야 합니다. HS256보다는 RS256 같은 비대칭 알고리즘을 사용해 서명 검증과 생성을 분리하는 것이 안전합니다. Access Token은 짧은 만료 시간(15분~1시간)으로 설정해 탈취 위험을 줄이고, Refresh Token은 긴 만료 시간(7일~30일)으로 설정해 사용자 편의성을 제공합니다. Refresh Token은 HttpOnly 쿠키에 저장하거나 데이터베이스에 저장해 무효화 가능하도록 하고, 갱신 시 Rotation 기법으로 새로운 Refresh Token을 발급해 재사용을 방지합니다. 로그아웃 시 Refresh Token을 블랙리스트에 추가하거나 삭제해야 합니다.
- • HTTPS 필수, 민감 정보 제외
- • 비대칭 알고리즘 권장
- • Access Token 짧게, Refresh Token 길게
- • Refresh Token Rotation
- • 로그아웃 시 무효화
모바일 앱이나 SPA에서 세션 기반 인증 대신 JWT를 사용해 상태 비저장 인증을 구현합니다.
JWT를 사용할 때 토큰 무효화가 어려운 이유와 이를 해결하는 방법은 무엇인가요?
Q. 대용량 로그 파일에서 특정 패턴의 로그를 효율적으로 검색하고 집계하는 기능을 Go로 구현한다고 할 때, 메모리 제약 하에서 어떤 알고리즘과 자료구조를 사용해야 하는지 설명하고, 시간 복잡도와 공간 복잡도 관점에서 접근 방법을 제시해주세요.
스트리밍 처리, 해시맵 사용, 병렬 처리를 고려해보세요.
대용량 파일은 전체를 메모리에 로드할 수 없으므로 bufio.Scanner나 bufio.Reader로 스트리밍 방식으로 한 줄씩 읽어 처리합니다. 패턴 매칭은 정규표현식을 컴파일해 재사용하고, 집계는 맵을 사용해 O(1) 시간에 카운팅합니다. 파일을 여러 청크로 나눠 Goroutine으로 병렬 처리하고, 각 Goroutine의 결과를 채널로 수집해 최종 집계하면 멀티코어를 활용할 수 있습니다. 공간 복잡도는 O(k)로 고유 패턴 수에 비례하며, 시간 복잡도는 O(n)으로 파일 크기에 비례합니다. 메모리 사용을 더 줄이려면 Count-Min Sketch 같은 확률적 자료구조를 사용할 수 있지만 정확도가 떨어집니다. 정렬이 필요한 경우 외부 정렬 알고리즘을 적용합니다.
- • 스트리밍 방식으로 한 줄씩 처리
- • 맵으로 O(1) 집계
- • 병렬 처리로 멀티코어 활용
- • 시간 O(n), 공간 O(k)
- • 확률적 자료구조로 메모리 절약 가능
수십 GB 크기의 웹 서버 로그를 분석해 에러율이나 트래픽 패턴을 집계하는 작업에 사용됩니다.
여러 파일을 동시에 처리할 때 Goroutine 수를 어떻게 제한해야 하나요?
Q. Go 애플리케이션을 Kubernetes 환경에서 운영할 때 Graceful Shutdown을 구현하는 방법을 설명하고, SIGTERM 신호 처리와 readiness/liveness probe 설정이 무중단 배포에 어떻게 기여하는지 설명해주세요.
신호 처리, HTTP 서버 종료, 진행 중인 요청 완료, probe 역할을 생각해보세요.
Graceful Shutdown은 os/signal 패키지로 SIGTERM 신호를 수신하고, 수신 시 HTTP 서버의 Shutdown() 메서드를 호출해 새 요청을 거부하고 진행 중인 요청이 완료될 때까지 대기합니다. context.WithTimeout으로 최대 대기 시간을 설정해 무한 대기를 방지합니다. Kubernetes는 Pod 종료 시 SIGTERM을 보내고 기본 30초 후 SIGKILL을 보내므로, 타임아웃을 25초 이하로 설정해야 합니다. Readiness probe는 애플리케이션이 트래픽을 받을 준비가 되었는지 확인하고, 실패 시 서비스에서 제외해 배포 중 트래픽이 준비되지 않은 Pod로 가는 것을 방지합니다. Liveness probe는 애플리케이션이 살아있는지 확인하고, 실패 시 재시작합니다. 종료 시작 시 readiness probe를 실패하도록 해 트래픽을 먼저 차단한 후 종료하면 무중단 배포가 가능합니다.
- • SIGTERM 신호로 Shutdown 시작
- • 진행 중 요청 완료 대기
- • 타임아웃 설정 필수
- • Readiness probe로 트래픽 제어
- • 종료 전 트래픽 차단
Rolling Update 배포 시 Graceful Shutdown이 없으면 진행 중인 요청이 끊겨 503 에러가 발생합니다.
Shutdown 대기 중에 데이터베이스 연결이나 메시지 큐 연결도 함께 정리해야 하는데, 어떤 순서로 처리해야 하나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!