cloudflare·2026년 8월 5일·4분 읽기큐레이션 요약

Cloudflare OS: 에이전트, 앱 및 업무를 위한 개방형 플랫폼

Cloudflare OS는 회사의 지식·절차·용어·시스템을 에이전트가 활용하도록 만들어, 엔지니어뿐 아니라 모든 직원이 업무를 자동화하고 앱과 문서를 만들 수 있게 하는 플랫폼이다. 초기 버전의 한계였던 정적 앱, 반복적인 에이전트 실행, 데이터 권한 관리 문제를 해결하기 위해 보안과 거버넌스를 플랫폼의 핵심으로 재설계했다. 새 버전은 오픈 소스로 제공되며, 조직이 내부 시스템과 업무 방식을 연결해 직접 구축하고 확장할 수 있다. ## 조직의 맥락을 에이전트에게 전달하기 - 조직은 미션과 함께 고유한 용어, 절차, 시스템, 표준, 업무 방식을 구성원에게 전달한다. - 업무 결과는 코드뿐 아니라 문서, 발표 자료, 인간관계, 물리적 성과 등 다양한 형태로 나타난다. - 코드는 실행 여부라는 명확한 피드백이 있지만, 비정형 업무에는 조직의 맥락과 시스템 접근 권한이 필요하다. - Cloudflare OS는 회사가 축적한 지식과 반복 업무의 모범 사례를 에이전트가 따를 수 있는 컨텍스트와 스킬로 저장한다. - 한 사람이 더 나은 업무 방식을 만들면 조직 전체가 이를 재사용할 수 있다. ## 초기 버전에서 얻은 한계와 교훈 - 초기 Cloudflare OS는 개인별 비공개 워크스페이스 중심이었다. - 앱은 내부 시스템과 실시간으로 연결된 소프트웨어가 아니라 정적인 결과물에 가까웠다. - 결정적인 반복 작업도 스킬을 다시 실행해야 했고, 그만큼 추가 모델 토큰을 소비했다. - MCP 서버가 제공하는 도구 목록만으로는 에이전트가 실제로 어떤 데이터와 리소스를 관찰했는지 알 수 없었다. - 워크스페이스와 앱을 공유하면서, 사용자가 권한 없는 정보를 간접적으로 볼 가능성이 커졌다. - 이에 따라 보안을 앱 제작자나 개별 사용자에게 맡기지 않고 플랫폼 수준에서 처리하도록 새 기반을 설계했다. ## Cloudflare OS의 세 가지 구성 요소 - **조직 컨텍스트 기반 에이전트 워크스페이스** - 회사가 선별한 지식과 스킬을 바탕으로 대화하고 작업한다. - 에이전트가 코드를 작성·실행할 수 있는 격리된 런타임을 제공한다. - **보안·거버넌스 프레임워크** - 내부 데이터와 서비스에 대한 접근을 정책에 따라 통제한다. - 에이전트와 앱이 접근할 수 있는 리소스와 데이터의 이동 경로를 관리한다. - **수정 가능한 개인·협업 앱 플랫폼** - 대화에서 시작한 작업을 문서, 앱, 지속 실행 워크플로로 발전시킬 수 있다. - 사용자가 만든 앱을 공유하고 계속 수정할 수 있다. ## 브라우저 기반 에이전트 워크스페이스 - 개발자나 터미널 사용법을 몰라도 브라우저에서 사용할 수 있도록 설계됐다. - 워크스페이스는 다음 요소를 결합한다. - 에이전트 세션 - 지속 상태 - 파일과 산출물 - 외부 리소스 접근 - 코드를 작성하고 실행하는 격리 런타임 - 팀이나 회사가 수집한 컨텍스트와 스킬이 기본으로 포함되어 동일한 업무 절차를 매번 다시 설명할 필요가 없다. ### 조사와 질의 - 회사 컨텍스트와 허용된 리소스를 기반으로 주제를 조사할 수 있다. - 전체 데이터를 모델 컨텍스트에 넣는 대신, 에이전트가 코드를 작성해 검색·필터링·조인·분석을 수행한다. ### 문서·슬라이드·스프레드시트 생성 - 조사 결과를 문서, 프레젠테이션, 스프레드시트로 변환할 수 있다. - 결과물은 단순한 정적 파일이 아니라 원본 데이터와 연결된 상태로 유지될 수 있다. - 데이터가 변경되면 결과물을 갱신할 수 있으며, Google Drive 같은 기존 서비스나 익숙한 형식으로 내보낼 수도 있다. ### 협업 앱 구축 - 문서나 스프레드시트로 부족한 경우, 에이전트가 자체 인터페이스·로직·상태를 가진 앱을 만든다. - 앱은 회사 리소스와 연결될 수 있고 여러 사람이 함께 사용할 수 있다. ### 결정적 워크플로 실행 - 반복적인 업무의 예측 가능한 단계는 코드로 처리하고, 판단이 필요한 부분에만 모델을 사용한다. - 워크플로는 수동 실행, 예약 실행, 연결된 시스템의 이벤트 발생 시 실행이 가능하다. - 기존 MCP 서버는 MCP Server Portals를 통해 계속 사용할 수 있다. ## API 키 대신 세분화된 권한 모델 - 회사 시스템에 연결하기 위해 API 키를 에이전트나 사용자에게 직접 제공하는 방식은 위험하다. - API 키는 대개 권한 범위가 넓고 수명이 길며, 공유와 감사가 어렵다. - MCP 서버는 자격 증명을 내부에 보관하고 제한된 도구만 노출하므로 개선된 접근 방식이다. - 그러나 MCP만으로는 에이전트가 어떤 원본 리소스를 관찰했는지, 이후 데이터가 어디로 이동할 수 있는지까지 통제하기 어렵다. - 따라서 권한 부여는 단순히 “어떤 도구를 호출할 수 있는가”를 넘어 데이터의 후속 사용과 노출 가능성까지 고려해야 한다. ## 무권한 시작과 Gatekeeper 기반 접근 - Cloudflare Access가 Cloudflare OS에 들어올 수 있는 사용자를 통제한다. - OS 내부에서는 모든 에이전트와 앱이 처음에 아무 권한도 갖지 않는다. - 에이전트가 특정 리소스에 대한 접근을 요청하면 관리자가 승인하거나 거부한다. - 승인된 리소스는 생성 코드에 타입이 지정된 바인딩으로 전달된다. ```ts const issues = await env.PROJECT.listIssues({ teamId: "ENG", state: "open", }); ``` - `env.PROJECT`는 특정 리소스와 정책에 대한 권한을 나타내는 capability다. - 실제 인증 정보는 에이전트와 생성된 코드에서 완전히 격리된다. - 이러한 Gatekeeper를 통해 에이전트와 앱이 시스템 오브 레코드에 접근할 때 조직의 정책에 따른 통제가 가능해진다. ## 실용적인 결론 Cloudflare OS의 핵심은 단순히 AI 챗봇을 제공하는 것이 아니라, 조직의 지식과 시스템 접근 권한을 안전하게 결합해 업무 자체를 자동화하는 데 있다. 조직에 도입하려면 먼저 반복 업무를 컨텍스트·스킬·결정적 워크플로로 정리하고, API 키 직접 공유 대신 리소스별 최소 권한과 감사 가능한 접근 정책을 설계하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

