레이블이 사람과 기술인 게시물을 표시합니다. 모든 게시물 표시
레이블이 사람과 기술인 게시물을 표시합니다. 모든 게시물 표시

2009년 3월 26일 목요일

밥그릇을 지키려는 처절한 몸부림(기생충 개발자)

자신이 작성한 소스코드를 숨김으로써 자신의 밥그릇을 지키려고 애쓰는 개발자들이 상당히 많습니다.

이런 개발자들의 특징은 자신이 작성할 소스코드는 정말 어렵고 복잡하다고 광고를 하고, 소스코드관리시스템에 등록하는 것을 거부하거나 코드리뷰를 기피합니다. 그리고 철저히 문서와 주석 없이 코딩을 하며 심지어는 소스코드를 비비 꼬아서 분석하기 어렵게 만들어 놓기도 합니다.

개발자들의 이러한 행동은 단기적으로는 자리보존에 도움이 될지 모르지만, 스스로의 발전을 저해하고 결코 오래가지 못할 것입니다.

또한, 이러한 개발자들이 한두 명만 있어도 회사는 큰 시한폭탄을 안고 있는 것과 마찬가지입니다.

저는 직업상 수많은 개발자들을 만나기 때문에 이런 개발자가 정말로 많고 웬만한 소프트웨어 회사에는 꼭 몇 명씩 있다는 것을 잘 알고 있습니다. 실제로 수년 전 알고 있던 한 회사에서는 개발자가 암호 같은 소스코드를 잔뜩 남겨놓고 인수인계도 하지 않고 퇴사를 했는데, 소스코드관리시스템을 사용하지 않았기 때문에 개발 History도 하나도 없고, 스펙서도 설계서도 없고, 소스코드는 주석도 하나 없이 깨끗했으면, 혼자 다루던 소스코드라서 이를 알고 있던 개발자는 하나도 없었습니다. 물론 코드리뷰도 안 했었지요. 그래도 회사에서 가장 뛰어난 개발자라고 추켜줬었는데, 달랑 소스코드만 남은 상태에서 회사는 위기를 맞게 되었습니다. 이런 스토리는 너무흔합니다. 대부분 비슷한 얘기는 한 두개씩 알고 계실 걸요?

대부분의 별것도 아닌 소스코드라 하더라도 이렇게 망쳐 놓은 상황이라면 유지보수하기가 정말 어려운 상황이 됩니다. 이렇게 회사의 피를 빨아먹고 다른 곳으로 옮겨 다니는 "빈대형 개발자"가 있는 반면에 회사가 망할 때까지 회사를 숙주 삼아 오랫동안 고혈을 빨아먹는 "기생충형 개발자"도 있습니다.

이러한 개발자는 회사도 어렵게 하고, 본인 스스로도 미래를 지워버리는 것과 같습니다. 개발자는 이렇게 자신만 아는 소스코드를 생산함으로써 자신의 밥그릇을 지키기보다는 소프트웨어 전문가로서의 실력을 키우는데 집중해야 할 것입니다. 그래야 회사도 살고 본인의 미래도 키워집니다.

그럼 이런 개발자가 있는 회사는 어떻게 해야 할까요?

당장 짤라 버리십시오.

그럼, 회사가 망한다구요? 그런 상황이라면 이미 시기를 놓치셨네요. 안타깝습니다. 암조직을 떼어내는 순간 본인도 죽을 수 있는 상황이 된 겁니다. 당분간은 암조직과 같이 살아야 합니다. 그리고 암조직을 떼어내어도 살 수 있도록 체력을 키우셔야죠.

