제조업 AX 인사이트

글로벌 제조 솔루션 기업들이 신흥 시장으로 진출하며 AI와 디지털트윈 기술 표준을 선점하고 있습니다. 해외 거점 공장을 운영하는 제조기업은 현지 산학협력과 맞춤형 인프라 연계 전략을 시급히 마련해야 합니다. 왜 지금 이슈인가? 국내 시장의 성장 한계를 극복하고 중앙아시아 등 신흥 시장의 디지털 전환(DX) 수요를 선점하기 위한 글로벌 진출 경쟁이 본격화되었습니다. 특히 해외 거점 대학과의 협력을 통해 현지 맞춤형 기술 표준을 세우고 전문 인력을 미리 확보하는 전략이 중요해진 시점입니다. 핵심 내용 솔루션 기업들이 현지 대학과의 파트너십을 기반으로 중앙아시아 지역에서 AI와 디지털트윈 사업 영토를 넓히고 있습니다. 이는 단순한 소프트웨어 수출을 넘어, 현지 맞춤형 스마트팩토리 기술 확산과 현장 인력 양성 기반을 동시에 다지는 방식으로 전개됩니다. 무엇이 달라지는가? 이전에는 국내 중심으로 스마트솔루션을 도입하거나 개별 기업의 자체 역량에만 의존해 해외 공장을 관리했습니다. 이제는 현지 대학 및 파트너와의 산학협력 네트워크를 활용해, 글로벌 생산 거점마다 최적화된 AI와 디지털트윈 기술을 유연하게 적용할 수 있게 됩니다. 제조업에 미치는 영향 제조 솔루션 기업의 해외 영토 확장은 글로벌 제조 현장 전반에서 AI와 디지털트윈의 적용 범위가 넓어지고 있음을 방증합니다. 해외에 생산 법인이나 공장을 둔 제조기업은 앞으로 현지화된 기술 지원과 인프라 협력을 훨씬 수월하게 받을 수 있는 환경이 조성될 것으로 보입니다. 기업은 무엇을 준비해야 하는가? 해외 생산 거점 주변의 대학 및 연구기관과의 산학협력 가능성을 검토합니다. 현지 공장의 디지털 성숙도를 진단하고 맞춤형 AI 및 디지털트윈 도입 로드맵을 수립합니다. 글로벌 법인에서 현장 디지털 전환을 주도할 전문 인력의 현지 채용 및 육성 방안을 마련합니다. 현지 파트너십과 연계하여 외부 기술 지원과 인프라 협력을 조율할 전담 체계를 구축합니다. AX 관점의 시사점 제조기업은 단발성 솔루션 도입에서 벗어...

숙련공 부족과 생산성 정체에 직면한 중소 제조기업들이 외부 전문 기관과의 협업을 통해 인공지능 전환의 돌파구를 찾고 있습니다. 대학과 산단이 연계된 인프라를 활용하면 비용 부담을 낮추고 현장 맞춤형 AX를 효율적으로 추진할 수 있습니다. 왜 지금 이슈인가? 주요 제조 현장에서 숙련공 부족과 생산성 정체 문제가 심화되면서 외부 전문 기관과의 협업 필요성이 커졌기 때문이다. 대학의 연구 역량과 지역 산단의 현장을 연결하여 즉시 현장에 투입할 수 있는 AI 전환 솔루션이 요구되는 시점이다. 핵심 내용 대학과 지역 산업단지가 연계하여 제조 현장의 인공지능 전환을 주도하려는 움직임이 가속화되고 있다. 산단 중심의 제조AX 특화 인재 양성과 기술 지원 체계가 구축되는 추세다. 이는 단순한 이론 교육을 넘어 현장 맞춤형 AI 적용을 목표로 한다. 무엇이 달라지는가? 이전에는 개별 중소 제조기업이 막대한 비용과 전문 인력 부족으로 인해 AI 도입을 엄두도 내지 못하고 자체 해결에 의존했으나, 이제는 지역 대학 및 연구기관과의 산학 협력 생태계를 통해 산단 차원의 인프라와 전문 인력을 공동으로 활용하며 진입 장벽을 낮추게 된다. 제조업에 미치는 영향 개별 제조기업이 자체적으로 겪는 AI 도입 비용과 전문 인력 부족의 진입 장벽을 낮추는 계기가 된다. 산단 내 기업들은 대학의 인프라와 전문 인력을 활용해 공정 최적화와 품질 관리의 지능화를 추진할 수 있다. 기업은 무엇을 준비해야 하는가? 자사 공장의 주요 병목 공정과 데이터 현황을 진단하여 외부 지원이 필요한 영역을 정의합니다. 인근 대학이나 산단이 주관하는 제조AX 기술 지원 사업 및 국책 과제 공고를 상시 모니터링합니다. 현장 엔지니어의 AI 리터러시를 높이기 위한 실무 중심의 재교육 프로그램을 검토합니다. 대학 연구진과의 공동 기술 실증을 통해 비용 부담을 최소화하면서 소규모 파일럿 프로젝트를 기획합니다. AX 관점의 시사점 제조기업은 내부 역량만으로 AX를 추진하기보다 대학 및 연구기관과의 산학 협...

완성차 대기업을 중심으로 협력사와 부품사의 AI 전환을 지원하는 공급망 AX 전략이 본격화되고 있습니다. 제조 현장의 데이터 연계와 품질 관리 효율성 제고를 위해 부품사들은 실질적인 준비에 나서야 합니다. 왜 지금 이슈인가? 완성차 제조 공정의 복잡성이 증가하고 품질 관리 기준이 엄격해지면서, 대기업 단독의 혁신만으로는 공급망 리스크 대응에 한계가 왔기 때문입니다. 협력사의 기술 격차가 곧 완성차 기업의 경쟁력으로 직결되는 구조 속에서 상생형 AX의 필요성이 커졌으며, 이에 따라 업계 전반의 공급망 연계 디지털 전환 압박이 가중되고 있습니다. 핵심 내용 완성차 대기업을 중심으로 협력사와 부품사들의 인공지능(AI) 전환을 지원하는 공급망 AX 전략이 본격화되고 있습니다. 이는 개별 기업의 디지털 혁신을 넘어 공급망 생태계 전반의 역량을 끌어올리기 위한 조치로, 제조 현장의 데이터 연계와 공정 효율성 제고가 핵심 과제로 다뤄지고 있습니다. 무엇이 달라지는가? 이전에는 개별 부품사가 자체 예산과 인력 부족으로 독자적인 스마트팩토리 구축과 AI 도입에 큰 어려움을 겪었습니다. 하지만 이제는 완성차 대기업의 지원을 바탕으로 진입장벽이 낮아지고, 부품 품질의 균일화 및 생산 데이터 표준화가 공급망 단위로 추진됩니다. 제조업에 미치는 영향 부품 협력사들은 자체적인 예산과 전문 인력 부족 문제를 일부 해소하며 AI 도입 진입장벽을 낮출 수 있게 됩니다. 장기적으로는 부품 품질의 균일화, 납기 준수율 향상, 그리고 생산 데이터의 표준화가 가능해집니다. 다만, 대기업 주도의 표준을 수용하는 과정에서 초기 시스템 연동 비용이나 보안 가이드라인 준수 등 실무적 부담이 따를 수 있습니다. 기업은 무엇을 준비해야 하는가? 사내 공정 데이터를 표준화하여 상위 시스템과 연계할 수 있는 기반을 구축해야 합니다. 대기업의 보안 가이드라인과 연동 표준을 검토하고 이에 맞는 인프라를 정비해야 합니다. 현장 실무자가 AI 기반의 데이터 가시성 도구를 활용할 수 있도록 내부 역량을...

