DAM 공급업체에 AI가 있냐고 묻는 건 이제 그만하세요. 직접 증명하게 하세요

현재 많은 엔터프라이즈 디지털 자산 관리(DAM) 공급업체들이 AI를 핵심 기능으로 내세우고 있으며, 설문 조사에서는 모두 AI 기능을 제공한다고 답합니다. 이 글에서는 해당 AI가 실제로 비즈니스에 도움이 되는지 판별하는 방법을 알아봅니다.

DAM 공급업체 6곳을 최종 후보로 선정한 뒤 각각 플랫폼에 AI가 있냐고 물으면, 6곳 모두 자신 있게 “예”라고 답할 것입니다. AI 태깅, 자연어 검색, 생성형 변형, 에셋을 보강하고 게시하는 에이전트를 시연할 것입니다. 한 곳은 에이전틱 DAM을 보유하고 있다고 주장하고, 다른 곳은 새로운 MCP 서버를 대대적으로 홍보합니다. 세 번째 미팅쯤 되면 모든 데모가 뒤섞여 어느 업체가 무엇을 보여줬는지 기억조차 나지 않습니다.

저희는 DAM 비교 차트를 다루면서 이 시리즈의 첫 번째 글에서도 같은 맹점을 지적한 바 있습니다. 예/아니오 방식의 평가로는 모든 공급업체가 동일해 보입니다. DAM에 AI가 있나요? 예. 콘텐츠를 관리하나요? 예. 저희 스택에 맞나요? 예. 결국, 체크 표시가 가득한 표 하나를 근거로 30분짜리 데모 하나에 3년간의 플랫폼 도입 결정을 맡기는 셈입니다.

공급업체들이 거짓말을 하는 건 아닙니다. 다만 'AI'라고 말할 때 각자 다른 것을 의미할 뿐입니다. 일부에게 AI는 주로 더 나은 태깅, 풍부한 메타데이터, 자연어 검색을 통해 에셋을 더 빠르게 찾는 것을 의미합니다. 반면 더 큰 기회는 활성화에 있다고 보는 곳도 있습니다. AI를 활용해 에셋을 채널 전반에서 즉시 사용할 수 있도록 관리되고, 개인화되고, 승인된 콘텐츠로 전환하는 것입니다. 이는 동일한 체크 표시 뒤에 숨어 있는 전혀 다른 역할입니다. 플랫폼 간의 차이는 AI의 존재 여부가 아니라, AI가 실제로 무엇을 도와주는지, 그리고 실제 콘텐츠와 워크플로를 적용했을 때 제대로 작동하는지에 달려 있습니다. 이는 기능 비교표에서는 확인할 수 없습니다. 질문을 멈추고 직접 테스트를 시작해야 비로소 알 수 있습니다.

'AI 지원 준비가 된'의 진정한 의미 파악하기

팀이 DAM 외부에서 에셋이 필요한 경우가 얼마나 자주 있는지 생각해 보세요. 디자이너는 크리에이티브 툴에서, 마케터는 캠페인 플랫폼에서, 웹 팀은 고객을 위해 에셋이 필요합니다. 에셋이 어떻게 그곳에 도달하는지가 중요합니다. 어떤 플랫폼에서는 다른 애플리케이션이 DAM에 직접 접근해 관리되는 에셋을 활용할 수 있습니다. 반면 다른 플랫폼에서는 여전히 파일을 다운로드하고, 사본으로 작업한 후 다시 업로드하는 방식에 의존합니다. 두 공급업체 모두 통합 항목에 체크할 수 있지만, 실제 작동 방식은 전혀 다릅니다.

이제 AI를 더해 보겠습니다. 에이전트는 동일한 제약을 그대로 물려받습니다. MCP 연결을 제공하면 DAM에 접근할 수 있을지 모르지만, 과연 올바른 에셋을 찾을 수 있을까요? 이는 에이전트가 활용할 수 있는 메타데이터와 맥락에 달려 있습니다. 크리에이티브 팀은 캠페인, 콘셉트, 또는 시각적 특성을 기준으로 검색할 수 있습니다. 하위 팀은 제품, 시장, 권리, 채널, 또는 승인 상태를 중심으로 에셋을 찾을 수도 있습니다. 에이전트는 이 두 가지를 모두 이해해야 할 수도 있습니다. AI가 어떤 에셋이 실제로 적합한지 판단하지 못한다면, DAM에 대한 접근 권한이 있어도 큰 의미가 없습니다.

