AI Knowledge Base for Drawings: 구켄공업, 70년치 도면 찾기를 평균 4.5분으로 줄이다

구켄공업은 숙련자의 기억에 기대던 과거 도면 찾기를, AI가 부품 번호로 후보를 찾고 기술자가 원본을 보고 고르는 일로 바꿨습니다. 후쿠오카 공장 시험에서 수십 분에서 반나절 걸리던 일이 평균 4.5분이 됐습니다. 따라 하려면 모델보다 먼저 부품 번호·형번·치수를 뽑아 둔 지식 DB와, 개정판까지 후보로 보여 주는 매칭 규칙이 필요합니다.

요약

구켄공업(空研工業)은 후쿠오카에 본사를 둔 일본 공조 설비 제조사입니다. 상업 시설, 병원, 공장에 들어가는 냉각탑 같은 공조 기기를 70년 넘게 설계하고 만들어 왔습니다. 그동안 쌓인 도면과 기술 자료는 종이에서 디지털로 옮겨 두었지만 만든 연대와 형식, 표기가 제각각이었습니다. 회사는 OpenAI Advanced Partner인 Recursive와 함께 OpenAI API로 ‘AI 지식 기반 시스템’을 만들었습니다. AI가 도면, 사양서, 기술 자료에서 부품 번호·형번·치수를 뽑아 지식 DB(Knowledge DB)로 다시 짰습니다. 그 위에 두 기능을 웹 앱으로 올렸습니다. 하나는 부품표(BOM)를 올리면 맞는 과거 도면 페이지를 찾아 주는 도면 검색이고, 다른 하나는 여러 문서의 내용이 서로 맞는지 대조하는 도면 체크입니다.

바꾼 이유는 찾는 데 드는 시간과 사람 의존이었습니다. 이미 납품한 설비를 정비하려면 그 설비의 도면부터 찾아야 하는데, 개정 가지 번호와 표기 흔들림 때문에 어느 자료가 맞는지 고르는 일이 담당자 경험에 달려 있었습니다. 공장에 넘긴 사양이 외형도와 납입 사양서에 제대로 들어갔는지도 사람이 문서를 나란히 놓고 눈으로 맞춰 봤습니다. 후쿠오카 공장 시험에서 도면 찾기는 평균 4.5분으로 줄었습니다. 이전에는 수십 분에서 1시간, 때로는 반나절이 걸렸습니다. 회사는 2025년도 실적을 바탕으로 도면 검색 공수가 연간 약 90% 줄 것으로 추정하고, 숙련 기술자가 젊은 직원 육성과 어려운 안건에 시간을 쓸 수 있게 됐다고 설명합니다. 2026년 안에 후쿠오카·지바 두 공장에 본격 도입하는 것이 목표입니다. 아래에서 이 구조를 다섯 메커니즘으로 풀고, 직접 만들 때의 기술·현업 디테일을 붙입니다.

핵심 메커니즘

Structured Extraction: 도면 더미를 부품 번호로 찾는 DB로

무엇인가. 스캔하거나 PDF로 둔 도면과 문서에서 검색 열쇠가 될 항목을 뽑아 구조화하는 단계입니다. 구켄공업 시스템은 부품 번호, 형번, 치수를 뽑아 Knowledge DB로 다시 짭니다.

어떻게 작동하나. 디지털화만 한 도면은 파일 이름이나 폴더로만 찾을 수 있습니다. AI가 각 페이지를 읽어 어떤 부품 번호와 형번이 어느 페이지에 있는지를 기록하면, 부품 번호가 곧 검색어가 됩니다. 각 값이 어느 문서 어느 쪽에서 나왔는지도 함께 남겨야 결과 화면에서 원본을 바로 띄울 수 있습니다.

언제 쓰고 언제 안 쓰나. 연대마다 양식이 달라 규칙 기반 파서로는 감당이 안 되는 자료에 맞습니다. 최근 도면이 이미 PLM이나 CAD 속성으로 관리되고 있다면 그 메타데이터를 먼저 쓰는 편이 싸고 정확합니다.

