<div id="readability-page-1" class="page"><div><h2 id="프로젝트-개요">프로젝트 개요</h2>
<p>이 프로젝트는 UMC 7기 활동으로 시작했고, GitHub 협업 방식, 코드 리뷰 문화, 유지보수성을 고려한 설계 등을 경험하는 것을 목표로 했습니다.</p>
<p>또한, 혼자 iOS 개발을 담당했던 과거와 달리, <strong>다른 iOS 개발자들과 협업하여 효과적인 협업 방식과 여러명에서 하나의 프로젝트를 완성하는데 필요한 프로세스들을 배우는 것</strong>도 중요한 목표였습니다.</p>
<blockquote>
<p>깃허브 주소<br>
<a href="https://github.com/UMCWegg/iOS_Wegg">https://github.com/UMCWegg/iOS_Wegg</a></p>
</blockquote>
<h2 id="프로젝트-목표-및-성과">프로젝트 목표 및 성과</h2>
<h2 id="1-github-flow-브랜치-전략-적용">1. GitHub Flow 브랜치 전략 적용</h2>
<ul>
<li><strong>목표</strong>: GitHub Flow 도입 &amp; 브랜치 보호 전략 적용(Issue &amp; PR 활용)</li>
<li><strong>성과</strong>: GitHub Flow 도입과 함께 브랜치 보호 전략을 적용하고, Issue 및 PR 템플릿을 활용하여 코드 리뷰 시 일관된 기준을 마련했습니다. 이를 통해 팀원들이 코드 리뷰 시 놓치기 쉬운 부분을 체크할 수 있도록 유도했습니다.</li>
<li>관련 PR:<br>
<a href="https://github.com/UMCWegg/iOS_Wegg/pull/1">#1 Initial Set Up</a><a href="https://github.com/UMCWegg/iOS_Wegg/pull/28">#28 docs: PR 템플릿 업데이트</a></li>
</ul>
<h2 id="2-클린-아키텍처를-적용한-폴더링-설계">2. 클린 아키텍처를 적용한 폴더링 설계</h2>
<ul>
<li>목표: 유지보수를 고려한 폴더 구조를 설계하여 코드 관리의 효율성을 높이는 것</li>
<li>성과: Screen, Core, Componenet, Models, Resources 등의 폴더를 분리하여 역할별 관리가 가능하도록 구성하였습니다. 이를 통해 모둘별 폴더링 적용으로 유지보수 용이하게 하였고, 각 레이어의 역할을 명확하게 분리하여 가독성을 높일 수 있었습니다.</li>
<li>관련 PR: <a href="https://github.com/UMCWegg/iOS_Wegg/commit/c32a7c5e48c4714a0447d19fd49aefdbe68af149">docs: 초기 폴더 구조 구성 완료</a></li>
</ul>
<h2 id="3-swiftlint-적용하여-코드-컨벤션-통일">3. SwiftLint 적용하여 코드 컨벤션 통일</h2>
<ul>
<li>목표: 팀원 간 일관된 코드 스타일을 유지하고, 오류를 사전에 방지시키기 위해 SwiftLint를 적용하는 것</li>
<li>성과: SwiftLint를 초기에 도입하여 코드 컨벤션을 강제하였습니다. 특히, <code>force_unwrapping</code>을 설정하여 앱 실행 중 크래시를 방지했고, <code>line_length</code>를 통해 가독성을 향상시켰습니다.</li>
<li>관련 PR: <a href="https://github.com/UMCWegg/iOS_Wegg/commit/7c35fdddd55d3635e01423f83ab2f7b39ae23a54">dosc: SwiftLint 설정 완료</a></li>
</ul>
<h2 id="4-solid-원칙을-고려한-네이버-지도-모듈화">4. SOLID 원칙을 고려한 네이버 지도 모듈화</h2>
<ul>
<li>목표: 네이버 지도 SDK 의존성을 줄이고, 유지보수성을 높이기 위해 SOLID 원칙을 적용하여 모듈화 하는 것</li>
<li>성과: MapManagerProtocol을 정의하여 네이버 지도 SDK와의 강한 결합을 줄이고, 추후 다른 지도 API로 교체할 수 있도록 유연한 구조로 설계하였습니다.</li>
<li>관련 PR<br>
→ 초기 PR: <a href="https://github.com/UMCWegg/iOS_Wegg/pull/32">feat: 네이버 지도 뷰 띄우기 &amp; 커스텀 핀 마커 생성</a><br>
→ 최종본: <a href="https://github.com/UMCWegg/iOS_Wegg/blob/main/iOS_Wegg/iOS_Wegg/Models/Protocol/MapManagerProtocol.swift">MapManagerProtocol.swift</a></li>
</ul>
<h2 id="5-uikit--snapkit-활용한-ui-개발">5. UIKit + SnapKit 활용한 UI 개발</h2>
<ul>
<li>목표: 스토리보드 없이 코드 기반으로 UI 개발하고, Snapkit을 활용하여 AutoLayout을 설정하는 것.</li>
<li>성과</li>
<li>UIView 이미지 변환, 네비게이션 커스텀 등 다양한 기법 적용하였습니다.<br>
→ <a href="https://github.com/UMCWegg/iOS_Wegg/pull/121">feat: 장소 인증 페이지 제작 및 화면 이동</a>에서 인증 안내 뷰(UIView)를 UIImage로 변환하여 네이버 지도 위의 마커로 생성.<br>
→ <a href="https://github.com/UMCWegg/iOS_Wegg/pull/92">feat: 커스텀 검색바 제작 및 검색 결과 페이지 UI 제작</a>에서 네비게이션 스택이 중복으로 쌓이지 않도록 하고, 애니메이션 커스텀.<br>
→ <a href="https://github.com/UMCWegg/iOS_Wegg/pull/105">feat: 일정 페이지 UI 제작</a>에서 기존에 알고 있던 <code>UITableviewDataSoure</code> 대신 <code>DiffableDataSource</code>를 사용하여 자동으로 셀 데이터 변화를 감지하게 하고 애니메이션을 추가함. 이를 통해 사용자 경험과 유지보수성을 향상.<br>
→ <a href="https://github.com/UMCWegg/iOS_Wegg/pull/138">feat: 지각 토글 여부에 따른 지각 버튼 활성화</a> 에서 지각 여부 토글을 적용할 때 <code>updateConstraint</code>를 활용하여 UI가 자연스럽게 변경되도록 설계.</li>
</ul>
<h2 id="6-네트워크-모듈화moya-활용">6. 네트워크 모듈화(Moya 활용)</h2>
<ul>
<li>목표: Alamofire 대신 Moya를 사용하여 API 요청을 추상화하고, 유지보수성을 높이는 것</li>
<li>성과: 선택한 <code>Moya</code>를 기반으로 <code>APIManager</code> 제작하여 <code>TargetType</code> 으로 작성된 API 요청을 한 곳에서 관리할 수 있도록 설계하였습니다. 이를 통해 새로운 API 추가 시에도 최소한의 코드 변경으로 적용할 수 있게 확장성을 높였습니다.</li>
<li>관련 PR<br>
→ <a href="https://github.com/UMCWegg/iOS_Wegg/pull/86">feat: APIManager 완료</a>에서 Moya 기반 APIManager를 제작하여 API 요청을 구조화 하였습니다.<br>
→ 최종본: <a href="https://github.com/UMCWegg/iOS_Wegg/blob/main/iOS_Wegg/iOS_Wegg/Core/Services/API/APIManager.swift">APIManager.swift</a></li>
<li>문서화<br>
→ 깃허브 Wiki를 활용하여 <code>APIManager</code> 사용법을 공유함. 이를 통해 팀원들이 <code>APIManager</code> 사용법을 금방 숙지하고 적용할 수 있었습니다.<br>
<a href="https://github.com/UMCWegg/iOS_Wegg/wiki/APIManager-%EC%82%AC%EC%9A%A9%EB%B2%95">APIManager 사용법</a></li>
</ul>
<h2 id="7-주석-작성">7. 주석 작성</h2>
<ul>
<li>목표: 내가 작성한 코드를 팀원들이 이해하기 쉽게 하고, 시간이 지나서 코드를 보아도 금방 구조를 이해할 수 있도록 하여 유지보수가 용이하도록 하는 것</li>
<li>성과<ul>
<li>문서화가 필요한 클래스나 함수의 경우 ///을 사용했습니다.</li>
<li><code>// MARK:</code> 를 활용하여 코드 구조를 정리</li>
<li><code>TODO:</code> 와 <code>FIXME</code> 주석을 통해 개선이 필요한 코드 위치를 기록함</li>
</ul></li>
<li>대표적인 소스파일<br>
→ <a href="https://github.com/UMCWegg/iOS_Wegg/blob/main/iOS_Wegg/iOS_Wegg/Core/Services/API/APIManager.swift">APIManager.swift</a><br>
→ <a href="https://github.com/UMCWegg/iOS_Wegg/blob/main/iOS_Wegg/iOS_Wegg/Models/Protocol/MapManagerProtocol.swift">MapManagerProtocol.swift</a></li>
</ul>
<h2 id="8-폰트-및-색상-extension">8. 폰트 및 색상 Extension</h2>
<ul>
<li>목표: 폰트 및 컬러를 Extension 기능을 통해 확장하여 UIFont와 UIColor에서 커스텀 폰트를 사용할 수 있도록 하는 것</li>
<li>성과: 폰트를 UIFont 타입이라면 바로 사용할 수 있게 하였고, 색상 역시 UIColor 타입이라면 언제든 사용 가능했으며, 수정 및 확장에 용이했습니다.</li>
<li>관련 PR:<br>
<a href="https://github.com/UMCWegg/iOS_Wegg/pull/24">style: UIFont를 확장하여 커스텀 폰트 추가</a><a href="https://github.com/UMCWegg/iOS_Wegg/pull/25">style: UIColor에 커스텀 색상 확장</a></li>
</ul>
<h2 id="개발하면서-겪은-문제--해결-과정">개발하면서 겪은 문제 &amp; 해결 과정</h2>
<h2 id="문제-1-github-flow-적용-문제">문제 1) GitHub Flow 적용 문제</h2>
<h3 id="발생한-문제"><strong>발생한 문제</strong></h3>
<ul>
<li>대부분의 팀원이 Git을 잘 다루지 못했고, 브랜치 전략(GitHub Flow)에 익숙하지 않았고, 초반에는 PR &amp; 코드 리뷰 과정이 매끄럽지 않았습니다.</li>
<li>병합 충돌이 자주 발생하여 협업 속도가 저하되었습니다.</li>
</ul>
<h3 id="해결-방법"><strong>해결 방법</strong></h3>
<ul>
<li>GitHub Flow 개념을 설명하는 세션을 진행하고, 사용법을 정리한 문서를 공유하였습니다.</li>
<li>Issue와 PR을 올릴 때 템플릿과 리뷰 프로세스를 확립하여 코드 컨벤션을 맞추도록 유도하였습니다.</li>
<li>초반에는 충돌 해결을 함께 진행하며 가이드를 제공 → 이후 팀원들이 스스로 해결할 수 있도록 하였습니다.<br>
<a href="https://github.com/UMCWegg/iOS_Wegg/pull/33">feat: 게시물 상세뷰 UI 및 화면간 데이터 전달 구현</a>에 병합 가이드를 댓글로 남기면서 팀원들이 스스로 해결하기 시작했습니다.</li>
</ul>
<h3 id="결과"><strong>결과</strong></h3>
<ul>
<li>팀원들이 시간이 지남에 따라 GitHub Flow를 이해하고 스스로 적용하게 되었습니다.</li>
<li>코드 리뷰 문화가 정착되어 전체적인 코드 품질이 향상되었습니다.</li>
<li>프로젝트를 완성하는데 있어 기반을 다졌습니다.</li>
</ul>
<h2 id="문제-2-피그마-디자인을-구현하기-어려운-바텀-시트">문제 2) 피그마 디자인을 구현하기 어려운 바텀 시트</h2>
<h3 id="발생한-문제-1"><strong>발생한 문제</strong></h3>
<ul>
<li>기본 제공되는 <code>UISheetPresentationController</code>로는 피그마 디자인을 100% 재현하기 어려웠습니다..</li>
<li>커스텀 바텀 시트를 직접 구현할까 했지만 시간이 부족했습니다.</li>
</ul>
<h3 id="해결-방법-1"><strong>해결 방법</strong></h3>
<ul>
<li>여러 서드파티 라이브러리를 검토한 후, <code>FloatingPanel</code>이 원하는 기능을 대부분 제공한다는 점을 확인했습니다.</li>
<li><code>FloatingPanel</code>을 적용하면서 필요한 UI 커스텀을 진행하여 피그마 디자인과 최대한 유사하게 만들었습니다.</li>
<li>PR: <a href="https://github.com/UMCWegg/iOS_Wegg/pull/80">feat: 바텀 시트 UI 제작</a></li>
</ul>
<h3 id="결과-및-배운-점"><strong>결과 및 배운 점</strong></h3>
<ul>
<li>“모든 기능을 직접 구현할 필요는 없다” 라는 사실을 머리로는 알고 있었지만 실제 프로젝트에 들어가니 라이브러리를 중간 도입을 고려하기 보다는 직접 만들어서 해결하고자 하였음. 하지만 적절한 서드파티 라이브러리를 활용하면 개발 시간을 절약하면서도 품질을 유지할 수 있음을 체감하게 되었습니다.</li>
<li>기본 API가 한계를 가질 때, 어떤 방식으로 보완할 수 있을지 항상 고민하는 습관이 필요했습니다.</li>
</ul>
<h2 id="문제3-api-연결-시-http-차단-문제-발생"><strong>문제3) API 연결 시 HTTP 차단 문제 발생</strong></h2>
<h3 id="발생한-문제-2"><strong>발생한 문제</strong></h3>
<ul>
<li>애플은 보안 강화를 위해 기본적으로 https 프로토콜을 사용하도록 강제하고 있으며, http 요청은 기본적으로 차단되었습니다.</li>
<li>Info.plist에서 App Transport Security (ATS) 설정을 수정하여 예외적으로 http 요청을 허용하려 했으나, 여전히 네트워크 요청이 차단되는 문제가 발생했습니다.</li>
</ul>
<h3 id="해결-방법-2"><strong>해결 방법</strong></h3>
<ul>
<li>Info.plist에서 NSAppTransportSecurity 키를 추가하고, NSAllowsArbitraryLoads 값을 true로 설정하여 http 요청을 허용하려고 시도했으나 실패했습니다.</li>
<li>서버 개발팀과 논의 후, API를 https 프로토콜로 변경하도록 요청하여 문제를 해결했습니다.</li>
</ul>
<h3 id="결과-및-배운-점-1"><strong>결과 및 배운 점</strong></h3>
<ul>
<li>App Transport Security (ATS) 예외 설정이 모든 경우에 적용되는 것은 아니며, <strong>서버 환경에 따라 추가적인 설정이 필요할 수 있음</strong>을 깨달았습니다.</li>
<li>보안성을 고려했을 때, 가능하면 http 예외 설정을 적용하기보다는 <strong>서버에서</strong> https<strong>를 지원하는 방향으로 해결하는 것이 더 적절함</strong>을 알게되었습니다.</li>
<li>네트워크 연결 문제가 발생했을 때, <strong>클라이언트 단에서만 해결하려 하지 말고 서버 환경까지 고려하여 접근하는 것이 중요</strong>함을 다시 한 번 경험했습니다.</li>
</ul>
<h2 id="기획-및-디자인">기획 및 디자인</h2>
<p><img src="https://velog.velcdn.com/images/jwlee010523/post/059c234c-24d2-485c-9149-d501265c88ad/image.png"></p>
<p><img src="https://velog.velcdn.com/images/jwlee010523/post/b9e324ae-831a-49ba-8ee7-80662dfd5306/image.png"></p>
<h3 id="1-초기-화면-설계-개요"><strong>1. 초기 화면 설계 개요</strong></h3>
<ul>
<li>처음에는 <strong>탭 별로 기능을 나누는 방식</strong>을 고려했지만, 기능 중복 위험이 있어 <strong>기능별 역할을 나누는 방식</strong>으로 결정 했습니다.</li>
<li>이 과정에서 <strong>GitHub 브랜치 전략과도 잘 맞아떨어진다고 판단</strong>하여, 초기 설계부터 협업을 고려한 구조를 반영하였습니다.</li>
</ul>
<h3 id="2-디자인-변경-과정--영향"><strong>2. 디자인 변경 과정 &amp; 영향</strong></h3>
<ul>
<li><strong>디자인 확정이 늦어지면서 개발 일정이 약 2주 지연되었습니다.</strong></li>
<li>개발이 진행되는 도중 <strong>디자인이 일부 변경되면서, 추가 구현이 필요해져 일정이 더욱 촉박해졌습니다.</strong><ul>
<li><strong>바텀 시트 UI 변경 → FloatingPanel 적용하여 레이아웃 재조정</strong></li>
<li><strong>지도 화면 애니메이션 추가 → 기존 네비게이션 구조 수정 필요</strong></li>
</ul></li>
<li>일정이 부족하여 <strong>일부 기능의 구현 방식이나 코드 구조를 빠르게 변경해야 했습니다.</strong></li>
</ul>
<h3 id="3-디자인-확정-후-개발-프로세스-정리"><strong>3. 디자인 확정 후, 개발 프로세스 정리</strong></h3>
<ul>
<li><strong>디자인이 최종 확정된 후, 더 이상 추가 일정 지연 없이 개발을 진행했습니다.</strong></li>
<li><strong>UI/UX 변경으로 인해 발생했던 코드 리팩토링을 통해, 유지보수성을 고려한 코드 설계를 적용할 수 있었습니다.</strong>  <strong>→ FloatingPanel 기반 바텀 시트 커스텀 마무리</strong><br>
</li>
</ul>
<h2 id="아쉬운-점--개선-방향-추가">아쉬운 점 &amp; 개선 방향 추가</h2>
<h3 id="1-실시간-푸쉬-알람-미구현"><strong>1) 실시간 푸쉬 알람 미구현</strong></h3>
<ul>
<li>실시간 푸쉬 알람을 구현하기 위해서는 APNs를 사용하는 방법 외엔 다른 방법이 었었다. APNs를 사용하기 위해 유료 개발자 계정이 필요했지만, 팀원들이 구매하지 않기로 결정하여 MVP 단계에서는 제외되었습니다.</li>
<li><strong>개선 방향:</strong> 추후 프로젝트에서 실시간 알람이 중요한 경우, 기획 단계에서 Firebase Cloud Messaging(FCM)과 APNs 구현 가능 여부를 검토해야 하는 것을 알았습니다.</li>
</ul>
<h3 id="2-초기-디자인-변경으로-인한-일정-차질"><strong>2) 초기 디자인 변경으로 인한 일정 차질</strong></h3>
<ul>
<li>디자인 확정이 늦어지면서 대부분의 페이지 및 기능이 예상보다 약 2주정도 개발이 지연되었습니다.</li>
<li><strong>개선 방향:</strong> 초기 기획 단계에서 디자인 피드백 일정을 조정하여 개발 착수를 지연시키지 않도록 개선이 필요했습니다.</li>
</ul>
<h3 id="3-코드-리뷰의-어느정도로-할-것인지">3) 코드 리뷰의 어느정도로 할 것인지</h3>
<p>코드 리뷰를 하다보면 초반에 함께 설정한 그라운드 룰은 어느정도 준수하는 것이 보였지만, 중복 코드, 폴더링 문제, ViewController에서 구현해야 할 부분들을 View에서 구현하는 등 자잘한 문제들이 보였습니다.</p>
<p>수정을 요청할까 고민했지만, 팀원들이 UIKit과 아키텍처에 대해 아직 익숙하지 않은 상태에서 너무 세세한 피드백을 주면 오히려 개발 속도를 저하시키고 사기를 떨어뜨릴까봐 걱정되었습니다.</p>
<p>다행히 프로젝트는 초반에 설정한 코딩 컨벤션을 크게 벗어나지 않으며 무사히 마무리 할 수 있었지만, 코드 리뷰의 깊이를 어느 정도까지 가져가야 하는지에 대한 고민이 남았다. 이건 팀원들의 역량과 주어진 요건 등을 잘 파악하여 결정해야 하는 문제라 생각됩니다.</p>
<p>이번 프로젝트는 이런 고민을 할 수 있는 계기를 갖게 된 거 같습니다. 또한 이번에는 혼자서 팀원들의 코드를 리뷰했는데, 다음 프로젝트에서는 그룹 코드 리뷰 도입을 고려하여 팀원들의 코드 이해도를 함께 끌어올리는 방향으로 진행해 볼 계획입니다.</p>
<h2 id="마무리-및-느낀점">마무리 및 느낀점</h2>
<p>이번 프로젝트를 통해 <strong>GitHub 협업 방식, 코드 리뷰 문화, 네트워크 모듈화, SOLID 원칙 적용</strong> 등의 중요성을 실제로 경험할 수 있었습니다.</p>
<p>특히, <strong>팀원들과 함께 코드 품질을 유지하면서 협업하는 것이 혼자 개발할 때보다 훨씬 어려운 과정</strong>임을 체감했다. 하지만 그만큼 <strong>“팀 개발에서 무엇을 신경 써야 하는지”</strong>에 대한 감각이 생겼고, 앞으로도 이를 더 개선해 나가야겠다고 생각했습니다.</p>
<p>또한, 초기에는 SOLID 원칙을 준수하며 개발하고자 했지만, 일정이 촉박해지면서 일부 모듈에서 중복 코드가 발생하거나 의존성이 강한 구조가 남게 된 점이 아쉬웠습니다. 특히, ViewController가 비대해지는 것을 해결하며 개발하지 못한 것이 아쉽습니다.</p>
<p>다음 프로젝트에서는 <strong>설계 단계에서 협업 환경을 더 원활하게 만들고, 유지보수성을 고려한 코드를 작성하는 것</strong>을 더욱 신경 쓸 것입니다.</p></div></div>

