중급 프로젝트 최종 팀회고

[miju-seaweed]

왜 회고를 해야 하나요?

바쁘고 치열하게, 또 잘 버티고 있는 스프린트 16기 여러분!
정신없이 프로젝트를 하다 보면 현재 우리 팀의 방향성과 목표를 잊어버리기 쉬워요.
매주 팀원들과 일주일을 회고하며 프로젝트를 위한 원동력이 되었으면 좋겠어요.

회고에 대한 궁금증

회고와 일기의 차이는 무엇인가요?

• 일기는 일상에서 있었던 일들을 의식의 흐름대로 편하게 적는 것이라면,
  회고는 함께 보고 듣고 경험한 사건과 현상들을 곱씹어 보고, 그중에 특히 되짚고 싶은 것들을 '왜' 와 '어떻게'에 집중해서 기록하는 것입니다.

회고 방법

회고는 “KPT 회고” 방식으로 진행해볼거예요. 아래 방법대로 회고해주시면 됩니다.

• 팀원들과 모여 그 주의 팀 프로젝트 활동을 돌아보며, '좋았던 점(Keep) / 아쉬웠던 점(Problem) / 시도해볼 것(Try)'으로 항목을 나누어 회고해주세요.
  • Keep : 현재 우리팀이 잘 하고 있어서 계속 유지하면 좋을 것 같은 부분
  • Problem : 현재 우리팀이 가지고 있는 문제
  • Try : Problem에 적은 것을 해결하기 위해 우리 팀이 다음에 시도해볼만한 것 (혹은 Keep 중에서도 더 개선하거나 시도해보고 싶은 것)
• KPT 회고 피그마 템플릿을 활용해서, 팀 회고를 진행하셔도 됩니다.
  • 단 템플릿 사용시, 팀별로 복제해서 사용해주세요. 꼭 템플릿을 사용하지 않아도 되니, 팀별로 편한 방식으로 회고를 진행해주세요.
• 이번주 일요일까지, 팀 회고한 내용을 정리하여 댓글로 올려주세요.
  (댓글에 예시 회고를 올려드릴테니, 참고해주세요. 피그마 템플릿으로 진행하셨다면 캡쳐본을 올려주셔도 돼요.)

참고글

• KPT 회고란 무엇인가?
• 팀문화의 탄생

[miju-seaweed]

🍀 0팀 (예시)

Keep

• 미팅 시간 약속을 모두 잘 지켜준다.
• 프로젝트 과정에서 기술 고민을 함께 하는 것이 서로의 학습에 도움이 된다.
• 새로운 제안을 했을 때, 모두 개방적으로 의견을 들어주어서 고맙다.
• 위워크에 모여서 하다보니, 프로젝트 진행이 빠르게 잘 이루어진다.

Problem

• 커밋 메시지가 명시적이지 않아서, 서로 어떤 작업을 했는지 파악하기 힘들었다.
• 급하게 코드를 작성하느라, 폴더 구조가 이상하다.
• 서로를 너무 배려하느라, 의견을 더 많이 나누지 못한다.

Try

• 협업을 위해, 커밋 메시지를 더 구체적으로 작성한다. (커밋 메시지 규칙 정하기)
• 폴더 구조를 다시 논의하여 폴더 구조 규칙을 만들고, 규칙에 맞추어 파일을 배치한다.
• 각자 하루에 한 번 이상 의견을 낸다.

[3rdflr]

✨1팀 KPT 회고

Keep

• 초반 요구사항 분석이 잘 이루어져서, 원활한 역활분배가 됐다
• 매일 코어타임을 이용해서 빠른 소통을 통해 이슈관리가 잘 되었다
• 미팅 참여율이 좋아서 진행사항을 파악하기 좋았다
• 각자 목표하는 바가 뚜렷해서, 토론을 통해 방향성을 정하기 좋았다
• 단순히 구현해야하는 목적이 아니라 더 나은 UI/UX를 고민해서 발전성있는 작업을 하는것 같아서 좋았다.
• 깃허브 이슈를 통해 회고 및 이슈 관리가 원활하게 나누어졌다
• 최소한의 커밋 단위 유지
• 유저 페르소나 기반의 심층 테스트 도입

Problem

• 초반에 비해 작업에 몰두하느라 코드리뷰에 대한 중요도가 떨어진것 같다.
• 브랜치 혹은 커밋메시지 관리가 아쉬운점이 있었다.
• 초반에 비해 기능구현에 집중하다보니 읽기 쉬운 코드를 작성하지 못한것 같다.

Try

• 철저한 코드 리뷰 문화 정착
• 일관된 브랜치 명명 규칙 확립
• 마일스톤 활용을 통한 명확한 시간 관리

[Sea0Soda]

7팀

Keep

• R&R이 팀원 개개인의 역량에 맞춰 잘 분배되고 있다.
• 코어타임은 여전히 잘 지켜지고 있다.
• Git과 브랜치에 익숙해져서 컨플릭을 다같이 잡거나 한 브랜치에서 여럿이 작업해 동시에 Push하는 등의 심화 기능을 사용하고 있다.

