# 윈도 작업 관리자 개발자가 말하는 AI 코딩의 가능성과 한계

> 2025-09-06 · Lex Fridman · 큐레이션 김태우
> https://challengekim.com/insights/윈도-작업-관리자-개발자가-말하는-ai-코딩의-가능성과-한계
> 원문: https://lexfridman.com/dave-plummer-transcript

## 핵심 요약

- 데이브 플러머는 윈도 작업 관리자를 빠르고 안정적인 진단 도구로 만들기 위해 기능의 폭보다 응답성과 견고함을 중시했다고 말했다.
- 작업 관리자의 CPU 사용률이 100%를 넘던 오류는 추적 끝에 프로그램 자체가 아닌 운영체제 커널의 집계 문제로 확인됐다.
- 그는 게임 ‘템페스트’를 플레이하는 AI를 만들면서 게임 메모리에서 상태 정보를 추출해 강화학습 모델에 전달했다. 인터뷰 당시 모델은 약 36단계까지 진행했으며, 그가 제시한 목표인 96단계에는 이르지 못했다.
- 플러머는 AI가 생성한 파이썬 코드를 보며 새 언어를 익혔다. 다만 코드를 읽고 다음 작업을 지시하려면 프로그래밍 경험이 필요하다고 봤다.

## 빠른 도구가 필요했던 이유

플러머가 만든 윈도 작업 관리자는 어떤 프로그램이 CPU와 메모리를 쓰는지 살피고, 멈추거나 과도하게 자원을 쓰는 프로그램을 종료하는 도구다. 그는 처음에는 집에서 자신이 쓰려고 개발했다. 마이크로소프트 내부로 가져온 뒤에는 운영체제 내부 정보를 조회하는 기능을 이용해 필요한 수치를 더 빠르게 얻을 수 있었다고 설명했다. 초기 버전은 약 87KB였다.

그가 우선한 것은 기능을 많이 넣는 일이 아니라 위급할 때도 반응하는 프로그램을 만드는 일이었다. 예를 들어 다른 프로그램을 실행하는 호출이 네트워크 경로에 걸리면 응답까지 오래 걸릴 수 있다. 플러머는 이런 작업을 별도 실행 흐름에서 처리해 작업 관리자 화면이 함께 멈추지 않도록 했다. 화면도 값이 바뀐 행과 열을 추적해 필요한 부분만 다시 그리도록 구성했다.

## 오류의 위치를 증명하기까지

플러머에 따르면 작업 관리자에는 전체 CPU 사용률이 간혹 100%를 넘는 오류가 있었다. 그는 중간 계산과 최종 합계가 100%를 넘지 않는지 확인하는 검사 코드를 추가했지만, 사용자가 보는 오류는 계속 나타났다. 결국 야간 스트레스 테스트 중 디버거가 연결된 상태에서 문제가 재현됐고, 원인이 작업 관리자가 아닌 커널의 집계 방식에 있음을 확인했다. 수정도 커널에서 이뤄졌다.

그는 자신의 직업 경력에서 새 기능을 만드는 데 쓴 시간보다 디버깅과 수정에 쓴 시간이 훨씬 많았다고 회고했다. 당시에는 소스 코드 화면에서 바로 오류를 좇기 어려워 기계가 실행하는 어셈블리 명령을 살펴야 했고, 인텔·MIPS·알파·파워PC처럼 서로 다른 명령 체계도 다뤄야 했다.

## 게임 메모리에서 AI 학습 데이터로

플러머는 별도 프로젝트로 아타리 게임 ‘템페스트’를 플레이하는 AI를 개발했다. 먼저 게임의 ROM 코드를 역분석해 필요한 정보가 메모리 어디에 있는지 파악했다. 이어 루아 프로그램으로 실행 중인 게임의 상태를 추출하고, 이를 파이썬 프로그램에 보내 강화학습에 사용했다. 강화학습은 모델이 행동의 결과를 바탕으로 플레이 방식을 조정하는 방법이다.

그는 인터뷰 당시 AI가 약 36단계까지 진행한다고 말했다. 이를 대부분의 사람보다 나은 수준으로 평가하면서도, 자신이 목표로 삼은 96단계까지는 갈 길이 남았다고 했다. 프로젝트의 남은 작업으로는 모델의 크기와 층 구성 등 학습 설정을 조정하는 일을 꼽았다.

## 언어 속도 비교에 붙인 조건

플러머가 소개한 ‘GitHub Primes’는 소수를 찾는 알고리즘을 약 100개 프로그래밍 언어로 구현해 비교하는 프로젝트다. 각 구현은 5초 동안 1억까지의 소수를 찾는 작업을 가능한 한 많이 반복한다. 비교 대상에는 소수를 찾는 방식, 정수당 사용할 수 있는 메모리, 측정 중 메모리 할당 등 공통 규칙이 적용된다. 규칙을 따를 수 없는 일부 구현은 별도로 실행한다.

플러머는 인터뷰 시점에 Zig가 앞서는 것으로 기억했지만, C++ 구현이 개선되면 순위가 바뀌기도 한다고 말했다. 이 결과를 특정 언어의 보편적인 속도 순위로 제시하지 않은 셈이다. 동일한 과제와 규칙 아래에서도 구현을 어떻게 작성하느냐가 결과에 영향을 준다는 설명이다.

## AI가 코드를 쓰는 시대의 개발자 역할

플러머는 익숙하지 않은 파이썬 작업에 코드 생성 도구를 많이 사용했다. 생성된 코드를 읽으면서 간결한 파이썬 표현을 배울 수 있었다고 했다. 그러나 코드를 이해하고 다음에 무엇을 시킬지 판단하는 데에는 기존의 프로그래밍 능력이 필요하다고 봤다. 프로그래밍을 모르는 사람이 AI 생성 코드만으로 자신과 같은 방식으로 작업하기는 어렵다는 판단이다.

그는 앞으로 개발자가 코드의 개별 줄을 직접 다루기보다 구성 요소와 연결 방식을 정하고, AI에 각 부분의 구현을 설명하는 방향을 예상했다. 동시에 현재 도구가 복잡한 운영체제 전체를 요구 한 번으로 만들어낼 단계에는 이르지 못했다고 선을 그었다.

플러머의 사례에서 AI는 새 언어를 배우고 실험을 진행하는 데 도움이 됐다. 인터뷰에서 그가 반복해 강조한 개발자의 일은 생성된 결과를 이해하고, 시스템이 실제로 어떻게 작동하는지 확인하는 것이었다.

---

원문을 바탕으로 AI 가 한국어로 요약·재구성한 글입니다. 인용·수치는 원문 링크에서 확인해 주세요. [원문 링크](https://lexfridman.com/dave-plummer-transcript)