AI에 구글 스프레드시트를 연결하면 토큰이 빨리 소모되는 이유

AI와 구글시트를 연결할 때 실제로 일어나는 일

사용자는 “지난달 고객 문의를 요약해줘”라고 한 문장만 입력합니다. 하지만 뒤에서는 AI가 도구를 호출하고, 도구가 스프레드시트 API에서 데이터를 읽은 뒤, 그 결과를 다시 모델이 읽을 수 있는 형태로 전달합니다. 사용자가 쓴 문장은 짧아도 도구의 반환값이 길면 실제 입력 컨텍스트는 커집니다.

여기서 비용을 좌우하는 핵심은 2단계와 3단계 사이입니다. 조회 도구가 최근 한 달의 필요한 다섯 열만 반환할 수도 있고, 여러 탭의 사용 범위 전체를 반환할 수도 있습니다. 같은 질문이어도 연결 방식과 도구 설계에 따라 모델이 읽어야 하는 양이 크게 달라집니다.

구글시트는 최대 10만 행이 아니라 1,000만 셀로 계산한다

구글 스프레드시트의 공식 한도는 단순히 “몇 행”으로 정해져 있지 않습니다. 구글에서 만들거나 변환한 스프레드시트 한 파일은 최대 1,000만 셀 또는 18,278개 열까지 지원합니다. 따라서 열 개수에 따라 가능한 행 수가 달라집니다.

사용 열 수	1,000만 셀에 도달하는 행 수	AI 연결 시 의미
10열	약 100만 행	단순 로그도 전체 조회하면 매우 큰 결과가 될 수 있음
50열	약 20만 행	CRM·주문 데이터에서 흔히 넓어지는 구조
100열	약 10만 행	10만 행 예시는 이 조건에서 1,000만 셀에 해당

물론 1,000만 셀을 만들었다고 그 셀이 모두 AI에 전달되는 것은 아닙니다. 반대로 행 수가 적어도 상담 내용, 회의록, 상품 설명처럼 한 셀에 긴 문장이 들어 있다면 전달되는 텍스트는 상당히 커질 수 있습니다. 셀 개수는 위험 신호이고, 실제 토큰 사용량은 반환된 값의 길이와 반복 횟수를 함께 봐야 합니다.

공식 기준 확인: 구글은 스프레드시트 파일 한도를 1,000만 셀로 안내합니다. Sheets API는 요청당 강제 크기 한도를 두지 않지만 처리 속도를 위해 약 2MB 이하의 페이로드를 권장합니다. 자세한 기준은 Google Drive 파일 한도와 Google Sheets API 사용 한도에서 확인할 수 있습니다.

시트가 무거울수록 토큰이 새기 쉬운 일곱 가지 이유

1. 전체 열을 조회합니다. 필요한 열은 날짜·상태·내용뿐인데 A:ZZ처럼 넓은 범위를 읽으면 관계없는 값까지 반환됩니다.
2. 전체 사용 범위를 반복해서 읽습니다. 첫 질문에서 읽은 데이터를 후속 질문마다 다시 가져오면 같은 내용에 비용이 반복됩니다.
3. 긴 텍스트 셀이 많습니다. 상담 기록, 후기, 이메일 본문은 셀 수보다 글자 수가 문제입니다.
4. 여러 탭을 한꺼번에 검색합니다. 원본·백업·가공·보고서 탭에 같은 데이터가 중복될 수 있습니다.
5. 필터와 계산까지 AI에 맡깁니다. 단순 합계에 원본 행 전체를 보낼 필요는 없습니다.
6. 도구가 서식과 메타데이터까지 반환합니다. 값만 필요하지만 수식·서식·좌표 정보가 결과에 포함될 수 있습니다.
7. 오류 재시도가 중복 호출을 만듭니다. 응답 지연이나 API 제한 때문에 같은 범위를 다시 읽으면 호출량과 처리량이 늘어납니다.

전체 조회, 범위 제한, 사전 집계는 이렇게 다르다

고객 문의 10만 건이 있는 시트에서 “지난달 문의 유형별 건수와 주요 불만을 알려줘”라고 묻는 상황을 생각해보겠습니다.

설계	AI에 보내는 내용	장단점
전체 조회	원본 10만 행과 관계없는 열까지 포함	구현은 쉽지만 느리고, 비용과 개인정보 노출 범위가 커질 수 있음
범위 제한	지난달 행에서 날짜·유형·문의 내용만	원문 분석은 가능하면서 불필요한 데이터가 감소
사전 집계	유형별 건수, 변화율, 대표 문의 일부	가장 가볍고 반복 보고에 적합하지만 집계 기준을 먼저 정해야 함

이 막대는 특정 모델의 토큰 수를 뜻하는 실측치가 아니라 상대적인 데이터 흐름을 보여주는 그림입니다. 토큰 수는 언어, 셀 내용, 직렬화 형식, 도구가 붙이는 설명, 사용하는 모델에 따라 달라집니다. 운영에서는 “몇 토큰인지 추측”하기보다 실제 요청 로그의 입력 토큰과 도구 반환 크기를 함께 기록하는 편이 정확합니다.

토큰 비용을 줄이는 구글시트 구조

1. AI 전용 뷰를 따로 만든다

