심센터 HEEDS 더 깊게 살펴 보기 (9)   매번 같은 설정을 반복하고 있다면, 그 작업은 이미 자동화할 대상이다. HEEDS(히즈)에서는 GUI에서 수행한 설정을 스크립트(script)로 기록하고, 이를 재사용 가능한 파이썬 API(Python API) 흐름으로 발전시킬 수 있다. 이번 호에서는 복잡한 프로젝트 설정을 한 번의 실행으로 처리하는 오토메이션 스크립트(automation script)의 구성 방법을 살펴 본다.   ■ 연재순서 제1회 심센터 HEEDS 커넥트와 MBSE 방법론 제2회 심센터 X MDO의 새로운 HEEDS 제3회 심센터 HEEDS SHERPA의 최적 검색 원리 제4회 최적 검색 가속화를 위한 AI 프레딕터 제5회 심센터 HEEDS 2604 업데이트 제6회 모두를 위한 제너럴 포털과 맞춤 설정 제7회 특별한 워크플로 구성 및 자동화 제8회 다양한 매개변수를 위한 태깅 모드 제9회 복잡한 설정을 한번에, 오토메이션 스크립트 제10회 파이썬 스케줄러와 HEEDS 연동 제11회 심센터 HEEDS 2610 업데이트 제12회 데이터 분석을 위한 HEEDSPy API   ■ 이종학 지멘스 디지털 인더스트리 소프트웨어에서 심센터 HEEDS를 비롯하여 통합 설루션을 활용한 프로세스 자동화와 데이터 분석, 최적화에 대한 설루션을 담당하고 있다. 근사최적화 기법 연구를 전공하고 다양한 산업군에서 15년간 유한요소해석과 최적화 분야의 기술지원과 컨설팅을 수행하였다. 홈페이지 | www.sw.siemens.com/ko-KR 링크드인 | www.linkedin.com/in/jonghaklee-odumokgol   시뮬레이션 기반 설계 탐색을 수행할 때 가장 많은 시간이 소요되는 부분은 해석 자체가 아닐 수 있다. 해석 모델과 입력 파일을 연결하고, 설계변수와 응답을 정의하며, 실행 조건과 결과 저장 방식을 설정하는 과정에서 반복적인 수작업이 발생하기 때문이다. 같은 형식의 프로젝트를 여러 번 구성하거나, 여러 해석 모델에 동일한 규칙을 적용해야 한다면 이 부담은 더욱 커진다. 심센터 HEEDS(Simcenter HEEDS)는 이러한 설정 작업을 파이썬 기반 오토메이션 스크립트로 자동화할 수 있도록 스크립트 레코딩(Script Recording)과 HEEDS 파이썬 API(HEEDS Python API)를 제공한다. 사용자가 GUI에서 수행한 작업을 스크립트로 기록한 뒤, 필요한 부분을 정리하고 API를 이용해 프로젝트 생성, 파일 연결, 변수 및 응답 설정, 스터디(study) 실행과 리포트(report) 작성까지 하나의 흐름으로 구성할 수 있다. 이번 호에서는 HEEDS 오토메이션 스크립트의 기본 개념부터 프로젝트 설정 자동화, 실행 검증, 사용자 정의 도구와 배치(batch) 실행까지 살펴본다. 단순히 스크립트를 실행하는 방법이 아니라, 반복되는 설정을 재사용 가능한 표준 절차로 바꾸는 방법에 초점을 둔다.   반복 설정 작업이 만드는 자동화의 병목 HEEDS를 이용한 최적화 프로젝트는 일반적으로 Process, Analysis, Input File, Output File, Variable, Response, Study와 같은 객체를 조합하여 구성한다. 각각의 객체는 해석 모델과 최적화 알고리즘을 연결하기 위해 필요한 설정을 갖는다. 예를 들어 하나의 프로젝트를 구성할 때에도 다음 작업이 필요하다. 해석 솔버(solver)와 실행 명령 설정 입력 파일(input file)과 출력 파일(output file) 등록 입력 파일 위치에 설계변수 연결 출력 파일 위치에 응답값 연결 변수의 기준값과 탐색 범위 정의 목적함수와 제약조건 설정 스터디 방법과 평가 횟수 설정 실행 자원과 결과 저장 옵션 설정 이 작업을 한 번 수행하는 경우에는 GUI(그래픽 사용자 인터페이스)가 직관적인 방법이 될 수 있다. 그러나 동일한 구조의 프로젝트를 여러 개 만들거나, 설계변수의 개수가 수십 개 이상으로 늘어나면 사람이 직접 설정하는 방식은 한계가 있다. 변수 이름의 오타, 파일 경로의 불일치, 누락된 태깅(tagging), 잘못된 실행 명령과 같은 오류가 해석 시작 이후에 발견될 수도 있다. 오토메이션 스크립트의 목적은 GUI를 없애는 데 있지 않다. GUI는 처음 프로세스를 구성하고 기능을 확인하는 데 유용하다. 스크립트는 검증된 설정을 저장하고, 반복 작업에 재사용하며, 여러 모델에 동일한 규칙을 적용하는 역할을 한다.   스크립트 레코딩으로 첫 번째 자동화 만들기 HEEDS MDO Help의 ‘Scripting with Simcenter HEEDS’ 절에서는 GUI에서 수행하는 작업을 파이썬 스크립트로 기록하는 방법을 설명한다. File 탭에서 ‘Record new script’를 선택하고 작업을 수행하면, 대부분의 명령이 파이썬 코드로 기록된다. 작업을 마친 뒤 ‘Stop recording’을 선택하면 기록된 스크립트를 저장할 수 있다.   그림 1. 스크립트 레코딩(Script Recording) 기능 위치   그림 2. 스크립트 레코딩 기능 위치   기록된 스크립트는 HEEDS 파이썬 API를 학습하기 위한 출발점으로 사용할 수 있다. GUI에서 한 동작씩 수행한 결과가 코드로 나타나기 때문에, 어떤 객체가 생성되고 어떤 속성이 변경되는지 확인하기 쉽다. 다만 녹화된 코드는 GUI에서 수행한 순차적인 동작을 그대로 반영하므로, 최종 자동화용으로는 불필요한 명령을 정리하고 여러 속성을 한 번에 설정하는 과정이 필요하다.   그림 3. 스크립트 레코딩 및 파이썬 코드 예시   <그림 3>의 예시는 GUI 작업을 기록한 스크립트가 단순한 매크로에 머무르지 않고, 파이썬에서 임포트(import)하여 재사용할 수 있는 함수 구조로도 작성될 수 있음을 보여준다. 따라서 다음과 같은 방식으로 스크립트를 발전시킬 수 있다. 첫 번째 단계 : GUI 작업을 기록하여 API 사용법을 확인한다. 두 번째 단계 : 프로젝트 경로와 파일 이름을 변수로 분리한다. 세 번째 단계 : 반복되는 설정을 함수로 묶는다. 네 번째 단계 : 프로젝트 구성 후 오류 검사를 추가한다. 다섯 번째 단계 : 프로젝트 저장, 실행, 리포트 생성까지 연결한다.     ■ 자세한 기사 내용은 PDF로 제공됩니다.

