변수 하나가 전체 시스템을 무너뜨릴 수 있어요
어느 날 오후, 평온하게 코드를 수정하고 배포를 마쳤어요. 그런데 갑자기 서버 곳곳에서 원인을 알 수 없는 에러가 터지기 시작해요. 로그를 뒤져보니 범인은 아주 단순한 변수 하나였어요. 한 개발자가 편의를 위해 패키지 전역에 선언해둔 변수가, 다른 모듈에서 예상치 못한 타이밍에 값을 바꿔버린 것이죠.
이런 경험은 Go를 사용하는 많은 개발자가 겪는 흔한 실수 중 하나예요. 처음에는 변수 하나를 어디에 두든 큰 문제가 없어 보여요. 하지만 프로젝트 규모가 커지고 협업하는 팀원이 늘어나면 이야기가 달라져요. 제대로 설계되지 않은 변수는 시간이 흐를수록 거대한 스파게티 코드를 만드는 주범이 되거든요.
단순히 값을 저장하는 도구를 넘어, 코드의 흐름을 제어하고 시스템의 안정성을 결정짓는 것이 바로 변수와 상수의 설계예요. Go 변수 확장성을 고려하지 않은 코드는 나중에 기능을 하나 추가할 때마다 시스템 전체를 흔들어 놓을 수도 있어요.
이 글에서는 단순히 문법을 익히는 수준을 넘어서, 어떻게 하면 확장 가능한 구조로 변수와 상수를 다룰 수 있는지 깊이 있게 다뤄볼 거예요. 입문자분들이 실무에서 바로 적용할 수 있는 실전적인 전략들을 준비했어요.
이 글에서 함께 살펴볼 내용들
- 변수와 상수의 근본적인 차이와 메모리 관리 방식
- 확장성을 해치는 나쁜 습관과 이를 방지하는 설계 원칙
- 실무 아키텍처에서 빛을 발하는 변수 활용 기술
- 유지보수를 획기적으로 줄여주는 상수 관리 전략
설계 전 반드시 짚고 넘어가야 할 기본기
본격적인 아키텍처 설계에 들어가기 전에, 우리가 다루는 도구들이 정확히 무엇인지 명확히 정의해야 해요. Go 언어는 다른 언어와 비교했을 때 변수 선언 방식이 매우 직관적이지만, 그만큼 스코프(Scope)와 생명 주기(Lifecycle)에 대한 이해가 부족하면 큰 낭패를 볼 수 있어요.
가장 먼저 고민해야 할 지점은 이 값이 ‘변하는가’ 혹은 ‘고정되어 있는가’예요. 값이 변해야 한다면 변수를, 절대 변해서는 안 된다면 상수를 선택해야 하죠. 하지만 여기서 중요한 건 단순히 문법적인 선택이 아니라, 이 값이 코드의 어느 범위까지 영향을 미칠지를 결정하는 과정이라는 점이에요.
Go에서 변수는 메모리 주소를 통해 값을 저장하고 변경할 수 있는 공간을 의미하며, 상수는 컴파일 시점에 결정되어 프로그램 실행 중에는 절대 변경할 수 없는 값을 의미해요.
변수 선언 방식과 용도 비교
Go에서는 상황에 따라 다양한 방식으로 변수를 선언할 수 있어요. 각 방식의 특징을 정확히 알고 상황에 맞게 선택하는 것이 실력의 차이를 만들어요.
| 선언 방식 | 주요 특징 | 권장 사용 상황 |
|---|---|---|
| var 키워드 | 타입을 명시적으로 지정 가능 | 전역 변수 또는 초기값이 없는 경우 |
| 단축 선언 (:=) | 타입 추론을 통해 간결하게 선언 | 함수 내부의 지역 변수 |
| const 키워드 | 불변성 보장, 컴파일 타임 결정 | 설정값, 수학적 상수, 고정된 ID |
단순히 짧게 쓰는 것이 좋은 게 아니에요. 함수 내부에서 잠깐 쓰고 버릴 값이라면 단축 선언을 통해 코드 가독성을 높이는 것이 좋지만, 패키지 수준에서 관리되어야 하는 중요한 상태 값이라면 명확하게 타입을 명시한 var 선언을 사용하는 것이 동료 개발자에게 의도를 더 잘 전달할 수 있어요.
또한, 상수를 사용할 때는 단순히 숫자를 적는 대신 왜 이 값이 필요한지를 고민해야 해요. 예를 들어, 타임아웃 시간이 30초라면 그냥 30을 쓰는 게 아니라, `const DefaultTimeout = 30 * time.Second`와 같이 의미를 담아 선언하는 습관이 필요해요. 이것이 바로 확장성 있는 설계의 시작이에요.
확장 가능한 시스템을 만드는 단계별 설계 전략
이제 본격적으로 실무 환경에서 어떻게 변수와 상수를 설계해야 하는지 단계별로 살펴볼게요. 단순히 코드를 짜는 것을 넘어, 시스템이 성장해도 무너지지 않는 탄탄한 기반을 만드는 과정이에요.
STEP 1. 변수의 스코프를 최소화하여 격리하기
확장성 있는 설계의 제1원칙은 변수의 노출 범위를 최대한 좁히는 것이에요. 변수가 코드의 여기저기서 접근할 수 있다면, 그 변수의 상태를 추적하는 것은 불가능에 가까워져요. 이는 결국 디버깅 지옥으로 이어지죠.
가급적 모든 변수는 함수 내부의 지역 변수로 선언하세요. 함수가 실행될 때 생성되고 종료될 때 사라지는 변수는 다른 코드의 동작을 방해할 위험이 거의 없어요. 만약 여러 함수에서 공유해야 하는 상태가 있다면, 전역 변수를 만드는 대신 구조체(Struct)를 활용하여 상태를 캡슐화하는 것이 훨씬 안전해요.
패키지 레벨의 전역 변수는 반드시 필요한 경우에만 사용하세요. 전역 변수가 많아질수록 단위 테스트(Unit Test)를 작성하기가 매우 어려워집니다.
STEP 2. 상수를 활용한 매직 넘버와 문자열 제거
코드 중간에 갑자기 등장하는 숫자나 문자열을 우리는 매직 넘버(Magic Number)라고 불러요. 예를 들어 `if status == 2`라는 코드가 있다면, 나중에 이 코드를 읽는 사람은 2가 무엇을 의미하는지 알 길이 없어요.
이럴 때 상수를 사용하면 코드의 의도가 명확해져요. Go에서는 iota라는 아주 강력한 도구를 제공하는데, 이를 활용하면 연관된 상수 집합을 매우 우아하게 관리할 수 있어요.
예를 들어, 주문 상태를 관리한다면 아래와 같이 설계할 수 있어요.
const (
StatusPending = iota // 0
StatusProcessing // 1
StatusCompleted // 2
StatusCancelled // 3
)
이렇게 설계하면 새로운 상태가 추가되더라도 기존 로직을 크게 건드리지 않고 상수 집합에 한 줄만 추가하면 돼요. 이것이 바로 확장성 있는 상수 설계의 핵심이에요.
STEP 3. 구조체를 통한 데이터 응집도 높이기
변수들을 개별적으로 흩어놓는 것은 마치 부품을 상자에 담지 않고 바닥에 뿌려놓는 것과 같아요. 관련된 변수들은 반드시 하나의 구조체로 묶어서 관리해야 해요. 데이터의 연관성을 높이면 코드를 읽는 사람이 데이터의 흐름을 한눈에 파악할 수 있어요.
사용자 정보를 관리하는 예시를 들어볼게요. 단순히 이름, 나이, 이메일을 따로 선언하는 게 아니라, 하나의 `User` 구조체로 정의하는 것이죠. 시스템이 커져서 사용자의 주소나 전화번호가 추가되더라도, `User` 구조체에 필드만 추가하면 되기 때문에 API 인터페이스나 함수 인자 전달 방식이 바뀌지 않아도 돼요.
STEP 4. 패키지 캡슐화로 외부 접근 제어하기
Go 언어에는 접근 제어자가 따로 없지만, 식별자의 첫 글자가 대문자인지 소문자인지에 따라 외부 노출 여부가 결정돼요. 이 규칙을 전략적으로 활용해야 해요. 패키지 내부에서만 사용되어야 하는 핵심 상태 변수는 반드시 소문자로 시작하게 만들어 외부에서 직접 수정할 수 없도록 차단하세요.
외부에는 데이터의 값을 변경할 수 있는 ‘Setter’ 함수나, 데이터를 안전하게 읽어올 수 있는 ‘Getter’ 함수만 제공하는 것이 좋아요. 이렇게 하면 데이터의 유효성을 검증하는 로직을 한 곳에서 관리할 수 있어, 시스템의 안정성이 비약적으로 상승해요. 데이터가 오염되는 것을 원천적으로 막을 수 있는 가장 확실한 방법이죠.
패키지 내부의 상태를 외부에서 수정하게 두지 마세요. 반드시 메서드를 통해서만 변경하도록 설계하여, 데이터가 유효한 상태를 유지하도록 강제해야 합니다.
이러한 4가지 단계를 거치면, 처음에는 작았던 프로젝트가 수만 줄의 코드로 늘어나더라도 각 모듈이 독립적으로 작동하는 탄탄한 Go 아키텍처를 유지할 수 있어요.
자주 하는 실수와 해결법
설계 이론은 완벽해 보여도 실제 코드를 작성하다 보면 나도 모르게 나쁜 습관이 튀어나오곤 해요. 많은 개발자가 공통적으로 저지르는 실수들을 정리해봤어요.
- ❌ 실수: 모든 상태를 패키지 전역 변수로 관리하기
왜 발생하는가: 데이터 전달이 귀찮고 빠르게 기능을 구현하고 싶을 때 발생해요.
✅ 해결법: 데이터를 구조체에 담고, 필요한 곳에 의존성을 주입(Dependency Injection)하는 방식으로 전환하세요. - ❌ 실수: 상수가 필요한 곳에 리터럴 숫자 직접 쓰기
왜 발생하는가: 한두 번 쓸 때는 이게 더 빠르다고 느껴지기 때문이에요.
✅ 해결법: 조금이라도 재사용될 가능성이 있거나 의미가 중요한 숫자라면 반드시 상수로 선언하세요. - ❌ 실수: iota를 사용할 때 순서를 잘못 지정하기
왜 발생하는가: 상수의 순서가 데이터베이스나 프로토콜의 규격과 맞지 않을 때 발생해요.
✅ 해결법: 상수를 정의하기 전, 외부 규격과 매핑되는 순서를 먼저 확인하고 명시적으로 정의하세요. - ❌ 실수: 변수의 스코프를 너무 넓게 잡기
왜 발생하는가: 변수를 함수마다 인자로 넘기기 번거롭기 때문이에요.
✅ 해결법: 변수의 생명 주기를 분석하여, 해당 변수가 꼭 필요한 시점에만 생성되도록 범위를 좁히세요. - ❌ 실수: const에 계산 가능한 식이 아닌 값을 넣으려고 하기
왜 발생하는가: 실행 시점에 결정되는 값을 상수로 만들고 싶어 하기 때문이에요.
✅ 해حل법: 실행 시점에 값이 결정된다면 상수가 아닌 변수를 사용해야 하며, 이는 문법적으로도 명확히 구분됩니다.
자주 묻는 질문
Q. Go에서 상수는 반드시 문자열이나 숫자만 가능한가요?
아니요, Go의 상수는 문자열, 불리언, 정수형 타입 등을 지원해요. 하지만 구조체나 슬라이스처럼 런타임에 메모리 할당이 필요한 복잡한 타입은 상수로 선언할 수 없어요.
Q. 전역 변수를 아예 쓰면 안 되는 건가요?
아니요, 아주 예외적인 경우(예: 설정 정보, 로그 인스턴스 등)에는 사용될 수 있어요. 하지만 전역 변수가 늘어날수록 테스트가 어려워지고 예측 불가능한 버그가 생기므로 항상 신중해야 해요.
Q. iota를 사용하면 중간에 값을 삭제했을 때 문제가 생기나요?
네, 맞아요. iota는 순차적인 숫자를 생성하기 때문에 중간에 값을 삭제하거나 순서를 바꾸면 뒤에 오는 상수들의 값이 모두 변해버려요. 이는 매우 위험하므로, 외부 시스템과 통신하는 값이라면 주의가 필요해요.
Q. 구조체 필드를 소문자로 만들면 어떻게 되나요?
소문자로 시작하는 필드는 해당 패키지 외부에서는 볼 수 없어요. 즉, 다른 패키지에서 그 값을 읽거나 수정할 수 없게 되어 강력한 캡슐화를 달성할 수 있어요.
성장하는 개발자를 위한 마지막 조언
변수와 상수를 잘 다루는 것은 단순히 코드를 깨끗하게 만드는 것을 넘어, 변화에 유연하게 대처할 수 있는 확장 가능한 시스템을 구축하는 첫걸음이에요. 오늘 배운 내용들을 머릿속에 담아두고 코드를 작성해 보세요.
- 변수의 스코프는 최대한 함수 내부로 제한하여 격리하세요.
- 매직 넘버 대신 상수를 사용하여 코드의 의도를 명확히 하세요.
- 연관된 데이터는 구조체로 묶어 응집도를 높이세요.
- 패키지 접근 제어(대소문자 규칙)를 통해 데이터를 보호하세요.
- iota를 활용해 연관된 상수 집합을 우아하게 관리하세요.
처음부터 완벽한 설계를 할 수는 없어요. 하지만 코드를 작성할 때마다 ‘이 변수가 나중에 문제를 일으키지는 않을까?’라는 질문을 던지는 습관만으로도 여러분의 코드는 훨씬 더 단단해질 거예요.
오늘 할 일: 현재 작성 중인 코드에서 숫자로만 되어 있는 부분을 찾아 상수로 바꿔보세요.
이번 주 할 일: 패키지 전역 변수를 찾아 구조체 내부로 옮기는 리팩토링을 시도해 보세요.
실행 직전 할 일: 새로운 기능을 만들기 전, 필요한 데이터의 생명 주기를 먼저 메모장에 그려보세요.
다음 편에서는 Go의 인터페이스를 활용해 더욱 강력한 추상화를 구현하는 방법에 대해 다룰 예정이에요. 더 깊이 있는 Go 프로그래밍 세계로 나아가고 싶다면 구독을 통해 새로운 소식을 놓치지 마세요!
함께 읽으면 좋은 글: /programming/golang/go-variables-constants-complete-guide/
