정적 타입·컴파일 언어가 런타임 성능에 미치는 영향 (Go 기준 정리)

Go는 어디에 있는 언어인가

언어의 실행 방식은 스펙트럼이다. 소스를 그때그때 해석하는 인터프리터부터, 바이트코드를 VM이 돌리며 자주 쓰는 경로를 실행 중에 기계어로 바꾸는 JIT, 빌드할 때 기계어를 전부 만들어 두는 AOT까지 있다.

AOT와 JIT의 차이는 최적화에 쓰는 정보에서 갈린다. JIT는 실제 실행 프로파일을 보고 최적화하는 대신 워밍업이 필요하고, AOT는 첫 실행부터 최고 속도지만 정적 분석만으로 최적화해야 한다.

서버리스, 컨테이너, CLI에서 Go를 자주 고르는 이유가 이 표에 있다. 콜드 스타트가 잦은 환경일수록 워밍업 없는 AOT가 유리하다.

타입 시스템은 두 축으로 나누면 정리된다. 타입이 변수에 붙어 컴파일 시점에 검사되면 정적, 값에 붙어 실행 시점에 검사되면 동적이다. 암묵적 변환을 거부하면 강 타입이다.

Go는 정적 · 강 타입 중에서도 엄격해서 int와 int64 사이도 명시적으로 변환해야 한다.

잘 언급되지 않는 세 번째 축도 있다. 런타임의 두께다. 같은 AOT · 정적 타입이어도 이 축에서 언어가 갈린다.

여기서 Go의 특이한 자리가 보인다. 컴파일 언어인데 런타임이 있다. C와 Rust는 런타임이 얇아서 GC나 스케줄러를 체감할 일이 없고, Java는 JVM이 블랙박스다. Go는 런타임이 코드 성능에 그대로 드러나고, 그 런타임 소스(src/runtime/)가 Go로 쓰여 있어 직접 읽을 수 있다.

정적 타입이 런타임에 주는 이득

“정적 타입은 버그를 미리 잡아 준다”는 절반의 이야기다. 나머지 절반, 이 글의 핵심은 성능이다. 타입이 컴파일 시점에 정해지면 런타임에 이런 일이 가능해진다.

구조체 메모리 레이아웃이 가장 손에 잡히는 예다. 필드 순서만 바꿔도 크기가 달라진다. 정렬(alignment) 때문에 패딩이 들어가서다.

type Bad struct {
  a bool  // 1 + 패딩 7
  b int64 // 8
  c bool  // 1 + 패딩 7
}

type Good struct {
  b int64 // 8
  a bool  // 1
  c bool  // 1 + 패딩 6
}

필드 순서만 바꿨는데 33% 줄었다. unsafe.Sizeof, Alignof, Offsetof로 확인할 수 있고, go vet -fieldalignment가 자동으로 찾아 준다. 이 레이아웃이 컴파일 시점에 확정되니까 필드 접근이 기준 주소 + 상수 오프셋 명령 하나가 된다.

unsafe.Sizeof(Bad{})   = 24    unsafe.Offsetof(Bad{}.b)  = 8   ← a 뒤 패딩 7
unsafe.Sizeof(Good{})  = 16    unsafe.Offsetof(Good{}.a) = 8

make([]Bad, 1_000_000)  → HeapAlloc +24.0 MB
make([]Good, 1_000_000) → HeapAlloc +16.0 MB   // 필드 순서만으로 -33%

소스가 바이너리가 되기까지

Go 컴파일러가 .go 파일을 실행 파일로 만드는 순서다.

1. Lexer · Parser: AST를 만든다.
2. 타입 검사: 타입을 추론하고 검증한다.
3. 중간 최적화: 인라이닝, escape analysis.
4. SSA 최적화: 40개가 넘는 패스.
5. 기계어 생성: .o 파일.
6. 링킹: 런타임까지 포함해 바이너리 하나로.

눈여겨볼 건 마지막 단계다. 링킹할 때 GC, 스케줄러, 할당자가 통째로 실행 파일에 들어간다. hello world도 몇 MB인 이유이고, 반대로 런타임 설치 없이 파일 하나만 배포하면 되는 이유다.

이 중 성능에 바로 이어지는 최적화 다섯 가지다. 모두 도구로 확인할 수 있다.

