AI 컴패니언의 메모리는 수정 가능해야 할까? 프로젝트 세부 정보를 위한 실용적인 수정 플로우

일상적인 프로젝트 메모리에 수정 제어 기능이 필요한 이유

메모리는 선호도나 프로젝트 맥락을 이어받아 사용자가 이를 반복해서 말할 필요가 없게 함으로써 지속적인 대화를 더욱 유용하게 만들어 줍니다. 현재 제품 문서들에서는 메모리를 개인화의 원천으로 설명하는 동시에, 모든 세부 사항을 기억하지 못하거나 세부 사항을 잘못 파악할 수 있음을 인정하고 있습니다. OpenAI의 메모리 가이드에서는 기억된 정보가 서로 다른 출처에서 올 수 있으며 사용할 수 있는 제어 방식이 다양하다고 설명합니다. Google의 Gemini 메모리 가이드 역시 메모리가 프로젝트 제안에 정보를 제공할 수 있다고 밝히며, 사용자가 채팅 내에서 Gemini를 수정하도록 안내합니다.

시스템이 과거의 가능성을 확정된 계획으로 취급하면 작은 오류가 반복적인 골칫거리가 될 수 있습니다. 주말 목공 프로젝트에 대해 논의하는 사람을 상상해 보십시오. 삼나무 사용을 고려하다가 결국 자작나무를 선택했습니다. 이후 컴패니언이 그 선택이 최종적인 것인 양 삼나무 마감재를 제안한다면, 문제는 시스템이 대화를 기억했다는 사실 자체가 아닙니다. 사용자에게 기억된 내용을 확인하고, 수정하고, 그 수정 사항이 적용되는지 확인할 수 있는 방법이 필요하다는 점이 문제입니다.

이는 디자인 권장 사항이며, 모든 대화형 제품이 이미 동일한 제어 기능을 제공하고 있다는 주장은 아닙니다. Microsoft의 인간-AI 상호작용 가이드라인에서는 효율적인 수정, 시스템 동작에 대한 설명, 사용자 작업의 결과 전달을 별도의 디자인 고려 사항으로 꼽습니다. 메모리에 적용해 보면, 이러한 원칙은 수정이 간단해야 하며 그 실질적인 효과를 쉽게 검증할 수 있어야 함을 시사합니다. Microsoft Research의 인간-AI 상호작용 가이드라인

사용자가 점검할 수 있어야 하는 내용

유용한 메모리 뷰는 개별적인 내용을 일상적인 언어로 제시해야 합니다. 예를 들어 "책상 정리함의 경우 자작나무를 선택하셨습니다"라거나 "동네 간판에 관한 사진 시리즈를 고려 중이십니다"와 같은 형태입니다. 잠정적인 언어를 확실한 것으로 변환하는 일은 피해야 합니다. 기반이 되는 대화를 보여줄 수 있는 경우, 출처 링크나 짧은 맥락 미리보기를 제공하면 요약이 정확한지 사용자가 판단하는 데 도움이 될 수 있습니다. 또한 메모리 뷰는 이것이 전체 기록이 아니라 선별적인 요약일 수 있음을 분명히 해야 합니다. OpenAI의 문서는 메모리 요약이 상위 수준의 요약이며 모든 세부 정보나 출처를 보여주지 않을 수 있다고 명시적으로 설명합니다.

각 항목에 대해 사용자가 이해할 수 있는 방식으로 상태를 표시하십시오. 저장되어 향후 개인화에 사용 가능함, 확인 대기 중, 수정됨, 활성 사용에서 제거됨 등이 있습니다. 이러한 레이블은 제안된 인터페이스 패턴입니다. 그 바탕에 깔린 원칙은 시스템이 행동한 이유를 설명하고 사용자의 작업이 향후 동작에 어떤 영향을 미치는지 전달하라는 Microsoft의 지침에 의해 뒷받침됩니다. 이는 내부 모델 메커니즘을 노출할 것을 요구하지 않습니다. 사용자가 "무엇을 기억했는가, 그리고 내가 그것을 수정하면 무엇이 바뀌는가?"라는 질문에 답할 수 있을 정도의 정보만을 필요로 합니다.

5단계 수정 플로우

실용적인 수정 플로우는 오류가 나타나는 지점에서 시작될 수 있습니다. 어시스턴트가 "갤러리 출품이 다음 달이므로…"라고 말한다면, 사용자는 그 원인이 된 메모리를 열거나 응답 옆에서 수정 작업을 선택할 수 있어야 합니다. 메모리 설명은 어시스턴트가 출력 뒤에 있는 모든 이유에 완벽하게 접근할 수 있음을 암시하지 않으면서 관련 주장 내용을 식별해야 합니다. 현재 OpenAI의 메모리 제어 기능은 개인화에 기여한 출처를 표시할 수 있지만, 출처가 모든 요인을 보여주지 못할 수도 있음을 명시합니다. 메모리 출처 및 수정에 관한 OpenAI 가이드

