2008년 12월 23일 화요일

공개 소프트웨어 공모대전

대학 재학시절 동안 남들은 많이도 나가는 공모전이라고는 한번 나갔다가 탈락했던 기억뿐입니다. 그것도 소프트웨어 공모전이 아니고 마케팅 공모전을 준비했었던터라 어쩌면 당연한 탈락이 아니었나 생각도 합니다.

4학년 생활도 끝을 보이던 시기인 지난 10월 전 우연히 알게된 공모전에 참여를 했습니다. 예선과 본선 경쟁 프리젠테이션을 마치고 수상권이라는 말은 들었지만 예상보다 좋은 결과를 얻게 되어 더욱 기분이 좋았습니다. 

혹시나 이와 같은 대회를 준비하시는 분께 도움이 될까 제가 본선에서 이용했던 슬라이드를 올려놓습니다. 필요하신 분께 도움이 되었으면 좋겠습니다.

한양대 문병원 최종
View SlideShare presentation or Upload your own.

2008년 10월 8일 수요일

구글 서머 오브 코드 2008 경험 공유회를 마쳤습니다.

지난 포스트에서 말씀드렸던 것처럼 지난주 수요일에(10월 1일) 학교 공학관의 강의실을 빌려서 경험 공유회를 열었습니다. 1시간 동안 자료를 정리한 프리젠테이션을 하고 질문/답변 시간을 가졌습니다.

생각보다 많이 참여해주셔서(주로 학회 후배들었지만 ^^) 조금 놀랐는데요, 후배들이 포스터까지 멋지게 만들어서 붙여준 덕분이라 생각하고 있습니다. 약속했던 것처럼 동영상을 찍지는 못했지만(프로그램 사정상 조금 힘들었습니다) 발표에 사용했던 자료를 PDF로 변환해서 올립니다.

자세한 내용이 들어 있는건 아니라서 추가적으로 궁금한게 있으신분은 이곳에 코멘트를 달아주시거나 제 메일로 문의사항을 보내주시면 답변 드리도록 하겠습니다.

Google Summer Of Code 2008
View SlideShare presentation or Upload your own. (tags: jaram. gsoc)

2008년 9월 30일 화요일

Google Summer of Code 2008 경험 공유회를 합니다

Steve Jobs from Getty Images

Photo: Getty Images

내용와 아무런 상관이 없는 사진이지만, 잡스의 프리젠테이션을 목표로!

2008년 구글 서머 오브 코드(이하 : GSoC)에 참여했던 경험을 공유하려 합니다. 주로 이야기 할 내용은 아래와 같습니다.

  • Google Summer of Code 는 어떤 행사인가?

  • 참여하기 위한 방법 (프로젝트 선택하기, 지원서 준비하기, 서류 준비하기, 프로젝트 진행하기 등)

  • 참여 후 얻은 것들


"저는 이런 이런 것들을 했습니다"라는 방식의 손주한테 이야기가 아니라 실질적으로 참여를 권유하고, 참여하는 방법을 상세하게 알려주는 자리가 되도록 하려고 합니다. 이 시간을 통해서 내년 GSoC 2009에 우리나라의 많은 분들이 참여를 했으면 합니다.

원래, 제가 속해 있는 대학 소프트웨어 학회에서 내부적으로 하려다가 이번에 우리 학교에서 학술제를 하기에 학술제에 공개세미나 형식으로 하기로 했습니다. 비록 학교의 행사중에 하나로 하기는 하지만, 외부의 어떤 분이라도 참여를 환영합니다.

진행 방식은 1시간 정도의 위의 이야기할 내용에 대한 프리젠테이션과 이후 30분 정도의 질답이 있을 예정입니다. 학교가 안산에 있는 탓에 혹시나 관심 있으신 분들이 직접 오시기가 쉽지 않을 텐데, 세미나를 녹화해서 공개할 생각이니 제 블로그나 학회 홈페이지를 관심을 가지고 살펴보시면 될 것 같습니다.

일시 : 2008년 10월 1일 수요일 (오후 1시)

장소 : 한양대학교 안산캠퍼스 제1공학관 104호

문의 : 016 682 8198 (문병원)

2008년 9월 29일 월요일

Google Summer of Code 2008 : 지원하기

일단 행사에 지원하기 위해서는 언제 지원을 할 수 있는지를 알아야 합니다. 당연한 말이지만요.

행사 일정을 확인하기

일정을 파악하기 위한 가장 좋은 방법은 공식홈페이지에 자주 들리는 것입니. 하지만, 전 구글캘린터Google Summer of Code(이후:GSoC) 일정을 구독해서 활용을 하는데 이 방법이 더 좋은 것 같습니다. 단순히 응시기간뿐 아니라 응시과정 그리고 행사 전반의 일정들도 표시됩니다. 이를 이용해서 합격한 이후에도 개발과정의 일정도 확인하고 관리할 수 있습니다. 자신의 구글캘린더나 일정관리 프로그램에 GSoC의 일정을 넣기 위해서는 구글 캘린더에서 공개 캘린더 검색으로 summer of code로 검색을 하거나 Atom Feed형식의 데이터를 참고하면 됩니다.

행사에 지원하기

그렇게 모집 기간이 다가왔다면, 지원을 하면 되겠죠. 그 전에 자신이 행사에 참여할 수 있는지 확인해야 합니다. SoC에는 현재 대학에 재학중인 학생만 참여할 수 있습니다. 학부, 학사, 박사 등 학위 과정은 상관은 없는데요. 합격 후 자신이 재학중이라는 것을 증명하는 서류를 제출해야 하니만큼 재학생만 참여가 가능합니다.

재학생이라면 GSoC모집 기간에 GSoC홈페이지에 접속하면 신청 방법과 신청 경로를 찾을 수 있습니다. 첫페이지에 링크되어 있는 FAQ를 자세히 읽어보는 것이 도움이 될거라 생각합니다. 신청과 이후의 과정 모두에서 말이죠.

