HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
🐣
프론트엔드 데브코스 4기 교육생/
이동근팀
이동근팀/
🦆
SNS 팀 프로젝트/
팀 회고
팀 회고
팀 회고
팀 회고

팀 회고

2023. 09. 15 중간 회고

📢
AAR 회고 (After Action Review/Report) A (초기 목표) - 의도한 결과는 무엇이었나요? A (현실) - 실제로 어떤 일들이 일어났나요? R (배운점들, 목적) - 지속 및 개선할 점은 무엇인가요? 또 포기할 것들은 무엇인가요?

🐻‍❄️남궁호수

Expect

  • 처음 사용하는 tanstack-query로 프로젝트 기능구현 하는 목표를 가졌다.
  • 기존에 사용해보았던 tailwind가 아닌 chakra 새로운 라이브러리를 이용하여 디자인을 구현하는 목표를 가졌다.
  • 아이디어 회의 후, 맡은 기능 구현을 목표기한내에 구현할 수 있는 목표를 가졌다.
 

Actually occur

  • tankstack-query를 통해, 맡은 기능 구현의 api 요청에 성공하였다.
  • 처음에는 어려움이 조금 있었지만 chakra와 같은 새로운 툴 이용에 대해 익숙해질 수 있었다.
  • 맡은 기능 구현을 순차적으로 실현해 나갈 수 있었다.
 

Review/Report

  • 공식문서를 우선적으로 학습해나가야 함을 알게 되었다. 자신이 알고 있는 것과 모르는 것을 구별하여 새로운 것을 배우는데 걸리는 시간에 대한 감각을 익혀야 함을 알 수 있었다.
  • 다양한 css 속성 표기법에 대해 알 수 있었고, 공식문서 읽는 법에 익숙해질 수 있었다. 빠르게 필요한 내용만 찾는 법.
  • 기한에 맞춰 끝내기보다는 기한내로 미리 기능 구현을 끝낼 수 있도록 해야함을 알 수 있었다. 팀원들과 지속적인 상의를 통해 끊임없이 프로젝트를 진행하는데 있어 개선점을 찾아나가고 적용해 나갈 수 있었다.
 

🐯 박주연

Expect

  • 한달이라는 기간 내에 너무 욕심내지 않고 머-쓱레터에 필요한 기본 요구사항 완성하는 것이 최종 목표였습니다.
  • 아이디어 및 실현가능성과 관련된 의견들은 적극적으로 팀원들에게 여쭤보고 피드백 받으려 했습니다.
  • 처음 써보는 기술스택인 Chakra UI, Tanstack query, react-hook-form를 이해하면서 사용하는 것이 또다른 목표였습니다.

Actually occur

  • 사용자 검색, 슬랙 알림 등을 구현할 때 실현가능성과 사용자 친화적인 UI를 고려해 팀원들에게 피드백을 받았습니다.
  • 목표로 했던 기본 요구사항 구현이 순조롭게 진행되고 있는 것 같습니다.
  • Chakra 라이브러리르 사용하면서 아코디언 ui, card ui 같은 컴포넌트들을 쉽게 구현할 수 있었고 아직 100%이해했다고 확실하게 말할 수 없지만 react query, react-hook-form을 실제로 활용했다.
 

Review/Report

  • lodash를 사용해 보는 것도 프로젝트 시작하면서 목표로 있었지만 아직까지 사용하지 않았고 리팩토링 과정을 거치면서 lodash를 적극적으로 사용해보고싶습니다.
  • 아무래도 chakra UI를 사용하기 있기 때문에 emotion을 추가로 사용하는 것은 포기하려 합니다.
  • 남은 기간 동안 슬랙 알림 기능 및 QA기간을 거치면서 react-query, react-hook-form을 3차팀에서도 활용할 수 있도록 더 공부해서 확실하게 이해하려 합니다.
 

🐰 신호원

Expect

  • 프로젝트 요구 사항을 충족 시키면서 기간 내에 완성할 수 있도록 기본에 일단 충실하기.
  • 흔한 게시판 형식 SNS와는 차별점을 가진 프로젝트 만들어보기.
  • tanstack query처럼 유용하지만 사용해보지 못한 툴을 써보기.
 

Actually occur

  • 와이어 프레임이나 페이지 디자인 등 다양한 의견이 필요한 사항은 팀원이 모두 참여해서 결정하고, 개발은 요소 별로 나누어 각자 개발해서 진행 속도를 높일 수 있었다.
  • 디자인이 초반에 구체적으로 정해지니 개발 중에 블로킹되는 상황이 적었다.
  • 사용자 타겟을 타 팀보다 좁고 구체적으로 정하면서 슬랙 알림 기능을 고려할 수 있었다.
 

