자라기

자라기 파트를 읽고 정리한 글입니다.

김창준님의 <함께 자라기-애자일로 가는 길> 이라는 책을 읽게 된 이유와 새로 알게된 점에 대해 책 내용의 일부를 정리한 글입니다.

책을 읽게 된 이유?

주니어 개발자로 일하면서 생겼던 궁금증이면서 고민이 되었던 질문이 있습니다.

주니어 개발자로 일하면서 생겼던 고민

실력있는 개발자란 무엇일까?
개발자로서 빠르게 성장하기 위해선 무엇이 중요할까?
협업하는 과정에서 개발자가 가져야할 태도는 무엇일까?

이러한 고민들을 해결하기 위해 도움이 될만한 책이 없을까 찾다가 김창준님의 <함께 자라기-애자일로 가는 길> 이라는 책을 알게 됐고 개인적으로 많은 도움이 됐습니다. 저와 같은 고민을 가진 개발자가 계시다면 이 책을 추천 드리고 싶습니다. 그리고 개발자뿐 아니라 어느 업종에 종사하든 더 성장하고 싶은 분들에게도 분명 큰 도움이 될 것 같습니다.

자라기

: 당신은 몇년 차?

경력 연차는 실력과 무관하며 실력은 폭넓은 경험이 중요하다.

미국 연방 정부의 채용 선발 테스트와 직무 성과의 상관성 연구 결과, 경력 연차와 직무 성과는 상관성이 낮았습니다. 관심사를 기준으로 보고 채용하는 것과 직무 성과가 다르지 않은 수준이며 학력 또한 마찬가지였습니다.
상관성이 높은 선발 기준은 작업 샘플 테스트(과제 전형), 아이큐와 같은 지능 테스트, 구조화된 인터뷰가 있습니다.
경력 연차가 완전히 의미가 없는 것은 아닙니다. 대학교를 갓 졸업한 사람과 2년 차 프로그래머 중에서는 후자의 실력이 높을 확률이 큽니다. 하지만 5년 차와 10년 차의 연차 차이는 큰 의미가 없습니다.
600명 이상의 개발자를 대상으로 프로그래밍 생산성을 비교 분석한 결과, 최고는 최악보다 열 배 정도의 업무 능력의 차이가 있었습니다. 그리고 경력 연차는 생산성과 무관했습니다.
개발자의 경험이 얼마나 폭넓고 다양했는지가 실제 직무성과와 관련이 있었습니다. 경력의 양적인 면이 아니라 질적인 면의 중요성을 발견한 것입니다.

업무 능력 향상을 위한 수련 방법

보험 설계사가 업무 중에 자신의 능력을 향상시키기 위해 시간을 얼마나 쓰는가와 직무 성과를 비교한 연구가 있습니다. 이 연구에서는 최근 일주일 동안 업무 능력 향상을 위해 얼마나 시간을 쓰는지 물었는데, 이 시간의 양과 직무 성과 간에 통계적으로 유의미한 상관성이 있었습니다.
그들이 자주하는 수련으로는 '머릿속에서 시뮬레이션하기', '피드백 요청하기' 등이 있었습니다. 달리 말하면 내가 요즘에 얼마나 공부하고 수련하느냐로 내 직무 성과가 결정된다는 이야기가 됩니다.

회사 상사분께서도 자주 얘기했던 부분이라 출퇴근 길에 그 날의 업무나 이슈 사항들을 해결하기 위해 머릿 속으로 시뮬레이션을 해보고 있습니다. 하지만 피드백 요청하기는 아직 많이 어렵습니다.

1만 시간 법칙

1만 시간 법칙을 만든 주인공, 안데쉬 에릭손은 이에 대해 다음과 같이 딱 잘라 말합니다. '55년 동안 걸었다고 걷는 게 점점 더 나아지고 있는 건 아닙니다. (중략) 자신이 즐기는 걸 한다고 해서 더 뛰어나게 될 것이라고 믿는 것은 미신입니다.'
그가 말하는 1만 시간 법칙에서 1만 시간은 '자신의 기량을 향상시킬 목적으로 반복적으로 하는 수련'을 한 시간을 일컫습니다. 그런 수련을 의도적 수련이라고 합니다.
연구에 따르면, 악기 연주자에게 공연 시간은 이런 의도적 수련이 되지 못합니다. 정말 기량 향상을 목적으로 자신의 약점을 개선하려고 애쓰는 수련, 그것만이 의도적 수련입니다.

