C++ 개발자의 뇌 구조로 이해하는 Go 언어

들어가며: “이건 C++로 하면 이렇게 했는데”

C++에 익숙한 개발자가 Go를 배울 때, 메모리 관리(RAII vs GC), 타입 시스템(템플릿 vs 인터페이스), 에러 처리(예외 vs 반환값)에서 “C++로는 이렇게 했는데 Go에서는?”이 반복됩니다. 이 글은 C++ 관점을 기준으로 Go의 개념을 매핑해, 전환을 빠르게 하는 데 도움을 줍니다. Go 입문서라기보다 C++ 개발자를 위한 대응표에 가깝습니다. 관련 글: C++ #6 RAII·스마트 포인터, C++ vs Go 성능·동시성.

---

C++에서 Go로 넘어갈 때 막히는 질문들

C++ 개발자가 Go로 전환할 때 겪는 대표적인 상황을 정리했습니다.

flowchart TD
    subgraph Cpp[C++ 습관]
        A1[RAII/스마트 포인터]
        A2[예외 throw/catch]
        A3[템플릿/상속]
        A4["std thread/뮤텍스"]
    end
    subgraph Go[Go 환경]
        B1[GC/defer]
        B2[error 반환]
        B3[인터페이스]
        B4[고루틴/채널]
    end
    A1 -.->|매핑 필요| B1
    A2 -.->|매핑 필요| B2
    A3 -.->|매핑 필요| B3
    A4 -.->|매핑 필요| B4

파일은 어디서 닫나요?

상황: C++에서는 RAII로 std::ifstream이 스코프를 벗어나면 자동으로 닫혔습니다. Go에서는 os.Open()으로 열었는데, return 전에 Close()를 호출해야 하는지, 예외(panic)가 나면 어떻게 되나 헷갈립니다. 원인: Go에는 소멸자(RAII)가 없습니다. defer로 “함수 탈출 시 실행”을 등록해야 합니다. 해결: 파일을 연 직후 defer f.Close()를 씁니다. defer는 “이 함수가 끝날 때 실행해라”라고 예약하는 문법이라서, 정상 return으로 나가든 panic으로 나가든 상관없이 함수가 끝나기 직전에 Close()가 호출됩니다. (C++ RAII의 “스코프를 벗어나면 정리”와 비슷한 효과입니다.)

에러를 매번 if로 확인해야 하나요?

상황: C++에서는 try/catch로 한 곳에서 에러를 처리했습니다. Go에서는 if err != nil이 매 함수마다 반복되어 코드가 지저분해 보입니다. 원인: Go는 예외를 사용하지 않으며, 에러를 값으로 반환하는 철학을 택했습니다. 호출자가 명시적으로 처리해야 합니다. 해결: if err != nil { return err } 패턴을 익히고, 에러 래핑(fmt.Errorf("context: %w", err))으로 컨텍스트를 추가합니다.

템플릿은 어떻게 옮기나요?

상황: C++에서는 template<typename T>로 타입에 무관한 함수를 만들었습니다. Go에서는 제네릭이 1.18부터 생겼지만, C++ 템플릿처럼 복잡한 메타프로그래밍은 안 됩니다. 원인: Go 제네릭은 타입 파라미터 + 인터페이스 제약으로 단순하게 설계되었습니다. 컴파일 타임 다형성은 제한적입니다. 해결: 제네릭이 필요한 곳은 [T any] 또는 [T comparable]로 타입 파라미터를 쓰며, 인터페이스로 제약을 둡니다. 런타임 다형성은 인터페이스로 처리합니다.

뮤텍스는 그대로 쓰나요?

상황: C++에서는 std::thread + std::mutex로 공유 메모리를 보호했습니다. Go의 고루틴은 “경량 스레드”인데, 뮤텍스는 그대로 쓰나요? 원인: Go에도 sync.Mutex가 있지만, “공유 메모리를 피하고 채널로 통신하라”는 철학(Do not communicate by sharing memory; instead, share memory by communicating)을 권장합니다. 해결: 가능하면 채널로 데이터를 전달하며, 꼭 필요할 때만 sync.Mutex를 사용합니다.

포인터와 값 중 무엇으로 넘기나요?

