SCM CSV 검수: 줄 수와 주문 레코드 수가 다른 이유

SCM CSV는 줄 수와 레코드 수를 나눠 검수합니다. 2026-11-07 기준, 인용된 필드 안의 줄바꿈은 새 주문이 아닙니다.

파일을 받았고 오류도 없는데 주문 건수가 맞지 않을 수 있습니다. 비고에 들어간 쉼표나 줄바꿈을 데이터 경계로 잘못 잘랐는지부터 확인해야 합니다. 이 글은 CSV를 수신하는 단계의 구조 검수와 파일 보류 기준을 다룹니다.

연동 범위를 정하는 단계라면 ERP 연동 SCM 구축 가이드를 먼저 볼 수 있습니다. JSON 주문번호의 타입·자릿수 보존은 SCM 주문번호 정밀도 검수에서 다룹니다. 여기서는 주문 값의 의미를 판단하기 전 CSV 레코드가 어떻게 복원됐는지 확인합니다.

CSV 줄 수를 주문 건수로 써도 되나요?#

인용된 필드에 줄바꿈이 있으면 물리적 여러 줄이 한 레코드를 이룹니다. 헤더까지 포함한 줄 수를 데이터 레코드 수로 쓰면 대사 기준부터 달라집니다. 먼저 구분자·인용 문자·헤더 유무를 정하고 파서가 돌려준 레코드를 셉니다.

RFC 4180 §2는 줄바꿈·쉼표가 들어간 인용 필드와 내부 따옴표의 겹표기를 설명합니다. 문서는 2005-10의 Informational RFC이며 인터넷 표준을 제정한 문서는 아닙니다. 공급자별 파일 차이가 있으므로 이 설명만으로 모든 CSV가 같은 계약이라고 가정하지 않습니다. RFC 4180 원문을 2026-11-07 확인했습니다.

파일 송신자는 어떤 내보내기 규칙을 썼는지 제시합니다. 수신 개발자는 그 규칙으로 레코드·필드를 복원하고, 현업 인수자는 어떤 레코드가 어떤 주문 또는 주문 품목에 대응하는지 정합니다. 주문 하나에 여러 품목 레코드가 있다면 데이터 레코드 수와 고유 주문 수도 따로 셉니다.

Python 공식 문서도 csv reader의 line_num이 반환 레코드 수와 다르다고 설명합니다. 인용 필드가 여러 줄에 걸칠 수 있기 때문입니다. Python 3.14는 2025-10-07 최초 발행됐으며, 확인한 3.14 계열 csv 문서는 3.14.10 표기·2026-11-07 갱신본입니다. 아래 실험은 설치된 3.14.2에서 수행했고 이 동작이 새로 추가된 기능이라고 주장하지 않습니다.

같은 주문 자료를 어떻게 바꿔 검수하나요?#

정상 입력과 인용 문자, 잘린 입력을 같은 파서 설정으로 비교합니다. 아래 예시는 가상의 열 order_id·qty·note를 사용하며 데이터 한 레코드를 주문 하나로 정의했습니다. 표의 “구조 후보”는 업무 검수로 넘길 수 있다는 뜻이며 주문 등록 완료가 아닙니다.

이 표의 파일 보류는 저희가 예시로 고른 인수 정책입니다. 파서나 RFC가 업무 전체의 반영 단위를 정해 주지는 않습니다. 실제 SCM·DB에 적재하거나 고객 파일로 시험한 결과도 아닙니다. 문자 인코딩·BOM·한글·대용량·수식·수량 타입·상품 존재 여부는 이 실험에 포함하지 않았습니다.

합성 입력·기대값 JSON과 같은 관측을 확인하는 Python 스크립트를 공개했습니다. 두 파일을 같은 폴더에 저장한 뒤 python3 scm-csv-record-check.py로 실행할 수 있습니다. 이 스크립트는 입력·관측 대조용이며 운영 업로더가 아닙니다.

따옴표 안의 줄바꿈은 어떻게 재현하나요?#

줄을 먼저 나누어 각각 주문으로 처리하면 인용 필드의 경계를 잃습니다. 줄바꿈을 보존한 입력을 CSV 파서에 넘기고, 헤더와 데이터 레코드를 구분합니다. 다음 문자열은 표의 인용 CRLF 조건과 같은 합성 입력입니다.

