함께 자라기 : 애자일로 가는 길

저자 : 김창준

함께 자라기 표지

들어가며

---

 성장에 관심 많은 개발자라면(이렇게 말하는 이유는 성장에 관심 없는 개발자도 많기 때문이다) 꼭 읽어볼만한 책이다. 현재까지의 자기 성장을 돌아보고 앞으로 동료들과 어떻게 더 성장할 지에 대해 도움받을 수 있기 때문이다. 보는 내내 전 직장인 이랜드에서 후배들 온보딩할 때 참 안좋은 방식으로 했다는 미안함이 들었고, 그에 맞게 나도 실력적으로건 인격적으로건 성장을 잘 못했다는 후회가 들었다. 한 가지 아쉬운 건 중간중간 논리를 뒷받침할 저자 본인의 재미있는 블로그 글이 주석으로 실렸는데, 2023년 6월 16일 이후로 egloos가 서비스를 종료함에 따라 더 볼 수 없게 된다는 점이다. 김창준님 블로그는 찾아봤는데 egloos 외에는 안나온다. 아무튼 이제 8년차에 접어든 나에게 그동안의 개발자로서의 삶을 돌아보고 미래를 설계하는데 도움을 준 고마운 책이다.

 

대충 정리해봄

---

자라기

---

학교 학습 vs. 야생 학습

학교에서의 정적인 학습과 야생(현실)에서의 동적인 학습은 다르다. 아래 표는 차이점을 정리한 것이다.

	야생	학교
상호작용	협력적	개별적
학습 순서	비순차적	순차적(대부분 공부 순서가 정해져 있다)
학습 범위	대부분 자료에 한정이 없다	대부분 교과서, 교재, 시험 범위 등이 정해짐
평가	대부분 명확한 평가가 없다	대부분 시험이라는 명확한 평가기준이 있다
정답 유무	대부분 정답이 없다	무엇이 정답이라고 하는 것이 명확하다
목표	대부분 불분명하고 바뀌기도 한다	대부분 합격, 자격증 같은 목표가 분명하다

학습의 본의는 야생학습에 더 가깝고, 현실 세계에서는 야생 학습이 더 많이 필요하다.

 

소프트웨어 개발에서 경력과 실력

 톰 드마르코(Tom DeMarco)와 티모시 리스터(Timothy Lister)가 한 유명한 연구가 있다. 1984년부터 1986년까지 92개 회사에서 600명 이상의 개발자를 대상으로 프로그래밍 생산성을 비교했다. 최고는 최악보다 열 배 정도 업무 능력이 뛰어났고, 중간 이상의 업무 능력을 가진 사람들은 그렇지 못한 나머지 절반보다 두 배쯤 뛰어났다. 재미있는 점은 경력이 10년인 개발자가 2년인 개발자보다 더 우수하지 않았다. 경력과 생산성은 아무 상관관계가 없었다는 것이다. 단, 언어를 접한 경험이 6개월 미만인 개발자들은 정반적으로 나머지 개발자들보다 성적이 저조했다.

 그들은 이 연구에서 경력과 업무 수행 능력에 깊은 상관성이 없다고 밝혔다. 최소한도의 경험치만 넘어가면 경력 연수와 실제 직무 성과의 상관성이 생각보다 낮다는 것은 소프트웨어 개발뿐만 아니라 다른 여러 영역에서도 동일하게 밝혀졌다. 반면, 개발자의 경험이 얼마나 폭넓고 다양했는지가 실제 직무성과와는 관련이 있었다. 경력의 양적인 면이 아니라 질적인 면의 중요성을 발견한 것이다.

 

개발자들이 할 수 있는 것

 1만 시간 법칙을 만든 안뒈시 에릭손(Anders K. Ericsson)은 1만 시간 법칙에 대해 이렇게 말했다.

