/ WORK

Team Building 하기

우리 팀의 빌딩 스토리와 팀워크

이번 포스팅은 우리 팀의 팀에 대한 이야기를 써보려고 한다. 팀이 만들어지기까지, 그리고 내가 리더가 되기까지 험난한(?) 여정이 있었지만, 지금은 누구에게라도 자신 있게 보여 줄 수 있는 팀이 돼서 너무 감사하다. 좋은 사람들을 모으고, 이 사람들이 일을 잘 하기 위한 문화를 만들고, 같이 성장하기 위해 노력한 이야기를 정리해 보려고 한다. 그리고 내가, 아니 우리가 앞으로 만들 성장하는 팀에 대한 생각도 글로 남겨 보려고 한다.

어떻게 만들어졌나?

우리 팀은 처음 인원 3명이서 시작한 팀이었다. 원래 소속된 팀에서 특공대(?)로 뽑혀서 3명이 PoC(Proof of concept) 데모 개발을 시작했다. 처음에는 프로젝트 그룹으로 시작했다. 조직 리더님이 새로운 제품의 아디디어를 나에게 보여주셨고, ‘한번 해 보지 않을래?’라는 꼬심(?)에 홀딱 넘어갔다. 누구나 그렇듯 나도 새로운 것을 좋아하고, 특공대 역할을 자처하는 스타일이라, 리더님의 꼬심에 넘어갈 수밖에 없었다.

먼저 우리가 만들 제품의 콘셉트와 기술을 설계했다. 시스템 구조와 데이터 스트럭처를 설계하고, 기술 스펙을 정리했다. 이때도 코딩보다 이야기를 많이 한 것 같다. 먼저 각자의 생각을 모두 맞춘 다음 모여서 설계하고, 코딩하는 순으로 개발했다. 원래 팀에서도 대화하는 조직 문화가 있었고, 나도 이런 문화를 정말 좋아했다. 그래서인지 3명이 종일 이야기할 수 있었다. 대화는 서로를 이해하는 가장 좋은 수단이다. 글은 개념적인 지식을 공유하는 수단이라고 하면, 대화는 그 사람의 생각, 감정, 지식을 모두 공유하는 공유의 시작점이다. 상대방과 얼굴을 보면서 대화함여서, 나의 생각과 감정을, 상대방에게 전달하고 공감을 이끌어 내고, 이걸 기술로 만드는 과정이라고 생각한다.

