2015.05.07 15:17

初志一貫 - 처음에 세운 뜻을 끝까지 밀고 나감.

늘 똑같은 일상을 반복하는 것이야 말로 가장 어려운 것이다. 그저, 지금 할 수 있는 것을 한다. 당장 잡을 수 없을 것 같은 꿈에 목말라 하지 않고, 그저 한 걸음 한 걸음 나아갈 뿐이다.

지난 날에 못한 것들, 지금 할 수 없는 것들이 안타까울지라도 지금 할 수 있는 것들을 한다. 흔들리는 마음도 자연스러운 것이나, 다잡을 줄 아는 노력도 함께 어울려야 오래 간다.

The show must go on...


Posted by 善 곽중선
2015.05.07 15:16

수학은 순수 수학(pure)나 응용수학(applied)나 모두 data를 이해하고, logic을 짜는데 더할 나위 없는 도움이 된다고 생각하고 있지만, 실제 '하드웨어'와 '컴파일러'를 이해하기 위해 컴퓨터공학에 대한 공부가 필요하죠. '수학적인 논리(logic)와 공식(formula)를 '코드'로 파싱하는 방법론에 대해서는 계속해서 공부해야 하는 성질이 아닐까 생각되어요.

프로그래밍을 크게 두 가지 성질로 나누면,

  1. 논리(logic)를 생각하는 방법 (알고리즘 혹은 수학적 사고)

  2. 하드웨어/운영체제를 포함한 플랫폼에 대한 이해

이렇게 보고 있는데, 수학은 1)번에 대해서는 무엇보다도 큰 힘이 됩니다. 2)번은 수학을 베이스로 깔고, 따로 공부하셔도 되는 부분이구요.

일단 수학(혹은 논리적 사고)을 베이스로 깔고, 프로그래밍을 열심히 공부하시면, 논리(logic)를 나누는 방법, 데이터를 분류한 뒤, 각각에 대해 합리적으로 착안하는 방법 등에 대해 눈을 뜨기 쉬울 겁니다. 또한, 하드웨어의 원리, 운영체제의 동작방식, 네트워크 이론 등 컴퓨터 공학과 커리큘럼에 포함된 다양한 과목(혹은 분야)에 대한 지식을 함께 공부하셔야 프로그래밍을 잘 할 수 있습니다.


Posted by 善 곽중선
2015.05.07 15:12

별로 아는 것도 없고, 해본 것도 없지만 어찌어찌 오래 살아남다 보니 이런저런 조언을 해주는 위치에 올랐다. 요즘 같은 시절에 젊은 친구들에게 가장 애타는 문제는 취업 문제이니, 공부 방법에 대한 도움보다 '어떻게 취업을 준비하는가?' 에 대한 도움을 간절히 요청하는 경우가 많다.

이런 저런 경험을 바탕으로 기술 면접을 준비하는 자세라거나, 자기소개서 쓰는 법, 프레젠테이션 하는 방법 등에 대해서 나름 실전 경험을 고스란히 전해 주는데 세상사 맘대로 되는 일이 얼마나 되겠는가? 방금 대학원 졸업한 후배가 면접 본 지 몇 주가 지나서야 최종 불합격 되었다고 연락 왔다.

정말 중요한 것은 최선을 다했는가? 아니면, 부족한 점이 있었는가? 자기 반성이나, 노력 유무가 아니라고 생각한다. 씁쓸하지만, '선배님 소주 한 잔 사주세요' 라고 말할 수 있고, 또 그걸 들어줄 사람이 있느냐 하는 것이다.

다들 열심히 산다, 맘대로 안 될 때도 있다. 이러한 좌절의 순간이 그저 악몽이 되고 말 것인지, 아니면 먼 훗날 소주 한 잔의 추억이 될런지는 우리 곁에 누군가가 있으냐에 따라 달라진다. 이러나 저러나 인생이나, 忍(참을 인)生 으로 살 것인가? 아니면 人(사람 인)生으로 살 것인가?


Posted by 善 곽중선
2015.04.23 21:04

나에 대한 긍정적인 댓글은 가급적 그냥 읽어 넘긴다. 간혹 좋아요를 누른다.