55년 동안 걸었다고 걷는 게 점점 더 나아지고 있는 건 아니다. (중략) 자신이 즐기는 걸 한다고 해서 더 뛰어나게 될 것이라고 믿는 것은 미신이다.

 그가 말하는 1만 시간 법칙에서 1만 시간은 '자신의 기량을 향상시킬 목적으로 반복적으로 하는 수련'을 한 시간을 일컫는다. 그런 수련을 의도적 수련(deliberate practice)라고 한다. 

 연구에 따르면, 악기 연주자에게 공연 시간은 이런 의도적 수련이 되지 못한다. 체스 선수에게는 토너먼트 시간도 이런 의도적 수련이 되지 못한다. 다시 말해 그 시간들은 실력을 예측하지 못한다. 정말 기량 향상을 목적으로 자신의 약점을 개선하려고 애쓰는 수련, 그것만이 의도적 수련이다.

 업무를 하면서도 의도적 수련을 할 수 있는 방법은 애자일 철학을 활용하는 것이다. 일반적인 프로젝트에서는 모든 피드백의 주기가 느리다. 예를 들면, 내가 설계 단계에서 했던 결정의 피드백을 몇 달 후(테스트 단계)에 받는다. 그때쯤 되면 이미 내가 예전에 왜 그런 결정을 했는지조차도 가물거린다. 과거에 잘못한 실수는 한참 전에 지나가 버렸고 이제 와서 이걸 교정할 기회가 없기 마련이다. 하지만 애자일 프로젝트에서는 지금 내가 한 행동의 피드백을 10분 후, 한 시간 후, 하루 후, 일주일 후 등 여러 주기를 통해 지속적으로 얻을 수 있다. 그리고 그때 저지른 실수는 바로 다음 주기에서 교정할 수 있다.

 피드백을 짧은 주기로 얻는 것, 그리고 실수를 교정할 기회가 있는 것 이 두가지가 핵심이다.

 

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

 일반적인 조직에서는 조직은 그대로이고 결과물을 주기마다 찍어낸다. 매달 결과물을 만들어낸다고 치면, 저번 달의 조직과 이번 달의 조직은 차이가 없다는 것이다. 동일한 조직에서 동일한 제품을 반복적으로 찍어내는 공장의 비유가 딱 들어맞는다.

일반적인 조직이 일하는 구조

 아래는 복리 조직이 일하는 구조이다.

복리 조직이 일하는 구조

 조직이 첫 주기에 만들어낸 결과물을 계단 삼아서 다음 주기에는 조금 더 높은(더 똑똑한) 위치에서 다음 결과물을 만들어낸다. 내가 만든 결과물을 나의 일부로 만들어서 다음 단계에 보탬이 되도록 이용해먹는 것이다. 결과물이 다음 단계의 도구가 된다.

 

의도적 수련의 필수 조건, 적절한 난이도

 실력을 높이기 위해서는 '의도적 수련(Deliberate Practice)'이 중요하다. 의도적 수련이 되려면 나의 실력과 작업의 난이도가 비슷해야 한다. 이것은 미하이 칙센트미하이(Mihaly Csikszentmihalyi)의 몰입이론과도 일치하는 부분이다. 아래는 단순화된 도식이다.

 가로축은 해당 작업에 ㄷ재해 자신이 느끼는 자기 실력을 말하고 세로축은 해당 작업에 대해 자신이 느끼는 난이도이다.

 실력이 작업 난이도를 초과하는 A 영역의 일에서는 당장은 잘됐다 싶긴 해도 조금 지나면 지루함을 느낀다. 실력보다 높은 난이도의 일을 하는 B영역에서는 불안함이나 두려움을 느낀다. 난이도와 실력이 엇비슷하게 맞는 부분인 C 영역에서는 인간이 몰입을 경험한다고 한다. 최고 수준의 집중력을 보이고, 퍼포먼스나 학습 능력이 최대치가 될 수 있다고 한다. 또한 그때 최고 수준의 행복감을 경험한다고 한다.

 비슷한 이야기를 언어학자인 크라센(Stephen Krashen)이 입력가설(Input Hypothesis)을 통해 말한다. i+1 이론이라고 하는데, 현재 언어 학습자의 언어 수준을 i라고 할 때 딱 한 단계 높은 i+1 수준의 입력이 주어질 때에만 언어 능력이 유의미하기 진전한다는 이론이다.

 교육학에서도 비슷한 이야기를 한다. 인지 부하 이론(Cognitive Load Theory)에서는 학습 시 불필요하게 인지적인 부담을 주면 어떤 것도 제대로 학습하기 어렵다는 말을 한다. 예를 들어 미적분을 독일어로 배우면 미적분 자체보다 엉뚱한 다른 것들에 두뇌 에너지를 뺴앗겨서 학습 효율이 떨어질 수 있다는 것이다.

 

 현재 내 업무가 불만족스럽다면 몰입할 수 있도록 네 가지 전략을 취할 수 있다.