Problem

• 개발적인 R&R은 분배가 되었지만, 사회적인 R&R은 분배가 잘 이루어지지 못했다. 예를 들어 팀장의 자리에 맞는 역할이나, PM으로써의 역할 등의 R&R이 아쉬웠다.
• 문서화는 여전히 약간 부족한 느낌이 든다. 기억은 휘발되기 때문에 잘 기록을 해서 발표에 쓰거나 문서를 기반으로 멘토님에게 질문을 한다거나 하는 등의 응용이 가능하지만 이것이 부족했던 것 같다.
• 팀원들 스스로의 건강관리가 부족했다. 프로젝트 후반으로 가면서 마감은 다가오고 할 것은 많으니까 프로젝트에 매달리고 건강관리가 소홀해지면서 코어타임에도 빠지는 일이 팀원 가리지 않고 골고루 있었다.
• next.js 의 서버컴포넌트 활용을 못한게 아쉽다.
• Api 명세서를 한명이아닌 각자의 R&R에 맞게 각자 작성하는게 좋았을거같다.

Try

• 자신의 역할에 책임감을 갖고 이것을 짊어진 자신을 되돌아 보는 시간을 가졌으면 한다.
• 문서화의 시작으로 코드리뷰를 시도해보려고 한다. 다른 사람이 내 코드를 쉽게 읽기 위해 PR을 정성들여 쓰고, 다른 사람들이 정성들여 쓴 PR을 바탕으로 코드를 읽으며 이것에 대한 피드백을 주는 건설적인 과정을 건너뛰었던 것 같다.
• 코어타임에 프로젝트를 열심히 하고, 쉴 때는 열심히 쉬는 것이 건강관리의 시작이라고 생각한다. 중간중간에 쉬는시간도 가지고, 수다도 떨며 몸에 환기를 시키자.

[chowoowon0618]

6팀

keep

• 모두 열심히 해주셨다.
• 각자에 대해 포기 하지 않고 끝까지 해보려고 노력하였다.
• 의견 제시와 피드백을 아끼지 않았다.
• 서로 맡은 바를 끝내고 역할을 잘 분배해서 준비하였다.

Problem

• 작업 중에 내용 공유와 소통이 원활하지 않아 작업 진행이 제대로 이루어지지 않았던 것 같다.
• 초반에 비해 작업에 몰두하느라 코드 리뷰에 대한 중요도 가 떨어진 것 같다.

try

• 일정 공유와 계획에 대한 실행 여부, 또 지금 작업 현황을 자주 공유하기.
• 각자 하루에 한 번 이상 의견 내기.
• 코드 리뷰를 활발하게 하기.

[asksa1256]

3팀 최종 팀 회고

✅ Keep

• 최종 QA 전까지 예정된 작업을 마무리하여 QA를 차질 없이 진행하고, 수정 사항을 명확히 정리한 덕분에 높은 완성도로 마무리할 수 있었다.
• 모든 의사 결정에 팀원들이 적극적으로 참여하고 열린 마음으로 의견을 제시 및 수용했다.
• 중간중간 스몰 토크와 격려를 통해 긍정적인 팀 문화를 형성했다.
• 건설적인 코드 리뷰를 지속하며 성장할 수 있었고, 피드백을 자주 주고받으며 프로젝트 퀄리티를 높일 수 있었다.
• 기본 요구사항뿐만 아니라 디자인 디테일까지 신경 써 완성도를 높였고, 추가 기획이나 수정사항을 주도적으로 적용하면서 재미도 느꼈다.

⚠️ Problem

• 프로젝트 후반에는 마무리에 집중하느라 코드리뷰/회고 작성에 소홀해졌고, 데일리 회고도 지키지 못했다.
• 시간 분배가 어려워 예상보다 작업 시간이 초과되곤 했다.
• 코드 리팩토링에 충분한 시간을 할애하지 못했다.
• 작업 중 어려움을 제때 공유하지 못해 일이 커진 적도 있었다.
• 기능이 많은 페이지를 한 명에게만 분배하는 바람에 마감이 조금 늦어졌었다.

🔄 Try

• 마지막까지 페이스를 유지할 수 있도록 노력하고, 태스크를 더 세분화해 시간 분배를 개선해야겠다.
• 페이지별 세부 기능을 최소 2~3개는 파악한 후 역할을 분배해야겠다.
• 회고, 체크리스트, 일정 관리 등 개인 문서화 작업을 꾸준히 유지하고, 데일리 회고록 작성 습관을 이어가고 싶다.
• 회의나 이슈 상황에서 보다 명확한 의사 전달을 위해 비즈니스 커뮤니케이션 능력을 키워야겠다.
• 문제는 초기에 잡는 것이 중요하다는 점을 기억하며 빠른 공유와 대응을 실천해야겠다.

[llmojoll]

4팀

Keep

빠른 소통과 피드백