잘못된 지식이나, 자세에 대해 지적하는 글에는 감사하는 글을 꼭 남긴다. 잘 모르는 남을 질책하고 지적하는게 쉬운 일이 아니다. 귀찮을 때도 많다. 그럼에도 지적해 준다는 것은 정말 밥이라도 사드려야 할 일이나, 여건이 허락치 않으니 감사의 메시지라도 전해야 한다. 그래야 다음에 또 배울 수 있다. 기껏 지적해줬는데 무시하는 인간에게 계속 관심 주는 사람이 어디 있겠나? 없지야 않겠지만, 사람을 잘 가리지 못하는 분께 배울 것도 막상 많지 않다. 데스노트까지야 아니지만, 나도 나름 블랙 리스트 관리한다. 페이스북 친구 분들 중에는 없으니 신경 쓰지 마시길 바란다.


어쩌다 오해를 사는 일도 있다. 가급적 무시한다. 온라인 상에서 짧은 글만 보고 서로의 입장과 사상을 어찌 다 알 수 있단 말인가? 온라인 상의 논쟁은 별 가치가 없다. 간혹 온라인이라 할지라도 토론하는데 있어 올바른 자세가 무언지를 아는 분을 만날 때가 있는데, 이런 경우는 적극적으로 정반합을 추구하는 토론에 참여한다.


그러니, 결론은 늘 '확고한 주관'을 가지고 살자는 얘기다.


Posted by 善 곽중선
2015.04.09 16:16

다음 주 화요일(2015/04/14) 모교 동아리 신입생들 대상으로 '폰 노이만 아키텍쳐'에 대해 강의할 예정입니다. 강의 내용은 인류가 수와 계산이라는 개념을 어떻게 발전시켜 왔고, 컴퓨터가 어떻게 발명되었는지, 그리고 현대 모든 컴퓨터 구조의 원리를 제시한 폰 노이만 박사의 연구를 설명할 것입니다.


강의를 시작하기에 앞서 질문을 하나 던지고자 합니다.


"컴퓨터는 왜 전기를 필요로 하는가?"


모든 컴퓨터는 전기가 없으면 동작하지 않습니다. 스마트폰 배터리가 떨어질까 전전긍긍하면서 여기저기 콘센트를 찾아 헤매이고, 보조 배터리를 백팩에 무장하고 다니는 것이 현대의 일상적인 풍경이 되어 버렸습니다. 그런데 우리는 -정확히 프로그래머 혹은 지망생들- 컴퓨터가 왜 전기를 필요로 하는지 이해하고 있는 것일까요?


자동차를 동작시키는데 연료가 필요하고, 세탁기를 돌리는데 전기가 필요합니다. 동력기관이 어떤 식으로 움직이는지, 열역학과 동역학에 대한 아주 기초적인 상식을 가지고 있기 때문에 대부분의 사람들은 쉽게 간단하게 설명할 수 있을 것입니다. 하지만, 컴퓨터는 왜 전기를 필요로 할까요? 전기는 어떻게 컴퓨러를 움직이는 것일까요?


어쩌면 하드웨어에 대한 이해와 관심은 소프트웨어 개발자에게 불필요한 지식일수도 있습니다. 그러나 저는 두가지 관점에서 하드웨어에 대한 기초 원리를 이해해야 한다고 생각합니다.


첫번째는 논리적인 사고를 위한 첫걸음입니다. 명령어와 문법, 함수 등을 단지 외우기만 해서는 복잡한 프로그램을 개발할 수 없습니다. 기계- 그것이 전자부품이라고 할지라도 -의 동작 방식을 익히는 것은 소프트웨어에 비해 직관적이기에 더욱 용이합니다. 하드웨어의 동작 방식과 논리 구조를 익힌 후에 소프트웨어를 접할 경우, 소프트웨어의 동작 패턴 또한 기반이 되는 하드웨어에서 데이터가 흘러가고 변화하는 과정으로 머리 속에 그려보면 이해와 응용이 빨라집니다.


