에이전트는 더 높은 추상화에서 더 좋은 칩을 설계할까

이번에 다룰 논문은 Can Agents Design Better Chips with a Higher Level Abstraction?이라는 제목으로 arXiv 번호 2609.21157로 공개된 연구진의 작업입니다. 이 연구가 내세우는 주장은 한 문장으로 정리됩니다. 에이전트 기반 HLS 설계에 HLS 이후 RTL 다듬기를 결합한 AHRR이라는 흐름이 직접 RTL 설계보다 11개 과제의 기하평균으로 2.6배 빠른 칩을 만들었다는 것입니다. 원문 논문은 제목 아래 연결된 링크에서 확인할 수 있습니다.

왜 이 논문을 골라 읽었을까

저는 칩 설계에 에이전트를 붙인다는 이야기를 들을 때마다 반쯤은 기대하고 반쯤은 고개를 갸웃합니다. 기대하는 이유는 분명합니다. 칩 설계는 정해진 문법을 지키면서도 수많은 트레이드오프를 동시에 다뤄야 하는 일이라서, 탐색을 잘하는 기계가 들어오면 어울릴 것 같거든요. 그런데 고개를 갸웃하는 이유도 만만치 않습니다. 실제로 에이전트가 내놓는 RTL을 보면 문법은 맞는데 어딘가 어색한 경우가 많았기 때문입니다. 돌아는 가는데 느리고, 고치려면 사람이 처음부터 다시 뜯어봐야 하는 그런 코드 말이죠.

그래서 이 논문의 질문은 저에게 곧바로 들어왔습니다. 에이전트가 더 좋은 칩을 만들지 못하는 이유가 모델이 멍청해서가 아니라, 우리가 시키는 층위가 낮아서라면 어떨까 하는 질문이었거든요. 사람으로 치면 어셈블리로 짜라고 다그치면서 왜 파이썬처럼 못 짜느냐고 묻는 셈이니까요. 그렇다면 층위를 한 칸 올리면 에이전트의 실력이 달라질까요. 이 글에서는 그 질문을 따라가면서 네 가지 설계 흐름의 차이, AHRR이라는 결합이 만들어진 과정, FPGA에서 끝까지 돌린 평가의 뜻, 그리고 남는 의심을 차례로 풀어보겠습니다.

에이전트에게 RTL은 왜 버거운 작업일까

RTL을 직접 짜본 분들은 아시겠지만, RTL은 하고 싶은 말을 적는 언어가 아니라 하드웨어가 매 사이클마다 무엇을 할지를 못 박는 언어에 가깝습니다. C처럼 for문을 돌리면 알아서 빨라지는 세계가 아니고, 레지스터가 언제 값을 물고 언제 놓는지, 파이프라인이 어디서 끊기고 어디서 이어지는지를 설계자가 일일이 정해야 합니다. 타이밍이 어긋나면 기능은 맞는데 클록이 안 나오고, 자원을 아끼려다 보면 어느새 임계 경로가 길어져 전체가 느려집니다. 한 줄을 고치면 옆줄의 타이밍이 흔들리는 식이라서, 수정 비용이 생각보다 크게 느껴지죠.

에이전트에게는 이 부담이 더 크게 다가옵니다. 언어 모델은 다음 토큰을 잘 고르는 기계이지, 사이클 단위의 물리적 함의를 머릿속에 그리면서 코드를 짜는 존재가 아니기 때문입니다. 그래서 에이전트가 RTL을 직접 짜면 흔히 두 가지 모습이 나타납니다. 하나는 지나치게 조심스러운 코드인데, 합성은 되지만 병렬성을 살리지 못해서 느립니다. 다른 하나는 반대로 욕심을 부린 코드인데, 파이프라인을 섞다가 타이밍을 망가뜨리거나 자원을 터뜨립니다. 둘 다 문법 오류가 아니라 구조 감각의 문제라서, 컴파일러 메시지만으로는 잡아내기 어렵습니다.

여기서 재미있는 질문이 생깁니다. 사람이 RTL을 어려워할 때 꺼내는 해법은 무엇일까요. 답은 대개 추상화를 올리는 것입니다. C와 비슷한 코드에 지시문을 덧붙이면 하드웨어로 바꿔주는 HLS(high-level synthesis)가 바로 그 도구죠. 그렇다면 에이전트에게도 같은 처방이 통할까요. 사람이 추상화에 기대는 이유와 에이전트가 추상화에 기대는 이유가 같을지, 아니면 전혀 다른 층위에서 만날지가 이 논문의 출발점입니다.

네 가지 설계 흐름은 무엇이 다를까

