외규장각 도서 환수 모금 캠페인

Search Results for 'Study/Computer Science'

60 POSTS

  1. 2008.03.19 웹 2.0 구글과 MS
  2. 2008.02.27 Computer Science/Engineering 연구
  3. 2007.10.02 AI 과제 - 8Puzzle 구현하기 1
  4. 2007.09.27 파이프( | )와 변수 처리
  5. 2007.09.26 tar와 gzip

웹 2.0 구글과 MS

Posted 2008. 3. 19. 00:02, Filed under: Study/Computer Science
PC와는 달리 웹은 근본적으로 누군가의 소유물이 아니다. 2007년 세계지식포럼(WEF)에서 뉴욕타임스 수석 기자인 존 마코프는 웹2.0을 '인터넷의 레고 시대'라고 정의했다. 개개인이 쌓아 놓은 정보의 조각이 모인 집합체가 웹이라는 의미다.

따라서 웹을 플랫폼으로 활용한다는 것은 대중의 지혜를 내 편으로 만들어 함께 가는 것을 의미하며 이를 위해서는 '개방'이 필수적으로 수반돼야 한다.

구글 지도 서비스인 구글맵을 보자. 일반적인 지도와 다를 것이 없지만 전 세계인이 여기에 열광한다. 2차 가공이 가능하도록 프로그래밍 코드를 개방했기 때문이다.

예를 들어 '우리 동네 맛집'을 나타낸 지도를 만들어 팔고 싶다면 구글맵에 자신이 조사한 맛집 위치를 표기하기만 하면 된다. 같은 방식으로 부동산 정보나 클럽이 표시된 지도도 만들 수 있다. 자신이 정보를 열심히 모아 서비스를 제공해야 한다는 포털 사이트 사고로는 절대 이해할 수 없는 일이다.

이렇게 만든 정보는 다시 모여 웹을 살찌운다. 사용자들이 원하는 정보를 찾게 될 확률이 증가한 것이다. 여기에 인터넷 특성인 양방향성이 추가돼 정보가 3차ㆍ4차 혹은 그 이상으로 가공되면 그 양과 질은 우리 상상을 초월한다.

◆ 기업, 웹2.0에 도전하라

= '왜 구글은 아무거나 해도 다 잘되는 것 같지?'라는 생각을 해본 적이 있는가.

플랫폼 리더십을 가진 기업이 강력한 이유는 소비자들이 그 안에 있기 때문이다. MS가 한 시대를 풍미했던 이유도, 설립된 지 10년이 채 되지 않은 구글이 전 세계를 뒤흔드는 이유도 다 같은 맥락이다.

기업은 참여자들이 자기 목소리를 쉽고 자신 있게 낼 수 있도록 80% 기반을 어떻게 닦을지 고민하고 그 안에서 주도권을 가진 소비자가 어떤 방향으로 가는지 눈여겨봐야 한다.
미래는 정해져 있지 않다. 특히 요즘 같이 빠르게 변하는 세상에서 기업 비즈니스 환경이 어떻게 변할지 아는 사람은 아무도 없다.
한 가지 확실한 것은 소비자들과 함께하는 기업은 미래가 밝다는 것이다. 웹2.0이라는 패러다임 전환과 그 중심에 선 소비자 변화, 이들과 함께하기 위해 기업은 웹 플랫폼 전략이라는 새로운 접근 방식을 고민해 봐야 할 것이다.
Response : ,

Computer Science/Engineering 연구

Posted 2008. 2. 27. 20:05, Filed under: Study/Computer Science
Computer Science/Engineering 연구

물리학, 화학, 수학과 같은 자연과학은 신이 만들어 놓은 자연의 이치를 깨닫고자 하는 학문입니다. 진짜 신이 수소, 산소, 질소 등등의 각종 원소를 이용해서 물질을 만들게 하셨는지는 아무도 모릅니다. 단지 과학자들이 하는 일은 현상을 잘 설명할 수 있는 그럴듯한 가설을 만들고 그것이 현상을 제대로 설명하는지를 확인하는 일을 반복할 뿐입니다. 따라서 자연과학에는 "왜?" 그렇게 되었는지에 대해서 물을 필요도 없고, 단지 발견과 경탄만이 존재할 뿐입니다.

그러나 우리가 업으로 삼고 있는 computer science 혹은 computer engineering 분야는 신이 만든 것이 아니라 사람이 만들어 놓은 computer system을 학문의 대상으로 합니다. 따라서, 자연과학과는 본질적으로 학문의 성격이 틀릴 수 밖에 없습니다. Computer science에서의 연구는 어떻게 돌아가는지 "발견"을 하는 연구가 아니라, "왜" 그렇게 만들었는지를 알아내고, "어떻게 하면" 더 잘 만들 수 있을까 위주로 연구가 이루어지게 됩니다. 몇몇 사람들에게 이미 우스개소리로 말한 바 있지만, 결국 연구의 시작은 남이 한 일에 대해서 트집을 잡는 것부터 시작되는 것입니다. 논문을 하나 읽으면, 그 논문의 아이디어는 무엇인지, 어떻게 자신의 아이디어가 좋다고 설득을 했는지, 그리고 문제점이나 제한점은 무엇인지 분석하는 습관을 항상 들이기 바랍니다. 이러한 것을 생각해 보지 않는다면, 아무리 많은 논문을 읽어도 연구에 별 도움이 되지 않습니다. (영어에는 도움이 됨)


결국은 창의력 싸움