개별 공장 단위를 넘어 공급망 전체로 스마트팩토리와 AI 전환이 확산되고 있습니다. 중소·중견 제조기업은 수작업 중심의 공정을 벗어나 데이터 기반의 표준화된 관리 체계로 시급히 전환해야 합니다. 왜 지금 이슈인가? 개별 기업 단위의 디지털 전환을 넘어 공급망 전체의 유기적인 연동이 생존의 필수 조건이 되었기 때문입니다. 대기업의 주도하에 협력사까지 표준화된 스마트 제조 인프라를 구축하지 않으면 급변하는 납기 및 품질 요구를 맞추기 어려워졌습니다. 핵심 내용 완성차 및 대형 부품사를 중심으로 추진되던 스마트팩토리 전환이 1차 협력사를 넘어 생태계 전반으로 확장되는 추세입니다. AI와 로봇 기술을 제조 현장에 도입하여 품질을 고도화하고 생산 효율성을 높이는 움직임이 가속화되고 있습니다. 무엇이 달라지는가? 이전에는 개별 중소 협력사가 자체 역량에 의존해 부분적인 공정 자동화를 시도하거나 수작업으로 품질을 관리했으나, 이제는 대기업과 연동된 표준화된 AI와 로봇 인프라를 갖추고 공급망 전체의 데이터를 실시간으로 공유하는 체계로 바뀌고 있습니다. 제조업에 미치는 영향 중소·중견 협력사들은 수작업 의존도를 낮추고 데이터 기반의 공정 관리 체계로 전환해야 하는 압박을 받게 됩니다. 이 과정에서 공급망 전체의 데이터 가시성이 확보되어 불량률 감소와 원가 절감 효과가 나타날 것으로 보입니다. 기업은 무엇을 준비해야 하는가? 현장 공정의 수작업 데이터를 디지털로 전환할 수 있는 기초 센서와 로깅 인프라를 구축합니다. 대기업 발주처의 데이터 표준 요구사항을 분석하고 자사 공정 데이터 체계를 정렬합니다. 작업자의 숙련도 격차를 줄이고 AI 모델을 현장에 적용하기 위한 표준 작업 지침을 마련합니다. 단계별 스마트팩토리 고도화 로드맵을 수립하여 예산과 인력 투입 계획을 세웁니다. AX 관점의 시사점 제조기업은 단독 공장 자동화를 넘어 협력사와의 데이터 연동 및 AI 표준 모델 공유를 준비해야 합니다. AI와 로봇 도입 시 현장 작업자의 숙련도 격차를 줄이고, 표...

AI 에이전트와 MCP 기술이 도입되면서 제조 및 전장 부품의 개발과 테스트 프로세스 자동화가 빠르게 진행되고 있습니다. 복잡해지는 소프트웨어 검증 과정에서 반복 작업을 줄이고 품질 정확도를 높이는 실질적인 방안을 검토해야 합니다. 왜 지금 이슈인가? 소프트웨어 중심 자동차와 스마트 제조 공정이 확산되면서 엔지니어링 단계에서 처리해야 할 검증 데이터와 항목이 폭발적으로 늘어나고 있습니다. 기존의 수작업 위주 검증 방식으로는 개발 리드타임 단축과 품질 확보가 한계에 이르렀기 때문에, AI 기반의 자동화 솔루션 도입이 시급한 과제로 떠올랐습니다. 핵심 내용 임베디드 개발 및 테스트 환경에 AI 에이전트와 모델 컨텍스트 프로토콜이 적용되면서 복잡한 검증 프로세스의 자동화가 가능해지고 있습니다. 이는 서로 다른 개발 툴과 데이터를 유기적으로 연결하여, 사람이 개입하던 반복적인 테스트와 분석 업무를 AI가 수행하도록 돕는 기술적 변화입니다. 무엇이 달라지는가? 이전에는 엔지니어가 직접 테스트 시나리오를 작성하고 방대한 로그 데이터를 수작업으로 분석하느라 많은 시간과 휴먼 에러가 발생했습니다. 이제는 AI 에이전트가 반복적인 검증 작업을 자동 수행하고 표준화된 연동 기술을 통해 개발 툴 간의 데이터 교환이 매끄러워져 전체 프로세스의 효율성이 크게 향상됩니다. 제조업에 미치는 영향 제조 및 부품 개발 기업은 테스트와 검증에 투입되던 리소스를 크게 절감하고 제품 출시 주기를 단축할 수 있는 기반을 갖추게 됩니다. 특히 휴먼 에러를 최소화함으로써 고도화되는 전장 시스템과 복잡한 제조 소프트웨어의 품질 신뢰성을 높일 수 있습니다. 기업은 무엇을 준비해야 하는가? 사내 개발 및 테스트 프로세스 중 반복 비효율이 발생하는 병목 구간을 발굴합니다. 다양한 엔지니어링 툴 간의 연동 표준인 MCP 등 최신 기술 트렌드를 모니터링합니다. 수작업 위주의 검증 데이터를 정제하여 AI 에이전트가 활용할 수 있는 기반을 마련합니다. 품질 관리와 소프트웨어 테스트 영역에 AI 솔...