회사의 개발 체계를 정립하고, 소스코드를 관리하고, 개발 문서를 제대로 만들고, Peer Review도 시행을 해야 합니다. 3년이 걸릴지 5년이 걸릴지 모르는 일이지만, 이 수밖에 없습니다. 전문가의 도움을 받으면 시간이 조금 앞당겨지겠지요. 이 동안 이런 "기생충, 빈대형 개발자"들의 엄청난 반대와 비평에 시달릴 겁니다. 당장 프로젝트가 급하다고 하기도 하고, 개발자의 창의성을 방해한다고 하기도 하고, 온갖 그럴싸한 이유를 댈 겁니다. 그럼 같이 망하는 거죠. 듣기에는 정말 그럴싸하지만 이는 자신의 밥그릇을 지키기 위한 본능적인 몸부림이라는 것을 잊으면 안됩니다. 그렇다고 대놓고 이런 개발자를 비난하면 안됩니다. 살살 잘 유도해서 새로운 체계로 끌어들여야죠. 그렇지 않아서 중간에 나가버리면 곤란합니다. 그리고 이런 개발자들에게 기회를 줘야죠.

사실 대부분의 소프트웨어 회사의 경영자들은 이러한 고비를 넘지 못합니다. 심지어는 자신의 회사가 이러한 개발자에게 피를 빨리고 있다는 것을 인식조차 못하는 경우도 많습니다. 이러한 개발자가 회사를 먹여 살리고 있다고 생각하고 성실히 일하는 보통의 개발자들은 이런 개발자보다 못하다고 생각하기도 합니다.  이런 회사야 어차피 싹수가 없지만, 이를 알고 있는데도 이미 암덩어리가 커져서 어떻게 못하는 상황이라면 각고의 노력을 해야 합니다. 혼자 어려우면 전문가의 도움도 받으세요.

개발자들을 비난하기 위해서 이 글을 쓰는 것은 아닙니다. 대부분의 개발자들은 성실히 일하니까요. 대부분의 성실한 개발자들이 이러한 개발자들에게 피해를 당하지 안았으면 하는 바램이고, 소프트웨어 업계 저변에 소프트웨어 공학이 잘 접목된 개발 방법이 퍼져서 개발자도 살고 성공하는 회사도 마구 쏟아져 나오는 미래를 기대하는 마음에 글을 씁니다. 그동안 제 글들을 읽으신 분이라면 제가 소프트웨어 개발을 사랑하고 있다는 것을 아실 겁니다.

2009년 3월 11일 수요일

자기 중심적인 사고에 갇힌 개발자

개발자들은 모든 생각의 중심을 본인으로 생각하는 경우가 흔합니다.
소프트웨어를 개발하면 모든 판단의 기준을 본인으로 하는 것이지요.

우주가 자신을 중심으로 돌고 있다고 생각하는 개발자들입니다.

적용하는 기술도 본인이 잘 알고 익숙한 것으로, 또 사업적인 관점으로 고려를 하기보다는 본인의 취향에 따라서 섯부른 판단을 하는 경우가 많습니다.
특히나 이렇게 자기 중심적인 사고방식에 꽉 막혀 있는 개발자들과는 대화조차 어려운 경우가 많습니다. 보통 고집도 센 것이 아니어서 같이 일하기 피곤합니다. 이런 개발자들이 실력이 뛰어난 것처럼 보여서 어쩔 수 없이 붙들어 두고 있는 경우가 많은데 일찌감치 팀에서 제외를 하던가 해고를 하는 것이 더 나을 겁니다.

소프트웨어를 개발하면서 벌어지는 수많은 판단과 결정은 이렇게 개발자 중심으로 이루어져서는 경쟁력 있는 제품이 나오기 어렵습니다. 무슨 DB를 쓸지, 어떤 개발언어를 사용할지, 아키텍처를 어떻게 구성할지? 또는 무슨 기능을 포함할지도 개발자가 마음대로 결정하고 해당 담당자에게 리뷰도 하지 않고 덜렁 소프트웨어를 개발해 놓으면 뒤늦게 문제들이 뻥뻥 터집니다.