홈페이지의 첫화면 하단에 수많은 단체들의 목록이 있을겁니다. 각 단체들마다 내 놓은 프로젝트들도 적게는 2-3개에서 10개가 넘는 경우도 있습니다. 그중에서 자신이 지원서를 낼 프로젝트를 선택하는거죠. 시스템상 20개의 지원서를 낼 수 있지만, 현실적으로 20개나 되는 지원서를 쓰기도 힘들고 그럴 필요성도 없다고 봅니다. 맘에드는게 몇개가 있다면 자신이 가능한 한도에서 2-5개 정도의 지원서를 제출하는게 좋을 것 같습니다. 전 게을러서 한개만 썼네요.

더 참고할 것

지원서를 작성하는 전략에 대해 재밌고 영양가 있게 장혜식님께서 정리해 주셨는데 지원 생각하시는 분들을 읽어보시면 좋을 것 같습니다.

2008년 4월 24일 목요일

Google Summer of Code 2008 : 시작하기

Google Summber of Code 이라는 행사에 대해서 (이하 Soc) 들어본 분도 계시고 처음 듣는 분도 있을 겁니다. 일단 SoC가 무슨 행사인지 설명하자면;
구글에서 오픈소스 개발 단체들을 지원하여 여름 방학 동안 해당 단체의 프로젝트의 일정 작업을 학생들의 참여로 해결할 수 있도록 돕는 행사. 참여한 학생들에게는 최대 $4500의 돈이 지급된다.


한마디로 구글에서 돈을 줘가면서 오픈소스 프로젝트를 돕는 그런 행사인데요. 이미 3-4년은 된 행사이니만큼 어느 정도 규모도 커져서 2008년 현재 174개의 단체들에서 각자 3-10개 정도의 해결과제를 제시하고 있습니다. 이 과제들에 학생들이 참가서를 제출해서 단체의 멘터들이 참여여부를 결정하는거죠.

SoC를 처음 알게 된 것은 시작을 하던 2005년 부터인데 참여하고 싶었지만, 2005년 11월에 입대를 하느라(혹은 그 당시 회사를 다니느라) 하지 못했습니다. 군복무 중에도 행사를 눈여겨 보다가 이번에 복학을 하고 4학년으로 학교를 다니면서 얼마전에 지원을 했었는데 해당단체(MoinMoin Proejct)에서 제가 지원한 FCK Editor Improving 이 통과되었다고 메일이 왔네요.

하던 아르바이트들이 몇개가 있어서 정말 치여가며 작성했던 참가서이고 제가 봐도 부끄럽기만 한데 MoinMoin팀에서 잘 봐주신 것 같습니다. 이제 열심히 해야죠. ㅜㅜ 할일을 생각하니 앞길이 막막..

여튼, 준비를 하면서 새롭게 알게 된것도 많고 저와 비슷한 행사들이나 다음번 SoC 참여를 준비하시는 분들을 위해서 조만간 SoC를 준비하는데 알아야 할 것들과 제가 준비했던 것들을 정리해서 올리겠습니다.

Have a nice day :-)

2008년 4월 4일 금요일

Motion Picture Screensaver

예전에 Apple의 OS X을 처음 봤을 때, 가장 인상 깊었던 것은 미려한 인터페이스 디자인이었습니다. 그리고 또 다른 인상 깊었던 것이 슬라이드쇼였습니다. 제가 말하는 대상은 정말 단순한 슬라이드쇼인데요. 그림이 한장 한장씩 바뀌면서 표시가 되는거죠. 얼핏보면 정말 단순한 작업입니다. 물론, 생각한큼 단순한 작업이기도 하구요. 그런데 OS X의 그 작업은 뭔가가 달랐습니다. 단순히 이미지가 변경되는게 아니라 그 중간에 변경되는 효과, 이미지가 보여지는 효과가 달랐습니다.

그때는 그 효과를 뭐라고 말해야 할지 몰랐는데 뒤져보니 moving slideshow정도로 말하면 될 것 같습니다. 여튼 그 효과가 굉징히 인상 깊었는데, 윈도우에서 그런 효과를 내주는 프로그램이 없나 뒤지다가 motion picture screensaver라는 걸 찾았습니다. 화면보호기 말고도 그림을 보여주는 다양한 곳에서 사용할 수 있을 것 같은데, 일단은 화면 보호기네요.

설치 방법은 간단합니다. 일단 이곳을 클릭해서 프로그램을 다운로드 하시고, 받은 압축파일을 열어보면 디렉토리가 하나 보이는데 들어가보면 여러 파일들이 보입니다. 그 중에 MotionPicture.scr 라는 제목의 파일을 마우스 오른쪽 버튼으로 클릭하고 나오는 메뉴에서 설치를 선택하면 설치가 완료됩니다.

바 탕화면에서 마우스 오른쪽 버튼을 클릭 후, 나오는 메뉴에서 속성을 선택하면 창이 하나 뜨는데 거기서 화면보호기를 선택하면 아까 설치한 화면 보호기가 보입니다. 설정을 누르면 아래와 같은 메뉴가 나옵니다. 오른쪽 중간 즈음에 File Settings 라는 제목의 부분에서 원하는 사진이 있는 디렉토리를 선택하면 화면보호기에 그 사진으로 구성된 슬라이드쇼가 출력됩니다.

단순하지만 굉장히 멋있으니 즐겨보세요~

Motion Picture Screensaver Preference

2008년 4월 3일 목요일

Daum Dev Day 2008 : 열정 그리고 재미

DevDay에 대한 감상


지난주 토요일에는 비가 주룩주룩 내렸지만, 비와는 상관 없이 기분이 좋았습니다.

다음에서 주최한 Dev Day 2008이라는 행사에 다녀와서 그런데요. 한나절 동안 개발자들이 모여 OpenAPI를 이용하여 다영한 프로그램을 만드는 행사였습니다. 50명이라는 많지는 않은 인원이었지만 정말 활발하게 개발을 해서 6시간정도의 개발 시간 동안 20여개의 작품들이 만들어졌습니다.

