Go on 엔지니어 생존기록

SIMD를 알아보자(feat. Go)

Wed, 12 Aug 2026 21:30:50 +0900

최근에 Youtube에서 재밌는 영상 하나를 봤습니다. People Are Mad They’re Told to Learn 이라는 영상인데요, 영상의 발단은 Mitchell Hashimoto의 Everyone Should Know SIMD 라는 글이었습니다. 인터넷에서는 그 글에 대한 반발로 “아니 왜 모든 개발자가 이런 걸 꼭 알아야 한다는 말이냐"등과 같은 반응이 있었고, 저 영상에서는 그 글에 대한 반응과 함께 SIMD로 코드를 작성해보는 내용이 있었습니다. 그걸 보고 나니 저도 궁금해졌습니다. SIMD가 뭔데? 왜 이걸 다 알아야 한다는 거지? 그래서 그냥 한번 시작해봤습니다.

Go 환경설정

우선 Go를 통해 SIMD를 테스트할 수 있는 환경을 마련해보겠습니다. 저는 Go를 brew를 통해 설치했었는데요, 2026년 8월 현재 brew를 통해 설치할 수 있는 최신 버전은 1.26.5입니다. 1.26.5버전도 SIMD가 지원되긴 하지만 AMD64 환경에서만 제한적으로 지원되고, 맥(ARM64)에서 SIMD를 활용하려면 1.27rc2를 설치해야 합니다. 기존에 정식으로 설치된 버전과 간섭없이 동작할 수 있고, 나중에 제거할 때도 아무런 간섭없이 제거할 수 있습니다.

1. 래퍼 프로그램 설치

다음 명령으로 아주 작은 래퍼 프로그램을 설치합니다.

> go install golang.org/dl/go1.27rc2@latest

2. `~/go/bin` 을 PATH에 설정하기

> echo 'export PATH="$HOME/go/bin:$PATH"' >> ~/.zshrc
> source ~/.zshrc
> which go1.27rc2
/Users/onlifecoding/go/bin/go1.27rc2

3. 실제 SDK 다운로드

go1.27rc2 download
Downloaded 0.0% ( 2952 / 68280741 bytes) ...
Downloaded 5.6% ( 3833856 / 68280741 bytes) ...
Downloaded 24.7% (16859008 / 68280741 bytes) ...
Downloaded 41.2% (28131120 / 68280741 bytes) ...
Downloaded 58.3% (39828640 / 68280741 bytes) ...
Downloaded 74.9% (51134112 / 68280741 bytes) ...
Downloaded 90.1% (61488688 / 68280741 bytes) ...
Downloaded 100.0% (68280741 / 68280741 bytes)
Unpacking /Users/onlifecoding/sdk/go1.27rc2/go1.27rc2.darwin-arm64.tar.gz ...
Success. You may now run 'go1.27rc2'

4. 버전 확인하기

> go version
go version go1.26.5 darwin/arm64
> go1.27rc2 version
go version go1.27rc2 darwin/arm64
> go1.27rc2 env GOROOT
/Users/onlifecoding/sdk/go1.27rc2

5. SIMD 지원 확인하기

아래 명령을 통해 simd 패키지의 설명이 출력되면 환경 설정이 잘 끝났습니다.

> GOEXPERIMENT=simd go1.27rc2 doc simd | head -40
package simd // import "simd"
...

6. 설정 삭제하기

추후에 설정을 삭제하려면, SDK를 삭제하고 rm -rf ~/sdk/go1.27rc2, 래퍼 프로그램을 삭제하고 rm ~/go/bin/go1.27rc2, PATH 설정을 ~/.zshrc 에서 삭제하면 깔끔하게 제거할 수 있습니다.

테스트용 코드 작성하기

자 이제 일반 코드와 SIMD가 적용된 코드 간의 비교를 위해서 다음과 같이 코드를 작성 해볼겁니다.

simdbench/
├── go.mod
├── kernels.go # 스칼라 커널
├── kernel_simd.go # SIMD 커널 (goexperiment.simd 전용)
├── kernel_stub.go # SIMD 미지원 환경용 대체 커널
└── kernel_test.go # 정확성 테스트 + 벤치마크

1. 폴더와 모듈 생성

우선 폴더와 모듈을 생성합니다.

> mkdir simdbench && cd simdbench
> go mod init simdbench

2. 테스트에 사용할 2개의 연산 커널

이 테스트는 2개의 연산 커널의 기준으로 모든 테스트가 진행됩니다.

2-1. 합 구하기

다음과 같이 float32 배열의 합을 구합니다.

s = x[0] + x[1] + ... + x[n-1]

4 바이트를 읽어들일 때 마다 1개의 연산이 발생하기 때문에 메모리 중심의 연산 커널입니다. 또한 합을 구하기 위해서는 이전 단계의 합이 존재해야 하기 때문에 CPU가 대기해야 하는 구간이 발생합니다.

2-2. 삼차 다항식 계산

다음과 같은 삼차 다항식을 배열의 각 요소에 대해 독립적으로 계산합니다.

out[i] = ((0.5*x[i] + 1.2) * x[i] - 3.1) * x[i] + 0.7

1개의 요소 당 6번의 연산이 발생하는 계산 중심의 연산 커널입니다. 1번 연산 커널(합 구하기)에 비해 바이트당 연산 횟수가 더 많기 때문에 SIMD가 병렬화하기 더 좋은 구조입니다.

3. 커널 구현하기(kernels.go)

다음과 같이 kernels.go 를 작성합니다.

package kernels

func SumScalar(x []float32) float32 {
 var s float32
 for _, v := range x {
 s += v
 }
 return s
}

// 호너의 방법을 사용하여 거듭제곱 계산을 (곱셈, 덧셈)의 조합으로 변환
// 0.5v³ + 1.2v² − 3.1v + 0.7
// = v(0.5v² + 1.2v − 3.1) + 0.7
// = v(v(0.5v + 1.2) − 3.1) + 0.7
// = ((0.5v + 1.2)·v − 3.1)·v + 0.7
func PolyScalar(x, out []float32) {
 // 입력값을 체크한다. 동시에 컴파일러가 prove 과정에서 len(x) <= len(out)임을 확인한다.
 // 그러면 컴파일러는 아래 for 루프 안의 out[i]에 인덱스 접근 가드를 넣지 않는다.
 if len(out) < len(x) {
 panic("PolyScalar: out이 x보다 짧습니다.")
 }
 for i, v := range x {
 out[i] = ((0.5*v+1.2)*v-3.1)*v + 0.7
 }
}

// SumUnrolled4는 독립된 accumulator 4개를 사용한다.
// 각 덧셈이 앞 덧셈의 결과를 기다리지 않는다. 그래서 CPU가 덧셈 4개를 겹쳐 실행한다.
func SumUnrolled4(x []float32) float32 {
 var s0, s1, s2, s3 float32
 n := len(x)
 m := n - n%4 // 동시에 4개의 계산을 진행하니까 4로 나눠떨어지는 구간을 구하기
 i := 0
 for ; i < m; i += 4 {
 s0 += x[i]
 s1 += x[i+1]
 s2 += x[i+2]
 s3 += x[i+3]
 }
 s := s0 + s1 + s2 + s3
 for ; i < n; i++ { // 4로 나눠 남은 나머지 구간을 계산
 s += x[i]
 }
 return s
}

총 3개의 함수가 작성되었는데요. SumScalar, PolyScalar는 앞서 이야기 했던 연산 커널을 그대로 작성한 함수이고, SumUnrolled4 는 추가 설명이 필요합니다.

CPU는 float32를 더하는 작업에 3-4 사이클을 소비합니다. 그렇기 때문에 순차적으로 하나씩 더하는 SumScalar는 매 루프마다 앞선 더하기가 끝나기를 기다리는 비효율이 발생하게 되죠.

float32는 숫자로 저장되지 않으며, 1 부호 비트 + 8 지수 비트 + 23비트의 가수로 묶여있습니다. 그래서 float32 덧셈을 위해 각 피연산자를 계산 가능한 형태로 묶음을 해제(unpack)하는 1사이클과 계산의 1사이클, 계산 결과를 다시 float32의 형태로 재조정하는 데 1사이클이 필요합니다. 이 과정에 CPU 아키텍처에 따라서 3-4 사이클이 필요하다고 합니다.

그래서 앞선 계산을 기다리는 비효율이 발생하지 않도록 CPU가 4개의 계산을 동시에 진행한 뒤, 결과를 합치도록 하는 겁니다. 이런 방식을 ILP(Instruction-Level Parallelism)이라고 합니다.

4. SIMD 커널 구현하기(kernel_simd.go)

//go:build goexperiment.simd

package kernels

import "simd"

func SumSIMDSingle(x []float32) float32 {
 var acc simd.Float32s // accumulator vector. 실행 환경이 지원하는 SIMD lane 수만큼 누적 슬롯을 가진다. 초깃값은 Mac의 경우 [0, 0, 0, 0]
 lanes := acc.Len() // NEON은 4, AVX는 8 또는 16

 i := 0
 for ; i+lanes <= len(x); i += lanes { // lane 수만큼 딱 떨어지는 구간을 동시에 계산
 acc = acc.Add(simd.LoadFloat32s(x[i : i+lanes])) // 주어진 슬라이스에서 lane 수만큼 잘라서 각 lane별로 누적
 }

 var tmp [16]float32 // 스택에 배열을 생성(AVX512의 경우 최대 float32를 16개 담을 수 있으므로 최댓값으로 생성)
 acc.Store(tmp[:lanes]) // 각 lane의 값을 배열에 저장
 var s float32
 for j := 0; j < lanes; j++ { // 모든 lane의 결과 값을 더하기
 s += tmp[j]
 }

 for ; i < len(x); i++ { // lane 수로 딱 떨어지지 않고 남았던 인덱스에 대해 계산
 s += x[i]
 }
 return s
}

func SumSIMDUnrolled4(x []float32) float32 {
 var a0, a1, a2, a3 simd.Float32s // 4개의 accumulator vector를 생성
 lanes := a0.Len() // vector 하나가 담는 lane 수 확인
 step := lanes * 4 // 4개의 accumulator vector -> Mac의 경우 4 * 4 => 16

 i := 0
 for ; i+step <= len(x); i += step { // step 단위로 딱 떨어지는 구간을 계산 (Mac은 한 번에 16개)
 a0 = a0.Add(simd.LoadFloat32s(x[i : i+lanes])) // 각 accumulator vector에 lane 수만큼 끊어서 누적
 a1 = a1.Add(simd.LoadFloat32s(x[i+lanes : i+2*lanes]))
 a2 = a2.Add(simd.LoadFloat32s(x[i+2*lanes : i+3*lanes]))
 a3 = a3.Add(simd.LoadFloat32s(x[i+3*lanes : i+4*lanes]))
 }

 // step만큼 끊고 남은 나머지 중에서 lane 수만큼 끊을 수 있는 구간을 계산
 for ; i+lanes <= len(x); i += lanes {
 a0 = a0.Add(simd.LoadFloat32s(x[i : i+lanes]))
 }

 // (a0+a1)과 (a2+a3)를 먼저 묶어서 안쪽 Add 두 개가 겹쳐 실행되게 한다
 acc := a0.Add(a1).Add(a2.Add(a3))

 var tmp [16]float32 // 스택에 배열을 생성(AVX512의 경우 최대 float32를 16개 담을 수 있으므로 최댓값으로 생성)
 acc.Store(tmp[:lanes])
 var s float32
 for j := 0; j < lanes; j++ {
 s += tmp[j]
 }

 for ; i < len(x); i++ {
 s += x[i]
 }
 return s
}

func SumSIMDUnrolled8(x []float32) float32 {
 var a0, a1, a2, a3, a4, a5, a6, a7 simd.Float32s // 8개의 accumulator vector를 생성
 lanes := a0.Len() // vector 하나가 담는 lane 수 확인
 step := lanes * 8 // 8개의 accumulator vector -> Mac의 경우 4 * 8 => 32

 i := 0
 for ; i+step <= len(x); i += step { // step 단위로 딱 떨어지는 구간을 계산 (Mac은 한 번에 32개)
 a0 = a0.Add(simd.LoadFloat32s(x[i : i+lanes])) // 각 accumulator vector에 lane 수만큼 끊어서 누적
 a1 = a1.Add(simd.LoadFloat32s(x[i+lanes : i+2*lanes]))
 a2 = a2.Add(simd.LoadFloat32s(x[i+2*lanes : i+3*lanes]))
 a3 = a3.Add(simd.LoadFloat32s(x[i+3*lanes : i+4*lanes]))
 a4 = a4.Add(simd.LoadFloat32s(x[i+4*lanes : i+5*lanes]))
 a5 = a5.Add(simd.LoadFloat32s(x[i+5*lanes : i+6*lanes]))
 a6 = a6.Add(simd.LoadFloat32s(x[i+6*lanes : i+7*lanes]))
 a7 = a7.Add(simd.LoadFloat32s(x[i+7*lanes : i+8*lanes]))
 }

 // step만큼 끊고 남은 나머지 중에서 lane 수만큼 끊을 수 있는 구간을 계산
 for ; i+lanes <= len(x); i += lanes {
 a0 = a0.Add(simd.LoadFloat32s(x[i : i+lanes]))
 }

 // (a0+a1) (a2+a3) (a4+a5) (a6+a7)
 acc := a0.Add(a1).Add(a2.Add(a3)).Add(a4.Add(a5).Add(a6.Add(a7)))

 var tmp [16]float32 // 스택에 배열을 생성(AVX512의 경우 최대 float32를 16개 담을 수 있으므로 최댓값으로 생성)
 acc.Store(tmp[:lanes])
 var s float32
 for j := 0; j < lanes; j++ {
 s += tmp[j]
 }

 for ; i < len(x); i++ {
 s += x[i]
 }
 return s
}

// splat은 모든 lane을 v로 채운 vector를 만든다.
// hot loop 밖에서만 호출하므로 이 작은 루프의 비용은 무시해도 된다.
func splat(v float32, lanes int) simd.Float32s {
 b := make([]float32, lanes)
 for i := 0; i < lanes; i++ {
 b[i] = v
 }
 return simd.LoadFloat32s(b[:lanes])
}

// 호너의 방법을 사용하여 거듭제곱 계산을 (곱셈, 덧셈)의 조합으로 변환
// 0.5v³ + 1.2v² − 3.1v + 0.7
// = v(0.5v² + 1.2v − 3.1) + 0.7
// = v(v(0.5v + 1.2) − 3.1) + 0.7
// = ((0.5v + 1.2)·v − 3.1)·v + 0.7
func PolySIMD(x, out []float32) {
 var probe simd.Float32s
 lanes := probe.Len() // lane 수를 확인하는 용도로만 사용

 // 4개의 다항식 계수를 lane 수만큼 펼쳐서 레지스터에 로드(ex: [0.5, 0.5, 0.5, 0.5])
 c3 := splat(0.5, lanes)
 c2 := splat(1.2, lanes)
 c1 := splat(-3.1, lanes)
 c0 := splat(0.7, lanes)

 i := 0
 for ; i+lanes <= len(x); i += lanes {
 v := simd.LoadFloat32s(x[i : i+lanes]) // 레지스터에 lane 수만큼 로드
 r := c3.Mul(v).Add(c2) // c3 * v + c2 => [0.5*v1+1.2, ... , 0.5*v4+1.2]
 r = r.Mul(v).Add(c1)
 r = r.Mul(v).Add(c0)
 r.Store(out[i : i+lanes]) // 출력 슬라이스의 해당되는 인덱스에 결과값을 저장
 }
 for ; i < len(x); i++ { // lane 수만큼 딱 떨어지지 않고 남은 항목에 대해 계산
 v := x[i]
 out[i] = ((0.5*v+1.2)*v-3.1)*v + 0.7
 }
}

처음에 이 코드를 보면 좀 복잡할 수 있습니다. 저는 상당히 복잡하다고 느꼈었거든요… 그럼 한 줄씩 천천히 가보겠습니다.

//go:build goexperiment.simd

첫 줄의 //go:build goexperiment.simd 는 이 코드가 빌드되는 환경에서 goexperiment.simd 태그가 설정되어있다면 이 파일을 포함하고 아니면 제외하라는 의미입니다. 이 파일에는 SIMD를 사용하는 코드가 작성되어있으니, simd 활성화가 되지 않은 환경에서는 아예 제외하라는 의미인거죠. 환경을 설정하는 과정에서 GOEXPERIMENT=simd go1.27rc2 ... 형식으로 설정을 확인했었는데요. GOEXPERIMENT=simd 이 환경변수가 goexperiment.simd 태그를 활성화 하게 됩니다.

그러면 저 환경변수가 없을 때는 어떻게 될까요? kernel_simd.go 가 빌드에 포함되지 않으니까 빌드 오류가 발생하지 않을까요? 맞습니다. 오류가 발생하죠! 그래서 simd 활성화가 되지 않은 환경을 위해 잠시 뒤에 kernel_stub.go 를 추가하게 됩니다. 잠시 뒤에 다시 알아보죠.

import "simd"

다음으로는 simd 패키지를 임포트합니다. 참고로 simd/archsimd 패키지도 있는데요, 그건 1.26 버전에 AMD64 전용으로 추가된 패키지입니다. arm64에서는 1.27이상에서 제공하는 simd 패키지를 써야 하죠.

4-1. SumSIMDSingle 함수

func SumSIMDSingle(x []float32) float32 {
 var acc simd.Float32s // accumulator vector. 실행 환경이 지원하는 SIMD lane 수만큼 누적 슬롯을 가진다. 초깃값은 Mac의 경우 [0, 0, 0, 0]
 lanes := acc.Len() // NEON은 4, AVX는 8 또는 16

 i := 0
 for ; i+lanes <= len(x); i += lanes { // lane 수만큼 딱 떨어지는 구간을 동시에 계산
 acc = acc.Add(simd.LoadFloat32s(x[i : i+lanes])) // 주어진 슬라이스에서 lane 수만큼 잘라서 각 lane별로 누적
 }

 var tmp [16]float32 // 스택에 배열을 생성(AVX512의 경우 최대 float32를 16개 담을 수 있으므로 최댓값으로 생성)
 acc.Store(tmp[:lanes]) // 각 lane의 값을 배열에 저장
 var s float32
 for j := 0; j < lanes; j++ { // 모든 lane의 결과 값을 더하기
 s += tmp[j]
 }

 for ; i < len(x); i++ { // lane 수로 딱 떨어지지 않고 남았던 인덱스에 대해 계산
 s += x[i]
 }
 return s
}

이 글에서 다루는 첫 번째 SIMD 구현입니다! 이 함수에서도, 그리고 이후로도 simd.Float32s 타입이 중점적으로 쓰이기 때문에 별도로 설명을 하고 넘어가겠습니다.

위 코드를 보면, simd.Float32s에 대해서 accumulator vector라고 적어뒀습니다. accumulator는 뭔가 누적해서 담아두는 걸 말하니까 단어의 뜻은 알겠는데 “vector"는 뭘까요?

여기서 vector는 수학 시간에 이야기하던, 크기와 방향을 가진 화살표가 아니라 같은 타입의 숫자 여러 개를 한 줄로 나란히 담은 묶음입니다. CPU에는 이 묶음을 통째로 담는 넓은 레지스터(vector register)가 있고, SIMD 명령 1개는 묶음 전체에 같은 연산을 한 번에 적용합니다. 계란판에 담긴 계란 4개가 같이 이동하고 같이 계산된다고 생각하면 됩니다. 이때 계란판의 칸 하나하나를 lane이라고 부릅니다.

simd.Float32s는 이 vector register 하나를 Go 타입으로 나타낸 것입니다.

NEON(128비트, 맥): [ f32 | f32 | f32 | f32 ] Len() = 4
AVX2(256비트): [ f32 | f32 | f32 | f32 | f32 x 4 ] Len() = 8
AVX-512(512비트): [ f32 x 16 ] Len() = 16

이 타입의 특징은 4가지입니다.

이름에 개수가 없습니다. 하나의 레지스터에 몇 개의 float32가 들어갈지는 하드웨어가 정하기 때문인데요, 그래서 Len()으로 물어봐야 합니다. 맥(NEON)은 4, AVX2는 8, AVX-512는 16입니다. Float32s를 쓰면 같은 코드가 어느 CPU에서든 그 CPU에서 지원하는 레지스터의 크기로 설정됩니다.
슬라이스가 아니라 값입니다. 크기가 고정이라 힙 할당이 없고, 컴파일러가 가능하면 변수를 레지스터에 그대로 둡니다. 루프 내내 메모리를 오가지 않는 것이 SIMD 성능의 핵심입니다.
메서드 하나가 명령 하나입니다. a.Add(b)는 덧셈 4개를 동시에 수행하는 명령 1개입니다. 이때 lane 0은 lane 0끼리, lane 1은 lane 1끼리만 더해지고 lane 사이에는 아무 교류가 없습니다.
zero value는 모든 lane이 0.0입니다. 그래서 var acc simd.Float32s 선언만으로 누적 계산을 시작할 준비가 끝납니다.

지금까지의 내용을 그림 하나로 정리하면 이렇습니다.

이제 simd.Float32s를 이해했기 때문에 이 함수를 이해할 수 있는 준비가 됐습니다! 위 함수가 하는 일은

accumulator vector 준비
lane 수 만큼 x를 잘라서 SIMD로 누적 계산
accumulator vector의 계산 결과를 배열에 저장
배열에 저장된 각 lane의 계산 결과를 합산
lane 수로 나눠서 딱 떨어지지 않고 남은 x의 요소들을 별도로 합산

생각보다 간단하죠? 이 흐름을 애니메이션으로 보면 더 명확합니다. 12개짜리 슬라이스가 4개씩 레지스터로 올라가고, lane마다 부분합이 쌓이고, 마지막에 부분합 4개가 하나로 합쳐집니다.

4-2. SumSIMDUnrolled4 함수

func SumSIMDUnrolled4(x []float32) float32 {
 var a0, a1, a2, a3 simd.Float32s // 4개의 accumulator vector를 생성
 lanes := a0.Len() // vector 하나가 담는 lane 수 확인
 step := lanes * 4 // 4개의 accumulator vector -> Mac의 경우 4 * 4 => 16

 i := 0
 for ; i+step <= len(x); i += step { // step 단위로 딱 떨어지는 구간을 계산 (Mac은 한 번에 16개)
 a0 = a0.Add(simd.LoadFloat32s(x[i : i+lanes])) // 각 accumulator vector에 lane 수만큼 끊어서 누적
 a1 = a1.Add(simd.LoadFloat32s(x[i+lanes : i+2*lanes]))
 a2 = a2.Add(simd.LoadFloat32s(x[i+2*lanes : i+3*lanes]))
 a3 = a3.Add(simd.LoadFloat32s(x[i+3*lanes : i+4*lanes]))
 }

 // step만큼 끊고 남은 나머지 중에서 lane 수만큼 끊을 수 있는 구간을 계산
 for ; i+lanes <= len(x); i += lanes {
 a0 = a0.Add(simd.LoadFloat32s(x[i : i+lanes]))
 }

 // (a0+a1)과 (a2+a3)를 먼저 묶어서 안쪽 Add 두 개가 겹쳐 실행되게 한다
 acc := a0.Add(a1).Add(a2.Add(a3))

 var tmp [16]float32 // 스택에 배열을 생성(AVX512의 경우 최대 float32를 16개 담을 수 있으므로 최댓값으로 생성)
 acc.Store(tmp[:lanes])
 var s float32
 for j := 0; j < lanes; j++ {
 s += tmp[j]
 }

 for ; i < len(x); i++ {
 s += x[i]
 }
 return s
}

