PMDEXIT 프로젝트 용어사전

연계 파일 인코딩 맞추기 - EUC-KR과 UTF-8이 오픈 주에 갈라지는 지점

“인코딩이 갈리면 연계가 거절된다”

문제파일 인코딩EUC-KRUTF-8

금요일 저녁, 연계 서버는 떠 있는데 파일이 거절된다. 전문 항목은 맞고 구분자도 맞는데, 인코딩이 EUC-KR과 UTF-8로 갈라져 있다. 한글 거래처명이 깨진 채 3만 건이 적재되면 다음날 상담 창구가 멈춘다. 개발 환경에서는 UTF-8로 열리던 파일이 상대 기관 중계 서버에서는 CP949로만 받는 경우가 있다. 샘플 10건은 통과하고 전수에서만 깨지는 이유도 여기 있다. 특수문자와 BOM, 줄바꿈 문자가 전수에만 끼어 있기 때문이다. 인코딩과 줄바꿈, 헤더 유무를 인터페이스 확정 항목으로 언제 박는지 현장 순서로 적는다. 오픈 주에 샘플로 안심하지 않으려면 그 칸이 필요하다.

칸어긋날 때확인
인코딩한글 길이가 밀림상대 기관 회신
줄바꿈 LF CRLF행이 한 줄로 붙음양쪽 담당
BOM 헤더 유무첫 행이 전부 거절수신 측
특수문자 샘플전수에서만 깨짐송신 측
변환기 제거 주임시 변환이 상시로 남음연계 담당
연계 파일 확정 때 같이 닫는 칸

항목이 맞는데 왜 파일이 거절되나

거절 이유는 컬럼 순서가 아니라 바이트 해석인 경우가 많다. 한글이 깨지면 길이 검증부터 실패한다.

인터페이스 정의서의 항목 순서와 길이가 맞으면 연계는 끝난 것처럼 보인다. 상대 시스템이 파일을 CP949로 읽는데 우리가 UTF-8로 보내면, 한글 한 글자의 바이트 수가 달라진다.

길이가 달라지면 고정길이 전문은 다음 항목까지 밀린다. 밀린 항목은 코드 값이 아니라 깨진 문자가 된다.

샘플 10건에 한글이 단순한 단어만 있으면 이 밀림이 안 보인다. 전수 3만 건에 가운뎃점, 전각 괄호, 로마 숫자가 들어가면 그때 거절이 난다.

거절이 오픈 금요일에 나면 주말 창으로는 재전송이 한 번뿐이다. Risk(위험)에 인코딩 미확정이라고 적힌 줄이 착수 4주 차부터 있었는지 돌아본다.

그 줄의 확정일이 비어 있으면 위험 대장은 경고를 한 번도 안 한 것이다. 길이 검증 로그에 인코딩 이름이 없으면 팀은 항목 길이부터 의심한다.

의심의 순서가 바뀌면 남은 창은 더 빨리 닫힌다.

확정 항목은 정의서 어디에 두나

인코딩, 줄바꿈, BOM, 헤더 유무, 구분자, 날짜 형식을 전문 표 첫 줄에 둔다. 각주는 빠진다.

각주에 적힌 인코딩은 구현자가 안 본다. 전문 표의 첫 블록에 여섯 칸을 둔다.

문자 인코딩, 줄바꿈이 LF인지 CRLF인지, BOM을 넣는지, 첫 줄이 헤더인지, 구분자와 감싸는 따옴표, 날짜와 금액의 형식. 여섯 칸이 상대 기관 담당의 회신과 같이 있어야 확정이다.

우리 쪽 추정으로 채운 칸은 초안이다. PM은 회신 날짜를 그 칸 옆에 적는다.

회신이 2주를 넘기면 그 인터페이스는 임계 쪽에 올린다. 임계에 안 올리면 개발은 UTF-8로 끝나고, 연계 시험 주에 변환 프로그램을 급히 붙인다.

급히 붙인 변환은 전각 문자에서 다시 실패한다. WBS의 연계 시험 앞에 인코딩 확정 칸이 없으면, 시험 주는 개발 주가 된다.

개발로 바뀐 시험 주는 결함 수가 아니라 미확정 수가 올라간다.

샘플은 통과하는데 전수는 왜 깨지나

샘플에 특수문자와 빈 한글, 긴 이름이 없으면 전수 실패는 예정된 일이다. 표본을 일부러 더럽게 만든다.

