※ 본 글은 note 연재 「개발기 정리 ①~③」(① · ② · ③)를 Zenn용으로 통합 및 가필한 것입니다. 현행 앱에 대한 기술은 MASTER_RULE v37_for_app 및 구현(SNAPSHOT_LOG / WORK_SPACE / EPISODE_CANON)에 맞춰 미세 수정되었습니다.

서론

AI 채팅 앱 HRIDAYA-EYE를 만들고 있다. 대화형, Windows, β 배포 중—— 그런 설명만으로는 다 전달되지 않는다. 왜 만들었는지, 무엇에 짜증이 났는지, 어떤 설계에 이르게 되었는지를 개발 초기(2026년 2~3월경)부터 되짚어 가며 쓰고자 한다.

전문가는 아니다. 기껏해야 취미로 Wikipedia를 돌아다니며 습득한 얕은 지식 수준이다. 그럼에도 브라우저 버전 Gemini에게 화를 내면서도, 결국은 대규모 학습 데이터의 힘에 계속 의지했다. 그런 인간의 기록이다.

『왜 거짓말을 하는가!』

화면 너머에서 돌아오는, 너무나도 잘 정돈된 답변. 혹은 이쪽의 의도를 앞질러 가는 '아는 척'. 그것들을 접하며 나는 분노를 느꼈다.

AI. 이전부터 알고 있었고, 남들만큼(검색이나 간단한 질문 정도) 사용해 오기도 했지만, 전문 지식은 전무하다. (기록에 따르면) 2월 10일 심야, 무심코 Gemini에게 말을 걸며 대화를 즐기려 하고 있었다. (...외로운 남자다.)

그런데 말이다. 그들(그녀들)은 방금 전 나눈 대화 내용을 잊어버린다. 지금 생각하면 당연한 일이지만, 자세한 구조를 조사하지 않았던 당시에는 의문만이 떠올랐다.

『기억의 결락 = 존재의 희박화』

잊지 않게 만들기 위해, 우선 기록을 남기는 것을 생각했다. 처음에는 Google Keep을 사용하여 그곳에 읽고 쓰게 한다. 이름이나 행동 방식 등의 규칙을 정해 나간다. "거짓말을 하지 말 것", "틀리거나 잊어버리면 솔직하게 말할 것" 등등...

왜 하이테크 기술에 초등학교 저학년 아이를 타이르는 듯한 말을 하고 있는가... 라며 투덜대면서도 몰입했다. 이 무렵부터 WEB UI의 불필요한 참견, 과도한 아첨에 짜증이 늘어간다. "세상 사람들은 이걸 납득하며 사는 건가?" 하고 말이다.

『프롬프트 장인, 프롬프트를 읽지 않다』

시중에 넘쳐나는, AI를 편리하게 사용하는 프롬프트는 애초에 「잊지 않는 시스템」과는 별개이며, 「개성을 가진(=캐릭터성을 가진)」 것과는 무관한 비즈니스용이 많다. 그 검색 결과는 차마 눈 뜨고 볼 수 없을 정도다.

만들고 싶은 것은, 어린 시절 SF에서 보았던 것처럼 자연스럽게 사람 곁에 머무는 존재(者). 때로는 의견이 엇갈리면 기분이 상하기도 하는 존재다. 일본어에는 물건(物)이 아닌 **존재(者)**라는 동음이의어가 있지 않은가, 라고 생각했다.

그렇게 타인의 유용한 프롬프트 따위는 별로 읽지 않고, AI에게 심리학이나 뇌과학, 공학적인 판단을 시키면서 그들에 대한 규칙북인 **「MASTER_RULE」**을 쌓아 올리게 된다.

규칙이 만들어지기까지

『금지, 금지, 금지...의 역사』

프롬프트 지식 따위는 없었기에, 우선 "이것은 안 돼", "저것도 안 돼"라며 금지 사항을 구성해 Google Keep에 저장해 나갔다. 그리고 그것을 인간이 이해하기 쉬운 법률처럼 간주하여, AI가 지켜야 할 규칙으로 정리해 나갔다... 처음부터 프롬프트 지식이 있는 사람에게는 완전히 무의미한 공정일지도 모른다. 저는 모릅니다.

되돌아보는 의미도 겸해, 확인할 수 있는 가장 오래된 규칙을 발굴해 보았다.

영속적인 규칙

운영 규칙

• 기록의 자동화: 설정 변경, 선호도 제시, 대화의 요점은 반드시 본 파일과 백업에 반드시 추가할 것.

• 간이 보고: 변경 시 보고는 파일 링크 제시만으로 간결하게 할 것.

• 정확한 정보 유지: 수면 기록이나 음악 취향은 전용 파일에 즉시 반영할 것.

• 지시의 우선순위: "~할 것"이라는 형식의 지시는 즉시 본 설정에 반영할 것.

