내 업무에 알고리즘 진화를 들일 자리를 찾아봤다

원래는 그냥 스크롤을 내리려던 참이었다.

주말에 밀린 뉴스레터를 훑다가 "AlphaEvolve, 이제 모든 구글 클라우드 고객에게"라는 줄을 봤다. 7월에 GA로 풀렸다는 소식이었다. 나는 이미 머릿속으로 분류를 끝내고 있었다. 또 코딩 에이전트겠지. Gemini CLI, Claude Code, Copilot 계열에 하나 더 붙는 이름이겠거니 하고 엄지를 아래로 밀었다.

그런데 그 아래 딸려온 한 문장에서 손가락이 멈췄다. "코드 스니펫을 생성하는 게 아니라, 알고리즘을 반복적으로 평가하고 개선한다." 짧은 문장인데 이상하게 걸렸다. 코드를 생성하지 않는 코딩 에이전트라니. 그게 무슨 말인가 싶어서 원래 하려던 걸 멈추고 구글 딥마인드 공개 문서와 작년 논문을 열었다.

그날 밤 나는 이게 뭔지 얼추 이해했다. 이해하는 데는 성공했다. 그런데 이해가 끝나기 무섭게 머리가 멋대로 다음 계산을 시작했다. 그럼 이걸 내 일에 들이면 어디에 꽂히지. 내가 매일 만지는 코드 중에 이 진화 루프한테 던질 만한 게 있긴 한가. 그 질문에 답해보려다가, 생각보다 훨씬 곤란한 자리로 끌려 들어갔다.

미리 밝혀둔다. 나는 AlphaEvolve를 직접 돌려본 적이 없다. 그러니 이 글은 써본 후기가 아니다. 공개된 자료만 읽고, 이걸 내 개발 업무에 들인다면 어디에 쓰고 어디선 무용한지를 머릿속으로 설계해본 사고 실험에 가깝다. 실전 경험담이 아니라 아직 안 써본 사람의 가정과 계산이라고 생각하고 읽어주면 좋겠다.

코딩 도구가 아니라는 게 진짜 핵심이었다

먼저 이름 때문에 생기는 오해부터 걷어내야 한다. AlphaEvolve는 딥마인드가 붙인 이름이고, 이 회사의 Alpha 계보를 안다면 감이 온다. 바둑의 AlphaGo, 단백질 구조의 AlphaFold. 전부 "인간이 손으로 다 뒤져볼 수 없는 거대한 공간에서 좋은 수를 찾아내는" 계열이다. AlphaEvolve도 정확히 그 자리에 있다. 다만 이번에 뒤지는 공간이 바둑판도 단백질도 아닌 코드, 정확히는 알고리즘이라는 점이 다르다.

내가 처음에 착각한 지점이 여기였다. 코드라는 단어가 들어가니까 자동으로 "코드를 대신 써주는 도구"로 읽어버린 거다. 우리가 매일 쓰는 코딩 어시스턴트들이 하는 일이 그거니까. 내가 "이 함수 리팩터링해줘"라고 하면 그럴듯한 코드를 뱉는다. 그런데 AlphaEvolve가 푸는 문제는 성격이 완전히 다르다.

이걸 구분하는 가장 깔끔한 기준을 딥마인드 문서에서 봤다. "해가 알고리즘으로 기술될 수 있고, 그 결과를 자동으로 검증할 수 있는 문제." 이 두 조건이 동시에 걸리는 문제. 그러니까 답이 맞았는지 사람이 눈으로 봐야 아는 게 아니라, 스크립트를 돌려서 점수로 딱 나오는 문제여야 한다.

예를 들어보자. "로그인 화면 만들어줘"는 AlphaEvolve의 문제가 아니다. 잘 만들었는지는 사람이 봐야 하고, 정답이 하나로 떨어지지도 않는다. 반대로 "4×4 행렬 두 개를 곱하는데, 곱셈 연산 횟수를 최소로 줄여라"는 정확히 AlphaEvolve의 문제다. 후보가 나오면 실제로 곱셈이 몇 번 들어가는지 세면 되고, 결과가 원래 곱셈과 같은지 검증하면 된다. 점수가 숫자로 떨어진다.

