씀 - 클론코딩

씀 클론코딩

와플 스튜디오에서 2020년 하반기 Rookies Seminar가 끝나고 진행한 toy-project로 여러 조로 나누어서 실제 서비스를 클론 코딩하는 프로젝트를 진행하였고 우리 조는 글쓰기 어플인 ‘씀’을 클론 코딩하였다. 코드는 아래 repo에서 확인해볼 수 있다.

• github repo

구현 범위

기간이 정해져 있었던 프로젝트였기도 했고, 기말고사 기간이 겹치기도 했기 때문에 백엔드와의 소통을 통해 실제 ‘씀’ 서비스 중 필수적인 서비스만 구현하기로 하였다. 정리한 리스트는 다음과 같다.

글쓰기

메인 | 오늘의 글감과 글을 실제로 작성하는 UI로 갈 수 있는 버튼이 존재 | 구현
- 실제 서비스에서는 매일 오전 7시/오후 7시 마다 새로운 글감을 추천해주었으나, 백엔드에서 자동으로는 구현하기 어렵다고 하여 일단은 기존 글감 중 하나를 수동으로 '오늘의 글감'으로 추천하는 것으로 결정함

인용구 | 글감에 대해 대표글을 제공함 | 미구현
- 각각의 글감에 대해서 인용구를 모두 찾기 어려웠고 관련하여 구현하지 않기로 결정

글 리스트 | 글감에 대해 유저들이 작성한 글 리스트를 보여줌 | 구현

글 작성 | 글 작성 UI | 구현
- 글 작성 UI에서 볼 수 있는 여러 UI 중 복사/정렬/글자수 는 구현을 마쳤으나 맞춤법 검사는 Daum 맞춤법 Api가 제공되지 않는 것을 확인하고 구현하지 않는 것으로 결정

글감

글감 리스트 | 글감 리스트를 보여줌 | 구현

글감 검색 | 필터에 따른 글감을 검색하여 글감 리스트를 갱신 | 미구현
- 오늘의 글감에 대한 구현의 문제로 '모든 글감/공식 글감'의 경계가 희미해져 구현이 후로 미루어졌었고, 결국 구현하지 못했음

글감 클릭 시 글 리스트 | 글감에 대해 유저들이 작성한 글 리스트를 보여줌 | 구현

나의 글

나의 정보 | 유저의 필명 및 한 줄 소개를 보여줌 | 구현

나의 글 | 유저가 작성한 글들을 보여줌 | 구현

나의 모음 | 유저가 작성한 글들을 카테고리 별로 모은 '모음'을 보여줌 | 미구현
- 모음을 구현하기 복잡하다고 판단하였음

구독

구독 글 리스트 | 유저가 구독한 다른 유저의 글들을 보여줌 | 구현

구독 목록 | '내가 구독 / 나를 구독'한 유저를 보여줌 | 미구현
- 백엔드에선 구현되었지만 안드로이드 클라이언트에서 시간 문제로 구현하지 못함

보관함

최근 읽은 모음 | 유저가 최근에 읽은 모음을 보여줌 | 미구현
- 모음을 구현하지 않았기 때문에 구현하지 않았음

담아온 글 | 유저가 담아온 글들을 보여줌 | 구현

사용 기술

• Dagger Hilt - 기존 Koin의 경우 런타임에 의존성을 주입하기 때문에 컴파일 시에 의존성을 주입하여 더 안정적인 Dagger Hilt를 쓰는 방향이 더 좋다는 PM의 제안을 받아들여 Dagger Hilt를 활용하여 Dependancy Injection을 구현하였다. 기존에 Seminar에서 Koin을 활용하던 방식과 달라 처음 시작에 애를 먹었지만 관련 문서와 코드를 보며 정리하여 사용 방식을 익힐 수 있었다.

• RxJava - Seminar Assignment를 진행하던 때에는 RxJava를 활용한 Asynchronous Process를 Http request을 보낼 때만 제한적으로 사용하였기 때문에 RxJava의 성능을 과소평가하고 있었다. 심지어 사용한 기능이 subscribeOn, observeOn, subscribe 이 셋만을 사용하였기 때문에 RxJava의 제 기능을 활용하지 못했었다. 하지만 이번 프로젝트를 진행하면서 pagination을 활용한 RecyclerView 정보의 갱신, Dialog의 사용 등에 Asynchronous Process 및 Reactive Programming을 적용하면서 RxJava의 무한한 사용 가능성을 확인하였다. 특히나 BehaviorSubject를 활용하여 pagination을 활용한 정보를 갱신하는 방식, flatmap or map 등을 사용한 정보의 가공 등을 이용해볼 수 있었다.

• 그 외 - Timber을 사용한 Logging, Moshi를 사용한 Json 파싱, Retrofit과 OkHttp를 활용한 http 통신, MVVM Architecture을 적용한 애플리케이션 구조 등을 활용하였다.

협업에 관하여

소통

