macOS 앱 두 개, 4개월 운영 회고

얼마 전에 이름값을 떠나 바닥으로를 적었다. 큰 회사를 노리는 대신 영역을 넓혀 혼자 설 수 있는 개발자가 되는 쪽을 골랐다고 정리한 글이다. 커리어는 백엔드 개발자로 시작했지만 포지션 이름이 조금씩 바뀌어왔다. 누구는 '프로덕트 엔지니어'라 부르고, 누구는 'AI Engineer'라 부른다. 'harness engineer'나 'FDE' 같은 단어는 뭔지 몰라서 찾아봤다. 내 머릿속에서는 '복잡성 관리자'라는 단어가 떠올랐다. 3년 뒤에 내 타이틀이 무엇일지는 알 수 없다.

정해진 게 없는 시대다 보니, 개발자로서 영역을 넓히기로 한 결정이 지금 와서 보니 꽤 괜찮은 선택이었다. 다음 변화는 더 빠를지도 모른다. 풀타임 잡이 있어도 당장 내일 '구조적 실업'을 맞이할지 모른다. 그래서 여가 시간에도 개발과 관련된 무언가를 계속 손에 쥐고 있어야 했고, 이왕이면 인디 서비스를 만들어보기로 했다.

devglow & todoglow를 대표 사례로 소개하고자 한다. 보조 수입원이 되면 좋고, 그게 아니더라도 내 영역을 넓히고 지식을 다시 두텁게 만든다는 의미가 있다. 굳이 Tauri를 골라 macOS 앱 두 개에 도전한 이유가 거기에 있다. 두 앱을 4개월 운영한 기록을 남긴다.

devglow & todoglow 비긴즈

두 macOS 메뉴바 앱이다. devglow(개발 프로젝트의 상태, 그러니까 프로세스, 로그, MCP 연결을 메뉴바에서 한눈에 보는 앱)와 todoglow(메뉴바에서 바로 todo를 만들고 닫는 단축키 중심 앱). 내 안에선 두 앱을 묶어 'Glow Suite'라 부른다. (실제로 둘을 묶어 할인 번들로도 판다.) 모노레포로 묶인 정도는 아니고, 디자인 톤과 컴포넌트 패턴을 서로 참고하는 묶음이다.

devglow는 daily pain에서 시작했다. Claude Code, Cursor 같은 AI 코딩 에이전트를 여러 세션 동시에 굴리다 보면, 에이전트들이 제멋대로 띄운 프로세스가 이미 떠 있던 서버 포트와 충돌하면서 흐름이 꼬였다. PortKiller 같은 인디 앱을 봤는데 미관이 마음에 들지 않아, 내가 쓸 용도로 직접 만들어보자는 게 시작이었다. 개발할 때 프로세스 상태와 로그를 자주 들여다보는 편이라, 이왕 만드는 김에 로그 뷰어도 같이 넣었다. (이 결은 devglow 1.5 — 사이드바와 분할 패널에서도 한 번 적어둔 적이 있다.)

todoglow는 우연히 파생됐다. 여친이 devglow의 테마 톤을 보더니 영롱하다, 개발자만 쓰는 거냐, 아깝다며 아쉬워했다. devglow MVP를 마무리하던 즈음이라, 개발 문서를 따로 정리해서 todoglow MVP를 만들었다. 머릿속에서만 그리던 UI를 말로 옮기는 게 쉽지 않아, Claude Code 세션의 70% 정도는 UI 다듬는 데 썼다.

devglow에 MCP를 붙이는 건 수순에 가까웠다. AI 코딩 에이전트를 쓰는 세션은 거의 매번 로컬 서버 한두 개를 같이 띄워둔다. Next.js dev 서버, API 같은 것들. 그 서버들의 기동/중단/포트/로그를 에이전트가 직접 다룰 수 있어야 요즘 워크플로우에 맞고, 그 진입로가 MCP다. devglow는 이미 그 서버들을 관리하고 있었으니, 남은 건 에이전트에게 문을 열어주는 것뿐이었다.

