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

    비밀댓글입니다

2008.11.03 01:13

간단한 Subversion Branching/Merging

서버버전을 사용하여 소스코드 checkout 및 commit은 많이 하는데 왠지 branch를 만들거나 merge하려니 이거 좀 복잡한 생각이 들때가 있고 메뉴얼을 읽어 봐도 북잡하기만 하다.

그러나 Branch의 기능은 전제 Team의 개발에 영향을 주지 않고 혼자서 (또는 소규모 팀별로) 프로그램을 고치고 테스트 하고 잘 될때 head로 보낼때 아주 유용하게 사용할 수 있다. 서버버전을 사용하면 그 방법도 간단하다.

우선 Checkout 부터 한번 해보자. (Subversion 저장소- https://coolproj.googlecode.com/svn/trunk)


svn co https://coolproj.googlecode.com/svn/trunk/  coolproj
cd colproj
[작업]
svn ci -m"작업 잘 했음. 무엇 무엇 고쳤음. 무슨무슨 버그 잡았음"

이렇게 하는 것이 보통 그냥 branch같은거 사용하지 않고 하는 작업인데 여기서 branch만들기는 너무 간단하다.

svn copy coolproj  https://coolproj.googlecode.com/svn/branches/new-hot-feature

이렇게 하면 끝이난다.

그런다음 이 새로운 branch 를 checkout 해서 작업을 하면 된다.
svn co https://coolproj.googlecode.com/svn/branches/new-hot-feature coolproj-branch

그냥 이전의 coolproj 라는 workspace를 사용하고 싶으면 살짝 'switch' 해주면 된다.


cd dupbug/
svn switch https://coolproj.googlecode.com/svn/branches/new-hot-feature

[작업]
svn ci -m"작업 잘 했음. 무엇 무엇 고쳤음. 무슨무슨 버그 잡았음"

이렇게 checkin 된 코드는 이전에 생성된 branch에 남아 있게 된다.

여러번 작업을 한다음 이 branch가 충분히 훌륭한 관계로 trunk에 보내고 싶다면 merge하면 된다. 우선 바로 merge하기 전에 (trunk가 변했을수도 있으므로) 몇가지 확인 해보자. 우선 --dry-run (예행연습)

svn merge --dry-run  https://coolproj.googlecode.com/svn/branches/new-hot-feature \                                             https://coolproj.googlecode.com/svn/trunk

그러면 무엇이 바뀌는 것인지 보여 준다.

구체적으로 무엇이 달라졌는지 line-by-line으로 보고 싶으면 diff를 사용한다. (주의 URL의 순서가 merge때와 다르게 바뀌었다)

svn diff https://coolproj.googlecode.com/svn/trunk \
            https://coolproj.googlecode.com/svn/branches/new-hot-feature

마지막으로 모든것이 좋아 보여 merge를 하려면 앞에서 dry-run을 하면 된다.
svn merge --dry-run  https://coolproj.googlecode.com/svn/branches/new-hot-feature \ https://coolproj.googlecode.com/svn/trunk

branch와 merge는 작은 단위의 commit이 많이 필요할때는 불필요하게 다른 사람들이 나의 commit을 보이고 싶지 않을때 요긴하게 사용되는 기능이다. 한번만 사용해보면 쉽게 사용할 수 있다. 
신고
트랙백이 하나이고 댓글이 없습니다.


티스토리 툴바