jwlee010523.log

프로젝트 개요
이 프로젝트는 UMC 7기 활동으로 시작했고, GitHub 협업 방식, 코드 리뷰 문화, 유지보수성을 고려한 설계 등을 경험하는 것을 목표로 했습니다.
또한, 혼자 iOS 개발을 담당했던 과거와 달리, 다른 iOS 개발자들과 협업하여 효과적인 협업 방식과 여러명에서 하나의 프로젝트를 완성하는데 필요한 프로세스들을 배우는 것도 중요한 목표였습니다.
깃허브 주소
https://github.com/UMCWegg/iOS_Wegg
프로젝트 목표 및 성과
1. GitHub Flow 브랜치 전략 적용
목표: GitHub Flow 도입 & 브랜치 보호 전략 적용(Issue & PR 활용)
성과: GitHub Flow 도입과 함께 브랜치 보호 전략을 적용하고, Issue 및 PR 템플릿을 활용하여 코드 리뷰 시 일관된 기준을 마련했습니다. 이를 통해 팀원들이 코드 리뷰 시 놓치기 쉬운 부분을 체크할 수 있도록 유도했습니다.
관련 PR:
#1 Initial Set Up#28 docs: PR 템플릿 업데이트
2. 클린 아키텍처를 적용한 폴더링 설계
목표: 유지보수를 고려한 폴더 구조를 설계하여 코드 관리의 효율성을 높이는 것
성과: Screen, Core, Componenet, Models, Resources 등의 폴더를 분리하여 역할별 관리가 가능하도록 구성하였습니다. 이를 통해 모둘별 폴더링 적용으로 유지보수 용이하게 하였고, 각 레이어의 역할을 명확하게 분리하여 가독성을 높일 수 있었습니다.
관련 PR: docs: 초기 폴더 구조 구성 완료
3. SwiftLint 적용하여 코드 컨벤션 통일
목표: 팀원 간 일관된 코드 스타일을 유지하고, 오류를 사전에 방지시키기 위해 SwiftLint를 적용하는 것
성과: SwiftLint를 초기에 도입하여 코드 컨벤션을 강제하였습니다. 특히, force_unwrapping을 설정하여 앱 실행 중 크래시를 방지했고, line_length를 통해 가독성을 향상시켰습니다.
관련 PR: dosc: SwiftLint 설정 완료
4. SOLID 원칙을 고려한 네이버 지도 모듈화
목표: 네이버 지도 SDK 의존성을 줄이고, 유지보수성을 높이기 위해 SOLID 원칙을 적용하여 모듈화 하는 것
성과: MapManagerProtocol을 정의하여 네이버 지도 SDK와의 강한 결합을 줄이고, 추후 다른 지도 API로 교체할 수 있도록 유연한 구조로 설계하였습니다.
관련 PR
→ 초기 PR: feat: 네이버 지도 뷰 띄우기 & 커스텀 핀 마커 생성
→ 최종본: MapManagerProtocol.swift
5. UIKit + SnapKit 활용한 UI 개발
목표: 스토리보드 없이 코드 기반으로 UI 개발하고, Snapkit을 활용하여 AutoLayout을 설정하는 것.
성과
UIView 이미지 변환, 네비게이션 커스텀 등 다양한 기법 적용하였습니다.
→ feat: 장소 인증 페이지 제작 및 화면 이동에서 인증 안내 뷰(UIView)를 UIImage로 변환하여 네이버 지도 위의 마커로 생성.
→ feat: 커스텀 검색바 제작 및 검색 결과 페이지 UI 제작에서 네비게이션 스택이 중복으로 쌓이지 않도록 하고, 애니메이션 커스텀.
→ feat: 일정 페이지 UI 제작에서 기존에 알고 있던 UITableviewDataSoure 대신 DiffableDataSource를 사용하여 자동으로 셀 데이터 변화를 감지하게 하고 애니메이션을 추가함. 이를 통해 사용자 경험과 유지보수성을 향상.
→ feat: 지각 토글 여부에 따른 지각 버튼 활성화 에서 지각 여부 토글을 적용할 때 updateConstraint를 활용하여 UI가 자연스럽게 변경되도록 설계.
6. 네트워크 모듈화(Moya 활용)
목표: Alamofire 대신 Moya를 사용하여 API 요청을 추상화하고, 유지보수성을 높이는 것
성과: 선택한 Moya를 기반으로 APIManager 제작하여 TargetType 으로 작성된 API 요청을 한 곳에서 관리할 수 있도록 설계하였습니다. 이를 통해 새로운 API 추가 시에도 최소한의 코드 변경으로 적용할 수 있게 확장성을 높였습니다.
관련 PR
→ feat: APIManager 완료에서 Moya 기반 APIManager를 제작하여 API 요청을 구조화 하였습니다.
→ 최종본: APIManager.swift
문서화
→ 깃허브 Wiki를 활용하여 APIManager 사용법을 공유함. 이를 통해 팀원들이 APIManager 사용법을 금방 숙지하고 적용할 수 있었습니다.
APIManager 사용법
7. 주석 작성
목표: 내가 작성한 코드를 팀원들이 이해하기 쉽게 하고, 시간이 지나서 코드를 보아도 금방 구조를 이해할 수 있도록 하여 유지보수가 용이하도록 하는 것
성과
문서화가 필요한 클래스나 함수의 경우 ///을 사용했습니다.
// MARK: 를 활용하여 코드 구조를 정리
TODO: 와 FIXME 주석을 통해 개선이 필요한 코드 위치를 기록함
대표적인 소스파일
→ APIManager.swift
→ MapManagerProtocol.swift
8. 폰트 및 색상 Extension
목표: 폰트 및 컬러를 Extension 기능을 통해 확장하여 UIFont와 UIColor에서 커스텀 폰트를 사용할 수 있도록 하는 것
성과: 폰트를 UIFont 타입이라면 바로 사용할 수 있게 하였고, 색상 역시 UIColor 타입이라면 언제든 사용 가능했으며, 수정 및 확장에 용이했습니다.
관련 PR:
style: UIFont를 확장하여 커스텀 폰트 추가style: UIColor에 커스텀 색상 확장
개발하면서 겪은 문제 & 해결 과정
문제 1) GitHub Flow 적용 문제
발생한 문제
대부분의 팀원이 Git을 잘 다루지 못했고, 브랜치 전략(GitHub Flow)에 익숙하지 않았고, 초반에는 PR & 코드 리뷰 과정이 매끄럽지 않았습니다.
병합 충돌이 자주 발생하여 협업 속도가 저하되었습니다.
해결 방법
GitHub Flow 개념을 설명하는 세션을 진행하고, 사용법을 정리한 문서를 공유하였습니다.
Issue와 PR을 올릴 때 템플릿과 리뷰 프로세스를 확립하여 코드 컨벤션을 맞추도록 유도하였습니다.
초반에는 충돌 해결을 함께 진행하며 가이드를 제공 → 이후 팀원들이 스스로 해결할 수 있도록 하였습니다.
feat: 게시물 상세뷰 UI 및 화면간 데이터 전달 구현에 병합 가이드를 댓글로 남기면서 팀원들이 스스로 해결하기 시작했습니다.
결과
팀원들이 시간이 지남에 따라 GitHub Flow를 이해하고 스스로 적용하게 되었습니다.
코드 리뷰 문화가 정착되어 전체적인 코드 품질이 향상되었습니다.
프로젝트를 완성하는데 있어 기반을 다졌습니다.
문제 2) 피그마 디자인을 구현하기 어려운 바텀 시트
발생한 문제
기본 제공되는 UISheetPresentationController로는 피그마 디자인을 100% 재현하기 어려웠습니다..
커스텀 바텀 시트를 직접 구현할까 했지만 시간이 부족했습니다.
해결 방법
여러 서드파티 라이브러리를 검토한 후, FloatingPanel이 원하는 기능을 대부분 제공한다는 점을 확인했습니다.
FloatingPanel을 적용하면서 필요한 UI 커스텀을 진행하여 피그마 디자인과 최대한 유사하게 만들었습니다.
PR: feat: 바텀 시트 UI 제작
결과 및 배운 점
“모든 기능을 직접 구현할 필요는 없다” 라는 사실을 머리로는 알고 있었지만 실제 프로젝트에 들어가니 라이브러리를 중간 도입을 고려하기 보다는 직접 만들어서 해결하고자 하였음. 하지만 적절한 서드파티 라이브러리를 활용하면 개발 시간을 절약하면서도 품질을 유지할 수 있음을 체감하게 되었습니다.
기본 API가 한계를 가질 때, 어떤 방식으로 보완할 수 있을지 항상 고민하는 습관이 필요했습니다.
문제3) API 연결 시 HTTP 차단 문제 발생
발생한 문제
애플은 보안 강화를 위해 기본적으로 https 프로토콜을 사용하도록 강제하고 있으며, http 요청은 기본적으로 차단되었습니다.
Info.plist에서 App Transport Security (ATS) 설정을 수정하여 예외적으로 http 요청을 허용하려 했으나, 여전히 네트워크 요청이 차단되는 문제가 발생했습니다.
해결 방법
Info.plist에서 NSAppTransportSecurity 키를 추가하고, NSAllowsArbitraryLoads 값을 true로 설정하여 http 요청을 허용하려고 시도했으나 실패했습니다.
서버 개발팀과 논의 후, API를 https 프로토콜로 변경하도록 요청하여 문제를 해결했습니다.
결과 및 배운 점
App Transport Security (ATS) 예외 설정이 모든 경우에 적용되는 것은 아니며, 서버 환경에 따라 추가적인 설정이 필요할 수 있음을 깨달았습니다.
보안성을 고려했을 때, 가능하면 http 예외 설정을 적용하기보다는 서버에서 https를 지원하는 방향으로 해결하는 것이 더 적절함을 알게되었습니다.
네트워크 연결 문제가 발생했을 때, 클라이언트 단에서만 해결하려 하지 말고 서버 환경까지 고려하여 접근하는 것이 중요함을 다시 한 번 경험했습니다.
기획 및 디자인
1. 초기 화면 설계 개요
처음에는 탭 별로 기능을 나누는 방식을 고려했지만, 기능 중복 위험이 있어 기능별 역할을 나누는 방식으로 결정 했습니다.
이 과정에서 GitHub 브랜치 전략과도 잘 맞아떨어진다고 판단하여, 초기 설계부터 협업을 고려한 구조를 반영하였습니다.
2. 디자인 변경 과정 & 영향
디자인 확정이 늦어지면서 개발 일정이 약 2주 지연되었습니다.
개발이 진행되는 도중 디자인이 일부 변경되면서, 추가 구현이 필요해져 일정이 더욱 촉박해졌습니다.
바텀 시트 UI 변경 → FloatingPanel 적용하여 레이아웃 재조정
지도 화면 애니메이션 추가 → 기존 네비게이션 구조 수정 필요
일정이 부족하여 일부 기능의 구현 방식이나 코드 구조를 빠르게 변경해야 했습니다.
3. 디자인 확정 후, 개발 프로세스 정리
디자인이 최종 확정된 후, 더 이상 추가 일정 지연 없이 개발을 진행했습니다.
UI/UX 변경으로 인해 발생했던 코드 리팩토링을 통해, 유지보수성을 고려한 코드 설계를 적용할 수 있었습니다.
  → FloatingPanel 기반 바텀 시트 커스텀 마무리
