[TIL] 24.04.01 챌린지반 세션, 앱개발 입문주차 팀 프로젝트

1. 챌린지반 세션

 

 저번 주에 이어서 ViewModel을 이용할 때 유의해야하는 점들에 대해서 배웠다. 도중에 알게된 것이지만 DataBinding을 되도록 지양해야한다는 것은 조금 놀랐다. MVVM과 함께 썼을 때 정말 강력한 방법이라고 생각했는데, 지금에 와서는 득보다는 실이 많은듯 했다.

 보일러 플레이트 코드를 줄여주고, 양방향 바인딩이나 LiveData를 손쉽게 이용하게 해주는 것은 분명히 장점이지만, 협업 시에 코드 가독성을 해치고 디버깅이 어렵게 만든다는 것이 주요 골자였다. 더해서, Jetpack Compose가 구글의 권장사항이 된 이후로, 여러 기술적인 지원(KSP를 비롯)이 제대로 이루어지지 않아서 불안한 요소도 있다고 한다.

 듣고 보니, 충분히 납득할만한 이유들이었고, 나도 XML을 이용해 코드를 작성한다면 되도록 ViewBinding만을 사용해서 작성하도록 해야할 것 같다.

 

 그리고 새로운 과제가 나왔는데, 저번 주에 4주차 부분을 미리 해봤던지라 막 많은 시간이 필요한 정도의 분량은 아니었다. 예고했던대로, MVVM이 적용된 Validation의 구현이었는데 대신에 몇 가지 디테일한 요구사항이 있어 그에 맞춰서 수정할 생각이다. 튜터님께서 추가로 좀 더 생각해볼 수 있도록, View들에 대한 동일한 리스너를 설정할 때 리스너 설정 코드를 한번만 사용해서 모든 View에 적용할 수 있도록 해보라고 하셨다.

 들으면서 바로 View들을 한 자료구조에 묶어두는 방법은 떠올렸는데, 그렇게 되면 무엇을 기준으로 각각 다른 로직을 적용할지가 조금 애매해진다. 예를 들어서 같은 EditText라도 어떤 것은 비밀번호에 대한 Validation이 필요하고 어떤 것은 이메일에 대한 Validation이 필요할 것이다. 지금 떠올리기로는 id를 이용하는 방법과 View에 각각 tag를 지정해서 이용하는 방법이 떠오르는데, 이게 베스트인지는 잘 모르겠다.

 일단 고민을 좀 해봐야할 것 같다.

 

 

2. 앱개발 입문주차 팀 프로젝트

 이번 주차의 팀 프로젝트가 시작됐다. 일전에 구현했던, 팀과 함께 만드는 간단한 UI 앱이 있긴 했지만, 너무 간단한 작업이어서 사실 팀 프로젝트라고 체감하기 힘들었다. 물론, 그 때는 팀 프로젝트의 프로세스와 Git을 통한 협업을 맛본 것에 충분한 의의가 있다고 생각한다.

 

 이번 과제는 배운 것들을 이용하는 선에서 간단한 SNS 구현하기인데, 거창하게 CRUD가 모두 작동하는 SNS라기 보다는 데이터는 대부분 더미 데이터로 구현하고, Intent의 활용 등에 중점을 두는 것이 목적인듯 했다. 

 

 사실 저정도 선에서 생각하자면, 그리 복잡한 구성은 아니지만 Navigation이나 RecyclerView 등을 사용하지 않고 필요한 UI들을 그리는 것도 조금 생각해보아야 할 문제이고 무엇보다 주어진 기간이 일주일로 매우 촉박하다.

 팀 프로젝트에 숙련된 사람들로만 이루어져 있다면, 필요한 기능을 모두 구현하고도 남겠지만, 사실 나부터가 팀 프로젝트에는 아직 익숙하지 않다. 그런 상황 속에서, 와이어 프레임도 작성하고 기능 명세에 맞춰 역할 분배부터 타임라인 설정, 실제 구현, 지속적인 형상 관리, 코드 리뷰, 리팩터링, 발표준비까지 모두 해내야 한다.

 

 일주일 주고 온전하게 구현에만 신경 쓰라고 하는거랑 팀 프로젝트를 완성도 있게 완수해보는 것은 많이 다른 것 같다. 나는 전혀 튀고 싶지도 않고(하물며, 이 과제를 보고 발표를 듣는 이들이 내 취업을 책임져줄 사람은 아니니까..), 이 과제가 심도 있는 기술을 뽐내기 위한 과제는 정말 아니라고 생각한다. 물론 여유가 된다면, 팀원들과 조금 더 공부해볼 것과 발전시킬 거리를 생각해보겠지만, 그건 여유가 났을 때 얘기다. 나는 이번에 요구사항들과 발제 내용을 보면서 전혀 여유부릴 수 있는 일정이라는 생각이 안 들었다.

 

 그래도 이번 과제를 통해서, 확실하게 얻어 가고싶은 것은 만족스러운 팀 프로젝트의 과정을 경험하는 것이다. 유연한 일정 조정이나 상황에 맞게 적용할 기술을 선택하는 것, 서로 코드를 공유하고 리뷰해주는 것 등은 그 자체로 심도 있는 기술 스택 숙달과는 또 다른 가치가 있다고 생각한다.

 되도록이면 팀원들이 나로 인해서 불편함을 겪지 않았으면 좋겠고, 최대한 시간을 쪼개서 이번 프로젝트를 클린하게 끝내고 싶다. 타이트하게 하지 않으면, 필수 요구사항만 모두 구현하면서 일정 맞추기도 벅찰 것이다..

 

 

 대략 이런 느낌으로 팀원들과 노션도 작성했는데, 이것도 좋은 경험인 것 같다.