왜 우리는 데이터 구조 선택에 매번 고민할까요
한밤중에 갑자기 운영 중인 서버의 메모리 점유율이 치솟거나, 평소 잘 돌아가던 로직이 특정 대용량 데이터를 처리할 때만 눈에 띄게 느려지는 경험을 해보셨나요? 대부분의 경우 원인은 의외로 아주 기초적인 곳에서 시작돼요. 바로 데이터를 담는 그릇인 배열과 컬렉션을 잘못 선택했기 때문이에요.
레거시 .NET Framework로 작성된 오래된 프로젝트를 유지보수하다 보면, 성능 최적화가 절실한데도 불구하고 무턱대고 ArrayList나 일반적인 Array를 남발하는 코드를 자주 마주하게 돼요. 반대로 최신 .NET 환경에서는 C# 배열 라이브러리 비교를 통해 실무에서 바로 적용할 수 있는 기준을 제시해 드릴게요. 복잡한 이론보다는 개발자가 실제 코드를 짤 때 직면하는 성능과 메모리 문제를 중심으로 이야기를 풀어가 볼게요.
이 글을 읽고 나면 얻게 되는 것들
- 상황별로 적합한 C# 배열 및 컬렉션 선택 기준을 완벽히 이해해요.
- 레거시 코드의 성능 병목을 찾아내고 개선할 수 있는 안목을 길러요.
- 최신 .NET 기술인 Span
를 언제 도입해야 하는지 명확히 알게 돼요. - 메모리 할당을 최소화하여 가비지 컬렉션(GC) 부하를 줄이는 법을 배워요.
라이브러리 선택 전 반드시 체크해야 할 핵심 기준
무작정 코드를 작성하기 전에, 우리가 해결해야 할 문제가 무엇인지 명확히 정의하는 과정이 필요해요. 단순히 “데이터를 모아둔다”는 생각만으로는 부족해요. 데이터가 얼마나 자주 변하는지, 메모리 사용량은 어느 정도까지 허용할 수 있는지에 따라 정답은 완전히 달라지거든요.
가장 먼저 고려해야 할 점은 데이터의 크기 변화 여부예요. 처음부터 개수가 딱 정해져 있다면 고정 크기 배열이 유리하겠지만, 데이터가 계속 추가되거나 삭제되는 동적인 환경이라면 이야기가 달라지죠. 또한, .NET Framework 환경인지 아니면 최신 .NET 환경인지에 따라 사용할 수 있는 도구의 범위도 달라져요.
데이터 구조를 선택할 때는 항상 공간 복잡도(메모리)와 시간 복잡도(속도) 사이의 트레이드오프를 생각해야 해요. 메모리를 아끼면 연산이 느려질 수 있고, 속도를 높이려다 보면 메모리를 더 많이 쓸 수도 있어요.
선택을 돕기 위해 주요 라이브러리들의 특징을 표로 정리해 보았어요. 이 표를 가이드 삼아 여러분의 프로젝트 상황을 대입해 보세요.
| 구분 기준 | System.Array | List<T> | Span<T> |
|---|---|---|---|
| 크기 조절 | 불가능 (고정) | 가능 (동적) | 불가능 (뷰 제공) |
| 메모리 할당 | 힙(Heap)에 한 번에 할당 | 내부 배열 재할당 발생 | 스택 또는 힙 (매우 효율적) |
| 주요 용도 | 고정된 데이터 집합 | 일반적인 비즈니스 로직 | 고성능 데이터 슬라이싱 |
| 사용 난이도 | 매우 쉬움 | 매우 쉬움 | 중간 (메모리 이해 필요) |
위 표에서 보듯, 각 도구는 확실한 장단점을 가지고 있어요. 만약 여러분이 레거시 시스템을 유지보수하고 있다면, 기존의 데이터 흐름을 깨뜨리지 않으면서도 성능을 개선할 수 있는 지점을 찾는 것이 첫 번째 목표가 되어야 해요. 무리하게 모든 것을 Span<T>로 바꾼다고 해서 성능이 드라마틱하게 올라가는 것은 아니니까요.
실무 환경에 따른 5단계 선택 프로세스
이제 본격적으로 어떤 상황에서 어떤 라이브러리를 사용해야 하는지 단계별로 깊이 있게 살펴볼게요. 단순히 기능을 나열하는 것이 아니라, 실제 개발 시나리오를 바탕으로 고민해 봅시다.
STEP 1. 정적인 데이터 집합에는 System.Array를 활용하세요
가장 기본이 되는 System.Array는 데이터의 개수가 변하지 않을 때 가장 강력한 성능을 발휘해요. 배열은 메모리 상에 연속적인 공간을 차지하기 때문에, 인덱스를 통한 접근 속도가 매우 빨라요.
예를 들어, 일주일의 요일 데이터나 시스템 설정값처럼 프로그램이 실행되는 동안 크기가 변할 일이 없는 데이터라면 고민할 필요 없이 배열을 사용하세요. 배열은 추가적인 관리 오버헤드가 거의 없고, CPU 캐시 적중률(Cache Hit Rate)이 높아 대량의 데이터를 순차적으로 읽을 때 최상의 효율을 보여준답니다. 하지만 주의할 점이 있어요. 배열의 크기를 중간에 늘리려면 새로운 배열을 만들고 기존 데이터를 복사해야 한다는 점이에요. 이 과정에서 발생하는 비용은 생각보다 매우 크답니다.
STEP 2. 유연성이 최우선이라면 List<T>를 선택하세요
실제 비즈니스 로직을 짜다 보면 데이터가 몇 개가 들어올지 예측하기 어려운 경우가 훨씬 많아요. 사용자 목록, 주문 내역, 로그 데이터 등이 대표적이죠. 이때 가장 친절한 도구가 바로 List<T>예요.
List<T>는 내부적으로 배열을 가지고 있으면서, 공간이 부족해지면 자동으로 더 큰 배열을 만들어 데이터를 옮겨주는 기능을 제공해요. 덕분에 개발자는 메모리 관리에 신경 쓰지 않고 Add() 메서드 하나로 편하게 데이터를 쌓을 수 있죠.
하지만 여기서 성능 최적화의 핵심 팁이 하나 있어요. 만약 데이터의 개수가 대략 어느 정도 될지 짐작이 간다면, 반드시 생성자에서 Capacity를 미리 지정해 주세요.
List<int> list = new List<int>(1000); 처럼 초기 용량을 설정하면, 내부 배열이 커질 때마다 발생하는 재할당과 데이터 복사 과정을 획기적으로 줄일 수 있어요. 이것만으로도 성능 차이가 크게 벌어집니다.STEP 3. 초고성능이 필요하다면 Span<T>의 세계로 들어가세요
최신 .NET 환경에서 개발하고 있고, 텍스트 파싱이나 대규모 숫자 연산처럼 0.1초의 성능이 중요한 로직을 짜고 있다면 Span<T>를 반드시 고려해야 해요. Span<T>는 기존 배열이나 리스트의 특정 부분을 “복사 없이” 보여주는 창문 같은 역할을 해요.
기존 방식으로는 배열의 일부를 잘라내어 전달하려면 새로운 배열을 만들어 데이터를 복사해야 했어요. 이 과정에서 메모리 할당이 일어나고 가비지 컬렉터(GC)가 일해야 하죠. 하지만 Span<T>를 사용하면 원본 메모리의 주소만 가리키기 때문에 추가적인 메모리 할당이 거의 발생하지 않아요.
특히 Zero-allocation(할당 제로)을 목표로 하는 고성능 라이브러리 개발자들에게는 필수적인 도구예요. 다만, Span<T>는 ref struct이기 때문에 힙에 할당될 수 없고, 클래스의 필드로 가질 수 없는 등 사용 규칙이 까다롭다는 점을 명심해야 해요.
STEP 4. 실전 성능 비교 시나리오 분석
백만 개의 정수 데이터를 처리하는 상황을 가정해 볼게요. 각 방식에 따라 어떤 차이가 날까요?
- Array 방식: 메모리 할당이 한 번에 끝나며, 순차 접근 시 가장 빠른 속도를 보여줘요. 메모리 사용량도 예측 가능하죠.
- List<T> 방식: 데이터가 추가될 때마다 내부 배열이 2배씩 커지며 메모리 할당이 반복돼요. 이 과정에서 순간적인 메모리 사용량 급증과 GC 부하가 발생해요.
- Span<T> 방식: 이미 존재하는 큰 배열에서 특정 구간만 잘라내어 처리할 때 압도적이에요. 복사 연산이 아예 없으므로 CPU 사용량이 급격히 낮아져요.
실제로 성능 프로파일링 도구를 사용해 보면, 데이터 규모가 커질수록 List<T>의 재할당 비용과 Span<T>의 효율성 차이가 눈에 띄게 벌어지는 것을 확인할 수 있어요.
STEP 5. 레거시에서 모던 C#으로 전환하는 전략
기존의 낡은 코드를 한꺼번에 바꿀 수는 없어요. 다음과 같은 단계로 점진적인 개선을 추천해요.
- 1단계: 기존의 ArrayList나 타입이 불분명한 컬렉션을 List<T> 같은 제네릭 컬렉션으로 바꿉니다. (박싱/언박싱 제거)
- 2단계: 리스트의 크기가 예측 가능하다면 Capacity를 지정하여 재할당 비용을 줄입니다.
- 3단계: 루프 내부에서 배열의 일부분을 자르는 로직이 있다면, 해당 구간을 Span<T>로 처리하도록 변경합니다.
이렇게 단계적으로 접근하면 시스템의 안정성을 유지하면서도 점진적으로 성능을 끌어올릴 수 있어요.
자주 하는 실수와 해결법
실무에서 개발자들이 흔히 저지르는 실수들을 모아봤어요. 비슷한 경험이 있다면 지금 바로 코드를 점검해 보세요.
- ❌ 배열 인덱스 범위를 벗어나는 오류 (IndexOutOfRangeException)
왜 발생하는가: 배열의 크기를 고정해두고 반복문 조건 설정을 잘못하거나, 데이터가 하나도 없는 상태에서 0번 인덱스에 접근할 때 발생해요.
✅ 해결법: 반복문 조건을i < array.Length로 정확히 설정하고, 접근 전 배열이 비어있는지 반드시 확인하세요. - ❌ List<T>의 빈번한 재할당으로 인한 성능 저하
왜 발생하는가: 초기 용량(Capacity)을 설정하지 않고 수만 개의 데이터를Add()하면, 내부 배열이 계속해서 새로 만들어지며 데이터를 복사해요.
✅ 해결법: 예상되는 최대 데이터 개수를 안다면 생성자에서 용량을 미리 예약해 두세요. - ❌ ArrayList 사용으로 인한 박싱(Boxing) 문제
왜 발생하는가: 레거시 코드에서 값 형식(int, double 등)을 ArrayList에 넣으면 객체로 변환되는 박싱이 일어나 성능을 크게 떨어뜨려요.
✅ 해결법: 반드시 제네릭 버전인 List<T>를 사용하여 타입 안정성과 성능을 모두 잡으세요. - ❌ Span<T>를 클래스 필드로 사용하려는 시도
왜 발생하는가: Span<T&>는 스택에만 존재해야 하는 ref struct이기 때문에 힙에 저장되는 클래스의 멤버가 될 수 없어요.
✅ 해결법: Span<T> 대신 Memory<T>를 사용하여 클래스 내부에 저장하거나, 메서드 내의 지역 변수로만 활용하세요.
자주 묻는 질문
Q. Array와 List<T> 중 무엇이 더 빠른가요?
순수하게 인덱스로 접근하는 속도만 따지면 Array가 아주 미세하게 더 빨라요. 하지만 데이터의 추가/삭제가 빈번하다면 List<T>를 사용하는 것이 코드의 가독성과 유지보수 측면에서 훨씬 유리하며, 성능 차이도 체감하기 어려울 정도예요.
Q. Span<T>는 .NET Framework에서도 쓸 수 있나요?
Span<T>는 .NET Core 2.1 및 .NET Standard 2.1 이상부터 지원해요. 아주 오래된 .NET Framework 환경이라면 직접 구현하거나 외부 라이브러리를 활용해야 하니 버전을 꼭 확인하세요.
Q. LINQ를 배열과 리스트 모두에 쓸 수 있나요?
네, 둘 다 가능해요. 하지만 LINQ는 내부적으로 열거자(Enumerator)를 생성하므로, 극도의 성능이 필요한 루프 안에서는 LINQ 대신 일반적인 for 또는 foreach 문을 사용하는 것이 더 효율적이에요.
Q. 데이터 양이 가늠이 안 될 때는 어떻게 하나요?
그럴 때는 일단 기본 설정의 List<T>를 사용하되, 주기적인 성능 프로파일링을 통해 메모리 할당량이 지나치게 높다면 적절한 Capacity를 찾아 적용하는 것이 가장 현실적인 방법이에요.
성공적인 개발을 위한 최종 요약
C#의 배열과 컬렉션은 단순히 데이터를 담는 통이 아니라, 애플리케이션의 생명주기와 성능을 결정짓는 핵심 설계 요소예요. 오늘 배운 내용을 바탕으로 여러분의 프로젝트를 한 단계 업그레이드해 보세요.
- 데이터 크기가 고정적이라면 System.Array가 가장 효율적이에요.
- 동적인 데이터 처리가 필요하면 List<T>를 쓰되, Capacity를 미리 지정하는 습관을 들이세요.
- 고성능 데이터 슬라이싱이 필요하다면 Span<T>를 적극 활용하세요.
- 레거시 환경에서는 ArrayList 대신 제네릭(Generic)을 사용하는 것부터 시작하세요.
- 성능 최적화의 핵심은 메모리 할당 최소화와 가비지 컬렉션 부하 감소에 있어요.
오늘 바로 여러분의 프로젝트 코드 중에서 데이터가 대량으로 쌓이는 부분을 찾아보세요. 그리고 그곳에 사용된 컬렉션이 적절한지, 혹은 Capacity 설정이 빠져 있지는 않은지 점검해 보는 건 어떨까요? 작은 변화가 모여 거대한 시스템의 안정성을 만듭니다.
실행에 옮기기 전, 먼저 작은 데이터셋으로 성능 테스트를 진행해 보는 것을 추천해요. 데이터가 늘어날 때 메모리 점유율이 어떻게 변하는지 직접 관찰하는 것이 가장 좋은 학습이 될 거예요.
이 글이 도움이 되었다면, 다음 단계로 C# 반복문 최적화 기법에 대해서도 함께 학습해 보시길 권장해요. 효율적인 데이터 구조를 골랐다면, 이제 그 데이터를 얼마나 빠르게 순회하느냐가 다음 과제가 될 테니까요.
