🤖 AI

Automating Structural Analysis Across Multiple Software Platforms Using Large Language Models

이 논문은 다중 에이전트 아키텍처를 활용하여 사용자 입력을 구조화하고 이를 ETABS, SAP2000, OpenSees 등 여러 구조 해석 소프트웨어에서 실행 가능한 스크립트로 자동 변환하는 대규모 언어 모델 (LLM) 기반 프레임 구조 분석 시스템을 개발하여 90% 이상의 정확도로 검증한 연구입니다.

원저자: Ziheng Geng, Jiachen Liu, Ian Franklin, Ran Cao, Dan M. Frangopol, Minghui Cheng

게시일 2026-04-14

📖 3 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Ziheng Geng, Jiachen Liu, Ian Franklin, Ran Cao, Dan M. Frangopol, Minghui Cheng

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

🏗️ 1. 문제 상황: "모든 요리사가 다른 조리법을 쓰는 상황"

건축 엔지니어들은 건물의 안전성을 계산할 때 ETABS, SAP2000, OpenSees라는 세 가지 다른 '요리 도구 (소프트웨어)'를 사용합니다.

ETABS는 한국식 김치찌개 레시피처럼 계단별로 재료를 넣어야 합니다.
SAP2000은 일식 요리처럼 모든 재료를 하나하나 정교하게 배치해야 합니다.
OpenSees는 프랑스 요리처럼 코드로 직접 명령을 내려야 합니다.

기존의 AI 는 한 가지 도구만 다룰 수 있었습니다. 마치 "김치찌개는 잘하지만, 일식 요리나 프랑스 요리는 전혀 모르는 요리사"와 같습니다. 엔지니어는 건물을 설계할 때 상황에 따라 도구를 바꿔야 하므로, 이 AI 들은 실용성이 떨어졌습니다.

🤖 2. 이 연구의 해결책: "명령을 번역하는 '스마트 팀' (멀티 에이전트)"

이 논문은 **세 가지 도구를 모두 다룰 수 있는 'AI 팀'**을 만들었습니다. 이 팀은 혼자 일하는 것이 아니라, 서로 역할을 나누어 협력하는 2 단계 프로세스를 사용합니다.

1 단계: "설계도 해석 팀" (의사소통과 계획)

사용자가 "3 층짜리 건물을 만들고, 50 톤의 하중을 가해줘"라고 말하면, 이 팀이 그 말을 듣고 **중립적인 설계도 (JSON 파일)**로 바꿉니다.

문제 분석가: 사용자의 말을 듣고 핵심 숫자 (기둥 높이, 재료 강도 등) 를 뽑아냅니다.
건설 계획가: "기둥을 먼저 세우고, 그 위에 보를 얹는 순서"를 정합니다.
노드/요소 담당자: 기둥과 보의 위치를 좌표로 정확히 계산합니다.
하중 담당자: 어디에 얼마만큼의 무게가 실리는지 표시합니다.

비유: 마치 건축 설계사가 "이런 집을 지어줘"라는 말만 듣고, 어떤 도구를 쓰든 상관없이 완벽한 건축 도면을 그려내는 것과 같습니다.

2 단계: "번역 팀" (각 도구에 맞는 명령어 변환)

중립적인 설계도 (JSON) 가 만들어지면, 이제 각 소프트웨어에 맞는 전문 번역가들이 나섭니다.

OpenSees 번역가: 설계도를 OpenSees 가 알아듣는 코드로 바꿉니다.
SAP2000 번역가: 설계도를 SAP2000 의 표 형식으로 바꿉니다.
ETABS 번역가: 설계도를 ETABS 의 '층별 (Story)' 방식에 맞게 재배열한 뒤 코드로 바꿉니다.

비유: 같은 '건축 도면'을 가지고, 한국인 요리사, 일본인 요리사, 프랑스인 요리사에게 각각 자국 언어로 된 조리법을 만들어 주는 것과 같습니다.

🚀 3. 왜 이 기술이 특별한가요? (기존 AI 와의 비교)

연구진은 최신 AI (GPT-5, Gemini 등) 와 비교 실험을 했습니다. 결과는 놀라웠습니다.

