😎 KPT
중간회고는 KPT(Keep Problem Try)를 따릅니다 → [KPT회고란 무엇인가?]
KPT회고는 다양한 회고 방법 중의 하나로, Keep, Problem, Try 세 부분으로 나눠서 짧은 시간 동안 구성원의 생각을 공유하고, 즉시 실행 가능한 Action을 도출할 수 있도록 도와줍니다.
1월 5일부터 1월 15일까지 이뤄진 1차 개발 기간을 마치고 팀원들간 중간회고를 기록하였습니다.
🤝 Keep
현재 만족하고 있고, 프로젝트 종료까지 계속 이어져 갔으면 좋겠는 부분에 대해서 나누고자 합니다.
민우
- 중요한 것은 꺾이지 않는 협업
- 사소한 이슈까지 서로 공유하고 기능구현도 서로 상의를 해서 진행하다보니 아직까지 큰 틀의 변화는 없는것 같다. 의사소통면에서 작은 이슈가 있었지만..
- 팀원들이 있어서 든든해요😆
- 우리팀의 규칙은 작업시 디스코드 채널에 들어와있는 것이었는데, 새벽 늦게까지 팀원들이 등대처럼 빛을 내주어서 좀더 힘을 낼 수 있었다.
- 늘 새로워~
- 이번에 맡은 기능구현은 해보지 않았던 기능이 많았다. 덕분에 간단한 문제도 오랜 시간이 걸렸지만 결국 해결하고 뿌듯함을 느꼈던 것 같다.
- 중간발표 전에 다른팀과 프로젝트 리뷰를 했었는데 놓치고 있었던것과 알지 못했던 라이브러리들을 구경하는 좋은 기회가 되었다.
승준
- 코드 리뷰
- 팀원들이 잘못된 점을 잘 짚어주어서 많은 것을 개선할 수 있었다. 동시에 나도 리뷰를 하면서 참고 자료를 많이 찾아보게 되었는데 이 과정에서 애매했던 지식을 조금 더 구체화할 수 있었다.
- 문서화
- 팀원들이 이미 너무 잘해주고 있어서 미안할 정도다. 나중에 프로젝트가 끝나고 나서 참고하기에 정말 좋을 것 같다. 그리고 다른 프로젝트를 하더라도 이번 프로젝트에서 협업 방식, 로직, 기술 등 많은 것을 참고하게 될 것 같다.
충일
- 새로운 기능 담당
- 기존에 맡아보지 않았던 채팅 기능을 하게 되어서 너무 좋았다. 앞으로도 새로운 기능을 계속 하고 싶다.
- 팀원들과의 협업
- 디스코드에 들어와있는 팀원들을 보면서 으쌰으쌰하는 기운을 얻게 된다. 보이지않는 유대감도 많이 생긴 것 같다. 늦게까지 작업하고 있는 팀원들을 보면 “더 해줘” (훈훈한 분위기 멈춰)
유리
- 기록
- 개인적으로는 맡은 부분을 개발하면서 마주한 이슈와 진행 과정을 글과 사진으로 남겨놓은 점이 좋았습니다. PR도 형식에 맞춰 작성하다보니 문서화가 잘 되었습니다.
- 다른 프로젝트를 하면서 리드미와 위키, 노션 페이지에 과정을 체계적으로 정리하지 못한 게 아쉬웠었는데, 빅토리아 프로젝트에서는 팀원들 모두 꾸준히 기록에 기여해준 덕분에 잘 정리되고 있는 것 같습니다. 멋진 팀원들 덕분에 행복하다!!
- 협업
- 혼자 아이디어를 구상할 때는 잘 정리가 안 되었는데 피그잼을 활용한 기획 과정에서 여러 질문을 통해 생각을 공유하고 비교할 수 있었습니다. 일단 시작부터 즐거웠습니다!
- 디스코드에서 함께 이야기할 수 있는 분위기가 조성되어 좀 더 편하게 의견을 말할 수 있게 되면서 더 애정을 가지고 프로젝트에 임하게 됐습니다.
- 코드리뷰를 하면서 몰랐던 걸 새로 알거나 놓쳤던 부분을 바로잡을 수 있어서 좋았습니다. 특히 리액트 훅 규칙이나 가독성 좋은 코드를 작성하는 방법을 배울 수 있었습니다.
- 기술
- 어떻게 하면 프로젝트에 좀 더 효율적이고 도움이 되는 방향으로 진행할 수 있을지에 대해 고민하고 여러 방법을 시도해보는 팀원들 각자의 노력 덕분에 더 몰입할 수 있었습니다.
- 일찍이 배포를 시도해보고 여러 이슈에 대처해보면서 배포 과정에 대한 우려를 줄일 수 있었습니다. 팀원 분들이 적극적으로 진행해주셔서 감사했습니다!
- 리액트 훅을 활용해본 경험이 많이 없었는데 CRUD를 전반적으로 구현해보고 토큰에 따라 UI를 변경하는 등 세부적인 케이스까지 생각해볼 수 있었습니다.
미현
- 기능 구현의 목록들을 하나씩 제거해 나가기까지
- 리액트부터 타입스크립트까지 이번 데브코스 과정에서 처음 배우는 것들이라, 제대로 구현에 적용할 수 있을 지 확신할 수 없었으나, 최대한 목록으로 정리하고 하나씩 체크해나가면서 1차 개발기간을 보낸 거 같습니다.
- 혼자하는 게 아니었네~
- 각자 페이지별로 기능 분담을 하고, 구현을 하지만 디스코드에서 매일 스크럼과 이슈 회의를 진행하면서 서로 돕는 관계에 있었다는 걸 느낄 수 있었습니다. 프로젝트 진행할 때 발생한 이슈들에 대해서 나눌 수 있다는 것은 참으로 좋은 것 같습니다.
👏 Problem
팀 프로젝트를 진행하는데 있어서 개인적으로 아쉬움이 남았던 부분에 대해서 나누고자 합니다.
민우
- 그래서 맨데이가 뭔데…
- 기획 초기단계에서 팀원들과 맨데이를 설정을 했고, 결론부터 말하면 지키지 못했다. 생각한 시간보다 훨씬 많은 시간이 드는 과정도 있었고 부족한것이 많다고 느껴서 맨데이를 훌쩍 넘겨버린것 같다.
- 소통은 정말정말 중요하다😅
- 팀원과의 회의를 마치고 기능구현을 진행했는데 이게 웬걸… 팀원과 기능구현 파트가 겹치고 말았다. 서로 이상함을 감지했는지 짧은 회의를 통해 분담을 다시했다. 다행히 많은 작업을 해놓은 상태가 아니었고 빠르게 알아차려서 작업이 늦어지진 않은것 같다.
승준
- 원리 이해 부족
- React에서 가끔은 이게 왜 렌더링이 2, 3번 더 되는지 파악하는데 너무 오래 걸릴 때가 있고 이유를 알지 못할 때도 있었다. 배포를 진행할 때에는 http, https 등 네트워크에 대한 이해도가 부족하여 정확한 원인은 파악하지 못한 체 그냥 구글링을 통해, 혹은 여러가지 방법을 노가다성으로 시도하여 반쪽짜리 해결을 하였다. 프로젝트가 끝나고 나면 2 ~ 3주간의 시간 동안 부족한 점들(네트워크, React, TypeScript, Git)을 채우려고 노력해야겠다.
- 디자인
- 디자인을 확고히 정하지 못하고 진행하다보니 mui에 많이 의존했다. 생산 속도가 빨라지고 스타일 관련 코드량이 줄어든 반면 이 프로젝트만의 색깔을 보여주기에는 다소 부족함이 존재한다고 느꼈다. 어느 정도 기능 구현이 끝나면 전체적으로 스타일링을 해야할 것 같은데 워낙 의존한 부분이 많다보니 쉽지 않을 것 같다.
충일
- 시간 분배
- 평소에도 프로젝트를 여러 개 병행하지만 이번 데브코스 프로젝트에서는 병목 현상이 좀 심한 것 같다. 왜냐하면 다른 몇 프로젝트들도 기한, 데드라인이 다 비슷했다. 데브코스 프로젝트는 이번주 금요일까지고 다른 프로젝트는 이번주 목요일, 또 다른 건 이번주 수요일… 겹친 마감일이 문제였다. 마감일이 겹치면 다음부터 주의해야겠다.
- 복잡한 로직 아키텍처
- 복잡한 로직에 대해 최대한 신경쓰고 진행하려 했는데, 지식이 얕아서 한계가 보였다. 아키텍처에 대해 중요성을 깨달았고, 리팩토링에 대해서도 중요성을 다시 한번 깨달을 수 있었다. 복잡한 로직에 대해 설계 능력을 더 키워야겠다고 생각했다.
유리
- 세부 사항에 대한 논의 부족
- 주제와 와이어프레임을 빠르게 결정한 것은 좋았지만 좀 더 구체적인 컨셉과 디자인을 정하지 못하고 기능 개발을 이어간 점이 아쉽습니다.
- 구체적인 유저 스토리를 정의하지 않아 개발하는 과정에서 생각치 못한 예외 케이스를 처리하는 데 시간이 꽤 들었던 것 같습니다.
- 짧은 개발 기간
- 프로젝트 기간이 짧아 기한에 쫓기면서 하다보니 코드의 질이나 최적화에 대해 고민하고 반영해볼 시간이 부족하다고 느꼈습니다.
- 조바심을 느끼면서도 생각보다 기능 구현이 오래 걸려서 사전에 정한 MD보다 시간을 더 투자하게 되는 것 같습니다. 타입스크립트와 리액트를 다루는 게 아직 서툴어서 사소한 이슈에도 해결하는 데 시간이 오래 걸렸습니다..!
미현
- 지켜지지 않는 맨데이
- 분담한 일에 대해서 잘 마무리하고, 더 좋은 기능들을 도입해보려는 시도 때문에 맨데이를 초과해서 일정을 진행했던 거 같습니다. 좀 더 지혜롭게 일정을 관리하고, 건강과 프로젝트 모두 챙길 수 있는 방법은 없을 지…
- 능숙하지 않은 기술스택
- 머릿속에서 생각하는 기능을 구현하기 위해 여러 구글 검색과 공식 문서를 보는 시간이 생각보다 많았는데, 결국에는 가장 단순하게 기교를 부리지 않고, 주제에 맞게(?) 짜려고 노력했던 것 같습니다. 좀 더 기술을 다루는 방식이 능숙했으면 이번 프로젝트를 더 신나게 했을 것 같다는 아쉬움이 남습니다. 더 공부해야겠네요🙂
💪 Try
각자 나눴던 아쉬움을 어떻게 해결할 수 있을 지 당장 실행가능한 행동들에 대해서 나눠봅니다. 다음 회고때 얼만큼 개선되었는 지 비교해보는 것도 좋을 것 같습니다.
민우
- 이 작업 왜이렇게 오래걸렸지?
- 물론 집중을 못했을 수도 있다. 하지만 그와는 별개로 정말 많은시간이 걸렸던 기능구현도 있었다. 알고나면 쉽게 해결 가능했던 문제도 많았는데 저번 노션 프로젝트에서 고쳐야 할 점을 아직도 못고친것같다. 항상 머리로 기억하기보단 내가 겪은 문제를 어딘가에는 작성해 두자!
- 코드가 너무 복잡해
- 기능구현에만 몰두하고 코드를 작성하다보니 나중에 내가 작성한 코드를 봤을때 너무 복잡해서 이해하는데 오래걸렸다… 그래도 “내가 왜 이렇게 작성했지?”라는 생각이 든것은 오히려 다행이라고 생각한다. 지금은 시간이 남을때마다 내가 작성한 코드를 리팩터링 하고있다.
- 배움에 두려움 없이
- typescript를 도입해서 프로젝트를 진행하고 있는데, 처음에는 내가 잘 쓸수 있을까? 라는 두려움이 들었고 대부분의 시간을 타입에러때문에 소요한것같다. 하지만 문서를 찾아보며 이를 해결하는 과정에서 어느정도 익숙해지고 처음의 두려움은 사라졌다. 앞으로도 새로운 기술을 사용할때 두려움 없이 공부하는 법을 배운것 같다.
승준
- 이해하고 사용하자.
- React든 TypeScript든 이번에 구현하면서 당연하지만 내가 아직 많은 것을 이해하지 못하고 있다는 것을 깨달았다. 시간 없다고 대강 땜빵식으로 메꾸려고 하니 오히려 시간이 더 걸리는 듯 하다. 이후 생길지도 모르는 에러를 막기 위해 그 때 그 때마다 조금 더 심도 있게 생각하면서 코드를 작성해야겠다.
- 리팩터링
- 겹치는 부분이 많은 것 같다. 중복되지 않게 사용할 수 있도록 리팩터링이 필요하다고 생각한다.
충일
- 적절한 시간 분배
- 태평하게 자지말고 잠을 조금 더 줄여서 시간을 더 투자하려고 한다. 맡은 기능에 대해서는 다 구현하고, 팀원들이 올린 PR에 대해서는 더 적극적으로 코드 리뷰를 통해 생각을 공유하자!
- 프로젝트 구조 이해
- 프로젝트 전체적인 구조를 한번 살펴보고 더 나은 설계나 방향성이 있는지 고려해보려고 한다.
유리
- 세부 사항에 대한 논의와 리팩토링
- 디자인, 리팩토링 등 현재 계획해놓은 일정대로 하나씩 하다보면 멋지게 완성할 수 있을 것 같습니다! 파이팅
- 기술적인 고민을 좀 더 하자
- 기능 구현 중 최적화나 불필요한 렌더링을 줄일 수 있는 방법, 타입스크립트 사용, 배포 등에 대해 깊게 생각하지 않고 눈에 보이는 것에만 집중했는데 좀 더 깊게 파고드는 경험을 해야겠습니다(다른 팀원분들처럼요!).
미현
- 일단 적자!
- 구현 목록을 더 상세히 적어야겠습니다. 생각지 못한 예외처리 부분들에 대해서도 더 깊은 고민이 있어야 할 것 같아요.
- 기능 구현, 이슈 발생한 것들에 대해서 기록을 남기면 좋을 것 같습니다.
- 새로 배운 기술 목록들도요. 이슈 해결 사례나 기술 목록들을 잘 정리해서 공유해보는 것도 좋겠다는 생각이 듭니다:)