공장장과 함께하는 디지털 포렌식 이야기

 

얼마전 송부한 EnCase Certification Exam Phase II 결과가 나왔다.

합격!

드디어 EnCE, EnCase Certrified Examiner 라는 이름으로 활동할 수 있게 되었다.

60일이라는 Practical Test가 버겁긴 했지만 뿌듯하다.

이제부터 시작이다.

이전다음

01234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495

촌철살인!

이전다음

01

앞으로 60일!

Way to go, go for EnCE!

공부를 제대로 하진 못했지만 어쨌든 1차 관문 통과.

International Version이라 EnCase Legal Journal 의 압박이 없어서 다행이었던 듯.

Prometric 을 통해서 시험을 보았는데 생소한 시험이라서 그런지 학원 관계자(IT-Bank)가 응시방법을 묻기도 했다.

Way to go!

lol

http://www.zdnet.co.kr/news/enterprise/etc/0,39031164,39164694,00.htm

현장에서 마주칠 수 있는 10가지 타입의 프로그래머

Justin James ( TechRepublic )   2008/01/02    
     

프로그래머들은 특별한 사람이라고 평가되는 것을 좋아한다. 사실은 어떤 모범적인 프로그래머들은 다른 프로그래머들의 이상한 점을 개발자들의 커뮤니티 내에서도 발견한다. 아래에 10가지 타입의 프로그래머를 소개한다. 여러분은 이 중에 어떤 타입인가?

#1: 간달프(Gandalf)

이 프로그래머 타입은 ‘반지의 제왕’에 나오는 마법사 간달프와 닮았다. 이 타입의 외관은 턱수염을 기르고, 이상한 모자를 쓰고, 겨울에 망토 같은 외투를 입을지도 모르며, 좋게 보면 간달프와 같은 마법으로 팀을 위하고, 안 좋은 면은 팀원들이 간달프가 눈길을 걸어올라 오는 시간을 기다리듯이 그가 전산실에 오는 시간을 오랫동안 기다려야 한다는 것이다.

이런 타입은 실력이 아주 뛰어난 중요한 인물이지만 보통은 같이 일하기를 꺼려한다. 하지만 문제가 해결이 안 될 때는 간달프의 마법이 필요하듯 이런 타입의 도움도 필요한 법이다.

#2: 순교자

다른 업종에서는 순교자(The Martyr)는 워커홀릭이다. 하지만 개발 분야에서 순교자는 그 차원을 넘어 선다. 워커홀릭은 최소한 집에 가서 샤워하고 잠은 자기 때문이다. 순교자 타입은 다 먹은 피자 박스에 둘러싸인 책상에 엎드려 자는 것을 자랑스럽게 생각한다.

문제는 아무도 이렇게 일하는 것을 원하지 않았다는 것이다. 순교자 타입은 다른 팀원에게 부담스러운 말을 한다. “먼저들 들어가. 저녁 맛있게 먹고…. 나는 오늘밤에 3주 동안 해야 할 코딩을 모두 하고 들어갈래.”라는 식으로 말이다.

#3: 팬보이

팬보이(Fanboy)는 조심해야 한다. 이런 사람이 여러분 주의에 있다면, 그는 드래곤볼 Z와 건담 윙 중 어느 것이 재미있는지 또는 플레이스테이션3와 X박스 360중 어느 것이 더 좋은지에 관해 과장 좀 해서 3시간 동안은 이야기를 들어야 할 것이다.

팬보이의 책상 주변에는 일본에서 수입한 액션 피규어, 포스터 또는 장식품 등을 진열해 놓았을 것이다. 이들은 자신들이 가지고 있는 장식품을 가지고 생각하는 것을 좋아해서, 그 생각에 시간을 많이 허비한다. 이런 타입은 가끔 무엇 때문에 채용을 했는지 모를 때가 가끔 있다.

#4: 빈스 닐(Vince Neil): 미국 밴드 머틀리 크루의 리드싱어

마치 1984년으로 돌아간 것 같은 타입이다. 긴 머리카락, 찢어진 청바지에 큰 스카프를 목에 두르고 업무 시간 동안 본 조비, 데프 레퍼드(Def Leppard)와 같은 음악을 따라 흥얼거리며 일한다. 빈스 타입은 일반적으로 재미있고 경험도 많지만 발전이 없다. 게다가 힙합 스타일과 아웅다웅할지도 모른다. 이런 타입과 매일 일하는 것은 꽤 힘들 것이다.

#5: 닌자

닌자 타입은 여러분 팀의 MVP이지만, 아무도 누구인지 모른다는 것이다. 전설적인 자객처럼, 닌자 타입은 일을 하는 건지 안 하는 건지 모르지만 아침이 되면 결과물이 나와 있는 것을 발견할 수 있다.

여러분이 소스 제어 시스템을 가동하고, 새벽 4시에 한번 확인 해보라. 여러분은 닌자가 그 프로젝트를 알고 있을 것이라고 생각하지도 않았지만, 여러분이 일주일 동안 작업한 계획의 문제를 코드 레벨에서 확인하고 알려 두었을 것이다. 여러분이 다른 회의에 참석해 있을 때, 닌자 타입은 일을 하고 있을 테니 확인해 보라.

닌자 타입은 아주 비밀스럽게 일을 한다. 여러분은 그 사람의 이름조차 모르지만 모든 프로젝트마다 아주 깔끔하게 정리되어 있는 것을 볼 수 있다. 이런 타입은 신중하게 다가가야 한다. 이런 사람을 조직 내에서 순위를 매기거나 파일로 업무를 관리하려고 하지 마라. 닌자 타입은 혼자 일하는 전사이며, 관리 당하는 것을 싫어한다.

#6: 이론가(The Theoretician)

이 타입은 프로그래밍에 관해 알아야 하는 모든 것을 알고 있다. 이 타입은 애매한 프로그램 언어의 역사에 관해 4시간 정도 떠드는데 시간을 소비하거나 어떻게 프로그래밍 하면 런타임을 줄이고, 최적화 프로그래밍을 할 수 있는지에 대해 시간을 허비할 수 있다.

문제는 이런 타입은 소프트웨어 개발에 관한 것을 알지 못하고 있다는 것이다. 이론가 타입이 코딩을 하면 정말 말도 안 되게 ‘엘레강스’하다. 또 좋아하는 기술은 ‘반복’이며, 모든 코드는 최대한 꼬여 있어 읽는 데 시간이 많이 걸린다.

이런 타입은 주의가 산만해 쉽게 다른 일에 관심을 돌린다. 몇 시간이면 개발할 수 있는 일을 이런 타입은 석 달은 족히 걸린다. 왜냐하면 기존의 툴은 충분하지 않다며 새로운 라이브러리를 만들어 새로운 툴을 만들어 사용하려고 하기 때문이다.

이런 타입은 잘만 컨트롤 하면 아주 잘 활용할 수 있다. 프로젝트에서 정확히 할 일에 대한 범위를 정해 주고 다른 일에 시간을 허비하지 못하게 한다면 말이다.