도구의 시대를 지나 운영 모델의 시대로   디지털과 현실을 잇고 아이디어를 실제 가치로 구현하는 방식, 오토데스크가 말하는 ‘디자인 & 메이크(Design & Make)’다. 7월 15일에 열린 ‘오토데스크 디자인 & 메이크 서밋 코리아 2026’은 그 진화를 이끄는 세 개의 키워드(데이터, AI, 컨버전스) 를 축으로 구성되었다. 기조연설로 문을 열고, 세 곳의 고객 성공 사례가 이어졌으며, 오토데스크 코리아의 AI 세션으로 마무리되는 하루였다. 필자가 이날 현장에서 받은 인상을 한 문장으로 요약하면 이렇다. “지난해가 ‘어떤 도구를 써야 하나’로 우왕좌왕하던 시기였다면, 올해의 화두는 ‘어떤 데이터를 어떤 거버넌스로 다룰 것인가’로 옮겨 갔다.” 마지막 세션에서 오토데스크코리아의 정태승 박사가 던진 이 진단은 사실 그날 발표자 대부분이 서로 다른 언어로 반복한 말이기도 했다. 도구(BIM)는 이미 전제가 되었고, 승부처는 그 위에 쌓이는 데이터와 그것을 운영하는 방식으로 넘어가고 있었다.   ▲ 오토데스크 디자인 & 메이크 서밋 코리아 2026 현장   기조연설 — 새로운 청사진, 그리고 모두를 위한 디자인 이번 행사의 기조연설은 오토데스크의 켄 푸(Ken Foo) 전략 파트너십 부사장이 맡았다. ‘The New Blueprint : Data, AI, and Convergence’라는 제목처럼, 데이터·AI·산업 융합이 기업의 운영 방식을 어떻게 재편하는지를 조망했다. 프로젝트는 갈 수록 복잡해지고 수익성 압박은 커지는데, 연결된 데이터와 플랫폼, 그리고 워크플로에 내장된 AI가 의사결정과 리스크 관리, 업무의 예측 가능성, 효율과 품질, 나아가 혁신을 어떻게 끌어올릴 수 있는지가 핵심 메시지였다. 고객 기조연설은 현대자동차 제네시스의 송지현 실장과 이준호 책임연구원이 ‘Nanomobility – Design for All’을 주제로 진행했다. 이동약자와 도시의 이동 문제에서 출발한 나노 모빌리티가 포용적 디자인과 제품 혁신으로 발전하고, 오토데스크 설루션 기반의 워크플로를 통해 더 가볍고 강하며 제조 가능한 구조로 구현된 과정을 소개했다. 현대자동차 제네시스의 나노 모빌리티 사례는 ‘디자인’ 과 ‘메이크’가 하나의 흐름으로 이어지는 구체적인 예시였다.   고객 성공 사례 세 편 — 다른 출발점, 같은 결론 GS건설, 간삼건축, 삼우종합건축사사무소가 연달아 무대에 올라 각자의 현실적인 고민과 시도를 공유했다.   GS건설 — CDE로 ‘흩어진 정보’를 연결하다 GS건설 디지털건설팀의 조재영 팀장은 아주 현실적인 질문으로 발표를 열었다. ‘현장에서 최신 정보를 확인하려면 몇 개의 시스템을 뒤져야 할까?’ 도면은 도면 시스템에, BIM은 별도 서버나 담당자 PC에, 이슈는 메신저와 메일에, 검측 서류는 개인 PC와 휴대전화에 흩어져 있다. 정보가 없는 게 아니라, 서로 연결되어 있지 않다는 것이 문제다. 그 결과 무엇이 최종본이고 기준인지 확인하는 데만 많은 시간이 든다. 그 해법으로 제시된 것이 CDE(Common Data Environment, 공통 데이터 환경)다. 조 팀장은 CDE가 원드라이브 같은 단순 저장소가 아니라는 점을 강조했다. 최신 도면과 BIM, 시방, 이슈, 검측 사진 같은 ‘승인 정보’를 하나의 업무 흐름으로 연결하는 프로젝트 협업 공간이라는 것이다. 모든 참여자가 같은 승인 정보를 기준으로 일하고, 변경·검토·조치 과정이 기록되므로, 문제가 생겼을 때 누가 언제 어떤 정보를 기준으로 판단했는지 추적할 수 있다. 글로벌 건설사의 정보 관리는 파일 저장에서 출발해 사내 서버·EDMS를 거쳐, 영국발 정보 관리 기준(ISO 19650)이 확산되면서 상용 협업 플랫폼으로, 다시 클라우드·모바일 환경으로 발전해 왔다. 지금은 CDE를 PMS·ERP·데이터 레이크·AI와 연결해 전사 데이터 기반으로 확장하는 단계라는 설명이다. 특히 인상적이었던 것은 CDE와 ‘AI 도면 시스템’의 역할을 분명히 구분한 대목이었다. CDE가 답해야 할 질문은 “어떤 도면이 최신 승인본인가”(버전·승인 권한·배포·감사 이력)이고, AI 도면 시스템의 질문은 “이 도면에서 무엇을 찾고 분석할 수 있는가”(검색·비교·요약·오류 후보 탐지)다. 만약 AI 시스템이 승인·배포·버전 관리까지 떠안으면 사실상 또 하나의 CDE를 자체 개발·운영하는 부담을 지게 된다. 공식 기준 정보는 CDE가 관리하고, AI는 그 위에서 검토하는 구조가 바람직하다는 것이다. CDE 선택 기준으로는 여덟 가지 항목이 제시되었다. ISO 19650 기반 정보 관리 적합성 : 작성 중/공유/승인/보관 등 정보 상태 구분, 명명 규칙·고유 ID·메타데이터, 버전·워크플로·감사 추적·아카이브 도면 관리 : DWG·DGN·PDF 등 원본 형식과 외부 참조(Xref) 지원, 시트 단위 관리, OCR 속성 추출, 개정 전후 비교·마크업 BIM 지원 : 레빗(Revit)·나비스웍스(Navisworks)·IFC 등 주요 모델 조회, 건축·구조·설비 통합 검토, 간섭·설계 변경을 이슈로 전환 모바일 사용성 : 지하층·통신 음영 구간에서도 도면 확인, 이슈·체크리스트·사진을 도면 위치에 바로 연결 권한·보안 : 역할·폴더·문서 상태별 권한 구분, 인증·저장 위치·활동 로그 API·데이터 연계성 : PMS·공정·ERP·자재·원가·드론·레이저 스캔 연결, 데이터 레이크·AI 분석 활용 도입·표준화 용이성 : 표준 폴더·권한·워크플로 템플릿화, 한국어 지원, 국내 기술 지원, 확산성 비용·벤더 리스크 : 초기 구축비 외 라이선스·스토리지·교육·운영을 포함한 장기 총비용, 종료 시 데이터 반출과 종속성 조 팀장은 이 여덟 가지를 결국 세 개의 질문으로 압축했다. 공식 기준 정보를 제대로 관리할 수 있는가, 현장에서 실제로 쓸 수 있는가, 회사 시스템과 연계해 장기적으로 운영할 수 있는가. 이 조건을 폭넓게 충족하는 설루션은 많지 않은데, 오토데스크 포마(Forma)가 그 몇 안 되는 선택지에 든다는 것이 결론이었다. BIM 360과 컨스트럭션 클라우드(Construction Cloud, ACC)를 거쳐 지금은 포마를 중심으로 계획·설계·시공 데이터를 잇는 방향으로 발전하고 있고, 그 중심에 도면·문서·모델을 다루는 데이터 매니지먼트가 있으며 그 위에 Collaborate·Build·Takeoff와 초기 계획 기능이 얹힌다. 실제 적용 사례도 구체적이었다. 통도면을 시트 단위로 전환하면 변경된 도면만 새 버전으로 등록되고 개정 전후 비교가 가능해진다. 부담이 되던 통도면 분할은 GS건설이 AI OCR로 도면번호· 도면명을 인식해 자동 분할하는 웹 도구를 자체 개발해 써 왔는데, 최근에는 포마의 페이지·속성 추출 기능으로도 처리할 수 있게 되었다. 다만 잘못 인식된 정보가 그대로 기준이 되지 않도록 최종 검수는 반드시 필요하다는 단서를 달았다. 이 밖에 웹·태블릿에서의 BIM 접근, 도면·모델의 정확한 위치에 이슈를 등록하고 담당자·기한·상태를 지정하는 기능, 그리고 검측 서류의 준비·출력·제출 과정을 통째로 없앤 모바일 검측 사례가 소개되었다. 철근 검측 자동화(도면 속 부재명을 AI가 인식해 구조 일람과 연결)는 아직 개발 중이라고 밝혔다. 마지막으로 포마와 MCP(모델 콘텍스트 프로토콜)를 연결한 확장 실험을 공유했다. CDE의 도면·BIM·공정표·현장 데이터를 API로 LLM(대규모 언어 모델)에 연결해, 자연어로 특정 층 물량을 조회해 보고서로 받거나, 공정표 기반 CP(주공정) 분석, 구조 부재 Takeoff의 엑셀 내보내기, BIM 모델 기반 작업 위험 검토를 시험해 본 결과다. 최근 한글 지원이 개선되었고, 국가건설공사 표준시방·LH·도로·철도 등 국내 기준이 반영되면 활용도가 더 높아질 것이라는 기대도 덧붙였다. 조 팀장의 결론은 명료했다. “CDE는 하나의 시스템을 도입하는 것이 아니라, 프로젝트 구성원이 같은 정보를 기준으로 일하게 만드는 변화다.”   ▲ GS건설 조재영 팀장의 CDE·포마 적용 발표   ▲ GS건설 발표 인포그래픽(필자 생성 by Gemini)   간삼건축 — 데이터 자산화가 가져올 미래 간삼건축 이혁 INNOVATION 부문 대표의 발표는 세 사례 중 가장 서사적이고 성찰적이었다. 2008년 간삼건축에 합류해 십 수 년간 프로세스 효율화와 인적 자산 관리를 고민해 온 그는, “여전히 진행 중이고 실험적인 이야기”라며 담담하게 자사의 시행착오를 풀어놓았다. 출발은 2023년의 한 경험이었다. 연말에 급하게 작은 오피스를 호텔로 리모델링하는 기획설계를 맡게 되었는데, 유튜브에서 본 3D 모델링 기반 AI 렌더링을 처음 시도했다. 금요일 오전 세 시간 모델링, 오후엔 BIM 팀원과 함께 손을 보고, 두 시간 만에 50여 장의 이미지를 얻었다. 주말을 거쳐 결국 둘이서 14시간 만에 보고서를 완성했다. 그가 놀란 것은 이미지 품질이 아니라, ‘AI를 쓰면 우리 프로세스를 이렇게 압축할 수 있구나’라는 사실이었다. CAD와 스케치업이 각각 도면과 모델만 다루는 ‘반쪽짜리’라면, 라이노(Rhino)와 레빗으로 옮겨 모델링이 도면으로 직접 이어지고 AI로 이미지를 얻는 세상이 가능하다는 것. 그래서 그는 “AI를 잘 쓰려면 툴 자체가 바뀌어야 한다”고 말하며, “세상은 데이터로 넘어가고 있었다”고 덧붙였다. 간삼은 지난 5년간 여러 조치를 빠르게 진행했다. BIM 교육 동영상 배포, 전사 BIM 능력시험, CAD 허가제, 템플릿 개정, 파라메트릭 팀 신설, 연 10여 회의 AI 세미나. 그러나 그는 생텍쥐페리의 어린 왕자를 빌려 조직의 저항을 유쾌하게 꼬집었다. 어린 왕자가 지구에 오기까지 거친 여섯 별의 어른들이 회사에 다 있다는 것이다. 정작 본인은 하지 않으면서 아랫사람에게만 BIM을 시키는 사람, 끊임없이 허점만 지적하는 사람, “난 CAD가 BIM보다 빠르다”고 버티는 시니어 — 자전거를 빨리 타서 자동차를 이기겠다는 이들 — 와 매일 씨름한다고 했다. 그럼에도 ‘바오밥 나무를 뽑겠다’는 일념으로 만든 것이 ‘팀31’ 이다. 기존 BIM 매니저 팀에 건축 설계 시니어를 붙인 조직으로, 목표는 SD(계획설계) 종료 시점에 실시설계 도서 총량의 30%를 확보하는 것. 도면 총량 30%에 도면당 완성률 60%를 곱하면 18이라 원래 이름은 ‘T18’이었는데, 직관적인 ‘팀31’로 바꿨다는 뒷 이야기가 웃음을 자아냈다. 설계팀 한 명과 팀31 두 명을 짝지어 올해 이미 12개 프로젝트에서 SD 종료 시 40~45%까지 도면을 만들어 내고 있고, 회사 기준으로 전체 설계 효율을 약 6% 올릴 것으로 기대한다고 했다. 자산화 도구도 촘촘했다. 클라우드 협업 보드 미로(Miro)에 계약·목표와 SD 30% 분량의 도면 150여 장을 올려 피드백을 공유하고, 포마에는 간삼의 매스 자산을 허브에 DB처럼 올려 쓰며(파트너사 상상진화의 Forma Box로 초기 계획을 압축), 환경 분석은 라이노의 그래스호퍼(Grasshopper)보다 간편하다고 평가했다. 이미 2차 교육을 마쳤고 8월 중순 3차 교육 후 전면 적용할 계획이다. 오토데스크의 콘텐트 카탈로그(Content Catalog)로는 엘리베이터의 모든 사양에 이름을 붙여 클라우드에 올려 파라미터 조정 없이 선택·삽입하게 했고, 한 걸음 더 나아가 방풍실·병실·계단실·화장실 등 패밀리 조합을 블록으로 저장했다. 여기에 자체 개발한 디테일 DB는 1/50·1/60 도면을 함께 연동하고, 그 디테일을 언제 써야 하는지·주의점은 무엇인지에 대한 경험자의 설명과 별점·좋아요까지 붙였다. 이 대표는 아키텍트 펌의 기술을 ‘감자 이야기’에 비유했다. 1500년대 유럽에 감자가 퍼졌지만 사람들은 ‘악마의 식물’이라며 먹지 않았고, 1700년대 대기근 때에도 감자를 두고 굶어 죽었다. 1800년대 보급 이후 인구가 폭발했지만, 작황 좋은 한 품종만 심은 탓에 감자 마름병(역병)이 창궐하자 아일랜드에서만 150만이 아사했다. ‘안 먹어서 죽고, 그것만 먹어서 죽는다’는 이 우화를, 이 대표는 AI에 그대로 겹쳤다. 쓰지 않으면 뒤처지고, 특정 방식만 맹신하면 위험하다는 것. 실제로 지금 설계실을 들여다보면 절반은 PPT를, 절반은 AI를 쓰고 있는데, 도면 없이 화려한 겉모습만 남는 상태를 그는 오히려 경계했다. 지식 자산화의 진짜 벽은 기술이 아니라 사람과 세대였다. ‘내 자산인데 왜 회사에 내놔야 하느냐’는 물음은, 이 대표가 보기엔 도제식 문화의 방어 심리로서 나름 합리적이다. 아키텍트 펌은 사람을 자산처럼 다뤄 왔지만, 그 자산은 회계장부에 잡히지 않고 복제·확장·승계도 안 되며 사람이 떠나면 함께 사라진다. 동료의 피드백을 거치지 않은 개인 자산은 품질도 낮다. 결과의 공정성보다 과정의 공정성을 중시하는 MZ 세대는 회사의 지시를 맹목적으로 따르지 않는다. 그래서 그가 내린 결론은, 개인의 가치를 ‘추출’해 회사 가치로 만드는 구조에서 벗어나, 개인이 자신의 가치를 내어놓고 서로 교환하며 성장하는 ‘마당(커뮤니티)’을 만드는 것이다. 성과에는 ‘OO의 리포트’, ‘OO의 LISP’, ‘OO의 AI 디자인’처럼 이름을 붙여 인정한다. TFT로 만든 ‘모두가 만드는 플랫폼’은 이미 베타를 열었고 9월 초 정식 오픈을 앞두고 있다. 특히 간삼건축 이혁 부문 대표의 마지막 말은 이날 여러 발표가 향하고 있던 방향을 가장 명확하게 요약했다. “BIM을 시작으로 AI와 클라우드까지, 단순히 도구를 바꾸는 것만으로는 혁신이 안 되겠다는 생각이 들기 시작했다.”   ▲ 간삼건축 이혁 부문 대표의 ‘데이터 자산화’ 발표   ▲ 간삼건축 발표 인포그래픽(필자 생성 by Gemini)   삼우건축 — DX부터 AX까지 삼우건축 AX팀의 윤종근 프로는 삼우가 BIM 기반 설계 체계에서 출발해 DX(디지털 전환)를 거쳐 AX(AI 전환) 운영 모델로 이동한 여정을 단계별로 정리했다. 그는 이 여정을 새로운 기술의 도입이 아니라, “설계자가 문제를 더 빠르게 정의하고 AI·클라우드로 해결하며 그 결과를 조직의 자산으로 축적하는 새로운 업무 방식”으로 규정했다. 시작은 BIM이었다. 삼우는 2016년부터 전면 BIM을 수행하며 BIM을 조직의 ‘설계 기준’으로 만들었다. 전 직원 BIM 역량 평가, CAD 표준과 수행 경험·자동화 속성을 반영한 표준 템플릿, 반복 업무를 시스템화한 삼우 BIM 익스텐션, 2018년 건축·구조 표준 모델과 도면 기준, 2019년 설계 단계별 권장 모델이 그것이다. 핵심은 ‘BIM을 썼다’가 아니라, 설계 기준과 노하우·모델·도면 작성 방식을 디지털 자산으로 축적했다는 점이다. DX 단계의 목표는 본업 경쟁력 강화였다. AutoDrawings로 도면·시트 작성을, 창호·입면도 자동화로 뷰 생성·주석·시트 배치를 자동화했고, 구조 모델링과 일람표, 실내 마감표, 룸 데이터 시트(문서의 실 정보와 레빗 모델 정보를 연동)로 확장했다. 방식은 기술 부서가 현업의 문제를 수집·분석해 개발·배포·교육하고 현업이 적용하는 구조였다. 초기 성과는 분명했지만 한계도 뚜렷했다. 자동화 수요는 느는데 개발 인력은 제한적이고, 기능을 만들어도 실제 활용까지 이어지지 못했으며, 현업은 어떤 기능이 언제 있는지조차 알기 어려웠다. 질문은 ‘무엇을 더 자동화할 것인가’에서 ‘어떻게 더 잘 활용할 것인가’, 나아가 ‘누가 문제를 정의하고 해결에 참여할 것인가’로 바뀌었다. 이에 대한 두 갈래의 시도가 이어졌다. 하나는 사내 플랫폼 ‘DX 가이드맵’으로, 이미 만든 자동화 기능을 현업이 쉽게 찾아 적용하도록 연결했다. 이때 기술 부서의 역할이 ‘만드는 생산자’에서 ‘환경을 제공하는 프로바이더’로 분화된 것이 중요한 변화였다. 다른 하나는 2024년의 생성형 AI 공모전으로, 현업이 직접 문제를 정의하기 시작했다. 이미지 생성·데이터 분석·시각화 등 다양한 유스케이스가 나왔지만, 개인 역량에 의존한 방식은 회사 전체로 확산되기 어렵다는 한계도 함께 확인했다. 공모전에서 나온 아이디어가 기술 검증(PoC)과 사용성 개선을 거쳐 사내 이미지 생성 AI 서비스 ‘미지’로 발전한 것은, 문제 정의의 출발점이 기술 부서에서 현업으로 옮겨 간 상징적 사례였다. 전환점은 2025년의 APS 도면 자동화 프로젝트였다. 오토데스크 플랫폼 서비스(APS)와 포마를 기반으로 PDF 출도의 반복 업무를 자동화해, 대형 프로젝트에서 하루가 걸리던 작업을 30분으로 줄였다. 그러나 윤 프로가 강조한 진짜 의미는 결과가 아니라 ‘개발 방식’에 있었다. AI와 협업하면서 기술 학습·코드 작성·오류 개선의 속도가 달라졌고, AI가 단순 보조 도구가 아니라 개발 과정을 함께 푸는 파트너로 작동했다는 것이다. 그는 이 프로젝트를 “DX 방식으로 시작했지만 AX 방식으로 완성한 첫 프로젝트”이자 DX에서 AX로 넘어가는 터닝 포인트로 규정했다. 이 가능성을 공식 운영 모델로 구조화한 것이 삼우 AI 프레임워크, 이른바 ‘사이프(CYPHE)’다. 핵심은 AI 활용을 개인의 실험에 머무르게 하지 않는 것이다. 사이프는 세 관점으로 요약된다. 첫째, 고객과 회사의 정보를 안전하게 지키면서 AI를 강력하게 쓰는 표준 환경을 구축한다. 둘째, 특정 업무 목적에 맞는 AI 활용을 검증·지원하는 구조를 세운다. 셋째, 실제 업무 변화와 성과를 조직 차원에서 인정하고 확산한다. AI 활용의 기본값을 ‘보안 안에서의 활용’으로 바꾸고, 개인의 시도를 조직의 활용으로 전환하는 것이다. 여기에 유스케이스 등록과 인센티브·교육·멘토링으로 이어지는 성장 구조를 얹었다. 현업이 문제를 발굴하면 AX팀이 기술과 보안을 연결해 구체화하고, 현업의 오너십을 유지한 채 거버넌스와 파트너 리소스를 붙인다. 오토데스크 설루션과 연결성이 높은 케이스는 APS·포마 기반으로 더 확장된 업무 전환 모델로 발전시키며, 최근에는 오토데스크와 공동으로 AX 워크숍을 마쳤다고 밝혔다. 결론은 이랬다. “삼우의 AX는 AI 서비스를 도입한 결과가 아니라, 조직이 일하는 방식을 바꾸는 과정이다. BIM이 설계 데이터를 만들었고, 자동화가 프로세스를 바꿨으며, AI와 클라우드는 문제 해결의 주체와 방식을 확장하고 있다.”   ▲ 삼우건축 윤종근 프로의 ‘DX to AX’ 여정 발표   ▲ 삼우건축 발표 인포그래픽(필자 생성 by Gemini)   오토데스크 AI로 여는 업무 혁신 마무리 세션은 오토데스크코리아의 정태승 박사와 성진호 수석이 맡았다. 고객들이 저마다의 방식으로 AI를 쓰는 모습을 본 뒤, ‘그렇다면 오토데스크는 AI를 어떻게 생각하는가’를 짚는 자리였다.   AEC 관점 — 데이터 교환 모델과 포마, 그리고 어시스턴트의 현주소 정 박사는 오토데스크의 토대로 ‘데이터 교환(data exchange) 모델’을 먼저 꺼냈다. 한 프로젝트에서 수많은 소프트웨어가 쓰이지만 모든 데이터가 한곳에 모일 필요는 없고, 각 모델에서 필요한 부분만 상호 교환되도록 하는 것이 요체다. 이 기반 위에서 다양한 소프트웨어가 운영되는 베이스라인 플랫폼이 바로 포마이며, 이것이 오토데스크가 그리는 생태계라는 설명이다. 흥미로운 것은 ‘이미지에서 공간으로’라는 방향이었다. 같은 프롬프트로 이미지를 만드는 것을 넘어 3차원 ‘공간’을 생성하는 기술에 지속 투자하고 있으며, “공간이 다음 세대의 표준이 될 것”이라고 내다봤다. 현주소에 대해서는 솔직했다. 아직 목적 지향의 ‘에이전트’ 단계까지는 아니며, 현재는 ‘어시스턴트’ 수준이라는 것이다. 반복 작업 자동화, 정보 분석, 그리고 내가 잘 모르는 기능의 의사결정 지원이 지금의 몫이다. 제품별로는 사이트 디자인(Site Design)과 올해 출시하는 빌딩 디자인(Building Design)이 소개되었는데, 웹에서 여러 사람이 함께 작업하고 파사드뿐 아니라 개별 실 단위까지 적용하며 그 데이터가 레빗으로 바로 넘어가는 흐름이 강조되었다. AutoCAD에서는 "보여줘/찾아줘/표준을 검토해 줘" 같은 문구로 QA·QC와 도움말을 어시스턴트가 처리하고, 포마(구 ACC)에서는 RFI 등 정해진 정보를 '필터'처럼 자연어로 조회·검토할 수 있다. 특히 공식 레빗 MCP 서버(베타)를 클로드와 약 1분 만에 연결해, 레빗을 열어 두고 문(door)에 대한 대시보드·일람을 3분 남짓에 만들어 내는 시연이 눈길을 끌었다.   D&M 관점 — 퓨전과 클로드(MCP)로 ‘의도’를 전달하다 이어 성진호 수석은 제조(Design & Make) 영역을 맡아, 퓨전(Fusion)과 AI의 결합을 직접 테스트한 결과를 공유했다. 그는 “본사 발표 자료가 아니라 제가 직접 돌려 본 내용”이라고 전제했다. 퓨전의 오토데스크 어시스턴트(Autodesk Assistant)는 같은 모깎기(R) 형상을 한 번에 선택·편집하거나, 마이크로소프트와 협력한 이미지 렌더링, 오픈 API를 활용한 엔지니어링 앱 개발·배포를 지원한다. 제조 및 기계 설계 분야(DNN)를 담당한 성진호 수석의 오토데스크 퓨전 시연 역시 놀라웠다. 퓨전이 앤트로픽의 MCP 표준을 사용하기 때문에 클로드가 이질감 없이 붙어 명령 수행은 물론 결과를 스크린샷으로 분석하고 커뮤니케이션한다. 심플한 의자를 3D로 모델링하면 여섯 개의 골체가 배치되고 치수가 파라미터로 등록되며 BOM까지 자동 작성됐다. STL 메시를 솔리드로 변환하는 작업, 이미지를 주고 네 번의 피드백으로 원하는 형상을 얻는 과정도 시연됐다. 한 걸음 더 나아간 것은 ‘에이전트 협업’이었다. 에이전트 1이 제조를 전제로 한 지침(컨텍스트 약 100줄)을 만들고, 에이전트 2가 그에 맞춰 MCP 서버로 구현하는 방식이다. 이렇게 하면 펼쳐지는 구조의 의자가 제조 가능한 모델로 만들어지고, 관절이 연결된 로봇이 한 시간이 채 안 되어 생성되며, CNC 가공을 위한 툴패스도 만들어진다. 룰 베이스 CAM을 넘어, 가공되지 않는 영역을 피드백으로 알려 주면 공구 길이와 이송 속도를 스스로 조정하고 기가공 영역을 제외해 자동으로 연결하는 모습이 인상적이었다. 2D 도면을 3D로 변환하는 것은 아직 어렵지만, 규칙을 분석할 수 있는 도면이라면 구현이 가능하다고 했다. 성 수석의 결론은 한 문장으로 압축된다. “설계 개념이 ‘소프트웨어 조작’에서 '의도의 전달’로 넘어가고 있다.”   정리 — 데이터 자산화, 적합성 정의, 거버넌스 마지막으로 정 박사는 고객 사례와 겹치는 결론을 세 가지로 정리했다. 첫째, 데이터가 자산화되어야 한다. 둘째, 지금 하는 일이 그 모델로서 적합한가에 대한 정의가 필요하다. 셋째, 조직이 어떤 거버넌스로 이를 운영할 것인가가 정리되어야 한다. 그는 “AX는 결국 운영 모델을 설계하는 것”이라며, 무엇을 쓰고 어떻게 절차를 만들지, 그리고 “누군가는 책임을 져야 한다”는 점을 강조했다. 대부분의 문제가 책임을 지지 않으려는 데서 생긴다는 뼈 있는 말이었다.   ▲ 오토데스크코리아 정태승 박사의 오토데스크 AI 세션   ▲ 오토데스크 코리아 발표 인포그래픽(필자 생성 by Gemini)   필자의 시선 — 도구는 이미 전제, 승부는 데이터와 거버넌스 하루를 되짚어 보면, 네 개의 발표가 서로 다른 언어로 같은 말을 하고 있었다. GS건설은 ‘CDE와 역할 분리’로, 간삼건축은 ‘감자 우화와 지식 자산화’로, 삼우건축은 ‘사이프와 유스케이스 성장 구조’로, 그리고 오토데스크는 ‘데이터 교환 모델과 데이터·거버넌스’로. 표현은 달라도 지향점은 하나였다. BIM 같은 도구는 이미 전제가 되었고, 승부처는 그 위에 쌓이는 데이터를 어떻게 자산화하고, 개인의 AI 활용을 어떻게 조직의 자산으로 전환하느냐로 넘어가 있다는 것. 필자는 이 흐름이 개인 차원의 오래된 교훈과 맞닿아 있다고 본다. AI가 아무리 훌륭한 대안을 제시해도, 최종 판단은 도메인 지식을 가진 사람의 몫이다. 도구는 이미 민주화되었다. 이날 진행을 맡은 사회자가 훈민정음을 빗대어 “누구나 읽고 쓸 수 있다는 것은 지식의 민주화이고, 지금 AI가 바로 그렇다”고 한 것처럼, 이제 관건은 무엇을(도메인) 어떻게(프롬프트와 거버넌스) 시킬 것인가다. 개인 차원에서 ‘일머리’라 부르던 능력이, 조직 차원에서는 ‘데이터 자산화와 거버넌스’라는 이름으로 확장된 셈이다. 특히 “AX는 운영 모델을 설계하는 것”이고 “누군가는 책임을 져야 한다”는 말은, 화려한 AI 시연 사이에서 가장 오래 남는 문장이었다. 결국 도구를 바꾸는 것만으로 혁신은 오지 않는다. 어떤 데이터를 신뢰할 수 있는 기준으로 삼고, 누가 그것을 책임지며, 개인의 성과를 조직의 자산으로 어떻게 축적할 것인가 — 이 질문에 답하는 조직이 다음 단계로 나아갈 것이다.   ▲ 오토데스크 디자인&서밋 코리아 2026 핵심 메시지 인포그래픽(필자 생성 by Gemini)   맺음말 이번 서밋은 신기술의 전시가 아니라, 그 기술을 ‘어떻게 운영할 것인가’에 대한 고민의 공유장에 가까웠다. 지금 이 글을 읽고 있는 독자에게 묻고 싶다. 우리 조직은 어떤 데이터를, 어떤 거버넌스로 자산화하고 있는가. 그리고 각자의 자리에서 만들어 내는 AI 결과물은 개인의 실험으로 소모되고 있는가, 아니면 조직의 자산으로 쌓이고 있는가. 아직 답을 다 갖춘 조직은 없다. 모두 “늦은 감이 없지 않다”면서도 멈추지 않고 실험을 이어 가고 있었고, 오토데스크 역시 “내년에는 더 나아간 기술을 소개하겠다”고 약속했다. 내년 이맘때 이 자리에서 한 걸음 더 나아간 사례를 만나 보길 권한다. 도구를 넘어 운영 모델을 고민하기 시작한 조직에게, 올해의 서밋은 좋은 이정표가 되어 줄 것이다.   ■ 양승규 캐드앤그래픽스 전문 필진으로, MOT를 공부하며 엔지니어와 직장인으로 살아가는 방 법에 대해 탐구한다. 건축과 CAD를 좋아한다. (홈페이지)     ■ 기사 내용은 PDF로도 제공됩니다.

