Go는 동시성 안전성에 두 가지 접근을 제공합니다: channel("통신하여 메모리를 공유하라")과 sync 패키지(공유 메모리를 직접 보호하는 mutex/잠금). Go의 channel 우선 철학에도 불구하고, sync 기본 요소는 공유 상태를 보호하는 데 종종 더 단순하고 효율적인 선택입니다.
Counter {
mu sync.Mutex
count
}
Increment() {
c.mu.Lock()
c.mu.Unlock()
c.count++
}
Mutex는 한 번에 하나의 goroutine만 보호된 데이터에 접근하도록 보장하여 데이터 경쟁을 방지합니다. Lock()/defer Unlock() 패턴이 관용적입니다.
type Cache struct {
mu sync.RWMutex
data map[string]string
}
func (c *Cache) Get(key string) string {
c.mu.RLock() // 읽기 잠금 — 여러 읽기 동시 허용
defer c.mu.RUnlock()
return c.data[key]
}
func (c *Cache) Set(key, value string) {
c.mu.Lock() // 쓰기 잠금 — 배타적
defer c.mu.Unlock()
c.data[key] = value
}
RWMutex는 동시 읽기를 허용하되 배타적 쓰기를 강제합니다 — 캐시처럼 읽기가 많은 데이터에 이상적입니다.
sync.WaitGroup // goroutine 그룹의 완료를 대기(Add/Done/Wait)
sync.Once // 무언가를 정확히 한 번 실행(지연 초기화, 싱글톤)
var once sync.Once
once.Do(initialize) // initialize는 최초 호출 시에만, 영원히 한 번만 실행
sync.Map // 동시 map(특수한 경우)
atomic.AddInt64(&n, 1) // 간단한 카운터를 위한 잠금 없는 원자적 연산
sync(Mutex/RWMutex/atomic)를 쓸 때:
✓ 간단한 공유 상태 보호(카운터, 캐시, map)
✓ 로직이 "이 데이터를 지켜라"일 때 — 여기서는 잠금이 channel보다 단순하고 빠름
✓ 읽기 많은 데이터(RWMutex), 일회성 초기화(Once), 간단한 카운터(atomic)
channel을 쓸 때:
✓ goroutine 간 통신/데이터 전달, 신호, 조율
✓ 파이프라인, 워커 분배, 소유권 이전
실무 규칙: "메모리를 공유하여 통신하지 말라"는 지침이지 교리가 아닙니다. 공유 상태를 단순히 보호하는 경우, mutex가 로직을 channel로 비트는 것보다 명확하고 효율적입니다.
sync 패키지를 channel 대신 언제 쓸지 아는 것은 Go 동시성 성숙도의 핵심 표지입니다.
Go가 channel("통신하여 메모리를 공유하라")을 권장하지만 이는 지침이며 — 단순한 mutex가 더 명확하고 빠를 곳에 channel을 억지로 쓰는 것이 흔한 실수입니다.
sync 패키지는 공유 상태 보호(카운터, 캐시, map)에 올바르고 관용적인 도구입니다: 배타적 접근을 위한 mutex, 읽기 많은 데이터를 위한 RWMutex, goroutine 대기를 위한 WaitGroup, 일회성 초기화를 위한 Once, 특수 경우를 위한 atomic/sync.Map.
channel이 통신과 조율에 탁월하고 sync 기본 요소가 공유 메모리 보호에 탁월하다는 점을 이해하고 — 교리적으로 channel을 쓰기보다 적절한 도구를 선택하는 것 — 은 더 단순하고 효율적이며 올바른 동시 코드로 이어집니다.
이 판단력이 바로 경험 있는 Go 개발자를 구분 짓는 것이며 자주 나오는 고급 면접 주제입니다.