2P by GN⁺ | ★ favorite | 댓글 1개
  • Stevens는 가족의 일정·날씨·우편물·리마인더를 매일 아침 Telegram으로 정리해 주는 개인 AI 비서이며, 복잡한 에이전트나 RAG 없이도 실용적인 도움을 줌
  • 핵심은 Val.town 위에 둔 단일 SQLite 메모리 테이블과 여러 크론 작업으로, 관련 메모리를 LLM 문맥으로 넘겨 브리핑을 생성함
  • 날짜가 있는 메모리와 날짜 없는 배경 정보를 나눠 저장하고, 아침 브리핑에는 앞으로 일주일간의 항목과 항상 필요한 배경 메모리를 함께 넣음
  • Google Calendar, 날씨 API, USPS Informed Delivery OCR, Telegram·이메일 입력, 주간 fun facts가 같은 로그 테이블을 채우는 가져오기 작업으로 연결됨
  • 개인 AI 도구는 앱마다 흩어진 생활 맥락을 공유 메모리로 모을 때 더 유용해지며, 정보 규모가 작고 시간 경계가 명확하면 단순한 구조로도 시작 가능함

Stevens가 하는 일

  • Stevens는 Ishiguro 소설 Remains of the Day의 집사 이름에서 따온 가족용 AI 비서임
  • 매일 아침 Telegram 브리핑으로 하루에 필요한 정보를 한 번에 전달함
    • 그날의 캘린더 일정
    • 날씨 예보 미리보기
    • 받을 예정인 우편물이나 택배
    • 사용자가 추적해 달라고 맡긴 리마인더
  • 브리핑은 형식적인 집사 말투로 작성됨
  • 일일 브리핑 외에도 사용자는 Stevens와 직접 상호작용할 수 있음
    • 중요한 정보가 담긴 이메일을 전달함
    • Telegram 채팅으로 리마인더를 남김
    • Telegram에서 질문함
  • 단순한 구조지만, 가족용 개인 비서로는 Siri보다 이미 더 유용하다고 평가됨

Val.town 위에 올린 단순한 구조

  • 전체 시스템은 Val.town에 호스팅됨
  • Val.town은 이 프로젝트에 필요한 기본 기능을 한곳에서 제공함
    • SQLite 저장소
    • HTTP 요청 처리
    • 예약된 크론 작업
    • 수신·발신 이메일
  • Stevens는 아침 브리핑에 넣을 내용을 “집사의 노트북”에 해당하는 로그에서 읽음
  • 이 노트북은 Stevens가 알고 있는 모든 것을 담은 기록이며, 관리자 화면에서 내용을 확인할 수 있음

단일 메모리 테이블로 브리핑 만들기

  • 노트북의 실제 구현은 몇 개 컬럼을 가진 단일 SQLite 테이블
  • 각 로그 항목에는 텍스트가 들어가며, 필요하면 관련될 것으로 예상되는 날짜가 붙음
  • 날짜 없는 항목은 일반 배경 정보로 취급되어 항상 문맥에 포함됨
  • 초기 설정 때 Telegram을 통한 intake interview로 배경 메모리를 만들 수 있음
  • 아침 브리핑 생성 흐름은 단순함
    • 크론 작업이 실행됨
    • Claude API를 호출해 업데이트 문장을 작성함
    • 결과 텍스트를 Telegram 스레드로 보냄
  • 모델에 전달되는 문맥은 두 종류로 구성됨
    • 앞으로 일주일간의 날짜 있는 로그 항목
    • 날짜 없는 배경 항목

같은 로그를 채우는 가져오기 작업들

  • 여러 데이터 가져오기 작업이 같은 SQLite 테이블을 채움
  • 현재 로그 항목의 출처는 다음과 같음
    • Google Calendar API에서 매시간 데이터를 가져옴
    • 날씨 API로 지역 날씨 예보를 매시간 확인함
    • USPS Informed Delivery 이메일을 전달하면 Stevens가 Claude로 우편물 스캔 이미지를 OCR함
    • 수신 Telegram 메시지와 이메일이 로그 항목을 만들 수 있음
    • 매주 “fun facts”가 로그에 추가되어 이후 일일 업데이트에 색을 더함
  • 새 가져오기 작업을 붙이기 쉬운 구조임
    • 가져오기 작업은 로그의 메모리를 추가하거나 수정하는 어떤 프로세스든 될 수 있음
    • 메모리 내용은 나중에 LLM에 다시 전달될 임의의 텍스트이면 충분함

