커넥터·서브에이전트·기억 — 검증력, 생성과 검증의 분리, 디스크

앞 글 자동화·워크트리·스킬 — 기동 장치, 작업 분리, 프로젝트 지식에서 루프 구성 요소의 앞 셋을 봤다. 이 글은 나머지 셋, 에이전트를 바깥 도구에 잇는 플러그인/커넥터, 생성과 검증을 나누는 서브에이전트, 그리고 다섯 요소를 관통하는 토대인 기억을 다룬다. 여기까지가 개념이고, 다음 글 Claude Code와 Codex app에서 조립하는 법에서 실제 도구의 대응물로 떨어뜨린다.

④ 플러그인/커넥터 ── MCP로 이어서 검증력을 키운다

에이전트가 현실의 도구를 다룰 수 있게

루프가 제구실을 하려면 에이전트가 현실의 도구를 다룰 수 있어야 한다. 플러그인/커넥터는 에이전트를 기존 도구나 서비스에 잇는 구조다. 기술적으로는 MCP(Model Context Protocol, 2024년 11월에 Anthropic이 공개한, 에이전트와 외부 도구를 잇는 개방형 규격) 같은 게 쓰인다.

커넥터가 늘수록 확인하는 힘이 커진다

실무상의 요령을 하나 짚는다. 커넥터가 충실해질수록 루프는 자율적으로 확인하는 힘을 키운다.

브라우저 조작, 데이터베이스 질의, API 호출, 외부 서비스 연동. 이런 연동 대상이 늘수록 에이전트는 자기 작업 결과를 실물로 검증할 수 있게 된다. '코드를 썼다'에서 그치지 않고 '브라우저로 열어서 표시를 확인했다', 'DB에 질의해서 값을 확인했다'까지 스스로 돌릴 수 있다.

검증 수단이 는다는 건 그대로 루프의 정확도를 올리기 쉬워진다는 말이다. 커넥터는 바깥세상을 만지는 손인 동시에 자기 일을 실물로 확인하는 눈이다.

⑤ 서브에이전트 ── 생성과 검증을 나눈다

자기가 만들고 자기가 좋다고 하면 놓친다

에이전트 하나에게 만들기와 확인하기를 둘 다 맡기면 자기가 만든 걸 자기가 좋다고 하기 쉽다. 사람도 마찬가지여서, 쓴 본인이 하는 교정은 놓치는 게 많지 않나.

서브에이전트는 역할을 분담시키는 구조

서브에이전트는 역할이 다른 여러 에이전트에게 분담시키는 구조다(Claude Code에서의 기본 사용법은 서브 에이전트로 작업 나누기에 있다). 오스마니는 전형적인 분담을 이렇게 그린다.

"one of them has the idea and a different one checks it"

(한쪽이 아이디어를 내고, 다른 한쪽이 그걸 확인한다)

이건 일반적으로 Generator–Verifier(생성과 검증의 분리)라 불리는 패턴에 해당한다. 생성하는 쪽과 검증하는 쪽을 따로 두면 자기 승인 사고를 막을 수 있다.

검증 쪽은 '이건 망가져 있다'는 전제로 흠을 찾는 게 이상적이다. 실례와 정리에서도 반복해서 나오는, 루프의 신뢰성을 떠받치는 핵심 사고방식이다.

⑥ 기억 ── 에이전트는 잊고, 리포지터리는 잊지 않는다

모델은 실행과 실행 사이에 잊는다

마지막은 5개 요소를 관통하는 토대, 기억이다. 여기엔 중요한 전제가 있다. 모델(에이전트)은 실행과 실행 사이에 잊는다. 첫 바퀴에서 고생해서 알아낸 것도 다음 바퀴에서는 백지에서 시작할 수 있다. 에이전트의 기억은 기본적으로 휘발한다.

그래서 기억은 디스크에 남긴다

그래서 기억은 에이전트의 컨텍스트(그때뿐인 작업 메모리) 안에 두면 안 된다. 디스크에 남긴다. 파일로 써 두면 에이전트가 잊어도 다음 바퀴가 그걸 읽고 이어서 시작할 수 있다. 오스마니는 이걸 한 줄짜리 명언으로 정리했다.

"The agent forgets, the repo doesnt."

(에이전트는 잊지만, 리포지터리는 잊지 않는다.)

(원문 그대로. 오스마니는 아포스트로피를 빼고 doesnt로 적었다)

주어를 정확히 짚자

이 부분은 정확히 짚고 가면 좋겠다. 주어는 에이전트(the agent)이지 모델 일반이 아니다. 짝이 되는 건 리포지터리(the repo)다.

기억이 놓이는 자리를 휘발하는 컨텍스트에서 영속하는 파일(리포지터리)로 옮긴다. 이게 루프가 바퀴를 넘어가며 똑똑해질 수 있는 물리적 전제다. 안쪽 루프와 바깥쪽 루프에서 볼 바깥쪽 루프는 바로 이 영속 기억 위에 서 있다.

다음 글: Claude Code와 Codex app에서 조립하는 법