필요해서 만들고
계속 운영하는 것들

듀데잇

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

왜 만들었나

돈이 새는 방식은 두 가지입니다. 안 쓰는 구독료가 매달 빠져나가거나, 사둔 것을 기한 안에 못 쓰고 버리거나. 둘 다 '날짜를 놓쳐서' 생기는 손해인데, 대부분의 앱은 이 둘을 전혀 다른 문제로 다룹니다. 가계부는 이미 나간 돈을 기록하고, 냉장고 앱은 식품만 봅니다. 나는 이 둘이 같은 문제라고 봤습니다. 아직 오지 않은 날짜를 관리하면 둘 다 막을 수 있습니다.

무엇을 하는 서비스인가

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

계속 다듬고 있는 것

• ◆반복 지출의 '이번만 건너뛰기'와 '규칙 자체 변경'을 한 화면에서 구분해 보여주는 방법. 사용자에게는 다른 행동인데 UI에서는 비슷하게 생겼습니다.
• ◆소비기한 인식의 정확도. 라벨 인쇄 상태가 제각각이라 인식에 실패하는 경우가 남아 있고, 실패했을 때 손으로 넘어가는 흐름을 더 매끄럽게 만들고 있습니다.
• ◆알림 권한을 거절한 사용자에게도 앱이 쓸모 있게 남도록 만드는 것.

만들면서 시도해 본 것

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

개발 핸드북

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

왜 만들었나

검색으로 얻는 지식은 조각이 납니다. HTML 기초를 다시 볼 때마다 매번 다른 블로그를 찾아 들어가고, 어디까지 봤는지도 남지 않습니다. 순서가 있고, 읽은 곳이 기억되고, 로그인 없이 바로 열리는 레퍼런스가 필요했습니다.

무엇을 하는 서비스인가

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

계속 다듬고 있는 것

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

만들면서 시도해 본 것

• ◇콘텐츠 저장소를 앱·웹이 공유하는 구조 — 문서는 한 곳에서만 관리한다
• ◇expo-sqlite + Drizzle로 앱 안에 읽기 상태와 북마크를 두고, 콘텐츠와 분리해 관리
• ◇d3-force로 문서 간 선행 관계를 시각화

UXPlan

UI/UX 정책을 읽는 표가 아니라 눌러보는 화면으로

왜 만들었나

기획·디자인·개발이 UI 정책을 논의할 때 대부분 노션 표를 앞에 놓고 이야기합니다. 그런데 '필터를 바꾸면 페이지를 유지할까' 같은 문제는 글로 읽어서는 판단이 서지 않습니다. 실제로 둘 다 눌러보면 5초 만에 답이 나옵니다. 그 5초를 만들어주는 도구가 필요했습니다.

무엇을 하는 서비스인가

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

계속 다듬고 있는 것

• ◆정책 항목이 늘어날수록 데모 제작 비용이 선형으로 늡니다. 데모 없이 대조만으로 충분한 항목의 경계를 데이터에 표시하는 방법.
• ◆기획에서 엑셀로 전달받는 목록의 컬럼 구성이 아직 유동적이라, 변환 방식을 언제 고정할지.

만들면서 시도해 본 것

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

축제 모아

공공 관광데이터로 만드는 축제 정보 앱

왜 만들었나

2026 관광데이터 활용 공모전에 낼 목적으로 시작했습니다. 지역 축제 정보는 공공데이터로 열려 있지만, 정작 사람들이 찾아보기 좋은 형태로 정리된 곳이 없습니다. 데이터는 있는데 쓸 수 있게 만들어진 게 없다는 것이 출발점이었습니다.

무엇을 하는 서비스인가

• 공공 관광데이터를 수집·정규화해 자체 API로 제공합니다. 원본 데이터의 결측과 표기 흔들림을 서버에서 정리합니다.
• 축제를 시기·지역·성격으로 좁혀 볼 수 있는 모바일 앱.
• API는 Hono로 작성하고 OpenAPI 스펙을 자동 생성합니다. 앱은 그 스펙에서 타입을 받아 씁니다.

계속 다듬고 있는 것

• ◆공공데이터의 갱신 주기가 소스마다 제각각입니다. 언제 수집하고 언제 캐시를 버릴지 기준을 소스별로 나눠야 합니다.
• ◆축제 정보에서 정말 필요한 필드가 무엇인지. 원본에는 수십 개 필드가 있지만 대부분은 아무도 보지 않습니다.

만들면서 시도해 본 것

• ◇Hono + Zod OpenAPI로 API 스펙과 타입을 한 소스에서 뽑기
• ◇Redis로 외부 공공 API 응답을 캐시해 호출 한도와 응답 속도를 동시에 다루기
• ◇앱과 API를 혼자 만들면서 계약을 어디에 둘 것인지 실험