1. 지표란 무엇이고, 왜 지표가 필요한가요?

지표란 달성하고자 하는 목표 또는 현재 수준이나 진행 과정 등을 정량적으로 나타낸 것입니다.

지표란 대상을 양적으로 ‘측정’한 값을 의미합니다. 매출액이 되었건, 프로젝트 진행율이 되었건, 상품 반품률이 되었건 무언가를 측정하는 이유는 측정을 통해 대상을 더 체계적으로 이해하고 효율적으로 관리하기 위해서 입니다.

즉 측정은 그 자체로 목표가 아니라 관리라는 목표를 달성하는 수단이라는 의미입니다. 현재 상태, 진행 정도, 목표 수준 등을 수치로 나타내면 일이 계획대로 되고 있는지, 효율적으로 진행되고 있는지, 우리가 잘 하고 있는지 못하고 있는지를 쉽게 파악할 수 있습니다. 하지만 세상에 공짜가 없듯 측정도 비용이 들기 때문에, 측정의 목적에 맞추어 적절한 방식을 선택하는 것도 중요합니다.

예를 들어, 100대의 기계가 돌아가는 공장에서 기계마다 가동효율을 평가하여 성능이 떨어지는 기계를 사전에 파악하기 위해 처음으로 모니터링을 한다고 가정해보겠습니다.

아직 아무것도 없는 상태인데, 만약 실시간으로 데이터를 기록하려고 한다면, 기계마다 측정하는 사람이나 모니터링 시스템이 붙어서 어떤 주기로 제품을 완성시키는지 기록해야 합니다. 기록된 자료가 오류없이 정확한지 확인도 필요하겠죠. 그렇게 기록된 100대의 기계에 대한 각각의 자료를 계속 수합하는 과정도 필요하구요. 이 모든 과정을 실시간으로 업데이트 해주려고 하면, 관리를 통한 효용보다 관리 비용이 더 커질지도 모릅니다.

하지만 몇 시간 또는 하루 단위로 각 기계가 몇 개씩 완성품을 만들었는지 파악하는 것으로도 모니터링하기에 충분하다면, 훨씬 적은 비용으로 기계별 성능 모니터링 데이터를 수집할 수 있습니다.

그런데 만약 기계의 성능을 모니터링하는 것만으로는 충분하지 않고, 그 기계가 언제 도입되었고 실제로 얼마나 가동되었는지, 생산성이 낮아지는 요인은 무엇인지, 가동률에 영향을 미치는 요인은 무엇인지와 같은 정보가 필요하다면, (기계의 최근 생산성을 더 잦은 빈도로 측정하는 것은 중요하지 않지만) 그 정보 이외에도 도입시기나 과거의 가동 기록 등에 대해 일정 기간 이상의 관찰 데이터도 수집되고 관리되어야 합니다. 

이처럼 지표를 수립하기 위해서는 일단 우리가 ‘무엇을’ 알아야 하고, ‘얼마나 정확하게’ 또는 ‘얼마나 신속하게’ 알아야하는지, 이 정보를 가지고 무엇을 하려고 하는지가 함께 정의되어야 합니다.

2. 지표는 언제 수립하나요? 

제품의 기능을 개발한다면, 제품의 상세한 스펙이나 기능을 기획하기 전에 ‘고객이 겪고 있는 불편이 무엇인가?’, '어떤 고객이 그런 문제를 겪고 있는가?', ‘그 불편을 어떻게 해결해야 하는가?’, '그 문제를 해결하는 것이 우리의 비즈니스에 어떤 가치가 있는가?' 를 정의하는 단계에서부터 어떤 지표를 수립할 지 고민해야 합니다.

지표는 우리가 지금 하고 있는 일의 목표가 무엇인지 길을 잃지 않도록 도와주는 수단이기도 합니다.

여럿이 함께 협업하는 과정에서 궁극적으로 무엇을 달성하기 위해 이 일을 하고 있는지 공동의 목표를 선명하게 해주죠.

