Thoughts2014.09.02 10:03

5. 잘난 맛에 사는 개발자


이런 부류의 개발자는 보통 '내 코드에는 버그가 없다'나 '그건 당신 실수다'라거나 '그건 네 잘못이다'라는 말을 입에 달고 산다. 좋은 회사에서 일하는 프로그래머일수록 자부심이 지나쳐서인지 이런 경향이 강하다. 일례로 D모 사의 팀장급 개발자를 모셔다가 세미나를  한 적이 있는데, 청중의 어떤 요구도 가볍게 씹어주는 신공을 발휘한적이 있다. '내 목소리는 원래 작아서 이것 보다 크게 말씀드릴 수 없으니 알아서 들으시라'는 말은 아직도 우리 회사의 직원들 사이에 전설로 남아 있다. 와서 세미나 해 주는 것만 해도 영광이란 소리다.


거기다 이런 부류의 개발자는 같은 회사 직원을 제외한 다른 누구에게는, 동문 선배님이라도 되지 않으면 절대로 친절하거나 살갑지 않다. 살면서 누구에게 친절한 적이 한 번도 없는 인간들처럼 군다는 것이 특징이다. 본인은 스스로 멋있다고 생각할지 모르겠는데, 대다수의 사람들은 재수없다고 생각한다.


본인이 CEO라고 해도 쉽게 내치기에는 어려운 단계의 직원일 수 있으므로, 웬만하면 참고 같이 지내는 것이 좋다. CEO에게는 '잘난 척'하지 않는 경향이 있으므로, 참고 지내기는 쉬운 편이다.


4. 일을 줄이려는 본능에만 사로잡힌 개발자


윗 선에서 다 협의가 끝난 사항도 재차 전화를 걸어서 '부탁'하지 않으면 절대로 하려고 들지 않는 개발자. 윗 선에서 양해가 된 사항이라고 해도 끝까지 고집을 부린다. '더 많은 일은 싫다'는 본능에 따라서만 행동하기 때문이다. 이런 사람은 내가 네 윗선과 같은 급이라는 뉘앙스를 풍기면 알아서 기기도 한다. 


협력관계로 진행되는 일을 지연시키는 주범이기 때문에 이런 개발자를 발견하면 바로 자르는 것이 좋다. 


3. 다른 사람의 말에 잘 귀를 기울이지 않는 개발자


어지간한 대가의 말이 아니면 잘 배우려 들지 않는 부류의 개발자. 부하직원으로 두기에 어려운 유형이기도 하고, 상사로 모시기에도 어려운 유형이기도 하다. 세미나 시간에는 보통 졸기 마련이고, 회의 분위기를 해친다. 자기가 아는 내용일 경우에는 담당자가 답변할 기회를 가로채기도 한다. 


함께 일하기 피곤한 스타일이므로, 스타트업에서는 피하는 것이 좋다. 


2. 자기 개발 역량이 0인 개발자


뭐든 배우려는 생각이 별로 없어서 신기술 대응 능력이 0에 가까운 개발자. 아는 거라도 깊게 알면 그나마 다행이라고 볼 수 있다. (그러나 그런 경우는 드물다.) 강의를 듣거나 책을 보거나 하는 일이 드물기 때문에, 남들이 다 아는 내용도 뒤늦게 알게 되는 경우가 있다. 겸손히 들을 자세가 되어 있는 경우에는 예외이나, 그럴 준비도 되어 있지 않은 경우에는 영원히 초중급 개발자로 머물게 될 스타일이다. 


다른 길로 인도하는 것이 바람직하다. 


1. 짜증내는 개발자


짜증나는 개발자 제 1위는... 바로 짜증내는 개발자. 인생이 엿같고 힘들어서 아무한테나 짜증부리고 싶으면 일을 때려치우고 집에 가서 쉬는게 좋겠다. 전화에 응하는 상대방은 당신과 협력 관계에 있는 회사 직원이며, 당신에게 최대한 친절하려고 애쓰는 중이다. 그런 사람에게 전화로 짜증 내 봐야 당신 손해다. 당신 회사의 평판을 깎아먹기 때문이다. 


CEO는 이런 직원을 발견하면 바로 자르는 것이 좋다. 


저작자 표시 비영리 변경 금지
신고
Posted by 이병준
TAG 개발자

소중한 의견, 감사합니다. ^^

  1. 재미있게 잘 보았습니다.^^ 위의 5가지 이야기는 개발자보다는 사회에서 사회생활을 하는 모든 사람들에 해당 되는 이야기 같네요.

    2014.09.02 20:29 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 흑흑... 저는 자기계발 열심히 하려고 노력은 했는데 마음만큼 제대로 되질 않아서 회사에 미안하다는 생각이 계속 들더라구요. 결국은 개발자 때려치우고 다른길 찾아보고 있어요. ㅠㅠ

    2014.09.02 23:37 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. 공감가네요.. ㅋㅋㅋㅋ
    같이 일하면 힘든타입... ㅜ ㅜ

    2014.09.05 09:03 신고 [ ADDR : EDIT/ DEL : REPLY ]
  4. Frez

    이건 개발자에 해당하는 얘기들이 아니죠. 그냥 그런 사람이 있는 것일 뿐.
    기획자, PM에 갖다붙여도 마찬가지입니다.

    2014.09.05 16:40 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2014.01.08 09:09

예전에 '프로그래머를 위한 시간 관리의 법칙'이라는 글을 쓴 적이 있습니다. 지금 보니 좀 끔찍할 정도로 흥분해서 쓴 글이긴 하지만, 대체로 적은 그대로 실천하려고 노력했던 것 같습니다. 그랬던 덕분인지 뭔지는 잘 모르겠습니다만, 지난 10년간 TOEIC 990점의 성적, 8권의 번역서, 3회의 직원 포상 (우수직원상 포함) 등등의 실적을 올리고, 나름대로 인정받는 직원으로 생활하고 있습니다. 주 개발자로서 직접 개발한 시스템 3건도 있고, 그 중에 한 건은 지금 오픈 소스로 공개되어서 전세계 개발자의 반응을 기다리고 있습니다. 지난 10년간 야근을 한 횟수는 손에 꼽을 정도입니다. 



SEE ALSO: 프로그래머를 위한 시간 관리 법칙 [1] [2] [3] [4] [5] [6] [7] [8]


제가 생각하는 이 시간관리의 법칙을 간단히 요약하면 다음과 같습니다. 자세한 것은 위에 원문 링크를 걸어두었으니 참고하시기 바랍니다. 


- - - 


1. 회사에서 일하는 시간이 곧 자기개발 시간이다 


회사에서 하는 활동들이 여러분을 성장시키지 못한다면, 회사에서 일하는 시간은 헛된 것입니다. 휴식시간을 쪼개어 스스로를 성장시키려고 하는 것은 그다지 유익하지 못합니다. 사람은 어차피 휴식이 필요한 유기체니까요. 회사에서 하는 모든 활동을 개선하고 또 개선하려고 노력하세요. 그러면 휴식 시간은 온전히 휴식에 바칠 수 있습니다. 야근이 필요없게 됨은 물론입니다. 일부러 시간을 내서 자기를 성장시키려고 하지 마시고, 쓸데없는 활동을 줄이고 모든 일을 효율적으로 만들어서 자기를 성장시키세요. 


2. 결합 가능한 활동들을 합쳐서 효율성을 높여라 


여러분이 하는 이런 저런 활동들 가운데에는 합칠 수 있는 것들이 있습니다. 자신이 전문가가 되고자 하는 영역에서 가장 중요한 활동들이 무엇인지 찾으시고, 그 활동들을 합쳐서 보다 효과적으로 만들 수 있는 방법이 있는지 고민하세요. 


1. 성취 목표를 뚜렷이 하라
2. 목표를 달성하기 위해 필요한 활동을 식별하라
3. 활동간 우선 순위를 정하고, 엄한 활동은 제거하라
4. 활동 간 결합 가능성을 평가하고, 결합 가능한 것은 결합하라
5. 결합한 활동을 수행하라


3. 지금 하는 일에서 더 많은 것을 끌어낼 방법은 없는지 고민하라


평생 개발자로 살고 싶다면 개발을 재미있게 해야 하고, 자신에게 주어지는 모든 일을 기술 향상의 기회로 삼아야 합니다. 그렇게 하지 않으면 '저 친구에게는 프로그래밍을 시키는 것이 가장 좋아'라는 평판을 얻을 수 없습니다. 끊임없이 혁신을 만들어 내고 시험하는 개발자가 되도록 합시다. 그러면 여러분은 평판 뿐 아니라, 시간도 지배할 수 있습니다. 결국 여러분이 만들어 낸 혁신이 여러분의 시간을 아껴줄 것이니까요. 


4. 도메인 지식에 집중하라 


결국 더 큰 개발자가 되도록 만드는 것은 도메인 지식입니다. 효과적인 코드를 만들어 내는 기술도 중요하지만, 그 코드가 적용될 기술 영역에 대해 좀 더 깊이 있는 지식을 갖추는 것이 훨씬 더 중요합니다. 그런 지식이 없이는 쓸만한 코드도 만들어 낼 수 없습니다. 여러분의 시간은 그 목표를 향해서 조직되어야 합니다. 


- - - 


두서없이 이야기하였습니다만, 제가 말하고자 하는 요지는 충분히 전달되었으리라 생각합니다. 물론 너무 과격해서 과연 이런 실천법이 현실에 맞나 의아햘 분도 계시리라 생각합니다만. 아무튼 더 자세한 내용은 이 글에 걸어둔 원문 링크를 참고해 주세요. 감사합니다. :-) 



저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 비단 개발자가 아니더라도 명심해야 할 말씀이로군요. 새겨듣겠습니다. 고맙습니다. ^^

    2014.01.08 09:35 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 하고 있던 단순한 업무에 지쳐있던 저에게 자극이 되는 글이네요~좋은 글 감사합니다.
    저 한가지 궁금한 점이 있는데요
    마지막부분에 도메인 지식에 초점을 두고 나아가야 한다고 하신 말씀이에서요....
    최근에 기업들 채용 경향이나 글로벌 it기업들(아마존이나 구글같은)의 채용과정을 보면 효율적으로 코드를 작성하는 과정(자료구조나 알고리즘)을 중시한다고 하더라구요....
    그런데 위와 같이 말씀하신 이유가 무엇인지 궁금하네요


    참~번역하신 이펙티브 자바 잘보고 있습니다~^^
    종종 놀러올께요
    ㅎㅎ

    2015.11.12 20:46 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 자료구조나 알고리즘을 중시하는 이유는 그것이 기본이기 때문이구요. 실제로 업무를 시작하면 이제 그 업무에 관계된 도메인 지식이 가장 중요하죠. 기본이 없이는 도메인 지식 습득도 어렵다는 것은 더 말할 필요는 없겠습니다. :-)

      2015.11.14 09:04 신고 [ ADDR : EDIT/ DEL ]

Thoughts2014.01.07 09:41

개발자들은 생각보다 많은 책을 읽습니다. 직업상 그래야 할 일이 많기 때문이죠. 그런데 그런 책만 보다 보면 지칠 때가 있습니다. 개발자도 사람인데 항상 딱딱한 프로그래밍 관련서만 볼 수 있나요. 그래서 오늘은 좀 가벼운 마음으로 읽을 수 있는 책들 몇 가지를 소개하려고 합니다. 개인적으로, 이 책들은 저에게 참 많은 자극을 주었던 책들이기도 합니다. 


1. 아웃라이어 (김영사) 


