Thoughts2014.01.24 12:19

#1.


코드에 새로운 기능을 추가하는 시간이 점점 길어지고 느려지고 따분해지고 지겨워진다면 바로 그 때가 리팩터링 시점이다. 물론 '코드에 새로운 기능을 추가하는' 것은 대체로 '요구사항의 변화'를 의미하므로, 요구사항이 계속 밀려드는 바쁜 시점에 코드를 리팩터링한다는 것이 부담이 될 수도 있겠다. 만일 지금 당장 리팩토링 할 수 없다면, 나중에 따로 시간을 내서라도 프로그램 구조를 변경해 놓는 것이 바람직하다. 그렇지 않으면 나중에 유지보수해야 할 시점이 되었을 때 피를 보게 될 것이다.


#2. 


프로그램이 너덜너덜해져서 보기 끔찍할 지경이 되어가고 있다면, 리팩터링을 심각하게 고려하는 것이 바람직하다. 그렇게 될 지경까지 대체 뭐 했느냐고 묻는 사람이 있을 수도 있으나, 일정 시점까지는 합리적이었던 구조가 시간이 자나면서 점점 불합리하게 바뀌는 경우도 있으므로 (소프트웨어 개발 과정은 생산 공정과는 다르다는 것에 유의하자) 처음에 아무리 잘 설계한 프로그램이라 해도 이런 일이 생기지 않으리라는 보장은 없다.


#3. 


당신의 라이브러리의 유저가 라이브러리의 사용성에 대해 의문을 제기하기 시작한다면, 아마 본인으로는 만족스럽더라도 리팩터링을 고려해봐야 할 것이다. 사용성이 만족스럽지 않다는 것은 잘못 설계되었다는 증거일 수도 있다. 잘못 설계된 구조를 계속 고수한다는 것에는 별로 의미가 없다. 그리고 결정적으로 사용하기에 문제가 있는 라이브러리들은 '유저가 원하는 대로 확장하기 곤란한' 라이브러리라는 문제도 갖는다. 





#4. 


파일명, 클래스명, 함수명을 봐서는 대체 뭘 하는 모듈인지 정확하게 알 수 없을 때는 역시 리팩터링을 심각하게 고려해 봐야 한다. 문서를 봐도 알 수 없다면 상황이 심각한 것이므로, 역할에 따라서 모듈을 적절히 나누어 주어야 한다. 그런 작업을 할 때는 다른 개발자들에게 혼란을 줄 수 있으므로 주의해야 한다. 


#5. 


더 나은 구조가 있을지도 모른다는 생각이 든다면, 그 때가 아마 리팩터링을 하면 좋은 시점일 것이다. '더 나은 구조'에 대한 갈망은 대체로 현재 구조에 대한 불만에서 출발한다. 해결책이 없다면 일단은 포기하더라도, 문제를 머리에 넣어놓고 일정한 시간이 지나면 대체로 해결 방안이 떠오른다. 해결 방안을 적용할 때는 바로 소스코드를 수정하려는 시도를 하는 대신, 원래 구조와 비슷한 구조의 모형 프로그램을 만들어서 시험해 본 다음에 적용하는 것이 좋다. 




Posted by 이병준

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

Thoughts2014.01.14 09:18

개발자들의 집중을 막는 요인에는 회의 등 외부적인 요인도 많겠습니다만, 웹 검색이나 인터넷 이용 등의 개발자 내부적인 요인들도 있습니다. 몰입을 방해하는 이런 요소들을 제거하고 온전히 업무에만 몰두하기 위해서는 훈련이 필요할 때도 많은데요. 그럴 때는 모래시계를 사용하는 것도 도움이 됩니다. 





10분 정도의 모래시계면 이 용도로는 충분한데요. 모래시계를 뒤집어 놓고 일을 하다가 집중이 흐트러졌을 때 모래시계를 보면 10분동안 몰입할 수 있었는지 없었는지를 알 수 있기 때문에 좋습니다. 모래시계를 사용해서 이런 저런 일들을 한 번 해 보시기 바랍니다. 


1. 10분동안 리팩터링 

2. 10분동안 책 한 페이지

3. 10분동안 논문 한 페이지

4. 10분동안 디버깅

5. 10분동안 클래스 설계

6. 10분동안 메서드 1개 코딩 

7. 10분동안 잡일 처리 

8. 10분동안 휴식


10분이라는 시간을 모래시계를 통해 재면서 이런 저런 일들을 처리할 때는 주의할 점이 있는데요. 가장 주의할 것은 중간에 자꾸 시계를 보지 않도록 하는 겁니다. (우리가 집중하려는 것은 10분이라는 시간 그 자체가 아님을 명심합시다.) 하기로 한 일을 마치거나 문득 딴짓에 손이 갔을 때 10분이 지나있는지만 살펴보면 됩니다. 10분이 채 지나지 않았다면 집중력을 더 개선할 여지가 있는 것이고, 10분이 지났다면 더 오랜 시간 집중할 준비가 되었다고 생각할 수 있는 것이죠.


