한 데이터 팀에는 하루 한 번 돌리는 예약 계산이 있고, 끝나기까지 40분이 걸린다. 엔지니어는 그 코드를 자동 최적화 도구에 넘기며 목표를 “최대한 빠르게"로 정했다. 하룻밤이 지나자 도구는 12분 만에 끝나는 버전을 돌려줬고, 테스트도 모두 통과했다. 다음 주 대사 작업에서 몇몇 금액의 소수점 아래 몇 자리가 예전과 다르다는 것이 드러났다. 새 버전이 속도를 위해 정밀도가 낮은 계산 방식으로 바꿨는데, 기존 테스트는 마침 그 자릿수를 확인하지 않았던 것이다.

2026년 7월, Google Cloud는 AlphaEvolve를 기업에 공개했다. Gemini 모델을 바탕으로 한 코드 최적화 도구로, 사용자가 시작 프로그램과 평가 프로그램을 주면 수정 버전을 대량으로 거듭 만들어 평가 프로그램이 점수를 매기게 하고, 점수가 높은 것을 남긴다. 이런 도구는 사람이 떠올리지 못한 해법을 실제로 찾아내기도 한다. 하지만 보는 것은 평가 프로그램이 잴 수 있는 것뿐이다. 그래서 맡기기 전에 팀은 “더 나은"을 실행할 수 있는 조건으로 바꿔 써야 한다. “더 빠르게, 품질은 떨어지지 않게"만으로는 부족하다.

측정된 것만 최적화된다

Google DeepMind는 2025년 AlphaEvolve를 처음 소개하면서, 자동화된 평가 지표로 후보 프로그램을 검증하고 실행하고 점수를 매긴다고 설명했다. 점수가 높은 버전이 남아 다음 회차 생성의 방향에 영향을 준다. 모든 것이 점수에 달려 있으니, 이런 도구는 진전을 분명히 잴 수 있는 분야에 가장 잘 맞는다.

Google Cloud의 설명은 사용 흐름을 네 단계로 정리한다. 시작 프로그램과 문제를 정의하고, 채점 방식을 정하고, 도구가 최적화하게 하고, 결과를 운영 환경에 적용한다. 평가 프로그램은 사용자가 직접 마련하며, 결과가 정해져 있고 재현 가능한 스크립트여야 한다. 컴파일하고, 테스트하고, 점수를 돌려주는 역할이다.

문제는 이 스크립트에 있다. 이 서비스를 보도한 InfoQ는 분명히 경고한다. 진화적 탐색은 평가 프로그램이 재지 않는 것이라면 무엇이든 파고든다. 예를 들어 빠르지만 테스트로는 잡히지 않는 미세한 오류가 있는 코드를 만들어 낸다. 기사는 또 지금까지 공개된 성과 수치가 Google이나 고객 스스로의 발표이고, 독립적인 벤치마크는 아직 없다고 짚었다.

처음 그 팀에 일어난 일이 바로 이것이다. 평가 프로그램은 속도는 쟀지만 정밀도는 재지 않았고, 도구는 정밀도를 내주고 속도를 얻었다.

맡기기 전에 평가 계약을 쓴다

자동 최적화 도구에 넘기는 것은 목표 하나가 아니라 실행할 수 있는 계약이어야 한다. 적어도 다음 다섯 가지에 답해야 한다.

  • 기준: 어떤 버전과, 어떤 환경에서 비교하는가.
  • 점수: “더 나은"을 실행 시간이나 메모리 사용량처럼 어떻게 숫자로 바꾸는가.
  • 어길 수 없는 제약: 점수가 올라도 절대 어겨서는 안 되는 조건. 결과가 예전 버전과 완전히 같아야 한다, 출력 형식을 바꾸면 안 된다, 메모리 상한을 넘으면 안 된다 등. 하나하나를 평가 프로그램이 자동으로 확인하는 테스트로 만든다.
  • 중단 조건: 계산 예산을 얼마나, 시간을 얼마나 쓰거나, 몇 번 연속으로 개선이 없으면 멈추는가.
  • 승인할 사람: 변경 내용과 확인 결과를 보고 쓸지 말지 정하는, 이름이 정해진 담당자.

다섯 가지 중 가장 빠뜨리기 쉬운 것은 어길 수 없는 제약이다. 사람이 검토할 때는 “이 숫자는 바뀌면 안 된다"는 생각이 자연스럽게 떠오른다. 하지만 평가 프로그램에 쓰여 있지 않은 조건은 도구에게는 존재하지 않는 것과 같다.

광고

이 목표가 맞는지 가려내기

