DEVOCEAN

안녕하세요😁 데보션 영 2기 밤비영의 이준규입니다.

이번 활동 중 데보션으로부터 다양한 책을 지원 받아, 여러 북 스터디를 진행할 수 있었는데요,

특히 저희 조는 꼬마집사님께서 추천해주신 함께 자라기 (애자일로 가는 길) 책을 선정하였습니다.

저희 밤비영은 프론트엔드, 백엔드, 머신러닝 개발자와 마케터까지, 다양한 분야의 IT 종사자들이 모여있었기에 이렇게 성장과 관련된 책을 선택하게 되었습니다!

기존에도 유명한 책이었지만, 저희가 스터디를 진행하는 동안 주위에서 이 책을 읽는 사람들이 늘어나는게 너무 신기했습니다!

(지인들과 공유하는 투두 앱에서 함께 자라기가 점점 등장하는 모습을 볼 수 있었어요)

이러한 책을 만날 수 있게 해주신 데보션과 꼬마집사님께 감사한 마음을 담아, 저희가 진행했던 스터디 중 각 장의 내용을 정리해보았습니다.

[1. 자라기 - 이준규]

1장은 전반적으로 "실력있는 개발자 되기 위한 올바른 길" 에 대해 설명하고 있었습니다.

1. 실력있는 개발자란 무엇일까?

2. 왜 우리는 실력있는 개발자가 되지 못했을까?

3. 실력있는 개발자 되기 위해 무엇을 어떻게 해야할까?

책의 본 목차는 아니지만, 스터디를 진행하며 저희끼리 이야기했던 저희만의 1장 흐름이었습니다🤔

작년의 저는 분명 어제에 짰던 코드가 레거시로 느껴질 정도로 실력이 빠르게 성장한다는 것을 느꼈는데, 올해의 저는 알고 있는 것을 활용하기만 한다는 느낌을 강하게 받았습니다.

이러한 저의 작은 고민과 걱정... 을 1장에서 어느정도 해결할 수 있었 던 것 같아요. 앞으로 어떻게 공부해야 할지에 대한 방향성도 다잡을 수 있었던 것 같습니다.

1. 실력있는 개발자란 무엇일까?

1장의 1 ~ 4 목차의 내용은 실력있는 개발자에 대한 개괄적인 이야기였습니다.

그 중 인상깊게 읽었던 부분을 소개드립니다.

✅ 1만 시간의 법칙의 1만 시간은 의도적 수련이다.

IT 업계에서 경력을 중시하는 문화가 점차 줄어들 것이라는 이야기가 있습니다.

예를들어 어떤 기업은 지나치게 경력을 중요시하고 협력 능력을 등한시하는데,

이에 대해 저자는 경력의 양적인 면은 업무 성과와 큰 연관이 없는 것을 넘어서 편향을 주는 잘못된 지표가 될 수 있다고 말합니다.

때문에 이러한 문화가 팽배해지면서 개발자들은 자신의 경력이나 연차 말고도 다른 것을 준비해야 한다고합니다.

어떤 이는 몇년전까지 유행했던 1만 시간의 법칙을 떠올리고, 지금까지 업무량만 합해도 1만 시간이 넘으니 본인은 전문가에 길을 걷고 있다고 생각하기도 합니다.

하지만 잘 생각해보면, 우리는 매일 이를 닦고 세수를 하지만, 이 닦기와 세수하기의 마스터가 되지는 않았습니다.

1만시간의 법칙을 만든 저자가 말하는 1만 시간이란, 자신의 기량을 향상시킬 목적으로 반복적으로 하는 수련 시간

입니다. 악기 연주자에게는 공연 시간은 포함되지 않고, 체스 선수에게 토너먼트 시간은 포함되지 않습니다. 우리 개발자들에게도 업무 시간은 포함되지 않습니다.

✅ 자기 계발과 복리 조직

저자는 연말에 매번 회고를 한다고 합니다. 회고를 하면서 자신에게 투자했던 시간을 체크하는데, 이 자신에게 투자하는 자기 계발의 시간이 아주 중요하다고 말합니다.

자기 계발은 마치 복리와 같아서, 자신에게 전혀 시간을 투자하지 않는다면 당장에는 별 일이 없는 것처럼 보이지만 추후에 큰 문제로 돌아올 수도 있고,

자신에게 시간을 조금이라도 투자한다면 당장 큰 차이가 없어보이지만 추후에 아주 좋은 작용으로 돌아올 수 있다고합니다.

