DB 데이터를 팀과 공유하는 방법 5가지

핵심 요약

"데이터를 공유해주세요"라는 요청 뒤에는 사실 세 가지 다른 니즈가 섞여 있다. 조회(반복적으로 최신 데이터를 봐야 한다), 내보내기(특정 시점 데이터를 추출해서 활용한다), 동기화(다른곳에 최신 데이터를 활용해야한다). 이걸 먼저 구분해야 방법 선택이 가능하다.

• 팀원이 데이터를 직접, 반복적으로 조회해야 한다
  → BI 툴, 어드민 직접 개발, 사내 도구 빌더
• 특정 시점 데이터를 추출해서 보고서나 외부 공유에 쓴다
  → CSV 수동 내보내기, 사내 도구 빌더의 데이터 내보내기, BI 툴 데이터 다운로드 기능
• 시트가 항상 최신 데이터를 반영해야 하거나 다른 자동화의 인풋으로 쓰인다
  → Google Sheets API (동기화 패턴)
• 주기적으로 스냅샷을 Drive 폴더에 자동으로 쌓아야 한다
  → Google Sheets API (자동 내보내기 패턴)

아래에서 각 방법의 구현 비용, 실시간성, 권한 제어, 유지보수 부담을 용도별로 비교한다.

어떤 상황에서 고민이 시작되는가

IT팀, 백엔드 개발자, 데이터 담당자라면 이 상황이 익숙하다.

CS팀에서 슬랙 메시지가 온다. "이번 달 결제 실패 건 데이터 좀 볼 수 있을까요?" 운영팀에선 "지난주 신규 가입자 목록 구글 시트로 공유해주실 수 있어요?"라고 묻는다. 기술적으로 어려운 일이 아니라는 걸 잘 안다. 문제는 이런 요청이 하루에 세 번씩 올 때, 그리고 매번 직접 처리해야 할 때이다.

셀렉트 어드민을 운영하면서 수십 개 팀의 내부 도구 운영 방식을 봐왔다. 처음엔 대부분 CSV로 시작한다. 그러다 요청이 쌓이면 Sheets API를 붙이거나 어드민을 만들게 된다. 그런데 이 선택이 애매해지는 경우가 있다. 팀원이 원하는 게 조회인데 내보내기 자동화를 만들거나, 단순 내보내기가 필요한데 어드민을 새로 짜는 경우다. 용도를 먼저 구분하면 선택이 훨씬 단순해진다.

먼저 용도를 구분하자

"데이터를 공유해주세요"라는 말 뒤에는 실제로 다른 니즈가 섞여 있다.

조회(View): 비개발자 팀원이 DB 데이터를 직접, 반복적으로 확인해야 할 때. 오늘 가입자 현황을 매일 아침 확인하거나, CS팀이 특정 주문을 검색해야 하는 경우. 데이터가 항상 최신이어야 하고, 팀원이 조건을 바꿔가며 볼 수 있어야 한다.

내보내기(Export): 특정 시점의 데이터를 추출해서 외부에서 활용해야 할 때. 월간 보고서 작성, 파트너사 공유, 다른 툴에 붙여넣기 등. 스냅샷이 목적이라서 실시간성은 필요 없다.

동기화(Sync): 데이터 자체가 항상 최신 DB 값을 반영해야 할 때. 또는 그 시트가 Zapier, Slack 알림 같은 다른 자동화의 인풋으로 쓰이는 경우. 사람이 직접 보는 게 아니라 시트가 파이프라인의 한 노드가 되는 구조다.

이 세 가지는 해결 방법이 다르다. 아래에서 각 방법이 어떤 용도에 맞는지를 기준으로 비교한다.

방법 1: CSV 수동 다운로드 → 구글 드라이브 업로드

용도: 수동 내보내기

한 줄 요약: 세팅 비용은 없다. 하지만 요청이 반복되면 개발자가 데이터 담당자가 된다.

DB 클라이언트(Sequel Ace, DBeaver, DataGrip 등)에서 쿼리 결과를 CSV로 내보내고, 구글 드라이브에 업로드한 뒤 Google Sheets로 열면 된다. 가장 기본적이지만 가장 빠르다.

• 구현 비용: 없다. 쿼리 하나 작성하는 시간이 전부다.
• 실시간성: 없다. 내보낸 시점의 스냅샷이다.
• 권한 제어: 드라이브 공유 설정으로 파일 단위 제어가 가능하다.
• 유지보수 부담: 없다. 대신 사람이 매번 해야 하고 쿼리를 관리해야한다.

