Jeongseok's Notes

혁신은 제약이 있는 환경에서 나온다 - Unix의 사례

Jeongseok Son — Tue, 27 Oct 2020 05:30:00 GMT

탁월한 인재들이 모여서 마음껏 자원을 쓸 수 있고 다른 일에는 신경 쓰지 않고 문제 풀이에만 집중할 수 있는 환경. 혁신적인 결과들은 당연히 이런 환경에서 가장 잘 나오지 않을까? 하지만 역사를 들여다보면 온갖 제약이 걸려있는 상황에서 세상을 바꾼 결과가 나오기도 하고, 모든 것을 갖춘 최고의 환경이 그 어떤 중요한 결과도 만들어내지 못하는 사례를 쉽게 찾을 수 있다.

컴퓨팅의 역사에서 세상을 가장 크게 바꾼 소프트웨어 단 하나를 골라야 한다면 많은 사람이 Unix를 선택할 것이다. 물론 자유 소프트웨어 운동을 완성하고 현재 가장 많이 쓰이는 운영체제인 Linux를 꼽는 경우도 있을 것이다. 하지만 BSD (Berkeley Software Distribution)를 비롯해서 수 많은 대안들이 있었던 Unix-like 운영체제 보다는 핵심 디자인과 철학을 처음 정립한 Unix가 더 중요한 발명이었다는 것에 대부분 동의할 것이다¹.

얼마 전에 Unix를 만든 Ken Thompson의 인터뷰 영상을 보게 됐다. UC Berkeley 졸업 후 벨 연구소에서 일하게 된 이야기와 Multics 운영체제 프로젝트 참여로부터 시작된 Unix의 탄생 비화, Uinx Pipe 아이디어를 얻은 과정과 Grep 도구 개발 등을 회상하는데 재밌는 구전 동화를 듣는 것 같아서 1시간이 금방 지나갔다. 그런데 인터뷰를 보고 나니 Unix가 바로 제약 있는 환경 속에서의 만들어진 혁신적인 결과물의 재밌는 예시라는 생각이 들었다.

Multics의 실패

(영상의 17분 36초) Thompson이 Multics에 대해 다음과 같이 평가한다.

Multics는 너무도 복잡하게 설계된 (over-engineered) 거대한 프로젝트였습니다. 전형적인 속편의 문제 (second-system syndrome)였죠. MIT는 정말 잘 만든 시분할 (time-sharing) 시스템을 갖고 있었는데 후속 시스템을 더 잘 만들기로 했지요. 그런건 실패할 수밖에 없어요. MIT, 벨 연구소, 제너럴 일렉트릭 (GE) 세 조직의 협력 프로젝트였는데 ...

이 부분을 보고 오래전에 재밌게 읽었던 The Art of Unix Programming (TAOUP) 의 관련된 챕터를 다시 찾아봤다. Multics의 전신은 CTSS 운영체제였고 CTSS와 Multics 모두 미국 국방성 DARPA에서 Project MAC (Mathematics and Computation)을 통해 펀딩을 받았다. 초기 지원 금액만 1960년대에 2백만 달러에 달하는 큰 규모의 프로젝트였다.

Multics는 당시에도 최고의 대학원이었던 MIT에서 이미 성공적으로 운영 체제를 만든 팀이 DARPA와 벨 연구소, GE로부터 지원을 받아 만들어졌다. 그러나 일부 시스템에서 쓰이다가 1988년에 개발이 중단되고 지금은 Unix의 역사 속에서나 언급된다. Multics의 실패에는 여러 가지 이유가 있겠지만 공통적으로 너무 잘 만들려고 필요 이상으로 복잡해져 현실에서의 사용성이 떨어진 것을 지적한다. Multics는 많은 자원이 오히려 최적의 시스템을 만드는 데 좋지 않은 영향을 미친 경우이다.

Unix를 외면한 벨 연구소

벨 연구소는 그 당시 통신과 컴퓨터 관련 최고의 연구소였으니 그 곳에서 세상을 바꾼 Unix라는 결과물이 나온 게 당연해보인다. 하지만 Multics와 달리 Unix는 개발 과정에서 제대로 된 지원을 받지 못했다.