data-governanceAI 에이전트모델 컨텍스트 프로토콜cloudflare+3

figma·2026년 7월 31일·3분 읽기큐레이션 요약

AI 숙련도는 최종 목표가 아니다 | Figma 블로그

AI 도구를 잘 다루는 능력은 중요하지만, 그것만으로는 AI 시대의 성공을 보장할 수 없다. 더 중요한 역량은 개인의 생산성 향상을 팀 전체의 속도로 확장하고, 다양한 의견을 모아 결정을 내리며, 실험과 실패를 안전하게 공유하는 협업 능력이다. 결국 AI의 가치는 한 사람이 10배 빠르게 일하는 데보다 팀 전체가 함께 더 빠르고 현명하게 움직이는 데 있다. ## AI 활용 능력 이상의 역량 - 제품 개발자 90% 이상이 AI 활용 능력을 미래의 성공에 필수적이라고 답했다. - AI 도구 숙련도는 채용, 업무 속도, 자신감 향상에 직접적인 도움을 준다. - 그러나 AI가 업무 방식을 바꿀수록 다음과 같은 역량의 중요성이 더 커진다. - 팀이 함께 사용할 수 있는 시스템 구축 - 적절한 사람들과 아이디어를 주고받는 능력 - 공동의 목표를 향해 협력하는 능력 ## 내부 제품 빌더가 되기 - AI 도구를 개인용으로만 사용하지 말고, 팀 전체가 활용할 수 있는 내부 도구로 전환해야 한다. - 예시는 다음과 같다. - 프로토타이핑 에이전트 - 브랜드 플러그인 - 공유 프롬프트 라이브러리 - 누구나 사용할 수 있는 프로토타이핑 도구 - Figma 연구팀은 AI를 활용해 설문 데이터를 탐색할 수 있는 인터랙티브 웹사이트를 만들었다. - 데이터와 맥락이 개인의 컴퓨터나 머릿속에만 머무르지 않게 했다. - AI를 개인 생산성 도구가 아니라 팀의 협업 역량을 확장하는 수단으로 활용했다. - Figma Brand Studio는 Figma Make로 이미지 효과 생성기를 제작했다. - 팀원이 사진이나 디자인에 브랜드에 맞는 질감을 클릭 한 번으로 적용할 수 있었다. - 핵심은 팀의 업무에서 반복되거나 막히는 지점을 발견하고, AI로 마찰을 줄이는 것이다. - 한 사람이 10배 빠르게 일하는 것보다 팀 전체가 함께 10배 빠르게 움직이는 편이 더 큰 효과를 낸다. ## 수많은 선택지에서 결정으로 이끌기 - AI는 짧은 시간에 수십 개의 방향과 결과물을 만들어내므로, 생성 자체보다 선택과 의사결정이 어려워진다. - 효과적인 의사결정을 위해서는 프로젝트 책임자뿐 아니라 다음 사람들을 참여시켜야 한다. - 반대 의견이나 새로운 관점을 가진 사람 - 과거의 맥락과 조직의 경험을 아는 사람 - 잠재적 위험을 발견할 수 있는 전문가 - 한 팀이 AI로 내부 앱을 빠르게 만들었지만, 직원들이 접근해서는 안 되는 회사 프로젝트 정보가 노출되는 문제가 발생했다. - 데이터 거버넌스 전문가를 초기 단계부터 참여시켰다면 예방할 수 있었던 사례다. - 회의 전에 이해하기 쉬운 선택지를 제공해야 한다. - 프로토타입의 각 흐름을 설명하는 Loom 영상 - 방향별 동작을 보여주는 주석이 달린 FigJam 파일 - 회의에서는 단순한 설명보다 트레이드오프를 비교하고 결정을 내리는 데 집중해야 한다. - 발언하지 않은 사람의 의견을 요청한다. - 모호한 추천은 구체적으로 되묻는다. - 논의를 진전시키는 질문을 한다. - 회의가 끝나기 전에 결정사항과 다음 단계를 확인한다. ## 나쁜 아이디어도 공유하기 - AI 활용 속도는 개인과 조직 사이에서 서로 다르게 나타난다. - 20%는 개인 기여자가 조직의 지원 없이 앞서가고 있다고 답했다. - 27%는 리더십이 AI 도입을 밀어붙이지만 팀이 따라가기 어려워한다고 답했다. - 팀원마다 AI를 접한 시점과 숙련도가 달라, 방치하면 역량 격차가 계속 커질 수 있다. - 앞선 사람만 계속 실험하면 다른 구성원은 AI 활용법을 배우기보다 뒤처지는 상황에 놓인다. - 따라서 아직 다듬어지지 않은 아이디어나 실패한 시도도 공유할 수 있는 환경이 필요하다. - 실험 결과를 공개적으로 나누면 개인의 경험이 팀의 학습 자산이 되고, AI 도입 속도 차이를 줄일 수 있다. AI 도구를 배우는 데 그치지 말고, 팀이 함께 사용할 수 있는 도구와 프로세스를 만들고, 다양한 이해관계자를 참여시켜 의사결정을 구조화하는 것이 좋다. 또한 완성된 결과만 공유하기보다 실패와 미숙한 아이디어까지 안전하게 나누는 문화를 구축해야 AI의 효과를 조직 전체로 확장할 수 있다.

원문 읽기(새 탭에서 열림)

data-governanceAI대규모 언어 모델프로토타이핑+2

figma·2026년 7월 1일·4분 읽기큐레이션 요약

검증할 수 있는 신뢰: Figma, 이제 ISO 42001 인증 획득 | Figma 블로그

