[독서 감상] "함께 자라기" - 자라기 편

서론

동아리 선배가 강력 추천해주셔서 언젠간 읽어야지~ 하고 있다가, 도서관에 들른 김에 빌려서 지하철에서 틈틈이 읽었던 책. 읽은 기억이 날아가기 전에, 책의 간단한 내용들과 읽으며 느낀 점을 기록하고자 한다.

개요

이 책은 개발자(그리고 모든 팀들)에게 있어, 함께 자라기가 얼마나 중요한 것인가, 애자일이란 무엇인가를 설파하는 책이다.

 

책은 크게 함께, 자라기, 애자일 3개의 단원으로 이뤄져 있으며, 각각의 중요성을 여러 가지 사례와 함께 일깨워준다.

책 전체의 감상문을 쓰기엔 글이 너무 길어지므로, 여기선 1단원(자라기)과 2, 3단원(함께, 애자일)로 나눠 포스트를 작성하겠다.

---

자라기

이 책의 첫 장은 자라기로 시작한다. 개인이 성장하는 방법에 대해 몇 가지 방법을 소개해주는데, 확실히 도움이 된다고 느꼈다.

주요 내용들을 짧막하게 소개해보면

• 학습하는 방법을 배워야 제대로 학습할 수 있다.
• 적절한 난이도의 수련만이 성장할 수 있다.
• 목표 없는 수련으론 성장할 수 없다.
• 전문가가 되려면, 전문가를 관찰하라.
• 실수는 예방하는 것이 아닌, 관리하는 것이다.
• 협력을 못하는 전문가는 전문가가 아니다.

정도로 요약이 가능할 듯하다. 책의 단원과 무관하게, 내가 해석한 문장들로 적었다.

 

학습하는 방법을 아는 것이 학습보다 중요하다.

이 부분은 읽으며 크게 공감한 부분이었다. 나는 어릴 적부터 영재로 불렸는데, 그에 걸맞게 관찰력, 이해력, 직관력이 매우 뛰어났다. 중학교까진 교과서만 보고도 내용을 완벽히 이해했고, 응용하여 문제를 푸는 것도 막힘없었다. 비록 중학교 2학년, 교과 공부에 회의감이 들어 대학에 오기까지 손에서 놓다시피 했지만, 그 열정을 프로그래밍에 쏟았으니 결과적으론 더 좋은 성취를 이뤄냈다.

 

줄이자면, 나는 공부하는 방법을 알고 있었다. 특정 지식을 학습할 때, 단순히 받아들이는 대신 온갖 질문으로 반박해본다. 유사한 다른 개념과 연결되진 않는지, 어떤 부분이 뛰어나서 채택되었는지, 만들어진 목적은 무엇인지, 실제로 그렇게 동작하는지 시뮬레이션까지, 끊임없이 머릿속으로 되뇌인다. 지식을 습득하는 동시에 다른 분야까지 확장해나가며, 남들보다 빠른 시간에 개념을 본질적으로 이해하고, 간단한 응용까지 할 수 있다.

누군가는 어떻게 강의 시간에만 듣고 이해가 다 되냐 하던데, 교수님이 같은 개념에 대해 다른 방법으로, 오래 설명하는 동안 저런 걸 하고 있다.

 

예를 들어, 자료 구조에서 이진 트리에 대해 배운다고 생각해보자. 그럼 가장 먼저 떠올리는 건 비슷한 구조를 본 적 있는가다. 분할 정복법과 유사한 부분이 보이며, 일상생활에선 업다운 게임과도 비슷하다. (1부터 100까지의 수 중 임의의 수를 맞출 때, 반씩 나눠 나가는 게 가장 유리하다는 게임) 그중 업다운 게임은 이미 잘 알고 있는 개념이니 이와 이진 트리를 결부시키고, 이 방식이 다른 구조에 비해 얼마나 뛰어날지 상상해보고 (배열에 비해, 탐색 시 O(N)과 O(log N)의 차이니 매우 빠를 것), 아직 모르는 부분을 상상해보고(배열엔 삽입/삭제도 있는데, 배우지 않고 트리에서 삽입/삭제를 시도해본다던지), 어떤 경우에 응용 가능할지. 이런 것들을 이진 트리의 개념만 봤을 때 해낸다.

 

