접은 앱 기능들과 왜 접었는가 — 만들 수 있어도 내놓지 않은 것들

만들다 만 기능 이야기입니다. 정확히는 다 만들어 놓고도 내놓지 않은 것들이요.

새 기능을 거의 다 끝낸 밤이었어요. 버튼도 눌리고 화면도 그럴듯했고, 출시 목록에 한 줄만 더 적으면 되는 상태였습니다. 그런데 마지막으로 다른 언어 설정에서 일정을 넣어 봤더니 안내 문장이 일정 제목으로 저장되더군요. 사용자는 기능을 하나 배운 게 아니라 잘못된 일정을 하나 얻는 셈이었습니다. 고치려면 시간이 더 필요했고, 그대로 내면 "된다"는 약속부터 거짓이 되고요.

그날 제가 한 일은 완성이 아니라 삭제였어요.

처음엔 실패처럼 느껴졌습니다. 이미 쓴 시간이 있고 화면도 다 나와 있었으니까요. 그런데 기능을 접는 건 만든 시간을 부정하는 일이 아니었어요. 사용자에게 넘겨도 되는 것과 아직 내부 실험으로 남겨야 하는 것을 가르는 일이었죠.

데이리플을 만들며 접은 건 기능 몇 개가 아니라 제품이 무엇인지 흐리는 가능성이었습니다. 기능보다 중요한 것을 말로는 알고 있었는데, 실제로 버튼을 지워 보기 전까지는 몰랐어요.

데스크톱 앱은 왜 멈췄나

큰 화면에서 달력을 쫙 펼치는 그림은 확실히 매력적이었습니다. 키보드로 일정을 넣고 주간 계획을 넓게 보는 장면도 좋았고요. 데스크톱 프로토타입을 만들면서 반복 일정과 빠른 입력에서 놓쳤던 문제도 꽤 찾아냈습니다.

문제는 제품의 문이 두 개가 된다는 데 있었어요.

모바일에서는 스토어 심사, 알림, 위젯, 결제, 작은 화면을 검증해야 합니다. 데스크톱에서는 창 크기, 로그인, 업데이트, 키보드 동작을 다시 책임져야 하고요. 같은 기능처럼 보여도 출시 이후에 나는 고장은 완전히 다릅니다. 한 사람이 두 문을 동시에 지키면 어느 쪽도 마음 놓고 열 수가 없어요.

그래서 데스크톱은 버리지 않고 개인 검증용으로 동결했습니다. 거기서 발견한 문제는 모바일로 가져오되, 사용자가 들어오는 문으로는 열지 않았어요. 접는 게 파일을 없애는 일은 아니었던 겁니다. 역할을 바꾸는 일이었죠.

아이폰과 안드로이드를 함께 만든 기록과도 이어지는 이야기입니다. 플랫폼 하나가 늘면 화면 하나가 느는 게 아니라 검수해야 할 세계가 하나 더 생겨요.

말로 넣는 일정은 왜 언어별로 닫았나

"내일 저녁에 약속"처럼 말로 일정을 만드는 기능은 입력을 확 줄여 줍니다. 잘 작동할 때는 키보드를 여러 번 누르는 것보다 훨씬 편하죠.

문제는 날짜와 시간 표현이 번역만으로 옮겨지지 않는다는 겁니다. 어떤 언어는 날짜가 먼저 나오고 어떤 언어는 시간이 먼저 나와요. 같은 단어가 오늘을 뜻하기도 하고 요일을 뜻하기도 하고요. 오른쪽에서 왼쪽으로 쓰는 화면은 글자만 뒤집는다고 끝나는 게 아니라 달력 이동 방향과 버튼 배치까지 같이 봐야 합니다.

문구만 번역해 놓고 기능을 켜면 사용자는 당연히 그 언어도 이해한다고 받아들여요. 여기서 틀린 일정이 저장되면 작은 오타로 끝나지 않습니다. 병원 예약이나 기차 시간이 엉뚱한 날로 들어갈 수 있으니까요.

그래서 검증하지 못한 언어에서는 버튼을 아예 숨겼습니다. "나중에 지원"이라는 빈칸이 "지금 지원하는 척"보다 정직했어요. 다시 여는 조건도 기능 개수로 잡지 않았습니다.

예시 문장이 제목으로 저장되지 않고, 날짜·시간·반복이 실제 일정과 일치할 때만 열어요.

혼자 만들 때 무엇을 검수했는지와 같은 기준입니다. 화면이 나왔다는 사실보다 잘못 저장될 길이 닫혔는지를 봐야 했어요.

