[책을 읽게 된 계기]
살면서 만난 교육자 중 가장 기억에 남는 분을 뽑자면 우아한테크코스 프리코스 과정에서 만나 뵌 박재성 님이다. 박재성 님의 추천으로 책의 존재를 처음 알게 되었다. 한동안 잊고 있다가, 글또 알고리즘이란 게 따로 있는걸까? 싶을 정도로 글또에서 자주 보여서 집어들어 읽기 시작했다.
개발자와 왠지 거리가 멀어보이는 단어 "함께 자라기" - 그토록 많이 회자되는 이유는 무엇일까?
핵심 메세지
"함께"와 "자라기" 처음 들었을 때 이질적인 두 단어의 조합이다.
흔히 "성장"이라고 하면 고독하게 일이나 공부에 정진하는 모습이 떠오른다. 이 책의 저자는 정통으로 반박하며, "자라기"는 "함께"와 빠질 수 없다는 메세지를 전달한다.
함께 자라기와 애자일의 관계성
단순히 애자일의 "방법론"을 다루는 책은 아니다. 그보다는 애자일의 본질을 마음에 새기도록 가르치는 책이라고 느꼈다. 구체적인 방법론을 기대하고 집어들면 실망하지 않을까 싶다. "How"보다는 "Why"를 다루는 책에 가깝다. 그리고 그 Why는 "함께 자라기"와 연결된다.
그렇다고 "How"가 빠져 있지 않다. 현재 나의 환경에서는 개인적으로 2부 "함께"보다는 1부 "자라기"에서 배우고 적용할만한 포인트가 많다고 느꼈다. 개인적으로 느낀 게 많은 1부 "자라기" 파트 위주로 정리해보고자 한다.
나는 왜 학습이 어려울까 ?
정답이 존재하던 학창시절을 지나고 느낀 혼란
사실 성인이 되고 나서의 학습은 늘 어렵다고 느꼈다. 그 어려움의 뿌리는 무엇이였을까?
학습의 본의는 야생 학습에 가깝다
그렇다, 정리하자면 모호함, 불확실함에서 오는 게 크다. 학창 시절과 달리 기준도, 범위도, 순서도 없다. 세상에 널린 정보는 많은데 뭘 언제 어떻게 주워 먹으면 될지 아무도 안 알려준다. 종종 불안감이 언습한다; '나는 잘 공부하고 있는 것인까..?' 여기서 웃긴 건 이 학습의 채점자도 나라는 사실이다.
그렇다면 내가 학습이 어렵다고 느낀 본질적인 이유, 그 괴로움의 뿌리는 아마도 학창 시절의 명확히 O/X가 떨어지던 학습 패턴을 혼란하고 무질서한 현실의 학습에 적용하기 때문일 것이다. 존재하지 않는 틀을 가져와서 구겨 넣어 보면서 '아니 이게 왜 안 먹지?' 끙끙거리는 꼴이다.
이러한 학습의 야생적인 성격은 책에서 꾸준히 언급되면서, 스스로 안고 있던 고정관념을 깨뜨리고 방향성을 재고해보는 기회가 되었다.
자라기: 어떻게 자랄까?
의도적 수련이란
Q. 1만 시간만 채우면 나는 전문가가 되는가?
A. 핵심은 자신의 기량을 향상시킬 목적으로 반복적으로 하는 수련, 즉 의도적 수련이다.
어린 시절 잘못 심어진 신화 탑 10으로 뽑는 것 중 하나는: "뭐든 열심히, 부지런히 하면 된다"이다.
아니, 열심히 말고 "잘"해야 한다.
"잘"해야 한다는 건 무엇인가?
내가 일을 하는 목적을 확실히 하고 진행해야 한다는 말이다.
책에서 말하듯 공이 어디로 가는지 보지 않고 100개, 1000개의 공을 쳐봤자 크게 달라지는 것은 없다. "정확하게 퍼팅하는 연습"에는 그다지 큰 효력을 발휘하지 않는다는 말이다.
애자일 철학이 핵심
피드백을 짧은 주기로 얻는 것, 실수를 교정할 기회가 있는 것
자기계발은 복리로 돌아온다
해당 챕터에서는 저자가 중요한 힌트들을 잔뜩 던져주셔서 적어두고 주기적으로 봐야지 싶었다.
내가 평소에 투자하는 작업의 비용은 어떤 성격일까?
A 작업 : 원래 그 조직이 하기로 되어 있는 일
B 작업 : A 작업을 개선, 제품을 만드는 사이클에서 시간과 품질을 개선
C 작업 : B 작업을 개선, 개선 사이클 자체의 시간과 품질을 개선주로 하고 있는 건 A 작업이다. 아직 2년차 주니어로서 "해야 할 과제를 명확히 이해하고 이를 잘 수행하는 것"이 가장 중요하다고 생각이 들면서도.. A 작업을 개선하면 비용적으로 줄일 수 있는 게 많아지지 않을까? 싶었다. 평소의 불편함을 감지하고 A 작업을 개선하는 방법을 생각해봐야겠다.
❓ 나의 A 작업을 개선하려면
1. 어떻게 하면 더하기보다 곱하기를 할 수 있을 것인가
2. 어떻게 해야 곱하는 비율을 높일 수 있는가 or 이자 적용 주기를 짧게 할 수 있는가
자신이 이미 갖고 있는 것들을 잘 활용하라.
외부 물질을 체화하라.
내가 집중해야 할 부분이다. 강점 TOP 5 중 하나로 "수집"이 나오는만큼 호기심으로 외부 유입을 끊임없이 수집하는 건 잘해도, 이를 내 안에서 체화해서 표현하는 게 참 어렵다는 생각이 든다.
Action Item
🤔 내가 가진 지식들은? 나는 이걸 얼마나, 어떻게 활용하고 있지?
👉 꾸준히 일지 작성 & 회고하면서 리스트업하자 !
단순 리스트업에서 그치지 말고 인사이트를 뽑아내자.
이러한 과정들을 블로그 포스팅과 포트폴리오로 남기자.
피드백을 자주 받아라.
(거를 게 하나 없어서 박제)
자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라
"결국 그는 어셈블리 언어에서도 우아한 춤을 출 수 있다"
워드 커닝햄의 일화가 인상깊다. 종종 불편한 환경을 탓하곤 했는데, 앞으로 우아한 춤까진 아니더라도, 중력을 줄여 보다 편안한 환경을 만들어나가는 노력을 해야겠다고 다짐했다.
의도적으로 수련하는 방법
자신이 업무 시간 중에 불안함이나 지루함을 느끼는 때가 대부분이라면, 실력이 도무지 늘지 않는 환경에 있다는 겁니다.
! 뜨끔
침착하고 다음 페이지를 넘겨보자
제자리걸음에서 벗어나기
✍️ 이 부분은 스스로의 상태를 돌아보는데 활용하기 위해 자세히 메모해두려고 한다.
작업 난이도와 실력이 핵심이다. 이를 지속적으로 돌아보면서 조절하는 게 중요하다는 걸 배웠다. 자기가 지금 어떤 상태인지 살피고(=알아차림) 조치를 취하는 동적인 균형을 잡는 것이 중요하다(일신우일신)
Case 1) 지루함을 느끼는 경우
a1) 실력 낮추기
- 키보드로만 개발하려고 한다던지
👉 CLI에 익숙해지기
아무래도 리눅스 환경에서 개발하다보니, 마우스와 키보드를 오가는 내가 간지가 부족하다는 생각이 문득 들었다. 올해의 소소한 목표 중 하나는 VIM 에디터에 익숙해지고 이를 활용하여 개발해보기다🔥 나도 한번 춰보자 우아한 춤 !!
a2) 난이도 높이기
- 자기에게 요구되는 수준을 더 높게 여기는 것 (ex. 하루만에 개발할 거를 한시간 안에 !)
- 안 해도 되는 업무를 자신의 의지로 추가 (리팩토링, 자동화 테스트, 자신만의 도구/방법 개발)
- 이런 것들을 만들기 위해서는 자주 일어나는 반복 패턴을 파악하고 분석해야 하며, 부족한 시간에도 짬을 내어 도구를 고안하고 작성해야 함
👉 업무상의 불편과 비효율을 분석하고, 이를 경감시킬 방안 생각해볼 것
Case 2) 불안함을 느끼는 경우
b1) 난이도 낮추기
- 자신이 맡은 일의 가장 간단하면서 핵심적인 결과물, 즉 아기 버전을 첫번째 목표로 삼는 것
👉 전에 인턴으로 처음 다뤄보는 유니티 개발할 때 이렇게 접근했던 기억이 난다. 돌아보니 난이도를 낮춰서 성공적으로 진행한 케이스다.
"GPS 기반 경로 시각화"를 위해 첫번째 스텝으로 하나의 점을 정확한 위치에 표현하기, 두번째 스텝으로 경로들을 스냅샷으로 찍어보기, 세번째 스텝으로 실시간으로 경로들을 찍는 식으로 진행했다.
b2) 실력 높이기
- 사회적 접근: 나보다 뛰어난 전문가의 도움을 얻는 것 (ex. 짝 프로그래밍)
- 도구적 접근: 다른 도구의 도움을 받는 것 (a-1와 반대)
- 내관적 접근: 비슷한 일을 했던 경험을 머릿속에서 되살려본다
프로그래밍 언어 배우기의 달인
✍️ 역시 내게 필요하고 다 적용해볼만한 내용들이라 메모해두려고 한다
튜토리얼을 읽을 때 뭘 만들지 생각하고 읽는다 (👉 도전❕)
- 적극적 읽기
- 이 정도면 그 프로그램을 작성할 수 있겠다 → 읽기를 멈추고 코딩 시작
공부할 때 표준 라이브러리 소스코드를 읽는다
- 표준 라이브러리 = 가장 그 언어다운 코드들의 말뭉치
→ 해당 언어의 결을 배우고 그걸 따른다
👉 최근 몇년 사이 상당히 여러 언어들을 경험해봤는데 확실히 언어마다 결이 다르다는 말이 와닿는다. 표준 라이브러리를 읽어볼 생각은 못했는데 이번 기회에 참고해야겠다.
공부 중 다른 사람의 코드에 내가 필요한 기능을 추가한다
전문성을 효과적으로 뽑아내는 전문가가 되기
- 전문가가 구체적인 사건에 대해 말하도록 유도
👉 회사의 최모 수석님, 황모 수석님을 집중 공략해봐야겠다!
개발자에게 사회적 자본 쌓기란?
개발자의 가장 큰 스테레오 타입은 사람과 소통하지 않고 컴퓨터와 친하다는 이미지인데, 실상은 그렇지 않다. 책에서 언급하기를 뛰어난 소프트웨어 개발자일수록 타인과 인터랙션에 더 많은 시간을 쏟는다고 한다.
대학생 때 진행한 프로젝트 대부분은 편한 대학 동기들과 한 경우가 많아서, 사회적 자본을 크게 고려하지는 않았다.
목적 조직으로 모이게 된 회사라는 집단에서는 어떻게 커뮤니케이션을 잘 할 것인가?라는 고민을 종종 하는 것 같다. 그동안에는 "효율적으로 커뮤니케이션하기"에 조금 더 치중한 거 같아서, 신뢰 자본을 잘 쌓는 데 신경 써야겠다는 생각이 들었다.
어떤 기술적 실천법이라도 그걸 현실에서 적용하기 위해서는 사회적 자본과 기술이 필요합니다
오죽 중요하면 거듭 강조하실까 싶다. 최근 일하면서 가장 느끼는 부분은 기술과 사람은 떨어지지 않는다는 점이기에, 전반적으로 공감되는 내용이였다. 백날 어떤 기술이 좋다고 외쳐도 사회적 맥락 속에서 실천되어야 한다는 점을 잊지 말자.
그 조직원들이 선생님을 좋아하나요?
ㄴ아파요.
Wrap Up
나는 어떤 개발자가 되고싶을까?
읽으면서 스스로에게 질문을 던지며 읽어볼 수 있어서 좋은 기회였다. 스스로를 돌아보는 기회가 되기도 했고.
최근 스스로에 대해 깨달은 점은 주변 사람들에게서 참 많이 배우고 자극 받는다는 사실이다. 또한, 누군갈 도와주고 기여할 때 큰 기쁨을 느낀다.
이러한 성향과 잘 맞는 이야기들이 적혀 있어서인지 읽으면서 종종 가슴이 벅차기도 하고, 그만큼 삶에 적용하고 싶어서 꼼꼼히 메모해가며 읽기도 했다.
비록 현 상황에서 적용해보기 어려운, 다소 이상적으로 보이는 부분들도 있었지만, 책에서 말하는 것들을 꼭 한번 경험해보고 싶다는 생각을 했다. 아마 5년 뒤의 내가 보면 또 다르게 느끼지 않을까 싶다. 그때의 나는 이러한 개발자에 가까워졌기를 바라며 글을 마쳐본다.
