대화에서 바로잡은 컬럼 뜻, 테이블 메모로 다음 사람에게 싣기

고객 테이블의 상태 컬럼 STAT_CD 에는 1, 2, 9가 들어 있습니다. 스키마만 봐서는 9가 해지라는 것을 알 수 없어서, 「활성 고객 수」를 물으면 모델은 해지 고객까지 세어 보고서에 올립니다. 한 사람이 대화에서 「9는 해지야」라고 바로잡으면 그 대화의 답은 맞아집니다. 하지만 다음 날 다른 사람이 같은 테이블을 물으면 모델은 같은 숫자를 다시 틀립니다. 정정이 그 대화에만 남기 때문입니다.

테이블 메모는 이런 정정을 모델이 그 테이블이나 컬럼에 적어 두는 공유 기록입니다. 그 테이블을 쓰는 모든 사람의 다음 질문에 함께 실립니다. 메모는 누구의 승인도 거치지 않고 여러 사람의 대화에서 쌓이므로, 정확한 테이블과 컬럼에만 붙이고, 날짜를 단 힌트로만 싣습니다. 이 글은 메모를 어디에 붙이고, 어떤 모양으로 싣고, 틀린 메모를 어떻게 치우는지 다룹니다.

#정정을 사람이나 분석 결과에 붙이면 다음 질문에서 빠진다

테이블 분석은 값 분포와 주석, 조인 관계에서 컬럼의 뜻을 꽤 많이 추정합니다(「컬럼의 뜻은 DDL에 없다, 질문 전에 값을 읽어 둔다」). 그래도 코드 값의 업무상 뜻, 날짜 컬럼이 어느 시간대로 저장됐는지, 어떤 조인이 행을 불리는지처럼 데이터만 봐서는 알 수 없는 사실이 남습니다. 이런 사실은 결국 사람이 대화 중에 알려 줍니다.

정정을 붙일 자리로 먼저 떠오르는 곳은 두 군데입니다.

9가 해지라는 사실은 말한 사람보다 테이블에 속합니다. 그리고 분석이 몇 번을 다시 돌아도 사실은 바뀌지 않습니다. 그래서 메모는 테이블과 컬럼에 붙이되 분석 결과와 따로 저장하고, 모델이 카드를 열 때 붙여서 싣습니다. 조직이 승인한 업무 정의는 용어집이 따로 맡습니다(「부서마다 다른 매출 계산식, 승인된 용어집 정의만 질문 앞에 싣는다」). 메모는 승인 없이 대화에서 바로 쓰이는 현장 기록입니다.

#메모는 스키마까지 정확한 테이블에만 붙는다

메모 하나는 DB 연결, 스키마, 테이블에 붙고, 필요하면 컬럼 하나까지 지정합니다. 컬럼을 지정하지 않으면 테이블 전체에 대한 메모입니다. 메모마다 남긴 사람과 남긴 대화를 함께 저장해서, 나중에 이 메모가 어느 대화에서 왔는지 되짚을 수 있습니다.

모델이 스키마 없이 테이블 이름만 넘기면, 메모 기록 도구는 분석된 테이블 목록에서 같은 이름을 찾아 스키마를 채웁니다. 일치하는 테이블이 없거나 여러 스키마에 같은 이름이 있으면 저장하지 않고 schema.table 꼴로 다시 지정하라고 돌려보냅니다. 카드는 정확한 스키마로 메모를 찾기 때문에, 빈 스키마로 저장된 메모는 어느 카드에서도 보이지 않습니다. 반대로 스키마를 무시하고 찾으면 sales.CUSTOMER 의 메모가 archive.CUSTOMER 카드에 섞입니다.

컬럼도 같은 원칙을 따릅니다. 컬럼은 모델이 인자로 이름을 적었을 때만 붙고, 메모 문장이나 직전 SQL에서 추론하지 않습니다. 추론하면 모델이 컬럼 이름을 적는 수고는 덜지만, 틀린 추론은 메모를 엉뚱한 컬럼 밑에 붙이고 그 오류는 눈에 잘 띄지 않습니다.

메모를 남기고 고치고 지울 권한은 그 테이블을 읽을 권한을 따릅니다. 판정은 테이블 카드를 열 때와 같아서, 볼 수 없는 테이블에는 메모를 남길 수 없습니다. 검색 결과에 메모를 실을 때도 사용자 역할이 허용하는 테이블의 메모만 싣습니다.

#분석을 다시 돌려도 메모는 남는다

메모를 분석 결과와 따로 둔 덕분에 테이블 분석을 몇 번 다시 돌려도 메모는 그대로입니다. 카드는 분석 결과에서 만들고, 메모는 카드를 열 때마다 따로 읽어 붙입니다.

