🎉들어가면서...

오늘 글 에서는 이번에 진행했던 chaeg-check 프로젝트에 대한 회고를 적어보려고 한다. 프로젝트 진행중에는 PR과 여러 검색을 통해 코드적인 실력을 향상시킬 수 있는 기회가 있었는데 소통,협업적인 부분의 성장을 이루기 위해서는 회고를 통해서 각자의 의견을 글로 남겨보고 이해 해보는 시간이 가장 좋을 것이라는 생각이 든다.

🤷‍♂️이번 프로젝트는?

2주간의 프로젝트와 1주의 refactoring을 끝마치며 회고를 적어보려고 한다.
chaeg-check 이라는 book-review서비스를 만들어봤는데

우여곡절 끝에 프로젝트를 초기목적에 거의 부합하게 완성은 하긴했지만 부족한 부분이 많았던것 같다.

Chaeg Check

배포 주소 : https://chaegcheck.vercel.app/sign
프로젝트 저장소 : https://github.com/mobi-projects/mobi-3rd-1-typescript
개발 기간 : 2024.4.29 ~ 2024.5.12

🔧이런 방식으로 회고해 보겠습니다.

이번 회고는 (Keep, Problem, Try)형식으로 작성해보려한다.

1.이런 경험은 좋았습니다. 다음에도 적용한면 좋을것 같아요~
2.이런 부분은 개선하면 좋을것 같아요.(대체 방안과 함께)
3.이런 부분은 이번엔 미리정해두지 않았지만 다음에 적용해보면 어떨까요?

이번 프로젝트를 진행하며 생각했던 내용들을 글로 적어보고 팀원들과 공유한다면
다같이 더 성장할 수 있는 계기가 될 것 같아서 다음의 세가지를 위주로 회고를 시작해본다.

👍이런경험은 좋았습니다

😎1.새로운 개발 진행방식

우선 이번 프로젝트에서 개인적으로 가장 좋았다고 생각한 부분은 바로 기능을 먼저 개발한 후 퍼블리싱을 진행하는 방식이었다.

이전 진행방식은?

지금까지 약 8~9개월정도의 프론트앤드 개발자가 되기 위해서 이런저런 프로젝트를 진행했었는데 항상 공용컴포넌트 => 페이지 퍼블리싱 => 기능추가 의 방식으로 진행해왔다.

여기서 항상 문제점이 있었는데 너무 완벽하게 publishing을 마무리하고 기능을 완성하려고 하니 항상 속도가 쳐지고 프로젝트를 마무리하지 못하는 문제점이 있었다.

이번에는?

이번 프로젝트에서는 팀에서 가장 잘하시는 팀원분의 의견으로 기능을 먼저 완성하고 publishing은 나눠서 마무리하는 것은 어떨까요? 라는 의견을 적용했는데 실제로 만족스러운 진행속도가 나왔다.

예를 들어 이런 방식으로 진행을 했는데

위와같이 최소한의 ui배치와 영역의 구분만 해주고 기능에 관한 pr을 열어서 기능을 모두 완료한후 publishing을 진행했다.

좋았던 이유는?

이런 진행방식이 효과적이었다 라고 생각한 이유는 병렬적인 작업을 하기 더 유리한 진행방식이란 생각을 했기때문이다.

이전에 publishing우선 개발에서는 정확한 설계가 없어서 공용컴포넌트 or 페이지 컴포넌트를 만든후에 수정해야할 부분이 계속추가되고 pr을 마무리하는 과정에서 시간이 딜레이 된 부분이 있다고 생각한다.

하지만 모든 페이지에 기본적인 ui를 배치해두고 기능또한 동작하는 상태이기에
공용컴포넌트 or 페이지 컴포넌트를 작업하는 과정에서 변수를 줄일수있었다.
그렇기때문에 각자맡은 퍼블리싱작업을 병렬적으로 진행해도 수월한 진행을 하게 된거 같다.

😎2.수정 전,후 비교를 보여주는 PR

지금까지 나의 PR방식은

이전까지 PR은 내가 이런 기능들을 작업했으니 코드를 보고 평가해주세요~ 라고만 생각해서 어느정도 작성해두면 review해주는 사람들이 알아서 봐주겠지? 라는 안일한 생각이 있었던것 같다.

