[오름캠프] 첫 팀 프로젝트 회고록

프로젝트 소개

오름캠프에서의 첫 번째 팀 프로젝트, SPACE_VAR

🚀 SPACE_VAR : 우주 여행 예약 사이트

✔️ 개요

• 우주 여행 예약을 위한 웹사이트
• HTML, CSS, JavaScript 활용
  
  

✔️ 주요 기능

• 태양계 행성 목적지 선택 (목성, 화성, 토성 등)
• 우주 배경 영상으로 몰입감 제공
• 간편한 예약 폼 제공
  
  

✔️ 특징

• 우주 여행의 로망을 담은 UI/UX
• 신비로운 분위기 연출
  
  

📆 프로젝트 일정: 11월 1일(금) ~ 11월 11일(월)

(모든 팀원이 함께한 내용을 기술했습니다.)

11월 1일

• 팀 빌딩
• 팀컨벤션 정하기
• 프로젝트 주제 정하기
• 간단하게 프로젝트 기획하기
• 간단한 레이아웃 정하기
• 피그마로 첫 페이지 디자인 하기

11월 4일

• 프로젝트 기획 정리 및 마무리 하기
• 피그마로 구체적인 디자인 하기

11월 5일 ~ 11월 8일

• 팀원별로 역할을 나눠서 개발하기

11월 9일 ~ 11월 10일

• 코드 리팩토링 및 발표 자료 준비하기

11월 11일

• 프로젝트 발표
  
  

👩‍🚀 프로젝트에서 맡은 역할

• 팀장

  • GitHub Project 관리하기(이슈 생성 체크, pr 연결 체크)
  • GitHub push 상황 체크
  • 전체 진행 상황 체크
  • GitHub Wiki에 문서화
  • 프로젝트 발표
  
  

• 주 구현 부분

  • 상세 예약 페이지의 폼 구현 및 예약 완료 창 구현
    
    

🔗 프로젝트 GitHub

회고

회고는 KPT 형식으로 진행하겠다.
회고록을 쓰기 전에 프로젝트 처음부터 일주일동안 어땠는지 다시 돌아보는데, 좋았던 점도, 아쉬웠던 점도 많이 생각이 난다.

👍 KEEP

만족했던 부분

• 우여곡절이 있었지만 일단 프로젝트를 완성을 했다는 점 !

• 팀원들이 맡은 일들을 각자 잘해주었고, 각자의 방식으로 팀장을 서포트해주려고 노력해줬던 것들이 고마웠다.

• 성향이 다르지만 그래서 보완되었던 팀워크였다.

  • 열정적이고 아이디어가 넘치는 팀원들
  • 묵묵하게 할 일을 하며 팀장이 놓치거나 다른 팀원이 놓치는 부분을 예리하게 찾아내는 팀원들
  • 성향이 다른게 오히려 시너지 효과가 났었다.

• GitHub Issue, Project, Wiki를 처음부터 완전히 활용은 못했더라도 경험을 해본 것 !

  
  

🧐 PROBLEM

아쉽거나 부족했던 점

이번 팀플에서 제일 부족했던 것이 팀장으로서의 내 역량이었다고 생각해서 그걸 위주로 써보려고 한다.

• 유리멘탈과 우유부단함
  • 초반에 팀장으로서 당황스러운 일이 있었다. 첫 회의 시작도 전에 팀원이 혼자 역할을 다 나누고 정리해서 모두에게 공유한 것이다. 나는 일단 팀원들과 차근차근 팀 내의 컨벤션과 팀 코드 컨벤션을 먼저 정하고, 역할은 그 후에 정할 것이라고 계획을 짰었는데.. 너무 당황스러웠다.
    또한 공유한 내용에 수정할 부분이 보였고, 그에 대해 이야기를 하다보니 더 먼저 정해야할 것들은 제쳐두고 역할에 대해서 이야기를 나누는 시간을 가져버렸다. 그때부터 순서가 꼬이기 시작하고, 스스로 허둥지둥 대기 시작했다. 내가 멘탈을 잡지 못하고 회의를 하니, 제대로 진행되지 않았다. 팀원들도 그 때를 생각해보면 정해진 것 없이 붕 뜬 느낌이라고 했다.
  • 그 후에도, 팀원이 같이 구현하기로 약속한 부분을 혼자 다 구현해오거나, 팀원 스스로 생각했을 때 괜찮을 것 같은 디자인으로(협의했던 디자인이 아닌) 혼자 다 구현해오는 일이 몇 번 있었다. 그 때마다 단호하게 이야기하지 못했다.
  • 주말을 반납했거나, 밤을 새서 혼자 만들어 왔다고 말하는 팀원들에게 협의되지 않았으니 그건 합치지 못하겠다고 말하기가 힘들었고, 또 이로 인해 일어나는 갈등과, 다시 정해야함에 있어서 지연되는 시간들을 생각했을 때 오히려 이게 시간낭비가 될 수 있고, 다른 팀원들을 신경 쓰지 못할 것 같아서, 그냥 일단 알겠다고 했다. 그리고 '일단 완전히 구현만 일단 하자. 그리고 나서 생각해보자.' 라고 미지근하게 넘어가버렸다.
  • 결국 돌아보면 "내가" 힘들거라 생각해서 넘어간 것이다. 그게 문제였다. 그러한 순간들이 팀장으로서 제일 경계해야하는 것이라는 것을 이제서야 깨달았다. 당황스럽더라도, 멘탈을 잡고 앞으로의 팀워크를 위해서 말해야하는 건 말을 하는 것이 중요한 행동임을 알았고 반성을 하게 되었다.
    
    
