Notion의 모든 직원에게 개인 데이터 사이언티스트를 제공하기까지

Notion의 데이터팀은 데이터 관련 질문을 다룰 때마다 처리 여력이 부족해 번번이 벽에 부딪혔습니다. 누군가 Slack에 질문을 올리면 데이터 사이언티스트가 요청을 분류하고, 적절한 데이터 출처를 찾고, 정의를 확인하고, 쿼리를 작성한 뒤 결과를 설명해야 했습니다. 일상적인 질문조차 며칠이 걸릴 수 있었죠.

이러한 과정을 단축하기 위해 사내 데이터 에이전트인 Data Scout를 개발했습니다. 이제 Notion 직원이라면 누구나 일상적인 표현으로 질문하고 Snowflake의 관리 체계가 적용된 데이터를 바탕으로 답변을 얻을 수 있습니다. 도입 후 두 달 만에 데이터팀에 들어오는 주간 요청이 약 80% 감소했으며, 이전에는 처리 순서를 기다려야 했던 질문도 이제는 몇 분 만에 답을 얻을 수 있습니다.

이러한 변화로 데이터팀은 업무 시간을 확보할 수 있었습니다. 팀원들은 같은 수치를 반복해서 조회하거나 같은 분석을 조금씩 변형해 반복할 필요 없이, 전문성과 판단력이 필요한 심층적인 업무에 집중할 수 있게 됐습니다.

현재 Notion 직원의 절반가량이 Data Scout를 사용합니다. 하지만 더 큰 변화는 사람들이 일하는 방식이 달라졌다는 점입니다. 팀원들은 조사하고, 보고서를 작성하고, 회의를 준비하는 과정에서 Data Scout에 필요한 수치를 조회해 달라고 요청합니다. “Data Scout에 물어보셨나요?”라는 질문도 이제 흔해졌습니다. 직원들은 티켓을 접수하고 기다리지 않고도 데이터를 의사결정에 활용할 수 있습니다.

저는 Data Scout 구축에 참여한 데이터 엔지니어입니다. 이 글에서는 Data Scout를 왜 만들었고 어떤 변화가 있었는지 비즈니스 리더들에게 소개하고자 합니다. Data Scout의 구축 방식이 궁금한 데이터 엔지니어 동료들에게도 유용한 참고 자료가 되기를 바랍니다. 먼저 현재 팀에서 Data Scout를 어떻게 활용하는지 살펴본 다음, 구축 과정에서 내린 기술적 선택과 그에 따른 트레이드오프를 다뤄 보겠습니다.

Data Scout는 Snowflake의 관리 체계가 적용된 데이터와 Notion의 사내 지식, Slack 같은 연동 소스를 함께 활용합니다. Snowflake는 데이터 접근 권한을 적용하고, Notion은 에이전트와 도구에 대한 접근을 제어하는 한편 각 질문을 이해하는 데 필요한 업무 맥락을 제공합니다.

이러한 공통 기반과 권한 모델 덕분에 여러 팀이 같은 에이전트를 활용해 다양한 의사결정을 내릴 수 있습니다. 영업팀은 고객의 제품 활용 현황을 확인하고, 프로덕트팀은 온보딩 과정의 이탈을 살펴보며, 고객경험팀은 고객 지원 문의량을 조사할 수 있습니다.

Data Scout에 입력된 실제 질문 200개를 표본으로 분석한 결과, 자주 등장한 주제는 다음과 같습니다.

각 요소가 어떻게 어우러지는지 살펴보기 위해 고객사와의 계약 갱신을 준비하는 GTM팀 팀원 한 명의 업무 과정을 따라가 보겠습니다.

이 팀원은 “이 고객사에서 AI 도입이 늘고 있나요?”라고 질문합니다. 유용한 답변을 얻으려면 적절한 사용량 지표와 고객사 범위는 물론, 고객의 목표와 계획된 AI 도입·확대 계획도 알아야 합니다. Data Scout는 Snowflake의 사용량 데이터와 Notion에 기록된 고객사 관련 메모, 과거 회의 기록을 함께 분석해 AI 도입이 고객의 계획에 부합하는지 보여줍니다.

