개발팀과 개발팀장이 사라져야 하는 이유
오늘도 극단주의자는 극단적으로 이야기한다.
보통 회사에서는 팀을 꾸릴때 기능별로 분리하는 경우가 많다. 마케팅팀, 디자인팀, 개발팀, 기획팀 등등. 해당 팀의 리더가 팀장이 되어 팀원들의 성장과 업무분배를 책임진다. 일반적으로는 가장 경력이 길고 실력이 좋은 사람이 팀장이라는 직함을 달게 되고, 팀원의 인사평가, 업무 분배 등 여러가지 매니징을 하게 된다. 아주 쓰레기 같은 시스템이다.
1. 팀의 역할과 책임, 회사의 방향 그리고 프로덕트 자체의 니즈는 종종 충돌한다.
이게 무슨 개소린가 싶겠지만, 실제로 그렇다.
프론트엔드 개발팀 이라는게 뭘까? 백엔드 개발팀은? 이들이 책임져야 하는 영역은 어딜까? 어떻게 보면 당연한 질문 같지만 여기서부터 시작해야 한다. 프론트엔드 개발팀이 책임져야 하는 영역은 단순화하면 웹사이트가 브라우저에서 잘 동작하게 하는 것 이라고 볼 수 있을 것 같다.
그럼 회사에서 바라보는 서비스란 무엇인가? 회사에서는 돈을 잘 벌어다 주는 기능의 총합 이 서비스에 대한 본질일 것이다. 미려한 UI, 에러없는 사이트 이런건 그냥 다 부차적인 기능일 뿐이고, 웹사이트의 기능 100가지 중 사람들이 잘 쓰는 10가지에서 90%의 매출이 나온다면, 나머지는 사실 부질없는 것이다.
프로덕트 니즈라는 것은 그럼 무엇인가? 프로덕트는 어떻게 보면 유저와 회사만이 가지고 있는 니즈라고 볼 수 있다. 눈에 드러나지 않고, 대충 감은 오지만 감각적으로 느껴야 하는 부분이다. 유저가 우리 서비스에 더 머무르게 할 수 있는 기능 이라고 정의할 수 있을 것 같은데, 예를 들어서 “휴대폰을 구매를 완료하고, 케이스 구매로 연결하는 기능” 이다. 잘 만들면 유저의 편의를 해치지 않으면서 매출에 기여할 수 있는 킬러 피쳐가 될 수도 있을 것이다.
어떻게 보면 큰 틀에서 프로덕트와 회사의 니즈는 거리가 무척 가깝다. 우리 서비스에 더 오래 머무르게 하는 것이, 결국 회사의 매출을 증대시킬 테니까.
그런데 개발팀의 입장은 약간 다르다. 웹사이트가 브라우저에서 잘 동작하게 하는 것은 사실 프론트엔드 개발”자” 에게 당연한 것이다. 당연한 것을 계속하는 것에 대해서 평가하는 것은 매우 어렵다. 서비스가 뭐 일주일을 멈춘다면 당연히 문제가 있겠지만, 보통은 충분히 납득가는 선에서 장애가 일어나고 이러한 부분에 대해서 평가를 박하게 하는 것인 개발자를 무척 소극적으로 만들 것이다.
실제로 이런 일들이 일어난다. 회사에서 (정확하게는 영업 부서에 가깝겠지만) 어떤 기능을 추가해야 할 때, 개발자의 눈치를 보는 경우가 종종 일어난다. 또한 개발자와 커뮤니케이션 할때 알게 모르게 자주 사용되는 용어가 “부탁한다” 이다. 나 또한 이런 걸 이상하다고 못 느꼈는데, 생각해보면 말이 안되는 단어긴 하다. PM 이 필요하다고 결정한 기능을 개발하는데 개발자에게 부탁을 한다? 디자인이 완성되지 않아서 QA 를 하고 부족한 부분을 지적하는데 부탁한다?
일견 개발자들의 의견도 이해는 간다. “이런 기능을 만들다가 에러가 많이 생기고 그게 서비스 안정성에 해를 끼친다.” 맞는 말이다. 그런데 이러한 부분을 다른 측면에서 이해해 볼 필요가 있다. “니가 하자고 하는게 이해는 되는데, 우리팀의 역할이 기능 하나 만들어서 돈을 벌어오는 건 아니잖니?” 쪽에 가깝다고 생각한다. 회사가 돈을 잘 버는 것이 개발자 한명의 평가에 영향을 줄 수 없고, 역할이 나뉘어져 있기 때문에 공감을 하기 어렵다는 것이다.
2. 다른 기능 조직의 역할에 공감을 하기 어렵다.
기능 조직의 가장 큰 단점이 바로 이 공감부족에서 나타난다.
과거로 좀 돌아가서 쏘카에서 일할 당시를 떠올려본다. 쏘카에는 쏘모임이라는 재밌는 제도가 있었다. 쏘카는 기능 조직이 크게는 본부별로 나뉘어져 있었는데, 다른 3개 본부의 사람들로 최소 5명을 모아오면(?) 한달에 한번씩 N만원 정도의 지원금을 주는 제도였다. 취지도 좋고, 참여자의 만족도도 높으면서, 회사에서 부담할 금액은 적은 상당히 괜찮은 지원 제도였다고 생각한다. 취지야 뭐 예상할 수 있다시피 다른 기능 조직과의 커뮤니케이션을 통해 공감 능력을 길러보자 였을거다.
그 쏘모임을 통해 다른 조직을 만날때마다 나는 입장 차이라는 걸 뼈저리게 느꼈다. 마케팅팀의 답답함, 고객 서비스 조직의 불편함, 개발조직의 거만함. 요청을 받아서 일을 시작하는 개발팀 입장에서 다른 모든 조직은 왜 자꾸 일을 가져오는지 귀찮은 존재일 수 밖에 없았다. 그도 그럴 것이 기본적으로 하는 유지보수, 레거시를 개선하기 위한 개발 프로젝트, 새로 만드는 피쳐 개발에, 중간중간 인터럽트로 들어오는 개별 요청들. 어떤 개발자나 개발팀이 나뻐서가 아니라, 개발팀으로 일을 하게 될때 이런 정체 현상이 자연스럽게 생겨난다.
또한 일을 분배하는 것이 매우 어렵기도 하다. 회사의 규모가 어느정도 커지면 이제 개발팀장의 역할은 일을 막는 사람으로 변질된다. 그도 그럴것이 팀 사이의 수많은 회의에 참가해야 하고, 다양한 의견을 디펜스 하면서, 때로는 방향 제시도 필요하다. 한편으로 회의 결과를 팀과 공유하고 필요한 리소스를 분배해야 하며, 종종 직접 개발을 해야할때도 있다. 5~6명만 넘어서도 개별 업무 진행 상황을 파악하기도 어렵고, 이럴때 할 수 있는 최선은 수비적으로 대응하는 것이다. 즉, “확인하고 말씀드리겠습니다.” 기껏 한시간의 회의를 했는데 결론은 “다음에 말씀드릴게요.” 다른 바쁜일 때문에 깜빡 하기라도 하면, 요청한 팀의 입장에서는 “더럽게 안도와주네” 가 된다.
또한 리소스를 분배하다보니 이전 코드를 작성하지 않았던 사람이 해당 코드를 수정하게 되면서 여러가지 버그나 의도하지 않았던 문제들이 발생하는 경우도 종종 있다. 문서화 잘~~ 하면 되지 않냐고? 문서화가 잘된 개발 프로젝트라는 것은 강물과 비슷하다. 잘 해두더라도, 곧 흘러가버린다. 자기가 쓴 코드라도 3개월만 지나면, 처음 보는 코드와 다를 것이 별로 없다.
그런데 진짜 문제는 전문성이 사라진다는 것이다.
3. 팀의 전문성이 없다.
프론트엔드 개발팀에 왜 전문성이 없냐고 하겠지만 사실 그건 개발자 입장일 뿐이니 패스하겠다. 프론트엔드 개발 기술이 좋아지면 회사의 매출이 올라가는 게 아니라 그 개발팀 혹은 개발자의 몸값이 올라가는 것이다. 가치가 없다는 것이 아니라 회사의 존재 이유인 이윤 추구 와는 분명히 다르다는 것이다. 개별 직원의 성장이 회사의 성장과 거리가 있다는 점은 매우 아쉬운 일이다. 개발 숙련도라는 것이 다른 직군 보다 누군가의 가르침으로 향상 시키기 어렵다는 점에서 특히 그럴 것이다.
회사 입장에서 팀의 전문성은 아마 매출과 연결할 수 밖에 없을 것이다. 팀의 전문성이 올라가면 비용이 줄어든다거나 아니 좀 더 본질적으로 매출이 올라가는 것을 기대할 것이다. 개발팀의 전문성은 상관관계는 있으나 인과관계는 없다고 봐야 한다. 개발을 잘한다고 회사가 돈을 더 버는 것은 아니니까.
또한 개발팀 입장에서 매출은 뭐랄까 나와는 별로 상관 없는 어떤 것 일 경우가 많다. 이것 또한 개발팀을 욕할 수 없는 것이 매출 말고도 개발자가 신경 써야 할 것은 매우 많다. 역으로 개발을 잘한다고 매출이 올라가는 것이 아니기 때문에 개발팀의 목적은 개발 그 자체로 향하는 것이 어찌보면 당연한 것이다. 개발팀의 목적은 개발을 잘하기 위함이 아니던가? 그래서 기능 조직으로 구성된 회사의 개발팀은 대체로 이질적인 존재가 된다. 가뜩이나 커뮤니케이션 스킬이 부족한 개발자를 더더욱 회사의 목적과 다르게 유도하게 된다. 이런 개발팀에서 오랫동안 경력이 쌓이면, 당연히 폐쇄적이고 아집에 빠지기 쉬운 사람이 될 수 밖에 없다.
전문성이 없으니 당연히 자율성도 떨어진다. 뭘 해야할지 모르니까.
누구도 의도하지 않았지만 개발자와 개발팀은 회사에서 고립되고 소통하기 어려운 사람(들)이 된다. 다른 팀들도 개발팀은 다루기 어렵고 불편한 존재가 되어 회의 때마다 어떻게 해야 하나 고민이다. 또한 대체할 수 없는 경우가 많기 때문에 오히려 CEO 조차도 개발자의 눈치를 봐야 하는 경우가 생기기도 한다. 다행히도 우리에겐 “목적 조직” 이라는 대안이 존재한다.
우선 이 목적 조직에 대해서 정의를 하고 넘어가자.
목적 조직 이란 해당 목적을 달성할 책임과 권한을 모두 가지고 있어야 한다.
즉, 어떤 목적을 달성하기 위해 시작부터 끝까지의 전 과정을 가급적이면 팀 내에서 해결해야 한다는 것이다. 기획에서 디자인, 개발 그리고 배포 까지 전부 한 팀에서 결정하고 실행할 수 있어야 한다. 마케팅이나 영업까지도 할 수 있으면 더더욱 좋다. 기획자의 자리가 점점 더 좁아지고 있는 것은 이러한 목적 조직의 등장 과도 결을 같이한다. 디자이너가 한 팀에 존재하면서 UI 에서 UX 디자인으로의 전환이 이루어졌고, 개발자가 하나의 분야를 담당하면서 백엔드, 프론트엔드가 아니라 풀스택 개발이라는 개념도 나타났다.
엔지니어 출신 CEO 가 많아지는 이유도 바로 여기에서 기인한다. 목적 조직의 리더는 가장 피드백하기 어려운 직군 출신이 되야 하는데, (평가와 지시를 제대로 내리기 위해서) 개발 분야가 바로 그렇기 때문이다. 목적 조직의 리더들 중 많은 사람이 개발자라면, 최고 책임자가 개발자 출신이 되는 것은 필연적일 것이다.
나는 IT 서비스 목적 조직의 최소 조건이 개발자와 디자인이라고 생각한다. 개발자와 디자이너가 함께 일할 수 없으면, 목적 조직을 좀 더 큰 개념으로 확장하는 것이 옳다. 회사에서 가장 해결하기 어려운 것이 커뮤니케이션이다. 조직의 구조적인 면에 기인하기 때문에 오랜 시간 동안 노력해도 잘 개선되지 않는다.
이런 목적조직의 가장 큰 강점은 단순하다는 데 있다.
1. 목적조직의 목표와 평가 기준은 이해하기 쉽다.
개발팀의 목표는 이해하기 쉽지만, 회사에 기여한다는 점에서는 다소 어려운 점이 있다. KPI 든 요즘 유행하는 OKR 이든 근본적으로 한 사람의 생산성을 평가하는데 계량적인 것을 주로 사용한다는 점은 동일하다. 그런데 개발팀의 생산성을 어떻게 평가해야 할까?
버그가 적은 개발자에게 점수를 더 준다면 보수적으로 개발을 할테고, 많은 기능을 개발한 사람이 유능하다면 버그가 많은 어플리케이션을 개발하거나 작은 기능을 체리피킹 할 가능성이 높다. 커밋 순으로 줄을 세운다면 커밋만 수없이 쪼개버릴테고, 코드 줄수로 판단하자니 간결한 코딩이 외면받을 것이 뻔하다.
버그가 없다고 좋은 개발자가 아니고, 속도가 빠르다고 좋은 개발자가 아니다. 결정적인 기능을 만든 사람만 우대하면, 양적으로 필요한 개발은 누가 하겠는가? 때문에 개발팀의 인사평가는 의미 없는 경우가 많고 그저 감으로 하게 될 뿐이다.
그러나 목적 조직은 OKR 이든 KPI 든 목표를 명확하게 세울 수 있다. 예를 들어 “회원 가입” 팀이라면 회원 가입에 걸리는 시간이라던가 작년 대비 회원 가입 숫자의 성장 폭이라던가 누구라도 쉽게 이해할 수 있는 지표들을 손쉽게 만들 수 있다. 요즘엔 북극성 지표라는 말을 많이 사용하던데, 팀의 목적을 명확하게 하면 이 또한 자연스럽게 해결될 일이다.
2. 목적 조직은 팀웍, 나아가 회사 분위기가 좋을 수 밖에 없다.
모든 사람이 하나의 목표를 향해 달려간다는 것은 경쟁보다는 팀웍을 더 중요하게 생각한다는 것이다. 아니 반대로 좋은 팀웍은 하나의 목표를 필요로 한다. 개발팀, 마케팅팀, 영업팀, 디자인팀 각각의 애매하게 다른 지표와 방향성은 팀웍을 당연히 해칠 수 밖에 없다. 회사는 매출을 내야 살아남을 수 있다. 디자인을 잘하고, 개발을 잘하는 것이 아니라 매출에 기여하는 것이 목표가 되어야 한다.
우리 팀이 가진 목표가 명확하고 단순하기 때문에 협력을 해야 한다. 왜 잘되는지, 왜 안되는지를 면밀하게 살펴야 하고 디자인을 개선해야 하는 이유, 개발 스택을 발전시켜야 하는 근거를 우리 팀원들 그리고 다른 팀들과 회사도 공감할 수 있다. 개발팀일때 나와 상관없어 보였던 마케팅 팀의 요청이 이제 직접적으로 와 닿는다. 뭘 해야 할지, 뭘 하지 말아야할지 우리 조직의 목적에 맞는지만 확인하면 그만이다. 물론 그렇다고 해서 의견 차이가 없을 순 없겠지만, 잘된 혹은 잘못된 결정에 대한 피드백도 쉽고, 이러한 과정을 몇번을 반복하면 훨씬 더 건강한 방향으로 발전해 나갈 것이다.
개발팀으로 일을 하다보면 애매하게 빈 공간이 종종 생긴다. 목표가 포괄적인데, 팀장이 일을 분배하는 방식이다보니 당연히 쏠림이 발생하고 공백이 생길 수 밖에 없다. 개인에게야 여유를 갖게 되니 좋을수도 있지만, 경험해 본 사람이라면 이게 얼마나 뻘쭘한 상황인지 잘 알 것이다. 모르긴 몰라도 마케팅팀이나 디자인팀도 마찬가지 일거다. 미뤄둔 걸 하자니 이 기간이 얼마나 될지 모르겠고, 아무것도 안하자니 월급 루팡이 된 기분이다.
목적 조직은 조금 다를 수 있을것이다. 아마 개발 직군이 아닌 사람들은 개발자 손이 비기를 호시탐탐 노리고 있었을거다. 작은 디자인 변경이나, AB테스트, 퍼포먼스 개선 등 해야할 일들이 명확하고 어차피 팀내에서 무엇을 할지 결정할 것이기 때문에 진행하기도 훨씬 수월하다.
3. 팀에 도메인 전문성이 쌓인다.
도대체 도메인 지식이라는게 뭔가? 내가 게임을 좋아해서 게임회사를 들어가면 그게 충분히 도메인 지식을 갖췄다고 할 수 있을까? 제조업 종사자라면 생산 기술을 잘 알고 있을때 우리는 해당 도메인에 대해 잘 안다고 평가할 수 있을 것 같다. 그럼 IT 회사는 무엇일까? 나는 해당 도메인의 유저에 대해 잘 알고 있을때 도메인 전문성을 갖췄다고 말할 수 있을 것 같다.
도메인 지식을 쌓기 위해서는 두가지 방법이 있다. 1) 운 혹은 동물적인 센스가 있어서 내가 하는대로 사람들이 반응하거나 2) 이렇게 저렇게 수없이 시도해봐서 귀납적으로 유저의 경향을 깨닿는 것이다. 1번은 단기간은 가능하더라도 지속가능하지 않고, 2번의 경우가 상식적이라고 본다. 스타트업에서 널리 통용되는 Fail Fast Rapid Feedback Loop 라는 것이 바로 2번을 의미하는 것이다. 그런데 기능 조직으로 이러한 것이 가능할까? 가능하다 단, 그 기능에 대해서 가능할 것이다.
다시 한번 말하지만, 회사는 돈을 벌기 위해서 존재한다. 그 외의 것들이 중요하지 않다는 것이 아니라, 돈을 벌어야 비로소 다른 것들을 할 수 있게 된다. 돈 잘 못버는 회사 중에 복지가 좋은 회사가 있을리가 있나? 기능 조직은 회사의 목적인 “사업” 에서 관심을 다른 곳으로 몰아간다. 돈을 벌기 위한 디자인과 개발, 마케팅, 영업을 해야 그에 합당한 대우와 보상을 기대할 수 있다.
1년 동안 하나의 목표에 집중해서 팀을 운영하면 아마 더이상 할게 없을때까지 해당 분야를 발전시키게 될 것이다. 이렇게도 바꿔보고 저렇게도 바꿔보고, 잘 되면 잘되는대로 안되면 이렇게 하면 안된 다는 지식을 쌓게 될 것이다. 잘했으면 좋은 보상을 받을테고, 못했어도 나름대로의 포스트모템을 회사내 다른 팀들과 나눌 수 있다. 기대한 성과가 나오지 못했어도 실패가 아니다. 성공을 하기 위해 겪어야 하는 과정일 뿐이다.
개발팀과 디자인팀의 적절한 개발 없이, 마케팅 팀에서 돈을 쏟는게 무슨 의미가 있나? 개발 기간 선정도 어려우니 일정을 위해 야근을 해야하고, 디자이너들은 맨날 이팀 저팀 요청 때문에 결과도 알 수 없는 일들에 시달린다. 돈을 쓰는 팀은 팀대로 뭘 해도 도와주지 않으니 답답하고, 영업을 가봐야 될지 안될지 모르니 공수표만 날리고, 사업을 따오면 개발팀 입장에서 일만 더 늘어날 뿐이니 볼멘소리가 나온다. 목적 조직이라고 어찌 사람사이에 문제가 없겠냐만은 우리팀의 일을 한다는 안정감은 확실히 다를 거라는 말이다.
스타트업이 성정하고 많은 사람들이 들어오면서 자연스럽게 분위기가 변질되가는 경우를 종종 볼 수 있는데, 많은 경우 기능 조직으로 재편하면서 생기는 문제라고 본다. 경력이 쌓이니 팀장을 줘야 하고 팀장을 주니 기능 조직을 관리하게 되고 그러다보니 커뮤니케이션 코스트가 올라가고 비효율이 발생한다. 사람을 계속 뽑아도 이탈하고, 이탈한 사람의 빈자리는 채울 수 없다. 1년 일하고 나가면 1년 만큼의 빈자리가 생기고, 3년을 일했는데도 팀에 남은 것들은 별로 없어보인다.
회사가 사업을 잘했는가를 평가할 때 매출과 영업이익은 너무나 명확한 지표다. 그런데 도대체 개발팀을 디자인팀을 어떻게 평가해야 할까? 기술 개발을 잘해서? UI 가 다른 회사보다 좋아서? 정성적인 평가는 어디까지나 정량적인 평가의 보조 역할을 할 수 있을 뿐이지 정성적인 것으로 일을하는 조직의 성장은 정체될 수 밖에 없다. 왜냐고? 그것이 회사 다까라…
개발팀은 존재해서는 안된다. 디자인팀, 데이터팀, 마케팅팀 모두 마찬가지다.
1. 목적 조직은 비대해서는 안된다.
개발팀장이 마케팅 전문성을 가지긴 어렵다. 하지만, 도메인 전문성은 다르다. 목적 조직의 리더는 해당 목적에 대해서 자연스럽게 지식을 쌓아갈 것이다. 그렇게 하려면 우선 팀의 규모를 어느정도 제한해야 한다.
피자 두판의 법칙 이라는 말은 아마존이 오랜 경험에서 터득한 일종의 경험적 사실일 것이다. 나는 이 말을 좀 다른 방식으로 이해하고 싶다. 한 팀은 8명이 되어야 한다라기 보다는, 사람은 직접적인 관계를 맺을 때 한번에 7~8명 정도를 넘기 어렵다는 뜻이라고 본다. 이건 인류가 진화해서 초인류가 되기 전에는 극복하기 어려운 한계로, 업무 시간은 정해져 있고 그 시간내에 소통하는데는 어쩔 수 없는 제한이 따른다. 회식을 한번 할래도 8명이 넘어가면 장소 예약부터 수월하지 않고, 시간을 정하기는 더더욱 힘들다.
돈으로 해결할 수 있는 것이 가장 싸다. 그럼 가장 비싼것은? 커뮤니케이션이다. 사람은 자신을 표현하는데 서툴고, 어쩔 수 없이 오해와 생각 차이가 생긴다. 팀이 커지면? 더더욱 그렇다. 리더가 해야 하는 가장 중요한 일은 1대1 미팅이고 이를 통해 생각을 계속 맞춰 나가야 한다. 그러기 위해서는 의사소통의 갯수를 어느정도로 제한해야 할 필요가 있다. 인간성을 이해해야한다.
2. 목적 조직의 리더는 스스로 결정할 수 있어야 한다.
목적 조직을 회사의 뱡항으로 설정했으면 무엇보다도 권한을 이양해야 한다. 현 시점에서 그럴 수 있는 사람이 없다면 차라리 해당 팀의 리더를 경영자가 직접 하는 편이 낫다. 다만 기억할 것은 권한 위임은 기본적으로 능력있는 사람이라서 하는게 아니라, 그럴 수 밖에 없기 때문에 하게 되는 것이다. 대표는 한명이고 사람의 주의력은 다양한 것을 한꺼번에 처리할 수 없게 되어 있다. 대표는 모든 일을 다 챙겨야 한다고 주장하는 사람이 있으면, 나는 “네 말이 맞다. 운전할때는 전화를 하면서 간식을 먹어도 된다” 고 주장하겠다.
팀 그리고 서비스의 규모가 작을때야 어쩔 수 없는 부분도 있지만, 회사의 규모가 커지면 더이상 내 손안에 있지 않음을 인정해야 한다. 사람 또한 환경에 종속적인 존재로, 좋은 환경에 놓여지면 어지간하게 무능한 사람이 아닌 이상 역할에 맞게 성장한다. 성장하지 못한다면 자리를 빼앗는 것 또한 방법이다. 어려운 의사결정 이겠지만 쉬운일이면 책임자가 왜 있겠는가?
일단 결정했으면 조직의 리더가 시행착오를 겪을 수 있도록 권한과 책임을 함께 부여하고 지켜보며 피드백을 주어야 한다. 어린아이가 놀이터에 놀기 위해서는 부모의 관심이 필요하다. 부모가 딴짓을 하면서 아이를 놀게 하는걸 우리는 자율이라 부르지 않고 방치라 부른다. 다만, 조금만 위험한 것을 해도 아이를 다그쳐서는 아무것도 결정 못하는 청소년으로 자라버릴 수 도 있다. 아이가 편하게 자신을 표현할 수 있도록 바운더리를 정해주고 그 것을 넘어갈때 피드백을 통해 다시 방향성을 잡아주어야 한다. 어쩌면 기능 조직 보다 훨씬 쉬울수도 있다. 결과만 보고, 검증하면 되니까.
3. 기능 전문성은 Principal 을 통해 확보한다.
“아니 그럼 기능 조직에서 추구하는 완성도는 어떻게 확보하나요?” 와 같은 합리적인 질문이 할 수 있을거라 생각한다. 그래서 엔지니어의 경우 Principal 이라는 개념이 생겨났다고 본다. 어느정도의 수준에 도달하면 분명히 기능 조직의 끝을 보고자 하는 사람들이 필요해질 수도 있다. 단순히 주니어와 시니어의 경계가 아니라 회사에서 가장 어려운 과제에 대한 해결책을 제시하는 것들 말이다.
나는 이런 사람들을 TFT 나 용병같은 형태로 운영해야 한다고 생각한다. 그리고 최대한 한가하도록(?) 시간을 보장해줘야 한다. Principal 급 엔지니어는 데일리 코딩을 하라고 주어지는 칭호(?)가 아니다. 기술적인 한계에 다다랐을때 이를 극복하기 위한 아키텍쳐를 설계하거나 나아가 기반기술 그 자체를 의심하고 재발명 하는 역할을 주어야 하는 것이다.
또한 목적 조직에서 놓치기 쉬운 헛점들을 찾아주고 필요하면 일시적으로 팀을 꾸려서 개선 프로젝트를 진행하거나 미래의 과제에 대한 로드맵을 설계한다. 주기적으로 기능별 모임을 통해 기술적인 완성도를 추구할 수 있는 분위기를 조성하고, 교육에 대한 기회를 열어주거나 하는 등 좀 더 거시적인 관점에서 회사와 서비스를 바라보고 성장에 대한 청사진을 제공한다.
엔지니어 뿐만 아니라 디자이너도 마찬가지다. 지시하지 않고 리드 해야 한다. 큰 틀에서 따라가야할 원칙을 만들고, 의사결정을 위한 구조, 피드백 루프를 통한 점진적인 개선을 추구한다. 왜 그 회사에서 가장 디자인을 잘 하는 사람을 누가 무엇을 해야할지 결정하는데 시간을 낭비하게 하는 것인지 모르겠다. 일관적인 브랜딩, UX 의 원칙, 트렌드와 디자인 지식의 전파 등 정말로 해야하는 일들이 무궁무진하게 많다.
기능 조직의 수명은 이미 끝이 났다. 적어도 IT 서비스를 하는 기업에서는 너무나 낡고 낡은 선사시대의 화석 같은 것이다. 회사 내 모든 조직이 반드시 목적 조직이 될 필요는 없겠지만, 가능하면 최대한 추구하는 것이 좋은 방향이라고 생각한다. 특히 서비스를 직접 개발하고 운영하는 쪽이면 당연히 목적 조직이 되어야 한다.
왜 개발팀은 격리되어서 지들만의 세상에 살아야 하는 건가? 왜 디자인팀은 리드의 컨펌 하에 움직여야 하는건가? 왜 마케팅팀은 개발팀에게 아쉬운 소리를 해야하고, 영업팀은 사업과 개발을 분리해서 생각해야 하는건가? 이쯤 되니까 나는 내 생각이 편협해서 그런건가, 기능 조직이 맞는건가? 하는 생각이 들 정도다. 기능 조직은 필연적으로 리더의 한계가 팀의 생산성을 제한하게 된다. 그 중에 젤 잘해서 팀장을 맡은건데, 그 생각의 폭을 극복한다는게 구조적으로 매우 어렵다.
목적 조직은 다르다. 개발자, 디자이너, 마케터, 세일즈 모두가 한 방향을 바라보고 팀의 리더 또한 전문성을 가졌겠지만, 다른 직군의 전문성을 인정 할 수 밖에 없기 때문에 다양한 의견이 나오고 이에 대한 결과도 목적에 맞는지 평가하기도 쉽다. 레이달리오의 “원칙” 이라는 책에서의 핵심적인 메시지는 이렇다. “The best idea must win.” 회사에서 가장 좋은 아이디어를 찾기 위해서 어떻게 직원들을 성장시켜야 할까?
명확한 목표를 제시하고, 시행착오를 격게 하는 것이다. 돈을 더 잘 버는 방향으로 말이다.