그렇다면 에이전트가 찾은 에셋을 실제로 활용할 때는 어떤 일이 벌어질까요? 거버넌스가 적용된 소스를 기반으로 작동하며, 콘텐츠가 워크플로를 통해 이동하는 동안에도 그 연결이 유지될까요? 다운스트림 툴과 채널이 별도의 복사본을 만들지 않고도 승인된 에셋을 사용할 수 있을까요? 아니면 모든 전달 단계마다 추적하고, 업데이트하고, 관리해야 할 새로운 파일이 생성될까요?

DAM이 이 속도를 감당할 수 있을까요? 사람이라면 에셋을 검색하고, 열고, 수정한 뒤 다음 작업으로 넘어갑니다. 하지만 에이전트는 그 시간 동안 수십 건의 요청을 처리할 수 있습니다. 여러 에이전트, 애플리케이션, 사람이 동시에 작업에 투입되면 요청 건수는 순식간에 폭발적으로 증가합니다.

이는 에이전트를 연결하기 훨씬 전에 DAM 벤더가 내린 인프라 결정에 직접적인 압박을 가합니다. 해당 플랫폼이 대규모 머신 기반 활동을 지원할 수 있는 처리 용량을 갖추고 설계되었는지, 아니면 애플리케이션에서 작업하는 사람들의 속도에 맞춰 구축되었는지가 핵심입니다. DAM이나 해당 API가 용량 또는 속도 제한으로 인해 요청량을 감당하지 못하면, 요청이 지연되거나 차단됩니다. 워크플로는 멈추고, 요청은 타임아웃이 발생하거나 실패합니다. 통제된 데모 환경에서 완벽하게 작동했던 것도, AI가 대규모로 실제 업무를 시작하는 순간 완전히 멈춰버릴 수 있습니다.

바로 이 지점에서 플랫폼 간 차이가 복잡하게 쌓이기 시작합니다. AI를 DAM에 연결하는 것은 출발점에 불과합니다. AI가 실질적인 성과를 내기 위해 필요한 맥락, 접근 권한, 성능, 그리고 거버넌스가 적용된 경로를 제공하는 것은 전혀 다른 문제입니다. AI에 더 많은 작업을 맡길수록, 그 기반이 되는 아키텍처의 중요성은 더욱 커집니다.

따라서 어느 벤더의 말도 그대로 믿지 마세요 — 저희 말도 예외는 아닙니다. 직접 증명하게 하세요. 아래에는 단계적으로 심화되는 질문들이 준비되어 있습니다. 첫 번째는 누구나 쉽게 던질 수 있는 질문이고, 마지막은 진정한 실력 차이를 가리는 질문입니다.

다섯 가지 질문: 갈수록 더 어려워지는 질문들

질문 1: DAM이 팀에서 이미 사용 중인 툴과 연결되나요?

모든 벤더는 "그렇다"고 답할 것입니다. 이제 그 "그렇다"가 실제로 무엇을 의미하는지 확인해야 합니다. 해당 플랫폼은 단순히 다른 애플리케이션이 에셋을 검색하고 가져올 수 있는 API를 제공하는 수준에 그치나요? 일반적인 워크플로를 위한 사전 구축된 통합이 공식적으로 지원되나요? 비즈니스 고유의 워크플로를 지원할 수 있도록 해당 API를 확장할 수 있나요? 그리고 다른 시스템이 에셋을 사용할 때, 관리되는 소스를 기반으로 운용되는 건지, 아니면 별도로 동기화하고 관리해야 하는 복사본을 만드는 건지 반드시 확인해야 합니다.

여기에 에이전트까지 더해보겠습니다. 해당 연결이 DAM을 사용하는 사람들과 동일한 ID, 권한, 사용 권한, 거버넌스 체계 아래서 운용되나요, 아니면 AI가 콘텐츠에 접근하는 별도의 경로를 부여받았나요? 에이전트는 사람보다 훨씬 많은 결정을 내리고 요청을 처리할 수 있습니다. 거버넌스 체계를 우회하는 연결은 처리 속도가 빨라지는 만큼 리스크도 함께 증폭시킵니다.

