Go 언어의 메서드(Method)는 단순히 “구조체에 속한 함수”를 넘어, 타입 시스템과 인터페이스를 연결하는 핵심 메커니즘입니다. 앞서 구조체 글에서 메서드의 기본 정의와 리시버를 다뤘다면, 이번 글에서는 메서드 집합(Method Set), 메서드 표현식(Method Expression), 그리고 인터페이스 만족(Interface Satisfaction) 규칙 등 실무에서 반드시 이해해야 할 고급 개념을 심층적으로 다룹니다.

이 글에서는 “왜 포인터 리시버 메서드는 값 타입에서 호출할 수 있는데, 인터페이스에서는 안 되는가?”와 같은 미묘하지만 중요한 Go 언어의 규칙들을 명확히 이해하게 될 것입니다.

🛠️ 실무에서 메서드의 중요성

필자가 대규모 API 서버를 설계할 때, 메서드는 비즈니스 로직을 캡슐화하는 주요 수단입니다. 특히 인터페이스와 함께 사용하면 의존성 역전(Dependency Inversion)과 테스트 가능성(Testability)을 크게 향상시킬 수 있습니다. 하지만 메서드 집합 규칙을 제대로 이해하지 못하면 “왜 컴파일이 안 되지?”라는 상황에 자주 빠지게 됩니다.

---

1. 메서드 기본 복습: 리시버가 있는 함수

메서드는 리시버(Receiver)를 가진 함수입니다. 리시버는 함수 이름 앞에 위치하며, 해당 메서드가 어떤 타입에 속하는지를 명시합니다.

type Rectangle struct {
    Width, Height float64
}

// 값 리시버
func (r Rectangle) Area() float64 {
    return r.Width * r.Height
}

// 포인터 리시버
func (r *Rectangle) Scale(factor float64) {
    r.Width *= factor
    r.Height *= factor
}

핵심 차이점:

• 값 리시버 (r Rectangle): 구조체 복사본을 받음, 원본 수정 불가
• 포인터 리시버 (r *Rectangle): 구조체 포인터를 받음, 원본 수정 가능

---

2. 메서드 집합(Method Set): 타입이 가진 메서드의 집합

Go 언어에서 메서드 집합은 특정 타입이 “가지고 있는” 메서드들의 집합을 의미합니다. 이는 인터페이스 만족 여부를 결정하는 핵심 규칙입니다.

2-1. 메서드 집합 규칙

타입	메서드 집합
T	값 리시버 메서드만 포함
*T	값 리시버 + 포인터 리시버 메서드 모두 포함

type Counter struct {
    count int
}

// 값 리시버
func (c Counter) Get() int {
    return c.count
}

// 포인터 리시버
func (c *Counter) Increment() {
    c.count++
}

위 코드에서:

• Counter 타입의 메서드 집합: Get()만 포함
• *Counter 타입의 메서드 집합: Get() + Increment() 모두 포함

2-2. 호출 vs 인터페이스 만족은 다르다

중요한 함정: Go 컴파일러는 메서드 호출 시 자동으로 역참조/참조를 해주지만, 인터페이스 만족 여부 판단 시에는 메서드 집합 규칙을 엄격하게 적용합니다.

func main() {
    var c Counter
    c.Increment() // ✅ 컴파일 성공: 컴파일러가 (&c).Increment()로 변환
}

type Incrementer interface {
    Increment()
}

func main() {
    var c Counter
    var i Incrementer = c // ❌ 컴파일 에러!
    // Counter는 Increment()를 메서드 집합에 가지지 않음

    var i Incrementer = &c // ✅ 정상: *Counter는 Increment()를 가짐
}

🛠️ 실무 Best Practice

인터페이스를 만족해야 하는 타입은 모든 메서드를 포인터 리시버로 통일하는 것이 일반적입니다. 이렇게 하면 값 타입과 포인터 타입 간의 혼란을 줄일 수 있습니다.

---

3. 메서드 표현식(Method Expression): 메서드를 함수로 변환

메서드를 타입을 통해 참조하면, 리시버를 첫 번째 매개변수로 받는 일반 함수로 변환됩니다.

type Rectangle struct {
    Width, Height float64
}

func (r Rectangle) Area() float64 {
    return r.Width * r.Height
}

func main() {
    // 메서드 표현식
    areaFunc := Rectangle.Area

    rect := Rectangle{Width: 10, Height: 5}
    area := areaFunc(rect) // 리시버를 명시적으로 전달

    fmt.Println(area) // 출력: 50
}

Rectangle.Area는 func(Rectangle) float64 타입의 함수입니다.

3-1. 포인터 리시버의 메서드 표현식

func (r *Rectangle) Scale(factor float64) {
    r.Width *= factor
    r.Height *= factor
}

func main() {
    scaleFunc := (*Rectangle).Scale
    // scaleFunc는 func(*Rectangle, float64) 타입

    rect := Rectangle{Width: 10, Height: 5}
    scaleFunc(&rect, 2)

    fmt.Println(rect) // 출력: {20 10}
}

💡 활용 사례

