페이스북 개발자의 성과 만들기

이제는 메타(Meta)라고 불러야 하는 페이스북에서 일하는 지인이 휴가차 한국에 입국했었어요. 오랜만에 얼굴도 보고 술 한잔했습니다. 오랜만에 만나는 자리다 보니 참 많은 이야기를 나눴었죠. 어느덧 자리가 무르익으니 늘 하던 대로 또 개발 이야기를 하기 시작했어요. 업무나 개발에 대해 서로 이야기를 많이 나누던 친구다 보니 자연스럽게 그렇게 됐죠. 이 글에서는 다룰 수 없지만 네이티브 앱에 대한 동적이고 유연했던 파격적인 아키텍처는 제게 많은 영감을 줬죠. 그 자리는 페이스북의 개발자는 어떻게 일하는가에 대한 이야기가 주 주제가 됐습니다. 시간 가는 줄도 모르고 이야기를 나눴습니다. 위드코로나 시기였지만 아쉽게 일찍 자리를 파했습니다. 그 자리에서 나왔던 내용들이 저는 매우 유익했어요. 그래서 정리해서 공유하면 좋겠다 싶었습니다.

이 글은 페이스북에서는 어떻게 업무가 시작, 실행, 관리되고 성과로 이어지는지 그리고 성과를 어떻게 평가하는지가 주된 골자입니다. 성과에 대해서 조금 더 시간을 들였고요. 들었던 내용을 토대로 이야기가 흐르겠지만 제가 주관적으로 느낀 점들이나 의견을 많이 합성할 예정입니다 :) 일부 조심스러운 부분은 생략했고요. 애매한 부분은 전화로 재검증을 하기도 했습니다만 일부 제가 오해하거나 과장해서 생각한 부분도 있을 수 있습니다.

일단 미리 요약을 하면 이렇습니다.

• 데이터 기반의 명확한 목표
• 작업자가 스스로 할 일을 결정하는 능동적인 업무
• A/B 테스트 위주의 개발
• 데이터 기반의 성과 측정
• 연예인 매니저같은 매니저
• 체계적이고 합리적인 성과 관리 및 평가

자 이제 어떤 이야기를 들었는지 썰을 풀어 보겠습니다.

업무의 시작

한국 개발자들의 업무는 기획자가 작성한 기획서로부터 시작하는 것이 일반적입니다. 하지만 페이스북은 기획자가 따로 없다고 합니다. PM, 매니저, 개발자, 디자이너 등 누구나 기획을 할 수 있는 구조입니다. 해외에는 이런 경우가 많기 때문에 그렇게 큰 특징은 아닌 것 같아요. 누구나 일을 기획한다는 것은 작업자들이 좀 더 서비스에 밀착되어 능동적으로 일할 수 있게 만들어주는 원동력이 되지만 그만큼 주전공에만 집중할 수 없다는 단점도 생깁니다. 능률의 포인트를 어디에 두느냐에 따라 장단이 갈릴 수 있는 내용인 것 같아요.

우선 일정 기간을 두고 명확한 목표가 내려옵니다. KPI라고도 하죠. 이런 목표가 정해지면 그때부터는 알아서 일을 해야 합니다. 누군가 무엇을 하라고 일일이 알려주지 않는다는 거죠. 매니저가 이거 하세요 저거 하세요 이렇게 시키지 않습니다.

제가 여기서 중요하게 생각한 점은 KPI가 데이터를 기반으로 하는 뚜렷하고 심플한 목표라는 점입니다. 물론 조직의 뎊스에 따라서 명확함은 다를 수 있겠지만 개발자에게 주어지는 목표는 뚜렷하다는 겁니다. "유저의 A 화면에서 B 화면으로 전환하는 클릭률을 20% 높인다" 단순한 클릭률이지만 이미 저 클릭률이 서비스에 기여하는 중요도가 다양한 데이터를 기반으로 이미 분석이 된 것이고 그것들이 이 목표의 근거가 되는 거죠. 이유와 근거는 복잡할지언정 목표는 단순합니다. 목표를 이루거나 문제를 해결하려면 우선 목표와 문제를 단순화해야 합니다.

