이 글은 QANDA에 재직 중일 때 작성한 글입니다.

멘탈 모델 — 세상을 보는 마음의 안경

같은 직종의 팀이라고 할지라도 팀마다 분위기나 성향은 다를 것입니다. 구직을 하고 있는 상황이라면 목표한 회사에 대해서도 면밀히 검토해야 할뿐더러, 자신과 성향이 잘 맞는 팀인지 확인하는 것도 중요합니다. 그래야만 일상의 대부분을 차지하는 회사 생활이 즐거울 것이기 때문입니다.

저희 콴다 프론트엔드 팀에 관심을 가져주시고 지원해주시는 분들께서 가장 많이 질문하셨던 것 역시 “이 팀은 어떤 성향의 팀인가?”였습니다. 이제 보상이나 복지 같은 전통적인 기준을 넘어서 함께 일하는 사람이 누구인가 라는 기준이 구직자에게 매우 중요해졌음을 느낍니다.

많은 분들께서 궁금해 하신 만큼 저희가 미리 저희 팀의 특성을 블로그에 공개하고자 합니다. 그렇게 하면 구직자분들께서 팀의 성향을 더 잘 파악하시고, 전략적인 구직활동을 하시는 데에 도움이 될 것이라 생각했습니다. 그러면 저희 팀이 어떤 사고방식과 멘탈 모델을 갖고 업무에 임하는지 소개해보겠습니다.

저희 팀의 멘탈 모델 중 가장 강력한 세 가지는 다음과 같습니다.

1. 자유로운 의사소통 분위기가 훌륭한 팀의 기반이다.
2. Agile은 모든 곳에 적용될 수 있다.
3. 프로세스는 본질이 아니다.

하나씩 자세히 이야기해 보겠습니다.

Model 1. 자유로운 의사소통 분위기가 훌륭한 팀의 기반이다

저희는 개인일 때 보다 팀으로 있을 때 더 빠르게 성장할 수 있다고 믿습니다. 다만, 그 전제 조건은 ‘팀 내에 자유롭고 적극적인 의사소통 분위기가 존재한다'는 것입니다.

훌륭한 팀이란 무엇인가?

전 세계 어디에서나, 사람이 ‘그냥 모여있는 집단'은 Team으로 불리지 않습니다. 공동의 목표를 갖고 의사소통을 통해 문제를 효과적으로 해결하는 집단만이 Team으로 불릴 자격이 있습니다. 팀에 속해 있음에도 불구하고 개인으로서도 충분히 할 수 있는 일들을 한다면, 굳이 팀으로 일할 이유가 없을 것입니다.

저희는 협업으로만 가능한 일들을 최대한 발굴합니다. 이렇게 좋은 동료들과 팀으로서 일할 수 있는 시기는 귀중하기 때문에, 이 시기 동안만 할 수 있는 일들을 최대한 많이 경험하고자 합니다. 그래서 혼자일 때와는 명백하게 다른 결과물들을 낳는 것이 저희가 함께 일하며 명심하고자 하는 중요한 기준입니다. 그리고 이를 잘 해내는 팀이 훌륭한 팀이라고 생각합니다.

집단지성

집단지성이란 단어는 살면서 평소에 많이 접하게 되기에, 마치 고리타분한 속담처럼 그 중요성이 쉽게 희석되는 것 같습니다. 하지만 평범한 팀이 훌륭한 팀이 되기 위해 필요한 필수요소 중 하나가 바로 집단지성이라 생각합니다. 서로의 지식이 잘 뒤섞이는 팀이 그렇지 못한 팀보다 문제를 더 빠르고 참신하게 해결할 것이란 건 자명합니다.

집단지성의 예를 하나 들어보겠습니다. 글로벌 웹 서비스를 운영 중인데, 특정 국가에서 사이트의 첫 로드 속도가 위험 수준으로 낮은 상황이라고 하겠습니다. 속도를 개선하기 위해 팀원 한 명이 ‘코드를 정리하여 번들 사이즈를 줄이자’는 아이디어를 내었습니다. 좋은 기초적인 방법이지만, 이미 많은 코드가 최적화 되어 있어 임팩트 있는 개선을 가져오진 못할 것 같습니다.

