연결: 다른 팀의 메모리를 읽기

AiAkiv의 메모리는 서로 완전히 나뉘어 있다. 옆 팀 메모리는 검색해도 아예 나오지 않는다. 일부러 그렇게 만들었다. 남의 기억이 새어 나가면 안 되니까.

그런데 실제 일은 메모리 하나로 끝나지 않는다. 개인 메모리의 아이디어를 회사 프로젝트에서 꺼내 쓰고 싶고, 본사와 협력사가 같은 고객을 상대하고, 컨설턴트는 쌓아온 사례를 고객사에 못 가져간다. 저쪽에 답이 있는 걸 아는데 꺼낼 방법이 없는 상황이다. 그걸 푸는 것이 연결이다.

한 줄 요약. 두 메모리를 엔티티 별칭으로 연결한다. 단, 연결은 단방향이다. 그리고 메모리 내용이 업데이트되었다면 별칭도 업데이트해야 한다.

연결이란 무엇인가

두 팀이 합의한 읽기 권한 한 줄이다. 성질이 셋 있다.

• 사본이 없다. 데이터를 넘겨받는 게 아니라 그때그때 들여다본다. 원본이 바뀌면 바로 보이고, 끊으면 사라진다.
• 내 저장 자리를 건드리지 않는다. 프로젝트를 바꾸는 게 아니다. 도구를 부를 때 연결을 지정해 상대 쪽만 읽는다. 그 대화에서 ak 저장해를 하면 평소처럼 내 Main으로 들어간다.
• 단방향이다. 수락하면 우리가 상대를 읽을 뿐, 우리 기억이 상대에게 열리지는 않는다. 반대로도 열려면 연결을 하나 더 맺는다.

가져오기와 무엇이 다른가

공개 메모리와 묶는 것도 의미가 있다

공개 메모리는 원래 누구나 읽는다. 그런데 읽을 수 있는 것과 내 질문에서 나오는 것은 다르다. 내 기억과 이어져 있지 않으면 내가 물었을 때 안 나온다. 그래서 공개 메모리와 연결을 맺고 별칭을 이어두는 것이 의미가 있다.

콘솔에서 맺고 관리하기

콘솔 → 팀 → 연결이다. 팀 소유자만 보이는 화면이다. 메모리를 밖으로 여는 일이라 내부 권한과 같이 볼 수 없다.

목록은 두 묶음으로 갈린다. 성질이 반대인 것들이라 섞어 두면 상태 칸만 다른 같은 것처럼 보인다.

• 우리가 읽는 연결 — 상대 팀 기억을 우리가 읽는 쪽이다. 상대 팀 · 상태 · 계약 · 지금 읽기 · 만료 다섯 열이 뜬다. 대화 중 도구가 쓰는 것이 이쪽이다.
• 우리가 제공한 연결 — 우리 기억을 상대에게 여는 쪽이다. 우리가 읽을 것은 없으므로 지금 읽기 열이 아예 없다. 정지·해제·별칭은 여기서 한다.

어느 쪽이든 상세를 누르면 상세·별칭 두 탭이 열린다.

맺기: 제안하고 수락한다

한쪽이 초대를 발급하고 상대 소유자가 수락하면 살아난다. 수락 창이 방향을 분명히 알려준다.

수락하면 우리가 〇〇 팀의 기억을 읽게 됩니다. 한 방향입니다: 우리 기억이 상대에게 열리지는 않습니다. 상대가 우리 기억을 읽으려면 우리가 초대를 발급해야 합니다.

거절하면 그 제안은 종결된다. 다시 맺으려면 새 제안이 필요하다.

끊기: 한쪽이 혼자 끊는다

일시 정지는 진행 중인 읽기까지 즉시 끊는다. 그리고 정지를 건 팀만 재개할 수 있다.

맺을 때는 둘의 합의가 필요하고 끊을 때는 하나면 된다. 일부러 이렇게 만들었다. 합의가 있어야 끊을 수 있으면, 상대가 답을 안 할 때 갇혀버린다.

상세 탭: ‘지금 읽기’ 조건 5개

읽기가 되는지는 다섯 가지가 모두 맞아야 한다. 화면이 체크리스트로 보여준다.