이 연구는 에이전트가 칩을 만드는 방식을 네 가지로 나눠서 견줍니다. 첫째는 직접 RTL 설계인데, 에이전트가 처음부터 Verilog나 VHDL 같은 RTL을 짜는 방식입니다. 기존 연구의 다수가 이 층위에 머물렀고, 그래서 기준선이 됩니다. 둘째는 에이전트 기반 HLS 설계인데, 에이전트가 C와 비슷한 높은 층위의 코드를 짜고 HLS 컴파일러가 이를 하드웨어로 낮추는 방식입니다. 셋째는 컴파일러 이후 HLS 다듬기인데, 컴파일이 끝난 HLS 산출물을 다시 손보는 흐름입니다. 넷째는 HLS 이후 RTL 다듬기인데, HLS로 뼈대를 세운 뒤 낮은 층위에서 RTL을 직접 고쳐서 성능을 끌어올리는 방식입니다.

제가 이 구분에서 가장 흥미롭게 본 부분은 세 번째와 네 번째를 갈라놓은 대목입니다. 언뜻 보면 둘 다 다듬기라서 비슷해 보이는데, 손을 대는 층위가 다르거든요. HLS 산출물을 고치는 일은 컴파일러가 이해하는 힌트의 세계에 머무는 일이고, RTL을 고치는 일은 실제 게이트와 타이밍의 세계로 내려가는 일입니다. 어디까지를 기계에게 맡기고 어디부터를 직접 만질지를 나누는 감각이랄까요. 저희가 새로운 AI 아키텍처를 볼 때도 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 보는데요. 이 논문의 네 갈래 구분도 같은 역할을 합니다. 무엇이 빨라졌느냐 이전에, 어디에서 빨라졌는지를 묻게 만드니까요.

이 구분을 그림으로 그리면 에이전트의 일감이 얼마나 달라지는지가 바로 보입니다. 직접 RTL에서는 에이전트가 사이클과 자원과 타이밍을 전부 짊어지고, HLS 기반에서는 뼈대 구조와 병렬성의 방향만 잡으면 컴파일러가 나머지를 받아줍니다.

그렇다면 AHRR은 어떻게 이어 붙였을까

논문이 제안하는 AHRR은 이름 그대로 에이전트 기반 HLS에 RTL 다듬기를 덧붙인 흐름입니다. 순서를 따라가면 이렇습니다. 먼저 에이전트가 높은 층위에서 설계 코드를 씁니다. 이때 에이전트는 매 사이클의 배선을 정하는 대신, 어떤 연산을 어떤 순서로 펼치고 어디에 병렬성을 둘지 같은 구조적인 결정을 내립니다. 그러면 HLS 컴파일러가 이 코드를 받아서 스케줄링과 바인딩을 거쳐 RTL로 낮춥니다. 여기까지는 사람이 HLS를 쓸 때와 크게 다르지 않습니다. 차이는 그다음에 생깁니다. 에이전트가 다시 등장해서, 컴파일 결과로 나온 RTL을 직접 읽고 고치는 것이죠. 파이프라인 균형이 어긋난 곳을 다잡거나, 메모리 접근이 몰린 곳을 흩뜨리거나, 컴파일러가 보수적으로 잡아둔 부분을 필요에 맞게 푸는 식입니다.

이 순서를 사람 일에 비유하면 꽤 익숙하게 느껴집니다. 초안을 쓸 때는 큰 구조에 집중하고, 퇴고할 때는 문장 하나하나를 만지는 것과 비슷하거든요. 초안부터 문장 끝맺음에 매달리면 전체가 삐걱거리는 것처럼, 칩도 처음부터 RTL에 매달리면 구조가 굳어버립니다. 반대로 초안만 쓰고 퇴고를 건너뛰면 어딘가 밋밋한 글이 남죠. AHRR은 그 둘을 나눈 셈입니다. 구조는 높은 층위에서 잡고, 마무리는 낮은 층위에서 다듬는 것이죠.

문제는 그다음입니다. 이 결합이 말처럼만 쉬우면 누구나 했을 텐데, 실제로는 두 층위를 오가는 에이전트가 필요합니다. 높은 층위의 의도를 낮은 층위의 배선까지 들고 내려가야 하니까요. 예컨대 HLS 코드에서 펼친 루프가 RTL에서는 어떤 파이프 단계로 내려앉았는지, 그 단계가 임계 경로에 어떤 부담을 얹었는지를 읽어야 합니다. 저는 여기서 조금 멈칫했습니다. 에이전트가 두 층위를 넘나드는 읽기를 정말 해낼까 하는 의심이 들었거든요. 이 의심에 대한 답은 뒤에 나오는 사례 연구와 평가 숫자에 갈려 있습니다.

