중급 프로젝트 1주차 팀회고

[miju-seaweed]

왜 회고를 해야 하나요?

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

회고에 대한 궁금증

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

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

회고 방법

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

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

참고글

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

[miju-seaweed]

🍀 0팀 (예시)

Keep

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

Problem

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

Try

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

[Sea0Soda]

🍀 7팀 KPT 회고

Keep (잘했던 점)

• 코어타임을 활용해서 문제가 발생했을 때 팀원들과 실시간으로 소통하며 빠르게 해결할 수 있었습니다
• 팀원들이 서로에게 진심으로 관심을 가지고 집중해주었고, 서로 동기부여를 해주면서 함께 성장할 수 있었어요
• 자유로운 분위기에서 의견을 나눌 수 있었고, 문제 상황을 공유하면 즉시 피드백을 받을 수 있어서 좋았습니다

Problem (아쉬웠던 점)

• GPT에 지나치게 의존하는 경향이 있었던 것 같아요
• 개발 순서를 제대로 정하지 않아서 같은 코드를 여러 번 작성해야 하는 비효율이 발생했습니다
• 중요한 내용들을 문서로 정리하지 못한 점이 아쉬워요
• PR을 너무 큰 단위로 올려서 리뷰하기 어려웠던 것 같습니다

Try (앞으로 시도해볼 점)

• 코어타임에 서로의 코드를 살펴보고 리뷰하는 시간을 정기적으로 가져보면 어떨까요
• 중요하고 필요한 부분들은 꼼꼼히 문서화해서 팀 지식을 축적해보겠습니다
• PR은 가능한 한 작은 단위로 나누어서 올리도록 하겠어요
• 남은 프로젝트 기간 동안 다양한 시행착오를 통해 많이 배우고 성장했으면 좋겠습니다!

[asksa1256]

3팀 1주차 KPT 회고

✅ Keep (잘 된 점)

원활한 커뮤니케이션, 적극적인 참여와 빠른 의사결정

• 코어타임뿐 아니라 그 외 시간에도 소통이 활발하게 이루어졌고, PR 중심으로 협업하면서 빠른 피드백이 가능했습니다.
• github issues에 개인별 담당 작업을 등록해놓음으로써 협업이 효율적으로 진행되고 있습니다.
• 적극적으로 의견을 제시하는 분위기라서 의사결정이 빠르고 명확한 편입니다.
• 회고를 꾸준히 작성하면서 좋은 회고 습관을 만들어가고 있는 것 같습니다.
• 코드 리뷰 속도를 유연하게 조절하면서 코드 퀄리티를 개선하고, 서로의 지식과 노하우를 공유할 수 있었습니다.
• 기획이나 성능 개선의 의견도 반영해서 프로젝트를 주도적으로 개발하고 있는 것 같습니다.

❗ Problem (아쉬웠던 점)

일정 관리, PR 분할의 어려움

• 개인 일정으로 인해 시간 투자가 어려운 경우가 있었고, 목표 작업량을 중간 점검까지 달성하지 못한 경우도 있었습니다.
• 명세 외의 예외 상황까지 처리하려다 보니 작업 속도가 느려져서 기본 요구사항 구현이 지연되는 일이 있었습니다.
• 기술적 어려움이나 불확실한 기준으로 작업을 세분화하다가 진행 속도가 저하된 경우가 있었습니다.
• 공용 컴포넌트나 유틸 함수는 잘게 나눠 PR을 올렸지만, 페이지 작업은 PR 단위를 잘 분할하지 못한 점이 아쉬웠습니다.

🔄 Try (개선할 점)

기본 요구사항 우선 구현, 작업 속도 체크

• 리팩토링이나 예외 처리는 이후로 미루고, 마감 기한을 지키기 위해 기본 요구사항 구현을 우선하는 전략이 필요합니다.
• 하루 이상 소요되는 작업은 팀과 공유해 논의하고, 각 태스크의 우선순위를 명확히 하여 일정 지연을 방지해야 합니다.
• 회고는 개발 일정에 영향을 주지 않도록 요약 메모 후, 일정이 끝난 뒤에 정리하는 방식으로 효율을 높여야 할 것 같습니다.
• 페이지 작업 시에도 처음부터 세분화된 이슈를 생성해 PR을 나누는 방식이 필요합니다.

[chowoowon0618]

🍀 6팀 KPT 회고

( Keep : 잘 된 점 )
새로운 기술 스택 관련 제안 시 팀원들이 수용해줘서 고맙다
시간을 많이 사용하여 참여하신다
계획대로 포인트 작업을 하려고 노력함, 계획 외에 변경사항에 유연하고 빠르게 적응함