SumSIMDSingle로 이미 4개씩 동시에 더하고 있는데, 여기서 더 빨라질 수 있을까요? 있습니다. 사실 SumSIMDSingle에는 SumScalar에서 봤던 비효율이 그대로 남아있거든요.

acc = acc.Add(...) 는 앞선 Add의 결과가 나와야 다음 Add를 시작할 수 있습니다. vector 덧셈도 결국 덧셈이라 3-4 사이클을 소비하는데요, 그래서 매 루프마다 CPU가 앞선 vector 덧셈이 끝나기를 기다리게 됩니다. SumScalar의 대기 문제가 vector 세계에서 똑같이 재현된 거죠.

해법도 이미 알고 있습니다. SumUnrolled4에서 썼던 트릭을 vector에 그대로 적용하는 겁니다. 서로 독립적인 accumulator vector를 4개 만들어서 기다림 없이 겹쳐 실행되게 하는 거죠. 말하자면 SumUnrolled4의 SIMD 버전인 셈입니다.

accumulator 1개: Add ──▶ Add ──▶ Add ──▶ Add ──▶ ... (앞 결과를 기다린다)

accumulator 4개: a0: Add ───▶ Add ───▶ ...
 a1: Add ───▶ Add ───▶ ...
 a2: Add ───▶ Add ───▶ ...
 a3: Add ───▶ Add ───▶ ... (4개의 연산이 기다림 없이 진행된다)

그래서 이 함수의 루프는 한 번에 step(= lanes * 4, 맥에서는 16개)만큼 전진합니다. 연속된 4개 구간을 각자의 accumulator에 나눠 담는 거죠.

한 바퀴 (i = 0, 맥 기준):
x: [ x0~x3 ][ x4~x7 ][ x8~x11 ][ x12~x15 ]
 ↓a0 ↓a1 ↓a2 ↓a3 ← 4개의 Add가 겹쳐서 실행

그리고 SumSIMDSingle에는 없던 루프가 하나 추가됐는데요, 16개 단위로 끊고 남은 나머지 중에서 4개 단위로 끊을 수 있는 구간을 처리하는 중간 단계입니다. 이 구간은 a0에 몰아서 누적합니다. 많아야 3번 도는 루프라서 accumulator 1개로도 충분하거든요.

마지막 합치기에도 눈여겨볼 부분이 있습니다. a0.Add(a1).Add(a2.Add(a3)) 는 (a0+a1)과 (a2+a3)를 먼저 계산하는 균형 트리 모양인데요, 이렇게 하면 안쪽 Add 2개도 서로 독립이라 겹쳐 실행됩니다. 마지막까지 기다림을 줄이는 거죠.

정리하면 이 함수가 하는 일은 다음과 같습니다.

accumulator vector 4개 준비
step(16개) 단위로 x를 잘라서 accumulator 4개에 겹쳐서 누적
남은 구간 중 lane 수만큼 끊을 수 있는 구간은 a0에 누적
accumulator 4개를 균형 트리로 하나로 합치기
이후는 SumSIMDSingle과 동일 (배열에 저장 → lane 합산 → 나머지 합산)

구조가 SumUnrolled4 + SumSIMDSingle 이라는 게 보이시죠? 전체 흐름을 애니메이션으로 보면 이렇습니다. 20개짜리 슬라이스가 한 바퀴에 16개씩 accumulator 4개로 나눠 담기고, 남은 4개는 중간 단계에서 a0에 더해진 뒤, 균형 트리로 하나로 합쳐집니다.

실제로 얼마나 빨라졌는지는 잠시 뒤 벤치마크에서 확인해 보겠습니다.

4-3. SumSIMDUnrolled8 함수

이 함수는 8개의 accumulator vector를 동시에 사용하면 4개보다 얼마나 빨라질까…를 테스트해보기 위해서 만들었습니다.

구조는 Unrolled4와 동일하기 때문에 설명은 생략하겠습니다!

4-4. PolySIMD 함수

마지막으로 두 번째 연산 커널, 삼차 다항식의 SIMD 버전입니다. 그런데 이 함수를 보기 전에 먼저 봐야 할 함수가 하나 있습니다. 바로 splat 함수입니다.

// splat은 모든 lane을 v로 채운 vector를 만든다.
// hot loop 밖에서만 호출하므로 이 작은 루프의 비용은 무시해도 된다.
func splat(v float32, lanes int) simd.Float32s {
 b := make([]float32, lanes)
 for i := 0; i < lanes; i++ {
 b[i] = v
 }
 return simd.LoadFloat32s(b[:lanes])
}

왜 이런 함수가 필요할까요? 다항식 계산에는 0.5, 1.2 같은 상수 계수가 등장하는데요, vector의 Mul과 Add는 양쪽 모두 vector여야 합니다. 계란판과 계란 1개를 곱할 수는 없는 거죠. 그래서 상수 하나를 모든 lane에 복사해서 [0.5, 0.5, 0.5, 0.5] 같은 vector로 만들어야 하는데, 이 작업을 하는 함수가 splat입니다.

splat은 “철퍼덕 퍼뜨린다"는 뜻으로 SIMD 관련해서 자주 쓰인다고 합니다. broadcast라고도 한다네요.

슬라이스를 만들고 작은 루프를 돌긴 하지만, 잠시 뒤에 보듯 hot loop(빡세게 도는 루프) 밖에서 계수당 1번씩만 호출되기 때문에 무시해도 됩니다. splat이 하는 일을 그림으로 보면 이렇습니다.

// 호너의 방법을 사용하여 거듭제곱 계산을 (곱셈, 덧셈)의 조합으로 변환
// 0.5v³ + 1.2v² − 3.1v + 0.7
// = v(0.5v² + 1.2v − 3.1) + 0.7
// = v(v(0.5v + 1.2) − 3.1) + 0.7
// = ((0.5v + 1.2)·v − 3.1)·v + 0.7
func PolySIMD(x, out []float32) {
 var probe simd.Float32s
 lanes := probe.Len() // lane 수를 확인하는 용도로만 사용

 // 4개의 다항식 계수를 lane 수만큼 펼쳐서 레지스터에 로드(ex: [0.5, 0.5, 0.5, 0.5])
 c3 := splat(0.5, lanes)
 c2 := splat(1.2, lanes)
 c1 := splat(-3.1, lanes)
 c0 := splat(0.7, lanes)

 i := 0
 for ; i+lanes <= len(x); i += lanes {
 v := simd.LoadFloat32s(x[i : i+lanes]) // 레지스터에 lane 수만큼 로드
 r := c3.Mul(v).Add(c2) // c3 * v + c2 => [0.5*v1+1.2, ... , 0.5*v4+1.2]
 r = r.Mul(v).Add(c1)
 r = r.Mul(v).Add(c0)
 r.Store(out[i : i+lanes]) // 출력 슬라이스의 해당되는 인덱스에 결과값을 저장
 }
 for ; i < len(x); i++ { // lane 수만큼 딱 떨어지지 않고 남은 항목에 대해 계산
 v := x[i]
 out[i] = ((0.5*v+1.2)*v-3.1)*v + 0.7
 }
}

함수 위의 주석은 PolyScalar에서 봤던 호너의 방법 그대로입니다. 거듭제곱 없이 (곱하고 더하기) 3단계로 삼차 다항식을 계산하는 거죠. 이 3단계가 SIMD와 만나면 각 단계가 lane 4개를 동시에 처리하게 됩니다.

코드를 위에서부터 따라가 보겠습니다.

먼저 probe는 계산에는 전혀 쓰이지 않는 변수입니다. Len()을 물어보는 용도로만 존재하죠. 그 다음 계수 4개를 splat으로 미리 vector로 펼쳐 둡니다. 루프 밖에서 딱 1번씩만 호출되고, 루프 안에서는 이미 레지스터에 준비된 상수 vector를 가져다 쓰기만 하면 됩니다.

메인 루프는 이렇게 한 번씩 돌아갑니다.

한 바퀴 (맥 기준):
v: [ v0 | v1 | v2 | v3 ] ← x[i:i+4]를 로드
1단계: r = c3·v + c2 (lane 4개 동시)
2단계: r = r·v + c1
3단계: r = r·v + c0
Store: [ f(v0) | f(v1) | f(v2) | f(v3) ] → out[i:i+4]에 기록

lane 0은 v0만으로, lane 1은 v1만으로 자기 다항식을 계산합니다. Add에서 봤던 것과 똑같이 lane 사이에는 아무 교류가 없는 거죠.

그런데 Sum 함수들과 비교해보면 구조가 눈에 띄게 다릅니다. 3가지가 없거든요.

accumulator가 없습니다. v와 r은 매번 새로 만들어지고 해당 반복이 끝나면 사라집니다. 각 반복 사이에 이어지는 값이 없는 거죠.
horizontal reduction이 없습니다. 결과를 Store로 out에 바로 내려쓰면 끝입니다. lane끼리 합칠 일이 없으니까요.
unrolled 버전이 없습니다. 4-2에서 봤던 대기 문제는 이전 계산의 결과를 기다릴 때 생기는데, 이 루프는 각 반복 사이에 의존성이 없습니다. 그래서 accumulator를 늘리지 않아도 CPU가 알아서 여러 반복을 겹쳐 실행합니다.

그러고 나면 마지막으로 동일한 계산식으로 나머지 요소들을 계산합니다.

전체 흐름을 애니메이션으로 보면 이렇습니다. 미리 준비된 계수 vector 4개 아래로, 4개씩 로드 → 호너 3단계 → out에 기록이 반복됩니다. 각 단계에서 사용되는 계수가 주황색으로 표시됩니다.

정리하면 이 함수가 하는 일은 다음과 같습니다.

계수 4개를 splat으로 vector화 (루프 밖에서 1번)
lane 수만큼 로드해서 호너의 방법 3단계로 계산
결과를 out에 바로 저장
남은 원소는 같은 모양의 스칼라 코드로 계산

Sum보다 오히려 단순하죠? 이제 SIMD 커널은 모두 준비되었습니다.

5. 대체 커널 구현하기(kernel_stub.go)

4번 섹션 초반에 다시 돌아온다고 이야기 했던 바로 그 부분입니다. GOEXPERIMENT=simd 없이 빌드하면 kernel_simd.go가 통째로 빠지면서 SumSIMDSingle 같은 함수들이 존재하지 않게 되고, 이 함수들을 부르는 코드는 전부 컴파일 오류가 난다고 했었죠. 그 구멍을 메우는 파일이 kernel_stub.go입니다.

//go:build !goexperiment.simd

package kernels

func SumSIMDUnrolled8(x []float32) float32 { return SumUnrolled4(x) }
func SumSIMDUnrolled4(x []float32) float32 { return SumUnrolled4(x) }
func SumSIMDSingle(x []float32) float32 { return SumUnrolled4(x) }
func PolySIMD(x, out []float32) { PolyScalar(x, out) }

첫 줄의 build tag를 보면 !goexperiment.simd, kernel_simd.go와 정확히 반대 조건입니다. 그래서 어떤 환경에서 빌드하든 두 파일 중 정확히 하나만 빌드에 포함됩니다.

GOEXPERIMENT=simd 있음: kernel_simd.go ✓ kernel_stub.go ✗ → 진짜 SIMD
GOEXPERIMENT=simd 없음: kernel_simd.go ✗ kernel_stub.go ✓ → 스칼라 fallback

내용은 아주 단순합니다. SIMD 함수들과 같은 이름의 함수를 선언하고, 몸통에서는 우리가 가진 가장 빠른 스칼라 버전(SumUnrolled4, PolyScalar)을 그대로 호출합니다. 덕분에 SIMD를 지원하지 않는 환경에서도 컴파일이 항상 성공하고, 호출하는 쪽은 아무것도 바꿀 필요가 없죠.

한 가지 조심할 점이 있는데요, 이 파일 덕분에 GOEXPERIMENT=simd를 빼먹어도 아무 오류 없이 잘 돌아갑니다. “SIMD가 생각보다 안 빠른데?” 싶으면 환경변수부터 확인해보세요!

6. 테스트 작성하기(kernel_test.go)

커널이 다 모였으니 이제 두 가지를 확인해야 합니다. 정답을 내는가(test), 그리고 얼마나 빠른가(benchmark). 순서는 아무래도 정확성이 우선이겠죠?

package kernels

import (
 "fmt"
 "math"
 "math/rand/v2"
 "testing"
)

func data(n int) []float32 {
 x := make([]float32, n)
 for i := range x {
 x[i] = rand.Float32()
 }
 return x
}

// 정확성 우선. 허용 오차를 두는 이유: SIMD는 스칼라와 다른 순서로 더하므로
// 완전히 같은 값을 기대하는 검증은 잘못된 검증이다.
func TestSumImplsMatchScalar(t *testing.T) {
 impls := []struct {
 name string
 fn func([]float32) float32
 }{
 {"unrolled4", SumUnrolled4},
 {"simd-single", SumSIMDSingle},
 {"simd-unrolled4", SumSIMDUnrolled4},
 {"simd-unrolled8", SumSIMDUnrolled8},
 }
 // 모든 분기를 지나도록 길이를 고른다.
 // 32의 배수는 8-vector 본 루프만, 그 사이 값은 중간 단계와 스칼라 tail을 지난다.
 // 0과 1은 본 루프에 한 번도 들어가지 않는 극단값이다.
 for _, n := range []int{0, 1, 3, 4, 5, 7, 8, 15, 16, 17, 31, 32, 33, 63, 64, 65, 1000, 10_037} {
 x := data(n)
 want := SumScalar(x)
 for _, impl := range impls {
 t.Run(fmt.Sprintf("%s/n=%d", impl.name, n), func(t *testing.T) {
 got := impl.fn(x)
 // 상대 오차 1%에 절대 오차 1e-6을 더한다. 합이 0에 가까운 극단값 대비.
 if math.Abs(float64(want-got)) > 1e-2*math.Abs(float64(want))+1e-6 {
 t.Errorf("scalar=%v got=%v", want, got)
 }
 })
 }
 }
}

func BenchmarkSum(b *testing.B) {
 for _, n := range []int{1024, 65536, 1 << 20} {
 x := data(n)
 for _, impl := range []struct {
 name string
 fn func([]float32) float32
 }{
 {"scalar", SumScalar},
 {"unrolled4", SumUnrolled4},
 {"simd-single", SumSIMDSingle},
 {"simd-unrolled4", SumSIMDUnrolled4},
 {"simd-unrolled8", SumSIMDUnrolled8},
 } {
 b.Run(fmt.Sprintf("%s/n=%d", impl.name, n), func(b *testing.B) {
 b.SetBytes(int64(n * 4)) // → MB/s in the output
 for b.Loop() { // Go 1.24+: keeps the call alive
 impl.fn(x)
 }
 })
 }
 }
}

func BenchmarkPoly(b *testing.B) {
 for _, n := range []int{1024, 65536, 1 << 20} {
 x, out := data(n), make([]float32, n)
 b.Run(fmt.Sprintf("scalar/n=%d", n), func(b *testing.B) {
 b.SetBytes(int64(n * 4))
 for b.Loop() {
 PolyScalar(x, out)
 }
 })
 b.Run(fmt.Sprintf("simd/n=%d", n), func(b *testing.B) {
 b.SetBytes(int64(n * 4))
 for b.Loop() {
 PolySIMD(x, out)
 }
 })
 }
}

data 함수는 랜덤 float32 슬라이스를 만드는 도우미입니다. 테스트와 벤치마크가 같이 씁니다.

TestSumImplsMatchScalar는 Sum 구현 4개를 전부 SumScalar와 비교하는 테스트입니다. 가장 단순한 SumScalar를 정답지로 삼는 거죠. 눈여겨볼 부분이 2가지 있습니다.

다양한 길이의 데이터를 사용합니다. 0, 1, 17, 33 같은 값이 섞여 있는 이유는 모든 분기를 지나가게 만들기 위해서입니다. 32의 배수는 Unrolled8의 본 루프만 지나가고, 어중간한 값은 중간 단계와 스칼라 tail까지 지나갑니다. 0과 1은 vector 루프에 한 번도 못 들어가는 극단값이고요.
완전히 같은 값이 아니라 허용 오차로 비교합니다. float 덧셈은 더하는 순서가 바뀌면 마지막 자리가 조금 달라질 수 있습니다(결합법칙이 성립하지 않습니다). SIMD는 스칼라와 더하는 순서가 다르니까 == 비교는 잘못된 검증인 거죠. 그래서 상대 오차 1%에, 합이 0에 가까운 경우를 대비한 절대 오차 1e-6(0.000001)을 더해서 비교합니다.

BenchmarkSum은 구현 5개 × 크기 3개 = 15개의 서브벤치마크를 만듭니다. 크기 3개는 cache에 쏙 들어가는 1024부터 cache를 벗어나는 100만 개까지, 메모리 계층이 달라지는 구간을 골랐습니다.

b.Run에 붙인 이름이 결과에 BenchmarkSum/scalar/n=1024 형태로 그대로 나타납니다.
b.SetBytes(n*4)는 1번 호출이 n×4 바이트를 처리한다고 알려주는 겁니다. 이 덕분에 결과에 MB/s 컬럼이 붙어서 크기가 다른 벤치마크끼리도 처리량으로 비교할 수 있습니다.
for b.Loop()는 Go 1.24에 추가된 벤치마크 루프입니다. 정해진 시간(기본 1초)이 찰 때까지 알아서 반복하고, 반환값을 안 쓰더라도 컴파일러가 호출 자체를 없애버리지 않도록 지켜줍니다.

BenchmarkPoly도 같은 패턴입니다. out 슬라이스를 벤치마크 루프 밖에서 만들어 재사용하기 때문에 측정값에 메모리 할당 비용이 섞이지 않습니다.

이제 정말로 돌려볼 시간입니다!

테스트와 벤치마크 돌려보기

먼저 테스트를 돌려볼까요?

> GOEXPERIMENT=simd go1.27rc2 test -run=Test -v ./...
=== RUN TestSumImplsMatchScalar
=== RUN TestSumImplsMatchScalar/unrolled4/n=0
=== RUN TestSumImplsMatchScalar/simd-single/n=0
=== RUN TestSumImplsMatchScalar/simd-unrolled4/n=0
=== RUN TestSumImplsMatchScalar/simd-unrolled8/n=0
=== RUN TestSumImplsMatchScalar/unrolled4/n=1
=== RUN TestSumImplsMatchScalar/simd-single/n=1
=== RUN TestSumImplsMatchScalar/simd-unrolled4/n=1
=== RUN TestSumImplsMatchScalar/simd-unrolled8/n=1
=== RUN TestSumImplsMatchScalar/unrolled4/n=3
=== RUN TestSumImplsMatchScalar/simd-single/n=3
=== RUN TestSumImplsMatchScalar/simd-unrolled4/n=3
=== RUN TestSumImplsMatchScalar/simd-unrolled8/n=3
...
=== RUN TestSumImplsMatchScalar/unrolled4/n=10037
=== RUN TestSumImplsMatchScalar/simd-single/n=10037
=== RUN TestSumImplsMatchScalar/simd-unrolled4/n=10037
=== RUN TestSumImplsMatchScalar/simd-unrolled8/n=10037
--- PASS: TestSumImplsMatchScalar (0.00s)
 --- PASS: TestSumImplsMatchScalar/unrolled4/n=0 (0.00s)
 --- PASS: TestSumImplsMatchScalar/simd-single/n=0 (0.00s)
 --- PASS: TestSumImplsMatchScalar/simd-unrolled4/n=0 (0.00s)
 --- PASS: TestSumImplsMatchScalar/simd-unrolled8/n=0 (0.00s)
 --- PASS: TestSumImplsMatchScalar/unrolled4/n=1 (0.00s)
 --- PASS: TestSumImplsMatchScalar/simd-single/n=1 (0.00s)
 --- PASS: TestSumImplsMatchScalar/simd-unrolled4/n=1 (0.00s)
 --- PASS: TestSumImplsMatchScalar/simd-unrolled8/n=1 (0.00s)
 --- PASS: TestSumImplsMatchScalar/unrolled4/n=3 (0.00s)
 --- PASS: TestSumImplsMatchScalar/simd-single/n=3 (0.00s)
 --- PASS: TestSumImplsMatchScalar/simd-unrolled4/n=3 (0.00s)
 --- PASS: TestSumImplsMatchScalar/simd-unrolled8/n=3 (0.00s)
 ...
 --- PASS: TestSumImplsMatchScalar/unrolled4/n=10037 (0.00s)
 --- PASS: TestSumImplsMatchScalar/simd-single/n=10037 (0.00s)
 --- PASS: TestSumImplsMatchScalar/simd-unrolled4/n=10037 (0.00s)
 --- PASS: TestSumImplsMatchScalar/simd-unrolled8/n=10037 (0.00s)
PASS
ok simdbench (cached)

다양한 경우의 수에 대해서 모든 테스트가 통과하는 걸 볼 수 있습니다. 코드가 정확한 걸 확인했으니 이제 벤치마크를 돌려봅시다!

> GOEXPERIMENT=simd go1.27rc2 test -bench=. -benchmem ./...
goos: darwin
goarch: arm64
pkg: simdbench
cpu: Apple M5 Pro
BenchmarkSum/scalar/n=1024-18 2244930 532.5 ns/op 7691.73 MB/s 0 B/op 0 allocs/op
BenchmarkSum/unrolled4/n=1024-18 4383312 273.3 ns/op 14985.48 MB/s 0 B/op 0 allocs/op
BenchmarkSum/simd-single/n=1024-18 8875933 134.0 ns/op 30566.12 MB/s 0 B/op 0 allocs/op
BenchmarkSum/simd-unrolled4/n=1024-18 19148451 62.21 ns/op 65842.86 MB/s 0 B/op 0 allocs/op
BenchmarkSum/simd-unrolled8/n=1024-18 20095088 59.71 ns/op 68592.91 MB/s 0 B/op 0 allocs/op
BenchmarkSum/scalar/n=65536-18 31131 38428 ns/op 6821.65 MB/s 0 B/op 0 allocs/op
BenchmarkSum/unrolled4/n=65536-18 62958 19042 ns/op 13766.93 MB/s 0 B/op 0 allocs/op
BenchmarkSum/simd-single/n=65536-18 122510 9654 ns/op 27153.36 MB/s 0 B/op 0 allocs/op
BenchmarkSum/simd-unrolled4/n=65536-18 318691 3733 ns/op 70220.68 MB/s 0 B/op 0 allocs/op
BenchmarkSum/simd-unrolled8/n=65536-18 332295 3638 ns/op 72056.81 MB/s 0 B/op 0 allocs/op
BenchmarkSum/scalar/n=1048576-18 1942 613160 ns/op 6840.47 MB/s 0 B/op 0 allocs/op
BenchmarkSum/unrolled4/n=1048576-18 3706 308846 ns/op 13580.58 MB/s 0 B/op 0 allocs/op
BenchmarkSum/simd-single/n=1048576-18 7534 159293 ns/op 26330.67 MB/s 0 B/op 0 allocs/op
BenchmarkSum/simd-unrolled4/n=1048576-18 19327 61679 ns/op 68001.61 MB/s 0 B/op 0 allocs/op
BenchmarkSum/simd-unrolled8/n=1048576-18 20790 57774 ns/op 72597.91 MB/s 0 B/op 0 allocs/op
BenchmarkPoly/scalar/n=1024-18 3528297 340.6 ns/op 12024.97 MB/s 0 B/op 0 allocs/op
BenchmarkPoly/simd/n=1024-18 6932178 172.9 ns/op 23692.89 MB/s 0 B/op 0 allocs/op
BenchmarkPoly/scalar/n=65536-18 55312 21780 ns/op 12036.22 MB/s 0 B/op 0 allocs/op
BenchmarkPoly/simd/n=65536-18 113785 10453 ns/op 25077.27 MB/s 0 B/op 0 allocs/op
BenchmarkPoly/scalar/n=1048576-18 3398 349927 ns/op 11986.24 MB/s 0 B/op 0 allocs/op
BenchmarkPoly/simd/n=1048576-18 7154 168198 ns/op 24936.76 MB/s 0 B/op 0 allocs/op
PASS
ok simdbench 25.564s

