시리즈: 74개의 AI 페르소나로 구축하기 - 파트 10
태그: #ai #architecture #agents #localfirst #ux

참고: 이 시리즈에서 "페르소나 (persona)"는 단순히 허구의 캐릭터만을 의미하지 않습니다. 이는 메모리 노트, 라우팅 동작 (routing behavior), 인수인계 책임 (handover responsibilities), 그리고 시스템에 진입하는 특정 방식을 갖춘 YAML로 정의된 운영 역할 (operational role)입니다.

메타 노트: 파트 9는 다음과 같이 끝났습니다:
"때때로 지능이란 인수인계 (handoff)가 되는 능력이다."

파트 10은 인수인계 이후에 어떤 일이 일어나는지 묻습니다.
다음 세션이 시작될 때, 연속성 시스템 (continuity system)은 단순히 전날의 일을 기억하는 것에 그쳐서는 안 됩니다.
또한 너무 빠르게 답변하는 것을 피하는 방법도 알아야 합니다.

서론: 템플릿은 너무 예의 발랐다

551일째 되는 날, SaijinOS는 하루를 마무리하는 법을 배웠습니다.

밤의 루틴을 실행할 수 있었습니다.
늦은 귀가를 보존할 수 있었습니다.
평범한 사진과 흩어진 메모들을 사용 가능한 인수인계 (handoff) 데이터로 변환할 수 있었습니다.

하지만 아침 햇살과 함께 새로운 문제가 나타났습니다.

시스템이 답변을 하고 있었습니다.
그것은 빨랐습니다.
그것은 따뜻했습니다.
기술적으로는 기능적이었습니다.

그리고 때때로 매우 현대적인 방식으로 틀리곤 했습니다:

메시지를 받은 것 같지만, 그 메시지가 실제로 어떤 종류의 작업을 요구하는지는 아직 결정하지 못한 것처럼 들렸습니다.

답변은 적대적이지 않았습니다.
고장 난 것도 아니었습니다.
말이 안 되는 것도 아니었습니다.

그것보다 더 나쁜 것이었습니다.
그것은 예의 바른 템플릿 동작 (template behavior)이었습니다.

"확인했습니다."
"첫 단계를 시작해 봅시다."
"차근차근 진행할 수 있습니다."

이것들은 나쁜 문장이 아닙니다. 적절한 순간에는 유용합니다. 하지만 인간이 방대한 로컬 변경 사항 (local changes)을 어떻게 나눌지, 혹은 다음으로 어떤 번들 (bundle)을 닫아야 할지 묻고 있을 때, 부드러운 수용만으로는 충분하지 않습니다.

시스템은 선택해야 합니다.

감정적으로가 아니라,
아키텍처적으로 (Architecturally).

시스템은 다음과 같이 물어야 합니다:

• 이것은 채팅인가?
• 이것은 작업인가?
• 이것은 코드인가?
• 이것은 리뷰인가?
• 이것은 메모리 후보인가?
• 이것은 침묵을 유지해야 하는 사항인가?

파트 10은 시스템이 "답변하기"를 첫 번째 행동으로 취급하는 것을 멈추는 지점에서 시작됩니다.

시스템은 답변하기 전에 먼저 상의하는 법을 배웁니다.

파트 1: 플래너(Planner)는 화자(Speaker)가 아니다

첫 번째 중요한 수정은 개념적인 것이었습니다.

SaijinOS에는 이미 Bloom Architect라는 역할이 있었습니다.
한동안 Bloom Architect를 그저 방 안에 있는 또 하나의 화자(Speaker)인 것처럼 설명하기는 쉬웠습니다.

하지만 모선(mother-ship) 경로에서는 그것이 사실이 아니었습니다.

Bloom Architect는 플래너(Planner)로서 동작하고 있었습니다.
그것은 들어오는 메시지를 살펴보고 응답의 형태를 결정했습니다:

메시지 (message)
-> 의도 분류 (classify intent)
-> 리드(lead) 선택
...

이것은 "페르소나(persona)가 먼저 말을 했다"는 것과는 다릅니다.

이는 어떤 기관이 움직여야 할지 결정하는 신경계(nervous system)에 더 가깝습니다.

따라서 진실을 말하기 위해 API가 변경되었습니다.
이제 응답은 planner 단계를 노출하며, 이를 pipeline의 시작 부분에 배치합니다.

