이제 Snowflake Workspaces에서 시맨틱 뷰를 작성하고, Snowflake CoCo, Git, CI/CD까지 한 곳에서 활용할 수 있습니다.
AI 에이전트가 잘못된 답변을 내놓으면, 모니터링의 요청 ID에서 실제 오류 원인까지 찾아가는 데 오후 한나절이 걸릴 수도 있습니다. 원인을 찾고 나면 솔루션 자체는 대체로 간단한데도 말입니다.
에이전트 문제는 잘못된 지표 정의나 다른 지침에서 비롯되는 경우가 많고, 그 지침은 대개 시맨틱 뷰에 담겨 있습니다. 1~2년 전만 해도 Snowflake의 시맨틱 뷰는 단일 Snowflake Cortex Analyst 배포 환경에 컨텍스트를 제공하는 용도로 처음 도입되었습니다. 당시에는한두 명이 데이터를 충분히 이해하고 시맨틱 뷰를 유지 관리할 수 있을 것이라고 가정했습니다. 하지만 데이터 에이전트가 확산되면서 이제 시맨틱 뷰는 지표를 다루는 모든 에이전트와 모든 BI 도구가 참조하는 대상이 되었고, 한 줄만 수정해도 이들 모두에 영향을 줄 수 있게 되었습니다. 초기 사용자를 위해 만든 편집기는 Snowsight 인터페이스의 AI & ML 섹션에 있는 단일 페이지에 불과했고, 데이터 담당자들이 수행하던 다른 작업 환경과도 다소 동떨어져 있었습니다.
하지만 이제 시맨틱 뷰를 위한 IDE인 Semantic Studio가 GA로 제공됩니다. Semantic Studio는 시맨틱 뷰 작성을 Workspaces로 가져와 팀이 이미 사용 중인 SQL, Notebook/노트북, dbt 프로젝트 옆에 배치하고, 깊이 있는 Snowflake CoCo 통합과 Git 버전 관리, UX 개선을 더합니다.
지금 Snowflake에서 Semantic Studio 사용해 보기 | 설명서 보기
숫자 하나를 바로잡기까지
이전에는 에이전트 문제 하나를 해결하는 데도 여러 단계를 거쳐야 했습니다. 먼저 모니터링 화면에서 요청의 세부 정보와 요청 ID를 확인한 다음, 에이전트 트레이스를 열어 어느 도구에서 문제가 비롯되었는지 파악했습니다. 원인을 좁혀 나가려면 에이전트가 생성한 SQL을 읽고, 직접 작성했을 때의 쿼리와 비교해야 했습니다.
시맨틱 뷰 편집기는 Snowsight의 다른 섹션에 있었습니다. 어떤 에이전트 오류를 수정하고 있는지 UI가 알지 못했기 때문에, 편집기를 열면 항상 파일 맨 위부터 표시되었습니다. 지표 오류의 원인으로 짐작한 부분을 검증하려면 아직 저장하지 않은 정의를 대상으로 시맨틱 SQL을 실행해야 했습니다. 이를 위해 별도의 워크시트를 열고 에이전트가 생성했을 법한 쿼리를 직접 작성했습니다. 쿼리가 의도대로 작동하면 편집기로 돌아가 수정을 마무리하고, 다시 에이전트와 모니터링 화면을 차례로 확인하며 문제가 해결되었는지 검증했습니다.
한 줄을 수정하는 데 네 개의 화면을 오가야 했고, 화면마다 흩어진 정보를 연결해 작업을 이어 가는 일도 온전히 사용자의 몫이었습니다.
내부 텔레메트리 데이터에 따르면, 에이전트 개발자의 절반 이상이 시맨틱 뷰 UI와 에이전트 관리 UI를 오가며 작업하고 있었습니다. 유지 관리에서 무엇이 어려운지 물었을 때도, 개발자들이 꼽은 것은 편집 자체가 아니라 여러 화면을 오가며 정보를 연결하는 작업이었습니다.
Semantic Studio로 달라지는 오후
이 모든 정보를 서로 연결하는 일은 코딩 에이전트에게 맡기고 싶은 작업입니다. Semantic Studio에서는 Workspaces에서 시맨틱 뷰를 다루며, 편집기 옆 패널에서 CoCo를 사용할 수 있습니다. 탭을 전환할 때마다 페이지를 새로 불러올 필요가 없어 정의, 평가, 평가 결과 사이를 훨씬 빠르게 오갈 수 있습니다.
작업의 출발점은 이전과 같습니다. 모니터링 화면에서 요청 ID를 확인하는 것입니다. 하지만 이제는 ID를 CoCo에 전달하기만 하면 어떤 지표에서 해당 수치가 나왔고 왜 그런 결과가 나왔는지 알 수 있습니다. CoCo가 에이전트 구성, 실행된 쿼리, 로그에 함께 액세스할 수 있기 때문입니다. 답변은 자연어로 돌아오고, 바로 시맨틱 뷰 수정을 요청하면 됩니다.
정의와 그에 따른 결과 데이터를 나란히 확인할 수 있으면 답변도 더 쉽게 신뢰할 수 있습니다. 표현식을 읽고 결과를 상상하는 대신, CoCo에 어떤 결과가 반환되는지 물어보면 언제든 정의를 손쉽게 확인할 수 있습니다.
수정 사항은 추가, 삭제, 변경될 내용을 비교해 보여주는 diff 형식으로 제시되며, 사용자가 이를 수락하거나 거부할 수 있습니다. 수정 내용을 시각적 편집기나 YAML에서 확인할 수 있고, 둘 형식은 항상 동기화된 상태를 유지합니다.
해당 지표를 참조하는 다른 모든 에이전트와 대시보드에도 변경 사항이 적용되므로, 오후의 남은 시간에는 이를 신중하게 배포하는 데 집중할 수 있습니다. Workspaces에서 시맨틱 뷰는 팀이 소유한 리포지토리 안의 파일로 관리됩니다. 따라서 오브젝트를 바로 덮어쓰는 대신, 버전 단위로 다음 환경에 반영할 수 있습니다. 먼저 수정된 뷰에 대해 eval 세트를 실행하면, 기존에 올바르게 답하던 질문에 여전히 제대로 답하는지 확인할 수 있습니다.
그다음부터는 팀이 다른 변경 사항을 릴리스할 때와 같은 워크플로우를 따르면 됩니다. 변경 사항은 풀 리퀘스트로 제출되므로 다른 사람이 diff와 그 근거를 검토할 수 있고, CI는 병합 시 eval을 실행할 수 있습니다. 배포 단계에서는 무엇이 바뀌는지 정확히 보여주고 사용자의 확인을 기다립니다. 하나의 파일로 개발, 스테이징, 프로덕션 환경을 각각 지정할 수도 있습니다. 배포 후에는 작성자와 수정 이유가 변경 이력에 함께 남으며, 필요하면 변경 사항을 되돌릴 수 있습니다.
Semantic Studio 시작하기
이제 Snowsight에서 시맨틱 뷰를 열면 Semantic Studio로 이동합니다. 사용 중인 계정에서 Semantic Studio를 사용해 보세요. 자세한 내용은 설명서에서 확인할 수 있습니다.
