**2023.01**
(This article is also available in [[My Journey at the Apple Developer Academy|English]])
<br>
## 자율성이 중심이 되는 [[ko/archives/memo/성장의 기회를 발견하다 - 애플 개발자 아카데미에 도전한 이유|아카데미]]
일반적으로 정해진 커리큘럼에 따라 태스크와 숙제가 주어지는 환경에 익숙한 개발자에게 아카데미의 방식은 다소 낯설 수 있습니다. 이곳에서는 **1년 동안 프로젝트를 진행할 수 있는 기간과 간단한 가이드라인만** 주어지며, 프로젝트 운영의 나머지는 모두 자율적으로 결정해야 합니다.
초기에는 멘토에게 "다음은 뭘 해야 할까요?"와 같은 질문을 반복하며 정답을 찾으려 시도했습니다. 하지만 두 번째 프로젝트를 경험하며 **"정답이 없다는 사실"**을 깨달았습니다. 아카데미에서의 핵심적인 성장은, **주도적으로 관심 있는 분야의 문제를 정의하고, 뜻이 맞는 동료들과 다양한 시도를 통해 해결 방향을 모색**하는 과정에서 이루어졌습니다.
실패하더라도 과정 자체에서 많은 것을 얻는 **능동적인 학습 자세**의 중요성을 체감할 수 있었습니다.
<br>
![[신난다.png|center|w25]]
<br><br><br>
## MC1: 첫 SwiftUI 경험과 프레임워크 분석
![[분리수거딱대.png]]
첫 번째 프로젝트에서는 ***“Recycle with a single touch”*** 를 모토로, 지역별 분리수거 정보를 빠르게 안내하는 앱인 **수거딱대(Sugeo-ttakdae)**를 개발했습니다. 이 앱은 **SwiftUI, Vision, AVFoundation** 기술과 **공공데이터**를 복합적으로 활용했습니다. 주요 기능으로는 바코드 스캔을 통한 분리수거 방법 안내, 사용자 실천도에 따른 캐릭터 레벨업 및 오픈 요소와 같은 작은 게이미피케이션 요소 적용, 그리고 지역별 수거일 확인 등이 있었습니다.
<br>
이 프로젝트를 통해 기존에 UIKit만 다뤄왔던 저는 **SwiftUI**를 처음 사용해봤습니다.
SwiftUI의 **선언형 문법**은 레이아웃 배치를 직관적으로 만들었으며, 코드를 작성하는 즉시 변화된 화면을 확인할 수 있다는 점에서 높은 개발 효율성을 경험할 수 있었습니다. UIKit에서 제약 조건을 일일이 구성해야 했던 방식에 비해 화면 구성이 훨씬 간편했습니다.
다만, 기존 UIKit에 익숙했기에 **데이터 흐름을 관리하는 방식**이나 **커스텀 UI 구현을 위한 접근 방식**이 달라 적응하는 데 시간이 필요했습니다. 그럼에도 불구하고, **코드 가독성 향상과 유지보수 용이성** 측면에서 SwiftUI는 매력적인 프레임워크임을 확인했으며, 이 경험을 바탕으로 앞으로 프레임워크를 더 깊이 다뤄보고자 합니다.
<br>
\+ 이 프로젝트에서 만난 동료 개발자 덕분에 **Git 관리 방법**부터 iOS 개발의 모범 사례(Best Practices)까지 정말 많은 전문 지식을 습득할 수 있었습니다. 곁에 있는 것만으로도 배울 점이 넘쳐나는 경험이었습니다.
<br>
![[UIKit은 가라.png|w60|center]]
<br><br>
<br>
## NC1: HIG 스터디와 크로스 도메인 협업
![[HIG 노션.png|center|w80]]
NC1 기간은 개인 프로젝트를 진행하는 시기였으며, **UI/UX**에 대한 높은 관심으로 학습을 확장했습니다. **좋은 UI/UX는 기획자, 개발자, 디자이너 모두가 함께 고민해야 하는 영역**이라는 판단 아래, 사용자 경험을 심층적으로 다루기 위해 **HIG(Human Interface Guidelines) 스터디 모임**을 조직했습니다.
이 스터디는 디자이너, 개발자 등 **다양한 도메인**의 사람들이 모여, 디자인 관점에서의 고민과 실제 개발 팁 등 유익한 정보를 교류하는 협업의 장이 되었습니다. 단순히 문서를 읽고 정리하는 것을 넘어, **실제 앱 사례를 함께 분석**하며 HIG 가이드라인을 더 깊이 이해할 수 있었습니다. 스터디는 성공적으로 진행되어 2개월 만에 모든 정리를 마쳤습니다.
<br>
![[HIG 스터디.png]]
<br><br>
그러나 운명적으로 **공식 HIG 문서가 전면 개편**되었고, 결국 업데이트된 내용을 다시 정리하느라 추가로 3개월이 소요되었습니다.
![[거짓말.png|center|w35]]
<br>
<br><br><br>
## MC2: 위젯 구현의 기술적 도전과 사용자 테스트 기반 UX 개선
MC2에서 진행된 **PacKit**은 자율좌석 근무자나 프리랜서 등 업무 환경이 자주 바뀌는 사용자를 위한 **데스크 오거나이저 앱**이었습니다. 핵심 목표는 칸반보드, 일정 관리, 투두 리스트 등의 기능을 **상호작용 가능한 위젯 형태**로 한 화면에 제공하는 것이었습니다.
당시 iPad 위젯이 상호작용을 지원하지 않았기에, 이러한 기능 구현을 통해 기존 위젯 대비 **경쟁력 있는 개발자 도구**를 만들 수 있다고 판단했습니다. 여기에 **기기 간 동기화**까지 지원하여 편리한 업무 환경을 조성하고자 했습니다.
<br>
![[레이아웃 영상.mov]]
기존 iPad 위젯이 추가 시 상단부터 차곡차곡 쌓이며 기존 위젯을 '밀어내는' 방식이었던 것에 한계를 느꼈습니다. PacKit에서는 사용자가 원하는 위치에 **위젯을 자유롭게 배치**할 수 있도록 구현하는 데 집중했습니다.
다만, 각 위젯이 사실상 개별 앱의 기능을 해야 했기 때문에 앱의 규모가 예상보다 훨씬 커졌고, 모든 위젯을 완성하지 못한 채 프로젝트를 마무리해야 했습니다.
<br><br>
![[사용자 테스트.jpg|center|w45]]
프로젝트에서 가장 기억에 남는 순간 중 하나는 **실제 사용자 테스트** 과정이었습니다.
실제 사용자의 불편함과 요구를 반영하는 것이 중요하다고 판단해, 앱 개발 전에 **프로토타입을 인쇄**하여 사용자들이 직접 시뮬레이션하며 피드백을 받을 수 있도록 했습니다.
이 테스트 과정에서 예상하지 못했던 다양한 의견이 도출되었습니다. 예를 들어, 일부 사용자는 특정 메뉴의 역할을 직관적으로 이해하지 못했으며, 몇몇 기능은 기대와 다르게 받아들여졌습니다. 이 피드백 덕분에 **개발 착수 전에 UI/UX를 보완하고, 보다 직관적인 사용자 흐름을 만들 수 있도록** 수정하는 결정적인 기회를 가질 수 있었습니다.
<br><br>
| ![[레이아웃 고민 1.jpg]] | ![[레이아웃 고민 2.jpg]] | ![[레이아웃 고민 3.jpg]] |
| :----------------: | :----------------: | ------------------ |
<div style="text-align:center"><span style="color:gray;">고민의 흔적들</span></div>
또 다른 중요한 경험은 팀원과 함께 **아이패드 위젯과 비슷한 자연스러운 애니메이션과 레이아웃**을 구현하기 위해 며칠 동안 연구한 것입니다.
애플의 **PIP(Picture-in-Picture) 애니메이션** 등을 참고하며 위젯이 부드럽게 동작하도록 연구하고 개발 방향을 끊임없이 논의했습니다.
이처럼 같은 관심사를 가진 동료와 밤새도록 기술적인 아이디어를 주고받는 과정 자체가 즐거움이었습니다. 이 경험을 통해 만난 팀원들과의 관계는 **최종 프로젝트뿐 아니라 창업까지 이어지는** 끈끈한 인연이 되었습니다.
<br>
<br>
<br><br>
## NC2: Core ML을 활용한 턱걸이 카운팅 앱 개발
NC2 기간에는 개인적인 관심사였던 턱걸이 훈련에 도움을 줄 수 있는 **턱걸이 횟수 자동 카운팅 앱**을 개발했습니다. 이 프로젝트는 **Core ML**을 활용해 볼 기회가 되었습니다.
| ![[턱걸이앱 1.png]] | ![[턱걸이앱 2.png]] | ![[턱걸이앱 3.png]] |
| --------------- | -------------- | -------------------------- |
앱을 테스트한 결과, 제 모습뿐 아니라 유튜브의 다양한 턱걸이 영상에도 적용했을 때 **예상보다 높은 정확도로 대부분의 자세를 인식**할 수 있었습니다.
다만, 아쉬웠던 점은 **올바르지 않은 턱걸이 자세일 때 경고음을 주는 기능**까지 확장하고 싶었으나, **프로젝트 범위 관리(Scope Management)** 측면에서 단순 카운팅 기능에서 멈춰야 했다는 점입니다.
향후 개발 목표는 이 기능을 더 발전시켜 실제 훈련에 활용하는 것입니다.
![[강한 키티.png|center|w25]]
<br><br><br>
## MC3: 프로덕트 배포 경험 및 코드 리뷰
MC3에서 개발한 **Sleepie**는 평소 90분 단위 수면 조절이 개운한 기상에 도움이 된다는 근거를 바탕으로, **90분 수면 주기를 기반으로 한 알람 앱**이었습니다. 핵심 기능은 다음과 같습니다.
![[Sleepie.png]]
- 현재 시간을 기준으로 **90분 단위로 기상/취침 알람을 설정**하는 기능
- 특정 기상 시간(예: 오전 7시)에 맞춰 **취침 시간을 역으로 계산하여 알람 설정**하는 기능
- **수면 기록 및 간단한 수면 퀄리티 평가** 기능
<br>
지난 MC2에서 디자인 작업에 시간이 과도하게 소요되었던 경험을 바탕으로, 이번에는 **최대한 아이폰 기본 앱과 유사한 디자인을 유지**하며 **개발 구현에 집중**하는 전략을 취했습니다. 덕분에 **기한 내에 앱스토어에 성공적으로 배포**할 수 있었습니다.
앱스토어 배포를 직접 담당하면서, 처음에는 애플 심사 과정이 다소 까다롭게 느껴졌으나, 실제 배포를 진행하며 앱을 출시하는 **전반적인 프로세스**를 익힐 수 있었습니다. 배포 후 실제 사용자가 앱을 다운로드할 수 있다는 점에서 내부 프로젝트만 진행했을 때와는 차별화된 성취감을 느꼈습니다.
<br>
![[코드리뷰.png|center|w85]]
이번 프로젝트에서는 **PR(Pull Request)과 코드 리뷰**를 적극적으로 활용하며 진행했습니다. 이는 단순히 기능을 구현하는 것을 넘어, **더 효율적인 코드 작성 방법을 고민하고 코드 컨벤션을 맞춰가는 협업 과정**을 경험하게 해주었습니다.
코드 리뷰를 통해 미처 발견하지 못한 **잠재적인 문제를 사전에 확인할 수 있었고**, **더 효율적인 코드 작성 방법**에 대해 고민할 기회가 많아졌습니다.
<br><br>
![[귀여운 커밋 목록.png|center|w85]]
다만, 프로젝트 과정에서 **PR 단위가 너무 커지는 문제점**이 발생했습니다. 파일 변경량이 많아지자, 리뷰어 입장에서 검토하는 것이 부담스러워지면서 리뷰의 질이 저하될 위험이 있었습니다.
이 경험을 통해 향후 프로젝트에서는 **한 PR의 파일 변경량이 200줄 이상을 넘지 않도록** 변경량을 관리하는 것을 핵심적인 **코드 리뷰 베스트 프랙티스**로 삼아야겠다고 결론 내렸습니다.
<br>
<br>
<br><br><br><br>