또 한가지 주의할 것은 10분이라는 시간에 맞추기 위해서 너무 급하게 모든 일을 처리하려고 하지 않는다는 겁니다. 버그가 있는 코드를 만드는 것 보다는 그렇지 않은 편이 나으니까요. 모래시계를 통해 달성하려는 목적은 집중력을 올리는 것이지 더 많은 일을 처리하는 것이 아님을 명심할 필요가 있습니다. (물론 집중력이 올라가면 저절로 더 많은 일을 처리하게 되기도 합니다.)


이런 식으로 하다 보면 업무 집중도를 굉장히 개선할 수 있고, 짧은 시간에 다시 몰입 상태로 돌아갈 수 있습니다. '고개를 들어보니 퇴근시간이더라'는 드문 경험을 꽤 자주 할 수 있게 될 겁니다. (저도 그랬습니다.) 비결은 아마 긴장감을 계속 유지하게 된다는 점이 아닐까 싶습니다. 그리고 10분 단위의 단기목표를 하루 종일 성취하고 회고하는 데서 오는 뿌듯함도 한 몫을 하겠죠. 



Posted by 이병준

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

  1. http://ebook.insightbook.co.kr/ebooks/4fa07b22bf6e100ce9000011

    2014.01.14 14:52 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 진한여운

    좋은 글 항상 잘 보고 있습니다. 댓글은 처음 달지만요.. ^^;
    본문중에 한가지 문의드리는 것은..
    10분이 지나있다면 과 10분이 채 지나지 않았다면의 내용이 서로 바뀐것이 아닌가 싶어서요.
    10분이 지나도록 집중을 했다면 더 오랜시간 할수있는 준비가 된거고, 10분이 채 지나지않고 딴짓을 하거나, 시계를 봤다면 좀더 10분집중을 개선해야하는 것이 아닌가.. 해서요..
    제가 잘못 이해한건가요~
    저도 10분 집중 시작해보려구요~ ㅎ

    2014.01.15 13:54 신고 [ 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 ]

Thoughts2014.01.02 23:08

새해가 되면 누구나 계획을 세웁니다. 올해는 담배를 끊겠다, 올해는 술을 끊겠다, 올해는 영어공부를 하겠다, 올해는 새로운 프로그래밍 언어를 배우겠다.... 등등 셀 수 없이 많은 계획을 세우죠. 그러나 역시 개발자로서 가장 현실성 있는 계획은 아무래도 새로운 프로그래밍 언어를 배우는 것. 저는 올해 Julia라는 언어를 한 번 배워볼까 계획중인데요. 앞선 글에서도 밝혔듯이, 새로운 프로그래밍 언어를 배우는 것은 프로그래머에게 있어서 굉장히 중요합니다. 프로그래밍을 바라보는 시각의 지평을 넓혀주기 때문이죠.



여러분은 어떠십니까? 이 블로그를 방문하는 분들은 과연 올해에는 어떤 프로그래밍 언어를 배우려 하실지, 저도 사실 굉장히 궁금한데요. 여러분의 계획을 이 블로그를 찾는 다른 분들과도 한 번 나눠보지 않으시겠어요? 아래에 투표지를 마련했습니다. 결심을 공개하면 작심삼일의 위험을 피할 수 있다는 것을 명심하세요 (응?). 아 그리고, 하나만 고르지 않으셔도 됩니다. (수줍)


SEE ALSO: 파이썬을 배워야 하는 다섯가지 이유

SEE ALSO: 자바를 배워야 하는 다섯가지 이유


online poll by Opinion Stage


이 블로그를 찾아주시는 모든 분들께, 2014년 한해 동안 CODE의 FORCE가 충만하기를!



Posted by 이병준

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

  1. 저는 컴전공자는 아닌데 요새 블로그하면서 html 과 ccs 같은거 배워보고싶네요 ㅋ

    2014.01.03 03:19 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 염구나

    전 언어전환 이슈가 있어서 상반기에는 자바(스프링)을 배워야 할 것 같고 하반기에는 파이썬을 해볼까 생각 중입니다.

    2014.01.03 12:42 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. 명뷁

    음......... 매번 공부한다고 하고.. 안하내요 ㅎㅎㅎ;;

    전 JAVA와 안드로이드 등 을 좀더 공부해볼까합니다.

    2014.02.27 15:08 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2014.01.02 09:40