웅진 씽크빅 CF에서 "이젠 창의력이 경쟁력"이라는 말이 나오는데 예전에는 저도 창의력이 그렇게 중요한지 아무 생각이 없었습니다만, 요즘 들어서는 결국은 창의력이 문제라는 생각을 하게 됩니다. 일단 다른 사람이 한 일에 대해서 트집을 잡았다면, 자신이 했다면 어찌 했을지를 생각해 보아야 하는데 이 부분에서 창의력 있는 사람과 창의력 없는 사람이 드러납니다. 만일 몇몇 논문을 읽고, 중요한 것은 다른 사람들이 이미 모두 파먹어서 나는 별로 할게 없다는 생각이 드는 사람은 일단 자신의 창의력을 의심해 보기 바랍니다. 당신이 그렇게 생각하고 시간을 보내는 사이에도, 꾸준하게 새로운 논문들이 쓰여지고 있습니다.  

처음부터 창의력이 있고, 창의력이 없는 사람이 있는 것은 아니라고 봅니다. 창의력은 계속 이것저것을 생각해 보는 훈련에 의해 충분히 그 역량이 늘어날 수 있습니다. 한가지 권장하고 싶은 방법은, 어떤 논문의 introduction만을 읽고, 혼자 생각해 보는 방법입니다. 논문의 introduction을 읽으면, 그 논문이 대상으로 하고 있는 background와 문제점, motivation 등이 나옵니다. 그럼, 그 부분에서 논문 읽는 것을 중지하고, 해당 문제점을 해결하기 위해 자신이라면 어떤 식으로 approach 하겠는지를 생각해 봅니다. 또한, 그것을 어떤 방법으로 실험하고 다른 사람에게 설득했겠는지를 생각해 봅니다. 마치, 연구 topic이 주어졌을 때 본인이 그것에 대한 논문을 쓴다고 생각하고 자유롭게 풀어나가라는 뜻입니다. 그런 다음, 논문의 나머지 부분을 읽어보고 자신의 생각과 비교해 봅니다. 비교를 하면 보통 세가지 경우 중의 하나입니다. 첫째, 자신의 생각이 너무 단순해서 논문의 related work에 나와있는 경우 - 그 정도로는 안된다는 뜻이죠. 둘째, 자신의 생각과 논문의 아이디어가 거의 비슷할 때 - 아쉽지만 나도 할 수 있다는 자신감을 갖게 됩니다. 셋째, 논문의 아이디어나 related work에 나와 있는 내용과 다를 때 - 새로운 논문이 될지도 모릅니다. 그러나 다른 사람이 이미 했을지도 모르니 관련 연구를 다시 자세히 조사해 보는 것이 필요합니다.  

대개의 경우 관련 연구를 조사해 보면, 누군가 이미 한 경우가 대부분이지만, 혹시 아무도 자기가 생각한 것을 시도해 보지 않았다면... 결과가 좋게만 나온다면 새로운 논문이 될 가능성이 많습니다. 그러나 십중팔구, 아이디어는 좋은 것 같아서 시도해 보았는데 결과는 생각보다 좋지 않은 경우가 또 대부분입니다. ㅠ.ㅠ 이 경우, 어떤 사람들은 결과가 좋지 않으니 더 해 볼 생각도 안하고 거기서 그냥 하던 일을 접곤 합니다. 그러나 그렇게 되면 투자한 시간과 노력이 전부 날라가게 됩니다. 그 보다는, 무엇때문에 자신이 생각하던 결과와 차이가 나는지를 분석하고, 원래의 아이디어를 수정하고 optimize 해 나가는 것이 바람직합니다.  

가끔 제가 여러분에게 이러저러한 일을 해 보면 어떻겠냐고 할 때에는, 저도 그 결과가 좋을지 나쁠지 정확히 알 수 없는 경우가 대부분입니다. 어렵게 일을 해서 결과를 뽑으면 결과가 안 좋게 나올 때도 있을 것입니다. 그렇다고 해서 거기서 주저앉지 말고, 그 결과를 어떻게 하면 활용하고, 향상시킬 수 있는지 고민하는 사람이 되었으면 좋겠습니다. 한 두 번 생각해서 좋은 생각이 떠오르지 않는다고 포기하면 안 됩니다. 그 정도로 해결이 될 것이라면 이미 누군가는 시도해 보았을 가능성이 많기 때문입니다. 자나 깨나 밥먹을 때나 샤워할 때나 문제를 생각하다 보면 좋은 생각이 떠오르는 때가 틀림없이 있을 것입니다. 정 안되어서 문제를 해결할 수가 없더라도, 자신이 시간과 노력을 들인 일에 대해서는 어떻게 하던지 논문으로 정리를 하기 바랍니다. 논문 내용이 아무리 해도 더 이상 안되더라..가 되더라도 말입니다.  


Discussion의 중요성

창의적인 아이디어는 항상 처음에는 허황되게 보이기 마련입니다. 허황되어 보이는 아이디어를 다른 사람들이 그럴듯하다고 생각되게 만드는 과정이 연구입니다. 자신의 아이디어를 발전시키는 중요한 방법 중의 하나는 다른 사람과 discussion을 하는 것입니다. Discussion을 하는 것은 여러가지 면에서 연구에 중요한 도구입니다. 다른 사람에게 자신의 생각을 논리적으로 설명하려다 보면, 자신의 아이디어도 정리되고, 자신이 빼먹고 있었던 사실도 알게 됩니다. 그리고, 일반적인 경우 다른 사람의 아이디어를 들으면 대부분의 사람들은 부정적인 입장에서 공격을 하게 됩니다. 그러면 그러한 사람들을 설득시키는 과정에서 자신의 아이디어의 장단점이 무엇인지 파악되고, 새로운 아이디어가 나오게 됩니다.