( Problem : 아쉬웠던 점 )
서로 어떤 작업이 끝났는지 제대로 소통이 안된다
잘 모이지 못한다 , 중간에 기술스택 변경으로 작업이 조금 늦어짐

( Try : 개선할 점 )
많은 소통을 통해 서로 힘든부분이나 작업량을 공유하면 좋겠다
팀미팅에 잘 참여하도록 노력한다
최대한 나눈 포인트를 잘 끝내고, 상황 공유를 데일리 스크럽에 이야기, 최대한 당일 작업 사항은 당일 push하기

[llmojoll]

4팀

Keep (잘한 점)

코어 타임 운영

• 코어 타임에 전원이 잘 참여하여 활발한 의견 교류와 이슈 해결이 가능했습니다.
• 디스코드 등 실시간 커뮤니케이션을 통해 빠르게 피드백을 주고받을 수 있었습니다.

효율적인 코드 리뷰 문화

• 리뷰어를 미리 지정하여 리뷰 진행 속도를 높일 수 있었습니다.
• PR에 상세한 주석과 설명을 남겨 코드 의도를 명확히 전달할 수 있었습니다.

좋은 팀 분위기와 소통

• 팀 분위기가 좋아 어려운 점도 자유롭게 공유할 수 있었습니다.
• 기술 스택과 방향성을 초반에 논의함으로써 프로젝트 전략 수립이 용이했습니다.

Problem (아쉬운 점)

작업 속도 및 기술 역량

• 개인적인 작업 속도가 느려 팀 전체 진행 속도에 영향을 준 점이 아쉬웠습니다.
• 기술적인 개념 부족으로 인해 비효율적인 로직 작성과 시간 소모가 있었습니다.
• 코드 리뷰 시 더 나은 피드백을 주고 싶었으나, 여유나 실력 부족으로 아쉬움을 느꼈습니다.

설계 및 코드 구조

• 공통 컴포넌트 설계 시 리렌더링 최적화나 추상화 등을 충분히 고려하지 못해 리팩토링 시간이 필요했습니다.
• PR을 세분화하지 못해 리뷰어가 코드를 읽기 어려웠을 수 있습니다.

개발 환경 및 설정 문제

• Node/npm 버전이 팀원 간 달라 오류가 발생했습니다.
• 최신 버전 패키지 사용 시 기존 도구들과의 호환성을 충분히 고려하지 못해 문제가 생겼습니다.
• CI 단계에서 빌드 테스트가 누락되어 빌드되지 않는 코드가 병합된 경우가 있었습니다.

Try (개선하고 싶은 점)

기술 역량 및 피드백 능력 향상

• 기술적으로 어려운 부분은 멘토님께 적극적으로 질문하는 연습을 하겠습니다.
• 코드 리뷰 시 팀원들의 코드를 더 잘 이해하고, 도움이 되는 피드백을 드릴 수 있도록 노력하겠습니다.

문서화 및 기록 정리

• 트러블슈팅 DB를 노션 등에 정리하여 문제 해결 과정과 지식을 문서화하고 공유하겠습니다.

작업 및 설계 전략 강화

• PR은 가능한 한 작게 나누어 리뷰가 수월하도록 하겠습니다.
• 다음 프로젝트에서는 사소한 부분까지 전략적으로 계획하고 실행하겠습니다.
• 컴포넌트 분리도와 재사용성을 고려하여 유지보수하기 쉬운 구조를 만들겠습니다.

환경 설정 관리

• 패키지 선택 시 기존 시스템과의 호환성을 반드시 확인하겠습니다.
• CI 파이프라인에 빌드 테스트를 강제하여 안정적인 코드만 병합되도록 하겠습니다.

Learned (배운 점)

• 코어 타임을 통해 팀원 간 실시간 소통과 이슈 해결이 매우 효과적이라는 점을 느꼈습니다.
• 공통 컴포넌트 설계 시 단순 구현을 넘어서 추상화, 리렌더링 등 다양한 관점을 고려해야 한다는 점을 배웠습니다.

[jirene0]

Keep (잘한 점)

• 초기에 역할분배가 원할하게 이루어져서 , 개발 시작을 빠르게 할 수 있었고, 계획에 지장없이 흘러갔다.
• 의사소통이 코어 타임 외에도 활발하게 이루어졌고, PR 중심으로 협업하면서 빠른 피드백이 가능했다
• Zep을 활용하여 코어 타임동안 소통을 자유롭게 할 수 있어서 좋았다.
• 매일마다 코어타임을 함께해서 좋았다

Problem (아쉬운 점)

