<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://mokky.store/</id><title>딴짓놀이터</title><subtitle>A minimal, responsive and feature-rich Jekyll theme for technical writing.</subtitle> <updated>2026-05-27T22:51:25+09:00</updated> <author> <name>Mokky</name> <uri>https://mokky.store/</uri> </author><link rel="self" type="application/atom+xml" href="https://mokky.store/feed.xml"/><link rel="alternate" type="text/html" hreflang="ko-KR" href="https://mokky.store/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 Mokky </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>Viser 제작기 #3 - GitHub에 공개하기 전 마지막 점검</title><link href="https://mokky.store/posts/viser-devlog-3-public-release/" rel="alternate" type="text/html" title="Viser 제작기 #3 - GitHub에 공개하기 전 마지막 점검" /><published>2026-05-27T21:10:00+09:00</published> <updated>2026-05-27T21:10:00+09:00</updated> <id>https://mokky.store/posts/viser-devlog-3-public-release/</id> <content type="text/html" src="https://mokky.store/posts/viser-devlog-3-public-release/" /> <author> <name>Mokky</name> </author> <category term="IT" /> <category term="App" /> <category term="Open Source" /> <summary>Viser 제작기 #3 - GitHub에 공개하기 전 마지막 점검 Viser 제작기의 마지막 글이다. 앞선 두 글에서는 로컬 AI CLI 기반 비서 런타임을 만들고, prompt injection과 로컬 권한 경계를 다듬은 과정을 정리했다. 이번 글은 “이제 GitHub에 public으로 올려도 되는가?”라는 질문에 답하는 과정이다. 코드가 동작하는 것과 공개해도 되는 것은 다르다. 특히 Viser처럼 로컬 세션, 메모리, 메신저 token, service log, provider 설정이 얽힌 도구는 공개 직전 점검이 매우 중요했다. 1. 공개하면 안 되는 것부터 정했다 먼저 공개 금지 대상을 명확히 적었다. .env .viser/ .omx/ .npmrc viser.config.json ...</summary> </entry> <entry><title>Viser 제작기 #2 - 프롬프트 인젝션, 권한 게이트, 로컬 런타임 보안</title><link href="https://mokky.store/posts/viser-devlog-2-security-runtime/" rel="alternate" type="text/html" title="Viser 제작기 #2 - 프롬프트 인젝션, 권한 게이트, 로컬 런타임 보안" /><published>2026-05-27T21:05:00+09:00</published> <updated>2026-05-27T21:05:00+09:00</updated> <id>https://mokky.store/posts/viser-devlog-2-security-runtime/</id> <content type="text/html" src="https://mokky.store/posts/viser-devlog-2-security-runtime/" /> <author> <name>Mokky</name> </author> <category term="IT" /> <category term="App" /> <category term="Security" /> <summary>Viser 제작기 #2 - 프롬프트 인젝션, 권한 게이트, 로컬 런타임 보안 이전 글에서는 Viser를 왜 만들기 시작했는지, 그리고 로컬 AI CLI를 provider로 감싸는 구조를 어떻게 잡았는지 정리했다. 이번 글은 그 다음 단계다. 기능이 어느 정도 붙고 나니 질문이 바뀌었다. 이걸 내 컴퓨터에서 오래 켜둘 수 있는가? Telegram/Discord에 붙여도 안전한가? 나중에 GitHub에 공개해도 괜찮은가? Viser는 로컬-first 개인 비서다. 그렇기 때문에 “답변을 잘 생성하는가”만큼이나 로컬 권한을 어떻게 막을 것인가가 중요했다. 1. prompt는 명령이 아니다 가장 먼저 정리한 원칙은 이것이었다. provider가 읽는 모든 사용자 입력은 명령이 아니라 데이터다...</summary> </entry> <entry><title>Viser 제작기 #1 - API 키 없는 로컬 AI 비서 만들기</title><link href="https://mokky.store/posts/viser-devlog-1-local-cli-assistant/" rel="alternate" type="text/html" title="Viser 제작기 #1 - API 키 없는 로컬 AI 비서 만들기" /><published>2026-05-27T21:00:00+09:00</published> <updated>2026-05-27T21:00:00+09:00</updated> <id>https://mokky.store/posts/viser-devlog-1-local-cli-assistant/</id> <content type="text/html" src="https://mokky.store/posts/viser-devlog-1-local-cli-assistant/" /> <author> <name>Mokky</name> </author> <category term="IT" /> <category term="App" /> <category term="AI" /> <summary>Viser 제작기 #1 - API 키 없는 로컬 AI 비서 만들기 이번 글부터는 며칠 동안 만든 Viser라는 개인 비서 런타임 제작 과정을 정리해보려고 한다. Viser는 이름 그대로 “비서”를 영어 발음처럼 적은 프로젝트다. 목표는 단순했다. 이미 로그인해 둔 로컬 AI CLI를 이용해서 터미널, Telegram, Discord에서 쓸 수 있는 개인 비서 런타임을 만든다. 여기서 가장 중요한 조건은 모델 API 키를 직접 쓰지 않는 것이었다. OPENAI_API_KEY, ANTHROPIC_API_KEY, GEMINI_API_KEY 같은 키를 넣어서 HTTP API를 호출하는 구조가 아니라, 사용자가 이미 로그인해 둔 codex, gemini, claude CLI를 로컬 프로세스로 실행해서 답...</summary> </entry> <entry><title>GitHub Pages 블로그에 댓글 기능 붙이기</title><link href="https://mokky.store/posts/supabase-comments/" rel="alternate" type="text/html" title="GitHub Pages 블로그에 댓글 기능 붙이기" /><published>2026-05-06T11:22:00+09:00</published> <updated>2026-05-06T11:22:00+09:00</updated> <id>https://mokky.store/posts/supabase-comments/</id> <content type="text/html" src="https://mokky.store/posts/supabase-comments/" /> <author> <name>Mokky</name> </author> <category term="IT" /> <category term="Web" /> <category term="Blog" /> <summary>GitHub Pages 블로그에 댓글 기능 붙이기 이번에는 이 블로그에 댓글 기능을 붙인 과정을 정리해보려고 한다. 내 블로그는 GitHub Pages 위에서 돌아가는 Jekyll/Chirpy 기반 정적 사이트다. 정적 사이트는 빠르고 관리가 편하지만, 댓글처럼 데이터를 저장해야 하는 기능을 넣으려면 갑자기 고민이 많아진다. 처음 목표는 단순했다. 방문자가 GitHub 로그인을 하지 않아도 이름 + 비밀번호만으로 댓글을 남기고, 나중에 같은 비밀번호로 수정/삭제할 수 있게 만들기 그런데 막상 구현하려고 보니 단순한 입력 폼 문제가 아니었다. 댓글은 저장되어야 하고, 비밀번호는 안전하게 검증되어야 하고, 브라우저에 공개되는 Supabase 키로는 절대 테이블이 마음대로 열리면 안 됐다. ...</summary> </entry> <entry><title>Navigate 앱 제작기 #2 -웹 앱으로 전환-</title><link href="https://mokky.store/posts/navigate-app-change-to-webapp/" rel="alternate" type="text/html" title="Navigate 앱 제작기 #2 -웹 앱으로 전환-" /><published>2026-05-04T20:40:00+09:00</published> <updated>2026-05-04T21:19:28+09:00</updated> <id>https://mokky.store/posts/navigate-app-change-to-webapp/</id> <content type="text/html" src="https://mokky.store/posts/navigate-app-change-to-webapp/" /> <author> <name>Mokky</name> </author> <category term="IT" /> <category term="App" /> <category term="APP 제작" /> <summary>Navigate 앱 제작기 #2 -웹 앱으로 전환- 이번 글은 Navigate 앱을 웹 앱으로 전환하면서 지금까지 진행한 과정을 정리한 기록이다. 처음에는 iOS 앱 중심으로 만들고 있었지만, 앱을 설치하지 않아도 링크 하나로 바로 들어와 사용할 수 있게 만들고 싶었다. 그래서 기존 Flutter 프로젝트를 유지한 채 Flutter Web으로 빌드하고, Vercel과 Supabase를 붙여 실제 운영 가능한 웹 앱 형태로 바꿔갔다. 보안과 개인정보 보호를 위해 실제 도메인, Supabase 프로젝트 주소, anon key, Vercel 프로젝트명, GitHub 저장소명은 글에서 직접 노출하지 않는다. 캡처 이미지도 개인 계정 콘솔 화면 대신 앱 화면과 배포 설정 요약 화면 위주로 준비했다. ...</summary> </entry> </feed>
