늘모자란, 개발분류

이 글의 영어 번역 / English translation

에이전트에게 같은 잘못을 두 번 설명하고 싶지는 않았다. 한 번 고친 일을 다음 작업에서도 기억하고, 자주 쓰는 절차는 스킬로 정리하고, 실패를 겪었으면 다음에는 조금이라도 덜 헤매기를 바랐다. 그런데 이것을 매번 내가 시켜야 한다면 자기개선이라는 말이 좀 민망해진다.

그렇다고 에이전트가 좋다고 생각한 내용을 곧바로 모든 장비에 적용하는 것도 원하지 않았다. 틀린 해석을 기억에 넣으면 다음 작업부터는 그 해석이 전제가 된다. 잘못 만든 스킬이 자동 배포되면 실수도 같이 배포된다. 내가 원한 것은 매번 시키지 않아도 나아지되, 검증 없이 제멋대로 바뀌지는 않는 것이었다.

2026년 5월에 공개 자기개선 스킬의 교훈을 흡수하는 작업부터 시작했다. 7월에는 일상 작업에서 후보를 수확하는 경로를 다시 열었고, 8월에는 고정 과제로 전후를 비교하는 루프를 만들었다. 9월에는 Hermes 에이전트로 이관하면서 빠진 기능을 찾았고, 10월에는 평가와 배포 사이에 남아 있던 관문을 하나씩 고쳤다. 이 글은 그 약 다섯 달의 기록이다. 자료의 마지막 확인 범위는 10월 15일 아침까지이며, 그 뒤의 운영 상태를 뜻하지 않는다.

먼저 범위를 분명히 해 두자. 여기서 바꾸는 것은 모델의 가중치가 아니라 스킬, 작업 지침, 일부 관리 도구다. 모델 자체를 강화학습으로 훈련한 실험은 아니다. 또한 이 글은 보존된 위키 노트, 작업 로그, 그 안에 연결된 평가·승인·배포 영수증을 읽고 쓴 사례 기록이다. 글을 쓰면서 운영 작업을 다시 실행하지는 않았다. 자료가 확인한 사실과 내가 거기서 얻은 해석을 구분해서 적으려 한다.

처음에는 기억 저장소를 하나 더 만들지 않았다

5월에 본 공개 self-improving 스킬에는 가져올 만한 생각이 있었다. 사용자 교정에서 배우고, 반복 실패의 해결책을 남기고, 오래 쓰는 규칙과 일시적인 기록을 구분하는 것이다. 다만 그것을 그대로 설치하면 기존 기억과 위키 옆에 또 다른 기억 체계가 생긴다. 어느 쪽을 믿어야 하는가부터 다시 정해야 했다.

그래서 스킬 전체 대신 교훈만 흡수했다. 명시적인 교정이나 안정적인 사용자 요구, 해결 방법이 분명한 반복 실패를 기존 기억·위키·스킬에 넣는 방식이었다. 사용자가 아무 말도 하지 않았다는 이유로 성공했다고 배우거나, 한 번의 애매한 사건을 전역 규칙으로 승격하지 않는다는 경계도 두었다. 당시 자료는 이 선택과 스킬 배포·가시성 확인을 기록한다. 실제 미래 작업이 얼마나 좋아졌는지를 측정한 기록은 아니다.

이 구분이 이후에도 계속 중요했다. 잘 정리된 교훈이 있다는 것과 다음 작업이 더 잘된다는 것은 다른 이야기다.

켜진 잡이 학습을 하고 있다는 보장은 없었다

7월 말에는 자주 쓰는 절차가 실제로 스킬 후보가 되고 있는지 확인했다. 결과가 꽤 허탈했다. 이름은 ‘스킬 후보 수집’이고 잡도 켜져 있었지만, 실제 구현은 필수 파일과 위키 상태를 검사하는 건강 검사였다. 세션의 반복 패턴을 읽거나 후보를 만드는 일은 하지 않았다. 후보를 판단하던 주간 작업은 꺼져 있었다.