나는 이런 식으로 내게 맞는 공부법을 갖고 있고, 그에 따라 대학에서도 보통 기존에 이해한 내용을 하루 전에 복습하는 정도로 A+을 따내고 있다. 물론 단점도 있는데, 직관과 유추, 이해에 기반한 만큼 단어를 정확히 암기하거나, 수학 문제처럼 어려운 응용이 필요한 경우에 약하다. 다만 내가 학점에 크게 연연하는 편도 아니고, 목표는 충분히 이루기에 이 방법을 고수하고 있다.

 

만약 내가 공부법을 갖고 있지 않았다면 어떨까? 처음 보는 지식을 습득할 때 어떻게 해야할 지 몰라 당황하고, 냅다 남들이 하는대로 따라해보고, 그들보다 많은 시간을 쓰면서도 성과는 낮게 나왔을 것이다. 또한 학습법이란 건 게임의 경험치 획득량과도 같아서, 재화를 투자해 올려두면 남들보다 빠른 시간에 레벨업할 수 있게 된다. 만약 당신이 RPG 게임을 한다고 해보자. 모든 경험치 도핑을 하고 사냥하는 자와 스킬도 찍지 않고 평타로만 사냥하는 사람, 둘 중에 누가 더 빨리 레벨이 오르겠는가? 그런 상황에서도 단순히 후자가 많이 노력했으니 뛰어난 사람이라 할 수 있는가?

 

이 책의 화자는 자기계발은 복리로 돌아온다. 라고 한다. 그처럼 학습보다 중요한 건, 학습 방법을 얼마나 갈고 닦았냐인 것이다.

 

적절한 난이도의 수련만이 성장할 수 있다.

필자는 또한, 학습엔 난이도가 중요하다고 말한다. 게임으로 치면 100레벨이 270레벨 몹을 잡으러 가거나, 1레벨짜리 몹만 주구장창 잡아대는 걸로 비유할 수 있다. 전자의 경우 언젠가 잡을 순 있겠지만 힘들고 비효율적이며, 후자의 경우 쉽지만 지루하고 성과는 없는 상태가 된다. 게임을 안 하는 사람도 있을 테니, 이 비유는 여기서 멈추겠다.

 

아무튼, 중요한 건 실력에 맞는 과제가 주어져야 한다는 것이다. 이쯤에서 난 우리 동아리가 생각났다. WAP은 프로젝트 동아리로, 신입과 선배들 모두 한 학기동안 하나의 프로젝트를 완성하는 걸 목표로 한다. 이쯤에서 신입생들에게 많이 나오는 불만이, 너무 어렵다는 것이다.

 

코딩 경력이 없음에도 갖은 노력 끝에 프로젝트를 성공해내는 인원이 있는가하면, 한 학기 내내 선배들이 시킨 일만 하다가, 혹은 마무리 짓지 못하고 끝나는 경우도 많았다. 맨땅에 헤딩하며 배우는 게 많다지만, 그게 과연 적절한 난이도일지는 고려해봐야 할 것이다.

 

컴퓨터에 영어를 써내려가는 것도 벅찬데, 거기에 MVC 구조를 적용하거나, 코드 리뷰를 시키거나, 컨벤션을 완벽히 지키거나, 객체지향적 코드를 짜라는 것 자체가 부담이다. 내가 아무리 좋은 인사이트를 얻었어도, 상대가 받아들일 실력이 되지 않으면 무용지물이다. 그러니 정보를 공유할 때 상대의 실력을 고려하고, 혹 그 사람이 이 좋은 걸 해내지 못했어도 실망하지 말아야 한다. 당연한 거니까.

 

목표 없는 수련으론 성장할 수 없다.

학습에 있어 가장 중요한 것은, 무엇을 배워야하는지 명확히 아는 것이다. 더 나아가 목표를 위해 어떤 연습 방법을 채택할지까지 정한 후에나 수련이 의미가 있다.

 

