26Y05c

Young-Kyoo Kim·2026년 7월 5일

"50억 개 이상의 객체 적재"라는 초대형 인프라 제약과 "MetaDB 내에 Object별 사용 용량(Byte)을 저장하지 않는다"는 연쇄 결정에 따라, 26가지 요건 중 기술적으로 구현이 절대 불가능하여 프로젝트 범위에서 반드시 제외(Drop)해야 하는 요건 리스트를 정리해 드립니다.

이 요건들은 MinIO AIStor의 순정 기능으로도 지원하지 않고, 아키텍처 슬리밍을 위해 백엔드 구조(Kafka/Redis/Capacity DB)를 생략했기 때문에 발생하는 '물리적인 한계'입니다. 현업 및 유관 부서와의 요구사항 조율(네고) 시 아래 리스트와 사유를 명확히 제시하시기 바랍니다.

❌ 절대 구현 불가능한 요구사항 리스트 (Drop 항목)

1. Prefix 단위의 바이트(Byte) 기준 쿼터 통제 및 차단 부문

AIStor는 Prefix 단위의 누적 용량 제한 기능이 없고, 시스템에서 실시간 용량을 추적하지 않으므로 용량 관련 모든 제어 요건은 수행할 수 없습니다.

REQ-03-01: Prefix별 쿼터 설정/수정/삭제 API (단위: GB/TB)
불가 사유: 관리자 화면에서 "이 프리픽스는 10GB만 줘"라고 설정 값을 입력받아 DB에 저장하는 것까지는 가능하나, 실질적으로 이를 비교할 '현재 사용량' 데이터 소스가 없으므로 기능의 본질이 성립하지 않습니다.

REQ-03-02: 실시간/주기적 용량 집계 및 동기화
불가 사유: 메타DB에 용량 정보를 누적하지 않기로 결정했으므로, Webhook이나 Prometheus를 통해 실시간으로 바이트를 합산하고 싱크하는 파이프라인 자체를 만들 수 없습니다.

REQ-03-03: 용량 초과 시 쓰기 제한 차단 (Enforcement)
불가 사유: 유저가 mc나 Console UI로 우회하여 직접 업로드할 때, 스토리지 레벨에서 "이 프리픽스는 용량이 꽉 찼으니 업로드를 거부한다"라고 바이트 단위로 막아줄 수 있는 AIStor 순정 API가 존재하지 않습니다. (MinIO QoS는 속도와 동시성만 제어 가능).

REQ-05-02: 쿼터 임계치 도달 알람 (Soft Limit 80%, Hard Limit 100%)
불가 사유: 현재 사용량이 몇 %인지 실시간 계산이 불가능하므로, 임계치 도달을 감지하여 큐브 알람을 쏘는 비즈니스 로직은 구현이 절대 불가능합니다.

2. Prefix 단위 시계열 가공 메트릭 및 분석 부문

과거의 용량 변화 추이나 누적 통계 데이터를 저장하는 저장소가 없으므로, 시간에 따른 변화율 측정이 불가능합니다.

REQ-04-02: Prefix별 세부 메트릭 가공 및 집계 (전일 대비 증가율 등)
불가 사유: "전일 대비 증가율"을 계산하려면 최소한 어제 자 용량과 오늘 자 용량의 스냅샷 이력이 DB에 시계열로 쌓여있어야 합니다. 메타DB 용량 저장을 배제했기 때문에 증가율 가공은 불가능합니다. (단, 일일 업로드/다운로드 '횟수'는 OpenSearch 로그가 살아있는 1~2주 범위 내에서만 일시적으로 조회 가능).

3. 비동기 이벤트 처리 아키텍처 부문

REQ-06-01: 비동기 이벤트 기반 용량 증감 업데이트 (성능 저하 방지)
불가 사유: 50억 개 환경의 성능 보존을 위해 Kafka 레이어와 파일 단위 실시간 트리거 증감 로직을 아키텍처에서 완전히 배제(Drop)하기로 선언했으므로, 이 요건은 개발 대상에서 제외됩니다.

⚠️ 부분적으로 기능이 극도로 제한되거나 타협이 필요한 요건

RFQ-05-01: Webhook 수신 및 라우팅 엔진 (쿼터 통제 엔진 등 이상 징후 수신)
타협 내용: 이 요건 중 '쿼터 초과 여부 판단' 소스는 활용할 수 없습니다. 대신 "Audit Log를 통한 사용자 접근 행위 추적" 및 "에러 로그 수신" 용도로만 범위를 대폭 축소하여 OpenSearch와 연계해야 합니다.

💡 현업 설득을 위한 한계 요약 장표 가이드

유관 부서에 범위를 축소할 때 아래와 같이 3대 불가 원칙을 선언하시면 커뮤니케이션이 수월해집니다.

