[팀 프로젝트 회고]

코쿼 이후 첫 팀 프로젝트 회고

원래 매주 쓰려고 했는데... 흑흑
역시 꾸준히 하는 게 어려운듯하다.

시작

코쿼가 끝난 후 안드반 동료분에게 연락이 왔다.
"끝나고 뭐하시나요? 같이 팀 프로젝트해보시는 거 어떤가요?"
마침 이제 어떻게 해야 하나 고민 중이었는데 룰루 바로 좋다고 하고, 팀에 합류하였다.

멤버는 안드 2, 백엔드 2, 디자인 1
아주 좋은 구성이라고 느꼈고 디자이너 분과의 작업은 처음이라 굉장히 기대가 되었다.

코쿼에서는 기획서를 보고 거기에 맞게 구현하고, 만드는 것만 했지 디자이너 분과 협의를 하며 진행할 수 있다는 게 굉장히 기대가 되었고 좋았다.

프로젝트 시작 07.25

07.25 프로젝트를 시작하고 기간은 한 달 8.25까지로 기한을 잡았다.
기간이 없으면 너무 늘어질 수도 있다고 다들 동감하였기에 기간을 잡고 임하게 되었다.

첫 회의를 시작하고, 깜빡하고 첫 스크럼을 빠져버려서..... 너무 죄송했다.
앞으로는 이런 일이 없게 하겠다고 사죄드리고 실제로 끝날 때까지 지각도 한 번도 안 함 ㅎㅎ

그렇게 대충의 기획서가 나오게 되었다. (이때까지 디자이너분을 구하지 못했음)
ppt를 이용해서 대강의 프레임과 기능 등을 정하였고, 개인적으로 기능이 너무 커지면 감당할 수 없어져서 프로젝트를 망치는 경우가 많다고 해서 그 부분에 대해서 이야기했는데 다른 팀원 분들도 동의를 해주셔서 마찰 없이 서로 기능을 이야기하고, 너무 어려울 거 같으면 뒤로 미루는 식으로 어플의 콘셉트와 기능을 추려나갔다.

디자이너 에바 합류

스타크의 불이 나는 노력으로 디자이너 에바를 모셔올 수 있었고, 우리가 만들었던 콘티를 받아서 아주 멋지게 바꿔 주셨다.
그 후 에바의 와이어프레임을 보며 가능할 거 같은 기능과 시간을 많이 잡아먹을 거 같은 기능을 분리해서 에바에게 스크럼 때 전달해드리고,
그 부분이 디자인이나 기획적인 부분에서 크게 의미가 있는 부분이 아니라면 제외하는 식으로 진행을 하였고, 기획의도나 이용자 편의를 위해서 꼭 필요하다면 좀 까다롭더라도 구현하는 쪽으로 가닥을 잡으며 회의를 진행하였다.

9.6 프로젝트 마무리

그렇게 8.26까지로 계획했던 프로젝트는 이제야 마무리를 하게 되었다는 전설이...
아직도 완성이라고 하기에는 에러도 많이 남았지만 그래도 우리가 생각했던 기능이나, ui는 구현이 완료되어서 다행이다.
이제 코드를 정리하고, 구현하느라 신경 쓰지 못했던 부분들을 정리하려고 한다.

🏠집 넘기기 App

github : https://github.com/street62/Home-Rent-App.git

📱주요 기능

• 카카오, 네이버 로그인 (OAuth2 & JWT)
• Data Store를 이용한 자동 로그인
• splash screen을 이용해서 자동 로그인 로직 완료 후 홈 이동
• Stream SDK를 이용한 채팅
• 하단 탭 (Bottom navigation)
• FloatingAction button을 이용한 메뉴
• AppcompatEdittext, AppCompatImageView를 상속받은 커스텀 뷰
• 앨범에 접근해서 사진 가져오기
• Drag And Drop을 이용한 선택 사진 위치 변경
• stateFlow를 이용한 2 way databinding
• sharedFlow를 이용한 이벤트 처리
• ViewPager2를 이용한 이미지 보여주기
• flow를 이용한 실시간 검색
• Authenticator를 이용한 JWT 갱신 요청

✏️구현 중 문제 사항

나름 기한을 잡고 제대로 해보려고 했던 프로젝트인 만큼 많은 것을 공부할 수 있었고, 아주 재미있었다.
팀원들도 다들 너무 좋았고, 다 같이 회의도 하고 하니 뭔가 제대로 개발을 하는 느낌 ㅎㅎ

그만큼 고민도 많이 하고, 문제도 많이 있었다.(물론 아직도 많을 것이다...)

그중 내가 고민하고 해결했던 몇 가지 문제들을 정리해 보려 한다.

 

Flow collect가 안됨 

