← 인프라·격리

개인·팀·전사 3단 승격을 설계하고 팀 단계에서 서버를 잃었다

검색 본체보다 그 본체를 만드는 과정의 기억을 먼저 세웠고, 팀 배포를 위해 권한 게이트웨이를 경유하는 번들 여섯 벌을 만들어 검증한 뒤 서버 유실로 승격 단계를 잃은 기록

목차
  1. 문제
  2. 3단으로 올리는 경로를 먼저 그렸다
  3. 팀 배포를 막은 것은 권한이었다
  4. 잃은 것의 성숙도를 문서에 적었다
  5. 결론
  6. 한계·재검토 트리거
  7. 참고

메모리를 개인에서 팀으로, 팀에서 전사로 올리는 3단 승격 경로를 설계했다.
팀 단계까지 현업 검증을 끝냈고 전사 확장을 준비하던 2026년 6월에 백엔드 서버를 잃었다.
데이터는 돌아오지 않았다.
그때 그린 계층 하나는 지금도 쓰고 있다.

문제

로드맵에는 사내 통합 플랫폼의 RAG 모듈이 올라 있었고 착수는 몇 달 뒤였다.
그 모듈 하나에 코퍼스 구성과 청킹, 접근 제어, 인용, 재색인, 평가가 각각 별도 설계로 붙는다.
정작 걸린 것은 착수까지 남은 몇 달이었다.
그 사이에 갈린 판단과 돌려보고 버린 실험과 운영에서 걸린 함정은 적히지 않으면 사람 머리에만 남는다.
사람이 바뀌면 그대로 사라진다.

그래서 검색 본체보다 그 본체를 만드는 과정의 기억을 먼저 세웠다.
오픈소스 에이전트 메모리 Hindsight를 개발팀의 작업 기억과 결정 이력 레이어로 선제 도입했다.
RAG 모듈이 사내 문서를 검색하는 본체라면 이쪽은 그 본체를 만든 근거를 보관하는 메타 레이어다.
순서를 이렇게 잡은 이유는 하나다.
근거가 휘발된 뒤에 본체를 만들면 무엇을 왜 그렇게 정했는지 다시 세울 방법이 없다.

3단으로 올리는 경로를 먼저 그렸다

승격 경로는 세 단이었다.
개인 메모리와 팀 메모리와 전사 메모리다.
각자 자기 기록을 남기는 것이 1단이다.
그중 팀이 공유할 것을 올리면 2단이고, 조직 전체가 참조할 것을 다시 올리면 3단이다.

단이 올라갈수록 넓어지는 것은 기록의 양이 아니라 그 기록을 볼 수 있는 사람의 범위다.
나만 볼 때와 옆자리가 볼 때는 같은 기록에 걸리는 조건이 다르다.
승격은 저장 문제로 시작해서 권한 문제로 굴러떨어진다.

단계도달 상태
개인 메모리현업 검증 완료
팀 메모리 승격현업 검증 완료
전사 메모리 승격설계만 있음. 확장 준비 단계에서 유실

세 단 중 두 단이 현업 검증을 통과했다.
셋째 단은 설계에서 멈췄다.
검증의 기준은 실제 업무였다.
팀이 그 도구로 기록을 남기고 나중에 다시 꺼내 쓰는 데까지 갔다.
이 표가 나중에 인수인계 문서에 그대로 들어간다.

팀 배포를 막은 것은 권한이었다

팀에 내보내려던 첫 도구는 사내 서버에 직접 붙는 방식이었다.
붙으면 뱅크가 통째로 보였다.
누가 무엇을 기록했는지가 전부 열리는 도구를 팀원에게 나눠 줄 수는 없다.
하루치 기록에는 아직 정리되지 않은 판단과 실패한 시도가 섞인다.
그게 옆자리에 그대로 열리면 기록을 남기는 손이 먼저 조심해진다.
기능은 다 돌아갔고 구조 자체가 배포를 허락하지 않았다.

이 상태를 그때 판단대로 적어 둔 문장이 당시 일일업무보고에 남아 있다.

기존 일일보고 도구는 사내 서버에 직접 접속하는 방식이라 전체 메모리가 노출될 수 있어 팀원 배포에 부적합했습니다. 팀원 한 사람이 본인 기록만 안전하게 조회하도록 권한 게이트웨이를 경유하는 버전을 새로 작성하고 검증했습니다.

