[iOS] 일기장 어플리케이션 메뉴얼(Menual) 출시 회고

 

올해 초부터 본격적으로 시작한 사이드프로젝트 'Menual(메뉴얼)'이

앱스토어에 12월 24일 크리스마스 이브에 출시되었습니다.🎉

아무래도 사이드프로젝트를 약 1년동안 진행하게 되면서 약간은 루즈해졌음에도 불구하고,

팀원들이 꾸준히 달려와 준 덕에 기획부터 출시까지 잘 해낼 수 있었던 것 같습니다.

 

1년동안 메뉴얼을 개발하면서 어떻게 진행하게 되었는지, 어떤 방식으로 의사결정이 되었는지,

그리고 기술 스택은 어떤지 회고하는 시간을 가져보고자 합니다.

‎Menual : 나를 새롭게 하는 일기장, 메뉴얼

 

---

1. 왜 일기장 앱인가요?

사이드 프로젝트를 진행하기 시작한 것은 사실 21년 10월부터였어요.

대학 생활때 가장 힘들었던 것이 '세상에 없는 새로운 기획😇'을 찾아내는 거였거든요?

교수님은 대학생의 통통 튀는(?) 아이디어을 원하셨고,

저희는 정말 '세상에 없던 기획'을 위해서 온갖 아이템을 다 가져오곤 했어요.

 

그런데 사실 이런 '세상에 없던 기획'을 발굴하고,

이 아이템을 가지고 실제로 서비스화하고 출시하기 위해서는 현실적으로는 힘들 것 같다는 생각이 들었습니다.

'사이드' 프로젝트인 만큼 최대한 가볍게 가져가고자 했어요.

 

너무 기획을 헤비하게 가져가게 되면, 끝까지 프로젝트를 진행하기 어려워지고

기술 스택이나 생각할 것들이 복잡해지면서 결국 수많은 타협점을 찾다가 원하는 결과물이 나오지 않을 때가 많더라구요.

 

1-1. 기획은 가볍게!

적어도 출시되면 우리라도 꾸준히 쓰는 앱을 만들어 보자!

 

그래서 저희는 아주 흔한 아이템이라 하더라도 우리라도 쓰는 앱을 만들어 보자는 목표를 가지고 시작했습니다.

그 중 하나가 '일기장' 이었는데요. 사실 메모&일기는 너무나 흔한 아이템이긴 했어요.

하지만, 기획부터 출시까지 해내기 위해서는 다소 가볍지만 심플한 기획을 가져갈 수 있는 아이템이길 원했고,

흔하지만 우리 팀만의 방식으로 풀어내는 것도 좋은 경험이라고 생각되어 시작하게 되었습니다.

 

1-2. 개발은 단순하게!

또, 개발에 너무 많은 시간이 투자되지 않도록 기술적 제약도 함께 몇가지 가지고 시작했는데요.

가장 핵심적인 제약조건은 '네트워크를 사용하지 않을 것' 이었습니다.

 

이 제약 조건을 설정한 이유는, 이전에 대학 졸업작품으로 제작했던 '디모다모'를 개발하면서 느꼈던 점인데,

네트워크를 사용하는 앱과 사용하지 않는 앱의 개발 속도는 정말 많이 차이났었어요.

 

서버개발자가 따로 있지 않아서, 파이어베이스의 DB 구조를 혼자 짜야했고, 이는 굉장한 병목현상을 만들어냈습니다.

위와같은 이유로 최대한 네트워크 연결은 배제하고,

로컬로 작동하는 어플리케이션을 목표로 '일기장' 어플리케이션 기획을 시작했습니다.

 

물론, 후에 일기장 앱의 필수 기능 중 하나인 '일기장 백업/불러오기' 등의 기능 개발을 위해서는

일부 서버를 사용하기는 했지만, 기본적으로 로컬 기반 어플리케이션으로 제작하고자 했습니다.

 

---

2. iOS 기술 스택

이전 프로젝트는 따로 기술 스택을 정하지 않고 "iOS로만 개발할거야!" 하고 머리부터 들이밀었던 기억이납니다.😇

그 이유는 다양하겠지만, 그때는 iOS에 대해서 알고 있는 지식이 너무 부족하기도 했고,

아키텍쳐라든지, 어떤 라이브러리를 사용한다든지, 어떤 프레임워크를 사용한다든지.. 아무런 고려가 되지 않았어요.

특히 개발하면서 중간 중간 갈피를 못잡게 되면서

그때마다 따로 공부해서 진행해야 한다는게 일정 지키기에 꽤나 큰 걸림돌이었어요.

 

특히 첫 개발이다 보니까, 모든 기능을 외부 라이브러리 없이 iOS Native에 의존했어요.

이게 나쁘다는 것은 아니지만, UIKit으로 모든 기능을 개발하고 있었는데,