지루함을 느끼는 경우 : a1 실력 낮추기

 같은 난이도의 체력훈련을 하는데 팔과 다리에 모래주머니를 달고 운동하는 경우이다. 프로그래머의 예를 들면 평상시 즐겨 쓰던 보조 도구를 일부러 안 쓰는 것이다. 좀 더 집중해야 하고 머릿속에서 좀 더 많은 연산을 해야하고 난이도와 실력이 잘 맞아 들어가기만 하면 의도적 수련이될 수 있다.

지루함을 느끼는 경우 : a2 난이도 높이기

 하루 만에 개발하라고 주어진 업무인데 지루한 느낌이 드니 한 시간 만에 할 수 있는 방법을 고안해 보기, 100rps면 되는 시스템을 1,000rps 기준으로 만들기. 평소 코드를 검토할 때 버그를 시간당 하나 찾았다면 오늘은 두 개 찾기, 익숙한 작업을 새로운 언어로 진행해 보기 등이 있다.

 또 다른 방법으로는 공식적으로는 안 해도 되는 업무를 자신의 의지로 추가하는 경우가 있다. 보통은 자신의 업무를 개선하는 일인데, 리팩터링을 하거나 자동화 테스트를 달거나 혹은 자신만의 도구(혹은 방법)를 개발하거나 하는 것들이다.

불안함을 느끼는 경우 : b2 실력 높이기

 장기적으로 책을 보거나 스터디에 참가하는 등 방법이 있지만, 지금 당장 불안함을 느끼고 있다면 어떻게 해야 하는가가 문제이다. 크게 보면 사회적 접근과 도구적 접근, 내관적 접근이 있다.

 사회적 접근은 나보다 뛰어난 전문가의 도움을 얻는 것이다. 잘하는 사람한테 가서 짝 프로그래밍을 해달라고 부탁하는 방식이다.

 도구적 접근은 다른 도구의 도움을 받는 것이다. a1에서 도구 접근을 제약하는 겅우의 반대로 볼 수 있다. 내 능력을 확장시켜 줄 수 있는 도구들을 찾아 쓰면 된다. 예컨대 괜찮은 디버거, 자동 통합 도구, 코드 분석툴, REPL 환경 등을 사용하거나 오픈소스 라이브러리를 빌려 쓰는 것이다.

 내관적 접근은 비슷한 일을 했던 경험을 머릿속에서 되살려 보는 것이다. 그때 그 일을 어떻게 했는지 떠올려 보면서 비유적으로 문제를 해결한다. 보통 이런 과정을 거치면 자기효용감(self-efficacy)이 증대하면서 스스로 인식하는 자기 실력이 향상되기 쉽고, 결과적으로 몰입 영역으로 들어가기 좋다.

불안함을 느끼는 경우 : b1 난이도 낮추기

 간단하면서 효과적인 방법은 자신이 맡은 일의 가장 간단하면서 핵심적인 결과물, 즉 아기 버전(혹은 0.0.1 버전)을 첫 번째 목표로 삼는 것이다. 한 연구에서는 피실험자를 A그룹과 B그룹으로 나누어 A그룹은 어려운 코딩 문제를 먼저 풀게 한 다음 쉬운 문제를 풀게 했고, B그룹은 그 반대로 풀게했다. 결과는 B그룹이 A그룹보다 절반 이하의 결함을 만들어 냈다. 난이도를 낮춘 결과 합습 효과, 동기 강화, 스트레스 감소, 자기 효능감 증가 등의 긍정적인 효과가 생겨 이득을 얻은 것으로 볼수 있다.

 

