솔직히 고백하자면, 처음 이 프로젝트를 접했을 때 헛웃음이 나왔습니다. "OS 프로세스 스케줄러를 LLM으로 교체한다니, 배보다 배꼽이 더 큰 거 아닌가?"라는 생각이 먼저 들었거든요. 보통 우리가 시스템 최적화를 논할 때는 마이크로초(µs) 단위의 레이턴시(Latency)를 줄이기 위해 C++이나 Rust로 로직을 쥐어짜곤 합니다. 그런데 무거운 LLM을 가장 민첩해야 할 스케줄링 영역에 가져온다니요. 하지만 brainkernel이라는 오픈소스 프로젝트의 코드를 뜯어보고 구동 원리를 살펴보면서, 제 생각은 '무모함'에서 '가능성'으로 바뀌었습니다. 오늘은 이 재미있는 실험이 우리에게 시사하는 바를, 기술적 관점과 비즈니스적 관점에서 이야기해보고자 합니다.
기존의 OS 스케줄러(Scheduler)는 근면 성실하지만 '눈치'가 없습니다. CFS(Completely Fair Scheduler) 같은 알고리즘은 CPU 자원을 공평하게 분배하는 데는 도사지만, 프로세스의 '의도'는 전혀 파악하지 못합니다. 예를 들어 Chrome이 CPU를 40%나 쓰고 있다면, 기존 OS는 그저 "자원을 많이 먹네"라고만 판단합니다. 하지만 사용자는 화상 회의 중일 수도 있고(중요함), 단순히 광고 스크립트가 폭주하는 중일 수도 있습니다(죽여야 함). 이 프로젝트의 핵심은 바로 이 지점, '정량적 측정'의 영역에 '정성적 판단'을 개입시켰다는 데 있습니다.
brainkernel은 Python과 Textual 기반의 TUI(Terminal User Interface)로 작동하며, psutil로 수집한 프로세스 정보를 LLM(Groq API 또는 로컬 Ollama)에게 넘깁니다. 그리고 묻습니다. "이 프로세스가 왜 돌고 있는 것 같아? 살려둘까, 죽일까?" 흥미로운 점은 LLM이 단순히 자원 점유율만 보는 게 아니라, 부모 프로세스 관계(Parentage)나 디스크 I/O 패턴을 보고 맥락을 읽어낸다는 것입니다.
개발자로서 인상 깊었던 부분은 '안전장치(Safety Rail)'에 대한 설계였습니다. AI가 제멋대로 시스템 프로세스를 종료하면 재앙이 닥칠 테니까요. 이 프로젝트는 'Diplomatic Immunity(외교적 면책 특권)'라는 개념을 도입해 브라우저나 IDE(VS Code 등)는 절대 건드리지 않도록 하드코딩된 보호막을 쳤습니다. 또한, PID Safety Lock을 통해 OS가 PID를 재사용하는 Race Condition 상황까지 고려했습니다. 단순히 LLM을 API로 호출하는 것을 넘어, 시스템 엔지니어링의 기본 원칙 위에 AI의 추론 능력을 얹으려는 시도가 엿보이는 대목입니다.
물론 실무에 바로 적용하기엔 아직 갈 길이 멉니다. API 호출 비용이나 네트워크 지연 시간은 실시간 OS 커널 레벨에서는 치명적일 수 있습니다. 하지만 이 프로젝트가 보여준 'Context Aware Computing'의 비전은 명확합니다. 벤더들이 몰래 심어놓은 블로트웨어(Bloatware)를 AI가 "이건 사용자에게 가치가 없다"고 판단하여 종료시키고, 심지어 "Hall of Shame"에 기록해 사용자가 낄낄거리게 만드는 UX(Roast Mode)는 기계적인 시스템 관리에 인간적인 감성을 불어넣습니다.
비즈니스 리더나 CTO 분들께서는 이 사례를 통해 '에이전트(Agent)의 확장'을 고민해 보셨으면 합니다. 지금은 터미널 앱 수준이지만, 머지않아 Windows나 macOS의 NPU(신경망 처리 장치)가 로컬에서 이 역할을 수행하게 될 것입니다. 직원의 업무 몰입을 방해하는 프로세스를 OS 차원에서 능동적으로 차단하거나, 서버 리소스를 낭비하는 좀비 프로세스를 맥락 기반으로 정리하는 것. 이것은 단순한 자동화(Automation)가 아니라, 시스템이 스스로 판단하는 자율화(Autonomy)의 초기 단계입니다.
우리는 그동안 시스템을 '어떻게(How)' 최적화할지에만 몰두했습니다. 하지만 AI 시대의 개발은 시스템이 '왜(Why)' 작동하는지를 묻는 방향으로 나아가야 합니다. 여러분의 레거시 시스템 중, 단순히 규칙(Rule)대로만 돌아가서 비효율을 낳고 있는 부분은 없나요? 그곳에 작은 '전두엽'을 달아주는 상상을 해보시기 바랍니다. 기술의 발전은 언제나 엉뚱한 상상을 현실적인 코드로 구현하는 과정에서 시작되었으니까요.
