ChatGPT가 지표 정의를 잊어버리는 이유와 해결 방법 (2026)

지표 이름은 지표가 아닙니다

"매출총이익률(Gross margin)"은 여러 가지 의미를 가질 수 있는 단어입니다. AtScale은 시맨틱 드리프트(semantic drift)의 비용에 관한 보고서에서, 세 팀이 "지난 분기 매출총이익률은 얼마였습니까?"라는 질문에 각각 30%, 32%, 31%로 답한 사례를 소개합니다. 이는 매출 원가에 무엇을 포함할지에 대한 세 가지 정의에서 나온, 각각 나름의 근거가 있는 세 가지 숫자였습니다.

여러분의 AI 비서도 이러한 모호함을 그대로 물려받지만, 이를 해결하는 기준은 물려받지 못합니다. 여러분이 "이탈(churn)"이라고 말할 때, 모델은 일반적인 이탈의 의미에 대한 강력한 사전 지식(prior)을 가지고 있을 뿐, 여러분의 회사가 계정 수가 아닌 매출 기준으로, 연간이 아닌 월간으로, 다운그레이드는 제외하고 측정한다는 사실은 알지 못합니다. 여러분의 정의가 없으면 모델은 사전 지식을 사용합니다. 이는 좁은 의미의 메모리 오류가 아닙니다. 자신감 넘치는 답변의 형태로 나타나는 메모리 오류입니다.

정의는 데이터가 아니라 사람 속에 존재합니다

이 부분이 지표 정의를 스키마보다 더 어렵게 만드는 요인입니다. 테이블은 검사할 수 있는 형태가 있고, 모델은 열 이름과 타입을 읽을 수 있습니다. 하지만 정의는 '의사결정'입니다. 누군가가 어느 시점에 체험판은 포함하지 않기로 결정한 것이며, 그 결정은 Slack 스레드, 대시보드의 SQL, 혹은 누군가의 머릿속에 기록되어 있습니다.

이에 대한 업계의 합의는 유독 직설적입니다. AtScale은 다음과 같이 말합니다: "AI 시스템은 상충되는 정의를 조정하지 못할 뿐만 아니라, 일관성 없는 답변을 자신 있게 제시함으로써 문제를 더욱 악화시킵니다." 실패의 원인은 모델이 수학을 지어내서가 아닙니다. 조직의 여러 정의 중 우연히 재구성한 정의를 모델이 충실하게 실행하기 때문입니다.

이것이 ChatGPT가 데이터 스키마를 잊어버리는 현상과 어떻게 다른지 주목해 보세요. 스키마 유실은 존재하지 않는 열이나 조인 실패처럼 눈에 띄는 오류를 발생시킵니다. 반면 정의 유실은 아무것과도 일치하지 않는 숫자를 만들어내며, 여러분은 회의 중에야 이를 발견하게 됩니다.

세션 간에 정의를 전달하는 장치가 없습니다

한 대화에서 정의를 올바르게 설정하더라도, 이를 다음 대화로 전달하는 메커니즘은 이러한 종류의 콘텐츠에 존재하지 않습니다. 내장 메모리는 사용자에 대한 몇 페이지 분량의 짧은 사실만 기억할 수 있으며, 제외 기준이 포함된 9개 조항의 적격 파이프라인(qualified pipeline) 정의를 담기에는 용량이 부족합니다. 맞춤 지침(custom instructions)은 다른 모든 내용을 밀어내기 전에 두세 개의 정의만 담을 수 있습니다. 프로젝트 파일이 도움이 되지만, 이는 해당 프로젝트와 해당 도구의 범위로 제한됩니다.

결국 정의는 수동으로 다시 제공되며, 이는 대략적으로 제공됨을 의미합니다. 목요일에 입력하는 버전은 월요일 버전보다 짧아집니다. 기억에 의존해 입력하는 데다 제외 기준은 번거로운 부분이기 때문입니다. 여러분 스스로 요약하는 과정에서 미세한 차이(drift)가 발생합니다.

정의는 변경되지만, 이전 버전은 철회되지 않습니다

