[회고] CMC 19기 회고
📱 또 동아리를 한다고?
이번에 CMC라는 동아리에 참여했다.
2026년 5월부터 8월까지 약 3개월 동안 활동하며 모디(MODY)라는 앱을 출시했다.
모디(MODY)는 친구들과 식사와 운동을 기록하고 공유하며 다이어트 습관을 만들어 가는 서비스다.
나는 2024년에 Prography라는 동아리에서 활동했다.
이후에는 회사 동료들과 오목완을 만들고,
친구와 Flutter 기반의 달릴까말까를 개발하며 사이드 프로젝트를 이어갔다.
함께하는 사람과 환경이 달라질 때마다 배우는 점도 달랐다.
그러다 다시 동아리라는 환경에서 프로젝트를 하며 배우고자 하는 부분이 있어 CMC 19기에 지원했다.
새롭게 도전해보고 싶은 기술이 있었고, 다양한 직군의 사람들과 하나의 프로덕트를 완성하며 또 다른 경험을 쌓고 싶었다.
CMC에서는 기획자, 디자이너, 개발자가 팀을 이뤄 하나의 프로덕트를 만든다.
내 경험상 너무 동아리 활동 기간이 길면 루즈해지는 경향이 있었고, CMC는 짧은 기간 안에 아이디어를 구체화하고 실제 앱으로 출시하는 과정을 경험할 수 있다는 점이 좋았다.
우리 팀은 PM, 디자이너, Android·iOS 개발자, 서버 개발자까지 총 5명이었다.
iOS 개발자는 나 혼자였고, 앱을 구현하면서 기획과 디자인을 논의하고 서버 개발자와 API를 맞춰 갔다. 기능 개발뿐 아니라 프로덕트를 만들어 가는 전반적인 과정에 함께 참여했다.
🎯 이번 프로젝트에서 해보고 싶었던 것
이번 동아리에서는 특정 상황을 가정하고, 협업에 초점을 둔 개발을 해보는 것을 목표로 삼았다. 구체적으로는 다음과 같은 상황이었다.
- 대규모 프로젝트를 개발하는 상황
- 여러 직군이 협업하며 개발 중인 결과물을 자주 공유해야 하는 상황
- UIKit 기반 앱에 SwiftUI를 점진적으로 도입하는 상황
사실 그냥 특정한 회사의 환경이라고 생각하고 개발했던 것 같다.
이를 위해 기능을 작은 단위로 나누고, 다른 모듈에서 재사용하기 쉬운 구조를 만들고자 했다.
개발 중인 기능은 Demo 앱으로 배포해 결과물을 공유하고, UIKit과 SwiftUI가 함께 존재하는 앱의 구조도 직접 구성해 보고 싶었다.
현재 프로젝트 규모에 필요한 수준보다 큰 구조를 의도적으로 시도한 셈이다.
동아리 프로젝트 안에서 이런 상황을 직접 다뤄보는 것이 이번 개발의 목표였다.
이런 요구사항을 바탕으로 Toss의 글에서 소개한 MicroFeature Architecture를 적용하기로 했다.
🧩 왜 MicroFeature Architecture를 선택했을까?
여러 앱을 개발하면서, 프로토콜로 인터페이스를 정의하고 실제 구현을 분리하는 방식의 장점을 느꼈다.
구체적인 구현에 대한 의존을 줄이면 다른 부분에 미치는 영향을 줄이면서 코드를 수정하거나 기능을 확장하기가 수월했다.
협업할 때도 서로 연결할 인터페이스를 기준으로 각자의 구현을 진행할 수 있다는 점이 좋았다.
그래서 이번 프로젝트에서도 기능 사이의 경계를 나누고, 서로의 내부 구현에 직접 의존하지 않도록 만드는 것에 특히 신경을 썼다.
MODY를 시작하기 전 Toss의 MicroFeature Architecture 관련 글을 여러 번 읽은 것도 이런 관심에서 출발했다.
당시 궁금한 것은 크게 두 가지였다.
- 기능마다 사용하는 기술이 달라도 서로의 내부 구현을 깊게 알지 않고 연결할 수 있을까?
- 개발 중인 기능만 따로 실행해 팀원에게 보여줄 수 있을까?
기능의 구현과 외부에 공개하는 인터페이스를 분리하고, 기능별 Demo 앱을 구성하는 방식은 이 고민에 잘 맞았다.
특히 하나의 기능을 구현하는 Feature, 외부에 공개할 Interface, 테스트를 위한 Testing·Tests, 독립 실행을 위한 Demo 타깃으로 나누는 방식이 인상적이었다.
기능을 독립적으로 개발하고 테스트하고 실행한다는 것이 실제 프로젝트에서는 어떤 모습일지 궁금했다.
단순히 글을 읽는데서 끝내지 않고, 내 프로젝트에 적용했을 때 의존성 관리와 협업 방식이 어떻게 달라지는지 경험해 보는 것이 선택의 중요한 이유였다.
물론 바로 MODY에 적용한 것은 아니다. 모디는 철저히 계획된 설계 속에서 개발됐다.
먼저 micro-feature-study라는 별도 프로젝트에서 구조를 검증했다.
Tuist로 모듈과 의존성을 구성하고, 기능별 Demo 앱을 GitHub Actions와 Fastlane으로 배포하는 흐름까지 먼저 시도했다.
🔀 검증한 구조를 실제 서비스에 적용하며
사전 검증 프로젝트에서 구성해 본 구조를 바탕으로 MODY의 기능을 개발했다.
기능을 추가할 때도 다른 기능의 내부 구현을 직접 참조하기보다, 필요한 연결을 인터페이스로 드러내려고 노력했다.
UIKit + ReactorKit과 SwiftUI + TCA를 함께 사용한 것도 같은 맥락이다.
이미 UIKit과 ReactorKit으로 개발된 프로젝트에 SwiftUI와 TCA를 도입하는 상황을 가정했다.
실제 레거시 앱을 넘겨받은 경험은 아니지만, 서로 다른 방식으로 만든 기능을 하나의 앱으로 연결해 볼 수 있었다.
구조만 검증하던 프로젝트에서 나아가, 실제 서비스의 기능을 그 안에 채워 넣는 과정이었다.
모디 앱을 개발하면서 어떤 어려움이 있었고, 어떻게 해결했는지에 대해서는 별도 글에서 정리하려 한다.
🚚 작은 앱을 팀원에게 전달하기
iOS 개발은 혼자 했지만, 프로덕트를 만드는 일은 기획자, 디자이너, 서버 개발자와 함께했다.
항상 회사에서 일을 할 때, 구현하고 있는 과정이 빨리 공유가 되면 좋겠다라는 생각을 했었고,
때문에 내가 구현한 결과물을 다른 직군의 팀원이 직접 확인할 수 있게 빠르게 전달하는 과정도 이번에 시도하고 싶었던 부분이다.
그래서 기능별 Demo 앱을 작게 배포해 봤다.
GitHub Actions와 Fastlane을 이용해 배포를 자동화하고, 전체 앱이 완성되기 전에도 일부 기능을 설치해 확인할 수 있도록 했다.
왜 Github Actions와 Fastlane이었는지는 다른 포스트에서 다루도록 하겠다.
아키텍처를 선택할 때 생각했던 독립적인 실행이 협업 방식으로 이어지는 지점이었다.
규모가 큰 팀에서 기획과 디자인에 결과물을 자주 전달해야 한다는 상황을, 이번 프로젝트에서 직접 시도해 봤다.
이전부터 필요성을 느꼈지만 현실적인 어려움 때문에 시도하지 못했던 방식이다.
이번 동아리에서 처음 실험해 봤고, 팀원들에게 좋은 피드백을 받았다.
특히 기획자와 디자이너가 개발 중인 결과물을 직접 확인할 수 있어 협업이 수월했다는 의견을 주었다.
🏆 프로젝트를 마치며
MODY는 CMC에서 대상·1위를 받았다. 팀이 함께 만든 서비스로 얻은 결과다.
돌아보면 사전 검증 프로젝트에서 구조를 먼저 다뤄보고, MODY에서 실제 기능 개발과 협업에 적용해 본 기간이었다.
모바일 개발을 맡으면서 기획과 디자인, 서버와의 협업까지 프로덕트를 만드는 과정을 함께 경험했다.
처음 생각한 구조를 실제 기능에 적용했고, 설계한 방향대로 개발을 마쳤다.
실제 개발 기간은 6주 남짓으로 회사를 다니면서 진행하기에는 매우 타이트했다.
그럼에도 초기 설계를 해 둔 덕분에 기능을 추가하거나 수정할 때 빠르게 대응할 수 있었다.
이번 글에서는 프로젝트 전체의 방향을 정리했다. 구체적으로 막혔던 부분과 해결 과정은 다음 글에서 이어가려 한다.
Leave a comment