인라이닝이 첫 줄인 이유가 있다. 호출 비용이 사라지는 것보다, 인라이닝된 뒤에야 escape analysis, 상수 전파, 경계 검사 제거가 이어서 적용되는 효과가 더 크다. 인라이닝은 다른 최적화의 전제 조건이다.

$ go build -gcflags='-m -m' add.go
./add.go:5:6: can inline Add with cost 4 as: func(int, int) int { return a + b }

# 분기를 계속 더하다 보면 어느 순간:
./add.go:5:6: cannot inline Add: function too complex:
              cost 83 exceeds budget 80

BenchmarkAdd (기본)          0.26 ns/op   ← 호출이 사라지고 상수 접기까지
BenchmarkAdd (-gcflags=-l)   1.94 ns/op   ← 매번 실제 CALL

스택이냐 힙이냐: escape analysis

C는 malloc을 쓰면 힙, 아니면 스택이다. Go에는 그런 문법이 없고 컴파일러가 정한다. 기준은 규칙 암기가 아니라 원리 하나다. 값의 수명이 함수 프레임을 넘어가는가. 넘어가면(판단할 수 없으면 보수적으로) 힙, 아니면 스택이다.

func f() *int { x := 1; return &x }    // 포인터 반환
func g(v any) { ... }                  // 인터페이스로 전달 (대상을 모른다)
func h(n int) { s := make([]int, n) }  // 크기를 컴파일 시점에 모른다
go func() { use(x) }()                 // 클로저 캡처 + 고루틴
fmt.Println(x)                         // ...any 가변 인자 (의외의 단골)

직접 확인하는 게 이 주제의 전부다. 30초면 된다.

$ go build -gcflags='-m' esc.go
./esc.go:6: can inline stack
./esc.go:7: p escapes to heap   ← 이 한 줄이 GC 부담의 출발점

스택 할당은 프레임 포인터만 움직이면 끝이라 사실상 공짜고, 함수가 끝나면 자동으로 사라진다. 힙 할당은 할당자를 거치고, 나중에 GC가 치워야 하는 빚이 된다. 그래서 Go 성능 최적화의 첫 원칙은 빠르게 할당하기가 아니라 덜 할당하기다.

escape analysis 결과는 컴파일러 버전마다 달라진다. Go 1.26은 슬라이스 백킹 스토어를 스택에 두는 경우를 넓혔다. 이 패턴은 힙이라고 외우기보다, 쓰는 버전에서 -gcflags='-m'으로 확인하는 습관이 맞다.

$ go build -gcflags='-m' log.go
./log.go:8:14: x escapes to heap        ← ...any 인자로 들어가는 순간
./log.go:8:13: []interface {}{...} escapes to heap

$ go test -bench=. -benchmem
BenchmarkDirect-8     0.3 ns/op     0 B/op   0 allocs/op
BenchmarkPrintln-8   58.1 ns/op    16 B/op   1 allocs/op

타입의 런타임 모습: 슬라이스, 인터페이스, 그리고 함정

정적 타입이 런타임에 어떻게 생겼는지 보면 유명한 함정이 전부 설명된다. 개념적으로는 이렇다.

// slice: 3워드 — 데이터 포인터 + 길이 + 용량
type slice struct { array unsafe.Pointer; len, cap int }

// string: 2워드, 불변
type string struct { data *byte; len int }

// 인터페이스: 2워드 — 타입 정보 + 데이터 포인터
type iface struct { tab *itab; data unsafe.Pointer }
// itab: (인터페이스, 구체 타입) 쌍마다 하나. 메서드 함수 포인터 테이블

여기서 이런 것들이 나온다.

• append와 재할당. cap을 넘으면 새 배열을 할당하고 복사한다. 이 순간 원본과의 공유가 끊긴다. “append 했는데 원본이 바뀔 때도 있고 아닐 때도 있어요”의 정체다.
• 재슬라이싱 메모리 누수. 큰 배열의 작은 조각(huge[:3])을 들고 있으면, 슬라이스 헤더가 배열 전체를 가리키고 있어서 전체가 GC되지 않는다.
• nil 인터페이스 함정. 인터페이스는 (타입, 데이터) 두 워드라서, nil 포인터를 담으면 {tab: T, data: nil}이 된다. 타입 정보가 있으니 != nil이다.
• 인터페이스 변환 비용. 포인터가 아닌 값을 인터페이스에 담으면 보통 힙 할당이 생긴다(0~255 같은 작은 정수, 크기가 0인 값 등은 예외).