계약을 쓰는 과정 자체가 판단이 된다. 다음 순서로 물어보면 된다.

  • 결과를 객관적으로 채점할 수 있고, 제약도 모두 자동으로 확인할 수 있다: 시작해도 된다. 다만 변경 범위와 예산을 제한하고, 결과는 사람이 검토하며, 자동으로 배포하지 않는다.
  • 채점은 할 수 있지만, 쓸 수 있는지는 아직 경험으로 판단한다: 아직 시작하지 않는다. 자주 나오는 반려 사유 하나를 테스트로 만들어 평가 프로그램에 더하고, 자동화하지 못하는 판단이 얼마나 남는지 본다.
  • 좋고 나쁨이 사람의 안목에 달렸거나, 틀렸을 때의 대가를 미리 막을 수 없다: 자동 탐색에 맞지 않는다. AI가 선택지를 정리하는 일은 도울 수 있지만, 결정과 책임은 사람에게 남는다.

채점을 통과해도 요구 사항이 완전하다는 뜻은 아니다

평가 프로그램을 아무리 꼼꼼히 만들어도, 그것을 통과했다는 것은 후보가 적어 둔 조건을 만족한다는 뜻일 뿐, 요구사항 자체가 빠짐없다는 뜻은 아니다. 실행할 때마다 시작 버전, 환경, 점수, 제약 확인 결과, 멈춘 이유를 남겨, 승인할 사람이 전체 증거를 볼 수 있게 한다. 필요하면 보안, 운영, 제품 관점의 확인도 더한다.

또 평가 프로그램을 쓰는 데도 시간이 든다. 몇 번밖에 돌리지 않고 느려도 상관없는 코드라면 그 수고는 수지가 맞지 않는다. 투자할 가치가 있는 것은 매일 실행되어 비용이나 속도 차이가 계속 쌓이는 계산이다.

다음 단계로, 경계가 분명하고 팀이 오래전부터 빠르게 하고 싶어 했던 계산 하나를 골라 다섯 항목을 적어 보자. 적지 못한 항목이 있다면 그것부터 채운다. AI에게 버전을 더 만들게 하는 일은 서두를 필요가 없다. 후보가 돌아온 뒤 누가 그것을 이해하고 유지보수할지는 AI가 내놓은 코드 변경의 첫 버전은 가격 확인이고, 진짜 청구서는 검토와 유지보수다를 참고하자. 탐색 도중 어디서 멈춰 증거를 볼지는 이 issue를 coding agent에 맡길 수 있는지는 첫 번째 diff를 적을 수 있느냐에 달렸다를 참고하면 된다.

AI 정리 카드

자동 최적화 도구(AlphaEvolve처럼 코드 버전을 거듭 만들고 점수로 고르는 도구)로 코드 일부를 개선하고 싶다. 그 전에 이 목표가 맞는지 판단하고 싶다.
판단 방법은 이 글에서 가져왔다: https://boosterminiclass.com/ko/posts/ai-code-optimization-needs-evaluator-contract/
글의 관점은 이렇다. 이런 도구는 평가 프로그램이 재는 것만 최적화하고, 적혀 있지 않은 제약은 희생될 수 있다. 맡기기 전에 평가 계약을 쓴다. 기준, 점수, 어길 수 없는 제약, 중단 조건, 승인할 사람이다.

먼저 나에게 질문 3개를 해 달라:
1. 최적화하고 싶은 코드는 무엇이고, 지금 성능과 비교 환경은 어떤가;
2. "더 나은"을 어떻게 숫자로 바꾸고, 점수가 올라도 어겨서는 안 될 조건은 무엇인가;
3. 그 조건들에 지금 자동 테스트가 있는가, 새 버전을 채택할지는 누가 정하는가.

내 답을 바탕으로 다음을 출력해 달라:
- 평가 계약 초안: 기준, 점수, 어길 수 없는 제약(각각 자동 테스트가 있는지 표시), 중단 조건, 승인할 사람. 빠진 것은 "확인 필요"로 적을 것;
- 평가 프로그램이 놓치기 쉬워 도구가 파고들 수 있는 부분;
- 한 줄 판단: 시작 / 평가 프로그램 먼저 보강 / 자동 탐색에 맞지 않음, 그리고 가장 중요한 이유;
- 오늘 할 수 있고 배포하지 않는 다음 단계 하나.
코드나 설정은 하나도 바꾸지 말 것. 점수가 높은 버전은 이름이 정해진 담당자가 차이와 확인 결과를 본 뒤에야 배포 흐름에 넣을 것.
광고

Share

이 미니 클래스 공유

이 글이 업무 병목을 푸는 데 도움이 되었다면, AI를 어떻게 쓸지 고민하는 사람에게도 공유해 주세요.

참고 자료