경력, 그 견딜 수 없는 무거움

대다수 개발자는 “소프트웨어 사업 대가의 기준”에서 말하는 “소프트웨어 기술자 등급별 노임 단가”에 대해 잘 알 것이다. “소프트웨어 기술자”들을 기술자격 및 경험기준이나 학력 및 경험기준으로 등급을 나누고, 각 등급에 대해 노임 단가를 책정해 놓은 것이다. 자신이 어느 등급에 속하는지에 따라 한 달에 얼마를 받는지가 결정되므로 관심이 안 갈래야 안 갈 수가 없다.

그런데 소프트웨어 기술자의 등급이라는 것이 겉으로는 기술자격이나 학력에 경험을 함께 고려해 결정되는 것 같은데 사실상으로는 “경험”이라는 요소가 가장 결정적 역할을 한다.

“기술자격”은 기사자격을 가진 사람으로부터 경력이 몇 년이냐에 따라 등급을 나누는데 현실적으로 기사자격증이라는 것이 실무에서 얼마나 일을 잘하느냐에 별 참고가 되지 못한다는 점, 그래서 겉치레로 인식되는 경우가 일반적이라는 점을 고려한다면 기술자격이라는 것이 결과적으로는 경력에 의해 좌지우지된다고 볼 수밖에 없다.

“학력”이라는 기준도 고졸, 전문대졸, 학사, 석사, 박사학위자 등으로 나누나 각 학력에 따라 인정해주는 경력 연수가 다를 뿐이지, 이것 역시 경력이 가장 큰 변수가 된다. 결국 학교에서 몇 년 있었나를 경력의 일부로 셈해주는 것이기 때문이다.

이런 제도가 있기 때문에 사람들은 이 틀(심리학적 프레임) 안에서 생각한다. 개발자의 가치는 그 사람이 이 업계에서 얼마나 오래 살아 남았는지로 결정된다. 그래서 개발자를 뽑을 때에도 중급 이상을 뽑는다거나, 중급에 경력 얼마 이상을 뽑는다는 식으로 채용공지를 하는 경우가 많다.

하지만 이런 기준에 의해 나눈 초•중•고급 등이 실제로 얼마나 의미가 있을까? 이 사람이 중급 몇 년 차라는 사실로부터 그 사람의 실력에 대해 무엇을 얼마만큼 기대할 수 있을까?

나는 이 글을 통해 경력 연차라는 것으로부터 이 사람이 초급이구나, 아니구나 하는 정도의 정보를 기대할 수 있으며, 후자에 속하는 사람들(초급이 아닌)에 대해서는 경력 연차가 오히려 혼동을 불러일으키는 잘못된 정보로 작용할 수 있다, 고로 경력 연차에 의한 채용 여부나 임금 수준 결정은 판단 편의적이고 관료주의적이며 결과적으로 조직에 손해를 줄 수 있는 방식이라고 이야기하겠다.

존 헌터(John Hunter)가 그의 연구진인 론다 헌터(Ronda Hunter) 그리고 프랭크 슈미트(Frank Schmidt)와 채용 시 가장 효과적인 예측변수가 무엇이냐에 대해 연구했다[1]. 사람을 뽑을 때에 뭘 봐야 잘 뽑았다고 소문이 나는지에 대한 연구다. 잘 뽑았다는 것의 기준은 이 사람들이 채용된 후에 실제 직무를 하면서 얼마나 생산적이고 성과를 내는지로 판단한다. 통계적으로 말하면 채용 시 선발 여부를 고려하는 변수와 직무 성과라는 변수 양자간의 상관성이 어떤가를 살펴봤다는 것이다.

혹시나 상관성이란 말이 생소한 독자들을 위해 간략하게 설명을 해보자. 상관성은 어느 하나가 올라가거나 내려올 때 다른 하나도 어느 한 방향으로 움직이는지 또는 움직이지 않는지 그 정도를 수치화한 걸 말한다. 예를 들어 부모의 경제적 수준과 자식의 학업 성적은 상관성(일반적으로 부모가 돈이 많으면 자녀의 성적이 높은데 이것을 양의 상관성이 있다고 하며, 반대 방향의 영향이 있으면 음의 상관성이 있다고 한다)이 꽤 높을 것이지만, 부모의 머리카락 길이와 자녀의 성적 사이에는 상관성이 낮을 것이다.