예를 들어, 우린 오랜 시간 양치질을 해왔으나 양치질의 마스터가 되진 않았다. 이는 무엇을 배워야하는지 모른 채 매일같이 해왔기 때문이다. 우린 솔질을 어디부터 어디까지 해야 하는지, 치아 사이는 어떻게 닦아야 잘 닦이는지, 어떻게 회전시켜야 이물질이 잘 제거되는지 등을 알아보며 양치질을 하지 않았다. 그렇기에 몇십 년을 해도 전문가라 부를 수 없기 때문이다.

 

책의 화자는 이러한 예를 들며, 무언가의 전문가가 되기 위해선 목표를 설정하고, 그를 위해 필요한 지식(연습법)을 학습한 후에 수련해야 한다고 한다. 어느 정도 경지에 올라가면, 스스로 제약을 걸어 난이도를 높이는 방법 또한 소개한다. 그러나 이미 전제로 깔려 있기에 간과할 수 있는 것이, 이 일이 내가 전문가가 되어야하는 일인가?하는 것이다.

 

화자는 전문가가 되려는 자에게 설파했으니, 이는 기본 전제로 깔려 있다. 그러나 일반 독자라면 여기서 문제가 발생할 수 있다. 이 책을 읽은 고3이 양치질 마스터가 되는 것은 의미있는 것인가?

 

위에서, 나는 내 공부법이 한계가 뚜렷하다 하였다. 가장 취약한 부분은 빠른 시간 내에 정해진 문제를 푸는 것이다. 예를 들면 수능 수학, 코딩 테스트 등이 여기에 속할 것이다.

 

얼핏 보면 수련을 게을리해서 못하는 것으로 보이지만, 사실 난 반쯤 의도적으로 수련을 회피하고 있다. 그 이유는, 코딩 테스트의 목적은 좋은 개발자가 되는 것이 아니기 때문이다.

 

변명처럼 들릴 수 있겠지만, 이는 꽤 중요한 문제다. 코딩 테스트의 목적은 무엇인가? 정해진 문제 상황을, 빠른 시간 내에, 정확한 알고리즘을 구현해 풀어내는 것이다. 이를 달성하기 위한 수련법은 문제 상황을 구조화하고, 올바른 알고리즘을 빠르게 떠올리는 능력, 그리고 부가적으로 로직을 빠르고 정확하게 구현해내는 능력이다. 흔히 수학 공부할 때 많은 문제를 풀 듯, 코딩 테스트 역시 많은 문제를 풀어보며 "왜 이 로직을 써야 할까?"를 고민해야 실력이 는다. 그렇게 단련되면 문제 지문만 읽고도 "음, 이건 다익스트라네. 이건 DP네." 하고 풀게 된다. 얼핏 보면 좋아보이지만, 결국 문제 해결법에 틀을 만드는 행위로 이어진다.

 

나는 수학 문제를 풀 때, 수능 30번 문제를 푸는 걸 즐겼다. 비록 정답률도 낮고, 숙련되진 않았으며, 푸는 속도도 몇 시간씩 걸렸지만, 그냥 그게 재미있었다. 이는 코딩 테스트도 비슷했고, 나는 여전히 성장보다 재미에 집중했다. 그 결과...

 

[C++] 소인수분해: 두 소수 p, q의 곱 n이 주어질 때, p, q 알아내기

 

이렇게 잘 알려진 문제에 도전해보기도 하고,

 

[백준/C++] 1038번. 감소하는 수

 

이렇게 단순하면서 강력한, 그리고 흥미로운 정답을 도출한 적도 있다.

 

내 목표는 문제풀이의 전문가가 되는 것이 아닌, 가끔은 웃기고, 창의적인 로직을 만드는 것이다. 성능이 중요한 분야라면 어차피 즉석에서 공부해 적용할 수 있으니, 좀 더 새로운 발상을 해내는 쪽이 목표다. 무엇이 옳고 그름을 떠나, 내가 어떤 전문가가 되고 싶은지를 명확히 아는 것이, 완벽하게 선행되어야 이 책이 의미있어질 것이다.

 

