Hacker News Korea에 올라온 SideQuick 소개를 보고 가장 먼저 든 생각은 “이건 생산성 앱이라기보다 사이드 프로젝트용 운영체계에 가깝다”였습니다. SideQuick은 사이드 프로젝트를 퀘스트 단위로 쪼개고, 진행 상황과 스트릭을 기록하고, 다시 돌아왔을 때 AI가 어디서 멈췄는지 요약해주는 데스크톱 앱입니다. 계정 없이 로컬에 저장되고, AI 기능은 자기 OpenAI/Anthropic 키를 넣는 BYOK 방식이며, v1.0.9부터는 OpenAI 호환 커스텀 엔드포인트도 지원한다고 소개되어 있습니다.
흥미로운 지점은 기능 목록보다 출발점입니다. 제작자는 GitHub 레포를 134개 만들었지만 실제로 의미 있게 간 것은 15개 정도였고, 늘 같은 패턴으로 프로젝트가 죽었다고 적었습니다. 아이디어에 들뜨고, 도메인을 사고, 초기 세팅을 하고, 몇 주 하다가 어느 날부터 열지 않는 패턴입니다. 이건 개발자에게 너무 익숙합니다. 프로젝트가 망한 게 아니라, 다시 들어가는 문턱이 매번 조금씩 높아져서 결국 안 열게 되는 겁니다.
이 글에서 얻는 것
- SideQuick이 왜 단순 TODO 앱과 다른 문제를 건드리는지 이해할 수 있습니다.
- 사이드 프로젝트가 죽는 이유를 “의지 부족”이 아니라 “재진입 비용” 관점으로 볼 수 있습니다.
- 퀘스트, 스트릭, 재진입 요약, 로컬 우선 저장을 내 프로젝트 운영 루틴에 적용할 수 있습니다.
- AI 계획 생성 도구를 쓸 때 생기는 과잉 계획, 죄책감 스트릭, 로컬 백업 문제를 미리 피할 수 있습니다.
SideQuick 요약: 할 일을 관리하는 게 아니라 다시 열게 만드는 앱
SideQuick의 핵심 기능은 네 가지로 볼 수 있습니다.
- Quest system: 목표를 단계별 퀘스트 트리로 나눕니다. 단계가 순서대로 열리고, 직접 편집하거나 AI로 초안을 만든 뒤 수정할 수 있습니다.
- Streak tracking: 매일 이어간 기록과 마일스톤을 보여줍니다. 공개 리더보드가 아니라 개인용 진행 신호에 가깝습니다.
- Re-entry summaries: 프로젝트를 한동안 안 열었을 때, 어디서 멈췄고 다음에 무엇을 해야 하는지 AI가 요약합니다.
- Local-first + BYOK: 계정 없이 오프라인 동작하고 데이터를 로컬에 저장합니다. AI 키도 사용자가 직접 넣고, 수동 모드에서는 키가 없어도 됩니다.
보통 TODO 앱은 “해야 할 목록”을 잘 보여줍니다. 그런데 사이드 프로젝트의 진짜 문제는 목록이 없어서가 아닙니다. 오히려 목록은 너무 많습니다. 문제는 한 주 쉬고 돌아왔을 때 “이걸 왜 하고 있었지?”, “마지막으로 뭘 고치다 말았지?”, “지금 30분이면 뭘 할 수 있지?”에 바로 답하지 못한다는 점입니다. SideQuick이 건드리는 부분은 바로 이 재진입 문턱입니다.
사이드 프로젝트는 시작보다 재진입에서 죽는다
사이드 프로젝트는 시작할 때 에너지가 큽니다. 새 레포, 새 프레임워크, 새 도메인, 예쁜 README까지는 빠르게 갑니다. 그런데 흥분이 빠진 뒤에는 프로젝트가 생활의 빈틈에 들어가야 합니다. 퇴근 후 40분, 주말 오전 2시간, 출근 전 20분 같은 조각 시간입니다. 이때 프로젝트 상태가 선명하지 않으면 그 시간은 세팅 기억을 복구하는 데 사라집니다.
한 개발자 글은 사이드 프로젝트의 적을 컨텍스트 스위칭으로 설명합니다. 알림 하나, 피드 하나, 대시보드 확인 하나가 작업 세션을 끊고, 다시 집중 상태로 돌아오는 데 큰 비용이 든다는 이야기입니다. 이 숫자를 엄밀한 법칙처럼 받아들일 필요는 없지만, 체감은 분명합니다. 사이드 프로젝트 시간은 원래 짧기 때문에 한 번의 이탈이 하루 작업 전체를 날릴 수 있습니다.
그래서 “더 열심히 해야지”보다 중요한 질문은 이것입니다.
- 프로젝트를 다시 열었을 때 3분 안에 현재 상태가 보이는가?
- 다음 행동이 15~30분 안에 끝낼 수 있을 만큼 작게 잘려 있는가?
- 지난번에 막힌 이유가 기록되어 있는가?
- 성공 여부와 별개로 오늘 한 작은 진전이 보이는가?
- 일주일 쉬어도 다시 이어받을 수 있는 요약이 있는가?
이 질문에 답하지 못하면 프로젝트는 의지력이 약해서가 아니라 운영 정보가 사라져서 멈춥니다.
퀘스트는 TODO보다 작고, 체크리스트보다 서사가 있다
SideQuick이 “task”가 아니라 “quest”라는 단어를 쓰는 것도 재밌습니다. 퀘스트는 단순 할 일이 아니라 다음 단계가 열리는 구조입니다. 사이드 프로젝트에서는 이 차이가 큽니다. TODO 목록은 병렬로 늘어날수록 부담이 됩니다. 반면 퀘스트는 “지금 열려 있는 다음 문”을 보여줍니다.
예를 들어 “개인 RSS 리더 만들기”라는 프로젝트가 있다고 합시다. TODO 방식은 이렇게 흐르기 쉽습니다.
- DB 설계
- 피드 파서
- UI
- 로그인
- 배포
- 모바일 대응
- 추천 알고리즘
이 목록은 맞지만, 다시 열고 싶게 만들지는 않습니다. 퀘스트 방식은 더 작고 순차적이어야 합니다.
- 샘플 RSS 3개를 fixtures로 저장한다.
- 첫 번째 피드에서 title/link/pubDate만 파싱한다.
- 실패한 XML 1개를 에러 케이스로 남긴다.
- SQLite에
feeds,items두 테이블만 만든다. - CLI로 최신 10개 글을 출력한다.
- 그 다음에야 아주 못생긴 HTML 목록을 만든다.
이렇게 하면 오늘 30분짜리 행동이 보입니다. 중요한 건 완벽한 WBS가 아니라, 다시 들어왔을 때 “이번 판에서 깨야 할 것”이 보여야 한다는 점입니다.
스트릭은 동기부여가 아니라 상태 모니터링이다
스트릭은 조심해서 써야 합니다. 잘못 쓰면 “어제 못 했으니 망했다”는 죄책감 도구가 됩니다. 하지만 SideQuick 설명처럼 공개 스코어보드가 아니라 개인용 기록으로 쓰면 의미가 있습니다. 스트릭은 나를 평가하는 점수가 아니라 프로젝트가 내 생활 리듬 안에 살아 있는지 알려주는 상태 신호입니다.
좋은 스트릭 기준은 낮아야 합니다. “매일 2시간 개발” 같은 기준은 금방 실패합니다. 대신 아래처럼 잡는 편이 현실적입니다.
- 10분이라도 프로젝트를 열었다.
- 다음 행동 하나를 완료했다.
- 코드를 못 짜도 막힌 이유를 한 줄 남겼다.
- 오늘 못 할 것 같으면 내일의 첫 행동만 적었다.
Harvard Business Review의 “The Power of Small Wins”가 말하는 방향도 비슷합니다. 창의적 지식노동에서 사람을 움직이는 중요한 신호는 거창한 보상이 아니라 “내가 앞으로 가고 있다”는 감각입니다. 사이드 프로젝트는 외부 보상이 늦게 오기 때문에, 작은 진전을 눈에 보이게 만드는 장치가 더 중요합니다.
재진입 요약은 개인 프로젝트의 README.now다
SideQuick의 가장 실용적인 기능은 재진입 요약입니다. AI가 멈춘 지점을 요약해준다는 말은 단순히 멋진 기능처럼 들리지만, 실제로는 사이드 프로젝트의 생존 장치에 가깝습니다. 프로젝트가 죽는 순간은 보통 에러가 터진 순간이 아니라 “다음에 뭐 해야 하지?”를 떠올리기 귀찮아지는 순간입니다.
내가 직접 구현한다면 프로젝트마다 NOW.md 또는 status.md를 두고 아래 6줄만 유지할 겁니다.
# NOW
- Goal: 이 프로젝트가 끝났다고 말할 수 있는 기준
- Current state: 지금 동작하는 것 / 안 되는 것
- Last changed: 마지막으로 건드린 파일과 이유
- Next 15 minutes: 바로 시작할 가장 작은 행동
- Blocker: 막힌 것, 결정해야 할 것
- Re-entry note: 일주일 뒤의 내가 읽을 요약
AI 요약은 이 파일을 업데이트하는 데 잘 맞습니다. 다만 AI에게 “멋진 계획 짜줘”라고 맡기면 계획이 부풀어 오릅니다. 더 좋은 프롬프트는 “현재 diff, README, TODO를 보고 다음 15분 행동 3개와 막힌 이유만 요약해줘”에 가깝습니다. 완주에 필요한 건 웅장한 로드맵보다 다음 커밋을 시작하게 만드는 문맥입니다.
로컬 우선과 BYOK가 중요한 이유
SideQuick이 계정 없이 로컬 저장을 택한 것도 방향성이 좋습니다. Ink & Switch의 local-first 글이 말하듯, 창작물과 작업 기록은 사용자가 오래 소유해야 할 데이터입니다. 사이드 프로젝트의 퀘스트, 메모, 실패 기록, 다음 행동은 단순 앱 데이터가 아니라 나중에 다시 꺼낼 수 있는 개인 작업 자산입니다.
클라우드 TODO 앱에만 이 기록이 있으면 서비스가 바뀌거나, 계정이 꼬이거나, 내보내기가 불편할 때 흐름이 끊길 수 있습니다. 반대로 로컬 파일이나 로컬 DB에 있으면 백업, 버전 관리, 검색, 마이그레이션이 쉬워집니다. 특히 개발자라면 Git 레포 안의 docs/progress.md, NOW.md, .project/quests.json 같은 형태가 더 오래 갑니다.
BYOK도 같은 맥락입니다. 내 프로젝트 내용을 AI가 읽어야 한다면 어떤 모델로, 어떤 경로로, 어떤 키를 써서 보낼지 사용자가 통제하는 편이 낫습니다. SideQuick이 OpenAI 호환 커스텀 엔드포인트를 지원한다는 점은 로컬 모델, 사내 프록시, OpenRouter, LM Studio 같은 다양한 경로를 열어둔다는 뜻이라 실험 여지가 큽니다.
다만 로컬 우선은 백업 책임도 사용자에게 옵니다. 정말 중요한 프로젝트 운영 기록이라면 아래 세 가지는 챙겨야 합니다.
- 데이터 저장 위치를 확인한다.
- 자동 백업 또는 Git sync 경로를 만든다.
- AI 키가 평문으로 저장되는지, OS keychain을 쓰는지 확인한다.
도구보다 중요한 7일 실험 루틴
SideQuick을 쓰든, Notion/Obsidian/GitHub Projects로 직접 만들든, 핵심은 루틴입니다. 아래 7일 실험은 도구 없이도 바로 해볼 수 있습니다.
Day 1: 프로젝트 하나만 고른다
미완성 프로젝트가 많을수록 하나만 고르는 게 중요합니다. 기준은 “완성하면 가장 아까움이 줄어드는 것”입니다. 돈이 될 프로젝트일 수도 있고, 블로그 글일 수도 있고, 개인 자동화일 수도 있습니다.
Day 2: 완료 기준을 한 문장으로 쓴다
“앱 완성”은 완료 기준이 아닙니다. “내가 매일 쓰는 RSS 10개를 등록하고, 새 글 목록을 로컬에서 볼 수 있다”처럼 관찰 가능한 기준으로 씁니다.
Day 3: 퀘스트를 30~90분 단위로 자른다
하루에 끝낼 수 없는 퀘스트는 너무 큽니다. 퀘스트 이름은 동사로 시작합니다. “DB”가 아니라 “items 테이블을 만들고 샘플 3개를 insert한다”가 좋습니다.
Day 4: 작업 종료 시 재진입 요약을 남긴다
커밋을 못 해도 됩니다. 대신 Next 15 minutes를 반드시 적습니다. 다음번의 내가 바로 시작할 수 있어야 합니다.
Day 5: 스트릭 기준을 낮춘다
10분 열어보기, 에러 로그 한 줄 정리, TODO 하나 삭제 같은 것도 진전으로 인정합니다. 목적은 자기기만이 아니라 프로젝트를 계속 메모리에 올려두는 것입니다.
Day 6: AI에게 계획이 아니라 요약을 시킨다
AI에게 “다음 큰 기능”을 묻기보다 “현재 상태와 다음 작은 행동을 요약해줘”라고 시킵니다. 과잉 계획을 막는 게 중요합니다.
Day 7: 계속할지 버릴지 결정한다
일주일 뒤에도 재미가 없고 완료 기준도 애매하다면 버려도 됩니다. 대신 버릴 때도 이유를 남깁니다. “관심 없음”, “시장성 낮음”, “기술 검증 완료”, “다른 프로젝트와 합치기”처럼 남겨두면 다음 아이디어의 품질이 좋아집니다.
제품 아이디어로 보면 더 재밌는 지점
SideQuick 같은 도구는 개인 생산성 앱이지만, 더 크게 보면 “작업 기억을 제품화하는 흐름”입니다. 최근 AI 도구는 코드를 작성하거나 문서를 요약하는 데 집중했지만, 실제 사람의 문제는 작업 사이를 건너뛰는 데 있습니다. 어제의 나와 오늘의 나, 회사 일과 개인 프로젝트, 코드와 노트, 계획과 실행 사이의 컨텍스트를 이어주는 도구가 필요합니다.
이 관점에서 다음 기능들이 붙으면 더 강력해질 수 있습니다.
- Git diff 기반 자동 재진입 요약
- 마지막 실패 로그와 다음 실험 자동 연결
- 프로젝트별 “abandonment risk” 신호
- 완료 기준이 없는 퀘스트 감지
- 너무 큰 퀘스트 자동 분할
- 로컬 파일 export/import
- GitHub issue, Linear, Obsidian과의 단방향 sync
- 로컬 모델을 이용한 완전 오프라인 요약
반대로 주의할 점도 있습니다. 생산성 앱은 쉽게 “일하는 느낌”을 줍니다. 퀘스트를 예쁘게 정리하고, 레벨을 올리고, 아이콘을 고르는 데 시간을 쓰면 실제 프로젝트는 그대로입니다. 좋은 Side Project Operating System은 관리 시간을 줄이고 실행 시간을 늘려야 합니다.
내 결론
SideQuick이 재밌는 이유는 사이드 프로젝트를 “의지력으로 버티는 취미”가 아니라 “재진입 비용을 낮춰야 하는 운영 문제”로 보기 때문입니다. 개발자는 시작을 잘합니다. 레포 만들고, 세팅하고, 첫 화면 띄우는 건 빠릅니다. 하지만 완주는 매일의 작은 재진입에서 갈립니다.
나중에 이 글을 다시 볼 때 하나만 가져가면 됩니다.
사이드 프로젝트를 살리는 최소 단위는 거대한 로드맵이 아니라, 일주일 뒤의 내가 3분 안에 이해할 수 있는 현재 상태와 15분 안에 시작할 수 있는 다음 행동이다.
SideQuick을 써봐도 좋고, 직접 NOW.md 하나로 흉내 내도 좋습니다. 핵심은 프로젝트를 “언젠가 해야 할 것”으로 두지 않고, 다시 열 수 있는 상태로 매번 닫는 것입니다.
💬 댓글