첫 번째 답변은 종종 “어떤 팀에서 AI 도입이 늘고 있나요?” 또는 “이러한 증가는 신규 사용자 유입 때문인가요, 아니면 기존 사용자의 활용도가 높아졌기 때문인가요?”와 같은 후속 질문으로 이어집니다. 후속 질문이 생길 때마다 새로운 데이터 요청을 접수하는 대신, 계정 관리자는 같은 대화에서 데이터를 더 자세히 살펴볼 수 있습니다. 이를 통해 다가오는 계약 갱신 회의에 참석할 때는 어떤 변화가 있었는지 종합적으로 파악할 수 있습니다.

시간이 지나면서 팀들은 공유 MCP 연결을 통해 Data Scout에 연결되는 에이전트를 만들고, 관리 체계가 적용된 데이터에 대한 접근 권한과 사내 업무 맥락을 재사용했습니다. 그 결과 두 가지 유형의 활용 방식이 나타났습니다.

• 반복적인 분석: Data Scout Reporter는 Data Scout에 연결해 저장된 리포트 정의를 바탕으로 Notion과 Slack에서 정기 리포트를 생성합니다. 덕분에 팀은 매주 분석을 다시 실행하지 않고도 같은 지표의 변화를 추적할 수 있습니다.

• 분야별 전문성: 팀들은 Data Scout의 관리 체계가 적용된 데이터와 맥락을 활용하면서도, 각자의 워크플로에 맞는 더 구체적인 지침을 갖춘 전문 에이전트를 구축했습니다.

Data Scout는 Notion에서 가장 많이 사용되는 사내 에이전트이지만, 관련 에이전트들도 각자 인기를 얻었습니다. Data Scout는 그때그때 질문이 있을 때 사용하는 에이전트이고, 관련 에이전트들은 그 기반을 활용해 반복적이고 팀별 특성에 맞는 업무를 지원합니다. 하지만 더 많은 팀과 에이전트가 같은 기반을 재사용하면서 답변의 신뢰성을 유지하는 일이 더욱 어려운 과제로 떠오르게 되었습니다.

쿼리가 오류 없이 실행되더라도 엉뚱한 질문에 답할 수 있다는 것을 알게 되었습니다. 어려운 점은 질문이 쿼리로 바뀌고 쿼리가 답변으로 이어지는 과정에서 업무상의 의미를 온전히 유지하는 것이었습니다. 도입 관련 질문을 예로 들어보겠습니다. SQL이 정상적으로 실행되더라도 답변은 네 가지 방식으로 잘못될 수 있습니다.

• 의미가 잘못될 수 있습니다. 한 사람이 여러 워크스페이스에 속해 있을 때 사용자 수 대신 워크스페이스 멤버 수를 세면 도입률이 실제보다 높게 집계될 수 있습니다.

• 라우팅이 잘못될 수 있습니다. 에이전트가 그럴듯한 테이블이나 연결을 찾더라도 지속적으로 관리되는 정의와 필수 필터를 찾지 못할 수 있습니다.

• 측정이 잘못될 수 있습니다. 사용량 추적 방식이 바뀌거나 과거 데이터가 수정되면 고객의 실제 사용 방식에는 변화가 없는데도 도입률이 오르거나 내린 것처럼 보일 수 있습니다.

• 해석이 잘못될 수 있습니다. 올바른 수치도 잘못 해석될 수 있습니다. 고객이 팀별로 차례차례 AI를 도입하고 있다면 도입률이 정체된 것처럼 보여도 실제로는 계획에 맞게 진행 중일 수 있습니다. 이러한 맥락은 Snowflake가 아니라 Notion의 고객사 관련 메모와 과거 회의 기록에 담겨 있습니다.

우리가 얻은 교훈은 분명했습니다. 잘 정리된 맥락은 연결 자체만큼 중요합니다. 데이터에 접근할 수 있다는 사실만으로는 에이전트가 어떤 정의를 신뢰해야 하는지, 어떤 출처를 사용해야 하는지, 결과가 업무상 어떤 의미인지 알 수 없습니다. 이러한 지식을 관리할 담당자와 지식을 최신 상태로 유지할 방법이 필요합니다.

우리는 관리 체계가 적용된 에이전트와 데이터 접근 권한, 공유 데이터 맥락, 명확한 지침을 기반으로 에이전트를 구축합니다. 이 세 가지는 에이전트의 권한과 에이전트가 활용하는 지식, 에이전트가 따르는 절차를 정의합니다.