문제를 더 악화시키는 것은, 3분기에 정의를 수정하더라도 이전의 모든 분석은 2분기 버전을 기준으로 계산되었다는 점입니다. 채팅 기반 워크플로우에는 특정 날짜에 어떤 정의가 다른 정의로 대체되었는지 기록할 공간이 없습니다. 결국 서로 다른 규칙에 따라 계산된 숫자들이 혼재하게 되고, 어떤 규칙이 적용되었는지 알 수 없게 됩니다. 이는 분석 분야에서 날짜가 없는 문서와 같습니다.

매 채팅 시작 시 정의를 복사하여 붙여넣기. 효과적이며, 가장 흔히 쓰이는 방법입니다. 하지만 시간이 지날수록 붙여넣는 텍스트가 짧아지고, 채팅별로 적용되기 때문에 팀의 다른 사람들은 각자 자신만의 버전을 붙여넣게 됩니다.

맞춤 지침(custom instructions)에 정의 넣기. 매일 사용하는 두세 개의 지표에는 더 나은 방법이며, 실제로 해볼 만한 가치가 있습니다. 하지만 곧 공간이 부족해지고, AI 비서가 어떻게 행동해야 하는지 지정하는 대신 지침 용량을 정의로 채우는 데 다 쓰게 됩니다.

정의 문서가 첨부된 프로젝트(Project) 사용하기. 제품 내 옵션 중 가장 좋습니다. 하지만 해당 프로젝트로 범위가 제한되며, 코딩 에이전트나 BI 도구에서 작업하는 경우 해당 문서는 보이지 않습니다.

AI 비서가 SQL을 읽도록 하기. 영리하고 부분적으로 효과적입니다. 정의가 실제로 쿼리 안에 있기 때문입니다. 하지만 의도와 예외 사항을 놓치게 됩니다. SQL은 WHERE status != 'internal' 절을 보여주지만, 이 조건이 감사 결과 때문에 존재한다는 사실은 보여주지 않으며, 논란의 여지가 있는 대시보드 버전을 그대로 보여주기도 합니다.

시맨틱 레이어(semantic layer) 구축하기. 이것이 실제 전문적인 해결책이며, 분명히 짚고 넘어가야 합니다. dbt의 Semantic Layer, AtScale, Cube 등 이 카테고리의 시맨틱 레이어는 지표를 한 번 정의하고 모든 도구가 동일한 방식으로 계산하도록 하기 위해 존재합니다. AtScale은 그 목표를 다음과 같이 설명합니다: "누군가 '우리 매출이 얼마인가요?'라고 물었을 때, 정의가 모든 곳에 일관되게 적용되므로 단 하나의 답변만 존재합니다." 조직이 공유 지표를 기반으로 운영된다면 이는 반드시 투자해야 할 가치가 있으며, 메모리 레이어가 이를 대체할 수는 없습니다.

AtScale은 또한 LLM이 데이터베이스에 직접 쿼리할 때 비즈니스 질문에 대한 정확도가 약 20%에 불과하지만, 시맨틱 레이어가 거버넌스가 적용된 정의, 다차원 비즈니스 로직, 컨텍스트 관계를 제공할 경우 사실상 100%에 가까운 정확도로 상승한다고 보고합니다. 이 수치는 이해관계가 얽힌 벤더의 주장이므로 독립적인 벤치마크로 취급해서는 안 되지만, 그 방향성만큼은 이견이 없으며 거버넌스가 적용된 정의의 필요성을 뒷받침하는 가장 강력한 근거입니다.

시맨틱 레이어가 메우지 못하는 공백은 여러분이 실제로 처한 상황입니다. 오후 6시에 CSV를 붙여넣는 AI 비서, 모델링된 레이어를 거치지 않는 임시(ad-hoc) 질문, 결정은 되었으나 아직 지표로 구현되지 않은 정의, 그리고 BI 권한이 없는 사람이 수행하는 모든 분석이 이에 해당합니다. 바로 이곳에서 정의가 유실되며, 실제로 일어나는 분석의 대부분이 여기에 속합니다.

정의를 채팅 외부의 저장소에 보관하고, AI 비서가 매 요청마다 이를 읽도록 하세요. 복사해서 붙여넣는 메모가 아니라, 답변 과정의 일부로 정의를 제공하는 레이어입니다.