Figma는 AI 거버넌스 관리 체계(AIMS)에 대해 국제 표준 ISO/IEC 42001:2023 인증을 획득했다고 발표했습니다. 이번 인증은 자체 설명이 아니라 ANAB 공인 인증기관인 Schellman의 독립적인 심사를 통해 정책, 위험 관리, 데이터 관행, 기술적 보호조치가 실제로 운영되고 있음을 검증받았다는 의미입니다. Figma는 이를 통해 규제 산업 고객이 AI 관련 공급업체 위험 평가와 규제 보고에 활용할 수 있는 객관적 근거를 제공한다고 강조합니다. ## ISO/IEC 42001과 AI 관리 시스템 - ISO/IEC 42001은 2023년 12월 제정된 AI 관리 시스템 국제 표준입니다. - 정보보호 관리체계 표준인 ISO 27001과 유사하게, 조직이 AI를 책임 있게 개발·배포·운영하기 위해 필요한 정책과 절차, 통제 항목을 정의합니다. - AI 관리 시스템(AIMS)은 다음 활동을 관리하는 운영 기반입니다. - AI 기능의 설계와 개발 - 제품 내 AI 배포 - 데이터 및 위험 관리 - 성능과 영향 모니터링 - 인간의 감독과 책임 체계 유지 ## 자체 문서보다 독립적 검증이 중요한 이유 - AI 공급업체는 백서, 보안 설문, 정책 문서 등을 통해 거버넌스 수준을 설명할 수 있지만, 문서만으로는 실제 통제가 작동하는지 판단하기 어렵습니다. - ISO 42001 인증은 공인된 제3자가 국제 표준에 따라 관리 체계를 직접 심사했다는 점에서 자체 평가와 구별됩니다. - Figma는 Schellman이 다음 항목을 검토했다고 설명합니다. - AI 거버넌스 정책 - 데이터 처리 관행 - AI 위험 관리 절차 - 기술적 보호조치 - 실제 운영 효과 - 따라서 고객은 Figma의 설문 답변만 검토하는 대신, 벤더 위험 평가·이사회 보고·규제 제출에 활용할 수 있는 외부 검증 결과를 참고할 수 있습니다. ## 인증 적용 범위 - 인증 대상은 Figma 플랫폼 전반의 AI 기능을 관리하는 AIMS입니다. - 적용 제품은 다음과 같습니다. - Figma Design - Figma Make - FigJam - Dev Mode - Figma Sites - Figma Slides - Figma Draw - Figma Buzz - Figma Weave ## 실제 심사 방식과 9개 통제 목표 - 심사는 두 단계로 진행되었습니다. - **1단계:** AIMS의 설계, 문서, 정책, 위험 평가 방법론 검토 - **2단계:** 직원 인터뷰, 업무 프로세스 관찰, 실제 운영 효과 평가 - 총 38개 통제를 다음 9개 Annex A 통제 목표에 따라 평가했습니다. - AI 영향 평가 - 거버넌스와 책임 - AI 특화 위험 관리 - AI 시스템 생명주기 관리 - 데이터 거버넌스 - 제3자 AI 위험 관리 - 모니터링과 성능 평가 - 인간의 감독 - AI 시스템의 책임 있는 사용 - Figma는 이번 인증이 관련 개념을 문서화했다는 사실보다, 실제 프로세스에 적용하고 운영하고 있음을 검증한 데 의미가 있다고 설명합니다. - 인증기관 자체도 ANAB의 공인을 받았기 때문에, 비공인 기관의 인증보다 신뢰성과 객관성이 높다고 강조합니다. ## 규제 산업 고객에게 의미하는 점 - Figma의 AI 기능은 금융, 의료, 보험, 공공 부문 등 보안·개인정보·규제 요구가 높은 환경에서 사용될 수 있습니다. - 이런 조직은 AI 공급업체를 평가할 때 다음을 입증해야 할 수 있습니다. - AI 위험을 식별하고 관리하는지 - 데이터가 적절히 통제되는지 - AI 시스템에 인간의 감독이 존재하는지 - 공급업체의 통제가 실제로 운영되는지 - EU AI 법(EU AI Act)과 새로운 AI 조달 기준은 단순한 선언보다 증빙을 요구하는 방향으로 발전하고 있습니다. - ISO 42001 인증은 기업의 벤더 위험 관리, 감사 대응, 이사회 보고, 규제 제출에 활용 가능한 공식 근거가 될 수 있습니다. ## 향후 지속적인 검증 - Figma는 AI 기능이 확대될수록 거버넌스 체계도 계속 제3자 검증에 맡기겠다고 밝혔습니다. - ISO 42001 인증서는 기존 ISO 27001 및 SOC 2 Type II 인증과 함께 제공됩니다. - 인증서와 보안·컴플라이언스 문서는 `compliance.figma.com`에서 확인할 수 있으며, Schellman 인증서 디렉터리를 통해 인증을 검증할 수 있습니다. - Figma는 AI 거버넌스가 변경되어 고객의 위험 평가에 영향을 줄 경우 이를 투명하게 알리고, 관련 정보를 지속적으로 최신 상태로 유지하겠다고 약속합니다. 실무적으로는 AI 서비스를 도입하거나 갱신할 때 공급업체의 자체 설명만 확인하기보다, ISO 42001처럼 공인기관이 검증한 인증 범위·유효기간·적용 제품을 함께 확인하는 것이 바람직합니다.

원문 읽기(새 탭에서 열림)

data-governanceAIai-governancesecurity-compliance+3

meta·2026년 6월 25일·5분 읽기큐레이션 요약

AI 네이티브 시대의 프라이버시 인식 인프라: 자산 분류 사례 연구

