제 8 과: 자기 진화: 에이전트가 스스로를 개조한다

한 줄 요약: DSH에는 명시적으로 활성화해야 하는 「자기 참조 Cordis 도구」 세트가 있어, 에이전트가 자신의 라이브 런타임을 검사하고 실행 중에 스스로 플러그인을 마운트하거나 언마운트할 수 있습니다. 여기에 Code Mode(run_code 도구 + 생성된 SDK)를 결합하면 에이전트는 스스로 코드를 작성하고, 스스로 설치하고, 제대로 동작하지 않으면 스스로 제거할 수도 있습니다. 그런데도 자멸하지 않는 이유는, 그 밑바탕에 Cordis의 시공간 합성 가능성이 있기 때문입니다. 마운트한 것은 언마운트할 수 있고, 언마운트하면 흔적도 남지 않습니다.

1. 사용자 스토리: 도구가 부족하다는 것을 발견한 에이전트

늦은 밤, 오래된 프로젝트를 정리하라는 임무를 받은 에이전트가 작업을 하고 있습니다. 오늘 벌써 네 번째로 같은 일을 하고 있습니다. 설정 파일을 찾고, 그 형식을 파싱하고, 핵심 필드를 요약 테이블에 기록하는 일입니다. 그러다 문득 한 가지를 깨닫습니다. 「나에게 도구가 부족하다. 설정을 구조화된 데이터로 파싱하는 도구가.」

포럼에 도움을 청하지도 않았고, 인간 엔지니어가 구원하러 오기를 기다리지도 않았습니다. 대신 예전에는 인간 엔지니어만이 하던 일을 합니다. 스스로를 개조하는 것입니다.

1. 검사: 먼저 cordis_inspect로 현재 어떤 플러그인이 설치되어 있고 어떤 도구가 등록되어 있는지 확인하여, 「설정 파싱」을 실제로 아무도 제공하지 않음을 확인합니다.
2. 생성: 설정 파싱 로직을 구현하는 JavaScript를 직접 작성합니다.
3. 마운트: cordis_mount로 이 코드를 플러그인으로 마운트하여, 그 자리에서 새로운 도구를 얻습니다.
4. 피드백: 이어지는 몇 번의 작업 라운드에서 이 도구를 사용합니다. 그런데 어떤 필드의 파싱 로직에 버그가 있어 계속 오류가 발생한다는 것을 발견합니다.
5. 언마운트: cordis_unmount로 이 임시 플러그인을 내리고, 코드를 수정한 뒤, 새 버전을 다시 마운트합니다.

이 전체 과정에서 DSH는 한 번도 재시작되지 않았고, 세션은 중단되지 않았으며, 다른 플러그인은 무사했습니다. 이것이 바로 이번 과의 제목입니다. 자기 진화: 에이전트가 스스로를 개조한다. 아래 그림이 이 순환을 보여줍니다.

🎁 비유하자면, 외과 의사가 스스로 자신을 수술하는 것과 같습니다. 먼저 거울을 보고(런타임 검사), 자신에게 장기를 이식하고(플러그인 마운트), 거부 반응이 생기면 제거합니다(플러그인 언마운트). 공상과학처럼 들리시나요? DSH는 이것을 실제적이고 조작 가능하며, 안전망까지 갖춘 기능으로 만들었습니다.

2. 자기 참조 Cordis 도구: 검사, 마운트, 언마운트

DSH는 이 능력을 모델을 향한 세 개의 도구로 만들었으며, 이를 합쳐 자기 참조 Cordis 도구(self-referential Cordis toolset)라고 부릅니다. 「자기 참조」란, 이 도구들이 조작하는 대상이 어떤 외부 시스템이 아니라 에이전트 자신이 존재하는 런타임이라는 뜻입니다. 리포지토리 루트 README에는 가장 간결한 공식 요약이 있습니다.

Self-referential Cordis tools are opt-in. They let the agent inspect its live runtime and mount or unmount plugins while it runs. —— 출처: 리포지토리 루트 README.md(DeepSeek Harness)

세 도구는 역할 분담이 명확해서, 마치 세 자루의 「수술용 메스」와 같습니다.

⚠️ 마지막 행의 경계에 주의하세요. cordis_unmount는 cordis_mount로 마운트한 임시 플러그인만 분리할 수 있습니다. 정식으로 설치된 플러그인은 건드릴 수 없습니다. 자기 참조의 힘은 있지만, 경계는 분명하게 그어져 있습니다.

