6. Pointers

Alert

이 글은 Claude Code의 도움을 받아 작성되었습니다

TL;DR

• Python은 모든 변수가 참조지만 Go는 기본이 값 복사(call by value)
• &로 주소를 얻고 *로 역참조하며, 포인터 산술은 불가
• 포인터를 함수에 넘겨도 포인터 변수 자체는 복사되므로, 포인터를 재할당하면 원본에 영향 없음
• 포인터가 가리키는 값을 *px = ...로 수정해야 원본이 바뀜
• 슬라이스는 (포인터·길이·용량) 헤더가 복사되며, 공용 API 입출력엔 맵보다 구조체가 안전
• 포인터는 힙 할당(escape)을 늘려 GC 부하를 키우므로, 값 타입·버퍼 재사용으로 GC 일감을 줄임
• Go에서는 포인터 사용을 최소화하는 것이 권장됨

Python에서는 변수가 객체의 참조라는 걸 의식하지 않아도 대부분 잘 동작한다. Go는 다르다. 값이 복사되는지 참조가 전달되는지를 개발자가 직접 결정해야 한다. 이 글은 Python 개발자가 Go의 포인터를 처음 접할 때 헷갈리는 부분을 정리한다.

---

1. Python은 모든 것이 참조, Go는 기본이 값 복사

Python에서는 변수에 값을 할당하면 실제로는 객체의 참조가 저장된다. 함수에 인자를 넘기면 그 참조가 복사되므로, 원본 객체를 직접 수정할 수 있다.

# Python
def modify(lst):
    lst.append(4)
 
a = [1, 2, 3]
modify(a)
print(a)  # [1, 2, 3, 4] — 원본이 바뀜

Go는 기본적으로 값 전체를 복사한다. 함수에 구조체를 넘기면 통째로 복사본이 만들어진다.

// Go
func modify(nums [3]int) {
    nums[0] = 999
}
 
func main() {
    a := [3]int{1, 2, 3}
    modify(a)
    fmt.Println(a) // [1 2 3] — 원본 안 바뀜. 복사본이 수정됨
}

정리하면 이렇다.

	Python	Go
변수 할당	객체의 참조 저장	값 자체를 저장
함수 인자 전달	참조의 복사	값의 복사
원본 수정	기본적으로 가능	포인터를 명시적으로 사용해야 함

슬라이스, 맵, 채널은 예외

Go의 슬라이스([]int), 맵(map), 채널(chan)은 내부에 참조를 포함하는 타입이다. 이들은 값 복사가 일어나도 내부 데이터를 공유하므로 Python의 리스트/딕셔너리와 비슷하게 동작한다. 위 예시에서 배열([3]int)을 쓴 이유도 이 차이를 보여주기 위해서다.

---

2. &와 * — 주소와 역참조

포인터는 메모리 주소를 저장하는 변수다. Go에서는 두 가지 연산자로 포인터를 다룬다.

• &x — 변수 x의 메모리 주소를 가져옴
• *p — 포인터 p가 가리키는 값을 가져옴 (역참조)

x := 10
pointerToX := &x        // x의 주소
fmt.Println(pointerToX)  // 0xc0000b4008 같은 메모리 주소
fmt.Println(*pointerToX) // 10 (역참조)
 
*pointerToX = 20
fmt.Println(x)           // 20 — 포인터를 통해 원본 수정

포인터의 zero value는 nil

Go의 모든 타입에는 zero value가 있다(02편에서 다뤘다). int은 0, string은 ""인 것처럼. 포인터의 zero value는 **nil**이다. 아직 아무 주소도 가리키지 않는, “빈 포인터” 상태를 뜻한다.

var p *int             // 선언만 하면 nil
fmt.Println(p)         // <nil>
fmt.Println(p == nil)  // true

주의할 점은 nil 포인터를 역참조하면(*p) 런타임 패닉이 난다는 것이다. 가리키는 대상이 없는데 그 값을 꺼내려 하기 때문이다.

var p *int
fmt.Println(*p)   // panic: runtime error: invalid memory address or nil pointer dereference

