[개발] 모여바라 (Moyobara) 개발

2026년 목표 중 하나였던, 앱 출시가 빠르게 끝나서 되돌아볼겸 글을 오랜만에 쓰게 되었다.

2025년은 20살을 넘긴 이후로 정말 시간이 빨리 지나간 해였다. 안 좋은 의미로.

왜 사이드 프로젝트를 진행했는지, 어떤 기술 스택을 썻는지, 결과는 어떤지 등등 정리할 목적으로 써보려한다.

 

외근 시작 (2025년 8월 ~ 12월)

회사 업무로 외근을 나가게 되었다.

 

빨리 끝내고 복귀해야지 생각하긴 했었는데, 생각보다 쉬운 일이 아니었다.

원래 양이 많았던게 문제가 아니라. 해도 해도 원점으로 돌아오는 말도 안 되는 업무였다.

 

처음에는 정말 힘들었다. 다 끝냈다고 생각하고 다음 날 보면 다시 원점으로 돌아와 있었다.

보안 때문에 정확히 무슨 일인지 여기에 기록하진 못하지만, 같은 짓을 매일 매일 매일 매일 반복하고 있었고

 

다들 25년 11월에는 모든 작업이 마무리되고 복귀할 것이라는 희망을 가지고 있었지만, 어림도 없었다.

이때 다이어트를 했어야 했나 싶은데, 오히려 스트레스 때문에 다들 엄청 먹고 증량만 했댄다..

 

결국 외근은 12월까지 진행이 확정이 되었고. 제발 마무리라도 잘 되길 바라는 마음으로 다들 열심히 시간을 보냈다.

 

그러면서 정신적으로 많이 무너졌던것 같다.

 

이 업무가 나한테, 개발적으로 도움이 되면 모를까. 진짜 단순히 노가다 뛰는 것 같은 느낌이었다.

몸으로 떼우고, 같이 나간 직원들과 말싸움하고 신경질적이고.

심지어 내가 이러려고 iOS 개발을 배워놨나, 괜히 뭐 하나 할 줄 안다고 잡힌건가 싶기도 했다.

시간이 지나고 프로젝트도 기대 이상으로 잘 끝나서 이제서야 웃을 수 있는데, 회사 다니면서 제일 힘들었던 일 같다.

 

가끔 하루 이틀씩 사무실로 정리를 위해서 복귀를 했을 때, 오랜만에 잡아보는 Xcode와 Swift 코드는 진짜 손에 안 익더라

 

집에 오면 공부를 따로 하지 그래? 싶은데.

하루종일 몸으로 일하다가 집에 돌아오면 의자에 앉기는 커녕,

스트레스를 해소한답시도 엄청 먹고 눕고 반복이었다.

 

12월 중순이 되었을 때, 누군가 물어본 코드를 설명하려고 보니, 진짜 설명을 못 하겠더라.

외근을 나가기 전까지는 주마다 스터디를 하고 머리가 정말 잘 굴러갔었는데,

한 5개월을 안 하니까 진짜 다 잊고 있었던 것이다.

 

이때 충격을 많이 받았다. 그래서 언젠가 필요한 포트폴리오용 앱도 만들고, 공부도 다시하고, 개인 앱으로 앱스토어 배포도 할겸

사이드 프로젝트를 시작했다.

 

개발 시작 (2025년 12월 ~ 2026년 2월)

12월 3일이 시작이었구나

 

나는 INTP다. INTP는 논리적인 토론을 하는걸 좋아한다(?) 라고 한 선임님이 그러더라.

만약 이런 토론하는 앱이 있다면 (또는 치고박는 앱이 있다면) 사람들한테 인기가 많을 수도 있다고 생각했다.

이런 앱을 만든다면 사용하게 될 기술 스택도 나쁘지 않았다.

 

채팅, 게시판 앱이라면 가장 기본적인 것이라 생각했고, 로그인, 개인정보처리, API, DB 모든 것을 적용하기 완벽했다.

이 생각이 들었던 시간에 바로 생성부터 했다.

 