모든 벤더는 자사 솔루션이 "연결되어 있다"고 말할 수 있습니다. 하지만 그 연결의 이면에 있는 아키텍처와 거버넌스는 벤더마다 크게 다를 수 있습니다.

질문 2: DAM의 연결 범위는 어디까지입니까?

연결이 이루어지면, 실제로 무엇을 확인하고 가져올 수 있을까요? 모든 벤더는 자사 DAM이 에셋을 제공한다고 말합니다. 이제 그 "제공"이 실제로 무엇을 의미하는지 확인해야 합니다. 다른 애플리케이션이나 에이전트가 파일 자체에만 접근할 수 있나요, 아니면 해당 파일을 실제로 활용하는 데 필요한 정보인 설명 메타데이터, 제품 및 캠페인 맥락, 사용 권한, 승인 상태, 다른 에셋과의 관계, 출처 정보까지 접근할 수 있나요?

원본 바이너리 파일 너머도 살펴보세요. DAM이 에셋의 다양한 렌디션을 생성할 수 있다면, 연결을 통해 추가 복사본을 만들거나 관리하지 않고도 적합한 크기, 자르기 방식, 형식 또는 다른 표현 방식을 검색하고 요청할 수 있나요? 원본을 승인된 렌디션이나 생성된 변형과 구별할 수 있나요? 그리고 어떤 것을 가져오든, 거버넌스와 맥락이 요청과 함께 전달되나요?

에셋을 단순히 가져올 수 있다는 것은 연결의 한 가지 수준에 불과합니다. 에셋 자체는 물론, 비즈니스 맥락과 거버넌스, 그리고 작업에 맞는 올바른 표현 방식까지 접근할 수 있는 것이 진정한 연결입니다. 벤더에게 연결이 실제로 어디까지 미치는지 직접 증명해달라고 요구하세요.

질문 3: DAM은 워크플로 체이닝을 지원합니까?

실제 콘텐츠 작업이 하나의 시스템에서 완결되는 경우는 거의 없습니다. 에셋은 고객에게 도달하기 전, 검색, 수정, 검토, 승인, 조합을 거쳐 최종 배포에 이르기까지 수많은 단계를 통과해야 합니다. 모든 벤더는 이 워크플로를 지원한다고 말합니다. 이제 실제로 몇 단계나 거쳐야 하는지 직접 세어보세요. 에셋이 실제로 활용 가능한 상태로 게시되기까지 몇 개의 도구, 통합, 내보내기, 인계 과정을 거쳐야 하나요?

각 전환 단계에서 어떤 일이 일어나는지 꼼꼼히 살펴봐야 합니다. 에셋이 고유 식별 정보, 메타데이터, 권한, 승인 상태, 출처 정보와의 연결을 유지합니까? 아니면 다른 시스템이 복사본을 생성해 자체 버전을 독립적으로 관리하기 시작합니까? 다음 단계가 연결된 콘텐츠 공급망의 일부로 자동 진행됩니까? 아니면 담당자나 별도 시스템이 결과물을 직접 가져와 수동으로 전달해야 합니까?

벤더에게 실제 에셋 하나를 원본에서 게재 위치까지 이동시키면서, 그 과정에서 거치는 모든 시스템을 직접 시연해 달라고 요청하세요. 6개의 도구가 연결된 워크플로는 기술적으로 통합된 것처럼 보일 수 있습니다. 하지만 그것은 동시에 콘텐츠, 컨텍스트, 거버넌스가 무너질 수 있는 6개의 취약 지점이기도 합니다.

질문 4: AI가 에셋에 컨텍스트를 보강할 수 있습니까?

모든 벤더가 자사 AI가 에셋을 보강한다고 말합니다. 이제 보강이 실제로 무엇을 의미하는지 따져봐야 합니다. 플랫폼이 수집 시점에 몇 가지 설명 태그를 생성하는 데 그칩니까? 아니면 에셋이 생애주기 전반에 걸쳐 활용도를 높이는 컨텍스트를 지속적으로 축적합니까? 콘텐츠의 본질을 이해하고, 비즈니스 및 브랜드 컨텍스트와 연결하고, 권한과 거버넌스를 유지하고, 출처 정보를 보존하며, 콘텐츠가 어떻게, 어디서 활용되는지 학습할 수 있습니까?

