AI 활용 어플 만드는법 — 코딩보다 완료를 정하는 게 더 어려웠어요

약속을 분명히 말했는데 상대는 처음 듣는 표정을 짓습니다. 대화창을 올려 보니 날짜는 중간에 바뀌었고, 최종 시간은 사진 아래에 묻혀 있어요. 한 사람은 캘린더에 옛 시간을 적었고, 다른 사람은 머릿속으로 새 시간을 기억하고 있었습니다.

그날 필요한 건 거창한 기술이 아니었어요. 둘이 같은 원본을 보고, 앱을 열지 않아도 다음 약속이 눈에 보이면 됐거든요. 그런데 제가 원하는 모양을 설명하려고 하면 늘 같은 벽이 나왔습니다. "저는 개발을 몰라요."

예전에는 이 문장이 끝이었어요. 아이디어는 있어도 코드를 못 쓰니 누군가에게 맡겨야 하고, 맡기려면 큰돈과 완성된 기획이 필요하다고 생각했으니까요. 지금은 다르게 봅니다. 코드를 직접 쓰지 못해도 문제의 장면을 고르고, 끝나는 모습을 문장으로 정하고, AI가 만든 결과를 실제 기기에서 확인할 수 있어요.

그래서 앱을 만들기 시작했습니다. 개발자가 되고 싶어서가 아니라, 반복해서 설명하던 불편을 더는 말로만 넘기고 싶지 않았기 때문이었어요. 이 글에서는 제 직업이나 회사 이야기를 하지 않겠습니다. 제품을 만드는 판단은 신원보다 구체적인 장면으로 설명하는 편이 더 정확하니까요.

아이디어는 거대한 시장보다 작은 마찰에서 나왔어요

"사람들은 캘린더가 필요하다"는 말로는 제품을 만들 수 없습니다. 이미 캘린더는 많고, 일정은 기본 앱에도 적을 수 있으니까요. 제가 붙잡은 장면은 더 작았어요. 적어 둔 일정이 있는데 앱을 안 열어서 놓치는 것, 관계가 다른 사람들의 일정이 한 달력에 섞이는 것, 한 사람이 바꾼 시간을 다른 사람이 늦게 보는 것.

문제를 이렇게 줄이면 제품 문장도 달라집니다.

"한 사람이 약속을 바꾸면, 상대의 홈 화면에도 바뀐 시간이 보여요."

이 한 문장이 데이리플의 출발점이었어요. 달력을 새로 발명하는 대신, 함께 쓰는 공간과 홈 화면 위젯에 집중했습니다. 데이리플이 어떤 앱인지는 기능 목록보다 이 장면으로 설명해요.

다른 도구도 비슷했습니다. 긴 대화가 끝난 뒤 무엇이 잘됐는지 감으로만 남는 장면, 공개된 자료가 너무 길어 처음 보는 사람이 어디부터 읽을지 모르는 장면처럼요. 저는 이런 불편을 만나면 "AI 기능을 넣자"부터 생각하지 않아요. 지금 누가 무엇을 못 보고 있는지부터 적습니다.

문제의 크기보다 반복성이 중요했어요. 한 번의 불편은 메모로 끝낼 수 있지만, 같은 자리에 계속 시간이 새면 도구를 만들 이유가 생기니까요.

코딩보다 어려웠던 건 완료를 말하는 일이었어요

AI에게 "예쁜 공유 캘린더를 만들어 줘"라고 하면 화면은 나옵니다. 색도 있고 버튼도 눌려요. 처음에는 그 속도가 제품 제작이라고 생각했습니다. 그런데 초대받은 계정에 일정이 안 보이고, 위젯에는 옛 날짜가 남고, 결제 뒤 다른 공간이 열릴 수 있다면 예쁜 화면은 완료가 아니에요.

비개발자가 맡아야 할 일은 코드를 대신 쓰는 게 아니라 무엇이 끝인지 결정하는 일이었습니다. 기획서가 실력인 이유에서 완료 기준을 화면 장면으로 쓰는 이유예요.

예를 들면 이렇습니다.

기능 이름	제가 실제로 확인할 마지막 장면
초대	링크를 받은 새 계정이 같은 공간에 들어옴
공유 일정	한쪽의 수정이 다른 쪽 화면과 위젯에 반영됨
결제	구매한 계정의 올바른 공간만 열림
로그아웃	앱과 위젯에서 이전 사용자의 정보가 사라짐
계정 삭제	다시 가입해도 옛 데이터가 돌아오지 않음

이 문장은 코드를 몰라도 쓸 수 있어요. 오히려 사용자의 자리에서 끝을 보기 때문에 개발 용어보다 선명할 때가 많습니다. AI나 개발자가 구현 방법을 정해도, 이 장면이 나왔는지는 제가 직접 봐야 하고요.

AI에게 맡긴 일과 제가 놓지 않은 일

AI는 빠르게 많은 후보를 만듭니다. 화면 구조를 제안하고, 반복 코드를 작성하고, 오류 원인을 찾아보고, 테스트 목록의 초안을 만들 수 있어요. 저는 그 속도를 빌렸습니다. 코딩 문법을 처음부터 모두 배우고 나서 시작하는 대신, 필요한 조각을 시키고 결과를 비교했어요.