제조 현장과 사무직군의 생성형 AI 도입이 가속화되면서 핵심 공정 데이터와 영업비밀의 외부 유출을 차단하는 보안 대책이 시급해지고 있습니다. 공인된 AI 게이트웨이 솔루션을 활용해 사내 보안 규정을 준수하면서도 업무 생산성을 동시에 확보하는 방안을 검토해야 합니다. 왜 지금 이슈인가? 제조 현장과 사무직군 전반에서 업무 효율화를 위해 생성형 AI 도입이 빠르게 추진되면서, 데이터 유출과 보안 리스크 통제가 핵심 과제로 떠올랐습니다. 이에 따라 기업 내외부의 AI 트래픽을 안전하게 관리하고 통제할 수 있는 게이트웨이 솔루션의 도입 필요성이 본격적으로 대두되는 시점입니다. 핵심 내용 생성형 AI 게이트웨이 솔루션이 소프트웨어 품질 인증 1등급을 획득하는 등, 기업이 안전하게 AI를 활용할 수 있는 기반 기술이 공인되고 있습니다. 이는 개별 업무 효율화를 넘어 사내 네트워크 전반에서 AI 관련 트래픽을 통제하고 리스크를 예방할 수 있는 기술적 대안이 마련되었음을 뜻합니다. 무엇이 달라지는가? 이전에는 제조기업이 정보 유출 우려 때문에 생성형 AI 도입을 주저하거나 사내 사용을 전면 통제하는 데 그쳤습니다. 이제는 인증된 게이트웨이 솔루션을 활용해 사내 보안 규정을 준수하면서도 임직원들이 안전하게 생성형 AI를 업무에 활용할 수 있는 환경이 조성되고 있습니다. 제조업에 미치는 영향 영업비밀, 설계 도면, 공정 데이터 등 민감한 정보가 외부 생성형 AI 모델로 유출되는 리스크를 기술적으로 차단할 수 있습니다. 제조기업은 보안 사고에 대한 부담을 덜고, 현장 엔지니어와 사무직군 모두 안심하고 AI 기반 업무 혁신을 시도할 수 있게 됩니다. 기업은 무엇을 준비해야 하는가? 사내 임직원의 생성형 AI 활용 현황과 주요 업무 영역을 파악합니다. AI 트래픽을 모니터링하고 통제할 수 있는 게이트웨이 솔루션 도입을 검토합니다. 영업비밀과 공정 데이터 등 외부 유출 방지가 필요한 핵심 자산을 분류합니다. 보안성과 생산성을 모두 만족하는 사내 생성형 AI 사용 가이...

스마트팩토리 확산으로 제조 현장의 엔드포인트가 급증하면서 실시간 보안과 IT 관리의 복잡성이 커지고 있습니다. 수동 대응의 한계를 극복하기 위해 에이전틱 AI를 결합한 자율형 인프라 관리 체계 도입이 시급해졌습니다. 왜 지금 이슈인가? 공장 자동화와 스마트팩토리 도입으로 제조 현장에 연결된 기기와 엔드포인트가 급증하면서 보안과 IT 관리의 복잡성이 커졌습니다. 기존의 수동 대응 방식으로는 고도화되는 사이버 위협과 시스템 장애를 실시간으로 통제하기 어려워졌기 때문입니다. 핵심 내용 엔드포인트 관리에 에이전틱 AI를 결합하여 IT 및 보안 자동화를 강화하는 방향으로 기술이 진화하고 있습니다. 단순한 모니터링을 넘어 AI가 실시간으로 자산을 파악하고 조치까지 수행하는 것이 핵심입니다. 무엇이 달라지는가? 이전에는 엔드포인트 모니터링과 보안 취약점 대응을 관리자가 수동으로 확인하고 조치해야 하므로 시간이 오래 걸렸습니다. 이제는 에이전틱 AI가 실시간으로 자산을 파악하고 장애나 위협에 즉각적으로 자동 조치를 수행하는 체계로 변화하고 있습니다. 제조업에 미치는 영향 제조기업의 생산 설비와 IT 인프라 전반에서 발생하는 방대한 엔드포인트 데이터를 실시간으로 보호하고 관리하는 역량이 핵심 경쟁력이 됩니다. 보안 취약점이나 시스템 장애 발생 시 대응 시간을 단축하여 제조 라인의 가동 중단 리스크를 최소화할 수 있습니다. 기업은 무엇을 준비해야 하는가? 제조 현장의 모든 엔드포인트 자산과 연결된 기기 현황을 전면적으로 파악합니다. 수동 중심의 IT 및 보안 관제 프로세스에서 자동화 도입이 필요한 영역을 식별합니다. OT와 IT 영역의 융합 환경을 고려한 통합 보안 및 장애 복구 전략을 수립합니다. 에이전틱 AI 기반의 인프라 관리 솔루션 도입을 위한 파일럿 테스트를 검토합니다. AX 관점의 시사점 제조기업은 단순한 AI 도입을 넘어 자율적으로 판단하고 실행하는 에이전틱 AI 기반의 인프라 관리 체계를 검토해야 합니다. OT와 IT 영역이 융합되는 스마트팩...

제조 현장의 품질 관리와 공정 효율화를 위해 AI 도입이 필수적이지만 중소 협력사는 자체 역량 확보가 어렵다. 완성차 업계의 협력사 AI 훈련센터 개소를 계기로 제조 공급망 전반의 디지털 격차를 해소하고 품질 경쟁력을 높이는 방안을 살펴본다. 왜 지금 이슈인가? 제조업 현장에서 품질 관리와 공정 효율화를 위해 인공지능 도입이 필수가 되었으나, 자금과 인력이 부족한 중소 협력사는 자체 역량 확보가 어려운 상황이다. 대기업과 협력사 간의 디지털 격차가 공급망 전체의 리스크로 작용하기 때문에 지금 시점에서 인프라 지원이 본격화되고 있으며, 협력사 교육을 통해 공급망 전체의 체질을 개선하려는 움직임이 가속화되는 국면이다. 핵심 내용 대기업 중심의 공급망 내에서 협력사의 인공지능 전환을 지원하기 위한 전용 훈련센터가 개소되었다. 이는 완성차 업계가 개별 기업의 역량을 넘어 공급망 전반의 기술 격차를 줄이고 생산 체계를 고도화하려는 시도로 해석되며, 제조 현장 전반에 인공지능 기술을 확산하기 위한 실무 교육 인프라가 조성되고 있다. 무엇이 달라지는가? 이전에는 중소 협력사들이 예산과 전문 인력 부족으로 자체적인 AI 도입과 실무 교육에 한계가 있었으나, 이제는 완성차 업계가 조성한 전용 훈련센터를 통해 별도의 비용 부담 없이 AI 실무 교육과 기술 지원을 받을 수 있는 환경이 마련되었다. 제조업에 미치는 영향 개별 부품 제조사와 협력사들은 자체적인 예산 투입 없이도 인공지능 실무 교육과 기술 지원을 받을 수 있는 환경이 조성된다. 이를 통해 공정 불량률 감소, 작업 안전성 향상, 생산 데이터 활용 능력이 동반 상승할 것으로 기대되며, 결국 부품 공급망 전체의 품질 경쟁력이 상향 평준화되는 효과를 낳는다. 기업은 무엇을 준비해야 하는가? 사내 인력 중 AI 실무 교육에 참여할 대상자를 선발하고 직무 연계 방안을 수립해야 한다. 현재 공정 데이터 수집 상태를 점검하고 외부 교육과 연계할 수 있는 현장 과제를 도출해야 한다. 완성차 업계나 유관기관이 제공하는...