todoglow는 사정이 좀 달랐다. 단축키로 빠르게 들어와 한 줄 적고 닫는, 사람 손에 정확히 잡히는 동작인데, 거기에 에이전트를 들이는 게 옳은지 한참 망설였다. 요즘 내 작업 방식은 AI와의 대화 세션 여러 개를 동시에 굴리는 식이다. 화구 여러 개에 냄비를 올려두고 돌아가며 젓는 요리사처럼, 세션마다 서로 다른 단계에 가 있다. 그럼에도 사람의 집중은 원칙적으로 하나다. 한 사람이 두 가지를 동시에 '진행 중'일 수는 없다. 그래서 고심 끝에 '진행 중' todo를 1개로 제한한 건 유지했다. 사람의 정신 모델에 그게 더 맞다고 봤기 때문이다. 대신 사용자가 직접 적은 todo와 에이전트가 적은 작업을 분리했다. 에이전트가 적은 건 'AGENTS' 패널에 따로 쌓이고, 사용자가 그 중 하나를 '진행 중' 자리로 올릴 수 있다(promote).

출시 직후 — 수요가 있구나

2026년 2월 베타를 풀었을 때, 처음 계획은 그 베타를 몇 달 굴리는 거였다. 수요는 천천히 묻고 천천히 답을 받아도 된다고 봤다. 라이선스 모델을 어떻게 할지 한창 고민 중이었다. (LemonSqueezy를 유력하게 고려했지만 심사에서 거절당했고 Polar¹에서 받아주었다.)

2026년 2월 3일, 출시 직후 Threads에 첫 포스트를 올렸다. '100만개 todo앱 중 제 맘에 드는 게 없어서 만들었어요. 모바일보다 Mac 앞에 앉아있는 시간이 긴 분, 키보드 쫄깃한 느낌을 간직하려고 애썼습니다.' 24시간 사이 3천 명 가까이가 페이지에 들어왔다. 그 중 OS 비율을 보니 macOS 유저가 1/10 정도. 단순 트래픽이 아니라 실제 타깃 청중이 그 안에 300명 정도 들어와 있다는 뜻으로 읽었다.

지표만큼 댓글 반응도 또렷했다. '맥에서 상시 플로팅 되는 투두앱, 딱 원하던 앱', 'Raycast focus 모드 상위호환 느낌' 같은 라인이 올라왔다. 개발자가 만든 도구를 같은 개발자나 디자이너가 알아본다는 게 좋았다. 며칠 뒤 올린 첫 r/macapps 포스트 댓글에서도 비슷한 반응이 따라왔다. 모르는 사람들이 자기 워크플로우 안에 비슷한 도구를 기다리고 있었던 셈이다.

그 과정에서 장문의 피드백을 보내주신 분들도 기억난다. MVP라는 게 얼마나 허술했는지 댓글과 메일에서 또렷이 드러났다. 그래도 굳이 시간 들여 적어 보내준다는 것 자체가 가장 정직한 응답이었다.

계획을 조금 빠르게 가도 되는 시장이라는 판단이 따라왔고, 베타를 무료로만 길게 끌어가는 흐름을 접고 라이선스 모델 도입을 서둘렀다.

앞서 말한 그 문, 에이전트에게 devglow를 열어주는 일에도 이 무렵 손을 댔다. 출시 직후 1개월차 첫 주에 AI 에이전트가 devglow로 프로세스를 관리하는 코드가 들어갔고, 그 며칠 전에는 GUI 앱이 셸 env를 상속받게 만드는 작업도 끝냈다. AI 에이전트가 사람 손에 잡힌 셸과 같은 환경에서 일해야 진짜로 동작한다는 디테일까지 챙기고 싶었다.

MCP는 내가 처음 다뤄보는 프로토콜이었다. 다만 따로 공부하고 들어가지 않았다. 쓸 자리가 먼저 떠올랐고, 거기에 필요한 것들을 그때그때 익혀가며 붙였다.

2개월차의 리디자인, 그리고 3개월차

2개월차 후반엔 devglow를 사이드바 + 분할 패널 구조로 갈아엎었다. 그전에는 프로세스가 그냥 평탄한 리스트였다. 그 즈음 cmux를 직접 써보며, 개발자들이 이미 익숙하게 쓰고 있는 멘탈 모델(tmux, Ghostty, 노트 앱들이 다 그런 식)이 사이드바와 분할 패널이라는 걸 잡았다. 내가 만든 도구가 조작 측면에서는 익숙하게 느껴졌으면 좋겠다 싶었다. 같은 흐름으로 카테고리 이름도 두 번 옮겼다. 'Dev Server Manager' → 'Process Manager' → 'tmux/cmux 옆에서 같이 쓰는 도구'.

같은 기간 todoglow도 쉬지 않고 올라갔다. v1.6에서 v1.8까지 minor 버전을 거의 매주 찍었다. 커맨드 모드로 애플 리마인더에 바로 보내는 기능, 아카이브에 월별 통계를 영수증 카드로 보여주는 화면 같은 것들.