중간에 RxSwift를 공부할 기회가 생겼는데 너무나 매력적인 거예요.

 

결국 UIKit으로 개발했던 부분을 조금 더 효율적으로 만들고 싶어서
RxSwift/RxCocoa로 변경했던 경험이 있었습니다.

내부적인 완성도는 챙길 수 있었지만, 마감 기한도 같이 늦어졌던 경험이 있습니다.

 

그래서 이번에는 기술 스택을 좀 더 명확하게 정리하고, 기획/디자인이 진행되는 시간동안 따로 공부를 진행해서

실제로 개발하는 시간에는 기능 개발에만 집중할 수 있는 시간을 만들어보고자 했습니다.

 

2.1 RIBs

GitHub - uber/RIBs: Uber's cross-platform mobile architecture framework.

이번에는 조금 새로운 도전을 해보고 싶었어요.

"뷰와 완전히 분리된 뷰모델을 어떻게 설계할 수 있을까?"에 대해서 굉장히 궁금했었던 시기였거든요.

ReactorKit도 함께 고려하긴 했지만, 제 기준에는 RIBs가 당시에는 조금 더 매력적으로 보였던 것 같아요.

다음 프로젝트에는 ReactorKit으로 도전해보고 싶긴 합니다!

 

Presenter와 Interactor가 완벽하게 분리되어 있는 것이 너무 좋았고,

각 RIB 간 Dependency를 설정해서 의존성을 역전 시키는 것도 너무나 흥미로웠어요.

 

처음에 부모/자식 RIB에게 값을 넘겨주는 것에 대해 꽤나 많은 시간 헤매기도 했고,

Interactor와 ViewController를 어떻게 하면 손쉽게 바인드할 수 있을까를 많이 고민했던 것 같아요.

조금씩 익숙해질 때 앱이 어느정도 완성되었는데, 추후 추가 기능 업데이트에는 기존보다는 빠르게 접근할 수 있지 않을까 싶습니다.

 

"이때 RIBs를 도입할거야!"

라고 하지 않았다면 아직도 새로운 프레임워크/아키텍쳐에 관심이 없을지도 모르겠어요.

이런 의미에서 사이드프로젝트는 참 사랑스럽습니다 ㅎㅎㅎ

 

2.2 RxSwift

GitHub - ReactiveX/RxSwift: Reactive Programming in Swift

Combine을 사용해보고 싶은 마음은 굴뚝같지만, RIBs를 처음 사용하는 입장에서 Combine보다는

Rx 예제나 정보들이 많은게 크게 작용했어요.

 

나중에 SwiftUI와 Combine 조합으로 아주 작은 앱 하나를 만들어보고 싶습니다.

Rx는 꾸준히 사용하고 있지만, 메모리 관리하기 시작하면 굉장히 어려운 친구로 변하는 것 같습니다.

편리하게 사용하고 있지만, 어떻게 하면 메모리 누수 없이 효율적으로 사용할 수 있을지 고민은

앞으로도 꾸준히 해야할 것 같습니다!

 

2.3 RealmSwift

GitHub - realm/realm-swift: Realm is a mobile database: a replacement for Core Data & SQLite

일기장 어플리케이션이기 때문에, 로컬 DB를 굉장히 많이 고민했어요.

CoreData를 사용할 지, UserDefaults를 사용해서 쉽게 갈지, Realm을 사용할 지...

 

iOS앱이기때문에 CoreData를 사용하면 추후 애플 생태계 내에서 멀티플랫폼 지원에 큰 이점이 있는 것은 알았지만,

당장은 빠른 속도로 완성해내는 것이 중요했어요.

 

이미 어느정도는 활용하고 있고, 직장에서도 사용하고 있는 RealmSwift를 선택했고,

그 이후에도 Realm으로 겪은 이슈는 굉장히 많았습니다.. (어려워요)

하지만, 동기적으로 데이터를 뽑아오고 그 데이터를 바로 조리해서 뷰로 뽑아줄 수 있는 건 역시 정말 최고였습니다.

 

2.4 SnapKit/Then

GitHub - devxoul/Then: ✨ Super sweet syntactic sugar for Swift initializers

GitHub - SnapKit/SnapKit: A Swift Autolayout DSL for iOS & OS X

이전 프로젝트는 StoaryBoard를 활용해서 UI개발을 진행했습니다.

하지만, 이번 프로젝트 만큼은 디자인 시스템을 꾸려서 코드 몇줄에 뷰가 그려지도록 하는 로망(?)을 이루고 싶었고,

효율적으로 UI를 개발해서 다양한 곳에 쓰이게 하고 싶었거든요.

 

실제로 이전 프로젝트에서 디자인 시스템 개발 없이, 커스텀 뷰 개발 없이..(!) StoaryBoard로 UI를 그리다 보니,

