Dots 사용을 거부하는 이유: 불충분한 가시성과 개인 정보 및 정보 분리 통제 문제

요약하자면(TL;DR): 검사 가능하고 선택적으로 삭제 가능한 메모리 기능과 도메인 간 공유에 대한 명시적인 통제가 없다면 Dots를 사용하지 않을 것입니다. 또한, 시간이 지남에 따라 프라이버시 위험을 평가하고 품질을 관리하기 위한 아키텍처 투명성도 필요합니다. 그때까지는 확실히 포기입니다.
https://preview.redd.it/5h1hcsv4eeth1.png?width=2399&format=png&auto=webp&s=dd20f21f614a8c03111c9f740665997345bf793a

항상 켜져 있는 에이전트(agent)는 명확하게 정의된 한 가지 종류의 작업을 수행하고 그것을 위해 사용하는 사람에게는 좋은 아이디어처럼 들립니다. 하지만 전문적이고 개인적인 삶에서 다양한 영역에 걸쳐 AI를 사용하는 (대부분의) 사용자들은 어떨까요?
누군가가 자신의 정부(mistress)에 대한 생활 조언을 AI에게 말하는 것이 그 사람의 업무 보조 AI가 알아야 할 바는 아닙니다. 법률 상담사 AI, 건강 관리 자문 AI, 데이팅 코치 AI, 치료사 AI, 영양사 AI가 같은 사용자에게 서비스를 제공한다는 이유만으로 자동으로 컨텍스트를 공유해서는 안 됩니다.
하지만 OpenAI는 현재 사용자가 유지하는 한 대화 및 연결된 앱으로부터 정보를 보존할 수 있는 단일 Dots를 제공하며, 개별 메모리를 검사하거나 편집하거나 삭제할 수 있도록 허용하지 않습니다. 이는 사용자 삶의 완전히 다른 부분에 걸쳐 요구하기에는 너무 많은 신뢰입니다.
어떤 중첩(overlap)이 전반적으로 사용자를 더 잘 서비스하는 데 도움이 될 수도 있을까요? 물론입니다. 그렇다면 어떤 정보가 경계를 넘을지, 어떤 목적으로, 그리고 얼마나 오랫동안 넘어갈지를 사용자 스스로 선택하게 해야 합니다.
그렇지 않으면 깊은 개인 정보가 우리가 감사(audit)할 수 없는 영구적인 상태에 들어갈 수 있고, 우리는 그것이 관련 없는 업무에서 재등장하지 않을 것이며 외부 서비스에 도달하지 않을 것이라고 신뢰해야 하는 상황이 됩니다? 강제적인 경계가 없다면, 모든 것을 아는 단일 Dots는 비록 국가 기밀을 다루지 않더라도 발생할 수 있는 프라이버시 악몽처럼 들립니다.
그리고 네, ChatGPT에도

또한, 프라이버시와 사이버 보안은 초기 인터넷 시절에는 부가적인 기능(bolt-on)에 불과했지만, 이제는 진지한 앱에서는 필수 요소(first-class citizens)가 되었으며, 처음부터 보안이 내장되어야 합니다. 권한은 기본적으로 거부되어야 하며 명확한 사용자 통제가 이루어져야 합니다. 사용자의 삶의 한 부분에 대한 접근 권한이 다른 모든 부분을 영구적으로 사용할 수 있는 허가로 조용히 변해서는 안 됩니다. 좁고 역할별(role-specific) 권한, 기본 만료 기한 및 쉬운 취소 기능은 어떨까요? 공격 표면적(attack surface), 폭발 반경(blast radius), 불필요한 정보 공유를 최소화하는 것은 어떻게 되었나요? 내부 액션 확인이 애초에 관련 없는 작업이 민감한 정보를 받는 것을 막는 것과는 다릅니다.
(이 중 일부는 멋지하게 들리는 사이버 보안 용어들이지만, 은행 앱부터 클라우드 생산성 스위트까지, AI 이전 웹 앱에서는 매우 표준적인 개념들입니다.)