그런 다음 사용자는 가장 작은 유용한 작업을 선택합니다. 내용을 편집하거나, 삭제하거나, 불확실한 것으로 표시하는 것입니다. 편집을 통해 "시리즈를 갤러리에 출품함"을 "시리즈 출품 여부를 고려 중임"으로 바꿀 수 있습니다. 세부 정보를 더 이상 전혀 원하지 않는 경우에는 삭제가 적절합니다. 불확실성 표시는 잠정적인 생각을 확정된 약속으로 격상시키지 않으면서 유용한 맥락을 보존할 수 있습니다. 불확실성 옵션은 디자인 제안이며, 해당 제품에서 검증되지 않은 한 특정 제품의 기능으로 제시되어서는 안 됩니다.

저장하기 전에 정확히 수정된 문구를 보여주고, 수정으로 인해 의미가 바뀌거나 이후의 제안을 크게 바꿀 수 있는 경우에는 확인을 요청하십시오. 사소한 오타 수정에는 별도의 확인 단계가 필요하지 않을 수 있지만, 확정된 계획을 열린 가능성으로 대체하는 작업에는 확인이 필요할 수 있습니다. 이러한 구분은 수정 및 명확화 지침에서 도출된 추론입니다. Microsoft는 수정을 쉽게 만들고, 시스템이 사용자의 목표에 대해 불확실할 때 사용자를 참여시킬 것을 권장합니다. 확인 단계는 사용자의 의도된 의미를 보호해야 하며, 일상적인 모든 편집에 번거로움을 더해서는 안 됩니다.

확인 후에는 다음과 같은 명확한 결과를 보여줍니다. "업데이트되었습니다. 향후 프로젝트 대화에서는 갤러리 출품을 미정으로 처리하겠습니다." 사용자가 항목을 삭제하면 활성 메모리에서 제거되었음을 알리고 제품의 실제 적용 범위를 명확히 하십시오. 완전히 사라진 것이 확실하지 않다면 모든 흔적이 사라졌다고 말하지 마십시오. 기존 시스템들은 정확성이 왜 중요한지 잘 보여줍니다. OpenAI는 저장된 메모리와 원본 채팅이 별도로 저장될 수 있다고 설명하며, Gemini 가이드에서는 기억된 세부 정보의 수정을 채팅 내에서 할 수 있고 관련 채팅을 삭제하더라도 개인화에 반영되기까지 약간의 시간이 걸릴 수 있다고 말합니다. 이러한 제품별 동작을 보편적인 삭제 약속으로 일반화해서는 안 됩니다. OpenAI 메모리 가이드 및 Gemini 메모리 가이드

마지막으로, 사용자가 자연스러운 후속 대화를 통해 변경 사항을 테스트할 수 있도록 하십시오. 사용자는 정리함의 마감 아이디어를 물어볼 수 있습니다. 어시스턴트가 자작나무를 사용한다면 사용자는 수정 사항이 재사용에 영향을 미쳤다는 구체적인 신호를 얻게 됩니다. 만약 삼나무를 다시 언급한다면 해당 메모리 항목으로 돌아가는 경로나 불일치를 신고할 수 있는 방법을 제공하십시오. 중요한 디자인 선택은 한 번 성공적인 응답을 했다고 해서 시스템이 다시는 같은 실수를 저지르지 않을 것이라는 보장을 피하면서, 재사용을 관찰 가능하게 만드는 것입니다.

편집, 삭제, 확인을 수행해야 하는 시점

기억된 아이디어는 여전히 유용하지만 문구나 세부 정보가 틀린 경우 편집을 사용하십시오. 예를 들어 "선반 너비는 80cm임"을 "선반 너비는 90cm임"으로 수정하는 경우입니다. 해당 항목이 더 이상 향후 답변을 안내해서는 안 될 때 삭제를 사용하십시오. 예를 들어 포기한 프로젝트 선호 사항이 이에 해당합니다. 제안된 메모리가 모호하거나 변경으로 인해 탐색적 의견이 결정으로 바뀔 수 있는 경우 확인을 사용하십시오. 명확한 인터페이스라면 "그 말은 하지 마"를 "메모리 삭제"와 동일하게 취급하지 않고 이러한 작업들을 명확히 구분해야 합니다. OpenAI의 문서도 비슷한 구분을 두고 있습니다. 시스템에 무언가를 언급하지 말라고 요청하면 개인화 동작은 변경되지만 기본 출처 자체가 삭제되지는 않습니다.

인터페이스는 상황에 따라 가치가 달라지는 세부 정보에 대해 "확실하지 않음" 또는 "다음에 다시 묻기" 옵션을 제공할 수도 있습니다. 예를 들어, 어떤 사람은 평소에는 짧은 캡션을 선호하지만 특정 포트폴리오 페이지에는 더 긴 설명을 원할 수 있습니다. 이는 유연성을 유지하기 위해 제안된 방식이며, 검증된 기능에 대한 주장이 아닙니다. 핵심 질문은 메모리가 안정적인 선호도, 일시적인 선택, 아니면 열어두어야 할 가능성 중 무엇을 나타내고 있는가입니다.

