난 현재 개발 생활만 10년 물론 내세울만한 기술은 없다.

그러나 누구나 느끼듯 현실은 10년차 개발자가 되어 가다보면 개발 보다는 다른 것을 원한다.
현재 회사에서 요즘 주로 하게 되는것이 고객과 기술 미팅을 하고 필요한 설계 그리고 개발을 한다. 요즘 외부에 업무 미팅을 많이 하다 보니 스스로 한계점을 느낄때가 있다. 기술적인 한계점이야 검색하면서 책을 뒤지면서 공부를 하면 풀리는 부분들이 대부분이지만 설계에 있어 어떤것이 더 나은 방법인지 내가 접하지 않은 환경이면 어떻게 풀어야 할지 한참 고민 할때가 많다. 그리고 이것을 어떻게 정리하여 개발팀에 같이 공유를 해야 하는지..

정리한 문서를 던져 주었을때 그 문서만으로 대부분 이해 할 수 있게 할 수 없을까 하는 부분들이 가장 큰 어려움이다. 그러다가 우연히 접하게된 '아키텍트 이야기'(저자 : 야마모토 게이지)

이책을 읽으면서 내가 생각했던 단순한 아키텍트(즉 고객의 요구 사항을 듣고 전체적인 그림을 그리고 프로세스 설계를 하는)가 아니란 것을 알게 되었다.

이 책에서 아키텍트의 정의를 다음과 같이 내린다.

아키텍트는 '어떻게 만드는것이 올바른가'를 결정하는 결정권 자이다. 그리고 설계와 구현에 대한 스페셜리스트이고 동시에 시스템에 대한 다각적인 관점을 겸비한 제너럴리스트이다.

초기 이부분에 대한 정의를 보고 나를 되돌아 보게 되었다. 난 설계와 구현에 대한 스페셜 리스트이지도 않고 많은 시스템을 접해 보지 않았기에 다각적인 관점을 가지고 있지 않다.
여기서 한번의 좌절을 느낀다... 이후 아키텍트의 일을 예를 들어 아주 쉽게 설명 되어 있었다. 그리고 느끼는 부분은 아키텍트의 일이 정말 재미 있다 라는 것과 프로젝트에서만큼은 중추적 역활을 하는 사람이라는 것을 느끼게 된다.

즉 아키텍트는 단순히 다양한 지식만이 아닌 프로젝트 구성원에 대한 성격 및 스킬 레벨등 다양하게 파악하여 아키텍쳐를 구성 하여야 하며 또한 이 구성원들 사이에 중심축 역활이 필요 하다는 것이다.(솔직히 현재 나로선 정말 힘든 부분들이다..)

현재 IT 개발자들의 현실을 보면(저자가 일본사람인데 내용을 보면 일본이나 우리나라나 딱히 차이는 없다.) 어느정도 개발 년차가 되면 회사내에서 개발자가 아닌 다른 것을 원한다. 그것이 영업이던 PM이던 관리자던... 또한 현실적으로 어떤 회사던 아키텍트만 하는 사람을 원하진 않는다. 아키텍트 + PM등 슈퍼맨을 원한다. 그렇지 않으면 도태가 되는 것이 현실이다.

이 글을 보는 개발자 분들도 한번 이책을 보라고 권하고 싶다. 아키텍트에 대한 설명을 재미있게 쉽게 설명을 했지만 그외에 프로젝트 진행에 대하 세분화하게 분업화 시켜 놓은 부분에 다른 무언가를 느낄 수 있지 않을까 한다.

최고의 개발자? 최상의 개발? 과연 이것이 어떤 의미를 내포 하고 있을 것일까? 스킬 면에서 최고가 진정 최고의 개발자일까? 엄청난 언어 사용 기술을 가지고 있다는 것은 최고의 코더이지 최상의 개발자는 아니라는 것이 나의 개인적인 생각이다.