실시간 바이트 차단 불가: 50억 개 객체 환경에서 파일 하나 올라갈 때마다 실시간으로 용량을 계산해 쿼터를 막는 것은 현존하는 어떤 분산 스토리지 아키텍처로도 불가능하며, 인프라 전체를 마비시킵니다.

용량 기반 대시보드 제외: Grafana 대시보드에서 "우리 부서가 지금 몇 GB 쓰고 있는가?"에 대한 실시간 바이트 그래프는 제공되지 않습니다. 대신 "우리 부서의 프리픽스 마스터 정보(소유주, 별칭, 생성일)"와 "최근 1주일간 우리 부서의 파일 업로드/다운로드 발생 트래픽 건수" 중심으로 대시보드가 구성됩니다.

권한 격리 중심으로 패러다임 전환: 용량을 옭아매어 스토리지를 통제하는 대신, 앞서 합의한 서비스 어카운트(Service Account) 발급 API를 통해 "철저하게 자기 부서 경로 외에는 1바이트도 구경하지 못하게 만드는 권한 격리 보안"에 집중하는 것으로 프로젝트 목표를 재정의합니다.

50억 개 이상의 초대형 객체를 안정적으로 핸들링하면서, 시스템 복잡도를 획기적으로 줄인 설계 변경 사항을 현업 부서(비즈니스 조직)에 명확히 전달하고 설득하기 위한 회의 준비 문서(Agenda & Playbook)를 작성했습니다.

출력하여 회의 테이블에 바로 올리거나 스크린에 띄워 사용할 수 있도록 두 가지 관점(전략/전술)을 정교하게 반영했습니다.

[회의 준비 문서] 데이터 레이크하우스 2.0 프리픽스(Prefix) 관리 요건 조정 및 아키텍처 최적화 선언

일시: 2026년 7월
참석 대상: 인프라/DevOps 파트, 현업 데이터 서비스/플랫폼 활용 부서 담당자, 거버넌스 담당자
회의 목적: 50억 개 이상 대규모 객체 환경에서의 인프라 안정성 확보를 위한 프리픽스(Prefix) 단위 요건(용량 규제 및 조회)의 현실적 재조정 및 합의

1. 전반적인 전략 (Core Strategy)

"무거운 인프라 부채를 지지 않는 슬림한 아키텍처(Thin API)로 전환하고, 통제의 패러다임을 '용량 제한'에서 '완벽한 권한 격리'로 바꾼다."

안정성 최우선 (Stability First): 50억 개가 넘는 데이터 레이크하우스에서 파일 하나 올라올 때마다 실시간으로 용량을 계산하여 차단하는 방식은 인프라 마비를 초래합니다. 대규모 분산 환경의 가용성을 지키는 것을 최우선 가치로 둡니다.
순정 기능 극대화 (Fat Storage): 무리하게 자체 카프카(Kafka)나 레디스(Redis) 클러스터를 추가 전개하여 운영 오버헤드를 키우지 않고, MinIO AIStor의 내장 엔터프라이즈 기능(IAM, STS, Service Account, Inventory)을 200% 활용합니다.
보안 거버넌스로의 전환: 현업이 진짜 원하는 본질은 '스토리지 폭발 방지'와 '우리 부서 데이터 보안'입니다. 이를 위해 바이트 단위 통제 대신 부서 간 데이터 접근을 완벽히 차단하는 철저한 권한 격리 전략을 전면에 내세웁니다.

2. 세부 실행 전술: 구현 가부(可否) 및 범위 확정

현업 요구사항 26가지 중 '반드시 가져갈 핵심 가치(In-Scope)'와 '인프라 파괴를 막기 위해 과감히 배제할 항목(Drop)'을 명확히 선언합니다.

▣ 추진 및 개발 항목 (In-Scope: 1차년도 집중 개발)

프리픽스 마스터 및 한글 별칭(Alias) 관리: 가벼운 관리 DB 테이블을 생성하여 부서별 프리픽스의 소유주, 생성일, 한글 별칭을 0.001초 만에 조회/수정할 수 있도록 API를 제공합니다.
하이브리드 계정형 트리 조회 (Deep Tree View): 현업이 원하는 '깊은 하위 계층 폴더 전체 조회 및 검색'을 위해, 새벽에 자동 덤프되는 Inventory Parquet 파일과 OpenSearch의 최근 실시간 증분 로그를 API 서버가 결합하여 스토리지 부하 전혀 없이 완벽히 실시간 계층 구조를 제공합니다.
자율형 서비스 어카운트(Service Account) 발급: 현업 부서가 관리자 요청 없이 스스로 특정 하위 프리픽스 권한으로 꽁꽁 묶인 '반고정(장기) API Key'를 안전하게 뽑아서 타 시스템 연동에 쓸 수 있도록 Self-Service API를 제공합니다.
Grafana 멀티테넌시 대시보드: 단 하나의 대시보드로, 로그인한 사용자의 사번 컨텍스트를 인식하여 자기가 소유한 프리픽스의 메타 정보와 최근 1~2주간의 파일 업로드/다운로드 발생 트래픽 건수를 격리하여 시각화합니다.

