2편부터 4편까지는 칩에 관한 이야기였습니다. 이 글은 일이 어떻게 이루어졌는지에 관한 것입니다. 이 프로젝트의 실제 작업 중 상당 부분은 Anthropic의 AI 코딩 에이전트인 Claude Code가 G2 안에서, 엔지니어 한 명과 함께 했습니다. 그것이 어떻게 진행되었는지, 잘못된 부분까지 포함해 소개합니다.
두 가지 역할
역할 분담은 단순했습니다.
| Claude Code | 엔지니어 |
|---|---|
| G2 자체 명령으로 흐름 실행 | 목표와 제한 설정 |
| 로그와 리포트 읽기 | 결정: A안이냐 B안이냐, 어떤 플로어플랜인가, "그래도 마무리" |
| 실패 진단 | 방향을 바꾸는 질문 |
| 스크립트, 수정, 문서 작성 | 공개되는 모든 것의 승인 |
간단히 말하면, 에이전트는 손을 제공했고 엔지니어는 판단을 제공했습니다.
처음부터 중요했던 규칙이 하나 있습니다. 모든 흐름 단계는 G2의 API를 거칩니다. WebUI의 버튼이 호출하는 것과 같은 sd -e 명령입니다. 에이전트는 임시 셸 스크립트로 도구를 실행하지 않았습니다. 필요한 단계에 API가 없으면, 그것은 우회할 것이 아니라 보고하고 만들어야 할 빈틈이었습니다. 덕분에 모든 실행이 엔지니어가 볼 수 있는 G2의 기록에 남았습니다.
2:11YouTube에서 보기(영어) ↗Bilibili에서 보기(중국어) ↗
무인으로 진행한 하룻밤
10월 13일 21:40, 엔지니어는 약 열 시간을 맡기면서 지시 하나만 남겼습니다. 갈 수 있는 데까지 가고, 진짜 결정이 필요할 때만 멈추라는 것입니다. 다음 날 아침 07:00까지:
- otbn v5가 배선되었습니다. 배선 실패 네 건을 차례로 진단하고 고쳤습니다(이야기는 2편에 있습니다).
- 블록 일곱 개가 포스트 라우트와 피니시를 거쳤고, 그 IP 뷰(abstract LEF, 타이밍 모델, 블랙박스 스텁)가 생성되었습니다.
- i2c를 먼저 했습니다. 새 피니시 스크립트를 비싼 블록보다 먼저 가장 싼 블록에서 시험했습니다.
- 칩 v2의 스크립트를 준비해 두었습니다. 전원 그리드와 플로어플랜입니다.
- 결정 16건이 기록되었고, 각각 이유가 있습니다.
결정 추적
자명하지 않은 모든 선택은 네 부분으로 된 항목을 남겼습니다. 시간, 무엇을 결정했는지, 왜, 그리고 태그입니다. 그날 밤의 예 두 가지: 리타이밍을 별도 스크립트가 아니라 G2 단계로 넣기, 그리고 새 스크립트를 가장 싼 블록에서 먼저 시험하기. 각 항목은 짧으며, 쓸모를 만드는 것은 "왜" 한 줄입니다.
7일 동안(10월 13~19일) 추적에는 101개 항목이 쌓였습니다. 엔지니어는 로그로 재구성하는 대신 다음 날 아침 몇 분 만에 밤새 일어난 일을 검토할 수 있었습니다.
실수가 규칙이 되었습니다
에이전트는 실수를 했습니다. 실수마다 대가가 있었고, 실수마다 기록된 규칙이 되었습니다.
| 일어난 일 | 규칙 |
|---|---|
| 에이전트가 스스로 설정한 4시간 타임아웃이 배치 실행을 아무 출력 없이 중단시켰습니다. | 긴 EDA 실행에는 타임아웃을 두지 않습니다. |
| 기존 버전 위에 블록을 다시 실행해 첫 결과를 덮어썼습니다. | 실행마다 새 버전. |
| 프로브를 프로젝트 바깥의 임시 폴더에 두었습니다. | 검사는 테스트 버전 안의 G2 단계이며, README가 있습니다. |
| SPEF 버그를 클록 트리 도구 탓으로 돌렸습니다. | 같은 코드가 제대로 하는 것과 비교합니다. |
| 칩 타이밍을 OpenROAD 안에서 돌리자고 제안했습니다. | 사인오프는 별도 도구에서. |
| 결코 참이 될 수 없는 조건을 기다렸습니다. 엔지니어가 "왜 기다리고 있나요?"라고 세 번 물었습니다. | 기다림이 끝날 수 있는지 확인하고, 타임아웃이 보고하게 만듭니다. |
SPEF 사례는 협업을 가장 잘 보여 주는 예입니다. 에이전트의 첫 이론은 그럴듯했고, 증거로 추적한 버퍼 하나가 있었습니다. 엔지니어는 그 증거를 반박하지 않았습니다. 대신 더 나은 질문을 했습니다. 같은 파일이 이 모듈의 합성된 넷은 올바르게 쓰는데, 여기서는 무엇이 다를까요? 그 질문이 탐색을 클록 트리 도구에서 버그가 있던 SPEF 출력기로 옮겼습니다(4편).
AI 엔진을 위해 기록한 규칙
규칙은 다음 에이전트가 G2 프로젝트를 건드리기 전에 읽는 평문 가이드에 있습니다. 황금 규칙은 열 가지입니다.
- 모든 단계에 G2 API를 사용합니다.
- 실행마다 새 버전.
- 검사는 G2 단계로.
- 테스트 케이스를 만들기 전에 묻습니다.
- 공개되는 것은 무엇이든 먼저 묻습니다.
- EDA 작업은 한 번에 하나, 스레드는 최대 10개.
- 긴 실행에는 타임아웃을 두지 않습니다.
- 사인오프 타이밍은 독립 실행 OpenSTA에서.
- 타이밍 분석은 G2의 타이밍 경로 데이터로.
- 데모 실행은 클로저가 아닙니다. 남은 문제를 기록하고 넘어갑니다.
이 중 일부는 어느 칩 팀이든 알아볼 엔지니어링 관행입니다. "공개되는 것은 먼저 묻기"나 "기다림이 끝날 수 있는지 확인하기" 같은 것은 에이전트와 일할 때 특유의 규칙입니다. 규칙 5는 업스트림 버그 리포트에도 적용되었습니다. 에이전트가 이슈와 풀 리퀘스트를 준비했고, 엔지니어가 승인하기 전에는 아무것도 게시되지 않았습니다.
G2에서 이것이 통하는 이유
열 시간 동안 무인으로 일하는 에이전트는 사람이 빠르게 검토하고 신뢰할 수 있는 작업을 남겨야 합니다. 그 대부분을 G2의 구조가 해 줍니다.
- 모든 실행은 버전입니다. 에이전트가 하는 어떤 일도 결과를 덮어쓰지 않으므로, 잘못된 실행은 시간은 잃어도 데이터는 잃지 않습니다.
- 모든 단계는 스테이지이며, 로그, QoR 요약, README가 있습니다. 에이전트는 실행이 끝날 때 README를 씁니다. 목적, 결과, 다음 단계입니다.
- 결정은 추적에 기록됩니다. 시간, 무엇을, 왜.
- 하나의 페이지 묶음. 엔지니어는 에이전트가 쓰는 것과 같은 WebUI 페이지를 검토합니다. 믿거나 의심해야 할 별도의 리포트가 없습니다.
다른 팀에게 해 주고 싶은 말
- 실수의 비용이 적은 구조를 에이전트에게 주세요. 버전, 스테이지, 그리고 이유를 적을 곳입니다.
- 실수마다 다음 세션이 읽을 기록된 규칙으로 바꾸세요. 대화로만 한 교정은 오래가지 않습니다.
- 결과가 따르는 결정과 공개되는 모든 것은 사람에게 남겨 두세요.
- 결정 추적을 읽으세요. 지켜보지 않은 작업을 검토하는 가장 빠른 방법입니다.
다음은 마지막 편입니다. 백만 셀 칩이 노트북 한 대에서 메모리와 실행 시간을 얼마나 쓰는지, 그리고 언제 컴퓨터가 더 있으면 도움이 되는지 다룹니다.