프로젝트 2주차 KPT : 나는 혼자가 아니다

1. 혼자 가면 빠를 순 있다.

 

1주차 회고에서 깨달음을 얻었음에도 불구하고, 인간은 역시 망각의 동물인가 갑자기 변하기는 쉽지가 않다. 이유는 아래와 같다.

 

발단

내가 맡은 페이지는 피그마에서 미처 만들어두지 않은 페이지(회원 탈퇴 등..)였다.

• 늘 극한의 효율을 추구해왔던 나는, 무에서 유를 창조하는 디자인을 하면서 공통된 디자인도 그렇고, 정말 사소한 요소들(회색 글자를 hover했을 때 글자 색)에 대해 정말 아무런 고민도 없이 휘리릭 CSS 처리를 해버렸다.
• 주말에 작업해서 팀원들을 호출하기 미안한 것도 있었으나, 그렇게 하는 것이 일처리에 있어서 효율적이었던 것도 있었다.
• (물론 피그마 작업에 인터렉티브 효과까지 있었으면 기획 단계에서 논의가 다 끝나는 문제였겠지만 아쉽게도 우리는 그렇게까지는 하지 않았다.)

 

그리고 나는 혼자가 아니다.

 

사건

그리고, 내가 임의로 처리한 CSS 효과에 대해서 나의 PR을 들락날락 거려야 하기 때문에 번거롭다는 피드백을 받았다.

• 물론, PR 내용에는 디자인이나 문구에 대해 피드백 부탁드린다는 말을 써놓았지만, 내가 진짜 했어야 하는 요청은 임의로 디자인한 페이지에 대한 전체 회의 였던 것이다.
• 그뒤, 전체 회의를 통해 정말 사사로운 부분들까지 팀원들과 협의 하에 결정하게 되었다.

 

깨달음

아, 이게 바로 팀 워크구나. 내가 한 달 동안 체화하고 습득해야 하는 팀 정신이구나!

• 이론적으로는 알지만 체화되지 않았던 팀 플레이어로서의 기본 정신을 깨달을 수 있었다..!
• 그 뒤부터는 공통적인 부분이 있는 경우, 무조건 팀원들과 의논하고 진행하고자 노력했다.

 

2. 때로는 효율적이라고 생각한 방법이

 

발단 

우리 팀은 24시간 채팅이 워낙 활발하여, 굳이 회의를 해야할까? 라는 생각이 문득 들었다.

• 프리 프로젝트 회고 때 어떤 분께서 우리 팀에서 좋았던 부분에 대한 이야기를 하면서 필요할 때만 회의가 열렸던 시스템이 좋았다, 라고 말한 것이 기억이 났다.
• 따라서 현재 팀원 분들께도, 정기적인 전체 회의는 생략하고 필요할 때만 회의를 진행하는 것이 어떨까요? 라고 물었다.
  • 이미 프론트엔드끼리, 백엔드끼리, 그리고 기능별로 페어로 지정된 프론트~백 팀원끼리 소통이 원활했으며 이 경우 ‘굳이 형식적인 전체 회의가 필요한 것인가?’ 라는 생각이 들었기 때문이다.
  • 모두가 위의 맥락에서 찬성을 했으며 그 후부터 매일 회의는 진행되지 않았다.
  • 나는 그 방법이 제한적인 리소스를 사용하는 데 있어서 효율적인 방법이라는 생각이 들었다. 🚩

 

비효율이라는 결과를 낳기도 한다.

 

문제 

결과적으로 우리는 소통이 부족했다.

• 그렇기 때문에 시간이 속절없이 지나고 나서야 진행 상황이 더디구나, 정도만 생각했던 상황들을 정확히 어떤 이슈가 있었고 이러한 이슈 때문에 리소스를 의미없이 잡아먹고 있었다는 것을 전달받게 되었다.
• 이슈의 내용은 백엔드에서 merge를 할 때마다 클라이언트 코드가 충돌이 난다는 것이었다.
• 반성할 점은 저번에 백엔드 채팅방에서 잠깐 이런 내용이 나왔던 것 같은데 그 뒤 별 이야기가 없어서 해결됐겠거니, 하고 지나쳤던 점이다.

 

그뒤에는 그저 백엔드에서 공통 코드를 합치는 과정에서의 문제가 있는 줄 알고 쉽게 물어보지는 못했다.

• 알고 보니 클라이언트 충돌 문제는 3~4일 동안 지속 되었고, 해당 팀원 분들은 그 이슈를 해결하기 위해 다양한 시도를 해 본 상태였다.
• 코드를 작성하는 시간보다 남의 코드 충돌을 해결하는 것에 시간을 쓰고 있었던 것이다..

 