하지만 AI에게 맡기면 안 되는 자리가 있었습니다.

첫째는 문제 선택이에요. 사용자가 실제로 아픈 장면과 제가 만들고 싶은 기능은 다르니까요. 둘째는 근거 확인입니다. 스토어 정책이나 가격을 AI의 기억으로 정하면 낡은 답을 받아요. 셋째는 실제 화면 검증이에요. 코드가 맞다는 설명과 제 휴대폰에서 위젯이 맞게 보이는 건 다른 증거니까요. 넷째는 멈출 결정입니다. 기능을 더 만들 수 있어도 사용자가 핵심 장면까지 가지 않으면 원인을 먼저 봐야 해요.

AI 코딩에서 정말 어려웠던 것과 AI에게 맡기지 않을 일에 이 경계를 더 자세히 적어 뒀습니다.

실제 제품이 되자 숫자와 문장이 책임이 됐어요

아이디어 단계에서는 "구독 없는 앱"이라고 말하기 쉬워요. 스토어에 올리면 정확한 가격, 무엇을 사는지, 어느 기기에서 가능한지를 공개해야 합니다.

2026년 8월 22일 데이리플 한국 App Store를 직접 확인했어요. 앱은 무료로 받을 수 있고, 인앱 구매에는 우리 공간 평생권 9,900원과 추가 인원권 4,900원이 표시됩니다. 공식 설명에는 둘이 무료로 시작하고, 한 사람이 공간 평생권을 사면 초대받은 상대도 함께 쓰는 구조가 안내돼 있어요. 일정·할 일·기념일, 관계별 공간, 오늘·다가오는 일정·디데이 위젯도 현재 설명에서 확인되고요.

좋은 이야기만 하면 광고가 됩니다. 현재 한계도 같이 말해야 해요. 같은 날 공식 다운로드 페이지를 확인하면 iPhone은 받을 수 있지만 Android는 아직 Google Play 준비 중입니다. App Store 설명의 방향이 혼합 기기 사용을 말하더라도, 실제 설치 가능 상태가 준비 중이면 지금 갤럭시 사용자에게 된다고 권하면 안 돼요.

이 간격은 실패를 숨겨야 한다는 뜻이 아닙니다. 제품을 만든 사람은 되는 것과 아직 안 되는 것을 같은 문장 안에서 구분할 책임이 있다는 뜻이에요. 아이폰과 Android를 함께 만든 과정도 두 코드가 있다는 사실과 두 스토어에 출시됐다는 사실을 나눠서 봐야 합니다.

개발을 몰라서 오히려 붙잡은 질문

전문 용어를 몰라서 답답한 순간이 많았어요. 대신 사용자의 말로 계속 물었습니다. "왜 앱에서는 바뀌었는데 홈 화면은 그대로예요?", "왜 로그아웃했는데 이름이 남아요?", "왜 돈을 냈는데 이 방이 아니라 저 방이 열려요?"

이 질문들은 기술적으로 단순하지 않았어요. 위젯은 앱과 별도 과정으로 움직이고, 공유 공간은 권한이 있고, 결제는 영수증과 서버 상태를 맞춰야 하니까요. 하지만 문제를 발견하는 데 기술 이름이 필요하지는 않았습니다. 이상한 장면을 끝까지 놓치지 않으면 됐어요.

그래서 비개발자의 약점과 강점을 같이 봅니다. 구현 비용을 모르면 무리한 요구를 할 수 있고, 보안이나 데이터 구조를 과소평가할 수 있어요. 이건 전문가의 설명과 검증으로 보완해야 하고요. 반면 익숙한 기술 해법보다 실제 불편을 먼저 볼 수 있고, "사용자는 왜 이걸 해야 하죠?"라는 질문을 계속 할 수 있습니다.

비개발자가 첫 달에 밟는 함정은 모르면 괜찮다는 이야기가 아니에요. 모르는 지점을 표시하고, 중요한 경계는 공식 문서와 실제 기기로 확인하는 방법을 배우는 이야기입니다.

앱을 만들면서 만들지 않기로 한 것도 생겼어요

제품을 직접 만들 수 있게 되면 아이디어가 부족해지지 않아요. 오히려 너무 많아집니다. 말로 일정을 넣는 기능, 데스크톱 화면, 더 많은 꾸미기, 별도의 할 일 앱처럼 계속 뻗어요.

처음에는 만들 수 있으면 만드는 게 진전이라고 생각했습니다. 지금은 핵심 장면을 흐리는 기능을 접는 것도 제작이라고 봐요. 공유 일정이 안정되지 않았는데 새 플랫폼을 벌리면 검증할 경로만 늘어나고, 사용자가 초대를 끝내지 않는데 테마를 늘리면 핵심 문제는 그대로니까요.

접은 기능과 그 이유에 남긴 기준은 단순합니다. 지금 사용자가 겪는 가장 비싼 구멍을 막는가, 이미 쓰는 사람이 있는 경로를 깨뜨리지 않는가, 제가 끝까지 검증할 수 있는가.

