혼자 떠나는 사람이 여행 동행을 만나고,
혼여행자를 위한 게스트하우스에 머무는 앱.
iOS · Android · 2024.11 → 2026.06 · 화면 150여 개 · 개발 2명 + 디자이너 1명
Note
프론트엔드 담당자의 시선에서 작성한 회고입니다. 상용·팀 프로젝트라 앱 소스 전체는 담지 않았고, 설계 의도가 드러나는 부분만 시크릿을 걷어내고 발췌했습니다. 같은 프로젝트의 서버 이야기는 pill27211/align-retrospective에 따로 있습니다.
앱을 처음 켠 사람이 어떤 순서로 화면을 지나가는지 그대로 따라가 보겠습니다. 각 화면에서 무엇을 고민했는지도 함께 적었습니다.
Note
프로젝트가 멈추면서 서버도 함께 내려가 지금은 앱을 켜도 데이터가 오지 않습니다. 그래서 화면을 다시 보여줄 수 있도록 일부 화면은 앱이 서버에 보내는 요청을 가로채 준비된 응답을 돌려주는 목 서버를 붙이고, 실제 기기에서 앱을 띄워 촬영했습니다.
 |
설명이 필요한 서비스라 여기서 개념이 전달되지 않으면 사용자는 그냥 나갑니다. 그래서 네 문장을 한 화면에 몰아넣지 않고 한 장에 하나씩 두었고 각 화면 안에서도 제목 → 설명 → 이미지 순으로 시차를 줬습니다. 장식으로 넣은 시차가 아닙니다. 시선의 순서를 만들려고 넣었습니다. 마지막 화면에서 소셜 로그인 네 종류로 이어집니다. |
 |
 |
목록과 지도, 두 갈래로 찾습니다. 지도 쪽이 이 앱에서 기술적으로 가장 많이 손을 댄 화면입니다. 손가락이 움직이는 내내 카메라 콜백이 오는데 그때마다 "이 화면의 숙소 주세요"라고 물으면 드래그 한 번에 요청이 수십 번 나갑니다. 한반도를 2,066개의 고정 격자로 나눠, 연속적인 좌표 문제를 정수 집합 문제로 바꿨습니다. 직접 재보니 16번 드래그에 서버 호출은 1번, 필요한 타일 64개 중 61개를 캐시가 받아냈습니다. → 지도 타일링 |
 |
 |
숙소를 고르기 전에 공간과 호스트를 먼저 보여주는 쪽으로 설계했습니다. 사진 · 편의시설 · 환불 규정 · 리뷰가 한 화면 안의 탭으로 붙어 있습니다. 예약은 객실 → 날짜 → 인원 → 확인의 네 단계입니다. 각 단계가 앞 단계의 선택에 따라 가능한 범위가 달라집니다. 뒤로 돌아갔을 때 이미 고른 값이 어긋나지 않게 맞추는 일이 생각보다 손이 갔습니다. |
 |
이 앱의 핵심입니다. 오늘 갈 동행을 찾거나 직접 만들고 신청·수락을 거쳐 자동으로 만들어진 그룹 채팅에서 모입니다. 처음 만나는 사이라는 전제 때문에 화면에도 장치가 들어갔습니다. 신청 수락제, 후기, 그리고 안심 동행 게이지 — 가입 기간·활동 이력 같은 조건을 채울수록 차오르는 지표입니다. 한 번에 다 묻지 않고 지역·날짜 → 소개 → 계획의 3단계로 쪼갠 이유도 같습니다. 낯선 사람에게 보여줄 정보를 한 화면에서 결정하게 하면 부담이 큽니다. |
 |
 |
커뮤니티는 여행지에서 사진을 잔뜩 올리는 곳입니다. 네트워크가 불안정한 상태에서 사진 열 장을 걸어 놓고 앱을 나가는 게 정상적인 사용 패턴입니다. 그래서 업로드를 앱 생명주기 밖으로 빼고 큐 자체를 디스크에 저장했습니다. 일정 탭은 예약과 동행이 모이는 곳입니다. 직접 추가한 일정도 함께 놓입니다. |
 |
 |