Review/Report

  • 기본 기능은 문제없을 것으로 예상되어서 추가 기능을 고려해봐도 좋을 것 같다.
  • 브랜치 전략같은 걸 수정 불가의 법칙으로 생각하지 않고 우리 상황에 맞춰 변형해도 괜찮았던 것처럼 생산성을 최우선 목표로 하기.
  • 기본 기능이라 해서 우겨넣을 필요는 없을 것 같았다. 더 완성도 있는 서비스가 되기 위해선 어떤 게 필요할 지 고민하기.
 

🐻 이상훈

Expect

  • 처음에는 한 달 내에 아이디어 기획, UI 설계, 유저 스토리로부터 떠오르는 세부 기능 설계, 실제 구현, 그리고 발표와 정리 및 QA 까지 진행해야 한다는 것을 고려해서 한정된 일정 안에 완성할 수 있는 것에 초점을 맞췄었다.
  • 혹여나 결과물이 기대에 미치지 못할 수 있을지라도 함께 개발하면서 태스크를 적절하게 분할해서 개발한다거나, 코드 리뷰를 통해서 지식을 공유하기도 하고 통합 브랜치에 머지하는 과정을 진행해보면서 현업에서 마주치게 될 상황들을 미리 경험해보는 것에 주안점을 뒀었다.
 

Actually occur

  • 실제로 개발 과정을 진행해보니 우리 모두가 맡은 파트에 대해서 열심히 진행해서 인지 생각보다 빠르게 기능을 구현할 수 있었다. 그래서 추가 기능으로 고려하고 있었던 슬랙 DM 알림 기능도 시도해볼 수 있었다.
  • Chakra UI는 처음 사용해본 기술 스택이었는데 디자인 시스템에서 레이아웃에 대한 UI를 어떤 방식으로 제공하는지를 경험하게 된 계기가 되었다.
  • Tanstack Query는 예전에 했었던 프로젝트에서 도입해본 기술이었는데, 이번에 재사용성이나, 변화에 대한 위해서 custom hook으로 묶는다거나, 쿼리 키 관리를 손쉽게 하기 위해서 query key factory를 사용한다거나 하는 시도를 했다. 또한 오랜만에 공식 문서를 다시 살펴보기도 하고 이해한 부분에 대해서 팀원과 공유하는 과정을 통해서는 더 깊고 견고하게 기술을 이해할 수 있게 되었다.
  • 폼 데이터를 쉽게 다루기 위한 react-hook-form이나, 유효성 검사는 위한 zod 라이브러리를 학습하고 실제로 적용해보는 계기가 되었다.
 

Review/Report

  • 프로젝트의 환경설정을 하면서 Eslint, Prettier, Husky 등 협업하면서 코딩 스타일이나 컨벤션에 대한 규칙을 정하는 방법을 알게 되었다. 또한, 슬랙 알림 기능을 구현하는 방식을 고민하다가 결국 본인 인증과 관련한 문제 때문에 간단한 서버가 필요하다고 판단이 되었는데, 이 덕분에 오랜만에 node.js로 환경 설정이나 배포하는 방법을 다시 학습하는 계기가 되었다.
  • 우선 우리 팀에서 기획한 기능을 정상적으로 작동하도록 구현하는 것이 최우선 과제라고 생각한다. 그리고 아이디어가 흥미롭기도 하고 데브코스 과정에서 지속적으로 사용할 수 있을만한 서비스라고 생각되어서 API 서버가 닫히더라도 꾸준히 사용할 수 있도록 간단한 API 서버의 기능에 대한 작업을 추가적으로 해야할 것 같은데… 추후에 Next.js 를 학습하면서 진행해볼지, 혹은 FE 개발자로 취업을 준비하는 입장으로서 너무 욕심인 부분일지는 고민이 된다..
 

🐨 우현지

Expect

  • 주어진 기한 내에 디테일한 기능까지 구현하는 것보다 기본적인 기능을 구현하고 나중에 추가기능을 생각해보는 방향으로 프로젝트를 진행한다.
  • tanstack query를 새로 배우면서 이해하면서 프로젝트에 적용한다.

