나 혼자 기획, 디자인, 개발
프로덕트 디자이너의 앱 제작기 그리고 가까운 미래 이야기
완성한 지는 조금 되었지만, 3개월간 매일 1~2시간씩 투자해 만든 App Blocker를 앱 스토어에 출시한 과정과, IT 업계에 앞으로 다가올 미래에 대한 생각을 늦게나마 공유합니다.
AI 코딩
때는 2025년 봄, 온 세상이 Cursor, Bolt 등 AI를 활용한 빠른 제품 개발에 대해 이야기하고 있었습니다. 마치 디자인의 중심이 인쇄에서 디스플레이로 옮겨갔던 것처럼, 또 한 번 변화의 바람이 느껴졌습니다.
Product Designer라는 직업, 더 나아가 IT 업계의 미래에 대해 진지하게 고민할 필요가 있다고 느꼈습니다. 우선, 지금의 기술이 나를 어디까지 데려다 줄 수 있는지를 알아야 미래를 제대로 가늠할 수 있을 것이라는 생각이 들었습니다.
과거 서체나 웹을 공부할 때 저는 늘 한 벌의 폰트나 웹사이트를 직접 만들어보며 배웠습니다. 몸으로 겪으면서 배우는 것을 선호하는 사람이기에, 이번에는 하나의 작은 앱을 만들고, 앱 스토어에 배포까지 해보는 것을 목표로 삼았습니다.
뭘 만들지?
한때 일 평균 2시간 릴스를 시청 기록을 보유한 저는, Opal이라는 스크린 타이머 앱으로 도파민 중독을 치료한 경험이 있습니다. 직원이 많은 서비스의 숙명일까요, 시간이 지나며 Opal은 점점 복잡한 서비스가 되었습니다. 그래서 제가 정말 필요로 하는 기능만 남긴 단순한 App Blocker를 만드는 것을 목표로 잡았습니다.
옛날 Opal이 정말 단순하고 좋았는데..어떻게 만들지?
크로스플랫폼 개발을 고려하면 React Native가 적합하겠지만, Swift에 대한 기초 지식이 있어 이번에는 Swift를 사용하기로 결정했습니다. 개발 환경으로는 Cursor + Claude 3.5, Xcode를 사용했습니다.
제품 개발은 단순합니다. 일단 상상의 나래를 펼칩니다. 정규 Flow부터 있으면 좋은 것들을 모두 나열하고, 우선순위를 세우면 됩니다. 본인의 학습 속도를 보며 시간 내 현실 가능한 분량으로 덜어내는 것이 중요합니다. 물론 목적이 유료 서비스에 대외 유저를 대상으로 한다면 다른 접근방식이 필요합니다.
일단 위시 리스트를 다 쓴다. 그리고 덜어낸다.
Happy Case 정도만 Flow 확인용으로 그려도 좋다.워크플로우 만들기
효율적인 [질문 - 답변 - 오류 파악 - 재질문 - 교정] 구조를 만드는 것이 프로젝트 속도를 끌어올리는 핵심입니다. 가장 중요하고, 시간을 꽤 써야 하는 부분입니다. 이 부분을 최적화하는 데 1주 반 정도 시간을 썼습니다. 당시에는 Cursor가 지금처럼 각광받던 시절이 아니었기 때문에 처음에는 GPT에 그냥 질문을 하는 방식으로 삽질을 했습니다.
핵심은 맥락 전달입니다. 어느 정도 화면과 로직이 생기고, 데이터를 저장하고 가공해야 하는 순간, 코드의 의존 관계를 AI에게 전달해야 맥락이 고려된 올바른 답변이 돌아옵니다.
몇 가지 팁을 드리자면, PRD(Product Requirement Document)를 작성하고 수시로 정리해야 합니다. 명령과 질문은 멘션(Mention) 형태로 작게 나누어 여러 번 질문하는 것을 추천드립니다. 다시 한 번 말하지만 핵심은 맥락 전달입니다. 아! Rules for AI도 꼭 잘 설정하길 바랍니다.
이 세개만 기억하자.나를 힘들게 한 놈들
가계부나 일기장 앱을 만들었다면 3주 정도면 끝났을 텐데, 제가 꽤 어려운 주제를 골랐더군요. 감정이 격해진 나머지 Claude에게 미운 말을 하기도 했습니다. 아래와 같은 챌린지들이 있었습니다.
Family Controls을 통한 시간 측정
Family Controls이라는 익스텐션을 통해 기기의 앱 사용량 측정 로직과 데이터에 접근할 수 있습니다. 익스텐션 자체를 처음 사용해서 어리둥절했습니다.
특이하게도 Family Controls을 사용하려면 Apple에 허가 신청서를 제출하고 승인을 받아야 합니다. 기기 내부의 개인정보와 어린이가 연관되어 있어서인지, 과정이 꽤 깐깐하다고 느껴졌습니다. Target에서도 Identifier를 각각 등록해야 합니다. 참고로 사용량은 분 단위로만 측정 가능합니다. QA 때 정말 눈물 나게 고생했습니다.
사용하기 생각보다 까다롭다.잔여시간 계산하기
유사 앱들을 둘러보면서 신기하게도 대부분 몇 분을 사용했는지는 알려주지 않는다는 공통점을 발견했습니다. 개발하면서 알게 된 사실은, Device Activity Monitor Extension(DAM)이 잔여 시간을 제공하지 않는다는 점이었습니다. 공식 문서와 포럼을 통해 그 이유를 알 수 있었는데, 이 API는 유저의 행동을 가이드하기 위한 용도이지 실시간 모니터링을 위한 것이 아니라고 선을 긋고 있었습니다. 배터리와 메모리 소모가 이유였습니다.
당연하게도 선행 모험가들이 이렇게 만든 이유가 있더라.다른 Report API는 앱 사용량에 대한 이런저런 정보를 제공하긴 하지만, 역시 실시간성은 없었습니다. 저는 태생이 반골이라 그런지 실시간으로 잔여 시간을 보여주는 앱을 꼭 만들어야겠다는 생각이 들었습니다.
회사에서도 말썽꾸러기인 편.결국 1분 간격으로 Time Interval을 강제로 리셋시키고 앱이 Foreground로 올라오면 동기화 하는 방식으로 구현했습니다. 꽤 용도 외적인 방식입니다. 억지로 만들어서 그런지 예외 처리, 저장, 리셋 로직이 꽤 지저분하게 완성되었습니다. 이후에 날짜 개념까지 추가해볼까 고민했지만, 이런 구조에서는 불가능하다는 걸 깨달았고, 왜 타사 서비스들이 그렇게 만들었는지 그제야 이해할 수 있었습니다.
Swift UI의 법칙
"큰 바텀시트 위에 작은 바텀시트를 올리고 싶어요". SwiftUI에서는 불가능합니다(아니면 내가 못하거나). 저는 코드 문제인 줄 알았는데 그냥 애플이 생각한 컴포넌트의 룰이고 철학이었습니다. 이런 규칙들은 곳곳에 숨어 있었고, 이해하는데 시간이 조금 필요했습니다.
이 부분은 시각적으로, 경험적으로 어떻게 접근해야하지? 생각이 들때면 HIG(Human Interface Guidelines)를 읽어보시는 것을 추천드립니다. iOS는 상상 이상으로 치밀하게 기획된 세계관임을 알 수 있을 것 입니다.
문서를 읽고, 코드로 구현해보고, 뜯어보세요!Xcode의 DX
소문은 많이 들었습니다만.. 이 정도일 줄이야. 괴랄한 설정 방식과 숨어 있는 메뉴, 작은 글씨, 알 수 없는 크래시 등.. Xcode의 개발 경험은 그닥 좋지 못했습니다. 왜 지금까지 만났던 iOS 개발자들이 모두 성격이 좋았는지 알 것 같았습니다.
대청소
프로젝트를 진행하며 총 3번의 코드 대청소 시간이 있었습니다. 생각을 해야 합니다. 멍하니 프롬프트를 계속 Accept하다 보면, 마치 화장실 문을 달았는데 변기 때문에 문을 열 수 없는 상황이 발생합니다.
그리고 내가 코드를 자유롭게 짤 수는 없어도, 읽을 수는 있어야 합니다. 글과 똑같습니다. 작문 능력이 없어도 GPT로 글을 쓸 수 있습니다. 하지만 첨삭을 하려면 최소한의 문법은 이해하고 있어야 합니다.
AI 코딩은 누구나 할 수 있습니다. 하지만 상용 서비스는 지속적인 모니터링과 유지 보수가 필요합니다. 만드는 것과 가꾸는 것은 엄연히 다릅니다. 마치 피아노 건반을 누르면 소리가 나지만, 연주는 어렵듯이 말입니다.
QA, 빌드
이름은 Wind로 정했습니다. 삶 속에 불필요한 것들이 사라지고, 그 사이에 바람이 분다는 이야기로 접근했습니다. 스토리를 시각화한 로고도 만들고, Splash 화면, Darkmode 대응, 그리고 entitlement 승인까지 받으면 빌드 준비가 끝납니다.
QA는 화면 기능별 시나리오를 쓴 TC 테이블을 작성하고, Custom Log를 만들어 주요 동작 구간에 심은 후 꾹꾹 누르면서 테스트했습니다. 자동화를 하면 편하겠지만, 일정상 생략했습니다.
로그를 잘 작성하세요. 특히 UI로 안 보이는 요소를 테스트 할때요..심사 런칭
이후 비행기에 탑승하기 전 체크처럼, 몇 가지 점검을 거친 뒤 심사를 받습니다. 보통 한 번은 반려된다고 하는데, 저는 서버나 Auth도 없었고 Terms와 Privacy Policy를 나름 정성껏 작성해서인지 한 번에 통과되었습니다. 이제 앱 스토어에서 Wind를 다운로드할 수 있게 되었습니다. 만세!
치명적인 결함
일단 지금까지 저는 잘 사용하고 있습니다(강조). 하지만 지인 10명이 사용하면 4명은 작동하지 않는다고 하더군요. 속상한 마음에 포럼을 찾아보니, Family Control의 고질적인 이슈로 보입니다. 더구나 저는 잔여 시간 노출을 위해 매 분마다 초기화하는 기형적인 방식을 사용했더니, 오류가 많이 발생하는 모습을 보였습니다.
익스텐션(라이브러리)의 성숙도, 업데이트 주기, 호환성을 잘 살펴봐야 한다는 것, 그리고 코어 로직과의 의존성을 반드시 고려해야 한다는 것을 따끔하게 배웠던 것 같습니다.
너 핸드퐁이 문제얏!변화의 바람
바이브 코딩의 현주소와 한계점에 대해 왈가왈부하는 건 사실 큰 의미가 없을 것 같습니다. 중요한 건 이미 변화는 시작되었고, 생각보다 빠르고 거칠 것이라는 점입니다. 기어가는 아기를 보며 뛰지 못한다고 생각하더라도, 그 아이는 곧 무럭무럭 자라 뛰게 될 것입니다. 그것이 제가 몸으로 느낀 AI였습니다.
인사이트, 마치며
지면에서 디스플레이로 넘어온 지 10년도 안 됐는데, 이 업계는 끊임없이 변화를 요구합니다. 앞으로 IT 업계는 어떻게 변화할까요? 제가 정리한 몇 가지 인사이트를 공유하며 마치겠습니다.
직군 재편성
2.5년 안에 직군이 크게 바뀌지 않을까 싶습니다. 고유의 하드 스킬이 있는 T형 제너럴리스트가 이상적인 인재상이 되지 않을까 싶습니다.
작은팀 큰 임팩트
큰 제품적 성공을 위해 반드시 큰 팀이 필요한 것 같지는 않습니다. 이미 해외 사례를 통해 모두가 아는 사실이고, 앞으로는 작지만 단단한 팀들이 더 많이 생겨날 것 같습니다. 1인 사업가에게도 매우 유리한 시대가 될 것 같습니다.
팀 분리
빠른 개발과 유지보수를 담당하는 인력이 분리되지 않을까 싶습니다. 한 사람이 빠르게 기획–디자인–개발–배포를 진행하고, 유효한 데이터가 나오면 이후 디자이너, 개발자 등 직군별로 다듬고 정리하는 방식으로 말입니다.
프롬프트 디자인
System Designer가 관리하는 라이브러리를 연결해 프롬프트로 디자인한다면, 라이브러리의 컴포넌트와 에셋을 기반으로 유지보수 가능한 무언가를 만들 수 있을 것 같습니다. 라이브러리와 에셋은 철저하게 System Designer가 중앙에서 관리하고, 여러 명의 Maker가 이를 가져다 쓰는 방식으로 말입니다.
...
긴 글, 시간 내어 읽어 주셔서 감사합니다.