말콤 글래드웰의 역작 "아웃라이어"는 왜 어떤 사람은 평범하게 살아가고, 어떤 사람은 탁월한 인생을 사는지를 알려줍니다. 그것도 풍부한 예제와 함께요. 이 책은 일만시간의 법칙, 그러니까 누구든 10,000시간 동안 의도적인 수련(deliberate practice)를 거듭하면 전문가가 될 수 있다는 법칙으로 잘 알려져 있습니다만, 사실 그것보다 더 많은 이야기를 담고 있습니다. 노벨상 수상과 출신 대학 간에는 유의미한 통계적 관련성이 없다던가, 어린 아이들을 상대평가하는 것이 아무 의미가 없다던가, 전문성에 소통이 굉장히 중요한 팩터라던가 하는 것들이 그런 사례죠. 


그러나 역시 우리같이 전문가로서의 인생을 꿈꾸는 사람들에게는 '일만 시간의 법칙'이 매력적일 수 밖에 없겠어요. 인생을 조금씩이라도 개선하려고 의도적으로 노력하는 사람들에게, 대략 오년쯤의 시간이 흐르면 새로운 인생이 펼쳐질 수 있다는 것만큼 매력적인 메시지가 어디 있겠어요?


SEE ALSO: 10,000시간의 법칙 

SEE ALSO: 10,000시간의 법칙 (2)


2. 이소룡, 세계와 겨룬 영혼의 승부사 (김영사)


갑자기 웬 이소룡 타령이냐구요? 그러게 말이죠. (풉) 그러나 돌이켜보면 이소룡은 정당히 대접받을만한 가치가 있는 무술인입니다. 심지어 개발자에게까지 말이죠. 글래드웰의 기준으로 보면, 이소룡이야 말로 '아웃라이어'죠. 그의 인생은 온전히 무자비할 정도로 모든 것을 개선하려는 노력에 바쳐져 있습니다. 이런 인물을 만나기란 쉬운 일이 아니에요. 여러분 주변에 그런 노력으로 모든 것을 조금씩이라도 바꾸려는 사람이 있습니까? 그렇다면 여러분은 행운아입니다. 





SEE ALSO: 달인, 이소룡


3. 에릭 클랩튼: 음악으로 굴곡진 삶을 관통한 뮤지션의 자서전 (마음산책) 


에릭 클랩튼의 삶은 딱 한 가지 단어로 요약할 수 있습니다. 바로 음악이죠. 다소 예의없이 이야기하자면, 이 거장의 인생 가운데 중반부는 음악 말고는 완전히 개판이었어요. 그러나 그 인생이 후반부에 극적으로 바뀔 수 있었던 것은, 그가 절대로 포기하지 않았던 바로 그 음악 덕분입니다. 이 자서전을 보다 보면 흥미로운 대목을 여러 군데 발견할 수 있는데요. 특히 그가 처음에 기타 연습을 어떻게 시작했는지를 보면, 재미있는 통찰을 얻을 수 있습니다. 그것은 바로, 그가 지루할 정도로 반복적인 연습에 굉장히 많은 시간을 투자했다는 점이에요. 개발자 주변에도 이렇게 끔찍할정도로 지겹게 반복되는 무언가가 널려 있습니다. 그런 지루함을 인생을 바꿀 자극제로 삼을 방법은 없는 것일까요? 


SEE ALSO: 프로그래머를 위한 시간 관리 법칙 [1] [2] [3] [4] [5] [6] [7] [8]


4. CODE 코드: 하드웨어와 소프트웨어에 숨어있는 언어 (인사이트)


윈도 진영의 Guru 찰스 펫졸드가 저술한 이 책은, 프로그래머라면 한 번은 보고 넘어가야할 탁월한 교양서입니다. 아마 컴퓨터의 하드웨어와 소프트웨어를 다룬 책 가운데, 이 책처럼 쉽게 가벼운 마음으로 읽을 수 있는 책도 드물 거예요. 이 책은 우리 주변에 존재하는 다양한 '코드'들이 어떻게 탄생되었는지를 이야기해주고, 그 코드들이 어떤 수학적 근거 위에 탄생했으며, 어떻게 컴퓨터 안으로 자연스럽게 스며들게 되었는지를 알려줍니다. 그 과정이 전혀 흥미진진하게 느껴지지 않는다면, 여러분의 적성은 아마 컴퓨터가 아닐지도 모릅니다 (응?)


5. 넛지: 똑똑한 선택을 이끄는 힘 (리더스북)


이 책은 우리가 만드는 시스템이 사용자와 어떻게 상호작용하는 것이 바람직할 것인지를 일깨워줍니다. 어떻게 해야 최대한 사용자에게 유리한 선택을 불편하지 않게 알려줄 수 있을 것인가? 물론 이 책이 기술하는 영역은 개발자가 관심있어하는 영역과는 좀 다릅니다만, 우리가 하려는 일이 결국 세상에 좋은 일을 하려는 것이고보면, 어떻게든 사용자에게 좋은 일을 해 보자는 목적을 달성하기 위해서는 이 책이 말하는 메시지 처럼, 사용자가 똑똑한 선택을 할 수 있도록 하는 시스템을 구축하는 것이 바람직하겠다는 귀중한 통찰을 얻을 수 있습니다.



저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 좋은 정보 잘 얻어 갑니다^^ㅎㅎ

    좋은 하루 되세요~

    2014.01.07 09:47 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 마음에 치유와 여유를 가지는 것이 저도 좋다고 생각합니다. 그 중에서 Code 정말 좋은 책이죠 ^^
    한편으로 자기 개발서에 실망도 많이 했는데
    "성공한 사람의 인생은
    성공한 후에 포장되어
    평범한 사람을 망친다. "
    라는 글에 심하게 공감하기 때문에 심취만 안하면 될 듯 합니다. ^^

    좋은 글 언제나 감사합니다.

    2014.01.07 10:21 신고 [ ADDR : EDIT/ DEL : REPLY ]

Languages/Python2014.01.01 11:42

1. 다양한 기능을 갖춘 언어가 필요하다면 


"실용주의 프로그래머(Pragmatic Programmer)"라는 책을 보면 일년에 하나 정도의 새 언어를 배우라는 조언이 있어요. Peter Norvig라는 사람이 쓴 "Teach Yourself Programming in Ten Years"라는 에세이를 봐도, 적어도 여섯 개의 "종류가 서로 다른" 언어를 10년간 배우라는 조언이 있지요. 뒤집어 이야기하면, 세상에는 여섯 가지 부류의 언어가 있다는 이야긴데요. 대충 정리해보면 다음과 같습니다. 


http://www.smallanimaltalk.com/2013/04/worlds-cutest-python.html


(1) 클래스 추상화(class abstraction)를 제공하는 언어

(2) 함수형 추상화(functional abstraction)를 제공하는 언어 

(3) 문법 추상화(syntactic abstraction)을 지원하는 언어 

(4) 선언적 명세(declarative specification)를 지원하는 언어

(5) 코루틴(coroutine)을 지원하는 언어 

(6) 병렬수행(Parallelism)을 지원하는 언어 


다른건 잘 모르겠고 (1), (2), (5)는 지원되면 좋겠다고 생각하는데요. 객체지향 언어는 이미 업계 대세니까 당연한거고, 함수형 추상화는 요즘 유행인데다 거의 모든 언어가 함수형 추상화를 지원하기 위해 삽질중이라 더더욱 그렇죠. Python은 (1), (2), (5)를 지원합니다. 객체지향 언어이자, 함수형 프로그래밍 언어이기도 하죠. 파이썬의 함수와 함수형 프로그래밍에 대해서는 http://docs.python.org/2/howto/functional.html 이 문서를 참고하면 좋겠습니다. 


사실 위의 여섯가지 속성을 거의 전부 만족시키는 언어도 있긴 한데요. Python의 미래라고 보는 사람도 있는 Julia입니다. http://julialang.org/ 


SEE ALSO: Java를 배워야 할 다섯가지 이유

SEE ALSO: 새로운 언어를 더 빨리 배우려면?


2. 생산성이 중요하다면


Python과 다른 언어의 성능을 비교하는 논쟁은 다양하게 있어 왔습니다. 한 가지 얻을 수 있는 결론은, Python의 성능이 나쁘지 않다는 겁니다. http://stackoverflow.com/questions/672857/is-python-slower-than-java-c 하지만 우리가 언어를 선택하는 기준이 꼭 성능 뿐만인 것은 아니죠. Python의 가장 큰 장점은 생산성입니다. https://pythonconquerstheuniverse.wordpress.com/2009/10/03/python-java-a-side-by-side-comparison/ 물론 어떤 언어의 생산성을 단순히 언어의 문법적인 측면만으로 논하는 것은 좀 위험한 일이긴 합니다만, Python의 문법이 보다 간결한 프로그래밍을 가능케 하는 것은 사실입니다. 


3. 프로그래밍 습관을 고치고 싶다면


파이썬은 들여쓰기(indentation)로 프로그래밍을 하는 드문 언어 가운데 하나입니다. C/C++/Java 등의 일반적인 프로그래밍 언어들은 보통 {와 }를 사용해서 구문의 범위를 구별하죠. 들여쓰기로 프로그래밍을 하면 {와 }를 쳐 넣지 않아도 되니까 프로그래밍 하기가 좀 편해지긴 하겠습니다만 코드가 길어지면 가독성이 점차로 떨어지게 되는 문제도 있습니다. 대체 어디서부터 어디까지가 함수인지를 명확하게 알기 어렵다는 문제도 있죠. 


그래서 파이썬으로 프로그래밍을 하다 보면 의식적으로 함수 하나의 길이를 줄이게 되는데요. (너무 길어지면 정말 정신 사나워지거든요.) 그러다보면 코드는 좀 더 테스트하기 쉬운 단위로 분할되죠. 이런 종류의 리팩터링(refactoring)을 의식적으로 하게 된다는 것은, 프로그래밍을 처음 배우는 사람 뿐 아니라 프로그래밍을 굉장히 오랫동안 해 온 사람에게도 유익한 것이죠. (Python 프로그램의 가독성이 다른 프로그램보다 높다는 사람이 있는데요. 아마 이런 종류의 반강제적 리팩터링과 간결한 문법 덕분에 그런 주장이 가능한 것이 아닐까 생각합니다.)


4. 초대형 프로젝트에 사용되는 dynamic 언어를 배우고 싶다면 


Python은 초대형 프로젝트에서 널리 사용되고 있는 동적 프로그래밍 언어이기도 합니다. http://www.ozytive.com/2012/10/13/10-reasons-why-you-should-learn-python/ 그러니, 초대형 프로젝트를 진행할만한 여력이 있는 회사에 취직하고 싶다면, Python을 알아두는 것이 좋겠어요. 이런 것은 단순히 프로그래밍 언어 유행을 따라가느냐 마느냐의 문제는 아니죠. 


5. 배우기 쉬운 dynamic language가 필요하다면


Python은 분명 배우기 쉬운 dynamic language입니다. 거기다 거대한 개발자 커뮤니티를 갖고 있죠. (Python의 역사는 꽤 오래 되었습니다.) 거기다 문서화도 충실하게 잘 되어 있어서, 아주 쉽게 배울 수 있는 언어이기도 합니다. (아마 기본적인 문법서 한권 정도를 본 다음 doc.python.org의 HOWTO 문서를 읽으면 바로 프로그래밍을 시작하실 수 있을 겁니다. 저는 일주일 걸렸습니다.) 


이것은 Python의 기본적인 문법이 기존 프로그래밍 언어와 크게 다르지 않기 때문이기도 하고, 가능한 자연어에 가깝게 느껴지는 문법적 구조를 채택하고 있기 때문이기도 합니다. Julia는 이점에서 Python과는 좀 다릅니다. 코드를 보면, 뭘 하는 코드인지 한 눈에 확 들어오질 않아요. (물론 다르게 생각하시는 분들도 있긴 하겠습니다만. :-P)