용의자는 대단한 액션 영화입니다. 누군가는 용의자의 내러티브에 창의성이 결여된다고 언급하기도 한 모양입니다만, 사실 요즘 액션 영화의 줄거리는 대체로 '다 거기서 거기'죠. 그래도 그 정도의 의외성을 끌어내고, 결말에 이르는 순간까지 어색함 없이 (결말에 가까와지면 응? 싶은 부분이 두어군데 나오긴 합니다만, 애교로 봐 줄 수 있는 수준이긴 합니다) 끌어간 것은 높이 사고 싶습니다. 의외다 싶은 반전도 초반부의 복선과 맞물려 만족스러운 효과를 내 주고 있구요.



공유의 '몸을 사리지 않는 연기'도 볼만합니다. 한 배우의 열정이 영화 전체를 온전히 지배하는 것이 고스란히 느껴질 정도죠. 박희순의 연기는 다소 오버스러워서 거북스럽게 느껴질 때도 있었습니다만 (특히 초반부) 영화 후반에 가면 균형을 되찾습니다. 유다인의 기자 연기는 지나치게 정형화되어 있다는 느낌이 들었습니다만, 그래도 자기 몫을 충실하게 해 냈다는 느낌입니다. 


배우 조재윤


영화의 무거운 분위기를 완충시키는 역할을 아주 훌륭하게 해 낸 조재윤의 연기는, 칭찬해 주고 싶습니다. '추적자'에서 건달 역을 훌륭하게 소화해 내면서 명품 조연으로서의 가능성을 훌륭하게 입증해 보인 이 배우는, 주연 옆에서 주연을 빛나게 해 주는 역할이 어떤 것인지의 전범을 보여줍니다. 이런 역할로 성공한 배우로는 유해진, 오달수, 성동일 등의 배우가 떠오르는데요. 그런 배우들의 계보를 충실하게 이어줄 것으로 기대됩니다.


그러나 아쉬운 것은 액션을 잡는 촬영입니다. 핸드 헬드(hand-held) 촬영이 대세이긴 합니다만, 거의 모든 장면에서 화면은 지나칠 정도로 흔들립니다. (그런 의미에서 '아저씨'의 촬영은 모범적이라 할 만 한데요. 핸드 헬드로 현장감을 높이면서도 액션을 감상하고자 하는 관객의 욕구를 훼손하지 않는 선에서 안전하게 모든 배우를 관찰하죠.) 그래서 도무지 누가 누구를 어떻게 치고 어떻게 꺾고 어떻게 분지르는지 잘 감이 오지 않을 때가 있어요. (앞자리에서 보시면 더 심합니다. ㅎ) 액션을 감상하러 간 관객의 한 사람으로서 아쉬운 부분이었습니다. 


지나칠 정도로 복잡한 스토리를 깔끔하게 풀어낸 감독의 역량을 높이 사고 싶습니다만, 이 점은 아쉽습니다. 다음에 찍을 영화에서는 그 점을 좀 더 고민했으면 좋겠어요. 그리고 용의자를 보러갈 다른 관객 여러분께는, 한 가지를 조언하고 싶습니다. 가능한 한 뒷 자리에서 보세요. 그럼 훨씬 쾌적하게 관람하실 수 있을 겁니다.



Posted by 이병준

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

Thoughts2013.12.24 17:40

변호인은 잘 알려진 한 남자의 일생 가운데 'AWAKENING'에 해당하는 사건을 다루는 영화다. 이 영화의 주인공 '송우석' 변호사의 인생은 그 사건을 전후로 극명하게 달라진다. (스포일러에 해당하므로 그 '사건'이 무엇인지는 여기서 이야기하지 않겠다.)


사실 특정 인물을 소재로 삼았다는 것을 제외하면, 이 영화의 내러티브에는 전혀 신기한 구석이 없다. 음모가 있고, 그 음모에 구속당한 인물들이 있다. 그 인물들을 구하기 위해 '인간 말종'으로 살던 한 사내가 몸을 던진다. 그 과정에서 스스로 개과천선하고, 전혀 다른 남자가 된다. 그야말로 '정의의 수호신'이 된다. 어떤가. 익숙한 이야기 아닌가? 




지나치게 오랫동안 변주되어 온 탓에, 관객들은 이런 류의 스토리에 익숙하다. 익숙한 스토리는 따분해야 마땅하다. 그러나 '변호인'은 전혀 따분하거나 지루하지 않다. 무엇때문일까. 결론은 하나다. 바로 이 이야기가 우리 주변에 살았던 한 남자의 이야기이기 때문이다. 


앞서 말했다. '변호인'의 스토리는 이미 따분할 정도로 자주 변주된 정형적 내러티브의 동어반복이라고. 이런 반복이 계속될 수록, 관객들은 믿지 않는다. 그런 스토리의 주인공이 현실에 정말로 존재할 수도 있다는 사실을. 그렇지 않은가? 그런 사람들을 만나는 가장 좋은 방법은, 극장에 가거나, TV를 켜고 드라마를 보거나, 인터넷을 통해 다운받은 영화를 보거나, 소설책을 보는 것이다. 우리 주변에서 흔히 볼 수 있는 사람들은 대체로 타협하고, 협상하고, 원칙을 희생한다. 