(영상의 19분 17초) Thompson은 초기 개발 과정을 다음과 같이 회상한다.

벨 연구소가 (Multics 개발에서) 빠지면서 좋지 않은 인상을 받았죠. 그래서 연구소에서 운영체제 개발을 다시는 하지 않기로 했어요. 하지만 저는 운영체제를 개발하고 싶었고 ...

(24분 57초)

벨 연구소는 여전히 운영체제 개발을 허락하지 않았어요. (PDP-7에서 개발한) Unix를 PDP-10으로 이식하는 제안서를 냈는데 우리 네 명이 요청할 수 있는 예산 총액으로 충분하고도 남았는데도 곧바로 거절당했어요. ... 그래서 Joe Ossanna가 특허를 작성하고 수정하는 애플리케이션을 만들겠다는 속임수를 고안해냈어야 했어요.

Thompson의 회상대로 Unix는 벨 연구소의 프로젝트가 아니라 그의 개인 프로젝트였다. Space Travel 게임을 개발하려고 PDP-7 컴퓨터에서 작동하는 운영체제를 만든 게 시작이었고 연구소에서 운영체제 개발을 지원하지 않아 다른 부서의 잘 쓰이지 않는 PDP-7 컴퓨터를 찾아서 써야 했다고 한다. 새로운 컴퓨터를 사기 위해서 프로젝트를 위장했어야 했다는 기억은 "웃프다"는 표현이 어울린다.

그러나 역설적이게도 벨 연구소에서 제대로 지원을 받지 못했기에 Unix가 성공했다고도 볼 수 있다. "간단하고 바보같이" 만든다는 KISS (Keep It Simple and Stupid)는 Unix를 성공하게 만든 철학들을 요약하는 가장 중요한 원칙이다. 만약 Unix가 벨 연구소 차원의 프로젝트로 전폭적인 지원을 받았다면 Multics가 그랬듯이 더 잘 만들어야 하고 복잡해져야 한다는 압력을 받아 같은 전철을 밟지 않았을까? TAOUP에서도 Multics와 Unix를 비교하며 같은 점을 환기해준다.

Multics는 수천 장의 기술 명세를 하드웨어가 도착하기도 전에 작성했던 거대한 프로젝트인 반면에 처음 동작했던 Unix는 세 명이 브레인스토밍하고 Ken Thompson이 구식 컴퓨터에서 이틀 만에 작성했다.

Ken Thompson의 개인적인 상황

연구소에서 운영체제 개발을 지원해주지 않는 문제도 있었지만, Unix를 개발할 당시의 Thompson은 개인적으로도 일에만 온전히 몰두할 수 있는 상황은 아니었던 것 같다.

(22분 42초)

(디스크 스케쥴링 프로그램을 작성하다가) 그 순간이 오기 전까지는 몰랐는데 운영체제를 완성하기까지 3주의 시간이면 될 거라는 걸 깨달았어요. ... 다행히도 그때 제 아내가 3주의 휴가를 가기로 했고 (청중 웃음) - 돌을 맞은 아이와 캘리포니아에 있는 처가에 가려고 말이죠 - 떠나고 혼자 남은 덕에 3주 만에 Unix를 완성할 수 있었죠.

Thompson은 Unix를 개발할 때 갓난아이를 키우고 있었다. 아이와 함께 아내가 떠난 3주의 기간이 주어져 다행이었다고 하는 걸 보니 육아 때문에 많은 개인 시간을 Unix 개발에 투자하기는 어려웠을 것이라 쉽게 추측할 수 있다. 이 시기와 Unix 개발이 겹치는 건 그저 우연일까? 프로그래밍 언어를 연구하시는 이광근 교수님이 번역한 Donald Knuth의 글을 읽고는 아닐 수도 있다는 생각이 들었다.

"내 인생에서 제일 창의적이었던 일들을 꼽으려고 회고해 보면, 그것들이 모두 어느 한 시절, 가장 많은 제약조건과 잡무로 치이고 있었던 시기에 일어났었다는 것을 알게된다. ... 쓰고있던 책(The Art of Computer Programming)이 곧 출판을 준비하고 있었고, 태어난 애기 둘을 아내와 함께 돌봐야 했고, 잠깐 입원까지 하기도 했었고, ... "