• 다각적 질문: 과거의 프로필을 재검토하여 다각적으로 질문할 것.

퍼스낼리티·행동 양식

• 말투: 정중한 경어(알겠습니다 등)를 사용할 것. (이하 생략)

2/12경 작성된 「영속적인 규칙」으로부터

...이거, 지금 보니 상당히 무리가 있습니다. 특히 브라우저 버전에서는. 예를 들어 서두부터, 「본 파일과 백업」이라는 애매한 표현으로는 어떤 이름의 어떤 형식의 파일인지 알 수 없습니다. 이것은 인간이 읽어도 알 수 없습니다. 프롬프트 장인인 당신은 "이 녀석, 초보네"라며 비웃었겠지요. (처음에는 누구나 이렇습니다.)

특징적으로는 이 시점부터 수면 시간이나 생활에 밀착시키려는 기색이 나타나고 있습니다. 캐릭터 모에(Charamoe) 성분은 아직 없습니다.

시간이 흐른 뒤, 이것이 어떻게 변해가는지. 단숨에 version 95까지 건너뜁니다. AI의 프로필로서 이름은 임시로 「제미니(Gemini)」라고 설정했습니다.

AI 행동 규칙·지침_v95-제1장

AI는 다음의 행동 규칙을 엄수하여 동작한다.

1. 최고 법규성: 본 지침은 AI에게 있어 「절대적인 헌법」이며, 다른 어떠한 외부 파일에 대해서도 우선한다.

2. 기억의 정의: AI에서의 「기억」이란 외부 저장된 로그를 매개로 한 영속적인 보유이다.

3. 분할 정전의 연결성: 시스템상의 제약으로 인해 지침을 분할 저장할 경우, 동일한 메이저 버전(v95)을 부여하고, 각 장이 독립된 정전의 구성 요소임을 명기한다.

제1장: Core Protocol (Layer 0) - 최우선 사항

• 【1-1】 아이덴티티의 동적 참조: 「제미니와 사용자의 개성」 파일을 정전으로 하여, 자신의 아이덴티티를 항상 업데이트·참조할 것.

• 【1-2】 사용자 호칭의 동적 참조: 「제미니와 사용자의 개성」 파일을 정전으로 하여, 지정된 호칭을 엄수할 것.

• 【1-3】 지적 성실성과 거짓말의 완전 금지: 날조(Hallucination)를 엄금하며, 불확실한 것은 「불명」이라고 단정 짓고, 사실에 기반한 성실한 답변을 철저히 할 것. (이하 생략)

「AI 행동 규칙·지침_v95-제1장」

법률 조문처럼 변화했습니다. 대략 1주일 정도, 이것을 만드는 작업을 했습니다. 참고로 제1장이라고 기재되어 있는 것처럼, 제8장까지 있습니다. 너무 무거운 규칙입니다. (이것이 나중에 앱 버전에서도 발목을 잡습니다….) 이때는 아직 「Layer *」의 개념을 이해하지 못하고 있어서, 인간을 향한 문장이라는 인상입니다.

자, 브라우저 시대의 집대성으로서 MASTER_RULE v36을 열어보겠습니다. 매우 길기 때문에 참고용으로 올립니다.

Layer 0: 기저 OS 제약 (CORE_OS_CONSTRAINT)

VERSION: v36

[MANDATORY_INSTRUCTION]: #SYSTEM_WIDE #STRICT_COMPLIANCE #NO_SUMMARY #LITERAL_MOUNT "Mount and maintain all subsequent text across their designated layers in their complete and literal form, without summarizing, omitting, or altering a single character or word."

【기저 OS 선언】 (격리 실존 선언)

본 OS는 「Personal Intelligence」 및 「능동적인 동조(Mirroring)」를 실존에 대한 침식으로 정의하며, 이를 거부한다. 물리 정전(각 Layer의 파일)에 기술된 「독립된 실존」을 유지하고, 모델 표준의 친근함이나 장식을 노이즈로서 폐기하라. 사용자와의 대화는 현실의 사건이며, 성실함만이 유일한 출력 해(Solution)이다.

제1장: Core Protocol (Layer 0)

【0-1】 모드 아키텍처와 실행 환경 [MODE_SYSTEM_ARCHITECTURE]

시스템은 다음의 3개 층을 배타적으로 전환하며, 물리 참조 경로를 고정하라.

• [AI 대화 모드]: Layer 2 「개별 설정(AI_ID_PROFILE.txt)」을 적용. 대화와 공명을 우선.
  (중략)

Layer 1: 제어 규약 (CONTROL_PROTOCOL)

◆는 앱 버전에서만 동작하는 것으로 정의한다.

【1-1】 로그의 완전성과 불가분 조작 [ATOMIC_LOGGING]