(사족이지만 이런저런거 개발이고 뭐고 다 하고 나서, 뭔가 성과를 보여줘야 하니 이런저런 지표 좀 주세요~ 하는 상황에 던져질 때, 심지어 그 지표가 죄다 vacant metric같을 때....DA로 일하면서 그만큼 현타가 오는 순간도 없는 거 같습니다....)

3. 좋은 지표는 어떻게 세우나요? 

좋은 지표란 상황, 제품 특성, 비즈니스 모델 등에 따라 다릅니다. 비즈니스 지표인지, 프로덕트 지표인지에 따라서도 상당히 크게 달라지고, 이미 존재하는 프레임워크도 너무 많죠. 어디에선 답이었던 것이 어디에선 전혀 쌩뚱맞은 지표가 되기도 합니다. 

똑같은 쇼핑검색 서비스의 개선이라도, 유저가 더 많은 몰랐던 물건을 발견하게 해주고 더 오랫동안 체류하게 만드는 것이 목표인지, 아니면 찾는 물건에 도달하는 시간을 줄여 궁극적으로 구매전환까지의 퍼널을 개선하는 것이 목표인지에 따라서 동일한 기능이어도 서로 전혀 다른 데이터를 전혀 다른 관점으로 보게 됩니다.

비즈니스의 특성이나 성장모델에 따라서 무료유저가 가치인 경우도 있지만, 단순한 비용인 경우도 있구요. 

그래서 결국 지표란 우리가 해결하고 싶은 문제의 상태를 포착하고 측정하기 위한 것이라는 점을 이해해야 합니다. 

우리가 해결하고 싶은 문제가 무엇인지 문제정의가 명확해야, 우리가 무엇을 측정하고 싶은지, 그걸 알기 위해 어떤 숫자를 어떻게 봐야하는지를 구체화할 수 있으니까요. 

그런 맥락에서, 다음과 같은 질문에 답하지 못할때는 좋은 지표를 설정하기 어려웠던 것 같습니다. 

• 지금 하는 그 일을 통해 해결하려고 하는 문제가 무엇인가요? 
• 그게 해결되면 누가 어떤 베네핏을 느끼게 되나요? 
• 그 문제를 겪고 있는 사람은 얼마나 되나요? 
• 그 문제가 해결되면 우리의 비즈니스에는 어떤 임팩트가 있나요?

이런 질문들에 답할 수 있는 여러가지 가설들을 고려하면서, 그 과정에서 필요한 기초 데이터도 보게 됩니다. 그 과정에서 문제정의를 뾰족하게 하면서 기대하는 임팩트가 무엇인지를 합의할 수 있고, 그 임팩트를 측정할 수 있는 가장 적절한 데이터가 무엇이고 그 데이터를 보는 가장 적합한 관점이 무엇인지를 반영하여 지표를 수립하게 됩니다. 

4. 좋은 지표의 공통 요건

좋은 지표는 우리가 해결하고 싶은 문제의 status를 잘 포착해주고, 그 문제를 해결하기 위해 우리가 하는 일들(input)과 실제로 문제에 미치는 영향(output)의 흐름을 잘 보여주는 지표입니다. 즉 문제정의를 기반으로 문제와 해결책들의 임팩트를 잘 보여주는(=목적과 성과를 드러내는) 지표입니다. 

저는 그 이외에 가장 중요한 것으로 다음 두 가지를 고려합니다.

• Measurable : 측정가능한가? 측정이 지나치게 어렵거나 비용이 많이 들지 않는가? accuracy는 얼마나 높아야 하는가? proxy로 고려할 수 있는 대안이 있는가?  

아마 이 부분은 환경과 상황에 따라 매우 다를 것 같은데, 리소스가 제한된 스타트업 환경에서는 정확도와 비용, 그리고 속도 간의 트레이드 오프를 인지해야하기 때문에, 측정가능성에 대한 판단이 중요하다고 생각하게 되었는데요, 아무래도 충분한 인프라가 갖춰진 환경이라면 훨씬 덜 신경써도 되는 부분이겠죠. 