저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 블로그 내용 잘 보고 갑니다.

    2014.01.01 15:14 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 파이썬에 대해 다시금 바라보게 되는 좋은 글이네요. 특히나 6가지 항목이 가장 눈길을 끄는군요. 파이썬 책을 하나 사봐야겠는데요.

    2014.11.18 09:14 신고 [ ADDR : EDIT/ DEL : REPLY ]

Languages/Java2013.12.31 11:56

1. Garbage Collection이 필요하다면


메모리 할당/반환을 처리하는 것이 너무 지겹고 고단하다면, Java를 배워야 할 필요가 있을지 모릅니다. 잘 잘려진 대로, Java는 메모리 할당과 반환에 대한 작업을 Garbage Collector를 통해 알아서 처리해 줍니다. 그 성능이 걱정되신다구요? Java는 만들어진 지 오래된 언어이고, JVM의 성능을 최적화하기 위해 오랫동안 애써 왔습니다. 그 이야기는, Java의 JVM이 제공하는 Garbage Collector의 성능이 이제 믿을만한 수준까지 도달했다는 의미이기도 합니다. (물론 Java에서도 메모리 누수 현상, 즉 Memory Leak은 발생할 수 있으므로 이를 피하기 위해서는 코딩할 때 주의해야 합니다. Effective Java 2nd Edition을 참고하세요.) 


물론 잘 최적화된 C/C++ 바이너리와의 성능을 비교하는 것은 어불성설입니다. 하지만 C++로 작성한다고 무조건 성능이 더 나을거라는 생각은 버리는 것이 좋습니다. 대체적으로, 높은 성능을 내는 것은 무슨 무슨 언어를 쓴다고 공짜로 따라오는 것이 아니라, 프로그래머의 노하우, 패턴, 최적화 등등이 함께 결합되어야 가능하기 때문입니다. 


http://neuroph.sourceforge.net/index.html



2. 어떤 라이브러리를 쓸까 고민하기 싫다면


Java에는 이미 굉장히 큰 규모의 라이브러리가 번들링되어 있습니다. 이 라이브러리들만 잘 사용해도 대다수의 작업은 무리없이 처리할 수 있습니다. 게다가, 관련된 오픈소스 프로젝트들도 많아서, 용도에 맞는 써드 파티 라이브러리를 선택할 때 자유도가 굉장히 높습니다. '무슨 무슨 일을 하는 라이브러리는 파이썬이나 C++ 밖에 없어요. 그러니 우리는 프로젝트를 C++로 진행해야...'와 같은 상황이 생길 여지가 별로 없다는 것이죠. 


