Go 신입 프레임워크 기술면접
새 면접Q. Go 표준 라이브러리의 net/http 패키지를 사용해서 간단한 HTTP 서버를 만들 때, http.HandleFunc와 http.ListenAndServe 함수의 역할을 각각 설명해주세요.
하나는 라우팅 설정, 다른 하나는 서버 시작과 관련이 있습니다.
http.HandleFunc는 특정 URL 경로와 해당 경로로 요청이 들어왔을 때 실행될 핸들러 함수를 연결하는 라우팅 설정 함수입니다. http.ListenAndServe는 지정된 포트에서 HTTP 서버를 실제로 시작하고 들어오는 요청을 대기하는 함수입니다. ListenAndServe는 블로킹 함수로, 서버가 종료되거나 에러가 발생하기 전까지 반환되지 않습니다. 일반적으로 HandleFunc로 여러 경로를 등록한 후 마지막에 ListenAndServe를 호출하여 서버를 시작합니다.
- • http.HandleFunc는 URL 경로와 핸들러 함수를 매핑
- • http.ListenAndServe는 서버를 시작하고 요청 대기
- • ListenAndServe는 블로킹 함수
모든 Go 웹 서버의 기본이 되는 표준 라이브러리 사용법으로 실무에서 가장 먼저 배우게 됩니다.
http.Handler 인터페이스와 http.HandlerFunc의 차이는 무엇인가요?
Q. Go 웹 프레임워크에서 미들웨어(Middleware)의 개념과 역할을 설명하고, 어떤 기능들을 미들웨어로 구현하면 좋은지 예시를 들어주세요.
요청이 핸들러에 도달하기 전후에 공통으로 실행되는 로직을 생각해보세요.
미들웨어는 HTTP 요청이 최종 핸들러에 도달하기 전이나 응답이 클라이언트에게 전송되기 전에 실행되는 중간 처리 계층입니다. 요청-응답 사이클에서 공통적으로 필요한 로직을 재사용 가능하게 분리할 수 있습니다. 로깅, 인증/인가 체크, CORS 헤더 설정, 요청 시간 측정, 에러 복구(panic recovery), 요청 본문 파싱 등을 미들웨어로 구현하면 좋습니다. 미들웨어는 체인 형태로 연결되어 순차적으로 실행되며, 각 미들웨어는 다음 핸들러를 호출할지 결정할 수 있습니다.
- • 요청-응답 사이클의 중간 처리 계층
- • 공통 로직의 재사용과 분리
- • 로깅, 인증, CORS 등을 미들웨어로 구현
- • 체인 형태로 순차 실행
Gin, Echo 같은 프레임워크에서 인증 체크나 로깅을 모든 라우트에 일괄 적용할 때 사용합니다.
미들웨어의 실행 순서가 중요한 경우는 어떤 것들이 있나요?
Q. Go 웹 프레임워크에서 경로 파라미터(Path Parameter)와 쿼리 파라미터(Query Parameter)의 차이를 설명하고, 각각 어떤 상황에서 사용하는지 말씀해주세요.
URL의 어느 부분에 위치하는지, 필수인지 선택인지를 생각해보세요.
경로 파라미터는 URL 경로의 일부로 포함되는 변수로, /users/123에서 123처럼 리소스를 식별하는 필수 값에 주로 사용됩니다. 쿼리 파라미터는 URL 뒤에 ?key=value 형태로 붙는 선택적 파라미터로, /users?page=2&sort=name처럼 필터링, 정렬, 페이징 같은 옵션 전달에 사용됩니다. 경로 파라미터는 RESTful API에서 특정 리소스를 가리킬 때 사용하고, 쿼리 파라미터는 리소스 조회 시 부가 옵션을 전달할 때 사용합니다. Gin 프레임워크에서는 c.Param()과 c.Query()로 각각 추출할 수 있습니다.
- • 경로 파라미터는 URL 경로의 일부로 리소스 식별
- • 쿼리 파라미터는 ?key=value 형태로 옵션 전달
- • 경로는 필수, 쿼리는 선택적
- • RESTful API 설계의 기본 원칙
사용자 상세 조회 API에서 /users/123은 경로 파라미터, 사용자 목록 조회에서 /users?page=1은 쿼리 파라미터로 구현합니다.
경로 파라미터를 사용할 때 /users/:id와 /users/:id/posts/:postId처럼 중첩된 리소스는 어떻게 설계하나요?
Q. Go의 context.Context가 무엇이며, HTTP 서버에서 어떤 용도로 사용되는지 설명해주세요.
요청의 생명주기와 취소, 타임아웃 처리를 생각해보세요.
context.Context는 Go에서 작업의 취소 신호, 타임아웃, 데드라인, 요청 범위 값을 전달하기 위한 표준 인터페이스입니다. HTTP 서버에서는 각 요청마다 context가 생성되어 요청 처리 전체 과정에 전달됩니다. 클라이언트가 연결을 끊거나 타임아웃이 발생하면 context가 취소되어, 불필요한 작업을 중단하고 리소스를 절약할 수 있습니다. 데이터베이스 쿼리나 외부 API 호출 시 context를 전달하면 요청이 취소되었을 때 즉시 작업을 중단할 수 있습니다. http.Request.Context()로 요청의 context를 얻을 수 있습니다.
- • 작업 취소, 타임아웃, 데드라인 관리
- • HTTP 요청마다 context 생성
- • 클라이언트 연결 종료 시 자동 취소
- • DB 쿼리 등에 전달하여 리소스 절약
외부 API를 호출할 때 context에 타임아웃을 설정하여 응답이 느린 경우 자동으로 중단합니다.
context.WithTimeout과 context.WithCancel의 차이는 무엇인가요?
Q. Go에서 구조체를 JSON으로 변환하거나 JSON을 구조체로 파싱할 때 사용하는 표준 라이브러리 함수들을 말하고, 구조체 필드의 태그(tag)는 어떤 역할을 하는지 설명해주세요.
encoding/json 패키지의 Marshal과 Unmarshal 함수를 생각해보세요.
구조체를 JSON으로 변환할 때는 json.Marshal 함수를, JSON을 구조체로 파싱할 때는 json.Unmarshal 함수를 사용합니다. 구조체 필드에 백틱으로 작성하는 태그는 JSON 키 이름, 생략 조건, 타입 변환 등을 지정합니다. 예를 들어 `json:name,omitempty`는 JSON 키를 name으로 매핑하고 값이 비어있으면 생략합니다. 태그를 사용하면 Go의 네이밍 컨벤션(대문자 시작)과 JSON의 네이밍 컨벤션(camelCase, snake_case)을 맞춰줄 수 있습니다.
- • json.Marshal로 구조체를 JSON으로 변환
- • json.Unmarshal로 JSON을 구조체로 파싱
- • 구조체 태그로 JSON 키 이름과 옵션 지정
- • omitempty로 빈 값 생략 가능
API 응답을 구조체로 정의하고 JSON으로 변환하여 클라이언트에게 전송할 때 매번 사용합니다.
구조체 필드가 소문자로 시작하면 JSON 변환 시 어떻게 되나요?
Q. Go 웹 서버에서 HTTP 핸들러 함수 내부에서 발생한 에러를 클라이언트에게 어떻게 응답해야 하는지, 적절한 HTTP 상태 코드와 함께 설명해주세요.
에러의 종류에 따라 4xx, 5xx 상태 코드를 구분해서 사용합니다.
클라이언트의 잘못된 요청으로 인한 에러는 400번대 상태 코드를 사용합니다. 예를 들어 필수 파라미터 누락은 400 Bad Request, 인증 실패는 401 Unauthorized, 권한 부족은 403 Forbidden, 리소스 없음은 404 Not Found를 반환합니다. 서버 내부 에러는 500번대 상태 코드를 사용하며, 일반적인 서버 에러는 500 Internal Server Error를 반환합니다. http.Error 함수나 ResponseWriter.WriteHeader로 상태 코드를 설정하고, JSON 형태로 에러 메시지를 포함한 응답 본문을 작성하는 것이 좋습니다. 민감한 에러 정보는 로그에만 남기고 클라이언트에는 일반적인 메시지만 전달해야 합니다.
- • 클라이언트 에러는 400번대 상태 코드
- • 서버 에러는 500번대 상태 코드
- • http.Error 또는 WriteHeader로 상태 코드 설정
- • 민감한 에러 정보는 클라이언트에 노출하지 않음
API에서 사용자가 존재하지 않는 리소스를 요청하면 404를, 서버 DB 연결 실패 시 500을 반환합니다.
panic이 발생했을 때 서버가 종료되지 않도록 하려면 어떻게 해야 하나요?
Q. Go에서 database/sql 패키지를 사용할 때 sql.Open과 sql.DB의 역할을 설명하고, 커넥션 풀(Connection Pool)이 왜 중요한지 말씀해주세요.
sql.DB는 단일 연결이 아니라 연결들을 관리하는 객체입니다.
sql.Open은 데이터베이스 연결 정보를 받아 sql.DB 객체를 생성하는 함수이지만, 실제로는 즉시 연결을 시도하지 않습니다. sql.DB는 데이터베이스 커넥션 풀을 관리하는 객체로, 여러 고루틴이 동시에 안전하게 사용할 수 있습니다. 커넥션 풀은 데이터베이스 연결을 재사용하여 매번 새 연결을 생성하는 오버헤드를 줄이고 성능을 향상시킵니다. sql.DB는 전역 변수나 싱글톤으로 선언하여 애플리케이션 전체에서 공유하는 것이 권장됩니다. SetMaxOpenConns와 SetMaxIdleConns로 풀 크기를 조정할 수 있습니다.
- • sql.Open은 DB 객체 생성, 즉시 연결하지 않음
- • sql.DB는 커넥션 풀 관리 객체
- • 커넥션 풀로 연결 재사용하여 성능 향상
- • 전역으로 공유하여 사용
웹 서버 시작 시 DB 연결을 초기화하고 모든 핸들러에서 같은 sql.DB 인스턴스를 공유합니다.
sql.DB를 사용 후 Close 해야 하나요? 언제 Close를 호출해야 하나요?
Q. Go의 html/template 패키지가 text/template과 어떻게 다른지 설명하고, 왜 HTML 렌더링 시 html/template을 사용해야 하는지 말씀해주세요.
보안과 자동 이스케이핑을 생각해보세요.
html/template은 text/template의 기능을 포함하면서 HTML 출력 시 보안을 강화한 패키지입니다. 가장 큰 차이는 html/template이 사용자 입력 같은 동적 데이터를 자동으로 이스케이핑하여 XSS 공격을 방지한다는 점입니다. text/template은 단순 텍스트 처리용으로 이스케이핑을 하지 않아 HTML에 사용하면 보안 취약점이 발생할 수 있습니다. html/template은 컨텍스트를 인식하여 HTML, JavaScript, CSS, URL 등 위치에 따라 적절한 이스케이핑을 적용합니다. 웹 페이지 렌더링 시에는 반드시 html/template을 사용해야 합니다.
- • html/template은 자동 이스케이핑으로 XSS 방지
- • text/template은 이스케이핑 없는 단순 텍스트용
- • 컨텍스트 인식 이스케이핑 제공
- • 웹 페이지 렌더링에 필수
서버 사이드 렌더링으로 사용자 이름이나 게시글 내용을 HTML에 삽입할 때 안전하게 처리합니다.
템플릿에서 의도적으로 HTML을 그대로 출력하고 싶을 때는 어떻게 하나요?
Q. Go 웹 서버에서 multipart/form-data 형식의 파일 업로드를 처리할 때 사용하는 메서드와 주의해야 할 보안 사항을 설명해주세요.
http.Request의 FormFile 메서드와 파일 크기, 확장자 검증을 생각해보세요.
http.Request의 FormFile 메서드를 사용하여 업로드된 파일을 받을 수 있으며, multipart.File과 multipart.FileHeader를 반환합니다. ParseMultipartForm을 먼저 호출하여 메모리에 저장할 최대 크기를 지정할 수 있습니다. 보안상 업로드 파일의 크기 제한, 허용된 파일 확장자 검증, MIME 타입 확인이 필수입니다. 파일명은 사용자 입력을 그대로 사용하지 말고 UUID 같은 안전한 이름으로 변경해야 합니다. 업로드된 파일은 웹 루트 외부의 안전한 경로에 저장하고, 실행 권한을 제거해야 합니다.
- • FormFile 메서드로 파일 수신
- • ParseMultipartForm으로 메모리 크기 제한
- • 파일 크기, 확장자, MIME 타입 검증 필수
- • 파일명 변경과 안전한 경로 저장
사용자 프로필 이미지 업로드 기능에서 파일을 받아 검증 후 서버에 저장합니다.
대용량 파일 업로드 시 메모리 사용을 줄이려면 어떻게 해야 하나요?
Q. Go 웹 애플리케이션에서 의존성 주입(Dependency Injection)이 무엇이며, 핸들러 함수에서 데이터베이스 연결이나 설정값을 어떻게 전달하는 것이 좋은지 설명해주세요.
전역 변수 대신 구조체와 메서드를 활용하는 방법을 생각해보세요.
의존성 주입은 함수나 구조체가 필요로 하는 의존성을 외부에서 전달받는 설계 패턴으로, 코드의 테스트 가능성과 유연성을 높입니다. Go에서는 핸들러들이 필요로 하는 DB, 설정, 로거 등을 포함하는 구조체를 만들고, 이 구조체의 메서드로 핸들러를 정의하는 방식이 일반적입니다. 예를 들어 App 구조체에 DB 필드를 포함시키고, func (app *App) HandleUser(w http.ResponseWriter, r *http.Request) 형태로 핸들러를 작성합니다. 이렇게 하면 전역 변수 사용을 피하고, 테스트 시 목(mock) 객체로 대체하기 쉬워집니다. 클로저를 사용하여 의존성을 캡처하는 방법도 있습니다.
- • 의존성을 외부에서 주입받는 설계 패턴
- • 구조체 메서드로 핸들러 정의
- • 전역 변수 사용 회피
- • 테스트 용이성 향상
여러 핸들러에서 같은 DB 연결과 Redis 클라이언트를 사용할 때 구조체로 묶어서 관리합니다.
클로저를 사용한 의존성 주입과 구조체 메서드 방식의 장단점은 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!