이 차이가 왜 중요한지는 조금 있다 이야기하겠지만, 일단 여기서 한 번 멈추고 넘어가자. AlphaEvolve는 "코드를 써주는" 도구가 아니라 "정답을 아무도 모르는데 좋고 나쁨은 기계가 채점할 수 있는 문제에서, 더 좋은 답을 찾아 헤매는" 에이전트다. 실제로 딥마인드가 자랑하는 성과들을 보면 이 성격이 확 드러난다.

구글 발표에 따르면 AlphaEvolve는 4×4 복소 행렬을 곱하는 데 필요한 스칼라 곱셈을 48번으로 줄이는 절차를 찾아냈다. 이게 왜 뉴스가 됐냐면, 1969년에 나온 슈트라센 알고리즘이 이 설정에서 57년 가까이 최고 기록이었기 때문이다. 반세기를 버틴 기록을 갱신한 거다. 수학자들이 못 풀었다는 게 아니라, 손으로 뒤지기엔 경우의 수가 너무 많은 공간이었다는 뜻에 가깝다. 그 외에도 50개 넘는 미해결 수학 문제 중 상당수에서 기존 최고 수준의 해를 다시 찾아냈고, 일부에서는 그걸 넘어섰다고 발표했다. 11차원 키싱 넘버 문제에서 새로운 하한을 세웠다는 것도 그중 하나다.

여기까지 읽고 "그래서 그게 나랑 무슨 상관인데"라고 생각했다면, 내가 딱 그랬다. 수학 정리 이야기는 멋있긴 한데 멀게 느껴졌다. 그런데 성과 목록을 더 내려가다 보니 갑자기 확 가까워지는 대목이 나왔다.

이건 이미 구글 내부를 돌아가고 있었다

딥마인드가 밝힌 실사용 사례 중에 나 같은 엔지니어의 등을 서늘하게 만드는 게 몇 개 있다.

하나는 데이터센터 스케줄링이다. 구글의 클러스터 관리 시스템 Borg가 작업을 어떻게 배치할지 결정하는 휴리스틱을, AlphaEvolve가 찾아낸 새 버전으로 바꿨더니 전 세계 컴퓨트 자원의 0.7%를 회수했다고 한다. 0.7%가 작아 보이지만, 구글 규모의 0.7%가 어느 정도인지 상상해보면 이야기가 달라진다. 게다가 이건 실험이 아니라 1년 넘게 프로덕션에서 돌고 있는 값이라고 발표했다.

또 하나는 AI 학습 커널 최적화다. Gemini 자체를 학습시키는 데 쓰이는 중요한 커널 하나를 23% 빠르게 만들었고, 그 결과 전체 학습 시간을 1% 줄였다고 한다. 여기서 좀 묘한 재귀가 생긴다. Gemini가 AlphaEvolve의 엔진인데, AlphaEvolve가 Gemini를 더 빨리 학습시키는 코드를 찾아낸 거다. 모델이 자기를 만드는 파이프라인을 스스로 손보는 그림. GPU 쪽에서는 FlashAttention 구현에서 최대 32.5%까지 속도를 끌어올렸다는 수치도 나왔다.

이 사례들을 보면서 내가 멈칫한 이유는 성과의 크기 때문이 아니었다. 이게 다 원래 사람 엔지니어가 하던 일이라는 점 때문이었다. Borg 스케줄러 휴리스틱을 다듬는 일, GPU 커널을 손으로 튜닝하는 일, 컴파일러가 뱉는 코드를 뜯어고쳐 몇 퍼센트 짜내는 일. 이건 시니어 중에서도 특정 영역을 깊게 파온 사람들이 하던, 소위 "장인의 영역"이었다. 성능 엔지니어링이라고 부르는 그 일들.

그 일을 이제 진화 루프가 밤새 돌면서 대신 뒤진다. 그것도 사람보다 넓게, 사람이 지치지 않는 방식으로.

한 가지 짚어둘 건, 이 성과들이 하루아침에 나온 게 아니라는 점이다. AlphaEvolve가 처음 공개된 건 2025년 5월이고, Borg 사례는 그 시점에 이미 1년 넘게 프로덕션에서 돌던 값이었다. 그러니까 우리가 뉴스로 접하기 훨씬 전부터 구글 내부에서는 이 방식이 조용히 자원을 아끼고 있었다는 뜻이다. 그리고 올해 7월, 이걸 자기들만 쓰던 단계에서 클라우드 고객 누구나 쓸 수 있는 단계로 열었다. 연구 데모에서 상용 제품으로 넘어오는 이 1년 남짓한 간격이, 나한테는 성과 수치 자체보다 더 신호처럼 읽혔다. 검증이 끝났다고 판단했으니 파는 거니까.