개발자는 자신이 잘하는 일을 해야죠. 자신의 전문분야가 아닌 것은 다른 사람의 의견을 들을 수 있어야 합니다. 무슨 DB를 쓸지에 대한 이슈도 기술적인 이슈라기 보다는 비즈니스적인 측면이 더 큽니다. 개발자들은 이러한 결정의 순간에 자기 중심적인 사고를 버려야 합니다. 경험이 많은 개발자들은 이렇게 균형을 갖춘 사고를 하지만, 경험이 많은 모든 개발자가 그런 것은 아닙니다.

세상은 자신을 중심으로 돌고 있지 않다는 것을 알아야 합니다.

2009년 2월 16일 월요일

개발자도 문서를 잘 작성할 수 있어야 한다.

개발자(엔지니어)들이 문서를 잘 작성하지 못한다는 것은 익히 알려져 있는 사실입니다.
 
개발자에게 프로그래밍 실력이 더 중요하지 문서 작성 기술이 얼마나 중요하겠냐?라고 생각하는 사람이 있을 수도 있겠지만, 개발자가 성장할수록 문서 작성 능력의 중요도는 점점 더 커집니다.
 
문서를 잘 작성하지 못하는 개발자는 협업을 하는데 있어서 치명적인 결함을 가지고 있다고 할 수 있습니다.
 
그럼 문서를 잘 작성하는 것은 무엇이고? 문서를 잘 작성하지 못하는 것은 무엇일까요?
잘 작성되지 못한 문서의 특징을 한번 살펴보죠.
 
  • 문서의 내용이 쉽게 이해가 되지 않는다. 외계어로 작성된 것 같다.
  • 여백 없이 빽빽이 작성되어서 읽는데 너무 피곤하다.
  • 문법이 많이 틀려서 내용도 신뢰가 가지 않는다. 주어도 없고 문장의 앞뒤가 전혀 맞지 않는다.
  • 주변 얘기만 빙빙돌려서 하고 있고 핵심이 뭔지 잘 모르겠다.
  • 내가 관심있는 내용은 없고 작성자의 관심거리만 적혀있다.
  • 사용하고 있는 단어들이 너무 전문적이고 어렵다.
  • 분량이 너무 많아서 읽기 힘들고 주제 파악이 힘들다.
 
물론 개발자라면 개발에 필요한 핵심문서를 잘 작성할 수 있어야 합니다. 하지만, 이같이 기본적인 문서작성 기술도 없다면, 개발문서라고 해서 잘 작성할 수는 없습니다.
 
"조엘온소프트웨어"의 저자인 조엘 스폴스키는 개발자를 뽑을 때 글을 잘 쓰는 사람을 뽑는다는 원칙이 있다고 합니다. 글 쓰기 능력을 키우는 것은 프로그래밍 실력을 키우는 것보다도 더 어려울 수 있습니다. 그래서 아예 글을 잘 쓰는 사람을 뽑는 것이 더 합리적으로 보이기도 합니다.
 
개발자들은 문서를 잘 작성하지 못한다는 얘기는 어디서나 통하는 말이지만, 특히 우리나라의 개발자들은 단순 주입식 교육 환경 때문에 읽고, 외우는 것은 잘하지만 자신의 의견을 남들에게 쉽고 조리있게 전달하는데는 익숙하지 못합니다. 그렇다고 문서작성을 포기할 수는 없죠. 평생 혼자서 개발할 것이 아니라면 문서는 점점 더 필요하게 되죠. 아니 혼자서 개발을 하더라도 문서를 잘 작성하는 것이 필요합니다.
 
그럼 문서 작성 실력을 키우기 위해서 어떻게 해야 할까요? 역시 훈련이 필요합니다. 단순히 여러 번 작성해 본다고 되는 것이 아니라 제대로 작성하기 위해서 노력해야 합니다. 이제, 문서 작성 실력을 향상하기 위한 몇 가이드를 하려고 합니다. 그 출발점은 다음과 같습니다.
 
"문서작성 기술이 필수 기술이라는 것을 먼저 인식해야 합니다."
 
