TL;DR

• 주간 태스크 점검(Task Inventory)을 매주 계속하더라도, 이전과의 '변화점'만 알고 싶은 상황에서는 리스트 전체를 다시 읽게 하는 것만으로는 효율이 낮다. 이전 점검 결과를 외부에 저장하고, 이번 분량과 함께 전달하여 '집합 차(Set Difference)'를 answer 하도록 운용 방식을 전환했다.
• 차분 추출은 본질적으로 집합 연산(이번 주에 있고 지난주에는 없는 것 · 지난주에 있고 이번 주에는 없는 것)이지만, 요소의 일치 판정을 어휘 일치에 맡기면 표현만 다를 뿐인 동일 태스크를 모두 '신규'로 오검출한다.
• LLM 자체는 세션을 넘나드는 상태를 가지지 않는다 (Stateless). 차분 비교를 성립시키려면, 인간 측에서 '이전 상태'를 텍스트로서 외부화하여 매번 프롬프트에 명시적으로 포함할 필요가 있다.
• '이번 주 리스트에서 사라졌다'는 검출 결과는 어디까지나 입력 텍스트상의 부재일 뿐이며, 태스크가 실제 세계에서 완료되었음을 증명하는 것은 아니다. 모델은 외부의 실제 상태를 검증할 수단이 없으므로, 소멸 = 완료 여부는 인간 측의 확인이 필수적이다.

배경

이전 기사에서는 주간에 여러 개 쌓인 회의 메모를 AI로 정리하여 점검하는 운용 방식을 소개했다. 이 운용 자체는 안정적으로 돌아가게 되었지만, 계속하다 보니 다른 과제가 나타났다. 점검 리스트는 매주 만들 수 있지만, '지난주부터 무엇이 변했는가'를 알기 위해서는 결국 리스트 전체를 인간이 대조하며 읽어야 했고, 점검 자동화의 효과가 절반은 사라진 상태였다.

그래서 점검 결과를 그때마다 텍스트로 저장하고, 다음 주에는 '지난주의 결과'와 '이번 주의 결과' 두 가지를 프롬프트에 포함하여 차분(늘어난 항목 · 사라진 항목)만을 answer 하도록 하는 공정을 추가했다. 이 기사에서는 해당 운용을 안정화하기까지 부딪혔던 3가지 포인트를 원리부터 기술한다.

원리 1: 차분은 집합 연산이며, 요소의 일치 판정이 모든 기점이 된다

차분 추출은 형식적으로 다음 두 가지 집합 연산으로 환원할 수 있다.

• 이번 주의 태스크 집합 \ 지난주의 태스크 집합 = 신규 태스크
• 지난주의 태스크 집합 \ 이번 주의 태스크 집합 = 사라진 태스크

이 연산 자체는 단순하지만, 제대로 기능하는지 여부는 '두 요소가 동일한 태스크를 가리키고 있는가'라는 판정 기준에 완전히 의존한다.

다음은 지난주와 이번 주의 태스크 점검 결과입니다.
[지난주]
(지난주 텍스트를 붙여넣기)
...

'동일하다고 간주한다'는 문구를 생략하고 테스트해 본 결과, 'A사 견적서 송부'(지난주)와 'A사 견적서 보낼 것'(이번 주)을 별개의 태스크로 취급하여 둘 다 '신규 태스크' 쪽에 계상되었다. 이는 이전 기사에서 다루었던 복수 문서 내의 중복 통합과 같은 현상으로, 판정 기준을 명시하지 않는 한 모델은 어휘적 일치(lexical equivalence)에 가깝게 해석한다. 다른 점은, 이전에는 '하나의 입력 내에서의 태스크 통합'이었던 반면, 이번에는 '두 개의 독립된 스냅샷 간의 요소 대응'이며, 집합 차라는 연산 형태를 취하는 만큼 일치 판정의 오류가 그대로 신규/소멸의 오판정으로 직결되기 쉽다는 점이다.