제조업 공급망 전반의 디지털 전환이 가속화되면서 완성차뿐만 아니라 부품 협력사의 AI와 로봇 도입이 생존 전략으로 부각되고 있습니다. 개별 공장 단위를 넘어선 공급망 연계 스마트 제조 생태계 구축 방안을 살펴봅니다. 왜 지금 이슈인가? 글로벌 공급망 불안정과 제조 원가 상승 압박 속에서, 부품 협력사까지 생산성과 품질 경쟁력을 동시에 확보해야 하는 필요성이 커졌습니다. 제조 현장의 고령화와 숙련공 부족 문제에 대응하기 위해 AI와 로봇 도입은 이제 선택이 아닌 생존 전략이 되었습니다. 핵심 내용 완성차 업계의 주도 하에 부품 협력사들과 인공지능 및 로봇 기반의 제조 혁신 기술을 확대하며 스마트 제조 생태계 조성이 추진되고 있습니다. 이는 대기업 중심의 단발성 기술 도입을 넘어, 공급망 전반의 디지털 전환과 지능화를 가속화하는 흐름입니다. 무엇이 달라지는가? 이전에는 개별 부품 협력사가 자체 자금과 인력만으로 개별 공정의 자동화를 시도하며 데이터 연계의 한계를 겪었으나, 이제는 완성차 업계와 연계된 지원 프로그램을 바탕으로 AI와 로봇 기술을 공급망 전반에 확대 적용하는 방식으로 변화하고 있습니다. 제조업에 미치는 영향 개별 기업 차원을 넘어 부품 공급망 전체의 제조 지능화 수준이 향상되는 계기가 됩니다. 협력사의 불량률 감소와 생산 효율성 증대는 결국 완성차 제조사의 품질 경쟁력 강화로 직결됩니다. 기업은 무엇을 준비해야 하는가? 자사 공장의 현재 자동화 수준을 진단하고 AI 및 로봇 도입이 시급한 병목 공정을 식별합니다. 대기업 및 유관기관의 협력사 스마트 제조 지원 프로그램과 연계 가능한 방안을 검토합니다. 생산 현장의 데이터를 수집하고 표준화하여 향후 공급망 데이터 연동에 대비합니다. 현장 작업자의 AI 및 로봇 장비 운용 역량을 높이기 위한 교육 체계를 마련합니다. AX 관점의 시사점 제조기업은 자사 공장 내의 AI 도입에만 머물지 않고, 부품을 공급하는 1, 2차 협력사들과의 데이터 연계와 기술 표준화를 준비해야 합니다. 공급망 ...

앞선 글에서 설비는 관제하는데 업무는 관제하지 않는다고 썼습니다. 그러면 어떻게 거기까지 갈 수 있는지가 남습니다. 화면부터 만들 수는 없습니다. 순서가 있습니다. 부서별 조각 → L4 흐름 정의 → E2E 드러남 → E2E 흐름 감시 지금은 조각으로 있습니다 프로세스 문서가 없는 회사는 드뭅니다. 대개 있습니다. 문제는 부서별로 따로 있다는 것 입니다. 설계 부서에는 설계 프로세스가 있고, 구매에는 구매 프로세스가 있습니다. 각각은 잘 정리되어 있습니다. 그런데 이것들을 나란히 놓아도 전체 흐름이 나오지 않습니다. 이유는 문서가 부실해서가 아닙니다. 각 문서가 자기 부서 안에서 완결되게 쓰여 있기 때문입니다. 설계 프로세스는 "설계 완료"로 끝나고, 구매 프로세스는 "소요량 접수"로 시작합니다. 그 사이에 무엇이 어떤 형태로 넘어가는지는 어느 문서에도 없습니다. 그리고 문제는 대개 그 사이에 있습니다. L4까지 내려갑니다 프로세스는 계층으로 봅니다. 큰 덩어리에서 시작해 실제 작업 단위까지 내려가는 구조입니다. L1 — 수주, 설계, 구매, 생산 같은 대분류 L2 — 설계 안에서 기본설계, 상세설계, BOM 작성 L3 — BOM 작성 안에서 표준품 BOM, 신규 BOM, 변경 반영 L4 — 실제로 사람이 하는 작업 단위 단계 수는 회사마다 다릅니다. 중요한 것은 더 쪼갤 수 없는 작업 단위까지 내려가는 것 입니다. 앞서 AX 수준을 판정하려면 업무를 쪼개야 한다고 썼는데, 그 쪼개기의 끝이 여기입니다. 여기서 하나를 더 적습니다 보통 프로세스 문서에는 순서와 담당자와 산출물 이름이 들어갑니다. 그것으로는 부족합니다. L4에 프로세스 흐름과 데이터 흐름을 함께 정의해야 합니다. 이 작업이 무엇을 받아서 무엇을 내놓는지, 그 데이터가 어느 시스템의 어느 항목인지까지 적는 것입니다. "BOM 작성" 옆에 이렇게 붙습니다. 받는 것은 확정된...

지금까지 잘된 이야기를 주로 썼습니다. 1억 견적을 700만 원으로 줄인 이야기, 2주에 시스템을 만든 이야기, 팀으로 퍼진 이야기입니다. 그것만 읽고 판단하면 안 됩니다. 저는 계속 이 방식으로 일할 생각이고, 그래서 오히려 위험을 더 정확히 알아야 합니다. 이번 글은 반대편입니다. 느낌이 아니라 확인된 데이터로 정리했습니다. 1. 빨라졌다는 느낌은 정확하지 않습니다 2025년 7월에 나온 METR의 실험이 있습니다. 숙련 개발자 16명에게 246개의 실제 과제를 주고, AI 도구를 쓸 수 있는 조건과 못 쓰는 조건으로 나눠 비교했습니다. 결과는 이랬습니다. 참가자들은 실험 전에 AI가 24% 빠르게 해줄 것으로 예상했습니다. 실제로는 19% 더 느렸습니다. 그런데 실험이 끝난 뒤에도 참가자들은 AI가 20% 빠르게 해줬다고 믿었습니다. 마지막 항목이 중요합니다. 겪어본 사람이 겪은 다음에도 반대로 인식했습니다. 다만 이 연구는 스스로 한계를 분명히 밝히고 있습니다. 참가자들은 별 2만 개가 넘는 대형 오픈소스 저장소에 수년간 기여한 사람들이었고, 문서화와 테스트와 린팅 같은 암묵적 요구가 많은 환경이었습니다. 연구진 스스로 이 결과가 소프트웨어 개발 전반을 대표한다고 주장하지 않습니다. 학습 곡선 가능성도 언급합니다. 도구를 오래 쓴 경우는 다를 수 있다는 것입니다. 그래서 이 데이터를 "AI가 개발을 느리게 한다"로 읽으면 과장입니다. 제가 읽은 것은 다른 부분입니다. 속도를 체감으로 판단하면 안 된다는 것 입니다. 앞선 글에서 운영 2개월 실측치를 적었습니다. 접수 112건, 완료율 61%, 평균 리드타임 153시간. 이 숫자를 굳이 넣은 이유가 여기 있습니다. 좋아진 것 같다는 감각은 근거가 되지 못합니다. 2. 코드가 쌓이면서 유지보수성이 나빠집니다 이쪽이 더 무섭습니다. GitClear가 2023년부터 2026년까지 6억 2천만 건의 코드 변경을 분석한 결과입니다. 중복 블...