이 상관성은 수치로 1에서 -1 사이의 값이 되는데, 0에 가까우면 상관성이 없다고 말하고, 1(양의 상관성)이나 -1(음의 상관성)에 가까우면 상관성이 높다고 한다. 일반적으로 사회과학에서는 상관성이 0.5를 넘는 경우가 그렇게 흔하지 않다.0.5를 넘으면 강한 효과(strong effect)가 있다고 하고 0.2에서 0.5 사이는 중간 정도라고 하며, 0.2 이하는 약하다고 한다.

우선 이 질문을 좀 더 들여다보기에 앞서 다음 질문에 답해보자. 사람을 잘 뽑는 것이 정말 중요한가? 얼마나?

존 헌터는 미국 연방 정부의 숫자들을 가지고 몇 가지 대략적인 추산을 해보았다. 거기에서 사람을 뽑을 때 나름 직무 성과와 상관성이 높은 선발 방식을 갖고 있다고 가정하자. 선발 테스트와 그 이후 직무 성과의 상관성이 0.5를 좀 넘는 수준이라고 보고, 매년 평균 몇 명을 뽑는지, 평균 근속 연수가 몇 년인지, 평균 임금은 얼마인지 등으로 계산을 해서 앞서의 선발 테스트를 적용하면 1년에 150억 달러가 넘는 생산성 향상(무작위로 뽑는 것에 비해)을 얻는 것으로 나온다. 만약 상관성이 절반 이하인 선발 테스트를 하면 그 150억 달러에서 최소 100억 달러가 넘는 금액을 잃는다.

이 연구는 85년 동안의 심리학 연구를 합해 메타 분석을 한 것으로 대상은 피고용자 3만 2000명을 포함하며 산업 및 조직 심리학, 특히 직원 선발(personnel selection)에 있어 매우 중요한 위상을 차지하고 있다. 여기에서 발견된 것들에 반론을 달기는 그다지 쉽지 않을 것이다.

이 연구 결과 경력 연차는 직무 성과와 얼마나 많은 상관성을 갖고 있었을까? 또 학력과의 상관성은 얼마나 됐을까? 경력 연차의 상관성은 0.18, 학력의 상관성은 0.10이다. 상관성이 0.20 이하이면 사회과학에서도 꽤나 약한 상관성이라고 말한다. 관심사(interests)도 직무 성과와 0.10의 상관성을 갖는 수준이다. 즉, 학교에서 받은 교육 연수로 사람을 뽑으면, 채용 후 직무 성과 면에서 봤을 때에 관심사를 보고 뽑는 것과 별반 다를 바가 없다는 이야기다.

어떤 것들이 상관성이 높았을까? 작업 샘플 테스트(work sample test: 실제로 채용 후 해야 할 작업의 일부를 해보는 테스트)가 0.54, IQ와 같은 지능 테스트가 0.51, 구조화된 인터뷰(예컨대 모든 후보에게 직무 분석을 토대로 한 같은 순서의 같은 질문을 하는 인터뷰)가 0.51이다. 성실성이나 꼼꼼함 같은 성격 테스트도 0.41이나 0.31 정도의 상관성이 있었다. 레퍼런스 체크(예전 직장의 상사 등에게 확인)도 0.26으로 앞서의 “연차”들보다 높다(작업 샘플 테스트, IQ,, 구조화된 인터뷰, 성격 등을 결합하면 직무 성과에 대한 예측력이 좀 더 높아진다).

연차들보다 낮은 것들은? 필체나 나이 같은 것은 0.02, -0.01 수준이다.