• 팀원들이 팀장이 먼저 어느정도 정해주는 것을 바란다는 것을 나중에야 알았다.
  • 내 딴에는 팀장이 이걸 정해보자라고 제안하는 것만 따르면 결국 놓치는 부분이 생긴다고 생각했고, 모든 것을 정할 땐 모두가 의견을 내서 정해야 근거가 생긴다고 생각했기에 어떤 주제를 정하면 좋을지부터 이야기해보자는 입장이었다.
  • 하지만 회의가 흘러가면서 내가 "어떤 걸 정하면 좋을까요?"의 입장을 보이니, 점점 팀원들의 의견이 많이 나오지 않았고 결국 내 생각과는 완전히 다르게 내가 물어보고, 내가 거의 의견을 내고 그게 괜찮은지 다시 물어보게되는, 역설적인 결과가 나왔다.
  • 어떤 팀원은 답답했는지, "그냥 팀장님이 다 정해주고 우리한테 이거해라 저거해라 시키면 안돼요?!" 라는 말도 했었다. 이 말을 듣고 '아, 이런 방향이 지금 팀에게 효과적이지 않구나.. 지금 잘못하고 있구나..' 라고 깨닫게 되었다.
  • 어느정도는 팀장이 정해주고 틀을 잡아주어야 팀원들이 갈피를 잡고 더욱 의견을 낼 수 있다는 것을 이 때 통감하게 되었다. 모든 걸 자율적으로 정한다? 내가 팀원이었어도 너무 막연했을 거란 생각이 든다.
    
    
• 협의 내용의 시각화 문제
  • 회의를 했을 때, "다들 ~~한 부분 괜찮으신가요?"하고 말로만 말하고 넘어갔었다. 깃헙 위키에 회의록을 기록해두긴 했지만, 세세한 것까지는 남기지 못해서 팀원들이 놓치는 부분들이 있었다. 그리고 그렇게 놓치는 부분이 있을 때마다 다시 작업해야한다던지, 다시 팀장에게 질문을 해야한다던지 비효율적인 흐름이 계속되었다.
  • 계속 피피티를 만들어야한다, 피피티 정리를 해야한다고 말하는 팀원이 있었다. 처음엔 회의록을 위키에 따로 작성을 하고 있으니, 지금 피피티까지는 조금 힘들 것 같다고 말씀을 드렸었다. 이야기를 들어보니, 피피티는 그냥 수단 중 하나였고, 그 분이 하고 싶었던 이야기는 즉각적, 지속적인 문서화가 필요하다는 것이었다.
  • 협의 내용은 무조건 팀원들이 잘 보이는 곳에 시각화, 문서화해서 지속적으로 상기시켜야한다는 것이다. '어디에 기록했으니, 당연히 보겠지?' 라는 마인드는 이기적인 생각이다. 시간이 지나면 지날 수록 협의 내용의 시각화 및 명시화가 중요하다는 것을 깨달을 수 있었다.
    
    
• 의사소통
  • 앞서 말했던 피피티를 말씀하신 팀원 분이 계속 피피티를 이야기했던 이유는, 나에게 "문서화를 해야해요. 앞으로 이렇게 이렇게 합시다!"라고 이야기하는 것이 오히려 내가 불편하게 느낄거라 생각해서 그렇게 돌려서 말했던 것이라고 했다. 그런데 내가 알아듣지 못했던 것이다.. 이런 부분에 있어서도 팀원들이 나에게 솔직하게 직관적으로 말하지 못하게 분위기를 만들었었나.. 라는 생각이 들었고, 나 또한 솔직하게 바로 바로 이야기하지 못했던 것이 생각이 나서 반성이 되었다.
    
    

이건 조금 다른 얘기지만,

