[Section6] 프로젝트를 리딩하며

 
 
 

background music

 

무지개의 끝 - 심규선

 
 

---

 

CODESTATES BE 42th

 
 

Section 6

(23.03.03 ~ 23.04.03)
 

 
 

섹션6은 메인프로젝트 기간이다.
열정적인 사람들과 팀이 되어서 
성공적으로 마무리하는 과정을 경험했다.
 
 
이번에도 팀장을 맡았는데 
프리 프로젝트와 다른 태도로 임할 수 밖에 없었다.
 
프리 때는 성장에 집중하자는 말 하나로도 충분했다.
 
그러나 메인은 실제로 이용할 만한 가치가 있는 서비스를
퀄리티 높게 만들어야만 했다.
 
그래서 프리때 내가 보여줬던 팀장의 태도와
메인때 보여준 팀장으로써의 태도는 조금 많이 달랐을것 같다.
 
 
이번 프로젝트에서 느낀점과 성장한점을 위주로 회고를 적어보겠다. 
 
 
 

---

 

✅ 프리와 메인에서 보여준 태도의 차이점

 
좋은 팀과 커뮤니케이션이라는 주제로 프리 프로젝트를 회고 했었다. 
내가 느낀 좋은 팀장의 역량은 다음과 같았다.

• 사소한 이야기에 귀를 기울이고, 감정을 보듬어 줄수 있는 사람
• 한사람마다의 역량을 파악해 긍정 및 부정 피드백을 줄 수 있는 사람
• 적절한 업무 분배
• 이상한 방향으로 갈때 그 길이 아님을 말하고, 올바른 길을 알려주는 사람

 
프리 프로젝트에선 결과가 그렇게까지 중요하지 않았기 때문에
팀원 한사람 한사람의 성장에만 집중하는게 가능했다.
 
나 또한 코드의 퀄리티가 좋지는 못했지만 어떤생각을 갖고 작성했는지 정도를 나누며
천천히 의견을 나누는게 가능했었다.
 
이는 클론 프로젝트의 성격 때문이기도 했다.
화면과 기능이 정의되어 있기 때문에 시간적으로 개발 자체에 더 집중할 수 있었다.
 
 
메인에서는 환경이 변해서 절대로 천천히 갈 수 없었는데
첫째로는 화면의 정의부터 기능까지 아무것도 정해지지 않은 상태에서, 퀄리티를 더더욱 높혀야했고
둘째는 우리가 활용할 수 있는 인적 및 시간적인 자원이 어디까지 커버칠 수 있는지를 확신할 수 없었다.
 
그래서 메인임에도 불구하고 너무 커다란 서비스를 만들 계획은 세우지 않았다.
우리가 확실하게 할 수 있는 것들을 추리고, 서비스의 완성도를 높히겠다고 다짐을 했다.
 
이 과정에서 커뮤니케이션의 방식 또한 약간 달라지게 되었다.
 
 

✅  보편적인것이 당연한 것은 아니다.

어떤 기능에 대해 많은 사람들이 그렇게 개발하고 있다고 해서, 모든 사람을 납득시킬 수는 없다는 것을 깨달았다.
사람마다 갖고 있는 관점이 다르기 때문에, 많은 서비스들이 이렇게 하니까 당연하게 그렇게 가야하는것 아닌가라고 생각한것이 잘못되었다. 머릿속에 있는 방법이 정답일지라도, 나와 다른 생각을 갖고 있는사람을 잘 설득할 수 있도록.. 표현의 방식을 바꿔야 겠다는 것을 느꼈다.
 
 

✅ 정보의 양 : 적당선은 어느 정도인가?

⏺ 세부적인것까지 의견을 나누는것은 불가능하다.

팀의 인원이 많아질수록, 시간이 부족할 수록
너무 세부적인 의견까지 묻기 어려워질것이라고 생각했었다. 
 
팀장의 역할은 그런 것들까지 관리를 하는게 있다고 생각했다.
그래서 초반부에 어느정도는 트러블이 있었다. 
 
 
API 응답을 작성할 때  <댓글을 페이지네이션을 할것인가>에 대해 이야기 하다가 문제가 발생했다.
 
팀원분이 당시에
"만들고 싶은 서비스의 형태가 사람마다 다를 수 있기 때문에 프론트 분들과 논의하면서 가야한다"고 말씀해주셨는데
나는 그게 프론트분들까지 논의할 필요가 없다고 느꼈었다.
 