하지만 연차가 완전히 의미가 없는 것은 아니었다. 경력 처음 몇 년 동안에는 연차의 상관성이 꽤 높은 편이다. 하지만 연차가 높아짐에 따라 그 상관성은 곤두박질친다. 즉, 대학을 갓 졸업한 사람과 2년 차 프로그래머 중에서 후자의 실력이 높을 확률은 크다. 하지만 예컨대 5년 차와 10년 차의 연차 차이는 실력에 있어 큰 의미가 없다.

앞서의 연구에 대해, 소프트웨어 분야에 특화한 연구가 아니므로 받아들일 수 없다고 생각하는 사람들도 있을 것이다. 그럼 소프트웨어 쪽은 어떤가 알아보자.

현실적으로 경력은 측정이 간단하므로 이 분야에서도 경력을 통해 업무 능력을 추측하는 경우가 많다. 1980~90년대에 걸쳐 이루어진 많은 소프트웨어 개발 전문가에 대한 연구들의 가정은 전문가를 경력이 많은 사람과 동일하게 취급하는 것이었다. 예를 들면 학부생과 대학원생, 또는 학생과 전문개발자 식으로 비전문가와 전문가를 구분해 실험, 비교했다. 반면에 상대적으로 그렇게 흔하지는 않지만, 전문가를 (좀 더 귀찮은 작업이긴 하지만) 실력이 뛰어난 사람으로 정의하고 진행한 연구들도 있다[2].

이런 연구들을 서로 비교해 보면, 경험이 많은 사람으로서의 전문가와 실력이 뛰어난 사람으로서의 전문가가 비슷한 면도 있지만 다른 면, 심지어는 정반대의 면도 있음을 발견한다.

소프트웨어 설계와 프로그래밍에 대한 전문성 연구에서 요구 사항 분석 단계의 전문가와 비/준전문가의 차이를 보면, 경험 많은 사람(경험이 부족한 사람과 비교해)을 전문가로 본 연구에서는 그들이 문제 이해에 더 많은 시간과 노력을 기울이는 것으로 밝혀졌으나, 실력이 뛰어난 사람은 (실력이 보통 정도인 사람과 비교해) 문제 이해에 시간을 적게 쓰는 것으로 나왔다. 그리고 실력이 뛰어난 전문가일수록 의사소통과 협력에 많은 시간을 사용한다는 것도 밝혀졌다. 이렇게 우리는 경력과 실력을 양변에 놓는 항등식의 함정에 빠지면 잘못된 전문가상(전문가의 이미지가 전문가의 현실을 바꾸는 상황)을 갖는다는 것을 알 수 있다.

이런 전문가에 대한 새로운 정의로 접근한 연구들을 통해 앞서 말한 바와 같이, 최소한도의 경험치만 넘어가면 경력 연수와 실제 직무성과의 상관성이 생각보다 낮다는 것이 소프트웨어 개발뿐만 아니라 여러 영역에서 밝혀졌다[3]. 한 가지 흥미로운 연구(Sonnentag, 1995)에서는 경력이 직무성과와 관련이 있음을 발견했다. 단, 이 경우 경력 연차가 아니다. 개발자의 경험이 얼마나 폭넓고 다양했는지가 실제 직무성과와 관련이 있었다.

좀 더 널리 알려진 연구를 인용해 보자. 톰 디마르코와 티모시 리스터가 한 유명한 연구가 있다[4]. 1984년부터 1986년까지 92개 회사에서 600명 이상의 개발자를 대상으로 프로그래밍 생산성 비교를 했다. 가장 놀라운 점은 개발자 개개인의 능력 차이다. 최고는 최악보다 열 배 정도 업무 능력이 뛰어나다. 중간 이상의 업무 능력을 가진 사람들은 그렇지 못한 나머지 절반보다 두 배쯤 뛰어나다. 그런데 그런 능력 차이보다 다음 내용을 주목하자.