투두 앱을 따로 만들지 않은 이유

할 일을 캘린더와 분리하면 제품 설명이 쉬워집니다. 일정 앱 하나, 투두 앱 하나. 아이콘도 두 개 생기고 스토어 페이지도 두 개 생기죠.

그런데 사용자의 하루는 그렇게 둘로 갈라지지 않아요. 금요일 회의는 일정이고 회의 자료 준비는 할 일입니다. 장보기 약속은 캘린더에 있고 장볼 목록은 투두에 있고요. 앱을 나누는 순간 사용자는 매번 어느 쪽을 열어야 하는지 판단해야 합니다.

저는 그 판단 비용이 새 앱의 깔끔함보다 크다고 봤어요. 그래서 투두를 별도 제품으로 떼지 않고 같은 앱 안에서 혼자 실행하는 모드로 남겼습니다. 공유 캘린더와 개인 할 일의 경계는 지키되 설치는 늘리지 않은 거죠.

물론 "모든 걸 한 화면에 넣자"는 뜻은 아닙니다. 한 앱 안에서도 모드는 분명히 갈라야 해요. 캘린더를 보러 들어왔는데 할 일 목록이 앞을 가로막으면 합친 이점이 사라집니다. 합치는 기준은 기능이 비슷해서가 아니라 같은 하루를 다루기 때문이었어요.

접기를 두고 자주 부딪히는 말들

"이미 만들었으면 일단 내고 반응을 보면 된다." 되돌리기 쉬운 꾸미기라면 맞습니다. 하지만 일정 저장, 결제, 권한처럼 틀렸을 때 사용자의 돈이나 약속을 건드리는 기능은 달라요. 반응을 보기 전에 안전하게 실패하는 길부터 있어야 합니다. 이걸 "완벽할 때까지 출시하지 말자"로 뒤집어 읽으면 곤란해요. 작은 기능은 내되 틀리면 큰 손해가 나는 기능만 기준을 통과한 뒤 내자는 말입니다.

"기능을 접으면 경쟁 앱보다 약해진다." 기능표의 칸은 줄어듭니다. 대신 남은 기능의 약속이 선명해져요. 사진 기록과 채팅이 중요한 커플이라면 그걸 잘하는 앱이 맞고, 데이리플은 일정과 위젯이 중심인 사람에게 맞습니다. 앱의 우열이 아니라 사용 장면의 선택이에요. 고르는 기준은 공유 캘린더 앱 비교에 따로 정리해 뒀습니다.

"접었다는 건 영원히 안 한다는 뜻 아닌가." 조건이 있으면 동결이고 조건이 없으면 그냥 미뤄두기입니다. 데스크톱은 모바일 운영이 안정된 뒤 검토하고, 언어 입력은 그 언어의 실제 예문으로 저장 정확도를 확인한 뒤 엽니다. 다시 여는 조건을 안 적어 두면 로드맵이 아니라 미련만 남아요.

"사용자가 원하면 전부 넣어야 한다." 요청은 문제를 알려 주지만 해법까지 확정해 주지는 않습니다. "PC에서도 보고 싶다"는 말은 데스크톱 앱을 새로 만들라는 뜻일 수도 있고, 큰 화면에서 확인할 웹 보기면 충분하다는 뜻일 수도 있어요. 요청 문장을 그대로 기능명으로 바꾸면 제품은 아주 빠르게 무거워집니다.

다시 열지 말아야 할 것도 있습니다

접은 기능을 전부 빚처럼 들고 있으면 로드맵이 과거에 끌려다녀요. 다시 여는 질문은 "아까우냐"가 아니라 셋입니다. 사용자가 겪는 문제가 아직 남아 있는지, 지금 남은 기능으로는 정말 해결이 안 되는지, 그리고 새 기능을 연 뒤에 계속 검수할 수 있는지. 셋 중 하나라도 아니면 목록에서 내려도 됩니다.

특히 경쟁 앱에 있다는 이유만으로 넣은 기능은 되살릴 근거가 약해요. 사진 앨범이 꼭 필요한 사용자는 앨범을 잘하는 앱을 고르는 게 맞고, 데이리플이 모든 사람의 앱일 필요는 없습니다. 다음 앱에서 다르게 할 것도 결국 이 경계를 더 일찍 세우자는 이야기였고요.

접기 직전에는 기능이 아니라 실패 장면을 적었습니다

버튼을 지울지 고민할 때 기능 이름만 보면 아까움이 먼저 옵니다. "음성 입력", "데스크톱", "다국어"라고 써 놓으면 전부 있으면 좋은 것처럼 보이거든요. 그래서 이름 옆에 사용자가 실제로 겪을 실패를 한 문장으로 적었어요.