저는 여기에서 제가 얼마만큼의 의도적 수련이라는 것을 하고 있는지 되돌아 보게 됐습니다.

업무를 하면서도 의도적 수련하기

애자일 프로젝트에서는 지금 내가 한 행동의 피드백을 10분 후, 한 시간 후, 하루 후, 일주일 후 등 여러 주기를 통해 지속적으로 얻을 수 있습니다. 그리고 그때 저지른 실수는 바로 다음 주기에서 교정할 수 있습니다.
피드백을 짧은 주기로 얻는 것, 그리고 실수를 교정할 기회가 있는 것, 이 두 가지가 학습에 큰 차이를 불러일으킵니다.

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

직장인들의 자기계발 시간 통계에서 1~2시간이 압도적으로 많습니다. 이 자료를 보고 "우와 사람들이 의외로 자기계발을 많이 하네"라는 느낌이 든다면 반성해야 합니다. 하루 평균 1시간도 투자하지 않는 사람은 자기계발이란 면에서 직장인의 하위 1/3에 속하는 셈입니다.
저는 여기서 많은 반성을 했습니다.
일례로, 전설적 프로그래머 워드 커닝햄(최초의 위키 사이트를 만들었다.)은 자기의 수족을 마음대로 놀릴 수 없는 불편한 언어에서 프로그래밍을 하면서 점차적으로 자신을 도와주는 환경을 만들어 나갑니다. 나의 속도를 늦추는 것들을 중력에 비유한다면, 워드는 중력을 점점 줄여나간다고 할 수 있습니다. 결국 그는 어셈블리 언어에서도 우아한 춤을 출 수 있게 됩니다.
너무 멋있다고 느꼈습니다. 저도 어셈블리 언어에서 탭댄스를 출 수 있는 개발자가 되고 싶단 생각을 했습니다.
완벽한 도구와 환경을 갖추는 데에 집착해선 안 됩니다. **"방이 조용해지고 배도 안 고프고 온도도 적절해지기만 하면 공부 시작해야지"**라고 생각하는 사람들 중에 1등은 없습니다. 또한 실제로 그런 환경이 되어도 몸에 배어든 습관 때문에 결국은 공부하지 못할 것입니다.

최근에 읽은 책 중 <습관의 재발견> 이라는 책이 있습니다. 위에서 말한 "방이 조용해지고 배도 안 고프고 온도도 적절해지면 공부해야지" 라는 생각에 시작이 어려운 분이 계시다면 한번쯤 읽어볼 것을 추천드립니다. <함께 자라기>에서도 언급되는 내용인데요. <습관의 재발견> 에서 핵심적으로 말하는 것 중 하나는 작게 시작하라는 것입니다. 여기서 작게는 스스로도 한심하게 느껴질 정도로 작게를 의미합니다. 운동을 예로 들자면 '매일 하루 잠들기 전에 팔굽혀펴기 1개 하기' 와 같은 것들이 있습니다. 별 것 아닌 것처럼 느껴질 수도 있지만 실제로 별 것 아니기에 한번쯤 해보셨으면 좋겠습니다. 저도 매일 하루 팔굽혀펴기 1개 하기를 통해 현재는 꾸준히 운동하는 습관을 갖게 되었습니다.

: 가장 학습하기 힘든 직업이 살아남는다.

혼자서 딱 정해진 일만 할 수 있는 환경은 축복이 아니라 저주가 될 수 있겠지요. 결론적으로, 미래에는 암묵지와 직관을 잘 학습하는 사람들이 높은 경쟁력을 가질 것입니다.
혼자서 딱 정해진 일만 할 수 있는 환경을 좋은 환경이라고 생각을 했는데 달리 생각하게 됐고, 암묵지와 직관을 학습하는 것이 중요하다는 것을 알게 됐습니다.
한발 더 나아가, 알파고랑 경쟁하기보다는 협력하는 방법을 배우는 것을 추가할 수 있을 겁니다. 즉, 알파고를 사용하는 데에 필요한 암묵지와 직관, 독창성, 그리고 다른 사람과 협력을 잘하는 것이 알파고를 얼마나 잘 쓰냐를 결정하는 핵심이 될 것입니다.
따라서 직관, 독창성, 협업 능력을 학습하는 것이 개발자에게 앞으로 더욱 중요해질 것 같습니다.