프라이버시 통제는 데이터의 정체와 사용 맥락을 정확히 이해해야 제대로 작동하며, 이를 위한 자산 분류가 모든 보존·접근·목적 제한·공유·익명화 정책의 기반이 된다. Meta는 LLM을 모든 운영 판단에 사용하는 대신, 풍부한 맥락과 인간 검토를 바탕으로 모호하거나 새로운 자산을 해석하게 하고, 검증된 패턴은 버전 관리되는 결정론적 규칙으로 전환하는 하이브리드 방식을 제안한다. 그 결과 일상적인 운영 집행은 빠르고 재현 가능하며 감사하기 쉬운 규칙이 담당하고, LLM은 점차 예외적인 경우에만 사용된다. ## 프라이버시 인프라에서 자산 분류가 중요한 이유 - 프라이버시 인식 인프라(PAI)는 다음 네 가지 운영 문제를 다룬다. - 어떤 데이터가 존재하고 어떻게 관리되는지 파악 - 특정 정책과 관련된 데이터 흐름 탐색 - 보존 기간, 접근 권한, 허용 목적, downstream 공유 제한 집행 - 검증 가능한 증거를 통한 컴플라이언스 입증 - 자산 분류는 이 중 ‘데이터 이해’ 계층에 해당하며, 이후 모든 통제의 기반이 된다. - 분류 대상은 테이블과 컬럼에 한정되지 않는다. - 중첩 페이로드의 필드 - 로그 키와 이벤트 파라미터 - API 필드 - ML 피처와 임베딩 - 중간 파이프라인에서 생성된 파생 데이터셋 - 같은 데이터가 파이프라인을 거치며 피처, 모델 학습 데이터, 결합된 파생 신호 등 여러 표현으로 바뀌므로, 분류는 데이터의 형태보다 의미와 계보(lineage)를 따라야 한다. ## 데이터 분류가 어려운 네 가지 이유 - **노이즈가 많고 신호가 약하다** - 자산마다 수십 개의 맥락 필드를 제공하면 모델이 매번 중요한 정보를 다시 찾아야 한다. - 불필요한 필드가 토큰과 주의를 소모해 실제 결정 경계를 흐린다. - 예를 들어 `age`는 개인정보 맥락에서는 사람의 나이지만, 인프라 파이프라인에서는 캐시 TTL일 수 있다. - 코드 해석과 lineage 분석이 없으면 캐시 파이프라인 전체에 불필요한 제한이 적용되는 false positive가 발생한다. - **관련 정보가 여러 시스템에 흩어져 있다** - 코드, 데이터 계보, 소유자, 의미론적 주석, 문서, 실제 사용 패턴을 함께 확인해야 한다. - **요구사항과 정책 해석이 계속 변한다** - 제품 기능이 빠르게 바뀌면 정적 규칙이나 주기적 수동 검토만으로는 정책 공백이 생긴다. - **분류 오류가 downstream 전체에 전파된다** - false positive는 불필요한 제한을 유발한다. - false negative는 보호되지 않은 데이터가 남는 문제를 만든다. - 따라서 모호성을 다루는 추론 능력과 설명·재현 가능한 집행 방식이 모두 필요하다. ## LLM과 결정론적 규칙의 역할 분담 - LLM은 다음 상황에 제한적으로 사용한다. - 기존 규칙으로 처리하기 어려운 모호한 자산 - 초기 데이터가 부족한 cold start 상황 - 이전에 보지 못한 새로운 패턴 - 검증된 패턴은 버전이 있는 결정론적 규칙으로 변환한다. - 낮은 지연 시간 - 동일 입력에 대한 재현성 - 실행 결과의 감사 가능성 - 대규모 운영에 적합한 비용과 성능 - 일반적인 운영 판단은 LLM이 아니라 규칙이 담당한다. - 인간은 다음 단계에 관여한다. - 기준 라벨(reference label) 판정 - 보호 정책에 영향을 주는 규칙 승격 검토 및 승인 - 장기적으로는 LLM이 담당하는 운영 범위를 줄이고, 규칙이 처리하는 안정적인 영역을 넓히는 것이 목표다. ## 원칙 1: 프롬프트보다 맥락이 중요하다 - 분류 실패의 주요 원인은 지시문이 약해서가 아니라 모델에 제공된 증거가 부족하거나 정리되지 않았기 때문이다. - 원시 필드를 그대로 전달하면 중요한 정보와 오해를 일으키는 정보가 섞인다. - 대신 다음 요소를 포함한 **evidence brief**를 구성한다. - 판단을 지지하는 신호 - 판단과 모순되는 신호 - 각 정보의 출처(provenance) - 모델이 이미 알고 있는 정보와 중복되는 순환 필드의 마스킹 - 프롬프트를 계속 최적화하는 것보다, 코드·계보·소유권·문서 등 관련 증거를 선별하고 구조화하는 편이 정확도 향상에 더 효과적이다. - 즉, 모델에 무엇을 어떻게 묻는지보다 먼저 무엇을 보여줄지를 설계해야 한다. ## 원칙 2: 평가와 최적화를 분리한다 - LLM의 결과는 추천이며, 그 자체가 정답 데이터가 되어서는 안 된다. - 평가 체계는 분류기와 독립적으로 유지해야 한다. - 서로 다른 모델과 프롬프트 전략 - 고정된 reference set - 사람이 검토한 라벨 - 회귀(regression) 통과 기준 - 분류 결과를 다시 평가 기준으로 사용하면 실제 개선이 아니라 모델의 드리프트를 측정할 위험이 있다. - 인간 검토 라벨은 모델 출력과 분리된 신뢰 가능한 기준점으로 사용해야 한다. ## 원칙 3: 안정적인 동작을 규칙으로 증류한다 - 반복적으로 검증된 분류 패턴은 사람이 검토한 뒤 결정론적 규칙으로 만든다. - 규칙에는 버전, 적용 조건, 판단 근거를 남겨야 한다. - 규칙 기반 집행은 LLM 추론보다 빠르고, 결과를 재생(replay)할 수 있으며, 감사와 디버깅이 쉽다. - LLM은 새로운 패턴을 발견하는 학습 장치로 활용하고, 안정화된 지식은 규칙에 축적한다. ## 플랫폼 서비스로서의 분류 계약 분류기는 개별 모델 호출이 아니라 안정적인 플랫폼 서비스처럼 설계해야 한다. - 입력 - 자산 식별자 - 정리된 맥락 정보 묶음 - 출력 - 분류기 taxonomy상의 카테고리 - 모델의 원시 confidence score - 판단에 영향을 준 증거를 보여주는 decision trace - 결정론적 규칙으로 판단했다면 매칭된 규칙 - 사용된 맥락, 규칙, 프롬프트의 버전 정보 - confidence는 모델의 자기평가일 뿐이므로, 사람이 검토한 라벨과 비교해 실제 보정 상태를 평가해야 한다. - 모든 분류기를 하나의 보편적 taxonomy로 통합하지 않고, 각 분류기가 하나의 범위가 좁은 질문을 담당하도록 한다. - 예: 사용자 데이터인지 운영 데이터인지 분류 - 예: 특정 AI 학습 용도에 적합한 자산인지 분류 - 좁은 범위의 분류기는 평가·디버깅·거버넌스가 쉽고, 여러 분류기의 결과를 downstream에서 조합할 수 있다. 실무적으로는 LLM을 최종 집행 엔진으로 삼기보다, 사람이 검토한 라벨과 충분한 맥락을 이용해 새로운 패턴을 발견하는 보조 계층으로 두는 것이 바람직하다. 이후 안정화된 판단은 버전 관리되는 규칙으로 승격해 운영하고, 모든 결과에 증거·버전·추적 정보를 남겨 재현성과 감사 가능성을 확보해야 한다.

원문 읽기(새 탭에서 열림)

data-governance대규모 언어 모델human-in-the-loopdata-lineage+3

spotify·2026년 6월 3일·4분 읽기큐레이션 요약

도메인 전문가를 코드화하기: Spotify 데이터 어시스턴트를 뒷받침하는 컨텍스트 레이어 | Spotify Engineering

