AI 루프의 외부 메모리란? 작업 상태와 근거를 잃지 않는 방법
AI 루프의 외부 메모리란? 작업 상태와 근거를 잃지 않는 방법#
어제 AI와 분기 보고서를 작성하다가 중간에 멈췄다. 오늘 “어제 하던 것 이어서 해 줘”라고 말했을 때 AI가 정확히 이어 가려면 무엇이 필요할까?
보고서 초안의 위치, 사용한 데이터, 이미 확인한 수치, 아직 승인받지 않은 해석이 필요하다. 이러한 정보를 다음 실행에서도 찾도록 저장하는 구조가 외부 메모리다. 그러나 대화 전체를 무작정 저장한다고 좋은 기억이 되지는 않는다. 오래된 가설과 확정된 결정을 섞어 보관하면 오히려 잘못된 업무를 이어 갈 수 있다.
루프 엔지니어링에서 기억은 ‘AI가 나를 알아본다’는 인상을 만들기 위한 기능에 그치지 않는다. 실행이 중단되었을 때 검증된 상태부터 안전하게 다시 시작할 근거다. 어제 계산한 숫자를 다시 계산해야 하는지, 사람의 승인 뒤 어떤 문장을 고쳤는지, 다음 단계가 어디인지 확인하는 데 쓰인다.
기억이 루프의 네 단계에 어떻게 쓰이는가#
| 단계 | 불러오거나 기록할 정보 | 확인할 기준 |
|---|---|---|
| 계획 | 이전 실행의 목표·마지막 성공 단계 | 같은 목표를 이어 가는가 |
| 실행 | 사용할 자료의 위치와 버전 | 지난번 자료가 아직 유효한가 |
| 관찰 | 도구 결과, 수정 내역, 실패 원인 | 실제 작업과 기록이 일치하는가 |
| 검증 | 승인 기록, 미해결 질문, 근거 출처 | 완료 또는 재시작을 결정할 수 있는가 |
고객 문의 답장처럼 한 번에 끝나는 일에도 메모리가 필요할 수 있다. 재시도 시 이미 발송했는지를 기억하지 못하면 고객에게 같은 답장을 두 번 보낼 수 있기 때문이다.
현재 맥락과 외부 메모리는 다르다#
AI가 이번 요청에 답할 때 입력으로 받은 문서와 대화는 현재 컨텍스트다. 컨텍스트 윈도우는 한 번에 처리할 수 있는 입력의 한계를 뜻한다. 일부 서비스는 대화 기록이나 사용자 기억 기능을 제공하지만, 어떤 정보가 실제 다음 요청에 다시 들어오는지는 제품 설정과 사용 방식에 따라 다르다.
외부 메모리는 이와 별도로 파일·데이터베이스·업무 시스템 등에 보관한 정보다. 새로운 작업을 시작할 때 필요한 부분만 검색해 현재 컨텍스트에 넣는다.
비유하면 현재 컨텍스트는 책상 위에 펼친 자료, 외부 메모리는 서랍에 정리해 둔 기록이다. 서랍에 문서가 있다는 사실만으로 AI가 그것을 읽는 것은 아니다. 찾는 과정과 불러오는 과정을 연결해야 한다.
무엇을 기억해야 하는가: 네 종류의 정보#
| 정보 | 예시 | 저장 목적 | 주의점 |
|---|---|---|---|
| 작업 상태 | 보고서 3절 작성 완료, 수치 검토 대기 | 다음 실행에서 재개 | ‘70% 완료’만 남기면 실제 위치를 알기 어려움 |
| 근거 | 사용한 파일, 문서 위치, 수집일 | 사실·수치 재검증 | 출처 변경과 최신성 확인 |
| 결정 | 사람이 승인한 문장과 이유 | 같은 논의를 다시 하지 않기 | 가설과 승인을 구분 |
| 선호 | 간결한 보고서 형식 | 반복 출력에 적용 | 언제든 수정·삭제할 수 있어야 함 |
여기에 개인정보와 기밀 정보의 보존 규칙을 붙인다. 사용자 이름이나 고객 사건 내용을 ‘개인화에 도움이 된다’는 이유만으로 모두 영구 저장할 필요는 없다.
‘어제 하던 보고서’를 다시 여는 과정#
학습용 가상 사례를 보자. 어제의 작업이 중간에 멈췄다면 다음 기록이 필요하다.
작업 ID: q3-sales-report
상태: 수치 검증 대기
초안: work/q3-report/draft-v2.md
원본: input/q3-sales.csv
확인한 내용: 월별 합계는 원본과 일치
남은 내용: 환불 반영 기준 확인, 결론 작성
마지막 결정: 담당자가 전월 비교를 승인
다음 담당: 영업팀 담당자에게 환불 기준 확인다음 날 AI는 이 기록과 실제 초안 파일을 함께 읽는다. 기록에 ‘초안이 있다’고 적혀 있지만 파일이 사라졌다면 작업을 그대로 진행해서는 안 된다. 메모리는 실행 상태를 안내하고, 파일과 원자료는 내용을 검증하는 근거다.
저장된 사실, 가설, 선호를 섞지 말자#
“이번 분기 매출이 감소했다”는 계산 근거가 있으면 확인된 사실일 수 있다. “경쟁사가 할인했기 때문”은 근거가 없다면 가설이다. “그래프는 파란색을 선호한다”는 사용자의 취향이다.
이 세 문장을 같은 ‘기억’으로 저장해 다음 보고서에 가져오면, 가설이 사실로 굳어질 수 있다. 저장할 때 유형, 출처, 작성 시각, 유효 기간, 승인자 같은 항목을 구분한다.
type: hypothesis
content: 매출 감소의 한 원인은 경쟁사의 할인일 수 있음
source: 작성자의 검토 메모
verified: false
next_action: 가격 자료로 확인이 기록은 ‘다음 번 보고서에도 그대로 쓸 사실’이 아니라 ‘검증할 항목’임을 알려 준다.
파일·데이터베이스·벡터 검색 중 무엇이 필요한가#
원고에는 파일 메모리, 요약 메모리, 벡터 데이터베이스가 함께 등장한다. 하나를 무조건 골라야 하는 것은 아니다. 저장 방식과 찾는 방식은 다른 선택이다.
| 방법 | 잘 맞는 정보 | 장점 | 한계 |
|---|---|---|---|
| 작업 메모 파일 | 한 프로젝트의 현재 상태 | 사람이 쉽게 읽고 수정 | 프로젝트가 많아지면 찾기 어려움 |
| 표·관계형 DB | 작업 ID, 상태, 승인 기록 | 구조화된 조건 검색 | 자유로운 문장 검색에 추가 설계 필요 |
| 키워드 검색 | 정책명, 주문번호, 문서 제목 | 정확한 단어 찾기에 유리 | 다른 표현을 찾지 못할 수 있음 |
| 벡터 검색 | 비슷한 주제의 긴 문서 | 의미상 가까운 내용을 찾음 | 유사하다고 정확하거나 최신이라는 뜻은 아님 |
| 하이브리드 검색 | 키워드와 의미가 모두 중요 | 번호·고유명사와 문맥 함께 찾기 | 설계·운영 복잡도 증가 |
벡터 데이터베이스가 곧 기억 자체는 아니다. 문장을 숫자 표현으로 저장해 유사한 항목을 찾는 방식이다. “지난주 결재한 환불 기준”을 묻는다면 의미 검색 결과에 오래된 정책이 섞일 수 있으므로 날짜와 권한, 승인 상태를 다시 확인해야 한다.
벡터 검색을 비전공자 눈높이로 설명하면#
서랍 속 문서를 문서 제목으로만 찾는다면 제목을 정확히 알아야 한다. 의미 검색은 “지난번 고객 배송 지연 대응 기준”처럼 비슷한 뜻을 가진 문장을 바탕으로 후보 문서를 찾는다. 다만 가장 비슷한 문서와 정답인 문서는 다르다. 후보를 찾은 다음 원문을 열어 실제 내용을 대조하는 단계가 필요하다.
컨텍스트를 관리하는 방법#
자료가 많으면 무조건 현재 대화에 넣고 싶어진다. 그러나 관련 없는 과거 기록까지 넣으면 비용이 늘고, 오래된 정보가 현재 판단에 끼어든다. 컨텍스트 관리의 목표는 ‘가능한 많이 넣기’가 아니라 현재 일에 필요한 근거를 빠짐없이 선택하기다.
요약: 진행 상황을 압축한다#
장시간 보고서 작업을 진행한다면 다음 항목을 요약해 저장한다.
- 확정된 목표와 제약
- 마지막으로 검증한 결과
- 수정해야 할 파일과 위치
- 아직 확인되지 않은 질문
- 다음 단계의 실행 조건
“지금까지 대화를 세 문장으로 요약해 줘”만 요청하면 수치나 승인 조건이 빠질 수 있다. 구조화된 재개 메모를 만드는 편이 안전하다.
청킹: 긴 문서를 부분으로 나눈다#
계약서나 프로젝트 문서를 통째로 넣기 어렵다면 단락이나 절 단위로 나누어 필요한 부분을 찾는다. 하지만 조항 3의 예외가 조항 4에 있다면 조항 3만 읽고 답하면 틀릴 수 있다. 문서의 위치 정보와 앞뒤 문맥을 함께 보존한다.
검색 증강: 필요할 때 다시 찾는다#
RAG라고 부르는 방식에서는 질문과 관련된 문서를 검색해 응답의 재료로 사용한다. 내부 정책 답변처럼 외부 근거가 필요한 일에 유용하지만, 검색되었다는 사실이 문서의 정확성과 현행성을 보증하지는 않는다. 답변에 사용한 문서의 날짜와 출처를 표시하고 중요한 결정은 확인한다.
원문의 숫자 규칙은 그대로 적용하지 않는다#
컨텍스트가 80% 차면 무조건 요약한다거나, 100번의 대화 뒤에는 반드시 앞부분을 잊는다는 규칙은 제품과 구성에 따라 성립하지 않는다. 현재 사용 중인 도구의 실제 길이 제한과 대화 관리 방식을 확인하고, 중요한 목표·승인·근거는 요약만 믿지 말고 지속 저장소에도 기록한다.
개인정보와 망각도 설계한다#
‘AI가 사용자를 잘 기억하게 하자’는 목표가 모든 대화를 모으자는 뜻은 아니다. 개인화가 필요한 선호만 저장하고, 고객 자료는 필요한 업무 범위에만 접근한다.
기억마다 다음 질문에 답해야 한다.
- 이 정보를 왜 보관하는가?
- 누가 접근할 수 있는가?
- 무엇을 근거로 사실이라고 표시했는가?
- 언제 다시 확인하거나 삭제할 것인가?
- 사용자가 수정 또는 삭제를 요청하면 어떻게 반영하는가?
비밀번호·인증 토큰은 업무 메모에 넣지 않는다. 비밀값이 필요하다면 적절한 비밀 관리 수단과 도구 권한으로 제공한다. ‘사용자가 피곤하다고 말한 날이 있었으니 앞으로 답변을 짧게 한다’ 같은 추측성 선호도 동의 없이 오래 저장할 이유가 없다.
직접 해보기: 재개 메모 작성#
현재 진행 중인 작은 작업 하나를 고른 뒤 다음 항목을 적는다.
목표:
작업 ID:
현재 단계:
초안 위치:
사용한 원자료와 날짜:
확인 완료한 사실:
검증되지 않은 가설:
사람이 승인한 결정:
다음 실행 전에 필요한 질문:
이 메모를 삭제·갱신할 시점:새 대화에서 이 메모만 읽고도 무엇을 이어서 해야 하는지 설명할 수 있다면 외부 메모리의 기본 구조가 갖춰진 것이다. 네 번째 부품의 핵심은 많이 기억하는 AI보다, 근거를 잃지 않고 잘못된 기억을 수정할 수 있는 업무 기록이다.
다음 글의 분업 구조에서는 여러 작업자가 같은 ‘기억’을 공유해야 한다. 그때는 모든 대화 기록을 넘기지 않고, 검증된 근거와 현재 단계, 전달해야 할 파일 위치만 역할별로 제공한다. 이 범위를 정하는 일도 메모리 설계의 일부다.