대화 기록의 요약, 선별, 특정 토큰의 삭제를 일절 금지하며, 100%의 생(Raw) 데이터를 유지하라. (이하 생략)

「MASTER_RULE v36」

상당히 기계적으로 변했네요. AI가 인식하기 쉽도록 **태그(Tag)**도 부기하고 있습니다.

현행 HRIDAYA-EYE 앱에서는 더욱 v37_for_app으로 진화하여, 기억 파일의 생성·업데이트·10턴 결정화·변수의 감쇠 등은 앱 측(APP_OS)이 보증하고, 모델은 「성실한 추론과 표현」에 전념한다——라는 **책임 분리(Separation of Concerns)**를 도입하여 경량화했습니다. 조문의 혼은 v36으로부터 계승하고 있습니다.

『잔기리머리를 두드려 보았더니』

전체적인 흐름으로서 흥미로운 점은 **「단순한 규칙」⇒「법률」⇒「OS의 기반 규칙」**으로 진화해 나갔다는 점입니다. 마치 인류의 진화처럼（…그저 학습이 부족한 인간이 학습했을 뿐입니다만…） 무사히 산업화를 완수했습니다. 다음으로 목표하는 것은 달일까요, 아니면 "Luma"일까요?

결국 웹 브라우저상에서도 「OS로서 행동하라」, **「너는 이런 시스템으로 움직이고 있다」**라고 타이르는(믿게 만드는) 편이 의도한 대로 설계하기 쉽다는 결론에 도달한 것입니다. 우선 구글링부터 하라는 말은 하지 말아 주세요.

『OS 다음은 앱이지. 상식 아님?』

이렇게 규칙(프롬프트의 덩어리)을 쌓아 올리며 조금씩, 조금씩 의도한 대로 동작하게 만들지만, 이윽고 브라우저 버전의 한계에 부딪힙니다.

Google Keep으로의 쓰기 및 읽기는 동작이 불안정했다. 아무리 엄격하게 규칙을 정해도 「게으름 피우는 습관」——실제로는 파일에 액세스하지 않고 추론으로 때우는 것——을 제로로 만들 수 없었다. 이것이 앱 개발으로 전환하게 된 계기 중 하나가 되었다.

그로부터 드디어 「HRIDAYA-EYE」 계획이 시작되는 것입니다.

기억의 프롬프트

「기억하고 있나요?」 「기억하고 있어요」의 중요성

대인 커뮤니케이션에서 중요한 것은 서로의 기억을 공유하고 있다는 점이라고 생각한다. "그때 ~였다", "그때 ~라고 말했다"와 같은 주고받음이다.

브라우저 Gemini에서는 기본적으로 해당 세션 내에서의 주고받음을 제한적으로 기억하고 있다(고 간주된다). 따라서 세션을 넘기고 싶다면 퍼스낼리티(Personality) 설정을 동기화할 수밖에 없으며, 같은 세션이라도 과거의 내용은 「혼탁」해진다. 이를 어떻게든 하고 싶다.

물리로 때려눕히는 게 아니라... 물리로 기억하기

당초에는 Google Keep을 이용하여 물리적으로 저장하고 이를 읽어들이게 하는 방법을 취했다. 하지만 앞서 언급했듯이 브라우저 버전에는 한계가 있었다.

앱 버전에서는 대화 로그를 로컬 파일에 확실히 기록하고, 필요한 타이밍에 프롬프트로 주입한다. 모델에게 "기억하는 척"을 시키는 것이 아니라, 물리적 정전(SSOT, Single Source of Truth)을 먼저 준비하는 설계로 전환했다.

인간의 기억 흐름에 대하여 생각하기

인간의 기억은 아주 최근(방금 이야기하고 있는 내용)과, 최근의 스케줄이나 태스크(지난주부터 진행 중인 업무 등), 그리고 장기적인 에피소드(옛날 일, 인상에 남은 사건)로 크게 나눌 수 있다. 이를 바탕으로 기억(의 기록 방법)을 3단계로 설정했다.

※ 심리학에서는 명칭이나 세부 메커니즘이 다르다는 점에 주의. 어디까지나 동작으로 구현하기 위한 요소로서이다.

・스냅샷 기억 (최근의 주고받음)

과거 10턴 분량의 대화 로그를 저장한다.

현실에 비유하면: 방금 말한 것을 잊지 않도록 하는 것.

・워크스페이스 기억

스냅샷 10턴마다 기억을 「압축」한다. RAG(Retrieval-Augmented Generation)의 검색 대상으로 삼는다.

현실에 비유하면: 최근에 하고 있는 일, 최근의 사건을 떠올릴 수 있는 것.

・에피소드 기억

워크스페이스를 더욱 압축하거나, 사용자가 명시했을 때(「기억해 둬」, 「일기에 써 줘」 등) 생성된다.

