[What We've Done]
1. 프로젝트 이름: GRAMSLAM (인스타그램(Instagram)의 GRAM + 그랜드 슬램의(Grand slam)의 SLAM)
2. 한 일:
3. 사용한 기술:
[Keep]
1. 이번에 습득한 깃(Git)과 깃허브(GitHub) 사용법 적용하기
2. 깃 커밋 메시지 컨벤션(Git commit message convention)을 팀에서 정한 다음 프로젝트를 진행한 점
3. 프로젝트 첫날부터 조바심에 바로 코드를 작성하기보다는 아예 하루 날 잡고 클래스 레이어(Class Layer)라든지 기획하고 틀을 잡는 데에 시간을 쏟은 점
4. 사소한 오류가 발생했을 때도 바로 팀 전체에 알리고 논의한 점
5. 프로젝트 초반부터 스코프(scope)를 너무 넓게 잡지 않은 점
6. 해야 할 부분을 놓치지 않도록 todo 주석을 팀 전체에서 자주 사용하기
7. 자신이 맡은 부분에 주석을 꼼꼼하게 달아주기
8. 트러블슈팅(troubleshooting) 같은 자료를 전부 팀 문서에 기록해 두어 발표 자료로 골라서 쓸 수 있게 한 점
9. 각자 구현한 기능이 어떤 원리로 작동하는지 팀 안에서 특강을 열어서 모두가 전체 흐름을 파악할 수 있도록 한 점
10. 팀장이든 팀원이든 누군가 물어봤을 때 대답을 빨리빨리 해서 시간을 낭비하지 않은 점
11. 논의할 사항이 생기거나 서로 의견이 다를 때 팀 전원의 이야기를 듣고 결정한 점
12. 팀 단톡방을 열어서 각자 일정이 달라도 팀 프로젝트 진행 상황과 계획을 모두 숙지한 점
[Problem]
1. 기능을 구현하는 데에 급급해서 서로 작성한 코드를 볼 시간이 부족했다.
[해결] 성능 테스트와 리팩토링(refactoring)을 반복하면서 서로의 코드를 읽을 수 있었다. 그래도 완벽한 해결책은 아닌 만큼, 다음 팀 프로젝트 때는 제대로 코드 리뷰를 하면 더 좋을 듯하다.
2. 다양한 툴(tool)을 많이 써보지 못했다.
[Try]
1. 와이어프레임(Wireframe)은 초반에 작성하기
2. 프로젝트 초반에 API 명세서는 Request Body 형식과 Response Body 형식은 모두 정하기
3. 다음에도 뉴스피드 프로젝트를 진행하면 댓글 기능과 DM 기능까지 구현해 보기
4. Path variable에 들어가는 id 같은 요소는 프로필의 식별자인지, 아니면 사용자의 식별자인지 구분할 수 있도록 'id' 말고 'userId', 'profileId' 같이 지어주기
5. 클래스(class)및 패키지(package) 구조, 메서드(method) 이름, 어떤 어노테이션(annotation)을 사용할지 등등 세세한 부분을 모두 프로젝트 초반에 팀에서 논의 후 통일하기
6. 다음 팀 프로젝트 때는 테스트 코드(test code)를 반드시 활용하기
7. Pull Request 방법과 규칙을 팀에서 정하고 서로 코드를 리뷰하기
[Feel]
리은: 이번 팀 프로젝트를 진행하면서 이해심이 많은 팀원들과 잘 이끌어 준 팀장님을 만나 정말 많은 것을 배웠다. 각자의 업무가 분명하게 정해졌고, 팀원들이 책임지고 각자 맡은 기능을 매우 구현해 주었기 때문에, 마찬가지로 내게 주어진 임무에만 집중하면 되겠다는 생각이 들었다. 특히 기본으로 구현해야 하는 CRUD 기능과 인증 및 인가 기능을 구현하고 병합하는 과정에서 수정할 부분이 많이 생긴다는 점을 배웠다. 이 과정에서 개발 전에 세세한 부분까지 팀에서 협의하고 조율해야 코드를 수정할 부분이 크게 줄어든다는 점을 깨달았다. 이렇게 사전 준비를 철저히 하면, 한정된 시간을 더 잘 관리할 수 있음을 함께 깨달았다. 앞으로 코드 작성에 더욱 익숙해지면, 스코프(scope)를 넓혀 더 다양한 기능 구현에 도전하고 싶다. 또한 문제가 생기면 팀원들과 곧바로 소통하는 방식이 무척 좋았다. 질문이나 아이디어가 있을 때 부담 없이 의견을 전달할 수 있는 분위기 또한 정말 편안했다. 이번 경험을 기반으로 삼아 팀 프로젝트에서 무엇을 담당할 수 있는지 더 깊이 알았고, 이러한 경험이 한 발짝 나아가는 데에 큰 도움이 되었다.
신우: 이렇게 좋은 팀장과 좋은 팀원들을 만났는데, '이 프로젝트가 최종 프로젝트였다면 얼마나 좋았을까?' 이런 아쉬움이 남는다. 일주일 만에 헤어져야 한다는 생각에 감정이 이입되어 눈물이 조금 고인다. 스스로 이렇게 감성이 풍부한 사람이었나 싶다. 벌써 정이 들어서인지, 아니면 아쉬움 때문인지 잘은 모르겠다. 이번 프로젝트를 하며 느낀 점이 많았다. 특히 '좋은 팀장과 좋은 팀원은 어떤 사람인가?'라는 질문에 답을 조금 얻을 수 있었다. 좋은 팀장이 되려면 일정을 세세하게 수립하고, 모든 업무를 팀원들과 함께 진행하며, 경청과 피드백에 막힘이 없어야 한다는 점을 깨달았다. 또한 적절한 업무 분배와 팀원들을 챙기는 따뜻한 마음과 기록 정리까지 갖추었을 때 팀의 사기는 증진되고, 모든 팀원의 신뢰를 얻을 수 있다는 점 또한 배울 수 있었다. 좋은 팀원이 되려면 기본적으로 좋은 의견을 낼 수 있는 실력 있는 개발자가 되어야 하지만 각자의 역량이 다르듯, 경청하고 배우며 주어진 임무를 추진력 있게 수행하는 점도 좋은 팀원이라면 반드시 지녀야 하는 자질임을 깨달았다. 이번 팀 프로젝트를 하며 정말 즐거웠고 이 기억은 왠지 오래갈 듯하다. 팀원 모두 다른 팀에 가서도, 나중에도 정말 잘 되면 좋겠다. 각자 다른 팀으로 가더라도 멀리서 늘 응원하겠다.
우현: 팀 프로젝트를 진행하며 가장 크게 느낀 점은 무엇보다도 원활한 의사소통이 가장 중요하다는 점이었다. 좋은 팀원들을 만나 서로 다른 아이디어와 업무 수행 방식을 조정하며 협력하는 과정에서 의사소통이 얼마나 중요한지 다시금 깨달을 수 있었다. 처음으로 진행한 팀 프로젝트였기 때문에 협업을 원활하게 이끌어 갈 수 있는 컨벤션(convention)을 더욱 자세하고 세세하게 논의하지 못한 점이 아쉬웠다. 초기 기획 단계에서 컨벤션을 더 명확하게 정했다면 작업이 더 매끄럽게 진행되고, 불필요한 시행착오를 줄일 수 있었다. 그래도 기능 구현뿐만 아니라 기획과 트러블슈팅(troubleshooting) 등 개발 외에 다른 부분까지 깊이 고민할 기회를 얻었다는 점에서 이번 프로젝트는 매우 소중한 경험이었다. 협업 과정에서 단순한 코드 작성뿐만 아니라, 아이디어를 제시하고 문제 상황을 함께 해결하는 과정 또한 프로젝트에서 중요한 부분이라는 점을 깨달았다. 앞으로 남은 팀 프로젝트에서는 이러한 경험을 바탕으로 더 나은 컨벤션과 협업 방식을 미리 준비하고, 팀원들과 적극 대화하고 참여하여 효율성 높은 협업을 해 나가고 싶다. 무엇보다도 상대방 의견을 경청하고 빠르게 피드백(feedback)하며 끊임없이 조율해 가는 태도가 팀 프로젝트 성공의 핵심이라는 사실을 잊지 않도록 노력할 거다.
지현: 이번 프로젝트는 미니 프로젝트 다음으로 진행한 두 번째 팀 프로젝트이면서도 예비 백엔드 개발자로서 진행한 첫 팀 프로젝트였다. 각자 실력도 다르고
'KPT: Keep, Problem, Try > KPT: 우리는 팀으로서 어땠는가?' 카테고리의 다른 글
KPT 24.11.22-24.11.28 '키오스크 만들기' (개인 프로젝트) (0) | 2024.11.30 |
---|---|
KPT 24.11.11-24.11.20 '계산기 만들기' (개인 프로젝트) (0) | 2024.11.30 |
KPT 24.11.04-24.11.08 '미니 프로젝트' (0) | 2024.11.08 |