• 초기에 세팅의 세부적인 것들이 정해지지 않아서 프로젝트 진행 중에 소통이 원할하지 못했다.
• 모르는 것에 대해 너무 주눅이 들어 자신의 입장을 분명하게 끝맺지 못하는 부분들이 아쉬웠다.
• 서로 어느 부분을 작업하는지 시각적으로 알 수 없어 아쉬운 부분이 있었다.
• 개발단계에서 계획보다 지연되는 부분이 아쉬웠다.
• 어떤 부분을 작업했는지 / PR에서 이해가 안되는 점/ 주요 기능 등등 개발시 팀원들과 공유하는 시간을 가져야 할 거 같다.
• API를 다루거나 토큰을 다루는데 있어서 경험이 적어 이해를 하는데 어려움을 겪고 있다.

Try (개선할 점)

• 잘 모르더라도 자신감있게 자신이 어떤것을 모르는지, 어느것이 이해가 되지 않는지 확실히 말할 필요성이 있다.
• 데이터 플로우에 관해서 조금 더 깊게 회의 진행이 필요하다.
• 작은 단위로 PR을 올려서 작업 내용을 팀원들과 공유할 수 있도록 하겠다.
• 미리 세워둔 계획을 지킬 수 있도록 최대한 빠르게 개발을 이어나가겠다.
• 상대방의 코드를 더 면밀히 분석하고자 한다. 나를 포함한 팀원 모두의 코드를 이해해야할 필요성이 크다고 생각하기때문이다.
• 구현이 완성되면 각자 코드를 대략적으로 설명해주는 시간을 가졌으면 한다.

[3rdflr]

✨1팀 KPT 회고

Keep

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

Problem

• 초반에 비해 작업에 몰두하느라 코드리뷰에 대한 중요도가 떨어진것 같다.
• 브랜치 혹은 커밋메시지 관리가 아쉬운점이 있었다
• 초반에 비해 기능구현에 집중하다보니 읽기 쉬운 코드를 작성하지 못한것 같다
• 설계를 할때 기능적인 구조를 생각하지 못해서 디자인 부분에 맞추느라 곤란했다
• conflict 해결에 대한 어려움이 조금 있었다

Try

• 철저한 코드 리뷰 문화 정착
• 일관된 브랜치 명명 규칙 확립
• 유저 페르소나 기반의 심층 테스트 도입
• 최소한의 커밋 단위 유지
• 마일스톤 활용을 통한 명확한 시간 관리

[Heedong0924]

2팀 KPT 회고

Keep

• 협업 툴 사용과 일정 조율에 팀원들이 능동적으로 참여하여 팀워크의 기반을 잘 다졌음
• Linear 을 통해 이슈 관리를 통합적으로 진행해서 팀 단위의 이슈를 빠르게 파악할 수 있었음
• 일정 계획이 체계적이었고, 여유 시간을 염두하여 바쁜 일정을 소화하기 위해 달려주는 모습에서 팀워크를 느꼈음
• 프로젝트 일정대로 1차 완성을 목표로 진행했고 목표치에 도달했음
• 모두가 발벗고 나서서 같이 오류를 해결하는 모습이 인상적이었음

Problem

• 역할 분담 이후 각자 구현 범위에 집중하다보니 전체 구조에 대한 이해가 부족했음
• 이슈 발생의 원인이나 구체적인 에러 라인 없이 문제점을 보고 받았을 때, 해결을 위해 다시 이슈 재현이나 에러 코드를 요구하는 과정이 업무 효율상 개선되어야 한다고 생각했음
• 러닝 커브가 높은 상태에서 모든 사람의 문제를 즉각적으로 해결해주기 어려웠음
• 공용 컴포넌트 만드는 게 예상보다 오래걸려서 코어타임 외 시간을 사용하여 개인시간이 거의 없었음
• 작업 포인트 분배가 많이 아쉬웠음 나의 개발속도를 파악하고 대비하지 못 했음
• 초기부터 퍼포먼스와 성능을 고려하지 않고 개발을 시작해서 최적화에 대한 고민이 있었음

Try

• 기능 구현 전 전체 흐름과 구조를 팀원들과 공유하고 피드백 받는 시간을 정기적으로 가지면 좋을 것 같음
• 컴포넌트를 설계할 때 무작정 써나가기 보단 한 번 정리를 한 후에 작업에 착수해야겠음
• 프로젝트 일정 계획 뿐만 아니라 개인의 일정 관리도 체계적으로 짜야겠음
• 프로젝트 설계시 작은 단위까지 의논이 필요하다고 느꼈음
• 프로젝트 진행 전 각자 새롭게 배우게 될 라이브러리의 공식 문서를 함께 읽거나 분할해서 읽어보는 방식으로 팀원들의 숙련도를 높이는 방식을 생각해보게 되었음