DUCTILE: Agentic LLM Orchestration of Engineering Analysis in Product Development Practice

이 논문은 제품 개발 과정에서 도구와 데이터 형식의 변화로 인해 기존 자동화가 실패하는 문제를 해결하기 위해, LLM 에이전트가 유연하게 작업을 조정하고 엔지니어가 최종 판단을 내리는 'DUCTILE'이라는 새로운 엔지니어링 분석 자동화 접근법을 제안하고 항공우주 산업의 구조 해석 사례를 통해 그 유효성을 입증했습니다.

핵심

🚀 제목: "DUCTILE(ductile: 연성)" - 유연한 AI 지휘자

1. 문제: "유리처럼 깨지기 쉬운 자동화"

지금까지 공학자들은 컴퓨터 프로그램을 짜서 작업을 자동화했습니다. 하지만 이 자동화 프로그램은 유리잔과 비슷합니다.

• 상황: 공학자들은 설계 도면, 데이터 파일, 사용하는 프로그램 등을 매일 바꿉니다. 파일 이름이 바뀌거나, 단위 (미터 vs 인치) 가 달라지거나, 파일 형식 (JSON vs YAML) 이 조금만 변해도, 기존에 짜둔 자동화 프로그램은 바로 깨져버립니다.
• 결과: 엔지니어들은 멋진 제품을 설계하는 대신, 깨진 프로그램을 고치거나 데이터를 일일이 정리하는 '데이터 정리' 작업에 시간을 다 보냅니다.

2. 해결책: "AI 지휘자 (에이전트) 와 인간 오케스트라"

이 논문은 새로운 방식을 제안합니다. 모든 일을 AI 가 다 하는 게 아니라, AI 를 '지휘자'로, 기존 검증된 공학 도구들을 '악기'로 활용하는 것입니다.

• 비유:
  • 기존 방식 (유리): 악보 (코드) 가 딱 정해져 있어서, 악기 하나만 바뀌면 연주 전체가 멈춥니다.
  • DUCTILE 방식 (연성/ductile): AI 지휘자가 악보와 악기 상태를 실시간으로 봅니다.
    • "아, 오늘 바이올린 대신 첼로가 왔네? 그럼 지휘법을 살짝 바꿔서 연주하자."
    • "악보에 실수가 있네? 내가 바로 수정해서 연주할게."
    • 핵심: AI 는 계산 자체를 하지 않습니다. (그건 검증된 공학 도구가 합니다.) AI 는 "어떻게, 어떤 순서로 도구를 쓸지"를 지시할 뿐입니다.

3. 실제 실험: "항공기 엔진 부품 테스트"

이 아이디어를 실제 항공기 엔진 부품 (터빈 후방 구조물) 제작 현장에 적용해 보았습니다.

• 시나리오: 고객사 (엔진 제조사) 에서 보낸 데이터가 예전과 4 가지나 달랐습니다.
  1. 파일 형식이 바뀌었다.
  2. 단위 (파운드 vs 킬로그램) 가 달랐다.
  3. 부품 이름 표기가 달랐다.
  4. 계산 방법이 약간 수정되었다.
• 기존 방식: 자동화 스크립트가 바로 멈추고, 엔지니어가 수동으로 고쳐야 했습니다.
• DUCTILE 방식: AI 지휘자가 데이터를 보고 "아, 파일이 YAML 이네? JSON 으로 바꿔서 읽어야겠다. 단위가 인치네? 미터로 바꿔야겠다" 라고 스스로 판단하여, 기존에 있던 공학 도구들을 올바른 순서로 작동시켰습니다.
• 결과: AI 가 10 번을 반복해도 10 번 모두 정확한 결과를 냈습니다.

4. 인간의 역할: "감독관"

여기서 중요한 점은 AI 가 모든 걸 결정하는 게 아니라는 것입니다.

• 비유: AI 는 똑똑한 비서이고, 엔지니어는 사장님입니다.
  • 비서 (AI) 가 "이 파일을 이렇게 처리하면 어떨까요?"라고 계획을 세우고 실행합니다.
  • 사장님 (엔지니어) 은 그 계획을 보고 "좋아, 이대로 해" 라고 승인하거나, "잠깐, 여기가 이상한데?" 라고 지적합니다.