팀 내에 고민을 공유하니 한 동료가 ‘해당 국가와 물리적 위치가 가까운 곳에 서버를 추가로 배치하자’는 의견을 제시했습니다. 또 어떤 동료는 ‘리소스를 유저에게 보내줄 때 사용하는 압축 알고리즘을 새로운 알고리즘으로 변경해보자’는 아이디어를 주었습니다. 전자는 문제의 원인에 근본적으로 접근하는 방법이지만 구현의 난이도가 높았고, 후자는 1분도 안 걸리는 작업을 통해 비슷한 효과를 낼 수 있었습니다. 작업자는 자신이 생각지도 못한 방법으로 원하던 것보다 더 많은 결과를 얻을 수 있었습니다.

이렇게 지식을 섞는 것은 일상에서 무의식중에 일어나는 일이지만, 이를 의도적으로 이용하는 것이 저희 팀의 특성입니다. 문제를 해결하는 도구로서 집단지성을 사용하는 것을 독려합니다. 그러면 팀원 개개인은 언제든 난관에 부딪힐 때 팀원들로부터 집단지성 찬스를 받을 수 있다는 믿음을 바탕으로 일하게 됩니다.

집단지성의 중요성은 시대를 막론합니다— 출처: 문화재청

의사소통이 자유로운 분위기

훌륭한 팀이 되기 위해서는 많은 대화와 상호작용이 필요합니다. 간단한 의견을 제시하는 것도 눈치가 보이거나 어려운 분위기라면 제대로 된 협업이 불가능합니다. 그런 상황에선 팀원들은 도전하지 않게 되고, 본인만의 이익을 추구하는 방향으로 일하게 됩니다. 그러다가 결국 팀에서 일하는 것이 개인으로서 일하는 것만 못하게 됩니다. 따라서 의견을 자유롭게 던질 수 있는 분위기가 훌륭한 팀의 기본적인 요구사항입니다.

의견 내기에 안전한 분위기는 어떻게 조성할 수 있을까요? 저희는 팀원들이 서로 주고받는 신호의 종류가 다양할수록, 그리고 신호의 빈도가 잦을수록 의견 내기의 적극성이 증진되는 것을 느꼈습니다.

예를 들면, 코드 리뷰를 쉽고 빠르게 할 수 있는 환경을 만들고, 다양한 Raid(Raid 시스템에 대한 자세한 설명은 이 포스팅을 참고해주세요)가 진행될 수 있는 기회를 제공한 이후로 팀 내에서 생각의 교환이 매우 자주 일어나게 되었습니다. 이런 잦은 생각의 교환은 팀원들에게 본인의 의견은 어떤 것이든 제시할 수 있다는 자신감을 줍니다.

저희는 인간적인 친밀감 역시 훌륭한 팀을 위한 중요한 신호 유형이라고 보았습니다. 따라서 매일 TMI를 공유할 수 있는 창구를 제공한다거나, 모두 일과를 잠시 쉬고 미술관에 가는 등의 활동들을 진행했습니다. 그리고 이는 팀원들이 누구와도 편하게 대화할 수 있는 분위기를 만드는 데에 큰 도움이 되었습니다. (여기에 더해 전사적인 토마토 주기 문화도 한몫했습니다.)

떠들 수 있는 곳이 있다면 떠들게 되는 것 같습니다

데이터 노동이 만연한 세상에 대해 고찰 중인 콴다 프론트엔드 팀

저희가 서로 토마토를 주고 받는 이유는 무엇일까요? -> 보러가기

Model 2. Agile은 모든 곳에 적용할 수 있다