두번째는 소프트웨어의 성능 문제와 설계 기법을 익히는데 큰 도움이 됩니다. 거대한 소프트웨어를 설계하기 위해서는 어떤 알고리즘과 자료구조를 사용하는가의 문제 뿐만 아니라, 자신의 소프트웨어를 어떤 하드웨어에서 동작 시키느냐 (PC, 모바일 기기, 클라이언트/서버, 클러스터링, 그리드 등등)에 따라 큰 편차의 성능을 나타내기 마련입니다. 성능 문제는 소프트웨어의 활용가치 뿐 아니라, 존재 가치를 좌우 하기도 합니다. (잘못된 설계는 너무 느리거나, 아예 동작하지 않는 결과물을 만들기도 합니다.)


마지막으로 작고하신 SF 작가이신, 아서 C. 클라크의 명언을 인용합니다.


"충분히 발달한 과학 기술은 마법과 구별할 수 없다."


기술을 제대로 이해하지 못하는 엔지니어는 최신 과학을 접한 고대인과 다를 바 없게 되는 것입니다.


Posted by 善 곽중선
2015.03.18 14:08

봉급쟁이 생활을 20년 가까이 하고 있는데,

나 스스로 일을 잘하고 있는가에 대해 생각해 본다.


- 학부 시절에는 대학원도 없고, 교수 연구생도 공식적으로 없었으나, 학과 역사상 최초로 비공식 교수연구생이 되었다. 교수님 연구실에서 3번이나 쫒녀나는 진기록도 세우고 - 전무후무함 -, 아래한글 초창기 버전으로 제대로 그려지지도 않는 행렬 수식 등을 독학으로 학습하며 논문 편집도 도와 드리고, 혼자서 이리 삽질 저리 삽질 많이  했다. 당시 교수님은 공부하는 법, 일하는 법 무엇하나 가르쳐주신 게 없다. 그건 학과 모든 교수님들의 공통된 교육 방식이었으니 할 말은 없다. 하여간 익힌게 하나 있다면... 아무리 힘들어도 버텨야 한다는 점, 강한 놈이 살아남는 게 아니라, 살아남는 놈이 강한 것이다.


- 사회 생활 초년에 배운 것은 영어의 필요성. 대충 알아듣는 실력으로 두번이나 해외 교육 받고, 프랑스 국적의 수퍼 프로그래머, 그리고 지금은 모 컨설팅 회사의 대표로 계신 OOP 매니아 과장님 덕분에 영어의 중요성을 깨달았다. 한가지 더 깨달은 것이 있다면 이론적이고 기초적인 지식도 충분히 갖추어야 한다는 점. 현장에서 오고가는 수많은 기술 용어들에 대해서 아무도 친절히 설명해 주지 않는다. 못 알아 먹어도 일은 할 줄 알아야 한다. 눈치가 빠르던지, 아니면 계속 메모하면서 저녁마다 인터넷을 검색하던지... 미리 예습/복습 안한 놈은 나이 들어서 고생하는 법이다.


- 그나마 회사 이익에 기여를 하게된 경력을 갖추었을 때 배운 것은 눈치,코치 그리고 처세와 라인의 중요성. 나름 대기업 계열에서 일한다는 것은 실력이 전부가 아니다. 최선은 필요없다. 아무도 인정하지 않는 자기 위안일 뿐이다. 일단, 실력 면에서 사내외의 경쟁상대를 압도하는 것은 기본 중의 기본이요. 위아래 좌우 평판, 정치판을 잘 넘나들어야 한다. 그런 거 절대로 안한다고 버티다가, IMF 터지자 마자 냉정하게 내쳐졌다. 나이 서른에 병역 특레 4년차에 군대 입대해야 하느냐고 항변했더니만, 가라고 하더라.


- 구멍가게 전전하는 시절. 좋은 말로 벤쳐하던 시절. 나름 개발 업무 전체를 책임지는 입장이 되다 보니, 혼자서 다해서는 안되는 일이다. SI 시절에 어깨너머 배우던 여러 방법론 자료를 펼쳐 놓고, 내가 처한 환경에 어떻게 적용할 것인가? 소위 말하는 tailoring 도 해보고, 업무 절차 표준화도 해보고 많은 고민을 했다. 결론은 일은 사람이 하는 것이지 결코 매뉴얼(manual)대로 되는 것이 아니다. 매뉴얼이 불필요한 것은 아니나, 제조업종과 소프트웨어업종은 근본적인 차이가 있다는 것을 깨달았다. 무려 식스 시그마를 소프트웨어 업종에 적용하자는 소리에 솔깃했던 순간도 있었다. 부끄러운 얘기지만, 당시에는 똑똑한 컨설턴트들 말씀이 하나님 말씀과 동격인줄 알았다.

