AI 에이전트는 컴퓨터 구조를 이해할까

Do AI Agents Understand Computer Architecture?는 arXiv에 공개된 논문으로 식별자는 2609.19387이며, 에이전트에게 하드웨어 설계를 맡겼을 때 좋아진 점수와 진짜 이해를 구분할 수 있는지 묻습니다. 이 글에서는 같은 15차원 가속기 설계 공간을 두 가지 표현으로 나눠 비교한 AutoTuring 실험을 따라가며, 그 차이가 무엇을 말해주는지 살펴보겠습니다. 원문 논문 링크는 제목 아래에 걸어두었습니다.

에이전트가 설계했다는 말을 들으면 저는 일단 멈칫합니다

안녕하세요, 패트릭입니다. 저는 이 논문을 읽기 전부터 한 가지 장면이 계속 마음에 걸렸습니다. 누군가 에이전트에게 가속기를 설계시켰더니 기존 제품보다 빨라졌다는 소식을 전하면, 주변에서는 곧바로 이해했다는 말까지 덧붙이곤 하는데요. 그런데 점수가 좋아졌다는 사실과 왜 좋아졌는지를 아는 일은 서로 다른 층위에 있지 않을까요. 사람은 우연히 정답을 맞힐 수도 있고, 남이 짜놓은 길을 따라가서 좋은 자리를 찾을 수도 있습니다. 그렇다면 에이전트도 그럴 수 있지 않을까요.

제가 이 논문에서 가장 흥미롭게 본 부분은 바로 이 지점을 정면으로 찌른 방식입니다. 논문은 에이전트를 바꾸지 않습니다. 대신 문제를 보여주는 방식을 바꿉니다. 같은 에이전트에게 같은 설계 공간을 주고, 한 번은 구조의 이름이 보이는 형태로, 다른 한 번은 이름이 지워진 숫자로만 보여주는 것이죠. 이렇게 하면 에이전트 자체의 능력은 그대로 둔 채, 문제의 의미가 얼마나 쓰였는지를 따로 떼어낼 수 있습니다. 생각해보면 사람도 비슷하게 배웁니다. 낯선 기계 앞에 섰을 때 버튼마다 이름이 적혀 있으면 감이 오지만, 이름이 모두 지워진 다이얼만 있으면 같은 기계도 전혀 다른 문제가 되니까요.

여기서는 조금 조심해서 읽을 필요가 있습니다. 이 실험은 어떤 가속기가 더 좋은지를 가리려는 것이 아닙니다. 오히려 비교 자체가 결과물에 가깝습니다. 논문도 이 점을 여러 번 강조하는데요. 저도 그 태도가 마음에 들었습니다. 요즘처럼 에이전트 성공담이 빠르게 도는 시기에는, 무엇을 쟀는지를 먼저 묻는 글이 더 필요하기 때문입니다.

좋아진 설계와 이해한 설계는 어떻게 다를까

에이전트가 하드웨어를 설계한다는 보고를 볼 때마다 저는 두 가지 가능성을 함께 떠올립니다. 하나는 에이전트가 구조를 읽고, 어디가 병목인지 짐작하고, 그 짐작에 맞춰 손을 댔다는 이야기입니다. 다른 하나는 에이전트가 탐색을 잘해서, 구조를 모르더라도 좋은 점을 찍었다는 이야기입니다. 두 경우 모두 마지막 점수는 올라갑니다. 그래서 점수만 보면 둘을 구분할 수 없죠.

논문이 진단하는 지점도 여기와 겹칩니다. 기존 평가는 대개 에이전트를 바꾸면서 문제의 틀은 그대로 두었다고 합니다. 그러면 점수가 오른 이유가 에이전트가 똑똑해서인지, 문제의 표현이 친절해서인지, 아니면 탐색 예산을 많이 써서인지가 뒤섞입니다. 제가 보기에는 이 지적이 논문 전체에서 가장 단단한 토대입니다. 왜냐하면 하드웨어 설계는 답이 맞았는지를 넘어, 어떤 추론으로 그 답에 도달했는지가 비용과 직결되는 영역이기 때문입니다.

일상적인 비유를 하나 들어보겠습니다. 요리 초보에게 간장통과 설탕통에 이름이 적혀 있으면 그럴듯한 맛을 낼 수 있습니다. 하지만 이름표를 떼고 똑같은 가루와 액체를 주면 같은 사람은 같은 요리를 만들지 못합니다. 그렇다면 처음의 성공은 요리 이해 덕분이었을까요, 아니면 이름표 덕분이었을까요. 논문이 묻는 것도 이와 같은 질문입니다. 이름표가 있을 때와 없을 때의 간격이야말로 측정해야 할 대상이라는 것이죠.