4년 사이에 AI를 쓰는 방식이 세 번 바뀌었습니다. 처음에는 질문을 잘하는 법을 배웠습니다. 그다음에는 무엇을 읽게 할지를 고민했습니다. 지금은 다른 곳에 시간을 쓰고 있습니다. 이 흐름을 정리해두면 지금 어디에 힘을 써야 하는지 판단하기 쉬워집니다. 1단계 · 프롬프트 엔지니어링 (2022~2024) 초점은 지시 였습니다. 어떻게 물어보면 좋은 답이 나오는지를 찾는 일입니다. "너는 전문 개발자다"로 역할을 지정하고, 예시를 두세 개 보여주고, "단계별로 생각해봐"를 붙이는 기법들이 이 시기에 정리됐습니다. 프롬프트 잘 쓰는 법을 모아놓은 자료가 쏟아졌습니다. 이 단계의 실패 모드는 일관성이 없다는 것 이었습니다. 어제 잘 나온 방식으로 오늘 물으면 다른 답이 나옵니다. 같은 질문을 조금 다르게 썼는데 결과가 달라집니다. 그래서 "잘 물어보는 사람"이 실력처럼 보였습니다. 2단계 · 컨텍스트 엔지니어링 (2025) 초점이 지시에서 지식 으로 옮겨갔습니다. 질문을 아무리 다듬어도 넘지 못하는 벽이 있다는 것이 분명해졌기 때문입니다. AI가 우리 코드베이스를 모르고, 우리 데이터 구조를 모르고, 왜 이렇게 설계했는지를 모르면, 질문이 완벽해도 결과가 맞을 수 없습니다. 그래서 무엇을 읽게 할지를 설계하기 시작했습니다. 코드베이스, 스펙 문서, 설계 결정 기록을 구조적으로 넣어주는 일입니다. 이 단계의 실패 모드가 특히 위험합니다. 잘못된 정보 위에서도 자신 있게 추론한다는 것 입니다. 앞선 글에서 첫 시스템을 만들 때 화면만 만들어지고 뒷단이 비어 있었던 이야기를 썼습니다. 그것이 정확히 이 실패였습니다. 저는 질문을 잘못한 것이 아니었습니다. 우리 환경에 대한 정보를 주지 않았고, AI는 없는 정보를 채워서 그럴듯한 것을 만들었습니다. 그리고 자신 있게 내놓았습니다. 여기서 배운 것은 AI가 모른다고 말하지 않는다 는 사실이었습니다. 모르면 채웁니다. 3단...

앞선 글에서 첫 시스템을 만들 때 한 번 되돌린 이야기를 썼습니다. 화면은 다 만들어져 있는데 뒷단이 비어 있었던 일입니다. 그때는 제가 도구를 잘 몰라서 그런 줄 알았습니다. 지금 보면 도구 사용법의 문제가 아니었습니다. 개념을 몰랐던 것 입니다. 바이브 코딩에는 알아야 할 개념이 다섯 개 있습니다. 도구마다 이름이 조금씩 다르지만 하는 일은 같습니다. 이것을 알기 전과 후가 결과에서 확실히 달랐습니다. 1. 컨텍스트 — 지식의 책장 AI가 작업할 때 참고하는 사전 정보와 환경입니다. 이것이 왜 중요한지는 제 실패가 정확히 보여줍니다. 저는 "요청 관리 시스템을 만들어줘"라고 말했습니다. AI는 우리 회사가 어떤 데이터베이스를 쓰는지, 기존 시스템이 어떻게 생겼는지, 데이터를 어디에 저장해야 하는지 몰랐습니다. 모르면 AI는 추측합니다. 그리고 추측한 결과를 자신 있게 내놓습니다. 일반적인 웹 화면을 만들어주는 것은 잘합니다. 우리 환경에 맞는 뒷단을 만드는 것은 알 방법이 없었습니다. 여기서 중요한 것은 AI가 "모르겠다"고 말하지 않는다는 점입니다. 그럴듯한 것을 만들어냅니다. 그래서 컨텍스트가 비어 있으면 틀린 결과가 아니라 그럴듯하게 틀린 결과 가 나옵니다. 이쪽이 훨씬 위험합니다. 컨텍스트를 채운다는 것은 시험을 오픈북으로 바꾸는 일입니다. 우리 시스템 구조, 데이터 스키마, 코딩 규칙, 기존 코드를 미리 읽게 해두는 것입니다. 다섯 개 개념 중에서 결과에 미치는 영향이 가장 큽니다. 2. 스킬 — 업무 레시피 특정 작업을 어떻게 해야 하는지 적어둔 매뉴얼입니다. 같은 종류의 작업을 반복하다 보면 매번 같은 설명을 하고 있다는 것을 알게 됩니다. "목록 화면을 만들 때는 검색과 정렬을 넣고, 페이지당 20건으로, 권한 체크를 앞에 두고..." 이런 설명입니다. 이것을 문서로 만들어두면 그다음부터는 "목록 화면 만들어줘"만 말하면 됩니다...

보통은 이렇게 합니다. 과제 목록을 만들고, 담당자를 지정하고, 일정을 넣고, 주기적으로 점검합니다. 저도 오래 그렇게 해왔습니다. 이번에는 안 했습니다. IT팀은 일곱 명입니다. 팀장 한 명과 팀원 여섯 명이 정보기획, ERP, PLM, MES, CRM, AI, 보안, 인프라를 나눠 맡고 있습니다. 이 인원에게 과제를 나눠주지 않고 이렇게만 말했습니다. 각자 가장 답답했던 일을 하나 고르십시오. 왜 배분하지 않았는가 앞선 글들에서 반복해서 부딪친 원칙이 있습니다. 데이터를 입력하는 사람과 그 이득을 보는 사람이 같아야 시스템이 정착한다 는 것입니다. 어긋나면 규정으로 강제해도 형식만 채워집니다. 과제도 같습니다. 위에서 배분한 과제는 받는 사람 입장에서 남의 일 입니다. 하기는 하지만 일정에 맞춰 보고할 수 있을 만큼만 합니다. 그리고 만들어놓고 본인도 안 씁니다. 반대로 자기가 매일 겪는 불편을 고르면 만드는 이유가 자기 안에 있습니다. 중간에 막혀도 붙들고 있습니다. 다 만들면 본인이 제일 먼저 씁니다. 도구 값이 싸졌기 때문에 이 선택이 가능해졌습니다. 예전에는 개발 자원이 귀해서 우선순위를 정해 배분하는 것이 유일한 방법이었습니다. 지금은 각자 만들 수 있으니 굳이 줄을 세울 필요가 없습니다. 각자 고른 것 결과가 흥미로웠습니다. 보안 담당자 — 방화벽 로그 분석 인프라 담당자 — 자산관리 시스템 CRM 담당자 — 고객 요구사항 포털 AI 담당자 — 데이터 관리 포털 혁신 담당자 — 프로세스 관리 포털 ERP 담당자 — Agent 관리 포털 PLM 담당자 — KPI 주별 리포트, 교육자료 포털 팀장이 만든 두 건을 합쳐 프로젝트가 열 건이 되었습니다. 목록을 보고 두 가지가 눈에 들어왔습니다. 아무도 남의 영역을 고르지 않았습니다. 각자 자기가 매일 만지는 것에서 골랐습니다. 당연해 보이지만 배분했다면 이렇게 되지 않습니다. 배분하는 사람은 전체를 보고 나누기 때문에 담당자...