그리고 잠시나마 에자일 프로세스에 호기심을 느꼈던 적도 있다. 여러 책도 읽어보고 사례 분석도 해보았지만, 에자일 방식을 채택한 팀이 제대로 흘러가기 위해서는 팀원들의 수준이 일정 수준이 되어야 한다는 것을 깨닫고 포기했다.


- 결론을 맺자. 틀에 박힌 방법론은 시시각각 돌변하는 예측 불가한 상황에 대처하기 어렵다. 방법론에서 자체가 틀렸다면 어찌할 것인가? 눈앞에 절벽이 있어도 매뉴얼에서 나아가라고 하면 나아가야만 하는가? 애자일은 회고라는 방식을 통해 시행착오를 최소화 한다. 하지만, 애자일은 프로젝트의 전체 규모를 예측하고, 투자를 결정하며, 짜여진 계획대로 흘러가기를 원하는 문화를 가진 조직에서는 받아들여지기 어렵다. 남의 지붕 아래서는 일하는 처지에 방법론을 내가 선택할 수도 없다.


지금 생각하는 최선은 나중에 어찌 될런지 모르지만, 모든 시도과 경험에 대한 기록을 남기자는 것이다. 결과가 아니라, "근거 : rationale"를 남기는 것이 중요하다는 것이다. 간단하다. 결과가 아니라, 과정을 기록하는 것이다.

Posted by 善 곽중선
2015.03.03 22:30

전에도 유사한 이야기를 한 적이 있는 것 같은데, 이번에는 조금 다른 이야기를 해보렵니다. 답변하지 않게 되는 질문의 대다수는 제가 잘 모르는 분야입니다. 어설프게 답변하거나 아는 체 하는 수준 정도로 얘기할 수 있는 것에는 답하지 않습니다. 해당 분야에 호기심이 있을 경우에는 의견이라 밝히고, 할 말이 아예 없으면 "알림 켜기"로 보이지 않는 와드를 박아두기도 합니다.


다음으로 질문자가 자신이 무엇을 질문하는지 조차 모르는 상태로 판단되면 질의응답이 혼란의 카오스에 빠질 수 있어서 자제합니다. 간혹 오지랖이 넘쳐서 질문 의도를 되묻기는 합니다만 그건 실수하고 있는 겁니다. 실수라는 걸 깨달으면 재빨리 발을 뺍니다.


마지막으로 질문자가 열정적이고 자신이 무얼 묻는지 아는데 답변 안하는 경우가 있습니다. 이런 경우 갈등에 빠지죠. 가이드 할 것인가 말 것인가? 대부분 답변을 안합니다. 어떤 상황인지 비유를 통해 이야기해 보겠습니다.

남자들 중에는 프라모델이나, 피규어를 좋아하는 사람들이 있습니다. 라즈베리파이 같은 보드를 이용한 하드웨어 매니아를 예로 들 수도 있죠. 고가의 장난감(?)인데다 섬세한 부품들로 이루어져 있습니다. 이런 걸 우악스럽게 집어던지거나, 부품들을 마구 뽑고 비트는 유치원 다니는 사촌동생이 찾아왔다면 과연 차분하게 조립하거나 다루는 법을 설명할 수 있을까요? 그냥 숨기는 편이 나을 겁니다.


남자들의 사례가 이해 안가신다면, 여자분들이 아끼는 메이크업 화장품을 어린 조카가 마구 꺼내서 얼굴에 치덕치덕 바르는 상황을 예시할 수도 있겠죠.


기술도 열정만으로 혹은 성실함 만으로 익힐 수 있는 게 아닙니다. 나이가 많건 적건 간에 선행 지식, 기초 이론을 공부할 건 해야만 합니다. 그저 열정만으로 자신의 수준을 뛰어넘는 공부에 매달리는 것은 자칫 시간낭비가 될 수 있습니다. 안스럽거나 혹은 도움을 주고 싶은 순수한 마음만으로 조언을 해준다 해도 배우는 입장에서 어렵습니다. 어린 사촌동생에게 아무리 잔소리를 한들 섬세한 피규어의 까다로움을 받아들이기 어렵고, 자칫 갈등만 생길 뿐입니다.