컬럼 이름이 바뀌어도 메모는 사라지지 않습니다. 컬럼을 지정한 메모는 카드의 컬럼 이름과 정확히 같을 때만 그 컬럼 항목 밑에 실립니다. 같은 이름의 컬럼이 카드에 없으면 테이블 단위 메모 칸으로 옮겨 실립니다. 이름이 바뀐 컬럼의 메모가 아무 데도 안 보이는 것보다, 테이블 단위로라도 보이고 모델이 고치는 편이 낫기 때문입니다.

테이블이 원본 DB에서 사라진 경우도 같습니다. 연결 계정의 테이블 목록에서 빠진 테이블은 조회 불가로 표시만 하고, 메모를 포함한 데이터는 지우지 않습니다(「DB가 바뀌면 분석은 낡는다, 바뀐 테이블만 찾아 다시 분석한다」). 지우는 것은 관리자가 정리를 확인할 때뿐이고, 확인 창은 함께 지워질 메모 수를 보여 줍니다. 분석 결과는 다시 분석하면 되살아나지만, 메모는 사람이 대화에서 알려 준 내용이라 다시 만들 수 없습니다.

#메모는 날짜를 단 힌트로 세 경로에 실린다

메모가 모델에게 닿는 경로는 세 가지입니다.

셋째 경로 덕분에 카드에는 없고 메모에만 있는 말로 물어도 그 테이블이 후보에 오릅니다(「테이블을 잘못 고른 SQL도 실행된다, 검색이 후보부터 좁힌다」).

세 경로 모두 메모를 ID, 내용, 날짜 세 칸만 남긴 같은 모양으로 줄여 싣습니다. ID는 모델이 고치거나 지울 메모를 가리키는 데 씁니다.

날짜는 메모의 나이를 보이려고 넣었습니다. 실운영 환경 관측에서 활성 메모의 절반 이상이 「2025-10 기준」 같은 시점 표현이나 절대 날짜를 담고 있었습니다. 날짜가 없으면 모델은 열흘 전 집계와 어제 집계를 가를 수 없습니다. 싣는 날짜는 마지막 갱신일입니다. 생성일을 실으면 방금 고친 메모가 옛 날짜로 보이고, 최근 갱신 순으로 정렬한 순서와도 어긋납니다. 날짜는 사용자의 시간대로 자릅니다. 모델은 사용자의 시간대로 「오늘」과 「어제」를 가르므로, UTC 날짜를 실으면 서울에서 오전 9시 전에 고친 메모가 전날 기록으로 읽힙니다.

도구 설명은 메모를 정답이 아니라 확인해서 쓸 힌트로 정해 둡니다. 메모에 「9는 해지」라고 적혀 있어도 모델은 값 분포나 코드 테이블로 확인할 수 있고, 확인한 결과가 다르면 그 메모를 ID로 지목해 고칩니다.

시스템 프롬프트가 메모를 직접 근거로 쓰는 자리도 있습니다. DB가 시각을 어느 시간대로 저장하는지는 값만 봐서는 알 수 없습니다. 테이블 메모나 DB 설명에 「이 DB의 시각은 UTC로 저장된다」가 있으면, 모델은 쿼리에서 시간대를 바꿔 사용자의 「오늘」에 맞춥니다. 적힌 것이 없으면 사용자의 시간대로 저장됐다고 가정하고, 그렇게 가정했다고 답에 밝힙니다. 메모 한 줄이 「오늘 매출」의 기준 시각을 9시간 바꾸는 셈입니다.

#같은 메모는 하나로 묶고, 테이블당 40개까지 싣는다

메모의 상태는 활성, 보관, 삭제 세 가지이고, 모델에게 실리는 것은 활성 메모뿐입니다.

여러 사람이 같은 정정을 되풀이하면 같은 메모가 여러 개 쌓입니다. 그래서 기록할 때 같은 테이블, 같은 컬럼에 사실상 같은 내용의 활성 메모가 있는지 봅니다. 앞뒤 공백을 지우고 연속 공백을 하나로 줄이고 대소문자를 맞춰 비교해서, 같으면 기존 메모의 갱신 시각만 올립니다. 같은 문장이라도 붙은 컬럼이 다르면 다른 메모입니다.

테이블 하나의 활성 메모는 40개까지입니다. 41번째가 들어오면 가장 오래 갱신되지 않은 메모가 보관으로 넘어가고, 모델은 그 사실을 경고로 받습니다. 보관된 메모는 지워지지 않지만 더는 실리지 않습니다. 같은 문장이 다시 기록되면 그 메모의 갱신 시각이 올라가므로, 여러 대화에서 거듭 나오는 사실일수록 오래 남습니다.

틀린 메모를 치우는 길은 두 가지입니다.

