문서가격블로그
문의하기
로그인무료로 가입하기
Back to Tech Articles

Go 웹 개발의 흔한 함정: 전역 상태 및 기본 HTTP 클라이언트

11월 07, 2025
# Misc

Lukas Schneider

DevOps Engineer · Leapcell

이 게시물은 English, 日本語 및 Deutsch에서도 볼 수 있습니다.
Cover of "Go 웹 개발의 흔한 함정: 전역 상태 및 기본 HTTP 클라이언트"

소개

Go는 단순성, 동시성 모델, 견고한 표준 라이브러리로 인해 성능이 뛰어나고 확장 가능한 웹 서비스를 구축하는 데 인기 있는 선택이 되었습니다. 그러나 모든 강력한 도구와 마찬가지로 Go도 오용될 수 있으며, 이는 미묘한 버그, 디버깅하기 어려운 문제 및 유지보수 악몽으로 이어질 수 있습니다. 안정성과 응답성이 가장 중요한 웹 개발에서는 일반적인 안티 패턴을 이해하고 피하는 것이 중요합니다. 이 글은 이러한 두 가지 함정에 초점을 맞춥니다. 즉, init()을 전역 상태 관리에 오용하는 것과 기본 http.Get 클라이언트에만 의존하는 고유한 위험입니다. 이러한 문제를 이해함으로써 개발자는 더 강력하고 테스트 가능하며 유지보수하기 쉬운 Go 웹 애플리케이션을 작성할 수 있습니다.

핵심 개념 설명

안티 패턴에 대해 자세히 알아보기 전에, 논의와 관련된 몇 가지 기본 Go 개념을 간략하게 복습해 보겠습니다.

  • init() 함수: Go에서 init() 함수는 패키지가 초기화될 때 자동으로 실행되는 특별한 함수입니다. 패키지에는 여러 개의 init() 함수(다른 파일에 걸쳐 있더라도)가 있을 수 있으며, 파일 이름의 사전순으로 실행됩니다. init() 함수는 주로 외부 입력에 의존하지 않는 패키지별 상태 설정, 예를 들어 데이터베이스 드라이버 등록 또는 존재가 보장되는 구성 파일 구문 분석을 위해 사용됩니다.
  • 전역 상태: 전역 상태는 프로그램 내 어디에서나 접근하고 수정할 수 있는 변수 또는 데이터 구조를 의미합니다. 때때로 피할 수 없지만, 전역 변경 가능한 상태에 과도하게 의존하면 추적하기 어려운 버그, 테스트 용이성 저하 및 동시성 안전성 감소로 이어질 수 있습니다.
  • HTTP 클라이언트: HTTP 클라이언트는 서버에 HTTP 요청을 보내고 응답을 받는 프로그래밍 방식입니다. Go의 net/http 패키지는 이 목적을 위해 강력하고 유연한 http.Client 구조체를 제공하며, 타임아웃, 리디렉션 및 전송 세부 정보를 구성할 수 있습니다.

init() 및 전역 상태의 위험

가장 일반적인 안티 패턴 중 하나는 init() 함수를 사용하여 복잡한 전역 상태를 초기화하는 것입니다. 특히 해당 상태가 외부 리소스에 의존하거나 다양한 환경에서 다르게 구성될 수 있는 경우 더욱 그렇습니다.

데이터베이스 연결이 init() 함수 내에서 전역적으로 초기화되는 다음 예제를 고려해 보세요.

// bad_db_client.go
packagel database

import (
	"database/sql"
	_ "github.com/go-sql-driver/mysql" // Database driver
	"log"
	"os"
	time
)

var DB *sql.DB

func init() {
	connStr := os.Getenv("DATABASE_URL")
	if connStr == "" {
		log.Fatal("DATABASE_URL environment variable is not set")
	}

	var err error
	DB, err = sql.Open("mysql", connStr)
	if err != nil {
		log.Fatalf("failed to open database connection: %v", err)
	}

	DB.SetMaxOpenConns(10)
	DB.SetMaxIdleConns(5)
	DB.SetConnMaxLifetime(5 * time.Minute)

	if err = DB.Ping(); err != nil {
		log.Fatalf("failed to connect to database: %v", err)
	}
	log.Println("Database connection successfully initialized!")
}

// In your web handler:
// func getUserHandler(w http.ResponseWriter, r *http.Request) {
//     rows, err := database.DB.Query("SELECT * FROM users")
//     // ...
// }