필요성을 못 느끼면 발전도 없습니다. 그리고 문서를 잘 작성하려면 다음과 같은 것을 고려해야 합니다.
 
  • 문서를 작성하는 목적은 내가 일기 위한 것이 아니고 남이 읽기 위한 것이다. 읽는 사람의 눈높이에 맞춰서 적절한 단어를 사용해야 한다.
  • 주제를 직설적으로 전달해야 한다. 문서를 읽는 사람은 친절하게 문서를 처음부터 끝까지 다 읽어 줄만큼 한가하지 않다. 주제를 먼저 전달함으로써 문서를 읽는 사람이 문서를 계속 읽을지 말지 결정할 수 있도록 해야 한다.
  • 필요한 내용을 쓴다. 문서 작성의 목적을 달성할 수 있도록 문서를 읽는 사람이 기대하는 내용을 충분히 적어야 하며 자신만 관심 있어 하는 필요 없는 내용은 쓰지 않는다. 이런 내용들은 문서의 양만 늘리고 문서의 가치를 떨어뜨린다.
  • 사실과 의견을 확실히 구분하여 작성한다. 사실과 의견의 혼동은 수많은 오해를 불러일으키게 된다. 심지어는 중요한 비즈니스에서 잘못된 결정을 유도할 수도 있다.
  • 쉬운 표현을 써야 한다. 복합문장은 이해하기 어려운 경우가 종종 있다. 가능하면 문장은 작게 잘라서 하나의 문장에 하나의 논리만 포함하도록 하는 것이 좋다.
  • 맞춤법이 맞아야 한다. 맞춤법이 틀리면 문서의 내용 및 문서 작성자에 대한 신뢰가 떨어질 수 있다.
  • 읽기 편하게 화면을 구성해야 한다. 화면에 적당한 여백을 두고 자간, 행간을 조절하고, 적절한 그림이나 표를 사용해서 문서를 읽는 사람이 지루해 하지 않고 문서의 내용을 빨리 파악할 수 있도록 해야 한다.
  • 화면 꾸미기에 시간을 허비 하지 않는다.
 
다시 한번 강조를 하지만 개발자는 문서를 잘 작성할 줄 알아야 합니다. 구슬이 서말이라도 꿰어야 보배이듯이 머리 속에 아무리 좋은 정보를 담고 있어도, 이를 문서로 잘 작성할 수 없다면, 고급 개발자는 될 수 없습니다. 꾸준히 문서를 작성하고 읽는 사람으로 부터 평가를 받아야 합니다. 문서를 잘 작성해야 한다고 깨닫는 것이 문서를 잘 작성하기 위한 과정의 시작입니다.

2009년 2월 10일 화요일

우리는 당장 써먹을 수 있는 경력 개발자 위주로 뽑아요.

언제부터인가 소프트웨어 개발자를 경력 개발자 위주로 채용하는 것이 일반화 된 것 같습니다.
물론 다른 업계도 마찬가지이지만, 당장 써먹을 수 있는 경력직을 선호하는 것은 사실입니다.

그렇게 경력직 위주로 개발자를 채용하다가 개발팀의 조직 구조가 효율적이지 못하게 변하는 경우를 종종 보게 됩니다. 소규모 개발조직이라면 어떠한 구조라도 별 상관이 없다면 일정 규모 이상의 개발조직은 각 직급별 적정한 분포를 가지는 것이 효율적입니다. 

그럼, 경력 개발자 위주로 채용을 하다가 종종 벌어지는 조직 구조의 변화의 예를 하나 들어 보겠습니다.