깨달음 

형식적인 정기 회의가 없어 효율적이라고 생각했던 것이 오히려 비효율의 결과를 낳았다.

• 채팅으로 할 수 없는, 스몰톡으로 간간히 실시간 대화로 해결할 수 있을 법한 문제들을 우리는 지나치고 있었다.
• 그냥 흘러가듯, 오늘 어떠셨어요? 어떤 이슈가 있었나요? 할 때 기록에 남는 채팅이나 글로 쓰지 못하는, 쓸 생각 조차 못하는 정말 사소한 이야기들을 우리는 하지 않고 있었다.
• 때로는 그런 사소하고도 사소한 말의 뉘앙스나 단어에서 이슈를 감지하고 사사로운 꼬리 질문을 하며 문제를 인지할 수 있다는 것을 그 때의 우리는 알지 못했다.

 

3. 그리고 함께이기에, 이겨낸다.

 

문제를 알게 된 시각은 오후 11시. 나는 긴급회의를 소집했다.

• 백엔드 쪽 이슈를 인지하고, 프론트엔드에서 해당 이슈 전달을 위해 회의를 진행했지만 빠르게 백엔드 팀원 분들께서도 회의를 끝내시고 바로 합류해주셨다.
  • 덕분에 바로 전체 회의로 전환하여 문제 해결에 대해 디테일하게 고민해볼 수 있었다.
  • 팀원 분들께서도 너무나 적극적으로 회의에 참석해주셨으며 문제 해결에 대한 다양한 방안을 고민하기 시작했다.
  • 이 때, 백엔드 멘토님이셨던 아서님께서도 새벽까지 계속 들락날락거리며 백엔드 쪽에서 이슈 해결을 위한 조언을 정말 많이 해주셨다.

 

문제는 깃헙의 브랜치에서 백엔드 코드와 프론트엔드 코드가 뒤엉켜 있는 것이었다.

• 정석대로라면 레포지토리를 분리하여 따로 진행하는 것이 맞지만, 부트캠프 측에서 하나의 레포지토리를 줬기 때문에 같이 진행할 수밖에 없었다.
• 그리고 우리는 trunk 전략을 사용하고 있었기 때문에 중간 브랜치는 해당 기능을 맡은 프론트와 백엔드가 공유하고 있었다.
• 정확히 어떤 부분에서 충돌 문제가 시작되었는지 아직도 알지는 못 하지만 중요한 것은 여기서 가장 효율적으로 문제를 해결하는 방법이 무엇인가? 를 빠르게 결정을 내려야 한다는 것이다.

 

이 과정에서 아서 멘토님께서 정말 좋은 말씀을 주셨는데, 중요한 건 ‘문제를 해결’하는 것이기 때문에 최소한의 리소스로 최대한의 효과를 내는 방법이라면 그게 논리적이지 않고 물리적인 방법이라도 좋은 방법이고, 그렇기 때문에 기피해야 할 이유가 전혀 없다는 것이다.

 

회의는 새벽 2시까지 이어졌으며, 결국 프론트와 백에서 작업 브랜치를 아예 분리시켜 코드 충돌을 막는 방법으로 결정되었다.

• 브랜치 분리 작업 속에서 특히 깃 데스크탑을 사용하시는 H님의 대활약으로 무사히 문제를 해결할 수 있었다. (틈새 깃 데스크탑 영업을 계속 하셨다ㅋㅋㅋㅋㅋㅋㅋㅋ)
• 다시 말해, 브랜치 전략을 우리 팀의 상황에 맞게 살짝 바꿨고, 현재까지의 순항 중이다.
• + (이후에 브랜치 전략을 아예 깃플로우로 또 바꿨다..ㅋㅋ) ← 따로 쓸 예정

 

장난스럽게 집단지성의 힘! 이라고 종종 얘기 하지만 정말 그렇다.

• 적극적으로 백엔드 쪽에서의 의견을 개진해주신 Y님,
• 다른 팀원 분의 문제를 해결하기 위해 힘써주신 백엔드 팀원 Y, J, H님 (이름 순입니다ㅎㅎ)
• 안정 지향적으로 리스크를 줄이기 위한 많은 의견을 제시해주신 E님,
• 논리 & 물리적으로든 자유자재로 문제를 해결해주신 깃헙 데스크탑 소유자, H님

 

모두가 한 마음 한 뜻으로 문제 해결에 진심 이었기에, 함께이기에 힘을 내서 이겨낼 수 있었다.

• 생애 2번째 프로젝트가 말 그대로 우 당 탕! 탕! 굴러가고는 있지만 중요한 것은 나는 혼자가 아니다.
• 함께 이기에, 이겨낼 수 있는 것이다.