Python의 None과 비슷한 위치다. 다만 Python은 None 자체가 하나의 객체라 변수에 담아 두는 것만으로는 터지지 않지만, Go에서 nil 포인터를 역참조하는 건 즉시 패닉으로 이어진다. 그래서 포인터를 인자로 받는 함수에서는 if p == nil으로 먼저 확인하는 패턴이 흔하다.

Python과 비교

Python에는 포인터가 없다. id() 함수로 객체의 메모리 주소를 볼 수는 있지만, 그 주소를 통해 값을 직접 조작하는 방법은 없다.

x = 10
print(id(x))  # 4345678912 같은 주소
# 하지만 이 주소로 값을 바꾸는 방법은 없음

C와 비교

C/C++ 경험이 있다면 &와 *가 친숙할 것이다. 다만 Go에는 두 가지 중요한 차이가 있다.

• 포인터 산술 불가 — p++ 같은 연산으로 메모리를 직접 이동할 수 없다. 안전성을 위한 설계다.
• GC가 메모리를 관리 — free()나 delete를 호출할 필요가 없다. Go의 가비지 컬렉터가 알아서 정리한다.

---

3. 함수에서 포인터 사용

원본 값을 함수 안에서 수정하고 싶으면 포인터를 넘긴다.

func update(px *int) {
    *px = 20  // 포인터가 가리키는 값을 수정
}
 
func main() {
    x := 10
    update(&x)
    fmt.Println(x)  // 20
}

*int은 ‘주소를 담는 타입’이다

여기서 px *int라는 표기가 처음 보면 헷갈린다. *int이라는 타입이 값을 뜻하는지 주소를 뜻하는지 모호하게 느껴지기 때문이다. 결론부터 말하면 *int은 주소를 담는 타입이다.

• int 타입 변수 → 정수 값을 담는다 (x := 10 → x 안에는 10)
• *int 타입 변수 → int의 주소를 담는다 (px := &x → px 안에는 x가 사는 메모리 주소)

그래서 func update(px *int)은 “px는 int의 주소를 받는다”는 뜻이고, px에 들어오는 값은 처음부터 끝까지 주소다.

헷갈리는 진짜 이유는 * 기호가 붙는 위치에 따라 정반대로 동작하기 때문이다.

위치	예시	의미
타입 옆	px *int	”int을 가리키는 포인터 타입” — 주소를 담는다 (선언)
변수·값 옆	*px = 20	”그 주소가 가리키는 값” — 역참조 (연산)

• px *int에서 *는 타입 int에 붙어 “int 주소 타입”을 만든다. 주소 한 겹을 씌우는 쪽이다.
• *px에서 *는 변수 px에 붙어 “px가 든 주소로 찾아간 값”을 꺼낸다. 주소 한 겹을 벗기는 쪽이다.

방향이 반대다. 타입 자리에서는 주소를 씌우고, 식 자리에서는 주소를 벗긴다.

읽는 요령

• var px *int → “px is a pointer to int” (px는 int를 가리키는 포인터 = 주소를 담는다)
• *px → “value at px” (px가 가리키는 곳의 값)

집 주소에 비유하면 px는 종이에 적힌 주소이고, *px는 그 주소로 찾아가 집 안에서 꺼낸 물건이다. &x는 x라는 집의 주소를 알아내는 일이다.

이 구분을 염두에 두고 위 예시의 흐름을 단계별로 보면 이렇다.

1. x는 값 10을 가진 변수다 (int)
2. &x로 x의 주소를 구해서 update에 넘긴다 (*int 값, 즉 주소)
3. update 안의 px는 x의 주소를 담고 있다
4. *px = 20으로 그 주소에 있는 값을 20으로 바꾼다 (역참조)
5. main의 x가 20이 된다

---

4. 포인터 변수 자체도 복사된다 — 가장 흔한 실수

이 부분이 포인터를 처음 배울 때 가장 헷갈리는 지점이다. Go는 포인터를 넘길 때도 포인터 변수 자체는 복사한다. 포인터가 가리키는 대상을 공유할 뿐, 포인터 변수 자체는 별개다.

왜 별개인가 — 포인터도 자기 주소에 사는 변수다