정적 디스패치와 동적 디스패치

func Do(w *bytes.Buffer)  // 정적: 직접 호출 → 인라이닝 가능
func Do(w io.Writer)      // 동적: itab.fun 을 거치는 간접 호출
                          //       인라이닝 불가 + 할당 가능성

인터페이스는 유연성을 주는 대신 인라이닝 기회와 직접 호출을 포기하는 트레이드오프다. 인터페이스를 피하라는 게 아니라, 핫 패스에서는 비용을 알고 쓰라는 것이다. 조건이 맞으면 컴파일러가 devirtualize 해 주고, PGO(프로파일 기반 최적화)를 쓰면 그 범위가 넓어진다.

제네릭은 어느 쪽도 아니다

Go는 그 중간이다. 코드 팽창도 전면 박싱도 피하지만, 포인터 타입 인스턴스에는 딕셔너리를 거치는 간접 참조 비용이 남는다. 제네릭도 공짜는 아니다.

func mayFail() error {
  var p *MyErr // nil 포인터
  return p     // nil 포인터를 error 인터페이스에 담아 반환
}

err := mayFail()
fmt.Println(err == nil) // false

// unsafe로 iface 내부를 찍으면:
// (tab=0x4a2e88, data=0x0)  ← 타입 정보가 있으니 nil이 아니다
// 진짜 nil 인터페이스는 (tab=0x0, data=0x0)

BenchmarkConcrete-8    1.9 ns/op    0 B/op   0 allocs/op   // 직접 호출 + 인라이닝
BenchmarkGeneric-8     2.1 ns/op    0 B/op   0 allocs/op   // 값 타입 stenciling
BenchmarkInterface-8   4.6 ns/op    8 B/op   1 allocs/op   // itab 간접 호출 + 박싱

런타임 ① GC: 컴파일 언어에 왜 GC가 있고, 어떻게 멈추지 않나

Go GC를 한 표로 정리하면 이렇다.

동작 원리는 3색 마킹이다. 흰색(미방문)에서 회색(방문, 자식은 아직)을 거쳐 검은색(끝)으로 칠해 나가고, 끝났을 때 남은 흰 객체를 치운다. 문제는 이걸 애플리케이션이 돌아가는 중에 한다는 것이다. 마킹하는 사이에 프로그램이 포인터를 바꿔 버리면 어떻게 될까.

write barrier는 포인터를 쓸 때마다 컴파일러가 심어 둔 코드가 끼어드는 장치다. 그리고 여기서 이 글의 주제가 한 바퀴 돈다. GC가 힙을 정확히 스캔할 수 있는 건 정적 타입 덕분이다. 컴파일러가 모든 타입의 어느 오프셋이 포인터인지 메타데이터로 남겨 두니까, GC는 정수를 포인터로 착각하는 보수적 스캔을 할 필요가 없다. 고루틴 스택을 자유롭게 옮길 수 있는 것도 같은 이유다. 스택 안의 포인터를 전부 정확히 아니까 복사한 뒤 다시 맞출 수 있다.

GC 한 사이클과 힙 할당자

한 사이클은 네 단계다. STW(Stop The World)는 시작과 끝의 짧은 두 지점뿐이고, 무거운 마킹은 애플리케이션과 함께 돈다(CPU 25% 목표).

1. Sweep 종료: 짧은 STW.
2. Mark: 동시에 진행, write barrier 켬.
3. Mark 종료: 짧은 STW.
4. Sweep: 동시에 진행, 할당할 때 조금씩.

GC가 치울 객체를 만드는 할당자도 계층 구조다. TCMalloc 계열로, 락 없는 P별 캐시에서 시작해 부족할 때만 아래로 내려간다.

mcache   (P마다 하나, 락 없음)      ← 대부분의 할당이 여기서 끝난다
  ↓ 부족하면
mcentral (size class별, 락 있음)   ← 작은 객체(≤32KB)는 약 68종의
  ↓ 부족하면                          size class별 span에서 할당
mheap    (전역, 페이지 단위)        ← 큰 객체(>32KB)는 여기서 바로
  ↓ 부족하면