업스트림 변경을 받아들이는 경로는 살아 있었다. 하지만 외부 스킬 업데이트를 흡수하는 것과 내 일상 작업에서 새 교훈을 뽑는 것은 같은 기능이 아니다. 기존 후보 문서가 남아 있는 것도 살아 있는 수집 경로의 증거는 아니었다.

복구는 기존 구조를 이용했다. 가벼운 센서가 최근 자료에서 제한된 신호를 모으고, 신호나 미해결 후보가 있을 때만 판단을 열었다. 한 번에 다루는 후보 수도 제한했다. 읽기 전용 시험과 등록 검사는 통과했지만, 그 복구 작업에서 새 스킬을 배포한 것은 아니었다. 기록을 읽으면 ‘경로를 마련했다’와 ‘승격을 완료했다’가 따로 적혀 있다.

내가 여기서 얻은 첫 교훈은 단순하다. 자동화의 이름과 스케줄러의 초록불만 보면 안 된다. 무엇을 읽고 무엇을 만드는지 실제 구현을 봐야 한다.

바꾸기 전에 같은 과제로 비교하기

8월에는 Prime Agent의 자기개선 구조를 검토했다. 변경 종류를 제한하고, 적용 전 상태를 다시 확인하고, 변경 이력을 남기는 방식은 참고할 만했다. 그러나 런타임 자체를 병행 설치하지는 않았다. 기존 에이전트의 기억·스킬·작업 관리와 많이 겹쳤고, 공개 구현의 자기개선은 주로 다음 호출에 넣을 외부 상태를 편집하는 방식이었다. 고정 과제에 대한 전후 비교가 그대로 갖춰진 것은 아니었다.

우리 쪽에서는 다음 흐름을 택했다.

신호 수집 → 후보 하나 → 고정 과제로 기존 버전과 후보 비교 → owner 적용 → 이후 관찰.

신호는 명시적인 교정, 확인된 실패, 서로 다른 증거로 확인한 반복 성공에 한정했다. 후보는 바로 활성화하지 않았다. 평가 자료와 변경 전 상태를 고정하고, 같은 조건에서 기존 버전과 후보를 실행했다. 공통 스킬의 최종 적용과 배포는 중앙 서버의 owner가 맡았다. 여기서 owner는 사람이 매번 승인 버튼을 누른다는 뜻이 아니라, 적용 권한과 책임을 가진 기존 실행 경로를 뜻한다.

초기 적용 자료에는 실제 사용자 교정에 대한 제한된 평가가 기존 0.2에서 후보 1.0으로 개선되어 프로젝트 범위에 적용된 사례가 있다. 이 수치는 그 평가 묶음의 결과다. 에이전트 전체 정확도가 20%에서 100%가 됐다는 뜻도, 다른 업무에서 같은 효과가 난다는 뜻도 아니다. 그래도 단순히 ‘좋은 스킬을 만들었다’고 말하는 것보다 비교할 근거는 생겼다.

Hermes로 옮기면서 배포는 남고 수집은 빠졌다

9월의 이관 기록에는 또 다른 틈이 나온다. 기존 배포와 일부 위키·기억 수집은 남았지만, 사용자 교정과 작업 실패를 읽어 개선 후보로 넘기던 수집기가 Hermes의 세션·잡 자료에 맞게 연결되지 않았다. 서비스가 실행되고 스킬 파일이 보인다는 확인으로는 이 누락을 잡지 못했다.

Hermes 자체의 배경 학습도 중앙 관리와는 별개의 경로였다. 로컬에서 스킬을 만들 수 있다고 해서 중앙의 증거·평가·승인·배포 절차를 통과하는 것은 아니다. 기존 관리 스킬을 직접 바꾸지 못하더라도 비슷한 로컬 스킬을 새로 만들면 행동에 영향을 줄 수 있다.

그래서 Hermes는 후보를 만드는 쪽으로 쓰되, 공통 스킬을 활성화하는 권한은 중앙에 유지하는 구조를 택했다. 각 에이전트의 교정·실패·학습 후보를 모아 고정 평가로 넘기고, 통과한 변경만 기존 owner가 적용한다. 10월 초 요구도 이 방향이었다. 개선할 때마다 내가 다시 명령하지 않아야 하지만, 평가를 건너뛰어서는 안 된다는 것이다.