그래서인지, 우리들 중 상당수는 그런 인물이 현실에 존재할 가능성을 애써 부정해 왔다. '변호인'의 주인공 송우석은, 국밥집 아들에게 이렇게 일갈한다. '세상이 그렇게 말랑말랑해? 데모 몇번 한다고 세상이 바뀌어?' 이 말은 사실 '혼자서 깨끗한 척 하지 말라'는 말을 자조적으로 내뱉은 것에 불과하다. 그리고 '혼자서 깨끗한 척 하지 말라'는 말은, 사실 '너희같은 놈들이 있으면, 우리 같은 사람들은 너무 불편하다. 그러니 제발 존재하려고 하지 말라'는 말을 좀 점잖게 한 것일 뿐이다.  


그러나 좋건 싫건 간에, 우리는 그런 사람들과 동시대를 살았다. 그러니까 다시 말해서, '대한민국은 자유민주주의 국가이고 그 국가의 모든 주권은 국민에게서 나온다는 헌법적 진리를 수호하기 위해 모든 것을 내 던졌던 사람들과 같은 시대를 살았다'는 말이다. 이 영화의 힘은, 바로 거기에 있다. 우리 주변에 그런 사람들이 있었다는 것. 그리고 우리가 지금 디디고 있는 자유 민주주의의 토대는 바로 그 사람들이 쌓아올린 것이라는 아주 단순한 사실을, 정말 소름끼치도록 직선적인 방식으로 일깨우는 것이다. 


그러니까 이 영화가 새삼 감동적인 것은, 사실 굉장히 참담한 현실을 일깨우는 것이기도 하다. 그런 지도자가 없는 대한민국, 그런 사람들이 애써 쌓아올린 가치들이 너무나 손쉽게 훼손되는 대한민국, 그리고 그런 가치를 훼손하는 사람들이 훨씬 더 편안하고 안락하게 살아가는 대한민국. 이런 현실 속에서 '민주주의라는 유산'이 무엇을 의미하는 지, 우리는 대체로 깊이 생각해 볼 겨를이 없이 살아간다. 그러니 송강호의 신들린듯한 연기에 취한 우리 가슴이 이토록 격렬하게 뛰는 것도, 무리는 아니다. 


이 영화는 우리에게 묻고 있다. 당신의 민주주의는 과연 안녕하신가, 하고. 이 물음에 가슴이 쉬이 뜨거워지는 것을 보면, 그다지 안녕한 것 같지 않다고 해야 옳을 것이다.



Posted by 이병준

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

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 13:48

1. 보통 개발자는 선형적인 일을 하고, 뛰어난 개발자는 지수적인 일을 한다. 


보통 개발자는 대개의 경우 시간을 많이 들이면 해결될 문제를 풉니다. 고급 개발자는 고민하지 않으면 해결되지 않을 문제를 풉니다. 이런 문제로는 (1) 소프트웨어의 구조 (2) 소프트웨어의 성능 등, 고민과 실험과 선택을 요구하는 문제들이 있습니다. 소프트웨어의 패턴을 찾아내는 것은 보통 이런 수준의 개발자들입니다. 고급 개발자들이 프로젝트 초기에 해결한 문제들은 프로젝트의 진도를 획기적으로 개선합니다. 


2. 보통 개발자는 문법 때문에 고민하고, 뛰어난 개발자는 알고리즘 때문에 고민한다. 


보통 개발자에게 중요한 것은 프로그래밍 문법과 그것이 야기하는 오만가지 재미있는 문제일지 모르지만, 고급 개발자가 고민하는 것은 보통 문제의 본질에 더 가깝고, 그것은 보통 수학적인 형태를 띱니다. 그래서 '훌륭한 프로그래머가 되려면 수학을 잘 해야 한다'고 이야기하곤 하죠. 


프로그램 세계에서 이 수학은 보통 알고리즘과 맞닿아 있습니다. 프로그래밍을 공부하면서 알고리즘과 관련된 수학의 중요성을 느껴보지 못한 분이라면, (딱히 수학적인 책은 아닙니다만) "생각하는 프로그래밍"을 추천합니다. 제가 가장 좋아하는 절은, 이진 탐색이 어떻게 발전했는지를 다루는 절입니다. 읽어볼만 합니다. iTunes U의 알고리즘 개론 수업도 괜찮습니다. 



3. 보통 개발자는 남의 솔루션 때문에 고민하고, 뛰어난 개발자는 자기 솔루션 때문에 고민한다.