다년간 개발업무에 있던 나는 여러종류의 개발자를 보았다. 정말 스킬면에서는 대단한 엔지니어다라는 직원이 있었는데 나는 처음부터 지금가지 그사람을 대단한 코더라고는 생각하지만 최고의 개발자라고는 생각하지 않았다. 이유는 이렇다. 그 사람에게 JOB을 주면 코드 옵티마이제이션 코드 디자인 패턴 이런것은 나무랄때 없다. 그러나 두가지의 문제가 있다. 보통 공통작업을 많이 하는 요즘 개발 추세에서 자기만의 툴과 자기만의 방법을 사용 한다는 것이다. 즉 그 사람이 작업을 하지 않으면 그 코드를 이해하는데 그리고 새로운 툴에 대한 이해하는데 시간이 너무 많이 걸린 다는 것이다. 팀 작업전에 분명 당신이 작업 한 부분 다른 사람이 받아서 작업 할 수 있으니 VC를 사용 하시오 하면 그 엔지니어는 난 MS가 싫어 다른 툴 쓸레 하면서 처음 듣는 공개용 윈도우 라이브러리를 사용 하였다. 그 당시 클라이언트 부분은 그 사람의 작업이었고 난 서버 단을 맞고 있었다. 이후 이 프로젝트에 다른 사람이 투입 되고 그 사람은 다른 일을 하게 되었는데 새로 투입된 사람은 경력이 많지 않은 엔지니어였다. 문제는 경력이 많지 않은 이 사람이 그 라이브러리를 이해하는데 더 많은 시간이 투자 되었다는 것과 해당 라이브러리에 대한 도움을 받을 수 있는 환경이 많지 않았던 것이 문제였다. 결국 그 사람은 자진 퇴사하고 프로젝트는 홀딩 되는 사태가 발생을 하였다.

또 다른 문제는 이 사람의 개발자적 마인드이다. 급해서 도움을 요청 하면 귀찮아 하고 윗 분들한테 요청을 해서 그 사람에게 작업을 하게 하면 결국 그 코드는 버그 투성이의 엉망인 프로그램이 나온다. 그리고는 나머진 알아서 해 라고 하는 자세적 문제다. 시간이 촉박하여 요청을 한건데 그 이상의 시간이 걸리는 것이다.

다른 케이스를 보자면 한 개발자는 무언가 JOB을 주면 그 자리에서 바로 그거 어떻게 해야 되요? 라는 질문을 하면서 입버릇 처럼 실력이 없어서 라는 말을 하는 사람이 있다.
그러면 난 "야! 넌 찾지도 않고 먼저 생각도 안하고 바로 묻냐? 계속 그런식으로 하면 난 절대 안알려줘" 라고 말을 한다. 스스로 하려고 하지 않고 의타적으로 이렇게 이렇게 해 라는 답을 마냥 기다리는 경우인 것이다.

위 경우처럼 극단적인 경우가 될 수도 있으나 50보 100보 차이로 많은 사람들이 이런 경우가 아닐까 라는 생각을 한다. 내가 생각하는 최고 개발자는 스스로 생각하는 개발자라고 생각을 한다.

즉 어떤 JOB이 떨어 졌을때 코드를 바로 생각 하는 것이 아니라. 이 기능은 어떤 식으로 적용 되어서 최종 어떻게 결과가 떨어질 것인가? 라는 스스로의 생각을 적립 하여 그것을 코드로 만들어 내는 것이 아닐가 생각한다. 코드를 만들때 스킬이 중요 한건지 정작 중요한 스스로 최상의 아키텍쳐를 그려내는 것이 진정 개발자의 최고의 스킬이자 최고의 능력이 아닐가 생각을 한다. 그리고 자기가 생소하다거나 또는 하기 싫은 개발이라도 자기에게 맏겨 졌으면 프로의 정신으로 깔끔하게 마무리 짓는 것 또한 최고의 개발자에 대한 덕목이라고 생각을 한다.

이제 막 프로그램을 시작하는 개발자들은 명심 해야 할 것입니다. 최고의 개발자가 되는건 VC, VB등 뭐 이런것이 먼저가 아닙니다. 학교 수업시 이론적으로 플로우차트 그려라. 아키텍쳐 그려라, 등 하품나는 이야기를 많이 듣고 보셨을겁니다만. 최고의 개발자는 앞에 언급한 것들을 잘한다면 80%는 된것입니다. 그리고 자기 작품(난 개발자가 만든 프로그램을 작품이라고 생각한다)에 대한 애착을 가지십시오. 하다가 하기 싫다고 또는 재미 없다고 그만 두거나 대충 하지 말기 바랍니다.

최고의 개발자는 프로입니다.

덧붙임..