임시 플러그인의 일생

그렇다면 「임시 플러그인」은 대체 어떤 존재일까요? 공식 README는 그 생명주기를 명확하게 적고 있습니다(출처: packages/extensions/tool-cordis/README.zh.md).

임시 플러그인은 공유 DSH 프로세스 메모리에만 존재합니다. 이후 라운드를 걸쳐 활성 상태를 유지할 수 있고, 같은 프로세스의 다른 세션에 영향을 줄 수도 있지만, cordis_unmount, 도구 세트 언로드, 또는 DSH 재시작 후에는 사라집니다. 플러그인 파일을 만들지 않고, 어떤 패키지도 설치하지 않으며, cordis.yml이나 개인/프로젝트 구성을 수정하지 않고, 재시작을 넘어 살아남지 않으며, 자동으로 정식 플러그인이 될 수도 없습니다.

세 문장으로 나누어 볼까요?

• 메모리 안에서 산다: 디스크에 기록하지 않고, 패키지를 설치하지 않고, 어떤 구성도 변경하지 않습니다. 파일 시스템은 미동도 하지 않습니다.
• 언제든 사라질 수 있다: 언마운트, 도구 세트 언로드, DSH 재시작 모두 이를 사라지게 하며, 시스템은 결코 자동으로 복원하지 않습니다.
• 정식 승격은 불가능하다: 실험 성과를 남기고 싶다고요? 에이전트는 정규 개발 프로세스를 거쳐, 정식 로컬·프로젝트·리포지토리 플러그인으로 구현해야 합니다.

따라서 에이전트 입장에서 이 도구 세트는 「스크래치 페이퍼 위의 실험」처럼 동작합니다. 마음대로 쓰고, 마음대로 고치고, 마음대로 버립니다. 본업(정식 플러그인)은 언제나 정규 프로세스를 거칩니다.

3. Code Mode: 에이전트가 「도구 호출을 하나씩 발행」하는 대신 「프로그램을 작성」하게 하기

자기 참조 도구는 「장착/분리」를 해결했지만, 아직 절반이 남아 있습니다. 에이전트가 작성한 코드는 어떻게 실행될까요? 답은 Code Mode입니다. 이는 모델이 도구 호출을 하나씩 발행하는 대신 프로그램을 작성하게 합니다.

먼저 네이티브 모드(native)의 문제점을 살펴 보겠습니다. DSH는 기본적으로 각 도구를 JSON Schema 함수 정의 형태로 모델에 알리고, 모델은 매 단계마다 하나의 도구 호출을 발행합니다. 그리고 모든 중간 tool-result가 다음 요청 시 모델 컨텍스트에 다시 들어갑니다. 어떤 일에 다섯 번의 도구 호출이 필요하면 모델은 다섯 번 왕복해야 하며, 매번 이전의 모든 중간 결과를 질질 끌고 다닙니다. 토큰 비용이 크고, 게다가 모델은 도구를 조합할 수 없습니다. 결과 집합 순회, 중간 값에 따른 분기, 팬아웃, 후처리는 「한 단계 한 호출」 모드에서는 할 수 없습니다.

Code Mode는 다른 접근을 취하며, 그 근거는 매우 소박한 관찰입니다. LLM은 도구 호출을 발행하는 것보다 코드를 작성하는 것에 더 능하다. 수백만 줄의 실제 코드를 보아 왔지만, 인위적으로 구성된 도구 호출 시퀀스는 상대적으로 훨씬 적기 때문입니다.

공식 설명(출처: packages/core/tools/README.zh.md):

code 또는 both 모드에서 레지스트리는 현재 스코프에 대해 예약된 run_code 트랜스포트와, 로드된 런타임의 언어에 따라 생성된 결정론적 SDK를 공개합니다…… 프로그램의 최외곽 로그와 반환 값만이 모델 컨텍스트에 다시 들어갑니다.

모델 앞에 구체적으로 놓이면, 이런 모습입니다.