기존 AI (단일 요리사):
- "OpenSees"는 18% 만 성공하고, "SAP2000"과 "ETABS"는 100% 실패했습니다.
- 이유: 문법 (레시피) 을 잘못 이해하거나, 건물의 구조를 엉뚱하게 해석했습니다. (예: 2 층짜리 건물을 3 층으로 잘못 만듦)
이 연구의 AI (스마트 팀):
- 90% 이상의 정확도로 세 가지 소프트웨어 모두에서 성공했습니다.
- 이유: 복잡한 구조를 먼저 논리적으로 이해한 뒤 (1 단계), 각 도구의 규칙에 맞춰 번역 (2 단계) 하기 때문입니다.

⏱️ 4. 효율성과 비용

속도: 세 가지 소프트웨어의 코드를 동시에 만드는 데 약 2 분이 걸립니다.
비용: 한 번의 작업당 약 1~~2 센트 (0.01~~0.02 달러) 정도만 듭니다.
효과: 엔지니어가 직접 코드를 짜거나 실수할 걱정을 덜고, AI 가 만든 파일을 바로 확인하고 분석만 하면 됩니다.

💡 요약

이 논문은 **"하나의 AI 가 모든 것을 다 할 수 없다면, 역할을 나누어 협력하는 팀을 만들어라"**는 아이디어를 증명했습니다.

마치 **건축 설계도 (중립적 데이터)**를 바탕으로, 한국식, 일식, 프랑스식 조리법 (각종 소프트웨어) 을 자동으로 만들어주는 초고급 주방 팀을 만든 것과 같습니다. 이제 엔지니어들은 복잡한 소프트웨어의 문법을 외울 필요 없이, 자연어로 "이런 건물을 만들어줘"라고 말하면 AI 가 모든 것을 처리해 줄 수 있게 되었습니다.

1. 연구 배경 및 문제 제기 (Problem)

현재의 한계: 대형 언어 모델 (LLM) 의 발전으로 구조 모델링 및 해석 워크플로우 자동화의 가능성이 열렸으나, 기존 연구들은 주로 단일 구조 해석 소프트웨어 플랫폼 (예: OpenSees, SAP2000 등) 에만 초점을 맞추고 있습니다.
실무적 요구: 실제 구조 엔지니어링 현장에서는 프로젝트 요구사항, 사용자 선호도, 회사 제약 등에 따라 ETABS, SAP2000, OpenSees 등 여러 유한요소해석 (FEA) 도구를 병행하여 사용합니다.
핵심 문제: 단일 플랫폼 전용 LLM 은 실무 적용에 제한이 있으며, 각 소프트웨어 환경마다 별도의 LLM 을 훈련시키는 것은 확장성과 채택에 비효율적입니다. 따라서 다양한 소프트웨어 플랫폼을 아우르는 범용 자동화 시스템의 부재가 주요 과제로 대두되었습니다.

2. 제안된 방법론 (Methodology)

이 연구는 2 단계 다중 에이전트 (Multi-Agent) 아키텍처를 도입하여 자연어 입력을 다양한 FEA 소프트웨어의 실행 가능한 스크립트로 변환하는 시스템을 개발했습니다.

1 단계: 입력 해석 및 의미 추론 (Input Interpretation & Semantic Reasoning)

목표: 사용자의 자연어 문제 설명을 FEA 모델링에 필요한 구조적 정보 (기하, 재료, 경계조건, 하중) 로 변환하고, 이를 플랫폼 중립적인 통합 JSON 형식으로 표준화합니다.
에이전트 구성 (GPT-OSS 120B 기반):
1. 문제 분석 에이전트: 자연어에서 기하학적 파라미터, 지지 조건, 하중 등을 추출.
2. 시공 계획 에이전트: 하단에서 상단, 좌측에서 우측으로의 결정론적 조립 논리 수립.
3. 노드 및 요소 에이전트: 좌표, 지지 유형, 요소 연결성 등을 도출.
4. 하중 할당 에이전트: 하중을 적절한 노드와 요소에 매핑.
산출물: 모든 정보가 포함된 표준화된 JSON 파일.

2 단계: 병렬 코드 변환 (Parallel Code Translation)

목표: 1 단계에서 생성된 통합 JSON 을 각 타겟 소프트웨어 (OpenSees, SAP2000, ETABS) 에 맞는 실행 가능한 스크립트로 변환합니다.
에이전트 구성 (Llama-3.3 70B Instruct Turbo 및 GPT-OSS 120B 기반):
- OpenSees 및 SAP2000:
  - 기하 변환 에이전트: JSON 의 기하 정보를 각 플랫폼의 문법에 맞는 명령어로 변환.
  - 코드 컴파일 에이전트: 기하, 하중, 분석 설정 모듈을 통합하여 실행 가능한 스크립트 (.tcl, .s2k) 생성.