디지털 지식전문가 조형식의 지식마당   세계적인 제조업 위기에도 인공지능(AI) 열풍이 불고 있다. 그러나 제조업에서 반도체 분야 말고는 아직은 이익을 내지 못하고 있다. 한국의 제조업은 소프트웨어 중심 전환(SX : Software-Defined Transformation)에 보다 관심을 가져야 된다고 생각한다.   그림 1. 제조업 경쟁력 진화의 함정   제조업은 지금 또 하나의 거대한 전환점에 서 있다. 지난 100여 년 동안 제조업의 경쟁력은 좋은 제품을 얼마나 정밀하고, 빠르고, 저렴하게 생산할 수 있는가에 의해 결정되었다. 설계 역량, 생산 설비, 공정 기술, 품질 관리, 공급망이 기업 경쟁력의 중심이었다. 제품의 가치는 대부분 물리적 하드웨어에 내재되어 있었다. 그러나 AI, 소프트웨어, 클라우드, IoT(사물인터넷), 디지털 트윈, 디지털 스레드가 결합하면서 이러한 전통적 제조업의 공식이 바뀌고 있다.   그림 2. 하드웨어 중심의 성공 공식   앞으로 제조기업의 경쟁력을 결정하는 질문은 단순히 ‘무엇을 잘 만드는가’가 아니다. ‘제품과 공장, 엔지니어링과 서비스를 얼마나 소프트웨어적으로 정의하고 지속적으로 변화시킬 수 있는가’이다. 필자는 이러한 제조업의 구조적 변화를 SX라고 부르고자 한다. SX는 단순한 소프트웨어 도입이나 IT 시스템 구축이 아니다. 제품(product), 공장(factory), 엔지니어링(engineering), 서비스(service), 기업 운영(entERPrise)을 소프트웨어 중심 구조로 다시 정의하는 제조업의 패러다임 전환이다. 전통적인 제조업에서는 하드웨어가 제품을 정의했다. 자동차는 엔진과 차체가 정의했고, 항공기는 기체와 엔진이 정의했으며, 공작기계는 기계 구조와 제어장치가 정의했다. 따라서 경쟁력도 하드웨어 중심이었다.(기계 → 전자 → 소프트웨어 → 데이터 → AI) 그러나 오늘날 제품의 기능과 성능은 점점 소프트웨어에 의해 결정된다. 자동차의 주행 특성, 배터리 관리, 운전자 지원 기능, 인포테인먼트 시스템은 소프트웨어로 변화한다. 산업 장비 역시 소프트웨어 업데이트를 통해 새로운 기능을 추가할 수 있으며, 운영 데이터를 분석하여 고장 가능성을 예측하고 성능을 최적화한다. 결국 제조업의 가치(value) 중심이 하드웨어 가치 → 소프트웨어 가치 → 데이터 가치 → AI 가치로 이동하고 있다. 이것이 SX가 필요한 가장 근본적인 이유다.   그림 3. 소프트웨어 가치   지난 10여 년 동안 제조기업들은 DX(Digital Transformation, 디지털 전환)를 추진했다. ERP, PLM, MES, SCM, IoT, 클라우드, 디지털 트윈, AI 등 다양한 디지털 기술이 도입되었다. 그러나 많은 DX 프로젝트는 기존 프로세스를 디지털화하는 수준에 머물렀다. 종이 문서를 전자문서로 바꾸고, 수작업을 시스템으로 옮기고, 데이터를 클라우드로 이전하는 것만으로 제조업의 본질적인 경쟁 구조가 바뀌지는 않는다. DX가 주로 기존 업무를 디지털 기술로 개선하는 것이었다면 SX는 한 단계 더 나아간다. 제품과 제조 시스템 자체를 소프트웨어적으 로 정의하는 것이다. 따라서 다음과 같이 구분할 수 있다. DX = Digitize the Process SX = Software-Define the Business DX가 디지털화를 의미한다면 SX는 기업 구조 자체의 재정의를 의미한다.   그림 4. 소프트웨어 중심 전환   소프트웨어 중심(software-defined)이라는 개념의 핵심은 단순하다. 물리적 시스템의 기능과 동작을 소프트웨어가 정의하고 변경할 수 있도록 만드는 것이다. 과거에는 기능이 하드웨어에 고정되어 있었다. 제품이 출하되는 순간 기능 역시 거의 확정되었다. 그러나 소프트웨어 중심 제품은 출하된 이후에도 소프트웨어를 통해 기능을 추가하거나 변경할 수 있다. 따라서 제품은 더 이상 완성된 물체가 아니다. 제품 = 하드웨어 + 소프트웨어 + 데이터 + AI + 서비스가 된다. 그리고 더욱 중요한 변화가 발생한다. 제품의 생명주기가 설계(design) → 제조(manufacturing) → 공급(delivery)에서 끝나는 것이 아니라, 설계 → 제조 → 공급 → 운영(operation) → 데이터(data) → 학습(learning) → 업데이트(update)라는 지속적인 순환 구조로 바뀐다. 이것이 소프트웨어 정의 제조업의 본질이다. 소프트웨어 중심 자동차(Software-Defined Vehicle : SDV)는 자동차 산업에서 가장 빠르게 나타나고 있는 소프트웨어 중심 전환이다. 그러나 소프트웨어 중심 개념은 자동차에 국한되지 않는다. 앞으로 제조업에서는 다음과 같은 구조가 확대될 것이다. Software-Defined Product : 제품의 기능과 성능을 소프트웨어가 정의한다. Software-Defined Vehicle : 자동차의 기능과 사용자 경험을 소프트웨어가 지속적으로 변화시킨다. Software-Defined Machine : 산업기계의 동작과 성능이 소프트웨어와 AI에 의해 최적화된다. Software-Defined Factory : 공장의 생산능력과 운영방식이 소프트웨어를 통해 동적으로 재구성된다. Software-Defined Engineering : 설계·해석·검증 프로세스가 모델, 소프트웨어와 AI 중심으로 변화한다. Software-Defined EntERPrise : 기업의 업무 프로세스와 의사결정 구조가 소프트웨어, 데이터와 AI를 중심으로 운영된다. 따라서 SX는 개별 제품의 변화가 아니다. 제품 → 엔지니어링 → 제조 → 서비스 → 엔터프라이즈 전체를 연결하는 제조업의 구조적 전환이다.   그림 5. 소프트웨어 중심의 구조적 전환   SX를 구현하기 위해 가장 중요한 기반 가운데 하나가 디지털 스레드(digital thread)다. 제조기업에는 이미 많은 시스템이 존재한다. CAD, CAE, PLM, ERP, MES, SCM, IoT, QMS, CRM 등이다. 문제는 시스템이 부족한 것이 아니다. 데이터와 맥락이 서로 단절되어 있다는 것이다. 설계 데이터와 생산 데이터가 분리되어 있고, 생산 데이터와 품질 데이터가 연결되지 않으며, 운영 데이터가 다시 설계로 돌아오지 않는 경우가 많다. 디지털 스레드는 이러한 단절을 연결한다.   그림 6. 새로운 생명주기의 시작   이렇게 제품의 전 생애주기 정보를 연결하면 소프트웨어 중심 제조업이 작동할 수 있는 데이터 기반이 만들어진다. 따라서 필자는 SX를 다음과 같이 표현하고 싶다. SX = 소프트웨어 중심 아키텍처 + 디지털 스레드 + 디지털 트윈 + AI  디지털 스레드가 정보를 연결하는 구조라면 디지털 트윈은 그 정보를 활용하여 현실 세계를 모델링하고 시뮬레이션하는 공간이다. 물리적 제품과 디지털 제품이 연결되고, 물리적 공장과 디지털 공장이 연결된다. 그리고 현실에서 발생하는 데이터가 디지털 트윈으로 전달된다. 물리적 요소 → 데이터 → 디지털 트윈 → 시뮬레이션 → AI → 의사결정 → 물리적 요소의 순환구조가 만들어지면 제조 시스템은 단순 자동화를 넘어 지속적으로 학습하고 최적화되는 시스템으로 발전한다. 과거의 디지털 트윈이 물리적 자산을 복제하는 개념에 가까웠다면, 앞으로의 디지털 트윈은 점차 의사결정을 지원하고 실행하는 지능형 운영 모델로 발전할 것이다. SX의 다음 단계에서 가장 중요한 변화는 AI다. 기존 소프트웨어는 사람이 정의한 규칙에 따라 움직였다. 그러나 AI가 결합된 소프트웨어 중심 시스템은 데이터를 분석하고 패턴을 발견하며 상황에 따라 의사결정을 지원하거나 일부 의사결정을 자동화한다. 여기에 생성형 AI와 AI 에이전트가 결합하면 또 다른 변화가 시작된다. 앞으로 엔지니어는 모든 시스템을 직접 조작하는 대신 AI 에이전트에게 목표를 제시하고, 필요한 데이터를 검색하게 하며, 시뮬레이션과 분석을 수행하도록 할 수 있다. 즉, 소프트웨어 중심 제조(software-defined manufacturing)에서 AI 중심 제조(AI-defined manufacturing)로 발전할 가능성이 커지고 있다. 하드웨어 중심 제조업에서는 경쟁력의 중요한 척도가 생산성이 었다. 얼마나 빨리 만들 수 있는가, 얼마나 싸게 만들 수 있는가, 얼마나 높은 품질로 만들 수 있는가가 중요했다. SX 시대에는 여기에 새로운 경쟁 변수가 추가된다. 얼마나 빠르게 제품과 시스템을 변화시킬 수 있는가? 자동차를 예로 들면, 과거에는 새로운 기능을 제공하려면 새로운 모델을 개발해야 했다. 그러나 소프트웨어 중심 제품에서는 소프트웨어 업데이트를 통해 새로운 기능을 제공할 수 있다. 따라서 경쟁의 단위가 제품 릴리스에서 지속적인 업데이트로 이동한다. 이는 제조업의 시간 개념 자체를 변화시킨다. 과거 제조업의 혁신 주기가 ‘년’이었다면 앞으로는 ‘월’, ‘주’, 경우에 따라 ‘일’ 단위가 될 수 있다. 결국 SX 시대의 핵심 경쟁력은 변화의 속도(change velocity)가 된다.   그림 7. 생산성과 변화의 속도   많은 기업이 ‘데이터가 자산’이라고 이야기한다. 그러나 AI 시대에는 데이터만으로 충분하지 않다. AI가 제조업에서 제대로 작동하려면 데이터의 의미와 관계를 이해해야 한다. 예를 들어 특정 센서 데이터가 어떤 제품의 데이터인지, 어떤 부품에서 발생했는지, 어떤 설계 요구사항과 관계되는지, 어떤 제조공정에서 생산되었는지, 어떤 소프트웨어 버전에서 발생했는지 알아야 한다. 즉 데이터에는 맥락(context)이 필요하다. 이 때문에 앞으로 제조업에서는 온톨로지(ontology)와 지식 그래프(knowledge graph)의 중요성이 더욱 커질 것이다. 데이터 → 정보 → 맥락 → 지식 → 인텔리전스라는 발전구조가 필요하다. 디지털 스레드가 데이터를 연결한다면 온톨로지는 그 연결의 의미를 정의하고, 지식 그래프는 관계를 표현하며, AI는 그 위에서 추론한다. SX의 가장 중요한 의미는 제품의 정의 자체를 바꾸는 데 있다. 과거의 제품은 공장에서 출하되는 순간 거의 완성되었다. 그러나 SX 시대의 제품은 출하가 끝이 아니다. 오히려 출하 이후 새로운 생명주기가 시작된다. 제품은 데이터를 생성하고, 기업은 데이터를 분석하고, AI가 새로운 인사이트를 발견하며, 소프트웨어 업데이트를 통해 제품에 다시 반영한다. 따라서 새로운 제품 생명주기는 다음과 같다. 설계 → 구축(build) → 운영(operate) → 감지(sense) → 학습 → 업데이트 → 진화(evolve). 여기서 중요한 단어는 마지막의 ‘진화’다. 미래의 제조기업은 단순히 제품을 만드는 회사가 아니라 제품을 지속적으로 진화시키는 회사가 될 것이다.   그림 8. 지속적 진화 생태계   제조업의 역사를 길게 바라보면 경쟁력의 중심은 계속 이동해 왔다. 기계화→ 자동화→ 전산화→ 디지털화→ 연결화→ 소프트웨어 중심 → AI 중심. 이 변화 속에서 SX는 단순한 기술 트렌드가 아니다. 그것은 제조기업이 제품을 정의하는 방식, 공장을 운영하는 방식, 엔지니어링을 수행하는 방식, 고객에게 서비스를 제공하는 방식, 그리고 기업 자체를 운영하는 방식을 바꾸는 새로운 제조업 운영체제(manufacturing operating system)라고 할 수 있다. 따라서 SX의 핵심 질문은 ‘우리 회사에 소프트웨어가 얼마나 많이 사용되고 있는가’가 아니다. 진짜 질문은 다음과 같다. ‘우리의 제품과 공장, 엔지니어링과 기업은 얼마나 소프트웨어적으로 정의되고 있는가?’ 그리고 한 단계 더 나아가야 한다. ‘그 소프트웨어 정의 구조 위에서 디지털 스레드, 디지털 트윈, 온톨로지와 AI가 얼마나 유기적으로 연결되어 있는가?’ 필자는 앞으로 제조업의 경쟁 구도가 결국 이 질문에 대한 답에 의해 결정될 것이라고 생각한다. 하드웨어 중심 제조에서 소프트웨어 중심 제조로. 그리고 다시 소프트웨어 중심 제조에서 인공지능 중심 제조로. 이것이 제조업이 직면하고 있는 다음 대전환이며, 바로 SX의 시대다.   ■ 조형식 항공 유체해석(CFD) 엔지니어로 출발하여 프로젝트 관리자 및 컨설턴트를 걸쳐서 디지털 지식 전문가로 활동하고 있다. 현재 디지털지식 연구소 대표와 인더스트리 4.0, MES 강의, 캐드앤그래픽스 CNG 지식교육 방송 사회자 및 컬럼니스트로 활동하고 있다. 보잉, 삼성항공우주연구소, 한국항공(KAI), 지멘스에서 근무했다. 저서로는 ‘ PLM 지식’, ‘서비스공학’, ‘스마트 엔지니어링’, ‘MES’, ‘인더스트리 4.0’ 등이 있다.     ■ 기사 내용은 PDF로도 제공됩니다.