이번 프로젝트를 진행하며 느낀 것 부족한 점은 Coroutine과 Flow 등의 대한 이해와 생명주기에 대한 공부가 많이 필요하겠구나라고 느꼈다.
그 시작이 된 부분이 collect였다.
수업 때 suspend 함수에 대해서 배웠고, collect가 suspend 함수인 것도 다 배운 부분이었는데, 직접 체감을 하니 "내가 아는게 아니었구나"를 또 느꼈다.
문제는 UserSession 객체에 유저 정보를 넣어놓고, 접근을 하려 했다.
그때 자동 로그인이 되어있을 경우 DataStore에 유저 정보(id, 프로필 사진 링크, 닉네임)를 가져와서 UseSession에 넣어야 했다.
DataStore는 Flow를 이용하게 되어있어서 collect를 통해서 데이터를 받아와야 했는데, collect를 작동하면 같은 launch 아래의 함수들이 작동하지 않는 상황이 발생하였고, 내부 구현에서 suspend를 보고 나니 "아! suspend는 정지지!"라는 생각이 바로 떠올라 launch를 하나 더 생성해서 해결하였다.
(그리고 UserSession에는 user id 값만 저장하도록 변경...)

Refresh Token 갱신

이번 프로젝트에서 JWT를 사용을 하고 access token이 만료될 시 refresh token과 access token을 헤더에 넣어서 서버에 요청을 해서 토큰을 갱신하고, 헤더의 access token을 변경 후 진행 중이던 요청을 재요청을 보내야 했다.
이 부분에서 시간을 많이 잡아먹었다....
처음에는 그냥 401 잡아서 다시 요청하면 되겠다 했는데....
세상에 쉬운 일은 없었다.
처음에는 okhttp3의 Interceptor를 이용해서 갱신 요청을 해보려 했는데 진행 중이던 사항을 다시 재요청하는 게 힘들다고 판단해서 고민을 하던 중
안드 선배님들이 계신 단톡방에 질문을 드렸고 한분께서 Authenticator라는 키워드를 알려주셔서 그 부분에 대해 찾을 수 있었고, 무사히 토큰 갱신 요청 처리를 할 수 있게 되었다.

 

Authenticator 적용 중 runBlocking의 사용

Authenticator를 사용 중 Coroutine의 문제가 또 발목을 잡았다.
토큰 갱신 요청을 하고, 응답이 오면 갱신된 토큰을 헤더에 넣고 재요청이 진행이 되어야 했는데
Coroutine을 사용하다 보니 응답이 오기 전 return으로 가버려서 같은 토큰을 재요청을 보내는 상황이 발생을 하였다.
이 부분을 고민하던 중 스타크가 runBlocking에 대해 제안을 하였고, 나는 이번 기회로 막연하게 쓰면 안 된다고만 생각했던 runBlocking에 대해서 공부할 수 있었다.
runBlocking을 사용하면 안 되는 큰 이유는 스레드를 중단시켜 ANR을 발생시킬 수 있기 때문인데
우리가 사용할 때는 Main 스레드를 사용하는 것도 아니고, 데이터의 동기화가 필요한 사항이라고 판단해서 runBlocking을 사용해도 되겠다는 확신을 가지고 runBlocking을 사용하게 되었다.

 

Stream SDK 커스텀

Stream SDK를 이용하여 채팅 기능을 구현하기로 결정

작업에 들어가게 되었다.

그런데 디자인 요구사항에 맞게 커스텀하는 과정에서 어려움을 많이 느꼈다.

UI 자체를 커스텀하게 되면 스와이프 같은 기능들을 직접 구현해야 했기에 시간상 뜯어고치는 것을 자제하고,

MessageComposerView를 이용해서 채팅 입력 창의 아이콘 등을 커스텀하였는데,

공식문서에는 MessageComposerView를 사용하라는 말이 있는데 내 거에선 찾을 수없는 문제를 만났다.

그래서 바로 github을 가서 MessageComposerView를 사용한 코드를 찾았고, 그 프로젝트의 Stream SDK 버전이 나보다 높다는 것을 알게 되어서 버전을 맞춰서 해결하게 되었다.

그리고 커스텀 자체는 Stream SDK 홈페이지에 있어서 쉽게 해결하였다.

 

아쉬운 점

 

아쉬운 점이 없을 수 없다.

일단 팀원들과 오프라인에서 모두 볼 수 없었다는 점이 아쉬웠다.

다들 가까우면 만나서 얘기했으면 좋았을 텐데 ㅠㅠ 팀원들이 거리가 멀어서... 아쉬웠다.

 

그리고 작업을 진행하면서 아쉬웠던 점은 안드 팀원이 스타크와 좀 더 자세하게 함수명, 변수명, 설계 등에 대해서 이야기를 하지 못한 점이 아쉬웠다.

지금도 해결 중인 문제지만 같은 DTO인데 두 개를 만들거나, 이름만 다른 함수가 두 개가 생기거나 하는 일이 있었고,

설계적인 부분도 더 세밀하게 대화를 했어야 했는데 둘 디 처음이다 보니 얘기가 끝난 줄 알았는데 서로 다른 생각을 해서 꼬일 뻔한 적이 몇 번이었다.

그리고 패키지 명 같은 부분도 다음에 또 기회가 된다면 더 세밀하게 정하고 시작을 해야겠다는 생각이 들었다.

(물론 회사는 정해져 있겠지만.... 회사를 가야.... ㅠ)

 

마무리

 

이번 프로젝트로 인해서 많이 공부를 하게 되었고,

무엇보다 너무 재미있었다.

직접 회의도 하고, 디자인, 기능적인 부분에서 서로 의견을 제시하고, 양보하면서 진행을 하니 기획서를 보고 구현을 할 때와는 다른 부분도 고민할 수 있었고, 커뮤니케이션에 대한 중요성도 배울 수 있었던 거 같다.