6개월, 프론트엔드 회고

내가 했던 것, 그리고 미리 생각해봤더라면 좋았을 내용
 

• PR에 gif 이미지 첨부(PR을 더 잘 설명하기 위한 방법)
• 커밋 생활화
• 타 팀원과 교류하기
• 팀에서의 나의 페르소나 돌아보기(예측 가능한 사람이 되도록)
• 팀워크를 위해 팀규칙과 컨벤션 정하기
• 스크럼 시간에 오늘의 할 일 목록 만들기(목표 달성으로 인한 성취감)
• 팀원의 요청에 대한 나의 태도(긍정적인 방향으로 생각해보기)
• 문서화. 변경사항 발생 시 반드시 알리기
• 원격 근무시 갖춰야 할 태도(소통의 양방향성을 위해 카메라와 스피커를 켜야 하는 이유)
• 슬랙 스레드를 읽고 반응 남겨야 하는 이유(읽은 사람 체크, 리마인드, 의견에 대한 반응 확인)
• 팀 프로젝트 회고글

 

 

1. 첫 과제 PR

GIF 이미지와 함께 업로드

 
간단한 과제였지만,
● 직접 코드를 실행하지 않고도
●  코드가 어떻게 동작하는지 보이기 위해
●  PR본문에 동작 과정에 대한 gif를 첨부했다.
 
제 작업물 한번 보세요 여러부우운
제 코드는 이렇게 동작합니다아아 여기보세요오오
생각해보면 학부때 과제도 이렇게 영상 기록으로 남기긴 했는데, PR로는 처음.
 
그리고, 그 다음번 과제부터는 다른 분들도 gif를 올리셨는데,
vscode로 실행해보지 않아도 UI 및 작동 방식을 확인할 수 있어서,
다른 분들 PR을 간편하고 재밌게 볼 수 있었다.
 

2. PR

작성 방법 고민

 
PR은 특히나 고민을 많이 했던 부분이었다.

줄글로 작성하는 경우 가독성이 떨어지기도 하는데, 잘 전달하기 위한 방법을 고민했다.
글자 배경색을 바꾸거나, 숫자를 붙이거나, ● 점을 표시해도 글자가 많으면 읽는 사람이 힘들겠다 싶었다.
 
그래서 문장을 줄이고, 개조식으로 문장을 작성해보자는 생각을 하게 되었다. (보고서 형태)
회의록 및 커피챗을 작성할 때도 간결하게 작성하면 중요한 정보를 확인하기 수월하기도하다.
 
(그러나 문장 구성이 필요한 경우도 있다)

PR작성 내용

따로 포스팅 분리 합니다.
 

3. Commit

diff 확인

 
처음엔 귀찮게 느껴질 수 있다. 모든 변경사항을 통으로 커밋해버리는 경우도 많지 않을까? 진행시켜!
잘게 쪼개는건 의식해서 하지 않으면 어려웠다. 의식의 흐름대로 모든게 흘러가버리기 때문… 어라라 이렇게 변경이 많네?

깔끔한 코드들만 저장소에 올렸으면 좋겠는데 싶었던 때는, 중간단계는 커밋을 하지 않기도 했지만, 이젠 좀 다르다.

변경사항이 너무 많아지게 된 경우에는, file change를 부분부분 나눠 스테이징해서 커밋한다.
그런데 린트 에러가 생기면 커밋이 안될 수 있으니, sub task에 따라 미리미리 하는게 가장 좋은 것 같다.
커밋하는 습관이 있으면 좋다.

커밋을 분할해서 작성하는 일이 왜 필요한지를 생각해봤는데

1. 팀원들이 작업물의 과정을 이해하는데 도움
2. 개발자 본인에게, 중간 세이브 역할
3. 이슈트래킹에 활용 가능(할 수도)
 
작업 시간도 확인 가능.. "저 이 시간에 이거 히고있었어요"
가끔 엄청난 변경을 거치고 다시 돌아가고 싶어질 때가 있는데 ctrl+z 가 안될 수 있다. 돌려줘요~~

가장 궁금했던 것
코드 리뷰는 그럼 file change로 하는걸까? 아니면 커밋 단위로 하는걸까?
 