아… 이야기가 삼천포로:(

아무튼 3명이서 PoC를 열심히 만들어서 초기 프로토타입을 생각보다 일찍 만들었다. 이것도 먼저 토론하면서 설계를 했기 때문이 아닐까 싶다. 우리는 다음 스텝으로 넘어가려고 준비 중이었는데, 어쩌나.. 갑자기 프로토타입으로 실 서비스에 적용해야 하는 상황이 되었다. 이 프로젝트의 개발 스폰서십을 위해 현재 기술을 서비스에 적용해서 실증해야 했다. 실 서비스 구현은 PoC 와는 다른 차원의 문제이다. 3명 가지고는 어려운 일이었고, 기존 팀에서 1명을 더 차출하고, 마크업을 지원받았다. 이제 구성원이 5명이 되었지만, 그때도 팀이라기보다 TF 개발팀처럼 빨리 서비스를 만들어야 했다, 일을 중심으로 하다 보니 대화의 기회가 줄어 들었고, 개발에 더 집중하게 되었다.

그렇게, 서비스를 우여곡절 끝에 오픈을 했으나… 개발 그룹 중 1명이 다른 팀으로 전배를 가게 되었다. 그때는 좀 섭섭하긴 했지만, 지금은 웃으면서 만나는 사이이다. 다시 3명이 되었고, 정비하기도 전에 다시 또 다른 프로젝트가 시작되어 버렸다… 3명의 인력으로 프로젝트를 진행하다 보니, 나는 외부 커뮤니케이션과 일정 조율, 개발까지 담당해서 정신이 없었고, 다른 분들도 각자 업무에 정신이 없었다. 그때는 팀도 아니었고 여유도 없어 일하는 문화를 만드는 것은 더 어려운 일이었다.

한 명의 팀원이 합류했고, 구세주 팀원이 긴 설득 끝에 입사를 했다. 전에 같은 팀에 있었던 동료인데, (김 코딩하라고 하면 알만한 인 씨..) 스타트업을 거치면서 팀 빌딩 마스터가 되어 돌아왔다. 우리는 이제 팀으로 움직이기 시작했다.

팀 빌딩의 어려움

5명이 되면서 소규모 팀이 되었고, 본격적인 팀 빌딩에 들어갔다. 우선 몇 가지 해야 할 것들을 정했다.

  • 팀 위키 스페이스를 만들고, 위키를 정리하여 지식 베이스를 만들기
  • 스크럼을 통한 업무와 생각 공유
  • 팀 빌드업 미팅으로 팀에 필요한 문화 및 제도의 활성화
  • 팀 채용에 대한 기준 정리와 인재상 정리

팀을 만드는 것은 사람의 생각을 맞추는 일이 핵심이다. 나의 생각과 동료의 생각을 맞추고, 내가 고민한 내용을 동료와 함게 고민할 수 있는 문화를 만드는 것이 중요하다. 그래서 각자의 생각을 맞추고 팀의 목표나 문화를 맞추는 일이 쉽게 되지는 않는다. 이야기가 많이 필요하고 공감과 동의가 필요한 작업이다.

우리는 하나하나씩 미션을 해 가면서 지금의 팀을 만들어 가고 있다.

원칙과 규칙 만들기

자유로운 팀을 만들기 위해서는 자유의 범위를 정하는 원칙과 규칙이 필요하다. 팀의 규칙은 팀을 운영하기 위한 최소한의 가이드라인으로 정한다. 규칙이 너무 많다면 기억하기가 어렵다. 곧 지키는 것도 어렵다는 의미다.

몇 가지 꼭 지켜야 하는 핵심 문장들로 가이드라인을 정하자

우리 팀이 정리한 핵심 가치

  • 무엇이든 재미있게 합시다.
  • 팀과 함께 성장합니다.
  • 하고 싶은 일은 도전하세요, 하지만 힘들면 쉬어가세요.
  • 조건 없이 협력하고 일이 되게 만듭니다.

온 보딩의 과정에 이런 내용을 넣어 신규로 입사하면 자연스럽게 팀의 문화와 규칙에 익숙해지도록 유도했다.

문서로 만들자

정리되지 않은 지식은 휘발되게 마련이다. 좋은 아이디어들도 정리되지 않으면 생각으로만 머물다가 없어진다. 문서는 그래서 중요하다. 그러나 무조건 문서가 많은 것도 좋은 것은 아니다. 만들기만 하고 사용하지 않은 문서는 의미가 없다.

꼭 필요한 문서를 핵심만 담아서 정리하는 것도 중요한 문화이다. 문서는 곧 공유의 시작이기 때문이다. 문서를 기반으로 일이 이루어지면 사람이 일일이 이야기하지 않아도 문서로 업무의 많은 부분을 줄일 수 있다.

우리 팀은 위키로 정보를 정리하고 지식 체계화를 하고 있다. 팀의 규칙과, 서비스 정보, 트러블 슈팅, 스펙 문서까지. 위키에서 팀의 모든 정보를 빠르게 찾아보도록 카테고리를 만들어 정리하고 있다. 이렇게 만들어진 문서를 활용해 온 보딩과, 업무 가이드 및 작업에 활용하여 문서를 최신으로 유지시키고 있다.

사람이 답이다

팀은 사람이 있어야 유지된다. 특히나 IT 산업은 사람이 핵심 경쟁력이다. 요새 우수한 인재를 채용하기 위해 개발자 몸값이 천정 부지로 오르고 있는 것도 그 때문이라고 생각된다. 좋은 인재는 어떤 인재일까? 슈퍼 개발자가 들어오면 팀이 성공하는 것일까?

우리 팀의 좋은 인재는, 팀원들과 어우러져 팀플레이를 할 수 있는 팀 플레이어를 원한다. 혼자서 잘한다고 일은 돌아가지 않는다. 개별의 전투력이 약하더라도, 팀플레이에 능한 사람은 팀을 통해 이를 극복할 수 있다. 이를 위해 협력하고, 커뮤니케이션과 개선에 대한 에너지가 높은 인재가 필요하고, 우리 팀이 바라는 인재상이다.

이렇듯 본인의 팀에 맞는 팀원의 인재상을 만들어야 한다. 무작정 개발 잘하는 사람만 뽑으면 팀 문화나 팀 협업을 놓치게 되어 결과적으로 팀워크를 깨뜨리는 사례를 많이 봐왔다. 팀의 컬처 핏을 확실히 정리하고, 여기에 맞는 사람을 어떻게 뽑을지 채용절차까지 정리해 두어야 채용이 일관성 있게 진행될 수 있다.

우리 팀은 채용 관련해 핸드북을 한 달 동안 정리했다.

  • 팀에 필요한 인재상을 정하고,
  • 인재상에 부합하는 기준을 정리
    • 신입 / 경력의 기준
    • 서류 검토 시 점검하는 항목과 평가 기준 및 점수
    • 사전 평가 시 점검하는 항목과 평가 기준 및 점수
    • 1차 면접 시 점검하는 항목과 평가 기준 및 점수
  • 면접 프로세스 정리
    • 타임테이블 정리
    • 정리 템플릿
  • 면접 가이드

이렇게 정리해 놓고 채용을 진행해 보니 지원자의 어떤 면을 봐야 할지 확실히 정리가 되고, 평가에 대한 기준도 명확해서 누구나 이해하기 쉬웠다. 특히나 1차 면접 프로세스의 순서를 아래처럼 정리해서 진행하니 면접자들이 긍정적으로 반응했다.

  • 인사 및 자기소개(5분)
  • 지원 직무 확인 & 아이스브레이킹(5분)
  • 면접 - 90분(면접 3명 참여 시 1인당 30분)
  • 회사 QnA(10분)
  • 상호 피드백 교환(10분)

시작 전 아이스브레이킹을 통해 긴장도 줄이고, 친근감도 높여 면접 집중력을 높여 주고, 사전 면접자에 대한 리뷰로 질문을 준비해 확인하고 싶은 내용을 효율적으로 질문했다. 그리고 QnA를 통해 지원자의 궁금함이나 팀에 대한 문의를 답해주었는데. 여기서도 지원자의 성향이나 태도를 좀 더 볼 수 있는 시간이 되었다. 특히 마지막 피드백 시간에서 지원자분이 받고 싶은 피드백을 질문해서 지원자와 면접관 사이에 서로 생각을 공유하고 개선 포인트를 찾아보는 시간으로도 사용해서 유용했다.

면접을 통해 실력의 검증도 있지만 면접을 보는 사람이 또 다른 학습을 하는 시간이라고 생각했다. 지원자가 최대한 얻는 것이 많도록 질문하고 피드백을 줘서, 꼭 합격이 아니더라도 배우고 성장하고 간다는 인상을 주면 나중에라도 우리 팀을 기억하지 않을까?

팀의 채용은 다른 어떤 것보다 중요한 프로세스이고, 기준과 과정에 대해 오랜 토론을 통해 정리가 필요하고, 이 기준의 전체 팀원들에게도 공유 되어야 한다. 사람을 잘 모으면 팀 빌딩의 절반은 끝난 것이다.

짧은 회의와 스몰토크

업무 시간 중 회의가 차지하는 시간은 얼마나 되는가? 나처럼 리더를 맡다 보면 일주일 일정을 정리하다 보면 하루의 반 이상을 회의에 보낼 때가 많다. 회의 자체가 업무일 수는 있지만 너무 긴 시간의 회의는 오히려 피로만 늘어나고 좋은 결론이 나지 않는 경우가 많다.

우리 팀도 초기 팀 빌딩을 위해 회의가 많았고, 이에 따른 팀원 들의 피로감에 대해서 많이 언급되었다. 그래서 회의 시간을 줄이기 위한 몇 가지 방법을 만들어 실천하고 있다.

  1. 회의록 선 공유 회의 주제자가 회의록을 미리 적어 회의의 목적과 참가자들이 미리 정리할 내용을 공유하여 이슈에 대한 논의만 짧게 가져가도록 했다. 그리고 회의의 핵심 목표와 기대 결과 등을 정리하여 집중하도록 했다.
  2. 30분 단위 회의 1시간 단위의 회의보다 30분 단위로 짧게 제약해서 집중도를 높이도록 했다. 불필요한 설명은 피하고, 사전회의록으로 미리 정보를 공유하여 핵심만 논의하면 30분으로도 회의는 가능하다.
  3. 스크럼 시간의 활용 별도 회의를 잡지 말고 아침에 하는 스크럼 시간에 빠르게 이야기하는 것도 회의를 줄이는 좋은 방법이다. 별도 회의를 많이 하기 보더 모두 모이는 시간을 활용해서 간단한 이슈는 바로바로 논의해서 정리하면 불필요한 회의를 줄 일수 있다.

적극적인 문화 만들기

개발자들은 내성적이다. 자기 생각을 잘 안 보여주려고 하고, 특별히 반박하고 싶어 하지도 않는다. 자기 일에 관련한 말만 조금 하고 싶을 이다. 팀의 문제는 언제나 많다. 이런 문제를 이야기하는 자리에서도 침묵이 길어진다. 생각은 있지만 부끄러워하는 사람, 자신과 직접 연관 이슈가 아니라서 관심 없는 사람 여러 가지 상황들로 개발자들은 이야기를 잘 하지 않는다.

팀의 활기가 있고, 개선이 되려면 이야기를 쉽게 하고, 편안하게 이야기하는 분위기가 돼야 한다. 그래야 평소 생각을 편하게 이야기하고, 의견도 자연스럽게 가질 수 있다.

팀원들이 편하게 의견을 내는 분위기를 만들기 위해 무던히 노력을 했다. 나는 침묵의 시간을 굉장히 싫어해서 내가 주로 떠드는 편이었다. 그러다 보니 더더욱 팀원들이 이야기할 시간이 없었다. 그래서 나의 이야기는 줄이고 팀원들에게 시간을 많이 할애했다. ‘그래서 당신의 생각은?’ ‘돌아가면서 이야기해 볼까요?’ ‘어떻게 하면 좋을까요?’ 이렇게 피드백을 듣는 질문들로 유도하면서 이야기를 진행하니, 처음에는 쑥스러워 했지만 시간이 지나면 지날수록 자연스러운 이야기 참여가 가능했다.

상대방의 이야기를 잘 들어 줄 수 있는 마음가짐과 기회가 왔을 때 생각을 편하게 이야기하는 환경을 만들어 주는 것이 적극적인 팀 문화를 만드는 비결일 것이다.

하지만 이런 문화는 하루 이틀에 만들어지지 않는다. 3개월이고 4개월이고 꾸준히 이런 분위기를 유도하는 것은, 리더와 시니어 들의 몫이다.

집단지성으로 일하기

주니어 친구들이 주로 그렇지만, 개발자들은 문제를 만나면 혼자 풀어 보려고 애를 쓴다. 도움을 요청하는 것이 다른 사람의 시간을 방해하는 것 같고, 내 능력이 없어 보이기도 해서, 혼자 고민하다 시간을 많이 허비한다. 나도 그랬지만, 일반적인 개발자들의 습성이다. 물론 혼자서 빨리 해결한다면 문제는 되지 않는다. 다만, 혼자서 해결이 불가능 한 이슈를 잡고 있다가, 팀 전체의 퍼포먼스를 덜어 뜨리는 경우가 문제이다.

팀의 개발 환경 셋 팀에 대한 업무를 하다가 기술 이슈에 막혀 개발 환경이 세팅이 늦어지면 전체 개발 일정에도 영향이 간다. 이럴 때는 팀의 집단지성으로 빨리 해결하는 게 바람직하다. 문제에 대한 배경과 정확한 내용을 팀에 공유하고 그룹으로 방법을 찾으면 생각 보다 금방 이슈가 해결된다. 팀원들의 다양한 경험치를 살려 빠르게 이슈를 해결해야, 개발 일정을 효율적으로 사용할 수 있다. 같은 질문의 반복은 안 좋지만, 팀을 통해 빠르게 해답을 찾는 것도 좋은 해결 방법이다.

회고로 돌아 보자

애자일 프로세스에는 회고가 반드시 있어야 한다. 회고를 통해 한일의 내용을 복기하고, 일하면서 불편하거나 어려웠던 점들을 이야기하고 개선 계획을 세우는 것이 중요하다. 우리 팀도 스크럼과 스프린트 운영의 애자일 프로세스로 일하고 있어 회고를 좋은 시간으로 쓰고 있다. 업무에 관련한 것도 좋지만, 팀의 문화나, 평소에 토론하고 싶은 주제도 회고를 통해 서로 이야기하고, 구체적인 개선 방법을 정리하는 것도 좋은 방향이다.

회고를 통해서 업무나, 문화의 개선도 가져올 수 있지만, 팀이 끊임없이 개선한다는 팀 구성원의 프라이드도 가지게 하는 효과도 있다. 우리는 항상 개선하려고 하고 있고 좋아지고 있다는 느낌을 주면 팀에 대한 소속감을 높일 수 있다.

내가 원하는 일에 집중

우리팀은 가급적 원하는 업무에 맞춰 일을 배분한다. 자기가 원하는 일일 수록 집중역 높에 일하고, 그만큼의 보람도 돌아 올 수 있다. 스프린트 업무 미팅에서 이런 업무 분배 과정을 거친다.

자신이 하고싶은 일에 손을 들고 가져가기 때문에 책임감이 높아지고, 도전적인 목표를 가진 업무로 역량도 자연스레 향상 된다. 대신, 너무 일에 너무 욕심을 내다보면 번아웃이 오는 경우가 종종 있고, 야근이 많아 지는 경우가 있으니 감당 할 수있는 이슈인지 생각 해 보고 주위 에서도 피드백을 줘야 한다.

운영과의 운명

우리 팀은 신규 플랫폼을 만드는 조직이다. 하지만, 초기 적용된 서비스들이 있고, 신규로 개발한 레거시로 만든 시스템도 있다. 어떤 개발 조직에도 운영이라는 업무는 필수 불가결하게 따라오는 업무이다. 신규 플랫폼을 만드는 팀에서는 이런 운영 업무가 달갑지 않다. 운영 업무를 맡는 사람들은 신규 프로젝트 업무 참여에 대한 박탈감이 있다. 이런 점들이 쌓이면 팀워크가 깨지게 된다. 운영은 예전 코드를 수정하는 허드렛일로 보는 시각이 문제이다.

나는 팀 리더로 팀원들에게 문영의 중요함을 강조한다. 운영은 절대 작은 업무가 아니며, 팀의 핵심 경쟁력이다. 플랫폼을 아무리 잘 만들어도 운영을 못하면 아무 소용이 없게 된다. 서비스에서 장애가 나고, 유지 보수가 되지 않는 플랫폼을 누가 써줄까? 새로운 것을 만들기 위해서는 기존 것을 잘하는 것이 토대가 돼야 한다. 운영은 신규 기술 개발을 위한 기본 요건이다. 그래서 운영은 중요한 업무이고 팀의 경쟁력이다.

운영을 통해서 많은 것들을 배울 수 있다. 신규 플랫폼을 만들 때는 팀 내 커뮤니케이션을 주로 하지만, 유지 보수를 하면서는 외부 부서와 커뮤니케이션을 해야 한다. 이 과정에서 자연스럽게 남과 이야기하는 방법 그리고, 다른 부서분들과 친분도 쌓을 수 있게 된다. 즉 사내 인맥이 강화된다. 내가 운영이라는 일을 하면서 가장 많이 배운 점이 커뮤니케이션이다. 운영에는 다양한 이슈가 발생하고, 이슈에 대한 해결을 위해 커뮤니케이션이 필요하다. 이런 과정을 통해 자연스럽게 외부와 커뮤니케이션을 능숙하게 할 수 있다.

레거시를 통해 기술적인 성장도 가져올 수 있다. 레거시를 유지 보수하면서 누더기 코드를 만든다는 자괴감에 빠질 수 있지만, 누더기 코드를 만들지 말고 개선하는 프로젝트도 진행해 보면 어떨까? 기존 코드를 읽어서 개발 의도를 이해해 내는 것도 좋은 역량 중에 하나이다. 다른 사람의 코드를 빨리 이해할 수 있는 것은 좋은 개발 역량이다. 그만큼 다른 프로젝트에서도 금방 적응할 수 있다.

나는 운영을 통해 이런 3가지의 큰 장점을 얻을 수 있다고 생각한다. 아직도 운영이 괴로운 업무라고 생각하는가? 다시 돌아 보면 정말 가치 있는 일이다. 이것으로 얻는 성과도 높다.

팀으로 성장하기

업무나 학습을 통해 개인은 성장한다. 개인이 성장한다고 팀이 성장할까? 개인의 성장의 과정에 따라 팀도 같이 성장한다. 스스로의 성장에 대해 기록하고, 팀에 공유하고, 외부에 발표하면서 팀도 같이 성장할 수 있다. 혼자서만 아는 지식은 개인의 성장에 그치지만, 혼자 아는 지식을 문서로 공유하거나 팀에 설명해서 같이 공유하면, 팀의 역량이 올라간다. 혼자 공부하지 않고 스터디그룹으로 학습하면서 팀을 성장시켜야 한다.

앞에서 이야기한 모든 팀 활동과 개선 과정을 통해 개인의 마인드 셋을 변화 시켜야 팀이 성장한다. 내가 강해지면 팀이 강해지고 강한 팀은 나를 더 강하게 밀어 줄 수 있다는 확신을 주어야 한다.

앞으로 우리 팀은.

이런 이야기를 하다 보니 무언가 대단한 팀이 된 것 같지만, 아직도 우리 팀은 빌딩 중이다. 새로운 분들이 오시고, 새로운 일이 생기고, 새로운 환경에 적응하고 있다. 하지만 우리가 만든 좋은 문화가 있기에 이런 변화들이 두렵지 않다. 지금의 문화를 계속 이어가고 더 좋게 만들어 가는 것이 앞으로 가야 할 팀의 방향이다. 지금보다 더 편하고, 즐겁게 일하는 팀이 되도록 나와 동료들은 열린 마음으로 이야기하고 있다.

3명에서 지금의 10명의 팀이 되기까지 힘든 일도 많았지만, 어느 대보다 즐겁게 팀을 빌딩 했다. 같은 마음으로 동료들을 신뢰할 수 있어서 였지 않을까 싶다. 이런 훌륭한 팀을 만들어준 동료분들에게 박수를 보낸다.

어떤가요? 우리 팀과 같이 성장해 보시면 어때요? 연락을 기다립니다.