원문의 예. 도면, 사양서, 기술 자료에서 부품 번호·형번·치수를 AI로 추출하고 구조화해 Knowledge DB로 재구축했습니다.

BOM-driven Matching: 부품표로 찾고 개정판까지 후보로

무엇인가. 검색어를 사람이 치는 대신 부품표를 올리면, AI가 거기서 부품 번호를 뽑아 맞는 과거 도면 페이지를 찾는 방식입니다.

어떻게 작동하나. 결과는 세 층으로 나옵니다. 번호가 똑같은 완전 일치, 개정 번호나 가지 번호만 다른 후보, 문자열이 비슷한 후보입니다. 오래된 설비일수록 같은 부품이 여러 번 개정됐고 사람마다 번호를 다르게 적었기 때문에, 완전 일치만 찾으면 놓치는 도면이 생깁니다. 후보마다 도면 페이지 미리보기가 붙어 담당자가 바로 원본을 확인합니다.

언제 쓰고 언제 안 쓰나. 정비·교체처럼 부품 번호가 출발점인 업무에 맞습니다. 번호 없이 모양이나 기능으로 찾아야 하는 일에는 이미지 유사도 검색 같은 다른 열쇠가 필요합니다.

원문의 예. 부품표를 올리면 부품 번호를 뽑아 대응하는 도면 페이지를 자동으로 찾고, 개정·가지 번호 차이와 표기 흔들림까지 고려한 후보를 보여 줍니다.

Diff as Candidates: 문서 간 차이를 후보 목록으로 띄운다

무엇인가. 기준 문서와 다른 문서를 대조해, 값이 어긋나는 곳을 AI가 후보로 표시하는 도면 체크 기능입니다.

어떻게 작동하나. 담당자가 공장 仕切 통지서(工場仕切通知書, 도면 체크의 기준 문서)와 외형도, 납입 사양서를 올립니다. AI는 각 문서에서 형번, 치수, 주기(注記)를 뽑아 기준 문서와 비교하고, 다른 곳을 원본의 해당 위치와 나란히 보여 줍니다. 외형도에 꼭 있어야 할 주기와 벌룬(부품 번호를 가리키는 표시)이 빠졌는지도 봅니다.

언제 쓰고 언제 안 쓰나. 같은 사양이 여러 문서에 옮겨 적히고, 옮기다 생긴 불일치가 납품 문제로 이어지는 업무에 맞습니다. 문서가 한 시스템에서 자동 생성된다면 대조보다 원천 데이터를 하나로 묶는 편이 낫습니다.

원문의 예. 공장 仕切 통지서의 사양이 외형도·납입 사양서에 제대로 반영됐는지 사람이 견주어 보던 일을 차이 후보 제시로 바꿨습니다.

Human-final Review: AI는 후보까지, 결정은 기술자가

무엇인가. AI의 결과를 정답이 아니라 후보로 다루고, 기술자가 원본 자료를 확인해 최종 판단하는 설계입니다.

어떻게 작동하나. 두 기능 모두 결과 화면에 원본 페이지를 함께 띄웁니다. AI는 탐색과 비교를 돕고, 어떤 도면을 쓸지와 차이가 실제 오류인지는 기술자가 정합니다. 손글씨 주기나 배치 오류는 지금 AI가 모두 잡지 못하기 때문에 이 경계가 필요합니다.

언제 쓰고 언제 안 쓰나. 잘못 고른 도면이 잘못된 부품 교체로 이어지는 정비 업무처럼 틀렸을 때 비용이 큰 곳에 씁니다.

원문의 예. 시스템이 내놓는 결과는 후보이고, 손글씨 주기와 배치 오류를 모두 잡지는 못하므로 최종 판단은 기술자가 합니다.

Forward Deployed Team: 현장에서 업무 흐름에 맞춰 만든다

무엇인가. Recursive는 BSA(Business Solution Architect, 업무 설계 담당)와 FDE(Forward Deployed Engineer, 고객 현장에 붙어 만드는 엔지니어)로 팀을 꾸려 개발했습니다.

