C++ 개발자의 뇌 구조로 이해하는 Go 언어 [#47-2]

· 18분 읽기 · 수정 중급 개념
C++ 개발자의 뇌 구조로 이해하는 Go 언어 [#47-2]

이 글의 핵심

RAII, 스마트 포인터, 템플릿에 익숙한 C++ 사고방식을 Go의 가비지 컬렉션(GC)과 인터페이스 환경에 맞게 매핑하는 방법을 다룹니다. 문제 시나리오, C++ vs Go 완전 비교, 자주 하는 실수, 학습 경로, 프로덕션 패턴까지.

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

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

이 글에서 다루는 것:

  • 문제 시나리오: C++→Go 전환 시 겪는 실제 상황
  • 메모리: RAII·스마트 포인터 vs GC·defer
  • 타입·다형성: 템플릿·가상 함수 vs 인터페이스·구조체 임베딩
  • 에러·리소스: 예외 vs error 반환, defer로 정리
  • 동시성: std::thread·뮤텍스 vs 고루틴·채널
  • 자주 하는 실수: C++ 습관이 Go에서 문제가 되는 경우
  • 학습 경로: 단계별 Go 학습 로드맵
  • 프로덕션 패턴: 실전에서 쓰는 Go 설계 패턴

관련 글: C++ #6 RAII·스마트 포인터, C++ vs Go 성능·동시성.

개념을 잡는 비유

이 글의 주제는 여러 부품이 맞물리는 시스템으로 보시면 이해가 빠릅니다. 한 레이어(저장·네트워크·관측)의 선택이 옆 레이어에도 영향을 주므로, 본문에서는 트레이드오프를 숫자와 패턴으로 정리합니다.

목차

  1. 문제 시나리오: C++→Go 전환 시 겪는 상황
  2. 메모리: RAII·스마트 포인터 → GC·defer
  3. 타입·다형성: 템플릿·가상 → 인터페이스
  4. 에러·리소스: 예외 → error 반환·defer
  5. 동시성: 스레드·뮤텍스 → 고루틴·채널
  6. 문법 비교: C++ vs Go 완전 대응표
  7. 자주 하는 실수
  8. 학습 경로
  9. 프로덕션 패턴
  10. 정리: C++→Go 체크리스트

1. 문제 시나리오: 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

시나리오 1: “파일 닫기를 어디서 해야 하지?”

상황: C++에서는 RAII로 std::ifstream이 스코프를 벗어나면 자동으로 닫혔습니다. Go에서는 os.Open()으로 열었는데, return 전에 Close()를 호출해야 하는지, 예외(panic)가 나면 어떻게 되나 헷갈립니다.

원인: Go에는 소멸자(RAII)가 없습니다. defer로 “함수 탈출 시 실행”을 등록해야 합니다.

해결: 파일을 연 직후 defer f.Close()를 씁니다. defer는 “이 함수가 끝날 때 실행해라”라고 예약하는 문법이라서, 정상 return으로 나가든 panic으로 나가든 상관없이 함수가 끝나기 직전에 Close()가 호출됩니다. (C++ RAII의 “스코프를 벗어나면 정리”와 비슷한 효과입니다.)

시나리오 2: “에러를 매번 if로 체크하는 게 맞나?”

상황: C++에서는 try/catch로 한 곳에서 에러를 처리했습니다. Go에서는 if err != nil이 매 함수마다 반복되어 코드가 지저분해 보입니다.

원인: Go는 예외를 사용하지 않고, 에러를 값으로 반환하는 철학을 택했습니다. 호출자가 명시적으로 처리해야 합니다.

해결: if err != nil { return err } 패턴을 익히고, 에러 래핑(fmt.Errorf("context: %w", err))으로 컨텍스트를 추가합니다.

시나리오 3: “템플릿 대신 뭘 쓰지?”

상황: C++에서는 template<typename T>로 타입에 무관한 함수를 만들었습니다. Go에서는 제네릭이 1.18부터 생겼지만, C++ 템플릿처럼 복잡한 메타프로그래밍은 안 됩니다.

원인: Go 제네릭은 타입 파라미터 + 인터페이스 제약으로 단순하게 설계되었습니다. 컴파일 타임 다형성은 제한적입니다.

해결: 제네릭이 필요한 곳은 [T any] 또는 [T comparable]로 타입 파라미터를 쓰고, 인터페이스로 제약을 둡니다. 런타임 다형성은 인터페이스로 처리합니다.

시나리오 4: “스레드 대신 고루틴을 쓰면 뮤텍스는?”

상황: C++에서는 std::thread + std::mutex로 공유 메모리를 보호했습니다. Go의 고루틴은 “경량 스레드”인데, 뮤텍스는 그대로 쓰나요?

원인: Go에도 sync.Mutex가 있지만, “공유 메모리를 피하고 채널로 통신하라”는 철학(Do not communicate by sharing memory; instead, share memory by communicating)을 권장합니다.

해결: 가능하면 채널로 데이터를 전달하고, 꼭 필요할 때만 sync.Mutex를 사용합니다.

시나리오 5: “포인터를 써야 하나, 값으로 써야 하나?”

상황: C++에서는 복사 비용을 피하려 포인터나 참조를 썼습니다. Go에서는 *T와 T가 모두 있는데, 언제 무엇을 써야 할지 모르겠습니다.

원인: Go는 값에 의한 전달이 기본입니다. 큰 구조체는 포인터로 넘기고, 작은 값·인터페이스는 값으로 넘기는 것이 관례입니다. 메서드 리시버도 (t *T)와 (t T) 중 선택합니다.

해결: 메서드가 필드를 수정하면 *T, 수정하지 않으면 T 또는 *T(일관성). 64바이트 이상 구조체는 포인터 전달을 고려합니다.

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

C++에서의 습관

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

Go에서의 대응

  • 힙 할당: 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.Close() 호출됨
}

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
}