조사 결과를 분석하면서 우리는 다음과 같은 요인들이 업무 능력과 거의 상관없음을 알아냈다. … * 경력: 경력 10년 차 사람들이 경력 2년 차 사람들보다 더 뛰어나지는 않았다. 대회에서 사용한 프로그래밍 언어를 경험한 지 6개월 미만인 사람들이 나머지 사람들보다 잘하지 못했다는 사실을 제외하고는 경력과 업무 수행 능력은 깊은 상관성이 없었다.

그들은 이 연구에서 경력과 업무 수행 능력에 깊은 상관성이 없다고 밝혔다.

나는 소프트웨어 개발 프로세스(특히 애자일) 컨설팅을 한다. 소프트웨어 성공을 위해 고민을 하다 보니, “사람”이라는 요소가 정말 중요하다는 교훈을 얻었고, 그러다 보니 인력 구인/선발 프로세스 컨설팅도 제공한다.

그런 경험을 통해 항상 느끼는 것이지만, 대다수의 조직에서 직원을 뽑는 데 중요하다고 생각하는 요소는 많은 경우 별로 중요하지 않고, 중요하지 않다고 생각하는 요소는 중요하다. 예를 들면 경력을 지나치게 중요하게 여기는 회사가 많다. 동시에 협력 능력을 지나치게 등한시하는 회사가 많다. 통계적으로 분석을 해보면 채용자 스스로도 놀란다. ‘어, 나는 당연히 이게 높은 사람이 성과도 좋을 줄 알았는데…’

나는 회사에서 사람을 뽑을 때 경력에 대한 현실적 대안을 이야기하기 이전에 경력이 오히려 편향을 주는 잘못된 지표가 될 수 있다고 본다. 최소한도의 경력 수준만 넘겼으면 오히려 몇 년 일했는지는 모르는 것이 더 낫다고 본다. 그 이후에는 구조화된 인터뷰(특별히 구조화된 행동중심적 인터뷰(structured behavioral interview)를 권한다. 간략한 설명은 「인터뷰에서 진실을 들으려면」을 참고하라)와 실제 작업을 해보도록 하는 작업 샘플 테스트, 딱히 정답이 없는 퀴즈 문제를 주고 그걸 푸는 과정을 지켜보는 것, 그리고 가능하다면 실제 업무를 주고 시험적으로 짧은 기간 동안 일을 해보게 하는 것 등을 권한다. 그리고 전체 구인 과정에서 실제로 함께 일할 사람들이 인터뷰에 참여하도록 하는 것을 강력히 권한다.

하지만 이런 것들만큼, 또는 그 이상으로 중요한 것이 또 있다. 이미 뽑은 사람을 어떻게 할 것인가 하는 문제다. 많은 조직이 사람을 뽑는 것에는 신경을 쓰지만 이 사람들을 차후 어떻게 교육, 훈련시키고 성장시킬지에 큰 노력을 들이지 않는다(며칠을 고민해서 이것저것 비교하다가 운동 기구를 사놓고는 그 이후 실제 운동은 잘 안 하는 경우라고 할까).

보험 설계사가 업무 중에 자신의 능력을 향상시키기 위해 시간을 얼마나 쓰는가(조금 후에 설명하겠지만 이런 것을 의도적 수련이라고 한다)와 직무 성과를 비교한 연구[5]에서는 요즘 일주일에 그런 시간을 얼마나 쓰는지를 물었는데, 그것과 직무 성과 간에 통계적으로 유의미한 양의 상관성이 있었다(경력 연차가 비슷한 사람, 하루 중에 다루는 업무량이 비슷한 사람끼리 비교를 해도 그렇다). 반면 자신의 커리어에서 이제까지의 누적 수련 시간은 현 직무성과와는 통계적으로 유의미한 관계를 보이지 못했다. 그들이 자주 하는 수련으로는 “머리 속에서 시뮬레이션하기”(클라이언트와 어려운 대화 상황을 머리 속에 그리고 가능한 시나리오를 탐색해 봄), “피드백 요청하기” 등이 있었다. 달리 말하면 내가 요즘에 얼마나 공부하고 수련하느냐로 내 직무 성과가 결정되며 이것은 시간이 지나면서 변동 가능하다는 이야기가 된다.