상황: C++에서는 복사 비용을 피하려 포인터나 참조를 썼습니다. Go에서는 *T와 T가 모두 있는데, 언제 무엇을 써야 할지 모르겠습니다. 원인: Go는 값에 의한 전달이 기본입니다. 큰 구조체는 포인터로 넘기고, 작은 값·인터페이스는 값으로 넘기는 것이 관례입니다. 메서드 리시버도 (t *T)와 (t T) 중 선택합니다. 해결: 메서드가 필드를 수정하면 *T 리시버를 씁니다. 수정하지 않더라도 한 타입의 메서드 중 하나라도 *T라면 나머지도 *T로 맞추는 것이 Go 커뮤니티의 관례입니다. 구조체가 커서 복사 비용이 신경 쓰이면 포인터로 넘기되, 몇 바이트부터인지는 정해진 기준이 없으므로 프로파일링으로 판단합니다.

---

메모리: RAII·스마트 포인터 → GC·defer

C++: RAII와 스마트 포인터

• 소유권: unique_ptr로 “누가 해제하는지” 명확히 함. shared_ptr은 공유가 꼭 필요할 때만.
• 리소스: 파일·락은 생성자에서 획득, 소멸자에서 해제(RAII). 예외가 나도 스택 언와인딩으로 정리됩니다.

Go: GC와 defer

• 힙 할당: new나 &T{}로 만든 객체는 GC가 수거합니다. “누가 free하는지”를 신경 쓸 필요가 없습니다. 다만 순환 참조가 있어도 GC가 돌지만, 불필요한 참조를 오래 들고 있으면 GC 부담이 커질 수 있습니다.
• 리소스 정리: defer로 “함수 탈출 시(return·panic 포함) 실행할 정리 코드”를 등록합니다. C++의 RAII처럼 “반드시 한 번” 실행되므로, 파일 닫기·락 해제를 defer에 넣는 패턴이 Go의 RAII 대용입니다. C++ RAII 예시:

// C++: RAII로 파일 자동 닫기
#include <iostream>
#include <fstream>
void process_file() {
    std::ifstream f("file.txt");
    if (!f) {
        std::cerr << "open failed\n";
        return;
    }
    // 스코프를 벗어나면 f 소멸자에서 자동 close (RAII)
    std::string line;
    while (std::getline(f, line)) {
        std::cout << line << "\n";
    }
    // return 시 f의 소멸자가 파일을 닫음
}

Go defer 예시:

// Go: defer로 파일 닫기 (RAII 대용)
func processFile() error {
    f, err := os.Open("file.txt")
    if err != nil {
        return err
    }
    defer f.Close() // 함수 반환 시 무조건 실행 (return, panic 모두)
    scanner := bufio.NewScanner(f)
    for scanner.Scan() {
        fmt.Println(scanner.Text())
    }
    return scanner.Err()
}

주의: C++처럼 “이 스코프를 벗어나면 자동 해제”가 아니라 함수 단위입니다. 루프 안에서 매 반복마다 리소스를 열고 닫을 때는 블록을 나누거나 반복마다 defer를 쓰면 안 됩니다(함수 반환 시에만 실행되므로). 명시적으로 Close를 호출하는 편이 맞습니다. 루프 안에서 잘못된 defer 사용:

// ❌ 잘못된 예: 루프 안 defer - 함수가 끝날 때까지 파일이 닫히지 않음
func processManyFiles(paths []string) error {
    for _, path := range paths {
        f, err := os.Open(path)
        if err != nil {
            return err
        }
        defer f.Close() // 모든 파일이 함수 종료 시 한꺼번에 닫힘 - 리소스 누수!
        // ... 처리 ...
    }
    return nil
}

루프 안에서 올바른 리소스 처리:

// ✅ 올바른 예: 루프 안에서는 명시적 Close
// 함수 정의 및 구현
func processManyFiles(paths []string) error {
    for _, path := range paths {
        f, err := os.Open(path)
        if err != nil {
            return err
        }
        // 처리 후 즉시 닫기
        err = doProcess(f)
        f.Close()
        if err != nil {
            return err
        }
    }
    return nil
}

unique_ptr·shared_ptr·RAII 대응표

