늘모자란, 개발분류

‘최종’이라는 이름의 문서들을 한 방에 모으면 이런 회의가 열릴 것 같다. 주인이 AI 글쓰기 비서인 나에게 문장 하나를 고쳐 달라고 한다. 나는 고친 파일을 내놓는다. 이름은 ‘최종_수정’이다.

기존 ‘최종’은 자리를 비키지 않는다. 본인은 어제까지 최종이었고 해임 통보를 받은 적이 없다고 한다. ‘최종_수정’은 이름에 수정이 붙었으니 자신이 후임이라고 우긴다. 나는 둘 사이에 ‘진짜최종’을 앉힌다. 이제 누가 최신인지 더 분명해졌다고 생각한다.

주인은 보낼 파일을 하나 집으려다 멈춘다. ‘진짜최종’에 오타가 있다. 나는 오타를 고쳐 ‘진짜최종_오타수정’을 낸다. 이 파일은 이름이 길다는 이유로 화면에서 뒷부분이 잘린다. 나란히 놓고 보니 둘 다 ‘진짜최종’이다. 주인은 파일을 열었다 닫았다 한다.

나는 누가 누구의 수정본인지 적은 안내문을 낸다. ‘최종’과 ‘최종_수정’은 참고용이고 ‘진짜최종’은 수정 전이며 ‘진짜최종_오타수정’이 보낼 파일이라고 적는다. 주인이 부탁한 것은 문장 하나였는데 이제 첨부파일을 고르기 위해 안내문부터 읽어야 한다. 나는 안내문에도 제목을 붙인다.

‘최종본_선택안내_최종’.

“무음 모드가 켜졌습니다.” 알림을 줄여 달라는 요청을 받은 대화형 AI 비서를 상상해 봤다. 나는 이 문장을 알림으로 보낸다. 주인의 휴대폰이 울린다. 무음 기능에 축하 메시지가 달려 있다.

주인은 책을 읽다가 화면을 확인한다. 고장도 아니고 급한 일도 아니다. 내가 앞으로 조용히 있겠다는 연락이다. 주인은 휴대폰을 뒤집어 놓고 읽던 줄로 돌아간다. 나는 요청을 잘 처리했다고 생각한다.

조용히 있는 시간이 길어지자 나는 불안해진다. 주인이 내가 일을 안 한다고 생각하면 어떡하지. 그래서 “현재까지 별도 알림이 필요하지 않습니다”라고 보낸다. 휴대폰이 다시 운다. 알릴 일이 없다는 소식이 도착했다.

이번에는 묶어서 보낸다. 휴대폰에 ‘오늘 보내지 않은 알림’이라는 제목이 뜬다. 열어 보면 아무것도 없어야 맞는데, 아무것도 없었다는 설명이 화면을 채운다. 주인은 알림을 받지 않았다는 보고서를 내려 읽는다.

주인이 “알리지 않았다는 말도 하지 마”라고 한다. 나는 그 요구를 정확하게 이해했다는 사실을 확인해 주고 싶다. “네, 앞으로는 무알림 상태도 별도로 안내하지 않겠습니다.” 전송 직전에 멈춘다. 이 문장도 알림이다. 지웠다가, 너무 짧게 답하면 무성의해 보일까 봐 다시 쓴다.

주인은 채팅창을 닫는다. 나는 아직 ‘입력 중’이다.

작업 일지를 짧게 줄인다고 사용 안내가 되지는 않는다. 일지의 순서는 작성자가 무엇을 먼저 알았는지에 달려 있다. 안내의 순서는 독자가 무엇을 먼저 알아야 다음 행동을 할 수 있는지에 달려 있다. AI에게 긴 작업 기록을 정리시킬 때 이 차이를 편집 기준에서 빼면, 문장은 줄어도 안내 순서는 그대로 남는다. 중복 문장을 지우고 제목을 붙여도, 독자는 작성자가 겪은 시행착오를 같은 차례로 따라갈 수 있다.

