LLM은 스프레드시트 수식을 꽤 그럴듯하게 써 준다. 함수 이름이 생각나지 않거나 여러 조건을 한 식으로 묶어야 할 때 특히 편하다. 하지만 수식을 쓰는 것과 수식이 맞는지 판단하는 것은 다른 일이다.
내가 택한 원칙은 단순하다. 수식 후보는 LLM에게 맡긴다. 실제 계산은 Excel이나 Google Sheets에 맡기고, 더 복잡해지면 Python 스크립트로 옮긴다. 그리고 그 결과가 내 의도와 맞는지는 내가 확인한다.
복잡한 데이터 설계를 설명하려는 글은 아니다. 수식을 직접 쓰기 어려운 사람도 AI를 이용하면서 결과를 확인할 수 있도록, 작은 작업 순서를 정리하려 한다.
수식을 쓰는 일과 계산하는 일을 나눈다
자연어를 스프레드시트 수식으로 옮기는 일은 이미 하나의 연구 분야다. NL2Formula는 표와 자연어 요청을 바탕으로 실행 가능한 수식을 만드는 문제를 다룬다. 다만 수식이 만들어졌다는 사실만으로 사용자의 뜻까지 맞게 옮겼다고 볼 수는 없다. NL2Formula
누가 무엇을 맡을지 정하면 확인할 지점도 분명해진다.
| 역할 | 맡을 일 |
|---|---|
| 사람 | 계산 목적, 포함 범위, 빈칸 처리, 기대 결과를 정한다. |
| LLM | 자연어를 수식 후보로 옮기고, 자신이 이해한 조건을 설명한다. |
| 스프레드시트·Python | 실제 값을 읽어 수식이나 계산 절차를 반복해서 실행한다. |
| 사람과 검토용 표 | 실제 결과가 기대 결과와 같은지 판단한다. |
PAL 연구도 LLM이 프로그램을 만들고 실제 실행은 별도의 인터프리터에 맡겼다. 이 연구가 스프레드시트 사용법을 정한 것은 아니다. 여기서는 언어 모델의 답변과 계산 실행을 나눌 수 있다는 점만 참고한다. PAL
스프레드시트 엔진은 주어진 수식을 정해진 방식대로 실행한다. 그러나 잘못된 범위를 지정한 수식도 똑같이 성실하게 실행한다. 계산을 엔진에 맡기는 것만으로는 부족한 이유다.
수식보다 기대 결과를 먼저 적는다
예를 들어 다음 표에서 플랫폼이 A인 행만 고른 뒤, 결과 1부터 결과 3까지의 Pass 개수를 세고 싶다고 하자.
| 플랫폼 | 결과 1 | 결과 2 | 결과 3 |
|---|---|---|---|
| A | Pass | Fail | Pass |
| B | Pass | Pass | Pass |
| A | Fail | Pass | 빈칸 |
사람이 먼저 정할 내용은 수식이 아니라 다음 네 가지다.
- 플랫폼이
A인 첫째 행과 셋째 행만 본다. - 선택된 두 행의 결과 칸 여섯 개를 모두 본다.
Pass만 세고Fail과 빈칸은 세지 않는다.- 기대 결과는
3이다.
이 내용을 받은 LLM은 다음과 같은 수식 후보를 만들 수 있다.
=COUNTIFS(A2:A4,"A",B2:B4,"Pass")+COUNTIFS(A2:A4,"A",C2:C4,"Pass")+COUNTIFS(A2:A4,"A",D2:D4,"Pass")
함수와 구분자는 제품과 지역 설정에 따라 달라질 수 있다. 여기서 중요한 것은 식 자체가 아니다. LLM이 결과 1 열만 세었다면 수식은 정상적으로 실행되지만 답은 1이 된다. 오류 메시지가 없다고 내 뜻까지 제대로 전달된 것은 아니다.
수식을 읽기 어려워도 검토할 수 있다
복잡한 수식을 한 글자씩 읽는다고 제대로 확인되는 것은 아니다. 오래된 연구 하나에서는 스프레드시트 수식을 화면에 보여 줘도 오류를 더 잘 찾지 못했다. 지금의 모든 사용자에게 그대로 적용할 결과는 아니지만, “수식을 보여 줬으니 검토가 끝났다”고 생각해서는 안 된다는 점은 분명하다. Spreadsheet Presentation and Error Detection
수식 문법 대신 동작을 확인한다.
- LLM에게 이해한 뜻을 먼저 되묻는다. 어떤 행과 열을 읽는지, 빈칸과 오류값은 어떻게 다루는지 짧게 설명하게 한다.
- 정상 사례와 경계 사례를 적는다. 기준값 바로 전과 후, 빈칸, 0, 잘못된 형식을 넣고 기대 결과를 사람이 정한다.
- 원본의 사본에서 실행한다. 기대 결과와 실제 결과를 나란히 놓는다.
- 값과 행을 바꿔 다시 계산한다. 현재 데이터에서 우연히 맞은 수식인지 확인한다.
- 중요한 값은 다른 방법으로 한 번 더 본다. 손계산, 더 단순한 별도 수식, 짧은 코드, 업무 기준을 아는 사람의 판단을 이용한다.
Excel의 오류 검사도 모든 오류를 찾아 주지는 않는다. Microsoft 역시 수식이 의도하지 않은 결과를 낼 수 있고, 오류 검사 기능만으로 모든 문제를 찾을 수는 없다고 설명한다. Detect formula errors in Excel
같은 LLM에게 “다시 검토해 줘”라고만 하는 것은 별도의 확인이 아니다. 처음에 범위를 잘못 이해했다면 설명과 재검토에서도 같은 가정을 되풀이할 수 있다. 핵심 기대값 몇 개는 사람이 정하거나 다른 계산 방법에서 가져와야 한다.
LLM에게는 수식과 가정을 함께 요청한다
“이 표를 계산해 줘”보다 다음처럼 요청하는 편이 낫다.
Google Sheets용 수식 후보를 만들어 줘.
목적: 플랫폼이 A인 행에서 결과 1~3의 Pass 개수를 센다.
범위: A2:D4
빈칸: 세지 않는다.
기대 결과: 위 예시에서는 3이다.
수식을 만들기 전에 네가 이해한 행 선택 조건과 집계 범위를 설명해 줘.
수식과 함께 참조 범위, 빈칸 처리, 확인이 필요한 가정도 적어 줘.
여기서 자연어 설명은 검토를 돕는 보조 수단이다. 설명이 그럴듯하다고 수식까지 맞는 것은 아니다. 마지막 판단은 스프레드시트에서 나온 값과 미리 적어 둔 기대값을 비교해 내린다.
업무 기준이 모호하면 수식 생성을 멈추는 편이 낫다. 이상과 초과, 이번 달, 유효 사용자, 평균은 문맥에 따라 뜻이 달라진다. 빈칸이 0인지 미측정인지, 숨긴 행과 필터로 빠진 행을 포함하는지, 반올림 전후 어느 값을 비교하는지도 먼저 정해야 한다. 사용자가 답할 수 없다면 해당 기준을 아는 사람에게 확인해야 한다. LLM의 추측을 업무 규칙으로 채택해서는 안 된다.
데이터의 기준은 검토에 필요한 만큼만 정한다
수식을 제대로 살펴보려면 계산에 쓰인 데이터의 기준도 알아야 한다. 그렇다고 거대한 데이터 체계를 만들 필요는 없다. 수식 결과를 바꾸는 항목만 먼저 정하면 된다.
| 확인할 항목 | 물어볼 질문 |
|---|---|
| 범위 | 어느 시트와 열, 몇 번째 행까지 읽는가? 새 행은 자동으로 포함되는가? |
| 값의 뜻 | 빈칸, 0, N/A, 오류값은 각각 무엇을 뜻하는가? |
| 단위 | 분과 시간, 원과 천 원처럼 섞일 수 있는가? |
| 경계 | 이상인가 초과인가? 시작일과 종료일을 모두 포함하는가? |
| 계산 순서 | 반올림한 뒤 더하는가, 모두 더한 뒤 반올림하는가? |
작고 한 번만 쓰는 표라면 몇 개의 예시만으로 충분할 수 있다. 반복해서 쓰거나 다른 사람에게 전달하거나 자동화에 연결한다면 수식 버전과 검토용 사례도 함께 남긴다.
모든 계산을 LLM에서 떼어 낼 필요는 없다
“하루 20분을 아끼면 1년에 대략 몇 시간이냐”처럼 한 번만 보는 추정은 LLM에게 바로 물어도 된다. 약간의 오차가 결정을 바꾸지 않고 사용자가 크기를 쉽게 가늠할 수 있기 때문이다.
반면 정확한 합계나 비율이 필요하거나 결과를 반복해서 쓸 때는 계산 도구가 낫다. 돈, 권리, 신고, 안전, 배포처럼 결과가 다른 행동으로 이어지면 업무 기준과 별도의 확인도 필요하다.
AI를 쓰는 것이 늘 더 빠른 것도 아니다. 수식 하나를 직접 쓰는 데 5분이 걸리는데 표 구조를 설명하고 결과를 확인하는 데 20분이 든다면 직접 쓰는 편이 합리적이다. 반대로 비슷한 수식을 여러 번 만들고 같은 검토용 사례를 반복 실행할 수 있다면 처음 들인 시간을 나눠 쓸 수 있다.
수식이 복잡해지면 구조를 바꾼다
긴 수식 하나에 조건을 계속 붙이면 사람도 LLM도 범위를 놓치기 쉽다. 이때는 더 영리한 한 줄을 요구하기보다 다음 선택을 살펴본다.
- 중간 결과가 보이도록 보조 열을 만든다.
- 여러 열에 흩어진 같은 종류의 값을 한 열로 정리한다.
- 반복 규칙을 짧은 코드로 옮기고 예시를 자동으로 대조한다.
- 급여, 세금, 회계, 의료, 안전처럼 영향이 큰 계산은 해당 분야의 기준과 담당자 검토를 거친다.
SpreadsheetBench는 실제 스프레드시트 과제를 평가할 때 생성된 코드를 파일에 적용하고, 여러 시험용 파일에서 최종 결과를 확인했다. 연구 당시 모델의 성능을 현재 제품에 그대로 적용할 수는 없지만, 답변 모양보다 실제 실행 결과를 봐야 한다는 평가 방식은 참고할 만하다. SpreadsheetBench
OpenAI의 현재 모델 지침도 필터링, 결합, 집계, 검사처럼 규칙이 분명한 일은 프로그램으로 처리하고, 실제 사용 사례로 결과를 따로 확인하라고 권한다. 스프레드시트 수식에 관한 공식 규칙은 아니지만, LLM의 언어 처리와 반복 계산을 한꺼번에 맡기지 말아야 할 이유는 잘 보여 준다. OpenAI Model Guidance
수식을 붙여 넣기 전의 짧은 점검표
- 내가 원하는 결과를 한 문장으로 적었는가?
- 정상·경계·빈칸 사례의 기대 결과를 먼저 정했는가?
- LLM이 이해한 행, 열, 범위, 제외 조건을 되받아 보았는가?
- 원본이 아닌 사본에서 실제로 계산했는가?
- 기대값과 실제값을 나란히 비교했는가?
- 행을 추가하거나 값을 바꿔도 같은 규칙이 유지되는가?
- 결과의 영향이 크다면 다른 방법이나 담당자가 한 번 더 확인했는가?
LLM은 수식 문법을 대신 써 줄 수 있다. 스프레드시트는 그 수식을 빠르고 일관되게 계산한다. 하지만 어느 결과가 맞는지는 둘 다 정할 수 없다. 사람이 먼저 정해야 할 것은 정답 계산이 아니라, 어떤 입력에서 어떤 결과가 나와야 하는지다. 이 작은 표가 있어야 AI가 만든 수식을 믿을지, 고칠지, 버릴지 판단할 수 있다.
AI disclosure
Researched and drafted with OpenAI Codex using GPT‑5.6 Sol (xhigh reasoning). Editorial review and final approval by Yioo.