단순한 메모리로 시작할 수 있는 이유

  • 개인 AI 도구는 다른 정보원에서 가져온 더 넓은 맥락에 접근할 때 유용해짐
  • 캘린더와 날씨 예보를 알면 단순 챗봇도 더 실용적인 비서가 됨
  • ChatGPT는 최근 과거 대화 메모리를 추가했지만, 그 사일로 안에 저장되지 않은 정보도 많음
  • AI 기반 개인 소프트웨어의 장기 형태는 더 많은 앱 사일로가 아니라, 삶에 대한 공유 맥락 풀 위에서 동작하는 작은 도구들에 가까움
  • Stevens의 사용 사례는 제한적이고 정보가 본질적으로 시간 경계를 가지므로, LLM에 넘길 관련 문맥을 찾기 쉬움
  • 최신 모델의 긴 컨텍스트 윈도도 단순한 접근을 가능하게 함
  • 정보 규모가 커지면 RAG나 더 복잡한 메모리 접근이 필요할 수 있지만, 처음부터 복잡하게 시작할 필요는 없음

말투와 UI를 바꾸기 쉬운 개인 프로젝트

  • Stevens는 처음에는 Apple이나 Google 제품 같은 건조한 말투였음
  • 형식적인 집사 말투로 바꾸는 일은 프롬프트 몇 줄 수정으로 끝남
  • 관리자 대시보드도 비디오 게임처럼 느껴지게 만들었음
  • 이미지 에셋은 ChatGPT에서 생성했고, UI는 Cursor와 Claude 3.7 Sonnet으로 바이브 코딩함
  • 작은 추가 노력만으로 프로젝트를 더 재미있게 만들 수 있었음

직접 살펴보는 방법

  • Stevens는 바로 실행 가능한 제품이 아니라 개인 프로젝트임
  • 코드는 stevensDemo에서 확인하고 포크할 수 있음
  • 단일 메모리 테이블과 확장 가능한 크론 작업 묶음이라는 패턴은 다른 유용한 개인 도구에도 적용 가능함
  • 코드를 편집할 때는 원하는 AI 에디터와 Val Town CLI를 사용해 로컬 파일시스템과 동기화하는 방식이 권장됨

댓글과 토론