차분하고 사용하기 쉬운 상호작용을 위한 디자인

수정 제어 기능을 메모리나 그것이 영향을 미치는 응답에 가깝게 배치하십시오. "편집", "삭제", "확인"과 같은 익숙한 단어를 사용하고, 일상적인 사실 오류를 바로잡기 위해 사용자가 특별한 프롬프트를 작성하게 만들지 마십시오. Microsoft의 지침은 효율적인 수정과 세분화된 피드백을 명시적으로 요구합니다. Apple의 최신 생성형 AI 디자인 가이드라인 역시 미세 조정이나 실행 취소를 쉽게 만들고 사용자의 조정이 적용되었을 때 신호를 보낼 것을 권장합니다. 생성형 AI를 위한 Apple Human Interface Guidelines

결과에 영향을 미치는 중요한 편집의 경우, 간결한 전후 비교 뷰를 제공하십시오. 상충되는 버전을 조용히 병합하거나 사용자의 수정을 추론된 선호도로 대체하지 마십시오. 사용자가 "이 정리함에는 자작나무를 골랐지만 야외 프로젝트에는 여전히 삼나무가 좋아요"라고 말한다면, 이를 일반적인 목재 선호도로 단순화하지 말고 두 주장의 범위를 모두 보존하십시오. 이는 디자인적 추론입니다. Microsoft는 불확실할 때 서비스의 범위를 한정할 것을 권장하며, 신중한 업데이트에 관한 지침은 시간이 지남에 따라 발생할 수 있는 혼란스러운 변화를 방지하는 것을 지지합니다.

가벼운 변경 이력은 사용자가 실수로 편집한 내용을 복구하는 데 도움이 될 수 있으며, 특히 복원하고 싶을 수 있는 프로젝트 사실 정보의 경우 더욱 그렇습니다. 하지만 이력은 이해하기 쉬워야 하며 사용자의 통제 하에 있어야 합니다. 인터페이스가 실행 취소를 제공하는 경우, 무엇이 복원되는지 그리고 복원된 내용이 다시 활성화되는지 여부를 알리십시오. Apple의 지침은 특히 생성된 결과를 다듬기 위한 유용한 패턴으로 실행 취소와 명확한 피드백을 지목합니다. 이러한 패턴을 메모리 편집에 적용하는 것은 합리적인 확장이지만, 해당 가이드라인이 특정 메모리 이력 기능을 규정한다는 의미는 아닙니다.

플로우가 제대로 작동하는지 확인하는 방법

일상적인 프로젝트 시나리오와 관찰 가능한 작업을 통해 플로우를 평가하십시오. 사용자가 답변에 잘못된 세부 정보가 나타난 후 이를 찾을 수 있습니까? "결정됨"을 "고려 중"으로 변경하고, 업데이트된 문구를 확인하고, 시스템이 다음에 무엇을 사용할지 알아낼 수 있습니까? 폐기된 선택 사항을 제거하면서 그 작업을 어시스턴트에게 한 번 언급하지 말라고 요청하는 것과 혼동하지 않을 수 있습니까? 이는 제안된 디자인을 위한 테스트 질문이며, 보고된 테스트 결과가 아닙니다.

유용한 검토를 통해 사용자가 이러한 작업을 완료하는지, 편집과 삭제의 차이를 이해하는지, 수정된 세부 정보가 이후의 관련 답변에 반영되는지 추적할 수 있습니다. 또한 세부 정보를 찾을 수 없거나, 두 메모리가 충돌하거나, 수정 사항이 아직 반영되지 않았거나, 사용자가 저장 전에 취소하는 등의 실패 경로도 확인해야 합니다. 이러한 경우 인터페이스는 변경 사항을 확인할 수 없을 때 단순히 "수정됨"이라고 말하는 대신 현재 상태를 인정하고 명확한 다음 단계를 제공해야 합니다. 이는 수정을 효율적으로 만들고 작업 결과를 전달하라는 지침을 따르는 것이며, 측정 항목 자체는 권장 사항입니다.

메모리를 수정 가능하게 만들고, 그 수정을 눈에 보이게 하십시오

일상적인 프로젝트 세부 정보는 변경되며 기억된 요약은 불완전하거나 틀릴 수 있으므로 AI 컴패니언 메모리는 편집 가능해야 합니다. 강력한 수정 플로우는 사용자가 특정 내용을 점검하고, 편집하거나 삭제하고, 필요한 경우 의미를 확인하고, 변경 사항이 향후 개인화에 어떻게 영향을 미칠 것으로 예상되는지 확인할 수 있도록 합니다. 이러한 경험은 메모리가 완벽하다거나 한 번의 수정으로 이후의 모든 응답이 정확해질 것이라고 암시하는 것이 아니라, 각 작업에 대해 눈에 보이고 정확한 피드백을 제공함으로써 신뢰를 얻습니다.

이 주제 더 살펴보기