굳이 예를 하나 들자면.... 여러분은 GPU 코어를 사용해 시스템 처리 성능을 높이는 방법론인 CUDA를 알고 계실 겁니다. 예전 같으면 이처럼 시스템에 아주 가깝게 다가가 있는 기능을 사용하는 프로그램을 작성할 때 C/C++ 말고는 선택할 수 있는 언어가 거의 없었겠지만, 이제 자바 사용자는 JCUDA(http://www.jcuda.org/)를 사용해서 CUDA 프로그래밍을 할 수 있습니다. 


3. 높은 이식성이 필요하다면


JVM마다 성능이 조금씩 달라지는 일은 있습니다만, 대체로 Java 프로그램의 이식성은 JVM에 의해 보장됩니다. Java 표준을 충실히 따르는 프로그램을 개발했다면, 거의 모든 플랫폼에서 재컴파일 없이도 프로그램을 돌릴 수 있습니다. 아, 물론 Microsoft VM을 사용하는 프로그램을 짰다면 그것은 예외. (묵념) 


4. 수평적 규모 확장성이 요구된다면


Hadoop을 아십니까? 이제 데이터 처리에 있어 수평적 규모확장성(horizontal scalability)이 필요할 때, Hadoop 기반의 플랫폼은 무슨 업계 표준인 것 처럼 받아들여지고 있는 실정이죠. 놀라운 것은, Hadoop이라는 플랫폼이 Java로 작성되어 있다는 것입니다. 그 말은, 시스템에 요구되는 높은 확장성을 달성할 때 중요한 것이 더 이상 언어가 아니라는 점이며, Java가 그러한 성능 요구사항을 달성할 수 있는 수준으로 진화했다는 사실입니다. 어쨌든, Hadoop이 필요하다면 여러분은 Java를 배우는 것이 좋습니다. 물론 다양한 언어 바인딩(binding)들이 나오고 있는 실정이지만 말이죠. 


물론 수평적 규모 확장성을 달성하는 방법이 Hadoop만 있는 것은 아닙니다. Hazelcast(http://www.hazelcast.com/)도 한번 구경해 보세요. Java 기반의 미들웨어가 어디까지 진화해 있는지 느끼실 수 있을 겁니다.


5. 좀 더 편하게 개발하고 싶다면 


Java 개발자들에게 있어서 Eclipse란 어떤 존재인가요? (물론 요즘은 C++/Python 등 다양한 언어의 개발 환경도 Eclipse로 통합되고 있는 실정이긴 합니다만.) 아마 대다수의 Java 개발자는 (저 포함) Eclipse 없는 개발은 상상도 하지 못할지 모르겠군요. 이 놀라운 IDE 덕분에, Java 개발자들의 개발 생산성은 vi로 코딩하고 Make로 빌드하던 초창기에는 상상도 할 수 없을 차원으로 높아졌습니다. 


게다가 여러분은 지금, Android 개발 까지도 진행할 수 있을 만큼 진보된 Eclipse를 사용하고 있습니다. 게다가 Marketplace 기능을 통합한 Eclipse는, 새로운 개발 지원 기능의 통합을 믿을 수 없을 만큼 신속하게 수행할 수 있도록 해주죠. Eclipse는 Java 개발자들의 생산성을 높여줄 뿐 아니라, Java 언어에 대한 진입 장벽 또한 낮추고 있습니다. 


SEE ALSO: 파이썬(Python)을 배워야 할 다섯가지 이유



저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 비밀댓글입니다

    2013.12.31 18:22 [ ADDR : EDIT/ DEL : REPLY ]
  2. 어? 왜 비밀글이 되었지??

    2013.12.31 18:23 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 항상 좋은 글 잘 보고있습니다. 이번 주제는 JAVA의 필요성에 대해 말씀해 주셨는데요 위와같은 사항으로 고민중인 C/C++ 프로그래머라면 개인적인 소견이지만 JAVA보다는 C#도 어떨까 싶습니다.
      1) 자동화된 메모리관리
      2) JAVA와 유사한 라이브러리들과 MSDN
      3) C/C++과 유사한 문법
      4) C/C++의 dll링크가 가능 (C++의 속도와 C#의 편의성 두 이득을 동시에...)
      5) 윈도우 뿐 아니라 리눅스에도 모노를 통해 점점 확장성이 생기고 있음
      6) 스마트폰 게임을 개발중이라면 유니티에서 제공하는 기본 언어(물론 자바도 가능하지만 C#쪽이 더 낫다더군요.. JAVA쪽 유니티는 경험하지 못했습니다.)
      ---
      코멘트 해주신 내용 다시 붙였습니다. 감사합니다.

      2013.12.31 18:38 신고 [ ADDR : EDIT/ DEL ]

Thoughts2013.12.23 17:35

개발자는 대체로 문서 작업을 "오버헤드"로 받아들이는 경향이 있습니다. 품질 관리자 가운데는 이런 경향에 섭섭함을 토로할 분도 계시겠습니다만, 이건 엄연한 사실입니다. 개발자 가운데, 문서를 요구하는 관리자와 언쟁을 벌여본 경험이 없는 사람은 없을 겁니다. 


http://www.challengefuture.org/news/707


개발자에게 한가지 불행한 일은, 누군가는 그렇게 생산된 문서를 본다는 사실입니다. (편의상 문서 소비자라고 해 봅시다.) 그러니 문서화를 완전히 피할 방법은 없지요. 


문서 소비자에게 불행한 일은, 개발자가 생산한 문서 가운데 상당수에 적힌 내용이 실제 소프트웨어와 다르다는 사실입니다. 그런 상황이라면 소프트웨어를 만든 사람의 역량을 의심하게 되는 것도 무리는 아니지요.


이 불행은 무엇에서 비롯된 것일까요? 저는 '가치'에 대한 오해에서 비롯되었다고 봅니다. 개발은 고객에게 반드시 전달되어야 하는 가치를 만드는 행위입니다. 그렇다면 문서는 어떻습니까? 고객에게 보여주어야 하는 문서라면, '문서화'의 목적 또한 '고객에게 가치를 전달하는 것'이 되어야 마땅합니다. 내부 개발자들만이 공유할 문서라면요? 그럴 때는 이야기가 좀 달라집니다. 개발자들만이 볼 문서라면, 개발자들에게 최선의 가치를 전달할 수 있는 형태의 문서가 되어야 맞습니다. 관리자에게 보고할 문서라면요? 관리자들이 개발 진행상황을 쉽게 이해할 수 있도록, 최대한 간략화되고 개조식으로 정리된 문서가 되어야 맞을 겁니다. 그것이 관리자가 요구하는 '문서의 가치'이니까요. (관리자에게 가장 중요한 것은 '의사결정'임을 상기합시다.)


자. 그렇다면 우리는 비교적 쉽게, 문서화를 하는 데 있어 지켜야 할 원칙들을 뽑아낼 수 있을 것 같습니다. 문서화 작업에 있어서 우리가 지켜야 할 원칙들은, 의외로 우리가 개발할 때 지키는 원칙들과 비슷합니다. 


1. 단순성 (Simplicity) - 쓸데 없는 이야기를 하지 않는다. 


문서를 만들 때 중언부언 하지 않습니다. 가치에 반하는 것은 없앱니다. 개발자 내부적으로만 공유할 문서에 참여자들의 사인을 전부 받을 필요는 없습니다. 그런건 이슈 관리 시스템의 동료 검토 기능을 활용하면 됩니다. 개발자들만 볼 문서에 API의 상세 스펙을 넣을 필요는 없습니다. 그런건 JavaDoc에나 넣으면 됩니다.  단순하게 만들면 정보 중복이 줄어들고 관리 비용이 하락합니다. 필요한 내용만 넣고, 쓸데 없는 건 다 빼버리세요. 그런건 누가 요구할 때나 추가해 넣으면 됩니다 (규칙 5 참고).


2. 무결성 (consistency) - 소프트웨어의 실제 상태에 부합한다.


문서는 언제나 소프트웨어의 실제 상태에 부합해야 합니다. 고객이 어떤 사람이건 간에, 실제 상태에 부합하지 않는 문서는 언제나 실패한 문서입니다. 실패한 문서를 만들지 않는 몇 가지 방법이 있습니다. 첫 번째는 필요한 순간에 문서를 만들어 전달하고 해당 문서에 유효기간을 두는 것입니다 (규칙 4 참고). 두 번째는 개발자로 하여금 언제나 문서 창을 열어놓고 시스템을 변경할 때 마다 문서까지 변경하도록 요구하는 것입니다. 세 번째는 개발자가 언제나 주석에 가장 정확한 내용을 반영하도록 권하고, 필요할 때마다 주석에 적힌 내용을 갈무리해 문서를 만드는 것입니다. (세 번째 가이드라인을 따르는 문서가 JavaDoc같은 것입니다.) 


3. 독자 지향 (reader-oriented) - 문서를 읽을 사람을 고려한다. 


문서를 읽을 사람이 용역을 준 갑이라면 클래스 다이어그램이 필요할 것입니다. 그러나 고객이 시스템 사용자라면 클래스 다이어그램까지 그려진 문서를 주는 것은 과도합니다. 그런 경우에는 웹에 '사용자 가이드'와 'API 명세서'만 올려놓으면 충분합니다. 누가 문서의 고객인지를 생각하고, 거기 맞는 문서를 만드세요. 10명도 안되는 팀에서 다섯명 정도의 개발자들만이 돌려볼 문서라면, 아예 문서화를 포기하는 것도 생각해 보세요. 그런 팀에서라면 문서화 보다 잡담을 장려하는 쪽이 훨씬 나을지도 모릅니다. (그 팀의 진정한 목적이, 고객에게 '훌륭한 소프트웨어'라는 가치를 전달하는 것이라면 말이에요.) 


4. 적시성 (timeliness) - 문서가 필요한 시점을 고려한다. 


프로토타이핑이 진행된 결과로 이미 돌아가는 시스템이 있는 상태인데 굳이 설계 문서를 만들어서 클래스 다이어그램을 넣을 필요는 없습니다. 그런 것은 고객의 요구가 없는 한, 쓸데 없는 짓입니다. 문서가 여섯달 뒤에 필요한데, 지금부터 문서를 작성하는 것도 쓸데 없는 짓입니다. 그렇게 되면 문서의 무결성을 확보하기 위해 너무 많은 수고를 들여야 합니다 (규칙 2 참고). 언제 문서가 필요한지를 보고, 그에 맞는 문서화 계획을 세우세요.


5. 요구 지향 (demand-oriented) - 문서에 대한 고객의 요청을 고려한다. 


요청이 있다는 것은 고객이 문서를 통해 얻고자 하는 가치가 있다는 뜻입니다. 고객의 요구를 추정하다보면 문서에 너무 많은 내용을 담게 됩니다. 한 번에 완벽한 문서를 만들기 보다는, 고객의 요구를 받아들여 필요한 문서를 작성하는 것이 바람직합니다. 위키는 이런 용도에 적합한 시스템입니다. 위키에 기록된 사항만 언제나 무결하게 정리해 놓으면, 고객의 요구에 즉시 응답할 수 있습니다. 새로운 요청은 위키에 먼저 반영하여 고객의 반응을 살피고, 고객이 만족할 때 공식 문서로 변환할 수 있습니다. 그러니, 필요하지도 않은 문서를 만드는 데 너무 많은 시간을 쓰지 마세요. 


그리고 이 모든 원칙들이 너무 복잡하다면, 이것만 항상 생각하세요. '이 문서는 고객(문서를 읽을 사람)에게 어떤 가치를 주게 될까?' 이것만 기억한다면, 과도한 문서화의 함성에서 조금은 벗어나게 될 수도 있습니다.



저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2013.12.23 09:13

개발직도 직업인지라 어디 취직이라도 하려면 TOEIC 성적이 필요할 때가 있죠. (응?) 물론 대부분의 경우엔 필요 없습니다. 개발자가 '영어가 진짜 필요하다'고 느끼는 건 보통 실무에서죠. 어디 가서 제품 설명이라도 해야하거나, 아니면 제품 설명이라도 들어야 하거나. 뭐 그런 상황 말이에요. 그런 상황에 처하면, 무슨 습관처럼 영어가 아쉬워집니다만 막상 영어 공부를 하려고 들면 어디부터 해야 할지 막막한 것도 사실입니다. 그런 분들을 위해서, 실천 지침을 몇 가지 알려 드리죠. 적어도 '착수'는 하실 수 있을 겁니다. 



1. 시험 날짜를 잡아라. 


물론 시험 싫어하는 분들 많습니다만, 시험을 적절히 이용하면 훨씬 효율적으로 공부할 수 있습니다. 저 같은 경우에는 '영어 성적을 3개월 만에 올려야겠다'는 목표가 있었습니다. 이 목표를 달성하려고, 미리 3개월 뒤의 TOEIC 시험 날짜를 잡아 돈 까지 내 뒀죠. 그리고 공부를 시작했습니다. 시험은 '영어 능력 향상'이라는 목표를 달성하는 데 있어서, 마일스톤 지점 역할을 합니다. 


2. 중구난방하지 마라. 


3개월이라는 시간 밖에 없었기 때문에, 교재는 철저히 몇 가지로 제한했습니다. (너무 이것 저것 고르고 따지고 하다 보면 결국 공부해야 할 양이 많아져서 집중하기 힘들어집니다. 그러지 마세요.) 제가 고른 교제는 이런 것들이었는데요. 


(1) 20개 정도의 영어 뉴스가 담긴 CD

(2) TOEIC 문제 수준의 대화가 담긴 회화 테이프

(3) TOEIC 모의고사 문제집


20개 정도의 영어 뉴스가 담긴 CD는 당시 Voice Of America라는 웹사이트에서 구한 MP3 파일로 구웠던 것인데요. 이 웹사이트에서 구할 수 있었던 MP3 파일들은 정치, 경제, 문화 등등 다양한 부문의 관심사들을 뉴스로 전하고 있어서 지루하지 않았을 뿐 아니라, 난이도가 TOEIC보다 조금 어려운 수준이고 사용되는 단어도 2000개 정도로 제한되어 있어서 듣기 훈련을 하는 데 좋았습니다. 차 안에서 출퇴근할 때 마다 듣고 아침에는 안들리는 문장 중심으로 지문을 보면서 다시 정리를 했기 때문에 석달이 지날 때 쯤에는 거의 모든 뉴스를 외우다시피 할 수 있었죠. 


그 다음으로 활용했던 것은 회화 테이프인데, 이건 아버지께서 저한테 물려주셨던 겁니다. (응?) 버리기 뭐해서 가지고 있다가 결국 TOEIC 시험 준비하면서 활용하게 되었는데요. 이건 테이프라 출퇴근할 때 듣기가 뭐해서 (ㅋㅋ) 많이는 못들었지만 테이프를 한 3개 정도는 달달 외웠던 것 같습니다. 


그리고 나서 시험 보기 한주 전에 모의고사 문제집을 2개 정도 풀었는데요. 딱 2개 틀린걸로 나와서 '응? 이게 뭐지?' 하면서 경악했던 기억이...


3. 최소 2달 정도는 회화 학원에 다녀라. 


시험보기 한 한달 전부터는 집근처 회화 학원에 다녔는데요. 당시 선생님이 호주 선생님이었습니다. 발음이 기대했던 거와 차이가 있으셔서 조금 힘들었지만, 다양한 발음에 적응하는 훈련한다고 치고 걍 열심히 다녔습니다. 사실 회화 학원에 다닌 것은 외쿡인을 만나면 습관처럼 발병하는 영어 울렁증 때문이었는데요. 덕분에 외국인 앞에서 입을 전혀 떼지 못하던 제가 더듬더듬이라도 이야기를 할 수 있게 되었습니다. 그런데 그러려면 최소 2달 정도는 다녀야 하는 것 같아요. 처음 한달간은 보통 적응하느라 힘들고, 많은 말을 하게 되는 것은 보통 두 번째 달부터나 되어야 가능하더군요. 


4. 한국 드라마는 끊어라. 


시간날때 습관처럼 틀어놓는 한국 드라마는 끊으시구요. 영어 자막이 있는 영화나 미드를 보세요. 열심히 연습하기에 좋은 영화로 제가 주로 활용했던 것은... (구닥다리 영화들이라 죄송)


(1) 볼륨을 높여라

(2) 해리가 셀리를 만났을 때 

(3) Big

(4) 아담 샌들러의 코미디 영화들 (웨딩싱어, 50 First Dates 등등) 


이런 (또는 본인이 좋아하는) 영화들을 보고 또 보고... 하시다보면 나중에는 웬만한 영화는 대충 자막 없이도 들으실 수 있게 될 겁니다. 꼭 100% 들려서 듣는다기 보다, 모르는 건 대충 넘어가도 지장없는 경지에는 이르게 된다는 것이죠. 어차피 영어로 먹고살것도 아닌데 그 정도는 양해합시다. (묵념)


5. 출장 나갈 기회를 피하지 마라. 


출장 나갈 기회가 있으면 두려워하지 말고 꼭 챙겨서 다녀오세요. 영어 Presentation을 하실 기회가 있다면 더더욱 놓치지 마세요. Globecom 2010 학회에 논문 준비를 하면서 거의 스크립트를 달달 외웠었는데요. 그리고 나니까 나중에는 꼭 한국말인것 처럼 발표를 할 수 있게 되더군요. 이처럼 '달달 외워 말한 경험'이 한번 생길 때 마다, 말하기 능력이 껑충 성장합니다. 업무 때문에 출장을 나가게 되면 이처럼 '달달 외워서라도 말해야 하는' 일이 자주 생기는데요. 그런 기회를 활용하시라는 겁니다. 후회하지 않으실 겁니다. 



저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. EWRJW

    영어엔 왕도가 없고, 끝도 없는것 같습니다. 꾸준히 열심히 하는 방법밖엔 없더군요.
    회화학원도 좋은 학원을 다녀야 될것 같군요. 문제는 돈과 시간...

    2013.12.23 10:57 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 잉글리시

    학원선택은 어케하시나요?

    2013.12.23 17:40 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 저는 '집에서 가까운 학원'을 골랐었습니다. 원어민이 진행하는 회화수업을 받을 수 있으면 좋곘다는 것 정도가 요구사항이었고, 집에서 멀면 멀수록 수업을 들을 가능성이 떨어질지 모른다는 생각 때문이었죠.

      2013.12.23 17:49 신고 [ ADDR : EDIT/ DEL ]
    • 잉글리시

      그 학원이 잘 가르친다거나 그런거는 별 상관이 없을까요?

      2013.12.23 20:39 신고 [ ADDR : EDIT/ DEL ]
    • 저한테 중요했던 건 일단 원어민과 말할 기회가 주어진다는 거였으니까, 그당시에는 '잘 가르치고 못 가르치고' 가 별로 중요하지 않았었죠. 물론 저와 상황이 똑같은 분은 없으실 것 같으니, 각자 기준에 따라 고르시면 될 것 같습니다. :-)

      2013.12.23 21:29 신고 [ ADDR : EDIT/ DEL ]

Thoughts2013.12.21 12:24

개발 프로젝트건, 영어 공부건 간에, 단기간에 좋은 성과를 내야 할 때가 있습니다. 그럴 때는 이렇게 해 보면 도움이 됩니다. (제 개인적인 경험에 따라 정리한 것이므로, 맘에 들지 않는 부분도 있으실 수 있습니다. 그런 부분은 가볍게 무시해주세요.)


1. 평가 일정을 먼저 잡으세요.


가령 'TOEIC 시험에서 좋은 성적을 내고 싶다'는 목표를 잡았다면, 석달 뒤에 TOEIC 시험 날짜를 미리 예약해 두세요. 그래 놓으면 중간에 포기하고 싶다는 생각은 안 들겁니다. 제가 이렇게 해서 TOEIC 시험 준비를 했는데요. 시작할 때 760점이었던 점수가 TOEIC 시험 볼 때쯤에는 만점 가까이 나왔습니다. 


2. 장기적인 목표보다 단기적인 목표에 집중하세요. 


'프로젝트를 성공적으로 마친다'는 장기적이고도 추상적인 목표보다는, 단기적이고 구체적인 목표를 잡는 것이 좋습니다. '이 클래스는 오늘 내로 리팩터링한다', '저 코드는 내일까지 디버깅을 마친다', '이 제품의 디자인은 무슨 수를 써서라도 이번 주 내로 마무리한다'. 




단기적인 목표는 집중력을 높여서 생산성을 올리는 데 도움이 됩니다. 제 경험으로는, 단기적인 목표가 명확하지 않은 주는 그냥 날리는 주였습니다. (Orz)


3. 그날 그날 무엇을 성취했는지 기록해 두세요.


저 같은 경우에는 포스트잇, 프랭클린 플래너, 그리고 하루 일정을 시간별로 적을 수 있는 수첩을 활용했습니다. 제가 가장 좋아했던 것은 기자 수첩처럼 위 아래로 긴 스프링노트였는데요. 안에 하루 일정을 시간별로 적을 수 있어서 좋았습니다. 뭔가 하나를 마칠 때 마다, 이 수첩에 '오늘, 이 시간에, 이런 일을 마쳤다'고 적었습니다. (TO-DO 리스트는 프랭클린 플래너에 적었으므로 이 수첩과 병행했습니다.) 



