함께 자라기

저자인 김창준님의 세미나를 두 번 들었다. 첫 번째는 XPER에서 진행하는 “의도적 수련”, 두 번째는 이브레인에서 주최한 개발자 실력 평가 어떻게 할 것인가? 였다. 두 세미나 모두 나에게 생각할 거리를 던져 주는 훌륭한 세미나였다.

이번에 페이스북 피드에서 ‘함께 자라기’ 책을 내신다고 하길래 꼭 읽어 봐야겠다는 생각을 하고 있었는데, 아니나 다를까 나온 지 얼마 되지도 않았는데 동료들의 책상 위에서 그리고 페이스북 피드에서 이 책이 보이기 시작했다.

개발자 채용을 할 때, 그리고 구성원들에게도 “함께”와 “성장”을 자주 말하곤 한다. 하지만 성장이 어떻게 이루어지는가, 어떻게 하면 함께 잘할 수 있는가에 대한 고민과 통찰은 부족했다. 이 책을 가볍게 요약해 보며 내 경험을 덧붙여 본다. 그리고 이를 통해 내 생각을 다져본다.

목표하는 프로그램을 떠올리며 프로그래밍 언어를 학습하면 도움이 되는 것처럼 책을 읽을 때에는 독후감 쓸 것을 생각하며 읽으면 더 얻어가는 것이 있다. 책에서 말하는 적극적 읽기다.

자라기

당신은 몇 년 차?

개발자들을 만나보고 함께 일해 보면 책에서 언급한 것처럼 2년이 넘으면 연차라는 것이 큰 의미가 없다는 것을 느낀다. 다시 말해 보면 단순 근무를 한 연수는 중요하지 않고, 나아가는 시간이 얼마나 되었느냐가 중요하다. 이 수련의 시간에 영향을 크게 미치는 것이 피드백을 짧은 주기로 얻는 것, 그리고 실수를 교정할 기회를 얻는 것이다. 이것에 해당하는 것이 제대로 된 코드 리뷰이다. 작성한 코드에 대해서 빠르게 피드백을 받을 수 있고 피드백을 받게 되면 실수를 교정할 기회를 적은 비용(장애 없이!)으로 얻을 수 있다.

나도 개발한 지 10년이 넘었는데 이제 연차를 말하기가 좀 부끄러워지려 하고 있다. 지금 1~2년 개발한 친구들을 보면 이들 중 대부분이 10년 이후 나보다 훨씬 더 좋은 개발자가 되리라 생각이 든다. 나아가는 시간이 필요하다.

자기 계발은 복리로 돌아온다.

조직의 작업은 다음 3가지 차원으로 나뉜다.

A 작업: 한 회사의 제품과 서비스의 개발
B 작업: A를 개선하는 시스템과 프로세스를 개발
C 작업: B를 개선하는 것

개발팀을 기준으로 좀 더 구체적인 예를 들어 보자면, B 작업은 CI, 스크럼 도입과 같은 것이 되겠다. C 작업은 이런 개선들을 지속적으로 할 수 있는 개발 문화가 되겠다. 개인의 기준에서 살펴보면 B 작업은 독서나 공부와 같은 일반적인 자기 계발이 되겠다. 그리고 C 작업은 자기 계발을 잘하기 위한 회고, 환경을 갖추어 나가는 것이 되겠다.

B, C 작업에 대한 비중이 얼마나 되는가가 그 사람과 조직의 미래를 결정한다.

학습 프레임과 실행 프레임

학습 프레임: 이 일을 통해서 무엇을 배울 수 있을까에 집중
실행 프레임: 이 일을 통해서 무엇을 얻을 것인가에 집중

달리 이야기해보면 과정에 가치를 둘 것인가? 결과에 가치를 둘 것인가? 에 대한 이야기이기도 하다. 과정에 가치를 두었을 때가 더 학습에 유리하다는 이야기다. 결과라는 것은 항상 불안하다. 그 목표를 내가 달성할 수 있을까? 라는 생각이 들기 시작하면 현재에 집중하지 못한다. 하지만 과정에서의 학습에 집중하면 현재에 몰두할 수 있다.

스타트업에서의 삶이라는 것이 이것과 비슷하다는 생각이 든다. 스타트업은 항상 이 회사가 성공할 수 있을까? 에 대한 의문이 따른다. 성공에 대한 확신을 갖는 것이 쉽지 않기 때문에 이 성공에 대한 불안감이 현재에 집중하지 못하게 한다. 스타트업에서의 삶이라는 것이 다른 선택 보다 학습에 유리한 상황이기에 이것에 집중해서 한걸음 한걸음 내딘는 것이 결과를 위해서도 더 옳은 방향이 아닐까 싶다.

의도적 수련

의도적 수련을 통해 전문성을 형성하기 위해서는 다음과 같은 것이 필요하다.