이런 목표들이 공유되면 PM에 의해서뿐 아니라 개발자, 디자이너 등 각 작업자들에 의해서도 목표를 이루기 위한 아이디어를 기반으로 프로젝트가 자발적으로 구성됩니다. "What"은 정해주지만 "How"는 개발자, 작업자들이 정하는 거죠. 프로젝트는 클 수도 있지만 아주 작을 수도 있습니다. 단순히 버튼의 위치를 조금 옮기는 정도의 작업일 수도 있죠. 아무튼 목표를 이루기 위한 아이디어들입니다. 누군가의 아이디어에 의해 프로젝트가 구성되면 해당 프로젝트에 필요한 인원으로 사람들을 끌어모읍니다. 보통 아이디어를 시작한 사람이 리더가 되지만 그렇지 않은 경우도 있다고 합니다. 아무튼 프로젝트를 잘 이끌 사람이 하게 됩니다. 프로젝트의 시작과 동일하게 그 프로젝트에 참여하는 인원도 자발적으로 참여합니다. 깐부를 구하는거죠. 깐부를 구할때는 페이스북에서 직접 개발한 페이스북과 유사한 형태의 협업관리도구를 사용한다고 합니다. "이런 이런 목표달성을 위해 이런 이런 아이디어가 있는데 여기 개발자 1명 디자이너 1명 필요하고 작업 공수와 일정은 이 정도 예상합니다" 요렇게 공개적으로 구인을 한다고 합니다. 흥미롭죠? 자주 언급되는 김국현님의 만화중 한 장면인 "자바 2명 타요"와 비슷해보이지만 그 내용은 전혀 다르네요. :)

PM이 만든 사업적으로 꼭 진행해야 할 프로젝트도 있을 겁니다. 누구나 목표를 위해 아이디어를 내고 실현할 수 있는데 PM은 그 책임을 지고 있으니 해야 할 프로젝트가 많겠죠. 하지만 PM이 만든 프로젝트라고 다르지 않습니다. 자발적으로 그 프로젝트에 참여하고 싶은 사람들이 손을 들고 참여합니다. 참여자가 적다면 프로젝트를 제대로 진행할 수 없겠죠. 사람들을 움직이는 건 성과입니다. 성과를 가장 많이 내고 임팩트(실제로 이 용어를 사용한다고 합니다)가 있는 일을 하려고 합니다. 성과에 관해서는 후반부에 다시 다룹니다.

반드시 실행돼야 할 프로젝트지만 여러 가지 이유로 참여자가 적어 실행을 할 수 없을 때는 매니저들이 개입을 해서 상황에 맞게 성과가 부족한 사람이나 혹은 프로젝트에 반드시 필요한 사람들을 설득해서 매칭한다고 합니다. 매니저는 사람이 필요한 프로젝트와 해야 할 일이 필요한 프로젝트를 매칭해주는 해드헌터 같은 역할을 하는 거죠. 이게 당연한 역할이고 한국이라고 다를 건 없지만 뭔가 다른 의미처럼 느껴집니다. 뭔가 각각이 독립된 주체 같다고 할까요? 유기적인 최소 단위가 팀이 아니라 개인인 느낌입니다.

업무의 진행

일을 하기에 앞서 제일 먼저 하는 작업은 문서작업이라고 합니다. 기획서가 아니고요. 목표를 이루기 위해 생각했던 아이디어를 구현했을 때 그 성과를 어떻게 검증할 것인가에 대한 문서작업입니다. 업무는 일한 시간, 노력, 고생, 희생 같은 건 다 필요 없고 어떤 성과를 냈는지가 제일 중요하다고 합니다. 그러기에 작업을 시작하는 제일 첫 번째 단계에서 성과를 어떻게 측정할 것인가부터 고민하는 거죠. 내가 한 일이 어떻게 목표를 달성에 영향을 줬는지 검증할 방법부터 생각합니다. 이게 불가능하다면 해봤자 성과를 증명할 수 없으니 안 하느니만 못하는 작업이 됩니다. 이 부분이 명확하지 않으면 같이 작업할 사람도 구하기도 힘듭니다. 이 과정에서 어떤 로그를 쌓을지도 결정하고 A/B 테스트는 애초에 시작부터 고려합니다.

