"점심 드실 분?" 묻기 싫어서 만든 앱 — 오늘뭐픽 출시기

오늘뭐픽 출시기를 한 줄로 요약하면?

• 매일 사내 메신저에 “점심 드실 분?”을 묻는 일이 은근히 고역이라, 투표와 추천으로 대신해 주는 앱 오늘뭐픽을 만들었다. Flutter와 Firebase로 혼자 개발해 iOS·Android 양대 스토어 출시까지 간 기록이다.

왜 오늘뭐픽을 만들었나?

점심시간이 가까워지면 늘 같은 질문이 나온다. “오늘 뭐 먹지?” 쉬운 질문처럼 보이지만, 여러 사람이 함께 정하려면 생각보다 어렵다. 누군가는 어제 먹은 메뉴를 피하고 싶고, 누군가는 가까운 곳을 원하고, 누군가는 그냥 아무거나 빨리 정해지길 바란다.

결정적인 계기는 사내 메신저였다. “점심 드실 분?” “약속 있으신 분?” 하고 물어봐도 모두가 바로 대답하는 것은 아니다. 다른 일에 집중하고 있을 수도 있고, 선뜻 말을 꺼내기 어려운 사람도 있다. 저마다의 사정이 있을 뿐인데, 묻는 사람은 몇 번을 되묻고 기다리게 되고 시간은 시간대로 흘러갔다.

그래서 이 과정을 자동화하고 싶었다. 정해진 시간에 투표가 자동으로 올라오면 팀원들은 각자 편한 순간에 부담 없이 투표만 하면 되고, 마감되면 결정된 결과대로 움직이면 된다. 투표에 참여한 사람들끼리는 채팅으로 “몇 시에 출발할까요?” 같은 이야기를 이어 가면 된다. 묻는 사람의 부담도, 대답을 미루는 어색함도 줄이고 싶었다. 매일 함께 일하는 팀원들에게 실제로 도움이 되는 도구라면, 직접 만들어서 반응을 보며 계속 다듬을 수 있겠다고 생각했다.

오늘뭐픽은 이 문제를 거창하게 바꾸기보다, 팀 안에서 부담 없이 고르고 기록할 수 있게 만들자는 생각에서 출발했다. 팀 전용 채널을 만들고, 함께 갈 맛집 리스트를 관리하고, 직접 입력이나 룰렛을 포함한 투표로 선택지를 좁히는 방식이다. 여기에 AI 메뉴 추천, 최종 PICK, 팀 맛집 통계·랭킹, 건의사항 루프, 푸시 알림을 붙여 “정하기”와 “다시 쓰기”가 이어지도록 설계했다.

혼자 만들 때 가장 먼저 정한 기준은 무엇이었나?

처음부터 iOS와 Android를 따로 만들 여유는 없었다. 그래서 Flutter를 선택했다. 하나의 코드베이스로 두 플랫폼을 함께 가져가되, 앱처럼 느껴지는 기본 경험을 놓치지 않는 것이 목표였다. 백엔드는 Firebase를 중심으로 잡았다. Auth로 로그인 흐름을 만들고, Firestore에 팀·맛집·투표 데이터를 저장하고, FCM으로 알림을 보내며, Cloud Functions로 필요한 서버 로직을 분리했다.

혼자 개발할 때의 장점은 기획과 구현 사이의 간격이 짧다는 점이었다. 화면을 만들다가 투표 흐름이 어색하면 바로 기획을 고치고, 데이터 구조가 운영에 불편해 보이면 다시 설계를 조정할 수 있었다. 반대로 단점도 분명했다. 내가 놓친 예외를 잡아 줄 사람이 없기 때문에, “완료”라고 부르기 전에 실제 기기와 실제 흐름으로 다시 확인해야 했다.

출시 과정에서 무엇을 배웠나?

오늘뭐픽은 2026년 3월 13일 App Store와 Google Play에 정식 출시했다. Android와 iOS 출시 경험이 없던 것은 아니지만, 계정 세팅부터 심사 대응까지 처음부터 끝까지 혼자 해 본 것은 이번이 처음이었다. 회사에서는 이미 누군가 해 두었던 일들 — 개발자 계정 등록, 앱 서명 키 관리, 스토어 등록 정보, 기기별 스크린샷 제작, 개인정보처리방침 페이지 — 이 전부 내 몫이 됐다.

의외로 시간이 간 곳은 코드가 아니라 그 주변이었다. 해상도별 스토어 스크린샷을 만들고, 앱 설명 문구를 다듬고, 심사 반려에 대비해 데모 계정과 권한 사용 사유를 미리 정리했다. 그리고 Apple 개발자 프로그램의 연 99달러 결제 화면 앞에서 잠시 숙연해졌다. 구글은 25달러 한 번이면 평생인데, 애플은 매년 돌아오는 구독형 꿈이었다. 그래도 결제 버튼을 눌렀다. 꿈은 원래 유료다.

출시 준비 자체가 하나의 프로젝트였다. 앱 설명, 권한 안내, 로그인 흐름, 알림 사용 이유처럼 사용자가 보기 전에 심사자가 먼저 확인하는 지점들이 있었고, 이걸 정리하는 과정에서 앱을 설명하는 언어도 함께 정리됐다.

