Ansys 공식 PyAEDT-MCP 공개, 이제 해석이 자동으로 될까?
김홍석 | 2026년 09월 17일 | 3Ansys가 PyAEDT용 공식 MCP 서버를 공개했습니다. 문서를 처음 열어봤을 때 든 생각은 "드디어"와 "이것만으로는 안 되겠는데"가 반반이었습니다.
드디어, 인 이유는 분명합니다. 그동안 AI를 해석 도구에 붙이려면 각자 알아서 해야 했습니다. 우리도 그랬고, 다른 회사도 그랬을 겁니다. 붙이는 방식이 제각각이니 만들어놓고도 다음 버전에서 깨지고, 남이 만든 걸 가져다 쓸 수도 없었습니다. 이제 그 부분이 정리됐습니다. 새 도구의 MCP가 나오면 연결만 하면 됩니다. 코드를 다시 짜지 않아도 됩니다.
이게 작은 변화가 아닙니다. 다만 이걸로 해석 업무가 끝나느냐는 다른 얘기입니다.
공식 MCP가 실제로 주는 것
문서를 보면 범위가 깔끔하게 정리돼 있습니다.
| 구분 | 기능 |
|---|---|
| 연결 · 세션 관리 | 설치 · 실행 상태 확인, AEDT 실행 또는 기존 세션 연결, 로그 확인 |
| 프로젝트 · 디자인 | 프로젝트 열기 · 저장, 목록 조회, 새 디자인 생성 |
| 해석 · 결과 처리 | 설정된 해석 실행, sNp · 수렴 · mesh export, 모델 정보와 3D 화면 조회 |
| 코드 생성 · 실행 | 미지원 작업은 가이드라인에 따라 코드 작성 후 실행 |
연결하고, 실행하고, 결과를 꺼내옵니다. 무엇을 왜 해석할지는 들어 있지 않습니다.
당연합니다. 범용 프로토콜이 EMC 규격까지 알고 있을 이유가 없습니다. 한계라고 부를 일도 아닙니다. 애초에 그걸 하려고 만든 물건이 아니니까요.
문제는 우리 업무에서 시간이 드는 구간이 정확히 그 바깥이라는 점입니다.
해석은 창작 도구와 다르다
요즘 나오는 MCP 사례들은 대부분 창작 쪽입니다. 3D 모델링, 영상 편집, 음악. 거기서 AI가 실수하면 되돌리기를 누르면 됩니다. 몇 초 손해입니다.
해석에서는 포트를 잘못 잡고 돌린 해석이 몇 시간을 먹습니다. 그것보다 나쁜 경우는 틀린 결과가 멀쩡한 그래프로 나오는 것입니다. 그래프가 이상하면 다시 보는데, 그럴듯하면 그대로 설계 판단으로 넘어갑니다.
EMC는 마지막에 시험소에서 확인받는 분야입니다. 해석과 시험이 어긋나면 그 비용은 해석 시간이 아니라 개발 일정으로 계산됩니다. ISO 쪽 표준 작업에 참여하면서 가상평가 논의를 계속 보고 있는데, 거기서도 결국 돌아오는 질문은 하나입니다.
“그 결과를 믿을 근거가 무엇이냐.”
그래서 자동화를 어디까지 맡길지 정할 때 우리가 보는 건 세 가지입니다.
01판정 기준이 어디서 오는가
결과를 뽑는 것과 합부를 판정하는 것은 다른 일입니다. CISPR 25 CE 한계선이 어느 클래스 기준이고 여유를 얼마나 볼 것인지가 정해져 있어야 판정이 성립합니다.
02같은 조건에서 같은 결과가 나오는가
LLM이 매번 조금씩 다른 코드를 생성하면 이 조건이 깨집니다.
03근거가 남는가
설계 리뷰에서 "AI가 그렇게 했습니다"는 답이 아닙니다.
어디서 갈리는지
공식 MCP만 놓고 작업 난이도를 나눠보면 이렇게 됩니다.
| 수준 | 작업 | MCP만으로 |
|---|---|---|
| 단순 | 프로젝트 열기, 설정된 해석 실행, S-파라미터 export | 된다 |
| 반복 | 대량 파라미터 스윕, 정해진 형식의 결과 추출 | 되지만 스크립트가 더 빠르고 싸다 |
| 판정 | 규격 한계선 대비 합부 판정 후 설계 변경 | 기준을 밖에서 넣어줘야 한다 |
| 진단 | 시스템 레벨에서 원인을 짚고 실현 가능성 판단 | 도메인 계층 없이는 도달하지 않는다 |
위 두 줄은 연결만 있으면 끝납니다. 아래 두 줄에서 갈립니다.
하나 더 짚어둘 게 있습니다. 공식 MCP에서 지원하지 않는 작업은 LLM이 생성한 코드로 수행됩니다. 실제로 돌려보면 이 부분이 결과 품질을 상당히 좌우합니다. 같은 프로토콜, 같은 솔버를 쓰는데도 결과가 다른 이유가 대개 여기입니다. 모델이 그 코드를 쓸 때 무엇을 알고 있었느냐의 차이입니다.
우리가 하는 일
그래서 공식 MCP 위에 계층을 하나 더 둡니다.
| 계층 | 하는 일 | 담당 |
|---|---|---|
| 도메인 판단 | EMC 규격 해석, 합부 판정 기준, 설계 판단 | AutoSim / CPS Tech |
| 데이터 · 지식 | 사내 물성 DB, 과거 해석 이력, 검증된 워크플로우 | AutoSim / CPS Tech |
| 오케스트레이션 | AEDT 외부 도구 연계, 다중 에이전트, 보고서 생성 | AutoSim / CPS Tech |
| 도구 접근 | 연결, 프로젝트 관리, 해석 실행, 결과 export | Ansys (PyAEDT-MCP) |
| 솔버 | 물리 계산 | Ansys |
아래 두 줄은 Ansys가 잘 만들어놨습니다. 다시 만들 이유가 없습니다.
위 세 줄이 우리 몫입니다. 규격에서 한계선을 뽑고, 결과를 읽어 판정하고, 통과 못 하면 무엇을 바꿀지 정하고, 바꾼 다음 다시 검증하는 루프. 그리고 그걸 근거와 함께 남기는 일입니다.
돌려보면 이렇게 된다
① EMI 필터 설계
지시는 한 문장이었습니다.
“Ansys Circuit을 써서 CISPR 25 CE 규제치를 만족하는 EMI 필터를 설계해줘.”
에이전트가 규격 한계선을 스스로 인출하고, 현재 상태를 해석해 어느 구간이 위반인지 확인하고, 2단 LC 필터를 구성했습니다. 여기까지는 예상한 대로였습니다.
의외였던 건 다음입니다. 재해석에서 turn-on ringing이 나오자 RC 댐퍼를 추가했습니다. 정수를 조정한 게 아니라 회로 구성을 바꾼 것입니다. 최적화 도구와 갈라지는 지점이 정확히 여기입니다. Optimetrics는 사람이 정한 변수 범위 안에서 답을 찾습니다. 토폴로지는 고정입니다.
그다음 소자 ±20% 산포 조건에서 강건성을 검증하고 BOM과 근거 표까지 만들었습니다. 시뮬레이션 명목값으로 통과한 게 아니라 양산 산포까지 보고 통과시킨 결과입니다.
여기서 목표치를 사람이 준 적이 없습니다. 목표는 규격이 정했습니다.
② 차량 시스템 레벨
차량 쪽은 규모가 다릅니다. 고전압 부품 8종과 연결 케이블, Front · Rear의 CM/DM 노이즈 소스 조합을 통합 해석했습니다. 전류 피크 상위 지점을 뽑고, 민감도 분석으로 유효 소자를 특정하고, 설계를 바꿔 재해석했습니다. 지배 피크가 10 MHz에서 25.12 MHz로 옮겨갔습니다.
그리고 에이전트가 이런 진단을 붙였습니다. 해당 부품 자체 필터로는 한계이고 인버터 내부 기생 인덕턴스를 개선해야 한다고. 목표를 맞추는 데서 멈추지 않고 원인까지 짚은 셈입니다.
③ 칩 · 패키지 레벨
칩 · 패키지 레벨은 KAIST Tera Lab 쪽 사례를 봤습니다. 사양서를 주면 bump map 조건을 도출하고, 라우팅 후보를 만들고, geometry 규칙을 스스로 검증한 뒤, 운영체제가 다른 도구를 오가며 해석까지 이어갑니다.
세 건의 판정 기준은 다 다릅니다. 설계 규칙, 국제 규격, 사람이 지정한 목표치. 판정 시점도 다릅니다. 그런데 판정하고 고치는 구조는 같습니다. 이걸 확인한 게 우리한테는 꽤 컸습니다.
남는 질문
연결 방식이 표준이 되면 도구를 붙이는 비용은 사라집니다. 좋은 일입니다. 대신 차이가 나는 지점이 위로 올라갑니다.
해석 도구는 이미 충분히 좋습니다. 남은 건 언제 어떤 기준으로 돌리고, 결과를 어떻게 판정하고, 판정한 다음 무엇을 바꿀지입니다. 프로토콜이 풀어주는 문제가 아닙니다.
AI는 이미 우리 가까이 와있습니다. 쓸모가 있느냐는 지난 질문이 됐고, 지금은 어디까지 맡길 수 있느냐가 남았습니다.
AutoSim는 Ansys 환경에서 시뮬레이션 자동화와 Agentic AI 플랫폼을 개발합니다.
지금 쓰시는 환경 그대로 PoC부터 시작할 수 있습니다.
참고 — Ansys 2026 R1 발표자료, Ansys 공식 PyAEDT-MCP 문서
※ 프리미엄 컨텐츠란?
유료회원 및 유지보수 고객에게 제공되는 컨텐츠입니다.
해석 파일 및 다양한 정보를 받아보실 수 있습니다.