페이스북의 모든 작업은 A/B 테스트를 통해서 최종적으로 배포할지 말지를 결정한다고 합니다. 보통의 경우에는 A는 원래 시나리오일 것이고 B는 새로운 아이디어를 적용한 시나리오가 됩니다. 그리고 A와 B를 비교하며 새로운 기능을 부분적으로 배포하면서 효용성을 따져봅니다. 처음에는 5% 사용자를 대상으로 사용할 수 있게 열어줍니다. 각종 로그를 통해 이번 작업이 목적에 맞는 효용가치가 있다는 게 증명이 된다면 10%로 조금 더 늘려보고요. 점점 더 늘리면서 여러 가지 검증을 하다가 최종적으로 100% 적용하는 것이죠. 만약 5%의 유저에게만 공개한 상황에서 갑자기 버그나 오류가 발견됐다고 생각해 보세요. 이럴 땐 번잡스럽게 롤백이니 뭐니 생각할 필요 없이 일단 0%로 즉 비공개되도록 바꾸고 문제를 해결한 뒤 배포해서 다시 조금씩 엽니다.

이 친구가 소속된 팀은 QA가 따로 없다고 합니다. 회사에 QA팀이 없다는 말이 아니고요. 모든 프로젝트가 QA를 거치는 것은 아니라고 합니다. 기본적으로 이 팀의 프로젝트는 QA 프로세스가 없다고 합니다. QA없이 이런 대규모의 서비스에 반영된다는 점에서 경악을 했지만 A/B 테스트의 도움이라면 조금 용기를 낼 수 있지 않을까라는 생각이 들었습니다. A/B 테스트는 사람들의 반응을 분석할 수 있는 도구이자 QA가 없음으로 해서 생기는 불안감의 최종 방어 군인 셈이죠. 여차하면 금방 원래 코드로 전환이 가능하니까요. 처음엔 조금 불안하니 0.01%만 공개해 보고 로그를 살펴보는 거죠. 사실 사용자가 워낙 많은 서비스라 0.01% 만도 엄청난 수의 유저들입니다. 로그에 이상 징후가 포착되면 바로 0% 바꾸고 해당 문제를 해결해서 다시 배포하면 되는 겁니다. B가 새로운 컴포넌트라면 A 대비 B의 효용가치를 검증하면서 안정성까지 함께 검증하는 거죠.

QA가 없는 대신 개발 작업에서 E2E 테스트를 굉장히 철저하게 적용해서 개발을 하고 있습니다. 자체적으로 전사에서 사용할 수 있도록 구축해놓은 개발 환경을 이용하면 각종 기기들에 대한 테스트 환경이 매우 잘 만들어져 있어서 테스트 코드만 잘 작성하면 대응 기기들에 대한 테스트의 결과를 쉽게 받아볼 수 있다고 합니다. 테스트 후 문제가 있는 기기들에 대한 실행 화면 정보나 디버깅도 수월하고요.