이것이 안티 패턴인 이유:

  1. 테스트 불가 코드: init() 함수는 모든 테스트 코드가 실행되기 전에 실행됩니다. 이로 인해 database.DB에 의존하는 핸들러나 함수를 격리하여 테스트하는 것이 극도로 어려워집니다. 환경 변수를 조작하지 않고는 데이터베이스 연결을 쉽게 모의하거나 다른 데이터베이스 구성을 테스트할 수 없으며, 이는 번거롭고 오류가 발생하기 쉽습니다.
  2. 유연성 부족: 데이터베이스 구성은 환경 변수에 하드 코딩되어 패키지 초기화에 직접 연결됩니다. 여러 데이터베이스 연결이 필요하거나 스테이징 대 프로덕션에 대한 다른 구성이 필요한 경우는 어떻습니까?
  3. 오류 처리 및 시작 실패: init()이 실패하면(예: 데이터베이스 다운, 환경 변수 누락), 전체 프로그램이 log.Fatal을 호출하고 종료됩니다. 이것이 중요한 종속성에 대해 허용될 수 있다고 생각될 수 있지만, 종종 덜 우아한 오류 처리로 이어지고 시작 문제 진단을 더 어렵게 만듭니다.
  4. 전역 변경 가능 상태: database.DB는 전역 변경 가능 변수가 됩니다. sql.DB 객체 자체는 동시성 안전성을 위해 설계되었지만, 전역 인스턴스에 의존하는 패턴은 코드 결합도를 높이고 리소스 수명 주기 관리를 더 어렵게 만듭니다.

선호되는 접근 방식: 의존성 주입 및 명시적 초기화

대신, 명시적 초기화를 선호하고 필요한 곳에 종속성을 전달하세요.

// good_db_client.go
packagel database

import (
	"database/sql"
	_ "github.com/go-sql-driver/mysql"
	time
	"fmt"
)

// Config holds database configuration
type Config struct {
	DataSourceName string
	MaxOpenConns   int
	MaxIdleConns   int
	ConnMaxLifetime time.Duration
}

// NewDB creates and returns a new database connection
func NewDB(cfg Config) (*sql.DB, error) {
	db, err := sql.Open("mysql", cfg.DataSourceName)
	if err != nil {
		return nil, fmt.Errorf("failed to open database connection: %w", err)
	}

	db.SetMaxOpenConns(cfg.MaxOpenConns)
	db.SetMaxIdleConns(cfg.MaxIdleConns)
	db.SetConnMaxLifetime(cfg.ConnMaxLifetime)

	if err = db.Ping(); err != nil {
		db.Close() // Ensure the connection is closed on ping failure
		return nil, fmt.Errorf("failed to connect to database: %w", err)
	}
	return db, nil
}

// In main.go (or similar entry point):
// func main() {
//      // ... get configuration from environment or config file
//      dbConfig := database.Config{
//          DataSourceName: os.Getenv("DATABASE_URL"),
//          MaxOpenConns: 10,
//          MaxIdleConns: 5,
//          ConnMaxLifetime: 5 * time.Minute,
//      }
//      db, err := database.NewDB(dbConfig)
//      if err != nil {
//          log.Fatalf("failed to initialize database: %v", err)
//      }
//      defer db.Close() // Ensure closing the connection

//      router := http.NewServeMux()
//      // Pass the db instance to your handlers or repositories
//      router.HandleFunc("/users", getUserHandler(db))
//      // ...
// }

// Your handler, now receiving the dependency:
// func getUserHandler(db *sql.DB) http.HandlerFunc {
//     return func(w http.ResponseWriter, r *http.Request) {
//         rows, err := db.Query("SELECT * FROM users")
//         // ...
//     }
// }

이 접근 방식은 테스트 용이성, 더 유연한 구성 및 명시적인 오류 처리 기능을 제공합니다.

http.Get의 기본 클라이언트의 숨겨진 위험

Go의 net/http 패키지는 매우 강력하며 http.Get(url string) (*Response, error)는 편리한 바로가기입니다. 그러나 그 편리함은 장기간 실행되는 웹 서비스에서 리소스 고갈 및 성능 병목 현상을 일으킬 수 있는 중요한 기본 동작을 숨깁니다.

http.Get 함수는 http.Post, http.Head 등과 함께 http.DefaultClient를 사용합니다. 이 기본 클라이언트는 다음과 같은 특징을 가진 사전 구성된 http.Client 인스턴스입니다.

  • 요청 타임아웃 없음: 기본적으로 http.DefaultClient에는 요청에 대한 타임아웃이 설정되어 있지 않습니다. 즉, 원격 서버가 응답이 느리거나 응답이 없으면 Go 애플리케이션의 나가는 HTTP 요청이 무기한으로 중단될 수 있습니다. 웹 서버에서는 이로 인해 Goroutine과 연결이 빠르게 고갈되어 서버가 응답하지 않게 될 수 있습니다.
  • 기본 전송: http.DefaultTransport를 사용하며, 이는 견고하지만 모든 프로덕션 시나리오에 이상적인 설정(예: MaxIdleConnsPerHost가 기본값 2인데, 동시성이 높은 애플리케이션에는 낮을 수 있음)이 아닐 수 있습니다.
  • 연결 풀링 구성 없음: DefaultTransport에는 연결 풀링이 포함되어 있지만, 사용자 지정 클라이언트를 만들지 않고는 해당 매개변수를 쉽게 최적화할 수 없습니다.

