아내의 아침은 늘 분주했습니다.
출근 준비를 하면서, 학교 갈 아이의 채비까지 함께 챙겨야 했으니까요.
오늘 날씨는 어떤지, 시간표는 무엇인지, 학사일정에 빠뜨린 건 없는지 —
매일 아침, 흩어져 있는 정보를 하나하나 따로 찾아봐야 했습니다.
책을 좋아해 자주 빌려 읽는 아이에게는
가까운 도서관과 좋은 책 소식을 더 잘 전해주고 싶었습니다.
"이 모든 걸 한 화면에서 볼 수 있다면 얼마나 좋을까."
i-하루는 바로 이 한 줄의 바람에서 시작되었습니다.
아이는 학업에 더 집중하고, 부모는 아이의 하루를 조금 더 쉽게 챙길 수 있도록.
2026.02.19, 첫 줄의 코드 → 2026.07, 세상에 나오기까지의 기록
한 줄의 고민이 한 줄의 코드가 되기까지
아내가 출근 준비 중에 휴대폰을 들고 날씨 앱과 시간표, 학사일정 사이를 오가는 모습이 눈에 들어왔습니다.
학교에 갈 아이의 가방을 챙기면서, 또 자기 출근 가방도 챙기면서요.
"이걸 한 화면에서 볼 수 있다면" — 그날 저녁 첫 줄을 타이핑했습니다.
commit 712d4a8 — "EduLife v6.1 initial commit"
처음엔 진로 추천에 OpenAI를 써볼까 했습니다. 한 달 비용을 계산해보니, 사용자 한 명이 늘 때마다 비용이 발생하는 구조였습니다.
그날로 코드에서 다 지웠습니다. 무료로 만들려는 건 멋이 아니었습니다. 운영비가 늘어 결국 사용자에게 요금으로 돌아가는 걸 막고 싶었고, 솔직히 수익이 없는 동안 그 비용을 혼자 감당하기도 어려웠습니다.
그래서 "i-하루는 무료로 유지한다"를 원칙으로 두고, 이후 모든 기능을 한국의 무료 공공데이터로만 만들기로 했습니다.
학교 정보, 날씨, 급식 영양, 도서관 — 흩어져 있던 네 가지를 처음으로 한곳에 끌어모은 주였습니다.
비로소 "한 화면"이라는 말이 형태를 갖추기 시작했습니다.
React Native + Expo로 5탭 골격을 잡았습니다. 홈 · 급식 · 시간표 · 학사일정 · 설정.
이때만 해도 학원·체험학습·병원까지 욕심껏 다 넣을 생각이었습니다.
코드에 얼굴이 생기는 한 달
브랜드 이름 "i-하루"의 뜻 — "나의 하루"와 "나의 아이의 하루" — 을 그림으로 옮겼습니다.
떠오르는 해, 그 아래 흰색 "i" 한 글자. 크림색 배경(#FFF7ED)에 오렌지 #F97316.
슬로건 세 줄도 같이 굳혔습니다.
화면을 하나씩 만들 때마다 버튼도 카드도 매번 새로 그렸습니다.
자주 쓰는 조각들을 한 벌로 정리하고 나니, 새 화면을 만드는 시간이 절반으로 줄었습니다. 무엇보다, 어느 화면을 열어도 같은 얼굴이었습니다.
다크모드를 시도했지만 화면마다 색 일관성이 무너지는 것을 발견했습니다.
"잘 안 되는 다크모드는 없느니만 못하다" 판단으로 출시 후 재검토로 미뤘습니다.
되는 것만 내놓자 — 안 되는 걸 접는 것도 결정이었습니다.
급식 · 시간표 · 학사일정 · 아침 브리핑 · 날씨 · 도서관 · 추천도서 · 교육청 공지 · 직업 · 학과 · 자격증 · 심리검사.
메인 페이지의 12카드 그리드는 이 시점에 거의 자리를 잡았습니다.
취미가 책임이 된 한 달
두 달간 이것저것 넣었던 기능들을 한꺼번에 정리했습니다.
레시피, 병원·약국, 학원 목록, 교육체험, 안전지도 — 다 좋은 기능이었지만 "학교생활"에서 한 발짝 멀었습니다.
욕심을 줄이고 핵심에 집중했습니다. 급식 · 시간표 · 학사일정 · 진로 · 도서관 · 날씨 · 교육청 공지 — 학교생활 핵심 일곱 갈래만 남겼습니다.
이 일곱 갈래가 이후 진로(직업·학과·자격증·심리검사)와 도서(도서관·추천도서)로 나뉘고 아침 브리핑이 더해지며, 출시 시점엔 12가지 기능으로 자리잡습니다.
v7.0~v7.1 축소
마지막까지 들고 있던 기능 하나를 더 정리했습니다.
학부모가 자주 쓰는 양식이라 아쉬웠지만, 양식을 자동 생성하는 책임은 학교 시스템이 져야 한다고 판단했습니다.
학교 위치로 정확한 날씨를 가져오려고 여러 API를 호출하다 보니, 한 화면 띄우는 데 32초가 걸렸습니다. 사용자 입장에서는 "고장난 앱"이었습니다.
일주일을 통째로 들여 호출 구조를 뜯어고쳤습니다. 결과는 2~4초. 같은 정보, 8분의 1 시간.
신규 가입한 사용자가 다음 날 아침 자동으로 브리핑 푸시를 받도록 만들었습니다.
시간표 · 급식 · 날씨 · D-day가 한 줄로 도착합니다.
"가입하고 바로 가치를 경험"한다는 원칙이 여기서 출발했습니다.
v1.1.3 신규 가입 자동화
두 달 만에 사업자등록증을 받았습니다. 상호 "아이하루". 일반과세자.
광고나 투자 때문이 아니었습니다. 사용자에게 정직한 책임을 지려면 "장난이 아니다"는 신호가 필요했습니다.
그날 이후 모든 결정에 "이게 사용자에게 떳떳한가"를 한 번 더 묻게 되었습니다.
사업자등록번호 594-56-00915
한국관광공사 디지털콘텐츠 공모전 출전을 결정했습니다. 가족이 한 팀이 되어 출전한 첫 공모전이었습니다.
제안서는 11번을 고쳐 썼습니다. 마감 6일 전에 제출을 마쳤습니다.
보이지 않는 곳에서 더 많은 일이 일어난 한 달
데이터베이스 27개 테이블에 RLS(행 단위 보안)를 전수 적용했습니다.
에러 로그와 분석 로그에 개인정보 마스킹을 적용했습니다 — 사용자 개인정보가 평문으로 저장되는 일이 없도록.
사용자가 볼 수 없는 변화지만, 이게 안 되어 있으면 사업을 할 수 없습니다.
에러 모니터링용으로 Sentry를 붙여뒀습니다. 그런데 자세히 보니, 환경 변수 이름이 미묘하게 어긋나서 단 한 건의 에러도 전송되지 않고 있었습니다.
고쳐서 살릴까 고민하다, 결국 깔끔하게 지웠습니다. 자체 에러 리포팅 API와 Supabase 로그로도 충분했고, 비용 발생 외부 서비스를 늘리지 않는다는 원칙이 더 중요했습니다.
commit 2d2daed
전국 17개 시도 교육청 공지사항을 매일 자동으로 크롤링해서 한 화면에서 보여주도록 만들었습니다.
교육부 공지까지 합치니 학부모가 다른 사이트를 오갈 필요가 없어졌습니다.
이날 앱에 i-haru.co.kr이라는 정식 주소가 생겼습니다. 친구에게 공유 링크를 보내면, 앱이 깔린 폰은 앱으로, 없는 폰은 웹으로 알아서 열립니다.
받는 사람이 아무것도 신경 쓰지 않아도 되도록.
한번 정체성을 이유로 접었던 "실종아동 알림" 기능을 다시 살렸습니다. 아이를 키우는 사람으로서, 그 가족의 아픔을 조금이라도 나누고 싶었습니다.
그래서 광고가 나가는 자리에 함께 띄우기로 했습니다. 앱을 쓰는 분들이 지나다 한 번 더 봐주신다면, 누군가는 집으로 돌아갈 수 있을지 모릅니다.
비율은 처음엔 30%였는데, 실제로 폰에 깔아보고 답답해서 10%로 낮췄습니다.
데이터를 가져와 보니 전국에 168명. 1년 이내 사건은 4명뿐이고, 1958년 사건도 아직 찾고 있습니다.
시간 필터를 다 빼고, 우리 동네 → 같은 시도 → 전국 → 장기 미해결 순으로 보여주도록 v2로 재설계했습니다.
부활 결정 → v2 12 task 완료 (18 + 12 commit)
App Store에 회사로 등록하려면 D-U-N-S라는 국제 기업 식별번호가 필요합니다. 신청 5일 만에 도착했습니다.
아직 App Store에 올리지는 않았지만, 올릴 수 있는 자격은 이날 갖췄습니다.
무료로 유지하려면 광고가 필요했습니다. 그래도 아무 광고나 받고 싶진 않았습니다.
광고주가 신청하면 직접 검토하고, 내보낸 뒤 다달이 리포트를 보내는 흐름까지 끝을 봤습니다. 광고를 받더라도 떳떳하게.
한 광고 자리에 광고주 배너, 실종아동 알림, 자동 광고 세 가지가 번갈아 들어옵니다.
어느 것을 얼마나 자주 보여줄지, 그 비율을 직접 조절할 수 있게 만들었습니다.
도서관 책에 더해, 서점에 갓 나온 책까지 아이에게 닿게 하고 싶었습니다.
새로 나온 책 44권과 많이 읽힌 책 50권을, 매일 새벽 자동으로 받아오도록 했습니다.
한국관광공사 공모전 예비심사 합격 통지가 도착했습니다.
한번은 정체성을 이유로 접었던 "관광" 기능이, 공모전 출전작 v1.4.0 탐방 모듈로 다시 돌아옵니다.
1차 심사가 9월 21일, 최종 심사가 10월 28일, 시상이 11월 5일. 갈 길은 멀지만, 처음으로 혼자 하는 일은 아니라는 느낌이 들었습니다.
기자와 리뷰어가 쓸 수 있도록 로고와 앱 스크린샷을 정리한 미디어킷 페이지를 정식 가동했습니다.
같은 날 저녁, 지금 보고 계신 이 페이지의 작성을 시작했습니다.
준비를 마치고 문을 여는 시간
주변 도서관을 위치로 안내하는 기능 하나 때문에, 위치정보법상 사업자 신고가 필요했습니다.
큰 회사만 밟는 절차 같았지만, 한 사람이 만든 무료 앱도 예외는 아니었습니다. 신청서를 쓰고, 보완 요청을 받아 양식을 다시 맞췄습니다.
2026년 6월 15일, 방송미디어통신사무소의 수리증이 도착했습니다. 신고번호 제1170호.
위치기반서비스사업 신고번호 제1170호
출시를 앞두고 개인정보처리방침과 이용약관을 한 줄씩 다시 봤습니다.
데이터가 거쳐 가는 회사는 빠짐없이 적었습니다 — 이메일 발송, 캐시, 크롤러 서버까지. 어느 나라를 거치는지, 무엇이 오가는지.
약관의 "위치 정보를 서버에 저장하지 않는다"는 문장이 코드와 정말 일치하는지도 직접 대조했습니다.
네이버 로그인 검수가 ‘승인’으로 돌아왔습니다. 다만 로그인 버튼을 가이드에 맞춰달라는 ‘권장’이 붙어 있었습니다.
권장이니 넘어가도 됐지만, 이왕 하는 김에 카카오·네이버·구글 세 곳의 공식 가이드를 모두 펼쳐 버튼을 처음부터 다시 그렸습니다.
각 브랜드의 진짜 로고와 정해진 문구, 정해진 색으로. 작은 버튼 하나도 남의 브랜드는 함부로 그리지 않는다는 마음으로요.
Android 정식 출시를 위한 AAB 패키지를 Play Console에 업로드합니다.
실제 학교 사용자 시나리오를 따라가며 마지막 검증을 진행합니다.
드디어 사용자에게 닿습니다.
한 줄의 고민에서 시작한 앱이, 누군가의 바쁜 아침을 조금이라도 가볍게 한다면 좋겠습니다.
끝이 아니라 또 다른 시작
한국관광공사 공모전 출전작입니다. 1차 심사 9월 21일, 최종 심사 10월 28일, 시상 11월 5일.
가족 여행 · 학교 탐방 · 지역 축제를 학생과 학부모 관점에서 다시 풀어냅니다.
학생은 학업에, 학부모는 아이의 하루에 — 거기에 보탬이 되는 기능을 하나씩 더해갑니다.
거창한 목표는 없습니다. 매일 쓰는 앱이 매일 조금씩 나아지면 됩니다.
100일간 AI 도구로 1인 서비스를 만든 실전 워크플로
모든 작업을 네 단계로 나눴습니다. 브레인스토밍에서 무엇을 왜 만들지 합의하고, 스펙 문서로 화면·데이터·예외를 글로 못박고, 플랜에서 작업을 독립적인 task로 쪼갠 뒤, 마지막에 구현합니다.
단계마다 사람이 승인해야 다음으로 넘어갑니다. AI가 큰 그림을 멋대로 바꾸는 일이 구조적으로 막힙니다.
구현은 task 하나당 새 작업자(subagent)를 띄워 처리하고, 끝나면 두 번 검토합니다. 먼저 "스펙대로 만들었나 — 빠진 것·더한 것", 그다음 "코드가 깔끔한가".
지금 보고 계신 이 스토리 페이지도 14개 task 플랜으로 쪼개, 컴포넌트 하나씩 구현하고 매번 타입 검사·테스트·커밋을 거쳐 만들어졌습니다.
스펙과 플랜은 모두 git에 문서로 남깁니다. 나중에 "왜 이렇게 만들었지"를 코드가 아니라 문서에서 찾습니다.
AI와의 대화는 길어지면 끊깁니다. 그래서 매 대화가 끝날 때마다 결정사항·피드백·우여곡절을 메모리 파일로 남깁니다.
메모리는 네 종류입니다. 내가 누구인지(사용자), 어떻게 일해야 하는지(행동 지침), 지금 무엇을 하는지(프로젝트 현황), 외부 자원은 어디 있는지(참조).
한 파일에 사실 하나. 위에는 요약, 본문엔 "왜 그렇게 정했는지"와 "어떻게 적용할지"를 적습니다. 인덱스 한 장으로 전체를 훑습니다.
예를 들어 "존댓말로 말할 것", "보라 그라디언트 같은 AI 색은 금지", "공공데이터 키는 전부 같은 키" 같은 지침이 박혀 있어, 다음 세션의 AI가 같은 실수를 반복하지 않습니다.
덕분에 100일 넘게 세션이 수백 번 바뀌어도, AI는 매번 "이 프로젝트에서 무엇을 왜 정했는지"를 들고 시작합니다.
경계는 분명했습니다. AI는 "어떻게"를 맡고, 사람은 "무엇을"과 "왜"를 쥡니다.
AI는 코드를 쓰고 테스트를 짜고 리팩토링하고, 마이그레이션 SQL과 커밋 메시지, 문서와 시각 디자인 1차안까지 만듭니다.
사람은 어떤 기능을 넣고 뺄지, 무료로 갈지, 사업자를 낼지, 마케팅을 어떤 톤으로 할지, 상표를 어디에 낼지를 정합니다. 실제 폰에 깔아 답답한지 확인하는 것도 사람 몫입니다.
AI가 짠 코드라도 보안·DB 마이그레이션·결제처럼 되돌리기 어려운 곳은 사람이 한 번 더 읽고 넘어갔습니다.
"됐어"라고 말하기 전에 검증 명령을 실제로 돌리고 결과를 눈으로 본 다음에 말합니다. 타입 검사 통과, 테스트 통과, 배포 후 주소로 직접 호출해 정상 응답 — 그제서야 "됐다"입니다.
이 원칙이 빛난 순간이 있습니다. 이 스토리 페이지를 배포한 직후, 주소는 열리는데 본문이 비어 있었습니다. 공통 레이아웃의 한 줄 때문에 본문이 검색엔진에 안 보이는 상태였고, 한 줄을 고쳐 해결했습니다. "열리니까 됐겠지"로 넘겼으면 못 잡았을 문제입니다.
사람의 직관이 AI의 그럴듯한 가정을 뒤집은 적도 여러 번입니다. "공공데이터 키는 사실 다 같은 키 아니냐", "실종아동 1년 이내가 4명뿐인데 왜 1년으로 자르냐" — 한 줄의 의심이 며칠을 아꼈습니다.
AI는 빠르지만, 틀릴 때도 확신에 차 있습니다. 그래서 빠르게 만들되 그대로 믿지 않고 확인합니다.
운영비를 0원에 가깝게 유지하는 건 자랑이 아니라 약속에 가깝습니다. 비용이 늘면 결국 사용자에게 요금으로 돌아가니까요.
돈을 낸 건 둘뿐입니다. AI 코딩 도구 하나, 도메인 하나.
나머지는 전부 무료 등급으로 버텼습니다. 웹과 예약 작업은 Vercel, 데이터베이스·로그인·저장소는 Supabase, 캐시는 Upstash, 매일 도는 크롤러는 Oracle Cloud의 평생 무료 서버.
기능을 채우는 데이터도 전부 한국의 무료 공공데이터입니다. 급식·시간표는 교육부 NEIS, 날씨는 기상청, 진로는 커리어넷, 도서는 도서관정보나루 — 사용자가 늘어도 추가 요금이 붙지 않는 구조만 골랐습니다.
AI는 만능이 아니었습니다. 한계를 알고 우회하는 게 일의 절반이었습니다.
첫째, 기억은 낡습니다. 메모리에 적힌 "이 파일 몇 번째 줄"은 며칠 뒤면 어긋나 있곤 합니다. 그래서 메모리를 믿되, 코드는 항상 다시 열어 확인합니다.
둘째, 모르면 그럴듯하게 지어냅니다. 빈 결과가 나오면 "필수 파라미터를 빠뜨린 것 아닌가"부터 의심하도록 가드레일을 메모리에 박아 뒀습니다.
셋째, 마케팅 문구에서 과장으로 흐릅니다. "검증할 수 없는 단언은 쓰지 말 것" 같은 규칙을 메모리에 적어 두면, AI가 알아서 그 표현을 피합니다.
결국 AI의 한계는 사람의 규칙으로 메꿨습니다. 한 번 정한 규칙은 메모리에 남아 다음 세션까지 따라갑니다.