처음에 정한 이름은 카피챗.

인기 많은 동물인 카피바라와 커피챗을 합쳐서, 자유로운 주제로 자유로운 대화를 할 수 있는 앱을 만들고 싶었다.

 

중간으로 넘어가면서 좀 딱딱하다는 의견도 있고, 별로 재미없는 이름 같아서

카피바라의 정체성을 유지하면서 말장난을 치는듯한 모여바라로 바꾸게 되었다.

 

프로젝트 구조

먼저 프로젝트 구조를 정했다.

배울 때도 그랬고, 알고 나서도 느끼는 거지만, 처음에 기능 구조던지, 코드 구조던지, 파일 구조던지 제대로 안 해놓으면 피를 꼭 본다는 생각을 먼저 했다.

공부를 하는거니까 새로운걸 해볼까? 싶었는데, 그냥 원래 하던거나 잘하자고 생각했다.

괜히 어렵고 새로운거 도전하다가 포기할 가능성도 있었고, 지금 당장 급한건 앱을 하나 완성해서 내는거지, 모험을 할 필요는 없다고 느꼈다.

 

1. 논리적 구조 - Clean Architecture

사실 할 줄 아는게 이거밖에 없기도 하고, 가장 일반적이라고 생각했다.

회사에서 항상 하던거라 적용하기도 쉬웠고, 참고할 자료도 많았기 때문에, 바로 선택했다.

UseCase, Repository, DataSource를 만드는건 그리 어렵지 않았다.

 

2. 상태 관리 - MVVM + MVI (TCA)

사실 내가 알고 있었던건 MVVM 밖에 없었는데, 개발하면서 변형되고 적용된걸 나중에 공부해보니

내가 하고 있었던건 MVVM + MVI + TCA 특성이 적절히 조합된 극강의 효율 세팅이었더라

 

3. 프로젝트 파일 구조 - Micro Architecture

사실 이 표현이 맞는지는 모르겠는데, Xcode에서 Feature, Domain, Data + Shared, DesignSystem 등의 모듈을 만들어서 활용했다.

 

 

백엔드

Firebase

서버 개발자 없이 혼자 진행하는 프로젝트이니, 쉽게 구성하면서 내가 원하는 기능을 모두 구현할 수 있는데 딱 좋았다.

채팅 앱이기 때문에 회원관리가 필수인데, 이를 위해 소셜 로그인도 쉽게 구현할 수 있다. 

 

Firebase에서도 주로 사용한 기능은 

 

1. Authentication

애플 로그인을 구현하기 위해서 사용했다.

 

2. Firebase Database

당연하게도 DB를 위해 사용했다.

실시간 Listener를 제공하기 때문에, 채팅 기능을 소켓 없이 구현하는데 도움을 주었다.

 

3. Storage

원래 쓸 일이 없었는데, 개발 막판에 사용을 시작했다.

사용 목적은 언어 필터링.

언어 필터링을 위해 필요한 텍스트 데이터를 파일로 관리를 하고, 이를 저장하기 위해 사용했다.

 

디자인

이 부분이 사실 제일 막막했다. AI의 도움을 받으면 된다고는 하는데, 생각보다 잘 만들어주지 못했다. 그런데..

 

 

 

본인의 GPT가 뛰어나다고 맡겨만 달라던 동료가 있었는데, 덕분에 문제가 없어졌다.

이 외의 UI는 다른 앱들도 참고하고, 머리속으로 해보고 싶었던 UI/UX를 즉석으로 적용하면서 만들었다.

 

주요 기능

귀여운 주제와 채팅들

 

 

1. 로그인

Firebase Authentication로 Apple 로그인만 구현했다.

문서에 설명되어 있는대로 따라하기만 하면 큰 어려움없이 30분 내로 구현할 수 있었다.

 

2. 내 주제 리스트

내 주제 리스트에는 4가지 채팅 리스트를 보여준다.

(1). 전체 리스트

(2). 내가 '좋아요'한 리스트

(3). 내가 '참여'한 리스트 (채팅을 친)

(4). 내가 '생성'한 리스트

 