팀 내에서 소통을 위해 Slack을 활용하였다. 현업에 종사하고 있는 세미나 장들이 카카오톡을 활용하지 않고 Slack을 적극적으로 활용하려는 모습이 Slack을 한 번도 제대로 활용해보지 않았던 입장에서는 이해할 수 없었다. 하지만 프로젝트가 끝난 뒤, Slack을 활용하여 프로젝트를 하는 방식이 훨씬 효율적이라는 생각을 하게 되었다. Thread를 활용한 대화 방식을 통해 하나의 issue에 집중할 수 있었으며, github watcher을 통해 실시간으로 우리 팀의 개발이 진행되고 있는지를 확인할 수 있었다. 그리고 custom emoji가 있다.

API

18.5 Rookies 중 백엔드 세미나 이수자가 많았던 터라, 팀 구성은 3 Backend + 2 Android로 이루어졌다. Backend 세미나를 이수했었기 때문에 서버의 구현에도 참여를 할 수 있는 상황이었지만, Android 클라이언트 개발자로서 Backend와 어떻게 소통하여 협업을 진행할 것인가에 집중하기 위해 Backend 내부 구현보다는 Backend와 Android의 접점에 있는 API 구성에 많은 기여를 하는 것으로 결정하였다.

가장 먼저 회의했던 내용은 구현 범위에 대한 것이었다. 프로젝트 기간 내에 목표하는 서비스의 Backend에서의 구현 가능성과 Android에서의 구현 가능성을 고려하여 구현 범위를 제시하였고 위에서 제시한 리스트에 맞추어 구현할 수 있었다. 타 팀의 회의 내용을 확인해볼 수는 없었지만 발표 과정에서 아직 미구현 된 기능들을 소개하는 것을 보며 우리 팀의 방향성 설정이 알맞게 진행되었다고 스스로 평가할 수 있었다.

다음으로 회의했던 내용은 구현 범위에 맞춘 API endpoint들을 어떻게 구현할 것인지였다. 이 과정에서 약간의 문제가 있었는데 Backend와 Android 간의 소통이 원활하게 이루어지지 않았던터라, 프로젝트가 끝날 때까지 API endpoint 구성이나 response 구성을 변화시키는 일이 있었다. 팀 프로젝트 진행 도중 혼자 여러가지를 개발하려 시도하던 도중 발견한 Riot API와 비슷한 구조를 시작부터 공유하였다면 더 효율적인 협업이 되었을 것인데 그 부분이 아쉬웠다. Riot API 에서는 각각의 endpoint별로 Dto를 제시하여 클라이언트의 입장에서 여러 endpoint들이 하나의 Dto를 공유할 수 있어 코드의 재사용성을 높힐 수 있도록 한 것 같았다. 하지만 이번 팀 프로젝트에서는 이런 구조를 사용하지 않았고 endpoint별로 각각이 필수적으로 필요한 data들만 제시되어 있었다. 물론 Riot API와 같은 구조를 사용한다면 불필요한 data들이 reponse로 넘어갈 수 밖에 없다는 단점이 존재한다. 하지만 Android 클라이언트를 개발하다보니 처음에는 불필요하다고 생각했던 정보들이 이후 필요해져서 새롭게 다른 endpoint를 활용하여 다시 통신을 해야하는 경우가 생겼기 때문에 개인적으로는 Dto를 제시하고 재사용하는 방식이 더 좋아보이는 것은 어쩔 수 없다고 생각한다.

Client 개발

확실하게 협업을 하지 않으면 개발의 속도가 느려지는 것을 느낄 수 있었다. ‘Branch 생성 - 개발 - Review - Review 적용 - Approve - Merge’ 의 과정이 적절하게 톱니바퀴 돌아가듯이 맞아떨어지지 않으면 B 구현을 위해 A의 merge가 필요한데 review를 기다리고 있는 상황을 마주하는 등 개발의 템포가 느려졌다. 하지만 이는 동아리 프로젝트라는 다소 느슨한 환경에서 협업이 진행되었기 때문이고 실제 회사와 같은 구조에서는 빠른 review를 통해 개발할 수 있을 것이라 생각하였다.

결과

프로젝트에 참여한 8개 팀 가운데 상호평가(7점 만점)에서 2위를 하는 결과를 얻을 수 있었다. 기존 앱 디자인의 세련됨 및 적절한 구현 범위 세팅을 통한 완성도 이 두 가지 요인이 좋은 평가를 받은 원인이라고 생각한다. 프로젝트를 진행하며 기존에 알지 못했던 다양한 기술을 적용시킬 수 있었던 점을 가장 큰 수확이라고 생각한다. 배운 다양한 기술과 지식을 연마하여 완전히 내 것으로 만드는 데에는 시간이 필요하겠지만 첫 걸음을 성공적으로 뗀 것은 분명하다. 이 toy-project만으로 동아리 활동이 끝나는 것은 아니기 때문에 Android Developing에 대한 공부는 여전히 진행중에 있고, 다른 project를 통해 내 개발 실력을 한 층 더 끌어올릴 수 있는 기회가 오면 좋겠다.