안녕하세요 개발자 doro입니다.
Introduction
많은 개발자분들이 그렇듯 저에게 있어서 코딩은 일이 아니고 삶입니다. 단기간 안에 무엇인가 만들어야만 하는 숙제가 아니고, 늘 고민하며 저의 삶과 함께 하고 있습니다. 그래서 저는 어느 언어를 사용하냐, 어느 플랫폼으로 어떤 직군에서 일을 하냐는 그렇게 중요하게 생각하지 않습니다. 단지, 컴퓨터를 공부하는 것이고, 하나를 알더라도 정확하게 아는 것이 중요하다고 생각을 하며 개발을 배워나가고 있습니다.
그런데 30년차 개발자인 아버지는 늘 동료의 중요성을 강조하십니다. 혼자 컴퓨터를 얼마나 잘하는가도 중요하지만 세상에 가치 있는 일을 만들기 위해서는 혼자만의 힘으로 할 수 있는 것은 한계가 있다고 저에게 어렸을 때부터 말씀해주셨습니다.
그래서 저는 개인적인 실력에 대해선 어떻게와 무엇을 할지 고민해 본적은 없으나 동료라는 주제에 대해선 늘 고민이고 숙제라고 생각하고 있었던지라 책 제목에 흥미를 느끼며 첫 장을 피게 되었습니다.
당신은 몇 년차?
필자는 첫 장으로 경력 연차와 업무 생산성에 관한 이야기를 했습니다. 결론부터 말하자면
어느 수준 이상의 경력은 업무의 생산성을 판단하는데 효력이 없다
였습니다.
이는 톰 드마로크와 티모시 리스터의 실험을 예로 들었는데, 개발자의 경력보다는 구조화된 인터뷰나 작업 샘플 테스트로 인해 채용을 했던 직원들이 더 생산성이 높은 결과를 만들었다는 것 이었습니다.
물론 대학을 갓 졸업한 개발자와 2년차의 개발자의 업무 실력은 차이가 확연히 있었지만, 5년차와 10년차 개발자의 차이는 그렇게 크지 않았다고 합니다. 결국에 일정 시간 이상의 경력은 시간에 비례하여 생산성을 만들어 낼거라고 기대할 수 없다는 것이었죠.
제 생각도 마찬가지 입니다. 일정 시간이 지나면 결국엔 밀도가 중요합니다. 얼마나 그 분야에 고민을 했고, 타당성과 피드백이 이루어지는 의도적 수련을 얼마나 했느냐가 실력에 영향을 준다고 생각합니다.
결국
강한놈이 오래 가는 게 아니라, 오래 가는 놈이 강한 거더라
라는 말은 몇 년차 이상부터는 그렇게 신뢰할 수 있는 말은 아니게 되는것이지요.
가장 학습하기 힘든 직업이 살아 남는다
2016년 알파고의 등장으로 세상 사람들이 “자신의 직업이 컴퓨터로 대체 되지 않을까”하는 불안감을 화두로 얘기를 시작하고 있습니다. 옥스포드 대학에서 발표한 논문에 의하면
- 독창성
- 사회적 민감성
- 협상
- 설득
- 타인을 돕고 돌보기
가 필요한 직군일 수록 컴퓨터로 대체되기 어렵다고 말하고 있습니다. 또한 이러한 직업들이 학습하기 쉽지 않은 직군입니다. 이렇게 학습하기 어려운 직군들의 특징은 또 몇 가지로 나눌 수 있었는데, 그 특징은 유동적, 불확실성 등과 같이 데이터만으로는 획일화 될 수 없는 직관의 영역들과 관련된 부분이었습니다.
단순히 주어진 업무를 하는 프로그래머는 45퍼센트의 확률로 대체될 수 있다고 하지만 사용자의 요구사항을 분석하고 그에 대한 솔루션을 설계하는 소프트웨어 개발자는 4.2퍼센트로 컴퓨터가 대체할 확률이 낮았습니다.
즉 개발자는 단지 코딩만 하는 프로그래머와는 다르게 더 높은 수준에서 사회적 맥락을 이해해야 한다는 것입니다. 남이 시킨 대로 혼자 프로그램을 만드는 것 그 이상으로, 다른 동료들과 협력하며 직관을 개발자가 되어야 합니다.
당신이 제자리 걸음인 이유
필자는 실력을 향상시키기 위해서는 의도적 수련이 중요하다고 강조하고 있습니다. 1만 시간의 법칙으로 의도적 수련의 양적인 측면은 많은 사람들이 인지하고 있지만 질적인 측면에 대해서는 간과하는 경우가 많습니다.
질적인 측면에서 의도적 수련이 일어나기 위해서는 자신의 실력에 업무를 하는 것이 중요하다고 했습니다. 자신의 실력이 i라면 i+1에 맞는 작업들을 연습할 때 집중력이 최대로 올라가고 몰입을 할 수 있기 때문이지요.
현재 자신의 업무의 난이도가 너무 낮아 지루함을 느껴 몰입이 되지 않는다면, 제약 조건을 거는 등 현재 자신의 실력을 낮춰서 업무를 해보기를 제안했습니다. 예를 들어, 이소룡은 상대를 3분만에 제압시키지 못했다는 이유로 이겼지만 졌다고 생각하며 자신을 더 수련했다고 합니다.
같은 업무를 하더라도 특정 제약조건을 걸어서 자신의 부족한 부분의 실력을 더 갈고 닦을 수 있는 등의 방법입니다.
이는 개발자로서 정말 중요한 부분이라고 생각합니다. 특정 기능을 구현하는 것은 어느 정도 고민을 하면 누구나 가능한 부분이라고 생각합니다. 하지만 이 기능을 잘 짜여진 디자인 패턴 안에서 동작을 하게 한다거나 동작 이후에 테스트 코드를 작성해 좀 더 정확성을 보장받는다는거나 하는 등, 기획자가 요구하는 기능이 동작한다고 해서 개발자가 할 일을 다 했다고 생각하는 것은 자신의 성장에 제동을 거는 사고방식입니다.
저는 위에서 말했다시피 “무엇을”할지 고민하는 것은 그렇게 중요하다고 생각하지 않았습니다. 많은 사람들이 고민을 위한 고민 때문에 시간을 허비한다고 생각했고, 실제로 아무것도 하지 않은 채 뭘 할지 모르겠어서 스트레스 받는 경우도 많다고 생각했었으니깐요.
그래서 “무엇이든 하자”라는 생각으로 살아왔습니다. 하지만 제 자신의 문제가 무엇인지 정확히 상황 파악을 하고 적절한 업무를 저에게 할당하는 것 또한 중요한 프로세스임을 알게 되었습니다.
나홀로 전문가에 대한 미신
보통 어떤 사람이 전문가라고 하면 그 사람의 뇌 안에서 무슨 일이 벌어질까에만 주목하는 면이 있습니다. 때로는 고독한 천재같은 전문 지식은 뛰어나지만 사회성은 부족한 사람을 전문가의 대표 이미지로 떠올리기도 하죠. 그런데 현실에서의 전문가가 과연 그런 사람일까요?
아무리 기술적으로 훌륭한 실천이라고 해도 그 기술은 사회적 맥락에서 사회적 자원을 가지고 실천되어야만 합니다. 팀원들이 마음에 안들고 그들도 나를 마음에 들어하지 않는 상황에서는 어떤 기술을 골라도 실패하곤 하죠.
회사에 새로운 기술, 예를 들어 TDD를 도입하고자 할 때, TDD가 어렵거나 TDD에 대한 도메인 지식이 부족해서 못하는 경우는 매우 드물었다고 합니다. 어떤 기술적 지식을 전달하기 위해서는 그것을 사회적 맥락 속에서 가르치고 경험하게 하려고 노력하는게 중요하기 때문이죠.
저 또한 “나홀로 전문가”가 되기 위해서 많이 노력해왔습니다. 아직 주니어 개발자이다 보니 도메인에 대한 지식이 부족하고, 더 많은 공부를 함으로써 전문가가 될 수 있다고 믿어왔기 때문이죠. 하지만 더 큰 의미에서의 훌륭한 개발자가 되기 위해서는 사회적 맥락을 무시하면 안된다는 생각도 하게 되었습니다.
이 글을 읽고난 후에는 , 제가 가진 기술을 사회적 맥락안에서 실현시키기 위해 노력을 해볼 것입니다.
복수 공유
두 명의 디자이너가 공익 광고에 관련된 디자인 시안을 서로 30분 동안 개별적으로 디자인하고 이후에 서로의 디자인을 피드백 하는 시간을 가졌습니다.
이 때
- 하나의 디자인을 하고 하나를 공유하는 하나 공유
- 여러 개의 디자인을 하고 최고만 공유하는 최고 공유
- 여러 개의 디자인을 하고 여러 개를 공유하는 복수 공유
로 나눠서 실험을 진행했습니다. 실험 이후에 상대방에 대한 신뢰도를 점수를 매겨 측정을 했는데 놀랍게도 “복수 공유”를 했을 때만 유의미하게 신뢰도가 증가했다고 합니다.
현실 세계에서는 보통 1,2번의 형태가 흔히 하는 공유의 방식일 겁니다. 이는 안하느니만 못한 피드백 방식이라는 것이죠. 복수공유는 여러 개를 준비했으니 그 중 하나에 대해서 안 좋은 피드백이 오고 가도 괜찮습니다. 나에 대한 공격이 아니니깐요. 피드백시에 훨씬 더 열린 마음으로 할 수 있게 됩니다.
또한 복수 공유 피드백 이후에 고친 작업물들은 전문가 평가나 노출당 클릭률이 더 올라가는 결과를 만들었습니다. 복수공유는 디자이너들간의 신뢰도가 상승했을 뿐만 아니라 작업물도 더 좋아졌다는 말입니다.
이렇게 협업을 할 때, 어떤 조건에서 피드백이 이루어지냐가 상대방의 신뢰도와 나의 작업물에 모두 영향을 끼칠 수 있다는 사실이 정말 새로웠습니다. 자신의 단점과 장점을 모두 공유하며 상대방에게 저 자신을 온전히 공유하는 것, 그것이 복수 공유가 가진 장점이 아닐까 생각합니다.
이것도 모르세요?
다음 대화에서는 사수인 홍춘이와 부사수인 술퍼맨이 등장하고, 부사수가 사수에게 모르는 것을 물어보는 장면입니다.
술퍼맨 : 저기, 홍춘이님
홍춘이 : 네?
술퍼맨 : 정규식을 쓰다가 물어볼 게 있어서요. 시간 괜찮으세요?
홍춘이 : 네 그러세요
술퍼맨 : 이런 문자열을 잡아내려면 패턴을 어떻게 써야 하는지 감이 잘 안 오네요. 정규식에 익숙하질 않아서..
홍춘이 : 뭔데요? ( 힐긋 보고는 ) 이것도 모르세요?
술퍼맨 : …
홍춘이 : 혹시 정규식 관련 책 보셨어요?
술퍼맨 : 아니요.
홍춘이 : 그럼 유닉스 정규식 man 페이지 읽어보셨어요?
술퍼맨 : 딱히…
홍춘이 : 저기 회사 서기에 가면 정규식 교과서 하나 있거든요? 그거 좀 읽어보고나서 그래도 해결 안 되면 저한테 오세요.
술퍼맨 : (기어들어가는 목소리로) 네…
뭐 이 정도까지는 아니어도 저 또한 비전공자가 코딩 관련 질문을 하면 항상 좀 더 혼자서 고민해봐라는 식으로 조언을 해줬습니다. 개발자에게 있어서 혼자 고민하고 혼자 답을 찾을 수 있는 능력은 매우 중요하다고 생각했기 때문이죠.
그런데 비코치 입장에서 생각을 해본다면, 문제를 겪게 된 상황에 대한 이해나 현재 생각에 대해 공감을 해준다면 저의 조언을 받고 좀 더 기분 좋아진 상태로 혼자 고민을 하는 시간을 가지게 되지 않을까? 라는 생각이 문득 들게 되었습니다.
앞으로는 피코치가 문제를 겪고 있는 것을 알게 되었을 때, 그 문제를 해결했던 저의 방법을 알려주는 것보다, 그 사람이 어떻게 그 문제에 직면을 하게 되었는지 진단을 잘 해서 피코치의 에너지와 기술 외적인 부분까지 관여를 할 수 있는 조언을 하기 위해 노력을 해야 겠다는 생각이 들었습니다.
패러다임 전환, 죽느냐 사느냐
사장님이 기술 컨퍼런스에서 뭘 들었는지
올해 안에 MVC 기반의 자바로 바꿔라!
라는 방침이 떨어졌습니다. 사내에 어떤 팀은 자바로 잘 옮겨탔지만 몇몇 팀은 여전히 기존의 코드를 부등켜 안고 전전긍긍 하고 있었는데요. 패러다임을 전환하는데 중요한 요소로 작용했던 것이 어떤 것들이 있었을까요?
놀랍게도 도메인 지식이 훌륭한 사람이 속한 집단이라고 해서 패러다임의 전환이 잘 일어난다는 상관관계는 증명할 수 없었습니다. 또한 교육 배경이나 관련 경험들 , 그리고 학습 속도 마저도 관련이 없었습니다.
도전 자체를 팀의 학습 능력에 대한 도전으로 받아들이고, 같이 학습해야 한다고 생각하는 태도가 가장 크게 작용하였습니다.
- 다른 사람과 협력을 잘 할 수 있고
- 새롭고 애매모호한 상황을 즐길 수 있고
- 자기보다 지위가 높은 사람들에게도 자신있게 의견을 제안할 수 있는
팀의 분위기가 쾌속 학습으로 가는 지름길이라고 하였습니다.
이런 내용은 평소에 제가 가지고 있는 “겸손하게 코딩하자”라는 식의 생각과 일맥상통하였습니다. “그거 내 업무 아니야”, “그거 내 탓 아니야” 라는 식의 생각은 서비스와 팀 안에서의 나의 위치를 경직되게 만들고 수동적이게 만들게 됩니다. “내 코드가 맞아”라는 식의 생각이 결국에는 새로운 상황에 직면하였을 때, 자신의 잘못을 피드백하기 어렵게 만듭니다.
이러한 유동적이고 능동적인 자세로 개발을 하며 제가 속해있는 단체에 긍정적인 영향을 끼칠 수 있게 노력하는 개발자가 되야겠다고 생각했습니다.
고객에게 매일 가치를 전하라
필자가 애자일이라는 단어를 한 줄로 표현한 것입니다. 참 귀찮습니다. 고객이라는 존재는 상황에 따라 변화하며 변화하는 고객에 대해서 다른 가치를 전달해줘야 합니다.
그것도 매일말이죠. 한꺼번에 전달하면 좋겠지만, 점진적으로 전달해야합니다. 목적지가 항상 변화하고 그에 대한 피드백이 자주 이루어져야 하기 때문이죠.
제 친한 친구와 함께 무엇을 공부할지 논의를 한 적이 있습니다. 한참을 논의하다가 “아 그건 너무 귀찮지 않을까?” 라는 주제를 마주한 적이 있었는데요. 저희 둘은 한숨을 내쉬며 이 주제를 공부하기로 결정하였습니다.
“귀찮다고 생각한거 보니깐 우리에게 꼭 필요한건가 보다”가 저희의 결론이었습니다. 귀찮은 것은 그 자체가 정말 쓸데없는 일인 경우는 정말 드물다고 생각합니다. 정말 필요한 것들인데 하기가 싫은 경우가 대부분이고, 식탁위의 시금치마냥 외면하고 싶어지는 존재이죠. 매일 아침 6시에 일어나 5km 달리기를 하지 않을 이유가 없습니다. 그냥 귀찮아서 못하는것이죠.
필자의 말처럼 성장하려면 귀찮은 것을 마주하고 정면돌파 해야합니다. 인간관계에서도 그렇고 합리화 하지않고 겸손하게, 그리고 “재밌게” 함께 자라는 개발자가 되야겠습니다.
마치며
저의 아버지는 재무재표를 보면서 코딩을 해야한다고 말씀하십니다. 기업이 필요한 것이 무엇인지 능동적으로 분석하고 그 문제를 해결하는 개발자가 되라고 하셨습니다. iOS 개발자인 저의 형은 주어진 일을 넘어서 더 좋은 방안이 있다면 반대를 무릅쓰고 프로토타입을 실제로 제작해 사람들을 설득해 보라고 말합니다.
위의 주옥같은 말들을 이 책을 읽으면서 한 번 더 생각을 해보게 되었고, 기술적인 능력 향상도 점진적으로 이루어져야 하지만 어떻게 사람들을 사회적 문맥속에서 이해하는가도 항상 염두해두며 개발을하는 개발자 인생을 살아야겠습니다.
긴 글 읽어주셔서 감사합니다.
