**2023.01** (This article is also available in [[My Journey at the Apple Developer Academy|English]]) <br> ### 자율성이 중심이 되는 [[Apple Developer Academy 1기 지원 후기|아카데미]] 정해진 커리큘럼에 따라 태스크와 숙제가 주어지는 환경에 익숙하다면, 아카데미의 방식이 다소 낯설 수 있다. 이곳에서는 1년 동안 프로젝트를 진행할 수 있는 기간과 간단한 가이드라인만 주어지고, 나머지는 모두 자율적으로 운영된다. 내가 하고 싶은 것을 찾고, 주변 러너들과 함께 고민하며, 멘토들에게 조언을 구하는 과정 속에서 iOS 개발과 환경을 배워나간다. 처음에는 **“이렇게까지 자유롭게 해도 되는 건가?”** 싶어, 매일 멘토님께 _“다음은 뭘 해야 할까요?”_ _“이렇게 해도 괜찮을까요?”_ 라는 질문을 던지며 정답을 찾으려 했다. 하지만 두 번째 프로젝트를 진행하며 깨달았다. **“아, 정답이 없구나.”** 그 후로는 관심 있는 분야에서 뜻이 맞는 팀원들과 함께 다양한 시도를 해보며 프로젝트를 진행했다. 실패하면 그 나름대로 배울 점이 있었고, 과정 자체에서도 많은 것을 얻을 수 있었다. 이렇게 해도 좋고, 저렇게 해도 좋았다. ![[신난다.png|center|w25]] <br><br> ### MC1: 첫 SwiftUI 첫 프로젝트에서 귀인을 만나, Git 관리부터 iOS 개발까지 정말 많은 것을 배울 수 있었다. 이건 팁이라기엔 너무 당연한 이야기지만, 아카데미에서 **“고수”** 로 불리는 사람이 있다면 꼭 한번쯤 팀이 되어보길 추천한다. 곁에만 있어도 배울 것이 넘쳐난다. 정말 최고다. ( 감사합니다 듀나 ༼;´༎ຶ ۝ ༎ຶ༽ ) 첫 번째 프로젝트는 **_“Recycle with a single touch”_** 를 모토로, 빠르게 분리수거 정보를 제공하고 각 지역에 맞는 분리수거 방법을 안내하는 앱을 개발했다. 이름하여 **수거딱대 (Sugeo-ttakdae)**. ![[분리수거딱대.png]] <div style="text-align:center"><span style="color:gray;">Guide 화면의 문구는 임시로 넣은 것이니 무시해도 된다..^^</span></div> `SwiftUI`, `Vision`, `AVFoundation`, 그리고 공공데이터를 활용해 제작한 앱이다. 바코드를 스캔하면 해당 물품의 분리수거 방법을 안내하고, 작은 게이미피케이션 요소를 적용해 사용자의 분리수거 실천도에 따라 캐릭터를 레벨업하거나 새롭게 오픈할 수 있도록 했다. 또한, 지역별로 다른 분리수거 수거일도 확인할 수 있는 기능을 추가했다. <br> 이 프로젝트를 통해 처음으로 **SwiftUI**를 사용해봤다. 기존에는 **UIKit**만 다뤄왔는데, SwiftUI는 레이아웃 배치가 훨씬 직관적이라는 점이 인상적이었다. 코드를 작성하면서 변화된 화면을 즉시 확인할 수 있다는 점이 특히 편리했다. UIKit에서는 스토리보드나 코드 기반으로 레이아웃을 구성할 때 제약 조건을 하나하나 신경 써야 했지만, SwiftUI에서는 선언형 문법 덕분에 보다 직관적으로 화면을 구성할 수 있었다. 다만, 기존의 UIKit에 익숙하다 보니 데이터 흐름을 관리하는 방식이나, 커스텀 UI를 만들 때의 접근 방식이 조금 달라 적응하는 데 시간이 필요했다. 하지만 코드의 가독성이 좋아지고 유지보수도 용이하다는 점에서 충분히 매력적인 프레임워크라고 느꼈다. 이번 프로젝트를 통해 SwiftUI의 장점과 한계를 직접 경험할 수 있었고, 앞으로 더 깊이 있게 다뤄보고 싶다는 생각이 들었다. <br> ![[UIKit은 가라.png|w60|center]] <br><br> <br> ### NC1: 자연스럽게 만들어진 스터디 문화 NC1 기간은 개인 프로젝트를 진행하는 시기였다. 이때 UI/UX에 관심이 많았던 터라, 사용자 경험을 함께 고민할 수 있는 플랫폼 앱을 만들어보려 했다. 나는 비록 개발자지만, **좋은 UI/UX는 기획자, 개발자, 디자이너 모두가 함께 고민해야 하는 영역**이라고 생각한다. 그 과정에서 같은 관심사를 가진 러너들과 함께 **HIG 스터디 모임**을 만들었다. <span style="font-style:italic; color:gray;"> 이 시기쯤, 일렉 소모임, 영어 회화 스터디, 배드민턴 모임 등 적어도 20개 이상의 동아리가 생겼다. <br>누가 “동아리를 만드세요!” 라고 한 것도 아닌데, <br>자연스럽게 다들 자발적으로 동아리를 조직하고 활동하는 모습이 신기했다. </span> <br><br> HIG 스터디는 성공적으로 진행되었고, 2개월만에 모든 정리를 마쳤다. 디자이너, 개발자 등 다양한 도메인의 사람들이 모이다 보니, 디자인 관점에서의 고민이나 개발 팁 등 여러 유익한 정보가 오갔다. 단순히 문서를 읽고 정리하는 것을 넘어, 실제 앱 사례를 함께 분석하며 HIG 가이드를 더 깊이 이해할 수 있었다. ![[HIG 스터디.png]] <div style="text-align:center"><span style="color:gray;">HIG 공식 문서에는 예시가 부족하거나 설명이 불친절한 경우가 있어, 실제 앱 사례와 함께 살펴보며 이해하고자 했다.</span></div> <br><br> 그런데 운명의 장난처럼, **공식 HIG 문서가 전면 개편되었다.** 결국, 업데이트된 내용을 다시 정리하느라 추가로 3개월이 걸렸다. 허허. ![[거짓말.png|center|w35]] <br> ![[HIG 노션.png|center|w80]] <br><br><br> ### MC2: 창업 파트너와의 첫 만남 MC2에서 진행한 프로젝트는 **PacKit**, 자율좌석 근무자, 프리랜서, 혹은 업무 환경이 자주 바뀌는 사람들을 위한 **데스크 오거나이저 앱**이다. 사용자가 언제 어디서나 필요한 업무 환경을 쉽게 세팅할 수 있도록, **위젯 형태의 기능들**을 제공하는 것이 핵심 목표였다. 칸반보드, 일정 관리, 투두 리스트, 프로젝트 진행 관리 기능을 **상호작용 가능한 위젯 형태로 한 화면에 제공하는 방식**을 고민했다. 당시 iPad의 위젯은 상호작용을 지원하지 않았기 때문에, 이러한 기능을 구현하면 기존 위젯보다 더 경쟁력 있는 앱이 될 것이라고 생각했다. 여기에 **기기 간 동기화까지 지원**하면 더욱 편리한 업무 환경을 만들 수 있을 것 같았다. 또한, 기존 iPad 위젯의 배치 방식에도 한계를 느꼈다. 기본적으로 iPad에서는 위젯을 추가하면 상단부터 차곡차곡 쌓이며 기존 위젯을 ‘밀어내는’ 방식이었다. 하지만 PacKit에서는 사용자가 원하는 위치에 위젯을 자유롭게 배치할 수 있도록 구현했다. 다만, 기능이 늘어나면서 앱의 규모가 예상보다 훨씬 커졌고, 결국 모든 기능을 완성하지 못한 채 프로젝트를 마무리해야 했다. (위젯 하나하나가 사실상 개별 앱의 기능을 해야 했던 게 가장 큰 도전 과제였다.) 그럼에도 불구하고, 기획부터 개발까지 모든 과정이 흥미로운 경험이었다. ![[왕따봉.png|center|w30]] <br> <br><br> 프로젝트에서 특히나 기억에 남는 두 가지 순간이 있는데, 첫번째는 **실제 사용자 테스트** 과정이다. 단순히 _“이런 앱이 있으면 좋겠다”_ 수준에서 출발한 프로젝트였지만, 실제 사용자의 불편함과 요구를 반영하는 것이 중요하다고 판단해 **유저 테스트**를 진행했다. 앱 개발 전에 **프로토타입을 인쇄**해, 사용자들이 직접 앱을 사용하는 것처럼 시뮬레이션하며 피드백을 받을 수 있도록 했다. 이 과정에서 예상하지 못했던 다양한 의견이 나왔다. 예를 들어, 일부 사용자는 특정 메뉴의 역할을 직관적으로 이해하지 못했고, 몇몇 기능은 기대했던 것과 다르게 받아들여졌다. 덕분에 개발 전에 **UI/UX를 보완하고, 보다 직관적인 흐름을 만들 수 있도록 수정할 기회**를 가질 수 있었다. ![[사용자 테스트.jpg|center|w45]] <div style="text-align:center"><span style="color:gray;">날것 그자체</span></div> <br><br> 두번째 순간은 한 팀원과 함께 **아이패드 위젯과 비슷한 자연스러운 애니메이션과 레이아웃을 구현하기 위해** 며칠 동안 머리를 맞대고 고민했던 경험이다. 애플의 **PIP 애니메이션** 등을 참고하며 위젯이 부드럽게 동작할 수 있도록 연구하고, **개발 방향을 끊임없이 논의했다.** 그 과정에서 밤새 열띤 토론이 이어졌고, 함께 개발하는 과정 자체가 정말 즐거웠다. 같은 관심사를 가진 사람과 밤새 아이디어를 주고받으며 고민하는 경험은, 흔치 않은 행운이라고 느꼈다. 이런 순간들 덕분인지 MC2에서 만난 팀원들과의 관계는 단순한 프로젝트를 넘어, **최종 프로젝트 그리고 창업까지 이어질 정도로** 끈끈한 인연이 되었다. | ![[레이아웃 고민 1.jpg]] | ![[레이아웃 고민 2.jpg]] | ![[레이아웃 고민 3.jpg]] | | :----------------: | :----------------: | ------------------ | <div style="text-align:center"><span style="color:gray;">고민의 흔적들</span></div> ![[레이아웃 영상.mov]] <div style="text-align:center"><span style="color:gray;">완성~</span></div> <br><br> <br> ### NC2: 턱걸이 카운팅 앱 이때는 한창 턱걸이에 빠져 있던 시기였다. 집에 치닝디핑을 들여놓고 연습하던 중, **턱걸이 횟수를 자동으로 카운팅해주는 앱**을 만들어보면 좋겠다고 생각했다. 마침 Core ML도 활용해볼 기회가 될 것 같아, 자연스럽게 프로젝트로 연결됐다. | ![[턱걸이앱 1.png]] | ![[턱걸이앱 2.png]] | ![[턱걸이앱 3.png]] | | --------------- | -------------- | -------------------------- | 앱을 테스트하기 위해 내 모습뿐만 아니라, 유튜브에 올라온 다양한 턱걸이 영상에도 적용해 봤다. 예상보다 정확도가 높았고, 대부분의 자세를 인식할 수 있었다. 다만, 아쉬운 점이 있다면 **올바르지 않은 턱걸이 자세일 때 경고음을 주는 기능을 넣고 싶었지만,** **결국 단순한 카운팅 기능에서 멈췄다는 점.**. 시간이 된다면 더 발전시켜 실제 턱걸이 훈련에 활용해 보고 싶다. ![[강한 키티.png|center|w25]] <br><br><br> ### MC3: 🌙 최소한의 수면으로 최고의 효율을 🌞 평소 90분 단위로 수면을 조절하면 개운하게 일어날 수 있다는 이야기를 많이 들었다. 실제로 6시간이나 7시간 30분 정도 자는 편인데, 그때마다 일일이 시간을 계산해 알람을 맞추는 게 꽤 번거로웠다. <span style="color:gray;">수면 사이클이 90분마다 반복된다는 다양한 근거 자료가 있다.   아래는 실제로 자주 사용하던 수면 시간 계산 사이트다. https://thesleepcharity.org.uk/information-support/adults/sleep-calculator/ </span> <br> 이런 불편함을 해결하고자, 이번 프로젝트에서 **90분 수면 주기를 기반으로 한 알람 앱**을 기획하고 개발하게 됐다. 핵심 기능은 다음과 같다. - 현재 시간을 기준으로 **90분 단위로 기상/취침 알람을 설정** - 특정 기상 시간(예: 오전 7시)에 맞춰 **취침 시간을 역으로 계산하여 알람 설정** - **수면 기록 및 간단한 수면 퀄리티 평가** 기능 <br> ![[Sleepie.png]] <br> 지난 MC2 프로젝트에서는 디자인 작업에 시간이 너무 많이 소요되었던 경험이 있어, 이번에는 최대한 아이폰 기본 앱과 비슷한 디자인을 유지하며 개발에 집중했다. 덕분에 기한 내에 앱스토어에 배포할 수 있었다. 이번 프로젝트에서 앱스토어 배포를 직접 담당하면서 처음으로 배포 과정을 경험했다. 처음이라 애플 심사 과정이 다소 까다롭게 느껴졌지만, 실제 배포를 진행하면서 앱을 출시하는 전반적인 프로세스를 익힐 수 있었다는 점이 가장 큰 수확이었다. 배포 후 앱을 직접 다운로드해서 사용해 본 순간, 그동안의 개발 과정이 실감 났다. 이전까지는 프로젝트를 진행해도 대부분 내부에서만 사용했는데, 실제 사용자가 앱을 다운로드할 수 있도록 배포했다는 점에서 색다른 성취감을 느꼈다. <br><br> 이번 프로젝트에서는 **PR과 코드 리뷰를 적극적으로 활용**하며 진행했다. 덕분에 단순히 기능을 구현하는 것에서 그치는 것이 아니라, **더 좋은 구현 방법을 고민하고 코드 컨벤션을 맞춰가는 과정**을 함께 경험할 수 있었다. 코드 리뷰를 진행하면서 미처 발견하지 못한 **잠재적인 문제를 사전에 확인할 수 있었고**, **더 효율적인 코드 작성 방법**에 대해 고민할 기회가 많아졌다. 다만, **PR 단위가 너무 커지는 문제가 있었다.** 파일 변경량이 많아지다 보니, 리뷰어 입장에서 검토하는 것이 부담스러울 수밖에 없었다. **다음 프로젝트에서는 한 PR에 200줄 이상이 넘어가지 않도록 신경 써야겠다고 다짐했다.** <br> ![[귀여운 커밋 목록.png|center|w85]] <div style="text-align:center"><span style="color:gray;">귀여운 이모지 커밋 컨벤션</span></div> ![[코드리뷰.png|center|w85]] <div style="text-align:center"><span style="color:gray;">떨렸던 첫 코드 리뷰</span></div> <br><br><br> ### Macro 정리중... <br><br><br><br>