스토어 심사에서 배운 점은 두 가지였다. 첫째, 앱이 무엇을 하는지 짧고 명확하게 설명할 수 있어야 한다. 만든 사람에게는 당연한 흐름도 처음 보는 사람에게는 낯설 수 있다. 둘째, 권한이나 로그인처럼 사용자의 신뢰와 연결되는 부분은 “필요하니까 쓴다”가 아니라 “왜 필요한지 이해할 수 있게 보여 준다”에 가까워야 한다. 이 기준은 이후 v1.0.7에서 v1.0.8로 이어지는 개선에서도 계속 기준이 됐다.

출시 후에는 무엇이 달라졌나?

출시는 끝이 아니라 시작이었다. 스토어에 올라간 뒤에는 내가 예상한 사용 흐름보다 실제 건의사항이 더 중요해졌다. 어떤 팀은 맛집 리스트를 더 빨리 정리하고 싶어 했고, 어떤 흐름에서는 투표 이후의 PICK이 더 분명해야 했다. 같이 쓰는 팀원들의 “이거 조금 불편해요” 한마디가 다음 버전의 우선순위가 됐고, 그렇게 반영한 개선이 실제로 쓰이는 걸 보는 것이 혼자 개발하며 가장 즐거운 순간이었다.

또 하나의 운영 과제는 맛집 메뉴와 가격 데이터였다. 앱 안의 리스트가 오래되면 추천이나 선택의 신뢰도도 떨어진다. 그래서 맛집 메뉴·가격 데이터를 자동으로 보강하는 파이프라인을 운영하며, 단순히 기능을 추가하는 것보다 정보가 계속 쓸 만한 상태로 유지되는지를 보게 됐다. 이 과정에서 “완료는 검증 후에”라는 기준이 더 중요해졌다. 코드를 바꿨다는 사실과 사용자에게 안정적으로 보인다는 사실은 같은 말이 아니었다.

화면에 등장하는 식당들은 광고가 아니다. 실제로 자주 가는 곳들이라 자연스럽게 담겼을 뿐이고, 혹시 내려 달라는 요청이 오면 바로 내릴 생각이다. 다만 맛있어서 자주 가는 것은 사실이다.

혼자 전 과정을 해 보며 배운 점은 무엇인가?

가장 크게 배운 점은 기획, 개발, 심사, 운영이 따로 떨어진 단계가 아니라는 것이다. 기획에서 정한 문장은 스토어 설명과 온보딩에 영향을 주고, 데이터 구조는 운영 자동화의 난이도를 바꾸고, 심사에서 배운 표현 방식은 사용자 안내에도 다시 돌아온다. 혼자 했기 때문에 모든 연결을 직접 맞닥뜨렸고, 그만큼 다음 프로젝트에서 무엇을 먼저 확인해야 하는지 더 선명해졌다.

앞으로도 앱을 만들 때는 기능 목록보다 반복 사용 흐름을 먼저 볼 생각이다. 오늘뭐픽의 핵심도 “투표 기능이 있다”보다 “팀이 점심 결정을 덜 어색하고 더 공정하게 할 수 있다”에 가깝다. 결국 개발은 함께 일하는 사람들의 시간을 아껴 주고, 매일의 작은 결정을 조금 더 매끄럽게 만드는 일이라고 생각한다. 기술은 그 경험을 유지하기 위한 선택이어야 했다.

직접 써 보고 싶다면 — 시작 방법

오늘뭐픽은 무료로 받을 수 있고, 팀 단위로 쓰도록 만들어져 있다. 시작 흐름은 이렇다.

1. 앱 설치 — App Store 또는 Google Play에서 “오늘뭐픽”을 설치한다.
2. 간단 회원가입 — 이메일로 가입하거나 카카오·네이버 계정으로 바로 시작할 수 있다.
3. 채널 만들기 또는 가입 요청 — 우리 팀의 채널을 새로 만들거나, 이미 만들어진 팀 채널에 가입을 요청한다. 채널 관리자가 승인하면 팀의 구성원이 된다.
4. 투표 시작 — 구성원이 되면 맛집을 등록하고 투표를 만들 수 있다. 정해진 시간에 올라오는 투표에 참여하고, 마감되면 결과대로 움직이면 된다.

회고 — 남은 숙제와 다음 이야기

돌아보면 기능을 만드는 시간보다 화면을 고민하는 시간이 더 길었다. 그리고 그 시간의 대부분은 “왜 이 화면이 어색한지”를 설명할 언어가 부족해서 생겼다. 개발자로서 가장 크게 남은 숙제는 UX/UI 감각이다. 버튼을 그리는 능력이 아니라, 사용자가 어디서 머뭇거리는지 알아채고 그 이유를 구조로 설명하는 능력. 그래서 요즘은 잘 만든 앱의 화면을 따라 그려 보고, 왜 그 배치와 순서였는지 분해해 보는 연습을 하고 있다.

또 하나의 숙제는 운영 데이터를 더 적극적으로 읽는 것이다. 건의사항과 투표 패턴은 다음 개선의 가장 정직한 근거인데, 지금은 이 신호를 모으는 구조까지만 만들었다. 신호를 해석해서 우선순위로 바꾸는 체계는 아직 사람(나)의 감에 기대고 있다.

Flutter나 Firebase 조합이 모든 앱에 정답이라는 뜻은 아니다. 혼자 iOS·Android 동시 출시를 목표로 했을 때 유효했던 선택과 운영 기준을 정리한 글에 가깝다. 이후에는 v1.0.7에서 v1.0.8로 이어진 개선 과정, 사용자 건의가 실제 화면과 데이터 흐름에 반영된 사례, 맛집 데이터 보강 파이프라인을 운영하며 배운 점을 공개 가능한 범위에서 더 나눠 보려고 한다.