현장의 요구사항 61건부터 시작했다 — 제조업 IT 책임자가 AI 혁신을 '2트랙'으로 추진하는 이유

결론부터

• ‘AI를 도입한다’가 아니라 ‘현장의 불편함 100가지 모으기’부터 시작했다. AI로 해결할 수 있는 문제는 그중 일부에 불과했다.
• 모은 요구사항을 점수화하여 61건으로 압축하고,
  덴탈/메디컬의 2트랙을 병행시켰다. 한쪽이 조직 합의를 기다리며 멈춰도, 다른 쪽이 앞으로 나아갈 수 있었다. 첫 번째 ‘완료’는 화려한 AI가 아니라,
  BOM 전개 30분 → 1초와 발주 메일 자동 발송이었다. 신뢰는 여기서 쌓였다.

이 연재는 국내 치과 의료기기 제조업체(도쿄증권거래소 성장 기업 수준의 중견기업)에서, PowerBuilder 기반 ERP・벤더제 MES・Excel의 그림자 프로세스가 살아있는 ‘레거시 현장’에 Claude Code를 축으로 AI 및 자동화를 도입해 나간 실천 기록입니다. 저는 22년 차 제조업 IT 책임자이며, 개발팀은 저를 포함하여 3명 규모입니다. 이 정도 규모로 ERP・MES・AI 에이전트를 자체 개발하여 운영하고 있습니다.

참고로 본 기사에서는 공개된 방법론의 정의는 출처와 함께 ‘정의상으로는’, 저희가 실제로 진행한 것은 ‘실제로는’과 같이 구분하여 작성합니다. 출처는 마지막 ‘참고’에 정리했습니다.

배경 — 왜 ‘요구사항 수집’부터 시작했나

2026년 사업 계획에서 경영진으로부터 ‘전사 AI 도입’이 미션으로 내려왔습니다. 여기서 흔히 발생하는 실패 사례는, 먼저 툴(RAG, 챗봇, 예측 모델)을 결정하고 나중에 용도를 찾는 것입니다. 과거 사내에서 RPA를 검토했을 때도, 툴 선행으로 인해 중단된 경험이 있었습니다.

그래서 순서를 역전시켰습니다. 덴탈 및 메디컬 양 사업장의 생산/품질/구매/물류/생산기술/기술지원 각 부서와 현장 미팅을 진행하여, ‘매일 불편한 점’을 약 100가지 모았습니다. 수집된 내용을 해결 수단에 따라 5가지 축으로 분류했습니다.

| 項目 | 3点 | 2点 | 1点 |
|---|---|---|
| 効果 | 여러 부서의 작업이 사라짐 | 1개 부서의 작업이 절반 이하로 줄어듦 | 특정 사람이 편해짐 |
| ... |

트랙 분할에는 또 다른 효과가 있었습니다. 바로 동시 진행 건수의 상한선이 자연스럽게 정해진다는 것입니다. 3명이 2개 트랙을 맡는다면, 한쪽에서 동시에 처리할 수 있는 것은 많아봐야 몇 건입니다. 이를 초과하면 검토나 검증이 돌아가지 않게 됩니다. '몇 건까지 동시에 할지'를 정하지 않고 요청을 받으면, 착수된 것만 늘어나고 완료되는 것이 없는 상태가 됩니다.

첫 번째 '완료' 기준 설정하기

처음에 완료시킨 것은 메디컬 쪽의 2건이었습니다.

• 발주서 스마트 이메일 자동화 — 수작업으로 보내던 발주서를 자동으로 전송하고, 협력사가 이메일 링크를 클릭하면 ERP에 반영되는 기능 -
  초고속 BOM 전개 & ATP 엔진 — 긴급 주문이 있을 때마다 30분이 걸리던 BOM 전개를 1초로 단축. 생산 가능 대수가 실시간으로 확인됨

둘 다 AI는 아니었습니다. 하지만 '30분이 1초가 되었다'는 것은 현장의 누구에게나 와닿습니다.

RICE의 용어로 말하자면, 이 2건은 Reach도 Impact도 압도적으로 높지는 않았습니다. 높은 것은 **Confidence(예측에 대한 자신감)**였습니다. 둘 다 기존 인프라만으로 완결되며, 읽기 중심이고, 실패해도 업무가 멈추지 않는다는 점입니다. 첫 번째 건을 빼놓으면 다음 협력을 얻기 어렵습니다. 그래서 초반에는 기대값의 높이가 아니라 분산의 작음으로 선택했습니다. 이후 프로젝트에서 '저 팀이 만든다면'이라는 전제 하에 협력을 얻을 수 있었던 것이 바로 이 2건 덕분이었습니다. 화려함보다는, 측정 가능한 성과를 먼저 내는 것. 이것은 의도적으로 그렇게 선택한 것입니다.

해보니 알게 된 점

착수 건수는 급격히 늘어난다. 5월 기준으로 진행 중이던 4건이었던 것이 7월에는 12건(덴탈 8 / 메디컬 4)으로 늘었습니다. 첫 번째 완료가 신뢰가 되었고, 구매/재고의 축이 'D+1 분기' 예정보다 일찍 열렸습니다. 계획대로 진행된다기보다는, 신뢰가 쌓이는 순간 한 번에 폭발적으로 열린다는 전개 방식을 보입니다.

점수는 '재현되지 않는다'를 전제로 운영한다. 같은 요청을 시기를 바꿔 점수화하면 점수가 변합니다. RICE가 Confidence를 별도의 곱셈 항으로 가지고 있는 것은, 바로 이 불확실성을 수식 안에 넣기 위함이라는 것을 스스로 해보니 알게 되었습니다. 우리는 Confid

• Claude Code를 위한 '지침서' 설계 — 3명이 6개의 리포지토리를 운영하는 구조
• BOM(Bill of Materials) 전개 시간 30분 → 1초 — 첫 번째 '가시적인 성과'를 만드는 방법
• PowerBuilder ERP를 망가뜨리지 않고 연결하기 — 3DB 분리/멱등 API/부분 업데이트
• 67,500품목의 MIN/MAX를 매일 아침 계산하기 — ML(머신러닝) 이전에 실측 리드타임을 확보했던 이야기
• 전 자동화로 만들지 않기 — 자동 발주 OFF/섀도우 운영/승인 게이트 설계 사상
• B2B 수주 플랫폼, 인증서 무인 발급 챗봇, 소스 없는 MES/POP 화면 단일 위치 이동
• Obsidian×Claude Code를 활용하여 사내 LLM Wiki를 매일 자동 운영하기 (이 연재 자체가 여기서 생성되었습니다)

그 후에는 진행 중인 프로젝트 보고와 1년 치 실측 수치 공개가 이어집니다. 잘되지 않았던 일, 포기했던 것도 그대로 적을 것입니다.

다음 편에서는 이 61건의 과제를 3명이 운영하기 위해 만든 **Claude Code를 위한 '지침서'**에 대한 이야기를 다룹니다. 6개의 리포지토리에서 공통적으로 사용하고 있는 CLAUDE.md

／ .planning

／ .serena

의 3층 구조를 실제 사례와 함께 설명하겠습니다.

본 연재의 설계 판단, 템플릿, 체크리스트를 모은 유료 북 'Claude Code 실무 운영 가이드 — 레거시 현장 편'을 준비 중입니다. 요구사항 양식과 기준표 실물을 수록할 예정입니다.

참고

Discussion