내 경우에 리뷰 남기는건 file change를 보고 했는데,
(흠 그런데 diff를 파악하기에는 그다지 좋은 것 같지는 않았을까?)

 
특이한 커밋이 있는 경우엔 직접 커밋을 클릭해서 세부내용을 확인했던 것 같다.
 
그런데 지금 생각해보면 sub task에 따라 잘 나뉜 커밋을 보면
diff를 구분해서 달라진 내용을 파악하기가 용이한 것 같기도 하다.
 
차라리, 커밋 메시지를 상세하게 작성하는 건 어떨까?
 
PR 본문에 커밋 해시를 포함해서 커밋 메시지를 작성하는게 아니라..

[해시값1] : ~ 를 구현했습니다.
[해시값2] : ~ 를 구현했습니다.
[해시값3] : ~ 를 구현했습니다.

 
커밋 메시지를 구체적으로 작성하면

• PR 본문에 작성하는 메시지의 중복을 피할수도 있고
• 커밋을 클릭해서 확인하여, 작업 범위를 한정해서 확인할수도 있지 않을까..?

커밋 메시지 작성 방법 부터 시작해서 커밋에 대해 좀 더 연구해야 할 것 같다.
 

4. 과제 PR 모두 읽어보기

내 고민과 같은 고민을 했던 분은 없을까?
더 멋지게 풀어낸 코드를 보고싶어

 
- 다른 팀원들의 PR까지 전부 읽어봤다.
- 다른 팀의 리뷰 문화를 간접적으로 배울 수 있었다.
- 다른 팀 멘토님의 리뷰를 보며 다양한 관점을 접할 수 있었다.

초반 과제로 특별하게 기억났던 다른 팀의 리뷰는
자주 반복되어 발생하는 human error는 eslint로 체크할 수 있다는 점이었다.

그래서 린트 규칙을 찾아본적도 있었는데,
생각보다 다양하게 규칙을 설정할 수 있어서 흥미로웠다.

import 순서를 지정할 수 있다는 점도 놀라웠다. 정말 멋진걸
 

5. 다른 팀의 팀원과 교류

안녕하세요? 여러분의 PR을 읽고있는 사람입니다. (웃음)

 
다른 팀이었던 팀원에게 말을 걸었다.

그 당시 과제에 vercel로 배포하는 과정이 포함되어 있었다.
그런데, 이 때 API를 래핑하지 않으면 고스란히 API key가 노출되기 때문에 코드가 노출되지 않는 방법을 사용해야 했다.
 
그 분의 PR을 읽으면서, 코드와 폴더구조를 봤는데 API를 숨기는 부분이 없었다.
그래서 직접 웹페이지에서 Network 탭을 확인해봤다.
 
PR에는 api key가 노출되지 않는다고 체크되어 있었지만,
실제로는 key가 그대로 노출된 상태였다.

으음.. 말을 해야 할까
일단, 같은 팀이 아니어서 참견하는 것이 맞는지 고민을 했었다.

그런데 이 부분은 나중에라도 다음과 같은 이유로 도움이 될 것 같아서, 꼭 말씀드리는 게 좋을 것 같았다.
1) vercel로 배포시 key가 노출되지 않도록 주의해서 관리
2) 네트워크 탭 확인해서 크로스 체크하는 방법이 있다는 점

그래서 말씀드렸다.

…(중략)…
F12로 [개발자 도구]를 열어서, Network 탭을 확인해보시면 api 요청 부분에 API key가 노출되어 같이 전송되고 있어요.
한번 확인해보시면 좋을 것 같아요.

 
여러 대화가 짧게 오갔고, 대화는 잘 마무리 되었다.

또 다른 한 번은
슬랙 채널에서 공개적으로 도움을 요청하신 분이 계셨다.

깃허브로 관리되던 영역(폴더)가 있었는데
vscode에서 잘못 클릭해서 파일들이 전부 사라졌다는 내용이었다.
 