이제와서야 이렇게 느꼈다는 것은 같이 늘 같이 작업했던 Jeff님이 많이 이해를 해주셨던 덕분에 큰 문제의식없이 PR을 꼼꼼하게 작성하지 않아도 열심히 리뷰를 달아주셧던것 같다.
이 기회를 빌려 사과를 드리겠습니다...🤣

수정 전, 후 비교를 보여주는 PR

이번에도 늘 하던대로 pr을 올리던 와중 Jeff님의 PR을 보며 이 사람이 PR에서 전달하고자 하는 내용이 확실히 눈에 잘 보인다 라고 생각하게 된 PR방식이 있었는데
바로 수정 전, 후를 ts코드와 함께 보여주는 PR이었다.

실제 이번 프로젝트에서 Jeff님이 올려주신 PR인데 이런식으로 PR을 올려주신 것을 읽으며 확실히 코드에 가서도 어떤부분을 확인해야하고 작업내용이 무엇인지 한눈에 들어왔다.

개인이 PR을 작성하는 시간은 조금 늘어날수 있어도 팀원들의 리뷰시간은 줄어들고 이는 팀 전체의 생산성이 올라가는 방향이라는 생각을 한다.
따라서 앞으로의 프로젝트에도 이런 부분은 적용해서 작업한다면 좋을것같다.

😎3.칭찬은 고래도 춤추게 한다

늘 작업하던 팀원들과 PR을 하는 과정에서 어느순간 서로의 코드에 좋은부분보다 개선해야할 부분만 집중해서 확인하게 됐던것 같다.

내가 올린 PR에 한 팀원이 위와같은 리뷰를 작성해주셧는데 칭찬리뷰에 즐겁게 작업했던 기억이 있다.
그러나 프로젝트를 진행할 수록 서로 바쁘고 스트레스도 쌓이다보니 어느순간 수정요청사항에 대한 리뷰만 달리게된것 같다.

나도 이런 부분은 신경쓰지 못했는데 회고를 하는 과정에서 문득떠올랐다.
아무래도 코드를 작성하지만 사람들이 모여하는 작업이고 각팀원의 기분, 컨디션을 향상시키는 것도 생산성의 증가일탠데 간단한 한줄의 칭찬을 통해 생산성의 증가를 시킬수 있다면 굉장히 좋은 방법 아닐까?

물론 너무 남발하면 효과가없겠지만 고생한 팀원들을 위해 특정 코드에대해 칭찬할 부분은 없을까?를 의식하며 리뷰를 해보는 것도 좋은방향일것 같다.

ex) 이런 식으로 잘한부분을 칭찬해보면 좋을것 같아요~

const CheckMyComponent = ()=>{
   return <div>칭찬해줘~ </div>
}

오 여기서 이런 컴포넌트명을 사용하셨다니 굉장한데요??

와같은 디테일한 칭찬 한 줄에 즐겁게 작업할 수 있는 원동력이 될 것 같다.

😱이런점은 개선하면 좋을것 같아요

👏1.왜 소통과 협업이 중요한가에 대해

우선 개선할점에 대해 작성해보기 전에 소통,협업이 왜 중요한지 생각해 봐야할 것 같다.

사실 이전에 항상 협업,소통,문서화 이런 부분들이 아주 중요하다고 들었을땐 이런생각을 했었다. 코드만 잘치고 서비스만 잘 완성하면 되는거 아니야?
제일 중요한건 서비스의 완성이고 소통,협업 이런것들은 그것을 위한 수단 아닌가라는 건방진 생각을 했었지만 이런생각이 이번 프로젝트에서 어려움을 만드는 원인을 만들었다고 생각한다.

이번 프로젝트를 진행할때만해도 드디어 내실력을 보여줄때야!!라는 기대감에 들떠 시작을 했다. 하지만 얼마 가지 않아서 몇가지 의견다툼이 생겼다.

회고를 작성하며 생각해보면 팀원모두 더 좋은방향이라는 하나의 목표를 공유하지만 서로 생각하는 방식이 다르기에 의견충돌이 생겼고 이를 해결하기 가장 좋은 방법은
효과적인 소통임에도 그것이 잘 이뤄지지 않았다는 생각이든다.

