들어가며

이 도구를 만든 이유는 단순하다. 매번 수작업으로 처리하는 것이 너무 번거로웠기 때문이다.

사내 시스템 CSV, Excel을 CSV로 바꾼 파일, Linux·Windows·DB에서 뽑은 설정 파일은 출처가 모두 다르다. 출처가 달라질 때마다 인코딩, 개행, BOM 유무가 흔들린다.

  • UTF-8인 줄 알았는데 Shift_JIS
  • LF인 줄 알았는데 CRLF
  • 어떤 시스템은 BOM이 필요하고, 어떤 시스템은 BOM 때문에 깨짐

이 확인과 변환을 사람의 눈과 감으로 반복하는 방식에는 한계가 있다. 그래서 어떤 출처든 받아들이고, 가져갈 시스템 사양에 맞춰 출력을 정렬하는 도구를 만들었다.

진짜 문제는 한 번의 깨짐이 아니다

파일 하나만 깨지면 어떻게든 복구할 수 있다. 어려운 건 출처가 제각각인 파일 10개, 100개가 동시에 들어오는 상황이다.

더 까다로운 점은 가져가는 시스템마다 “정답”이 다르다는 것이다.

  • 시스템 A: UTF-8(BOM 없음)만 허용
  • 시스템 B: UTF-8(BOM 있음)에서 안정적
  • 시스템 C: Shift_JIS 전제, UTF-8은 보여도 import에서 실패

이때 “UTF-8로 통일하면 된다”는 일반론은 쓸모가 없다. 필요한 것은 목적지에 맞춘 안전한 운영 절차다.

이 도구로 하고 싶었던 것

핵심 원칙은 세 가지다.

  1. 어떤 출처든 받아들인다
  2. 목적지 사양에 맞춰 변환한다
  3. 일괄 처리에서도 사고를 늘리지 않는다

즉 변환 기술 과시가 아니라, 운영 마찰을 줄이는 도구다.

내가 실제로 돌리는 절차

1. 먼저 출력 사양을 고정한다

입력이 아니라 출력을 먼저 정한다. 아래 3가지를 고정한다.

  • 문자 인코딩(UTF-8 / Shift_JIS 등)
  • 개행 코드(LF / CRLF)
  • BOM 유무(있음 / 없음)

여기가 모호하면 담당자가 바뀔 때마다 결과가 달라진다.

2. 변환 대상을 작게 나눈다

처음부터 전량을 흘리지 않는다. 시스템별·기간별·파일 유형별로 나누고, 먼저 소배치로 돌린다.

이유는 실패 시 되돌릴 수 있기 때문이다. 전량 원샷은 성공하면 빠르지만 실패하면 치명적이다.

3. 조건을 고정해 일괄 변환한다

문자 인코딩 변환 도구에서 용도별 조건을 고정하고 처리한다. 중간에 설정을 바꾸지 않는다. 매번 같은 조건으로 돌릴 수 있어야 한다.

4. 성공 판정을 눈대중에 맡기지 않는다

“열리면 OK”는 사고의 시작이다. 최소한 다음은 확인한다.

  • 전후 행 수가 일치하는지
  • CSV/TSV 열 수가 무너지지 않았는지
  • �(대체 문자)가 늘지 않았는지
  • 키 열(ID/코드)의 자리수·문자 종류가 유지되는지

검증을 통과하지 못하면 import로 진행하지 않는다.

BOM은 신념이 아니라 상대 사양으로 결정한다

BOM 유무 논쟁은 현장에서 큰 의미가 없다. 상대 시스템이 어떻게 받는지가 전부다.

  • 상대가 BOM에서 안정적이면 BOM 포함
  • 상대가 BOM에서 깨지면 BOM 제외

“정답 형식”보다 “상대가 안 깨지는 형식”을 우선한다. 운영은 원래 그렇게 해야 한다.

이 도구의 가치는 변환 자체가 아니다

진짜 가치는 두 가지다.

  • 사람마다 판단이 흔들리지 않는다
  • 반복 확인 비용을 낮춘다

문자 인코딩 사고를 0으로 만들 수는 없다. 하지만 같은 사고를 반복하는 운영은 멈출 수 있다. 그래서 무엇이든 받아 목적에 맞춰 되돌려 주는 도구를 준비했다.

결론

이 도구는 이상론으로 만든 것이 아니다. 현장에서 반복되는 귀찮은 인코딩 조정을 없애기 위해 만들었다.

출처가 다른 파일을 받아, 목적지 사양에 맞게 인코딩·개행·BOM을 맞춰 반환한다. 이 흐름만 자동화해도 운영은 훨씬 편해진다.

문자 깨짐 대응은 기합으로 버티는 일이 아니다. 재현 가능한 절차로 내려서, 누가 해도 같은 결과가 나오게 만들어야 한다. 그 지점까지 가야 비로소 “안전한 일괄 복구”라고 말할 수 있다.