발자가 되기 위해 프로그래밍 기술만 있으면 된다고 생각한다면, 틀렸다!
코드를 잘 쓰는 것도 중요하지만, 일의 능률을 높이고 더 높은 연봉을 받기 위해서는 많은 이에게 자신이 누구인지 알리는 것이 중요하다. 다시 말해, 스스로를 마케팅해야 한다. 여기에서 성공적인 셀프 마케팅 방법을 소개한다.
모두의 개발자 팁 No.1 : 블로그
블로그를 개설 후 한 달에 한 번 이상 포스팅을 올려라. 블로그에 올리는 글은 꼼꼼히 리서치하고, 바보 같아 보이는 말은 하지 않는다.
농담이 아니고, 개발자들도 정말 작문 실력을 높이기 위해 노력해야 한다. 학교 다닐 때 국어 선생님이 가르쳐준 것들을 활용해보자. 글을 쓰기 전 개요를 작성하고, 서술 기법을 정하고, 문법이나 맞춤법을 확인하는 것 말이다.
그런 후에는 아깝더라도 필요 없는 부분은 잘라내 지나가는 사람이 한번 훑어만 보아도 무슨 이야기인지 알 수 있을 만큼 단순하게 만들어라. 필자의 글을 읽는 에디터도 마찬가지지만 인터넷에서는 대화문과 같은 '뉘앙스'를 완벽히 전달할 수 없다.
모두의 개발자 팁 No.2 : 오픈 소스
오픈 소스에 대한 거짓말들을 믿지 마라. 나이가 조금 어린 개발자들은 개발자가 실업자가 될 수 있었던 시절을 기억하지 못할 지도 모르지만, 경제 불황이 아주 최악일 때도 오픈 소스 프로젝트 개발자들은 빠른 시간 안에 일자리를 구할 수 있었다.
오픈 소스 코드를 만들 때 자신이 원하는 직업이 어떤 것인지를 충분히 반영하기 바란다. 필자는 가능한 한 간단한 솔루션으로 어려운 문제를 해결하려 했지만, 그간 인터뷰해 온 개발자들은, 그들의 오픈 소스 코드에서도 분명히 알 수 있었듯, 간단한 문제를 복잡하게 만들기를 원했다.
믿거나 말거나지만, 이런 시장도 형성이 되어 있으며 자신이 속한 시장을 반드시 코드에 반영시키기 바란다.
모두의 개발자 팁 No.3 : 한 직장에 너무 오래 머물지도, 너무 자주 이직하지도 마라
너무 자주 이직하지 마라. 농담이 아니다. 개발자들의 취업이 어려워지는 시절은 반드시 다시 온다. 그 때가 되면, 잦은 이직만큼 자신을 끈질기게 따라다닐 꼬리표도 없을 거다.
반면, 한 직장에서 10년 가까이 머물며 한 가지 일만 하는 것도 좋지 않다. 한 곳에 너무 오래 머물다 보면 그 일이 일상화 돼버린다. 자신의 가치를 높이기 위해서는 IBM에서 IBM식으로 IBM 스택 코드를 쓰는 것에 만족해서는 곤란하다.
필자는 개인적으로도 IBM이나 이와 비슷한 조직에서 1, 2년 이상 머무른 사람은 고용하지 않는다. 이들은 대체로 면접에서는 아주 훌륭한 모습을 보여주지만 프로그래밍 테스트에서 떨어지고 만다.
모두의 개발자 팁 No.4 : 눈으로는 새로운 것을 좇되, 실용적인 것에서 손을 놓지 마라
나이가 어린 개발자들은 화려하고 눈에 띄는 일을 좇는 경향이 있다. 필자가 가장 좋아하는 프로그래밍 언어는 루비(Ruby)지만, 루비는 평균적으로 봤을 때 자바(Java)만큼 돈을 많이 받지도 못하고 시장도 더 좁다.
그렇지만 항상 그런 것은 아니다. 스칼라(Scala)가 강세를 얻고 있는 것처럼 보이지만, 시장 규모는 속일 수 없다. 반면 한 곳에 너무 오래 머무르다가 미래의 코볼(COBOL)이나 파워빌더(PowerBuilder) 개발자가 돼버려서도 곤란하다.
모두의 개발자 팁 No.5 : 읽는 사람을 배려해 문서를 작성하라
필자는 회사 임원들이 읽고 한 번에 이해할 수 있는 문서나 프레젠테이션을 만들었다는 이유만으로 프로젝트에 참여하거나 경영진 미팅에 참여하게 된 경험이 수없이 많다.
필자는 항상 임원진들을 위한 개요를 서두에 작성해둔다. 다시 말해, 꼭 읽어야 하는 페이지는 개요뿐이고 나머지는 개요를 잘 이해하지 못했을 때 읽으면 된다. 이 때 고려해야 할 것은 엄청나게 바쁜 일정을 소화해야 하는 사람에게 이 주제에 대해 얘기하려면 어떤 정보를 골라서 설명해 줘야 하는가다.
대부분 매니저들은 '누가 일의 진척 상황에 대해 자신을 귀찮게 하지 않고 이 일을 끝까지 이끌어 갈 수 있는가'를 가장 궁금해 한다. 이 부분에 중점을 두고 보고서를 쓰길 바란다.
모두의 개발자 팁 No.6 : 간결성이 생명이다
경영진들을 가까이 하다 보면 바로 알 수 있는 특징 가운데 하나는, 말을 잘 하는 사람일수록 짧고 정확한 답변을 한다는 것이다.
답변이 길고 복잡해진다는 건 그 사람이 주제에 대해 잘 모르거나 별로 성실하게 일을 하지 않는다는 의미다. 또, 주제의 중요도와 목소리 톤은 반비례하는 것도 사실이다.
정말 나쁜 소식을 전할 땐 조용히 문을 닫고 들어와 속삭이듯 말하는 법이다. 그다지 중요한 일은 아닌데 그냥 짜증 나는 소식일 경우 격앙된 목소리로 그 문제에 대해 목소리를 높이게 된다.
중요하지 않은 일에 대해 목소리를 높이는 사람이 되지 마라. 자신이 무슨 이야기를 하는지 정확히 알고, 그 이야기를 어떻게 요약할 지 고민하되 세부적 사항들을 포함시키려 노력해야 한다.
그렇지만 문장 하나 하나를 전부 세부 사항들을 곁들여 설명할 필요는 없고, 하늘이 무너진 것도 아닌데 작은 일에 호들갑을 떨지 마라(단지 한동안 괜찮은 빌드(build)가 없었기에 젠킨스(Jenkins)를 살펴봐야 할 지도 모를 뿐이다).
말로 하는 게 정 안 되면, 비용으로 승부봐야 한다. 숫자를 신중히 선택해 차트에 기입하고, 비용적인 측면에서 이것이 다른 것보다 더 낫다는 것을 확실히 보여줘라.
모두의 개발자 팁 No.7 : 관중을 놀라게 해라
관중 앞에서 발표하고 프레젠테이션을 잘 하는 방법에 대해 고민하라. 한 가지 주제에 대해 리서치하고 그 주제에 대해서는 '유일한' 권위자가 되지는 못하더라도 '전문가' 정도는 돼야 한다. 여러 사람을 상대로 하는 프레젠테이션은 재미적인 요소가 가미돼 있으면 좋다.
이런 기술은 낯뜨거운 실수를 몇 번씩 반복하지 않고는 얻을 수 없는 것이다.
그렇지만 경영진에게 한 주제에 대해 분명한 말로 잘 설명해 낼 수 있고 이에 대해 전문 지식을 가지고 있다면 그렇지 못한 사람에 비해 높은 연봉을 받게 된다는 건 장담할 수 있다.
모두의 개발자 팁 No.8 : 현실적인 개발자가 되라
자신이 설령 얼랑(Erlang)을 좋아한다고 해도, 이 시장은 그다지 크지 않다. 개발자라면 하나 이상의 프로그래밍 언어를 알아야 하며, '새로운' 주제나 새롭게 떠오르는 주제에 대해서도 잘 알아야 한다.
그러나 충분한 고려 없이 '얼랑이 아니면 코드를 하지 않겠다'는 식의 미숙한 발언은 하지 않아야 한다. 좁은 분야의 전문가가 되는 것도 돈을 벌 수는 있겠지만, 거기에도 비용이 따른다.
결국 자신은 전문 분야에 따라 그 분야에 국한된 배역만을 맡게 될 것이며, 그 분야가 유행을 탈 때는 좋겠지만 그 후에 자신이 뭍에 올라온 물고기처럼 바싹 말라갈 일만 남은 것이다. NoSQL이 자신이 진행하는 프로젝트에 더 잘 맞을 수도 있다. 그렇지만 기업에서는 일회성 시스템에 투자를 하지는 않을 것이다. RDBMS으로도 충분히 할 수 있는 프로젝트이기 때문이다.
모두의 개발자 팁 No. 9 : 툴을 이용해 어려운 문제를 해결하라
따로 시간을 내 다른 사람들이 잘 모르는 툴을 몇 가지 배워둬라. 다른 이들이 잘 모르거나, 사용하지 않는 툴은 무엇인가? 그 가운데 자신의 효율성을 더욱 높여줄 툴은 무엇인가?
예를 들어, 아스펙트4j(Aspect4j)는 사용하는 사람이 얼마 되지 않지만, 필자는 개인적으로 이를 아주 유용히 사용한다. 필자는 아스펙트4j를 잘못된, 아주 잘못된 것들에 사용한다. 아스펙트4j를 웹스피어(WebSphere) 대신 톰캣(Tomcat)에서 작동시키기 위해 클래스 파일 오퍼레이션(class file operations)을 만들었다. 비록 오리지널 소스는 없었지만 말이다.
또한 상용 소프트웨어의 메모리 누수 문제도 고쳤다. 필자는 윌리 인트로스코프(Wily Introscope)를 도입했다. 그럴 때마다 사람들은 필자가 다른 이들이 잘 사용하지 않는 툴을 사용한다는 점 때문에 천재처럼 여기곤 했다.
그리고 다른 이들이 개발업체를 기다리기로 결정했을 때에도 필자에게는 계속 진행하라고 하기도 했다. 필자는 eclipse.org/mat과 함께 살고 숨쉬었으며 그 결과 메모리 누수 문제를 해결할 수 있었을 뿐 아니라 어떤 행동과 한도가 OOME(Out Of Memory Error)를 초래하는지도 말해줄 수 있었다.
복잡한 문제를 해결해 주는 이런 간단한 툴 덕분에 필자는 다른 개발자 사이에서도 돋보일 수 있었다.
모두의 개발자 팁 No.10: 겸손을 잃지 마라
개발자에게는 겸손이라는 자질이 아주 부족하다. 겸손해진다는 건, 때로는 원하는 것 이상으로 힘든 일을 도맡아야 함을 의미한다.
또한 문제를 해결했다고 해서 이에 대해 자만해서는 안됨을 의미하기도 한다. 유명세는 오고 가는 것이지만, 한 가지 기억해야 할 것은 자신이 최근에 한 일 덕분에 유명세가 찾아오는 것이라는 사실이다. 그런 다음, 한 주만 지나도 유명세는 사라져 버릴 지도 모른다.
타일러 더든의 말을 빌리자면, "당신은 특별한 사람이 아니다." 그렇다, 필자도 이 말의 아이러니에 대해서는 잘 알고 있다.
자신이 인기있는, 모두의 개발자가 됐는지 어떻게 알 수 있을까?
자신이 서 있는 곳에서 양 옆을 살펴 보자. 자신이 하고 있는 일과 같은 일을 하는 사람들이 보이는가? 그렇다면, 아직 멀었다.
자신이 많은 이들이 원하는 개발자가 됐다는 신호에는 다음과 같은 것들이 있다.
사람들과 함께 있는데 다들 자신을 주목하고 있다든지, 특별한 상황이 아님에도 자신과 함께 사진을 찍고 싶어 한다든지, 자신의 연설을 모두가 기다린다든지, 혹은 자신의 연설을 얼마나 좋아하는지 직접 얘기한다든지 하는 것들이다.
덧붙여, 영업 및 마케팅 직원들이 자신의 의견에 귀 기울여 듣는지도 봐야 한다. 딱 자신의 얘기라고? 그렇다면 축하한다, 이미 모두의 개발자가 된 것이다.
그러나, 명성과 성공은 한 순간일 뿐이다. 이를 지속하기 위해서는 끊임없이 발전해야 한다. 아이러니하게도, 인기 있는 개발자가 될수록 정작 코드는 점점 더 적게 쓴다.
다른 사람들과 소통하고 그들에게 동기를 주는 것이, 그리고 자신의 성공 비결을 전파하는 것이 경제적으로 더 효율적이 되기 때문이다. 자신이 원했든 원하지 않았든 말이다.
앞서 말했지만, 소프트웨어 개발자들이 일자리를 원한다고 해서 다 가질 수는 없는 시기가 다시 한 번 찾아올 것이다. 특히 '적자생존' 식의 분위기가 만연해지면, 묵묵히 제 할 일만 하는 사람보다는 '셀프 마케팅'을 잘 하는 개발자가 살아남게 될 것이다.
뭐? 아프니까 청춘이다?
[펌] 좋은 기획서는 '형용사' 가 없다.