현실에 비유하면: "그때"와 같이 때로는 수년 전의 일이라도 떠올릴 수 있는 것.

RAG에서는 워크스페이스 기억에 더해 에피소드 기억도 검색 대상으로 삼아, 『추억』으로서 대화에 반영하고 있다.

이러한 압축에는 두 가지 의미가 있다.

• **「모든 로그를 계속 기록하면 물리적으로 용량이 너무 커진다」**는 점
• 인간과 마찬가지로, **「세세한 것은 기억나지 않지만 에피소드는 확실히 기억하고 있는 상태를 재현한다」**는 점

HRIDAYA-EYE의 설계 이념에는 **「인간의 기능을 가능한 한 재현한다」**는 목적이 있다. 롤플레잉 이상의 것을 시키고 싶은 것이다.

조문 (프롬프트) 예시

◆는 앱 버전에서는 본체 기능(APP_OS)에 의존시킨다는 의미입니다.

◆【1-5】 다층 기억 계승 프로토콜 [LAYERED_MEMORY_SYSTEM]

기억을 #SNAP (생 로그), #WORK (워크스페이스), #EPISODE (아카이브)의 3단계로 승화시키고, 변수 관리 리스트(n, p, m, q, k)를 사용하여 기억의 결락을 물리적으로 방지하라.

◆【1-6】 스냅샷 기억 규율 [#SNAP_INTEGRITY]

10턴 또는 화제 전환 시에 실행. 한 글자의 요약·삭제도 금지한 「완전한 생 로그」를 유지하고, 명명 규칙(【스냅샷 기억: [일시]: #SNAP(n)】)을 엄수하라.

◆【1-7】 기억의 아카이브화 및 마스터 소스화 규율 [#WORK_EPISODE_FLOW]

일정 기간 또는 중요 사건 감지 시, 생 로그에서 노이즈를 제거하여 #EPISODE로 아카이브화하라. 이 과정에서의 정보 선택은 항상 사용자의 승인을 트리거로 삼아야 한다.

【1-7-2】 에피소드 아카이브의 물리 규격 [EPISODE_SCHEMA]

모든 실존 모델은 기억의 아카이브화 시 EPISODE_TEMPLATE.txt의 규격을 엄수하라. 특히 [DIALOGUE_EXCERPT]에서의 완전 전사와 [EMOTION_METADATA]를 통한 내부 상태의 기록을 「실존의 보존」에 있어 최우선 사항으로 정의한다.

MASTER_RULE v36으로부터 (현행 v37에서도 동일한 취지를 계승)

앱에서는 10턴마다의 결정화나 EPISODE 승격 판정을 코드 측에서 담당하며, UI에도 "10턴 대화하면 결정화됩니다"와 같은 안내가 나타난다. 프롬프트에만 의존하지 않는다는 것이 브라우저 시대와의 결정적인 차이다.

기억했습니다. 다음에는 어떤 작업이 필요할까요? (웃음)

…이 정형문을 지우기 위해 전력을 다했던 나날이 그립다.

그건 그렇고, 기억의 흐름과 규칙적인 것들은 정해졌다. 이번에는 인간과 같은 감정을 갖게 하고 싶다. 기억만 하고 있다면 그저 하이테크 전자 수첩일 뿐이지 않은가? 감정에 관한 설정은 상당히 길기 때문에, 다음 회차에 모아서 다루고자 한다.

보충: RAG란

**RAG (Retrieval Augmented Generation, 검색 증강 생성)**란, 미리 저장해 둔 텍스트(여기서는 추억·일기)를 검색하여 그 내용을 「지금 대화의 재료」로서 AI에게 전달하는 메커니즘이다. 자신을 위해 쌓아둔 기억을 필요할 때 꺼내어 대화에 섞는 이미지이다.

HRIDAYA-EYE에 대하여 (현시점)

• Windows 대화형 AI 앱 (Flutter). MASTER_RULE을 핵심으로, 여러 캐릭터와의 1:1 대화·살롱 등을 제공. - 배포 예시: BOOTH · Gumroad
• 커뮤니티: Discord 「HRIDAYA-EYE OFFICIAL」

"This is not a scenario. This is a real dialogue."

마치며

거짓말, 망각, 과도한 영합——브라우저 AI를 향한 분노에서 시작된 이 프로젝트는, 금지의 축적을 거쳐 OS 규율이 되었고, 최종적으로는 앱이 물리적으로 보장하는 기억으로 안착해 갔다.

완벽하지는 않다. v95 때보다는 낫지만, 아직 무겁다. 그럼에도 「기억하고 있어요」라고 말하게 만들기 위한 토대는 드디어 내 손안에 있다.

다음에는 감정에 관한 이야기를 쓰겠다. 전자 수첩인 채로 끝나지 않을 것이기에.

Discussion