현장에서 얻은 것 No. 26     프롤로그 — 광교의 어느 여름 저녁 2026년 7월 24일, 미래 모빌리티 셀럽 모임 ‘미모셀(MIMOCELL)’의 7월 정모가 열렸다. 장소는 경기도 용인시에 최근 문을 연 ‘더핏(THE PIT)’이었다. 730평 규모의 이 공간은 자동차 튜닝 전문 제조사 네오테크가 만든 첫 번째 직영점이다. 문을 열고 들어서는 순간, 이곳이 단순한 매장이 아니라는 것을 직감했다. 1층과 지하 1층의 플래그십 튜닝 작업장에서는 슈퍼카부터 내수차까지 장착과 세팅, 정비가 원스톱으로 이루어지고 있었고, 쇼룸의 ‘PIT WALL’ 너머로는 고객이 자기 차의 작업 과정을 직접 지켜볼 수 있었다. 카페와 미디어 라운지, 스파르코와 미니 GT가 입점한 MD숍, 파트너 기술 교육장까지 — 제조에서 도매, 소매에 이르는 통합 경험이 한 장소에 구현되어 있었다. ‘PIT’라는 이름은 F1 경주에서 경주차가 타이어를 교체하고 정비를 받는 그 피트에서 왔다. 기술력의 정점이자 세팅의 중심을 상징하는 이름이다. 이준명 대표는 이곳을 “매장이 아닌, 살아있는 레퍼런스(reference store)”라고 불렀다. 현장의 고객 목소리(VOC)가 R&D로 직결되는 기술 허브이자, 해외 바이어에게 ‘이렇게 운영하면 된다’를 실물로 보여주는 글로벌 확장의 실증 엔진이라는 것이다. 이날 저녁, 이 공간의 미디어 라운지에서 필자는 최근 몇 년간 들었던 그 어떤 디지털 전환 강연보다 강렬한 발표를 들었다.   주권을 소유한 제조 브랜드, 네오테크 네오테크는 2006년 7월에 설립된 자동차 튜닝 1세대 기업이다. 경북 김천에 본사와 공장을 두고, 약 50명의 직원이 자동차 애프터마켓용 서스펜션(코일오버)과 고성능 브레이크 시스템(NF 시리즈), 스테빌라이저와 하체 링크류를 개발·생산한다. 부품 개발부터 생산, 품질 검증까지 직접 책임지는 국내 대표 퍼포먼스 섀시 전문 제조사다. 숫자가 이 회사의 궤적을 말해준다. 2025년 매출 101억 원(2024년 96억 원), 2019년부터 2024년까지의 매출 성장률 398%, 전국 800개 이상의 파트너 튜닝샵·정비소 네트워크, 그리고 13개국 수출에 2025년 수출액 약 22억 원. 100억 규모의 중소기업이지만 미국, 캐나다, 호주, 홍콩, 중국 등으로 판로를 넓히며 자동차 튜닝의 세계적 브랜드로 커 나가고 있는 전형적인 강소기업이다. 이준명 대표는 이날 발표에서 네오테크의 정체성을 세 가지 ‘주권’으로 정리했다. 첫째, 브랜드 주권 — 직접 판다. 자사몰과 직영점(THE PIT), 자체 미디어(GridZero)로 고객과 직접 연결되는, 딜러에 의존하지 않는 D2C 구조다. 둘째, 제조 주권 — 직접 만든다. HMLV(다품종 소량) 커스터마이징 제조로 수백 개 차종에 대응하며, 튜닝을 넘어 모빌리티 OE와 방산 섀시까지 같은 공장에서 소화한다. 현대모비스, 오토노머스 A2Z와의 협력이 그 확장의 증거다. 셋째, 운영 주권 — 직접 구축한다. 자체 개발한 MES와 그룹웨어, 그리고 AI 운영체계(AI-SAOS)로 외부 SaaS에 종속되지 않고 데이터·로직·프로세스를 모두 내부 자산으로 소유한다. 가업 승계와 투자 유치, 해외 개척을 차례로 이뤄내고 이제 수도권 광교에 깃발을 꽂은 이 회사의 이야기는 그 자체로 흥미로웠다. 그러나 이날 발표의 진짜 주제는 세 번째 주권, 즉 ‘운영 주권’이 어떻게 만들어졌는가였다.   여러분의 회사입니다. 하지만 여러분의 데이터입니까? 발표의 첫 슬라이드가 스크린에 떠올랐을 때, 장내가 조용해졌다. “여러분의 회사입니다. 하지만 여러분의 데이터입니까?” 이준명 대표는 담담하게 말을 이었다. 그룹웨어, MES, ERP — 우리 회사의 데이터라고 믿고 있는 그 데이터는 사실 설루션 업체의 서버에 있는, 업체를 통해서만 접근 가능한 ‘업체의 데이터’일 뿐이라는 것이다. 화면에는 네오테크에서 각 설루션 업체로 화살표가 뻗어나가고, 그 끝에 데이터가 매달려 있는 다이어그램이 그려져 있었다. 데이터의 주인이 회사가 아니라 설루션이라는, 뒤집힌 구조의 시각화였다. 네오테크의 현실도 다르지 않았다. 근태·메일·전자결재는 다우오피스, 프로젝트 진행과 수주·업무공유는 플로우, 거래명세서와 회계는 이카운트, 생산 현장은 스마트팩토리 지원사업으로 구축한 세아소프트의 커스텀 MES, 그리고 ‘일부’ 자료만 자체 NAS에 저장되어 있었다. 다섯 개의 시스템, 다섯 개의 데이터 섬이었다. “이 다섯 시스템은 과연 융합될 수 있었을까요? 그렇다면 대기업은 왜 자사 시스템을 직접 개발할까요?” 버튼 하나만 옮겨도, API 하나만 요청해도 비용이 발생하고, 새로운 개발 요청은 수천만 원이 든다. 데이터는 각 설루션 회사의 것이고, 결국 직원들이 각 시스템의 데이터를 수작업으로 조합해 대표에게 보고하는 구조가 된다. 이 대표는 “네오테크도 마찬가지였습니다”라고 인정했다. SaaS 구독의 편리함 뒤에 숨어 있는 종속의 구조를 이렇게 정면으로 짚어낸 발표를, 필자는 오랜만에 들었다.   첫 투자를 받은 후 — 대표가 대답하지 못한 질문 전환점은 2025년 7월에 찾아왔다. 네오테크가 첫 투자를 유치한 것이다. 축하할 일이었지만, 그날부터 수시로 들어오는 질문과 보고 요청이 이 대표를 시험대에 올렸다. 거래처별 채권·채무 현황을 실시간으로 볼 수 있는가. 채권 회수 기간은 며칠인가. 평균 납기는 며칠이고, 제품별 납기는 얼마나 차이가 나는가. 외주처의 입고 납기는 평균 얼마나 지연되고 있는가. 누가 회사에서 가장 활발하게 활동하고 있는지, 그 사람이 지금 무슨 일을 하고 있는지 아는가. 이 대표의 고백은 솔직했다. “나는 모든 숫자를 ‘대략’, ‘감으로’ 알고 있었다.” 그리고 청중을 향해 물었다. “노트북 제출 없이, 지 금 이 자리에서 대답할 수 있는 분 계십니까?” 이 질문 앞에서 자유로운 경영자가 몇이나 될까. 20년째 회사를 경영해 온 대표조차 투자자의 기본적인 질문에 즉답할 수 없는 상황 — 이것이 시스템을 다섯 개나 쓰고 있는 중소기업의 실제 모습이었다. 문제는 시스템의 부재가 아니라 데이터 흐름의 단절이었고, 더 근본적으로는 데이터 주권의 부재였다. 필자가 제조기업의 PLM·ERP 혁신 프로젝트 현장에서 늘 마주하는 문제의식과 정확히 같은 지점이었다. 도구는 있다. 그러나 데이터가 흐르지 않고, 흐른다 해도 그 데이터의 주인이 내가 아니다.   바이브 코딩으로 다시 설계하다 — 네오테크의 AI-SAOS 여기서 이준명 대표가 택한 길이 이날 발표의 백미였다. 그는 설루션 업체에 수천만 원짜리 커스터마이징을 요청하는 대신, AI와 함께 직접 만들기 시작했다. 이날 강연의 제목 그대로 ‘바이브 코딩(vibe coding)으로 개발한 네오테크 그룹웨어·MES’였다. 바이브 코딩은 자연어로 의도를 전달하면 AI가 코드를 생성하고, 사람은 방향을 잡고 검증하며 빠르게 반복하는 개발 방식이다. 이 대표는 아이디어에서 서비스 구현까지의 실제 경험과 노하우를 공유했는데, 그 결과물이 놀라웠다. 근태와 전자결재를 담는 그룹웨어, 김천 공장의 생산 현장을 담는 MES, 그리고 이들을 관통하는 AI 운영체계 ‘AI-SAOS’까지 — 흩어져 있던 다섯 개의 데이터 섬이 네오테크 내부 자산으로 통합되어 가고 있었다. 투자자의 질문에 ‘감’이 아니라 데이터로 답하는 경영, 이 대표는 이것을 ‘눈에 보이는 경영’, 투명경영이라고 불렀다. 그리고 이 투명성은 내부 경영에 그치지 않는다. 13개국의 글로벌 바이어들과 함께 성장하려면 회사의 상태를 데이터로 보여줄 수 있어야 하고, THE PIT라는 실증 매장과 자체 구축한 AI 운영체계는 그 신뢰의 인프라가 된다. 제조 강소기업이 브랜드 강화를 넘어 토털 설루션을 만들어 가는 것 — 이것이 글로벌 기업으로 가는 첫 단추라는 생각이 들었다. 발표를 들으며 필자가 특히 주목한 것은 ‘기술 도입’과 ‘업무 혁신’의 차이였다. 많은 기업이 AI를 도입한다. 그러나 네오테크는 AI를 도입한 것이 아니라, AI로 자기 문제를 풀었다. 현대자동차의 국재창 책임연구원도 같은 지점을 짚었다. 아무리 바이브 코딩을 적극적으로 활용한다 해도 이처럼 짧은 시간 안에 실제 업무에 적용 가능한 수준의 결과물을 구현하는 것은 결코 쉬운 일이 아니며, 기술을 단순히 도입하는 것을 넘어 실질적인 업무 혁신으로 연결한 점이 큰 의미로 다가왔다는 소감이었다.     현장의 반향 — 그리고 나눔으로 이어지는 혁신 발표가 끝난 뒤의 분위기는 감동과 놀라움, 그 자체였다. 매출 500억 규모 중소기업의 경영자문을 맡고 있는 김준완 컨설턴트는 MES와 ERP 때문에 방향을 잡지 못해 어려워하던 차에, 이 대표의 적극적인 열의와 구성원들의 오픈 마인드가 조화를 이루어 ‘눈에 보이는 경영’을 실현하고 있는 모습에 놀랐다며 좋은 영감을 얻었다고 했다. 이 모임을 주선한 에이스웍스 박승범 대표는 가업승계, 투자유치, 해외 개척에 이어 수도권 광교에 깃발을 꽂은 네오테크가 완전히 인상적이었다며 앞으로가 더욱 기대된다고 화답했다. 필자 역시 질문을 많이 던진 참석자 중 하나였다. SaaS 구독 서비스가 갖는 구조적 어려움과, 그 속에서 네오테크만의 비장의 무기를 만들어 가는 여정 — 니즈를 찾아 네오테크만의 색깔을 입히는 것이야말로 오늘날 AI가 가야 할 방향이 아닐까 싶었다. 이날 필자는 AI 기술로 기업의 구축 설루션을 A부터 Z까지 만들 수 있겠다는 희망을 보았고, 동시에 ‘사람이 미래인 이유’도 다시 확인했다. AI는 고민하지 않는다. 무엇이 문제인지 정의하고, 왜 데이터 주권이 내게 없는지 의심하고, 그것을 되찾겠다고 결심하는 것은 결국 사람의 몫이다. 네오테크는 그 고민을 시스템으로 녹여 실제로 적용하는 모습을 보여주었다. 더 감동적인 대목은 그다음이었다. 이준명 대표는 자신의 성과에 그치지 않고, 비슷한 어려움을 겪고 있는 다른 기업들에게 자신의 경험과 노하우를 아낌없이 나누고 있었다. 이날의 발표 자체가 그 나눔의 실천이었다. 소매 매장이 생기면서 주 7일을 일하고, 세미나 당일에도 자정까지 고객을 응대하고 다음 날 아침 예약 차량 때문에 다시 출근하는 대표 — 그러면서도 “많은 진심 어린 조언과 관심이 저뿐만 아니라 팀원들에게도 큰 도움이 됐다”며 함께 커 나가겠다는 그의 인사에서, 이 회사가 왜 젊고 강한지를 보았다.   에필로그 — 현장에서 얻는 것 돌아오는 길에 이날의 발표를 곱씹었다. 네오테크가 던진 질문은 사실 모든 제조기업을 향한 것이다. ‘여러분의 회사입니까? 그렇다면 여러분의 데이터입니까?’ 디지털 전환의 담론은 흔히 ‘어떤 설루션을 도입할 것인가’에서 출발한다. 그러나 네오테크의 사례는 질문의 순서를 바꾸라고 말한다. 먼저 물어야 할 것은 ‘나의 문제는 무엇이고, 그 문제를 풀기 위한 데이터의 주인은 누구인가’이다. 대기업은 오래전부터 자사 시스템을 직접 개발해 왔다. 이제 생성형 AI와 바이브 코딩의 시대 가 열리면서, 그 길이 45명 규모의 중소기업에게도 열렸다. 수천만 원의 커스터마이징 견적서 앞에서 좌절하던 중소기업 대표가, AI 를 파트너 삼아 자기 회사에 꼭 맞는 시스템을 직접 만들 수 있는 시대가 온 것이다. 물론 모든 기업이 네오테크처럼 할 수 있는 것은 아니다. 대표의 문제 정의 능력, 구성원의 오픈 마인드, 그리고 끝까지 밀어붙이는 실행력이 전제되어야 한다. 그러나 방향만큼은 분명하다. AI 시대의 경쟁력은 도구의 보유가 아니라 데이터 주권의 소유에서 나오고, 혁신은 기술의 도입이 아니라 문제의 해결에서 완성된다. ‘대표자는 문제를 해결할 수 있어야 한다’는 이준명 대표의 명제는, 그래서 튜닝 회사의 이야기를 넘어 이 시대 모든 경영자를 향한 화두로 남았다. F1의 피트에서 경주차는 멈추는 것이 아니라 더 빨리 달리기 위해 정비를 받는다. 광교의 THE PIT에서 필자는 한 강소기업이 데 이터 주권이라는 새 타이어로 갈아 끼우고 글로벌 트랙으로 다시 출발하는 장면을 목격했다. 신차를 뽑으면 꼭 이곳에 맡기고 싶다는 생각과 함께, 경정비를 넘어 차량의 상태를 살펴주는 ‘주치의’ 같은 브랜드로 커 가기를 응원하며 — 오리지널을 넘어서는 업그레이드(UPGRADE BEYOND THE ORIGINAL), 네오테크의 다음 랩(lap)이 기대된다.   ■ 류용효 디원 PLM기술본부에서 상무로 재직 중이며, 페이스북 ‘류용효컨셉맵 연구소’ 리더, CNGTV 지식방송 전문위원으로 활동하고 있다. PTC코리아, 오라클, 지멘스 PLM 등을 거치며 PLM과 프로세스 컨설팅 분야에서 일해 왔다. 저서로 ‘베테랑 기획자의 바이브코딩 도전기’가 있다. (블로그)     ■ 기사 내용은 PDF로도 제공됩니다.

