SW개발과 Teamwork, 그리고 Review

거의 모든 SW개발은 팀으로 진행됩니다. 종종 혼자서 기획하고 개발, 테스트, 영업까지 모두 다하는 경우도 있기는 하지만, 이는 워낙 작은 규모의 회사에서 있는 일이고, 대부분은 팀을 이뤄서 일을 해야 효과적으로 SW를 개발해 낼 수 있습니다. 

그 팀의 규모는 2명에서부터 수천 명에 이르기까지 다양합니다.

하지만, 주변에서 대규모 프로젝트 팀을 보기란 그렇게 쉽지 않습니다. 5~6명 안팎의 소규모 팀은 아주 흔하게 볼 수 있고, Teamwork도 꽤 좋은 편입니다. 하지만, 규모가 몇 십 명만 넘어가도 효과적으로 관리를 해내지 못하는 경우가 흔합니다. 그래서 팀이 규모가 커지면 프로젝트가 오히려 늦어진다는 얘기도 있습니다.

이런 경우라면 소규모의 팀은 제대로 된 Teamwork를 갖춘 것이 아니라 워낙 작아서 서로 인간적으로 잘 통하고 서로 커뮤니케이션을 왕성하게 하면서 프로젝트를 진행하기 때문에 문제가 없는 것이고 수십 명 규모의 팀은 똑같은 방법으로 커뮤니케이션이 잘 되지 않기 때문에 문제가 많을 가능성이 더 높습니다.

팀을 이뤄서 소프트웨어를 개발할 때 가장 중요한 것은 Review입니다.

Review에 익숙하지 않은 개발자들이 모여서 개발을 하는 것은 서로 따로 개발하는 개발자들을 한데 모아 놓은 것과 별반 다르지 않습니다. 이런 팀은 개발을 하면서 서로 다른 목표를 가지고 개발을 하기도 하고, 아키텍처

에 대한 오해를 하고 통합 시 인터페이스가 안 맞고, 일정이 서로 어긋나곤 합니다.

물론 각 개발자들이 서로 개발하는 모든 내용을 다 Review하고 공유할 수는 없습니다. 프로젝트의 규모에 따라서 또, 서로의 역할에 따라서 Review하는 범위와 대상이 달라집니다. 그럼 소프트웨어 개발팀에서 리뷰를 해야

하는 것들은 어떤 것이 있는지 알아보겠습니다.

1. SRS(스펙) 작성 및 리뷰 (중요도 : 매우 높음)

제가 여러 차례 강조했지만 SRS는 SW개발에 있어서 가장 중요하며 프로젝트 기간을 단축하고 비용을 절약하는데 가장 핵심입니다. SRS작성시는 개발팀 뿐만 아니라 프로젝트의 모든 관련자와 수 차례 리뷰를 합니다. 모든 관련자가 SRS의 모든 항목을 다 리뷰하는 것이 아니고 본인들이 책임지는 부분만 리뷰를 하면 됩니다. 예들 들어 Marketer인 경우는 프로젝트 목표와 비전, 주요 기능 등과 같이 마케팅에 필요한 부분만 리뷰를 하면 됩니다. 이렇게 SRS를 철저히 리뷰를 해야 모든 관련자가 프로젝트에 대하여 동일한 생각을 가지게 되고 프로젝트가 끝

날 때까지 스펙 변경을 최소한으로 유지하게 됩니다. 또한 이런 SRS리뷰가 일상적으로 반복적으로 일어나야 자연스러운 관행으로 자리잡고, 개발자들의 분석 능력을 향상하는데도 도움이 됩니다. 참고로 SRS(스펙, 요구분서)는 SW개발에서 약 40%의 비중을 차지한다고 합니다. 

2. SW아키텍처 리뷰 (중요도 : 높음)

웬만한 규모의 SW의 아키텍처는 한 명의 머리 속에 나올 수가 없습니다. 아키텍처는 정답이 있는 것이 아니라서 생각을 많이 할 수록 좋아 질 수 있습니다. 개발자들은 설계 단계에서 이런 아키텍처 리뷰를 여러 차례 반복하게 됩니다. 그러면서 아키텍처를 점점 구체화 해나가고 개량해나갑니다. 규모가 큰 SW인 경우에는 상,하위 아키텍