10월에는 관문이 하나씩 모습을 드러냈다

이후 며칠은 평가에서 배포까지 가는 길을 실제로 뚫는 작업이었다. 외부 드라이버 에이전트가 후보 코드를 만들고, 중앙 owner는 검토와 적용을 맡았다. 이 기반 수리에는 사람이 관여했다. 그 뒤 특정 개선 후보의 생성·평가·배포가 무인으로 이어졌다는 기록과는 구분해야 한다.

수정 묶음에 붙은 번호는 v20부터 v42까지 올라갔다. 숫자를 나열하면 많이 고쳤다는 말밖에 남지 않으므로, 실제로 막았던 일을 네 부류로 묶어 보겠다.

첫째는 무엇을 다시 처리할지 정하는 문제였다. 변하지 않은 사건을 매번 깨워 다시 읽거나, 정상적인 거절을 실패로 취급하거나, 이미 평가가 끝난 항목을 장부에서 닫지 못했다. 반복을 줄이려고 넣은 제한이 실제 진전이 있는 작업까지 주차시키는 역효과도 있었다. 필요한 것은 무조건 더 자주 실행하는 일이 아니라, 진전·거절·범위 밖·대기를 서로 다르게 기록하고 이어가는 일이었다.

둘째는 평가 계약과 평가기가 만드는 결과의 불일치였다. 행동 비교는 통과했는데 공식 평가에서 존재하지 않는 지표 이름을 찾다가 거절된 후보가 있었다. 행동 평가의 점수와 형식 평가의 지표·체크 이름을 섞은 것이다. 해결은 없는 지표를 만들어 통과시키는 일이 아니었다. 각 평가가 실제로 내보낼 수 있는 이름을 구분하고, 잘못된 계약은 접수 시점과 실행 직전에 거절하도록 연결했다.

셋째는 실제로 로드되는 코드와 준비한 후보가 다른 문제였다. 바깥의 승인 이력 검사는 새 평가기를 인정해도 안쪽 로더는 옛 해시만 비교했다. 재스테이징 과정에서 새 초안 대신 옛 초안이 다시 패키지에 들어간 일도 있었다. 테스트가 후보가 아니라 설치본을 실행한 경우까지 나왔다. 함수가 있다는 것과 운영 호출이 그 함수를 지나간다는 것은 달랐다.

넷째는 권한·배포·롤백의 마지막 연결이었다. 평가를 통과한 관리 도구 후보에 적용 처리기가 없어 제출 준비 상태에서 멈췄다. 배포 중 캐시 파일의 처리 규칙이 기존 테스트와 충돌했고, 실패한 배포 뒤 로컬과 원격 포인터가 서로 다른 세대를 가리키기도 했다. 첫 상태 교체가 받아들인 실패 세대를 마지막 재검사는 거절하는 결함도 있었다. 각각의 함수가 통과하는 것보다, 중간 실패 뒤 무엇이 남는지가 더 어려웠다.

해시가 맞아도 잘못된 동작일 수 있다

드라이버 기록에서 가장 인상적인 대목은 보류된 수정들이 대규모 해시 검사와 무결성 검사, 셸 문법 검사를 이미 통과했다는 부분이다. 18,133개 고정 항목을 확인해도 잘못된 정책이나 빠진 호출은 남을 수 있었다.

해시는 승인한 바이트가 맞는지 확인해 준다. 그 바이트가 올바른 동작을 하는지는 별도 문제다. 문법 검사도 비슷하다. 실행할 수 있는 문장이라는 뜻이지, 실행해야 할 문장이라는 뜻은 아니다.