부디 이런 분들은 스스로 깨우치시고 다시 기초 원리를 공부하시길 코드의 신께 기도할 뿐이죠.


Posted by 善 곽중선
2015.03.03 22:29

IT 공부를 20년 넘게 하면서 지식 하나 하나를 가르치며 이끌어 준 선배나 사수가 없었던 것을 오히려 감사하며 산다. 내가 누군가에게 틀에 박힌 지식을 전수받고, 자세 하나하나를 교정 받으며 배웠다면 지금의 내가 될 수는 없었을 것이다.


그 누구에게도 나를 닮으라고 이야기하지 않으며, 스스로 길을 찾게끔 조용히 뒤를 지키는 것은 누구에게도 배우지 않았기 때문이다. 내가 배운 것이 없으니 가르칠 것도 없다. 그저 스스로 찾아가게끔, 다만 엉뚱한 길로 벗어나지는 않는지 살피는 노력 정도만 할 뿐이다.


미래는 아무도 모른다. 내가 이미 알고 있는 지식은 과거의 산물이다. 지식은 가르칠 수 있어도 지혜는 가르칠 수 없다. 과거의 지식만을 쫒는 사람에게서 발전을 기대할 수는 없다. 내가 후배들에게, 또 주변 사람들에게 바라는 것은 부디 나를 뛰어 넘는 것이다. 그렇게 되기 위해서는 내가 장벽이 되어서는 안되고, 그늘을 만들어서도 안된다. 이미 많은 후배들이 그러했듯이, 또 앞으로도 많은 후배들이 나를 뛰어 넘기를 바란다.

Posted by 善 곽중선
2015.03.03 22:28

잘 배우려면 먼저 질문을 잘하는 기술을 익혀야 한다. 꼬장꼬장 하다는 소리를 들어도 질문을 잘 못하는 사람에게 되묻는 편이다. 질문이 이상하지 않냐고? 그냥 가르쳐 주면 안되냐고 짜증 내는 친구들보다 질문을 고쳐서 다시 묻는 친구들이 성장한다.

모호하게 아는 것은 지식이 되지 못한다. 그건 그냥 데이터(data)일 뿐이다. data 와 information은 다른 것이다. data는 숫자와 문자의 무의미한 집합이며 활용할 수 없는 것이고, information은 체계적이고 가치 있으며, 활용할 수 있는 것을 말한다.

좋은 질문은 답변을 잘 분류할 수 있게 하고, 잘 분류된 답변은 찾기 용이하며, 정보와 정보 간의 연결과 조합을 통한 창의적인 응용을 가능하게 한다.

좋은 질문은 자신이 이미 아는 것과 새롭게 아는 것을 연결 시켜 지식의 피라미드를 쌓을 수 있게 하고, 무너지지 않는 단단한 구조를 만들어내지만, 나쁜 질문은 그저 모래성을 쌓는 것과 같다.


Posted by 善 곽중선
2015.02.20 13:29

한동안 접고 살던 Spring framework오픈 소스를 다시 꺼내 분석한다면 나는 어떻게 할까? 일단 생각해보고 정리를 하자니... 장강의 뒷물의 앞물을 밀어낸다고 - 이게 아닌가? 아무튼 생각이 유실될 우려가 있어 그냥 냅다 적어보기로 한다.


남의 소스를 분석한다는 것은 남의 생각 속을 여행하는 것에 비유할 수 있다. "여행"을 하려면 무엇이 필요한가? 아니, 길을 잃지 않기 위해서는 무엇이 필요한지 생각해보자. "GPS"과 "지도"가 필요할 것이다. 그리고, 내가 가야할 길은 아직 가보지 않은 길이기 때문에 욕심 부리지 않는 '자세'를 준비하자. (무심결에 나침판이라고 적고 보니... 21세기인데.. 라는 생각이 들어 고쳤다.)


항해(navigation)를 시작하기 전에 준비물이 잘 갖추어 있는지 확인해 보자.