외부 서비스에 http.Get을 사용하여 호출하는 웹 API를 고려해 보세요.

// bad_http_client.go
packagemain

import (
	"io/ioutil"
	"log"
	"net/http"
	time
)

func fetchExternalData(url string) (string, error) {
	resp, err := http.Get(url) // Using the default client
	if err != nil {
		return "", err
	}
	defer resp.Body.Close()

	body, err := ioutil.ReadAll(resp.Body)
	if err != nil {
		return "", err
	}
	return string(body), nil
}

// In a web handler
// func apiHandler(w http.ResponseWriter, r *http.Request) {
//      data, err := fetchExternalData("http://slow-api.example.com/data")
//      // ...
// }

slow-api.example.com에서 응답하는 데 30초가 걸리거나 전혀 응답하지 않으면 fetchExternalData에 대한 각 호출은 해당 기간 동안 차단되어 웹 서버의 Goroutine을 소비합니다. 로드 중에는 리소스 부족으로 인해 웹 서버가 빠르게 작동하지 않게 됩니다.

선호되는 접근 방식: 타임아웃 및 조정된 전송을 갖춘 사용자 지정 http.Client

나가는 HTTP 요청에는 항상 사용자 지정 http.Client를 만들고 사용하세요. 이를 통해 애플리케이션의 요구 사항에 맞게 타임아웃, 연결 풀링 및 기타 전송 설정을 구성할 수 있습니다.

// good_http_client.go
packageservices

import (
	"io/ioutil"
	"net/http"
	time
	"fmt"
)

var httpClient *http.Client // Declare a package-level client

func init() {
	// Initialize the custom client once when the package is loaded
	httpClient = &http.Client{
		Timeout: 10 * time.Second, // Timeout for the entire request
		Transport: &http.Transport{
			MaxIdleConns:        100, // Important for connection reuse
			MaxIdleConnsPerHost: 20,  // Max idle connections per host
			IdleConnTimeout:     90 * time.Second, // How long idle connections are kept alive
			// You can also add TLSClientConfig, Proxy, etc.
		},
	}
}

func FetchExternalData(url string) (string, error) {
	req, err := http.NewRequest(http.MethodGet, url, nil)
	if err != nil {
		return "", fmt.Errorf("failed to create request: %w", err)
	}

	resp, err := httpClient.Do(req) // Use the custom client
	if err != nil {
		// Differentiate between network/timeout error and other errors
		if err, ok := err.(net.Error); ok && err.Timeout() {
			return "", fmt.Errorf("request timed out: %w", err)
		}
		return "", fmt.Errorf("http request failed: %w", err)
	}
	defer resp.Body.Close()

	if resp.StatusCode != http.StatusOK {
		return "", fmt.Errorf("received non-ok status code: %d", resp.StatusCode)
	}

	body, err := ioutil.ReadAll(resp.Body)
	if err != nil {
		return "", fmt.Errorf("failed to read response body: %w", err)
	}
	return string(body), nil
}

// In your web handler:
// func apiHandler(w http.ResponseWriter, r *http.Request) {
//      data, err := services.FetchExternalData("http://api.example.com/data")
//      if err != nil {
//          http.Error(w, err.Error(), http.StatusInternalServerError)
//          return
//      }
//      // ...
// }

http.Client를 명시적으로 구성함으로써 네트워크 통신의 중요한 측면을 제어할 수 있어 리소스 고갈을 방지하고 서비스의 복원력을 높일 수 있습니다. httpClient는 전역적으로 선언되지만 init()에서 한 번만 초기화된다는 점에 유의하세요. http.Client 자체는 동시에 안전하게 공유되도록 설계되었고 초기화 후 수정되지 않으므로 init()을 사용하는 것은 허용됩니다. 이는 싱글턴 패턴(효율성을 위해 하나의 인스턴스)과 올바른 구성을 결합합니다.

결론

Go 웹 개발에서는 init()을 변경 가능한 전역 상태에 오용하거나 http.Client 구성을 소홀히 하는 일반적인 안티 패턴을 피하는 것이 강력하고 유지보수 가능한 애플리케이션을 구축하는 데 매우 중요합니다. 리소스 관리를 위한 의존성 주입을 우선시하고 외부 HTTP 요청을 명시적으로 구성하면 서비스가 테스트 가능하고 유연하며 오류에 복원력이 보장됩니다. 궁극적으로 규율 있는 리소스 관리와 명시적 구성은 더 안정적이고 확장 가능한 Go 웹 서비스로 이어집니다.

Share this article

HackerNews

More Posts from Leapcell

cover

context.Value와 선택적 인수의 미묘한 함정

cover

Go 프로젝트의 자기주장적인 구조

Popular Posts