ファイルインターフェースがいまだに最善である理由

LabHub 에서 이어서 보기

한국어 원문으로 표시합니다.

한 줄 요약

파일 연동이 살아남은 이유는 대량·명확한 경계·쉬운 재처리이고, 그 대신 위치가 곧 의미인 고정길이와 다 쓰기 전에 집어 가는 문제를 직접 다뤄야 한다.

概念マップ: 위치가 곧 의미인 고정길이・다 쓰기 전에 집어 가는 문제・대량에 강하다.・경계가 명확하다.

왜 아직도 파일인가

REST 와 큐가 있는데 왜 파일로 주고받는가. 이유가 분명하다.

대량에 강하다. 100만 건을 건별 호출로 보내면 몇 시간이지만 파일 하나면 몇 분이다.
경계가 명확하다. "8월 1일자 매출 파일"이라는 단위가 업무 담당자에게 자연스럽다. 건수와 합계를 딱 떨어지게 대사할 수 있다.
재처리가 쉽다. 파일을 다시 넣으면 된다. 큐 재처리보다 직관적이다.
상대가 그것만 가능하다. 20년 된 시스템, 대외 기관, 은행 EDI. "REST 로 주세요"가 통하지 않는다.

그래서 SI 현장에서 파일 연동은 사라지지 않는다. 오히려 배치 야간 작업의 큰 축이 여전히 파일이다.

고정길이 전문 — 위치가 곧 의미다

20260801HONG                    0000012500Y
|      ||                      ||        ||
1-8    9-28                     29-38     39
일자    고객명(20)               금액(10)   여부(1)

레이아웃 정의서에는 시작 위치, 길이, 타입, 정렬, 채움 문자가 있어야 한다.

항목	관행
문자 필드	왼쪽 정렬, 오른쪽 공백 채움
숫자 필드	오른쪽 정렬, 왼쪽 `0` 채움
금액	소수점 없이 정수로, 자릿수를 정의서에 명시
음수	마지막 자리에 부호를 겹치거나 별도 부호 필드
날짜	`YYYYMMDD` 8자리

한글이 들어가면 문제가 시작된다. '길이 20'이 20바이트인지 20글자인지에 따라 전혀 다른 파일이 된다. EUC-KR 이면 한글 1자가 2바이트, UTF-8 이면 3바이트다. 그리고 고정길이는 한 바이트만 밀려도 그 뒤가 전부 깨진다.

그래서 국내 대외 연동에서 EUC-KR(또는 CP949)이 아직 살아 있다. 한글이 2바이트로 딱 떨어져서 자릿수 계산이 편하기 때문이다. 받은 파일이 깨져 보이면 먼저 인코딩을 의심하고 변환해 본다.

iconv -f EUC-KR -t UTF-8 SALES_20260801.dat > SALES_utf8.dat

헤더와 트레일러 — 파일 자체의 자기 검증

잘 설계된 파일 인터페이스에는 헤더와 트레일러가 있다.

H20260801SALES        0001          ← 헤더: 구분, 일자, 업무, 파일순번
D20260801HONG        0000012500     ← 데이터
D20260801KIM         0000030000
T0000000002000000042500              ← 트레일러: 건수, 금액 합계

트레일러의 존재 이유는 단 하나 — 파일이 온전히 도착했는지 스스로 증명하기 위해서다.

데이터 건수 == 트레일러의 건수인가
데이터 금액 합계 == 트레일러의 합계인가

전송 중 잘렸거나, 중간에 한 줄이 유실됐거나, 인코딩 변환 중 깨졌으면 이 검사에서 걸린다. 이 검증을 안 하면 절반만 온 파일을 정상 처리한다. 그리고 그 사실은 월말 마감 때 "숫자가 안 맞는다"로 발견된다.

트레일러 검증은 처리 전에 해야 한다. 처리 중에 하면 이미 절반이 반영된 상태가 된다.

완료 플래그 — 다 쓰기 전에 집어 가는 문제