핵심은 포인터 변수도 결국 자기만의 메모리 주소에 저장된 평범한 변수라는 점이다. 담고 있는 값이 “주소”일 뿐이다. 그래서 함수에 넘기면 그 값(주소)이 또 다른 위치에 복사된다.

x := 10
px := &x       // px는 x의 주소를 담는다
update(px)     // px의 '값'(주소)이 파라미터로 복사됨

세 변수가 각자 다른 주소에 산다고 보면 명확해진다.

변수	사는 주소(예시)	담은 값
x	0x100	10
px (= &x)	0x200	0x100 ← x의 주소
update의 파라미터 (px 복사본)	0x300	0x100 ← px에서 복사된 같은 주소

px와 파라미터는 같은 값(0x100)을 담지만, 자기 자신은 서로 다른 곳(0x200 vs 0x300)에 사는 별개의 변수다. 여기서 두 동작이 갈린다.

• *파라미터 = 20 → 파라미터가 든 주소 0x100으로 찾아가 값을 고침 → x가 바뀐다 (px도 같은 0x100을 가리키니 공유됨)
• 파라미터 = &다른변수 → 파라미터가 사는 0x300에 새 주소를 덮어씀 → px(0x200)는 그대로 → 바깥엔 영향 없음

즉 “가리키는 대상”은 공유하지만 “포인터 변수 그 자체”는 복사본이라 따로 논다. 만약 함수가 px가 가리키는 대상 자체를 바꾸게 하려면, px가 아니라 px의 주소(&px, 타입은 **int)를 넘겨야 한다. 값 복사 규칙은 포인터라고 예외가 아니기 때문이다.

Case 1: nil 포인터 전달

func failedUpdate(g *int) {
    x := 10
    g = &x   // g는 복사본. 바깥의 f는 안 바뀜
}
 
func main() {
    var f *int       // nil
    failedUpdate(f)
    fmt.Println(f)   // <nil> — 여전히 nil
}

failedUpdate 안에서 g에 새 주소를 할당해도, g는 f의 복사본이다. f는 여전히 nil이다.

Case 2: 포인터 재할당 vs 역참조 수정

// 실패하는 버전
func failedUpdate(px *int) {
    x2 := 20
    px = &x2   // px 복사본만 바뀜 — main의 x는 그대로
}
 
// 성공하는 버전
func update(px *int) {
    *px = 20   // px가 가리키는 곳의 값을 수정 — main의 x가 바뀜
}
 
func main() {
    x := 10
 
    failedUpdate(&x)
    fmt.Println(x)   // 10 — 안 바뀜
 
    update(&x)
    fmt.Println(x)   // 20 — 바뀜
}

핵심 규칙

• 포인터를 넘겨도 포인터 변수 자체는 복사된다
• 포인터 변수를 다른 주소로 재할당(px = &x2)하면 원본에 영향 없음
• 포인터가 가리키는 값을 수정(*px = 20)해야 원본이 바뀜

Python 용어로 비유하면 이렇다. Python에서 함수 안에서 lst = [4, 5, 6]처럼 새 리스트를 할당하면 원본이 안 바뀌는 것과 같은 원리다. 참조 자체를 교체한 것이지, 참조가 가리키는 대상을 수정한 게 아니기 때문이다.

# Python에서도 같은 원리
def failed_update(lst):
    lst = [4, 5, 6]   # 새 리스트로 교체 — 원본 안 바뀜
 
def update(lst):
    lst.append(4)      # 기존 리스트를 수정 — 원본 바뀜
 
a = [1, 2, 3]
failed_update(a)
print(a)  # [1, 2, 3]
 
update(a)
print(a)  # [1, 2, 3, 4]

---

5. 맵과 슬라이스를 함수에 넘길 때

1번에서 짚었듯 슬라이스·맵·채널은 값 복사가 일어나도 내부 데이터를 공유한다. 함수에 넘겨 내용을 바꾸면 원본에 반영되는 이유다. 이 동작은 05편의 call by value에서도 다뤘는데, 여기서는 그 구조와 실무에서의 주의점을 정리한다.