추상화가 에이전트를 돕는 방식

사례 연구가 전하는 이야기는 의외로 또렷합니다. HLS가 설계 지식을 추상 안에 눌러 담고 있어서, 에이전트가 날것의 RTL보다 훨씬 잘 붙들고 쓴다는 것입니다. 여기서 추상이라는 말을 어렵게 들을 필요는 없습니다. 루프를 펼치라는 지시문 하나가 수십 줄의 파이프라인 배선을 대신하고, 메모리 나누기 옵션 하나가 뱅크 충돌을 피하는 배치를 대신하는 식이니까요. 컴파일러가 수년간 쌓은 최적화 상식을 에이전트가 한 줄의 힌트로 빌려 쓰는 셈이죠.

이 차이는 생각보다 중요합니다. 직접 RTL에서는 에이전트가 매번 바닥부터 쌓아야 합니다. 파이프라인 깊이를 정하고, 핸드셰이크를 맞추고, 리셋과 이네이블을 챙기는 일이 끝없이 이어지죠. 그런데 HLS 앞에서는 일이 달라집니다. 에이전트는 무엇을 병렬로 풀지를 정하고, 컴파일러는 그것을 어떻게 배선으로 펼지를 정합니다. 역할이 갈라지면서 에이전트의 실수가 줄어듭니다. 타이밍을 깨는 잔실수가 컴파일러의 스케줄러 안에서 걸러지니까요. (참고로 이 대목은 저에게 예전에 본 소프트웨어 합성 도구들의 교훈을 떠올리게 했는데요. 사람이든 기계든, 잘 만든 층위 위에서는 어깨가 가벼워집니다.)

물론 여기서 조심해서 읽을 지점이 있습니다. 추상화가 에이전트를 돕는다는 말이, 추상화가 설계를 대신한다는 뜻은 아니기 때문입니다. HLS가 뼈대를 세워줘도 어디를 펼치고 어디를 묶을지는 여전히 에이전트의 몫이고, 그 판단이 틀리면 컴파일러도 살려내지 못합니다. 예컨대 의존성이 얽힌 루프를 무리하게 펼치면 파이프라인은 길어지고 이득은 줄어드는데, 이런 구조 판단은 지시문 한 줄을 넘어서는 일입니다. 그래서 저는 이 대목을 이렇게 읽었습니다. HLS는 에이전트를 똑똑하게 만드는 약이 아니라, 에이전트가 똑똑해질 수 있는 자리를 내주는 일이라고요.

컴파일러가 놓치는 자리는 왜 남을까

그렇다면 HLS만으로 충분하지 않을까요. 논문의 답은 분명합니다. 충분하지 않으니 RTL 다듬기가 필요하다는 것이죠. HLS 컴파일러는 일반적인 경우에 안전하게 동작하도록 설계되어 있어서, 특정 과제에서만 통하는 과감한 선택을 잘 하지 않습니다. 보수적으로 잡은 스케줄, 넉넉하게 잡은 자원 여유, 모든 경우를 커버하려는 범용 템플릿이 그 흔적입니다. 기능은 맞지만 어딘가 아쉬운 결과가 나오는 이유가 여기 있습니다.

사례 연구가 짚는 RTL 다듬기의 역할이 바로 이 아쉬움을 메우는 일입니다. 컴파일 과정에서 사라진 낮은 층위의 최적화 여지를 다시 찾아내는 것이죠. 메모리 포트가 몰리는 지점을 흩뜨리거나, 파이프 단계마다 일이 고르게 나뉘도록 경계를 옮기거나, 실제로는 동시에 일어나지 않는 동작들을 묶어서 자원을 아끼는 식입니다. 이런 손질은 HLS 지시문만으로는 표현하기 어렵습니다. 컴파일러의 눈에는 보이지 않거나, 보여도 건드리기 조심스러운 자리에 손을 대는 일이라서요.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이 다듬기가 운 좋게 걸린 것인지, 반복해서 먹히는 기술인지 말이죠. 논문이 보여주는 흐름은 후자에 가깝습니다. HLS가 뼈대를 크게 틀어지지 않게 잡아두니, RTL 단계의 손질이 전체를 무너뜨리지 않고 성능만 긁어모을 수 있다는 설명이거든요. 바닥부터 쌓은 RTL을 고치는 일과, 이미 선 HLS 뼈대 위에서 마무리하는 일은 위험의 크기가 다릅니다. 전자는 한 줄을 건드리면 타이밍 전체가 흔들리지만, 후자는 구조가 잡혀 있어서 손질이 국소적으로 머뭅니다. 저는 이 대목에서 AHRR이라는 이름이 괜히 붙은 게 아니라고 느꼈습니다. 순서가 곧 안전장치인 셈이니까요.