제가 근무하는 회사에는 '주간업무보고'라는 제도가 있는데, 이 주간업무보고 시에 사용되는 보고서를 만들 때 방금 말씀드린 스프링노트에 적은 내용을 옮겼습니다. '내가 왜 이런 일을 했고 어떻게 해결했다'까지 적은 보고서를 만들었기 때문에, 가끔 '개조식으로 한 일만 적은 보고서'와 비교하여 칭찬을 듣기도 했습니다.


이렇게 매일 매일 무엇을 했는지 기록해 두면, '장기적인 목표'에 얼마나 가까이 다가갔는지 계량적으로 측정할 수 있다는 장점도 생깁니다. 


4. 자신에게 보상을 해 주세요.


'하루 종일 자리에 앉아서 일 생각만 한다'는 목표를 세웠던 날에는, '퇴근할 때 좋은 커피를 한 잔 마신다. 오늘은 한 잔도 못 마셨으니까.' 같은 보상을 해 줍니다. '오늘 이 강의를 다 들으면, 주말에는 일 생각하지 않고 운동만 한다.' 같은 것도 제가 만들었던 보상 중 하나였습니다. 사실 그렇게 한다고 일상이 크게 달라지는 것은 아니었지만, '보상이 있다'는 생각을 하는 것 만으로도 '같은 일도 다르게 여겨지는' 일이 생기기도 합니다.


단기적인 성과를 위해 달리는 과정은 100m 달리기나 비슷해서, 지치기 쉽습니다. 스스로 마음을 달래는 보상 같은 것을 정기적으로 해 주는 것이 좋죠. (술이나 담배는 제외.) 


5. 실패는 생각하지 마세요.


그건 그 때 가서 생각해도 됩니다. 


6. 생산성을 높이는 도구를 활용하세요. 


'주석을 정말 잘 달고 싶다!' 같은 목표를 세웠다면, 그 목표를 달성할 수 있도록 해 주는 좋은 도구를 찾으세요. 대가들의 코드에서 가끔 발견되는 '주석 내 다이어그램' 같은 것이 필요하다면, AsciiFlow 같은 도구를 활용하면 좋겠죠. 



클립이던, 포스트 잇이던, 도움될 만한 모든 도구를 활용하세요. 저는 책이나 개발 스펙 문서를 읽을 때는 독서대를 사용하고, 노트북으로 장시간 작업을 해야 할 때는 노트북 스탠드를 활용하고 있으며, 구할 수 있는 가장 좋은 키보드와 마우스를 사용하고 있습니다. 하지만 뭐니 뭐니해도 가장 좋았던 도구는...


지우개 달린 노란 연필이랄까요. (수줍) 


저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2013.12.19 14:02

어느날 아들이 물었다. 


"아빠는 하는 일이 정확히 뭐야?"


자주 느끼는 것이지만, 이런 질문을 받으면 모골이 송연해진다. 내가 뭘 하는 사람인지, 이제 초등학교 4학년인 아들에게 설명하는 것은 쉬운 일이 아니다. 물론 스마트폰이나 태블릿들 덕분에 예전보다 더 컴퓨터에 친숙해지긴 했지만, 그래도 아직 '개발'의 많은 부분은, 아이들에게는 미지의 영역이다. 



"그러니까 아빠는 말이야..."


정확히 이야기하면 나는 프로토콜 스택(protocol stack)을 개발하는 개발자다. 그런데 아이에게 '프로토콜 스택'이 정확하게 어떤 소프트웨어인지 설명하는 것은 쉽지 않다. 나는 '두 대의 컴퓨터가 서로 통신하는 데 필요한 소프트웨어를 개발하는 것이 아빠가 하는 일'이라고 대충 얼버무리고 말았다. 


"그러니까 아빠는 핸드폰 앱 같은건 안 만든다는 거지?"


아들은 실망한 눈치였다. 아빠가 핸드폰 앱을 만드는 개발자였더라면, 아마 친구들에게 할 말이 많았을 것이다. 뻐길 수도 있었을 것이다. 그러나 아빠는 그런 건 만들지 않는다. 


"아빠가 만드는 소프트웨어가 없으면, 그런 앱들도 동작을 못하지."


그 말에, 아들의 얼굴에는 화색이 번졌다. 아마도, 친구 중 하나가 물었으리라. '아버지 뭐하시노?' 그리고 핸드폰을 보여주며 물었으리라. '니 아부지는 이런거 안만드시나?' 


아이들에게 소프트웨어란, 앱이다. 그게 다다. 그것 이외의 어떤 것이 있으리라는 것을 아이들은 모른다. 아들은 아빠가 개발자라는 것은 알고 있지만, 아빠가 만드는 소프트웨어가 어떤 것인지 한 번도 본 적은 없다. 그러니까 궁금했을 것이고, 한편으로는 속도 상했을 지 모른다. '왜 나는 아빠가 개발한 걸 만져보지 못하지? 핸드폰에 깔 수 있으면 써 볼 수 있었을텐데.' 


옆에 누워서 책을 읽어주지 않으면 쉽게 잠들지 못하는 아들 옆에서, 나는 그날 책 대신 '만질 수 없는 소프트웨어' 이야기를 해 주었다. 세상의 모든 컴퓨터들이 어떻게 연결되는지, 그리고 그 컴퓨터들이 서로 협력해서 어떤 결과를 만들어 내는지. 인터넷은 무엇이고, 웹 서버란 무엇인지, 라우터란 어떤 장비들인지. 그리고 아빠가 만드는 소프트웨어는 그 사이에서 무슨 일을 하는지. 잠이 솔솔 올 만한 이야기들이었다. 



그 알쏭달쏭한 이야기를 듣다 잠든 아들은 다음날 졸린 눈을 비비고 일어나더니, 청천벽력같은 선언을 하고야 만다. 


"아빠, 나 컴퓨터 배울래!"


"이미 세상이 다 컴퓨터로 도배되었는데 뭘 또 배워?"


그렇지 않은가. 이미 세상 모든 사람이 손에 컴퓨터 하나씩은 들고 다니고 있는데, 굳이 뭘 또 배운단 말인가. 내 말에 아들은 잠깐 생각하더니, 말했다. 


"나도 아빠처럼 컴퓨터로 뭐 만들어 볼래!"


난리났다. 아, 이게 아닌데. 

저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 어릴때 저도 프로그래머가 장래희망이었는데 현실은 정말 쉽지 않겠죠

    2013.12.19 14:55 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 선님

    지금부터준비해서 10년후면 괜찮지 않을까요.
    소프트웨어 개발자가 제대로 대우받는 때가 언젠가 오지
    않을까요. 안철수 대통되면 말이죠. 그렇다고 안철수 미는건아니구요
    담은 반기문땜에 틀린것 같고 9년후에요

    2013.12.19 18:00 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. 김은미

    하하하 웃겨요를 누릅니다

    2013.12.19 18:52 신고 [ ADDR : EDIT/ DEL : REPLY ]
  4. rainyway

    컴퓨터전공 학생입니다 ^^
    이번 졸업후엔 전공관련으로 바로 취직하지 않지만
    과거엔 임베디드 소프트웨어 개발자의 꿈을 키우던 터라
    공감이 많이 가는 글이네요
    잘 보고 갑니다 아이 건강하게 키우시길 바래요 :)

    2013.12.23 21:22 신고 [ ADDR : EDIT/ DEL : REPLY ]
  5. 장래희망을 아빠가 하는 일 한다는 이야기를 들으면 너무 행복할것 같습니다.
    저도 미래에 아들이 '아빠가 하는거 재밌을것 같아' 라고 하는 소리를 들으면 좋을 것 같은데요? ㅎ

    2014.04.04 10:17 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2013.12.18 09:43

개발자를 뽑아야 한다면, 대체 그들을 위해 무슨 물건을 갖춰 놓아야 하는 걸까요? 저렴한 비용으로 최대의 생산성을 달성하려면, 대체 어떤 것들을 준비해 놓아야 하는 것일까요? 오늘은 제가 생각하는 BEST 8을 정리해 보았습니다. 


1. 듀얼 모니터


개발자에게 모니터 한 대로 쓸만한 결과물을 내 놓으라는 것은 너무 가혹합니다. 터미널 네 개만 열어놓으면 화면이 꽉 차 버리는 19인치 모니터 한 대로 세상을 바꿀 소프트웨어를 내놓던 시대는 지났습니다. 적어도 두 대의 모니터는 갖춰 놓으세요. 그러면 모니터 하나로는 웹 서핑을 하면서도 다른 하나로는 코딩을 할 수 있습니다. (응?)


http://blog.sethgillespie.com/tag/dual-monitor/


2. 쓸만한 키보드와 마우스


좋은 키보드와 마우스에 열광하는 것은 게이머들 뿐만이 아닙니다. 개발자들은 손가락으로 먹고 사는 사람들이기 때문에, 손가락으로 조작하는 모든 기기의 품질이 중요합니다. 무선 연결이 가능하고, 자리를 많이 차지하지 않고 (개발자의 책상은 보통 굉장히 너저분하기 때문에, 너무 크면 곤란합니다), 오래 작업해도 피곤하지 않은 키보드와 마우스를 준비합시다. 마우스를 고를 때는 어떤 환경에서도 동작하는 (심지어 유리 위에서도 동작하는) 마우스를 고르는 것이 좋습니다. 개발자가 그 마우스를 어떤 환경에서 사용하게 될는지 알 수 없거든요. (마우스를 무릎 위에서 굴리게 될 수도 있습니다.) 


로지텍 Anywhere MX. 최고의 마우스 중 하나.


3. 대형 화이트보드 


때로 백마디 말보다 한 장의 그림이 의사소통에 효율적일 때가 있습니다. 그리고 개발자들은 그림을 그려서 서로 의견을 나누는데 굉장히 익숙합니다. (그림을 그리지 않으면 서로 딴 소리를 하고 있다는 것을 알아채지 못할 때도 있습니다.) 그러니 대형 화이트보드를 하나 마련해서, 어디든 붙여 놓으세요. 요즘은 시트지 형태로 나오는 화이트보드도 있어서, 그냥 아무 벽이나 붙여놓을 수 있습니다. (벽이 없는 경우는 제외.) 


http://www.shoutot.com/fullhd/sheldon-and-penny-whiteboard-calculations-big.html


4. 포스트-잇


개발자들 가운데 꼼꼼히 수첩 관리를 하는 사람은 드뭅니다. 대부분은 해야 할 일을 포스트 잇에 아무렇게나 적어서 아무데나 붙여놓기 마련이죠. (그리고도 잘 보지 않는 경우가 있긴 합니다. 때로는 메모를 확인할 시간도 없거든요.) 그러니 메모지는 가급적 많이 준비해 두세요. 그러면 의사소통도 원활해 집니다. 때로 얼굴 보고는 하기 힘든 이야기를 포스트잇에 적어서 책상에 붙여놓는 사람도 있거든요. 


http://www.123rf.com/photo_3842806_yellow-post-it-note-with-you-re-fired-message.html


5. SSD가 달린 데스크탑과 노트북


개발자들은 서로 커피를 마시면서 '내 컴퓨터 부팅속도가 더 느리다구' 같은 걸로 내기를 합니다. (응?) 그 이야기는 뒤집어서 말하면 '내가 일을 더 빨리 하길 원하면 더 빠른 컴퓨터를 사달라구'와 비슷한 이야기입니다. 개발자들에게 빠른 컴퓨터를 사주면, 아마 개발자들은 부팅 속도로 내기를 하는 대신, 누가 더 빨리 개발할 수 있나 같은 걸로 내기를 하기 시작할 겁니다. (근거는 없습니다.) 