Spotify의 데이터 어시스턴트가 신뢰할 만한 답변을 제공하는 핵심은 거대한 스키마를 LLM에 모두 넣는 것이 아니라, 도메인 전문가가 선별한 맥락 계층을 구축하는 데 있다. 이 맥락은 관련 데이터셋, 검증된 질문-SQL 예시, 업무 문서로 구성되며 각 도메인 팀이 소유하고 관리한다. 결국 AI는 전문가를 대체하기보다 전문가의 지식을 여러 사용자에게 확장하는 역할을 한다. ## 대규모 데이터 환경에서 스키마만으로 부족한 이유 - Spotify에는 7만 개 이상의 데이터셋과 페타바이트 규모의 데이터가 있다. - 모든 스키마를 LLM의 컨텍스트에 넣는 방식은 다음과 같은 한계가 있다. - 컨텍스트 윈도우가 전체 데이터 웨어하우스를 담기에 부족하다. - 컬럼 타입만으로는 실제 업무 의미를 알 수 없다. - 예를 들어 `INT64` 컬럼만 보고는 테스트 데이터와 실제 데이터의 구분, 또는 “활성 사용자”의 정의를 알 수 없다. - 테이블 수가 많을수록 모델은 비슷한 테이블 중 잘못된 대상을 선택하면서도 자신 있게 답할 수 있다. - 따라서 스키마와 LLM 사이에 도메인별 의미와 사용법을 담은 별도의 맥락 계층이 필요하다. ## Spotify 데이터 에이전트의 동작 방식 - 사용자가 자연어로 질문하면 에이전트가 다음 과정을 수행한다. - 적절한 데이터 맥락을 선택한다. - SQL을 생성한다. - 데이터 웨어하우스에서 쿼리를 실행한다. - 답변, 생성된 SQL, 사용한 출처를 함께 반환한다. - ReAct 루프를 사용해 도구 호출 결과에 따라 추론과 행동을 반복하고, 필요하면 쿼리를 수정한다. - 사용자는 결과뿐 아니라 답변이 어떻게 만들어졌는지도 확인할 수 있다. - Slack 봇, IDE와 AI 도구에서 사용할 수 있는 MCP 서버, 전용 웹 UI로 제공된다. - 관련 지식 기반이 없을 경우에도 이를 명시해 답변의 한계를 투명하게 드러낸다. - 2025년 8월 기준 2,100명 이상의 사용자가 13,000건 이상의 대화에서 활용했으며, 광고·팟캐스트·음악·오디오북·재무 등 177개 클러스터를 지원한다. ## 도메인별 클러스터 모델 Spotify는 데이터 도메인을 “클러스터”라고 부른다. 클러스터는 특정 조직, 프로젝트, 이니셔티브 또는 관심 주제를 중심으로 구성되며, 각 클러스터는 이름이 지정된 전문가 팀이 소유한다. - **데이터셋** - 관련 웨어하우스 테이블과 전체 스키마를 포함한다. - 컬럼 카디널리티, 자주 등장하는 값의 샘플, 파티션 구조 등을 프로파일링한다. - 예를 들어 `country` 컬럼에 `US`, `GB`, `SE` 등이 존재한다는 정보는 모델이 적절한 `WHERE` 조건을 작성하는 데 도움을 준다. - **질문-SQL 쌍** - 전문가가 작성하거나 검토한 질문과 SQL의 조합이다. - 단순한 예시가 아니라 해당 도메인에서 권장되는 쿼리 패턴과 데이터 의미를 가르치는 few-shot 자료로 사용된다. - **문서** - 업무 용어, 팀별로 달라지는 정의, 데이터 사용 시 주의점 등을 기록한다. - 어떤 컬럼을 사용해야 하고 어떤 컬럼을 피해야 하는지도 설명할 수 있다. - 클러스터의 범위, 포함할 테이블, 중요한 예시는 데이터 과학자와 애널리틱스 엔지니어 등 도메인 전문가가 결정한다. ## 자동 생성보다 전문가 검토가 중요한 이유 - Spotify는 데이터 웨어하우스의 과거 쿼리 기록에서 질문-SQL 쌍을 자동으로 생성하는 방법을 검토했다. - 실제 쿼리이므로 유용할 것처럼 보였지만, 큐레이터가 승인한 예시는 전체의 12.5%에 불과했다. - 나머지 87.5%에는 다음과 같은 쿼리가 포함되어 있었다. - 일회성 탐색이나 디버깅 쿼리 - 다시 사용하지 않을 임시 분석 - 잘못된 테이블을 사용한 쿼리 - 기술적으로는 맞지만 다른 사용자에게 잘못된 패턴을 가르치는 쿼리 - 쿼리 기록에는 정보가 많지만, 어떤 쿼리가 표준적인 지식인지는 자동으로 표시되지 않는다. - 따라서 AI가 데이터의 진실을 결정하도록 하지 않고, 전문가가 예시를 검토하고 정식 사례로 승인한다. - 목적은 전문가를 대체하는 것이 아니라 전문가의 판단을 재사용 가능한 형태로 확장하는 것이다. ## 클러스터의 지속적인 건강 관리 데이터 스키마와 업무 규칙은 계속 변하기 때문에, 한 번 만든 맥락이 영원히 정확한 것은 아니다. - 테이블이 교체되거나 폐기될 수 있다. - 컬럼명이 변경될 수 있다. - 비즈니스 정의와 분석 방식이 달라질 수 있다. - 기존 질문-SQL 쌍이 변경된 스키마와 호환되지 않을 수 있다. - Spotify는 여러 신호를 종합해 클러스터 건강 점수를 계산한다. - 기반 데이터의 상태 - 최근 스키마 변경 이후에도 curated pair가 유효한지 여부 - 실제 사용자가 묻는 질문을 충분히 다루는지 - 생성된 SQL을 재현할 수 있는지 - 기타 품질 및 활용 지표 - 문제가 발생하면 건강 점수가 낮아지고, 전문가에게 필요한 정비 작업이 제안된다. - 클러스터 소유자는 대시보드의 점수와 세부 신호를 보고 우선적으로 관리할 영역을 결정한다. ## 사용자 대화로 이어지는 피드백 루프 - 모든 대화와 쿼리는 기록되어 클러스터 소유자에게 전달된다. - 소유자는 질문, 답변, 생성된 SQL, 사용자 피드백을 확인할 수 있다. - 전문가가 질문-SQL 쌍을 승인하거나 문서를 보완할 때마다 이후 사용자에게 제공되는 맥락이 개선된다. - 즉, 실제 사용 과정이 새로운 품질 관리와 지식 축적의 자료가 된다. - 어시스턴트의 신뢰도는 모델 자체보다 그 모델이 참조하는 맥락의 품질과 최신성에 달려 있다. ## 실용적인 시사점 데이터 AI를 구축할 때는 모든 스키마를 한꺼번에 제공하기보다, 도메인별로 범위를 나누고 전문가가 검증한 예시와 업무 규칙을 함께 관리하는 것이 효과적이다. 또한 자동 생성된 지식은 그대로 신뢰하지 말고 사람의 검토를 거치며, 스키마 변경·사용 패턴·쿼리 재현성을 기반으로 지속적인 품질 관리를 해야 한다.

원문 읽기(새 탭에서 열림)

data-governanceAI대규모 언어 모델모델 컨텍스트 프로토콜+4

cloudflare·2026년 5월 28일·4분 읽기큐레이션 요약

Cloudflare의 데이터 플랫폼과 그 위에 구축한 AI 에이전트 이야기