슬라이스는 (포인터, 길이, 용량) 헤더가 복사된다

슬라이스 값은 데이터 배열 자체가 아니라, 그 배열을 가리키는 작은 헤더다. 정확히는 세 가지 값으로 이뤄진다.

• 포인터 — 실제 데이터가 담긴 배열의 시작 주소
• 길이(len) — 현재 원소 개수
• 용량(cap) — 재할당 없이 담을 수 있는 최대 개수

함수에 슬라이스를 넘기면 이 헤더 세 값이 복사된다. 복사본의 포인터도 원본과 같은 배열을 가리키므로, 원소를 수정하면 원본에 반영된다.

func zeroFirst(s []int) {
    s[0] = 0   // 같은 배열을 가리키니 원본에 반영
}
nums := []int{1, 2, 3}
zeroFirst(nums)
// nums == [0 2 3]

반면 append는 복사본 헤더의 길이만 늘리거나, 용량이 모자라면 아예 새 배열을 할당한다. 어느 쪽이든 원본 헤더의 길이는 그대로라 추가분이 보이지 않는다. (이 동작은 03편의 슬라이싱·저장 공간 공유와 이어진다.)

func addItem(s []int) {
    s = append(s, 99)   // 복사본 헤더만 바뀜
}
nums := []int{1, 2, 3}
addItem(nums)
// nums == [1 2 3] — 99 안 보임

맵도 같은 원리다. 맵 값은 내부 해시 테이블을 가리키는 포인터라서, 복사돼도 같은 테이블을 공유한다. 그래서 함수 안에서 추가·삭제한 항목이 원본에 반영된다.

공용 API에서는 맵을 입력·반환으로 쓰지 마라

맵이 공유되고 구조도 느슨하다는 점 때문에, 설계할 때 주의해야 한다. 특히 공용 API의 입력 파라미터나 반환값으로 맵을 쓰는 것은 피하는 게 좋다. 대신 구조체를 쓴다.

// 권장하지 않음 — 어떤 키가 유효한지 시그니처에 드러나지 않는다
func NewUser(data map[string]string) User { ... }
// 호출하는 쪽: "name"? "Name"? "username"? 무엇을 넣어야 하나
// 오타가 나도 컴파일러가 잡아주지 않는다

// 권장 — 필드가 시그니처에 명시되고 컴파일러가 검증한다
type UserInput struct {
    Name  string
    Email string
}
func NewUser(in UserInput) User { ... }

차이는 분명하다.

• 자기 문서화 — 구조체는 어떤 필드가 있는지 타입 정의만 봐도 안다. 맵은 코드를 읽어야 유효한 키를 알 수 있다.
• 컴파일러 검증 — 구조체 필드명은 컴파일 타임에 검사된다. 맵 키는 오타가 나도 런타임까지 모른다.
• 원본 보호 — 맵을 넘기면 호출된 함수가 임의로 키를 추가·삭제할 수 있다. 구조체 값은 복사되므로 원본이 안전하다.

맵은 컴파일 타임에 키를 알 수 없는, 진짜 동적인 데이터에만 쓰는 게 맞다. 필드가 정해져 있다면 구조체가 거의 항상 낫다.

---

6. 포인터는 최후의 수단

Go 커뮤니티에서는 포인터 사용을 최소화하는 것을 권장한다. 이유는 명확하다.

• 데이터 흐름이 복잡해진다 — 포인터를 따라가면서 어디서 값이 바뀌는지 추적하기 어려워진다
• GC 부하가 증가한다 — 힙에 할당된 포인터가 많을수록 가비지 컬렉터가 할 일이 늘어난다
• 동시성에서 위험하다 — 포인터를 통해 공유 상태를 만들면 경쟁 조건(race condition)이 발생하기 쉽다

포인터 대신 값을 반환하는 패턴

구조체를 함수에 넘겨서 수정하는 대신, 함수 안에서 새로 만들어서 반환하는 것이 깔끔하다.

// 포인터를 쓰는 방식
func initUser(u *User) {
    u.Name = "Alice"
    u.Age = 30
}
 
// 값을 반환하는 방식 (권장)
func newUser() User {
    return User{
        Name: "Alice",
        Age:  30,
    }
}