프로그래밍 실력 높이기 1 : 적극적 읽기

 저자가 경험해본 프로그래밍 언어를 빨리 습득하는 개발자 한명의 태도를 예시로 들었는데 개인적으로 많이 와닿았다. 튜토리얼을 읽을 때 다음 작성할 프로그램을 염두해 둔다는 것이다. 튜토리얼을 읽다가도 이 정도면 그 프로거램을 작성할 수 있겠다는 생각이 들면 읽기를 멈추고 코딩을 시작한다. 프로그램을 완성하면 잠시 멈췄던 자리로 돌아와서 읽기를 계속한다. 이때도 역시 다음 프로그램을 목표로 두면서 말이다. 

 이런 것을 적극적 읽기라고 한다. 무언가를 읽을 때 구체적인 질문이나 목적을 가지고 있는 방법이다. 나도 역시 적극적 읽기를 할 때 더 재미있고 학습한 내용이 장기기억으로 잘 전환되는 것 같다. 주로 회사에서 어떤 큰 프로젝트나 문제 해결을 하기 전 준비단계에서 참고서적을 읽을 때이다. 이렇게 읽은 책들로는 '마이크로서비스 패턴', 'Spring Batch Definitive Guide', '도메인 주도 개발 시작하기' 등이 있다. 실무에 적용하기로 작정하고 읽은 책들은 학습효과가 좋다.

프로그래밍 실력 높이기 2 : 표준 라이브러리 소스코드 읽기

 표준 라이브러리는 보통 해당 언어 발명자가 직접 작성하거나 적어도 해당 언어의 스타일을 따르는 소수의 사람들이 작성한다. 가장 그 언어다운 코드들의 말뭉치이다. 이런 실제 사례들을 통해 해당 언어의 문화와 스타일을 익히는 것이 중요하다. Java라는 언어로 작성했지만 C 언어로 작성한 코드와 별반 차이가 없는 코드도 나올 수 있다. Java로 작성된 프로그램이냐 C로 작성된 프로그램이냐를 가르는 진짜 기준은 어떤 언어의 키워드를 썼느냐가 아니라 어떤 스타일을 따르고 어떤 숙어를 사용했는가이다. 이것이 프로그램 기능의 차이를 가져오지는 않을지 몰라도, 프로그램 작성 비용과 더 나아가 수정(유지보수) 비용을 좌우하게 된다. 그래서 해당 언어의 결을 배우고 그걸 따르는 것이 중요하다.

 

두 가지의 실수 문화

실수 문화별 개입 시점

 마이클 프레제(Michel Frese)는 회사에서의 실수 문화에 대해 연구를 했다. 그에 따르면 실수 문화에는 크게 실수 예방과 실수 관리 두 가지가 있다. 실수 예방은 행동에서 실수로 가는 경로를 차단하려고 한다. 즉, 실수를 저지르지 말라고 요구한다. 근데, 전문가도 1시간에 평균 3~5개의 실수를 저지른다고 하니 불가능에 가깝다.

 다만, 전문가들은 실수를 조기에 발견하고 빠른 조치를 취할 수 있다. 이렇게 "실수는 어떻게든 할 수밖에 없다. 대신 그 실수(예컨대 코딩하다가 ==대신 =를 쳤다든지)가 나쁜 결과(서버가 도미노 현상을 내며 죽든다든가, 그걸로 수술 기계가 오동작을 해서 사람이 다치거나)로 되기 전에 일찍 발견하고 빨리 고치면 된다"는 것이다. 이 태도를 실수 관리라고 한다. 이미 결과가 난 실수에 대해서는 학습을 통해 '다음 행동할 때 이렇게 하자'는 계획을 세우기도 한다.

 실수 예방 문화에서는 실수를 한 사람을 비난하고, 처벌하고, 따라서 실수를 감추고 그에 대해 논의하기 꺼리며 문제가 생겼을 때 협력도 덜하게 된다. 실수에서 배우지 못한다. 반대로 실수 관리 문화에서는 실수가 나쁜 결과를 내기 전에 빨리 회복을하도록 돕고, 실수를 공개하고, 실수에 대해 서로 이야기하고 거기에서 배우는 분위기가 생긴다.

 이 부분이 굉장히 중요한데, 실수 연구의 역사를 보면 초기에는 기술적인 부분만 보다가 그 다음에는 인간적인 부분(결국 80%가 사람 실수라든지)을 보다가(특히 1979년 쓰리마일섬의 사고가 계기가 되었음), 이제는 문화적인 부분(컬럼비아호 사고가 계기가 되었음)을 이야기한다. 심리적 안전감이라고 하는 것이 이 문화의 일부이다.

 이런 실수 관리 문화가 회사에 정말 도움이 되는지에 대한 연구도 있다. 회사 문화가 실수 예방보다 관리에 가까울수록 그 기업의 혁신 정도가 더 높다. 그리고 실수 관리 문화일수록 회사의 수익성이 더 높다. 이런 현상이 나타나는 이유는 실수가 없으면 학습하지 못하기 때문이다(고로 직원들에게 실수하지 말라고 하는 조직은 학습하지 말라고 지시하는 것과 같다). 이는 학습이론의 기본이다. 즉, 실수 관리를 하는 문화일수록 학습을 더 잘한다.

 