처를 구분해서 설계를 하기도 하고 각 컴포넌트간에는 인터페이스만 정하게 되고 그 내부는 또 각 개발자들이 설계를 하고 리뷰를 하게 됩니다. 이 때 UML을 사용하건, Flow chart를 사용하건, DFD를 쓰던 큰 상관은 없으며 각자 익숙한 툴로 현재의 아키텍처를 가장 잘 표현할 수 있는 것으로 작성하면 됩니다. 이러한 과정 또한 선배 개발자들이 후배 개발자들에게 지식과 경험을 전달할 수 있는 좋은 기회가 됩니다.

3. 소스코드 리뷰 (중요도 : 중간)

소스코드 리뷰가 중요하기는 하지만 SRS와 아키텍처리뷰보다 중요하지는 않습니다. SRS와 아키텍처가 잘못되면 엄청나게 많은 재 작업을 해야 하지만, 소스코드가 잘못된 것은 버그로 발견되고 또, 상대적으로 쉽게 고칠 수 있습니다. 그렇긴 하지만 소스코드 리뷰는 좋은 관행이며 꾸준히 노력해서 정착해야 합니다. 소스코드 리뷰 방법은 매우 다양하지만, 저는 가장 간단한 방법은 Peer desk check을 권합니다. 소스코드 관리시스템에 Commit하기 전에 동료와 같이 리뷰를 하는 겁니다. 간단히 Diff툴을 실행해서 바뀐 소스코드를 볼 수도 있습니다. 그리고 소스코드를 등록할 때 누가 리뷰를 했는지도 꼭 기록하게 하는 정책도 소스코드리뷰를 확산하는 좋은 방법 중 하나입니다.

소프트웨어 개발에 있어서 Teamwork은 서로 사이가 좋은 팀을 말하는 것은 아닙니다. Teamwork에 있어서 서로 간의 신뢰는 중요한 요소이지만 필요충분조건은 아닙니다. 각자 전문가로서의 자신의 일들을 제대로 수행하면서 리뷰 등의 커뮤니케이션이 적절히 원활하여 동일한 목표와 비전을 가지고 SW를 개발해야 합니다.

우리는 흔히 혼자서는 일을 정말 잘하는데 뭉쳐 놓으면 삐걱대는 개발자들을 많이 보아 왔습니다. 이는 그 개발자만의 탓도 아닙니다. 서로들 Teamwork이 부족한 것이지요. 즉, 팀을 이뤄서 일하는 방법에 서툰 것입니다. 가장 좋은 방법은 제대로 되어 있는 회사에서 몇 년 일해보는 것입니다. 그런 환경이 안 된다면 SRS(스펙)리뷰부터 조금씩 활성화 해나가는 것이 좋습니다. 제대로 된 SRS(스펙)을 써보지 않는 개발자들에게는 SRS(스펙)을 쓰는 것도 큰 도전이지만, 어차피 SW를 제대로 개발하기 위해서는 피해 갈 수 있는 것이 아니기 때문에 시도를 해봐야 합니다. 

좋은 Teamwork를 갖추지 못한 개발팀에서는 아무리 뛰어난 개발자라고 하더라도 제대로 실력을 발휘할 수 없습니다.

개발자 부품화 vs. 만능 개발자

개발 프로세스를 너무 따지만 개발자가 부품화 되고 창의성이 줄어든다고 합니다.

또 분석, 설계, 구현, 테스트를 나눠서 하게 되면 부품화되고 비인간적이라고 하기도 합니다.

그래서 개발자가 이것 저것 다하는 만능의 역할을 수행하게 합니다.

투수는 공만 던지고, 골키퍼는 골만 막는 것은 부품화일까요?

이렇게 전문화되지 않고 모두 만능으로 잘하는 동네 축구를 해서 어떻게 세계적인 소프트웨어와 경쟁할 수 있을까? 잘 하고 싶어도 동네축구를 계속 하는 이유는 제대로 된 방법을 경험해 본적이 없어서 그렇습니다. 개발자가 한명인 회사나 개발자가 50명인 회사가 개발하는 방법은 크게 다르지 않습니다. 개발자가 개발 전반의 모든 일을 다 알아서 하고 프로젝트는 개발자의 역량과 의지에 달려있습니다. 

동네 축구를 벗어나기 위해서는 소프트웨어를 개발하는 전체 프로세스를 이해해야 합니다. 이에 따라서 프로세스를 체계화 하고 각 역할별 전문화된 조직을 갖춰나가고 설령 인원이 매우 적어서 한명의 개발자가 여러가지 일을 수행하더라도 업무의 구분이 필요합니다. 나중에 조직이 커지면 일을 떼어 줄 수 있어야 합니다.