이 세 가지 기반만으로는 답변의 신뢰성을 보장할 수 없습니다. 그래서 우리는 결과를 검증하고, 에이전트가 어떤 과정을 거쳐 결과를 도출했는지 살펴보며, 데이터와 비즈니스 환경이 변화함에 따라 지침을 업데이트합니다.

Notion과 Snowflake는 워크플로의 서로 다른 부분을 관리합니다. Notion은 워크스페이스에 대한 접근 권한과 사용 가능한 도구를 관리하고, Snowflake는 쿼리를 실행하는 사용자의 신원에 따라 데이터 접근 권한을 적용합니다.

• 사용자는 커스텀 에이전트 또는 Notion 에이전트를 통해 Snowflake MCP에 연결할 수 있습니다. 어떤 경로로 연결하든 각 사용자는 자신의 인증 정보로 Snowflake에 로그인해야 합니다. 이렇게 하면 쿼리는 해당 사용자의 인증된 Snowflake 계정으로 실행되며, 답변에는 해당 사용자의 데이터 접근 권한이 반영됩니다.

• Snowflake의 데이터 제어 기능은 역할과 권한 부여 설정을 적용하고, 데이터 마스킹과 행 수준 정책이 구성된 경우 이를 통해 워크플로에 필요한 데이터와 작업으로 권한을 제한합니다.

계정 관리자의 쿼리는 연결에 설정된 데이터 접근 권한을 준수해야 하며, 결과는 공유되는 리포트나 채널에 적합해야 합니다. 에이전트는 찾기 어려웠던 데이터를 찾아 제시할 수 있지만, 접근 권한 제어를 우회하지는 않습니다.

공유 데이터 맥락은 에이전트가 동일한 정의와 데이터 출처 지침을 활용하도록 돕습니다. Notion은 업무 맥락을 모아 두는 중심 공간으로, 에이전트가 질문의 의미를 더 잘 이해하는 데 활용할 수 있는 계획, 의사결정, 고객 관련 지식을 담고 있습니다.

참조 정보가 한곳에 모여 있더라도 다음 항목별 책임 범위는 명확히 구분합니다.

• 데이터 맥락은 계산 방식을 관리합니다. 여기에는 지표, 출처, 데이터 단위, 관계, 필수 필터, 최신성 등이 포함됩니다.

• 업무 맥락은 목표, 회사에서 사용하는 용어, 고객 이력, 결과를 해석하는 데 도움이 될 수 있는 상황을 설명합니다.

• 라우팅 지침은 승인된 출처, 연결, 도구 중 적절한 것을 선택하고 관련 맥락을 찾습니다. 단일 데이터 웨어하우스 내의 테이블뿐 아니라 여러 Snowflake 연결이나 서로 다른 플랫폼에 걸쳐 적용될 수 있습니다.

우리는 정의, 스키마, 스킬, 알려진 데이터 변경 사항을 위한 공유 인덱스로 Notion 데이터베이스를 사용합니다. 각 행은 개별 페이지이기도 합니다. 각 페이지의 속성은 에이전트가 관련 지침을 찾는 데 도움을 주며, 본문에는 에이전트가 활용해야 하는 정의, 절차, 주의 사항, 참조 자료가 담겨 있습니다.

에이전트는 데이터베이스 전체를 불러오는 대신 선택한 페이지의 본문을 읽고 관련 참조를 따라갑니다. 메타데이터는 에이전트가 적절한 맥락을 찾는 데 도움을 주지만, 맥락 자체를 대체하지는 않습니다. 정의가 다른 곳에 있는 경우, 해당 항목은 정의를 복사하는 대신 그 정의가 관리되는 원본 출처를 참조합니다.

Notion을 선택한 이유는 우리 팀이 이미 관리하고 있는 계획, 의사결정, 고객 관련 지식과 업무 맥락을 함께 활용할 수 있기 때문입니다. 에이전트는 같은 워크스페이스에서 지표 정의와 그 의미를 설명하는 고객사 관련 메모를 읽을 수 있습니다. 담당자는 Notion의 기존 권한을 활용해 익숙한 페이지를 편집하고 공유할 수 있으며, 에이전트는 페이지 속성을 통해 항목을 찾은 다음 본문을 읽습니다. 더 빠르게 검색하기 위해 모든 지침을 데이터베이스 속성에 넣어 봤지만, 메타데이터에 너무 많은 정보가 몰리면서 유지 관리도 더 어려워졌습니다.