OS (mmap)

size class 덕분에 외부 단편화가 억제되고, 16바이트 미만이면서 포인터가 없는 값은 tiny allocator가 묶어서 처리한다. 할당 자체는 이렇게 빠르게 설계돼 있다. 문제는 언제나 할당의 총량이다.

튜닝 노브는 사실상 두 개

• GOGC(기본 100): 라이브 힙이 직전보다 100% 늘면 다음 GC를 시작한다. 키우면 GC는 덜 돌고 메모리는 더 쓴다.
• GOMEMLIMIT(1.19+): 소프트 메모리 상한. 컨테이너 OOM을 막는 데 사실상 필수다.
• 실전 조합: GOGC=off GOMEMLIMIT=512MiB. 상한까지 쓰고 GC는 최소로.

$ GODEBUG=gctrace=1 ./app
gc 14 @2.104s 0%: 0.018+1.3+0.076 ms clock, ...
#                  ↑ STW + 동시 마킹 + STW — STW가 1ms 미만인 게 보인다

GC는 지금도 바뀌고 있다. Go 1.25에서 실험으로 나온 Green Tea GC가 1.26부터 기본이 됐다. 객체 단위가 아니라 메모리 블록 단위로 마킹해서 캐시 지역성을 살리는 방식이고, 작은 객체가 많은 서비스에서 GC 오버헤드가 10~40% 줄었다. 그래도 교훈은 같다. 할당이 빨라져도 할당 횟수는 GC 빚으로 돌아온다.

$ GODEBUG=gctrace=1 ./concat-plus     # += : 매번 새 문자열 할당 + 복사
gc 1 ... gc 2 ... (중략) ... gc 47    # GC 47회, 2.9s

$ GODEBUG=gctrace=1 ./concat-builder  # Builder + Grow()
gc 1 @0.11s ... gc 3 @0.14s           # GC 3회, 0.08s

런타임 ② 스케줄러: G, M, P

고루틴이 OS 스레드보다 훨씬 가벼운 이유도 런타임에 있다. 시작 스택이 2KB(OS 스레드는 보통 1~8MB)이고, 모자라면 두 배짜리 새 스택을 할당해 복사하고 포인터를 다시 맞춘다. 그 위에서 런타임 스케줄러가 M:N 스케줄링을 한다.

M은 P를 쥐어야만 Go 코드를 실행할 수 있다. 이 규칙 하나에서 아래 동작이 전부 나온다.

• Work stealing. P의 로컬 큐가 비면 전역 큐, netpoller를 보고, 그래도 없으면 다른 P의 큐 절반을 훔친다. 코어를 놀리지 않는다.
• Handoff. G가 블로킹 시스템 콜에 들어가면 M이 P를 내놓고, 그 P는 다른 M에 넘어가 나머지 고루틴을 계속 돌린다. 시스템 콜 하나가 프로그램 전체를 세우지 못하는 이유다.
• netpoller. 네트워크 I/O는 epoll · kqueue로 묶어 처리한다. 코드는 conn.Read()처럼 동기로 쓰는데 실제로는 논블로킹이라, G만 재워 두고 M은 다른 일을 한다. async/await 없이 동시성이 되는 비밀이다.
• 비동기 선점(1.14+). 함수 호출이 없는 for {}도 시그널로 선점한다. 그전에는 이런 루프가 스케줄러를 굶겼다.

$ GODEBUG=schedtrace=1000 ./app   # 1초마다 스케줄러 상태 출력
SCHED 1009ms: gomaxprocs=8 idleprocs=2 threads=14
      runqueue=3 [2 0 1 4 0 0 1 0]   # 전역 큐 + P별 로컬 큐 길이

동시성 이야기에 하나만 덧붙이면, 데이터 레이스는 가끔 틀린 값이 나오는 문제가 아니라 정의되지 않은 동작이다. 컴파일러와 CPU가 코드를 재배치하기 때문에 무엇이든 일어날 수 있다. 채널 송수신, mutex, atomic이 만드는 happens-before 관계만 보장되고, go test -race는 선택이 아니라 기본이다.

goroutines: 100001,  HeapSys+StackSys 증가분 ≈ 292 MB
→ 약 2.9 KB/goroutine   (OS 스레드였다면 기본 스택만 100,000 × 1~8MB)