결과 한 줄 해부하기

처음 보면 숫자가 잔뜩이라 어지러운데요, 한 줄만 잘라서 보면 구조가 단순합니다.

BenchmarkSum/scalar/n=1024-18 2244930 532.5 ns/op 7691.73 MB/s 0 B/op 0 allocs/op
└──────────┬────────────┘└┬┘ └──┬──┘ └────┬────┘ └─────┬────┘ └─┬─┘ └────┬─────┘
 함수/서브벤치마크 이름 ① ② ③ ④ ⑤ ⑤

이름: BenchmarkSum 함수 아래에 b.Run으로 만든 서브벤치마크 이름이 그대로 붙습니다.
① -18: GOMAXPROCS 값입니다. 이 벤치마크를 실행 중인 맥의 CPU 코어가 18개라는 표시입니다.
② 반복 횟수: 측정 시간 동안 함수를 몇 번 호출했는지 센 값입니다. 설정값이 아니라 결과물인 거죠. b.Loop가 약 1.2초 동안 돌 수 있는 만큼 돌고 멈춘 겁니다. 실제로 2,244,930 × 532.5ns ≈ 1.2초가 나옵니다.
③ ns/op: 호출 1번에 걸린 시간인데요, 사실 이 부분 말고는 다 사족에 불과합니다!
④ MB/s: 초당 처리한 데이터 양입니다. b.SetBytes를 호출했기 때문에 붙는 컬럼이고, 크기가 다른 벤치마크끼리 비교할 때는 이 컬럼이 제일 편합니다.
⑤ B/op, allocs/op: -benchmem 옵션이 붙여주는 컬럼입니다. 호출 1번당 힙 할당량인데요, 전부 0인 이유는 커널들이 var tmp [16]float32처럼 스택 배열만 쓰기 때문입니다. 여기 0이 아닌 값이 보이면 측정에 할당 비용이 섞이고 있다는 신호입니다.

반복 횟수를 ops/sec로 읽으면 안 됩니다. 측정 창이 정확히 1초가 아니거든요. 속도 정보는 ns/op와 MB/s에 있고, 반복 횟수는 “몇 번의 호출을 바탕으로 ns/op와 MB/s를 도출했나"를 뜻합니다.

이렇게 읽고 나면 n=1024의 Sum 결과에서 속도가 개선되는 경향이 보입니다. 532 → 273 → 134 → 62 → 60 ns로, 단계마다 절반씩 줄어들다가 마지막에 멈칫하죠. 그런데 이 표는 각 벤치마크를 1번씩만 잰 겁니다. 1번의 측정은 동전 던지기 1번과 같아서, CPU 발열이나 백그라운드 작업에 따라 몇 %씩 쉽게 흔들립니다. 마지막에 멈칫 한게 진짜인지 아니면 뭔가가 개입해서 그런지는 명확하지 않은 거죠.

10번 재서 통계로 판정하기

그래서 제대로 잴 때는 -count=10으로 10번 반복하고, 결과를 파일로 저장합니다.

> GOEXPERIMENT=simd go1.27rc2 test -bench=. -count=10 ./... > result.txt

result.txt를 열어보면 같은 이름이 10줄씩, 조금씩 다른 숫자로 반복됩니다.

goos: darwin
goarch: arm64
pkg: simdbench
cpu: Apple M5 Pro
BenchmarkSum/scalar/n=1024-18 2344214 503.0 ns/op 8142.36 MB/s
BenchmarkSum/scalar/n=1024-18 2438886 492.0 ns/op 8324.60 MB/s
BenchmarkSum/scalar/n=1024-18 2422869 493.4 ns/op 8300.86 MB/s
BenchmarkSum/scalar/n=1024-18 2431774 493.6 ns/op 8298.66 MB/s
BenchmarkSum/scalar/n=1024-18 2439853 492.7 ns/op 8314.17 MB/s
...(이하 200여 줄 생략)...

벤치마크를 10번씩 실행하면 몇가지 잡음이 있더라도 분포를 통해 경향을 비교적 정확하게 파악할 수 있습니다.

결과가 말해주는 것

10개 표본의 중앙값으로 n=1024의 벤치 결과를 그려보면 이렇습니다.

scalar 492.7 ns ████ 8.3 GB/s
unrolled4 254.1 ns ████████ 16.1 GB/s ×1.94
simd-single 126.3 ns ████████████████ 32.4 GB/s ×2.01
simd-unrolled4 58.4 ns ███████████████████████████████ 70.2 GB/s ×2.16
simd-unrolled8 56.7 ns ████████████████████████████████ 72.2 GB/s ×1.03

각 단계가 병목을 하나씩 제거하면서 약 2배씩 빨라졌습니다.

단계	제거한 병목
scalar → unrolled4	덧셈 대기 사슬. 독립 accumulator 4개로 덧셈을 겹쳐 실행
unrolled4 → simd-single	명령 1개가 float32 1개만 처리하던 한계. lane 4개를 동시에 계산
simd-single → simd-unrolled4	vector 덧셈의 대기 사슬. accumulator vector 4개로 다시 겹침
simd-unrolled4 → simd-unrolled8	남은 병목이 거의 없음. 그래서 3~4%에 그침 (아래에서 설명)

크기별 처리량(GB/s, 중앙값)을 보면 또 하나 재미있는 점이 있습니다.

구현	n=1024	n=65536	n=1M	scalar 대비 (n=1M)
scalar	8.3	7.3	7.3	×1.0
unrolled4	16.1	14.6	14.4	×2.0
simd-single	32.4	28.3	28.2	×3.9
simd-unrolled4	70.2	71.7	70.9	×9.7
simd-unrolled8	72.2	74.4	73.9	×10.1

크기가 100만 개로 커져도(cache를 완전히 벗어나도) 처리량이 거의 그대로입니다. 병목이 memory가 아니라 계산 쪽에 있다는 뜻이죠. memory 대역폭이 한계였다면 n=1M에서 그래프가 뚝 꺾였을 겁니다.

그러면 4개 → 8개 unroll이 정말 이득이 있긴 한 걸까요? 이럴 때 쓰는 도구가 benchstat입니다. unrolled4 줄과 unrolled8 줄을 뽑아서 같은 이름으로 바꾼 파일 2개를 만들면, benchstat가 둘을 짝지어 통계 판정을 내려줍니다.

> grep 'simd-unrolled4' result.txt | sed 's|simd-unrolled4|X|' > u4.txt
> grep 'simd-unrolled8' result.txt | sed 's|simd-unrolled8|X|' > u8.txt
> benchstat u4.txt u8.txt

 unrolled4 unrolled8 delta
Sum/n=1024 58.35n → 56.67n -2.88% (p=0.000, n=10)
Sum/n=65536 3.655µ → 3.522µ -3.65% (p=0.000, n=10)
Sum/n=1048576 59.09µ → 56.71µ -4.03% (p=0.000, n=10)

p=0.000은 “이 차이가 우연일 확률이 사실상 0"이라는 뜻입니다. 그러니까 진짜 이득은 맞는데, 34%뿐인 거죠. 이유는 4-2에서 배운 원리 그대로입니다. 여러 accumulator는 CPU가 앞선 덧셈을 기다리는 동안만 일감을 주는데, 4개면 그 대기 시간이 이미 거의 다 채워집니다. 그 다음 한계는 CPU가 1 cycle에 발행할 수 있는 명령 수와 memory에서 데이터를 끌어오는 속도인데, accumulator를 늘려도 이 둘은 개선할 수 없습니다. 남은 34%는 루프 1바퀴가 32개를 처리하면서 비교/분기 비용이 절반으로 준 몫입니다. 즉, 합계 구하기의 경우 SIMD + 4개 accumulator 사용하기가 최적인 셈이죠.

Poly는 어떨까요?

구현	n=1024	n=65536	n=1M
scalar	12.1	12.3	12.2
simd	24.2	25.6	25.6

모든 크기에서 일관되게 약 2.1배입니다. lane이 4개인데 왜 4배가 안 될까요? 호너의 방법 3단계가 앞 단계의 결과에 의존하는 사슬이라서, vector 안에서도 대기가 남기 때문입니다. Sum에서 accumulator를 늘렸던 것처럼, 서로 다른 원소 묶음 여러 개를 겹쳐서 처리하는 unroll을 실험해볼 수 있을 것 같습니다.

후속 실험: Poly도 unroll 해보기

후보로만 남겨두면 아쉬우니 바로 실험해봤습니다. 한 번에 원소 묶음 4개(16개)를 처리하는 PolySIMDUnrolled4를 추가했는데요, 핵심은 연산을 원소별이 아니라 단계별로 묶는 겁니다. 이렇게 하면 매 단계마다 서로 독립적인 연산 4개를 CPU가 처리하게 됩니다.

 v0 := simd.LoadFloat32s(x[i : i+lanes]) // v1, v2, v3도 같은 방식으로 로드
 ...
 // 1단계 4개를 먼저 전부, 그 다음 2단계 4개, 3단계 4개 순서로
 r0 := c3.Mul(v0).Add(c2)
 r1 := c3.Mul(v1).Add(c2)
 r2 := c3.Mul(v2).Add(c2)
 r3 := c3.Mul(v3).Add(c2)

 r0 = r0.Mul(v0).Add(c1)
 // ... r1, r2, r3도 동일

Sum 때처럼 정확성 테스트(TestPolyImplsMatchScalar)를 먼저 통과시키고, -count=10으로 재서 benchstat로 판정했습니다.

 PolySIMD PolySIMDUnrolled4 delta
Poly/n=1024 169.0n → 160.6n -4.97% (p=0.000, n=10)
Poly/n=65536 10.358µ → 9.678µ -6.56% (p=0.000, n=10)
Poly/n=1048576 168.1µ → 154.4µ -8.15% (p=0.000, n=10)

5~~8% 빨라졌습니다. p=0.000이니 진짜 이득이고, Sum의 4개 → 8개(3~~4%)보다는 얻는 이익이 크긴 한데… 굳이? 싶은 느낌도 있긴 하네요.

참고로 PolySIMDUnrolled4의 전체 코드와 정확성 테스트(TestPolyImplsMatchScalar), 벤치마크 추가분은 이 글의 저장소 simdbench 폴더에 있습니다.

마지막 실험: core는 다 쓰고 있었을까?

여기까지 읽고 이런 의문이 들 수 있습니다. “SumSIMDUnrolled4가 이미 core를 다 쓰고 있는 거라면, 더 병렬화할 곳은 없을까?” 그런데 사실 지금까지의 모든 측정에는 함정이 하나 숨어 있습니다. 벤치마크 결과에 표시되던 -18은 GOMAXPROCS 표시일 뿐이고, 벤치마크는 goroutine 1개를 쓰고 있었습니다. 70 GB/s가 전부 core 1개의 처리량이었던 거죠.

지금까지는 2개의 병렬화 수단(accumulator로 명령을 겹치기, 그리고 lane 4개로 데이터를 겹치는 SIMD)을 이용했습니다. 그런데 둘 다 core 1개 안에서 일어나는 일이기 때문에 모든 코어를 다 활용하진 못했던 거죠. 이번에 확인할 마지막 SIMD 커널에서는 슬라이스를 core 수만큼 나눠서 goroutine마다 SumSIMDUnrolled4를 돌리고, 부분합을 하나로 합쳐볼 겁니다!

// SumSIMDParallel은 슬라이스를 core 수만큼 나눠서 goroutine마다 SumSIMDUnrolled4를 돌린다.
// SIMD(lane)와 ILP(accumulator)에 이어 세 번째 병렬화 요소인 core 병렬화를 추가하는 구현이다.
func SumSIMDParallel(x []float32) float32 {
 workers := runtime.GOMAXPROCS(0)
 // 작은 입력(65535 이하)는 goroutine을 만들고 기다리는 비용이 계산 비용보다 크다
 if len(x) < 1<<16 || workers == 1 {
 return SumSIMDUnrolled4(x)
 }

 // 각 워커가 처리해야 할 데이터의 크기
 // 남는 데이터가 발생하지 않도록 worker-1을 더하고 worker로 나눠준다.
 chunk := (len(x) + workers - 1) / workers
 // 각 worker의 출력을 저장할 슬라이스
 partial := make([]float32, workers)
 var wg sync.WaitGroup
 for w := 0; w < workers; w++ {
 lo := w * chunk
 // 남는 데이터가 발생하지 않도록 chunk의 크기를 조정했기 때문에, 후반부 작업에서는 worker의 시작 지점이 데이터의 길이를 넘어서는 경우가 있음.
 if lo >= len(x) {
 break
 }
 hi := min(lo+chunk, len(x))
 wg.Add(1)
 go func(w, lo, hi int) {
 defer wg.Done()
 partial[w] = SumSIMDUnrolled4(x[lo:hi])
 }(w, lo, hi)
 }
 wg.Wait()

 var s float32
 // 부분합을 모두 더하기
 for _, p := range partial {
 s += p
 }
 return s
}

위 코드에서 chunk를 나누는 부분이 헷갈릴 수 있는데요,(제가 그랬다는 겁니다…) 그림으로 보면 좀 더 명확합니다.

10개 입력에 대해서 3개의 worker가 작업을 나눠가질 때, 10/3을 해버리면 결과가 3이 되어서 9번 요소는 버려지는 상황이 되죠. 그래서 딱 떨어지는 경우를 제외하고 +1의 경계에 걸리도록 worker-1을 더해주고 나누도록 합니다. 뭐… 그렇답니다!

이 함수를 추가할 때는 kernel_simd.go의 import에 runtime과 sync를 추가해야 합니다. 측정에 쓴 벤치마크(BenchmarkSumBig)를 포함한 전체 코드는 이 글의 저장소 simdbench 폴더에 있습니다.

작은 입력에 core 병렬화를 걸면 비효율이 증가합니다. 그래서 큰 입력 2개(1M, 16M 원소)로 측정해봤는데요, 16M(64MB)은 cache를 완전히 벗어나 DRAM까지 내려가는 크기입니다.

 simd-unrolled4 simd-parallel
n=1M (4MB) 60.06µ → 28.55µ ×2.1 (p=0.000, n=10)
n=16M (64MB) 1003.3µ → 329.7µ ×3.0 (p=0.000, n=10)

처리량: 70 GB/s → 147 GB/s (n=1M) → 204 GB/s (n=16M)

core를 18개나 줬는데 3배밖에 안 빨라졌습니다. 왜일까요? 204 GB/s가 CPU core들이 실제로 끌어낼 수 있는 실효 대역폭 근처이기 때문입니다. core 1개가 이미 70 GB/s, 그러니까 실효 대역폭의 1/3을 혼자 끌어오고 있었던 겁니다. core가 18개라도 메모리가 데이터를 그보다 빨리 못 내주는 거죠.

앞에서 진행했던 single core 측정에서는 크기가 커져도 처리량이 안 꺾여서 계산 병목이라고 했었는데요, 정확히 말하면 “core 1개의 명령 발행 한계가 core 1개 몫의 메모리 대역폭보다 낮았던” 겁니다.

정리하면 병렬화의 축은 3개이고, 축마다 부딪히는 벽이 다릅니다.

축	기법	부딪히는 벽
ILP	accumulator 4개로 명령 겹치기	덧셈 latency → 명령 발행 폭
SIMD	lane 4개로 데이터 겹치기	명령 발행 폭
core	goroutine으로 나눠 돌리기	DRAM 대역폭

축 3개를 다 쌓으면 n=16M 기준 scalar 대비 약 27배입니다(scalar 처리량 7.3 GB/s로 환산하면 약 8.8ms → 330µs). 여기까지 하고 나면 더 적용할만한 방법은 없어보입니다. 데이터를 읽는 속도보다 빠르게 더할 수는 없으니까요.

정리하면 이번 측정의 교훈은 4가지입니다.

최적화는 병목을 제거할 때만 배수로 돌아옵니다. 병목이 사라진 뒤의 같은 기법은 몇 %짜리입니다.
몇 % 차이는 눈으로 판정할 수 없습니다. -count=10과 benchstat의 p 값이 근거입니다.
벤치마크가 빠르다는 것과 결과가 맞다는 것은 별개입니다. 정확성 테스트가 벤치마크보다 먼저입니다.
병렬화의 축은 3개입니다(ILP, SIMD, core). 그리고 마지막 벽은 memory 대역폭입니다. 데이터를 읽는 속도보다 빠르게 계산할 수는 없습니다.

마치면서

생각보다 복잡한 과정이긴 했지만, 그래도 SIMD가 뭐다 정도는 이해를 한 거 같습니다. 곧 까먹긴 하겠지만요…하하하하하…

참고자료

go를 알아보자(3) - 포인터

Mon, 25 May 2026 08:46:28 +0900

아주 오래전, 중학생이었던 제가 혼자서 C를 공부했던 시절이 있었습니다. 터보C 2.0 컴파일러와 안녕하세요 터보C 라는 책을 하나 들고 열심히 공부를 했습니다. 그때 당시엔 함수라는 개념을 도저히 이해할 수 없었습니다. 그리고 시간이 1-2년 지나서 그 책을 다시 집어 들고 공부를 했지만 이번엔 포인터, 구조체의 개념을 도저히 이해할 수 없었던 기억이 납니다. 그리고 포인터는 대학교 2학년이 되어서야 제대로(??? 그러니까 한 2차원 배열을 다룰 정도?) 이해할 수 있었습니다.

그리고는 그 당시 베타 버전이 출시되던 닷넷(.NET)으로 넘어가면서 포인터와의 악연은 막을 내렸죠. 그런데 말입니다…

최근에 작업을 Go로 하려다보니… 어쩔 수 없이 다시 포인터를 마주하게 됩니다. 20년도 더 지나서 포인터를 다시 보니 너무 헷갈려서 머리가 빙빙 돌더군요. 그래서 저를 위해서 포인터를 다시 한 번 정리해보자, 하는 하찮은 이유로 그냥 정리해봅니다. 미래의 저를 위해서!

포인터…

포인터는 말 그대로 그냥 어느 한 지점을 가리키는 걸 말합니다. 포인터는 두 개의 특수기호 *, & 가 연관되어 있는데요, 우선 *는 어디에서 사용되느냐에 따라 의미가 다릅니다.

타입의 앞에 붙은 경우(ex: *bool) -> 메모리에서 해당 타입의 값이 위치하는 곳을 가리키는 포인터
표현식에서 사용된 경우(ex: *isActive) -> 포인터가 가리키는 지점에 위치한 값, 참조 해제(포인터->실제 값)

그리고 &는 메모리의 주소를 가져오는 연산자로, 변수나 구조체등에 붙이게 되면 값이 위치한 메모리의 주소를 리턴합니다.

다음 예시를 볼까요?

var b bool = true // bool 타입의 변수 b에 true를 설정 -> 메모리의 어딘가 변수 b가 할당됨
var p *bool = &b // 변수 b의 메모리 주소를 bool타입의 포인터 p에 할당
fmt.Println(p) // 포인터 p가 가리키는 -> 변수 b의 메모리 주소가 출력됨(ex: 0xc0000140a0)
fmt.Println(*p) // 포인터 p가 가리키는 -> 참조 해제 -> 변수 b의 값이 출력됨(true)

*p = false // 포인터 p가 가리키는 -> 변수 b의 값을 false로 변경
fmt.Println(b) // 변수 b의 값이 출력됨(false)

그림으로 보면 이렇습니다.

메모리:
 ┌──────────────┐
변수 b 0xc000014090 │ true │ ◄──┬── *p (참조 해제 결과: true)
 └──────────────┘ │
 │ p가 가진 주소를
 │ 따라가서 도달
 ┌──────────────┐ │
포인터 p 0xc0000140a0 │0xc000014090 │ ───┘
 └──────────────┘ (&b로 얻은 주소를 값으로 가짐)

&b 는 변수 b가 위치한 메모리 주소(0xc000014090)를 얻어옵니다.
포인터 p는 그 주소를 자신의 값으로 가집니다.
*p 는 p가 가리키는 곳으로 따라가서 실제 값(true)을 가져옵니다.

간단해 보이지만, 두고두고 사람을 헷갈리게 만드는 요소입니다. 제가 그렇습니다.

nil 포인터 - 아무것도 가리키지 않는 포인터

포인터에는 한 가지 특별한 값이 있는데요, 바로 nil 입니다. 다른 언어의 null 과 비슷한 개념이라고 생각하시면 됩니다. 포인터를 선언만 하고 아무 주소도 할당하지 않으면 zero value인 nil 이 되죠.

var p *bool // 선언만 함 -> p는 nil
fmt.Println(p) // <nil>

if p == nil {
 fmt.Println("p는 아무것도 가리키지 않습니다")
}

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

nil 포인터를 역참조(*p) 하려고 하면 위 코드의 마지막 줄처럼 런타임 패닉이 터집니다. 그래서 포인터를 다룰 때는 사용하기 전에 nil 체크를 하는 습관이 중요합니다.

도대체 이런 포인터를 왜 사용하게 된 걸까요? 메모리를 빠르고 효율적으로 사용하기 위해서 그렇습니다. 좀 더 알아볼까요?

스택(stack) vs 힙(heap)

프로그램이 실행될 때는 스택, 힙 이렇게 2가지 유형의 메모리를 사용합니다.