고급 개발자라면 자기가 주도적으로 설계하고 만든 솔루션이 하나는 있게 마련. 그것이 아무리 작건 간에 그것 때문에 고민하고 있고, 그 솔루션을 사용하는 사람들로부터 다양한 피드백을 받고 있으며, 그 솔루션의 성장을 위해 지속적인 고민을 하고 있다면, 당신은 이미 (초) 고급 개발자입니다. 


4. 보통 개발자는 밥 걱정을 하지만, 뛰어난 개발자는 세상 걱정을 한다.


뛰어난 개발자들이 세상 걱정을 하다 못해 만들어낸 다양한 오픈 소스들이 세상을 어떻게 바꾸어 놓았는지는 이미 잘 알고 계실 것이므로 패스. 


5. 보통 개발자는 버그가 나타나면 괴로워하지만, 뛰어난 개발자는 재미있어 한다.


그리고 이런 경지에 오른 개발자들은 보통 디버거를 사용하기 보다 '증상을 관찰하고 그 원인을 추정하는' 머리속 과정을 더 즐기는 경우가 많습니다. 그래서 코드와 디버깅 아웃풋을 몇 분 정도 바라보다 '거긴가부다'하며 버그를 잡는 일이 많죠. 이런 일은 (1) 자기가 만드는 시스템에 대한 깊은 이해와 (2) 많은 경험이 없이는 불가능하죠. 그러니, 같이 일하다가 이런 개발자를 만났다면 좋은 친구로 삼도록 하세요. 데드라인으로 가는 일이 외롭지 않을 겁니다. 



Posted by 이병준

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

  1. 비밀댓글입니다

    2018.01.18 06:38 [ ADDR : EDIT/ DEL : REPLY ]

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.20 10:37

주변에 개발자들이 많은 것은 아닙니다만, 의외로 교류할 기회는 많습니다. 그분들과 이런 저런 이야기를 나누다 보면, 노련한 개발자들에게는 공통적인 특성이 있음을 발견하게 됩니다. 나이가 많던 적던, 그런 분들 앞에서는 항상 고개를 숙이고 배우게 되지요. 


http://www.infragistics.com/community/blogs/marketing/archive/2013/03/27/how-to-find-a-top-paying-developer-job.aspx


1. 남들이 뭐라 하던 별로 신경쓰지 않는다. 


이런 분들은 남들이 자기에 대해서 뭐라고 하던 별로 신경쓰지 않습니다. '어차피 인정해 줄 사람들은 다 인정해 준다...'는 태도랄까요. '그런 것 까지 다 신경쓰면 일 못한다'일 때도 많습니다. 그러나 독불장군식의 안하무인적인 자세라기 보다는, '어차피 보는 눈은 다 다르다'에 가깝습니다. 


2. 모르는 것은 모른다고 말한다. 


이런 분들은 '모르는 것도 안다고 우겨 잘난체 하려는' 의식이 별로 없습니다. 모르는 걸 모른다고 말해야 더 많은 것을 배울 수 있기도 하거니와, 모르는 걸 안다고 우겨봐야 얻을 수 있는 장기적인 이득이 별로 없기 때문입니다. (아는 척 하기 시작하면, 대체로 프로젝트 진행에 있어서의 불확실성은 더 커집니다.) 


3. 의외로 통솔력이 좋다.


개발 능력이 어느 단계에 오르면, '이 일은 내가 더 잘 할 수 있어'같은 생각에 사로잡히기 쉽습니다. 그러나 노련한 개발자일 수록 그런 생각은 잘 하지 않습니다. 장기적으로 보면 일과 권한을 나눠야 팀 전체적 역량이 상승하기 때문입니다. (초 고급 개발자가 아니라면, 프로젝트의 성패를 자기 어깨에 전부 얹어놓는 모험 따위는 하지 않는 것이 바람직합니다.) 그래서 노련한 개발자는 적절히 일을 나누고, 진행상황을 점검하고, 진도에 따라 팀원 각자에게 적당한 동기를 부여하는 데도 능숙합니다. 


4. 해결 방법을 (많이) 알고 있다. 


프로젝트를 진행하기 위해서는 때로 '프로젝트 외적인 준비'가 필요할 때가 많습니다. 개발 서버 준비, 형상 관리 준비, 이슈 관리 준비 등등이 바로 그것이죠. 노련한 개발자는 그런 준비를 어떻게 해야 하는지, 그리고 어떻게 준비를 해야 생산성이 향상될 수 있는지 이미 알고 있는 경우가 많습니다. 백업은 어떻게 하는 것이 효율적인지, 이슈 관리 소프트웨어로는 어떤 것이 쓸만한지, 물어보면 바로 대답이 나오는 사람들이 바로 이런 부류의 개발자들이죠. 이런 개발자들과 함께 일하면 프로젝트 준비 과정이 한결 쉬워집니다. 


http://www.insightbook.co.kr/post/5633


5. 쉽게 몰입한다. 