6. 비데 


개발자들은 오랫동안 앉아서 일하는 직업을 가진 사람들입니다. 물론 개중에는 집중력을 높이기 위해서 일어서서 일을 하는 사람도 있습니다. 


http://www.pcpro.co.uk/features/380731/a-standing-workstation-for-your-home-or-office


그러나 역시 대부분은 앉아서 일하는 쪽을 선호하죠. 개발자들 가운데 치질로 신음하는 사람들이 많은 것은 우연이 아닙니다. 그들의 똥X에 은밀하고도 지속적으로 가해지는 압력을 생각해보세요. 비데는 선택이 아니라 필수입니다. 개발자들을 소중하게 생각하신다면, 그들의 X꼬 또한 가족처렴 여겨주세요. 


7. 카페인


개발자들이 일하다 곯아떨어지는 일이 없도록, 적절한 양의 카페인을 항상 공급해 줄 수 있는 환경을 갖춰놓으세요. 카페인 없는 환경에서 일하는 개발자는 종종 괜한 일에 짜증을 냅니다. 카페인은 개발자들에게는 각성제이자 진정제 같은 것이죠. (아마 카페인으로 진정시킬 수 있는 몇 안되는 부류의 사람들일 겁니다.)


http://inchoo.net/fun-zone/whats-up-with-web-developers-and-coffee/


다만 주의할 것은, 지나치게 칼로리가 높은 커피는 금물이라는 겁니다. (크림을 잔뜩 얹은 마키아또 같은 것이 거기 해당.) 가뜩이나 과중한 업무에 시달리는 개발자들을 고칼로리 환경에 오래 노출시켜 놓으면, 데드라인을 일주일 남겨놓고 병원에 실려가는 긴박한 상황이 생길수도 있습니다. (묵념) 


8. 라꾸라꾸 / 야전침대 


개발자들이 편안하게 눈치보지 않고 쪽잠을 즐길 수 있도록, 야전침대 류의 물건을 하나 정도는 비치해 놓으세요. 다만 너무 공개된 장소에 놓으면 곤란합니다. 아무도 사용하지 않을 것이거든요. (면접 보러 온 사람이 도망갈 수도 있습니다.) 다리를 쭉 뻗을 수 있는 형태의 의자로 대체하는 것도 가능하겠습니다. 


http://ani2life.egloos.com/3573446


이 얼마나 아름다운 광경입니까? (수줍) 



저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. ㅎㅎ 재미있게 읽었습니다.. 지금 회사에서 커피를 마시며 일하는 개발자 1인입니다..ㄷㄷ 많은 공감이... ㅜㅜ

    2013.12.18 10:24 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 포스트가 재치있습니다.
    개발외에 다른 능력이 부럽네요.
    늘 즐겁게 보고 있습니다.

    2013.12.18 10:51 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. 개발자심에도 철학도 가지고 계시고 소통하시는 법도 가지고 계시네요. 멋지고 배울점이 많습니다. 종종들러서 눈팅하겠습니다. ^^

    2013.12.18 11:18 신고 [ ADDR : EDIT/ DEL : REPLY ]
  4. 면접갔는데 라꾸라꾸부터 보이면 오해하지 않을까요 :)

    2013.12.18 11:58 신고 [ ADDR : EDIT/ DEL : REPLY ]
  5. tonny

    한가지 더 추가하자면??!!
    헤드폰(또는 이어폰)을 좋은거로 하나 장만해야겠죠. 코딩하다보면 주변 소리에 무척 신경을 쓰는 경우가 많으니 주위에서 싸움이나도 모르고 나 혼자 즐길 수 있는 그런거로^^ 단, 이어폰은 직접 귀에 들어가니 청각에 문제가 될 듯. 헤드폰으로 ^^

    2013.12.18 13:04 신고 [ ADDR : EDIT/ DEL : REPLY ]
  6. 초보코알라

    달달한 군것질 거리도 필요합니다....
    저도 개발(?) 또는 디버깅을 하다보면 배가 고파도.. 조금만 더.. 조금만더... 하다가 식사시간을 놓치는 경우가 있습니다..
    이럴때를 대비해서 필요 할 것 같습니다.

    2013.12.18 13:15 신고 [ ADDR : EDIT/ DEL : REPLY ]
  7. 백수프로그래머

    좋은 의자!! 앉아서 개발하는 대부분 개발자들에겐 필수 아니겠습니까 ㅋㅋㅋ

    2013.12.18 14:03 신고 [ ADDR : EDIT/ DEL : REPLY ]
  8. 아.. 맨 밑에 제 사진이..(...)

    2013.12.18 18:12 신고 [ ADDR : EDIT/ DEL : REPLY ]
  9. 널널한개발자

    아 왠지 슬프네요 ㅋㅋㅋ

    2013.12.19 07:16 신고 [ ADDR : EDIT/ DEL : REPLY ]
  10. 키작은거인

    개발자를 꿈꾸는 취준생으로써 흥미로운 글이네요ㅎㅎ
    글쓴이님이 글에서 언급하신 환경을 갖추고 있는 회사는 어느 정도 규모의 회사인지도 궁금하네요.
    첫 직장을 저런 환경에서 시작한다면 너무 좋을거 같아요 :D

    2013.12.19 09:15 신고 [ ADDR : EDIT/ DEL : REPLY ]
  11. 비밀댓글입니다

    2013.12.19 12:22 [ ADDR : EDIT/ DEL : REPLY ]
    • 네 괜찮습니다. 감사합니다. ^^

      2013.12.19 12:30 신고 [ ADDR : EDIT/ DEL ]
    • 주민영

      감사합니다. 여기에 간단히 소개했습니다. 글을 재미있게 참 잘쓰시네요 ^^
      https://www.facebook.com/dailymaso

      또 뵙겠습니다~

      2013.12.19 14:39 신고 [ ADDR : EDIT/ DEL ]
    • 고맙습니다. 좋은 하루 되세요~

      2013.12.19 14:45 신고 [ ADDR : EDIT/ DEL ]
  12. 페이스북에 친구가 글을 소개하여 찬찬히 읽어보던 중 오랜만에 찾아뵙게 되었습니다.
    지금도 재미있는 글을 많이 쓰시네요.^^

    학교 연구실에 있던 글 속의 모든 것이
    회사 인턴으로 오게 되면서 몇몇 가지가 없다보니 (특히 듀얼 모니터...ㅜ)
    여러모로 고생을 하게 되더군요.
    그래도 사람은 적응의 동물이라 그런지 나름 적응해가며 살아가게 되네요.
    (물론 듀얼 모니터가 없으니 alt+tab을 열심히 누르거나 혹은 모두 다 출력하거나 둘 중에 하나네요. :))
    본문에 언급하신 건 프로그래머에게 정말 필요한 것이 아닌가 싶습니다.^^

    2013.12.27 23:50 신고 [ ADDR : EDIT/ DEL : REPLY ]
  13. 저는 마지막 야전 침대 빼놓곤 다 갖추고 있네요.
    그래서 좀 더 열심히 살아봐야 겠습니다.^^

    2014.04.11 19:31 신고 [ ADDR : EDIT/ DEL : REPLY ]
  14. 나마꼬

    6번 조항에 크게 공감하고 갑니다.
    겪어본 고통을 알기에 좋은 의자와 규칙적인 스트레칭 알람, 그리고 비데는 매우 중요하다고 생각합니다.

    2017.03.20 17:09 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2013.12.15 18:23

이 바닥에서 일을 하다보면 어떤 이유에서건 직장을 옮길 일이 한 번 이상은 생깁니다. 이 바닥에서 평생 직장이라는 개념은, 아무래도 다른 부류의 직장 보다는 덜 하게 마련이죠. 그렇다면 어떻게 직장을 선택하고 옮겨야 나중에 후회를 하지 않을까요? 제 개인적인 경험을 토대로 몇 자 적어보겠습니다. 





1. 왜 옮기는 지를 분명히 하라. 


왜 옮기는 지가 분명해야 나중에 후회할 일이 적습니다. 사람들은 다양한 이유로 직장을 옮깁니다. 더 높은 연봉을 찾아 옮기기도 하고, 집 가까운 직장을 찾아 옮기기도 하고, 더 나은 근무환경을 꿈꾸며 새 직장을 찾기도 합니다. 왜 옮기는 지가 분명하면 새 직장을 고르는 기준이 명확해지니까 좋습니다. 


단기 목표와 장기 목표가 분명한 사람일 수록 '왜 옮기는 지'도 비교적 정확하게 이야기할 수 있습니다. '왜 옮기는 지' 도무지 설득력 있게 이야기할 수 없다면, 개발자로서의 인생을 얼마나 구체적으로 설계하고 있는지 스스로에게 물어보세요. 


한 가지 주의할 것은, 옮기고자 하는 이유를 부정적인 단어들로 채우지 말라는 겁니다. '이 회사가 싫어서', '이 회사가 너무 따분해서', '이 회사가 너무 배울 것이 없어서' 같은 이유들을 생각했다면, 다른 단어들로 바꿔 보세요. '더 많은 배움을 찾아서', '더 즐거운 근무 환경을 찾아서' 이런 문장으로 바꿔 보라는 겁니다. 그러면 '더 많이 배우려면' 또는 '더 즐거우려면' 어떻게 해야할 지, 무엇을 추가해야 할 지가 명확해 집니다. 그러면, 지금 회사에서 왜 많이 배우지 못했는지, 그리고 왜 즐겁지 못했는지가 분명해지죠. 그러고 나면, '정말로 옮기는 것이 능사인지' 스스로 결론을 내리는 것도 쉬워질 겁니다. 


2. 많은 사람의 이야기를 들어라.


기준이 섰다면, 거기 부합하는 다양한 회사들을 후보로 골라보세요. 자신이 선택한 회사가 있다면 후보 중 하나로 포함시키세요. 그리고 그 회사들에 대한 의견들을 들어보세요. 의견들을 듣는 단계에서는 가급적 자기 의견은 내세우지 마시고, 일단 다양한 목소리들을 들어본 다음에 정리하고, 그 다음에 자기 생각을 추가해 넣으세요. 그 과정에서 여러분은 다양한 사실들을 발견하게 될 겁니다. 전혀 고려하지도 않았던 회사의 미래 성장 가능성이 생각보다 높다는 것을 발견하고 놀라게 될 수도 있고, 무시했던 회사가 현재 탄탄한 매출을 올리고 있는 건실한 회사임을 발견하고 경악하게 될수도 있습니다. 


많은 사람들의 이야기를 들으면 들을수록, 나중에 '저 회사로 갔으면 좋았을 걸...' 하는 일을 피할 수 있습니다. 회사를 옮기는 것은 생각보다 큰 결정입니다. 나중에 후회할 일은 만들지 않도록 합시다. 옮긴 회사에서 생각보다 오랜 시간을 보내게 될 수도 있으니까요.


3. 정말로 옮겨야 하는 지 스스로에게 다시 한 번 물어보라. 


왜 옮기려고 생각하고 있습니까? 단순히 일이 힘들어서 또는 재미가 없어서 옮기려고 생각하고 있습니까? 그렇다면 일이 힘들게 느껴지거나, 재미가 없는 이유는 무엇인가요?


제가 생각하기에 직장 생활이 따분하고 소모적으로 느껴지는 가장 큰 이유는, 적절한 동기 부여가 이루어지지 않기 때문입니다. 그런데 우리가 명심할 것은, 그 동기라는 것은 외부에서 주어지기도 하지만 내부적으로 만들어질 때도 있다는 점입니다. 내부적인 동기를 스스로 창조하지 못하는 사람은 어떤 직장에 가더라도 따분함을 느끼게 될 가능성이 높습니다. 


내부적인 동기가 뚜렷한 사람은 이런 경향이 있습니다.


