Reminding : Webserv

웹서브의 마지막 후기 글. 이번에는 ‘실패’와 ‘성공’을 곱씹어 보려고 한다.

Webserv 1.0의 실패 = 신뢰감이 떨어지고, 팀은 부숴졌다.

사실 이 내용을 적는 것이 옳은가? 하는 생각을 조금 해보았다. 나에게 이것을 곱씹는 것이 도움이 될까? 라는 생각을 잠시 해보았다. 이윽고 내 머릿속에 남겨진 말은 ‘그럼에도 불구하고 가치있는 작업이다’ 라는 생각이었다. 나의 부족함을 드러내는 것일 수도 있으며, 잘못 적으면 오해가 될 만한 부분이라고 생각도 든다.

하지만 그런 것들이 부끄럽거나, 그저 포장만 잘해서는 진짜 객관적 성장을 이루는 것은 불가능하다는걸 몸소 지금껏 느껴오지 않았는가? 더불어 내가 부족했던 점에 대해서도 좀더 고민을 해봐야 한다고 생각했다. 왜냐면 실패기의 과정에서 나는 상당히 열도 받았었고, 어이가 없었기에 결국 박차고 일어나 새롭게 팀을 구했다. 하지만 거기서 더 좋은 방법이나, 더 현명한 해결책이 있었을지 누가 알겠는가?

처음 웹 서브를 시작하면서, 스터디를 모집했었다. 정확히는 나에게 같이 하자는 다소 커뮤니케이션 능력이 떨어진다고 해야할까? 조용한 한 친구가 같이 하기를 요청했었다. 그의 실력은 충분히 잘 한다는 것을 알고 있었고, 나 역시 그를 통해 배운게 한 둘이 아니었기에 이번 스터디와 프로젝트 역시 그를 통해 많이 배워야 하겠다는 생각을 갖게 되었었다.

그가 팀장이되고, 우리 팀은 1달이라는 시간 동안 정말 열심히 웹, HTTP, 서버의 개념을 파악해 나갔다. 무얼 준비해야 하는가. 무얼 고려해야 하는가. 설계 하나하나가 매우 유익했고, 팀의 분위기는 괜찮았다.

그런데 문제는 그 뒤에 조금씩 서서히 찾아왔다.

가장 애매했던 점은, 팀 내에서 리딩을 하려는 사람들 사이에 의견 갈등이 있었다. 예를 들면 나는 업무 처리 방식에 있어서, 설령 수정을 하더라도 데이터 구조라던지 함수 로직을 일단 부족해도 확정 짓고 가기를 원했다. 왜냐하면 2번 일을 하는게 실패-개선 의 루트라면 배울 것도 있고, 그 과정이 지루하게 느껴지지 않았다.

하지만 팀장과, 또 한 명의 팀원은 일단 무조건 시작부터하고 안 맞으면 그때 그때 수정하길 원했다. 이해가 되지 않는 부분은 그냥 일단 무시하고 달리길 바랬다. 팀장 자체가 공통과정을 빨리 돌파하려는 마음이 강한 사람이라는 것은 알고 있었지만, 그런 방식으로 자꾸 하려고 할 때면 상당히 곤란한 부분이 발생했다. 왜냐면 서로 다른 생각으로 파트를 짜버렸고, 그러니 일이 이중 삼중인데, 막상 고쳐도 확실한 개선이 된게 아닌, 그냥 누벼놓고 다시 테스트를 돌려야 하는 상황이니 팀 내에 불만이 쌓이기 시작했다.

결정적으로 두 차례의 사건이 팀이 분해되는데 핵심적인 역할을 했다. 터지기 직전, 나는 소통이 안되거나 리딩을 원하는 사람이 주변에 신경을 안 쓰는 이런 상황이 터지면, 나중에 신뢰에 금이 갈거라 판단이 들었다. 왜냐면 신뢰, 믿고 맡긴다는 행위는 팀 전체의 의욕을 유지하는데 있어 상당히 중요한 부분이기 때문이다. 책임감을 고양시키거나 하락시키는건, 결국 믿고 맡길 수 있냐 없냐의 문제며, 실수를 하더라도 맡기는 것으로 성장이 되어야 한다고 나는 내 나름의 경험적 신념을 갖고 있었다.

그런데 리딩을 하겠다는 팀원 한명과, 소통을 해서 진행하기보단 혼자 묵묵하게 하고 있는 팀장은 또 어떻게 그 둘은 마음이 맞았는지, 다른 사람의 파트를 다 뒤집어 엎어 놓는 일이 벌어졌다. 문제는 그걸 그렇게 바꾸면서 무리를 해서 아프다고 그 다음날 나오지도 않았고(이 부분이 가장 충격이다 😅), 바꾼 것 역시 잘못 바꾸었기에 원래 담당자가 해당 부분을 다시 수정하는 일이 벌어졌다.