잡일을 하다가도 쉽게 원래 일로 돌아와 집중하는 자세는, 노련한 개발자의 가장 큰 장점 중 하나입니다. 하지만 이런 개발자 조차도 서로 관련성이 없는 두 가지 프로젝트를 동시에 진행할 경우에는 집중력이 크게 떨어지므로 주의해야 합니다. 


6. 남 탓을 하지 않는다. 


노련한 개발자에게 '프로젝트가 실패한 이유는 무엇인가요?' 같은 질문을 던지면, 많은 이야기를 하지 않습니다. 노련한 개발자는 방어적인 자세를 보이기 보다, 프로젝트를 실패로 이끈 이유들을 단순히 나열하는 수준에서 이야기를 마무리 짓습니다. 그리고 대체로, 마지막에는 항상 이런 이야기를 합니다. '결국 제가 해야 할 역할을 제대로 못했기 때문에 실패한 것이 아닐까...' 겸손함은 노련한 개발자의 가장 큰 미덕 중 하나입니다. 


7. 화내는 대신 설득한다.


노련한 개발자는 화를 잘 내지 않습니다. (화내봐야 득될 것이 별로 없다는 것을 알기 때문이죠.) 그래서 화를 내기 보다는 설득적인 자세를 유지합니다. 설득하려는 시도가 논리적으로 반박당하면, 인정하고 주장을 철회하는 유연한 자세를 보이는 경우가 대부분입니다. 


8. 추정이 정확하다. 


노련한 개발자일 수록, 추정에 냉정합니다. 필요한 시간, 필요한 자원, 필요한 인력을 물을 때 지나치게 보수적이면 팀원들을 보호하기는 쉽겠지만 프로젝트의 목적을 달성하는 데는 오히려 해가 될 수도 있습니다. 지나치게 긍정적이지 않으면서도 지나치게 비관적이지 않는 추정치를 내 놓는 것은 어려운 일입니다. 그렇기 때문에, 노련한 개발자의 냉정하면서도 객관적이고 정확한 추정치는 의사결정에 항상 큰 도움이 됩니다. 


http://book.daum.net/detail/book.do?bookid=KOR9788991268463


이런 개발자를 만나면, 적절한 권한을 주시고 돈이 얼마가 되었던 '모시고' 있는 것이 좋습니다. 함께 일하는 동료 개발자의 행복지수를 상승시키는 데도 큰 도움이 되니까요. 



Posted by 이병준

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

  1. N레빗

    아.. 글읽다가 방심해서 ProGit 책 질렀네요...~_~a; 주말에 먹을 닭값이 날아감...orz

    2014.01.07 17:33 신고 [ ADDR : EDIT/ DEL : REPLY ]

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.16 17:16

저는 야근을 잘 하지 않습니다. 회사 입사한 이후로, 어지간히 급한 데드라인이 걸려 있지 않으면 야근을 하지 않습니다. 여섯시 반이면 자전거를 몰고 집으로 가서 쉽니다. 물론, 저도 처음부터 그랬던 것은 아닙니다. 많은 관리자들이 야근하지 않으면 열심히 하지 않는다고 생각합니다. (미국에도 그런 회사는 많습니다.) 야근을 회사에 대한 충성심의 척도로 생각하는 것이죠. 


그래서 가끔 사람들이 묻습니다. 왜 야근을 하지 않느냐고. 이런 질문을 받으면 여러가지로 대답이 곤궁한데, 대체로 이런 이야기를 들려주고는 합니다.





그러니까 세상에 없던 제품을 만들어 3개월 만에 시연까지 마쳐야 했던 201X년의 어느날, 저는 "3개월만에 만들 수 있겠느냐"라는 윗분의 물음에, "3개월 만에 만들어 보이겠습니다"라고 호기로운 선언을 합니다. 추정키로, 3개월이면 넉넉할 것 같아 보였던 것이죠. 


그러나 정작 업무에 돌입하자, 모든 것이 빡빡해졌습니다. 밑바닥부터 구현을 시작했던 시스템은 도무지 완성될 줄을 몰랐고, 겨우 얼개를 쌓아올린 시스템은 그다지 만족스런 성능을 보여주지 않고 있었죠. 세상에 없던 소캣 클래스를 구현해야 했고, 세상에 없던 파일 시스템도 만들어야 했습니다. 그리고 거기에 단말을 물려, 비디오가 성공적으로 전송되고 재생되는 것 까지 보여야 했죠. 


솔직히 말해서, 회사에 출근해서 자리에 앉는 아홉시부터 저녁 퇴근하는 여섯시 반까지, 밥을 먹거나 화장실을 가거나 간식을 먹거나 차를 마시는 약간의 시간을 제외하고, 제 눈은 항상 모니터를 보고 있었습니다. 저녁에 퇴근할 시간이 되면 눈에서 눈물이 줄줄 흐르는 일도 많았죠. 