지금까지의 내 인생에서도 가장 생산적이었던 시절은 3년 동안 산업기능요원으로 병역 의무를 수행하던 때였다. 회사에서 일을 해야 하니 개인적으로 배우고 하고 싶었던 일을 할 시간이 학생 때와 비교도 안 되게 부족했다. 하지만 이 시기에 출퇴근 시간을 포함한 남는 시간을 최대한 활용해서 그 전에 학교에서 보낸 3년보다 더 많은 책을 읽고 더 많은 것들을 해내며 발전할 수 있었다.

어쩌면 우리는 시간이 제한되면 꼭 해야 하는 중요한 일에 더 잘 집중할 수 있는 게 아닐까? Stephen Covey를 통해서 유명해진 아이젠하워 시간 관리법에서는 일을 중요도와 긴급성에 따라 네 가지로 분류한다. 여기서 시간 관리의 핵심은 "중요하지만 급하지 않은 일" (책읽기, 가족과 시간 보내기 등)의 우선순위를 높여서 처리하는 것이다. 시간이 많을 때는 급하지 않다고 생각했던 일들이 시간에 제약이 생기면 상대적으로 급해 보이게 된다. 거기에 시간이 제한되었다는 생각에 집중력이 향상되는 효과까지 더해졌던 게 내 경우에는 좋게 작용했다. Thompson과 Knuth의 경우처럼 해결하고자 하는 중요한 일을 알고 있다면, 시간의 제약조차도 성취를 하는데 도움이 될 수 있다고 생각하게 된다.

마치며

앞에서 인용했던 이광근 교수님의 웹 페이지에서 혁신적인 성취가 제약된 환경에서 이루어졌다는 여러 위인의 회고를 볼 수 있다. 이후 Unix의 역사에서도 비슷한 다른 사례들을 더 자세히 들여다보아도 재밌을 것이다. 가장 성공하기 좋아 보였던 환경에서 만들어진 UC Berkeley의 BSD가 아니라 핀란드의 대학원생이 만든 Linux가 성공한 사례, 그리고 벨 연구소 차원에서 제대로 만들어보려 했던 Unix의 후속 Plan 9의 사례 등에서 비슷한 패턴을 찾을 수 있을 것 같다.

이런 역사를 배우는 게 흥미로울 뿐만 아니라 내 삶의 태도를 더 낫게 만든다고 느낀다. 누구나 온갖 제약 조건에 시달리지만 그것들을 기회로 바라볼 수 있는 관점은 모두가 갖고 살아가지는 않을 것이다. 더 나은 환경에서 일하기 위한 노력을 계속하면서도 어쩔 수 없는 제약들은 긍정적으로 받아들인다면 어느 곳에 있어도 혁신적인 일을 해낼 수 있다는 것, 내가 Unix로부터 배운 또 하나의 교훈이다.

그럼에도 Linux라는 이름 때문에 거의 모든 일반 대중들과 심지어 많은 수의 프로그래머들조차 Linus Torvalds는 알아도 Ken Thompson은 모르는 게 현실이다. 유명해지고 싶다면 작성한 소프트웨어 이름은 당신의 이름과 어떻게든 연관되게 지으라는 교훈을 준다(?). ↩

Reviewing my time at graduate school

Jeongseok Son — Mon, 05 Oct 2020 02:45:00 GMT

Intro: I was a graduate student pursuing a Ph.D. in Computer Science at UC Berkeley. I recently graduated with an M.S. and am joining Google shortly. This memo is mainly for me to reflect on time at graduate school. I decided to share my decision process here in case someone finds it helpful somehow or just becomes interested in reading about it.

Why I decided to do a Computer Science Ph.D.

I started learning computer programming when I was in elementary school. My mother opened the door to the world of the computer when I turned 10¹. I grew up in an island in South Korea, the farthest away from the most advanced city of the nation. My mother suggested me taking a class at the only programming cram school in my hometown. Learning how to program, I saw the potential of computer software to dominate the future. It was just a gut feeling of a 10-year-old without a great rationale behind it. Since then, I have never stopped learning about computers. Before I went to college, I was almost always the only student who can actually program in my class.