포인터가 필요한 경우

물론 포인터가 반드시 필요한 상황도 있다.

• 인터페이스 충족 — 메서드의 리시버가 포인터 타입이어야 하는 경우
• JSON 마샬링 — null과 zero value를 구분해야 할 때
• 큰 구조체 — 복사 비용이 실측으로 문제가 될 때

이런 케이스는 별도 글에서 다룬다.

---

7. Go의 가비지 컬렉터와 메모리

포인터를 최소화하라는 조언(6번)의 배경에는 Go의 메모리 관리 방식이 있다. Go는 가비지 컬렉터(GC)를 가진 언어이고, 포인터를 어떻게 쓰느냐가 GC 부하에 직접 영향을 준다.

garbage와 스택·힙

garbage는 프로그램에서 더 이상 도달할 수 없는(unreachable) 메모리다. 전역 변수나 실행 중인 함수의 지역 변수에서 출발해 포인터를 따라가도 닿지 않는 데이터를 말한다. C처럼 직접 free하지 않아도, Go 런타임이 이런 메모리를 찾아 자동으로 회수한다.

메모리가 어디에 할당되는지가 중요하다.

• 스택(stack) — 함수의 지역 변수·파라미터가 올라가는 영역. 할당이 싸고(스택 포인터만 이동), 함수가 끝나면 자동으로 해제된다. GC가 신경 쓸 필요가 없다.
• 힙(heap) — 함수가 끝나도 살아남아야 하는 데이터가 가는 영역. GC가 추적하고 회수해야 한다. 힙 할당이 많을수록 GC가 할 일이 늘어난다.

escape analysis — 무엇이 힙으로 가는가

Go 컴파일러는 escape analysis로 값을 스택에 둘지 힙에 둘지 결정한다. 기준은 값 자체가 아니라, 그 변수를 가리키는 참조가 함수 밖까지 살아남아야 하느냐다. 같은 지역 변수라도 값으로 반환하면 스택에 머물고, 주소로 반환하면 힙으로 간다(“escape”).

func valueReturn() int {
    x := 10
    return x      // 값의 복사본만 나감 → x는 스택에 머묾, 힙 할당 없음
}
 
func pointerReturn() *int {
    x := 10
    return &x     // x의 주소가 밖으로 나감 → x는 힙으로 escape
}

두 함수의 차이는 함수가 끝나는 순간에 드러난다.

• valueReturn — 끝나기 직전에 x의 값(10)이 호출 측으로 복사되고, 함수 스택 프레임은 통째로 사라진다. 호출자는 이미 복사본을 들고 있으니 x가 없어져도 문제없다. 그래서 스택에 둬도 된다.
• pointerReturn — 호출자가 x의 주소를 들고 있는데, 함수가 끝나면서 그 주소의 스택 슬롯이 사라지면 가리킬 곳이 없어진다(C라면 dangling pointer 버그다). 그래서 컴파일러는 x를 처음부터 힙에 올려 함수가 끝나도 살아있게 만든다.

즉 값 복사는 escape를 일으키지 않고, 주소(포인터)가 프레임 밖으로 새어나갈 때만 힙으로 간다. return &x뿐 아니라 &x를 전역 변수에 저장하거나, 밖으로 탈출하는 클로저가 x를 캡처하는 경우도 같은 이유로 escape한다. 힙 할당이 늘면 GC 비용이 따라오므로, 포인터를 남발하면 그만큼 GC 부하가 커진다 — 6번에서 “GC 부하가 증가한다”고 한 이유다.

어떤 값이 escape하는지는 컴파일러에게 물어볼 수 있다.

go build -gcflags="-m" main.go
# pointerReturn에서만 "moved to heap: x" 가 뜬다

GC 부하를 줄이는 패턴

데이터를 어떻게 배치하느냐로 힙 할당과 GC 부하를 줄일 수 있다.

