함께 자라기

서론

우선 이전글에서 다뤘던 SW Maestro 소마 라고 하는 정부지원사업에 붙게 되었다. 320명이나 되는 연수생들을 대충 확인해보았는데, 정말 다양한 사람들이 정말 많다는것을 느꼈다. 그리고 대부분이 전공생이 였다는게 정말 놀라웠다. 현재 진행중인 42 Seoul 인 경우에는 전공생보다는 부전공 혹은 아예 다른 전공에서 다른 일을 하다 프로그래머의 길로 빠지게 된 경우도 많이 보았는데 참 색달랐다.

그 후 멘토링을 몇번 받게 되었고, 운 좋게 마음에 드는 두분을 만나 팀 매칭까지 끝나게 되었다. 우리는 AI, 나 어플의 CRUD 시스템같은것 보다는 조금 더 혁신적이고, 재미있는 프로젝트를 하기로 했다. 아직 정확한 기획은 없지만 아마 메타버스 혹은 그 상위의 무엇인가가 될것 같다. 조합은 웹의 정석이라 불리는 2FE 1BE 로 진행이 될 것 같다.

그리고 우리의 목적은 사업적으로 엄청나게 뛰어난 창업을 하겠다! 혹은 이 세계에 도움이 되는 무언가를 만들어 내겠다! 이런것은 아니다. 좀 더 우리의 가치와 실력을 높일 수 있는 기회가 되었으면 좋겠다! 에 가깝다. 그래서 우리는 최대한 다양한 기술들을 배우고 협력하는 과정을 느껴보자! 가 주제가 되었다.

그렇게 우리의 목적에 맞춰 우선 정한것은

Jira 를 사용해보자
애자일 방법론을 채용하자

였다.

Jira 같은 경우에는, 차차 더 알아보며 Git Confluence 와 연동해서 사용 해 볼 예정이고 애자일 방법론에 대해서는 스프린트와 스크럼 정도밖에 몰랐던 나였기에 조금 더 공부를 해보고자 하였다.

그렇게 애자일이 무엇인가! 항상 근본적인것을 좋아하는 나는 애자일의 뜻부터 알아보았다.

애자일은 민첩성을 뜻하며 소포트웨어 기업들이 도입한 개념으로 급변하는 시장에서 기민한 대응을 하기 위해 빠르고 유연한 기업 환경(조직)을 만드는 것을 목적으로 한다.

항상 말은 참 쉽지만, 실제로 이해하기는 정말 까다롭다. 그러던 중 팀원 중 한명이 함께 자라기 라는 좋은 애자일 방법론에 대한 책이 있다하여 읽어 보기로 하였다.

자라기

이 책을 읽다보면 정말 단순하지만 머리를 띵! 하게 만드는 부분들이 꽤나 있다. 우선 자라기에 대한 부분이 내 입장에서 제일 생각을 많이하게 만들었다.

가치

다들 1만시간의 법칙 을 많이들 들어보았을 것이다. 정말 단순하게 어떠한 분야의 전문가가 되려면 1만시간 정도가 필요하다는 뜻이다. 하지만 이 말에는 큰 함정이 빠져있다. 이 1만시간 에는 단순히 내가 즐기거나, 어쩔 수 없이 하는것이 아니라 피드백을 받고 공부하거나 노력하는 과정이 포함되어야 된다는 것이다. 게임을 보더라도 내가 낮은 티어에서 게임을 몇천판을 하였지만, 아직도 낮은 티어일 수 있다. 책에서는 그 이유를 피드백 혹은 노력을 하지 않는것이라고 본다. 매 판마다 분석을 하고 취약점에 대하여 고치려는 노력을 한다면, 약점에 대해서는 반복적인 훈련을 한다면, 과연 실력이 낮은채로 가만히 있을까? 당연히 실력이 개선되는 미래가 펼쳐질 것이다.

피드백

자라기에 또 매우 중요한 부분이 있다. 바로 피드백이 빨라야 된다는 것이다. 만약 우리가 어떠한 액션을 취하였을 때, 그에대한 결과가 1년후에 온다면 어떨까? 아마 1년전에 어떤 액션을 취했는지 기억도 잘 나지않아, 피드백이 제대로 이루어지지 않을것이다. 액션 직후 피드백을 바로 받고 그것을 기록 후 다음에 볼때 진정한 피드백이 완성된다고 본다. 그리고 이것은 1만시간의 법칙 에도 포함이 된다. 빠르고 진정성있는 피드백이 나를 발전시키는 중요한 포인트라 할 수 있다.

실수

