ChatGPT Work 데이터 에이전트의 지표·권한 경계 설계

1. 새 데이터 에이전트가 바꾸는 것은 질의 화면이 아니라 해석의 진입점이다

2026년 9월 10일 OpenAI는 ChatGPT Work에 Data agent를 도입한다고 발표했다. 발표에 따르면 이 기능은 회사 데이터에 연결해 변화 원인을 살피고, 대화 안에서 분석을 다듬으며, 공유 가능한 대시보드를 만들 수 있도록 설계됐다. 승인된 원천으로 Amazon Redshift, Datadog, Google BigQuery, ClickHouse, Databricks, MongoDB, Snowflake 등을 예시로 들고, Google Drive와 SharePoint의 파일·문서도 분석에 가져올 수 있다고 설명한다. OpenAI의 제품 발표는 이 기능을 “질문만으로 회사 데이터를 답변과 대시보드로 바꾸는” 도구로 소개한다.

여기서 중요한 변화는 SQL을 몰라도 된다는 문구 자체가 아니다. 조직 안에는 이미 같은 이름으로 서로 다른 수치를 뜻하는 지표가 많다. 예를 들어 “활성 사용자”가 로그인한 사람인지, 핵심 기능을 한 번 실행한 사람인지, 결제 권한이 살아 있는 사람인지에 따라 답은 달라진다. “지난달 매출”도 주문일 기준인지 결제일 기준인지, 환불을 어느 시점에 차감하는지, 세금과 할인은 포함하는지에 따라 비교가 바뀐다. 자연어는 이 모호함을 숨기기 쉽다.

OpenAI는 Data agent가 조직의 비즈니스 용어, 지표 정의, 사용자 정의 계산, 데이터 관계를 이용하며, 이런 맥락이 시맨틱 레이어와 신뢰할 수 있는 원천에서 온다고 밝힌다. 이 사실은 제품이 모든 조직에서 올바른 결론을 보장한다는 뜻은 아니다. 오히려 도입팀이 먼저 물어야 할 질문을 선명하게 한다. 우리에게 신뢰할 만한 정의가 실제로 존재하는가, 그리고 그 정의가 현재 연결하려는 데이터와 같은 버전인가.

따라서 첫 번째 도입 과제는 모델에게 긴 프롬프트를 쓰게 하는 일이 아니라, 분석에 쓰일 지표를 작고 명확한 계약으로 남기는 일이다. 이 글에서는 이를 ‘지표 정의 카드’라고 부른다. 이는 공식 기능 요구사항이 아니라, 발표 범위를 현장에 적용하기 위한 편집부의 운영 제안이다.

# 지표 정의 카드 — 제안 양식

- **질문에서 쓰는 지표명**: 주간 활성 사용자
- **비즈니스 정의**: [조직이 합의한 정의를 한 문장으로 작성]
- **계산식 또는 시맨틱 모델 이름**: [dbt 모델·BI 지표·문서 링크]
- **모집단과 제외 규칙**: [테스트 계정, 내부 계정, 탈퇴 계정 처리]
- **시간 기준과 비교 기간**: [KST/UTC, 캘린더 주/최근 7일]
- **소유자와 마지막 검토일**: [담당 팀과 날짜]
- **질문에 답할 수 없는 조건**: [정의 미승인, 원천 지연, 결측 등]

이 카드는 답변의 부록이 아니라 답변 전 단계다. 질문자가 “활성 사용자가 왜 줄었나”라고 물으면 에이전트는 먼저 적용한 정의와 기간을 보여 주고, 질문자가 다르게 의도했다면 그 지점에서 수정할 수 있어야 한다. 그래야 자연어의 편리함이 조용한 정의 변경으로 바뀌지 않는다.

2. 접근 권한은 데이터 연결 설정이 아니라 답변이 말할 수 있는 범위다

데이터를 연결할 때 가장 위험한 오해는 ‘읽기 권한’만 있으면 안전하다는 생각이다. 고객·직원·거래 데이터는 같은 테이블 안에서도 행과 열마다 노출 조건이 다를 수 있다. 제품 발표는 관리자가 어떤 연결을 제공하고 어떤 역할이 이를 사용할지 선택하며, 질의는 연결 계정의 기존 권한을 적용한다고 명시한다. 여기에는 테이블, 행, 열 수준의 제한이 포함된다. OpenAI 제품 발표의 권한 설명은 새 도구가 별도의 전권 계정을 가져간다고 말하지 않고, 연결된 계정의 접근 제어를 따른다고 설명한다.