값 타입과 연속 메모리. 구조체 슬라이스([]Point)는 데이터가 메모리에 연속으로 놓이고 할당도 한 번이다. 반면 포인터 슬라이스([]*Point)는 원소가 따로 힙에 할당되기 쉬워, GC가 추적할 대상이 그만큼 늘고 캐시 효율도 떨어진다. 특별한 이유가 없으면 값 슬라이스가 낫다.

버퍼 슬라이스 재사용. 반복문에서 매번 새 슬라이스를 할당하면 그만큼 garbage가 쌓인다. 슬라이스 하나를 미리 만들어 버퍼로 재사용하면 할당이 한 번으로 준다.

// 매 반복마다 새로 할당 — garbage 누적
func process(r io.Reader) {
    for {
        buf := make([]byte, 1024)   // 반복마다 할당
        n, err := r.Read(buf)
        if n > 0 {
            handle(buf[:n])
        }
        if err != nil {
            break
        }
    }
}
 
// 버퍼 하나를 재사용 — 할당 한 번
func process(r io.Reader) {
    buf := make([]byte, 1024)       // 한 번만 할당
    for {
        n, err := r.Read(buf)       // 같은 버퍼에 덮어씀
        if n > 0 {
            handle(buf[:n])
        }
        if err != nil {
            break
        }
    }
}

Go GC의 성향 — 저지연 우선

Go의 GC는 동시(concurrent) 삼색 mark-and-sweep 방식이다. 프로그램을 멈추고 한꺼번에 청소하는 대신, 프로그램과 동시에 돌면서 쓰레기를 표시·회수한다. 설계 철학은 낮은 지연시간(low latency) 우선이다. 잠깐 멈추는 stop-the-world 구간을 극도로 짧게 유지한다(Go 1.8 이후 서브밀리초 수준, 보통 수백 마이크로초. 힙 크기와 부하에 따라 달라진다). 대신 전체 처리량(throughput)은 약간 희생하는 트레이드오프를 택했다. 짧고 예측 가능한 멈춤이 서버 응답성에 중요하기 때문이다. 또 객체를 옮기지 않는(non-compacting) 방식이라, GC가 돌아도 포인터가 가리키는 주소가 도중에 바뀌지 않는다.

동작을 조절하는 환경 변수가 둘 있다.

• GOGC — 다음 GC를 언제 돌릴지 정한다. 기본값 100은 대략 “직전 GC 후 살아남은 힙만큼 새로 할당되면(즉 힙이 약 두 배가 되면) 다음 GC를 돌린다”는 뜻이다. 값을 높이면 GC가 덜 자주 돌고 메모리를 더 쓰며, 낮추면 자주 돌고 메모리를 아낀다.
• GOMEMLIMIT — 소프트 메모리 한도(Go 1.19+). 힙이 이 한도에 가까워지면 GC가 더 적극적으로 일해서 메모리 초과를 막는다. 컨테이너처럼 메모리 상한이 있는 환경에서 OOM 방지에 쓴다.

GOGC 트리거를 더 정확히

위의 “힙이 약 두 배”는 직관용 근사다. Go 1.18부터 실제 트리거 기준은 살아있는 힙뿐 아니라 GC roots(고루틴 스택·전역 포인터)까지 포함한다. 정확한 공식은 목표 힙 = 살아있는 힙 + (살아있는 힙 + GC roots) × GOGC / 100이고, GC roots가 작을 때 근사적으로 “살아있는 힙의 두 배”가 된다. (출처: go.dev/doc/gc-guide)

Python의 메모리 관리와 비교

CPython은 참조 카운팅이 기본이고, 순환 참조를 처리하는 별도 GC가 보조로 돈다. 참조 카운트가 0이 되는 즉시 해제되는 구조라 예측 가능하지만, 카운트를 갱신하는 비용이 상시 든다. Go는 참조 카운팅 없이 동시 mark-sweep으로만 돌며, 값 타입과 스택 할당을 적극 활용해 애초에 GC가 건드릴 대상을 줄이는 쪽으로 설계됐다.

Python 개발자를 위한 한 줄 요약

Python에서는 신경 안 써도 되던 것을 Go에서는 명시적으로 다뤄야 한다. 값이 복사되는지, 참조가 전달되는지를 코드에서 직접 결정하는 것이 Go 방식이다.