import csv
import io

csv_text = (
    'order_id,qty,note\r\n'
    'A-01,2,"first\r\nsecond"\r\n'
    'A-02,3,last\r\n'
)
rows = list(csv.reader(
    io.StringIO(csv_text, newline=''),
    delimiter=',', quotechar='"',
    doublequote=True, strict=True,
    skipinitialspace=False,
))
header, data_rows = rows[0], rows[1:]

이 입력의 물리적 줄은 헤더 포함 4줄이고 데이터 레코드는 2개입니다. 첫 레코드의 비고는 CRLF를 포함한 한 필드로 남습니다. 원고의 문자열을 평가해 공개 표본의 입력과 같은지 확인했습니다. 쉼표나 줄바꿈을 수동 치환해 사라지게 만들면 원천 값이 바뀌므로, 구분자로 해석할 위치와 값으로 보존할 위치를 구별해야 합니다.

공식 csv 문서는 파일을 열 때 newline=''를 지정하고 인코딩도 명시할 수 있도록 안내합니다. 이 실험은 이미 만들어진 문자열을 StringIO에 넣으므로 바이트 디코딩은 시험하지 않았습니다. 파일에서 읽는 구현은 문자 인코딩부터 별도로 확인해야 합니다. 출처는 Python csv의 파일 읽기·개행 설명입니다.

파싱에 성공하면 바로 반영해도 되나요?#

파싱 성공 뒤에도 헤더·열 수와 업무 값을 검사해야 합니다. 표의 짧은 레코드는 strict=True에서도 오류 없이 읽혔고, 중복 헤더 역시 별도 비교가 없으면 기대 구조와의 차이를 놓칩니다. 엄격 모드 하나를 전체 인수 검증으로 쓰지 않습니다.

첫째, 파일 계약에는 인코딩·구분자·인용 규칙·헤더의 이름과 순서·빈 줄 처리 기준을 적습니다. 둘째, 구조 검수에는 파싱 오류, 헤더 일치, 각 데이터 레코드의 필드 수를 남깁니다. 셋째, 구조를 통과한 자료에 주문번호·수량·상태·중복·기준일 검수를 적용하고 반영 승인을 분리합니다. 이 순서는 설계 예시이며 실제 업무 명세로 확정해야 합니다.

닫히지 않은 인용 필드 앞에서 읽힌 정상 레코드도 자동 반영 수로 세지 않는 정책을 표에 적용했습니다. 이 보류 정책이 실제 DB 트랜잭션으로 구현됐다는 뜻은 아닙니다. 파일 전부를 검수한 뒤 반영할지, 항목별 부분 성공을 허용할지는 별도 합의하고 실패·재처리 표본으로 확인해야 합니다. 업무별 부분 성공은 SCM 일괄 처리 검수에서 다룹니다.

CSV 파서에 기본 설정을 맡기는 것만으로 공급자 파일을 모두 해석할 수는 없습니다. 세미콜론·탭·다른 문자셋, 헤더 없는 자료, 빈 값과 NULL의 의미도 이번 표와 다를 수 있습니다. 추정해서 열을 맞추거나 잘린 비고를 다음 주문으로 보정하기 전에 송신 규칙과 기대 결과를 확인합니다.

확인일은 2026-11-07이며 다음 검토일은 2026-12-07입니다. 파일 계약이나 파서 버전이 바뀌면 같은 합성 표본과 비식별 업무 표본을 다시 대조합니다. 관측 재현은 모든 CSV 형식의 적합성이나 실제 업무의 정확성을 보장하는 시험이 아닙니다.

SCM CSV 줄바꿈 검수 FAQ#

CSV 수신 인수표 초안 협의#

알파카랩스는 맞춤 ERP 개발 서비스에서 기존 시스템과의 API·파일 연동, 이관·대사·실패 후 재처리의 검수 범위를 협의한다고 설명합니다. 이는 자사 제공 범위의 설명이며 위 합성 실험이 고객 납품 사례라는 뜻은 아닙니다. 비식별 원본 파일·열 명세·기대 레코드와 반영 단위를 준비하면 구조·업무·반영 판정을 나눈 인수표 초안을 협의할 수 있습니다. 소요 시간은 자료와 연동 범위를 확인한 뒤 정합니다.