이에대해 다음 내용들을 보며 좀 살펴보려한다.

👏2.글로 작성해보는 것은 어떨까?

첫 의견 충돌

사실 이전까지 프로젝트에서는 이렇게까지 의견충돌을 해본 적이 없었다.
첫 의견충돌의 발생은 바로 기능먼저 vs publishing먼저에서 Jeff님과 의견 충돌이 있었다.

개인적인 생각으로는 이제 충분히 연습을 해봤으니 publishing을 우선 진행하고 기능을 해도 시간이 충분하다는 생각이있었다.

이에 반해 Jeff님은 그동안의 시행착오를 바탕으로 기능을 먼저 완성하고 publishing을 진행해야 시간내로 완성할 수 있다는 판단을 하셨다.

이유가 뭘까?

첫 대면회의에서 이와같은 의견충돌이 발생했고 그 당시에는 서로 가장 중요한 왜에대한 이유는 서로 제시하지 않고 각자의 그림을 그렸기때문에 좀 큰 의견대립을 겪었던것 같다. 그래서 어느 순간 논점을 벗어난 감정만을 앞세운 토론을 했다고 생각한다.

그 후에 비대면으로 각자의 의견을 한번더 얘기해볼 시간이 있었는데 왜에 대한 이유를 글로 적어서 읽어보니 충분히 납득할만 했고 이를 적용해서 충분히 만족할만한 결과를 얻어낸것 같아서 좋은의견을 내주신 Jeff님 덕분에 좋은 경험을 하게됐다.

이번 경험을 바탕으로

이렇게 지나고보니 이번 의견충돌의 문제점은 바로 각자가 생각하는 방향을 충분히 설명해주지 않았던 것이 원인이 아니었을까? 라고 생각이된다. 결국 두 의견 모두 효과적인 진행 방향에대한 같은 목적을 가지고 있음에도 각자의 그림을 그렸기 때문이고 이런 내용을 소통을 통해 해결했으면 쉽게 넘어갈 문제였지만 그렇지 못했다고 생각한다.

앞으로의 프로젝트에서도 이와같은 문제가 생긴다면 다음의 방식으로 해결해보려고 하면 좋을것같다.

1. 구체적으로 왜에대한 이유를 제시해본다.
2. 각자 생각하는 바를 글로 적어보자.

상대방을 설득하기 위해 왜 에대한 것을 납득시키는 것이 가장 이상적인 방향이라고생각한다. 그렇기때문에 내가 생각한것에 왜라는 이유와함께 의견을 제시해보는 것은 어떨까?

때론 말로 하는 것보다 글로 적어서 의견을 어필하는것이 효과적일때가 있다.
말로하다보면 정리되지않은 생각을 전달할수도 있고 그렇기에 논점을 벗어난 대화로 이어질 가능성이 있다.
각자의 의견을 글로 적어서 팀원들과 공유한다면 의견을 제시하는 사람도 논리적으로 글을 작성할 수 있고 팀원들도 차분하게 내용을 받아들일 수 있을 것이라고 생각한다.

😎3.더좋은 의견이 있다면 설득해보자

아무래도 프로젝트 경험이 부족하다보니 어디까지를 팀원들과 의견을 나눠야할지 좀 서툴렀던 부분이 있다. PR과정 중에 있었던 일을 예로 알아보자.

너무좋은 아이디어이지만 공유했다면 더 좋았을것 같아요

프로젝트의 진행과 동시에 모비에서는 쏙쏙들어오는 함수형 코딩이라는 책을 읽고있었다.
해당 책에서는 클린코드에 관한 내용을 다루는데 한 PR에 이를 적용한 PR이 올라온 적이 있었다.

배운것을 적용해보고 시도해보는 과정은 언제나 긍정적이고 좋은 방향이라고 생각한다.
여기서 한가지 얘기하고싶은 것은 팀프로젝트이기에 해당내용이 팀원들과 잘 공유되었나
에 관한것이다.