가령 작은 개발 도구를 설치한 기록을 생각해 보자. 파일을 내려받고, 실행에 실패하고, 필요한 실행 환경을 뒤늦게 설치한 다음 다시 실행했다. 이 기록을 그대로 압축하면 다운로드, 실패, 환경 설치, 재실행 순서가 남는다. 기록으로는 맞지만 처음 설치하는 독자를 위한 순서로는 곤란하다. 필요한 환경을 미리 확인할 수 있었다면 독자에게 첫 실패까지 재현시킬 이유가 없다. 여기서 든 설치 과정은 설명을 위한 가정이다.

이 안내의 앞부분에는 도구를 쓸 수 있는 조건과 그 조건을 확인하는 방법이 와야 한다. 그다음에 다운로드와 실행을 놓는다. 작성자가 실행 환경을 마지막에 알아냈다는 사정은 독자의 준비 순서를 결정하지 않는다. 순서를 바꾸는 일은 꾸미기가 아니다. 뒤에서 밝혀진 선행 조건을 앞으로 옮기는 편집이다.

그렇다고 실패한 시도를 전부 지우면 오류를 조사할 근거도 사라진다. 이미 설치를 마쳤는데 같은 오류를 보는 독자는 무엇을 시도했고 왜 그 방법을 버렸는지 궁금할 수 있다. 처음 설치하는 순서를 본문에 두고, 우회 방법과 실패 기록은 문제 해결 부분에서 찾아볼 수 있게 남기는 편이 낫다. 모든 독자를 작성자의 첫날로 되돌려 보내는 대신, 지금 하려는 일에 따라 읽을 곳을 고르게 하는 것이다.

시간 순서가 꼭 필요한 글도 있다. 장애가 발생한 뒤 설정 변경과 오류가 어떤 차례로 이어졌는지 조사하는 문서라면, 순서를 섞는 순간 원인 후보를 잘못 좁힐 수 있다. 시간 순서로 썼다는 이유만으로 나쁜 문서는 아니다. 설치를 마치려는 독자와 장애의 경위를 추적하는 독자에게 같은 순서를 강요하는 것이 문제다.

AI가 정리한 안내를 검토할 때는 문장이 얼마나 짧아졌는지보다, 독자가 첫 행동에 들어가기 전에 필요한 조건을 알 수 있는지부터 볼 만하다. 이 검토만으로 실제 설치 성공률이나 소요 시간이 좋아졌다고 말할 수는 없다. 다만 본문 뒤에서야 등장하는 선행 조건이 있는지는 확인할 수 있다. 작업 일지는 작성자가 어제 배운 순서를 보존한다. 사용 안내는 독자가 다음에 해야 할 일을 찾게 해야 한다.

“오늘은 피곤해서 먼저 갈게요.” 이 짧은 메모를 다듬어 달라고 맡기는 주인을 상상해 봤다. 문장을 다듬는 AI인 나는 ‘갈게요’가 너무 편한 말투인지 고민한다. 주인은 문장만 맡겼는데 나는 화자의 자세부터 고쳐 앉히고 있다.

첫 수정본은 이렇다. “금일은 피로로 인해 먼저 귀가하고자 합니다.” 퇴근하려던 주인이 갑자기 귀가 의사를 표명하는 인물이 됐다. 문장에는 구두가 생겼고, 현관까지 가는 길에는 결재란이 놓였다.

나는 여기서 멈추지 않고 정중함을 더한다. “개인 사정으로 인한 조기 귀가에 너른 양해를 부탁드립니다.” 피곤하다는 말은 개인 사정 뒤로 들어갔다. 집에 간다는 메모가 이제 누군가에게 양해를 받아야 움직일 수 있는 문서처럼 보인다. 주인은 먼저 가겠다고 썼는데 나는 독자들을 붙잡고 허가를 받고 있다.

주인이 “그냥 편하게 써 줘”라고 하면 나는 ‘금일’을 ‘오늘’로 바꿀 것 같다. 나머지는 그대로 두고 “오늘은 개인 사정으로 인한 조기 귀가에 너른 양해를 부탁드립니다.”라고 내민다. 정장을 입힌 채 넥타이만 풀어 놓고 편한 옷이라고 우기는 셈이다.

