왜 나는 DataTable을 싫어하는가?

⚠️ C# 개발에서 DataTable을 지양하는 이유

"빠르게 시작하려다, 나중엔 유지보수 지옥에 빠진다."

---

1️⃣ DataTable은 실질적으로 Dictionary<string, object>이다

DataTable은 겉보기엔 테이블처럼 보이지만, 내부 구조는 매우 느슨합니다.

• Key: 문자열 기반의 컬럼명
• Value: object 타입

즉, Dictionary<string, object>와 매우 유사한 동작을 합니다.
이는 유연하지만, C#의 정적 타입 시스템과는 정면으로 충돌합니다.

---

2️⃣ 값 형식(Value Type)에선 성능 손실이 발생한다

int value = (int)row["SomeColumn"]; // Unboxing

이처럼 object에서 값 형식을 꺼내려면 Unboxing이 필요합니다.

• Boxing/Unboxing은 CPU 연산을 수반
• 반복 루프 안에서 수천 번 반복되면 → 성능 저하
• GC Pressure까지 유발

단순한 데이터 처리인데도, 비용이 너무 큽니다.

---

3️⃣ View 바인딩 시에도 비효율적이다

WinForms, WPF, Blazor 등 어떤 View에서도 DataTable은 타입 힌트를 제공하지 않습니다.

• IDE에서 자동완성 X
• 컬럼명이 문자열 → 오타 나도 컴파일러가 잡아주지 않음
• DBNull.Value 체크 강제

string name = row["Name"].ToString(); // null이면 문제 발생

 

결국 UI에서도 방어 코드와 불필요한 예외 처리가 늘어납니다.

---

4️⃣ 서버에서 반복 처리? → 리스크의 시작

foreach (DataRow row in table.Rows)

{

    int id = (int)row["Id"];

    long price = (long)row["Price"]; // ❌ InvalidCastException 가능성

}

• object 타입을 잘못된 형으로 캐스팅 → InvalidCastException
• 타입 확인은 모두 런타임까지 미뤄짐
• 수많은 if-check 혹은 try-catch가 남발됨

---

5️⃣ 결국 유지보수가 불가능해진다

DataTable["컬럼명"]은 다음과 같은 문제를 만듭니다:

• 어떤 열이 어떤 타입인지 파악하려면 → 전역 검색
• 리팩토링 불가능 (문자열 기반)
• 중복된 열 이름 사용 → 런타임 오류
• IDE가 아무 도움도 주지 못함

시간이 흐를수록 코드는 해석 불가능한 늪이 됩니다.

---

✅ 대안은? 정적 타입 기반 모델

public record User(int Id, string Name);

List<User> users = new() {

   new(1, "Alice"),

   new(2, "Bob")

};

• 컴파일 타임 타입 검증
• 자동완성, 리팩토링, 추적 가능
• 성능 최적화: Boxing 없음
• 데이터의 의미가 명확

ORM을 쓰든, Dapper를 쓰든, 정적 구조로 가는 것이 정답입니다.

---

📊 비교표

항목DataTableDTO + List<T>

타입 안정성	❌ 없음	✅ 있음
성능	❌ 낮음	✅ 빠름
디버깅	❌ 어려움	✅ 용이
리팩토링	❌ 불가	✅ 가능
생산성	⚠️ 초기에만 좋음	✅ 장기적으로 우수

 

---

✋ 마치며

DataTable은 빠르게 시작하기엔 좋습니다.
하지만 프로젝트가 커질수록, 협업 인원이 늘어날수록, 유지보수 기간이 길어질수록 엄청난 비용을 유발하는 구조적 부채가 됩니다.

• 타입 불안정
• 성능 병목
• 추적 불가능한 데이터 흐름

이 모든 문제는 결국 구조화되지 않은 object 남용에서 시작됩니다.

👉 이제는 구조화된 데이터 모델로 전환할 때입니다.