물론 제가 여러분의 discussion 상대가 되겠지만, 여러분끼리의 discussion도 많으면 많을수록 좋겠습니다. 간혹 보면, 이것은 나의 일이고, 저것은 쟤가 맡은 일이라서 서로 간섭하지 않으려고 하는 경향이 있으나 그것은 결코(!) 바람직하지 않습니다. 남이 무슨 일을 하고 있는지 알아서 서로서로 도움을 주고 받을 수 있는 문화가 되었으면 좋겠습니다. 제가 weekly reports를 공개적으로 이 곳 게시판에 올리게 하는 이유도 자신이 하는 일 뿐만이 아니라 다른 사람이 무엇을 하고 있는지에 대해서도 관심을 가지게 하기 위함입니다.


실험에 대한 사전 고려

어떤 아이디어가 좋다는 것을 다른 사람에게 설득하기 위해서는 무엇이 좋아지는지 구체적인 증거를 들이밀어야 합니다. 구체적인 실험 결과가 없이 단지 말로만 이것이 저렇게 좋아진다고 하는 것은 software engineering 같은 데서는 통할지 몰라도, 우리 분야에는 통하지 않습니다. 따라서, 아이디어가 좋다고 해도, 그것을 증명할 방법을 찾지 못하면 그것은 무용지물입니다. (진짜 아이디어가 좋다면 특허는 낼 수 있습니다. 특허에는 아이디어가 좋다고 증명할 필요가 없으므로...)

결국, 적당한 실험이 뒷받침되지 않은 아이디어는 허공에 대고 메아리치는 격입니다. 이것은 바꿔 말하면, 아이디어를 발전시켜 나가는 초기부터 어떻게 실험을 해야 할지 미리미리 고려를 해야 한다는 뜻입니다. 만일, 어떤 주제에 대해서 연구를 시작할 때,  우리가 가지고 있는 infrastructure를 가지고 실험을 해 볼 수 있는 것인지를 함께 생각해 보기 바랍니다. 실제 implementation을 할 수 있겠는지, 아니면 필요한 simulator를 얻을 수 있는지, benchmark로는 무엇을 사용하면 되는지 등등에 대해서 사전 검토가 필요합니다.  

이러한 점에서 저는 예전에 비해 연구 환경이 매우 나아졌다고 생각합니다. 예를 들어, 제가 학교 다닐 때에는 우리나라에서 OS나 architecture에 대해서 연구하기가 매우 힘들었습니다. OS에 관한 아이디어가 있어도 OS source code가 없으니 implement 해 볼 방법이 없었고, architecture에 관한 연구도 이와 사정이 비슷하였습니다. 그러나 이제는 Linux와 같이 source code가 가용한 OS를 이용할 수 있으니, 무언가를 해 볼 수 있는 여지가 많이 생겼습니다. 저는 Linux를 좋아하고 즐겨 사용하지만, open source니 뭐니 그런 것 보다도, 일단 연구의 중요한 도구라는 점에 의의를 두고 있습니다. 이제는 Linux 상에서 무언가를 했다고 해도 그 사실만으로는 태클을 받지 않는 정도의 수준까지 올라왔으니, 학교의 입장에서는 연구를 하는데에 굉장히 큰 도움이 되는 것은 사실입니다. Architecture에서도 요즘에는 SimpleScalar와 같은 좋은 시뮬레이터들이 많이 있어서 연구에 활용되고 있으니, 이제 실험을 못해서 논문을 쓰기 어렵다는 핑계를 대기도 힘들어 졌습니다.

어쨌거나 요약하면, 적절한 실험을 통하여 검증해 볼 수 있는 아이디어만을 일단 연구의 대상으로 하는 것이 좋겠다는 것입니다. 이렇게 하면 단지 장비나 실험 환경이 없어서 여러분의 좋은 아이디어가 사장될 지는 모릅니다. 그러나 검증할 수 없는 아이디어에 대해서 시간을 보내고 있기에는 여러분의 시간이 너무나 한정되어 있습니다. 졸업들 빨리 해야죠...


많은 사람의 관심이 되는 topic vs. 일부의 사람들만 관심있는 topic

연구 topic, 특히 박사학위 논문 topic에는 두가지가 있습니다. 하나는 아주 일부의 사람들만 관심이 있는 topic입니다. 이것은 community도 작고, 관련된 컨퍼런스나 워크샵도 수가 작습니다. 일부의 사람들만 관심이 있는 이유는 다른 사람들이 별로 중요하지 않다고 생각하거나, 현실성이 없거나, 너무 미래지향적이거나 하기 때문입니다. 다른 하나는 많은 사람들이 현재 active하게 연구하고 있는 topic입니다. 이런 분야는 많은 사람들이 달라 붙어있기 때문에 논문도 많이 발표되고 굉장히 속도가 빠르게 진행됩니다.

전자의 경우에는 사람들이 적기 때문에, 경쟁도 그리 심하지 않고, 시간적인 여유도 있고, 잘(!)만하면 비교적 쉽게 논문을 쓸 수 있을 가능성이 있습니다. 그러나 그렇게 논문을 쓴다고 해도 일부의 사람들만 인정을 할 뿐입니다. 반면, 후자의 분야는 내가 하고 있는 것을 남이 한 발 앞서 할 수도 있고, 경쟁도 매우 심하지만, 일단 그런 경쟁을 뚫고 논문을 발표하게 되면, 많은 사람들이 자신이 한 일에 대해서 관심도 갖고 국제적인 지명도도 얻게 됩니다.