• 왜 중요한가요? 항공기나 자동차는 안전이 최우선입니다. AI 가 실수할 수도 있으니까, 최종적인 책임과 판단은 항상 사람이 가져야 합니다.

5. 결론: "지루한 일은 AI 가, 중요한 결정은 사람이"

이 연구는 AI 가 엔지니어의 능력을 대체하는 것이 아니라, 엔지니어가 지루하고 반복적인 '데이터 정리'와 '프로그램 고치기'에서 해방되게 해준다는 것을 보여줍니다.

• 기존: 엔지니어 = 데이터 정리가 90%, 설계가 10%
• DUCTILE: 엔지니어 = 설계와 판단이 90%, 데이터 정리는 AI 가 처리

한 줄 요약:

"유리처럼 깨지기 쉬운 자동화 대신, AI 지휘자가 상황에 맞춰 유연하게 지휘하고, 인간 엔지니어는 최종 감독관으로서 안전하고 멋진 제품을 만들어내는 새로운 방식입니다."

이 방식이 보편화되면, 엔지니어들은 더 이상 "파일 이름이 왜 바뀌었지?"라고 짜증 내는 대신, "어떻게 하면 더 안전한 비행기를 만들까?"라는 더 중요한 고민에 집중할 수 있게 될 것입니다.

기술 요약

1. 문제 정의 (Problem Statement)

• 엔지니어링 자동화의 취약성 (Brittleness): 제품 개발 과정에서 엔지니어링 분석 자동화는 도구, 데이터 형식, 문서화된 프로세스 간의 경직된 인터페이스에 의존합니다. 제품이 진화함에 따라 이러한 인터페이스 (파일 형식, 단위, 명명 규칙, 방법론 등) 가 변경되면 기존 스크립트 기반 자동화 파이프라인은 즉시 실패합니다.
• 기존 접근법의 한계:
  • 규칙 기반 확장 (KBE, PIDO): 더 많은 규칙을 추가하여 상황을 커버하려 하지만, 복잡성이 증가하고 새로운 실패 모드를 생성합니다.
  • 전문가 의존: 변경 사항이 발생하면 전문가가 수동으로 대응해야 하므로, 지식이 개인에게 집중되어 조직적 취약성을 초래하고 속도가 느립니다.
• 핵심 과제: 변화하는 엔지니어링 생태계 (도구 업데이트, 요구사항 변경 등) 에 적응하면서도, 안전성과 추적 가능성이 보장된 엔지니어링 분석 작업을 자동화할 수 있는 새로운 방식이 필요합니다.

2. 제안된 방법론: DUCTILE (Methodology)

이 논문은 DUCTILE(Delegated, User-supervised Coordination of Tool- and document-Integrated LLM-Enabled) 이라는 새로운 접근법을 제안합니다. 이는 LLM 기반 에이전트 (Agent) 를 활용하여 엔지니어링 분석 작업을 자동화하는 프레임워크입니다.

• 핵심 원리: 적응형 오케스트레이션과 결정론적 실행의 분리

  • 적응형 오케스트레이션 (Adaptive Orchestration): LLM 에이전트가 수행합니다. 문서화된 설계 관행을 해석하고, 입력 데이터를 검사하며, 컨텍스트에 맞게 처리 경로를 동적으로 조정합니다.
  • 결정론적 실행 (Deterministic Execution): 검증된 엔지니어링 도구 (상용 솔버, 검증된 스크립트 등) 가 수행합니다. LLM 은 계산 자체를 수행하지 않고, 해당 도구를 호출하는 코드와 명령을 생성합니다.
  • 인간 감독: 엔지니어는 계획을 검토하고, 실행을 감독하며, 최종 결과를 승인합니다.

• 기술적 구현 요소:

  • 생각 모드 (Thinking Mode): LLM 이 초기 응답을 결정하기 전에 스스로 비판하고 대안을 모색할 수 있도록 하여, 모호한 상황이나 예외 처리 능력을 향상시킵니다.
  • 도구 호출 (Tool Calling): LLM 이 외부 데이터베이스나 계산 도구를 직접 호출하여 검증된 정보를 기반으로 답변을 생성하도록 합니다.
  • 관찰 가능성 및 추적성: 모든 에이전트의 행동 (생각 과정, 도구 호출, 생성된 코드) 은 엔지니어가 직접 검토할 수 있도록 투명하게 기록됩니다.

