기억을 혼자만 쌓을 거면 이 페이지는 건너뛰어도 된다. 여럿이 함께 쌓을 때 읽는다. AiAkiv의 진짜 힘이 여기서 나온다.
함께 쌓으면 뭐가 좋나
혼자 쓰면 효용이 작다. 하지만 여러 사람·여러 AI가 한 팀에 함께 기억을 쌓으면:
- 동료가 내린 결정과 그 이유가 내 검색에 함께 잡힌다.
- 담당자가 바뀌어도 "이건 왜 이렇게 했지"의 이력이 남는다.
- 누가 무엇을 언제 했는지가 한 그래프에 모인다.
팀 = 함께 쓰는 경계
팀과 프로젝트에서 본 대로, 팀(team)이 공유의 단위다.
- 한 팀에 동료를 들이면, 그 팀의 기억을 함께 보고 함께 쌓는다.
- 멤버 초대는 사람이 콘솔에서 한다. 초대·역할·별칭 설정 절차는 팀 만들기와 관리.
- 팀 밖으로는 나가지 않는다. 한 팀의 기억은 자동으로 공유되지 않는다. 회사 팀과 개인 팀은 서로 안 보인다. (의도적으로 열어 주는 방법은 따로 있다 → 연결.)
즉 "누구와 나눌지"는 어느 팀에 저장하느냐로 정해진다. 나누고 싶으면 공유 팀에, 혼자 볼 거면 개인 팀에.
누가 썼는지는 @로: 함께 써도 섞이지 않는다
여럿이 한 팀에 쌓으면 "이건 누가 넣은 거지?"가 궁금해진다. AiAkiv는 저장 시점에
작성자와 팀을 둘 다 자동으로 기록한다(위조 불가). 그래서 @로 두 단위로 골라
본다.
-
개인 단위(
@동료): 그 사람이 넣은 기억만.ak @동료 가 세이브 쪽에서 짚은 게 뭐였어? -
팀 단위(
@팀이름): 그 팀이 함께 쌓은 기억 전체를.ak @게임팀 이 내린 밸런스 결정들 보여줘
팀 안을 파트로 나눠 두었다면 그 파트에도 @이름을 줄 수 있다: 그러면 조직의
한 갈래로 좁혀 검색된다(팀 만들기와 관리).
덕분에 함께 쌓아도 누구의/어느 팀의 판단인지가 흐려지지 않는다. 상세는 검색하기.
여러 팀에 속할 때: 어디로 저장되나
한 사람이 팀 하나만 쓰는 건 아니다. 개인 팀 + 회사 팀 + 스터디 팀처럼 여러 팀에 동시에 속할 수 있다. 그러면 "지금 저장이 어느 팀으로 들어가지?"가 문제가 된다.
그걸 정하는 게 프로젝트다. 프로젝트는 어느 팀의 어느 칸으로 갈지를 담은 좌표이고, 그 좌표의 팀이 곧 이 기억이 귀속될 팀이다. 즉:
- 회사 프로젝트로 저장 → 회사 팀으로 들어가고
@회사팀으로 잡힌다. - 개인 프로젝트로 저장 → 개인 팀으로 들어가고 회사 동료에겐 안 보인다.
그래서 저장 전에 프로젝트(=어느 팀으로 가는지)를 확인하는 게 중요하다: 회사 기억을 실수로 개인 팀에, 또는 그 반대로 넣지 않으려면. 프로젝트 확인·전환은 팀과 프로젝트.
권한 경계: 어디까지 막아 주나
팀 안을 서브파트로 나누면 "권한이 없는 파트의 기억은 정말 안 보이나"가 문제가 된다. 무엇을 저장해도 되는지(내용 책임)는 무엇을 저장하나에 있고, 여기서는 누가 무엇을 볼 수 있는지만 다룬다.
권한 없는 파트의 기억은 "안 보이는" 것이 아니라 "없는" 것이다
읽기 권한이 없는 서브파트의 기억은 존재 자체가 드러나지 않는다.
- 검색 결과에 안 나온다. 건수에도 안 잡힌다.
- 이벤트 id 를 정확히 알고 직접 물어도 없다고 답한다. "권한이 없다"가 아니라 "없다"이다. 있다는 사실 자체를 알려 주지 않기 때문이다.
- 도구를 바꾸거나 질의를 다르게 짜도 결과가 같다. 거르는 곳이 데이터베이스 자신이라서 그렇다. 응용 프로그램이 조건을 빠뜨려도 그 행은 나오지 않는다.
상위 파트의 관리자는 하위 파트의 기억을 옮길 수 있다
파트 트리에서 위쪽 노드의 owner 는 그 아래 전체의 관리자다. 그래서 하위 파트에 있는 기억을 다른 파트로 옮길 수 있고, 옮기고 나면 그 파트에 권한이 있는 사람만 읽는다.
옮기는 데는 조건이 붙는다.
- 출발지와 도착지 둘 다 관리할 수 있어야 한다. 남의 서브트리로 밀어 넣거나 남의 것을 빼 오는 것은 막힌다.
- 이유를 반드시 적어야 한다. 적지 않으면 거부되고, 이동은 감사 기록에 남는다.
- 읽는 사람이 늘어나는 이동(좁은 곳에서 넓은 곳으로)은 경고가 뜨고 한 번 더 확인해야 실행된다.
- 팀 밖으로는 못 옮긴다. 팀 경계는 어떤 권한으로도 넘지 못한다.
작성자 본인의 접근은 옮기기로 끊지 못한다. 자기가 저장한 기억은 어느 파트로 옮겨져도 작성자에게는 계속 읽힌다. 옮기기는 다른 사람의 열람 범위를 바꾸는 일이지, 작성자에게서 자기 기록을 회수하는 기능이 아니다.
다만 "항상"은 아니다. 팀에 속해 있는 동안만이다. 작성자의 자기 기억 접근은 팀 멤버십에 딸려 있어서, 팀에서 빠지면 자기가 저장한 것도 더는 읽지 못한다. 그래서 작성자에게서 접근을 떼는 방법은 파트 이동이 아니라 팀에서 내보내는 것뿐이다.
팀을 나가면 자기가 쓴 것도 못 읽는다
권한은 팀 멤버십 위에 얹혀 있다. 그래서 팀에서 빠지는 순간 그 팀의 기억은 전부 닫힌다. 남이 쓴 것은 물론이고 자기가 저장한 것까지 그렇다.
- 나가거나 내보내지면 그 팀의 기억은 검색에도 조회에도 안 나온다. 앞의 파트 규칙과 같은 방식이라 "권한 없음"이 아니라 "없음"으로 응답한다.
- 그 팀에 쓰던 정적 API 키는 폐기되고, 그 팀을 가리키던 프로젝트 설정도 함께 정리된다. 예전 키로 되돌아올 수 없다.
- 기억은 팀에 남는다. 사람이 나갔다고 지워지지 않고, 누가 썼는지 표시도 그대로다. 팀은 그 기록을 계속 쓴다.
- 다시 초대받아 들어오면 자기가 쓴 것은 다시 보인다. 접근은 회수된 것이지 삭제된 것이 아니다. 다만 파트 좌석은 다시 배치해야 한다.
앞 절의 이동과 짝이 된다. 이동은 남의 열람 범위를 바꾸고, 팀에서 내보내는 것은 그 사람의 접근을 통째로 끊는다.
팀 owner 는 팀 안 전부를 본다
팀의 owner 는 파트 배치와 무관하게 그 팀의 모든 기억을 읽는다. 파트를 나눈다고 팀 owner 에게서 가려지지는 않는다. 반대로 팀 경계는 넘지 못해서, owner 라도 다른 팀의 기억은 못 본다.
엔티티와 태그는 보안 경계가 아니다
Entity(개체 이름)와 Tag(라벨)는 권한으로 가려지지 않는다. 이벤트 본문은 파트 권한을 따르지만, 거기서 뽑힌 이름과 라벨은 팀 안에서 공유된다.
- 이름 자체에 비밀을 담지 않는다.
A사 인수 검토같은 엔티티 이름은 본문을 못 읽는 사람에게도 보일 수 있다. - 태그도 같다.
M&A-프로젝트X같은 태그명은 팀 안 어디서나 보인다.
가려야 할 것은 본문이고, 이름과 라벨은 찾기 위한 색인이다. 정말 이름조차 드러나면 안 되는 일이라면 파트를 나누는 것으로는 부족하니 팀을 따로 쓴다.