개발 환경 이야기가 나와서 조금 말씀드리면 커스터마이징된 vscode를 기반으로 샌드박스 형태의 개인 개발 환경을 클라우드 환경처럼 쉽게 사용할 수 있다고 합니다. vscode에서 버튼 한번 클릭하면 프로젝트 리포(머큐리얼)를 체크아웃 받고 동시에 작업 결과를 확인할 수 있는 샌드박스 서버가 뜨면서 별도의 도구 설치나 설정 없이 바로 클라우드 기반 1인 개발 환경이 바로 셋업이 된다고 합니다. 코드만 수정하면 바로바로 서버에서 확인 가능하고 E2E 테스트까지 일사불란하게 진행이 됩니다. 그리고 클릭 한 번으로 전 세계에 배포까지 쉽게 진행할 수 있죠. 아무튼 누구라도 어디서나 바로 코드를 수정해서 전 세계에 배포할 수 있는 환경입니다. 이 친구는 다른 무엇보다도 이 개발 환경을 엄청 극찬했습니다. 제일 놀라웠다고 합니다. 아 방금 설명드린 내용을 들으면서 "웹 개발"이라면 뭐 가능하겠지 라고 생각하신분 계실텐데요 방금 설명드린 환경은 iOS, Android 같은 네이티브 앱을 개발하는 환경입니다. 이건 솔직히 개인적으로는 충격적일정도로 진보적인 클라이언트 아키텍처가 있었기 때문에 가능한 일이기도 합니다. 여기서 말씀드릴수 있는 내용은 아쉽게도 그저 Hack을 사용한다 정도일것 같습니다.

업무의 위기

구성된 프로젝트 팀은 리더에 의해 각자 역할에 맡게 업무들이 부여되고 작은 TF 조직으로 프로젝트가 종료될 때까지 진행됩니다. 해결하려는 이슈는 하루 혹은 이틀이 충분한 아주 간단한 작업일 수도 있고 오랜 시간이 필요한 작업일 수도 있죠. 개인이 참여하는 프로젝트는 한 개 이상일 수도 있습니다. 프로젝트가 수월하게 진행된다면 좋겠지만 늘 그렇듯 문제가 생기기 마련인데요. 진행 과정에서 특정 분야의 전문가가 새롭게 필요하게 될 수도 있고 여러 가지 이유로 사람이 변경되거나 추가될 수 있어요.

사람이 필요할 때는 리더나 맴버들이 직접 구하기도 하지만 각 팀의 매니저들에게 특정 업무를 진행할 수 있는 사람을 구해달라고 요청하기도 합니다. 매니저들은 적합한 인재나 현재 일을 찾고 있는 작업자를 연결해 줄 수도 있고 정말 사람이 없는 경우에는 좀 더 성과를 내야 할 사람들을 대상으로 프로젝트에 참여하도록 독려한다고 합니다. 여기의 매니저는 연예인의 매니저와 같은 느낌을 줬어요. 똑같은 단어이지만 관리직으로의 매니저와 연예인의 매니저는 조금 다른 느낌이잖아요? 한 명 한 명을 선수처럼 관리하고 회사라는 외주(?)와 업무로 연결해 주죠.

여담이지만, 페이스북도 다른 해외 기업들처럼 매니저와 개발자의 트랙이 명확히 구분됩니다. 개발팀의 매니저라고 매니저에게 개발 역량을 요구하지 않고 반대로 개발자에게 관리 역량을 요구하지 않습니다. 매니저와 개발자가 위아래의 관계가 아니라 매니저는 매니징 팀의 팀원 정도의 느낌이었어요. 그렇기에 개발자의 성과에는 책임이 있더라도 성장에는 책임이 있지 않습니다. 그래서 새로 입사한 개발자는 초반에 적응이 힘들다고 합니다. 일도 알아서 찾아서 해야 하고 누가 뭘 가르쳐주질 않으니까요.

온콜은 기본적으로 당번제고 팀원들이 일주일 단위로 돌아가면서 합니다.(update 220311) 장애가 나거나 긴급히 대응해야 할 상황이 생긴다면 시스템에 장애를 이슈로 등록합니다. 누구나 등록할 수 있지만 보통은 온콜이 등록합니다. 장애 이슈가 등록이 되면 시스템이 자동으로 담당자들에게 ARS 전화로 연락한다고 합니다. 전화를 받은 담당자가 약속된 코드를 누르기 전까지 계속 연락이 갑니다. 이런 경우는 장애도가 매우 심각할 때라고 하는데요. 장애는 정도에 따라서 4단계로 관리한다고 합니다. 단계별로 해결해야 하는 기한도 정해집니다. 최고 단계의 경우는 서비스를 이용할 수 없는 수준의 장애인데 이 경우는 미봉책으로라도 우선 빨리 정해진 시간에 해결하고 그다음에 실질적인 문제를 해결합니다. 장애를 해결해야 할 시간까지 정해져있으니 쫄깃하네요.

