AI가 AI 가속기를 설계한다면? OpenTPU와 FPGA 검증의 책임

핵심 요약

AI가 설계에 얼마나 기여했는지 판단하려면 구조 설계와 코드 작성, 오류 수정에서 맡은 범위를 구분해야 합니다.
FPGA에서 실제로 동작하도록 구현한 것은 중요한 성과지만, 모든 조건에서 정확하게 작동한다는 보장은 아닙니다.
FPGA 구현 결과만으로 전용 반도체의 성능과 전력 효율을 확정할 수는 없습니다.
오픈소스 하드웨어는 설계 코드와 함께 재현 가능한 검증 자료를 공개할 때 더 신뢰할 수 있습니다.

AI가 AI를 돌릴 하드웨어까지 설계한다면 사람은 어떤 일을 맡게 될까요. OpenTPU를 보면서도 이 질문을 하게 됩니다. 설계 자동화가 어디까지 가능한지 따지려면 먼저 설계를 만드는 일과 검증하는 일을 구분해야 합니다.

‘AI가 설계했다’는 말부터 나눠봐야 합니다

AI 가속기는 AI 계산에 자주 쓰이는 연산을 효율적으로 처리하도록 만든 하드웨어입니다. 곱셈과 덧셈을 많이 처리하는 능력도 중요하지만, 필요한 데이터를 제때 가져오는 구조도 갖춰야 합니다.

이런 하드웨어를 ‘AI가 설계했다’고 해도 AI가 맡은 일은 제각각일 수 있습니다. 사람이 정한 구조를 코드로 옮겼을 수도 있고, 연산 장치의 구성까지 제안했을 수도 있습니다. 검증 과정에서 발견한 오류를 AI가 고쳤을 수도 있고요.

작업마다 자동화한 범위와 수준이 다릅니다. 특히 RTL을 작성했다는 사실만으로 전체 설계를 맡았다고 보기는 어렵습니다. RTL은 클록에 따라 회로 안의 데이터가 어떻게 이동하고 처리되는지를 기술하는 코드입니다.

OpenTPU의 설계 자동화 수준을 평가할 때도 이 차이를 살펴야 합니다. 요구사항을 정하고 구조를 선택한 주체가 누구인지 확인해야 하고, 실패한 설계를 누가 고쳤는지도 봐야 합니다. 코드의 양보다 AI가 실제로 어디까지 판단했는지가 중요합니다.

FPGA에서 돌아간다는 것은 어디까지 증명할까요

FPGA는 내부 논리 회로의 구성을 바꿀 수 있는 반도체입니다. 새 전용 칩을 제작하기 전에 하드웨어 설계를 실제 장치에서 시험하는 데 쓸 수 있습니다.

FPGA에 설계를 구현하려면 여러 단계를 거쳐야 합니다. 설계 코드를 회로로 변환한 뒤 칩 내부에 배치하고 연결합니다. 목표한 클록 속도에서 신호가 제시간에 도착하는지도 확인해야 합니다.

그래서 ‘구현 성공’이 구체적으로 무엇을 뜻하는지 살펴야 합니다. 도구가 회로 파일을 만들어낸 것과 보드에서 계산 결과를 확인한 것은 서로 다른 성과입니다. 보드에서 예제 하나를 실행하는 데 성공했더라도 다양한 조건에서 검증을 마쳤다는 뜻은 아닙니다.

OpenTPU의 FPGA 구현을 평가할 때는 어떤 보드와 동작 클록을 썼는지 봐야 합니다. 실행한 연산과 결과를 비교한 방법도 중요한 판단 기준입니다. ‘돌아간다’는 말에 그치지 않고 실제로 어떤 조건에서 확인했는지 구체적으로 짚어야 합니다.

FPGA는 특정 목적에 맞춰 제작하는 전용 반도체인 ASIC과 구조도 다릅니다. FPGA에서 확인한 속도나 자원 사용량을 그대로 ASIC의 성능·전력·면적으로 바꿔 말할 수는 없습니다.

계산이 맞아도 검증은 끝나지 않습니다

가령 2×2 행렬을 입력했을 때 정답이 나왔다고 해보겠습니다. 첫 단계에서 확인할 만한 유용한 결과입니다. 하지만 입력이 연속으로 들어오거나 메모리 응답이 늦어질 때도 정확하게 동작하는지는 따로 확인해야 합니다.

숫자를 어떤 규칙으로 다루는지도 살펴야 합니다. 작은 정수로 계산하는 가속기라면 중간 결과가 표현 범위를 넘을 수 있습니다. 소수점을 줄일 때는 반올림 방식에 따라 결과가 달라질 수 있고요.

비교 기준으로 삼는 소프트웨어 계산도 같은 숫자 표현과 반올림 규칙을 따라야 합니다. 두 결과가 다르다고 해서 곧바로 회로가 틀렸다고 결론 내릴 수는 없습니다. 무엇을 정답으로 삼았는지부터 분명히 해야 합니다.

검증 방법은 각각 맡는 역할이 달라 함께 쓸 수 있습니다. 시뮬레이션으로는 입력에 따라 회로가 어떻게 동작하는지 살펴보고, 형식 검증으로는 명시한 가정 아래 특정 조건이 항상 성립하는지 논리적으로 확인합니다. 보드 테스트에서는 실제 장치와 메모리, 통신 경로까지 포함해 동작을 점검합니다.

AI가 설계와 테스트를 모두 만들 때는 둘에 공통된 오해가 담길 가능성도 경계해야 합니다. 요구사항을 잘못 해석해 설계하고 테스트까지 같은 해석에 맞춰 만들면, 테스트를 통과해도 의도한 기능과 다를 수 있습니다. 그래서 별도의 기준 구현을 두고 요구사항도 검토해야 합니다.

오픈소스의 가치는 다른 사람이 확인할 수 있다는 데 있습니다

설계 코드를 공개하면 다른 사람이 읽고 수정할 수 있습니다. 검증 자료까지 함께 공개하면 설계자의 설명이 맞는지 직접 확인할 수 있습니다.

하드웨어의 동작을 재현하려면 실행 환경도 알아야 합니다. 어떤 FPGA 보드와 도구 버전을 썼는지, 어떤 설정으로 빌드했는지에 따라 결과가 달라질 수 있습니다. 같은 조건에서 시험해 보려면 테스트 입력과 예상 출력도 함께 있어야 합니다.

어떤 조건에서 실패했는지도 유용한 정보입니다. 지원하지 않는 입력 크기가 있는지, 어떤 클록에서 타이밍 조건을 충족하지 못하는지 알면 사용자가 설계를 어디까지 쓸 수 있을지 판단할 수 있습니다.

OpenTPU의 가치를 판단할 때도 AI가 만든 코드의 분량보다 다른 사람이 재현하고 검토할 수 있는 범위를 봐야 합니다. 설계 자동화가 빨라지는 만큼 그 결과를 믿을 수 있는 근거도 함께 쌓아야 합니다.

AI가 설계 작업을 더 많이 맡더라도 요구사항을 정하고 결과를 승인할 책임은 프로젝트를 운영하는 사람과 조직에 남습니다. AI가 설계한 가속기를 도입할 때 무엇부터 확인할지도 이들이 판단해야 합니다. 저는 성능 숫자를 보면서, 그 숫자가 어떤 조건에서 재현됐는지도 함께 확인하겠습니다.