Cloudflare는 여러 데이터베이스와 스트림에 흩어진 데이터를 하나의 SQL 인터페이스로 통합하기 위해 데이터 레이크하우스 플랫폼 **Town Lake**를 구축했다. Town Lake는 신선하고 정확한 원천 데이터와 빠른 분석용 샘플 데이터를 함께 제공하며, 권한 관리·PII 탐지·감사 기능을 기본으로 포함한다. 그 위에 자연어로 질문하면 감사 가능한 답을 제공하는 AI 데이터 에이전트 **Skipper**를 구축해 데이터 접근성을 높이려 했다. ## 데이터 파편화와 접근성 문제 - Cloudflare는 초당 10억 건이 넘는 이벤트를 처리하고 330개 이상의 도시, 120개 이상의 국가에서 네트워크를 운영한다. - 데이터가 다음과 같은 다양한 시스템에 분산되어 있었다. - Postgres: 계정 및 업무 메타데이터 - ClickHouse: 분석 이벤트 - BigQuery: 집계 데이터 - R2: 원시 로그 - Kafka: 실시간 이벤트 스트림 - 시스템마다 인증 방식, 쿼리 언어, 보존 기간이 달라 간단한 질문에도 여러 시스템을 알고 있어야 했다. - 올바른 테이블과 조인 방법이 조직 내 암묵지에 의존했다. - 예를 들어 ClickHouse의 사용량 테이블과 Postgres의 고객 차원 테이블을 연결하려면 별도의 고객 ID 변환 규칙을 알아야 했다. - 기존 분석 파이프라인은 초당 7억 건 이상의 이벤트를 처리하기 위해 데이터를 샘플링했다. - 대시보드에는 적합하지만 청구 금액 계산이나 보안 조사처럼 정확한 전체 데이터가 필요한 작업에는 부적합했다. - 일부 내부 리포팅 시스템은 외부 업체와 다른 클라우드에 의존하고 있어 비용과 운영상 종속성도 발생했다. ## 구축 목표 - 적절한 권한과 업무상 필요가 있는 모든 직원이 Cloudflare 데이터를 한곳에서 조회할 수 있도록 했다. - 사용 목적에 따라 서로 다른 데이터 품질을 제공하려 했다. - 청구·보안 조사: 신선하고 정확한 비샘플링 데이터 - 대시보드·탐색: 빠른 응답을 위한 다운샘플링 데이터 - PII를 자동으로 식별하고 민감한 테이블은 기본적으로 제한했다. - 모든 데이터 접근을 감사할 수 있도록 하고, 권한을 일정 기간 동안만 부여하도록 설계했다. - R2, Workers, Cloudflare Access, Workflows 등 Cloudflare 자체 제품 위에 플랫폼을 구축했다. - 최종적으로 SQL을 몰라도 자연어로 데이터를 조회할 수 있는 인터페이스를 제공하는 것이 목표였으며, 이것이 Skipper로 이어졌다. ## Town Lake의 데이터 레이크하우스 구조 Town Lake는 오브젝트 스토리지에 저장된 데이터를 쿼리 엔진으로 조회하고, 메타데이터 계층을 통해 데이터베이스처럼 사용하는 레이크하우스 구조다. - **Apache Trino** - 통합 쿼리 엔진으로 사용된다. - 하나의 SQL 쿼리에서 Postgres, ClickHouse, R2의 Iceberg 테이블을 함께 조인할 수 있다. - 필터를 ClickHouse로 푸시하고, Postgres의 계정 차원 데이터와 R2의 청구 집계 데이터를 결합하는 식으로 쿼리를 최적화한다. - **R2 Data Catalog와 Apache Iceberg** - 차갑거나 따뜻한 데이터를 R2에 저장한다. - Iceberg의 스키마 변경, 시점 조회(time travel), 파티션 변경, 데이터 컴팩션 기능을 활용한다. - 오래된 데이터는 분 단위에서 시간 단위, 다시 일 단위로 집계해 저장 비용을 줄인다. - Parquet 파일을 R2에 저장하면 동일한 데이터를 OLAP 데이터베이스에 보관하는 것보다 비용이 낮다. - **DataHub** - 테이블, 컬럼, 소유 팀, 데이터 계보(lineage), 용어집 정보를 관리한다. - 사용자가 특정 테이블의 의미를 물으면 컬럼 설명, 담당 팀, 상위 입력 테이블, 하위 소비 테이블까지 제공한다. ## 권한 관리와 데이터 거버넌스 - **Lifeguard**가 데이터 접근 제어를 담당한다. - 접근 규칙은 D1에 저장하고, 내부 접근 관리 시스템에서 사용자·그룹 정보를 동적으로 가져온다. - 이 정보를 결합해 JSON 정책을 생성하고 Trino가 HTTP를 통해 읽도록 한다. - Skipper와 Gateway에도 기본적인 권한 정보를 전달해 쿼리가 실행된 뒤가 아니라 진입 단계에서 접근을 차단할 수 있다. - 권한을 업무 목적과 기간에 맞춰 부여함으로써 민감 데이터에 대한 불필요한 상시 접근을 줄인다. - 데이터 접근 기록을 남겨 누가 어떤 데이터에 접근했는지 감사할 수 있도록 했다. ## PII 자동 탐지 - **Skimmer**는 테이블의 모든 컬럼을 지속적으로 검사하는 PII 탐지 스캐너다. - 각 컬럼에서 행을 샘플링하고 Workers AI를 이용해 PII 포함 여부를 분류한다. - 이를 통해 데이터 카탈로그에 민감도 정보를 자동으로 반영하고, 민감한 테이블이나 컬럼의 기본 접근 정책을 강화할 수 있다. ## 자연어 데이터 에이전트 Skipper - Skipper는 Town Lake 위에서 동작하는 AI 데이터 에이전트다. - 사용자가 영어로 질문하면 관련 데이터와 메타데이터를 찾아 SQL 기반 답변을 생성한다. - 데이터 위치, 테이블 구조, 조인 관계, 권한을 사용자가 직접 알 필요를 줄이는 것이 목적이다. - 자연어 질의의 예시는 다음과 같다. - 최근 분기의 매출 기준 상위 100개 고객 조회 - 특정 ASN에서 발생한 고위험 Bot Management 이벤트 검색 - 일정 금액 이상 지출한 고객의 청구 지원 티켓 분석 - 답변은 단순한 생성형 응답이 아니라 데이터에 근거하고 감사 가능한 형태여야 한다는 점이 중요하다. ## 실용적인 시사점 데이터 플랫폼을 구축할 때는 저장소 통합만으로는 충분하지 않다. 통합 쿼리 엔진, 메타데이터 카탈로그, 데이터 계보, 세분화된 권한 관리, PII 탐지, 감사 기능을 함께 설계해야 데이터가 실제 조직 전체에서 활용된다. 또한 정확성이 필요한 업무와 속도가 중요한 분석 업무에 동일한 데이터 처리 방식을 적용하지 않고, 목적에 따라 원천 데이터와 샘플 데이터를 구분하는 전략이 효과적이다.

원문 읽기(새 탭에서 열림)

data-governanceAI 에이전트sqlapache-iceberg+4

toss·2026년 5월 14일원문

AI 시대, 성과 내는 조직일수록 토스식 TPM이 필요한 이유 (새 탭에서 열림)

