AI가 이제 회로 기판을 설계할 수 있을까? EEBench 결과

Who Should Read

LLM 에이전트에게 하드웨어·전자회로 설계를 맡겨 보려는데 결과를 어떻게 검증할지 고민인 개발자

Core Mechanics

• GUI 대신 코드로 회로를 짠다
  • EEBench는 atopile이라는 선언형 코드로 회로를 표현한다.
  • 에이전트가 클릭·좌표 대신 부품, 연결, 전기적 제약을 직접 다룬다.
  • 설계 수정, 빌드, 시뮬레이션, 실패 확인을 프로젝트 안에서 끝낸다.
• 빌드 통과해도 회로는 실패한다
  • 에너지 미터 과제는 전원이 끊긴 뒤 20ms 동안 3.0V 이상을 유지해야 한다.
  • 22µF 커패시터를 쓴 제출물은 4.7V 바이어스에서 유효 용량이 11.4µF뿐이었다.
  • 요구값 545µF에 한참 못 미쳐 0.85ms 만에 3V 아래로 떨어졌다.
• 채점은 전부 결정론적이다
  • 설계를 빌드해 회로 그래프와 BOM을 만들고 SPICE 시뮬레이션과 설계 검사를 돌린다.
  • 요구사항마다 한계값이 있는 측정값이 나온다.
  • 비용 효율은 회로가 동작할 때만 점수에 반영된다.
• 실제 제조사 부품으로 트레이드오프를 푼다
  • 데이터시트 사양을 SPICE 모델에 넣고 부품 허용오차 최악 조건에서도 검사한다.
  • 존재하고 주문 가능하며 가격이 적당한 부품을 골라야 한다.

Community Reactions

• PCB 경력 15년 이상 개발자가 Fable로 LED 이어링을 설계시켰다는 경험
  • 코인셀 홀더 풋프린트의 스루홀 누락과 센터 패드 축소, 두 가지 실수가 있었다.
  • JLC에서 부품을 교체하고 납땜으로 보완해 잘 동작했고, Max 플랜 기준 6일 사용에 약 $50였다고 한다.
• 레이아웃과 복잡한 아날로그·RF는 아직 약하다는 의견
  • 단순한 회로의 회로도는 쓸 만하지만 PCB 레이아웃은 매번 형편없었다는 경험이 있었다.
  • 데이터시트와 errata를 꼭 함께 줘야 한다는 조언도 나왔다.
• 넷리스트와 BOM을 LLM에 넣어 검증시키면 유용하다는 의견
  • 핀, 극성, 부품 사양, 버스 종단 등을 데이터시트와 교차 확인해 준다고 한다.
• 벤치마크 신뢰도에 대한 반론
  • 리더보드가 과제·모델당 한 번만 실행한 것처럼 보여 노이즈가 클 수 있다는 지적이 있었다.
  • 방법론이 불명확해 모델이 명시되지 않은 제약을 얼마나 아는지 보는 테스트일 수 있다는 의견도 있었다.
• LLM에게 결정론적 스크립트로 보드를 생성시켰다는 경험
  • 한 댓글러는 완전히 vibe로 맡기지 않고 Claude가 보드 생성 스크립트를 쓰게 했다.
  • 다른 댓글러는 KiCad 파일을 만드는 파이썬 스크립트를 만들게 했다고 한다.

How to Apply

• 회로도 넷리스트와 BOM을 LLM에 검수시키기
  • 지금 진행 중인 보드의 넷리스트, BOM, 데이터시트를 LLM에 붙여넣어라.
  • 핀 연결, 극성, 부품 사양 문제를 표로 뽑게 하라.
• 에이전트용 설계 검증을 시뮬레이션 채점으로 만들기
  • 하드웨어 에이전트를 만든다면 빌드 성공 대신 SPICE 측정값과 한계값을 통과 기준으로 써라.
  • 허용오차 최악 조건도 함께 돌려라.
• GUI 대신 코드 기반 설계 도구 쓰기
  • 에이전트에 보드를 맡길 땐 atopile처럼 선언형 코드 도구를 골라라.
  • 빌드, 시뮬레이션, 실패 확인을 한 루프로 묶어라.
• 실패 로그를 보상·재시도 신호로 쓰기
  • 어떤 전압이나 코너가 한계를 넘었는지 기록해 다음 시도 프롬프트에 넣어라.
  • 비용 초과 여부도 같이 기록하라.

Try It

# Claude 또는 ChatGPT에 그대로 붙여넣기 (EEBench식 검증 방식의 간이 버전)

너는 전자회로 설계 검토자다. 아래 설계를 이상적인 값이 아니라 실제 부품 기준으로 검토해라.

[요구사항]
{{요구사항: 예) 5V 전원 상실 후 20ms 동안 레일이 3.0V 이상 유지}}

[넷리스트/BOM]
{{넷리스트와 BOM}}

[데이터시트/errata]
{{데이터시트 발췌}}

다음 순서로 답해라.
1. 요구사항마다 측정해야 할 값과 한계값을 표로 만든다.
2. 부품 허용오차, 바이어스에 따른 유효 용량 감소 등 최악 조건에서 통과 여부를 계산한다.
3. 실패하는 항목과 이유를 적는다.
4. 비용과 크기를 고려한 수정안을 낸다.

이어서 해 볼 것: 수정안을 ngspice 테스트로 만들어 달라고 요청해 보라.

Terminology

관련 논문

• The Judge Can Debias Itself: LLM-as-a-Judge가 스스로 편향을 고치게 하는 법

  심사 프롬프트에 편향 경고를 넣거나 스스로 비판시켰더니 21개 중 20개 조합에서 정확도가 올랐다

• 미국 노동시간의 90%는 AI 벤치마크가 제대로 다루지 못하는 일이다

  벤치마크 29개를 직업 과제에 매핑했더니 노동시간 90%가 커버 밖

• Postgres 19, AI 코드 리뷰가 버그를 너무 많이 찾아 출시 연기

  LLM 코드 리뷰가 버그를 쏟아내 Postgres 19가 11월로 밀리고 기능 8~10개가 빠졌다

• StarSkirmish Bench v0.2: LLM이 1시간 만에 짜는 StarCraft 봇 대결

  LLM에게 1시간 동안 StarCraft 봇을 짜게 했더니 GPT-6 Astra가 1위

• 그럴듯한 설명 하나면 멀티모달 LLM 심사위원도 속는다 (JUPE 벤치마크)

  정답은 그대로 두고 설명만 붙였더니 MLLM 심사위원의 오답 거절률이 12.7~13.8%p 떨어졌다

• 신경망은 이미 깔끔하다: polysemanticity의 원인 재해석

  뉴런을 직접 들여다봤더니 대부분 한 가지 역할이 있었다는 주장

• Linus Torvalds의 첫 LLM 보조 패치 시리즈

  Linus가 LLM으로 folio 조회 패치 10개를 만들어 read() 벤치가 10배 빨라졌다

Related Resources

• https://eebench.org/blog/can-ai-design-circuit-boards-yet/
• https://eebench.org/
• https://eebench.org/methodology.html
• https://www.jitx.com/
• https://github.com/JITx-Inc/jitx-skills
• https://github.com/itomato/NeXTBus-Dev-Board