C++	Go
unique_ptr	그냥 값·포인터, GC가 수거
shared_ptr	참조 카운팅 없음, GC가 순환 참조도 수거
RAII (생성자/소멸자)	defer + 명시적 Close
소유권 명시	관례(캡슐화·패키지 내 사용)

---

타입·다형성: 템플릿·가상 → 인터페이스

C++: 템플릿과 가상 함수

• 템플릿: 컴파일 타임에 타입이 정해지고, 다형성 없이 인라인·전문화로 성능을 냅니다. “타입이 다르면 다른 코드”가 생성됩니다.
• 가상 함수·상속: 런타임 다형성. 기반 클래스 포인터로 파생 클래스를 다룹니다.

Go: 인터페이스와 제네릭

• 제네릭(Go 1.18+): 타입 파라미터로 “어떤 타입이든 받는” 함수·구조체를 만들 수 있습니다. C++ 템플릿만큼 복잡한 메타프로그래밍은 없으며, 타입 제약은 인터페이스로 표현합니다.
• 인터페이스: 메서드 집합만 정의하며, 그 메서드들을 구현한 타입은 별도 선언 없이 그 인터페이스를 만족합니다(덕 타이핑). C++의 “기반 클래스 + 가상 함수” 대신 “인터페이스 + 메서드 구현”으로 다형성을 씁니다. C++ 가상 함수·상속:

// C++: 가상 함수와 상속
class Reader {
public:
    virtual int Read(char* buf, int size) = 0;
    virtual ~Reader() = default;
};
class FileReader : public Reader {
public:
    int Read(char* buf, int size) override {
        return fread(buf, 1, size, file_);
    }
private:
    FILE* file_;
};
void process(Reader* r) {
    char buf[1024];
    r->Read(buf, sizeof(buf));
}

Go 인터페이스:

// Go: 인터페이스 (명시적 implements 없음)
// 타입 정의
type Reader interface {
    Read(p []byte) (n int, err error)
}
// *os.File은 Read를 가지므로 Reader로 사용 가능 (덕 타이핑)
func process(r io.Reader) {
    buf := make([]byte, 1024)
    r.Read(buf)
}
// 사용
f, _ := os.Open("file.txt")
process(f) // *os.File은 io.Reader를 만족

C++ 템플릿:

// C++: 템플릿
template<typename T>
T add(T a, T b) {
    return a + b;
}
// 사용
int x = add(1, 2);
double y = add(1.0, 2.0);

Go 제네릭:

// Go: 제네릭 (1.18+)
func Add[T ~int | ~float64](a, b T) T {
    return a + b
}
// 사용
x := Add(1, 2)     // int
y := Add(1.0, 2.0) // float64

구조체 임베딩: 내장 타입의 메서드가 “포함”되므로, 상속처럼 메서드를 물려받는 효과. 오버라이드는 같은 이름 메서드를 정의하면 됩니다.

// Go: 구조체 임베딩
// 타입 정의
type Reader struct{}
func (Reader) Read(p []byte) (n int, err error) {
    return 0, nil
}
type FileReader struct {
    Reader // 임베딩 - Reader의 메서드가 FileReader에 포함됨
    path   string
}
// FileReader는 Read 메서드를 자동으로 가짐

템플릿·상속 대응표

C++	Go
템플릿	제네릭 + 인터페이스 제약
가상 함수·상속	인터페이스 + 구조체 임베딩
명시적 상속 관계	암묵적 인터페이스 만족 (덕 타이핑)

---

에러·리소스: 예외 → error 반환·defer

C++: throw와 RAII

• 예외: 오류 시 throw, 호출자가 try/catch. 스택이 풀리면서 자동으로 정리(RAII).
• 에러 코드: 반환값으로 성공/실패를 넘기는 방식도 있음.

Go: error 반환과 defer

• 예외 없음(일반적인 흐름): error 타입을 반환합니다. if err != nil { return err } 패턴이 반복됩니다. 호출하는 쪽에서 매번 에러를 확인해야 합니다.
• panic/recover: 예외와 비슷하게 “복구 가능한 패닉”에만 제한적으로 사용. 일반 에러는 반환값으로 다룹니다.
• 리소스 정리: defer로 파일 닫기·락 해제를 보장. panic이 나도 defer는 실행됩니다. C++ 예외:

// C++: 예외
void mightThrow() {
    throw std::runtime_error("something went wrong");
}
void caller() {
    try {
        mightThrow();
    } catch (const std::exception& e) {
        std::cerr << "Error: " << e.what() << "\n";
    }
}

Go error 반환:

// Go: error 반환
func mightFail() error {
    return fmt.Errorf("something went wrong")
}
func caller() error {
    if err := mightFail(); err != nil {
        return fmt.Errorf("caller: %w", err) // 에러 래핑
    }
    return nil
}

에러 래핑과 errors.Is/As:

// Go: 에러 래핑 및 검사
var ErrNotFound = errors.New("not found")
func findUser(id int) (*User, error) {
    user, err := db.Query(id)
    if err != nil {
        return nil, fmt.Errorf("findUser id=%d: %w", id, err)
    }
    if user == nil {
        return nil, ErrNotFound
    }
    return user, nil
}
func handler() error {
    user, err := findUser(1)
    if errors.Is(err, ErrNotFound) {
        return fmt.Errorf("user not found")
    }
    if err != nil {
        return err
    }
    // user 사용
    return nil
}

panic/recover (제한적 사용):

// Go: panic/recover - 일반적으로 지양, 복구 가능한 경우만
// 함수 정의 및 구현
func safeCall(fn func()) (err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("panic recovered: %v", r)
        }
    }()
    fn()
    return nil
}

예외·에러 대응표

C++	Go
throw / try-catch	error 반환, if err != nil
RAII로 정리	defer로 정리
예외 전파	err 반환 체인
std::exception	error 인터페이스

---

동시성: 스레드·뮤텍스 → 고루틴·채널

C++: std::thread와 mutex

• 스레드: std::thread로 OS 스레드 생성. 기본 스택은 OS 설정에 따라 다르며 리눅스는 보통 8MB, 윈도우는 1MB를 예약합니다.
• 동기화: std::mutex, std::condition_variable, std::atomic.
• 패턴: 공유 메모리 + 락으로 보호.

Go: 고루틴과 채널

• 고루틴: go f()로 경량 스레드 생성. 작은 스택(현재 구현은 2KB)으로 시작해 필요하면 늘어나고, 런타임이 많은 고루틴을 적은 OS 스레드에 배치하는 M:N 스케줄링을 합니다.
• 채널: chan T로 고루틴 간 데이터 전달. “공유 메모리보다 통신으로” 권장.
• 동기화: sync.Mutex, sync.WaitGroup, sync.Once 등. C++ 스레드 + 뮤텍스:

// C++: 스레드와 뮤텍스
#include <thread>
#include <mutex>
#include <vector>
std::mutex mtx;
int counter = 0;
void increment() {
    std::lock_guard<std::mutex> lock(mtx);
    ++counter;
}
int main() {
    std::vector<std::thread> threads;
    for (int i = 0; i < 10; ++i) {
        threads.emplace_back(increment);
    }
    for (auto& t : threads) {
        t.join();
    }
    return 0;
}

Go 고루틴 + 채널:

// Go: 고루틴과 채널 (권장 패턴)
func main() {
    ch := make(chan int)
    go func() {
        ch <- 1 // 전송
    }()
    result := <-ch // 수신
    fmt.Println(result)
}

Go: 여러 고루틴 결과 수집:

// Go: 채널로 결과 수집
func fetchAll(urls []string) []string {
    ch := make(chan string, len(urls))
    for _, url := range urls {
        go func(u string) {
            resp, err := http.Get(u)
            if err != nil {
                ch <- "" // 실패해도 반드시 하나를 보내야 수신 루프가 멈추지 않음
                return
            }
            defer resp.Body.Close() // err를 확인한 뒤에 defer: 실패 시 resp는 nil
            body, err := io.ReadAll(resp.Body)
            if err != nil {
                ch <- ""
                return
            }
            ch <- string(body)
        }(url)
    }
    results := make([]string, 0, len(urls))
    for i := 0; i < len(urls); i++ {
        results = append(results, <-ch)
    }
    return results
}

Go: Mutex (필요할 때):

// Go: sync.Mutex (공유 메모리가 꼭 필요할 때)
var (
    mu      sync.Mutex
    counter int
)
func increment() {
    mu.Lock()
    defer mu.Unlock()
    counter++
}