프론트분들은 당시에 화면을 제작하고 기획하는 등의 하시는 일이 존재했고,
API문서는 우리가 작성하는 것이었으니까 우리가 결정해도 된다고 생각했었다.
 
프론트 분들께 물어보고 오자와
우리끼리 결정했으면 좋겠다로
당시에 15분~20분 정도 디스코드에서 이야기를 나눴다.
 
 
사실 프론트분들께 물어보고 오면 금방 끝낼 수 있었다.
 
 
그러나 이후에도 굉장히 간단한것들까지 세부적인 의견을 모두 나누게 되지 않을까를 염려했고,
어떤 것이 발생했을때마다 의견을 구하러 다녀야하기 때문에 나 스스로가 금방 지칠것을 예상했었다.
 
 
팀빌딩을 할 때부터 불필요한 커뮤니케이션을 없애기 위해
회의도 하루에 한번 오전에만 진행하는걸로 했는데, 
이 역시 불필요한 커뮤니케이션을 줄이기 위한 개인적인 노력이었다.
 
 
결과적으로는 내 의견대로 페이지네이션 처리를 하지 않고 프론트분들께도 여쭤보지 않게 되었는데, 
같은 논제로 이야기를 하다보니 약간 지치게 되었다
 
 
토론이 발생한 원인은 표현의 문제였을까..? 설득을 잘 하지 못한 나의 문제였을까 조금 더 고민을 해봐야겠다.
 
 

⏺ 좋은 커뮤니케이션 방법을 계속 찾아나가자

 
이야기를 나누면서 느꼈던 점은
사람마다 다른 가치관을 갖고 있기 때문에 사소한 것에서도 의견차이가 크게 발생할 수 있다는것이다.
 
 
나는 커뮤니케이션을 잘하고 팀장 역할도 잘해내는 사람이라고 생각했었는데,
이전의 나는 누구와도 커뮤니케이션을 잘한다고 자부했었지만,
이번 프로젝트를 통해 결국은 이 또한 자만일 수 있다는 것을 느꼈다.
 
 
 

✅ 이번에 극복한 것

이전 프로젝트에서는 스스로 해결할 수 없는 문제가 발생해 멘탈이 잠깐 나갔었다.
프로젝트 마지막으로 갈수록 힘들다는 등의 부정적인 말을 뱉었었는데,,
 
이번 프로젝트에선 이런 점이 극복되었다. 
 
 
내가 할수 있는것과 없는 것을 명확히 구분하고,
시간이 부족할 것 같으면 개인 잠자는 시간을 줄여가면서 미리미리 가능할 수 있게 만들었다.
 
결과적으로 조금 더 긍정적인 말을 할 수 있었고
시간상 불가능 할것만 같았던 업무도 잘 마무리 하게 되었다.
 
 
 
 

✅ 퀄리티 잡기

 

⏺ 서비스의 규모와 인적/시간적 리소스 비교하기

우리 팀의 ERD는 다른 팀에 비해 조금 작다는것을 느낄 수 있다.
이는 서비스의 규모를 적당히 가능한 정도로 최소화했기 때문이다.
 
우리는 제대로 된 서비스를 제공하는것을 1차 목표로 잡았고
이는 불확실한 시간 투자가 필요한 다양한 기능의 제공보다는
퀄리티를 높히는 것에 집중하겠다는 의미가 되었다.
 
Refresh Token, Redis, Logout, Interceptor, SMTP,
레이어 분리, S3업로드, 복잡한 쿼리문 작성하기 등
 
프리때보다 훨씬 훨씬 더 많은것을 적용했다.
 
 

⏺ 도전과제의 정의 : 처음해보는것은 도전과제인가?

문제는 우리가 이것들에 대해 확실히 도전했다라고 표현할 수 없다는 것이다.
 
리프레시 토큰이나 S3, SMTP 등 한번도 해보지 못한것들을 도전이라 생각했었는데
이 모든것들이 금새 끝나는걸 보고 도전과제가 맞았나 의문이 들었다.
 
분명히 프리프로젝트 때보다 더 어려운것을 한게 맞는데 그만큼 실력이 더 증가해서 쉽게 느껴진것일까?
 
 
나에겐 배포 쪽이 좀더 도전적인 과제가 되었다. 
 