조금 다른 길로 샜는데, 결국 전문가가 되기로 한 길이라면 작가의 의견에 100% 공감한다. 농구를 할 때 슛을 1,000번씩 쏘라곤 하지만, 정확히 골대를 노리고 쏘면서 자세를 조정하는 1,000번과, 아무 생각 없이 아무 곳으로나 던지는 1,000번은 다르지 않겠는가?

 

전문가가 되려면, 전문가를 관찰하라.

이 부분 역시 읽으며 많은 공감이 되었다. 나는 새로운 분야에 도전할 때, 가장 먼저 하는 것은 잘하는 사람을 관찰하는 것이었다. 그림을 그릴 땐 작가의 라이브 방송을 찾아보고, 클레이로 조소할 땐 배속된 영상을 0.25배속해 돌려보았다.

 

우린 흔히 전문가에게 가르침을 받으면 전문가가 된다고 생각하지만, 실상 전문가가 가르칠 수 있는 건 자신의 실력 중 극히 일부에 불과하다. 신입과 전문가 사이엔 거대한 시간의 벽이 있으며, 그동안 전문가가 겪어온 경험이 우리에겐 없기 때문이다. 오랜 시간 부딪히고, 배우며 체득한 기술들은, 습관이 되어 무의식 중에서도 발생한다. 그래서 우리가 하는 것과 그들이 하는 것엔 큰 격차가 존재한다. 우리가 해야하는 건, 그들이 가진 습관까지 베껴오는 것이다.

 

그래서일까, 나는 누군가를 가르칠 때 내가 작업하는 방식을 있는 그대로 보여주는 것에 집중하곤 했다. 당연히 지식을 가르칠 때가 아닌, 개발을 잘하는 방법이나, 공부를 잘하는 방법 같은 것에 말이다. 그래서 상당히 장황해보이기도 하지만, 그것이 가장 좋은 선생이라고 믿고 그렇게 해왔다. 물론, 대부분의 경우 내 스타일에 안 맞다며 떠나곤 했지만.

 

반대로, 나는 정말 전문가들을 철저히 관찰해왔나? 돌아보게 되었다. 유튜브 영상을 분석해가며 게임을, 그림을, 조각을 배우던 때에도, 나는 언제나 그들의 몸짓만 따라할 수 있었다. 진정 중요한 것은 그들이 왜 그런 행동을 했는가, 어떤 의도를 갖고 했는가인데, 운좋게 그런 강좌를 찍은 경우라면 배울 수 있었지만, 그렇지 않은 경운 한계가 있었다. 그리고, 정작 개발에 있어선 전문가를 관찰해본 적이 없었다. 실력자를 만날 기회 자체도 적었으나, 그들이 일하는 방식을 관찰할 기회는 더 적었다. 그나마 좋은 기회로 뛰어난 게임 기획자분을 보며 배울 순 있었지만, 이 역시 매주 회의 때 준비해오신 것들로 엿볼 뿐이었다.

 

다행히, 개발자는 네트워킹 행사가 많은 직업인 것 같다. 오프라인 세미나부터 온라인에 녹화된 세미나들까지. 우선은 그런 영상을 찾아보고, 행사에 참여하며 편린이라도 엿보는 것에 집중해야겠다.

 

실수는 예방하는 것이 아닌, 관리하는 것이다.

사실 당연한 일인데, 나조차 무의식적으론 그렇게 생각하지 않았나 반성하게 되었다. 내가 군대에 있던 시절, 사고를 많이 치는 후임에게 입버릇처럼 했던 말이 있다. "실수는 누구나 하는 거고, 그러니 실수 하나하나에 연연하지 마라. 중요한 건, 실수한 후 어떻게 행동하느냐다." 잘못을 저질렀다면 진심을 다해 사과하고, 내 잘못으로 피해를 봤다면 메꾸려 노력하며, 일의 수습이 끝나면 왜 이런 일이 벌어졌는지 분석하고, 예방한다. 여기서, "실수는 예방하는 게 아니라는데요?"라고 할 수도 있겠지만, 같은 실수를 여러 번 하는 건 실수가 아닌 나태라고 생각한다. 실수가 허용되는 건 어디까지나 처음 한 번뿐이다.

물론 저 말을 들은 후임은 동기들에게 잘못을 했을 때, 사과하는 대신 이 말을 인용해 화만 돋궜지만.

 