매핑 요약

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

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

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
템플릿제네릭 + 인터페이스 제약
가상 함수·상속인터페이스 + 구조체 임베딩
명시적 상속 관계암묵적 인터페이스 만족 (덕 타이핑)

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

C++에서의 습관

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

Go에서의 대응

  • 예외 없음(일반적인 흐름): 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-catcherror 반환, if err != nil
RAII로 정리defer로 정리
예외 전파err 반환 체인
std::exceptionerror 인터페이스

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

C++에서의 습관

  • 스레드: std::thread로 OS 스레드 생성. 스레드당 1~8MB 스택.
  • 동기화: std::mutex, std::condition_variable, std::atomic.
  • 패턴: 공유 메모리 + 락으로 보호.

Go에서의 대응

  • 고루틴: go f()로 경량 스레드 생성. 고루틴당 수 KB 스택, 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, _ := http.Get(u)
            defer resp.Body.Close()
            body, _ := io.ReadAll(resp.Body)
            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::threadgo 키워드 (고루틴)
std::mutexsync.Mutex
std::condition_variable채널 또는 sync.Cond
공유 메모리 + 락채널 통신 우선, 락은 보조

6. 문법 비교: C++ vs Go 완전 대응표

변수·상수

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
nullptrnil

반복문

// 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 }

7. 자주 하는 실수

실수 1: defer 호출 순서 오해

문제: defer는 LIFO(나중에 등록된 것이 먼저 실행)입니다. C++ 소멸자 순서와 반대일 수 있습니다.

// ❌ 의도와 다를 수 있음
defer fmt.Println("1")
defer fmt.Println("2")
// 출력: 2, 1 (등록 역순)
// ✅ 리소스 정리 순서가 중요하면 명시적으로
f1, _ := os.Open("a.txt")
f2, _ := os.Open("b.txt")
defer func() {
    f2.Close()
    f1.Close()
}()

실수 2: 루프 변수 클로저

문제: 고루틴에서 루프 변수를 캡처하면, 고루틴이 실행될 때는 이미 루프가 끝나 있어 마지막 값만 참조합니다.

// ❌ 잘못된 예
for i := 0; i < 5; i++ {
    go func() {
        fmt.Println(i) // 항상 5 출력 (또는 비결정적)
    }()
}
// ✅ 올바른 예
for i := 0; i < 5; i++ {
    go func(n int) {
        fmt.Println(n)
    }(i) // i를 인자로 전달
}

실수 3: 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

실수 4: 포인터 리시버 vs 값 리시버