서비스의 장애 이슈만 수시로 살피면서 도움을 주는 구원자들도 있는데요. 구원자들은 별도의 명칭이 있지만 공개는 하지 않겠습니다. 마치 슈퍼맨처럼 하늘에서 쓰윽 쓰윽 살펴보다가 위기에 빠진 서비스를 구해주러 날아가는 사람들입니다. 슈퍼맨과 다른 점은 그 사람들은 그게 성과라는 점입니다. 선의로 도와주는 게 아닙니다. 그들은 10년 차 이상의 시니어 개발자들로 구성되며 페이스북에서 오랜 경험이 있어 이 조직 저 조직의 사정을 대부분 파악하고 있는 사람들이라고 합니다. 장애 해결에 직접 도움을 주거나 도움을 줄 수 있는 팀이나 사람을 연결해 주기도 합니다. 장애가 해결되면 이 사람들을 주축으로 관련자와 함께 리뷰를 하며 장애 리포트를 만듭니다. 장애 발견까지 얼마나 걸렸는지, 오래 걸렸으면 왜 오래 걸렸는지, 어떻게 해결했는지, 이런 문제의 재발을 막기 위해 무엇을 해야 하는지 등을 정리합니다.

따뜻한 온콜 문화도 있습니다. 아프다던가의 기타 사정으로 새벽에 온콜 대응이 힘들다면 지구 반대편 직원 그러니까 지금 정규 업무시간인 직원에게 대타를 요청하기도 한다고 합니다. 이후 동일한 상황에 대타로 보답해 주고요. 이건 뭔가 회사 차원에서의 체계로 정해진 건 아니고 글로벌 기업의 톡특한 배려 문화인 것 같습니다.

그밖에 짜글짜글하게 그냥 일만 잘하면 되도록 나머지 부분들이 모든 부분들이 세심하게 잘 정리된 느낌이었습니다. 이런 것들이 오랜 시간 많은 유저를 대상으로 글로벌하게 서비스를 운영해왔던 노하우겠죠.

성과의 기준

이미 몇 번 언급했듯 여긴 철저히 성과 위주로 평가합니다. 그래서 성과에 대한 기준이 매우 명확합니다. 네 가지 범주를 기준으로 성과를 평가합니다.

• 프로젝트 영향력
• 엔지니어링, 서비스 전반
• 피플
• 리더쉽

용어는 이 친구의 요청에 따라 조금 각색해서 표현했습니다. 각 범주의 성과는 대상자의 연차와 직급에 맞게 필요한 양이 어느 정도 정해져있습니다. 그래서 대학의 학점처럼 챙겨야 합니다. 예를 들어 프로젝트 영향력 성과는 충분하지만 피플성과가 부족하다면 평가 기간이 오기 전에 피플 성과를 채우기 위해 피플 성과 관련 업무 위주로 일을 해야 합니다.

성과의 네가지 범주와 내용은 꼭 페이스북이 아니더라도 성과 관리를 위해 일반적으로 활용할 수 있을 것 같습니다. 사실 어디서나 환영받을 수 있는 내용들입니다.

프로젝트 영향력

프로젝트 영향력은 그 명칭으로 짐작하실 수 있듯 프로젝트에 공헌한 성과들입니다. “AA 를 유지 보수했음.” 혹은 “BB 파트를 맡아 스프린트를 N 개 진행했음” 이런 것은 성과로 증명할 수 없는 내용입니다.