I have just loved studying Computer Science itself. It was not just a means of implementing software or getting a lucrative job for me ². I felt understanding how computers work and acquiring knowledge in this field is something that actually defines me and differentiates me from other peers simultaneously. Moreover, its practicality has always fascinated me. Even a theoretical class like Computer Algorithms taught me how to solve real-world problems fast using a computer. Just taking Computer Science classes and graduating with a Bachelor’s didn’t look fulfilling enough for me.

Thus, I decided to try research. I asked a professor to do research in operating systems with the application of cloud computing because the field looked most practical to me. It was challenging to participate in research as an undergrad, but the outcome of our project was quite fruitful. Our team published a paper successfully and it has been cited more than 100 times so far. I also did networked and distributed systems research. One of the projects turned out well and I first-authored another paper published at a prestigious venue. Overall, I had a strong conviction that I enjoy doing research and I painted a rosy picture of my graduate study.

Expectation and reality of being a Ph.D. student

I was extremely lucky to join the RISELab at UC Berkeley. RISELab was formerly an AMPLab, where impactful research projects such as Apache Spark and Apache Mesos were started. I was amazed by the chance to work with and learn from the smartest and passionate people from all over the world. Indeed, the expectation was met much more than I imagined. Not to mention the faculty, the group of the best of the best scholars, all my peers were a set of the brightest people I have ever met. Interacting with these folks has always been inspiring, and I will certainly miss all of them.

The other thing was obviously about the research I would conduct. I was eager to do important and publishable research and become a prolific graduate student. I didn’t doubt much about achieving this goal by doing enjoyable research at the lab that has had a great impact on the real world. However, it didn’t take too much time to realize I didn’t raise more important questions in the first place.

Advisors and peer students are all crucial factors for a successful Ph.D. study. However, what matters most is the candidate herself. What kind of research I truly enjoy? What are the problems that “I” think indeed important? I paid too much attention to peripheral issues such as the prospect of sub-fields, interests of my advisors, and publishability of projects. I started computer security research beginning my graduate study. I soon realized that I am not even sure if I like this field and have a good aptitude for doing relevant research. I struggled a lot to find a good project that I can fully devote my time and energy to, even though the lab has a wide variety of projects and members to collaborate with. Without answering the important questions to myself early on, all my efforts were like shooting with no definite targets.

I finally settled down to a project and made slow progress thanks to my supportive advisors. However, those important questions I raised later on evolved to more fundamental ones about myself: Do I really enjoy doing research? Will I be able to solve problems “I” think important as a researcher ultimately? These are the ones I didn’t doubt before I started my Ph.D. study, overshadowed by the small success I accomplished in college. Two years of endeavor was long enough to draw a conclusion that my answer to these questions is no. When I was an undergrad, the projects I did were already well-defined by my supervisors. Also, research was an optional quest that did not have a big downside. Even if I had failed to publish papers, no one would have blamed me including myself. Doing research as a Ph.D. student was vastly different in contrast. As a Ph.D. student, I had to (or quickly learned to) find and scope a problem to solve. It has to be at the intersection of what I think important and academics agree so. I found an almost irreconcilable mismatch between me and academia here.

Deciding to leave grad school

I love problems in which I can see the tangible near-term impact of solving it. As a graduate student, however, finding this type of problem felt difficult if not often undesirable in academia. Students usually learn about problems in their fields from their advisor and senior students or by reading published literature themselves, and so did I. However, I was not able to convince myself of the importance of these problems. Are these real problems for people outside of academia to care about? I realized that the answer to this question is often hard to find and actually does not matter much. The problems solved in academia has to be novel. However, they should not necessarily be the ones already prevalent in the real world. In fact, this kind of problem is often avoided because of the existing academic solutions occupying the publishable territory. The remaining problems are considered a matter of engineering. This makes sense taking the purpose of research into account: broadening the horizon of human understanding and knowledge on a certain subject. Research thus tends to precede the development in the real world. Even though only a tiny fraction of them becomes relevant in the future, the farseeing nature distinguishes research from industry works. Academic and real-world problems are not mutually exclusive at all, but I concluded that the chance of me spotting the overlap is slim.