문제: 인터페이스에 값 리시버로 구현한 타입을 넣으면, 인터페이스가 값을 복사해 들고 있어서 포인터 메서드가 호출되지 않을 수 있습니다. 일관되게 *T 리시버를 쓰는 것이 안전합니다.

// ❌ 값 리시버 - 메서드가 필드를 수정해도 원본에 반영 안 됨
func (c Counter) Inc() { c.n++ }

// ✅ 포인터 리시버 - 수정이 필요할 때
func (c *Counter) Inc() { c.n++ }

실수 5: 채널 닫기 누락

문제: 채널을 닫지 않으면 수신자가 영원히 대기할 수 있습니다. 송신자가 더 이상 보낼 것이 없으면 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)
}

실수 6: error 무시

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

// ❌ 에러 무시
f, _ := os.Open("file.txt")

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

8. 학습 경로

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로 재작성

추천 자료:

9. 프로덕션 패턴

패턴 1: 옵션 함수 (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))

패턴 2: 컨텍스트로 취소·타임아웃

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

// 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)
}

패턴 3: 워커 풀

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
    }
}

패턴 4: 의존성 주입 (인터페이스)

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

// 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 }

패턴 5: 에러 체인과 로깅

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

// 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
}

10. 정리: C++→Go 체크리스트

메모리·리소스

  • “해제는 GC가 한다”고 받아들이기
  • 파일·락 등 리소스는 defer로 정리
  • 루프 안에서는 defer 대신 명시적 Close

타입·다형성

  • “인터페이스 = 메서드 집합”으로 이해
  • 구현 타입은 선언 없이 인터페이스 만족 (덕 타이핑)
  • 제네릭은 [T any] 또는 인터페이스 제약

에러

  • 예외 대신 error 반환과 if err != nil
  • 에러 래핑: fmt.Errorf("context: %w", err)
  • errors.Is, errors.As로 에러 검사

동시성

  • “공유 메모리 최소화·메시지 전달” 사고 전환
  • 채널 우선, sync.Mutex는 필요 시
  • 루프 변수 클로저 주의 (인자로 전달)
  • 채널 사용 후 close 호출

일반

  • 포인터 vs 값: 수정 필요 시 *T, 64바이트 이상은 포인터 고려
  • 에러 무시 금지 (_ 사용 지양)

같이 보면 좋은 글 (내부 링크)

이 주제와 연결되는 다른 글입니다.

  • C++ 개발자를 위한 2주 완성 Go 커리큘럼 · Go 시리즈 전체 목차
  • [Go 심화 #09] context·우아한 종료
  • C++ RAII | “파일을 열 수 없습니다” 장애의 원인과 자동 리소스 관리
  • C++ vs Go | 성능·동시성·선택 가이드 완전 비교 [#47-1]
  • C++ std::thread 입문 | join 누락·디태치 남용 등 자주 하는 실수 3가지와 해결법

이 글에서 다루는 키워드 (관련 검색어)

C++ 개발자 Go, Go 배우기, C++ Go 비교, RAII vs GC, Go 인터페이스, 고루틴 채널 등으로 검색하시면 이 글이 도움이 됩니다.

자주 묻는 질문 (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++ 관점에서 Go의 GC·defer·인터페이스·고루틴·채널을 이해하면 전환이 수월합니다. 다음으로 Rust vs C++(#47-3)를 읽어보면 좋습니다.

다음 글: [C++ vs 타 언어 #47-3] Rust vs C++ 메모리 안전성 비교: 컴파일러가 잡아내는 오류의 차이

이전 글: [C++ vs 타 언어 #47-1] C++ vs Go: 성능 및 동시성 모델 실전 비교

관련 글

  • C++ vs Go | 성능·동시성·선택 가이드 완전 비교 [#47-1]
  • C++ vs Rust 완전 비교 | 소유권·메모리 안전성·에러 처리·동시성·성능 실전 가이드
  • Rust vs C++ 메모리 안전성 | 컴파일러 오류 차이 [#47-3]
  • Rust 메모리 안전성 완벽 가이드 | 소유권·Borrow checker·수명·unsafe 실전
  • C++ 개발자를 위한 2주 완성 Go 언어(Golang) 마스터 커리큘럼