그때 마침 우리 팀원도 비슷한 실수를 한적이 있었기 때문에, 찾아보고 도움을 드렸던 경험이 있어서 추론해볼 수 있었다.
글로도 남겼음. [vscode discard changes](https://hello-kk.tistory.com/909)
 
만에 하나라도 안된다면.. 희망이  절망으로 바뀔까봐 걱정했지만 정황상 맞을 것 같았다.

조심스럽게 댓글을 적었고 확인해보셨다.
 

6. base branch 확인

우리 팀원들도 깜짝 놀라곤 했던 PR의 base branch

 
어라라 main을 베이스로 하고 PR 올렸네!!!
삭제삭제!!

하지 않아도 된다.(사실 삭제는 불가능. PR close 만 존재) 그냥 제목에서 edit 클릭해서 base branch 변경만 하면 된다.
PR을 이미 닫았다면? 그냥 다시 하단의 오픈 버튼 누르면 된다.
 
PR은 소중한 자산(누군가의 코드리뷰, 내 리소스)

브랜치 이름

23/feat/review-component ▶ 터미널에서  git checkout 23/ 을 입력하고 tab키를 누르면 자동완성 된다.
feat/23/review-component ▶feat/23/까지 입력해야 자동완성이 된다. 왜냐면 feat는 공통된 부분이니까.
#23/feat/review-component ▶#은 주석을 의미해서..

그런데 브랜치내 경로가 트리처럼 구성되어 있다면…
그래도 자주 삭제하곤 하니까..
좀더 찾아봐야 할 것 같다.

7. 만약 메인에 푸시를 해버릴 것 같다면?

반성문 걱정을 하십니까? No~ No~

 
commit lint를 설정해서 사고를 방지할 수 있다.
 

8. 페르소나 설정

예측 가능한 사람? 그리고 신뢰자본
https://jojoldu.tistory.com/675

 
역지사지로 생각해본다면…
내가 어떤 말을 했을 때, 상대방은 어떻게 반응할까?
 
나는 팀 프로젝트를 할 때 페르소나가 있다.
 
1. 친절할 것(물론 안되기도 함)
2. 이해할 것(아침엔 다들 피곤한 상태 이해한다)
3. 책임감을 갖고 임할 것(어려운 일이다. 자책감에 괴로울 때도 있다)
4. 도움을 요청 받았을 때 관심갖기
5. 팀 내 세세한 일들을 포함해 신경쓰기(일정 관리, 제출 여부 체크 등)
6. E처럼 행동하기(이건 좀 특수한데, 팀플을 하는 시기에 MBTI검사를 하면 E랑 J가 나온다. T도 나옴)
7. 가끔 TMI 농담하기(종종 실패하곤 함. 음소거여서 그런걸까..? 사실 다들 화면 너머에서는 피식 웃었지 않을까..?)
8. 말을 천천히 하기(너무 느리면 듣는 입장에서 답답할수 있지만, 무언가를 설명해야 하는 경우 너무 빠르지 않게 조절해야 한다)
 
일을 하는데 있어서 얼마나 마음에 벽을 허물 수 있는지, 그러면 결과가 어떻게 달라질 수 있는지 생각해보면 좋을 것 같다.

9. 팀워크

초반에는 이런것도 상의하나? 싶은 내용도 그냥 말해본다.

 
여기에 덧붙여 보자면, 생각보다 나랑 다르게 생각하는 부분이 (당연히) 존재한다.

예를 들어 누군가 스크럼에 지각한다는 가정을 해보자. 언제 올지는 모른다.
1. 오전 스크럼을 건너 뛸 것인가?

2. 기다릴 것인가?
2-1. 얼마나 기다릴 것인가?
2-2. 기다린 뒤에도 오지 않는다면?

3. 지각한 사람 없이 진행을 우선 할 것인가?

 
가끔은 미리 약속을 정하는 방법이, 나중에 스트레스를 덜 받을 수도 있는 것 같다.

그리고… 쫌 바보같이 느껴지는 질문을 해도 돼! 쫄지마!
사실 저 모르는게 많아요 여러분 죄송…

개인적인 생각이지만, 이런저런 질문을 하고 팀원들에게 상의하게 되면 (인과관계가 명확하게 있는지는 잘 모르겠지만.. 상관관계는 있을까? 어쨌든 경험상) 질문하기 쉬운 환경이 형성되는 것 같다.
그냥 자연스럽게 의견을 교환하는 분위기로.

여러가지 사정으로 운을 떼기 어려운데,
말을 많이 하고 의견을 내는게 가장 건강한 팀워크를 이룰 수 있는 것 같다. 스노우볼을 막을 수 있다.

그리고 혼자 끙끙 앓는 것 보다, 집단지성을 발휘하면(누군가는 경험이 있을 수 있다) 바로 해결 방법이 나오기도 한다.
만약 그렇지 않더라도 다양하게 등장한 새로운 단서들로 추론 범위를 넓혀볼수도 있다.

가끔은 내가 못보는 것을 팀원이 보고, 팀원이 못보는 것을 내가 알려주면 그것도 나름 팀의 결속력을 높이는 것 같다.

10. 컨벤션

평소 나의 코딩 습관을 생각해보기

 
팀 규칙을 정할 때 그때가서 생각하지 말고 ,미리미리 내 wiki docs를 만들어 보는 것도 좋을 것 같다.

예를 들면 아주 사소한 것부터.
event 객체는 e? evt? event?
그리고 왜 그렇게 하는지 한번 생각해보는 것도 좋을 것 같다.
 

11. 코드리뷰(코드 컨벤션)

기분이 상할수도 있지만, 배우는 게 정말 많다

 
그리고 기분이 안 좋아지면
곰곰히 생각해보는 것을 추천한다.
단순히 지적 받아서?
그런데 명확하게 좋은 코드로 거듭난다면? 이걸 알게되면 사실 기분이 상할 이유가 없어지게 될수도 있다.


그런데 만약 우리가 사전에 약속한 컨벤션이 있다면, 그렇게 기분나쁘지 않을 수도 있다.

"이거 왜 이렇게 쓰셨어요?"
대신에,
"컨벤션과 다르게 작성된 부분이 있어요. 확인부탁드립니다"
객관적 사실을 제시하면 더 받아들이기 쉬운 것 같다.

물론 모든 내용들을 컨벤션 이름 하에 포함할 수는 없지만, 컨벤션은 만들어 나가는 것이라고 생각한다.
그리고 규칙이 정해지면 리뷰받을 때 스트레스를 덜 받을 수 있는 것 같다.
 
또, 팀원이 작성한 코드를 자주 리뷰하다 보면
나한테도 소중해 지는 느낌이 들었다.
 
계속 리뷰에 참여하며 흐름을 따라가는 것도 다음 PR을이해할 때 도움이 되는 것 같다.
 

PR merge가 지연되는 문제가 있었다.

 
원인을 찾기 위해 각 팀원의 PR 리뷰에 참여한 횟수, 작성한 코멘트 갯수, 승인 여부 횟수를 조사해봤다.
 
그리고 회의 시간에 해당 이슈로 팀원들과 대화를 나눴는데, 리뷰가 어렵다는 문제가 있었다.
 
어떤걸 리뷰해야 하는지 항목화를 해서 글을 작성하고, 팀원들에게 공유했다.
[PR 리뷰가 어렵다면, 해볼 수 있는 내용](https://hello-kk.tistory.com/1019)
 
설계는 아직 알아가는 중이고, 표에 나열할 수 있는지 잘 모르겠어서 추후에 보충하려고 한다.
 

12. 스크럼

시작시 10분
1. 오늘의 체크인 점수(기분 점수)
2. TODO 공유
3. TMI 

종료시 10분
1. 오늘 한 것
2. TMI

 
팀원이 어떤 일을 했는지, 나를 자극하는 동기가 될 수 있다.
팀 프로젝트를 시작하면 어떻게 진행되고 있는지 파악할 수 있으며, 백엔드 팀원과 싱크를 맞추는데 중요한 시간이 된다.
 
TODO를 이 때 정리해보자. (내가 오늘 작업할 일 목록)
마음이 급해지면 이거저거 해보다가 안되는 경우가 있는데, 이를 보완해준다. 나의 작성 방법은 다음과 같다.
1. 할 일 목록을 만든다. 내 경우 노션 checkbox [ ] 를 사용
2. 일을 하는 중간에도 목록에 sub task로 추가하면서
3. 하나씩 완료해 나가자
4. 성취감도 있고
5. 해야할 일이 명확해진다.

특히 코드를 설계할 때 정리를 하고 시작하면, 일의 순서를 따라 하나씩 달성해 나갈 수 있다.
 

13. 팀원의 요청

태스크를 이전에 해보지 않은 경우, 압박감

 
앞으로 어떤 역경이 펼쳐질 지 모르기 때문에 걱정이 생기기도 한다.
경험해본 사람이 있다면, 앞으로 어떤 고민을 하게 되는지 내 경험을 공유해보는건 어떨까?
막연하게 걱정스러운 부분을, 해결해야 할 문제로 정리하면 답답한 기분이 어느정도 사라지고 목표가 생긴다.

몰입할 수 있도록 도와주자
 
사실 아쉬웠던 부분이 있는데, 티키타카로 더 이야기를 해보고 싶었다.
 
이후로는 상대방의 생각을 더 들어보고 싶다는 말 또는 문장으로 여지를 남기곤 했다.

어떤 부분을 더 얘기해보고 싶어요
그 부분에 대해서는 어떻게 생각하시는지 궁금합니다~!

 

14. YES MAN ? NO~ NO~

나는, 그대의 생각이 궁금해

 
좋다고 말하기 보다, 좋다는 결론을 내리기까지 과정을 함께 얘기해보는 건 어떨까?

난 ~ 이렇게 생각해서 A 부분이 괜찮네.
그런데 B 는 우려되는 부분인걸?
흐음, 그래도 안건은 A 였으니까.. 이 부분은 나도 좋다고 생각해. => 좋아요 (B에 대한 의견이 생략됨)

어라 C 라고?
흠 그런데 가정이 조금 이상한걸?
D를 가정하고 말한 것이 맞을까?
팀원들이 좋다고 하니까 ... 다들 이 부분은 생각해봤겠지? => 으음 좋아요 (D에 대한 의견이 생략됨)

 
의견을 같이 공유해요~
사실 다른 팀원은 그렇게까지 생각 안했을 수도 있음!
확인차라도 말해보자.
 

15. 오픈 소스 기여

ko.react.dev 공식 문서에 기여

오픈 소스에 기여하는 방법이 궁금하다면,
good first issue 검색

 
React를 좀 더 React 답게 사용해보기 위해 공식 문서를 읽고, ko.react.dev 공식 문서에 기여했다.

javascript.ko랑 React 공식 문서가 제일 재밌는 것 같다. 이유는 바로바로 과제가 있다는 것.
퀴즈★좋아
동일한 맥락으로 w3c schools도 좋아한다.

16. 문서화

항상 sync를 맞추기! (디자인-프론트, 프론트-백엔드, 기획-디자인)
변경사항 → 즉시 업데이트 (Figma/API 명세서/노션)
@담당자 (담당자 태그해서 변경 사항 알리기)

 
Figma도 API도. 수정사항이 발생하면 곧바로 수정해야 하고 담당자에게 알리는게 중요하다.
Task 담당하신 분을 태그하자
 
문서가 바뀌었다고 했을 때 바뀐 부분을 저절로 알아차린다고 생각하면 안된다! 어라라? 바뀐거 몰랐어요..!
변경 부분이 생긴다면 반드시 공유하기! (예: A → B로 수정되었습니다. 확인 부탁드립니다.)

• API 문서
• Figma 문서
• .env 문서
• Notion

그리고, 확실하게 말하기

확실하다는 말도 확실하지 않지. 무엇이, 얼마나 확실한지 모르니까

자세한 내용일 수록, 상대방이 해야 할 Ation을 명확하게 전달하자.

자세한 줄글 이라면, 간결함도 포함해야 하는 것 같다.

상대방이 쭉 읽고 나서, '음 그래서 뭘 해야 하는거지?' 하고 글을 다시 읽지 않도록.
 
[문서화](https://hello-kk.tistory.com/1031)

17. 불필요한 시간 줄이기

단축키 활용부터 시작

 
파일 찾기: ctrl + p
현재 탭(파일)의 형제 노드: Explore 보면 현재 파일이 위치한 트리가 보여짐
ctrl + d: 단체로 수정하기

18. API  스팩이 변할 때

API 스펙이 바뀌더라도, 관련 코드를 모두 수정하느라 바쁘면 안된다.
어댑터 레이어에 있는 부분만 수정해도 되도록 고민을 해봤다.

19. 팀원 요구사항

이력서에 한 줄 더 적을 수 있는 기회

~ 해보는건 어떨까요?
~ 해주세요

 
'일이 더 늘었네' 라고 생각하지 말고, 이력서에 한 줄 더 적을 수 있는 기회라고 생각해보는 건 어떨까? (긍정적 해석)

그리고 A와 B가 있을 때, 생각보다 무언가 더 특출하게 좋다는 결론이 (나의 짧은 식견으로는) 안난다면
제안 받은 내용을 적용해보는 것도 좋은 것 같다.
실제로 바꾸고 나서 달라진 점을 내가 느껴볼 수 있다.
유지보수할 때 빛을 발휘할 수 있는 경우도 있다.

21. 해커톤에 선발됨

토요일 특강 vs 해커톤

 
해커톤을 선택했다. 호호
잔뜩 긴장했지만 처음 만난 사람들과 재밌는 경험이었다.

22. 팀 회의

회의록 작성

 
팀원 의견이 이해하기 어렵다면, 기록하면서 들어보자.

그리고 떠오르는 질문을 옆에 함께 작성하면,

• 내가 어떤 대답을 해야 하는지,
• 질문의 의도를 다시 확인하는 것도 가능하고,
• 궁금한  내용을 잊어버리지 않고 잘 물어볼 수 있다.

23. 멘토님들의 조언 실행해보기

커피챗에서 해주신 챌린지들을, 의식적으로 과제에 포함해서 한번씩은 해봤다.
(우연하게도 적용 가능한 과제들이 등-장!)

24. 일을 하는 것

지나치게 배려해서 말을 아끼려고 하지는 말자. 핵심은 '지나치게'라는 것!

 
꼭 말해야 한다고 생각하거나, 업무를 체크하는 경우는 꼭 말해야 하는 것 같다.
'무슨 사정이 있겠지'를 시작으로 점점 넘어가면, 스노우볼이 될수도 있는 것 같다.

25. Figma 사용법

[FE 엔지니어의 Figma 사용법 (초급편)](https://hello-kk.tistory.com/1004)
간단하게 다뤄볼 수 있는 내용들로 구성해서 글을 작성했다.
 
만약 새로 기술을 도입해야 하는 경우라면?
 
내가 알고 있는 내용을 문서로 정리해서
팀원과 공유하고 피드백을 받아보자.
 
0부터 시작하는 것보다는

• 빠르게 온보딩이 가능하고
• 토론할 수 있는 환경을 갖추게 될 것이라는 생각이 든다.

26. 디스코드 카메라 on, 스피커 on

규칙으로 정해져있는 부분인데,
원격 근무를 하게 되면 필수적인 것 같다.

• 자리에 있는지 확인
• 바로 소통 가능한지 확인

카메라 off 상황이면 누군가를 호출해야 할 때 “~님 혹시 자리에 계신가요?” 를 물어봐야 하고
(만약 미리 자리를 언제까지 비운다는 메시지를 남기지 않았다면) 자리에 언제 돌아오는지 모르기 때문에, 메시지를 남겨야 한다.
메시지를 남겼을 때 회신이 언제 올지 모르면 일단 기다려야 한다.

카메라를 켜고 스피커도 켜놓는게 처음엔 불편할 수 있지만, 소통을 원활하게 하기 위한 규칙이니 준수하면 좋을 듯 하다.

27. 슬랙에서 이모지로 반응하기

✅ (확인했습니다) 👍 (좋아요)

누군가 팀 슬랙에 글을 올렸다면, 읽었다는 표시를 해보는건 어떨까?

누가 읽었는지 확인할 수 있고
누가 아직 읽지 않았는지 점검 할 수도 있다.
리마인드를 할지 결정할 수 있는 지표가 될 수 있고
의견에 대한 반응을 확인할수도 있다.
 

28. 두번의 팀 프로젝트 회고 글 작성

프로젝트를 진행하면서 팀으로 배운 점은

• 같이 일하는 과정을 배웠고, 전달력을 높이기 위해 고민을 했다.
• 팀이 진행될 때 앞으로 전개될 문제 상황을 예측하거나,
• 문제를 효과적으로 보고하고 해결책을 찾아낼 수 있는지를 고민했고,
• 놓친 부분은 없는지 점검하려고 했었다.
• 발전된 코드 리뷰
• 백엔드와 일하는 과정, 소통 방법도 조금은 배웠다고 할 수 있을 것 같다.

개인적으로 엔지니어로 배운 점은

• 리액트를 리액트답게 사용하는 것
• 왜 사용하는지 이해하게 되었다는 것
• 어떤 근거를 갖고 의사결정을 해야하는지

 
프로젝트 회고(2차 팀)
프로젝트 회고(3차 팀)