그런 다음, 누가 그 인텔리전스를 활용할 수 있는지 물어봐야 합니다. 해당 인텔리전스가 크리에이티브 팀, 다운스트림 애플리케이션, AI 에이전트 모두가 접근할 수 있는 관리되는 에셋 컨텍스트의 일부가 됩니까? 아니면 검색 기능이나 별도의 AI 환경 안에 고립되어 있습니까? 그리고 에셋이 활성화되어 성과를 낼 때, 그 신호가 다시 반영되어 다음 의사결정을 위한 컨텍스트를 더욱 풍부하게 만들 수 있습니까?

메타데이터 생성은 가장 기본적인 수준의 보강입니다. 사람과 AI가 콘텐츠를 발견하고, 이해하고, 활용하며, 궁극적으로 개선할 수 있도록 신뢰할 수 있는 컨텍스트를 구축하는 것은 훨씬 높은 수준의 과제입니다.

질문 5: DAM이 관리되는 게재를 지원합니까?

콘텐츠는 최종 수신자에게 도달했을 때 비로소 진정한 가치를 발휘합니다. 모든 벤더가 자사 DAM이 웹사이트, 앱, 캠페인에 콘텐츠를 게재한다고 말합니다. 이제 게재가 실제로 무엇을 의미하는지 확인해 보세요. 채널이 에셋의 또 다른 복사본을 단순히 전달받고 있습니까? 아니면 관리되는 원본에 연결된 게재 레이어를 통해 콘텐츠를 직접 요청하고 있습니까? 에셋이 변경되거나, 재승인되거나, 만료되거나, 사용 권한을 잃으면 이미 시장에 배포된 콘텐츠는 어떻게 됩니까? 변경 사항이 자동으로 반영됩니까? 아니면 누군가가 채널 전반에 걸쳐 복사본을 일일이 찾아 교체해야 합니까?

DAM 외부에서도 테스트를 진행해 보세요. 벤더에게 실시간 채널이 에셋을 요청하는 방식 그대로 직접 시연해 달라고 하세요. 그런 다음 관리되는 버전을 변경하고 다시 요청해 보세요. 고객에게 전달되는 콘텐츠는 누군가가 수동으로 복사본을 일일이 찾아다니지 않아도 현재의 승인된 상태를 반영해야 합니다. 관리되는 콘텐츠를 저장하는 것과 게재하는 것은 전혀 다른 문제입니다.

이제 다섯 가지를 모두 합쳐 보겠습니다. 연결, 도달 범위, 워크플로, 보강, 게재 — 누구든 이 모두에 '예스'라고 말할 수 있습니다. 하지만 그 '예스'가 실제로 무엇을 의미하는지가 중요합니다. 사람, 애플리케이션, 에이전트가 관리되는 연결을 통해 실제로 작동할 수 있을까요? 에셋과 그 맥락, 그리고 적합한 표현 방식에 접근할 수 있을까요? 콘텐츠가 공급망을 이동하는 동안 불필요한 복사본이 쌓이거나 각 단계에서 맥락을 잃지 않을 수 있을까요? 시간이 지남에 따라 콘텐츠의 맥락이 더욱 풍부하고 유용해질까요? 그리고 승인된 콘텐츠가 관리되는 소스와의 연결을 유지하면서 최종적으로 고객에게 도달할 수 있을까요?

이것이 AI가 활용해야 할 토대입니다. 에이전트는 그 아래에 있는 문제를 해결하지 않습니다. 있는 그대로를 이어받아 더 빠르게, 더 큰 규모로 실행할 뿐입니다. 연결되고 맥락을 갖춘 관리되는 콘텐츠 공급망 내에서 작동하는 에이전트가, DAM 외부에 단순히 덧붙인 에이전트와 근본적으로 다른 이유가 바로 여기에 있습니다. 다음 포스트에서 이 주제를 이어서 살펴보겠습니다.

Adobe 직접 테스트하기

테스트는 언제든 환영합니다. 다음은 Adobe가 공개적으로 문서화하고 보증하는 내용을 기준으로, Adobe Experience Manager Assets가 각 질문에 답변하는 방식입니다.

