프로그래머의 14가지 성격 유형

등록일: 06.10.2021 14:26:15  |  조회수: 1288
개발자들은 종종 방 안에서 유일하게 제정신을 가진 사람이 자신이라고 생각하곤 한다. 그러나 이것 역시 임상적으로 정신 이상 증상 중 하나다.

어떤 개발자의 성격은 그대로 방치할 경우 프로젝트 진행의 장애물이 되거나, 더 나쁜 경우 다른 사람에게 함께 일하고 싶지 않은 사람으로 인식될 수 있다.

필자가 이 분야에서 오랜 기간 일하면서 겪은 바로는 이러한 성격은 14가지로 분류된다.

사실 필자 역시 이러한 성격들 중 여러 가지에 해당되는 행동을 한 적이 있고, 이런 성격을 가진 사람을 알고도 채용한 적도 있다. 개발자의 성격이 어디 가겠는가.


개발자 유아독존

뛰어난 소프트웨어가 한 사람의 작품인 경우는 거의 없다. 사용자도 있고, 테스터와 홍보 및 마케팅 담당자도 있다. 그러나 개발자 유아독존형은 자신이 오스카 시상식에서 상을 받는 배우라면 이 사람들은 배우가 수상 소감에서 감사 인사를 전하는 '소소한 주변인' 정도라고 간주한다.

이들은 보편적인 대우로는 만족하지 못하며 제멋대로 행동해야 직성이 풀린다. 사실 경영진의 누군가는 이들의 불평을 듣고 일을 하도록 이끄는 데만 업무 시간의 절반 정도를 써야 한다. 개발자 유아독존형이 새로운 기술을 습득할 때마다 관리 부담이 가중된다면 기술이 조금 떨어지는 사람으로 대체하는 한이 있더라도 회사에서 내보내야 할 시점일지도 모른다.

록 스타

일반적으로 이 유형은 HTML과 자바스크립트, 어쩌면 PHP 정도까지 다루는 정도의 실력을 가졌다. 그러나 이들의 자부심은 그야말로 매디슨 스퀘어 가든에서 방금 공연을 끝내고 기타를 내려놓은 록 스타급이다. 15분이 지나 그 자부심이 무너지는 모습은 결코 아름답지 않다.

'마지못해' 프로그래머

어떤 부모는 자식에게 의사나 변호사를 종용하는 대신 소프트웨어 개발자가 되도록 이끈다.

이것이 잘 통할 때도 있다. 그러나 제대로 풀리지 않았을 때, 가여운 이들의 자식은 적성과 무관하게 자신이 하고 싶지 않은 일을 하면서 인생을 낭비하지 않을 수만 있다면 35도 무더위 속에서의 육체 노동이든 뭐든 하고 싶다는 생각을 하며 창 밖을 응시하는 신세가 된다.

이들은 대부분 그저 그런 결과물을 내놓고, 매일 오후 4시 55분에 칼퇴근한다.


성스러운 사제

이 사람은 스스로 기술에 심취하며, 'regex', 'SOAP', '비동기 메시징', 'n-티어 아키텍처', 'CORBA'와 같은 용어가 난무하는 신성한 기도문을 입에 달고 살지 않는 불운하고 능력이 떨어지는 개발자들을 보면 참지 못한다.

성스러운 사제는 동료 성직자급 인물의 의견에만 귀를 기울이며 기회가 될 때마다 '기술 초보자'들에 대한 경멸감을 표현한다. 코더로서는 뛰어날지 몰라도 고객과 멀리 떨어진 벽장 속에 가두어 두어야 할 유형이다.


프로세스 구루

시간이 날 때마다 최신 기술 방법론에 대한 책을 독파하는 사람이 있을까? 프로세스 구루가 바로 그런 사람이다. 이들은 스크럼, XP, RUP, 크리스탈, PSP, TSP, 그리고 COCOMO에 대해 나머지 조직원 전체를 합친 것보다 더 많이 안다.

구루는 오로지 소프트웨어를 만드는 과정에만 관심을 두며, 그 과정의 결과물에 대해서는 전혀 신경 쓰지 않는다. 회의 때마다 구루는 '지금 회사에서 에자일 방법론이 어떻게 잘못 실행되고 있는지' 설명하려 들고 더 많은 에자일 교육의 필요성을 거들먹거리면서 강조한다. 항상 그렇지는 않지만 공인 스크럼 마스터(Certified Scrum Master) 자격을 보유했다면 프로세스 구루로 의심할 만하다.

'퀴즈' 챔피언

널리 알려지지 않은 소소한 분야에 대한 전문가인 이 개발자는 업무적 측면에서 유능할 수도 있고 그렇지 않을 수도 있지만 언제든 필요한 지식의 일부를 항상, 다소 애매하게 소유하고 있는 사람이다.

 메모리 모델 스펙에 대한 변경 전후 자바 작업의 '휘발성'에 대한 세부 지식도, J보스 AS 4.2.3 구성을 튜닝에 대한 심층적인 지식도 갖춘 이 '퀴즈' 챔피언은 가치 있는 자산이다. (적어도 1년에 두 번 정도는)


지옥에서 온 힙스터 해커

이 유형은 보통 이렇게 말을 하곤 한다. "모든 소프트웨어를 하스켈로 다시 써야 합니다. 그래야 코드가 아름답기 때문이죠. 비용은 상관 없습니다! 방금 제가 하스켈이라고 했나요?