이 기능 범위를 실무 문장으로 바꾸면 다음과 같다. Data agent에 무엇을 묻느냐보다 어떤 연결 계정으로 무엇을 볼 수 있느냐가 답변의 관측 창을 정한다. 따라서 운영자는 “전사 매출을 요약해 줘” 같은 요청이 들어왔을 때 결과 문장만 검토해서는 안 된다. 사용된 연결, 적용된 역할, 조회한 원천, 보지 못한 범위를 함께 확인해야 한다.

권한을 넓히기 전에 작은 역할부터 시작하는 편이 낫다. 예컨대 성장팀에는 승인된 제품 사용 지표와 익명화된 집계 뷰만, 재무팀에는 정해진 손익 모델만 연결한다. 이 문단은 특정 권한 구성이 공식 권고라는 주장이 아니라, 최소 권한 원칙을 데이터 에이전트 도입에 적용한 제안이다. 핵심은 모든 사용자가 더 많은 데이터를 보게 하는 것이 아니라, 필요한 사람이 승인된 의미의 데이터를 검토 가능한 방식으로 보게 하는 데 있다.

3. ‘답변’, ‘추가 확인’, ‘보류’를 분리하는 운영 경로

질문 하나가 들어왔을 때 시스템이 곧장 분석을 시작하도록 두면, 모호함과 권한 문제는 최종 문장의 작은 각주로 밀려난다. 반대로 아래처럼 세 가지 결과를 분리하면, 분석은 단순한 답변 생성이 아니라 검토 가능한 의사결정 과정이 된다. 이는 이 글의 운영 제안이며 제품의 자동 동작을 설명한 것이 아니다.

[업무 질문]
     |
     v
[지표 정의·기간·모집단 확인]
     |-- 정의가 모호함 --> [추가 맥락 요청] --> [질문 재확인]
     |
     v
[연결 계정의 접근 범위 확인]
     |-- 필요한 원천에 권한 없음 --> [보류 + 필요한 승인 경로 안내]
     |
     v
[승인된 원천에서 분석]
     |
     v
[정의·원천·한계·근거 링크를 포함한 답변]

▲ 이 이미지는 실제 제품 화면이 아니라, 모호한 정의와 불충분한 권한을 답변 이전에 분기하는 제안 운영 흐름을 나타낸 개념 일러스트입니다.

추가 확인은 실패가 아니다. “전환율이 떨어졌다”는 요청에서 분모가 방문자인지 가입자인지 불명확하면, 정확해 보이는 숫자를 내는 것보다 확인 질문을 돌려주는 편이 낫다. 보류도 실패가 아니다. 권한 없는 개인 식별 데이터가 필요하다면, 에이전트가 비슷한 집계로 추측하거나 우회하지 않고 필요한 데이터 소유자와 승인 절차를 알려야 한다. 이 두 결과를 채택하면 팀은 ‘무슨 답을 얻었나’뿐 아니라 ‘왜 아직 답하지 않았나’를 추적할 수 있다.

OpenAI는 사용자가 결과의 근거를 검토하기 위해 후속 질문을 할 수 있으며, 분석 결과를 대시보드로 만들고 공유·갱신할 수 있다고 설명한다. 분석과 후속 질문에 대한 설명은 특히 이 마지막 단계의 설계가 중요함을 보여 준다. 대시보드나 요약은 확정판처럼 보이기 쉽기 때문이다. 따라서 답변 화면이나 공유 문서에 최소한 다음 네 줄을 남기는 방식을 권한다.

## 답변 검토 메모 — 제안 양식

- **적용한 지표 정의**: [정의 카드 또는 시맨틱 모델 링크]
- **조회 범위**: [기간, 필터, 연결 원천, 적용 역할]
- **확인한 근거**: [원천 쿼리·대시보드·문서 링크]
- **해석의 한계와 다음 확인**: [지연, 결측, 비교 불가 조건]

이 기록은 모델의 추론 과정을 완전히 공개한다는 약속이 아니다. 사람이 결과를 재검토할 때 필요한 데이터 계약과 근거의 위치를 남기자는 제안이다. 근거 링크가 없는 흥미로운 설명은 가설로 취급하고, 원천을 따라가 확인할 수 있는 설명만 의사결정 재료로 올리는 기준이 필요하다.