메서드 표현식은 고차 함수(Higher-Order Function)에서 메서드를 콜백으로 전달할 때 유용합니다.

func ApplyToAll(rectangles []Rectangle, fn func(Rectangle) float64) []float64 {
    results := make([]float64, len(rectangles))
    for i, r := range rectangles {
        results[i] = fn(r)
    }
    return results
}

areas := ApplyToAll(rects, Rectangle.Area)

---

4. 메서드 값(Method Value): 특정 인스턴스에 바인딩된 함수

메서드를 인스턴스를 통해 참조하면, 해당 인스턴스에 바인딩된 함수가 됩니다.

func main() {
    rect := Rectangle{Width: 10, Height: 5}

    // 메서드 값
    areaFunc := rect.Area
    // areaFunc는 func() float64 타입 (리시버가 이미 바인딩됨)

    area := areaFunc() // 리시버 전달 불필요
    fmt.Println(area)  // 출력: 50
}

4-1. 클로저(Closure)와의 유사성

메서드 값은 클로저처럼 동작합니다. 리시버가 캡처되어 함수 내부에 저장됩니다.

func main() {
    rect := Rectangle{Width: 10, Height: 5}

    scaleFunc := rect.Scale
    scaleFunc(2) // rect를 2배 확대

    fmt.Println(rect) // 출력: {20 10}
}

🛠️ 실무 활용: 이벤트 핸들러

웹 프레임워크에서 HTTP 핸들러를 메서드로 정의하고, 메서드 값으로 등록하는 패턴이 흔합니다.

type Server struct {
    db *sql.DB
}

func (s *Server) HandleUsers(w http.ResponseWriter, r *http.Request) {
    // s.db 사용 가능
}

func main() {
    srv := &Server{db: db}
    http.HandleFunc("/users", srv.HandleUsers) // 메서드 값
}

---

5. 임베딩과 메서드 섀도잉(Shadowing)

구조체 임베딩 시, 외부 타입이 내부 타입과 동일한 이름의 메서드를 정의하면 섀도잉(가림)이 발생합니다.

type Inner struct{}

func (i Inner) Method() string {
    return "Inner.Method"
}

type Outer struct {
    Inner
}

func (o Outer) Method() string {
    return "Outer.Method"
}

func main() {
    o := Outer{}
    fmt.Println(o.Method())        // 출력: Outer.Method (섀도잉)
    fmt.Println(o.Inner.Method())  // 출력: Inner.Method (명시적 접근)
}

5-1. 부분 오버라이드(Partial Override)

Go 언어는 진정한 상속이 아니므로, 메서드를 “오버라이드”하는 것이 아니라 이름을 가릴 뿐입니다.

type Logger struct{}

func (l Logger) Info(msg string) {
    fmt.Println("[INFO]", msg)
}

type CustomLogger struct {
    Logger
    prefix string
}

func (cl CustomLogger) Info(msg string) {
    fmt.Println(cl.prefix, msg) // Logger.Info를 가림
}

func main() {
    cl := CustomLogger{prefix: "[CUSTOM]"}
    cl.Info("test")         // 출력: [CUSTOM] test
    cl.Logger.Info("test")  // 출력: [INFO] test
}

---

6. 인터페이스 만족(Interface Satisfaction) 규칙

인터페이스는 메서드 집합의 부분 집합(Subset)입니다. 타입 T가 인터페이스 I를 만족하려면, T의 메서드 집합이 I의 모든 메서드를 포함해야 합니다.

type Reader interface {
    Read() string
}

type Writer interface {
    Write(string)
}

type File struct{}

func (f *File) Read() string  { return "data" }
func (f *File) Write(s string) { /* ... */ }

func main() {
    var f File

    // var r Reader = f  // ❌ 에러: File은 Read()를 메서드 집합에 가지지 않음
    var r Reader = &f    // ✅ 정상: *File은 Read()를 가짐

    var w Writer = &f    // ✅ 정상
}

6-1. 인터페이스 설계 Best Practice

// ❌ 나쁜 예: 너무 큰 인터페이스
type Repository interface {
    Create(data Data) error
    Read(id int) (Data, error)
    Update(data Data) error
    Delete(id int) error
    List() ([]Data, error)
    Search(query string) ([]Data, error)
}

// ✅ 좋은 예: 작고 명확한 인터페이스
type Creator interface {
    Create(data Data) error
}

type Reader interface {
    Read(id int) (Data, error)
}

type Updater interface {
    Update(data Data) error
}

Interface Segregation Principle: 인터페이스는 작고 명확하게 유지하여, 클라이언트가 필요한 메서드만 의존하도록 합니다.

---

7. nil 리시버 처리: 방어적 메서드 설계

Go 언어에서는 nil 포인터에서도 메서드를 호출할 수 있습니다. 이를 활용하면 우아한 에러 처리가 가능합니다.

type Tree struct {
    value int
    left  *Tree
    right *Tree
}

func (t *Tree) Sum() int {
    if t == nil {
        return 0 // nil 리시버 방어
    }
    return t.value + t.left.Sum() + t.right.Sum()
}