3. 주요 기여 (Key Contributions)

1. DUCTILE 프레임워크 제안: 엔지니어링 분석 작업을 위한 LLM 기반 에이전트 자동화 개발, 실행 및 평가를 위한 체계적인 방법론을 제시했습니다. 이는 LLM 의 유연성과 검증된 도구의 엄격함을 결합합니다.
2. 산업적 검증 사례: 항공우주 제조사 (GKN Aerospace) 의 실제 구조 분석 작업 (터빈 후방 구조물, TRS) 에 적용하여 성공적으로 검증했습니다.
   • 4 가지 입력 편차 처리: 기존 자동화 파이프라인이 실패했을 4 가지 시나리오 (YAML 대 JSON 파일 형식 변경, 단위계 변경, 노드 명명 규칙 변경, OEM 의 수정 계수 적용) 를 에이전트가 성공적으로 해결했습니다.
   • 다양한 감독 스타일 검증: 두 명의 엔지니어 (전체 작업 위임형 vs 단계별 발견형) 가 동일한 에이전트 설정을 사용했을 때, 모두 동일한 정확한 결과를 도출했음을 확인했습니다.
3. 평가 지표 및 기준 마련: 항공우주 구조물 인증 기준 (S-Basis, B-Basis, A-Basis) 에서 영감을 받아, 에이전트의 신뢰성을 평가하기 위한 Pass-$k$ 지표를 도입했습니다. (예: 배포 시 95% 신뢰도를 위해 10 회 이상의 독립 실행에서 모두 통과해야 함).

4. 실험 결과 (Results)

• 성공적 편차 처리: 에이전트는 파일 형식 (YAML→JSON), 단위 변환 (Imperial→SI), 노드 이름 매핑, 그리고 OEM 의 수정 계수 (1.04) 적용 등 4 가지 변경 사항을 모두 식별하고 처리했습니다.
• 일관성 및 재현성: 동일한 시나리오에서 10 회 독립 실행을 수행한 결과, 모든 실행이 정량적 (최종 값 비교) 및 정성적 (LLM-as-a-judge 평가) 기준을 100% 통과했습니다.
• 엔지니어 수용성:
  • 엔지니어는 에이전트가 생성한 스크립트와 중간 결과를 직접 검토할 수 있었으며, 에이전트의 의사결정 과정을 투명하게 파악했습니다.
  • 복잡한 데이터 정제 (Data Wrangling) 작업이 줄어들어 엔지니어가 실제 엔지니어링 의사결정에 집중할 수 있게 되었습니다.

5. 의의 및 시사점 (Significance)

• 엔지니어링 자동화의 패러다임 전환: 경직된 규칙 기반 자동화에서, 변화에 적응할 수 있는 에이전트 기반 오케스트레이션으로의 전환을 제시합니다. 이는 제품 개발 주기 동안 발생하는 지속적인 변경 사항을 흡수할 수 있는 '연성 (Ductility)'을 제공합니다.
• 지식 관리 및 조직적 회복탄력성: 암묵지 (Tacit Knowledge) 를 문서화하고 에이전트가 이를 학습하도록 함으로써, 특정 개인에게 의존하던 조직적 취약성을 줄이고 지식의 계승을 용이하게 합니다.
• 안전성과 혁신의 균형: LLM 의 확률적 특성을 완전히 배제하지 않으면서도, 검증된 도구를 통해 엔지니어링의 엄격함과 추적 가능성을 유지합니다. 이는 항공우주 및 자동차와 같은 안전 필수 (Safety-critical) 산업에서 AI 도입을 위한 실용적인 길잡이가 됩니다.
• 주의점 및 미래 과제: 에이전트가 엔지니어의 판단력을 대체해서는 안 되며, 오히려 엔지니어가 더 높은 수준의 감독 역할을 수행해야 함을 강조합니다. 또한, 문서화된 프로세스가 명확하지 않은 경우 적용에 한계가 있음을 지적했습니다.

결론적으로, 이 논문은 LLM 에이전트가 단순한 도구를 넘어, 변화하는 엔지니어링 환경에서 도구와 프로세스를 유연하게 연결하는 '오케스트레이터' 역할을 수행할 수 있음을 실증적으로 증명했습니다.