Windows 환경에서의 앱이나 프로그램을 설치하는 방식은 일반적으로 GUI 기반으로 된 설치 마법사를 사용하고 있는데요. 이러한 방식은 프로그램 설치가 익숙 하지 않은 사용자들에게는 직관적이지만, 반복적인 설치 과정과 환경 구성의 비일관성이라는 불편함이 존재합니다. 특히 개발 환경 구축이나 자동화 중심의 작업 흐름에서는 동일한 설정을 여러 번 재현해야 하는 상황이 빈번하게 발생하며, 이 과정에서 시간 소모와 오류 가능성이 증가합니다.
이러한 배경에서 명령줄 기반 패키지 관리 도구를 사용하면 이런 불편함을 개선할 수 있습니다. 그 중에서도 Scoop은 Windows 환경에서 사용자 권한 범위 내 설치, 명확한 디렉토리 구조, 그리고 비교적 단순한 동작 방식을 통해 기존 설치 방식의 단점을 보완하는 도구라고 할 수 있습니다.
그래서 이번 글에서는 Scoop의 기본적인 개념과 동작 방식, 그리고 실제 사용 흐름을 중심으로 Windows 환경에서의 패키지 관리 방법을 정리합니다.
Scoop은 Windows에서 사용자 영역 기반으로 소프트웨어를 설치하고 관리할 수 있는 명령줄 패키지 관리 도구로, 시스템을 깔끔하게 유지하면서 일관된 환경 구성이 가능합니다. 명령어 한 줄로 설치, 업데이트, 버전 관리까지 처리할 수 있어 개발 환경 구축과 자동화 작업에 효율적입니다.
튜토리얼 환경: 윈도우 11 Pro (빌드: 26200.8039)
기본 개념
Scoop을 처음 사용하기 전에 알아두면 이해하는 데 도움이 되는 기본적인 개념들을 먼저 정리합니다. 이 구조를 먼저 파악해두면 설치, 업데이트, 오류 해결 시 어디서 무엇이 일어나는지 직관적으로 파악할 수 있습니다.
디렉토리 구조
Scoop은 모든 데이터를 %USERPROFILE%\scoop 하위에 일관된 구조로 관리합니다.
| 경로 | 역할 |
|---|---|
scoop\apps\ | 설치된 앱이 버전별로 저장되는 위치 |
scoop\apps\앱이름\current\ | 현재 버전을 가리키는 심볼릭 링크 |
scoop\shims\ | 앱 실행을 위한 링크 파일 모음 |
scoop\buckets\ | 등록된 버킷(저장소) 목록 |
scoop\persist\ | 앱 설정 및 사용자 데이터 보존 영역 |
scoop\cache\ | 다운로드된 설치 파일 임시 저장소 |
버킷 (Bucket)
버킷은 Scoop의 패키지 저장소입니다. 설치 가능한 앱 목록과 설치 방법이 정의된 JSON 기반 manifest 파일들의 모음이며, 일반적으로 Git 저장소 형태로 관리됩니다. Scoop은 패키지를 설치할 때 이 버킷에 포함된 manifest를 기준으로 다운로드 주소, 버전 정보, 체크섬, 설치 절차를 확인합니다.
- 기본 제공되는
main버킷은 Scoop 설치 직후 바로 사용할 수 있는 기본 원본 저장소이며,scoop install 앱이름실행 시 우선적으로 참조됩니다. main버킷은 명령줄 도구와 개발 환경 관련 패키지 비중이 높은 편이지만, 단순히 개발 도구만 포함하는 저장소로 한정해서 이해할 필요는 없습니다.extras버킷은 기본 버킷에 포함되지 않는 다양한 패키지를 확장하는 용도로 사용되며, GUI 앱을 포함한 더 넓은 범위의 프로그램을 다룰 때 자주 추가됩니다.- Scoop은 버킷을 Git 저장소처럼 관리하므로 패키지 목록의 변경 이력 추적, 동기화, 사용자 정의 버킷 추가가 비교적 명확합니다.
scoop update실행 시 설치된 앱의 최신 정보 확인과 함께 Scoop 본체 및 등록된 버킷 정보도 함께 갱신될 수 있으므로, 패키지 검색 결과와 설치 가능한 버전 정보가 최신 상태로 유지됩니다.
shim
shim은 앱 설치 시 scoop\shims\ 경로에 자동 생성되는 명령줄 실행용 바로가기 파일입니다. Scoop은 실제 실행 파일이 버전별 디렉토리 내부의 깊은 경로에 있더라도, 사용자가 긴 전체 경로를 직접 입력하지 않도록 shim을 만들어 터미널에서 앱 이름만으로 실행할 수 있게 합니다.
scoop\shims\경로는 설치 과정에서 PATH에 포함되므로, PowerShell이나 CMD 같은 Shell에서 명령어를 바로 호출할 수 있습니다. Shell과 터미널에 대해 더 알아보기- shim은 실제 프로그램 본체가 아니라 실행을 중계하는 진입점에 가깝기 때문에, 앱이 업데이트되어 실제 파일 위치가 바뀌어도 사용자는 동일한 명령 이름을 계속 사용할 수 있습니다.
- 이 구조 덕분에 버전별 설치 디렉터리와 실행 경로가 분리되어 관리되며, 환경 재현성과 유지보수 측면에서 유리합니다.
- 앱 제거 시 해당 shim도 함께 정리되므로 더 이상 존재하지 않는 실행 경로가 남을 가능성을 줄일 수 있습니다.
- 명령이 인식되지 않거나 실행 연결이 꼬인 경우에는
scoop reset 앱이름으로 shim, 바로가기, 관련 환경 구성을 다시 생성할 수 있습니다.
manifest
manifest는 각 앱의 설치 정보를 담은 JSON 파일입니다. 다운로드 URL, 버전, 체크섬, 설치 스크립트, 의존성 등의 정보가 포함되며, 버킷 저장소에서 패키지 정의의 기준 역할을 합니다.
- Scoop은 manifest에 정의된 정보를 기반으로 패키지를 다운로드하고 설치를 수행하며, 설치 과정에서 지정된 체크섬을 통해 파일 무결성을 검증합니다.
- manifest에는
url,hash,bin과 같은 핵심 필드가 포함되며, 이를 통해 실행 파일 위치, 실행 명령 연결, 설치 후 동작이 자동으로 구성됩니다. - manifest 자체는 버킷 업데이트에 따라 변경될 수 있으므로, 동일한 명령을 실행하더라도 시점에 따라 설치되는 버전이나 세부 동작이 달라질 수 있습니다.
- 이러한 구조로 인해 Scoop은 선언 기반 설치 방식을 따르며, 동일한 manifest를 사용하는 한 설치 과정의 재현성과 예측 가능성을 유지할 수 있습니다.
- 직접 manifest를 작성해 별도 버킷으로 관리하면 사내 도구나 사용자 정의 패키지도 동일한 방식으로 배포하고 버전 관리할 수 있습니다.
특징
Scoop이 어떤 방식으로 기존 Windows 설치 환경을 개선하는지 이해하는 것이 중요합니다. Scoop은 Windows 사용자 및 개발자에게 최적화된 여러 특징을 가지고 있습니다. 이 도구는 다음 과 같이 단순한 설치 편의성을 넘어서, 설치 구조와 실행 방식 자체를 간소화하여 시스템 관리 방식에 변화를 가져옵니다.
참고: 공식 홈페이지인 https://scoop.sh 에서도 이러한 설계 철학과 사용 방식을 명확하게 설명하고 있으므로, 전체 개념을 이해하려면 참고하는 것이 도움이 됩니다.
장점
Scoop이 제공하는 장점은 단순한 편의성을 넘어서, 시스템 관리의 일관성과 예측 가능성을 높이는 데 있습니다.
- 관리자 권한(UAC) 팝업 없이 대부분의 앱 설치 가능: 일반 사용자 권한 범위 내에서 동작하기 때문에 보안 경고를 최소화하면서도 설치가 가능합니다. 이는 반복적인 설치 작업이나 자동화 환경에서 특히 유리하며, 관리자 권한 의존으로 인한 실행 중단을 방지합니다.
- 앱 설치 경로가
C:\Users사용자\scoop으로 고정되어 관리가 용이합니다. 설치 위치가 일관되기 때문에 파일 추적, 백업, 삭제가 명확해집니다. 또한 여러 프로그램이 시스템 디렉토리에 분산되지 않아 환경 오염을 방지할 수 있습니다. - 심볼릭 링크를 활용하여 앱 버전 업데이트 시 설정 유지가 가능합니다. 실제 실행 파일은 버전별 디렉토리에 저장되고, current 링크만 최신 버전을 가리키도록 변경됩니다. 이 구조는 업데이트 시 기존 설정을 유지하면서도 이전 버전으로의 롤백을 가능하게 합니다.
- 불필요한 GUI 설치 마법사에서의 입력 과정이 불필요하고, 명령어 기반으로 단순화되어 반복 작업등에 적합합니다. 이는 스크립트 자동화, 서버 환경 구성, 개발 환경 재현 시 일관된 결과를 얻을 수 있습니다. 패키지관리자를 사용하는 가장 큰 이유 중 하나라고 볼 수 있습니다.
단점
Scoop의 구조는 명확하지만, 사용 환경에 따라 고려해야 할 제한 요소도 존재합니다.
- 명령줄 인터페이스(CLI)에 익숙하지 않은 사용자에게는 진입 장벽 존재: 모든 작업이 명령어 기반으로 이루어지기 때문에 초기에는 사용법 학습이 필요합니다. 특히 그래픽 사용자 인터페이스(GUI) 중심 사용자에게는 설치 및 관리 과정이 직관적이지 않을 수 있습니다.
- 공식 버킷(Main) 외의 앱을 설치하려면 별도의 버킷 추가 과정 필요: 기본 저장소 외의 패키지를 사용하려면 Git 기반 버킷을 추가해야 합니다. 이는 확장성을 제공하지만 그로 인해 저장소 신뢰성 확인과 관리 부담이 추가될 수 있습니다.
대안 비교
Scoop은 다른 도구들과 확실한 차별점을 가집니다. Windows 환경에서 사용되는 대표적인 패키지 관리 도구들은 각각 공식 문서에서 제시하는 목적과 설계 철학이 명확하며, 이에 따라 설치 방식과 시스템 영향 범위가 다르게 나타납니다. 이를 간단하게 비교해 봅니다.
마이크로소프트 공식 도구이나 설치 경로 제어가 어렵고 권한 팝업이 자주 발생합니다. Winget 더 알아보기
- Microsoft 공식 패키지 관리자(
Windows Package Manager)로 Windows 생태계에 통합되어 제공됩니다. - 공식 저장소(community repository)를 기반으로 검증된 패키지를 제공하며 신뢰성이 높습니다.
- 기본적으로 시스템 전역 설치를 지향하며, 일부 패키지는 관리자 권한이 필요합니다.
- 설치 경로 및 세부 옵션 제어가 제한적이기 때문에 동일한 개발 환경을 반복 구성하는 데에는 유연성이 낮은 편입니다.
가장 방대한 패키지를 보유했으나 설치 과정이 무겁고 상용 버전 유도가 있어 사용자들이 이탈하는 편이며, 필자의 경우도 최근 사용 빈도가 줄고 있습니다. Chocolatey 더 알아보기
- Chocolatey 공식 문서 기준으로 Windows용 패키지 자동화 도구로 설계되었으며, 기업 환경까지 고려한 기능을 제공합니다.
- NuGet 기반 저장소를 활용하여 매우 방대한 패키지 수를 지원합니다.
- 설치 시 기존 MSI, EXE 설치 방식을 호출하는 구조이므로 시스템 변경 범위가 넓고 관리자 권한이 요구됩니다.
- 조직 단위 관리, 중앙 통제 기능 등은 상용 버전인 Chocolatey for Business에 포함되어 있어 사용 목적에 따라 비용 요소가 발생할 수 있습니다.
개발 도구와 휴대용(Portable) 앱 관리에 가장 특화되어 있으며 시스템이 깔끔해, 개인적으로 cli용 도구 들은 대붑분 Scoop를 사용합니다.
- 공식 GitHub 문서 기준으로 명령줄 설치 프로그램(Command-line installer for Windows)으로 정의되며, 사용자 영역 기반 설치를 핵심 철학으로 합니다.
- 모든 애플리케이션을 사용자 홈 디렉토리(
~/scoop)에 설치하여 시스템 전역 변경을 최소화합니다. - 심볼릭 링크를 통해 실행 경로를 구성하고, 버전별 디렉토리를 분리하여 관리합니다.
- Portable 중심 설계로 레지스트리 사용을 최소화하며, 개발 환경 재현성과 자동화에 최적화되어 있습니다. Windows 레지스트리 더 알아보기
설치
Scoop을 사용하기 위해서는 기본적인 실행 환경을 구성하는 과정이 필요합니다. 이 단계에서는 보안 정책 설정과 설치 스크립트 실행을 통해 최소한의 준비만으로 패키지 관리 환경을 구축합니다.
PowerShell 실행 정책 변경
먼저 PowerShell을 실행한 뒤 외부 스크립트 실행 정책을 사용자 범위에서 조정합니다.
Windows는 기본적으로 외부 스크립트 실행을 제한하고 있으므로, 우선 다음 명령을 실행해 사용자 범위에서 실행 정책을 완화해야 합니다. 만약, 위 내용이 이미 적용이 된 경우 별도의 출력 없이 빈 프롬프트를 반환합니다.
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
옵션은 로컬에서 작성한 스크립트는 허용하고 외부 스크립트는 신뢰된 서명이 있는 경우에만 실행하도록 제한하여 보안을 유지합니다.
- Scope를
CurrentUser로 설정함으로써 현재 사용자 계정에만 적용되며 시스템 전체 정책에는 영향을 주지 않습니다. - 보안과 사용 편의성 간의 균형을 고려한 설정으로, 일반적인 개발 환경에서 널리 사용됩니다.
Scoop 핵심 바이너리 설치
설치 명령어를 입력하면 자동으로 Scoop 환경이 구축됩니다. 이 과정에서는 설치 스크립트를 다운로드하고 실행하여 기본 디렉토리 구조와 환경 변수PATH를 설정합니다.
irm은 Invoke-RestMethod의 별칭이며 iex는 Invoke-Expression의 별칭입니다. 아래 명령은 설치 스크립트를 내려받아 즉시 실행하라는 의미입니다.
irm get.scoop.sh | iex
설치가 완료되면 기본 경로(~/scoop)가 생성되고, shim 디렉토리가 PATH에 자동 등록됩니다. 별도의 재부팅 없이 즉시 scoop 명령어를 통해 앱을 설치하거나 사용할 수 있으며, 이후 모든 패키지는 사용자 디렉토리에 설치됩니다.
사용법
설치가 완료되면 기본적인 명령어 흐름을 이해하는 것이 중요합니다. Scoop은 검색, 설치, 업데이트까지의 과정을 일관된 명령어 체계로 처리하도록 설계되어 있으며, 비교적 단순하고 직관적인 구조를 가지고 있어 사용이 어렵지는 않습니다.
프로그램 검색 및 설치
Scoop은 기본적으로 패키지를 검색하고 설치하기 위한 도구인데요. 그래서 필요한 프로그램을 빠르게 찾고 동일한 방식으로 간단하게 설치할 수 있다는 점이 핵심이라고 할 수 있습니다.
아래 명령으로 현재 등록된 버킷 내에서 해당 키워드를 포함하는 패키지를 검색합니다. 결과에는 패키지 이름, 간단한 설명 등이 포함되어 설치 가능 여부를 빠르게 판단할 수 있습니다.
scoop search sudo
scoop install sudo
앱 업데이트 및 정리
설치된 패키지를 최신 상태로 유지하고 불필요한 파일을 제거하는 과정입니다. 장기적인 환경 관리에서 매우 중요한 작업입니다.
아래 update * 명령어로 모든 패키지를 검사하여 새 버전을 내려받습니다. 이 명령으로 각 패키지의 최신 버전을 확인하고 필요한 경우 자동으로 다운로드 및 교체를 수행합니다.
참고: 본문에서는 모든 설치된 앱이 최신 버전이며 불필요한 파일 정리까지 완료된 정상 상태이기에 위와 같이 출력되었습니다. 일반적으로는 업데이트가 필요한 앱 목록이 표시되거나 최신 상태가 아니라는 메시지가 출력됩니다.
scoop update *
이후 cleanup 명령을 통해 차지하고 있는 이전 버전의 잔해를 제거합니다. 이전 버전 디렉토리를 삭제하여 디스크 사용량을 최적화합니다. 본 설명의 두 명령을 함께 사용하면 시스템을 항상 최신 상태로 유지하면서도 불필요한 파일 누적을 방지할 수 있습니다.
scoop cleanup *
기타 명령어
기본적인 설치 및 업데이트 외에도 환경을 관리하기 위해 자주 사용하는 명령어들입니다. 아래 명령어들은 설치된 패키지 상태를 확인하거나 정리할 때 활용됩니다.
다음과 같이 명령하면 현재 사용자 환경에 설치된 모든 패키지 목록을 출력합니다. 여기서 패키지 이름과 함께 설치된 버전 정보가 표시되어 전체 환경 상태를 빠르게 파악할 수 있습니다. 환경 백업이나 동일한 시스템 구성 시 기준 데이터로 활용하기에 적합합니다.
scoop list
아래 info 명령으로 특정 패키지의 상세 정보를 확인할 수 있습니다. 여기서 설치된 버전, 최신 버전 여부, 설치 경로, 의존성 정보를 포함합니다. 문제가 발생했을 때 실제 파일 위치를 추적하거나 설정 경로를 확인하는 데 유용합니다.
scoop info 패키지명
다음 명령으로 지정한 패키지를 사용자 디렉토리에서 제거합니다. 실행을 위한 shim 링크도 함께 삭제되어 PATH 환경이 자동으로 정리됩니다. persist 구조로 유지된 설정 데이터는 일부 남을 수 있으므로 필요 시 별도 정리가 필요합니다.
scoop uninstall 패키지명
persist 구조는 Scoop에서 앱의 실행 파일과 사용자 설정 및 데이터를 분리하여 관리함으로써, 업데이트 시에도 기존 환경을 그대로 유지할 수 있도록 설계된 저장 방식입니다.
- 앱은
scoop/apps/앱이름/버전형태로 버전별로 분리 저장되며, 실제 실행은current심볼릭 링크를 통해 항상 최신 버전을 가리키도록 구성됩니다. - 설정 파일과 사용자 데이터는
scoop/persist/앱이름에 별도로 저장되고 실행 경로와 연결되므로, 버전 교체 과정에서도 데이터가 영향을 받지 않습니다. - 업데이트 시에는 실행 파일만 새로운 버전으로 교체되고 persist 영역은 유지되기 때문에 설정 초기화 없이 동일한 작업 환경을 지속적으로 사용할 수 있으며, 필요 시 특정 버전으로 롤백하거나 persist 폴더만 별도로 백업하는 것도 가능합니다.
FAQ
대부분의 앱은 scoop\apps앱이름\current 경로를 통해 실행되지만, 실제 설정 파일과 사용자 데이터는 scoop\persist 디렉토리에 별도로 저장되고 심볼릭 링크로 연결됩니다.
이 구조는 실행 파일과 데이터를 분리하여 관리하기 위한 것으로, 앱 업데이트 시 실행 파일만 교체되고 설정 데이터는 그대로 유지됩니다. 따라서 프로그램을 재설치하거나 버전이 변경되더라도 기존 환경과 설정을 그대로 이어서 사용할 수 있으며, 필요 시 persist 폴더만 별도로 백업하거나 복원하는 것도 가능합니다.
설치는 가능하지만 이를 권장하지 않습니다. Scoop은 사용자 계정 기반 설치를 전제로 설계되었기 때문에 관리자 권한으로 실행할 경우 파일 권한 충돌이나 환경 변수PATH 중복 등록 등의 문제가 발생할 수 있습니다.
특히 일반 사용자 환경과 관리자 환경 간의 경로 차이로 인해 동일한 명령이 서로 다른 결과를 초래할 수 있으므로, 일관된 환경 관리를 위해서는 반드시 일반 PowerShell 세션에서 설치 및 관리를 수행하는 것이 바람직합니다. Windows PowerShell 과 PowerShell에 대해 더 알아보기
Scoop은 특정 패키지의 업데이트를 제한하는 기능을 제공하며, 이를 통해 안정성이 중요한 환경에서 버전 고정을 유지할 수 있습니다.
아래 명령어를 사용하면 전체 업데이트(scoop update *) 실행 시 해당 패키지는 제외되며, 현재 설치된 버전이 유지됩니다. 이후 업데이트를 다시 허용하려면 unhold 명령을 사용하여 상태를 해제할 수 있습니다.
scoop hold 앱이름
이 기능은 개발 환경에서 특정 버전에 의존하는 도구를 사용할 때 유용하며, 예기치 않은 업데이트로 인한 오류를 방지하는 데 도움을 줍니다.
네, 설치 전 환경 변수를 먼저 선언하면 기본 경로인 %USERPROFILE%\scoop 대신 원하는 경로에 설치할 수 있습니다. 주로 시스템 드라이브 용량이 부족하거나 데이터 드라이브를 별도로 관리하는 경우에 활용합니다.
$env:SCOOP='D:\Scoop'
이제 아래 명령으로 환경 변수 선언 후 설치 스크립트를 실행합니다.
irm get.scoop.sh | iex
사내 네트워크나 제한된 환경에서 Scoop을 사용하는 경우 프록시 설정이 필요할 수 있습니다. 아래 명령으로 프록시 주소를 등록하면 이후 모든 패키지 다운로드에 해당 설정이 적용됩니다.
scoop config proxy http://proxy.example.com:8080
반대로 해제를 하고 싶은 경우 아래 명령을 사용합니다.
scoop config rm proxy
현재 설치된 패키지 목록을 JSON 파일로 내보낼 수 있습니다. 이렇게 하면 개발 환경을 여러 기기에서 일관되게 유지할 수 있어 편리합니다.
scoop export > scoop-backup.json
새 PC로 파일을 옮긴 뒤 아래 명령으로 동일한 환경을 복원합니다.
scoop import scoop-backup.json
앱이 정상 동작하지 않거나 설치 파일이 손상된 경우에 활용합니다. 기존 설치를 제거하고 동일 버전을 다시 설치하므로 설정 초기화 없이 실행 환경만 복구됩니다.
scoop reinstall 앱이름
shim은 Scoop이 생성하는 실행 파일 링크입니다. 특정 앱의 명령어가 인식되지 않거나 실행이 안 될 때 아래 명령으로 해당 앱의 shim을 재생성할 수 있습니다.
scoop reset 앱이름
모든 앱의 shim을 한 번에 재생성하려면 아래 명령을 사용합니다.
scoop reset *