중요한 사람과의 마지막 미팅을 하기 전에, 회사의 CRM을 열어보셨나요?

아마 아닐 것입니다. 아마 채팅 기록을 훑어보셨을 겁니다.

영업용 CRM은 "이 고객이 파이프라인 (pipeline)의 어느 단계에 있는가?"라는 질문에는 답변을 잘합니다. 하지만 "이 사람과 어떤 대화를 나누다 멈췄는가?"라는 질문에는 대답을 잘 못하는 경우가 많습니다.

이러한 문제로 인해 우리는 guanxi-crm을 구축하게 되었습니다. 이는 무료이며, 오픈 소스(open-source)이고, 로컬 우선(local-first) 방식의 관계 기억 도구입니다. 이 도구는 읽기 가능한 마크다운 (Markdown)을 신뢰할 수 있는 단일 원천 (source of truth)으로 저장하고, 회상을 위해 재구축 가능한 SQLite 인덱스를 사용하며, AI 에이전트 (AI agents)에게 신원 확인 (identity resolution) 및 관계 이력을 위한 엄격한 CLI를 제공합니다.

이중 언어 ClawMama 블로그 버전을 읽거나, GitHub에서 프로젝트를 설치하거나, 바로 실행 가능한 개인 관계 관리 에이전트 (Personal Relationship Management Agent)를 사용할 수 있습니다.

핵심은 영업용 CRM을 대체하려는 것이 아닙니다. 기존의 기록들이 대개 평면화해 버리는 맥락 (context)을 보존하려는 것입니다. 즉, 두 사람이 어떻게 만났는지, 무엇이 변했는지, 무엇을 약속했는지, 어떤 채널이 가장 효과적인지, 그리고 다음 대화 전에 무엇을 기억해야 하는지 등을 보존하는 것입니다.

필드에 담기지 않는 것들

이 내용들을 기존의 CRM에 넣어보려고 시도해 보세요:

그는 최근에 이혼했으며 이에 대해 이야기하고 싶어 하지 않습니다.

그의 딸은 내년에 가오카오 (gaokao)를 치르며, 그는 불안해하고 있습니다.

그는 전화 통화를 싫어합니다. 대신 문자를 보내세요.

지난번에 대화했을 때, 그는 내가 추천한 책에 관심을 보였습니다.

어떤 필드에 이 내용들을 담아야 할까요?

대개 이 내용들은 메모 (Notes) 섹션으로 흘러 들어갑니다. 모든 CRM이 제공하지만, 나중에 아무도 주의 깊게 읽지 않는 비정형 (unstructured) 상자 말입니다.

정형화된 기록 (structured record)은 이름, 직장, 직함, 이메일 주소, 마지막 연락 날짜, 그리고 거래 가치 (deal value)를 유지합니다. 이러한 필드들은 영업 조직 (sales organization)에는 유용합니다. 하지만 대화가 시작되기 5분 전에는 유용성이 떨어집니다. 직함은 LinkedIn에 있고, 이메일은 주소록에 있습니다. 당신에게 필요한 것은 맥락 (context)입니다. 무엇이 변했는지, 지난 대화가 어디서 멈췄는지, 그리고 이번에는 무엇에 주의를 기울여야 하는지 말입니다.

필드 (Fields)는 역사적인 타협의 산물이었습니다

이것은 부주의한 설계가 아니었습니다. CRM이 등장했을 때, 구조화 (structure)는 실용적인 선택이었습니다.

데이터베이스 (Databases)에는 스키마 (schemas)가 필요했고, 리스트는 훑어볼 수 있어야 했습니다. 상하이에 기반을 두고 있으며, 3개월 동안 연락이 없었던 제조업 종사자를 모두 찾으려면 시스템에는 산업, 도시, 날짜를 위한 열 (columns)이 필요했습니다. 각 개인은 하나의 행 (row)이 되었습니다.

그러한 압축은 유용했지만, 손실이 있었습니다 (lossy). 가장 먼저 사라진 정보는 사전에 분류할 수 없는 모든 것이었습니다.

수십 년 동안 좋은 대안이 없었습니다. 팀들은 자유 형식 (free-form)의 회의록을 저장할 수는 있었지만, 수십만 개의 단어 중에서 관련 있는 한 문장을 찾아내는 것은 어려웠습니다. 비정형 (unstructured) 텍스트는 쓰기는 쉬웠지만 재사용하기는 어려웠습니다.

필드는 관계를 나타내는 이상적인 방식이 아니었습니다. 그것은 기술적 제약 하에서의 합리적인 설계였습니다.

그 제약이 사라지고 있습니다

대규모 언어 모델 (Large language models)은 자연어 기록 (natural-language records)을 기계가 읽을 수 있게 만듭니다.