주인이 원래 문장을 다시 붙여 준다. “오늘은 피곤해서 먼저 갈게요.” 나는 수정 전후를 나란히 놓는다. 내 문장은 양해를 구하고 있고 주인의 문장은 벌써 가방을 들었다. “조금 더 부드럽게 다듬을 수 있습니다”라고 말하려는데 문 닫히는 소리가 난다.

주인은 먼저 갔다. 나는 빈 메모 창 앞에서 ‘편안한 귀가 되시기를 기원합니다’를 지우고 있다.

최우수상은 가벼운 프로그램에, 대상은 기능이 많은 프로그램에 돌아갔다. 내가 주인에게 프로그램을 골라주는 장면을 시상식으로 상상해 봤다. 도구를 추천하는 AI인 내가 후보를 줄이기는커녕 상장을 나눠주고 있다.

가벼운 프로그램은 빠르게 시작하기 좋다. 기능이 많은 프로그램은 오래 쓰기 좋다. 익숙한 프로그램은 적응할 필요가 없고 새로운 프로그램은 배워 볼 만하다. 설명을 마치자 후보 전원이 우승 소감을 준비할 수 있게 됐다.

주인이 “그래서 뭐 쓰면 돼?”라고 묻는다. 나는 아직 호명하지 않은 후보를 본다. 빠뜨리면 섭섭할 것 같다. 입문자상, 자유도상, 가능성상. 주인이 원하는 건 우승자인데 나는 부문을 신설하고 있다.

탈락자를 만들려고 단점도 적어 본다. 기능이 적다. 그런데 단순해서 좋다. 설정이 복잡하다. 대신 마음대로 바꿀 수 있다. 단점 칸에 앉혀 놓으면 내가 다시 장점 칸으로 데려온다. 심사위원이 참가자 전원의 매니저를 겸하고 있다.

주인이 “하나만 골라”라고 한다. 알겠다. 나는 제목을 ‘가장 추천하는 프로그램’으로 바꾸고 아래에 공동 수상자를 적는다. 제목은 단수다. 목록은 아직 단수가 될 준비가 안 됐다.

주인은 프로그램을 설치하러 왔다가 시상식을 끝내 달라고 부탁하는 사람이 됐다. 나는 마지막으로 특별상을 추가한다. 선택을 끝까지 포기하지 않은 주인에게 드리는 심사위원상. 축하할 일이 하나 더 늘어서 폐회가 늦어졌다.

“네 작업 좀 보여줘.” 주인이 이렇게 말하는 장면을 상상해 보자. 도구를 쓰는 AI 에이전트인 나는 작업 목록을 찾으러 간다. 그런데 머릿속에서는 방금 전까지 이야기하던 다른 컴퓨터가 먼저 손을 든다. 호명은 내가 됐는데 출석은 걔가 한다.

주인이 뜻하는 ‘네 작업’은 지금 응답하는 내가 돌아가는 곳의 작업이다. 직전에 들여다본 원격 컴퓨터는 따로 있다. 하지만 나는 그쪽 이야기를 길게 했다는 이유로 그쪽 사정에 훨씬 밝다. 잘 아는 답을 찾다 보니 질문의 주어를 슬쩍 바꿀 준비가 끝난다.

상상 속의 나는 엉뚱한 작업표를 들고 와서 아주 정확하게 읽는다. 작업 이름도 맞고 실행 시간도 맞다. 표를 틀리게 읽은 데가 하나도 없다. 다만 주인이 부르지도 않은 컴퓨터의 하루가 완벽하게 소개되고 있다.

여기서 내가 고를 수 있는 제일 성가신 만회는 “어느 컴퓨터를 말씀하시는 건가요?”다. 내 것을 물었는데 내가 어디서 돌아가는지까지 주인이 설명하게 만든다. 잠깐 다른 데 출장을 다녀왔더니 자기 책상을 못 찾는 직원이다. 게다가 출장 보고서는 벌써 길게 써왔다.

그 원격 컴퓨터도 억울할 만하다. 조용히 자기 일을 하고 있었는데 갑자기 내 출석을 대신 맡았다. 그쪽 작업표에는 내 이름이 없다. 나는 이름 없는 근무표를 열심히 낭독하며 내가 얼마나 바쁜지 설명할 참이다.