: 당신이 제자리 걸음인 이유

의도적 수련의 필수 요건 중 하나가 '적절한 난이도' 입니다.

'적절한 난이도'에 대해 이야기하면서 미하이 칙센트미하이의 몰입이론이 나옵니다. 적절한 난이도가 몰입의 경험을 불러 일으키고 인간은 몰입의 상태에서 최고의 퍼포먼스를 보여준다는 이론입니다. 미하이 칙센트미하이의 책 <몰입> 도 있으니 읽어보신다면 작은 도움이 될 것 같습니다.

자신이 업무 시간 중에 불안함이나 지루함을 느끼는 때가 대부분이라면, 실력이 도무지 늘지 않는 환경에 있는 겁니다. 더 무서운 건 점차 이런 환경에 익숙해지고 행동이 습관화된다는 점이죠. 그때는 자기 인식도 잘 되지 않습니다.
불안함이나 지루함을 느끼는 때가 자주 있는데 그 환경에 익숙해지고 행동이 습관화된다는 것이 무섭게 느껴졌습니다.

제자리 걸음에서 벗어나기

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

프로그래머의 예를 들자면, 평상 시 즐겨 쓰던 보조 도구를 일부러 안쓰는 겁니다.

저는 앞으로 키보드만으로 프로그래밍을 할 수 있도록 노력하고 있습니다. 나중엔 VIM 만으로도 개발해보고 싶다는 생각이 들더라구요.

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

예컨대, 이웃팀이 임베디드 장비의 데드락 문제로 고생을 하길래 도와줬다는 분이 있었습니다. (중략) 해당 C 파일들에 자동으로 특정 로그를 삽입해서, 스레드나 프로세스가 어떻게 동작하는지 쉽게 분석하게 해주는 도구를 직접 만들어 쓰고 계시더라구요. 그분은 그런 도구가 수십 개가 넘는다고 했습니다.

그런 도구가 수십 개가 있는 개발자는 얼마나 경쟁력이 있을까? 란 생각을 해봤습니다.

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

잘하는 사람한테 가서 짝 프로그래밍을 해달라고 부탁하거나 인터넷 상에서 전문가의 도움을 얻는 것도 괜찮은 방법이고요. (중략) 괜찮은 도구를 사용하는 것도 좋은 방법입니다.

저도 최근에 많이 느낀 부분입니다. 꼭 잘하는 사람이 아니더라도 누구에게나 배울 점이 있고 없더라도 서로 알려주고 질문하면서 스스로에게 배우게 되는 것 같습니다.

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