같은 미로를 두 가지 지도로 건네는 방법

이제 실험 장치인 AutoTuring을 들여다보겠습니다. 겉으로 보면 단순합니다. 같은 에이전트가 같은 15차원 가속기 설계 공간을 두 가지 조건으로 풉니다. 한쪽은 설계 조건으로, 구조 변수의 이름이 보이고 시뮬레이터 카운터도 함께 주어집니다. 다른 한쪽은 블라인드 조건으로, 같은 변수들이 0과 1 사이 익명 변수로만 보입니다.

그런데 이 단순함 뒤에는 꽤 까다로운 통제가 숨어 있습니다. 평가자도 같고,合法한 설계 공간도 같고, 도달 가능한 최적점도 같게 두었다고 합니다. 그래서 두 조건에서 달라지는 것은 의미뿐입니다. 숫자만 놓고 보면 같은 미로인데, 한 번은 벽에 이정표가 붙어 있고 다른 한 번은 이정표가 모두 지워진 셈이죠. 저는 이 설계가 마음에 들지만, 동시에 얼마나 손이 많이 가는 선택이었을지도 짐작이 갑니다. 최적점이 어긋나면 비교가 깨지기 때문에, 두 표현이 정말 같은 공간을 가리키도록 맞추는 작업이 먼저 필요했을 테니까요.

그렇다면 왜 15차원일까요. 너무 작으면 이름의 힘이 드러나기 전에 탐색으로 다 뒤집을 수 있고, 너무 크면 반대로 이름이 있어도 헤맬 수 있습니다. 15라는 숫자는 그 중간 어딘가에서 이름의 도움을 가늠하기에 적당한 크기로 읽힙니다. 물론 논문이 이 차원 수를 정당화하는 별도 논증을 길게 펼치지는 않는데, 저는 그래서 이 숫자를 절대적인 기준보다는 비교를 위한 무대로 이해했습니다. 중요한 것은 차원의 개수가 아니라, 두 조건이 같은 무대 위에 있다는 점이기 때문입니다.

이름이 보인다는 것은 정확히 무엇이 달라지는 걸까

설계 조건에서 에이전트가 보는 것은 이름 있는 구조 변수와 시뮬레이터 카운터입니다. 예컨대 어떤 버퍼를 키웠는지, 어떤 타일 크기를 바꿨는지 같은 선택이 언어로 보인다는 뜻이죠. 시뮬레이터 카운터까지 함께 보면, 바꾼 선택이 어디에서 시간을 벌고 어디에서 메모리를 더 쓰는지 힌트를 얻을 수 있습니다. 반면 블라인드 조건에서는 같은 선택이 0과 1 사이 숫자로만 보입니다. 올리면 무엇이 커지는지는 알 수 있지만, 그것이 버퍼인지 연산기 개수인지, 메모리 대역폭과 어떤 관계인지는 가려집니다.

이 차이는 생각보다 중요합니다. 이름을 안다는 것은 과거에 읽은 문서와 연결할 수 있다는 뜻이기 때문입니다. 학습 과정에서 본 아키텍처 논의, 병목에 대한 설명, 타일링과 재사용에 대한 직관이 전부 단서로 소환될 수 있죠. 그래서 설계 조건은 단순히 정보가 더 많은 조건이 아니라, 사전 지식이 개입할 수 있는 조건입니다. 반대로 블라인드 조건은 사전 지식을 쓸모없게 만드는 장치에 가깝습니다. 같은 숫자라도 그것이 무엇을 뜻하는지 모르면, 아는 이야기로 꿰맞출 수 없으니까요.

저는 여기서 한 가지 질문을 덧붙이고 싶었습니다. 카운터는 과연 이름과 같은 층위의 단서일까요. 카운터는 바꾸고 나서 돌아오는 반응이라서, 이름처럼 미리 아는 지식이라기보다 실험에서 얻는 피드백에 가깝습니다. 논문은 두 가지를 묶어서 설계 조건으로 두었는데, 실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이름만 지우고 카운터는 남기면 어떻게 될까, 반대로 카운터만 지우면 어떻게 될까 하는 것이죠. 이번 실험은 그 둘을 나누지 않았으므로, 이름의 효과와 피드백의 효과를 따로 떼어 말하기는 어렵습니다. 저는 이 점을 논문의 흠이라기보다 다음 실험을 부르는 여백으로 봅니다.

아홉 개 커널 묶음이 무대가 된 이유