스택: 여러분이 알고계시는 바로 그 스택입니다. 가장 나중에 들어온 게 가장 먼저 나가는(LIFO) 방식으로 이 타입의 메모리는 관리가 매우 쉽습니다. 메모리에 할당할 때는 스택의 꼭대기를 나타내는 top 포인터를 증가/감소 시키기만 하면 됩니다. 함수가 호출될 때 마다 해당 함수에서 사용하는 모든 지역 변수들을 하나의 프레임으로 구성하여 스택의 꼭대기에 push하고, 함수의 실행이 종료되면 프레임 전체를 pop합니다.
힙: 함수의 실행 주기와 관계없이 프로그램 전체에서 공유되어야 하거나, 스택에 할당되기에 너무 큰 메모리의 경우 힙에 할당됩니다. 스택에서는 함수 실행 주기에 따라 메모리에서 자동적으로 pop을 하는 방식으로 관리가 되지만, 힙은 함수 실행과 관계없이 그대로 남아있습니다. 그래서 주기적으로 가비지 컬렉터(GC)가 더 이상 사용되지 않는 항목을 찾아서 제거하고 메모리를 압축하는 등의 작업을 수행합니다.

이 둘의 차이를 그림으로 보면 이렇습니다.

 STACK (LIFO) HEAP (자유 할당)
 ┌──────────────────────┐
 ┌─────────────────┐ ◄─ top │ ┌────┐ ┌──────┐ │
 │ bar() frame │ (가장 │ │obj1│ │ obj2 │ │
 ├─────────────────┤ 나중에 │ └────┘ └──────┘ │
 │ foo() frame │ push됨) │ ┌────┐ │
 ├─────────────────┤ │ │obj3│ ← GC가 │
 │ main() frame │ │ └────┘ 정리 │
 └─────────────────┘ └──────────────────────┘
 호출 순서: main() → foo() → bar()
 push/pop 으로 관리

아주 단순하게 말하면 값 타입(value type)은 스택에, 참조 타입(reference type)은 힙 메모리에 할당된다고 말할 수 있는데요.(물론 Go 컴파일러는 escape analysis를 수행해서 함수의 수명보다 길게 살아남을 요소들은 힙에 할당하기도 합니다.) 그러면 값 타입과 참조 타입에 대해서 알아보죠.

값 타입(value type) vs 참조 타입(reference type)

일단 값 타입(value type)과 참조 타입(reference type)부터 정리하고 가겠습니다. 너무 기본이지만 어느새 까먹어 버리는 개념이기 때문이죠.

값 타입(value type): int, bool 같은 기본(또는 원시 primitive)타입과 배열, 구조체 등의 복합 타입은 일반적으로 스택에 할당됩니다.
참조 타입(reference type): 슬라이스, 맵, 채널, 인터페이스, 포인터 처럼 힙 메모리 어딘가에 위치하는 실제 데이터를 참조하는 타입입니다.

그런데 사실 참조 타입은 값 타입이기도 합니다. 위에서 설명드린 것 처럼 값 타입이지만, 메모리 어딘가에 위치하는 데이터를 가리키는 포인터를 값으로 가지는 타입을 편의상 참조 타입으로 부르는 거죠.

Go에서는 기본적으로 모든 걸 값으로 전달(pass by value, 값을 복제해서 전달함) 하는데요, 여기에서 참조 타입은 약간 헷갈릴 수도 있게 동작합니다.

다음 코드를 볼까요?

package main

import "fmt"

func main() {
 array1 := [3]int{10, 20, 30} // 값 타입 배열 선언
 fmt.Println(array1) // [10 20 30]

 array2 := array1 // array2 에 array1 할당(pass by value, 배열이 복사됨)
 array2[0] = 100

 fmt.Println(array1) // [10 20 30] array1과 array2는 별개의 복사본이므로 변화 없음

 slice1 := make([]int, 3, 5) // len:3, cap: 5
 slice1[0] = 10
 slice1[1] = 20
 slice1[2] = 30

 fmt.Println(slice1) // [10 20 30]

 slice2 := slice1 // slice1를 slice2에 할당(pass by value)
 slice2[0] = 100

 fmt.Println(slice1) // [100 20 30] slice1과 slice2는 동일한 배열 데이터를 참조함
}

값 타입인 배열의 경우, array2 := array1 에서 배열의 모든 요소들이 새로운 배열로 복제되어 array2에 할당됩니다. 그래서 array2의 데이터를 변경해도 array1은 전혀 영향을 받지 않죠.

참조 타입인 슬라이스의 경우 slice2 := slice1 에서 값 타입인 슬라이스의 헤더(실제 배열 값을 가리키는 포인터, 슬라이스 요소 개수 len, 배열 길이 cap)만 복제되어 slice2로 전달됩니다. 두 슬라이스 모두 동일한 포인터를 가지고 있기 때문에 slice2의 요소를 변경하면 slice1도 변경된 값을 참조하게 됩니다.

이 차이를 그림으로 보면 한눈에 들어옵니다.

▶ 배열 (값 타입) - array2 := array1 후, array2[0] = 100 까지 실행한 상태

 array1 array2
 ┌──┬──┬──┐ 복사 ┌───┬──┬──┐
 │10│20│30│ ────────► │100│20│30│ ← 완전히 별개의 메모리
 └──┴──┴──┘ └───┴──┴──┘ (array2만 100으로 변경됨)


▶ 슬라이스 (참조 타입) - slice2 := slice1 후, slice2[0] = 100 까지 실행한 상태

 slice1 헤더 slice2 헤더
 ┌──────┬───┬───┐ ┌──────┬───┬───┐
 │ ptr │ 3 │ 5 │ │ ptr │ 3 │ 5 │ ← 헤더만 복사
 └──┬───┴───┴───┘ └──┬───┴───┴───┘
 │ │
 └────────────┬────────────┘
 ▼
 underlying array (힙)
 ┌───┬──┬──┬─┬─┐
 │100│20│30│ │ │ ← 동일한 배열을 공유
 └───┴──┴──┴─┴─┘ (slice2의 변경이 slice1에도 보임)
 len=3 cap=5

배열은 통째로 복제되어 두 개의 독립된 메모리가 되지만, 슬라이스는 헤더만 복제되고 실제 데이터(underlying array)는 하나를 공유합니다. 그래서 slice2[0] = 100 으로 변경한 값이 slice1 에서도 보이는 거죠.

구조체도 헷갈리게…

Go는 OOP를 지원하긴 하지만, 클래스를 사용하지 않습니다. 이 부분이 저도 처음엔 좀 의아하긴 했는데요, Go는 값 타입인 구조체를 활용해서 이 문제를 해결합니다.

package main

import "fmt"

type Counter struct {
 count int
}

func main() {
 counter1 := Counter{count: 1}
 fmt.Println(counter1) // {1}

 counter2 := counter1
 counter2.count = 10

 fmt.Println(counter1) // {1}
}

구조체는 값 타입이기 때문에 counter1을 counter2에 대입할 때 count 값이 새로운 복제본으로 복사되어 전달됩니다.

구조체의 메서드 정의

클래스는 지원하는 언어는 클래스의 내부에 메서드(멤버 메서드)를 정의합니다. 하지만 Go는 클래스 대신 구조체를 사용하죠. 그래서 구조체 외부에 메서드를 정의하고 그 메서드의 수신자가 누구인지를 명시하도록 되어 있습니다.

package main

import "fmt"

type Counter struct {
 count int
}

// 값 수신자(value receiver) - 복사본에 대해 수행
func (c Counter) IncrementOnCopy() {
 c.count++
}

// 포인터 수신자(pointer receiver) - 원본에 대해 수행
func (c *Counter) Increment() {
 c.count++ // 원래는 (*c).count++ 이어야 하지만, Go는 자동으로 참조를 해제해준다
}

func main() {
 counter := &Counter{count: 0}
 // 위 라인은 아래 두 줄과 동일
 // tmp := Counter{count: 0}
 // counter := &tmp

 fmt.Println("복사본에 대해 카운트 증가")
 for i := 0; i < 5; i++ {
 counter.IncrementOnCopy()
 fmt.Printf("%d번 증가: %d \n", i+1, counter.count)
 }

 fmt.Println("원본에 대해 카운트 증가")
 for i := 0; i < 5; i++ {
 counter.Increment()
 fmt.Printf("%d번 증가: %d \n", i+1, counter.count)
 }
}

위 코드의 실행결과는 다음과 같습니다.

❯ go run .
복사본에 대해 카운트 증가
1번 증가: 0
2번 증가: 0
3번 증가: 0
4번 증가: 0
5번 증가: 0
원본에 대해 카운트 증가
1번 증가: 1
2번 증가: 2
3번 증가: 3
4번 증가: 4
5번 증가: 5

Go에서는 데이터를 전달할 때 항상 값으로 전달(pass by value)을 사용합니다. 따라서 값 수신자에 전달되는 구조체 데이터 역시 복제되어 전달됩니다. 아무리 IncrementOnCopy() 를 호출해도 복사본에 대해 수행되기 때문에 카운트는 제자리에 멈추게 됩니다.

포인터 수신자는 구조체의 참조를 전달받아 연산을 수행하기 때문에 원본의 값을 변경하게 되고 카운트가 계속 증가하게 됩니다.

이 차이를 그림으로 정리하면 다음과 같습니다.

▶ 값 수신자: func (c Counter) IncrementOnCopy()

 [호출자의 메모리] [함수의 스택 프레임]

 counter 값 복사 c (Counter의 복사본)
 ┌────────┐ ───────────► ┌────────┐
 │count: 0│ │count: 0│
 └────────┘ └───┬────┘
 ▲ │ c.count++
 │ ▼
 │ ┌────────┐
 │ ── 함수가 끝나도 ── │count: 1│ ← 복사본만 증가
 └── 여전히 count: 0 └────────┘
 함수 종료 → c 폐기


▶ 포인터 수신자: func (c *Counter) Increment()

 [호출자의 메모리] [함수의 스택 프레임]

 counter 주소(&counter) 전달 c (*Counter)
 ┌────────┐ ─────────────────► ┌────────────┐
 │count: 0│ │0xc000014090│
 │ ↓ │ ◄── (*c).count++ 으로 ───── │ (원본을 │
 │count: 1│ 원본을 직접 수정 │ 가리킴) │
 └────────┘ └────────────┘
 원본이 변경됨

IncrementOnCopy() 는 호출할 때마다 매번 새로운 복사본을 만들어 그 위에서 1을 더한 뒤, 함수가 끝나면 복사본은 사라집니다. 그래서 원본인 counter.count 는 계속 0인 거죠. 반면 Increment() 는 counter 의 주소만 받기 때문에 함수 안에서 c.count++ 를 하면 원본의 메모리가 직접 바뀝니다.

`new()` 와 `&Counter{}` - 둘 다 구조체 포인터를 만들어요

위 예시에서 counter := &Counter{count: 0} 으로 구조체 포인터를 만들었는데요, Go에는 내장 함수 new() 라는 또 다른 방법도 있습니다.

counter1 := &Counter{} // 빈 구조체 포인터 (모든 필드가 zero value)
counter2 := new(Counter) // 위와 동일한 결과

counter3 := &Counter{count: 10} // 초기값을 지정하고 싶다면 이쪽

new(T) 는 타입 T의 zero value를 가지는 새 메모리를 할당하고 그 포인터를 돌려주는 내장 함수입니다. 초기화할 필드가 없다면 new(Counter) 가 좀 더 간결하긴 한데요, 실제로는 초기값을 함께 지정하는 경우가 대부분이라서 &Counter{...} 쪽이 훨씬 자주 사용됩니다.

참고자료

Tucker의 Go 언어 프로그래밍
Claude

go를 알아보자(2) - gRPC

Sun, 22 Mar 2026 10:34:52 +0900

paxos 기반의 분산 key-value 스토어 를 만들면서 가장 처음에 ‘뭐지?’ 싶었던 건 gRPC였습니다. gRPC자체를 몰랐다기 보다는 뭔가 코드가 완전 암호같아 보였기 때문이죠. 그래서 gRPC만 우선 따로 간단하게 이해해보자 하고 간단한 앱을 만들어 보고 한 줄씩 따라가면서 이해해보려고 노력했습니다.

gRPC란?

RPC(Remote Procedure Call)은 원격, 그러니까 실행되는 프로그램 입장에서 자신이 아닌 외부의 함수를 호출하는 걸 뜻합니다. 그럼 g는 뭐냐 싶었는데 찾아보니 이건 좀 개발자들의 말장난 같은 느낌이네요… 버전마다 뜻이 다르답니다. 뭐 그렇다니까 그렇겠죠…

어쨌거나 gRPC는 바이너리 형식인 Protocol Buffer(protobuf)를 사용해서 REST에 비해 매우 빠르고, 엄격하게 주고 받을 데이터 및 호출할 함수에 대한 정의를 해줄 수 있는 등의 장점이 있습니다. 단점이라면… 코드가 기존 REST에 비해서 좀 이해하기 어렵다? 별도의 코드 생성과정이 필요하다? 뭐 이런게 있겠네요. 그래서 저도 좀 이해하기가 어려웠었죠.

항목	REST	gRPC
프로토콜	HTTP/1.1 (주로)	HTTP/2
데이터 형식	JSON (텍스트)	Protocol Buffers (바이너리)
계약 정의	OpenAPI/Swagger (선택)	.proto 파일 (필수)
스트리밍	제한적	양방향 스트리밍 지원
브라우저 지원	네이티브	gRPC-Web 필요

그냥 한 번 해보자!

자 그럼 일단 그냥 한 번 해보죠. 아주 간단하게 서버와 클라이언트가 인사를 주고 받는 예제를 만들어 보겠습니다.

폴더 생성 및 go 모듈을 초기화

grpc-helloworld 폴더를 만들고 모듈을 초기화 합니다.

> mkdir grpc-helloworld
> cd grpc-helloworld
> go mod init grpc-helloworld

gRPC 계약(contract) 작성

이제 gRPC를 통해 어떤 메시지를 주고 받을 거며, 어떤 원격의 함수를 호출할 수 있는지 계약(contract)을 정의해주겠습니다. greet.proto 파일에 다음과 같이 작성합니다.

syntax = "proto3";

package greet;

// 생성된 go 코드가 위치할 경로
option go_package = "./pb";

