직접 만든
서비스와 도구

듀데잇

고정지출과 소비기한을 한 화면에서

왜 만들었나

안 쓰는 구독료는 매달 빠져나가고, 사 둔 식품이나 화장품은 기한을 넘겨서 버립니다. 둘 다 날짜를 놓쳐서 생기는 손해인데, 가계부는 이미 나간 돈만 기록하고 냉장고 앱은 식품만 봅니다. 저는 이 둘이 같은 문제라고 생각했습니다. 아직 오지 않은 날짜를 한곳에서 관리하면 둘 다 막을 수 있을 것 같아서 만들었습니다.

무엇을 하는 서비스인가

• 구독·통신비·보험료·할부 같은 반복 지출을 등록하면 이번 달 예상 지출과 다음 결제일을 함께 보여줍니다. 매주·매월·매년 주기와 여러 통화를 지원합니다.
• 식품·의약품·화장품의 소비기한을 냉장·냉동·실온 등 보관 장소별로 정리합니다. 라벨을 카메라로 비추면 날짜 표기를 인식해 입력을 대신합니다.
• 알림은 결제일이나 만료일 당일이 아니라, 아직 손쓸 수 있을 때 먼저 옵니다. 알림에서 바로 '확인'이나 '폐기'를 누를 수 있습니다.
• 홈 화면 위젯으로 가까운 일정을 앱을 열지 않고 확인합니다. 달력 뷰에서 한 달 치를 한 번에 봅니다.
• 월별 리포트로 버린 금액과 카테고리별 추이를 돌아봅니다. 해지로 아낀 금액도 함께 계산합니다.
• 회원가입과 로그인이 없습니다. 데이터는 기기와 사용자 본인의 iCloud에만 저장되고, 카메라로 찍은 이미지는 기기 밖으로 나가지 않습니다.

계속 다듬고 있는 것

• ◆반복 지출에서 '이번만 건너뛰기'와 '규칙 자체 바꾸기'를 어떻게 구분해서 보여줄지. 사용자에게는 다른 동작인데 화면에서는 비슷하게 생겼습니다.
• ◆소비기한 인식 정확도. 라벨 인쇄 상태가 제각각이라 인식에 실패하는 경우가 아직 있어서, 실패했을 때 직접 입력으로 넘어가는 흐름을 다듬고 있습니다.
• ◆알림 권한을 거절한 사용자도 앱을 계속 쓸 수 있게 하는 것.

만들면서 시도해 본 것

• ◇SwiftData + CloudKit 자동 동기화. 기기 간 동기화는 프레임워크에 맡기는 대신, 모델 제약과 스키마 배포 절차를 정확히 지켜야 했습니다.
• ◇Vision 프레임워크로 기기 안에서 날짜 표기 인식. 서버로 이미지를 보내지 않습니다.
• ◇WidgetKit 위젯과 알림 스케줄이 앱 내부 상태와 어긋나지 않게 유지하기

개발 핸드북

웹 개발 기초를 손안에서 다시 훑는 레퍼런스

왜 만들었나

검색으로 찾은 지식은 조각조각 흩어져 있습니다. HTML 기초를 다시 볼 때마다 매번 다른 블로그를 열게 되고, 어디까지 봤는지도 남지 않습니다. 순서대로 읽을 수 있고, 읽은 곳이 기억되고, 로그인 없이 바로 열리는 레퍼런스가 있었으면 해서 만들었습니다.

무엇을 하는 서비스인가

• HTML·CSS·JavaScript·TypeScript 등 도메인별로 순서가 있는 문서를 제공합니다. 기본 개념부터 차례대로 읽어 나갈 수 있습니다.
• CDN, Deadlock, DNS처럼 자주 마주치지만 매번 다시 찾게 되는 용어를 사전으로 따로 정리했습니다.
• 문서와 용어를 한 번에 검색합니다. 읽은 문서는 진도로 남고, 자주 보는 것은 북마크로 모입니다.
• 코드 구문 강조와 예상 읽는 시간, 다크·라이트 테마를 지원합니다. 회원가입이나 로그인이 없습니다.
• 모바일 앱과 웹사이트가 같은 콘텐츠 저장소를 봐서, 문서는 한 곳에서만 고칩니다.

계속 다듬고 있는 것

