AI 자동화 출력 형식 비교 — JSON·CSV·마크다운 표 180회 파싱 실측 (2026)
마크다운 표의 구조 실패는 60회 중 15건, 25퍼센트였습니다. CSV의 1건과 비교하면 '몇 배' 수준이 아니라 정확히 15배입니다. 눈에는 멀쩡한 답도 프로그램이 못 읽으면, 뒤에 연결한 자동화까지 통째로 멈춥니다.
파싱 실패에 유난히 인색한 시네가 월급 없는 AI 일꾼을 세 가지 서식으로 번갈아 굴렸습니다. 같은 한국어 사례를 JSON·CSV·마크다운 표로 각각 출력하게 하고, 사람이 중간에서 고쳐주지 않은 채 표준 파서에 바로 넣었습니다. 60사례에 3형식, 총 180회입니다. 2026년 7월 29일 gemma3:4b 로컬 모델에서 측정했습니다.
결론부터 말하면, JSON은 60/60, CSV는 59/60이 파싱됐지만 값까지 맞은 최종 성공은 둘 다 40/60이었습니다. 마크다운 표는 파싱부터 45/60으로 내려갔고, 최종 성공은 28/60이었습니다.
표를 믿다 파이프라인이 표류합니다. 자동화에서는 "보기 좋다"보다 "응답 전체를 그대로 읽을 수 있다"가 먼저였습니다.
눈으로 맞아 보이는 것과 프로그램이 읽는 것은 다릅니다
AI 일꾼이 제출한 보고서를 한 덩어리로 채점하면 원인을 놓칩니다. 인턴 답안에서 문법과 업무 정답을 갈라 보듯, 이번에는 세 단계를 따로 기록했습니다.
- 엄격 파싱 성공 — JSON·CSV·마크다운 파서가 응답 전체를 오류 없이 읽었는가
- 스키마 준수 — 필수 키·열·행 수가 정확한가
- 의미 정확성 — 읽힌 값이 미리 고정한 정답과 같은가
세 단계를 모두 통과한 것만 최종 성공 1건으로 셌습니다. JSON 중괄호가 맞아도 category가 환불 대신 환불 요청이면 값 오류입니다. 반대로 사람이 내용을 알아볼 수 있어도 마크다운 표를 요구했는데 JSON이 나오면 파싱 실패입니다.
공통 전처리는 응답 전체를 감싼 코드펜스 1쌍만 허용했습니다. "결과는 다음과 같습니다" 같은 설명을 잘라내거나, 본문에서 JSON 조각만 찾아내거나, 열이 부족한 CSV를 자동으로 복구하지 않았습니다. 부분 추출을 허용하면 파서의 안정성이 아니라 복구 코드의 영리함을 재게 되기 때문입니다.
60사례에 출력 형식만 세 번 바꿨습니다
같은 일꾼을 세 종류 서식으로 번갈아 굴렸습니다. 시험지는 자동화에서 자주 만나는 세 작업으로 구성했습니다.
- 고객 문의 20건을
환불·배송·교환·상품문의·기타중 하나로 분류 - 발주 문장 20건에서 업체·품목·수량·단가·납기일 추출
- 상품 설명 20건을 제품명·색상·규격·재질·재고 여부로 정규화
각 사례의 입력과 정답은 고정했습니다. 모델도 gemma3:4b 하나만 썼고, 요청은 한 번에 하나씩 보냈습니다. 바뀐 것은 마지막 출력 계약뿐입니다.
- JSON은 객체 1개
- CSV는 헤더 1행과 데이터 1행
- 마크다운 표는 헤더·구분선·데이터 정확히 3행
매 요청 뒤 모델을 내리는 keep_alive: 0 조건이라 총소요 시간에는 콜드 로딩이 섞였습니다. 형식마다 출력 길이도 다르므로 속도는 이번 결론에서 뺐습니다.
첫 파일럿 27회는 한 번 폐기했습니다. 처음 만든 공통 프롬프트가 필드 이름만 알려주고 category 허용값, 날짜 ISO 변환, 재고 Y/N 계약을 빠뜨렸기 때문입니다. 세 형식이 똑같이 1/9로 무너졌고, 그건 형식 비교가 아니라 누락된 지시 비교였습니다. 이 결함을 기록한 뒤 작업별 공통 계약을 보완하고, 새 디렉터리에서 27회를 처음부터 다시 돌렸습니다. 수정한 파일럿은 JSON 9/9·CSV 8/9·마크다운 표 6/9로 본 실험 진행 조건을 통과했습니다.
실측 결과 — JSON과 CSV는 같았고, 마크다운 표만 구조에서 먼저 흔들렸습니다
| 출력 형식 | 엄격 파싱 | 값까지 맞은 최종 성공 | 95% Wilson 구간 | 값 오류 | 구조·행·스키마 오류 |
|---|---|---|---|---|---|
| JSON | 60/60 | 40/60 | 54.1~77.3% | 20건 | 0건 |
| CSV | 59/60 | 40/60 | 54.1~77.3% | 19건 | 1건 |
| 마크다운 표 | 45/60 | 28/60 | 34.6~59.1% | 17건 | 15건 |
월급 없는 일꾼은 JSON 60개를 전부 파서에게 넘겼고, CSV도 59개를 읽히게 만들었습니다. 그런데 최종 성공은 둘 다 40/60입니다. 읽는 데 성공한 것과 업무를 맞게 처리한 것은 다른 문제였습니다.
마크다운 표는 엄격 파싱이 45/60, 최종 성공이 28/60이었습니다. 최종 성공의 95% Wilson 구간은 JSON·CSV가 54.1~77.3%, 마크다운 표가 34.6~59.1%로 조금 겹칩니다. 이 표본만으로 모든 모델에서 마크다운이 열등하다고 증명했다고 말하진 않겠습니다. 다만 이번 180회에서 마크다운 표는 다른 두 형식과 달리 구조 실패 15건을 추가로 만들었습니다.
마크다운 표를 시켰는데 JSON이 돌아왔습니다
표 전담 인턴으로 앉혀 둔 녀석이 계약을 통째로 바꾼 셈입니다. 마크다운 표의 구조 실패 15건은 단순히 파이프 하나가 빠진 경우만이 아니었습니다. 문의 분류에서 표를 요구했는데 모델이 아래처럼 JSON을 반환한 사례가 반복됐습니다.
{
"id": "Q01",
"category": "환불"
}내용은 맞습니다. 사람이 보면 합격입니다. 그러나 계약은 "마크다운 표 3행"이었으므로 표 파서는 이 응답을 읽지 못합니다. 다른 사례에서는 JSON 배열을 반환했고, 상품 정규화에서는 정상 표 아래에 빈 데이터 행을 두 줄 더 붙였습니다. CSV 한 건은 헤더가 6열인데 데이터가 5열로 줄어 스키마 단계에서 탈락했습니다.
JSON·CSV의 실패는 거의 전부 값 오류였습니다. 마크다운 표는 값 오류 17건에 구조 오류 15건이 더 붙었습니다. 사람이 읽을 보고서라면 표가 편하지만, 프로그램끼리 넘기는 중간 데이터라면 모델이 다른 형식으로 갈아타는 순간 복구 분기가 하나 더 필요해집니다. 가성비를 따지면, 구조화 데이터를 먼저 받고 표는 코드로 렌더링하는 쪽이 관리할 가동부가 적습니다.
JSON이 안전해도 자동화가 안전한 것은 아니었습니다
이 일꾼은 중괄호는 반듯하게 맞추고도 업무 답을 틀렸습니다. 모델 인턴의 JSON은 파싱 60/60이었지만 값 오류가 20건이었습니다. 실패는 상품 속성 정규화에 몰렸습니다. 형식별 최종 성공을 작업으로 나누면 다음과 같습니다.
- 고객 문의 분류: JSON 16/20 · CSV 16/20 · 마크다운 표 6/20
- 발주 정보 추출: JSON 18/20 · CSV 18/20 · 마크다운 표 19/20
- 상품 속성 정규화: JSON 6/20 · CSV 6/20 · 마크다운 표 3/20
발주 추출에서는 오히려 마크다운 표가 19/20으로 한 건 높았습니다. 반면 상품 정규화는 세 형식이 모두 크게 무너졌습니다. 제품명에 색상을 붙이거나 모델 코드를 빼고, 화이트를 흰색으로 바꾸는 식으로 정답 계약과 다른 값이 나왔습니다.
이 지점이 형식만 보면 안 되는 이유입니다. 형식만 비교하면 "JSON을 쓰면 해결"이라는 결론으로 달려가기 쉽지만, 어려운 정규화에서는 JSON도 6/20에 그쳤습니다. 형식을 잘 고른 건 문법 오류를 줄일 뿐, 값이 맞는지는 따로 검증해야 합니다. 날짜·수량·허용 라벨·상품 코드처럼 코드로 검사할 수 있는 값은 모델 뒤에 반드시 검증기를 붙여야 합니다.
프롬프트에 필요한 조건을 빠뜨렸을 때 얼마나 크게 무너지는지는 AI 프롬프트 4칸 공식 실측에서도 따로 측정했습니다. 답이 그럴듯해도 원문과 맞대야 하는 이유는 AI 환각을 거르고 검증하는 방법에 정리해뒀습니다.
자동화에서는 이렇게 고르겠습니다
일꾼을 직원처럼 자동화 라인에 넣으려면, 보고서 서식보다 검수 절차를 먼저 정해야 합니다.
API나 프로그램 사이의 기본 교환 형식이라면 JSON을 먼저 고르겠습니다. 이번 단층 스키마에서는 CSV와 최종 성공이 같았지만, JSON은 구조 실패가 0건이었고 키와 타입을 검증하기 편했습니다. 다만 이 글은 중첩 구조를 시험하지 않았으므로 복잡한 JSON까지 안전하다고 확대하면 안 됩니다.
행과 열이 고정된 평면 데이터라면 CSV도 충분한 선택입니다. 59/60이 파싱됐고 최종 성공은 JSON과 같은 40/60이었습니다. 스프레드시트나 기존 CSV 파이프라인으로 바로 넘길 때 굳이 JSON으로 한 번 더 바꿀 이유는 이번 결과에서 찾지 못했습니다.
마크다운 표는 사람이 읽는 마지막 화면에 두겠습니다. 모델에게 표를 직접 요구하기보다, JSON이나 CSV를 검증한 다음 코드로 표를 만드는 편이 안전합니다. 원자료를 구조화 형식으로 보관하면 웹 표·엑셀·차트로 다시 쓰기도 쉽습니다.
어느 형식이든 운영 경로는 같아야 합니다.
- 응답 전체를 파싱하고 실패하면 조용히 복구하지 말고 기록
- 키·열·행 수를 스키마로 검사
- 허용 라벨·날짜·숫자·코드를 별도 검증
- 사람이 읽는 표는 검증된 값에서 렌더링
형식을 고르는 데 10분 쓰고 값 검증을 빼면, 가장 반듯한 JSON으로 오답을 자동 처리하게 됩니다. 이번 테스트에서 가장 비싼 실패는 중괄호가 빠진 답이 아니라, 중괄호는 완벽한데 값이 틀린 답이었습니다.
이 숫자를 어디까지 믿어도 되나
같은 일꾼을 다른 환경에서 굴리면 같은 숫자가 나오지 않을 수 있습니다. 아래 경계 안에서만 읽어주세요.
- 한 모델
gemma3:4b만 측정했습니다. ChatGPT·Claude·Gemini 결과로 옮겨 읽을 수 없습니다. - 한국어 합성 업무문장 60건과 단층 스키마만 썼습니다. 실제 장문 메일·특수문자·여러 데이터 행·중첩 JSON은 더 어렵거나 다른 결과가 날 수 있습니다.
- 마크다운 파서는 양쪽 파이프와 정확히 3행을 요구했습니다. 관대한 파서나 자동 복구를 붙이면 성공률은 올라갈 수 있지만, 그만큼 복구 코드와 오판 경로가 늘어납니다.
- 같은 사례에 형식별 요청을 한 번씩 보냈습니다. 모델의 무작위성까지 반복 측정한 실험은 아닙니다.
- 95% Wilson 구간은 표본 불확실성을 보여주는 범위이지, 다른 모델의 성능을 예측하는 보증서가 아닙니다.
- 측정 시점은 2026년 7월 29일입니다. 모델이나 Ollama 런타임이 바뀌면 결과도 달라질 수 있습니다.
이번 실측에서 JSON과 CSV는 구조화 출력의 출발점으로 충분히 비슷했습니다. 마크다운 표는 사람에게 보여주기엔 좋지만 모델의 중간 출력 계약으로는 15건의 구조 실패를 더 만들었습니다. 셋 다 값 오류에서는 자유롭지 못했습니다.
시네의 선택은 단순합니다. 모델에게는 JSON이나 CSV를 시키고, 코드가 값을 검증한 뒤, 사람에게 보여줄 표는 마지막에 만든다. 보기 좋은 출력보다 검증 가능한 출력이 자동화 비용을 덜 새게 합니다.
참고자료
- Ollama gemma3 모델 정보
- 테스트 방법론: cinevyze 고정 테스트셋
FMT-01~03, 실행기run_format_bench.py, 채점기format_score.py - 원자료: 180개 응답·호출 로그와
aggregate.json을 실행 아티팩트에 보존
이 글은 cinevyze 운영자가 해당 모델을 테스트하고, 180개 원응답을 결정론적 파서로 채점한 뒤 결과를 비교·검수해 정리·편집했습니다. 무엇을 어떻게 테스트할지·판단·사실확인은 모두 사람이 했고, 글 다듬는 일부 과정에 AI 도구의 도움을 받았습니다.
댓글
댓글 쓰기