왜 지금 Go 변수 마이그레이션이 필요한가요?
새벽 2시, 운영 중인 서비스에서 원인 모를 데이터 오류가 발생했어요. 코드를 살펴보니 누군가 전역 변수의 값을 실수로 변경했고, 그 영향이 시스템 전체로 퍼져나가고 있었죠. 이런 상황은 Go를 사용하는 많은 개발자가 한 번쯤 겪게 되는 끔찍한 시나리오예요. 단순히 값을 저장하는 것을 넘어, 그 값이 변해야 하는지 아니면 고정되어야 하는지를 명확히 구분하는 것이 시스템 안정성의 핵심이에요.
기존의 거대한 레거시 프로젝트를 유지보수하다 보면, 어디서부터 어디까지가 상수로 치환 가능한지 판단하기 어려울 때가 많아요. 무턱대고 상수로 바꿨다가는 컴파일 에러의 홍수에 빠질 수 있고, 반대로 변수로 방치하면 데이터 무결성이 깨질 위험이 있어요. 그래서 체계적인 Go 변수 마이그레이션 전략이 필요해요.
이 과정은 단순히 문법을 바꾸는 작업이 아니에요. 코드의 의도를 명확히 하고, 컴파일러가 최적화를 할 수 있도록 돕는 설계 과정에 가까워요. 올바른 마이그레이션을 마치고 나면, 코드는 더 읽기 쉬워지고 예상치 못한 부수 효과(side effect)로부터 자유로워져요.
이 글을 끝까지 읽고 나면 다음과 같은 역량을 갖추게 될 거예요.
- 변수와 상수의 차이를 명확히 이해하고 적재적소에 배치하는 능력
- 기존 코드를 분석하여 안전하게 상수로 전환하는 프로세스
- 마이그레이션 과정에서 발생할 수 있는 타입 오류와 범위 문제를 해결하는 기술
- 테스트 코드를 통해 마이그레이션의 무결성을 검증하는 방법
마이그레이션 전 반드시 확인해야 할 준비 사항
본격적인 작업에 들어가기 전에 우리가 다루는 도구들의 특성을 정확히 알아야 해요. Go 언어에서 변수와 상수는 비슷해 보이지만, 메모리에 머무는 방식과 컴파일러가 처리하는 방식이 완전히 달라요. 준비 없이 코드를 수정하면 런타임 에러가 아니라 컴파일 단계에서 거대한 벽에 부딪히게 돼요.
변수와 상수의 근본적인 차이점
가장 먼저 이해해야 할 점은 불변성이에요. 상수는 프로그램이 실행되는 동안 절대 변하지 않는 값을 의미하고, 변수는 필요에 따라 언제든 값이 바뀔 수 있는 저장 공간을 의미해요. 이 차이가 왜 중요한지 아래 표를 통해 비교해 볼게요.
| 구분 항목 | 변수 (var) | 상수 (const) |
|---|---|---|
| 값의 변경 | 언제든 가능 | 불가능 (컴파일 타임 결정) |
| 데이터 타입 | 모든 타입 가능 | 기본 타입만 가능 (문자열, 숫자, 불리언) |
| 메모리 할당 | 런타임에 할당 | 컴파일 타임에 결정 |
| 사용 권장 상황 | 상태가 변하는 데이터 | 설정값, 매직 넘버, 고정된 기준 |
마이그레이션 환경 체크리스트
작업을 시작하기 전에 현재 프로젝트의 상태를 점검해야 해요. 아무 준비 없이 대규모 파일을 수정하는 것은 매우 위험해요. 다음 체크리스트를 확인해 보세요.
- 테스트 커버리지 확보: 기존 기능이 정상 작동함을 증명할 단위 테스트가 충분한가요?
- Go 버전 확인: 사용 중인 Go 버전에서 지원하는 상수 표현 방식(예: untyped constants)을 숙지했나요?
- 의존성 분석: 변경하려는 변수가 다른 패키지에서 직접 참조되고 있지는 않나요?
- IDE 설정: 코드 리팩토링 도구가 잘 작동하는 환경인가요?
Go의 상수는 컴파일 타임에 값이 결정되어야 해요. 즉, 함수의 리턴값이나 외부 API에서 가져온 값을 상수로 만들 수는 없다는 점을 반드시 기억해야 해요.
안전한 변수와 상수 전환을 위한 4단계 실행 프로세스
이제 실제 코드를 어떻게 만져야 하는지 구체적으로 살펴볼게요. 무작정 코드를 지우고 다시 쓰는 것이 아니라, 시스템의 안정성을 해치지 않으면서 점진적으로 개선하는 것이 핵심이에요. 이 과정은 정교한 분석과 검증을 필요로 해요.
STEP 1. 기존 코드의 변수 패턴 분석하기
가장 먼저 해야 할 일은 현재 코드에서 사용 중인 변수들이 어떤 성격을 가졌는지 분류하는 일이에요. 모든 변수를 다 바꾸려는 욕심을 버려야 해요. 변수의 수명 주기(Lifecycle)를 추적하는 것이 첫걸음이에요.
먼저, 프로그램이 실행되는 동안 값이 단 한 번도 변하지 않는 지점을 찾아내세요. 예를 들어, 타임아웃 설정값, API 엔드포인트 URL, 에러 메시지 정의 등이 여기에 해당해요. 이런 값들은 현재 `var`로 선언되어 있더라도 사실상 상수의 역할을 하고 있어요. 반면, 사용자의 요청에 따라 매번 값이 바뀌는 상태 데이터나 누적되는 카운터 등은 절대 상수로 바꾸면 안 돼요.
분석할 때는 다음 질문을 스스로에게 던져보세요.
- 이 값이 프로그램 실행 중에 변경되는 코드가 존재하는가?
- 이 값이 외부 환경(환경 변수, DB, 파일)에 의해 결정되는가?
- 이 값을 다른 곳에서 수정할 권한이 있는가?
만약 위 질문 중 하나라도 ‘예’라고 답한다면, 그 값은 변수로 남겨두어야 해요. 잘못된 상수는 코드의 유연성을 완전히 박살 낼 수 있어요.
STEP 2. 상수(const)로 전환할 후보 선별 및 그룹화
분석이 끝났다면, 이제 상수로 만들 후보들을 모아야 해요. 단순히 한 줄씩 바꾸는 것보다 성격이 비슷한 것끼리 그룹화하는 것이 유지보수에 훨씬 유리해요.
예를 들어, HTTP 상태 코드를 정의하는 변수들이 여기저기 흩어져 있다면, 이를 하나의 `const` 블록으로 모으는 것이 좋아요. 이렇게 하면 코드를 읽는 사람이 “아, 이 값들은 이 서비스의 표준 상태 코드구나”라고 즉시 이해할 수 있어요.
이 단계에서 주의할 점은 매직 넘버(Magic Number) 제거예요. 코드 중간에 갑자기 등장하는 `86400` 같은 숫자는 무엇을 의미하는지 알기 어렵죠. 이를 `const SecondsPerDay = 86400`과 같이 의미 있는 상수로 바꾸는 과정이 병행되어야 해요. 이것이 진정한 의미의 Go 변수 마이그레이션의 가치예요.
STEP 3. 코드 구현과 타입 추론의 전략적 활용
이제 실제로 코드를 작성할 차례예요. Go의 상수는 크게 두 가지 방식으로 작성할 수 있는데, 이 차이를 아는 것이 고수와 하수를 가르는 기준이 돼요.
첫 번째는 타입이 지정된 상수(Typed Constant)예요. `const Timeout int = 30`처럼 타입을 명시하는 방식이죠. 이는 타입 안정성을 높여주지만, 때로는 타입 불일치로 인한 불편함을 초래할 수도 있어요. 두 번째는 타입이 지정되지 않은 상수(Untyped Constant)예요. `const Timeout = 30`처럼 작성하면, Go 컴파일러가 문맥에 따라 적절한 타입으로 유연하게 해석해 줘요.
실무에서는 다음과 같은 시나리오를 추천해요.
- 정밀한 타입 체크가 필요한 핵심 도메인 로직에서는 타입을 명시하세요.
- 다양한 타입(int, float64 등)과 혼용되어 계산이 잦은 수치 데이터에는 타입을 생략한 상수를 사용하세요.
타입이 없는 상수는 컴파일 타임에 결정되는 매우 높은 정밀도를 가질 수 있어요. 이는 수학적 계산에서 발생할 수 있는 부동 소수점 오차를 줄이는 데 큰 도움을 줍니다.
STEP 4. 단위 테스트를 통한 무결성 검증
코드를 수정했다면 이제 확인해야 할 시간이에요. 마이그레이션이 성공적이었는지 판단하는 유일한 기준은 테스트 통과예요. 단순히 컴파일이 된다고 해서 끝난 게 아니에요.
특히 전역 변수를 상수로 바꿨을 때, 기존에 그 변수를 수정하며 로직을 수행하던 코드가 있다면 컴파일 에러가 발생할 거예요. 이때 단순히 에러를 없애기 위해 다시 변수로 돌리는 것이 아니라, 로직 자체가 설계 오류였음을 인지하고 구조를 개선해야 해요.
다음은 마이그레이션 검증을 위한 권장 절차예요.
- 기존 테스트 코드 실행: 모든 테스트가 통과하는지 확인해요.
- 레이스 컨디션 체크: `go test -race ./…` 명령어를 사용하여, 상수로 바꾼 값이 여전히 스레드 안전하게 읽히는지 확인해요. (상수는 원래 안전하지만, 주변 로직의 변화를 감지하기 위함이에요.)
- 경계값 테스트: 상수로 바꾼 수치들이 계산식에서 의도한 대로 작동하는지 경계값을 넣어 확인해요.
이 과정을 거치면 비로소 안전하게 마이그레이션을 완료했다고 말할 수 있어요.
상수로 변환한 값이 나중에 설정 파일(Config file)을 통해 동적으로 변경되어야 하는 값인지 다시 한번 확인하세요. 설정값은 상수가 아닌 변수로 관리해야 합니다.
자주 하는 실수와 해결법
마이그레이션 과정은 생각보다 험난할 수 있어요. 많은 개발자가 겪는 실수들을 미리 파악해 두면 시행착오를 크게 줄일 수 있어요.
- ❌ 런타임에 결정되는 값을 상수로 선언함
왜 발생하나요? 환경 변수나 DB에서 읽어온 값을 상수로 만들려고 시도할 때 발생해요.
✅ 해결법: 그런 값은 반드시 `var`로 선언하고, `init()` 함수나 생성자 함수를 통해 초기화하세요. - ❌ 슬라이스나 맵을 상수로 만들려고 시도함
왜 발생하나요? Go에서 상수는 기본 타입(문자열, 숫자, 불리언)만 가능하기 때문이에요.
✅ 해결법: 슬라이스나 맵은 `var`로 선언하되, 외부에서 수정하지 못하도록 캡슐화(private 변수로 만들고 Getter 함수 제공)를 적용하세요. - ❌ 타입 불일치로 인한 컴파일 에러
왜 발생하나요? 타입이 지정된 상수를 다른 타입의 변수에 대입하려 할 때 발생해요.
✅ 해결법: 명시적 타입 변환을 수행하거나, 상수를 선언할 때 타입을 지정하지 않는 방식을 활용하세요. - ❌ 패키지 레벨 변수의 과도한 상수화
왜 발생하나요? 패키지 전체에서 공유되는 변수를 모두 상수로 바꾸면 테스트 시 모킹(Mocking)이 불가능해져요.
✅ 해결법: 테스트 용이성을 고려하여, 테스트 중에 값이 바뀌어야 하는 의존성은 변수로 남겨두세요. - ❌ 상수 이름의 불명확성
왜 발생하나요? `const Val = 10`처럼 너무 단순하게 이름을 지으면 의미를 알 수 없어요.
✅ 해결법: `const MaxRetryAttempts = 10`처럼 의도를 담은 이름을 사용하세요.
자주 묻는 질문
Q. 상수를 사용하면 성능이 정말 좋아지나요?
네, 어느 정도는 그래요. 컴파일러가 값을 미리 알고 있기 때문에 런타임에 메모리를 할당하거나 값을 읽어오는 오버헤드가 줄어들고, 인라인 최적화가 가능해져요. 다만, 미세한 성능 차이보다는 코드의 가독성과 안전성 측면에서 얻는 이득이 훨씬 커요.
Q. 기존의 거대한 프로젝트를 한 번에 다 바꾸고 싶어요. 괜찮을까요?
절대 안 돼요! 한 번에 모든 것을 바꾸면 어디서 문제가 생겼는지 찾기가 불가능해져요. 기능 단위나 모듈 단위로 쪼개서 점진적으로 진행하는 것을 강력히 권장해요.
Q. `const`와 `var` 중 무엇을 선택해야 할지 정말 헷갈려요.
가장 쉬운 기준은 “이 값이 바뀌어야 하는가?”예요. 코드 전체를 훑었을 때 이 값을 수정하는 곳이 단 한 군데라도 있다면 그것은 변수예요. 수정하는 곳이 전혀 없고, 앞으로도 생길 일이 없다면 상수예요.
Q. 상수를 정의할 때 관례적인 이름 규칙이 있나요?
Go에서는 다른 언어처럼 모든 상수를 대문자로 시작(PascalCase)할 필요는 없어요. 패키지 외부에서 접근해야 하는 경우에만 대문자로 시작하고, 내부용이라면 소문자로 시작하면 돼요. 다만, 의미를 명확히 전달하는 것이 가장 중요해요.
