시스템 연구에 대한 단상

 

시스템 연구...?

이 연구실에 와서 "시스템 연구"라는 것을 처음으로 들어봤다. 일반적으로 "알고리즘 연구"와 대비되는 의미로 사용하는데, 그렇다고 아주 명확한 경계가 있는 것은 아닌듯 하다. 

 

시스템 연구가 굉장히 생소하게 느껴졌던 이유는, (일단 '시스템'이라는 말 자체가 너무 포괄적이어서 처음 보면 이게 도대체 뭔지 감이 안 올 뿐더러) 그 동안 컴퓨터공학에서 배웠던 것들이 알고리즘 위주이기 때문이다. 보통 처음에 프로그래밍 언어를 하나 배우고, 그거로 각종 알고리즘 문제를 푼다거나 자료구조를 배우기 시작한다. 여기서부터 "컴퓨터=알고리즘"이라는 사고가 고착화되어버린다. 그 후 컴퓨터구조, 운영체제 등 컴퓨터가 어떻게 동작하는지 로우레벨 단도 배우고 데이터베이스, 네트워크 등의 거대한 시스템들을 배운다. 이러한 시스템들을 잘 배우면 시스템의 의미에 대해서 약간은 깨우칠 수 있지만, bottom-up식 사고에 익숙한 (나를 포함한) 대부분의 학생들은 그 거대한 시스템 안의 자잘한 컴포넌트들, 특히 알고리즘들에 집중하게 된다. 그 동안 그런 식으로 공부해왔으니까... 뿐만 아니라, 우리가 많이 접하는 연구논문들도 알고리즘 쪽이 많긴 하다. 특히 딥러닝 분야 탑티어 학회들의 논문들을 보면 알고리즘 연구가 대부분이다. (물론 아직 덜 mature한 분야라서 그런것도 있긴 하다.)

 

 

뭘 하는가?

하지만 컴퓨터를 다루는 것, 그리고 시스템을 디자인하는 것은 단순히 알고리즘을 만드는 것 이상의 일이다.

먼저, 어떤 로직을 타겟 디바이스에 얹으려고 할때 여러 문제들이 발생한다. 하드웨어 설계 문제일 수도 있고, 현실적인 워크로드와 이상적인 워크로드 간의 차이 문제일 수도 있다. 혹은 성능 개선을 위한 로직을 추가하려는데 다른 부분에서 병목이 발생하는 바람에 end-to-end 퍼포먼스는 개선되지 않을 수도 있다. 이런 여러 가지 문제들을 고려하는 것이 시스템 디자이너 혹은 시스템 연구하는 사람들의 일이다. 결국 엔지니어링 문제다.

또한, 디자인 tradeoff를 고려해야 한다. Accuracy, latency, power 등 여러 측면의 메트릭들에 대해, 이들의 상호관계는 어떠한지, 이 시스템의 튜닝 가능한 파라미터들이 메트릭들에 어떤 영향을 미치는지, tradeoff 커브 자체를 개선할 방법은 없는지 생각해야 한다. 고려하는 메트릭이나 knob들이 많아질수록 더욱 어려워진다.

결국 시스템 연구는 문제 모델링을 실제로 컴퓨터에서 효율적으로 enable시키는 것이다. 그 후 문제를 실제로 푸는 것은 알고리즘 연구한테 맡긴다. 어차피 알고리즘은 plug-and-play하면 되니까.

 

 

예를 들어, Heimdall: mobile GPU coordination platform for augmented reality applications (MobiCom'20) 논문을 보자. 이 논문의 모티베이션은 모바일 환경에서 여러 개의 DNN 모델을 병렬적으로 실행하기 힘들다는 것이다. 여기서부터 워크로드에 대한 고려가 들어간다. 아래와 같이 미래 AR 앱들이 감당해야 할 워크로드를 시나리오에 기반하여 정해놓고 이에 맞게 시스템을 최적화하고자 한 것이다. (미래지향적인 논문이므로 당장 현실에서 흔히 볼 수 있는 워크로드는 아니긴 하지만 어쨌든 미래에는 충분히 있을 법하다.)

 

모바일에서 여러 DNN을 실행하기 힘든 이유는, 데스크탑 gpu와 달리 모바일 gpu는 병렬 실행을 아키텍쳐 상에서 지원하지 않고, fine-grained time-sharing을 하기에는 메모리 bandwidth가 상당히 작기 때문이다. 즉, 데스크탑에서는 잘 돌아가던 스케줄링 알고리즘들을 모바일 환경에서는 사용하기 힘들다. 논문에서는 이걸 가능하게 하기 위한 메커니즘으로 'pseudo-preemption'을 제안한다. 간단히 말하면 DNN을 operator 단위로 잘게 쪼개고, 한 단위가 끝났을 때만 preemption을 허용하는 방법이다. 이렇게 함으로써 모바일에서도 fine-grained time-sharing을 하면서도 추가적인 메모리 엑세스 비용을 없앴다. 

이렇게 메커니즘을 디자인한 후, 각 DNN들의 유틸리티에 따라 스케줄링하는 스케줄링 폴리시를 제안한다. 이 폴리시가 일종의 알고리즘이고, 이후 이 시스템을 사용하는 유저들이 각자의 상황에 맞게 자유롭게 plug-and-play할 수 있는 부분이다. 논문에서는 간단하게 사용할 수 있는 폴리시들을 몇 가지 제안해주는 것뿐이다.

 

 

반성합니다

처음 시스템 연구라는 걸 접하고 논문들을 읽었을 때, 되게 별로라고 생각이 드는 논문들이 많았다. 알고리즘 지향적인 사고를 갖고 있던 내가 보기에는 딱히 얘네가 한 일이 크게 없어 보이고, novelty도 떨어져보였던 거다. 위에 Heimdall 논문도 마찬가지로 처음 봤을 때는 '결국 그냥 DNN 쪼갠 게 끝 아니야? 너무 아무것도 없는데?'라고 생각했다. 하지만 (비록 심플하더라도) 모바일 GPU에서 multi-DNN을 실행할 수 있도록 하는 메커니즘을 고안해냈다는 점, 각종 시나리오와 워크로드를 만들고 그에 맞게 실험했다는 점 등을 생각해보면 충분히 의미 있는 연구이다. 

시간이 지나면서 시스템 연구는 알고리즘 연구와는 조금은 다른 방향의 일을 하고 있고, 이 역시 매우매우 중요하다는 것을 조금은 깨닫게 되었다. 알고리즘 연구가 어떤 태스크에서 성능을 대폭 상승시켰다고 해도 현실 애플리케이션에서는 아무런 영향이 없을 수도 있다는 점...을 생각하면, 시스템 연구 참 감사하다~

시스템 논문들뿐 아니라 그동안 내가 별로라고 생각했던 논문들도 다시 돌아볼 필요가 있다는 생각이 조금씩 든다. 어쩌면 내가 해당 논문의 차별점이나 contribution을 충분히 개념화하지 못해서 논문이 별로라고 느꼈을 수도 있기 때문이다. 아는 만큼 보인다.

 

그리고 '알고리즘을 잘하는 사람보다는 컴퓨터를 잘하는 사람이 되자!'는 생각도 든다... 알고리즘 팔거였으면 수학과 갔어야지 ㅎㅎ

복잡한 컴퓨터 시스템을 잘 이해하고 디자인할 수 있는 사람이 된다면 좋을 거 같다.