추상화를 은퇴시켜라: 에이전트 시대에 CUDA DSL의 자리를 다시 묻다

스탠퍼드 헤이지 리서치(Hazy Research)가 자신들이 만든 CUDA 라이브러리 ThunderKittens을 두고 "머지않아 은퇴할 것"이라는 도발적인 진단을 내놨다. GPU 커널을 손으로 최적화해 본 사람이라면 라이브러리 하나를 애지중지 만들어 놓고 스스로 그 수명을 예고하는 이 태도가 얼마나 이례적인지 알 것이다. 배경에는 지난 1년간 이들이 겪은 개발 방식의 급격한 변화가 있다.

메가커널, 그리고 사라진 추상화 계층

이들이 씨름해 온 대상은 이른바 메가커널(megakernel)이다. 여러 연산을 하나의 거대한 GPU 커널로 융합해 실행하는 방식으로, 복잡한 자료구조와 스레드·SM·GPU 간의 광범위한 동기화, 깊게 중첩된 제어 흐름을 요구한다. 사람의 머릿속에 다 담기 어려운 복잡도다. 그래서 지난해 이들은 컴퓨터과학이 70년간 해 온 그대로, 추상화 계층을 하나 쌓았다. 그럼에도 경쟁 조건과 교착 상태를 두어 달간 붙잡고 나서야 라마(Llama) 모델을 빠르게 돌릴 수 있었다.

올해 MoE(전문가 혼합) 메가커널을 만들 때는 접근을 바꿨다. 추상화 계층을 아예 삭제하고, 에이전트와 함께 복잡도를 직접 뚫고 들어가 목표 하드웨어에 맞춘 코드를 처음부터 작성했다. 중간에 끼워 넣던 C++ 추상화 계층은 필요하지 않았다. 핵심은 메가커널을 설계하는 아이디어 자체가 덜 중요해진 것이 아니라, 그 아이디어를 정교한 C++ 템플릿 대신 프롬프트라는 형태로, 불완전하고 지저분한 상태 그대로 표현할 수 있게 됐다는 점이다.

자동화되는 일과 아직 남은 일

지난 분기 동안 관찰된 패턴은 흥미롭다. 추상화 없이도 이미 할 수 있던 작업, 예컨대 최적화된 GEMM 커널 작성은 적절한 프롬프트만 주면 거의 자동화됐다. 아직은 어떤 PTX 명령을 쓸지, 워프 특화(warp specialization) 설계를 어떻게 할지 사람이 짚어 줘야 하지만, 그 상태에서 최신 수준에 도달하는 속도는 놀랍도록 빠르다. 반면 추상화가 반드시 필요했던 메가커널은 여전히 한 번에 뽑아내지 못한다. 다만 관리 불가능해 보이던 복잡도가 관리 가능해졌는데, 모호한 지시를 받아 코드를 만들어 내는 일종의 '컴파일러'가 손에 들어왔기 때문이다. 인지 부담을 덜어 주던 추상화의 역할을 에이전트가 넘겨받기 시작한 셈이다.

저자들은 여기서 귀납적으로 한 걸음 더 나간다. 인지 부담을 덜어 주는 용도의 추상화가 은퇴한다면, 같은 논리로 CUDA DSL도 은퇴 명단에 오른다는 것이다. 어디까지 내려갈지는 모른다고 인정한다. 추상화가 순수하게 '계약'으로만 기능하고 더는 인지 부담을 대신 짊어지지 않는 어떤 바닥이 있을 텐데, 지금 위치에서는 그 바닥이 보이지 않는다고 말한다.

코드베이스의 정밀함과 프롬프트의 이동성

글의 중심 논지는 코드베이스와 프롬프트의 대비다. 코드베이스의 강점은 정밀함이다. 특정 기계가 두 번 실행해도 똑같이 동작하는, 모호하지 않은 유일한 산출물이다. 그러나 그 정밀함의 대가는 취약성이다. 특정 언어, 프레임워크, 하드웨어 타깃, 그리고 작성한 팀만이 온전히 이해하는 관습에 묶여 있어 이식 가능해 보이지만 실은 그렇지 않다. 프롬프트는 정반대다. 모호하지만 이동한다. 같은 의도를 다른 작업자에게 넘겨도, 그 작업자가 빈틈을 옳게 메울 만큼 똑똑하다면 빈틈을 미리 표준화하지 않고도 올바른 결과를 얻는다. 여기서 저자들은 컴파일러 비유를 든다. 우리는 이미 불투명한 변환을 받아들여 왔다. 실제로 실행되는 어셈블리를 직접 쓰는 사람은 드물고, 컴파일러가 재배열·인라인·벡터화하며 실행 내용을 바꿔도 우리는 그 거래를 택했다. 컴파일러가 우리보다 더 자주 옳았기 때문이다. 지능이 의도와 기계 사이에 앉는 일은 새롭지 않고, 그 지능이 한 단계 더 위로 올라앉는 것은 정도의 차이일 뿐 종류의 차이는 아니라는 것이다.

놓아주기 전에 따져야 할 것

다만 저자들은 스스로의 주장에 신중한 단서를 여럿 단다. 첫째, 추상화는 인지 부담 관리 수단만이 아니라 적용·재사용·리뷰가 달라붙는 공유된 표면이다. 이것이 없으면 검증 문제가 폭발적으로 늘어난다. ThunderKittens을 쓰는 열 개 팀은 같은 타일 의미론을 공유해 검증하지만, 저마다 메가커널을 만드는 열 개 팀은 서로 겹치지 않는 열 개의 문제 집합을 안고 간다. 둘째, 공유된 오라클(정답 판정 기준)이 없다는 문제다. 메가커널에서는 테스트가 곧 계약이자 작업 그 자체인데, 프레임워크를 지웠을 때도 이들은 참조 구현, 수치 허용 오차, 프로파일링한 간트 차트에 대한 직관 같은 오라클은 남겨 두었다. 오라클이 층보다 오래 살아남을 때에만 그 층을 은퇴시킬 수 있다는 것이다. 셋째, 자신들이 편향된 단일 표본이라는 점이다. 이들은 깊이 아는 도메인에서 추상화를 지웠다. 추상화는 아직 지식이 없는 사람에게 지식을 전달하는 역할도 하는데, 에이전트가 워프 특화를 처음 듣는 사람의 빈틈까지 메워 줄지는 알 수 없다고 솔직히 인정한다.

결국 이들이 던지는 실무적 함의는 무엇을 남기고 무엇을 버릴 것인가로 요약된다. 남길 것은 의도, 불변식, 테스트, 그리고 ThunderKittens 같은 추상화 안에 살면서 그것을 하드웨어 위에서 옳게 유지하던 어렵게 얻은 도메인 지식이다. 라이브러리는 사라질 수 있어도 그 지식은 밑에 깔린 CUDA나 HIP가 손튜닝 대신 재생성된다고 해서 증발하지 않는다. 바뀌는 것은 신뢰의 위치다. 우리는 diff가 아니라 명세와 오라클을 검증하게 되고, 구현물은 진실의 원천이 아니라 특정 한 번의 컴파일 결과를 담은 캐시처럼 소모품이 된다. 한국의 커널·인프라 엔지니어에게 이 글은 도구 하나의 미래 예측이라기보다, 앞으로 무엇에 검증 역량을 집중할지에 대한 질문으로 읽힌다. 다만 이 진단이 도메인을 깊이 아는 소수의 경험에서 나온 것이며 온보딩과 지식 전수의 문제는 열린 채 남아 있다는 점은 함께 기억할 필요가 있다.