일단, 생각보다 대학생들이 많이 와서 놀랐구요(저도 대학생이었지만). 그 중 상당수가 숭실대인 것에 놀랐습니다(한양대도 좀 오지..). 아무래도 직장인들의 참여가 적은 것은 황금같은 토요일 오전, 오후가 행사시간 이었기 때문일 것 같은데요. 저도 예전에 회사 다닐때는 토요일에 집에서 뒹굴거리면서 자는게 젤 좋았던 기억이 있는데, 그것 때문에 직장인들이 참여를 적게 한게 아닐까 생각되네요.

행사는 오전 10시에 시작해서 30분정도 각자 소개를 간단하게 하고 1시간 가량 준비해온 프로그램을 만들고 점심을 먹고 다시 5시 좀 넘게까지 프로그램을 만들고 마지막에 제작한 것들을 발표하는 형식이었습니다. 그 중에 옆에 만든 작은 공간에서는 작은 세미나 같은 형식으로 발표가 이루어지고 있었구요. 개발을 하는 공간에서는 자유롭게 팀을 이루어서(혹은 이미 만들어온 팀에서) 프로그램을 만들었습니다. 전 학교 후배 두명이랑 갔었는데 계속 프로그램을 만들다가 마지막 튜토리얼만 잠시 들을 수 있었습니다.

제가 했던 것은 대학에서 활도하고 있는 전산전공학회인 자람이라는 단체의 새로운 홈페이지 중에 위젯기능이 있는데 거기에 사용될 위젯을 만드는 일이었습니다. 일단 OpenAPI를 이용하여 프로그램을 만드는게 행사의 목적이었던 만큼 평소 하던 것 중에서 관련된 것을 찾다보니 위젯이 생각났고 후배 두명과 함께 위젯들을 만들면서 시간을 보냈습니다.

그런데, 처음부터는 위젯 구동 시스템을 세팅하는데 30분이 넘게 걸렸고, 전역 후 간만에 소스를 만지다보니 또 적응하는데 시간이 걸려서 이런 저런 시간 낭비가 많았습니다. 또, 후배들은 처음으로 PHP를 써보는거라서 이것저것 가르쳐주고 찾아보면서 개발하다보니 위젯 2개 정도 밖에 만들지 못했네요.

그래도 같이 모여 즐겁게 프로그래밍하고 서로 만든 결과도 보면서 열정을 나눌 수 있었고 재미도 많았습니다. 무엇을 했는가보다는 어떻게 했느냐가 더 중요한 거겠죠.

결과물


RSS Reader Widget

rss_reader_1.png

Weather Widget

weather_1.png

2008년 4월 2일 수요일

Origin of A* Algorithm

오늘 인공지능 수업 을 들으면서 A*알고리즘 에 대해서 배웠는데, 수업 중간에 문득 한가지 의문이 떠올랐습니다.
A* 알고리즘 이라는 이름을 지었을까?

점점 궁금해지더군요. 결국 교수님께 물어보긴 했는데 교수님도 그 유래는 잘 모르셔서 제가 한번 알아봤습니다.

일단 위키피디아의 A*알고리즘 페이지 를 살펴보니 처음으로 이 알고리즘이 소개 된 것은 1968년에 한 논문 을 통해서였습니다.

The algorithm was first described in 1968 by Peter Hart, Nils Nilsson, and Bertram Raphael. In their paper, it was called algorithm A. Since using this algorithm yields optimal behavior for a given heuristic, it has been called A*.

- from wikipedia A* Algorithm page

"A Formal Basis for the Heuristic Determination of Minimum Cost Paths in Graphs" 라는 제목의 논문 이었는데요, 간단히 말해서 "그래프 상에서 최소 비용의 경로의 휴리스틱 결정을 위한 기초 원리" 정도로 해석할 수 있겠습니다. 논문의 내용들이야 A*알고리즘에 대한 일반적인 설명(지금 시점에서는요)이지만 한가지 눈여겨 볼 부분이 있습니다. 논문 2페이지의 오른쪽 단의 하단 부분에 아래와 같은 내용이 있습니다.

We call an algorithm admissible if it is guaranteed to find an optimal path from s to a preferred goal node of s for any 8 graph. Various admissible algorithms may differ both in the order in which they expand the nodes of G, and in the number of nodes expanded.

- from "A Formal Basis for the Heuristic Determination of Minimum Cost Paths in Graphs", page 2

인용문의 강조 표시는 제가 했습니다. 바로 강조 표시된 부분이 유래라고 설명 될 만한 부분이죠. 일단 A*의 A가 어디서 유래했는지는 알 수 있게 되었습니다. admissible 이라는 단어에서 유래한거죠. 사전에서 그 뜻을 찾아보면 "자격이 있는" 정도로 해석되는데 적합한 혹은 최적이라는 정도의 뜻으로 이해하면 될 것 같습니다. 왜 그런 이름을 붙였는지는 모르겠지만, 일단 위키피디아에 언급된 algorithm A는 알게 되었죠. 그리고 위키피디아에 언급된 것처럼 논문에서 A*라는 단어가 처음으로 언급되는 부분은 algorithm A라고 명명했던 알고리즘에 휴리스틱한 함수를 사용하도록 하면서 A*라고 부르게 됩니다.

결론은 그냥 A 알고리즘의 발전형이라서 A*라고 부른 것 같네요.

2008년 3월 17일 월요일

프로그램 그려보기

김진애님의 자기 집을 그려보자 라는 글을 보면서 문득 소프트웨어를 설계할 때도 사용할 수 있는 방법이다 라는 생각이 들었습니다. 제가 관심을 가지게 된 부분은 이 부분인데요.

주택을 설계할 때면 나는 집주인을 유혹하곤 한다. 같이 그려 봅시다 하고. 직업상 나는 남들이 말로 표현하는 것 또는 몸으로 표현하는 것을 잘 파악해서 그림으로 그려 내는 사람이지만 살 사람의 마음 깊은 속, 심리 깊은 속까지 들어가기란 그리 쉽지 않다. 이럴 때 집주인이 뭔가 그려 주면 훨씬 더 가깝게 짐작할 수 있다. 힌트가 풍성해지는 것이다.집주인은 쑥스러워들 한다. “못 그려요.” 그려 보고 나서는 “그리기 만만치 않데.” 하기도 한다. 내가 권하는 것은 건물의 형태나 전체의 구성은 아니다. 이것은 아무래도 어려운 일이고 전문적인 훈련이 필요하기 때문이다. 권하는 것은,

