오픈소스 on To the Moon

직접 만든 무료 압축 프로그램 ArcBox를 공개합니다

Sat, 12 Sep 2026 13:00:00 +0900

몇 년째 잘 쓰던 무료 압축 프로그램이 있었다. 어느 날부터 압축을 풀 때마다 광고가 뜨기 시작했다.

오늘따라 이게 유독 귀찮고 걸리적거리게 느껴졌다. 유료판을 사면 광고가 없어지는 건 알지만, 압축 푸는 데 돈을 내자니 그것도 내키지 않았다.

요즘 AI가 워낙 뛰어나니, 그냥 한번 만들어보기로 했다.

ArcBox

광고가 전혀 없는 무료 압축 프로그램이다. Windows용이고, C#/WPF와 .NET 10으로 만들었다.

https://github.com/junstellar/ArcBox-free-zip-archiver

광고 없음
번들 설치 없음 (다른 프로그램 끼워팔기 안 함)
결제 유도 없음, 기능 제한 없음
소스 전체 공개 (Apache-2.0)

쓰고 싶은 분은 그냥 가져다 쓰시면 된다. 출처 표시만 지키면 회사에서 쓰든 고쳐서 쓰든 상관없다.

어떻게 생겼나

탐색기와 비슷하게 생겼다. 왼쪽에 폴더 트리, 가운데에 파일 목록, 오른쪽에 미리보기가 있다. 목록에는 원래 크기와 압축된 크기, 압축률이 같이 나온다.

위쪽 버튼들이 하는 일은 이름 그대로다. 압축 풀기는 위치를 고르는 창을 띄우고, 여기에 풀기는 압축 파일이 있는 폴더에 바로 푼다. 파일이 여러 개면 압축 파일 이름으로 폴더를 하나 만들어 그 안에 푸는 것이 기본이라, 압축을 풀었더니 바탕화면에 파일 수십 개가 쏟아지는 일은 없다.

테스트는 압축 파일이 깨지지 않았는지 확인하고, 악성코드 검사는 풀지 않고 내용만 백신에 넘겨 본다. 창에 파일을 끌어다 놓으면 기존 압축 파일에 그대로 추가된다.

아래쪽 상태 줄의 파일 이름 인코딩을 바꾸면 목록이 즉시 다시 그려진다. 오래된 압축 파일에서 이름이 깨져 보일 때 쓴다.

압축할 때

압축할 파일을 골라 오른쪽 클릭하면 나오는 창이다. 형식과 압축 수준을 고르고, 필요하면 암호를 건다. 기본이 AES-256이고, 오래된 프로그램과 주고받아야 할 때만 구형 ZipCrypto를 쓰면 된다. 7z은 파일 이름까지 암호화할 수 있다.

멀티코어는 따로 고를 것 없이 항상 전체 코어를 쓴다. 위 화면에서는 16개다.

고속 압축은 jpg·mp4·zip처럼 이미 압축된 파일을 다시 누르지 않고 그냥 담는 기능이다. 눌러봐야 크기는 그대로인데 시간만 걸리기 때문이다. 기본으로 켜져 있고, 확장자 목록은 설정에서 고칠 수 있다.

뭐가 되나

	압축	해제
ZIP (AES-256, ZIP64, 파일명 인코딩 자동 감지)	✔	✔
7z (LZMA2, 솔리드, 헤더 암호화, 분할 볼륨)	✔	✔
TAR, TAR.GZ, TAR.BZ2, TAR.XZ, TAR.ZST	✔	✔
GZ, BZ2, XZ, ZST	✔	✔
RAR, CAB, ISO, WIM, ARJ, LZH, CPIO, RPM, DEB, DMG, VHD, MSI 등	–	✔

압축 20여 종을 풀고, 주요 포맷은 압축도 된다.

속도는 신경 써서 만들었다

압축 프로그램에서 제일 중요한 건 결국 속도라고 생각해서 여기에 시간을 많이 썼다.

zip 압축은 파일을 1 MB 블록으로 잘라 모든 CPU 코어에서 동시에 압축한다. 보통 압축 프로그램은 파일 여러 개를 동시에 처리할 뿐, 큰 파일 하나는 한 코어로만 압축한다. 그래서 200 MB짜리 파일 몇 개를 압축하면 코어가 남아돌아도 느리다. ArcBox는 파일 하나를 블록으로 쪼개 전 코어에 뿌린다. (pigz라는 리눅스 도구가 쓰는 방식이다.)