깨끗한 샘플은 시험을 통과시키기 쉽다. 통과가 목적이면 그 샘플은 위험하다.

전수에서만 나오는 문자를 샘플에 넣는다. 성명 사이 공백, 주소의 동과 호, 법인명의 괄호, 제로폭에 가까운 공백.

열 종류를 20건에 섞어 상대 서버에 먼저 보낸다. 상대가 그 20건을 열어 한글이 살아 있다고 회신해야 샘플 합격이다.

우리 편집기에서 열린 화면을 캡처로 대신하지 않는다. 캡처는 우리 인코딩으로 연 결과다.

상대 회신이 없으면 합격이 아니다. 전수 적재 전에는 깨진 행 수를 센다.

3만 건 중 깨진 행이 40이면 그 40행의 문자 코드를 남긴다. 코드를 안 남기면 다음 리허설에서 같은 40행을 다시 찾느라 반나절이 간다.

반나절은 컷오버 창에서는 없는 시간이다.

변환기를 중간에 넣으면 무엇이 남나

변환기는 임시 우회다. 원본 인코딩, 변환 규칙, 실패 행의 보관 위치를 같이 적지 않으면 운영에 남는다.

오픈을 지키기 위해 중계 구간에 인코딩 변환기를 넣는 선택이 있다. 선택 자체는 가능할 수 있다.

기록이 없으면 그 변환기는 다음 해에도 남는다. 남는 동안 원본을 고친 사람과 변환 규칙을 고친 사람이 달라지고, 장애 때 어느 쪽을 볼지 모른다.

변환기를 허용할 때는 네 줄을 남긴다. 입력 인코딩, 출력 인코딩, 실패하면 파일을 멈추는지 행만 빼는지, 그 기능을 제거할 목표 주.

목표 주가 없으면 임시가 상시가 된다. 상시 변환은 처리 시간을 늘린다.

3만 건에 변환 20분이 붙으면 컷오버 6시간 창의 여유가 줄어든다. 여유를 일정 회의에 숫자로 말한다.

말하지 않으면 변환기는 공짜 안전장치처럼 보인다. 공짜가 아니다.

오픈 당일 거절되면 무엇을 먼저 보나

항목 정의를 다시 열기 전에 인코딩, 줄바꿈, 헤더, 파일 크기를 본다. 네 가지가 맞으면 그때 항목을 본다.

거절 로그가 형식 오류라고만 하면 팀은 전문 항목을 처음부터 다시 읽는다. 그 읽기에 두 시간이 가고, 창은 닫힌다.

순서를 고정한다. 파일이 합의한 인코딩인지, 줄바꿈이 맞는지, 헤더 한 줄이 더 붙었는지, 바이트 크기가 전수 건수와 맞는 범위인지.

네 가지 중 하나가 틀리면 항목 회의를 열지 않는다. 헤더가 더 붙은 파일은 첫 데이터 행이 컬럼명이라 전 행이 거절된다.

이 실수는 리허설에서 한 번 잡아 두면 당일에 안 나온다. 리허설 체크의 첫 줄을 인코딩과 헤더로 바꾼다.

항목 매핑 합격은 그 다음 줄이다. 당일 재전송은 한 번으로 제한한다고 미리 적는다.

제한이 없으면 깨진 파일을 세 번 보내 상대 창구까지 멈춘다. 멈춘 창구의 복구는 우리 일정 밖에 있다.

재전송 파일명에는 시각을 붙여 앞의 거절 파일과 구분한다. 구분이 없으면 상대는 같은 파일을 다시 받은 것으로 보고 창구를 닫아 둔다.

자주 묻는 것

UTF-8로 통일하면 끝나나
상대가 UTF-8을 받을 때다. 수신 측이 CP949만 열면 우리 통일은 거절이다. 회신된 인코딩이 기준이다.
샘플 10건 합격이면 전수도 되나
특수문자와 긴 한글 이름이 샘플에 있을 때다. 깨끗한 10건은 전수 합격의 근거가 아니다.
변환기를 상시로 두면 안 되나
제거 목표 주와 실패 행 처리가 있을 때만 임시로 둔다. 목표 주가 없으면 장애 때 볼 곳이 두 개가 된다.
오픈 당일 거절되면 항목부터 다시 보나
인코딩, 줄바꿈, 헤더, 파일 크기를 먼저 본다. 네 가지가 맞은 뒤에 항목을 연다.

관련 용어

출처

다른 가이드