하스켈의 시대는 이미 지났습니다. 단순한 클로저(Clojure)가 대세입니다. 버그? 기능? 그런 사소한 것에 신경 쓸 시간은 없습니다. 실론(Ceylon)으로 완전히 새로운 아키텍처를 구축합시다!"

아키텍처 우주비행사

이 개발자는 복잡성을 사랑하며, 적어도 자바 애플리케이션 서버, 여러 개의 메시징 큐, SOAP 기반 웹 서비스와 분산 트랜잭션, 더불어 네이티브 C++를 사용한다.

계층 분산 시스템까지 필요한 수준의 문제가 아니면 관심조차 두지 않는다. 비잔틴 양식에 비견할 만한 아키텍처를 설계하지 않을 때는 WS-* 스펙 또는 CORBA 매뉴얼에 푹 빠져 지낸다.


종종 지옥에서 온 힙스터 해커와 손잡고 얼랭(Erlang), 스칼라(Scala) +아카(Akka), Node.js, 그리고 하스켈의 조합으로 구축되는 새로운 분산 시스템을 구상하기도 한다.

우주비행사는 프로젝트에 할당된 시간 중 적어도 절반은 UML 다이어그램을 그리고 아키텍처에 살을 붙이는 데 사용한다. 이들의 신조는 'GoF 책에 나온 패턴의 7/8 이상을 사용할 때까지 프로젝트는 결코 완성된 것이 아니다' 정도 될 것이다.


불안정한 전도사

이 사람은 전체 시스템을 설계했지만 사람들이 새로운 제안을 내놓으면 위협을 느낀다. 기본적으로 내 아이디어는 좋고 당신들의 아이디어는 나쁘다. 그 아이디어를 내 아이디어로 재포장할 때까지는.

코드 시인

시인의 코드는 우아하고 디자인 패턴에 완벽하게 부합한다. 코드 시인은 회의 시간에 무한정 시간을 끌고, 마감 시한 초과 또는 다른 사람들의 불편한 표정을 전혀 인지하지 못한다.

클라우드 광신도

이 성격 유형은 분산 컴퓨팅에 대한 8가지 오해를 들어본 적이 없거나 믿지 않으며, “S”, “L”, “A”라고 불러주면 “SLA”라고 쓰지 못한다. 그러나 사바나의 사자가 가젤을 쫓듯이 최신 유행에 집착한다.

클라우드 광신도는 보안, 지연, 네트워크 중단, 데이터 상호 운용성, 벤더 종속 또는 SaaS 벤더의 장기적인 운영 능력 등에 개의치 않고 경쟁적으로 모든 것을 클라우드로 옮긴다.


빨리 한몫 잡는 데만 혈안인 SaaS 서비스라도 결코 해킹된 적도, 사용자 이름과 이메일 주소, 암호화되지 않은 비밀번호를 유출한 적도 없다는 굳건한 믿음으로 두 다리 뻗고 편히 잔다.

러시아 범죄 조직이 모든 직원의 신원을 확보해 이를 판매하고 있음을 여러분이 미처 알아채기 전에 이들은 새 회사로 옮겨갈 것이다.


전통주의자
“자바와 오라클 DB 외에 다른 것이 필요한가?" "절대적으로 웹스피어에서 애플리케이션을 실행해야 한다.” “노드 간에 메시지를 전송하고 싶다고? XML 스키마를 준비해야겠군.”

극단적 전통주의자
이들은 자바가 너무 새로운 기술이라서 아직 프로덕션 용으로는 검증되지 않았다고 생각하며 AS/400, RPG, SEU를 사용한 개발 작업을 선호한다. 업무 시간의 대부분을 VAX가 기술의 정점이었고 PC는 아직 태어나지도 않았던 자신의 젊은 시절에 대해 이야기하며 보낸다.

브레드보드와 트랜지스터를 사용해 자신의 첫 컴퓨터를 만들었고 지옥에서 온 힙스터 해커(극단적 전통주의자의 영원한 적)에게 “자네도 알다시피 Node.js 아이디어는 원래 70년대 SNOBOL에서 개발된 것이지”라고 상기시켜주거나 “하스켈은 여러 측면에서 덜 순수하고 질 낮은 LISP일 뿐이야” 등의 거침없는 말을 쏟아낸다.

사유 기술의 사제
이 유형의 두드러진 특성은 모든 솔루션은 퍼포스, 웹스피어, AIX, 오라클과 같은 듬직한 브랜드의 사유 도구를 사용해야 한다고 주장한다는 것이다. 마이크로소프트, IBM 또는 그 동급 기업이 만들지 않은 것은 모두 쓰레기라고 생각한다.

위에 나온 성격 중 얼마간 본인에게 해당되는 것이 있다면 그나마 자기 성찰을 통해 어느 하나로 정형화되는 사태를 피한 사람일 것이다. 위 성격 중 본인에게 해당되는 것이 전혀 없다고 생각된다면, 함께 일하는 사람들은 거의 틀림없이 저 중에서 여러분과 정확히 일치하는 유형을 찾아낼 수 있다고 보면 된다.

훌륭한 소프트웨어는 한 사람의 노력으로 만들어지지 않는다. 가장 먼저 해야 할 일은 본인이 모든 것의 중심이라는 생각을 버리는 것일지도 모른다.

<출처 : CIO KOREA>



이민법

사람찾기

상법 · 소송