푸는 것도 병렬로 한다. ZIP은 워커 스레드가 항목을 나눠 동시에 풀고, 7z 같은 건 압축 해제와 디스크 쓰기를 별도 스레드로 분리했다.

측정 결과

말로만 빠르다고 하면 의미가 없으니 재봤다. 쓰던 그 프로그램과 같은 조건에서 나란히 돌린 결과다.

데이터 8,004개 파일, 878 MiB. 텍스트 파일 8,000개에 200 MB짜리 이진 파일 4개를 섞었다. 작은 파일만 쓰면 파일 하나당 드는 비용만 보이고, 큰 파일만 쓰면 순수 처리량만 보여서 둘 다 넣었다.

방법 예열 1회를 먼저 돌리고 버린 뒤, 3회 측정해서 중앙값을 썼다. 푼 결과는 파일 수와 총 바이트를 원본과 대조해서 덜 풀고 빨리 끝난 경우를 걸렀다.

	ArcBox	반디집
ZIP 압축	1.98초	3.88초
ZIP 해제 — ArcBox가 만든 파일	3.69초	4.62초
ZIP 해제 — 반디집이 만든 파일	3.63초	4.40초
7z 해제	4.24초	5.03초

압축 결과 크기는 619 MB 대 619.8 MB로 거의 같다. 속도를 얻으려고 압축률을 버린 게 아니라는 뜻이다.

세 번째 줄이 개인적으로는 제일 마음에 든다. 자기가 만든 파일을 자기가 잘 푸는 건 자랑이 아니라서, 상대가 만든 zip을 양쪽이 각각 푸는 항목을 따로 넣었다. 남의 파일을 풀어도 결과는 같았다.

악성코드 검사 설정별로도 따로 쟀다.

검사 설정	ZIP 해제	7z 해제
위험 형식만 (기본값)	3.69초	4.24초
검사 끔	3.74초	4.15초
모든 파일 검사	5.32초	6.16초

기본값과 검사를 끈 것의 차이가 거의 없다. 위험한 확장자만 골라 앞부분만 보기 때문이다. 모든 파일을 검사하면 느려지지만, 그건 선택하는 사람만 감수하면 된다.

밝혀둘 것

측정 환경 Intel Xeon 6517P (16코어 32스레드), 64 GB RAM, Windows 11. 코어가 적은 PC에서는 병렬화 이득이 줄어든다. 노트북에서 이 차이가 그대로 나오진 않을 것이다.
비교 대상의 에디션을 결과에 기록해두지 않았다. 무료판은 압축 스레드가 16개로 제한되는데 측정 환경이 32스레드였으니, 압축 항목은 내 쪽에 유리했을 수 있다. 해제 항목은 이 제한과 무관하다.
파일 캐시가 더운 상태다. 반복 측정이라 원본이 메모리에 올라가 있다. 디스크가 느린 환경이라면 차이가 좁혀진다.
PC 한 대에서 잰 결과다.

측정에 쓴 스크립트와 원본 결과(csv, md)를 저장소 bench/ 폴더에 그대로 넣어뒀다. 명령 두 줄이면 각자 PC에서 다시 잴 수 있다.

그 외 챙긴 것들

악성코드 검사를 해준다. Windows에 설치된 백신(Defender 등)을 그대로 불러다가, 압축을 풀기 전에 내용을 검사하고 걸리면 저장하지 않는다. 기본은 exe·dll·스크립트·매크로 문서 같은 위험 형식만 검사해서 체감 속도 저하가 거의 없다. 설정에서 끄거나 전체 검사로 바꿀 수 있다.

압축 파일을 다시 안 풀고 수정할 수 있다. ZIP과 7z은 파일 추가·삭제·이름 바꾸기가 된다. 창에 끌어다 놓거나 F2, Delete로 된다.

이미 압축된 파일은 다시 안 누른다. jpg·mp4·zip·docx처럼 이미 압축된 파일은 저장만 해서 시간을 아낀다. 확장자 목록은 설정에서 고칠 수 있다.

명령줄 도구도 같이 들어 있다.

1
2
3
4


arcboxc a photos.zip D:\photos # 압축
arcboxc x download.zip -o D:\out # 해제
arcboxc a backup.7z D:\docs -p secret # 암호 걸어서
arcboxc scan download.zip # 풀지 않고 백신 검사

Windows 11 우클릭 메뉴에 들어간다. “추가 옵션 표시"를 거치지 않고 맨 위 메뉴에 바로 뜬다. 설치할 때 체크하면 되고, 원하지 않으면 빼도 된다.