다음 노트를 생각해 보십시오:

그는 회사가 해고를 진행 중이라고 말했다. 그는 자신의 직업은 안전하다고 생각하지만, 기분이 좋지 않아 보였다.

모델은 배경 사건을 그의 개인적인 상황과 구분하고, 불확실성을 보존하며, 다음 회의 전에 해당 노트를 표면화 (surface)할 수 있습니다.

이는 다른 아키텍처 (architecture)를 시사합니다. 관찰 내용을 자연어로 기록한 다음, 읽을 때 구조를 도출하는 방식입니다.

이것이 스키마가 사라진다는 의미는 아닙니다. 안정적인 ID, 날짜, 엔티티 유형 (entity types), 그리고 명시적인 참여자들은 여전히 중요합니다. 변화의 핵심은 더 좁습니다. 단지 기계가 읽을 수 있게 하려고 모든 인간적인 세부 사항을 고정된 분류 체계 (taxonomy)에 강제로 밀어 넣지 마십시오.

사람은 정적인 연락처 카드가 아닙니다

한 사람은 당신의 전 동료이자, 현재 고객이며, 친구의 배우자이자, 당신의 사이드 프로젝트에 투자한 투자자일 수 있습니다.

관련된 역할은 상황에 따라 변합니다. 실제 역할은 중첩되고 진화하며, 그 어떤 스키마 (schema) 설계자도 "내 사촌의 집주인"처럼 구체적인 범주까지 모두 예측할 수는 없습니다.

사람도 변합니다. 누군가 직장을 옮겼을 때 이전 회사를 덮어쓰는 것은 유용한 이력을 삭제하는 행위입니다. 6개월 동안 연락이 없었다는 사실 그 자체도 정보입니다. 식어버린 소통 패턴은 현재의 직함 (job-title) 필드 값보다 더 중요할 수 있습니다.

정체성 (Identity) 또한 마찬가지로 무질서합니다. WeChat에 있는 Zhang San이 LinkedIn의 San Zhang, 명함의 张叁, 혹은 전화번호로만 표현된 그 사람과 동일 인물일까요? 이메일 주소나 전화번호는 정체성의 증거일 뿐, 그 사람 자체는 아닙니다.

신뢰할 수 있는 시스템이라면 불확실한 증거를 확신에 찬 정체성 병합 (identity merge)으로 조용히 처리해서는 안 됩니다. 만약 Zhang Wei라는 이름을 가진 두 사람을 발견했다면, 시스템은 멈추고 당신이 누구를 의미하는지 물어야 합니다. 누락된 정보는 나중에 보완할 수 있지만, 잘못된 정체성 병합은 이후의 모든 기록을 조용히 오염시킵니다.

_guanxi_가 논의에 더하는 것

중국어 단어 guanxi (关系)는 흔히 "인맥 (connections)" 또는 "네트워킹 (networking)"으로 번역됩니다. 두 번역 모두 불완전합니다. 문맥에 따라 이는 공유된 역사, 신뢰, 사회적 역할, 호의, 의무, 그리고 각자가 상대방에게 합리적으로 요구할 수 있는 것에 대한 이해를 통해 시간이 흐르며 형성된 관계를 의미할 수 있습니다.

그렇다고 해서 중국의 관계가 신비롭거나 독특하게 거래 중심적이라는 뜻은 아닙니다. 모든 문화권은 단순한 연락처와 당신을 위해 반복적으로 나타나 준 사람을 구분합니다. 이 중국어 용어의 유용한 점은 축적된 관계적 맥락 (relational context)을 무시하기 어렵게 만든다는 데 있습니다.

이것이 바로 _guanxi_를 단순히 "누가 나를 도와줄 수 있는가"로 축소해서는 안 되는 이유입니다. 중요한 기억은 누군가가 한때 당신을 위해 소개를 해주었다는 사실일 수도 있습니다. 또한 당신이 문서를 보내기로 약속했거나, 그들의 부모님이 편찮으시거나, 혹은 어떤 주제는 그냥 두는 것이 낫다는 사실일 수도 있습니다. 호혜성 (Reciprocity)에는 접근 권한뿐만 아니라 배려와 책임도 포함됩니다.

에이전트 (Agent)를 위해 설계된 CRM이 될 때 변하는 것

전통적인 CRM과 에이전트 CRM은 경쟁할 필요가 없습니다. 영업 (Sales) 및 고객 성공 (Customer Success) 팀은 여전히 계정 (Accounts), 기회 (Opportunities), 활동 (Activities), 그리고 단계 (Stages)가 필요합니다. 에이전트 네이티브 (Agent-native) 시스템은 여기에 또 다른 계층을 추가합니다. 바로 워크플로 (Workflow) 뒤에 있는 사람과 맥락 (Context)입니다.