그러나 이렇게 일할 수록, 저는 '가능하면 야근은 하지 않는다'는 원칙을 포기하지 않았습니다. 야근 한다 해도 여덟시를 넘기지 않았습니다. 저는 이런 식으로 개발을 진행했습니다.


(1) 진행중인 디버깅은 무조건 다섯시 반까지 마친다: 뒤집어 이야기하면, 다섯 시 반까지 끝낼 수 없는 디버깅은 시작하지 않았다는 뜻입니다. 디버깅이 마무리되지 않은 채로 퇴근하면 집에서도 내내 그 생각만 하게 되기 때문에, 무조건 다섯 시 반에 일을 마감하고, 여섯시 반 까지는 잡무를 처리했습니다. 


(2) 소스 코드 관리 시스템을 적극적으로 활용해, 언제든지 이전 상태의 소스코드로 되돌릴 수 있는 준비를 한다: 그 덕에, 수정하고 테스트하는 과정에서 시스템에 돌이킬 수 없는 상태에 빠졌을 때 언제나 이전 코드로 되돌아갈 수 있었습니다. 그래서 시스템이 이상동작해도, 언제든지 손을 놓고 퇴근할 수 있었습니다. 다음날, 최종 commit 지점으로 돌아가면 충분했기 때문이죠. (이런 류의 작업에는 Git이 갑입니다.)


(3) 도무지 해결책이 보이지 않을 때는 알 만한 사람들을 귀찮게 한다: 그래서 꽤 많은 사람들을 만나고, 그들의 이야기를 들었습니다. 그들의 조언은, 거의 항상 저에게 새로운 돌파구를 보여주었습니다. 일단 돌파구라고 생각되는 지점을 만나면 미련없이 진격했고, 그 결과는 거의 항상 성공적이었습니다. 


(4) 일 이외에는 아무것도 보지 않고 말하지 않는다: 그리고 그 3개월 동안, 저는 업무 이외의 분야에는 인터넷을 사용하지 않았습니다. (일이 없었다면 불가능했을 겁니다.) 대화 내용은 항상 일과 관계된 것이었고, 일 이외의 것에 대해서는 별로 이야기를 하지 않았습니다. 


그랬던 탓인지, 최종 시연이 오는 그날까지 아무도 저의 칼퇴근을 문제삼지 않았습니다. 중요한 것은 회사에서 보내는 시간의 질이지 양이 아니라는 사실을 점차로, 저와 함께 일하는 직속 상관도, 동료도 모두 이해해 주었습니다. 그리고 그 모든 시간이 결국 저의 평판을 만들었습니다. 


저는 이렇게 생각합니다. 누군가 야근을 강요한다면, 그것은 그 사람이 당신이 어떻게 일하는지 보지 못하기 때문입니다. 당신의 직속 상관 마저도 당신에게 야근을 강요한다면, 그것은 당신의 직속 상관마저도 당신이 어떻게 일하는 지 알지 못한다는 뜻입니다. 자주 보고하세요. 중요한 일은 가장 먼저 직속 상관과 상의하세요. 귀찮더라도 그것이 답입니다. 당신이 어떻게 일하는지 알게 만든다는 것. 그것이 가장 중요합니다. 일을 대하는 당신의 태도에서 자연스럽게 느끼게 하던, 이메일을 통해 느끼게 하던, 당신은 당신이 무슨 일을 하고 있으며 그 일을 얼마나 소중하게 생각하고 있는지 끊임없이 알릴 의무와 책임이 있습니다. 


물론 말하거나 보여주지 않아도 그 모든 걸 알아차려 줄 눈썰미 좋은 직속 상관 밑에서 일한다면 문제는 또 다르겠습니다만, 어디 세상이 그렇게 만만한가요.