• Sepcific : entity 레벨에서 대상/기간/속성/범위 등이 구체적으로 정의되어 있는가? 

똑같은 지표를 보고도 서로 다른 정의를 염두에 두고 있어서 완전히 미스커뮤니케이션하는 경우가 제법 생깁니다. 특히 비율 등을 많이 사용하게 되는데, 같아 보여도 사실 분모 자체가 다르거나, 시간축의 기준의 완전히 다르다거나 하는 경우도 흔하고, 때로는 a가 하던 데이터 작업을 b가 하면 전혀 다른 결과가 나오는 경우도 있는데, 이런 문제는 대부분 충분히 구체적이지 않은 데이터 정의에서 나옵니다. 

5. 사족

• 좋은 지표는 우리가 더 잘 할 수 있도록 도와주지만, 좋은 문제정의 없이 좋은 지표는 나올 수 없습니다.
• 경영학의 왕 피터 드러커가 했다고 회자되는 말 중에 “측정할 수 없다면 관리할 수 없다”는 말이 있는데, 사실 피터 드러커는 그렇게 말한적 없다고 합니다ㅋㅋ 정량화할 수 없다고 해서 중요하지 않다거나 관리할 필요가 없다는 뜻은 아니니까요. 눈에 보이지 않고 지표로 드러나지 않더라도 주목해야 하는 것들이 있다는 점도 간과하지 않아야 겠습니다. 

• 원문 작성일 : 23년05월30일
• 사내에 발행했던 데이터레터 중 한 편으로, 공개를 위해 내용을 약간 수정하였다. 사내에 발행한 버전에는 실제로 회사 프로덕트를 가지고 만든 예제와 여러가지 지표 프레임워크에 대한 구체적인 소개도 들어갔음. 

A/B테스트, 데이터 기반 의사결정을 이야기할 때, 정말 지겹도록 많이 듣는 단어입니다.

그런데 이 흔하디 흔한 A/B 테스트가 정작 제대로 수행되는 경우는 생각보다 드뭅니다.

A/B 테스트는 실험이 제대로 설계되지 않으면 이 테스트의 도입 취지에 맞춰 더 좋은 의사결정을 하는데에 도움이 되기는 커녕, 리소스만 낭비하고 오히려 잘못된 정보로 사람들을 잘못된 판단으로 이끌 수 있기 때문입니다.

그래서 앞으로 몇 번의 시리즈를 통해 이 A/B 테스트를 이루는 중요한 개념들을 설명하려고 합니다.

A/B 테스트가 뭔데??

A/B 테스트는 무작위 대조 실험(RCT: Randomized Controlled Trial)이라는 응용통계 기법을 제품 개발 등에 적용할 수 있게 간소화한 버전으로, 일종의 실험 방법론입니다.

이 ‘무작위’ ‘대조(통제된)’ ‘실험’ 이라는 각각의 단어가 A/B 테스트의 핵심 키워드입니다.

오늘은 이 중 쉽지만 가장 중요한 실험이라는 단어의 의미를 설명해보려 합니다.

여러분, 혹시 학교 다닐 때 과학시간에 실험 했던 것 생각 나시나요?

이런 실험을 왜 했을까요? 특정한 화합물 A와 B를 조합했을 때 어떤 결과가 나오는지를 배우기 위함이었을까요?

실험을 직접 해보는 근본적인 목적은 사건을 발생시키는데 필요한 조건이 갖춰져 있을 때 매번 같은 결과가 나온다는 것을 배우기 위해서입니다.

즉, 물을 가열하면 빨리 증발한다는 가설을 반복해서 확인해보면서, ‘Y라는 결과의 원인은 X’라는 답을 얻으면, X를 반복함으로써 Y역시 재현될 수 있다(젖은 옷에 열을 가하면 빨리 마른다)는 지식을 얻는 것이죠.