#7: 코드 카우보이(The Code Cowboy)

이 타입은 절대 스스로 멈추는 법이 없다. 이런 타입은 거의 항상 최고의 프로그래머이며, 다른 사람보다 두세배는 빠르게 일을 할 수 있다. 하지만 문제는 그렇게 빠르게 하는 일의 반을 대충 한다는 것이다. 소스 컨트롤 하는 코드 확인에 시간이 걸리고, 외부 컨피규레이션 데이터 저장에 시간이 걸리고, 다른 사람과 대화중에 생각을 이해하는 데도 시간이 걸린다.

이 타입의 코드는 스파게티처럼 혼란스럽다. 이유는 프로그래밍 하면서 리팩토링 하는 것이 절대 일어나지 않게 빨리 하기 때문이다. 프로그래밍 책에 예제로 되어 있는 “이렇게 하지 마세요”라고 7페이지에 걸쳐 중요하게 설명되어 있는 것과 비슷하게 프로그래밍을 했지만 신기하게도 프로그램은 돌아간다.

코드 카우보이 타입은 다른 사람과 함께 일을 잘 하지는 못한다. 그리고 여러분이 이런 타입 두 명을 같은 프로젝트에 투입시키면, 서로의 변화에 대해 인정을 하지 않고 싸우기 때문에 확실히 실패 한다.

이 타입은 정확하게 해야 하는 프로젝트보다 납기 일정이 더욱 중요한 프로젝트에 투입하는 것이 좋고, 코드는 항상 일정 전에 완성되어 있을 것이다. 코드 카우보이는 ‘시끄러운 닌자 버전’이라고 보면 된다. 닌자가 정교한 외래 수술을 하는 것에 비유한다면, 코드 카우보이는 성난 소처럼 저돌적으로 자신의 길을 달려가는 것에 비유할 수 있다.

#8: 공수부대요원(The Paratrooper)

여러분은 영화에서 적지 깊숙이 침투하여 비밀스럽게 업무를 수행하는 특공대 요원을 본적이 있을 것이다. 이 타입은 소프트웨어 개발 세계에서 ‘공수부대 요원’이라고 한다. 이 요원은 다 죽어 가는 프로젝트를 살리기 위해 마지막으로 보내는 프로그래머이다.

이 요원은 장기 프로젝트에 대해서는 부족하지만, 그들의 최대 자산은 친숙하지 않는 코드를 배워서 작업을 하는 불가사의한 능력이다. 다른 프로그래머들은 이러한 것을 충분히 배워서 프로젝트를 실행하는 데 몇 주 내지 몇 달이 걸릴지도 모르지만, 공수 부대 요원들은 몇 시간 또는 하루 정도면 충분하다.

이 요원들은 그 코드의 핵심을 알 정도로 배우지는 못하지만, 전체의 팀이 실패할지도 모르는 곳에서 성공할 수 있는 것을 의미한다.

#9: 보통사람(Mediocre Man)

“충분히 좋다”라고 듣는 것이 이 ‘보통사람’ 타입에게서 들을 수 있는 최고의 찬사이다. 이 이름에 속지 말아라. ‘보통사람’이라는 타입에는 엄청난 다양함이 있다. 그리고 이들은 다른 팀원들보다 더 나쁜 코드를 만드는 데 시간이 더 걸린다.

이 타입들의 특징은 느리고 침착하게 하지만 프로젝트가 언제 끝날지 모르며, 회사에 오랫동안 일을 하기 위해 항상 “충분히 좋다”라는 슬로건을 외친다.

이런 타입을 인터뷰 할 때 그들은 많은 프로젝트에 관여한 사실을 여러분에게 이야기 하겠지만 실제로 관여한 프로젝트는 많지 않다. 이러한 타입을 알아내는 것은 쉬운데 그들이 한 일에 대한 자세한 물음을 하면 아마 갑자기 건망증 증세를 보일 것이다. 이런 타입을 채용한다면 퇴사시키는 데 몇 년은 걸릴 것이다.

#10: 이반젤리스트(The Evangelist)

여러분이 어떤 환경에 처해 있더라도, 이반젤리스트는 지금 사용하고 있는 툴, 프로세스를 버리고 다른 것들로 대체해 업무 향상을 할 수 있다고 주장한다. 이반젤리스트는 실제로 이론가(The Theoretician)와 정반대이다. 이들은 솔직하고, 소프트웨어 개발에 관하여 많이 알지만 실질적으로 프로그래밍 작업은 거의 하지 않는다.

이들은 자신이 프로젝트 매니저나 부서장이라고 마음속으로 생각하고 있으나 지식이나 프로젝트 경험은 부족하다. 따라서 이들은 순수하게 경영자 역할을 할 수 있으므로 다른 사람들은 이들이 변혁을 시도하는 것을 참을 필요가 있다. @

원리 파악과 경험 축적으로「프로그래밍 길들이기」

중학교 시절 첫 프로그램인 격투기 게임을 완성하기 위해 수업 시간 뒤편에 앉아 베이직 코드를 적어 나갔다. 주말이면 이 코드를 컴퓨터에 옮기는 작업을 했고, 이런 일을 거의 몇 주 동안 반복했다. 드디어 게임 프로그램 완성의 시간이 다가왔고, 조심스럽게 RUN을 쳤다. 결과는 참담했고 그날 필자는 하늘에서 떨어지는 눈을 맞으며 펑펑 울었다. 사춘기 소년의 눈물이 아니었다. 이유가 무엇이었을까?

유경상 (마이크로소프트웨어) 2002/02/20


다음은 1부터 1000까지의 합을 구하는 C 코드이다. 하지만 제대로 작동하지 않는다. 왜 그럴까?

int i, sum;
sum = 0;
for(i=1; i <= 1000; i++);
sum += i;
printf("sum = %d", sum);

단번에 알아낸 독자들도 있겠지만 앞의 코드 오류는 for 문 맨 뒤의 세미콜론 때문이다. 이 세미콜론 때문에 sum 값은 1001이 된다. 필자는 몇 년 전 이와 비슷한 코드를 작성하면서 4시간 정도를 허비한 경험이 있다. 코드가 앞의 코드보다는 훨씬 더 복잡했지만 잘못된 세미콜론 하나 때문에 제대로 된 수치 해석 결과가 나오지 않았다. 덕분에 여기 저기 코드를 마구 수정했고 원인을 발견하고 수정한 코드를 다시 복구하는 데 모두 4시간이나 소요해야 했다.

프로그래머라면 누구나 코드를 작성하면서 겪는 황당한 경험들이 많이 있을 것이다. 사소한 실수부터 개발환경, 개발도구 등의 버그 등등…. 이러한 황당한 경험들을 겪었을 때 각자의 반응들은 다양할 것이다. 부정적인 반응 중에서 좀 심한 경우 "이 짓거리 더 이상 못하겠다"며 나동그라지는 사람이 있는가 하면, 긍정적인 반응으로 "앞으로 이런 실수는 하지 말아야지"하며 씨익 웃는 사람도 있을 것이다.