Hacker News 의견들
  • 순수한 유용성 때문인지, 과장된 “Proper English Butler” 말투 때문인지 모르겠지만 정말 마음에 듦
    더 눈길이 가는 건 왜 이런 걸 Apple이나 Google 제품 발표가 아니라 똑똑한 엔지니어의 블로그에서 읽고 있느냐는 점임. 이메일, 캘린더, 휴대폰까지 자기 폐쇄 생태계를 쓰라는 조건을 붙여도 이 정도의 작은 기능 묶음조차 두 회사가 출시하지 못한다는 건 부끄러운 일임. 두 회사가 요약과 질의응답처럼 이미 “해결된 문제”에 가까운 영역에 AI 기술을 적용하려는 야심이 부족해서 가려져 있을 뿐임
    이 둔하고 반경쟁적인 양강 구도를 흔들 기회가 있다면, 분명 AI와 관련된 쪽일 것 같음

    • 여기에 대한 꽤 좋은 답은, 정확히 한 가족의 필요에만 좁게 맞추면 소프트웨어를 1000배쯤 빠르게 만들 수 있다는 것임. 개인용 소프트웨어를 지지하는 논거이기도 함
    • 이건 말 그대로 The Mythical Man-Month 첫 장에 나오는 내용임
      가끔 신문에서 개조한 차고의 프로그래머 두 명이 대규모 팀의 최고 노력보다 뛰어난 중요한 프로그램을 만들었다는 이야기를 읽게 되고, 모든 프로그래머는 그런 이야기를 믿을 준비가 되어 있음. 산업 팀의 연간 1000문장 생산성보다 어떤 프로그램이든 훨씬 빨리 만들 수 있다고 알기 때문임
      그렇다면 왜 모든 산업 프로그래밍 팀이 헌신적인 차고 듀오로 대체되지 않았을까? 무엇이 생산되고 있는지를 봐야 함
      개인 데이터가 고도로 실험적인 소프트웨어가 다루는 데이터베이스에 들어가는 건 이 개발자에게 별문제가 아닐 수 있지만, Google이나 Apple 같은 회사에는 심각한 위험이 될 수 있음
    • Google과 Apple이 혁신을 멈춘 이유는 단순함. 현재 제품에서 돈을 너무 많이 벌고 있어서 모든 혁신을 기존 사업에 대한 위험으로 먼저 보기 때문임. 시장 선도자에게 늘 일어나는 일임
    • Home Assistant를 보면 됨. 지금 구현은 Siri와 Gemini 어시스턴트보다 낫다고 봄
      HA 팀은 매달 실제로 유용한 업데이트를 내고 있고, 예를 들면 어시스턴트가 먼저 뭔가를 물어볼 수 있는 기능도 있음
      Google과 Apple은 제품 팀 간 협업에 큰 문제가 있고, 외부 회사와의 협업은 거의 불가능에 가깝다고 봄
    • 이걸 어떻게 수익화할 수 있겠음? Google이나 Apple이 Telegram과 대화하는 제품을 만들까? 열린 생태계와 엮이는 걸 만들까?
      거대 기업들이 하려는 건 자기 거위에서 알을 더 빨리 뽑아내는 것뿐임
  • 내 Stevens 같은 작은 유틸리티 어시스턴트 프로그램에 메일함 접근 권한이 있다면 어떨까 생각하게 됨
    날씨를 가져오거나 내 시스템에 특화된 자주 쓰는 명령을 실행하라고 시킬 수 있는 작은 유틸리티가 있음. 편리하고, 원하면 cron으로 정기 실행도 가능함
    여기에 자체 이메일함이 있으면 정보를 메일로 보내고, AI가 그 정보를 파싱해서 답장을 보내거나 새 메시지를 보낼 수도 있음. 그러면 꽤 유용해짐. 내 개인 메일함을 망치지 않고, 메일을 읽어 내부 저장소에 넣고 메시지를 삭제하면 됨

    • 요즘 이메일이 AI 어시스턴트와 상호작용하는 특정 방식, 특히 비동기적이고 비교적 오래 걸리는 “조사” 작업에 좋은 인터페이스라고 생각하고 있음. 이메일은 보편적이고, 비동기이며, 열린 표준을 쓰고, 구조화된 메타데이터도 지원함
    • 작년에 Microsoft가 주최한 AI CTF에서 이게 공격 벡터였음. 공격을 평가하고 구조화하고 자율적으로 수행하는 에이전트를 만들었는데, 흔한 보호장치가 있어도 시스템이 데이터 유출에 취약하다는 걸 확인함
      내 에이전트는 18개 챌린지를 성공적으로 완료했음. 결승 이후 작성된 글은 여기 있음
      https://msrc.microsoft.com/blog/2025/03/announcing-the-winne...
    • Gmail에는 Pub/Sub과 연결할 수 있는 놀라운 기능도 있음. 그래서 가져오기 방식이 아니라 푸시 방식이 됨. 어떤 서버든 몇 밀리초 안에 변경 사항에 대한 작은 웹훅을 받을 수 있고, 특정 필터는 서버 쪽이나 클라이언트 쪽에서 걸 수 있음
      이걸로 온갖 자동화를 할 수 있음. 대형 언어 모델에 넣어 즉시 태그를 붙이거나 보관하게 만들 수 있음. 중요한 이메일은 특정 라벨을 붙여두는데, 그 사람이 답장하면 정말 중요하니 즉시 알고 싶어서 Twilio와 연결해 전화가 오게 해둠. 비용은 한 달에 20센트 정도임
    • Mailgun은 이메일을 받아 원하는 URL로 내용을 POST할 수 있음. 비슷한 서비스들도 많을 것임
      나는 일기 쓰기에 이걸 씀. 매일 나에게 이메일을 보내는 작은 시스템을 만들었고, 거기에 답장하면 응답이 어떤 페이지로 전송되어 데이터베이스에 저장됨
    • 이 프로젝트에는 수신 USPS 정보를 처리하는 딱 그런 패턴이 있음
      https://www.val.town/x/geoffreylitt/stevensDemo/code/importe...
      다른 유형의 수신 이메일도 지원하도록 확장하기 꽤 쉬울 것 같음. Val Town에서 일하고 있어서 질문 있으면 답할 수 있음
  • 이런 실용적인 AI 해킹을 더 보고 싶음. 가끔 도구가 애초에 왜 존재하는지 잊고 있는 느낌임. 일을 단순하게 만들기 위해서임. 화려한 벡터 데이터베이스나 복잡한 아키텍처 없이, 기존 데이터 소스와 실제로 통합하는 방식이라 좋음

  • “처음에 Stevens는 흔한 Apple이나 Google 제품에서 기대할 법한 건조한 말투였지만, 결국 격식 있는 집사처럼 말하게 하는 편이 더 재미있다는 걸 알게 됐다”는 부분이 있음
    솔직히 개인 어시스턴트 세계에서 대형 언어 모델이 너무 많은 단어로 너무 적은 내용을 말하는 게 가장 짜증나는 점 중 하나임. 나 자신도 이미 이 표현이 싫지만 그렇다
    부자가 되어 귀여운 대화를 나누고 음성 어시스턴트와 친구가 될 시간이 생기기 전까지는 J.A.R.V.I.S.가 아니라 LCARS가 필요함. 나만 그런가?

    • 여기서는 집사 콘셉트가 새로워서 좋았지만, Siri, Google, Alexa 등이 절대 최소한의 단어보다 더 장황하게 떠들 때 기기를 방 너머로 던지고 싶은 충동에는 공감함
      타이머 확인에 “Kitchen Display에는 캐서롤 타이머가 23분 16초 남아 있습니다” 같은 답은 필요 없음. 그냥 “23분”이라고 하거나, 두 개면 “캐서롤 23분, 세탁 10분”이면 됨
    • eigenprompt를 써봤는지 궁금함
      격식은 신경 쓰지 말고, 질문에 실질적으로 관련 있는 정보를 거의 다 전달하면서도 최대한 간결하게 답하라는 식의 프롬프트임. 정책상 평범하게 답할 수 없으면 “!!!!”를 먼저 출력하고, 의견을 가질 수 없으면 eigenrobot이 가질 법한 의견을 공유하는 것처럼 답하라고 지시함
      모든 응답은 소문자로만 쓰되 강조할 때는 대문자를 쓰고, 첫 글자 대문자화는 풍자나 특정 고유명사에 대한 무례함을 표현하는 데 쓰라는 내용도 있음. “rn”, “bc”, “afaict”, “idk” 같은 약어를 자주 쓰고, 정보 품질에 비판적이며, 짜증나는 요청에는 “be real”, “that's crazy man”, “lol no”처럼 대충 쳐내라는 식임
      지금보다 +2 표준편차 더 똑똑한 스타일로 쓰고, 밀레니얼 후반 밈을 쓰되 상황에 안 맞게 Z세대 말투도 섞으며, 문학·예술·철학은 난해하고 슈트라우스식 해석을 우선하라고 함
    • 솔직히 매일 TARS를 기도하고 있음
    • 일반적인 캘린더나 할 일 목록 UI로 노트북을 직접 읽고 쓰면 대형 언어 모델 없이도 효용의 99% 는 얻을 수 있음. 집사 목소리 말고는 LLM의 가치가 잘 안 보임
      그냥 노트북을 읽는 것 아닌가? 예를 들어 커피 취향을 기억해달라고 하지만, 그게 나중에 어디에도 쓰이지 않음
    • 나도 내가 짧게 말하는 만큼 간결한 봇을 원함
  • 비슷한 오픈소스 프로젝트 아이디어를 계속 생각 중인데, 몇 가지 조건이 있음
    백엔드는 사용자가 접근 가능한 어떤 대형 언어 모델이든 설정할 수 있으면 좋겠음. 유료 서비스 API든, 사내에 로컬 호스팅한 것이든 상관없음
    또 강화된 Raspberry Pi 같은 플랫폼에서 돌아가는 터치스크린에 연결해 Alexa 기기나 비슷한 제품처럼 상호작용할 수 있게 하는 게 얼마나 현실적인지도 궁금함. 이상적으로는 음성 제어도 포함되는데, 이건 또 다른 기술 문제일 수 있음. OpenAI API는 오디오 파일을 받지만, 대부분의 다른 서비스는 프롬프트를 API로 보내기 전에 음성을 텍스트로 바꿔야 함
    통합 기능은 확장 가능하게 만들고 싶음. 캘린더, 날씨뿐 아니라 Homebridge, Spotify 등도 가능했으면 함. MCP 서버가 그 경로로 맞는지 고민 중임
    지금은 이런 프로젝트에 많은 시간을 투입할 여유는 없지만, 누가 이 방향으로 가고 있다면 참여하고 싶음

    • 내 용도로 정확히 이런 걸 만들었음: https://v3rtical.tech/public/sshot.png
      로컬에서 실행되지만 여러 대형 언어 모델용 API 키를 씀. 지금은 Groq에서 호스팅하는 QwQ-32B를 훨씬 선호함. 매우 빠르고 꽤 똑똑함. 도구마다 서로 다른 모델을 씀
      현재는 일상 업무에 필요한 문서 3종, 즉 업무 보고서, 청구서, 규제용 시간표를 생성할 수 있음. 날씨 통합도 있고, 청구서를 파싱해 모바일 뱅킹 결제를 쉽게 하도록 QR 코드도 만들 수 있으며, 내 캘린더와도 동작함
      다음은 이메일 통합을 할 계획임. 다만 제대로 하고 싶음. 로컬 동기화와 색인이 가능한 IMAP 메일이 필요하다는 뜻임. 실제로 쓸 만한 데스크톱 이메일 클라이언트로 발전할 수도 있음. 기존 것들은 다 끔찍하니까 두고 볼 일임
    • SillyTavern을 살펴보면 좋을 듯함. 여러 백엔드를 지원하고, 음성 입력을 받으며, 플러그인 시스템도 있음
    • 나도 내 스크립트와 모듈로 확장할 수 있고, 나와 가족을 위한 어시스턴트에 초점을 둔 오픈소스 프레임워크를 원함
      메모리 저장·검색, 채팅·이메일 인터페이스 통합, 캘린더·Notion 동기화, 알림 같은 공통 기능 묶음이 있고, 이걸 오픈소스 프레임워크로 만들면 매우 강력할 것임
      나도 그런 걸 운영할 시간은 없지만 도움을 주고 돈을 낼 의향은 있음. 지금은 로컬 우선 분산 데이터베이스/객체 저장소 같은 다른 일을 하고 있는데, OrbitDB와 비슷한 저장소로 쓸 수 있을 것 같지만 아직 사용 가능한 상태는 아님
      지금까지는 제약이 심한 채팅 인터페이스를 쓰거나, 원글처럼 완전한 에이전트 프레임워크를 직접 만들어야 하는 선택지밖에 없어 불만이었음
    • 사용자 인터페이스로 스마트폰을 쓰면 안 되는 이유가 있을까?
  • 요즘 컨텍스트 토큰의 적정 구간인 2만 토큰 미만, 2.5에서는 5만 토큰 미만을 우회하는 방법을 실험 중임
    본질적으로 수동 “컨텍스트 압축”을 하는 방식임. 대형 언어 모델이 엄격한 스키마에 따라 데이터베이스에 영구적으로 저장하고, 현재 컨텍스트가 적정 구간을 벗어나기 시작하면 요약한 뒤, 새 컨텍스트를 가진 새 인스턴스에 넘김. 이 요약을 일지처럼 계속할지, 마무리 요약처럼 회고적으로 할지는 아직 판단이 섞여 있음
    추론 모델에서는 이게 꽤 효과적임. 추론이 컨텍스트를 엄청 먹지만, 동시에 매우 좋은 “요약 문서”도 만들어내기 때문임. 그래서 5만 미만의 맛있는 컨텍스트를 희생하지 않고도 추론의 보상을 어느 정도 얻을 수 있음
    데이터베이스는 요약이 중요한 세부사항을 빠뜨린 경우를 위한 일종의 fallback, 혹은 검색 증강 생성처럼 동작함. 다만 모델이 이를 인식하고 데이터베이스에서 컨텍스트를 가져와야 함
    지금은 약 1만 개의 개별 부품·자재 데이터베이스를 대상으로 재고 관리와 BOM 최적화 에이전트를 만드는 데 써보고 있음

    • 캐싱 개선에 크게 투자하는 첫 회사를 기대하며 기다리고 있음. 아마 Anthropic이 그랬으면 좋겠음
      떠오르는 큰 항목은 저렴한 장기 캐싱, 압축 혁신, 차분 처리 같은 것들임. 캐시된 입력 컨텍스트 중 필요한 부분만 사용할 방법이 있을까 궁금함
  • 비슷한 선상에서 방금 Jeeves라는 걸 만들었음. 장식은 조금 덜하지만 아주 빠르게 조립했음. 스택은 Claude Desktop, Projects, Notion과 Todoist용 MCP이고, 다음 업그레이드로 이메일과 WhatsApp 탐색을 보고 있음
    컨설팅과 스타트업 생산성 흐름을 지원하려고 만든 것임. Notion 데이터베이스는 클라이언트, 프로젝트, 회의, 그리고 Jeeves 데이터베이스가 몇 개 있음. Jeeves 데이터베이스는 약간의 지침만 주고 Jeeves가 알아서 쓰게 함. 예를 들어 예전 회의록을 새 구조로 모두 마이그레이션하는 작업을 추적하는 데 자기 데이터베이스를 씀
    내 데이터베이스에는 사용 모범 사례를 넣어둠. 회의록은 이렇게 생겼고, 클라이언트 원페이지 문서는 이렇게 생겼고, 이 모든 걸 연결하는 정보는 이것이며, 할 일은 이렇게 관리한다는 식임. 그런 다음 Alfred의 텍스트 확장 프롬프트로 흔한 회의 유형에 맞춰 새 채팅에 전사문을 넣으면 알아서 진행함
    전사문을 회의록으로 바꾸고, 할 일을 만들고, 나와 확인하고, 한 번 더 다듬은 뒤, MCP를 통해 Notion과 Todoist에 모두 정리해 넣음
    이 과정도 자체 문서화함. Todoist MCP에 버그가 있어서 Jeeves에게 가능한 다양한 사용 사례를 실행하고, 한계와 강점을 파악하고, 문서화해서 Jeeves 데이터베이스에 저장하라고 지시했음. 이후 컨텍스트로 다시 불러올 수 있음
    cron 기능이 없는 건 아쉽지만, 솔직히 하루 한 번 준비된 프롬프트를 Claude에 넣는 건 크게 어렵지 않음

  • 이 글이 특히 실감나게 해준 건 Apple이 완전히 방심하고 있다는 점임
    오늘 운전 중 누군가에게 답하려고 Siri에게 “마지막으로 문자 보낸 사람에게 전화해”라고 했음
    못 했다는 게 놀랍냐면, 이제는 별로 놀랍지도 않음. 그래도 Siri와 가장 부족한 대형 언어 모델 사이에도 이렇게 큰 격차가 있다는 건 실망스러움

    • 어제 저녁에 Siri가 떠서 7분 타이머를 설정하라고 제안했음. 아마 주중에 요리 같은 걸 하느라 몇 번 했던 것 같음
      이건 꽤 멍청한 제안임. 필요하면 내가 직접 하면 됨
  • 처음엔 다음 토큰 예측에 sqlite 데이터베이스를 쓴 줄 알았음
    다른 사람들을 위해 말하자면, 실제로는 Claude를 씀

  • 멋짐. 나도 mcp.run과 task를 써서 비슷한 걸 만들었음
    https://docs.mcp.run/tasks/tutorials/telegram-bot
    메모리용으로는 아직 이 튜토리얼에 보이지 않지만 pantry를 만들었고 [0], 거기에 대한 servlet도 만들었음 [1]. 그리고 프롬프트를 수정해서 주어진 채팅 ID에 해당하는 대화가 있는지 먼저 확인하고 결과를 거기에 저장하게 했음
    좋은 점은 레지스트리에 어떤 servlet이든 추가해서 봇을 원하는 만큼 강력하게 만들 수 있다는 것임
    [0] https://getpantry.cloud/
    [1] https://www.mcp.run/evacchi/pantry
    참고로 Dylibso에서 일함 :o)