새로운 Windows 머신에서 당연한 너드(nerd) 실험을 해보았습니다. 바로 AI 에이전트에게 설정을 맡기는 것이었습니다.

약 2분 동안은 똑똑해 보였습니다.

그러더니 OpenClaw가 설치 프로그램의 체크박스에서 막히고, 모달 창(modal windows)에서 멈추며, 일반적으로 방에 왜 들어왔는지 잊어버리는 것과 같은 디지털적 상황을 연출하는 것을 지켜보았습니다.

에이전트가 여전히 하나의 설치 프로그램과 싸우고 있는 동안, 저는 전략을 바꿨습니다:

• 일반적인 앱 번들에는 Ninite 사용
• 유지하고 다시 실행하고 싶은 패키지 설치에는 WinGet 사용
• 지루한 시스템 수준(system-level) 작업에는 PowerShell 사용
• 클릭이 아닌 계획 수립에는 GPT-5 또는 Claude 사용

이 조합은 에이전트가 회복하기 전에 18개의 앱 설치를 완료했습니다.

그리고 이 r/openclaw 스레드를 읽어본 후, 저는 진짜 교훈이 Windows 설정보다 더 크다는 것을 깨달았습니다:

GUI를 구동하는 에이전트는 결정론적(deterministic)인 작업에 잘못된 추상화(abstraction)입니다.

만약 작업이 "이 머신에 무엇이 필요한지 파악하라"는 것이라면, 모델을 사용하세요.
만약 작업이 "이 18가지를 설치하고 더 이상 흥미로운 짓을 하지 마라"는 것이라면, 스크립트를 사용하세요.

실수: 에이전트에게 마우스가 되라고 요구하는 것

저는 에이전트에 반대하는 것이 아닙니다.

저는 취약한 자동화(anti-fragile-automation)에 반대하는 것입니다.

OpenClaw, GPT-5, 그리고 Claude는 문제가 모호할 때 유용합니다:

• "이 머신을 Python, Docker, VS Code, Node, 그리고 로컬 Ollama 스택을 사용할 수 있도록 설정해줘"
• "패키지 매니저들을 비교하고 가장 깔끔한 설치 경로를 제안해줘"
• "설정 스크립트를 초안하고 무엇이 실패할 수 있는지 설명해줘"

문제가 완전히 결정론적일 때는 훨씬 덜 유용합니다:

• Next 클릭
• 번들로 제공되는 툴바 거절
• 기본 설치 경로 선택
• 대기
• 17번 반복

두 번째 카테고야말로 WinGet, Ninite, 그리고 PowerShell이 지루함을 무기로 승리하는 영역입니다.

지루한 것이 좋은 것입니다.

이것은 n8n, Make, Zapier 또는 커스텀 에이전트 워크플로우의 실제 자동화에서 볼 수 있는 것과 동일한 패턴입니다:

• GPT-5 또는 Claude가 지저분한 입력을 해석하게 합니다.
• 결정론적인 단계들이 계획을 실행하게 합니다.
• 판단이 필요한 경우가 아니라면 모델을 루프(loop)에서 제외합니다.

그러한 아키텍처는 더 빠르고, 디버깅이 쉬우며, 보통 더 저렴합니다.

새로운 Windows 설정에서 실제로 효과가 있었던 것

제가 다시 사용한다면 다음과 같이 분류하겠습니다.

Reddit이 계속해서 Ninite를 추천하는 이유

깨끗한 상태의 Windows를 설치한 첫 한 시간 동안, Ninite는 여전히 말도 안 될 정도로 효율적이기 때문입니다.

만약 다음과 같은 번들을 원한다면:

• Chrome
• 7-Zip
• VLC
• Discord
• Zoom
• Steam
• Spotify
• Notepad++

Ninite를 이기기는 어렵습니다.

앱을 선택하고, 설치 프로그램 하나를 다운로드하여, 한 번 실행하면 끝입니다.

제조사 사이트를 뒤져가며 보물찾기를 할 필요도 없습니다.
애드웨어(adware) 체크박스를 찾기 위해 고고학자가 될 필요도 없습니다.
열 개의 탭을 띄워놓고 설치 의식을 치를 필요도 없습니다.

이것이 Reddit에서 계속 언급되는 이유입니다. Ninite는 아주 최소한의 절차로 명백한 문제를 해결합니다.