두 가지 종류의 topic 중 어떤 것을 선택할 지는, 개개인의 성향입니다. 저보고 추천하라고 하면, 저는 힘들지만 후자를 선택하라고 하겠습니다. 많은 사람들이 연구하는 topic에서 일을 하는 것은 많은 시간과 노력과 때로는 좌절을 수반하지만, 그만큼 보람도 큰 법입니다. 제가 앞서 중요한 conference 들을 언급하였는데, 그러한 conference에 논문을 발표한다는 것은 여러분이 후자의 일을 하고 있다는 뜻입니다.


능동적/공격적인 연구

능동적 연구라고 함은 누가 시키지 않아도 스스로 연구를 해 나아갔으면 좋겠다는 뜻이고, 공격적인 연구라 함은 논문쓰는 것을 두려워 하지 말라는 뜻입니다.  

능동적인 연구를 강조하는 이유가 교수가 논문지도 안하고 놀기 위함은 절대(!) 아닙니다. 석사건, 박사건, 졸업을 하는 것은 지도교수보다는 본인의 역량이라는 점을 명심하시기 바랍니다. 지도교수가 밥상을 차려줄 수는 있어도, 밥을 먹는 것은 본인입니다. 제가 석사 신입생들 면접할 때도 얘기를 했는데, 대학원은 제가 여러분을 귀찮게 하는 곳이 아니라, 여러분이 저를 귀찮게 하는 곳입니다. 언제라도 어떤 문제에 대해 저와 얘기하고 싶다면 제게 찾아오시기 바랍니다. 대부분 제가 잘 알지 못하는 내용이 될 가능성이 높지만서두...^^. 가끔 보면 지도교수가 옆에서 이거해 봐라, 저거해 봐라 하는 경우에는 왜 하는지도 모르고 별로 신도 나지 않은 채로 일을 하지만, 지도교수가 아무 신경도 쓰지 않으면 오히려 불안해서 스스로 연구를 하게 되는 경우가 많은 것 같습니다. 저도 여러분의 졸업과 관련하여서는 귀찮게 하지 않을 작정이니 졸업하고 싶으면 스스로 알아서 하세요.

공격적으로 연구를 하라는 것은 좋은 논문 하나에 집착하지 말라는 뜻입니다. 간혹 보면 대학원, 특히 박사과정에 들어오면 박사 논문 topic을 찾아 헤매서 돌아다니고, 그 외의 일은 신경도 쓰지 않는 것을 봅니다. 큰 거 한 방을 찾는 거죠. 하지만, 논문도 써 본 사람이 잘 쓰는 법입니다. 실제 박사논문 topic을 잡아서 집중적으로 일을 하기 전에, 작은 아이디어라도 논문으로 만들어 내어 보고, 영어 엉터리라고 reject도 당해 보고, accept 되어 다른 사람들 앞에서 영어로 발표도 해 보고 할 기회를 갖기를 바랍니다. 몇 번 해 보면, 대충 어떻게 돌아가는 건지 감도 잡히고, 실제 본 무대에서 뛸 때 도움이 됩니다. 야구 선수들도 처음에는 minor league에서 연습하다가 major league에서 뛰는 것과 마찬가지로, 작은 아이디어라도 실험 결과를 뽑고, 논문으로 만들어서 좀 떨어지는 컨퍼런스나 워크샵에라도 발표하려는 노력을 하기 바랍니다. 제가 생각하기에는 박사 1-2년차때 석사논문 내용이나, 수행한 project, course term project에서 한 일들을 가지고 major/minor conference에 한 두 개의 논문을 발표해 보고, 박사 3년차 이후에 본격적으로 자신의 topic에 대해서 연구하여 major conferences에 논문 2개 이상, 그리고 journal 논문 하나 이상 정도를 쓰고 졸업을 하면 좋겠습니다. 석사과정의 경우에도, 웬만한 conference에 실을 수 있을 정도가 되어야 석사 논문으로 적당합니다. 석사 논문을 쓰면 그것을 정리해서 conference나 정보과학회 논문지에 내어 보는 것을 권장합니다.

또 하나, 능동적/공격적인 연구와 관련하여 제가 강조하고 싶은 것은, 앞에서도 얘기했지만 절대 혼자서 모든 것을 다하려고 하지 말라는 것입니다. 좋은 아이디어가 있으면 혼자 끙끙거리지 말고, 다른 사람과 상의하고 일을 나누어서 하세요. 혼자서 논문 2개 쓰는 것보다, 둘이서 논문 4개 쓰는 것이 훨씬 쉽습니다. 그리고, 같이 일하는 사람이 후배일 경우에는 후배에게 일을 가르쳐주는 효과도 있게 되겠죠.

마지막으로, 대학원에 들어올 때는 순서대로 들어오지만, 졸업은 반드시 들어온 순서대로가 아니라는 점입니다. 때로는 선배를, 혹은 교수를 뛰어 넘어 자신의 능력을 발휘하는 여러분이 되기 바랍니다. 그리고, 석사과정에 있다 하더라도 반드시 4학기를 채워야 할 필요는 없습니다. 3학기만에 조기졸업을 할 수도 있고, 이제 석박사 통합과정이라는 것도 생겼으니 필요하면 이용하시기 바랍니다.


논문의 first author

