2008.11.28 16:09

김성훈 교수와 일해보세요!

김성훈 교수와 일해보세요!


더 좋은 디버깅방법은 없을까요?”

숨어 있는 버그를 자동으로 찾아 낼 수는 없을까요?”

보다 더 나은 방법으로 프로그램을 개발하고 싶은가요?”

  

소프트웨어 개발에 있어 지금보다 더 멋지게 소프트웨어를 개발하는 좋은 아이디어를 가지고 계신가요? 이러한 분야를 연구하여 전 세계의 모든 개발자들에게 영향력있는 도움을 주고 싶은가요이런 문제들을 고민해 보신 적이 있나요그렇다면 홍콩과학기술대학의 김성훈 (Sung Kim) 교수와 함께 소프트웨어 공학 박사과정 학생으로 전체 등록금과 생활비를 지원 받으면서 연구하는 것을 고려해 보세요세계적인 인재가 될 수 있는 발판을 마련해 드립니다.

1.   Who is Sung Kim?

김성훈 박사는 홍콩과학기술대학 (Hong Kong University of Science and Technology, HKUST 이하 홍콩과기대) 컴퓨터 공학과 조교수로 일하고 있습니다. 그는 1995년 로봇에이전트를 이용한 최초의 한글 검색엔진인 까치네를 개발했고 ()나라비전에서 6년간 CTO로 근무하면서 깨비웹메일의 개발을 이끌었습니다. 2000년 미국으로 건너간 그는 프로그램을 개발하면서 느낀 불편한 점을 바탕으로 소프트웨어 공학 (효과적으로 소프트웨어 버그를 찾는 연구) 으로 2006년 캘리포니아 주립대학교 Santa Cruz에서 박사학위를 받았으며 2006년 부터 2008월까지 MIT 프로그램분석 연구실에서 버그 검출에 대한 연구를 진행하였습니다.

그의 논문들은 소프트웨어 공학의 최고 저널인 IEEE Transaction on Software Engineering 등에 게재 되었고 2007 International Conference on Software Engineering 에 발표된 그의 논문은 한국인 최초로 최우수 논문상을 수상하기도 했습니다. 그는 자동화된 테스팅 및 버그 검출기술, 소프트웨어 history 마이닝, 동적/정적 분석기술 등의 개발로 안정화된 프로그램을 만들고 프로그래머들이 더욱 신나게 일할 수 있는 방법을 연구하고 있습니다.

그의 최근 주요 논문:

ReCrash: Making software failures reproducible by preserving object states
by Shay Artzi, Sunghun Kim, and Michael D. Ernst.
In ECOOP 2008
Object-Oriented Programming, 22nd European Conference, (Paphos, Cyprus), July 9-11, 2008, pp. 542-565.
Details. Download: PDF, PostScript, ReCrash implementation.

Classifying Software Changes: Clean or Buggy?
by Sunghun Kim, E. James Whitehead, Jr., and Yi Zhang.
IEEE Transactions on Software Engineering, vol. 34, no. 2, March/April 2008, pp. 181-196.
Details. Download: PDF.

Predicting faults from cached history
by Sunghun Kim, Thomas Zimmermann, E. James Whitehead, Jr., and Andreas Zeller.
In ICSE'07, Proceedings of the 29th International Conference on Software Engineering, (Minneapolis, MN, USA), May 23-25, 2007, pp. 489-498.
Details. Download: PDF.

2.   HKUST?

홍콩과기대는 1991년에 설립된 대학으로 국제적인 명문대학중의 하나입니다. 전체 행정과 수업이 영어로 진행되며 약 30% 교수진이 외국인 (서양인)으로 구성되어 있습니다. 소프트웨어, 데이타 베이스, 그래픽스 분야에 최고 연구팀을 가지고 있으며 해당 분야 연구를 주도하고 있습니다.