- ETABS (특수 처리):
  - ETABS 는 '스토리 (Story)' 기반 모델링 로직을 사용하므로, **시맨틱 매핑 에이전트 (Semantic Mapping Agent)**가 추가됩니다. 이 에이전트는 객체 기반의 JSON 정의를 ETABS 고유의 스토리 레벨 표현으로 변환한 후, 나머지 에이전트들이 스크립트 (.e2k) 를 생성합니다.
특징: 각 플랫폼별 변환 파이프라인이 병렬로 실행되어 효율성과 확장성을 확보합니다.

3. 주요 기여 (Key Contributions)

다중 플랫폼 호환성: 단일 모델로 OpenSees, SAP2000, ETABS 등 상용 및 오픈소스 FEA 소프트웨어를 모두 지원하는 최초의 LLM 기반 자동화 프레임워크를 제시했습니다.
2 단계 다중 에이전트 아키텍처: 고수준 의미 추론 (1 단계) 과 플랫폼별 코드 생성 (2 단계) 을 분리함으로써, 추론 능력과 문법 정확도를 동시에 최적화했습니다.
표준화 인터페이스: 다양한 소프트웨어의 복잡한 문법 차이를 극복하기 위해 '통합 JSON'이라는 중간 표현 계층을 도입하여 플랫폼 간 이식성을 확보했습니다.
비용 효율성: 고가의 상용 LLM 대신 경량 오픈소스 모델 (GPT-OSS-120B, Llama-3.3-70B) 을 활용하여 저비용으로 고품질 결과를 도출하는 방안을 제시했습니다.

4. 실험 결과 (Results)

평가 데이터셋: 20 개의 대표적인 프레임 구조 해석 문제 (불규칙한 토폴로지 포함) 를 3 가지 플랫폼 (OpenSees, SAP2000, ETABS) 에서 평가했습니다. 각 문제는 10 회 반복 실행하여 정확도를 측정했습니다.
성능:
- 제안된 모델: 모든 플랫폼에서 90% 이상의 일관된 정확도를 달성했습니다.
  - OpenSees: 평균 98%
  - SAP2000: 평균 100% (완벽한 정확도)
  - ETABS: 평균 99%
- 기존 최첨단 모델 (GPT-5.2, Gemini-3-Pro) 과의 비교:
  - GPT-5.2: OpenSees 에서 18% 정확도, SAP2000 과 ETABS 에서는 **0%**로 실패. 문법 오류와 시맨틱 추론 부족 (예: 잘못된 요소 연결, 누락된 노드) 이 주된 원인.
  - Gemini-3-Pro: OpenSees 에서 79% 정확도였으나, SAP2000 과 ETABS 에서는 **0%**로 실패. 특히 ETABS 의 스토리 기반 모델링 로직을 이해하지 못해 실패했습니다.
효율성 및 비용:
- 실행 시간: 플랫폼별 약 2 분 내외 (병렬 처리) 로 스크립트 생성 가능.
- 비용: 문제당 플랫폼당 약 $0.012 ~$ 0.025로, 상용 모델 대비 매우 경제적임.

5. 의의 및 결론 (Significance)

실무 적용 가능성: 이 연구는 엔지니어가 익숙한 소프트웨어를 유지하면서 수동 모델링 노력을 줄이고 문법 오류를 최소화할 수 있는 'Human-in-the-loop' 자동화 솔루션을 제공합니다.
신뢰성 확보: 생성된 스크립트를 STKO, SAP2000 GUI 등을 통해 시각화하고 검증할 수 있어, 엔지니어의 최종 검증을 통한 의사결정을 지원합니다.
미래 전망: 현재는 직사각형 프레임 구조에 국한되어 있으나, 이 아키텍처는 보강재 시스템이나 캔틸레버 등 더 복잡한 구조 유형으로 확장 가능하며, 실제 현장의 다양한 시나리오에 적용될 잠재력이 큽니다.

결론적으로, 본 논문은 LLM 이 단일 도구를 넘어 다양한 공학 소프트웨어 생태계에서 신뢰할 수 있는 자동화 도구로 작동할 수 있음을 입증하며, 구조 공학 분야의 디지털 전환을 가속화할 수 있는 중요한 기술적 토대를 마련했습니다.