어떻게 작동하나. 현장 담당자를 인터뷰하고, 실제 도면과 부품표로 결과를 검증하는 일을 되풀이하며 기능을 업무 흐름에 맞췄습니다. 그 결과를 후쿠오카 공장 시험으로 확인하고, 피드백을 받아 두 공장 도입으로 넓히는 순서입니다.

원문의 예. 현장 히어링과 실자료 검증을 거듭해 업무 흐름에 맞게 최적화했습니다.

저자가 든 사례

구켄공업: 과거 도면 찾기와 문서 대조를 AI 후보 제시로

구분	내용
상황	70년 넘게 쌓인 도면·기술 자료가 연대·형식·표기가 제각각. 납품 설비의 정비 도면 찾기에 수십 분~1시간, 때로 반나절. 사양 반영 확인은 사람이 문서를 견주어 봄. 자료 선택이 담당자 경험에 기댐
한 일	Recursive와 OpenAI API 기반 AI 지식 기반 시스템 공동 개발. 부품 번호·형번·치수를 뽑아 Knowledge DB 구축. 도면 검색(부품표 입력)과 도면 체크(문서 간 차이 후보) 웹 앱
결과	후쿠오카 공장 시험에서 도면 찾기 평균 4.5분. 2025년도 실적 기준 연간 도면 검색 공수 약 90% 감소 추정. 숙련자가 육성과 어려운 안건에 시간을 씀
연결	Structured Extraction, BOM-driven Matching, Diff as Candidates, Human-final Review, Forward Deployed Team 다섯 메커니즘이 한 업무에서 함께 돈 사례

기술 디테일: 도면 검색 AI를 실제로 돌리려면

아래는 원문에 없는 내용입니다. 같은 구조를 다른 제조사에서 만들 때 필요한 설정을 새로 정리했고, 값과 필드명은 가상 예시입니다.

Structured Extraction은 페이지 단위 JSON으로 받습니다. 도면 한 쪽을 이미지로 넣고, 비전 입력을 받는 모델에 JSON 스키마를 강제하는 구조화 출력을 씁니다. temperature는 0으로 둡니다. 읽지 못한 값은 추측하지 말고 null로 둡니다. 값마다 쪽 번호와 영역(bbox)을 받아 미리보기에서 그 자리를 강조합니다. 손글씨로 보이는 값에는 handwritten: true를 달아 검토 대상으로 돌립니다.

{
  "doc_id": "DWG-1987-0412",
  "doc_type": "외형도",
  "page": 3,
  "revision": "C",
  "parts": [
    {"part_no_raw": "KT2041/3", "part_no_norm": "KT-2041-03",
      "base_no": "KT-2041", "rev_no": "03",
      "bbox": [412, 880, 640, 905], "handwritten": false, "confidence": 0.91}
  ],
  "model_no": "CT-150",
  "dimensions": [{"name": "전고", "value": 3200, "unit": "mm", "bbox": [120, 300, 210, 320]}],
  "notes": ["방진 가대 별도"],
  "unreadable": ["parts[4].part_no_raw"]
}

BOM-driven Matching은 정규화 키와 유사도를 둘 다 씁니다. 추출한 번호에서 공백·하이픈·슬래시를 통일하고 대문자로 맞춘 뒤 기본 번호(base_no)와 개정·가지 번호(rev_no)로 나눠 저장합니다. 검색은 세 번 돌립니다. 정규화 번호가 같으면 1순위, base_no만 같으면 개정 후보, 그 밖에 편집 거리 2 이하이면 표기 흔들림 후보로 붙입니다. 후보마다 왜 나왔는지(match_type)를 화면에 적어 주면 기술자가 개정판을 실수로 고르는 일이 줄어듭니다. 부품표 쪽 번호도 같은 정규화를 거쳐야 합니다.

