AI 에이전트 공유 작업공간: 6칸 artifact 인수 계약

핵심 요약

• 공유 작업공간은 편리한 공용 폴더가 아니라 작업별 책임 경계로 다루셔야 합니다.
• scratch → handoff → approved 세 경로를 나누면, 초안과 검증된 산출물이 섞이는 일을 줄일 수 있습니다.
• 승격에는 파일 해시, 생성 주체, 입력 데이터 분류, 검증 결과처럼 다시 확인할 수 있는 근거가 필요합니다.
• 종료 단계의 revoke, TTL, 보존 예외, 삭제 기록까지 정해야 고아 파일과 과도한 권한이 남지 않습니다.

왜 파일 경계가 먼저일까요?

여러 에이전트가 코드를 만들고, 표를 갱신하고, 결과 이미지를 저장하는 환경에서는 파일 하나가 다음 작업의 입력이 되기 쉽습니다. 이때 모든 작업자에게 하나의 쓰기 가능한 폴더를 주면, 어느 파일이 어느 작업에서 나왔는지와 검토 전 파일이 어디까지 퍼졌는지를 추적하기 어려워집니다.

Google Cloud는 Filestore agent volumes 소개에서 AI 에이전트 작업공간을 위한 관리형 파일 저장소라는 맥락을 제시합니다. 다만 저장소를 연결하는 일만으로 소유자, 검토, 보존 책임이 생기지는 않습니다. 공식 사전 조건 문서도 제공 범위와 준비 조건을 확인하게 하므로, 이를 일반적인 보안 보장이나 모든 운영 환경의 도입 권고로 넓혀 해석해서는 안 됩니다.

scratch·handoff·approved: 세 경로가 맡는 일이 다릅니다

scratch는 한 작업이 자유롭게 쓰는 임시 공간입니다. 다른 작업은 이곳을 기본적으로 읽지 않습니다. handoff는 검토를 기다리는 산출물을 두는 경계이며, 가능한 한 읽기 전용으로 넘깁니다. approved는 검증을 마친 결과만 보관하거나 다음 단계가 신뢰하고 읽는 위치입니다.

이 구분은 폴더 이름만 바꾸는 규칙이 아닙니다. 경로마다 writer와 reader를 다르게 두고, 승격 기준과 보존 기간을 다르게 적용하는 약속입니다. volume pools 관리 문서처럼 저장소를 관리 단위로 나누는 접근은 이 경계를 구현할 때 참고할 수 있지만, 실제 권한 모델과 보관 요구사항은 팀의 환경에 맞게 별도로 결정하셔야 합니다.

공유 전에 채우는 6칸 artifact 인수 계약

아래 표는 작업마다 한 장씩 작성할 수 있는 최소 계약입니다. 값이 비어 있으면 공유를 시작하지 않는다는 원칙을 두면, 속도를 늦추기보다 나중의 재작업과 조사 비용을 줄이는 데 도움이 됩니다.

작업 ID 하나로 작성해 보는 구체 예시

예를 들어 task-241이 고객 문의를 분류한 CSV와 요약 이미지를 만든다고 가정해 보겠습니다. 분석 에이전트는 scratch/task-241에만 씁니다. 검토 에이전트는 이 경로를 직접 수정하지 않고, 해시와 행 수 확인 결과가 붙은 파일만 handoff/task-241에서 읽습니다. 사람이 검토를 마친 뒤에만 필요한 결과를 approved/task-241으로 옮깁니다.

승격 기록에는 최소한 파일명, 해시, 생성 에이전트, 입력 데이터의 분류, 검토 결과, 승인 시각을 남기세요. 이 기록은 완벽한 보안 체계를 대신하지 않습니다. 그러나 문제가 생겼을 때 공유 범위를 넓히지 않고 해당 파일을 되짚을 수 있는 운영 단서가 됩니다.

회수 리허설: 끝난 뒤의 책임까지 확인하세요

작업이 끝난 뒤에는 산출물만 남기고 접근 권한을 회수하는 리허설이 필요합니다. 먼저 mount 또는 경로 권한을 회수할 대상 목록을 확인하고, TTL 만료 예정 파일을 점검합니다. 법적·계약상 이유로 보존해야 하는 예외는 승인자와 만료 검토일을 함께 기록하세요. 삭제가 끝났다면 무엇을 언제 누가 처리했는지 남겨야 합니다.

비용 관점에서도 이 순서가 유리합니다. 저장 용량을 줄이겠다고 검토 전 파일을 무작정 지우면 재현과 조사 비용이 커질 수 있고, 반대로 모든 초안을 남기면 보관과 접근 관리 비용이 누적됩니다. 따라서 작업별 TTL과 보존 예외를 함께 결정하는 것이 현실적입니다.

다음 작업에 바로 적용하는 순서

1. 공유가 필요한 작업 하나만 고르고 task ID를 붙이세요.
2. scratch·handoff·approved의 writer와 reader를 문장으로 적으세요.
3. 6칸 계약에서 비어 있는 칸을 채우기 전에는 경로를 공유하지 마세요.
4. 작업 종료일에 revoke와 삭제 기록을 확인하는 짧은 리허설을 예약하세요.

병렬 작업 자체의 선택이 먼저 고민되신다면 멀티 에이전트 병렬화 판단표를, 실행 공간과 권한 경계를 더 넓게 정리하려면 AI 에이전트 런타임 경계를 함께 참고해 보세요. 작업이 끝난 뒤 남길 기록과 정리 기준은 세션 정리·보존 계약에서 이어서 확인하실 수 있습니다.

자주 묻는 질문

공용 폴더 하나로 시작한 뒤 나중에 정리해도 되나요?

작은 실험에서도 작업 ID와 writer·reader부터 정해 두시는 편이 좋습니다. 나중에 경계를 만들면 이미 섞인 파일의 출처와 검증 상태를 다시 확인해야 합니다.

모든 파일에 해시를 남겨야 하나요?

다음 작업의 입력이 되거나 승인 경로로 옮기는 파일부터 우선 적용해 보세요. 임시 로그까지 같은 강도로 관리할 필요가 있는지는 데이터 성격과 재생성 비용에 따라 정하시면 됩니다.

handoff를 읽기 전용으로 두는 이유는 무엇인가요?

검토 대상이 검토 중 바뀌는 일을 줄이기 위해서입니다. 수정이 필요하면 scratch에서 새 산출물을 만들고, 다시 검증 절차를 거치는 흐름이 더 명확합니다.

보존 기간은 어떻게 정하면 좋을까요?

재현 필요성, 입력 데이터의 민감도, 계약상 보관 의무, 저장 비용을 함께 보세요. 공통 기간 하나를 강제하기보다 작업 유형별 기본값과 승인된 예외를 두는 방식이 관리하기 쉽습니다.

참고 자료

• Google Cloud Blog — Filestore agent volumes: AI 에이전트 작업공간용 파일 저장소라는 발표 맥락을 확인했습니다.
• Google Cloud Documentation — Set up Filestore agent volumes: 제공 범위와 준비 조건을 확인하는 공식 문서입니다.
• Google Cloud Documentation — Create and manage volume pools: 저장소를 관리 단위로 나누는 구현 맥락을 참고했습니다.