이 방법의 제약: 요청이 주 2-3회를 넘기 시작할 때. 그 시점부터는 자동화 구축 비용보다 반복 처리 비용이 커진다.

어울리는 상황: 데이터 공유가 간헐적인 1-2회 수준이고, 한 사람이 담당해도 부담이 없을 때.

방법 2: Google Sheets API 연동

용도: 자동 내보내기 또는 동기화 — 패턴에 따라 다르다

한 줄 요약: 코드로 시트를 제어하는 방식이라 유연하지만, 두 가지 패턴을 구분해서 써야 한다.

Google Sheets API는 스크립트로 시트를 생성하거나 데이터를 쓰는 방식이다. 어떻게 설계하느냐에 따라 용도가 완전히 달라진다.

패턴 A: 단일 시트를 주기적으로 갱신 (동기화)

하나의 시트를 고정해두고 주기적으로 데이터를 덮어쓰거나 append한다. 시트가 항상 최신 데이터를 보여주는 대시보드처럼 쓰이거나, Zapier·Slack 알림 같은 다른 자동화의 인풋이 되는 구조에 적합하다.

• 구현 비용: 서비스 계정 발급, 스크립트 작성, 스케줄러 연결까지 익숙한 개발자 기준 2-3시간. cron이나 GitHub Actions를 이미 쓰는 팀이라면 더 짧다.
• 실시간성: 스케줄 주기에 따라 다르다. cron을 분 단위로 설정하면 분 단위 갱신이 가능하다. 단, Google Sheets API v4는 프로젝트당 분당 300 요청 쿼터*가 있어서 대용량 데이터를 자주 쓰면 제약이 생긴다. (*공식 문서에서 최신 쿼터 확인 필요)
• 권한 제어: 시트 단위로 공유와 열람 제어가 가능하다.
• 유지보수 부담: 서비스 계정 키를 잘 관리, 인수인계 해야한다. 시트 구조가 바뀌거나, 쿼리 컬럼이 변경되면 에러 없이 조용히 멈출 수 있다. 별도 알림을 붙여두지 않으면 며칠 동안 아무도 모른다.

이 패턴의 제약: CS팀이 "시트 데이터가 며칠째 안 바뀌는데요"라고 말하기 전까지 아무도 문제를 모를 수도 있음.

패턴 B: 주기적으로 새 파일을 생성해서 Drive 폴더에 저장 (자동 내보내기)

매일·매주 새 시트 파일을 만들어서 Drive의 특정 폴더에 쌓는 방식이다. 스냅샷 이력이 필요하거나, 팀원이 날짜별로 파일을 찾아서 쓰는 경우에 적합하다. 성격상 CSV 수동 내보내기를 자동화한 버전이다.

• 구현 비용: 패턴 A와 비슷. 파일 생성 + Drive 폴더 지정 로직이 추가된다.
• 권한 제어: Drive 폴더 단위 공유로 관리한다. 파일이 쌓일수록 관리가 번거로워질 수 있다.
• 유지보수 부담: 패턴 A와 동일하다.

이 패턴이 어울리는 상황: 월간 정산, 주간 리포트처럼 이력 관리가 필요한 경우. 파일 자체를 외부에 전달해야 하는 경우.

방법 3: Redash, Metabase 같은 BI 툴 활용하기

용도: 조회 + 수동 내보내기

한 줄 요약: 이미 BI 툴을 쓰는 팀이라면 추가 개발 없이 가장 합리적인 선택. 없는 팀이 이 목적만으로 도입하기엔 비용이 크다.

Redash, Metabase, Superset 같은 BI 툴은 비개발자가 저장된 쿼리를 직접 실행하고 결과를 볼 수 있는 인터페이스를 제공한다. 내보내기는 기본적으로 CSV 다운로드 방식이며, Google Sheets로의 직접 push는 제품 버전이나 추가 설정에 따라 다르다.

• 구현 비용: BI 툴이 이미 세팅되어 있다면 거의 없다. 쿼리 저장 + 공유 설정이 전부다.
• 실시간성: 팀원이 쿼리를 실행하는 시점의 데이터. 직접 실행이라 원할 때 최신 데이터를 볼 수 있다.
• 권한 제어: BI 툴 자체의 접근 제어를 따른다. 대시보드·쿼리 단위 권한 관리가 가능한 경우가 많다.
• 유지보수 부담: BI 툴 자체의 유지보수가 별도로 존재한다.