필자 역시 십 수년 동안 프로그램을 작성하면서 많은 경험을 했다. 필자가 직접 겪은 경험들도 있으며 후배나 선배를 통해 간접적으로 겪은 경험도 있다. 필자가 직간접적으로 겪은 이런 일들 중 몇 가지를 여기서 독자들에게 소개하고, 몇 가지 사건들로부터 필자가 얻은 교훈을 공유해 보고자 한다.

점진적 프로그래밍
중학교 2학년 때였다. 80년대 중반 필자가 처음 접했던 컴퓨터는 Z80이라는 8비트 CPU를 탑재한 퍼스널 컴퓨터였다. 64KB(64MB가 아니다)의 메모리에 BASIC을 기본 탑재한 이 컴퓨터는 그 당시 고가의 제품이었다. 필자의 기억으로 TV와 냉장고보다 훨씬 비쌌던 것 같다. 그다지 넉넉하지 않은 집안 사정상 필자는 이 컴퓨터를 사달라고 말할 엄두도 못 냈다.

필자는 모 회사의 컴퓨터 전시장에서 매주 토·일요일은 살다시피 하면서 프로그램을 작성했다. 처음 도전한 프로그램다운 프로그램은 격투기 게임. 매일 수업시간 뒤편에 앉아 노트에다 베이직 코드를 적었다. 컴퓨터가 없었기 때문에 평소에 코드를 정확히 기록해 놓고 주말이 되면 이 코드를 그대로 컴퓨터에 옮기는 작업만을 몇 주 동안 반복했다. 그리고 수천 라인의 게임이 완성되고 처음으로 실행시켜볼 때가 왔다.

RUN(베이직의 수행 커맨드)을 조심스럽게 타이핑하고 리턴 키(지금의 엔터 키)를 눌렀다. 결과는 참담했다. 코드는 전혀 제대로 작동하지 않았고 게임 화면은 엉망으로 나왔으며 캐릭터는 전혀 움직이지도 않았다. 그날 집에 돌아가던 필자는 내리는 눈이 왜 그리 서러웠던지 펑펑 울었던 기억이 난다.

갑자기 웬 자서전? 필자가 여기서 말하고 싶은 이야기는 점진적으로 코드를 작성하라는 조언을 하고 싶어서다. 필자가 겪은 실수의 원인은 점진적으로 코드를 작성하지 않고 수백 수천 라인의 코드를 단번에 작성하려고 했기 때문이다. 인간은 결코 완벽할 수 없는 존재다. 단 수십 라인의 코드를 작성하더라도 실수를 할 수 있다. 더 많은 코드를 작성해야 한다면 실수의 가능성이나 실수 횟수는 더 늘어날 것이다.

이러한 오류를 줄이기 위해서는 프로그램을 작은 기능 단위로 나누고 이것들을 하나하나 작성하고 테스트하는 작업을 반복하면서 전체 프로그램을 완성하는 것이 중요하다. 필자는 거의 하나의 함수를 작성할 때마다 그 함수가 제대로 작동하는가를 테스트한다. 그 함수가 예상대로 작동하는 경우에 다음 함수 작성에 들어간다. 물론 항상 이런 경우만 있는 것은 아니지만 대부분의 코딩 작업을 이러한 방식으로 수행한다.

시간이 더 많이 소요될 것 같지만 실제로 전혀 그렇지 않다. 더 많은 코드를 작성하고 테스트하는 것보다 더 적은 시간이 소요된다. 왜냐면 더 많은 코드는 보다 정확히 테스트하기 위해 더 많은 경우의 수를 테스트해야 하기 때문이다. 또한 코드에 문제가 발생했을 때 어느 부분에서 문제가 발생했는가를 알아내기 위해서도 더 많은 시간이 필요하다.

반면 적은 양의 코드, 즉 함수 단위를 테스트하는 데는 훨씬 더 적은 경우의 수만을 테스트해도 되며 문제가 발생한 곳을 정확히 알아낼 수 있다. 그리고 단위 함수가 제대로 작동하기 때문에 이들 함수들이 연동돼 작동하는 작업 역시 테스트하고 문제를 파악해 내기가 쉽다.

하나의 변수가 프로젝트의 실패로 연결된다
필자의 후배가 아르바이트를 할 때였다. 그 후배가 맡은 일은 국회의원 선거 결과를 통계적으로 추측해 당선 여부를 유추해 내는 프로그램을 작성하는 것이었다. 그리고 그 결과는 모 방송사를 통해 생방송으로 방송될 예정이었다.

선거 날이 다가왔고 예비 조사가 수행되고 그 조사 결과가 프로그램의 입력으로 주어졌다. 프로그램은 당선 가능성이 있는 후보들을 지목했고 이 내용이 일부 방송됐다. 하지만 개표가 진행됨에 따라 프로그램이 예측한 것은 전혀 엉뚱한 것이었음이 밝혀졌다. 프로그램의 수행 결과가 테스트할 때와는 달리 이상하게 나온 것이다.

그 방송사는 추측 보도를 포기하고야 말았다. 프로젝트는 완전 실패로 돌아간 것이다. 그 후배가 저지른 실수는 5개의 중첩된 for 문장에서 반복 변수 하나를 잘 못 썼기 때문이었다. 이 실수는 그 코드를 수행하는 함수가 별도로 테스트되지 않았기 때문에 발견되지 않았다. 단 하나의 변수가 프로젝트의 실패라는 참담한 결과를 낳은 것이다.

바보가 아닌 다음에야 누구나 점진적인 방식으로 코딩할 것 같지만 실제는 전혀 그렇지 않다. 많은 개발자들이 수 백 라인의 코드와 십 수개의 함수를 작성하면서 단 한번의 테스트 수행을 해보지 않고 개발하는 경우가 많다. 이렇게 하면 한 번에 제대로 작동할 수도 있지만 그렇지 않을 확률이 훨씬 더 높다. 그리고 코드가 원하는 대로 작동하지 않을 때 문제를 찾아 해결하는데 오랜 시간이 소요될 것이다.

오류 메시지의 중요성
필자는 가끔씩 프로그래밍 관련 사이트에 들어가 질문에 답변을 하거나 필자에게 직접 전달되는 질문에 대한 답변을 하곤 한다. 이 때 필자를 황당하게 하는 질문들은 '막연히 이렇게 저렇게 했더니 오류가 나더라 어떻게 하면 되느냐'는 것이다. 어떤 오류인지는 말하지도 않고 막연히 안 된다는 것이다. 이럴 때는 정말 답변해 주기 난감하다. 원인을 알아야 그 문제를 해결할 텐데 이 경우는 아예 원인에 접근하기 위한 단서를 주지 않는 경우이기 때문이다.

