P&ID·설계 PDF를 RAG에 넣기 전: 표·도형·체크박스 추출 품질부터 검증하는 법
설계 PDF 기반 RAG의 첫 산출물은 챗봇이 아니라, 원문과 대조해 통과 여부를 판단할 수 있는 **추출 승인표**여야 합니다.
설계 PDF 기반 RAG의 첫 산출물은 챗봇이 아니라, 원문과 대조해 통과 여부를 판단할 수 있는 추출 승인표여야 합니다.
들어가며 — 독자가 지금 이 문제를 검색하는 이유
사내에 쌓인 P&ID, 설계 사양서, 검사표, 품질절차서를 AI 검색에 활용하려면 보통 “PDF를 임베딩해 검색하면 되지 않을까?”라는 질문부터 나옵니다. 하지만 설계 문서는 일반 텍스트 문서와 다릅니다. 설비 태그는 표 안에 있을 수 있고, 주의사항은 도형 옆 주석에 적혀 있을 수 있으며, 점검 상태는 체크박스나 선택 표시로 남아 있을 수 있습니다.
이때 원본 구조가 추출 단계에서 무너지면, 이후 검색·답변 단계가 아무리 좋아도 근거 문서를 정확히 찾기 어렵습니다. 설계 PDF RAG의 첫 질문은 “어떤 챗봇을 쓸 것인가?”가 아니라 다음이어야 합니다.
“우리 문서에서 검색해야 할 표·선택 표시·제목 구조가 원문대로 추출되는가?”
RAG 이전에 확인할 것: PDF는 텍스트 묶음이 아니라 구조화 대상입니다
Microsoft의 Document Intelligence Layout 모델 문서는 텍스트뿐 아니라 표, 선택 표시(selection marks), 문서 구조도 추출 대상으로 설명합니다. 문서의 제목·섹션·표·선택 표시가 어떤 구조로 반환되는지 확인할 수 있다는 뜻입니다.
출처: Microsoft Learn — Document layout analysis
설계 PDF를 RAG에 넣을 때 이 기능 목록을 곧바로 “P&ID 의미를 자동으로 이해한다”는 뜻으로 받아들이면 안 됩니다. 공식 문서가 설명하는 범위는 문서 레이아웃과 구성 요소의 추출입니다. 특정 P&ID에서 기호의 의미, 배관 연결 관계, 설계 의도를 얼마나 정확히 판정하는지는 문서 형식·스캔 품질·표기 규칙에 따라 달라집니다. 별도 검증이 필요합니다.
초기 적용 범위는 작게 잡는 편이 좋습니다.
- 스캔본과 디지털 PDF가 섞인 문서를 포함합니다.
- P&ID 또는 설계 문서 가운데 대표성이 있는 샘플을 고릅니다.
- 설비 태그, 표, 주석, 제목 계층, 체크박스처럼 실제 검색에 필요한 요소를 지정합니다.
- AI 답변을 평가하기 전에 추출 결과와 원문을 사람이 대조합니다.
여기서 중요한 것은 “문서 전체를 한 번에 자동화”하지 않는 일입니다. 먼저 검색 품질을 좌우할 구조가 무엇인지 정하고, 그 구조가 보존되는지 확인해야 합니다.
5~10개 샘플에서 만들어야 할 산출물: 설계 PDF 추출 승인표
초기 검증의 결과물은 모델 점수나 데모 화면이 아니라 설계 PDF 추출 승인표입니다. 승인표에는 추출 결과가 실제 업무 검색에 쓸 수 있는 수준인지 문서별·항목별로 기록합니다.
검수 항목 | 원문에서 확인할 대상 | 추출 결과에서 볼 기준 | 판정 |
|---|---|---|---|
설비 태그 | 도면·표·주석에 표시된 태그 | 태그 문자열이 누락·분리·오인식되지 않았는가 | 통과 / 보완 / 확인 필요 |
표 | 장비 목록, 사양표, 점검표 | 행·열 관계와 헤더가 유지되는가 | 통과 / 보완 / 확인 필요 |
선택 표시 | 체크박스, 선택란, 완료 표기 | 선택 여부와 위치가 원문과 일치하는가 | 통과 / 보완 / 확인 필요 |
제목 계층 | 문서 제목, 절, 하위 절 | 검색 단위로 나눌 수 있게 계층이 유지되는가 | 통과 / 보완 / 확인 필요 |
주석 | 도형 주변의 경고·보충 설명 | 본문과 다른 위치의 주석이 누락되지 않았는가 | 통과 / 보완 / 확인 필요 |
이 표에서 중요한 것은 추출 결과가 “보기 좋게” 정리됐는지가 아니라 원문과 대조할 수 있는지입니다. 예를 들어 표 안의 태그가 텍스트로 존재하더라도 다른 행의 사양과 결합됐다면, 검색 시 잘못된 근거가 될 수 있습니다. 체크박스도 기호 자체를 인식했는지에 그치지 않고, 어떤 점검 항목과 연결되는지 확인해야 합니다.
검수자는 각 항목을 다음 세 가지로 단순하게 판정할 수 있습니다.
1. 통과: 원문과 대조했을 때 검색·인용에 사용할 수 있는 수준입니다.
2. 보완: 후처리 규칙, 문서 분할 방식, 원본 품질 개선 등이 필요합니다.
3. 확인 필요: 사람이 의미를 판정해야 하거나, 특정 문서군에서 추가 표본 검증이 필요합니다.
“추출 성공”과 “검색 가능”을 같은 말로 쓰지 않는 법
텍스트와 표가 추출됐다고 해서 곧바로 RAG 검색 품질이 확보되는 것은 아닙니다. 추출 단계의 통과 기준은 검색 단계의 설계 조건으로 이어져야 합니다.
예를 들어 설비 태그가 중요한 검색 키라면, 다음 질문을 실제로 재현해 봐야 합니다.
- 특정 설비 태그를 검색했을 때 해당 태그가 포함된 표와 주석을 찾을 수 있는가?
- 표의 헤더와 값의 관계가 보존돼, 사양값이 다른 장비에 잘못 연결되지 않는가?
- 체크된 점검 항목과 체크되지 않은 항목을 구분할 수 있는가?
- 제목·절 구조를 따라 검색 결과의 출처 위치를 사람이 다시 확인할 수 있는가?
P&ID 도형의 의미 판정처럼 문서 구조 추출만으로 결론 내리기 어려운 항목은 분리해야 합니다. 해당 영역을 “자동 추출 완료”로 처리하지 말고, 사람 검수나 별도 도메인 규칙이 필요한 확인 필요 영역으로 남기는 편이 안전합니다.
RAG 구축 순서는 다음과 같이 잡을 수 있습니다.
1. 대표 문서 5~10개를 선정합니다.
2. 태그·표·선택 표시·제목·주석 등 검수 항목을 정합니다.
3. 추출 결과를 원문과 나란히 비교합니다.
4. 승인표에 통과·보완·확인 필요를 기록합니다.
5. 통과한 구조만 검색 인덱스와 답변 근거에 우선 활용합니다.
6. 보완 항목은 원본 품질, 문서 분할, 후처리 규칙 관점에서 다시 점검합니다.
바로 적용하는 체크리스트
- [ ] RAG 전체 구축 전에 대표 설계 PDF 5~10개를 선정했습니다.
- [ ] 스캔본과 디지털 PDF가 혼재돼 있다면 둘 다 표본에 포함했습니다.
- [ ] 문서별로 설비 태그, 표, 선택 표시, 제목 계층, 주석의 중요도를 표시했습니다.
- [ ] 추출 결과만 보지 않고 원본 PDF와 대조할 담당자를 정했습니다.
- [ ] 표의 행·열·헤더 관계가 유지되는지 별도로 확인했습니다.
- [ ] 선택 표시가 어떤 점검 항목에 연결되는지 확인했습니다.
- [ ] 도형·기호의 의미 판정처럼 자동 처리가 불확실한 영역을 “확인 필요”로 분리했습니다.
- [ ] 검색 인덱스에는 승인표에서 통과한 구조부터 반영하기로 했습니다.
- [ ] “추출됐다”와 “업무 검색 근거로 사용할 수 있다”를 서로 다른 승인 기준으로 관리합니다.
마무리
설계 PDF RAG의 성패는 처음부터 거대한 지식베이스를 만드는 데 있지 않습니다. 원문 안의 태그, 표, 선택 표시, 제목 구조가 검색 가능한 형태로 남는지 검수하는 작은 단계에서 시작됩니다.
문서 구조 추출 기능은 출발점이 될 수 있습니다. 다만 실제 설계 문서에서 무엇을 정확한 근거로 쓸 수 있는지는 샘플 문서와 사람 검수로 확인해야 합니다. 챗봇보다 추출 승인표를 먼저 만들면, 이후 검색·답변 품질 문제를 더 이른 단계에서 발견할 수 있습니다.
생각해볼 질문: 우리 조직의 설계 PDF에서 “검색 결과에 반드시 원문 그대로 남아야 하는 정보”는 설비 태그, 표, 체크 상태, 주석 중 무엇일까요?
이 글이 도움이 되었나요?
관련 포스트
사내 문서 검색, 챗봇보다 먼저 "Gemini Enterprise 업무 포털"로 검증해야 합니다
사내 AI 검색 PoC는 답변 품질보다 먼저 "어떤 업무 앱을 연결하고, 권한을 어떻게 지키며, 검색 결과를 어떤 업무 흐름으로 바꿀 것인가"를 확인해야 합니다.
Claude Agent Skills로 반복 문서 산출물을 팀 표준으로 만드는 법
매번 프롬프트를 다시 쓰는 대신, `SKILL.md`·템플릿·검증 체크리스트를 한 폴더에 묶으면 리서치 브리프나 보고서 같은 반복 문서 업무를 팀 표준 산출물로 재현할 수 있습니다.
리서치 AI 비교, 긴 보고서보다 출처 범위부터 정해야 합니다
ChatGPT·Claude·Gemini Deep Research를 비교할 때는 "누가 더 긴 보고서를 쓰는가"보다 "어떤 출처를 허용하고, 내부자료를 어떻게 섞고, 인용을 어떻게 확인하게 해주는가"를 먼저 봐야 합니다.
ChatGPT가 앱 스토어가 되면, SaaS 도입 검토는 이렇게 바뀝니다
ChatGPT 안에서 앱을 발견하고 연결하는 흐름이 열리면, 기업의 SaaS 검토는 “기능 비교”보다 “어떤 데이터와 실행 권한을 넘길 것인가”를 먼저 묻는 일로 바뀝니다.
에이전트 PoC를 운영으로 넘기기 전, OpenTelemetry GenAI 로그부터 표준화해야 합니다
에이전트 로그는 프롬프트 전문 보관소가 아니라, operation·tool·model·latency·error를 추적하는 운영 telemetry로 설계해야 합니다.
Google Workspace Gemini로 문서 초안을 만들기 전, 출처부터 선택해야 합니다
Gmail·Drive·Docs·Slides·Chat을 오가는 업무에서 Gemini를 쓰려면, 먼저 “어떤 파일과 메일을 근거로 삼게 할 것인가”를 정해야 합니다.