4. 첫 도입은 ‘전사 연결’이 아니라 하나의 반복 가능한 질문에서 시작한다

Data agent의 공식 예시는 주간 활성 사용자 변화의 원인을 살피기, KPI 프레임워크를 설계하기, 실제값·비교·동인·주의점·권고 조치를 포함한 리더십 업데이트 만들기 등을 제시한다. OpenAI가 공개한 시작 프롬프트를 보면, 기능의 목표는 하나의 고정 대시보드보다 질문을 반복하며 분석을 발전시키는 데 있다.

그래서 첫 파일럿은 ‘우리 회사의 모든 데이터를 연결한다’가 아니라 하나의 되풀이되는 질문으로 잡는 것이 좋다. 예를 들면 “지난 주 활성 사용자가 변한 이유”처럼 범위가 분명하고, 이미 소유자·정의·원천이 있는 질문이다. 다음 네 가지가 준비되지 않았다면 연결 범위를 넓히기보다 준비 작업을 먼저 하는 편이 낫다.

1. 해당 지표의 정의와 계산 책임자가 정해져 있는가.
2. 분석에 필요한 원천과 접근 역할을 목록으로 설명할 수 있는가.
3. 사람이 기존 보고서나 쿼리로 결과를 대조할 수 있는가.
4. 답변이 틀리거나 불완전했을 때 정정·보류·에스컬레이션 경로가 있는가.

이 네 항목은 인증이나 규제 준수를 보장하는 체크리스트가 아니다. 도입 범위를 작게 유지하면서, 자연어 분석이 실제 의사결정에 들어가기 전에 검토 루프를 만들기 위한 업무 점검 질문이다. 확인이 끝난 질문만 다음 단계의 대시보드·공유·행동으로 넘겨야 한다.

파일럿을 평가할 때도 ‘답변을 몇 개 만들었는가’만 세면 안 된다. 같은 질문을 기존의 승인된 보고서와 비교했을 때 어떤 정의가 적용됐는지 설명할 수 있었는지, 근거 링크가 끊기지 않았는지, 모호한 요청을 실제로 되물었는지, 권한이 없는 원천을 보류했는지를 사례 단위로 검토해야 한다. 이 평가는 모델의 일반 성능을 측정하는 실험이 아니라, 팀이 만든 데이터 계약과 검토 흐름이 작동하는지를 점검하는 운영 기록이다. 답변이 맞더라도 적용한 기간·필터·정의가 불명확했다면 그 결과는 다음 의사결정에 재사용하기 어렵다. 반대로 보류가 남았더라도 필요한 정의의 소유자나 승인 경로가 분명해졌다면, 그 보류는 시스템이 경계를 지킨 유용한 결과가 될 수 있다.

이 기록은 데이터 팀만의 문서가 아니다. 현업 질문자도 자신이 요청한 수치의 뜻과 제한을 확인할 수 있어야 하며, 소유자는 정의가 바뀐 시점과 영향받는 보고서를 추적할 수 있어야 한다. 그래야 같은 질문이 다음 달에 다시 들어와도, 더 그럴듯한 문장이 아니라 같은 기준으로 비교 가능한 답을 만들 수 있다.

5. 결론: 데이터 에이전트의 신뢰는 답변의 화려함이 아니라 경계의 명확함에서 나온다

ChatGPT Work의 Data agent 발표는 데이터 분석의 입구를 더 많은 현업 사용자에게 열었다. 동시에 조직은 답변을 생성하는 능력과 답변을 믿어도 되는 조건을 분리해 설계해야 한다. 공식 발표가 말하는 승인된 연결, 조직의 비즈니스 정의, 기존 접근 제어, 근거 검토는 그 출발점이다.

이 글의 제안은 간단하다. 모든 질문 앞에 정의 카드를 두고, 모든 분석 앞에 연결 계정의 권한 범위를 확인하며, 모든 답변 뒤에는 근거와 한계를 남긴다. 정의가 모호하면 추가 확인을 요청하고, 권한이 없으면 보류한다. 이 경계가 있어야 빠른 자연어 질의가 빠른 오해가 아니라, 조직이 함께 검토할 수 있는 분석으로 이어진다.

참고 자료 (References)

• OpenAI Help - ChatGPT Enterprise Privacy, Compliance & Security FAQ
• OpenAI Business - Enterprise Data Controls