게스트 앱과 호스트 앱이 한 바이너리 안에 들어 있습니다. 권한이 바뀌면 하단 탭 다섯 개가 통째로 교체됩니다.
두 모드는 사실상 다른 앱이라 화면 안에서 호스트 콘솔만 파일이 89개입니다. 숙소 등록은 유형 → 위치 → 객실 → 편의시설 → 정책 순의 다단계 마법사이고 정산은 주차 단위로 수수료를 빼고 입금 예정일까지 보여줍니다. |
Note
위 GIF의 동행 화면에는 동행 탭이 하단에 보이는데 마지막으로 빌드된 코드의 탭 구성은 위 표와 같습니다. 동행을 별도 탭으로 끌어올리는 개편이 진행 중이었고 코드에 반영되기 전에 프로젝트가 멈췄습니다.
🔍 탐색 · 숙소 — 목록 · 검색 · 날짜 · 지도 · 상세 · 리뷰
 숙소 목록 거리순 · 필터 · 찜 |
 검색 최근 검색 |
 검색 결과 |
 날짜 선택 |
 지도 타일 기반 로딩 |
 마커 선택 |
 숙소 상세 |
 리뷰 |
🧾 예약 — 객실 · 날짜 · 인원 · 결제
 객실 선택 |
 날짜 |
 인원 · 성별 |
 예약 확인 이용자 정보 · 결제 금액 |
🧭 동행 · 커뮤니티 — 모집 · 신청 · 글쓰기 · 태그 · 정렬
 오늘 동행 마감 임박 · 남은 시간 |
 약속 동행 날짜 · 모집 형태 필터 |
 동행 신청 |
 커뮤니티 피드 |
 피드 스크롤 |
 글쓰기 임시저장 · 사진 |
 숙소 목록 스크롤 |
 내 동행 신청 수 · 참여 인원 |
 태그 |
 정렬 |
 신고 사유 선택 · 내용 첨부 |
 찜한 숙소 |
💬 메시지 · 일정 — 1:1 · 단체 · 동행 채팅 · 일정 추가
메시지 목록 일반 · 단체 · 동행 |
 대화 검색 |
 일정 |
 일정 추가 날짜 · 시간 · 알림 |
 일정 날짜 |
 호스트 예약 달력 — 월 이동 · 입·퇴실 일정 · 기간 하이라이트 |
||
🔑 계정 · 호스트 — 소셜 4종 · 휴대폰 인증 · 숙소 관리
 시작 게스트 · 호스트 갈림길 |
 로그인 카카오 · 네이버 · 구글 · 애플 |
 내 정보 쿠폰 · 찜 · 방명록 · 설정 |
 정보 약관 · 오픈소스 · 버전 |
 회원가입 인증 · 약관 · 닉네임 |
 숙소 정보 관리 |
호스트 콘솔은 파일만 89개라 일부만 실었습니다. 숙소 등록 마법사와 정산 화면은 위쪽 GIF에서 볼 수 있습니다. | |
 객실 설정 이용 가능 성별 · 수용 인원 |