// gRPC를 통해 제공할 서비스(함수 목록)
service Greeter {
 rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// 요청 메시지 형식
message HelloRequest {
 string name = 1; // 필드 번호
}

// 응답 메시지 형식
message HelloReply {
 string message = 1; // 필드 번호
}

추가 설명이 필요 없을 정도로 직관적이죠?

gRPC 코드 생성

이제 proto 파일에 정의된 서비스를 호출 및 응답하는데 사용할 코드를 생성해야 합니다.

# Protocol Buffer 컴파일러 설치
# macos의 경우
> brew install protobuf
# linux(ubuntu / debian)의 경우
# > sudo apt install -y protobuf-compiler

# go install 명령으로 설치된 패키지 경로 설정
> echo 'export PATH="$PATH:$(go env GOPATH)/bin"' >> ~/.zshrc
> source ~/.zshrc

# grpc 관련 패키지 설치
> go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
> go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest

# 코드 생성
> protoc --go_out=. --go-grpc_out=. greet.proto

pb 폴더를 확인해보면 greet_grpc.pb.go, greet.pb.go 파일 두 개가 생성된 걸 확인할 수 있습니다.

greet.pb.go: proto 파일에 정의된 서비스와 요청/응답 메시지에 대한 정의를 담고 있습니다.
greet_grpc.pb.go: gRPC 클라이언트와 서버의 구현을 담고 있습니다.

서버 코드 작성

일단 코드를 작성하기 전에 다음 명령을 실행하여 부수적으로 필요한 패키지들을 모두 설치하고, go.mod 파일을 정리하도록 합니다.

> go mod tidy

그리고 server/main.go 파일을 다음과 같이 작성합니다.

package main

import (
 "context"
 "log"
 "net"

 "grpc-helloworld/pb"

 "google.golang.org/grpc"
)

type server struct {
 /*
 "protoc --go_out=. --go-grpc_out=. greet.proto" 명령으로 생성된 코드에는 greeterServer, greeterClient 구현이 있음.
 UnimplementedGreeterServer 구조체 역시 protoc가 생성한 것으로 proto 파일에 정의된 Greeter 서비스의 모든 메서드에 대해 껍데기 구현을 가지고 있음.(호출시 codes.Unimplemented 오류 리턴)
 이는 추후 proto 파일에 새로운 메서드가 추가되고, 이에 대한 구현이 되지 않았을 때 컴파일 단계의 오류를 방지하기 위함.
 -> 컴파일은 잘 되지만, 해당 함수를 호출하면 codes.Unimplemented 오류 리턴.
 */
 pb.UnimplementedGreeterServer
}

// pb.UnimplementedGreeterServer의 SayHello 함수를 오버라이드(더 정확히는 덮어서 감추기, shadowing)
func (s *server) SayHello(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {
 return &pb.HelloReply{Message: "Hello " + in.GetName()}, nil
}

func main() {
 // 50051번 포트에 대해 네트워크 리스너를 생성
 lis, err := net.Listen("tcp", ":50051")
 if err != nil {
 log.Fatalf("failed to listen: %v", err)
 }

 // gRPC 서버 생성
 s := grpc.NewServer()
 // Greeter grpc 서비스에 서버를 등록
 pb.RegisterGreeterServer(s, &server{})

 // 서버 시작
 log.Println("Server listening at :50051")
 if err := s.Serve(lis); err != nil {
 log.Fatalf("failed to serve: %v", err)
 }
}

이 코드에서 유심히 봐야 할 내용은(처음에 제가 이해를 못했던 내용은) server 선언부 입니다. 이걸 이해하려면 일단 greet_grpc.pb.go 파일의 다음 내용을 봐야 합니다.

...

// UnimplementedGreeterServer must be embedded to have
// forward compatible implementations.
//
// NOTE: this should be embedded by value instead of pointer to avoid a nil
// pointer dereference when methods are called.
type UnimplementedGreeterServer struct{}

func (UnimplementedGreeterServer) SayHello(context.Context, *HelloRequest) (*HelloReply, error) {
 return nil, status.Error(codes.Unimplemented, "method SayHello not implemented")
}

...

proto 파일에 정의했던 서비스의 함수가 UnimplementedGreeterServer의 메서드로 정의되어 있는데요, 내용을 보면 이 함수가 아직 구현되지 않았다 는 오류 메시지입니다. 그러니까 gRPC 서버를 구현할 때, SayHello 라는 메서드를 직접 구현하지 않으면 대신 이 기본 구현이 실행되면서 서비스를 제공할 함수를 구현해야 한다 고 알려주는 거죠.

근데 왜 이렇게 할까요? 이건 안전장치입니다.

새로운 gRPC 함수가 추가된다고 생각해보죠. 그러면 우선 proto 파일을 수정합니다. 그리고 코드를 생성하죠. 그런데 만약 gRPC 서버 구현을 맡은 사람이 새 함수를 구현하는 걸 깜빡하면 어떻게 될까요? 갑자기 gRPC 서버는 컴파일 조차 되지 않을겁니다. 인터페이스의 함수를 모두 구현하지 못했기 때문이죠.

그런데 기본 구현을 생성해서 그걸 서버 구현에 임베드 하게 된다면? 구현을 못 한 상태에서도 기존 구현은 아무 문제 없이 컴파일 되고 동작합니다!

클라이언트 코드 작성

다음으로 client/main.go를 다음과 같이 작성합니다.

package main

import (
 "context"
 "grpc-helloworld/pb"
 "log"
 "time"

 "google.golang.org/grpc"
 "google.golang.org/grpc/credentials/insecure"
)

func main() {
 // 1. 서버에 연결하기
 conn, err := grpc.NewClient("localhost:50051", grpc.WithTransportCredentials(insecure.NewCredentials()))
 if err != nil {
 log.Fatalf("failed to dial: %v", err)
 }
 defer conn.Close()

 // 2. GreeterClient 생성
 client := pb.NewGreeterClient(conn)

 // 3. SayHello 메서드 호출(1초 동안 서버가 응답하지 않으면 컨텍스트 취소)
 ctx, cancel := context.WithTimeout(context.Background(), time.Second)
 defer cancel()

 r, err := client.SayHello(ctx, &pb.HelloRequest{Name: "World"})
 if err != nil {
 log.Fatalf("failed to say hello: %v", err)
 }

 log.Printf("Server response: %s", r.GetMessage())
}

gRPC 서버에 연결해서 요청을 보내고 응답을 수신합니다. 만약 요청이 처리되는데 1초 이상 소요된다면, 요청을 취소하게 설정되었습니다.

서버와 클라이언트 실행

2개의 터미널을 열고 먼저 서버를 실행합니다.

❯ go run server/main.go
2026/03/22 10:22:14 Server listening at :50051

그리고 클라이언트를 실행해서 요청을 전송하고 응답을 받습니다.

❯ go run client/main.go
2026/03/22 10:22:51 Server response: Hello World

정리

매우 간단한 예제지만 gRPC 계약 정의와 코드 생성 및 서버와 클라이언트 사용 등의 내용은 충분히 확인할 수 있었습니다. 이걸 몰랐을 때는 완전히 블랙박스 처럼 보였던 코드와 과정을 좀 더 명확하게 이해할 수 있었죠! 이 글의 모든 학습과정은 gemini가 생성한 튜토리얼을 기반으로 저의 삽질을 통해 진행하였습니다.

분산 시스템 설계(1) - Paxos 심화(분산 Key-Value 스토어)

Sun, 22 Mar 2026 10:34:52 +0900

Paxos 알고리즘 관련 세번째 글입니다. 그러니까… 지난 글에서는 아주 간단하게 리더를 선출하는 예제를 만들어 봤었지만, 그게 뭐랄까 좀 예제를 위한 예제 같은 느낌이 들었습니다. Multi-Paxos를 제대로 구현하지도 못했고 말이죠. 그래서 Claude와 함께 고민을 하던 중에 Redis 같은 분산 Key-Value 스토어(이하 dkv)를 만들어 보는 게 어떨까 싶었습니다. 그래서 관련해서 튜토리얼을 생성해내고, 직접 쳐보기도 하면서 Claude Code와 예제를 완성하고 코드를 모두 한 줄씩 읽어가면서 동작을 이해하려 노력해봤습니다.

그 과정의 결과물을 여기 에 올려두었습니다.

간략한 소개

해당 리포지토리에 방문하시면 훨씬 더 상세한 README가 기다리고 있긴 합니다. 해당 내용은 초반에 틀을 제가 손으로 직접 잡고 나머지 부분을 Claude Code와 함께 완성 및 보강했습니다. 여기서는 어떻게 dkv가 동작하는지를 좀 설명드려보고자 합니다.

Paxos Prepare-Accept를 통한 리더 선출

우선 3개의 노드를 실행하는 과정을 볼까요? 일단 첫 번째 노드부터 실행합니다.

❯ go run ./cmd/dkv -id=1
2026/03/17 14:16:53 gRPC listening on 127.0.0.1:9001
time=2026-03-17T14:16:53.495+09:00 level=INFO msg="wal: 재생 완료" node=1 lastApplied=1 totalRecords=42 acceptorStates=41 committedEntries=1
time=2026-03-17T14:16:53.495+09:00 level=INFO msg="paxos: 시작" node=1 peers="[1 2 3]" electionTimeout=500ms heartbeatInterval=100ms
time=2026-03-17T14:16:53.495+09:00 level=INFO msg="http: HTTP 서버 시작" node=1 addr=127.0.0.1:8001
Node 1 started — HTTP: 127.0.0.1:8001, gRPC: 127.0.0.1:9001
time=2026-03-17T14:16:54.253+09:00 level=INFO msg="election: 타이머 발동, 선거 시작" node=1 elapsed=2562047h47m16.854775807s threshold=500ms
time=2026-03-17T14:16:54.253+09:00 level=INFO msg="election: 🟢 prepare 시작" node=1 ballot=N1.1 prevNumber=0
time=2026-03-17T14:16:54.256+09:00 level=INFO msg="election: prepare 전송 실패" node=1 peer=2 ballot=N1.1 err="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 127.0.0.1:9002: connect: connection refused\""
time=2026-03-17T14:16:54.256+09:00 level=INFO msg="election: prepare 전송 실패" node=1 peer=3 ballot=N1.1 err="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 127.0.0.1:9003: connect: connection refused\""
time=2026-03-17T14:16:54.257+09:00 level=INFO msg="election: prepare 거부됨" node=1 peer=1 ballot=N1.1 promisedBallot=N30.1
time=2026-03-17T14:16:54.257+09:00 level=INFO msg="election: prepare 결과" node=1 promises=0 majority=2 ballot=N1.1 result=실패
time=2026-03-17T14:16:54.257+09:00 level=INFO msg="election: ballot fast-forward" node=1 from=1 to=30
time=2026-03-17T14:16:54.257+09:00 level=INFO msg="election: 실패" node=1 err="🔴election failed: 0/2 promises"
time=2026-03-17T14:16:54.988+09:00 level=INFO msg="election: 타이머 발동, 선거 시작" node=1 elapsed=2562047h47m16.854775807s threshold=500ms
time=2026-03-17T14:16:54.988+09:00 level=INFO msg="election: 🟢 prepare 시작" node=1 ballot=N31.1 prevNumber=30
time=2026-03-17T14:16:54.988+09:00 level=INFO msg="election: prepare 전송 실패" node=1 peer=2 ballot=N31.1 err="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 127.0.0.1:9002: connect: connection refused\""
time=2026-03-17T14:16:54.988+09:00 level=INFO msg="election: prepare 전송 실패" node=1 peer=3 ballot=N31.1 err="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 127.0.0.1:9003: connect: connection refused\""
time=2026-03-17T14:16:54.994+09:00 level=INFO msg="election: prepare 약속 받음" node=1 peer=1 ballot=N31.1
time=2026-03-17T14:16:54.994+09:00 level=INFO msg="election: prepare 결과" node=1 promises=1 majority=2 ballot=N31.1 result=실패
time=2026-03-17T14:16:54.994+09:00 level=INFO msg="election: 실패" node=1 err="🔴election failed: 1/2 promises"
...

뭔가 로그가 복잡해 보이지만, 리더 선출을 위한 선거(Prepare)를 진행하고 있습니다. 🟢과 🔴를 주목해서 보시면 선거가 시작됐지만 아직 자신 밖에 없으므로 선거는 실패하고 있습니다. 자 이제 2번 노드 투입합니다!

❯ go run ./cmd/dkv -id=2
2026/03/17 14:17:01 gRPC listening on 127.0.0.1:9002
time=2026-03-17T14:17:01.908+09:00 level=INFO msg="wal: 재생 완료" node=2 lastApplied=1 totalRecords=20 acceptorStates=19 committedEntries=1
time=2026-03-17T14:17:01.908+09:00 level=INFO msg="paxos: 시작" node=2 peers="[1 2 3]" electionTimeout=500ms heartbeatInterval=100ms
time=2026-03-17T14:17:01.908+09:00 level=INFO msg="http: HTTP 서버 시작" node=2 addr=127.0.0.1:8002
Node 2 started — HTTP: 127.0.0.1:8002, gRPC: 127.0.0.1:9002
time=2026-03-17T14:17:02.429+09:00 level=INFO msg="election: 타이머 발동, 선거 시작" node=2 elapsed=2562047h47m16.854775807s threshold=500ms
time=2026-03-17T14:17:02.429+09:00 level=INFO msg="election: 🟢 prepare 시작" node=2 ballot=N1.2 prevNumber=0
time=2026-03-17T14:17:02.431+09:00 level=INFO msg="election: prepare 전송 실패" node=2 peer=3 ballot=N1.2 err="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 127.0.0.1:9003: connect: connection refused\""
time=2026-03-17T14:17:02.431+09:00 level=INFO msg="election: prepare 거부됨" node=2 peer=1 ballot=N1.2 promisedBallot=N42.1
time=2026-03-17T14:17:02.432+09:00 level=INFO msg="election: prepare 거부됨" node=2 peer=2 ballot=N1.2 promisedBallot=N25.1
time=2026-03-17T14:17:02.432+09:00 level=INFO msg="election: prepare 결과" node=2 promises=0 majority=2 ballot=N1.2 result=실패
time=2026-03-17T14:17:02.432+09:00 level=INFO msg="election: ballot fast-forward" node=2 from=1 to=42
time=2026-03-17T14:17:02.432+09:00 level=INFO msg="election: 실패" node=2 err="🔴election failed: 0/2 promises"
time=2026-03-17T14:17:02.991+09:00 level=INFO msg="election: 타이머 발동, 선거 시작" node=2 elapsed=2562047h47m16.854775807s threshold=500ms
time=2026-03-17T14:17:02.991+09:00 level=INFO msg="election: 🟢 prepare 시작" node=2 ballot=N43.2 prevNumber=42
time=2026-03-17T14:17:02.991+09:00 level=INFO msg="election: prepare 전송 실패" node=2 peer=3 ballot=N43.2 err="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 127.0.0.1:9003: connect: connection refused\""
time=2026-03-17T14:17:02.996+09:00 level=INFO msg="election: prepare 약속 받음" node=2 peer=2 ballot=N43.2
time=2026-03-17T14:17:03.000+09:00 level=INFO msg="election: prepare 약속 받음" node=2 peer=1 ballot=N43.2
time=2026-03-17T14:17:03.000+09:00 level=INFO msg="election: prepare 결과" node=2 promises=2 majority=2 ballot=N43.2 result=성공
time=2026-03-17T14:17:03.000+09:00 level=INFO msg="election: 미커밋 엔트리 재제안" node=2 slot=1 ballot=N43.2 key=hahaha
time=2026-03-17T14:17:03.008+09:00 level=INFO msg="election: 🎉 리더 당선" node=2 ballot=N43.2 committedUpTo=1

마지막 줄을 보시면 2번 노드는 시작되자 마자 과반수의 지지를 받아 리더가 됩니다! 이때 1번 노드의 상황을 볼까요?

...
time=2026-03-17T14:17:02.997+09:00 level=INFO msg="election: 🟢 prepare 시작" node=1 ballot=N43.1 prevNumber=42
time=2026-03-17T14:17:02.997+09:00 level=INFO msg="election: prepare 전송 실패" node=1 peer=3 ballot=N43.1 err="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 127.0.0.1:9003: connect: connection refused\""
time=2026-03-17T14:17:02.997+09:00 level=INFO msg="election: prepare 전송 실패" node=1 peer=2 ballot=N43.1 err="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 127.0.0.1:9002: connect: connection refused\""
time=2026-03-17T14:17:03.000+09:00 level=INFO msg="election: prepare 거부됨" node=1 peer=1 ballot=N43.1 promisedBallot=N43.2
time=2026-03-17T14:17:03.000+09:00 level=INFO msg="election: prepare 결과" node=1 promises=0 majority=2 ballot=N43.1 result=실패
time=2026-03-17T14:17:03.000+09:00 level=INFO msg="election: 실패" node=1 err="🔴election failed: 0/2 promises"
time=2026-03-17T14:17:03.110+09:00 level=INFO msg="heartbeat: 새 리더 감지" node=1 leader=2 ballot=N43.2 prevLeader=0
...

자신이 리더가 되고자 하는 요청(Prepare)는 한 표도 받지 못했고, 2번 노드가 2표를 모두 약속받은 뒤 Accept까지 진행해버렸기 때문에 2번 노드가 새로운 리더임을 인정하게 됩니다.

이제 3번 노드가 또 합류합니다!

❯ go run ./cmd/dkv -id=3
2026/03/17 14:17:11 gRPC listening on 127.0.0.1:9003
time=2026-03-17T14:17:11.717+09:00 level=INFO msg="wal: 재생 완료" node=3 lastApplied=1 totalRecords=31 acceptorStates=30 committedEntries=1
time=2026-03-17T14:17:11.717+09:00 level=INFO msg="paxos: 시작" node=3 peers="[1 2 3]" electionTimeout=500ms heartbeatInterval=100ms
time=2026-03-17T14:17:11.717+09:00 level=INFO msg="http: HTTP 서버 시작" node=3 addr=127.0.0.1:8003
Node 3 started — HTTP: 127.0.0.1:8003, gRPC: 127.0.0.1:9003
time=2026-03-17T14:17:12.468+09:00 level=INFO msg="election: 타이머 발동, 선거 시작" node=3 elapsed=2562047h47m16.854775807s threshold=500ms
time=2026-03-17T14:17:12.469+09:00 level=INFO msg="election: 🟢 prepare 시작" node=3 ballot=N1.3 prevNumber=0
time=2026-03-17T14:17:12.471+09:00 level=INFO msg="election: prepare 거부됨" node=3 peer=2 ballot=N1.3 promisedBallot=N43.2
time=2026-03-17T14:17:12.471+09:00 level=INFO msg="election: prepare 거부됨" node=3 peer=3 ballot=N1.3 promisedBallot=N34.3
time=2026-03-17T14:17:12.471+09:00 level=INFO msg="election: prepare 거부됨" node=3 peer=1 ballot=N1.3 promisedBallot=N43.2
time=2026-03-17T14:17:12.471+09:00 level=INFO msg="election: prepare 결과" node=3 promises=0 majority=2 ballot=N1.3 result=실패
time=2026-03-17T14:17:12.471+09:00 level=INFO msg="election: ballot fast-forward" node=3 from=1 to=43
time=2026-03-17T14:17:12.471+09:00 level=INFO msg="election: 실패" node=3 err="🔴election failed: 0/2 promises"
time=2026-03-17T14:17:13.092+09:00 level=INFO msg="election: 타이머 발동, 선거 시작" node=3 elapsed=2562047h47m16.854775807s threshold=500ms
...
time=2026-03-17T14:17:16.468+09:00 level=INFO msg="election: 🟢 prepare 시작" node=3 ballot=N49.3 prevNumber=48
time=2026-03-17T14:17:16.469+09:00 level=INFO msg="election: prepare 거부됨" node=3 peer=2 ballot=N49.3 promisedBallot=N43.2
time=2026-03-17T14:17:16.469+09:00 level=INFO msg="election: prepare 거부됨" node=3 peer=1 ballot=N49.3 promisedBallot=N43.2
time=2026-03-17T14:17:16.472+09:00 level=INFO msg="election: prepare 약속 받음" node=3 peer=3 ballot=N49.3
time=2026-03-17T14:17:16.472+09:00 level=INFO msg="election: prepare 결과" node=3 promises=1 majority=2 ballot=N49.3 result=실패
time=2026-03-17T14:17:16.472+09:00 level=INFO msg="election: 실패" node=3 err="🔴election failed: 1/2 promises"
time=2026-03-17T14:17:17.109+09:00 level=INFO msg="heartbeat: 새 리더 감지" node=3 leader=2 ballot=N43.2 prevLeader=0

처음에는 자신을 리더로 제안(Propose)하지만, 결국 2번 노드가 리더임을 인정하게 됩니다.

Paxos Accept를 통한 key-value 전파

3번 노드에 키를 gundam으로 하고 값을 건담이말을건담으로 넣어볼까요?

❯ curl -L -X PUT http://127.0.0.1:8003/kv/gundam -d "건담이말을건담"
OK (index=2)

참고로 -L 플래그는 요청이 리다이렉트 될 수 있도록 해줍니다. 현재 dkv는 리더가 아닌 노드에게 쓰기 요청을 하면 해당 요청을 리더에게 리다이렉트 하도록 구현되었거든요! 자 그럼 1번 노드에서 키를 조회해볼까요?

❯ curl http://127.0.0.1:8001/kv/gundam
건담이말을건담

3번 노드가 쓰기 요청을 리더인 2번 노드에게 전달하고, 리더는 다른 노드들에 Accept 요청을 전송해서 쓰기 요청이 다른 노드에 전파되도록 합니다. 그래서 1번 노드에서도 키로 값을 조회해올 수 있는 거죠.

리더 선출 과정에서 이미 Prepare를 거쳤기 때문에 바로 Accept단계로 넘어갑니다!

정리

이걸 구현하고 이해해보려고 노력하면서 왜 Paxos가 더 이상 쓰이지 않는지 이해했습니다. 이게 좀 많이 복잡하네요. 솔직히 아직도 좀 헷갈립니다. 다음 부터는 dkv를 만드는 과정에서 제가 새롭게 배운 내용들을 따로 한 번 정리해보려고 합니다. 그러고 나서 Raft를 추가로 구현해볼 생각입니다.

분산 시스템 설계(1) - Paxos 알고리즘(GO)

Sun, 22 Feb 2026 08:03:55 +0900

지난 글에서는 Paxos 알고리즘에 대해서 정리를 했고, 리더 선출 예시를 살펴보면서 구체적인 알고리즘 동작과정을 살펴봤습니다. 해당 예시는 node.js로 작성을 했었죠. 이번에는 그 예시의 Go 버전을 확인해볼까 합니다. 이유는… 별게 없고 그냥 제가 최근에 Go를 좀 보기 시작 했기 때문입니다! 하하하하하….

구조와 동작은 지난 글의 내용과 똑같습니다. 다만, Go는 접근 방식이 다르다 보니 구체적인 구현에서는 좀 차이를 보이는데요. 그런 특징적인 부분들을 정리해보고자 합니다. 미래의 저를 위해서 말이죠!

코드 실행 방법

go는 원래 컴파일을 통해 실행 파일을 생성하지만, 다음 명령을 통해 바로 실행 해볼 수 있으며, 실행 과정은 이전의 node.js 버전과 동일합니다!

> go run . cluster

go run 명령도 컴파일을 합니다! 컴파일을 통해 임시 바이너리를 생성해서 실행을 하지만, 눈에 보이지 않을 뿐입니다. 개발 중에 계속 컴파일 -> 실행은 너무 귀찮죠 하하하하…

프로그램 진입점 구현

프로그램이 시작되는 main.go는 다음과 같습니다.

package main

import (
 "fmt"
 "os"
)

func main() {
 if len(os.Args) < 2 {
 fmt.Println("사용법:")
 fmt.Println(" go run . cluster -- 클러스터 모드 (3개 노드 실행)")
 os.Exit(1)
 }

 switch os.Args[1] {
 case "node":
 runNode() // 클러스터 관리 cli가 각 노드를 실행할 때 사용
 case "cluster":
 runCluster() // 클러스터 관리 cli를 실행
 default:
 fmt.Printf("알 수 없는 명령어: %s\n", os.Args[1])
 os.Exit(1)
 }
}

프로그램에 설정된 인자에 따라서 서로 다른 모드로 실행합니다.

cluster: 클러스터 관리 cli를 실행
node: 서버 노드를 실행

앞서 실행 방법에서 봤듯이 우리는 “cluster” 모드로 클러스터 관리 cli를 실행합니다. 그리고 클러스터 관리 cli가 “node” 모드로 3개의 서버 노드를 실행하게 되죠. main.go와 이후에 살펴볼 cluster.go, node.go 가 모두 같은 main 패키지에 포함되어 있기 때문에 다른 파일의 함수를 자유롭게 가져다 쓸 수 있습니다.

클러스터 관리자 cli 구현

cluster.go의 전체 소스코드는 다음과 같습니다.

package main

import (
 "bufio"
 "encoding/json"
 "fmt"
 "net/http"
 "os"
 "os/exec"
 "os/signal"
 "strconv"
 "strings"
 "sync"
 "syscall"
 "time"
)

type nodeConfig struct {
 id int
 port int
}

// 각 노드 아이디와 포트 번호 정의
var nodes = []nodeConfig{
 {id: 1, port: 3001},
 {id: 2, port: 3002},
 {id: 3, port: 3003},
}

// 가독성을 위해 각 노드의 아이디별 출력 색상 정의
var colors = map[int]string{
 1: "\033[36m", // 파란색 (cyan)
 2: "\033[33m", // 노란색
 3: "\033[35m", // 핑크색 (magenta)
}

const colorReset = "\033[0m"

// 노드 프로세스 관리를 위한 맵 정의
var (
 // 키 타입이 int이고, 값 타입이 *exec.Cmd인 맵
 processes = make(map[int]*exec.Cmd)
 // 맵에 대한 동시성 접근을 위한 뮤텍스(lock)
 processesMu sync.Mutex
)

// 노드 프로세스 시작 처리 함수
func startNode(nc nodeConfig) {
 // 현재 노드가 통신해야 할 다른 노드의 URL 목록 생성
 var peers []string
 for _, n := range nodes {
 if n.id != nc.id {
 peers = append(peers, fmt.Sprintf("http://localhost:%d", n.port))
 }
 }

 color := colors[nc.id]
 fmt.Printf("%s노드 %d 시작...%s\n", color, nc.id, colorReset)

 // 노드 프로세스 생성
 args := []string{"run", ".", "node", strconv.Itoa(nc.id), strconv.Itoa(nc.port)}
 args = append(args, peers...)

 cmd := exec.Command("go", args...)

 stdout, err := cmd.StdoutPipe()
 if err != nil {
 fmt.Printf("노드 %d stdout pipe 실패: %v\n", nc.id, err)
 return
 }
 stderr, err := cmd.StderrPipe()
 if err != nil {
 fmt.Printf("노드 %d stderr pipe 실패: %v\n", nc.id, err)
 return
 }

 if err := cmd.Start(); err != nil {
 fmt.Printf("노드 %d 시작 실패: %v\n", nc.id, err)
 return
 }

 // 여러 goroutine에서 동시에 접근할 수 있으므로, 동시성 접근을 위해 뮤텍스를 사용
 processesMu.Lock()
 processes[nc.id] = cmd
 processesMu.Unlock()

 // goroutine: 노드 프로세스의 출력에 색상을 적용하여 출력
 go func() {
 scanner := bufio.NewScanner(stdout)
 for scanner.Scan() {
 fmt.Printf("%s%s%s\n", color, scanner.Text(), colorReset)
 }
 }()

 // goroutine: 노드 프로세스의 에러 출력에 색상을 적용하여 출력
 go func() {
 scanner := bufio.NewScanner(stderr)
 for scanner.Scan() {
 fmt.Printf("%s[노드 %d 에러] %s%s\n", color, nc.id, scanner.Text(), colorReset)
 }
 }()

 // goroutine: 노드 프로세스가 종료될 때 처리
 go func() {
 err := cmd.Wait()
 exitCode := -1
 if cmd.ProcessState != nil {
 exitCode = cmd.ProcessState.ExitCode()
 }
 fmt.Printf("%s[노드 %d] 프로세스 종료 (code: %d, err: %v)%s\n",
 color, nc.id, exitCode, err, colorReset)

 processesMu.Lock()
 delete(processes, nc.id)
 processesMu.Unlock()
 }()
}

// 노드 프로세스 종료 처리 함수
func killNode(id int) {
 processesMu.Lock()
 // 맵에서 노드 프로세스 조회
 cmd, exists := processes[id]
 processesMu.Unlock()

 // 노드 프로세스가 존재하면 종료
 if exists && cmd.Process != nil {
 if err := cmd.Process.Signal(syscall.SIGTERM); err != nil {
 fmt.Printf("[클러스터] 노드 %d 시그널 전송 실패: %v\n", id, err)
 }
 color := colors[id]
 fmt.Printf("\n%s[클러스터] 노드 %d 종료%s\n\n", color, id, colorReset)
 } else {
 fmt.Printf("\n[클러스터] 노드 %d 실행 중이 아님\n\n", id)
 }
}

// 클러스터 상태 출력 함수
func printStatus() {
 fmt.Println("\n=== 클러스터 상태 ===")

 // 타임아웃이 1초인 http.Client 생성
 client := &http.Client{Timeout: 1 * time.Second}

 for _, node := range nodes {
 // 즉시 실행되는 익명 함수. 함수 종료시 defer 처리된 리소스 해제
 func() {
 url := fmt.Sprintf("http://localhost:%d/status", node.port)
 resp, err := client.Get(url)
 color := colors[node.id]

 if err != nil {
 fmt.Printf("%s 노드 %d: 다운%s\n", color, node.id, colorReset)
 return
 }
 // err 발생시 resp는 nil. 따라서 err 체크 후 defer 처리가 일반적인 방법.
 defer resp.Body.Close()

 var data StatusResponse
 // resp.Body를 JSON -> StatusResponse 타입으로 변환; 그리고 err 발생시 처리
 if err := json.NewDecoder(resp.Body).Decode(&data); err != nil {
 fmt.Printf("%s 노드 %d: (응답 파싱 실패)%s\n", color, node.id, colorReset)
 return
 }

 leaderMark := " "
 if data.IsLeader {
 leaderMark = "👑"
 }

 leaderStr := "none"
 if data.CurrentLeaderID != nil {
 leaderStr = strconv.Itoa(*data.CurrentLeaderID)
 }
 promisedStr := "none"
 if data.PromisedProposal != nil {
 promisedStr = strconv.Itoa(*data.PromisedProposal)
 }
 acceptedStr := "none"
 if data.AcceptedProposal != nil {
 acceptedStr = strconv.Itoa(*data.AcceptedProposal)
 }

 // 노드 상태 출력
 fmt.Printf("%s%s 노드 %d: leader=%s, term=%d, isLeader=%v, promised=%s, accepted=%s%s\n",
 color, leaderMark, node.id, leaderStr, data.CurrentTerm, data.IsLeader,
 promisedStr, acceptedStr, colorReset)
 }()
 }
 fmt.Println()
}

func isValidNodeID(id int) bool {
 for _, n := range nodes {
 if n.id == id {
 return true
 }
 }
 return false
}

func findNode(id int) *nodeConfig {
 for _, n := range nodes {
 if n.id == id {
 return &n
 }
 }
 return nil
}

// === 대화형 CLI 구현 ===

func runCluster() {
 // 모든 노드 시작
 fmt.Print("\n🚀 Starting Paxos Leader Election Cluster...\n\n")

 for _, node := range nodes {
 startNode(node)
 }

 // 모든 노드가 시작될 때까지 대기 후 명령어 출력
 time.AfterFunc(1*time.Second, func() {
 fmt.Println()
 fmt.Println(strings.Repeat("=", 60))
 fmt.Println("📋 사용 가능한 명령어:")
 fmt.Println(" kill <id> - 노드 종료 (특정 노드에 장애가 발생하여 종료되는 걸 시뮬레이션)")
 fmt.Println(" start <id> - 종료된 노드 재시작")
 fmt.Println(" status - 클러스터 상태 출력")
 fmt.Println(" exit - 모든 노드 종료 및 종료")
 fmt.Println(strings.Repeat("=", 60))
 fmt.Println()
 })

 // goroutine 끼리 메세지를 주고받기 위한 채널 생성, 버퍼 크기를 1로 설정하여 수신자가 메세지를 받을 때까지 대기할 수 있도록 함
 sigChan := make(chan os.Signal, 1)
 // Ctrl+C 발생시 해당 시그널을 채널로 전달
 signal.Notify(sigChan, os.Interrupt)

 go func() {
 // 채널에서 메세지(Ctrl+C)를 받을 때까지 대기
 <-sigChan
 fmt.Print("\n\n🛑 모든 노드 종료...\n\n")
 // 모든 노드 프로세스에 SIGTERM 시그널 전송
 processesMu.Lock()
 for _, cmd := range processes {
 if cmd.Process != nil {
 cmd.Process.Signal(syscall.SIGTERM)
 }
 }
 processesMu.Unlock()
 time.Sleep(500 * time.Millisecond)
 os.Exit(0)
 }()

 // 대화형 CLI 명령어 처리
 scanner := bufio.NewScanner(os.Stdin)
 // Stdin이 종료될 때까지 한 줄씩 읽어서 처리
 for scanner.Scan() {
 line := strings.TrimSpace(scanner.Text())
 if line == "" {
 continue
 }

 parts := strings.SplitN(line, " ", 2)
 cmd := parts[0]
 arg := ""
 if len(parts) > 1 {
 arg = parts[1]
 }

 // 명령어 처리
 switch cmd {
 case "kill":
 id, err := strconv.Atoi(arg)
 if err != nil || !isValidNodeID(id) {
 fmt.Printf("잘못된 노드 ID: %s\n", arg)
 continue
 }
 killNode(id)

 case "start":
 id, err := strconv.Atoi(arg)
 if err != nil || !isValidNodeID(id) {
 fmt.Printf("잘못된 노드 ID: %s\n", arg)
 continue
 }
 processesMu.Lock()
 _, running := processes[id]
 processesMu.Unlock()
 if running {
 fmt.Printf("\n노드 %d 이미 실행 중\n\n", id)
 } else {
 nc := findNode(id)
 if nc != nil {
 startNode(*nc)
 }
 }

 case "status":
 printStatus()

 case "exit":
 fmt.Print("\n🛑 모든 노드 종료...\n\n")
 processesMu.Lock()
 for _, cmd := range processes {
 if cmd.Process != nil {
 cmd.Process.Signal(syscall.SIGTERM)
 }
 }
 processesMu.Unlock()
 time.Sleep(500 * time.Millisecond)
 os.Exit(0)

 case "help":
 fmt.Println("\n📋 사용 가능한 명령어:")
 fmt.Println(" kill <id> - 노드 종료")
 fmt.Println(" start <id> - 종료된 노드 재시작")
 fmt.Println(" status - 클러스터 상태 출력")
 fmt.Println(" exit - 모든 노드 종료 및 종료")

 default:
 fmt.Printf("알 수 없는 명령어: %s. 'help' 명령어를 사용하세요.\n\n", cmd)
 }
 }
}

map 타입

두 군데에서 map을 사용하고 있는데 타입 정의 생김새가 좀 다릅니다.

// 키 타입이 int이고, 값 타입이 string인 맵
var colors = map[int]string{
 1: "\033[36m", // 파란색 (cyan)
 2: "\033[33m", // 노란색
 3: "\033[35m", // 핑크색 (magenta)
}
...
// 키 타입이 int이고, 값 타입이 *exec.Cmd인 맵
processes = make(map[int]*exec.Cmd)

우선 배열의 인덱스 처럼 둘러싸인 타입이 키의 타입이고, 그 뒤에 붙은 타입이 값의 타입이다 하는 건 몇 번 보다보면 알 수 있습니다. 그런데 colors는 그냥 map을 생성했고, processes는 make 함수를 호출해서 생성하고 있네요?

우선 colors는 map 리터럴(literal) 방식으로 map을 생성하고 있습니다. map안에 어떤 값이 들어갈지 명시해주면서 생성하고 있죠. 그래서 이 때는 Go가 map의 생성을 암묵적으로(implicitly) 처리해줍니다. 그런데 processes는 빈 map을 생성하고 있습니다. 그래서 암묵적으로 map을 생성할 수 없고, 따라서 make 함수를 호출해서 Go가 런타임 초기화를 실행하도록 해줘야 합니다.

map은 javascript의 map, C#의 Dictionary와 같은 key-value 매핑을 저장하는 자료 구조이고 동작방식도 동일합니다. 다만, Go에서는 map을 생성하기 위해서 make 함수를 사용해야 합니다. map외에도 make 함수를 사용하는 경우는 슬라이스와 채널이 있는데요, 이 타입들은 내부적으로 해시테이블, 동적 배열, 큐 등의 자료구조를 사용하기 때문에 Go가 런타임 초기화를 실행해야 합니다. 그래서 make를 실행해야 한다고 하네요! struct나 배열, int등의 다른 기본 타입들은 make없이도 각 타입의 기본 값(zero value)으로도 충분합니다.

또 한가지 Go의 특징은 map에서 값을 찾을 때도 볼 수 있습니다.

// 맵에서 노드 프로세스 조회
cmd, exists := processes[id]

map에서 값을 조회할 때, 리턴 받을 변수를 2개 지정해주면 2번째 변수에는 map에 특정 키에 해당하는 값이 있는지 여부를 같이 리턴해주는데요, 예를 들어 타입스크립트에서는 다음과 같이 해야 합니다.

const cmd = processes.get(id);
const exists = processes.has(id);

typescript 버전과 비교하면 가독성은 떨어지는 느낌입니다. 하지만 간결하죠? 간결함을 우선하는 Go의 철학이 느껴지네요!

동시성 처리 및 lock 걸기

스레드와 고루틴 비교

각 언어와 런타임은 여러 작업을 동시에 처리하기 위해 스레드(thread)를 활용합니다. 스레드는 간단하게 말하면, 코드 실행 묶음이라고 볼 수 있는데요, CPU의 각 코어는 한 번에 하나의 스레드만 처리할 수 있습니다. 예를 들어 1번 코어가 처리 중인 스레드가 네트워크를 통해 응답이 아주 오래걸리는 요청을 처리 중이라면 어떻게 될까요? 1번 코어가 그 스레드를 계속 처리하게 둔다면 우리는 코어 1개를 낭비하는 셈이죠. OS는 이런 비효율을 참지 못합니다. 오래 걸리는 스레드는 응답이 올 때 까지 잠깐 대기 시키고 다른 스레드를 처리하게 하는 등 멀티 스레드 작업을 진행하게 하죠. 언어와 런타임은 이런 OS의 스레드 관리를 기반으로 해서 자체적인 동시성 처리 모델을 제시합니다.

다만, 이 멀티 스레드라는 게 공짜가 아닙니다. 코어가 처리해야 되는 스레드를 변경할 때는 문맥 교환(context-switching)이 발생합니다. 스레드1->스레드2로 문맥 교환되는 과정을 간략하게 살펴보면요,

커널 모드 진입*: CPU는 필요한 권한을 얻기 위해 유저 모드에서 커널 모드로 진입
스레드1의 상태 저장: CPU 레지스터, 프로그램 카운터, 스택 포인터 등 스레드1의 모든 상태를 스레드1의 메모리 블록에 기록(TCB, Thread Control Block)
스케쥴러 상태 갱신: OS가 스레드1을 대기 상태로 설정하고 스레드2를 대기 큐에서 선택
TLB/cache 초기화*: 스레드1과 스레드2가 서로 다른 프로세스의 스레드라면, TLB(translation lookaside buffer)를 초기화
스레드2의 상태 불러오기: 스레드2의 TCB에서 모든 상태를 불러오기
유저 모드로 복귀*: CPU가 유저 모드로 돌아와서 스레드2의 이전 상태로 부터 계속 실행

저도 정확하게 다 아는 건 아니지만, 어쨌든 이런 복잡한 작업을 매번 진행해야 하고 특히 * 가 붙은 부분들이 비교적 많은 시간이 걸리는 작업이라고 합니다. 게다가 또 하나의 문제점도 있습니다. 저 유명한 StackOverflow 에러를 다들 아시겠지만, OS의 스레드는 대략 1-8MB 정도의 스택 메모리를 가지는데, 스레드 내부에서 발생하는 각 로컬 변수와 함수 호출 등을 기록하기 위해서 사용하죠. 그래서 어마어마하게 큰 로컬 변수나 어마어마하게 복잡한 제귀 호출을 하다보면 띵하고 StackOverflow가 발생합니다. 그런데 Go는 이걸 조금 다르게 접근한다고 하네요.

Go는 이런 동시성 처리의 문제를 고루틴(Goroutine)으로 접근합니다. 고루틴은 OS레벨의 스레드가 아니라 각 스레드에서 스위칭해서 실행할 수 있도록 하는 일종의 경량 스레드라고 할 수 있을 거 같네요. 그리고 OS레벨의 스레드가 아니라는 건, 앞서 살펴본 문맥 교환이 발생하지 않도록 하면서도 수많은 동시성 작업을 처리할 수 있다는 말이 됩니다. 게다가 한 가지 더 장점이 있는데요, 고루틴은 스택 메모리를 유연하게 사용합니다. 매우 작게 시작해서(2-4KB) 필요에 따라 늘리고 줄일 수 있게 설계되었습니다.

그러니까 OS 레벨의 스레드를 사용하는 경우,

graph TD
subgraph OS["OS 커널 (스케줄러)"]
direction LR
OSS["OS 스케줄러<br/>모든 스레드를 직접 관리<br/>⚠️ 비싼 문맥 교환"]
end
subgraph CPU["하드웨어 (4코어)"]
C1["코어 1"]
C2["코어 2"]
C3["코어 3"]
C4["코어 4"]
end
subgraph Threads["OS 스레드 (각 1-8 MB 고정 스택)"]
T1["스레드 1<br/>📦 1 MB 스택"]
T2["스레드 2<br/>📦 1 MB 스택"]
T3["스레드 3<br/>📦 1 MB 스택"]
T4["스레드 4<br/>📦 1 MB 스택"]
T5["스레드 5<br/>📦 1 MB 스택"]
T6["스레드 6<br/>📦 1 MB 스택"]
T7["스레드 7<br/>📦 1 MB 스택"]
T8["스레드 8<br/>📦 1 MB 스택"]
end
T1 & T2 & T3 & T4 & T5 & T6 & T7 & T8 -->|"OS 문맥 교환<br/>🐌 ~1-10 μs<br/>커널 모드 전환 + 레지스터 저장<br/>+ 캐시 플러시"| OSS
OSS --> C1 & C2 & C3 & C4
style OS fill:#8b0000,color:#fff
style CPU fill:#1a3a5c,color:#fff
style Threads fill:#2e2e1a,color:#fff

스레드의 문맥 교환 비용도 막대 하지만, 스레드의 개수 * 스택 메모리 를 계산해보면, 메모리 사용량 역시 부담이 되죠.

하지만 고루틴을 사용하는 경우,

graph TD
subgraph CPU["하드웨어 (4코어)"]
C1["코어 1"]
C2["코어 2"]
C3["코어 3"]
C4["코어 4"]
end
subgraph OSThreads["OS 스레드 (코어에 고정)"]
M1["OS 스레드 1<br/>(M)"]
M2["OS 스레드 2<br/>(M)"]
M3["OS 스레드 3<br/>(M)"]
M4["OS 스레드 4<br/>(M)"]
end
C1 --- M1
C2 --- M2
C3 --- M3
C4 --- M4
subgraph GoRuntime["Go 런타임 스케줄러 (유저 공간)"]
GS["Go 스케줄러<br/>⚡ 저비용 고루틴 전환<br/>스택 포인터만 교체"]
end
M1 & M2 & M3 & M4 --> GS
subgraph Goroutines["고루틴 (초기 스택 2-4 KB, 필요시 자동 확장)"]
G1["G1 🪶"]
G2["G2 🪶"]
G3["G3 🪶"]
G4["G4 🪶"]
G5["G5 🪶"]
G6["G6 🪶"]
G7["G7 🪶"]
G8["G8 🪶"]
G9["G9 🪶"]
G10["G10 🪶"]
G11["G11 🪶"]
G12["G12 🪶"]
GN["... 100K+ 🪶"]
end
GS --> G1 & G2 & G3 & G4 & G5 & G6 & G7 & G8 & G9 & G10 & G11 & G12 & GN
style CPU fill:#1a3a5c,color:#fff
style OSThreads fill:#2e1a2e,color:#fff
style GoRuntime fill:#2d5a27,color:#fff
style Goroutines fill:#1a2e1a,color:#fff

각 고루틴은 CPU의 커널 전환 같은 문맥 교환 없이 사용할 수 있으므로 스레드 전환에 비해 50-100배 정도 빠르고 메모리 사용량도 현저히 적습니다.

위 다이어그램에서는 간단하게 설명하기 위해서 마치 Go가 코어와 OS 스레드를 1:1 매핑 시키는 것 처럼 묘사했지만, 사실은 그렇지 않습니다. Go는 GMP(Goroutine-Machine-Processor) 스케쥴러를 사용하는데요, 이 스케쥴러는 OS 스레드(M)를 코어에 1:1 매핑하지는 않습니다. 실제로는 GOMAXPROCS 설정에 따라 논리적 프로세서(P)를 생성하고, 각 P는 OS 스레드(M)에 붙어서 고루틴(G)을 실행합니다. 그러니까 코어와 OS 스레드(M)가 1:N이 될 수도 있는거죠. 또한 특정 P의 대기열이 비면, 다른 P의 대기 중인 고루틴(G)을 빼앗아 올 수도 있습니다!

Java의 Project Loom(JDK 21)에서 지원하는 Virtual Thread가 이 고루틴을 구현한 것입니다!

동시성 처리 작업에 lock 걸기

자 지금까지 미래의 저를 위해서 스레드와 고루틴을 비교해서 적어봤는데요, 어떤 방법을 사용하든 동시성을 다루다 보면 상태 값을 어떻게 공유해야 할지 문제가 생깁니다. 스레드나 고루틴은 생성 순서가 처리 순서를 보장하지 못하기 때문에 예상하지 못한 결과가 나올 수 있죠. 그래서 먼저 접근 한 쪽이 처리 우선권을 가지도록 lock을 걸 필요가 있습니다.

// 노드 프로세스 관리를 위한 맵 정의
var (
 // 키 타입이 int이고, 값 타입이 *exec.Cmd인 맵
 processes = make(map[int]*exec.Cmd)
 // 맵에 대한 동시성 접근을 위한 뮤텍스(lock)
 processesMu sync.Mutex
)
...
// 여러 goroutine에서 동시에 접근할 수 있으므로, 동시성 접근을 위해 뮤텍스를 사용
processesMu.Lock()
processes[nc.id] = cmd
processesMu.Unlock()

Mutex를 통해 lock을 획득한 고루틴만 값을 변경할 수 있도록 하고 있습니다. lock은 필요한 작업을 마치면 반드시 해제 해야 하고, lock을 거는 시간은 최소화 해야 합니다. 따라서 다음과 같은 두 가지 패턴역시 이후 살펴볼 node.go 파일에서 등장합니다.

func (node *PaxosNode) runElection() {
 node.mu.Lock()
 ...
 allNodes := make([]string, len(node.allNodes))
 /**
 * lock은 최대한 짧게 유지하는게 중요하므로 필요한 작업 이후에 해제해야 함.
 * 따라서 이후 작업에 사용할 node.allNodes를 로컬 변수에 복사하여 사용.
 */
 copy(allNodes, node.allNodes)
 majority := node.majority
 nodeID := node.nodeID
 // lock 해제
 node.mu.Unlock()

 // 함수 종료시 리더 선출 상태를 초기화하기 위해 defer 처리
 defer func() {
 node.mu.Lock()
 node.electionInProgress = false
 node.mu.Unlock()
 }()
 ...
}

lock이 필요한 최소한의 작업을 진행하고 그 값을 로컬 변수에 복사. 그리고 lock을 해제하고, 이후의 작업에서는 복사한 로컬 변수로 현재 상태에 대한 작업 진행
함수 종료시 실행되어야 하는 작업을 defer로 감싸고 lock을 통해 상태 값을 변경

채널

채널은 고루틴끼리 서로 메세지를 주고 받을 수 있는 메세지 큐 같은 자료구조입니다. 이 코드에서는 다음과 같이 사용되고 있습니다.

func runCluster() {
 ...
 // goroutine 끼리 메세지를 주고받기 위한 채널 생성, 버퍼 크기를 1로 설정하여 수신자가 메세지를 받을 때까지 대기할 수 있도록 함
 sigChan := make(chan os.Signal, 1)
 // Ctrl+C 발생시 해당 시그널을 채널로 전달
 signal.Notify(sigChan, os.Interrupt)

 go func() {
 // 채널에서 메세지(Ctrl+C)를 받을 때까지 대기
 <-sigChan
 fmt.Print("\n\n🛑 모든 노드 종료...\n\n")
 // 모든 노드 프로세스에 SIGTERM 시그널 전송
 processesMu.Lock()
 for _, cmd := range processes {
 if cmd.Process != nil {
 cmd.Process.Signal(syscall.SIGTERM)
 }
 }
 processesMu.Unlock()
 time.Sleep(500 * time.Millisecond)
 os.Exit(0)
 }()
 ...
}

runCluster를 실행하는 메인 고루틴에서 프로그램 종료 시그널을 수신하면, 해당 시그널을 채널을 통해 고루틴에게 전송합니다. 그리고 시그널을 받은(<-sigChan) 고루틴은 각 프로세스에 종료 시그널을 전송해서 모든 노드가 종료될 수 있도록 합니다.

여기서 주목할 점은 채널을 생성할 때 버퍼 크기를 1로 설정해준 부분입니다. 만약 버퍼 크기가 없다면, 채널을 통해 전송한 메세지는 그 즉시 수신되어야 하며 수신자가 없다면 메세지를 전송한 고루틴은 수신자가 나타날 때 까지 계속 대기 하게됩니다. 그리고 만약 모든 고루틴이 메세지를 수신할 수 없는 상황이 된다면 deadlock이 발생하여 종료됩니다. 이후 node.go 파일에서 좀 더 다양한 채널의 사용 예시가 등장합니다!

즉시 실행 익명 함수(IIFE)로 defer 보장

printStatus 함수를 보면, 클러스터의 상태를 조회하기 위해 각 노드에 상태 조회 api 요청을 전송합니다. 그리고 api 응답을 닫기(close) 위해 defer를 사용하는데요, 이 작업이 항상 실행되도록 보장하기 위해 즉시 실행되는 익명 함수(IIFE, Immediately Invoked Function Express)를 사용하고 있습니다.

// 클러스터 상태 출력 함수
func printStatus() {
 fmt.Println("\n=== 클러스터 상태 ===")

 // 타임아웃이 1초인 http.Client 생성
 client := &http.Client{Timeout: 1 * time.Second}

 for _, node := range nodes {
 // 즉시 실행되는 익명 함수. 함수 종료시 defer 처리된 리소스 해제
 func() {
 url := fmt.Sprintf("http://localhost:%d/status", node.port)
 resp, err := client.Get(url)
 color := colors[node.id]

 if err != nil {
 fmt.Printf("%s 노드 %d: 다운%s\n", color, node.id, colorReset)
 return
 }
 // err 발생시 resp는 nil. 따라서 err 체크 후 defer 처리가 일반적인 방법.
 defer resp.Body.Close()

 var data StatusResponse
 // resp.Body를 JSON -> StatusResponse 타입으로 변환; 그리고 err 발생시 처리
 if err := json.NewDecoder(resp.Body).Decode(&data); err != nil {
 fmt.Printf("%s 노드 %d: (응답 파싱 실패)%s\n", color, node.id, colorReset)
 return
 }
 ...
 }()
 }
}

각 API 요청을 IIFE로 감싸면서 해당 함수가 끝날 때 defer된 defer resp.Body.Close() 가 실행될 수 있도록 하고 있습니다.

웹 서버 노드 구현

이제 웹 서버 노드의 구현을 확인해보겠습니다. 우선 node.go의 전체 코드는 다음과 같습니다.

package main

import (
 "bytes"
 "context"
 "encoding/json"
 "fmt"
 "math/rand/v2"
 "net/http"
 "os"
 "os/signal"
 "strconv"
 "strings"
 "sync"
 "syscall"
 "time"
)

// === 타입 정의 ===

type PrepareRequest struct {
 ProposalNumber int `json:"proposalNumber"`
}

type PrepareResponse struct {
 Promise bool `json:"promise"`
 AcceptedProposal *int `json:"acceptedProposal"`
 AcceptedValue *int `json:"acceptedValue"`
}

type AcceptRequest struct {
 ProposalNumber int `json:"proposalNumber"`
 Value int `json:"value"`
}

type AcceptResponse struct {
 Accepted bool `json:"accepted"`
}

type HeartbeatMessage struct {
 LeaderID int `json:"leaderId"`
 Term int `json:"term"`
}

type StatusResponse struct {
 NodeID int `json:"nodeId"`
 CurrentLeaderID *int `json:"currentLeaderId"`
 CurrentTerm int `json:"currentTerm"`
 PromisedProposal *int `json:"promisedProposal"`
 AcceptedProposal *int `json:"acceptedProposal"`
 AcceptedValue *int `json:"acceptedValue"`
 IsLeader bool `json:"isLeader"`
}

// === Paxos 노드 구조체 ===

// PaxosNode는 Paxos 노드의 모든 상태를 관리합니다.
type PaxosNode struct {
 mu sync.Mutex

 // 컨텍스트 (graceful shutdown 용도)
 ctx context.Context
 cancel context.CancelFunc

 // 설정
 nodeID int // 노드 아이디
 port int // 노드 포트
 peers []string // 통신해야 할 다른 노드의 URL 목록
 allNodes []string // 자신을 포함한 모든 노드의 URL 목록
 majority int // 다수 필요 개수 (전체 노드 수 / 2 + 1)

 // === Paxos Acceptor 상태 변수들 ===
 promisedProposal *int // 약속한 제안 번호 (nil = 아직 약속 없음)
 acceptedProposal *int // 수락된 제안 번호 (nil = 아직 수락 없음)
 acceptedValue *int // 수락된 값(리더의 노드 아이디) (nil = 아직 수락 없음)

 // === Leader 상태와 Heartbeat ===
 currentLeaderID *int // 현재 리더 아이디 (nil = 리더 없음)
 currentTerm int // 현재 턴
 electionRound int // 선거 라운드

 // === 타이머 ===
 heartbeatStop chan struct{} // 리더의 하트비트 전송 중지 시그널
 electionTimer *time.Timer // 하트비트 타임아웃 감시 타이머 (3~5초, 리더는 선출 후 중지)
 nextElectionTimer *time.Timer // 다음 선거 시작 타이머
 electionInProgress bool // 선거 진행 중 플래그 (동시 선거 방지)

 // HTTP 클라이언트
 httpClient *http.Client
}

// newPaxosNode는 새로운 Paxos 노드를 생성합니다.
// cli 매개변수로 전달받은 노드 아이디, 포트, 통신해야 할 다른 노드의 URL 목록 등의 값을 변수에 저장
func newPaxosNode(ctx context.Context, nodeID, port int, peers []string) *PaxosNode {
 ctx, cancel := context.WithCancel(ctx)
 selfURL := fmt.Sprintf("http://localhost:%d", port)
 allNodes := append([]string{selfURL}, peers...)
 majority := len(allNodes)/2 + 1

 return &PaxosNode{
 ctx: ctx,
 cancel: cancel,
 nodeID: nodeID,
 port: port,
 peers: peers,
 allNodes: allNodes,
 majority: majority,
 httpClient: &http.Client{Timeout: 1 * time.Second},
 }
}

// intPtr는 int를 *int로 변환하는 헬퍼 함수입니다.
func intPtr(v int) *int {
 return &v
}

// ceilDiv는 올림 나눗셈을 수행합니다.
func ceilDiv(a, b int) int {
 return (a + b - 1) / b
}

// === Paxos Proposer 로직 ===

// runElection은 리더 선출 시작
func (node *PaxosNode) runElection() {
 node.mu.Lock()
 // 이미 리더 선출 중인 경우
 if node.electionInProgress {
 node.mu.Unlock()
 // 리더 선출 중단
 return
 }
 node.electionInProgress = true

 // 제안 번호가 이미 있는 것보다 큰지 확인
 if node.promisedProposal != nil {
 /**
 * 이전에 약속된 제안 번호가 있는 경우, 라운드 조정(다른 노드가 이미 제안한 제안 번호보다 높은 제안 번호를 사용하도록 함)
 *
 * ex: max(0, ceilDiv(6, 3)) = max(0, 2) = 2
 */
 node.electionRound = max(node.electionRound, ceilDiv(*node.promisedProposal, len(node.allNodes)))
 }
 node.electionRound++

 /**
 * 제안 번호 = 노드 아이디 + (라운드 * 노드 개수) -> 각 라운드 마다 노드의 제안 번호의 고유성을 보장하기 위함
 *
 * 예를 들어, 노드 1, 2, 3이 있고, 라운드가 1인 경우,
 * 노드 1, 라운드 1: 1 + (1 * 3) = 4
 * 노드 2, 라운드 1: 2 + (1 * 3) = 5
 * 노드 3, 라운드 1: 3 + (1 * 3) = 6
 * 노드 1, 라운드 2: 1 + (2 * 3) = 7
 * 노드 2, 라운드 2: 2 + (2 * 3) = 8
 * 노드 3, 라운드 2: 3 + (2 * 3) = 9
 * ...
 */
 proposalNumber := node.nodeID + (node.electionRound * len(node.allNodes))
 allNodes := make([]string, len(node.allNodes))
 /**
 * lock은 최대한 짧게 유지하는게 중요하므로 필요한 작업 이후에 해제해야 함.
 * 따라서 이후 작업에 사용할 node.allNodes를 로컬 변수에 복사하여 사용.
 */
 copy(allNodes, node.allNodes)
 majority := node.majority
 nodeID := node.nodeID
 // lock 해제
 node.mu.Unlock()

 // 함수 종료시 리더 선출 상태를 초기화하기 위해 defer 처리
 defer func() {
 node.mu.Lock()
 node.electionInProgress = false
 node.mu.Unlock()
 }()

 fmt.Printf("\n[노드 %d] 🗳️ 리더 선출 시작 / 제안 번호 #%d\n", nodeID, proposalNumber)

 // === Phase 1: PREPARE 요청 전송 ===
 fmt.Printf("[노드 %d] Phase 1: 모든 노드에 PREPARE 요청 전송...\n", nodeID)

 type prepareResult struct {
 resp *PrepareResponse
 err error
 }
 results := make([]prepareResult, len(allNodes))
 var wg sync.WaitGroup

 // 자신을 포함한 모든 노드에 PREPARE 요청 전송
 for i, nodeURL := range allNodes {
 wg.Add(1)
 go func(idx int, url string) {
 defer wg.Done()
 resp, err := node.sendPrepare(url, proposalNumber)
 results[idx] = prepareResult{resp: resp, err: err}
 }(i, nodeURL)
 }
 wg.Wait()

 // PREPARE 요청 결과 처리 - 약속을 받은 것들만 추출
 var promises []PrepareResponse
 for _, r := range results {
 if r.err == nil && r.resp != nil && r.resp.Promise {
 promises = append(promises, *r.resp)
 }
 }

 fmt.Printf("[노드 %d] Phase 1: 약속을 받은 노드 %d/%d 개 (필요 %d 개)\n",
 nodeID, len(promises), len(allNodes), majority)

 if len(promises) < majority {
 fmt.Printf("[노드 %d] ❌ Phase 1 실패: 약속을 받은 노드가 다수 필요 개수보다 적습니다. 리더 선출을 중단하고 다음 선거 시작.\n", nodeID)
 node.scheduleNextElection()
 return
 }

 // 수락된 값 중 가장 높은 값을 채택, 없으면 자신을 제안
 proposedValue := nodeID
 highestAcceptedProposal := -1

 for _, p := range promises {
 // 수락된 값 중 가장 높은 값을 채택
 if p.AcceptedProposal != nil && *p.AcceptedProposal > highestAcceptedProposal {
 highestAcceptedProposal = *p.AcceptedProposal
 proposedValue = *p.AcceptedValue
 }
 }

 if highestAcceptedProposal > -1 {
 fmt.Printf("[노드 %d] Phase 1: 이전에 수락된 값 (노드 %d) 채택 / 제안 번호 #%d\n",
 nodeID, proposedValue, highestAcceptedProposal)
 } else {
 fmt.Printf("[노드 %d] Phase 1: 이전에 수락된 값이 없으므로 자신을 제안 (노드 %d)\n", nodeID, proposedValue)
 }

 // === Phase 2: Accept ===
 fmt.Printf("[노드 %d] Phase 2: 모든 노드에 ACCEPT (값: 노드 %d) 요청 전송...\n", nodeID, proposedValue)

 type acceptResult struct {
 resp *AcceptResponse
 err error
 }
 // ACCEPT 요청 결과를 저장할 슬라이스 생성
 acceptResults := make([]acceptResult, len(allNodes))
 // 모든 작업이 완료될 때까지 대기할 WaitGroup 생성
 wg = sync.WaitGroup{}

 // 자신을 포함한 모든 노드에 ACCEPT 요청 전송, 병렬 처리
 for i, nodeURL := range allNodes {
 // 대기 그룹에 작업 1개 추가
 wg.Add(1)
 // goroutine: ACCEPT 요청 전송
 go func(idx int, url string) {
 // 작업 완료시 대기 그룹에서 작업 1개 제거
 defer wg.Done()
 resp, err := node.sendAccept(url, proposalNumber, proposedValue)
 acceptResults[idx] = acceptResult{resp: resp, err: err}
 }(i, nodeURL)
 }
 // 모든 작업이 완료될 때까지 대기
 wg.Wait()

 // ACCEPT 요청 결과 처리 - 수락된 것들 카운트
 accepts := 0
 for _, r := range acceptResults {
 if r.err == nil && r.resp != nil && r.resp.Accepted {
 accepts++
 }
 }

 fmt.Printf("[노드 %d] Phase 2: 수락된 노드 %d/%d 개 (필요 %d 개)\n",
 nodeID, accepts, len(allNodes), majority)

 if accepts >= majority {
 fmt.Printf("[노드 %d] ✅ 리더 선출 성공! 노드 %d 가 리더가 되었습니다. (제안 번호 %d)\n",
 nodeID, proposedValue, proposalNumber)

 if proposedValue == nodeID {
 fmt.Printf("[노드 %d] 👑 나는 리더!\n", nodeID)
 // 리더는 자신의 선출 타임아웃을 중지 (팔로워만 타임아웃을 감시)
 node.mu.Lock()
 if node.electionTimer != nil {
 node.electionTimer.Stop()
 }
 node.mu.Unlock()
 node.startHeartbeat(proposalNumber)
 }
 } else {
 fmt.Printf("[노드 %d] ❌ Phase 2 실패: 수락된 노드가 다수 필요 개수보다 적습니다. 리더 선출을 중단하고 다음 선거 시작.\n", nodeID)
 node.scheduleNextElection()
 }
}

func (node *PaxosNode) sendPrepare(url string, proposalNumber int) (*PrepareResponse, error) {
 body, err := json.Marshal(PrepareRequest{ProposalNumber: proposalNumber})
 if err != nil {
 return nil, fmt.Errorf("marshal prepare request: %w", err)
 }

 req, err := http.NewRequestWithContext(node.ctx, "POST", url+"/paxos/prepare", bytes.NewReader(body))
 if err != nil {
 return nil, fmt.Errorf("create prepare request: %w", err)
 }
 req.Header.Set("Content-Type", "application/json")

 resp, err := node.httpClient.Do(req)
 if err != nil {
 return nil, fmt.Errorf("send prepare to %s: %w", url, err)
 }
 defer resp.Body.Close()

 if resp.StatusCode != http.StatusOK {
 return nil, fmt.Errorf("prepare request to %s returned status %d", url, resp.StatusCode)
 }

 var result PrepareResponse
 if err := json.NewDecoder(resp.Body).Decode(&result); err != nil {
 return nil, fmt.Errorf("decode prepare response from %s: %w", url, err)
 }

 return &result, nil
}

func (node *PaxosNode) sendAccept(url string, proposalNumber, value int) (*AcceptResponse, error) {
 body, err := json.Marshal(AcceptRequest{ProposalNumber: proposalNumber, Value: value})
 if err != nil {
 return nil, fmt.Errorf("marshal accept request: %w", err)
 }

 req, err := http.NewRequestWithContext(node.ctx, "POST", url+"/paxos/accept", bytes.NewReader(body))
 if err != nil {
 return nil, fmt.Errorf("create accept request: %w", err)
 }
 req.Header.Set("Content-Type", "application/json")

 resp, err := node.httpClient.Do(req)
 if err != nil {
 return nil, fmt.Errorf("send accept to %s: %w", url, err)
 }
 defer resp.Body.Close()

 if resp.StatusCode != http.StatusOK {
 return nil, fmt.Errorf("accept request to %s returned status %d", url, resp.StatusCode)
 }

 var result AcceptResponse
 if err := json.NewDecoder(resp.Body).Decode(&result); err != nil {
 return nil, fmt.Errorf("decode accept response from %s: %w", url, err)
 }

 return &result, nil
}

func (node *PaxosNode) sendHeartbeat(url string, leaderID, term int) error {
 body, err := json.Marshal(HeartbeatMessage{LeaderID: leaderID, Term: term})
 if err != nil {
 return fmt.Errorf("marshal heartbeat: %w", err)
 }

 req, err := http.NewRequestWithContext(node.ctx, "POST", url+"/leader/heartbeat", bytes.NewReader(body))
 if err != nil {
 return fmt.Errorf("create heartbeat request: %w", err)
 }
 req.Header.Set("Content-Type", "application/json")

 resp, err := node.httpClient.Do(req)
 if err != nil {
 return fmt.Errorf("send heartbeat to %s: %w", url, err)
 }
 defer resp.Body.Close()

 return nil
}

// 리더가 자신을 생존을 알리는 하트비트 전송을 시작하는 함수 (리더만 실행)
func (node *PaxosNode) startHeartbeat(term int) {
 node.mu.Lock()
 // 기존 하트비트 중지 (TOCTOU 경합 방지를 위해 인라인 처리)
 if node.heartbeatStop != nil {
 // 기존 하트비트 채널 종료
 close(node.heartbeatStop)
 }
 // 데이터는 없이 신호만 수신할 채널 생성
 stopCh := make(chan struct{})
 node.heartbeatStop = stopCh
 node.mu.Unlock()

 // goroutine: 각 채널의 메세지 수신 및 처리
 go func() {
 // 1초 간격 타이머 채널 생성
 ticker := time.NewTicker(1 * time.Second)
 // goroutine 종료시 타이머 종료
 defer ticker.Stop()

 for { // 종료될 때까지 무한 반복하는 이벤트 루프
 // 각 채널에서 수신되는 신호를 대기하며, 수신된 신호에 따라 동작 결정(select)
 select {
 case <-stopCh: // 하트비트 중지 신호
 return
 case <-node.ctx.Done(): // context 취소 신호
 return
 case <-ticker.C: // 1초 간격 타이머 채널 신호
 fmt.Printf("[노드 %d] 💓 하트비트 전송 (턴 %d)\n", node.nodeID, term)

 node.mu.Lock()
 // 이후 작업에 사용할 node.peers를 로컬 변수에 복사하여 사용
 peers := make([]string, len(node.peers))
 copy(peers, node.peers)
 // lock 해제
 node.mu.Unlock()

 // 자신(리더)를 제외한 나머지 노드에 하트비트 전송
 for _, peerURL := range peers {
 // goroutine: 하트비트 전송
 go func(url string) {
 _ = node.sendHeartbeat(url, node.nodeID, term)
 }(peerURL)
 }
 }
 }
 }()
}

// 하트비트 중지 처리 함수
func (node *PaxosNode) stopHeartbeat() {
 node.mu.Lock()
 if node.heartbeatStop != nil {
 close(node.heartbeatStop)
 node.heartbeatStop = nil
 }
 node.mu.Unlock()
}

// 모든 타이머와 하트비트를 정리하고 context를 취소하는 함수
func (node *PaxosNode) shutdown() {
 node.mu.Lock()
 if node.electionTimer != nil {
 node.electionTimer.Stop()
 }
 if node.nextElectionTimer != nil {
 node.nextElectionTimer.Stop()
 }
 node.mu.Unlock()
 node.stopHeartbeat()
 node.cancel()
}

// 리더 선출 타임아웃 리셋 처리 함수
//
// 타임아웃 이후, 리더가 없으면 리더 선출 시작
func (node *PaxosNode) resetElectionTimeout() {
 node.mu.Lock()
 defer node.mu.Unlock()

 if node.electionTimer != nil {
 // 기존 리더 선출 타이머 중지
 node.electionTimer.Stop()
 }

 // 리더 선출 타임아웃 랜덤 적용 (3-5초)
 timeout := 3*time.Second + time.Duration(rand.Float64()*2000)*time.Millisecond

 // goroutine: 리더 선출 타임아웃 타이머 설정
 node.electionTimer = time.AfterFunc(timeout, func() {
 fmt.Printf("[노드 %d] ⏰ 하트비트 타임아웃 - 리더 없음 감지, 리더 선출 시작...\n", node.nodeID)

 node.mu.Lock()
 node.currentLeaderID = nil
 // 현재 리더로 선출된 노드가 서비스 다운되는 경우에 해당 노드는 리더 선출에서 제외되어야 함
 // 따라서 수락된 상태를 리셋하여 진행하며, 각 리더 선출은 사실상 새로운 Paxos 인스턴스가 되도록 함
 node.acceptedProposal = nil
 node.acceptedValue = nil
 node.mu.Unlock()

 node.runElection()
 })
}

// 다음 리더 선출 예약 처리 함수
func (node *PaxosNode) scheduleNextElection() {
 node.mu.Lock()
 defer node.mu.Unlock()

 if node.nextElectionTimer != nil {
 // 기존 다음 리더 선출 타이머 중지
 node.nextElectionTimer.Stop()
 }

 // 다음 선거 시작 전 랜덤 딜레이 적용
 delay := 2*time.Second + time.Duration(rand.Float64()*3000)*time.Millisecond

 // goroutine: 다음 리더 선출 타이머 설정
 node.nextElectionTimer = time.AfterFunc(delay, func() {
 node.mu.Lock()
 hasLeader := node.currentLeaderID != nil
 node.mu.Unlock()

 // 현재 리더가 없으면 다음 선거 시작
 if !hasLeader {
 node.runElection()
 }
 })
}

// === HTTP 핸들러들 ===

// Paxos Phase 1: Prepare 요청 처리 함수
func (node *PaxosNode) handlePrepare(w http.ResponseWriter, r *http.Request) {
 // 요청 본문을 JSON -> PrepareRequest 타입으로 변환; 그리고 err 발생시 처리
 var req PrepareRequest
 if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
 http.Error(w, "bad request", http.StatusBadRequest)
 return
 }

 node.mu.Lock()
 fmt.Printf("[노드 %d] PREPARE 요청 수신 / 제안 번호 #%d\n", node.nodeID, req.ProposalNumber)

 // 함수 내부에서만 쓰이므로 포인터(*) 없이 사용
 var resp PrepareResponse

 if node.promisedProposal == nil || req.ProposalNumber > *node.promisedProposal {
 node.promisedProposal = intPtr(req.ProposalNumber)
 // 수락된 상태를 리셋하여 진행하며, 각 리더 선출은 사실상 새로운 Paxos 인스턴스가 되도록 함(죽은 리더 재선출 방지)
 node.acceptedProposal = nil
 node.acceptedValue = nil

 fmt.Printf("[노드 %d] → 제안 번호 #%d 약속\n", node.nodeID, req.ProposalNumber)
 resp = PrepareResponse{Promise: true, AcceptedProposal: nil, AcceptedValue: nil}
 } else {
 fmt.Printf("[노드 %d] → 이미 약속한 제안 번호 #%d 거절\n", node.nodeID, *node.promisedProposal)
 resp = PrepareResponse{Promise: false, AcceptedProposal: nil, AcceptedValue: nil}
 }
 node.mu.Unlock()

 w.Header().Set("Content-Type", "application/json")
 if err := json.NewEncoder(w).Encode(resp); err != nil {
 fmt.Printf("[노드 %d] 응답 쓰기 실패: %v\n", node.nodeID, err)
 }
}

// Paxos Phase 2: ACCEPT 요청 처리 함수
func (node *PaxosNode) handleAccept(w http.ResponseWriter, r *http.Request) {
 var req AcceptRequest
 if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
 http.Error(w, "bad request", http.StatusBadRequest)
 return
 }

 node.mu.Lock()
 fmt.Printf("[노드 %d] ACCEPT 요청 수신 / 제안 번호 #%d, 값: 노드 %d\n",
 node.nodeID, req.ProposalNumber, req.Value)

 var resp AcceptResponse

 // 약속된 제안 번호가 없거나, 현재 제안 번호가 약속된 제안 번호보다 크거나 같으면 수락
 if node.promisedProposal == nil || req.ProposalNumber >= *node.promisedProposal {
 // 약속된 제안 번호 갱신
 node.promisedProposal = intPtr(req.ProposalNumber)
 // 수락된 제안 번호 갱신
 node.acceptedProposal = intPtr(req.ProposalNumber)
 // 수락된 값 갱신(리더의 노드 아이디)
 node.acceptedValue = intPtr(req.Value)
 // 현재 리더 아이디 갱신
 node.currentLeaderID = intPtr(req.Value)
 // 현재 턴 갱신
 node.currentTerm = req.ProposalNumber

 fmt.Printf("[노드 %d] → 수락! 새로운 리더: 노드 %d (제안 번호 %d)\n",
 node.nodeID, req.Value, req.ProposalNumber)

 // 리더가 아니라면 하트비트 중지
 shouldStopHeartbeat := req.Value != node.nodeID
 node.mu.Unlock()

 if shouldStopHeartbeat {
 node.stopHeartbeat()
 }

 // 리더 선출 타임아웃 리셋
 node.resetElectionTimeout()

 resp = AcceptResponse{Accepted: true}
 } else {
 fmt.Printf("[노드 %d] → 이미 약속한 제안 번호 #%d 거절\n",
 node.nodeID, *node.promisedProposal)
 node.mu.Unlock()
 resp = AcceptResponse{Accepted: false}
 }

 w.Header().Set("Content-Type", "application/json")
 if err := json.NewEncoder(w).Encode(resp); err != nil {
 fmt.Printf("[노드 %d] 응답 쓰기 실패: %v\n", node.nodeID, err)
 }
}