11개 과제에서 2.6배라는 숫자를 어떻게 읽을까

이제 숫자를 볼 차례입니다. 논문은 다양한 11개 과제로 묶은 벤치마크에서 AHRR이 직접 RTL 설계보다 기하평균 2.6배의 속도 향상을 냈다고 밝힙니다. 기하평균이라는 말을 풀면 이렇습니다. 어떤 과제에서 유난히 크게 튀어 평균을 부풀린 게 아니라, 여러 과제에 걸쳐 꾸준히 빨라졌다는 뜻에 가깝죠. 단일 과제 최고 기록이 아니라 전체 흐름의 성적표로 읽어야 합니다.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 2.6배라는 값 자체도 눈에 띄지만, 그 값이 네 가지 흐름을 나란히 견준 자리에서 나왔다는 점이 더 마음을 끕니다. 직접 RTL과 견줘서 빨라졌다는 말은, 같은 에이전트라도 시키는 층위에 따라 결과가 크게 갈린다는 뜻이니까요. 모델을 바꾸지 않고 흐름을 바꿨는데 성적이 달라졌다면, 병목은 모델이 아니라 흐름에 있었다고 읽는 편이 자연스럽습니다.

다만 여기서는 조금 조심해서 읽을 필요가 있습니다. 11개라는 과제 수는 흐름을 견주기에는 넉넉해 보이지만, 칩 설계 전체를 대표한다고 말하기에는 조심스러운 숫자이기도 합니다. 과제의 종류가 연산 위주인지 메모리 위주인지, 제어 로직이 얼마나 얽혀 있는지에 따라 HLS의 덕을 보는 폭이 달라질 수 있거든요. 속도라는 말이 정확히 무엇을 재었는지도 함께 봐야 합니다. 실행 사이클인지 벽시계 시간인지, 같은 클록 조건에서 견준 것인지에 따라 숫자의 결이 달라집니다. 논문이 끝단 평가를 강조하는 이유도 여기에 있습니다. 합성 통과가 아니라 실제로 돌아가는 상태까지 가서 재야 숫자 앞에서 덜 흔들리니까요.

왜 하필 FPGA에서 끝까지 돌렸을까

논문은 평가를 FPGA 위에서 끝까지 돌렸다고 밝힙니다. 에이전트 칩 설계 연구를 위한 실용적이고 손쉬운 실험대로 FPGA를 택했다는 설명입니다. 이 선택은 저에게 꽤 설득력 있게 다가왔습니다. 칩 설계 논문에서 흔히 보는 함정이 합성 추정치에서 멈추는 것인데, FPGA 끝단 평가는 그 함정을 피하는 길이거든요. 실제로 비트스트림을 올리고 돌려야 보이는 병목이 있고, 보고서상의 숫자와 바닥에서 재는 숫자 사이에는 종종 간극이 있습니다.

FPGA를 택한 또 다른 이유는 재현과 속도에 있습니다. 주문형 반도체로 찍어내기에는 돈과 시간이 너무 들고, 시뮬레이션으로만 돌리기에는 실제 보드에서 터지는 문제를 놓치기 쉽습니다. 그 중간에서 FPGA는 에이전트가 뱉은 설계를 바로 올려서 확인할 수 있는 자리입니다. 에이전트 연구처럼 시도가 많이 필요한 흐름에서는 이 짧은 반복 주기가 큰 자산이 됩니다. 실패를 빨리 보고 빨리 고칠 수 있으니까요.

그렇다면 이 결과는 FPGA 바깥에서도 통할까요. 논문은 설계 흐름의 트레이드오프가 목표 기술과 크게 무관해서 FPGA 너머에도 들어맞는다고 말합니다. 저는 이 말을 절반쯤은 받아들이고 절반쯤은 남겨두고 싶습니다. 흐름의 방향, 즉 높은 층위에서 구조를 잡고 낮은 층위에서 다듬는다는 원칙은 다른 기술에서도 살아남을 가능성이 큽니다. 하지만 숫자의 크기는 기술에 따라 달라질 수밖에 없습니다. 셀 라이브러리가 다르고, 배선 지연의 비중이 다르며, 메모리 구조가 다르면 같은 손질이 다른 이득을 냅니다. 원칙은 가져가되 2.6이라는 숫자는 FPGA라는 바닥 위에서 읽어야 합니다. 실제 시스템 관점에서 보면 다음에 물을 질문도 정해져 있습니다. 같은 흐름을 다른 기술에 올렸을 때 어디까지 따라오느냐는 것이죠.

