도면에서 데이터까지: 오늘 하루 AI와 함께 정리한 현장 자동화 제품의 방향
오늘 대화의 출발점은 결국 ‘현장의 정보가 어디에서 시작되는가’였습니다
오늘 AI와 나눈 대화를 다시 훑어보면 주제가 상당히 넓어 보입니다. 자동용접기 데이터 전산화, 도면에서 정보를 추출하는 방식, 회사 이름과 브랜드, PRD와 사업계획서, 현장 문구 해석, AI를 이용한 시각화와 포스터 제작까지 서로 다른 이야기가 이어졌습니다.
그런데 하나씩 연결해보니 중심은 의외로 명확했습니다.
현장에서 발생하는 정보를 디지털 데이터로 바꾸고, 그 데이터를 다음 작업의 판단과 실행까지 연결하는 것.
오늘 이야기의 대부분은 이 한 문장으로 정리됩니다.
현장에서는 이미 수많은 데이터가 발생합니다. 도면이 있고, 용접 조건이 있고, 작업자 정보가 있고, 검사 결과가 있고, 자재 정보가 있고, 작업일보가 있습니다. 문제는 데이터가 없는 것이 아니라 각각의 정보가 서로 다른 문서, 장비, 사람, 엑셀, 종이 기록 안에 흩어져 있다는 점입니다.
그래서 오늘 대화는 자연스럽게 “AI를 어디에 붙일 것인가?”보다 더 근본적인 질문으로 이동했습니다.
어떤 정보를 기준 데이터로 삼고, 무엇부터 연결해야 실제 현장에서 가치가 생기는가?
1. 자동용접 장비를 보면서 다시 확인한 문제: 장비는 디지털인데 결과는 여전히 아날로그입니다
오늘 먼저 살펴본 것은 Polysoude와 AXXAIR 같은 자동용접 장비였습니다.
자동용접기는 이미 상당히 디지털화된 장비입니다. 작업자는 컨트롤러와 터치 인터페이스를 통해 용접 조건을 입력하고, 장비는 전류, 회전, 시간, 프로그램 번호 등 다양한 조건을 기준으로 용접을 수행합니다.
그런데 실제 현장에서 문제는 그다음부터 시작됩니다.
장비 안에서는 데이터가 만들어졌지만 결과가 종이로 출력되거나, 개별 장비 내부에 남아 있거나, 다른 품질 시스템과 연결되지 않는 경우가 많습니다. 즉, 자동용접 장비는 자동화되어 있지만 전체 품질관리 프로세스는 자동화되어 있지 않은 상태가 발생합니다.
예를 들어 하나의 용접 포인트를 생각해볼 수 있습니다.
도면에는 Joint 번호가 있습니다. 작업 전에는 용접사 또는 장비가 배정됩니다. 작업 시에는 용접 프로그램과 조건이 적용됩니다. 용접 후에는 결과 데이터가 발생합니다. 이후에는 검사 결과와 WIR 같은 품질 문서가 연결됩니다.
이 정보가 각각 분리되어 있으면 관리자는 여러 시스템을 다시 확인해야 합니다.
반대로 아래처럼 연결된다면 이야기가 달라집니다.
Drawing → Joint → Welder/Machine → Welding Parameter → Result → Inspection → WIR
이 구조가 만들어지면 장비 데이터는 단순히 ‘용접기에서 나온 기록’이 아니라 특정 Joint의 품질 이력이 됩니다.
그리고 여기서 AI가 할 수 있는 일도 훨씬 명확해집니다. AI가 용접을 대신하는 것이 아니라, 누락된 데이터 확인, 이상 조건 탐지, 검사 우선순위 선정, 작업 기록 정리, 문서 자동 생성 같은 업무를 수행할 수 있습니다.
즉, 오늘 자동용접기를 보면서 다시 확인한 것은 AI보다 먼저 데이터 연결 구조가 필요하다는 사실이었습니다.
2. ‘Drawing to Start’라는 표현에서 시작된 브랜드 고민
오늘은 회사명과 서비스명을 고민하면서 Drawing to Start라는 표현이 자연스러운지에 대해서도 이야기했습니다.
의도는 분명했습니다.
“도면으로부터 정보를 취합하고, 모든 작업을 시작한다.”
하지만 영어 표현으로 그대로 사용했을 때 의미 전달이 완전히 직관적인지는 다시 생각할 필요가 있었습니다. 그 과정에서 중요한 아이디어가 하나 나왔습니다.
도면은 단순한 파일이 아니라 현장 데이터의 출발점이 될 수 있다는 것입니다.
배관 프로젝트를 기준으로 보면 도면 안에는 이미 상당한 정보가 있습니다.
- Line 또는 Spool 정보
- Pipe Size
- Fitting 구성
- Joint 위치
- Shop / Field 구분
- 제작 범위
- BOM과 연결할 수 있는 정보
- 현장 설치 위치와 작업 범위
이 데이터를 제대로 추출할 수 있다면 이후 자재관리, 제작관리, 용접관리, 품질관리, 공정관리가 하나의 흐름으로 이어질 수 있습니다.
그래서 D2X 같은 이름도 검토했습니다.
여기서 X는 단순히 특정 하나의 단어가 아니라 확장성을 의미할 수 있습니다.
Drawing to Data
Drawing to Execution
Drawing to Everything
이런 식으로 도면에서 출발한 정보를 여러 실행 영역으로 확장할 수 있습니다.
브랜드를 고민하는 과정 자체가 결국 제품 구조를 다시 정의하는 과정이 된 셈입니다.
3. 오늘 가장 중요한 변화: 기능 목록이 아니라 ‘Core Kill Product’를 고민하기 시작했습니다
오늘은 이미지 자료를 바탕으로 PRD와 사업계획서를 작성하고, 실제 출시 가능한 Core Kill Product를 만들어야 한다는 이야기도 했습니다.
개인적으로 오늘 대화에서 가장 중요한 부분이 바로 이것이라고 생각합니다.
현장 문제를 많이 알고 있다고 해서 좋은 제품이 자동으로 만들어지는 것은 아닙니다.
현장에는 해결하고 싶은 문제가 너무 많습니다.
도면 관리도 불편합니다. WIR도 불편합니다. 작업일보도 불편합니다. 자재관리도 불편합니다. 용접기 데이터도 흩어져 있습니다. 검사 기록도 따로 관리됩니다.
이 모든 것을 처음부터 하나의 거대한 시스템으로 만들려고 하면 제품은 쉽게 무거워집니다.
그래서 핵심은 하나의 질문입니다.
처음 출시할 제품이 현장에서 가장 강하게 제거해야 하는 고통은 무엇인가?
오늘 대화를 기준으로 보면 가장 강력한 후보는 ‘도면 기반 현장 데이터 연결’입니다.
도면을 업로드하면 필요한 정보를 추출하고, Joint와 자재, 작업, 검사 데이터를 연결할 수 있는 기본 구조를 만드는 것입니다.
초기 제품에서는 모든 기능을 넣을 필요가 없습니다.
예를 들어 첫 버전은 다음 정도로도 충분히 가치가 있을 수 있습니다.
- 도면 업로드
- Spool / Joint / Size / Fitting 정보 추출
- 작업 단위 생성
- 용접 또는 작업 상태 입력
- 관리자 실시간 현황 확인
- WIR 또는 작업일보용 데이터 자동 정리
이렇게 되면 제품은 단순한 ‘도면 OCR 프로그램’이 아니라 현장 실행 데이터의 시작점이 됩니다.
이 차이는 큽니다.
4. 결국 필요한 것은 기능이 아니라 하나의 데이터 모델입니다
오늘 여러 이야기를 하면서 계속 반복해서 등장한 것은 데이터 구조였습니다.
현장에서는 하나의 객체를 중심으로 여러 정보가 연결됩니다.
예를 들어 Joint를 중심 객체로 본다면 아래와 같은 구조를 생각할 수 있습니다.
중요한 것은 코드 자체가 아닙니다.
핵심은 drawingId, spoolId, jointNo, welderId, machineId, inspectionResult가 서로 관계를 가진다는 점입니다.
지금 현장에서는 이 정보가 도면, 작업일보, 장비 출력물, WIR, 엑셀 등에 각각 존재할 수 있습니다.
제품이 해야 할 일은 정보를 새로 만들어내는 것이 아니라 이미 존재하는 정보를 하나의 관계 구조로 연결하는 것입니다.
이 데이터 모델이 안정적으로 설계되면 이후 기능은 자연스럽게 확장할 수 있습니다.
자재 부족 예측도 가능하고, 작업 진행률도 계산할 수 있고, 검사 지연 구간도 찾을 수 있고, 특정 용접사의 작업 이력도 추적할 수 있습니다.
그리고 그 위에서 AI가 작동합니다.
AI는 데이터 구조가 없으면 매번 문서를 읽고 추론해야 하지만, 구조화된 데이터가 있으면 실제 업무 자동화 엔진으로 바뀔 수 있습니다.
5. 오늘 현장 문구 하나를 해석하면서 느낀 것: 작은 문장 하나가 작업 기준을 바꿀 수 있습니다
오늘 도면 또는 기준 문서에 표시된 괄호 안의 ‘현장 내’라는 표현이 어떤 의미인지도 확인했습니다.
이런 질문은 사소해 보이지만 실제 현장에서는 매우 중요합니다.
문서의 한 문장이 적용 범위를 바꿀 수 있고, 제작 Shop과 현장의 작업 범위를 나눌 수도 있습니다.
사람은 주변 문맥과 경험을 기준으로 해석할 수 있지만, 시스템이 자동으로 판단하려면 적용 범위가 데이터로 정의되어야 합니다.
예를 들어 다음과 같은 값이 필요할 수 있습니다.
scope = SHOP
scope = FIELD
scope = BOTH
그리고 도면 또는 기준서에 애매한 표현이 있다면 AI가 바로 결정하는 것이 아니라 사용자에게 근거 문장과 함께 확인을 요청하도록 설계할 수 있습니다.
이런 작은 기능이 실제 현장에서 신뢰도를 만듭니다.
AI 시스템에서 중요한 것은 무조건 답을 내는 것이 아니라, 확실한 데이터와 해석이 필요한 데이터를 구분하는 능력입니다.
6. 디자인과 로고를 고민한 이유도 결국 같은 문제였습니다
오늘은 회사 로고와 D2X 이미지도 만들었습니다.
기술 제품을 만들 때 개발자는 기능에 집중하기 쉽지만, 실제로 제품을 설명하고 판매하려면 이름과 시각적 정체성도 필요합니다.
특히 산업용 SaaS는 기능이 복잡하기 때문에 브랜드가 전달해야 하는 메시지가 더 중요합니다.
사용자가 제품 이름을 보고 “도면을 기반으로 뭔가를 연결하는 서비스구나”라는 느낌을 바로 받을 수 있어야 합니다.
좋은 브랜드는 예쁜 로고보다 먼저 제품이 무엇을 하는지 압축해서 전달하는 인터페이스에 가깝습니다.
오늘 D2X 같은 이름을 고민했던 이유도 그래서였습니다.
도면에서 데이터로, 데이터에서 실행으로 이어지는 흐름을 짧게 표현할 수 있다면 브랜드와 제품 구조가 같은 방향을 바라보게 됩니다.
7. AI와 협업하는 방식 자체도 제품 개발 프로세스가 되고 있습니다
오늘은 기술적인 질문만 한 것이 아닙니다.
이미지를 기반으로 PRD와 사업계획서를 만들고, 이름을 고민하고, 로고를 만들고, 현장 문장을 해석하고, 자동용접 시스템을 조사하고, 마지막에는 오늘의 대화 자체를 다시 블로그 글로 만드는 과정까지 이어졌습니다.
이 흐름을 보면 AI를 사용하는 방식도 점점 달라지고 있습니다.
과거에는 질문 하나를 하고 답변 하나를 받는 방식이었다면, 지금은 하나의 프로젝트를 중심으로 여러 역할을 AI에게 연결하고 있습니다.
- 기술 조사
- 현장 문제 분석
- 제품 기획
- PRD 작성
- 데이터 모델 설계
- 네이밍
- 디자인
- 문서화
- 콘텐츠 발행
결국 AI가 하나의 도구라기보다 여러 작업 사이의 연결 계층처럼 사용되고 있습니다.
하지만 여기에서도 중요한 것은 AI 자체가 아닙니다.
현장의 실제 문제와 데이터 구조가 먼저입니다.
AI는 그 위에서 속도를 높이고, 정보를 정리하고, 반복 작업을 줄이고, 새로운 관점을 제공하는 역할을 합니다.
8. 오늘 대화에서 정리된 제품 방향
오늘 하루의 대화를 제품 관점에서 다시 압축하면 다음 흐름으로 정리할 수 있습니다.
Step 1. Drawing을 기준 데이터의 시작점으로 설정
도면에서 Spool, Joint, Size, Fitting, 위치와 같은 핵심 정보를 추출합니다.
Step 2. 실제 현장 작업 데이터를 연결
작업자, 용접기, 용접 프로그램, 작업 시간, 작업 상태를 연결합니다.
Step 3. 품질 데이터를 연결
검사 결과, WIR, Repair 이력, 품질 문서를 Joint 단위로 연결합니다.
Step 4. 자재와 제작 데이터를 연결
BOM, 자재 입출고, 부족 자재, 제작 상태를 연결합니다.
Step 5. 관리자에게 실시간 실행 정보를 제공합니다
단순한 현황판이 아니라 다음 행동을 결정할 수 있는 정보를 제공합니다.
예를 들어 “오늘 완료된 Joint가 몇 개인가?”보다 더 중요한 질문은 다음과 같습니다.
“내일 작업을 진행하지 못하게 만드는 문제가 무엇인가?”
부족 자재인지, 미승인 도면인지, 검사 대기인지, 작업자 배정 문제인지 시스템이 알려줄 수 있어야 합니다.
여기까지 가면 단순한 관리 프로그램이 아니라 현장 의사결정 시스템에 가까워집니다.
결론: 결국 제품의 시작은 AI가 아니라 현장의 한 줄짜리 문제입니다
오늘은 여러 주제를 다뤘지만 방향은 하나였습니다.
자동용접 장비의 데이터를 웹으로 연결하고 싶다는 생각도, Drawing을 기준으로 정보를 추출하고 싶다는 생각도, 작업일보와 품질 문서를 통합하고 싶다는 생각도 결국 같은 문제에서 시작합니다.
현장에는 데이터가 있지만 서로 연결되어 있지 않습니다.
그리고 연결되지 않은 데이터는 사람이 계속 다시 확인하고, 다시 입력하고, 다시 전달해야 합니다.
그래서 내가 만들고 싶은 제품의 핵심은 점점 분명해지고 있습니다.
도면에서 시작된 정보를 실제 작업, 자재, 용접, 품질, 공정까지 연결하는 것.
그리고 AI는 그 데이터 위에서 판단과 자동화를 돕는 역할을 합니다.
오늘의 가장 큰 수확은 새로운 기능 아이디어 하나가 아닙니다.
오히려 ‘무엇부터 만들 것인가’에 대한 기준이 조금 더 명확해졌다는 점입니다.
모든 것을 한 번에 만드는 대신, 현장에서 가장 중요한 데이터 흐름 하나를 완전히 연결하는 것.
그것이 앞으로 만들어야 할 첫 번째 Core Kill Product의 시작점이라고 생각합니다.