• ◆콘텐츠를 앱에 내장할지, 받아 올지. 내장하면 오프라인에서도 완벽하게 되지만 문서를 고칠 때마다 앱을 다시 내야 합니다.
• ◆문서 사이의 선행 관계를 그래프로 보여주는 화면. 보기에는 그럴듯한데 실제로 쓸모 있게 만드는 데까지는 아직 거리가 있습니다.
• ◆'기초'의 범위. 넓히면 끝이 없고, 좁히면 볼 이유가 없습니다.

만들면서 시도해 본 것

• ◇콘텐츠 저장소를 앱과 웹이 같이 쓰는 구조. 문서는 한 곳에서만 관리합니다.
• ◇expo-sqlite + Drizzle로 읽기 상태와 북마크를 앱 안에 저장하고, 콘텐츠와는 따로 관리
• ◇d3-force로 문서 간 선행 관계를 시각화

UXPlan

UI/UX 정책을 눌러 보면서 비교하는 도구

왜 만들었나

기획, 디자인, 개발이 UI 정책을 정할 때는 보통 노션 표를 보면서 이야기합니다. 그런데 '필터를 바꾸면 페이지를 유지할까' 같은 건 글만 읽어서는 판단이 안 섭니다. 두 경우를 직접 눌러 보면 5초 만에 답이 나옵니다. 그래서 정책을 표로 읽는 대신 눌러 볼 수 있게 보여주는 도구를 만들었습니다.

무엇을 하는 서비스인가

• 폼·입력, 목록·테이블, 파일 업로드처럼 실무에서 자주 마주치는 UI/UX 정책을 분야별로 정리했습니다.
• 선택지마다 실제로 동작하는 화면을 붙였습니다. 필터를 바꿔보고, 백드롭을 눌러보고, 삭제를 되돌려 볼 수 있습니다.
• 선택지를 번갈아 누르면 같은 화면이 어떻게 달라지는지 바로 보입니다. 얻는 것과 잃는 것은 데모 옆에서 함께 읽습니다.
• 검색·분류 조건은 URL에 남아서 그대로 링크로 공유됩니다. 회의 중에 '이거 보세요' 하고 던질 수 있어야 하니까요.
• 어떤 선택지를 골랐는지는 저장하지 않습니다. 상태, 진행률, 역할별 체크는 이 도구가 할 일이 아니라고 범위를 잘라 뒀습니다.

계속 다듬고 있는 것

• ◆정책 항목이 늘수록 데모 만드는 비용도 같이 늘어납니다. 데모 없이 비교표만으로 충분한 항목을 데이터에서 따로 표시하는 방법을 찾고 있습니다.
• ◆기획 쪽에서 엑셀로 받는 목록의 컬럼 구성이 아직 자주 바뀌어서, 변환 방식을 언제 고정할지 고민 중입니다.

만들면서 시도해 본 것

• ◇Storybook을 컴포넌트 문서 대신 '선택지 카탈로그'로 쓰기. 스토리 하나가 정책 선택지 하나에 해당합니다.
• ◇샌드박스 iframe으로 라우팅 정책처럼 페이지 이동이 필요한 항목까지 미리보기
• ◇스토리를 전부 지워도 앱이 동작하도록 의존 방향을 한쪽으로만 두기

축제 모아

전국 축제를 지도·달력·검색으로 찾는 앱

왜 만들었나

2026 관광데이터 활용 공모전에 내려고 시작했습니다. 지역 축제 정보는 공공데이터로 공개돼 있는데, 사람들이 찾아보기 좋게 정리된 곳은 없었습니다. 데이터는 있는데 바로 쓸 수 있는 형태가 아니라는 점이 출발점이었습니다.

무엇을 하는 서비스인가

• 홈에서 지금 진행 중인 축제와 이번 주 축제를 먼저 보여주고, 지역으로 좁혀 볼 수 있습니다.
• 전국 지도에 축제 위치를 핀으로 표시합니다. 가까운 핀은 묶어서 보이고, 핀을 누르면 기간과 주소를 확인한 뒤 관심 등록이나 길찾기로 이어집니다.
• 월별 달력에서 날짜별로 열리는 축제를 확인합니다.
• 축제 이름이나 지역으로 검색하고, 최근 검색어를 다시 불러올 수 있습니다.
• 관심 축제는 따로 모아 D-day와 함께 봅니다. 상세 화면에서는 행사 기간, 장소, 요금, 홈페이지, 문의처를 확인합니다.
• 회원가입과 위치 권한이 필요 없습니다. 관심 목록과 최근 검색어는 기기 안에만 저장합니다.
• 공공데이터포털의 Tour API 응답을 자체 서버가 받아 저장하고, 앱에는 그 서버를 거쳐 내려줍니다.

