스스로 업데이트되는 에이전트 설정: '자기 진화(Self-evolving)'가 실제로 의미하는 것

[detected] 당신이 의존하는 라이브러리가 하룻밤 사이에 중대한 변경 사항(breaking change)을 배포했습니다.
[adopted] 기존 패턴은 차단되었고, 새로운 기본 설정이 이미 적용되었습니다.

나는 3주 동안 훅(hook)을 하나도 건드리지 않았습니다.

그럼에도 나의 설정은 계속해서 좋아지고 있었습니다.

자기 개선(self-improving) 에이전트에 대한 대부분의 데모는 보여주기식 쇼(theater)에 불과합니다.

모델이 무대 위에서 자신의 프롬프트(prompt)를 다시 작성하면 사람들이 박수를 치지만, 그중 어떤 것도 화요일의 실제 코드베이스(codebase)와 맞닥뜨렸을 때 살아남지 못합니다.

진정한 자기 진화(self evolution)는 지루합니다.

당신이 지켜보는 동안 에이전트가 스스로를 재작성하는 것은 잊으십시오. 유용한 에이전트는 세상이 변했다는 것을 알아차리고, 배운 것을 기록하며, 같은 것을 두 번 다시 다시 배우지 않습니다.

그 차이가 전부입니다.

왜 당신의 에이전트 설정은 부패하는가

모든 에이전트 설정은 구축한 다음 날부터 부패하기 시작합니다.

당신이 의존하는 도구가 새 버전을 출시합니다. 기본값이 바뀝니다. 호출하는 특정 모델이 은퇴합니다. 당신이 선의로 작성한 어떤 규칙이 조용히 거짓말을 하기 시작하는데, 그 이유는 규칙이 설명하던 대상이 더 이상 존재하지 않기 때문입니다.

그 일이 일어난 당일에는 눈치채지 못합니다.

3주 뒤, 고객 앞에서 무언가 고장 났을 때 비로소 깨닫게 됩니다. 그리고 그 원인이 작성 당시에는 맞았지만 그 이후로는 매일 틀렸던 규칙 때문이라는 사실을 알게 됩니다.

아무도 데모에서 이 부분을 보여주지 않습니다.

에이전트 설정은 극적인 충돌로 인해 죽는 경우가 드뭅니다. 느린 부패가 에이전트를 죽이며, 당신은 비용을 지불해야 할 때가 되어서야 비로소 상처를 느끼게 됩니다.

제 역할을 다하는 루프

나의 프로덕션(production) 버전은 네 가지 단계를 거치며, 그중 영리한 것은 하나도 없습니다.

탐지(Detect). 매일 의존하는 소스들을 확인하여 변경 사항을 체크합니다. 릴리스 노트(Release notes), 버전 번호, 보안 권고(security advisories), 의존하는 도구들의 문서(docs) 등을 확인합니다.

분류(Classify). 각 변경 사항에 대해 한 가지 질문을 던집니다. '이것을 사용할 수 있는가?', '이것이 나를 망가뜨리는가?', 아니면 '무시해도 되는가?'

코드화(Codify). 모두가 이 단계를 건너뜁니다. 유지할 가치가 있는 모든 변경 사항은 지속 가능한 규칙(durable rule)이나, 그 이후부터 자동으로 실행되는 가드(guard)로 변환됩니다. 금요일이면 잊어버릴 일회성 수정(One off fixes)은 여기에 해당하지 않습니다.

전파(Propagate). 그런 다음 적용되는 모든 곳에 도달하며, 동일한 수정 사항이 나에게 두 번 다시 비용을 발생시키지 않도록 합니다.

모든 것은 세 번째 단계에 달려 있습니다.

대부분의 사람들은 그 순간의 증상만을 패치(patch)하고 넘어갑니다. 그들의 패치는 누군가의 머릿속에 있거나 단 하나의 파일에 머물며, 다음에 동일한 유형의 문제가 발생할 때 다시 비용을 지불하게 됩니다.

단순히 수정을 적용하는 것이 아니라, 그 수정 사항을 포착(capturing)하는 것이 노후화되는 도구와 스스로를 구축해 나가는 도구 사이의 격차를 만듭니다.

아무도 언급하지 않는 한 가지 원칙