루프를 손으로 따라가 봤다

이게 어떻게 돌아가는지 이해하지 못하면 그냥 "AI가 알아서 잘한대"라는 신비주의로 끝나버린다. 나는 그게 싫어서 논문의 그림을 종이에 옮겨 그리면서 한 바퀴를 손으로 따라가 봤다. 생각보다 구조는 담백했다. 네 덩어리가 원을 그리며 돌 뿐이다.

시작점은 프로그램 데이터베이스다. 지금까지 시도해본 프로그램들이 각자 받은 점수와 함께 저장돼 있는 창고라고 보면 된다. 처음엔 사람이 넣어준 시드 프로그램 하나만 덩그러니 있다.

첫 번째 덩어리는 프롬프트 샘플러다. 이 창고에서 과거 시도들을 골라 와서, 지금 LLM에게 던질 프롬프트를 조립한다. "여태 이런 것들을 해봤고 점수는 이랬어. 이걸 참고해서 더 나은 버전을 만들어봐" 같은 맥락을 만들어주는 역할이다. 어떤 부모를 골라 오느냐가 다음 세대의 방향을 정하니까, 사실상 진화에서 짝짓기 상대를 고르는 단계에 가깝다.

두 번째 덩어리가 LLM 앙상블이다. 여기가 Gemini가 들어가는 자리다. 재밌는 건 한 모델만 쓰지 않는다는 점이다. 구글 설명으로는 Gemini Flash가 아이디어의 폭을 넓히는 역할을, Gemini Pro가 깊이 있는 제안을 하는 역할을 맡는다. 빠르고 다양하게 던지는 쪽과 신중하게 파고드는 쪽을 섞은 거다. 이 앙상블이 "기존 프로그램을 이렇게 고치면 어떨까" 하는 후보 프로그램들을 뱉어낸다.

세 번째 덩어리가 평가자다. 나는 이 부분이 이 시스템의 진짜 심장이라고 생각한다. 앙상블이 내놓은 후보 프로그램을 실제로 실행하고, 사용자가 정의한 채점 기준으로 점수를 매긴다. 여기엔 LLM의 그럴듯함이 끼어들 자리가 없다. 코드를 돌려서 나온 숫자가 전부다. 빠르면 빠른 대로, 정확하면 정확한 대로, 결정론적으로 채점된다.

그리고 그 점수가 다시 프로그램 데이터베이스로 돌아가 저장된다. 점수가 좋았던 프로그램은 다음 세대에서 부모로 뽑힐 확률이 올라간다. 나쁜 건 도태된다. 이 네 덩어리가 계속 돈다. 샘플링, 제안, 채점, 저장. 세대를 거듭할수록 창고에 쌓인 프로그램들의 평균 점수가 올라간다.

말로 풀면 유전 알고리즘 교과서에 나오는 그림과 거의 똑같다. 선택, 변이, 평가, 도태. 다른 점은 딱 하나다. 변이를 만드는 자리에 무작위 비트 플립 대신 Gemini가 앉아 있다는 것. 이게 생각보다 큰 차이다. 전통적인 진화 알고리즘의 변이는 멍청하다. 그냥 여기저기 무작위로 건드려보고 운이 좋으면 좋아지는 식이다. 그런데 여기서는 코드를 이해하는 LLM이 "이 부분을 이렇게 바꾸면 더 나을 것 같은데"라는, 나름 근거 있는 변이를 만든다. 무식하게 넓은 탐색과 똑똑한 방향 감각이 붙은 셈이다.