AWS를 잘 이용하지 못했었는데
웹 배포와 https 적용, 도메인 적용을 하며 정말 다양한 것을 만져보게 되었다. 
( 시간이 부족해서 다른 분께 맡긴 서버 배포 - 도커와 도커컴포즈는 아직 제대로 하지 못했지만...)
 
 
안해본것을 적용했기 때문에 도전을 안했다고 볼수는 없지만
스프링 쪽에서 뭔가 축소된 느낌은 계속 받는다.
(데모데이가 끝났으니 도전적인 부분들을 좀 더 추가해 봐야겠다.)
 
 

⏺ 서비스의 퀄리티를 잡는다는 것

퀄리티를 잡은것에는 후회가 없다.
도메인도 예쁘게 잘 적용되었고, https나 토큰에 대해서도 안전하게 데이터가 전송되고 있다. 
또 프론트 버그도 발견한 것에 대해선 다 잡혀있다.
 
사용자가 이용할 만한 서비스를 만들고,
다른 일반적인 서비스가 제공하는 기본적인것들도 제공하며
눈에 보이는 버그를 최소화 한것...
 
최선을 다했기 때문에 1차 배포의 퀄리티에는 만족한다.
 
그리고 아직 작동하지 않는 부분과 추가하기로 한 기능들을
점차 개선하면서 점점 퀄리티를 높혀야겠다.
 
 

✅ 우리 팀

유명한 웰시코기

 
팀원분들이 각자의 역할에 최선을 다해주셨고, 끝까지 노력해주셔서 좋은 결과가 나올 수 있었다.
 

⏺ 서로 보완해줄 수 있는 팀원들

도커와 관련된 부분을 전부 맡겼는데, 성실하게 잘 마무리해주신 지후님
많은 것들이 동시다발적으로 작용하는 부분을 담당하셔서 세세한것들을 봐주신 다운님,
서비스 이용자들에게 예쁜 화면을 보여줄 수 있게 기여해주신 지호님,
프론트 팀장으로 끝까지 책임감있는 모습을 보여주신 정수님,
리프레시토큰과 쿠키를 고민하거나, 이메일 발송 관련해서 고민할 때 빠르게 해결방법을 내주신 시원님
 
진짜 한분한분이 모두 열심히 했다는걸 알아서 너무 감사할 뿐이다!
 
 

✅ 나의 회고

• 느낀점
  • 한달이라는 짧은 시간동안 기획부터 배포까지, 전반적인 프로젝트를 진행할 수 있어서 값진 시간이었다고 생각한다. 스스로 부족한점이 진짜 많다고 생각되면서도 점점 성장해나가는 걸 볼 수 있었다.
  • 팀장이라는 역할에 살짝 부담이 있었는데, 모든분들이 주도적으로 책임감 넘치는 분들과 함께해서 프로젝트가 성공적으로 마무리 될 수 있었다고 생각된다.
  • 아이디어를 이것저것 더 낼수도 있었지만, 부족한 시간을 고려해 서비스의 범위를 너무 크게 잡지 않았던게 다행인것 같다. 적정선에서 우리가 할 수 있는 목표를 잡았고 그걸 완벽하게 마무리 하려고 노력했던 점이 이 프로젝트의 성공 요인 중 하나였던것 같다.
    • 다른 팀을 보면 테이블이 꽤 많은데 우리는 너무 작게 만들었나? 하는 생각이 들었었다.
  • 앞으로도 조금씩 발전시켜서 실제로 많이 사용되는 서비스로 만들고 싶다!
• 성장한 부분
  • 로드밸런서나 AWS와 관련된 것들에 대해 잘 알지 못했는데, 전체적인 프로젝트가 돌아가는 구조나 키워드를 이해하고 더나아가 질문할 수 있는 사람이 되었다.
• 부족했던 부분
  • 프리 이후에 로그아웃, Refresh token을 도전해보고 싶었는데 시간적 여유가 없었다. 지후님이 작성해주신 코드를 훑어만 봤지 제대로 분석해보지도 못했다. 앞으로 시간을 내서라도 다른 사람들의 코드를 좀더 자세하게 분석하도록 노력해야겠다.
  • 마찬가지로 Docker에 대해 하나도 보지 않았는데, 다운님이 도커를 따로 공부하시는 모습을 보면서 반성하는 시간을 가졌다. 팀장이라는 역할때문에라도 전체적으로 조금씩은 봤었어야 했는데, 그렇지 못한것 같아서 많이 아쉬웠다.

 
 
 
 
이번 회고는 커뮤니케이션에 대한 것으로,
다음 회고는 프로젝트 및 기술에 대해 좀더 자세히 적으러 와야겠다.

-> 그냥 기술 블로깅으로 대체했다!