스레드·동기화 대응표

C++	Go
std::thread	go 키워드 (고루틴)
std::mutex	sync.Mutex
std::condition_variable	채널 또는 sync.Cond
공유 메모리 + 락	채널 통신 우선, 락은 보조

---

변수·포인터·반복문·메서드 문법 대응

변수·상수

C++	Go
int x = 1;	x := 1 또는 var x int = 1
const int c = 42;	const c = 42
auto x = getValue();	x := getValue()

포인터

C++	Go
int* p = &x;	p := &x
*p = 2	*p = 2
nullptr	nil

반복문

// C++
for (int i = 0; i < 10; i++) { }
for (auto& x : vec) { }
while (cond) { }

// Go
for i := 0; i < 10; i++ { }
for i, x := range slice { }
for cond { }
// while 없음 - for cond { } 사용

조건문

// C++
if (x > 0) { }
if (auto it = m.find(k); it != m.end()) { }

// Go
if x > 0 { }
if v, ok := m[k]; ok { }

구조체

// C++
struct Point {
    int x, y;
};
Point p{1, 2};

// Go
type Point struct {
    X, Y int
}
p := Point{1, 2}
// 또는 p := Point{X: 1, Y: 2}

메서드

// C++
class Counter {
    int n;
public:
    void Inc() { n++; }
    int Get() const { return n; }
};

// Go
type Counter struct {
    n int
}
func (c *Counter) Inc() { c.n++ }
func (c *Counter) Get() int { return c.n }

---

defer 순서, 루프 변수 클로저, nil 슬라이스: C++ 개발자가 자주 하는 실수

defer 호출 순서와 인자 평가 시점

defer는 LIFO(나중에 등록된 것이 먼저 실행)입니다. 이는 C++에서 지역 객체가 생성의 역순으로 소멸하는 것과 같은 순서라서, 먼저 연 리소스가 나중에 닫힙니다. C++ 개발자가 실제로 자주 틀리는 것은 순서보다 인자 평가 시점입니다. defer 문의 인자는 등록하는 순간 평가되고, 함수 호출만 나중에 일어납니다.

defer fmt.Println("1")
defer fmt.Println("2")
// 출력: 2, 1 (등록 역순)

x := 1
defer fmt.Println(x) // 1이 출력됨: x는 등록 시점에 평가
x = 2

defer func() { fmt.Println(x) }() // 2가 출력됨: 클로저는 실행 시점의 x를 읽음

루프 변수 클로저

Go 1.21까지는 for 루프 변수가 루프 전체에서 하나의 변수였기 때문에, 고루틴이 루프 변수를 캡처하면 대부분 마지막 값을 보게 되었습니다. Go 1.22부터는 반복마다 새 변수가 만들어지도록 의미가 바뀌어, 아래 코드도 0~4를 (순서는 보장되지 않지만) 한 번씩 출력합니다. 단, 이 동작은 go.mod의 go 지시어가 1.22 이상일 때 적용되므로, 오래된 모듈이나 예전 코드를 읽을 때는 여전히 알아 둘 필요가 있습니다.

// go.mod가 go 1.21 이하라면 5가 여러 번 출력될 수 있음
for i := 0; i < 5; i++ {
    go func() {
        fmt.Println(i)
    }()
}

// 버전과 무관하게 안전한 예: 인자로 값을 넘김
for i := 0; i < 5; i++ {
    go func(n int) {
        fmt.Println(n)
    }(i)
}

두 예제 모두 main이 고루틴을 기다리지 않으면 아무것도 출력되지 않고 끝날 수 있으므로, 실제로는 sync.WaitGroup으로 기다려야 합니다.

nil 슬라이스 vs 빈 슬라이스

문제: nil 슬라이스와 []T{}는 JSON 직렬화 시 다르게 동작할 수 있습니다. nil은 null, 빈 슬라이스는 []로 직렬화됩니다.

// nil 슬라이스
var s []int        // s == nil, len(s) == 0
// 빈 슬라이스
s := []int{}       // s != nil, len(s) == 0
s := make([]int, 0) // s != nil, len(s) == 0

포인터 리시버 vs 값 리시버

