구축 제안 · 동작 데모 포함

제품표준서 자동 작성
시스템 구축 제안서

만드는 것보다 사람이 확인할 곳을 좁히는 것이 이 시스템의 가치라고 봅니다

신영진 | 풀스택 개발 · 시스템 운영

검토 화면을 먼저 만들어 봤습니다

자동 생성보다 중요한 것은 담당자가 무엇을 확인해야 하는지 알려주는 것이라고 판단했습니다

1확신도를 표시합니다전부 똑같이 보여주면 담당자가 65쪽을 다시 읽어야 합니다. 판독 신뢰도가 낮은 항목만 색으로 구분하면 확인할 곳이 좁혀집니다

2원문을 나란히 둡니다값만 보여주면 맞는지 판단할 수 없습니다. 스캔 원문의 해당 위치를 함께 보여줍니다

3미완은 승인을 막습니다원천이 없는 절을 빈칸으로 둔 채 승인되면 미완성 문서가 확정본이 됩니다. 하나라도 남으면 버튼이 눌리지 않습니다

처리 흐름과 HWPX 생성

단계를 나눠 기록하고, 실패한 단계부터 다시 돌릴 수 있게 만듭니다

처리 현황

7단계로 나눠 성공·실패와 원인을 남깁니다. 깨진 외부 참조는 원문값으로 대체하고 경고로 남긴 뒤 계속 진행합니다. 중단하면 담당자가 매번 파일을 고쳐야 합니다

HWPX 생성

HWPX는 ZIP으로 묶인 XML입니다. 양식 파일을 열어 표 노드를 찾고 행을 복제해 값을 채운 뒤 다시 압축합니다. 한글 프로그램이 필요 없습니다

HWPX 생성 방식과 근거

한글 프로그램 없이 서버에서 생성해야 한다는 조건을 어떻게 충족하는지 말씀드립니다

1파일 구조를 직접 다룹니다HWPX는 한글과컴퓨터가 공개한 개방형 형식이라 압축을 풀면 XML이 나옵니다. 본문·표·병합이 모두 그 안에 있어 파이썬으로 읽고 고칠 수 있습니다. 서버에 한글을 설치하지 않아도 되고 라이선스 문제도 없습니다

2행 증감은 노드 복제배합비 성분이 최대 29행까지 가변이므로 원본 행 노드를 복제해 데이터 수만큼 만듭니다. 셀 서식과 테두리가 원본과 동일하게 유지됩니다

3병합이 가장 어렵습니다행을 복제할 때 병합 범위를 함께 재계산해야 합니다. 쪽을 걸치는 세로 병합과 다층 병합이 있다고 하셨는데, 여기가 오류가 가장 잦은 지점이라 별도 검증 항목으로 둡니다

4저장 성공은 정상이 아닙니다병합이 어긋나도 파일은 저장됩니다. 한글에서 열 때 깨집니다. 그래서 생성 후 다시 열어 표 개수와 쪽 수를 확인하는 단계를 반드시 둡니다

제형 분기는 규칙표로 분리합니다 — 9개 절 26개 소절의 포함 여부를 코드에 박지 않고 설정 파일로 둡니다. 제형이 추가되거나 양식이 개정될 때 코드를 고치지 않고 표만 수정하면 되도록 하기 위함입니다.

스캔 인식 정확도를 어떻게 보장하는가

"정확도 몇 %를 보장한다"고 말씀드리지 않겠습니다. 대신 측정하고 관리하는 방법을 제안드립니다

1기준 표본으로 측정착수 초기에 표본 PDF에서 항목별 정답을 사람이 작성하고, 판독 결과와 대조해 항목 단위 정확도를 냅니다. 전체 평균이 아니라 항목별로 봐야 어디가 약한지 드러납니다

2항목별 보정 규칙숫자 항목은 단위·자릿수, 날짜는 형식, 규격은 허용 목록 대조로 검증합니다. "KP 12"가 "KP 1Z"로 읽혔다면 목록에 없으므로 확신도를 낮춰 표시합니다

3확신도를 그대로 노출낮은 값을 숨기지 않습니다. 담당자가 어디를 봐야 하는지 알게 하는 것이 목적이므로, 임계값 아래는 전부 표시합니다