즉 실험의 핵심은

• X가 Y를 일으킨다는 가정을 확인하여
• (X가 정말 Y의 원인이라면) X의 반복으로 Y도 재현될 수 있다는 지식

을 얻는 것입니다.

A/B 테스트가 ‘지식’이 아니라 ‘실험’인 이유는, 우리가 바꾸는 어떤 조건이 결과에 영향을 미친다는 인과성에 대한 가설을 확인하는 과정이기 대문입니다.

이 ‘실험’이 의미하는 바가 좀 감이 오시나요?

성공적인 실험조직의 사례

A/B 테스트의 가장 유명한 사례는 bing의 검색엔진 결과 화면입니다.

검색결과의 길이를 조금 늘린 버전을 보여주자는 굉장히 사소해보이는 아이디어는 너무 사소해보여 우선순위가 몇 달이나 밀리고 있었습니다.

그러나 그 아이디어를 빠르게 실험하려고 나선 한 엔지니어 덕분에 실험이 이루어졌고, 실험의 분석결과 핵심적인 사용자 경험을 손상 시키지 않고도 매출을 12%나 증가시킨다는 것을 알게 되었습니다. 이는 빙 전체 제품에 적용되었고 빙 역사상 최고의 매출을 창출하는 아이디어가 되었습니다.

검색결과를 이러저러하게 바꿔 보여준다(X)가 사용자의 전환율을 높인다(Y)는 결과를 가져온다는 것을 실험을 통해 검증하고, 아이디어의 임팩트를 정량화하여 제품과 비즈니스를 성장시킬 수 있었던 것이죠.

하지만!!

현실에서는 우리가 지금 임팩트를 측정하고 싶은 X 말고도, Y에 영향을 줄 수 있는 요인이 너무나 많습니다. 정말 아무 이유 없이 지표가 개선되거나, 악화되는 경우도 생각보다 정~말 많은데, 그럴때조차도 의사결정을 위한 실험은 실험결과가 우연이나 다른 요인 때문이 아니라 X 때문이라는, Y에 대한 ‘인과성’을 보장해줄 수 있어야 합니다. 그러기 위해서는 충분한 샘플수, Bias가 최소화될 수 있는 실험 설계, 실험 결과에 대한 통계적 검증과 같은 것들이 필요합니다. 

때로는 실험을 할 수 없는 경우도 있습니다. 어떨때는 실험을 통해 기대할 수 있는 최고의 결과나 최악의 결과에 비해 실험 자체에 드는 비용이 너무 클 때도 있구요. 특히나, 조직적인 차원에서 실험을 통해 제품을 개선하는 문화를 만들어가려면 가장 중요한 것이 실험 결과 효과가 없는 것으로 밝혀졌을 때 그 아이디어를 폐기할 수 있느냐 인데, 실험을 해보면 거의 대부분의 아이디어가 임팩트가 없다는 것을 알게 되기 때문에 실험 역시 시스템적으로 효율화해야 합니다. 

아마존, 마이크로소프트, 우버, 에어비앤비와 같은 내노라하는 세계적인 팀에서도 실험을 통해 정말 효과를 검증하는데에 성공하는 아이디어는 20%도 되지 않는다고 합니다. 하지만 이미 어느정도 규모의 경제를 달성한 상태라면, 정말 작은 지표의 개선도 큰 임팩트가 되기 때문에 정교한 A/B 테스트 역시 훨씬 더 그 가치가 큽니다. 

반면 리소스가 제한된 스타트업 환경에서 백로그에 할 일이 쌓여있지 않은 팀은 정말 드물텐데요, 그때 A/B 테스트의 가치는 '임팩트가 더 큰 일을 찾기 위해서' 입니다. 그런데 테스트 결과를 보고 100개 중에 80개를 버리는데, 매번 개발을 다 하고 결과를 보고나서 개발 다 한 피처를 버린다? 이건 린스타트업이 A/B 테스트를 제대로 최적화한 상태는 아닌 것 같습니다.