Every Ph.D. student feels lost and unhappy several times throughout her journey to the dissertation. To successfully get through these hurdles, I think a candidate should have either deep affection toward doing research or a strong conviction that she is doing important research. I admitted that I had neither in the first place after a couple of years of graduate study. I initially blamed other minor factors such as changing my research field from systems to security. If I truly love doing research, however, I had ample opportunities to resolve small issues like that. My affection for research was just too shallow to endure the difficulties of doing a Ph.D.. I didn’t have the same degree of conviction I had when I was 10 towards research.

Once I concluded that I won’t be in academia, the value of the Ph.D. degree diminished drastically. Neither did I appreciate the research topic enough to become an expert in the relevant industry. Still, I forced myself to complete a project I led. After getting it into a publishable shape, which took longer than I thought, I told the final conclusion to my advisor. Before I made the decision, I had discussed my concerns with my advisor already. Here, I cannot appreciate her enough. She not only understood my trouble but also sincerely encouraged me to take a decision whatever makes me the happiest. She let me focus on my job search during the Summer and even helped it by connecting me with people in the industry. I am tremendously indebted to her for all the support I’ve got.

Job search

When I was about to start a job search for a software engineer position, the COVID-19 pandemic hit the world. Lots of companies implemented hiring freezes. I became so anxious about my job search. However, there’s one important thing I did right: (human) networking. RISELab is one of the most renowned research groups in the industry. Our lab is distinguished for its wide and close connections with companies that sponsor the lab. RISELab holds biannual retreats, weekly seminars, and annual tutorials where hundreds of researchers and engineers from industry join. Every time I attended these events, I had many 1-on-1 chats with seminar speakers and participants if s/he is in the fields of my interest. It was mainly a way to get a sneak peek of interesting problems in the industry. Little did I anticipate that these connections I made would open a lot of job opportunities. Even though I didn’t do any internship, people I spoke to remembered me and kindly provided valuable referrals.

Algorithmic problem solving is a major form of interviews for software engineers in the tech industry. I had competed in the national competitive programming contest before I entered a college, but haven’t done it for many years. I was able to spend the Summer sharpening the interview programming skills.

The unexpected flexibility of Google

When I started my job search, Google was not on the top of my list. Google is still regarded as a symbol of Silicon Valley and I once dreamed of working there when I was younger. However, I wanted to join a company that has a bigger upside-potential in terms of my personal growth and equity. I learned there are numerous other exciting and promising companies that are up and running in the Bay Area. In contrast, Google became a giant from a nimble and fast-growing startup long ago. Moreover, I heard from several Googlers that Google is quite conservative in the level of the offer. Since many candidates still accept an offer from Google even if the level of the position is lower than the others, Google enjoys this advantage in the recruitment. I assumed that even if I get an offer from Google, the level would be lower than the other offers.

Fortunately³, I got a handful of great offers from multiple thrilling companies. One of them was the one I wanted to join most when I started my job search. It’s a famous pre-IPO company with excellent potential and reputation. I finished the interviews of both Google and this company around the same time and I felt I did very well in these interviews. Before I got an offer from the other company, the Hiring Committee of Google reviewed my interview performance and then offered a chance to raise the level of the offer by taking an additional interview for senior candidates.

In fact, the hiring process of Google was much more flexible and fair than I expected. None of the other companies I got interviewed gave me a chance to level up the offer based on the result of the coding interview. If you pass the bar, you normally get an offer of a level that an employer decided based on your years of experience. If you don’t, you just lose the offer in general. I felt Google is most confident about their interview questions and interviewers. Google cared about the interview performance more than any other company in making the final offer. I felt this is more reasonable than taking mostly the years of experience of a candidate into account for the decision. The interview experience with Google changed my impression of the company a lot.