이러한 자기 계발과 복리 이론은 조직에서도 적용되는데, 조직에서 생산한 결과물을 받아들이고 개선해서 다음 결과물을 낫게 만드는 구조를 "복리구조"라고합니다.

2. 왜 우리는 실력있는 개발자가 되지 못했을까?

1장의 5 ~ 7 목차는 우리가 일반적으로 실력있는 개발자가 되지 못한 이유에 대한 내용이 담겨있었습니다.

✅ 프로그래머와 개발자는 다르다.

인공지능이 고도화 되면서, 많은 직업이 대체 위협에 놓이게 되었습니다.

옥스퍼드에서 발표한 논문을 살펴보면, 인공지능으로 대체하기 어려운 직업은 독창성 사회적 민감성 협상 설득 타인을 돕고 돌보기 등의 특징을 갖고 있었습니다.

이러한 특징을 바탕으로 여러 직업을 계산해보았더니, 컴퓨터 프로그래머는 대체 확률이 48%로 중 위험군에 속한 반면, 소프트웨어 개발자는 4.2%로 확률이 아주 낮았습니다.

즉, 자신이 주로 하는 일이 남이 시킨대로 혼자 프로그램을 만드는 것이라면 그것은 특색이 되지 못하며

미래에는 암묵지와 직관을 함양한 사람들이 경쟁력을 가진 개발자가 될 것이라는 것입니다.

✅ 타당성과 피드백

타당성과 피드백이 낮은 환경에서 일을하면, 전문성을 향상할 수 없습니다.

가령 포커의 경우에는 운이 적용하지만, 결정을 할 때 타당성이 작용합니다.

하지만 주가의 경우에는 실제로 펀드 매니저가 예측한 것과 원숭이가 예측한 것의 차이가 크지 않을 만큼 타당성이 떨어집니다.

또한 위에서 말한 골프 퍼팅의 경우에는 피드백이 빠르게 일어날 수 있지만,

공항 보안 검색대에서 일을 한다면 본인이 잡지 못한 물건에 대해서 영영 피드백을 받을 수 없습니다.

소프트웨어 개발자의 경우에는 타당성도 피드백도 모두 중간 정도이기 때문에, 스스로 이를 높일 수 있는 방법을 찾아야합니다.

3. 실력있는 개발자 되기 위해 무엇을 어떻게 해야할까?

1장의 마지막은 실력있는 개발자가 되기 위한 방법이었습니다.

✅ 의도적인 수련의 방법은?

1만 시간의 법칙에서, 1만 시간은 의도적 수련이라고 했습니다. 그렇다면 그 의도적 수련을 할 수 있는 방법은 무엇일까요?

저자는 골프 선수가 공이 어디 떨어지는지도 모른채 1000번 스윙 연습을 하는 것에 대해 어떻게 생각하는지 묻습니다.

물론 무언가 연습이 되긴 하겠지만, 이는 정확히 내가 무엇을 고쳐야하는지 모른채 그저 휘두르는 연습을 할 뿐입니다.

개발자도 마찬가지입니다. 우리에겐 무엇이 잘못되었고 무엇을 고쳐야하는지 "피드백"이 필요하고, 이 피드백을 기반으로 수련해야합니다.

✅ 타당성과 피드백 높이기

본인의 하루가 지루하거나 불안하다면, 도무지 실력이 늘지 않는 환경에 위치하고 있다는 것입니다.

이때 우리는 몰입 안으로 들어가는 것을 목표로 해야하고, 저자는 그 방법에 대해 소개하고 있었습니다.

a1. 실력 낮추기

만화에서 주인공이 모래주머니를 들고 수련하듯, 작업 난이도는 그대로 두고 본인에게 일정한 장애 요소를 두는 것입니다.

지루하던 작업에 몰입하고, 실력이 늘어날 수 있습니다.

a2. 난이도 높이기

일반인과는 싸움이 되지 않던 이소룡이 3분 내에 이겨야한다는 조건을 건 것처럼, 실력은 그대로 두고 난이도 자체를 높이는 전략입니다.

뛰어난 프로그래머들은 이미 적용하고 있는 방법이며, 가령 하루만에 개발할 것을 한 시간만에 해보기, 100rps를 기준으로 삼는 기능을 1000rps로 만들어보기 등 작업 난이도 자체를 높이는 방법이 있습니다.

b1. 난이도 낮추기

아기 버전을 만들어 보는 것입니다. 가령 저자가 소개하는 P 프로그래머의 경우에는, C언어로 제출해야하는 과제에서 본인의 주 언어인 python로 아기 버전을 작성 후 C언어로 변환했다고 합니다.