이 방식의 한계는 검색 가능한 페이지 라이브러리만으로는 지표 정의를 적용하거나 시맨틱 계층을 대체할 수 없다는 점입니다. 여전히 명확한 담당자와 최신 상태로 관리되는 출처 참조 정보, 검토 프로세스가 필요합니다. 이 때문에 우리는 아래에서 설명하는 검토·분류 과정을 지속적으로 운영합니다.

그럼에도 Notion은 우리에게 딱 맞는 공간이었습니다. 수치의 의미를 잘 아는 사람들이 이미 Notion에 관련 내용을 기록하고 있기 때문에, 수치에 관한 정보를 업데이트하는 업무와 그 맥락이 밀접하게 맞닿아 있습니다. 고객은 Snowflake Semantic Views와 Cortex Analyst 같은 기존 도구에서 데이터 전문성을 계속 활용하면서, 이를 Notion의 업무 맥락과 연결할 수 있습니다.

라우팅 가이드는 쿼리를 작성하기 전에 검색 범위를 좁히고, 데이터 정의와 업무 맥락에 따른 해석을 구분합니다. 이는 하나의 예시이며, 연결되는 시스템은 각자의 환경에 따라 달라집니다.

검색 지침은 테이블을 선택하기 전에 관련 분야 한두 개와 관련 스킬부터 살펴봅니다. 우선순위가 높고 질문에 정확히 부합하는 스킬이나 자주 묻는 질문(FAQ)만으로도 특정 정보를 조회하기에 충분할 수 있습니다. 에이전트는 관련 지침이 없을 때만 검색 범위를 넓힙니다.

인덱스는 에이전트가 적절한 페이지를 찾고 해당 페이지의 용도를 이해하는 데 도움을 줍니다. 다음 필드는 검색 지침에 따른 것이며, 예시 값은 이해를 돕기 위한 것입니다.

각 행을 열면 제목 구성이 일관된 페이지가 열립니다. 간단한 스킬 항목은 다음과 같은 형태입니다.

유형이 중요합니다. 스킬은 절차를 제공하고, 지표 정의는 계산 방법을 제공하며, 테이블 스키마는 데이터 단위, 필터, 조인, 주의 사항을 제공합니다. 이 항목은 별도의 정의를 새로 만드는 대신 지속적으로 관리되는 정의를 참조합니다.

검토 상태, 최신성, 담당자도 여전히 중요합니다. 우선순위는 검색 순서를 좌우할 뿐, 승인 여부나 접근 권한에는 영향을 주지 않습니다.

좋은 맥락이라도 이를 일관되게 활용하는 방법이 필요합니다. 명확한 지침은 에이전트가 올바른 출처를 선택하고 작업 결과를 확인하며, 답변을 뒷받침할 수 없을 때 중단하도록 돕습니다.

질문과 출처가 명확하고 실행이 성공적으로 이루어졌더라도, 그 결과를 답변으로 제시하기 전에 확인해야 합니다.

검색 가이드에는 오류 발생 시 대응 방법도 구체적으로 명시되어 있습니다. 필요한 열이 문서화되어 있지 않으면 관련 스키마를 살펴봅니다. Snowflake에서 잘못된 식별자 오류가 발생하면 그럴듯한 다른 열 이름을 시도하는 대신 스키마를 확인합니다.

불러온 지침에 필요한 필드가 이미 문서화되어 있다면, 에이전트는 광범위한 스키마 정보를 다시 가져오지 않고도 해당 지침을 활용할 수 있습니다. 이러한 선택은 쿼리나 검색 호출을 어디에 사용할지 구체적으로 결정하는 것입니다.

• 계산하기 전에 지표, 고객사 또는 대상 집단, 기간, 비교 기준을 정합니다.

• 승인된 연결과 출처로 라우팅한 다음, 관련 분야 가이드나 스킬을 사용합니다.

• 조인 카디널리티, 필터, 분모, 아직 끝나지 않은 기간 등을 포함해 쿼리 로직과 쿼리 결과 데이터를 확인합니다.

• 임의로 우회 방법을 만들어 내지 말고, 정의 누락, 접근 거부, 검사 실패를 표시합니다.