만능 개발자는 자칫하면 정작 개발자로서의 가치 있는 성장에 지장을 초래할 수 있습니다. 

우리는 다르다.

"우리는 다르다"

"우리는 너무 바빠서 문서를 쓸 시간이 없다."

"우리는 고객이 요구사항을 너무 자주 바꿔서 스펙을 작성할 필요가 없다."

"우리가 개발하는 시스템의 업무는 너무 복잡해서 문서로 만들 수도 없고 개발자도 몇 년 일해야 제대로 일할 수 있다."

"우리 고객은 문제가 생기면 당장 고쳐주지 않으면 큰일 난다."

"우리의 기술은 너무 어려워서 설명할 수가 없다."

"우리 소스코드는 너무 중요해서 아무에게도 보여 줄 수 없다."

"우리 제품의 시장은 너무 경쟁이 치열해서 고객이 원하는 것은 다 들어 줘야 한다."

"우리 프로젝트는 항상 너무 촉박해서 제대로 된 프로세스를 밟을 수 없다."

"우리는 도저히 리뷰할 시간이 없다."

"우리는 프로젝트 기간이 항상 너무 짧아서 테스트는 대충하고 출시해야 한다."

"우리 시스템은 너무 복잡해서 설계자가 구현까지 하지 않을 수 없다."

"우리 시스템은 너무 복잡해서 개발자가 테스트를 해야 한다."

다들 가장 까다로운 고객을 가지고 있고, 너무 어려운 기술이고, 업무도 너무 복잡하고, 항상 시간이 없다라고 말합니다. 

이 얘기는 거의 모든 SW회사들에게서 듣는 별로 특별할 것도 없는 얘기들입니다.

결국 SW 회사들의 근본은 별반 다를 것이 없습니다. 소프트웨어를 제대로 개발하기 위해서 거쳐야 할 프로세스, 문서 작성, 리뷰 등은 크게 차이가 없습니다. Detail한 부분은 서로 다를 수 있지만, 기본 원리는 같습니다. 하지만 자신의 회사는 대단한 도전을 하는 것과 같은 착각을 하고 있는 경우가 너무나 많습니다. 오히려 제대로 하고 있지 못하고 있기 때문에 환경이 더욱 열악하게 느껴지는 것을 알고 있지 못하는 경우가 더 많습니다.

세상에 시간이 너무 넉넉한 SW프로젝트는 거의 없습니다. 

세상에 마음 착하게 문제 해결을 개발회사가 원하는 만큼 넉넉하게 기다려 주는 고객은 거의 없습니다.

대부분의 회사가 다루고 있는 기술은 크게 특출 날 것도 어려운 것도 별로 없습니다. 대단히 소수의 SW회사들만 그런 어려운 기술을 다루고 있습니다.

결국 현재의 문제를 자신의 부족함에서 찾지 않고 환경의 열악함으로 돌리는 것은 나아질 수 있는 기회를 잃어버리는 결과를 초래할 수도 있습니다.

정말 열심히 일하고 있는데, 개발은 점점 복잡해지고, 야근은 점점 늘어가고, 고객의 요구는 점점 까다로워 진다면 내부를 돌아봐야 합니다. 회사가 제대로 SW를 개발하고 있는 것인지 심각하게 고민해 봐야 합니다.

거짓말쟁이 개발자

의도적이던, 의도적이지 않던 간에 개발자의 거짓말은 개발자 스스로의 신뢰를 떨어뜨릴 뿐만 아니라 회사의 중요한 결정을 잘못된 방향으로 이끌기도 합니다.

거짓말쟁이 개발자들은 거짓말을 하면서도 본인이 거짓말을 하고 있다는 것을 자각하지 못하거나 온갖 합리화를 할 수 있는 핑계로 무장을 하여 진실을 말하고 있는 자기 최면에 빠지기 도합니다.

사람들은 계속 속아주지는 않습니다. 결국 신뢰도 떨어지는 개발자가 될 수 있습니다.

모르는데 아는 것처럼 말하는 것

이름 한번 들어본 기술 또는 샘플 코드 한번 돌려본 것 가지고 아는 척하는 경우를 흔히 볼 수 있습니다. 이때는 자신이 어느 정도 아는지 정확하게 밝혀야 합니다. "들어는 봤다", "프로젝트에 적용해 봤다", "남을 가르칠 수 있다"