카운트다운 타이머도 이때 넣었다. 뽀모도로 앱이 수십 개 있지만 대부분 남은 시간을 큰 숫자로 들이민다. 나는 그 숫자가 오히려 신경 쓰여서, 시계를 지운 타이머를 만들었다. 남은 시간은 숫자 대신 은은한 격자 패턴이 차오르는 걸로만 보여주고, 끝나면 알림이 온다. 내가 그렇게 쓰고 싶어서 그렇게 만들었다.

기술적으로 더 어려운 건 devglow 쪽이 많았다. 프로세스 관리, 셸 env 상속, 로그 스트리밍, MCP까지. 그런데 매일 내가 직접 쓰면서 가장 애착이 갔던 건 todoglow였고, 손이 자주 간 쪽도 그래서 todoglow였다.

그리고 3개월차에 데이터가 멈췄다. mcp_connect는 6건. 신규 트라이얼은 4건. 노트에 'DG 파이프라인이 말랐다'고 적었다. 그 즈음 우선순위가 높은 다른 일들이 많아 데이터를 들여다보는 시간도 함께 줄었다. 한 달 반 정도, devglow의 신규 기능 작업은 거의 손을 놓고 있었다. CS 응답은 그 사이에도 계속 이어졌다.

4개월차 — 6주 뒤 데이터

4개월차 말에 다시 데이터를 들여다봤다. 3개월차 신규 트라이얼 4건이 4개월차엔 14건, MAU 15에서 28, MCP 연결 이벤트는 6건에서 55건. devglow 자체 커밋도 3개월차 6개에서 4개월차 60개. 코드에 빠져 있느라 데이터를 한참 안 봤는데, 그 사이 흐름이 한 번 바뀌어 있었다.

MCP 연결 이벤트가 6 → 55로 뛴 것 자체엔 큰 의미를 두지 않는다. 내가 초기 버전에 애널리틱스를 제대로 안 붙여둔 탓도 있고, CS 인입에서 내가 직접 MCP 사용을 안내한 케이스도 두 명 이상 있었기 때문이다. 정량 신호만 봐서는 이런 인입 경로가 흐름에 잡히지 않는다.

그 안내가 어떻게 나갔는지 한 사례를 적어둔다. devglow를 쓰던 한 시니어 PM과 4개월차 초부터 메일을 몇 차례 주고받았다. 로그 영역에서 selection이 자꾸 풀린다거나, copy/download 동선이 어렵다거나, search/filter가 좀 더 강했으면 좋겠다는 요청들이었다. 받아서 v1.5.13/v1.5.16에 단계별로 업데이트로 내보내면서, 답장 말미에 "로그를 직접 들여다보는 흐름이라면 devglow에 MCP server가 떠 있으니 Claude Code나 Cursor에서 바로 다룰 수도 있다. '로컬 서버 좀 실행해줘'라고 하면 에이전트가 직접 띄우고, '방금 그 서버 로그 읽고 에러 있으면 알려줘'라고 하면 바로 읽는다" 식으로 슬쩍 던져봤다. 요청들을 받아보니 MCP를 곁들이면 자연히 풀리겠다 싶어서였다.

며칠 뒤에 답장이 왔다. "The MCP is AN ABSOLUTE GAMECHANGER!! The number of times I've had to create custom logging, filter for it select, copy, paste – back and forth. That's just gone!" 내가 "이게 게임체인저"라고 적는 것과 사용자가 직접 그렇게 적어 보내준 것은 다르다.

여기서 3개월차의 판단을 다시 봤다. 시기 상조가 아니라 자연 침투에 시간이 걸린다는 쪽이었다. AI 코딩 에이전트를 쓰는 사람과 거기에 MCP server를 직접 설치하고 설정해본 사람 사이에 갭이 있고, 그 갭을 넘어온 사람이 천천히 쌓이는 중이라는 게 더 정확한 그림 같다.

타깃 가설도 같이 재조정됐다. devglow는 처음에 로그를 직접 들여다보는 전통적 개발 습관을 가진 개발자들을 머릿속 타깃으로 잡고 만들었다. 그런데 정작 이메일로 문의나 피드백을 적극적으로 보내주는 유저들 중엔 개발 백그라운드가 아닌 사람들도 꽤 있다. (흔히 '바이브 코더'라고 부르는 쪽인데, 나는 이 단어가 정확한 호명이라 생각하지 않아 가급적 안 쓰는 편이다.) 코드를 직접 다루지 않더라도 프로세스가 어떻게 살아 움직이는지 보고 싶은 수요는 따로 존재한다. 이런 건 머리로 미리 잡히지 않고, 제품을 사람들 손에 쥐여주고 한참 지나서야 보였다.