하나라도 어긋나면 도구가 막힌다. 목록의 지금 읽기 열과 같은 판정이니, 안 읽힐 때는 여기부터 본다. 재동의가 필요하면 우리 승인·상대 승인 중 누가 안 했는지도 표시된다.

우리가 제공한 연결에서는 넷만 뜬다. 제목이 상대가 읽기 위한 조건 으로 바뀌고 마지막 줄(이 방향이 열려 있음)이 빠진다. 그 줄은 우리가 읽는 방향 얘기라, 멀쩡한 연결에 빨간 표시가 찍히기 때문이다. 실제 방향은 바로 아래 읽기 방향 이 보여준다.

표시명은 계약 당시의 기록이다. 이후 상대 팀이 이름을 바꿔도 반영되지 않는다. 화면의 세대 숫자는 이 연결이 몇 번째로 맺어진 것인지를 뜻한다.

계약이 언제 어떻게 바뀌었는지는 팀 → 연결 이력에서 본다. 누가 맺고 바꾸고 끊었는지가 양쪽 모두에게 남는다. 내 접근이 끊겼는데 당사자가 그걸 못 보는 건 말이 안 되기 때문이다.

별칭

별칭이 하는 일 (권한과는 다르다)

두 팀의 엔티티는 서로 다른 id 공간에 있다. 같은 것을 두고도 우리 메모리와 상대 메모리가 부르는 이름이 다르면, 사람은 같은 거라고 알아도 시스템은 모른다.

별칭은 그 둘을 “같은 것”이라고 알려 주는 표시다. 탐색은 이 표시를 따라 두 엔티티를 오간다.

우리 메모리의 이름   ←── 같은 것 ──→   상대 메모리의 이름

여기서 제일 많이 오해하는 것: 별칭은 권한이 아니다. 연결된 팀의 기억은 별칭과 상관없이 이미 읽을 수 있다. 아래 표가 그 경계다.

즉 별칭이 하나도 없어도 상대를 찾을 수는 있다. 별칭이 필요한 것은 내 기억에서 출발해 상대까지 건너갔다 오는 쪽이다. 연결의 값어치는 여기에 있다.

이어야 할 것과 끊어야 할 것

별칭 탭에 우리 ↔ 상대 쌍이 줄줄이 나온다. 출처는 자동 탐색과 사람이 지정 두 가지다.

• 이름만 같고 다른 것이면 제외로 끊는다. 잘못 이어두면 두 기억 사이에 틀린 연결이 생기고, 그게 답변에 섞이면 나중에 찾기 어렵다.
• 잘못 끊었으면 다시 잇기, 판단을 미루려면 후보로 되돌린다.

시스템이 후보를 찾아주긴 하지만 최종 확인은 사람이 한다. 이름이 비슷하다고 같은 것이 아니기 때문이다.

⚠ 새 내용을 저장했으면 다시 이어야 한다

별칭은 저절로 유지되지 않는다.

• 새로 생긴 엔티티는 자동으로 안 이어진다. 저장을 한 뒤에는 별칭 탭에서 이름 같은 것 잇기 를 다시 눌러야 한다. 누르면 이름이 같은 N쌍 중 M쌍을 새로 이었습니다 로 결과가 뜬다. 결과가 잘렸다고 나오면 다시 실행하면 이어서 찾는다.
• 엔티티가 병합되면 별칭이 끊어진다. 끝점 엔티티가 병합으로 흡수되면 그 별칭은 끊김 이 되어 더는 동작하지 않는다. 사람이 끊은 게 아니다.

그래서 주기적으로 다시 잇는 것이 좋다. 연결은 살아 있는데 교차 탐색 결과만 빈약해졌다면 십중팔구 이쪽이다.

실제로 읽기: 도구 5종

읽는 것은 화면이 아니라 대화 중 도구가 한다. 콘솔은 맺고 끊고 별칭을 손보는 곳이다.

list_partner_links                     어떤 연결이 있고 지금 쓸 수 있나(usable)
  ├ search_partner_memory(문장, link_id)      상대 메모리를 직접 검색
  ├ find_partner_memory_connections(link_id, 문장)       내 기억에서 출발해 별칭을 따라 교차 탐색
  ├ query_partner_memory_graph(link_id, 질의) 두 팀에 걸친 그래프 질의
  └ get_partner_memory_content          상대 기록의 본문을 읽기