원본 탭을 그대로 연결하지 말고 AI가 읽을 AI_VIEW 탭을 만듭니다. 필요한 열만 가져오고, 날짜 형식과 상태값을 통일하며, 불필요한 메모와 개인정보를 제외합니다. 원본과 AI 입력을 분리하면 사람이 시트에 열을 추가해도 에이전트의 입력 구조가 갑자기 변하지 않습니다.

2. 질문 전에 범위를 결정한다

“이 시트를 분석해줘” 대신 “2026년 7월 데이터 중 상태가 완료인 행의 B·D·F열만 읽어줘”처럼 기간·조건·열을 지정합니다. 도구가 A1 표기법을 지원한다면 문의!A1:ZZ보다 실제 필요한 범위를 사용합니다.

3. 숫자 계산은 시트나 코드에서 먼저 한다

합계, 평균, 개수, 중복 제거, 날짜 필터처럼 규칙이 분명한 작업은 QUERY·피벗 테이블·Apps Script·데이터베이스가 더 적합합니다. AI에는 집계 결과와 해석에 필요한 표본만 보내고, “왜 변했는지 설명하는 일”을 맡깁니다.

4. 변경된 행만 읽는다

정기 보고 자동화라면 마지막 처리 시각이나 행 ID를 저장합니다. 매번 첫 행부터 읽지 않고 지난 실행 이후 추가되거나 바뀐 행만 가져오면 반복 전달을 줄일 수 있습니다.

5. 긴 원문은 검색 후 일부만 가져온다

상담 내용이나 회의록 전체를 한꺼번에 보내지 말고 키워드·기간·상태로 후보를 좁힙니다. 문서가 많다면 제목과 짧은 요약을 먼저 검색하고, 관련성이 높은 원문만 두 번째 단계에서 읽는 구조가 낫습니다.

AI 에이전트에 줄 수 있는 실전 지시문

프롬프트만으로 모든 커넥터의 동작을 강제할 수 있는 것은 아닙니다. 하지만 도구 호출을 확인할 수 있는 에이전트라면 전체 파일 검색을 기본값으로 두는 일을 줄이는 데 도움이 됩니다. 더 확실한 방법은 도구 자체가 허용하는 행 수, 열, 기간과 반환 글자 수에 상한을 두는 것입니다.

구글드라이브 연결에서도 같은 문제가 생긴다

구글드라이브는 시트보다 파일 종류가 다양합니다. 오래된 제안서, 중복 PDF, 회의록, 백업 문서가 검색 결과에 함께 나오면 AI는 관계없는 내용을 읽거나 서로 다른 버전을 섞을 수 있습니다. 문서를 많이 연결하는 것과 필요한 지식을 잘 찾는 것은 다른 문제입니다.

폴더 범위, 작성일, 파일 유형, 문서 상태를 먼저 좁히고 최신본과 보관본을 구분해야 합니다. 검색 결과에서는 제목·날짜·요약만 먼저 받고, 선택된 문서의 필요한 부분만 읽는 2단계 구조가 유리합니다. 토큰 절약뿐 아니라 오래된 문서를 근거로 답하는 오류도 줄일 수 있습니다.

연결 전에 확인할 체크리스트

마무리: AI에는 데이터 창고가 아니라 필요한 작업대를 보여준다

AI와 구글시트를 연결할 때 흔한 착각은 데이터가 많을수록 답도 좋아질 것이라는 생각입니다. 실제로는 질문과 관계없는 행과 열이 많을수록 비용이 커지고 핵심 정보가 흐려질 수 있습니다. 연결의 목표는 AI가 모든 자료를 읽게 만드는 것이 아니라, 매 질문에 필요한 자료를 정확히 꺼내주는 것입니다.

가장 먼저 할 일은 단순합니다. 전체 시트 대신 AI 전용 탭을 만들고, 필요한 기간과 열만 읽게 하며, 숫자는 먼저 집계합니다. 이 세 가지로도 구글시트 기반 AI 자동화의 비용과 응답 품질을 훨씬 관리하기 쉬워집니다.

자주 묻는 질문

구글시트를 AI에 연결하기만 해도 토큰이 사용되나요?

연결 권한만 부여한 상태와 실제 데이터를 읽어 모델에 전달하는 상태는 다릅니다. 일반적으로 모델의 입력 토큰에는 도구가 조회해 컨텍스트로 전달한 내용이 영향을 줍니다.

구글 스프레드시트는 최대 몇 행까지 가능한가요?

고정된 행 한도보다 파일당 최대 1,000만 셀이라는 기준을 적용합니다. 사용하는 열이 100개라면 약 10만 행에서 1,000만 셀에 도달합니다.

빈 셀도 AI 토큰을 소비하나요?

커넥터가 빈 셀을 어떤 형식으로 반환하는지에 따라 다릅니다. 빈 값 자체보다 넓은 범위의 좌표·구조·메타데이터가 함께 반환되는지를 확인해야 합니다.

토큰을 가장 많이 줄이는 방법은 무엇인가요?

원본 전체를 보내지 않고 질문에 필요한 행과 열만 조회하는 것이 출발점입니다. 반복 보고라면 시트나 코드에서 먼저 집계한 작은 표를 AI에 전달하는 방식이 효과적입니다.