GearFirst
제조/물류 운영을 위한 ERP형 대시보드(Web) + 발주 핵심 플로우(iOS) 프론트엔드 구현
나의 역할
Frontend
구성원
Backend 2명 Frontend 3명
작업기간
2025.07.10 - 2025.07.23 (2주)
프로젝트 개요
GearFirst는 제조/물류 운영을 지원하는 ERP형 대시보드(Web)와 현장 발주 업무를 빠르게 처리하는 iOS 앱을 함께 제공하는 프로젝트입니다. 저는 Web에서는 프로젝트 초기 뼈대와 공통 UX 인프라를 먼저 고정해 ‘빠르게 붙고, 덜 깨지는’ 구조를 만드는 데 집중했고, 입고·BOM·품목 등 핵심 도메인 API 연동의 안정화에 기여했습니다. iOS에서는 발주 도메인의 핵심 사용자 여정(요청 → 이력 → 상세)을 SwiftUI + MVVM으로 설계·구현하고, 네트워크 레이어(APIConfig/NetworkManager/PurchaseOrderAPI)를 구조화하여 발주 상태/이력 조회, 발주요청/취소까지 실제 API 연동을 완성했습니다. 결과적으로 Web–iOS가 같은 도메인 규칙을 공유하면서도 각 플랫폼에서 운영 친화적인 탐색/상태 표현/에러 정책을 일관되게 제공하도록 정리했습니다.
주요 화면
담당 역할 / 업무
Web: 초기 구조 설계 및 확장 가능한 레이아웃 구축
TopBar/SideBar/Layout/AppRoutes를 먼저 세워 이후 도메인 추가 속도를 높이고, 화면 일관성을 강하게 고정했습니다.
Web: 공통 UX 인프라 표준화
버튼, 검색, 날짜 선택, 페이지네이션, 스크롤 테이블, 모달 레이아웃, 로딩 오버레이까지 공통화해 구현 비용과 화면 편차를 줄였습니다.
Web: 핵심 도메인 API 연동 주도
입고(Inbound), BOM, 품목(부품/자재/카테고리), 인증/권한, 차량모델 등에서 API 연동과 화면 완성도를 함께 끌어올렸습니다.
iOS: 발주 핵심 플로우(요청/이력/상세) 설계 및 구현
OrderRequestView, OrderHistoryView, OrderDetailView를 중심으로 화면 구조, 상태 흐름, 상호작용을 주도적으로 설계하고 완성했습니다.
iOS: 발주 API 연동 및 네트워크 레이어 구조화
APIConfig, NetworkManager, PurchaseOrderAPI로 책임을 분리하고 URLSession + async/await 기반으로 호출/디코딩/에러 흐름을 일관되게 정리했습니다.
iOS: 공통 컴포넌트화 및 운영형 리스트 UX 개선
BottomBar, EditableField(제네릭), BaseButton, SectionCard, StepProgressView 등을 정리해 일관성을 확보하고, OrderHistory에 필터·검색·건수·새로고침을 도입해 탐색성과 즉시성을 강화했습니다.
주요 성과
- Web–iOS를 하나의 도메인 프로젝트로 묶어, 플랫폼별 핵심 플로우를 실제 운영 시나리오 기준으로 완성
- Web 초기 라우팅/레이아웃 뼈대를 고정해 이후 도메인 확장 속도와 화면 일관성을 개선
- Web 로딩 처리 표준화(페이지/모달)로 비동기 화면의 깜빡임·상태 꼬임을 크게 감소
- iOS 발주 여정(요청 → 이력 → 상세)을 실제 API와 연결해 ‘동작하는 플로우’로 완성
- iOS 네트워크 레이어를 화면 코드에서 분리해 변경 영향 범위를 줄이고 유지보수성을 개선
- 운영형 리스트(필터·검색·새로고침·건수 표시) 강화로 데이터 누적 환경에서의 탐색 경험을 개선
- OAuth2 + PKCE 및 권한 가드 도입(웹)과 401 공통 처리(iOS)로 인증 만료/접근 제어 안정성 확보
트러블슈팅
로딩 UX 불일치로 인한 화면 신뢰도 저하 (Web)
이슈: 페이지/모달마다 로딩 방식이 달라 ‘멈춘 것처럼 보임/깜빡임’이 반복되어 사용자가 화면 상태를 신뢰하기 어려웠음.
해결: LoadingOverlay + 공통 모달 레이아웃 중심으로 로딩 패턴을 통일하고 주요 화면에 일괄 적용했습니다.
💡 배운 점: 대시보드에서는 ‘정확한 데이터’만큼 ‘안정적으로 보이는 상태 관리’가 핵심이며, UX 표준화가 유지보수성과 직결된다는 점을 체득했습니다.
서버 상태값과 진행률 UI의 불일치 문제 (iOS)
이슈: 서버 상태를 그대로 노출하면 단계형 진행 UI(색상/단계/라벨)가 쉽게 깨지거나 일관성이 무너질 수 있었음.
해결: 도메인 모델(RequestOrderItem)과 StepProgressView 중심으로 상태 매핑 규칙을 고정하고, 화면은 매핑된 상태만 사용하도록 정리했습니다.
💡 배운 점: 상태 기반 UI는 ‘서버 상태 → 도메인 상태 → 화면 상태’의 변환 계층을 명확히 둘수록 안정적이라는 점을 배웠습니다.
OAuth 리다이렉트/도메인 불일치 이슈 (Web)
이슈: 로컬/배포 환경 차이로 로그인/로그아웃 흐름이 자주 깨지고, 리다이렉트 경로가 엇갈리며 장애가 발생했음.
해결: 환경 변수/redirect 유틸/라우팅 경로를 정리하고 인증 경로를 구조적으로 고정했습니다.
💡 배운 점: 인증은 기능 구현보다 ‘경로·환경 정합성’이 본질이며, 이를 코드 구조로 강제해야 안정화된다는 점을 배웠습니다.
인증 만료(401) 시 쓰기 요청 실패 대응 (iOS)
이슈: 발주요청/취소 같은 쓰기 API에서 401이 발생하면 흐름이 중간에 붕괴하고 원인 파악이 어려워질 수 있었음.
해결: API 레이어에서 401을 감지하고 공통 경로(알림/세션 처리)로 넘기도록 정리해 예외 상황을 한곳에서 다루게 했습니다.
💡 배운 점: 에러 정책은 화면마다 흩어지기보다 API 레이어에서 일관되게 관리할수록 안전하다는 점을 배웠습니다.
이력 화면의 탐색성 한계 (iOS)
이슈: 데이터가 누적될수록 원하는 항목을 찾는 시간이 길어지고, 최신 상태 반영에 대한 신뢰도도 떨어질 수 있었음.
해결: 필터, 검색, 건수 표시, pull-to-refresh를 도입해 ‘정제·탐색·갱신’ 흐름을 한 화면에서 해결하도록 개선했습니다.
💡 배운 점: 운영형 리스트는 단순 렌더링보다 탐색 도구와 갱신 경험이 핵심이라는 점을 체감했습니다.