어느순간 올라온 PR에서 클린코드를 적용한 것을 확인했을땐 PR을 올려주신 분이 앞으로 클린코드를 작성하는 방향으로 프로젝트를 하자고 제안하는것인가? 라는 의문이들었다.

같은 책을 읽은 상태이기 때문에 클린코드를 적용했다는 것은 당연히 알아챘지만
나도 클린코드를 적용해서 PR을해야하는가?에 대한 언급이 없었기 때문에 어떤 방향을 원하는지 정확하게 파악못했던 일이 있었다. 이에 대해 다음과 같은 리뷰 를 작성했었다.

이 PR이 올라올때쯤에 아무래도 모두 너무바쁘고 완성이라는 하나의 목표만을 향해 달려가던 와중이라 이런부분을 생각하지 못하고 지나갔을거라고 생각한다.

위와같은 리뷰를 작성한 나또한 이전 PR들에서 팀원들에게 내 의견을 충분히 전달했는가? 라는 질문에 그렇지 못했다라고 대답할 것이다.
예시를 위해 이런 에피소드를 소개했지만 나도 충분히 의견을 제시하지 않고 팀프로젝트에 내 의견을 반영해서 올린 적이 있을것이다.

아마 이전에 내 PR에 이런것들좀 미리 설명해주면 좋았잖아요라는 부분이 없었던 것은 팀원들이 배려해준것이 아닐까라고 생각한다. 죄송합니다 ㅜㅜ 앞으로 주의할게요😘

앞으로는?

이런 경험을 바탕으로 앞으로 더 좋은 의견이 있다면 팀원들에게 모두 공유를 하고진행하면 좋을 것 같다.

PR에 좋은 의견을 적용한 코드와 함께 이런것을 적용해봅시다!라는 의견을 남기거나
혹은 회의,문서로 팀원전체와 공유하는 과정이 있다면 좋을 것이다.

😎4.앞으로 이렇게 하면 좀더 좋을것 같아요

위에서 언급했던 내용들 모두 소통이 조금 부족했기 때문에 생긴일들이라고 생각한다.
아직 경험이 적기에 완벽한 설계를 못했고 추가되는 사항들, 의견들에대해 의견을 나눌시간을 정해뒀다면 더 효율적이었을것 같다.

소통,협업은 프로젝트 진행과정 중에는 PR과 직결된다는 것을 이번 프로젝트를 통해 많이 느꼇다.
이번에 좋았던내용, 부족했던 내용들을 참고해서 앞으로 PR을 소통의 도구로 활용한다면
개선의 여지가 있을것 같다.

또한 바쁘더라도 주에 2~3회 의견을 나눌 시간을 꼭 가져보는 것이 좋다고 생각한다.

🙌이런점은 다음에 시도해보면 어떨까?

🤣1.맘에안드는게 있으면 얘기해!

이전과 다르게 조금더 많은 일들이 있었다.
처음으로 완성을 목표로한 프로젝트였기 때문일까?? 모두 바쁘고 예민한 부분이 있었다.
처음으로 팀원들과 조금 격한? 대화도 해보고 어쩌면 감정이 상한 부분도있었을 것이다.

불만사항

프로젝트의 마무리쯤에 팀원분과 이런 대화를 한적이 있었다.
난 솔직히 팀원분들이 나에게 어떤것을 원하는지 모르겠다..!라는 얘기로 불만사항에 대해 얘기를 하셔서 이에대해 대화를 나눈 일이 있었다.

솔직히 말해서 프로젝트를 진행하며 완성이라는 것에 너무 집중한 나머지
팀원들의 컨디션,감정들을 깊게 생각못하고 가다보니 쌓인것이 폭발했을 것이라고 생각한다.

이럴땐 대화로 꼭 풀어야한다

이에대해 서로 생각했던 부분들, 부족했던 부분들에 대해 솔직하게 얘기하고 앞으로의 진행방향에 대해 대화를 나눴다.
그 동안 오해의 소지가 있었던 부분들에 대해 다 설명하고 그 과정에서 잘못된 부분들은 분명히 사과하고 앞으로 이렇게 진행하면 좋을것 같아요~라는 말과 함께 잘 해결하고 대화를 마무리 지었던 기억이있다.