심센터 HEEDS 더 깊게 살펴 보기 (8)   이번 호에서는 어떠한 형식의 해석 입출력 파일이라도 직관적이고 효율적으로 연결할 수 있도록 돕는 5가지 태깅 모드(tagging mode)의 원리와 특징을 소개한다. 나아가 수십· 수백 개의 매개변수를 다룰 때 작업 시간을 획기적으로 단축할 수 있는 오토 태깅(auto-tagging) 워크플로와 파이썬 로직을 결합한 고급 실무 활용 사례까지 함께 살펴보고자 한다. 이를 통해 데이터 연결 작업의 진입 장벽을 낮추고, 설계 탐색에 온전히 집중할 수 있는 방향을 제시할 것이다. ■ 연재순서 제1회 심센터 HEEDS 커넥트와 MBSE 방법론 제2회 심센터 X MDO의 새로운 HEEDS 제3회 심센터 HEEDS SHERPA의 최적 검색 원리 제4회 최적 검색 가속화를 위한 AI 프레딕터 제5회 심센터 HEEDS 2604 업데이트 제6회 모두를 위한 제너럴 포털과 맞춤 설정 제7회 특별한 워크플로 구성 및 자동화 제8회 다양한 매개변수를 위한 태깅 모드 제9회 복잡한 설정을 한번에, 오토메이션 스크립트 제10회 파이썬 스케줄러와 HEEDS 연동 제11회 심센터 HEEDS 2610 업데이트 제12회 데이터 분석을 위한 HEEDSPy API   ■ 이종학 지멘스 디지털 인더스트리 소프트웨어에서 심센터 HEEDS를 비롯하여 통합 설루션을 활용한 프로세스 자동화와 데이터 분석, 최적화에 대한 설루션을 담당하고 있다. 근사최적화 기법 연구를 전공하고 다양한 산업군에서 15년간 유한요소해석과 최적화 분야의 기술지원과 컨설팅을 수행하였다. 홈페이지 | www.sw.siemens.com/ko-KR 링크드인 | www.linkedin.com/in/jonghaklee-odumokgol   시뮬레이션 자동화 및 최적화 프로세스를 성공적으로 구축하기 위해 가장 기본적이면서도 중요한 단계는 바로 해석 모델과 최적화 알고리즘 간의 ‘매개변수(parameter) 연결’이다. 최적화 알고리즘이 광범위한 설계 공간을 탐색하기 위해서는, 매 해석 사이클마다 입력(input) 파일의 특정 변수 값을 변경하여 모델을 구동하고, 해석이 완료된 후에는 수많은 데이터가 담긴 결과(output) 파일에서 원하는 성능 지표를 한 치의 오차 없이 추출할 수 있어야 한다. 심센터 HEEDS(Simcenter HEEDS)는 이러한 매개변수 연결 과정을 ‘태깅(tagging)’이라는 직관적이고 유연한 기능으로 제공한다. 사용자가 입력 파일의 특정 위치를 태깅하면, HEEDS(히즈)는 기존에 적혀 있던 기준값(baseline value)을 새로운 설계안의 값으로 치환하여 해석을 수행한다. 반대로 출력 파일에서 특정 위치를 태깅하면, HEEDS는 해당 위치의 데이터를 읽어와 최적화 결과 지표로 활용한다. 이번 호에서는 단순한 텍스트 파일부터 복잡한 상용 해석 툴의 데이터 구조까지, 어떠한 형태의 파일이라도 매끄럽게 연결할 수 있도록 HEEDS가 제공하는 다섯 가지 태깅 모드를 깊게 살펴본다. 아울러 이 과정에서 사용자 인터페이스(UI)가 어떻게 구성되어 있는지, 수백 개의 변수를 다룰 때 작업 효율을 어떻게 극대화할 수 있는지 통합적인 관점에서 소개한다.   그림 1. HEEDS의 태깅 개념   직관적인 UI를 결합한 5가지 태깅 모드 딥다이브 HEEDS는 해석 툴의 특성과 파일 구조의 복잡성에 따라 맞춤형으로 대응할 수 있는 5가지의 태깅 모드를 제공한다. 각 모드는 사용자 친화적인 설정 화면과 함께 고유의 파싱(parsing) 능력을 발휘한다.   구분자/고정 폭 기준 태깅 : 정적 ASCII 파일의 완벽한 제어 해석 입출력 파일로 가장 널리 쓰이는 CSV나 텍스트(TXT) 형식의 파일은 보통 특수한 기호로 데이터가 구분되어 있거나, 일정한 글자 폭을 기준으로 데이터가 나열되어 있다. 구분자 기준 태깅(Delimited Tagging) : 공백(space), 탭(tab), 쉼표(comma) 등의 구분자(delimiter)를 기준으로 파일을 행과 열로 분할한다. 엑셀과 같이 익숙한 스프레드시트 형태로 파일 내용이 표시되며, 사용자는 원하는 셀을 클릭하여 태그를 생성할 수 있다. 필요에 따라 `="()`와 같은 복잡한 사용자 정의 구분자도 추가할 수 있어 유연성이 높다. 고정 폭 기준 태깅(Fixed-Width Tagging) : 과거부터 사용되어 온 일부 레거시 FEA 코드(예 : 나스트란 등)는 열 너비(column width)가 엄격하게 정해져 있어, 값이 특정 위치를 벗어나면 해석 오류를 일으킨다. HEEDS는 이러한 파일의 열 너비를 시각적으로 지정하여 데이터를 분할할 수 있게 해주며, 태깅된 변수에 값을 쓸 때도 지정된 고정 폭(fixed-width format)을 유지하도록 보장한다.   그림 2. 구분자 및 고정폭 설정 예시   그림 3. 구분자 및 고정 폭 설정 예시   XML 태깅과 계층 구조 제어 최신 해석 툴이나 복잡한 설정 파일은 태그(element)와 속성(attribute)이 중첩된 트리 형태의 XML(또는 HTML) 형식을 취하는 경우가 많다. XML 파일은 구조적이지만, 사람이 직접 텍스트로 보며 태깅하기에는 눈이 쉽게 피로해진다. HEEDS의 XML 태깅 모드는 파일을 파싱하여 ‘요소 ID(element ID)’와 ‘태그 값(tag value)’만을 깔끔한 표 형태로 나타낸다. 여기서 가장 돋보이는 기능은 XML Element Configuration 창에서 불필요한 하위 요소(child elements)의 표시 여부를 체크박스로 켜거나 끄는 것이 가능하다는 점이다. 이를 통해 사용자는 수만 줄에 달하는 방대한 XML 파일에서도 원하는 데이터 노드만을 화면에 필터링해 띄워 놓고 손쉽게 태깅을 진행할 수 있다.   그림 4. XML 파싱 및 하위 요소 제어 화면   스크립트 태깅의 강력한 커스터마이징과 즉각 검증 해석이 끝난 후 생성되는 결과 파일(예 : `*.f06`, 동적 `*.csv` 등)은 매 해석마다 출력되는 텍스트의 줄 수나 위치가 달라질 수 있다. 이런 동적인 파일 구조에서는 고정된 행/열을 지정하는 방식이 통하지 않는다. 이때 HEEDS 고유의 스크립트 태깅(script tagging)이 진가를 발휘한다. 파이썬(Python) 기반으로 설계된 이 모드는 코딩 지식이 없어도 제공되는 버튼 명령어를 블록 쌓듯 조합하여 강력한 스크립트를 작성할 수 있다.     ■ 자세한 기사 내용은 PDF로 제공됩니다.