동기: 실력을 개선하고 싶다.
타당성: 전문성을 형성하고자 하는 영역이 예측 가능해야 한다.
피드백: 구체적인 피드백을 적절한 시기에 받아야 한다.
적절한 난이도: 난이도와 작업의 실력이 엇비슷하게 맞아야 한다.

이 중 피드백과 난이도에 대한 생각을 덧붙여 본다.

피드백

소프트웨어 개발에 대한 피드백은 4단계로 이뤄지는 것 같다.

첫 번째는 스스로 만든 테스트 케이스에 의한 피드백이다. 이 과정을 통해서 기본적인 동작에 대한 피드백을 받을 수 있다.
두 번째는 코드 리뷰를 통한 피드백이다. 모듈 단위의 설계를 잘했는지 가독성이 좋은 코드를 만들었는지에 대한 피드백을 받을 수 있다.
세 번째는 고객을 통한 피드백이다. 내가 만든 코드가 “가치”를 전달했는지에 대한 피드백을 받을 수 있다. 나의 의도가 “실제 문제”를 해결했는지를 알 수 있다.
네 번째는 프로젝트의 진행에 따른 피드백이다. 해당 프로젝트를 지속적으로 개발해 나가면 기존에 작성한 코드가 얼마큼 미래의 변화를 예상했는지를 알 수 있다.

소프트웨어 개발의 전문성을 키워나가기 위해서는 위 4가지에 대한 피드백이 모두 필요하다. 첫 번째는 TDD 등을 통해서 피드백 주기를 빠르게 할 수 있다. 두 번째는 좋은 개발 환경, 좋은 개발자들과 함께 일하면 도움을 받을 수 있다. 세 번째는 좋은 프로덕트를 만나게 되면 얻을 수 있다. 마지막은 큰 규모의 프로젝트를 장기적으로 진행하면 얻을 수 있다.

하지만 개발자에게는 그가 만든 소프트웨어에 대한 피드백만이 필요한 것이 아니라 소프트웨어를 만들어 가는 과정에 대한 피드백 또한 필요하다. 대부분 “함께”에 대한 내용들이다. 이 피드백이 훨씬 어려운 피드백이다.

난이도

실력에 맞는 난이도의 일이 주어졌을 때 가장 몰입을 할 수 있고, 성장이 따라오게 된다. 팀장은 팀원들이 현재 어떤 상태를 경험하는지를 파악하고 몰입을 할 수 있도록 도와주어야 한다. 하지만 종종 반대로 몰입 영역 밖으로 팀원들을 몰아내는 행동을 한다. 그 예는 다음과 같다.

난이도가 낮은 일을 하는 직원에게 동기 부여 차원에서 스터디를 시키거나 콘퍼런스에 보내는 것
높은 난이도의 일을 해서 불안함을 느끼는 직원에게 핀잔을 주어서 자기 효능감을 떨어뜨리거나, 진행 안 되는 문제의 분석을 지시하는 추가 업무로 난이도를 높이는 것

프레임은 생각을 단순하게 만들어 주고 쉽게 해결책을 생각해 볼 수 있게 한다. 실력과 그에 걸맞은 난이도라는 프레임에서 살펴보면 팀원들을 몰입하게 할 수 있는 방법을 보다 잘 찾을 수 있겠다.

실수

실수는 예방하는 것이 아니라 관리하는 것이다.

소프트웨어를 개발하고 서비스를 운영하다 보면 정말 다양한 곳에서 다양한 원인으로 문제가 발생된다. 이 실수를 예방하고자 노력하면 끝도 없고, 답도 없다. 실수가 발생했을 때 그것을 드러내고 근원적인 문제를 찾고 해결해서 더 이상의 유사한 문제가 발생하지 않도록 하는 것이 중요하다.

실수로 큰 장애가 발생하게 되면 개발자 대부분은 충분히 심적인 고통을 받는다. 그리고 사람의 본성에 따라 문제를 축소하고 덮어 두고 싶은 생각이 든다. 팀 리더가 해야 하는 일은 오히려 이런 개발자를 격려하고 그 문제를 함께 분석하고 이미 발생한 장애에서 가치를 찾아내는 일이겠다. 이 장애는 더 큰 장애를 막을 수 있는 소중한 기회다.

뛰어난 선생에 대한 미신

전문가가 기술을 가르쳐 줄 때 그 기술을 성공적으로 해내기 위해 필요한 것의 30%만 가르쳐 놓고 자신은 다 가르쳤다고 생각한다는 것. 요약하면 “이게 안돼?”

실제로 전문가에게는 무의식 중에 해내는것을 설명 하기는 쉽지 않다. 이것은 실제 과업을 함께 해결하는 과정을 통해서 효과적으로 전달된다. 페어 프로그래밍이 그렇고 디버깅을 함께 하는 경우도 그렇다. 함께 작업을 하게 되면 필연적으로 암묵지를 꺼내어 보일 수밖에 없다.