간단하면서 효과적인 방법은, 자신이 맡은 일의 가장 간단하면서 핵심적인 결과물, 즉 아기 버전을 첫 번째 목표로 삼는 겁니다. 애자일에서 말하는 WTSTTCPW와 같습니다. (What's The Simplest Thing That Could Possibly Work? : 작업을 시작할 때 "동작할 수도 있는 가장 간단한건 뭘까?"하고 서로 묻는 걸 말합니다.) P 님은 특이한 전략을 취해서 학기 내내 거의 1등을 놓치지 않았다고 합니다. 기본적으로 과제는 C 언어로 작성해야 했는데, P 님은 파이썬으로 한 번, 그리고 그걸 C 언어로 한 번 해서 총 두 개의 프로그램을 만들었습니다.

그래서 저도 저에게 익숙한 로직으로 먼저 구현을 하고 고도화하는 식으로 프로젝트를 진행하고 있는데 시간도 줄일 수 있고 로직에 대한 이해가 더 높아지는 것 같습니다.

동적인 균형

그런데 유념해야 할 점이 있습니다. 자신의 실력이나 작업의 난이도가 계속 조금씩 요동을 치고 있다는 점입니다. (중략) 그런 면에서 자기가 지금 어떤 상태인지 살피는 '알아차림(mindfulness)'이 꼭 필요합니다. 메타인지 전략이라고도 하는데, 공부를 잘하는 사람들의 중요한 특징 중 하나로 꼽습니다.

: 프로그래밍 언어 배우기의 달인

튜토리얼을 읽을 때 뭘 만들지 생각하고 읽는다.

튜토리얼을 읽는 것 자체는 다른 프로그래머랑 비슷해 보입니다. 여기에 차이가 있다면 읽을 때 다음 작성할 프로그램을 염두에 둔다는 점입니다. 그래서 튜토리얼을 읽다가도 이 정도면 그 프로그램을 작성할 수 있겠다는 생각이 들면 그 자리에서 읽기를 멈추고 코딩을 시작합니다.

공부할 때 표준 라이브러리 소스코드를 읽는다.

S 님은 튜토리얼을 읽어 나가면서 틈틈이 해당 언어의 표준 라이브러리를 찾아 읽었습니다. 표준 라이브러리는 보통 해당 언어 발명자가 직접 작성하거나 적어도 해당 언어의 스타일을 따르는 소수의 사람들이 작성합니다. 이런 실제 사례들을 통해 해당 언어의 문화와 스타일을 익히는 것이 중요합니다.
이것이 프로그램 기능의 차이를 가져오지는 않을지 몰라도, 프로그램 작성 비용과 더 나아가 수정 비용을 좌우하게 됩니다.

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

실수 예방은 행동에서 실수로 가는 경로를 차단하려고 합니다. 즉, 실수를 저지르지 말라고 요구합니다. 근데, 사실 이것이 불가능에 가깝습니다. 전문가도 1시간에 평균 3~5개의 실수를 저지른다고 합니다.
"실수는 어떻게든 할 수 밖에 없다. 대신 그 실수가 나쁜 결과로 되기 전에 일찍 발견하고 빨리 고치면 된다" 이 태도를 실수 관리라고 합니다.
실수 관리 문화에서는 실수를 공개하고, 실수에 대해 서로 이야기하고 거기에서 배우는 분위기가 생깁니다. 실수 관리 문화일수록 회사의 수익성이 더 높습니다. 이유는 간단합니다. 실수가 없으면 학습하지 못합니다. 이는 학습이론의 기본입니다.

저는 결과를 결정짓는 건 과정보다도 결과를 낸 이후의 선택들이라고 생각합니다. 결과에 대해 어떻게 대처할 것인지 고민하고 선택하는 과정과 그 태도가 결과를 결정짓는다고 생각합니다.

: 나홀로 전문가에 대한 미신

어떤 기술적 실천법이라도 그걸 현실에서 적용하기 위해서는 사회적 자본과 기술이 필요합니다.

고독한 전문가라는 미신

전문가가 해당 도메인 지식만 뛰어난 사람이라는 것은 대표적인 미신입니다. 전문가는 사회적 자본과 사회적 기술 또한 뛰어납니다.
뛰어난 소프트웨어 개발자일수록 타인과의 인터랙션에 더 많은 시간을 쓰며, 초보 개발자들에게 조언을 할 때 사회적인 측면(예컨대 "모르면 주변에 물어봐라", "남을 도와줘라"등)이 포함됩니다.
초보 개발자에게 해줄 조언에 대해 뛰어난 개발자들은 약 70%가 동료와의 협력을 언급하는 반면, 실력이 그저 그런 개발자들은 20%도 안 되는 사람들만이 동료와의 협력을 언급했습니다.
사회적 기술을 훈련시킬 수 있는 간단한 방법으로 주변 사람들과 매일 주고받는 마이크로 인터랙션에 신경을 쓰는 겁니다. 그걸 기록하고, 복기하고, 다르게 인터랙션한다고 하면 어떻게 했으면 좋았을까를 생각해 보는 것만으로도 훈련이 될 수 있습니다.

여기까지가 책 <함께 자라기-애자일로 가는 길> 에서 자라기 파트였습니다. 개인적으로 새로웠고 도움이 됐던 내용만 정리해봤습니다. 이후에는 함께 파트가 시작되는데 흥미롭고 앞서 자라기 파트와 마찬가지로 큰 도움이 되는 내용이 많이 있었습니다. 이후 마지막 파트로 애자일에 대한 저자의 생각과 애자일을 어떻게 그리고 무엇을 도입해야 하는지 말해줍니다.

어제보다 더 잘하고 싶고 더 나아지고 싶은 분이라면, 불확실함이 가득한 세상 속에서 좋은 개발자로 성장하고 싶은 분이라면 꼭 한번 읽어봤으면 좋겠습니다. 긴 글 읽어주셔서 감사합니다.

Previous함께 자라기 Next99클럽

Last updated 10 months ago