4운영하며 조정초기에는 임계값을 높게 잡아 확인 대상을 넓히고, 실제 오류율이 확인되면 낮춥니다. 처음부터 자동 통과 범위를 넓히면 잘못된 값이 그대로 승인됩니다

인식 정확도는 입력 문서 품질에 좌우됩니다 — 발행 주체와 서식이 제각각이면 같은 항목도 위치와 표현이 달라집니다. 공고에서도 이 점을 확인 중이라고 하셨는데, 착수 초기 진단에서 표본을 유형별로 나눠 어느 유형이 어려운지 먼저 파악하겠습니다. 그 결과에 따라 수용 기준을 함께 정하는 편이 정확합니다.

자동 검증과 사람 확인의 역할 분담

무엇을 기계가 걸러내고 무엇을 사람이 보는지 나눕니다

구분	담당	내용
형식 검증	자동	필수 항목 누락, 숫자 형식, 날짜 형식, 단위 일치, 값 범위. 기계가 확실히 판정할 수 있는 것만 자동 처리합니다
대조 검증	자동	규격·원료명이 허용 목록에 있는지, 배합비 합계가 100%인지, 엑셀 유도값과 원문값이 어긋나지 않는지
문서 검증	자동	생성된 HWPX가 정상적으로 열리는지, 표 개수와 쪽 수가 예상과 맞는지
확신도 낮은 항목	사람	기계가 "이건 확실하지 않다"고 표시한 것. 판단은 사람이 합니다
원천 없는 항목	사람	입력 두 종으로 채워지지 않는 절. 미완으로 표시하고 승인을 막습니다
최종 승인	사람	승인자와 시각이 이력에 남습니다. 승인 이후에만 정식 산출물이 됩니다

LLM은 보조로만 씁니다 — 예외 보완과 결과 점검에 쓰되, LLM이 판단한 값도 확신도 낮은 항목으로 표시해 사람이 확인하게 합니다. LLM은 그럴듯한 답을 만들어내는 성질이 있어, 검증 없이 믿으면 오히려 찾기 어려운 오류가 생깁니다. 호출량과 비용은 건별로 기록하고 한도를 둡니다.

반출 금지 정보 차단

원료사·단가와 외부 참조에 남은 타 품목 정보를 어떻게 막는지

1제외가 아니라 안 읽습니다읽어서 메모리에 올린 뒤 전송할 때 빼는 방식은 한 군데만 빠뜨려도 나갑니다. 판독 단계에서 제외하면 시스템 어디에도 존재하지 않습니다

2수식은 버립니다셀에는 값만 보이지만 수식 안에 다른 파일 경로와 거래처명이 남아 있습니다. 값만 읽고 수식 문자열은 버립니다

3차단 로그를 남깁니다무엇을 걸렀는지 기록해 나중에 확인할 수 있게 합니다

금융권에서 민감정보를 다뤄온 방식입니다. 마이데이터와 자금세탁방지 시스템은 조회 범위 제한과 전송 대상 통제가 기본 요건이었습니다. "보호를 잘하는 것보다 애초에 덜 가지는 것이 안전하다"는 원칙을 여기에도 적용했습니다.

추가 도입 검토 항목에 대한 의견

이번 범위 밖이지만 확장 가능한 구조로 설계하겠습니다

항목	권장안	개략 규모
기준정보 관리	이번에 자리만 잡는 것을 권장합니다. 원료 규격·설비·자재·표시사항을 지금은 사람이 채우더라도, 그 값이 들어갈 데이터 구조를 미리 만들어 두면 나중에 화면만 추가하면 됩니다. 구조 없이 나중에 붙이면 기존 데이터를 다시 정리해야 합니다	구조 설계 이번 포함 화면은 2차
사내 시스템 연동	2차 권장. 엑셀 업로드로 먼저 운영해 보시고, 어떤 항목이 실제로 쓰이는지 확인된 뒤 연동하는 편이 낫습니다. 지금 연동하면 쓰지 않을 항목까지 맞추게 됩니다. 업로드 처리부를 분리해 두면 연동 시 그 부분만 교체됩니다	2차 중간 규모
액상 양식 판독	양식 실물 확인이 먼저입니다. 정제용과 구조가 크게 다르면 판독 규칙을 새로 만들어야 하고, 비슷하면 규칙표에 유형 하나를 추가하는 수준입니다. 양식을 보기 전에는 규모를 말씀드릴 수 없습니다	확인 후 산정