대표가 주관하는 월례 회의가 있었습니다. 전사 AI 과제를 점검하는 자리였습니다. 2026년 7월에 처음 운영했고 8월이 두 번째였습니다. 문제는 자료였습니다. 사업부마다 PPT나 Word로 각자 만들어 왔는데 관리하는 내용이 서로 달랐습니다. 꼭 있어야 할 항목이 빠진 자료도 있었습니다. 취합하는 IT 부서 입장에서는 매달 반복되는 일이었습니다. 그래서 지시가 내려왔습니다. "양식을 통일하라." 합리적인 지시입니다. 양식이 같으면 비교가 되고 누락도 줄어듭니다. 저도 처음에는 양식을 만들려고 했습니다. 그런데 양식을 통일해도 안 풀리는 것 양식을 통일하면 무엇이 해결되는지 따져봤습니다. 항목 누락은 줄어듭니다. 비교도 조금 쉬워집니다. 그런데 취합은 여전히 사람이 합니다. 사업부에서 파일을 보내고, IT 부서가 받아서 하나로 합치고, 합치면서 오류를 잡고, 회의 전날 밤에 마무리합니다. 다음 달에 또 합니다. 그리고 더 근본적인 것이 남습니다. 양식이 같아져도 각자는 여전히 자기 문서만 봅니다. 회의의 목적을 보니 답이 달랐습니다 이 회의에서 실제로 무엇을 다루는지 다시 봤습니다. 어느 과제를 지원할지 정하는 것 다른 사업부는 무엇을 만들고 있는지 아는 것 잘 되는 곳의 방식을 가져오는 것 어떻게 더 활성화할지 논의하는 것 네 가지 중 세 가지가 서로를 보는 일 입니다. 이 회의의 목적 자체가 그것이었습니다. 그런데 문서는 각자 쓰는 도구입니다. 자기 파일을 열고 자기 내용을 쓰고 제출합니다. 다른 사업부가 무엇을 하고 있는지는 회의 자리에서 발표를 들을 때 알게 됩니다. 그것도 그 순간에만 알고 넘어갑니다. 도구가 목적을 배반하고 있었습니다. 양식을 통일하는 것은 이 모순을 건드리지 않습니다. 그래서 양식을 만들지 않고 양식이 필요 없는 시스템 을 만들기로 했습니다. 2주가 걸렸습니다 지난 글에서 쓴 ITSM 다음이 이 시스템이었습니다. 한 번 해본 경험이 있으니 두...

사내 IT 서비스 요청을 관리하는 시스템이 필요했습니다. 흔히 ITSM이라고 부르는 것입니다. 직원이 IT 관련 요청을 올리고, 담당자가 배정되고, 처리 상태가 추적되는 시스템입니다. 기한이 정해진 지시였습니다. 방법은 두 가지로 보였습니다. 외주를 주거나, 상용 솔루션을 사거나. 외주 견적은 1억 원 이었습니다. 규모가 큰 회사라면 쓸 수 있는 금액입니다. 그런데 사내 요청 관리 시스템 하나에 1억을 쓰는 것은 우선순위가 맞지 않았습니다. 그래서 다른 길을 찾다가 소스 코드를 구할 수 있다는 것을 알았습니다. 필요한 것은 표(Grid) 컴포넌트 라이선스뿐이었고 그 값이 500만 원 이었습니다. 1억과 500만 원 사이의 간격을 보면서 생각이 바뀌었습니다. 이 일의 본질이 무엇인가. 계기는 하루짜리 교육이었습니다 2026년 5월 26일, 바이브 코딩 교육을 하루 받았습니다. 다른 과제의 부속 과정으로 잡힌 일정이었고 큰 기대는 없었습니다. 바이브 코딩은 코드를 직접 타이핑하지 않고 만들고 싶은 것을 말로 설명하는 방식입니다. "로그인 페이지 만들어줘", "에러 나는데 왜 그래?", "배경색 바꿔줘" 같은 대화로 진행합니다. 파일 관리, 코드 작성, 오류 해결, 명령어 실행까지 대화로 처리됩니다. 교육을 받고 나서 판단이 하나 섰습니다. 이 방식이면 직접 만들 수 있다. 3주 후에 열었습니다 6월 16일에 ITSM을 오픈했습니다. 교육받은 날로부터 3주, 실제 작업은 4주 남짓이었습니다. 개발 인원은 한 명이었습니다. 도구는 ChatGPT와 Cursor를 함께 썼습니다. 담은 기능은 이렇습니다. 요청부터 결재까지 포털 하나에서 — 메일과 전화로 흩어져 있던 요청을 한 곳으로 모았습니다. 카테고리를 고르면 담당자가 자동으로 연결 — 누구에게 보내야 하는지 요청자가 몰라도 됩니다. 내 요청이 지금 어느 단계인지 보인다 — 진행 상황을 물어보는 전화가 사라졌...

