내가 19개의 AI 에이전트를 사용해 물리 엔진을 설계하는 방법 (Tournament Architecture)

발행: (2026년 2월 15일 오전 05:30 GMT+9)
12 분 소요
원문: Dev.to

Source: Dev.to

저는 **PISTON**이라는 엔진 시뮬레이터를 만들고 있습니다.
이 시뮬레이터는 실제 열역학을 기반으로, 곡선 피팅이나 임의 보정 없이 첫 원리에서 마력과 토크를 예측합니다. 현재 22개의 검증된 엔진(혼다 비트 경차부터 쉐보레 LT4 슈퍼차저 V8까지)에서 8.08 % HP 오차를 기록하고 있습니다.

흥미로운 부분은 물리 자체가 아니라 그것을 어떻게 구축했는가입니다.

모든 주요 기능은 토너먼트를 거칩니다:

8 planners → 8 reviewers → 3 judges

각각 독립적으로 작업하는 19개의 AI 에이전트가 최고의 구현을 만들기 위해 경쟁합니다.

단일 에이전트 개발의 문제

단일 AI 에이전트가 복잡한 기능을 설계하고 구현하면 다음과 같은 문제가 발생합니다:

  • 앵커링 편향 – 처음 떠올린 접근 방식이 지배합니다.
  • 맹점 – 아무도 그 가정을 도전하지 않습니다.
  • 지역 최적 – 대안을 탐색하기보다 초기 프레임 내에서 최적화합니다.
  • 자기 자신과의 집단사고 – 같은 편향이 설계 → 구현 → 테스트 전 과정에 걸쳐 복합됩니다.

예측 연소 모델과 같이 (잘못된 연소 속도 방정식이 30 % 오류를 추가할 수 있는) 경우, 하나의 에이전트만으로는 충분하지 않습니다.

토너먼트 구조

Phase 1: Planning (8 Agents)

여덟 명의 독립적인 플래너가 동일한 브리프를 받습니다:

  • Feature description (예: “Exhaust Tuning Model”)
  • Technical requirements (예: “Method of Characteristics wave propagation”)
  • Integration constraints (기존 코드베이스와의 적합성)
  • Validation targets (예상 정확도 향상)

각 플래너는 데이터 구조, 알고리즘, 방정식, 파일 조직, 테스트 전략을 포함한 완전한 설계 문서를 작성합니다. 플래너들은 서로 격리된 상태에서 작업하므로 다른 사람의 결과물을 볼 수 없습니다.

왜 8명인가?
여덟 명이면 접근 방식의 진정한 다양성을 확보할 수 있습니다. 적은 수면 주제에 대한 변형만 나오지만, 여덟 명이면 3‑4개의 근본적으로 다른 아키텍처를 안정적으로 확인할 수 있습니다.

Phase 2: Review (8 Agents)

여덟 명의 독립적인 리뷰어가 모든 8개의 계획을 받습니다. 그들의 업무는 다음과 같습니다:

  1. 다섯 가지 차원에서 각 계획을 평가합니다:
    • 물리 정확도
    • 코드 품질
    • 성능
    • 유지보수성
    • 통합 위험
  2. 모든 계획 중 가장 강력한 요소를 식별합니다.
  3. 최고의 요소들을 결합한 하이브리드를 제안합니다.
  4. 물리 오류 또는 오해를 표시합니다.

리뷰는 가혹합니다. 일반적인 발견 예시는 다음과 같습니다:

  • “Plan C는 해리온 화염 온도를 사용하지만 분해 억제 보정이 없으므로 NOₓ를 40 % 과대 예측합니다.”
  • “Plan F의 데이터 구조는 크랭크‑각 단계당 O(n²) 탐색을 요구합니다 — 720 단계/사이클에서는 받아들일 수 없습니다.”
  • “Plan A, D, 그리고 G는 모두 동일한 Woschni 상관식을 사용하지만 계수 표기법이 다릅니다 — D의 것이 올바릅니다.”

Phase 3: Judging (3 Agents)

세 명의 심사가 모든 8개의 계획모든 8개의 리뷰를 받습니다. 각 심사는 독립적으로 다음을 수행합니다:

  • 우승자를 선택하거나 특정 요소들의 하이브리드를 제안합니다.
  • 상세한 근거를 작성합니다.
  • 구체적인 구현 지침을 제공합니다.

결정 로직

심사위원 합의결과
모두 3명 동의해당 계획을 채택합니다.
3명 중 2명 동의다수 의견을 채택하고 이견을 기록합니다.
의견 일치 없음기준을 명확히 하여 두 번째 라운드를 진행합니다.

실제 예시: 예측 연소

연소‑모델 토너먼트는 가장 중대한 것이었습니다. 이는 우리의 Wiebe 곡선‑피팅(본질적으로 조회 테이블)을 물리‑기반 연소 속도 예측으로 대체했습니다.