todoglow 쪽엔 4개월차에 큰 작업을 하나 더 얹었다. 내가 맥 두 대를 오가며 쓰다 보니 sync가 절실해졌다. 모바일에서 쓸 수 있느냐는 질문도 사용자로부터 띄엄띄엄 따라왔다. 그래서 multi-device cloud sync를 v1.9에 담아 배포했다. 3개월차에 devglow 데이터가 말랐고 4개월차에 todoglow에 다시 손을 댄 게 같은 두 달 안에 일어났다.

숫자도 같이 정리해두면, todoglow는 누적 86 트라이얼에 20명이 라이선스(23.3%), 누적 디바이스 321개. devglow는 누적 48 트라이얼, 14명 라이선스(29.2%), 누적 디바이스 85개.

두 앱 모두 쓰는 유저가 22명. 내가 두 앱을 다 쓰니까 cross-sell이 일어나길 바라긴 했지만 기대가 크진 않았다. devglow를 주변 개발자 지인들에게 보여줬을 때 큰 반응이 없었기 때문이다. 그런데 막상 데이터를 보니 은근한 스테디셀러 역할은 하고 있었다.

운영하며 — 결정들

앱을 운영하는 건 결정의 연속이었다. 4개월 동안 두 앱 합쳐서 크고 작은 결정을 100개쯤 내렸다. 가격, trial 길이, 마케팅 채널, CS 응답 사이클, 기술 스택 안에서 무엇을 신뢰하고 무엇을 갈아엎을지의 판단들이다. 어느 것도 한 번에 정해지지 않았다.

1. 기술 판단 — 어떤 추상화를 안 믿어야 하나

출시 직후 두 앱 모두 Tauri 내장 자동 업데이트 플러그인을 폐기하고 Sparkle² 프레임워크로 갈아엎었다. macOS /Applications에 설치된 앱은 admin 권한 타이밍 문제로 내장 업데이터가 silent failure를 일으켰다. 다운로드는 성공하지만 실제 앱 교체가 안 됐다.

Sparkle에 닿은 건 내가 한 명의 유저였기 때문이다. 평소 Fork(git 클라이언트)를 자주 쓰는데, 업데이트 흐름이 깔끔하다는 인상이 있었다. "이거 무슨 라이브러리 쓰는 거지?" 찾아보니 Sparkle이었고, 그 방식을 내 앱에도 적용해보면 어떨까 싶어 손을 댔다. (많은 macOS 앱이 이걸 쓰고 있다는 걸 그제야 알았다.)

인디 풀스택은 어떤 추상화를 신뢰하고 어떤 추상화를 직접 만질지를 매번 결정해야 한다. 두 앱 동시에 같은 날 갈아엎었다.

2. Pricing — 가격이 헷갈렸다

처음부터 유료 의도였다. 무료로 시작하면 무료가 계속 무료가 되기 쉽다는 걸 알았다. 베타 유저 23명은 grandfathered로 처리해 평생 무료로 두었다. '베타 풀었을 때 들어와 준 사람들은 유료화로 가도 끌어안고 싶다' — 비즈니스적으로 매출 못 받는 결정이었지만 그게 맞다고 느껴졌다. 무료 쿠폰 비중이 4개월 합산 57%였다.

가격 모델부터 흔들렸다. 한 번은 구독제까지 시도했다가 일회성 구매로 되돌렸다.

trial 길이도 마찬가지였다. 맨 처음엔 trial 없이 바로 결제를 요구했다가 반발을 샀고, 그 다음 7일을 줬다. 그러다 todoglow에 월별 통계 화면을 넣고 나서 14일로 두 배 늘렸다. 통계가 쌓이는 걸 직접 보려면 일주일로는 짧고, 그 맛을 봐야 결제로 이어진다고 판단해서였다.

한국에서는 잘 팔리지 않았다. 물론 의외는 아니었다. (애초에 영어로만 만든 것도 이 때문이다.) 결제는 미국뿐만 아니라 유럽에서도 들어왔다. 어디서 누가 산다는 게 미리 그려지지 않는 시장이다. Polar 누적 매출은 4개월에 $451, 주문 90건, 결제 전환율 25.6%. 큰 숫자는 아니어도 라이선스 모델이 돌아가고는 있다는 신호였다.

3. todoglow 슬롯별 테마 — 사용자 요청에 내 호기심이 얹힌 자리

