흩어진 분철 정보와 불투명한 참여 현황을 정리해, 원하는 분철을 빠르고 투명하게 참여할 수 있도록 돕는 서비스
팬덤 문화에서 원하는 멤버의 굿즈를 갖기 위해 물품을 공동 구매하여 나누는 행위
현재의 분철은 플랫폼 이동 + 반복 소통이 필수인 비효율적인 구조
- 분철 정보가 여러 곳에 흩어져 있어 탐색이 어렵습니다.
- 진행 상황을 수동으로 체크하고, 입금/배송 상태를 개인의 기억에 의존해야 합니다.
- 신뢰 판단 기준이 없어 모집자와 참여자 모두 피로도가 높습니다.
- 검색의 비효율 ->
옵션 기반 검색 · 아이돌 굿즈 추천 시스템으로 해결합니다. - 진행 관리의 불편함 ->
진행 상황 상태바 · 참여자 관리 페이지로 해결합니다. - 신뢰와 안전에 대한 불안 ->
EMA 별점 시스템 도입 · 거래 이력 기반 신뢰도 시스템으로 해결합니다.
 |
 |
|---|---|
| 김나연 | 김수민 |
| iOS Lead Developer | iOS Developer |
 |
 |
|---|---|
| 박정환 | 이서현 |
| iOS Developer | iOS Developer |
| 기술 / 라이브러리 | 목적 |
|---|---|
| UIKit | 안정적이고 풍부한 레퍼런스, 우수한 호환성, 예측 가능한 UI 레이아웃 작업 |
| MVVM | UI, 비즈니스 로직 분리를 통해 화면 상태 변화를 명확하게 관리, 유지보수성 강화 |
| Clean Architecture | 도메인 중심의 의존성 분리를 통해 변경에 강하고 확장 가능한 구조 구축 |
| Alamofire | 간결한 네트워크 요청과 구조화된 관리 방식으로 코드 가독성과 유지보수성 향상 |
| Combine | 비동기 데이터 흐름을 선언적으로 관리, 상태 변화에 따른 UI 업데이트 처리 |
| Snapkit | 간편한 Auto Layout 적용 |
| Then | UI 코드 작성시 편의성 향상 |
| Kingfisher | 효율적인 이미지 다운로드 및 캐싱을 통해 네트워크 이미지 로딩 성능 향상 |
| Lottie | JSON 기반 애니메이션 활용을 위해 사용 |
| Logger | 구조화된 로깅을 지원하여 성능 저하 없이 효율적으로 로그 수집 및 분석 가능 |
| KakaoOpenSDK | 카카오 소셜 로그인을 위해 사용 |
| Swift Concurrency | 명확하고 안전한 비동기 흐름 관리를 통해 복잡한 비동기 로직의 가독성과 유지보수성 향상 |
📁 Poti-iOS
├── 📁 Application
│ ├── 📝 AppDelegate.swift
│ ├── 📝 SceneDelegate.swift
│ └── 📝 AppDIContainer.swift
│
├── 📁 Core
│ ├── 📝 PotiError.swift
│ └── 📝 PotiLogger.swift
│
├── 📁 Data
│ ├── 📁 Network
│ │ └── 📁 Auth
│ │ ├── 📁 DTO
│ │ ├── 📝 AuthService.swift
│ │ └── 📝 AuthAPI.swift
│ │
│ └── 📁 Repository
│
├── 📁 Domain
│ ├── 📁 Entity
│ ├── 📁 Interface
│ └── 📁 UseCase
│
├── 📁 Presentation
│ ├── 📁 Splash
│ ├── 📁 Onboarding
│ ├── 📁 Home
│ │
│ └── 📁 Common
│ ├── 📁 Base
│ │ ├── 📝 BaseViewController.swift
│ │ └── 📝 BaseViewModel.swift
│ ├── 📁 Component
│ ├── 📁 Extension
│ └── 📁 Protocol
│
├── 📁 Resource
│ │ ├── Assets.xcassets
│ │ └── 📁 Fonts
Swift Style Guide를 따릅니다.
- Tag
| 태그 | 사용하는 부분 |
|---|---|
| [feat] | 새로운 기능 구현 |
| [fix] | 버그, 오류 해결 |
| [chore] | 코드 수정, 내부 파일 수정 등 중요도가 낮은 기타 작업 |
| [add] | 라이브러리 또는 에셋 추가 |
| [del] | 쓸모없는 코드 삭제 |
| [docs] | README나 WIKI 등의 문서 개정 |
| [refactor] | 기존 코드 리팩토링 또는 구조 개선 |
| [setting] | 프로젝트 관련 설정 변경 |
| [merge] | Pull Develop |
- Message
(커밋 메세지 형식)
[종류] #이슈번호 - 작업 내용
(기본 커밋 메시지 예시)
[feat] #1 - 메인 UI 구현
(Conflict 해결 시)
[merge] #이슈번호 - Conflict 해결
(PR을 develop에 merge 시)
[merge] #이슈번호 - 작업 내용 간략히
Default Branch & PR Target : develop
모든 개발은 develop 브랜치를 중심으로 진행됩니다.
1. 작업할 내용에 대해 이슈를 판다. (이슈 제목: [태그] 작업 내용)
2. develop 브랜치로부터 새 브랜치를 만든다. (브랜치 명: 타입/#이슈번호)
- 브랜치 파기 전 최신화 된 develop 브랜치 pull 받기
3. 만든 브랜치에서 작업한다.
4. 커밋은 쪼개서 작성하며 컨벤션을 따라 메시지를 작성한다.
5. 작업할 내용을 다 끝내면 에러 없이 잘 실행되는지 확인 한 후 push 한다.
- PR 올리기 전 작업 브랜치에 develop 브랜치 pull 받은 뒤 충돌을 해결한 후 push 하는 것을 권장
6. PR을 작성한 후, 팀원들의 코드리뷰를 반영한 뒤 develop 브랜치에 merge 한다.
- 깃허브 내에서 merge 할 때 메시지 변경하기 ([merge #이슈번호 - 작업 내용)