SAP 코리아가 7월 14일 열린 ‘SAP 나우 AI 투어 코리아 2026’에서 단순 답변형 인공지능(AI)을 넘어 기업 업무 프로세스와 데이터를 관통하는 ‘자율형 기업’으로의 전환 비전을 제시했다. 업무를 보조하는 데에 머무르지 않고, 데이터 정합성과 거버넌스를 기반으로 AI 에이전트가 업무를 감지·판단·실행하는 자율 운영 체계를 구축하는 것이 핵심이다. ■ 정수진 편집장     엔드 투 엔드 프로세스 관통하는 자율형 기업 비전 많은 기업이 AI를 도입하고 있지만, 대다수는 문서 요약이나 단순 챗봇 수준의 보조 도구 활용에 머물러 있다. SAP는 이러한 방식이 기업의 복잡한 맥락을 파악하지 못하고 예외 상황을 통제하는 데 한계를 드러낼 수밖에 없다고 지적했다. 단순히 질문에 잘 대답하는 AI를 넘어, 기업의 엔드 투 엔드 비즈니스 프로세스에 깊이 내재되어 스스로 업무를 감지하고 판단하며 실행하는 ‘자율형 기업(Autonomous EntERPrise)’으로 진화해야 한다는 것이 SAP 의 설명이다. 자율형 기업 환경에서는 과거 사람이 일일이 시스템에 결과를 입력하고 업무를 수행하던 방식에서 벗어나, AI가 실질적인 프로세스를 주도한다. 사람은 전략적 의사결정과 통제 영역에 집중하게 된다. SAP의 얀 벙커트(Jan Bohnert) 최고매출책임자(CRO) 는 “사람이 결정만 내리면 백그라운드에서 고객 대상 크레딧 노트 발행과 창고 물품 이동 지시 등 모든 후속 조치가 자율적으로 처리된다”고 설명했다. SAP 코리아의 하경남 부문장 역시 “오늘날 기업에 필요한 것은 답변을 잘하는 AI가 아니라 업무를 직접 수행하는 AI”라며, AI를 단순 보조 도구로 쓰는 기업과 운영 체계로 내재화한 기업 간의 격차는 앞으로 돌이킬 수 없을 만큼 벌어질 것이라고 강조했다.   ▲ 자율형 기업을 위한 비즈니스 AI 혁신 전략을 소개한 얀 벙커트 CRO    비즈니스 맥락 이해하는 기술과 강력한 거버넌스 체계 구축 SAP는 자율형 기업으로 도약을 뒷받침하는 기술 기반으로 ‘SAP 비즈니스 AI 플랫폼’을 제시한다. 사용자는 단일 관문인 ‘쥴(Joule)’을 통해 여러 시스템을 오갈 필요 없이 업무를 지시할 수 있으며, 재무·구매·공급망 등 일상 운영은 ‘SAP 자율형 스위트’ 안에서 AI 에이전트들이 유기적으로 연결되어 처리한다. 이런 세 가지 층위(layer)에 산업별 특화 규제와 프로세스를 반영한 ‘SAP 인더스트리 AI’를 더해 새로운 산업 표준을 만들어가고 있다. 정확한 자율 실행을 위해서는 비즈니스 맥락을 깊이 이해하는 기술이 필수다. SAP는 수십만 개 테이블과 수백만 개 필드를 논리적으로 연결하는 지식 그래프(knowledge graph)로 데이터 간의 복잡한 관계를 짚어내고, 정형 데이터 예측에 최적화된 테이블 모델을 통해 추가 학습 없이 즉각적인 예측 결과를 도출한다. 또한 ‘쥴 스튜디오(Joule Studio)’를 제공해 자연어 프롬프트 한 줄로 맞춤형 AI 에이전트를 생성하고 요구사항 정의서 등 제반 문서까지 자동 작성하도록 지원한다. 한편, AI가 업무에 깊이 개입할수록 통제와 모니터링 체계는 더욱 중요해진다. SAP는 멀티 벤더 환경에서 작동하는 에이전트의 활동 현황을 감시하고 이상 작동을 조기에 차단하는 통합 거버넌스를 제공한다. 최종 통제권은 시스템이 아닌 사람에게 부여하는 ‘휴먼 인더루프(Human-in-the-Loop)’ 원칙을 기반으로 한다. 하경남 부문장은 “자율화가 이뤄지더라도 통제권은 여전히 사람에게 맡기는 구조”라고 설명했다. 이와 함께 SAP는 오픈AI, 구글, 엔비디아 등 다양한 파트너 모델을 목적에 맞게 선택할 수 있는 개방형 생태계 전략을 병행하고 있다.     프로세스 슬림화와 화학적 데이터 결합으로 혁신 실천 이번 ‘SAP 나우 AI 투어 코리아’에서는 이런 SAP의 자율형 기업 비전을 현장에서 성공적으로 실천해 낸 삼성전기의 사례가 소개됐다. 삼성전기가 차세대 통합 플랫폼 구축에 나선 2022년은 코로나19 특수가 끝나고 경영 환경이 불확실한 시기였다. 삼성전기는 대규모 투자가 어려운 상황에서 시스템을 가볍게 만드는 선행 과제부터 착수했다. 불필요한 자체 개발 프로그램을 과감히 줄이고 전사 자원 관리(ERP) 프로세스의 약 40%를 슬림화하여 총투자비를 절감했으며, 임직원 역량 강화를 통해 표준에 가까운 ‘클린 코어(Clean Core)’ 환경을 완성했다. 데이터 통합과 보안 측면에서도 대대적인 구조 개편이 이뤄졌다. 흩어져 있던 ERP, 데이터 웨어하우스, 공급망 관리 데이터베이스(DB)를 하나로 합쳐 거대한 데이터 레이크를 구축하고, 제조업의 엄격한 보안 요건을 충족하기 위해 프리미엄 서플라이어 모델을 도입했다. 시스템 전환 시 공장 가동 중단을 최소화한 과정에 대해 삼성전기의 박준호 그룹장은 “ERP 전환은 마치 심장 이식 수술과 같다”면서, 임시 서버 운영과 단계별 차단을 통해 비즈니스 무중단 전환을 달성했다고 밝혔다. 삼성전기의 사례는 최고 수준의 AI가 결국 최고 수준의 데이터에서 시작된다는 점을 보여준다. 박준호 그룹장은 “데이터를 물리적으로 통합하는 것은 쉽지만, 각기 다른 생태계를 가진 데이터를 모아 화학적으로 결합하는 작업이 가장 중요하고 힘들다”고 전했다. 화학적으로 결합해 정합성을 확보한 데이터와 튼튼한 프로세스가 선행되어야만 AI가 업무 맥락을 이해할 수 있기 때문이다. 삼성전기는 향후 생산 계획과 실행이 사람 개입 없이 연결되고, AI 에이전트가 예외 상황을 감지해 대안을 수립하는 폐순환(closedloop) 형태의 자동화를 향해 나아가고 있다.     ■ 기사 내용은 PDF로도 제공됩니다.