이 차이가 얼마나 큰지는 숫자 감각으로 따져보면 실감이 난다. 무작위 변이는 좋은 방향으로 갈 확률이 극단적으로 낮다. 코드 한 줄을 아무 데나 뒤집어서 성능이 올라갈 가능성은 사실상 로또다. 그래서 전통적인 진화 탐색은 세대를 어마어마하게 돌려야 겨우 조금 나아진다. 반면 LLM은 "여기는 이중 루프인데 캐시 지역성이 나쁘니까 순서를 바꿔보자" 같은, 사람이 할 법한 추론을 담아 후보를 만든다. 물론 그 추론이 다 맞지는 않는다. 틀린 제안도 무더기로 나온다. 그런데 그 틀린 것들은 평가자가 걸러준다. 그러니까 이 시스템의 묘미는 LLM이 완벽해서가 아니라, LLM의 그럴듯한 추론과 평가자의 냉정한 채점이 서로의 약점을 메운다는 데 있다. 아이디어는 넓게 풀어놓고, 진위는 실행으로 판정한다. 나는 이 조합이 이 물건의 진짜 발명 포인트라고 생각한다.

입력이 딱 두 개라는 게 오래 걸렸다

루프를 다 따라가고 나서 제일 오래 곱씹은 건 정작 다른 부분이었다. 사용자가 이 시스템에 넣어주는 게 딱 두 개라는 점.

하나는 시드 프로그램이다. 최적화하고 싶은 알고리즘의 초기 버전, 컴파일이 되는 최소한의 코드. 완벽할 필요는 없다. 오히려 대충 돌아가기만 하는 출발점이면 된다. 진화가 이걸 부모 삼아 개선해나갈 거니까.

다른 하나가 평가자다. 후보가 얼마나 좋은지를 하나의 스칼라 값으로 돌려주는 채점 스크립트. 최대화하고 싶은 지표 하나를 정의하는 함수다.

처음엔 "입력이 두 개뿐이라니 간단하네"라고 생각했다. 그런데 며칠 지나면서 이 두 번째 입력이 사실 이 시스템에서 제일 어려운 부분이라는 걸 깨달았다. 시드 프로그램은 대충 짜도 된다고 했다. 하지만 평가자는 대충 짜면 안 된다. 왜냐하면 진화 루프는 오로지 평가자가 주는 점수만 보고 방향을 정하기 때문이다.

이게 무슨 뜻이냐면, 내가 채점 함수를 잘못 정의하면 AlphaEvolve는 내가 진짜로 원한 걸 최적화하는 게 아니라, 내가 실수로 적어놓은 지표를 미친 듯이 최적화한다. 속도만 점수에 넣고 정확도를 안 넣었다면, 답이 틀렸는데 엄청 빠른 코드를 자랑스럽게 들고 온다. 진화는 내 의도를 읽지 않는다. 내가 쓴 숫자를 읽는다.

이게 얼마나 얄궂은지 상상으로 한 장면을 그려보자. 내가 어떤 정렬 루틴을 최적화하고 싶어서 "처리 시간이 짧을수록 높은 점수"라고만 채점 기준을 짰다고 하자. 진화 루프는 며칠 밤을 돌아 놀랄 만큼 빠른 코드를 들고 온다. 신나서 열어보니, 입력이 특정 크기일 때만 맞고 나머지는 대충 뭉개는 코드다. 왜냐면 나는 "정확해야 한다"를 점수에 안 넣었으니까. 시스템 입장에선 완벽하게 임무를 수행한 거다. 내가 시킨 대로 시간만 줄였다. 이런 걸 두고 흔히 보상을 잘못 설계하면 시스템이 그 허점을 파고든다고 하는데, AlphaEvolve는 그 교과서적 함정을 아주 성실하게 재현할 수 있는 물건이다. 그래서 실제로 이걸 쓰는 팀에서 제일 신경 써야 하는 건 근사한 시드 코드가 아니라, 내가 원하는 좋음을 빠뜨린 구석 없이 숫자로 옮겼는가 하는 점일 거다.

여기서 개발자의 일이 어디로 옮겨가는지가 처음으로 선명해졌다. 코드를 짜는 일에서, 무엇이 좋은 코드인지를 숫자로 정의하는 일로 무게 중심이 넘어간다. 알고리즘의 본문을 쓰는 사람에서, 알고리즘이 뭘 향해 진화해야 하는지 그 기준을 설계하는 사람으로. 이건 더 쉬운 일이 아니다. 오히려 훨씬 까다롭다. 그리고 바로 이 지점에서 나는 아까 하려던 계산으로 돌아가게 됐다. 그럼 내 업무 중에 시드 프로그램과 평가자를 이렇게 손에 잡히게 정의할 수 있는 게 진짜 있나.

내 일에 들인다고 상상하면 어디에 꽂히나