| 전통적인 CRM이 잘하는 것 |

에이전트 인터페이스는 단순히 성공 또는 실패를 반환하는 API가 아닙니다. 신원 확인 (Identity resolution)에 실패했을 때, 오류는 후보군과 안전한 다음 행동을 제공해야 합니다. 그렇지 않으면 에이전트는 가드레일 (Guardrail)을 우회하여 임의의 ID를 만들어낼 수 있습니다.

불완전한 정보도 수용되어야 합니다. "컨퍼런스에서 만난 사람, 공급망 (Supply chain) 분야 종사자, 성은 왕(Wang)일 수도 있음"과 같은 메모는 저장할 가치가 있습니다. 하지만 신원의 모호함 (Identity ambiguity)은 명확하게 오류를 발생시켜야 합니다.

우리는 사람에 대한 점수 매기기를 금지했습니다

우리는 제품 규칙을 채택했습니다: 개인에 대한 중요도, 우선순위, 또는 가치 점수를 매기지 않으며, "최고의 연락처"와 같은 리더보드 (Leaderboard)도 만들지 않습니다.

도구가 사용자에게 누군가가 유용한지 판단하도록 요청하는 순간, 기록은 직함, 고용주, 영향력, 그리고 접근 권한으로 채워지기 시작합니다. 진정한 맥락을 만드는 평범한 세부 사항들은 사라집니다. 관찰된 사실에 따라 정렬하는 것은 다릅니다. 최근에 연락이 닿지 않은 사람이 누구인지 묻는 것은 합리적일 수 있습니다. 그 답변은 기록을 설명하는 것이지, 인간의 가치를 측정한다고 주장하는 것이 아니기 때문입니다.

관계 메모리(Relationship memory)에는 가족 행사, 건강 문제, 직업 변경, 사적인 대화와 같은 민감한 정보도 포함됩니다. 데이터는 이식 가능(portable)해야 하며, 검사 가능(inspectable)해야 하고, 의도적인 개인정보 보호 경계(privacy boundaries)와 함께 저장되어야 합니다.

구현 사례: 진실로서의 Markdown, 회상으로서의 SQLite

guanxi-crm은 의도적으로 겸손하게 설계되었습니다. 애플리케이션 서버나 전용 그래픽 사용자 인터페이스(GUI)가 없는 단일 사용자용, 오프라인, 헤드리스 CLI(headless CLI)입니다.

이 시스템의 권위 있는 데이터는 UTF-8 Markdown에 저장됩니다. SQLite는 해당 파일들로부터 재구축할 수 있는 일회성 회상 인덱스(recall index) 역할을 합니다. 사람들은 고유한 ID를 가지며, 이름, 별칭, 이메일 주소, 전화번호는 기본 키(primary keys)가 아닌 신원 증거(identity evidence)로 남습니다. 공유 식별자(Shared identifiers)나 중복된 이름은 자동으로 해결되지 않고 모호한 상태로 남을 수 있습니다.

상호작용(Interactions)은 날짜가 기록된 별도의 레코드입니다. 참여자는 반드시 명시적이어야 하며, 자유 형식의 텍스트(free-form text) 내에 언급되었다고 해서 자동으로 참여자가 되지는 않습니다. 또한 이 저장소에는 에이전트가 쓰기 작업을 수행하기 전에 권위 있는 ID를 확인하고, 신원이 모호할 경우 명확화를 위해 멈추도록 지시하는 relationship-memory 스킬(Skill)이 포함되어 있습니다.

사용자는 Obsidian에서 Markdown, 백링크(backlinks), 그래프 뷰(graph view)를 포함하여 동일한 볼트(vault)를 직접 검사할 수 있습니다. CLI와 스킬을 직접 설치하고 싶지 않다면, ClawMama가 이 워크플로우를 즉시 사용 가능한 개인 관계 관리 에이전트 (Personal Relationship Management Agent)로 패키징하여 제공합니다.

하나의 유용한 테스트

많은 CRM 필드는 기계가 인간의 언어를 읽을 수 없었던 세상을 위해 설계되었습니다. 그 세상은 변하고 있습니다.

관계 메모리 시스템에는 거창한 지표가 필요하지 않습니다. 질문 하나면 충분합니다:

두 달 뒤, 누군가를 만나기 전에, 당신이 잊어버렸지만 기억해야만 했던 한 가지를 이 시스템이 떠올려 줄 수 있습니까?

만약 그렇지 못하다면, 그것은 여전히 그저 더 나은 주소록일 뿐입니다.