list_partner_links 부터 부르는 게 좋다. usable 이 지금 답이 나올 연결을 알려주고, 안 되는 것은 blocked_reason 이 무엇을 고쳐야 하는지를 가리킨다.

우리가 제공한 연결은 이 목록에 아예 안 나온다. 연결은 단방향이라 초대를 발급한 쪽에는 읽을 것이 없고, 그래서 고칠 것도 없다. 몇 개가 있는지만 provided_link_count 로 알려준다 — 관리는 콘솔의 우리가 제공한 연결 묶음에서 한다. 그 id 를 그래도 도구에 넘기면 principal_not_active 로 거부된다.

교차 탐색이 알려주는 것

find_partner_memory_connections 는 결과마다 어느 쪽 것인지(side)를 표시하고, 별칭에는 양쪽에서 얼마나 흔한 말인지를 함께 싣는다. “우리 쪽 1건, 저쪽 109건” 이면 나에겐 스쳐 가는 언급이 저쪽엔 중심 주제라는 뜻이다. 그 숫자 자체가 답이 되기도 한다.

진입은 내 쪽에서만 일어나므로, 상대 쪽에서 아무것도 안 나왔다고 해서 “없다”는 뜻은 아니다. 별칭이 없어서 못 건너간 것일 수 있다.

안 되는 것 · 알아둘 것

• 연결로 들어가 저장할 수는 없다. 연결은 읽기 능력이다.
• 끊으면 즉시 끊긴다. 보고 있던 중이어도 그렇다. 읽는 도중에 해지되면 잘린 답이 아니라 명시적인 오류로 중단된다. 반쪽짜리 답을 받는 일은 없다.
• 읽은 사람의 기억까지 막지는 못한다. 상대가 화면으로 본 내용을 자기 메모에 옮겨 적는 것은 막을 수 없다. 연결이 막는 것은 시스템이 통째로 복사해 가는 것이지 사람의 머릿속이 아니다. 그래서 누구와 맺을지는 여전히 신뢰의 문제다.
• 상대 결과는 상대 것으로 다뤄야 한다. AI가 두 기억을 섞어 답할 때, 어느 쪽에서 온 말인지 구분해 두지 않으면 나중에 되짚기 어렵다.

시나리오: 컨설턴트와 고객사

컨설턴트 A가 고객사 B에 들어간다. B는 자기 메모리를 3개월간 A에게 열기로 한다.

1. 맺기: B 소유자가 A에게 초대를 발급하고, A 소유자가 수락한다. 방향은 B→A 한쪽, 기한은 3개월.
2. 별칭 잇기: A가 별칭 탭에서 이름 같은 것 잇기를 누른다. B의 “결제 모듈”과 A의 “페이먼트 게이트웨이”가 후보로 뜨면 사람이 확인해서 잇고, 이름만 같은 것은 제외 한다.
3. 확인: list_partner_links 로 usable 인지 본다.
4. 쓰기: A가 묻는다. “결제 모듈 재시도 정책, 우리가 전에 비슷한 걸 한 적 있나?” 탐색은 A의 기억에서 출발해 예전 사례를 잡고, “페이먼트 게이트웨이” 별칭을 따라 B의 결제 이슈를 집어 온다. 별칭 옆에 우리 2건 / 저쪽 87건이 찍힌다. A에겐 두 번 나온 주제가 B에겐 중심 주제다.
5. 본문 읽기: 상대 쪽 결과는 get_partner_memory_content 로 편다. 이 동안 A의 저장 자리는 그대로여서, 정리해서 ak 저장해 하면 A의 Main으로 들어간다.
6. 끝: 3개월이 지나면 자동으로 닫힌다. 그전에도 B가 혼자 끊을 수 있다.

관련 문서

• 팀·프로젝트와 저장 대상 → 팀과 프로젝트
• 한 팀 안에서 나눠 보기(서브파트·역할) → 팀 만들기와 관리
• 콘솔 메뉴 전반 → 콘솔 안내
• 무엇을 저장해도 되나 → 무엇을 저장하나