작년 이 팀은 GPU 커널이 너무 복잡해 머릿속에 담기지 않자 C++ 추상화 계층을 만들었습니다. 컴퓨터과학이 70년간 해온 바로 그 방식이죠. 올해 같은 종류의 커널을 다시 만들면서는 그 계층을 지웠습니다.
메가커널 연구로 알려진 스탠퍼드 Hazy Research가 「Retire the Abstractions」라는 글을 내놨습니다. 요약은 한 줄이죠. CUDA DSL이 은퇴를 향해 가고 있다는 것. 자신들이 만들어 애착을 갖고 있는 ThunderKittens도 그 명단에 함께 올려두었습니다.
출처: Retire the Abstractions – Hazy Research
추상화가 맡고 있던 일자리
작년의 상황은 이랬습니다. 메가커널을 짜려면 복잡한 자료구조, 스레드와 SM과 GPU를 넘나드는 동기화, 깊게 중첩된 제어 흐름을 한꺼번에 다뤄야 했죠. 감당이 안 되니 추상화 계층을 세웠고, 그러고도 두 달을 경쟁 조건과 교착 상태와 싸운 뒤에야 원하는 속도가 나왔습니다.
올해 MoE 메가커널을 만들 때는 그 추상화를 지웠습니다. 에이전트와 함께라면 복잡도를 직접 뚫고 들어가 목표에 맞춘 코드를 처음부터 짤 수 있었기 때문이죠. 중간 계층의 C++ 템플릿은 필요하지 않았습니다.
팀이 관찰한 구분이 흥미롭습니다. 원래도 추상화 없이 하던 일, 예컨대 최적화된 GEMM 커널 작성은 프롬프트만 제대로 주면 거의 자동화됐죠. 반대로 추상화가 있어야 했던 메가커널은 여전히 한 번에 나오지 않습니다. 달라진 건 그 추상화를 정교하게 설계된 C++ 템플릿이 아니라, 불완전하고 지저분한 형태로 프롬프트에 담아둘 수 있게 됐다는 것.
인지 부하를 대신 져주는 역할로서의 추상화가 은퇴하고 있다는 게 팀의 표현입니다. 그 자리를 에이전트가 가져가고 있다는 뜻이죠.
코드베이스와 프롬프트가 맞바꾸는 것
여기서 글은 도발적인 질문을 던집니다. 프롬프트가 스택의 모든 계층을 생성할 수 있다면, 코드베이스의 값어치는 얼마인가.
코드베이스가 내세우는 강점은 정밀함입니다. 특정 기계가 두 번 실행해도 똑같이 동작하는, 모호하지 않은 유일한 산출물이죠. 그런데 그 정밀함의 대가는 부서지기 쉽다는 것. 언어와 프레임워크, 하드웨어 타깃, 그리고 작성한 팀만 제대로 이해하는 관습에 묶여 있으니까 말입니다.
프롬프트는 정반대입니다. 흐릿하지만 이동하죠. 같은 의도를 다른 실행자에게 건넸을 때 그 실행자가 빈칸을 알아서 메울 만큼 똑똑하다면, 빈칸을 미리 표준화하지 않고도 맞는 결과가 나오는 겁니다.
그래서 경쟁 구도가 이렇게 잡힙니다. 덜 명세된 지시를 읽고 알아서 판단하는 똑똑한 실행자 대 판단이 필요 없도록 모든 빈칸을 명세해두는 방식. DSL과 프레임워크는 후자를 코드베이스의 형태로 구현한 것이고, 실행자가 더 이상 멍청하지 않다면 그 근거가 사라진다는 논리입니다.
낯선 거래도 아닙니다. 실제로 돌아가는 어셈블리를 직접 쓰는 사람은 이제 거의 없습니다. 컴파일러가 순서를 바꾸고 인라인하고 벡터화하며, 팀의 누구도 정확히 짚어낼 수 없는 방식으로 실행 코드를 바꿔놓죠. 그 거래를 받아들인 이유는 컴파일러가 우리보다 더 자주 옳았기 때문입니다.
의도와 기계 사이에 지능이 끼어드는 구조는 이미 있었습니다. 남은 질문은 그 지능을 더 위층에 두는 것이 정도의 차이냐 종류의 차이냐죠. 팀은 종류의 차이는 아니라고 봅니다.
그래도 남겨야 하는 두 가지
글이 결론을 밀어붙이지 않는다는 점도 눈에 띄죠. 추상화를 놓아주기 전에 따져볼 게 더 있다고 팀은 스스로 단서를 답니다.
첫째는 공유 표면입니다. 추상화는 인지 부하를 덜어주기만 하는 게 아니라, 응용과 재사용과 리뷰가 들러붙는 자리이기도 합니다. 열 개 팀이 같은 라이브러리의 타일 의미론을 함께 검증하면 그 노력이 시간이 갈수록 쌓입니다.
반면 열 개 팀이 각자 맞춤 커널을 생성하면 서로 겹치지 않는 문제 열 벌이 생기죠. 검증 과제의 캄브리아기 대폭발이라는 게 팀의 표현입니다.
둘째는 검증 오라클입니다. 정답을 독립적으로 확인할 수단이 없으면, 생성된 코드가 맞는지 판단할 근거도 함께 사라지니까 말이죠. 추상화가 물러난 자리에 이 두 가지가 남아 있어야 한다는 것이 글의 조건입니다.
코드를 덜 읽자는 이야기와 만나는 자리
이 논의는 antirez가 앞서 꺼낸 주장과 층위만 다를 뿐 방향이 같습니다. 그는 코드를 줄 단위로 읽는 대신 설계를 묻고 그 모델이 맞는지 판단하는 쪽이 낫다고 했죠. 커널 추상화 이야기와 개발자의 하루 이야기가 같은 자리에서 만나는 셈입니다.
코드를 안 볼수록 나은 개발자가 된다, Redis 창시자의 역설
두 글을 겹쳐 보면 통제 대상의 목록이 남습니다. 무엇을 만들지에 대한 아이디어, 여러 사람이 함께 기대설 수 있는 공유 표면, 그리고 결과가 맞는지 독립적으로 확인할 수단.
희소해지는 쪽은 판단이다
O’Reilly에 실린 글 하나가 이 목록에 각도를 더합니다. 소프트웨어 아키텍처의 제1법칙, 그러니까 “모든 것은 트레이드오프”라는 명제는 생성형 AI가 등장했다고 폐기되지 않죠. LLM은 “어떻게” 질문의 기계입니다. 사가 패턴을 어떻게 구현하는지 같은 질문의 답은 이미 문서와 오픈소스로 세상에 존재합니다.
아키텍처 질문은 “해야 하는가”의 질문이고, 답에 필요한 정보는 어떤 학습 데이터에도 없습니다. 운영팀이 세 명이라는 것, 방금 클라우드 지출이 동결됐다는 것, 지난 조직 개편으로 특정 팀 분위기가 가라앉았다는 것. 트레이드오프를 나열하는 일은 모델이 훌륭하게 해내지만, 저울에 올릴 추는 조직 안에 있지 인터넷에 있지 않습니다.
그래서 코드가 싸질수록 결정은 비싸집니다. 예전에는 구현 비용 자체가 나쁜 설계의 제동장치였습니다. 의심스러운 설계도 만드는 데 몇 달이 걸렸고, 두 달째쯤 누군가 이상하다는 걸 알아챘습니다. 지금은 일주일이면 서비스 여러 개가 올라가고, 그 결정과 몇 년을 같이 살게 되죠.
내 일에 대입해보면 질문은 하나로 좁혀집니다. 지금 내가 시간을 쓰는 대상이 남이 대신 만들어줄 수 있는 층에 있는지, 아니면 나만 가진 맥락이 필요한 층에 있는지. 추상화를 은퇴시킬 수 있느냐는 물음은 결국 그 층을 다시 고르라는 요구에 가깝습니다.
참고자료:
답글 남기기