아쉬운 점 & 개선 방향 추가
1) 실시간 푸쉬 알람 미구현
실시간 푸쉬 알람을 구현하기 위해서는 APNs를 사용하는 방법 외엔 다른 방법이 었었다. APNs를 사용하기 위해 유료 개발자 계정이 필요했지만, 팀원들이 구매하지 않기로 결정하여 MVP 단계에서는 제외되었습니다.
개선 방향: 추후 프로젝트에서 실시간 알람이 중요한 경우, 기획 단계에서 Firebase Cloud Messaging(FCM)과 APNs 구현 가능 여부를 검토해야 하는 것을 알았습니다.
2) 초기 디자인 변경으로 인한 일정 차질
디자인 확정이 늦어지면서 대부분의 페이지 및 기능이 예상보다 약 2주정도 개발이 지연되었습니다.
개선 방향: 초기 기획 단계에서 디자인 피드백 일정을 조정하여 개발 착수를 지연시키지 않도록 개선이 필요했습니다.
3) 코드 리뷰의 어느정도로 할 것인지
코드 리뷰를 하다보면 초반에 함께 설정한 그라운드 룰은 어느정도 준수하는 것이 보였지만, 중복 코드, 폴더링 문제, ViewController에서 구현해야 할 부분들을 View에서 구현하는 등 자잘한 문제들이 보였습니다.
수정을 요청할까 고민했지만, 팀원들이 UIKit과 아키텍처에 대해 아직 익숙하지 않은 상태에서 너무 세세한 피드백을 주면 오히려 개발 속도를 저하시키고 사기를 떨어뜨릴까봐 걱정되었습니다.
다행히 프로젝트는 초반에 설정한 코딩 컨벤션을 크게 벗어나지 않으며 무사히 마무리 할 수 있었지만, 코드 리뷰의 깊이를 어느 정도까지 가져가야 하는지에 대한 고민이 남았다. 이건 팀원들의 역량과 주어진 요건 등을 잘 파악하여 결정해야 하는 문제라 생각됩니다.
이번 프로젝트는 이런 고민을 할 수 있는 계기를 갖게 된 거 같습니다. 또한 이번에는 혼자서 팀원들의 코드를 리뷰했는데, 다음 프로젝트에서는 그룹 코드 리뷰 도입을 고려하여 팀원들의 코드 이해도를 함께 끌어올리는 방향으로 진행해 볼 계획입니다.
마무리 및 느낀점
이번 프로젝트를 통해 GitHub 협업 방식, 코드 리뷰 문화, 네트워크 모듈화, SOLID 원칙 적용 등의 중요성을 실제로 경험할 수 있었습니다.
특히, 팀원들과 함께 코드 품질을 유지하면서 협업하는 것이 혼자 개발할 때보다 훨씬 어려운 과정임을 체감했다. 하지만 그만큼 “팀 개발에서 무엇을 신경 써야 하는지”에 대한 감각이 생겼고, 앞으로도 이를 더 개선해 나가야겠다고 생각했습니다.
또한, 초기에는 SOLID 원칙을 준수하며 개발하고자 했지만, 일정이 촉박해지면서 일부 모듈에서 중복 코드가 발생하거나 의존성이 강한 구조가 남게 된 점이 아쉬웠습니다. 특히, ViewController가 비대해지는 것을 해결하며 개발하지 못한 것이 아쉽습니다.
다음 프로젝트에서는 설계 단계에서 협업 환경을 더 원활하게 만들고, 유지보수성을 고려한 코드를 작성하는 것을 더욱 신경 쓸 것입니다.

Wegg 프로젝트 회고

댓글