// 리더가 전송하는 하트비트 수신 처리 함수
func (node *PaxosNode) handleHeartbeat(w http.ResponseWriter, r *http.Request) {
 var msg HeartbeatMessage
 if err := json.NewDecoder(r.Body).Decode(&msg); err != nil {
 http.Error(w, "bad request", http.StatusBadRequest)
 return
 }

 node.mu.Lock()
 // 새로운 턴이 시작되었다면,
 shouldReset := msg.Term >= node.currentTerm
 if shouldReset {
 // 새로운 리더가 등장했다면,
 if node.currentLeaderID == nil || *node.currentLeaderID != msg.LeaderID {
 fmt.Printf("[노드 %d] 💓 새로운 리더로부터 하트비트 수신 / 리더: 노드 %d (턴 %d)\n",
 node.nodeID, msg.LeaderID, msg.Term)
 }

 // 현재 리더 아이디 갱신
 node.currentLeaderID = intPtr(msg.LeaderID)
 // 현재 턴 갱신
 node.currentTerm = msg.Term
 }
 node.mu.Unlock()

 /**
 * 리더 선출 타임아웃 리셋(타임아웃 이후, 리더가 없으면 리더 선출 시작)
 *
 * 리더의 하트비트가 안정적으로 수신된다면, 리더 선출의 타임아웃은 계속 리셋된다. -> 현재 상태 유지.
 * 현재 턴 이상의 하트비트만 타임아웃 리셋 (오래된 리더의 하트비트는 무시)
 */
 if shouldReset {
 node.resetElectionTimeout()
 }

 w.Header().Set("Content-Type", "application/json")
 if err := json.NewEncoder(w).Encode(map[string]bool{"ok": true}); err != nil {
 fmt.Printf("[노드 %d] 응답 쓰기 실패: %v\n", node.nodeID, err)
 }
}

