TL;DR

  • 리눅스 설정이 기술과 인내심을 시험하는 통과의례였지만, 두 대의 리눅스 머신에서 겪은 여섯 가지 문제 가운데 대부분은 에이전트와 함께 5분 이내에 해결됐으며, 바뀐 것은 작업 자체가 아니라 조사 과정임.
  • 기존에는 증상을 검색하고, 다른 배포판을 위한 위키와 오래된 포럼 글을 비교하며, 한 번에 하나씩 명령을 시험하는 데 문제마다 2~5시간이 들었음.
  • Aquamarine, World of Warcraft의 마우스 입력, 키보드 입력, 카드 스캐너, 열전사 프린터, Canon PIXMA 프린터가 두 머신에서 차례로 문제를 일으켰으며, 키보드와 스캐너는 해결에 더 오래 걸림.
  • 에이전트는 조사 결과를 설명한 상황에 맞는 명령으로 바꾸지만, 사용자는 결과를 확인하고 책임져야 하며 스캔의 채도나 키 입력 같은 현장 검증을 대신하지 못함.
  • 에이전트의 권한을 기본적으로 신뢰해서는 안 되며, 설정 변경은 먼저 계획을 확인하고 디스크 구성·부트로더·자격 증명처럼 영향 범위가 큰 작업은 특히 신중히 다뤄야 함.

개발자들은 왜 여전히 macOS를 선택하는가?

  • X에서 개발자들이 여전히 macOS를 선택하는 이유를 묻는 글에, 리눅스 설정이 수십 년 동안 구성과 드라이버 문제를 견뎌야 하는 통과의례처럼 취급됐기 때문이라고 답함.
  • macOS를 계속 쓰는 이유로 흔히 나오는 “그냥 작동한다”는 말은 첫 주의 차이를 가리킴. 리눅스에서는 그 첫 주가 자리를 얻기 위해 치러야 하는 과정이었음.
  • 예전에는 증상을 발견한 뒤 검색하고, 2019년 포럼 글과 다른 배포판을 위한 위키를 찾아 명령을 하나씩 시도했음. 두 가지를 동시에 바꾸면 어떤 변경이 도움이 됐는지 알기 어려웠음.
  • 실패가 조용히 발생해 실제 오류 메시지를 끌어내야 하는 경우도 있었으며, 그때는 어떤 구성 요소가 고장 났는지부터 찾아야 했음.
  • 문제가 무엇인지 파악한 뒤에도 설정을 바꾸는 방법을 알아내야 했으며, 에이전트가 없던 때에는 이런 문제마다 2~5시간이 걸렸을 것으로 추정함.
  • 이 과정이 통과의례였으며, 측정한 것은 인내심이었음.

내 머신에서 실제로 고장 난 것은 무엇인가?

  • 현재 리눅스 머신 두 대를 사용함. 하나는 macOS와 이중 부팅하는 Asahi 기반 M1 MacBook Pro이며, 다른 하나는 Windows 11과 이중 부팅하는 x86_64 데스크톱임.
  • M1 설치 중 Aquamarine 문제가 발생함. Omarchy 설치 프로그램이 Hyprland의 렌더링 라이브러리인 Aquamarine을 설치하기에는 너무 최신인 버전으로 가져오려 했음.
  • 설치가 진행 중이어서 휴대전화에서 Claude를 사용했고, Claude가 조사해 명령을 작성한 뒤 직접 적용함. 해결 방법은 pacman 캐시에 있던 이전 빌드로 다운그레이드하는 것이었음.
  • 이 문제는 M1 현장 보고서에 정리함.
  • 데스크톱의 World of Warcraft 정식 버전에서 마우스 입력이 인식되지 않았음. 약관에 동의하려고 스크롤할 수 없었고 일부 클릭도 무시됐음.
  • 원인은 Hyprland가 입력을 게임 창으로 전달하는 방식이었으며, Claude Code로 비교적 빠르게 해결함.
  • 데스크톱에서 키보드 기능 키와 일부 다른 입력이 처음부터 작동하지 않았음. 에이전트와 함께 키를 누르고 결과를 반복해서 확인하며 실제로 어떤 신호가 머신에 도달하는지 점검했으며, 시간이 조금 더 걸림.
  • 데스크톱의 트레이딩 카드 스캐너는 처음부터 작동하지 않았음. Claude Code를 이용해 스캔 기능을 작동시키는 데는 오래 걸리지 않았지만, 실제로 사용할 만한 결과를 얻는 데는 더 오래 걸림.
  • 이미지를 제대로 만들기 위해 여러 차례 스캔하며 채도와 색상을 조정함. Windows에서는 제조업체의 PaperStream 소프트웨어로 쉽게 조정할 수 있었음.
  • 열전사 프린터는 올바른 크기로 인쇄하지 못했고 네트워크에서도 보이지 않았음.
  • Canon PIXMA 프린터 역시 네트워크에서 보이지 않았으며, 두 프린터 모두 에이전트와 함께 문제를 진단함.
  • 이런 문제는 특이한 사례가 아니라, 하드웨어 제조업체가 우선 대상으로 삼지 않는 운영 체제에서 흔히 치르는 비용임.