연결. 팀은 이미 사용 중인 도구에서 지원 연결을 통해 에셋에 액세스할 수 있습니다. Adobe Asset Link를 통한 Creative Cloud, Adobe Workfront, 나머지 Experience Cloud, 그리고 자체 워크플로로 확장 가능한 개방형 API까지 연결됩니다. Dynamic Media도 함께 활용할 수 있습니다. 에이전트를 도입하더라도 동일한 원칙이 적용됩니다. 통합된 Adobe Experience Manager의 MCP Server는 Adobe Experience Manager의 기존 권한 모델 내에서 작동하므로, 에이전트는 별도의 우회 경로 없이 인증된 사용자의 ID와 권한에 따라 작동합니다. 변경 및 삭제 작업의 경우, Adobe는 에이전트를 AI 어시스턴트 인터페이스로 안내하며, Adobe Experience Manager 에이전트에는 기본 제공 보호 기능이 포함되어 있습니다.

도달 범위. 이 연결을 통해 애플리케이션이나 에이전트는 파일 그 이상에 접근할 수 있습니다. 파일을 실제로 활용 가능하게 만드는 메타데이터와 비즈니스 맥락, 즉 팀이 실제로 검색에 활용하는 커스텀 필드(예: 제품, 시장, 캠페인, 채널, 권리, 승인 상태)와 에셋 간의 관계 정보 및 출처 정보에도 접근할 수 있습니다. Adobe Experience Manager의 콘텐츠 검색은 이러한 필드를 대상으로 자연어로 작동하므로, 에이전트는 파일명이 일치하는 에셋이 아닌 작업에 가장 적합한 에셋을 찾아낼 수 있습니다. 특정 크기, 자르기 또는 형식이 필요할 때는 Dynamic Media with OpenAPI가 별도의 복사본 생성 없이 참조 방식으로 해당 렌디션을 생성하고 제공하며, 승인된 에셋만 노출됩니다.

체이닝. 실제 업무는 여러 시스템을 넘나들며, 시스템 간 이동이 발생할 때마다 연결고리를 잃을 위험이 생깁니다. 애플리케이션과 채널이 관리되는 전달 경로를 통해 콘텐츠를 사용하면, 에셋은 각 도구가 개별적으로 관리해야 하는 복사본이 아닌 승인된 원본에 대한 참조로 유지될 수 있습니다. 관리되는 에셋에 한 번 변경이 이루어지면 해당 참조가 사용된 모든 곳에 즉시 반영되므로, ID, 권리, 승인 상태 정보가 각 단계에서 재구성되는 대신 에셋과 함께 유지됩니다. 워크플로에서 생성되는 복사본이 줄어들수록, 콘텐츠·컨텍스트·거버넌스가 손상될 수 있는 지점도 그만큼 줄어듭니다.

보강. 보강은 수집 단계에서 시작됩니다. 지원되는 이미지, 영상, 텍스트 에셋에 대한 스마트 태그, 호환 릴리스에서 AI가 생성하는 제목·설명·키워드, 그리고 비즈니스와 브랜드 맥락을 담은 사용자 정의 메타데이터 스키마가 여기에 포함됩니다. 이 맥락은 관리되는 에셋의 일부가 되어, 단일 검색창에 갇히는 대신 검색과 탐색을 통해 크리에이티브 팀, 다운스트림 애플리케이션, 에이전트가 활용할 수 있게 됩니다. 나아가 사용 및 게재 신호는 리포팅 및 최적화 워크플로에 활용될 수 있으며, Adobe는 메타데이터와 사용 신호를 기반으로 탐색, 거버넌스, 콘텐츠 추천을 지원하는 에이전틱 기능으로 Adobe Experience Manager Assets를 확장하고 있습니다. 태그 몇 개를 생성하는 것은 기본 중의 기본입니다. 사람과 AI가 실제로 활용할 수 있는 관리된 맥락을 구축하는 것, 그것이 진정한 기준입니다.

게재. 콘텐츠는 고객에게 도달해야 비로소 가치를 발휘하며, 바로 이 지점에서 거버넌스가 제대로 작동하는지 여부가 드러납니다. Dynamic Media with OpenAPI를 사용하면, 소비 애플리케이션과 채널은 원본 바이너리의 복사본이 아닌 승인된 에셋을 참조하는 게재 URL을 받을 수 있으며, 승인된 에셋과 최신 승인 버전만 노출됩니다. 관리되는 에셋이 변경되거나 재승인, 만료, 또는 권리를 상실하는 경우, 변경 사항은 전달 경로를 통해 자동으로 반영됩니다. 각 채널에 퍼진 오래된 복사본을 일일이 찾아다닐 필요가 없으며, 문서화된 캐시를 기반으로 업데이트는 일반적으로 10분 이내에 반영됩니다. 관리되는 콘텐츠를 저장하는 것과 게재하는 것은 엄연히 다른 문제입니다.