1. GPS (Global Positioning System)


프로그래머에게 필요한 GPS는 당연히 실제 물리적인 장치가 아니다. 소스를 분석할 때, 내가 어떤 소스를 분석하고 있으며, 다음으로 어느 소스를 분석해야 하는지를 판단하는데 필요한 도구이다.


내가 생각하는 소스 분석에 필요한 GPS 도구들은 다음과 같다. 프로그래밍 언어론에 대한 기초 지식 혹은 프로그래밍 언어 문법에 대한 정확한 지식이다. 언어를 모르는 사람이 소스를 분석하겠는가 라고 반문하겠지만, 남의 소스를 분석하다 보면 평소에 모르던 키워드나 연산자 혹은 문법을 마주치는 법이 생기게 마련이다. 막다른 골목에 다다르는 것과 같은 현상이 벌어진다. 즉, 머리속이 하얗게 지워진다. 이전까지 분석한 게 다 머리 속에서 지워지고 만다. goto 명령어는 자바에도 있다. 안쓸거라고 생각지 마라. 다중 루프에서 고속으로 탈출하기 위해 사용되는 경우도 간혹 있다. final 이 클래스에 붙어 있을 때 그 의미를 파악하지 못하거나, public 수식어가 없는 클래스의 의미를 모르면 오픈 소스 설계자의 진의를 절대 파악할 수 없다. 문법 공부할 때 뒷장은 건너뛴 사람은 분석하다가 오도가도 못하는 신세에 빠지는 경우가 많다. 언어의 문법을 일부만 알고 오픈 소스를 분석하는 것은 단어 몇개만 배우고, 사전도 없이 뉴욕 한복판에서 엠파이어 스테이트 빌딩을 찾는 것과 같다.


다음으로 상속과 합성에 대한 개념이다. 상속과 합성은 이정표에 해당한다. 객체지향이건 절차지향이건 간에 소프트웨어는 항상 '부품'들이 조립되는 방식으로 구축된다. 그런데, 상속과 합성의 개념을 제대로 모르면 위아래로 이동해야 하는지, 좌우로 움직이야 하는지 모르게 된다. 그리고 코드를 따라가다가 어떻게 되돌아 가야 하는지 모르게 된다. 미로에 빠지고 말 것이다. 그냥 상속만 익히면 된다고 생각지 말라. 인터페이스와 구현체 간의 관계 등을 모르면 지나쳐도 되는 코드와 코드들의 집합인 모듈 단위를 전혀 알아 볼 수 없게 된다. 코드는 단순히 작은 메소드들의 무수한 나열이 아니다. 작은 단위들이 모여 큰 단위를 이루고 작고 큰 구조를 표현하기 위해 인터페이스 상속과 패키지 개념들이 있는 것이다. 모르고 보면 아무리 보고 또 봐도 까만 건 코드, 하얀 건 배경일 뿐이다.


리팩토링은 몰라도 된다. TDD도 필요 없다. 다만, 디자인 패턴은 알아야 한다. 패턴을 이해하는 것은 운전 면허 시험을 배울 때, 교차로와 순환로 등 다양한 도로 형태를 배우는 것과 동일하다. 사람은 익숙한 지형이나 형태를 보면 깊이 생각할 필요도 없이 반사적으로 움직일 수 있다. 소스 분석도 이와 같다. 패턴을 모르면 그만큼 분석하는데 드는 시간이 기하급수적으로 늘어난다.


이클립스 혹은 IntelliJ 같은 IDE 사용 방법에도 능숙해야 한다. 탐색기를 이용해서 소스를 하나씩 열어보거나, notepad++ 로 수많은 소스를 열어 본다면? 노가다로 시간 낭비하지 말자. 상위 클래스, 하위 클래스, 참조 위치 등등 단축키만 알면 아무리 멀고 먼 위치도 워프(warp) 할 수 있는 순간이동 능력을 갖출 수 있게 된다. 다만, 앞서 말한 상속과 합성 개념이 머리에 박혀있지 않으면 금새 지나온 길을 잃어 버리게 된다.