Diff as Candidates는 필드를 맞춘 뒤 규칙으로 비교합니다. 기준 문서와 대상 문서에서 같은 스키마로 형번·치수·주기를 뽑고, 같은 필드끼리 값을 비교합니다. 치수는 단위를 mm로 통일한 뒤 비교하고, 주기는 문장 유사도로 짝을 지은 다음 짝이 없는 주기를 누락 후보로 올립니다. 벌룬 누락은 추출된 부품 목록에 있는데 외형도 bbox에서 찾지 못한 번호로 판단합니다. 모델은 값을 뽑는 데만 쓰고, 같다·다르다의 판정은 코드로 하면 결과가 매번 같습니다.

정확도는 시험 기간에 따로 잽니다. 숙련자가 정답 도면을 확정한 부품표 100건 안팎을 골드셋으로 두고, 정답이 후보 상위 3개 안에 든 비율과 개정판을 정답으로 잘못 고른 비율을 봅니다. 도면 체크는 이미 알고 있는 불일치를 섞은 문서 묶음으로 놓친 비율과 헛경보 비율을 함께 셉니다.

실패하는 경우	대응
오래된 도면의 손글씨 주기·흐린 스캔	handwritten·confidence 0.7 미만은 검토 표시, 재스캔 대상 목록 관리
같은 부품이 개정을 거쳐 여러 번호로 존재	base_no로 묶어 개정 이력을 한 화면에 나란히 표시
부품표 번호와 도면 번호 체계가 다름	사내 번호 대응표를 DB에 넣고 정규화 전에 치환
도면 접근 권한이 부서·고객마다 다름	문서마다 권한 태그를 저장하고 검색 결과를 사용자 권한으로 거름

현업 실행 디테일: 누가, 언제, 무엇을

아래 역할·일정·판정 기준은 가상 예시입니다. 구켄공업이 밝힌 계획이 아니라 비슷한 업무에 옮길 때의 출발점으로 새로 작성했습니다.

역할	누가	맡는 일
업무 오너	설계 또는 서비스(정비) 부서 팀장	대상 설비·자료 범위와 판정 기준 결정
지식 오너	도면을 잘 찾는 숙련 기술자 1~2명	골드셋 정답 확정, 번호 체계·개정 규칙 설명
시험 사용자	한 공장의 설계·정비 담당 5~10명	실제 의뢰로 사용, 고른 도면과 걸린 시간 기록
정보보안	IT·보안 담당	도면 반출 범위, 권한 태그, API 사용 조건 확인
개발	사내 AX 팀 또는 FDE 파트너	추출·정규화·검색, 화면, 로그

시작 전에 모을 것. 대상 설비군의 디지털화된 도면 폴더와 문서 목록, 최근 1년 정비 의뢰 중 도면을 찾은 기록(부품표와 최종 사용 도면), 사내 부품 번호 규칙과 개정 표기 규칙, 지금 한 건 찾는 데 드는 시간을 2주 동안 재 둔 기준값입니다. 구켄공업이 전년도 실적으로 연간 감소율을 추정한 것처럼, 기준값이 있어야 효과를 말할 수 있습니다.

기간	할 일	산출물
1~2주	숙련자와 골드셋 100건 확정, 기준 시간 측정	골드셋, 기준 시간표
3~5주	대상 도면 추출·정규화·색인, 검색 화면	Knowledge DB v1, 검색 앱
6~9주	한 공장에서 실제 의뢰로 시험, 모든 검색을 로그로 남김	사용 로그, 실패 사례 목록
10주	판정 회의, 확대 여부와 도면 체크 착수 결정	판정 보고, 확대 계획

숙련자에게 물을 것. 도면을 찾을 때 가장 먼저 보는 번호는 무엇인가? 개정판 중 어느 것을 써야 하는지 어떻게 아는가? 번호 없이 찾을 때는 무엇을 단서로 쓰는가? 찾고 나서 맞는지 무엇으로 확인하는가?

진행 판정 기준(예시). 골드셋에서 정답이 상위 3개 후보 안에 드는 비율 90% 이상, 한 건 찾는 중앙값 시간이 기준값의 30% 이하, 개정판을 잘못 고른 사례 0건, 시험 사용자 과반이 계속 쓰겠다고 답할 것. 하나라도 못 미치면 원인 필드를 고쳐 2주 더 시험합니다.

