우아한테크코스 7기 레벨 3 회고

너무나도 바빴던 레벨 3가 끝났다.

6기 선배들이 "오늘이 가장 한가한 날이다"라고 말했던 이유를 체감했던 레벨이었다. 명언이다.

 

 

좋은 팀 만들기

프로젝트 초반, 우리 팀은 8인 페어 회의를 했다.

※ 충격 주의!: 8인 페어 회의란, 여덟 명이 전부 의견이 맞아야 다음 안건으로 넘어가는 회의 방식을 말한다.

 

 다들 프로젝트에 진심을 다했고, 열정이 넘쳤다. 그러다 보니 자연스럽게 각자의 의견을 내세우고, 어떻게든 다른 팀원을 설득하려 했다. 나 또한 마찬가지였다.

 

 시간이 흐를수록 무언가 잘못되었다는 것이 느껴졌다. 결국 데모데이 3일 전에야 겨우 기획을 마쳤고, 남은 3일 동안 밤샘 개발을 해야만 했다. 프론트엔드 팀원들은 24시간 카페에 모여 개발하다가 찜질방에서 쪽잠을 자고 출근할 정도였다.

 

 반복되는 자기주장은 회의를 '힘든 시간'으로 만들었다. 모두가 자신의 주장만 고집하면 어떤 결정도 내릴 수 없다는 것을 깨달았다. 우리는 이 문제를 해결하기 위해 함께 머리를 맞대고 두 가지 규칙을 세웠다.

좋은 팀이 되기 위해 세운 규칙 1

 기획을 각 파트별로 나누고, 해당 파트의 결정사항을 존중하기로 했다. 각자 맡은 부분에 책임감을 가지고 개발하니 불필요한 논쟁이 줄어들고 작업 효율이 크게 올랐다. 다른 파트의 의견에 자신의 의견을 고집하기보다는, 의사결정 이유를 묻고 개선점 정도만 제시하는 방향으로 나아갔다.

좋은 팀이 되기 위해 세운 규칙 2

회의 시간에 서로의 주장을 내세우며 과열되지 않도록 진행자, 타임키퍼를 도입했다.

 진행자는 회의의 전체적인 흐름을 맡는다. 중앙 제어 시스템을 통해 모두가 공평하게 의견을 낼 수 있도록 하기 위함이다. 회의가 과열된다 싶으면 진행자가 막는다.

 타임 키퍼는 전체 회의 시간을 관리하며 회의가 늘어지는 것을 막는다. 또한, 특정 안건이나 논의가 길어지면 시간 초과를 팀에 알리고 정리나 결정을 유동한다.

 

 회의에서 역할을 가지니 회의 진행이 매끄러워졌고, 의견 충돌로 인한 회의 과열이 거의 없어졌다. 역할과 책임이 있으니 서로 존중해 주는 우리 팀이 좋았다.

 무엇이 문제인지 적극적으로 고민하고 함께 해결책을 찾아낸 덕분에 회의가 더 이상 부담스럽게 느껴지지 않게 되었다.

 

 

우선 동작하는 코드를 작성하자

 팀 프로젝트를 시작하기 전, 스프링 MVC 코드를 파헤치며 객체지향 설계의 우아함과 아름다움에 푹 빠져 있었다. 레벨 1, 2를 거치며 습득한 객체지향 설계를 프로젝트에 적용시켜 보고 싶었고, 우아한 코드를 작성하고 싶었다.

 

 하지만 팀원들의 생각은 나와 달랐다. 객체지향 설계보다 당장 알아보기 쉽고 단순한 코드를 선호하는 팀원이 있었고, 지금 당장 확장성이 보이지 않으니 설계를 미루자는 의견도 있었다.

 클래스명과 겹치는 메서드 네이밍이나 40줄이 넘어가는 긴 메서드들을 보며 솔직히 힘들었다.. 어떤 날에는, 코드를 보는 것이 힘들어 리팩터링하는 망상을 하며 혼자 다이어그램을 그리기도 했다.

 

그때 한 팀원과 리뷰를 주고받으며 내가 잘못된 방향으로 가고 있다는 것을 깨달았다.

 

 

이 리뷰에 답변하다 의문이 하나 들었다. "왜 이 간단한 기능을 이렇게까지 설계했지?"

 

 스스로에게 질문을 던졌다."내가 정말 하고 싶었던 것은 객체지향 코드, 클린 코드 작성하기인가, 아니면 사용자에게 가치를 전달할 수 있는 서비스를 만드는 것인가?"

 답은 명확했다. 나는 내가 불편했던 점을 해결하는 라이브러리를 만들거나, 학교 축제 부스 운영을 자동화하는 서버를 만들며 행복감을 느끼는 사람이다. 나는 사용자가 내가 만든 서비스를 사용하며 편리함을 느끼는 것을 가장 기쁘게 생각하는 사람이다.

 

본질은 결국 사용자에게 가치를 전달하는 것에 있다는 것을 깨달았다.

 이후 나의 가치관을 바꾸려고 노력했다. 마음에 들지 않는 코드가 보여도 "코드나 설계 리팩터링은 레벨 4 때 하자 ㅋㅋ"라는 농담을 주고받으며 개발에 속도를 냈다.

 덕분에 서비스를 빠르게 출시하고 Usability Test도 신속하게 받을 수 있었다.

 