b2. 실력 높이기

점진적으로 실력을 높이는 방법은 많습니다. 하지만 지금 당장 b2를 경험하고 싶다면,

사회적 접근을 통해 닥친 문제를 해결한 경험이 있는 사람을 만나보거나

도구적 접근을 통해 오픈소스 라이브러리르 활용하거나

내관적 접근을 통해 이전의 경험을 떠올려보는 것입니다.

전반적으로 굉장히 유익하고 많았던 내용 중, 인상 깊었던 내용을 함축해서 작성해보았습니다.

실력있는 개발자에 대한 많은 인사이트를 얻을 수 있었고, 앞으로 어떤 식으로 나아가야할 지 결정할 수 있었습니다.

[2. 함께 - 정승연]

책을 읽으며 11월 앱 출시를 준비하는 우리 팀 생각이 많이났어요.

팀의 리더로써, 이런 점을 중심으로 우리팀을 이끌었으면 좋았을텐데 하는 후회와 앞으로 제시해야할 방향성을 정리하며 읽었답니다!

2장은 ‘함께’ 에 집중한 내용이었어요.

책에서 함께 추상화를 이뤄가는 과정, 함께 공유하며 신뢰를 쌓아가는 과정 등에 내해 논하고 함께 성장할 수 있는 방법을 제시했고, 이를 통해 많은 것을 깨달을 수 있었어요.

‘함께 자라기’ 의 2장 함께를 읽으며 도움이 되었던 부분, 인상 깊었던 내용을 중심으로 책 내용을 정리해보았습니다!

"일반적으로 실력이 뛰어난 프로그래머는 보통 정도의 실력을 가진 프로그래머에 비해 커뮤니케이션, 협력 능력이 뛰어나다." 라는 연구결과를 제시하며 ‘함께’ ‘협력’ 하는 프로그래머를 중시했습니다.

톱니 바퀴 실험을 통해 협력을 통해 결과물을 얻어내는 것이 훨씬 효율적이라고 밝혔습니다.

혼자 작업한 경우에는 14%만이 추상화 규칙을 찾았지만, 둘이서 함께 작업한 경우 58%가 추상화 규칙을 찾아냈습니다.

두 사람이 서로 마주 앉아 허공에 손을 들고 톱니바퀴가 도는 흉내를 내며 실험을 진행하는데, 과정 중에 톱니바퀴의 방향에 대해 혼동이 생기게 됩니다.

이런 혼동을 해결하기 위해 추상적 개념을 도입하고, 이 추상적 개념이 문제 해결을 가속화 했습니다.

둘이 협력하면서 작업하면 서로 시각이 다르기에 두 사람의 다른 시각을 연결해줄 다리가 필요하고, 그 다리에는 필연적으로 추상화의 요소가 있습니다.

두 사람 사이의 서로 다른 것을 하나로 묶어야 하기 때문입니다.

신뢰를 깎는 공유인가 신뢰를 쌓는 공유인가

신뢰의 가치가 최근 경영학 등에서 많은 주목을 받고 있는데, 신뢰 자산이 높은 조직은 커뮤니케이션 효율이나 생산성이 높다 는 연구가 많기 때문입니다.

어떻게 조직 간 신뢰를 쌓을 수 있을까. 저자는 투명성과 공유, 인터랙션으로 쌓는다. 고 밝혔습니다.

자신이 한 작업물을 투명하게 서로 공유하고 그에 대해 피드백을 주고 받으며 인터랙션 한다. 이를 소통 신뢰라고 합니다.

전문가팀이 실패하는 이유

전문가팀이 실패하는 이유에 대해 다음과 같이 정의하고 다음과 같은 해결책을 제시했습니다.

전문가들 모아서 팀 만든다고 잘 하는 것도 아니고

오히려 성과가 떨어질 수 있고

정보 공유하고 협력을 잘 하기 위한 명시적인 도움이 필요하며

소셜 스킬 등이 뛰어난 제너럴리스트가 있으면 도움이 된다.

구글이 밝힌 탁월한 팀의 비밀

데이터 중심 회사 답게 구글은 데이터를 기반으로 뛰어난 관리자의 특징을 찾는 프로젝트를 진행했습니다.

저자는 그 연구 결과중 다음 세 가지를 중심으로 보았습니다.

1. 팀에 누가 있는지보다 팀원들이 서로 어떻게 상호작용 하고 자신의 일을 어떻게 바라 보는지가 훨씬 중요하다.