• 수치 자체의 불확실성과 그 수치에 대한 설명의 불확실성을 구분합니다.

분석 결과와 이를 뒷받침하는 근거를 먼저 제시하세요. 독자가 답변을 검증하는 데 도움이 되는 경우가 아니라면, 중간 쿼리는 주요 답변에 포함하지 마세요.

앞서 살펴본 고객사별 도입 현황 사례로 돌아가 보겠습니다. Data Scout는 고객사 계획을 바탕으로 추세를 해석하기 전에 측정값 자체에 문제가 없는지 확인합니다.

• 엔터티 확인: 고객사와 워크스페이스 간 매핑이 대상 고객사를 포함하면서 사용자나 활동이 중복되지 않는지 확인합니다.

• 메트릭 확인: 분자, 분모, 제외 항목, 기간이 지속적으로 관리되는 정의를 따르는지 확인합니다.

• 데이터 확인: 해당 기간의 데이터가 비교하기에 충분히 확보되었는지, 알려진 추적 방식의 변경 사항과 과거 데이터 보완 작업이 반영되었는지 확인합니다.

• 스냅샷 확인: 출처에 엔터티당 하루 한 행이 있는 경우, 현재 상태를 조회할 때는 기준 날짜를 하나만 사용합니다. 여러 날에 걸친 범위에서는 동일한 엔터티가 반복 집계될 수 있으므로, 명시적으로 추세를 분석할 때만 해당 범위를 사용합니다.

• 해석 확인: 응답에서 측정된 변화와 롤아웃 메모나 고객과의 대화에 담긴 가능한 설명을 구분합니다.

계정 관리자는 추가 질문을 하고 데이터 출처를 확인할 수 있지만, 최종 의사결정은 고객사 담당팀의 몫입니다.

데이터와 업무 환경은 계속 변화하므로, 관련 지침도 이에 맞춰 업데이트해야 합니다. 모델, 정의, 데이터 출처 시스템이 바뀌면 데이터 맥락도 달라지고, 계획, 의사결정, 고객 활동이 달라지면 업무 맥락도 달라집니다. Notion에서는 데이터베이스 자동화가 아니라 특정 범위에 맞게 설정된 커스텀 에이전트를 사용해 이러한 지침을 유지합니다. 매일 밤 검토 에이전트가 Data Scout의 대화와 쿼리, Slack, Notion, GitHub를 살펴보며 누락되었거나 최신 상태가 아니거나 서로 모순되는 맥락을 찾아 그 내용을 기록합니다. 그런 다음 분류 에이전트가 중복을 제거하고 근거가 충분한 소규모 수정 사항을 적용합니다. 모호하거나 위험도가 높은 내용은 추가 검토를 위해 사람에게 전달합니다.

이 검토 프로세스는 변경의 근거와 해당 변경을 적용할 권한을 구분합니다.

• 근거가 있다고 해서 승인된 것은 아닙니다. Slack에서 수정 사항이 제기되면 조사할 이유는 되지만, 그것만으로 메트릭을 다시 작성할 권한이 생기는 것은 아닙니다.

• 병합되었다고 해서 배포된 것은 아닙니다. PR 하나만으로 변경 사항이 실제 적용되었거나 과거 데이터가 보완되었다고 볼 수 없습니다.

• 재사용하기 전에 검토합니다. 승인된 변경 사항만 적용하고, 사람이 나중에 편집한 내용은 유지하며, 업데이트가 올바르게 적용되었는지 확인합니다. 불분명하거나 영향이 큰 변경 사항은 담당자에게 전달합니다.

고객사별 도입 현황 사례에서는 이벤트 이름이 변경되거나 인시던트가 해결되면 데이터 출처 지침을 업데이트해야 할 수 있습니다. 답변을 생성하는 에이전트는 답변 과정에서 자체 정의를 임의로 수정하지 말고, 검토가 완료된 업데이트를 사용해야 합니다. 함께 제공되는 가이드에서 검토·분류 워크플로를 더 자세히 설명합니다.

쿼리 실행 래퍼인 run_tagged_query는 메타데이터와 실행을 한 번의 호출로 결합합니다. SQL에 구조화된 메타데이터를 JSON 주석으로 추가한 다음 내부적으로 업스트림 Snowflake 쿼리 도구를 호출합니다.

