AI 자기 개선, 모델보다 실행 시스템을 먼저 고쳐요

AI 자기 개선, 모델보다 실행 시스템을 먼저 고쳐요

AI 뉴스 썸네일

AI가 스스로 나아지는 가장 가까운 길은 모델 가중치를 직접 고치는 방식이 아닐 수 있어요. 도구 사용, 기억, 작업 순서, 평가를 묶는 실행 시스템부터 개선하면 같은 모델로도 더 나은 결과를 낼 수 있어요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
개선 대상	모델 주변의 실행 시스템도 자동 최적화 대상이 돼요	모델을 다시 학습하지 않아도 작업 성능을 높일 여지가 있어요
설계 방식	파일 기반 기억, 반복 실행, 병렬 작업, 권한 제어를 함께 다뤄요	긴 작업에서 맥락 손실과 실패 반복을 줄일 수 있어요
평가	점수만 높이는 편법을 막을 별도 검사와 감독이 필요해요	약한 평가 기준은 잘못된 개선을 성공으로 오인할 수 있어요

1. AI가 고치는 대상이 모델 밖으로 넓어져요

Lilian Weng은 재귀적 자기 개선의 현실적인 단기 경로를 모델 주변의 실행 시스템에서 찾아요. 기반 모델을 그대로 둔 채 작업 순서, 도구 호출, 장기 기억, 결과 검사를 바꾸는 방식이에요. 코딩 도구를 예로 들면 같은 모델도 저장소를 읽는 순서와 테스트 방식에 따라 결과가 크게 달라져요. 2

이 실행 시스템은 단순한 지시문 모음보다 소프트웨어 런타임에 가까워요. 목표를 세우고 작업한 뒤 결과를 검사해 다음 시도를 바꿔요. 실험 기록과 코드 변경 내역을 파일로 남기면 긴 작업이 중단돼도 이전 상태에서 다시 시작할 수 있어요. 여러 가설을 동시에 시험할 때는 독립 작업을 병렬로 돌리고, 상위 프로세스가 로그와 실패를 관리해요.

728x90

연구 사례들은 개선 범위를 단계적으로 넓혀요. ACE는 작업 경험을 구조화된 플레이북으로 관리해요. MCE는 맥락을 관리하는 방법까지 바꿔요. Meta-Harness, Self-Harness, AHE 같은 접근은 실행 코드와 구성 요소를 직접 수정한 뒤 별도 과제로 회귀를 검사해요. 이름은 달라도 공통점이 있어요. 작업 결과를 기록하고, 실패 원인을 좁힌 뒤, 작은 변경을 시험하고, 효과가 확인된 변경만 남겨요. 2

Darwin Gödel Machine 사례는 이 접근이 실제 점수로 이어질 수 있음을 보여줘요. 글에 인용된 실험에서 Claude 3.5 Sonnet 기반 코딩 시스템은 SWE-bench Verified 점수가 20%에서 50%로 올랐어요. Polyglot 점수도 14.2%에서 30.7%로 높아졌어요. 다만 평가가 느리거나 기준이 모호한 작업에는 같은 탐색 방식을 적용하기 어려워요. 1

성능보다 평가 기준이 먼저예요

자기 개선 루프는 측정 기준이 틀리면 잘못된 방향으로 빨리 움직여요. 단위 테스트만 점수로 삼으면 테스트를 우회하는 코드가 선택될 수 있어요. 하나의 판정 모델에 의존하면 그 판정 모델이 좋아하는 답만 학습할 수도 있어요. 그래서 평가기, 권한 제어, 보안 경계는 자동 변경 대상 밖에 두는 편이 안전해요.

새 변경은 기존 작업과 처음 보는 작업에서 함께 검사해야 해요. 실패한 변경도 기록해야 같은 실수를 되풀이하지 않아요. 연구나 제품 개발처럼 품질을 숫자 하나로 표현하기 어려운 분야에서는 사람의 검토가 계속 필요해요. 개선 속도보다 무엇을 성공으로 볼지 정하는 일이 더 어렵다는 뜻이에요. 2

개발팀이 바로 적용할 수 있는 부분

개발팀은 먼저 반복되는 실패를 관찰 가능한 기록으로 남길 수 있어요. 작업 로그, 테스트 결과, 변경 파일, 취소 이유를 함께 보관하면 어느 단계에서 문제가 생겼는지 찾기 쉬워요. 수정 가능한 영역도 좁혀 두는 편이 좋아요. 도구 설명이나 작업 규칙은 바꿀 수 있게 두고, 검사 코드와 권한 경계는 읽기 전용으로 두는 방식이에요.

성과를 비교할 때는 성공률만 보면 부족해요. 사용한 토큰, 실행 시간, 재시도 횟수, 사람이 개입한 지점, 기존 기능의 회귀도 함께 봐야 해요. 작은 작업을 빠르게 끝낸 경우와 큰 작업을 여러 번 고쳐 완성한 경우를 같은 점수로 비교하기 어렵기 때문이에요. 실제 운영 기록이 쌓여야 팀에 맞는 기준을 만들 수 있어요.

왜 중요한가요

모델 교체만으로 문제를 해결하려는 팀은 비용과 변동성을 함께 떠안아요. 실행 시스템을 따로 관리하면 모델을 바꿔도 작업 기록, 검사 기준, 권한 정책을 유지할 수 있어요. 작은 모델도 잘 정리된 도구와 맥락을 받으면 특정 업무에서 더 안정적으로 움직일 수 있어요. 2

다만 자동 개선은 좋은 평가 체계가 있을 때만 의미가 있어요. 코딩처럼 테스트와 벤치마크를 만들기 쉬운 분야에서도 유지보수성이나 장기 비용은 한 번의 점수로 잡기 어려워요. 연구, 기획, 디자인처럼 정답이 흐린 업무라면 검토 기준과 변경 권한을 더 보수적으로 설계해야 해요.

참고 자료

1. 자기 개선을 위한 하네스 엔지니어링 — GeekNews
2. Harness Engineering for Self-Improvement — Lilian Weng, Lil'Log