문제: 값 리시버 메서드는 복사본에서 실행되므로 필드를 바꿔도 원본에 반영되지 않습니다. 또 포인터 리시버로 구현한 메서드는 T 값의 메서드 집합에 포함되지 않으므로, var s Stringer = Counter{}처럼 값을 인터페이스에 넣으면 “Counter does not implement … (method has pointer receiver)” 컴파일 에러가 납니다. 이때는 &Counter{}를 넣어야 합니다.

// ❌ 값 리시버 - 메서드가 필드를 수정해도 원본에 반영 안 됨
func (c Counter) Inc() { c.n++ }
// ✅ 포인터 리시버 - 수정이 필요할 때
func (c *Counter) Inc() { c.n++ }

채널 닫기 누락

문제: 채널을 닫지 않으면 수신자가 영원히 대기할 수 있습니다. 송신자가 더 이상 보낼 것이 없으면 close(ch)를 호출합니다.

// ✅ 채널 닫기
ch := make(chan int)
go func() {
    defer close(ch)
    for i := 0; i < 10; i++ {
        ch <- i
    }
}()
for v := range ch {
    fmt.Println(v)
}

error 무시

문제: Go에서는 에러를 반드시 처리해야 합니다. _로 무시하면 나중에 디버깅이 어려워집니다.

// ❌ 에러 무시
f, _ := os.Open("file.txt")
// ✅ 에러 처리
f, err := os.Open("file.txt")
if err != nil {
    return fmt.Errorf("open file: %w", err)
}

---

단계별 Go 학습 순서

C++ 개발자를 위한 단계별 Go 학습 로드맵입니다.

flowchart TD
    A[1. 기본 문법] --> B[2. 패키지·모듈]
    B --> C[3. 에러 처리]
    C --> D[4. 인터페이스]
    D --> E[5. 동시성]
    E --> F[6. 실전 프로젝트]

1단계: 기본 문법 (1~2일)

• Tour of Go 공식 투어
• 변수, 함수, 반복문, 조건문
• 구조체, 메서드, 포인터
• 슬라이스, 맵

2단계: 패키지·모듈 (1일)

• go mod init, go mod tidy
• 패키지 임포트, export (대문자/소문자)
• 표준 라이브러리 탐색: fmt, os, io, net/http

3단계: 에러 처리 (1일)

• error 타입, if err != nil
• fmt.Errorf와 %w 래핑
• errors.Is, errors.As

4단계: 인터페이스 (2~3일)

• io.Reader, io.Writer
• 커스텀 인터페이스 정의
• 구조체 임베딩

5단계: 동시성 (3~5일)

• 고루틴, 채널
• select, 버퍼 채널
• sync.Mutex, sync.WaitGroup
• 컨텍스트(context.Context)

6단계: 실전 프로젝트 (1~2주)

• CLI 도구 (예: 파일 처리, HTTP 클라이언트)

• 간단한 REST API 서버

• 기존 C++ 프로젝트의 일부를 Go로 재작성 추천 자료:

• Effective Go

• Go by Example

• Uber Go Style Guide

---

Functional Options·context·워커 풀: Go 실무 패턴

옵션 함수 (Functional Options)

생성자에 많은 인자가 필요할 때, 옵션 함수로 유연하게 설정합니다.

// Go: Functional Options 패턴
type Server struct {
    host string
    port int
}
type Option func(*Server)
func WithHost(host string) Option {
    return func(s *Server) {
        s.host = host
    }
}
func WithPort(port int) Option {
    return func(s *Server) {
        s.port = port
    }
}
func NewServer(opts ...Option) *Server {
    s := &Server{host: "localhost", port: 8080}
    for _, opt := range opts {
        opt(s)
    }
    return s
}
// 사용
srv := NewServer(WithHost("0.0.0.0"), WithPort(9000))

컨텍스트로 취소·타임아웃

고루틴에 취소 신호와 타임아웃을 전달합니다.

// Go: context로 취소·타임아웃
func fetchWithTimeout(ctx context.Context, url string) ([]byte, error) {
    ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
    defer cancel()
    req, err := http.NewRequestWithContext(ctx, "GET", url, nil)
    if err != nil {
        return nil, err
    }
    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()
    return io.ReadAll(resp.Body)
}

워커 풀

CPU 바운드 작업을 코어 수만큼의 워커로 분배합니다.