Actually occur

  • 프로젝트를 기획하면서 디테일한 부분까지 생각할려고 하다보면 그것을 구현할 수 있을까라는 고민부터 시작하면서 시간에 쫓긴다는 압박을 받게된다. 디테일한 부분까지 완벽하게 구현할려고 생각하지 않고 기본적인 기능에 초점을 두고 프로젝트를 시작하니 부담감도 적어지고 시간적 여유가 생기면서 추가기능구현에 대해서 생각도 하게 되었다.
  • 프로젝트를 진행하면서 새로운 라이브러리인 tanstack query를 배우게 되면서 프로젝트 기한 내에 적용을 할려고 하니 일정에 대해서 고민을 하게 되었고 더 빨리 적용을 하기 위해서 필요한 부분에 대해서만 더 집중을 하게되어 효율적으로 새로운 기술에 대해서 배우고 익히게 되었다.

Review/Report

  • 완벽을 목적으로 기획을 할려고 한다면 끝이 나지 않고 오히려 100% 완벽하게 구현을 할 수 없다는 것을 깨닫게 되었다. 오히려 기본기능에 집중을 하게 되면 오히려 부담감도 적어지고 시간적 여유가 생기면서 추가기능에 대해서 생각을 할 수 있게되면서 그렇게 더 나은 과정으로 나아간다는 것을 깨닫게 되었다.
  • 새로운 기술을 배우면서 프로젝트를 구현한다는것이 처음에는 자신이 없고 기한내에 잘 할 수 있을까 걱정이 되었지만 프로젝트를 같이 진행하는 팀원들과 공유하고 질문을 통해서 배우는 과정에서 더 많이 배울 수 있다는 점을 깨닫게 되었다. 코드리뷰와 질문을 통해서 코드 스타일도 더 느끼게 되고 팀원들은 어떻게 적용을 하였는지에 대해서 바로바로 알 수 있어서 새로운 기술을 이해하는 시작점이 빨랐던것 같다.
 

2023. 09. 27 최종 회고

📢
KPT 회고 (Keep, Problem, Try) K (Keep) - 현재 만족하고 있는 부분이나 계속 이어나갔으면 하는 부분이 있나요? P (Problem) - 불편하게 느껴지는 부분이나 개선이 필요하다고 생각되는 부분이 있나요? T (Try) - 앞으로 새롭게 시도해보고 싶은 내용이나, 현재의 문제를 개선하기 위한 방법이 있을까요?

🐻‍❄️남궁호수

Keep

  • 길지 않은 코드로 PR을 자주 올림으로써, 팀원간의 맡은 기능구현사항 공유
  • 팀원들간 공유하면 좋을 정보들의 공통 문서화
  • 프로그래머스 교육생들을 위한 '머쓱래터' 서비스 장기화와 기능 개선
 

🐯 박주연

Problem

  • 메인페이지에서 최근 Post 목록이 없다는 점에서, 최근 Post와 메세지 개수 순서대로 Post. ( 머쓱이 정렬기준 )
  • 그 외 리팩토링 정리내용
  • 프로젝트 리팩토링을 위한 팀원들간의 일정 협의
 

Try

  • 머쓱이 상세페이지 react hook form 사용하여 리팩토링
  • 메인페이지 ‘최근순’ , ‘메세지 개수 순’ 정렬 기준 추가
  • 머쓱이 생성페이지 Suspense 로딩 적용
  • lighthouse를 통한 페이지 성능 측정
 

Keep

  • 기본요구사항 MVP를 먼저 구현해보고 시간이 남으면 추가기능을 넣어보자는 계획이 잘 지켜진 것 같다.
  • 막히는 부분이 있다면 팀원에게 도움을 구하는 문화가 잘 이루어진 것 같다.
  • 피드백을 누구에게 받을 수 있을지 생각하던 중 가장 가까운 데브코스 교육생들을 타켓으로 잡은 점이 매우 좋았다. 피드백 접근성에 대해서도 따로 생각할 수 있는 계기가 되어 좋았다.
 

Problem

  • 프로젝트 내에서 소통이 조금 부족한 느낌이 들었다. 이 부분을 개선하기 위해서는 팀장을 따로 정하지 않고 리팩토링 기간에는 스크럼 마스터를 돌아가면서 해보는 문화도 좋을 것 같다.
  • chakra ui를 쓰다보니 팀끼리 공통 컴포넌트를 회의하고 빼내는 연습과정이 없었던 것 같아 아쉬웠다. 이를 개선하기 위해서는 현재 프로젝트에서 공통적인 부분에 대한 리팩토링 과정이 필요하다고 생각했다.
  • 문서화가 좀 부족했던 것 같다. 3차팀에서는 따로 기획서, 브랜치, 컨벤션, 팀 규칙, 기술스택 등등을 보드로 각각 문서화해보면 좋을 것 같다.
 