진화 단계설명
탄두형회사의 초기에 일반적인 조직 구조 형태입니다.
항아리형신입 개발자보다 경력 개발자를 위주로 채용을 하면서 자연스럽게 아래 부분이 줄어들게 됩니다. 또 아래 계층이 충성도가 부족하여 더 많이 퇴사를 하게 됩니다.
스페이드형항아리형이 점점 심해지면 뒤늦게 개발 조직이 비효율적으로 변한 것을 깨닫고, 신입 직원을 다시 뽑기 시작합니다. 이러면서 조직은 스페이드형으로 변합니다.
오뚜기형다시 정상적인 조직 구조로 바꾸려고 해도 비어있는 중간 계층은 쉽게 메꾸기가 어렵습니다. 즉, 회사를 이끌어가는 초창기 멤버와 고참들과 뽑은지 얼마 안되는 직원들이 개발조직의 주를 이루게 됩니다. 그래서 정상적인 분업이 이루어지지 않습니다. 일은 고참들에게 몰리고, 하층 개발자들은 기대에 못미치는 성과를 내고 있습니다.

여기서 예로든 하부 조직이나 중간 조직이 빈약한 구조가 개발에 전혀 지장을 주고 있지 않다면 특수한 개발 조직이거나 각개격파형 개발조직 구조일 것입니다. 또는 주먹구구이거나요.
대부분의 조직은 각 기능별 계층별로 업무가 나눠지며, 아래 계층의 개발자가 인원수로는 더 많이 필요하게 됩니다. 하지만 그렇지 못한 경우 그러한 Value가 낮은 일까지 고참들이 수행을 해야 하고, 이 과정에서 자연스럽게 이루어지는 교육 및 기술 전달이 이루어지지 않는 악순환이 벌어집니다. 이 과정에서 개발 팀의 생산성은 낮아지게 되고, 미래 전만도 어두워집니다.

그럼에도 불구하고 경력개발자만을 위주로 채용하는 이유는 여러가지가 있습니다.
  • 단기적인 이익을 내려는 경영층의 조급증
  • 신입 개발자를 채용해도 효과적으로 교육시킬 수 있는 교육 시스템 부재
  • 3,4년 미래도 내다보지 못하는 HR Plan
  • 주먹구구 식으로 개발을 하고 있기 때문에 체계는 필요 없고, 무조건 경험 많고 능력 있는 개발자만 필요한 경우
이미 회사를 위해서 오랫동안 헌신한 개발자들이 개발은 잘하고 업무관련 지식은 뛰어난데, 소프트웨어 전문가로서는 턱없이 모자라는 경우가 흔합니다. 오랫동안 각개격파식으로 혼자서 북치고 장구치고 하는 식으로 개발들을 많이 해왔기 때문에 이런 일들이 일어납니다. 이경우 이러한 고참 개발자들이 다른 회사로 이직을 할 경우 그 가치가 현저히 떨어지는 경우가 많습니다. 전문가로서의 역량은 부족하기 때문입니다. 자칫하면 이러한 공신들이 희생될 수도 있고, 골치덩어리가 될 수도 있습니다.

그러면 어떻게 해야 할까요? 

적어도 개발자를 채용할 때는 오늘 당장 필요해서 뽑는다는 생각만 가지고 채용하는 것은 위험합니다. 적어도 몇 년을 내다보는 채용 계획이 있어야 합니다. 그리고 계획에 따라서 항상 채용을 위한 노력을 기울여야 합니다. 그리고 이미 채용한 개발자와 미래에 채용할 개발자들의 경력 개발 계획을 갖추고 있어야 합니다. 이것만 따로 돌아가는 것이 아니고 회사의 개발 프로세스와 조직 등 모든 것이 맞물려 돌아가야 개발자도 성장을 하면서 자연스럽게 생산성이 높은 조직을 유지할 수 있게 됩니다. 사람에서 사람에게로 고참에서 신참에게로 기술과 지식이 전달되고 조직이 계속 성장하려면 기반시스템, 개발문화가 필수적입니다. 전혀 체계가 없는 개발조직이라면 지금이라도 하나씩 갖춰나가는 수 밖에는 없습니다

이것을 해결할 끝내주게 좋은 방법은 없습니다. 가장 효율적인 것부터 찾아서 하나씩 바꿔나가는 겁니다.