그 뒤 팀의 생명을 끊은 사건은, 그 뒤에 전체 파트 나눈 것을 합치는 브리핑을 하는 날이었다. 이번엔 팀장이 아무런 말도 안하다가, 나의 파트 GET 메소드 파트를 보여주고 리뷰를 해야 하는데, 자기의 메인 로직을 보여준 뒤 갑자기 자기가 만든 GET을 보여주고 입을 닫아버렸다. 처음엔 정말 황당했다. 그 뒤에 다시 물었다. 내 역할이 GET 메서드의 구현이 아니었나? 왜 내가 만들어야 할 부분을 당신도 추가로 만들었는가? 거기서 그는 지금껏 어떤 표현도 하지 않다가, 자기가 원하는데로 GET을 만들지 않았다고 이야기를 했고, 팀은 박살이 나버렸다.

GET을 만든다고 해도, 내게 맡은 바, 시작부터 마지막까지의 로직을 고려해야 했다. 따라서 나는 그저 로직의 간단한 부분만 만들수도 없는 노릇이었다. 리더가 원하는 부분도 전부 고려한 상태였다. 심지어 만들어 놓고 시간이 남아서 할 수 있는게 없는 상황이었다. 나에게 말 한마디라도 해줬다면, 그리고 내용을 조금만 뜯어보면 원하는 요구사항대로 다 구현이 되어 있었음에도, 팀원의 코드를 하나도 보지 않았고 그저 자기 원하는 코드가 아니라는 이유로 자기의 코드를 만든 뒤 그걸 먼저 보여주면서 이걸로 하자- 는 식의 표현이었다. 당연히 불만은 폭발했고, 팀은 더 이상 6명 전원으로 뭉치지 못했다.

참.. 적으면서도 부끄럽기도 하고, 화도 난다. 그리고 참 아쉬웠다. 실력 좋은 사람들 끼리 모였던 팀이었다. 정말 열심히 준비했었고, 서로 머리를 마주하고 괜찮은 결과물이 나올거란 기대감이 있었다. 하지만 그것이 단 두명의 행동에서 박살나버렸고, 결국 그 과제팀에서 나온 나는 아예 다시 팀을 꾸리게 된다. 뿐만 아니라 결국 그 팀에 남은 사람들은 정상적인 방식도 아님에도 어거지로 구동시킨 서버를 만들어 통과를 했고, 그렇게 통과한 팀원 중 일부는 현재 다시 그 과제를 하겠다 하고 있다.

나는 이번 1.0의 실패가 누군가의 탓으로 돌리는 것으로 귀결하면 안된다는 생각한다. 이 글을 이렇게 적게 된 것도 사실 그런 의미를 갖고 있다. 그때 내가 할 일은 없었던 것일까. 그런 상황에서 결국 어쩔 수 없이 커뮤니케이션을 기피하던 팀장은, 혼자만의 불만으로 신뢰를 박살내는 행동을 했다는 사실은 분명히 있지만, 그럼에도 내가 개선하거나 그런 상황을 바꿀 물고를 틀 방법은 없었을까? 하고 고민을 하게 된다.

명색이 심리 상담사를 하기도 했고, 나이도 찰만큼, 경험도 찰 만큼 했는데 참 아쉬운 영역이다. 한 가지 확실한 점은 있다. 소통이라는 것이 안되는 사람이라고 한다면, 내가 먼저 나서서 소통도 했어야 한다는 점만큼은 확실히 머릿속에 남는다. 20대 초반의 어린 리더. 리더는 어려운 말은 하지 못했고, 특히나 다양한 사람들이 모여 있으니 더더욱 불만이나 어려움은 있었을 것이었다. 그런데 그때 나의 행동을 곰곰히 생각해보면 나 역시 어지간히 알겠지~ 라는 다소 편안한 마음으로 소통에 있어 노력을 많이 하진 못했던 것 같다. 팀워크, 협업, 정말 어려운 일이 아닐 수 가 없다.

Webserv 2.0의 성공 = 소통, 협업, 약속

그렇게 팀이 와해가 되고, 나는 떨어져 나와 몇 일간은 정말 힘들었다. 멘탈이 갈린다는 말을 오랜만에 써봤다. 2달 안에 해결하고 싶었지만 그러지 못했단 사실과, 커뮤니케이션 능력이 부족하다 아니다를 떠나, 내가 노력할 수 있는 부분이 제대로 안 된 것 같다는 생각에 너무나 아쉬운 순간이었다. 그렇게 화도 뒤섞이니 나중엔 “그냥 나 혼자 할까?” 라는 이상한 독기까지 생기면서 서버의 기초 로직 설계와 config 설계를 진행했다.

그 뒤 멘탈을 회복하고, 나는 독불장군이 되어선 안되지- 라는 생각과 함께 팀원을 모으기 시작했고, 다시 스터디를 열고, 팀원들과 함게 프로젝트를 재정비하기 시작했다. 이 과정에서 내가 가장 생각한 것은 ‘팀원들의 실력’이 아닌 ‘팀원들의 소통능력’ 또는 ‘협조성’이었다.