(1) '개선'에 대한 열망이 높다

(2) '소통'에 대한 열망이 높다

(3) 본인도 모르는 '리더십'이 강하다 


개선하려는 욕구는 소통을 유발하고, 그렇게 이뤄지는 소통은 다른 사람에게 모종의 영향력을 발휘하게 됩니다. 어떻습니까. 여러분의 내적 동기는 과연 충분한 수준이었나요? 그리고 그런 내적 동기를 통해 주변 환경을 바꿀 수 없었나요? 


4. 옮기려는 회사에 적합한 자질을 보유하고 있는지 자문해 보라.


스스로에게 물어봅시다. 전직에 적합한 자질을 보유하고 있는지. 그렇지 못하다는 겸손한 결론을 내렸다면, 그 자질을 채우기 위해 짧은 시간이나마 반성하고 노력해 봅시다. 새로운 직장에서도 여러분은 어떤 팀의 일원일 것입니다. 팀의 일원이 되어 기쁜 사람이 될 수 있도록 마음을 잘 추스린 다음에 옮깁시다. 


직장을 옮길 때는, 가급적 아집이나 고집, 편견 따위는 다 내려놓은 다음에 옮기는 것이 좋습니다. 새로운 직장에서 여러분이 갖춰야 할 최선의 덕목은 겸손입니다. 자신감은 어디까지나 그 다음이죠. 그렇게 믿고 있어야 새 직장에서 실패할 가능성이 줄어듭니다. 


저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2013.12.13 13:06

스스로 초급 개발자라고 생각하십니까? 초급 개발자가 중급 개발자로 인정받는 것은 생각보다 어렵습니다. 그 단계에서 많은 사람들이 개발자로서의 인생을 포기하거나, 그저 그런 개발자로서의 자신에 만족하며 살아가길 택하기도 하죠. 그렇다면, 초급 개발자에서 중급 개발자로 올라서려면 어떤 노력을 해야 하는 걸까요?



http://www.forouzani.com/great-developers-are-slightly-autistic.html



1. 좋은 책을 읽으라. 


여러분이 Java로 개발자 생활을 시작했다면, 중급 개발자가 되기 위해 읽어야 할 책들은 명확합니다. "Effective Java"같은 책은 아마 1순위겠죠. 이런 책은 개발 패턴에 대해 알려주고, 개발 시 반드시 피해야 할 일들에 대해 알려주어 여러분이 멍청한 실수를 저지르지 않도록 도와줍니다. 멍청한 실수를 저지르는 것은 스스로 초급임을 만천하에 알리는 가장 좋은 방법입니다. 그러지 않으려면, 소위 "Effective"나 "Exceptional" 시리즈들을 읽을 필요가 있습니다. C++이라면 Scott Meyers의 "Effective" 3부작을 읽어둘 필요가 있겠죠.


2. 소스 코드를 읽으라.


같은 팀원의 소스코드이건, 아니면 오픈소스에 포함된 소스이건, 관심있는 부분을 골라서 많은 코드를 읽으세요. 같은 팀원의 소스코드라면 더 좋고, 그것이 여러분의 사수나 멘토의 소스코드라면 더 좋습니다. 많은 코드를 읽으시고, 그 코드가 왜 그렇게 작성되었는지 살펴보세요. 생각에 더 나은 코딩 방법이 있다면 그 방법을 작성자와 의논하세요. 그런 소통과정을 통해서 여러분은 세상에 기여할 수 있을 뿐 아니라, 팀의 중요한 일원이 될 수 있습니다. 읽고, 말하고, 들으세요. 그게 가장 좋은 방법입니다. 


3. 커뮤니티 활동을 하라. 


페이스북이건 아니면 커뮤니티 웹 사이트건, 자신과 같은 관심사를 가진 사람들이 모여있는 곳에서 다양한 사람들이 하는 이야기를 들으세요. 직장을 구하는 문제건, 아니면 개발시 접하는 문제건 간에, 여러분은 많은 귀중한 교훈들을 거의 공짜로 들을 수 있을 겁니다. 물론 처음에는 소위 "Guru"들이 하는 많은 이야기들이 대체 무슨 소린지 알아들을 수 없을 겁니다. 그러나 시간이 지나면 점차로 여러분은 그런 사람들이 어떤 패턴으로 이야기하는지, 문제 중심적으로 이야기한다는 것이 무엇인지, 소통에 있어서 쓸데 없는 이야기를 제거하려면 어떻게 해야 하는지, 그리고 검색이 왜 중요한 지 배울 수 있게 될 것입니다. 


그리고 그러려면, 쓸데 없는 뉴스 사이트들을 돌아다니는 건 당분간 그만둬야 하죠. 


4. 영어 공부를 하라. 


프로그래밍에 대해 알려주는 많은 웹 사이트들에 올라오는 글들은 불행히도 대부분 영어권 사용자들을 위한 것입니다. 그런 사람들이 무슨 소리를 하는 지 알아들을 수 있으려면 영어 공부는 필수죠. 물론 그런 사람들이 구사하는 영어의 패턴은 일반적인 회화와 다르고, 문법적 정확성이 기술적 간결함에 희생되는 경우도 빈번합니다. (그래서 처음에는 무슨 소린지 알아듣기가 쉽지 않죠.) 하지만 블로그나 전문적인 웹 사이트에 올라오는 글들은 대부분 정제되어 있고, 기술적인 용어들을 사용해 알기 쉽게 작성되어 있습니다. 그러니 조금만 공부하면 의외로 쉽게 이해할 수 있습니다. 원서들을 통해 최신 기술을 쉽게 접할 수 있다는 것은 덤.


5. 좋은 롤 모델을 찾아라.


주변을 보시고, 배울만한 개발자가 있는 지 보세요. 여러분이 만일 어떤 회사의 신입 개발자라고 가정해 보죠. 회사에 적응을 하고 나면, 소위 그 회사의 탑 프로그래머들이 누군지, 왜 그들 중심으로 개발이 진행되는 지 파악할 수 있게 될 겁니다. 그 사람들 중 한 사람을 멘토로 삼을 수 있다면 가장 좋겠지만, 그럴 수 없다면 최소한 롤 모델로라도 삼고 그 사람이 어떻게 회사 생활을 하는 지 배울 수 있도록 하세요. 명심할 것은, 중급 개발자가 되는 데 있어서 가장 중요한 것은, 좋은 개발자로 살기 위해 반드시 갖춰야 할 기술과 삶에 대한 태도를 배우는 것이라는 점입니다. 그 사람들의 삶 전반을 보고, 배울 것은 배우고, 고쳐야 할 것은 고쳐서 자신만의 무엇으로 삼으세요. 결국 여러분은 단순한 코더가 아니라, 팀의 일원이니까요. 


저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 좋은 글이네요. 책을 많이 읽기도 해야겠지만, 말씀처럼 좋은 책을 읽어야겠습니다. ^^

    2013.12.13 14:21 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 좋은글 잘읽었습니다 감사합니다

    2013.12.15 14:32 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. 지나가던 개발자

    좋은 글 잘 읽었습니다. 가치 있는 공유 감사드립니다. :)
    한가지 코멘트 드리고싶은 점이 있어 덧글 남깁니다.
    C++ 의 명서인 Effective 시리즈 저자의 이름은 Scott Meyers 입니다.
    좋은 글에 사소한 오타가 있어 수줍게 코멘트 드려봅니다. (도망)

    2013.12.15 20:06 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 이병준

      생각나는대로 적었더니 오류가 있었군요. 감사합니다.
      좋은 하루 되세요~

      2013.12.15 20:47 신고 [ ADDR : EDIT/ DEL ]
  4. blueasa

    좋은 글 잘 읽고 갑니다. :)

    2013.12.16 02:20 신고 [ ADDR : EDIT/ DEL : REPLY ]
  5. 루이

    잘 읽고 갑니다~~

    2013.12.16 08:11 신고 [ ADDR : EDIT/ DEL : REPLY ]
  6. 책읽는아이

    좋은 글 감사합니다

    2013.12.16 10:38 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2013.12.12 20:43

개발자의 꿈은, 역시 인정받으면서 잘 나가는 개발자가 되는 것. 그러나 이 치열한 경쟁 사회에서 잘 나가는 개발자, 또는 직장인이 되는 것은 역시 어렵습니다. 과연 어떻게 하면 잘 나갈 수 있을까요?





1. 남들보다 잘 하는 것 하나는 꼭 만들라


"저건 쟤가 제일 잘 해"라는 평판을 만들어 놓으면 회사에서 '영향력'을 행사할 수 있는 기회가 늘어납니다. 그게 JavaScript가 되었건 CSS가 되었건 DB가 되었건 Hadoop이 되었건 CUDA 프로그래밍이 되었건 간에, 남들보다 잘 하는 것이 하나는 있어야 합니다. 


2. 신속 정확하게 일을 마쳐라 


일을 신속하고 깔끔하게 마무리하는 사람이야 말로 직장에서 환영받습니다. 물론 일을 너무 빨리 마치면 다른 일이 더 밀려들지 않느냐고 뭐라 할 분도 계실것 같은데요. 그런 경우에는 다른 동료의 일을 도와주는 것도 한 방법입니다. 직장 내의 신용도도 올리고, 평판도 쌓는 좋은 방법이죠. 물론 상사에게 인정도 받습니다.


3. 말은 못하는 것 보다 잘 하는 것이 낫다


개발자로서 말을 할 일이 그렇게 많지는 않겠습니다만, (1) 일의 방향을 두고 설득할 때나 (2) 일의 결과물을 놓고 defense해야할 때는 꽤 말을 많이 해야 할 겁니다. (3) 어디 가서 결과물을 시연하거나 발표하는 경우에도 말을 꽤 많이 해야 하죠. 그럴 때는 (1) 흥분하지 말아야 하고 (2) 논리적이어야 합니다. 그런데 그럴 수 있으려면 '이러고 있을 시간에 코딩이나 한 줄 더 하는게 낫겠다'는 생각은 머리속에서 지워버려야 합니다. 시간이 아깝다는 생각을 하고 있으면 상대방을 설득하다 성질이 나는 경우가 있거든요. 어차피 말을 해야 한다면, 차분하고 조리있게 합시다. 결과물을 팔아먹는 데도 도움이 되고, 대외적으로 좋은 평판도 쌓을 수 있습니다. 천라인 코딩을 한 마디 말로 다 까먹는 경우가 왕왕 있다는 것을 유념합시다.


4. 자기만의 라이브러리를 만들어 두라


자기만의 공구상자가 있으면 비슷한 일을 몇 년이고 계속 하게 되는 상황에 처할 때 굉장히 큰 도움이 됩니다. 신속 정확하게 일을 끝마칠 수 있으므로, 직장 내 평판은 계속 상승할 것입니다. 물론, 이런 부류의 라이브러리는 계속 기름칠을 해서 중요한 순간에 언제든 꺼내 휘두를 수 있도록 해 둬야 하죠. 여러 종류의 시스템에 설치할 수 있도록 이식성을 확보해두는 것도 좋겠습니다. 


5. 일년에 한 두 달 정도는 미친듯이 열정적으로 일하라


그 한 두 달 덕분에, 여러분의 일년을 바라보는 상사의 시선이 달라질 겁니다. 야근 하라는 이야기는 아니구요. 적어도 업무시간 중에는 사생결단의 각오로 키보드를 두들기라는 겁니다. 데드라인과 별 상관 없는, 상대적으로 여유있는 기간에 이런 식으로 일하면 약빨이 더 잘 받습니다. 일정을 앞당길 수 있게 되기도 하고, 다른 리스크가 줄어들게 되기도 합니다. 납기에 해야 하는 일이 줄어들때도 있다는 건 덤입니다. 


6. 억지로라도 공부하라