이 모든 것은 머신 속도에서도 안정적으로 작동해야 합니다. 에이전트는 사람과 달리 수많은 요청을 처리하기 때문에, 기반 아키텍처가 그 무엇보다 중요합니다. Adobe Experience Manager Assets는 클라우드 네이티브로 구축되어 워크로드에 따라 유연하게 확장되며, Dynamic Media with OpenAPI는 확장 가능한 애플리케이션 및 머신 환경을 위해 설계된 관리형 콘텐츠 전송 네트워크 (CDN)와 엣지 캐싱을 통해 콘텐츠를 제공합니다. 변환은 엣지에서 처리되어 오리진 서버의 부하를 줄입니다. 실제 성능은 요청 유형, 변환, 캐싱, 구성에 따라 달라집니다. 바로 이러한 이유로, 데모의 일회성 성능이 아닌 실제 에셋과 워크플로를 활용한 대표적인 검증만이 성능을 제대로 입증하는 방법입니다.

다섯 가지를 모두 갖추면 에이전트에게 진정으로 필요한 기반이 완성됩니다. 관리되는 연결, 컨텍스트에 대한 실질적인 접근, 각 단계에서 복사본 증식을 방지하는 공급망, 지속적으로 더욱 유용해지는 컨텍스트, 그리고 소스와의 연결을 유지하면서 고객에게 전달되는 승인된 콘텐츠가 바로 그것입니다. 에이전트는 기반 구조의 문제를 해결하지 않습니다. 그 구조를 그대로 물려받아 더 빠르고 더 큰 규모로 작동할 뿐입니다. 이것이 바로 연결되고 관리되는 콘텐츠 공급망 안에서 운영되는 에이전트와 DAM에 단순히 덧붙여진 에이전트의 차이입니다.

저희 말만 믿으실 필요가 없습니다. Adobe는 2025 Gartner® Magic Quadrant™ for Digital Asset Management Platforms 및 The Forrester Wave™: Digital Asset Management Systems, Q1 2026에서 리더로 선정되었습니다.

다음 벤더 미팅에서 활용하기

이 질문들을 최종 후보 업체와의 모든 미팅에 가져가세요. 저희와의 미팅도 예외가 아닙니다. '가능한지'를 묻지 말고, 실제로 해보도록 요청하세요. 사전에 준비된 샌드박스가 아닌 실제 에셋으로, 실시간으로 직접 확인하세요. 팀이 실제로 사용하는 도구와 연결해 보고, 해당 애플리케이션이 관리되는 에셋을 기반으로 작동하는지, 아니면 단순히 복사본을 가져오는지 확인하세요. 파일 너머로 어디까지 연결이 가능한지도 물어보세요. 에셋이 소스에서 배치 지점에 이르기까지 몇 단계를 거치는지 세어보세요. 무언가를 수집해 보고 플랫폼이 어떻게 처리하는지 확인하세요. 그런 다음 실시간 채널이 요청하는 방식으로 콘텐츠를 요청하고, 승인된 버전을 변경한 후, 누구도 복사본을 일일이 추적하지 않아도 고객에게 전달되는 콘텐츠가 자동으로 업데이트되는지 확인하세요. 실제로 예상되는 사람과 에이전트의 동시 활동을 반영한 현실적이고 대표적인 워크로드로 테스트하세요. 데모 수준의 성능에 만족하지 마세요.

각 공급업체가 실제 증거 대신 슬라이드나 로드맵, 구두 설명에 의존하는 순간을 주목하세요. 그 순간 자체가 이미 답입니다. 약속이 증거로 이어지지 못하는 지점이 바로 그때이기 때문입니다. 5가지 항목 모두에서 근거를 제시할 수 있는 공급업체가, 데모의 기억이 희미해진 3년 후에도 AI 워크플로를 안정적으로 운영할 파트너일 가능성이 가장 높습니다.

모든 DAM이 "가능하다"고 답합니다. 하지만 실제로 보여줄 수 있는 곳은 극히 드뭅니다.

자주 묻는 질문