트렌드에서 얻은 것 No. 34   지난 7월, 필자는 ‘데이터공작소’ 온톨로지 스터디 그룹에서 ‘지식그래프 : AI와 온톨로지로 여는 지식혁명’(이강배 저)의 3장을 주제로 발표를 진행했다. 발표 제목은 ‘온톨로지의 개념, 그리고 컨셉맵’이었다. 이 글은 그날의 발표를 제조기업의 경영자와 실무자를 위해 다시 정리한 것이다. 그리고, 글의 끝에서 8월에 출간되는 필자의 새 책 이야기를 잠시 나누려 한다. 두 이야기는 겉보기엔 다르지만, 결국 하나의 질문으로 만난다. “AI 시대, 우리의 경험과 지식은 어떻게 시스템 위에서 다시 움직이는가?”   “좋습니다. 그런데 실제로 되는 겁니까?” 제조기업의 회의실 풍경이 달라지고 있다. 예전에는 잘 정리된 문서와 유창한 설명이 설득의 무기였다. 지금은 다르다. AI 도입 보고가 끝나면 경영진은 이렇게 묻는다. “좋습니다. 그런데 실제로 되는 겁니까?” 방향이 아니라 증거를, 설명이 아니라 결과를 요구하는 시대가 된 것이다. 그런데 막상 ‘실제로 되게’ 하려고 하면, 대부분의 제조기업은 같은 벽에 부딪힌다. 데이터는 많은데 연결이 안 된다. ERP, MES, PLM, CRM에 수십 년 치 데이터가 쌓여 있지만 같은 부품이 부서마다 다른 코드로 등록되어 있고, 같은 고객이 시스템마다 다른 이름으로 존재한다. AI에게 “이번 달 출하 지연 리스크를 요약해 달라”고 묻고 싶어도, AI는 우리 회사의 ‘출하’가 무엇이고 ‘지연’의 기준이 무엇인지 알지 못한다. 데이터는 있지만 ‘의미’가 없기 때문이다. 이 문제를 정면으로 겨냥한 개념이 바로 온톨로지(ontology)다. 미 국방부와 BMW, 에어버스같은 기업들이 팔란티어(Palantir) 플랫폼에 주목하는 이유도, 그 중심에 온톨로지가 있기 때문이다.   ▲ 제미나이로 생성한 이미지 (클릭하면 큰 그림으로 볼 수 있습니다.)   온톨로지, 어렵지 않다 − 출석부와 우리 반 지도 온톨로지라는 단어는 철학의 존재론에서 왔다. 낯설게 들리지만, 개념 자체는 초등학생도 이해할 수 있다. 전학 온 친구에게 우리 반을 소개하는 상황을 떠올려 보자. 이름만 쭉 적힌 출석부를 건네는 방법이 있고, ‘민수는 축구를 좋아하고, 지우와 짝꿍이다’처럼 관계를 그린 지도를 건네는 방법이 있다. 출석부는 데이터의 나열이고, 지도는 지식의 구조다. 어느 쪽이 우리 반을 더 잘 설명하는지는 물을 필요도 없다. 이 지도에는 온톨로지의 재료 네 가지가 모두 들어 있다. ‘3반 친 구’라는 범주가 클래스(class), 민수와 지우라는 실제 인물이 인스턴스(instance), 키 145cm와 같은 특징이 속성(attribute), ‘짝꿍이다’라는 연결이 관계(relationship)다. 책은 이를 노트북으로 설명한다. ‘컴퓨터’와 ‘노트북’은 클래스, ‘LG 그램’은 인스턴스, ‘사양과 가격’은 속성, ‘노트북은 컴퓨터에 포함된다’는 관계다. 회사 버전으로 바꾸면 이렇게 된다. ‘고객·제품·설비’가 클래스, ‘A 조선소와 스크러버 1호기’가 인스턴스, ‘소재지·등급·가동 상태’가 속성, ‘A 조선소는 스크러버를 발주했다’가 관계다. 스탠포드대학교의 토마스 그루버 교수는 온톨로지를 “공유된 개념화의 정형화되고 명시적인 명세”라고 정의했다. 어렵게 들리지만 세 조각으로 나누면 명료하다. ‘공유된 개념화’란 부서마다 다르게 부르던 용어를 하나로 합의한 회사 공용어 사전이다. ‘정형화·명시적’이란 베테랑의 머릿속 암묵지를 규정집처럼 명문화하는 것이다. ‘명세’란 그것을 사람만이 아니라 시스템도 읽을 수 있는 업무 문법으로 만드는 것이다. 한 줄로 줄이면, 책 76쪽의 표현 그대로 “특정 분야의 지식을 구조화하여 컴퓨터가 이해하고 처리할 수 있도록 표현한 것”이다.   스키마가 이미 있는데, 왜 온톨로지인가 실무자들이 가장 많이 던지는 질문이 있다. “우리 데이터베이스에도 이미 테이블 설계, 즉 스키마가 있는데 뭐가 다릅니까?” 책 3.1.1이 정확히 이 질문에 답한다. 스키마(schema)는 데이터의 구조를 정의한다. 고객 테이블에 이름과 나이 컬럼이 있다는 식이다. 반면 온톨로지는 ‘고객은 사람의 하위 클래스이고, 구매 행동을 수행할 수 있다’는 지식 자체를 모델링한다. 스키마의 모델링 대상이 ‘데이터’라면, 온톨로지의 대상은 ‘개념과 개념 간 관계’이며, 결정적 차이는 추론 가능 여부다. 제조 현장의 언어로 옮기면 차이가 더 선명해진다. ‘선박 코드 SHIP-001, 블록 ID BLK-A-017, 작업 ID WLD-0342’라고 코드를 나열하는 것이 기존 데이터 모델이라면, 온톨로지는 ‘선박은 블록으로 구성된다, 블록은 용접작업을 필요로 한다, 용접은 특정 자격을 가진 작업자만 수행한다, 모든 작업은 규정된 품질 기준을 따라야 한다’는 업무의 문법을 시스템에 심는다. 이 문법이 있어야 설계 변경이 발생했을 때 시스템이 영향받는 블록을 스스로 추적하고, 작업을 재계획하고, 지연 리스크를 예측할 수 있다. 사람이 엑셀로 하루 걸리던 영향 분석이 관계를 따라 실시간으로 이루어지는 것이다. 팔란티어가 조선·자동차 산업에서 보여주는 시나리오가 정확히 이것이며, 그 구동 방식은 다섯 단계다. 레거시 데이터를 옮기지 않고 연결하고, 그 위에 온톨로지 계층을 얹어 의미를 부여하고, 현장이 쓰는 업무 앱을 제공하고, 조치의 비용과 리스크를 시뮬레이션하고, 마지막으로 AI(AIP)가 실행까지 연결한다. 스키마가 ‘데이터를 담는 그릇의 규격’이라면, 온톨로지는 ‘지식의 의미와 규칙까지 담는 모델’이다. 그리고 이 온톨로지라는 설계도에 실제 데이터를 채워 넣은 결과물이 지식 그래프(knowledge graph)다. 구글의 의미 검색과 아마존의 추천이 이미 그 위에서 돌아가고 있다.   회의실의 콘셉트맵이 시스템의 온톨로지가 되기까지 여기서 필자가 오래 다뤄 온 주제인 콘셉트맵(concept map) 이 등장한다. 1970년대 코넬대학교의 조셉 노박이 개발한 콘셉트 맵은 개념(상자)과 연결어(화살표 위의 단어)로 명제를 그리는 생각의 지도다. ‘온톨로지는 지식 그래프의 청사진이다’처럼, 개념−연결어−개념이 한 문장을 이룬다. 흥미로운 것은 이 명제 구조가 지식 그래프의 기본 단위인 트리플(주어−술어−목적어)과 정확히 같다는 점이다. 콘셉트맵과 온톨로지는 같은 뿌리에서 나온, 독자가 다른 두 표현이다. 콘셉트맵은 사람이 읽는 지식의 스케치이고, 온톨로지는 기계까지 읽는 지식의 도면이다. 그래서 필자는 두 가지를 경쟁 관계가 아니라 ‘한 정의의 앞뒤 반쪽’이라고 부른다. 그루버의 정의로 돌아가 보면, 전문가들이 모여 콘셉트맵을 그리고 용어를 표준화하는 과정이 ‘공유된 개념화’이고, 그 합의를 클래스·관계·규칙으로 변환해 시스템에 싣는 과정이 ‘정형화되고 명시적인 명세’다. 콘셉트맵 없이 온톨로지를 만들면 합의 없는 표준이 되고, 온톨로지 없이 콘셉트맵만 있으면 그림으로 끝난다. 실무 적용법은 단순하다. 업무 인터뷰와 워크숍의 대화를 실시간 콘셉트맵으로 기록해 암묵지를 형식지로 바꾸고, 부서 간 용어 합의의 회의 도구로 쓰고, 합의된 맵을 개념은 클래스로, 연결어는 관계로 변환해 온톨로지 설계의 초안으로 삼는 것이다. 도구는 시맵(Cmap)이든 화이트보드든 상관없다. 경영자에게 강조하고 싶은 지점이 있다. 온톨로지 프로젝트의 성패는 기술이 아니라 합의에서 갈린다. 그리고 품목 명칭조차 통일되지 않은 상태라면 어떤 온톨로지도 그 위에 설 수 없다. 그래서 현실적인 로드맵은 전사 빅뱅이 아니라, 효과가 분명한 핵심 도메인 하나(예컨대 품목, BOM, 변경 관리)를 골라 콘셉트맵으로 합의를 만들고, 온톨로지로 정형화하고, 데이터를 채워 인접 도메인으로 확장하는 것이다. 책도 균형 있게 짚는다. 도메인이 복잡할수록 설계와 유지보수가 어렵고 주기적 갱신 부담이 있다. 그러니 작게 시작해야 한다.   그리고, 바이브코딩 − 8월의 새 책 이야기 온톨로지가 ‘조직의 지식’을 시스템이 이해하게 만드는 일이라면, 개인 차원에서 같은 전환을 다룬 이야기가 있다. 오는 8월 출간 예정인 필자의 새 책, ‘베테랑 기획자의 바이브코딩 도전기’다. “나는 아직 유효한 사람인가.” — 회의실에서 젊은 동료들이 빠르게 도구를 다루는 모습을 볼 때, 은퇴라는 단어가 더 이상 먼 일이 아니게 느껴질 때, 조용히 계산하곤 했다. 내가 가진 경험이 앞으로도 통할까.  책은 이 질문에서 출발한다. 바이브 코딩(vibe coding)이란 프로그래밍 문법을 외워 코드를 치는 것이 아니라, 커서(Cursor)나 제미나이(Gemini)같은 AI 도구에게 자신의 의도와 맥락을 전달해 프로그램을 만들도록 지휘하는 일하는 방식이다. 필자는 데이터공작소 스터디에서 8개월간 개발자들과 함께 배우며, 하루 30분씩 눈으로 70%를 이해하고 손으로 30%를 부딪히는 자신만의 학습 공식을 찾았다. 거창한 프로젝트가 아니라 매주 나를 지치게 하던 엑셀 정리 하나, 파일 정리 하나부터 고쳐 나가는 ‘하루 한 프로그램’의 기록이다. 책의 부록에서는 노코드(no code), 로코드(low code), 바이브 코딩을 비교하며 언제 무엇을 써야 하는지도 다룬다. 요구사항이 표준적이면 노코드, 예외 처리와 연동이 필요하면 로코드, 요구사항이 계속 바뀌고 기획자가 직접 프로토타입을 쥐어야 한다면 바이브 코딩이다. 눈 밝은 독자라면 이미 알아챘을 것이다. 온톨로지 도입 로드맵과 바이브 코딩 학습법은 같은 철학 위에 서 있다. 작게 시작하고, 합의(같은 방향)를 먼저 만들고, 증거로 말하는 것. 조직은 온톨로지로 지식을 시스템에 싣고, 개인은 바이브 코딩으로 의도를 실행에 싣는다. 제조 기업의 디지털 전환이란 결국 이 두 층위가 만나는 지점에서 완성된다.   맺으며 − 같은 방향을 본다는 것 생텍쥐페리는 “사랑이란 서로 바라보는 것이 아니라, 서로 같은 방향을 보는 것”이라고 했다. 필자가 이 문장을 좋아하는 이유는, 프로젝트와 조직의 성패도 결국 같은 방향을 보는 능력에서 갈리기 때문이다. 온톨로지는 사람과 시스템이, 현장과 경영진이, 그리고 사람과 AI가 같은 방향을 보게 만드는 언어다. LLM(대규모 언어 모델)은 유창하지만 사실에 약하고, 지식 그래프는 사실에 강하다. 둘의 결합이 신뢰할 수 있는 기업 AI의 핵심이라는 책의 통찰 (6.3장)은, 앞으로 제조기업의 AI 전략이 어디로 가야 하는지를 가리키고 있다. 이번 여름, 회의실 화이트보드에 우리 회사의 콘셉트맵 한 장을 그려 보기를 권한다. 우리 회사의 ‘고객’이란 무엇인가, ‘품목’과 ‘설비’는 어떻게 연결되는가. 그 한 장의 합의가 온톨로지의 시작이고, 지식 그래프의 청사진이며, AI가 우리 회사를 이해하는 첫 문장이 된다.   ■ 류용효 디원 PLM기술본부에서 상무로 재직 중이며, 페이스북 ‘류용효컨셉맵연구소’ 리더, CNGTV 지식방송 전문위원으로 활동하고 있다. PTC코리아, 오라클, 지멘스 PLM 등을 거치며 PLM과 프로세스 컨설팅 분야에서 일해 왔다. 저서로 ‘베테랑 기획자의 바이브코딩 도전기’가 있다. (블로그)     ■ 기사 내용은 PDF로도 제공됩니다.