• 코드리뷰 시간

  • 팀을 운영하며 코드리뷰 시간을 너무 늦게 가지게 되었다. 그래서 코드에 어떤 점들이 개선되었으면 좋겠다는 피드백을 서로 너무 늦게 주고 받게 되었고, 제대로 리뷰가 이루어졌다고 보긴 힘들었다. 스노볼 효과로 결국 발표직전 대대적인 리팩토링이 진행되었다. 코드 리뷰를 지속적으로 하는 것이 코드 품질을 높일 뿐만 아니라, 모두 팀 컨벤션을 제대로 숙지하고 있는지, 협의된 내용이 잘 구현되고 있는지 미리미리 확인할 수 있다는 측면에서도 중요하다는 생각이 들었다.
  
  

🌌 TRY

앞으로 팀플을 위해 기억할 것들(시도할 것들)

1. 멘탈 관리와 리더십 강화

• 첫 회의 때부터 팀장으로서의 확고한 방향성을 가지고 시작하자. 팀원들이 예상치 못한 행동을 하더라도 당황하지 말고, 차분히 대응할 수 있도록 마음가짐을 준비하자.
• 협의되지 않은 일을 진행한 팀원에게는, 그들의 노력은 인정하되 팀워크를 위해 앞으로는 꼭 사전 협의를 하자고 단호하게 전달하자. "노력해주셔서 감사합니다. 하지만 앞으로는 먼저 팀과 상의해주시면 좋겠습니다."
• 갈등을 피하려 넘어가지 말자. 당장은 불편할 수 있어도, 팀의 장기적인 발전을 위해서는 필요한 조치라고 생각하자.

2. 적절한 프레임워크 제시

• 첫 회의 때 기본적인 프로젝트의 방향성과 큰 틀은 팀장인 내가 제시하자. "이런 방향으로 진행하면 어떨까요?"라고 구체적인 예시와 함께 제안하자.
• 그 다음에 팀원들의 의견을 물어보면서 수정하고 발전시키는 방식으로 진행하자. 이렇게 하면 팀원들이 더 구체적인 의견을 낼 수 있을 것이다.
• 팀원들의 의견을 받을 때도 "A와 B 중에 어떤 게 좋을까요?"처럼 선택지를 주면서 물어보자. 너무 열린 질문은 오히려 답변하기 어려울 수 있다.

3. 체계적인 문서화 시스템 도입

• 모든 회의 내용은 즉각적으로 문서화하자. 노션이나 피피티 등 팀원들이 쉽게 접근하고 이해할 수 있는 형태로 정리하자.
• 특히 결정사항은 반드시 시각화해서 기록하자. 예를 들어:
  • 컨벤션 규칙
  • 역할 분담
  • 일정표
  • 기능 명세
• 매 회의가 끝날 때마다 결정된 사항들을 팀원들과 함께 리뷰하는 시간을 가지자.

4. 솔직한 의사소통 문화 만들기

• 첫 회의때 "솔직한 의견 개진"을 팀의 핵심 가치로 정하자. 팀원들이 돌려 말하지 않아도 되는 분위기를 만들자.
• 정기적으로 1:1 미팅 시간을 가져서 팀원들의 고충이나 의견을 편하게 말할 수 있는 자리를 마련하자.
• 나부터 먼저 솔직하게 소통하자. "이 부분은 제가 부족해서 도움이 필요합니다" 또는 "이렇게 하면 더 좋을 것 같아요"라고 직접적으로 표현하자.

5. 정기적인 코드리뷰 문화 정착

• 첫 회의때부터 코드리뷰 일정을 팀 스케줄에 필수적으로 포함시키자. 예를 들어:

  • 매주 수요일 오후 2시는 코드리뷰 시간으로 고정
  • 리뷰 전날까지 PR은 반드시 올리기
  • 리뷰어는 최소 2명 이상 지정하기

• 코드리뷰는 개발 초기부터 시작하자. '기능이 완성된 후에 리뷰하자'는 생각은 버리자.

  • 설계 단계의 코드도 리뷰하면서 방향성을 맞추기
  • 작은 단위의 PR이라도 꾸준히 올리고 피드백 받기

• 리뷰 가이드라인을 명확히 정하자:

  • 컨벤션 체크리스트
  • 성능 개선 포인트
  • 재사용성/유지보수성 고려사항
  • 테스트 코드 작성 여부

• 리뷰 시간에는 모든 팀원이 참석하여 함께 코드를 보면서 학습하는 시간으로 활용하자. "이런 방식으로 구현했네요. 저는 이렇게 생각했는데, 어떠신가요?"라며 서로의 관점을 공유하자.

• 이렇게 하면 발표 직전의 대규모 리팩토링을 방지하고, 점진적인 코드 개선이 가능할 것이다. 또한 팀원들의 코드 품질도 자연스럽게 향상될 수 있을 것이다.

이러한 시도들을 통해 팀에 더 나은 방식으로 기여할 수 있도록 노력해보려한다. 모든 걸 완벽하게 할 순 없겠지만, 이번에 배운 점들을 토대로 조금씩 발전해나가면 좋겠다.