받는 곳

다운로드 — https://github.com/junstellar/ArcBox-free-zip-archiver/releases/latest

설치 파일(ArcBox-0.1.0-setup.exe) 하나만 받아서 실행하면 된다. 소스는 저장소에 있다. .NET 같은 걸 따로 깔 필요 없고, 관리자 권한도 필요 없다. 내 계정 폴더에만 설치된다.

미리 알아두실 것 두 가지.

하나. 유료 코드 서명 인증서가 없어서 처음 실행하면 “Windows에서 PC를 보호했습니다” 경고가 뜬다. 추가 정보 → 실행을 누르면 된다. 인증서가 연간 수십만 원이라 개인 무료 프로젝트에는 부담이 커서 못 샀다. 소스가 전부 공개돼 있으니 미심쩍으면 직접 빌드해서 쓰셔도 된다.

둘. 64비트 Windows 전용이다. Windows 10과 11 모두 된다.

마지막으로

혼자 만든 첫 공개 버전(0.1.0)이라 부족한 데가 있을 것이다. 안 되는 게 있거나 이런 기능이 있으면 좋겠다 싶은 게 있으면 GitHub 이슈로 남겨주시면 고맙겠다.

암호 관리자, 손상된 압축 파일 복구, ALZ·EGG 해제는 아직 안 된다. 필요하다는 분이 있으면 붙여볼 생각이다.

광고 없는 압축 프로그램이 필요하셨던 분들께 도움이 되면 좋겠다.

게이밍 노트북으로 나만의 LLM 돌리기 — llama.cpp로 완전 무료·오프라인 AI 만들기

Mon, 06 Jul 2026 20:45:00 +0900

요즘 클로드나 챗GPT 안 쓰는 사람이 없죠. 그런데 이걸 인터넷도 없이, 요금도 없이, 내 노트북에서 직접 돌릴 수 있다면 어떨까요? “그건 서버실에 GPU 잔뜩 있어야 하는 거 아냐?” 싶은데, 결론부터 말하면 집에 있는 게이밍 노트북 한 대로, 돈 한 푼 안 들이고 됩니다. 지난번엔 ComfyUI로 ‘그림 그리는 로컬 서버’를 만들었는데, 이번엔 llama.cpp로 **‘말하고 글 쓰는 LLM’**을 내 GPU에 올려본 실전 기록입니다.

왜 굳이 로컬로 돌릴까요?

솔직히 똑똑함만 따지면 클라우드 AI가 위입니다. 그런데도 로컬로 돌리는 이유가 분명히 있어요.

가장 큰 건 토큰을 무제한으로 쓸 수 있다는 점입니다. 클라우드 API는 글자(토큰) 하나하나에 요금이 붙죠. 문서 수백 개를 요약하거나, 로그 수만 줄을 분류하거나, 밤새 뭔가를 돌리다 보면 요금이 은근히 무섭게 불어납니다. 로컬은 전기값 빼곤 0원이라, “이거 토큰 아까운데…” 하고 망설일 일이 없어요. 프롬프트를 마음껏 길게 쓰고, 마음에 들 때까지 몇 번이고 다시 돌려도 됩니다.

여기에 이런 것들이 더 붙습니다.

속도 제한이 없어요. API는 분당 요청 수에 제한이 걸려서 대량 작업을 하면 계속 기다려야 하는데, 내 GPU는 온전히 내 것이라 줄 설 일이 없습니다.
데이터가 밖으로 안 나갑니다. 회사 내부 문서, 개인정보, 아직 공개 안 한 코드처럼 외부에 올리기 껄끄러운 걸 다룰 때 이게 결정적이에요. 애초에 전송을 안 하니 유출될 게 없죠.
인터넷이 필요 없습니다. 비행기 안이든, 네트워크가 막힌 폐쇄망이든 그대로 돌아갑니다.
모델이 갑자기 사라지지 않아요. 클라우드 모델은 어느 날 구버전이 종료되곤 하는데, 내 디스크에 받아둔 파일은 영원히 그 버전 그대로입니다.

한마디로 **“똑똑함은 클라우드, 자유도·비용·프라이버시는 로컬”**입니다. 민감한 데이터를 다루거나 같은 작업을 잔뜩 반복할수록 로컬이 빛을 발해요.

로컬 LLM, 뭘로 돌리죠? — 후보 3가지

방법이 몇 가지 있는데, 셋을 비교해보고 골랐습니다.

