적합한 사람을 버스에 태워야 한다
짐 콜린스가 쓴 『Good to Great』라는 책에 나오는 구절 중 하나입니다.
적합한 사람은 무엇일까요? 저는 회사의 조직 문화에 잘 맞는 사람이라고 생각합니다.
만약 적합한 사람이라는 것에 일률적으로 정해져 있는 답이 있다면, 누군가는 반드시 적합하지 않은 사람이 되기 마련입니다. 그러나 세상은 그렇게 단순하게 굴러가지 않습니다. 어떤 회사에서 적합하지 않다고 여겨지는 누군가도, 또 다른 회사에서는 인정받으며 일할 수 있기 때문입니다.
많은 경우, 답은 상대적입니다. 답을 찾는 주체에 따라서, 그리고 상황이나 트렌드에 따라서도 그 답이 달라질 수 있습니다.
반면에, 어떤 방향성은 보편적인 가치를 지니기도 합니다. 조직에서 추구하는 바람직한 문화에는, 보통은 모두가 맞다고 생각하는 방향성이 존재합니다.
이를테면 ‘오너십’, ‘본질’, ‘책임감’, ‘배려’, ‘주도성’과 같은 가치들입니다.
다만 이 경우에도, 그 조직이 겪어온 경험에 따라 우선순위가 달라질 수는 있습니다. 그에 따라 적합한 사람의 기준도 달라질 수 있는 것입니다.
이러한 맥락에 따라, 제가 경험한 바에 근거해 중요하다고 생각하는 적합한 사람의 기준을 하나 말씀드리고자 합니다.
바로 ‘전체를 생각하는 사람’입니다.
개인적인 측면에서 먼저 말씀드리겠습니다. 저의 직무는 개발이고, 현재는 개발자를 매니징하고 있는 역할을 맡고 있습니다. 개발자는 회사에 어떻게 기여해야 하는지에 대해 많은 고민을 해왔습니다. 그리고 내린 결론은, 바로 비즈니스 가치를 이해하는 사람이어야 한다는 점입니다.
많은 업무의 성과에는 양과 질이라는 두 가지 요소가 존재합니다. 이 둘은 때로는 트레이드오프가 되기도 합니다. 개발자의 관점에서 ‘양’이란 빠르게 개발 산출물을 내는 것이고, ‘질’이란 유지보수와 확장에 유리하며 가독성이 좋은 개발 산출물을 만드는 것입니다. 이 경우에도 잘 만들려면 느릴 수밖에 없기에, 양과 질은 상충 관계를 가지게 됩니다.
그렇다면 비즈니스 가치란 단순히 빠르게 개발하는 것을 말하는 것일까요? 그렇지는 않습니다. 단기적으로는 빠른 생산이 중요하지만, 제품의 라이프사이클이 충분히 길다면 중장기적으로 빠른 생산이 가능한 구조를 고민해야 합니다. 스파게티 코드가 되면, 당장은 빨리 요구사항을 맞췄다 하더라도 6개월, 1년 뒤에 확장할 때 더 많은 시간이 소요될 수밖에 없습니다. (비개발자 출신의 대표님들께서는 너무 늦기 전에 꼭 아셨으면 하는 부분입니다.)
이러한 점을 인지하고, 상황에 맞는 올바른 고민을 통해 의사결정을 하고 개발을 진행하는 것이 중요합니다. 예를 들어, 빠른 시장 테스트가 필요하고, 나중에 삭제할 수도 있는 부분이라면 ‘질’을 지나치게 따질 필요는 없습니다. 반면에 결제와 같이 핵심 비즈니스 로직은 빠르게 만드는 것보다 안정성을 확보하고, 최대한 확장성을 고려하여 복잡한 로직이라도 이해하기 쉽게 코드를 구성해야 합니다.
결국 개발자 입장에서 비즈니스 가치를 이해한다는 것은, 회사의 상황과 요구사항을 보고 적절한 개발 의사결정을 내릴 수 있는 능력을 의미합니다.
비즈니스 가치를 이해하지 못한다는 것은 전체를 보지 못한다는 것입니다. 더 부정적인 측면에서는, 자신만 생각하는 경우도 있습니다. 지금 당장 필요하지 않은, 자신의 커리어에 도움이 되는 기술을 선택하거나, 코드의 질에 과도하게 집착하여 회사에서 요구하는 일정을 맞추지 못하는 경우가 이에 해당합니다. 이는 자신의 커리어 성장과 뛰어난 개발자가 되고자 하는 목표 아래 회사를 이용하는 태도이기도 합니다.
비개발자는 지금 당장 요구사항을 빠르게 만들어주는 것에 열광합니다. 개발조직의 리더는 비개발자와 개발자 사이에서 비즈니스 가치에 따라 어떻게 개발해야 할지를 정리해야 합니다. 개발자에게는 양과 질 중 무엇을 우선해야 하는지에 대한 가치판단을 도와주고, 비개발자에게는 반드시 빠르게 만드는 것이 정답이 아님을 알려주어야 합니다. (몇 년간 서비스를 운영해본 비개발자분들께서는 이러한 점을 현실적으로 이해하고 계십니다.)
정리하자면,
개개인의 개발자 관점에서 비즈니스 가치를 이해하는 개발자가, 회사 관점에서 올바른 판단을 할 수 있고, 결국 ‘전체를 생각하는 사람’이다.
이번에는 팀 단위의 관점에서 말씀드리겠습니다.
팀은 기능적으로 구성되기도 하고, 목적 중심으로 구성되기도 합니다. 기능적 관점에서는 백엔드팀, 프론트엔드팀이 될 수 있고, 목적 중심으로는 도메인을 기반으로 한 주문 스쿼드, 상품 스쿼드로 나뉘거나, OKR을 기반으로 한 그로스 스쿼드, 유입 스쿼드 등으로 구성되기도 합니다.
이 팀이라는 것은, 팀을 이끄는 리더의 성향에 따라 팀의 결속력이 매우 강해지기도 하고, 그렇지 않기도 합니다. 결속력이 강한 팀은 팀 내 분위기가 화기애애하며, 효과적인 커뮤니케이션 속에서 좋은 성과를 내기도 합니다. 그렇다면 결속력이 강하다는 것은 언제나 좋은 것일까요? 그렇지 않습니다.
특히 결속력이 강한데 전체를 생각하지 못하는 리더가 구성원들에게 그 생각을 전파한다면, 그 부정적인 영향력은 더욱 커지게 됩니다. 이른바 사일로 현상이 발생하는 것입니다.
전체를 생각하지 못하는 경우, 리더가 주로 하게 되는 매니징의 핵심은 팀을 보호하는 데 초점이 맞춰지게 됩니다. 이것이 개발조직 전체로 확산되면, 개발조직을 보호하는 것이 최우선 과제가 됩니다. 개발 분야는 조금 특이한데, 개발을 직접 경험해보지 못한 비개발자는 다른 것은 이해할 수 있어도 개발은 이해하기 어렵다고 느끼기 때문에 소통에 어려움이 발생하기 쉽습니다. 이를테면 개발조직에서 어떤 프로젝트가 얼마만큼의 공수가 든다고 하면, 그것을 믿어야 하는 상황이 자주 발생합니다.
믿지 못할 경우, 대다수는 그 공수가 오래 걸린다고 판단하며, 흔히 말하는 ‘일정 박기’를 통해 개발조직을 압박하기도 합니다. 공수가 오래 걸린다고 판단하는 이유는 두 가지입니다. 첫째, 양과 질에서 양만 생각하기 때문이고, 둘째, 그 양만 고려한 결과 반복된 코드가 많아져 개발자가 더 많은 공수를 산정하게 되는 경우입니다.
예전에는 한두 명이 뚝딱뚝딱 만들었는데, 지금은 왜 더 비싼 개발자가 더 오래 걸리냐는 질문은, 개발조직을 인하우스로 둔 조직에서 매우 흔하게 들리는 피드백 중 하나입니다. 여담이지만, 제품의 라이프사이클을 고려한 공수 파악 및 일정 조율, 그리고 이를 연결하고 이해시키는 개발 리더의 역할이 매우 중요하다고 다시 한번 강조드리고 싶습니다.
다시 돌아와서, 개발자를 보호하는 리더는 개발자가 야근하는 것, 일정을 독촉받는 것에서 보호하는 것이 최우선 과제가 됩니다. 물론 이는 개발자 입장에서는 좋은 리더처럼 보일 수 있습니다. 그러나 여기에서 사일로 현상이 심화되고, 특히 결속력이 강한 개발팀의 경우 리더에 대한 평가와 비즈니스 측면에서의 현실 간에 모순이 발생하게 됩니다. 개발자들은 리더를 굉장히 좋게 평가하지만, 비즈니스는 잘 진척되지 않고, 비개발조직은 그 개발조직을 신뢰하지 않게 됩니다.
사일로 현상이 심화되면, 보수적인 조직문화가 뿌리내리게 됩니다. 다른 조직을 같은 비즈니스 목표를 추구하는 한 팀의 일원으로 보지 않습니다. 업무, 요구사항을 전달하는 조직을 ‘강요하는’ 조직으로 여기게 되고, 그들과의 커뮤니케이션은 점점 더 껄끄러워집니다. 한마디로, 다른 조직은 개발조직과는 다른 목적을 가진 조직이며, 그들이 추구하는 목적은 개발조직의 목적에 반한다고 여기게 됩니다. (일정을 압박하는 다른 조직과, 그것을 방어하는 개발조직의 관계를 떠올리면 이해하기 쉽습니다.)
더 큰 문제는, 이러한 상황에서 회사의 비즈니스가 제대로 진행되지 않을 확률이 높다는 것입니다. 커뮤니케이션 비용은 높아지고, 개발조직의 구성원들은 타팀과 일정을 강요하는 다른 조직에 대한 불만을 가지게 됩니다. 싱크되지 않고, 납득되지 않는 상황에서는 업무가 원활히 진행되기 어렵습니다. 한 회사의 구성원들이 서로 다른 목적을 바라보게 되면, 이기심이 발동될 수밖에 없습니다. 우리 팀이 다른 팀보다 더 소중하다는 생각이 생기면, 우리 팀을 위한 의사결정을 하게 됩니다.
전체를 생각해야 합니다. 팀의 리더는 구성원들에게 회사 입장에서 어떻게 사고해야 하는지를 끊임없이 알려주어야 하고, 적절히 개발조직의 성과를 드러내며, 코드의 질이 왜 중요한지를 비개발조직에도 충분히 설명하여 납득시켜야 합니다. 중간다리 역할을 해야 합니다. 그래야 조직 간 신뢰가 쌓입니다. 이 신뢰는 선순환을 만들고, 전체가 같은 팀이라는 인식을 심어주며, 더 빠르고 효과적인 비즈니스 아웃풋을 만들어낼 수 있습니다.
따라서, 제 경험에 따른 결론은 이렇습니다. 회사에 필요한 인재의 중요한 덕목 중 하나, 특히 리더에게 필요한 그 자질은 바로 전체를 생각할 줄 아는 사람입니다.