높을수록 좋다는 말은 왜 틀릴까

이 논문을 빠르게 훑으면 높을수록 좋다는 한 줄 요약이 떠오르기 쉽습니다. 추상화를 올렸더니 빨라졌다는 이야기니까요. 그런데 그 요약은 논문이 실제로 보여준 것을 반쯤 놓칩니다. 논문이 보여준 것은 높은 층위 그 자체가 아니라, 높은 층위와 낮은 층위를 잇는 순서이기 때문입니다. HLS만 쓴 흐름과 RTL 다듬기까지 붙인 흐름은 성적이 다르고, 논문이 밀어붙이는 것도 둘의 결합이거든요.

이 차이는 곱씹을수록 선명해집니다. 높은 층위는 에이전트가 구조를 잡게 돕지만, 컴파일러가 보수적으로 남긴 여백까지 메워주지는 않습니다. 반대로 낮은 층위의 손질은 여백을 메우지만, 뼈대부터 잘못 선 설계를 구해내지는 못합니다. 둘 중 하나만 택하라는 문제가 아니라 어디에 무엇을 맡길지를 정하는 문제인 셈이죠. 생각해보면 사람도 비슷하게 배웁니다. 개요를 잘 잡는 것과 문장을 잘 다듬는 것은 다른 근육이라서, 둘 다 있어야 글이 삽니다.

여기서 현장의 엔지니어들이 흔히 빠지는 함정이 하나 있습니다. 추상화를 올리면 하드웨어 감각이 필요 없어진다고 믿는 것인데, AHRR의 그림은 오히려 반대에 가깝습니다. 추상이 일을 덜어주는 만큼, 남은 낮은 층위의 판단은 더 정밀해져야 합니다. 어디를 펼치고 어디를 접을지, 파이프 경계를 어디에 둘지, 메모리를 어떻게 흩뜨릴지를 아는 눈이 여전히 필요합니다. 다만 그 눈이 처음부터 끝까지 전부 볼 필요는 없어진 것이죠. 볼 자리를 컴파일러가 골라주는 셈입니다.

앞으로 무엇을 지켜보면 될까

논문은 코드와 평가 산출물을 함께 공개해서 다른 연구진이 같은 저울 위에 올려놓고 견줄 수 있게 했습니다. 저는 이런 대목을 반갑게 봅니다. 에이전트 설계처럼 흐름이 복잡한 연구는 숫자의 재현보다 흐름의 재현이 어려운데, 산출물이 열려 있으면 다음 연구가 허공에서 시작하지 않아도 되니까요. 흐름을 뜯어보고 싶은 독자에게는 뼈대 코드를 따라가 보는 일이 좋은 다음 걸음이 됩니다.

제가 앞으로 보고 싶은 것은 세 가지입니다. 첫째, 과제의 결이 바뀌어도 같은 폭의 향상이 따라오는지입니다. 연산 위주 과제와 메모리 위주 과제, 데이터 흐름이 규칙적인 과제와 제어가 자주 꺾이는 과제에서 AHRR의 덕이 어떻게 달라지는지 궁금합니다. 둘째, 에이전트의 손질이 얼마나 안정적인지입니다. 같은 출발점에서 여러 번 다듬었을 때 결과가 크게 흔들리지 않는지, 한 번의 운이 아니라 반복되는 솜씨인지가 중요합니다. 셋째, 흐름의 비용입니다. 2.6배 빨라지는 동안 에이전트 호출은 몇 번 늘었고, 컴파일과 합성에 든 시간까지 합치면 전체 벽시계는 어떻게 되는지가 실제 도입에서는 더 크게 느껴질 수 있습니다.

그렇다면 사람의 역할은 무엇일까요. 저는 이 논문을 읽고 나서 그 질문을 이렇게 바꿔봅니다. 에이전트에게 어느 층위의 언어를 가르쳐야 할까, 그리고 어느 층위의 마무리는 사람이 계속 쥐고 있어야 할까 하는 질문으로 말이죠. 층위를 올리는 일은 에이전트를 편하게 하는 동시에, 사람이 볼 자리도 다시 정하는 일입니다. 구조를 읽는 눈과 마무리를 맡기는 용기 사이에서, 설계자의 일은 어쩌면 전보다 더 설계다워집니다. 다음에 에이전트에게 칩을 맡기는 날이 오면, 저는 RTL부터 쥐여주기 전에 먼저 물을 것 같습니다. 어느 층위에서 생각하게 할지를요.