본문으로 건너뛰기

LLM에 맡긴 PCB 라우팅 사례

LLM 초안은 규칙 불일치로 실패했고 유료 엔지니어가 재작업해 라우팅 기법 레지스트리를 남긴 사례이다

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

저자는 21mm 원형 4층 PCB 라우팅을 LLM에 맡겼다가 autorouter의 via 템플릿 불일치로 143개의 DRC 위반을 받은 뒤, 유료 계약 엔지니어가 개입해 문제를 해결하고 라우팅 실패를 재현 불가 지점까지 정리한 사례를 기록했다. 문제 원인은 autorouter가 보드 규칙을 무시해 annular ring가 부족해진 비아와 규칙 튜닝으로 인한 밀도 문제였으며, 패드 직경 확대와 수동 리루트로 위반 일부가 해소되었다는 수치가 제시되었다. 이 과정을 통해 16개의 라우팅 기법 레지스트리를 만들고 gui_card로 표기된 사람 작업 영역을 남겨 자동화의 한계와 검증 절차를 정리했다.

섹션별 상세

작업 맥락은 21mm 원형, 4층 PCB를 LLM에 맡겨 라우팅을 시도한 사례이며 목표는 반복되는 라우팅 실수를 에이전트가 다음 프로토타입에서 피하게 만드는 것이었다. 입력은 파이썬으로 생성한 보드 파일과 라우팅 규칙 상수였고 출력은 autorouter가 만든 초기 라우트와 DRC 리포트였다. 결과물은 수치와 파일 기반의 진단을 남겼고, 그 진단을 토대로 사람과 계약 엔지니어가 개입해 결함을 해결한 점이 핵심 증거이다.
핸드오프로 넘기기 전 3D 렌더링 이미지로, 21mm 원형 PCB의 전면 트레이스와 테스트포인트 배치가 보인다.
Screenshot이 이미지는 초기 autorouter 결과를 시각적으로 보여주며 트레이스가 외곽을 크게 감아 도는 배치와 테스트 패드 위치를 확인할 수 있다. 비아와 패드 밀집 구역, 실크스크린과의 간섭 가능성을 화면상에서 확인할 수 있어 DRC에서 나온 위반 항목의 공간적 원인을 연결하는 근거가 된다. 라우팅이 내부 층으로 얼마나 의존하는지도 렌더 상태로 유추할 수 있어 기술적 세부 확인에 유용하다.
LLM이 만든 초안은 총 143개의 DRC 위반을 기록했고 진단은 그중 약 90건을 잘못된 비아 패드스택 템플릿에서 기인한 것으로 분류했다. 원인은 autorouter가 보드 규칙의 via 템플릿을 무시하고 자체 padstack을 찍어 annular ring가 부족해진 점이며 이로 인해 hole_to_copper(hole_clearance) 규칙을 위반한 것이다. 패드 직경을 0.5mm에서 0.6mm로 키우자 동일 클래스의 위반이 사라졌고 이 변화는 DRC 리포트 수와 판결 상태가 어떻게 바뀌는지에 대한 직접적 증거로 제시되었다.
근거
  • Autorouter가 보드의 via 규칙을 무시해 padstack가 작게 생성되었고 그 결과 90개의 hole_clearance 관련 DRC 위반이 발생했다. 섹션 'What the LLM produced'에서 autorouter의 via 템플릿이 보드 규칙을 무시했고 pad Ø0.5/drill Ø0.3으로 annular ring가 부족했다는 진단을 확인할 수 있다.
  • 패드 직경을 0.5mm에서 0.6mm로 확장하면 새로 생성되는 비아의 annular ring가 규칙을 만족해 동일 클래스의 hole_clearance 위반이 사라졌다. 섹션 'Why those 11 violations disappeared'의 계산에서 pad Ø0.6/drill Ø0.3일 때 annular ring와 copper-to-copper 합이 0.25mm 요구치에 도달한다고 기술되어 있다.
초기 자동화 수정은 새로운 문제를 낳았다; 비아를 키우면 비아 밀도 제한(DENSITY_LIMITED) 위반과 미연결 넷 수 증가가 발생했다. 실제로 143개에서 64개로 총 위반 수는 줄었지만 밀도 경고가 나왔고 미연결 넷은 6에서 13으로 늘었다는 수치가 제시되었다. 이 사례는 규칙 튜닝이 하나의 오류 클래스를 지우는 대신 다른 계층의 적합성 문제를 만들 수 있음을 실증한다.
근거
  • 계약 엔지니어는 수작업으로 남은 넷과 DRC 위반을 정리했고 그 결과를 바탕으로 16개의 라우팅 기법 레지스트리를 만들어 반복 실수를 기록했다. 섹션 'Putting the two boards side by side' 및 'Distilled into techniques'에서 네트별 비교 표와 레지스트리 생성 과정이 설명되어 있다.