이 책은 이상하리만치 실수에 관대하다. 오히려 실수를 권장하는 모습까지 보여준다. 이건 나의 입장에서는 정말 특이한 접근이였다. 프로그래밍을 하다보면 실수를 줄여가는 것이 전문가의 덕목이라고 생각했고, 실제로 내가 처음 프로그래밍을 하던것과 비교를 해보면 실수가 정말 상당히 줄었다. 하지만 여기서 말하는 실수는 실제로 컴파일 과정을 하고 서버 배포를 해보니 앗! 에러가 있네! 이런것이 아니다. 프로그래밍을 하다 작은 오타 혹은 변수 하나 잘못 넣은것도 실수라고 본다. 그리고 이러한 소소한 실수는 얼마든지 해도 되지만 이러한 실수를 한 후 어떤식으로 대처를 하는것인가에 대해 집중한다.

책에서는 실수에 대한 문화를 두가지로 나누는데 실수 예방 과 실수 관리 이다. 첫번째인 실수 예방 을 중점으로 두는 회사같은 경우, 실수를 하는 경로를 방지하며, 실수에 대하여 비난 및 처벌이 주가 되는 반면, 실수 관리 를 중점으로 두는 회사는, 실수를 빨리 발견 및 해결 그리고 피드백 후 다음에는 어떤식으로 대처를 하자가 주가 된다.

함께

AND OR

여기서 AND OR 연산자로 사람을 설명한다. 정말 공대스럽지 않을 수 없다. 하지만 또 정말 이것만큼 공대생들을 이해시켜주기 편한게 없다고 생각한다. 사람이 무엇인가를 배우거나 협력을 할 떄 AND 인지 OR 인지에 대하여 진지하게 설명한다.

우선 우리는 AND 보다 OR 적인 사람이 되어야 된다 설명한다. 분석을 하였을 떄, AND 성향이 있는 사람은 독립 개체로 본다. 통계적으로 보면 독립사건이 되는것이다. 예를 들어, 프로그래머가 작업을 마감일에 맞춰 끝낼 확률이 0.9라 보자. 그럼 프로그래머가 5명이 모두 마감일에 맞출 확률은 0.9일까? 이건 0.9 ^ 5 의 확률이 될 것이고, 이건 0.6 밖에 되지 않는다. 즉 통계의 오류가 발생한 것이다. 하지만 팀을 꾸려 5명이서 한 작업을 같이 끝내고, 다음으로 넘어가는 식으로 한다면? 그건 OR 연산으로 오히려 한 프로젝트당 잘 끝낼 확률이 0.9보다 높아지며 효율또한 증가할것이라는 분석이다. 물론 실제로는, BE FE 등 따로 작업을 하겠지만, 그럼에도 불구하고 정말 좋은 접근이라 생각한다.

당국자미 방관자청 (當局者迷傍觀者淸) 바둑을 구경하는 이가 더 수를 잘 본다 라는 뜻이다. 이건 단순히 바둑이 아닌 프로그래밍에도 통용이 된다 생각한다. 내가 페어프로그래밍을 할 때, 실제로 타이핑을 하는 사람은 타이핑하느라 정신이 없고, 설계한 대로 구현하고 있을때, 옆에서 보조하는 사람은, 코드를 보며 오류를 손쉽게 찾을 수 있으며, 설계에서 더 흐름을 보기 쉽다고 생각을 한다. 이러한 점에서 OR 적이며 앞에서 말한 실수의 관리에도 더욱 효율이 좋을것이다.

애자일?

사실 책은 애자일 방법론에 대하여 그렇게 중점적으로 설명해주지 않는다. 오히려 애자일이 디테일해질수록 애자일에 멀어진다고 설명한다. 애자일은 애초에 민첩하게 급변하는 시장에 맞춰 발전하는 형태이기에, 정적일수록 근본적으로 맞지않다고 판단하는 것이다.

그럼에도, 나는 조금 더 스크럼을 하는법 혹은 스프린트를 뛰는법에 대하여 알려줬으면 좋겠다고 생각을 했지만, 그런부분은 조금 아쉬웠다. 그럼에도, 애자일을 왜 사용해야 되는지는 정말 깔끔하게 설명을 해준 것 같다. 앞에서 언급한 가치, 피드백, 실수 등 애자일 방법론을 채택하면 모두 극복이 가능한 시나리오 이다. 매일매일 스크럼과 일주일 단위의 회고로 인하여 완벽한 피드백 시스템을 구축 할 수 있으며, 이러한 과정에서 가치를 높일 수 있다 생각한다.