“해석 한 번 돌리는 데 이틀을 기다렸던 시절이 있었다. 이제는 실시간으로 결과가 나온다.” 한 자동차 부품사 수석 엔지니어의 말이다.
들어가며 — 왜 지금 이 얘기를 꺼내는가
솔직히 말하면, CAE(Computer Aided Engineering)는 오랫동안 엔지니어들만의 세계였다. 해석 소프트웨어를 다룰 줄 아는 전문 인력, 엄청난 컴퓨팅 파워, 그리고 결과를 해석할 수 있는 도메인 지식이 동시에 있어야만 돌아가는 분야였다. 그래서 프로젝트 관리자 입장에서도 CAE 팀은 늘 “블랙박스”였다. 뭘 하는지는 알겠는데, 얼마나 걸릴지, 결과가 맞는지, 검증은 어떻게 하는지 — 이게 불투명했다.
그런데 2025년을 지나 2026년에 접어든 지금, 이 판이 근본적으로 흔들리고 있다. AI가 CAE 안으로 들어오면서, 단순히 계산이 빨라진 것이 아니라 시뮬레이션의 패러다임 자체가 바뀌고 있다. 그리고 이건 엔지니어만의 이야기가 아니다. 이 프로젝트를 기획하고, 예산을 따고, 팀을 꾸리고, 납기를 맞춰야 하는 사업관리·프로젝트 관리자들에게도 직접적인 이야기다.
이 글에서는 현장에서 벌어지고 있는 AI+CAE 플랫폼 개발 프로젝트의 실체를 해부한다. 기술 트렌드만이 아니라, 왜 이 프로젝트들이 어렵고, 어디서 미끄러지고, PM이 무엇에 집중해야 하는지까지.
1. CAE가 뭔지 모르면 이 프로젝트를 관리할 수 없다
프로젝트를 맡은 PM이 처음 부딪히는 벽은 용어다. CAE, FEM, CFD, FEA, 디지털 트윈 — 이게 다 다른 건지, 연결된 건지부터 헷갈린다. 간단하게 정리하고 넘어가자.
CAE는 컴퓨터를 이용해 제품 설계의 물리적 거동을 수치 해석하는 행위 전반을 가리킨다. 자동차 충돌 시뮬레이션, 건물 구조 해석, 항공기 날개의 공력 분석, 반도체 패키지의 열 해석 — 이 모든 게 CAE다.
그 안에 세부 기법들이 있다. **FEM(유한요소법)**은 고체 구조물의 변형·응력을 분석하는 데 주로 쓰이고, **CFD(전산유체역학)**는 유체의 흐름을 해석한다. **FEA(유한요소해석)**는 FEM을 적용한 해석 행위를 말한다.
디지털 트윈은 물리적 실체의 가상 복제본이다. 공장 설비, 교량, 엔진 같은 실물을 가상 공간에 그대로 구현하고, 실시간 센서 데이터를 연결해 현재 상태를 모니터링하거나 미래 거동을 예측하는 개념이다. CAE가 “설계 단계의 해석”이라면, 디지털 트윈은 “운영 단계에서도 살아있는 시뮬레이션”이다.
그리고 이 모든 것에 AI가 접목되는 것이 지금 벌어지는 일이다.
2. 지금 시장에서 무슨 일이 벌어지고 있나 — 최신 동향
2-1. 글로벌 시장: 65억 달러를 향해 달리고 있다
CAE 시장은 2025년 기준으로 약 65억 9천만 달러 규모에 달할 것으로 전망된다. 단순한 엔지니어링 소프트웨어 시장이 아니다. 여기에 클라우드, AI, 디지털 트윈이 합쳐지면서 제조업 전체의 디지털 전환을 이끄는 핵심 인프라로 격상되고 있다.
NVIDIA가 움직이기 시작했다는 것이 가장 강력한 신호다. NVIDIA는 GPU 가속 기반의 CAE 워크플로우를 지원하면서, Omniverse 플랫폼을 통해 실시간 디지털 트윈을 구현하고 있다. 자동차 공기역학 시뮬레이션을 실시간으로 돌리는 가상 풍동(Virtual Wind Tunnel)은 이제 데모 수준을 넘어 실제 엔지니어링 현장에 들어오고 있다. Altair, Ansys, Cadence, Siemens 같은 전통적인 CAE 강자들도 NVIDIA 기술 기반 위에서 다음 세대를 설계 중이다.
Dell Technologies는 2025년 3월 AI 기반 클라우드 CAE 플랫폼을 출시하며 3,000개 이상 기업에 멀티 사용자 시뮬레이션 환경을 열었다. 이 흐름의 핵심 키워드는 “플랫폼으로서의 시뮬레이션(Simulation as a Platform)”이다. 도구가 아니라 인프라로 보기 시작한 것이다.
Ansys Mechanical 2025 R2에서는 자유도가 높은 모델의 GPU 가속 솔버가 도입되면서 대용량 메모리 문제를 상당히 해소했다. Abaqus와 Dassault의 3DEXPERIENCE 플랫폼 통합도 성숙 단계에 접어들었다는 평가다.
물리 정보 기반 신경망(PINN, Physics-Informed Neural Networks)은 단순히 학계 논문 주제가 아니라 실제 시뮬레이션 병목을 해소하는 수단으로 자리 잡고 있다. 기존 수치해석이 풀지 못하거나 수십 시간이 걸리던 문제를 PINN이 훨씬 빠르게 근사 해법을 제시한다.
2-2. 국내 시장: 정부가 판을 키우고 있다
국내에서도 이 흐름은 예외가 아니다. 2026년 현재, 정부는 11개 부처 합동으로 ‘AI 응용제품 신속 상용화 지원사업(AX-Sprint)’을 추진 중이다. 총 7,540억 원 규모로, 제조·국토·교통·보건 등 5대 분야에서 246개 AI 제품의 상용화를 밀어붙이고 있다. 이 사업의 규모만 봐도 정부가 AI 기반 산업 플랫폼을 얼마나 전략적으로 키우려 하는지 알 수 있다.
자동차, 전자, 조선, 방산 분야에서 국내 대기업들의 CAE 내재화 수요도 꾸준히 높아지고 있다. 예전에는 해외 소프트웨어에 전적으로 의존하던 기업들이 자체 시뮬레이션 플랫폼 구축이나 국산 CAE 솔루션 개발에 관심을 보이기 시작했다. 국방·항공우주 분야의 경우 안보 이유로 해외 의존도를 줄여야 한다는 현실적 압박도 있다.
CAE 컨퍼런스 2025가 “시뮬레이션의 미래: AI와 디지털 트윈이 주도하는 제조 혁신”을 주제로 열린 것도 이 맥락이다. 산업 현장에서 AI+CAE 융합이 더 이상 미래 담론이 아니라 당장 다음 분기에 검토해야 할 실행 과제가 됐다는 방증이다.
3. AI+CAE 플랫폼 개발, 실제로는 어떤 프로젝트인가
3-1. 프로젝트의 전형적인 구조
AI+CAE 플랫폼 개발 프로젝트는 크게 세 가지 유형으로 나뉜다.
첫째, 기존 CAE 워크플로우 AI 고도화 프로젝트. Ansys나 Abaqus 같은 상용 도구를 이미 쓰고 있는 기업이 AI를 통해 해석 속도를 줄이거나, 설계 파라미터 최적화를 자동화하거나, 결과 해석을 보조하는 도구를 덧붙이는 방식이다. 비교적 범위가 명확하고, 현장 엔지니어의 수용도가 높다.
둘째, 디지털 트윈 플랫폼 구축 프로젝트. 공장·설비·제품에 IoT 센서를 달고, 실시간 데이터를 수집해 시뮬레이션 모델과 연동하는 프로젝트다. Azure IoT Hub, AWS IoT Core 같은 클라우드 플랫폼과 Siemens Simcenter, ANSYS Twin Builder 같은 도구가 맞물린다. 규모가 크고 이해관계자가 많아 PM의 부담이 크다.
셋째, 자체 시뮬레이션 엔진 개발 프로젝트. 해외 상용 소프트웨어 라이선스 비용을 줄이거나, 특정 도메인에 특화된 솔버를 직접 만드는 프로젝트다. 국방·항공우주·조선 분야에서 주로 나오는 수요다. 기술 난이도가 가장 높고, 실패율도 높다.
3-2. 기술 스택의 현실
이 프로젝트를 처음 접하는 PM이 당황하는 건 기술 스택의 복잡도다. 단순히 개발자들이 코드 짜는 프로젝트가 아니다.
물리 해석 쪽에서는 FEM, CFD 솔버 알고리즘에 대한 이해가 필요하다. AI 쪽에서는 머신러닝, 딥러닝 기본 원리와 함께 물리 기반 신경망(PINN), 서로게이트 모델(Surrogate Model), 생성형 AI 기반 형상 최적화 같은 개념이 나온다. 인프라 쪽에서는 고성능 컴퓨팅(HPC), GPU 클러스터, 클라우드 아키텍처가 들어온다. 데이터 쪽에서는 시뮬레이션 결과 데이터의 전처리·관리·버전 관리가 필수다.
PM이 이 모든 것을 깊이 알 필요는 없지만, 각 영역의 담당자가 서로 다른 언어로 말한다는 걸 알고 있어야 한다. 물리 해석 팀과 AI 개발 팀이 같은 테이블에 앉아도 서로 전혀 다른 얘기를 하고 있는 경우가 비일비재하다.
4. 이 프로젝트가 특히 어려운 이유 — 현장 경험에서 나온 이야기
4-1. 요구사항이 애매하다, 치명적으로
AI 프로젝트 실패의 가장 흔한 원인 중 하나는 “우리도 AI를 도입해야 하는데”라는 모호한 요구로 시작하는 것이다. 생성형 AI 파일럿의 88~95%가 운영 단계로 전환되지 못하고 있다는 건 데이터가 말해주는 현실이다. IBM 기업가치연구소의 2025년 CEO 연구에 따르면, AI 이니셔티브 중 기업 수준에서 규모를 확장하는 데 성공한 비율은 16%에 불과하다.
CAE+AI 프로젝트에서 이 문제는 더 심각하다. 발주처(또는 경영진)가 원하는 건 “AI로 CAE를 빠르게”인데, 이게 무슨 의미인지가 명확하지 않다. 해석 시간을 줄이고 싶은 건지, 비전문가도 해석을 돌릴 수 있게 하고 싶은 건지, 설계 최적화를 자동화하고 싶은 건지, 아니면 실시간 모니터링을 원하는 건지 — 전부 다른 프로젝트다.
킥오프 전에 발주처와 이 질문들을 끈질기게 파고들지 않으면, 3개월 후에 팀이 열심히 만든 것과 발주처가 원했던 것이 완전히 다른 상황이 벌어진다. 필자가 관리하던 현장에서도 비슷한 일이 있었다. “AI로 해석 자동화”를 요구사항으로 받아서 모델 학습 파이프라인을 열심히 만들었더니, 발주처가 원한 건 “엔지니어 없이도 버튼 하나로 해석 가능한 UI”였던 것이다.
4-2. 데이터가 없거나, 있어도 쓸 수 없다
AI 학습에 필요한 시뮬레이션 데이터를 모으는 게 생각보다 훨씬 힘들다. 수십만 건의 해석 결과 데이터가 필요한데, 기업 내에 쌓인 CAE 데이터는 대부분 일관성이 없거나, 파일 형식이 제각각이거나, 담당자가 퇴사하면서 컨텍스트가 사라진 경우가 많다.
게다가 시뮬레이션 데이터는 라벨링이 어렵다. 자연어 데이터처럼 “이건 긍정, 이건 부정”이 아니라, 해당 해석 결과가 맞는 설정에서 나온 건지, 경계 조건은 적절했는지, 메시 품질은 충분했는지를 검증해야 한다. 이걸 할 수 있는 사람은 결국 베테랑 해석 엔지니어고, 그들의 시간은 비싸다.
4-3. 엔지니어들의 저항
솔직히 가장 뜻밖의 장벽이 여기서 나온다. AI가 CAE 업무를 도와주는 도구라고 하는데, 막상 현장 엔지니어들은 달갑지 않아 한다. “내가 10년 쌓아온 해석 노하우를 AI가 대체한다는 거냐”는 심리적 저항이 있다. 또 AI가 낸 결과를 믿을 수 없다는 기술적 불신도 있다. “AI가 99% 케이스는 잘 맞추지만, 극단적인 1% 케이스에서 크게 틀리면 어떻게 하냐”는 우려는 사실 타당하다.
이 저항을 무시하고 “우리는 AI를 도입했다”고 선언만 한 프로젝트는 시스템이 완성되어도 아무도 안 쓰는 결과로 이어진다. PM은 기술 구현만이 아니라 현장 엔지니어의 신뢰를 얻는 과정을 처음부터 프로젝트 계획에 넣어야 한다.
4-4. 물리 팀과 AI 팀의 사일로
CAE 해석 전문가와 AI 엔지니어는 사고방식 자체가 다르다. 물리 팀은 “정확도”에 집착한다. 1% 오차도 용납 못 하는 경우가 있다. AI 팀은 “확률적 근사”에 익숙하다. 이 두 집단이 만나면 초기에 심한 마찰이 생긴다.
“서로게이트 모델이 95% 정확도면 충분하다”는 AI 팀과 “그 5% 오차가 재료 파단을 놓칠 수 있다”는 해석 팀이 대립하는 상황, 이게 실제로 회의실에서 벌어진다. PM은 이 두 세계의 통역사 역할을 해야 한다. 그리고 이 역할이 이 프로젝트에서 PM이 제공하는 가장 큰 가치 중 하나다.
5. 주요 솔루션 및 플랫폼 비교 — PM이 알아야 할 선택지
실제 프로젝트에서 어떤 도구와 플랫폼을 선택하느냐는 예산, 기존 시스템, 도메인에 따라 달라진다. 각 선택지의 성격을 파악하고 있어야 제대로 된 기술 결정을 지원할 수 있다.
| 구분 | 주요 솔루션 | 강점 | 약점 | 비용 수준 |
|---|---|---|---|---|
| 상용 CAE | Ansys, Abaqus, Nastran | 검증된 정확도, 방대한 레퍼런스 | 고비용 라이선스, 커스터마이징 제한 | 매우 높음 |
| AI 가속 플랫폼 | NVIDIA Modulus, Rescale | GPU 가속, 클라우드 유연성 | 구축 복잡도, 내부 인력 필요 | 높음 |
| 디지털 트윈 | Siemens Simcenter, ANSYS Twin Builder | 실시간 연동, 예측 유지보수 | IoT 인프라 선행 필요 | 높음 |
| 오픈소스 기반 | OpenFOAM, FEniCS, SU2 | 비용 절감, 커스터마이징 자유 | 기술 지원 없음, 인력 의존도 극히 높음 | 낮음(인력 비용 높음) |
| 서비스형 시뮬레이션 | Rescale, SimScale | 온디맨드 컴퓨팅, 진입장벽 낮음 | 데이터 보안 우려, 사용량 비용 | 중간 |
프로젝트 유형에 따라 출발점이 달라진다. 기존 Ansys 라이선스가 있는 대기업이 AI 고도화를 하는 거라면 Ansys 생태계 안에서의 AI 확장을 먼저 검토하는 것이 현실적이다. 스타트업이나 연구기관에서 새 플랫폼을 만드는 거라면 오픈소스 기반+클라우드 조합이 경제적이다.
6. 롤스로이스가 디지털 트윈으로 한 일, 그리고 우리 현장의 현실
롤스로이스는 디지털 트윈을 사용해 엔진 성능을 시뮬레이션하고 테스트 비용을 18%나 절감했다. C-Suite 기술 임원의 70%가 이미 디지털 트윈 솔루션에 투자하고 있다는 조사 결과도 있다. 화려한 수치들이다.
그런데 현실에서 이걸 그대로 따라 하려다가 미끄러지는 곳이 많다. 롤스로이스와 우리 회사의 차이를 냉정하게 봐야 한다. 그들은 수십 년간 쌓인 엔진 운영 데이터가 있고, 수백 명의 해석 전문가가 있고, IT 인프라도 이미 갖춰져 있다. 우리 회사는? 센서도 없고, 데이터도 없고, 해석 전문가는 한두 명뿐이다.
디지털 트윈 개발은 복잡할 수 있으며, 명확한 비전과 정확한 데이터 통합이 없으면 실패한다. 이건 교과서에 나오는 말이 아니라 현장에서 증명된 사실이다.
그렇다면 답은 무엇인가? 한 번에 완벽한 디지털 트윈을 만들려다 실패하는 것보다, 가장 가치 있는 설비 하나, 가장 임팩트가 큰 공정 하나를 먼저 타깃으로 MVP(최소 기능 제품)를 만들어 검증하는 것이다.
7. 프로젝트 관리자의 핵심 전략 — 이 프로젝트를 살아남게 하는 방법
25년 IT 프로젝트 경험에서 AI+CAE 프로젝트에 통하는 원칙들을 정리하면 이렇다.
7-1. 요구사항 정의에 엔지니어를 직접 참여시켜라
발주처 임원이나 기획팀이 아니라, 실제로 CAE 툴을 쓰는 현장 엔지니어를 요구사항 정의 단계에 끌어들여야 한다. 그들이 어떤 작업에서 가장 많은 시간을 쏟는지, 어디서 가장 짜증을 느끼는지가 진짜 요구사항이다. 경영진이 원하는 “AI로 시뮬레이션 자동화”가 현장에서는 “해석 설정 실수를 줄이고 싶다” 혹은 “결과 보고서 작성 시간을 줄이고 싶다”로 번역될 때가 많다.
이 번역을 PM이 해야 한다.
7-2. PoC → MVP → 확장, 단계를 뚜렷이 끊어라
처음부터 완벽한 플랫폼을 만들려 하면 높은 확률로 실패한다. PoC(개념 증명) 단계에서는 “이 AI 접근법이 우리 도메인에서 기술적으로 가능한가”를 검증한다. 여기서 합격점을 받아야 MVP로 넘어간다. MVP는 실제 엔지니어 몇 명이 쓸 수 있는 수준으로 만드는 것이다. 이 단계에서 현장 피드백을 받고, 그 후에 확장한다.
PoC에서 MVP로 넘어가지 못하고 실험만 반복하는 “파일럿 지옥(Pilot Purgatory)”에 빠지는 프로젝트가 의외로 많다. 단계마다 명확한 성공 기준(Success Criteria)을 정의해두는 것이 이를 막는 유일한 방법이다.
7-3. 물리 팀과 AI 팀 사이에 ‘인터페이스 엔지니어’를 두어라
두 팀을 같은 팀으로 묶어놓고 알아서 협업하라고 하면 안 된다. CAE 도메인과 AI 기술을 모두 이해하는 “인터페이스 엔지니어” 역할의 사람이 필요하다. 이 사람이 없으면 PM이 직접 그 역할을 해야 하는데, 그러면 PM의 에너지가 기술 중재에 다 소진된다.
실제로 이런 역할을 하는 사람이 팀에 있을 때와 없을 때의 프로젝트 진행 속도 차이는 두 배 이상 난다.
7-4. 검증(Validation) 계획을 처음부터 세워라
AI 모델이 만든 시뮬레이션 결과가 “맞다”고 어떻게 증명할 것인가? 이 질문에 대한 답을 프로젝트 시작 전에 가지고 있어야 한다. 기존 고정밀 해석 결과와의 비교, 실험 데이터와의 비교, 전문가 리뷰 — 이 중 어떤 방법을 어느 기준으로 사용할 것인지 미리 합의해야 한다.
이걸 나중에 정하겠다고 미루면, 완성 직전에 “이 결과를 믿을 수 있냐”는 논쟁으로 프로젝트가 지연된다.
7-5. 컴퓨팅 자원 계획은 별도로 세워라
HPC 클러스터 구축이든 클라우드 GPU 사용이든, 컴퓨팅 자원 비용과 조달 일정은 별도의 세부 계획으로 관리해야 한다. 클라우드 GPU 사용량을 예측 없이 썼다가 예산이 폭발하는 경우가 있고, 온프레미스 HPC를 구매하려고 했더니 납기가 6개월이 넘는 경우도 있다.
한국 국가대표 AI 프로젝트에서도 GPU 환경 최적화와 데이터 공급이 초기 계획보다 더디게 진행되면서 전체 일정이 밀렸다는 사례가 나왔다. 이런 자원 수급 리스크를 프로젝트 초기에 식별하고 대응 계획을 세우는 것은 PM의 기본 역무다.
8. 비교 분석 — 전통 CAE 프로젝트 vs AI+CAE 플랫폼 프로젝트
이 두 가지를 같은 기준으로 관리하면 반드시 탈이 난다. 무엇이 다른지 명확히 보자.
| 비교 항목 | 전통 CAE 프로젝트 | AI+CAE 플랫폼 프로젝트 |
|---|---|---|
| 요구사항 명확도 | 비교적 명확 (해석 수행) | 불명확한 경우 많음 (AI “최적화” 기대) |
| 성공 기준 | 해석 결과 오차 범위 | 학습 정확도, 속도 향상률 등 복합 |
| 핵심 리스크 | 해석 정확도, 납기 | 데이터 부족, 모델 신뢰성, 현장 수용성 |
| 팀 구성 | 해석 엔지니어 중심 | 해석 + AI + 데이터 + 인프라 멀티 도메인 |
| 전형적 일정 패턴 | 후반 해석 병목 | 초반 데이터 구축 병목 |
| 변경 관리 난이도 | 중간 | 매우 높음 (AI 모델 재학습 필요) |
| 운영 이관 복잡도 | 낮음 | 높음 (지속 학습, 모델 유지보수) |
가장 주목해야 할 차이는 “운영 이관”이다. 전통 CAE는 일단 도구가 안정화되면 엔지니어가 익숙하게 쓴다. 하지만 AI 모델은 시간이 지나면 성능이 저하될 수 있고(데이터 드리프트), 새로운 설계 유형이 나오면 재학습이 필요하다. 이걸 운영 팀이 할 수 있는 체계를 프로젝트 단계에서부터 설계해야 한다. “만들어서 넘기면 끝”이 아니라는 것이다.
9. 실패 패턴과 성공 요인 — 이걸 알면 반은 먹고 간다
실패 패턴 요약
기술 과신형 실패: AI 모델이 학습 데이터 범위를 벗어난 케이스에서 크게 틀리는데, 이를 검증 단계에서 걸러내지 못하고 배포했다가 신뢰를 한 번에 잃는 경우.
조직 소외형 실패: 기술 팀이 멋진 플랫폼을 만들었는데 현장 엔지니어들이 기존 방식을 고수하며 안 쓰는 경우. 변화 관리(Change Management)를 기술 개발과 병행하지 않은 결과.
범위 폭증형 실패: CAE AI 가속화로 시작했다가 중간에 디지털 트윈도 해보자, 공장 전체로 확장해보자 — 이런 식으로 범위가 늘어나다가 아무것도 못 마무리하는 경우. 특히 발주처 경영진이 중간에 “우리도 저거 해보자”를 반복할 때 취약하다.
파일럿 지옥형 실패: PoC를 성공적으로 마쳤는데 MVP로 전환이 안 되는 경우. 예산 조달 실패, 내부 승인 지연, PoC와 실제 운영 환경의 차이 — 이런 이유들로 파일럿만 계속 반복하다 프로젝트가 유야무야되는 경우다.
성공 요인 요약
성공한 프로젝트들을 보면 몇 가지 공통점이 있다.
명확한 비즈니스 임팩트 정의: “해석 시간 30% 단축”처럼 측정 가능한 목표가 있었다.
소규모 선 검증: 전체 제품 라인이 아닌 특정 부품, 특정 공정에서 먼저 증명했다.
현장 엔지니어 공동 개발: AI 팀이 만든 것을 엔지니어에게 보여주는 게 아니라, 처음부터 같이 만들었다.
명확한 검증 기준과 합의: AI 결과의 신뢰도를 어떻게 측정하고 어떤 기준에서 운영에 투입할지 미리 합의했다.
10. PM이 지금 당장 준비해야 할 것
이 프로젝트를 받게 될 가능성이 있는 PM이라면, 혹은 이미 진행 중인 PM이라면, 다음을 점검해보자.
1) CAE 도메인 최소 이해: FEM, CFD, 경계 조건, 메시 품질 — 이 용어들의 개념 수준은 가지고 있어야 한다. 엔지니어와 대화가 가능해야 하기 때문이다.
2) AI 모델 생애주기 이해: 데이터 수집 → 전처리 → 학습 → 검증 → 배포 → 모니터링 → 재학습. 이 사이클을 이해해야 일정을 제대로 잡을 수 있다.
3) 이해관계자 맵 작성: 발주처 경영진, 현장 엔지니어, AI 개발팀, 인프라팀, 최종 사용자 — 각각의 기대와 우려가 다르다. 이걸 처음부터 정리해두지 않으면 나중에 각 방향에서 날아오는 요구를 감당하기 어렵다.
4) 데이터 가용성 사전 실사: 프로젝트 수주 전에, 발주처가 보유한 CAE 해석 데이터의 양과 질을 확인해야 한다. “나중에 수집하면 된다”는 말을 곧이곧대로 믿으면 안 된다.
5) 컴퓨팅 자원 리스크 등록: GPU 조달 일정, 클라우드 비용 추정, 온프레미스 vs 클라우드 의사결정 — 이것들이 리스크 등록부에 올라가 있어야 한다.
마치며 — 이 프로젝트가 어려운 이유와 그래도 해야 하는 이유
AI+CAE 플랫폼 개발은 솔직히 어렵다. 도메인 전문성, AI 기술, 인프라, 그리고 조직 관리가 동시에 요구되는 복합 프로젝트다. 실패 사례도 많다.
그런데 이 흐름을 외면하면 더 큰 문제가 생긴다. 경쟁사가, 발주처의 경쟁사가, 해외 기업들이 이 플랫폼을 내재화하고 있는 동안 우리만 예전 방식으로 남아있을 수는 없다.
2025년 CAE 컨퍼런스에서 “시뮬레이션의 미래는 AI와 디지털 트윈”이라는 주제가 채택된 것, 정부가 7,500억 원 규모의 AI 응용 상용화 사업을 밀어붙이는 것, NVIDIA가 실시간 물리 시뮬레이션에 전사적 자원을 투입하는 것 — 이 흐름은 되돌릴 수 없다.
PM의 역할은 이 어려운 프로젝트를 “그냥 되게 해주는 마법사”가 아니다. 기술의 가능성과 현실의 제약 사이에서, 발주처의 기대와 팀의 한계 사이에서, 완벽함과 납기 사이에서 — 최선의 균형을 찾아 프로젝트를 앞으로 나아가게 하는 사람이다.
설계실에서 클라우드로, 수식 해석에서 AI 추론으로 — 시뮬레이션의 세계가 바뀌고 있다. 그 변화 한가운데에 우리가 관리하는 프로젝트가 있다.