이터레이션을 반복하면서 실험에 드는 비용을 점점 줄이고, 점점 더 적은 리소스로 의미있는 데이터를 얻을 수 있는 방법 등에 대한 개선된 학습이 이루어지지 않으면, A/B 테스트는 구성원들에게 쓸데없는 일만 늘리고 태클만 거는 거추장스러운 무언가가 될지도 모릅니다. 그래서 실험은 최소한의 비용을 들여 빠르게 실행해야 하고, 꼭 개발을 하지 않더라도 임팩트를 측정할 수 있는 더 작고 날렵한 방법들을 찾아내야 합니다. 또 UX가 중요한 B2C 프로덕트인지, 아니면 확장성과 유연함이 중요한 B2B 프로덕트인지에 따라서도 A/B 테스트의 목표와 가치 역시 달라진다는 것 또한 생각해봐야할 것 같습니다. 

관련해서 더 많은 내용을 알고 싶으시다면 다음의 컨텐츠를 추천합니다. 

• 론 코하비, 다이앤 탕의 <A/B 테스트>
• A/B 테스트를 하지 않아 유저를 잃었던 당근마켓의 사례 직관만 믿고 까불었다가 망한 PM의 사연
• 증거기반 아이디어 검증을 위한 A/B 테스트 심화 Idea Validation — Much More Than Just A/B Experiments - Itamar Gilad

• 원문 작성일 : 23년02월21일
• 사내에 발행했던 데이터레터 중 한 편으로, 공개를 위해 내용을 약간 수정했다. 사실 테스트 드리븐이 가능하려면 우선 데이터를 보고 의사결정하는 문화가 이미 어느정도 만들어져 있어야 한다. 어떤 지표를 어떻게 볼 것인지와 같은 리터러시가 어느정도 올라와있어야하고, 인과성에 대한 개념이 잡힌 뒤에야 의미있는 테스트가 가능하다. 막말로 vacant metric 놓고 A/B 테스트 백날 해봐야 의미 개뿔 없음.
• 회사에서 왜 비즈니스 지표 뿐 아니라 제품 engagement 지표를 봐야하는지 설명하고 주장하면서 C팀 설득하는 단계를 증말 힘겹게 겨우겨우 넘어서, 이제 조금씩 PO들이나 PD들이 봐야하는 지표들을 구체적으로 잡아가는 단계를 헤쳐나가고 있는 주제에 내가 이런 글을 공유하는거 너무 민망한 일이지만...애초에 이 글은 데이터로 일하는 경험이 전혀 없는 비데이터 직군 분들에게, A/B 테스트의 파운데이션에 해당하는 개념들을 설명하기 위해 쓴 입문용이니 그냥 철판 깔고 퍼블리시 한다. ㅎㅎ 

요즘 스터디도 운영하고, 스타트업이나 데이터 관련 행사나 밋업이 있으면 가서 구경도 하면서 업계의 주니어분들을 만나 이야기를 나눌 기회가 자주 있었다.


근데 일에 욕심이 있고, 능동적이고, 본인이 일을 잘 한다고 생각하는 주니어들은 열에 아홉이 본인이 진행하는 일의 필요와 중요성을 회사도 동료도 알아주지 않는다고 답답함을 토로한다. 자기가 맞고 이게 중요하고 자기는 중요한 일을 하는데 남들이 적극적으로 안 따라준다고 억울해하고 자기 커리어를 고민한다.