• 내가 한 작업으로 인해 클릭률 혹은 방문율이 몇 퍼센트 올랐는지
• 내가 한 작업으로 KPI를 어떻게 얼마나 달성했는지
• 어떤 중요한 아이디어를 냈고 그것이 어떻게 반영됐는지
• 퍼포먼스를 어떻게 얼마나 향상시켰는지(이게 제일 중요함)
• 기타 프로젝트 자체에 기여한 성과

아이디어 같은 경우는 채팅이나 구두상으로 아이디어가 논의된 경우에는 성과로 증명하기 힘들겠죠. 그래서 논의는 메신저나 구두상으로 할지언정 아이디어에 대한 정리 문서를 직접 작성해서 관련 작업자에게 공유하고 그 문서를 성과의 증거로 만듭니다. 여긴 글을 잘 써야 하는 회사다라는게 전반적으로 많이 느껴졌습니다. 실제로 이 친구도 글쓰기가 개발만큼 중요하다고 했고요.

엔지니어링, 서비스 전반

엔지니어링, 서비스 전반은 개발자로서의 역량에 대한 전반적인 항목입니다.

• 코드 퀄리티, 테스트, 문서화
• 코드 리뷰 수준
• 개발 관련 가이드라인에 대한 공현
• 장애 대응, 모니터링 강화
• 안정성, 퍼포먼스를 크게 개선
• 기타 개발자로서의 역량이 드러난 성과

이렇게 서비스와 별개라고 볼 순 없지만 순수하게 개발 그 자체로서의 성과입니다. 퍼포먼스 같은 경우는 프로젝트 영향력하고 겹치는 부분이 있을 수 있는데요. 서비스의 퍼포먼스를 개선했다면 그럴 수 있겠죠. 이 경우에는 본인에게 유리한 쪽, 그러니까 프로젝트 영향력의 성과가 충분하다면 엔지니어링, 서비스 전반 성과로 만들고 반대의 경우에는 반대의 성과로 만드는 식으로 성과 관리를 한다고 합니다.

코드 퀄리티, 코드 리뷰 수준 등의 세부 항목은 다른 회사에서도 평가하는 항목입니다. 여기서 페이스북이 조금 나은 점이 있다면 안정성이나, 코드 리뷰, 코드 복잡도 그리고 커버리지 등을 정성적, 정량적으로 판단할 수 있는 지표와 기준 그리고 시스템이 있다고 합니다. 그래서 전체 코드 리뷰 횟수 집계 같은 것도 쉽게 확인할 수 있습니다. 이 지표들을 성과를 증명하는 용도로 사용합니다.

피플

피플 성과는 공유, 동료, 태도 그리고 커뮤케이션에 대한 성과라고 볼 수 있습니다.

• 동료를 도와줌
• 협업을 이렇게 저렇게 잘했음
• 발표를 해서 지식을 공유함
• 위키에 중요 or 복잡한 이슈를 정리해서 공유함
• 인터뷰 참여
• 멘토링
• 파티
• Thanks Vote

각 항목은 특별한 설명이 필요 없을 것 같은데요. “파티”와 “Thanks Vote(땡스 보트)” 가 조금 특이한 항목일 것 같습니다.

파티를 주최해 팀의 분위기를 좋게 만드는 것도 “피플” 성과라고 합니다. 이런 파티는 일정한 룰이 있어서 플레이샵 처럼 몇 가지 정해진 게임을 진행해야 합니다. 일종의 가이드가 있다고 합니다. 이렇게 스케줄을 만들고 계획하고 사람들을 불러 참여시키는 일을 개발 업무와 동등한 성과로 봅니다.

땡스 보트는 페이스북과 비슷한 형태로 만든 사내 업무 관리 시스템에 있는 기능입니다. 페이스북의 "좋아요"와 비슷한 기능인데요. 게시물 뿐 아니라 사람에게도 땡스를 줄 수가 있습니다. 땡스 보트는 코드 리뷰에도 줄 수 있을 정도로 시스템에 잘 녹아들어 있습니다. 유용한 코드 리뷰를 남겨줬거나 문제 해결에 도움을 준 사람에게 땡스 보트를 주곤 한답니다. 이 땡스 보트의 개수도 피플 성과로 활용할 수 있습니다. 땡스 보트는 정말 영끌해야 할 상황에서만 성과에 넣는다고 합니다.

