(Computer Science) System design choice에 대해서

하루 종일 책 쳐다보고 있는 그레인저 보이

Disclaimer:

해당 글은 computer system paper에 관련된 내용들 이다. 다른 학문의 논문은 읽어본적이 없으면 어떻게 비슷하고 다른지 잘 모르기 때문에 해당 내용이 적용이 될 수도 안될 수도 있다. 그래도 어느정도 다른 분야 논문들에도 적용이 될 수 있지 않을까 생각한다.

 

이 글의 Background

"Ray: A Distributed Framework for Emerging AI Applications" paper를 qual 준비를 위해 깊이 있게 읽고 있다. 해당 페이퍼는 회사로 이어지고 지금 Anyscale이라는 이름으로 아주 성공적으로 잘 나가고 있는 클러스터 스케쥴러 회사이다.

 

Ray 논문을 깊게 여러번 읽으며 느낀점

1. 여러 논문의 겉핡기식으로 읽는 거보다 한 논문의 깊이 이해하는 것이 훨씬 더 도움이 많이 되는 듯 하다.

2. 거꾸로 이야기하면 자신의 분야와 관련된 논문들에 시간투자를 많이해야한다. 그리고 관련 없는 페이퍼들은 톡보고 abstract and introduction 정도 읽고 skim through하는게 시간을 아끼는 길이다.

3. 아무 논문이나 흥미롭다고 닥치는 대로 읽으며 새로운 지식을 습득했다고 뿌듯함을 느끼는 것은 굉장히 위험한 행동이다. 지식습득은 그렇게 primary goal이 아니다. 지식습득은 생각보다 쉽고 경쟁력을 갖추지 못한다. 보기에는 멋있을지 몰라도.

 

'깊이 읽는다'라는 것

보통 대학원 수업들을 보면 페이퍼 리딩이 수업의 거의 대부분이다. 그리고 리뷰를 쓰라고 하는데 "review"를 쓰라고 하는 거 보면 결국 "summary"를 쓰게 된다. 그리고 possible improvement or weakness 몇개 쓰고 critical reading했다 라고 스스로 행복해할 수 있다.. 그런데 이제서야 내가 느끼는 깊이 읽는다 의 옳은 정의는

- Design choice를 이해해야한다. 왜 그렇게 system을 design하였는지 이해해야한다.

- 그 말은 즉은 다른 design choice가 무엇이 있었는지 그리고 그 alternative design choice가 무엇일 수 있는지 파악이 되면 좋다. 이는 보통 alternative design을 별개의 paragraph에서 언급하지 않으면 related work 과 intro에서 contribution을 주장할때 보통 언급된다. 거기에 나오는 related work들에 대한 이해가 있어야한다. 다 이해해야하는 건 아니기도 하다. Related works를 broad하게 다류는 경우들이 많기도 하기 때문이다. 여기서 잘 이해해야하는 related work은 directly related works이다. baseline + 좀 더 정도 랄까.

 

또 중요한 것.

Design choice ≠ Techniques or optimization that the paper uses

 

이제까지 위의 두개를 분리해서 이해하지 못하는 경우가 자주 발생한다. 거꾸로 이야기 하면 system design을 하자 라는 말을 이해하지 못하고 있었다고 보면 되겠다... (본인도 많이 그랬었다.)

system design을 system optimization과 혼동해서 이해하고 있었던 거 같다.

 

Ray는 여러번 읽으며 이해를 더 깊게 하게 되었다. 이렇게 디자인한 이유와 해당 디자인의 장점 그리고 왜 이 시스템이 좋은지/나쁜지 이해가 조금 됐달까.

 

이렇게 제대로 이해한 페이퍼가 언제인지... (물론 다시 말해 페이퍼 페이퍼 리딩에 너무 많은 시간을 쓰는 것은 좋지 않다.)