내가 “doll”을 만드는 이유: 개인용 AI 연속성 시스템
요약
개인용 AI 환경의 연속성을 보장하기 위한 오픈 소스 시스템 'doll'을 소개합니다. 모델이나 서비스 제공업체가 변경되더라도 사용자의 메모리, 선호도, 대화 기록 등 핵심 상태를 유지하는 것을 목표로 합니다.
핵심 포인트
- 모델은 교체 가능한 추론 엔진이며, 사용자의 상태(state)가 지속 가능한 핵심임
- 특정 모델이나 서비스 제공업체에 대한 종속성(lock-in) 탈피 지향
- 메모리, 선호도, 대화 출처 등 사용자 데이터의 보존 및 마이그레이션 강조
- 로컬 실행만으로는 해결할 수 없는 애플리케이션 단위의 데이터 고립 문제 해결
고성능 AI를 이용할 수 있는 사람들이 이전보다 훨씬 더 많아졌습니다.
하지만 동일한 조건 하에서 이러한 접근성이 계속 유지될 것이라는 보장은 없습니다.
가격이 변동될 수 있습니다. 사용 제한이 더 엄격해질 수 있습니다. 모델이 중단될 수도 있습니다. 계정, 지역 제한, 규제, 제공업체 정책 또는 서비스 종료로 인해 어제까지 잘 작동하던 AI 시스템을 사용할 수 없게 될 수도 있습니다.
이것은 특정 회사를 신뢰해야 하는지 말아야 하는지에 대한 논쟁이 아닙니다.
문제는 현재 개인용 AI 환경의 연속성이 사용자가 통제할 수 없는 조건에 달려 있다는 점입니다.
그것이 바로 제가 오픈 소스 개인용 AI 연속성 시스템인 **"doll"**을 만들기 시작한 이유입니다.
doll은 새로운 파운데이션 모델 (foundation model)이 아닙니다. 또한 Ollama, llama.cpp, Open WebUI 또는 LM Studio와 같은 모델 러너 (model runners)나 인터페이스 (interfaces)를 대체하려는 목적도 아닙니다.
doll의 목적은 모델, 제공업체, 애플리케이션, 런타임 (runtimes), 인터페이스 또는 머신이 변경되거나 사라지더라도 계속 사용할 수 있어야 하는 개인용 AI 환경의 구성 요소들을 보존하는 것입니다.
모델이 지속 가능한 핵심이 되어서는 안 된다
AI 시스템은 종종 모델이 모든 것의 중심인 것처럼 묘사되곤 합니다.
하지만 모델 자체가 반드시 사람이 보존해야 할 가장 필요한 부분은 아닙니다.
지속 가능한 부분에는 다음과 같은 것들이 포함될 수 있습니다:
- 메모리 (memory) 및 장기 상태 (long-term state);
- 선호도, 정책 및 권한;
- 대화 및 그 출처 (provenance);
- 문서, 연구 기록, 주장, 증거 및 출처;
- 생성된 결과물 (artifacts) 및 프로젝트 이력;
- 모델 및 런타임 매니페스트 (manifests);
- 가져오기 (import), 내보내기 (export), 백업 (backup), 복구 (restore) 및 마이그레이션 (migration) 기록;
- 전송할 수 없었던 정보에 대한 명시적 기록.
모델은 교체될 수 있습니다.
더 유능한 모델이 출시될 수 있습니다. 제공업체가 오래된 모델을 은퇴시킬 수 있습니다. 사용 가능한 하드웨어가 변경됨에 따라 사용자가 더 작은 로컬 모델 (local model)로 이동해야 할 수도 있습니다.
모델을 변경한다고 해서 사용자가 축적해 온 상태 (state)를 자동으로 잃게 되어서는 안 됩니다.
doll의 핵심 아이디어는 다음과 같습니다:
모델은 교체 가능한 추론 엔진 (reasoning engines)입니다. 사용자의 상태 (state)가 지속 가능한 핵심입니다.
로컬 AI만으로는 연속성을 해결할 수 없습니다
모델을 로컬에서 실행하는 것은 외부 의존성을 줄이는 중요한 방법입니다.
클라우드 서비스를 사용할 수 없을 때도 로컬 모델은 계속 사용할 수 있습니다. 또한 지속적인 API 비용을 제거할 수 있으며, 데이터를 사용자가 제어하는 하드웨어에 유지할 수 있습니다.
하지만 로컬 실행만으로는 연속성 (continuity)을 보장할 수 없습니다.
만약 대화와 메모리가 단일 로컬 AI 애플리케이션에 속한 특정 애플리케이션 전용 데이터베이스 (application-specific database) 내에 저장된다면 어떻게 될까요?
만약 그 애플리케이션이 더 이상 유지 관리되지 않거나, 저장 형식을 변경하거나, 새로운 운영 체제에서 작동을 멈추거나, 다른 기기로 옮길 수 없게 된다면 어떻게 될까요?
로컬 애플리케이션은 또 다른 형태의 락인 (lock-in)이 될 수 있습니다.
이러한 이유로, doll은 ChatGPT, OpenAI 호환 API, Ollama, Open WebUI 또는 기타 제공업체, 런타임 (runtime), 인터페이스의 형식을 사용자 상태의 표준 표현 (canonical representation)으로 취급하지 않습니다.
다른 AI 환경에서 가져온 데이터는 문서화되고 검사 가능한 표현 방식으로 매핑 (mapped)되어야 합니다.
해당 매핑의 결과 또한 손실에 대해 정직해야 합니다.
가져오기 (import) 또는 내보내기 (export)는 다음과 같을 수 있습니다:
- 전체 (full);
- 부분적 (partial);
- 변환됨 (transformed);
- 지원되지 않음 (unsupported);
- 손실 발생 (lossy).
전송할 수 없는 정보가 소리 없이 사라져서는 안 됩니다.
로컬 완결형, 클라우드 선택형
doll의 핵심 원칙 중 하나는 다음과 같습니다:
로컬 완결형, 클라우드 선택형 (Local-complete, cloud-optional).
로컬 시스템은 API 키, 계정 등록 또는 영구적인 인터넷 연결 없이도 유용하게 유지되어야 합니다.
클라우드 모델은 궁극적으로 선택적인 성능 확장 도구로 사용될 수 있습니다. 많은 경우, 클라우드 모델은 사용자가 로컬에서 실행할 수 있는 모델보다 더 뛰어난 능력을 갖출 것입니다.
하지만 클라우드 서비스가 다음 항목의 신뢰할 수 있는 원천 (source of truth)이 되어서는 안 됩니다:
- 메모리 (memory);
- 정체성 (identity);
- 파일 (files);
- 권한 (permissions);
- 이식성 (portability);
- 백업 (backups);
- 복구 정보 (recovery information).
클라우드에 대한 접근 권한을 잃으면 성능은 저하될 수 있습니다.
하지만 사용자의 상태를 지우거나 복구 경로를 제거해서는 안 됩니다.
왜 doll에는 아직 연결된 모델이 없는가
이 글을 쓰는 시점에 doll은 pre-alpha (프리 알파) 단계입니다.
아직 연결된 모델 런타임 (model runtime)이 없으며, 일상적으로 사용하는 AI 어시스턴트도 아닙니다.
이는 의도된 사항입니다.
많은 AI 프로젝트들이 모델을 연결하고 채팅 인터페이스를 구축하는 것으로 시작합니다. 하지만 doll은 다른 경로를 택하고 있습니다. 모델이 도입되기 전에, 모델이 넘지 말아야 할 경계(boundaries)를 먼저 정의하고 강제해야 하기 때문입니다.
현재 구축 중인 모델 독립적인 기반 (model-independent foundation)에는 다음 사항들이 포함됩니다:
- 일반적인 메모리 (ordinary memory)와 비밀 정보 (secrets)의 분리;
- 로그 (logs), 내보내기 (exports), 백업 (backups), 테스트 픽스처 (test fixtures) 또는 진단 (diagnostics)을 통해 비밀 정보가 유출되는 것을 방지;
- 일반적인 상태 (ordinary state)에 비밀 값 자체를 저장하는 대신 비밀 정보에 대한 참조 (references)를 저장;
- 저장된 자격 증명 (credentials)을 모델에 노출하지 않고, 제한된 자격 증명 기반 작업 (credential-backed operations)을 수행;
- 확인된 사실 (confirmed facts), 주장 (claims), 증거 (evidence), 그리고 추론 (inferences)의 구분;
- 정보와 지침의 출처 (origin) 기록;
- 검색된 페이지, 문서, 도구 결과 (tool results), 그리고 가져온 데이터 (imported data)를 권위 (authority)가 아닌 데이터로 취급;
- 외부 기능 (external capabilities)을 명시적으로, 그리고 정의된 제한 범위 내에서만 부여;
- 고위험 작업 (high-risk operations)에 대해 사용자의 새로운 확인을 요구;
- 작업이 실패했을 때 마지막으로 알려진 양호한 상태 (last known good state)를 보존.
모델이 단순히 로컬 (locally)에서 실행된다고 해서 자동으로 신뢰할 수 있는 것은 아닙니다.
로컬 애플리케이션, 플러그인 (plugins), 가져온 대화, 문서, 검색 결과, 그리고 도구 출력 (tool output)은 단지 모델의 컨텍스트 (context)에 배치되었다는 이유만으로 권위를 얻어서는 안 됩니다.
모델을 연결한 후에 이러한 제어 장치들을 추가하는 것은, 권위 모델 (authority model)이 명확하게 정의되지 않은 시스템 주변에 부차적인 보호책을 만드는 위험을 초래할 수 있습니다.
따라서 doll은 경계를 먼저 구축하고 있습니다.
doll이 아닌 것
doll은 다음과 같은 것을 의도하지 않습니다:
- 또 다른 모델 실행기 (model runner);
- 기존 로컬 AI 인터페이스의 복제본;
- 클라우드 의존적인 어시스턴트 (assistant);
- 제한 없는 자율적 컴퓨터 제어 에이전트 (agent);
- 일반적인 AI 상태 (state)에 내장된 자격 증명 데이터베이스;
- 영구적인 프론티어 모델 (frontier-model) 성능의 보장;
- 서로 다른 모델들이 동일하게 동작할 것이라는 주장;
- 보편적이고 손실 없는 마이그레이션 (migration)에 대한 약속.
다른 모델로 이동하면 응답 품질, 동작, 성격 또는 추론 능력 (reasoning ability)이 변할 수 있습니다.
성능이 낮은 하드웨어로 이동하면 시스템이 할 수 있는 작업이 줄어들 수 있습니다.
연속성 (Continuity)이 성능이 절대 변하지 않는다는 것을 의미하지는 않습니다.
그것은 그러한 변화 속에서도 살아남아야 하는 것들을 보존한다는 의미입니다:
- 사용자가 소유한 상태 (user-owned state);
- 출처 (provenance);
- 권한 및 안전 경계 (safety boundaries);
- 가시적인 마이그레이션 손실;
- 백업 (backups);
- 복구 절차 (recovery procedures);
- 다른 환경으로 가는 문서화된 경로.
현재 상태
doll은 완성된 제품이 아닙니다.
아직 완전한 개인용 AI 어시스턴트로 설치하여 사용할 수 없습니다.
현재의 초점은 로컬 모델 통합이 시작되기 전에 모델에 독립적인 상태 관리 (state management), 전송 (transfer), 백업 (backup), 복구 (restoration), 휴대성 (portability) 및 안전 경계 (safety boundaries)를 구축하는 데 있습니다.
개발은 작은 사양 (specifications), 이슈 (issues), 브랜치 (branches) 및 풀 리퀘스트 (pull requests)로 나뉘어 진행됩니다.
저장소 (repository)에는 구현된 내용뿐만 아니라, 구현 순서의 근거, 수락 요구 사항, 그리고 무언가 실패했을 때의 예상 복구 동작도 기록됩니다.
프로젝트 웹사이트:
소스 코드, 사양 (specifications), 아키텍처 결정 기록 (architecture decision records) 및 구현 이력:
https://github.com/badjoke-lab/doll
제가 비판받고 싶은 부분
이 단계에서의 목표는 많은 사용자를 끌어들이는 것이 아닙니다.
지금은 홍보보다 설계에 대한 비판이 더 유용합니다.
저는 특히 다음과 같은 질문들에 관심이 있습니다:
- 표준적인 사용자 상태(canonical user state)는 어디에서 끝나고 모델별 상태(model-specific state)는 어디에서 시작되어야 하는가?
- AI 환경 사이를 이동할 때 어떤 정보가 필연적으로 손실되는가?
- 출처(provenance)를 현실적으로 어느 정도까지 보존할 수 있는가?
- 비밀 정보(secrets), 일반 상태(ordinary state), 그리고 모델 액세스(model access) 간의 제안된 분리가 숨겨진 취약점을 포함하고 있지는 않은가?
- 애플리케이션, 런타임(runtime), 모델, 또는 기본 머신(primary machine)이 사라졌을 때 시스템이 실제로 복구될 수 있는가?
- doll 자체가 새로운 형태의 락인(lock-in)이 될 수 있는가?
- 로컬에서 완결성(locally complete)을 갖는다는 주장이 아직 인식되지 않은 가정이나 외부 구성 요소에 여전히 의존하고 있지는 않은가?
또한 저는 동일한 문제를 다루는 기존의 표준, 프로젝트, 연구, 그리고 문서화된 실패 사례들에 대해서도 알고 싶습니다.
doll은 아직 초기 단계에 있습니다.
그렇기에 저는 이것을 완성된 AI 시스템으로 제시하기 전에, 무엇이 살아남아야 하는지, 무엇이 교체 가능한 상태로 남아야 하는지, 그리고 권한(authority)이 어디에서 멈춰야 하는지를 정의하고자 합니다.
공개 사항: 이 기사는 AI의 도움을 받아 작성되었으며, 프로젝트 유지 관리자(maintainer)에 의해 검토, 편집 및 승인되었습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기