토스가 정의하는 TPM(Technical Program Manager)은 일정과 리스크를 관리하는 전통적 조율자를 넘어, 여러 팀 사이에 방치된 구조적 문제를 발견하고 해결하는 **전략 실행자**다. 특히 AI 도입으로 기술·조직·운영의 의존성이 복잡해질수록, 공식 Owner가 없는 회색지대를 구조화하고 실행 가능한 상태로 만드는 역할이 중요해진다. TPM의 성과는 문서나 상태 보고가 아니라 병목 제거와 현실의 변화로 증명된다. ## 기존 TPM 정의의 한계 - 일반적인 TPM은 이미 정의된 기술 프로그램의 일정, 리스크, 의존성, 커뮤니케이션을 관리해 안정적인 전달을 돕는다. - 그러나 조직이 커질수록 어려운 문제는 정식 프로그램이나 명확한 과제의 형태로 등장하지 않는다. - 대표적인 문제는 다음과 같다. - 여러 팀이 관련되어 있지만 최종 책임자가 없는 문제 - 전략은 존재하지만 실행 구조가 없는 문제 - 상태 공유는 계속되지만 실제 상황은 바뀌지 않는 문제 - 제품·기술 전략·조직 설계·운영 방식이 복합적으로 얽힌 문제 - 이런 상황에서는 일정 관리나 이해관계자 조율만으로 문제를 해결하기 어렵다. ## PO·EM·전통적 TPM과의 차이 - **PO(Product Owner)**는 사용자와 비즈니스 관점에서 무엇을 만들고 어떤 우선순위를 둘지 정의한다. - **EM/SDM**은 사람, 기술 품질, 팀 운영과 조직 건강을 관리해 특정 팀이 꾸준히 실행할 기반을 만든다. - **전통적 TPM 또는 Technical Project Manager**는 정해진 목표를 일정 안에 전달하도록 계획과 리스크를 관리한다. - **토스식 TPM**은 이 역할들을 대체하지 않고, 역할 사이와 조직 경계 밖에 남은 문제를 담당한다. - 제품 방향은 있지만 여러 조직을 움직일 실행 구조가 없을 때 - 각 팀은 제 역할을 하지만 전체 관점의 Owner가 없을 때 - 리더십이 중요성을 인식해도 기존 구조에서는 우선순위를 만들기 어려울 때 - 따라서 이미 정의된 업무를 관리하기보다, 정의되지 않은 중요한 문제를 해결 가능한 형태로 바꾸는 데 초점을 둔다. ## 성숙한 조직에서 커지는 회색지대 - 조직이 성숙하면 각 팀의 책임과 목표가 선명해지고 실행 속도도 빨라진다. - 반면 명확한 조직 경계 때문에 어느 팀에도 완전히 속하지 않는 문제가 방치될 수 있다. - 이러한 문제는 여러 조직에 조금씩 걸쳐 있거나, 당장은 긴급하지 않지만 미래를 위해 해결해야 하거나, 개별 팀의 로컬 최적화로는 풀리지 않는 경우가 많다. - AI 시대에는 모델 도입, 데이터 거버넌스, 품질 기준, 보안, 개발 생산성, 업무 방식이 동시에 얽히면서 이런 현상이 심화된다. - 높은 자율성과 실행력을 가진 조직일수록 팀 간 경계를 전담해 다룰 역할이 필요하다. ## 토스식 TPM이 다루는 문제 - 중요한데 공식 Owner가 없다. - 여러 팀과 직무가 동시에 연관되어 있다. - 전략·기술·운영·사람 문제가 섞여 있다. - 진행 상황은 자주 공유되지만 실질적인 전환은 일어나지 않는다. - 기존 역할 하나의 권한과 책임만으로는 끝까지 해결하기 어렵다. - TPM은 표면적인 현상만 추적하지 않고 다음을 수행한다. - 진짜 문제와 단순 증상을 구분한다. - 빠진 이해관계자와 필요한 의사결정을 드러낸다. - 권한과 책임 구조를 설계한다. - 결과가 만들어질 때까지 실행에 개입한다. ## 문제 발견부터 현실 변화까지의 역할 - **문제를 선제적으로 발견한다** - 누군가 정리한 업무를 기다리지 않고 반복되는 병목, 책임의 공백, 이름 붙지 않은 중요 문제를 찾는다. - **전략을 실행 구조로 전환한다** - 어떤 팀이 어떤 순서로 움직일지, 무엇을 포기할지, 누가 DRI(최종 책임자)가 될지 구체화한다. - **팀 사이에서 실행을 설계한다** - 서로 다른 조직의 목적·속도·제약을 연결하고 공동 문제를 풀 수 있는 협업 구조를 만든다. - **블로커를 보고하는 데서 그치지 않는다** - 필요하면 의사결정 구조, 우선순위, 참여자 구성과 협업 방식을 바꿔 실제 장애물을 제거한다. - **사람과 조직 구조를 함께 본다** - 필요한 리더십, 팀 구성, 권한 배치와 반복 가능한 운영 메커니즘을 함께 설계한다. - **현실의 변화로 성과를 판단한다** - 막힌 실행이 다시 움직이고 반복 병목이 줄어들며, 다음에는 같은 문제를 더 쉽게 해결할 수 있어야 한다. - 문서와 회의, 조율은 수단이며 TPM의 정체성은 문제 해결에 있다. ## 강한 TPM에게 필요한 역량 - **문제 구조화** - 모호한 현상에서 본질과 증상을 구분하고, 관계자와 의사결정 병목을 빠르게 파악한다. - 회의 후 내용을 정리하는 수준을 넘어 회의 전부터 문제의 프레임을 제시한다. - **전략의 실행 전환** - 필요한 작업 흐름, 개입 순서, 시점별 책임자를 설계해 방향성을 실제 행동으로 연결한다. - **영향력과 동원 능력** - 공식 권한에 의존하지 않고 신뢰와 판단력으로 여러 팀을 움직인다. - 조직마다 다른 언어를 번역하고, 불편한 대화를 열며, 합의가 느린 상황에서도 실행 기반을 만든다. - **시스템 사고** - 문제가 반복되면 개인의 노력보다 조직 구조와 운영 메커니즘을 점검한다. - 영웅적인 개인의 희생 없이도 기본적으로 잘 작동하는 시스템을 만든다. - **완결성** - 문제 발견, 구조 설계, 관계자 동원, 실행, 결과 도출, 재발 방지까지 끝까지 책임진다. - 업무량보다 어렵고 넓은 회색지대의 문제를 완결할 수 있는지가 중요하다. ## AI 시대의 TPM - AI 도입이 확대될수록 기술 변화는 빨라지고 팀 간 의존성과 책임 경계는 복잡해진다. - 조직에 필요한 것은 회의와 상태 보고를 늘리는 사람이 아니라, 비어 있는 구조를 찾아 실행이 다시 움직이도록 만드는 사람이다. - 모두가 중요하다고 하지만 아무도 끝까지 책임지지 않는 문제가 반복된다면 새로운 형태의 TPM이 필요하다는 신호다. - 정식 직책이 없더라도 이런 문제를 발견하고 구조화해 해결까지 이끄는 비공식 TPM 역할부터 시도해볼 수 있다.

data-governanceAIcross-functional-collaborationorganizational-design+3

daangn·2025년 12월 10일원문

당근 데이터 지도를 그리다: 컬럼 레벨 리니지 구축기 (새 탭에서 열림)