여러 제품을 동시에 떠올릴 수 있어도 한꺼번에 키우는 게 능력은 아니었어요. 여러 제품을 병행하며 배운 것처럼 실사용과 결제가 없는 상태에서 기능 수만 늘리는 건 위험했습니다.

여기서 자주 갈리는 이야기들

"코딩을 모르면 앱을 만들 수 없다." 혼자 모든 구현을 할 수 없다는 말은 맞아요. 하지만 제품 문제를 정하고, 마지막 장면을 쓰고, AI나 개발자에게 나누어 맡기고, 실제 기기에서 검증하는 일까지 못 한다는 뜻은 아닙니다. 만들 수 있다는 말과 안전하게 혼자 다 할 수 있다는 말도 구분해야 하고요. 보안·결제·개인정보는 더 엄격한 검토가 필요해요.

"AI가 이제 개발자를 대신하니 전문가가 필요 없다." AI가 구현 속도를 크게 높여도 책임을 대신 지지는 않습니다. 인증, 결제, 데이터 삭제, 개인정보처럼 잘못되면 사용자가 피해를 보는 경계는 전문가의 검토와 공식 문서 확인이 중요해요. AI는 작업자이자 설명 도구일 수 있지만 최종 책임자가 아닙니다.

"현장을 아는 사람이 만들면 무조건 좋은 제품이다." 문제를 가까이 본다는 장점은 있어요. 동시에 자기 방식이 모든 사람에게 맞는다고 착각하기 쉽고요. 그래서 실제 사용자 행동과 결제를 봐야 합니다. 내 불편은 출발점이지 시장 전체의 증거가 아니에요. 현장을 아는 사람이 도구를 만들 때의 장단점을 함께 보세요.

"스토어에 출시하면 성공한 것이다." 출시는 설치할 수 있는 상태일 뿐입니다. 초대가 수락되고, 함께 일정이 만들어지고, 다음 주에도 쓰고, 필요한 사람이 돈을 내는 건 그다음 검증이에요. iPhone 출시와 Android 준비 중 상태도 정확히 나눠 말해야 하고요. 출시를 끝으로 읽으면 고쳐야 할 장면을 못 봅니다.

이 숫자를 읽을 때 알아두실 것

데이리플 가격과 출시 상태는 2026년 8월 22일 한국 App Store와 공식 다운로드 페이지 확인 기준이에요. 가격은 국가·스토어·시점에 따라 바뀌고, Google Play 준비 상태도 이후 달라집니다. 실제 설치와 결제 전에는 공식 페이지를 다시 확인하세요.

9,900원이 다른 앱보다 무조건 이득이라는 뜻도 아니에요. 필요한 기능, 인원, 기기 조합이 맞아야 가격 비교가 의미가 있습니다. 현재 Android가 필요한 사람에게는 가격이 아니라 설치 가능 여부가 먼저고요.

이 글을 "누구나 당장 앱을 만들라"로 읽지 마세요

앱 제작에는 시간과 유지 책임이 들어요. 이미 좋은 도구가 있고 그 도구로 문제가 풀리면 직접 만들 이유가 없습니다. 데이터와 결제를 다루는 제품은 출시 뒤에도 보안, 고객지원, 정책 변경을 따라가야 하고요.

직접 만들기 전에 세 질문을 해 보세요. 같은 문제가 반복되는가, 기존 도구로 풀 수 없는가, 만든 뒤 계속 돌볼 수 있는가. 셋 중 하나가 아니면 자동화나 작은 문서가 더 좋은 답일 수 있습니다.

자주 묻는 질문

코딩 공부부터 시작해야 하나요?

기본 개념은 도움이 돼요. 하지만 첫 단계는 문제 장면과 완료 기준을 쓰는 일입니다. "공유 캘린더"보다 "상대가 초대를 받고 홈 화면에서 같은 약속을 봄"이라고 쓰세요. 필요한 기술은 그다음에 배워도 됩니다.

외주와 AI 중 어느 쪽이 나아요?

요구사항이 선명하고 책임 범위가 크면 검증된 전문가가 안전해요. 빠른 시안과 작은 반복은 AI가 유용하고요. 둘 중 하나를 고르는 문제보다, 누가 만들든 내가 완료 기준과 검증 증거를 갖고 있는지가 중요합니다.

비개발자가 꼭 직접 확인해야 하는 것은 무엇인가요?

가입, 초대, 공유, 결제, 로그아웃, 삭제가 실제 사용자 화면에서 끝나는지예요. 특히 다른 계정과 실제 휴대폰에서 보세요. 코드가 통과했다는 말만으로 대신할 수 없는 장면입니다.

그래도 다시 앱을 만들 건가요?

만들 겁니다. 다만 만들 수 있다는 이유로 기능을 늘리지 않고, 반복되는 불편과 실제 사용 신호가 있는지부터 볼 거예요. 화면이 나온 날이 아니라 사용자의 문제가 닫힌 날을 완성으로 부르려고요.