프로젝트 중간 회고

KPT 회고 방식

Keep (프로젝트에서 만족했고, 앞으로의 업무에서 지속하고 싶은 부분)

• 기술
• recoil을 통한 상태관리와 라우팅 적용에 대해 많이 알게된 것 같다. 특히 라우팅 같은 경우는 spa환경에서 새로고침 시 화면을 유지할 수 있고, param 값을 통해 상태관리를 대체되는 부분이 있어서 앞으로도 의미있게 사용할 수 있는 나의 기술 스펙이 된 것 같다.

• 협업
• 먼저 깃허브를 깊게 다루어볼 수 있어서 좋았다. 이슈와 PR을 통한 리뷰를 통해 협업에 대하여 깊게 경험할 수 있었고, Rebase라는 기능도 마스터했다고 할 수 있을 것 같다. 물론 아직 사용해보지 못한 부분이 많이 남았지만, 앞으로 다른 프로젝트에서도 깃허브를 자신있게 사용할 수 있을 것 같다.

• 기술
• 상태관리에 recoil을 처음 적용해보았다. 먼저 이해를 하고 진행을 하니 더욱 효율적으로 사용할 수 있는 것 같아 좋았다. 리액트도 사용은 해봤지만, 제대로 알고 사용한 적이 없었다고 생각이 들 정도로 많은 것을 알고, 눈에 많이 보이게 되었다. 제일 늘었다고 생각했던 점은 오류를 해결하는 시간이 상당히 많이 줄었다는 것이다.
• commit 단위나 issue 단위를 어떻게 하면 좀 더 쪼개고 신경쓸 수 있을지 고민하고 더욱 반영해보아야겠다고 생각했다.

• 협업
• 협업을 이렇게 처음부터 많은 것을 기획하고, 프로젝트를 진행해본것은 처음이였다. 처음 git flow는 지연님의 도움 덕에 손쉽게 이해할 수 있었지만, 충돌이 일어나는 부분은 생각치 못해서 애를 먹었다. 같이 충돌 해결에 대해 고민하고 rebase를 공부해서 잘 해결했던 것 같다.
• 팀원을 너무 잘 만난 것 같다. 힘들었던 부분이나 맡아야될 부분들을 너무 잘 나누고, 부족한 부분 피드백 바로바로 되며 반영하니까 너무 좋았고, 이게 팀 프로젝트였구나를 깨닫게 되었다.
 

• 기술
• 이번 프로젝트 덕분에 emotion styled 처음 사용해보면서 스타일링에 대한 감을 조금씩 잡고 있는 기분이다. css가 젤 어렵다.
• 독립적으로 마이페이지 위주로 개발을 하다보니 메인페이지에 대한 도메인 지식이 부족한 기분이다. 그래도 덕분에 앞으로 사용자 관련 페이지를 개발하는 업무가 주어지면 금방 만들 수 있을 것 같다.

• 협업
• 첫 프론트엔드 협업이라 많은 어려움이 있었다. 일단 메인페이지 디자인이 계속 바뀌고 여기에 맞추기 위해서 개발을 하다보니 이부분에서 시간을 많이 쓴 것 같다. 기능은 별게 없었는데 css 부분이 많은 시간을 소모하고 있는 기분이다. → 현업에서도 계속 디자인 요구사항이 바뀌고 기능 요구사항도 개발 도중에 바뀌는 일이 많을텐데 미리 경험해보는 좋은 시간이였다. 앞으로 독립적으로 페이지를 구현 할때는 앞단에서 넘어오는 데이터가 있으니 서로 소통을 충분히 하고 개발을 시작해야겠다고 느끼게 되었다.
 
• git에 대해서 혼자서 개발할때는 정말 간단한 기능들만 사용했는데 협업을 하면서 git에 대해서 자신감이 생긴 것 같다. 협업하다가 어떤 충돌이와도 해결할 수 있을 것 같다.

• 기술
• 처음으로 recoil을 사용해 보았는데 redux보다는 러닝 커브가 낮아 적용하기 수월했던 것 같다. 앞으로 간단한 프로젝트는 recoil을 통해서 개발해볼 수 있을 것 같다.

• 협업
• 깃을 사용해 어떤 단위로 issue를 쪼개면 더 좋을 지, pr은 어떻게 작성하면 좋을 지를 깨달을 수 있었다.
• git-flow를 적용해보았는데 협업의 흐름을 대략적으로 익힐 수 있는 시간이었다. rebase 또한 처음에는 충돌이 많이 일어나 걱정도 되었지만 점차 충돌이 발생하지 않고 안정화가 되었다. 이 프로젝트를 통해 rebase 기능을 마스터해본 경험이 가장 기억에 남을 것 같다.