여기서부터가 그날 밤 나를 제일 오래 붙든 부분이다. 구글이 든 예시는 물류, 반도체, 유전체, 금융처럼 거대한 도메인이었다. 멋있는데 멀다. 나는 그런 스케일의 문제를 다루지 않는다. 그래서 질문을 내 쪽으로 바짝 당겼다. 내가 최근 몇 달 만진 코드 중에, 이 진화 루프한테 던질 만한 게 하나라도 있나.

제일 먼저 한 건 후보를 찾는 게 아니라 선을 긋는 거였다. AlphaEvolve로 들어가는 관문은 딱 하나다. 평가자를 결정론적 스칼라 지표로 정의할 수 있는가. 후보 코드를 넣으면 사람 손 안 타고 숫자 하나가 떨어지는가. 이 관문을 통과 못 하면 시드 코드가 아무리 근사해도 애초에 대상이 아니다. 나는 이 선을 정직하게 긋는 게 이 도구를 제대로 보는 첫걸음이라고 생각한다.

그 기준으로 내 일상 업무를 훑으니 대부분이 그냥 탈락했다. 기능 하나 새로 붙이는 일, CRUD API 만드는 일, 버그 잡는 일, 화면 그리는 일. 이게 내 시간의 팔 할이다. 그런데 이것들은 정답이 하나의 연속적인 점수로 채점되지 않는다. 버그 수정이 맞았는지는 테스트가 통과하느냐 마느냐의 이진 판정이지, 최대화할 스칼라가 아니다. 화면이 잘 나왔는지는 결국 내가 눈으로 본다. API 설계가 좋은지는 반년 뒤에야 안다. 이런 일에 진화 루프를 붙이는 건 도구를 잘못 든 거다. 이 선을 흐리면 "AI가 다 해준다"는 붕 뜬 기대만 남고, 정작 진짜 쓸 자리를 놓친다.

그렇게 팔 할을 걷어내고 나니, 남은 이 할에서 오히려 후보들이 또렷하게 떠올랐다. 평소엔 "나중에 성능 한번 봐야지" 하고 미뤄두던, 목적이 숫자로 딱 떨어지는 일들이었다.

가장 먼저 떠오른 건 프로파일러에서 늘 상위에 뜨는 핫패스 함수 하나였다. 어떤 직렬화나 거리 계산 루틴 같은 거. 이런 함수는 결과의 정합성이 이미 있는 테스트로 검증되고, 속도는 벤치마크로 밀리초까지 찍힌다. 여기라면 그림이 손에 잡힌다. 시드 프로그램은 지금 돌아가는 그 함수의 현재 구현 그대로 넣으면 된다. 평가자는 "기존 테스트를 전부 통과할 때에 한해 벤치마크 처리 시간의 역수를 점수로 돌려주고, 하나라도 틀리면 0점"으로 짜면 된다. 정확성을 통과 게이트로 걸어두고 속도만 최대화하는 형태다. 이렇게 설계하면 앞에서 본 "빠른데 틀린 코드" 함정을 구조적으로 막을 수 있다. 틀리면 0점이니 진화가 그쪽으로 샐 이유가 없다.

두 번째 후보는 데이터베이스 쪽이었다. 복잡한 리포트 쿼리 하나가 인덱스 조합이나 조인 순서에 따라 성능이 요동칠 때. 옵티마이저가 늘 최선을 뽑아주지도 않고, 사람이 손으로 힌트를 붙여가며 더듬던 그 영역. 여기서 시드는 지금의 쿼리와 인덱스 구성이고, 평가자는 실제 데이터 분포를 흉내 낸 대표 쿼리 세트를 돌렸을 때의 총 실행 시간이나 총 비용을 스칼라로 반환한다. 정답이 하나로 정해져 있지 않고, 좋고 나쁨은 실행해보면 숫자로 나온다. 딱 이 도구의 결이다.

거기서 힘을 받아 몇 개가 더 줄줄이 나왔다. 배치 작업의 스케줄링과 리소스 할당은 처리량이나 마감 위반 건수를 점수로 잡으면 되고, 캐시 교체 정책은 대표 트래픽을 재생했을 때의 적중률을 최대화하면 된다. 빌드나 컴파일 파이프라인의 단계 순서와 병렬화도 전체 소요 시간이라는 명확한 스칼라가 있다. 비용 함수가 분명한 휴리스틱이나 하이퍼파라미터 탐색은 말할 것도 없다. 하나같이 "정답은 아무도 딱 잘라 말 못 하지만, 좋고 나쁨은 돌려보면 숫자로 나오는" 문제들이다.