func main() {
    var tree *Tree = nil
    fmt.Println(tree.Sum()) // 출력: 0 (패닉 없음)
}

7-1. 실무 패턴: Optional 타입 구현

type Optional struct {
    value *int
}

func (o *Optional) OrElse(defaultVal int) int {
    if o == nil || o.value == nil {
        return defaultVal
    }
    return *o.value
}

func main() {
    var opt *Optional = nil
    fmt.Println(opt.OrElse(42)) // 출력: 42
}

---

8. 실무 패턴: Builder와 Fluent Interface

8-1. Builder 패턴

메서드 체이닝을 통해 객체를 단계적으로 구성합니다.

type HTTPRequest struct {
    method  string
    url     string
    headers map[string]string
    body    []byte
}

func NewRequest() *HTTPRequest {
    return &HTTPRequest{
        headers: make(map[string]string),
    }
}

func (r *HTTPRequest) Method(method string) *HTTPRequest {
    r.method = method
    return r // 포인터 리시버 반환
}

func (r *HTTPRequest) URL(url string) *HTTPRequest {
    r.url = url
    return r
}

func (r *HTTPRequest) Header(key, value string) *HTTPRequest {
    r.headers[key] = value
    return r
}

func (r *HTTPRequest) Body(body []byte) *HTTPRequest {
    r.body = body
    return r
}

func main() {
    req := NewRequest().
        Method("POST").
        URL("https://api.example.com").
        Header("Content-Type", "application/json").
        Body([]byte(`{"key":"value"}`))

    // req 사용...
}

8-2. Fluent Interface의 장점

1. 가독성: 코드가 자연어처럼 읽힘
2. 유연성: 선택적 설정이 자유로움
3. 타입 안전성: 컴파일 타임에 검증 가능

---

9. 메서드 vs 함수: 언제 무엇을 쓸까?

기준	메서드 사용	함수 사용
상태 관리	타입의 상태를 수정해야 할 때	상태 없는 순수 연산
인터페이스 구현	인터페이스를 만족해야 할 때	유틸리티 기능
네임스페이스	타입별로 논리적 그룹화가 필요할 때	전역 유틸리티
코드 조직화	타입과 강하게 결합된 로직	여러 타입에 공통으로 적용되는 로직

// ✅ 메서드가 적합: 타입의 상태 변경
func (u *User) Activate() {
    u.active = true
}

// ✅ 함수가 적합: 상태 없는 순수 연산
func Max(a, b int) int {
    if a > b {
        return a
    }
    return b
}

---

10. 성능 고려사항

10-1. 값 리시버 vs 포인터 리시버 성능

type LargeStruct struct {
    data [1000]int
}

// 값 리시버: 구조체 복사 발생 (4000 바이트)
func (l LargeStruct) ValueMethod() {
    // ...
}

// 포인터 리시버: 포인터 복사만 발생 (8 바이트)
func (l *LargeStruct) PointerMethod() {
    // ...
}

🛠️ 실무 가이드라인

• 구조체가 12바이트 이상이면 포인터 리시버 고려
• 필드를 수정해야 하면 무조건 포인터 리시버
• 일관성 유지: 한 타입의 모든 메서드는 같은 종류의 리시버 사용

10-2. 메서드 인라이닝(Inlining)

Go 컴파일러는 작은 메서드를 자동으로 인라이닝하여 함수 호출 오버헤드를 제거합니다.

// 인라이닝 가능성 높음 (단순한 연산)
func (p Point) Distance() float64 {
    return math.Sqrt(p.X*p.X + p.Y*p.Y)
}

---

마치며: 메서드는 Go의 다형성 기반

Go 언어에서 메서드는 타입과 인터페이스를 연결하는 다리입니다. 클래스와 상속이 없는 Go에서, 메서드와 인터페이스 조합만으로 강력한 다형성과 추상화를 구현할 수 있습니다.

오늘 배운 핵심을 요약하면:

1. 메서드 집합 규칙을 이해해야 인터페이스 만족 여부를 정확히 판단할 수 있다.
2. 메서드 표현식과 값을 활용하면 함수형 프로그래밍 패턴을 적용할 수 있다.
3. 임베딩 섀도잉을 이해하면 구조체 합성 시 예상치 못한 동작을 방지할 수 있다.
4. nil 리시버 방어로 더 안전하고 우아한 API를 설계할 수 있다.
5. Builder 패턴과 Fluent Interface로 가독성 높은 API를 만들 수 있다.
6. 값/포인터 리시버 선택은 성능과 일관성을 모두 고려해야 한다.

다음 글에서는 Go 언어의 인터페이스(Interface)를 심층적으로 다루며, 덕 타이핑(Duck Typing), 빈 인터페이스(Empty Interface), 그리고 타입 단언(Type Assertion)과 타입 스위치(Type Switch)를 통한 유연한 타입 처리 방법을 알아보겠습니다. Go의 인터페이스가 어떻게 Java/C#과 다른지, 그리고 왜 더 강력한지 확인해보세요!