owner의 보류는 실제 결함을 잡았다. 터미널의 최대 대기 시간보다 긴 규칙, 기본적으로 꺼진 검사, 실제 접수 함수에 연결되지 않은 검사, 평가 직전의 다른 호출 경로에서 빠진 검사를 찾아냈다. 관리 도구 적용 후보에서는 실행 주체를 환경 변수로 합성한 부분과, 롤백이 이후 다른 변경을 덮어쓸 수 있는 부분도 보류했다. 캐시 정책 변경 때는 일부 테스트만 실행해 놓친 기존 불변 조건이 전체 테스트에서 드러났다.

그래서 증명을 만드는 방식도 바뀌었다. 테스트한 파일과 보낸 파일이 같아야 한다. 중앙 서버가 실제로 로드하는 방식으로 번들 안의 후보만 로드해야 한다. 잘못된 입력이 진짜 접수·실행 진입점에서 거절되는지 보고, 다음 실행 경계에 표시를 두어 거기까지 도달하지 않았음을 확인해야 한다. 정상 입력도 통과해야 한다. 로컬에만 있는 보조 폴더가 없더라도 owner가 같은 증명을 재실행할 수 있어야 했다.

이것을 두고 검증을 더 많이 하면 된다고 이해하고 싶지는 않다. 내가 얻은 해석은 실제 실패를 잡는 위치로 검증을 옮겨야 한다는 것이다. 관련 없는 검사를 반복하는 일은 자동화를 앞으로 보내지 못했다.

실제로 배포된 두 종류의 개선

첫 번째 구체적인 사례는 frontend-taste의 CSS 검사 개선이다. 처음 후보는 행동 비교에서 좋아졌지만 공식 지표 이름 문제로 거절됐고, 무시 표시를 지우는 별도 위험도 있었다. 이름 문제를 고친 뒤 한 번의 후속 평가를 허용했고, 호환성을 포함한 새 후보를 평가했다. 이 재접수 경로를 마련한 일은 기반 수리에 해당한다.

그 뒤 후보 생성·평가·승인·배포는 자동 경로를 탔다. 드라이버 로그에는 고정된 CSS 검사 사례 9개에서 학습 평가가 0에서 1, 별도 검증 평가가 0.625에서 1, 치명적 실패가 3개에서 0개로 바뀌었다고 기록돼 있다. 공식 평가도 통과했고, 정기 owner 실행이 후보를 가져가 적용했다. 배포 영수증은 완료와 독립 두 번째 감사의 정상 종료를 기록하며, 알림 전송과 장부의 채택 종료도 뒤따랐다. 해당 후보의 승인·배포 단계에 사람이 대신 들어간 것은 아니라는 것이 작업 기록의 설명이다.

이것은 그 CSS 검사 사례에서의 개선과 배포 완료를 보여 준다. 프런트엔드 작업 전체의 품질 상승을 증명하지는 않는다. 이후 agent-refinement 자체의 독립 성공 증거 URI 접수 변경도 정기 owner를 통한 배포 완료로 기록됐다. 이 두 번째 사례에는 같은 형태의 품질 수치가 제시돼 있지 않으므로 배포 사실까지만 말할 수 있다.

두 번째 종류는 관리 도구 cron_command_bridge.py의 알림 개선이다. 출발점은 10월 14일 밤의 실제 실패였다. 중앙 서버의 네트워크·DNS 장애 중 배포 아티팩트를 FTP로 받다가 시간 초과가 났다. 평가 잡은 이 확인된 실패를 근거로, 기존 실패 알림이 FTP 응답 대기 시간 초과를 구체적으로 설명하지 못한다는 문제를 제안했다.

후보는 작았다. FTP 함수 안에서 발생한 TimeoutError일 때만 “아티팩트 FTP 응답 대기 시간 초과”라는 문구를 반환하는 7줄 추가였다. 제안은 재시도, 알림 전달 경로, 자격 증명을 바꾸지 않으며 배포나 복구가 성공했다고 주장하지도 않는다고 범위를 적었다. 네트워크 장애를 고친 것이 아니라, 그 장애의 한 실패 양상을 더 정확히 알리려는 변경이었다.