계속 다듬고 있는 것

• ◆Android 버전. 스토어에 올릴 화면과 빌드 설정은 만들어 뒀고, 지금은 App Store에만 있습니다. Google Play 등록을 준비하고 있습니다.
• ◆지도 화면. 1.1.0에서 핀을 풍선 모양으로 바꾸고, 가까운 핀을 묶고, 처음 위치로 되돌리는 버튼을 넣었습니다. 핀이 많이 몰리는 지역에서 보기 편한지는 계속 써 보면서 조정하고 있습니다.
• ◆목록은 1시간, 상세는 하루가 지나면 공공 API에서 다시 가져오도록 정했습니다. 일정이 바뀌는 축제를 더 빨리 반영하려면 이 간격을 줄여야 하는데, 공공 API 호출 한도도 있어서 함께 따져야 합니다.

만들면서 시도해 본 것

• ◇Redis 캐시가 느리거나 죽어도 요청이 막히지 않게, 연결 대기열을 끄고 명령 제한 시간을 1초로 두기
• ◇Hono + Zod OpenAPI로 요청 검증과 API 문서(Scalar)를 같은 스키마에서 만들기
• ◇관심 목록과 최근 검색어를 서버 없이 기기 안 SQLite(expo-sqlite + Drizzle)에 저장하기
• ◇상세 화면의 위치는 Kakao 지도를 WebView로 임베드하고, 길찾기는 사용자가 지도 앱을 골라 열게 하기

MailForge

업무 메일을 템플릿으로 저장하고 예약 발송하는 데스크탑 앱

왜 만들었나

업무일지나 보고처럼 같은 형식으로 반복해서 보내는 메일이 있습니다. 매번 서식을 열어 날짜 같은 부분만 고쳐서 보내는 일이 번거로워서, 템플릿을 저장해 두고 정해 둔 시각에 자동으로 보내 주는 프로그램을 만들었습니다. 혼자 쓰려고 만든 개인용 프로그램입니다. Go를 배우는 중이어서 학습을 겸했습니다. AI에게 요구사항을 설명해 가며 코드를 만드는 바이브 코딩으로 작성했고, 코드마다 설명 주석을 달게 해서 읽으면서 따라갔습니다.

무엇을 하는 서비스인가

• TipTap 에디터로 메일 템플릿을 만들고 저장합니다. 본문에 {{변수}}를 넣으면 발송 전에 값을 입력받고, {{date}}는 오늘 날짜로 자동으로 바뀝니다.
• 수신자와 그룹을 저장해 두고 받는 사람, 참조, 숨은참조를 골라 보냅니다.
• SMTP 서버에 직접 연결해서 보내고, 설정 화면에서 연결 테스트를 할 수 있습니다. 보낸 메일 사본은 IMAP으로 웹메일 보낸편지함에도 저장합니다.
• 예약 발송은 앱 안의 스케줄러가 1분마다 확인해서 시각이 된 메일을 보냅니다. 앱이 켜져 있어야 동작합니다.
• 작성 중인 메일은 30초마다 자동 저장되어 다음에 열면 복원됩니다. 발송 기록, 서명 이미지 첨부, 다크 모드도 있습니다.
• 서버가 없습니다. 템플릿과 발송 기록은 내 컴퓨터의 SQLite 파일에만 저장됩니다.

계속 다듬고 있는 것

• ◆앱이 꺼져 있는 동안 시각이 지난 예약은 다음에 앱을 켜면 1분 안에 발송됩니다. 며칠이 지난 메일까지 그대로 보내도 되는지는 정하지 않았습니다.
• ◆발송에 실패한 예약은 발송 기록에 실패로 남고 예약 목록에서는 지워집니다. 자동으로 다시 시도하지 않습니다.
• ◆자동 테스트는 메일 발송과 DB 마이그레이션에만 있습니다. 예약 발송 로직에는 아직 없습니다.

만들면서 시도해 본 것

• ◇Wails로 Go 백엔드와 React 화면을 한 앱으로 묶고, 화면에서 부르는 Go 메서드를 app.go 한 곳에 모으기
• ◇CGO가 필요 없는 순수 Go SQLite 드라이버(modernc.org/sqlite)를 쓰고, 마이그레이션 SQL을 바이너리에 포함시키기
• ◇robfig/cron으로 앱 안에 1분 주기 스케줄러 두기
• ◇Wails가 file:// 로 화면을 불러 History API를 쓸 수 없어서, TanStack Router를 해시 히스토리로 쓰기