주로 집 내부의 가구 배치, 컴퓨터 배치, 텔레비전 배치 같은 것들이다. 전문가인 나보다도 집주인이 훨씬 더 잘 아는 물품들, 습관들, 선호도가 나타나는 항목들이다.



그러니까 집을 설계할 때 집주인과 함께 그가 정말 원했던 것을 알아가는 과정의 일종으로 좀 더 직관적으로 생각할 수 있는 집의 내부 같은 부분을 그린다. 라는 것인데요. 이 과정의 진정한 가치는 집주인이 단순히 자신이 생각했던 것을 그림으로 표현해서 건축가에게 전달하는게 아니라, 그림을 그리는 과정을 통해서 자신이 인식하고 있지 않았던 혹은 자신도 몰랐던 원했던 것을 발견할 수 있다는데 있는거죠. 그리고 그런걸 발견하지 못할 수도 있지만 집을 짓는 과정의 초반부터 참여하는 것은 집을 짓는 다는 일종의 프로젝트에 대한 참여도와 소속감을 높일 수 있을 것 같구요. 뭐, 물론 이 경우는 자신의 집을 짓는 것이지 당연히 그런게 높겠지만 말이죠.

이제 프로젝트 설계에 적용을 해볼까요?


클라이언트와 회의를 할 때, 그들이 원하는 요구사항을 추출해내는 것이 결코 쉬운게 아니죠. 그렇기 때문에 요구사항에 관련된 서적들 만 해도 몇 권씩 되기도 하는 거구요. 그런데 그런 요구사항을 알기위한 보조적인 방법으로 위와 같은 방법을 사용해보면 어떨까요? 사실 많은 프로젝트에서 대부분 사용자나 클라이언트측의 담당자도 자신들이 원하는 프로그램을 정확히 파악하고 있지 못하는 경우가 많거든요. "이런 이런 형태의 프로그램을 만들어 주세요" 혹은 "이런 기능을 포함하는 프로그램을 만들어 주세요" 라고 이야기를 하지만 프로젝트를 진행하다보면 "이런 기능을 더 추가해야 겠는데요" 라거나 "그 기능은 별로 필요가 없을 것 같네요" 라는 정도의 말을 자주 듣게 되요. 물론, 고마울 정도로 클라이언트 측에서 계획을 잘 세워서 오는 경우도 있기는 하지만, 그렇게 많지는 않죠.

그럼 실제로 그림을 그리는 방법을 어떻게 응용해볼 수 있을까요?


우선 클라이언트와 앉아서 프로그램에서 핵심적인 기능들을 추려보는 거에요. 아마도 그렇게 추려진 기능들은 요구사항이 제대로 추출되지 않았다면 제작후에도 수정을 할 가능성이 많은 부분이겠죠. 그렇게 추려진 기능들을 종이에 한번 그려보도록 유도하는 거에요. 실제 모니터 화면에서 자신이 보게될 화면을 그려보도록 하는거죠. 전체 화면을 그리도록 하고, 특정 기능들을 실행되는 과정을 그림으로 그려보는 거에요. 이런 과정을 통해서 단순히 원하는 요구사항 목록을 뽑는게 아니라 클라이언트가 선호하는 화면구성, 중요요소, 실행과정 같은 걸 알 수 있는 힌트를 얻을 수 있는 겁니다.

CRC(Class-Responsible-Collaboration) Card 라는 소프트웨어 디자인(코드의 설계를 이야기하는 거죠)을 위한 기법이 있는데요. 간단하게 설명하면 인덱스 카드 정도의 종이에다가 3등분을 하여(좁은 가로줄 아래로 등분하는 세로줄을 그리는거죠) 상단에는 클래스의 이름을 하단 왼쪽에는 그 클래스가 해야할 일들을 오른쪽에는 그 클래스와 연관된 클래스의 이름을 적는거죠. 그렇게 프로그램에서 구현된 클래스들을 실제 한장의 카드로 만들어 보는 과정을 통해서 실제로 어떤 클래스들이 만들어 질지 미리 예측을 해볼 수가 있는데요. 그렇게 만든 클래스 카드를 프로그램의 특정 기능을 동작시키는데 사용해보는거죠. 예를 들어 장바구니에 물건을 넣는다고 하고, 장바구니, 물건, 사용자 같은 클래스가 있다고 생각하는거죠. 그러면 물건을 넣는 기능을 그 카드들을 배열해보면서 동작시키는거에요. 물건을 보는 화면에서 장바구니를 클릭하면 물건.물건정보() 같은 메쏘드가 호출이 될 것이고 물건.고유번호() 를 사용자.장바구니얻기() 해서 얻은 장바구니에 장바구니.추가() 같은 방식으로 넣는다. 뭐, 이렇게 꼭 되진 않겠지만 카드를 이리저리 배열해보면서 구성을 하는거죠. 여러명의 개발자가 같이 하고 있었다면 일종의 롤플레잉 게임처럼 각자 나누어 클래스를 담당하고 어떤 기능을 정하고 각자 필요한 부분에서 카드를 내거나 설명을 해요.

이런 방식들로 사용될 수 있는데, 다시 본론으로 돌아가보죠. 그림을 그리는 작업도 어쩌면 CRC카드 처럼 아직 우리가 눈으로 볼 수 없는 것들을 미리 볼 수 있게 해주는 작업일겁니다. 생각만 했는데 실제로 보니 다른 점들이 보이고 하는거겠죠. 그리고 실제로 보니 이런 저런 부분이 바뀌었으면 하는 부분도 있을 테구요.

흠.. 결론은 백번 들어도 한번 보는 것만 못하다 정도가 될 수 있을려나요? :-)

2008년 3월 15일 토요일

자람 신입생 워크샵 2008