• 모델이 메모 ID를 지목해 내용을 고치거나 지운다. 내용을 고치면 검색용 임베딩도 다시 만든다. 임베딩을 다시 만들지 못하면 예전 벡터를 비운다. 남겨 두면 고치기 전의 틀린 내용으로 검색에 걸린다.
• 관리자가 데이터베이스 화면의 테이블 상세 창, 메모리 탭에서 메모를 보고 지운다. 누가 어떤 메모를 지웠는지는 감사 기록에 남고, 지운 메모는 그 테이블을 쓰는 모든 사람의 다음 답변부터 빠진다.

관리자 경로가 없으면 잘못된 공유 메모를 누군가의 대화에서 모델이 지워 주기를 기다려야 합니다. 감사 기록에는 메모 본문 없이 식별자만 남깁니다.

#무엇을 남길지는 도구 설명이 정하고, 쓰기는 채팅에서만 한다

메모를 언제 남길지는 모델이 판단합니다. 「아니, 9는…」 같은 말이 나오면 저장하는 키워드 규칙은 예측하기 쉽지만, 사람이 정정하는 말투는 끝이 없어서 규칙이 따라가지 못합니다. 대신 메모 기록 도구의 설명이 남길 메모의 조건을 정합니다.

• 컬럼의 뜻이나 값의 범위, 조인 힌트, 데이터 주의 사항처럼 오래 유효한 사실
• 몇 달 뒤 처음 보는 사람이 읽어도 통하는 독립된 문장(이번 대화의 경과나 특정 시점에 묶인 내용은 제외)
• 한 컬럼에 대한 사실이면 그 컬럼에 붙인 메모

사람을 적은 기록은 메모에 남기지 않습니다. 이름, 사번이나 계정 ID, 이메일, 누가 언제 무엇을 했는지, 사람별 순위와 건수는 데이터 속 사람의 정보입니다. 메모는 그 테이블을 쓰는 모든 사람에게 실리므로 이런 내용이 들어가면 다른 사용자의 답에 그대로 보입니다. 사람을 가리키는 컬럼이 있으면 그 컬럼이 무엇을 식별하고 사용자 목록과 어떻게 조인되는지를 남깁니다. 메모를 고칠 때도 같은 조건이 걸립니다.

메모를 남기고 고치고 지우는 도구 세 개는 채팅에서만 씁니다. 무인으로 반복 실행되는 플레이북 노드에는 넣지 않았습니다. 사람이 지켜보지 않는 실행이 공유 지식을 바꾸거나, 재시도 때문에 같은 쓰기를 되풀이하면 안 되기 때문입니다. 플레이북도 메모를 읽기는 합니다.

정확도 평가처럼 매번 같은 조건으로 돌아야 하는 실행에서는 메모 주입과 메모 검색을 함께 끕니다. 메모는 검색 결과에 어떤 테이블이 오르는지까지 바꾸므로, 주입만 끄고 메모 검색을 남겨 두면 같은 질문에도 결과가 달라집니다.

#설계에서 고른 것

메모는 승인 없이 대화에서 바로 쓰입니다. 정정한 사람이 관리자의 등록을 기다리지 않아도 되고, 다음 사람이 같은 실수를 겪지 않습니다. 그 대가로 틀린 메모도 바로 퍼집니다. 이 위험은 메모를 힌트로만 싣고, 날짜와 출처 대화를 함께 남기고, 모델과 관리자 양쪽에 지우는 길을 두는 것으로 받습니다. 정답으로 굳혀야 하는 정의는 승인을 거치는 용어집에 둡니다.

중복은 문자열 정규화로만 가립니다. 뜻이 비슷한 메모를 임베딩으로 합치면 메모 수는 줄지만, 「9는 해지」와 「9는 해지 신청 접수」처럼 조금 다른 사실 하나가 사라집니다. 그래서 표현이 같은 메모만 하나로 묶고, 비슷한 메모가 나란히 남는 쪽을 받아들였습니다.

상한은 테이블당 40개이고, 넘으면 가장 오래 갱신되지 않은 메모를 보관으로 돌립니다. 오래 아무도 다시 기록하지 않은 사실이 밀려나는 대가로, 테이블 하나에 쌓이는 활성 메모의 양이 묶입니다. 카드는 그 가운데 최근 갱신된 20개를 싣습니다. 밀려난 사실이 여전히 중요하면 모델이 경고를 보고 다시 기록할 수 있습니다.

메모의 위치는 모델이 명시한 테이블과 컬럼으로만 정하고, 모호하면 저장하지 않습니다. 모델이 한 번 더 호출해야 하는 경우가 생기지만, 어느 카드에서도 보이지 않거나 다른 스키마의 카드에 섞이는 메모는 생기지 않습니다.

여러 부서가 같은 DB를 묻고, 코드 값의 뜻이나 저장 시간대가 담당자의 머릿속에만 있는 환경이라면 이 구조를 그대로 옮길 수 있습니다. 메모는 분석 결과와 따로 테이블에 붙이고, 날짜를 단 힌트로 싣고, 사람이 직접 지울 길을 함께 둡니다.