03Tomo

친구와 모임 자체를 기록하고 관리하는 Android 서비스입니다. Backend 개발자 1명과 2인으로 진행하며 Android 클라이언트 전체를 단독으로 맡았고, 기획부터 Google Play 정식 출시까지 직접 진행한 첫 개인 모바일 서비스입니다.

AI 도구 없이 Kotlin과 Jetpack Compose로 화면·상태·데이터 흐름을 직접 설계했고, Backend API 협업과 Firebase 연동, 지도 SDK 선택, 스토어 출시까지 클라이언트 개발의 전 구간을 경험했습니다.

친구들과 모임을 자주 가지면서, 기존 메신저와 SNS로는 관계 자체를 관리하기 어렵다고 느꼈습니다. 메시지와 콘텐츠 전달이 중심이라 지금 어떤 모임에 속해 있는지, 예정된 약속이 무엇인지, 누구와 자주 만나는지가 한 곳에 남지 않았습니다.

그래서 메시지가 아니라 친구와 모임을 중심에 두고, 다음 흐름이 하나의 서비스 안에서 이어지도록 기획했습니다.

1. 친구 추가
2. →모임 생성
3. →친구 초대
4. →약속 생성
5. →달력 확인
6. →친밀도 확인

모임 생성은 한 화면에서 모든 값을 입력받는 대신, 사용자가 실제로 모임을 만드는 순서를 따라 3단계로 나눴습니다.

1. 기본 정보
2. →친구 초대
3. →확인

모임 멤버는 단순한 참여자 목록이 아닙니다. 모임장이 각자 아는 친구들을 초대하면 멤버끼리는 서로 친구가 아닐 수 있어서, 멤버 하나를 그리는 데에도 여러 상태를 함께 판단해야 했습니다.

• 본인인지 · 모임장인지 · 일반 멤버인지
• 현재 친구인지, 친구가 아니라면 친구 추가를 노출할지
• 친밀도 점수를 보여줄 수 있는 관계인지

1. 어색한 친구
2. →아는 사이
3. →친구
4. →좋은 친구
5. →절친
6. →최고의 친구

약속은 모임에 속한 일정입니다. 아무나 일정을 만들면 모임 자체가 흔들리기 때문에 모임장만 약속을 생성할 수 있도록 권한을 나눴고, 생성된 약속은 모임 멤버들의 달력에서도 함께 보이도록 데이터 흐름을 연결했습니다.

1. 모임장
2. →약속 생성
3. →모임 연결
4. →멤버 Calendar

개발 중 Backend 개발자의 일정 문제로 필요한 API 개발이 한동안 어려워졌습니다. 개발을 멈추고 기다리는 대신, 지금 있는 인프라로 클라이언트에서 먼저 완성할 수 있는 범위를 찾았습니다.

인증 구조상 Firebase가 이미 붙어 있었고 데이터도 Backend DB와 Firestore를 함께 쓰고 있었습니다. 그래서 API를 기다려야 하는 기능 대신, Firestore로 먼저 만들 수 있는 기능을 골라 개발을 이어갔습니다.

• Friend Push

  FCM Token을 발급해 Firestore와 연결하고, 친구 추가 시 상대방에게 Push Notification이 가도록 구현

• Appointment DTO

  API가 없는 상태에서 약속 데이터를 표현할 DTO를 직접 설계하고 Firestore 기반으로 약속 생성을 완성

지금 다시 보면 Backend DB와 Firestore를 함께 쓰는 구조에는 개선할 부분이 많습니다. 다만 이 경험에서 남은 것은 Backend가 준비되지 않아 멈춘 게 아니라, 쓸 수 있는 기술과 인프라를 파악해 클라이언트에서 해결 가능한 범위를 찾아 기능을 끝냈다는 점입니다.

약속 장소를 등록하기 위해 지도와 장소 검색이 필요했습니다. 처음부터 Kakao Maps를 고른 것이 아니라 세 가지를 실제로 붙여보고 비교했습니다.

• Google Maps

  Android 연동은 가장 쉬웠지만 국내 장소 검색에는 적합하지 않다고 판단

• Naver Maps

  지도 연동까지 직접 성공했으나 장소 검색과 당시 운영 조건 · 비용을 고려해 제외

• Kakao Maps

  국내 장소 검색을 제공하고 프로젝트에서 쓸 수 있는 범위가 충분해 최종 선택

SDK 선택 기준이 연동 난이도만은 아니라는 것을 배운 경험입니다. 필요한 기능과 API 제공 범위, 국내 사용자 환경, 비용과 운영 조건까지 함께 비교해야 했습니다.

Backend 개발자 1명과 Discord로 소통하고 Swagger로 API 명세를 공유했습니다. 클라이언트와 서버가 서로 다른 DTO 구조를 쓰면 불필요한 변환과 오해가 생기기 때문에, DTO 구조를 맞추는 협의를 여러 차례 거쳤습니다.

개인 프로젝트로는 처음 해보는 Client-Server 협업이었고, API가 완성되면 호출하는 것이 아니라 어떤 데이터를 어떤 형태로 주고받을지 먼저 함께 정의해야 한다는 것을 배웠습니다.

정식 출시

Google Play정식 출시

클라이언트 단독 개발

Android 전체클라이언트 단독 개발

Downloads

약 45Downloads

Android · Backend 협업

2인Android · Backend 협업

• 단순해 보이던 친구 · 모임 기능도 실제 제품에서는 상태와 권한, 데이터 관계가 훨씬 복잡했습니다.
• 모바일 개발이 화면을 그리는 일이 아니라 사용자의 행동과 데이터 흐름을 설계하는 일이라는 것을 체감했습니다.
• Backend가 지연됐을 때 기다리는 대신 Firebase · Firestore로 구현 가능한 범위를 찾아 개발을 이어갔습니다.
• 클라이언트와 서버가 협업할 때 API 명세와 DTO 구조에 대한 합의가 먼저라는 것을 배웠습니다.
• SDK 선택에는 개발 편의성뿐 아니라 서비스 요구사항과 비용, 운영 조건까지 함께 봐야 했습니다.
• 이후에는 새 기능을 만들 때 화면보다 먼저 사용자의 상태가 어떻게 바뀌고 데이터가 어디까지 전달되는지를 생각하게 됐습니다.