Try

  • 이름으로 사용자를 검색해서 편지를 보낼 수 있도록 구현 했었는데 회원가입과정에서 본인인증 없이 이름을 자유롭게 만들 수 있다보니 사용자를 찾는 과정이 어려울 수 있다는 생각이 들음. 이 문제를 개선하기 위해서 회원가입 과정에서 본인인증을 넣어 실명을 가져올 수 있게 하거나 사용자의 이름 말고도 머쓱이의 제목을 가지고 검색할 수 있도록 추가로 기능 구현을 해야함.
  • 장식들을 단순히 클릭해서 붙이는 것 뿐만 아니라 Drag&Drop 할 수 있게 해주는 기능을 추가로 넣으면 좋을 것 같다.
 

🐰 신호원

Keep

  • 팀의 의사 결정을 질질 끌지 않고 일단 해보는 방향으로 결정하여 빠르게 서비스를 구현할 수 있었다.
  • 과제를 해결한다기보다 실제 사용될 서비스를 만든다는 마음가짐으로 개발하여 서비스 목적에 맞는 기능 만을 넣을 수 있었다.
  • QA 시간을 따로 할당할 수 있는 여유가 생겨서 더 완성도 있는 상태로 배포할 수 있었다.
 

Problem

  • 생각보다 적은 사용률. 피드백을 주고 받는 상황 자체가 자율적으로는 만들어지기 어려운 것 같다. 당장 우리 팀도 안썼다. 완성도를 높여서 진짜로 데브코스에 채택이 되거나 더 접근 허들을 낮출 필요가 있어보인다.
  • 성능 최적화. 이미지를 많이 사용하는 만큼 로딩이 느린 것 같다. 이미지 스프라이트나 해상도 분기가 필요할 수도 있어 보인다.
 

Try

  • 원래의 목적에 맞는 진짜 익명 댓글 API를 만들어보는 것도 좋을 것 같다.
  • 커스터마이징 강화. 현재는 옵션이 적어 다른 사람과의 차별점을 주기 어려운 것 같다.
  • 목록을 더 효과적으로 보여줄 방법 고민해보는 것도 좋을 것 같다.
 

🐻 이상훈

Keep

  • 개발하면서 마주하는 이슈를 공유하면서 해결책을 찾기도 하고, 기술에 대해서 알고 있는 지식을 서로 공유하면서 말로 구체화하는 경험은 잘 했다고 생각한다.
  • 자연스럽게 팀원 각자의 강점을 잘 살리는 방향으로 프로젝트가 진행된 것 같다.
  • 계획한 서비스를 위한 핵심 기능만 구현하기로 기능을 많이 줄였기에 모노레포를 구성해보거나 서버를 배포해보는 등 새로운 시도와 학습을 할 수 있었다.
 

Problem

  • 아이디어가 꽤 재미있고 실제로 사용해볼 가능성이 있다는 점에서 서비스를 꾸준히 개선하고 리팩토링해나가고 싶은데 이제 팀도 바뀌고 모두들 최종 프로젝트나 다른 학습으로 바빠질 수도 있다보니 계획을 어떻게 잡아야할지 고민이다.
  • 앞으로 서비스를 개선하면서 피드백을 반영하기도 하고 기능을 추가하기도 할텐데 어떻게 의사결정을 할지 고민이다.
 

Try

  • 평소에는 비동기 커뮤니케이션을 중점으로 진행하되, 일주일에 한 번 정도 회의 시간을 잡는 방법도 있겠다.
  • 각 기능에 대한 추가 여부를 투표로 결정하는 방법도 있겠다.
 

🐨 우현지

Keep

  • QA를 통해서 프로젝트내의 버그를 잡는과정이 있어서 더 완성도 있는 프로젝트를 만들수 있었다.
  • 프로젝트를 진행하다가 겪는 이슈에 대해서 공유하고 같이 고민을 하는 과정을 통해서 빠르게 이슈를 해결할 수 있었다.
  • 실제 사용자가 있는 서비스를 기획하고 구현해서 사용자에게 피드백을 받을 수 있었다.
 

Problem

  • 생각보다 사용자 수가 적고 서비스가 활발하지 못한점이 아쉽다.
  • 피드백을 받고 꾸준히 개발을 하고 싶지만 팀이 바뀌고 계속 고민을 할수 없는 환경적인 요인이 아쉽다.
 
 

Try

  • 일주일에 한번 정도 같이 프로젝트를 개선하는 방안을 고민하는 시간을 가지는게 좋을것 같다.
  • 실제 사용자의 수를 늘리기 위해서 기술적으로 개선할 부분을 고민을 해야겠다.