오류 메시지는 문제를 해결하기 위한 중요한 단서다. 하지만 초보 개발자나 많은 개발자들이 이 오류 메시지의 중요성을 간과하는 것 같다. 프로그램을 개발하다 보면 예상하지 못한 오류 메시지가 자주 등장할 것이다. 그리고 이 오류를 해결할 수 있는 첫 번째 단서는 이 오류 메시지다. 메시지를 잘 읽어보면 왜 오류가 발생했는가를 알 수 있다. 때에 따라 친절하게도 오류가 발생한 위치도 알려준다. 비록 이 위치가 정확하지 않을 때도 많지만 말이다. 한 가지 예를 들어보자. 다음 비주얼 베이직 스크립트 코드를 살펴보자. 얼핏 봐서는 별다른 문제가 없는 듯한 코드다.

strConn = "Provider=SQLOLEDB;Data Source=(local);User ID=Tester;Password=Test"
strSQL = "SELECT * FROM Employees"
Set adoRS = WScript.CreateObject("ADODB.RecordSet")
adoRS.Open strSQL, strConn, adOpenStatic, adLockReadOnly

이 코드를 윈도우 스크립팅 호스트나 ASP에서 수행해보자. 분명히 오류 메시지가 나타날 것이다. 오류 메시지는 "잘못된 형식이거나 올바른 범위 밖에 있거나 서로 충돌하는 인수입니다"로 나타나며, 오류가 발생한 위치는 네 번째 라인인 adoRS.Open에서 발생한 것으로 표시될 것이다. 메시지는 인수(parameter)에 문제가 있음을 알려주고 있다. strSQL이나 strConn의 문제는 아닌 듯하다.

그렇다면 adOpenStatic과 adLockReadOnly 둘 중 하나가 혹은 모두가 문제일 가능성이 높다. 하지만 우리가 사용한 매개변수는 ADO에서 정의하는 정확한 상수임에 틀림없다. 정확한 상수이지만 이 상수는 어디에도 정의되지 않았다. 따라서 이 상수 값은 0이 되며 이것을 ADO가 거부하는 것이다. 이 코드를 제대로 작동시키기 위해서는 adOpenStatic과 adLockReadOnly의 상수 값을 미리 정의하든가 이 상수 대신 숫자 값을 사용해야 한다.

비록 단순한 예이지만 이 예를 통해 오류 메시지가 주는 힌트를 조금만 생각해 보면 오류 메시지의 원인을 찾아 낼 수 있다는 것을 알았을 것이다. 대부분의 오류 상황은 이 보다 훨씬 복잡한 상황일 것임에 틀림없다. 하지만 이 오류를 해결하는 최초의 단서는 오류 메시지임을 누구도 부정하지는 않을 것이다.

소스 코드는 가장 훌륭한 메모장
프로그램을 작성해본 사람이라면 누구나 소스 코드에 주석(comment)을 다는 것이 좋은 습관이라는 것을 알고 있다. 필자가 아는 K 프로그래머는 프로젝트 진행 중에 한 모듈의 코드를 보고 "누가 이렇게 작성했냐"며 길길이 날뛴 적이 있다고 한다. 그 코드는 너무 복잡했기 때문에 유지 보수가 어렵다는 것이었다.

하지만 팀원 누구도 그 코드를 작성하지 않았다. 자세히 코드를 살펴본 결과 그 코드의 작성자는 다름 아닌 K 씨 자신이었다. 그리고 그는 그렇게 복잡하게 코딩하지 않으면 안 되었던 이유를 겨우 생각해 냈다. 왜 그런 식으로 코딩했는지 몇 줄의 주석만 달아 놨더라도 아마 이런 해프닝은 발생하지 않았을 것이다.

주석만 달았어도 이 고생은 안했을텐데…
자기가 작성한 코드라도 몇 개월이 지나면 기억하기 어렵다. 특히 대형 프로젝트일수록 이러한 상황이 심하다. 필자가 리눅스 커널의 TCP/IP 시스템 코드를 수정할 때였다. 그때 커널 버전은 1.0.8이었지만 여전히 거대한 분량의 커널 코드는 필자를 압도하고도 남았다. 논문은 고속의 데이터 전송을 위한 운영체제 레벨의 지원에 대한 것이었는데, 커널의 디바이스 드라이버를 수정해야 했다.

드라이버를 수정해 원하는 속도 향상을 얻었다. 그리고 두 달 후, 관련 논문을 작성하다가 드라이버 코드를 참고해야 할 상황이 왔다. 하지만 코드를 아무리 살펴봐도 정말 '무식한' 방법으로 코딩이 되어 있었다.

아무리 생각해봐도 왜 내가 그렇게 코딩했는지 생각이 나지 않았다. 그래서 좀더 효율적인 코드로 바꿔보았다. 수정한 코드는 제대로 작동하지 않았고 그때서야 왜 그렇게 무식한 방법을 사용했는지 이유가 떠올랐다. 이 경우도 비슷하게 몇 줄의 주석만 있었다면 이런 고생은 안 했을 것이다.

그 이후로 필자는 코드에 주석을 다는 습관을 들였다. 그리고 추가적으로 코드를 메모장처럼 사용하는 습관도 들였다. 대부분의 프로그래머는 많은 시간을 소스 코드와 함께 보낸다. 따라서 코딩과 관련된 사항을 종이나 다른 파일 등에 기록하는 것보다 소스 코드에 기록해 두는 것이 매우 효율적이다.

다음에 작업할 내용이나 다른 코드가 완성된 후에 수정해야 할 사항, 하드 코드(hard code)된 내용 등을 소스 코드 내에 주석으로 남겨두는 것이다. 그리고 차후 작업할 때 이 주석을 보면 앞으로 해야 할 내용, 수정해야 할 내용 등이 설명과 함께 남게 될 것이다. 다음은 필자가 소스 코드에 사용한 몇몇 주석을 예로 들어본 것이다.

// FIXME : 테스트 후 잘 작동하면 삭제할 것!
// FIXME : 다음 멤버 변수를 private로 바꿀 것!
// CONSIDER : 여기서 예외를 발생하는 것이 합당할까?
// HARD CODE : 보다 간단히 하기 위해 아스키 코드를 하드 코드함

이렇게 작성된 주석들을 탐색기의 검색 기능이나 대부분의 에디터가 제공하는 검색을 통해 키워드(FIXME, CONSIDER 등)를 찾으면 소스 코드에서 어떤 작업을 더 해야 하는가가 명백히 드러난다. 소스 코드는 다른 어떤 것 보다 훌륭한 개발 일지이자 메모장이다.

고수는 자료를 잘 찾는 사람
독자들이 프로그램을 작성하다보면 어려운 문제나 쉽게 해결되지 않는 오류에 부딪힐 때가 많을 것이다. 그럴 때 독자들 중에 많은 사람은 인터넷의 개발자 포럼에 자신이 부딪힌 문제를 질문할 때가 종종 있을 것이다.