도구	장점	아쉬운 점
Ollama	명령어 한 줄이면 바로 뜬다, 제일 쉬움	속은 결국 llama.cpp, 세밀한 튜닝엔 한 겹 껴 있음
LM Studio	예쁜 GUI, 클릭 몇 번	프로그램에서 불러다 자동화하기엔 무거움
llama.cpp ← 선택	엔진 그 자체, VRAM 짜내기 최강, OpenAI 호환 API	명령어에 조금 익숙해져야 함

사실 위의 Ollama·LM Studio가 안에서 실제로 돌리는 엔진이 바로 llama.cpp예요. GPU에 레이어를 몇 개나 올릴지까지 손으로 조절할 수 있어서 8GB 노트북에서 짜내기 가장 좋고, 딸려오는 llama-server가 OpenAI랑 똑같은 형식의 API를 열어줘서 어떤 앱이든 깔끔하게 붙습니다.

전체 그림 — 원리는 간단합니다

원리는 ComfyUI 때랑 똑같아요. 무거운 계산은 로컬 GPU가 하고, 바깥 프로그램은 API로 부르기만 합니다.

1
2
3
4
5
6
7


사용자/앱: "이 문단 요약해줘"
 ↓
llama-server (로컬, http://127.0.0.1:8080/v1) ← OpenAI 호환 API
 ↓
GGUF 모델이 RTX 4060에서 토큰을 하나씩 생성
 ↓
스트리밍으로 답변이 흘러나옴

두 단어만 알고 가면 됩니다. llama.cpp는 C/C++로 짠 LLM 추론 엔진이라 GPU가 약해도 모델을 CPU와 GPU에 나눠 올려 돌립니다. GGUF는 llama.cpp 전용 모델 포맷인데, 원본 모델을 양자화해서 용량과 VRAM 사용량을 확 줄여놓은 파일이에요.

내 노트북으로 될까? — 사양부터 확인

일단 될지부터 따져봤습니다. 지난 ComfyUI 글과 같은 HP Victus 16 노트북이에요.

항목	필요 사양 (7~8B 모델)	내 노트북	판정
GPU VRAM	6GB 이상 (Q4 기준)	RTX 4060 Laptop 8GB	통과
RAM	16GB	16GB	통과
디스크	모델당 약 5GB	여유 충분	통과

VRAM 8GB면 7~8B급 모델을 Q4로 양자화했을 때 통째로 GPU에 올라갑니다. 이 구간이 제일 빨라요. 13~14B급부터는 일부를 RAM으로 내려야 해서 속도가 뚝 떨어지고, 30B 이상은 이 노트북엔 좀 욕심입니다.

모델 고르기 — ‘양자화’가 절반입니다

같은 모델이라도 **양자화(quantization)**를 어떻게 하느냐에 따라 용량·속도·품질이 갈립니다. 여기서 첫 삽질을 했어요. “이왕이면 고품질이지” 하고 Q8을 받았다가 VRAM이 부족해서 모델이 반쪽만 GPU에 올라가는 상황을 만났거든요. 결국 8GB의 현실적인 정답은 **Q4_K_M**이었습니다.

양자화	7B 모델 용량	특징
Q8_0	~7.5GB	원본에 제일 가깝지만 8GB엔 버겁다
Q4_K_M	~4.5GB	속도·품질 균형, 로컬의 사실상 표준
Q3_K_M	~3.5GB	더 가벼운 대신 품질 저하가 슬슬 느껴진다

모델은 7~8B급 instruct 계열(예: Qwen2.5-7B-Instruct, Llama-3.1-8B-Instruct 등)이면 무난합니다. GGUF 파일은 보통 Hugging Face의 bartowski 같은 배포처에서 양자화별로 받을 수 있어요.

설치하기 (Windows 11 기준)

1. llama.cpp 바이너리 받기

소스를 직접 빌드해도 되지만, 제일 빠른 길은 미리 빌드된 CUDA 바이너리를 받는 겁니다. GitHub 릴리스에서 llama-bxxxx-bin-win-cuda-x64.zip 같은 파일을 받아 C:\llama에 풀면 끝이에요.

2. GGUF 모델 다운로드

1
2
3


# 7B급 Q4_K_M 모델 (~4.5GB) → C:\llama\models\ 에 저장
curl.exe -L -o C:\llama\models\model-q4_k_m.gguf ^
 "https://huggingface.co/bartowski/Qwen2.5-7B-Instruct-GGUF/resolve/main/Qwen2.5-7B-Instruct-Q4_K_M.gguf"

3. 서버 실행

여기서 딱 하나만 기억하면 됩니다. -ngl — GPU에 올릴 레이어 수예요. -ngl 99는 “가능한 만큼 다 GPU에 올려라"라는 뜻이고, 7~8B Q4 모델은 8GB에 통째로 들어갑니다.

1

C:\llama\llama-server.exe -m C:\llama\models\model-q4_k_m.gguf -ngl 99 -c 8192 --port 8080

-ngl 99 : 전 레이어 GPU에 올리기 (VRAM 모자라면 숫자를 낮춰 일부만)
-c 8192 : 컨텍스트 길이 8k 토큰
--port 8080 : 서버 포트

4. 잘 도나 확인

브라우저에서 http://127.0.0.1:8080을 열면 채팅 UI가 바로 뜹니다. GPU를 제대로 쓰는지는 서버 켤 때 로그의 offloaded 29/29 layers to GPU 같은 줄로 확인해요. 저 숫자가 꽉 차 있으면 성공입니다.

흔한 함정 3가지 (미리 알려드려요)

설치 자체는 쉬운데, 딱 이 세 군데서 사람들이 잘 걸립니다.

함정 1 — CPU 빌드를 받아버림. 릴리스에 파일이 여러 개라, 무심코 win-cpu 빌드를 받으면 GPU가 놀고 답이 굼벵이처럼 느립니다. NVIDIA면 반드시 cuda 빌드를 받으세요. (AMD는 vulkan 빌드)
함정 2 — -ngl을 안 줌. 이 옵션을 빼먹으면 모델이 전부 CPU에서 돌아 엄청 느려집니다. “GPU 있는데 왜 이렇게 느리지?” 싶으면 십중팔구 이거예요.
함정 3 — 욕심내서 큰 모델·높은 양자화. 위에서 겪은 그 삽질입니다. VRAM을 넘기면 속도가 확 죽어요. 8GB면 7~8B Q4가 정답입니다.

앱이랑 붙이기 — OpenAI 호환 API

llama-server가 진짜 편한 건, OpenAI랑 똑같은 형식의 API를 열어준다는 점이에요. OpenAI 쓰던 코드에서 주소만 로컬로 바꾸면 그대로 붙습니다.

1
2
3
4
5
6
7
8


from openai import OpenAI
client = OpenAI(base_url="http://127.0.0.1:8080/v1", api_key="local")

resp = client.chat.completions.create(
 model="local",
 messages=[{"role": "user", "content": "안녕, 자기소개 해줘"}],
)
print(resp.choices[0].message.content)

문서 요약, 코드 자동완성, 번역 같은 걸 오프라인·무과금으로 돌리는 나만의 백엔드가 이걸로 완성됩니다.

어느 정도 빠를까요

7~~8B Q4_K_M을 전 레이어 GPU에 올린 기준으로 **초당 40~~60토큰 정도**. 눈으로 따라 읽기 벅찰 만큼 빠릅니다.
첫 응답까지는 모델을 VRAM에 올리는 시간 포함 몇 초.
컨텍스트를 길게(예: 16k) 주면 VRAM이 부족해질 수 있는데, 그땐 -ngl 숫자를 낮춰 일부를 RAM으로 내리면 됩니다. 조금 느려지는 대신 돌아는 가요.

솔직한 결론 — 어디까지 되고, 어디부터 안 되나

됩니다: 공짜로, 인터넷 없이, 내 노트북에서 꽤 쓸 만한 LLM이 돌아갑니다. 요약·번역·분류·코딩 보조 같은 실무엔 7~8B로도 충분해요. 무엇보다 토큰 걱정 없이 마음껏 굴릴 수 있는 게 크죠.
한계: 아무리 좋은 로컬 모델도 최상위 클라우드 모델(클로드 등)만큼 똑똑하진 않습니다. 복잡한 추론이나 긴 코드 설계는 아직 클라우드가 낫습니다.
현실적인 조합: 그래서 저는 민감한 데이터·대량 반복 작업은 로컬, 어려운 문제는 클라우드로 나눠 쓰는 게 제일 낫다고 봐요. 둘은 경쟁이 아니라 역할 분담입니다.

돈 안 들이고 노트북 한 대로 여기까지 된다는 것 자체가, AI 문턱이 얼마나 낮아졌는지 보여주는 것 같습니다. 다음엔 이 로컬 LLM을 클로드 코드 같은 도구에 물려서 완전 오프라인 코딩 도우미로 만들어볼 생각이에요.