Go 네이밍 컨벤션 제대로 정리해봤어요 — 이름 짓기가 코드 품질의 절반입니다

왜 이름 짓기가 그렇게 중요할까요

Go를 처음 배우면 문법 자체는 꽤 간결해서 빠르게 익힐 수 있는데요, 막상 실무 코드를 작성하다 보면 의외로 막히는 부분이 있어요. 바로 이름 짓기예요. 변수명, 함수명, 패키지명을 어떻게 정하느냐에 따라 코드의 가독성이 완전히 달라지거든요. Go는 다른 언어와 달리 대문자·소문자가 접근 제어(public/private)를 결정하기 때문에, 네이밍이 단순한 스타일 문제가 아니라 언어의 핵심 기능과 직결돼요.

Alex Edwards가 정리한 Go 네이밍 컨벤션 가이드가 이 부분을 아주 체계적으로 다루고 있어서, 핵심 내용을 한국 개발자 시각에서 풀어보려고 해요.

패키지 이름: 짧고 명확하게

Go에서 패키지 이름은 다른 언어의 네임스페이스와 비슷한 역할을 하는데요, 중요한 차이가 있어요. Go에서는 패키지 이름이 호출할 때 항상 접두사로 붙는다는 거예요. 예를 들어 http.Server처럼 쓰이기 때문에, 패키지 이름 자체가 맥락을 제공해요.

그래서 패키지 이름은 소문자, 한 단어, 짧은 것이 좋아요. httputil처럼 간결하게. http_util이나 httpUtil처럼 언더스코어나 camelCase를 쓰는 건 Go 스타일이 아니에요. 또 하나 중요한 건, 패키지 이름과 내부 타입 이름이 겹치지 않게 하는 거예요. http 패키지 안에 HTTPServer라고 이름 붙이면 http.HTTPServer가 되어서 중복이 생기잖아요. 그냥 http.Server가 훨씬 깔끔하죠.

이게 뭐냐면, Go 커뮤니티에서는 "패키지 이름이 이미 문맥을 제공하니까, 그 안의 식별자에서 패키지 이름을 반복하지 마라"는 원칙을 stuttering(말더듬) 방지라고 부르거든요. encoding/json 패키지의 json.Decoder가 좋은 예시예요. json.JSONDecoder라고 하지 않잖아요.

변수와 함수: MixedCaps가 기본

Go에서는 변수명과 함수명에 MixedCaps(또는 mixedCaps)를 써요. 이게 뭐냐면 단어 경계를 대문자로 구분하는 방식인데, 첫 글자가 대문자면 패키지 외부에서 접근 가능하고(exported), 소문자면 패키지 내부에서만 쓸 수 있어요(unexported). 다른 언어의 public/private 키워드 없이 대소문자만으로 접근 제어를 하는 거예요.

예를 들어 ProcessOrder는 외부에 공개되는 함수이고, processOrder는 내부 전용이에요. 이 규칙은 타입, 상수, 인터페이스 등 모든 식별자에 동일하게 적용돼요.

변수명의 길이에 대한 Go 커뮤니티의 관습도 독특한데요. 스코프가 짧으면 이름도 짧게, 스코프가 길면 이름도 설명적으로 짓는 게 권장돼요. for 루프 안에서 인덱스에 i를 쓰는 건 전혀 문제없지만, 패키지 레벨 변수라면 requestTimeout처럼 의미를 명확히 담아야 하는 거죠.

흔히 보이는 관용적 약어들도 있어요. ctx는 context, err는 error, req/resp는 request/response, buf는 buffer 같은 것들이요. Go 코드를 읽다 보면 이런 약어가 자연스럽게 눈에 들어오는데, 처음엔 좀 낯설 수 있어요. 하지만 Go 생태계 전체가 이 관습을 따르기 때문에, 이걸 익혀두면 오히려 다른 사람의 코드를 읽는 속도가 빨라져요.

인터페이스 네이밍: -er 접미사의 힘