▨ 제외 및 기각 항목 (Drop-Scope: 기술적 불가로 제외)

실시간 바이트(Byte) 단위 쿼터 제한 및 알람 전면 취소: 파일 업로드 시 실시간으로 남은 용량을 체크해 하드 리밋(Hard Limit)으로 차단하거나 80% 도달 시 알람을 주는 요건은 시스템 성능 보존을 위해 전면 배제합니다.
용량 기반 실시간 시계열 그래프 제외: 각 프리픽스별 일일 누적 용량 변화 추이 등의 무거운 시계열 메트릭 가공은 메타DB 부하 최소화를 위해 아키텍처에서 제외합니다.

3. 현업 설득을 위한 논리 체계 (Negotiation Playbook)

현업의 반발("용량 제한 안 되면 스토리지 터지면 어떡하냐", "실시간 조회가 왜 안 되냐")에 대응하기 위한 기술적 팩트 기반의 방어 논리입니다.

💬 시나리오 A: "왜 프리픽스별 실시간 용량 제한(Quota) 안 주나요?"

현업의 요구: 부서별로 10TB, 20TB 딱 끊어서 용량 넘치면 업로드 안 되게 막아주세요.
인프라 파트 대응: > "현재 우리 데이터 레이크하우스는 50억 개 이상의 객체가 적재된 엑사스케일급 인프라입니다. 파일 하나가 올라갈 때마다 전체 스토리지의 바이트를 실시간 연산하여 차단하는 방식은 검색 엔진과 스토리지 전체에 극심한 병목을 일으켜, 되려 현업 분들의 파일 업로드/다운로드 속도를 수십 배 저하시키는 원인이 됩니다. 스토리지 전체 공간 관리는 인프라 파트에서 인프라 레벨 쿼터로 상시 모니터링하며 안전하게 방어하고 있으니 안심하셔도 됩니다."

💬 시나리오 B: "OpenSearch 로그가 1~2주 뒤에 지워지면 과거 파일은 조회가 안 되나요?"

현업의 요구: 1년 전에 올린 파일도 하위 폴더 트리 구조에서 한눈에 다 펼쳐서 보고 싶어요.
인프라 파트 대응: > "당연히 가능합니다. OpenSearch 로그 보존 주기가 짧은 한계를 극복하기 위해, 저희가 '하이브리드 조회 아키텍처'를 도입했습니다. 1주일 전, 1년 전의 모든 과거 데이터 구조는 새벽마다 덤프되는 초경량 'Inventory 시스템'이 완벽하게 백업본을 쥐고 있고, OpenSearch는 오늘 당장 방금 올린 최신 파일들을 추적하는 데만 쓰입니다. API 서버가 이 두 장부를 실시간으로 섞어서 보여주기 때문에, 현업 유저분들은 인프라 부하 없이 100% 실시간으로 과거부터 현재까지의 전체 계층 트리를 완벽하게 탐색할 수 있습니다."

💬 시나리오 C: "특정 프리픽스 권한을 다른 팀에 넘길 때 왜 자꾸 토큰이 아니라 서비스 어카운트를 쓰라는 건가요?"

현업의 요구: 타 부서랑 연동할 때 며칠 동안 쓸 수 있는 임시 토큰 발행해 주면 안 되나요?
인프라 파트 대응: > "보안 표준상 임시 토큰(STS)은 최대 12시간까지만 유지가 가능하여, 반고정 형태로 수일 이상 연동할 경우 매번 토큰을 새로 갱신해야 하는 개발 공수가 현업 부서에 발생합니다. 대신, 관리자 승인을 기다릴 필요 없이 콘솔에서 클릭 몇 번으로 특정 하위 폴더 경로 권한만 상속받은 만료 기간 없는 '서비스 어카운트 Key'를 직접 생성할 수 있게 기능을 열어드립니다. 연동이 끝나면 직접 삭제하시면 되므로, 현업 입장에서는 훨씬 주도적이고 편리한 '반고정 자격 증명 방식'입니다."

4. 회의 결론 및 합의 유도 사항 (To-Do)

범위 확정 및 서명: 실시간 바이트 쿼터 기능을 드롭하는 대신, 'OpenSearch + Inventory 기반 하이브리드 전체 계층 트리 뷰' 및 '자율형 서비스 어카운트 발급'으로 1차년도 스펙을 확정 짓는 것에 동의를 구함.
현업 협조 요청 (데이터 가이드라인): 50억 개 객체 환경에서 하이브리드 트리의 완벽한 성능을 위해, 한 폴더(동일 경로 단일 Depth) 안에 파일 수백만 개를 평평하게(Flat) 집어넣는 적재 방식은 지양하고, 반드시 /연도/월/일/ 또는 /프로젝트/ 단위로 디렉터리 계층 구조를 나누어 적재해 줄 것을 가이드라인으로 배포 및 합의.