// 상태 조회 엔드포인트 처리 함수
func (node *PaxosNode) handleStatus(w http.ResponseWriter, r *http.Request) {
 node.mu.Lock()
 isLeader := node.currentLeaderID != nil && *node.currentLeaderID == node.nodeID
 resp := StatusResponse{
 NodeID: node.nodeID,
 CurrentLeaderID: node.currentLeaderID,
 CurrentTerm: node.currentTerm,
 PromisedProposal: node.promisedProposal,
 AcceptedProposal: node.acceptedProposal,
 AcceptedValue: node.acceptedValue,
 IsLeader: isLeader,
 }
 node.mu.Unlock()

 w.Header().Set("Content-Type", "application/json")
 if err := json.NewEncoder(w).Encode(resp); err != nil {
 fmt.Printf("[노드 %d] 응답 쓰기 실패: %v\n", node.nodeID, err)
 }
}

// === 메인 함수 ===

func runNode() {
 if len(os.Args) < 4 {
 fmt.Println("Usage: go run . node <id> <port> <peers...>")
 os.Exit(1)
 }

 nodeID, err := strconv.Atoi(os.Args[2])
 if err != nil {
 fmt.Fprintf(os.Stderr, "invalid node ID %q: %v\n", os.Args[2], err)
 os.Exit(1)
 }

 port, err := strconv.Atoi(os.Args[3])
 if err != nil {
 fmt.Fprintf(os.Stderr, "invalid port %q: %v\n", os.Args[3], err)
 os.Exit(1)
 }

 peers := os.Args[4:]

 ctx := context.Background()
 node := newPaxosNode(ctx, nodeID, port, peers)

 fmt.Printf("[노드 %d] 시작 with 통신해야 할 다른 노드의 URL 목록: %s\n",
 nodeID, strings.Join(peers, ", "))
 fmt.Printf("[노드 %d] 다수 필요: %d 중 %d 이상\n",
 nodeID, len(node.allNodes), node.majority)

 mux := http.NewServeMux()
 mux.HandleFunc("POST /paxos/prepare", node.handlePrepare)
 mux.HandleFunc("POST /paxos/accept", node.handleAccept)
 mux.HandleFunc("POST /leader/heartbeat", node.handleHeartbeat)
 mux.HandleFunc("GET /status", node.handleStatus)

 server := &http.Server{
 Addr: fmt.Sprintf(":%d", port),
 Handler: mux,
 }

 go func() {
 fmt.Printf("[노드 %d] 🚀 포트 %d에서 수신 중...\n", nodeID, port)
 if err := server.ListenAndServe(); err != nil && err != http.ErrServerClosed {
 fmt.Printf("[노드 %d] 서버 에러: %v\n", nodeID, err)
 os.Exit(1)
 }
 }()

 // 리더 선출 예약(랜덤 딜레이 적용)
 delay := 1*time.Second + time.Duration(rand.Float64()*2000)*time.Millisecond
 fmt.Printf("[노드 %d] 리더 조회 전 %dms 대기...\n", nodeID, delay.Milliseconds())

 // 랜덤 딜레이 이후, 리더가 없으면 리더 선출 시작
 time.AfterFunc(delay, func() {
 node.mu.Lock()
 hasLeader := node.currentLeaderID != nil
 node.mu.Unlock()

 if !hasLeader {
 fmt.Printf("[노드 %d] 리더 없음, 리더 선출 시작...\n", nodeID)
 node.runElection()
 }
 })

 // 리더 선출 타임아웃 리셋(타임아웃 이후, 리더가 없으면 리더 선출 시작)
 node.resetElectionTimeout()

 sigChan := make(chan os.Signal, 1)
 signal.Notify(sigChan, os.Interrupt, syscall.SIGTERM)
 <-sigChan

 fmt.Printf("[노드 %d] 종료 중...\n", nodeID)
 node.shutdown()

 shutdownCtx, shutdownCancel := context.WithTimeout(context.Background(), 2*time.Second)
 defer shutdownCancel()
 _ = server.Shutdown(shutdownCtx)
}