평가 무대는 아홉 개 커널로 이루어진 FP16 GEMM 묶음이라고 합니다. 행렬 곱을 여러 모양으로 반복해서 재는 셈인데, 가속기 이야기를 할 때 GEMM이 자주 등장하는 데는 이유가 있습니다. 연산 밀도가 높아서 구조 선택의 차이가 성능으로 비교적 또렷하게 드러나기 때문입니다. 한 가지 모양만 재면 특정 모양에 맞춘 설계가 유리해질 수 있지만, 아홉 개를 묶으면 그런 편법을 누르기가 쉬워집니다.

여기서 비교 기준으로 등장하는 것이 모델링된 H200입니다. 실제 칩을 가져다 둔 것이 아니라, 모델로 구현된 기준 가속기를 넘는지가 관전 포인트가 됩니다. 설계 조건은 이 기준을 평균 5.4% 앞섰다고 합니다. 5.4%라는 숫자는 얼핏 보면 크지 않아 보이지만, 이미 잘 다듬어진 기준을 상대로 거둔 차이로 보면 가볍지 않습니다. 다만 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 이깟 몇 퍼센트가 아니라, 그 몇 퍼센트가 이름이 있을 때만 나왔다는 사실이 논문이 말하려는 바이기 때문입니다.

그렇다면 왜 FP16일까요. 요즘 가속기에서 많이 쓰이는 정밀도라는 점도 있지만, 실험을 해석할 때는 다른 의미도 있습니다. 정밀도가 고정되면 숫자 표현 방식이라는 변수가 잠기고, 구조와 매핑의 효과가 더 잘 드러납니다. 그래서 아홉 개 커널 묶음은 단순한 점수판이 아니라, 구조 이해가 개입할 여지를 남기면서도 운을 줄이는 장치로 읽힙니다. 물론 실제 워크로드에는 GEMM이 아닌 연산도 많으므로, 이 묶음에서의 승리가 곧바로 일반 가속기 설계 능력으로 이어진다고 보기는 어렵습니다. 논문도 그런 일반화를 서두르지 않는데, 그 신중함이 오히려 신뢰를 줍니다.

숫자는 작아 보여도 이야기는 크다

이제 논문이 전하는 숫자를 한꺼번에 펼쳐보겠습니다. 설계 조건은 블라인드 조건보다 평균 12.3% 앞섰고, 시뮬레이터 호출은 70.1% 적게 썼다고 합니다. 기준 가속기와 견준 5.4%와 나란히 두면 그림이 더 또렷해집니다. 이름을 볼 때 에이전트는 더 좋은 점에 더 적은 시도로 도달한 것이죠.

12.3%라는 차이는 두 조건의 간격, 즉 이름이 주는 이득을 가리킵니다. 70.1%라는 절감은 그 이득이 어떻게 만들어졌는지를 보여줍니다. 마구 찔러보는 대신 방향을 잡고 움직였다는 뜻이기 때문입니다. 제가 이 대목에서 떠올린 장면은 낯선 동네에서 길을 찾는 일입니다. 지명이 보이는 지도를 든 사람은 몇 번만 꺾어도 목적지에 닿지만, 지명이 지워진 지도라면 같은 자리를 찾기 위해 훨씬 많이 헤맬 수밖에 없습니다. 호출 수의 차이는 바로 그 헤맴의 차이입니다.

문제는 그다음입니다. 이 숫자를 어디까지 믿어야 할까요. 논문에 따르면 조건마다 다섯 번에서 여섯 번 정도의 실행을 거쳤다고 합니다. 적지 않은 노력이지만, 분산이 큰 탐색 실험으로 보면 넉넉한 횟수는 아닙니다. 평균 12.3%라는 값이 몇 번의 잘 풀린 실행에 끌려간 것은 아닌지, 호출 수 절감이 매번 안정적으로 나타난 것인지가 궁금해집니다. 저는 그래서 이 숫자를 확정된 성능표보다는 방향을 가리키는 화살표로 읽었습니다. 화살표의 방향은 분명합니다. 이름이 있을 때 더 잘, 더 빨리 찾는다. 다만 화살표의 길이는 앞으로 더 많은 실행으로 다듬어야겠죠.

비평가가 끼어들면 벌어지는 일

논문에서 개인적으로 인상 깊었던 대목은 비평가 루프에 대한 결과입니다. 구조화된 비평을 덧붙이면 블라인드 조건의 부족한 점이 상당 부분 메워졌지만, 설계 조건에서는 별다른 이득이 없었다고 합니다. 이름이 없을 때는 비평가가 길을 잡아주고, 이름이 있을 때는 비평가가 더 보탤 것이 없었다는 것이죠.