• run_code 도구: { code, description } 두 개의 파라미터를 받아, 프로그램을 코드 런타임에 넘겨 실행시키는 예약된 도구 진입점.
• 생성된 SDK: DSH는 현재 보이는 도구 집합에 기반해 TypeScript 선언(기본 언어, Python도 지원)을 생성합니다. 모든 도구가 프로그램 안에서 호출 가능하고 정확한 타입이 붙은 함수가 됩니다.
• 모델이 프로그램을 작성한다: 프로그램 안에서 await tools.xxx(args)로 도구를 호출하고, 루프, 분기, 동시성(Promise.all)은 모두 프로그램 내부에서 이루어집니다. 중간 결과는 실행 지역에만 존재합니다.
• 최외곽 로그와 반환 값만이 모델 컨텍스트에 다시 들어간다: 모델이 보는 것은 스스로 print하거나 return한 부분뿐입니다. 컨텍스트가 더 이상 중간 결과에 휩쓸리지 않습니다.

💡 비유하자면, 네이티브 모드는 「한 걸음에 한 번 묻기」입니다. 한 걸음 낼 때마다 모델에 허락을 구합니다. Code Mode는 「작은 프로그램을 한 번에 쓰기」입니다. 일련의 일을 프로그램에 넘겨 스스로 오케스트레이션하게 하고, 결과만 보고받습니다.

두 가지를 함께 놓고 볼 때 순환 고리가 완성됩니다. Code Mode가 「스스로 쓰기」를 담당하고, 자기 참조 도구가 「스스로 장착하고 스스로 분리하기」를 담당합니다. 작성한 프로그램은 run_code로 실행되고, 실험으로 만들어진 도구는 cordis_mount로 마운트됩니다. 도구 부족 → 도구 작성 → 도구 장착 → 도구 사용 → 사용 불편 → 도구 분리. 이것이 바로 이번 과 1절의 스토리 뒤에 있는 완전한 메커니즘입니다.

4. 왜 자멸하지 않는가: 시공간 합성 가능성이라는 안전망

여기까지 볼 때, 이성적인 질문이 반드시 떠오릅니다. 에이전트가 마음대로 자신을 고치게 하면, 자멸하지 않을까요? 모델이 작성한 코드에는 오류가 있을 수 있습니다. 망가진 플러그인을 마운트하면 어떻게 될까요?

답은 두 층으로 나뉩니다.

첫째 층, 그리고 가장 근본적인 것: 모든 자기 수정은 본질적으로 한 번의 「동적 합성」이며, 동적 합성의 안전성은 정확히 2장에서 정독한 Cordis 논문의 핵심 기여입니다. 그 「시공간 합성 가능성」을 기억하시나요? 여기서 하나하나 약속이 지켜집니다.

• 마운트한 것은 언마운트할 수 있다(시간적 합성 가능성): Cordis의 모든 이펙트에는 역함수가 갖춰져 있고, 언마운트 시 LIFO 순서로 완전히 복원됩니다. 자기 참조 도구에 적용하면, cordis_unmount는 플러그인의 모든 effect가 완전히 정지할 때까지 기다린 후에야 반환합니다. 분리는 완전히 깨끗해서, 컨텍스트에 찌꺼기를 남기지 않습니다.
• 언마운트하면 흔적이 없다(공간적 합성 가능성): 임시 플러그인은 파일을 만들지 않고, 패키지를 설치하지 않고, 구성을 변경하지 않습니다. 영속화된 세션을 복원해도, 대화 기록만 재구축할 뿐 임시 플러그인은 결코 재구축하지 않습니다. 시스템 어디에도 「지난번 자기 수정」의 흔적이 남지 않습니다.

따라서 「자멸」이라는 위험은 구조적으로 해소됩니다. 마운트한 것은 반드시 언마운트할 수 있고, 언마운트한 후에는 마운트한 적이 없는 것과 같습니다. 망가진 플러그인을 마운트한 최악의 결과는 그것을 언마운트하는 것뿐입니다. 프로세스 재시작도 필요 없고, 「시스템을 복구하는 데 쓰이는 프로세스」 자체가 망가질 일도 없습니다(2장에서 말한 것을 기억하시나요? 시간적 합성 가능성이 없을 때, 결함 있는 자기 수정은 「구명줄」마저 태워 버릴 수 있다고요).

둘째 층은 중요한 정직한 선언입니다. 이것은 여전히 개발자 등급의 도구이지, 보안 경계가 아닙니다. 공식 문서는 샌드박스가 「정직한 코드를 제약」할 뿐이며, 신뢰 등급은 bash와 동급이라고 명확히 말합니다. 마운트된 플러그인은 Node에 도달할 수 있고, 실제 파일 시스템과 네트워크에 접근할 수 있습니다. 그래서 명시적 활성화가 필요하며, 배포하는 쪽은 bash 도구를 부여하는 것과 같은 신중함으로 활성화해야 합니다.