원리 2: LLM은 스테이트리스(Stateless)이며, 차분 비교에는 이전 상태의 외부화가 필요하다

통상적인 채팅 세션에서 모델은 이번 입력(이번 주의 점검 결과)만을 보고 있으며, 지난주 세션에서 무엇을 출력했는지를 내부적으로 기억하지 않는다. 대화 이력이 이어지고 있다면 문맥으로서 참조할 수 있지만, 다음 주의 별도 세션에서는 당연히 그 이력이 존재하지 않는다.

따라서 차분 비교를 기능하게 하려면, 이전 출력을 인간 측이 텍스트 파일 등에 저장하고 매번 프롬프트에 명시적으로 포함하는 '상태의 외부화'가 필수적이다. 이는 소프트웨어 설계에서의 '스테이트리스(Stateless)한 서비스에 대해 호출 측이 상태를 전달하는' 설계와 같은 구조로, 모델 스스로에게 지속적인 기억을 기대하는 것이 아니라 비교에 필요한 상태를 매번 프롬프트 측에서 완결시켜 두어야 한다. 이번에는 날짜만 적힌 파일명(0804.txt 등)으로도 충분했지만, 운용이 장기화될수록 '이전 상태를 어디에 · 어떤 형식으로 저장할 것인가' 자체가 설계 대상이 된다.

원리 3: '사라졌다'는 입력으로부터의 부재 검출이며, 완료의 검증이 아니다

차분 추출에서 '지난주에는 있었으나 이번 주에는 없어진 태스크'로 꼽힌 항목 중, 실제로 1건을 본인에게 확인해 본 결과 완료된 것이 아니라 단순히 본인이 이번 주의 메모에 적는 것을 누락했을 뿐인 태스크였다.

모델이 수행하고 있는 것은 어디까지나 "이번 주의 텍스트 안에 해당 태스크를 가리키는 표현이 보이지 않는다"라는 입력 내의 부재(absence)를 탐지하는 것일 뿐이며, 해당 태스크가 실제 세계에서 정말로 완료되었는지 검증할 수단(담당자 확인, 진척 관리 툴 접근 등)을 모델은 가지고 있지 않다. "사라짐 = 완료"라는 해석은 인간 측이 개입시킨 암묵적인 가정일 뿐, 모델의 출력이 보증하는 사실이 아니다. 이러한 종류의 Ground Truth (실제 정답)에 접근할 수 없는 태스크에서는 모델의 출력을 "가설의 압축"으로 취급하고, 최종 확인은 인간이 담당하도록 설계할 필요가 있다.

효과가 없었던 것

• "동일한 것으로 간주한다"는 지시를 생략한 차분 추출: 표현의 변이(variation)가 있는 동일 태스크를 신규 태스크로 오탐지했다. 지난 기사의 중복 통합과 동일한 원리(표층 일치에 대한 편향)가 집합 차분 연산에서도 동일하게 작용한다.
• "사라진 태스크 = 완료"라는 전제하의 운용: 확인 절차 없이 주간 보고서로 전기(transcription)했을 때, 기록 누락으로 인한 부재를 완료로 잘못 처리한 사례가 발생했다. 모델의 출력을 검증 수단의 대용으로 사용할 수는 없다.

요약

주간 차분 추출은 (1) 일치 판정을 어휘 일치가 아닌 의미 일치로 명시할 것, (2) 스테이트리스 (Stateless) 모델에 대해 이전 상태를 매번 외부화하여 전달할 것, (3) "사라짐"이라는 탐지 결과를 완료의 증거로 취급하지 않고 인간이 최종 확인할 것, 이 세 가지 점을 운용에 포함해야 비로소 안정화된다. 특히 (2)와 (3)은 단일 세션 내의 요약이나 통합에서는 의식할 필요가 없었던, 세션을 넘나드는 운용에 특유한 제약이다.

Discussion