이번주 그러니까 3월 11일부터 13일까지 제가 속해 있는 자람이라는 동아리에서 "신입생 워크샵"이라는 행사를 했습니다.

행사 준비를 일주일 정보 밖에 못했기 때문에 생각했던 것 만큼 많은 내용을 담을 수는 없었지만, 좋은 다양한 경험을 할 수 있는 시간이었습니다. 그렇게 진행되었던 뼈대가 다른 비슷한 행사를 준비하는 경우에도 적용될 수 있을 것 같습니다.

이번의 경우 여건상 하루에 1시간 30분이라는 시간 밖에 운용할 수 없었습니다. 3일동안 다 합쳐봐도 5시간이 안되는 시간이죠. 그렇게 짧은 시간에 무엇을 할 수 있느냐는 물음에 당연히 도달하게 되었습니다. 그래서, 프로그래밍을 한번도 접해보지 않은 신입생에게 그 흥미를 이끌어내는 과정을 제안했습니다.

첫째날


첫째날은 터틀(turtle)이라는 간단한 교육용 시스템을 다루는 시간으로 정했습니다. kturtle이라는 kurtle의 구현중 하나를 사용하고 싶었지만 KDE 라는 제약 때문에 python에 기본으로 내장되어 있는 turtle을 이용하였습니다.

http://edu.kde.org/kturtle/pics/kturtle4.png
kturtle 동작화면 (from kturtle website )

파이썬 내장 turtle의 경우 간단히 아래처럼 시작할 수 있습니다
from turtle import *
reset()
forward(10)
left(50)
forward(10)

간단한 몇가지 문법을 이용해서 화면에 그림을 그리는 과정이지만 그 안에서 프로그래밍의 기본적인 제어문이나 알고리즘에 대한 개념을 배울 수 있습니다. 이번 신입생들과 조를 나누어 turtle을 배우는 시간도 신입생들과 재학생 모두에게 도움이 되는 시간이었습니다. turtle처럼 간략한 문법을 가지고 있는 시스템은 최대한 문제의 해결과정에 집중할 수 있도록 해주기 때문에 프로그래밍을 처음 배우는 사람에게 적합한 것 같습니다. 1시간 약간 넘는 시간 도안 몇가지의 다양한 문제들을 해결해보고 마지막은 자유작품을 제출해서 가장 많은 표를 얻은 팀에게 상품을 수여하기도 하였습니다.

둘째날


둘째날의 1시간 30분중 20분은 신입생을 위해서 만든 홍보 동영상과 졸업한 선배들을 찾아가서 인터뷰를 요청한 영상을 편집하여 상영했습니다.

이번 행사의 특징중 하나는 최대한 동영상이나 사진, 그리고 turtle처럼 눈으로 볼 수 있는 과정들이 많았다는 점입니다. 이것은 1시간 30분이라는 시간이 생각하기에 따라 짧을 수도 길수도 있기 때문입니다. 결국 이 시간을 지루하게 느낄 수 있는 사람들도 있을테고 그들의 흥미를 최대한 높일 수 있는 방식으로 시각적인 과정의 비율을 높였습니다. 또한, 눈으로 그 결과를 바로 볼 수 있기 때문에 더 쉽게 접근이 가능하다는 점도 선택 이유였습니다.

동영상 상영 이후, 제가 준비한 "시작하는 후배들을 위하여.."라는 제목의 30분짜리 발표가 있었습니다. 이후 자람15기 김효준선배현업개발자와의 대화라는 프로그램이 있었습니다.


시작하는 후배들을 위하여 세미나에 사용된 pt의 일부

세째날


마지막날에는 Open Space Technology 라는 형식의 토론을 진행했습니다. 초기에 우려했던 바와는 다르게 성공적으로 진행할 수 있었고, 5개의 테이블에서 10개정도의 주제가 토론되었습니다. OST 기법은 동아리에 4번째 적용하는 것이었는데, 기본지식이 없는 신입생들과 함께 하는 것이라 성공에 대한 의문이 있었는데, 이번 시도로 다양한 집단에 성공적으로 적용할 수 있는 가능성을 볼 수 있었습니다.

결론


일단, 무언가 새로운 행사를 구성해서 진행을 한것도 거의 3년만의 일이라서 여러면에서 즐거웠습니다. 계획을 세우는 것도 재밌었고, 약간 바쁜 일정이었지만 제시간에 준비해서 발표했을 때의 기쁨도 있었습니다. 무엇보다 새로운 것들을 시도했던게 보람찬 일이었습니다. 차후로 이와 같은 행사들이 이어지면 좋겠지만, 지금의 모습을 답습하기보다는 항상 새롭게 바뀌는 모습이었으면 좋겠습니다. 그리고 이번 과정을 듣지 못했던 학교의 다른 후배들이 아쉬웠는데, 다음행사는 더 많은 참여가 가능한 방법을 모색해야겠습니다.

tags : 신변잡기

2008년 3월 13일 목요일

시작하는 후배들을 위하여..

자람 18기 문병원(tasyblue@gmail.com)


작성일 : 2007년 3월 31일


수정일 : 2008년 3월 12일


처음 이 세미나를 기획하면서 여러가지 생각들을 했습니다. 어떻게 하면 그들의 생각에 전환을 줄 수 있을까. 어떻게 해야 스스로의 열정을 느낄 수 있게 할지. 그러다 문득 든 생각이 있습니다. "우리들이 지금까지 보아온 수 많은 명언들, 그리고 다양한 종류의 위대한 책들. 그런 것들을 수 없이 접했어도 일어난 변화가 이 정도라면, 우리에게 영향을 줬던 그 무언가에 문제가 있는 것이 아니라. 바로 우리 자신이 문제였던게 아닐까" 하는 생각입니다.

제가 어떤 이야기를 해도, 어떤 행동을 보여도 여러분께 끼칠 수 있는 영향은 미약하기 짝이 없을 것입니다. 결국 받아 들이는 것은 개인이니까요. 이건 단순히, 체념적인 생각이 아니라. 어떤 일을 시작할 때, 그 한계를 파악하는 것이라 생각합니다. 비관적으로 들리더라도 전 이렇게 생각합니다. 오늘 내가 이 앞에 앉은 이들의 삶을 바꿀 수는 없는 것이라고.

