Human-in-the-loop 견적: 닛토공업, 도면에서 분전반 견적 정보를 뽑고 영업이 고친 결과를 지식으로 쌓다
닛토공업이 일본IBM과 1년 반 동안 만든 생성형 AI 앱으로 설비 도면에서 분전반 견적용 회로·기기·특기사항을 뽑고, 영업이 고친 결과를 구조화 데이터로 쌓습니다. 2026년 10월부터 23개 거점 약 50명에게 단계 적용합니다. 출력 스키마, 수정 로그, 12주 파일럿안을 붙였습니다.
닛토공업은 영업 담당이 도면을 읽고 분전반 견적 정보를 뽑던 일을, 생성형 AI가 먼저 뽑고 영업이 확인해 고치는 방식으로 바꿨습니다. 2026년 10월부터 전국 23개 영업 거점의 약 50명에게 단계적으로 적용합니다. 이 사례에서 가져올 것은 모델보다 설계입니다. 사람이 고친 결과를 구조화 데이터로 남겨, 몇 사람 머릿속에 있던 견적 노하우를 조직의 지식으로 바꾸는 방식입니다.
요약
배전·제어 설비를 만드는 일본 제조사 닛토공업(日東工業)이 일본IBM의 지원을 받아 견적용 생성형 AI 앱을 개발했습니다. 이 앱은 설비 도면에서 분전반(차단기를 모아 건물 각 회로로 전기를 나누는 함) 견적에 필요한 정보를 뽑아냅니다. 영업 담당이 건축·설비 도면을 웹 앱에 올리면 멀티모달 생성형 AI(그림과 글자를 함께 읽는 모델)가 회로 정보, 기기 정보, 특기사항을 뽑아 정리합니다. 영업 담당은 자기 업무 지식으로 그 결과를 확인하고 틀린 곳을 고칩니다. AI가 낸 결과와 사람이 고친 내용은 함께 구조화 데이터로 저장돼 지식 베이스로 쌓입니다.
이렇게 바꾼 이유는 견적 업무가 사람에게 묶여 있었기 때문입니다. 도면 형식은 안건마다 다릅니다. 그 도면을 보고 적용할 규정, 제품 사양, 필요한 기기, 회로 구성을 판단하려면 깊은 업무 지식과 경험이 있어야 했습니다. 그래서 견적이 특정 담당자에게 기댔고, 의뢰가 많을 때 속도와 품질을 함께 지키기 어려웠습니다. 건설·설비 업계의 인력 부족과 기능 전승 문제도 배경에 있습니다. 두 회사는 약 1년 반 동안 견적 노하우를 정리하고 업무 지식을 구조화했습니다. 사람과 AI의 역할을 나누고 운영 체제를 갖추는 일도 함께 했습니다. 정확도나 시간 절감 같은 효과 수치는 아직 공개하지 않았습니다. 앞으로는 현장 피드백으로 도면 판독 정확도와 사용성을 높이고, 다룰 수 있는 도면의 종류와 범위를 넓힐 계획입니다. 설계·생산·보수 업무에 쓰는 방안도 검토합니다. 아래에서는 이 구조를 이루는 다섯 가지 메커니즘을 풀고, 우리 회사에서 돌릴 때 필요한 기술·현업 디테일을 붙입니다.
핵심 메커니즘
Multimodal Drawing Extraction: 도면에서 견적 항목을 뽑는 판독
무엇인가. 도면 이미지를 읽어 견적에 바로 쓸 항목으로 바꾸는 단계입니다. 닛토공업의 앱은 회로 정보, 기기 정보, 특기사항 세 묶음을 뽑습니다.
어떻게 작동하나. 도면에는 단선 결선도 같은 그림, 표, 손으로 쓴 메모, 범례가 섞여 있습니다. 글자만 읽는 OCR로는 어느 차단기가 어느 회로에 붙어 있는지 알기 어렵습니다. 그래서 그림의 연결 관계와 글자를 함께 해석하는 멀티모달 모델이 필요합니다. 출력은 사람이 다시 옮겨 적을 필요 없게 견적 항목 단위로 나옵니다.
언제 쓰고 언제 안 쓰나. 입력 형식이 제각각이고 판단에 해석이 들어가는 문서에 맞습니다. 이미 CAD 데이터나 정형 사양서로 들어오는 안건이라면 모델보다 파서가 싸고 정확합니다.
원문의 예. 안건마다 형식이 다른 건축·설비 도면에서 분전반 견적용 회로, 기기, 특기사항을 뽑습니다.
작은 예시(가상). 상가 도면 한 장에서 “분기 회로 12개, 누전차단기 4개, 옥외 설치”를 뽑아 견적 화면의 칸을 채웁니다.
Human-in-the-loop Review: AI가 정리하고 영업이 확정한다
무엇인가. AI의 출력을 그대로 견적으로 쓰지 않고, 영업 담당이 확인해 고친 뒤 확정하는 단계입니다.
어떻게 작동하나. AI는 도면을 읽고 정보를 정리하는 데까지 맡습니다. 영업 담당은 업무 지식으로 결과를 검토하고 필요하면 고칩니다. 견적의 책임은 사람에게 남고, AI는 처음부터 도면을 읽는 시간을 줄여 줍니다. 사람의 역할은 입력하는 사람에서 검토하는 사람으로 바뀝니다.
언제 쓰고 언제 안 쓰나. 틀렸을 때 비용이 큰 업무(가격, 규정 적합성)에 씁니다. 틀려도 곧 고칠 수 있는 내부 메모라면 검토 단계를 가볍게 해도 됩니다.
원문의 예. 영업 담당이 AI의 추출 결과를 업무 지식으로 확인하고 수정해, 견적을 효율화하고 품질을 높입니다.
Correction as Data: 수정 내역을 구조화 데이터로 쌓는 지식 베이스
무엇인가. 영업이 고친 결과만 남기지 않고, AI가 처음 낸 값과 고친 값을 함께 구조화 데이터로 쌓는 방식입니다.
어떻게 작동하나. 견적 한 건이 끝날 때마다 AI 결과와 사람의 수정이 짝으로 저장됩니다. 쌓인 짝은 어떤 도면에서 AI가 자주 틀리는지, 숙련자는 그 자리를 어떻게 판단하는지를 보여 줍니다. 닛토공업은 이렇게 개인에게 묶여 있던 견적 노하우를 조직 전체가 쓰고 물려줄 수 있게 하려 합니다.
언제 쓰고 언제 안 쓰나. 숙련자의 판단이 문서로 남아 있지 않은 업무에서 가장 값이 큽니다. 수정이 거의 없는 업무라면 쌓이는 지식도 적습니다.
작은 예시(가상). AI가 정격 전류를 30A로 읽었고 영업이 20A로 고쳤다면, 도면 유형, 해당 칸, 두 값, 수정 이유가 레코드 한 줄로 남습니다.
Model-agnostic Agent Framework: 모델을 바꿔도 앱이 남는 구조
무엇인가. 견적 앱과 업무 흐름을 특정 AI 모델이나 시스템 환경에 묶지 않는 설계입니다.
어떻게 작동하나. 앱은 일본IBM의 통합 AI 기반(전사 AI 플랫폼) 레퍼런스 아키텍처 위에 올렸습니다. 일본IBM이 자사 업무에 AI를 먼저 적용해 얻은 Client Zero 경험과, IBM Consulting Advantage로 정리한 생성형 AI 방법론을 담은 AI 에이전트 프레임워크를 씁니다. 모델을 부르는 부분과 업무 흐름을 나눠 두었기 때문에 기술이 바뀌거나 업무 요건이 달라져도 앱 전체를 다시 만들지 않아도 됩니다.
언제 쓰고 언제 안 쓰나. 몇 년 쓸 업무 시스템이라면 처음부터 이렇게 나눠야 합니다. 몇 주짜리 시험이라면 모델 하나에 바로 붙여도 됩니다.
원문의 예. 두 회사는 이 앱과 별도로 AI 거버넌스, AI 보안, AI 아키텍처를 포함한 전사 AI 기반도 검토하고 있습니다.
AI Operating Model: 업무와 역할을 함께 바꾸는 틀
무엇인가. 일본IBM이 내세우는 개념으로, AI 활용을 전제로 업무 프로세스와 역할을 다시 설계해 가치를 계속 만들어 내는 운영 방식입니다. 이번 프로젝트는 그 개념을 실제로 구현한 사례로 소개됐습니다.
어떻게 작동하나. 앱만 만들지 않고, 견적 노하우 정리, 업무 지식 구조화, 사람과 AI의 역할 분담, 운영 체제 정비를 같은 기간에 진행했습니다. 출시 뒤에는 현장 피드백을 받아 판독 정확도와 사용성을 높이고, 범위를 넓혀 갑니다.
원문의 예. 닛토공업은 이번에 얻은 지식을 전사로 넓히고, 설계·생산·보수 같은 주변 업무에도 쓰는 방안을 검토합니다.
통념과 다른 주장
흔히 이렇게 봅니다도면 판독 AI는 정확도가 충분히 오르면 사람 없이 견적을 낼 수 있고, 그래서 모델 성능이 성패를 가른다.
이 사례는 이렇게 봅니다사람이 확인하고 고치는 단계를 처음부터 설계에 넣고, 그 수정을 조직의 지식으로 쌓습니다. 모델은 바꿀 수 있게 두고, 오래 남는 자산은 노하우와 수정 데이터로 봅니다.
근거두 회사는 약 1년 반을 견적 노하우 정리, 업무 지식 구조화, 역할 분담, 운영 체제 정비에 썼습니다. 앱은 특정 모델에 묶이지 않게 설계됐고, AI 결과와 영업의 수정이 함께 구조화 데이터로 저장됩니다.
저자가 든 사례
닛토공업: 설비 도면에서 분전반 견적 정보 추출
| 구분 | 내용 |
|---|---|
| 상황 | 안건마다 형식이 다른 도면을 보고 규정, 제품 사양, 기기, 회로 구성을 판단해야 해서 견적이 숙련자에게 기댐. 많은 의뢰를 빠르고 정확하게 처리하기 어려움. 업계의 인력 부족과 기능 전승 문제 |
| 한 일 | 일본IBM 지원으로 멀티모달 생성형 AI 앱 개발. 도면에서 회로·기기·특기사항을 뽑고 영업이 확인·수정. AI 결과와 수정을 구조화 데이터로 쌓아 지식 베이스 구축. 약 1.5년 공동 작업 |
| 결과 | 전국 23개 영업 거점, 약 50명이 쓸 수 있는 환경 마련. 2026년 10월부터 단계적으로 실무 적용. 효과 수치는 원문에서 밝히지 않음 |
| 연결 | Multimodal Drawing Extraction, Human-in-the-loop Review, Correction as Data, Model-agnostic Agent Framework, AI Operating Model 다섯 메커니즘이 한 업무 안에서 함께 돈 사례 |
기술 디테일: 도면 견적 AI를 실제로 돌리려면
아래는 원문에 없는 내용으로, 같은 구조를 우리 회사 업무에 만들 때 필요한 설정을 새로 정리한 것입니다.
Multimodal Drawing Extraction을 돌리려면 출력 스키마부터 고정합니다. 회로·기기·특기사항을 자유 서술로 받으면 검토도 저장도 어렵습니다. 필드마다 타입과 단위를 정하고, 읽지 못한 값은 지어내지 말고 null로 두게 합니다. 값마다 도면 몇 쪽의 어느 영역에서 읽었는지(bbox)를 함께 받아야 검토 화면에서 바로 원본을 대조할 수 있습니다.
{
"drawing_id": "PRJ-0427-E03",
"drawing_type": "단선결선도",
"panel": {"name": "1F-L1", "main_breaker": {"type": "ELCB", "poles": 3, "rated_a": 100}},
"circuits": [
{"no": 1, "load": "조명 1F 동측", "breaker": "MCCB", "poles": 2, "rated_a": 20,
"evidence": {"page": 2, "bbox": [412, 880, 640, 905]}, "confidence": 0.93}
],
"equipment": [{"item": "계량기 박스", "qty": 1, "evidence": {"page": 1, "bbox": [90, 120, 300, 160]}}],
"special_notes": [{"text": "옥외 설치, 방수형 함 지정", "source": "도면 비고란"}],
"unreadable": ["circuits[7].rated_a"]
}고해상도 도면은 나눠서 읽힙니다. A1·A0 도면을 한 장 이미지로 줄이면 작은 글자가 뭉개집니다. 범례와 기호표를 먼저 읽힌 다음, 도면을 겹치게 타일로 잘라 영역별로 추출하고 합칩니다. 회로가 여러 장에 걸치면 도면 번호와 회로 번호로 이어 붙입니다.
Human-in-the-loop Review가 빨라지려면 볼 곳만 띄웁니다. temperature는 0으로 두고 같은 도면을 두 번 추출해 값이 갈린 필드, confidence가 0.8 미만인 필드, 규칙 검사(분기 회로 정격 합계와 주차단기 정격의 관계 같은 사내 기준)에 걸린 필드만 노란색으로 표시합니다. 영업은 전체가 아니라 표시된 칸부터 확인합니다.
Correction as Data를 쌓으려면 수정을 diff 레코드로 남깁니다. 최종 견적만 저장하면 무엇을 왜 고쳤는지가 사라집니다. 필드 단위로 AI 값과 사람 값을 함께 남기고, 수정 이유는 자유 서술 대신 코드로 고르게 합니다.
{
"drawing_id": "PRJ-0427-E03", "field": "circuits[1].rated_a",
"ai_value": 30, "human_value": 20,
"reason_code": "MISREAD_SYMBOL",
"drawing_type": "단선결선도", "designer_office": "A설계",
"editor_role": "영업", "edited_at": "2026-11-04T10:12:00+09:00"
}reason_code는 처음에 다섯 개 안팎(MISREAD_SYMBOL, MISSING_PAGE, RULE_APPLIED, CUSTOMER_SPEC, OTHER)으로 시작합니다. OTHER가 20%를 넘으면 코드를 다시 나눕니다.
쌓인 수정은 세 곳에 씁니다. 첫째, 같은 설계사무소·도면 유형의 과거 수정 사례 3~5건을 검색해 프롬프트에 예시로 넣습니다. 둘째, 수정이 끝난 도면을 평가용 골드셋에 더합니다. 셋째, 같은 이유의 수정이 열 번 넘게 반복되면 규칙 검사로 올립니다.
Model-agnostic 구조를 지키려면 모델 교체 절차를 정해 둡니다. 앱은 추출 결과 스키마만 알고, 어느 모델을 부르는지는 어댑터 하나에 모읍니다. 새 모델을 넣기 전에는 골드셋 200건으로 필드별 정확도를 재고, 기존 모델보다 낮은 필드가 하나라도 있으면 그 필드는 기존 모델을 유지합니다.
| 실패하는 경우 | 대응 |
|---|---|
| 스캔 상태가 나쁘거나 손글씨 수정이 겹친 도면 | 해상도 기준(예: 300dpi) 미달이면 재요청 안내, 손글씨 영역은 무조건 검토 표시 |
| 설계사무소마다 기호·범례가 다름 | 범례를 먼저 추출해 기호 사전을 도면별로 만들고 그 사전으로 해석 |
| 특기사항이 도면이 아니라 별도 사양서에 있음 | 사양서도 함께 업로드받고, 출처 필드에 문서명을 남김 |
| 회로가 여러 장에 걸침 | 도면 번호·회로 번호로 연결, 이어지지 않으면 MISSING_PAGE로 표시 |
현업 실행 디테일: 누가, 언제, 무엇을
아래 일정과 기준은 가상 예시입니다. 닛토공업이 밝힌 계획이 아니라, 비슷한 업무에 적용할 때의 출발점으로 새로 작성했습니다.
| 역할 | 누가 | 맡는 일 |
|---|---|---|
| 업무 오너 | 영업기획 또는 견적 담당 팀장 | 범위·판정 기준 결정, 거점 확대 승인 |
| 지식 오너 | 견적 숙련자 1~2명 | 골드셋 정답 확정, reason_code 정의, 규칙 승격 판단 |
| 검토자 | 파일럿 거점 영업 담당 | AI 결과 확인·수정, 불편 사항 기록 |
| 기술 검토 | 설계·기술 부서 담당 | 규정·사양 판단이 갈리는 수정 확인 |
| AX·IT | 사내 AX 추진 또는 IT | 스키마, 검토 화면, 수정 로그, 모델 교체 절차 운영 |
시작 전에 모을 것. 최근 1년 안에 견적을 마친 도면 100~200건과 확정 견적, 도면 유형 목록(단선결선도, 평면 배치도, 사양서 등), 숙련자가 견적할 때 확인하는 항목 체크리스트, 지금 견적 한 건에 드는 평균 시간과 재견적 비율입니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~2주 | 골드셋 정리, 출력 스키마·reason_code 확정 | 골드셋, 스키마 v1 |
| 3~6주 | 2~3개 거점에서 실제 의뢰로 파일럿, 모든 수정을 로그로 남김 | 수정 로그, 거점별 사용 기록 |
| 7~10주 | 필드별 수정률 분석, 자주 틀리는 도면 유형 대응, 규칙 승격 | 개선 목록, 스키마 v2 |
| 11주~ | 판정 기준을 넘으면 거점 단위로 확대 | 확대 계획, 월간 품질 보고 |
파일럿 중에 물을 것.
- AI 결과를 보고 처음부터 다시 읽은 도면은 몇 건이었고, 왜 그랬나요?
- 고친 칸 가운데 경험이 없으면 놓쳤을 것은 무엇이었나요?
- 검토 화면에서 원본 도면 위치를 찾는 데 시간이 걸린 적이 있나요?
- 고객이나 설계사무소에 다시 확인해야 했던 항목은 무엇이었나요?
진행 판정 기준(예시). 핵심 필드(회로 수, 차단기 종류·정격, 특기사항)의 수정률이 파일럿 마지막 2주 동안 15% 아래로 내려오고, 견적 회신 시간이 기존보다 줄었으며, 재견적 비율이 늘지 않았을 때 다음 거점으로 넓힙니다. 기준은 파일럿 전에 정해 둡니다.
AX에 옮길 때. 이 구조는 전기 설비 견적에만 해당하지 않습니다. 도면이나 사양서를 읽고 사람이 판단해 견적·수주를 내는 B2B 제조 영업(제어반, 공조, 배관, 맞춤 부품)에 그대로 옮길 수 있습니다. 첫 적용처는 숙련자 몇 명에게 의뢰가 몰려 대기가 생기는 업무로 고르는 편이 좋습니다. 효과는 처리 시간만 보지 말고 쌓인 수정 레코드 수와 규칙으로 올라간 판단 수로도 재야 합니다. 그 숫자가 회사에 남은 노하우의 양입니다. 스폰서는 영업 조직장이 맡고, 데이터 준비도는 지난 견적과 도면이 안건 번호로 묶여 있는지로 판단합니다. 견적에서 수정 데이터가 쌓이면 닛토공업이 검토하는 것처럼 설계·생산·보수 쪽으로 넓힐 근거가 생깁니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 회사 | 닛토공업(日東工業), 지원 일본IBM |
| 발표 | 2026년 10월 20일 발표, MONOist 2026년 10월 22일 보도 |
| 대상 업무 | 설비 도면을 보고 분전반 견적에 필요한 정보 판단 |
| 입력 | 웹 앱에 올린 건축·설비 도면 (안건마다 형식이 다름) |
| 추출 항목 | 회로 정보, 기기 정보, 특기사항 |
| 사람의 역할 | 영업 담당이 업무 지식으로 확인·수정 |
| 지식화 | AI 결과와 수정 내용을 구조화 데이터로 저장해 지식 베이스 구축 |
| 기술 기반 | 일본IBM 통합 AI 기반 레퍼런스 아키텍처, Client Zero 경험, IBM Consulting Advantage, AI 에이전트 프레임워크, 특정 모델·환경에 묶이지 않는 설계 |
| 규모·일정 | 전국 23개 영업 거점, 약 50명. 2026년 10월부터 단계적 실무 적용. 공동 작업 약 1.5년 |
| 이후 계획 | 판독 정확도·사용성 개선, 대응 도면 종류·범위 확대, 설계·생산·보수 적용 검토, 전사 확대, 전사 AI 기반(거버넌스·보안·아키텍처) 검토 |
핵심 개념
- 분전반
- 주차단기와 분기 차단기를 한 함에 모아 건물의 각 회로로 전기를 나누는 설비. 회로 수와 차단기 사양에 따라 견적이 달라집니다.
- 특기사항
- 도면 비고란 등에 적힌 별도 조건. 설치 장소, 지정 사양처럼 표준 견적에서 벗어나는 요구를 담습니다.
- 통합 AI 기반
- 일본IBM이 제시하는 전사 AI 플랫폼의 레퍼런스 아키텍처. 개별 앱이 같은 기반 위에 올라가게 합니다.
- Client Zero
- IBM이 자사 업무에 먼저 AI를 적용해 보고 그 경험을 고객 프로젝트에 옮기는 방식.
- IBM Consulting Advantage
- IBM 컨설팅이 생성형 AI 활용 방법과 도구를 체계화해 둔 플랫폼.
- 골드셋
- 정답이 확정된 평가용 사례 묶음. 모델을 바꾸거나 프롬프트를 고칠 때 성능이 떨어지지 않았는지 재는 기준입니다.
내 메모
TODO: 내 생각 추가
원문은 MONOist의 「設備図面から見積情報を抽出するAI活用アプリを開発 2026年10月から実業務に適用」(2026.10.22)입니다. 사실관계는 일본IBM의 보도자료(PR TIMES, 2026.10.20)와 대조했습니다. 요약, 핵심 메커니즘의 원문 예, 사례, 원문 사례 표는 기사 내용을 AX Review가 다시 정리했습니다. 메커니즘 이름과 작은 예시, 기술·현업 실행 디테일, JSON 예시, 실패 대응 표, 일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했으며 숫자는 가상 예시입니다. 원문 전체와 앱 화면 이미지는 MONOist 기사에서 볼 수 있습니다.