제조업에는 관제라는 말이 익숙합니다. 설비 상태를 실시간으로 봅니다. 온도와 진동과 가동률이 화면에 뜨고, 이상이 생기면 알림이 옵니다. 오래전부터 해온 일입니다. 그런데 이렇게 물어보면 답이 잘 안 나옵니다. "지금 진행 중인 수주 100건 중에 몇 건이 어디서 막혀 있습니까." 각 부서에 물어보면 자기 구간은 답합니다. 설계는 설계 진척을, 구매는 발주 현황을, 생산은 작업 진행을 압니다. 그런데 수주 한 건이 들어와서 출하까지 가는 전체 흐름을 한눈에 보는 화면은 대개 없습니다. 설비는 관제하는데 업무는 관제하지 않습니다. 왜 지금 이 이야기를 하는가 업무가 안 보이는 상태는 새로운 문제가 아닙니다. 오래 그랬고 그럭저럭 굴러왔습니다. 사람이 전화하고 메일 보내고 회의해서 맞췄습니다. 그런데 지금 두 가지가 달라지고 있습니다. 첫째, 사람이 보지 않는 곳에서 일이 진행되기 시작했습니다. 부서마다 Agent를 만들어 쓰고, 만들기 쉬워지면서 도구가 늘어납니다. 그것들이 각자 판단하고 각자 처리합니다. 사람이 매 건을 확인하던 시절에는 흐름이 사람 머릿속에 있었습니다. 이제는 어디에도 없습니다. 둘째, 안 보이는 것은 통제할 수 없습니다. 자동화된 것이 잘못 돌아가면 사람이 하던 실수보다 빠르게 번집니다. 그리고 무엇이 왜 그렇게 됐는지 나중에 되짚을 수 없으면 고칠 수도 없습니다. E2E로 본다는 것 E2E는 끝에서 끝까지라는 뜻입니다. 수주에서 시작해 설계, 구매, 생산, 출하, 정산까지 하나의 흐름으로 보는 것입니다. 지금은 대개 구간별로 봅니다. 각 부서가 자기 시스템에서 자기 지표를 봅니다. 그러면 두 가지가 안 보입니다. 구간 사이 — 설계가 끝나고 구매가 시작되기까지 며칠이 걸리는지. 각 부서 안에서는 문제없이 처리됐는데 사이에서 시간이 사라집니다. 한 건의 전체 여정 — 이 수주 건이 지금까지 어디서 얼마나 지체됐는지. 부서별 평균 리드타임은 알지만 특정 한 건이 왜 늦...

지난 글에서 업무마다 수준을 판정하는 방식을 이야기했습니다. 그 계단에서 프로세스 정립 이 시스템 사용보다 앞에 있었습니다. 이번에는 그 순서를 지키지 않으면 어떻게 되는지 써보겠습니다. 프로세스 없이 시스템을 넣으면 흔히 이렇게 생각합니다. "시스템을 넣으면 프로세스가 정리되겠지." 실제로는 반대로 일어납니다. 프로세스를 정의하지 않은 상태에서 시스리 업무를 얹으면, 맞는 부분은 그냥 쓰고 안 맞는 부분은 우회하게 됩니다. 우회의 결과가 엑셀과 메일 입니다. 시스템에 안 맞는 일이 밖으로 나가고, 밖으로 나간 일은 기록에 안 남습니다. 그리고 아무도 이 프로세스를 설계하지 않았습니다. 패키지가 절반, 우회 관행이 절반을 만들었습니다. 몇 년 지나면 왜 이렇게 하는지 아는 사람이 없어집니다. "원래 이렇게 해왔다"는 답만 남습니다. 그런데 순서를 지키기가 비쌌습니다 순서를 지킨다는 것은 이런 뜻입니다. 먼저 우리 업무를 정의하고, 그다음에 그 업무에 맞는 시스템을 만드는 것. 이 방식이 옳다는 것은 오래전부터 알려져 있었습니다. 그런데 실제로는 거의 하지 못했습니다. 비용 때문입니다. 우리 프로세스에 맞춰 시스템을 만들려면 개발이 필요했고, 개발은 비쌌습니다. 사람과 기간이 들어가고, 만든 다음에도 유지보수가 따라옵니다. 반면 패키지는 이미 만들어져 있습니다. 그래서 대부분 패키지를 사고 업무를 거기에 맞췄습니다. 합리적인 선택이었습니다. 프로세스에 시스템을 맞추는 것보다 시스템에 프로세스를 맞추는 것이 훨씬 쌌기 때문입니다. 그 비용 구조가 바뀌고 있습니다 지금 달라지고 있는 것은 개발 비용입니다. AI가 코드를 만들면서 무언가를 새로 만드는 데 드는 시간과 비용이 크게 줄었습니다. 그러면 계산이 뒤집힙니다. 업무 하나에 맞는 도구를 만드는 일이 패키지를 도입하고 커스터마이징하는 것보다 빠르고 싸질 수 있습니다. 여기서 중요한 결론이 나옵니다. 병목이 개발에서 프로세스 정의...

AX를 시작하려는 회사에서 가장 먼저 나오는 질문은 대개 이것입니다. "우리는 지금 어디쯤 와 있나." 이 질문에 답하려고 성숙도 모델을 꺼내는 경우가 많습니다. 레벨 1부터 5까지 나누고, 각 레벨의 특징을 적고, 우리 회사가 몇 단계인지 표시하는 방식입니다. 그런데 이 방식은 대개 쓸모가 없습니다. 이유는 모델이 부실해서가 아닙니다. 회사 단위로 레벨을 매기는 것 자체가 성립하지 않기 때문 입니다. 같은 회사 안에서도 수준이 다릅니다 앞서 쓴 글 에서 이런 상황을 다룬 적이 있습니다. 자재관리는 시스템을 아주 잘 쓰는데, 몇 걸음 떨어진 설계 쪽에서는 BOM이 엑셀로 만들어지고 메일로 넘어옵니다. 같은 회사, 같은 시스템입니다. 이 회사는 몇 단계일까요. 답할 수 없습니다. 자재 입출고는 시스템에 정착된 수준이고, BOM 작성은 엑셀 수준입니다. 사업부에 따라서도 다릅니다. 회사 전체에 숫자 하나를 붙이면 이 차이가 사라집니다. 그리고 사라진 그 차이에 정작 중요한 정보가 들어 있습니다. 그래서 업무를 쪼갭니다 제가 쓰는 방식은 이렇습니다. 회사의 큰 업무 단위에서 시작해 계속 쪼갭니다. 더 쪼갤 수 없을 때까지 내려갑니다. 설비제조업이라면 예를 들어 이런 식입니다. 수주 — 견적, 사양 확정, 계약, 수주 등록 설계 — 기본설계, 상세설계, BOM 작성, 설계 변경관리 구매 — 소요량 산출, 발주, 납기 관리, 수입검사 생산 — 생산계획, 작업지시, 실적 집계, 조립·시운전 품질 — 검사 기준 관리, 부적합 처리, 원인 분석 원가 — 견적원가, 실적원가, 차이 분석 여기서 더 내려갑니다. "BOM 작성"도 한 덩어리가 아닙니다. 표준품 BOM과 신규 설계 BOM은 성격이 다르고 수준도 다릅니다. 업무마다 수준을 판정합니다 쪼갠 업무 하나하나에 대해 지금 어디에 있는지를 봅니다. 순서대로 올라가는 계단입니다. 업무가 정의되어 있는가 — 이 일을 ...