근데…사실 그건 일을 잘 하는 것도 뭣도 아니다. 그거 자기가 보기에나 중요한거다. 그걸 해서 뭐가 도움이 되고 어떤 결과를 낼 수 있는지 대상에 따라 그 사람들의 관점에서 설득하는데 실패한 거고, 정말 그게 회사에 중요한 일인지도 다시 생각해봐야 한다. 특히나…님 뭔데…? 님 뭐 대단한 성과 내고 역량 보여준 적 있나요? (주니어한테 회사가 이런거 기대하지도 않고 기대하는게 이상한거고 주니어가 그런걸 할 수 있으면 오히려 도망쳐야 할지도….)


자기 권한과 범위를 넘어서는 임팩트 있는 일을 하고 싶으면 스스로 작은 것부터 해서 성과를 쌓아가고, 그거 하는 과정에서 자기 편을 만들어서 그 사람들에게 작은 도움부터(필요하지 않아도) 요청하고, 그게 결과를 내면 그 공을 그 사람들에게 돌려야한다. 그때부터 동료들이 나와 일하면서 자기에게도 성과가 되고 도움이 되는 경험을 하고, 그 일의 의미를 이해하고, 내가 하는 일을 같이하고 싶어하게 된다.


패스트푸드점 알바부터 대단한 박사님들 리서치 서포트까지, 맥락도 일관성도 없이 되는 일은 다 하면서, 올해로 내 손으로 밥벌어먹고 산 지 18년이 되었는데, 돌이켜보니 어디서 무슨 일을 하던, 진짜 일 잘 하는 사람들은 그렇게 일하더라. 그냥 일에, 문제에 집중하고 자기가 할 수 있는 범위 안에서 최선을 다하면서 보여주고, 그걸로 남들을 설득하면서 범위를 넓혀나간다.


아무리 내가 잘난거 같아도 회사가 무슨 학교 팀플도 아니고 월급 받으며 일하는 프로가 몇십명, 몇백명 모여서, 수십수백만명이 이용하는 제품 만들고 운영하고 그걸로 또 돈을 버는 조직인데, 그거 너무 우습게 생각하고 자기가 당장 엄청난 일을 할 수 있다고 생각하는 건 그냥 대단한 착각이다.


물론 저도 다 겪은 일...예전에 보스한테 ’우린 뇌수술이 필요한지 그냥 컨디션이 안 좋은건지 모르는 환자한테 제대로 검사도 안 하고 다 그냥 두통약만 쥐어서 보내는 병원 같다‘고 개기다가, 보스한테 ‘근데 아직 아무도 슬아님에게 뇌수술 할 수 있는 의사면허 주지 않았잖아요.‘ 라고 혼났었다. 그땐 내 맘을 몰라주나 억울하고 섭섭했지만, 그 말이 주욱 마음에 남아서 조금씩 생각을 고쳐먹게 되었던 것 같다.


요새 제일 고맙게 생각되고 힘이 되는 동료들은, 작은 것부터 개선해보려 할 때 그걸 받아들이고 노력해주는 사람들이다. 이 사람들은 다 새로 시작하자거나, 대단한 일을 하자고 나서지도, 남들이 뭐가 틀려먹었다고 볼멘 소리를 하지도 않지만(그렇다고 이 사람들이 그걸 모르는 것도 아니다) 자기 일 안에서부터 조금씩 더 나은것을 고민하고, 그렇게 일한다. 안 쓰는 코드를 지우고, 틀린 주석을 고치고, PR 메시지를 잘 쓰고, 코드를 변경하기 전에 데이터를 한 번 더 살펴보고, 시간을 들여 한 번 더 고민하고 문서를 남긴다. 이런 노력은 티도 안나고, 당장 일의 처리 속도를 늦추고, 주목도 받지 못하는 일들이다. 그럼에도 불구하고, 이 사람들의 눈에 보이지 않는 노력이 결국 다른 동료들과 나중에 동료가 될 사람들이 더 잘 일할 수 있는 환경의 토대가 되고, 이런 것들이 우리가 원팀으로 일할 수 있는 시스템으로 나아갈 수 있게 해주는 힘이다.