무엇이 바뀌었고, 무엇이 바뀌지 않았는가?

  • 측정값이 아닌 개인적 추정으로, 문제 대부분은 에이전트를 사용한 뒤 5분 이내에 해결됨. 키보드와 스캐너는 더 오래 걸렸으며 다른 문제와 맞추려고 시간을 줄여 말하지 않음.
  • 공정한 반론은 리눅스에 더 익숙해진 것 아니냐는 점이며, 부분적으로는 그럴 수 있음. 에이전트가 없었다면 같은 문제에 걸렸을 시간은 추정치임.
  • 바뀐 것은 누가 조사하는가임. 에이전트는 포럼 글과 위키를 읽고, 실제로 설명한 문제에 맞는 명령으로 바꿈.
  • 결과가 원하는 것인지는 여전히 직접 확인함. 에이전트는 스캔의 채도가 적절한지 판단할 수 없고 키보드의 키를 직접 눌러 볼 수도 없음.
  • 결과에 대한 책임은 여전히 사람에게 있음. 에이전트는 모든 자료를 읽었지만 책상을 본 적은 없는 빠른 동료와 같으며, 수행한 내용을 읽고 결과를 확인해야 함.

에이전트가 운영 체제를 고치게 해도 안전한가?

  • 기본적으로 안전하다고 볼 수 없음. Omarchy 실행기에서 시작하면 시스템을 고치는 에이전트가 승인 절차를 건너뛰고 실행될 가능성이 있음.
  • 에이전트 안전성 글에서 해당 실행기를 살펴본 결과, 실행 방법을 아는 에이전트 열네 개 가운데 열한 개가 각기 다른 표현으로 “멈춰서 묻지 말라”는 설정과 함께 실행됨.
  • Omarchy 자체 설명서는 설정 기술을 실험적이라고 표시하고, 실행 전에 에이전트가 하려는 일을 읽을 수 있도록 먼저 계획 모드를 사용할 것을 권장함.
  • 에이전트가 설정을 망쳤을 때 되돌리는 방법으로 omarchy reinstall configs를 안내함. 이 내용은 에이전트 안전성 글에서 인용함.
  • 해당 기술은 설정 파일을 다루지만, 프린터나 스캐너 드라이버에는 루트 권한이 필요함. AGENTS.md를 읽은 내용에 인용된 Omarchy 규칙에 따르면, 에이전트가 실행하는 권한 상승 명령에는 암호 입력이 요구됨.
  • 프린터 작업이라면 암호 입력에 응할 수 있지만, 디스크 구성·부트로더·자격 증명에 영향을 주는 작업이라면 먼저 계획을 확인하고 싶음. 같은 에이전트라도 영향 범위에 따라 대응이 달라짐.

에이전트에게 운영 체제 변경을 맡기는 사람은 나뿐인가?

  • 그렇지 않음. Shopify CEO Tobi Lütke는 The Knowledge Project에서 에이전트에게 요청해 운영 체제를 바꾸며 설정 파일은 직접 건드리지 않는다고 말함.
  • 이는 2026년 9월 15일 공개된 에피소드의 약 21분 51초부터 나오는 발언을 바꿔 표현한 것임. 전혀 다른 위치에서 같은 변화가 나타남.

macOS를 선택하는 이유는 왜 약해지고 있는가?

  • macOS는 개발자가 설정 비용을 치르지 않아도 되는 머신이라는 이유로 자리를 얻었으며, 오랫동안 타당한 이유였음.
  • 이제 드라이버 문제를 해결하는 비용이 오후 한나절에서 대화 한 번으로 줄어들면서 그 이유는 약해짐. 터미널 사용에 익숙하고 에이전트가 돌려준 결과를 확인할 의향이 있는 개발자에게 “그냥 작동한다”는 말은 더는 충분히 강한 주장이 아님.
  • 이 판단은 두 대의 머신, 설정을 직접 만져도 괜찮다는 성향, 복구 가능한 시스템을 전제로 함. 월요일 아침에 반드시 필요한 노트북이나 회사 머신 여러 대, 결과를 확인하는 역할을 맡고 싶지 않은 사람에게까지 적용되는 말은 아님.
  • 리눅스의 통과의례는 리눅스의 본질이 아니라 질문에 답해 줄 사람이 없었던 데서 생긴 부작용이었음. 이제는 그런 역할을 하는 무언가가 있음.