ChatGPT가 데이터 스키마를 잊어버리는 이유
분석 샌드박스는 설계상 일회용입니다
Python을 실행하고, DataFrame을 보유하며, 업로드된 CSV를 저장하는 컨테이너의 범위는 세션으로 제한됩니다. 30분 동안 유휴 상태이거나 하루 종일 연속으로 작업하면 컨테이너는 사라집니다. 대화를 닫으면 의도적으로 해체됩니다. 분석가들은 분석 도중 갑작스러운 연결 끊김으로 인해 상당한 작업 내용을 잃었다고 보고하곤 합니다. 이는 무언가 실패해서가 아니라, 환경 자체가 영구적으로 유지되도록 설계되지 않았기 때문입니다.
스키마는 저장되는 것이 아니라 추론됩니다
파일을 업로드하면 모델은 상위 행을 샘플링하여 유형과 의미를 추측합니다. 이는 합리적인 휴리스틱이지만 취약한 기반이기도 합니다. 깨진 인코딩, 잘못 들어간 헤더 행, 숫자처럼 보이는 ID 열, 두 가지 형식이 섞인 날짜 열 등이 문제를 일으킬 수 있습니다. 추론은 매번 새로 발생하므로, 월요일에 읽은 동일한 파일이 화요일에는 약간 다르게 해석될 수 있습니다.
내장 메모리는 열 정의가 아닌 선호도를 저장합니다
ChatGPT의 메모리는 사용자의 역할, 보고 스타일, 상시 지침 같은 것들을 위해 설계되었으며, 이러한 용도에는 유용합니다. 하지만 이는 데이터 사전(data dictionary)이 아닙니다. 40개의 열 정의, 3개의 제외 규칙, 그리고 특정 테이블이 복합 키로 조인되는 이유를 안정적으로 기억하지 못합니다. 이와 관련된 실패 사례로는 ChatGPT가 세션 간에 컨텍스트를 잃어버리는 현상 및 업로드된 파일을 잊어버리는 현상 등이 있습니다.
정의는 데이터 내에 존재한 적이 없습니다
이 부분이 바로 파일의 문제가 아니라 메모리의 문제로 만드는 원인입니다. 어떤 열이 기준인지, 실제 null이 의미하는 바가 무엇인지, 재무팀이 어떤 행을 제외하는지, 지난 분기 수치가 왜 재조정되었는지 등은 CSV 파일에 들어있지 않습니다. 이는 여러분의 머릿속, 위키 페이지, 또는 Slack 스레드에 있습니다. 매 세션마다 이를 다시 입력해야 하며, 매 세션이 끝날 때마다 이 정보는 버려집니다.
분석가들이 시도하는 방법들
다시 업로드하고 다시 설명하기
가장 기본적인 방법입니다. 10분의 시간이 소요되며, 더 교활하게는 분석 품질이 저하됩니다. 네 번째 세션쯤 되면 예외 케이스를 언급하지 않게 되고, 모델은 겉보기에는 맞지만 실제로는 미세하게 틀린 숫자를 조용히 만들어냅니다.
10~15분마다 중간 결과 내보내기
만료되는 샌드박스에 대해 널리 추천되는 임시방편입니다. 상태를 CSV나 Excel로 저장하고, 연결이 끊어지면 다시 업로드하는 방식입니다. 효과는 있지만, 말 그대로 매우 번거롭습니다. 또한 이는 데이터만 보존할 뿐, 추론 과정은 보존하지 못합니다. DataFrame은 되찾을 수 있지만, 그 데이터에 대해 내렸던 6가지 결정 사항은 되찾을 수 없습니다.
모든 대화에 데이터 사전 붙여넣기
더 나은 방법이며, 수동 옵션 중에서는 실제 해결책에 가장 가깝습니다. 문제는 '동기화 어긋남(drift)'입니다. 원본 문서는 문서 파일에 있고, 붙여넣은 내용은 대화창에 있으며, 스키마는 데이터베이스에서 변경됩니다. 한 달 안에 이 세 가지가 서로 불일치하게 되며, 모델이 이 중 어떤 버전을 사용했는지 알려주는 에러 메시지도 나타나지 않습니다.
참조 파일이 포함된 Custom GPT 또는 Project 사용하기
안정적인 데이터셋을 위한 실질적인 개선책입니다. 지침과 참조 파일을 한곳에 모아 팀과 공유할 수 있습니다. 하지만 여전히 수동적이며 사일로(silo)화되어 있습니다. 스키마가 변경될 때 파일이 자동으로 업데이트되지 않으며, ETL 작업을 작성하는 코딩 에이전트나 동일한 숫자로 이사회 요약을 작성하는 어시스턴트는 그 안의 내용을 볼 수 없습니다.
해결책: ChatGPT에 영구적인 데이터 메모리 제공하기
해결책은 지금까지 하나로 묶어 생각했던 두 가지를 분리하는 것입니다. 데이터는 웨어하우스나 파일에 속해야 하며, 정의와 결론은 샌드박스보다 오래 살아남는 메모리에 속해야 합니다. 이것이 바로 MemoryLake가 수행하는 역할입니다. 어떤 대화가 열려 있는지와 관계없이 어시스턴트와 에이전트가 읽을 수 있는 단일 메모리 레이어를 제공합니다.
1단계: API 키 생성하기
키를 생성하고 약 30초 만에 첫 번째 요청을 보낼 수 있습니다.
2단계: 첫 번째 메모리 업로드하기
데이터를 정의하는 문서, 이미지, 파일을 업로드하세요. 데이터 사전, 열의 의미 및 기준 소스, 제외 및 필터링 규칙, 조인 키, 날짜 범위별 알려진 특이사항, 그리고 이미 검증된 분석 결과 등을 포함할 수 있습니다.
3단계: AI 및 에이전트 연결하기
Claude, Codex, OpenClaw 및 기타 에이전트에게 MCP 또는 API를 통해 해당 메모리에 대한 액세스 권한을 부여하세요. ChatGPT의 경우, API를 통해 관련 정의를 검색하여 대화나 분석 워크플로우에 주입할 수 있습니다. 이를 통해 모델은 첫 5개 행에서 추측하는 대신 사용자가 정의한 의미 체계를 가지고 작업을 시작할 수 있습니다.
실제 업무에서 달라지는 점
스스로 얼마나 반복하고 있는지 계산해 보세요. 스키마와 규칙을 설명하는 데 8분이 걸리고 일주일에 4번 분석 세션을 시작한다면, 분석가 한 명당 매주 30분 이상을 순수하게 똑같은 말을 반복하는 데 쓰는 셈입니다. 붙여넣는 사전이 1,500 토큰이고 팀 전체에서 하루에 25번 전송된다면, 변하지 않은 사실을 다시 확인하는 데 매달 약 110만 토큰을 소비하는 것입니다.
진짜 값비싼 실패는 토큰 낭비가 아닙니다. 아무도 제외 규칙을 다시 언급하지 않아 환불 데이터가 조용히 포함되어 버린 분석, 레거시 금액 열을 사용한 보고서, 그리고 재조정된 수치가 다시 재조정되는 상황들입니다. 영구적인 정의를 사용하면 이러한 실패 확률이 크게 줄어듭니다. 규칙이 누군가 기억해서 다시 입력하는 것에 의존하지 않기 때문입니다. 또한 AI에게 컨텍스트를 반복해서 설명하는 일이 더 이상 업무 기술서의 일부가 되지 않도록 막아줍니다.
데이터 메모리 활용을 위한 모범 사례
행 데이터가 아닌 사전과 규칙을 저장하세요
메모리는 의미 체계(semantics)를 위한 것입니다. 각 필드가 의미하는 바, 어떤 소스가 우선권을 갖는지, 무엇을 제외할지, 기간을 어떻게 정의할지 등입니다. 데이터 자체는 데이터가 있어야 할 곳에 보관하세요. 그래야 메모리를 정밀하게 검색할 수 있을 만큼 작게 유지하고, 전송 비용을 저렴하게 유지할 수 있습니다.
스키마가 변경되면 정의의 버전을 관리하세요
열 이름이 바뀌거나 규칙이 변경되면 저장된 사실을 교체하고 적용 날짜를 기록해 두세요. "2026-03-01부로 지역 코드 변경됨"과 같은 세부 정보는 전년 대비 비교 분석의 신뢰성을 결정짓는 중요한 요소입니다. 오래된 정의는 정의가 아예 없는 것보다 나쁩니다. 모델이 이를 확신을 가지고 적용하기 때문입니다.
숫자와 함께 검증된 분석 결과를 기록하세요
분석 결과가 확인되고 승인되면, 그 결론과 도출 과정을 저장해 두세요. 이를 통해 동일한 질문에 대해 처음부터 다시 답변을 구하는 일을 방지할 수 있으며, 다음 세션에서 새로운 숫자가 타당한지 판단할 수 있는 기준점을 제공합니다. 단순한 검색(Retrieval)만으로는 이를 해결할 수 없습니다. RAG가 메모리가 아닌 이유를 참고하세요.
결론
ChatGPT가 데이터 스키마를 잊어버리는 이유는 스키마를 담고 있던 환경이 일회용이었고 의미 체계가 어디에도 저장되지 않았기 때문입니다. 샌드박스는 약 30분의 유휴 시간 또는 24시간 사용 후 만료되며, 컨테이너는 대화와 함께 소멸하고, 다시 시작할 때마다 첫 몇 행을 기준으로 스키마를 새로 추론합니다.
15분마다 중간 파일을 내보내는 것은 데이터를 보호할 뿐, 정의를 보호하지는 못합니다. 사전, 제외 규칙, 검증된 분석 결과를 도구가 읽을 수 있는 메모리 레이어에 두세요. 그러면 다음 세션이 시작될 때 amount_net이 기준 열이고 환불은 제외된다는 점을 이미 인지한 상태로 시작할 수 있습니다. 이는 데이터를 분석하는 어시스턴트와 데이터를 추측하는 어시스턴트의 차이입니다.