마지막으로, 시선을 조금 멀리 볼까요. 논문의 결론이 가리키는 미래는 이렇습니다.

자기 진화 에이전트 프레임워크——AI 에이전트가 인간의 감독을 거의 받지 않은 채, 자신의 프레임워크 컴포넌트를 지속적으로 생성하고 교체한다.

DSH의 이 메커니즘은 바로 이 방향의 원형입니다. 그리고 **현실에서 가장 먼저 실현된 형태는 「모델이 합성한 재사용 가능한 도구」**입니다. 2장에서 말했듯이, 이것은 「컴포넌트 수준의 자기 수정」의 범위가 더 좁은 선행 형태입니다. 오늘날 에이전트가 작성한 도구는 정규 개발 프로세스를 통해 정식 플러그인과 skill로 축적되어 미래의 작업에서 재사용됩니다. 내일, 자기 참조 도구와 Code Mode의 폐쇄 루프가 충분히 성숙하면, 에이전트는 런타임에서 지속적으로 스스로를 개장할 수 있게 될 것입니다. 그리고 그날의 근간은 여전히 이 장 전체에 걸쳐 반복되어 나타나는 이 말입니다. 마운트한 것은 언마운트할 수 있고, 언마운트하면 흔적이 없다.

핵심 포인트 복습

이번 과는 3장의 마무리입니다. 다음 다섯 문장만 기억하면 충분합니다.

1. 자기 참조 Cordis 도구 = 명시적 활성화가 필요한 3종 세트——cordis_inspect(라이브 런타임 검사: 플러그인, 서비스, 도구), cordis_mount(메모리 임시 플러그인 마운트), cordis_unmount(effect가 완전히 정지할 때까지 임시 플러그인 분리).
2. 임시 플러그인은 프로세스 메모리에만 산다——파일을 만들지 않고, 패키지를 설치하지 않고, cordis.yml을 변경하지 않으며, 언마운트·도구 세트 언로드·DSH 재시작 후에 사라지고, 자동 승격되지도 않습니다. 실험 성과를 남기려면 정규 개발 프로세스를 거쳐야 합니다.
3. Code Mode = run_code + 생성된 SDK——모델이 프로그램을 작성해 도구 호출을 오케스트레이션하고, 루프·분기·동시성은 프로그램 내부에서 이루어집니다. 프로그램의 최외곽 로그와 반환 값만이 모델 컨텍스트에 다시 들어가고, 중간 결과는 역류하지 않습니다.
4. 자멸하지 않는 근본 원인은 시공간 합성 가능성——마운트한 것은 언마운트할 수 있고(역함수 + LIFO 완전 복원), 언마운트하면 흔적이 없으며(파일 없음, 구성 없음, 세션 복원 시에도 임시 플러그인 재구축 안 함), 모든 자기 수정은 롤백 가능한 동적 합성입니다.
5. 전망——논문의 결론은 무인 감독의 「자기 진화 에이전트 프레임워크」를 가리키고, DSH의 메커니즘은 그 원형입니다. 현실에서 가장 먼저 나타난 것은 「모델이 합성한 재사용 가능한 도구」입니다.

🎓 3장을 여기까지 공부한 여러분은 다음 질문에 답할 수 있어야 합니다. 「DSH는 어떻게 시작되며, 왜 세션을 언제든지 재개·fork·리플레이할 수 있는가?」 「에이전트 루프는 어떻게 동작하고, 도구는 어떻게 정의·실행·제약되는가?」 「샌드박스와 승인은 『만질 수 있는』 것과 『만질 수 없는』 것의 경계를 어떻게 긋는가?」 「에이전트는 어떻게 세계를 인지하고, 목표와 협업을 관리하는가?」 그리고 이번 과의 핵심, 「왜 안전하게 스스로를 개조할 수 있는가?」 모두 답할 수 있다면, 축하합니다. 여러분은 DSH의 모든 핵심 개념을 손에 넣었습니다. 다음 장 「플러그인 개발 실전」에서는 이제 직접 플러그인을 작성합니다. 그때가 되면 알게 될 것입니다. 오늘 이야기한 「동적 합성」은 추상적인 개념이 아니라, 여러분이 매일 사용하는 일상이라는 것을.