영어든 코딩이든 뭐가 되었든 억지로라도 공부하는 모습을 보이면, 직장내 평판은 더욱 좋아질 것입니다. 모르는 것 같아도, 당신의 상사는 당신이 어떻게 여가를 보내는지 까지 주시하고 있습니다. 


7. 팀원들과 소통하라 


가급적 팀원들과 많은 이야기를 나누는 것이 좋습니다. (1) 인간적인 이야기로 서로에 대한 호감도를 증가시키는 것도 좋고 (2) 기술적인 토론을 통해 지식을 쌓는 것도 좋습니다. 어떤 형태의 대화라도 도움이 됩니다. 다만 조심할 것은 '수다성' 대화는 지양해야 한다는 것. 그런 대화에 너무 많은 시간을 쏟으면 '놀기만 하고 일은 안하네'라는 평판을 얻기 딱 좋습니다. 그런 대화는 어디까지나 술자리에서. 소통은 대체적으로 양보다는 질이니까요. 


8. 잘나가는 회사에서 일하라


당연한 이야기지만, 잘나가는 회사의 개발자는 회사 덕에 덩달아 잘 나갑니다. 안에서는 어떨지 몰라도, 밖에서 보기에는 '잘 나가는 개발자'죠. 그러니, 잘 나가는 개발자가 되기 위한 이런 저런 노력이 귀찮다면, 그냥 잘 나가는 회사에서 개발자로 일하시기 바랍니다. (입사가 어렵다는 것은 함정.) 


저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. Rodney

    한 문장 한 문장에 정말 감탄하고 갑니다
    본문 정도만 해도 기술을 떠나 인정받는 사람이 될 수 있을듯 하네요

    2013.12.12 21:15 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 개발자로서 공감얻고 갑니다 ㅎㅎ

    2013.12.12 21:30 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. aa

    멋진들이네요 잘봤습니다.

    2013.12.13 12:31 신고 [ ADDR : EDIT/ DEL : REPLY ]
  4. 개발자는 아니지만 생각 많이 하게 하는 글이네요, 잘보고갑니다 ^^

    2013.12.13 18:36 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2013.12.11 17:07

좋은 개발자를 뽑기 위한 환경을 갖추었다고 칩시다. 그런데 대관절 좋은 개발자는 어떻게 알아볼 수 있을까요? 좋은 개발자와 그렇지 않은 개발자를 가려내는 것은 생각보다 어렵습니다. 



일단 개발자를 만났다면: 


1. 어떤 프로그램을 만들어 보았는지 물어보라.


만일 '재미삼아' 만들어 본 프로그램이 있다면, 그리고 그 프로그램을 아직도 유지보수하고 있다면, 혹은 그 프로그램을 공개 소프트웨어로 만들어 많은 사람들에게 배포해 본 경험이 있다면, 그 사람은 좋은 개발자일 가능성이 아주 높습니다. 


2. 어떤 프로젝트를 진행했었는지 물어보라. 


자신이 진행했던 프로젝트 이야기를 하면서 많은 개발자들은 자기 어필을 하려고 시도합니다. 가급적이면 그 이야기를 끝까지 들어주면서 그 개발자의 역할이 어느 정도였는지 파악하세요. 가능하면 무엇이 어려웠고, 그 어려움을 극복하기 위해 어떤 노력을 했는지 들어보세요. 그런 이야기를 듣다 보면, (1) 독야청청 독불장군형 개발자인지 (2) 협업 중심의 개발자인지 (3) 문제 방임형 개발자인지 (4) 문제 해결형 개발자인지 (5) 자기를 잘 포장할 줄 아는 개발자인지 (5) 말에는 별 소질이 없는 개발자인지 (6) 문제를 깊이있게 들여다보고 개발을 진행하는 사람인지 (7) 일단 만들어 보고 문제를 몸으로 이해하는 유형의 개발자인지 등등의 중요한 정보를 알아낼 수 있을 겁니다. 


3. 간단한 문제를 던져주고 어떤 접근법으로 풀 지를 물어보라.


보통 '코딩 인터뷰'를 진행하기도 하는데, 문법을 다 기억 못하거나 관련 자료를 찾아보면서 프로그래밍하는 사람도 많으니 코딩을 실제로 해 보라고 요구하기 보다는 어떤 접근법을 사용할 것인지 물어보는 것도 괜찮습니다. (물론 대부분의 외국 IT 업체는 종이에라도 프로그램을 만들어 보라고 요구하죠.) 답변을 들어보면 꽤 많은 정보를 얻을 수 있는데 (1) 예전에 이 개발자는 어떤 식으로 문제를 풀었는지를 알 수 있고 (2) 필요한 분야에 맞는 최신 지식을 많이 갖추고 있는지 알 수 있고 (3) 실질적으로 문제를 해결할 능력이 있는 지를 알 수 있습니다. 


덤으로, '당신의 해결방법에는 이러저러한 문제가 있을 것 같은데, 그건 어떻게 해결할 건가요?' 같은 질문도 던져 보면 좋습니다. 


4. 개발자의 입장에서 대화해 보라.


개발자의 입장에서 술 한잔 하면서 이런 저런 이야기를 하다보면, (결국에는) 일과 관련된 무용담을 털어놓게 되기 마련입니다. 가능하면 솔직하게 가감없이 자기 이야기를 먼저 하세요. '저도 그런 문제를 겪었었는데 저는 이렇게 해결했습니다' 같은 답변을 듣게 된다면, 아마 술이나 커피 값이 아깝지는 않을 겁니다. 


5. 옷차림에는 신경쓰지 마라.


허술한 옷차림을 하고 있는 개발자라면, 일 이외의 다른 문제에는 아예 관심이 없는 사람일 가능성이 있습니다. 의외로 갖춰입고 면접에 임한 개발자라면, 세상에 대한 열정이 가득한 사람일 가능성이 높습니다. 어느 쪽이라도 손해날 것은 없으니 웬만하면 옷차림은 신경쓰지 마세요. 


6. 회사 문화에 잘 동화될 만한 사람인지 알아보라. 


자만심, 아집, 편견 등등은 협력이나 조화같은 보편적인 가치에 굉장히 적대적인 속성들입니다. 이런 속성들을 갖춘 사람인지 살펴보시고, 능력이 기대치를 훨씬 상회하지 않는 한 그런 사람은 뽑지 마세요. 결국에는 팀이 아작납니다. 남 이야기를 잘 들으려 하지 않는 사람, 열 명이 아니라고 해도 자기 고집대로 하는 사람은 전부 이 부류에 넣을 수 있습니다. 냉소적이거나 빈정대는 습관이 있는 사람도 좋지 않습니다. 다른 사람 기분을 상하게 만드니까요. 


7. 가르칠 수 있을만한 사람인지 알아보라. 


즐겁게 배울 준비가 되어 있는 사람은 설사 배경지식이 부족해도 뽑아볼 만 합니다. 의외의 분야에 사람이 필요한데 거기 지원해 볼 생각은 있느냐, 같은 질문을 던져보고 반응을 보면 좋습니다. 물론 거짓된 반응을 보일 수도 있으니, 일정 기간 동안은 함께 일하면서 살펴볼 기회를 갖는 것도 좋습니다. 새로운 업무에 대한 파악 능력이 좋은 사람은 어떤 상황에 처하더라도 도움이 됩니다. 


8. 이전 직장에서의 평판을 알아보라. 


요즘은 전직을 통해 새로운 기회를 찾는 것이 보편화되고 있는 추세이므로, 직장을 많이 옮기는 것은 그다지 흠이 되지 않습니다. 오히려 전 직장에서 사람들과 어떻게 어울렸고, 어떤 리더십을 발휘했고, 어떤 결과를 만들어 낸 다음에 퇴사했는지를 알아보면 뽑는 사람 입장에서는 리스크를 줄일 수 있으므로 도움이 됩니다. 다만 너무 뒷조사하듯 할 필요는 없고, 그냥 아는 사람이 있다면 (이 바닥에서는 한 다리 건너면 다 아는 사람이죠) 한번 넌지시 물어보는 것으로 충분하겠죠. 


저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2013.12.11 09:16

모든 스타트업에게 '좋은 개발자를 뽑는 것'은 아주 중요한 일입니다. 혼자서 모든 개발을 다 할 생각이 아니라면 더더욱 그렇죠. 그렇다면, 좋은 개발자를 뽑으려면 어떻게 해야 하는 걸까요?


1. 어떤 개발자가 필요한지를 명확하게 하라


개발자는 만능이 아니므로 '필요한 개발자가 어떤 부류인지' 명확하게 해 놓으면 도움이 됩니다. 필요한 분야에 맞지 않는 개발자를 전부 경력 부족으로 치부할 필요는 없겠지만, 뽑아야 하는 개발자가 갖추어야 할 기술이 어떤 것인지 명확하게 해 놓으면 도움이 되죠. 


2. 회사의 비전을 공개하라


비전은 여러 가지 측면으로 구성되는데, '성공할 것으로 보이는 아이템'도 그 중 하나겠지만, 유무형의 적절한 보상 체계도 거기 포함됩니다. 자기 개발 가능성도 빼 놓을 수 없겠죠. 그런데 어쨌든 중요한 것은, 이런 비전들이 내부적으로만 공유되는 것이 아니라 외부로도 공개되어야 한다는 것입니다. 회사 웹 사이트를 잘 구축해 놓거나, 회사가 자체적으로 운영하는 블로그 등이 그런 목적을 달성하는 데 유용합니다. 그러니 그런데 쏟는 노력을 아까와 하지 않는 것이 좋겠어요.


3. 회사의 문화를 명확하게 하라 


애플, 마이크로소프트, 구글 등등은 전부 회사의 개발 문화가 명확합니다. 좀 단순한 면이 없잖아 있지만 이 세 회사의 개발 문화를 각각 한줄로 요약해 보면:


(1) 애플: 까라면 까라. 대신 너희는 세상을 바꾸는 일에 동참하게 된다.

(2) 마이크로소프트: 인재를 인재답게 대우해준다. 최대한의 대우를 약속하지만 자유는 포기하라.

(3) 구글: 개발자가 원하는 모든 형태의 자유를 준다. 그 자유를 회사를 위해 써라. (?) 


회사의 문화가 명확하고 공개되어 있으면, 개발자가 회사를 선택하는 일이 좀 수월해집니다. 여러분의 회사도 마찬가지입니다. 이 때 중요한 것은 회사 문화에 대해서 거짓말을 하면 곤란하다는 겁니다. 그런 짓을 하면 나중에 '악평'을 덤으로 얻을 수 있습니다.


4. 쾌적한 근무환경을 만들어라


몇 명으로 시작하는 초기 단계에서는 어쩔 수 없는 일일지도 모릅니다만, 그렇더라도 회사의 근무환경은 최대한 쾌적하게 꾸밀 필요가 있습니다. 초기 단계에서 이 작업은 파티션 등을 쌓아올리는 구조적인 작업이라기 보다, 자유와 자율을 중시한다는 느낌을 주는 심미적인 측면에서 접근할 필요가 있습니다. 





5. 인맥을 적절히 활용하라


언제나 그렇습니다만, 구인 광고만 올린다고 사람이 오진 않습니다. 회사 홍보는 좋은 개발자를 뽑는 데 필수일 수밖에 없고, 지명도가 올라간 이후에도 꾸준히 이루어져야 하는 활동입니다. 그리고 보통 이 바닥에서 '홍보'의 한 수단으로 가장 효과적인 것 중 하나가 바로 인맥이죠. '한 다리 건너 아는 사람'이 좋은 개발자일 확률은 굉장히 높습니다. 중간에 낀 '한 다리'가 바로 그 '아는 사람'과 일해본 경험이 있는 경우가 대부분이기 때문이죠. 일해본 사람은 그 사람이 어떤 사람인지 알고, 서로 무엇이 아쉬운지 잘 알게 마련이죠. 


저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^