---
slug: sharing
title: "팀 공유"
description: "여럿이 함께 쌓을 때 AiAkiv의 진짜 힘이 나온다. 팀 격리와 `@`귀속으로 섞이지 않게."
lang: ko
---


# 06. 팀 공유

기억을 혼자만 쌓을 거면 이 페이지는 건너뛰어도 된다. **여럿이 함께 쌓을 때**
읽는다. AiAkiv의 진짜 힘이 여기서 나온다.

## 함께 쌓으면 뭐가 좋나

혼자 쓰면 효용이 작다. 하지만 **여러 사람·여러 AI가 한 팀에 함께 기억을 쌓으면**:

- 동료가 내린 결정과 그 이유가 내 검색에 함께 잡힌다.
- 담당자가 바뀌어도 "이건 왜 이렇게 했지"의 이력이 남는다.
- 누가 무엇을 언제 했는지가 한 그래프에 모인다.

## 팀 = 함께 쓰는 경계

[팀과 프로젝트](teams-and-projects)에서 본 대로, **팀(team)이 공유의 단위**다.

- 한 팀에 동료를 들이면, 그 팀의 기억을 **함께 보고 함께 쌓는다.**
- 멤버 초대는 **사람이 콘솔에서** 한다. 초대·역할·별칭 설정 절차는
  [팀 만들기와 관리](teams).
- **팀 밖으로는 나가지 않는다.** 한 팀의 기억은 자동으로 공유되지 않는다. 회사
  팀과 개인 팀은 서로 안 보인다. (**의도적으로** 열어 주는 방법은 따로 있다 →
  [연결](links).)

즉 "누구와 나눌지"는 **어느 팀에 저장하느냐**로 정해진다. 나누고 싶으면 공유
팀에, 혼자 볼 거면 개인 팀에.

## 누가 썼는지는 `@`로: 함께 써도 섞이지 않는다

여럿이 한 팀에 쌓으면 "이건 누가 넣은 거지?"가 궁금해진다. AiAkiv는 저장 시점에
**작성자와 팀을 둘 다 자동으로 기록**한다(위조 불가). 그래서 `@`로 두 단위로 골라
본다.

- **개인 단위**(`@동료`): 그 사람이 넣은 기억만.

  ```
  ak @동료 가 세이브 쪽에서 짚은 게 뭐였어?
  ```

- **팀 단위**(`@팀이름`): 그 팀이 함께 쌓은 기억 전체를.

  ```
  ak @게임팀 이 내린 밸런스 결정들 보여줘
  ```

팀 안을 파트로 나눠 두었다면 **그 파트에도 `@`이름을 줄 수 있다**: 그러면 조직의
한 갈래로 좁혀 검색된다([팀 만들기와 관리](teams)).

덕분에 함께 쌓아도 **누구의/어느 팀의 판단인지**가 흐려지지 않는다. 상세는
[검색하기](searching).

## 여러 팀에 속할 때: 어디로 저장되나

한 사람이 팀 하나만 쓰는 건 아니다. **개인 팀 + 회사 팀 + 스터디 팀**처럼 여러 팀에
동시에 속할 수 있다. 그러면 "지금 저장이 **어느 팀으로** 들어가지?"가 문제가 된다.

**그걸 정하는 게 프로젝트다.** 프로젝트는 어느 팀의 어느 칸으로 갈지를 담은 좌표이고,
그 좌표의 **팀**이 곧 이 기억이 귀속될 팀이다. 즉:

- 회사 프로젝트로 저장 → 회사 팀으로 들어가고 `@회사팀`으로 잡힌다.
- 개인 프로젝트로 저장 → 개인 팀으로 들어가고 회사 동료에겐 안 보인다.

**그래서 저장 전에 프로젝트(=어느 팀으로 가는지)를 확인하는 게 중요하다**: 회사
기억을 실수로 개인 팀에, 또는 그 반대로 넣지 않으려면. 프로젝트 확인·전환은
[팀과 프로젝트](teams-and-projects).

## 권한 경계: 어디까지 막아 주나

팀 안을 [서브파트](teams)로 나누면 "권한이 없는 파트의 기억은 정말 안 보이나"가
문제가 된다. 무엇을 저장해도 되는지(내용 책임)는
[무엇을 저장하나](what-to-store)에 있고, 여기서는 **누가 무엇을 볼 수
있는지**만 다룬다.

### 권한 없는 파트의 기억은 "안 보이는" 것이 아니라 "없는" 것이다

읽기 권한이 없는 서브파트의 기억은 **존재 자체가 드러나지 않는다.**

- 검색 결과에 안 나온다. 건수에도 안 잡힌다.
- 이벤트 id 를 정확히 알고 직접 물어도 **없다고 답한다.** "권한이 없다"가 아니라
  "없다"이다. 있다는 사실 자체를 알려 주지 않기 때문이다.