# CPU 바운드: P 8개가 전부 바쁘고 로컬 런 큐에 G가 쌓인다
SCHED 2013ms: gomaxprocs=8 idleprocs=0 threads=11 runqueue=14 [7 3 5 6 2 4 8 3]

# I/O 바운드: G는 수천 개인데 전부 netpoller에서 대기, P는 논다
SCHED 2011ms: gomaxprocs=8 idleprocs=7 threads=10 runqueue=0 [0 0 0 0 0 0 0 0]

==================
WARNING: DATA RACE
Write at 0x00c000014098 by goroutine 7:
  main.main.func1()  race.go:11 +0x44
Previous write at 0x00c000014098 by goroutine 6:
  main.main.func1()  race.go:11 +0x44
==================

언어 기능의 숨은 런타임 비용

문법은 공짜처럼 보여도 런타임 가격표가 붙어 있다. 자주 쓰는 것만 추렸다.

바이너리와 링킹: 컴파일 언어의 마지막 구간

링킹까지 끝난 Go 바이너리는 그 자체로 볼거리다. .text(코드), .rodata(상수) 같은 표준 섹션에 더해 Go만의 .gopclntab(PC와 소스 줄을 잇는 테이블)이 들어 있다. 스택 트레이스와 GC의 정확한 스캔이 둘 다 여기에 기댄다. hello world가 몇 MB인 건 런타임, 리플렉션 메타데이터, DWARF 디버그 정보가 모두 정적으로 들어가기 때문이다.

호출 규약(ABI)도 컴파일 언어라서 보이는 부분이다. Go 1.17부터 인자를 스택 대신 레지스터로 넘기는 내부 ABI로 바뀌어 함수 호출이 5~10% 빨라졌다. go tool objdump로 역어셈블하면 인자가 AX, BX 레지스터에 실리는 게 그대로 보인다.

$ go build -o app . && ls -lh app
-rwxr-xr-x  7.9M app

$ go build -ldflags="-s -w" -o app-small .    # 심볼 · DWARF 제거
-rwxr-xr-x  5.4M app-small                     # -32%

$ CGO_ENABLED=1 go build -o app-cgo . && ldd app-cgo
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6   ← 동적 링크

$ CGO_ENABLED=0 go build -o app-static . && ldd app-static
        not a dynamic executable                        ← 완전 정적

전부 도구로 확인할 수 있다

이 주제를 공부하며 가장 크게 배운 건 개념이 아니라 태도였다. 읽어서 아는 것과 확인해서 아는 것은 다르다. Go는 확인 도구가 전부 표준 툴체인에 들어 있다.

$ go tool pprof http://localhost:6060/debug/pprof/profile?seconds=10
(pprof) top5
      flat   cum
    41.2%  63.8%  encoding/json.(*encodeState).marshal   ← 범인
    18.9%  18.9%  runtime.mallocgc                       ← 그 할당 비용
     9.1%   9.1%  runtime.memmove
     ...

$ benchstat old.txt new.txt
              │   old.txt    │   new.txt              │
Handler-8       41.3µs ± 2%    17.8µs ± 3%   -56.9%  (p=0.000)
Handler-8       18.2KB ± 0%     3.1KB ± 0%   -83.0%  (B/op)
Handler-8         214 ± 0%        38 ± 0%    -82.2%  (allocs/op)

도구가 있어도 순서가 틀리면 시간만 버린다. 최적화는 이 순서로 한다.

1. 측정한다. 추측하지 않는다.
2. 알고리즘과 자료 구조를 본다.
3. 할당을 줄인다.
4. 동시성 구조를 본다.
5. 마이크로 최적화를 한다.
6. 다시 측정한다.

30초짜리 입구

지금 바로 해 볼 수 있는 출발점을 남겨 둔다. 컴파일러의 결정을 읽고, GC와 스케줄러를 관찰하는 데 각각 명령 하나면 된다.

type Point struct{ X, Y int }

func stack() Point { return Point{1, 2} }
func heap() *Point { p := Point{1, 2}; return &p }

$ go build -gcflags='-m -m' esc.go    # 컴파일러의 결정 읽기
$ GODEBUG=gctrace=1 ./app             # GC 관찰
$ GODEBUG=schedtrace=1000 ./app       # 스케줄러 관찰