2. 5가지 성공적 팀의 특징을 찾았는데 그 중 압도적으로 높은 예측력을 보인 변수는 팀의 심리적 안정감이었다.

3. 팀 토론 등 특별히 고안된 활동을 통해 심리적 안정감을 개선할 수 있다.

여기서 말하는 심리적 안정감이란 내 생각이나 의견, 질문, 걱정 혹은 실수가 드러났을 때 처벌받거나 놀림 받지 않을 거라는 믿음을 말합니다.

이러한 심리적 안정감을 높이기 위해서는 팀 토론 등 특별히 고안된 활동을 통해 안전한 환경에서 이야기 할 수 있도록 해주는 것이 중요합니다.

단순히 우리 팀의 현 상황에 대해 연린 대화를 시작하는 것만으로도 변화가 시작될 수 있습니다.

그것보다 이전에 우선적으로 리더와 관리자가 팀원과 갖는 마이크로 인터랙션에서 신뢰를 쌓는 행동을 보여주어야합니다.

쾌속 학습팀

기술이 급변하는 패러다임에서 살아남을 수 있는 방법에 대해 논했습니다.

학습을 팀의 중대한 목표로 받아들이고 리더는 기회와 가능성, 큰 변화의 흐름에 동참하는 중요성과 즐거움 등을 강조했습니다.

그에 반해 급변하는 패러다임에 살아남지 못한 팀은 학습보다는 단기 퍼포먼스를 중시했고, 리더는 낙오의 위험성, 팀원의 실력에 대해 불평했습니다.

이를 현실에서 실천할 수 있는 방법으로 자신의 실천 환경을 만들기. 학습과 일을 분리하지 말고 하나로 생각하기를 제시했습니다.

[3. 애자일 - 박병규]

책에 많이 나왔던 용어지만, 익숙하지만은 않은 '애자일 소프트웨어 개발 방법론'의 정의와 효과에 대한 설명입니다!

현재 애자일을 활용하는 IT 기업의 역사를 봤을 때 기존 방법에서 애자일 방법론으로 바꾸는 과정이 있을텐데, 이 두 방법은 완전히 반대라고 할 수 있죠.

기존 방식은 개발 단계 전 계획을 철저하게 세우고*(배보다 배꼽이 큰 개발세상..)* 개발단계에 돌입합니다. 이 때는 철저하게 계획을 세워야 개발 단계가 편해진다고 생각을 했기 때문이에요.

하지만 애자일은 성공의 여부가 확실하지 않은 프로젝트에서 더욱 빛을 발합니다.

제가 현재 기업에서 진행하는 프로젝트도 개발의 성공여부가 확실하지 않을 때, PoC(Proof of Concept)를 먼저 진행하고 완전한 개발에 들어가는 과정이 필수입니다.

'애자일 방법론'은 이러한 과정을 짧은 주기로 반복적으로 진행합니다.

그럼 이런 특징만이 기존 방법과의 차이점일까요?

아닙니다. 애자일 방법론의 또 다른 특징은 Customer에게 주기적으로 배포해 가치를 전달합니다.

지속적으로 Customer에게 피드백을 받고, 점진적으로 개발해 나갑니다. 이는 '프로젝트의 성패를 좌우하는 사람을 참여시키기 위해 노력하는 것'을 목표로 합니다.

이런 방식은 조직의 애자일 방법론에 대한 성숙도가 낮을수록 더욱 효과적으로 보입니다.

애자일의 대표적인 특징 3가지,

1. 짧은 반복 개발 주기

2. 고객 참여

3. 코드 공유

중 성숙도가 낮은 조직은 고객 참여에 가장 큰 효과를, 높은 조직은 짧은 개발주기에 큰 효과를 봤습니다.

"함께 자라기"라는 책의 제목과 애자일 방법론은 밀접한 연관이 있습니다.

가치가 있는 프로덕트임이 확실한 개발만을 하는 시대가 아닌, 불확실한 개발을 위주로 진행하고,

이러한 개발을 가치있게 만들어야 하는 시대가 왔기 때문에, 개발자들과 고객은 함께 자라야 한다는 것이 애자일과 요즘 개발의 큰 특징입니다.

대학생의 입장에서 애자일 방법론이 익숙하지는 않습니다.

하지만 어떠한 가치를 목표로 프로젝트를 할 때, 중간중간 배포 후 예상 고객층들에게 피드백을 받는 것만으로도 애자일을 실천할 수 있을 것이라고 생각합니다.