[TIL] 24.04.08 팀 프로젝트 회고

1. 팀 프로젝트

 팀 프로젝트가 우여곡절 끝에 마무리 됐다. 완벽한 완성도는 아니었지만, 의미 깊은 프로젝트였다고 생각한다. 발표를 위해 만들어둔 프레젠테이션 자료를 보며 되돌아볼까 한다.

 

 

 일단 목표가 여기 적어둔 것처럼, 온전한 팀 프로젝트를 경험하는 것에 초점을 맞췄다. 그래서 팀원들에 여건에 맞춰 적용할 기술을 선택했고, 구현할 기능도 욕심내지 않았다.

 

 

 역할 배분에 내 의견이 많이 반영됐는데, 그래도 팀원들이 모두 본인 역량을 조금 웃도는 수준으로 경험하면 좋겠다 싶어서 그 정도의 선을 기준으로 분배했다. 내가 처음 안드로이드를 공부할 때 그게 도움이 많이 됐기 때문인데, 러닝 커브가 가파르니까 일단 부딪혀서 조금 어렵다 싶은 것들을 어떻게든 해내다 보면 지나고 봤을 때 많이 성장해 있었던 것 같다.

 대신 그만큼 팀원들이 다양한 경험을 하되, 괜한 곳에서 시간 끌리지 않도록 신경을 많이 쓴 것 같다. 이번 프로젝트를 하면서 남의 코드를 리뷰하는 시간과 형상 관리 문제들을 해결하는데 시간을 정말 많이 썼으니까.. 또 갈피를 못 잡으면 오래걸리는 부분들은 내가 도맡아 한 것 같다.

 그리고 되도록이면 정답을 알려주진 않고, 의도를 물어보고 로직을 떠올릴 수 있는 방향으로 많이 도왔던 것 같다. 물론 바로바로 해결책을 알려준다면 프로젝트가 훨씬 시원시원하게 진행됐겠지만, 나는 이런 고민들은 어차피 해야하는 과정이라고 생각했다. 특정 기능을 구현하기 위해 했던 고민이 쌓여서 경험치가 되고, 다음에 비슷한 기능을 구현할 때는 막힘없기 구현할 수 있으니.

 

 

 위와 같은 팀 컨벤션을 정해두고, 브랜치 관리를 위한 컨벤션도 정해뒀지만 잘 지켜지지는 않았다. 사실 처음에는 의식하지 않으면, 챙기기가 힘든 부분이라고 생각해서 그러려니 했다. 괜히 이런 요소로 압박감을 주기 싫기도 했고..
 운전에 익숙해지면, 자연스럽게 주변 도로 환경까지 머리에 집어넣으며 주행하는 여유가 생기듯이, 개발 자체에 익숙해지면 신경 쓸 여유가 훨씬 생길테니까. 그리고 당장 나부터가 GitHub를 십 분 활용하지 못하고 있는 것 같아서, 항상 노력하고 있다.

 

 

 요구되는 필수 구현 사항들에 비해, 일정은 꽤나 타이트 했다. 그래서 기능이나 도입 기술에서 큰 욕심을 내지 않기로 하고, 타임라인을 여유롭게 설정한다고 설정했는데 그것도 지켜지지 않았다. 사실 화요일에 느낌이 제때 PR을 못 받을 것 같은 느낌이 들긴 했다. 팀원들의 구현 정도로 미루어 보았을 때, 수요일 오전까지 완성될 속도가 아니었기 때문이다.

 같은 팀원의 입장에서, 데드라인에 도달하지도 않았는데 막 묻고 그러기가 꺼려졌다. 만약 본인이 충분히 역량이 있는 사람이고, 제때 맞춰 해올 수 있는데 그런 닥달 아닌 닥달을 들으면 불쾌할 것 같아서다.

 결과적으로는 내가 세심하게 체크를 했어야 하는 부분이었지만, 데드라인을 준수하는 건 정말로 중요하고 본인의 역량을 객관적으로 파악해서, 플랜 단계에서부터 기한 안에 된다 안된다를 가늠하는 것 또한 매우 중요한 능력이라고 생각한다.

 이런 건 경험을 몇 번 해봐야 더 와닿는 부분이기도 하고, 다들 초심자인걸 생각하면 그럴 수도 있겠다싶어서 그냥 딜레이에 맞춰서 계획을 수정했다. 

 

 

 앱에 필요한 기능들을 매우 단순했다. 복잡한 로직이나, 엄밀하게 설계된 구조보다는 UI 구성 능력을 토대로 구성할 수 있는 내용이 많았다. 안드로이드의 기본적인 요소들을 조금 얹어야 하긴 했지만 그래도 심플했다.

 

 

 실제 구현과정은 딱히 특별할 것이라곤 없었다. 각자 맡은 기능 열심히 구현하고, PR 및 코드 리뷰 진행 후 브랜치 합치고, 팀원들이 고민하는 부분 함께 고민하고, 버그 찾아서 개선하고, 기능 추가하고의 반복이었다. 대신에 최대한 팀원들이 기존 강의에서 접한 내용들이나 사용하는데에 어려움이 없는 것들 위주로 이용했다.

 

 

 마지막에 더보기 기능이나, 유효성 검증 과정을 가다듬고, 트랜지션 및 레이아웃을 좀 가다듬고 나니 그래도 완성도가 꽤나 올랐다. 나는 사실 개발에 있어서 심미적인 부분도 중요하지만, 그보다 우선되어야 하는 것은 요구 사항의 충족이라고 생각한다.

 곧 죽어도 제한 시간 내에 요구 사항은 모두 달성해야 하고, 이후에 퍼포먼스도 개선하고 UI/UX도 세심하게 바꾸는 것 맞지 않을까 싶다.

 껍데기만 화려하게 감싸놓으면 어디 보여주기엔 좋겠지만, 내부에 고민해서 들어간 로직과 존재 이유가 명확한 코드들이 훨씬 더 우아하다고 생각한다. 물론, 챙길 수 있다면 심미적인 요소도 당연히 챙기는 것이 맞다.

 이런 측면에서, 팀원들과 함께 만든 프로젝트는 완성도가 꽤나 괜찮았다. 코드의 견고함에 있어서는 깐깐하게 리뷰했고, 실제로도 신경을 쓰기로 한 부분들에 대해서는 견고한 코드가 작성됐다.

 

 

 

 당연히 이슈도 많았고, 대부분 코드 리뷰나 화면 공유를 통해 함께 문제점에 대해 토론하는 방법으로 해결했다. 되도록이면 팀원들의 의견을 먼저 존중하고, 의도를 물은 뒤에 발생한 문제의 원인과 결과를 짚는 식으로 진행했다. 그 와중에도 절대로 코드를 어떻게 작성하라고는 안 하고, 로직에 대한 인사이트만 제공했다. 시간은 오래 걸렸지만, 그렇게 하니까 팀원들의 실력이 많이 늘어가는게 체감 됐다.

 또 팀원들이 열심히 작성한 코드에서 좋은 점도 찾아서 칭찬하고, 배울 건 배우고, 또 내 코드에 대한 질문들도 상세하게 답변하면서 나도 한층 단단한 지식을 가지게 된 것 같다. 누군가와 질의응답을 주고 받는 과정이, 내가 무엇을 알고 모르는지를 좀 더 명확하게 해주는 것은 이미 잘 알려진 사실이다.

 

 

 

 어려움도 많았고, 힘들었지만 과정을 생각하자면 만족스러웠던 프로젝트였다. 팀 프로젝트에서 생길 수 있는 개발 외적인 상황들도 경험했고, 소프트 스킬도 많이 활용해볼 수 있었다.

 나 또한 팀원들의 코드나 생각을 보면서 공부가 많이 되었고, 팀 프로젝트의 과정을 온전하게 경험하겠다는 소기의 목적은 제대로 달성한 것 같다. 다음에는 좀 더 좋은 프로젝트를 진행해 볼 수 있을 것 같다.

 

 내가 많이 부족했지만, 의지하고 따라준 팀원들에게도 감사의 인사를 전하고 싶다. 팀에 성격 나쁜 사람이 없어서 정말로 좋았고, 그렇기 때문에 다들 고생도 많이 했지만 그 이상의 더 좋은 성과를 낼 수 있었다고 생각한다.