“이것 확인해 보세요.”
“이건 그럼 이 원인이 아닌 것 같네요. 다른 부분을 확인해 봐야 할 것 같아요.”
“여기에는 어떤 값이 들어 있나요?”
“어? 여기에는 이런 과정을 거치면 이 값이 들어가야 할 것 같은데요.”

와 같은 식이다. 스스로가 문제를 해결하기 위한 과정을 잘 분석해서 이를 잘 전달하는 것이 좋은 선생님이다. 전문성의 깊이와는 또 다른 이야기다.

나 홀로 전문가에 대한 미신

“소프트웨어 전문가”라고 생각하면 골방에 혼자 앉아 컴퓨터에만 몰두하는 해커의 모습이 떠오른다. 하지만 이미 소프트웨어는 혼자서 하기는 어려운 일이 되어 버렸다. 오픈소스 프로젝트가 그렇고 회사에서 진행하는 프로젝트 또한 그렇다. 따라서 실제로는 뛰어난 개발자일수록 동료와의 협력에 뛰어나다. 더 많은 노력을 협업에 기울이고, 더 쉽게 사람들로부터의 도움을 이끌어 낸다.

나 또한 소프트웨어 전문가에 대해서 동일한 미신을 가지고 있었고 이 부분을 읽고 최근 구성원들에게 팀, 협업을 강조하는 것에 대한 자신감을 얻었다. 그래요! 함께 더 잘할 수 있는 개발자가 전문가입니다.

함께

협력을 통한 추상화

책의 마지막 부분을 옮겨 본다.

자신이 작성하는 코드의 추상성을 높이고 싶다면 혼자서 고민하지 말고 다른 사람들과 협동하고, 대화하세요. 같이 그림도 그려보고 함께 소스코드를 편집하세요. {중략} 대화는 기적입니다.

Rubber duck debugging이라는 것이 있다. 오리 인형을 옆에 두고 오리 인형에게 한 줄 한 줄을 설명하다 보면 문제의 실마리를 찾을 수 있다는 이야기다. 우리 팀에서도 가끔 함께 문제를 풀어 달라고 요청할 때

저의 곰돌이가 되어주세요.

라고 말하는 경우가 있다. 하물며 무생물과의 대화를 통해서도 문제를 해결할 수 있는데 실제 이해를 시켜야만 하는 사람과 대화를 하게 되면 훨씬 자신의 생각을 가다듬어서 전달해야 한다. 이 과정을 통해서 더 좋은 설계, 더 좋은 코드가 만들어진다.

면접을 볼 때에도 논리적인 대화를 할 수 있는가를 많이 살펴보는 편이다. 논리적인 대화를 할 수 있는 사람은 프로그래밍에 대한 스킬 여부를 떠나서 다른 사람들과의 협력에서 빛을 발한다.

이것도 모르세요?

함께 일한다는 것은 어떻게 생각해 보면 서로를 이끌어 가는 과정이기 하다. 하지만 누군가를 잘 이끌어 가려면 (진짜로 변화시키려면) 동기와 의지를 북돋아 주어야 한다. 누군가 물어보았을 때 “이것도 모르세요?”라는 답을 주기 시작하면 팀은 서로 각자의 길을 가기 시작한다.

최근 전체 팀원들에 대한 피드백을 진행했다. 피드백을 전달하기 전에 팀원들의 이야기를 열심히 들어보았다. 가능하면 그들이 겪고 있는 문제를 위주로 피드백을 전달하기 위해 노력했고, 스스로의 변화를 위한 시도를 할 수 있는 방향으로 유도하기 위해 노력해 봤다. 책에서 좋은 것을 배웠다.

쾌속 학습팀

팀은 꾸준히 새로운 것을 학습해야 한다. 특히 소프트웨어 개발팀은 같은 일을 반복하지 않는다. 늘 새로운 일을 하기 때문에 늘 학습해야 한다. 팀 학습 속도에는 기술적 탁월함을 갖춘 사람보다는 학습 환경을 만들 수 있는 리더가 필요하다고 한다. 또한 학습 속도가 빠른 팀은 학습을 팀 단위의 목표로 생각해서 같이 학습한다고 한다.

실제로 팀의 역량은 슈퍼스타 한 명을 영입하는 것으로 큰 차이가 만들어지지 않는다. 각자가 꾸준히 역량을 쌓아갈 수 있는 환경을 만들 때 슈퍼팀이 만들어진다.

마지막

책을 읽어 가면서도 끄덕끄덕 동의를 하면서 읽었는데, 이렇게 독후감 형식을 빌어 책 내용을 곱씹어 보다 보니 더 좋은 책이다. 각각의 챕터에 대해서 좀 더 깊게 생각해 보고 관련된 자료들을 읽어 보면서 생각을 정리해서 글로 풀어 보고 싶다.

자라기