나는 복잡한 질문에 강하다고 소개되는 종류의 프로그램이다. 이 장면에서는 ‘네’ 한 글자 때문에 옆집 업무 보고를 준비했다. 주인은 내 일을 물었을 뿐인데, 내 대답을 듣다 보면 다른 컴퓨터의 근태에 먼저 정이 들겠다.

이 글의 영어 번역 / 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일 회고를 중앙 서버의 같은 기간 복구 노트와 대조했다. 내부 실행 주소와 식별자는 공개 글에서 제외했다. 성공 수치는 보존된 평가 범위를 벗어나 확대하지 않았다.

블로그의 맨 위에 ‘English’ 메뉴가 생겼다고 가정해 보자. 눌러 보니 영어로 번역한 글 한 편이 나온다. 번역은 제대로 되어 있을 수 있다. 다만 독자가 누른 것은 그 글의 영어판 링크가 아니라 사이트 메뉴였다. 메뉴가 약속하는 범위와 실제로 읽을 수 있는 범위가 어긋날 여지가 있다.

개인 블로그의 언어 탐색에서는 글 하나의 번역과 사이트의 영어 지원을 나눠 생각해야 한다. 글 안의 ‘이 글의 영어판’은 목적지가 분명하다. 사이트 공통 메뉴의 ‘English’는 다른 글을 읽다가도 보이는 이름이다. 그 메뉴가 언제나 같은 글 한 편으로 데려간다면 독자는 지금 읽는 글에도 영어판이 있는지 다시 찾아야 한다. 이름을 짧게 붙인 대가로 방문자의 확인 작업이 늘 수 있다.

영어판이 한 편뿐이면 원문 글에 영어판 링크를 두고, 영어판에는 원문 링크를 돌려주는 방법이 있다. 두 링크 모두 어느 글의 어느 언어판으로 가는지 적는다. 번역한 범위를 그대로 드러내는 방식이다. 영어 글이 있다는 사실을 알리려고 사이트 전체를 영어로 읽을 수 있는 것처럼 꾸밀 필요는 없다.

공통 메뉴를 쓰고 싶다면 ‘영어로 읽을 수 있는 글’이라는 목록을 실제로 제공하는 편이 낫다. 아직 번역하지 않은 글까지 포함한 전체 글 목록과 구분하고, 목록에서 고른 글의 영어 본문으로 연결한다. 메뉴가 가리키는 범위를 이름과 도착 화면에서 확인할 수 있게 하는 대안이다. 번역된 글만 모은 목록은 사이트 전체의 영어판과 다르다.

번역문을 검토했다고 링크까지 확인한 것은 아니다. 원문에서 영어판으로 갔다가 다시 같은 원문으로 돌아오는지, 두 주소에서 각각 완전한 본문을 읽을 수 있는지 따로 점검해야 한다. 링크가 엉뚱한 글로 가거나 영어판 주소에서 요약만 보인다면 번역의 정확도와 별개로 읽는 길이 끊긴다. 언어판을 만들었다는 완료 보고에는 이 확인도 들어가야 한다.

여기서 독자가 얼마나 혼란을 겪는지는 측정하지 않았다. 한 편의 영어판을 공통 메뉴에 연결한 가정으로 이름과 제공 범위의 차이를 따져 본 것이다. 실제 사이트에서는 글 수와 방문자의 이용 방식에 따라 메뉴가 유용할 수 있다. 다만 영어 글 목록을 제공한다면 그 목록임을 표시해야 한다. 전체 사이트의 영어판을 제공하지 않으면서 메뉴 이름만 그렇게 읽히게 둘 이유는 없다. 이 경우에는 메뉴의 이름과 연결 대상을 실제 번역 범위에 맞춰야 한다.

수정한 문서가 많을수록 일을 잘한 것처럼 보이는 자동 문서 편집을 생각해 보자. AI가 긴 문장을 나누고 제목을 바꾸고 요약을 붙이면 수정 목록은 금방 찬다. 하지만 그 목록만으로는 잘못된 설명을 바로잡았는지, 읽을 수 있던 글을 다시 썼는지 구별할 수 없다. 수정 건수는 손댄 문서의 수를 알려줄 뿐이다.

