Go에서 Dependency Injection: 웹 API에 충분히 적용하려면?

Source: Dev.to

번역을 진행하려면 실제 텍스트(본문 내용)를 제공해 주시겠어요?
본문을 주시면 원본 포맷과 코드 블록을 그대로 유지하면서 한국어로 번역해 드리겠습니다.

소개

Go에서의 의존성 주입(DI)은 대부분의 웹 API가 실제로 필요로 하는 수준보다 과도하게 논쟁을 불러일으키는 경우가 많습니다. 논의는 컨테이너, 라이프사이클, 스코프, 동적 해석 등으로 급속히 확대되지만, 많은 서비스는 시작 시 한 번만 해결되는 단순하고 정적인 의존성 그래프를 가지고 있습니다.

핵심 포인트:
일반적인 웹 API에서는 컴파일‑타임 의존성 해석만으로 충분합니다.

전형적인 Go 웹 API의 특징

• 상태 비유지 요청 처리
• 시작 시 한 번만 의존성 해결
• 대부분 트리 형태의 의존성 그래프

config → database → repository → service → handler

• 런타임 시 구현 재바인딩 없음

이 환경에서는 DI가 런타임에서의 유연성을 위한 것이 아니라, 연결의 정확성과 유지보수성을 위한 것입니다.

런타임 DI 프레임워크가 과도할 때

fx, dig, 혹은 do와 같은 제네릭 기반 컨테이너와 같은 프레임워크는 애플리케이션 자체가 프레임워크처럼 동작할 때 빛을 발합니다:

• 모듈이 동적으로 자신을 등록한다
• 라이프사이클 훅(시작/정지)이 중요하다
• 플러그인이나 선택적 컴포넌트가 런타임에 로드된다

일반적인 웹 API에서는 이러한 기능이 종종 단점을 초래합니다:

• 배우고 기억해야 할 추가 API
• 본질적으로 정적인 연결을 위한 런타임 오류 발생
• 시작 시 따라가기 어려운 제어 흐름

의존성이 고정되어 사전에 알려져 있다면, 런타임 DI는 실제로 필요하지 않은 문제를 해결하게 됩니다.

wire를 이용한 정적 DI

wire는 런타임 컨테이너 없이 컴파일 타임에 의존성 해석을 제공하며, 순수 Go 코드를 생성합니다. 이 모델은 다음과 같은 장점을 제공합니다:

• 안전성 및 예측 가능성
• 런타임 DI 오버헤드 제로

Wire의 설계

• 프로바이더 함수
• 프로바이더 세트
• 루트당 인젝터 함수

명시성이 가치 있을 수 있지만, 유지 보수 부담이 될 수도 있습니다:

• 그래프가 변함에 따라 프로바이더 세트를 지속적으로 업데이트해야 합니다
• DI 전용 파일이 비즈니스 코드와 함께 증가합니다
• 와이어링 자체가 개발자가 고민해야 할 대상이 됩니다

필드‑태그 생성기를 이용한 최소 정적 DI

정적 와이어링과 생성된 생성자를 원하지만 DI‑특화 코드를 줄이고 싶다면, 더 간단한 모델이 잘 작동합니다:

type Container struct {
    Handler *UserHandler `inject:""`
}

생성된 코드는 순수 Go 코드입니다:

func NewContainer() (*Container, error) {
    cfg := NewConfig()
    db, err := NewDatabase(cfg)
    if err != nil {
        return nil, err
    }
    svc := NewUserService(db)
    h := NewUserHandler(svc)
    return &Container{Handler: h}, nil
}

• 런타임 컨테이너 없음
• 프로바이더 세트 없음
• 리플렉션 없음

이것이 injector의 아이디어이며, 필드‑태그만을 사용하는 DI 코드 생성기입니다.

와이어가 여전히 의미가 있을 때

• Provider sets는 공개 컴포지션 API로 취급됩니다
• 명시적인 와이어링 경계는 의도적인 설계 목표입니다
• DI 그래프는 일급 아티팩트로 검토 및 관리됩니다

다시 말해, wire의 강점은 조직적이며 프로세스 중심입니다. 프로젝트가 그런 수준의 명시성을 필요로 하지 않는다면, wire를 정당화하기가 어려워집니다.

비교

결론

일반적인 경우—상태가 없는 웹 API와 안정적인 의존성 그래프—에서는 정적 와이어링만으로 충분합니다. 유지해야 하는 DI‑전용 코드를 줄이면 더 좋은 결과를 얻을 수 있습니다.

Dependency Injection은 대부분의 Go 웹 API에서 프레임워크 수준의 결정이 될 필요가 없습니다. 이는 시작 단계의 상세 사항에 불과합니다:

1. 의존성을 한 번만 해결합니다.
2. 순수 Go 코드를 생성합니다.
3. 와이어링을 지루하게 유지합니다.

wire가 충분하지만 다소 무겁게 느껴진다면, 필드‑태그 기반 접근 방식(injector)이 자연스러운 다음 단계가 될 수 있습니다. 이런 의미에서 이것은 급진적인 대안이 아니라 단순히 다음을 묻는 것입니다:

정적 DI가 충분하다면… 왜 더 간단하게 만들지 않을까요?