디렉션

디렉션은 시니어이거나 시니어가 되어야 할 주니어에게 많이 필요한 성과입니다.

• 프로젝트 리딩
• 상반기 하반기 로드맵 회의 때 아이디어를 많이 냄
• 기술에 대한 가이드를 제공하고 리딩함

디렉션은 단어에서 주는 뉘앙스 그대로 리더십과 기술 리딩에 대한 항목입니다. 프로젝트 리딩은 프로젝트에서 큰 업무를 작은 태스크로 나누고 각 태스크를 적절한 사람에게 분배하는 작업까지 포함합니다. 한국에서도 프로젝트에 참여하는 개발 리더들이 하는 작업입니다. 프로젝트 리딩은 필요에 따라 디렉션 성과에 넣을 수도 있고 프로젝트 임팩트에도 넣을 수 있습니다.

반기별로 로드맵을 정하는 회의가 있는데 서비스의 방향성을 정하는 회의라고 할 수 있습니다. 회의에서 중요한 아이디어를 많이 내 공헌한다면 이것 역시 성과가 됩니다. 단순한 의견만으로는 증거가 남지 않으니 의견을 낸 다음에는 문서화 하는 작업이 뒤를 잇는다고 합니다. 일종의 기획서겠죠. 회의실에서 말만 많이 한 것은 의미가 없습니다. 명확한 아이디어로 문서화되어 공유됐을 때 비로소 하나의 성과로 인정됩니다.

사용하고 있는 기술을 더 잘 활용할 수 있도록 가이드를 하는 것도 디렉션 성과입니다. 예를 들어 테스트는 이런 식으로 합시다라는 문서를 작성해 적절한 예제까지 만들어서 공유하는 것들을 말합니다. 코드 리뷰에 대한 가이드일 수도 있고요. 잘못된 개발 관행이나 성능을 저해하는 코드에 대한 개선책일 수도 있겠네요.

성과 평가

성과 평가는 1년 주기로 진행합니다. 원래는 반기별로 한 해에 총 2회를 진행했었는데 사람들이 단기 성과에만 매달리는 경향이 있어서 변경됐다고 합니다. 평가는 1년 단위로 하지만 중간에 내가 현재 잘하고 있는지 확인을 위해 동료와 매니저에게 피드백 요청을 할 수 있다고 합니다. 이건 용어를 말해도 괜찮을 것 같은데 의미 그대로 미드 텀(mid-term) 체크라고 합니다. 개개인의 성과들은 성과를 트래킹 하는 도구에 등록해서 관리하는데 이 내용을 누구에게나 공유할 수 있습니다. 캐쥬얼하게 “내가 지금 잘하고 있는지 확인 좀 해줘~” 라고 요청하는 거죠. 도움이 되는 피드백을 받는다면 굳이 평가까지 기다릴 필요 없이 부족한 부분을 미리 알게 되고 개선할 수 있습니다. 그것이 결국 평가에 긍정적으로 반영이 되겠죠.

앞서 이야기했듯 성과가 체계적이고 구체적으로 평가됩니다. 모든 것이 측정 가능한 성과라고 생각하니 이것보다 더 투명하고 솔직하고 명확한 인사고과가 없는 것 같아요. 합리적인 거죠. 그래서 누가 업무시간에 일을 하든 말든 아무도 터치하지 않습니다. 일의 시간적인 양은 중요하지 않죠. 어차피 성과로만 평가되니까요. 그래서 야근을 했다고 월급을 더 주지 않으며 적게 했다고 월급을 덜 주지 않습니다. (애초에 보상이 넘사입니다만...) 회의, 다른 협업들 때문에 개발을 못해서 성과를 못 냈다는 변명도 의미가 없습니다. 불필요한 회의나 협업에 대한 비용은 스스로 줄이거나 문제를 제기해서 같이 해결해야 하는 거죠. 그렇게 프로세스를 개선해 문제가 해결되면 그것도 성과가 됩니다. 작은 개선, 큰 개선 상관없습니다. 오히려 이런 문제를 이야기하지 않고 혼자 끙끙 앓고 있다가 문제가 불거지면 더 큰 마이너스가 된다고 합니다.