• 문제 발생 시 팀원들의 빠른 응답 덕분에 작업이 수월했음
• 코어타임과 그 외 시간에도 적극적으로 소통하며 빠른 피드백 가능

협업 분위기

• 어려운 부분에 대해 부담 없이 질문하고 도움을 주고받는 문화
• 기능 추가나 수정사항도 자발적으로 공유하고 반영

책임감 있는 참여

• 끝까지 포기하지 않고 맡은 역할을 충실히 수행
• 생각하지 못한 이슈를 발견할 수 있도록 모두가 적극적으로 참여

Problem

일정 및 계획 부족

• 이슈 대응이 느려 일정이 밀리는 경우 발생
• 일정에 쫓기다 보니 코드 퀄리티가 낮아지고, 추가 기능 구현이 어려웠음

코드 구조 문제

• 상태 관리 방식이 일관되지 않고 여러 라이브러리 사용으로 복잡해짐
• 로직 중복, 코드가 한 곳에 몰림 → 가독성과 재사용성 저하
• 조건문 처리 방식의 비효율성

협업 도구 활용 미흡

• Git Issue, PR 사용이 점점 줄어들고 여러 기능을 한 PR에 몰아서 관리 어려움

Try

설계 및 구조 개선

• 초반부터 전략과 설계를 세심하게 계획
• 코드 구조를 컴포넌트 단위로 분리해 재사용성과 가독성 강화
• 유연한 설계로 변화에 유연하게 대응

개인 역량 강화

• AI에 의존하기 전에 직접 디버깅하여 문제 해결력 향상
• 코드 작성 시 역할 분리와 명확한 구조 의식

협업 방식 개선

• 진행 중인 작업에 대한 대화와 기록을 지속적으로 유지
• 깃 이슈 및 PR 활용을 일관성 있게 유지

[jirene0]

KEEP

문제 해결을 명확히 공유하여 모두가 인지하고 순조롭게 진행됨
공통 컴포넌트 작성 시 재사용성을 고려하고, 사용법 설명도 잘 정리됨

PROBLEM

중간 점검과 배포가 프로젝트 후반에 이루어져 리팩토링 및 수정 시간 부족
커스텀 훅과 유틸 함수 공유가 부족해 활용이 어려웠음

TRY

페이지와 컴포넌트를 더 쉽고 활용도 높게 개발하고 싶음
공통 코드 사용 시 간단한 설명 시간 마련 필요
렌더링 방식, 인증 개념 등은 사전 정리 및 피드백 후 코딩 시작 필요

[Heedong0924]

2팀 팀회고

Keep

• 저번주와 비교해 이슈가 생겼을 때, 구체적인 에러 라인이나 이슈 시나리오 재현 등을 구체화해주셔서 좋았음
• 코어타임 준수, 커뮤니케이션 등 적극적인 참여율이 좋았음
• 모두 힘내서 데드라인 직전까지 완성하기로 한 것을 완료하여 끝낸 것 (다크모드까지)
• 예상치 못한 에러나 트러블 발생 시 원인을 빠르게 분석하고 해결한 뒤, 팀과 공유하면서 문서화하려고 노력함
• 프로젝트에서 이슈 발생시 다같이 의논하며 트러블슈팅을 진행하는 점이 좋았음
• 라이브러리를 선정 기준에 맞춰서 효율적으로 사용한 점이 좋았음

Problem

• 요구사항 중 필수 기능인 드래그 앤 드랍 또한 개발 중후반에 만들어진 시스템 내에 구축하기가 어려워서 결국 포기하게 되었는데 이 부분도 많이 아쉬움이 남음
• 테마를 나중에 추가해서, 전체적인 수정사항이 많았음 (초반 테마 기능을 고려하지 않은 설계와 디자인)
• 프로젝트 끝에 갑자기 터진 문제을 해결만 하고 어떤문제인지 찾지 못 한 점 (구체적인 원인 파악과 재발 방지가 미흡)
• 비교적 높은 러닝커브에 의해 팀원의 도움에 의존적이었던 부분들이 많아서 아쉬웠음
• 되돌아보니 기술적으로 의미 있는 시도가 많았음에도 그 가치를 내부 평가시 스스로 과소평가했던 부분이 있었다고 느낌
• 유저 인증과 관리에서 미들웨어를 사용해보고 싶었는데 프로젝트가 어느 정도 완성된 상황에서 추가하려고 하니 어려움이 많았음

Try

• 서비스 전반적으로 영향을 끼치는 기능은 개발 초기에 시스템을 구축하여 디자인하는 것이 낫겠음
• 타입 정의와 사용에 있어서 팀 단위로 의논하고 보다 자세하게 정의해서 유지보수성을 높이는 시도를 해보고 싶음
• 차후에라도 시간을 내어 문제 발생의 원인을 구체화 시키고 트러블 슈팅을 마무리 짓고 싶음
• 단순 구현에 그치지 않고, 사용하는 기술에 대한 깊이 있는 이해를 바탕으로 설계와 적용까지 고려하는 개발을 지향하고 싶음