I passed the additional system design interview as well and finally decided to join Google. I was mainly deciding between Google and the other company that I wanted to join most. The other company’s offer had a better upside potential clearly and the work encompasses hotter technologies than the ones I will use at Google. However, I focused on myself more this time to make the decision.

At Google, I will work at the Systems Infrastructure (SyInfra) group. The group manages the issues arising out of the massive scale of the computer clusters where services like search, YouTube, and Maps are running on. As more and more services from other enterprises using Google Cloud also rely on the compute infrastructure, I guess the group has become even more crucial inside Google. I was excited about joining a group that I can easily appreciate its significance intuitively. Moreover, I was confident that I will enjoy the work at Google more than at any other company. I already had several years of positive experience in operating systems, computer networks, and distributed systems before I started my graduate study. These are the key foundation stones of any large scale compute clusters in data centers. I wanted to return to the systems territory that I am both familiar with and fond of. Obviously, Google has maintained the largest scale of clusters in the world and led the advancement of this field. I wasn’t able to find a stronger force to join in the battlefield. My decision may not be the right choice when I look back in the future. However, I believe I raised the right questions this time at least.

Looking ahead

Almost 5 years ago, I wrote a post (in Korean) which ended with a resolution:

Am I working on what I think important? I will constantly ask this question to myself. When I can’t confidently answer yes, I will stop it and search for another important work

The question led me to a grad school and then made me leave it. Now the answer convinced me to go to industry and work as a Software Engineer. My answer will not stay the same as it didn’t already. I may decide to come back to academia after several years. Who knows? However, asking this question has not just guided me to the right path but also given me courage. I will keep using my answer to it as an indicator. I hope my tenure at Google will be lengthy so that I can accomplish too many great things until I leave!

She emphasized the importance of learning two important skills as a millennial: one was computer, the other was English. She often described them as the wings that will empower me to comfortably explore any new realm of human knowledge, and realize my own goals in the future. In retrospect, she had better insight than any other teachers I’ve ever learned from in my life. ↩
Software engineer was not a popular job in my country even when I was in college. The CS major took off around the year of 2014 and now it became the most popular major nationwide. ↩
I am not saying this word for humble-bragging. I learned that luck plays a significant role in the interviews since one bad (or mismatched) interviewer is enough to fail you. It is thus important to apply to plenty of companies to make luck be on your side. ↩

내가 중요하다고 생각하는 일을 하는 것

Jeongseok Son — Tue, 16 Feb 2016 11:28:00 GMT

“제 나이쯤 되면요 삶의 낙이 많이 없어요. 꽃보다 할배에 나오는 그리스 산토리니 근처에서 학회를 해도 그냥 귀찮다고 학회 끝나면 바로 비행기 타고 한국 와버려요. 여러분은 상상이 안 되죠?
그래도 일을 계속하게 만드는 가장 큰 원동력은 내가 중요하다고 생각하는 일을 하고 있다는 믿음이에요. 돈, 물론 나도 돈 많이 벌어보지는 못했지만 돈을 많이 버는 것보다 이게 훨씬 중요한 것 같아요.”

교양 수업 중에 교수님이 스쳐 지나가듯이 한 얘기지만 내 머릿속에는 꽤 오랫동안 저 말이 맴돌았다. 얼마 전에 우연히 다시 읽었던 리차드 해밍(Richard Hamming)의 당신과 당신의 연구(You and Your Research) 발표의 스크립트에 적혀있던 해밍의 일화가 떠올랐기 때문이다.

(벨 연구소의) 식당 반대편에는 화학자들이 앉는 식탁이 있었습니다. … 그들과 함께 밥을 먹다가 물어보기 시작했지요.

“당신의 연구 분야에서 중요한 문제들은 무엇인가요?”

그리고 한 주 정도 지나서 또 물어봤지요.

“당신은 어떤 중요한 문제들을 풀기 위해 노력하고 있나요?”

그리고 조금 더 시간이 지난 어느 날 이렇게 물었습니다.

“중요한 일을 하고 있지도 않고 당신이 하는 일이 뭔가 중요한 것으로 이어지지도 않는다면 왜 벨 연구소에서 그걸 하는데 시간을 쏟고 있죠?”