후보는 행동·공식 평가를 통과했지만 처음에는 관리 도구를 적용하는 경로가 없어서 멈췄다. 그 처리기와 배포·롤백 연결을 owner 검토로 마련한 뒤, 10월 15일 아침의 정기 실행이 적용했다. 06:44 상태 영수증을 정리한 로그는 적용 시각을 05:06으로 기록하고, 설치 파일 확인과 장부 채택 종료를 함께 남긴다. 따라서 보존 자료가 뒷받침하는 결론은 에이전트가 실패에서 작은 도구 개선을 제안했고, 허용된 owner 경로로 자동 적용됐다는 것이다. 실제 알림을 본 사용자가 더 빨리 원인을 찾았는지까지 측정한 것은 아니다.

아직 ‘매일 더 뛰어난 에이전트’는 아니다

두 사례는 의미가 있다. 후보가 문서에만 머무르지 않고 정기 실행을 거쳐 적용될 수 있다는 것을 보여 줬기 때문이다. 하지만 이것으로 다섯 달의 모든 요구가 해결됐다고 말할 수는 없다.

관리 도구 자동 배포 허용 목록은 아직 cron_command_bridge.py 하나다. 평가기, 무결성 검사, owner 처리, 감사 코드까지 에이전트가 마음대로 바꾸는 구조가 아니다. 허용 범위를 넓히려면 owner의 별도 검토와 적용이 필요하다. 승인 없이 바뀌었다가 되돌린 감시 규칙도 정식 제안으로 다시 들어와야 한다.

정기 복구 기록에는 설치 확인, 격리 테스트, 위키 정리, 실제 사업 실행이 서로 다른 시점에 남아 있다. 이른 아침 노트가 보존한 미완료 상태를 뒤의 성공 로그로 지워서는 안 된다. 뒤의 성공도 해당 거래의 범위에서 읽어야 한다. 새 성공이 나왔다는 이유로 모든 과거 장애와 모든 장비가 해결됐다고 할 수는 없다.

텍스트 검사는 문장의 조건을 확인한다. 배포 성공은 파일과 적용 경로를 확인한다. 모델의 자기평가는 모델이 그렇게 판단했다는 것을 남긴다. 어느 것도 혼자서는 업무 품질 향상의 증거가 아니다. 고정 과제에서 좋아진 결과조차 그 과제 밖의 일반화, 장기간의 재발 감소, 전체 비용 절감을 자동으로 증명하지 않는다.

그리고 자동화 기반을 복구하는 데 외부 드라이버와 사람의 개입이 많이 필요했다는 사실도 남는다. 경로를 고치는 일을 사람이 했고, 그 경로 위에서 일부 후보가 자동 배포됐다. 내가 확인한 범위는 여기까지다.

다섯 달 전에는 교훈을 잘 남기면 다음 작업도 나아질 것이라고 생각했다. 지금은 교훈이 후보가 되고, 같은 과제로 비교되고, 권한 있는 경로로 적용되고, 다음 작업에서 다시 관찰될 때까지 연결돼야 한다고 생각한다. 그중 하나만 빠져도 ‘자기개선이 켜져 있다’는 말과 실제로 달라지는 일 사이에 꽤 큰 거리가 생긴다.

이번에는 그 거리를 일부 줄였다. 늘 나아진다는 약속을 할 단계는 아니지만, 어디까지 자동으로 됐고 어디부터는 아직 모르는지를 말할 수 있는 기록은 생겼다.

이 글의 자료 범위

2026년 5월의 자기개선 패턴 흡수 기록, 7월의 일상 작업 승격 경로 진단·복구, 8월의 Prime Agent 검토와 제한된 비교 평가, 9월의 Hermes 학습·중앙 관리 이관 설계, 10월의 무인 개선 요구와 복구 기록을 사용했다. 특히 10월 11~15일 외부 드라이버의 원본 작업 로그와 15일 회고를 중앙 서버의 같은 기간 복구 노트와 대조했다. 내부 실행 주소와 식별자는 공개 글에서 제외했다. 성공 수치는 보존된 평가 범위를 벗어나 확대하지 않았다.