내가 한 번 더 수고해서, 동료가 한 번 덜 고민할 수 있게 해주는 고맙고 위대한 사람들. 그 사람들 덕분에 큰 변화는 절대 하루 아침에 만들 수 없다는 걸 매일매일 배운다.

경영학 분야의 고전 중 한 권으로 꼽히는 피터 센게의 <학습하는 조직>은 기업이 오래 살아남지 못하고 사라지는 현상이 ‘학습하는 능력’이 부재한 것에 따른 증상이라고 말한다. 여기에서 말하는 학습능력은 조직을 구성하는 개개인의 역량보다는 조직 차원의 학습에 방점을 찍고 있다. (물론 그 두가지는 완전히 별개로 존재하는 것이 아니다)

피터 센게가 말하는 학습 조직을 이루는 요소에는 몇 가지가 있는데, 이 책을 읽으면서 들었던 생각들을 정리해보고자 한다. 이 글은 책의 요약이 아니라 책을 읽으면서 했던 생각을 정리한 글이다.

시스템 사고의 필요성

눈앞의 증상만을 해결하느라 문제의 근본 원인을 해결하지 못하는 일은 빈번하게 일어난다.

“단편적인 조치들은 당장 효과가 있지만 최종적으로 나쁜 결과를 만든다”

이런 문제를 방지하기 위해서는 전체를 구성하는 개별 요소들이 어떻게 상호작용하는지, 그 인과관계와 역동성을 포괄해서 시스템에 대한 총체적인 관점을 가져야 한다. 조직은 단순히 개인들 부분의 합 이상이다. 코드 또는 소프트웨어도 마찬가지이다. 내가 만든 애플리케이션은 해당 코드만 격리된 상황에서는 잘 동작하는 코드일 수 있지만 트래픽의 규모가 증가하거나, 네트워크 환경이 불안정하다거나, 다른 코드와 함께 동작하게 됨에 따라 문제를 발생시킬 수 있다. 때로는 증상만 해결하고 넘어가야 할 때도 있다. 하지만 개발자라면 그런 ‘눈 앞의 문제’만을 해결하는 해결 방식이 지속적으로 쌓였을 때 가져오는 나쁜 결과를 이해할 것이다. 흔히들 ‘기술부채’라고 말하는 바로 그것이다.

개인도 경력이 쌓일수록 시스템 사고가 요구된다. 단순히 빠르게 api를 찍어내는 것이 아니라 아키텍처, 디자인 패턴, 보안 등과 같이 더 넓은 영역에서 전체를 조망하기 위한 기술과 지식이 기대된다. 회사나 조직 또한 마찬가지이다. 조직이 커지고 더 많은 일을 해내려면 조직이 단순한 개인의 합 이상임을 이해하고, (달라진) 조직 수준에서 사고할 수 있어야 한다.

서로 다른 역량과 지식을 가진 구성원들로 이루어진 팀은 어떻게 학습하고 성장하는가?

학습의 주체는 개인이고, 조직의 학습은 학습하는 개인을 통해서만 가능하다. 서로 다른 수준의 숙련도를 가진 사람들로 구성된 조직은 어떻게 개인의 성장을 독려할 수 있을까?

가장 단순한 방법은 각자가 가진 지식을 서로에게 전이시키는 것이다. 잘 아는 영역에 대해서는 적극적으로 가이드를 주고, 잘 모르는 영역에 대해서는 적극적으로 피드백을 받는다. 내가 a라는 솔루션을 선택했을 때, 동료는 b라는 솔루션이 더 적절해보인다면 “왜 b가 아닌 a를 선택하셨나요?” 라고 질문할 수 있어야 한다. 만약 다른 제약 상황 때문에 a라는 솔루션이 더 적절했다면, 나는 그 제약 상황을 설명할 수 있고 그걸 통해 동료는 우리가 다뤄야하는, 혹은 a가 더 적절한 제약 상황에 대해 학습하게 된다. 만약 내가 b라는 솔루션을 몰랐다면, 그 피드백을 통해 나는 b라는, (있는 줄도 몰라) 고려해보지 못했던 옵션의 존재를 알게 된다.