이번 프로젝트를 통해 나는 "우선 동작해야 한다"는 가장 중요한 교훈을 얻었다.

코드가 객체지향적이고 깔끔하지만 사용자가 없는 서비스보단, 코드가 다소 미흡하더라도 많은 사용자에게 실제로 가치를 제공하는 서비스가 훨씬 더 의미 있다는 것을 깨달았다.

 

 

말을 예쁘게 하자

 나는 어려서부터 직설적으로 말하는 편이었다. 논리적으로 옳지 않다고 생각하면 "그건 조금 ~한 문제가 있지 않을까?" 하고 돌려 말하기보다는 "그거 아닌 것 같은데?"라고 직설적으로 말하곤 했다.

 그렇다고 사회성이 부족한 괴짜는 아니었다. 해맑게 "그건 아닌 것 같은데?"하고 다녀서 주변 사람들은 나를 "말투가 강하지만, 애는 착하고 재미있다"라고 표현하곤 했다.

 

 하지만 스무 살 무렵, 이러한 직설적인 화법이 새로운 사람들을 만날 때 큰 단점이 된다는 것을 깨달았다. 새로운 모임에 나갈 때마다 "첫인상이 무서워서 다가가기 힘들었다"는 말을 자주 들었다.

 나의 직설적인 표현이 상대방에게는 무례하거나 위협적으로 느껴질 수 있다는 것을 그때 처음 알게 되었다.

 

 이 경험을 계기로, 나는 오랜 시간 동안 말을 예쁘게 하기 위해 노력했다. 그 덕에, 다른 사람에게 공감하고 때로는 따뜻한 말을 건네는 사람이 되었다. 상대방이 틀린 것 같아도 반대 의견을 강하게 주장하기보다는 웬만하면 따르는 사람으로 바뀌었다.

 

 몇 년간의 노력으로 일상적인 대화에서는 많이 개선되었지만, 우테코에서 기술적인 토론을 주고받다 보니 다시 예전의 직설적인 모습이 드러났다. 기술적인 부분에서 논리에 어긋나면 곧바로 "그건 아닌 것 같다"라고 말하고 있었다.

 

 몇몇 팀원들은 나의 이런 말투가 부담스러웠다고 솔직하게 피드백을 주었다.

 

 

 나는 "부담스러운 팀원"가 아니라 "함께 일하고 싶은 사람"이 되고 싶었다. 좋은 개발자는 혼자서만 완벽한 코드를 짜는 사람이 아니라, 팀원들과 함께 더 나은 결과물을 만들어내는 사람이라 생각하기 때문이다.

그런 관점에서, 내 직설적인 말투는 다른 사람의 아이디어를 위축시키고 서비스의 발전을 늦추는 장애물이었다.

 

 이 문제를 해결하기 위해 "의식적으로 10초 이상 고민하고 부드러운 말투로 의견을 제시하기"를 계획하고 실천하기 시작했다. 상대방의 의견이 당장 마음에 들지 않더라도, 우선 10초 이상 참고 "반박하기보다는 의견을 제시하자"와 "어떻게 말해야 부드럽게 전달할 수 있을까?"를 고민했다.

 

 이런 노력을 꾸준히 이어갔더니, 변화가 찾아왔다. 레벨 3가 끝날 무렵, 이전에 피드백을 주었던 팀원들이 "머랭의 말투가 크게 개선되었다", "앞으로도 같이 팀을 하고 싶다", "머랭 덕에 재미있었다"는 긍정적인 피드백을 주었다.

 

 

이런 피드백을 받을 만큼 많이 개선되었는지는 잘 모르겠지만, 다른 팀원들이 좋았다니 나도 좋았다.

 레벨 3 동안 이런 팀원들과 함께할 수 있었던 것이 나에게는 큰 행운이었다. 개발 외적으로도 재미있게 장난치며 놀았고, 우아한테크코스가 끝나도 계속 함께 서비스를 개발하고 싶은 소중한 사람들이 생겼다.

 

 이 일을 계기로 "함께 일하고 싶은 개발자"에 한걸음 더 다가갈 수 있었다. 프로덕트는 혼자 만드는 것이 아니라 주변의 동료들과 함께 상호작용하며 만들어나가는 것이다. 이번 레벨에 했던 "10초 참기"를 앞으로도 의식적으로 해 볼 생각이다.

 

 

 

마무리

레벨 3는 개발자로서의 인생에 있어 정말 값진 시간이었다.

 레벨 3를 통해 나는 "소프트웨어 장인 정신"이 무엇인지 다시 생각하게 되었다.  "소프트웨어 장인 정신"은 우아하고 완벽한 코드를 짜는 기술적인 미덕만을 의미하지 않는다는 것을 깨달았다. "기술적 역량을 바탕으로 사용자에게 실질적인 가치를 제공하고, 건설적인 소통으로 팀의 문제를 함께 해결하며 더 좋은 프로덕트를 만들어나가는 정신"이 내가 지향해야 할 진정한 소프트웨어 장인 정신임을 깨달았다. 앞으로 기술과 사람 모두를 소중히 여기는 개발자로 살고 싶다.

 

 

 

부록  -  우리 팀 분위기를 가장 잘 나타내는 "팀 가족신문"