이것이 작동하는 핵심은 저장 공간이 아니라, 정의가 컨텍스트(맥락)와 함께 전달된다는 점입니다. 저장된 정의는 제외 기준, 각 제외 기준의 이유, 승인한 사람, 마지막 변경 시기, 이전 버전이 무엇이었는지를 함께 담을 수 있습니다. 이것이 단순히 "활성 = 90일 이내 결제"라고 적는 것과, 누군가 실제로 책임질 수 있는 정의를 갖는 것의 차이입니다.

MemoryLake는 이를 위해 구축된 메모리 레이어입니다. 여러분의 정의, 의사결정 기록, 소스 문서를 하나의 저장소에 보관하여 ChatGPT는 API를 통해 읽고, Claude 및 Codex와 같은 MCP 지원 도구는 직접 읽을 수 있도록 합니다. 따라서 임시 채팅, 쿼리를 작성하는 코딩 에이전트, 지난주에 입사한 분석가 모두에게 동일한 정의가 전달됩니다.

과장 광고가 실제 피해를 줄 수 있는 영역이므로 두 가지 한계점을 명확히 밝힙니다:

• 메모리 레이어는 정의를 사용 가능하고, 일관되며, 추적 가능하게 만듭니다. 하지만 이를 강제(enforce)하지는 않습니다. 강제하는 것은 시맨틱 레이어의 역할입니다. 즉, 하나의 정의를 통해 모든 쿼리를 계산하는 것입니다. 메모리 레이어는 질문하는 사람에게 정의를 제공할 뿐이며, 모델이 원시 테이블을 전달받아 자체적으로 연산하는 것을 막을 수는 없습니다. 이사회 보고서나 공시 자료에 들어갈 숫자라면 채팅이 아닌 거버넌스가 적용된 레이어를 통해 나와야 합니다.
• 정의에는 메타데이터가 필요합니다. 그렇지 않으면 문제의 위치만 옮기는 꼴이 됩니다. 지표 이름과 공식만 있는 두 개의 열로 된 테이블은 정확히 드리프트를 유발했던 바로 그 유물입니다. 함께 전달되어야 하는 것은 세분성(grain), 시간 범위, 제외 기준과 그 이유, 소유자, 그리고 효력 발생일입니다.

1단계: API 키 생성하기

키를 생성하고 약 30초 만에 첫 번째 요청을 보내보세요. 공유되는 설정 파일이나 노트북에 인라인으로 작성하기보다 환경 변수나 시크릿 관리자(secret manager)에 보관하는 것이 좋습니다.

2단계: 첫 번째 메모리 업로드하기

지표 문서, 대시보드 사양서, 제외 기준이 결정된 Slack 스레드, 이를 유발한 감사 노트 등 정의가 실제로 존재하는 문서, 이미지, 파일을 업로드하세요. 깔끔하게 정리된 요약본이 아닌 소스 파일 자체를 업로드해야 합니다. 정리된 요약본에서는 "내부 계정 제외"와 같은 내용이 소리 소문 없이 사라지기 쉽습니다.

3단계: AI 및 에이전트 연결하기

Claude, Codex, OpenClaw 및 기타 AI 에이전트가 MCP 또는 API를 통해 메모리에 액세스할 수 있도록 하세요. ChatGPT에는 MCP 클라이언트가 없으므로 API를 통해 관련 정의를 검색하여 프롬프트, 맞춤형 GPT 또는 모델을 호출하는 워크플로우에 주입해야 합니다. MCP를 지원하는 도구의 경우 해당 도구의 설정에 서버를 추가하면 동일한 저장소를 읽게 됩니다. 이것이 바로 핵심입니다. 하나의 정의, 여러 소비자.

목요일의 숫자가 월요일의 숫자와 일치하게 됩니다. 이것이 핵심이며, 미화 없이 사실대로 말할 가치가 있습니다. 정의를 다시 입력할 필요가 없기 때문에, 동일한 정의를 기준으로 계산된 동일한 질문은 동일한 답변을 생성합니다.