2009년 2월 6일 금요일

타이핑이 느린 프로그래머

대부분의 프로그래머의 타이핑 실력은 정말 뛰어납니다.
심야에 정말 빠른 타이핑 실력을 가지고 있는 프로그래머가 타이핑을 하고 있는 소리를 들어보면 음악과도 같습니다. "딱딱딱"이 아니고 "좌르르~"소리나 납니다.
이런 개발자들을 많이 봐왔죠.

그런데, 가끔 타이핑이 느린 프로그래머를 접하게 됩니다.
심지어는 자판을 보지 않고는 영어를 입력하지 못하는 프로그래머도 본적이 있습니다.

타이핑이 개발 실력과는 크게 연관이 없는 것처럼 보일 수도 있지만, 프로그래머의 무기는 키보드인데, 타이핑이 느리다는 것은 대단한 손해가 아닐 수 없습니다.

프로그래머의 일생의 수십%는 타이핑을 하면서 보냅니다. 그 시간의 10~20%는 절약하는 것은 인생의 대단한 시간 절약이 아닐 수 없습니다. 그 반대의 경우는 대단한 낭비죠.

한글, 영어 구분하지 않고, 자신의 생각이 주르륵 바로 입력이 될 수 있도록 훈련이 되어 있어야 합니다. 타이핑이 느려서 생각의 흐름이 끊겨서는 안됩니다. 더불어서 자신이 사용하고 있는 개발툴과 에디터의 단축키들을 몸에 익혀서 자동으로 단축키를 사용할 수 있어야 합니다.

혹시 자신이 타이핑이 느리거나, 마우스에 많은 의존을 하고 있는 개발자라면 타이핑 속도 향상을 위해서 연습을 해야 합니다. 

이것은 프로그래머에게는 기본의 기본의 기본이 아닐 수 없습니다.

필자의 첫번째 상용 프로그램이 타자연습프로그램이었는데, 타자연습프로그램을 이용해서 꾸준히 일정기간만 연습해도 필요한 만큼의 속도는 누구나 달성할 수 있습니다. 그렇지 않고 실무적으로 일을 하면서 자연스럽게 속도가 느는 것을 바라는 것은 자칫 자꾸 자판을 본다던지, 또는 손가락의 위치가 틀렸다던지 하는 나쁜 습관을 가질 수 있으므로, 제대로 연습을 하는 것이 중요합니다.

이 글은 대부분의 프로그래머에게는 필요 없는 글이나, 본인이 타이핑 속도가 느리거나 팀원들 또는 신입개발자가 타이핑이 느리다면 당연히 해결해야 할 것입니다.

2008년 12월 22일 월요일

개발자 5적

소프트웨어 회사의 가장 중요한 자산은 개발자입니다.
개발자는 회사를 흥하게도 하지만 망하게도 합니다.
안타깝게도 우리 주변에는 좋은 개발자보다 나쁜 개발자가 더 많습니다.
초년병 때는 대부분은 좋은 개발자이거나 좋은 개발자가 되려고 합니다.
하지만 시간이 흐를수록 주변의 환경 때문이던 본인 때문이던 나쁜 개발자가 더 많아집니다.
내가 생각하는 가장 나쁜 개발자는 다음과 같습니다.

  • 자신의 지식을 남에게 공유하지 않는 개발자
  • 다른 개발자를 도와주지 않는 개발자
  • 개발보다 정치에 관심이 많은 개발자
  • 자기 개발을 위해서 노력하지 않는 개발자
  • 경영자, 관리자, 동료와 자신을 속이는 개발자

안타깝게도 이러한 개발자는 쉽게 구분하기 어렵거나 회사가 이러한 개발자에 완전히 종속되어서 어쩔 수 없는 경우가 대부분입니다. 아무리 그렇다고 하여도 이러한 개발자가 회사를 이끌어가고 있다면 회사의 미래는 이미 정해진 것이나 다름이 없습니다.