"약속 시간을 말했는데 안내 문장이 제목으로 저장돼요."

"모바일에서 고친 일정이 데스크톱의 오래된 화면과 다르게 보여요."

이렇게 적어 놓으면 논점이 개발 진척도에서 사용자 손해로 옮겨갑니다. 화면을 거의 다 만들었는지보다, 잘못됐을 때 사용자가 스스로 알아차리고 되돌릴 수 있는지가 보이거든요.

그다음에는 공개 범위를 세 칸으로 나눴습니다. 손님에게 열어도 되는 기능, 내부에서만 시험할 기능, 아예 폐기할 기능. 내부 시험 칸에 둔 기능은 제품 소개와 설정 메뉴에서도 숨겼어요. 앱 안에서만 닫아 놓고 소개 글에 "지원한다"는 문장이 남아 있으면 약속은 여전히 열려 있는 셈이니까요.

다시 여는 날에도 같은 실패 문장으로 확인합니다. 기능이 더 예뻐졌는지가 아니라 그 장면이 더는 재현되지 않는지를요. 접기와 재개가 같은 기준을 써야 "이번엔 괜찮을 것 같은데" 하는 기분으로 문을 다시 열지 않게 됩니다. 기준을 통과하지 못했으면 출시 일정이 코앞이어도 상태표를 억지로 바꾸지 않았어요. 날짜는 다시 잡을 수 있지만 잘못 저장된 약속은 사용자가 대신 복구해야 하니까요.

여기서 잘못 따라 하면 안 되는 것

"기능을 줄여라"만 가져가면 빈 앱이 됩니다. 접기의 목적은 적게 만드는 데 있지 않아요. 핵심 장면을 더 확실하게 만드는 데 있습니다.

공유 일정이 핵심인데 초대와 동기화를 접으면 제품 자체가 사라지죠. 반대로 일정 앱에 사진 필터가 없어도 핵심은 멀쩡합니다. 무엇을 접을지는 구현 난도가 아니라 사용자가 이 앱을 여는 이유로 판단해야 해요.

접은 뒤에는 빈자리도 확인합니다. 버튼을 숨겼는데 안내문만 남았는지, 설정 링크가 죽었는지, 예전 결제 상품이 아직 노출되는지까지요. 지우는 일도 하나의 출시입니다.

확인 기준과 한계

이 글의 제품 상태는 2026년 8월 기준입니다. 현재 데이리플 공식 제품 페이지는 홈 화면 위젯, 기간 일정, 공간 공유를 핵심으로 안내하고 있고 공식 App Store 페이지는 iPhone 앱의 현재 기능을 보여 줍니다. 앞으로 플랫폼과 기능 상태가 바뀌면 접었던 이유와 다시 여는 조건도 달라질 수 있어요.

사용자 수나 전환율 같은 성과 숫자는 넣지 않았습니다. 접은 결정이 매출을 올렸다고 증명할 자료가 없기 때문이에요. 말할 수 있는 건 제품을 실제로 만들고 검수하면서 어떤 위험을 확인했고 무엇을 공개 범위에서 뺐는지까지입니다.

짧은 문답

기능을 접을지 고칠지 가장 빨리 가르는 질문은요?

"틀렸을 때 사용자가 무엇을 잃나요?"입니다. 불편만 생기는 정도면 작게 내고 고칠 수 있어요. 돈, 일정, 개인정보를 잃을 수 있으면 공개 전에 실패 경로부터 닫습니다.

경쟁 앱에 다 있는 기능도 빼도 되나요?

우리 앱을 고르는 이유와 상관없는 기능이라면 빼도 됩니다. 다만 저장·동기화·알림처럼 사용자가 기본으로 기대하는 건 경쟁표의 장식이 아니라 제품의 바닥이라 따로 봐야 해요.

접은 기능은 어디에 기록하나요?

기능명보다 이유와 재개 조건을 적습니다. "데스크톱 보류"만 써 두면 다음 사람이 처음부터 다시 논쟁해요. "모바일 운영 안정 뒤 검토, 현재는 개인 검증용"처럼 적어야 판단이 이어집니다.

데이리플이 맞지 않는 사람도 있나요?

있습니다. 지금 당장 Android 앱이 필요하거나 사진·채팅·추억 기록이 중심이라면 다른 앱이 나아요. 일정과 위젯, 관계별 공간을 단순하게 쓰고 싶은 iPhone 사용자에게 현재 초점이 맞춰져 있습니다.