논문을 쓸 때 주의할 점은 아이디어를 낸 사람이 반드시 first author가 되는 것은 아니라는 점입니다. First author는 기본적으로 해당 논문을 작성할 때 주도적으로 writing을 한 사람입니다. 즉, 아이디어를 A가 냈다고 하더라도, 논문을 B가 썼다면 B가 first author가 된다는 것입니다. 이것은 아이디어를 내는 것에 못지 않게 그 아이디어를 구체적으로 논문화하는 데에도 많은 시간과 노력이 들어가기 때문입니다. 그러니 아이디어내고, 실험 결과만 뽑았다고 해서 자동적으로 first author가 되는 것은 아니라는 점을 명심하시기 바랍니다. 논문의 first author가 되기 위해서는 그 논문을 실제로 본인이 작성해야 합니다.


연구는 타/이/밍

항상 computer systems에서도 resource management가 문제가 되는데, 여러분의 대학원 생활에도 자원 관리, 특히 여러분의 시간 관리가 중요합니다. 대학원, 특히 박사과정에서는 어리버리 하다 보면 시간이 금새 지나가는 수가 많습니다. 박사 1-2년차에는 랩일 하고, 코스웍 듣고 하다 보면 가고, 3년차는 뭔가 해 봐야지 하면서 보내고, 4년차가 되면 슬슬 초조해지기 시작하는데 박사논문 topic은 잘 안 잡히고, 5년차에 다행이 topic하나 잡아서 한 6개월 죽어라 일을 하고 간신히 졸업하면 다행... 인 것이 잘못하면 걷게 되는 여러분의 운명입니다.  

일단 가장 문제가 되는 것은 빨리 졸업해야 되겠다는 motivation의 부재입니다. 그냥 사람들 좋고, 시간 여유 많고, 사회에 나가는 것도 두렵고, 그러다가 보면 대학원 생활에 익숙해 지고, 왜 대학원에 있는지도 모르고, 빨리 나가고 싶은 생각도 없고 그렇게 됩니다. 국내 대학원에 있는 사람과 유학간 사람들을 비교해 볼 때, 대부분 국내에서 박사학위를 하는 사람들이 상대적으로 performance가 떨어진다고들 합니다. 이것이 원래 부지런하고 자기 앞가림하는 사람들이 유학을 갔기 때문이라고 보는 사람도 있으나, 저는 기본적으로 국내에서 박사학위를 하는 대학원생들이 유학간 사람들에 비해 motivation과 긴장도가 떨어지고 열심히 하지도 않기 때문이라고 생각합니다. 제가 그래봤기 때문에 잘 압니다.

여러분이 할 일이 많다는 것은 저도 잘 아나, 대학원에 있는 동안 만이라도 일단은 연구에 우선 순위를 두었으면 하는 것이 제 바램입니다. 졸업하고도 할 수 있는 일은 대학원에 있는 동안은 잠시 미뤄두세요. 그게 싫다고요? 그러면 열심히 연구해서 빨리 졸업하고 그 다음에 하고 싶은 것 실컷 하면 되지 않습니까? 이렇게 얘기한다고 해서 매일 모니터 앞에만 앉아있으라는 말은 아닙니다. 사람이 연구만 하면서 살 수는 없으니까 가끔 기분전환도 하고 술도 마시고, 게임도 하고 그래야 되겠죠. 따라서 결국은 시간 관리를 잘 해야 하는 문제가 되는데, 제가 볼때는 생산성과 집중력이 중요합니다.

연구는 타이밍입니다. 특히 많은 사람들이 관심을 가지고 있는 topic에 대해서 일을 할 경우에는 더욱 그러합니다. 나에게 참신한 아이디어가 있더라도, 내가 어리버리하면서 시간을 보내고 있는 사이 다른 사람이 비슷한 아이디어를 발표해 버리면 내가 들인 시간은 물거품이 됩니다. 가끔 어떤 참신한 아이디어가 있으면, 저는 빨리 결과 뽑아서 논문으로 만들고 싶은데, 정작 그 일을 하는 학생은 여유를 가지고 일을 하는 바람에 제 속만 타는 경우가 있습니다. 저는 누가 먼저 발표할까봐 불안해 죽겠는데 말이죠. 따라서, 같은 일을 하더라도 1년 내내 일을 꾸준히 성실하게 하는 사람보다는, 6개월에 집중해서 끝내고 나머지 6개월을 탱자탱자 보내는 사람이 훨씬 더 낫습니다.  


학자적 양심

나중에 졸업 등에 스트레스를 받게 되면 한순간 실험 결과를 조작하고 싶은 충동이나 다른 사람의 아이디어를 내 것인냥 슬쩍 빌려오는 등의 유혹을 받게 될 경우가 있는데, 이것은 무!조!건! 절!대! 안 됩니다. 왜냐고요? 바로 학자적 양심 때문입니다. 도덕적인 양심이 있듯이, 배운 사람에게는 학자적 양심이라는게 있습니다. 누가 강요하지 않아도 스스로 지켜야 할 선이 있는 거죠.  

일전에 우연히 정보과학회 춘계 학술대회 논문집을 넘겨보다가, 우리 랩 학생이 말도 안 되는 논문을 낸 것을 보고 혼낸 적이 있습니다. 이미 웬만한 사람은 다 알만한 내용을, 심지어 예제 코드로도 많이 나오는 내용을 논문이랍시고 버젓이 쓴 것이 실렸기 때문입니다. 물론 정보과학회 학술대회 논문집을 살펴보면 말도 안되는 논문들이 많은 것은 사실이고, 그런 논문들이 심사 과정에서 걸러지지 않는 것도 문제이긴 합니다. 또한, 정보과학회 학술대회 논문의 경우에는 교수님들께서 일일이 신경을 쓰시지도 않고요. 그러나 그렇다고 해서 그런 논문을 실을 수는 없는 일입니다. 왜냐하면, 많은 사람들이 KAIST에서는 도대체 무슨 일을 하고 있는지 주의 깊게 살펴보고 있기 때문이죠. 여러분이 허접한 논문을 발표하면 여러분 논문 발표 실적에 한 줄 더 쓸 수는 있겠지만, KAIST나 여러분의 지도교수, 혹은 여러분 자신의 얼굴에 먹칠을 하게 되는 것입니다. 많이 배울수록, 스스로 지켜야 할 선의 수준도 높아지기 마련입니다.


