원래는 그냥 스크롤을 내리려던 참이었습니다. 요즘 이런 소식은 하루에도 몇 개씩 지나가서 제목만 보고 넘기는 게 습관이 됐습니다.
주말에 밀린 뉴스레터를 보다가 AlphaEvolve 를 이제 구글 클라우드 고객 누구나 쓸 수 있게 됐다는 줄이 지나갔습니다. 7월에 GA 가 됐다는 얘기였는데, 저는 읽기도 전에 이미 분류를 끝내고 있었습니다. 또 코딩 에이전트구나. Gemini CLI 랑 Claude Code 랑 Copilot 옆에 이름 하나 더 붙는 거겠지 하고 엄지를 밀었습니다.
그런데 바로 밑에 붙어 있던 문장에서 손이 멈췄습니다. 코드 스니펫을 생성하는 게 아니라 알고리즘을 반복해서 평가하고 개선한다는 문장이었습니다. 코드를 생성하지 않는 코딩 에이전트라는 게 무슨 말인지 감이 안 와서, 하려던 걸 미뤄두고 딥마인드 공개 문서와 작년 논문을 찾아 읽기 시작했습니다. 써본 건 아니고 읽기만 했습니다. 그날 밤 이게 뭔지는 얼추 알게 됐는데, 알고 나니까 머리가 제멋대로 다음 질문으로 넘어가더군요. 이걸 제 일에 들이면 어디에 쓰게 될까. 제가 매일 만지는 코드 중에 이 진화 루프한테 던질 만한 게 있긴 할까. 그 질문을 붙잡고 있다가 생각보다 곤란한 데까지 끌려갔습니다.
코드를 써주는 도구가 아니었습니다
이름에 Alpha 가 붙어 있으니 딥마인드 쪽 계보를 아는 분이면 감이 올 것 같습니다. AlphaGo 는 바둑, AlphaFold 는 단백질 구조를 다뤘고, 둘 다 사람이 손으로는 다 뒤져볼 수 없는 거대한 공간에서 좋은 수를 찾는 물건이었습니다. AlphaEvolve 도 그쪽입니다. 이번에 뒤지는 공간이 알고리즘이라는 것만 다릅니다.
저는 코드라는 단어를 보자마자 코드를 대신 써주는 도구로 읽어버렸습니다. 매일 쓰는 코딩 어시스턴트가 그런 일을 하니까요. 함수 하나 리팩터링해 달라고 하면 그럴듯한 코드를 내놓는 식입니다. AlphaEvolve 가 푸는 건 그런 문제가 아니었습니다.
딥마인드 문서에 나오는 설명이 제일 알아듣기 쉬웠습니다. 답을 알고리즘으로 쓸 수 있어야 하고, 그 결과를 자동으로 검증할 수 있어야 한다는 겁니다. 답이 맞았는지 사람이 들여다봐야 아는 문제가 아니라, 스크립트를 돌리면 점수가 나오는 문제여야 한다는 말로 읽었습니다.
로그인 화면을 만들어 달라는 건 AlphaEvolve 가 받을 문제가 아닙니다. 잘 만들었는지는 사람이 봐야 하고 정답도 하나가 아니니까요. 4×4 행렬 두 개를 곱하는 데 곱셈 횟수를 최소로 줄이라는 건 딱 맞는 문제입니다. 후보가 나오면 곱셈이 몇 번 들어갔는지 세고, 결과가 원래 곱셈과 같은지 확인하면 끝입니다. 정답은 아무도 모르는데 좋고 나쁨은 기계가 채점할 수 있는 문제, 그런 데서 더 나은 답을 찾아 계속 헤매는 에이전트라고 보면 될 것 같습니다.
생각해 보면 제가 쓰는 코딩 어시스턴트는 답이 맞았는지를 제가 봐야 압니다. 그래서 마지막엔 늘 제가 서 있습니다. AlphaEvolve 는 그 마지막을 스크립트한테 넘기는 대신 넘길 수 있는 문제만 받는 셈입니다. 받을 수 있는 문제는 훨씬 좁아지는데, 받은 문제는 사람 없이 끝까지 갑니다. 처음엔 그게 약점처럼 보였는데 읽을수록 이 도구가 일부러 그렇게 생긴 것 같다는 생각이 들었습니다.
실제로 이 행렬 문제에서 1969년 슈트라센 알고리즘 이후로 반세기 넘게 아무도 못 넘던 기록을 넘었다고 합니다. 수학자들이 머리가 모자라서 못 풀었다기보다는 손으로 뒤지기엔 경우의 수가 너무 많았던 문제였던 것 같습니다. 그 밖에도 풀리지 않은 수학 문제 수십 개에 던져서 상당수에서 기존 최고 수준을 다시 찾아냈고 몇 개는 넘어섰다고 합니다.
이 얘기를 읽으면서 든 생각은 좀 엉뚱한 쪽이었습니다. 반세기 동안 안 넘어간 기록이 사람이 모자라서가 아니라 뒤져볼 경우가 너무 많아서였다면, 제가 매일 보는 코드에도 그런 게 꽤 있을 것 같다는 생각입니다. 수학 기록처럼 대단한 건 아니어도, 처음 짠 사람이 이 정도면 됐다고 멈춘 뒤로 아무도 다시 들여다보지 않은 코드들 말입니다. 그 코드가 지금 최선이라서 그대로 있는 게 아니라 아무도 다른 방법을 안 뒤져봤기 때문에 그대로 있는 거라면, 그건 꽤 많은 양일 겁니다. 사람한테는 그걸 다 뒤져볼 시간이 없었고, 그래서 다들 그냥 두고 지나갔을 뿐이라는 생각이 들었습니다. 행렬 곱셈 기록이 넘어갔다는 소식보다 저한테는 이쪽이 더 오래 남았습니다. 대단한 발견이 아니라 그냥 아무도 손을 안 댄 코드가 많다는 얘기라서요.
수학 얘기는 멋있긴 한데 솔직히 저랑은 거리가 멀게 느껴졌습니다. 그러다 성과 목록을 조금 더 내려가니까 갑자기 가까운 얘기가 나왔습니다.
구글 안에서는 이미 돌고 있었습니다
하나는 데이터센터 스케줄링이었습니다. 구글 클러스터 관리 시스템인 Borg 가 작업을 어디에 배치할지 정하는 휴리스틱을 AlphaEvolve 가 찾은 버전으로 바꿨더니, 전 세계 컴퓨트의 0.7% 정도를 돌려받았다고 합니다. 숫자만 보면 작은데 구글 규모에서 0.7% 면 상상이 잘 안 되는 양입니다. 그리고 그게 실험이 아니라 1년 넘게 프로덕션에서 돌고 있는 값이라고 했습니다.
또 하나는 Gemini 를 학습시키는 데 쓰는 커널을 손본 얘기였습니다. 커널 하나를 꽤 빠르게 만들었고 그 덕에 전체 학습 시간이 조금 줄었다고 합니다. 여기서 좀 묘한 기분이 들었습니다. AlphaEvolve 안에서 돌아가는 게 Gemini 인데, 그 AlphaEvolve 가 Gemini 를 더 빨리 학습시키는 코드를 찾아낸 거니까요. 모델이 자기가 만들어지는 파이프라인을 직접 손보고 있는 셈입니다. FlashAttention 구현을 빠르게 만든 얘기도 같이 나왔습니다.
제가 멈칫한 건 성과가 커서라기보다 그게 원래 사람이 하던 일이라서였습니다. 스케줄러 휴리스틱을 다듬고, GPU 커널을 손으로 튜닝하고, 컴파일러가 뱉은 코드를 뜯어서 몇 퍼센트를 짜내는 일. 시니어 중에서도 한 분야를 오래 판 사람들이 하던, 성능 엔지니어링이라고 부르던 일입니다. 그걸 이제 진화 루프가 밤새 돌면서 대신 하고 있고, 사람보다 넓게 뒤지고 지치지도 않습니다.
그 일을 하던 사람들은 이걸 보고 어떤 기분일지 궁금했습니다. 몇 주씩 붙잡고 짜내던 걸 루프가 밤새 찾아온다면 허탈할 것 같기도 합니다. 그런데 거꾸로 생각하면 평가자를 제일 잘 쓸 사람도 그 사람들일 것 같습니다. 무엇이 빨라야 하고 무엇은 절대 희생하면 안 되는지, 벤치마크가 어디서 거짓말을 하는지를 제일 잘 아는 사람들이니까요. 일이 없어진다기보다 하던 일의 앞부분만 남는 쪽에 가깝지 않을까 싶은데, 이건 그냥 제 짐작입니다.
이게 처음 공개된 게 작년 5월이었고 Borg 쪽은 그때 이미 1년 넘게 돌고 있었다고 하니, 우리가 뉴스로 보기 한참 전부터 구글 안에서는 조용히 자원을 아끼고 있었다는 얘기가 됩니다. 그러다 올해 7월에 클라우드 고객한테 열었습니다. 저한테는 성과 숫자보다 이 순서가 더 크게 보였습니다. 자기들끼리 1년 넘게 써보고 이제 팔아도 되겠다고 판단한 거니까요.
루프를 종이에 그려봤습니다
어떻게 돌아가는지 모르면 AI 가 알아서 잘한다더라 정도로 끝나버릴 것 같아서, 논문 그림을 종이에 옮겨 그리면서 한 바퀴를 따라가 봤습니다. 구조는 생각보다 단순했습니다. 덩어리 네 개가 원을 그리면서 돕니다.
시작은 프로그램 데이터베이스입니다. 지금까지 시도한 프로그램이 각자 받은 점수랑 같이 쌓여 있는 창고 같은 겁니다. 맨 처음엔 사람이 넣어준 시드 프로그램 하나만 들어 있습니다.
프롬프트 샘플러가 이 창고에서 예전 시도들을 골라 와서 LLM 한테 줄 프롬프트를 만듭니다. 여태 이런 걸 해봤고 점수는 이렇게 나왔으니 참고해서 더 나은 걸 만들어 보라는 식의 맥락을 붙여주는 겁니다. 어떤 부모를 골라 오느냐가 다음 세대가 어디로 갈지를 정하니까 진화로 치면 짝을 고르는 단계 같습니다.
그다음이 LLM 앙상블이고 여기에 Gemini 가 들어갑니다. 모델 하나만 쓰는 게 아니라 Gemini Flash 가 아이디어를 넓게 뿌리고 Gemini Pro 가 깊게 파고드는 제안을 맡는다고 합니다. 빨리 많이 던지는 쪽과 천천히 신중한 쪽을 섞어둔 건데, 이 앙상블이 기존 프로그램을 이렇게 고쳐보면 어떻겠냐는 후보들을 내놓습니다.
세 번째가 평가자입니다. 저는 이게 이 시스템의 심장이라고 봅니다. 후보 프로그램을 실제로 실행해서 사용자가 정한 기준으로 점수를 매기는데, 여기에는 LLM 의 그럴듯함이 끼어들 틈이 없습니다. 돌려서 나온 숫자가 전부입니다. LLM 이 내놓은 걸 볼 때 늘 문제가 되는 건 그럴듯한 걸 믿어도 되느냐인데, 여기서는 그 질문이 아예 없어집니다. 맞았는지는 실행이 대답하니까요. 그럴듯한 것과 맞는 것이 따로 놀 수 있다는 걸 처음부터 인정하고 짠 구조 같아서 저는 이 부분이 제일 마음에 들었습니다.
그 점수가 다시 창고로 들어가고, 점수가 좋았던 프로그램은 다음 세대에서 부모로 뽑힐 확률이 올라갑니다. 나쁜 건 밀려납니다. 고르고, 제안하고, 채점하고, 저장하는 걸 계속 반복하면 창고에 쌓인 프로그램들의 점수가 점점 올라갑니다.
이 창고 얘기를 읽으면서 좀 부러웠던 게 있습니다. 실패한 후보도 점수와 같이 다 남는다는 겁니다. 사람이 성능을 만질 때는 해봤는데 안 빨라진 시도는 거의 안 남깁니다. 브랜치를 지우거나 되돌리고 나면 그런 걸 해봤다는 기억만 흐릿하게 남고, 몇 달 뒤에 다른 사람이 똑같은 걸 다시 해봅니다. 진화 루프는 그 헛수고를 안 합니다. 해본 건 다 점수로 적혀 있으니까요. 만약 제가 평소에 하는 성능 작업도 이렇게 해본 것과 점수를 전부 한 군데 쌓아두는 습관만 들여도, AlphaEvolve 를 안 쓰더라도 꽤 달라질 것 같다는 생각이 들었습니다. 적어도 같은 실패를 두 번 하지는 않을 테니까요. 그런데 막상 그런 기록을 남기는 사람은 거의 못 본 것 같습니다. 잘된 것만 커밋 메시지에 남고 안 된 건 아무 데도 안 남는 게 보통입니다.
말로 풀면 유전 알고리즘 교과서 그림이랑 거의 같습니다. 다른 건 변이를 만드는 쪽에 무작위 비트 플립 대신 Gemini 가 들어가 있다는 것 하나인데, 저는 이게 꽤 큰 차이라고 생각합니다. 전통적인 진화 알고리즘의 변이는 아무 데나 건드려 보고 운 좋으면 나아지는 식이라서, 코드 한 줄을 무작위로 바꿔서 빨라질 확률은 거의 로또입니다. 그래서 세대를 엄청나게 돌려야 겨우 조금 나아집니다. 여기서는 코드를 읽을 줄 아는 모델이 이중 루프인데 캐시 지역성이 나쁘니 순서를 바꿔보자 같은, 사람이 할 법한 생각을 담아서 후보를 만듭니다. 물론 그 생각이 다 맞지는 않고 틀린 제안도 잔뜩 나올 텐데, 그건 평가자가 걸러줍니다. 모델이 그럴듯하게 상상하고 실행 결과가 냉정하게 잘라내는 이 조합이 저는 제일 재밌었습니다. 따로 보면 둘 다 새로울 게 없는데 붙여놓으니 서로 모자란 걸 채워주는 느낌이었습니다.
넣는 게 딱 두 개라는 게 오래 남았습니다
루프를 다 따라가고 나서 제일 오래 붙잡고 있던 건 사용자가 이 시스템에 넣는 게 두 개뿐이라는 점이었습니다.
하나는 시드 프로그램입니다. 최적화하고 싶은 알고리즘의 첫 버전인데, 컴파일만 되면 되고 잘 짤 필요도 없습니다. 대충 돌아가는 출발점이면 진화가 알아서 그걸 부모 삼아 고쳐 나갑니다.
다른 하나가 평가자입니다. 후보가 얼마나 좋은지를 숫자 하나로 돌려주는 채점 스크립트, 그러니까 최대화하고 싶은 지표를 정의하는 함수입니다.
처음엔 두 개뿐이면 쉽겠다고 생각했는데 며칠 지나면서 두 번째가 제일 어렵다는 걸 알게 됐습니다. 시드는 대충 짜도 되지만 평가자는 대충 짜면 안 됩니다. 진화 루프는 평가자가 주는 점수 말고는 아무것도 안 보기 때문입니다. 제가 채점 함수를 잘못 쓰면 AlphaEvolve 는 제가 원한 걸 최적화하는 게 아니라 제가 실수로 적어둔 지표를 미친 듯이 최적화합니다. 속도만 점수에 넣고 정확도를 빼먹으면 답은 틀렸는데 엄청 빠른 코드를 자랑스럽게 들고 올 겁니다. 제 의도는 안 읽고 제가 쓴 숫자만 읽으니까요.
상상으로 한 장면을 그려보면 이렇습니다. 정렬 루틴 하나를 빠르게 만들고 싶어서 처리 시간이 짧을수록 점수가 높다고만 적어 넣었습니다. 며칠 밤을 돌리고 나니 놀랄 만큼 빠른 코드가 나왔습니다. 신나서 열어 봤더니 입력이 어떤 크기일 때만 맞고 나머지는 대충 뭉개는 코드였습니다. 정확해야 한다는 걸 점수에 안 넣었으니 시스템은 시킨 일을 완벽하게 한 겁니다. 보상을 잘못 설계하면 시스템이 그 허점을 파고든다는 얘기는 많이 들었는데, AlphaEvolve 는 그걸 아주 성실하게 재현해 줄 물건 같습니다. 이걸 쓰는 팀이라면 시드 코드를 근사하게 짜는 것보다, 자기가 원하는 좋음을 빠진 데 없이 숫자로 옮겼는지에 훨씬 오래 매달릴 것 같습니다.
사람한테 일을 맡길 때는 이런 일이 잘 안 생깁니다. 동료한테 이거 좀 빠르게 해달라고 하면 틀려도 된다는 뜻으로 알아듣는 사람은 없으니까요. 말하지 않은 상식이 같이 넘어갑니다. 평가자한테는 그 상식이 안 넘어가고 적은 것만 넘어갑니다. 그러니 평가자를 쓰는 건 평소에 말 안 하고 넘어가던 상식을 하나씩 꺼내서 적는 일에 가까울 것 같습니다. 그런 걸 적어본 적이 거의 없다는 게 좀 걸렸습니다.
생각해 보면 테스트 코드를 쓰는 일도 비슷합니다. 테스트는 이 함수가 당연히 이래야 한다는 걸 하나씩 꺼내서 적는 일인데, 다들 테스트 쓰기를 미루는 이유가 바로 그 당연한 걸 적는 게 지루하고 어색해서인 것 같습니다. 평가자는 거기서 한 단계 더 갑니다. 맞다 틀리다만 적는 게 아니라 얼마나 좋은지를 숫자로 적어야 하니까요. 테스트도 잘 안 쓰던 손이 평가자를 갑자기 잘 쓸 것 같지는 않습니다. 그래서 이 도구가 잘 들어가는 팀은 아마 원래부터 테스트와 벤치마크를 꼼꼼하게 챙기던 팀일 거라는 생각이 듭니다. 좋은 도구가 원래 잘하던 팀을 더 잘하게 만드는 쪽으로 쓰이는 건 늘 그랬던 것 같습니다.
여기서 처음으로 개발자가 하는 일이 어떻게 바뀌는지가 보였습니다. 코드를 짜는 일에서 무엇이 좋은 코드인지를 숫자로 정하는 일로 무게가 넘어갑니다. 알고리즘 본문을 쓰는 사람이 아니라 알고리즘이 어디를 향해 가야 하는지 기준을 세우는 사람이 되는 건데, 이게 더 쉬운 일 같지는 않습니다. 그래서 다시 처음 질문으로 돌아갔습니다. 제 일 중에 시드와 평가자를 이렇게 손에 잡히게 정할 수 있는 게 정말 있긴 한가.
제 일에 넣는다고 상상해 봤습니다
구글이 든 예시는 물류, 반도체, 유전체, 금융 같은 큰 도메인이었습니다. 멋있는데 저는 그런 규모의 문제를 안 다룹니다. 그래서 최근 몇 달 동안 제가 만진 코드 중에 이 루프한테 던질 만한 게 하나라도 있는지를 봤습니다.
후보를 찾기 전에 선부터 그었습니다. 평가자를 사람 손 안 타고 숫자 하나가 떨어지는 형태로 정의할 수 있느냐. 이게 안 되면 시드가 아무리 좋아도 처음부터 대상이 아닙니다.
그 기준으로 보니 제 일은 대부분 그냥 떨어졌습니다. 기능 붙이기, CRUD API 만들기, 버그 잡기, 화면 그리기. 제 시간의 팔 할이 이런 일인데 이건 점수 하나로 채점이 안 됩니다. 버그를 고쳤는지는 테스트가 통과했느냐 아니냐로 끝나지 최대화할 숫자가 아니고, 화면이 잘 나왔는지는 결국 제가 눈으로 봅니다. API 설계가 좋았는지는 반년쯤 지나야 압니다. 여기에 진화 루프를 붙이는 건 연장을 잘못 집은 거고, 이 선을 흐리게 두면 AI 가 다 해준다는 막연한 기대만 남고 진짜 쓸 데는 놓칠 것 같습니다.
팔 할을 걷어내고 나니 남은 두 할에서 오히려 후보가 잘 보였습니다. 평소에 나중에 성능 한번 봐야지 하고 미뤄두던, 목표가 숫자로 딱 떨어지는 일들입니다. 급하지 않으니까 미뤄두고, 미뤄두다 보니 성능은 그냥 지금 정도인 걸로 굳어 있던 것들이기도 합니다. 진화 루프한테 넘기면 밤새 돌려두면 되니까 미룰 핑계가 줄어듭니다. 그렇게 보면 이 도구는 제 일을 대신해 준다기보다 제가 안 하던 일을 하게 만드는 쪽에 더 가까울지도 모르겠습니다.
제일 먼저 떠오른 건 프로파일러를 켜면 늘 위에 떠 있는 핫패스 함수였습니다. 직렬화나 거리 계산 같은 루틴입니다. 이런 함수는 이미 테스트가 있어서 결과가 맞는지 확인할 수 있고, 속도는 벤치마크로 밀리초까지 찍힙니다. 시드는 지금 구현을 그대로 넣으면 되고, 평가자는 기존 테스트를 전부 통과할 때만 처리 시간의 역수를 점수로 주고 하나라도 틀리면 0점을 주게 짜면 될 것 같습니다. 정확성을 통과 조건으로 걸어두고 속도만 올리게 하는 겁니다. 이러면 아까 그 빠른데 틀린 코드는 0점이니까 진화가 그쪽으로 샐 이유가 없습니다.
그런데 이렇게 해서 빠른 코드가 나왔다고 쳐도, 그 코드를 제가 읽을 수 있을지는 또 다른 문제일 것 같습니다. 진화는 사람이 읽기 좋은지는 전혀 신경 쓰지 않으니까요. 점수에 안 들어간 건 없는 것과 같습니다. 테스트도 통과하고 빠르기도 한데 왜 빠른지는 아무도 설명 못 하는 코드가 핫패스 한가운데 들어오는 그림을 생각해 보면 좀 망설여집니다. 나중에 거기서 버그가 나면 그걸 고치는 건 루프가 아니라 사람입니다. 그렇다고 읽기 좋은 정도를 점수에 넣자니 그게 또 숫자로 안 떨어지는 종류의 일입니다. 결국 루프가 찾아온 아이디어를 보고 사람이 읽을 수 있는 모양으로 다시 짜는 단계가 하나 더 붙을 것 같은데, 그러면 밤새 돌려두고 끝이라는 그림이 조금 덜 깔끔해집니다.
그다음은 데이터베이스였습니다. 복잡한 리포트 쿼리가 인덱스 조합이나 조인 순서에 따라 성능이 크게 달라질 때가 있습니다. 옵티마이저가 늘 제일 좋은 걸 골라주지도 않아서 사람이 힌트를 붙여 가며 더듬던 일입니다. 시드는 지금 쿼리와 인덱스 구성이고, 평가자는 실제 데이터 분포를 흉내 낸 대표 쿼리 묶음을 돌렸을 때 총 실행 시간이나 비용을 돌려주면 됩니다. 정답이 정해져 있지 않은데 돌려보면 좋고 나쁨이 숫자로 나오니까 이 도구한테 딱 맞는 문제 같습니다. 다만 대표 쿼리 묶음을 뭘로 고르느냐가 또 평가자 문제입니다. 실제 트래픽이랑 다르게 골라두면 진화는 제가 고른 쿼리에서만 빠른 인덱스를 찾아올 거고, 운영에서는 오히려 느려질 수도 있습니다. 어느 후보를 붙잡아도 결국 같은 질문으로 돌아오는 게 좀 웃겼습니다. 좋다는 걸 뭘로 잴 거냐는 질문입니다.
그러고 나니 몇 개가 줄줄이 더 나왔습니다. 배치 작업 스케줄링이나 리소스 할당은 처리량이나 마감을 넘긴 건수를 점수로 잡으면 되고, 캐시 교체 정책은 대표 트래픽을 다시 돌렸을 때 적중률을 올리면 됩니다. 빌드 파이프라인 단계 순서나 병렬화도 전체 소요 시간이라는 숫자가 있습니다. 비용 함수가 분명한 휴리스틱이나 하이퍼파라미터 탐색은 말할 것도 없고요.
다만 선형 계획법이나 이차 계획법으로 깔끔하게 풀리는 문제라면 굳이 진화 루프를 밤새 돌릴 이유는 없을 것 같습니다. 정확한 답을 증명까지 붙여서 내놓는 전용 솔버가 이미 있으니까요. AlphaEvolve 가 잘 맞는 건 그 반대쪽인 것 같습니다. 탐색 공간이 지저분하게 넓고, 후보들이 기능은 다 맞는데 일부만 성능 기준을 넘는, 예전 같으면 유전 알고리즘이나 시뮬레이티드 어닐링을 꺼내던 문제들입니다. 저는 이걸 LLM 에 메타휴리스틱 탐색을 붙인 에이전트 정도로 이해하고 있습니다. 원리가 새롭다기보다 오래된 진화 탐색 뼈대에서 변이 만드는 쪽에 코드를 읽는 모델을 앉혀둔 것에 가깝다고 봅니다.
후보를 늘어놓고 보니 어려운 건 전부 평가자 쪽에 몰려 있었습니다. 핫패스 함수의 지금 구현을 시드로 넣는 건 복사해서 붙이면 끝입니다. 머리를 써야 하는 건 이 함수에서 좋다는 게 정확히 뭔지를 점수 한 줄로 줄이는 일입니다. 속도만 볼 건지, 메모리도 볼 건지, 최악 지연시간도 봐야 하는지, 정확성은 어디까지 통과 조건으로 걸 건지. 캐시라면 적중률만 볼 건지 지연시간과 메모리 압박까지 섞을 건지. 이걸 잘못 잡으면 진화는 제가 실수로 적은 지표를 향해 완벽하게 달려갑니다. 결국 이 도구를 쓸 수 있느냐는 모델이 얼마나 좋으냐보다 제가 평가자를 얼마나 잘 쓰느냐에 달려 있는 것 같습니다. 시드는 누구나 넣을 수 있으니까요.
스킬로 들어온다는 부분에서 또 멈췄습니다
GA 소식 중에 이 블로그 읽는 분들한테 제일 와닿을 것 같은 건, AlphaEvolve 가 Gemini Enterprise 에이전트 플랫폼을 통해 나오면서 에이전트형 코딩 도구 안에 스킬 형태로 붙는다는 부분이었습니다.
요즘 하네스를 짜고, 에이전트에 스킬을 물리고, 오케스트레이터로 엮는 얘기를 여기서 계속 해왔으니 스킬이라는 단어가 그냥 지나가지지 않았습니다. 딥마인드 연구소의 신기한 물건이 아니라 제 워크플로우 안에서 불러다 쓰는 부품이 된다는 뜻이니까요.
얼마 전에 제 레포를 트리거·토폴로지·verifier·stop rule 네 가지로 나눠서 본 적이 있는데, 그렇게 보면 AlphaEvolve 의 진화 루프는 verifier 가 사람 손을 완전히 떠난 형태입니다. 제가 만든 게이트는 그래도 결과를 사람이 읽게 되어 있는데, 여기서는 채점 결과가 사람을 안 거치고 곧바로 다음 세대 부모를 고르는 데 들어갑니다.
그려보면 이렇습니다. 코딩 에이전트한테 성능 병목 하나를 던집니다. 에이전트가 이건 최적화 탐색이 필요한 문제라고 보고 AlphaEvolve 스킬을 부릅니다. 시드 코드와 채점 기준을 넘겨두고 진화 루프가 뒤에서 도는 동안 다른 일을 하다가, 결과가 나오면 받아서 다음으로 넘어갑니다. 예전 같으면 성능 엔지니어를 붙여야 했던 일이 스킬 호출 한 번이 되는 겁니다.
만약 정말 그렇게 된다면 성능을 대하는 태도도 좀 달라질 것 같습니다. 지금은 성능 작업이 큰마음 먹고 하는 일이라 문제가 터지기 전까지는 잘 안 건드립니다. 그런데 호출 한 번으로 뒤에서 돌려둘 수 있다면, 코드를 고칠 때마다 이 함수도 한번 돌려볼까 하는 식으로 가볍게 쓰게 될 수도 있습니다. 그러면 성능은 가끔 하는 특별한 작업이 아니라 테스트 돌리듯 늘 하는 일이 되는 건데, 그게 좋은 건지 비용만 늘어나는 건지는 잘 모르겠습니다. 그래도 미뤄두던 일이 미뤄지지 않게 된다는 것만으로도 꽤 큰 변화일 것 같습니다. 성능이 나빠진 걸 몇 달 뒤에 알게 되는 일도 줄어들 거고요. 지금은 대개 누군가 느리다고 말해야 그제야 들여다보니까요.
이 대목에서는 등이 좀 서늘했습니다. 아까 본 Borg 얘기가 겹치면서, 장인의 영역이라고 다들 안심하던 성능 엔지니어링이 스킬 목록의 한 줄로 접히는 그림이 갑자기 구체적으로 보였습니다. 가격이나 운영 조건은 아직 나온 게 없어서 거기까지는 모르겠습니다. 진화 루프를 밤새 돌리는 비용이 사람 한 명이 며칠 붙는 비용보다 싸게 나올지, 아니면 비싸도 사람이 못 찾는 걸 찾으니까 쓰는 물건이 될지도 아직은 감이 안 옵니다.
사내 도입 계산을 안 해본 건 아닙니다. 봄에 회사 GPU 워크스테이션 한 대에 로컬 LLM 을 올리고 다섯 명이 붙었을 때 시트당 단가를 따져본 적이 있는데, 그때는 도입할지 말지가 모델 성능보다 동시 사용자 수와 워크플로우에 달려 있다는 쪽으로 생각이 모였습니다. AlphaEvolve 는 루프를 몇 시간씩 돌려두고 기다리는 물건이라 그 계산이 또 다르게 나올 것 같습니다. 사람이 붙어 있는 시간이 아니라 컴퓨트가 도는 시간으로 값을 매겨야 할 테니까요.
그리고 이 그림에서 좀 걸리는 게 하나 있습니다. 에이전트가 스킬을 부를 때 채점 기준은 누가 쓰는 걸까요. 앞에서 제일 어렵다고 한 그 부분을 에이전트가 알아서 짜서 넘긴다면, 제일 어려운 일이 제일 안 보이는 데서 일어나는 셈입니다. 빠르고 테스트도 통과했는데 뭘 기준으로 빨라졌는지는 아무도 안 들여다본 코드가 들어올 수도 있겠다 싶었습니다. 평가자는 제가 직접 쓰고 에이전트는 루프만 돌리게 하는 게 맞을 것 같은데, 그러면 스킬 호출 한 번이라는 편리함이 반쯤 사라집니다. 이건 아직 어느 쪽이 맞는지 모르겠습니다.
앞으로 길러야 할 근육
한동안 저는 AI 가 코드를 대신 쓰면 개발자는 코드를 치는 사람에서 코드를 읽고 판단하는 사람이 된다고 생각했습니다. 생성은 AI 가 하고 검증과 판단은 제가 하는 그림이었고, 그게 마음이 편했습니다. 마지막 판단은 어쨌든 제 손에 남으니까요.
AlphaEvolve 는 그 편한 그림을 한 칸 더 밀어냅니다. 여기서는 검증도 사람이 눈으로 안 하고 평가자 스크립트가 채점합니다. 만드는 것도 기계, 채점도 기계면 사람은 어디 있나 싶은데, 남는 건 무엇을 최대화할지, 무엇이 좋은 건지를 정하는 일인 것 같습니다. 코드 본문은 아래로 자동화되고 목표를 세우는 일은 위에 남습니다.
그래서 위기감보다는 준비할 게 달라졌다는 느낌이 더 컸습니다. 제가 길러야 할 건 빠른 코드를 손으로 짜는 능력이 아니라 이 문제에서 좋다는 게 뭔지를 빠진 데 없이 숫자로 옮기는 능력 같습니다. 이건 AlphaEvolve 가 없어도 지금 연습할 수 있습니다. 성능 튜닝을 하든 쿼리를 만지든 좋아졌다는 걸 뭘로 잴지부터 한 줄로 못 적으면 사실 방향 없이 손만 바쁜 거니까요. 보통은 고치고 나서 빨라졌네 하고 넘어가지, 고치기 전에 뭐가 빨라져야 하는지를 먼저 적지는 않습니다. 순서가 반대인 셈인데 이 순서를 바꾸는 게 생각보다 어색할 것 같습니다.
책임이 어디에 걸리는지도 달라질 것 같습니다. 예전엔 버그 하나가 함수 하나를 망가뜨렸는데, 이제는 채점 기준을 잘못 세운 것 하나가 밤새 그 기준을 향해 진화한 결과 전체를 조용히 망가뜨립니다. 코드는 흠 하나 없이 잘 돌아가는 채로요. 틀린 목표를 향해 나무랄 데 없이 달려간 결과물만큼 다루기 곤란한 게 또 있을까 싶습니다. 평가자를 세우는 건 있으면 좋은 부가 작업이 아니라 개발자가 지는 책임 그 자체에 가까워질 것 같습니다.
팔 할을 걷어낸 그 선은 오히려 다행으로 느껴졌습니다. 제 일 대부분은 여전히 점수로 안 줄어듭니다. 반년 뒤에 후배가 이 코드를 읽고 이해할지, 이 추상화가 다음 요구사항을 받아낼지, 이 설계가 팀의 다른 결정들이랑 어긋나지 않을지. 이런 건 숫자 하나로 안 떨어집니다. 억지로 점수를 만들 수는 있겠지만, 그렇게 만든 점수를 향해 진화한 코드는 아까 그 정렬 루틴처럼 점수만 높고 정작 원한 건 빠져 있을 것 같습니다. 숫자로 못 바꾸는 판단이 남아 있다는 게 저한테는 좀 안심이 됐습니다. 숫자가 되는 쪽에서는 좋은 평가자를 세우고, 숫자가 안 되는 쪽은 사람이 계속 붙잡고 있는 식으로 제 일이 나뉠 것 같습니다.
직접 써보면 여기 적은 것 중 절반은 틀렸다고 느낄지도 모르겠습니다. 시드를 던져보고, 평가자를 몇 번 틀려보고, 진화가 엉뚱한 데로 새는 걸 눈으로 봐야 몸으로 알게 되는 게 있을 테니까요. 일단 다음 주 월요일에는 손으로 코드를 짜기 전에 이게 좋아졌다는 걸 뭘로 잴지부터 적어보려고 합니다.
댓글
댓글 쓰기