전문성 연구는 사람들 간의 전문성 차이를 연구하는 경우가 일반적이지만, 한 사람이 시간 흐름에 따라 전문성이 어떻게 변하는가를 연구하기도 한다. 우리가 생각하는 것 이상으로 그 변동이 크다. 특히나 우리 분야처럼 지식이 계속 업데이트되는 경우라면 더더욱 그렇다.

그런데 이런 전문성 관리를 개인에게만 맡기고 회사는 손을 떼고 일년에 한번씩 하위 10%를 해고하는 것은 전체적으로 보아 회사나 개인에게 손해가 된다. 사회적으로도 좋은 일이 못 된다. 조직은 개인이 자신의 전문성을 좀 더 발전시키고 관리할 수 있게 최대한 지원을 해줘야 한다. 그것이 윈•윈하는 길이다.

뽑고 나서 잘 교육하고 성장하게 도와주는 것 이상으로 또 중요한 것이 있다. 시스템이다. 아무리 훌륭한 사람을 뽑아도 조직의 시스템과 문화에 문제가 있으면 그런 사람은 묻혀버리기 쉽고, 반대로 실력이 평범한 사람일지라도 좋은 시스템 속에서는 뛰어난 성과를 낼 수도 있다.

한 가지 극적인 예를 들어보자. 세계 최고의 두뇌집단이라는 나사(NASA)에는 뛰어난 인재들이 모여 있다. 하지만 1986년에 챌린저호 폭발 사고에서 교훈을 충분히 배우지 못했던 것 같다. 그것이 컬럼비아 사고 조사 위원회에서 내린 결론이다. 2003년 2월 1일 컬럼비아호는 귀환 도중 공중 폭발하여 탑승자 전원 사망에 이른다. 사고 조사 위원회에서는 챌린저호 사고와 컬럼비아호 사고에 유사성이 많다고 본다. 두 사고에 관련되어 있는 사람들은 거의 전원 다르지만 조직 체계와 문화는 별로 변하지 않았다. 비현실적인 예산과 일정에 맞추도록 강압되는 상황에서 기술적 전문성을 가졌으나 힘없는 사람들의 목소리는 완전히 밟혀버렸다. 사고 조사 위원회는 조직 체계가 바뀌지 않는 이상 비슷한 사고가 또 생길 수밖에 없다고 결론지었다. 품질 석학 에드워드 데밍(Edwards Deming)은 직원들이 문제가 아니라, 그 사람들이 속한 시스템, 그리고 그걸 만들고 책임지는 경영진이 문제라고 했다.

나는 이렇게 예측한다. 소프트웨어 개발에서 점차 경력 연수를 중시하는 문화가 사라질 것이다. 따라서 개발자들은 자신의 경력 연차 외에 다른 것에도 신경을 써야 한다.

요즘 1만 시간 법칙이 유행이다. 국내외에 여러 책에서 그 법칙을 언급하고 있다(말콤 글래드웰의 『아웃라이어』라는 책이 야기하는 오해에 대해 내가 블로그에 쓴 「1만 시간 법칙에 대한 오해」를 참고하라). 특정 분야의 전문가가 되는 데 1만 시간의 노력이 필요하다는 법칙으로 설명되고 있다.

자신이 IT 분야 종사자라면 그 법칙을 듣고 대부분 어림추산을 해봤을 것이라 생각한다. ‘아, 내 경력이 6년이고, 야근도 좀 해주고 했으니까, 대충 계산하면… 오호, 1만 시간 넘네. 아싸.’