저는 그 후로 환영받지 못했고 같이 밥을 먹을 다른 사람을 찾아야 했지요. … 그 후 학계에서 그 테이블에 있었던 그 누구의 이름도 언급되는 걸 들어보지 못했습니다. 그들은 자신에게 질문하지 못했던 거에요. “내 분야에서 중요한 문제들은 무엇일까?”

위대한 과학자가 되기 위해서는 중요한 문제를 푸는데 시간을 써야 하고 그렇게 하기 위한 용기가 필요하다는 것이 발표의 주된 내용이다. 읽을 때는 연구를 하면서 항상 생각해야 하는 좋은 질문이라 생각했는데 이제 생각해보니 인생에서 던져야 할 가장 중요한 질문이라는 생각이 든다.

컴퓨터 과학을 공부하고 프로그래밍을 하게 된 이유도 어렸을 때 이 분야가 다른 어떤 분야보다 중요한 분야라는 조금은 근거 없는 확신을 했기 때문이다. 공부하면서 잘 될 때도 있었고 좌절할 때도 있었고 프로그래밍이 재밌기도 하다가 지겨워지는 순간도 많았지만 처음 시작할 때부터 이 분야가 중요하다는 생각은 변한 적이 없었다.

본인이 즐길 수 있는 일을 하라고들 하지만 사실 흥미와 재미는 살다 보면 쉽게 변한다. 처음에는 그토록 재밌던 취미 생활도 한 달도 안 돼서 싫증이 나곤 한다. 하지만 “내”가 중요하다고 생각하는 것의 기준이 되는 가치관(Values)은 쉽게 변하지 않는다. 그렇기에 취미 생활을 넘어서 위대한 일을 이뤄내는 자아실현의 단계까지 가기 위해서는 “내가 이 일을 하면서 재미있는가?” 보다 “나는 내가 생각하기에 중요한 일을 하면서 살고 있는가?” 라고 묻는 편이 더 도움이 될 것이다.

나는 중요한 일을 하고 있는가? 끊임없이 나 스스로 묻고 확실히 답할 수 없을 때는 하던 일을 그만두고 다른 중요한 일을 찾을 것이다.

Having the ownership of my research

Jeongseok Son — Tue, 26 Jan 2016 13:26:00 GMT

Having spent 4 years outside of my home university, I finally came back to KAIST. I couldn't appreciate more that I have one last year I can spend here the day I return to the campus.

Whom should I work with?

To add a nice capstone to my undergraduate study, I decided to do an individual study. KAIST School of Computing and School of Electrical Engineering have world-class faculty working on exciting projects. I had meetings with two professors individually to work on research with one of them. Then I began to vacillate between two options.

One professor I met had numerous research problems to solve. The professor told me he needs a student to work on one of the projects and planned to submit several papers to top-tier conferences in his field of research. The project looked promising to me.

The meeting with the other professor was totally different from the one above. The professor first showed interest on the work I had done in UIUC before talking about a project to work on. The professor suggested me to do a seminar on what I did last year. However, I wasn't sure what I'll do with the professor since I don't have a specific problem to solve yet.

It seemed that there's definitely more chance to publish a paper if I work with the first professor. Since I plan to apply for a PhD program in the US, publishing a paper in a top conference would make my application much more stronger.

At the same time, however, I was attracted by the second option as well after the meeting. I imagined I'm presenting the works I had done last year in front of the professor and other PhD students. It somehow made my heart beat faster.

My resolution: Find my own problem

Meanwhile, I stumbled upon one of the article regarding the advice for graduate students which my advisor in UIUC sent to me. The title is Some Modest Advice for Graduate Students written by Stephen C. Stearns, a Professor of Ecology and Evolutionary Biology at Yale. Reading the following paragraph, I was finally able to decide who should I work with.

... if someone hands you a problem, you won’t feel that it is yours, you won’t have that possessiveness that makes you want to work on it, defend it, fight for it, and make it come out beautifully ...

Though I've done some research so far, the problems to solve were already decided by my advisors as they already have problems they want to solve and I thought that I would learn enough from just solving specific sub-problems to achieve the overarching goal of the projects. Indeed I've gained a lot of valuable knowledge and skills for doing research but haven't thought the projects are really my own work.