확고한 계획을 세우고 일하기에는 불확실성이 너무나 높은 시대입니다. 저희는 애자일 하지 않으면 살아남기 어려운 시대가 왔다고 생각합니다. 따라서 개발뿐만 아니라 모든 업무 과정에 Agile을 적용하고 있고, 그 효과를 체감하고 있습니다.

Agile의 개념을 처음으로 확립한 17인의 소프트웨어 전문가들 & 애자일 선언문

Agile이란 무엇인가?

이 글을 읽는 분 중에 애자일을 모르는 분은 없을 것이지만, 저희가 해석한 애자일에 대해 짧게 설명해보겠습니다.

개발자에게 들어오는 요구사항은 항상 변합니다. 그 변화의 주기가 짧다면 심지어 매일 변경될 수도 있습니다. 이런 잦은 변화는 안 좋은 것일까요? 꼭 그렇진 않습니다. 변화하는 것은 소프트웨어의 본질이고, 따라서 소프트웨어를 만드는 팀은 그런 변화를 품어야 하는 숙명을 갖게 됩니다. 하드웨어와는 다릅니다.

애자일은 이렇게 빠른 속도로 변하는 요구사항에 맞서 소프트웨어를 빠르게 개발하는 프로세스입니다. 그렇게 하기 위해서 프로젝트 개발 과정을 작은 반복 주기로 나눕니다. 긴 시간 동안 개발하고 마지막에 대량으로 QA 해서 배포하는 워터폴 방식과는 다릅니다. 애자일은 보통 1주일에서 2주일이라는 짧은 반복 주기 마다 QA가 완료된 결과물이 발생해야 합니다.

작은 반복 주기로 나눴을 때의 가장 강력한 장점은 변화에 대응할 수 있다는 점입니다. 매 주기에 들어가기 전에, 현 상황에서 우선순위가 가장 높은 것들을 먼저 작업하도록 계획을 수정할 수 있습니다. 그리고 이전 반복 주기에 만든 것을 되돌아보며 “우리 이렇게 가면 되는 거 맞나?” “우리가 원하는 게 이거 맞나?”를 끊임없이 확인합니다.

이때 우선순위가 변경되는 것을 환영해야 할 이유가 있습니다. 잘못 항해하고 있음을 깨닫고 방향을 제대로 다시 수정하는 것이기 때문입니다. 이렇게 자주 방향키를 고쳐 잡다 보면 결국 진정으로 가치 있는 제품에 도달하게 됩니다. 아무런 역경도 없고 편안하지만 무가치한 것을 만드는 것보단, 세상에 바쁘게 대응하더라도 가치 있는 것을 만드는 것이 훨씬 낫습니다. 우리의 인생, 회사, 그리고 유저에게 모두 큰 보상을 주기 때문입니다.

Agile 방법론 자체에 대해서는 하고 싶은 얘기가 더 있지만 차후 다른 포스팅에서 다뤄보도록 하겠습니다.

Next Level — Agile for Everything

애자일의 핵심은 “잦은 피드백”입니다. 우리가 만들고 있는 것이 유저에게, 그리고 이 세상에 정말로 효과적인가를 자주 물어보고, 피드백을 반영하여 다시 앞으로 나아가는 것이 바로 애자일의 정수입니다.

우리는 종종 자신만의 논리에 파묻혀서 현실을 보지 못하는 함정에 빠집니다. 또한 디즈니나 넷플릭스 같은 미디어가 만들어낸 가짜 현실을 실제 현실로 착각하는 경우도 많습니다. 우리가 만든 것이 유저나 이해관계자가 정말로 원하는 것인지를 자주 검증한다면, 진정 쓸모 있는 제품을 만들 수 있을 것입니다. 또한 우리 팀은 이 비즈니스와 진정한 현실을 깨닫게 되어 점점 더 타율을 높여갈 수 있을 것입니다.