소프트웨어 회사는 개발자들이 정보를 공유하지 않고는 정상적으로 동작하지 않습니다. 그리고 개발자들은 위로 올라갈수록 자신의 일보다는 동료의 일, 타 부서의 일에 관여를 하며 도와야 합니다. 하지만 공유 문화가 정착되지 않은 회사에서는 정보의 단절 악순환이 계속됩니다. 이러한 현상은 회사의 경쟁력을 약화시키고 개발자의 성장을 저해하며, 특정 개발자에 대한 의존도는 점점 커지게 됩니다. 따라서 실력은 부족하지만 회사에서 영향력만 커진 개발자들은 자신의 위치를 지키기 위해서 경영자와 동료를 속이며 정치에 매달리는 경우가 흔합니다. 그리고 자신이 모르는 것을 아는 척하며 심지어는 안다고 착각하기도 합니다.

이러한 문제는 착한 개발자를 뽑는다고 해결되는 것은 아닙니다.
소프트웨어 회사는 사람에 의해서만 돌아가게 되면 이러한 문제가 발생합니다. 최소한의 조직, 시스템, 프로세스를 갖추고 좋은 개발 문화를 장려하며 넓고, 장기적인 안목으로 개발팀을 가꿔나가야 합니다.  CTO가 이러한 것들을 리드하는 역할을 할 수 있습니다. 소프트웨어 회사에는 CTO가 꼭 필요한 이유입니다.

자신 스스로가 나쁜 개발자가 되어가고 있다면 한번 되돌아 봐야 합니다. 혼자서 이 굴레를 벗어날 수는 없습니다. 동료들이 같이 움직여야 하고, 회사가 도와줘야 가능한 일입니다. 필요하다면 제가 도움이 되어 드리겠습니다.

2008년 12월 19일 금요일

개발자 채용 시 코딩테스트를 하시나요?

연기자나 가수를 뽑을 때 오디션을 보듯이 개발자를 채용할 때는 코딩테스트가 꼭 필요합니다.
하지만 코딩테스트를 하지 않고 채용하는 경우가 매우 흔합니다.
이력서를 통해서 그 개발자가 과거에 참여했던 프로젝트가 무엇인지 보고 인터뷰에서 이거 저거 물어보는 것만 가지고는 개발자의 실력을 평가하기는 아주 부족합니다.
코딩 테스트는 다음과 같이 3가지 타입으로 진행할 수 있습니다.

첫째, 인터뷰를 하기 전에 E-mail을 통해서 코딩테스트 과제를 전달할 수 있습니다. 
이때는 시간이 반나절이나 하루 정도 걸리는 과제를 줄 수 있고 꽤 많은 내용을 점검할 수 있습니다.
단순히 로직 뿐만 아니라 코딩 습관, 최적화 시도, 소스트리, 빌드 스크립트 등 다양한 실력을 엿볼 수 있습니다.
1차에 끝나는 경우도 있고, 시험대상자가 너무 많으면 1,2차에 걸쳐서 1차에서는 기본적인 과제로 기본 이하의 개발자를 거르고 2차 과제에서 진짜 문제를 낼 수도 있습니다.
이 테스트의 단점은 다른 사람이 도와줄 수 있는 것입니다. 대부분의 경우 본인 스스로의 힘으로 과제를 해결하지만 실력이 좋은 사람이 도와 줄 경우 이를 확인하기 어려우므로 인터뷰 시 몇몇 내용을 확인하는 것이 좋습니다.
예) Caching 알고리즘 구현

둘째, 인터뷰를 하는 날 인터뷰를 하기 전에 코딩테스트를 하는 것입니다. 인터뷰 전에 약 한 시간 정도면 풀 수 있는 과제를 주고 코딩을 하게 하는 것입니다. 노트북을 준비해 오게 해서 인터뷰 전에 코딩을 시키고, 인터뷰 시 발표를 하게 하는 방법입니다. 실력을 적나라하게 볼 수 있는 좋은 방법 중에 하나입니다.
예) Quick sort 알고리즘 구현

