Perplexity는 2026년 10월 12일 공식 엔지니어링 블로그를 통해 Perplexity Computer에 이미 출시된 Projects 기능의 바탕이 일반 공유 폴더가 아니라 사람과 에이전트의 협업을 위해 만든 Git 저장소 시스템이라고 밝혔다. 프로젝트마다 Git 저장소 하나가 대응하고, 사용자의 대화형 에이전트, 예약 실행 에이전트, 다른 협업자의 에이전트가 모두 같은 저장소에 변경을 커밋한다. 새 모델 발표는 아니지만, 에이전트가 장기 작업을 맡기 시작하면 피할 수 없는 문제, 즉 결과물을 어디에 보관하고 누가 무엇을 바꿨으며 잘못된 변경을 어떻게 되돌릴 것인가를 정면으로 다룬 글이다.
하필 Git인 이유
Perplexity의 이유는 실무적이다. 몇 달에 걸친 협업에는 세 가지가 필요하다. 결과물이 세션을 넘어 남아야 하고 샌드박스가 사라질 때 함께 사라져서는 안 된다. 여러 사람과 여러 에이전트가 동시에 편집해도 서로의 변경을 조용히 덮어쓰지 않아야 한다. 모든 변경을 추적하고 되돌릴 수 있어야 한다. 이는 Git가 수십 년간 풀어 온 문제와 정확히 같다. 차이는 기존 코드 호스팅이 사람을 위해 설계됐고, 검토 화면과 브랜치 관리, 알림은 에이전트에게 불필요하다는 점이다. 그래서 Perplexity는 Git의 저장과 검증 장치만 남겼다. 에이전트는 사람의 승인을 기다리지 않고, Git 서비스가 저장소 계약에 따라 제출을 기계적으로 검사해 통과한 것만 최신 버전으로 받아들인다. 두 에이전트가 충돌하면 낡은 버전을 바탕으로 한 뒤쪽 제출은 명시적으로 거부되고, 해당 에이전트는 새 버전 위에 자기 변경을 다시 얹어 재제출한다. 회사 측 설명으로는 운영 환경에서 이런 거부는 전체 제출의 2% 미만이고, 제출 지연 중앙값은 1.7초 미만, 99백분위도 8초 미만이다.
다섯 부품의 역할 분담
시스템은 다섯 부분으로 이뤄진다. 각 에이전트는 독립 샌드박스에서 일하고, 샌드박스 안의 명령줄 도구가 저장소를 로컬에 동기화하며 의미 있는 작업 단위마다 결과물을 커밋한다. 컨트롤 플레인은 저장소 위치를 찾고 단기 자격 증명만 발급할 뿐 데이터 자체는 건드리지 않는다. Git 서비스는 클론, 가져오기, 제출 접수 같은 Git 고유 작업을 수행하고 어떤 제출을 최신 커밋으로 삼을지 결정하며, 상태는 DynamoDB에 기록된다. 저장소 데이터 자체는 AWS S3Files가 제공하는 공유 파일 시스템에 놓여 서비스 복제본은 상태를 갖지 않고 교체 가능하게 유지된다. 커밋이 받아들여지면 백그라운드 작업이 변경된 문서에서 텍스트와 메타데이터를 추출해, 다음에 프로젝트를 열 때 에이전트가 바로 검색할 수 있게 한다. 대역폭을 아끼기 위해 샌드박스는 처음부터 저장소 전체를 내려받지 않는다. 큰 파일은 먼저 Git LFS 포인터로 나타나고, 에이전트는 추출된 텍스트를 읽은 뒤 필요할 때만 원본을 가져온다. FUSE 기반 가상 파일 시스템도 시도했지만 파일 작업이 많은 부하에서 약 400배 느려 포기했다고 한다. 기록도 무한히 늘지 않는다. 보관 커밋이 기준을 넘으면 오래된 기록은 하나의 시작 스냅샷으로 압축된다.
숫자가 보여 주는 것과 주장의 한계
Perplexity가 공개한 내부 테스트는 이 설계의 지향을 잘 보여 준다. 같은 문서 뭉치를 대상으로 한 금융 질문 150개에서 파일을 탐색하며 답한 에이전트는 올바른 문서 검색에서 0.867, 정답에서 0.627을 기록해 의미 검색의 약 0.39와 0.37을 앞섰다. 정답 점수는 약 1.7배, 지연은 약 25% 낮았다. 이미 열었던 프로젝트에 다시 붙는 데는 약 2.9초, 처음에는 약 8초가 걸린다. Computer의 장기 기억인 Brain도 같은 저장소 기반 위에 있으며, 지식 페이지는 프로젝트 파일과 경합하지 않도록 별도 저장소에 커밋으로 저장된다. 다만 주의할 점이 있다. 이 숫자는 전부 Perplexity의 자체 측정으로 제3자 재현이 없고, 테스트 문서도 회사가 고른 것이다. 지금 단계에서는 설계의 자기 증명으로 받아들여야지 업계의 결론으로 볼 수는 없다. 그래도 방향 자체는 주목할 만하다. 에이전트가 일회성 답변에서 몇 달 단위 협업으로 이동하면서 경쟁 지점은 모델 자체에서 작업 공간의 지속성과 감사 가능성으로 옮겨 가고 있다. 수십 년 전 인간의 협업을 위해 발명된 버전 관리가 에이전트 협업이 빌릴 수 있는 가장 빠른 토대라는 판단이며, 이 층을 먼저 안정시킨 쪽의 에이전트가 더 긴 일을 맡게 될 가능성이 크다.