API와 라이브러리에 대한 경험... 코드를 따라가다 보면 자칫 너무 깊이 파서 땅속으로 파고 들 수 있다. 궁금하다고 클릭하다 보면 어느새 JDK 소스를 보고 있다는 사실 조차 모르게 된다. 그럴리 없다고 생각지 말라. JDK를 설치하면 소스도 따라온다. IDE에 decompiler를 설치해두면 클릭 한 번에 지하세계로 떨어진다. 라이브러리도 마찬가지인데, 자칫 내가 프레임워크를 분석하고 있는 건지 라이브러리 코드를 분석하고 있는 건지 혼란에 빠지게 된다. 더 심하면, 프레임워크가 의존하고 있는 라이브러리와 프레임워크를 구분하지 못하는 일체의 경지에 빠지게 된다.


2. 지도 (map)

무턱대고 서울 간다고 지도도 없이 나서면, 어느 산골 구석이나 경찰서 유치장에서 발견될 수도 있다. 오픈소스를 막무가내로 이해하려는 개발자라면, 소프트웨어에 대한 환멸을 느끼고 IT 업계를 영영 떠날 수도 있다.


가급적 분석하고자 하는 오픈소스에 대한 설계에 대해 많은 정보를 제공하는 책을 구해야 한다. 오픈소스를 창작자가 서술한 책이면, 창시자의 철학을 옅볼 수 있기 때문에 가장 좋고, 없다면 가장 두꺼운 책을 사야 한다. 두꺼울수록 다루는 부분이 많기 때문에 분석하면서 낯선 코드를 만나는 경험이 줄어든다. 책을 통해 큰 흐름과 전체 얼개를 파악하면 많은 시간을 절약할 수 있다. 책을 사기 싫다면 해당 오픈 소스의 홈페이지의 introduction, user's guide, 그리고 각종 reference 문서를 최대한 많이 읽어두면 좋다. 책도 안사고, 홈페이지에도 안 가 봤다면 분석을 포기해라. 당신이 수재 이상의 머리를 가지고 있지 않다면... 샹 폴리옹인가? 그럼, 구글 가라.


영어가 싫다면 해당 오픈 소스에 대해 언급된 국내 블로거들의 글을 최대한 검색해서 많이 읽어라. 그 어떤 책이나 블로그 글도 오픈 소스 전체를 설명할 수는 없지만, 부분에 대한 이해만 해도 길을 찾는데 큰 도움이 될 것이다. 그리고, 사전에 해당 오픈 소스에서 많이 쓰이는 클래스/ 메소드 명칭에 익숙해지면 좀 더 소스가 자연스럽게 읽힌다. 인간의 두뇌는 익숙한 것일수록 해석 속도가 매우 빨라지기 때문이다.


마지막으로 종이와 연필을 준비해라. 소스를 분석하면서 눈에 띄는 소스 파일 명칭과 메소드 명칭들을 적고, 클래스 다이어그램과 시퀀스 다이어그램을 그려본다. 직접 지도를 만들라는 것이다. 종이에 적으라는 이유는 우선 컴퓨터 화면에는 소스만 띄워놓아야 집중이 잘되고 덜 산만하다는 것이고, 사람 머리는 손으로 무언갈 쓰거나 할 때 논리회로가 잘 돌아간다. 참고로 Robert C Martin 선생님이 말씀하시길 UML을 그리는데 있어서 가장 좋은 도구는 종이와 연필이라고 했다.


내가 선호하는 오픈 소스 분석 방법은 디버거(debugger) 혹은 로그 분석을 해보는 것이다.어플리케이션을 디버그 모드로 실행하면서 stack trace을 추적해보거나, 분석하고자 하는 위치에 break point를 걸어둔 후에 정지 시키고 나서 해당 위치가 실행되기 이전과 이후를 분석한다. 때로는 일부러 예외를 발생시킨후에 로그를 분석하기도 한다. 대다수의 오픈 소스는 debug, trace 로그 출력을 제어할 수 있기 때문에 상당히 긴 로그를 분석할 각오가 되어 있다면, 로그 출력 수준을 높이고 (TRACE 레벨) 프로그램을 실행시켜 보는 것도 한 방법이다. 당연히 log4j 혹은 logback 환경 설정을 선행하는 것은 필수 작업이다.

Posted by 善 곽중선