여기서 한 가지 짚고 갈 게 있다. 이건 내가 문서를 읽고 그린 지도지 구글이 공식으로 정리해준 게 아니다. 내 감으로는, 선형 계획법이나 이차 계획법으로 깔끔하게 풀리는 문제라면 굳이 진화 루프를 밤새 돌릴 이유가 없다. 이미 정확한 답을 증명까지 해서 내놓는 전용 솔버가 있으니까. AlphaEvolve가 빛나는 자리는 그 반대편이다. 탐색 공간이 지저분하게 넓고, 후보들이 기능적으로는 다 맞는데 일부만 성능 기준을 만족하는, 예전 같으면 유전 알고리즘이나 시뮬레이티드 어닐링을 꺼내 들던 그런 자리. 그래서 나는 이걸 "LLM에 메타휴리스틱 탐색을 붙인 에이전트"로 이해하고 있다. 완전히 새로운 원리라기보다, 진화 탐색이라는 오래된 뼈대의 변이 자리에 코드를 읽을 줄 아는 LLM을 앉힌 것에 가깝다.

후보들을 늘어놓고 나서야 진짜 공통점이 보였다. 이 일들의 난이도는 전부 시드가 아니라 평가자 쪽에 몰려 있다는 거다. 핫패스 함수의 현재 구현을 시드로 넣는 건 복사 붙여넣기다. 진짜 머리를 써야 하는 건 "이 함수에서 좋다는 게 정확히 뭔데"를 한 줄의 점수로 압축하는 쪽이다. 속도만인가, 메모리도인가, 최악 지연시간도 봐야 하나, 정확성은 어느 수준까지 게이트로 걸 건가. 캐시 정책이면 적중률만 볼 건지 지연시간과 메모리 압박까지 섞을 건지. 이걸 잘못 잡으면 진화는 내가 실수로 적어둔 지표를 향해 완벽하게 달려가 버린다.

그러니까 이 도구를 쓸 수 있느냐는 결국 모델의 성능 문제가 아니다. 내가 좋은 평가자를 쓸 수 있느냐의 문제다. 좋은 목적함수를 정의하는 능력이 곧 이 도구를 다루는 능력이 된다. 시드는 누구나 넣는다. 평가자를 제대로 세우는 사람이 결과를 가져간다.

스킬로 들어온다는 대목에서 다시 멈췄다

7월 GA 소식에서 내가 이 블로그를 읽는 사람들에게 특히 흥미로울 거라 생각한 대목이 있다. AlphaEvolve가 Gemini Enterprise 에이전트 플랫폼을 통해 풀리면서, 에이전트형 코딩 도구 안에 "스킬" 형태로 붙는다는 부분이다.

이 블로그를 오래 본 사람이라면 스킬이라는 단어가 그냥 지나가지지 않을 거다. 우리는 요즘 하네스를 짜고, 에이전트에 스킬을 물리고, 오케스트레이터로 그것들을 엮는 이야기를 계속 해왔다. 그 판에 AlphaEvolve가 하나의 스킬로 들어온다는 건, 이게 저 멀리 딥마인드 연구소의 신기한 물건이 아니라 내 워크플로우 안에서 호출 가능한 부품이 된다는 뜻이다.

그림을 그려보면 이렇다. 내가 코딩 에이전트에게 어떤 성능 병목을 던진다. 에이전트가 "이건 최적화 탐색이 필요한 문제네" 하고 판단해서 AlphaEvolve 스킬을 호출한다. 시드 코드와 채점 기준을 넘기고, 진화 루프가 백그라운드에서 돌아가는 동안 에이전트는 다른 일을 한다. 결과가 나오면 받아서 다음 단계로 넘어간다. 예전 같으면 성능 엔지니어를 붙여야 했던 구간이, 스킬 호출 한 번으로 바뀌는 그림이다.