대개 제목은 "고수님들 부탁 드립니다…로 시작되기 쉽고" 얼마 후에 고수가 문제에 대한 해결책 혹은 해결을 위한 실마리를 알려준다. 그렇다면 그 고수라 불리는 사람들은 다양한 분야의 여러 질문을 어떻게 척척 대답해 주는 것일까? 그들의 머리는 정말 좋아서 모든 상황을 기억하고 있는 것일까?

필자의 경험에 비추어 본다면 전혀 그렇지 않을 가능성이 높다. 10여 년 전이라면 모를까 요즘에는 너무도 많은 기술과 너무도 많은 개발환경, 프로그래밍 언어, 플랫폼이 쏟아져 나오고 있다. 이들에 대해 모두 잘 알고 있는 사람은 정말 드물다. 그렇다 할지라도 게시판에서 답변을 잘해주는 고수들을 보면 세세한 함수들의 매개변수까지 정말 잘 알고 있다는 생각이 드는 것은 사실이다.

필자는 요즘의 고수란 필요한 프로그래밍 자료, 기술 가이드, How-to 등의 자료를 잘 찾는 사람이라고 말하고 싶다. 수만 개의 함수와 클래스 등을 모두 외우고 다니는 사람은 없을 것이다. 하지만 간략한 키워드만으로 필요한 함수와 클래스를 찾을 수 있는 능력이 있다면 그는 고수 반열에 오를 충분한 자격이 있다.

누군가가 질문을 하거나 자신이 프로그램을 작성할 때 특정 함수 혹은 기능이 필요하다면 고수라 불리는 사나이는 "어디서 봤었지…"'라고 몇 마디 중얼거리며 인터넷이나 관련 책자를 뒤적거릴 것이다. 오랜 시간을 소요하지 않고도 그는 자신이 필요한 기능을 찾을 것이고 구체적인 사용법 등은 그 자료에 모두 실려있다. 이제 프로그램을 작성하는 데 별 어려움은 없을 것이다.

반면에 남들이 고수라고 부르지 않는 사람들은 무언가 하고 싶지만 그것을 어떻게 할지 모를 때면 먼저 가슴이 답답하고 눈알이 튀어나올 것 같은 막막함에 부딪힌다. 관련 자료를 찾아보고 싶지만 어디서 자료를 찾아야 할지도 잘 모른다. 겨우 자료가 인터넷이나 어떤 책에 나와 있다고 주워 들어 구하게 된다. 됐다 싶은 마음에 자료를 살펴보지만 자료의 양이 너무 방대하다. 요즘 컴퓨터 관련 책들이 좀 두꺼운가? 게다가 MSDN 라이브러리 같은 자료는 CD 3장 1.8GB에 달하는 방대한 분량이다. 숨이 막히기 딱 좋은 분량 아닌가?

고기도 먹어본 사람이 잘 굽는다
"그렇다면 고수들처럼 자료를 빨리 잘 찾으려면 어떻게 해야 합니까?" 먼저 많이 찾아봐야 한다. 고기도 먹어본 사람이 잘 굽는다고 했다. 자료를 많이 찾아 본 사람은 어디에 유사한 자료가 있는지 알고 있다. 게다가 이렇게 자료를 찾다보면 자신도 모르는 사이에 공력이 쌓인다. 공력이라 함은 예전에 찾아보지 않았더라도 '이런 자료는 여기에 있을 거야'라고 추측할 수 있는 능력을 말한다. 그리고 실제로 찾아보면 대개 80∼90%는 원하는 자료가 찍어 본 그곳에 떡(?)하니 있기 마련이다.

비록 원하는 자료를 찾지 못하더라도 그것을 찾기 위한 실마리 정도는 얻을 것이다. 필자가 주로 참조하는 자료는 뭐니뭐니 해도 MSDN 라이브러리다. 윈도우 플랫폼에서 개발하는 개발자라면 모두 이 MSDN 라이브러리를 끼고 살아야 한다. 개발에 가장 많이 참조하기 때문에 하드디스크 용량이 아무리 부족해도 MSDN 라이브러리 CD 3장을 거의 모두 설치한다.

그리고 필자가 겪는 문제의 많은 부분을 여기 MSDN 자료에서 해결하곤 한다. MSDN 라이브러리를 한번이라도 돌아본 사람은 알겠지만 여기서 원하는 자료를 찾기란 쉽지 않다. 인덱스가 잘 갖춰져 있지만 키워드 하나를 던지더라도 그 키워드에 포함되는 자료가 수십 수백 개가 나타나기도 한다. "이들 중에서 내가 필요한 것은?" MSDN 라이브러리를 많이 참고해 본 사람은 그 많은 내용 중 내가 원하는 것이 무엇인가를 어렵지 않게 골라낼 수 있다.

대충 이번 이야기의 결론은 이렇다. 고수라고 해서 모든 것을 알고 기억하는 것은 불가능하다. 그러나 그들은 필요한 자료를 빨리 찾는 방법을 알고 있다. 그 방법은 배울 수 있는 것이라기보다는 자료를 많이 찾아봄으로써 스스로 터득하는 것이다. 물론 누군가가 옆에서 계속 자료 찾는 것을 도와 줄 수 있지만 스스로 고생하면서 터득한 자료 찾는 방법이 훨씬 더 값지다는 것을 명심하자.

보다 많은 경험
이제까지 필자가 직간접적으로 경험한 에피소드 몇 개를 소개했다. 마지막으로 황당한 에피소드는 아니지만 필자가 초보 프로그래머와 보다 고급 프로그래밍을 하고자 하는 개발자에게 해줄 수 있는 몇 가지 조언을 해보기로 하겠다. 다분히 개인적이고 주관적인 내용이기 때문에 모든 독자들이 공감하리라고 생각하지는 않는다. 그래도 1985년부터 프로그램을 짜온(대개 프로그래머들은 프로그램을 '짠다'라고 표현한다) 한 프로그래머의 이야기니 들어봐 주기 바랄 뿐이다.

프로그래밍은 경험이다
먼저 권장하고 싶은 것은 보다 많은 경험을 해보라고 권하고 싶다. 필자의 주관 하에 프로그래밍은 경험이라고 말하고 싶다. 보다 많은 프로그래밍 경험을 갖고 있는 사람은 주어진 문제를 보다 빨리 해결할 수 있는 능력을 갖고 있다. 말을 좋게 해서 많은 경험이지 속된 말로 '닥치는 대로 프로그램을 짜보라'고 권하는 것이다. 아무리 프로그램이 작더라도 직접 작성해 본 것과 그렇지 않은 것은 매우 큰 차이가 난다. 작은 연습 프로그램을 많이 작성해 본 사람은 큰 프로그램도 잘 짜기 마련이다. 큰 프로그램도 결국은 작은 모듈들의 집합이기 때문이다.

경험을 늘리는 방법 중 하나는 다른 사람이 작성해 놓은 예제를 분석해 보는 것도 좋은 방법이다. 하지만 반드시 그리고 정말 중요한 것은 예제를 분석하는 것에 그치지 말고 스스로 비슷하거나 진보된 예제를 작성해 보라고 권하고 싶다.