고독한 전문가라는 미신

 전문가가 해당 도메인 지식만 뛰어난 사람이라는 것은 대표적인 미신이고, 전문가는 사회적 자본과 사회적 기술 또한 뛰어나다.

 벨 연구소는 수십 년에 걸쳐 '뛰어난 연구자'의 특성에 대해 연구한 결과 뛰어난 연구자와 그렇지 않은 연구자를 가르는 결정적인 요인 중 하나는 사회적 자본, 특히 소셜 네트워크의 차이였음을 밝혀냈다.

 최근에 소프트웨어 공학에서 이뤄진 여구의 결과도 비슷한데, 뛰어난 소프트웨어 개발자일수록 타인과 인터랙션에 더 많은 시간을 쓰며, 초보 개발자들에게 조언을 할 때 사회적인 측면(예컨대 "모르면 주변에 물어봐라", "남을 도와줘라" 등)이 포함된다. 기술적인 조언만 하는게 아니라는 뜻이다.

 한 연구에서는 경력이 있는 개발자들에게 특정 문제를 해결할 때 초보 개발자에게 해 줄 조언을 적어보라고 했다. 평균 7년 경력의 개발자들이었는데 뛰어난 개발자들은 약 70%가 동료와의 협력을 언급하는 반면, 실력이 그저 그런 개발자들은 20%도 안 되는 사람들만이 동료와의 협력을 언급했다.

 사회적 자본과 기술이 그렇게 중요한데 왜 개발자를 포함한 다른이들이 학교에서 그걸 배우지 못했을까? 전문가에 대한 잘못된 모형 때문이다. 전문가를 혼자서 일하는 고독한 천재 같은 걸로 오해하는 것이다. 기존 전문성 연구들은 통상 연구비를 낮추고 변수를 줄이기 위해서도 개인을 골방에 넣고 그의 독자적 행동과 선택을 연구했다. 이런 연구에서 나온 전문가, 비전문가의 차이로 전문가 이미지가 형성되었고, 교육 과정도 거기에 기반해 짜여진 것이 아직도 많기 때문이다.

 

감정을 배제할 수 없다

 남을 설득하려면 논리성과 객관성에 대한 환상을 버려야 한다. 그래야 현실적으로 설득이 가능하다. 내가 설득하고 싶은 상댈글 자주 만나서 신뢰를 쌓고, 그 사람이 무엇을 중요하게 여기는지, 어떤 설명 방식을 선호하는지 이해해야 한다. 출발은 결국 내가 설득하려는 사람에게서 하는 것이다. 자료에서 출발하는 것이 아니다.

 이런 이유로 상사가 애자일을 받아들이게 하기 위해, 상사와는 별로 대화도 안 하면서 사례를 찾거나 근거 자료를 수집하려고 측정에 시간을 쏟는 이들에게 저자는 이렇게 조언한다. "상대방에 대해 얼마나 이해를 하고 계신가요? 얼마나 대화를 해보셨나요?