FTP 로 파일이 올라오는 중에 배치가 그 파일을 집어 가면 어떻게 되는가. 절반짜리 파일을 처리한다. 트레일러 검증이 있으면 걸리지만, 없으면 그대로 들어간다.

표준 규약은 완료 플래그 파일이다.

SALES_20260801.dat      ← 데이터 (전송 중일 수 있음)
SALES_20260801.dat.ok   ← 이 파일이 생겨야 처리 대상

송신측이 데이터를 다 보낸 뒤 빈 .ok 파일을 만든다. 수신측은 .ok 가 있는 것만 처리한다. 간단하지만 매우 효과적이다.

정의서에 반드시 명시해야 한다. "플래그 파일 규약"이 한쪽에만 있으면 상대는 그냥 데이터만 올리고, 우리 배치는 영원히 아무것도 처리하지 않는다. 그리고 아무 오류도 안 난다. 조용히 아무 일도 안 하는 것이 가장 늦게 발견된다.

파일명 규칙도 인터페이스다

<업무코드>_<기준일자>_<순번>.<확장자>
SALES_20260801_001.dat

기준일자가 파일명에 있어야 재처리할 파일을 특정할 수 있다
순번이 있어야 하루에 여러 번 오는 경우를 구분한다
파일명 규칙이 없으면 sales.txt 가 매일 덮어써지고, 어제 것을 못 찾는다

처리 후 보관

처리한 파일은 지우지 말고 보관한다.

/data/if/archive/20260801/SALES_20260801_001.dat.gz

날짜별 디렉터리로 나눠야 한 디렉터리에 파일 수십만 개가 쌓이지 않는다
압축한다. 텍스트 파일은 대개 80~90% 줄어든다
보관 기간을 정의서에 명시한다. 무한 보관은 디스크 풀 장애로 돌아온다

보관이 필요한 이유는 재처리와 분쟁 때문이다. "그날 우리가 보낸 건 12,000건인데요"라는 말에 답하려면 원본이 있어야 한다.

대사(Reconciliation) — 파일 연동의 마지막 단계

파일을 처리했다고 끝이 아니다. 양쪽 숫자가 맞는지 확인해야 한다.

대사 항목	방법
건수	송신 건수 == 수신 처리 건수 + 오류 건수
금액 합계	송신 합계 == 수신 합계
키 집합	송신 키 목록 - 수신 키 목록 = 공집합

건수와 합계만 맞으면 안심하기 쉽지만, 한 건이 빠지고 다른 한 건이 두 번 들어가면 건수는 맞는다. 그래서 금액 합계를 함께 보고, 정확성이 중요한 인터페이스는 키 집합까지 비교한다.

대사 결과는 파일로 남긴다. 그리고 불일치가 있으면 자동으로 담당자에게 통보되게 한다. 대사 결과를 사람이 매일 열어 보는 방식은 바쁜 날 건너뛰게 되고, 건너뛴 그날에 문제가 있다.

현장에서 만나는 모습

파일 연동에서 나는 사고는 종류가 정해져 있다.

반쪽 파일을 처리했다. 상대가 아직 쓰는 중인데 우리가 집어 갔다. 그래서 완료 플래그(.ok)를 함께 쓰고, 플래그가 있는 파일만 집는다. 이 규칙이 없으면 "어떤 날은 건수가 적게 들어온다" 는 재현 안 되는 버그가 된다.
인코딩이 바뀌었다. EUC-KR 로 오던 파일이 어느 날 UTF-8 로 온다. 고정길이에서는 한글의 바이트 길이가 달라지므로 그 뒤 필드가 전부 밀린다. 화면에는 이름이 깨진 채로, 금액은 엉뚱한 값으로 들어간다.
트레일러를 안 봤다. 파일 스스로 건수와 합계를 들고 있는데 그걸 대조하지 않으면, 전송 중에 잘린 파일을 그대로 적재하고도 아무도 모른다.

세 가지 모두 파일을 읽기 전에 파일을 믿을 수 있는지 확인하는 절차가 없어서 생긴다. 그래서 파일 연동의 첫 단계는 파싱이 아니라 검증이다.