하지만, 지금 이 글을 작성하는 제 마음에는 내 생각과는 다른 감정으로 가득합니다. 우리는 우리를 바꿀 수 있고, 우리는 다른 이들을 변화하도록 도울 수 있습니다. 그리고 우리는 주변을 행복하게 하고, 더 나아가 세상을 행복하게 할 수 있습니다. 그 시작은 미약한 변화를 일의키는 단 하나의 행동이며, 결국 어떠한 시도도 무모하거나 의미 없는게 아니라고 생각합니다.

진부한 말이라도, 이미 알고 있는 것이라도. 그것이 좋은 길이라면, 그것이 바른 것이라면 서로 상기시키고 함께 해야 한다고 생각합니다.

제가 앞으로 이야기 하고자 하는 것들은 그렇게 진부하기도 하고, 어떻게 보면 의미 없는 이야기지만 여러분께 지금 이순간 제가 드리고 싶은 진심입니다.

이번 기회를 통해, 이렇게 만나게 되어 반갑고 짧은 시간이지만 서로에게 의미있는 시간이 될 수 있기를 기대합니다.

Computer Science and Engineering


한양대학교 전자전기컴퓨터공학부를 선택하는 순간, 그리고 자람이라는 학회를 선택하는 순간, 여러분의 공부는 전산에 어느 정도 이상씩 관련된다. 지금 여기서 알아볼 전산에 대한 공부는 그 기초가 되는 전산을 알아보기 위함이다.

일단 우리는 뭉뚱그려서 전산학이라고 말하는 우리가 선택한 전자전기컴퓨터공학부에서 컴퓨터공학부에 해당하는 학문은, 그 구별을 크게 컴퓨터 사이언스와 소프트웨어 엔지니어링으로 나눌 수 있다. 여기서 말하는 구분은 내 생각일 뿐이며, 여러분들의 이해를 돕기 위해 임의로 구분한 것이라는 것을 일단 전제하려고 한다.

컴퓨터 사이언스(Computer Science)는 물리학이나 화학, 생물학과 마찬가지로 컴퓨터를 구성하는 원리나 컴퓨터를 이용하여 작동되는 다양한 프로그램들에 대해서 연구하는 학문이다. 필연적으로 학술적인 성격을 많이 가지고 있으며, 주로 대학이나 연구소에서 그 발전이 이루어진다.

컴퓨터에 관련된 분야 중에서(여러분이 앞으로 배울 교과가 각각의 분야라고 생각해도 된다) 컴퓨터 설계(Computer Architecture), 운영체제(Operating System), 컴파일러(Compiler), 데이터 베이스(Database), 파일 시스템(File System), 알고리즘(Algorithms), 자료구조(Data Structure), 네트워크(Network) 등의 분야가 이에 해당한다.

다시 말해, 컴퓨터 사이언스는 우리의 분야를 구성하고 있는 가장 기초적인 이론적 토대를 제공하는 부분이다. 결국 소프트웨어 개발이란 그 소프트웨어가 실행되고 개발되는 하드웨어적 소프트웨어적 기반요소가 자리 잡은 상태에서 이루어지는 것이므로, 그 기반에 대한 이해가 필연적으로 높은 수준의 소프트웨어 개발 역량으로 이어진다는 것을 생각해 볼 수 있으 것이다. 여기에 컴퓨터 사이언스의 중요함 중에 하나가 있다.

소프트웨어 엔지니어링(Software Engineering)은 일반적으로 소프트웨어 개발 프로세스와 같은 개발 방법에 대한 공학적 접근을 말하지만. 여기서 말하고자 하는 것은 그를 포함하는 소프트웨어 개발에 직접적으로 관련되는 전반적인 부분이다.

교과목으로 그 범위를 이야기해 보자면, 객체지향 프로그래밍(Object Oriented Programming), 프로그래밍 언어들(자바 프로그래밍, C 프로그래밍, ML, Scheme, Haskell..), 프로그래밍 방법론 등이 이에 해당한다.

단순하게 대학에 한정지어 각 분야의 비율을 따져보면 8:2정도로 컴퓨터 사이언스가 높은 비중을 차지한다. SE관련 분야들이 차후 실제 개발에 밀접하게 연관된다는 사실을 볼 때, 이는 아직 대학에 SE의 중요성에 대한 인식이 미흡하다는 것으로 생각할 수 있는데, 우리가 이런 상황을 극복하기 위해서는 소프트웨어 개발의 다양한 요소들을 나름의 계획을 세워 알아나가야겠다.

소프트웨어는 살아 있다


여기서 말하고자 하는 내용은 100% 내 개인적인 생각이지만, 꽤 높은 확률로 적중할 것이라고 생각한다.

일단 소프트웨어 분야가 점점 중요성이 더해지고 있다고 생각하는 근거를 보자면 아래와 같다.

  • 몇년 전부터 인텔리전트 아파트의 개념이 강해지고 있다. -> 앞으로 점점 똑똑한(Smart) 주거환경에 대한 관심과 투자가 이루어질 것이다.

  • 최근까지 휴대폰의 지상목표는 최대한 작고 가볍게였으나, 요즘은 다양한 기능과 사용성이 중요시 되고 있으며, 얼마전 IPhone의 등장은 소프트웨어의 혁신이 제품의 매력의 결정적인 요소가 된다는 점을 보여준다.

  • 구글에서 시작했던 구글맵, 그리고 그로 인해 현재 웹에 광범위하게 퍼진 AJAX -> 현재 구글의 웹 에플리케이션들은 컴퓨터를 이용하는 사람들의 이용 패턴을 바꾸어 놓을 정도의 영향력을 보여주고 있다.

  • 중요성이 점점 부각되고 있는 컨버전스의 핵심은 소프트웨어이다. -> 차후 높은 수준의 제품의 뒤에는 높은 수준의 소프트웨어가 핵심이 될 것이다.

  • 구글과 애플은 대표적으로 강력한 소프트웨어 개발능력 회사의 승패를 결정하는 요소가 되었던 예.

    • 구글은 소프트웨어 개발 능력이 회사의 발전을 주도한 전형적인 경우

    • 애플은 경우는 구글에 비해 소프트웨어 개발 역량이 차지하는 비율은 적은편, 애플의 혁신적인 아이디어가 애플의 현재 발전의 주요인. 하지만 그것을 뒷 받침 했던 것이 소프트웨어 개발 역량, 애플의 재등장의 숨은 주역은 소프트웨어 개발.