어디에 먼저 쓸까. 설치 기반이 길고 정비 매출이 큰 설비 제조사라면 신규 설계보다 납품 설비의 도면 찾기가 첫 대상으로 좋습니다. 입력(부품표)과 정답(실제로 쓴 도면)이 이미 업무에 있어 효과를 재기 쉽고 숙련자 은퇴로 생기는 공백을 바로 메웁니다. 검색이 자리 잡으면 같은 Knowledge DB를 써서 도면 체크로 넓힌 뒤 그다음 견적이나 부품 재고 같은 주변 업무로 잇는 순서를 권합니다.

원문 사례

항목	내용
회사	구켄공업(空研工業, 후쿠오카), 공조 기기·냉각탑 설계·제조, 70년 넘는 이력
파트너	Recursive(도쿄 시부야), OpenAI Advanced Partner, BSA·FDE로 꾸린 Forward Deployed Team
발표·보도	2026년 11월 4일 두 회사 발표, MONOist 2026년 11월 6일 보도, OpenAI 고객 사례 2026년 11월 9일 게재
기술 기반	OpenAI API, 웹 앱. 사용 모델명은 기사에 없음
도면 검색	부품표 업로드 → 부품 번호 추출 → 과거 도면 페이지 검색. 완전 일치와 개정·가지 번호·유사 문자열 후보, 미리보기
도면 체크	공장 仕切 통지서 기준으로 외형도·납입 사양서의 형번·치수·주기 대조, 차이 후보 제시. 필수 주기·벌룬 누락 확인
결과	후쿠오카 공장 시험에서 도면 찾기 평균 4.5분(이전 수십 분~1시간, 때로 반나절). 2025년도 실적 기준 연간 검색 공수 약 90% 감소 추정
남은 과제	오래된 도면·손글씨 주기 판독 정확도, 데이터 정비, 보안·접근 권한 운용 검증
계획	2026년 안에 후쿠오카·지바 공장 본격 도입
공개되지 않은 것	도면 총수, 사용 모델, 비용

핵심 개념

냉각탑

공조 설비에서 데운 냉각수를 바깥 공기로 식혀 다시 돌려보내는 장치. 상업 시설, 병원, 공장에 들어갑니다.

부품표(BOM)

설비를 이루는 부품과 번호, 수량을 적은 목록. 이 시스템에서는 도면 검색의 입력입니다.

개정 가지 번호

같은 도면·부품을 고칠 때 원래 번호 뒤에 붙이는 추가 번호. 비슷한 번호의 도면이 여러 장 생기는 원인입니다.

외형도

설비의 바깥 치수와 설치에 필요한 정보를 그린 도면.

납입 사양서

고객에게 납품하는 설비의 사양을 정리한 문서.

벌룬

도면에서 부품을 가리키며 번호를 적어 두는 원형 표시. 빠지면 어느 부품인지 도면만으로 알기 어렵습니다.

OpenAI Advanced Partner

OpenAI 협력사 지위. 원문은 Recursive를 이 지위의 회사로 소개합니다.

내 메모

TODO: 내 생각 추가

원문은 MONOist의 「AIで過去図面を検索、資料探索を平均4.5分に短縮し年間工数90％削減へ」(2026.11.6)입니다. 사실관계는 두 회사 발표를 옮긴 VOIX 기사(2026.11.4)와 대조했습니다. OpenAI 고객 사례(openai.com/index/kuken, 2026.11.9)는 열리지 않아 게재 사실만 2차 보도로 확인했습니다. 요약, 핵심 메커니즘의 원문 예, 사례, 원문 사례 표는 보도 내용을 AX Review가 다시 정리했습니다. 메커니즘 이름과 작은 예시, 기술·현업 실행 디테일, JSON 예시, 실패 대응 표, 일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했으며 부품 번호와 수치는 가상 예시입니다. 냉각탑·벌룬의 풀이는 일반적인 뜻으로 덧붙였습니다. 원문 전체와 화면 이미지는 MONOist 기사에서 볼 수 있습니다.