이슈는 언제, 어떻게 터질지 모른다. 중요한 건, 실수가 벌어져도 수습해내는 과정. 그 자체가 중요한 것이다. 나는 지금껏 실수 관리를 잘하고 있었을까? 혹여나, 누군가의 실수에 화낸 적은 없는가?

 

협력을 못하는 전문가는 전문가가 아니다

이 부분은 읽으면서 많이 찔렸다. 내가 어릴 적 꿈꾸던 내 모습은, 혼자서도 척척, 남들이 못하는 걸 해내는 천재 과학자였으니까. 개발을 시작한 후에도 목표는 1인 개발자였고, 남들과 협력할 생각은 갖지도 않았다. 성격도 혼자 있는 걸 즐겼고, 사람을 좋아하기보단 귀찮아했다. 조별과제는 내가 운전대를 잡을 일이었다.

 

그런 내가 군대를 전역하고, 복학하며 가장 먼저 한 일은 처음 만난 사람에게 말 걸기였다. 군대에서 후임들에게 잘 대해주지 못한 게 내내 원망스러웠고, 그 이유가 사람을 좋아하려한 적이 없었기 때문이었으니까. 억지로라도 다른 사람을 좋아해보자. 그렇게 강의실에서 우연히 옆에 앉은 사람에게 과제를 물어보며 말을 걸었다. (당시 수업은, 온라인 강의를 듣고 강의 시간엔 문제를 푸는 알고리즘 수업이었다.)

 

그리고 많은 게 변했다. 그 사람의 권유로 동아리에 들어가고, 동방의 모든 사람에게 인사를 건네고 이름을 물으며 친해지려 노력했다. 단순히 친해지는 걸 넘어, 그 모든 사람들을 사랑해보려 노력했다. 단점에게서 눈돌리고, 장점은 극대화하며, 그토록 싫어했던 스몰 토크도 끝없이 시도해보았다. 그렇게 좋은 사람들을 많이 만났고, 몇 개의 팀을 만들어 보았으며, 이전보다 행복한 삶을 살게 되었다. 자신의 작업물을 스스럼없이 공개하고, 남들의 작업물을 발전시키려 토론하는 개발자 문화 덕에, 점차 협력이란 무엇인지 깨달아가는 중이다.

 

그럼에도 아직 부족한 점이 많다. 난 아직 좋은 리더가 되지 못했고, 일정 관리는 미숙하며, 때론 내가 할 일을 떠넘기기도 한다. 이제 사람과 더불어 지내는 걸 넘어, 진정 협력을 위해 노력해야겠다고, 그걸 위해선 더 많은 기회를 움켜쥐고, 더 많은 책을 읽고, 더 많은 얘기를 나눠봐야겠다고 다짐하게 되었다.

---

마무리

"함께 자라기"는, 동아리의 친한 선배가 권유했던 책이다. 사실 영업한 진 꽤 되었으나, 미루고 미루다 이제서야 읽었다. 그리고 추천했던 이유를 알게 되었다. 이 책은, 분명 많은 사람에게 도움이 될 책이다.

 

이번 장은 3단원 중 자라기에 대해 적어보았다. 여기엔 이번 글에 적은 것 외에도, 성장에 도움되는 글들이 많으니 꼭 읽어보길 바란다. (사실 대부분의 내용은 책의 내용보단 내 경험이지만.)

 

이 책에선 자라는 법을 아는 법을 중요시하지만, 그렇다고 꾸준한 노력이 필요없어지는 건 아니다. 우리가 아무리 수련법을 깨우쳤다한들, 방법만 아는 채 아무 것도 하지 않으면 방법을 모른 채 미련하게 하는 자보다 못하게 된다. 이건 내 가장 큰 약점이기도 하다. 단순히 아는 것을 넘어, 배운 내용들은 꼭 직접 실천해보며 몸으로 체득해보자. 우리가 아무리 구조를 잘 짜도, 막상 프로그래밍해보면 예상치 못한 에러가 나타나듯, 직접 해보면서 배우는 것또한 많을 테니까. 앞으론, 조금만 더 성실해지자.