이 방법의 제약: BI 툴을 아직 도입하지 않은 팀이 데이터 공유 목적만으로 Metabase를 새로 세팅하는 상황. 조회·시각화까지 필요한 게 아니라면 과잉 투자다.

어울리는 상황: 이미 Redash나 Metabase를 운영 중인 팀. 데이터 시각화나 대시보드까지 함께 필요한 팀.

방법 4: 어드민 또는 내부 도구를 직접 개발하기

용도: 조회 + 내보내기

한 줄 요약: 기능 자체는 어렵지 않지만, 기존 어드민에 추가할지 새로 만들지에 따라 비용이 크게 달라진다.

케이스 A: 기존 어드민에 기능 추가

이미 어드민이 있다면 내보내기 버튼 하나를 추가하는 건 하루 작업이다. Sheets API 호출 + 권한 체크 정도다. 단, 레거시가 쌓인 어드민이라면 "여기 건드렸다가 다른 데 터지는 거 아닌가" 싶은 불안감이 생기고, 실제로 주변 코드를 파악하는 데 시간이 더 들 수 있다.

케이스 B: 새로 만들기

LLM으로 빠르게 초안을 뽑을 수 있다. 문제는 기능 자체가 아니라 그 주변이다. 배포 환경 세팅, 팀원 계정 관리, 테스트, 이런 것들을 챙기다 보면 어느 순간 "이게 원래 목적이 뭐였지?" 싶어진다.

• 구현 비용: 기존 어드민 추가는 하루 내외. 신규 개발은 기능 이틀 + 주변 작업 1주.
• 실시간성: 구현하기에 따라 다르다. 원하는 대로 설계할 수 있다.
• 권한 제어: 원하는 대로 설계할 수 있다. 단, 그만큼 직접 구현해야 한다.
• 유지보수 부담: 직접 만든 만큼 직접 관리해야 한다.

이 방법의 제약: 신규 개발 케이스에서 주변 작업이 예상보다 길어져 제품 개발 일정을 밀어낼 때.

어울리는 상황: 내부 도구에 투자할 개발 리소스가 충분하고, 단순 데이터 공유 외에도 수정·승인·처리 같은 워크플로우까지 함께 구축할 계획이 있을 때.

방법 5: 사내 도구 빌더 - 셀렉트 어드민

용도: 조회 + 수동 내보내기

한 줄 요약: 코드 없이 YAML 선언만으로 어드민을 구성한다. 필터·권한 설정까지 포함해도 배포 파이프라인을 건드릴 필요가 없다.

셀렉트 어드민은 YAML 설정으로 어드민을 구성하는 방식이다. DB 연결을 설정하고, 어떤 테이블의 어떤 컬럼을 보여줄지, 어떤 버튼을 만들지를 YAML로 선언한다. 구글 시트 내보내기도 액션 하나를 추가하는 방식으로 붙인다.

아래는 주문 테이블에 구글 시트 내보내기 버튼을 추가하는 실제 예시다. 특정 상태의 주문만 필터링해서 내보내고, CS 역할을 가진 팀원만 이 버튼을 볼 수 있도록 권한을 제한하는 설정까지 포함했다.

menus:
  - path: orders
    name: 주문 관리
    roles:
      list:
        - cs
        - admin
      view:
        - cs
        - admin

pages:
  - path: /orders
    blocks:
      - type: query
        resource: mysql
        sqlType: select
        sql: >
          SELECT
            id,
            user_email,
            product_name,
            amount,
            status,
            created_at
          FROM orders
          WHERE
            (!LENGTH(:status) OR status = :status)
            AND (
              !LENGTH(:start_date)
              OR created_at >= :start_date
            )
            AND (
              !LENGTH(:end_date)
              OR created_at < DATE_ADD(:end_date, INTERVAL 1 DAY)
            )
          ORDER BY id DESC
          LIMIT 1000
        params:
          - key: status
            label: 주문 상태
            dropdown:
              - ''
              - paid
              - shipping
              - failed
          - key: start_date
            label: 시작일
            format: date
          - key: end_date
            label: 종료일
            format: date
        selectOptions:
          enabled: true
        actions:
          - label: 구글시트로 열기
            single: true
            showDownload: true
            placement: top right