어도비가 생성형 인공지능(AI) 검색 환경에서 기업 브랜드의 가시성을 높이고 신뢰를 구축할 수 있도록 돕는 ‘어도비 브랜드 비저빌리티(Adobe Brand Visibility)’를 발표했다. 이 설루션은 기업이 고객 생애주기 전반을 관리하도록 돕는 에이전틱 AI 시스템인 ‘어도비 CX 엔터프라이즈(Adobe CX EntERPrise)’의 일부로 제공된다.     최근 AI 기반 채팅 서비스와 브라우저로 제품을 탐색하고 평가하는 소비자가 늘고 있다. 어도비가 공개한 데이터에 따르면 2024년 10월부터 2026년 5월 사이 미국 소매 사이트로 유입된 AI 트래픽은 1324% 증가했다. 같은 기간 여행 업계의 AI 트래픽도 2215% 늘어나며 성장세를 보였다. 어도비 브랜드 비저빌리티는 생성형 엔진 최적화(GEO)를 위한 포괄적인 설루션이다. 어도비 LLM 옵티마이저(Adobe LLM Optimizer) 기능과 셈러쉬(Semrush)의 AI 최적화 기술을 결합했다. 약 3억 개의 실제 AI 검색 프롬프트 데이터베이스를 바탕으로 챗GPT, 구글 AI 모드, 마이크로소프트 코파일럿, 퍼플렉시티 AI 등 주요 AI 환경에서 브랜드 언급 빈도, 청중 도달, 경쟁사 대비 점유율, 콘텐츠 공백을 분석한다. 분석 후에는 AI 에이전트가 우선순위가 높은 권장 사항을 제시하며, 사용자는 몇 분 안에 업데이트를 적용할 수 있다. 어도비 애널리틱스(Adobe Analytics)와 연동해 모든 작업을 영업 파이프라인 및 매출과 연결해 단일 워크플로로 관리하는 것도 가능하다. 또한 셈러쉬 데이터 기반 가시성 인사이트, 프롬프트 전략 제시, 경쟁 브랜드 비교, 에지 환경 AI 에이전트를 통한 자동 최적화, 285억 개 키워드 기반 SEO 인텔리전스 등을 제공한다. 어도비 브랜드 비저빌리티는 독립 애플리케이션으로 사용하거나, 콘텐츠 및 애셋 관리 시스템인 어도비 익스피리언스 매니저(Adobe Experience Manager)와 통합해 활용할 수 있다. 어도비의 아닐 차크라바티 고객 경험 오케스트레이션 사업 부문 사장은 “고객이 웹사이트 방문 전 AI 툴과 먼저 상호작용하는 환경에서 가시성은 매우 중요하다”면서, “어도비 브랜드 비저빌리티는 기업이 다양한 AI 환경에서 영향력을 확대하도록 지원하는 포괄적인 설루션”이라고 전했다.