Posted by 이병준
TAG 야근

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

  1. 키레네

    (4)번이 가능해야 나머지 것들도 가능하겠네요. ^^;
    대부분의 사람들은 (4)번 지키기를 너무 힘들어 하니 ..
    (4)번을 지키셨다는 것 자체로도 대단하고 아무나(?) 따라할 수 있는 일은 아니겠네요. :)

    2013.12.16 19:06 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 업무시간중으로 한정하고 식사시간을 빼면 어느정도는 가능하지않을까합니다.^^

      2013.12.16 19:56 신고 [ ADDR : EDIT/ DEL ]
  2. 검은무당벌레

    최근 야근이 뿌쩍 믾아진 시회 초년생입니다. 아직 배워야할 것도 많고 일을 함에 있어서 혼자 하는 것보단 협업 위주의 업무가 많아 시간이 오래 걸리는 경우가 잦습니다. 위에 쓰신 글 이외에 일을 좀 더 효율적으로 할 수 있는 노하우가 더 있는지 궁금합니다

    2013.12.17 00:19 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 말씀하신대로 숙련도가 낮은 사회 초년생일 때에는, 업무를 효율적으로 할 수 있는 방법을 잘 모르기 때문에 시간이 많이 걸립니다. 아마 한두 해 정도 시간이 지나면 자연스럽게 좋아질 것인데요. 일을 좀 더 효율적으로 하고 싶으시다고 하셨죠? 어떤 종류의 일인지 알려주시면 좀 구체적으로 답할 수 있을 것 같습니다.

      2013.12.17 08:51 신고 [ ADDR : EDIT/ DEL ]
  3. 노야그니즘은 저희팀 모토여서 저희팀도 위와같은 방법으로 사람과 시간을 최대한 활용하여 노야그니즘으로 3년간 버텨왔는데 이 시간이 누적되다보니 1년전에 팀장님이 "다른팀믄 야근이 잦은데, 일단 우리는 안하니 경영진이 올해는 얘기하네. 그렇게 어려운 프로젝트가 아니었던건지 정말로 능력이 좋아서인지." 하는 얘기를 들으셨나봅니다. 그리고 회사에 잔돈을 벌 수 있는 프로젝트를 하나 더 받으셨습니다. 그래도 야근을 안하려 다들 업무분담을 하여 일을 진행했죠. 근데 올해는 잔돈 프로젝트가 점점 늘어나더니 노야그니즘 3년이 지나니 이제는 고착화 됩니다. 이렇게 되다보니 저희 성과를 회사에서는 타팀에도 강요하기 시작했고 타팀은 저희팀을 엄청 싫어합니다. 연봉역시 몇년전이나 3년전이나 지금이나 % 유지가 아닌 강등입니다.
    요지는 이런 개인적 노하우와 노력으로 진행해와도 경영자들 입장에서는 당연한 것으로 인식되고 더욱 플러스 알파를 요구하지 고생흔적을 잘 알아주진 않는다는 생각입니다. 회사 전사적 활동이 아닌 이상에는 타팀과도 교류의 문이 닫히는 상황이고 순수개발자 회사분위기에서 정치라는 것이 시작된 느낌입니다.

    2013.12.17 10:02 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 전사적인 문제를 언급하시니 가슴이 답답해지는군요. ^^; 말씀하신 문제에 충분히 공감합니다. 이런 문제를 해결하려면 전사적인 차원에서 성과와 개발 방법론이 충분히 공유되어야 할 것 같은데요. 제조업 부문에서 이야기하는 생산 프로세스 개선과 비슷한 레벨에서 이야기가 되어야 하지 않을까 생각이 됩니다. 어차피 소프트웨어도 '생산'하는 것이니까요. 그런 부분에 대한 공유가 전체적으로 이루어지지 않으면, 개인이나 팀 차원에서 하는 노력이 빛을 잃을 수 있겠습니다. 그런 의미에서 보자면, 전사적으로 영향력을 행사할 수 있는 '목소리가 큰' 사람이 한 분은 있어야 하지 않을까 생각되는데요. 윗 선과의 소통이 부족한 상황으로 보이니 말이죠. 물론 제가 닻별님 회사의 상황을 잘 모르니 이렇게 말씀드리는 것 조차도 '뭘 잘 모르는 소리'로 들릴 가능성은 농후하겠습니다. 자주 뵙겠습니다. 감사합니다.

      2013.12.17 10:23 신고 [ ADDR : EDIT/ DEL ]
  4. 좋은글 잘 읽었습니다. 서로를 이해한다면 당연한 결과인것 같아요! 하지만 현실은 서로를 못믿어서 ㅋㅋ

    2013.12.17 19:14 신고 [ ADDR : EDIT/ DEL : REPLY ]
  5. 중요한 것은 회사에 보내는 시간의 질이지 양이 아니라는 말씀에 동감합니다.
    좋은 글로 많은 점을 느꼈습니다. 5시 반까지 끝낼 수 없는 디버깅은 시작도 않는 다고 하셨는데
    저도 그렇게 하고 싶지만, 가능할지 모르겠어요. 순차적으로 작업하는 방식을 바꾸어야 봐야겠네요.

    2013.12.18 10:18 신고 [ ADDR : EDIT/ DEL : REPLY ]
  6. Deflame

    이 분.. 제대로 애자일하시네요 ㅇㅇㅋㅋ

    2013.12.18 15:34 신고 [ ADDR : EDIT/ DEL : REPLY ]
  7. 사실상 근무시간에 땡땡이 안치고, 웹서핑 1분도 안하고, 업무에만 집중해서 일을 했다면...
    저녁 6시가 되면 녹초가 됩니다.
    더 일을 하고 싶어도 할 수 없다는...

    2014.02.06 18:14 신고 [ ADDR : EDIT/ DEL : REPLY ]