KAIST의 특수성

마지막으로 여러분에게 부탁하고 싶은 점은, 특히 KAIST 학생으로서의 책임감을 가져달라는 점입니다. KAIST는 다른 학교와는 달리 많은 부분을 정부의 지원, 그러니까 국민의 세금에 의존하고 있는 학교입니다. 여러분 한명을 교육시키기 위하여 여러분의 부모님들을 포함한 얼마나 많은 사람들이 일하고 세금을 내는지 생각해 보기 바랍니다. 그렇게 여러분을 믿고 지원해 준 국민들에게 보답하기 위해서라도, 좋은 연구하고 빨리 졸업해서 사회에 보탬이 되는 일을 하는 것이 바람직합니다. 만일 여러분이 하라는 공부는 안 하고 게임하면서 하루하루를 지세운다면, 제가 보기에는 공적자금 빼돌리는 악덕 기업주와 다를 바가 없습니다.  

많은 KAIST 학생들이 자신은 머리가 좋기 때문에, 아니면 여기까지 온 것도 경쟁을 뚫고 들어온 것이기 때문에 이만한 혜택을 받을 자격이 있다고 생각하는 경향이 있습니다. 그러나 사장이 되기까지 힘들었으니 이제 돈을 빼돌려도 된다는 것이 합리화되지 않는 것처럼, 여러분이 KAIST 학생이 되었다는 것이 여러분이 받고 있는 혜택을 당연하게 만드는 것은 아닙니다. 때로 여러분이 지치거나 힘들 때, 얼마나 많은 학생들이 여러분과 함께 KAIST에 들어오고 싶어 했고, 지금도 KAIST에서 공부하기를 꿈꾸면서 얼마나 많은 후배들이 공부하고 있는지 생각해 보기 바랍니다.


이것이 석사논문 주제가 되나요? (version 0.2 추가)

많은 학생들이 찾아와서는 묻습니다. "제게 이러저러한 아이디어가 있는데 이것이 석사논문 주제로 적당할까요?" 라고요. 태어날 때 천한 사람, 귀한 사람이 따로 있는 것이 아니듯이, 저는 처음부터 석사논문으로 적당한 topic이 따로 있는 것은 아니라고 생각합니다. 어떤 topic이 석사논문으로 적당한 지의 여부는 전적으로 그것을 주장하는 여러분에게 달려 있습니다. 즉, 여러분이 그것이 왜 중요하고, 어떤 점이 나아지며, 다른 사람이 한 일과는 어떻게 다른지를 논문 committee에 있는 교수님들이나 다른 사람들에게 효과적으로 설득할 수 있는지의 여부가 더욱 중요하다는 점입니다. 학위논문 심사를 보통 디펜스(defense) 한다고 하는데, 이것은 많은 사람들의 공격으로부터 자신이 한 일이 중요하다는 것을 설득시키고 지켜낼 수 있어야 하기 때문입니다.

자기의 논문을 디펜스하기 위하여 무엇보다도 중요한 것은 앞에서도 언급했듯이 다양하고 많은 사람들과의 discussion 입니다. 혼자서 생각하다보면 한쪽으로만 생각이 흐르는 경향이 있어서 중요한 것을 못보고 지나칠 가능성이 많습니다. 그러나 백그라운드가 다른 여러 사람에게 자기가 한 일을 설명하고 이해시키려고 하다 보면, 그 사람들이 이해하지 못하는 점을 설명해 주는 과정에서 놓치고 있던 것을 발견하게 되고 더 좋은 아이디어가 떠오르게 되기도 합니다. 또, 얘기를 하다 보면, 사람들이 여러가지를 물고 늘어지면서 시비를 걸게 되는데, 이런 점에 대해서 미리 대답을 생각해 보고 하면 실제 논문심사시에도 훨씬 여유가 있게 됩니다. 결국 논문심사를 위해 여러분이 준비해야 할 것은 이런 질문에는 이렇게 대답하고, 저런 질문에는 저렇게 대답하고.. 등을 미리 생각해 놓아야 하는 것인데, 당연히 예상문제를 많이 풀어보고 들어가는 것이 유리합니다. 그러니 다른 사람과의 discussion은 많으면 많을수록 좋습니다.

보통 어떤 논문에 대해서 눈여겨 보는 것은,

1. 어떤 환경 혹은 시나리오를 가정하고 있는가?
2. 가정하고 있는 환경에서 어떤 문제가 있는가?
3. 그 문제가 왜 중요한 문제인가?
4. 문제 해결을 위한 본인의 아이디어는 무엇인가?
5. 같은 문제 해결을 위해 다른 사람들이 기존에 한 일은 무엇인가?
6. 다른 사람들이 한 일과 본인이 한 일이 *객관적*이고 *정량적*으로 잘 비교, 분석되었는가?
7. 혹시 나빠지는 점은 없는가?

등등입니다. 위의 물음에 대해 자신을 가지고 다른 사람을 설득할 수 있으면 됩니다.

제 개인적으로, 석사논문의 수준은 웬만한 conference에 accept될 수 있는 정도면 적당하다고 생각합니다. 이 말은 바꿔말하면, 여러분이 작성하는 석사논문이 웬만한 conference의 심사위원들을 설득할 수 있는 정도의 수준이 되어야 한다는 뜻입니다.


