1. 개발
추상화
- 컴포넌트 재사용하기 위해 고민을 했다. ProgressBar를 구현하는데 로그인 뷰에서는 페이지가 5개, 기록 뷰에서는 페이지가 3개라면 이 설정값을 어떻게 전달할지 같은.
- 컴포넌트를 만들어 재사용하는 것은 좋으나 컴포넌트 안에 컴포넌트를 addSubview하면서 Subview가
어떤 컴포넌트에 속해있는지 찾기 힘들었다. - Delegate를 통해 컴포넌트의 state를 전달하는 로직을 구현할 일이 많았는데, Delegate를 사용하는 방법은 알아도 어떤 변수를 위임해야 하는지, 위임받은 뷰에서는 변수를 어떻게 호출하고 사용해야 하는지 감이 안 잡혔다.
- 이 상황에서 받은 솔루션은 일단 ViewController에 다 넣고 난 후에 이후 MVC로 구현하며 추상화의 이유를 찾아가야 한다는 것이다. 또한 라이노 멘토님께 데이터 전달에 대한 피드백은 상태값 전달 방식은 await/async, closure를 사용하는게 좋다는 것이었다.
Commit, PR, 코드리뷰
코드리뷰
본인 작업에 집중한 나머지 다른 팀원의 코드를 명확하게 이해하고 넘어가지 못한 점이 아쉽다. 팀원들과 이에 대해 논의하며 2주 내에 MVP를 만들어내기 위해서는 감수하고 넘어가야 할 부분이라고 결론 내렸다. 다만 프로젝트 이후에는 반드시 팀원이 구현한 코드를 읽어야 한다.
PR
합동세미나에서는 컨벤션에 맞춰 PR을 상세하게 작성해야 했던 반면 앱잼 기간에는 컨벤션은 생각하지 않고 내가 구현한 컴포넌트를 다른 팀원이 어떻게 사용하는지 설명을 작성하는 식이었다. 이 방식이 작업에는 큰 문제가 없었으며 코드리뷰와 동일한 상황인 것 같다. PR 컨벤션을 어떻게 가져가야 할지 다른 개발자의 견해를 참고할 필요가 있어 보인다.
Commit
프로젝트 초기에 다른 팀원에 비해 Commit 단위가 매끄럽지 않음을 느꼈다. 파일을 생성할 땐 add, 간단 수정 때는 chore, 기능 단위를 하나 구현했을 땐 feat으로 Commit을 신경쓰면서 작업하며 부족한 점을 보완했다.
클라이언트 개발자 성장 단계
-
프로젝트 사이클을 경험해보니 iOS 개발자가 기술적으로 밟아야 하는 계단이 느껴졌다. 아래에 개인적으로 정의내린 단계에 따르면 2주간 2단계까지 경험했다고 봐야겠다.
- 컴포넌트, 레이아웃을 통한 UI 구현
- 함수, 데이터 전달
- API 연동, 동기/비동기 처리
- 프레임워크, 아키텍쳐에 대한 고민
- 영상 처리, 지도 등의 기술 구현
클라이언트 개발자의 소양
- 기능을 구현할 때 일일히 모두 짜는 방식보단 레퍼런스를 바탕으로 코드를 변형하는 능력을 길러야 한다.
- 많은 앱 사용 경험이 필요하다. 이건 기획자로서의 소양이기도 하다. 내가 안 쓰는 서비스도 많이 다운로드 받아 플로우, UI/UX 경험을 쌓아야 한다는 것을 배웠다.
- 탑다운 방식은 어려운 기술 스택을 학습할 때 좋다.
2. 협업
기획, 디자인 - 개발자 간의 소통
- 프로젝트를 시작하기 전 <기획-디자인과 소통을 잘 하기 위해서는 어떻게 해야할까?>에 대한 대답은 <타 파트가 이해하기 쉬운 단어로 설명한다>였다.
- 프로젝트를 경험 후 이전과 생각이 달라졌다. 개발을 모르는 기획-디자인에게 쉬운 단어로 설명은 하지만, 그 설명은 이해를 돕기 위한 설명이 아니라 왜 해당 기능의 구현이 불가능한지에 대한 거절, 조율이었던 것이다.
- 소통을 잘한다는 것은 대화가 원활하게 오가는 것이 아니라 간결하고 정확한 주장으로 상대를 설득하는 것이었다.
- 기획 파트는 개발을 알고 개발은 기획을 알아야 함이 우선이다. 기획은 MVP 단위에서 유저를 확보할 수 있는 서비스를 구상, 개발 지식을 바탕으로 정확한 프로젝트의 볼륨을 체크해서 각 파트의 개발 일정을 관리하는 사람이여야 한다고 생각한다.
- 개발 파트는 본인의 기술을 숙달하여 기획 파트가 구상한 아이디어를 프로덕트로 만들 줄 아는 실력을 갖춰야 한다. 때로는 기술적, 시간적 제한으로 인한 기획의 제안을 거절하기 위해 정확한 개발 지식을 근거로 설득하는 역량을 갖춰야 한다.
디자인 파트원과 불화
- 디자인 파트의 팀원이 본인의 포트폴리오를 위한 3D Asset 디자인에 리소스를 과도하게 투자했다. 그리고 Lottie를 사용하며 앱 실행 메모리 풋프린트가 커졌다.
- 그 결과 클라이언트 파트는 피그마의 레이아웃을 제공받지 못했고, 완성된 레이아웃도 제대로 된 플로우를 고려되지 않았다.
- 해당 팀원과 소통 방식이 불일치했지만, 인정할만한 개인의 역량에 대해 격려와 칭찬은 아끼지 않았다.
- 개인적인 감정이 협업에 영향이 가지 않기 위해 감정을 분리하려고 노력했다.
- 문제 상황이 발생해도 개발자 선에서 해결할 수 있는 문제는 자체적으로 해결했다. 하지만 그것보다 더 중대한 사안까지도 다른 구성원들은 갈등을 피하겠다는 명목으로 쉬쉬하고 넘어갔는데, 나는 정중하게 문제를 해결해달라고 요구했다.
내가 옳았음을 증명