위 데이터는 모두, 회원가입/로그인에서 생성되는 데이터베이스에 함께 보관된다.

유저별로 가지고 있기 때문에, 주제 ID 자체는 바로 가져올 수 있는데, 상세 정보를 위해서 1 + n개의 읽기를 해야 했다.

 

3. 주제 관리

여기에는 주제 검색, 주제 생성, 주제 삭제, 주제 신고, 주제 숨기기 등

주제라는 틀에서 할 수 있는 모든 동작들이 있다. 

 

4. 유저 관리

주제 관리와 비슷하게, 유저 차단, 유저 글 숨기기, 유저 신고 등이 있다.

 

5. 주제 추천

생성된 주제들을 검토해서, 최근에 생성된 주제, 좋아요 많은 주제 등. 추천 시스템을 넣었다.

 

6. 채팅

당연히 채팅이 들어간다, 각 주제별로 채팅을 쓸 수 있고, 주제에 들어간 시점에 리스너에 연결되어 모든 채팅이 실시간 반영된다.

 

7. 기타 설정

(1). 로그아웃, 회원탈퇴는 로그인 기능이 있으면 필수다.

(2). Firebase Database에 version 정보 값도 저장해서 버전 검사 기능도 넣었다.

(3). 개인정보처리방침, 서비스 이용약관, 운영정책도 추가했다. 이것들은 slashpage라는 서비스를 활용해 WebView로 보여준다.

(4). 버전정보, 오픈소스 라이브러리 같은 정보도 추가했다.

 

대략적인 주요 기능들은 위와 같은데, 개발 기간은 약 3개월이 걸렸다.

아무래도 업무 시간에는 하지 않고, 퇴근하고 시간 남을 때 하게 되어 예상보다 시간이 더 걸린것 같다.

주말이나 공휴일에는 거의 시간을 갈아 넣었다. (설날 연휴에도 계속 했다.)

 

심사

심사하는데 작성해야 할 문구들은 AI의 도움을 많이 받았다.

필요한 이미지는 Figma의 공개된 템플릿을 활용했다. 

 

준비하는건 빠르고 쉽게 했는데, 리젝을 한 번 받았다.

 

Guideline 1.2 - Safety - User-Generated Content

 

사유는 Guideline 1.2 - Safety - User-Generated Content

사용자 생성 콘텐츠 (주제와 채팅)이 있는데, 그를 위한 예방 조치가 완료되지 않았다는 것이다.

 

저날 아침에 리젝을 알게 되었고, 회사에서 점심 시간이랑 퇴근후에 진짜 개발만 계속 해서 부족한 점을 채워서 다시 심사를 요청했고,

결국 심사를 통과했다.

 

아니 근데, 심사를 4일이나 안 해줘서 결국 문의 메일 따로 넣고 나니까 그날 밤에 3분만에 통과시켜주더라..

 

 

slashpage 서비스를 이용해 만든 웹사이트와 AppStore 링크

https://slashpage.com/moyobara 

Main - 모여바라 (Moyobara)

https://apps.apple.com/kr/app/id6757860890

모여바라 앱 - App Store

 

 

마무리

생각보다 크게 어려울것 없었다. 오히려 시간이 부족한게 제일 큰 문제였다.

걱정하던 것과 달리 개발은 잘 마무리 했고, 맥북을 만지니 코드 치던 습관이 잘 나왔다.

 

심지어 요새는 Gemini, Cursor 같은 AI도 잘 되어 있다보니 개발 자체에서 어려움은 없었다.

마음 먹는게 제일 어렵고 중요한 부분이었던 것 같다.

 

사실 이 앱의 첫 번째 심사를 올리자마자, 새로운 앱 개발을 바로 시작했다.

개발이 점점 마무리 되면서 자신감이 붙었고, 아이디어가 막 떠올랐다.

 

이 글을 쓰는 시점에는 이미 심사 요청까지 끝내놓은 상황이다.

심사가 잘 끝나면 모여바라의 버그 수정과 기능을 조금 더 붙여볼 생각이다.