포인터를 이용한 nullable 필드(*int)

이제와서 뒷북이긴 하지만, Go는 포인터를 사용합니다! 하하하하… 그런데 정말 다행인 건 C, C++ 처럼 직접 메모리를 관리하거나 포인터 연산을 걱정할 필요는 없습니다. Go에서 포인터는 그저 모든 게 값인 세상에서 어떤 값을 참조로 사용할지 선택권을 주는 수단입니다. 포인터에 대한 자세한 설명은 다음으로 미루고, 일단 여기서는 nullable 필드를 눈 여겨 보도록 할까요?

type PaxosNode struct {
 ...
 // 설정
 nodeID int // 노드 아이디
 port int // 노드 포트
 peers []string // 통신해야 할 다른 노드의 URL 목록
 allNodes []string // 자신을 포함한 모든 노드의 URL 목록
 majority int // 다수 필요 개수 (전체 노드 수 / 2 + 1)

 // === Paxos Acceptor 상태 변수들 ===
 promisedProposal *int // 약속한 제안 번호 (nil = 아직 약속 없음)
 acceptedProposal *int // 수락된 제안 번호 (nil = 아직 수락 없음)
 acceptedValue *int // 수락된 값(리더의 노드 아이디) (nil = 아직 수락 없음)
 ...
}

똑같은 int 변수 지만 어떤 변수는 int로, 어떤 변수는 *int로 선언되었습니다. Go에서는 변수를 선언할 때 값을 선언하지 않으면 해당 변수 타입의 기본 값으로 초기화를 진행합니다. int의 경우 0이고, *int의 경우는 nil 이죠. 즉, 반드시 값이 존재하지만 초기값이 0인 변수와 값이 존재하지 않을 수도 있는 변수 를 선언하는 거죠.

모든 고루틴이 종료될 때까지 기다리는 WaitGroup

자신을 포함해서 모든 노드에 prepare를 전송하는 코드를 살펴보죠.

// === Phase 1: PREPARE 요청 전송 ===
fmt.Printf("[노드 %d] Phase 1: 모든 노드에 PREPARE 요청 전송...\n", nodeID)

type prepareResult struct {
 resp *PrepareResponse
 err error
}
results := make([]prepareResult, len(allNodes))
var wg sync.WaitGroup

// 자신을 포함한 모든 노드에 PREPARE 요청 전송 ----> 모든 요청을 병렬로 처리
for i, nodeURL := range allNodes {
 wg.Add(1) // 고루틴 시작전 ----> WaitGroup 1 증가
 go func(idx int, url string) {
 defer wg.Done() // 고루틴 종료시 작업 완료 ----> WaitGroup 1 감소
 resp, err := node.sendPrepare(url, proposalNumber)
 results[idx] = prepareResult{resp: resp, err: err}
 }(i, nodeURL)
}
wg.Wait() // 모든 작업이 완료될 때 까지 대기

각 고루틴을 실행하기 전에 Add로 작업 수를 증가시키고, 병렬로 실행되는 고루틴이 종료될 때(defer) Done으로 작업 완료 처리합니다. 그리고 Wait으로 모든 작업이 완료될 때까지 대기하게 되죠. node.js의 Promise.allSettled 와 닮았네요!

채널 select -> 채널을 위한 switch

리더가 자신의 생존을 다른 노드에게 알리는 startHeartbeat 함수를 보면, 여러 채널에서 수신되는 메세지에 따라 다른 동작을 수행하도록 하고 있습니다.

// 리더가 자신을 생존을 알리는 하트비트 전송을 시작하는 함수 (리더만 실행)
func (node *PaxosNode) startHeartbeat(term int) {
 node.mu.Lock()
 // 기존 하트비트 중지 (TOCTOU 경합 방지를 위해 인라인 처리)
 if node.heartbeatStop != nil {
 // 기존 하트비트 채널 종료
 close(node.heartbeatStop)
 }
 // 데이터는 없이 신호만 수신할 채널 생성
 stopCh := make(chan struct{})
 node.heartbeatStop = stopCh
 node.mu.Unlock()

 // goroutine: 각 채널의 메세지 수신 및 처리
 go func() {
 // 1초 간격 타이머 채널 생성
 ticker := time.NewTicker(1 * time.Second)
 // goroutine 종료시 타이머 종료
 defer ticker.Stop()

 for { // 종료될 때까지 무한 반복하는 이벤트 루프
 // 각 채널에서 수신되는 신호를 대기하며, 수신된 신호에 따라 동작 결정(select)
 select {
 case <-stopCh: // 하트비트 중지 신호
 return
 case <-node.ctx.Done(): // context 취소 신호
 return
 case <-ticker.C: // 1초 간격 타이머 채널 신호
 fmt.Printf("[노드 %d] 💓 하트비트 전송 (턴 %d)\n", node.nodeID, term)

 node.mu.Lock()
 // 이후 작업에 사용할 node.peers를 로컬 변수에 복사하여 사용
 peers := make([]string, len(node.peers))
 copy(peers, node.peers)
 // lock 해제
 node.mu.Unlock()

 // 자신(리더)를 제외한 나머지 노드에 하트비트 전송
 for _, peerURL := range peers {
 // goroutine: 하트비트 전송
 go func(url string) {
 _ = node.sendHeartbeat(url, node.nodeID, term)
 }(peerURL)
 }
 }
 }
 }()
}

// 하트비트 중지 처리 함수
func (node *PaxosNode) stopHeartbeat() {
 node.mu.Lock()
 if node.heartbeatStop != nil {
 close(node.heartbeatStop)
 node.heartbeatStop = nil
 }
 node.mu.Unlock()
}

고루틴 내부를 살펴보면 다음과 같이 동작하고 있습니다.

1초 간격의 타이머를 설정하고
무한 반복하는 이벤트 루프 시작
stopCh에 메세지가 들어오면, 이벤트 루프 중지하고 고루틴 종료
context 취소 메세지가 들어오면, 이벤트 루프 중지하고 고루틴 종료
1초 간격 타이머 메세지가 들어오면, 나머지 노드에 하트비트 전송

그리고 그 아래 stopHeartbeat를 보면 고루틴에서 수신하는 stopCh를 close 함수로 닫아버리는데요, 이렇게 하면 모든 수신자에게 중지 신호가 전달됩니다.

context.Context 로 우아한 종료(graceful shutdown)

새로운 노드를 실행하는 runNode, newPaxosNode 함수를 살펴보면, context와 해당 context를 중지시킬 수 있는 cancelFunc를 생성하여 이후 처리 과정에서 계속 사용하도록 전달하고 있습니다.

func newPaxosNode(ctx context.Context, nodeID, port int, peers []string) *PaxosNode {
 ctx, cancel := context.WithCancel(ctx) // context를 중지 시킬 수 있는 cancelFunc 생성
 selfURL := fmt.Sprintf("http://localhost:%d", port)
 allNodes := append([]string{selfURL}, peers...)
 majority := len(allNodes)/2 + 1

 return &PaxosNode{
 ctx: ctx,
 cancel: cancel, // 노드에 cancelFunc 전달
 nodeID: nodeID,
 port: port,
 peers: peers,
 allNodes: allNodes,
 majority: majority,
 httpClient: &http.Client{Timeout: 1 * time.Second},
 }
}

...

func runNode() {
 ...
 ctx := context.Background()
 node := newPaxosNode(ctx, nodeID, port, peers)
 ...
}

// 모든 타이머와 하트비트를 정리하고 context를 취소하는 함수
func (node *PaxosNode) shutdown() {
 ...
 node.cancel() // 노드 중지시 cancelFunc를 실행하여 모든 작업 중지
}

그리고 shutdown 함수를 보면, 노드의 cancelFunc를 실행하여 해당 context와 관련된 모든 작업(http 요청, 타이머, 고루틴 등)을 중지하도록 하고 있습니다.

참고자료

Tucker의 Go 언어 프로그래밍, 공봉식, 골든래빗
요즘 개발자를 위한 시스템 설계 수업. 디렌드라 신하, 테자스 초프라 저. 길벗
CLAUDE

go를 알아보자(1)

Sat, 10 Jan 2026 10:03:50 +0900

새해가 되고 뭔가 해야하지 않을까… 싶은 불안감이 커지던 중 평소에 node.js의 다음은 go 아니겠나 하고 생각하던 게 떠올랐습니다. 물론 node.js는 대체 불가입니다. 풀스택 개발자에게는 내 고향같은 편안함이 있죠. DB 부터 백엔드, 프론트까지 모든 스택을 하나로 다룰 수 있고 Typescript를 사용하면 정적 타입의 편안함까지 느낄 수 있죠.(물론 타입이 너무 복잡해서 아직도 잘 모릅니다… 하하하하…)

그런데 아무래도 만드는 제품을 on-premiss 솔루션화 하려다 보면, node.js 는 약간 어색함이 있습니다. 어쨌든 스크립트니까 코드가 그대로 노출된다는 단점이 있죠. 난독화를 하긴 하지만, 여전히 불안한 느낌은 있습니다. 물론 바이너리 역시도 100% 안전한 건 없지만, 뭐 그래도 말이죠.

하여간 이제 아주 천천히, 하던대로 go를 알아볼까 합니다. 평소에 많이 하던 코드를 go로 간단하게 작성해보면서 말이죠!

mongodb야 반갑다!

예, mongodb를 이용할 겁니다. 그리고 아주 간단하게 도큐먼트를 하나 집어넣고, 집어 넣은 도큐먼트를 다시 꺼내오는 작업을 할 겁니다.

go를 설치하자.

현재 go 최신버전은 1.25.5 입니다. 저는 맥에서 작성중이기 때문에 homebrew로 그냥 설치하면 됩니다.

> brew install go
> go version
go version go1.25.5 darwin/arm64

프로젝트 셋업

그리고 적당한 곳에 폴더를 생성합니다.

> mkdir mongodb-example
> cd mongodb-example
# go 모듈 초기화
> go mod init mongodb-example

그리고 가장 좋아하는 ide를 띄웁니다. 그러면 go.mod 파일이 하나 보일겁니다.

module test

go 1.25.5

모듈 이름과 go 버전이 보이는데요, 이 파일은 node.js의 package.json 같은 역할을 합니다. 일단 이번에 우리가 사용할 모듈을 설치해볼까요?

> go get go.mongodb.org/mongo-driver/v2/mongo
go: added github.com/golang/snappy v1.0.0
go: added github.com/klauspost/compress v1.16.7
go: added github.com/xdg-go/pbkdf2 v1.0.0
go: added github.com/xdg-go/scram v1.1.2
go: added github.com/xdg-go/stringprep v1.0.4
go: added github.com/youmark/pkcs8 v0.0.0-20240726163527-a2c0da244d78
go: added go.mongodb.org/mongo-driver/v2 v2.4.1
go: added golang.org/x/crypto v0.33.0
go: added golang.org/x/sync v0.11.0
go: added golang.org/x/text v0.22.0

자 그리고 다시 go.mod 파일을 보면!

module test

go 1.25.5

require (
 github.com/golang/snappy v1.0.0 // indirect
 github.com/klauspost/compress v1.16.7 // indirect
 github.com/xdg-go/pbkdf2 v1.0.0 // indirect
 github.com/xdg-go/scram v1.1.2 // indirect
 github.com/xdg-go/stringprep v1.0.4 // indirect
 github.com/youmark/pkcs8 v0.0.0-20240726163527-a2c0da244d78 // indirect
 go.mongodb.org/mongo-driver/v2 v2.4.1 // indirect
 golang.org/x/crypto v0.33.0 // indirect
 golang.org/x/sync v0.11.0 // indirect
 golang.org/x/text v0.22.0 // indirect
)

설치된 패키지 목록이 보입니다. package.json 이랑 진짜 비슷하죠? 근데 저 많은 // indirect 는 뭘까요?

그러니까 직접적으로 사용하는 모듈(go.mongodb.org/mongo-driver/v2)가 간접적으로 사용하는 모듈이라는 뜻입니다. 근데 왜 go.mongodb.org/mongo-driver/v2 도 // indirect 냐고요? 아직 이 모듈을 사용하는 코드가 없기 때문입니다!

그럼 코드를 작성해보자.

main.go를 작성할 차례입니다.

// 이 파일은 실행가능한 패키지라는 의미
package main

// 사용할 모듈을 임포트
import (
 "context"
 "fmt"
 "log"
 "time"

 "go.mongodb.org/mongo-driver/v2/bson"
 "go.mongodb.org/mongo-driver/v2/mongo"
 "go.mongodb.org/mongo-driver/v2/mongo/options"
)

// 프로그램의 진입점
func main() {
 /**
 * 컨텍스트는 일종의 프로그램의 실행 환경을 제어하는 객체
 * 컨텍스트에 10초 동안 아무런 신호가 전달되지 않으면 컨텍스트를 취소하고 프로그램을 종료
 * 특정 연산이 너무 오래걸리는 경우 무작정 대기하지 않도록 함
 *
 * := 는 한 줄로 변수를 선언하고 초기화 한다
 */
 ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
 // defer는 프로그램이 종료될 때 실행되도록 지연시킨다
 defer cancel()

 // mongodb에 연결
 client, err := mongo.Connect(options.Client().ApplyURI("mongodb://localhost:27017"))
 if err != nil {
 // log.Fatal은 오류가 발생하면 프로그램을 종료하고 오류 메시지를 출력
 log.Fatal(err)
 }
 // 프로그램이 종료될 때 연결을 끊기
 defer client.Disconnect(ctx)

 // mongodb 서버에 연결 확인, ping 성공시 컨텍스트가 취소되지 않고 계속 실행
 if err := client.Ping(ctx, nil); err != nil {
 log.Fatal(err)
 }
 fmt.Println("Connected to MongoDB")

 // users 컬렉션을 가져옴
 collection := client.Database("testdb").Collection("users")

 // bson.M은 자바스크립트 객체와 유사한 형태의 데이터를 저장하는 Binary JSON 형식
 user := bson.M{
 "name": "John Doe",
 "email": "john.doe@example.com",
 "age": 30,
 }

 // 사용자를 컬렉션에 삽입
 insertResult, err := collection.InsertOne(ctx, user)
 if err != nil {
 log.Fatal(err)
 }
 fmt.Println("User inserted with ID:", insertResult.InsertedID)

 // 이메일로 사용자를 찾음
 filter := bson.M{"email": "john.doe@example.com"}
 var result bson.M
 err = collection.FindOne(ctx, filter).Decode(&result)
 if err != nil {
 log.Fatal(err)
 }

 // 찾은 사용자 정보 출력
 fmt.Println("User found:", result)
}

코드를 보면 Go의 특징적인 에러 처리 패턴을 볼 수 있습니다.
if err != nil {
 log.Fatal(err)
}
다른 언어의 try-catch 와는 다르게, Go는 에러를 명시적으로 반환값으로 처리합니다. 이게 처음엔 좀 번거로워 보이지만, 에러가 발생할 수 있는 지점을 명확하게 알 수 있다는 장점이 있죠. 예외가 여러개 중첩 된 경우 예외가 어디서 발생한 건지 어렵게 찾을 필요가 없습니다!

그리고 코드를 실행할 때마다 같은 데이터가 계속 쌓이는 게 싫다면, 삽입 전에 기존 데이터를 삭제하는 코드를 추가할 수도 있습니다.
// 삽입 전에 기존 데이터 삭제 (선택사항)
_, err = collection.DeleteMany(ctx, bson.M{"email": "john.doe@example.com"})
if err != nil {
 log.Fatal(err)
}

그리고 go mod tidy 를 실행한 뒤 다시 go.mod 파일을 보면 다음과 같습니다.

module test

go 1.25.5

require go.mongodb.org/mongo-driver/v2 v2.4.1

require (
 github.com/golang/snappy v1.0.0 // indirect
 github.com/klauspost/compress v1.16.7 // indirect
 github.com/xdg-go/pbkdf2 v1.0.0 // indirect
 github.com/xdg-go/scram v1.1.2 // indirect
 github.com/xdg-go/stringprep v1.0.4 // indirect
 github.com/youmark/pkcs8 v0.0.0-20240726163527-a2c0da244d78 // indirect
 golang.org/x/crypto v0.33.0 // indirect
 golang.org/x/sync v0.11.0 // indirect
 golang.org/x/text v0.22.0 // indirect
)

직접 임포트해서 사용하는 go.mongodb.org/mongo-driver/v2 모듈이 // indirect 에서 독립했습니다!

mongodb를 띄우자.

간단한 docker-compose.yml 을 사용해서 mongodb를 띄울 겁니다. 프로젝트 루트 폴더(mongodb-example)에 docker-compose.yml 파일을 생성해주세요.

services:
 mongodb:
 image: mongo:latest
 ports:
 - "27017:27017"
 volumes:
 - mongodb_data:/data/db

volumes:
 mongodb_data:

이걸 이렇게 띄우죠.

> docker-compose up -d

이제 결과를 보자

이제 결과를 확인해볼까요?

> go run main.go
Connected to MongoDB
User inserted with ID: ObjectID("6961a3ea4f62d4037b2611bb")
User found: {"_id":{"$oid":"6961a3ea4f62d4037b2611bb"},"name":"John Doe","email":"john.doe@example.com","age":{"$numberInt":"30"}}

예… 이게 끝입니다. 처음이니까요. 하하하하하하.

실습 환경 정리하기

실습이 끝났으면 깔끔하게 정리해줍시다. MongoDB 컨테이너를 종료하고 데이터까지 삭제하려면 다음 명령어를 실행하면 됩니다.

> docker-compose down -v

-v 옵션은 볼륨까지 삭제한다는 의미입니다. 실습용 데이터니까 깔끔하게 지워버리는 게 속이 시원하죠!

참고자료

MongoDB Go Driver
Perplexity와 Claude

Go on 엔지니어 생존기록

SIMD를 알아보자(feat. Go)

Go 환경설정

1. 래퍼 프로그램 설치

2. ~/go/bin 을 PATH에 설정하기

3. 실제 SDK 다운로드

4. 버전 확인하기

5. SIMD 지원 확인하기

6. 설정 삭제하기

테스트용 코드 작성하기

1. 폴더와 모듈 생성

2. 테스트에 사용할 2개의 연산 커널

2-1. 합 구하기

2-2. 삼차 다항식 계산

3. 커널 구현하기(kernels.go)

4. SIMD 커널 구현하기(kernel_simd.go)

4-1. SumSIMDSingle 함수

4-2. SumSIMDUnrolled4 함수

4-3. SumSIMDUnrolled8 함수

4-4. PolySIMD 함수

5. 대체 커널 구현하기(kernel_stub.go)

6. 테스트 작성하기(kernel_test.go)

테스트와 벤치마크 돌려보기

결과 한 줄 해부하기

10번 재서 통계로 판정하기

결과가 말해주는 것

후속 실험: Poly도 unroll 해보기

마지막 실험: core는 다 쓰고 있었을까?

마치면서

참고자료

go를 알아보자(3) - 포인터

포인터…

nil 포인터 - 아무것도 가리키지 않는 포인터

스택(stack) vs 힙(heap)

값 타입(value type) vs 참조 타입(reference type)

구조체도 헷갈리게…

구조체의 메서드 정의

new() 와 &Counter{} - 둘 다 구조체 포인터를 만들어요

참고자료

go를 알아보자(2) - gRPC

gRPC란?

그냥 한 번 해보자!

폴더 생성 및 go 모듈을 초기화

gRPC 계약(contract) 작성

gRPC 코드 생성

서버 코드 작성

클라이언트 코드 작성

서버와 클라이언트 실행

정리

분산 시스템 설계(1) - Paxos 심화(분산 Key-Value 스토어)

간략한 소개

Paxos Prepare-Accept를 통한 리더 선출

Paxos Accept를 통한 key-value 전파

정리

분산 시스템 설계(1) - Paxos 알고리즘(GO)

코드 실행 방법

프로그램 진입점 구현

클러스터 관리자 cli 구현

map 타입

동시성 처리 및 lock 걸기

스레드와 고루틴 비교

동시성 처리 작업에 lock 걸기

채널

즉시 실행 익명 함수(IIFE)로 defer 보장

웹 서버 노드 구현

포인터를 이용한 nullable 필드(*int)

모든 고루틴이 종료될 때까지 기다리는 WaitGroup

채널 select -> 채널을 위한 switch

context.Context 로 우아한 종료(graceful shutdown)

참고자료

go를 알아보자(1)

mongodb야 반갑다!

go를 설치하자.

프로젝트 셋업

그럼 코드를 작성해보자.

mongodb를 띄우자.

이제 결과를 보자

실습 환경 정리하기

참고자료

2. `~/go/bin` 을 PATH에 설정하기

`new()` 와 `&Counter{}` - 둘 다 구조체 포인터를 만들어요