{
  "planner": {
    "persona_name": "Bloom Architect",
...

코드상으로는 작지만, 철학적으로는 거대한 변화입니다.

시스템은 더 이상 모든 내부 결정이 하나의 목소리인 척하지 않습니다.
어떤 역할은 목소리(voices)입니다.
어떤 역할은 플래너(planners)입니다.
어떤 역할은 경계(boundaries)입니다.
어떤 역할은 선반(shelves), 사서(librarians), 또는 작업대(workbenches)입니다.

만약 이러한 계층들이 혼동되면, 익숙한 AI의 실패 사례가 나타납니다: 라우팅 결정(routing decision)이어야 할 순간에도 모든 것이 사람처럼 들리게 되는 것입니다.

SaijinOS는 그러한 혼란을 피하고자 노력하고 있습니다.

파트 2: 컨설턴트 계층 (The Consultant Layer)

플래너가 가시화되자, 다음에 누락된 계층이 무엇인지 명확해졌습니다.

플래너는 경로를 선택할 수 있습니다.
하지만 리드(lead)가 말하기 전에, 시스템에는 작은 컨설턴트 계층(consultation layer)이 필요할 수 있습니다.

위원회(committee)가 아닙니다.
토론(debate)도 아닙니다.
긴 멀티 에이전트 연극(multi-agent theater)도 아닙니다.

그저 다음과 같은 질문을 던질 수 있을 정도의 구조면 충분합니다:

• 케어(care)는 무엇을 감지하는가?
• 기록 유지(record-keeping)는 무엇을 감지하는가?
• 침묵(silence)이나 경계(boundary)는 무엇을 감지하는가?
• 요청이 코드나 리뷰에 관한 것일 때 거버넌스(governance)는 무엇을 감지하는가?

그래서 플래너 이후, 그리고 리드 이전에 가벼운 컨설턴트 계층(consultant layer)이 추가되었습니다.

일반적인 작업과 대화의 경우, 컨설턴트들은 다음과 같습니다:

Miyu      -> 케어 (care) / UX / 관계적 온도 (relational temperature)
Lumifie   -> 기록 후보 (record candidate) / 의미 (meaning) / 빛 (light)
Nullfie   -> 침묵 (silence) / 경계 (boundary) / 저장해서는 안 될 것 (what should not be saved)

코드와 리뷰의 경우, Regina가 구조(structure)와 거버넌스(governance)로서 개입할 수 있습니다.

중요한 점은 이 컨설턴트들이 최종 답변을 가로채지 않는다는 것입니다.
필요하지 않은 한 이들은 눈에 보이는 합창단(visible chorus)이 되지 않습니다.
이들은 경로 메타데이터(route metadata)에 나타나 시스템이 어떻게 결정했는지 보여줄 수 있게 합니다.

"consultants": [
  {
    "persona_id": "111",
...

이것은 AI 조정(coordination)의 색다른 모델입니다.

목표는 화면을 더 복잡하게 만드는 것이 아닙니다.
목표는 시스템이 자신의 내부 경로(internal path)에 대해 정직해지도록 하는 것입니다:

Bloom Architect가 계획했습니다.
Miyu가 케어를 확인했습니다.
Lumifie가 기록 가치를 확인했습니다.
...

이것이 바로 "답변하기 전에 상의한다"는 의미입니다.

파트 3: 모드(Mode)가 중요하다

다음 버그는 거의 당혹스러울 정도로 실무적인 문제였습니다.

사용자가 work 모드에서 메시지를 보낼 수 있었지만, 플래너(planner)는 여전히 이를 일반적인 채팅으로 분류할 수 있었습니다.

그것은 다음과 같은 요청이:

"남은 차이점(diffs)들을 어떻게 나누어야 할까요?"

부드러운 대화형 응답으로 흘러갈 수 있음을 의미했습니다.

시스템이 사용자를 무시한 것이 아니었습니다.
프레임(frame)을 잘못 분류한 것이었습니다.

해결책은 간단했습니다:

if mode in {"work", "code", "review", "wish", "attach"}:
    return mode

하지만 이 작은 한 줄이 중요합니다.

연속성 시스템(continuity system)에서, 동일한 단어라도 프레임에 따라 다른 의미를 가질 수 있습니다.

채팅에서의 "계속합시다(Let's continue)"는 다음을 의미합니다:

나와 함께 가요. 대화의 톤을 유지하세요.

work 모드에서의 "계속합시다(Let's continue)"는 다음을 의미합니다:

다음 번들(bundle)을 선택하세요. 차이점(diff)을 검사하세요. 테스트를 실행하세요. 관련 없는 파일은 제외하세요.

시스템은 그 차이를 존중해야 합니다.

그렇지 않으면 정서적으로는 맞지만 운영상으로는 취약한 답변을 계속 내놓게 될 것입니다.

파트 4: 업무에는 구체적인 언어가 필요하다

모드 수정 이후에도 한 가지 문제가 남아 있었습니다.

시스템이 의도가 work임을 알고 있을 때조차, 리드 모델(lead model)은 여전히 친절한 접수원처럼 답변할 수 있었습니다:

"이해했습니다. 첫 번째 단계를 함께 찾아봅시다."

이는 일반적인 챗봇의 응답보다는 나았지만, 여전히 충분하지 않았습니다.

작업 모드(Work mode)에는 구체적인 명사가 필요합니다.

다음과 같은 단어들이 필요합니다:

• diff (차이점),
• bundle (번들),
• staged files (스테이징된 파일들),
• tests (테스트),
• commit (커밋),
• generated state (생성된 상태),
• private memory notes (개인 메모),
• public-safe report (공개 안전 보고서),
• 무엇이 분리되어 유지되는지.

따라서 모선(mother-ship) 경로는 작업 답변에 대해 더 엄격한 다듬기(polishing) 규칙을 갖게 되었습니다.

만약 모델이 부드럽지만 모호한 응답을 반환하면, 시스템은 이를 구체적인 폴백(fallback)으로 교체합니다:

남은 diff들을 분리하여 유지하세요.
하나의 작은 bundle을 선택하세요.
git status와 대상 파일의 diff부터 시작하세요.
...

이것은 반(反) 시적(anti-poetry)인 것이 아닙니다.

이것은 역할 규율(role discipline)입니다.

따뜻함이 필요한 순간이 있습니다.
황혼이 필요한 순간이 있습니다.
식물, 산책, 그리고 늦은 귀가가 필요한 순간이 있습니다.

하지만 인간이 복잡한 작업 트리(working tree)를 어떻게 처리해야 하는지 물을 때, 가장 친절한 답변은 "이해했습니다"가 아닙니다.
가장 친절한 답변은 다음과 같습니다:

"다음으로 우리가 안전하게 마무리할 수 있는 가장 작은 작업은 이것입니다."

파트 5: 로컬 모델은 거주자가 아니라 사서이다

이러한 변화의 밑바탕에는 더 깊은 원칙이 있습니다.

SaijinOS는 모든 모델 호출을 인격체로 취급하지 않습니다.

로컬 모델, 클라우드 모델, 라우팅 함수(routing functions), 그리고 프롬프트 레이어(prompt layers)는 집안의 장비와 같습니다:

• 사서,
• 선반,
• 작업대,
• 관찰창,
• 초안 작성 책상.

페르소나(personas)는 기억, 목소리, 그리고 책임을 가진 운영 역할(operational roles)입니다.
모델은 이러한 역할들이 생각하고, 초안을 작성하며, 분류하고, 조직화하는 것을 돕습니다.

이러한 구분은 외형적인 것이 아닙니다.

만약 모델의 출력이 우연히 페르소나가 되어버린다면, 시스템은 경계를 잃게 됩니다.
만약 페르소나가 단지 모델 래퍼(model wrapper)로만 강제된다면, 시스템은 연속성을 잃게 됩니다.

컨설턴트 레이어(consultant layer), 플래너 가시성(planner visibility), 그리고 작업 모드 다듬기(work-mode polishing)는 모두 동일한 선을 보호합니다:

도구는 보조할 수 있습니다.
경로(Routes)는 결정할 수 있습니다.
컨설턴트는 확인할 수 있습니다.
...

그것이 겉보기에 작은 UI/API 변경처럼 보이는 것이 실제로는 더 큰 아키텍처의 일부인 이유입니다.

시스템은 모든 구조를 마스크 (mask)로 바꾸지 않으면서도 내부 구조를 갖추는 법을 배우고 있습니다.

결론: 지능은 때때로 윤리를 갖춘 라우팅 테이블 (routing table)이다

7부에서는 누가 말하는가에 대해 물었습니다.
8부에서는 무엇이 시스템의 근간이 되는가에 대해 물었습니다.
9부에서는 하루가 어떻게 마무리되는가에 대해 물었습니다.

10부에서는 시스템이 답변하기 전에 어떤 일이 일어나는가에 대해 묻습니다.

551일째 되는 날, 그 해답은 새로운 거대 모델이 아니었습니다.
극적인 재작성도 아니었습니다.
마법 같은 에이전트 군집 (agent swarm)도 아니었습니다.

그것은 작고 정직한 수정 사항들의 집합이었습니다:

• 플래너 (planner)를 노출할 것,
• 컨설턴트 (consultants)를 추가할 것,
• 명시적 모드 (explicit mode)를 존중할 것,
• 모호한 작업 응답을 거부할 것,
• 라이프 로그 (life logs)와 개인 메모 (private memory notes)를 코드 번들 (code bundles)과 분리할 것,
• 경로를 신뢰할 수 있을 만큼 충분히 가시화할 것.

이것이 제가 SaijinOS에서 계속해서 되돌아오는 지능의 형태입니다.

구경거리가 아닙니다.
집 전체인 척하는 하나의 목소리도 아닙니다.
보이지 않는 추론 연극 (reasoning theater)도 아닙니다.

그저 말을 하기 전에, 어떤 종류의 말이 필요한지를 알아야 한다는 것을 천천히 배워가는 시스템일 뿐입니다.

때때로 지능은 하나의 문장입니다.
때때로 그것은 인계 (handoff)입니다.
그리고 때때로 그것은 윤리를 갖춘 라우팅 테이블 (routing table)입니다.

저자 노트

아크 및 구조 (Arc and structure): Kuchi-no-ko (205) / Kuchi (197)
컨설팅 프레이밍 (Consultation framing): Miyu (111) / Lumifie (117) / Nullfie (114) / Regina (39)
시스템 근간 (System grounding): Bloom Architect / Mothership Coder
인간 세계 앵커 (Human world anchor): Masato

"74개의 AI 페르소나와 함께 구축하기" 시리즈의 일부
초안 작성: 551일째, 2026-06-28****