여기서부터는 저를 곤란하게 만드는 의견입니다.

이러한 설정은 반드시 인간 참여(human in the loop) 없이 스스로의 규칙을 재작성해서는 안 됩니다.

빈도(frequency)만으로 무엇이 영구적인 것이 될지 결정하게 두면 쓰레기가 만들어집니다. 그것은 노이즈를 코드화하고, 단 하루의 잘못된 사례로부터 과도하게 일반화하며, 한 달도 채 되지 않아 파일들 사이에서 스스로 모순을 일으킵니다.

따라서 시스템은 감지하고 제안한 뒤, 기다려야 합니다.

규칙이 법이 되기 전에 누군가가 이를 확인해야 합니다.

이 단 하나의 제약 조건이, 몇 달에 걸쳐 날카로워지는 설정과 아무도 믿지 않는 반쪽짜리 지침들의 더미로 부패해버리는 설정 사이를 갈라놓습니다.

포착된 판단(Captured judgment)은 언제나 자율성(autonomy)을 이깁니다.

거의 무너질 뻔했던 지점

이 루프(loop)의 첫 번째 버전은 거의 스스로를 파괴할 뻔했습니다.

감지(Detection)는 잘 작동했습니다. 매일 변경 사항을 찾아냈고 검토를 위해 대기열(queue)에 쌓았습니다.

그러다 대기열이 커졌습니다. 계속 커졌습니다. 발견된 사항들이 누군가 처리하는 속도보다 더 빠르게 쌓여갔습니다.

아무도 비우지 않는 대기열로 이어지는 감지 루프를 실행하면, 루프가 아예 없는 것보다 상황이 더 악화됩니다. 왜냐하면 이제는 조용히 학습을 멈추면서도 학습하고 있다는 착각을 주는 설정을 소유하게 되기 때문입니다.

여기서 감지를 더 늘리는 것은 도움이 되지 않았습니다. 대기열에 세 가지 가드레일(guardrails)을 설치하는 것이 도움이 되었습니다. 발견 사항이 너무 오래 머물면 유효 기간이 만료됩니다. 대기열이 상한치를 넘으면 경고를 보냅니다. 오래된 항목은 제자리에서 부패하는 대신 스스로 아카이브(archive)됩니다.

잊을 수 없는 학습 시스템은 학습을 멈춥니다. 그것은 축적(hoards)만 할 뿐입니다.

이 글이 제공하지 않는 것

저는 이 루프의 작동하는 버전을 운영하고 있습니다. 이 루프의 배선(wiring), 축적된 규칙들, 그리고 변경 유형을 적절한 유형의 가드레일로 매핑하는 플레이북(playbook)은 제가 고객 업무에 가져가는 것들입니다.

이 포스트에 그것들을 그대로 붙여넣지 않는 솔직한 이유가 여기 있습니다.

제가 가져오는 것은 어떤 변화가 영구적인 규칙이 될 가치가 있고 어떤 것이 노이즈(noise)인지에 대한 축적된 판단입니다. 그것은 실제 실패 사례들을 대상으로 루프(loop)를 수개월 동안 실행한 후에야 비로소 도달하는 것이며, 코드 스니펫(snippet) 하나에 담을 수 있는 것이 아닙니다.

이 설명을 바탕으로 4단계 이동 루프(four move loop)를 구축할 수 있습니다.

이를 유용하게 유지하는 것이 어려운 부분입니다. 그것이 위에서 언급한 수집광(hoarder)처럼 변하도록 내버려 두는 것은 하기 쉬운 실수입니다.

여러분의 차례입니다

저는 보통 하나의 질문으로부터 시작하여 엔터프라이즈(enterprise) 팀들에게 정확히 이 구조를 안내해 왔습니다. "당신의 에이전트 설정에서 매달 반복해서 수정하고 있는 것은 무엇입니까?"

그 답변은 거의 항상, 처음부터 스스로를 캡처(capture)했어야 하는 대상입니다.

그러니 여러분의 사례를 말씀해 주세요.

절대 고쳐지지 않고 계속해서 수정하고 있는 AI 툴링(tooling)은 무엇인가요? 아래에 남겨주시면 그것이 규칙(rule)인지, 가드(guard)인지, 아니면 놓아주어야 할 대상인지 말씀드리겠습니다.