호스트 콘솔은 파일만 89개라 일부만 실었습니다. 숙소 등록 마법사와 정산 화면은 위쪽 GIF에서 볼 수 있습니다. | ||
각 문제는 증상에서 시작합니다. 코드를 보고 발견한 게 아니라, 누군가 "이거 이상한데요"라고 말해서 알게 됐습니다.
| 증상 | 진짜 원인 | 해결 |
|---|---|---|
| 지도를 한 번 쓸면 요청이 수십 번 나간다 | 화면 경계가 연속적인 실수 값이라 캐시 키가 될 수 없었다 | 고정 격자로 정수 타일 ID 부여 · 디바운스 · 유사 영역 판정 · 30분 캐시 → 자세히 |
| 며칠 만에 앱을 켜면 가끔 로그아웃된다 | 동시에 뜬 요청 여섯 개가 각자 토큰 갱신을 시도해 1회용 리프레시 토큰이 서로를 무효화 | 갱신을 공유되는 Future로 만들어 요청이 한 번만 나가게 → 자세히 |
| 수락한 예약이 다른 화면에선 계속 대기 중 | 전역 변수는 값이 바뀌어도 리빌드를 유발하지 않는다 | 목록이 아니라 "다시 불러와야 한다"는 신호만 공유 → 자세히 |
| 사진 올리다 앱을 나가면 처음부터 다시 | 업로드가 앱 생명주기에 묶여 있었다 | 포그라운드 태스크로 분리 · 큐를 디스크에 저장해 강제 종료 후에도 이어서 → 자세히 |
| 같은 품질로 압축했는데 어떤 사진은 흐리고 어떤 사진은 용량 초과 | 사진마다 복잡도가 달라 고정 품질은 답이 될 수 없었다 | 품질 20~95 구간을 이분 탐색해 목표 용량을 넘지 않는 최고 품질을 사진마다 결정 · 최대 7회 → 자세히 |
| 지하철에서 보낸 메시지가 사라진다 | 연결이 끊겼는데 소켓은 연결됨으로 표시돼 있었다 | 25초 하트비트로 죽은 연결 감지 · 메시지를 로컬 DB에 저장 → 자세히 |
| 걸으면서 쓰면 버튼이 자꾸 빗나간다 | 디자이너가 준 24dp가 그대로 터치 영역이 됐다 | 보이는 크기는 두고 투명 여백으로 48dp까지 확장 → 자세히 |
여섯 개 중 가장 오래 붙잡고 있었던 건 첫 번째, 지도였습니다. 나머지는 원인을 찾으면 고칠 방법이 비교적 분명했는데 지도는 "무엇을 캐시의 단위로 삼을 것인가"부터 정해야 했기 때문입니다.
화면 경계는 연속적인 실수라 그대로는 캐시 키가 되지 못합니다. 그래서 한반도에 고정 격자를 깔고 좌표를 정수 번호로 바꿨습니다. 그러고 나니 "이미 받아온 영역인가"가 집합 연산 한 번으로 풀렸습니다.
만들면서 이게 제대로 도는지 눈으로 봐야 했는데 격자는 눈에 보이지 않는 개념이라 확인할 방법이 없었습니다. 그래서 격자와 타일 번호를 화면에 직접 그려 놓고 개발했습니다.
격자와 타일 번호를 화면에 직접 그려 검증하던 개발용 화면 · 실제 앱에는 나오지 않습니다
지도를 움직이면 화면에 걸치는 타일 번호가 바뀌고 그중 캐시에 없는 것만 서버로 나갑니다. 요청은 넓게 나가고 렌더링은 좁습니다. 하단의 "지도에 표시된 숙소 N개"는 타일 단위로 받아온 데이터 중 실제 화면 다각형 안에 드는 숙소만 센 값입니다.
손가락을 뗀 뒤 요청이 서버까지 가려면 관문 셋을 지나야 합니다.
flowchart TD
T["손가락을 뗀다"] --> V["보이는 숙소 개수 갱신<br/>네트워크 안 탐"]
T --> D1{"① 300ms 안에<br/>다시 움직였나"}
D1 -->|예| X1["요청 취소"]
D1 -->|아니오| D2{"② 직전과<br/>거의 같은 영역인가"}
D2 -->|예| X2["종료"]
D2 -->|아니오| CALC["화면이 덮는 타일 번호 계산"]
CALC --> D3{"③ 캐시에 없는<br/>타일이 있나"}
D3 -->|없음| X3["종료 · 네트워크 안 탐"]
D3 -->|있음| REQ["서버 요청<br/>타일별로 흩어 담고 캐시에 기록"]
REQ --> DRAW["화면 다각형 안에 드는 것만 마커로 그린다"]
style X1 fill:#fee2e2,stroke:#ef4444,color:#7f1d1d
style X2 fill:#fee2e2,stroke:#ef4444,color:#7f1d1d
style X3 fill:#fee2e2,stroke:#ef4444,color:#7f1d1d
style REQ fill:#fef9c3,stroke:#ca8a04,color:#713f12
style DRAW fill:#dcfce7,stroke:#16a34a,color:#14532d
style V fill:#dcfce7,stroke:#16a34a,color:#14532d
붉은 종료 지점 셋이 이 구조의 핵심입니다. 가장 빠른 요청은 나가지 않는 요청입니다.
말로만 하면 믿기 어려우니 지도를 16번 드래그하며 로그를 수집했습니다.
| 드래그 후 로드 시도 | 16회 |
| 그중 서버 호출이 나간 횟수 | 1회 |
| 캐시로 해결된 횟수 | 15회 |
| 화면이 덮은 타일 (누적) | 64개 |
| 그중 캐시 적중 | 61개 |
| 실제 서버에 요청한 타일 | 3개 |
캐시 적중률 95.3% · 로드 시도 대비 서버 호출 6.3%
같은 지역을 오가는 조작이라 적중률이 높게 나온 면이 있습니다. 다만 지도를 쓰는 실제 행동은 대개 한 지역을 들여다보며 왔다 갔다 합니다. 이 패턴에서 잘 듣는다는 것 자체가 설계 의도와 맞습니다. 측정 조건은 문서에 그대로 적어 뒀습니다.
화면 150여 개가 서로를 어떻게 붙들고 있는지의 이야기입니다.
flowchart TD
A["main()<br/>점검 확인 · 업로드 큐 복원 · 푸시 초기화"]
B["MultiProvider<br/>ChangeNotifier 32개"]
C["홈 셸<br/>IndexedStack · 탭 5개 상주<br/>하단 탭바는 권한에 따라 교체"]
A --> B --> C
C --> G["게스트 화면<br/>여행 · 동행 · 일정 · 내 정보"]
C --> H["호스트 화면<br/>달력 · 오늘 · 숙소 · 정산"]
C --> S["공통 화면<br/>커뮤니티 · 메시지"]
G --> L(( ))
H --> L
S --> L
L --> N1["ApiClient<br/>토큰 갱신 락"]
L --> N2["SocketManager<br/>하트비트 · 재연결"]
L --> N3["SQLite<br/>채팅 · 프로필 캐시"]
L --> N4["포그라운드 태스크<br/>업로드 큐 영속화"]
L --> N5["Platform Channel<br/>지도 SDK · 위치"]
style A fill:#f4f4f5,stroke:#a1a1aa,color:#18181b
style B fill:#f4f4f5,stroke:#a1a1aa,color:#18181b
style C fill:#dcfce7,stroke:#16a34a,color:#14532d
style G fill:#eff6ff,stroke:#3b82f6,color:#1e3a8a
style H fill:#fff7ed,stroke:#f97316,color:#7c2d12
style S fill:#faf5ff,stroke:#a855f7,color:#581c87
style L fill:#71717a,stroke:#71717a,color:#71717a
탭 다섯 개가 항상 살아 있습니다. IndexedStack이라 탭을 옮겨도 화면이 버려지지 않습니다. 커뮤니티 피드를 한참 내리다 메시지를 확인하고 돌아오면 화면이 그 자리에 그대로 있습니다. 이 앱에서는 그게 메모리보다 중요했습니다.
권한이 바뀌면 탭이 통째로 교체됩니다. 게스트와 호스트는 사실상 다른 앱이라 화면 안에서 if (isHost)로 나누지 않고 셸 수준에서 갈랐습니다. 조건문으로 시작하면 그게 모든 화면으로 번집니다.
화면은 서로를 직접 부르지 않습니다. 예약을 수락한 화면이 달력 화면을 직접 갱신하지 않고 가운데 상태 계층에 "바뀌었다"고만 알립니다. 화면이 150개가 넘는 앱에서 화면끼리 직접 얽히기 시작하면 어디서 무엇이 바뀌는지 추적이 불가능해집니다. → 상태 관리
시작 순서 자세히 보기
main()
├─ 스플래시 유지 (로그인 확인이 끝날 때까지)
├─ 서버 점검 확인 → 점검 중이면 여기서 멈춤
├─ 저장된 업로드 큐 복원 → 중단된 업로드 이어서
├─ 푸시 · 알림 초기화
└─ MultiProvider (ChangeNotifier 32개)
└─ 로그인 여부 분기
├─ 온보딩 / 로그인
└─ 홈 셸
├─ IndexedStack ······ 탭 5개를 모두 살려 둠
├─ 하단 탭바 ········· 권한에 따라 게스트/호스트 교체
└─ SocketManager ····· 하트비트 · 재연결 · 로컬 DB 동기화
탭을 IndexedStack으로 쌓아 둡니다. 매번 새로 만들면 스크롤 위치와 입력 중이던 내용이 날아갑니다. 커뮤니티 피드를 한참 내리다 메시지를 확인하고 돌아오면 화면이 그 자리에 그대로 있습니다. 이 앱에서는 그게 메모리보다 중요했습니다.
점검 확인을 첫 프레임 전에 합니다. 서버가 내려갔는데 앱이 정상적으로 열리면 사용자는 화면마다 다른 에러를 봅니다. 다만 네트워크 자체가 끊긴 경우는 점검으로 취급하지 않습니다. 지하철에서 앱을 켰다고 "서버 점검 중"이라고 하면 안 되니까요.
| 아키텍처 | 왜 Flutter였나 · 렌더링 3단 구조 · Platform Channel의 진짜 비용 |
| 지도 타일링 | 격자 상수를 역산한 이유 · 세 겹의 방어선 · 넓게 받고 좁게 그리기 |
| 상태 관리 | 전역 변수가 못 하는 한 가지 · 값을 공유할지 신호를 공유할지 |
| API 클라이언트 | 갱신을 함수가 아닌 Future로 · REST와 소켓이 락을 공유하는 법 |
| 실시간 메시지 | 연결됨을 믿지 않기 · 오프라인에서도 열리는 채팅방 |
| 백그라운드 업로드 | 앱이 살아 있다고 전제하지 않기 · 큐를 디스크에 두는 이유 |
| 디자인 시스템 | 시안 390×779를 모든 기기에 · 글자만 환산하지 않은 이유 |
| UX 디테일 | 에러 로그에 안 잡히는 버그들 · 애니메이션의 적정 구간 |
| 포크한 라이브러리 | 확대 상태는 어디서 어디로 흐르는가 · 손가락 떨림에 죽던 더블탭 |
코드 발췌는 src/에 있습니다. 단독으로 빌드되지 않는 조각이며 시크릿과 디버그 로그를 걷어냈습니다.
| 250 | 158,560 | 268 | 32 |
| Dart 파일 | 코드 라인 | 위젯 클래스 | ChangeNotifier |
| 101 | 5 | 271 | 128 |
| REST 엔드포인트 | 로컬 DB 테이블 | 커밋 | 병합된 PR |
Scaffold를 가진 파일이 147개, 호스트 콘솔(Manager · Lodging)만 89개 파일입니다. 가장 큰 덩어리가 호스트 쪽이고 그다음이 프로필 · 여행 · 메시지 · 예약 달력 순입니다.
| 화면 | Flutter · Dart |
| 상태 | Provider (ChangeNotifier) |
| 통신 | http · Dio (멀티파트) · Socket.IO |
| 저장 | SQLite · SharedPreferences · 이미지 캐시 |
| 지도 · 위치 | Kakao Map SDK · Google Maps · Geolocator |
| 인증 | Firebase Auth · 카카오 · 네이버 · 구글 · 애플 |
| 결제 | Toss Payments 결제위젯 v2 (WebView) |
| 문자 인증 | Solapi (휴대폰 번호 인증) |
| 미디어 | 이미지 압축 · 에셋 피커 · 직접 포크한 뷰어/크로퍼 |
| 알림 · 백그라운드 | FCM · 로컬 알림 · 포그라운드 태스크 |
쓰던 라이브러리에 필요한 동작이 없을 때, 옵션을 더 찾는 대신 소스를 열어 고쳤습니다. 두 번 있었습니다.
사진을 아래로 쓸어내려 닫기 · 원본 라이브러리에는 세로 드래그 처리가 한 줄도 없었습니다
Flutter_Photoview_Custom — 사진을 아래로 쓸어내려 닫는 동작을 넣었습니다. 진짜 문제는 제스처가 아니었습니다. 정보가 흐르지 않는 구조였습니다. 확대 배율은 사진 한 장을 그리는 안쪽 위젯이 들고 있고, 페이지를 넘기는 바깥 갤러리는 그걸 모릅니다. 확대 중에 손가락을 내리면 사진을 옮기려는지 닫으려는지 갤러리가 구분할 수 없습니다.
새 배선을 깔지 않고, 이미 지나다니던 신호(scaleStateChangedCallback)를 갤러리가 길목에서 가로채 읽고 원래 받을 사람에게 다시 넘기는 방식으로 풀었습니다. 그 값 하나가 드래그 수용 여부 · 좌우 페이지 스크롤 · 위젯 트리 분기를 한꺼번에 가릅니다. 덕분에 앱 코드는 한 줄도 바뀌지 않았습니다.
같은 포크에서 더블탭 확대도 고쳤습니다. 원본은 손가락이 몇 픽셀만 흔들려도 확대 인식기가 제스처를 먼저 가져가 버려서, 미동 없이 정확히 같은 자리를 눌러야만 먹혔습니다. 누른 자리에서 10픽셀 안쪽 움직임은 무시하도록 여유를 두니 평범하게 두드려도 동작합니다.
flutter_image_cropper_custom — 크롭 화면에서 상단 시계와 배터리가 검은 배경에 묻혀 보이지 않았습니다. 플러그인이 9.0.0에서 가장자리 처리를 앱 쪽으로 옮기면서 Dart에서 상태바 색을 넘기는 항목이 사라졌는데, 네이티브는 여전히 그 값을 읽고 있었습니다. 넘길 방법이 없으니 네이티브에서 기본값을 세 줄 박았습니다.
고친 양보다 고칠 자리를 찾는 데 걸린 시간이 훨씬 길었습니다. 그 과정을 포크한 라이브러리에 적었습니다.
숨기면 회고가 아니라서 적습니다.
공통 컴포넌트를 먼저 뽑을 것입니다. 버튼 · 앱바 · 바텀시트를 화면마다 다시 선언했습니다. 초반엔 빨랐지만 화면이 100개를 넘어가면서 디자인이 한 번 바뀔 때마다 수십 곳을 고쳐야 했습니다. 호스트 이벤트 등록 화면 네 개는 서로 거의 같은 코드가 각각 1,300줄씩 들어 있습니다. 16만 줄이라는 숫자는 규모의 증거가 아니라 이 부채의 크기입니다. 화면 열 개쯤 만든 시점이 가장 싸고 그 이후로는 계속 비싸집니다.
색과 간격은 한곳에 모으겠습니다. 브랜드 초록색을 쓸 때마다 Color(0xFF228B22)를 직접 적었습니다. 상수 하나로 두지 않았으니 색을 조금만 바꾸려 해도 전체 검색으로 찾아 하나씩 고쳐야 합니다. 여백과 글자 크기도 화면마다 그때그때 정했습니다. 큰 사고가 나지는 않았지만, "이 앱의 초록색은 무엇이다"라고 한 곳을 가리킬 수 없는 상태가 됐습니다. → 디자인 시스템
테스트를 쓰겠습니다. 이 프로젝트에는 코드가 제대로 도는지 자동으로 확인해 주는 장치가 없습니다.
무엇이 문제냐면, 한 곳을 고쳤을 때 다른 곳이 망가졌는지 알 방법이 없다는 것입니다. 예를 들어 예약 취소 로직을 손보면 예약 내역 화면만 영향받는 게 아닙니다. 호스트의 예약 달력, 게스트의 일정 탭, 알림, 정산 금액이 전부 같은 데이터를 봅니다. 제대로 확인하려면 그 화면들을 직접 눌러 봐야 합니다.
화면이 150개가 넘으니 매번 그럴 수는 없습니다. 결국 "이 정도면 됐겠지" 하고 넘어가고 문제는 엉뚱한 화면에서 나중에 드러납니다. 테스트가 있으면 이 확인을 명령 한 번으로 끝낼 수 있습니다. 당시에는 화면을 하나라도 더 만드는 쪽을 택했는데 화면이 늘어날수록 손으로 확인해야 할 양도 같이 늘어난다는 걸 나중에 체감했습니다.
이 프로젝트를 하며 부딪힌 문제를 정리해 둔 글입니다.
| 상태 관리가 필요했던 순간: 변수에서 Provider로 | 화면 간 상태가 어긋나는 문제와 해결 |
| 지도를 '그리지 않음'으로써 가장 빠른 지도를 그리는 법 | 격자 설계 · 캐시 · 요청 억제 |
| 모바일 앱 UI/UX 설계 가이드 | 인지 부하 · 체감 성능 · 터치 영역 |
| Flutter 아키텍처 딥다이브 | 렌더링 구조 · Platform Channel · 백그라운드 |
위 글들은 팀 기술 블로그 yeohaenghage.kr에 있습니다. 프론트엔드 외에 백엔드 · 인프라 · 디자인 · 브랜딩 글도 함께 올려 두었습니다. 서버 쪽 회고는 align-retrospective에 따로 있습니다.
| 이진수 @kiwijuse | 프론트엔드 — 앱 전 화면 구현 · 클라이언트 아키텍처 · API 연동 |
| 남궁찬 | 기획 · 디자인 · 마케팅 (팀 대표) |
| @pill27211 | 백엔드 · 인프라 |
| @Namhunk | QA |
사업자 등록과 법적 절차를 마치고 앱 출시 단계까지 갔지만 실서비스 직전에 마무리되지 못했습니다. 그래도 19개월 동안 화면 150여 개를 실제로 굴러가게 만들어 본 경험이 남았습니다.