필자가 2000년 말 닷넷과 C#을 처음 접한 이후로 지금까지 작성한 예제 코드들이 수백 가지이며 7만여 라인이 넘는다면 믿겠는가? '믿거나 말거나'지만 필자는 이렇게 많은 코드들을 작성해 보면서 닷넷 플랫폼과 C#이라는 언어를 이해할 수 있게 됐다. 독자들은 어떠한가?

필자는 왜 이렇게 프로그래밍 경험을 중요시할까? 경험에 관련된 필자의 한 후배 이야기를 하고자 한다. 필자의 한 대학 후배는 대학교에 들어와 처음으로 프로그래밍을 시작했다. 상당히 성실했고 머리도 매우 좋아 프로그래밍을 빠르게 배워나갔다. 필자가 보기에도 짧은 기간에 빠르게 프로그래밍을 배우는 것 같았다.

하지만 그 후배는 프로그램을 작성하다 예상하지 못한 문제에 부딪히면 그 문제를 해결하는데 상당한 시간을 소비하고 있었다. 후배가 부딪힌 문제들은 대개 경험 많은 개발자라면 손쉽게 해결할 수 있는 것이었다. 여기서 프로그래밍 경험의 차이가 조금씩 나타나기 시작했다.

그 후배는 프로그래밍을 배운지 얼마 안되 어느 경지에 이르게됐지만 그 경지 이후부터는 성장이 크게 둔화됐다는 것이다. 그 이후의 고급 프로그래머 나아가서 컨설턴트가 되기까지는 많은 경험을 요구하고 있었던 것이다. 짧은 기간에 그러한 경험을 쌓기는 아무래도 무리가 있었나보다.

비단 프로그래밍이 아니더라도 어느 경지까지는 학원이나 도서나 다른 사람의 도움을 통해 열심히 공부해 다다를 수 있다. 그 이후부터는 부단히 많은 경험을 쌓아가면서 다듬는 과정이라 할 수 있다. 경험은 곧 실력과 연결되며 그것은 곧 프로그래머로서의 자신의 가치를 높이는 일이다.

경험을 쌓아가는 좋은 방법은 실제적인 코드를 작성해 보는 것이다. 실제 프로젝트가 있다면 매우 좋겠지만 항상 그럴 수는 없을 것이다. 또한 자신의 관심사와는 다른 프로젝트를 수행할 수도 있을 것이다. 이럴 때에 수십 라인에서 수백 라인정도의 샘플들을 작성해 보는 것은 자신의 경험을 축적하는 좋은 방법이 될 것이라 필자는 생각한다.

한 기술에 정통하려고 노력하자
보다 넓은 경험 외에 한 가지 더 추천하고 싶은 것은 한 가지를 깊이 파고들라고 권하고 싶다. 한 가지 기술에 정통한 사람은 다른 기술에도 쉽게 적응할 수 있다. 대부분 기술들의 뿌리가 비슷하거나 같기 때문이다. 이 규칙이 가장 잘 적용되는 것은 아마도 프로그래밍 언어 분야일 것이다. 한 가지 언어에 정통한 사람은 다른 프로그래밍 언어도 쉽게 배운다.

그것도 초보적인 수준이 아닌 고급 수준에 쉽게 다다를 수 있다. C++에 정통한 사람은 델파이에서 사용하는 오브젝티브 파스칼(Objective Pascal)을 어렵지 않게 습득할 수 있다. 비슷하게 자바에 정통한 사람 역시 C#, 오브젝티브 파스칼 등의 언어에 쉽게 접근할 수 있다. 이유는 프로그래밍 언어들의 기저에 깔려 있는 기술·사상·구현이 서로 비슷하기 때문이다.

프로그래밍 언어뿐만 아니라 분산객체 기술 역시 한 가지 기술에 정통하면 나머지 역시 어렵지 않게 접근할 수 있다. 분산 객체의 기본 사상이 서로 비슷하기 때문에 한 가지 기술을 마스터한 사람은 자기가 알고 있는 기술과 배우고자 하는 기술의 차이점 위주로 지식을 습득하기 때문에 시간을 절약할 수 있다.

게다가 한 기술을 마스터 하면서 쌓은 노하우와 경험은 대부분 새로운 기술에도 비슷하게 적용될 수 있기 때문에 빠른 시간에 고수 반열에 오를 수 있는 것이다. CORBA 고급 엔지니어와 COM 고급 엔지니어가 의사 소통하는데 별다른 어려움이 없는 것은 이런 맥락에서 풀어볼 수 있겠다.

필자는 98년부터 지금까지 COM에 대해 공부하고 실제 프로젝트를 수행해 왔다. 이제 COM 컴포넌트나 액티브X 컨트롤을 만드는 일은 C++, VB, 델파이 등의 다양한 언어로 작성할 수 있게 됐고 다양한 분야에 COM 기술을 응용할 수 있게 됐다. 그리고 1년 전에 등장한 새로운 기술인 닷넷으로 이전하는 데는 그다지 긴 시간을 요구하지 않았다. COM이나 닷넷의 뿌리가 비슷했기 때문이다.

현 세대의 IT 기술은 세분화돼 있으며 정말 다양한 분야가 존재한다. 그리고 많은 기술들의 깊이는 수년에 걸쳐 상당히 심화돼 있다. 개인이 이렇게 다양한 분야의 기술을 모두 정통할 수 없을 것임은 너무도 자명하다. 그렇다면 한 가지 기술을 마스터할 정도로 깊숙이 파고드는 것은 중요하다고 볼 수 있다.

물론 모든 것을 다 할 수 있다면 금상첨화겠지만 그렇게 할 수 없기에 한 가지만이라도 깊숙하게 그 기술을 파고들라는 것이다. 남들이 대부분 알고 있는 정도를 내가 알고 있다면 그것은 그 기술을 심화했다고 할 수 없다. 내가 알고 있고 자유 자재로 남들에게 설명할 수 있는 내용이 다른 사람들이 잘 모르고 있다면 그는 어느 정도의 수준에 올랐다고 볼 수 있을 것이다.

한 가지 기술을 파고들어야 한다면 어떤 기술을 파고들어야 할까? 닷넷인가? 자바인가? 아니면 새로운 그 무엇인가? 만일 자바라면 자바에 대한 모든 것을 깊이 파고들 것인가? 아니면 JSP, EJB 등의 세부 분야에 대해 파고들 것인가? 이것이 선택의 갈림길이며 어려운 부분 중에 하나이다. 이 선택은 순전히 독자들의 몫이다. 기술이 지금까지 발전돼 온 방향과 앞으로 발전 방향을 고려하며 자신의 진로 역시 고려해야 할 것이다. 다만 현재 상황으로 C#과 자바 중 어느 것을 선택하더라도 향후 몇 년 동안 후회하지는 않을 것 같다.

