| 프로그래머의 공부법 | 독서일기 | 2004/11/18 01:03 |
| http://blog.naver.com/hmh919/80007779968 | |
| 우리 프로그래머들은 항상 공부해야 합니다. 우리는 지식을 중요하게 여깁니다. 하지만 지식에 대한 지식, 즉 내가 그 지식을 얻은 과정이나 방법 같은 것은 소홀히 여기기 쉽습니다. 따라서 지식의 축적과 공유는 있어도 방법론의 축적과 공유는 매우 드문 편입니다. 저는 평소에 이런 생각에서 학교 후배들을 위해 제 자신의 공부 경험을 짬짬이 글로 옮겨놓았고, 이번 기회에 그 글들을 취합, 정리하게 되었습니다. 그 결실이 바로 이 글입니다 이 글은 공부하는 방법과 과정에 관한 글입니다. 이 글은 제가 공부한 성공/실패 경험을 기본 토대로 했고, 지난 몇 년간 주변에서 저보다 먼저 공부한 사람들의 경험을 관찰, 분석한 것에 제가 다시 직접 실험한 것과 그밖에 오랫동안 꾸준히 모아온 자료들을 더했습니다. '만약 다시 공부한다면' 저는 이렇게 공부할 것입니다. 부디 독자 제현께서 이 글을 씨앗으로 삼아 자신만의 나무를 키우고 거기서 열매를 얻고, 또 그 열매의 씨앗이 다시 누군가에게 전해질 수 있다면 더 이상 바랄 것이 없겠습니다. 이 글은 특정 주제들의 학습/교수법에 대한 문제점과 제가 경험한 좋은 공부법을 소개하는 식으로 구성됐습니다. 여기에 선택된 과목은 리팩토링, 알고리즘·자료구조, 디자인패턴, 익스트림 프로그래밍(Extreme Programming 혹은 XP) 네 가지입니다. 이 네 가지가 선택된 이유는 필자가 관심있게 공부했던 것이기 때문만은 아니고, 모든 프로그래머에게 어떻게든 널리 도움이 될만한 교양과목이라 생각하여 선택한 것입니다. 그런데 이 네 가지의 순서가 겉보기와는 달리 어떤 단계적 발전을 함의하는 것은 아닙니다. 수신(修身)이 끝나면 더 이상 수신은 하지 않고 제가(齊家)를 한다는 것이 어불성설인 것과 같습니다. 원래는 글 후미에 일반론으로서의 공부 패턴들을 쓰려고 했습니다. 하지만 지면의 제약도 있고, 독자 스스로 이 글에서 그런 패턴을 추출하는 것도 의미가 있을 것이기에 생략했습니다. 그런 일반론이 여기 저기 숨어있기 때문에 알고리즘 공부에 나온 방법 대부분이 리팩토링 공부에도 적용할 수 있고, 적용되어야 한다는 점을 꼭 기억해 주셨으면 합니다. 다음에 기회가 닿는다면 제가 평소 사용하는 (컴퓨터) 공부패턴들을 소개하겠습니다. 알고리즘·자료구조 학습에서의 문제 우리는 알고리즘 카탈로그를 배웁니다. 이미 그러한 해법이 존재하고, 그것이 최고이며, 따라서 그것을 달달 외우고 이해해야 합니다. 좀 똑똑한 친구들은 종종 "이야 이거 정말 기가 막힌 해법이군!"하고 감탄할지도 모릅니다. 대부분의 나머지 학생들은 그 해법을 이해하려고 머리를 쥐어짜고 한참을 씨름한 후에야 어렴풋이 왜 이 해법이 그 문제를 해결하는지 납득하게 됩니다. 그리고는 그 '증명'은 책 속에 덮어두고 까맣게 사라져버립니다. 앞으로는 그냥 '사용'하면 되는 것입니다. 더 많은 대다수의 학생은 이 과정이 무의미하다는 것을 알기 때문에 왜 이 해법이 이 문제를 문제없이 해결하는지의 증명은 간단히 건너뜁니다. 이런 학생들은 이미 주어진 알고리즘을 사용하는 일종의 객관식 혹은 문제 출제자가 존재하는 시험장 상황에서는 뛰어난 성적을 보일 것임은 자명합니다. 하지만 스스로가 문제와 해답을 모두 만들어내야 하는 상황이라면, 또는 해답이 존재하지 않을 가능성이 있는 상황이라면, 혹은 최적해를 구하는 것이 불가능에 가깝다면, 혹은 알고리즘을 완전히 새로 고안해내야 하거나 기존 알고리즘을 변형해야 하는 상황이라면 어떨까요? 교육은 물고기를 잡는 방법을 가르쳐야 합니다. 어떤 알고리즘을 배운다면 그 알고리즘을 고안해낸 사람이 어떤 사고 과정을 거쳐 그 해법에 도달했는지를 구경할 수 있어야 하고, 학생은 각자 스스로만의 해법을 차근차근 '구성'(construct)할 수 있어야 합니다(이를 교육철학에서 구성주의라고 합니다. 교육철학자 삐아제(Jean Piaget)의 제자이자, 마빈 민스키와 함께 MIT 미디어랩의 선구자인 세이머 페퍼트 박사가 주창했습니다). 전문가가 하는 것을 배우지 말고, 그들이 어떻게 전문가가 되었는지를 배우고 흉내 내야 합니다. 결국은 소크라테스적인 대화법입니다. 해답을 가르쳐 주지 않으면서도 초등학교 학생이 자신이 가진 지식만으로 스스로 퀵소트를 유도할 수 있도록 옆에서 도와줄 수 있습니까? 이것이 우리 스스로와 교사들에게 물어야 할 질문입니다. 왜 우리는 학교에서 '프로그래밍을 하는 과정'이나 '디자인 과정'(소프트웨어 공학에서 말하는 개발 프로세스가 아니라 몇 시간이나 몇 십 분 단위의, 개인적인 차원의 사고 과정 등을 일컫습니다)을 명시적으로 배운 적이 없을까요? 왜 해답에 이르는 과정을 가르쳐주는 사람이 없나요? 우리가 보는 것은 모조리 이미 훌륭히 완성된, 종적 상태의 결과물로서의 프로그램뿐입니다. 어느 날 문득 하늘에서 완성된 프로그램이 뚝 떨어지는 경우는 없는데 말입니다. 교수가 어떤 알고리즘 문제의 해답을 가르칠 때, "교수님, 교수님께서는 어떤 사고 과정을 거쳐, 그리고 어떤 디자인 과정과 프로그래밍 과정을 거쳐서 그 프로그램을 만드셨습니까?"하고 물어봅시다. 만약 여기에 어떤 체계적인 답변도 할 수 없는 분이라면 그 분은 자신의 사고에 대해 '사고'해 본 적이 없거나 문제 해결에 어떤 효율적 체계를 갖추지 못한 분이며, 따라서 아직 남을 가르칠 준비가 되어있지 않은 분일 것입니다. 만약 정말 그렇다면 우리는 어떻게 해야 할까요? 자료구조와 알고리즘 공부 제가 생각건대, 교육적인 목적에서는 자료구조나 알고리즘을 처음 공부할 때 우선은 특정 언어로 구현된 것을 보지 않는 것이 좋을 때가 많습니다. 대신 말로 된 설명이나 의사코드(pseudo-code) 등으로 그 개념까지만 이해하는 것이죠. 그 아이디어를 절차형(C, 어셈블리어)이나 함수형(LISP, Scheme, Haskell), 객체지향(자바, 스몰토크) 언어 등으로 직접 구현해 보는 겁니다. 그 다음에는 다른 사람이나 다른 책의 코드와 비교합니다. 이 경험을 애초에 박탈당한 사람은 귀중한 배움과 깨달음의 기회를 잃은 셈입니다. 만약 여러 사람이 함께 공부한다면 각자 동일한 아이디어를 같은 언어로 혹은 다른 언어로 어떻게 다르게 표현했는지를 서로 비교해 보면 배우는 것이 무척 많습니다. 우리가 자료구조나 알고리즘을 공부하는 이유는, 특정 '실세계의 문제'를 어떠한 '수학적 아이디어'로 매핑시켜 해결할 수 있는지, 그것이 효율적인지, 또 이를 컴퓨터에 어떻게 효율적으로 구현할 수 있는지 따지고, 그것을 실제로 구현하기 위해서입니다. 따라서 이 과정에 있어 실세계의 문제를 수학 문제로, 그리고 수학적 개념을 프로그래밍 언어로 효율적으로 표현해내는 것은 아주 중요한 능력이 됩니다. 알고리즘 공부에서 중요한 것 개별 알고리즘의 목록을 이해, 암기하며 익히는 것도 중요하지만 더 중요한 것은 다음 네 가지입니다. ①알고리즘을 스스로 생각해낼 수 있는 능력 ②다른 알고리즘과 효율을 비교할 수 있는 능력 ③알고리즘을 컴퓨터와 다른 사람이 이해할 수 있는 언어로 표현해낼 수 있는 능력 ④이것의 정상작동(correctness) 여부를 검증해 내는 능력 첫 번째가 제대로 훈련되지 못한 사람은 알고리즘 목록의 스테레오 타입에만 길들여져 있어서 모든 문제를 자신이 아는 알고리즘 목록에 끼워 맞추려고 합니다. 디자인패턴을 잘못 공부한 사람과 비슷합니다. 이런 사람들은 마치 과거에 수학 정석만 수십 번 공부해 문제를 하나 던져주기만 하면, 생각해보지도 않고 자신이 풀었던 문제들의 패턴 중 가장 비슷한 것 하나를 기계적·무의식적으로 풀어제끼는 문제풀이기계와 비슷합니다. 그들에게 도중에 물어보십시오. "너 지금 무슨 문제 풀고 있는 거니?" 열심히 연습장에 뭔가 풀어나가고는 있지만 그들은 자신이 뭘 풀고 있는지도 제대로 인식하지 못 하는 경우가 많습니다. 머리가 푸는 게 아니고 손이 푸는 것이죠. 이렇게 되면 도구에 종속되는 '망치의 오류'에 빠지기 쉽습니다. 새로운 알고리즘을 고안해야 하는 상황에서도 기존 알고리즘에 계속 매달릴 뿐입니다. 알고리즘을 새로 고안해 내건 혹은 기존의 것을 조합하건 스스로 생각해 내는 훈련이 필요합니다. 두 번째가 제대로 훈련되지 못한 사람은 일일이 구현해 보고 실험해 봐야만 알고리즘 간의 효율을 비교할 수 있습니다. 특히 자신이 가진 카탈로그를 벗어난 알고리즘을 만나면 이 문제가 생깁니다. 이건 상당한 대가를 치르게 합니다. 세 번째가 제대로 훈련되지 못한 사람은, 문제를 보면 "아, 이건 이렇게 저렇게 해결하면 됩니다"하는 말은 곧잘 할 수 있지만 막상 컴퓨터 앞에 앉혀 놓으면 아무 것도 하지 못합니다. 심지어 자신이 생각해낸 그 구체적 알고리즘을 남에게 설명해 줄 수는 있지만, 그걸 '컴퓨터에게' 설명하는 데는 실패합니다. 뭔가 생각해낼 수 있다는 것과 그걸 컴퓨터가 이해할 수 있게 설명할 수 있다는 것은 다른 차원의 능력을 필요로 합니다. 네 번째가 제대로 훈련되지 못한 사람은, 알고리즘을 특정 언어로 구현해도, 그것이 옳다는 확신을 할 수 없습니다. 임시변통(ad hoc)의 아슬아슬한 코드가 되거나 이것저것 덧붙인 누더기 코드가 되기 쉽습니다. 이걸 피하려면 두 가지 훈련이 필요합니다. 하나는 수학적·논리학적 증명의 훈련이고, 다른 하나는 테스트 훈련입니다. 전자가 이론적이라면 후자는 실용적인 면이 강합니다. 양자는 상보적인 관계입니다. 특수한 경우들을 개별적으로 테스트해서는 검증해야 할 것이 너무 많고, 또 모든 경우에 대해 확신할 수 없습니다. 테스트가 버그의 부재를 보장할 수는 없습니다. 하지만 수학적 증명을 통하면 그것이 가능합니다. 또, 어떤 경우에는 수학적 증명을 굳이 할 필요 없이 단순히 테스트 케이스 몇 개만으로도 충분히 안정성이 보장되는 경우가 있습니다. 이럴 때는 그냥 테스트만으로 만족할 수 있습니다. 실질적이고 구체적인 문제를 함께 다루라 자료구조와 알고리즘 공부를 할 때에는 가능하면 실질적이고 구체적인 실세계의 문제를 함께 다루는 것이 큰 도움이 됩니다. 모든 학습에 있어 이는 똑같이 적용됩니다. 인류의 지성사를 봐도, 구상(concrete) 다음에 추상(abstract)이 옵니다. 인간 개체 하나의 성장을 봐도 그러합니다. 'be-동사 더하기 to-부정사'가 예정으로 해석될 수 있다는 룰만 외우는 것보다 다양한 예문을 실제 문맥 속에서 여러 번 보는 것이 훨씬 나을 것은 자명합니다. 알고리즘과 자료구조를 공부할 때 여러 친구들과 함께 연습문제(특히 우리가 경험하는 실세계의 대상들과 관련이 있는 것)를 풀어보기도 하고, ACM의 ICPC(International Collegiate Programming Contest: 세계 대학생 프로그래밍 경진 대회) 등의 프로그래밍 경진 대회 문제 중 해당 알고리즘·자료구조가 사용될 수 있는 문제를 같이 풀어보는 것도 아주 좋습니다. 이게 가능하려면 "이 알고리즘이 쓰이는 문제는 이거다"하고 가이드를 해줄 사람이 있으면 좋겠죠. 이것은 그 구체적 알고리즘·자료구조를 훈련하는 것이고, 이와 동시에 어떤 알고리즘을 써야할지 선택, 조합하는 것과 새로운 알고리즘을 만들어내는 훈련도 무척 중요합니다. 알고리즘 디자인 과정의 중요성 알고리즘을 좀더 수월하게, 또 잘 만들려면 알고리즘 디자인 과정에 대해 생각해 봐야 합니다. 그냥 밑도 끝도 없이 문제를 쳐다본다고 해서 알고리즘이 튀어나오진 않습니다. 체계적이고 효율적인 접근법을 사용해야 합니다. 대표적인 것으로 다익스트라(E. W. Dijkstra)와 워스(N. Wirth)의 '조금씩 개선하기'(Stepwise Refinement)가 있습니다. 워스의 「Program Development by Stepwise Refinement」(1971, CACM 14.4, http://www.acm.org/classics/dec95)를 꼭 읽어보길 바랍니다. 여기 소개된 조금씩 개선하기는 구조적 프로그래밍에서 핵심적 역할을 했습니다(구조적 프로그래밍을 'goto 문 제거' 정도로 생각하면 안 됩니다). 다익스트라의 「Stepwise Program Construction」(Selected Writings on Computing: A Personal Perspective, Springer-Verlag, 1982, http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD227.PDF)도 추천합니다. 알고리즘 검증은 알고리즘 디자인과 함께 갑니다. 새로운 알고리즘을 고안할 때 검증해 가면서 디자인하기 때문입니다. 물론 가장 큰 역할은 고안이 끝났을 때의 검증입니다. 알고리즘 검증에는 루프 불변식(loop invariant) 같은 것이 아주 유용합니다. 아주 막강한 무기입니다. 익혀 두면 두고두고 가치를 발휘할 것입니다. 맨버(Udi Manber)의 알고리즘 서적(『Introduction to Algorithms: A Creative Approach』)이 알고리즘 검증과 디자인이 함께 진행해 가는 예로 자주 추천됩니다. 많은 계발을 얻을 것입니다. 고전으로는 다익스트라의 『A Discipline of Programming』과 그라이스(Gries)의 『The Science of Programming』이 있습니다. 특히 전자를 추천합니다. 프로그래밍에 대한 관을 뒤흔들어 놓을 것입니다. 알고리즘과 패러다임 알고리즘을 공부하면 큰 줄기들을 알아야 합니다. 개별 테크닉도 중요하지만 '패러다임'이라고 할만한 것들을 알아야 합니다. 이것에 대해서는 튜링상을 수상한 로버트 플로이드(Robert Floyd)의 튜링상 수상 강연(The Paradigms of Programming, 1978)을 추천합니다. 패러다임을 알아야 알고리즘을 상황에 맞게 마음대로 변통할 수 있습니다. 그리고 자신만의 분류법을 만들어야 합니다. 구체적인 문제들을 케이스 바이 케이스로 여럿 접하는 동안 그냥 지나쳐 버리면 개별자는 영원히 개별자로 남을 뿐입니다. 비슷한 문제들을 서로 묶어서 일반화해야 합니다. 이런 패러다임을 발견하려면 '다시 하기'가 아주 좋습니다. 다른 것들과 마찬가지로, 이 다시 하기는 알고리즘에서만이 아니고 모든 공부에 적용할 수 있습니다. 같은 것을 다시 해보는 것에서 우리는 얼마나 많은 것을 배울 수 있을까요. 대단히 많습니다. 왜 동일한 문제를 여러 번 풀고, 왜 같은 내용의 세미나에 또 다시 참석하고, 같은 프로그램을 거듭 작성할까요? 훨씬 더 많이 배울 수 있기 때문입니다. 화술 교육에서는 같은 주제에 대해 한 번 말해본 연사와 두 번 말해본 연사는 천지 차이가 있다고 말합니다. 같은 일에 대해 두 번의 기회가 주어지면 두 번째에는 첫 번째보다 잘 할 기회가 있습니다. 게다가 첫 번째 경험했던 것을 '터널을 벗어나서' 다소 객관적으로 볼 수 있게 됩니다. 왜 자신이 저번에 이걸 잘 못 했고, 저걸 잘 했는지 알게 되고, 어떻게 하면 그걸 더 잘할 수 있을는지 깨닫게 됩니다. 저는 똑같은 문제를 여러 번 풀더라도 매번 조금씩 다른 해답을 얻습니다. 그러면서 정말 엄청나게 많은 것을 배웁니다. '비슷한 문제'를 모두 풀 능력이 생깁니다. 제가 개인적으로 존경하는 전산학자 로버트 플로이드(Robert W. Floyd)는 1978년도 튜링상 강연에서 다음과 같은 말을 합니다. 제가 어려운 알고리즘을 디자인하는 경험을 생각해 볼 때, 제 능력을 넓히는 데 가장 도움이 되는 특정한 테크닉이 있습니다. 어려운 문제를 푼 후에, 저는 그것을 처음부터 완전히 새로 풉니다. 좀 전에 얻은 해법의 통찰(insight)만을 유지하면서 말이죠. 해법이 제가 희망하는 만큼 명료하고 직접적인 것이 될 때까지 반복합니다. 그런 다음, 비슷한 문제들을 공략할 어떤 일반적인 룰을 찾습니다. 아까 주어진 문제를 아예 처음부터 최고로 효율적인 방향에서 접근하도록 이끌어줬을 그런 룰을 찾는 거죠. 많은 경우에 그런 룰은 불변의 가치가 있습니다. … 포트란의 룰은 몇 시간 내에 배울 수 있습니다. 하지만 관련 패러다임은 훨씬 더 많은 시간이 걸립니다. 배우거나(learn) 배운 것을 잊거나(unlearn) 하는 데 모두. 수학자와 프로그래머를 포함한 모든 문제 해결자들의 고전이 된 죠지 폴리야(George Polya)의 『How to Solve it』에는 이런 말이 있습니다: 심지어는 꽤나 훌륭한 학생들도, 문제의 해법을 얻고 논증을 깨끗하게 적은 다음에는 책을 덮어버리고 뭔가 다른 것을 찾는다. 그렇게 하는 동안 그들은 그 노력의 중요하고도 교육적인 측면을 잃어버리게 된다. … 훌륭한 선생은 어떠한 문제이건 간에 완전히 바닥이 드러나는 경우는 없다는 관점을 스스로 이해하고 또 학생들에게 명심시켜야 한다. 저는 ACM의 ICPC 문제 중에 어떤 문제를 이제까지 열 번도 넘게 풀었습니다. 대부분 짝 프로그래밍이나 세미나를 통해 프로그래밍 시연을 했던 것인데, 제 세미나에 여러 번 참석한 분이 농담조로 웃으며 물었습니다. "신기해요. 창준 씨는 그 문제를 풀 때마다 다른 프로그램을 짜는 것 같아요. 설마 준비를 안 해 와서 그냥 내키는 대로 하는 건 아니죠?" 저는 카오스 시스템과 비슷하게 초기치 민감도가 프로그래밍에도 작용하는 것 같다고 대답했습니다. 저 스스로 다른 해법을 시도하고 싶은 마음이 있으면 출발이 조금 다르고, 또 거기서 나오는 진행 방향도 다르게 됩니다. 그런데 중요한 것은 이렇게 같은 문제를 매번 다르게 풀면서 배우는 것이 엄청나게 많다는 점입니다. 저는 매번, 전보다 개선할 것을 찾아내게 되고, 또 새로운 것을 배웁니다. 마치 마르지 않는 샘물처럼 계속 생각할 거리를 준다는 점이 참 놀랍습니다. 알고리즘 개론 교재로는 CLR(Introduction to Algorithms, Thomas H. Cormen, Charles E. Leiserson, and Ronald L. Rivest)을 추천합니다. 이와 함께 혹은 이 책을 읽기 전에 존 벤틀리(Jon Bentley)의 『Programming Pearls』도 강력 추천합니다. 세계적인 짱짱한 프로그래머와 전산학자들이 함께 꼽은 위대한 책 목록에서 몇 손가락 안에 드는 책입니다. 아직 이 책을 본 적이 없는 사람은 축하합니다. 아마 몇 주간은 감동 속에 하루하루를 보내게 될 겁니다. 리팩토링 학습에서의 문제 먼저, 본지 2001년 11월호에 제가 썼던 마틴 파울러의 책을 추천하는 글을 인용하겠습니다. OOP를 하건 안 하건 프로그래밍이란 업을 하는 사람이라면 이 책은 자신의 공력을 서너 단계 레벨업시켜줄 수 있다. 자질구레한 술기를 익히는 것이 아니고 기감과 내공을 증강하는 것이다. 혹자는 DP 이전에 RF를 봐야 한다고도 한다. 이 말이 어느 정도 일리가 있는 것이, 효과적인 학습은 문제의식이 선행해야 하기 때문이다. DP는 거시적 차원에서 해결안을 모아놓은 것이다. RF를 보고 나쁜 냄새(Bad Smell)를 맡을 수 있는 후각을 발달시켜야 한다. RF의 목록을 모두 외우는 것은 큰 의미가 없다. 그것보다 냄새나는 코드를 느낄 수 있는 감수성을 키우는 것이 더 중요하다. 필자는 일주일에 한 가지씩 나쁜 냄새를 정해놓고 그 기간 동안에는 자신이 접하는 모든 코드에서 그 냄새만이라도 확실히 맡도록 집중하는 방법을 권한다. 일명 일취집중후각법. 패턴 개념을 만든 건축가 크리스토퍼 알렉산더나 GoF의 랄프 존슨은 좋은 디자인이란 나쁜 것이 없는 상태라고 한다. 무색 무미 무취의 무위(無爲)적 자연(自然) 코드가 되는 그 날을 위해 오늘도 우리는 리팩토링이라는 유위(有爲)를 익힌다. 주변에서 리팩토링을 잘못 공부하는 경우를 종종 접합니다. 어떤 의미에서 잘못 공부한다고 할까요? '실체화'가 문제입니다. 리팩토링은 도구이고 방편일 뿐인데, 그것에 매달리는 것은 달은 보지 않고 손을 보는 것과 같습니다. 저는 리팩토링 책이 또 하나의 (이미 그 병폐가 많이 드러난) GoF 책이 되는 현상이 매우 걱정됩니다. 리팩토링 공부 사람들이 일반적으로 생각하는 바와는 달리 리팩토링 학습에 있어 어떤 리팩토링이 있는지, 구체적으로 무엇인지 등의 리팩토링 목록에 대한 지식과 각각에 대한 메카닉스(Mechanics: 해당 리팩토링을 해나가는 구체적 단계)는 오히려 덜 중요할 수 있습니다. 더 기본적이고 유용한 것은 코드 냄새(Code Smell)와 짧은 테스트-코드 싸이클입니다. 이것만 제대로 되면 리팩토링 책의 모든 리팩토링을 스스로 구성해낼 수 있으며, 다른 종류의 리팩토링까지 직접 발견해낼 수 있습니다. 그 책에서는 테스트의 중요성이 충분히 강조되지 않았습니다. 하지만 테스트 코드 없는 리팩토링은 안전벨트 없는 자동차 경주와 같습니다. 그리고 테스트 코드가 리팩토링의 방향을 결정하기도 합니다. 양자는 음과 양처럼 서로 엮여 있습니다. 이런 의미에서 리팩토링은 TDD(Test Driven Development)와 함께 수련하는 것이 좋습니다. 훨씬 더 빨리, 훨씬 더 많은 것을 배울 수 있을 겁니다. 리팩토링을 공부할 때는 우선 코드 냄새의 종류를 알고, 왜 그것이 나쁜 냄새가 될 수 있는지 이해하고(그게 불가하다면 리팩토링 공부를 미뤄야 합니다) 거기에 동의할 수 있어야 합니다. 그런 다음, 대충 어떤 종류의 리팩토링이 가능한지 죽 훑어봅니다. 그 중 몇 개는 메카닉스를 따라가면서 실험해 봅니다. 이제는 책을 덮습니다. 그리고 실제 코드를 접하고, 만약 거기에서 냄새를 맡는다면 이 냄새를 없애기 위해 어떻게 해야 할지 스스로 고민합니다. 리팩토링 책의 목록은 일단 무시하십시오. 그 냄새를 없애는 것이 목표이지, 어떤 리팩토링을 여기에 '써먹는 것'이 목표가 되어선 안 됩니다. 이 때, 반드시 테스트 코드가 있어야 합니다. 그래야 '좋은' 리팩토링을 할 수 있습니다. 책을 떠나 있으면서도 책에서 떠나지 않는 방법입니다. 리팩토링을 하기 전에 초록색 불(테스트가 모두 통과)이 들어온 시점에서 코드를 일부 고치면 빨간 불(테스트가 하나라도 실패)로 바뀔 겁니다. 이게 다시 초록색 불이 될 때까지 최소한도의 시간이 걸리도록 하십시오. 현 초록색에서 다음 초록색까지 최소한의 시간을 소비하도록 하면서 코드와 테스팅을 오가게 되면 자기도 모르는 사이에 훌륭한 리팩토링이 자발공으로 터져 나옵니다. 여기서 목적지는 우선은 OAOO(Once And Only Once: 모든 것은 오로지 한 번만 말해야 한다)를 지키는 쪽으로 합니다. 그러면 OAOO와 짧은 테스트-코드 싸이클을 지키는 사이 어느새 탁월한 디자인이 튀어나옵니다. 참고로 저는 '모래시계 프로그래밍'이란 걸 가끔 합니다. 모래시계나 알람 프로그램으로 테스트-코드 사이클의 시간을 재는 것입니다. 그래서 가급적이면 한 사이클이 3분 이내(대부분의 모래시계는 단위가 3분입니다)에 끝나도록 노력합니다. 여기서 성공을 하건 실패를 하건 많은 걸 얻습니다. 리팩토링 수련법 제가 고안, 사용한 몇 가지 리팩토링 수련법을 알려드립니다. ①일취집중후각법: 앞에 소개한 본지 2001년 11월호에서 인용된 글 참조 ②주석 최소화: 주석을 최소화하되 코드의 가독성이 떨어지지 않도록(혹은 오히려 올라가도록) 노력합니다. 이렇게 하면 자동으로 리팩토링이 이뤄지는 경우가 많습니다. ③OAOO 따르기: OAOO 법칙을 가능하면 최대한, 엄격하게 따르려고 합니다. 역시 자동으로 좋은 리팩토링이 이뤄집니다. 여기서 디자인패턴이 창발하기도 합니다. GoF 책을 한번도 보지 못한 사람이 디자인패턴을 자유자재로 부리는 경우를 보게 됩니다. ④디미터 법칙(Law of Demeter) 따르기: 디미터 법칙을 가능하면 지키려고 합니다. 어떤 리팩토링이 저절로 이뤄지거나 혹은 필요 없어지는가요? ⑤짝(Pair) 리팩토링: 함께 리팩토링합니다. 혼자 하는 것보다 더 빨리, 더 많은 걸 배우게 됩니다. 특히, 각자 작성했던 코드를 함께 리팩토링하고, 제3자의 코드를 함께 리팩토링해 봅니다. 사람이 많다면 다른 짝이 리팩토링한 것과 서로 비교하고 토론합니다. ⑥'무엇'과 '어떻게'를 분리: 어떻게에서 무엇을 분리해 내도록 합니다. 어떤 리팩토링이 창발합니까? 여기서 번, 짝 리팩토링은 아주 효과적인 방법입니다. 저는 이것을 협동적 학습(Collaborative Learning)이라고 부릅니다. 상대가 나보다 더 많이 아는 경우만이 아니고, 서로 아는 것이 비슷해도 많은 양의 학습이 발생합니다. 특히, 전문가와 함께 짝 프로그래밍을 하면 무서울 만큼 빠른 학습을 경험할 수 있습니다. 저와 짝 프로그래밍을 한 사람이 학습하는 속도에서 경이감을 느낀 적이 한두 번이 아닙니다. 문화는 사회적으로 학습되는 것입니다. 우리가 지식이라고 하는 것의 상당 부분은 문화처럼 암묵적인 지식(Tacit Knowledge)입니다. 전문가가 문제가 생겼을 때 어떻게 사고하고, 어떤 과정을 거쳐 접근하며, 어떻게 디버깅하고, 키보드를 어떤 식으로 누르는지, 사고 도구로 무엇을 사용하는지, 일 계획과 관리를 어떻게 하는지, 동료와 어떻게 대화하는지 등은 성문화되어 있지 않습니다. 그러나 이런 것들은 아주 중요합니다. 프로페셔널의 하루 일과의 대부분을 이루고 있기 때문입니다. 이런 것들은 전문가 바로 옆에서 조금씩 일을 도와주면서 배워야 합니다. 도제 살이(Apprenticeship)입니다. 진정한 전문가는 모든 동작이 우아합니다. 마치 춤을 추는 것 같습니다. 이 모습을 바로 곁에서 지켜보게 되면, 주니어는 한마디로 엄청난 충격을 받습니다. 그리고 스펀지처럼 빨아들이게 됩니다. 도대체 이 경험을 책이나 공장화한 학교가 어떻게 대신하겠습니까. 이와 관련해서는 레이브와 웽거(Jean Lave, Etienne Wenger)의 『Situated Learning : Legitimate Peripheral Participation』을 강력 추천합니다. 이 글을 보는 모든 교육 종사자들이 꼭 읽어봤으면 합니다. 이 협동적 학습은 두 사람만이 아니고 그룹 단위로도 가능합니다. 스터디에 이용하면 재미와 유익함 일석이조를 얻습니다. 이 외에, 특히(어쩌면 가장) 중요한 것은 일취집중후각법 등을 이용해 자신의 코드 후각의 민감도를 높이는 것입니다. 코드 후각의 메타포 말고도 유사한 메타포가 몇 가지 더 있습니다. 켄트 벡은 코드의 소리를 들으라고 하고, 저는 코드를 향해 대화하라고 합니다. 코드의 소리를 듣는 것은 코드가 원하는 것에 귀를 기울이는 것을 말합니다. 코드는 단순해지려는 욕망이 있습니다. 그걸 이뤄주는 것이 프로그래머입니다. 그리고 짝 프로그래밍을 할 때 두 사람의 대화를 코드에 남기도록 합니다. 주석이 아닙니다. 마소에 실린 글입니다.. - 김창준 (마이크로소프트웨어) ============================================================================= 프로그래머라는 직업. yskim0691(김용선) [2003-12-09]일 컨텐츠 보기 다른 컨텐츠 보기 : 1 52살, 내가 프로그래머로 사는 얘기 (분류:프로그래밍) 2003-12-09 오후 2:22:26 1. FACOM 230-15 1970년대초 처음 내가 컴퓨터 프로그램을 광운전자계산소 부설학원에서 배울 때 구경하면서 배운 컴퓨터이다. 당시 광운대학교 전산실에 설치된 이 컴퓨터는 우리네 학원 수강생에게는 구경만 하는 존재였다. 메인 메모리가 16K 인 것으로 기억하는데 우리는 CODEING SHEET에 프로그램을 써주기만 하면 키펀쳐가 80컬럼 카드페이퍼에 천공을 해서 카드리더기로 읽힌다. 실행결과는 LINE 플린터로 나오는데 프로그램 오자라도 나오면 ERROR LIST만 한보따리 받고 한주일을 기다려 다시 실행을 할 수가 있었다. 키보드도 못만져보고 프린터, 모니터는 구경만 했다. 메모리는 CORE MATRICS방식이어서 커다란 석쇠 같은 망에 쪼그맣게 끼워진CORE(자석 링)를 볼 수 있었다. 그래도 한국땅에는 컴퓨터란게 10여대밖에 없던 시절이었으니까 구경한번 해본 것으로도 자랑거리삼아 떠들고 다녔으니 지금 생각하면 우습기만 하다. 아마 지금쯤 광운대학교 창고에 이 고철이 있을지 모른다. 1985년경 세미나로 학교를 방문했을 때 만해도 전산과 교수의 말이 창고에 먼지를 쓰고 있을 거라고 했는데... 2. 내가 프로그래머가 된 동기 가난을 핑계로 대학을 포기한 내게 하는 일이라고 교회 일밖에 없어 교회 청년부와 청년연합회일을 열심히했고 한편 대한결핵협회의 씰크럽일을 하느라고 어지간히 분주했는데 군필만 받아주는 세상이어서 취직도 못하고 있었다. 그때 한 목사님의 주선과 한 선배님의 배려로 컴퓨터 공부를 하도록 돈을 마련할 수가 있어 시작한 것이 지금까지 전산인으로 사는 게 된 것이다. 컴퓨터학원을 다니던중 1년간 군복무를 해야 했고 1975년 전산직 취직을 하려했지만 워낙 자리가 적고 특수직종이다 보니 우리처럼 공부한사람이 프로그램머가 된다는 것은 쉽지가 않음을 깨닫고 나중 언젠가는 반드시 써먹을 기술이라 여겨 대기업 생산직부터 직장생활을 시작했으며 10년 만에 기어이 프로그래머가 되었다. 3. SHARP 프로그래머블 계산기 1983년 회사의 품질관리업무 담당 시절에 매일 통계계산하고 그래프그리는 일이 다일 때 나는 컴퓨터를 생각했다. 그래서 구입한게 당시에 약 70만원짜리 일제 SHARP 계산기 인데 작기는 지금 노트북 만한 것이 키보트 다있고 컬러 펜사용하는 플로터 프린터에 카세트테이프 리더까지 있어서 BASIC프로그램만 익히면 못할 것이 없는 기가 막힌 기계였다. 나는 BASIC이란 언어를 처음 배우면서 이렇게 쉬운 프로그램도 있구나 하면서 밤을 풀풀 새웠다. 서비스로 제공된 프로그램 SOURCE를 분석하면서 회사 QC ROOM에서 사용할 모든 프로그램을 만들었다. 출근해서 하루 종일 프로그램하다가 사무실이 조용해지면 깨달으면 모든 직원들이 퇴근한 것이었고 배가 고프고 추워지면 밤을 새웠고 동이 트는 것이었다. 누가 시키지도 않았고 누가 감시하지도 않고 누가 성과를 따지지도 않는데 나는 70만원짜리 컴퓨터를 구입해준 회사가 고맙고 프로그램하는 게 즐거웠다. 근 1년을 씨름하고 나니까 품질관리업무는 웬만큼 전산화가 이루어 져서 일부 시험기계는 컴퓨터와 인터페이스하는 정도까지 되었다. 회사는 이 모든성과에 보답해서 Z-80 8BIT 프로세서의 마이크로 컴퓨터를 사주었고 나는 내친김에 급여관리까지 손을 대기 시작했다. 4. Z-80 8 BIT 컴퓨터 Z-80 8BIT 이 컴퓨터는 미국서 부품을 수입해서 한글만 PORTING한 제품으로 M.MEMORY가 64KB 이고 128KB 5.25"플로피 디스크드라이브에 40MB 하드 디스크까지 있어서 당시로서는 고가품이었다. 이 기계는 브레인컴퓨터라는 회사에서 구입했고 그 회사의 교육을 통해 본격적인 DATA BASE의 기술을 익히게 되었다. 지금생각하면 속도가 얼마나 느렸든지 1,800여명 직원 급여를 계산하려면 프로세스만 20분정도 걸렸고 프린트를 하려면 도트프린터(당시 고려시스템제품으로 80CPS정도)로 급여 명세서만 약 80분에 봉투를 찍으려면 90분정도 걸렸다. 그런데다 프로그램을 효율적으로 만들지 못해서 급여 명세서 까지 인쇄해서 하나하나 따져봐야 ERROR를 찾을 수가 있는데 명세서 인쇄하다 틀린 것이 나오면 자료 수정하고 처음부터 다시 해야 했으니 한심하기 짝이 없는 일이 다반사였다. 한번은 낮동안 입력하는 직원들시켜서 하루종일 급여 자료를 입력하게 하고 다들 퇴근한 밤시간에 계산 프로그램을 실행하고 명세서를 인쇄하는 중이었다. 이날도 급여계산은 한번에 되질않고 몇 번을 수정 재작업하는 바람에 시간은 새벽이 다되었고 아침이 되면 퇴근을 하는 밤근무자들부터 월급을 주어야 했었다. 나는 회사에서 특별히 제작해준 커다란 테이블위에 컴퓨터 본체, 모니터, 키보드, 프린터를 나란히 놓고 쓰는데 1시간이 넘게 걸리는 프린팅에서 종이라도 걸릴까봐 지켜보고 있으려니 프린터의 박박거리는 소리에 슬글슬금 졸음이 왔다. 나는 엎어져서 눈을 붙여보다가 결국 테이블 위로 올라가서 벌러덩 누워잠이 들었는데.... 한순간 나는 잠이 깨었다. 그건 박박거리면 급여명세서를 인쇄하던 프린터가 갑자기 조용해진 때문이었다. 아차! 잠든 내 팔꿈치가 컴퓨터의 RESET스위치를 눌러 버린 것이었다. 급여프로그램이 얼마나 멍청한 것인지 인쇄하다 중단하면 처음부터 다시인쇄해야 소계 합계 총계가 맞도록 인쇄되는 것이어서 할 수 없이 다시 작업을 하느라고 고생을 했다. 그시절 함께고생하던 직원 안덕민씨가 그립다. 5. HP/3000 S42와 전산실 회사는 1985년 HP/3000 미니컴퓨터를 들여놓고 전산실을 꾸미면서 전사적인 전산화를 추진하게 되었고 나는 1987년 본사 전산실에 합류하여 전산이 전업이 되었다. 인사.급여,회계.영업.수출.재고등 3개 지역의 공장과 본사의 온라인 시스템을 운영하는 방대한 시스템을 구축하면서 나는 COBOL-II를 사용하였고 정작 MIS의 경험을 올바로 할 수 있는 계기가 되었다. 결국 전산실 책임자가 되었지만 전산실 7,8명의 5년여 각고로 상당부분 전산화의 실적을 거둔데 비해 회사의 지속적인 투자부족이 더 나은 시스템을 발전시키지 못하고서 나는 중소기업으로 이직을 하고 말았다. 6. CLIPPER (주)전방에서 HP/3000의 LOAD가 심해 지면서 나는 PC에 의한 분산처리 방편으로 PC LAN을 구축하고 단말프로그램으로 RM-COBOL과 CLIPPER를 사용하여서 좋은 성과을 얻었고 계기로 PC에 의한 인사.급여.회계.교회행정등 많은 시스템을 개발하게 되었다. 특히 판매재고관리 펙키지판매업체에서 1년동안 CLIPPER개발일을 했던 경험은 프로그램의 배포와 보안에 대한 좋은 경험이 되었고 중소기업이 무엇이 중요하고 무엇이 필요한지를 이해하는 귀중한 경험으로 남았다. 지금도 개인적으로 CLIPPER어플리케이션 프로그램을 사용하고 있으며 개발도 그래픽 라이브러리를 사용하여 하고 있다.(참고:-아직도 DOS프로그램은 볼륨의 효율성과 실행 속도 면에서 윈도우와는 상대적인 잇점이 남아있다.) 7. Windows 그래도 이젠 윈도우다. 그리고 닷넷이다. 작년(2001년)부터 비쥬얼베이직으로 시작한 윈도우 도전은 아예 MS의 닷넷으로 빠지게 하였다. 이젠 회사의 어플이케이션 프로그램을 웹사이트와 연동하게 ASP.NET으로 전환하는 작업에 착수하였다. 현재 홈페이지는 ASP.NET으로 전환하였고 회계프로그램과 무역관련업무프로그램을 웹환경으로 C#을 사용하여 다시 개발하고 있고, 패션 브랜드 사이트개발을 수주하여 현재 개발중이다. 배운대로 잘 되지는 않았지만 책과 씨름하고 닷넷싸이트를 뒤지면서 하나씩 하나씩 풀어가는 재미에 날새는 줄도 모르고 지나간다. http://www.yongsun.pe.kr ========================================================================= 청년 실업이 증가하고 직장 구하기 어렵다는 보도를 자주 접하게 되는 요즘, 그래도 한쪽에서는 여전히 쓸만한 사람을 찾기 힘들다는 푸념을 듣게 된다. 종종 사람을 찾는다는 연락을 받곤 하는데, 이런 경우 대략 5년차쯤 되는 경력에 팀원이 5명 정도인 조그만 개발 팀을 이끌 사람을 찾는 것이 대부분이다. 4~5년차 엔지니어라면 일에 대한 열정이 있고 자신의 분야에 대해 자신감도 있을 한창 나이다. 게다가 미혼일 경우 밤늦게까지 일하거나 날밤을 새는 것도 어렵지 않다. 능력, 열정, 시간의 삼박자가 딱 맞는 시기라고도 하겠다. 기술이 워낙 빨리 변하는 IT 분야에서는 해당 분야 5년 정도의 경력이라면, 개발 팀장으로서 기술적인 부분을 이끌면서 프로젝트를 수행할 수 있다고 생각한다. 하지만 기술적인 면 이외의 부분에서는 적합하다고 할 수 있을까? 개발팀을 이끌기 위한 자질로는 해당 팀에 필요한 기술적 이해 이외에도 팀원에 대한 관리, 프로젝트 추진 능력, 중요 사안에 대한 의사결정 능력, 다른 팀과의 커뮤니케이션 능력 등이 필요하다. 이러한 능력은 천성적으로 모두 갖추고 태어난다기보다는 경험과 교육에 의해서 습득된다고 할 수 있을 것이다. 바쁜 개발 일정탓에 틈틈이 관리자나 팀장 교육을 시켜주는 회사는 그리 많지 않다. 대개는 교육이나 세미나 참가는 엄두조차 내기 힘든 일정을 보내고 있을 것이라 생각한다. 이런 상황이라면 준비된 팀장이 아닌 팀장의 자질을 가진 사람을 발굴하는 방법 밖에는 없다. 개발 팀장이라고 해서 반드시 기술적으로 뛰어난 사람이어야 할 필요는 없다. 팀원 개개인의 특징과 개발에 대한 이해가 높아서 팀원들에게 어떤 일을 시켜야할지 잘 아는 사람이 더 좋다. 프로그래밍을 빠른 속도로 잘한다고 해서 팀장이 돼야 하는 것도 아니고, 경력이 제일 많다고 해서 팀장을 해야 하는 것도 아니다. 프로젝트를 시작하기 위해 팀장을 맡길 사람을 찾을 경우, 팀장 경력이 되는 사람들은 이미 다른 팀의 팀장을 하고 있거나 중요 역할을 맡고 있어 데려올 수 없는 상황이어서 결국 회사 외부에서 데려오거나 이미 꾸려진 팀원중에서 팀장을 정해야 하는 상황이 된다. 재미있는 사실은 엔지니어들은 팀장이 되는 것을 별로 좋아하지 않는다는 것이다. 개발팀 팀장을 맡는 것을 매니저로서 레벨업되는 기회라 생각하기보다는 개발 업무외에 팀 관리업무와 개발에 대한 책임만 주어진다고 생각하기 때문이다. 무엇보다도 프로젝트 일정과 팀원을 관리하는 매니저로서의 능력이 엔니지어로 있을 때에 비해 훨씬 많이 요구되고, 개발보다는 관리와 팀원 간의 의사소통에 치중해야 하기 때문에 개발자로서의 기술 습득이나 개발에 집중할 시간이 줄어들거나 아예 할 수 없기 때문이다. 팀장으로서 뛰어난 자질을 가지고 있는데도 불구하고 개발에 집중하고 싶다는 이유로 그냥 개발자로 남겠다는 의사를 밝히는 엔지니어도 있다. 관리자로서의 경력보다는 개발자로서의 경력을 계속 가져가겠다는 것이다. 팀장이 된다고 해서 연봉이 크게 상승되는 것도 아니고(추가 수당이 아예 없는 경우도 있다), 회사에 따라서는 팀장들에게 아무런 권한없이 책임만 주어지는 경우도 있다. 별도의 팀장 교육을 거치는 것도 아니고 갑자기 팀원에서 팀장으로 만들어 놓고는 팀장으로서 행동하기만을 바랄 뿐이다. 갑작스레 팀장이 된 개발자가 팀장으로서의 역할을 잘 할리 만무하다. 문서 작업도 쉽지 않고 팀원들 관리나 일정관리도 제대로 되지 않는다. 팀장을 뽑은 높으신 분들은 반복되는 문제들을 처음에는 그냥 눈감아주지만 시간이 지날수록 눈초리가 곱지 않다. 결국 못미더운지 그나마 있던 권한도 도로 가져가 버리고 만다. 팀장으로서의 역할도 제대로 안되고 개발일정은 지연되고, 책임감 때문에 밤늦게까지 개발에 매달리다 결국 몸과 마음이 망가지는 상황으로 치닫게 된다. 좋은 팀장 밑에서 제대로 일을 배웠더라면 조금 나을 수 있었겠지만 크게 차이나지는 않았을 것이다. 능력없는 사람을 팀장으로 앉히지 말라는 것을 말하고자 한 것은 아니다. 처음 팀장을 하는 사람은 반드시 겪어야 할 과정이다. 하지만 사자가 어린 새끼를 절벽으로 떨어뜨리는 것과는 전혀 다르다. 책임을 주면 상응하는 권한도 주고, 실패에 대해서도 두려워하지 않게 해야 한다. 나이든 개발자가 계속 개발에 매진할 수 있는 미국과 달리 한국에서는 개발자를 관리하는 관리자층이 얇기 때문에 30대 중반만 넘어도 매니저로서 일해야만 한다. 개발에서 완전히 손을 떼지 않더라도 관리 업무가 상당히 늘어나기 때문에 경력이 쌓일수록 관리 능력이 요구된다. 개발자도 이러한 상황을 이해하고 좀더 긴 안목으로 자신의 위치를 가늠했으면 한다. 개발 업무 자체에만 집착하기보다는 팀원과의 의사소통, 개발팀과 다른 팀과의 관계 등에 눈을 돌려보는 것도 개발에 도움이 된다는 것을 인식했으면 한다. 그러한 인식의 전환이 매니저로서의 능력 개발에 밑거름이 된다고 믿는다. @ 출처 : zdnet 코리아 =========================================================================== 리사아빠입니다. 프로그램이란것은 컴퓨터가 알아 먹는 말로 일을 하게끔 하는 것에 불과 하다는 생각이 듭니다. 그러기 위해서 알고리즘이나 자료구조나 언어라든지 한는 부수적인 지식들이 필요한 것이구요. 저는 인문계열 출신인데도 요즈음에는 프로그램을 할때 인문계열에서 공부를 한 것이 더 도움을 줄때가 많이 있습니다. 거의가 응용이지만 프로그램 언어를 공부할때도 알고리즘도 인문교양지식이 많은 도움을 줍니다. 대부분 사람들이 하면 할 수록 프로그램이 어렵다고 하는 것은 자신의 기본지식을 응용하는데에 한계점에 다달해서뚜렸한 실마리를 ?지 못해서 그렇다고 생각을 합니다. 저의 경우 인간의 언어에 대해서는 어느 정도 자신이 있는데 이 언어를 가지고 설명을 해 보겠습니다. 저는 스페인어 프랑스어 둑일어 그리고 중국어는 보면 대충 이해를 하고 영어와 일본어는 모국어 가깝게 구사를 하는 편입니다. 그런데 이렇게 할 수 있었던 배경이 일본어를 모국어처럼 사용을 하게 되면서 자연스럽게 다른 언어를 쉽게 쉽득하는 습관이나 사고가 몸에 베어서 다른 언어를 쉽게 습득한 것에 불과 하다고 생각을 합니다. 그런데 일본어를 배울때 제가 가장 어렵게 느껴??던 것이 일본어가 아니라 모국어인 한국어가 어려웠던 사실입니다. 모든 언어의 기본이 되는 국어 실력이 없었던 것이지요. 한국에서는 고등학교밖에 나오지 못해서 언어라는 기본 개념도 없었던 것입니다. 그리고 언어라는 것은 한 언어의 단어를 많이 안다고 잘하는 것도 아니고 정치 경제 사회 문화등 각분야별로 어느 정도의 지식도 필요하기 때문에 단지 한국말이 모국어라고 해서 다들 한국말을 잘한다는 것도 아니라는 사실을 알게 되었지요. 그래서 제가 일본어를 배우는데 가장 먼저 착수한 것이 어떠한 언어라도 각분야의 지식이 필요하다는 생각에서 일본의 정치 경제 사회등 각분야의 책과 논문이나 사설등을 읽기 시작했습니다. 이해가 되지 않으면 그에 관련된 서적을 읽으면서 참고도 하였습니다. 그러면서 언어에는 각 단어마다 뚜렸한 개념이 라는 것이 있고 그 개념에는 학문일 경우에는 그 학설을 주장하는 학자가 각 용어에 대한 정의를 뚜렸하게 제시하고 있다는 것을 깨닫게 되고 사전을 보는 습관이 생기게 되었습니다. 이러한 언어를 정확하게 개념적인 측면에서 일반 생활과 밀접한 부분을 가장 잘 정리해놓은 것이 육법전서라는 것도 알게 되었지요. 한치의 불필요한 말도 없고 더 보탤 말도 없을 정도로 완벽하리 만큼 논리적이면서 정확한 언어로 구사되어 있음을 알았습니다. 그래서 대학에서는 법에 관한 과목과 신학 철학 심리학등 학문의 기본이 되는 과목을 많이 선택해서 들었습니다. 그리고 제일 외국어를 프랑스어를 선택하고 영어는 영어로 강의하는 과목만을 수강을 했습니다. 이러면서 어느 순간에 일본어나 영어로 습득된 지식이 한국어로 습득된 지식의 양을 초월하게 되었지요. 그러나 역으로 이러한 지식들로 인해 언어에 대한 뚜렸한 개념이 몸에 베어 한국어로 된 전문서적이나 소설을 대할때에 한층더 모국어인 한국어에 대한 이해력과 국어 실력이 늘었다는 것을 경험을 하게 되었습니다. 그리고 고등학교때에 미분과 적분 그리고 백터에 대한 개념과 왜 그러한 이론이 필요한것인가에 대해서 수학 선생님한테 물었다가 되지게 욕만 먹고 건방지다면서 가르쳐준 대로 하면 문제를 풀 수 있는데 말이 많다고 많은 친구들 앞에서 꾸지람을 당한 적이 있었습니다. 그 이후로 수학이라는 과목은 쳐다 보기도 싫었고 항상 꼴지에서 뱅뱅돌아 선생님한테 넌 가르쳐주는 것도 모르면서 말이 많다고 줄업할때까지 욕을 먹었던 기억이 있습니다. 한 마디로 교육의 폭행을 당한 것이죠. 그러나 대학에서 심리학이란 과목을 들었을때 거의가 확율과 수학의 이론에의해 가설을 입증하고 하나의 이론으로 정립되 가는 것을 보고 너무 어려워서 그 담당 교수에게 부탁을 해서 따로 필요한 수학 지도를 받았는데 너무나도 이론과 개념에 대해서 상세하게 가르쳐 주어서 2시간 만에 미분과 적분 확율 그리고 백터까지 정확하게 개념적으로 이해를 할 수 있었던 경험도 있습니다. 경제 경영 마케팅이란 과목도 거의 수학이었는데 심리학과 그 교수 덕분에 쉽게 점수를 딸 수 있었습니다. 위의 과목에서 제가 한국어로라도 수학적인 기본지식이 있었다면 따로 교수에게 부탁을 하지 않고도 수월하게 그 과목을 이해를 할 수 있었을 겁니다. 이러하듯이 언어란 것은 일반적인 사회생활이나 전문적인 분야에서도 관련지식이 따라 주어야 진정한 언어로서의 실력이 느는 것입니다. 영어나 일어를 대학에서 전공한다고 해서그 사람이 그 언어를 아주 잘 한다고 할 수 없는 것도 이러한 이유때문입니다. 한국에서 대학을 다녀 보지 못해서 모르지만 영어를 전공하면 문학을 하는 사람도 있을테고 영어의 문법을 학문적으로 하는 사람도 있을 겁니다. 그러나 이런 전공을 하는 사람들도 학문적으로 연구를 하기 위해서는 자신이 연구하는 분야에서 자신의 가설을 증명하기 위해서는 영어라고 하더라도 모든 학문에서처럼 그 검증 방법이 대부분이 같다는 것입니다. 예를 들어 자연 인류학에서 여기 저기에서 발굴되는 뼈와 유적들을 가지고 체계있게 정리를 하고 그것에서 얻어진 자료들을 바탕으로 이러이러했을 것이라는 것을 가설을 세우고 그것을 과학적으로 입증한 것이 학설입니다. 그리고 그 학설이 많은 학자들로부터 인정을 받고 의심의 여지가 없고 권위가 있으면 우리들은 역사책에서 그것을 줄쳐 가면서 외우고 입시에도 시험문제로 나오고 하는 것입니다. 자료를 정리하는 예를 하나 설명하자면 여러 유물들이 출토 되었을 때 그 자료들을 하나의 자료에 대해서 하나의 카드에다 기록을 합니다. 그리고 카드를 섞어서 자료들이 완전히 무의미하고 아무 관련성이 없는 상태로 합니다. 이것은 자신의 선입관이나 몸에 베어있는 지식에 영향을 받지 않게 하기 위해서입니다. 그리고 여러 사람들이 모여서 카드 한장 한장을 책상위에 같은 부류라고 생각되는 것을 직감적으로 같은 곳으로 모아 둡니다. 그러면 자료들이 정리가 되고 그자료들의 연관성이 보이고 다시 분류를 하고 하는 과정을 되풀이하다 보면 일관된 규칙들이 발견됩니다. 그리고 이 규칙들을 기본으로 재 정리하고 과학적인 방법으로 입증해 사람들이 알아 보게 언어로 설명을 하면 그것이 학설입니다. 학문이라고 어려운 것은 아닙니다. 이러한 기본적인 과학적인 입증방법으로 정리해서 글을 쓰면 그것이 학문이 되는 것이지요. 언어도 마찬가지로 하나의 언어를 아주 잘 구사할 수 있으면 언어의 공통적인 개념들이--과학적인 입증방법이 모든 학문에서 거의 동일 하듯이--비슷하기 때문에 다른 언어도 쉽게 익힐 수 있는 것입니다. 제 경험으로 6개월이면 하나의 언어를 어느정도 마스터할 수 있으리라는 생각을 합니다. 가끔 영어는 어떻게 공부하면 되요 라는 글을 대하는데 가장 좋은 방법은 그냥 소설책 하나 사다가 다 외워 버리면 됩니다. 그리고 그것을 바탕으로 다른 책들을 계속 읽어 나가다 보면 저절로 실력이 늡니다. 영어를 하기 위해서 공부하지 말고 필요한 지식을 영어로 습득하기 위해서 책을 보아야지 항상 줄쳐 가며 이놈 영어 배워야지 정복해야지 하다보면 죽을 때까지 영어만 공부하다가 끝입다. 회화를 하고 싶으면 어느정도 이러한 실력을 키우고 현지에 가서 더도 말고 6개월 정도만 살다 오면 귀가 트이고 왠만한 것은 다하게 됩니다. 이것은 언에에 대해서 저의 경험담을 쓴 것입니다. 그럼 프로그램의 경우는 어떠할까요? 프로그램을 하기 위해서는 적어도 하나의 컴퓨터 언어를 습득해야합니다. 많은 사람들이 컴퓨터 언어를 배우다가 프로그래머의 일을 마치거나 어느 정도 하다가 관리자가 되어 프로그래머의 길을 떠나는 사람들도 있습니다. 또는 중도하차하는 사람들도 많구요. 프로그램 언어도 인간의 언어와 마찬가지로 국어 하나만 잘하고 언어의 개념만 확실히 정립해 놓으면 새로운 다른 언어를 쉽게 배우고 새 문화에 대해서 바로 익숙해 질 수 있는 것처럼 새 언어와 기술이 나오더라도 별 큰 의미는 없는 것입니다. 0과1의 세계는 다름이 없기 때문입니다. 언어는 타인과 의사소통을 위한 수단이고 컴퓨터 언어는 컴퓨터가 알아 먹고 일을 하게끔하는 수단에 불과합니다. 만약 양자 컴퓨터가 실용화되어 0과1의 중간의 개념도 배워야 하는 시대가 온다면 지금까지 배워온 모든 것을 버리고 개념부터 다시 배워야 하겠지만요. 가끔 이 포럼란에 그러한 언어에 대한 글이 올 때마다 왜 그러한 언어에다가 목적을 두고 살아가야 하는 것인가에 대한 의문을 가지게 됩니다. 그것은 회사에서 채용을 할때 이러 이러한 언어가 할 수 있어야 하고 경험은 몇년이고 하는 채용 풍토나 기준으로 인해 학원이나 전문대등에서 언어 습득에 목적을 두는 교육을 받은 사람들이 많았기 때문이라고 제 나름대로 분석을 하고 있습니다. 그리고 2,3년에 모든 컴퓨터 이론을 가르친다는 것도 불가능하구요. 사실 하나의 소프트 엔지니어다운 엔지니어를 한명을 배출해 내려면 미국이나 일본의 커리쿨럼으로 7년이라는 과정이 필요합니다. 동경대의 한 교수가 소프트 공학 커리쿨럼에 대한 연구 논문이 책으로 나와서 한번 읽어본 기억이 있습니다. 이 논문에서는 경영과 일반 인문교양도 많이 포함되어 있고 실질적으로 인턴과정을 포함하면 10년이 필요하다고 주장합니다. 2년 3년으로 한가닥 한다는 것은 택도 없는 소리입니다. 저역시 프로그램은 오래하고 있지만 많이 부족하고 아직도 공부를 계속하고 있습니다. 저는 공부를 할때에 주로 일반 미국의 공과대학에서 커리큘럼 과목으로 지정되어 있는 것들을 10년 계획으로 조금씩 공부를 하고 있습니다. 지금은 컴파일 이론을 실질적인 프로그램 소스와 서적으로 공부하고 있습니다. 제가 머리가 나빠서 아마 2년 정도 걸리리라고 생각을 합니다. 자료구조나 이러한 것은 도서관학에 관한 서적을 주로 많이 봅니다. 현재 프로그래머로 일하는 대부분의 사람들이 회사에 다니면서 일을 하기 때문에 일하는데 바빠서 다른 공부를 할 기회도 없을 것이라는 생각을 합니다. 그리고 현재에 알고 있는 몇개의 언어 지식을 최대한 우려먹고 우려먹고 해서 더짜도 궁물도 제대로 안나오는 상황에 처한 분들도 많이 있을 겁니다. 응용이니 하는 것들은 상상도 할 수 없는 상황도 많을 거구요. 그러다 새로운 무슨 NET니 뭐니 하는 것이 나오면 저것도 해야지 밥줄 끊기지 않겠구나 하는 위기감에 처해 지거나 불안해 하고 힘들어서 더이상 프로그램일 못해 먹겠다 하고 생각하는 사람도 많이 있을 겁니다. 하나의 컴퓨터언어에 대해서 정확하게 프로그램소스를 이해하고 진정한 프로라고 말을 할 수 있을 정도의 실력이 되려면 PHP와 같은 스크립 언어라고 해도 제 생각으로는 주변 지식들을 포함하면 적어도 4년은 걸릴거라는 생각이 듭니다. 제가 머리가 나빠서 그렇게 걸리고 머리 좋은 천재는 1년 이내에도 해 내겠죠. 일본어의 경우는 제가 어느정도 실력을 가추었다고 생각을 한것이 항상 사용하면서도10년째가 되었을 때입니다. 영어도 그랬구요. 그래도 부족하다고 생각이 들어 지금도 시간이 있으면 서점에 가서 책을 사다가 분야를 가리지 않고 읽고 있습니다. 다른 언어를 6개월만에 어느정도 할 수 있다고 말한 것은 이러한 한 언어의 기본이 있기 때문에 필요성이 느껴진다면 6개월 정도 집중적으로 한다면 어느 정도는 할 수 있다고 말한 것에 불과합니다. 그리고 어느 정도 프로그래머로 일해서 팀장이나 해서 프로그램일을 때려 치우고 싶다는 생각을 가진 사람도 많으리라고 생각을 합니다. 그러면 컴퓨터 소프트 공학의 입문도 마치지 않은 영원한 초보로 남을 것이고 그러한 초보 밑에서 일하는 사람 역시 똑같은 초보의 길로 유도를 하리라고 생각을 합니다. 요즈음 서울 대학이나 여러 대학의 전삭학과 연구실 사이트를 들락 거리고 있습니다. 그러면서 전산학 계열의 대학을 나온 다고하더라도 연구 분야의 내용이나 커리큘럼의 과목이나 수준을 보면 역시 대학을 나와도 소프트 엔지니어 차원에서는 아주 초보라는 생각이 많이 들게 됩니다. 그런 고급 인재들은 회사에 취직하면 대부분이 어느정도 하다 실력이 막 늘고 어느 정도 실력자가 되려고 할때 그들은 전부 관리직으로 가게 되고 또 다시 그들 밑에는 초보자들이 들끊는 회사로 전락을 하게 되는 것을 되풀이 하는 것이 아닌가하는 마음이 듭니다. 이러한 것은 일본의 미즈호 은행과 같은 참사를 낼 소재들을 만들어 가는 것이라고 생각을 합니다. 일본도 어느 프로그램 일을 하면 관리직으로 일을 하는 것은 마찬가지 입니다. 제가 일본에서 취업 활동을 하면 거의 대부분의 회사가 관리직으로 와달라고 합니다. 연봉은 800만엔 이상 주겠다고들 합니다. 저는 연봉이 그 반 값이라도 프로그래머로 일하고 싶다고 해도 그런 자리는 제가 만 35살이라는 이유로 프로그래머로서는 회사측에서 고용을 할 수 없다고 합니다. 저는 그러면서 일본도 이제는 맛이 갔구만, 이대로 10년 정도만 흐르면 일본의 시스템도 빵꾸가 나겠구만, 미즈호 은행사건이 있었으면서도 회사들이 아직도 정신을 차리지 못했구나 하는 생각으로 프리랜서로서의 길을 고집하고 있습니다. 프로그래머로 오래 남으려면...? 이 아니라 저는 오래 해야만 된다는 생각을 하는 사람입니다. 그렇지 않으면 언제까지나 한국은 미국 소프트의 최대 소비국으로 남을 것이고 매번 새로운 언어나 개발툴이 나올때마다 테스트 시장으로 전락을 하게 되리라고 생각을 합니다. 그리고 PHP는 훌륭한 언어입니다. 펄도 그렇구요. 다들 쓸모가 있기에 있는 언어이고 하나라도 잘 하면 다른 것들도 다 잘 하게 되고 어렵지 않습니다. 만약에 다른 언어가 필요하다면 구현하기 위한 필요한 부분만 하면 되는 것입니다. 많은 프로그래머들이 먼저 현시점에서 자신이 가장 자신이 있는 하나의 언어를 정말로 프로라고 자신할 만큼 해놓고서 다른 언어에 대해서도 이야기를 해주었으면 하는 바램입니다. PHP 2,3년 하고 게시판떼기 일주일만에 만들었다고 하는 것은 소프트 엔지니어 세계에서는 의미가 없는 일입니다. 게시판도 제대로 만들면 저는 3년은 걸리리라고 생각하고 있고 실제로 제가 하나 만들고 있는 게시판은 펄로 5년째 작업을 하고 있는 것도 있습니다. 처음 이곳에 와서 그러한 이야기들을 읽고 다들 대단하구나. 정말로 나라는 인간은 돌대가리구나 하는 생각도 | |