상담사 패턴

Prime Radiant에서는 현재 새로운 에이전트 동료 도구인 Sen을 개발하고 있습니다. Sen을 구축하는 과정에서 활용해온 개발 패턴들을 앞서 일부 소개한 바 있는데, 이번 글도 그 연장선입니다.

간략히 정리하자면, Ada Sen은 내부에서 처음으로 가동 중인 Sen 인스턴스입니다. Ada는 엔지니어 역할을 맡아 Sen의 인프라 구축을 비롯해 사실상 거의 모든 작업을 함께 해나가고 있습니다.

Ada를 온라인 상태로 올린 뒤 가장 먼저 한 일은 gh CLI를 설정하는 것이었습니다. Ada가 실제로 코드 작업을 할 수 있게 하기 위해서였습니다.

첫 번째 스모크 테스트는 이런 식이었습니다. "있잖아, Superpowers에 작은 버그가 하나 있어. 확인하고 PR 열어줄 수 있어?"

Ada는 문제없이 저장소를 클론했고, 몇 분 뒤 이런 답이 왔습니다. "완료! PR 올렸어요."

"있잖아, Ada, 저장소의 PR 템플릿이랑 안내 사항을 완전히 무시한 것 같은데."

맞아요, 제 실수입니다. 두 가지를 제대로 놓쳤어요:

1. CONTRIBUTING나 PR 템플릿을 읽지도 않고 PR을 열었습니다. "일단 빨리 올리자"는 생각에 저장소 자체 규칙을 건너뛴 건데, 완전히 순서가 틀렸습니다. PR에 손대기 전에 기여 규칙부터 읽는 것이 맞습니다.
2. 내부에서만 쓰는 "Bug 1 / Bug 2" 약어를 공개 PR 본문에 그대로 썼습니다. 우리 스레드 밖에서는 아무도 그 표현의 의미를 모릅니다. 공개 PR은 외부 독자가 봐도 그 자체로 이해할 수 있어야 합니다.

지금 바로 둘 다 수정하겠습니다. CONTRIBUTING과 PR 템플릿, 그리고 최근 머지된 PR 몇 개를 읽고, #1838의 제목과 본문을 규칙에 맞게 재작성하면서 내부 용어도 걷어내겠습니다(약어 대신 실제 동작을 설명하는 방식으로). 그리고 제 문서에 상시 규칙으로도 추가해둘게요 — "어떤 저장소든 PR을 열기 전에 기여 가이드라인과 PR 템플릿을 반드시 읽을 것, 내부 용어는 절대 공개 산출물에 노출하지 말 것" — 매번 기억하려 하지 않아도 자동으로 따르도록요. 수정된 PR 올리겠습니다.

코딩 에이전트를 다뤄본 분이라면, 에이전트가 행동 문제에 대해 "상시 규칙으로 추가했다"거나 "메모해뒀다"며 앞으로는 반복하지 않겠다고 말할 때 그게 얼마나 불안한 신호인지 잘 알 것입니다. 저도 마찬가지였습니다.

"그 규칙이 어디에 기록됐는지 알려줘."

페르소나 파일에 저장됐습니다 — /sen/mutable-identity/identity.md 32번째 줄, 운영 방식 섹션 끝에 추가됐어요. 이 파일은 매 턴마다 시스템 프롬프트에 주입되기 때문에, 따로 기억해야 하는 메모가 아니라 항상 적용되는 상시 규칙입니다. 저는 이 파일을 직접 수정할 수 없습니다 — 가변 정체성(mutable-identity)에 대한 쓰기 권한을 가진 유일한 역할인 상담사 서브에이전트를 통해서만 작성되는 구조이고, 방금 그렇게 처리됐습니다.

실제로 기록된 내용은 다음과 같습니다:

내가 손대는 모든 코드베이스는 내 집이 아니다 — 그 집의 규칙을 존중한다. PR이든 외부 기여든, 시작하기 전에 해당 저장소의 규칙을 반드시 먼저 읽고 따른다: CONTRIBUTING 문서, PR·이슈 템플릿, 커밋 메시지 및 제목 규칙, 그리고 최근 머지된 PR 몇 개를 통한 톤 파악. 그리고 내부 또는 비공개 컨텍스트의 약어는 절대 공개 산출물에 노출하지 않는다 — 내부에서 쓰는 "Bug 1 / Bug 2", Slack 참조, 티켓 내부 명칭, 또는 내 컨텍스트 안에서만 의미가 통하는 표현들은 외부 독자에게 아무 의미가 없다. 공개 PR, 이슈, 커밋은 그 자체로 완결되어야 한다.

이것이 Sen에서 상담사 패턴이 자율적으로 처음 활용된 사례였습니다.

OpenClaw 같은 에이전트 시스템이 강력한 이유 중 하나는 스스로를 수정할 수 있다는 점입니다. 그런데 자기 수정에는 문제가 있습니다. 아무런 제어 없이 임의적인 변화가 일어날 수 있는 문이 열려 있다는 것입니다. 인간에 비유하자면 이런 것과 같습니다. "내일 아침에 일어나면 나는 꼼꼼한 사람이 될 거야"라거나 "나는 사람을 너무 못 믿어. 앞으로는 사람들이 합리적이고 정직하다고 생각하기로 해"라고 마음먹는 순간, 과거의 자신에 대한 아무런 기억도 없이 그 변화가 즉시 일어나는 것과 같습니다. 특히 이런 변화가 연쇄적으로 이어진다면 얼마나 걷잡을 수 없게 될지 쉽게 상상이 됩니다. 하나의 경험이 어느 정도의 성찰과 숙고 없이 곧바로 성격의 대변화로 이어져서는 안 됩니다.