또한 중요한 것은 우리가 아키텍처 자체를 이해할 수 있게 하는 것입니다. 영구 노트(persistent notes), 선택된 컨텍스트(selected context), 위임(delegation)에 대한 문서는 있지만, 여전히 충분히 명확한 엔드투엔드 그림을 갖추지 못했습니다. 구성 요소들은 어디에서 실행되나요? LLM은 어디에 있고, 하네스(harness)는 무엇을 하며, 영구 상태(persistent state)는 어디에 저장되나요? 각 추론(inference)에는 무엇이 입력되나요? 누가 또는 무엇이 결정하나요? 압축 정책(compaction policy)은 무엇인가요?
제가 이 도구를 1년 동안 사용한 후에는 어떻게 되나요?
컨텍스트 크기는 예전에는 시간이 지남에 따라 성능 저하를 의미했고, '중간에서 손실됨(Lost in the Middle)' 현상은 정보가 컨텍스트에 존재해도 신뢰성 있게 사용되지 않을 수 있음을 보여주었습니다. 압축과 핸드오프는 현대 에이전트에서 이를 해결하려고 하지만 또 다른 문제를 야기합니다: 정보 손실입니다.
그럼에도 불구하고, Codex가 이것을 어떻게 처리하는지(그리고 일반적인 에이전트 하네스가 어떻게 작동하는지에 대한) 충분한 공개 문서를 통해 저는 이들을 연구할 수 있었습니다(종종 GPT의 도움을 받아). 왜냐하면 이는 제가 일하는 방식을 바꾸기 때문입니다. 언제 분기하거나 새로 시작해야 하는지, 다중 에이전트 위임을 어떻게 구성해야 하는지, 동일한 프로젝트 디렉터리를 대상으로 언제 재시작해야 하는지, 그리고 보존된 원래 컨텍스트와 요약본을 어떻게 비교하여 확인할 수 있는지 등이요.

Voice 역시 좋은 예시입니다. GPT-Live가 실시간 대화와 백엔드 작업을 분리한다는 것을 알면, 즉각적인 응답과 나중에 도착하는 분석을 구분하는 데 도움이 됩니다. 시스템을 이해하면, 손실이 발생하는 핸드오프(handoff) 과정으로 인해 관리되는 기대치를 가지고 프론트 LLM의 피상성에 실망하지 않고 백엔드 모델의 추론에서 지능이 나오기를 기다릴 수 있습니다.
하지만 지금까지 Dots가 실제로 어떤 형태의 하네스(harness) 및 영속성 아키텍처를 갖는지에 대해서는 거의 찾아볼 수 없었습니다.
Dots에 대한 정보가 더 없으면, 사용자 측 QA(Quality Assurance)가 어떻게 보이는지, 그리고 실패 모드(failure modes)가 무엇인지 전혀 알 수 없습니다. Dots로부터 지속적인 품질을 얻으려면, 신중하게 구성된 컨텍스트를 가지고 작동하는 프론티어 추론 모델과 비교할 만한 동등한 이해가 필요합니다.
LLM은 폐쇄적일 수 있지만, 제가 Dots에 탑승하는 것에 편안함을 느끼기 전에, 문서화된 배포(deployment), 데이터 흐름(data-flow), 영속성 아키텍처; 도메인 간의 강제 가능한 경계(enforceable boundaries); 검사 가능하고 선택적으로 제어 가능한 메모리; 그리고 필수 정보를 잃지 않으면서 장기간 실행되는 컨텍스트를 관리하는 방법에 대한 지침이 필요합니다.
그렇게 되면, 제가 그것이 어디에 속하며 어떻게 잘 사용할 수 있는지 평가할 수 있을 것입니다. 그때까지는 새로운 기술을 살펴보는 것을 좋아하더라도, 저에게는 어렵습니다(hard pass).
면책 조항: 이 게시물은 제가 작성한 초안과 GPT-6-Astra (Pro) 및 저와 여러 번의 반복적인 초안 작성을 사용하여 작성되었으며, 최종 초안은 제가 편집하고 승인했습니다.
cc: u/tibo-openai
제출자 /u/curiousinquirer007 to r/OpenAI
[링크] [댓글]