변수와 상수, 왜 코드 리뷰의 단골 소재가 될까요?
어렵게 완성한 풀 리퀘스트(PR)를 올렸는데, 시니어 개발자로부터 “이 값은 왜 상수로 선언하지 않았나요?” 혹은 “변수명이 너무 모호합니다”라는 코멘트를 받은 적이 있나요? 처음 Go 언어를 배울 때는 단순히 문법에 맞춰 값을 담는 것에만 집중하게 돼요. 하지만 실제 프로덕션 환경의 코드를 작성할 때는 단순히 동작하는 것을 넘어, 다른 개발자가 읽기 쉽고 유지보수가 용이한 코드를 만드는 것이 훨씬 중요해요.
특히 Go 변수 코드 리뷰 과정에서 발견되는 작은 실수들은 나중에 프로젝트의 규모가 커졌을 때 예상치 못한 버그나 유지보수의 어려움으로 다가와요. 변수의 생명 주기가 너무 길거나, 바뀌지 말아야 할 값이 변수로 방치되어 있다면 시스템의 안정성을 해칠 수 있거든요. 코드 리뷰어는 단순히 문법 오류를 찾는 사람이 아니라, 코드의 의도를 파악하고 더 나은 구조를 제안하는 가이드 역할을 해야 해요.
많은 신입 개발자가 변수를 선언할 때 단순히 “값이 필요하니까”라는 이유로 선언을 남발하곤 해요. 하지만 Go는 명확성과 간결함을 지향하는 언어예요. 따라서 어떤 상황에서 var를 쓰고, 어떤 상황에서 const를 써야 하는지, 그리고 변수의 이름을 어떻게 지어야 동료들에게 의도를 정확히 전달할 수 있는지 아는 것이 실력의 차이를 만든답니다.
이 글을 통해 여러분은 다음과 같은 내용을 깊이 있게 다루게 될 거예요.
- 변수와 상수를 구분하는 명확한 기준과 코드 리뷰 관점
- Go 언어 특유의 변수 선언 방식(var, :=)의 적절한 활용법
- 실무에서 빈번하게 발생하는 변수 관련 안티패턴과 해결책
- 가독성을 높이는 식별자 명명 규칙과 스코프 관리 전략
효율적인 리뷰를 위한 기초 지식과 체크리스트
본격적으로 코드를 뜯어보기 전에, 우리가 어떤 기준을 가지고 변수와 상수를 바라봐야 하는지 정리해 볼게요. 리뷰어라면 코드를 보기 전에 스스로에게 질문을 던져야 해요. “이 값은 프로그램 실행 중에 변할 가능성이 있는가?” 그리고 “이 값의 의미가 명확하게 전달되는가?”라고 말이죠.
Go 언어는 변수 선언 방식이 매우 직관적이지만, 그만큼 용도에 맞지 않게 사용했을 때 발생하는 가독성 저하가 심할 수 있어요. 아래 표를 통해 상황에 따른 적절한 선언 방식을 먼저 머릿속에 넣어두세요.
| 선언 방식 | 주요 특징 | 권장 사용 상황 |
|---|---|---|
| const | 컴파일 타임에 결정되는 불변 값 | 설정값, 수학적 상수, 고정된 에러 메시지 등 |
| var (명시적) | 타입과 초기값을 명확히 지정 | 제로 값으로 초기화가 필요할 때, 전역 변수 선언 시 |
| :=(단축 선언) | 타입 추론을 통한 간결한 선언 | 함수 내부에서 즉시 값이 할당되는 지역 변수 |
리뷰를 진행할 때 단순히 “맞다, 틀리다”를 넘어, 왜 이 방식이 더 나은지 설명할 수 있어야 해요. 예를 들어, 함수 내부에서 값이 변하지 않는 변수를 `var`로 선언했다면, 이를 `const`로 바꿀 것을 권장할 수 있어요. 이는 코드의 의도를 명확히 하고, 실수로 값이 변경되는 것을 방지하여 안정성을 높여주기 때문이에요.
Go에서는 선언만 하고 사용하지 않는 변수가 있으면 컴파일 에러가 발생해요. 이는 불필요한 메모리 사용과 코드 혼란을 막아주는 아주 강력한 기능이에요. 따라서 리뷰 시 사용되지 않는 변수가 남아있다면 즉시 제거하도록 가이드해야 해요.
또한, 변수의 스코프(Scope)를 결정하는 기준도 중요해요. 변수는 가능한 한 좁은 범위에서 선언되어야 해요. 함수 전체에서 쓰이는 변수라 할지라도, 특정 조건문 안에서만 쓰인다면 그 안에서 선언하는 것이 읽는 사람의 인지 부하를 줄여준답니다. 이러한 기준들을 숙지하고 리뷰에 임한다면, 여러분은 단순한 에디터를 넘어 진정한 코드 품질 관리자가 될 수 있어요.
실전 Go 변수 및 상수 코드 리뷰 가이드
이제 실무에서 바로 적용할 수 있는 단계별 리뷰 전략을 알아볼게요. 이 가이드는 단순히 문법을 체크하는 것을 넘어, 코드의 설계 철학을 검토하는 데 중점을 둡니다.
STEP 1. 변수 선언 방식의 적절성 검토하기
가장 먼저 확인해야 할 것은 선언 방식의 일관성이에요. Go 개발자들 사이에서는 암묵적인 약속이 존재하거든요. 함수 내부에서 변수를 선언할 때, 값이 즉시 결정된다면 단축 선언(`:=`)을 사용하는 것이 일반적이에요. 하지만 만약 함수 시작 부분에서 변수를 미리 선언해두고 나중에 값을 할당해야 하는 구조라면 `var`를 사용해야 해요.
리뷰 시 주의 깊게 볼 점은 불필요한 var 사용이에요. 예를 들어, `var x = 10`이라고 쓰기보다는 `x := 10`이라고 쓰는 것이 훨씬 Go답고 간결해요. 반대로, `var x int`처럼 타입을 명시하며 제로 값으로 초기화해야 하는 경우에는 `var`가 정답이에요. 이 경계가 모호하면 코드가 지저분해지기 시작해요.
STEP 2. 상수(const) 활용을 통한 의도 명확화
많은 초보 개발자가 실수하는 부분 중 하나가 변하지 않는 값에 변수를 사용하는 거예요. 예를 들어, 서버의 타임아웃 시간이나 API 버전 번호 같은 것들이죠. 이런 값들은 반드시 const로 선언해야 해요.
상수를 사용하면 두 가지 큰 이득이 있어요. 첫째, 리뷰어가 코드를 읽을 때 “아, 이 값은 프로그램 실행 중에 절대로 바뀌지 않겠구나”라고 즉시 안심할 수 있어요. 둘째, 실수로 코드 중간에 해당 값을 수정하는 로직이 들어가더라도 컴파일 단계에서 잡아낼 수 있죠. 만약 코드 곳곳에 `30`이라는 숫자가 직접 적혀 있다면(Magic Number), 이를 `const MaxRetryCount = 30`과 같이 상수로 바꾸도록 제안하세요. 이는 코드의 의미를 부여하는 아주 중요한 작업이에요.
STEP 3. 식별자 이름(Naming)의 의미론적 분석
변수 이름은 그 자체로 문서가 되어야 해요. 리뷰어는 이름만 보고도 이 변수가 무엇을 담고 있는지, 어떤 역할을 하는지 유추할 수 있어야 한다고 생각해야 해요. 너무 짧아서 의미를 알 수 없는 이름(예: `a`, `b`, `data`)이나, 너무 길어서 읽기 힘든 이름(예: `theValueThatRepresentsTheUserAge`) 모두 피해야 할 대상이에요.
Go의 관례에 따르면, 짧은 범위의 지역 변수는 짧은 이름을 써도 괜찮지만, 패키지 레벨의 변수나 구조체의 필드는 그 의미를 명확히 드러내는 이름을 가져야 해요. 또한, 변수 이름에 `get`이나 `set` 같은 접두사를 붙이는 것은 Go에서 권장되지 않는 경우가 많으니, 명사 위주로 간결하게 짓도록 유도해 주세요. 예를 들어 `getUserName()` 보다는 `UserName()`이 더 자연스러울 수 있어요.
STEP 4. 스코프(Scope) 최소화 및 섀도잉(Shadowing) 방지
변수의 생명 주기는 짧을수록 좋아요. 변수가 선언된 범위가 넓을수록, 해당 변수가 어디서 어떻게 바뀌었는지 추적하기가 기하급수적으로 어려워지기 때문이에요. 따라서 가능하면 변수의 사용 범위를 좁게 유지하는 것을 권장해야 해요.
변수 섀도잉(Shadowing) 현상을 경계하세요. 상위 스코프에 있는 변수와 동일한 이름의 변수를 하위 스코프(예: if문이나 for문 내부)에서 다시 선언하면, 상위 변수의 값이 가려져 버려요. 이는 논리적 오류를 일으키는 매우 위험한 패턴이므로 리뷰 시 반드시 확인해야 해요.
STEP 5. 제로 값(Zero Value)의 전략적 활용
Go는 모든 타입에 대해 기본적으로 정해진 제로 값을 가져요. 이를 잘 활용하면 코드가 훨씬 깔끔해져요. 많은 경우, 변수를 선언하자마자 `0`이나 `false`로 초기화하려는 유혹을 느끼지만, Go에서는 굳이 그렇게 할 필요가 없어요. 제로 값을 활용한 명시적 초기화 생략은 코드를 더 간결하게 만들고 개발자의 의도를 단순하게 유지해 줍니다. 리뷰할 때 불필요한 초기화 코드가 있다면 제거를 제안해 보세요.
실전 시나리오 예시
다음은 잘못된 코드와 개선된 코드의 차이를 보여주는 시나리오예요. 이 흐름을 이해하면 리뷰가 훨씬 쉬워질 거예요.
[잘못된 사례]
함수 내부에서 타임아웃을 변수로 선언하고, 이름을 모호하게 지었으며, 사용하지 않는 변수가 포함된 경우입니다.
`var t = 30` (상수 사용 안 함)
`var d = “data”` (의미 없는 이름)
`var unused = true` (사용 안 함)
[개선된 사례]
의도를 명확히 하고, 상수를 사용하며, 불필요한 요소를 제거한 모습입니다.
`const TimeoutSeconds = 30`
`userID := “user_123″` (명확한 이름과 단축 선언)
이렇게 변수 하나를 고치는 것만으로도 코드의 품질은 몰라보게 달라진답니다.
자주 하는 실수와 해결법
코드 리뷰를 하다 보면 반복적으로 나타나는 패턴들이 있어요. 이를 유형별로 정리해 두면 리뷰 속도가 훨씬 빨라질 거예요.
- ❌ 사용하지 않는 변수를 그대로 방치함 → Go 컴파일러가 에러를 내지만, 개발 중에 임시로 만든 변수가 남는 경우가 많아요 → ✅ 즉시 삭제하거나, 정말 필요하다면 언더스코어(`_`)를 사용하여 명시적으로 무시하세요.
- ❌ 상수로 쓸 수 있는 값을 변수로 선언함 → 값이 변하지 않음에도 `var`를 사용하면 코드의 의도를 파악하기 어려워요 → ✅ 값이 고정되어 있다면 반드시 `const`를 사용하여 의도를 드러내세요.
- ❌ 변수 이름이 너무 짧거나 모호함 → `a`, `b`, `val` 같은 이름은 코드를 읽는 사람의 흐름을 끊어요 → ✅ 변수의 역할과 데이터의 성격을 담은 명확한 이름을 사용하세요.
- ❌ 변수 섀도잉(Shadowing) 발생 → 내부 스코프에서 같은 이름의 변수를 다시 선언하여 상위 변수의 값을 덮어씌워요 → ✅ 변수 이름을 고유하게 만들거나, 스코프를 재설계하세요.
- ❌ 전역 변수를 남용함 → 패키지 레벨의 변수가 많아지면 어디서 값이 바뀌었는지 추적하기 불가능해져요 → ✅ 가능한 한 함수 내부의 지역 변수로 제한하고, 필요하다면 구조체의 필드로 관리하세요.
자주 묻는 질문
Q. Go에서 상수는 어떤 타입까지 가능한가요?
상수는 숫자(정수, 실수, 복소수), 문자열, 불리언 타입만 가능해요. 런타임에 계산되는 함수 호출 결과나 구조체 인스턴스는 상수로 선언할 수 없으니 주의해야 해요.
Q. 단축 선언(`:=`)을 어디서든 써도 괜찮을까요?
아니요, 단축 선언은 함수 내부에서만 사용할 수 있어요. 패키지 레벨(함수 밖)에서 변수를 선언할 때는 반드시 `var` 키워드를 사용해야 한다는 점을 기억해 주세요.
Q. 변수 이름을 지을 때 대문자로 시작해야 하나요?
Go에서는 이름의 첫 글자가 대문자이면 패키지 외부에서도 접근 가능한 Exported 변수가 되고, 소문자이면 패키지 내부에서만 사용하는 변수가 돼요. 접근 제어 범위를 결정하는 중요한 규칙이에요.
Q. 제로 값 초기화가 꼭 필요한 상황이 있나요?
대부분은 필요 없지만, 특정 구조체의 필드가 제로 값이 아닌 다른 기본값으로 시작해야 하거나, 논리적으로 명시적인 초기화가 가독성에 도움을 주는 경우에는 `var`를 통해 초기화할 수 있어요.
Q. 코드 리뷰 시 변수 이름에 대해 너무 까다롭게 구는 것 아닐까요?
이름은 단순한 장식이 아니라 코드의 핵심적인 설계 요소예요. 좋은 이름은 주석을 줄여주고 버그를 예방하기 때문에, 적절한 피드백은 오히려 개발자의 성장을 돕는 길이에요.