생성된 계획

#접근 방식
2Tabaczynski 엔트레인먼트‑연소(최종 우승)
2프랙탈 화염 모델
1PDF를 이용한 준‑차원 모델
1Blizard‑Keck
1k‑ε 난류를 이용한 Eddy‑연소
1하이브리드 접근 방식

주요 리뷰어 발견 사항

  • Tabaczynski + Zimont 난류 화염 속도가 가장 강력한 물리적 기반을 제공했습니다.
  • 프랙탈 접근법은 우아했지만 구현 복잡도가 ≈ 3배 더 높았습니다.
  • 두 계획에 층류 화염 속도 오류가 포함되어 있었습니다(Metghalchi‑Keck vs. Gülder – 리뷰어가 Gülder는 다른 곡선‑피팅 계수가 필요함을 발견).

심사위원 결정

세 명의 심사위원 모두 만장일치로 Tabaczynski 엔트레인먼트‑연소 계획을 선택했으며, 구체적인 내용은 다음과 같습니다:

  • Zimont 난류 화염 속도(보정 계수 (A_z = 0.56))
  • k‑K 난류 모델(회전/소용돌이 인식, (C_K = 0.50))
  • Metghalchi‑Keck 층류 화염 속도
  • 민감도 테스트: 점화 시점, 압축비, 캠 타이밍

두 차례의 독립적인 보정 실행 후 (A_z = 0.52)와 (0.56)으로 수렴했습니다. 최종 모델은 엔진 기하학만으로 연소를 예측하며, 엔진별 튜닝이 전혀 필요하지 않습니다.

결과: 8.3 % HP MAPE, 이전 곡선‑피팅 접근법 대비 1 % 이내이지만 이제 보지 못한 엔진에도 일반화됩니다.

왜 이것이 효과적인가

  1. 진정한 다양성 – 여덟 명의 에이전트가 독립적으로 동일한 문제에 접근하면 근본적으로 다른 솔루션이 나오며, 단순히 “GPT의 첫 번째 직관을 약간 변형한 여덟 가지”가 아니다.
  2. 적대적 검토 – 검토자는 결함을 찾을 모든 동기가 있으며, 자신의 작업을 검토하지 않는다.
  3. 선택보다 통합 – 하이브리드(예: “Plan C의 데이터 구조, Plan A의 핵심 알고리즘, 그리고 Plan F의 오류 처리 사용”)는 종종 단일 플랜보다 뛰어나다.
  4. 문서화된 추론 – 각 토너먼트는 약 100 페이지에 달하는 기술 문서를 생성하여, 특정 접근 방식을 선택한 이유를 인용 및 정량적 비교와 함께 보존한다.

The Numbers

12개의 토너먼트 전반에 걸쳐 12 tournaments (연소, 노크, 강제 유도, VE/헬름홀츠, 배기 튜닝, 열 전달, 마찰, 방사…

원본 내용이 여기서 잘렸습니다; 필요에 따라 계속하십시오.

통계 개요

  • 대회당 평균 플랜 수: 8
  • 대회당 평균 리뷰 수: 8
  • 판정 합의율: 83 % 만장일치, 17 % 2‑1 다수
  • Zero 두 번째 라운드 판정 필요 없음 (모두 첫 번째 통과에서 해결)
  • 리뷰어가 발견한 물리 오류: 전체 대회에서 34건
  • 전체 엔진 검증 수: 22개 엔진, 44개 데이터 포인트 (HP + TQ 각각)

언제 사용하면 안 되는가

이 접근 방식은 다음과 같은 경우 과도합니다:

  • 간단한 기능 (예: CLI 플래그 추가, 오타 수정)
  • 명확한 모범 사례가 있는 잘 이해된 문제
  • 시간에 민감한 수정

사용할 경우

  • 물리 오류가 결과에 직접 영향을 미치는 기능
  • 되돌리기 비용이 큰 아키텍처 결정
  • “충분히 좋음”이 충분하지 않은 모든 경우

직접 해보기

이 접근법은 기술 문서를 작성할 수 있는 모든 AI에 적용됩니다. 핵심 요소는 다음과 같습니다:

  • Identical briefs – 모든 플래너가 동일한 정보를 받음
  • True isolation – 플래너가 서로의 작업을 보지 않음
  • Cross‑review – 리뷰어가 전체 플랜을 확인, 하나만이 아니라
  • Independent judging – 심사자가 서로 상의하지 않음
  • Preserved artifacts – 향후 참고를 위해 모든 것을 보관

The PISTON codebase is at .

  • 1,141 tests
  • 22 validated engines
  • All built through tournaments.

0 조회
Back to Blog

관련 글

더 보기 »