원리를 파악하자
마지막으로 독자들에게 권고하고 싶은 사항은 원리를 파악하라는 것이다. 원리를 파악하는 것만큼 중요한 것은 없다. HTTP의 원리나 TCP/IP의 원리를 모르고 ASP나 JSP를 코딩하는 것과 알고 코딩하는 것은 많은 차이를 드러낸다. 원리를 알고 코딩하는 사람은 다양한 응용이 가능하며, 문제가 발생했을 때 그 문제의 원인이 무엇인지 빨리 알아내고 해결책 역시 빨리 찾아낼 가능성이 높다.

반면 원리를 잘 이해하지 못한 사람들은 응용은 둘째치고 문제가 발생하면 문제의 원인조차 파악해 내지 못하는 경우가 많다. 기초를 건실하게 다져가면 새로운 기술들이 등장하더라도 빠르게 대처할 수 있다. 앞서 제시한 한 가지 기술을 깊게 파고드는 것과 비슷한 맥락으로 한 기술을 깊게 파고들면 그 원리를 터득하게 되는 것은 당연한 결과로 볼 수 있겠다.

그렇다고 지금부터 운영체제·컴파일러·TCP/IP 네트워킹 원리를 공부하라는 얘기는 아니다. 자신이 사용하는 기술을 단순히 '사용'하는 방법만 아는데 그치지 말고 '그 원리가 어떤 것일까'라는 호기심을 갖고 알아보라는 얘기다. ASP 개발자라면 HTTP라는 것이 어떤 프로토콜인가 한번 찔러 보고, HTTP가 TCP/IP를 사용한다던데 하면서 TCP/IP도 한번 찔러 보라는 얘기다. 이런 식으로 원리를 파악하려고 자주 시도하고 실제로 원리를 파악해 내는 것이 중요하다. 원리만을 위해서라면 다시 학교로 돌아가야 할 것이다.

지금까지 필자는 경험을 바탕으로 프로그래밍에 대한 몇 가지 이야기를 소개했다. 황당 에피소드라는 제목 하에 정말 황당한 이야기를 재미있게 했어야 하는데 필자의 글발로는 무리가 있었던 것 같다. 아무쪼록 프로그래밍의 고수가 되는 길은 자신의 부단한 노력과 상당한 시간이 필요함에는

프로그래머를 위한 성공적인 이력서 쓰기 10계명

Justin James ( TechRepublic )   2007/12/11