계약 엔지니어(유료 수정)는 배치 고정 상태에서 남은 몇 개 넷과 11개의 DRC 항목을 수작업으로 처리했고, 그 결과를 원래 보드와 네트별로 비교해 16개의 라우팅 기법을 추출하는 레지스트리를 만들었다. 레지스트리 항목은 각 기법에 대응하는 에디터 슬롯을 가리키며 그중 7개는 gui_card로 표기되어 사람이 GUI에서 직접 처리해야 하는 작업이라는 메타정보를 남겼다. 이 과정은 기계가 실패한 지점을 명명 가능한 기술로 전환해 다음 자동화 시도에 재사용 가능한 규칙으로 만든다는 점에서 의미가 있다.
계약 엔지니어가 수정한 후의 3D 렌더링으로, 트레이스가 짧아지고 실크스크린이 정리된 모습이 관찰된다.
Screenshot이 이미지는 수정 후 보드의 변화를 직관적으로 보여주며 특히 내부 레이어의 재분배로 트레이스 길이가 줄고 비아 배치가 달라진 점을 확인할 수 있다. 라우팅 밀도와 실크스크린 정리 상태가 개선된 시각 증거로서, 텍스트로 기록된 넷별 길이·비아 변화를 시각적 근거와 연결하는 데 의미가 있다. 결과 비교를 위해 핸드오프 전후 이미지를 함께 보는 것이 중요하다.
복제 실험에서는 엔지니어가 만든 round‑1 보드를 출발점으로 에이전트가 round‑2 변경을 눈가림 상태에서 재현하도록 테스트했으며 세 가지 채점 기준 중 두 개와 세 번째의 무결성 조건을 에이전트가 눈가림으로 통과했다. 그러나 통과한 항목 가운데 하나는 임계값 경계가 근접해 물리적 안전 마진과 충돌할 소지가 있었고, 나머지 하나는 gui_card로 분류되어 사람에게 에스컬레이션되었다는 점이 문서로 남아 있다. 핵심 한계는 동일한 보드 계열로만 재현이 검증되었고 진정한 전이(transfer) 증거는 다음 프로토타입에서의 독립적 성공이어야 한다는 점이다.
운영상 교훈은 두 가지 경계로 요약된다. 하나는 DRC 위반 수가 줄어드는 동안 미연결 넷이 늘어나면 '통과'가 실은 라우팅 방기일 수 있다는 점이고 다른 하나는 규칙으로 잡아내지 못하는 설계 품질 문제, 예컨대 전원(VBAT)과 고속 신호(SPI_SCK)를 같은 0.2mm 폭으로 그린 실수처럼 DRC가 침묵하는 결함이다. 따라서 DRC-clean은 필요한 조건이지만 충분조건은 아니며 fab.gate_ok 같은 추가 점검과 넷별 비교 테이블을 납품물 형태로 요구하는 절차가 중요하다는 결론이 제시되었다.

용어 해설

디자인 규칙 검사(DRC)
PCB 설계에서 제조 요구조건을 자동으로 확인하는 검증 도구로, 트레이스 폭·간격·비아 규격 등 공장 수용 한계를 규칙으로 체크하는 역할이다. DRC는 패브릭에 보낼 수 없는 항목을 숫자로 보고하며, 설계자와 자동화 시스템의 합법성 게이트로 작동한다.
자동 라우터(Autorouter)
사람 대신 트레이스와 비아를 배치해 신호선을 연결하는 소프트웨어로, 규칙과 템플릿을 바탕으로 경로를 생성한다. Autorouter는 조합 탐색에 강하지만 툴체인 규칙 해석이나 설계 의도(admissibility) 판단에서 사람보다 약하다.
비아(관통구)(Via)
PCB 층간 신호를 연결하기 위해 드릴로 뚫는 구멍과 그 주변의 도금 패드를 합친 구성요소로, 드릴 직경과 패드 직경의 차이인 annular ring가 규격 적합성에 결정적 영향을 미친다. 비아 규격 불일치는 DRC 위반과 제조 불가로 이어질 수 있다.

기술

  • Fable 5
  • Claude
  • kicad-cli 9.0.8
  • Python

활용 사례

  • 자동 PCB 라우팅의 초기 초안 생성
  • 라우팅 실패 지점을 기법 레지스트리로 축적해 다음 시도에 재사용
  • 라우팅 결과를 사람에게 에스컬레이션 하는 트리아지 워크플로
AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 08. 11.수집 2026. 08. 11.출처 타입 RSS

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.