GOOGLE AI AGENT
구글, 벡터 DB 대신 지속성 메모리 사용하는
에이전트 시스템 공개
Always-On Memory Agent의 아키텍처, 동작 원리, 설치 방법까지 완벽 분석
2026년 4월 13일
📑 목차
1. 프로젝트 개요 — Always-On Memory Agent란?
2026년 3월, 구글 AI 제품 매니저 슈밤 사부가 Always-On Memory Agent라는 이름의 오픈소스 프로젝트를 공개했습니다. 이 프로젝트는 Google Cloud Platform 공식 깃허브에 MIT 라이선스로 배포되었으며, AI 에이전트가 단순히 대화 세션 내에서만 기억하는 것이 아니라 지속적으로 정보를 축적하고 활용하도록 설계된 시스템입니다.
기존의 AI 에이전트는 대화가 끝나면 맥락을 잃어버리는 근본적인 한계가 있었습니다. 이를 해결하기 위해 많은 개발자들이 벡터 데이터베이스와 RAG(Retrieval-Augmented Generation) 파이프라인을 구축해왔지만, 이 과정에서 임베딩 생성, 벡터 인덱스 관리, 데이터 동기화 등 상당한 인프라 복잡성이 발생했습니다. 구글의 Always-On Memory Agent는 이 문제에 대해 완전히 다른 접근 방식을 제안합니다.
핵심 아이디어는 놀라울 정도로 단순합니다. 벡터 데이터베이스를 사용하지 않고 SQLite에 구조화된 형태로 메모리를 저장하며, LLM 자체가 메모리를 직접 읽고, 분석하고, 통합하는 역할을 수행합니다. 슈밤 사부는 이를 두고 "인간의 수면 중 기억 통합 과정"에 비유했습니다. 에이전트가 백그라운드에서 계속 동작하면서 수집된 정보를 주기적으로 정리하고 연결하는 것이죠.
이 프로젝트는 Google ADK(Agent Development Kit)와 Gemini 3.1 Flash-Lite 모델을 기반으로 구축되었습니다. 텍스트, 이미지, 오디오, 비디오, PDF 등 27가지 형식의 파일을 처리할 수 있는 멀티모달 수집 파이프라인을 갖추고 있으며, 파일 감시, HTTP API, Streamlit 대시보드 등 다양한 인터페이스를 제공합니다.
▲ Always-On Memory Agent 실행 시 초기화 과정 - 3개의 전문 에이전트가 순차적으로 로드된다
2. 왜 벡터 DB가 아닌가? — 패러다임의 전환
전통적인 RAG 시스템의 작동 방식을 먼저 살펴보겠습니다. 일반적인 RAG 파이프라인에서는 문서를 청크 단위로 나누고, 각 청크에 대해 텍스트 임베딩을 생성한 뒤, 이를 Pinecone이나 Weaviate 같은 벡터 데이터베이스에 저장합니다. 사용자가 질문하면 질문도 임베딩으로 변환하여 코사인 유사도 기반으로 가장 관련 있는 청크를 검색하고, 이를 LLM의 컨텍스트에 넣어 답변을 생성합니다.
이 방식은 대규모 데이터셋에서 효과적이지만 몇 가지 근본적인 한계가 있습니다. 첫째, 벡터 검색은 본질적으로 수동적입니다. 데이터를 임베딩하고 저장한 뒤 질문이 들어올 때만 검색하는 구조이므로, 서로 다른 시점에 수집된 정보 간의 연결고리를 스스로 발견하지 못합니다. 둘째, 임베딩은 의미의 근사치일 뿐이므로 복잡한 맥락이나 뉘앙스를 놓칠 수 있습니다. 셋째, 벡터 데이터베이스를 운영하려면 별도의 인프라 비용과 관리 부담이 발생합니다.
Always-On Memory Agent는 이 모든 과정을 LLM에게 직접 맡깁니다. 임베딩을 생성할 필요가 없고, 벡터 인덱스를 관리할 필요도 없습니다. LLM이 메모리를 직접 읽고, 어떤 정보가 관련 있는지 판단하고, 교차 참조를 생성하고, 새로운 인사이트를 도출합니다. 이는 마치 사람이 노트를 직접 읽으며 정리하는 것과 비슷한 방식입니다.
▲ 전통적 RAG 방식과 Always-On Memory Agent의 핵심 차이점 비교표
물론 이 접근 방식에도 트레이드오프가 있습니다. 벡터 데이터베이스는 수백만 개의 문서를 밀리초 단위로 검색할 수 있지만, LLM 직접 읽기 방식은 메모리 양이 많아질수록 처리 시간과 토큰 비용이 증가합니다. 따라서 이 시스템은 대규모 엔터프라이즈보다는 중소 규모의 에이전트 시스템에 더 적합하며, 정보의 양보다 정보 간 연결과 통찰이 중요한 시나리오에서 진가를 발휘합니다.
3. 핵심 아키텍처 분석
Always-On Memory Agent의 아키텍처는 멀티 에이전트 오케스트레이션 패턴을 따릅니다. 하나의 오케스트레이터가 전체 시스템을 관리하고, 3개의 전문 에이전트가 각자의 역할을 수행합니다. 각 에이전트는 Google ADK 프레임워크의 Agent 클래스로 정의되며, 전용 도구(tool) 함수들을 가지고 있습니다.
flowchart TB
subgraph Input["입력 소스"]
F["파일 감시 (inbox/)"]
A["HTTP API (/ingest)"]
D["대시보드 업로드"]
end
subgraph Orchestrator["Memory Orchestrator"]
O["오케스트레이터
요청 라우팅 및 통합 관리"]
end
subgraph Agents["전문 에이전트"]
IA["IngestAgent
데이터 수집 및 구조화"]
CA["ConsolidateAgent
메모리 통합 및 교차참조"]
QA["QueryAgent
질의 응답 및 인용"]
end
subgraph Storage["SQLite 저장소"]
MT["memories 테이블"]
CT["consolidations 테이블"]
PT["processed_files 테이블"]
end
subgraph Output["출력"]
API["JSON API 응답"]
UI["Streamlit 대시보드"]
end
F --> O
A --> O
D --> O
O --> IA
O --> CA
O --> QA
IA --> MT
IA --> PT
CA --> MT
CA --> CT
QA --> MT
QA --> CT
QA --> API
QA --> UI
style Input fill:#1e1b4b,stroke:#6d28d9,color:#e2e8f0
style Orchestrator fill:#1e293b,stroke:#7c3aed,color:#e2e8f0
style Agents fill:#1e293b,stroke:#3fb950,color:#e2e8f0
style Storage fill:#1e293b,stroke:#58a6ff,color:#e2e8f0
style Output fill:#1e293b,stroke:#d29922,color:#e2e8f0
▲ Always-On Memory Agent 전체 아키텍처 구조도
데이터는 3가지 경로로 시스템에 진입합니다. 첫째, inbox/ 폴더를 5초 간격으로 감시하는 파일 워처를 통해 자동으로 수집됩니다. 둘째, HTTP POST 요청으로 /ingest 엔드포인트에 텍스트 데이터를 전송할 수 있습니다. 셋째, Streamlit 기반 웹 대시보드에서 파일을 직접 업로드할 수 있습니다.
들어온 데이터는 오케스트레이터가 적절한 에이전트로 라우팅하며, 모든 처리 결과는 SQLite 데이터베이스에 구조화된 형태로 저장됩니다. 벡터 임베딩이나 별도의 검색 인덱스 없이, 순수하게 관계형 데이터베이스 구조만으로 메모리를 관리하는 것이 이 시스템의 핵심 설계 철학입니다.
4. 에이전트 구성과 역할
4-1. IngestAgent — 데이터 수집과 구조화
IngestAgent는 시스템의 입구 역할을 담당합니다. 파일이 감지되거나 API로 데이터가 들어오면, 이 에이전트가 Gemini 3.1 Flash-Lite를 활용하여 콘텐츠를 분석합니다. 텍스트 파일은 직접 읽고, 이미지와 오디오, 비디오는 Gemini의 멀티모달 기능으로 내용을 추출합니다. 27가지 파일 형식을 지원하며, 20MB 이상의 파일은 자동으로 건너뜁니다.
IngestAgent가 수행하는 작업은 다음과 같습니다. 먼저 콘텐츠의 1~2문장 요약을 생성합니다. 그다음 핵심 엔티티(인물, 제품, 기술 등)를 추출하고, 2~4개의 주제 태그를 부여합니다. 마지막으로 0.0에서 1.0 사이의 중요도 점수를 매겨 store_memory() 도구 함수를 호출하여 SQLite에 저장합니다.
▲ IngestAgent의 파일 수집 과정 - 텍스트, PDF, 이미지 각각에 대해 요약, 엔티티, 토픽, 중요도를 추출한다
▲ 지원되는 27가지 입력 파일 형식 - 텍스트, 이미지, 오디오, 비디오, 문서를 모두 처리한다
4-2. ConsolidateAgent — 메모리 통합의 핵심
ConsolidateAgent는 이 시스템에서 가장 혁신적인 구성 요소입니다. 기본적으로 30분 간격으로(설정 가능) 백그라운드에서 실행되며, 아직 통합되지 않은 메모리를 모두 읽어 들여 패턴을 찾고 연결고리를 생성합니다. 이 과정이 바로 슈밤 사부가 "인간의 수면 중 기억 통합"에 비유한 핵심 메커니즘입니다.
통합 과정은 다음과 같이 진행됩니다. 먼저 read_unconsolidated_memories()를 호출하여 미통합 메모리 최대 10개를 가져옵니다. 최소 2개 이상의 메모리가 있어야 통합이 실행됩니다. 그러면 LLM이 이 메모리들을 함께 읽으면서 교차 참조할 수 있는 관계를 찾습니다. 예를 들어, "회의록에서 언급된 API 출시 일정"과 "기술 사양서의 API 설계 내용"이 동일한 프로젝트에 대한 것임을 파악하고 연결합니다.
연결을 찾으면 store_consolidation()을 호출하여 통찰을 저장합니다. 이때 양방향 연결이 생성됩니다. 관련된 메모리 A와 B가 있다면, A의 connections 배열에 B에 대한 참조가 추가되고, B에도 A에 대한 참조가 추가됩니다. 처리가 완료된 메모리는 consolidated = 1로 표시되어 다음 주기에서 다시 처리되지 않습니다.
▲ ConsolidateAgent의 메모리 통합 주기 - 교차 참조 발견 및 인사이트 자동 생성 과정
4-3. QueryAgent — 인용 기반 질의 응답
QueryAgent는 사용자의 자연어 질문을 받아 메모리 기반 답변을 생성합니다. 질문이 들어오면 read_all_memories()로 최근 50개의 메모리를 가져오고, read_consolidation_history()로 최근 10개의 통합 인사이트를 함께 가져옵니다. 그런 다음 이 모든 정보를 종합하여 답변을 만들되, 반드시 출처를 표시합니다.
출처 표시는 "[Memory 1]", "[Memory 2]"와 같은 형식으로 이루어집니다. 이를 통해 답변의 각 부분이 어떤 원본 데이터에서 비롯되었는지 추적할 수 있습니다. 이는 엔터프라이즈 환경에서 특히 중요한 감사(audit) 가능성을 제공합니다.
▲ QueryAgent의 질의 응답 - 메모리 ID를 인용하여 출처가 명확한 답변을 생성한다
5. 메모리 저장 구조 — SQLite 스키마 분석
벡터 데이터베이스 대신 SQLite를 선택한 것은 이 프로젝트의 가장 대담한 설계 결정입니다. 데이터베이스는 3개의 테이블로 구성됩니다. memories 테이블은 개별 메모리를 저장하고, consolidations 테이블은 통합 인사이트를 저장하며, processed_files 테이블은 이미 처리된 파일 경로를 추적합니다.
memories 테이블의 각 레코드에는 원본 텍스트, LLM이 생성한 요약, 추출된 엔티티와 토픽(JSON 배열로 저장), 중요도 점수, 연결 정보, 통합 여부 플래그가 포함됩니다. 여기서 주목할 점은 벡터 임베딩 컬럼이 존재하지 않는다는 것입니다. 검색은 LLM이 전체 메모리를 읽으면서 수행하므로 임베딩이 필요 없습니다.
▲ SQLite 데이터베이스 스키마 - 벡터 임베딩 없이 구조화된 메타데이터만으로 메모리를 관리한다
6. 동작 원리 상세 분석
시스템의 전체 동작 흐름을 시퀀스 다이어그램으로 살펴보겠습니다. 파일이 수집되어 메모리로 저장되고, 통합 주기를 거쳐 인사이트가 생성되며, 최종적으로 질의에 응답하는 전 과정을 추적할 수 있습니다.
sequenceDiagram
participant U as 사용자/파일
participant O as Orchestrator
participant IA as IngestAgent
participant CA as ConsolidateAgent
participant QA as QueryAgent
participant DB as SQLite DB
Note over U,DB: Phase 1 - 데이터 수집
U->>O: 파일 또는 텍스트 입력
O->>IA: 수집 요청 라우팅
IA->>IA: Gemini로 내용 분석
IA->>DB: store_memory() 호출
DB-->>IA: memory_id 반환
Note over U,DB: Phase 2 - 메모리 통합 (30분 주기)
CA->>DB: read_unconsolidated_memories()
DB-->>CA: 미통합 메모리 반환
CA->>CA: 교차 참조 탐색
CA->>CA: 인사이트 도출
CA->>DB: store_consolidation()
CA->>DB: 양방향 연결 업데이트
DB-->>CA: consolidated = 1 표시
Note over U,DB: Phase 3 - 질의 응답
U->>O: 자연어 질문
O->>QA: 질의 라우팅
QA->>DB: read_all_memories()
QA->>DB: read_consolidation_history()
DB-->>QA: 메모리 + 인사이트 반환
QA->>QA: 답변 합성 + 출처 인용
QA-->>U: [Memory #1, #2] 인용 답변
▲ Always-On Memory Agent의 전체 동작 시퀀스 - 수집, 통합, 질의의 3단계 흐름
6-1. 수집 단계의 상세 흐름
파일 워처는 비동기 코루틴(watch_folder())으로 구현되어 5초 간격으로 inbox 폴더를 폴링합니다. 새 파일이 발견되면 확장자를 기준으로 처리 방식을 결정합니다. 텍스트 계열 파일(.txt, .md, .json, .csv, .log, .xml, .yaml)은 파일 내용을 직접 읽어 최대 10,000자까지 추출합니다. 이미지, 오디오, 비디오 등 미디어 파일은 Gemini의 멀티모달 API를 통해 types.Part 객체로 변환하여 처리합니다.
처리된 파일의 경로는 processed_files 테이블에 기록되어 중복 수집을 방지합니다. 이미 처리된 파일이 inbox에 남아 있어도 다시 수집하지 않으므로, 파일을 삭제하지 않아도 됩니다.
6-2. 통합 단계의 핵심 로직
통합 주기는 consolidation_loop() 비동기 코루틴으로 실행됩니다. 설정된 간격(기본 30분)마다 깨어나서 미통합 메모리 수를 확인하고, 2개 이상이면 ConsolidateAgent를 호출합니다.
ConsolidateAgent는 LLM에게 "이 메모리들 사이에서 패턴, 관계, 모순을 찾아라"라고 지시합니다. LLM은 메모리의 요약, 엔티티, 토픽을 종합적으로 분석하여 교차 참조를 식별합니다. 발견된 관계는 connections 배열에 {"from_id": 1, "to_id": 2, "relationship": "설명"} 형태로 저장됩니다.
이 과정에서 생성되는 인사이트는 단순한 요약이 아닙니다. 서로 다른 출처에서 온 정보를 조합하여 새로운 결론을 도출합니다. 예를 들어, "회의록에서 3월 15일 출시 목표가 언급되었고, 기술 사양서에 아직 구현되지 않은 기능이 3개 있으므로, 일정 조정이 필요할 수 있다"와 같은 통찰을 자동으로 생성합니다.
6-3. 질의 응답 단계
QueryAgent는 최근 50개의 메모리와 10개의 통합 인사이트를 LLM의 컨텍스트에 주입합니다. LLM은 질문의 의도를 파악하고, 관련된 메모리를 선별하여 종합적인 답변을 구성합니다. 모든 답변에는 반드시 출처 메모리 ID가 포함되어야 하며, 이는 에이전트의 인스트럭션에서 강제됩니다.
7. 설치 및 실행 가이드
Always-On Memory Agent를 로컬 환경에서 직접 실행하는 방법을 단계별로 알아보겠습니다. Python 3.10 이상과 Google API 키가 필요합니다.
▲ 프로젝트 클론 및 의존성 설치 과정
7-1. 프로젝트 설치
git clone https://github.com/GoogleCloudPlatform/generative-ai.git
cd gemini/agents/always-on-memory-agent
pip install -r requirements.txt7-2. API 키 설정
export GOOGLE_API_KEY="your-gemini-api-key"7-3. 에이전트 실행
# 기본 실행
python agent.py
# 옵션 지정 실행
python agent.py --watch ./inbox --port 8888 --consolidate-every 30
# 대시보드 실행 (별도 터미널)
streamlit run dashboard.py에이전트가 시작되면 SQLite 데이터베이스가 자동으로 생성되고, 3개의 전문 에이전트가 초기화됩니다. HTTP API는 기본적으로 8888 포트에서 리스닝하며, Streamlit 대시보드는 8501 포트에서 접근할 수 있습니다.
▲ HTTP API 엔드포인트 목록과 시스템 상태 조회 예시
7-4. 데이터 수집 테스트
# 파일 자동 수집 (inbox 폴더에 파일 복사)
cp meeting_notes.txt ./inbox/
# API를 통한 수동 수집
curl -X POST http://localhost:8888/ingest \
-H "Content-Type: application/json" \
-d '{"text": "Q2 제품 로드맵 회의 결과...", "source": "meeting"}'
# 메모리 상태 확인
curl http://localhost:8888/status
# 자연어 질의
curl "http://localhost:8888/query?q=이번 주 우선순위는?"
▲ Streamlit 기반 웹 대시보드 - 메모리 통계, 최근 메모리 목록, 질의 박스를 한눈에 확인
8. 비용 분석 — 24시간 운영이 가능한 이유
이 프로젝트가 Gemini 3.1 Flash-Lite를 선택한 이유는 명확합니다. 비용 대비 성능이 24시간 백그라운드 운영에 최적화되어 있기 때문입니다. 입력 토큰 100만 개당 $0.25, 출력 토큰 100만 개당 $1.50으로, 이전 세대 모델 대비 첫 토큰 생성 속도가 2.5배 빠르고 전체 출력 속도가 45% 향상되었습니다.
중규모 에이전트 시스템을 기준으로 일일 토큰 사용량을 추산하면, 수집 처리에 약 50,000 입력 토큰, 통합 주기에 약 30,000 입력 + 10,000 출력 토큰, 질의 응답에 약 20,000 입력 + 15,000 출력 토큰이 소요됩니다. 이를 합산하면 일일 약 $0.06, 월간 약 $1.80 수준입니다. 전통적인 벡터 데이터베이스 호스팅 비용이 월 $20~$100 이상인 것과 비교하면 약 10배에서 55배의 비용 절감 효과가 있습니다.
▲ Gemini 3.1 Flash-Lite 기반 24시간 운영 비용 분석 - 월 $1.80로 에이전트 메모리 시스템 운영 가능
벤치마크 성능 측면에서도 Gemini 3.1 Flash-Lite는 인상적입니다. 아레나 리더보드 Elo 점수 1432, GPQA 다이아몬드 86.9%, MMMU 프로 76.8%를 기록하며, 경량 모델임에도 불구하고 상당한 추론 능력을 보여줍니다. 에이전트 메모리 시스템의 핵심 작업인 요약, 엔티티 추출, 패턴 인식에는 충분한 수준입니다.
9. 한계와 전망
9-1. 현재의 기술적 한계
▲ 메모리 삭제, 수동 통합, 전체 초기화 등의 관리 기능
9-2. 패러다임 전환의 의미
이 프로젝트의 의미는 단순한 기술 데모를 넘어섭니다. AI 에이전트를 "요청에 응답하는 도구"가 아니라 "지속적으로 실행되는 소프트웨어 시스템"으로 보는 패러다임 전환을 보여줍니다. 메모리는 이제 부가 기능이 아니라 에이전트 런타임 인프라의 핵심 구성 요소가 됩니다.
특히 LLM의 컨텍스트 윈도우가 계속 확장되고 있다는 점을 고려하면, 이 접근 방식의 확장성 문제는 시간이 지남에 따라 자연스럽게 완화될 수 있습니다. Gemini의 100만 토큰 컨텍스트 윈도우는 이미 상당한 양의 메모리를 한 번에 처리할 수 있게 해주며, 향후 이 한도가 더 늘어난다면 벡터 데이터베이스 없는 메모리 시스템이 더 많은 사용 사례에 적용 가능해질 것입니다.
또한 이 프로젝트는 오픈소스로 공개되어 있어 커뮤니티의 발전 가능성이 열려 있습니다. 현재의 SQLite 기반 저장소를 Cloud SQL이나 Firestore로 교체하거나, 통합 알고리즘을 개선하거나, 멀티 에이전트 간 메모리 공유 기능을 추가하는 등의 확장이 가능합니다. 구글이 GCP 공식 리포지토리에 이 프로젝트를 포함시킨 것은, 이 방향의 연구가 구글 내부에서도 진지하게 고려되고 있음을 시사합니다.
10. FAQ
현재로서는 완전한 대체가 아니라 보완적 관계입니다. Always-On Memory Agent는 중소 규모 에이전트 시스템에서 벡터 DB의 인프라 복잡성을 줄이는 데 효과적입니다. 그러나 수백만 개의 문서를 밀리초 단위로 검색해야 하는 대규모 시스템에서는 여전히 벡터 데이터베이스가 필요합니다. 메모리가 수천 개를 넘어가면 LLM 직접 읽기 방식의 비용과 지연 시간이 증가하므로, 프로젝트의 규모와 요구사항에 따라 적절한 방식을 선택해야 합니다.
현재 구현은 Google ADK와 Gemini 3.1 Flash-Lite에 특화되어 있습니다. 그러나 아키텍처 자체는 LLM에 독립적이므로, ADK의 모델 설정을 변경하거나 다른 프레임워크(LangChain, CrewAI 등)로 포팅하면 OpenAI GPT, Anthropic Claude, Llama 등 다른 모델과도 사용할 수 있습니다. 핵심은 멀티모달 지원과 충분한 컨텍스트 윈도우를 가진 모델을 선택하는 것입니다.
QueryAgent는 최근 50개의 메모리만 가져오도록 제한되어 있어, 메모리가 많아져도 질의 처리 시 사용되는 토큰 수가 급격히 증가하지는 않습니다. 그러나 오래된 중요한 메모리가 검색 범위에서 벗어날 수 있다는 한계가 있습니다. 이를 보완하기 위해 통합 인사이트가 오래된 메모리의 핵심을 요약하여 보존하는 역할을 합니다. 필요하다면 API의 delete나 clear 엔드포인트로 불필요한 메모리를 정리할 수 있습니다.
개인 또는 팀 단위의 지식 관리 에이전트로 활용하는 것이 가장 적합합니다. 예를 들어, 회의록, 기술 문서, 이메일 요약 등을 inbox 폴더에 자동으로 전달하면 에이전트가 모든 정보를 통합하고, "이번 주 우선순위는?", "지난달 결정된 사항 중 진행되지 않은 것은?" 같은 질문에 출처가 포함된 답변을 제공합니다. 소규모 스타트업의 프로젝트 관리, 연구팀의 논문 및 데이터 관리, 개인 생산성 도구 등에 효과적입니다.
네, 가능합니다. 코드에서 SQLite 관련 부분을 PostgreSQL, Cloud SQL, Firestore 등으로 교체할 수 있습니다. 핵심은 memories와 consolidations 테이블의 스키마를 유지하는 것입니다. 멀티 사용자 환경이나 서버리스 배포를 원한다면 Cloud SQL이나 Firestore가 더 적합할 수 있습니다. 다만 SQLite의 단순성이 이 프로젝트의 철학과 맞닿아 있으므로, 꼭 필요한 경우에만 교체를 고려하세요.
'AI' 카테고리의 다른 글
| 학습용 칩 vs 추론용 칩, 무엇이 다를까? — TPU, GPU, 퓨리오사 RNGD 완전 정리 (0) | 2026.04.29 |
|---|---|
| ChatGPT image 2.0 Chameleon 실 사용 후기 (vs 나노바나나 2) (0) | 2026.04.22 |
| Flux 2.0 MAX로 인스타 AI 인플루언서 만들기 — 실제 API 크레딧 결제 후 사용 후기 (0) | 2026.04.09 |
| 오픈소스 RealVisXL V5.0으로 AI 버추얼 인물 생성 후기 — ComfyUI + PuLID + RunPod 실전 가이드 (0) | 2026.04.08 |
| Agent Flow — Claude Code에이전트 오케스트레이션을실시간으로 시각화하는 도구 (0) | 2026.04.02 |