중요한 의사 결정에 있어서 자신이 잘 아는 기술을 유리하게 주장하는 경우

자신이 잘 아는 기술을 계속 고집하여 자신의 지식이 계속 유용하게 하려는 주장은 흔히 들을 수 있습니다. 이로 인해서 회사가 잘못된 결정을 내리면 자칫 회사의 존폐가 위태로울 수도 있습니다. 또한 이런 개발자들은 다양한 기술을 접할 기회가 줄어들어서 결국 자신의 몸값을 낮추게 됩니다.

자신의 파워를 유지하기 위하여 그릇된 정보를 사실인 것처럼 말하는 경우

회사를 다니는 직원이라면 자신의 힘을 유지하고 키우는 것이 중요하지 않을 수는 없습니다. 하지만 이를 위하여 거짓된 정보로 잘못된 결정을 유도한다면 결국 자신의 도끼로 자신의 발등을 찍는 일이 될 수도 있습니다.

사실, 의견, 정보를 혼동하는 경우

가장 흔한 거짓말입니다. 말을 하면서도 이것이 자신의 의견인지? 공식화된 사실인지? 누구의 의견인지? 정확하게 밝히지 않는 것입니다. 이 이야기를 듣고 결정을 하는 사람들은 의견을 사실로 오해해서 중요한 의사 결정을 할 수도 있습니다. 그런 다음에 "누가 그렇게 얘기했다"라고 변명하는 것은 통하지 않습니다.

자신의 성과를 과대 포장하는 경우

자신이 개발한 SW를 마치 대단한 성과물인양 광고를 하고 심지어는 Open source를 가져다가 뚝딱뚝딱 만든 것을 자신의 창작물인 것처럼 속이는 경우도 많습니다. 자신을 전혀 홍보하지 못하는 것도 문제지만, 이렇게 너무 과대 포장하는 것은 자칫 회사도 과대 포장이 되고 결국 다른 개발자들의 시기의 대상이 되기도 합니다.

자신의 실력을 과대평가하여 불가능한 일을 할 수 있는 일처럼 말하는 경우

개발자는 자신의 실력의 한계를 잘 알아야 합니다. 자신의 실력을 뛰어넘는 일이라면 사실대로 밝혀서 회사의 지원을 받아야지, 거짓말로 일에 뛰어 들어서 프로젝트를 크게 망친다면 누구를 탓할 수는 없습니다. 이 거짓말은 마치 거짓말이 아닌 것처럼 생각되기도 하지만, 아주 흔한 거짓말 중 하나이며, 자신이 자신을 몰랐다는 핑계는 진짜 핑계일 뿐입니다.

결국 이런 거짓말들을 일삼는 개발자들은 거짓말이 또 거짓말을 낳게 되고, 적당한 핑계에 익숙해 지게 됩니다. 결국 제살을 깎아먹는 일이 됩니다. 또, 이런 개발자들이 더 대우받고 활개 치는 회사라면 같이 일하는 개발자들은 참 피곤한 노릇이 아닐 수 없습니다.

자칫하면 이런 개발자들의 많은 거짓말들이 거짓말이 아닌 것처럼 묻혀버리는데, 항상 커뮤니케이션을 할 때는 모든 것을 확실히 하여 특히 위 예와 같은 것들은 단단히 확인을 받아서 거짓말에 대한 책임을 지게 해야 항상 더 올바른 정보로 정확한 커뮤니케이션이 일상화 됩니다.

SW가내수공업

우리나라 SW회사들의 개발 상황을 보면 크나 작으나 가내수공업 형태를 벗어나지 못한 경우가 많습니다. 회사가 작을 경우에는 이런 가내수공업 형태의 개발이 큰 문제를 일으키지 않기도 하지만, 회사 규모가 가파르게 커 나가는데도 계속 그런 형태를 유지한다면 회사의 효율성은 급격하게 떨어지게 됩니다.

마치 원생동물이 군집생활을 하는 것 같은 이런 조직은 서로 같이 일함으로써 상승효과를 얻기는커녕 점점 비효율적으로 바뀌게 됩니다.

