<div id="readability-page-1" class="page"><div><img src="http://image.yes24.com/goods/105645204/XL" alt="표지">
좋았던 부분이 워낙 많아 다 담을 수는 없지만, 크리티컬 싱킹이 나에겐 정말 와닿는 문장이었고, 팀원간의 강점과 약점을 공유 하는 것, 리더로서 투명성을 유지 해야 하는 것들이 정말 좋았다.
<blockquote data-ke-style="style1">
경력이 10년 차쯤 되면 시니어 개발자입니다. 이때는 혼자서만 잘한다고 끝이 아닙니다. 일을 크게 만들 줄을 알아야 하고요, 다른 사람을 이끌며 일할 줄 알아야 합니다. 프로젝트를 리드하고 기술을 결정하며 점점 더 큰 일을 더 많이 하게 되는 거죠. 여기까지는 '열심히 영역에 속합니다. 다음 위치에 다다르려면 조금 더 많은 것이 필요합니다.
</blockquote>
<blockquote data-ke-style="style1">
블리자드에서는 이후 레벨의 개발자를 리드 개발자, 프린시펄 개발자라고 불렀습니다. 리드 개발자가 되려면 미지의 영역을 해결하는 능력이 필요합니다. 블리자드에서는 아는 일을 잘하는 능력보다 모르는 일도 분석해서 끝까지 처리하는 능력, 그래서 새로운 프로젝트를 맡을 수 있는 능력이 있어야 리드 개발자로 승진합니다. 리드 개발자 승진 평가에는 심지어 다른 팀의 디렉터들까지 참여합니다. 회사 전체에 영향력이 퍼져 있을 정도로 많은 일을 하고 있어야지만 리드 개발자가 되는 것이죠. 반면에 프린시펄 소프트웨어 개발자는 진정한 구루여야 합니다. 프로젝트의 개발을 리딩한다기보다는 정말 깊게 기술을 연구해서 회사에서 인정받는 기술 전문가이어야 합니다.
</blockquote>
<blockquote data-ke-style="style1">
그다음은 디렉터입니다. 경력 20년이 넘어가는 위치입니다. 이제부터는 책임의 영역입니다. 저는 농담으로 디렉터를 정의하며 이런 표현을 씁니다. “모든 일을 할 수는 있지만 아무 일도 하지 않고 대신 모든 일에 책임지는 사람”이라고요. 단순히 일을 하는 사람이 아닙니다. 책임질 줄 알아야 하는 사람입니다. 그러려면 모든 것을 파악하고 옳은 결정을 빠르게내릴 수 있어야 합니다. 디렉터 위로는 VP of 엔지니어링' 이나 CTO가 있습니다. 이 둘은 사실상 경영과 사업 영역에 속합니다. 개발과 기술을 기반으로 사업에 기여하는 모든 일을 책임집니다. 당연히 개발은 개발자들이 하는 것이므로 좋은 개발자들의 채용과 교육 그리고 개발 문화까지도 챙겨야 하며, 개발 프로세스도 잘 정립해야 합니다.
</blockquote>
<blockquote data-ke-style="style1">
여러 레벨을 언급했는데요, 정리해보면 '어시스턴트, 어소시에이트, 미드 레벨 개발자' 까지는 배우고 성장하는 시기, '시니어, 리드, 프린시펄 개발자' 까지가 리드하면서 일하는 시기, '디렉터, VP, CTO'가 경영과 사업의시기에 속합니다. 그런데 모든 개발자가 경영과 사업의 시기까지 도달하기는 어렵습니다. 그래서 이에 대한 대안으로 서포트 시기를 마지막으로제안합니다. 우리나라 IT 업계는 10년 전에도, 지금도, 향후 10년 후에도개발자가 부족했고 부족하며 부족할 겁니다. 게다가 모든 개발자가 꼭 승진에 승진을 거듭하여 경영과 사업의 길을 갈 필요도 없습니다. 자신의 성향에 맞게 꾸준히 개발자 생활을 계속해나가는 전략도 중요합니다.
</blockquote>
<blockquote data-ke-style="style1">
커리어패스 30년을 성장하는 시기, 리딩하면서 일하는 시기, 서포트하는 시기(또는 경영과 사업의 시기)로 나눠봤는데요. 다음 단계로 성장하려면 10년을 꼬박 채워야 하는 걸까요? 더 빠른 길은 없을까요? 그렇지 않습니다. 10년보다 중요한 건 성장입니다. 그런데 성장은 무엇일까요? '성장'은 역량이 늘어난다는 뜻입니다. 사람의 '역량'이란 무엇일까요? 첫 번째는 지식, 두 번째는 숙련도, 마지막은 경험입니다.
</blockquote>
<blockquote data-ke-style="style1">
첫 번째 지식은 공부를 해야 쌓입니다. 지식을 쌓는 공부는 혼자서 하는 영역입니다. 물론 일하면서도 지식을 쌓을 수는 있지만, 근본적으로 본인이 하지 않으면 쌓을 수 없다는 측면은 같죠. 두 번째 숙련도는 같은 일을 여러 번 오래 반복해야 쌓을 수 있습니다. 결국 프로그래밍, 프로젝트, 소통, 협업을 해봐야 숙련도가 높아집니다. 얼마나 열심히 하냐에 따라 공부와 숙련에 드는 시간이 짧아질 수 있습니다. 반면 경험을 쌓는 데 드는 시간은 단축하기가 어렵습니다. 경험은 성공과 실패를 해봐야 하고, 이런 사람 저런 사람도 만나봐야 합니다. 다행인 것은 강연이나 책으로 다른 사람 경험을 간접 습득하면 시간을 줄일 수 있습니다. 왜 많은 사람이 책을 강조하는지 이제 알겠죠?
크리티컬 싱킹하라
대개는 상사가 일을 시키면 '네 알겠습니다' 하고 곧바로 일을 합니다. '크리티컬 싱킹' 이라는 말이 있습니다. 우리말로는 '비판적 사고' 정도로 번역할 수 있습니다. 크리티컬 싱킹은 주어진 일의 앞뒤를 생각하는 습관입니다. '왜 이 일을 해야 될까?', '이 일을 하다가 말면 어떻게 될까?', '어떤 방식으로 일하는 게 최선일까?' 문제의 상하좌우까지 고민하는 사고방식을 습관으로 들이면 모든 일을 더 깊이 들여다볼 수 있습니다. 두 사람에게 같은 난도의 일을 주고 1년을 일하게 한다고 해봅시다. 둘 다 갓대학을 졸업한 신입 직원이고 현재 역량이 같다고 합시다. 그러니까 둘다 채용되었겠죠. 1년이 지나고 보면 둘의 역량은 같을까요? 차이가 난다면 '크리티컬 싱킹' 이 그 차이를 만든다고 생각합니다. 삽을 들고 가서열 번 땅을 파고 독을 묻은 다음에 돌아와라' 하고 시켰을 때 그대로 하면 숙련도는 올라갑니다. 하지만 지식이나 경험은 잘 쌓이지 않습니다.
'왜 10번만 파야 되지?', '왜 삽으로 파야 하지?', '곡괭이로 파면 안 되나?', '꼭 파야 하나?', '독을 왜 묻지' 이런 질문을 하고 더 좋은 방법을 고민하면 어떻게 될까요? 관리자 입장에서는 전자가 편합니다. 시키는 대로 하니까요. 후자는 뭐 하나만 시키면 맨날 물어봅니다. 그래서 귀찮습니다. 그런데 1년이 지난 다음에도 전자한테는 여전히 설명을 길게 해줘야합니다. '동쪽으로 열 걸음 가서 땅을 열 번 파고 독을 묻어라. 그런데 후자한테는 김치를 잘 보관해봐' 라고 하면 끝입니다. 땅을 파는 대신에 김치 냉장고를 구비해 보관할지도 모릅니다. 크리티컬 싱킹 습관이 들어 있으면 그 사람이 감당하는 업무 스케일이 계속 커지게 됩니다.
개발자 자세, 30년 동안 도그푸딩 실천하기
도그푸딩 Dogfooding 이라는 말이 있습니다. '내가 만든 개밥을 스스로 먹어라 Eat your own dog food' 라는 말에서 유례했습니다. 우리말로 풀면 '본인이 만든 제품을 직접 써보라' 라는 격언이 되겠습니다.
</blockquote>
<blockquote data-ke-style="style1">
두 번째로 팀 관리를 살펴보겠습니다. '팀을 만든다 → 유지한다 → 제품을 출시한다' 순서로 큰 그림을 그립니다.
팀을 포밍forming 하면 스토밍 stoming, 즉 폭풍처럼 마구 싸웁니다. 그러고나면 잔잔해지고 noming 사람들이 친해집니다. 마지막은 퍼포밍performing, 즉일을 잘하게 되는 단계로 진입합니다. 대부분의 팀이 이런 순서로 돌아갑니다.
여기서 핵심은 신뢰와 지식입니다. 무슨 뜻이냐면, 새로 결성된 팀에서처음 만난 사람들은 당연히 서로를 신뢰하지 않습니다. 그래서 지식도 공유하지 않습니다. 상대방을 믿지도 못하고 상대가 무엇을 하는지도 모릅니다. 이게 첫 단계입니다. 그러다 조금씩 자기가 하고 싶은 말을 합니다.그러면서 본인의 지식을 전하게 됩니다. 아직은 서로를 신뢰하지는 못하기 때문에, 상대방 말이 기분 나쁘게 들립니다. 그래서 싸움이 생깁니드 스토밍 단계에 접어드는 거죠. 사람은 참 이상합니다. 싸우다 보면 결친해집니다. 정이 드는 것이죠. 친해지면 신뢰가 생겨서 다른 사람의식을 믿고 잘 협력하게 됩니다. 비로소 팀이 잘 돌아가게 되는 거죠.
저는 새 팀을 만들 때마다 워크숍을 합니다. 워크숍 때마다 남들이써줬으면 하는 자신의 장점을 말하게 합니다. “나 C#을 정말 잘해. 나에게 물어봐줘" C# 고수가 동료라니 누가 반기지 않겠습니까? 약점도 말하게 합니다. 그런데 약점만 말하라고 하면 싫어합니다. 그래서 본인 약점을 말하되, 자신의 약점을 어떤 방식으로 도와줬으면 좋겠는지 말하게 합니다. “내 약점은 자리에 앉아서 혼자 일하는 걸 좋아하는 거야. 사람들이말 거는 것을 싫어해. 하지만 중요한 일로 말을 걸고 싶으면 책상을 한두번 톡톡 쳐줘. 그럼 하던 일을 멈추고 이야기할게.” “나는 일하다 보면 너무 집중해서 옆도 안 보고 앞만 보고 가. 그러니까 그럴 땐 꼭 옆에서 너무 빨리 가는 것 같으니 잠시 멈춰서 살펴보자고 알려줘."
팀 존재 이유는 서로의 장점을 공유해서 극대화하고 약점을 보완해주는 것이므로, 서로가 강점과 약점을 알아야 합니다. 특히 약점을 공격하는 데 사용하면 안 됩니다. 약점은 당사자를 보호하고 팀워크를 유지하는데 사용해야 합니다. 팀 생성 초기에 이 워크숍을 진행하면 빠르게 신뢰단계(규범기)로 진입해 원활히 지식을 나누게 됩니다.
</blockquote>
과거에 스타트업 얼라이언스에서 강연 하셨던 영상을 본 적이 있는데, 정말 정말 도움이 컸던 영상이었다.
<a href="https://youtu.be/fHyTA-UIcqs">[스타트업얼라이언스] 개발자가 갖추어야 할 9가지 기술 - 박종천 넥슨 부본부장 - YouTube</a>
이 영상을 보면서 느낀 바로 개발자가 갖추어야 할 역량에 대한 부분이었다면, 이 책에서는 역량 뿐만 아니라 전략 그리고 향후 매니지먼트 영역 그리고 그 이상의 역할에 대한 설명을 하고 있는 책인데, 개발자 관련해서 이런 책은 본적이 없다.
그리고 일단 확실히 재미난 사실은 뛰어난 개발자는 명확함을 늘 지닌다고 하는데, 박종천님께서 쓰시는 글에는 명확함만이 있다.
군더더기가 전혀 없다는 것이 정말 책의 몰입감을 높이는 첫번째라고 할 수 있고, 확실하게 알고 있는 명확함을 기반으로 커뮤니케이션에 대한 영역에 대한 부분, 영어 학습에 대한 부분은 반성을 좀 많이 하게 되었다. 앞으로는 최대한 영어를 노출 시키는 훈련을 해야겠다고 생각 했다.&nbsp;
내가 알지 못하는 시니어 개발자, 리드 개발자 그리고 그 너머의 영역에 대해서는 미지의 세계였는데, 그에 대한 방향성을 명쾌하게 알려주신 것 같다. 물론, 그 길이 나에게 늘 정답일리는 없겠지만, 좋은 지침이 될 수 있는 비법서 같은 책이었다.
쉽게 읽히는 책이지만, 개발자에게 연차가 쌓일 수록 부담을 느낄 수 밖에 없는 영역들을 잘 설명 해주고, 내가 못하는 것과 잘 하는 것을 분리하고 그 것들을 팀원과 잘 공유하며 시너지를 내는 어떤 선순환의 고리를 잘 설명 해주신 것 같다.
책을 읽으면서 팀원들과 팀장과 이야기 하면서 읽고 싶기도 했다. 다 읽은 뒤 열심히 프로세스를 정립 하기 위한 토론도 해야겠지만, 그게 가능한 팀이 있고 불가능한 팀이 있다는 사실을 나는 안다. 현실은 냉혹하며, 늘 이상향 속에 내가 있지 않다.
내가 모르는 세계도 많을테고, 나는 회사를 1번 경험해본 사람이라서 다양함을 나는 모르고 우물안 개구리라는 것을 인정한다. 다만, 내가 속한 곳을 최대한 좋게 바꾸려는 노력은 나에게 어떤 제 2의 업무라고 생각한다.
내가 늘 인생 코드를 작성 하는 구루의 반열이라면, 사실 그런 경지는 경험해보지 못해 모르지만, 그때에는 아마 더 군더더기 없는 커뮤니케이션과 코드를 짤 것이라 생각 한다. 아마 그때는 더 수월하게 업무를 둘 다 해낼 수 있겠지 ? 라는 생각을 하곤 한다.
하지만, 지금은 아직 아니기에 나는 더욱이 팀과 팀원들의 시너지를 위한 방법을 고려 해야 하는데, 나는 이게 맞다고 늘 생각 했었는데, 누군가에게는 그게 늘 정답이 아니 였을 것이란 생각을 나는 못했다.&nbsp;
그래서 앞으로는 조금은 힘을 빼고, 세상 밖에서 공부를 좀 해야겠다고 생각 했다. 그리고 나도 스스로 공부를 좀 많이 하고 만들어보는 훈련을 해야 하는 의도적 수련을 해야겠다고 다짐하게 되었다. 나는 늘, 컴퓨터에 대한 지식을 몰라도 되고 하다보면, 경험하게 되는 날이 오면 공부 하자 생각 했던 사람인데, 시간이 지나고 보니 공부 할 수 있을 때 열심히 하는게 남는 것이라는 결론을 얻었다.
늘, 이건 왜 동작하지? 이건 내부가 어떻게 되어 있지? 고민만 하고, 알아보지 않고 추측으로만 개발을 해왔다. 물론 가끔 정 궁금하면 소스 코드를 보기도 했다. (오픈소스의 강점이 바로 이것이다. 투명성) 그런데, 추측만 하고 제대로 실험을 해보진 않으니 지식의 깊이가 깊어지지 않는다.
시간을 허비한 것에 대한 아쉬움은 있으나, 나 같은 개발자도 어딘가에 또 있겠지 하고, 생각 하면서 조금은 결을 바꿔서 앞으로는 그때 그때마다 공부 하는 습관을 들이기로 다짐 하게 된 계기가 바로 이거다. 나에게 몇년 남지 않은 시간이다.
이 책에서 말하듯 성장기 10년이고, 총 30년이라 가정 할때 나는 이제 4년 정도면 시니어 계층 개발자라는 것을 의심 할 여지 없이 그 계층으로 가야 한다. 물론, 연차가 시니어를 보장 하거나 대변하는 것은 아니지만, 업계가 그렇다. 평균적으로 그렇기 때문에, 나는 어느 정도 사람들을 리드 하고, 프로젝트를 수행 해야 할 역량이 있어야 한다.
그럴려면, 기술력은 기본이고, 커뮤니케이션 능력과 리딩에 대한 자세가 필요한데, 변명 아닌 변명으로 늘 급한 일정 탓을 하며, 기술력을 연마 하지 않은 부분이 요즘들어 잠을 설치게 하는 원인이다. 어쩌면 나는 몇년 전부터 의미를 잃어버린 사람 같다.
열정적이던 개발자에서 시니컬 해진 개발자가 되어버린 것 같았다. 책속에 나오듯 내가 첫 사용자가 되었을때, 개선점들을 제안 했는데 생각보다 기획의 영역은 굳건하므로 내가 개발 하더라도 스펙이 바뀌지 않는다. 그러면서 차츰 식어버린 날 탓하면서도, 나는 이제 정해진 것만을 수용하는 개발자가 된 것이다. 차츰 차츰 그렇게 낡아져 갔다.
요즘의 트렌드는 정말 빠르고, 봐야 할 언어, 프레임워크, 라이브러리, 패턴, 아키텍처등 수 많은 내용들의 범람이다. 되려 하나만 해야 한다면 모르겠으나, 하나만 하면 괜시리 뒤쳐지는 느낌을 또 받는다. 그렇다고 또 여러개를 하자니 시간은 없고, 쉽게 지친다. 그래서 1년에 한 가지 혹은 두 가지 정도의 기술만 연마해 보기로 했다.
늘, 고민은 많지만, 이 책을 읽으면서 어떤 개발자로의 삶에 대한 고민이 줄었다. 그 만큼 내 무수히 많던 고민을 굉장히 명확하고, 군더더기 없게 만들어준 책이라 가끔 읽으려 한다. 
</div></div>

Seungdols Company

seungdols

좋았던 부분이 워낙 많아 다 담을 수는 없지만, 크리티컬 싱킹이 나에겐 정말 와닿는 문장이었고, 팀원간의 강점과 약점을 공유 하는 것, 리더로서 투명성을 유지 해야 하는 것들이 정말 좋았다. 경력이 10년 차쯤 되면 시니어 개발자입니다. 이때는 혼자서만 잘한다고 끝이 아닙니다. 일을 크게 만들 줄을 알아야 하고요, 다른 사람을 이끌며 일할 줄 알아야 합니다. 프로젝트를 리드하고 기술을 결정하며 점점 더 큰 일을 더 많이 하게 되는 거죠. 여기까지는 ..

개발자로 살아남기를 읽고,

댓글