• 기술
• 컴포넌트를 어떻게 구성해야 하는지, 라우팅 처리를 어떻게 해야 올바른 지 등.. 정말 다방면으로 많이 배운 느낌이다.
• 상태관리를 위한 리코일에 대해 공부하면서 상태관리의 중요성을 깨우칠 수 있었다.
• postman을 통해 api를 뜯어보기도 하며, 내가 담당했던 회원 가입을 구현하기 위해 formik이나 yup을 처음 경험해보고, 유저 리스트 출력 및 검색 기능을 구현하기 위해 삽질하면서 열심히 구글링하며 공부했다. 역시 하고자 하는 마음만 있으면 어떻게든 해낸다는 것을 또 한 번 깨닫게 되었다.

• 협업
• 다들 코어타임을 철저히 지키기도 하고 서로를 충분히 이해하고자 했기 때문에 큰 트러블이 없이 지금까지 진행된 것 같다. 협업에서는 주어진 시간 내에 다함께 참여하는 커뮤니케이션이 매우 중요한 것 같다는 생각을 했다.
• 깃 담당자(?)가 되어 git-flow를 파고 들며 공부해보기도 하고 팀원들에게 알려주면서 git을 통한 협업에 대해서는 이제 공포증이 사라진 것 같다. 이 경험을 토대로 앞으로 진행될 프로젝트에서는 조금 더 능숙할 수 있을 것 같다.

Problem (프로젝트에서 부정적인 요소로 작용했거나 아쉬웠던 점)

• 기술
• 컴포넌트 단위로 개발하며 붙이는 방식이 생각하기 어렵고 에러가 예상하지 못한 부분에서 계속 발생하여서 고전했던 것 같다. 좋아요 같은 경우 4가지 방법으로 접근하여 사용할 수 있도록 만들어야 했는데 각 접근 방식마다 가지고 있는 자원(상태값)이 달라서 이것을 적절하게 사용해야 했다. 이런 부분을 미리 파악하여 상태관리 구조나 해결법을 구상했다고 좋았을 것 같다

• 협업
• 초기세팅부터 개발을 하면서 까지 여러가지로 정하고 맞춰나가야하는 부분이 정말 많다는 것을 알 수 있었다. 개발이 조금 늦게 시작될지언정 정하고 맞춰둘 수 있는 부분은 최대한 해두고 개발을 시작하는 것이 추후에 더 좋은 방법이 될 수 있겠다는 생각을 했다

• 기술
• 설계의 중요성과 어려움을 알게되었다. 처음 설계를 진행할때, 머리속에 있던것을 글로 옮기는 것 조차 구체화에 시간이 많이 걸리고 상당히 어려웠다. 그리고, 계속 진행하면서 프로젝트가 계속 발전하며 설계가 계속바뀔수도 있는 것이 상당히 아쉬우면서 배운게 많았던 점이다.
• 타입스크립트로 바꿔보려 했지만 시간적으로 많이 부족할 것 같아 아쉽다. 끝나고라도 마이그레이션 한 번 해보면 좋겠다!

• 협업
• 같은 레포지토리를 다섯명이서 사용하면서 소통의 중요성을 알게 되었다. 내가 아무 생각 없이 한 행동이 수 많은 충돌을 만들 수 있고, 다시 한번 생각해보니 그 사람이 엄청 힘들어질수도 있겠구나 라는 것을 알게되었다. 협업에서 어떤 동작을 같이 쓰는 곳에다가 할때는 많은 고민과 배려를 해야겠다고 생각했다.

• 기술
• 타입스크립트 미적용 , 처음에 리스크때문에 자바스크립트로 진행을 하고 타입스크립트로 리펙토링을 하면 되겠지? 라는 생각으로 자바스크립트로 하자고 했었는데 막상 생각대로 일정이 안따라주는 것 같아서 타입스크립트로 마이그레이션을 못한게 아쉽다.
지금 생각해보면 처음부터 타입스크립트를 적용하는게 좋았을지도 모르겠다는 생각이 든다.

• 협업
• 커뮤니케이션에 대한 문제 , 중간에 오프라인 회의도 기침때문에 못가고 뭔가 놓친게 많이 있어서 커뮤니케이션 부분에서 문제가 발생했었다. 현업에서 왜 커뮤니케이션 중요성을 강조하는지 몸으로 느낄 수 있는 시간이였다.

• 기술
• 리팩토링 부분이 아쉬웠다. 서로가 맡은 파트에 대한 코드에 대한 이해도가 낮았던 점이 원인으로 작용하지 않았나 싶다.
• 처음에는 자바스크립트로 빠르게 개발한 후에 타입스크립트로 변환할 계획이었지만 시간이 부족해 타입스크립트를 적용하지 못한 것이 아쉽다.