같은 UI Componenet가 여기저기에 복사 붙여넣기가 되는 현상이 나타났어요.

 

예를 들어 NavigationBar 같은 경우에, 커스텀으로 제작했지만 커스텀뷰로 따로 만들지 않았기 때문에, 모든 VC마다 복붙이 필요했어요.

그런데 그 뷰에 폰트 위치가 1pt만 바꾸어도 수 십개의 VC를 모두 수정해야 하는 상황이 생겼습니다.

 

이런 경험을 몇 번 하다보니까, 커스텀 뷰를 만드는 것에 대한 니즈가 있었고

더 나아가서 디자인 시스템을 만들어 효율적으로 UI 개발을 하고 싶었습니다.

 

---

3. 린하고 애자일하기 위한 노력

기획과 디자인, 개발이 서로 병목없이 어떻게 협업할 수 있을까?

우리는 '기획-디자인-개발' 순으로 진행하고 싶지 않았어요(!)🥲

이게 무슨 말이냐구요?

기획하느라 디자인/개발이 쉬고 있고, 디자인하면서 기획/개발이 쉬고,

결국 나중엔 개발만 진행하고 나머지 포지션은 쉬게 되면서

각자 맡은 업무에 병목이 나타나지 않았으면 좋겠다고 생각했거든요.

(사실 유토피아적 생각이긴 했지만요!)

 

그래서 저희 팀은 이런 저런 노력을 해보았는데 어떻게 되었을까요?

결론만 말씀 드리면 힘들더라구요 ㅎㅎ..

결국 후반에는 기획 요구사항이 있어야, 디자인이 진행되고 그걸 보고 개발을 시작하는 워터폴형식을 따르게 되었어요.

하지만, 초반에 병렬 개발로 진행했던 것이 아예 소용이 없었던 것은 아니었습니다.

 

빠른 기술 검증과 정보 공유, 기반 작업 및 룰 세팅 등

기획/디자인/개발이 어떻게 하면 지속적으로 협업을 해나갈 수 있을지 고민하는 가장 중요한 시간이었습니다.

 

3-1. 개발은 기술 검증을 빠르게 하자

최대한 기획이 원활하게 진행될 수 있도록 개발자는 적극적으로 서포트한다.

기획 시즌에 개발자가 가장 많이 듣는 질문일 거예요.

"개발자님, 이거 개발가능 하신가요?"

기획자는 개발이 가능해야 세부 기획을 시작하기 때문에, 개발자는 해당 아이디어에 대해 실제 개발이 가능한지 빠른 기술 검증이 필요해요.

개발자는 우리 팀에서 저 혼자였기 때문에 아래와 같은 프로세스로 진행 했습니다.

 

• 리서치로 찾을 수 있는 검증 사항이라면, 빠른 리서치 후 기획팀의 병목 현상을 풀어준다.
• 리서치로 찾았지만 실제 적용 되는지 확인이 필요하다면, 프로토타입 개발 후 실시간으로 정보 공유
• 리서치로 나오지는 않지만 가능할 것 같은 경우, 프로토타입 개발 후 제약사항 실시간으로 정보 공유

 

최대한 빠른 기술 검증으로 기획과 디자인 팀이 본인 업무를 진행하는데 병목 현상을 겪지 않도록 했습니다.

가장 중요한 것은 실제로 개발이 가능한 지를 빠르게 테스트하고 '정보를 공유'하는 것이었습니다.

 

어느 순간, 기획자는 개발자만 바라보고 있는 상황이 생기더라구요.

제가 Yes/No를 해주어야 진행하게 되는데, 제 대답이 늦어지면 모두의 일정이 딜레이되는 현상을 최대한 막고자 했습니다.

 

3-2. 기획과 함께 UX를 검증해보자

작성된 UX를 보며 상상의 나래를 펼쳐보자.
개발자가 직접 검증하면, 같은 기획이더라도 기술적으로 보다 쉬운 방향으로 기획을 풀어낼 수 있다.

디자인 결과물도 없이 기획된 결과물만 가지고 없는데 UX를 검증한다는 것은 꽤나 어려운 일이었습니다.

먼저 개발을 진행할 때는 '당연히 수정은 진행한다'는 생각으로 Temp 코드를 작성했습니다.

실제로 검증한 코드가 사용된 경우도 많았는데요.

예로, 실제로 UI 디자인과 UX 검증에 사용되었던 코드가 크게 다르지 않아서

로직 코드는 그대로 사용하고 UI만 변경했던 코드가 굉장히 많았고, 실제 앱 개발 속도도 매우 빨라졌습니다.

 

그리고 세부적인 UX보다는 전반적인 큰 틀에서의 UX를 검증한다는 느낌으로 진행했습니다.