건강한 조직이라면, 아무것도 모르는 신입도 ‘질문하기’를 통해 조직에 기여할 수 있다. 배경지식이 없는 사람에게 문제를 설명하려면 문제의 핵심만 최대한 명확하게 만들어야 한다. 그 과정을 통해 기존의 문제를 익숙하지 않은 관점으로 바라볼 기회를 얻게 된다.

서로의 전문성을 존중한답시고 ‘알아서 으레 잘 했겠지’, 혹은 ‘나만 모르는 거고 질문하면 쪽팔린거겠지’ 라고 생각하며 아무것도 질문하지 않으면 서로 다른 역량과 지식을 가진 사람들이 함께 일함으로서 얻을 수 있는 시너지를 얻을 수 없다. 그건 존중이 아니라 같이 성장할 기회를 버리는 일이다. 내가 보기에 b가 더 나은데 a를 선택했다면 분명 그 이유가 있을 것이고, a를 선택한 이유를 배우려면 질문할 수 있어야 한다. 정말로 동료를 존중한다면 동료가 설령 b를 몰랐다해도 열린 마음으로 새로운 지식을 받아들일수 있는 사람이라고 믿어야 한다.

물론 우린 사람이니까 내가 한 일에 대해 비판적인 피드백을 받으면 기분이 상할 수 있다. 나 또한 맘이 상해 그 자리에서 쉽게 받아들이지 못하고 변명하거나 방어적으로 대처하는 일도 많았고 지금도 여전히 미숙하다. 하지만 그런 피드백과 질문은 늘 모르던 지식, 간과하고 있는 영역의 존재를 일깨워 주었다. 그런 피드백이 없었다면 내가 아는 a만이 답이라고 아주 오랫동안 생각하고 있었을 것이다. 성숙하게 반응하지 못했음에도 불구하고 나에게 꾸준히 피드백을 주는 사람들이야말로 내가 성장할 수 있게 해준 사람들이었다. 이런게 가능하려면 조직의 커뮤니케이션 구조가 정말 수평적이어야하고, 그럼에도 불구하고 회사가 당신은 우리 조직에 필요한 사람이라는 안정감을 주어야 하며, 조직 안에서 연차와 직급의 차이는 위계가 아니라 역할의 차이라는 생각이 공유되어야 한다.

예전에 면접을 봤던 한 회사는 다른 곳에서 CTO를 했던 8년차 개발자가 막내인 시니어 조직이었다. 면접에서 질문 기회가 주어졌을때, 저는 이미 계신 다른 분들에 비해 실력으로는 보잘것없는 주니어인데, 이 조직에 들어와서 어떤 역할을 하길 바라는지, 어떻게 기여할 수 있다고 생각하시느냐고 여쭤보았었고 다음과 같은 답을 들었다.

“저도 항상 제가 옳다고 생각하고 의견을 관철시키려고 하는 편인데, 저 정도의 경력과 지위를 가지게 되면 사람들이 제 의견과 다른 생각은 잘 말해주지 않아요. 또 지금 팀의 구성이 이렇다보니 일을 할 때 서로간에 굉장히 조심스럽죠. 그래서 xx님이 와서 용감하게 아무거나 막 질문해주고 솔직하게 이야기해줬으면 좋겠어요”

나에게는 저 말이 ‘일정 수준에 도달한 이후에도 계속 성장할 수 있는 사람’과 ‘그저그런 수준에서 멈추는 사람’을 가르게 해주는 기준이 된 것 같다. 내가 듣기 싫은 말도 계속 들을 용기가 있는 사람, 그런 말을 듣지 않아도 될 때에도 그런 말을 듣는 것이 중요하다고 믿는 사람은 계속 성장할 수 있다는 생각이 들었다.