PC가 지금 얼마나 많은 작업을 하는지 파악하는 것이 사실 꽤 복잡하다는 것을 누가 알았을까요?

전직 마이크로소프트 엔지니어인 데이브 플러머(Dave Plummer)는 Windows에 ZIP 파일 지원 기능을 추가하고 Windows NT 시작 메뉴를 만드는 등 상징적인 프로젝트에 참여한 경력이 있습니다. 그는 작업 관리자(Task Manager)가 실제로 CPU 사용률을 어떻게 읽어들이는지에 대해 설명했습니다. 플러머가 작업 관리자의 원래 개발자이며, 이 도구가 컴퓨터 자원을 불필요하게 소모하지 않도록 (프로그래밍 및 엔지니어링 관점에서) 매우 단순하게 설계했음에도 불구하고, 때때로 표시되는 수치가 부정확하다는 비판이 있었습니다. 이에 플러머는 CPU 사용률 확인이 얼마나 복잡한지, 작업 관리자가 이 수치를 어떻게 얻어내는지, 그리고 왜 사용자가 실제로 느끼는 사용 현황과 다르게 보일 수 있는지 자세히 설명했습니다.
플러머는 "하지만 CPU 사용률을 측정한다는 것은 컴퓨터 과학 분야에서 가장 쉬운 작업 중 하나일 것 같은데요. 즉, CPU가 바쁘거나 아니거나 둘 중 하나 아닌가요? 실리콘으로 된 것이지, 해석적 춤이 아니니까요. 그저 Windows에 '이봐, 얼마나 바쁘니?'라고 묻으면 73% 같은 답이 나오고 우리 모두 일찍 퇴근하는 거 아닌가요? 하지만 실제로는 전혀 그렇지 않아요"라며, "가장 불편한 질문은 '도대체 무엇을 하면서 바쁜가?'라는 점입니다. 코어 하나가 바쁜 건지, 아니면 전체가 바쁜 건지? 현재 순간에 바쁜 건지, 지난 1~2초 동안의 평균치인지, 아니면 사용자의 UI가 임의로 깨어나는 주기에 따른 것인지? 사용자 모드(user mode)가 바쁜 건지, 커널 모드(kernel mode)가 바쁜 건지, 인터럽트 시간(interrupt time)이 바쁜 건지, 지연된 프로시저 호출(deferred procedure calls) 때문인지, 유휴 루프(idle loop)가 바쁜 건지, 아니면 스케줄러가 계산서를 받을 곳이 필요해서 존재하는 어떤 기묘한 회계 계정(accounting bucket)이 바쁜 건지 따져보기 시작하면, 간단한 속도계처럼 보였던 것이 마치 법의학적 회계(forensic accounting)처럼 보이게 됩니다"라고 말했습니다.
플러머는 작업 관리자가 타이머 기반(timer-driven)으로 작동하여 일정한 간격마다 업데이트된 수치를 새로 고침한다고 설명했습니다. 이는 시스템이 새로 고침 간격 사이의 PC 활동에 대한 해석을 보여주는 것이지, CPU의 실제 사용 현황을 실시간으로 보여주는 것은 아니라는 의미입니다. 가장 간단한 해결책은 CPU 사용률을 새로 고침 간격의 경과 시간으로 나누는 것이었겠지만, 플러머에 따르면 이는 GUI 타이머가 정확하게 작동하는 것에 달려 있습니다. 그는 이를 "오목한 비포장도로를 달리는 픽업트럭을 싣고 있는 메트로놈이 완벽하게 규칙적인 속도를 유지하는 것을 믿는 것"에 비유했습니다.
대신, 그는 작업 관리자에게 프로세스가 시작된 이후 해당 프로세스의 커널 시간과 사용자 시간 합계, 즉 총 시간을 요청하도록 프로그래밍했습니다. 그리고 이 특정 프로세스에 대해 마지막 새로 고침 때 기록된 총 값에서 그 값을 빼서 해당 기간 동안의 CPU 사용량을 계산합니다. 이 수치를 새로 고침 간격 사이에 모든 프로세스가 계산하고 소비한 총 CPU 시간으로 나눕니다. 이는 단순히 총 CPU 사용률을 경과 시간으로 나누는 방식보다 복잡하게 들릴 수 있지만, 훨씬 더 정밀한 해결책입니다.
그러나 기술적인 발전으로 인해 이러한 측정값은 부정확하게 느껴지게 되었습니다. 이 회계 방식은 단순히 평균적인 수치이기 때문에, 새로 고침 상태 간의 수치로는 특정 순간에 실제로 이루어진 작업량을 정확하게 반영하지 못합니다. 플러머는 "현대 CPU 사용률은 실제로 이동한 마일(mile) 수치라기보다는 고속도로가 얼마나 혼잡했는지에 가깝습니다. 페라리 같은 차들이 다니는 반쯤 혼잡한 고속도로가 오래된 시멘트 트럭으로 막힌 도로는 아닙니다. 이 둘을 비교할 수 있습니다."라고 설명했습니다.
그는 또한, "저희는 ... 그 간극이 생겼습니다."라고 말했습니다.

그는 "그것은... 이론적으로는 완벽하지만..."이라고 말하며, 현대의 복잡한 컴퓨터 구조와 소프트웨어의 발전으로 인해, 이 측정 방법 자체가 가지는 한계가 생겼음을 지적했습니다.
[독자 가이드] (이 부분은 번역하거나 포함할 필요는 없으나, 맥락 이해를 돕기 위해 참고용으로 남깁니다.)
이 글은 전문가 인터뷰나 기술 블로그의 일부로, 기술적인 한계와 이론적 모델의 현실 괴리를 논하고 있습니다.
[최종 검토]
전반적인 흐름을 유지하며 문장 연결을 자연스럽게 다듬었습니다. 특히 비유적 설명(교통체증, 간극) 부분은 인터뷰의 생동감을 살려 번역했습니다.