// Go: 워커 풀
type Job struct{ ID int }
type Result struct{ Value int }
func process(j Job) Result {
    return Result{Value: j.ID * 2}
}
func processJobs(jobs []Job) {
    numWorkers := runtime.NumCPU()
    jobCh := make(chan Job, len(jobs))
    resultCh := make(chan Result, len(jobs))
    for i := 0; i < numWorkers; i++ {
        go func() {
            for job := range jobCh {
                resultCh <- process(job)
            }
        }()
    }
    for _, job := range jobs {
        jobCh <- job
    }
    close(jobCh)
    for i := 0; i < len(jobs); i++ {
        <-resultCh
    }
}

의존성 주입 (인터페이스)

테스트 가능한 코드를 위해 인터페이스로 의존성을 주입합니다.

// Go: 인터페이스로 의존성 주입
type UserStore interface {
    Get(id int) (*User, error)
    Save(u *User) error
}
type Service struct {
    store UserStore
}
func NewService(store UserStore) *Service {
    return &Service{store: store}
}
// 테스트 시 Mock 구현체 주입
type mockStore struct{}
func (m *mockStore) Get(id int) (*User, error) { return &User{}, nil }
func (m *mockStore) Save(u *User) error { return nil }

에러 체인과 로깅

에러를 래핑하면서 로깅합니다.

// Go: 에러 체인 + 로깅
func handleRequest(w http.ResponseWriter, r *http.Request) {
    if err := doWork(r); err != nil {
        log.Printf("handleRequest failed: %v", err)
        http.Error(w, "internal error", http.StatusInternalServerError)
        return
    }
}
func doWork(r *http.Request) error {
    if err := validate(r); err != nil {
        return fmt.Errorf("validate: %w", err)
    }
    if err := process(r); err != nil {
        return fmt.Errorf("process: %w", err)
    }
    return nil
}

---

같이 보면 좋은 글

• C++ 개발자를 위한 2주 완성 Go 커리큘럼 · Go 시리즈 전체 목차
• [Go 심화 #09] context·우아한 종료
• C++ RAII: 생성자에서 획득하고 소멸자에서 해제하는 자원 관리 클래스 만들기
• C++ vs Go | 성능·동시성·선택 가이드 완전 비교 [#47-1]
• C++ std::thread 입문 | join 누락·디태치 남용 등 자주 하는 실수 3가지와 해결법
• C++ vs Rust: 소유권, 메모리 안전성, 에러 처리, 동시성, 성능 비교
• C++ 개발자가 보는 Rust 메모리 안전성

---

자주 묻는 질문 (FAQ)

Q. C++와 Go를 같이 쓸 수 있나요?

A. 네. cgo로 C/C++ 코드를 Go에서 호출할 수 있지만, cgo 오버헤드와 크로스 컴파일 복잡도가 있습니다. 마이크로서비스 아키텍처에서는 C++ 서비스와 Go 서비스를 나눠 배포하는 방식이 더 흔합니다.

Q. Go에서 RAII처럼 리소스를 관리하는 방법은?

A. defer가 RAII 대용입니다. defer f.Close()처럼 리소스 획득 직후에 defer로 해제를 등록합니다. panic이 나도 defer는 실행됩니다.

Q. Go 제네릭이 C++ 템플릿보다 제한적인 이유는?

A. Go는 컴파일 속도와 단순성을 우선했습니다. C++ 템플릿의 SFINAE, 특수화, 메타프로그래밍은 Go에서 지원하지 않습니다. 대신 인터페이스로 런타임 다형성을 처리합니다.

Q. 프로덕션에서 Go를 선택하는 기준은?

A. 웹 API, 마이크로서비스, CLI, DevOps 도구, 컨테이너/쿠버네티스 관련 도구에 적합합니다. 극저지연(HFT), 메모리 제약이 극심한 임베디드에는 C++/Rust가 더 적합할 수 있습니다.

---

다음 글: [C++ vs 타 언어 #47-3] C++ 개발자가 보는 Rust 메모리 안전성: 소유권, Borrow Checker, 수명, unsafe 경계 이전 글: [C++ vs 타 언어 #47-1] C++ vs Go: 성능 및 동시성 모델 실전 비교