성과가 뚜렷하지 않은 일은 아무도 하지 않으려고 합니다. 하지만 현재 성과가 뚜렷하지 않은 일이 꼭 필요한 일이라면 명확한 성과가 될 수 있도록 만들 것이고 결국 필요한 일은 모두 측정 가능한 성과로 이어지도록 만들겠죠. 모든 것이 성과라는 것은 이 점이 핵심인 것 같아요.

평가를 매년 한다고 연봉협상도 매년 하는 것은 아닙니다. 연봉을 올려줘야 할 만큼 성과가 쌓였다면 특별한 시기 없이 연봉을 올려주고, 진급을 할 만큼 역량을 증명했다면 언제든 진급을 시켜줍니다. 그래도 물가 상승률 정도의 연봉 인상은 매년 해준다고 합니다. 반대로 몇 년간 성과가 너무 없다면 성과를 증진시키는 회사 차원의 교육 프로그램에 포함시키고 별도로 관리합니다. 업무 관리에 대한 교육도 하고 적절한 프로젝트도 소개해 주며 성과가 좋은 직원을 1:1 멘토로 붙여줍니다. 이 멘토는 멘토링이 성과가 됩니다. "피플" 성과죠. 하지만 이것저것 해주고 그래도 성과가 안 나오면 땡 탈락 집으로 돌아가야합니다.

평가는 대상자가 제출하는 성과 보고서를 기준으로 진행됩니다. 그동안의 매니저의 느낌적인 느낌이나 동료의 주관적인 리뷰 보다 이때 보고되는 성과를 위주로 객관적으로 평가됩니다. 그래서 이 성과 보고가 엄청 치열하다고 합니다. A4 한 장 수준이 아닙니다. 사소한 것 하나부터 열까지 모두 기록합니다. 얼마나 쓸게 많을까요. 그래서 성과 보고서를 작성하는 스킬도 많이 중요하다고 합니다. 워낙 양이 많다 보니 어필되어야 할 것들이 제대로 잘 어필되도록 정리해야 하니까요. 애초에 양이 많아 성과 보고 시기에 한꺼번에 정리해서 올리는 것은 거의 불가능하고 평소에 업무가 진행될 때마다 미리미리 작성해둔다고 합니다.

마무리

이 친구하고 이야기를 나누는 내내 감탄을 연발하며 찬사를 보냈지만 참 많은 생각을 하게 되네요. 디테일의 차이가 있을 뿐 표면적으로는 우리나라 기업문화와 크게 다르지 않은 것 같습니다. 한국의 IT기업들도 각자 성과 위주를 내세우고 있죠. 하지만 명확한 기준으로 제대로 워킹하고 있다고 생각하진 않습니다. 성과에 대한 명확한 기준과 객관적으로 점수화할 수 있을 정도의 체계가 있어야 할 것 같아요. 조심스러운 말이지만 한국의 기업 체계는 대충 얼버무리는 지점이 항상 있는 것 같습니다. 뭐 저의 미천한 생각입니다. 그렇다고 "와 역시 해외 기업이 짱이다" 뭐 이런 생각도 아닙니다. 이야기 듣는 내내 참 힘들겠다는 생각도 많이 들었어요. 이 친구도 힘든 점을 많이 언급했고요. 좋은 건 알겠는데 힘들다 빡세다. 뭐 이런 거죠. 실제로 입사 후 적응을 못해서 힘들어하는 분들이 태반이라고 합니다. 특히 한국인 포함해 외국인들이 많이 힘들어한다고 합니다. 어찌 보면 우리의 대충 얼버무리는 그 지점이 편한 부분도 분명 있는 것 같습니다.