셋째, 인터뷰 시 칠판에 간단한 코딩 과제를 풀게 하는 겁니다. 약 10분이면 풀 수 있는 간단한 문제여야 하고, 이 때는 개발자가 최소한 논리적인 사고를 하는지 점검할 수 있습니다. 사실 코딩 인터뷰를 시도해보면 이 10분에서도 각 개발자들이 엄청나게 많은 차이를 보입니다. 일반 인터뷰 질문으로는 확인할 수 없는 수많은 것들을 여기서 파악할 수 있습니다.
예) itoa함수 구현, strtok 함수 구현 

위 3가지 방법은 모두 효과가 있기 때문에 회사의 상황이나 규모 등에 따라서 적절히 선택을 하면 되겠습니다. 

코딩테스트는 추가 비용 거의 없이 개발자의 실력을 구분할 수 있는 좋은 방법입니다. 아주 뛰어난 개발자를 판단하기는 어려울 수 있어도 형편 없는 개발자는 잘 걸러 낼 수 있습니다.

과거의 경험에 대해서 얘기를 들어보면 경력만 보고 채용을 했다가 아주 쉬운 코딩도 믿고 맡기기 어려운 경우가 많더군요. 코딩테스트는 이러한 것을 막아줄 좋은 수단입니다.

2008년 11월 28일 금요일

소프트웨어 아키텍처는 어디에서 오는 것일까?

오늘은 아키텍처와 비즈니스의 관계에 대해서 적어볼까 합니다.
아키텍처… 비즈니스… 둘간의 무슨 관계가 있을까요?

 관계도 없어 보이고…

혹시 제품의 아키텍처를 구성하고 설계를 하시고 계시나요그렇다면 비즈니스에는 얼마나 관심을 가지고계십니까

기술은 기술비즈니스는 비즈니스 관계없다고 생각하실 수도 있습니다

결론은 말씀 드리면 "소프트웨어 아키텍처는 비즈니스에서 나온다."입니다.

 글을 쓰게  주된 이유는 많은 선임고참 개발자들이 기술에만 관심을 가지고 비즈니스에  관심이 없는 경우를 많이 봐왔기 때문입니다.

개발자는 상위 개발자가  수록 비즈니스를 알아야 합니다아키텍처에 대한 대부분의 결정은 단순히기술적인 결정이 아닙니다비즈니스를 제외하고 기술적인 결정만 있는 경우는 별로 없습니다.
지금 만드는 제품이   회사만 사용할지 100개의 회사가 사용할지 100만개의 회사가 사용할지에 따라서제품의 아키텍처는 완전히 달라집니다.

 내년에는 100개의 회사만 사용하지만  후년에는 10,000개의 고객을 가질 것이라면  달라집니다.

한국에서만  것인지아시아권에만  것인지미국유럽에도 진출할 것인지에 따라서 Localization이슈가완전히 달라지고, 1,2년은 한국에서만 팔지만추후 유럽에서도 판매할 의도가 있다면 미리 이를 고려하지않으면 안됩니다.

그리고 이러한 아키텍처 관련된 결정은 매우 중요해서 잘못된 결정이 엄청난 손실을 가져옵니다. 코드  잘못 짜고버그  만드는 것과는 차원이 다릅니다.

이러한 비즈니스적인 요소를 고려하지 않고그냥 기술적으로 기능이 동작하는 정도만 생각하고 소프트웨어를 개발하고 있다면 선임개발자로서의 자격이 부족하다고   있습니다.

따라서 선임개발자가 되면 비즈니스에 대해서 부지런히 관심을 가지고 공부를 해야 합니다. 회사 내부만 보지 말고 Global 시장이 어떻게 돌아가는지도 관심을 가져야 합니다.

아키텍트(Software Architect) 되는  걸음은 기술이 아니고 비즈니스를 알아가는 것입니다.