2008 The Times 지에서 발표된 전세계 대학의 랭킹의 따르면 전체 Ranking 39, IT/공학 계열은 24위에 올라 세계대학들과 비교하더라도 최상위권이라 할 수 있습니다. (조선일보 기사http://news.chosun.com/site/data/html_dir/2008/10/09/2008100900025.html 참조). 컴퓨터 공학과에는 230명이 넘는 대학원 생들이 있으며 (100명 이상의 박사과정) 43명의 교수진이 있습니다.



흥미진진한 도시 홍콩의 클리어워터베이에 자리잡고 있는 홍콩과기대는 100% 영어 사용환경, 중국본토를 비롯한 우수한 학생들의 유입, 실물경제가 탄탄한 중국 등의 영향으로 계속 발전해나갈 것입니다.



3.   묻고 답하기

-    박사과정 지원하려면 어떤 자격이 필요하나요?  석사 졸업 또는 학사졸업 후 수년 이상의 관련 연구 및 실무경력을 가지고 있다면 지원가능합니다. (석사학위가 없어도 지원 가능합니다.) TOEFL을 필요로 하며TOEFL(pbt)>=580  or TOEFL(ibt)>=92  이상의 성적이 있으면 지원 가능합니다.

-    졸업은 얼마 만에 가능한가요? 학생의 연구 진도에 따라 다를 수 있지만 일반적으로 석사학위를 가지고 있는 학생들은 약 3, 학사학위만 있는 경우에는 약 4의 시간이 소요 됩니다.

-    졸업 후 진로는 어떻게 되나요? 홍콩과기대학 졸업생들은 상당수 미국, 중국, 홍콩, 호주, 유럽, 캐나다 등에 교수요원으로 진출하였고 마이크로소프트 연구소, IMB 연구소, 구글 등의 회사에서 연구원으로 일하고 있습니다.  http://www.cse.ust.hk/pg/ourgraduates/ 를 참고하세요.

-    논문은 많이 쓸 수 있나요?  홍콩과기대학생들은 프로젝트의 진행보다는 논문을 제출할 수 있는 연구를 중요시 하기에 일반적으로 매우 많은 논문 실적이 있습니다. 참고로 그래픽스연구자의 최고 학회인 SIGGRAPH 2006 10, 2007 6, 2008 10편의 논문이 Accept되었습니다. (SIGGRAPH가 어떤 곳인지 그래픽스 하시는 분에게 물어 보세요. 과학자들에게  Science 지와 같은 곳입니다.).

-    영어를  사용하나요?  홍콩과기대에서는 모든 행정,  수업, 학생지도가 100% 영어로 이루어 지므로 국제적인 연구자의 중요한 자질인 영어 실력이 향상됩니다. 참고로 현재 컴퓨터 공학과 학부장은 중국말을 전혀 못하는 외국인 출신의 교수입니다.

-    생활비나 학비는 얼마나 드나요? 2008년 현재 대학원생에게 공식적으로 지급되는 월급은 13,750 HKD 으로 약 250만원 (2008 10월 환율 기준) 정도 되는 금액입니다. 입학이 허가된 박사과정 학생에세는 월급과 학비는 전액이 교수님의 연구비와 학교의 장학금으로 지급됩니다. 월급으로 대부분 생활이 가능하여 추가 비용없이 학위과정을 마칠수 있게 됩니다.

-    Housing은 지원되나요? 홍콩과기대 대학원학생들은 100% 기숙사 생활을 합니다 ( 2,500 HKD수준). 기혼자는 학교에서 차로 10~15분 정도 떨어진 곳의 off-campus housing을 찾을 수 있습니다. 자세한 사항은https://sao.ust.hk/housing/index.html 를 참조 하세요.

-    지원해보고 싶은데 필요서류와 원서마감은 언제인가요?  이력서, 추천서 등이 필요합니다. 매년 3월에 원서 가 마감됩니다. 학기는 매년 9월에 시작됩니다. 자세한 것은 http://www.cse.ust.hk/pg/admissions/recruiting_message/ 를 참조 하세요.

4.   참고 자료

    - 홍콩과기대 방문 결과 보고 (by 포항공과 대학교)

홍콩과기대.pdf



5.   더 묻고 답하기

더 궁금한 사항이 있거나 개인적인 질문이 있으시면 김성훈 교수<hunkim@cse.ust.hk> 에게 이메일을 보내주세요


저작자 표시 비영리 변경 금지
신고
Trackback 4 Comment 7
  1. 쩐의시대 2008.11.21 10:54 신고 address edit & del reply

    선배~~ 잘 보고 갑니다. 저두 같이 일하고 싶은데...

  2. 2008.12.18 15:00 address edit & del reply

    비밀댓글입니다

  3. 모든 것의 시작 2008.12.31 19:37 신고 address edit & del reply

    구글 메일에도 이글이 뜨네요~ 그래서 함 둘러봤는데~ 엄청 멋지신 분이시네요~
    잘 보고 갑니다~

  4. 2009.01.12 19:55 address edit & del reply

    비밀댓글입니다

  5. 막장버릇 2013.06.07 13:01 신고 address edit & del reply

    김성훈씨가 홍콩대 교수가 되었다니 축하.
    그렇지만.. 1996년 개통된 까치네를 1995년이라고 속이고...
    세계최초의 한글검색엔진이라고 거짓말치면 곤란하죠.

    • HannaKim 2013.06.08 09:14 신고 address edit & del

      지적해 주셔서 감사합니다. 우선 까치네는 1995년에 개발된것이 맞습니다.

      최초라는 부분은 수정하였습니다. 최근 글인 http://www.se.or.kr/116 에는 최초는 Kor-seek이라고 제가 밝혀 두었습니다. 혹 다른 잘못된 부분이 있으면 알려 주세요.

      홍콩대와 홍콩과기대는 다른 대학입니다. 저는 홍콩과기대에서 일하고 있습니다.

  6. 마방진 2017.03.01 13:23 신고 address edit & del reply

    강의 잘 보고 있습니다. 고맙습니다.
    불혹의 나이에 딸린 식구도 있지만, 꼭 같이 연구해보고 싶습니다^^* 그런데 먼저 영어부터 해야겠네요^^*

2008.11.27 22:35

MediaWiki 로 개인 홈페이지 만들기

좋은 학생들을 받고 자신의 연구를 알리기 위해 멋진 홈페이지가 필요하다고 하는데 기본적인 HTML실력으로 너무나 멋진 웹페이지를 만들기는 어렵고 또 업데이트도 쉽지 않을것 같고... 그래서 블로그나 위키또는 Plone등으로 만든 홈페이지를 조사 해 보았다.


이미 블로그도 있고 Plone도 있어서 같은걸로 만들면 따라 하는것 같고 나는 위키로 만들어 보기로 결심했다. (물론 위키로 홈피를 하시는 분들도 많겠지만 내가 아는 사람은 없는 관계로 It's OK.) 위키중에 가장 근엄한 위치를 차지하고 있는 MediaWiki (http://www.mediawiki.org/wiki/MediaWiki).

우선 그 홈페이지 부터 참 멋지다.



이런 기분으로 잘 마치고 Media 위키를 설치 했다. 첫 화면은 정말 썰렁한 페이지. MediaWiki 웹페이지와는 너무나도 다른 썰렁이다. 




어떻게 해야 할까? 답답한 마음이지만 나름 열심히 노력하여 다음과 같은 웹페이지가 탄생되었다. 



혹시 Media Wiki로 홈페이지를 만들고 싶은 사람을 위해 새로 배운것을 적어 본다.
1. 우선 보안 설정하기
위키를 홈페이지로 사용하다 보니 우선 홈페이지를 로그인 한 사람만 고치도록 해야 하고 또 내가 원하는 사람만 로그인 하도록 바꿔줄 필요가 있다. 이를 위해서는 mediawiki 웹페이지에 있는 LocalSettings.php 에 아래를 추가 해준다.
$wgGroupPermissions['*']['createaccount']   = false;
$wgGroupPermissions['*']['edit'] = false;

2. 왼쪽의 사이트 바를 메뉴로 사용하기
우선 왼족에 있는 사이드 바는 나의 홈페이지와 거리가 있기에 이를 과감하게 고친다. 왼쪽 Search bar에 "MediaWiki:Sidebar" 를 입력한다.

아래와 같이 고쳐 보았다;
  • Menu
    • mainpage|mainpage-description
    • Research|Research
    • Publications|Publication
    • Software|Software
    • Teaching|Teaching
    • Students|Students
    • Service|Service
    • Bio|Bio
    • Contact|Contact
    • recentchanges-url|recentchanges
  • SEARCH
  • TOOLBOX
  • LANGUAGES

3. 로고 바꾸기
그런 다음은 오른쪽에 있는 로고가 보이는데 이를 멋진것으로 고치기. 역시 LocalSetting.php 에 다음을 추가 해 준다.
$wgLogo = "http://cerg1.ugc.edu.hk/graphics/HKUST_f.gif";

이정도면 그럭저럭 만족할만하다고 할 수 있지만 아직 갈길이 멀다. 한숨 한번 내쉬고 계속

4. 첫화면에 박스를 넣어 보자.
MediaWiki에 나오는 것 같은 멋진 박스들을 넣으려면 어떻게 할까? 한참 보다 보니 Wiki의 table과 style로 만들고 있었다. 예를 들어 다음과 같은 식이다.
<div style="font-size:150%; padding-bottom:0.15em; text-align:center; margin-top:0.33em;">[[Sung Kim]] </div>

자세한 것은 필자의 (임시) 홈페이지를 보면 된다. http://webproject.cse.ust.hk:8016

5. Title 없애기
위키의 모든 페이지에 자동으로 H1 으로 멋없이 페이지 이름으로 타이틀을 붙여 버린다. 아래그림에서 보이듯이 아주 옥의 티다. 


이를 없애는 방법을 여러가지로 찾아 보았는데 Skin을 직접 고치는것 말고는 별로 없는것 같았다. (혹시 다른 방법을 아는 분을 연락주세요.)
skins/MonoBook.php 파일을 열어 보면 108 줄에 이런 부분이 있는데 이를 주석으로 막아 버린다.

<h1 class="firstHeading"><?php $this->data['displaytitle']!=""?$this->html('title'):$this->text('title') ?></h1>
6. 텝 없애기
그리고 위키의 편리성을 위해 텝을 통해 편집이나 History등을 볼수 있는 메뉴를 제공하는데 대부분이 로그인 하지 않은 사용자에게는 필요가 없다. 

이를 없애기 위해
skins/MonoBook.php 파일을 열어 보면 124 줄 정도에 있는 텝 보이기를 다음과 같이 수정 (즉 로그인 후에만 tab이 보이도록 한다)
-       <?php           foreach($this->data['content_actions'] as $key => $tab) {
+       <?php           if($this->data['loggedin']==1) foreach($this->data['content_actions'] as $key => $tab) {

이정도면 그런대로 홈페이지로 사용하기위해 준비된것 같다. 앞으로도 XML feed 나 하나의 위키 페이지의 일부를 박스에 넣어 보여 주는 등의 기능이 더 필요하겠지만 천천히 하나씩 하고 소개도 하려고 한다.

위키 홈페이지를 만들기 위해 참조한 두 사이트를 소개 한다.

저작자 표시 비영리 변경 금지
신고
트랙백이 없고 Comment 11
  1. swinside 2008.11.28 15:41 신고 address edit & del reply

    오 좋은데요... plone 이나 Media Wiki 중에서 조만간 하나로 해봐야겠어요. Wiki 쓰다가.. 좀 불편해서... Wordpress 로 그냥 간단하게 만들어 쓰고 있긴한데... 아무래도 다시 Wiki로 가야할지도... 좋은 자료 감사합니다.

  2. 마루날 2008.12.08 10:02 신고 address edit & del reply

    오.. 흥미롭습니다.

    그나저나 친구 12월에 모이기로 했는데
    편한 날짜를 찍어주게나 ^___^

  3. 조종우 2009.03.28 19:56 신고 address edit & del reply

    도움이 많이 되었습니다. 감사합니다.

  4. ssam 2009.09.01 02:58 신고 address edit & del reply

    대문이란 이름을 수정하고 싶으시면 아래처럼 수정하시면됩니다.

    <!-- // 대문 이름 막음 원본
    <h1 id="firstHeading" class="firstHeading"><?php // $this->data['displaytitle']!=""?$this->html('title'):$this->text('title') ?></h1>
    -->
    <!-- 대문 이름대신 서브페이지에 제목으로 -->
    <?php if($this->data['title'] != 'Main Page') { ?><h1 id="tagline" class="firstHeading"><?php $this->msg('tagline') ?></h1><?php } ?>
    <!-- 대문 이름대신 서브페이지에 제목으로 -->

    이렇게 수정하시면 좌측 서브메뉴에 첫번째 제목으로 수정됩니다.

    고맙습니다.

  5. 디백과 2010.07.14 01:25 신고 address edit & del reply

    감사합니다!덕분에 많은걸 배웠습니다^^

  6. 구종회 2011.06.12 13:27 신고 address edit & del reply

    아.. 위키사용하면서 답답했던 부분이 해결되었습니다. 감사합니다~

  7. 고래소년 2011.10.21 10:14 신고 address edit & del reply

    안녕하세요~!^^ 기존 위키를 미디어위키로 이전하는데 큰 도움이 되었습니다. 감사합니다~!

  8. 나그네 2012.07.12 15:57 신고 address edit & del reply

    잘 보고 갑니다. 위키홈피 제작에 관심이 생기네요

  9. 가람빛 2013.01.24 03:06 신고 address edit & del reply

    잘 읽었습니다. MediaWiki겨우 설치하고 막막했는데..

  10. 헬프미 2013.12.06 03:07 신고 address edit & del reply

    주소가 자구 리다이렉션 되는데 어떻게 수정해야될까요??;
    외부접속은 어떻게 하죠?

  11. 이태호 2014.08.17 13:29 신고 address edit & del reply

    안녕하세요 상명대학교 10학번 이태호 입니다.
    저번에 MITA학회에서 뵜었는데..ㅋㅋ
    연구실 홈페이지를 만들기위해 정보를 찾다가 우연히 들어왔는데
    교수님 블로그인것을 보고 깜짝 놀랐습니다!
    종종 방문하도록 하겠습니다 :)

2008.11.25 21:00

오래된 주제...애플리케이션의 복잡도를 새로운 관점으로...

과거에 소프트웨어 위기(Software Crisis)가 있었다. 이는 미국 인력의 대부분이 소프트웨어 개발에 매달려도 해결하기 힘들만큼 전체 시스템에서의 소프트웨어 비중이 커졌을 뿐 아니라, 복잡해졌기 때문에 발생한 위기였다. 소프트웨어에 대한 의존도가 그만큼 커지면서, 소프트웨어 오류로 인한 피해도 심각해졌다. Therac-25의 의료사고나 Ariane의 폭발사건 등은 너무나도 유명한 사례들이다. 대부분의 프로젝트들은 실패했고, 많은 자금이 낭비되었다.

컴퓨터공학자들은 이렇게 비용면에서 비효율적인 이유는 적절히 개발 관리가 되지 않기 때문이라고 생각했는데, 바로 그 관리를 하기 위해서는 개발 과정에서 등장하는 여러 상황이나 요소들의 상태를 판단하고, 적절히 제어할 수 있어야 했다. 결국, 대상에 대한 정확한 측정이 필요했다. 대상을 여러 기준에 따라 수치에 따라 측정한 값으로 판단하고, 계획하기 위해서였다. 그리하여, 소프트웨어 척도(Metrics)는 소프트웨어 공학이 생기는 초기부터 주목을 받아왔다.

하지만, 척도라는 것은 너무나도 다양한 요소들의 영향을 받는다. 뿐만 아니라, 측정의 대상도 빠르게 바뀌기 때문에 매번 척도에 적용되는 변인들을 새로 고려해 주어야 했다. 분명 중요한 문제임에도 불구하고, 정확한 측정이 어렵기 때문이다. 그래서, 아직까지도 가시적인 성과를 내지 못하고 있는 분야이다.

잠깐, 이야기를 돌려서... 우리가 소프트웨어를 설계할 때는 한 가지 관점으로 보지 않는다. 구조적, 행위적, 논리적 관점 등 다양한 관점이 존재한다. UML 모델 다이어그램을 보더라도 클래스 다이어그램, 액티비티 다이어그램, 인터랙션 다이어그램 등 10가지가 넘는다. 이러한 다양한 관점들의 설계가 모여서 애매모호함을 제거하고, 소위 말하는 오차를 줄여주는 역할을 한다.

복잡도의 경우도 마찬가지이다. 대부분의 복잡도는 크기와 상당한 관계를 가지고 있다. 그러므로, 소프트웨어의 크기와 복잡도를 거의 유사하게 생각하기도 한다. 하지만, 실제로는 크기와 상관없이 복잡도를 가지기도 한다. 아무리 크기가 작더라도 구조적으로 복잡할 수 있고, 간결한 구조를 가진다면 크기가 크더라도 오히려 간단하게 느낄 것이다. 우선 생각해볼 수 있는 것이 바로 이러한 구조적 복잡도이다. 구조적 복잡도는 크기를 어느 정도 반영하기는 하지만, 큰 관련을 가지지는 않는다. 바로, "엔트로피"가 구조적 복잡도를 측정할 수 있는 좋은 방법 중 하나이다.

엔트로피는 열역학에서 그 유래를 찾을 수 있지만, 정보공학에서 이야기하는 엔트로피는 섀넌(C. Shannon)의 1948년 논문인 "A Mathematical Theory of Communication" 에서 시작되었다고 볼 수 있다. 엔트로피는 가장 효율적인 정보 압축의 한계를 계산해주기도 하는데, 평균 정보량 또는 모호함의 정도를 의미한다. 각 객체의 정보량을 그 확률로 곱해서 합한 값이 바로 정보 엔트로피이며, 각 객체의 정보량은 그 객체의 확률에 밑이2인 로그를 취한값에 마이너스를 붙혀서 만든다. 셰넌은 자신의 논문에서 아래와 같은 일반적인 커뮤니케이션 모델을 가정했으며, 정보 소스로부터 목적지로 정보가 전송된다고 가정했다. 실제로 엔트로피는 모호함의 증가치를 나타내기 때문에, 최종적으로 우리의 모호함이 0이 되는 것으로 계산하면 원래 대상에 대한 전체 모호함의 크기가 나오게 된다.
정보 엔트로피에 대해 더 자세히 알고 싶으면, http://en.wikipedia.org/wiki/Information_entropy 를 참고하여 관련 링크들을 읽어보기 바란다. (하지만, 엔트로피를 이해하기 위해 수식까지 모두 이해할 필요는 없다고 생각된다.)


그 외에도 엔트로피는 객체의 복잡도를 측정하기 위해 사용되기도 했다. 객체 지향 시스템 등을 대상으로 몇몇 연구들이 존재한다. 이를 웹 애플리케이션에 대해서도 생각해볼 수 있는데, 각 페이지에 대한 참조 확률을 바탕으로 엔트로피를 이용하는 방법이다. 즉, 웹에서는 웹 소스로부터 개발자에게로 구조적 정보가 전달된다고 본다. 다음은 이러한 방법으로 계산된 복잡도 결과를 일부 보여준다.


총 3개의 실제 웹 애플리케이션의 엔트로피값은 중간에 파란색 선으로 표시된 것이고, 양쪽의 히스토그램에서 오른쪽의 것은 랜덤 생성한 웹 애플리케이션, 왼쪽은 재구조화(CCA모델로 재구조화)시킨 결과 얻어진 엔트로피의 빈도로 히스토그램을 나타낸 것이다. 실제로 3번째 웹 애플리케이션은 2번째 보다 페이지 수도 20개 정도 많고, 관계의 개수는 1000개(4배) 가량 많기 때문에, 크기로 비교한다면 2번째 보다 3번째 애플리케이션이 크다. 하지만, 엔트로피는 더 작을 수 있음을 보여준다. 그만큼 단순한 구조를 가지게 되면 구조에 대한 모호함이 줄어들기 때문에 엔트로피값이 낮아진 것이다.

물론, 이러한 결과 때문에 실제로는 크기의 영향을 많이 받는 예측되는 오류의 개수나 이해 노력도 등 다른 품질 요소들과의 관련성이 떨어질 수도 있다. 이러한 이유 때문에, 엔트로피는 유사한 크기의 애플리케이션 구조 복잡도를 비교하거나 동일한 애플리케이션이 진화하는 과정을 모니터링할 때 더 유용하다.

지금까지 엔트로피에 대해서만 이야기했지만, 복잡도에 영향을 주는 또다른 요소도 있다. 바로 "유사성"이다. 극단적인 예를 들면, 100개의 동일한 페이지와 5개의 서로 다른 페이지를 비교한다면, 분명 5개의 서로 다른 페이지를 이해하는데 드는 비용이 더 클 것이다. 즉, 크기는 작더라도 복잡도는 더 높아지게 된다. 이러한 이유로 유사한 개체들을 많이 포함한 시스템은 덩치가 크더라도 단순할 수 있다는 것이다.

그 외에도 복잡도에 영향을 줄 수 있는 요소들은 많이 있다. 다양한 복잡도 요소들에 대해 분석하고, 이들을 묶어서 일종의 패턴으로 본다면, 훨씬 정밀한 비용 예측이나 복잡도 계산을 할 수 있으리라 생각한다. 복잡도는 분명 중요한 연구 주제 중 하나이지만 어렵고 재미가 없는 주제이기도 하다. 너무 재밌는 주제만 하다가 가끔 실증이 날 때, 이러한 조금은 답답하고 그리 좋은 결과가 나오지도 않는 오래된 주제들을 다뤄보는 것도 좋을 것이라 생각된다.

"코드가 복잡하다고 느끼는 이유는 무엇일까?" 또는
"아키텍처가 복잡하다고 느끼는 이유는 무엇일까?"

이러한 질문들에 대한 새로운 관점이나 해석이 연구의 출발점이 될 것이다.
신고
트랙백이 없고 Comment 4
  1. 넘버3 2008.12.02 13:24 신고 address edit & del reply

    잘 알지 못하지만 엔트로피에 대해서 관심을 가지고 있었는데, 좋은 내용의 글로 생각합니다.
    소프트웨어나 개발쪽에서 엔트로피에 대해서 공부를 하려면 어떤 것을 참고하면 될까요?

    이 댓글 보시면 꼭 좀 답변 남겨주세요.

    감사합니다.

    • swinside 2008.12.09 22:00 신고 address edit & del

      몇몇 논문들이 있습니다. 주로 OO관련한 것들이 있구요. 엔트로피 이론과 관련한 내용은 위키피디아를 통해 보시면 관련 좋은 링크들이 많습니다.
      이를 SE와 관련지은 논문들은... 주로 메트릭 관련이 많지만... 다음과 같은 것들이 있습니다.

      ** 유명한 셰넌의 A Mathematical Theory of Communication 이 아무래도 제일 시작점이구요.

      ** W. Harrison, "An Entropy-Based Measure of Software Complexity," IEEE TSE, vol.18, no.11, 1992. ( 좀 옛날 논문이지만, SE관련으로 엔트로피 기반 메트릭 기본이 되는 논문...)

      그리고 저자가 Kapsu kim인 "Complexity Measures for Object-Oriented Program Based on the Entropy"는 연구실 선배님이 쓰셨던 논문입니다.

      첨언하면... 엔트로피는 크기 기반은 아니지만, 분명 "복잡한 정도라거나 무질서도와 관련이 있어서" software fault의 밀도와 관련성이 있는 것으로 알고 있어요. 전체 개수와는 상관없구요.

      여튼 뭐 엔트로피 이론이라는 것이 워낙 좀 우주 전체에서 나타나는 현상인지라... 인위적인 사람들의 개발 대상물에서도 나타나는지는 아직까진 모르겠지만... 잘 찾아보면, 그럴싸한게 있을지도 모르겠어요^^;

      그리고, 이건 한글 사이트이지만, 정보이론에 대해 꽤 쉽게 잘 정리되어 있는 내용이라서 링크 알려드립니다.
      http://www.aistudy.com/control/information_theory.htm

  2. 화사 2008.12.10 12:43 신고 address edit & del reply

    복잡도에 대한 관점이 어떤 기준에 따라 크게 달라질 수 있다는 생각을 해봅니다.

    코드가 OOP로 디자인 되어 있고, 이에 대한 복잡도를 측정한다고 할 때,
    디자인 패턴을 공부한 사람이라면 복잡한 계층을 가진 OOP 프로그램도 단순하게 느껴질 것이고, OOP를 알더라도 디자인 패턴을 공부하지 않은 사람에게는 매우 복잡하게 느껴질 것입니다..

    즉, OOP를 직관적인 관점에서 복잡도를 이해할 것인가, 디자인 패턴 관점에서 이해할 것인가에 따라 복잡도는 상이하다고 보아지는데요.

    웹 프로그램이라면 MVC 구조라든가, 객체DB라든가 하는 것을 사용하면 관점에 따라 더 복잡해 보일 수도, 덜 복잡해 보일 수도 있을 것 같습니다.

    또 다른 예로, MFC가 프로그램 구조를 복잡하게 하는 것인가? 단순화 하는 것인가?는 관점에 따라 틀린 것 같습니다.

  3. 이장석 2011.02.25 10:44 신고 address edit & del reply

    글 잘 보았습니다.
    좋은 하루 되십시오.

2008.11.05 03:55

박사학위 받던날!

늦은 나이와 영어의 압박은 가지고 시작했던 박사공부. 수업듣고 연구하면서 어려운 적들도 있지만 참 재미있게 공부한것 같다. 어렵게 잡은 박사 타픽에서 좋은 결과가 나왔고 디펜스 날짜가 잡히고... 

아래 디펜스 슬라이드가 있지만 나의 연구는 소프트웨어 개발 history에서 버그 패턴을 찾아 보는 연구이다. 어느 부분에 버그가 집중되는지를 캐쉬알고리즘으로 풀었고 소프트웨어에 변화가 생길때마다 이 변화에 버그가 있는지를 학습하여 새로운 변화가 있을때 버그가 있을지를 예측하는 연구였다.
Dissertation Defense
View SlideShare presentation or Upload your own. (tags: slides)

한시간 정도 공개 발표에 심사 교수님 3분과 비공개 심사가 이어졌고 심사결과를 기다리고 있는데 아래와 같은 메일이 날아 들었다.  
Dear All,

Please join me in congratulating Dr. Sunghun Kim who very
successfully defended his dissertation on "Adaptive Bug Prediction by
Analyzing Project History."

[...]

Congratulations, Dr. Kim, and all the best!

- Jim

지도 교수님이 친히 전체 학과 교수, 학생들에게 축하 메일을 보내 준것이다. 또 공식 심사가 끝난후 연구실에서 친히 칵테일 파티를 열어 주셨다. 제자를 아끼는 지도 교수님, 함께 축하 하는 심사위원들, 연구실 친구들, 대학원생 동료들 사이에서 나는 그동안 공부했던것들, 연구주제가 생각나지 않아 힘들어 했던것들 등등이 떠올랐다. 그간 힘들었던 시간만큼 오늘의 이 순간은 더욱 큰 감동으로 다가 왔다. 이런 큰 감동을 원하시는 분들에게 박사 학위도전을 추천합니다.
저작자 표시 비영리 변경 금지
신고
트랙백이 하나이고 댓글이 없습니다.
2008.11.05 03:33

소프트웨어 관련 학회 지도

HannaKim 과 Tao Xie 가 운영하는 소프트웨어 학회 지도 (http://ase.csc.ncsu.edu/semap/) 를 이용해 보세요. 어디에서 소프트웨어 관련 학회가 열리는지를 한눈에 볼수 있습니다. 우선 가고 싶은 지역이 있으면 선택하시고 논문을 내면 되겠죠?


아쉬운 것은 주로 소프트웨어 관련 학회가 유럽과 미국에서 열리고 아시아에는 그리 많지도 않고 한국에는 더 적다는 것입니다. 할일이 많다는 것이겠지요? 여러분이 컨퍼런스를 운영한다면 자신의 학회가 이 지도에 표시 될 수 있도록 요청할 수 있습니다.

저작자 표시 비영리 변경 금지
신고
트랙백이 없고 댓글이 하나 달렸습니다
  1. 김태호 2009.07.26 10:12 신고 address edit & del reply

    교수님 작품이란 걸 알고 놀랬습니다. ^^ 정말 대단하세요.

2008.11.03 22:27

버그 넘기기 (Tossing Bugs)

보통 잘 되어있는 소프트웨어 개발 프로세스를 보면 사용자들로 부터 버그 리포트 등을 받게 되면 이를 관리자가 검토한다음 수정해야할 버그라고 생각되면 담당 개발자에게 할당 (Assign)하게 된다. 그런 다음 이 개발자는 자신에게 적당한 버그면 수정을 하고 그렇지 않다면 이 버그는 다른 새발자에게 넘겨준다 (Tossing)

보통 버그는 몇명에게 Tossing된 다음 Fix 될까?
이 Tossing에 어떤 패턴이 있을까? 늘 Tossing하는 사람들의 그룹이 있을까?

그래서 Mozilla의 버그 리포드 35만개를 가지고 실험을 해보고 이런 그래프를 얻었다. 어떤 버그는 무려 24명의 개발자가 할당되기도 했다.



우선은 데이타 량이 너무 많이 그림이 복잡한데 하나의 노드는 개발자나 메너저를 의미하고 하나의 화살표는 100번의 버그 Tossing을 의미 한다.

재미있는 형태의 그래프가 나오긴 했지만 무엇에 사용할 수 있을까?

우선 1. 개발자들의 그룹을 자동으로 알수 있게 된다.
2. 혹 개발자들간의 그룹이 확연하게 나타나면 버그를 할당할때 해당 그룹 모두에게 할당하여 서로간의 할당 시간을 줄일 수 있지 않을까?
3. 메니저가 버그를 할당할때 이 그래프가 힌트를 줄 수 있을까?

여러분들이 한 소프트웨어 프로젝트의 메니저이고 자신의 팀들의 버그 Tossing관계를 보여 준다면 어디다 사용할수 있을까요?


저작자 표시
신고
트랙백이 없고 Comment 3
  1. 화사 2008.12.10 12:33 신고 address edit & del reply

    저라면 유사 버그 발생시에 이번 버그와 가장 유사한 기존 발생 버그를 찾아내서, 그 버그를 해결한 사람에게 의견을 구하겠어요. 3번 처럼 매니저가 버그 할당시 그래프가 도움이 되겠네요.

  2. Gurutect 2011.08.09 22:48 신고 address edit & del reply

    35만개의 버그리포트를 가지고 나온 그래프라서 그런지...매니저라면 안 볼것 같습니다..^^;;
    대신 토싱하는 사람들에 대한 정보가 있으니... 코드리뷰를 할때 자동으로 reviewer로 추천하면 좋을것 같네요. 그리고 기존에 유사한 버그를 해결한 사람에게 의견을 구할수도 있지만, 어떻게 해결을 했는지 연결을 시켜서, 리뷰시나 defect을 fix할때 참고할 수 있도록 해놓으면 좋을듯합니다.

  3. sangheestyle 2012.05.13 17:02 신고 address edit & del reply

    다음 팀 빌딩때 tossing이 자주 발생하는 그룹을 한 팀으로 엮는 시도를 해볼수 있을것 같습니다. Tossing이 자주 발생하는 문제의 경우 한 사람의 역량보다 여러명의 역량과 뷰가 필요한 경우가 있는데, 팀이 다른 경우 이해관계등에 의해서 협업이 깨져 비용이 더 드는 경우를 많이 봐왔습니다. 따라서 다음 팀 빌딩(예. 조직 변경)시에 이를 이용해서 tossing이 덜 일어나도록, 일어나더라도 그 횟수가 줄도록 하는게 좋을거라 생각합니다. 더불어 Gurutect 님의 말씀처럼 reviewer 로 추천하는것도 좋은것 같기는 한데, 그렇게 하면 너무 많은 메일을 받을 수 있다는 단점도 있기는 합니다. (실제 그런 사례를 보니 관련자들이 고통스러워했습니다.) :0

2008.11.03 02:21

[인터뷰후기] 2008년 미국 공학계열 대학교

 저는 공학계열 학생으로 올해 미국학교 30여군데를 지원하여 전화 인터뷰를 포함하여 8군데 인터뷰를 받았습니다. 그중 최종 5군데 방문 인터뷰를 받았고 (3곳은 전화 인터뷰후 떨어 졌습니다.) 몇군데 대학에서 오퍼를 받았습니다. (더 올지도 모르지만) 그동안 인터뷰 하면서 제가 경험했던것을 미래의 교수를 꿈꾸는 여러분들과 나누고자 합니다.

* 전화 인터뷰 - 이것이 저에게는 가장 어려운 것 중 하나였습니다. 우선 약한 영어에 잡음 섞인 전화소리를 듣고 답을 하는것이 힘든것 같았습니다. 가장 중요한것 중 하나가 목소리의 자신감과 연구 이야기때 exciting하다는 것을 전달 하는 것인데 어떤분이 이야기 하신것 처럼 핸즈프리 같은 것을 사용하여 일어서서 통화를 하는것이 도움이 되었습니다. 질문은 대부분 연구나 앞으로의 연구 방향에 대한 것들이었습니다. 제가 전화 인터뷰에서 떨어진 곳 중 하나는 굉장히 철학적인 질문을 하는 곳이였습니다.
- X 분야에서 가장 큰 문제가 뭐냐 (난 내가 하는 분야도 잘 모르겠는데)
- 최근 20년 동안 X 분야는 어떻게 발전했냐?
- 앞으로 10년동안 뭐가 좋은 연구 분야일까?

* 온사이트 인터뷰: 학교를 방문하여 하루 이틀정도 교수님들 10~20명까지 만나는 흥미 진진한 인터뷰입니다. 주로 호텔에 있으면 학과장이 데리러 오고 인터뷰 끝나고 다시 데려다 주는 아주 호의속에서 진행됩니다. 체력이 소진되거나 또 인터뷰 전에 잠자기 어려운 경우가 있는데 토끼눈으로 그다음날 가면 탈락하기 쉽니다. 잠들기 힘드신 분은 수면제등을 복용하여 그전날 10시정도 잠자리 드는것도 좋은 방법이라 생각합니다. 인터뷰 당일날 물을 많이 마시시고 인터뷰 중간 중간에 화장실 break를 달라고 해서 2~5분 정도 쉬는것이 큰 도움이 되었습니다.

** 1:1 - 보통 30분에서 한시간 정도 진행되었는데 연구 이야기와 학교, 생활 이야기로 자연스럽게 학회등에서 처음 사람 만나서 자연스레 이야기 하는 분위기가 되면 좋을것 같습니다. 좋은 인상을 남겨야 하는데 방법중 하나는 역시 본인의 연구 이야기 할때 (약간 침을 튀기며) 흥분된다는 것을 강하게 보여 주는 것이니다. 그리고 가급적 많이 웃어서 이 친구랑 일하고 싶다는 좋은 인상을 남기면 성공인것 같아요.

** 발표 - 보통 1시간 에서 1시간 반정도 하는데 전공 교수님들 말고는 이 친구가 잘 가르칠 수 있을지를 시험해 보는것 같았습니다. 저는 쉬운 내용으로 설명했고 자세한 사항은 1:1에서 이야기 하자고 했습니다. 어떤 학교는 아예 학부 4학년 학생들이 이해할 수 있는 내용으로 해달라고 하는곳도 있었습니다.

** 저녁식사 - 대부분의 미국학교는 첫날 인터뷰가 끝난후 커미티및 전공교수들 2~5명이 모여서 후보와 함께 저녁을 먹습니다. (이것도 인터뷰의 연속입니다.) 개인적으로는 이것이 저에게 가장 큰 어려움이었습니다. 저는 한국에서 학부를 하고 미국에서 공부를 해서 영어도 약하고 이들의 문화도 잘 모르는 것이 큰 단점이었습니다. 온갓 이야기 들이 다 나옵니다. 대처 방법에 대해서는 아래에 *배운점* 에서 더 이야기 하겠습니다.

* 인터뷰 후
인터뷰 후 느낌이 좋은곳도 있고 느낌이 안좋은 곳도 있는데 오퍼 받는데는 그 느낌이랑 별 상관이 없었던것 같습니다. 어떤 곳은 너 인터뷰 잘했고 좋은 소식이 갈것 같다는 이야기 까지 하고는 연락이 없는 것이 있습니다. 너무 첫 느낌에 많은 기대나 실망은 금물!

인터뷰 후 저는 주로 저를 호스트 한분이나 Search Chair에게 간단하게 감사하다는 메일을 보냈습니다. 감사메일도 오퍼에는 크게 작용을 하지는 않는것
같았습니다만 예의를 표하는 정도로 가볍게 하시면 좋을것 같습니다.

* 긴 기다림 후....
그런다음 기다림은 참으로 길었습니다. 아침에 일어나면 메일함부터 열어 보고 뭔 소식이 있나? 보통 오퍼는 전화로 옵니다. (또는 이메일을 보내 통화 하고 싶다고 어디로 언제 연락하면 좋겠냐 물어 본다음 전화 옵니다.) 전화통화 내용은 주로 구두로 너에게 오퍼를 주고 싶은데 너 지금 상태가 어떤지, 우리학교 오고 싶은 생각은 있는지 물어 봅니다. 전 가고 싶다고 그렇게 말했고 어떤 학교는 집요하게 우리학교가 너의 리스트에서 몇 순위인지를 물어 오는 곳도 있었습니다. (거짓말을 해야 하는지 정말 힘들었는데) 그냥 저는 보통 one of top choices 라고 말해 주었습니다. 그러면 그쪽에서 서류 작업에 들어가고 1주 정도후에 PDF나 메일로 정식 offer가 옵니다. 그리고 대부분의 학교는 2주에서 한달 정도 오퍼를 결정할 시간을 줍니다.

* 첫 오퍼를 받은후
첫 오퍼를 받는것이 매우 중요합니다. 자신감도 생기고 좀 까다로운 학교에는 "나 이미 오퍼 있어" 이런 마음으로 당당하게 대할 수도 있고. 무엇보다 중요한것은 첫 오퍼후 내가 가고 싶은 학교 오퍼를 기다리는 경우 입니다. 이럴때 당당하게 가고 싶은 학교 head나 Search chair 에게 전화를 해서 나 오퍼 있는데 너네 오퍼 줄거야 말거야 물어 볼 수 있습니다. 대게 첫 오퍼를 일찍 받은 후보들이 다른곳에서도 많은 오퍼를 받는 것을 보았습니다. 물론 실력이 있어서 첫 오퍼를 빨리 받은 것이지만 오퍼가 있는 후보는 실력이 있어 보이기도 하는것 같았습니다.

* 멀티 오퍼
성공적으로 하셔서 멀티 오퍼를 받게 된다면 또다른 (행복한) 고민의 시작입니다. 다들 학교들에 장단이 있어서 결정하기가 쉽지 않은 경우가 많지요. 그리고 오퍼를 거절하기도 쉽지 않고. 이부분은 행복한 고민이라 여러분들에게 맡깁니다.


* 인터뷰 하면서 배운점들

1. Small talk 준비 - 인터뷰 한달 전부터 NY Times등 미국 신문들을 많이 읽고 갔으면 참 도움이 되었겠다 하는 생각이 들었습니다. 저는 중간 부터 했는데 1:1에서 분위기 썰렁해지거나 저녁에 2~3시간 모여서 이야기 할때 재미난 세상 이야기들을 자연스럽게 주도할 수 있으면 5점 Plus

2. 자기 전공및 조금 넓은 분야에서 재미난 애피소드 준비 - 이건 정말 필요한것 같아요. 자신의 전공에 대한 이해와 관심이 넓다는 것도 보이고 또 사람들이 관심이 많아요. 저희 분야 같은 경우에는 "연구실 문을 열어 놓고 연구하는 사람이 성공한다" 이런 글을 읽은 적이 있는데 이런것에 대해 자연스레 소개하고 그 이유를 이야기 해주니 사람들이 많이 관심있어 했습니다. 이런 재미있는 에피소드 5정도 준비하시면 든든합니다.

3. 첫 오퍼 받기 좋은 학교를 집중 지원 - 본인의 실력에 맞게 학교를 지원해야 하겠지만 첫 오퍼를 받기 좋은 (원서를 일찍 받으면서 만만한) 학교들을 집중적으로 지원하여 첫 오퍼를 빨리 받으면 좋을것 같아요. 인터뷰 중에서도 가끔 물어 보는데, 나 오퍼 있어 이렇게 하면 기분도 아주 좋고 그쪽에서도 잘 봐주는것 같았어요. (내가 보긴 그런데 이 친구 벌써 오퍼 받았다는데 뭔가 있나 보다...)

4. 서치 커미티를 알라 - 학교마다 사정이 다르지만 보통 만난 교수들이 feedback을 서치 커미티에 보내면 그 정보를 바탕으로 서치 커미티가 모여 이야기 한다음 후보자들의 순서를 매깁니다. 그래서 보통 1, 2 등 후보에게 순차적으로 오퍼가 가고 나머지는 아쉽지만 탈락이 됩니다. 그런데 이야기 들어 보니 2, 3, 4등간의
차이가 그리 심하지 않을 수도 있는데 그 마지막 결정을 서치 커미티가 한다는 것입니다. 물론 모든 교수들에게 좋은 인상을 주는것이 중요하지만 이미 서치 커미티 멤버들을 알고 인터뷰를 보시고 그들의 마음을 완전 사로잡는것이 참 중요한것 같습니다.

5. 추천서 - 미국 학교 사정에서 가장 중요한 것입니다. 일차로 원서를 확 추린 다음 마지막 인터뷰 대상자는 추천서를 읽어 보고 결정하는 학교가 대부분입니다. 일부 교수님들 추천서를 솔찍하게 서주는 경우가 있는데 이렇게 추천서에 흠이 있으면 대부분 마지막 인터뷰 대상에서 제외입니다. (인터뷰중 그쪽 Search 를 담당했던 친구에게 들었습니다). 추천서를 받을때 유명한 사람에게 받는것도 중요하지만 정말 자신을 잘 알고 추천서를 잘 써주는 사람을 찾아야 합니다.

6. 교수직 준비는 빠르면 빠를 수록 좋다 - 저는 연구에만 집중(?) 한다고 이런 부분을 거의 생각하지 못했는데 대학원 학생들 중에 교수를 원한다면 그 준비는 빨리 하는 것이 좋을것 같습니다. 준비중 가장 중요한 것은 Network 이나 Collaboration입니다. 학회가시면 한국 분들이랑만 hang out 하지 마시고 본인이 가고 싶은 학교의 교수님들과 안면을 트고 자신이 참 멋진 사람이고 중요한 연구를 하고 있다는 인상을 주면 됩니다. 어자피 전공이 조금 다를 경우 하는 연구 내용은 잘 모르니 이야기 하실때 항상 흥분하는것을 잊지 말아야 합니다. 개인적으로 제가 아는 사람이 있는 학교는 대부분 전화인터뷰나 온사이트 인터뷰를 받았습니다. 미국에서도 인맥 중요

7. 정말 교수를 하고 싶은가? - 박사과정을 하기전에 잘 생각해 보는 것이 좋습니다. 솔찍하게 말해서 인터뷰를 다본후에 정말 내가 교수를 하고 싶은 것인가에 하는 자문을 해보았습니다. 엄청난 펀딩의 압력 (보통 한해에 10개의 프로포절을 작성), 논문 작성 그리고 그 결과를 기다려야 하는 초초하고 지루한 시간들, 바운드리 없는 근무시간, 적은 월급 등등을 감수하고서라도 학생들을 가르치고 또 자신이 하는 연구 분야를 Advance하는 그런 강한 소신감이 있어야 할것입니다. 석사 정도를 하고 회사에 취직하는것도 다른 좋은 길이 될 수 있으니 너무 늦기 전에 잘 생각해 보시고 결정하시는 것이 좋을것 같습니다.
저작자 표시
신고
트랙백이 없고 Comment 3
  1. Andy 2009.06.24 01:19 신고 address edit & del reply

    좋은 후기 잘 보고 갑니다 ^^

  2. 정영범 2010.11.02 16:58 신고 address edit & del reply

    도움이 되었습니다. 감사합니다.

  3. 2011.02.23 16:07 address edit & del reply

    비밀댓글입니다



티스토리 툴바