위에서 말하고 있는 근거는 그다지 설득력있는 근거는 아니지만, 직관적으로도 최근 우리 주변의 다양한 분야에 소프트웨어가 포함되고 지능화되거나 자동화되고 있다는 것을 알 수 있다. 이러한 변화는 차후 더 가속화될 것이며 앞으로 역량있는 개발자들의 수요는 더욱 늘어날 것이다.

How to study computer programming


위기지학을 하라


위기지학(爲己之學) : 학문의 시작은 자신을 위한 학문이다.
학문에는 자기를 위하는 위기지학(爲己之學)과 남을 위하는 위인지학(爲人之學)이 있다. 위기가 먼저고 위인이 나중이다. 수신제가가 있어서 치국평천하가 있는 것과 같다. 경전공부는 수기, 즉 내 몸을 닦는 위기지학이다. 그것은 안으로 수렴하는 공부다. 이를 통해 바탕이 서면, 그 다음에는 밖으로 미루어 확장하는 치인 또는 안인(安人)의 위인지학으로 나아간다. 역사와 경세제민(經世濟民)의 공부가 그것이다.

- 다산선생 지식경영법, 정민, 페이지66~67



소프트웨어 개발도 자신을 위한, 자신이 사용하는 소프트웨어를 만드는 것이 그 시작이 되어야 한다. 남을 위해서만 만드는 프로그램에서는 개발동기를 찾을만한 내용을 발견할 수 없고, 소프트웨어 개발과 같은 정신적인 측면이 차지하는 부분이 많은 작업에서는 동기나 흥미가 굉장히 중요한 요소.

요즘 프로그래머들 중에서는 예전에 게임을 하면서 자신이 직접 그 게임을 만들어 보고 싶다는 생각에서 프로그래밍을 시작한 경우가 많음.

주변이나 다양한 분야의 이름있는 개발자들을 보면, 실제 생활에서 소프트웨어 개발능력을 활요하고 있는 경우를 많이 볼 수 있음.

  • 장혜식 : 파이썬 커미터와 FreeBSD 포트 커미터로 생활에 필요한 프로그램들을 주로 파이썬이나 다른 스크립트 언어를 이용하여 만들어 사용.


  • 이승근 : 자람 17기, 내가 말은 안했지만, 존경하는 선배. 역시 필요한 프로그램들을 종종 개발하여 잘 사용하고 있음.

    • MSN 봇

    • 한양 소리바다

    • 카플 (이건 매쉬업용으로 만드는거지만)

    • 스토커

    • ...




위기지학에 대한 좋은글로 김창준 씨의 "프로그래머의 위기지학"을 추천한다.

프로그래밍은 종합학문


만류귀종(萬流歸終) : 프로그래밍은 종합학문이다. 공부의 중심을 잡고 변화와 변주를 추구하라. '주제와 변주'사이를 넘나드는 한편의 교향곡과 같은 생활이 필요하다.

꼭, 프로그래밍을 잘 하기 위해서가 아니라 생각을 넓히기 위해서라도 다양한 분야에 대한 공부가 필요하다.

프로그래밍이 종합학문이라기 보다는(물론 프로그래밍도 종합학문이지만) 프로그램 개발이 종합적인 요소들을 필요로 한다.

프로그램 개발은 단순히 프로그램을 만드는 과정뿐만이 아니라. 프로그램을 기획하고, 프로그램을 제작하는 과정에서 다양한 사람들과 의견을 조율하고, 요구사항을 생성하고, 프로그램의 사용성을 개선하고, 프로그램을 테스틍 하는 등의 모든 과정과 함께, 프로그램이 개발된 이후에 서비스하는 과정에서 발생할 수 있는 요구사항 변경이나, 유지보수 작업같은 부분까지 포함하는 일이다.

프로그램 개발은 사람이 하는 일이고 그 목적은 다양하겠지만, 궁극적으로 사람이 관련되기 때문에 그에 따라 발생하는 다양한 문제가 생긴다. 그로 인해, 심리학이나 인지공학 같은 부분, 인간관계론 같은 대인관계에 관한 기술, 대화나 회의를 위해 필요한 기술, 자료를 체계적으로 정리하고 요점을 뽑는 기술등 언듯보면 관련이 없어보이는 작업들이 함께 필요해진다.

시작하는 후배들을 위하여


무식한 대학생이 되지 않도록


매번 듣는 말이지만, 목적과 수단을 잘 구분하라.

프로그래밍 기술은 목적이 아니다.

당신이 프로그래밍을 하고 배우는 것은 무엇 때문인가?
그대 이름은 <무식한 대학생>

그대는 대학에 입학했다. 한국의 수많은 무식한 대학생의 대열에 합류한 것이다. 지금까지 그대는 12년 동안 줄세우기 경쟁시험에서 앞부분을 차지하기 위해 부단히 노력했다. 영어 단어를 암기하고 수학 공식을 풀었으며 주입식 교육을 받아들였다. 선행학습, 야간자율학습,보충수업 등 학습노동에 시달렸으며 사교육비로 부모님 재산을 축냈다.

그것은 시험문제 풀이 요령을 익힌 노동이었지 공부가 아니었다. 그대는 그 동안 고전 한 권 제대로 읽지 않았다. 그리고 대학에 입학했다. 그대의 대학 주위를 둘러 보라. 그 곳이 대학가인가? 12년 동안 고생한 그대를 위해 마련된 '먹고 마시고 놀자'판의 위락시설 아니던가.