노 련한 구직자들이 알고 있는 것처럼 일자리를 찾는 첫 번째 단계는 면접을 할 기회를 만들어 주는 이력서를 쓰는 것이다. 불행하게도 전통적인 이력서 작성 규칙 중에는 소프트웨어 개발 산업계에서 잘 먹히지 않는 것이 다소 있다. 다음은 면접을 할 가능성을 높여주는 프로그래머 이력서를 쓰는 10가지 요령이다. 참고: 이 정보는 PDF 다운로드 파일로도 제공된다. 이 주제에 대한 더 자세한 내용은 "프로그래머 구직 이력서 쓰기(Write a resume that will land you a programming job)"라는 블로그 게시물을 참조하라. #1: 보유 기능 목록을 제일 앞에 올리라 고용 담당자는 회사가 찾고 있는 기능을 보유하고 있는지 알고 싶어 한다. 물론 "경력" 란에 구직자의 보유 경력이 잘 나오겠지만, 이력서 상단에 "보유 기능" 란을 넣으면 자연스럽게 그 부분을 제일 먼저 보게 된다. 당연히 그런 이력서를 고르기가 더 쉽다. 동시에 그렇게 하지 않았다면 고용 담당자들이 놓쳐버렸을 수 있는 기능에 관심을 가지게 한다는 장점도 있다. 최소한 고용 담당자는 그 보유 기능 목록을 보게는 된다. #2: 눈길을 끄는 방식으로 경력을 소개하라 일자리를 구하는 대부분의 개발자들은 데이터 중심형 웹 사이트나 데스크톱 애플리케이션을 만든 적이 있다. 따라서 이력서에 그런 일반적인 예를 잔뜩 써 넣는 것은 별로 눈길을 끌지 못한다. 장래의 고용주가 관심을 가지는 것은 독특한 무언가가 있는 경력, 즉 단순히 기본적인 수준의 프로그래밍 작업을 한 것이 아님을 보여주는 경력이다. 독특한 제약 조건이 적용되는 작업을 했거나 트랜잭션이 많이 발생하거나 무장애 실행을 요구하는 환경에서 일한 경력은 이력서를 보는 사람에게 아주 좋은 인상을 준다. 즉, 자신의 경력이 남과 다르다는 것을 보여주어야 다른 사람이 그를 남다른 사람으로 보게 된다. #3: 문법, 철자 및 기타 일반적인 실수를 샅샅이 찾아내어 고치라 고용 업무를 담당하는 동안 필자는 이력서에서 온갖 종류의 문법 오류나 철자 오류를 보았다. 가장 황당했던 경우 중 하나는 자기가 졸업한 대학교의 철자를 잘못 쓴 경우였다. 이력서에는 몇 가지 독특한 문법적인 규칙이 관련되며, 특히 소프트웨어 개발 작업에는 약어나 철자가 특이한 단어들이 관련되는 경우가 많다. 하지만 어떤 경우에도 변명의 여지가 없다. 철자나 문법상으로 실수가 없는지 확인해야 한다. 이 점은 필자가 읽어 본 모든 이력서 관련 지침에 빠지지 않고 나오며, 분명히 강조할 가치가 있다. #4: 학력은 고려 대상이지만 중요하지는 않다 프로그래밍 구직 시장에 이제 막 발을 들여 놓은 사람이나 아주 전문적인 자리를 얻기 위해 이력서를 쓰는 것이 아닌 한 학력은 별로 중요하지 않다. 물론, 이력서에 학력이 빠질 수는 없지만 제일 마지막에 넣는 것이 좋다. 학력에 대해 알아야 하거나 알 필요가 있는 고용 담당자라면 학력 부분까지 읽을 것이고, 그 외의 사람들은 학력을 보느라 시간을 허비할 필요가 없다. 프로그래밍 계통은 변화가 너무 심하기 때문에 7년쯤 뒤에는 (수학이나 "순수" 컴퓨터 공학과 같은 "원론적인" 과목 이외에는) 대부분의 학과목과 자격증은 현재의 실제 업무와 거의 관계가 없다. #5: 빨리 본론으로 들어가라 전통적인 이력서 형식에는 개발 담당자가 볼 때 필요하지 않은 정보가 많이 포함되어 있다. 예를 들면 요약 부분이 그런 정보이며 아마도 목표 부분도 그렇게 볼 수 있을 것이다. 사실 이력서보다 더 간단한 내용으로 프로그래밍 경력을 표현하는 요약을 쓸 수 있는 방법은 없다. 대부분의 요약 항목이 아무 쓸모없는 정보로 보이는 이유가 바로 그것이다. 예를 들어 주요 기능을 기록한 부분 앞에 붙어 있는 "10년 개발 경력의 노련한 프로그래머"라는 표현이 무슨 의미가 있겠는가? 고맙지만, 없으면 더 고맙겠다. 목표는 (항상은 아니지만) 쓸모 없는 경우가 많다. 전직하려는 경우라면 목표는 고용 담당자가 당신의 보유 기능과 경력을 기준으로 당신을 분류하지 못하게 하는 좋은 방법이 될 수 있다. 하지만 선임 개발자 자리로 옮기려고 하는 중급 프로그래머는 목표를 생략해도 무방하다. 소프트웨어 아키텍트나 DBA가 되려고 하는 선임 프로그래머는 목표를 밝혀야 한다. 따라서 요약 부분은 어떻게든 빼고 쓸모 있는 목표만 포함시켜 이력서를 보는 사람이 당신의 보유 기능을 가능한 한 빨리 볼 수 있게 하라. #6: 서식을 주의 깊게 고려하라 이력서 서식은 중요하다. 고급 용지에 이력서를 인쇄하여 발송하던 시절은 오래 전에 지나갔지만 컴퓨터 화면으로 보든 종이로 된 문서이든 간에 이력서는 서식이 있어야 한다. 어쨌든 이력서를 쓰려면 상당한 균형 감각을 가져야 한다. 지금은 자신의 피카소 같은 감각을 과시하는 시대가 아니다. 원하는 자리가 시각적인 예술 감각과 관련이 있는 것이 아닌 한 그렇다. 지금은 가독성을 높여야 하는 시대이다. 가독성을 높이려면 더 큰 글꼴(10~12포인트)를 사용해야 하며 (문서 포맷에 글꼴이 내장되지 않는 한) 모든 컴퓨터에서 사용하는 글꼴이어야 함을 의미한다. 한 마디로 화면으로 보든 인쇄해서 보든 간에 보기 좋아야 한다. 추천할 만한 영문 글꼴은 Verdana, Arial, Tahoma, Calibri, Helvetica 등이다. 문서가 너무 빽빽해 보이지 않도록 여백을 충분히 두어야 한다. 그래야 보는 사람이 질리지 않는다. 반대로, 겨우 200단어를 여덟 페이지로 만들 정도로 공간을 낭비하지 말라. 물론, 파일 자체의 포맷은 중요하다. 필자의 경험으로는 사원 모집 담당자들의 99.9%는 접수된 이력서가 다른 포맷으로 되어 있으면 MS 워드 포맷의 이력서를 요구한다. 따라서 표준 .doc 포맷으로 문서를 만들어야 한다. 이력서가 자신을 상품으로 소개하는 주요 도구라는 사실을 항상 염두에 두어야 한다. 이력서를 보는 사람이 이력서에 담긴 정보를 이해하는 데 어려움이 있다면 그것이 기술적인 문제이든 가독성 문제이든 간에 그들은 즉시 다음 이력서로 넘어간다. #7: 길이에 주의하라 문서 포맷에 관계 없이 아주 특별한 상황이 아닌 한 분량을 2~4페이지 정도로 제한하라. 단기 계약직으로 일하는 데 많은 시간을 보내는 사람들이라면 이력서가 비교적 길 것이며 막 구직 시장에 뛰어든 사람이라면 이력서가 짧을 것이다. 전반적으로 기존의 1페이지 분량의 이력서 서식 안에 자신의 기술적인 보유 기능과 하나 이상의 직장 경력을 적절하게 부각시키기는 어렵다. 2페이지는 중급 개발자나 선임 개발자를 기준으로 한 것이다. 하지만 4페이지 이상이면 이력서를 보는 사람의 눈이 침침해진다. 학력과 마찬가지로 7~8년 전에 가졌던 경력은 별 관계가 없지만, 고용 담당자는 담당한 책임이나 프로젝트 수준이 점점 높아지는 과정을 보고 싶어한다. #8: 경력을 적절하게 정리하라 프로그래밍은 취업 경력 면에서 대부분의 분야와 차이가 있다. 우선, 많은 프로그래머들은 계약직이기 때문에 취업 경력은 줄줄이 이어지는 형태가 되기 마련이다. 뿐만 아니라 닷컴 불황이 지난 지 그렇게 오래 되지 않았으며, IT는 항상 파산, 인수, 합병이 많이 이루어지는 산업계였다. 문제는 고용 담당자는 단기직 경력이 길게 나열된 이력서를 좋아하지 않는다는 점이다. 이력서에 직책이 점점 높아지는 취업 경력이 쭉 이어지고 있다면 충성심이 없는 사람으로 보일 수 있다. 반면에 직무가 기본적으로 동일(하거나 점점 낮아)지는 것처럼 보인다면 실직자라는 느낌을 준다. 계속 단기직으로 일한 정당한 이유가 있다면 반드시 그 이유를 명확하게 밝히라. 예를 들어 계약직/컨설팅 직은 명확하게 표시하라. #9: 이력서를 보는 사람에게 법적인 부담을 주지 마라 어떤 고용 담당자도 고용 과정에서 편파적이거나 차별 대우를 했다고 고발 당하는 것을 좋아하지 않는다. 그런 행동은 비윤리적일 뿐만 아니라 불법이다. 따라서 직무를 올바르게 수행하려고 애쓰고 있는 고용 담당자는 신청인에게 해서는 안되는 질문을 잘 알고 있다. 바꿔 말하면, 이력서를 내는 사람은 그런 내용을 이력서에 포함시켜서는 안된다. 고용 담당자가 알 필요가 없는 그 외의 개인적인 정보도 많다. 관련이 없는 내용을 이력서에 자세히 밝히면 고용 담당자는 겁을 먹고 수동적이 된다. 그런 구체적인 내용은 밝히지 말기 바란다. #10: "튀는 사람이군!" 고등학교에서 튀는 행동으로 왕따를 당하는 것을 좋아하는 사람은 없다. 하지만 지금은 프로그래머로 일자리를 찾고 있는 중이다. 고용 담당자들은 "튀는 사람"을 "돈덩어리"로 본다. 따라서 그들에게 자신이 총명하며 프로그래밍을 사랑하고 끊임없이 성장하면서 새로운 아이디어를 배우고 탐구하는 사람임을 보여줄 수 있는 방법을 찾으라. 오픈소스 프로젝트에 참여하고 있거나 동네 아이들에게 프로그램을 가르치는 자원 봉사 활동을 하고 있다면 그런 취미 활동에 대해 이야기하라. 그런 정보를 통해 고용 담당자들은 당신이 퇴근 후에도 프로그래밍이나 컴퓨터를 다룰 만큼 그런 것을 좋아한다는 것을 알게 된다. 고용 담당자들이 이 문제를 보는 논리는 정말 단순하다. 현재 두 명의 후보자들이 거의 비슷한 수준이라면 내일은 열정이 있는 후보자가 업무를 "단순한 직업"으로 취급하는 후보자보다 훨씬 더 발전해 있기 마련이라는 것이다. @

출처 : zdnet