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.16 18:10



어디선가 컵라면 냄새가 나는 것 같은데...



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

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

  1. 영화처럼

    지금 저기 계단 아래에서는 철가방님이 오고 있습니다... ㅠㅠ

    2014.01.16 19:41 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 재미있는 그림이네요 ㅎㅎ 근데 야근할 때 라면먹으면 좀 섭하다는... 아무리 못해도 짜장면은 먹어야...

    2014.01.16 21:55 신고 [ 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.30 10:29

앞선 글에서 다단계 하청 업체들이 왜 생기는지 간략하게 짚어봤는데요. 물론 100% 그렇지는 않습니다. 다단계 하청업체 가운데는 아예 그 시장을 보고 만들어지는 업체들도 있습니다. 


http://jpub.tistory.com/334



SEE ALSO: 다단계 하청구조는 왜 생기나? (2)

SEE ALSO: 다단계 하청구조는 왜 생기나? (1)


어쨌든 다단계 하청업체들이 계속 유지될 수 있는 것은 이 업체들에게 일감을 주는 다른 업체들이 있기 때문이고, 그 시장이 계속 유지될 수 있기 때문입니다. 지금까지 이 글을 읽으신 분들은 아마 그 원인이 무엇인지 대충 짐작하시겠지요. 용역 단가가 낮기 때문입니다. 용역 단가가 낮으니까 직접 개발하는 것 보다 용역을 주는 것이 훨씬 쌉니다. 그리고 이렇게 용역 단가가 낮게 유지될 수 있는 이유에 대해서는 앞서 이야기했습니다. (개발자 등급제, 개발자 수급구조 등등) 


그런데 이렇게 용역 단가가 계속 낮게 유지되면, 전체적으로 봐서 시장에 나쁜 영향을 미칩니다. 가장 먼저 생각할 수 있는 것은, 아이디어만 가지고 창업에 뛰어드는 소위 얼치기(?) 창업자들이 생긴다는 겁니다. (개발은 용역주면 되니까 그 편이 저렴하죠.) 이런 창업자들은 투자 받고 서비스 런칭한 다음에 ㅈ망하고 나면 바로 초급 개발자들을 잔뜩 뽑은 다음에 하도급 업체로 변신합니다. 그러니 하도급 시장은 더 커지죠. 시장이 이렇게 커지면 커질수록, 하도급 업체들은 경쟁력을 확보하기 위해 용역 단가를 더 낮춥니다. 용역 단가가 이렇게 밑도 끝도 없이 낮아지면.... 결국 SW의 품질은 개판이 될 수 밖에 없죠. 


두 번째는, 바로 '다단계'가 생긴다는 점입니다. 고급 개발자를 보유한 업체 B가 A로부터 프로젝트를 수주합니다. 이 업체 B는 중급 개발자들로 구성된 업체 C에게 하도급을 줍니다. 이 업체 C는 초급 개발자들로 구성된 업체 D에게 하도급을 줍니다. 중간에 얼마를 먹을 수 있는지가 아주 명확하기 때문에, 다단계의 유혹을 피할래가 피할수가 없습니다. 거기다가, B 입장에서는 A 에게서 프로젝트를 수주할 때 약속한 사항을 지켜야 하기 때문에, C를 쥐어짜지 않을래야 않을 수가 없습니다. 그리고 보통 업체 B는 A같은 업체들을 아주 많이 '모시고' 있기 때문에 (그것도 제한된 인력으로요) C같은 업체도 아주 많이 거느려야 합니다. 


문제는 이 다단계의 맨 아래쪽에 있는 업체가 이 다단계에서 탈출할 가능성이 있느냐는건데요. 다단계의 속성상 먹이사슬의 위쪽에 있는 업체가 꼬장을 피우기 시작하면 그나마 받아먹고 있던 일감도 사라질 가능성이 높기 때문에 (어디서 많이 듣던 소리죠) 성공적으로 솔루션 업체로 변신하지 않는 한, 가능성은 굉장히 많이 떨어지죠. 게다가 하도급 일감들을 오래하게 되면, 정신적으로 피폐해져서 '솔루션 업체로서의 변신' 같은 건 꿈도 꾸지 못하게 됩니다. 


물론 개발자들 가운데는 이런 상황에서 탈피하고자 프리렌서로 전업하기도 합니다. (중급 이상의 개발자 분들이 특히 이렇습니다. 이런 프리렌서 개발자분들이 어떻게 일거리를 수주하는지는 네이버 '외주까페' 같은 곳을 참고하시기 바랍니다.) 그러나 이런 프리렌서 개발자들이 모여 금융권 전산시스템을 고도화하기도 한다는 것은, 개발할 사람에게도 그렇고 최종 소비자에게도 그렇고, 다소 안타까운 일이기도 합니다. (실제로 시스템 개발에 종사하는 많은 분들께 누가 될 수도 있어서, 더 이상의 말은 아끼겠습니다.) 


자. 그렇다면 우리는 다음과 같은 결론에 이르게 됩니다. 


(1) 등급제는 좋은 점보다 나쁜 점이 더 많다

(2) 용역 단가가 더 낮아지지 않게 할 방법이 필요하다 


등급제는 폐지해버리면 간단하겠습니다만, 용역 단가가 더 낮아지지 않도록 하려면 사회적인 노력이 필요하다고 생각합니다. 사업을 접을 수가 없어서 하도급 업체로 변신하는 회사들이 나오지 않도록, 투자 요건은 보다 강화되어야 할 것으로 생각되고요. 하도급 생활을 오래 한 업체들이 스스로 '솔루션 업체'로 거듭날 수 있도록 지원하는 방책이 마련되어야 할 것으로 생각됩니다. 그러니까 어떻게든 용역 시장을 줄여야 한다는 것이죠. 용역은 사실 '남의 솔루션'을 '내 몸을 대서' 대신 만들어 주는 행위입니다. 그 시장이 줄어들려면 자기 솔루션을 보유한 업체들이 많이 생겨야만 하죠. 


그리고 사실, 그런 '솔루션' 업체들이 활성화 되려면, 일단 '솔루션'을 만드는 것이 시장성이 있는 행위라는 것이 입증되어야 합니다. 우리나라 대기업들은 뭔가 조그만 회사가 그럴듯한 솔루션을 만든 것을 발견하면 그 회사를 제값주고 인수하기 보다는 비슷한 솔루션을 용역주고 개발해서 출시한 뒤 망하게 만들어 버리는 방법을 구사해 왔기 때문에 (묵념) 솔루션 활성화 보다는 용역 활성화에 더 기여해 왔다고 보는 것이 옳죠. 해외처럼 솔루션 업체의 창업이 활성화되려면 (그야말로 기술창업이죠) 대기업도 생각을 좀 바꾸는 것이 옳습니다. 대기업이 나서서 투자를 해야 하고, 투자가 잘 된 것으로 판단되면 M&A를 하던지 회사를 키우던지 하는 방식으로 나갈 수 있어야 한다는 것이죠. 그렇지 않으면 다단계 하청구조는 끊기 어렵습니다. 


그리고 정부는 등급제나 '개발자 10만 양병' 같은 삽질성 정책은 좀 그만 내놓고, 좀 더 그럴듯한, 그러니까 실제로 하도급 업체를 뛰어다니며 만나본 냄새가 좀 나는 정책을 내놓도록 애쓰는 것이 좋겠어요. 


이 글은 수시로 업데이트 하겠습니다. 좋은 의견 부탁드립니다. 



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

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

  1. Yup

    굉장히 좋은글인거 같은데 답글이 없네요 !

    넓은 안목과 깊은 지적 잘 보았습니다!

    2014.07.14 13:00 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 윌슨

    정말 좋은 분석입니다.
    읽고나니 큰 그림이 잡히네요.
    감사합니다~

    2014.12.10 14:35 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. 흠흠

    잘못된 정책이나 누군가의 의지라고 하기엔 시장이 단순하지 않죠. 현실적으로 한국은 SI 위주로 IT 산업이 형성되어 있어 초급 개발자의 수요가 엄청 많습니다. 그렇기 때문에 고위 말씀하신 '개미지옥' 레벨에 있는 개발자들이 많은 것이고, 또한 진입장벽도 다른 기술직군에 비해 매우 낮습니다. 그러니 볼멘소리도 많을 수 밖에 없지요.

    그리고 용역단가에 대한 문제는.. 인건비를 내리지 못하게 막는건 거의 불가능한 일입니다. 싼 값에 일을 하려고 하는 초급자들이 있는 한 바뀌지는 않을겁니다.

    2016.02.19 10:55 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2013.12.28 22:53

앞선 글에서, 저는 이런 질문을 던졌습니다. "왜 상당수의 개발자들은 하청업체를 떠나지 못하는 걸까?" 어떻습니까. 여러분은 이 질문이 정당하다고 생각하시나요?


http://blog.job.go.kr/3573


SEE ALSO: "다단계 하청구조는 왜 생기나? (1)"


이 글을 보고 계시는 분께서 개발자라면, 아마 이런 질문은 부당하다고 느끼실 겁니다. 꼭 개발자에게 책임을 떠넘기는 것 같으니까요. 하지만 저는 이렇게 물어야 좀 더 문제의 심각성이 선명히 드러난다고 믿습니다. 왜죠? 그 이유를 좀 더 정확히 설명하려면, 여러분과 저는 한 가지 정리에 동의해야 합니다.


Theorem 1: 개발자는 바보가 아니다. 


자. 개발자들이 바보가 아닌 담에야, 하청업체의 일원으로 일하는 부당함을 몸소 겪으며 자신을 소진시켜 가면서 버텨야 할 이유가 있을까요? 없을 겁니다. 그런데도 계속 그 바닥에 남아 일하고 있다면, 이유는 딱 하나죠. 


Theorem 2: 어딜 가나 개미지옥이다. 


그 이야기는, 소위 '초중급'을 따져가면서 일할 수 밖에 없는 대부분의 개발자가 갈 수 있는 직장이 하청업을 전문으로 하는 직장일 가능성이 굉장히 높다는 겁니다. 관련 링크(http://okjsp.net/seq/110080)를 한번 보시면 분위기를 대충 아실 수 있을 것 같은데요. '악덕 사장에게 걸리면 안된다'거나, '모르면 속는거고 협상하기 나름이다' 같은 분위기가 팽배해 있죠. 중급으로 확실히 인정받을 때 까지는 견뎌야 한다는 것이 인터넷 커뮤니티를 통해서 느낄 수 있는 개발자들 사이의 공감대인데요.


그러니까 이 대목에서 우리가 확실히 알 수 있는 것은 딱 하나입니다. 


Theorem 3: 중급 개발자의 스펙을 쌓을 때 까지는 견뎌야 한다.


다시 말해 초급 개발자로서 고를 수 있는 직장은 '개미지옥' 뿐이고, 중급 개발자가 되어야만 '개미지옥'을 탈출할 수 있다는 이야깁니다. 그런데 이런 인식을 통해 우리가 느낄 수 있는 것은 무엇이죠? 그것은 대한민국의 개발자 소비시장이 철저하게 양분되어 있다는 것입니다. 초급 개발자를 소비하는 개미지옥과, 그 이상의 개발자를 소비하는 소위 '더 나은 직장(the better tomorrow)'로 나뉘어 있다는 것이죠. 


이 모델은 '하청업체를 떠나지 못하는 개발자들의 아우성'이 그토록 거센 이유를 잘 설명해 줍니다. 초급 개발자를 면하는 그 순간까지 (군대 갔다오는 것 보다 한참 더 긴 시간입니다) 개미지옥에서 견뎌야 하는데, 그 과정이 녹록할 리가 없으니 아우성이 나오는 것이죠. 또한 이 모델은, '개발자들이 성장하지 못하는 이유', 다시 말해 '시장에 쓸만한 개발자들이 거의 언제나 부족한 이유'도 잘 설명해 줍니다. 개미지옥은 개발자의 성장을 담보하는 조직이라기 보다, 개발자들을 소진하고 나가 떨어지게 만드는 조직입니다. (물론 거기서 굳건히 살아남은 소수는 중급 개발자의 길을 걷습니다만, 개발자로 입에 단내나게 삽질한 그들이 과연 개발자로 만족하며 아키텍트로 성장할지는 의문이죠. 개발자라는 딱지를 스스로 벗어버릴 가능성도 언제나 있습니다.) 그러니 시장에 많은 중급 개발자들이 지속적으로 공급될리가 없지요. 그나마 탄생한 중급 개발자들은 바로 더 나은 직장을 찾아 떠나버릴 것이니, 중소 업체들이 쓸만한 직장을 구할 가능성은 점점 낮아집니다. 


자. 그런데 이 모델은 '왜 그토록 하청업체들이 많은지'는 잘 설명하지 못합니다. 하청업체들이 마치 우주의 배경복사처럼 널려있다고 가정하고 만들어진 모델일 뿐이니까요. 하청업체들이 그토록 많은 이유는, 다른 곳에서 찾아야 합니다. 


IMF가 도래하기 직전, 대한민국에도 닷컴 바람이 불었었습니다. 이 때 마치 빅뱅처럼 수많은 닷컴 기업과 투자사들이 생겼습니다. 그리고 IMF의 한파가 겹치자, 이들 가운데 상당수가 무슨 백색왜성마냥 스러지기 시작했습니다. 그러나 대한민국의 닷컴 기업에는 한 가지 자유가 없었는데요. (최근에 더 심해졌습니다.) 바로 실패할 자유였습니다. 대한민국에서 사업을 접는 건 사업을 하는 것 보다 더 어렵습니다. 설사 사업을 접는 데 성공하더라도, 이제는 재기하는 것이 문제입니다. 사업을 접고 재기하는 건 사업을 접는 것 보다 만 배 정도는 더 어렵습니다. 그러니까 사업을 접는 건 애시당초 안될 말입니다. 어떻게든 사업을 계속해야하죠. (투자사에게서 몇억씩 받은 값은 다 해야 하니까요.) 


대부분의 닷컴 기업은 아이디어로 만들어진 기업이지 기술력을 바탕으로 만들어진 기업들이 아니었기 때문에, 어떻게든 살아남기 위해서는 자기 인력을 활용해 현금장사를 할 수 있는 사업모델이 필요했습니다. 그 중 가장 안전한 것이 바로 하청과 재하청이었죠. 이렇게 해서 1세대 하청업체들이 만들어집니다.


그런데 이 상황은 지금이라고 해서 딱히 다르지 않습니다. 지금 창업되는 기업들은 대체로 솔루션 업체이거나 서비스 업체입니다. 서비스 업체들은 보통 투자를 받아 개발을 시작하고 서비스가 망하면 하청업체로 환골탈태하는 수순을 밟는 경향이 있습니다. 솔루션 업체들은 투자를 받아 의욕적으로 솔루션을 완성한 다음에 솔루션이 안팔리면 하청 업체로 환골탈태하는 경향이 있죠. (2, 3, 4세대 하청업체들이 만들어지는 메커니즘도 비슷하다는 겁니다.)


Theorem 4. 섣부른 투자 유치가 하청업체로의 변신을 부채질한다. 


투자를 받으면 돈 값을 해야 하기 때문에 ㅈ망했다는 것이 판가름나도 사업을 못 접습니다. 그러니 하청이라도 해야 하죠. 처음에는 부푼 꿈으로 시작했던 창업이 직원들에게는 아무런 꿈도 주지 못하는 회사로 귀결되는 것은 대체로 섣부르게 받은 투자 때문이다, 라고 저는 생각합니다. 


따라서 저는, 서비스 업체는 투자를 받기 전에 서비스를 반드시 먼저 릴리즈 하고, 시장의 반응을 봐야 한다고 생각합니다. (투자도 못받았는데 어떻게 서비스를 개발하냐구요? 그러니까 능력있는 개발자를 영입해야죠. 그게 어렵다구요? 그럼 이런 질문을 받으실지도 모릅니다. 개발자 한명도 설득 못시키는 아이템으로 어떻게 성공하려고 하셨나요?) 또한 저는, 솔루션 업체라면 투자를 받기 전에 솔루션의 초기 버전을 반드시 먼저 릴리즈하고, 시장의 반응을 봐야 한다고 생각합니다. (오픈 소스라는 거대한 흐름 덕분에, 요즘은 이런 '입질'을 먼저 해 보기가 굉장히 쉬워졌죠.) 그리고 저는, 솔루션 업체라면 걍 미국에 가서 사업을 하는 것이 훨씬 낫다고 생각합니다. (그 이유는 다음에 말씀드릴 기회가 있을 듯.)


물론, 이렇게 '선 개발 후 투자'라는 모델을 따르면, 창업을 하기가 훨씬 어렵습니다. (물론 쉽게 창업하는 것 보다는 훨씬 낫다고 생각하지만요.) 그런데 그런 문제를 해소하고 '선 투자 후 개발'을 유도하려면 대한민국에서 '투자로 만들어진 기업을 청산하는 절차'가 굉장히 쉬워져야 하는데, 정말로 정말로 해결되기는 어려운 문제이므로 그냥 넘어가도록 하겠습니다. 


자. 그런데 지금까지 저는 한 가지에 대해서는 말하지 않았습니다. '개미지옥'이 계속 지속되는 이유에 대해서는 말하지 않았는데요. '개미지옥'에게 계속 돈을 대서 시장을 유지시키는 다른 기업들에 대해서는 아무래도 다음 글에서 이야기를 해야 할 것 같군요.


[다음 글에 계속]



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

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

  1. 연재 하시는 글 잘 보고 있습니다. 정말 우울한 국내 프로그래머 시장이죠.

    2013.12.30 17:51 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2013.12.28 08:28

요즘 신문을 보면 개발자의 처우에 관한 글을 어렵지 않게 만날 수 있습니다. 많은 개발자들이 '갑을병정무기' 가운데 '무기'에 해당하는 하청을 하는 일도 적지 않다는 이유로, 자신을 '무기'라는 자조섞인 용어로 부르기도 한다는 이야기도 들리더군요. 그러니까 이런 기사의 요지는, 많은 개발자들이 다단계 하청구조에서 발생하는 여러가지 폐해들로 고생하고 있다는 이야기였습니다. 그런 폐해들로는 어떤 것이 있을까요?


(1) 낮은 임금

(2) 비정상적인 납기일


이 두 가지 요인은 개발자들의 삶의 질을 결정적으로 떨어뜨리고, 결국 IT 업계에서 개발자로 일하는 것을 포기하게 만듭니다. 당연한 결과죠. 월급도 코딱지만큼 주는데 비정상적인 데드라인때문에 집에도 갈 수 없는 날이 많다면, 어떤 사람이 미쳤다고 개발자로 일하고 싶어하겠어요?



그런데 문제는, 모 기사에서 지적한 것과 같이, 상황이 이런데도 아직 업체에서는 인력부족 타령을 한다는 겁니다. 그렇다면 이런 궁금증이 생길 수 있겠어요. 아니 사람이 부족한데 왜 개발자의 임금은 아직 저 모양이지? 사실 그렇짆아요. 수요는 많은데 공급이 부족하면 당연히 그 가격은 올라가야 맞습니다. 그런데 지금은 수요는 많고 공급이 절대적으로 부족한데도 개발자들의 가치가 전혀 올라가질 않아요. 비정상적이죠.


사실 이런 비정상적인 상황은, 개발자들에게 등급을 매길 때 부터 어느 정도 예견되었다고 보는 것이 옳습니다. 정부에서 나서서 모든 개발자들에게 '초급, 중급, 고급'의 딱지를 매기려고 했던 것을 여러분들은 기억하실겁니다. 그리고 그 결과, 지금 모든 개발자들은 이 바닥에서 일한 기간, 학위 소지 여부 등등 다양한 기준에 따른 '딱지'를 한 장씩 가지고 있죠. 문제는 이 딱지들이 하청 개발자들이 받을 수 있는 임금의 최대치를 규정하는 데 쓰인다는 겁니다. 


보통 하청을 줄 때 쓰는 공급 계약서를 보면, 인건비 비목이 있어요. 그런데 이 인건비 비목을 작성할 때 어떻게 쓰게 되어 있느냐면, 초급개발자 몇명 중급개발자 몇명 고급개발자 몇명을 프로젝트에 투입할 예정이냐에 따라 쓰도록 되어 있어요. 전부 고급개발자라면 인건비로 소요될 비용이 올라가게 될 것이고, 전부 초급이면 인건비로 소요될 비용은 내려가게 되어 있죠. 어쨌든 중요한 것은 말이에요. 최대치가 정해져 있다는 겁니다. 이런 상황에서는 공급이 아무리 딸리는 상황에서 하청을 줘도 하청 단가가 올라갈래야 올라갈 수가 없어요. 그러니까 하청 일을 하는 사람이 존 카멕이라고 해도 돈을 더 받을 수는 없게 되어 있다는 거죠. (응?)


그러니 많은 개발자들은 '개발자 10만 양병론'같은 이야기를 헛소리로 받아들일 수 밖에 없어요. 왜 그렇죠? 이런 형태의 시장에 개발자들을 잔뜩 양성해서 부어 놓으면 (김영삼 정부때 그랬었습니다만) 개발자 1인이 갖는 가치, 다시 말해 한 건의 프로젝트를 끝내기 위해 투입되어야 하는 인건비는 더 내려갈 것이 뻔하기 때문입니다. 아마 기업들은 당장 사람들이 부족하니까 개발자들을 더 양성해야 한다는 이야기를 하는 모양이고, 정부에서는 그런 요구에 맞춰 춤을 추는 모양인데 이런 상황을 안다면 사실 내 놓을 수 없는 정책이죠.


자. 그렇다면 대체 하청구조는 왜 생기는 거죠?


하청구조는 '내가 직접 하는 것 보다 다른 사람 시키는 것이 싸니까' 생긴다고 볼 수 있습니다. 그럼 IT 프로젝트를 하는 데 있어서, '다른 사람 시키는 것이 더 저렴한' 이유는 무엇인가요? 여러 가지 이유를 생각해 볼 수 있겠습니다. 


(1) 직접 개발하려고 해도 개발자가 없어서

(2) 외주 개발 단가가 저렴해서 


자. 제도적으로 외주 개발 단가를 올릴 방법을 차단한 현 시점에서, 외주 개발 단가는 당연히 저렴할 수밖에 없죠. 그런데 외주 개발 단가가 지금처럼 저렴해지기 전에는 하청이 없었나요? 아마 아닐 겁니다. 이 바닥에 사람이 없다는 이야기는 한 두 해 한 것이 아니고, 개발자 등급제가 시행되기 전에도 이미 하청 구조는 있었거든요. 대한민국의 개발 하청제는 역사가 깊어요. 개발자 등급제가 낮은 개발 단가를 고착시키는 역할을 하긴 했지만, 그 전에도 분명히 있었습니다. (사실 개발자 등급제 전에도 개발자들을 등급으로 나눠 분류하는 방법은 있었습니다. 그리고 그 기준에 따라 인건비를 산정했죠. 개발자 등급제는 그것을 명문화했을 뿐이라고 보는 분들도 있습니다.) 


그렇다면 이 문제는 우리가 생각하는 것 보다 훨씬 더 복잡한 것임에 분명합니다. 그리고 이 문제에 대해 올바른 답을 하려면, 다음의 질문들을 좀 더 깊이 있게 생각해 봐야 할 것이 분명해요. 


(1) 정말로 개발할 사람이 없나?

(2) 개발자들이 하청일을 떠나지 못하는 이유는 무엇인가?

(3) 하청 업체가 생기는 이유는 무엇인가?

(4) 하청 업체가 하청 일만 죽어라 하게 되는 이유는 무엇인가? 


개발할 사람이 없는 것은 사실인 것 같으니까 (저희 회사에서도 실제로 겪고 있는 문제입니다) 넘어가기로 하죠. 사실 이 문제를 깊이 있게 따지는 것은 지금의 상황에서 시간낭비에 가까와요. 우리 모두 왜 개발자가 부족한지는 알고 있는데, 이 문제의 근본적인 원인을 따지는 것은 이미 '닭이 먼저냐 달걀이 먼저냐'라는 식의 질문에 가까와서 전혀 생산적이지가 않죠. 다만 한가지는 언급할 필요가 있겠습니다. '개발자가 부족하다'는 것은 실상 정말로 개발자의 수가 적어서라기 보다는, 개발자를 뽑으려고 하는 회사가 정한 특정한 기준을 충족하는 개발자가 적다는 뜻일 수 있다는 것을요. 그렇게 본다면, 우리는 왜 개발자가 부족한지를 묻기 이전에, 대한민국에서 왜 개발자가 성장하지 못하는 지를 물어야 합니다. 그래야만, 실제로 구인 공고를 내는 회사들이 내건 기준을 충족하는 개발자들이 적은 이유가 무엇인지를 제대로 설명할 수 있을 것으로 보이기 때문이죠. 그리고 그 당위성을 인정한다면, 위의 (2)~(4)의 질문에 집중할 수 있죠. 하청구조라는 것이 개발자를 성장시키지 못하는 한 원인이 되고 있음은 분명해 보이니까요. (그렇지 않다면 개발자들이 왜 그렇게 아우성이겠어요?) 


자. 그럼 본격적으로 두 번째 질문으로 넘어가보죠. 그렇다면 개발자들이 하청일을 떠나지 못하는 이유는 무엇인가요? 하청일이 싫으면 때려 치고 다른 회사로 가면 되지 않느냐고 누가 물으면, 어떤 대답을 해 주어야 하나요? 


(1) 옮길 회사가 없다

(2) 옮겨도 마찬가지다

(3) 옮기면 받아야 할 돈을 못 받을 것 같다


[다음 글에서 계속]



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

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

  1. 이런식의 발전으로 국내 대기업들이 얼마나 발전할지 모르겠습니다. 새마을운동도 아니고 다같이 으쌰으쌰하는 비즈니스가 아닌 갑을관계의 착치구조는 분명 언젠가는 붕괴될거라고 굳게 믿고, 그래야한다고 생각합니다.
    대기업들의 무리한 원가절감이나, 무리한 요구에의한 lead타임감소가 아닌, SCM에 의한 물류효율화 또한 올바른 사회발전과 경제발전에 큰 힘이 된다는것을 마음 깊히 알고 실천해야, 진정한 선진 기업으로 나갈 수 있는 글로벌이 아닌가 생각해봅니다.

    2013.12.28 08:51 신고 [ ADDR : EDIT/ DEL : REPLY ]

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 이병준

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