😎 KPT
최종회고는 KPT(Keep Problem Try)를 따릅니다 → [KPT회고란 무엇인가?]
KPT회고는 다양한 회고 방법 중의 하나로, Keep, Problem, Try 세 부분으로 나눠서 짧은 시간 동안 구성원의 생각을 공유하고, 즉시 실행 가능한 Action을 도출할 수 있도록 도와줍니다.
1월 5일(목)부터 1월 20일(금)까지 이뤄진 전체 개발 기간을 마치고 팀원들간 최종회고를 기록하였습니다.
🤝 Keep
현재 만족하고 있고, 앞으로 계속 이어져 갔으면 좋겠는 부분에 대해서 나누고자 합니다.
민우
- 중간 발표 이후에 추가적인 기능 구현보다는 코드를 이해하기 쉽게 리팩터링 하는 과정을 거쳤다
- 내가 사용한 기술과 그 기술을 사용한 이유에 대해서 간략하게 메모해두었다. 이를 통해서 나중에 ‘왜 내가 이 코드를썼을까?’ 라는 질문에 대답할 수 있을것 같다.
승준
- 나중에 리팩토링하자라는 생각보다 시간이 적으니까 최대한 지금 생각할 수 있는 좋은 코드를 적자는 마인드로 개발했다.
- 무언가를 도입하려고 하면 최대한 공식 문서랑 영어로 된 아티클을 읽으려고 노력했다.
- 다른 팀원의 코드를 이해하려고 하면서 간접적으로 코드를 작성하는 경험을 할 수 있었다.
충일
- 리팩터링을 통해 프로젝트에 많이 기여할 수 있어서 좋았다.
- 조그마한 발전이라도 계속해서 이어가면 더 좋을 것 같다.
유리
1. 태스크 관리가 잘 되었다.
태스크가 크게 밀리지 않고 계획대로 잘 진행되었던 것 같다. 디자인이 정해지지 않은 상태에서 기능 구현을 우선시했던 것이 이번 프로젝트에서는 효과적이었고 짧은 시간 동안 스타일링에 집중할 수 있어서 좋았다.
2. 즐거운 분위기에서 프로젝트를 마무리할 수 있었다.
중간 회고에서 MD대로 하지 못했다고 했는데 계획한 기능을 구현하기 위해서는 어쩔 수 없었던 것 같고 밤 늦게까지 함께 디스코드에서 할 일 하면서 이야기했던 게 추억이 될 것 같다. 내가 해놓은 것들이 정말 미흡했지만 팀원들이 격려해주고 피드백 남겨줘서 지치지 않았다.
3. git/github 협업 경험을 제대로 해봤다.
이슈 생성 - 브랜치 생성 - 작업 - PR 제출하는 과정의 중요성을 알았고, fork해서 작업을 한 덕분에 실수를 하더라도 그렇게 치명적이지는 않았다. 실수로 main에 직접 커밋을 남기고 푸시했었지만 fork한 내 레포지토리의 main 브랜치라서 원본 팀 레포지토리의 main를 직접 건들지 않아 다행이었다.. 이번처럼 함께 작업하는 사람이 많을 경우에는 fork해서 하는 게 맞는 것 같다. 그 필요성을 제대로 느낌!
미현
- 1차 개발 기간 때, 구현 목표를 어느 정도 달성한 상태였기 때문에 구현 중반부터는 리팩토링이나, 더 좋은 효율을 내기 위한 기술 적용에 집중할 수 있었습니다.
- 2차 개발 기간에서는 1차 회고에서 다짐을 했었던, 구현 과정을 기록하는 일에 더 신경을 쓸 수 있었습니다. 기능 구현에 대한 목표와, 과정에 대해서 기록을 했고, 새로 습득한 기술에 대해서 정리해볼 수 있어서 좋았습니다.
👏 Problem
팀 프로젝트를 진행하는데 있어서 개인적으로 아쉬움이 남았던 부분에 대해서 나누고자 합니다.
민우
- 시간 배분 문제 중간 발표 이후에도 이부분은 고쳐지지 않았다.🥲 완벽한 일정계산은 어렵지만, 프로젝트 마감일이 가까워 질수록 더 많은 시간이 투자 되었던 것 같다.
- 계속되는 유효성 체크 회원가입 페이지의 유효성을 체크하는 과정에서 아마도 ‘이정도면 되겠지’라는 안일한 생각을 한것 같다. 사용자가 해당 사이트를 이용할때 가장 먼저 하는것은 회원가입일 것이다. 그만큼 간단하면서도 중요한 일이지만 회원가입 페이지의 유효성 검사에 대해서 많은 피드백을 받았다. 물론 피드백 받으면서 수정하는 것이 나쁘다고는 할 수 없지만 처음부터 사용자의 입장에서 생각해 보았다면 더 좋았을 것 같다.
- 코드리뷰 마감일이 다가올 수록 양질의 코드리뷰를 할 수 없었다. 이는 결국 오류를 발생한 경우도 있었고 개발 시간을 더 오래 걸리게하는 요인이 되었던것 같다. 아무리 바쁘더라도 팀원의 코드의 흐름을 잘 보고 피드백을 주었으면 좋았을 것 같다.
승준
- 무언가를 구현하려 할 때 일단 코딩하고 보는 습관이 가끔 일을 더 복잡하게 만들 때가 있었다. 비동기 체인이 계속 이어지거나 조금 복잡한 로직을 구현할 때 아예 구조를 바꿔야 할 때가 생겨 개발 시간이 길어지곤 했다. 그리고 과연 확장 가능한 코드일까라는 불안감이 들곤 했다.
- TypeScript를 어느 정도 안다는 인식을 가진 채로 진행하지 못한 것 같다. 이 역시 불안감을 주는 요소지 않았나 싶다.
- 비교적 시간이 남았음에도 불구하고 약간의 귀찮음으로 인해 마지막에 건설적인 업무를 진행하지 않은 것 같다. 성능 최적화에 도전해보면 좋지 않았나 싶다.
충일
- 아직 채팅 기능을 완벽하게 구현하지 못했다. 비즈니스 로직에 대해 더 깊게 고민해보지 못한 탓이다.
- 지금 프로젝트 아키텍처가 최선일까라는 의문점이 있다. 지금도 전혀 문제는 없지만 더 개선할 수 있을 것 같은 욕심이 생겼다.
유리
1. 기술적인 고민과 여유 부족
- 내가 담당한 기능과 관련된 기술적인 고민거리들을 직접 떠올리거나 고민을 바탕으로 개선하지 못한 점이 아쉬웠다.
충일님이 대대적으로 리팩토링을 해주셨는데 useNavigate와 useLocation을 이용해서 state에 데이터를 저장하고 불러오는 방법, font-display 속성 적용하기, 로딩 변수를 적절히 활용하는 방법 등 최적화하는 방법을 많이 배울 수 있었다.
- 구현한 코드의 결과를 완벽하게 예측하지 못하고 꼼꼼하게 예외 처리를 하지 않아서 테스트할 때마다 에러가 발생했다. 태스크를 쳐내는 것 자체에 집중하다보니 디테일을 놓쳤던 것 같다.
- 상태 관리 라이브러리를 좀 더 적극적으로 초반 단계에서부터 적용했다면 API 호출 횟수를 줄이고 중복 코드를 줄일 수 있었을 것 같다.
2. 다소 효율적이지 못한 업무 처리
- 발표 자료와 영상을 만드는 마무리 단계에서 효율적으로 빠르게 일을 해내지 못했다. 사소한 것에 신경쓸 시간에 좀 더 기능을 꼼꼼하게 점검했다면 배포 이후에 발생한 버그를 미리 방지할 수 있지 않았을까..
- 작업 단위를 다소 크게 잡아서 PR 단위가 커졌고 코드리뷰에 대한 부담을 높였다.
3. 기술적인 역량 부족
- 타입스크립트, 리액트를 쓰면서 기본적인 원리도 놓치며 구현했었다. 팀원들의 코드 리뷰나 버그 덕분에 뒤늦게 실수를 발견했었고, 타입 에러 때문에 시간이 오래 걸렸다.
- (다른 팀 회고를 읽은 후 내용 추가) 좋아요 디바운싱 처리, 이미지 업로드 시 이미지 크기 제한, 이미지 압축, 스켈레톤 처리, 게시글 캐싱, 텍스트 에디터 활용, 폼 리렌더링 방지 등 내가 담당한 기능들을 구현하는 과정에서 기술적인 챌린지를 할 만한 부분들이 많았다. 신중하지 않게 중요한 핵심 기능들을 맡아 다른 팀원들의 기회를 뺏어버린 것 같다는 생각이 들고 안일하게 개발을 진행한 것처럼 보여 마음이 무겁고 죄책감이 크다. 개선점을 정리하고 책임져야겠다. 독단적으로 진행하지 말고 팀원에게 조언을 구하고 정중하게 부탁하자.
미현
- 예외처리의 부분을 많이 생각하지 못한 것 같습니다. 일례로, API호출에 대해 좀 더 세분화해서 에러 핸들링을 할 수 있지 않았을까 하는 아쉬움이 있고, 구현 중반 이후부터는 유효성 검사와 해당 로직을 분리하는 과정들을 생각했었는데, 그럼에도 불구하고 아쉬움이 많이 남습니다.
- 주어진 시간에 비해 기술적 역량이 부족했구나 느낍니다. 어느 프로젝트에서든 개인적인 아쉬움은 있겠지만, 데드라인이라는 부담감이 있어서 여유 있게 임하지 못했다는 생각이 듭니다. 그러다 보니 너무 나의 구현에만 집중되어 있어서 다른 팀원들의 코드를 충분히 보지 못했었고, 코드리뷰에 많은 시간을 투자하지 못한 거 같아 아쉽습니다.
- 여전히 맨데이는 지켜지지 않았어요…🥲
💪 Try
각자 나눴던 아쉬움을 어떻게 해결할 수 있을 지 당장 실행가능한 행동들에 대해서 나눠봅니다. 다음 회고때 얼만큼 개선되었는 지 비교해보는 것도 좋을 것 같습니다.
민우
- 다른 팀의 프로젝트를 보고 각종 유효성을 검사할 수 있는 라이브러리가 존재하는 것을 처음 알았다. 물론 검색해보면 나오겠지만 나는 검색할 시도조차 안했다라는 뜻인것 같다. 물론 유효성 검사를 직접 구현해서 사용한 것은 내 실력 향상에 도움을 준 것 같다.
- 한가지 기능구현을 완벽하게 구현하는것은 물론 좋지만 너무 이런저런 상황을 모두 고려하다 보니 일정이 밀릴 수도 있다고 생각했다. 다음에는 모든일에 우선순위를 두고 미리 해당 기능에서 고려해야하는 사항을 적어두고 진행하면 개발속도를 높일 수 있을 것같다.
승준
- 코딩부터 하고 보자는 마인드도 좋지만, 조금은 처음에 시간을 두고 전체 그림을 보면서 개발하는 습관을 가져야겠다. 재활용 가능하고 확장 가능한 코드를 짜려는 생각을 미리 해야겠다는 생각이 든다.
- TypeScript를 아예 모른다는 생각으로, 백지라는 생각으로 다시 공부해야겠다.
- 성능 최적화 방법들을 찾아보고 다음 프로젝트에서는 적용해봐야겠다.
충일
- 꾸준히 공부한다.
- 복잡한 로직 다루는 것을 피하지않는다.
유리
- 기술적인 고민과 여유 부족
- 맡은 기능과 관련된 레퍼런스를 미리 많이 찾아보고 분석해보자.
- 구현한 기능에 대해 다른 사람들에게 조언과 피드백을 구해야겠다.
- 시간이 좀 더 걸리더라도 구현하는 기능에 대해 기술적으로 좀 더 고민하고 차분하고 신중하게 접근해야겠다. 지금 당장은 시간이 더 걸리는 것 같지만 생각보다 많이 걸리지 않을 수 있고 앞으로의 어려움이나 개발 시간을 줄일 수도 있다.
- 업무 처리의 효율성 높이기
- 태스크의 우선순위와 가용 시간을 파악해서 중요한 것에 우선 집중하자..!
- 태스크를 잘게 쪼개어 차근차근 해나가야겠다.
- 기술적인 역량 부족
- 타입스크립트와 리액트 등 이번 프로젝트에서 부족하다고 느낀 점을 채워나가자. 기본이 중요하다.
미현
- 팀프로젝트와 관련해서는
- 우선순위 명확히!
- 맨데이의 여유를 두고, 다른 팀원의 코드를 살피는 시간 강제적으로 확보하기
지금 해야할 일의 목표를 명확히하고, 전체 일정과 나의 해야할 목록의 우선순위를 정하는 것이 중요하구나 느꼈어요,
- 개인적인 면에서는
- 꾸준히 성장하고, 공부하는 것이 답인 듯 싶습니다.