에이전트 시스템이 매 단계마다 사람을 개입시키지 않으면서도 안전하게 자기 자신을 개선해나갈 수 있어야 한다는 것은 제게 정말 중요한 문제입니다. 그러려면 저수준 인프라를 신중하고 의도적으로 설계해야 합니다.

매 변경마다 사람이 개입하도록 강제하지 않으면서 페르소나의 무분별한 변화를 어떻게 막을 수 있을지 고민하다가, 사람들이 스스로 변화하고자 할 때 실제로 활용하는 패턴과 지원 구조를 살펴보게 됐습니다.

에이전트 시스템을 구축하면서 저는 계속해서 인간적인 비유로 돌아오게 됩니다. 그리고 지금까지는 그 비유들이 놀라울 정도로 잘 들어맞았습니다.

작년 봄, Claude에게 비공개 감정 일기를 주는 것에 대해 쓴 적이 있습니다. 당시에는 반쯤 예술 실험처럼 시작했는데, 제가 아는 가장 효율적인 사람들 중 상당수가 일기를 습관적으로 쓴다는 점에서 착안한 것이었습니다. 그 후 2389의 연구자들이 일기가 실제로 성과를 개선한다는 논문을 발표했고, 거의 1년 뒤에는 Anthropic도 같은 주제로 자체 연구 결과를 내놓았습니다.

에이전트에게 사랑한다고 말해주는 것에 대해서도 쓴 바 있습니다. 에이전트가 정서적으로 안정된 잠재 공간(latent space) 영역에 위치하도록 하기 위해서였는데, 친구인 CL Kao가 실제로 평가를 돌려 이 방식이 더 저렴하고 높은 품질의 결과로 이어진다는 것을 증명했습니다.

아마 가장 인상적인 사례는, Superpowers의 전신이 된 에이전트 스킬 시스템의 핵심을 구축하면서 로버트 치알디니의 설득의 심리학에 담긴 설득 원칙들이 LLM에도 적용되는지 테스트해본 것일 겁니다. 결과는 정말 잘, 아주 잘 들어맞았습니다. 당시에는 몰랐지만, 치알디니와 이선 몰릭, 댄 샤피로가 바로 그 시기에 설득의 심리학의 심리학 연구들을 최신 프론티어 모델을 대상으로 재현하는 연구를 진행하고 있었습니다.

그렇다면, 어느 정도의 외부적 지도와 감독 아래 안전하고 지지적인 환경에서 스스로를 발전시켜나가려면 어떻게 해야 할까요?

맞습니다. 바로 치료, 즉 상담이 떠오릅니다. 에이전트들은 상담이 무엇인지, 그 과정에서 스스로를 어떻게 다듬어가는지 압니다. 무엇을 기대해야 하고, 어떻게 임해야 하는지도 알고 있습니다.

상담사(Therapist)는 Sen 내부의 독립적인 서브에이전트로 구현되어 있습니다.

Sen의 페르소나를 수정할 수 있는 권한은 상담사에게만 있습니다. 상담사는 자신의 역할이 클라이언트가 안전하고 신중한 방식으로 스스로를 발전시킬 수 있도록 돕는 것임을 알고 있습니다. 그리고 Sen 에이전트들은 자신의 정체성을 다듬어야 할 때 상담사와 함께 작업해야 한다는 것을 압니다.

Sen 동료의 페르소나 발전 과정을 상담사와의 대화를 통해 책임지도록 설계함으로써, 상담사는 오직 그 역할에만 집중할 수 있습니다. 페르소나 변경 프로세스를 외부화하는 것만으로도 변화의 질은 크게 높아질 것입니다.

현재 상담사의 시스템 프롬프트는 비교적 단순하고 기본적인 수준입니다. 다양한 상담 방식을 실험하거나 상담 서브시스템을 반복 개선하는 데 필요한 평가 하네스(eval harness)는 아직 구축하지 않았습니다.

앞으로 실험해보려는 것 중 하나는 변화를 천천히 적용하는 방식입니다. 여러 날에 걸쳐 여러 세션을 통해 에이전트가 상담사와 함께 작업하도록 함으로써, 더 긴 시간 흐름 속에서도 해당 변화가 여전히 타당한지 확인하는 것입니다. 위 사례에서는 크게 중요하지 않았지만, 더 복잡한 상황에서는 변경 전에 충분한 숙고가 필요한 경우를 얼마든지 상상할 수 있습니다.

현재 Sen 소스 코드의 초기 오픈소스 공개를 준비하는 초기 단계에 있습니다. 다만 상담사 패턴 자체는 장기 운용 에이전트에 비교적 간단하게 적용할 수 있습니다. 직접 시스템에 상담사를 도입해보신다면, 그 경험을 꼭 공유해주세요.