이 YAML 하나로 세 가지가 동시에 해결된다. CS팀이 원하는 조건(기간, 상태)으로 필터링한 뒤 직접 내보낼 수 있고, 내보낼 수 있는 사람을 CS와 관리자 역할로 제한할 수 있으며, 코드 변경이나 배포 없이 YAML만 수정하면 된다.

• 구현 비용: 낮다. DB 연결 세팅과 YAML 작성이 전부다. 기존 어드민 코드베이스를 건드리지 않는다.
• 실시간성: 팀원이 버튼을 누르는 시점의 데이터. 필터를 붙여서 원하는 범위만 내보낼 수 있다.
• 권한 제어: 역할(role) 기반으로 어떤 팀원이 어떤 버튼을 쓸 수 있는지 YAML로 선언한다. 코드 없이 권한 구조를 변경할 수 있다.
• 유지보수 부담: 낮다. YAML 수정이 전부라 코드 리뷰나 별도 배포 없이도 변경이 쉽다.

이 방법의 제약: 기존에 이미 잘 만들어진 어드민이 있고, 거기에 기능을 추가하는 게 자연스러운 상황이라면 새로운 툴을 도입할 이유는 없다.

어울리는 상황: 어드민이 없거나 레거시 어드민을 대체하고 싶을 때. 개발 리소스를 제품에 집중하고 싶고, 내부 도구는 빠르고 가볍게 운영하고 싶을 때.

상황별 정리

데이터 공유 문제는 대부분 "일단 CSV"로 시작해서, 요청이 반복되면 자동화가 필요해지고, 팀원이 직접 조회해야 하는 시점이 오면 결국 어드민이 필요해진다. 지금 어느 단계에 있는지가 방법 선택의 핵심이다.

자주 묻는 질문

Q. 조회와 내보내기를 동시에 해결하고 싶다면?

단일 툴로 두 가지를 모두 커버하려면 어드민이 필요하다. Redash/Metabase는 조회 + CSV 다운로드를 커버하고, 셀렉트 어드민은 조회 + 구글시트/CSV/엑셀 내보내기를 커버한다. 직접 개발한 어드민은 원하는 대로 설계할 수 있다. Google Sheets API는 조회 인터페이스를 제공하지 않는다.

Q. Google Sheets API와 직접 어드민 개발 중 어느 쪽이 더 안전한가?

두 방법은 위협 모델이 다르다. Google Sheets API 방식은 서비스 계정 키가 유출되면 해당 시트 전체에 대한 접근 권한이 노출된다. 별도 인증 없이 스크립트가 돌기 때문에 "누가 언제 어떤 데이터를 내보냈는지" 접근 이력을 남기기 어렵다. 어드민 방식은 팀원 인증을 붙일 수 있어서 접근 이력 추적이 가능하다. 개인정보나 결제 정보처럼 민감한 데이터를 다룬다면 어드민 방식이 더 안전하다.

Q. DB 스키마가 바뀌면 각 방법은 어떻게 대응해야 하는가?

CSV 수동 방식은 쿼리를 수정하면 끝이다. Google Sheets API 스크립트는 컬럼 매핑 코드를 수정해야 한다. 직접 개발한 어드민은 코드를 수정하고 배포해야 한다. 셀렉트 어드민의 YAML 방식은 YAML 파일에서 컬럼 목록을 수정하면 된다. 코드 배포 없이 변경할 수 있어서 변경 반경이 가장 좁다.

Q. Redash 없이 비슷한 효과를 낼 수 있는가?

Redash가 제공하는 핵심은 비개발자가 직접 쿼리를 실행할 수 있는 인터페이스다. 이 인터페이스 없이 비슷한 효과를 내려면 어드민 빌더에서 테이블 뷰 + 필터 조합으로 구성하면 된다. 단, SQL 편집기나 대시보드 시각화까지 대체하려는 건 다른 얘기다.

Q. 팀 규모가 커지면 어느 방법이 가장 잘 확장되는가?

팀원이 늘어날수록 "누가 어떤 데이터를 볼 수 있는가"에 대한 제어가 중요해진다. CSV와 Google Sheets API 방식은 파일·시트 단위 공유라서 세밀한 권한 제어가 어렵다. 어드민(직접 개발 또는 어드민 빌더) 방식은 역할 기반 접근 제어(RBAC)를 붙일 수 있어서 팀이 커져도 관리가 가능하다. CS·운영·재무 등 역할이 세분화되는 시점에는 어드민 방식으로 전환을 검토할 만하다.