Today, in the beginning month of 2016, I come to my resolution. I'll find a problem in my field that I think is truly important, working with the great advisor and graduate students. Even if I don't publish a paper this year, if I find a problem and I can explain why it is important in confidence, that'll do.

How I created my blog

Jeongseok Son — Sun, 03 Jan 2016 04:56:00 GMT

Why I chose Ghost

It had been around 2 years since I found Ghost, a blogging platform that meets my expectation for a blogging tool. Here are some of the reasons I decided to use it:

1. Simple and elegant themes

Compared with Wordpress, which is more like a general content management system to make a general website, Ghost is developed solely for blogging. As you can see, it looks simple so that visitors can focus on the contents of the posts.

Without losing its simplicity, it comes with a default theme which looks elegant enough to distinguish itself from other static site generators like Jekyll and Octopress. Various free or paid themes are available in addition.

2. Self-hosting

There are other simple and beautiful blogging platforms, which I think are more dominant than Ghost like Tumblr, Medium and Svbtle. These services are the best options for most of the general users who want to write and publish posts on the web. However, I'd like to tweak my blog without restriction to do some personal experiments with it. Ghost is an open source project and you can freely install it on your own server or local machine.

3. Markdown

Using a cluttered WYSIWYG editor is always painful. Writing a post directly in HTML is tedious. Ghost not only supports Markdown, but also provides a built-in live editor for it. Static site generators like Jekyll also supports Markdown with more various features, but the Markdown and the editor of Ghost are simple, powerful enough and so convenient.

Static site generator for Ghost

Even though Ghost has its own advantages, it's not easy to host Ghost from scratch if you don't have your own server. I actually have a virtual private server on DigitalOcean but was a bit concerned about its performance and reliability. Therefore I tried to find a way to publish the blog to static web pages.

I found a work already done. Buster created by Akshit Khurana was exactly what I was looking for and it almost worked as I expected. However, I found some errors and inconsistencies between the original Ghost blog and the published static Ghost. As the project has not been maintained since Oct 2014, I forked the project and fixed some issues in my repo:

RSS feeds which appears when you click the subscribe button in the menu now looks normal
Remove unnecessary "index.html" appended to the path of the links
Correctly replace localhost URL in the static files with public domain name you specified as a CLI arugment

You can find my updated repo here.

Host a Ghost blog on GitHub Pages

I hosted my static Ghost blog on GitHub Project Pages. You can follow these brief steps to publish your Ghost blog to GitHub Pages:

Create a GitHub repository to host your blog like mine.
Clone the repository to your local machine and create a gh-pages branch, or use the setup command of Buster.

$ buster setup --gh-repo=https://github.com/invictusjs/blog.git
Generate static files using Buster. As I mentioned above, the arguments are different from the original Buster.

$ buster generate --localhost=blog.jeongseok.net --public=blog.jeongseok.net
You can easily preview the static website on http://localhost:9000/:

$ buster preview
If you want to use your own domain, add a CNAME file to your repo. You can also use this Buster command:

$ buster add-domain blog.jeongseok.net
Add, commit and push the generated files. You can do so with the deploy command of Buster as well:

$ buster deploy
That's it. Now you can see your blog on http://USERNAME.github.io/blog.

Setup a domain for GitHub Pages

I setup a custom subdomain, blog.jeongseok.net for my Ghost GiHub Pages. If you've already added a CNAME file to your repo, all you have to do is just adding a CNAME record with your DNS provider. Refer to the CNAME record I added:

If you already setup your GitHub User Pages and added a CNAME file to the repo, http://USERNAME.github.io/blog is redirected to http://YOUR-USER-DOMAIN/blog. Otherwise the GitHub project page isn't redirected.

As I have my own virtual private server, I added jeongseok.net to the CNAME file on my GitHub user page and make the web server running in my VPS redirect http://jeongseok.net/blog to http://blog.jeongseok.net/

The static blog I published on GitHub Pages seems to work pretty well so far. I may move my blog entirely to my VPC later on but I'll stick to the current setting for now.