WinGet이 Ninite를 압도하는 지점

재현성(repeatability)이 중요해지는 순간, WinGet이 승리합니다.

즉, 다음과 같은 상황을 의미합니다:

• 개발용 머신 재구축
• 여러 대의 노트북 프로비저닝 (provisioning)
• 온보딩 (onboarding) 문서화
• 팀 환경 표준화
• Git을 이용한 설정 스크립트 버전 관리

유용한 명령어 몇 가지:

winget search vscode
winget install --id Microsoft.VisualStudioCode -e
winget install --id Docker.DockerDesktop -e
...

설치된 항목 내보내기:

winget export -o apps.json

나중에 새 머신에서 가져오기:

winget import -i apps.json

이것은 에이전트가 모든 설치 프로그램 UI의 변동성을 견뎌낼 수 있기를 바라는 것보다 훨씬 더 나은 기반이 됩니다.

완전한 에이전트 제어를 능가하는 실용적인 설정 흐름

이것은 제가 대부분의 개발자에게 추천하는 워크플로 (workflow)입니다.

1) GPT-5 또는 Claude를 사용하여 계획 생성하기

프롬프트 예시:

백엔드 개발을 위해 새로운 Windows 11 머신을 설정하고 있습니다.
Python, Node.js, Docker Desktop, VS Code, Git, Postman, WSL, 그리고 Ollama가 필요합니다.
다음 내용을 제공해 주세요:
...

이 지점이 모델들이 빛을 발하는 부분입니다. 모델들은 다음과 같은 일을 할 수 있습니다:

• 모호한 요구사항을 구체적인 체크리스트로 변환
• 누락된 의존성 (dependencies) 포착
• 패키지 이름 제안
• 트레이드오프 (tradeoffs) 설명
• 무언가 실패했을 때 계획 재작성

2) 당연한 데스크톱 번들에는 Ninite를 사용하세요

흔히 쓰이는 앱들을 빠르게 가져오세요.

논쟁이 필요 없는 항목들에 Ninite를 사용하세요.

3) 계속 유지하고 싶은 모든 것에는 WinGet을 사용하세요

예시:

$packages = @(
  "Microsoft.VisualStudioCode",
  "Git.Git",
...

4) 시스템 설정에는 PowerShell을 사용하세요

예시:

wsl --install
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
mkdir $HOME\dev -ErrorAction SilentlyContinue
...

5) 정리 작업이나 예외적인 경우에만 GUI 에이전트를 사용하세요

어떤 이상한 설치 프로그램이 패키지도 없고 무인 설치 (silent install) 옵션도 없다면, 괜찮습니다.

그럴 때 OpenClaw 스타일의 제어가 도움이 될 수 있습니다.

하지만 그것은 예외여야지, 아키텍처 (architecture)가 되어서는 안 됩니다.

예시: 계획을 위한 모델, 실행을 위한 스크립트

이것은 PC 설정을 넘어 확장 가능한 패턴입니다.

GPT-5나 Claude에게 다음과 같은 스크립트를 초안으로 작성해 달라고 요청할 수 있습니다:

