왜 Go 반복문에서 예상치 못한 버그가 생길까요?
코드 상으로는 아무런 문제가 없어 보여요. 슬라이스를 돌면서 데이터를 하나씩 처리하는 아주 평범한 for 문을 작성했을 뿐이죠. 그런데 막상 실행해 보면 결과값이 모두 마지막 요소로 통일되어 있거나, 프로그램이 갑자기 종료되는 황당한 상황을 마주하곤 해요. 입문 개발자라면 한 번쯤 겪게 되는 이 당혹스러운 순간은 단순한 오타 때문이 아니에요.
Go 언어는 동시성(Concurrency)을 매우 강력하게 지원하는 언어지만, 그만큼 반복문과 고루틴의 상호작용에서 발생하는 미묘한 동작 원리를 이해하지 못하면 치명적인 버그를 만날 수 있어요. 메모리 주소를 공유하는 방식이나 변수의 생명 주기(Scope)를 잘못 이해했을 때 발생하는 문제들은 테스트 코드로도 잡아내기 어려울 때가 많아요.
특히 프로덕션 환경에서 이런 버그가 터지면 데이터가 오염되거나 시스템 전체가 멈추는 큰 사고로 이어질 수 있어요. 그래서 단순히 ‘돌아가는 코드’를 짜는 것을 넘어, ‘왜 이렇게 동작하는지’를 아는 것이 무엇보다 중요해요. 지금 이 글을 읽고 계신다면, 여러분은 이미 중급 개발자로 넘어가기 위한 가장 중요한 관문에 서 계신 거예요.
이 가이드를 통해 우리는 다음 내용들을 깊이 있게 다룰 예정이에요.
- 반복문 변수가 고루틴 내부에서 캡처될 때 발생하는 고전적인 오류
- range 문을 사용할 때 흔히 하는 값 복사 실수와 해결법
- 슬라이스를 반복문 안에서 수정할 때 생기는 인덱스 불일치 문제
- 성능 최적화를 위해 반드시 피해야 할 반복문 패턴
실수 방지를 위한 Go 반복문의 기본 원리
Go에서 반복문을 안전하게 사용하려면 먼저 변수의 유효 범위(Scope)와 메모리 할당 방식을 머릿속에 그려두어야 해요. Go의 for 문은 다른 언어의 while 문 역할까지 겸하며 매우 유연하지만, 그 유연함이 때로는 독이 되기도 해요.
가장 먼저 이해해야 할 점은 반복문에서 선언된 변수가 메모리 상에서 어떻게 관리되는가 하는 부분이에요. for i := 0; i < 10; i++와 같은 기본 형태와 for i, v := range slice와 같은 range 형태는 변수를 다루는 방식이 근본적으로 달라요. 이 차이를 무시하고 코드를 작성하면, 논리적으로는 완벽해 보여도 실행 시점에는 전혀 다른 값을 참조하게 될 수 있어요.
Go 1.22 버전부터는 반복문 변수의 생명 주기에 중요한 변화가 있었어요. 이전 버전에서는 반복문 변수가 매 루프마다 재사용되었지만, 최신 버전에서는 매 루프마다 새로운 인스턴스가 생성되도록 개선되었어요. 하지만 여전히 하위 버전을 사용하는 환경이나 고루틴 캡처 방식에 따라 주의가 필요해요.
반복문을 설계하기 전에 여러분이 선택해야 할 패턴을 아래 표로 비교해 보았어요. 어떤 상황에서 어떤 방식을 선택해야 실수를 줄일 수 있을지 확인해 보세요.
| 반복문 유형 | 주요 용도 | 주의할 점 |
|---|---|---|
| 기본 for문 | 정밀한 인덱스 제어 | 종료 조건 실수 시 무한 루프 |
| range 반복문 | 슬라이스/맵 순회 | 값(Value)의 복사본 사용 주의 |
| 무한 for문 | Worker 패턴/이벤트 루프 | break/return 조건 필수 |
단순히 코드를 나열하는 것이 아니라, 상황에 맞는 적절한 도구를 선택하는 안목을 기르는 것이 실수를 예방하는 첫걸음이에요. 인덱스가 필요 없다면 range를 사용하되, 값이 아닌 주소를 다뤄야 한다면 인덱스를 활용하는 식의 판단 기준이 필요하답니다.
실무에서 반드시 만나는 Go 반복문 오류 패턴
이제 본격적으로 개발자들을 밤잠 설치게 만드는 실제 오류 사례들을 살펴볼게요. 단순히 코드를 읽는 것에 그치지 말고, 머릿속으로 메모리 구조를 그리며 따라와 보세요.
STEP 1. 고루틴 내부의 변수 캡처 버그
Go 개발자들이 가장 많이 겪는 '클래식'한 실수예요. 슬라이스에 담긴 ID 값들을 이용해 각각 고루틴을 실행하여 API를 호출하는 시나리오를 가정해 볼게요. 코드는 다음과 같이 작성될 거예요.
for _, id := range ids { go func() { fmt.Println(id) }() }
분명히 각 고루틴이 서로 다른 ID를 출력할 것 같지만, 실제로는 모든 고루틴이 마지막 ID만 출력하는 현상이 발생할 수 있어요. 그 이유는 고루틴이 실행되는 시점과 반복문이 도는 시점이 다르기 때문이에요. 반복문은 눈 깜짝할 사이에 끝까지 달려가서 id 변수에 마지막 값을 넣어버리고, 뒤늦게 깨어난 고루틴들은 모두 동일한 메모리 주소를 참조하게 되는 것이죠.
이 문제를 해결하려면 고루틴에 인자를 직접 전달하여 각 루프의 값을 복사해 전달해야 해요. go func(val int) { ... }(id)와 같은 방식을 사용하여, 실행 시점의 값을 고루틴만의 개별 공간에 저장해 두어야 안전해요.
STEP 2. range 문에서의 값 복사 메커니즘
for i, v := range slice를 사용할 때, 여기서 나오는 v는 슬라이스 요소의 원본이 아니에요. 원본 데이터의 복사본이죠. 만약 반복문 안에서 v의 값을 변경한다면 어떻게 될까요?
놀랍게도 원본 슬라이스의 값은 전혀 변하지 않아요. 개발자는 당연히 슬라이스 내부 데이터가 수정될 것이라고 믿고 코드를 짰지만, 실제로는 로컬 변수 v만 바뀌고 사라지는 셈이에요. 이 실수는 데이터 처리 로직에서 매우 치명적일 수 있어요. 원본을 수정해야 한다면 반드시 인덱스를 사용하여 slice[i] = newValue와 같이 접근해야 한다는 사실을 잊지 마세요.
STEP 3. 슬라이스 수정 시 인덱스 불일치 문제
데이터를 순회하면서 특정 조건에 맞는 요소를 삭제해야 할 때가 있어요. 이때 가장 위험한 행동은 반복문 도중에 슬라이스의 길이를 줄이는 것이에요. 예를 들어 for i := 0; i < len(slice); i++로 돌면서 i번째 요소를 삭제하면, 다음 루프에서 인덱스가 하나씩 밀리게 되어 특정 요소를 건너뛰거나 범위를 벗어나는 런타임 에러가 발생해요.
안전한 방법은 두 가지예요. 첫째, 역순으로 순회하는 거예요. 뒤에서부터 삭제하면 인덱스가 앞으로 밀리는 영향을 받지 않죠. 둘째, 삭제할 요소를 따로 모았다가 한꺼번에 처리하거나, 새로운 슬라이스에 필요한 값만 옮겨 담는 방식이에요. 실무에서는 두 번째 방식이 코드의 가독성과 안정성 측면에서 더 권장되곤 해요.
슬라이스의 길이를 매번
len() 함수로 확인하는 것은 안전하지만, 반복문 시작 시점에 길이를 고정해버리면 중간에 추가된 요소를 처리하지 못할 수 있으니 의도에 따라 신중히 결정해야 해요.STEP 4. 포인터 슬라이스 사용 시의 함정
슬라이스가 단순 값 타입이 아니라 포인터 타입(예: []*User)을 담고 있다면 문제가 더 복잡해져요. range 문에서 값을 복사할 때, 복사되는 것은 '포인터 주소값'이지 '실제 객체'가 아니기 때문이죠. 이는 메모리 관리 측면에서 효율적일 수 있지만, 반복문 안에서 객체의 상태를 변경할 때 의도치 않게 다른 곳에 있는 데이터까지 건드릴 위험이 있어요.
포인터를 다룰 때는 항상 이 데이터가 공유되고 있는가를 자문해 보세요. 여러 고루틴이 동일한 포인터가 가리키는 메모리를 동시에 수정하려고 한다면, 데이터 레이스(Data Race)가 발생하여 프로그램이 예측 불가능하게 동작하게 됩니다.
STEP 5. 대규모 데이터 처리 시의 성능 저하
마지막으로 성능 문제입니다. 반복문 내부에서 매번 새로운 슬라이스를 생성하거나, 크기가 예측되지 않은 맵(Map)에 데이터를 넣는 행위는 엄청난 가비지 컬렉션(GC) 부담을 줘요. 100만 건의 데이터를 처리하는 루프 안에서 매번 작은 객체를 할당한다면, 프로그램은 계산보다 메모리 정리하느라 더 많은 시간을 쓰게 될 거예요.
실제 프로젝트에서는 반복문을 돌기 전에 필요한 크기만큼 미리 메모리를 할당해 두는 make([]Type, 0, capacity) 방식을 사용하는 것이 훨씬 효율적이에요. 작은 습관 하나가 서버의 응답 속도를 수 밀리초(ms) 단위로 바꿀 수 있다는 점을 기억하세요.
실전 시나리오: 안전한 데이터 처리 흐름도
아래는 위에서 배운 실수들을 방지하기 위한 권장 프로세스예요.
- 데이터의 규모를 파악하고 필요한 메모리 용량을 미리 계산한다.
make를 통해 슬라이스나 맵의 용량(Capacity)을 선점한다.- 반복문에서는
range를 사용하되, 원본 수정이 필요하면 인덱스를 활용한다. - 고루틴을 띄울 때는 반드시 변수를 인자로 넘겨 값을 복사한다.
- 슬라이스 삭제가 필요하면 역순 순회나 새 슬라이스 생성을 선택한다.
자주 하는 실수와 해결법
지금까지 배운 내용을 바탕으로, 실제 현업에서 빈번하게 발생하는 오류 패턴 5가지를 요약 정리해 드릴게요. 코드를 작성한 뒤 스스로 체크리스트처럼 활용해 보세요.
❌ 실수: 고루틴 내부에서 루프 변수를 직접 참조하여 모든 고루틴이 동일한 값을 처리함
왜 발생하는가: 변수의 메모리 주소가 공유되어 루프 종료 시점의 값만 참조하게 됨
✅ 해결법: 고루틴 호출 시 함수 인자로 변수를 명시적으로 전달하여 값을 복사함
❌ 실수: for _, v := range slice에서 v의 값을 변경하여 원본 데이터를 수정하려 함
왜 발생하는가: v는 슬라이스 요소의 복사본일 뿐 원본 메모리가 아님
✅ 해결법: slice[i] = newValue와 같이 인덱스를 사용하여 원본에 직접 접근함
❌ 실수: 반복문 중간에 append나 remove로 슬라이스 크기를 변경함
왜 발생하는가: 인덱스 순서가 밀리거나 범위를 벗어나 런타임 에러 발생
✅ 해결법: 역순으로 순회하거나, 조건에 맞는 데이터만 새 슬라이스에 담음
❌ 실수: 무한 루프를 작성하고 탈출 조건을 복잡하게 꼬아놓음
왜 발생하는가: 조건문이 특정 상황에서 만족되지 않아 CPU 점유율이 100%로 치솟음
✅ 해결법: 루프 내부에 타임아웃(Context)을 적용하거나 명확한 break 조건을 설정함
❌ 실수: 반복문 안에서 대량의 메모리 할당을 반복함
왜 발생하는가: 잦은 메모리 할당으로 인해 가비지 컬렉터 부하가 급증함
✅ 해결법: 반복문 시작 전에 make로 필요한 용량을 미리 할당함
자주 묻는 질문
Q. Go 1.22 버전 이후로는 고루틴 실수가 자동으로 해결되나요?
네, 많은 부분이 개선되었어요. 최신 버전의 Go에서는 루프 변수가 매 반복마다 새로운 인스턴스로 생성되므로, 이전처럼 고루틴이 마지막 값만 가져가는 문제는 대부분 사라졌어요. 하지만 하위 버전과의 호환성을 고려해야 하는 프로젝트라면 여전히 인자로 값을 넘기는 습관을 들이는 것이 안전해요.
Q. range 문을 쓸 때 성능이 걱정돼요. for i := 0 방식이 더 빠른가요?
매우 미세한 차이는 있을 수 있지만, 현대적인 컴파일러에서는 그 차이가 거의 무시할 만한 수준이에요. 성능 최적화보다는 코드의 가독성과 안전성이 더 중요해요. 다만, 복사되는 데이터의 크기가 매우 크다면 인덱스만 사용하는 방식이 메모리 복사 비용을 줄여줄 수 있어요.
Q. 슬라이스에서 요소를 삭제할 때 가장 권장하는 패턴은 무엇인가요?
가장 깔끔한 방법은 새로운 슬라이스를 만들어 필요한 요소만 append 하는 방식이에요. 원본 슬라이스를 유지해야 하는 상황이 아니라면, 이 방식이 읽기 쉽고 버그를 유발할 가능성이 가장 낮아요.
Q. 반복문 내에서 맵(Map)을 순회할 때 순서가 왜 매번 달라지나요?
Go 설계자들이 의도적으로 만든 특징이에요. 맵의 순회 순서가 일정하면 개발자들이 맵의 순서에 의존적인 코드를 짜게 될 수 있는데, 이는 나중에 데이터 구조가 바뀌었을 때 큰 버그를 유발하거든요. 순서가 중요하다면 별도의 슬라이스에 키를 담아 정렬한 뒤 순회해야 해요.
Q. 무한 루프를 방지하는 가장 좋은 습관은 무엇인가요?
context.Context를 활용하는 것이 가장 좋아요. 루프 조건에 ctx.Done()을 포함하면, 외부에서 신호를 주었을 때 안전하고 즉시 루프를 종료할 수 있어 시스템 자원을 보호하는 데 매우 효과적이에요.
안정적인 코드를 작성하기 위한 마지막 점검
반복문은 단순해 보이지만, Go의 강력한 기능들과 만났을 때 매우 복잡한 동작을 보여줍니다. 오늘 다룬 실수들은 단순히 실수가 아니라, 언어의 동작 원리를 이해하는 과정에서 마주하는 필수적인 관문이에요. 이 과정들을 잘 넘긴다면 여러분의 코드는 훨씬 더 견고해질 것입니다.
- 고루틴 사용 시 루프 변수는 반드시 인자로 복사해서 넘기세요.
range의 값은 복사본임을 명심하고, 수정 시에는 인덱스를 쓰세요.- 슬라이스 수정 시에는 역순 순회나 새 슬라이스 생성을 고려하세요.
- 메모리 할당은 반복문 밖에서 미리 해두는 것이 성능에 유리합니다.
- 맵 순회는 순서가 보장되지 않음을 항상 인지하세요.
- 복잡한 루프에는
context를 도입해 종료 조건을 명확히 하세요.
오늘 바로 실천해 보세요:
- 기존 프로젝트의 반복문 중 고루틴을 사용하는 곳이 있는지 검토하기
range문을 사용하면서 값을 직접 수정하고 있지는 않은지 확인하기- 슬라이스 용량을 미리 할당하는
make코드를 적용해 보기
더 깊이 있는 Go 프로그래밍 원리가 궁금하다면 Go 반복문 완벽 가이드 글을 함께 읽어보시는 것을 추천드려요. 지금 바로 여러분의 에디터를 열고, 예제 코드를 클론해 직접 실행하며 몸으로 익혀보세요!