잦은 피드백을 통해 세상을 배워나간다는 이 아이디어는 제품 개발에만 적용할 수 있는 것은 아닙니다. 우리의 모든 사고방식과 행위에도 애자일의 씨앗을 심을 수 있습니다. 예를 들어, 개발하는 도중에 기획에 의문이 들어도 우선 기획을 믿고 개발을 밀고 나가는 사람이 있는 반면, 그 즉시 관계자에게 질문하는 사람이 있습니다. 같은 시간이 주어진다면 결국 더 가치 있는 제품을 만드는 사람은 후자일 것입니다. 이유는 아실 거라고 생각합니다.

제품만큼 중요한 것이 우리의 소프트 스킬입니다. 내가 가진 소프트 스킬이 성숙해지고 팀에 더 잘 어울릴 수 있게 하기 위해서도 피드백이 필요합니다. “나의 협업 능력에는 문제가 없는가?”를 동료들에게 짧은 반복 주기로 물어보고, 의문이 들 때마다 물어본다면 소프트 스킬은 올바른 방향으로 빠르게 성장할 것입니다. 저희 팀은 첫 번째 멘탈 모델인 “Model 1. 자유로운 분위기가 훌륭한 팀의 기반이다”를 통해 동료들과 피드백을 주고받는 게 자연스러운 환경을 조성하고 있습니다.

저희는 통상적인 Agile의 개념인 “반복 주기마다 결과물을 가지고 회고하는 것”을 넘어서, 어떤 것이든 잦은 피드백을 통해 개선하는 것이 가능하고, 유용하다는 사실을 깨달았습니다. 불확실성이 가득해 예측 불가능한 현시대에서는 이렇게 모든 곳에 Agile을 적용하는 것이 **“이기는 전략”**이라고 생각합니다.

Model 3. 프로세스는 본질이 아니다

위클리 미팅, 원온원, 스크럼, KPT 회고 등 누구나 캘린더에 주기적으로 걸린 일정이 있을 것입니다. 또한 KPI, OKR, 피어 리뷰 등 분기마다 설정하고 따라야 할 일도 많습니다. 이렇게 목표를 달성하기 위해 구축하는 것들을 “프로세스”라고 지칭해보겠습니다. 저희는 프로세스를 신뢰하지 않습니다. 무슨 이유에서 그럴까요?

프로세스의 함정

잠시 학창 시절로 돌아가 보겠습니다. 좋은 대학에 가기 위해 열심히 공부하는 학생들 중 유난히 *“하루 공부 시간”*에 매달리는 학생들이 있습니다. 하루 10시간 이상 공부하기 등의 목표를 세우고, 앉아서 시간을 채우며 위안을 얻습니다. 그러나 모두가 알다시피 좋은 대학에 갈 수 있는 자격은 시험 성적으로 주어지는 것이지, 공부 시간으로 결정되는 것이 아닙니다.

따라서 본질은 시험 점수를 잘 받는 것입니다. 이 본질에 입각하여 “본인이 모르는 지식이 무엇인지 파악하고, 틀린 문제를 더 이상 틀리지 않도록 하는 것”이 목표를 달성하는 가장 빠른 길일 것입니다*(여담이지만 콴다가 궁극적으로 도움을 주려는 문제가 이것입니다)*. 그럼에도 불구하고 “사당오락” 같은 본질에서 벗어난 문구가 많은 학생들을 잘못된 길로 오도하고 묵묵히 걸어가도록 만듭니다.

본질과 목표 의식을 잃은 프로세스는 공허하다는 점을 이야기하고 싶었습니다. 저희 팀 역시 이러한 프로세스의 함정에 빠진 경험이 있습니다. 저희는 팀과 팀원의 기술적 성장을 위해 다양한 레이드를 진행하고 있습니다. 이 레이드 시스템을 통해 프론트엔드 팀은 Monorepo 도입, TDD 문화와 코드 리뷰 문화 강화 등 가시적인 성과를 많이 이룰 수 있었습니다.