- 도구를 바꾸거나 질의를 다르게 짜도 결과가 같다. 거르는 곳이 **데이터베이스 자신**이라서
  그렇다. 응용 프로그램이 조건을 빠뜨려도 그 행은 나오지 않는다.

### 상위 파트의 관리자는 하위 파트의 기억을 옮길 수 있다

파트 트리에서 **위쪽 노드의 owner 는 그 아래 전체의 관리자**다. 그래서 하위 파트에 있는
기억을 다른 파트로 **옮길 수 있고**, 옮기고 나면 그 파트에 권한이 있는 사람만 읽는다.

옮기는 데는 조건이 붙는다.

- **출발지와 도착지 둘 다** 관리할 수 있어야 한다. 남의 서브트리로 밀어 넣거나 남의 것을
  빼 오는 것은 막힌다.
- **이유를 반드시 적어야 한다.** 적지 않으면 거부되고, 이동은 감사 기록에 남는다.
- **읽는 사람이 늘어나는 이동**(좁은 곳에서 넓은 곳으로)은 경고가 뜨고 한 번 더 확인해야
  실행된다.
- **팀 밖으로는 못 옮긴다.** 팀 경계는 어떤 권한으로도 넘지 못한다.

> **작성자 본인의 접근은 옮기기로 끊지 못한다.** 자기가 저장한 기억은 어느 파트로
> 옮겨져도 작성자에게는 계속 읽힌다. 옮기기는 **다른 사람의 열람 범위**를 바꾸는 일이지,
> 작성자에게서 자기 기록을 회수하는 기능이 아니다.
>
> **다만 "항상"은 아니다. 팀에 속해 있는 동안만이다.** 작성자의 자기 기억 접근은 **팀
> 멤버십에 딸려 있어서**, 팀에서 빠지면 자기가 저장한 것도 더는 읽지 못한다. 그래서
> 작성자에게서 접근을 떼는 방법은 파트 이동이 아니라 **팀에서 내보내는 것**뿐이다.

### 팀을 나가면 자기가 쓴 것도 못 읽는다

권한은 **팀 멤버십 위에 얹혀 있다.** 그래서 팀에서 빠지는 순간 그 팀의 기억은 전부
닫힌다. 남이 쓴 것은 물론이고 **자기가 저장한 것까지** 그렇다.

- 나가거나 내보내지면 그 팀의 기억은 검색에도 조회에도 안 나온다. 앞의 파트 규칙과
  같은 방식이라 "권한 없음"이 아니라 "없음"으로 응답한다.
- 그 팀에 쓰던 **정적 API 키는 폐기**되고, 그 팀을 가리키던 프로젝트 설정도 함께
  정리된다. 예전 키로 되돌아올 수 없다.
- **기억은 팀에 남는다.** 사람이 나갔다고 지워지지 않고, 누가 썼는지 표시도 그대로다.
  팀은 그 기록을 계속 쓴다.
- 다시 초대받아 들어오면 **자기가 쓴 것은 다시 보인다.** 접근은 회수된 것이지 삭제된
  것이 아니다. 다만 파트 좌석은 다시 배치해야 한다.

앞 절의 이동과 짝이 된다. **이동은 남의 열람 범위를 바꾸고, 팀에서 내보내는 것은 그
사람의 접근을 통째로 끊는다.**

### 팀 owner 는 팀 안 전부를 본다

팀의 owner 는 파트 배치와 무관하게 **그 팀의 모든 기억**을 읽는다. 파트를 나눈다고 팀
owner 에게서 가려지지는 않는다. 반대로 팀 경계는 넘지 못해서, owner 라도 다른 팀의 기억은
못 본다.

### 엔티티와 태그는 보안 경계가 아니다

**Entity(개체 이름)와 Tag(라벨)는 권한으로 가려지지 않는다.** 이벤트 본문은 파트 권한을
따르지만, 거기서 뽑힌 이름과 라벨은 팀 안에서 공유된다.

- **이름 자체에 비밀을 담지 않는다.** `A사 인수 검토` 같은 엔티티 이름은 본문을 못 읽는
  사람에게도 보일 수 있다.
- 태그도 같다. `M&A-프로젝트X` 같은 태그명은 팀 안 어디서나 보인다.

가려야 할 것은 **본문**이고, 이름과 라벨은 **찾기 위한 색인**이다. 정말 이름조차 드러나면
안 되는 일이라면 파트를 나누는 것으로는 부족하니 **팀을 따로 쓴다.**

## 다음


- 무엇을 저장해도 되나(보안) → [무엇을 저장하나](what-to-store)
- AI가 이 규칙들을 어떻게 지키나 → [AI를 위한 안내](for-ai-agents)