인터페이스 이름 짓기에도 Go만의 재미있는 관습이 있어요. 메서드가 하나인 인터페이스는 메서드 이름 + er 형태로 짓는 게 관례예요. Read 메서드를 가진 인터페이스는 Reader, Write는 Writer, Close는 Closer 이런 식이죠. 표준 라이브러리의 io.Reader, io.Writer, fmt.Stringer 같은 것들이 대표적인 예시예요.

이 패턴이 좋은 이유는, 인터페이스가 "이 타입이 무엇을 할 수 있는가"를 이름만 봐도 바로 알 수 있게 해주기 때문이에요. Java의 Runnable, Comparable 같은 느낌이라고 보시면 돼요. 다만 메서드가 여러 개인 인터페이스는 이 규칙을 억지로 따르지 않아도 되고, 행동을 잘 설명하는 이름을 자유롭게 쓰면 돼요.

에러 변수와 타입: Err 접두사와 Error 접미사

에러 처리도 네이밍 관습이 명확해요. 패키지 레벨 에러 변수는 Err로 시작해요. ErrNotFound, ErrTimeout 이런 식이죠. 반면에 에러 타입(커스텀 에러 구조체)은 Error로 끝나요. PathError, SyntaxError 같은 거예요.

이 구분이 왜 중요하냐면, 코드를 읽는 사람이 Err로 시작하면 "아, 이건 미리 정의된 센티넬 에러(sentinel error)구나" 하고 바로 알 수 있고, Error로 끝나면 "이건 추가 정보를 담고 있는 에러 타입이구나" 하고 구분할 수 있거든요. 센티넬 에러라는 건 if err == ErrNotFound 같은 식으로 직접 비교해서 쓰는 에러 값을 말해요.

다른 언어와 뭐가 다를까

Java나 C#을 쓰던 분들이 Go로 넘어오면 가장 어색해하는 부분이 이름의 간결함이에요. Java에서는 AbstractSingletonProxyFactoryBean 같은 긴 이름도 흔하잖아요. 하지만 Go에서는 그런 긴 이름이 오히려 안티패턴으로 여겨져요. Go 커뮤니티는 "좋은 이름은 짧은 이름"이라는 철학을 강하게 갖고 있거든요.

Python에서 넘어오는 분들은 snake_case를 쓰고 싶은 유혹을 느낄 수 있는데요, Go에서 언더스코어는 테스트 파일이나 특수한 경우를 제외하면 거의 쓰지 않아요. Go의 linter 도구인 golint나 staticcheck가 snake_case를 쓰면 경고를 띄워주기도 해요.

한국 개발자에게 주는 시사점

국내에서도 Go를 쓰는 팀이 빠르게 늘고 있어요. 카카오, 당근, 라인, 토스 등에서 백엔드 서비스에 Go를 적극 도입하고 있고, 신규 마이크로서비스를 Go로 작성하는 경우도 많아졌거든요. 이런 환경에서 팀 내 코드 리뷰를 할 때, 네이밍 컨벤션이 통일되어 있으면 리뷰 속도가 확 빨라져요.

특히 Go를 이제 막 배우기 시작한 분이라면, 문법보다 네이밍 컨벤션을 먼저 체화하는 게 더 중요할 수 있어요. 왜냐하면 Go는 gofmt로 코드 포맷은 자동으로 맞춰주지만, 이름 짓기는 개발자 본인의 판단이거든요. 좋은 이름을 짓는 습관은 도구가 대신해줄 수 없는 영역이에요.

원문 가이드를 한 번 정독해두면, 앞으로 Go 코드를 작성할 때마다 "이 이름이 Go다운가?" 하는 판단 기준이 잡힐 거예요.

마무리

Go의 네이밍 컨벤션은 단순한 스타일 가이드가 아니라, 접근 제어와 직결된 언어 설계의 일부예요. 패키지 이름은 짧게, 대소문자로 공개 여부를 결정하고, 인터페이스는 행동을 나타내는 -er 접미사를 쓰는 것. 이 기본 원칙만 잘 지켜도 "Go를 Go답게 쓴다"는 느낌이 확 달라져요.

여러분 팀에서는 Go 네이밍에 대해 별도의 가이드라인을 운영하고 계신가요? 혹시 Go 스타일과 기존 팀 관습 사이에서 충돌이 있었던 경험이 있다면 공유해주세요!