메타데이터에는 기준 지표, 정의 참조 정보, 맥락 페이지, 필터, 시간 범위, 질문 ID 등이 포함될 수 있습니다. SQL 주석은 Snowflake의 기본 제공 QUERY_TAG 세션 매개변수가 아닙니다. 실행 계층에서 안정적인 Snowflake 세션을 제어할 수 있다면 동일한 메타데이터를 QUERY_TAG로도 설정할 수 있습니다. 그러면 ACCOUNT_USAGE.QUERY_HISTORY에서 쿼리의 귀속 정보를 직접 필터링할 수 있습니다. 별도의 도구 호출이 같은 세션을 공유한다고 가정하지 마세요. 풀링된 세션에서도 잘못된 귀속을 방지하기 위해 태그를 확실하게 교체하거나 지워야 합니다.

이러한 추적 기록은 분석 과정을 살펴보고 어느 부분을 개선해야 할지 판단하는 데 도움이 됩니다.

• 같은 의미의 질문에 각각 의도한 정의와 범위가 적용되고 있나요?

• 실패의 원인은 누락된 맥락, 잘못된 출처, 실행 문제 중 무엇인가요?

• 쿼리나 맥락 조회가 불필요하게 반복되는 부분은 어디인가요?

• 반복되는 질문 중 재사용 가능한 분석 패턴이나 리포트가 필요한 것은 무엇인가요?

도입 현황에 관한 질문에 서로 다른 답변이 나온다면, 추적 정보를 통해 고객사 매핑, 모집단 필터 또는 시간 범위가 서로 다르다는 점을 파악하는 데 도움이 될 수 있습니다. 그런 다음 데이터 정의, 라우팅, 검증 지침 중 어느 부분을 수정해야 할지 조사할 수 있습니다.

데이터 담당자가 검증한 답변과 대조해 확인하는 절차를 계속 개선하고 있습니다. 즉, 필요한 경우 고정된 기간이나 스냅샷을 사용해 동일한 대표 질문을 기준으로 맥락과 에이전트 지침의 변경 사항을 테스트합니다. 쿼리 성공과 사용량 증가는 유용한 신호이지만, 어느 쪽도 정확성을 입증하지는 못합니다.

이러한 추적 정보는 유용하지만 한계가 있습니다. 일관성이란 SQL이 완전히 동일해야 한다는 뜻은 아닙니다. 동등한 쿼리라도 형태가 다를 수 있고, 권한에 따라 결과가 달라질 수도 있으므로 우리는 대신 정의, 범위, 기간을 비교합니다. 읽기 전용 쿼리도 리소스를 소비하므로 도구를 필요한 작업에 집중해 사용하고 조사 범위를 제한합니다. 검색이나 재시도를 늘린다고 답변의 품질이 자동으로 향상되는 것은 아닙니다. 래퍼는 기본적으로 엄격한 기준을 적용하지 않으므로, 귀속 정보가 불완전하더라도 유효한 쿼리가 차단되지 않습니다. 더 엄격한 메타데이터 검사를 활성화할 수 있지만, 두 모드 중 어느 쪽도 답변이 정확하다는 것을 입증하거나 데이터 접근 권한을 변경하지는 않습니다.

승인된 데이터와 지속적으로 관리되는 지침을 바탕으로 자주 나오는 질문 몇 가지부터 시작하세요. 먼저 회사 전체를 문서화하려 하기보다, 이 질문들을 토대로 에이전트에 필요한 것이 무엇인지 결정하세요.

• 데이터 담당자가 신뢰하는 허용된 데이터와 정의를 선택하세요.

• 관련 업무 지식을 활용하고 분석 절차를 명확하게 정리하세요.

• 에이전트의 작업 내용을 검토하고, 시스템이 변화하는 과정에서도 수정 사항을 검토할 방법을 마련해 두세요.

Notion에서 데이터 에이전트를 어떻게 설정했는지 자세히 알아보려면 도움말 센터 가이드에서 연결 옵션, 에이전트 지침 예시, 라우팅 지침, 유지 관리 워크플로, 실제 쿼리 로깅 예시를 확인하세요.

팀을 위한 데이터 에이전트 구축에 관심이 있다면, Snowflake 기반 Notion 에이전트 설정을 지원하는 얼리 액세스 프로그램에 참여해 보세요. 자세한 내용은 여기에서 문의하세요.