플러스프로젝트 배경
1) 문제점 - 여러 회사가 하나의 오브젝트 스토리지를 공유하는 구조에서는, 다른 회사의 파일이 목록에 한 번 노출되는 것만으로 되돌릴 수 없는 사고가 된다. - 클라이언트가 오브젝트 키를 지목해 보내는 흔한 설계는, 키 하나가 조작되면 스토리지 전체가 열리는 것과 같은 위험을 안고 있다. - 회사마다 저장소 위치(클라우드/온프레미스)도 VPN 경로도 달라질 수 있는데, 그 선택이 무엇을 포기하는 선
프로젝트 성과
키를 받지 않는 구조로 테넌트 격리를 옮긴 것
파일을 열거나 내려받을 때 클라이언트가 오브젝트 키를 보내지 않고, 서버가 회사 스코프에서 존재를 확인한 뒤 키를 스스로 정하도록 만들었다.
링크가 새어나가도 시간이 지나면 무력해지는 공유 방식
외부 공유에 영구 링크나 실제 저장 키를 쓰지 않고, 만료 시간이 있는 presign URL만 발급하도록 했다.
핵심 기능
회사 파일 탐색기
폴더 단위로 파일을 올리고 내려받고 이동·삭제·검색하는 화면이다.
진행 단계
격리 모델과 저장소 구조 설계
2026.08.
기능마다 저장소를 따로 만들지 않고 하나를 공유하는 방향을 이때 확정했다.
프로젝트 상세
여러 회사가 하나의 오브젝트 스토리지를 함께 쓰는 사내 파일서버를 만들었다. S3 호환 스토리지(R2/MinIO) 위에 회사별로 완전히 격리된 저장 공간을 얹고, 폴더 단위로 올리고 내려받고 옮기고 지우는 탐색기 화면 하나로 그 전부를 다루게 했다. 문서 AI나 재고 사진처럼 다른 기능이 만들어 둔 파일도 저장소를 따로 만들지 않고 같은 탐색기 안에 회사 폴더로 들어온다. 이런 구조에서 가장 무서운 사고