양식 실물 없이 남는 불확실 구간 — 계약 후 제공하신다고 하셨으므로, 다음 항목은 실물 확인 후 확정해야 합니다. ① 42종 표 중 행 가변 표의 실제 개수와 병합 형태 ② 26개 소절의 분기 조건 ③ 입력 두 종으로 채워지는 절과 그렇지 않은 절의 경계 ④ 첨부·별첨 양식.

이 부분은 착수 후 1~2주를 양식 분석에 쓰는 것을 전제로 일정을 잡겠습니다. 추정으로 시작하면 중간에 되돌리게 됩니다.

기술 구성 · 일정 · 견적

기존 시제품이 파이썬이고, 한글 없이 생성해야 하며, 사내 인수가 가능해야 한다는 세 조건에 맞춰 제안드립니다

영역	제안	근거
처리 엔진	Python	기존 시제품이 파이썬이라 담당자가 만든 로직을 참고·이식할 수 있습니다. OCR·문서 처리 라이브러리도 파이썬이 가장 풍부합니다
웹 · API	Python 웹 프레임워크	처리 엔진과 같은 언어로 맞춥니다. 언어가 둘이면 인수받는 쪽 부담이 두 배가 됩니다
백그라운드 처리	작업 큐	한 건에 1분 이상 걸리므로 화면을 붙잡지 않고 뒤에서 처리합니다. 월말 집중을 견디려면 필수입니다
DB	PostgreSQL	작업 이력·감사 로그·개정 이력을 남깁니다
HWPX	XML 직접 처리	양식 구조를 직접 다루므로 외부 의존이 적고 버전 고정이 쉽습니다

일정과 견적 — 양식 실물을 보기 전이라 확정 금액을 드리기 어렵습니다. 다만 범위 기준 개략을 말씀드리면, 65쪽 13절 42표에 OCR·엑셀 판독·웹 시스템 13화면·권한과 감사 로그까지 포함하면 3~4개월 규모로 봅니다. 1~2주 양식 분석 후 상세 작업지시서와 함께 확정 견적을 드리는 방식을 제안드립니다.

계약 특이사항에 "착수 전 확인 필요 항목을 협의해 범위를 확정한 뒤 계약한다"고 하셨는데, 그 방식에 동의합니다. 양식을 보지 않고 금액을 확정하면 양쪽 모두 손해입니다.

성공적인 마무리의 기준

한 건을 자동으로 만드는 것과, 연 500~600건을 이 시스템으로 처리하는 것은 다릅니다

1담당자가 혼자 끝내는 것여러 사람이 나눠 쓰고, 누가 무엇을 언제 승인했는지 남는 것. 지금 시제품이 한 사람 환경에서만 도는 문제를 푸는 것이 이 프로젝트의 출발점입니다

2확인 시간이 줄어드는 것생성 시간보다 담당자가 검토에 쓰는 시간이 중요합니다. 확신도 표시가 제대로 동작하면 65쪽을 다 보지 않아도 됩니다

3깨진 문서가 안 나가는 것승인된 문서가 한글에서 열리지 않거나 표가 어긋나는 일이 없는 것. 자동 검증 단계에서 걸러집니다

4사내에서 이어갈 수 있는 것개발 인력이 없으시므로, 양식이 개정되거나 규칙이 바뀔 때 무엇을 고쳐야 하는지가 문서로 남아야 합니다. 규칙을 설정으로 분리한 이유이기도 합니다

인수인계 산출물 — 요구사항·화면·데이터 설계서, 입력 대응 규칙 정의서, 인터페이스 명세, 시험 결과서, 운영 매뉴얼, 운영자 교육에 더해 양식 교체 절차서와 장애 대응 안내를 포함하겠습니다. 개발 인력이 없는 환경에서는 "문제가 생겼을 때 어디를 보는가"가 가장 필요한 문서입니다.

확인할 곳을
좁혀 드리겠습니다

자동으로 만드는 것보다, 사람이 무엇을 봐야 하는지 알려주는 것이 이 시스템의 가치라고 봅니다.
데모는 직접 눌러보실 수 있습니다.