Sidekick Part 5 (최종): 네 가지 부분이 모여 무엇을 만들었는가
요약
본 기사는 '사용자 하드웨어에서 작동하는 터미널 컴패니언'인 Sidekick 프로젝트의 최종 정리 글입니다. 로컬 실행을 핵심 원칙으로 삼아, Ollama 기반 채팅/도구 사용, 사실 주입(Grounding), CPU 기반 음성 인식, 그리고 강력한 안전장치 등을 결합했음을 설명합니다. 이 모든 기능은 클라우드 의존성을 배제하고 사용자 하드웨어에 구조적으로 뿌리내리는 것이 핵심입니다.
핵심 포인트
- Sidekick은 Ollama를 이용해 로컬에서 실행되는 터미널 컴패니언이다.
- 접지(Grounding)는 모델의 환각을 막기 위해 실제 사실 정보를 주입하는 방식이다.
- 음성 기능은 CPU 기반으로 작동하며, 데이터가 외부로 전송되지 않아 프라이버시를 보장한다.
- 로컬 우선 구조와 한계에 대한 정직한 문서화가 이 프로젝트의 핵심 가치다.
Sidekick Part 5 (finale): 네 가지 부분이 모여 무엇을 만들었는가
이 시리즈는 '계정이나 요금 청구서 없이, 사용자의 하드웨어에서 작동하는 터미널 컴패니언'이라는 가설로 시작하여, 네 개의 파트를 거치며 이를 조각조각 방어해왔습니다. 이것이 마지막 계획된 파트입니다: 이 모든 것이 어떻게 합쳐졌는지, 제가 의도적으로 빼놓은 부분은 무엇인지, 그리고 앞으로 새로운 부분이 어디에서 나올 것인지를 다룹니다.
네 개의 아크(Arc)
Part 1: 개요 — sk는 Ollama를 통해 로컬에서 실행되는 채팅, 음성 및 19가지 도구입니다. 클라우드는 구조적인 요소가 아닌 키별 옵트인(opt-in) 방식입니다. 핵심 결정은 프롬프트 지침보다 결정론적 접지(deterministic grounding)에 두었습니다.
Part 2: 접지(Grounding) — 작은 모델들은 규칙을 무시하기 때문에, 코드가 모델이 프롬프트를 보기 전에 사실들(facts)을 주입합니다: 하드웨어 스냅샷, 자동 디렉토리 목록, 가져온 URL, 최신성 기반 검색. 과거의 모든 환각(hallucination)은 회귀 테스트(regression test)로 test_eval.py에 기록됩니다.
Part 3: 음성(Voice) — 푸시 투 토크(push-to-talk)는 int8 faster-whisper를 통해 CPU에서 전사되며, 녹음은 매번 사용 후 삭제됩니다. 아키텍처로서의 프라이버시: 업로드 경로가 존재하지 않습니다.
Part 4: 안전성(Safety) — 전송 시 승인, 기만을 가정하는 셸 블랙리스트(denylist), 기본적으로 거부되는 외부 통신(egress deny-by-default), 하나의 신뢰 병목 지점(trust chokepoint), 그리고 증거로서의 sk audit가 있습니다. 모든 한계는 과장된 것이 아니라 이슈 번호와 함께 문서화됩니다.
파트들이 공유하는 것들
제가 계획했든 아니든, 세 가지 핵심 주제가 매 회차에 나타났습니다. 첫째, 로컬 우선(local-first)은 브랜딩이 아닌 구조적 기반입니다. 접지가 작동하는 이유는 sysinfo가 실제이기 때문이며, 음성 프라이버시는 서버가 없기 때문에 유지되고, 감사(audit)는 원장(ledger)이 사용자 소유이기 때문에 의미를 갖습니다. '사용자의 하드웨어에서 실행된다'라는 문구를 제거하면 이 시리즈의 대부분 주장이 무너집니다. 이것이 원칙을 테스트하는 방법입니다: 그것을 삭제하고 무엇이 부서지는지 확인하는 것입니다.
둘째, 한계에 대한 정직함은 기능입니다. 이 시리즈는 추측된 상한선(guessed caps), 어설픈 정규 표현식 트리거(dumb regex triggers), 방어할 수 없는 쉘-curl 경로(unfenceable shell-curl path), 그리고 980줄짜리 인접 파일(이는 또 다른 프로젝트였지만 같은 본능이었습니다)을 문서화했습니다. 독자들은 '여기서 문제가 발생한다'는 말에 '그냥 작동한다'는 말보다 더 신뢰를 보내며, 미래의 유지보수자들—저를 포함하여—은 승리 기록보다 한계점들을 글로 적어 놓는 것을 더 필요로 합니다.
셋째, 모든 것은 퇴적층과 같습니다. 접지(Grounding)가 존재하는 이유는 지침이 실패했기 때문입니다. 이탈 규칙(Egress rules)이 존재하는 이유는 프롬프트가 실패했기 때문입니다. 평가 테스트(Eval tests)가 존재하는 이유는 운영 환경에서 답변이 실패했기 때문입니다. 여기에 있는 어떤 것도 위에서 아래로 설계된 것이 아니었습니다. 실제 실패들을 중심으로 쌓여 왔으며, 각 계층은 그것을 강요한 버그에 의해 날짜가 매겨졌습니다.
의도적으로 빠진 것들
메모리 및 스킬, 백그라운드 데몬(background daemon), 언급만 된 MCP 서버, 제공자 및 지출 상한선(providers and spend caps), TUI 내부 구조. 이것들은 간과된 부분이 아닙니다—범위 통제입니다. 각각은 같은 취급(메커니즘, 트레이드오프, 문제 발생 지점)을 받을 자격이 있으며, 실제로 이야기할 것이 있을 때마다 한 부분이 할당될 것입니다.
앞으로의 계획
이 시리즈는 계획대로 완료되었습니다. 하지만 소프트웨어는 가만히 있지 않습니다. 새로운 기능이 출시되거나, 오래된 기능이 흥미롭게 고장 날 때, 그것들은 새로운 부분으로 여기에 나타날 것입니다—같은 계약(증거, 메커니즘, 무엇이 문제였는지), 같은 번호 매김을 계속하며 위로 올라갈 것입니다. 끝나는 시리즈보다 진행되는 시리즈가 낫고; 이유를 가지고 재개하는 시리즈가 가장 좋습니다.
모든 다섯 편을 읽어주셔서 감사합니다. 로컬에서 실행해 보세요: uv tool install sidekick-agent 및 sk init.
Sidekick 커뮤니티 제작. 레포지토리(Repo): [https://github.com/Faisal-Fayaz/sidekick]
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기