새로 만든 배포본은 뱅크에 직접 붙지 않는다.
앞에 선 권한 게이트웨이를 지나고, 그 문이 요청자의 범위를 잘라 본인 기록만 돌려준다.
배포 형식은 MCP(모델 컨텍스트 프로토콜) 번들이었다.
에이전트에 외부 도구를 붙이는 공개 규격이고, 번들 하나가 설치되면 그 사람의 조회 도구 한 벌이 된다.
역할 세 종류와 사용자 조합으로 여섯 벌이 패키징됐다.
같은 시기의 종단 검증분이 함께 남아 있어 그 여섯 벌이 실제로 돌았다는 것까지 확인된다.

이 배포본이 바꾼 것은 조회가 지나는 경로다.
직접 접속 방식에서는 무엇을 보여줄지가 도구 안쪽 코드에 있었고, 도구를 받은 사람이 그 코드를 고치면 범위도 같이 열렸다.
게이트웨이를 경유하면 범위 판정이 도구 바깥으로 나간다.
받은 사람이 무엇을 하든 문이 잘라 준 만큼만 돌아온다.
팀에 무언가를 배포한다는 것은 이 판정을 어느 쪽에 두느냐를 정하는 일이었다.

잃은 것의 성숙도를 문서에 적었다

2026년 6월에 백엔드 장비가 교체되면서 팀 메모리가 서 있던 자리가 사라졌다.
그날 인수인계 문서에 먼저 적은 것은 설계의 도달 지점이었다.
3단 승격 구조를 쓰고, 팀 단계까지 현업 검증을 마쳤으며 전사 확장 준비 단계에서 유실됐다고 명시했다.
문서 세 종을 모두 같은 문장으로 갱신했다.
사라진 것이 실험 단계의 시제품이었는지 검증을 통과한 시스템이었는지는 그때 적어 두지 않으면 나중에 아무도 가리지 못한다.

재발방지 항목은 세 개를 넣었고 전부 중립 서술로 썼다.
서버와 네트워크 담당자를 지정하고 서버를 바꾸기 전에 담당자 확인을 받는다는 규칙이 첫째다.
사전 협의 없는 장비 교체가 팀 메모리 유실로 이어졌다는 사례를 근거로 달면서 주체는 표기하지 않았다.
시점과 주체는 내 기록에 남기고 회사에 넘기는 문서에는 규칙만 남겼다.

근거를 첨부하면서 그 근거의 구멍도 같이 표시했다.
인프라 교체 완료보고서를 붙였는데 재발방지 항목이 지목한 전기 배선 구절이 그 보고서에는 없었다.
그래서 출처 문서를 더 확인해야 한다고 같은 자리에 적어 두었다.
자기를 방어하는 문서일수록 근거의 빈 곳을 먼저 표시해 두는 편이 낫다.
남이 그 구멍을 먼저 찾으면 문서 전체가 같이 의심받는다.

이 세 가지를 묶는 규칙은 하나였다.
사실을 지우지도 않고 비난을 남기지도 않는다.
설계가 어디까지 갔는지는 문서로 남겼다.
왜 멈췄는지는 재발방지 규칙 문장으로 옮겼고 누가 무엇을 했는지는 넘기는 쪽에서 뺐다.

책임 소재를 가릴 자료는 내 기록에 확보해 두되 그것을 무기로 쓰지 않았다.
같은 사건을 두고 남길 수 있는 문서는 여러 종류다.
나중까지 쓸모가 남는 것은 규칙으로 번역된 쪽이다.

결론

서버와 함께 잃은 것은 승격 단계다.
데이터는 복구되지 않았고 설계는 남았다.

지금 개인 환경에서 쓰는 구조가 그 증거다.
뱅크 앞에 게이트웨이가 서고 기록의 형식과 실패 판정을 그 문이 직접 거절한다.
권한 때문에 세운 문이 지금은 규율을 강제하는 문으로 쓰인다.
2026년 6월에 사라진 것은 팀 뱅크의 데이터이고, 팀 배포를 위해 그린 계층은 이 구조의 직계 선행 설계로 남았다.

한계·재검토 트리거

2026-09 기준 / 재검토 트리거: 유실된 팀 뱅크의 데이터가 복구됐다는 사실이 확인되거나, 전사 단계까지 승격 경로를 실제로 굴린 사례를 다시 확보하면 이 글의 판정을 다시 연다.

참고