그대가 입학한 대학과 학과는 그대가 선택한 게 아니다. 그대가 선택 당한 것이다. 줄세우기 경쟁에서 어느 지점에 있는가를 알게 해주는 그대의 성적을 보고 대학과 학과가 그대를 선택한 것이다. '적성' 따라 학과를 선택하는 게 아니라 '성적' 따라, 그리고 제비 따라 강남 가듯 시류 따라 대학과 학과를 선택한 그대는 지금까지 한 권도 제대로 읽지 않은 고전을 앞으로도 읽을 의사가 별로 없다. 영어영문학과, 중어중문학과에 입학한 학생은 영어, 중국어를 배워야 취직을 잘 할 수 있어 입학했을 뿐, 세익스피어, 밀턴을 읽거나 두보, 이백과 벗하기 위해 입학한 게 아니다. 그렇다면 차라리 어학원에 다니는 편이 좋겠는데, 이러한 점은 다른 학과 입학생에게도 똑같이 적용된다. '인문학의 위기'가 왜 중요한 물음인지 알지 못하는 그대는 인간에 대한 물음 한 번 던져보지 않은 채, 철학과, 사회학과, 역사학과, 정치학과, 경제학과를 선택했고, 사회와 경제에 대해 무식한 그대가 시류에 영합하여 경영학과,행정학과를 선택했고 의대, 약대를 선택했다.

한국 현대사에 대한 그대의 무식은 특기할 만한데, 왜 우리에게 현대사가 중요한지 모를 만큼 철저히 무식하다. 그대는 <조선일보>와 <동아일보>가 '민족지'를 참칭하는 동안 진정한 민족지였던 <민족일보>가 어떻게 압살되었는지 모르고, 보도연맹과 보도지침이 어떻게 다른지 모른다. 그대는 민족적 정체성이나 사회경제적 정체성에 대해 그 어떤 문제의식도 갖고 있지 않을 만큼 무식하다.

그대는 무식하지만 대중문화의 혜택을 듬뿍 받아 스스로 무식하다고 믿지 않는다. 20세기 전반까지만 해도 읽지 않은 사람은 스스로 무식하다고 인정했다. 그러나 지금은 대중문화가 토해내는 수많은 '정보'와 진실된 '앎'이 혼동돼 아무도 스스로 무식하다고 말하지 않는다. 하물며 대학생인데! "당신의 능력을 보여주세요!"에 익숙한 그대는 '물질적 가치'를 '인간적 가치'로 이미 치환했다. 물질만 획득할 수 있으면 그만이지, 자신의 무지에 대해 성찰할 필요조차 느끼지 않게 된 것이다.

그대의 이름은 무식한 대학생. 그대가 무지의 폐쇄회로에서 벗어날 수 있을 것인가. 그것은 그대에게 달려 있다. 좋은 선배를 만나고 좋은 동아리를 선택하려 하는가, 그리고 대학가에서 그대가 찾기 어려운 책방을 열심히 찾아내려 노력하는가에 달려 있다.

홍세화, 2004.1.26. 진보누리에서



무식한 대학생이 되지 말이라. 네가 공부하는 것은 단지, 공부를 해야 해서가 아니다. 생각의 그리고 행동의 중심을 갖자. 지금까지 살아온 삶은 자신의 의지에 따른 삶이 아니었을 수도 있다. 하지만 이제 마음의 중심을 가져라

마음이 바로 선다면 그 때야 비로소 삶을 다체롭게 그리고 여유있게 살 수 있을 것이다.

난 스노우 보드를 타길 좋아한다. 보드를 탈 때는 몸의 중심을 잘 유지하는 것이 중요하다. 일단, 활강하면서 중심을 유지하는 방법만 알게 된다면, 간단한 중심이동으로 다양한 턴을 하면서 경사면을 내려올 수 있다.

마찬가지로 삶의 중심이 바로 선다면 대학생활에서도 다양한 가치와 경험의 순간을 경험할 수 있을 것이고 그러한 것들이 생활의 활력이자 더 나은 사람이 되는데 도움이 될 것이다.

당신의 스승을 찾아라


스승의 형태는 중요하지 않다. 학교 선배나 교수님이라도 상관없고 한권의 책, 혹은 잡지에서 우연히 본 기사의 저자라도 상관없다. 하지만 그 스승은 분명 현재의 위치의 당신에게 혁명적인 변화를 주었고 그 변화를 이루어 나갈 수 있어야 한다.

스승을 통해서 스승의 경지에 도달하고자 하면, 그 스승을 더욱 자세히 알게 된다. 그리고 그렇게 노력하다보면 어느 순간 예전과 같은 감정을 느낄 수 없게 될 것이다. 그것이 성장이다.

스승을 찾기 위해서 노력하라. 가만히 있는데 그런 존재가 나타날리가 없다. 찾기 위해 뛰어다녀라. 탐구하고 궁리하라. 즉, 다양한 사람을 만날 수 있는 기회에 부단히 참여하고, 새로운 시도를 두려워 하지 말아라. 다양한 책을 읽고, 이런 모든 일 과정에서 눈을 부릅뜨고 스승의 존재를 찾기위해 노력하라. 찾으라 그럼 얻을 것이다.

이번 1년 이 책은 읽어라


책에는 죽은 지식도 들어있고, 책을 읽다가 혁명적인 경험을 한다거나, 자신이 송두리째 바뀌는 그런 경험을 하기는 어렵다.

하지만, 그렇다는 것을 알 정도는 책을 보아야 하지 않을까?

아래, 두권의 책은 지난 1년, 더 나아가 최근 5년 동안 읽은 책중에서 삶을 바꾸는 힘을 느겼던 책이다.

 



 




tags : 프로그래밍에 대한 이야기, 신변잡기

Man of Month를 마치며

벌써 2020년 1월 14일이다. 19년의 마지막 달에 Man of Month라는 팀의 제도를 시작한다고 했었는데, 12월이 지나고 그 다음 달도 거의 절반이 흐른 것이다. MoM을 시작하면서 하겠다고 계획했던 것들도 실제 한 것들과 비교해보니...