데이터 포맷 변환, 제정신으로 하는 법

이런 상황 겪어보셨을 겁니다. 데이터베이스 내보내기는 CSV로 나옵니다. 새 API는 JSON을 원합니다. 배포 설정은 YAML이어야 합니다. 레거시 시스템은 XML만 받습니다. 그리고 어쩌다 보니, 이걸 다 연결하는 건 내 일이 됐습니다.

데이터 포맷 변환은 실제로 해보기 전까지는 간단해 보입니다. 무너지지 않는 실전 파이프라인을 만들어봅시다.

시나리오: 실제 마이그레이션

구 시스템에서 신 시스템으로 사용자 데이터를 이전한다고 합시다. 상황은 이렇습니다:

• 소스: 구 데이터베이스의 CSV 내보내기 (10,000행, 15열)
• API 레이어: 신 시스템은 REST API로 JSON을 받음
• 설정 파일: 배포 설정은 YAML
• 레거시 연동: 파트너 시스템은 여전히 XML 피드 필요

네 가지 포맷. 하나의 데이터셋. 시작합시다.

1단계: CSV → JSON — 내보내기에서 API 호환으로

CSV는 이렇게 생겼습니다:

id,name,email,plan,created
1,Alice,alice@example.com,pro,2024-03-15
2,Bob,bob@example.com,free,2024-06-22

JSON으로 변환하면 API가 소비할 수 있는 구조화된 데이터가 됩니다:

[
  {
    "id": 1,
    "name": "Alice",
    "email": "alice@example.com",
    "plan": "pro",
    "created": "2024-03-15"
  }
]

주의사항: 쉼표가 포함된 인용 필드, null이어야 할 빈 값이 빈 문자열로 처리되는 경우, 행마다 다른 날짜 형식. 이런 버그들은 "잘 되고 있다"고 생각했을 때 4,738번째 행에서 나타납니다.

2단계: JSON → YAML — 설정 파일용

배포에 YAML 설정이 필요합니다. 데이터 구조는 같고, 문법만 다릅니다:

users:
  - id: 1
    name: Alice
    email: alice@example.com
    plan: pro
    created: "2024-03-15"

YAML은 설정 파일에서 더 읽기 좋습니다. Kubernetes, Docker Compose, CI/CD 파이프라인이 모두 쓰는 이유죠. 하지만 들여쓰기에 민감해서, 한 칸 잘못 들여쓰면 새벽 2시에 배포가 깨집니다.

3단계: JSON → XML — 레거시 시스템용

2015년의 그 파트너 시스템이 XML을 요구합니다. 네, API 업그레이드는 안 합니다. 네, 그래도 지원해야 합니다.

<users>
  <user>
    <id>1</id>
    <name>Alice</name>
    <email>alice@example.com</email>
  </user>
</users>

변환 자체는 직관적이지만 XML에는 고유한 특성이 있습니다 — 속성 vs 요소, 네임스페이스 요구사항, 스키마 검증. XML 변환기가 구조적 변환을 처리하고, 비즈니스 로직은 여러분이 처리합니다.

4단계: JSON 포맷터로 모든 것을 검증

매 단계에서 JSON을 포맷하고 검증하세요. 괄호 하나, 후행 쉼표 하나, 이스케이프 안 된 따옴표 하나 — 그러면 임포트가 조용히 레코드를 빠뜨리거나 완전히 크래시됩니다.

변환된 데이터를 API로 보내기 전에 포맷하고 구조를 눈으로 확인하세요. 5초의 포맷팅이 "왜 200개 레코드가 없지"를 디버깅하는 5시간을 절약합니다.

데이터 마이그레이션의 흔한 함정

인코딩 문제: Windows Excel에서 나온 CSV는 UTF-8이 아니라 Windows-1252일 수 있습니다. 일본어 고객 이름이 물음표로 바뀝니다. 인코딩부터 확인하세요.

타입 변환: CSV는 모든 것을 문자열로 취급합니다. CSV의 001이 JSON에서 1이 됩니다. 우편번호, 전화번호, 선행 0이 있는 ID 필드가 주요 피해자입니다.

중첩 데이터: CSV는 평면적이고 JSON은 중첩됩니다. CSV의 address_street, address_city, address_zip을 JSON의 address 객체로 어떻게 매핑할지 결정해야 합니다.

Null vs 빈값: 빈 CSV 셀이 null인지, ""인지, 키 자체를 생략해야 하는지? 버그를 발견했을 때가 아니라 시작하기 전에 정의하세요.

파이프라인 패턴

데이터 마이그레이션의 워크플로는 이렇습니다:

1. 내보내기 — 소스 시스템에서 (보통 CSV 또는 SQL 덤프)
2. 변환 — 작업 포맷으로 (CSV → JSON)
3. 변형 — 구조 변경 (필드명 변경, 객체 중첩, 타입 수정)
4. 검증 — 출력 확인 (포맷 및 검사)
5. 변환 — 대상 포맷으로 (YAML 또는 XML)
6. 임포트 — 대상 시스템으로

도구가 2, 4, 5단계를 처리합니다. 1, 3, 6단계는 여러분의 코드입니다. "변환"과 "변형"을 분리하면 관리가 수월해집니다.

---

데이터 마이그레이션은 기획 문서에서 보이는 것처럼 간단하지 않습니다. 하지만 각 단계에서 신뢰할 수 있는 변환 도구가 있으면, 포맷 문법과 싸우는 대신 진짜 문제 — 비즈니스 로직, 엣지 케이스, 데이터 품질 — 에 시간을 쓸 수 있습니다.