개인적으로는 그렇게 말을꺼내주셔서 오히려 고마웠다. 불만사항들을 표출하기까지 힘들었을탠데 용기내서 얘기해주신 것이 고마웠다.

나도 프로젝트중에 불만들이 있었지만 이런 얘기를 꺼내면 감정이 상하진 않을까? 고민되고 그런것들을 담고가자니 답답하고..... 고민되는 부분이 있었다.

이런것을 적용해보면 어떨까?

이런 일이 있을 수 있기때문에 1주에 한번 혹은 2주에 한번 불만사항을 얘기해보는 시간을 가지는 것은 어떨까?

아무래도 민감한 사항이기에 잘못얘기했다가는 싸움으로 번질 수 있기때문에 규칙을 정해서 진행한다면 효과적일 것 같은데

1. 서로의 잘못보다 각자 본인의 잘못을 돌아보는 시간이라고 생각해보자.
2. 불만사항에 대해 들었음에도 이건아니다 싶으면 글로 작성해서 다시 서로의 글을 읽어보자.

이런 약간의 규칙을 세우고 진행한다면 오히려 감정상하는 일 없이 원활한 진행이 되지않을까?

🙌2.기다려!

첫 의견충돌후 운영진분께 이런 질문을 한적이 있었다.
Q : 팀원들과의 충돌이 있을때는 어떻게 해결하셧나요?
이에대해 답변해주신 부분을 이번에 최대한 지키려고 노력했었는데 바로 이것이었다.
A : 우선은 상대방이 말을 다끝낼때까지 들어주세요~

이전까지 의견을 나눌때 대화도중 이건아닌데 라는 생각이 들면 중간에 말을 끊고 들어간 적이 많았던것 같다.
이렇게 대화를 하면 상대방도 답답한 부분을 말하고싶어서 마음이 급해지고, 중간에 끊고 들어간 나도 급하게 얘기를해서 심해지면 자존심싸움으로도 번지는 일을 경험했었다.

방금전 언급했던 에피소드에서는 조언을 들었던것을 바탕으로 불만사항에대해 모두 얘기하실때까지 기다렸다가 내 의견을 전달해봤다. 확실히 상대방에게 모두 말할 시간을 주고, 나 또한 그 사이에 좀더 차분하게 생각을 정리해서 의견을 전달하다 보니
차분한 대화를 이어갈 수 있었고 이전보다는 안정적인 대화흐름을 경험한 것 같다.
(하지만 중간중간 또 끼어든 적이있습니다.. 죄송합니다..)

앞으로는?

앞으로는 팀원들과의 소통에서 이런 방식을 적용해보면 어떨까?

팀원1 : 제 의견은 ~~~ 합니다.
팀원2 : 의견제시는 다 하신건가요? // 질문을해서 답을 받아보자
팀원1 : 네!
팀원2 : 이렇게 말씀해 주셨는데 제 의견은 이렇습니다~

모든 의견제시에서 이 과정을 지킨다면 좀 답답하겠지만 아이디어 회의, 코드에대한 의견 같은 부분들은 이런 방식을 적용해보면 좋을것 같다.

📃마치며...

회고를 진행하며 더많은 것들이 떠오르지만 너무 길어지는 감이 있어서 몇 가지만 작성해봤다.

사실 이렇게 다 작성하고보니 의욕이 너무앞선 나머지 중요한 것(팀원들의 감정)을 우선시 하지 못하고 한가지 목표에만 너무 몰두했던것 같아서 굉장히 미안한 감정이 든다.

회고이지만 사실 반성문 이라고 하고싶은 심정이다. 이번 프로젝트에서 느꼇던 PR의 중요성 소통의 중요성을 이제서야 절실하게 느낀다는 것은 그 동안 팀원들이 나를 많이 배려해줬기 때문이라 생각한다. 이번 회고에 꼭 팀원들에게 사과를 전하고싶다.

그 동안 상처가 되는 말이나 행동들을 견뎌준 팀원들에게 감사하고 앞으로 신경쓰겠습니다!

이렇게 지난 프로젝트를 마무리하며 회고를 한것을 바탕으로 다음엔 더좋은 결과가 있기를 바란다.

수고하셧습니다~👍