두 번째 변화는 의견 불일치가 생산적으로 변한다는 점입니다. 지금은 두 숫자가 일치하지 않으면 각 숫자가 무엇을 측정했는지 재구성하는 데 한 시간을 허비합니다. 제외 기준 및 효력 발생일과 함께 정의가 저장되어 있으면, 연산 과정을 역공학하는 대신 정의를 비교하게 됩니다. 그리고 종종 두 숫자 모두 맞았으며 서로 다른 질문에 답하고 있었다는 사실을 발견하게 됩니다.

세 번째는 온보딩입니다. 신입 분석가의 첫 달은 주로 체험판은 포함되지 않는다는 사실을 배우는 데 소비됩니다. 도구가 읽는 저장소에 이 내용이 있으면, 대시보드에서 이를 다시 파악하는 대신 조직의 공식 버전을 바로 사용하기 시작할 수 있습니다.

또한 개정 이력이 명확해집니다. 효력 발생일이 있는 정의를 사용하면 아무도 묻지 않기를 바라는 대신 "이 분석은 8월 이전 정의를 사용했습니다"라고 명확히 말할 수 있습니다. 숫자가 어떤 규칙에 따라 계산되었는지 아는 것, 이 단 하나의 속성이 분석의 신뢰성을 확보하는 핵심입니다.

공식뿐만 아니라 제외 기준과 그 이유를 작성하세요

"활성 = 지난 90일 이내 결제된 인보이스"는 절반짜리 정의입니다. 드리프트를 방지하는 나머지 절반은 다음과 같습니다: 체험판 제외 (2025년 가격 변경 전에 숫자를 부풀렸음), 내부 계정 제외 (3월 감사 결과), 시트(seat) 수준이 아닌 계정 수준으로 계산. 이유가 중요한 이유는 매 분기마다 제외 기준을 두고 다시 논쟁하는 것을 막아주기 때문입니다.

모든 정의에 날짜를 기재하고 이전 버전을 보관하세요

정의가 변경되면 효력 발생일과 함께 새 버전을 추가하고, 이전 버전은 대체됨(superseded)으로 표시하여 보관하세요. 이전 정의를 삭제하면 지난 분기의 숫자를 해석할 수 없게 됩니다. 이는 전체 실무에서 가장 가치 있는 습관이자 가장 흔히 누락되는 부분입니다.

소유자를 지정하세요

모든 정의에는 이를 결정하는 사람이 명시되어야 합니다. 관료주의 때문이 아니라, "이것이 여전히 맞습니까?"라는 질문에 답할 대상이 필요하기 때문입니다. 소유자가 없는 정의는 소리 없이 변질되지만, 소유자가 있는 정의는 수정됩니다.

거버넌스가 적용된 레이어를 단일 진실 공급원(source of record)으로 유지하세요

정의를 어디서나 사용할 수 있도록 메모리 레이어를 사용하되, 보고되는 숫자를 실제로 계산하는 것은 시맨틱 레이어나 데이터 웨어하우스 모델로 유지하세요. 두 레이어가 충돌할 때는 거버넌스가 적용된 레이어가 우선하며 메모리 항목이 수정되어야 합니다. 이 계층 구조를 뒤집으면 문서화만 잘 된 틀린 숫자를 얻게 됩니다.

ChatGPT가 지표 정의를 잊어버리는 이유는 정의가 데이터의 속성이 아니라 의사결정이며, 채팅 기반 워크플로우에는 세션 간에 결정을 전달하는 장치가 없기 때문입니다. 대신 모델은 지표 이름이 대개 의미하는 바에 대한 사전 지식을 바탕으로 자신 있게 실행합니다. 이 때문에 실패는 눈에 보이는 오류가 아니라 일치하지 않는 숫자의 형태로 나타납니다.

도구가 읽는 저장소에 정의를 보관하면 가용성 문제가 해결됩니다. 정의, 제외 기준, 소유자, 효력 발생일이 질문과 함께 전달되기 때문입니다. 강제 적용 및 보고용 숫자 계산을 위해서는 시맨틱 레이어를 유지하세요. 이 두 가지를 병행하면 월요일에 설명한 "활성 고객" 버전이 목요일에도 여전히 사용되며, 특정 숫자가 어떤 버전을 사용했는지 증명할 수 있습니다.