지난 글 에서 AX가 세 단계로 들어온다고 썼습니다. 문서 작성, 부서별 Agent, 그리고 기간계 연계. 앞의 둘은 잘 굴러가는데 세 번째에서 막힌다고 했습니다. 이번에는 그 벽이 구체적으로 무엇인지 써보겠습니다. 전제 — 기간계가 먼저 제대로 돌아야 합니다 당연한 말 같지만 이것이 첫 관문입니다. ERP, MES, PLM이 각각 잘 작동하고 있어야 그 위에 무언가를 올릴 수 있습니다. 여기서 "잘 작동한다"는 화면이 열린다는 뜻이 아닙니다. 데이터가 제때 들어오고, 그 데이터를 믿을 수 있다는 뜻입니다. BOM이 늦게 올라오거나 재고가 실물과 다르면, 그 위에 무엇을 올려도 결과는 같이 틀립니다. 첫 번째 벽 — 기준정보와 용어 제조기업에는 기간계가 하나가 아닙니다. ERP, MES, PLM, CRM, 문서관리, 프로젝트관리가 각각 있고 대개 도입 시기도 다릅니다. 이 시스템들을 연계하려면 그 사이를 맞춰줄 기준정보와 용어가 정리되어 있어야 합니다. 그런데 대부분 정리되어 있지 않습니다. 거래선 정보를 예로 들면 이렇습니다. 어떤 시스템은 고객과 벤더를 분리 해서 관리합니다. 어떤 시스템은 거래선 하나로 합쳐서 관리합니다. 둘 다 그 시스템 안에서는 합리적인 설계입니다. 문제는 연계할 때 생깁니다. 코드 체계가 다르니 어느 코드와 어느 코드가 같은 회사인지 기계가 알 방법이 없습니다. 그동안은 사람이 맞춰왔습니다 여기가 핵심입니다. 이 불일치는 어제오늘 생긴 것이 아닙니다. 몇 년, 길게는 십 년 넘게 있었습니다. 그런데 큰 문제로 터지지 않았습니다. 담당자가 알고 있었기 때문입니다. "아, ERP의 이 코드랑 CRM의 저 코드는 같은 회사야." 이 판단을 사람이 매번 해주고 있었습니다. 명시된 규칙이 아니라 경험으로 아는 것이고, 그래서 어디에도 적혀 있지 않습니다. AI를 붙이는 순간 이 흡수 장치가 사라집니다. AI는 눈치로 맞추지 못합니다. 사람이 조용히...

요즘 AX라는 말이 부쩍 늘었습니다. DX는 이제 낡은 말처럼 취급되기도 합니다. 그런데 제조 현장의 사정은 좀 다릅니다. DX가 끝난 곳이 많지 않습니다. 시스템은 도입했지만 BOM은 여전히 엑셀로 만들어지고, 실적은 수기로 적었다가 나중에 입력됩니다. 그 상태에서 AX 이야기가 밀려옵니다. 그래서 두 단어를 구분하는 일이 용어 정리가 아니라 실무 판단의 문제가 됩니다. 무엇을 먼저 해야 하는지가 여기서 갈립니다. 용어부터 짧게 DX(Digital Transformation) 는 종이와 사람의 기억으로 돌아가던 일을 데이터로 옮기는 것입니다. ERP, MES, PLM 도입이 여기에 해당합니다. AX(AI Transformation) 는 그 데이터를 가지고 AI가 일의 일부를 맡는 것입니다. 여기까지는 어느 자료에나 있는 설명입니다. 문제는 이 정의가 현장에서 판단할 때 별로 도움이 안 된다는 것입니다. 실질적인 경계는 '판단을 누가 하는가'입니다 DX는 사람이 판단하도록 데이터를 보여줍니다. 대시보드를 만들고, 리포트를 뽑고, 현황을 화면에 띄웁니다. 판단은 그것을 보는 사람이 합니다. AX는 판단까지 합니다. 그리고 경우에 따라 실행도 합니다. 설비 데이터로 예를 들면 이렇게 갈립니다. DX — 진동값 추이 그래프를 보여줍니다. 담당자가 보고 "슬슬 봐야 하나" 판단합니다. AX — "3번 설비 베어링, 3주 내 점검 필요"라고 말합니다. 판단이 결과물로 나옵니다. 같은 데이터, 다른 산출물입니다. DX는 데이터를 보는 훈련을 요구했고, AX는 기계의 판단을 어디까지 믿을지 정하는 일 을 요구합니다. 후자가 훨씬 어렵습니다. AX는 DX가 남긴 데이터를 먹고 자랍니다 AI는 없는 데이터로 판단하지 못합니다. 설비 이력이 없으면 예측정비를 못 하고, 불량 데이터가 정리되어 있지 않으면 품질 예측을 못 합니다. 재고 정확도가 70%인 상태에서 AI에...

제조 현장에서 시스템을 넣고 정착시키는 일을 오래 했습니다. 그러면서 반복해서 보게 되는 장면이 있습니다. 자재관리 쪽은 시스템을 아주 잘 씁니다. 입고와 출고가 제때 잡히고, 재고를 물어보면 화면을 열어 답합니다. 굳이 확인 전화를 걸 필요가 없습니다. 그런데 몇 걸음 떨어진 설계 쪽으로 가면 이야기가 달라집니다. BOM이 엑셀로 만들어지고, 메일로 넘어옵니다. 같은 회사, 같은 시스템입니다. 사업부에 따라 어떤 곳은 잘 쓰고, 어떤 곳은 잘 쓰지 않습니다. 한 회사만의 이야기가 아닙니다. 엔지니어링 수주산업에서는 흔한 모습입니다. BOM이 늦으면 뒤가 전부 밀립니다 BOM은 단순한 부품 목록이 아닙니다. 그 프로젝트의 실행 계획입니다. BOM이 나와야 소요량이 계산되고, 소요량이 있어야 구매가 움직이고, 자재 입고 일정이 잡혀야 생산계획이 나옵니다. 생산계획이 없으면 작업지시도 나가지 않습니다. BOM 하나가 늦으면 그 아래가 전부 밀립니다. 엔지니어링 수주산업에서는 이 영향이 더 큽니다. 수주마다 구성이 달라서 표준 BOM을 꺼내 쓸 수 없습니다. 매번 새로 만들어야 하고, 그래서 매번 늦습니다. 도구가 문제라면 양쪽이 같이 어려워야 합니다 교육이 부족했나 싶어질 때가 있습니다. 화면이 불편한가 싶기도 합니다. 그런데 자재관리는 같은 시스템으로 잘 쓰고 있습니다. 같은 교육을 받았고 같은 화면을 씁니다. 도구가 문제라면 양쪽이 함께 어려워야 합니다. 그래서 도구가 아니라 일의 성질을 봐야 합니다. 확정하면 변경관리를 해야 합니다 BOM을 시스템에 올려 확정하면, 그다음부터 바뀔 때마다 변경관리를 해야 합니다. 엔지니어링 수주산업은 변경이 잦습니다. 고객 요구가 진행 중에 바뀌는 일이 흔하고, 설계가 잘못되어 고쳐야 하는 경우도 적지 않습니다. 확정하는 순간 이 모든 변경이 절차를 타는 일이 됩니다. 엑셀은 그냥 고치면 됩니다. 파일을 다시 보내면 그것으로 끝입니다. 기록이 남습니다 변경 사유를 남기는 이유는 원래 같은 문제가...