세미나 참석 (version 0.2 추가)

아이디어를 얻기 위해서 또 하나 강조하고 싶은 것은 세미나 참석입니다. 보통 대학원 연구실 배정을 받고 나면 언제부터 본인에게 연구분야가 있었다고 자기 연구분야가 아니면 세미나에 흥미조차 없는 사람들이 많습니다. 그러나, 앞으로 여러분이 어떤 일을 하게 될지 모르고, 그런 기회가 아니라면 다른 분야에서 어떤 일을 하는지 조차 모르게 되니 가급적 학과/학교에서 열리는 세미나에는 시간을 내어 참석하기 바랍니다. 그 시간에 여러분이 논문을 하나 읽는 것보다, 해당 분야에 대해서 잘 정리해서 발표해 주는 세미나를 듣는 것이 훨씬 도움이 됩니다.

그리고 결국 전산학에서 어떤 문제를 풀기 위한 approach는 거의 비슷하기 때문에, 다른 사람들이 어떤 문제를 어떤 식으로 풀어나갔는지를 보는 것이 많은 도움이 됩니다. 그리고 어떤 경우에는 전혀 다른 분야에서 쓰는 방법을 내 분야에 적용시켰을 때 매우 효과적인 경우도 많습니다. 따라서, 아무리 다른 분야의 세미나라 하더라도 세미나를 들으면서 자유롭게 내가 알고 있는 분야에 비슷한 문제는 없는지 등을 생각해 보는 것이 좋습니다. 내용을 모르더라도 최소한 발표는 어떻게 하는 것이 좋겠는지, 혹은 질문에 대해 어떻게 대처해야 하는지 등에 관해서라도 배울 수 있는 이점이 있으니 세미나 참석은 중요합니다. 같은 이유로 대학원 때 수업도 본인의 연구 분야에 관련된 부분만 집중해서 듣지 말고, 다른 분야의 과목들을 듣는 것을 권장합니다.  

흔히, 박사학위의 기본 요건 중의 하나가 T자형 인간이라고 합니다. 그러니까 전산학 전 분야에 대해서 breadth와 자기 분야에서의 depth를 가져야 한다는 것이죠. 보통 자격고사(qualifying exam)를 통해 breadth를 테스트 하고, depth는 박사학위논문심사에서 따지게 됩니다. 우리 학교의 경우 자격고사가 제 역할을 하고 있지 못해서 좀 문제이기는 하지만.. 아뭏든 둘 다 중요하니 자기 분야의 depth만 고집할 게 아니라, 다른 분야에서 어떤 일들이 일어나고 있는지도 관심을 가지고 살펴보기 바랍니다. 그게 다 피가 되고, 살이 됩니다.



----

쓰다 보니 조금 훈계조로 흐른 부분도 없지 않고, 일부는 몇몇 사람에게 얘기한 적도 있는데.... 정리하는 차원에서 쓴 것이니 참고하기 바랍니다. 또 다른 생각이 나면 지속적으로 업데이트 하도록 하겠습니다.


아래는 참고할 만한 링크입니다.


Useful Links on Graduate Studies, Research, and Technical Communication

Response : ,

AI 과제 - 8Puzzle 구현하기

Posted 2007. 10. 2. 21:02, Filed under: Study/Computer Science
이번 학기 첫번째 프로그래밍 과제- Search Tree를 탐색하는 방식으로 8-Puzzle을 푸는 것

8-puzzle 은 어릴 때 누구나 한번쯤 해보았을 8 개의 타일로 구성된 9칸짜리 판 위에 있는 1-8까지의 숫자를 순서대로 맞추는 퍼즐.

| 1 | 2 |   |                | 1 | 2 | 3 |   
| 3 | 4 | 5 |     →        | 4 | 5 | 6 |
| 6 | 7 | 8 |                | 7 | 8 |   |
 
시작 상태를 Root로 해서 변경 가능한 모든 상태를 탐색하면서 목표로하는 상태가 나올 때까지 트리를 탐색하는
것이 컴퓨터가 문제를 해결하는 과정인데, 이 과정에서 탐색 횟수를 줄이고 최소의 타일 이동으로 해답을 구할 수 있는 답안을 찾아야한다.

이를 위해 사용된 알고리즘은

1) BFS
2) IDS
3) A* Search

=====================

논리적으로 문제를 어떻게 해결해야하는지 알고 있는 경우에도 실제 구현에는 상당한 시간이 걸린다.
예상보다 훨씬 더..-_-

문서화도 만만치 않다.. 방학 때 과학기술 문서 작성 들으면서 뼈져리게 느꼈던건데..;;
그새 잊었나 ㅋ

이틀 반나절을 꼬박 코딩, 반나절 테스트, 반나절 문서화..
결국 제출기한을 한참 넘겨 오늘 오후에나 겨우 냈다.

다음부터는 좀 더 일찍 시작하고 여유있게, 침착하게 코딩하자.

프로그램을 짤 때 생산성을 높이는 방법은 단순한 것 같다.
설계니 개발방법론이니 알고리즘이니 하는건 코딩 이전의 문제.

코딩은 이미 있는 해결책을 프로그래밍 언어로 구현하는 것이니까
최대한 실수하지 않는 것이 빨리 프로그래밍하는 최고의 길인 것 같다.



Response : ,

파이프( | )와 변수 처리