$apps = @(
  "Microsoft.VisualStudioCode",
  "Git.Git",
...

이것은 AI에게 말 그대로 화면을 지켜보며 Next 버튼이 어디로 이동했는지 추측하라고 시키는 것보다 훨씬 더 나은 AI 활용법입니다.

동일한 교훈이 에이전트 워크플로 (agent workflows)에도 적용됩니다

이것은 단순히 Windows에 관한 글이 아닙니다.

이것은 여러분이 어떤 진지한 자동화 (automation)를 수행하든 내리게 되는 동일한 설계 결정입니다:

• n8n에서, 일반적인 HTTP 노드가 할 수 있는 일을 시뮬레이션하기 위해 모델을 사용하지 마세요.
• Make에서, 구조가 이미 알려져 있다면 결정론적 (deterministic)인 필드 매핑에 토큰을 낭비하지 마세요.
• Zapier에서, 직접 표현할 수 있는 API 호출을 모델에게 즉흥적으로 해달라고 요청하지 마세요.
• 커스텀 에이전트 프레임워크에서, 스크립트가 되어야 할 실행 경로 (execution paths)를 모델이 소유하게 두지 마세요.

모델은 다음을 위해 사용하세요:

• 계획 (planning)
• 분류 (classification)
• 추출 (extraction)
• 폴백 추론 (fallback reasoning)
• 실패한 단계 재작성 (rewriting failed steps)

결정론적 도구 (deterministic tools)는 다음을 위해 사용하세요:

• API 호출 (API calls)
• 패키지 설치 (package installs)
• 파일 작업 (file operations)
• 인프라 변경 (infrastructure changes)
• 반복적인 실행 (repetitive execution)

이러한 분리가 에이전트를 값비싼 연극이 아닌 유용한 도구로 만듭니다.

워크플로가 반복되기 시작하면 비용이 더 중요해집니다

이 지점이 PC 설정 실험이 실제 운영 자동화 (production automation)와 직접적으로 연결되는 부분입니다.

다음과 같은 작업을 위해 GPT-5나 Claude를 루프(loops) 내에서 사용하기 시작하면:

• 계획 생성 (plan generation)
• 재시도 (retries)
• 스크립트 수정 (script repair)
• 모니터링 (monitoring)
• 예외 처리 (exception handling)
• 다단계 에이전트 워크플로 (multi-step agent workflows)

토큰당 과금 방식 (per-token pricing)이 금방 짜증스럽게 느껴질 것입니다.

모델이 나쁘기 때문이 아닙니다.
반복적인 작업이 예측하기 어려운 방식으로 비용을 배가시키기 때문입니다.

그것이 바로 에이전트와 자동화(automations)를 구축하는 개발자들에게 정액제 컴퓨팅 (flat-rate compute)이 흥미로운 이유입니다.

만약 당신의 워크플로 아키텍처가 "모델이 생각하고, 스크립트가 실행한다"라면, 판단이 필요한 부분들을 위해 모델을 지속적으로 사용할 수 있어야 합니다. 다만 모든 재시도와 계획 수립 단계가 마치 과금 이벤트처럼 느껴지기를 원치 않을 뿐입니다.

이것이 Standard Compute의 매력입니다:

• 고정된 월간 가격 (flat monthly pricing)
• OpenAI 호환 API
• 기존 SDK 및 HTTP 클라이언트와 연동 가능
• n8n, Make, Zapier, OpenClaw 및 커스텀 에이전트 워크플로에 유용함
• 자동화가 하루 종일 돌아가는 동안 토큰당 과금에 대한 불안감 없음

이러한 가격 모델은 모든 워크플로를 단 하나의 저렴한 완료(completion)로 축소할 수 있는 척하는 것보다, 에이전트 중심의 시스템에 훨씬 더 합리적입니다.

이것을 시도해 본 후의 실제 의견

Ninite에 대한 Reddit의 말은 맞았습니다.

하지만 문제의 첫 번째 계층에 대해서만 해당되는 이야기였습니다.

처음에 어리석은 방식으로 직접 해본 후 저의 견해는 다음과 같습니다:

• Ninite는 새 PC에서 빠르게 번들을 설치할 때 가장 좋습니다.
• WinGet은 반복 가능하고 개발자 수준의 설정을 할 때 가장 좋습니다.
• PowerShell은 시스템 구성 및 자동화 접착제 (automation glue) 역할에 가장 좋습니다.
• GPT-5 또는 Claude는 워크플로를 계획하고 수정하는 데 가장 좋습니다.
• OpenClaw와 같은 GUI 에이전트는 결정론적 경로 (deterministic path)가 존재하지 않는 예외적인 경우(edge cases)를 위해 남겨두는 것이 가장 좋습니다.

승리하는 패턴은 "에이전트가 모든 것을 하게 만드는 것"이 아닙니다.

그것은 다음과 같습니다:

1. 모델이 무엇이 일어나야 할지 결정하게 한다
2. 스크립트와 패키지 관리자(package managers)가 작업을 수행하게 한다
3. 환경이 이상해질 때만 에이전트를 다시 불러온다

이것이 어처구니없는 새 PC 실험으로부터 얻은 유용한 교훈이었습니다.

에이전트가 도움이 되기 시작한 것은 제가 에이전트에게 마우스인 척하라고 요구하는 것을 그만두었을 때부터였습니다.

만약 여러분이 설정 흐름 (setup flows), 온보딩 스크립트 (onboarding scripts), 또는 에이전트 자동화 (agent automations)를 구축하고 있다면, 이 차이는 데모에서 보여주는 것보다 훨씬 더 중요합니다.