그렇게 사람을 찾았고, 컨벤션을 준비하고 GitHub에 브랜치 전략을 설정하고, 가능한한 소통이 가능한 구조를 만드려고 노력했다. 예를들어 1,0 때는 리뷰를 요청해도 사실상 아무도 평상시에 리뷰를 해주지도 않았고, 내용을 보지도 않았다. 모였을 때 그제야 부랴부랴 하는 느낌이었다면, 이번에는 slack에 ‘잠깐’ 이라는 키워드를 외치면, 반드시 해당 글에는 이모지를 달아주도록 했고, 그 내용에 해당하는 사람이면 댓글을 달도록 하고, 리뷰도 그런식으로 하도록 시스템화 시켰다.

또 한 번은 아무리 잘 모아도 상극인 사람들이 있었고, 둘의 갈등의 골이 심화 될 때, 가능한 중간에서 제재를 하는 것은 아니지만, 상한 감정골의 내용을 듣고, 가능하면 부딪히지 않을 환경을 조성하려고 노력했다. 그 과정에서 오히려 내가 욕을 먹기도 했지만, 결론적으로 그렇게 처리되고 나서 양쪽 모두 감정적 회복이 일어났다. 이후 둘의 효율이나 적극성이 훨씬 나아진게 보였다.

결국 이런 환경이 되고나니 생각 이상으로 놀라운 일이 생겼다. 전 팀에서 42 서울의 기수 별 탑티어가 몇명이나 있었음에도, 그보다 객관적인 지표면에서는 못한 분들, 그런 나였지만 오히려 복잡한 로직을 잘 소화시킬 수 있었다. 성능도 준수했으며, 무엇보다 디버깅 과정을 통해 잘 마무리 지을 수 있었다. 깃허브에서의 소통이나 문제를 해결해나가는 속도도 월등히 빠름을 느꼈다. 분명 기술적, 능력적 차이는 있었음에도 그 차이를 넘어서는 결과를 얻었고, 양 쪽을 다 경험해본 내 입장에선 뭔가 ‘대단하다’고 느꼈다. 두 번째 팀은 오히려 나에게 신선한 충격이기도 했으며, 동시에 세상 일이 절대 능력으로만 돌아가지 않는 이유를 보여주는 경험이었다.

물론, 아쉬움이 없었냐? 그렇진 않았다.

우선 여전히 소통하는 면에서 뭔가 매끄럽게 이야기가 잘 전달되진 않았었다. Request 파트나 GET 파트의 경우 로직의 이해를 위한 소통이 부족해 다른 파트와는 전혀 다른 방식으로 할당을 관리하거나, 이벤트를 등록했다가 나중에 되어서야 왜 안되는 지를 깨닫고 수정하게 되었었다. 설명을 해준다고 했음에도 여전히 오해는 존재했던 것이다.

뿐만 아니라, HTTP/1.1 규격에 어느정도 맞추긴 했으나, 팀원들의 인내심, 이루고자하는 목표를 좀더 디테일하게 잡아줬어야 했지만 그렇지 못했고 결국 마지막에 가서는 다소 급하게 마무리를 지은 감이 없지 않아 있었다.

또한, 코드적으로 보았을 때는 클래스 설계한 내용 외에 추가적으로 필요한 부분들을 역할을 정확히 나눠서 적용시키더라도 통일감을 유지 했어야 하는데, 그렇지 못했던 점은 코드의 가독성을 다소 약화시켰던게 아닌가 생각이 들었다. 뭔가 마무리를 지으면서도 ‘한끗’이 부족했구나를 느끼는 순간이었다고 생각이 든다.

After Webserv

웹서브라는 과제는 정말 재미있었다. backend라는 분야를 가고 싶다는 확신이 들게 한 과제였고, 동시에 좀더 디테일한 , 좀더 제대로된 서비스를 구축해보고 싶다는 생각을 할 기회였다.

뿐만 아니라 실패를 경험하다보니 1달이나 프로젝트를 달성한 꼴이 되었으나, 그럼에도 소통의 중요성, 소통이 잘 되면 될수록 사람의 인적자원은 살아나며, 제아무리 능력 좋은 사람이 몇명이 모여도, 소통이나 신뢰감 형성이 어긋나면 팀은 곧 와해되거나 갈등의 골에서 못 헤어나오는 구나- 라는 사실을 새삼 느낄 수 있었다.

비록 내 실력이나, 남의 실력, 이런 객관적 지표도 중요하지만 결국 팀이라는 것은 개인 그 이상의 공간이라는 점을 새삼 느낀 프로젝트였다. 이제 정말 마지막, 트렌센던스 과제는 또 얼마나 우당탕탕 해결을 해 나갈지 기대 반, 걱정반, 설렘반(150% 정도 되는듯)을 학습을 해봐야 할 것 같다.