한 todoglow 유저가 슬롯별로 색상/테마를 다르게 할 수 있냐는 요청을 보내왔다. todoglow는 ⌘1~⌘5 다섯 슬롯이 있는데(⌘1은 All view, ⌘2~⌘5는 분리된 리스트), 그때까지 테마는 전역 단 하나였다. 모든 슬롯이 같은 accent 색을 공유하는 구조였다.

듣고 보니 슬롯마다 다른 색이면 시각적으로 분리되어 더 재밌겠다 싶었다. 다른 todo 앱에서 잘 본 적 없는 방식이기도 했고. 다만 슬롯마다 색을 직접 고르게 할지, 아니면 자동으로 서로 다른 색이 배정되게 할지가 갈리는 질문이라, 답장에서 두 옵션을 같이 물어봤다.

기술적으로는 테마를 전역 단일 → 슬롯별 매핑으로 리팩토링하는 작업이 따라왔다. global theme이냐 slot theme이냐를 'scope'로 잡고 코드 전반에 일관되게 적용하는 흐름이었다. 슬롯 컨텍스트에 속한 오버레이는 main scope로 통일하고, archive footer 같은 곳도 슬롯 테마를 따라가게 정리했다. Settings → Display 탭에 슬롯별 테마 picker를 추가해 업데이트로 내보냈다. 사용자에겐 슬쩍 던진 요청이었을지 몰라도, 생각할수록 괜찮은 아이디어라 며칠을 머릿속으로 상상코딩하다 날 잡고 구현했다.

4. 그 외 — 마케팅, CS, 그 사이의 자잘한 결정들

마케팅 채널은 Reddit, Threads, 쇼츠/틱톡까지 돌려봤지만 한 채널이 길게 가는지는 아직 모른다. Reddit은 의외로 fit이 있었다. r/macapps 첫 포스트가 예상보다 반응이 좋아서 devglow의 핵심 외부 채널이 자연히 거기로 모였다. Threads는 한국에서 움직임이 있었지만 결제로 이어지지 않았다. 청중과 결제 시장이 따로 있었다. Product Hunt는 hunter 섭외와 타이밍의 메타 게임이라는 걸 모르고 들어갔다가, 런칭 다음 날부터 PH 뱃지를 떼어내기 시작했다. 솔직히 두 달 동안 내가 뭘 하고 있는 건지 잘 모르는 채로 흘러갔다. 그래서 마케팅은 내 나름의 기한을 정해두고 거기서 끊었다. 그러고 다시 빌더 모드로 돌아왔는데, 그게 너무너무 행복했다. (그만큼 마케팅이 힘들었다는 뜻 ㅋㅋ)

CS 쪽에서는 한 프랑스 유저가 AZERTY 키보드를 쓰는데 단축키 힌트가 자기 자판과 안 맞는다는 제보를 보냈다. todoglow는 키보드 중심 앱이라, 단축키를 글자가 아니라 물리적 키 위치 기준으로 설계해뒀다. 그래서 동작 자체는 어느 자판에서도 멀쩡한데, 화면에 표시되는 힌트가 QWERTY 글자로 박혀 있어서 AZERTY 사용자 눈엔 엉뚱한 키처럼 보였다. 컨셉을 지키려다 생긴 사각지대였던 셈이다. 며칠 안에 QWERTY/AZERTY/QWERTZ 레이아웃 선택을 settings에 더해서, 자기 자판을 고르면 힌트가 맞게 보이도록 내보냈다. 내가 평생 만져볼 일 없었던 자판 문제였다.

운영 모드, 그리고 다음

풀타임 잡을 하면서 이런 서비스를 운영하는 건 쉽지 않았다. 퇴근하고 나서 에러를 고치고 기능을 더하는 일이다. 출시하고 한 달 반쯤은 마케팅에도 신경을 썼는데, 그게 참 어려웠다. 그 뒤로는 회사 일과 개인 일에 밀려 손이 덜 닿았다. 그런데도 앱은 혼자 작은 사이클을 그리고 있었다. 어느 날은 내가 잠든 밤에 영국에서 누가 사 갔고, 최근 주말엔 중국에서 첫 결제가 들어왔다.

인디 개발자로 앱을 내는 건 아티스트가 앨범을 내는 것과 비슷한 데가 있다. 내가 만든 것에 사람들이 어떻게 반응하는지 보고, 한 줄 한 줄 피드백을 받아보는 게 재미있다. 나와 같은 걸 원했던, 그것도 돈을 낼 만큼 원했던 사람들이 세계 각지에 있다. 이 맛에 또 새 앨범을 내고 싶어진다.