Posted 2007. 9. 27. 20:35, Filed under: Study/Computer Science
  1 #!/bin/sh
  2 if [ $# -eq 0 ]
  3 then
  4     echo "USAGE: ./newls.sh [path]"
  5     exit
  6 fi
  7
  8
  9 dcnt=0
 10 fcnt=0
 11
 12 ls $1
 13
 14 ls $1| while [ "$dcnt" -le 10 ]
 15
 16 do
 17     dcnt=`expr $dcnt + 1`
 18     fcnt=`expr $fcnt + 1`
 19
 20 done
 21
 22 echo "$dcnt diretories, $fcnt files"

유닉스 프로그래밍 과제

ls 와 같은 기능을 하면서 디렉토리와 파일의 수를 출력해주는 newls를 쉘 프로그램으로 작성하는 것

요놈 때문에 오늘 하루종일 삽질 삽질

ls $1 | while read file
do
 if [ file이 디렉토리이면]
     dcnt = `expr $dcnt + 1`
 else
     fcnt = `expr $fcnt + 1`
 fi
done

이렇게 ls랑 똑같이 하면서 디렉토리인지 아닌지만 판단해서 카운트를 해줄려고 했는데
이 간단한거 하면서 어찌나 삽질은 했는지~
게다가 어디서 삽질하는지도 모르고 있어서 오늘 하루가 다 갔다..-_-;;

먼저  test  대신에 []를 쓰려면 [ ] 앞뒤로 공백을 둬야한다는걸 몰라서 한참 에러..

dcnt = `expr $dcnt + 1` 에서 변수 1씩 증가 안되서 $((expression)) 이랑 이것저것 해봐도 안됐는데
요거 원인 찾는거도 진짜 힘들었다.

결국 알아낸 건 | (pipe) 다음에 while을 쓰니까 변수가 증가가 안된다는거.
그냥 0이 출력된다. 값을 증가시키기 위해서는 pipe 다음에 변수를 선언해야하는 것 같은데
어떻게 해야하는지 잘 모르겠다..;;

Response : ,

tar와 gzip

Posted 2007. 9. 26. 12:56, Filed under: Study/Computer Science

[tar 사용하기]
tar는 파일을 묶는 기능을 가진 아카이브 프로그램이다.


파일 묶고 푸는 방법

tar (function)(option) (묶을 대상)

묶은 파일명은 (파일명).tar 이다.

function의 종류

c : 새로운 아카이브의 생성
x : 아카이브로부터 파일 추출
t : 아카이브에 담긴 내용을 나열
r : 아카이브의 마지막 부분에 파일 추가
u : 아카이브에 있는 기존 파일보다 새로운 파일로 업데이트
d : 아카이브에 있는 파일과 비교

option의 종류

v : 파일을 묶거나 풀 때 다양한 정보 출력
k : 기존의 파일을 보존한다. 즉 tar 파일에 담긴 파일이 이미 존재하는 상태이면 덮어쓰지 않는다.
f (파일명) : 읽거나 기록할 tar 파일을 정의
z : 자료를 쓸때 gzip으로 압축하도록 지시 또는 tar 파일 안의 자료가 gzip으로 압축되어 있다는 사실을 알린다.
v : 묶거나 풀고 있는 파일을 보여준다. 어떤 일이 벌어지고 있는지 확인하려면 사용하는 것이 좋다.

여러 개의 옵션을 쓸 때 f 옵션을 제일 마지막에 쓴다.

[gzip과 bzip2 사용하기]

gzip과 bzip2는 압축프로그램이며 여기서의 내용은 gzip과 bzip2 는 같은 명령어를 사용하며 gzip을 bzip2로 바꾸면 된다.



압축하는 방법

gzip (파일명).(확장자)
압축후에 원본 파일은 지워지며 압축후의 파일 이름은 (파일명).(확장자).gz이다.

압축된 파일의 정보 보는 방법
gzip -l (파일명).(확장자).gz

압축푸는 방법
gunzip (파일명).(확장자).gz
압축을 푼 후에 압축되었던 파일은 지워지며 압축푼후의 파일 이름은 원본파일의 이름 그대로 이다.


압축을 풀지 않고 파일 내용보는 방법
gzip -c (파일명).(확장자).gz



압축속도와 압축효율 설정 방법
gzip -(숫자) (파일명).(확장자)
zip -1 : 압축속도↑, 압축효율↓
    -2
    ...   (-6이 기본값이다.)
    -8
    -9 : 압축속도↓, 압축효율↑

[gzip과 함께 tar 사용하기]

|(파이프)를 이용하여 gzip과 함께 tar 사용할 수 있다.

묶고 압축하는 방법
tar cvf -(묶을 대상) | gzip -9 > (파일명).tar.gz


묶고 압축한 파일을 원래 상태로 축출하는 방법
gunzip -9c (파일명).tar.gz | tar xvf -

간단한 묶고 압축하는 방법
tar cvzf (파일명).tar.gz

간단한 압축풀기
tar xvzf (파일명).tar.gz

여기서 bzip2와 함께 tar를 사용한다면
tar xvfj (파일명).tar.bz2


tar 트릭
from-stuff와 to-stuff라는 하위디렉토리를 가진 디렉토리가 있을 때 from-stuff 디렉토리 구조를 to-stuff 라는 디렉토리로 미러링하는 방법(미러링 : 파일, 심볼릭 링크, 소유권 허가권 등을 전부)

  cd from-stuff

  tar cf - . | (cd ../to-stuff; tar xvf -)

Response : ,

« Previous : 1 : 2 : 3 : 4 : ··· : 12 : Next »

Recent Posts

Recent Comments

Recent Trackbacks

Total hit (Today , Yesterday )

Admin Write Post