요새 들어서 비슷한 작업을 다시하는 일이 많이 생기고 있다.
플레이어야 원래 자주 하던 작업이었으니 그건 제외하고, 3월달에 슬롯머신 게임 제작했던 거 리뉴얼 되서 부분적으로 변경되는 거라던지,
월드컵 축구게임 G마켓에서 했던거 이번엔 틴링에서 거의 비슷하게 진행되는 걸로 현재 일을 하고 있는 상태고, 오늘도 월드컵 퀴즈 작업했던거 3차로 이미지들 변경되는 일이 들어왔다.
사실 같은 작업을 거의 이미지만 교체하는 작업은 별로 흥이 안 나긴 한다.
그래도 다시 내가 했던 작업을 열어보면서, 새로 깨달았던 구조적 결함이 있었던 거라면 클래스 구조를 새로 짜서 다 변경해버리기도 하고,
코드가 좀 거슬리면, 맘에 안드는 코드를 변경하고 깔끔하게 다시 고치고 있다.
그렇게 까지 할 필요는 솔직히 없지만, 내가 작업한 코드는 남들이 봤을 때 부끄러워지고 싶지 않아서,그리고 또 그렇게 변경하다보면 새롭게 깨닫는 것도 많은 것 같아서 그런식으로 작업을 하고 있다.
그리고 오늘 오전에 '프로그래머를 위한 '공부론'이라는 글에도 이런 내용이 나온 것 보고,
이렇게 다시하고 다시 제대로 변경해보고 하는 작업이 굉장히 좋은 거라는 것도 알게 되었다.
이런 패러다임을 발견하려면 '다시 하기'가 아주 좋습니다. 다른 것들과 마찬가지로, 이 다시 하기는 알고리즘에서만이 아니고 모든 공부에 적용할 수 있습니다. 같은 것을 다시 해보는 것에서 우리는 얼마나 많은 것을 배울 수 있을까요. 대단히 많습니다. 왜 동일한 문제를 여러 번 풀고, 왜 같은 내용의 세미나에 또 다시 참석하고, 같은 프로그램을 거듭 작성할까요? 훨씬 더 많이 배울 수 있기 때문입니다. 화술 교육에서는 같은 주제에 대해 한 번 말해본 연사와 두 번 말해본 연사는 천지 차이가 있다고 말합니다. 같은 일에 대해 두 번의 기회가 주어지면 두 번째에는 첫 번째보다 잘 할 기회가 있습니다. 게다가 첫 번째 경험했던 것을 '터널을 벗어나서' 다소 객관적으로 볼 수 있게 됩니다. 왜 자신이 저번에 이걸 잘 못 했고, 저걸 잘 했는지 알게 되고, 어떻게 하면 그걸 더 잘할 수 있을는지 깨닫게 됩니다. 저는 똑같은 문제를 여러 번 풀더라도 매번 조금씩 다른 해답을 얻습니다. 그러면서 정말 엄청나게 많은 것을 배웁니다. '비슷한 문제'를 모두 풀 능력이 생깁니다.
제가 개인적으로 존경하는 전산학자 로버트 플로이드(Robert W. Floyd)는 1978년도 튜링상 강연에서 다음과 같은 말을 합니다.
제가 어려운 알고리즘을 디자인하는 경험을 생각해 볼 때, 제 능력을 넓히는 데 가장 도움이 되는 특정한 테크닉이 있습니다. 어려운 문제를 푼 후에, 저는 그것을 처음부터 완전히 새로 풉니다. 좀 전에 얻은 해법의 통찰(insight)만을 유지하면서 말이죠. 해법이 제가 희망하는 만큼 명료하고 직접적인 것이 될 때까지 반복합니다. 그런 다음, 비슷한 문제들을 공략할 어떤 일반적인 룰을 찾습니다. 아까 주어진 문제를 아예 처음부터 최고로 효율적인 방향에서 접근하도록 이끌어줬을 그런 룰을 찾는 거죠. 많은 경우에 그런 룰은 불변의 가치가 있습니다. … 포트란의 룰은 몇 시간 내에 배울 수 있습니다. 하지만 관련 패러다임은 훨씬 더 많은 시간이 걸립니다. 배우거나(learn) 배운 것을 잊거나(unlearn) 하는 데 모두.
수학자와 프로그래머를 포함한 모든 문제 해결자들의 고전이 된 죠지 폴리야(George Polya)의 『How to Solve it』에는 이런 말이 있습니다:
심지어는 꽤나 훌륭한 학생들도, 문제의 해법을 얻고 논증을 깨끗하게 적은 다음에는 책을 덮어버리고 뭔가 다른 것을 찾는다. 그렇게 하는 동안 그들은 그 노력의 중요하고도 교육적인 측면을 잃어버리게 된다. … 훌륭한 선생은 어떠한 문제이건 간에 완전히 바닥이 드러나는 경우는 없다는 관점을 스스로 이해하고 또 학생들에게 명심시켜야 한다.
저는 ACM의 ICPC 문제 중에 어떤 문제를 이제까지 열 번도 넘게 풀었습니다. 대부분 짝 프로그래밍이나 세미나를 통해 프로그래밍 시연을 했던 것인데, 제 세미나에 여러 번 참석한 분이 농담조로 웃으며 물었습니다. "신기해요. 창준 씨는 그 문제를 풀 때마다 다른 프로그램을 짜는 것 같아요. 설마 준비를 안 해 와서 그냥 내키는 대로 하는 건 아니죠?" 저는 카오스 시스템과 비슷하게 초기치 민감도가 프로그래밍에도 작용하는 것 같다고 대답했습니다. 저 스스로 다른 해법을 시도하고 싶은 마음이 있으면 출발이 조금 다르고, 또 거기서 나오는 진행 방향도 다르게 됩니다. 그런데 중요한 것은 이렇게 같은 문제를 매번 다르게 풀면서 배우는 것이 엄청나게 많다는 점입니다. 저는 매번, 전보다 개선할 것을 찾아내게 되고, 또 새로운 것을 배웁니다. 마치 마르지 않는 샘물처럼 계속 생각할 거리를 준다는 점이 참 놀랍습니다.
어떤 작업을 하더라도 무엇인가 하나는 꼭 배울 수 있는 게 있고,그것을 얻어내는 것이 중요하다고 난 생각하고 있다.
아래에 보이는 프로그래머를 위한 공부론은 , 프로그래머가 어떤식으로 공부하면 좋은지, 무엇을 공부하면 좋은지에 대해 길고 자세하게 설명해주고 있다.
[펌]어떻게 공부할까? 프로그래머를 위한「공부론」
우리 프로그래머들은 항상 공부해야 합니다. 우리는 지식을 중요하게 여깁니다. 하지만 지식에 대한 지식, 즉 내가 그 지식을 얻은 과정이나 방법 같은 것은 소홀히 여기기 쉽습니다. 따라서 지식의 축적과 공유는 있어도 방법론의 축적과 공유는 매우 드문 편입니다. 저는 평소에 이런 생각에서 학교 후배들을 위해 제 자신의 공부 경험을 짬짬이 글로 옮겨놓았고, 이번 기회에 그 글들을 취합, 정리하게 되었습니다. 그 결실이 바로 이 글입니다.
김창준 (마이크로소프트웨어)
2002/06/02
이 글은 공부하는 방법과 과정에 관한 글입니다. 이 글은 제가 공부한 성공/실패 경험을 기본 토대로 했고, 지난 몇 년간 주변에서 저보다 먼저 공부한 사람들의 경험을 관찰, 분석한 것에 제가 다시 직접 실험한 것과 그밖에 오랫동안 꾸준히 모아온 자료들을 더했습니다. '만약 다시 공부한다면' 저는 이렇게 공부할 것입니다.
부디 독자 제현께서 이 글을 씨앗으로 삼아 자신만의 나무를 키우고 거기서 열매를 얻고, 또 그 열매의 씨앗이 다시 누군가에게 전해질 수 있다면 더 이상 바랄 것이 없겠습니다.
이 글은 특정 주제들의 학습/교수법에 대한 문제점과 제가 경험한 좋은 공부법을 소개하는 식으로 구성됐습니다. 여기에 선택된 과목은
리팩토링,
알고리즘·자료구조,
디자인패턴,
익스트림 프로그래밍(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』도 강력 추천합니다. 세계적인 짱짱한 프로그래머와 전산학자들이 함께 꼽은 위대한 책 목록에서 몇 손가락 안에 드는 책입니다. 아직 이 책을 본 적이 없는 사람은 축하합니다. 아마 몇 주간은 감동 속에 하루하루를 보내게 될 겁니다.
리팩토링 학습에서의 문제
소프트웨어 공학에서 리팩토링(refactoring)은 주로 '결과의 변경 없이 코드의 구조를 재조정함'을 뜻한다. 주로 가독성을 높이고 유지보수를 편하게 한다. 버그를 없애거나 새로운 기능을 추가하는 행위는 아니다. 사용자가 보는 외부 화면은 그대로 두면서 내부 논리나 구조를 바꾸고 개선하는 유지보수 행위이다.
먼저, 본지 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』을 강력 추천합니다. 이 글을 보는 모든 교육 종사자들이 꼭 읽어봤으면 합니다. 이 협동적 학습은 두 사람만이 아니고 그룹 단위로도 가능합니다. 스터디에 이용하면 재미와 유익함 일석이조를 얻습니다.
이 외에, 특히(어쩌면 가장) 중요한 것은 일취집중후각법 등을 이용해 자신의 코드 후각의 민감도를 높이는 것입니다. 코드 후각의 메타포 말고도 유사한 메타포가 몇 가지 더 있습니다. 켄트 벡은 코드의 소리를 들으라고 하고, 저는 코드를 향해 대화하라고 합니다. 코드의 소리를 듣는 것은 코드가 원하는 것에 귀를 기울이는 것을 말합니다. 코드는 단순해지려는 욕망이 있습니다. 그걸 이뤄주는 것이 프로그래머입니다. 그리고 짝 프로그래밍을 할 때 두 사람의 대화를 코드에 남기도록 합니다. 주석이 아닙니다. 왜 이것이 중요한가는 본지 2001년 12월호 「허실문답 XP 강화」를 참고하기 바랍니다.
기학으로 우리 사상사에 큰 획을 그은 철학자요, '서울서 책만 사다 망한 사람'으로 이름을 날릴 정도로 엄청난 지식욕을 과시하던 조선시대 사상가 혜강 최한기는 그의 저술 『신기통』(神氣通)에서 '눈에 통하는 법(目通), 귀에 통하는 법(耳通), 코에 통하는 법(鼻通)' 등을 이야기하고 있습니다. 어떻게 하면 우리는 코드에 도통할 수 있을까요? 리팩토링을 공부하거나 혹은 했던 사람들에게 많은 영감과 메타포를 주는 책으로 일독을 권합니다. 필자가 기회가 닿는다면 프로그래밍을 혜강의 사상적 측면에서 조망한 글을 써보고 싶습니다.
앞서의 것들이 어느 정도 이뤄지고, 리팩토링에 대한 감이 오게 되면 그 때 비로소 리팩토링 책을 하나 하나 파헤치고 또 거기서 제대로 된 비판을 할 수 있게 됩니다.
디자인패턴 학습에서의 문제 잡지에 연재되거나 서적으로 출간된 혹은 세미나에서 진행되었던 디자인패턴 '강의'를 몇 가지 접했습니다. 훌륭한 강의도 많았지만 그렇지 못한 것도 있었습니다. 몇 가지 문제점을 지적하겠습니다.
◆패턴을 지나치게 실체화, 정형화해 설명한다. ◆컨텍스트와 문제 상황에 대한 설명이 없거나 부족하다. 결과적으로 문제를 해결하기 위해 패턴이 도입된 것이 아니라 패턴을 써먹기 위해 패턴이 도입된 느낌을 준다. ◆문제의식을 먼저 형성하게 하지 않고 답을 먼저 보여준 뒤 그걸 어디에 써먹을지 가르친다. 왜 이걸 쓰는 게 좋은지는 일언반구 언급이 없다. 독자는 '어린아이가 망치를 들고 있는 오류'에 빠질 것이다. ◆패턴이 어떻게 생성되었는지 그 과정을 보여주지 못한다. 즉, 스스로 패턴을 만들어내는 데 도움이 전혀 되지 않는다. ◆해당 패턴이 현실적으로 가장 자주 쓰이는 맥락을 보여주지 못한다. 대부분 장난감 문제(Toy Problem)에서 끝난다.
그런 패턴 강의를 하는 분들이 알렉산더(Christopher Alexander, 패턴언어 창시자)의 저작을 충실히 읽어봤다면 이런 병폐는 없을 것이라 생각합니다. 알렉산더의 저작을 접해보지 못 하고서 패턴을 가르치는 사람은 성경을 읽어보지 않은 전도사와 같을 것입니다. 알렉산더가 『The Timeless Way of Building』의 마지막에서 무슨 말을 하는가요?
이 마지막 단계에는 더 이상 패턴은 중요하지 않다. … 패턴은 당신이 현실적인 것에 대해 수용적이 되는 것을 가르쳐줬다.
패턴 역시 도구요, 방편일 뿐입니다. 패턴은 현실적인 것에 대해 수용적이 되도록 가르친다는 말은 결국 우리가 궁극적으로 추구하는 것은 패턴이 아니라 현실이어야 한다는 이야기입니다. 물론 처음 단계에는 교육적인 목적에서, 어느 정도 패턴에 얽매여도 괜찮다고는 해도, 나중에 패턴을 잊고 패턴에서 자유로워지려면 처음부터 패턴에 대해 도구적·방편적인 인식을 가져야 합니다.
미국 캘리포니아 주립대학의 교수 베티 에드워즈(Betty Edwards)가 쓴 책 중에 『Drawing on the Right Side of the Brain』이라는 유명한 베스트셀러가 있습니다. 사람의 뇌와 그림 그리기의 관계에 대한 탁월한 책입니다. 에드워즈는 자신의 그리기 실력을 향상시키기 위해 우뇌를 적극적으로 사용하는 구체적인 방법들을 가르쳐줍니다. 그 중 대표적인 것 하나가 대상을 뒤집어 놓고 그리는 것입니다. 지금 실험해 보길 바랍니다. 1000원권 지폐를 바로 놓고 그걸 비슷하게 그려보고, 이번에는 그걸 위아래가 거꾸로 되게 놓고 따라 그려보십시오. 아마 무척 놀랐을 겁니다. "아니 내가 이렇게 그림을 잘 그리다니! 그것도 거꾸로!" 그렇습니다. 우리는 자신의 머리 속 패턴에 얽매여 세상을 제대로 보지 못 할 때가 많습니다. 실체가 코에 약간이라도 비슷하게 보이면 우리는 그것을 이미 우리 머리 속에 추상적으로 갖고 있던 기하학적 '코'의 패턴으로 대체해버리는 것입니다.
디자인 패턴 공부 우선은 제 교육철학과 언어교습론, 그리고 공부론 이야기를 잠깐 하겠습니다.
기본적으로 교육은 교육자가 피교육자가에게 지식을 그대로 전달하는 행위가 아닙니다. 진정한 교육은 피교육자의 개인적 체험에 기반한 전폭적 동의에서 출발합니다. 저는 이를 동의에 의한 교육이라고 합니다.
제가 "주석문을 가능하면 쓰지 않는 것이 더 좋다"는 이야기를 했을 때 이 문장을 하나의 사실로 받아들이고 기억하면 당장 그 시점에는 학습이 일어나지 않는다고 봅니다. 대신 여러분이 차후에 여러 가지 경험을 하면서도 이 화두를 놓치지 않고 있다가 어느 순간엔가, "아! 그래, 주석문을 쓰지 않는 게 좋겠구나!"하고 자각하는 순간, 바로 그 시점에 학습과 교육이 이뤄지는 것입니다. 이는 기본적으로 삐아제와 비갓스키(Lev Vygotsky)의 구성주의를 따르는 것이죠. 지식이란 외부에서 입력받는 것이 아니고, 그것에 대한 모델을 학습자 스스로가 내부에서 구축할 때 획득할 수 있는 것이라는 사상이죠.
권법에서 주먹에 대해 달통한 도사가 '권을 내지르는 법'에 대한 규칙들을 정리해서 애제자의 머리 속에 아무리 쑤셔 넣는 데 성공한들 그 제자가 도사만큼 주먹이 나갈리는 만무합니다. 권을 내지르는 법을 유추해 내기까지 그 스승이 겪은 과정을 제자는 완전히 쏙 빼먹고 있기 때문입니다. 소위 '몸'이 만들어지지 않은 것이지요. 제자는 마당 쓸기부터, 물 긷기 등의 수련 과정을 겪어야만 하고 스승이 정리한 그 일련의 규칙에 손뼉을 치고 춤을 추며 기쁨의 동의를 할 수 있을 정도로 수련 과정이 축적된 이후에야 비로소 진정한 '가르침'이 이뤄지는 것이며, 청출어람의 가능성도 생각해 볼 수 있는 것입니다.
이런 동의라는 것은 학습자 자신만의 컨텍스트와 문제의식을 바탕으로 한 것입니다. 우리는 많은 경우, 어떤 지식과 동시에 그 지식의 필요성까지도 지식화해서 외부에서 주입을 받습니다. 하지만 진정 체화된 지식을 위해서는 스스로가 이미 문제의식을 갖고 있어야 합니다.
패턴도 마찬가지인데, 대부분 그 패턴의 필요성을 체감하지 못한 채 그냥 도식적 구조를 외우기에만 주력하는 사람이 많습니다만, 사실 그렇게 되면 어떤 경우에 이 패턴이 필요하고 어떤 경우에는 사용하면 안 되는지(GoF는 패턴을 정말 안다는 것은 그 패턴을 쓰면 안 될 때를 아는 것이라 했습니다) 등을 알기 힘듭니다. 설령 책에 나온 가이드를 암기했더라도요. 자신의 삶 속에서 문제의식이 구체적으로 실제 경험으로 형성되지 않았기 때문입니다.
GoF 중 한 명인 랄프 존슨(Ralph Johnson)은 다음과 같이 말합니다.
우리[GoF]는 책에서, 정말 그 패턴들이 필요하다는 것을 알만큼 충분한 경험을 갖기 전에는 그것을 [시스템 속에] 집어넣는 것을 피해야 한다고 말할 만큼 대담하진 못했다. 하지만 우리 모두는 그 사실을 믿었다. 패턴은 프로그램의 초기 버전이 아니고 프로그램 생애의 훨씬 나중에 가서야 비로소 등장해야 한다고 나는 늘 생각해 왔다.
결국은 어떤 패턴의 필요성을 자신의 경험 속에서 절감하지 못한다면 그 패턴을 제대로 아는 것이 아니라고 말할 수 있을 겁니다. 따라서 패턴 하나를 공부할 때는 가능한 한 실제 예를 많이 접해야 합니다. 그리고 패턴을 적용하지 않은 경우에서 그 필요를 느끼고 설명할 수 있게끔 다양한 코드를 접해야 합니다.
소프트웨어 개발에 푹 빠지기 패턴 중에 보면 서로 비슷비슷한 것이 상당히 많습니다. 그 구조로는 완전히 동일한 것도 있죠. 초보자를 괴롭히는 것 중 하나입니다. 이것은 외국어를 공부할 때 문법 중심적인 학습을 하면서 부딪치는 문제와 비슷합니다. '주어+동사+목적어'라는 구조로는 동일한 두 개의 문장, 즉 'I love you'와 'I hate you'가 구조적으로는 동일할지라도 의미론적으로는 완전히 반대가 될 수 있는 겁니다. 패턴을 공부할 때는 그 구조보다 의미와 의도를 우선해야 하며, 이는 다양한 실례를 케이스 바이 케이스로 접하면서 추론화 및 자신만의 모델화라는 작업을 통해 하는 것이 최선입니다. 스스로 문법을 발견하고 체득하는 것이라고 할까요.
DP는 사전과 같습니다. 이 책은 순서대로 소설 읽듯이 읽어나가라고 집필된 것이 아니고, 일종의 패턴 레퍼런스로 쓰인 것입니다. 역시 GoF의 한 명인 존 블리스사이즈(John Vlissides)는 다음과 같이 말합니다.
여기서 내가 강조하고 싶은 것은 디자인패턴, 즉 GoF 책을 어떻게 읽느냐는 것이다. 많은 사람들은 그 내용을 온전히 이해하기 위해서는 순서대로 읽어야 한다고 느낀다. 하지만 GoF는 소설이 아니라 레퍼런스 북이다. 독일어를 배우기 위해 독영 사전의 처음부터 끝까지 하나하나 읽으려고 하는 경우를 생각해 보라. 그렇게는 결코 배울 수 없을 것이다! 독일어를 마스터하기 위해서는 독일어 문화에 자기 자신을 푹 담궈야(immerse) 한다. 독일어로 살아야 하는 것이다. 디자인패턴도 똑같다. 그걸 마스터하기 이전에 소프트웨어 개발에 자신을 푹 담궈야 한다. 패턴으로 살아야 하는 것이다. 만약 꼭 그래야 한다면 소설 읽듯이 디자인패턴 책을 읽어라. 하지만 거의 아무도 그 방식으로 유창해지지 못한다. 소프트웨어 개발 프로젝트의 열기 속에서 패턴이 동작하게 하라. 실제 디자인 문제를 직면했을 때 그 패턴들의 통찰을 이용하라. 이것이 GoF 패턴들을 자신의 것으로 만드는 가장 효율적인 방법이다.
어떤 지식을 체화하기 위해선 그 지식으로 살아야 한다는 말을 확인할 수 있습니다. 영어를 배우려면 영어로 살고, DP를 배우려면 DP로 살라는 단순하면서도 아주 강력한 말입니다.
어떤 특정 문장 구조를 학습하는 데 최선은 그 문장 구조를 이용한 실제 문장을 나에게 의미 있는 실제 컨텍스트 속에서 많이 접하고 스스로 나름의 모델을 구축하여 교과서의 법칙에 '기쁨에 찬 동의'를 하는 것입니다.
주변에서 특정 패턴이 구현된 코드를 구하기가 힘들다면 이 패턴을 자신이 만지고 있는 코드에 적용해 보려고 노력해 볼 수 있습니다. 이렇게 해보고 저렇게도 해보고, 그러다가 오히려 복잡도만 증가하면 "아 이 경우에는 이 패턴을 쓰면 안 되겠구나"하는 걸 학습할 수도 있죠. GoF는 패턴을 배울 때는 한결 같이 "이 패턴이 적합한 상황과 동시에 이 패턴이 악용, 오용될 수 있는 상황"을 함께 공부하라고 합니다.
이런 식의 '사례 중심'의 공부를 위해서는 스터디 그룹을 조직하는 것이 좋습니다. 혼자 공부를 하건, 그룹으로 하건 커리프스키(Joshua Kerievsky)의 「A Learning Guide To Design Patterns」( http://www.industriallogic.com/papers/learning.html )를 참고하세요. 그리고 스터디 그룹을 효과적으로 꾸려 나가는 데는 스터디 그룹의 패턴 언어를 서술한 「Knowledge Hydrant」( http://www.industriallogic.com/papers/khdraft.pdf )를 참고하면 많은 도움이 될 겁니다. 이 문서는 뭐든지 간에 그룹 스터디를 한다면 적용할 수 있습니다.
LG2DP(「A Learning Guide To Design Patterns」) 뒷부분에 보면 DP를 공부하는 순서와 각 패턴에서 던질만한 질문이 같이 정리되어 있습니다. DP는 순차적으로 공부해야만 하는 것은 아닙니다. 효과적인 공부의 순서가 있습니다. sorry라는 단어를 모르면서 remorseful이라는 단어를 공부하는 학생을 연상해 보세요. 외국어 공부에서는 자기 몸에 가까운 쉬운 단어부터 공략하는 것이 필수적입니다. 이런 걸 근접 학습(Proximal Learning)이라고도 하죠. 등급별 어휘 목록 같은 게 있으면 좋죠. LG2DP에서 제안하는 순서가 그런 것 중 하나입니다.
랄프 존슨은 이런 순서의 중요성에 관해 다음과 같은 말을 했습니다.
… 하지만 나는 언제나 싱글톤 패턴을 가르치기 전에 콤포짓, 스트래터지, 템플릿 메쏘드, 팩토리 메쏘드 패턴을 가르친다. 이것이 훨씬 더 일반적인 것들이며, 대다수의 사람들은 아마도 이것들 중 마지막 두 가지를 이미 사용하고 있을 것이다.
마이크로패턴 그런데 사실 GoF의 DP에 나온 패턴들보다 더 핵심적인 어휘군이 있습니다. 마이크로패턴이라고도 불리는 것들입니다. DP에도 조금 언급되어 있긴 합니다. 이런 마이크로패턴은 우리가 알게 모르게 매일 사용하는 것들이고 그 활용도가 아주 높습니다. 실제로 써보면 알겠지만, DP의 패턴 하나 쓰는 일이 그리 흔한 게 아닙니다. 마이크로패턴은 켄트 벡의 『Smalltalk Best Practice Patterns』에 잘 나와 있습니다. 영어로 치자면 관사나 조동사 같은 것들입니다.
그리고 이런 마이크로패턴과 함께 리팩토링을 공부하는 게 좋습니다. 리팩토링은 패턴의 필요를 느끼게 해줍니다. 제가 리팩토링 공부에서도 언급했지만 OAOO를 지키면서 리팩토링을 하다보면 자연스레 디자인패턴에 도달하는 경우가 많습니다. 이 때는 지나친 엔지니어링(Overengineering)이 발생하지 않고, 오로지 필요한 만큼만 생깁니다. 이에 관해서는 커리프스키의 「Stop Over-Engineering!」( Software Development Magazine, Apr 2002, http://www.sdmagazine.com/documents/s=7032/sdm0204b/0204b.htm )의 일독을 권합니다. 리팩토링이 디자인패턴을 어떻게 생성해낼 수 있는지 보여주고 있습니다.
1980년대 이후 최근 알렉산더의 향방도 이런 쪽으로 가고 있습니다. 그는 자신이 발표한 기존 패턴들이 너무 크다고 생각해 그런 패턴들을 구성하고, 자동으로 만들어 내며, 또 관통하는 더 작은 원칙들을 발견하는 데 노력해 오고 있습니다. 코플리엔(James Coplien)은 컴퓨터계가 알렉산더의 최근 발전을 쫓아가지 못한다고 늘 이야기합니다.
제대로 된 패턴 구현을 위한 다양한 접근 시도하기 우리의 지식이라는 것은 한 가지 표현양상(representation)으로만 이뤄져 있지 않습니다. 사과라는 대상을 음식으로도, 그림의 대상으로도 이해할 수 있어야 합니다. 실제 패턴이 적용된 '다양한 경우'를 접하도록 하라는 것이 이런 겁니다. 동일 대상에 대한 다양한 접근을 시도하라는 것이죠. 자바로 구현된 코드도 보고, C++로 된 것도 보고, 스몰토크로 된 것도 봐야 합니다. 설령 '오로지 자바족'이라고 할지라도요(전 이런 사람들을 자바리안(Javarian)이라고 부릅니다. 자바와 바바리안(barbarian)을 합성해서 만든 조어지요). 이런 '오로지 하나만 공부하는 것'의 병폐에 대해서는 존 블리스사이즈가 쓴 「Diversify」( http://www.research.ibm.com/people/v/vlis/pubs/gurus-99.pdf )라는 글을 읽어보세요. 이렇게 다양화를 해야 비로소 자바로도 '상황에 맞는' 제대로 된 패턴을 구현할 수 있습니다. 패턴은 그 구현(implementation)보다 의도(intent)가 더 중요하다는 사실을 꼭 잊지 말고, 설명을 위한 방편으로 채용된 한 가지 도식에 자신의 사고를 구속하는 우를 범하지 않기를 빕니다.
이런 맥락에서 저는 DP를 공부할 때 GoF와 동시에 『Design Patterns Smalltalk Companion』을 필수적으로 읽기를 권합니다. 두 권은 말하자면 양날개입니다. 하나는 정적언어로 구현되었고(간간이 스몰토크 구현이 있긴 합니다), 다른 하나는 동적언어로 구현되어 있습니다. 언어와 패턴의 고리를 느슨하게 하고, 패턴을 여러 관점에서 신선하게 볼 수 있는 계기가 될 것입니다. 또, 한 쪽을 보고 이해가 잘 되지 않을 때 다른 쪽을 보면 쉽게 이해됩니다. 서로 상보적인 것이죠.
패턴도 결국 '문제해결'을 위한 한 가지 방편에 지나지 않습니다. 주변에서 "이 경우에는 무조건 이 패턴을 써야 합니다"하고 생떼를 쓰는 사람을 보면 씁쓸한 기분을 감출 수 없습니다.
디자인패턴 추천서 디자인패턴 책 중에 중요한 서적을 몇 권 소개하겠습니다.
◆『Design Patterns Explained』(Shalloway, Trott): 최근 DP 입문서로 급부상하고 있는 명저 ◆『Design Patterns Java Workbook』(Steven John Metsker): DPE 다음으로 볼만한 책으로 쏟아져 나오는 시중의 조악한 자바 패턴 책들과는 엄연히 다르다. 워크북 형식을 채용해서 연습문제를 풀고 뒷부분의 답과 대조해 볼 수 있는 등 독학자가 공부하기에 좋다. ◆『Refactoring』(Martin Fowler): DP 공부 이전에 봐서 문제의식 형성하기(망치를 들면 모든 것이 못으로 보이는 오류 탈피) ◆『Design Patterns』: 바이블. ◆『Design Patterns Smalltalk Companion』: GoF가 오른쪽 날개라면 DPSC는 왼쪽 날개 ◆『Pattern Hatching』(John Vlissides): DP 심화학습. 얇지만 밀도 높은 책. ◆『Smalltalk Best Practice Patterns』(Kent Beck): 마이크로 패턴. 개발자의 탈무드. 감동의 연속. ◆『Pattern Languages of Program Design』 1,2,3,4: 패턴 컨퍼런스 논문 모음집으로 대부분은 인터넷에서 구할 수 있음 ◆『Pattern-Oriented Software Architecture』 1,2: 아키텍처 패턴 모음. 2권은 네트워크 애플리케이션의 아키텍처 모음. ◆『Concurrent Programming in Java』(Doug Lea): 컨커런트 프로그래밍에 대한 최고의 서적. ◆『Patterns of Software』(Richard Gabriel): 패턴에 관한 중요한 에세이 모음. ◆『Analysis Patterns』(Martin Fowler): 비즈니스 분석 패턴 목록. 비즈니스 애플리케이션 개발자에게 많은 도움이 됨. ◆『A Timeless Way of Building』(Christopher Alexander): 프로그래머들이 가장 많이 본 건축 서적. 패턴의 철학적·이론적 배경. '구약'('신약'은 올해 안에 출간 예정인 동저자의 『The Nature of Order』). ◆『A Pattern Language』(Christopher Alexander): 알렉산더의 건축 패턴 모음집. ◆『Problem Frames』(Michael Jackson): DP의 해결(solution) 지향식의 문제점과 극복 방안으로서의 문제 지향식 방법. 마이클 잭슨은 요구 사항 분석 쪽에서 동명의 가수만큼이나 유명.
DP를 처음 공부한다면, DPE와 DPJW를 RF와 함께 보면서 앞서의 두 권을 RF적으로 독해해 나가기를 권합니다(하버드 대학의 뚜웨이밍 교수는 요즘 칸트를 유교적으로 독해하고 있다고 합니다. 하나의 책을 다른 각도에서 독해하는 것, 여기서 배우는 것이 많습니다). 이게 된 후에는 GoF와 DPSC를 함께 볼 수 있습니다. 양자는 상호 보완적인 면이 강합니다. 이쯤 되어 SBPP를 보면 상당히 충격을 받을 수 있습니다. 스스로가 생각하기에 코딩 경험이 많다면 다른 DP 책 이전에 SBPP를 먼저 봐도 좋습니다.
이 정도의 책을 봤다면 POSA와 PLOPD 등에서 자신이 관심이 가는 패턴들을 찾아 읽는 것이 좋습니다. 그리고 동시에 알렉산더의 원저들을 꼭 읽기를 권합니다. 가브리엘의 책이 알렉산더의 사상 이해에 많은 도움이 될 것입니다.
패턴 공부를 해나가면서 남을 가르치는 것이 공부에 많은 도움이 됩니다(사실 자바 패턴 책 중에 어떤 것은 "내가 패턴을 처음 공부하면서 같이 쓴 것이다"라고 저자가 고백한 것도 있습니다). 보이스카웃에서는 보통 다음 과정을 통해 뭔가를 '학습'하게 한다고 합니다. 처음은 어떻게 하는지를 보여주고, 다음은 스스로 그것을 해보게 하고, 다음으로 그걸 남에게 가르치게 합니다. 이 때 중요한 것은 상대가 이해하지 못 하면 그 이유를 자기 자신에게서 찾는 것이 나에게 더 이득이 된다는 것입니다. "내가 설명을 잘못 했군"하고 생각하는 것이죠. 그러면 다음번에는 설명을 좀더 잘 할 수 있게 되고, 동시에 자기의 이해도 더욱 명료해지게 됩니다. 저는 'OOP 개념을 한 시간 만에 가르치기'나 '특정 언어 문법을 한 시간 만에 가르치기' 등을 하나의 도전으로 생각하고 즐깁니다. 가르치면서 동시에 배운다는 것은 정말 놀라운 경험입니다.
익스트림 프로그래밍 학습에서의 문제
익스트림 프로그래밍(eXtreme Programming, XP)는 켄트 백 등이 제안한 소프트웨어 개발 방법이다. 비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법이다. 1999년 켄트 백의 저서인 'Extreme Programming Explained - Embrace Change'에서 발표되었다.
이 방법은 애자일 개발 프로세스라 불리는 개발 방법 중의 대표적인 하나로 꼽히며, 약칭인 ‘XP’로 잘 알려져 있다.
이 방법은 10~12개 정도의 구체적인 실천 방법(프랙티스)을 정의하고 있어, 비교적 적은 규모의 인원의 개발 프로젝트에 적용하기 좋다. 개발 문서 보다는 소스코드를, 조직적인 개발의 움직임 보다는 개개인의 책임과 용기에 중점을 두는 경향이 크다.
앞의 경우와 비슷합니다. 익스트림 프로그래밍을 공부하는 사람들은 실제로 행해보지 않고 책만 들여다보면 안 됩니다. 그렇다고 책이 중요하지 않다는 말은 아닙니다. 하지만 자전거 타기는 자기 몸으로 직접 굴려봐야 합니다.
게다가 켄트 벡 스스로가 『XP Explained』를 만약 다시 쓴다면 뜯어고치고 싶은 부분이 상당히 된다고 말하는 것을 봐도 알 수 있듯이 초기 XP 이후 바뀌고 보완된 점이 상당수 있습니다. 따라서 책만으로 XP를 공부하기는 힘듭니다. 지금은 책 속의 XP가 사람들의 머리 속 XP에 한참 뒤쳐져 있습니다.
어찌 되었든 XP에는 무술이나 춤, 혹은 악기 연주 등과 유사한 면이 많습니다. 따라서 글을 보고 그것을 익히기는 쉽지 않습니다. 그나마 메일링 리스트 같은 '대화'를 보면 훨씬 더 많은 것을 얻을 수 있기는 하지만, 태권도 정권 찌르기를 말로 설명하는 것이 불가능에 가깝듯이 XP를 언어를 통해 익히기는 정말 어렵습니다. 우리의 언어는 너무도 성글은 미디어입니다(XP는 매 초, 매 순간 벌어지는 '일상적' 장면의 연속이 매우 중요합니다).
익스트림 프로그래밍 공부 XP를 이해하려면 다음 기본 자료에 대한 이해가 우선해야 합니다(본지 2001년 12월호 「허실문답 XP 강화」 참조).
◆『XP Explained』(Kent Beck): XP 선언서 ◆『XP Installed』(Ron Jeffries et al): C3 프로젝트에 적용한 예, 얻은 교훈 등 ◆『Planning XP』(Kent Beck, Martin Fowler): 계획 부분 설명(관리자, 코치용) ◆『Refactoring』(Martin Fowler): 리팩토링에 대한 최고의 책 ◆『XP Applied』: 유즈넷과 메일링 리스트의 논의 등 최근 자료를 반영 ◆『XP Explored』: 가장 쉽고 구체적인 XP 안내서
이 중에서 XPI나 XPX를 먼저 권합니다. XPE는 좀 추상적인 서술이 많아서 봐도 느낌이 별로 없을 수 있습니다(2001년 본지 11월호에 제가 쓴 리뷰 참고). 여유가 되면 다음 자료를 더 참고합니다.
◆『The Timeless Way of Building』: 패턴 운동을 일으킨 알렉산더의 저작. 현장 고객(On-site Customer), 점진 성장(Piecemeal Growth), 소통(Communication) 등의 아이디어가 여기에서 왔음. ◆『XP in Practice』(Robert C. Martin 외): 두세 사람이 짧은 기간 동안 간단한 프로젝트를 XP로 진행한 것을 기록. 자바 사용(중요한 문헌은 아님). ◆『XP Examined』: XP 컨퍼런스에 발표된 논문 모음 ◆『Peopleware』(Tom DeMarco): 개발에 있어 인간 중심적 시각의 고전 ◆『Adaptive Software Development』(Jim Highsmith): 복잡계 이론을 개발에 적용. 졸트상 수상. ◆『Surviving Object-Oriented Projects』(Alistair Cockburn): 얇고 포괄적인 OO 프로젝트 가이드라인 ◆『Software Project Survival Guide』(Steve McConnell): 조금 더 전통적인 SE 시각. ◆『The Psychology of Computer Programming』(Gerald M. Weinberg): 프로그래밍에 심리학을 적용한 고전. 코드 공유와 짝 프로그래밍에 필수인 비자아적 프로그래밍(Egoless Programming)이 여기서 나왔다. ◆『Agile Software Development』(Alistair Cockburn): 전반적 애자일 방법론에 대한 개론서 ◆『Software Craftsmanship』(Pete McBreen): 장인으로서의 새로운 프로그래머 상 ◆『Agile Software Development with SCRUM』(Schwaber Ken): 최근 확장성(Scalability)을 위해 XP+SCRUM의 시도가 애자일 쪽의 큰 화두임. ◆『A Practical Guide to eXtreme Programming』(David Astels 외): 저자들이 직접 참여한 프로젝트를 따라가 보면서 배움. 자바로 구현. XPP보다는 스케일이 큼. ◆『Agile Modeling』(Scott Ambler): 애자일 쪽에서 모델링이 무시되는 느낌이 있을 수 있는데, 그쪽으로 깊게 천착한 사람이 앰블러임. ◆『Agile Software Development Ecosystems』(Jim Highsmith): 각각의 애자일 방법론에 대한 소개와 동시에 각 방법론의 대표자들 인터뷰가 백미. ◆『Test Driven Development』(Kent Beck): 곧(아마 올해 내에) 출간 예정인 최초의 TDD 서적. TDD를 모르면 XP도 모르는 것(TDD를 실제 적용하려면 적어도 반년 정도는 계속 훈련해야 함) ◆IEEE Software/Computer, CACM, Software Development Magazine 등에 실린 기사 ◆『XP Conference, XP Universe 등의 논문들(특히 최근 것들) ◆유즈넷, 메일링 리스트, 오리지널 위키( http://c2.com )의 논의들
특히 유즈넷, 메일링 리스트, 오리지널 위키는 늘 가까이 하고 있어야 합니다. 이 세 곳을 살필 때, 특히 다음 사람들의 글은 꼭 읽어보고 항상 레이더를 열어두면 좋습니다(이 외에도 개발 경력 10년, 20년이 넘는 짱짱한 사람이 많으므로 눈 여겨 관찰하세요. 모든 글을 읽는 것은 무리이므로 그들의 대화를 일차적으로 읽어야 합니다).
켄트 벡, 론 제프리즈(Ron Jeffries), 워드 커닝엄(Ward Cunningham), 앨리스테어 코번(Alistair Cockburn), 마틴 파울러, 로버트 마틴 혹은 엉클 밥(Robert C. Martin aka Uncle Bob), 마이클 페더즈(Michael Feathers), 켄 아우어(Ken Auer), 윌리엄 웨이크(William Wake), 로이 밀러(Roy Miller), 데이브 토마스(Dave Thomas), 앤디 헌트(Andy Hunt), 랄프 존슨, 스카트 앰블러(Scott Ambler), 짐 하이스미스(Jim Highsmith), 조슈아 커리프스키(Joshua Kerievsky), 로렌트 보사빗(Laurent Bossavit), 존 브루어(John Brewer) 등
이런 자료들 외에, 기회가 된다면 주변에서 XP를 직접 사용하는 곳을 방문해서 하루만 같이 생활해 보기를 권합니다. 반년 공부를 앞당길 수 있습니다. 제가 공부할 때는 주변에 XP를 아는 사람이 없어서 혼자 공부했는데, 그것에 비해 XP를 직접 사용하는 상황에 처한 사람은 (제가 억울하리만큼) 더 적은 노력으로 몇 배 이상 빨리 몸에 익히는 것 같았습니다.
이게 힘들면 같이 공부하는 방법이 있습니다(앞서 언급된 스터디 그룹에 관한 패턴 참고). 이 때 같이 책을 공부하거나 하는 것은 시간 낭비가 많습니다. 차라리 공부는 미리 다 해오고 만나서 토론을 하거나 아니면 직접 실험을 해보는 것이 훨씬 좋습니다. 두 사람 당 한 대의 컴퓨터와 커대란 화이트보드를 옆에 두고 말이죠. 제 경우 스터디 팀과 함께 저녁 시간마다 가상 XP 프로젝트를 많이 진행했고, 짤막짤막하게 프로그래밍 세션도 많이 가졌습니다. 나중에 회사에서 직접 XP를 사용할 때 많은 도움이 되었습니다.
Refactor Me 제가 하고 싶은 말은 더 있지만 이 글은 일단 여기서 끝이 납니다. 서두에서 말씀드렸듯이 애초 쓰려던 '일반론'은 생략하고, 대신 독자들의 몫으로 남겨두려 합니다. 이 글 자체가 여러분의 리팩토링 수련의 연장(延長)이 되었으면 하는 바램입니다. 이 글과 함께 실생활에서 직접 실험을 해보면서 - 이 때 욕심 부리지 않고 한 가지씩 지긋이 해보는 느긋함과 음미의 정신이 필요할지도 모르겠습니다 - 자신의 경험을 축적해 나가고, 동시에 이 글을 적절히 리팩토링해서 자신만의 패턴을 차근히 만들어 나가길 바랍니다. 그렇습니다. 리팩토링은 대상에 대한 이해가 깊고 경험이 많을수록 더 잘할 수 있습니다.
이 글에 소개된 제 공부론은 어찌 보면 상당히 진부해 보이기도 할 것입니다. 하지만 저는 이런 상식적이고 일상적이며 심지어는 소소해 보이는 것들에서 많은 감동을 받아왔습니다. 이 글도 사실 제 감동의 개인사입니다. 저는 "만약 오늘 어떤 것에라도 감동한 것이 없었다면, 오늘은 뭔가 잘못 산 것이다"라는 신조를 갖고 있습니다. 그것이 컴퓨터이건 대화이건 상관없이 말이죠. 저는 날마다 감동하며 살려고 노력합니다. 그러나 이 감동에 뭔가 꼭 대단한 것이 필요한 것은 아닙니다. 저는 오히려 감동 받기 위해 스스로 대단해져야 할 필요를 느끼기도 합니다. '감동'이라는 것은 주어지는 것이 아닙니다. 나와 타자가 공조하여 만드는 대화입니다.
감동해야 체득할 수 있다고 생각합니다. 그리고 이 감동은 개인적 삶 속에서 자기가, 자신의 몸으로, 직접 얻는 것입니다. 工夫 열심히 합시다. @
진짜 제대로 공부하려면 정말 끝이 없는 게 맞는 것 같다.
아직 시간이 많으니까 차근차근 욕심부리지 말고 하나하나씩 공부해나가고 싶다.
어제 엄마가 핸드폰을 잃어버리셨다고 해서
예전에 내가 쓰던 핸드폰을 택배로 부쳐야 되는 상황이 되었었다.
분명 이것저것 지울 것이 많을 거여서,
아주 오랜만에 핸드폰을 켜봤다.
문자메시지 화면에는 아직도 2009년인 것처럼
그 때 보냈던 문자들이 존재하고 있었다..
나는 아직도 남은 흔적들이 그대로다..
가끔 집을 청소하다보면 추억이 담긴 물건들이 하나씩 꼭 보인다.
절대 그리워서라던지, 미련이 남아서라던지 그런건 아닌데
그냥 그 때 그 추억이 아까워 버리질 못하겠다.
내 자취방에는 정말 짐이 많다.
정말 1년을 지나도 한번도 안 입는 옷도, 언젠가 입을꺼 같애서 버리지 못하고,
잡동사니들도 언젠가 쓸꺼 같아서, 추억이 담겨있어서 이런저런 이유로 버리질 못했다.
결국 그 문자들이랑, 같이 찍었던 사진도 모두 삭제 하고, 주소록도 싹 지워서 다시 회사에 가지고 왔다.
택배를 보내려고 했는데, 상자가 필요하길래 다음날 보내야겠다고 생각하고 있었다.
저녁에 전화가 왔는데 휴대폰을 보니 번호가 엄마핸드폰번호?!
휴대폰 누가 주워서 찾아줬다고 휴대폰 보내지 않아도 된다는 엄마의 말..
그 순간에 바로 괜히 지웠네라고 생각하는 나도 참..;
이번 주말엔 시간내서 필요없는 물건들, 옷들 싹 정리해야겠다는 생각을 한다.
버릴 껀 버려야지.
1. 블로그 스킨을 바꿨다.
요즘따라 연두색이 너무 좋아졌었는데, 요 스킨이 있길래 바꿔봤다.
처음 바꾸고 나서 한가지가 걸리는 게 있었는데 원래 본문쪽에 둥근네모 테두리가 있었다.
그게 좀 보기 싫어서 html 손 좀 봤다.
그거 빼고 맨 위만 바꾸고 나니 맘에 쏙 든다. ^ㅁ^//
음..? 근데 쓰고나니 스킨이 이상해져 버렸다;
갑자기 왜 이러지 ㅠ_ㅠ
나중에 다시 고쳐봐야겠다..
2. 다른 사람도 그런 기분을 원래 느끼는 건가 싶은데,
집중이 너무 잘되는 날의 내 모습을 알기때문에 더 집중이 안되는 날이 있다.
오늘 완전 칼퇴(6시!)를 하고 집에 와서 밥을 아주 빨리 해치운다음,
공부할 마음으로 가져온 헤드퍼스트 자바 책을 가지고 보는데,
한 페이지 보다가 인터넷 들어가서 서핑하고,
또 다시 그 페이지 보다가 휴대폰 만지작 거리고..
그러다 시계를 봤더니 벌써 10시..
정말 집중이 잘되는 날이나 때에는,
몇일 동안 해도 못할 일과 공부를 할 수 있게 되서 정말 좋은데,
그런 날에 아주 내 에너지를 다 뺏어가는 건지,
그 집중력있던 날이 지나가면 도통 집중을 못하겠다.
머리 속으로도 계속 '집중만 잘 됬어도, 이거 금방하는데.. 라던지
왜케 집중이 안되는거야 ㅠ_ㅠ 이런식으로 속상해 한다던지
이런 생각만 하다가 또 딴생각에 빠졌다가,
갑자기 인터넷을 한다거나 다른일을 하는 그런 ...
3. 오늘 좀 글을 몇 개 쓰면서 내 블로그를 보는데, 내 블로그 너무 재미없다 ㅠ_ㅠ
글도 지금은 이렇게 칸을 엔터치면서 글쓰기라도 하지..
꼭 소설책마냥 줄줄줄 말만 써놓고;
예전엔 일기 쓰듯 글 쓰는 거 잘 했던 거 같은데, 도통 모르겠다.
많이 채울려고 하지 말고 그때 그때 생각나는 거 조금씩만 적어야지..
라고 쓰는데 이미 이렇게 많은 글이 ㅠ_ㅠ
4. 요즘에 관심사가 너무 없어졌다. 정말 좋아하던 것들이 많이 시들해진 느낌이다.
요즘엔 판타지나,무협, 그리고 소설도 재미가 없고, 온라인 게임도 재미가 없고,
아이돌 좋아했던 것도 시들해졌고, 원래 티비는 별로 안 좋아했고, 드라마도 별로..
그렇다고 오로지 공부에 열의를 쏟고 있는 건 분명 아닌데..
블로그에 글이 이런글 밖에 없는 것도 요 이유중에 하나인 것 같다는 생각이 든다.
뭔가 새로운 흥미거리가 생겼으면 좋겠는데..
그림을 배우거나 운동을 배우고 싶다는 생각이 들긴 하는데 아직 잘 모르겠다.
저번주 내내 고민했던 것중에 하나는 노트정리에 대한 거였다. 지금쓰고 있는 담비노트는 성능이 정말 빠방!!하고, 유료결제도 해버려서 잘 쓰고는 있었는데, 회사 컴퓨터에서만 쓰고 있었고, 집에서는 잘 쓸 수가 없다는 단점(다른 컴퓨터에서는 사용 못함, 단 외장 메모리에서는 가능)이 있었고, 그렇다고 예전에 쓰던 jwfreenote를 다시 쓰기에는 이미 익숙해져 버린 좋은 기능들을 못 쓴다는 점이 아쉬웠다. 그래서 예전에 봐뒀던 에버노트를 써볼까 했는데, 설치하고 써보니까 모바일로도 볼 수 있다는 점은 좋긴 했는데.. 이것도 기능이 별로였다.
그래서 결국 결정한 것은
- 담비노트가 주 노트 : 모든 것을 다 정리하는 노트, 회사컴퓨터에서 주로 쓰고, 외장하드를 따로 사서 외장하드에 넣고 다니면서 여러 컴퓨터에서도 사용 가능하도록 하기
- 에버노트가 부 노트 : 자주 보는 내용은 에버노트에도 업데이트 해서 휴대폰(어썸노트에서 볼 수도 있어서 좋은듯, 어썸노트도 유료버전 쓰고 있음)이나 어디서나 볼 수 있게(인터넷으로도 볼 수 있으니까..)
- 내 목표 + 작업정리 노트 : 이건 오프라인 노트, 얼마전에 '탁월함에 이르는 노트의 비밀'이라는 책을 아주 좋게(?) 봐서, 컴퓨터용 말고도 오프라인으로 내가 직접 손으로 쓰는 노트도 마련했다. 이 노트는 플래너 + 회사 작업중에 과정과 결과를 쓰는 노트의 용도로 마련했다. 그 밖에도 내가 관심있어하는 주제에 대해서 스크랩하고 정리할 노트. 저번 주부터 쓰기 시작했는데, 진짜 노트를 펴면 그때부터 그 주제에 관해 집중이 되고 컴퓨터에 쓰는 노트와는 다른 매력이 있는 듯하다.
많이 고민했지만.. 노트를 하나로는 합치지 못했다 ㅠ_ㅠ
그리고 작년에 회사에 들어오기 한달 전부터 담비노트로 바꾸면서 jw노트에 정리한 내용들을 거의 다시 옮기지 못해서 그대로 있었는데, 이번에 다시 열어보면서 참 신기했다.
jw노트는 2007년?2008년도 부터 썼던 건데, 보면 일기도 있고, 정글에서 다녔던 웹디자인스페셜리스트 과정이랑 플래시스페셜리스트 과정때 배웠던 내용 정리한 거랑, 포트폴리오랑 졸업작품, 그 밖에 여러 작업들 하느라 스크랩했던 자료들까지 보니까 새록새록 그때 관심있었던게 뭐였고, 뭘 배웠고 했던 것이 기억이 많이 났다. 이 맛에 노트정리를 열심히 하는 것일지도, 빨리 다시 담비노트로 다시 정리해서 넣어놓고, 내 노트를 더 풍부하게 완성시켜야겠다.
1. 어제 또 참지 못하고 마구 먹어버렸다. 아침에 아주 둥글둥글 한 내 얼굴을 보니 왜 그랬나 싶다; 꼭 나는 열심히 잘하다가 한번씩 삐끗- 한단말이지 ㅠ_ㅠ 오늘은 선거 투표날, 수요일에 이렇게 갑자기 쉬게 되니까 참 좋다. 이따 1시 정도에 친구가 신림에 온다고 했으니까, 그 전에 투표하고 와서 포도몰 같이 가면 되겠다. 집이 청소도 안해서 완전 지저분,너저분하다. 이상하게도 한번 깨끗하게 청소를 해놓으면 나도 옷정리라든지, 물건정리를 좀 하게 되는데 어느순간 아침에 급히 나가거나 해서 더러워져 있는 집을 보게 되면 기분이 나도모르겠다, 귀찮다로 이어지는 지 모르겠다. 어제 그렇게 나도 모르겠다하고 먹어버린 이유중에 하나도 집이 어지러져 있었기 때문일꺼다;
2. 오랜만에 게임이나 할까 해서 하던것도 재미가 없다. 진짜 이제 게임은 흥미가 떨어진걸까. 신기하기도 하고.. 하긴 게임해서 남는게 하나도 없으니까 ; 빨리 귀차니즘을 벗어나서 얼른 집치우고 나갈준비해야지~~
3. 매주 토요일마다 하던 플렉스 스터디가 쫑 났다. 아마 스터디 안했으면 플렉스 공부를 계속하지 못했을 듯. 게다가 토요일 아침 10시부터 하던거라. 토요일을 좀 알차게 보낼 수 있어서 좋았다. 스터디 끝나도 12시인지라, 그냥 밥 먹고 강남 돌아다니거나, 거의 교보문고가서 보고싶었던 책을 많이 봤었다. 그래서 토요일 스터디를 계속 유지하고 싶었던 지라 바로 다음 스터디가 정해졌다.
이번 스터디가 몇번째 이더라.. 처음 플래시 스터디는 학원 다닐때였는데, 그 때는 포트폴리오 만드느라 정신이 없었었고, 내 실력도 많이 부족했던 지라, 첫번째 나가고 바로 다음스터디때 발표 걸려서 했는데 아주 준비도 안해가서 너무 부끄러웠고 그리고 다음에 4번째부터 못나갔던 거 같다. 그게 내 첫 스터디의 기억,
그 다음스터디가 학원 사람들이 거의 다 멤버였던 스터디. 그것도 어떻게 하다보니까 흐지부지되서 쫑났고..
그리고 나서 회사 들어가고, 이번년도에 각각 다른 언어를 RND해 보라는 과장님의 제안으로 안드로이드 스터디를 했었다. 처음 스터디는 그래도 꼬박꼬박나가고 끝까지 참여했고, 두번째 안드로이드 스터디 때는 별로 진행이 잘 되지 않았었다. 그래도 안드로이드 책 몇번 훑어 볼 수 있었고, 시작하라면 할 수 있는 정도까지는 스터디 해서 좋았다. 혼자 하라고 했음 분명 잘 안했을 듯.
그리고 그 다음이 플렉스 스터디였다. 한번도 빠지지 않고 나가고, 처음엔 숙제도 아주 열심히 했었다. 나중엔 바빠서 숙제는 잘 못했지만, 다루는 주제도 좋았고, 플렉스 제대로 하고 싶어서 열심히 참여했던 스터디였다.
이번주부터 나가게 되는 다음 스터디는 플래시 스터디이고, 주제를 정해서 한분이 가르쳐주고, 의견나누고 여러가지 이슈되는 사항에 대해서 말해보는 스터디인 거 같았다. 학원 오빠가 나가는 스터디라서 추천받아서 끼게 됬다. 그 스터디는 또 강남에서 오전 스터디이다. 아직 스터디를 만든건 아니지만 토요일 오후에는 또 우리 플스 사람들끼리 하는 스터디를 반장오빠가 주최할 예정이다.
이번주는 스터디 주제가 TEXT에 관한거라 지금 조금 공부해두고 있다. 클래스라던지, 관련해서 했던 내용들 다시 보고 있는중. 이번주 토요일에 또 세미나도 있어서, 거기에 나오는 주제도 미리 한번 훑어보고 가려고 한다. 그럼 더 내게 남는게 많을 거 같아서.. 아무튼 이로서 앞으로 토요일에는 하루종일 공부모드 +ㅁ+ 완성 ㅋㅋ
이번주 내내 작업했던 일은 3월달에 작업했던 이벤트를 리뉴얼 하는 작업이었다. 저번에 3월달에 작업할 때도 그냥 쉽게 생각하고 들어갔다가 만드는 데는 얼마 안걸렸는데 수정을 2,3주정도 했었었다. 작업기간을 다 합하면 한달 정도나 걸렸었던 이벤트였다. 툭하면 야근했고, 집에 돌아갔다가도 다시 돌아와서 작업해야되는 일도 많았었고, 이해할 수 없는 수정들을 계속해야 했던게 좀 힘들었었던 것 같다. 다른 동료들에게 그거 아직도 해? 라는 말을 엄청 들었었던 작업이다. 기간이 길고, 고충도 많았던 터라 3월 달에 이 일을 했던 기획자언니하고도 많이 친해졌었는데, 얼마전에 퇴사하고 다른데로 이직하면서 담당자가 바뀌었다. 이번엔 다른 기획자 언니인데, 역시 이 일하면서 꽤 친해졌다. (나만 그리 생각할지도..;)
그런데 이번 작업을 진행하면서 느낀점이 좀 있었다. 얼마전에 집에 있길래 본 책이 있는데 그 책 제목이 "불평없이 살아가기"라는 책이었다. 책에서 보면 자기가 긍정적이고 불평을 많이 안하는 것 같은 사람도 보면 하루에 꽤 많은 불평을 하면서 살고 있다는 것이 나와있었는데, 나도 그렇게 생각했었다. 나는 꽤 긍정적이고 불평을 별로 하지 않는다고 생각했었다. 근데 그게 아니라는 것을 이번 작업에서 깨달았던 것이다. 사실 이번 작업도 수정이 굉장히(!!!) 많고, 고치고, 고치고 고쳐야 했지만 저번보다는 별로 힘들지 않았다. 중요한 작업은 다 개발한 상태였고, 저번에 구조 짠것중에 맘에 안드는 부분을 수정하고, 주석을 친절하게 다 달면서 꽤 괜찮은 코드인데 혼자 자화자찬하면서 짜느라 재미있기도 했다.
문제는 기획자와의 친분(?)을 위해 어쩔수없는 불평을 해야만 했다는 것이다. 기획자와 공통적으로 통하는 부분일수 밖에 없는 클라이언트 욕하기를 엄청했었다. 솔직히 클라이언트 욕하기를 같이 하면서도 계속 머리속으로는 불평하고 싶지 않다를 외쳤던 것 같다. 그 책을 봤기 때문이기도 하고, 불평을 하면할수록 내가 피곤했기 때문이다. 별로 힘들지 않은 수정은 불평으로 인해 굉장히 짜증나는 일이 되었고, 인상을 쓰면서 수정을 하게 만들었다. 즐겁게 할 수 있는 일을 짜증내면서 하는 건 나에게 별로 좋지 않은 일이다.
그러고 보면 습관적으로 불평을 하는 일이 꽤 많다는 생각이 들었다. 특히 이번같이 친분을 위해 불평을 하는 일은 참 많다. 친구들을 만나면 경쟁이라도 하듯이 일이 힘들다를 외치고, 누군가를 욕하고, 나라를 불평하고, 그래야만 얘기를 할 수 있다는 듯이. 불평하는 것은 굉장히 쉽고, 내가 불평하면 주변사람들은 그 불평에 대해 맞장구를 쳐주며, 주위사람들의 친절을 받을 수 있다. 그 불평에 반대하더라도 말을 하지 말아야 한다. 그 분위기에 초를 치게 되는 것이니까. 그러나 그렇게 불평을 다하고 나면 기분은 좋을까. 좋지 않다 일이 해결되지도 않을 뿐더러 기분이 씁쓸하기만 하고 나를 더 불평의 구렁텅이에 빠지게 하는 일임을 알아야 한다.
책에 보면 이런 내용이 있다.
심리학자 로빈 코발스키 박사는 "불평은 대부분 다른 사람들로부터 동정이나 인정 같은 특별한 대인관계상의 반응을 얻어내려는 심리를 동반한다. 예를 들어 사람들이 자신의 건강에 대해 불평하는 것은 실제로 아파서가 아니라 아픈 사람이라는 역할이 그들로 하여금 동정이나 피하고 싶은 일을 안 해도 되는 것과 같은 부차적인 이득을 얻게 해주기 때문이다" 고 강조한다. 나는 뚱뚱하다는 사실에 대해 불평을 늘어놓음으로써, 즉 '뚱뚱하다'라는 카드를 사용함으로써, 동정과 인정을 받아냈고 여자아이들에게 말을 걸지 않아도 되는 핑계거리를 확보한 것이다.(67쪽)
21일 프로젝트에서 가장 중요한 것은 누군가가 불평하는 것을 듣게 되더라도 그러한 불평에 연루되어서는 안된다. 사람들은 자신들의 말로 당신의 동조를 끌어내고 당신 또한 그들의 동조를 끌어내려고 한다. 대화가 부정적인 방향으로 흘러가면 그저 묵묵히 지켜보라. 다른 사람을 변화시키려고 노력하지마라. 단지 불평없이 사는 사람이 되려고 노력하는 중이라고만 말하라.(100쪽)
또한 우리 자신이 불평을 하는 것은 위험을 감수하지 않기 위해, 해야 할 일을 하지 않기 위한 것이다. 그 경우 불평하는 것이 정당한 것처럼 보이지만 실제로 이러한 불평은 얄팍한 변명에 지나지 않는다.(114쪽)
나 같은 경우 친구들을 만나면 회사다니는 거 어때 하고 물어보면 항상 좋다고 그렇게 말한다. 일이 재미있다고, 회사도 좋고, 회사사람들도 재밌고, 회사다니는게 즐겁다고. 물론 그게 사실이기도 하다. 그러면 친구들은 하고 싶은 일을 하니까 좋겠다라던지 어떻게 일이 재밌다고 말할수 있냐고 신기하다고 말하곤 한다. 그래도 이런식으로 내가 먼저 긍정적인 얘기를 하게 되면 점점 대화는 생산적(?)인 대화가 많이 나오는 경우가 많았다. 자신이 하고 싶은 일이라든지, 목표라든지, 재태크에 관한거라든지, 요즘 열중하고 있는 일이라든지 그렇게 되면 친구들끼리 서로 정보도 공유하고 서로 격려하고 응원해주고 그랬던 것 같다. 물론 분이기가 항상 그렇지는 않고 나도 불평 많이 할 때는 많이 하긴 하지만 말이다.
결국 스트레스를 받던 나는 그 기획자언니랑 많이 말을 하지 않는 방향으로 바꾸기로 했다. 아무리 봐도, 내가 클라이언트를 불평해서 이득보는 일은 없다. 피곤하기만 할뿐이다. 그런거에 에너지를 쓰지 말아야겠다고 생각했고, 어제,오늘은 기획자가 울상을 지으며 나에게 수정사항을 가져왔어도 그냥 받고 아무말도 안하고 속으로 아무것도 아니다, 수정사항은 당연하다를 외치며 작업했다. 그제서야 마음이 좀 편안했다. 길게도 썼지만, 뭐 불평하면서 살지 말자는 얘기 , 불평하면 할수록 손해보는건 나니까^^;
글에는 친분을 위해 불평을 자주하게 된다는 얘기만 썼지만, 다른 좋은 얘기도 많은 책이다. 그냥 한번 보면 스스로 불평을 하면서 살지 말아야겠다는 생각을 심어주게 되는 꽤 괜찮은 책이다.
공부할 때 두가지 타입이 있는 것 같다.
모르는 것이 있으면 다음 단계로 넘어가지 않는 타입,
모르는 거 있어도 그냥 넘어가도 되는 타입.
나같은 경우는 후자인 편이다.
좋은 점은 공부할때 진도가 빨리빨리 나간다는 점,
그리고 전체로 모르는 것을 대충 추측할 수 있게 된다는 점이 있다.
하지만 하나하나 깊숙하게 공부되지 않는다는 단점은 있다.
프로그래밍 언어는 엄청나게 많고, 용어는 더 많다.
게다가 줄여서 쓰는 경우가 많기 때문에 그냥 사용하면서도 그게 뭘 의미하는 건데? 하고
물어보면 대답을 못하는 경우가 많은 거 같다.
내가 쓰고 있고, 대충은 알고 있다고 생각해도
용어정도는 한번 정리하고 가는 것이 좋을 것 같다.
이번에 플렉스 스터디 부분이 7장. 플렉스 데이터 연동 부분인데,
요 부분에서 모르는 용어가 꽤 많이 나왔다.
정확히는 많이 들어본 용어들인데, 설명하라고 하면 설명 못할 용어들..
그런 용어를 정리해 보려고 한다.
* 플렉스가 제공하는 데이터 연동방법은 크게 RPC 서비스방식과 데이터 서비스 방식으로 나뉜다.
연동방법
프로토콜
데이터 형태
서버 사이드 App.
BlazeDS
실시간메시징
RPC 서비스
Http
Service
HTTP
HTTPS
XML
PHP
ASP
JSP
XML
등 DB연결이 지원되는 모든 웹프로그램
선택적
X
Web
Service
HTTP
HTTPS
XML
SOAP 메시지
Web Service를 제공할 수 있는 시스템
선택적
X
Remote
Service
HTTP
HTTPS
AMF
JAVA객체(List,Map)
자바빈즈 클래스
필수
X
데이터
서비스
메시지 서비스
RTMP
AMF
JAVA객체(List,Map)
자바빈즈 클래스
필수
O
데이터 관리
서비스
HTTP
RTMP
AMF
JAVA객체(List,Map)
자바빈즈 클래스
LCDS만
가능
O
* RPC : 원격 함수 호출(Remote Procedure Call) - 정의 : 어떤 컴퓨터에서 떨어져 있는 다른 컴퓨터에서 작동하는 프로그램의 함수를 호출하여 실행결과를 리턴받는 것을 말한다.
- 방식 : 원격 함수 호출을 위해서는 네트워크를 통해 파라미터를 호출하려는 함수에 전달하고 지정된 포맷으로 결과를 리턴 받아야 한다.
- 종류 : 플렉스에서는 HTTP 방식과 WebService 방식, RemoteObject방식이 여기에 해당한다.
* HTTPService 방식 (RPC 방식_1) 브라우저에서 URL을 호출했을 때 XML 형식으로 데이터가 리턴이 되면 사용할 수 있는 방식이다. 즉, HTTP를 이용하여 데이터를 GET이나 POST 방식으로 웹서버로 전송하고 결과를 XML로 받는 방식을 말한다.
* WebService 방식 (RPC 방식_2) 브라우저에서 WSDL이 기술하는 WebService URL에 있는 WebService함수를 호출하고 그 결과를 SOAP(Simple Object Access Protocol) 메시지로 받는 방식이다. WebService는 HTTP를 기반으로 하여 결과는 [각주:1]SOAP라는 프로토콜에 맞춘 XML을 리턴하게 된다. WebService를 사용하게 할 수 있도록 서버가 제공하는 WebService의 위치, 메소드명,파라미터,리턴값을 정의한 XML 문서가 있어야 하는데 이것이 WSDL(WebService Definition Language)이다.
* RemoteObject 방식 (RPC방식_3) WAS(Web Application Server)에 디폴로이된 [각주:2]자바빈즈태그를 이용해 세팅하면, 파라미터들이, 자동으로, 빈즈에 담겨 사용할수 있게 된다. EJB에서는 EJB 스펙을 따르라 빈즈를 만들면 원격으로 빈즈에 담은 데이타를 보내고 받을수 있게 된다. ">자바빈즈로 만들어진 메소드를 호출하여 그 결과를 객체형식으로 리턴받는다. 서버측의 Java Object를 호출하여 그 결과를 AMF(Action Message Format)라는 Binary 형식으로 통신하며 Java Data Type과 ActionScript3 Data Type과 바인딩 해서 사용한다. RemoteObject 은 위 두방식이 XML을 기반으로 데이터를 처리하는 것과 달리 객체 배열의 구조를 갖는 바이너리데이터를 처리한다. 따라서 다른 통신방식에 비해 데이터 처리 속도가 빠르고, 속도가 빠르기 때문에 클라이언트에서 수만 건에 이르는 데이터를 가져와 처리하는 애플리케이션을 만드는 데 적당하다.
데이터서비스 방식
클라이언트에서 서버를 호출해야 데이터를 받을 수 있는 RPC방식과는 달리 서버에서 [각주:3]푸쉬하는 데이터가 클라이언트에 전달될 수 있다. 즉, 클라이언트가 화면을 새로고침하지 않아도 서버에서 특정 이벤트나 지정된 시간마다 데이터를 보내어 화면이 자동으로 업데이트 된다. 클라이언트 호출방식에서 구현하지 못했던 모니터링 서비스나 이벤트 알리미 서비스 등 인터랙티브한 서비스를 구현할 수 있다. 또한 대량의 데이터를 처리함에 있어 사용자가 페이지를 열 때마다 모든 데이터를 가져올 필요 없이 작동하는 아키텍처를 구성할 수 있다. 또한 화면 로직과 데이터 로직, 컨트롤 로직이 분리되어 프로젝트를 좀더 효율적으로 진행할 수가 있다.
메시지 서비스
데이터 관리 서비스
데이터 관리 서비스는 클라이언트와 서버간에 데이터를 동기화하기 위해서 개발자들이 수작업으로 코딩하던 번거로움을 없애고 클라이언트가 변경한 데이터를 즉시 반영해서 볼 수 있도록 했다. 이를 위해서 DataService라는 클래스를 도입했고 여기에는 데이터를 동기화하기위한 다양한 메소드들이 구현되어있다.
* 서비스들의 차이점들 비교하기
1. RPC 서비스 / 데이터 서비스
RPC 서비스는 서버에 데이터를 요청하지 않더라도 서버로부터 데이터를 푸쉬 받을 수 있는 실시간 메시징이 가능하지 않다. 2. HTTPService / WebService / RemoteService 각각 유저화면에서의 특정이벤트가 각 RPC Components를 통해서 Request가 만들어지고 HTTP Service의 경우에는 HTTP포멧(GET or POST)으로 전송되고 Web Service의 경우 SOAP로 전송되며 RemoteService의 경우에는 바이너리 형식의 AMF로 전송되어 Java Object, XML, TEXT등의 데이터로 Response를 전송 받아 클라이언트에서 처리한다. 3. HTTPService,WebService / RemoteService
앞의 두가지는 XML기반으로 데이터를 처리하지만 RemoteService는 바이너리 데이터를 처리한다. 그렇기 때문에 XML보다는 통신 패킷량이 적고 네트웍 전송 속도가 훨씬 빠르다.
2010 04 19 - 여러가지 신경쓰이는 게 너무 많은 날이다. 스트레스 받아서 죽는 줄 알았다. 내가 원래 그렇게 여러가지 신경쓰면서 그런스타일 아닌데.. 그런점에서 항상 내 스스로 B형같다고 느끼는 점인데, 오늘은 좀 이상했다. 몸도 안 좋아서 더 그랬었던 것 같다. 6시 땡치고 대충 정리하자마자 집에 들어가서 침대에 누워버렸다. 그리고 나서 두시간 뒤에 전화가 오고, 결국 하나씩 해결이 되고, 그러면서 괜찮아졌던 거 같다. 그러고보니 오늘 첨으로 지각을 1시간이나 하고, 그런날이었나보다..
2010 04 20 - 하루종일 RND를 할 수 있는 날은 참 좋다. 오늘 2주차 플렉스 숙제를 대충 끝냈음. 플렉스는 쉬운듯하면서도 어렵다. 근데 플래시와 다른점 몇가지 정도를 확실히 공부해두면 그 다음부터는 더 쉬울 거 같다. 검사 프린세스의 영향인가 밥을 먹는게 조심스럽다. 아침이라서 더먹어야되, 저녁에 안먹을라면 먹어둬야지 이런 생각도 많이 했었는데 생각을 바꿨다. 억지로 먹을필요는 없지 뭐.. 하지만 건강은 조심, 나중에 더 큰 화를 불러올수도 있을테니.. 요즘엔 혼자 집에 가서 밥을 먹는게 쓸쓸하다는 생각도 들긴 하는데, 돈 아끼고 다이어트에, 좀 쉴수 있는 나만의 시간이라 포기하고 싶진 않아서 그냥 계속 그러고 있다. 하나를 잃어도 여러가지는 얻고 있으니까.....
2010 04 21 - 6시 반에 일어났다. 일어나자마자 아이폰으로 TED틀어서 그냥 앉아서 듣고 있었다. 예전에 책에서 봤는데 사람의 수면싸이클이 3시간 간격이라서 3시간 간격으로 잠을 자는 게 제일 좋다고 하던데, 그러니까 3시간 혹은 6시간,9시간 정도로 자면 푹 자는 거라고... 딱 6시간 잤다. 저절로 눈이 떠질때 일어나면 피곤한것도 덜 한것 같고 ㅎ 오늘은 회사에 8시 10분에 출근, 빨리 일어나니까 좋다. 하지만 또 이렇게 일찍일어날지는 모르겠다. 최근에 나는 잠순이처럼 잠 엄청 자니까..
studywork_day01.fxp 파일을 올려놓았습니다. 플래시빌더에서 import해서 보시면되요.
플렉스 스터디 1주차 숙제 주제 : 간단한 콤포넌트를 사용한 Hello Flex 경고창 띄우기 또는 이와 흡사한 프로젝트 생성하기
첫주차라서 간단한 alert창을 띄우는 것이 과제였다. 목요일까지 까페에 숙제를 해서 올렸어야 했는데, 수요일,목요일 내내 플래시빌더를 여러가지 셋팅을 하느라고 숙제를 하지 못한 상태였다. 겨우 목요일날 셋팅을 어느정도 마쳤다. 원래는 저번에 배웠던 거를 이용해서 서버(BlazeDS, mysql , 톰캣아파치 ... 등등)을 함께 설치, 플래시빌더를 먼저 설치하고 그 위에 갈릴레오 플러그인을 설치하는 방식으로 했다. 하는 도중에 한가지 문제가 생겨서 못했고.. 그건 나중에 성공한다음에 포스팅을 할 생각이다.
이번 숙제는 여러가지 컴포넌트를 써보고, 그냥 컴포넌트를 쓰는게 아니라 여러가지로 변형해보면서 쓰는 것이었는데, 또 숙제는 상관없이 드래그앤드랍 부분을 해보고 싶어서 요걸로 숙제했음
이번엔 xml을 가져와서 데이터그리드에 바인딩 해주었고, 데이터그리드에 선택을하면 사진을 미리볼수 있게 연동해놨고,
데이터그리드는 드래그앤 드랍이 되서 장바구니에 드래그해서 넣으면 총가격과 갯수가 나타난다.
저번엔 삭제를 뒤에서부터만 하게 되있었지만, 이번엔 선택한 아이템을 삭제하게 했다.
좀 고생했던 것은 데이터그리드에 있는 데이터를 리스트에는 이름만 갖고 오는데,
가격 계산은 따로 해줘야된다는 점이다.
그래서 저 가격을 어떻게 접근해야하는지에 대해서 고민했었다.
방법은 나중에 포스팅할 예정.. (내가 제대로 했는지 모르겠네;)
할려다 안한게 있는데 사진을 드래그 앤드랍할려고 했다. 사진은 드래그를 허용하지 않는 컴포넌트이기 때문에
조금 다른 방법이 필요하더라. 그건 다음번에~
2010 04 14 AM 10 : 37 - 아이폰에서 유명한 게임. We Rule을 시작했다... 중독성 강하다 ; 어제 저녁에 계속 폰만 붙들고 있었음..
2010 04 14 - 안드로이드 스터디 하는 날. 오늘 왠지 모르게 기운도 없고 스터디 집중도 안되고.. 발표 다 듣고 나서 어짜피 선릉이니까 언니한테 연락해봤다. 왠지 술도 먹고 싶고, 결국 봤는데 6개월만에 본거였다. 언니랑 있으면 편해서 좋다. 얘기도 많이 했고, 언니가 좀 염장을 많이 지르긴 했지만 ㅎㅎ 덕분에 기분이 괜찮아 진듯
2010 04 16 - 대청소. 동생이 집에 내려가서 혼자 살게 됬다. 그래도 짐은 완전 그대로고, 분명 예전 집보다는 넓은 집인데 짐이 너무 많은듯. 이리저리 가구도 옮겨보고 하면서 청소했고, 결국 컴퓨터 책상은 밖에 내놨다. 배치는 맘에 드는데, 완벽하게 청소하지는 못했다. 혼자살아도 깨끗하게 살아야지..
2010 04 17 - PFG 세미나 갔다왔다. 강남역에서 6번출구쪽으로 걸어가고 있는데 낯익은 목소리가 들려서 보니 플스언니들 ㅎ 또 같이 가다가 커피사고 가는데 보이는 낯익은 뒷모습. 또 플스 사람~ 역시 서로 얘기 안하고 와도, 이런데서 만날수도 있고 좋았다. 세미나는 좋았다. 요즘 이런 세미나, 스터디 가는 것이 참 좋은 거 같다. 같은 분야의 더 열심히 일하고 더 위에 있는 사람의 에너지를 보게되서 좋고, 사람들도 알게되서 좋고 ㅎ 나도 더 열심히 해서 나중엔 나도 발표자가 되 바야겠지. 오늘 신기했던 거. 뒷풀이 갔는데 내가 제일 어리더라. 친구들끼리는 이제 우리 많이 늙었다고 이러는데, 아직 사회에서는 어린나이인가보다 ㅋ
2010 04 18 - 오늘 우리집에서 두탕. 점심때 대학교 친구 한명 와서 집에서 떡볶이 해먹고 드라마보고, 저녁에 고등학교 친구와서 낙지볶음이랑 우동 해먹고 얘기하다 가고, 주말이 완전 빨리갔다.
PM 03:30 - 플래시 빌더 공부한 것에 대한 블로그 글을 처음으로 써봤다. 제대로 설명하는 것이 은근 어렵구나. 시간도 꽤 많이 걸리지만 그래도 뭔가 보람은 있는 듯. 점점 스터디에 배운 내용들이랑 숙제한거 내용채우고, 작업하면서 있었던 문제 해결방안 같은것도 작성되면 괜찮을듯.
PM 04:27 - 캘린더를 또 다시 바꿨다. 원래 네이버 캘린더 쓰다가 이번에 아이폰에서 보기 위해 구글 캘린더로 바꿨었는데, 내가 필요한 기능도 부족하고, 아이폰에서 보이는 게 별로 좋지 않아서 이번엔 다음 캘린더로 바꿨다. 제일 맘에 드는 기능은 링크 기능이고, 메모를 써 놓으면 바로바로 볼 수 있다는 점이 좋은것 같다. 나는 최근에 기록정리병이 생겼는데, 캘린더를 기록하는 것도 그것 중의 하나다. 뭔가 내가 한일과 해야 할일을 제대로 봐야만 하는데, 아직도 기록정리는 진행중이다. 노트도 jwfreenote 에서 담비노트로 바꾸고 jw노트에서 정리한거 다시 담비노트로 정리하고, 그것도 별로 맘에 안들어서 어떻게 제대로 정리할 수 있을지 고민중이다. 우선 캘린더도 써보고 또 바꿀지도..
PM 04:35 - 회사 내 개인 컴퓨터 상태가 심각하다. 내 노트북보다 훨씬 느릴정도면... 언제 백업을 하고 다시 설치를 해야할지도 모르겠다.. 느려서 못쓰겠어 ㅠ_ㅠ
PM 05:21 - 방금 다음 캘린더를 Exchange 할수 있다는 걸 알게되서 연결했다. 완전 좋음
PM 07:42 - 한가지만 공부하면 그 것에 너무 매어서 제대로 된 생각을 못할수도 있고, 질리기 마련인데.. 여러가지를 공부함으로써 하루종일 여러가지를 지루하지 않게 조금조금씩 공부할 수 있고, 서로 시너지를 내고 있는데.. 흥.. 꼭 제대로 된거 만들어서 그런소리 안나오게 만들겠어. 물론 정말 끝까지 꾸준히 공부해서 이것 저것도 아닌것으로 만들지 않게 노력해야지
③번 부분의 데이터 지우기를 클릭하면 하나씩 지워지고, 모두 지우기를 클릭하면 모두 사라진다.
데이터 그리드 부분의 데이터 바인딩 부분은 "예제로 배우는 플렉스" 개정판 책의 213Page 부분을 보고 만들었다. 플래시빌더4로 오면서 그 부분에서 달라진 부분이 있는데 그건 아래에서 설명하도록 하겠다.
1. Data/Services기능을 사용해서 구글 날씨 API 데이터를 가져오기.
플래시 빌더 화면 아래에 보면 Data/Services라는 탭이 있다. 보이지 않는다면 Window > Show View 에 Data/Services를 선택하면 된다. 위 화면의 빨간색 네모 부분을 클릭한다.
요런 화면이 나오면 HTTP 클릭
데이터를 받아올 서비스의 이름을 정하고, URL을 적고, 파라미터를 정합니다.
받아올 리턴타입을 정해야 하는데, 저는 forecast_information에 있는 데이터와 current_conditions 에 있는 데이터를 가져올 것이므로 리턴타입을 weather로 정했습니다. 나중에 접근하는 방법은 weather.forecast_information.city.data 이런 형식이 될 것입니다.
화면에 데이터 그리드를 가져다 놓고, 마우스 오른쪽을 클릭해서 Bind to Data를 클릭한 후 Data provider를 Weather로 입력
Data provider에 보면 {getWeatherResult.lastResult}를 확인할 수 있다. Configure Columns 를 클릭해서 데이터 받아오는 것을 제대로 수정한다. Header text는 위에 보여질 이름이고. Bind to field에 forecast_information.city.data 이런식으로 적어주면된다.
이렇게 되면 데이터를 가져오는 것을 바로 확인할 수 있다.
다음 포스트에서는 도시를 클릭하면 그 도시의 데이터를 가져오는 방법에 대해서 보여드립니다~
주말 - 토요일에는 오전에 스터디 갔다가 스터디 끝나고 고속터미널 가서 햄버거 먹고, 전주 도착하고 나서 가족 다 같이 모여서 삼겹살을 먹고, 일요일에는 여동생 졸업옷사러 가는 데 따라갔다가, 오랜만에 고등학교 친구들을 만났다.
같이 밥먹고 커피먹고, 포켓볼도 쳤다. 그리고 저녁에 다시 집에와서 밥을 먹고 7시50분 차를 타고 서울에 올라왔다.
엄청 막힌다고 하길래, 제시간에 못 도착할줄 알았는데 다행이 기사님이 빠르게 와주셔서 11시 30분정도에 도착. 그래도 주말이라 차가 일찍 끊기는 바람에 딱 서울대입구역까지만 막차로 가서 택시타고 신림까지 왔었다.
PM 02:00 - 몸이 너무 피곤하다. 정말 오랜만에 피곤한 주말을 보낸 듯. 그래도 점심시간에 집에가서 한시간 정도 잤더니 좀 나아졌다.
PM 03:30 - 떡볶이가 너무 먹고 싶다
PM 08:00 - 오늘 집에서 피곤하다고 잠을 얼마나 잔건지... 오늘은 정말 아무것도 하기 싫은 날이다
11:28 - 드디어 티스토리에 블로그를 만들었다 !
nicekon 님 정말 감사합니다 ^^
블로그 이번엔 제대로 시작해 봐야지
20:30 - 얼마전에 엄진영의 BlazeDS 따라하기 세미나를 갔었다. 플렉스는 해야지만 생각하고 있었는데, 이 세미나를 갔다온 후 제대로 해봐야겠다는 생각이 들었었다.
특히 좋았던건 정말 들어만 봤던 생소한 용어들과 언어,프로그램들을 그 언어가 어떻게 되서 나오게 됬는지, 어떻게 쓰이는 지를 쭉 훑을 수 있어서 좋았고, 어려운 셋팅을 처음부터 해주어서 좋았다. 막판에 시간이 부족해서 끝까지 셋팅 못한건 아쉽지만 말이다. 다음에 한번 다시 세미나 해주신다고 했는데 언제가 되려나 .
이번에 노트북을 포맷하고 새로 설치하면서 다시 셋팅을 처음부터 해보고 있는데, 이클립스에 플러그인으로 FlashBuilder를 깔았던 것을 FlashBuilder에 이클립스플러그인으로 깔면서 엄청나게 해메이고 있다. 다른 사람들은 뭐하러 서버까냐고 그러고 ㅠ_ㅠ . 꼭 성공해서 제대로된 셋팅 폴더를 공유하고 싶다. 그리고 벌써 가물가물해진 용어들을 다시 인터넷으로 찾아보고 정리해야겠다.
20:50 - 그나저나 플렉스 숙제 해야되는데, 셋팅도 다 못해서 큰일이다. 숙제는 간단한건데, 그래도 너무 간단하게 하고 싶지는 않고.. 욕심만 많아가지고는..
21:00 - 공부는 하면 할수록 계속해서 더 해야 할것들이 생긴다. 좋긴 좋은데, 나아지고 있는 거 맞겠지?