SW개발조직은 정교하게 진화된 생체조직과 같이 서로 분업이 잘 이루어져 있고 각 역할은 전문적으로 발전을 해야 하고 시스템적으로 커뮤니케이션이 원활하게 진행이 되어야 합니다. 이러한 조직을 회사가 커진 이후에 준비를 하려고 하면 이미 늦습니다. 회사가 아주 작거나 심지어는 혼자서 회사를 하더라도 조직과 시스템을 갖춰놔야 자연스럽게 회사의 성장에 맞춰서 효율적인 조직을 유지할 수 있습니다.

아직도 전적으로 각 개발자 한 명, 한 명에 너무 크게 의존을 하고 개발의 대부분이 코딩이며, 프로젝트의 성패는 소수의 개발자에 달려 있다면 원생동물의 군집생활과 비슷한 조직이라고 보면 됩니다.

이런 조직을 효율적이고 리스크가 적은 조직으로 탈바꿈하기 위해서는 가장 먼저 필요한 기반시스템을 통해서 모든 개발 과정과 커뮤니케이션을 투명화 하면서 잘 분업화된 전문조직으로 하나씩 바꿔나가야 합니다. 물론 이 과정이 그렇게 쉬운 일도 아니고, 책보고 따라 하기도 쉽지 않죠. 그래도 일단 이 정도만 해도 상당한 효과를 볼 수 있죠. 그만큼 투명한 개발이라는 것은 대단한 변화를 가져옵니다. 그리고 나면 각 개발자들의 역량 향상인데, 이는 대단히 오래 걸리는 일입니다. 

가내수공업형태를 못 벗어난 여러 SW회사들이 미국에 진출한다고 해서 수많은 실패를 경험한 것을 잘 알고 있습니다. 동네 축구 좀 한다고, 월드컵에 나가 보겠다고 하는 것처럼 무모하게 들리기도 합니다. 물론 동네축구에도 정말 뛰어난 인재들이 있습니다. 하지만 박지성이 기회 없이 계속 동네 축구만 했다면 세계적인 선수가 못되었겠지요. 조직은 전문화가 되고 개발자는 진짜 개발자에게 필요한 역량을 키워나가고 해야만 그나마, 게임이 좀 될 수 있습니다.  

이 와중에 이를 해결해보고자 방법론들을 기웃거린다면 문제가 될 수 있습니다. 왜냐하면 방법론에서는 조직이나 시스템에 대해서는 별로 가이드를 하지 않기 때문에 엉뚱한 곳에서 헤맬 수가 있습니다. SW를 효율적으로 잘 개발하는 방법은 특별한데 있지 않습니다. 우리가 소홀히 하는 아주 기초적인 것들에 있습니다. 기본에 충실해야 할 때입니다.

시한부 프로그래머

우리나라 개발자들은 10년 후가 매우 불확실합니다.

오랫동안 프로그래머로서 일할 수 있도록 보장이 되지도 못하고, 그런 Role model을 본 적도 별로 없기 때문이죠. 그래서 5년~7년쯤 일하고 나면 미래를 걱정해야 할 시기가 도래합니다.

윗사람들은 자꾸 관리를 하라고 하고, 선배들을 봐도 15년차 개발자보다 15년차 관리자가 회사 내에서 영향력도 더 크고, 연봉도 더 높습니다.

개발이 좋기는 한데 계속 개발자로만 머물려면 미래를 많이 희생해야 합니다.

그래서 개발과 관리 양다리를 걸치기도 하는데, 결국 관리도 잘 못하고 개발도 잘 못하는 어정쩡한 상태가 계속 되기도 합니다.

SW선진국에서는 기본적으로 개발자의 Career path는 확실히 개발자냐 관리자냐 구분이 됩니다. 내가 개발자로 머물고 싶다면 관리를 하지 않고 개발자로 계속 머물 수 있습니다. 물론 그에 걸맞은 실력도 있고 기여도 해야겠지요. 보통 개발자가 연봉도 더 높고, 회사의 위기 때 짤릴 위험도 적고, 회사를 옮기기도 더 쉽습니다. 또 골치 아픈 관리를 하지 않아도 되니 흰머리도 덜 생기지요.

하지만 개발에 대한 전문성에 대한 이해가 부족한 우리나라에서는 개발과 관리의 구분을 명확하게 하지 못하고 개발을 잘하고 고참이 되면 팀장이 되고, 관리자가 되는 것을 당연하게 생각하고 있습니다. 이는 한창 잘 뛸 10년차 축구 선수에게 이제 고참이니 구단 관리도 좀 맡아 달라고 하는 것과 비슷합니다. 