• 협업
• 처음에 프로젝트를 기획할 때, 코드 컨벤션 등 세세한 부분까지 서로의 코드 스타일을 맞추는 과정이 필요하다고 생각해 코드의 일관성을 지키는 것이 좋다고 생각했다.
• 어떻게 일을 분배하면 좋을지 아직 잘 모르겠다. 우선 순위에 따라 기능을 분배하면 좋을지 페이지 별로 분배하면 좋을 지 아직 어떤 방법이 좋은지 깨닫지 못해 아쉽다.

• 기술
• api를 수정할 수 없었기에 한정적으로 진행되어야 했던 유저 목록 출력 및 검색 기능이 많이 아쉽다.
• 1월 15일에 오프팀과 진행한 중간 리뷰를 통해 초기 세팅(폴더 구조나 린트 설정, import 방식 등)에 조금 더 집중했으면 좋았을 것 같다는 생각을 했다.

• 협업
• 팀 회의를 통해 무언가를 결정해야 할 때, 모두의 의견을 충분히 듣고 결정할 시간이 짧았던 것 같다. 팀원들 모두가 참여하는 서비스이기 때문에.. 이런 토의 시간을 조금 더 확보해도 좋을 것이라는 생각을 했다.

Try (Problem에 대한 해결 방식으로 다음 프로젝트에서 시도해볼 점)

• 기술
• 먼저 현재단계에서 구현되지는 않았지만, useHooks의 형태로 상태를 관리하도록 교체할 예정이다. 이렇게 하면 컴포넌트 단위로 상태를 관리하는 것이 좋아지고, 코드의 분리 또한 이루어지기 때문에 더 좋은 코드를 짰다고 할 수 있을 것 같다.

• 협업
• 한번 문제되는 부분을 경험하였으니, 다름 프로젝트에서는 미리 정하고 맟춰야할 부분을 더 세심하게 할 수 있을 것 같다. 물론 아직도 부족한 것이 많지만 이런 경험들이 쌓이고 있다는 것이 의미있는 것이 아닐까?

• 기술
• 프로젝트의 구조를 바꿔보려할 때 많은 고민을 해보구 적용시켜보려 한다. 이번에 다른 팀들 코드를 보며 많이 배워서 많은 것을 적용시켜보려고 한다.
• 타입스크립트로 사이드 프로젝트라도 하나 처음부터 해보려고 한다. 좋은 기회이며 발전에 많은 도움이 될 것 같다.

• 협업
• 어떤 작업을 할 때, 좀 더 구체적으로 분리를 하거나 작업 분배를 해보려고 한다. 이렇게 하면 이슈 단위도 더 작아질 수 있고, 서비스로 나뉘는 작업들을 할 때 많은 도움이 될 것 같다.
• 티켓화를 좀 더 시켜 내가 하고 있는것, 칸반보드를 활용해 팀원들이 하고 있는 것을 시각화 해보면 좋을 것 같다.

• 기술
• 다음 프로젝트에서는 컴포넌트 구조를 처음부터 맡아서 만들어보고 싶다. 현재 우리 프로젝트도 좋은 구조를 가지고 있지만 어제 오프팀이랑 피드백을 나누고 보니 좀더 주도적으로 컴포넌트 구조를 맡아서 해보고 싶은 마음이 생겼다.

• 협업
• 프로젝트 역할을 나누어도 좀더 충분히 논의를하고 프로젝트를 시작해야겠다.

• 기술
• 미리 기획 단계에서 어떤 기능을 구현해야 할지 세세하게 문서화를 해야 함을 느꼈다.
• pr 과정에서 코드 리뷰를 제대로 진행하지 못한 것이 아쉬웠다. 급하게 기능 구현을 하기 보다 기능 구현을 한 후 리팩토링까지 충분히 한 다음 코드 리뷰를 주고 받았으면 좋았겠다는 생각이 들었다.

• 협업
• 이슈 단위를 좀 더 쪼개야 할 것 같다는 생각이 들었다. 한 사람이 많은 이슈를 가져가면 상황 공유도 어렵다고 느꼈다. 이는 프로젝트를 하면서 팀원들과의 많은 교류로 해결할 수 있을 것 같다.
• 이번 프로젝트에서는 트렐로나 Jira를 사용하지 않고 시간이 남는 팀원이 남은 일감을 가져가는 방식으로 진행했는데, 일의 작업 순서나 방향을 잡기 힘들었던 것 같았다. 앞으로는 일의 작업 순서, 방향을 시각화하는 것이 좋을 듯 싶다.

• 기술
• 프로젝트 초기 세팅 때, 조금 더 공들여보고 싶다. 우리팀의 경우에는 성현님이 대표로 초기 세팅을 맡아 주셨는데, 이 부분에서 다같이 공부하고 확실하게 다양한 부분을 결정해보고 싶다.

• 협업
• 충분한 토의 시간을 두고, 모두의 의견을 반영한 제대로 된 결정을 진행하고 싶고, 회의나 스크럼 시, 대화를 이끌어 나갈 때는 조금 더 차분하게 진행하고자 한다.