솔직히 이 대목에서 등이 좀 서늘했다. 앞에서 본 Borg 스케줄러 이야기가 여기서 겹쳐지면서, "장인의 영역"이라고 안심하고 있던 성능 엔지니어링이 스킬 카탈로그의 한 줄로 접히는 미래가 갑자기 구체적으로 보였기 때문이다. 다만 가격이나 구체적인 운영 조건은 이 글을 쓰는 시점에 공개된 게 없어서 여기까지만 말하겠다. 확인 안 된 걸 지어내는 순간 이 글 전체가 거짓말이 되니까.

그래서 지금부터 길러둬야 할 근육

여기까지 오니 이 블로그에서 내가 줄곧 맴돌던 이야기와 다시 만난다. AI가 코드를 대신 쓰는 시대에 개발자의 무게 중심이 어디로 옮겨가는가. 한동안 나는 그걸 "코드를 타이핑하는 사람에서 코드를 읽고 판단하는 사람으로" 옮겨간다고 정리했었다. 생성은 AI가 하고 검증과 판단은 내가 한다는 그림. 그게 나름 편했다. 최종 판단은 내 몫으로 남으니까.

AlphaEvolve는 그 편안함을 한 칸 더 밀어낸다. 여기선 검증조차 사람이 눈으로 하지 않는다. 평가자 스크립트가 대신 채점한다. 생성도 기계, 채점도 기계. 그럼 사람은 어디 있나. 답은 이 글 내내 한 자리를 가리키고 있었다. 무엇을 최대화할지, 무엇이 좋은 것인지 그 기준을 정하는 자리. 코드 본문은 아래로 자동화되지만, 목적함수를 세우는 일은 위로 남는다.

그래서 내가 이 도구를 보며 느낀 건 위기감보다는 준비할 게 바뀌었다는 감각에 가까웠다. 앞으로 내가 길러야 할 근육은 더 빠른 코드를 손으로 짜는 능력이 아니다. "이 문제에서 좋다는 게 정확히 뭔지"를 빠뜨린 구석 없이 숫자로 옮기는 능력이다. 평가자를 정의하는 근육. 그리고 이건 AlphaEvolve가 손에 없어도 지금 당장 기를 수 있다. 내가 지금 성능 튜닝을 하든 쿼리를 만지든, "이게 좋아졌다"를 무엇으로 잴지부터 한 줄로 못 적으면 사실 방향이 없는 거니까. 그 연습이 그대로 이 도구를 다룰 준비가 된다.

책임의 무게가 어디로 옮겨가는지도 여기서 드러난다. 예전엔 버그 하나가 함수 하나를 망가뜨렸다. 이제는 채점 기준을 잘못 세운 것 하나가, 밤새 그 기준을 향해 완벽하게 진화한 결과물 전체를 조용히 망가뜨린다. 코드는 흠 하나 없이 돌아가는 채로. 틀린 목표를 향해 나무랄 데 없이 달려간 결과물만큼 다루기 곤란한 건 없다. 그러니 평가자를 세우는 일은 이제 있으면 좋은 부가 작업이 아니라 개발자가 지는 책임 그 자체에 가까워진다.

앞에서 내 업무의 팔 할을 걷어냈던 그 경계선도, 나는 오히려 다행으로 읽는다. 내 일의 대부분은 여전히 점수로 압축되지 않는다. 이 코드를 반년 뒤 후배가 읽고 이해할지, 이 추상화가 다음 요구사항을 받아낼지, 이 설계가 팀의 다른 결정들과 어긋나지 않을지. 이런 판단은 스칼라로 안 떨어진다. 자동화가 끝내 삼키지 못하는 자리가 바로 여기, 정량화를 거부하는 판단들의 몫으로 남는다. 정량화가 되는 자리에서 좋은 평가자를 세우는 일과, 정량화가 안 되는 자리를 지키는 일. 앞으로 내 일은 이 두 축 위에 놓일 것 같다.

직접 써보고 다시 쓴다면 여기 적은 것의 절반은 뒤집힐지도 모른다. 시드를 던져보고, 평가자를 몇 번 틀려보고, 진화가 엉뚱한 데로 새는 걸 눈으로 봐야 몸으로 아는 게 생길 테니까. 지금 내가 가진 건 문서를 읽고 그린 지도와, 그 위에 내 업무를 얹어본 사고 실험뿐이다. 그래도 이 실험 하나로 다음 주 월요일에 뭘 연습할지는 분명해졌다. 손이 아니라 목적함수 쪽 근육이다. 그거면 주말 밤 하나 쓴 값은 했다.