당근마켓(당근) 데이터 가치화팀은 데이터의 흐름을 투명하게 파악하여 신뢰성을 높이기 위해 SQL 파싱 기반의 **컬럼 레벨 데이터 리니지(Column-level Lineage)** 시스템을 구축했습니다. 기존의 테이블 단위 추적으로는 해결하기 어려웠던 연쇄 장애 대응과 민감 정보(PII) 관리 문제를 해결하기 위해, 모든 BigQuery 쿼리 로그를 분석하여 데이터 간의 세부 의존 관계를 시각화했습니다. 이를 통해 당근의 복잡한 데이터 생태계에서 변경 영향도를 정교하게 분석하고 장애 복구 시간을 단축하는 성과를 거두었습니다. ### 데이터 흐름의 불투명성으로 인한 문제점 * **연쇄 실패 대응의 어려움**: 특정 테이블의 파이프라인이 실패했을 때 이를 참조하는 하위 테이블들을 즉각 파악할 수 없어, 수동으로 쿼리를 전수 조사하며 문제를 해결해야 했습니다. * **스키마 변경의 불확실성**: 원천 데이터(MySQL 등)의 컬럼을 삭제하거나 타입을 변경할 때, 해당 컬럼을 사용하는 수많은 파생 테이블 중 어떤 곳에 장애가 발생할지 예측하기 어려웠습니다. * **민감 정보 추적 불가**: PII(개인정보)가 여러 가공 단계를 거치며 어떤 테이블의 어떤 컬럼으로 흘러가는지 파악되지 않아 보안 관리 측면에서 한계가 있었습니다. ### 컬럼 레벨 리니지 도입의 기술적 의사결정 * **테이블 레벨의 한계**: BigQuery의 기본 기능을 통한 테이블 단위 추적은 뷰(View)의 기저 테이블을 정확히 파악하기 어렵고, 세부 컬럼의 변화를 감지하지 못하는 단점이 있었습니다. * **오픈소스(OpenLineage) 대비 효율성**: 다양한 조직이 각기 다른 환경(Airflow, 노트북 등)에서 쿼리를 실행하는 당근의 특성상, 모든 환경에 계측 코드를 심는 방식보다는 중앙화된 BigQuery 로그를 분석하는 방식이 운영 부담이 적다고 판단했습니다. * **SQL 파싱 접근법**: 실행된 모든 SQL의 이력이 남는 `INFORMATION_SCHEMA.JOBS` 뷰를 활용하여, 실행 환경과 관계없이 모든 쿼리로부터 의존성을 추출하는 방식을 채택했습니다. ### 시스템 아키텍처 및 추출 프로세스 * **기술 스택**: 대량의 쿼리 병렬 처리를 위해 **Spark**를 활용하고, SQL 파싱 및 AST(Abstract Syntax Tree) 분석을 위해 **sqlglot** 라이브러리를 사용하며, **Airflow**로 주기적인 추출 프로세스를 자동화했습니다. * **데이터 수집 및 분석**: 모든 GCP 프로젝트에서 쿼리 로그를 수집한 뒤, sqlglot으로 쿼리 구조를 분석하여 `Source Column -> Target Column` 관계를 도출합니다. * **엣지 케이스 처리**: `SELECT *`와 같은 와일드카드 쿼리는 테이블 메타데이터를 결합해 실제 컬럼명으로 확장하고, 복잡한 CTE(Common Table Expressions)나 서브쿼리 내의 의존성도 AST 탐색을 통해 정확하게 추적합니다. ### 데이터 지도를 통한 실질적 변화 * **정교한 영향도 분석**: 특정 컬럼 수정 시 다운스트림에서 이를 참조하는 모든 컬럼을 즉시 확인하여 사전에 장애를 예방할 수 있게 되었습니다. * **거버넌스 강화**: 데이터의 원천부터 최종 활용 단계까지의 흐름을 시각화함으로써 데이터 가계도(Data Genealogy)를 완성하고, 데이터 보안 및 품질 관리 수준을 한 단계 높였습니다. * **운영 효율화**: 장애 발생 시 영향 범위를 데이터 지도를 통해 한눈에 파악함으로써 원인 파악과 복구에 소요되는 리소스를 획기적으로 줄였습니다. 데이터 플랫폼의 규모가 커질수록 수동 관리는 불가능해지므로, 초기부터 SQL 로그를 활용한 자동화된 리니지 체계를 구축하는 것이 중요합니다. 특히 실행 환경이 파편화된 조직일수록 애플리케이션 계측보다는 쿼리 엔진의 로그를 파싱하는 접근법이 빠른 도입과 높은 커버리지를 확보하는 데 유리합니다.

data-governanceapache-sparkbigqueryapache-airflow+4

toss·2025년 10월 30일원문

토스 피플 : 데이터를 ‘이해하는’ 구조를 설계합니다 (새 탭에서 열림)

데이터의 품질은 사후 수습이 아닌 생성 단계의 초기 설계에서 결정되며, 특히 AI 시대에는 사람뿐만 아니라 기계도 데이터의 맥락을 완벽히 이해할 수 있는 의미 기반의 구조 설계가 필수적입니다. 토스는 이를 위해 데이터의 생성부터 활용까지 전 과정을 관리하는 'End-to-End 데이터 거버넌스'를 지향하며, 개발 속도를 저해하지 않으면서도 품질을 높이는 유연한 설계 표준을 구축하고 있습니다. 결과적으로 데이터 아키텍처는 단순한 규칙 강제가 아니라 비즈니스의 빠른 변화 속에서 데이터의 정합성을 유지하고 AI와 사람이 신뢰할 수 있는 기반을 만드는 핵심적인 역할을 수행합니다. **데이터 설계의 본질과 품질 관리의 전환** * 데이터의 품질은 분석 단계에서의 정제가 아니라, 데이터가 처음 만들어지는 순간의 설계(Design)에 의해 결정됩니다. * 서비스가 빠르게 변하는 플랫폼 환경에서는 데이터 수습에 에너지를 쏟는 사후 대응보다, 데이터가 생성되는 흐름부터 구조적으로 정리하는 사전 설계가 중요합니다. * '속도'와 '품질'은 대립하는 가치가 아니며, 설계 시 미래의 변화 가능성을 고려한 유연한 기준선을 마련함으로써 두 가치 사이의 균형을 잡아야 합니다. **AI가 이해할 수 있는 의미 중심의 데이터 구조** * 현대의 데이터 아키텍처는 사람뿐만 아니라 AI가 질문하고 분석하는 시대를 대비하여 기계가 읽을 수 있는(Machine-readable) 형태로 진화해야 합니다. * 단순한 메타데이터 관리를 넘어, 데이터 간의 의미 관계를 명확히 하는 '의미 기반 표준 사전'과 '온톨로지(Ontology)'를 도입하여 AI가 맥락을 놓치지 않도록 설계합니다. * 데이터 간의 연결 고리를 명확히 설계함으로써 AI가 스스로 의미를 추론하며 발생할 수 있는 해석 오류를 줄이고 데이터의 신뢰성을 극대화합니다. **실천적인 데이터 거버넌스와 아키텍트의 역할** * 효과적인 거버넌스는 규칙을 강제하는 것이 아니라, "표준을 따르는 것이 오히려 더 편하다"고 느낄 수 있도록 자연스러운 프로세스를 설계하는 것입니다. * 비즈니스의 빠른 사이클 속에서 모든 것을 완벽하게 설계하기보다, 현재 맥락에 맞으면서도 나중에 무리 없이 정리할 수 있는 '확장성 있는 여지'를 남겨두는 전략이 필요합니다. * 데이터 아키텍트는 거창한 담론에서 시작하는 것이 아니라, 작은 구조 하나를 더 낫게 만들고 싶어 하는 데이터 엔지니어와 분석가 모두가 도달할 수 있는 전문 영역입니다. 데이터 아키텍처는 단순히 테이블 명세서를 관리하는 일이 아니라 비즈니스의 복잡도를 구조로 풀어내는 일입니다. 고품질의 데이터를 유지하면서도 개발 속도를 잃지 않으려면, 초기 설계 단계에서부터 AI와 협업할 수 있는 표준 체계를 구축하고 이를 조직 내에서 자연스럽게 수용할 수 있는 '실현 가능한 거버넌스 모델'을 고민해 보는 것이 좋습니다.

data-governancedata-architecturedata-modelingmetadata+4