그런데 좀 이상하지 않나? 우리는 하루 세 번 3분씩 이를 닦는다. 대략 다섯 살부터 닦았을 것이고 죽기 전까지 닦을 것이다. 그런데 이 닦는 경력과 실력에 어떤 관련이 있다고 생각하는가? 나이 육칠십쯤 되면 도사 수준은 못되어도 준전문가 소리는 들어야 하지 않을까? 그런데 나이 들었다고 이 잘 닦는 사람 이야기를 들어본 적이 없다. 예를 들어 칫솔에 특수 약품을 묻히고 이를 닦은 후에 어느 부위가 닦였는지 안 닦였는지를 확인하면 얼마나 제대로 이를 닦는지를 알 수 있는데 이 실력과 칫솔질 경력과는 아무 상관이 없을 것이다.

1만 법칙을 히트시킨 주인공, 안데쉬 에릭손(Anders K. Ericsson)은 딱 잘라 말한다.

그가 말하는 1만 시간 법칙에서 1만 시간은 “자신의 기량을 향상시킬 목적으로 반복적으로 하는 수련”을 하는 시간을 일컫는다. 그런 수련을 그는 의도적 수련(deliberate practice)라고 한다. 악기 연주자에게는 공연 시간은 이런 의도적 수련이 되지 못한다. 체스 선수에게는 토너먼트 시간도 이런 의도적 수련이 되지 못한다. 정말 기량 향상을 목적으로 자신의 약점을 개선하려고 애쓰는 수련, 그것만이 의도적 수련이다. 통계적 분석의 결과가 그렇다. 실제 실력과 상관 있는 것은 의도적 수련이었다.

그럼 계산을 다시 해보자. 누적 몇 시간이 나오나. 상당히 좌절스러울 것이다. 하지만 업무를 하면서도 의도적 수련을 하는 방법이 있다. 개발자들이 의도적 수련을 늘릴 수 있는 방법에 대해 월간 마이크로소프트웨어 2005년 4월호와 6월호에 내가 쓴 「고수: 무술과 프로그래밍에 대한 소고」 1, 2를 참고하라.

그 내용을 여기서 간략히 소개하자면, 한마디로 애자일 철학을 활용하는 것이다. 애자일은 학습을 소프트웨어 개발의 가장 큰 병목 중 하나로 본다. 일반적 프로젝트에서는 모든 피드백의 주기가 느리다. 예를 들면, 내가 설계 단계에서 했던 결정의 피드백을 몇 달 후(테스트 단계)에 받는다. 이미 그 때쯤 되면 내가 예전에 왜 그런 결정을 했는지 자체가 가물거린다. 설사 그 때 기억이 난다고 해도, “아, 그런 거였군”하고 지나치기 쉽다. 실수를 교정할 기회가 다시 오지 않기 때문이다. 하지만 애자일 프로젝트에서는 지금 내가 한 행동의 피드백을 10분 후, 한 시간 후, 하루 후, 일주일 후 등 여러 주기를 통해 지속적으로 얻을 수 있다. 그리고 그 때 저지른 실수는 바로 다음 주기에서 교정할 수 있다.

이 두 가지가 학습에 어떤 차이를 불러일으킬지 쉽게 상상이 되지 않는 독자들을 위해 두 가지 예를 들겠다. 1) 골프 퍼팅 연습을 하는데 공이 어디로 가는지 전혀 보지 않고 1000개의 공을 친다. 2) 스키너의 상자 속에 생쥐 한 마리가 있고 거기에는 버튼과 먹이가 나오는 대롱이 있다. 버튼을 누르면 먹이가 나오지만 생쥐는 처음에 그 관련성을 모른다. 우연히 부딪혀서 몇 번 먹이를 받아먹은 후에는 배고플 때마다 직접 버튼을 눌러 먹이를 먹는다. 학습을 한 것이다. 하지만 영원히 학습을 못하게 할 수 있다. 버튼을 누른 시점과 먹이가 나오는 시점 사이의 시간 간격을 조금씩 늘려가다 보면 어느 시점에 생쥐는 학습을 못한다. 피드백 주기가 길어지면 학습이 안 된다.

여기에선 에릭손의 인터뷰 내용 일부를 인용하며 힌트를 드리고 마치겠다. 뛰어난 진단전문의(닥터 하우스를 떠올리면 된다)의 의도적 수련에 대한 이야기다.