예를 들어서, 일기장 어플리케이션의 '일기장 작성하기 UX'를 상상해보곤 했습니다.

저는 아래와 같이 상상해 간단한 UI를 그려보았는데요.

1. 홈에 글 작성 버튼이 있을거야!
2. 글 작성 버튼을 누르면 작성 스크린이 Presenting 될거야!
3. 제목과 내용을 입력하고 글 작성 완료 버튼을 누르면...
4. 홈이든 어디든.. 작성된 글이 TableView형태로 나타나겠지?

매우 간단한 UX 검증이지만 저는 여기서 미리 개발할 수 있는 것들이 꽤나 있었습니다.

그리고 처음 사용하는 RIBs에 대해서도 미리 스터디할 수 있는 시간을 가지게 되었구요.

이는 결론적으로 실제로 기능 개발을 진행할 때 큰 도움이 되었던 시간이었습니다.

 

그리고 회의 시간이나 카톡에다가 한 마디 던져 놓으면 더 좋죠.

"기획자님, 이거 해보니까 되더라 ㄱㄱ😎"

 

3-3. 모두 피그마로 모여!

커뮤니케이션 코스트를 줄여보자.
회의는 피그마를 통해서 하고, UX와 UI그리고 디자인 시스템은 모두 피그마에서 확인하자.

최대한 기획자와 디자이너 담당 팀원과 긴밀하게 소통하고자 했습니다.

개발자가 편한 툴로 디자이너와 기획자를 이주 시키면, 개발속도는 빠를지 몰라도

사이드 프로젝트에서는 개발 속도보다는 기획 추진력과 디자인 완성까지 도달하는 시간이 가장 중요하다고 생각했거든요.

 

그래서 제가 직접 피그마로 참여해서, 모든 소통은 피그마에서 같이 했어요.

IA나 Design System에 사용된 Component들은 모두 피그마에서 관리했어요.

 

디자이너가 Component를 수정하게 되면, 피그마에서 에셋을 일괄로 추출해서

실제 개발에 사용된 프로젝트에 넣기만 하면 앱에 적용되는 형태로 진행했습니다.

실제 프로젝트에서 Image Asset을 사용한 예시 -1

실제 프로젝트에서 Image Asset을 사용한 예시 -2

특히, 디모다모를 진행하면서 컬러 에셋이 변화하면서 코드까지 변경되는 상황이 많이 연출이 되었는데,

이럴때도 효율적인 컬러 에셋 관리를 위해서 룰을 추가하기도 했습니다.

• 특수한 상황이 아닐 경우, 컬러 에셋에 컬러 네임이 들어가지 말 것
• {다크/라이트테마}/{역할}/{부역할}/{채도/명도}

실제 코드에서 Color Asset를 사용한 예시

이러한 룰들을 초반에 만들지 않으면 후반에 굉장히 힘들어지는 것을 경험했기 때문에,

최대한 개발자와 디자이너 모두가 편리한 방식을 채택하기 위해서 통일된 룰을 가져가고자 했습니다.

---

4. 첫 번째 회고 포스팅 마무리

앱을 만든다는 것은 참 어렵습니다.

'일기장' 이라고 생각했던 것들에도 생각보다 많은 고민이 필요했고,

유저들이 실제로 사용했을때 어떤 차별화 포인트가 필요할까?에 대해서도 많이 고민하게 되었습니다.

 

이전에 겪었던 시행착오를 바탕으로 '더 나은 어플리케이션'을 위해서,

'더 유기적인 커뮤니케이션'이 되기 위해서 노력했던 것 같습니다.

 

1년 동안 긴 호흡으로 달려오면서 잘 지켜지지는 않았습니다만, 초반에 닦아놓은 기본적인 네이밍 컨벤션이라든가,

디자이너와 소통하기 위한 디자인 에셋 룰등을 정한 것은 매우 잘한 일이라고 생각합니다.

실제로, 개발하면서 디자인 에셋에 의해서 문제가 생기긴 적은 단 한 번도 없었으니까요! 😎

 

하지만, 조금 아쉬운 점은 디자인과는 좋은 소통을 시도했으나, 기획과는 약간 거리감이 생긴 것이 아쉽습니다.

디자인 에셋과 개발의 유기성은 어느정도 확보했지만

기획이 실제로 디자이너의 손을 거치고 개발로 진행되었을때 상당수 변화되는 부분도 있었고,

기획자와 디자이너, 그리고 개발자가 서로 이해하는 것이 달라서 다른 결과물이 나온 경험도 있었습니다.

 

위와 같은 세세한 경험은 다음 포스팅에서 이어 적도록 하겠습니다!

회고를 적다보니 할 말이 참 많아지는 포스팅이 되어버렸네요!

 

할 말이 많아서 쭈욱 적어보겠습니다,, 트라이트라이..