생각해보면 사람 조직에서도 비슷한 일이 벌어집니다. 배경 지식이 없는 사람에게는 좋은 비평가가 큰 도움이 됩니다. 어디를 봐야 하는지, 무엇을 의심해야 하는지를 짚어주니까요. 하지만 이미 맥락을 아는 사람에게 같은 비평을 덧붙이면 말이 길어질 뿐 결과가 크게 달라지지 않을 때가 있습니다. 논문은 이 관계를 대체재라는 말로 정리합니다. 구조 지식과 구조화된 비평이 서로 보완하는 것이 아니라, 한쪽이 있으면 다른 한쪽의 몫이 줄어든다는 것이죠.

그렇다면 비평가는 정확히 무엇을 메워준 걸까요. 아마도 방향 없는 탐색에 최소한의 질서를 부여한 것으로 보입니다. 익명 변수만 보고 헤매는 에이전트에게, 이전 시도가 어땠는지 되짚고 다음 시도를 좁히는 틀을 준 셈이죠. 반대로 이름을 보는 에이전트는 이미 그런 틀을 머릿속에 갖고 있었을 가능성이 큽니다. 그래서 바깥에서 주는 비평이 겹치는 조언에 그쳤을 수 있습니다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 그런 눈으로 보면 비평가 루프의 효과는 점수보다 과정에 대한 힌트로 읽힙니다.

서로 돕는 사이가 아니라 대신하는 사이라는 말

대체재라는 표현은 얼핏 차가워 보이지만, 실제로는 꽤 실용적인 뜻을 품고 있습니다. 두 가지가 서로를 보완한다면 둘 다 갖춰야 하지만, 대신할 수 있다면 상황에 따라 골라 쓸 수 있기 때문입니다. 구조 지식이 없는 환경이라면 비평가를 붙이고, 구조 지식을 줄 수 있는 환경이라면 비평가 없이도 간다는 식의 선택이 가능해집니다.

실제 시스템 관점에서 보면 이 선택은 비용 문제로 이어집니다. 시뮬레이터 호출은 공짜가 아닙니다. 시간도 들고, 컴퓨팅도 들고, 기다림도 필요합니다. 설계 조건이 70.1% 적은 호출로 더 좋은 점에 도달했다는 사실은, 이름이라는 단서가 탐색 예산을 아껴준다는 뜻입니다. 반면 블라인드 조건에서는 비평가 루프가 그 예산을 메워주는 역할을 했을 수 있습니다. 어느 쪽이 더 쌀지는 현장마다 다르겠죠. 시뮬레이터가 무겁다면 이름을 주는 쪽이 유리하고, 구조를 설명하기 어렵다면 비평가를 붙이는 쪽이 나을 수 있습니다.

여기서 한 가지 오해를 미리 걷어낼 필요가 있습니다. 대체재라는 말이 비평가가 쓸모없다는 뜻은 아닙니다. 오히려 이름이 없을 때 비평가가 격차를 상당 부분 메웠다는 사실은, 비평가의 가치를 보여주는 증거에 가깝습니다. 다만 그 가치가 이름이 있을 때는 드러나지 않았을 뿐이죠. 저는 이 대목을 읽으면서, 앞으로 에이전트 시스템을 짤 때는 무엇을 아는지와 어떻게 되짚는지를 같은 선반 위에 올려두고 봐야겠다고 생각했습니다. 둘은 다른 부품이 아니라, 같은 빈칸을 채우는 두 가지 방식일 수 있으니까요.

아직 결론이라고 부르기에는 이른 이유

이 논문을 과장 없이 읽으려면 한계도 함께 봐야 합니다. 논문 스스로 밝히듯, 결과는 예비적인 수준이며 조건마다 다섯 번에서 여섯 번의 실행을 거친 것이고, 무대도 모델로 구현된 단일 가속기입니다. 비교 자체가 기여라는 말도 덧붙였습니다. 저는 이런 선언을 논문의 약점이 아니라 미덕으로 봅니다. 작은 실험을 크게 포장하지 않았기 때문입니다.

그렇다면 이 한계는 결과를 어떻게 좁힐까요. 우선 단일 가속기라는 점이 큽니다. 구조에 대한 이해가 특정 공간에서만 통하는 요령일 가능성을 배제할 수 없습니다. 다른 가속기, 다른 정밀도, 다른 연산 묶음에서도 같은 간격이 나타나는지는 아직 모릅니다. 다음으로 실행 횟수가 적다는 점이 있습니다. 탐색 실험은 운에 따라 결과가 출렁일 수 있어서, 평균값 하나만으로는 분포를 알기 어렵습니다. 마지막으로 모델로 구현된 기준이라는 점도 있습니다. 실제 하드웨어의 제약, 예를 들어 전력이나 면적, 배치와 배선의 물리적 한계까지 담고 있는지는 분명치 않습니다.