고참개발자에게 관리를 맡기는 것보다 관리 전문가를 따로 뽑거나 키우는 것이 더 효율적이고 비용도 적게 듭니다. 관리를 만만하게 보고 개발자들에게 관리 일도 시킨다면 개발, 관리 둘다 망치는 일입니다.  

또한 개발자 역시 신참 때나 고참이 되어서나 코딩이 좀 빨라진 정도 가지고는 개발자로서의 신분 보장을 주장하기에는 설득력이 약합니다. 경력을 쌓아 갈 수록 단순 코딩이 아니고 설계, 분석 능력을 점점 키워야 하고 소프트웨어 전문가로서 손색이 없는 지식과 경험을 갖춰야 합니다.

하지만 결국 아무리 노력해도 회사차원에서 Career path가 보장되지 않는다면 어려운 일입니다. 회사가 그리고 경영자의 마인드가 먼저 바뀌어야죠. 멀게만 느껴집니다.

부지런한 개발자가 되라

지난번에 "게으른 개발자가 되라"는 글을 올린 적이 있습니다.

이번에는 그 반대 제목인 "부지런한 개발자가 되라"는 글입니다.

소프트웨어 개발은 대단히 섬세하고 꼼꼼한 작업입니다.

이를 어설프게 대충 접근하다가는 프로젝트도 망칠 수 있을 뿐만 아니라 본인 스스로의 성장에도 지장을 줄 수 있습니다. 다음에 몇 가지 질문에 답변을 해보시죠.

• IDE에서 제공하는 편리한 Wizard를 이용하지 않으면 개발이 어렵다.
• 새로운 시도를 할 때 책은 안보고 일단 해본다.
• 새로운 알고리즘에 원리는 관심이 없고 사용만 한다.
• 내가 작성한 코드를 꼼꼼하게 Trace 해보지 않는다.
• 버그는 미뤘다가 나중에 고친다.
• 유닛 테스트는 잘 하지 않고 QA테스트에서 걸러줄 것으로 기대한다.
• 내가 참여하는 프로젝트만 관심이 있고 다른 부서의 프로젝트에 대해서는 전혀 모른다.
• 내가 주로 쓰는 프로그래밍 언어 외에는 배척한다.
• 항상 업무에 치여서 신기술에는 관심을 가질 시간이 없다.
• 동료들과의 지식공유에 많은 노력을 기울이지 않는다.

이 질문들에 Yes가 얼마나 많으신가요? 설마 10개는 아니겠죠.

질문들이 직접적인 관계는 없는 것 같지만 개발자가 단순히 Output만을 내기 위해서만 일을 해서는 안되다는 메시지를 담고 있습니다. 

너무 편리하게 일하려고 하고 원리에 소홀하면 개발자로서의 기술적인 깊이를 다질 수가 업습니다. 또 자신의 코드를 꼼꼼하게 검사하는 습관을 들이지 않으면 항상 버그만 많이 만들어 내는 개발자로 낙인 찍힐 수 있습니다. 또한 다른 부서의 프로젝트에 대해서도 관심을 많이 가져야만 지식과 경험의 범위가 넓어지고, 회사 내에서도 기술적인 영향력을 지속적으로 확대해 나갈 수 있습니다. 또한 다른 부서의 개발자들에게 도움도 줄 수 있습니다. 

따라서 10년 이상의 경력을 가진 개발자인데 아직도 자신의 팀의 프로젝트에서 게다가 코딩만 열심히 하고 있다면 정말 똑똑하게 부지런한 개발자는 아닙니다. 이런 개발자들이 주는 Value는 신입사원에 2,3배에 불과합니다. 당연히 연봉도 많이 받을 수가 없죠. 10년 경력 이상이라면 적어도 타 부서의 프로젝트의 다양한 Review session에 참여하여 기술적인 결정에도 참여를 하고 전사적인 기술 Roadmap이나 의사결정에 참여할 수 있어야 합니다. 물론 회사 규모에 따라서 그 정도는 약간씩 달라지지만 아직까지 자신의 팀에만 머물러 있어서는 안됩니다.

요지는 부지런해도 좀 Smart하게 부지런해야 한다는 것입니다. 코딩에만 몰두하지 말고 본인의 지식과 경험을 좀더 깊게 좀더 넓게 하기 위해서 꾸준히 부지런을 떨어야 합니다. 그래야 10여년 후에 연봉 1억을 받아도 아깝지 않은 개발자가 될 수 있습니다.