「만들었다」와 「쓸모가 있다」는 별개의 문제

AMA-teras는 부족한 기능을 스스로 코드를 생성하여 도입하는 데스크톱 AI 에이전트입니다 (GitHub). 「에이전트가 자신의 도구를 작성한다」는 것 자체는 솔직히 말해 이제 드문 일이 아닙니다. 프롬프트를 잘 구성하면 어떤 LLM이라도 그럴듯한 플러그인 코드를 만들어냅니다.

문제는 그 이후입니다. 생성된 도구가 제대로 작동하는가. 망가져 있지는 않은가. 망가졌는데도 「완료했습니다」라고 보고하지는 않는가.

이 기사는 자기 진화(Self-evolution)를 「데모에서 한 번 작동하는 수준」에서 「일상적으로 사용할 수 있는 수준」으로 끌어올리기 위해 수행한 기록입니다.

한 일 1: 검증을 「진짜」로 만들기

초기 구현에서는 생성된 코드의 검증이 typecheck뿐이었습니다. 타입이 통과되면 바로 도입했습니다. 그 결과, 타입은 올바른데 실행하면 망가지는 도구가 흔하게 발생했습니다.

현재의 게이트(Gate)는 4단계입니다.

• inspect — 위험한 API(child_process, 네트워크) 사용을 탐지. 사용 중이라면 승인 다이얼로그로 명시적 경고
• typecheck — 플러그인 단독이 아닌 리포지토리(Repository) 전체에서 타입 검사
• test — 생성하는 것은 도구 본체뿐만 아니라 유닛 테스트(Unit Test)도 세트로 구성. 해당 테스트를 실제로 실행
• smoke — 헤드리스(Headless)로 기동한 실제 기기에서, 생성된 도구를 정말로 1회 실행

중요한 것은 4번입니다. 모크(Mock)를 통과한 코드가 아니라, 실제 런타임(Runtime)에 실제 입력을 넣어 실제 출력이 반환되는지를 확인하는 것입니다. 여기서 실패하는 도구가 실제로 일정 수 존재합니다. 타입도 테스트도 통과하지만 실행만 실패하는 경우—이를 도입 전에 잡아내는 것이 스모크(Smoke) 테스트의 역할입니다.

한 일 2: 격리된 장소에서 만들게 하기

생성 및 검증은 가동 중인 앱(A)에서 수행하지 않습니다. git worktree를 사용하여 만든 격리 환경(B)에서 수행합니다.

• 생성 에이전트가 폭주하더라도 A는 무사함
• 검증도 B 안에서 완결 (A의 프로세스에 영향을 주지 않음)
• 합격한 것만이 인간의 승인을 거쳐 A로 머지(Merge)됨

「에이전트에게 자신을 다시 쓰게 한다」고 하면 위험하게 느껴지지만, 실체는 풀 리퀘스트(Pull Request)를 보내는 동료에 가까운 구조입니다. 쓰는 것은 자유지만, main에 들어가는 것은 심사 후입니다.

한 일 3: 성공 보고를 의심하기

가장 효과적이었던 것은 이것일지도 모릅니다. 에이전트는 「잘 되었습니다」라고 말하기 쉽습니다. 학습의 특성상 성공 보고는 벌을 받기 어렵기 때문입니다.

그래서 보고가 아닌 1차 정보만을 신뢰하는 구조로 만들었습니다.

• 도구 도입의 성패는 게이트의 실행 로그를 기준으로 함
• 「공개했다」고 주장하는 기사는, 공개 URL에 실제로 HTTP 요청을 보내 확인 (published: true로 push했더라도 상대방이 동기화하지 않았다면 「미공개」로 취급)
• 승격 후의 건전성 체크에 실패하면, 직전의 git 태그로 자동 리버트(Revert)

실제로 「본문이 비어 있는 기사를 published: true로 3건 공개했던」 사고를 이 메커니즘으로 탐지하여, 생성 측에 최소 본문 길이 가드(Guard)를 추가했습니다. 에이전트의 자기 신고는 감사(Audit) 대상이지, 신뢰의 근거가 아닙니다.

한 일 4: 실패를 지우지 않기

검증에서 떨어진 도구의 브랜치는 원칙적으로 지우지 않습니다. 떨어진 이유(어떤 게이트에서, 왜)를 작업 이력(Job history)에 남겨 에이전트 스스로가 다음 생성 시에 참조하게 합니다. 「같은 실수를 반복하지 않는다」는 실패의 기록이 남아 있어야 비로소 성립합니다.

요약: 자기 진화는 생성의 문제가 아니라 운용의 문제

생성 AI에게 코드를 쓰게 하는 것은 쉬워졌습니다. 어려운 것은, 작성된 것을 신뢰해도 되는지를 기계적으로 계속 판정하는 메커니즘입니다.

• 검증은 실제 실행까지 (typecheck만으로 안심하지 말 것)
• 만드는 장소를 격리할 것 (worktree)
• 성공 보고를 의심할 것 (1차 정보로 확인)
• 실패를 기록할 것 (다음 생성의 재료로 활용)

AMA-teras는 AGPL로 공개되어 있습니다. 같은 문제를 겪고 계신 분들에게 참고가 된다면 좋겠고, 「우리 회사는 이렇게 해결했다」는 이야기가 있다면 꼭 들려주세요.

Discussion