그럼에도 저는 이 실험이 헛되지 않다고 봅니다. 기여가 가속기 자체가 아니라 비교 방식에 있다는 선언이, 한계를 솔직하게 드러내면서도 글의 중심을 지켜주기 때문입니다. 좋은 벤치마크는 처음부터 완벽한 것이 아니라, 무엇을 속이지 않겠다는 약속이 분명한 것이라고 저는 믿습니다. 그런 눈으로 보면 다섯 번 남짓한 실행도 변명으로 보이지 않습니다. 오히려 앞으로 몇 번을 더 돌리고, 어떤 가속기를 추가하고, 어떤 조건을 더 나눠야 할지를 보여주는 출발점으로 읽힙니다.

제가 앞으로 보고 싶은 것은 그다음 실험입니다

여기까지 읽으면 자연스럽게 다음 질문이 생깁니다. 그렇다면 무엇을 더 쪼개봐야 할까요. 저는 먼저 이름과 카운터를 나눠보는 실험이 보고 싶습니다. 이름만 있고 카운터가 없을 때, 카운터만 있고 이름이 없을 때, 둘 다 있을 때를 비교하면, 사전 지식의 힘과 피드백의 힘이 따로 드러날 것입니다. 지금은 두 가지가 한 묶음이므로, 12.3%라는 간격 안에 무엇이 얼마나 들어 있는지 알 수 없습니다.

다음으로 보고 싶은 것은 다른 설계 공간에서의 반복입니다. GEMM 묶음을 넘어 메모리 계층이 더 깊거나, 데이터 이동이 더 까다로운 연산으로 무대를 옮겼을 때도 같은 간격이 유지될까요. 만약 유지된다면 이해라는 말이 더 단단해지고, 만약 무너진다면 이해가 특정 무대에 묶인 요령에 가까웠다는 뜻이 됩니다. 어느 쪽이든 알아낼 가치가 있습니다. 실패에서 배우는 것이 성공을 따라 하는 것보다 클 때가 많으니까요.

마지막으로 비평가 루프의 내역이 궁금합니다. 어떤 비평이 블라인드 조건을 끌어올렸는지, 그 비평이 사실상 구조 지식을 말로 풀어준 것은 아니었는지가 궁금합니다. 만약 비평가가 이름 없이도 구조 비슷한 조언을 만들어냈다면, 대체재라는 말은 더 깊은 뜻을 갖게 됩니다. 지식이 머릿속에 있든, 대화 속에 있든, 같은 빈칸을 메울 수 있다는 이야기니까요. 그래서 저는 이 논문을 점수표가 아니라 질문표로 간직하려 합니다. 에이전트가 무언가를 해냈다고 할 때, 우리는 무엇을 물어야 하는지를 알려주는 질문표로 말이죠.

점수가 아니라 간격을 보는 습관

처음에 저는 에이전트의 하드웨어 설계 성공담을 들으면 곧바로 대단하다고 느끼는 쪽이었습니다. 그런데 이 논문을 따라가면서 생각이 조금 바뀌었습니다. 대단한 점수 뒤에는 대단하지 않은 이유가 숨어 있을 수 있고, 그 이유를 가려내는 일이야말로 평가의 본질에 가깝기 때문입니다. 같은 공간을 이름 있게도 풀어보고 이름 없이도 풀어보는 이 단순한 장치가, 그 본질을 꽤 날카롭게 찌른 셈이죠.

그렇다면 사람의 역할은 무엇일까요. 저는 앞으로 에이전트에게 설계를 맡기는 일이 늘수록, 점수를 읽는 눈보다 간격을 읽는 눈이 더 중요해질 것이라고 봅니다. 같은 에이전트라도 보여주는 방식에 따라 결과가 얼마나 달라지는지, 그 달라짐을 메우는 데 무엇이 들었는지, 그리고 그 비용을 현장에서 감당할 수 있는지를 묻는 습관이 필요합니다. 이 논문은 그 습관에 구체적인 모양을 준 글입니다. 답을 단정하지 않았지만, 물어야 할 질문을 분명히 남겼습니다. 그래서 다음에 또 에이전트가 무언가를 설계했다는 소식을 들으면, 저는 먼저 이렇게 묻게 될 것 같습니다. 이름표를 떼면 어떻게 되는데요.