몇 번의 성공을 하다 보니 *“레이드를 진행하면 무조건 좋은 성과가 난다”*는 위험한 착각에 빠졌습니다. 사람이 매주 모여서 뭔가를 하면 자동으로 결과물이 나올 것이라 기대한 저희는 이후 여러 차례 실패를 겪어야만 했습니다. 저희가 저지른 오류는 프로세스는 도구일 뿐이라는 점을 망각한 것입니다. 프로세스 자체는 본질이 아니었습니다.

프로세스를 “운전"하라

아무런 체계 없이 일하는 것은 팀에 불안감을 조성할 수 있습니다. 프로세스는 저희에게 “틀”을 제공하여 이 불안감을 없애는 데에 도움을 줍니다. 그리고 절차와 체계를 따르면 목적지에 도달할 것이라는 희망을 줍니다. 이는 프로세스의 좋은 점입니다.

그러나 프로세스가 모든 것을 해결해줄 것이라고 믿게 되는 순간, 구성원들은 본질을 잊고 시간만 채우게 됩니다. 그러다가 점점 수동적으로 변하고 결국 열심히 일하지 않게 됩니다. 프로세스 내에서 각 개인은 책임감을 가지고 수행해야 할 역할이 있습니다. 하지만 프로세스에 대한 맹신이 책임 의식을 분산시키고 결국 누구도 100%의 퍼포먼스를 내지 않는 무서운 결과를 가져옵니다. 그 유명한 “OKR”이나 “Agile” 등을 회사에 도입해도 상당수가 실패하는 이유가 바로 이러한 주체성의 부재 때문일 것입니다.

우리는 동료들과 프로세스에 탑승하여 어두운 밤길을 탐험하는 것과 같습니다

저희는 프로세스를 목표를 향해 빠르게 가게 해주는 탈것(Vehicle)으로 여기는 것이 주체성을 잃지 않게 해주는 효과적인 멘탈 모델이라는 것을 알게 되었습니다. 탈것은 우리를 질주할 수 있도록 해주지만, 우리가 의도적으로 조작하지 않으면 제대로 굴러가지 않습니다. 마찬가지로 우리가 일을 함에 있어서도 본질을 달성하기 위해 치열하게 고민하고, 일의 진행에 적극적으로 개입해야만 프로세스가 작동하여 목적지에 빠르게 다다를 수 있을 것입니다.

예를 들어 칸반이나 스프린트와 같은 ‘검증된’ 스케줄링 프로세스를 사용 중일 때, 태스크들이 잘 처리되고 있으면 일이 잘 진행되고 있다고 착각하기 쉽습니다. 그러나 무엇이 본질이던가요? 보통은 태스크를 시원시원하게 해결하는 것보다는 제품을 더 좋게 만들 수 있는 방법을 신중하게 고민하고, 의문을 던지고, 확신을 갖고 작업하는 것이 본질에 더 가까울 것입니다. 검증된 프로세스의 권위에 압도되지 않아야 합니다. 프로세스는 ‘따라야만 하는 규칙’이라기 보다는 ‘탈것’이며, 우리의 목적지에서 멀어지지 않도록 속도와 방향을 꾸준히 수정해야 합니다.

따라서 저희는 프로세스를 신뢰하기보단 구성원들을 신뢰하는 것이 더 효과적인 마음가짐이라고 생각합니다. 어떤 일이든 믿고 맡길 수 있으며, 본인 또한 동료들의 신뢰를 받기 위해 노력하는 환경만이 구성원들의 능력을 100%로 이끌어낼 수 있기 때문입니다.

마치며

이상 저희가 어떤 렌즈들을 착용하고 일하는지 소개해보았습니다. 이 글을 읽는 분께 저희 팀의 성향이 잘 전달되었다면 좋겠습니다.

저희는 논의와 사유를 통해 다양한 멘탈 모델들을 만들고 있습니다. 이 멘탈 모델들은 곳곳에서 산발적으로 발생하지만, 재미있게도 단 하나의 방향을 가리킨다는 사실을 깨달았습니다. 바로 우리 팀원들이 장기적으로 더 행복하게 일하고 살아갈 수 있는 방향입니다.