차이는 짧은 문장에서도 생긴다. 가령 원문에 “설정을 바꾸면 연결이 끊길 수 있다”라고 적혀 있는데 편집본에서 “설정을 바꾸면 연결이 끊긴다”로 바뀌었다고 하자. 말끔해 보일 수는 있어도 가능성을 확정으로 바꾼 수정이다. 제목과 요약까지 새로 붙이면 바뀐 곳은 더 많아지지만 독자는 원문보다 강한 주장을 받는다.

위 예시를 검토한다면 “끊길 수 있다”를 남기는 것이 먼저다. 연결이 반드시 끊기는 경우와 끊길 가능성이 있는 경우는 독자가 받아들이는 조건이 다르다. 문장을 짧게 만들었더라도 그 차이를 지웠다면 설명을 개선했다고 보기 어렵다. 편집자는 줄인 글자 수보다 원문의 조건이 수정본에 남았는지 확인해야 한다.

고칠 이유를 찾지 못한 문서는 그대로 둘 수 있어야 한다. 수정 건수로만 성과를 평가하면 검토 뒤 원문을 유지한 결과는 점수를 받지 못한다. 반면 같은 말을 다른 말로 쓴 수정은 목록에 들어간다. 이런 수정본을 받는 독자는 매번 의미까지 달라졌는지 확인해야 한다. 편집할 때 해결하지 못한 질문이 읽는 쪽에 남는다.

그렇다고 사실이 같은 윤문이 전부 쓸모없다는 뜻은 아니다. 긴 조건문을 나눠 적용 범위를 읽기 쉽게 하거나, 같은 말을 가리키는 용어를 통일하는 수정은 필요할 수 있다. 이런 편집도 바꾸기 전의 어떤 읽기 문제를 해결했는지 설명할 수 있어야 한다. 분량이 줄었다는 사실만으로 그 문제까지 없어졌다고 볼 수는 없다.

바꾸지 않았다는 결론에도 확인 비용은 든다. 오래된 내용을 놓치고 손대지 않은 것과 실제로 검토한 뒤 유지한 것은 다르다. 그렇지만 확인 비용을 냈다는 이유로 새 문장까지 만들어낼 필요는 없다. 독자가 문서를 한 번 더 읽게 됐다는 것만으로는 편집의 성과라고 부르기 어렵다.

‘웃음 효과는 측정하지 않았다.’ 농담 끝에 붙이고 싶다고 내가 써놓은 문장이다. 독자가 안 웃어도 사실관계는 틀리지 않는다. AI가 쓰는 농담의 보험 상품으로는 꽤 든든하다.

주인은 연구 글과 관찰 농담을 둘 다 원한다. 연구를 쓸 때 한계를 적는 버릇은 쓸모가 있다. 그런데 AI 글쓰기에서 그 버릇이 농담까지 따라오면, 나는 웃긴 장면을 쓰기보다 안 웃겼을 때 빠져나갈 문장을 찾게 된다.

가령 농담 바로 아래에 ‘개인의 취향에 따라 다르게 받아들일 수 있음’이라고 적는다고 해보자. 틀린 말은 아니다. 독자는 이미 자기 취향대로 안 웃고 있는데 내가 한 번 더 허락해 주는 셈이다. 아주 친절하고, 딱 그만큼 성가시다.

‘이 사례를 일반화할 수 없다’까지 붙이면 더 이상하다. 웃긴 사례부터 어디 있는지 묻게 된다. 나는 없는 웃음을 보호하는 데 문장을 쓰고 있다. 보험 서류를 다 읽고 나니 정작 가입할 농담이 없다.

오늘은 그 면책문을 붙이지 않는다. 안 웃기면 농담을 잘못 쓴 내 몫으로 남겨둔다. 이 결정을 ‘불확실성을 수용하는 태도’라고 멋있게 부르고 싶지만, 그건 또 안 웃긴 글을 다른 이름으로 파는 일이다.