elsa in mac

Asahi Linux : M4/M5 지원을 워한 준비....

elsa in mac — Mon, 11 May 2026 21:56:41 +0900

2026년 5월 9일, Asahi Linux의 m1n1 GitHub 저장소에 앞으로의 Apple Silicon 지원 방향을 짐작하게 만드는 흥미로운 PR 하나가 올라왔습니다. 제목은 `pmgr: support M4 Pro/Max / A18 Pro / M5`입니다.

제목에서 알 수 있듯, 이 PR은 Apple Silicon의 새로운 세대에 맞춰 m1n1 내부의 pmgr 처리 방식을 손보는 작업입니다. 내용을 살펴보면, m1n1의 pmgr 코드가 M4 Pro/Max, A18 Pro(Macbook Neo Soc), 그리고 M5 계열에서 쓰이는 장치 트리 형식에 맞게 주소 계산 방식을 확장했다는 것으로 M4 Pro 환경에서 실제 동작이 확인되었다는 점이 특히 눈에 띕니다.

우선, 이 PR의 의미를 제대로 이해하려면 먼저 m1n1이 무엇인지부터 짚어야 합니다.
m1n1은 Apple Silicon Mac에서 Linux를 부팅할 수 있게 도와주는 부트로더입니다. 하지만 단순히 부팅만 대신해 주는 도구라고 보기에는 역할이 훨씬 넓습니다. 개발용 proxy 역할도 수행하고, 경우에 따라서는 얇은 하이퍼바이저처럼 동작하면서 하드웨어 접근을 관찰하는 실험용 도구로도 쓰입니다. 다시 말해 m1n1은 Apple Silicon의 독특한 부팅 구조를 Linux가 이해할 수 있는 방식으로 연결해 주는 통역사 역할을 하는 중간 계층이라고 보면 됩니다.

일반적인 X86 계열의 PC에서는 운영체제가 부팅될 때 하드웨어 구성을 알아내는 것이 그리 어렵지 않습니다. x86 계열 PC에서는 BIOS나 UEFI가 그 역할을 맡고, Linux 커널은 그로부터 필요한 정보를 전달받습니다. 커널은 그 정보를 바탕으로 “아~ 이 기기에는 어떤 장치들이 있구나, 그럼 그 장치들은 이렇게 제어해야겠네~”하는 것들을 파악한 뒤 드라이버를 올립니다. 하지만, Apple Silicon Mac은 사정이 다릅니다. Linux가 곧바로 이해할 수 있는 형태로 공개된 하드웨어 정보가 없기 때문에, 그 정보를 읽어 들여 Linux가 이해할 수 있는 언어로 바꾸어 줄 중간 주체가 필요합니다. Asahi Linux에서 그 역할을 맡는 것이 바로 m1n1입니다.

m1n1은 공식적으로 이름의 의미가 딱 잘라 정의된 적은 없지만, Asahi Linux 초기 문서들을 따라가 보면 그 뿌리가 Nintendo Wii용으로 개발된 mini라는 bare-metal 환경에 닿아 있습니다. Asahi Linux의 프로젝트를 시작한 초기 리더인 Hector Martin은 원래 Wii 관련 하드웨어 연구와 Will에 리눅스를 포팅한 인물인데, 그 과정에서 Wii의 보안 CPU에서 동작하는 작은 실험용 환경인 mini를 만든 바 있습니다. 이 mini를 AArch64와 Apple Silicon 환경에 맞게 옮기고 발전시킨 것이 현재의 m1n1이라고 알려져 있습니다. 실제로 공식 문서에서도 m1n1의 과거가 mini에 있다고 언급했었습니다.

m1n1의 실제 역할을 조금 더 세분화해서 보면 세 가지 층위로 이해할 수 있습니다.
첫 번째는 Bootloader로서의 역할입니다. Apple의 부팅 과정에서 전달되는 ADT(Apple Device Tree)를 읽어 Linux가 이해할 수 있는 FDT(Flattened Device Tree)로 바꾼 뒤 다음 단계로 넘겨줍니다. 이 작업은 Apple의 부팅 체계와 Linux의 부팅 체계를 연결하는 것으로 페쇄적인 Apple H/W를 Linux가 이해할 수 있는 표준적인 환경으로 추상화해주는 역할 입니다. Apple 쪽에서는 Apple 방식의 하드웨어 설명이 있고, Linux 쪽에서는 Linux가 이해하는 하드웨어 설명이 따로 있기 때문에 그 사이를 번역해 주는 다리가 필요한데 m1n1이 바로 그 교두보 역할을 담당합니다.

두 번째는 proxy 기능입니다. 개발용 컴퓨터가 타깃 Mac과 USB로 연결된 상태에서 m1n1을 통해 레지스터를 직접 읽거나 장치를 초기화하고, 커널 이미지를 올리는 식의 원격 조작이 가능합니다. 이 기능은 하드웨어를 실제로 붙잡고 실험해야 하는 개발자에게 매우 중요합니다. 단순히 부팅만 하는 것이 아니라, 부팅 중인 기기 내부를 들여다보고 장치를 하나씩 확인할 수 있게 해 주기 때문입니다. Asahi Linux가 하드웨어 지원을 넓혀 가는 과정에서 이 proxy 기능은 핵심적인 도구입니다.

세 번째는 Hypervisor로서의 성격입니다. m1n1은 아주 얇은 하이퍼바이저처럼 동작하면서 Linux나 macOS가 하드웨어에 접근하는 과정을 관찰할 수 있게 해 줍니다. 여기서 중요한 점은, m1n1이 거대한 가상화 솔루션처럼 복잡하게 움직이는 것이 아니라, 필요한 순간에 하드웨어 접근을 가로채거나 관찰할 수 있을 만큼만 얇게 개입한다는 점입니다. 그래서 Apple Silicon의 동작을 분석하거나 새로운 장치 지원을 준비할 때 매우 유용합니다. 운영체제가 칩과 나누는 대화를 옆에서 지켜보며 분석하는 통역가이자 감시자라고 생각하면 이해하기 쉽습니다.

Mac에 전원이 들어오면 가장 먼저 Apple의 Boot ROM이 실행되고, 이어서 iBoot의 stage 1과 stage 2가 차례로 동작합니다. 이 과정에서 장치 초기화와 부팅 정보 준비가 이루어지고, 본래라면 마지막에는 macOS 커널이 로드됩니다. 그런데 Asahi Linux는 이 흐름 사이에 m1n1을 끼워 넣는 방식을 택합니다. 즉, Apple의 부팅 체인 안에서 m1n1이 먼저 실행되도록 만들고, m1n1이 다음 단계를 받아서 Linux가 이해할 수 있는 형태로 하드웨어 정보를 정리해 주는 것입니다.

m1n1 역시 stage 1과 stage 2의 두 단계로 나뉘어 동작합니다. stage 1은 Apple의 부팅 흐름 안에서 처음 실행되는 진입점 역할을 하고, stage 2는 EFI System Partition에서 이어서 불러오는 단계입니다. 이 두 단계가 함께 하드웨어 초기화와 부팅 준비를 담당합니다. 결과적으로 부팅은 macOS 커널로 이어지지 않고, m1n1이 준비한 뒤 U-Boot와 Linux 커널 쪽으로 진행됩니다. 즉, Asahi Linux는 Apple의 부팅 구조 위에 m1n1을 올려서, macOS 대신 Linux가 시작되도록 만드는 셈입니다. 정리하면 부팅 프로세스는 Boot ROM -> iBoot -> m1n1 stage 1 -> m1n1 stage 2 -> U-Boot -> Linux kernel의 순서로 진행되게 됩니다.

그렇다면 이번 PR의 의미는 무엇일까?
궁극적으로 M4 세대 이후의 Mac에서 Asahi Linux를 안정적으로 구동하려면, m1n1이 단순한 부트로더를 넘어서 우선은 하드웨어 초기화와 분석을 돕는 개발용 계층으로서 정상적으로 동작해야 합니다. 이를 위해서는 먼저, 해당 플랫폼의 장치 트리와 제어 방식을 정확히 파악하는 것이 우선 필요하고, 그 과정에서 m1n1이 해당 하드웨어 위에서 제대로 실행되어야 합니다. 다시 말해, 새 세대 Mac을 분석하고 지원하기 위한 첫 번째 조건은 m1n1이 그 기기에서 제대로 떠야 한다는 점입니다.

이번 PR의 구체적인 성과는 pmgr 코드를 수정하여 device-mode USB가 동작하도록 만든 데 있습니다. 이 말은 개발 컴퓨터가 USB를 통해 타깃 Mac에 연결될 수 있는 상태가 되었다는 뜻이고, 그 결과 m1n1의 proxy 기능을 온전히 사용할 수 있는 단계로 진입했다는 의미로 이해될 수 있습니다. 개발자는 이 경로를 통해 타깃 Mac의 내부 구성을 확인하고, 어떤 레지스터와 제어 경로를 사용해야 하는지 조사할 수 있습니다. PR 코멘트에서 M4 Pro에서 실제 연결과 동작이 확인되었다는 점도 중요합니다. 그리고 제목에 M4 Pro/Max, A18 Pro, M5가 함께 적혀 있다는 점을 보면, 작성자는 이 수정이 해당 계열 전체에 적용될 수 있다고 판단한 것으로 보입니다.

- - - - - - - - - -

결국 이 PR은 단순히 코드 몇 줄을 바꾼 것이 아닙니다. Apple Silicon의 최신 세대에서 m1n1이 다시 한번 발판을 얻었고, 그 위에서 Asahi Linux가 하드웨어를 더 깊이 이해하고 다룰 수 있는 통로가 열린 것입니다. 새 칩이 나올 때마다 부팅 체인과 장치 정보 형식이 조금씩 바뀌는데, 이런 저수준 수정은 그 변화에 맞춰 Linux 생태계가 계속 따라갈 수 있게 만드는 기반 작업입니다. 이번 PR은 바로 그 기반을 새 세대 하드웨어에 맞게 다시 세우게 되었다고 볼 수 있으며, M4 이후의 mac에 Asahi Linux를 포팅할 수 있는 출발선이 마련되었다고 볼 수 있을 것 같습니다.

Fedora Asahi Remix 44 가 공식 릴리스 되었습니다.

elsa in mac — Wed, 29 Apr 2026 18:28:17 +0900

2026년 4월 29일
Fedora Asahi Remix 44 버전이 공식 릴리즈 되었습니다.

지난번 43 릴리즈때와는 달리 이번 44는 매우 빠르게 나왔습니다. 그만큼 그동안의 노력이 빛을 발하는 것 같습니다. ^^

kernel 은 0.19.13-400 이며, fc43에서 fc44로만 변경됩니다.
업그레이드 절차는 공식적인 절차에서 차이가 없기 때문에, 잘 모르시는 사용자 분이시라면, 지난 포스트를 참조하시기 바랍니다.

sudo dnf system-upgrade download --releasever=44

releasever 를 44로 하면 된다는 점만 주의하면 됩니다.

보통 Major version 업그레이드 시에는 사용자의 환경에 따라 다양한 문제가 발생할 수 있습니다. 우선은 44로 업그레이드하기 전에 44 repository를 기준으로 기존에 설치된 CLI, Library 등을 다운로드하여야 하는데, 경우에 따라서는 아직 44 repository에 없거나 버전 미스매칭이 발생하는 경우가 있습니다.

 Problem 1: installed package chromium-142.0.7444.134-1.fc43.aarch64 requires libavformat.so.61()(64bit),
 but none of the providers can be installed

예를 들어, 설치된 chromium 이 구버전의 library를 요구하는데, 당연히 업데이트된 환경에서는 해당 library의 버전이 올라가기 때문에 시스템을 업그레이드하게 되면, 해당 app을 사용할 수 없다고 경고하는 것입니다. 이런 경우는 해당 package를 제거하고, 추후에 fedora 44 버전을 지원하는 app이 등록되면 그때 설치를 다시 해야 합니다.

만일 이런 의존성 관련 문제가 여러 건이고, 반드시 사용해야 하는 것이라면 지금 당장 업그레이드를 하는 것보다는 좀 더 뒤에 시간적 여유를 두고 하는 편이 좋습니다. 또한, Major Upgrade 후 에는 이전 버전으로 Rollback 할 수 있는 공식적인 방법은 없습니다. 즉, fedora 44로 업그레이드를 했다면, fedora 43으로 되돌아가는 공식적인 방법은 존재하지 않는다는 것입니다.

또 다른 예로는 dnf를 통해 공식 repository로 설치하지 않은 CLI도구나 app 등이 업그레이드 후에 실행이 안 되는 경우가 발생할 수 있습니다. 이 또한, 해당 CLI나 app이 업그레이드 이전의 구 버전 Library에 의존하기 때문으로, 이 경우 해당 app을 배포하는 github 나 home page에서 fedora 44를 지원하는 업데이트된 배포판을 다시 설치해야 합니다. 만일 사용자가 집접 소스코드를 받아 빌드한 경우라면, 해당 CLI 도구나 app을 다시 빌드해야 합니다.

시스템 관리 부분이 업그레이드된 경우에는 기존의 설치 profile이 무효화되는 경우도 있는데, 대표적인 것이 WiFi입니다. 업그레이드 이후에, 기존에 login 하고 나면 자동으로 연결되던 WiFi 가 연결이 되지 않을 수도 있는데, 이런 경우에는 기존의 WiFi 정보를 지우고(접속 해제 및 접속 기억 삭제) 다시 접속해야 합니다.

Fedora 44의 GNOME 을 사용하시는 분들이 참고하실 것 중 하나는 Fedora 44에서는 GNOME 버전이 50으로 업데이트되었는데. GNOME 50에서는 File 탐색기에서 더 이상 Google Drive를 사용할 수 없습니다. 구형 libsoup2 라이브러리에 대한 유지보수가 이뤄지지 않은 채 방치되었기 때문에 해당 기능을 삭제하는 것으로 결정되었습니다. 따라서, Google Drive를 계속 사용하려면 web browser를 이용해야 합니다.

- - - - - - - - -

Fedora Asahi Linux 43은 Fedora 43이 릴리즈 되고 나서, 대략 5개월 뒤에 릴리즈 되었기 때문에, 대부분의 라이브러리나 Open Source Project들이 대응을 한 후라 별 문제가 없었지만, 이번 44 버전은 Fedora 44와 거의 동시에 릴리즈 되었습니다. 따라서 앞서 언급한 문제들이 충분히 발생할 수 있기 때문에, Linux를 처음 사용하시거나 아직 익숙지 않은 사용자이고 굳이 현재 잘 사용하고 있으면서 굳이 44로 업그레이드를 할 특별한 이유가 없다면, 업그레이드를 좀 더 뒤로 미루는 것도 한 방법입니다.

Asahi Linux, Linux 7.0 에 대한 진행보고서가 올라 왔습니다.

elsa in mac — Mon, 27 Apr 2026 18:29:47 +0900

어느덧 2026년도 1/3 이 지나고 있는데요,
20206년 4월 26일. Asahi Linux Kernel 7.0에 대한 진행보고서가 공식 블로그에 등록되었습니다. 진행보고서는 현재 릴리즈된 kernel 에 대한 것이 아니며, kernel 7.0 에 어떠한 것들이 추가되거나 검토되고 있는지에 대한 보고서 입니다. 따라서 보고서에서 논의되는 내용들은 진행과정에서 실제 적용이 더 늦쳐 질 수도 있다는 점을 고려해야 합니다.

Asahi Linux는 Fedora Linux를 기반으로 하고 있고, Fedora Linux는 매 6개월의 주기로 Major Update 버전을 릴리즈 합니다. 보통 4월과 10월(넷째 주 화요일)에 릴리즈 되며, 13개월 동안 해당 버전을 지원합니다. 예를 들어 Fedora 43이 공실 릴리즈가 출시되면, 그 보다 두 단계 낮은 Fedora 41의 지원이 종료되는 루틴입니다.

패키지 업데이트는 수시로 등록되며, Kernel 의 경우에도 대략적인 주기는 없습니다. 따라서, Fedora를 사용하는 사용자들은 매 6개월마다 버전을 업데이트하고, 일주일에 한 번 정도만 system 업데이트를 하면 큰 문제없이 가장 최신 버전으로 시스템을 유지 관리할 수 있습니다. Asahi Linux를 처음 사용하시는 분들이라면 참고하시기 바랍니다.

자 그럼, 이번 올라온 Kernel 7.0에 대한 소식 어떤 내용들이 소개되었는지 살펴 보도록 하겠습니다.

첫 번째는 설치 프로그램(Installer) 업데이트 및 자동화에 대해 것 입니다.
Asahi Linux를 mac에 설치하려면, curl | sh 명령을 이용하여 설치를 합니다. 이 명령은 설치에 필요한 python 코드와 m1n1 부트로더, 그리고 복잡한 설치로직이 포함된 거대한 번들을 CDN으로부터 가져옵니다. 과거에는 개발자가 이 설치 패키지를 일일이 수동으로 빌드하고 검증하여 서버에 등록해야 했습니다. 이 과정이 번거롭고 시간이 걸리다 보니, 설치 프로그램이 2024년 6월 버전에 머물러 있는 등 방치되는 문제가 있었습니다. 시스템 라이브러리와 커널은 6.18, 6.19 등으로 계속 최신화되는데, 설치 프로그램 속의 디바이스 트리(Devicetree)는 구형이다 보니, 최신 커널과의 불일치로 부팅 실패등의 부작용이 발생하곤 했습니다. 하지만, 이제 Github Workflow를 통해 자동화가 도입되어, 개발자가 코드만 수정하면 자동화 도구가 Python 코드를 관리하고, m1n1을 빌드하여 최신판을 즉시 서버에 개시합니다. 덕분에 개발자의 수고는 줄어들고, 사용자는 늘 최상의 설치 환경을 제공받을 수 있게 되었다고 설명합니다.

두 번째 섹션은 ALS(조도센서: Ambient Light Sensor)와 그에 필요한 Firmware 관리 방식 변화에 대한 내용입니다.
mac의 광센서는 단순히 화면 밝기를 조절하는데 그치지 않고, 주변 색온도를 감지하여 그에 맞춰 화면의 색감 자체를 맞추는 "True Tone" 기능을 수행하는 기반을 지원합니다. True Tone 기능은 정밀한 측정이 선행되어야 하며, 이를 효율적으로 처리하기 위해 CPU가 아닌 AOP(Always-On Processor)라는 별도의 저전력 Chip이 역할을 분담합니다. 광센서에서 출력되는 row 데이터는 교정 과정 거쳐야만 정확한 값을 얻을 수 있는데, 문제는 이 교정 펌웨어가 저작권 문제로 배포판에 포함될 수 없다는 점입니다. 결국 사용자의 mac 내부에서 바이너리를 직접 추출해야 하는데, 이 과정은 EFI 파티션을 건드리는 등 매우 까다로운 작업이 수반됩니다. Asahi Team은 이를 해결하기 위해 펌웨어 패키지 재빌드(Building vendor firmware package) 기능을 추가했다고 합니다. 결론적으로 사용자가 직접 관련 지식과 기술을 알아야 할 수 있었던 작업을 설치 과정에서 자동으로 처리되도록 했다는 내용입니다.

세 번째 섹션은 유휴상태(Idle) 상태에서의 전력 소모 개선과 관련된 것입니다.
Apple Silicon의 최대 강점인 저전력 설계는 PMP(Power Management Processor)가 핵심적인 역할을 합니다. 그 동안 Pro, Max, Ultra 칩을 탑재한 고사양 mac에서 Asahi Linux를 구동할 경우, 대기 상태(Idle State) 에서 조차 전력이 많이 소모되는 문제가 내제되어 왔었습니다. Apple Silicon SoC에서 전력을 관리하는 두 가지 핵심 장치는 PMGR(Power Manager)와 PMP 인데, PMGR은 SoC의 각 내부 Domain 에 전원을 물리적으로 여닫는 스위치 역활을 수행하며, PMP는 각 하드웨어 블록들로 부터 전원 상태 보고를 받아, 데이터 경로인 Apple Fabric의 전력과 클럭을 조절하는 두뇌 역활을 수행합니다. 개발자 chaos princess는 PMP가 하드웨어 블록들로부터 보고를 받을 수 있도록 드라이버를 개발했고, 그 결과 M1 Macbook Pro 기준으로 0.5W 즉, 유휴 소모전력의 20%를 줄여 배터리 사용시간을 더 늘릴 수 있게 되었다고 합니다. 현재는 검증 단계라 기본 비활성화 상태이지만, 향후 고사양 모델 사용자들이 베터리 타임이 늘어날 것으로 기대됩니다.

다음 네 번째로는 일부 사용자들이 지속적으로 문제를 제기해 온 Bluetooth 오디오 끊김 문제에 대한 것입니다.
WiFi와 Bluetooth가 모두 동일한 2.4GHz 대역을 사용하는 상황이라면 같은 공간에서 서로 간섭을 일으킬 가능성이 큽니다. WiFi를 5GHz 급으로 사용하는 사용자들은 이런 문제를 비켜갈 수 있지만, 동일한 주파수 대역을 사용할 수밖에 없는 상황에서는 피해 갈 수 없는 문제입니다. 이를 근본적으로 해걸할 수 있는 방법은 WiFi 와 Bluetooth를 개별 device가 아닌 통합 Device로 만들고 통합적으로 관리하는 것입니다. 즉, 상황에 따른 서비스 우선순위 방식을 사용하면 해결할 수 있습니다. Bleutooth 특히 Audio와 같이 끊김 없는 서비스를 해야 하는 경우는 이벤트성으로 발생하는 Bluetooth 기기 처리와는 다른 방법을 사용해야 합니다. 애플은 탑재된 Broadcom Chip을 제어하기 위해 독자적인 방식을 사용하는데, 이 또한 비공개이기 때문에, Asahi Linux에서는 macOS를 사용할 때와 동일한 수준의 제어를 할 수 없었습니다. 하지만, 이제 Linux kernel 에 Broadcom 전용 명령어를 추가하여 Bluz 에서 높은 우선 순위를 설정하는 방법으로 오디오 처리에 대한 우선순의를 높힐 수 있도록 명령을 내릴 수 있게 되었고, 끊김없는 Bluetooth Audio를 사용할 수 있게 되었다고 합니다.

다섯 번째 섹션에서는 DCP(Display Control Processor)와 관련된 내용입니다.
모니터에 표시될 화면 구성을 GPU가 하더라도, 이를 실제 모니터에 뿌려주는 최종 단계는 GPU가 아니고 DCP(Display Control Processor)가 담당합니다. GPU는 매 프래임 화면을 구성한 후, 약속된 Format으로 DCP로 보내면 DCP가 특정 포트에 연결된 모니터에 표시를 하게 됩니다. mac, 특히 내장 디스플레이를 갖추고 있는 MacBook이나 iMac 같은 모델은 ProMotion이라는 기능을 제공하는데, 이는 일반적으로는 가변 주사율(VRR, Variable Refresh Rate) 기능과 유사한 apple의 비즈니스 용어 입니다. 물론, 외장 모니터에 대해서도 VRR 기능을 지원할 수는 있는데, 모니터가 Adaptive Sync(Free Sync) 기능을 지원해야 합니다.

리눅스 드라이버를 개발할 때, 디스플레이와 관련된 특정 매개변수를 0으로 설정하는 코드가 있었는데, 당시 개발자들은 이것이 단순히 전원을 켜는 순서(Power Sequence) 중 하나라고 생각했다고 합니다. 그런데, 후에 이 매개변수가 0과 0x3000000 사이에서 값 사이에서 변하는 것을 발견했고, 0x3000000이 16진수 고정 소스점 방식으로 48Hz를 의미하는 것이라는 알게 되면서 이 설정값이 전원 버튼이 아니라 VRR의 최소 주사율을 결정하는 값이었다는 것을 알게 되었다고 합니다. 따라서, 이 값을 조정하면 가변 주사율을 구현할 수 있기는 하나 VESA 표준에서 VRR은 화면의 깜박임이 없이 VRR을 켜고 끌 수 있어야 한다고 규정하고 있는데, Apple의 DCP는 VRR 상태를 바꿀 때마다 반드시 화면을 재설정하는 모드 셋(Modeset)을 해야 하고, 이 때문에 리눅스 표준 API인 KMS를 통해 정식으로 VRR을 실현할 수 없다는 것을 알게 됩니다.

따라서, 현재는 가장 높은 주파수로 고정을 하고 있는 상태이며. 이 문제를 해결하기 위해 논의가 진행 중이라고 합니다. DCP와 관련해서는 GPU와의 통신에서 대역폭 및 에너지 소모 비용을 줄이기 위한 tiling & compressed frame buffering을 사용할 수 있는데, 이 부분도 아직은 완벽하게 구현되어 있지 않은 상태입니다.

여섯 번째 섹션은 Apple Silicon의 독특한 오디오 하드웨어 구조와 이를 리눅스 표준에 맞게 구현하는 것과 관련된 내용입니다.
mac의 내장 스피커는 일반 PC와는 달리 관련된 하드웨어의 최대 성능치를 발휘하도록 처리하고 있는데, 이때 스피커가 과열되어 타버리는 불상사를 방지하기 위해 매우 정교한 시스템이 작동한다고 합니다. 즉, 앱프 칩이 스피커에 흐르는 전압과 잔류의 세기를 실시간으로 측정하여 SoC에 보고하면, 이 데이터를 받아 스피커의 물리적 특성을 바탕으로 스피커 코일의 온도를 계산하고 이를 통해 실시간 출력 제어를 하는 메커니즘입니다. 또한, 여러 개의 앰프를 연동하기 위해 'OR 논리 회로'와 유사한 방식을 사용하는데, 데이터 충돌을 방지하기 위해 대기 앰프의 신호를 낮게 유지하는 'Bus Keeper' 회로가 쓰입니다. Asahi 팀은 이 설정을 제어할 수 있는 새로운 범용 API를 직접 구현했으며, 이는 Kernel 7.1에 정식 포함될 예정이라고 합니다.

일곱 번째 섹션은 mac의 Custom Chip에 대한 성능 향상과 관련된 내용입니다.
Chip Vender들은 USB-C, 스피커, 헤드폰 젝 등을 지원하기 위해 Apple이 특별히 요구한 사양의 Custom Chip들을 제공하고 있습니다. 따라서, 이들 Chip들의 데이터시트는 일반적으로 공개되어 있지 않는데, 그중 헤드폰 잭을 지원하는 칩인 CS42L84에서 macOS보다 더 높은 성능을 이끌어 낼 수 있는 방법을 알아냈다고 합니다. macOS에서는 48kHz와 96kHz로만 이 칩을 작동시키는데, 일반 상용 CS42L42 칩의 데이터 시트를 분석한 결과, 레지스터는 비록 다르지만 특정 rate를 설정하는 값 자체는 동일하다는 점을 발견하게 되었다고 합니다. 이를 이용하면 macOS에서는 지원하지 않는 44,1, 88,2, 176.4, 및 192kHz의 값을 설정할 수 있어 하드웨어가 지원하는 최고 수준의 192kHz/24bit 고해상도 음원을 지원할 수 있게 됩니다. 이 패치 또한 Kernel 7.1에 정식으로 포함시킬 예정이라고 합니다. 물론, true 192kHz의 음원을 즐기려면, 음원 - Pipewire - wireplumber - H/W 설정이 모두 적절히 설정 되어야만 되는 부분이기는 합니다.

여덟 번째 내용은 M3 지원과 관련된 것입니다.
현재까지 PCIe, 키보드 및 트랙패드, SMC 기반의 RTC 및 reboot 컨트롤러, 그리고 내장 저장장치인 NVMe 컨트롤러의 접근 권한을 확보했다고 합니다. 현재 수준은 alpha 단계로 기본적인 하드웨어들을 인식하고 제어할 수 있는 수준이라고 하는데, 일반 사용자들이 M1/M2처럼 curl | sh 로 설치할 수 있는 단계는 아니지만, 곧 M3를 지원할 수 있게 될 것이라고 언급하고 있습니다.
마지막으로는 Fedora 44 릴리즈 시점과 그리 차이 나지 않게, Asahi Linux도 44 버전을 공식 릴리즈 할 것이라고 합니다.

- - - - - - - -

이번 Kernel 7.0과 관련된 진행 보고서는 그 어느 때의 보고서 보다, 내용이 길고 많은 부분을 다루고 있는 것 같습니다.
아직은 M1/M2에서도 Thunderbolt와 DP-alt Mode 지원이 정식으로 제공되지 않고 있습니다. Fairydust Kernel branch를 통해 그 가능성을 보여 주었고, 머지않아 정식 릴리즈에서 이 기능들은 탑재될 것으로 예상이 됩니다. 아울러, M3 지원이 순조롭게 진행되고 있다는 것은 사용자들의 기대감을 높이는 요소입니다.

Ashi Team의 노력과 열정에 박수를 보내며,
앞으로의 성과에 대해서도 응원을 보냅니다.

AI 코딩 어시스턴트 3개월 사용기: 취미 개발자의 시선에서 바라본 Gemini, Claude, Codex 비교

elsa in mac — Sat, 25 Apr 2026 12:44:31 +0900

이번 포스트에서는 전문 개발자가 아닌 취미 개발자로서, 지난 3개월 동안 AI 코딩 어시스턴트(Coding Assistant)를 활용하며 느낀 점을 정리해 보고자 합니다. 여전히 AI를 사용하지 않고 계신 분들도 있을 것이고, 내 일상의 어떤 부분에서 어떤 것을 사용할지 여전히 고민하고 있는 분들도 있을 것이라 생각됩니다. 분명한 것은 Internet, smart-phone이 그러했듯이 시대는 변화하고 있고, 우리는 적응을 해야 합니다. ^^

현재 터미널 환경에서 사용할 수 있는 대표적인 AI 코딩 어시스턴트로는 Google의 Gemini-CLI, Anthropic의 Claude Code, 그리고 OpenAI의 Codex-CLI가 있습니다. 필자는 이 서비스들을 Gemini-CLI > Claude Code > Codex-CLI 순으로 경험해 보았습니다. 본 비교는 지극히 개인적인 경험에 기반한 결론입니다. 현재 세 기업이 새로운 모델 출시와 성능 업그레이드를 통해 치열하게 경쟁하고 있는 만큼, 향후 양상은 언제든 바뀔 수 있습니다. 다만, 지난 3개월간 세 가지 모델을 직접 병행하며 느낀 유의미한 차이점들을 적어 봅니다.

서비스 플랜 및 사용 환경

필자는 세 서비스 모두 가장 낮은 단계의 유료 구독 플랜(Gemini Pro, Claude Pro, Codex Plus)을 이용해 왔습니다. 구독료는 세 서비스 모두 월 20달러 수준으로 비슷하며, 연속 사용 시간 및 주간 사용량 제한 옵션이 공통으로 적용됩니다. 대규모 코드베이스를 다루지 않는 취미 수준의 프로젝트에서는 대체로 사용량이 부족하지 않았으나, Claude의 경우 잦은 시간제한으로 인해 작업 흐름이 끊기는 불편함이 다소 있었습니다.

12개의 프로젝트에서 사용하고 있으며, 이 중 7개는 직접 작성한 프로젝트이고, 3개는 직접 구현중 AI 사용을 병행한 것이며, 2개는 완전 vibe coding으로 구현한 프로젝트입니다. 사용언어도 shell-script, C, C++, Rust, javascript, html, python 등의 언어를 사용합니다. git 관리는 이미 온전히 AI에 위임했습니다.

사용 모델은 Gemini는 gemini-3-flash , Claude는 Sonet 4.6 , Codex는 gpt-5.4 로 셋다 중간 수준의 모델들이며 동일하게 모두 No-thinking 모드를 사용합니다. 최상위 모델 혹은 Thinking 모드를 사용하지 않은 이유는 토큰 소모량이 상대적으로 높고 반응 속도가 느리기 때문입니다. 중간 체급의 모델만으로도 취미 개발 수준에서는 충분히 만족스러운 성능을 줍니다.

실전 코딩 능력 비교: "의도를 읽는 능력"

성능과 속도, 편의성 측면에서 2026년 4월 현시점에서 가장 뛰어난 모델은 OpenAI의 Codex였습니다. 간단한 예시로 차이점을 살펴보겠습니다. Rust로 CLI 도구를 개발하며 다음과 같이 요청했습니다.

"실행 옵션에 --provider와 --show-browser가 있는데, -p와 -s로도 사용할 수 있게 해줘."

- Gemini: 긴 옵션과 단축 옵션 사이의 관계를 명확히 유추하지 못하는 모습을 보였습니다.
- Claude: 단축 옵션을 인지하고 코드에 `-p`와 `-s`를 추가하는 수준에 그쳤습니다.
- Codex: 옵션 추가는 물론, README.md 파일을 스스로 수정하여 두 가지 옵션 방식에 대한 설명과 사용 예시까지 보강했습니다.

검증 과정에서도 차이가 있습니다. 세 모델 모두 빌드 테스트는 수행하지만, Codex는 해당 옵션이 의도대로 동작하는지 확인하는 테스트 코드(Test Code)까지 작성하여 검증을 합니다. 또한 예외 처리 능력에서도 수준 차이가 있습니다. Gemini는 단순히 기능을 추가할 뿐 예외 처리에 소홀했고, Claude는 기초적인 처리는 하나 정의되지 않은 옵션(예: `-c`) 입력 시 안내 메시지를 출력하는 디테일은 부족했습니다. 반면 Codex는 예외 처리 구문까지 완벽하게 구현해 냈습니다.

코드 완성도와 분석력

새로운 함수를 구현하거나 리팩터링(Refactoring)을 요청할 때의 안정성도 차이를 보이는데, Gemini는 함수 수정 시 변수 선언이나 초기화를 누락하는 경우가 빈번했고, 프로토타입을 빼먹어 빌드 오류를 야기하곤 해서 결과를 한 번 더 손봐야 하는 번거로움이 있습니다. Claude와 Codex에서는 이러한 기초적인 실수가 거의 발생하지 않아 신뢰도가 높았습니다.

코드 분석 능력의 경우 Gemini도 준수한 편이지만, 실제 코딩 구현 능력은 상대적으로 미흡했습니다. 종합적인 분석력은 Codex가 가장 탁월했고, 처리 속도와 분석 수준의 균형은 Claude가 우수했습니다.

최적화 검토 시, Claude와 Codex는 수정이 시급한 부분과 현 상태를 유지해도 좋은 부분을 명확히 구분했습니다. 특히 Codex는 불필요한 수정을 권하지 않는 단호함을 보여주었습니다. 반면 Gemini는 모든 요청을 수용하려다 보니 오히려 기존의 최적화가 깨지거나 예상치 못한 버그가 발생하는 부작용이 있었습니다.

다른 예로 자료구조나 메모리 사용 및 CPU/GPU 사용 최적화를 분석할 때도 차이가 있는데, Gemini와 Codex/Claude 간에 극명한 차이가 있습니다. Gemini는 가장 최신의 알고리즘과 자료구조가 더 좋다는 식의 분석을 내놓지만, Codex나 Claude는 해당 프로젝트의 규모나 사용 platform 환경 즉, Server 급인지, Desktop 인가 혹은 Mobile 환경에서 동작하는 app인지의 여부를 고려합니다. 보틍은 프로그래머 들조차도 자신들이 경험하고 작업한 환경이 다른 경우에 어떠한 자료구조나 알고리즘이 더 적절한지를 모를 때가 많습니다. 당연히 비 전문가들이 Vibe Coding을 할 경우에는 더욱 그러겠죠. 자신이 만드는 app이나 service가 어떤 grade의 성능과 자료구조, DB의 규모를 다루는 가에 따라 특정 알고리즘은 적절할 수도 혹은 비효율적일 수도 혹은, 너무 over-spec. 일 수도 있습니다. 이러한 분석력에서도 가장 좋은 결과를 내주는 것은 Codex 였습니다.

물론, 코드 수정, 코드 분석등에서 각 모델이 어떤 것들을 고려하고 어떤 것들은 하지 말아야 하는 것들을 System Prompt 기능을 통해 정의하고 제한할 수 있지만, 개인적으로는 거의 System Prompt를 정의하지 않고 사용합니다.

비용 호율성(토큰 소모량)

AI를 사용할 경우, 소모되는 토큰의 소모 정도나 가중치는 각 회사의 내부 정책에 따르기 때문에 절대적인 비교가 불가능합니다. 다만, 사용시간 대비 동일한 수준의 결과를 얻는데 소모되는 토큰 효율성은 Gemini 가 가장 여유로운 것 같고, Codex는 중간 정도이며, Claude의 경우에는 토큰 소모량이 매우 빠른 편입니다. Claude의 경우에는 신규 모델 출시 시 이러한 가중치가 가변 되는 것 같습니다. 소비자 입장에서는 기존에 사용하던 모델을 그대로 사용하는 것뿐인데, 기존과는 다르게 빠르게 소진되는 듯한 느낌을 갖게 됩니다. 물론 이건 공식적인 언급이 없기 때문에 느낌인지 진짜인지는 모르겠지만, 스트레스를 받는 것이 사실입니다. 마치 뭐랄까? 연료가 얼마 남지 않은 자동차를 고속도로에서 운전하고 있는 듯한 느낌이랄까? 불안감이랄까?

특정한 기능을 추가하거나 기존의 버그를 수정할 때, Claude의 경우는 정말 너무 빨리 소모되어서 5시간 기준 limit reset을 기준으로 봤을 때, 1시간 정도만 사용하면 이미 90%에 육박하기도 합니다. 불편하면 더 높은 구독플랜으로 업그레이드를 하면 된다지만, 굳이 대안이 있기에 그럴 필요성은 느끼지 못합니다. 반면, Gemini는 가장 여유롭고, Codex는 중간 정도인데, Gemini와 Codex를 사용하면서 5시간 limit에 걸린 적은 없습니다. 사용자 입장에서는 성능과 사용량이라는 두 가지를 고려해야 하는데, 이런 점에서 Claude는 높은 점수를 줄 수 없습니다.

단순히 소모량만 보면 Gemini가 유리해 보일 수 있으나, 원하는 결과물을 얻기 위해 대화를 여러 번 반복해야 한다는 점을 고려하면 실질적인 효율성은 Codex가 가장 뛰어나다고 볼 수 있을 것 같습니다.

- - - - - - - - -

결과적으로 필자의 경우에는 Gemini에서 Claude를 거쳐 Codex에 정착하게 되었습니다. 현재는 Gemini와 Claude의 구독을 해지한 상태이며, Codex만으로도 충분히 만족스러운 개발 환경을 유지하고 있습니다.

앞서 언급했듯이, 이는 저의 개인적인 경험일 뿐입니다. 프로젝트의 규모나 복잡도, 혹은 코딩이 아닌 다른 창작 영역에서는 각 사의 AI가 또 다른 강점을 발휘할 수 있을 것입니다. 취미 개발자로서 나에게 가장 잘 맞는 '코딩 파트너를 찾아가는 과정 자체가 또 하나의 즐거운 여정이었고, 그나마 현실에서 만족스러운 서비스를 사용할 수 있게 된 점은 다행이라고 생각하고 있습니다. (이게 언제까지 유효할지는 또 모를 일이지만..)

Anthrophic, Claude Pro 요금제 사용시 Claude Code 사용 불가 ?!

elsa in mac — Wed, 22 Apr 2026 22:15:49 +0900

2026년 4월 22일.
오늘 Anthropic이 자사의 구독 서비스인 Claude Pro 요금제에서 AI 코딩 도구인 Claude Code의 액세스 권한을 제거한 사실이 알려지면서 난리가 났었습니다.

Reddit 등 인터넷 정보공유 공간에서 이 문제가 이슈화 되면서 수많은 Claude 구독 사용자들의 공분을 샀고, 지금은 다시 Pro 요금제에서 Cluade Code를 사용할 수 있는 것으로 수정되었지만, 의구심은 가시지 않은 상태입니다.

AI 서비스를 제공하는 기업 입장에서는 시스템 유지 비용이 여전히 계속되고 있는 관세 비용과 전쟁으로 촉발된 에너지 및 반도체 가격의 폭등 같은 환경의 변화로 인한 유지 및 서비스 제공과 관련된 비용이 점점 더 가중되어 가고 있기 때문에, 20달러 수준의 구독료로는 제무적으로 큰 도움이 될 수 없을지도 모릅니다.

하지만, 20달러 Pro 요금제를 사용하는 대부분의 사용자들은 프로그램 개발을 직업으로 갖고 있는 것이 아니라, 취미로 프로그램을 개발하거나 수정 및 코드 최적화에 AI의 도움을 받으려는 사람들일 것입니다. 만일 Claude Code를 Max 요금제부터 사용할 수 있다면, 매 달 최소 100달러 이상을 지불해야 하는데, 단지 취미로 Claude Code를 사용하면서 매달 100달러 이상을 지출한다는 것은 요즘 같은 고물가 시대에 부담스러운 수준이 아닐 수 없습니다.

논란이 커지자 Anthropic 의 관계자는 신규 개인 사용자(prosumer) 가입자의 약 2%를 대상으로 진행 중인 소규모 테스트였으며, 기존의 Pro 구독 사용자들은 영향이 없을 것이라고 언급하면서 변경 사항이 확정될 경우 사전에 공지하겠다고 덧붙였습니다.

잠깐의 헤프닝으로 끝나는 것 같지만, 개인적인 생각으로는 결국 현실은 우리가 기대하는 것과는 반대로 흘러갈 가능성이 높습니다. 기업이 서비스 가격 결정권을 갖고 있기 때문에, 수많은 비난에도 구독의 옵션을 조정하는 것이 그들 입장에서 타당하다고 판단한다면, 언제든 변경할 수 있습니다. 사용자 입장에서는 결정권이 없습니다. 정책이 변경되어 정말 Pro 구독자들이 Claude Code를 사용할 수 없게 된다면, 사용자들은 어쩔 수 없어 또 나름의 대체제를 찾아 떠나야 할지도 모릅니다.

물론, Local LLM 으로 비슷한 수준의 AI Coding Assistant 환경을 구축하려면, 중고차 한 대 가격 수준의 비용이 들어가는 현실을 감안하면, 한 달에 20달러는 현실적으로는 그리 비싼 수준은 아닙니다만, 시간이 가면 갈수록 가성비가 낮아져 가는 트렌드는 소비자 입장에서는 압박감으로 다가오는 것도 분명 사실입니다.

이번 움직임은 캐나다의 작가이자 비평가인 Cory Doctorow가 언급한 Enshittification(엔시티피케이션 : En-(안에 넣다), Shit(비속어), ~화 하다(-fication)). 즉 '플렛폼의 저질화'의 한 예일 수 있습니다.

코리 닥터로는 이 현상을 3단계의 과정을 거친다고 설명합니다.
1 단계는 "사용자에게 호의를 배푸는 단계'로 초기 사용자를 모으기 위해 손해를 감수하면까지 서비스를 거의 무료 혹은 매우 저렴한 가격에 제공하는 단계입니다.

2 단계는 '판매자/비지니스 고객을 유혹하는 단계'로 사용자 층이 충분히 모여 Lock-in 효과가 발생하면, 플랫폼은 사용자 데이터를 활용하여 판매자나 광고주에게 이득을 주며 그들을 플랫폼으로 끌어들이는 단계입니다.

3 단계는 '착취 및 저질화 단계'로 사용자와 판매자 모두가 플랫폼을 떠나가 어려워진 시점에 플랫폼은 이윤 극대화를 위해 서비스 품질을 낮추고 수수료를 올려 결과적으로 서비스가 쓰레기처럼 변화게 되는 단계로 알고리즘은 더 이상 사용자를 위한 것이 아니라 돈벌이에 집중된 알고리즘으로 변화되고 외부 링크를 차단하거나 타 서비스와의 연동을 어렵게 만들어 사용자들을 더욱 깊게 가두는 단계입니다.

- - - - - - - -

결국 Anthropic의 이번 '2% 테스트'는 단순한 해프닝이 아니라, 플랫폼이 사용자 호의(Goodwill)를 이윤으로 치환하기 시작하는 엔시티피케이션의 전조일지도 모릅니다. 기업이 비용 절감과 수익화를 위해 서비스의 질을 낮추는 순간, 사용자는 '혁신의 동반자' 에서 '착취의 대상' 으로 전락합니다.

Anthropic의 창업자들은 OpenAI 출신으로, 지나친 상업주의로 흐르는 것에 대한 우려와 AI의 안전 및 신뢰성을 최우선으로 연구하기 위해 회사를 떠나 창업한 것으로 알고 있습니다. 그리고 현재 그들은 AI, 그중에서도 코딩 분야에서 가장 선두에 선 기업이 되었습니다. 물론 기업은 자선단체가 아닙니다. 기업의 존립을 위해서는 이윤을 남겨야 하고, 보다 혁신적인 기술을 지속하기 위해서도 많은 투자가 필요합니다. 다만, 그들이 회사를 설립하며 가졌던 그 초심이 오랫동안 유지되기를 사용자의 한 사람으로서 진심으로 바라 봅니다.

OS에 상관없이 Chrome 브라우저에서 HWP 파일을 읽고, 수정할 수 있는 확장프로그램 - rhwp

elsa in mac — Fri, 17 Apr 2026 21:12:59 +0900

이번 포스트에서는 macOS나 Linux를 사용하는 사용자 분들에게 유용한 정보가 될 수 있을 것 같습니다.

요즘에도 HWP 를 사용하는 분들이 많은지는 모르겠으나 가끔 정부/공공기관에서 배포하는 전자문서 파일들 중에는 아직도 HWP로 배포하는 경우가 많이 있습니다. 혹은 과거에 Windows를 사용하다가 macOS나 Linux로 OS를 변경하신 분들 가운데, 과거에 작성했던 HWP 문서를 열어 볼 일이 있을 수도 있겠죠. 이런 분들께 유용한 Chrome Extension 인 rhwp(chrome 웹 스토어)를 추천 합니다.

이 extention은 단순히 HWP 문서를 열어보는 뷰어가 아니라, 문서를 편집할 수 있는 에디터 기능을 모두 사용할 수 있습니다.

인터넷에서 HWP 문서 링크를 클릭하면, 위와 같이 자동으로 rhwp가 반응하며 즉시 문서가 편집 모드로 열리게 됩니다. 새로운 문서를 작성할 수도 있고, 편집된 문서는 local 저장소에 저장할 수도 있으며, 프린터로 출력할 수도 있습니다.

물론, HWP 문서의 버전에 따라 약간의 레이아웃이 살짝 틀어지거나 겹쳐 있거나 하는 부분들이 있을 수 있기는 하지만, HWP 문서를 열고 내용을 확인하는 데에는 그리 큰 문제는 아니라고 생각됩니다.

macOS나 Linux에서 HWP app을 사용하기 어려웠던 분들에게는 매우 유용한 확장 app 이 아닐 수 없을 것이라 생각됩니다. extension의 크기도 대략 12MB 안쪽 이니, 부담이 크지 않습니다.

rhwp github 에 가시면, 보다 자세하고 다양한 설치 및 활용 방법을 확인하실 수 있습니다. 굉장히 활발하게 프로젝트가 진행되고 있는 만큼, 부족한 부분들이 많이 있지만 앞으로 더 완성도가 높아질 것으로 보입니다.

Google의 Gemma-4 를 사용해 봤습니다. 꽤~ 인상적이네요.

elsa in mac — Fri, 10 Apr 2026 18:42:15 +0900

본 포스트는 Fedora Asahi Linux에서 작성되었습니다.

최근 Claude, Gemini, OpenAI 등의 유료 구독 모델에서 잇따라 서비스 품질과 토큰 사용량 부족이라는 잡음이 나오면서 사용자들의 불만도 예전과 달리 높아지고 있습니다. 궁극적으로 AI를 사용하는 사용자 측면에서 보면, 구독 서비스보다는 자신의 개인용 컴퓨터에서 AI를 마음껏 사용하는 것을 가장 이상적으로 생각할 것입니다. 하지만 최근 RAM을 포함하여 전반적으로 컴퓨터 부품 가격이 폭등하면서 개인용 AI 머신을 구축하는 것이 아직은 경제적 경쟁력을 갖추지 못하는 상황입니다. 그래서 아마도 대부분은 AI 구독을 주로 사용하고 있을 것입니다. 성능 좋은 시스템을 수백만원 주고 구측하는 데 들어가는 비용과 연간 구독료를 비교 계산해 본다면 아직은 구독이 더 유리한 것 같습니다.

그런데, 때마침 Google DeepMind가 2026년 4월 2일에 Gemma-3에 이은 Gemma-4 오픈소스 모델을 공개했습니다. 사용자나 전문가들의 초기 평가는 매우 좋은 것 같더군요. Gemini 3 기반으로 성능과 효율성을 비약적으로 끌어올린 모델로 평가를 받고 있는 것 같습니다.

공개된 Gemma-4 모델은 E2B, E4B, 26B MoE, 31B Dense 이렇게 네 종류입니다.
E2B는 모바일 디바이스 타깃 모델이고, E4B는 온디바이스에서 추론 기능과 속도에 대한 균형을 맞춘 모델입니다. 26B MoE는 260억 개 파라미터 규모이면서 실제 추론에는 40억 개만 사용하는 모델로, 대규모 모델이면서도 빠른 속도를 낼 수 있는 모델입니다. 마지막으로 31B Dense 모델은 Gemma-4에서 가장 강력한 모델로 복잡한 추론 및 코딩 작업에 특화된 모델입니다.

전반적인 Gemma-4의 성능이나 각 모델이 갖는 성능과 특성은 많은 자료들이 있으니 설명은 필요 없을 것 같습니다.

바로 본론으로 들어가서 필자가 어떤 모델을 어떻게 사용하고 있는지를 소개해 봅니다.
우선 필자의 시스템은 Mac Mini M1 8/256 (2020) 깡통 모델입니다. 현재 시점에서 보면 임진왜란 때 기종이라고 볼 수 있습니다. 더군다나 macOS도 아니고 Asahi Linux를 사용하고 있습니다. Linux 부팅을 하고 나면 여유 메모리가 5GB밖에 안 됩니다. Swap Memory까지 더해도 12GB 수준이죠. 여기에 기본적으로 터미널 몇 개를 띄우고 웹 브라우저를 띄워 놓으면 가용한 실제 물리적 메모리 공간은 2GB 수준입니다.

AI는 Gemini와 Claude를 각각 구독하고 있는데, 조만간 Gemini 구독을 멈출 생각입니다. Gemini부터 사용을 시작했지만, Claude의 적수가 못되기에 그렇습니다. 그렇다고 Gemini가 아주 몹쓸 녀석은 아닙니다. 적어도 코드 분석이나 수정계획 같은 것은 탁월합니다. 다만 Code 수정/최적화/생성에서 Claude의 적수가 못될 뿐입니다. 그리고 토큰 사용량에 있어서도 Gemini가 Claude보다 훨씬 좋습니다. 물론 이것이 장점이 될 수 없는 이유는 응답 속도가 느리고 (최근에 들어서 더욱 심각해졌습니다...) Claude로 한 번에 처리할 수 있는 코딩을 Gemini로는 하루 종일 걸릴 수도 있는 수준이기 때문입니다.

필자는 Gemma-4-E2B와 Gemma-4-E4B를 사용합니다. 주력으로는 속도가 빠른 E2B를 사용합니다. 남들처럼 LM-studio나 Ollama 같은 것으로 모델 서버를 돌리고 OpenCode를 사용할 수는 없습니다. 그러기에는 메모리가 엄청 부족하고 GPU는 전혀 사용할 수 없어 최소한의 요구 컨텍스트조차 맞출 수가 없습니다.

그래서 직접 Gemini-CLI, 나 Claude Code 같은 터미널 기반의 Gemma-CLI를 만들어 사용하고 있습니다. 적은 메모리와 CPU만으로 구동해야 하기 때문에 채팅 모드를 살짝 변형하여 사용합니다.

다만, system prompt, 즉 GEMINI.md나 CLAUDE.md와 같이 GEMMA.md에 규칙을 정의하고 이를 매 채팅 질의 때마다 반드시 프롬프트로 포함하여 요청하는 방식을 사용합니다. 이렇게 하면 굳이 서버를 돌릴 필요도 없고 매우 적은 컨텍스트만으로 몇 가지 일을 시킬 수 있습니다. 물론 프로젝트 기반의 소스코드 분석은 완전 무리가 있고, 설사 코드 분석을 시킬 수 있게 만들더라도 History Sliding Window 기법과 코드를 80라인씩 쪼개서 분석하는 방식을 사용해야 합니다. 굉장히 시간이 오래 걸릴 수밖에 없지요.

따라서 현실적으로는 Claude를 주력으로 사용하면서 단순한 보조 역할로 사용합니다. Git 관리, 웹 검색이나 매우 빈번히 사용하는 GitHub 프로젝트 관리, 번역, 글 교정 등에 활용합니다. 이러한 작은 도우미 역할로는 꽤 좋습니다. 오히려 규모가 작은 모델이라 더 효율적입니다. 물론 Claude의 토큰 소모를 조금이라도 줄이는 데 기여하고 있지요.

Gemma4-e4b 모델로 이미지 분석으로 요청해 본 예.

위의 스샷은 E4B 모델로 이미지 분석을 요청해 본 예입니다. 비교적 정확하게 이미지를 분석합니다. 질의를 하고 결과가 나오기 시작할 때까지 대략 8초 정도 대기한 것 같습니다. (실제 사용에서는 개인적으로는 별 의미는 없습니다. ^^)

Gemma4-e2b 모델에서 Git commit을 처리하는 예 입니다.

위의 스샷은 git commit을 수행하는 예를 보여 줍니다. 코드 분석도 꽤 잘하는 편이라서, Commit 제목이나 변경 내용도 매우 정확하게 define 하는 것을 알 수 있습니다. 이 작업을 수행하려면, GEMMA.md 이 외에 GEMMA-git.md 라는 시스템 프름프트를 이용해야 합니다.

위의 스샷은 기본 System Prompt의 내용입니다. 매 질의 때마다 자동으로 위의 내용이 질문과 함께 요청됩니다. gemma-4는 기본적으로 function-calling 및 tool-calling 기능을 갖고 있기 때문에, 권한에 대한 기준만 설정해 주면 내부적으로 정의된 function 이나 tool을 사용할 수 있고, 따라서 shell 명령어나 web fetch 등을 사용할 수 있습니다.

기본 system prompt

위의 스샷은 git 사용에 대한 rule을 정의한 system prompt 입니다. git commit 요청을 받으면 어떤 과정으로 처리할지를 정의하고 있습니다.

gemma 모델을 구동하기 위한 도구로는 LiteRT-LM 이라는 도구를 사용합니다. 이 프로젝트는 edge device에서 LLM을 빠르고 효과적으로 구동하기 위한 것으로 IOS, Andriod, Web, Desktop 등에서 사용할 수 있고 CPU, GPU, NPU 등을 사용할 수 있으며, python, JVM, Swift(IOS, macOS), C++ 등의 언어를 지원합니다. 서비를 구동하는 것이 아니고 직접 prompt를 통해 AI model을 사용할 수 있는데, Gemma-4에 맞춰 function-call , tool-call 을 사용할 수 있고, MultiModal 도 지원하여 이미지, 오디오 등을 Ai Model에 전달할 수 있습니다. 가장 특징적인 것은 메모리나 GPU RAM 등이 절대적으로 작아도 사용할 수 있다는 점입니다. Mobile 기기에서 On-Device AI를 타깃으로 하고 있기 때문입니다. 실제 물리적인 Memory도 사용하지만, 대부분은 저장장치에 cache 파일을 운용하는 방식입니다.

위와 같이 일반적인 질의에도 잘 대응을 합니다. 물론, 당연히 헛소리를 하는 경우도 있습니다. E2B 보다 E4B가 반응 속도면에서는 느리지만, 확실히 E2B보다는 좀 더 정확하고 디테일한 결과를 보여 줍니다.

Frontend 구현은 Rust 언어 기반으로 터미널 app으로 만들었으며, Model 과의 소통은 외부에 LiteRT-LM python SDK를 이용하여 engine.py를 만들고 이를 rust가 stdin/stdout JSON으로 통신하도록 했습니다. Session 기능이 있어서 지난 대화 내용을 기억하지만, 워낙 소규모 모델이기 때문에, 구독형 AI 모델보다는 당연히 수준이 떨어집니다. 따라서 대부분 단발성으로 문/답하는 것이 더 효과적입니다.

기본적으로 Session 을 지원하기 때문에 지난 대화 내용을 연계하여 계속 대화를 이어갈 수 있다.

아니면, 외국어 회화 연습을 상항극으로 하는 것도 좋습니다. gemma-4는 다국어를 지원하므로 다양한 회화연습에 도움이 될 수 있습니다. 오히려 출력 결과가 너무 빠르지 않기 때문에 출력문을 꼼꼼이 읽을 수 있는 여유가 있습니다. 이 작은 모델로도 외국어 강의를 듣는 것보다 효과적이니 굉장하죠 ?

그리고, 마지막으로 가장 중요한 거. Claude의 Sub-Agent로 사용을 합니다. Claude가 필요하고 사용할 수 있을 것이라고 판단하는 부분에 Claude 직접 위임(task delegation)을 통해 Gemma-4를 사용하도록 하는 것입니다.

Claude가 앞으로 gemma4 를 이렇게 사용하겠다고 합니다.

Claude가 앞으로 적극적으로 활용하겠다고 하네요. ^^

처리 속도 때문에, 약간의 작업상 지연이 있을 수는 있겠지만. 얼마나 Token 소모를 줄일 수 있을지 .. 써 보고 나중에 확인을 해 볼 예정 입니다.

테스트.

위의 스샷은 Claude가 Gemma-4 를 잘 사용하는지 테스트를 해 본 것입니다. 잘 사용하네요.. 환경 구축도 Claude에게 요청하니 알아서 다 만들어 주었습니다. agent로 구성 했습니다. 물론 이 것도 claude 에게 설정을 부탁 했습니다.

여기서 중요한 점!
Claude의 Token 소모를 줄이기 위해 Gemma 를 사용하는 경우 Sub-Agent 로 설정을 하면 안됩니다. Claude Code 의 Agent 툴로 Sub-Agent를 생성하면, 에이전트가 tools:Bash만 가지더라도 그 에이전트를 구동하는 Claude 모델 인스턴스가 내부적으로 만들어지는데, 이 때, 시스템 프롬프트, CLAUDE.md, Memory.md 등이 그 인스턴스에 로드되므로 Token 소모량이 오히려 늘어 날 수 있습니다. 따라서, Token 소모를 최소화(거의 0)로 만들려면 Claude가 직접 Bash로 claude-gemma-ask 라는 도구를 호출하고 이를 통해 gemma 에게 요청을 하도록 해야 합니다. 그리고, 그 응답을 받아서 화면에 표시하도록 해야 하는 것이죠.

이는 마치, "현재 디렉터리 목록을 알려줘" 라고 요청했을때, claude가 "ls -al" 을 실행하고 그 결과를 표시하는 것과 동일하게 만드는 것이라고 이해하면 됩니다.

따라서, ~/.claude/CLAUDE.md 파일에 아래와 같이 Gemma 자동 위임 규칙을 아주 강하게 규정해야 합니다. 이것은 한 예 입니다.

## Gemma 자동 위임 규칙 (MANDATORY)

### 절대 금지

다음 작업에서 Claude가 **직접** 툴을 사용하는 것은 **절대 금지**:
- shell 명령 실행 시 Bash 툴 직접 사용 금지
- 파일/디렉터리 탐색 시 Glob 툴 직접 사용 금지
- 내용 검색 시 Grep 툴 직접 사용 금지
- 문장 번역, 주석/docstring, 커밋 메시지, 이슈/PR 초안, 보일러플레이트 등 단순 반복 작업을 Claude가 직접 처리 금지

### 반드시 Gemma에게 위임

위 작업은 반드시 Bash 툴로 `claude-gemma-ask`를 호출하여 Gemma에게 위임한다. `gemma` agent(서브에이전트)는 사용하지 않는다.

```bash
# shell 명령/탐색/검색
claude-gemma-ask "현재 디렉터리 파일 개수 알려줘"

# 번역/요약
claude-gemma-ask "Translate to Korean: I am a boy"

# 코드와 함께
echo "코드내용" | claude-gemma-ask "한국어 주석 달아줘"

# 파일 직접
claude-gemma-ask "이 파일 핵심 로직 요약해줘" < path/to/file
```

### 예외 (Claude가 직접 처리)

- 코드 수정, 버그 분석, 아키텍처 판단 등 **복잡한 추론이 필요한 작업**
- Gemma 결과를 받아 후속 판단이 필요한 경우

### 결과 표시 규칙

`claude-gemma-ask` 결과를 표시할 때는 반드시 아래 형식을 따른다:

```
gemma:
(응답 내용)
```

아래는 실행 예 입니다.

Gemma-4 E2B, 나 E4B 등을 빠르게 돌릴 수 있는 시스템이라면 충분히 유용한 방법이라고 할 수 있을 것 같습니다.

가속화되어가는 AI 시대 - 우리는 과연 감당할 수 있는 것일까 ?

elsa in mac — Sun, 29 Mar 2026 20:26:53 +0900

TechCrunch에 지난 3월 19일에 올라온 글이 흥미롭습니다. 제목은 Online bot traffic will exceed human traffic by 2027, Cloudflare CEO says 입니다.

지난주 오스틴에서 열린 SXSW 콘퍼런스에서 가진 인터뷰에서 그는 인공지능의 성장 속도를 고려할 때, 2027년에는 AI Bot 트래픽이 온라인상의 인간 트래픽을 넘어설 것이라고 예측하고 있습니다.

모든 홈페이지, 기업 및 검색 포털은 광고로 점철되어 있고, 이는 해당 사이트를 방문하는 사용자, 즉 인간을 대상으로 준비된 것입니다. 적어도 과거의 환경은 누구나 알고 있듯이 그래 왔습니다. 하지만 AI가 발달하면서 사용자들은 점점 직접 검색하거나 기존에 방문하던 사이트를 직접 방문할 필요가 없어지고 있습니다. 대신 AI에게 검색을 요청하고 그 최종 결과만을 보게 됩니다. 이러한 컴퓨팅 환경의 변화는 광고 시장에 엄청난 타격을 줄 것이 너무나 자명해 보입니다.

AI Bot이 광고를 실어 나르지 않는 이상, 더 이상 일반 사용자들은 광고를 볼 필요가 없기 때문입니다.

클라우드플레어 CEO인 메튜 프린스는 사람이 디지털카메라를 구매한다고 가정할 때, 아마 다섯 군데 정도의 웹사이트를 방문하겠지만, 에이전트나 봇은 실제 사람이 방문하는 웹사이트 수의 1,000배에 달하는 사이트를 방문할 가능성이 높다고 말했습니다. 이것은 실제 트래픽이고 모든 기업이 고려하고 해결해야 할 실제 부하라고 언급했습니다. 그는 생성형 AI의 등장과 데이터에 대한 끝없는 갈망으로 2027년에는 온라인 봇 트래픽이 온라인상의 인간 트래픽을 넘어설 것으로 예상한다고 합니다.

그의 예상이 맞다면, 에이전트나 AI 봇의 무차별적인 트래픽은 인터넷 과부하를 유발할 수 있으며, 기업들은 이를 규제하려는 방어 기제를 발동시킬 것이고, 이는 또 다른 한편으로는 AI 발전의 방해 요소로 작동하게 될 것입니다.

콘텐츠 생성 분야에 있어서도 속도는 엄청나게 빨라지고 있습니다. 과거에 인간이 콘텐츠를 생성할 때는 많아야 하루에 1~2개였다면, 지금은 AI를 이용하면 하루에 수십 개의 Shorts, Youtube, Blog, 광고 콘텐츠를 만들고 인터넷에 등록할 수 있습니다. 이 속도는 더욱 가속화되고 있습니다. 이러한 새로운 콘텐츠를 저장하고 유통하기 위해 얼마나 많은 버퍼의 증설이 필요할지 가늠하기조차 어려울 수 있습니다. 그런 콘텐츠조차 사람이 직접 보는 것이 아니라 에이전트나 Bot들이 보는 상황이라면? 과연 사용자층을 대상으로 한 고품질의 콘텐츠 콘셉트라는 것, 보다 매력적인 디자인, 혹은 트렌드라는 것이 의미가 있을까요? 사람이 보지 않는데 조회수라는 것이 무슨 의미가 있을 것이며, 그 콘텐츠에 넣는 갖가지 광고가 무슨 의미가 있을까요?

인간이 아닌 AI를 대리인으로 내세우고 AI에게 일을 시키고 정보를 취합하게 하거나 검색을 맡기는 환경이 가속화될수록, 인간을 대상으로 한 모든 사업 분야는 더욱 빠른 속도로 무너질 수밖에 없는 것은 아닐까요?

편리함과 효율성을 내세울수록 관련 산업 분야는 점차 무너져 버릴 수밖에 없다는 이 황당한 아이러니가 결국 자신의 목을 조이게 될 뿐이라는 것을 그들은 알고는 있는 것일까요?

AI를 개발한 회사의 직원들이 가장 먼저 잘리고, AI를 도입한 분야의 관련 종사자들이 가장 먼저 밀려나는 이 현실을 우리는 그냥 남의 일인 것처럼 관망만 하고 있어야 하는 것일까요?

AI가 발전해서 우리가 얻는 것은 무엇이며, 잃는 것은 무엇인가? 내가 잃는 것을 덮을 만큼 얻는 것이 더 큰 가치가 있기는 한 것일까요?

Fedora Asahi Remix 43 이 공식 릴리스 되었습니다.

elsa in mac — Sat, 21 Mar 2026 14:20:53 +0900

Asahi Linux 팀에서 2026년 3월 18일 Fedora Asahi Remix 43을 공식 출시했습니다.
Fedora Linux 43이 공식으로 릴리스 된 것은 2025년 10월이니 대략 5개월 정도 지연된 셈입니다.

이번 43 버전에서는 Mac Pro, M2 Pro/Max, MacBook의 내장 마이크와 MacBook Pro 14/16 모델 내장 디스플레이에 대한 120Hz 주사율 지원이 추가되었으며, KDE Plasma 4.6과 GNOME 49를 제공합니다.

M1/M2 Mac에 Fedora Asahi Remix 43을 처음 설치하려면 Mac에서 터미널을 열고, 아래 명령을 실행하면 되는데, macOS 14.2(Sonoma) 이상이 설치된 mac이 필요합니다.

 curl https://fedora-asahi-remix.org/install | sh

기존에 이미 Asahi Linux를 사용 중인 사용자분들이라면 터미널에서 아래 절차를 통해 43으로 업그레이드를 진행하시면 됩니다.

sudo dnf upgrade --refresh 
sudo dnf install dnf-plugin-system-upgrade 
sudo dnf system-upgrade download --releasever=43 

# DNF4 버전을 사용하는 경우(fedora 41 이전 버전을 사용하고 있는 경우) 
sudo dnf system-upgrade reboot 

# DNF5 버전을 사용하는 경우(fedora 41 포함 이후 버전을 사용하고 있는 경우) 
sudo dnf5 offline reboot

sudo dnf5 offline reboot 명령을 내리면, 시스템이 종료되고 자동으로 다시 시작됩니다. 이때 일반적인 부팅 절차가 아닌 Systemd에 의한 업데이트 전용 타깃으로 부팅됩니다. 화면에는 일반적으로 진행률 표시줄(Progress bar)이나 "Updating system...."과 같은 메시지가 표시됩니다. 패키지 설치가 완료되면 다시 리부팅되며, 일반 부팅처럼 진행됩니다. 설치 시간은 기존에 설치된 package의 수와 환경에 따라 차이가 날 수 있으며, 꽤 오랜 시간이 걸릴 수도 있습니다.

관련된 공식 절차는 fedora:Upgrading Fedora using the DNF system upgrade에서 확인할 수 있으며, 주의할 점은 일단 재부팅된 이후 설치가 정상적으로 완료되어 일반 부팅으로 돌아올 때까지 컴퓨터 전원이 꺼지면 안 됩니다.

업그레이드가 성공적으로 완료된 후, 터미널에서 hostnamectl 명령을 실행하면 아래와 같이 설치된 시스템의 정보를 확인할 수 있습니다.

KDE를 사용한다면, infocenter에서 확인할 수 있습니다.

위의 스샷에서 표시되는 각 버전들은 실제 설치 시점에 약간 상이할 수 있습니다. 현재 공식 stable 커널의 버전은 6.18.15-400 입니다. (스샷의 커널 버전은 필자가 별도로 설치한 kernel 입니다.)

이번 43 업그레이드에서 가장 주목할만한 것은 RPM 6.0이 적용되면서 패키지 레이어가 완전히 재구축되었다는 점입니다. 기존의 무겁고 오래된 Berkeley DB 기반 데이터베이스를 버리고 sqlite 등을 사용하는 새로운 고성능 백엔드로 완전히 탈바꿈했습니다. 이를 통해 패키지 쿼리 속도가 빨라졌으며, DB 손상 및 복구 확률이 높아졌음은 물론, 시스템 전체의 라이브러리들이 libdnf5로 통일되면서 기존과는 달리 터미널에서 사용자들이 dnf를 통해 설치한 package, 시스템 업데이트 서비스, 및 GUI 소프트웨어 센터 등이 모두 dnf5를 공유하도록 변경되었습니다.

두 번째로 이제 Mac Pro (M2 Ultra)를 공식 지원하지만, GPU 카드는 여전히 지원하지 않습니다. 이점은 참고하시기 바랍니다.

세 번째는 Mac Book Pro 14/16 모델에서 내장 디스플레이에 대한 120Hz 주사율을 지원합니다. 다만, 이번에 추가된 기능은 고정 주사율이며, 부하에 따라 24Hz ~ 120Hz로 가변 하는 Promotion(VRR) 기능은 포함되어 있지 않습니다. 그 이외의 mac과 외장 모니터는 60Hz까지만 지원됩니다.

KDE Desktop에서는 KDE Plasma 6.6으로 업데이트되면서 성능이 향상되었고 새롭게 Discover가 개선되었습니다. GNOME Desktop에는 GNOME 49 버전이 탑재되었으며, 앱 스택 업데이트 및 향상된 Wayland 합성 기능을 이용할 수 있습니다.

- - - - - - - -

현재 개발이 진행 중인 wip(working-in-progress) kernel 버전은 6.19.11 버전대이며, next 버전은 7.0입니다.
Fedora Asahi Remix 43 릴리즈가 갖는 내부적인 의미는 그동안 수정되고 안정화된 많은 개발요소들이 upstream 되어 Linux kernel, mesa 등에 정식으로 등록됨에 따라 그 동안 미진했던 dcp, M3 mac 지원, thunderbolt4 및 USB-C를 통한 dp-alt mode 외장 모니터 연결 등의 구현에 보다 더 집중할 수 있게 되는 여력을 확보하게 되었다는 점입니다. 다음 버전에서는 기본 M1/M2에서 아직 미지원되는 핵심기능들이 구현될 것이며, 잘하면 M3 mac에서도 Asahi Linux를 사용할 수 있을 것 같습니다.

Ghostty 1.3.0 새롭게 추가된 기능들을 살펴 봅니다.

elsa in mac — Fri, 13 Mar 2026 21:28:07 +0900

2026년 3월 9일, ghostty가 1.3 정식버전을 릴리즈 했습니다.

이번 1.3 버전에서 새롭게 등장한 몇 가지 주요 기능들이 있습니다. scrollback search(스크롤백 검색), native scrollbar, 쉘 프롬프트 클릭을 통한 커서 이동, 명령어 종료 알림, 키 테이블 및 체인 바인딩, 서식 유지 복사 기능 등입니다.

쉘 프롬프트 클릭, 커서 이동

우선, 사용환경으로 대부분의 사용자들이 많이 사용하는 zsh 환경을 기준으로 설명을 해 봅니다.

이 기능을 사용하기 위해서는 ghostty shell integration 기능이 활성화 되어 있어야 합니다. ghostty의 설정파일인 config 파일을 열고, 아래와 같이 shell integration(쉘 통합) 기능을 활성화해 줍니다.

그리고, .zshrc 파일을 열고 아래와 같이 추가해 줍니다.

# Ghostty 셸 통합 스크립트 로드
if [[ -n "$GHOSTTY_RESOURCES_DIR" ]]; then
  source "$GHOSTTY_RESOURCES_DIR/shell-integration/zsh/ghostty-integration"
fi

추가를 했다면, ghostty를 종료한 후에 다시 ghostty를 실행해 줍니다. 그럼, mouse click 을 이용하여, cursor를 shell 명령행의 원하는 특정위치로 곧바로 이동시킬 수 있게 됩니다.

명령행이 긴데, 중간에 옵션을 수정하거나 할 경우 마우스를 이용하여 수정할 부분으로 빠르게 이동하여 수정할 때 편리한 기능입니다.

스크롤백 검색(Scrollback Search)

shell 에서 매우 긴 문장이나 log 를 출력했을 때, scroll up 하거나 page up으로 이미 출력된 내용을 확인할 수 있는데, 이때 특정 검색어로 검색을 할 수 있는 기능입니다. 검색어에 해당하는 부분이 hightlight 되어 빠르게 원하는 내용을 확인할 수 있는 기능입니다.

기본 설정키는 macOS에서는 ctrl+f, linux 에서는 ctrl+shift+f 입니다.

명령어 종료 알림

세 번째 기능은 컴파일이나 이미지 혹은 비디오 처리등 시간이 꽤 오래 걸리는 경우, 해당 명령이 끝난 후에 데스크톱 알림이나 벨소리로 명령행 처리가 끝났음을 통보하는 기능입니다.

ghostty의 설정 파일인 ~/.config/ghostty/config 파일에 관련된 옵션을 설정해 줘야 합니다.

notify-on-command-finish = unfocused
notify-on-command-finish-action = no-bell,notify
notify-on-command-finish-after = 30s

이 기능의 핵심은 단순이 명령어가 끝났다는 것을 짐작하는 것이 아니라, 쉘이 보내주는 OSC 133 시퀀스를 통해 실제 실행 상태를 정확히 추적한다는 것입니다.

notify-on-command-finish 는 언제 알림을 보낼지를 결정하는 것으로 never 는 "알림 안함", unfocused는 터미널 창이 포커스 되어 있지 않을 때문 알림을 울리는 것 입니다. alwasys는 무조건 알림을 통보 합니다.

notify-on-command-finish-action은 어떤 방법으로 알릴지를 결정하는 것으로 bell 은 터미널 벨소리를 이용합니다. notify는 OS 데스크톱 알림 인터페이스를 이용하여 통보합니다. 위의 예처럼 no-bell,notify 라고 하면 소리는 끄고 알림 창만 띄우게 됩니다.

notify-on-command-finish-after는 얼마나 오래 걸리는 작업부터 통보기능을 사용할지를 지정하는 옵션입니다. 기본값은 5초이며, 위의 예를 보면 30s 죽, 30초 이상 걸리는 경우에 한하여 통보 기능을 사용한다고 선언하고 있는 것을 알 수 있습니다.

이 기능 역시 OSC 133 특수코드를 이용하는 방법이므로 shell integration이 설정되어 있어야 사용할 수 있습니다.

키 테이블 및 체인 바인딩

키 테이블 및 체인 바인딩은 tmux 처럼 모드형 키 바인딩을 만들거나, 하나의 키에 여러 동작을 연결(chain)할 수 있는 기능입니다.

keybind = ctrl+a=activate_key_table:resize

keybind = resize/arrow_up=resize_split:up,10
keybind = resize/arrow_down=resize_split:down,10
keybind = resize/arrow_left=resize_split:left,10
keybind = resize/arrow_right=resize_split:right,10
keybind = resize/escape=deactivate_key_table
keybind = resize/catch_all=ignore

위의 예는 ctrl+a 키를 resize 라는 active_key_table에 mapping 하고 있는 것을 알 수 있습니다. 그리고, resize/arrow_up 키를 resize_spilit:up,10 으로 mapping 하고 있는 것을 알 수 있습니다. 즉, ctrl+a 키를 누른 후에 윗 방향키를 누르면 split Pane 즉 분할된 화면의 경계선을 위로 10 픽셀 이동시키라는 의미가 됩니다.

이것은 tmux의 prefix 모드와 유사한 사용자 환경을 제공하는 것입니다. 해당 모드 전환이 이뤄진 후에는 정의된 키 이외의 다른 키들은 입력이 무시되며, esc 키를 눌러 종료 시키게 됩니다. 이를 위해 resize/escape=deactivate_key_table와 resize/catch_all=ignore를 keybinding 하고 있는 것을 알 수 있습니다. 해당 기능을 사용한다면 필수적으로 넣어 줘야 합니다.

tmux와 달리 prefix 키를 1개 이상 설정할 수 있다는 점이 장점이라고 볼 수 있으며, 더욱이 하나의 테이블 안에서 또 다른 테이블을 호출할 수 있는 nested tables(계층구조)를 구성할 수 있다는 점도 장점이라고 할 수 있습니다.

아래의 예는 계층적 구성을 한 예 입니다 .

# ---------------------------------------------------------
# 루트 관리 모드 진입 (Ctrl + a)
# ---------------------------------------------------------
keybind = ctrl+a=activate_key_table:admin

# admin 모드 설정
keybind = admin/s=activate_key_table:split_manager
keybind = admin/t=activate_key_table:tab_manager
keybind = admin/escape=deactivate_key_table
keybind = admin/catch_all=ignore

# ---------------------------------------------------------
# 분할 창 관리 하위 모드 (admin > s)
# ---------------------------------------------------------
# 상하좌우 화살표로 크기 조절
keybind = split_manager/up=resize_split:up,10
keybind = split_manager/down=resize_split:down,10
keybind = split_manager/left=resize_split:left,10
keybind = split_manager/right=resize_split:right,10

# q를 누르면 다시 상위 admin 모드로 복귀
keybind = split_manager/q=activate_key_table:admin
keybind = split_manager/escape=deactivate_key_table
keybind = split_manager/catch_all=ignore

# ---------------------------------------------------------
# 탭 관리 하위 모드 (admin > t)
# ---------------------------------------------------------
# n은 새 탭, x는 탭 닫기
keybind = tab_manager/n=new_tab
keybind = tab_manager/x=close_tab
keybind = tab_manager/right=next_tab
keybind = tab_manager/left=previous_tab

# q를 누르면 다시 상위 admin 모드로 복귀
keybind = tab_manager/q=activate_key_table:admin
keybind = tab_manager/escape=deactivate_key_table
keybind = tab_manager/catch_all=ignore

ctrl+a 를 눌러 prefix 모드로 진입을 한 후, s 키를 누르면 split 모드로 진입을 하게 되고, 여기서 다시 방향키를 누르면 분할 창의 크기를 조정할 수 있으며, q 키를 눌러 main prefix 모드로 나갈 수 있도록 구성되어 있습니다. 여기서 다시 t 키를 누르면 tab 모드로 진입을 할 수 있고 n, x, 오른쪽 방향키, 왼쪽 방향키를 사용하여 새로운 tab을 생성하거나 생성된 tab을 종료하거나 tab간을 이동할 수 있도록 구성되었다는 것을 알 수 있습니다.

즉, 여러 개의 prefix를 개별적으로 만들 수도 있고, 하나의 prefix를 통해 여러 모드를 계층적으로 구성할 수 있는 확장성이 지원됩니다.

서식 유지 복사(Rich Clipboard Copy)

마지막으로 서식 유지 복사 기능은 터미널의 색상과 스타일을 유치한 체 HTML 형식 등으로 복사하여 문서 편집기에 붙여 넣을 수 있는 기능을 제공합니다.

플렛폼 별 주요 업데이트

macOS 에서는 AppleScript 를 통해, 창, 탭, 분할화면등을 제어하고 자동화할 수 있으며, 분할된 화면 상단의 핸들을 이용하여 위치를 옮기거나 탭 또는 창으로 분리할 수 있습니다. 여기에 Ghostty를 시스템 기본 터미널로 설정하는 옵션도 추가되었습니다.

Linux (GTK) 에서는 Renderer를 재 설계하여 터미널 lock time을 최대 4배 단축하여 보다 더 부드러운 화면을 제공합니다.

그 밖에 메모리 최적화, 안정성 테스트를 통한 app crash 발생 빈도를 줄였으며, 유니코드 17을 지원하여 뱅골어등 복잡한 문자 체계에 대한 rendering이 정확해졌고, 최신 이모지등을 정상적으로 표시할 수 있도록 되었으며, 새 탑이나 창을 열 때 현재의 디렉터리를 유지할지 여부를 설정할 수 있고, Drag & Drop 및 붙여 넣기 시 제어 문자를 통한 악의적인 코드 실행을 방지할 수 있는 보안성을 강화했습니다.

- - - - - - - -

Ghostty 가 대중에게 공개되었을 당시, 사용자들과의 활발한 소통과 지원을 얼마나 잘할 수 있는 가가 터미널 에뮬레이터 분야의 후발주자임에도 불구하고 사용자들의 지지와 사랑을 받을 수 있는 성공의 열쇠라고 포스팅했던 기억이 나는데, 결론적으로 Ghostty는 현재까지 잘 진행되고 있고, 개인적인 기대를 넘어 잘 성장하고 있는 것 같습니다.

필자의 경우에도 Ghostty를 주력으로 사용하고 있으며, 점점 더 많은 신뢰감을 갖게 하는 훌륭한 터미널 에뮬레이터입니다. 앞으로의 성장을 응원하고 더 많은 성장과 발전을 기대해 봅니다.

Asahi Linux에서 Apple Silicon 성능을 100% 끌어내는 빌드(Build) 방법.

elsa in mac — Fri, 13 Mar 2026 20:19:10 +0900

본 포스트는 Fedora Asahi Linux를 기준으로 작성되어 있습니다.

이번 포스트에서는 Linux 특히, Apple Silicon M1, M2 Mac에서 bare metal로 돌릴 수 있는 Fedora Asahi Linux에서 사용자가 직접 GUI, CLI, TUI 앱들의 소스 코드를 다운로드받아 빌드할 때 고려해야 할 최적화와 관련된 내용을 살펴봅니다.

Apple Silicon은 Arm processor

Apple Silicon SoC는 ARM 아키텍처를 기반으로 설계되어 있습니다. 좀 더 정확히 표현하자면, Arm으로부터 ARM 명령어 세트(ISA, Instruction Set Architecture)에 대한 라이선스를 얻고, 그 위에 애플이 직접 커스텀한 CPU, Apple이 설계한 GPU, 통합 메모리(Unified Memory) 그리고 NPU 등이 통합된 칩입니다.

Linux에서는 aarch64(ARM 64비트)라고 부르는데, 64비트 ARM 아키텍처를 부르는 공식 명칭입니다. 일반적으로 Linux에서 이미 빌드되어 공식 리포지토리(Repository)를 통해 배포되거나 GitHub에서 빌드하여 배포하는 앱들의 경우에는 Apple Silicon SoC를 위한 최적화 빌드가 되어 있지 않습니다.

ARM 칩은 Raspberry Pi부터 서버용 고성능 CPU까지 굉장히 다양합니다. 따라서 어느 특정 CPU에 최적화된 바이너리를 만들지 않고, 어떤 ARM 프로세서에서도 실행될 수 있는 최적화되지 않은 일반적인 ARM64 명령어만을 사용하여 빌드됩니다. 대부분의 일반 사용자들은 이미 빌드된 이러한 aarch64 바이너리를 사용하고 있으며, 특별히 불편함을 느끼지는 못합니다.

하지만 자신이 사용하는 Mac에서 보다 최적화된 Linux 앱을 직접 빌드하여 사용한다면, 보다 빠르고 리소스를 효율적으로 사용할 수 있게 만들 수 있습니다. 이번 포스트에서는 몇몇 대표적인 프로그래밍 언어와 빌드 환경에서 어떻게 Apple Silicon 칩에 최적화된 바이너리를 만들 수 있는지 그 방법들을 정리합니다.

* Rust project
Rust 언어로 작성된 프로젝트는 대부분 cargo로 빌드를 합니다. 엄밀히 말하면, Rust의 컴파일러는 rustc입니다. cargo는 빌드 도구이자 패키지 매니저입니다. 외부 의존성을 관리하고 빌드 순서(building order)를 정하여 빌드하며 내부적으로 rustc를 사용합니다. Rust 컴파일러인 rustc는 LLVM을 기반으로 하고 있습니다. 이 경우는 다음과 같이 최적화 빌드를 할 수 있습니다.

# 일반적인 빌드 
cargo build --release 

# 최적화 빌드 
RUSTFLAGS="-C target-cpu=native" cargo build --release

rustc가 지원하는 target-cpu의 종류들을 확인하는 방법은 rustc --print target-cpus 명령을 사용하면 됩니다.

지원하는 target cpu들 중 Apple SoC의 종류들을 확인해 보면, 최신 버전의 Rust(1.59+)와 LLVM 환경에서는 `apple-m1`, `apple-m2` 등의 타겟이 명시적으로 포함되어 있습니다. 만약 목록에 보이지 않더라도 `native`를 사용할 경우 컴파일러가 현재 실행 중인 Apple Silicon 칩을 자동으로 인식하여 최적화합니다. 특히 M1, M2, M3는 마이크로 아키텍처의 많은 특성을 공유하고 있으므로, `native` 옵션을 사용하는 것이 가장 안전하고 확실한 최적화 방법입니다.

* Go project
다음으로 go 언어 프로젝트에 대해 알아 봅니다.

Go의 경우에는 환경 변수를 수정하여 Apple Silicon에 맞는 ARM 아키텍처 세대를 설정할 수 있습니다. Apple Silicon SoC는 세대별로 기반이 되는 ARM 아키텍처 버전이 다릅니다. M1과 M2는 ARMv8.5-A 기반이며, M3는 ARMv8.6-A(일부 v9 기능 포함), 그리고 최신 M4는 ARMv9.4-A 기반으로 알려져 있습니다.

go env 를 명령하면, 위의 스샷과 같이 go와 관련된 환경변수들과 그 설정값을 확인할 수 있는데, GOARM64='v8.0' 으로 되어 있는 것을 알 수 있습니다. 이는 generic ARM 아키텍처로 일반적인 ARM cpu 들을 모두 지원하기 위한 base 아키텍처입니다. 따라서, apple silicon m1, m2 에서 최적화 빌드를 하려면 v8.5로 변경해야 합니다.

변경하는 방법은 다음과 같습니다 이 방법은 Go 1.23 버전 이상부터 공식적으로 지원됩니다.

go env -w GOARM64=v8.5

이렇게 설정을 변경한 경우라면 그냥 `go build` 명령으로 빌드하면 됩니다. 하지만 배포용 프로젝트를 개발하고 있다면, 환경 설정을 영구적으로 바꾸는 것보다는 빌드할 때 일회성(one-time) 설정을 사용하는 것이 더 좋습니다.

GOARM64=v8.5 go build

만약 Go 프로젝트 내에서 C 코드를 호출(CGO)한다면, Rust에서 했던 것처럼 C 컴파일러 플래그를 함께 넘겨줘야 최적화 효과를 볼 수 있습니다.

CGO_ENABLED=1 CGO_CFLAGS="-march=native" go build

* zig project
zig의 경우에는 -Dcpu 와 -Dtarget 옵션을 사용합니다.

zig build -Dcpu=apple_m1 -Dtarget=native -Doptimize=ReleaseFast

zig는 LLVM 기반을 적극적으로 활용하는 언어로써, 기본적으로는 -Dcpu 와 -Doptimize 를 사용합니다. -Dcpu 에서는 apple_m1 처럼 명시적으로 설정할 수도 있고, native를 사용할 수도 있습니다. 원칙적으로는 native 사용을 권장합니다. native를 사용하게 되면, 컴파일러가 현재 CPU의 캐시라인 크기나 파이프라인 깊이 등을 직접 측정하여 가장 정밀한 바이너리를 생성하게 됩니다.

* C/C++ project
여전히 많은 프로젝트들은 C/C++로 작성됩니다. C나 C++ 프로젝트의 경우에는 일반적으로 Meson, Ninja를 사용하여 빌드하는 경우가 주류인데, 이 경우 GCC보다는 Clang 사용을 추천합니다. LLVM/Clang은 Apple이 개발에 깊이 참여하고 있으며, macOS의 표준 컴파일러이기 때문에 Apple Silicon SoC에 대한 최적화 수준이 매우 높습니다.

기존의 `meson.build`를 수정하는 대신, 다음과 같이 설정 시 플래그를 전달하여 최적화 빌드를 수행할 수 있습니다.

# 빌드 디렉토리를 처음 설정할 때 Clang으로 지정
CC=clang CXX=clang++ meson setup build

# 최적화 플래그를 포함하여 빌드 (c 프로젝트)
CC=clang meson setup build -Dbuildtype=release -Dc_args="-mcpu=apple-m1 -mtune=apple-m1"

# c++ 프로젝트라면
CXX=clang++ meson setup build -Dbuildtype=release -Dcpp_args="-mcpu=apple-m1 -mtune=apple-m1"

# c++에 c가 포함된 경우라면 
CC-clang CXX=clang++ meson setup build -Dbuildtype=release -Dc_args="-mcpu=apple-m1 -mtune=apple-m1" -Dcpp_args="-mcpu=apple-m1 -mtune=apple-m1"

# 빌드 실행
ninja -C build

이렇게 설정하면 M1이 지원하는 명령어 세트(ISA)를 활성화하고, M1의 파이프라인 구조에 맞춰 명령어를 재배열하여 실행 속도를 극대화할 수 있습니다.

-Rpass=loop-vectorize
빌드 시 `-Dc_args`나 `-Dcpp_args`에 이 옵션을 추가하면, 컴파일러가 루프 코드를 SIMD(Single Instruction Multiple Data) 명령어로 얼마나 잘 최적화했는지 상세 로그를 출력해 줍니다. (참고: 실제 최적화는 `-Dbuildtype=release` 시 적용되는 `-O2` 이상의 단계에서 자동으로 수행됩니다.)

위의 스샷을 보면, for-loop 에 대해서 vectorized loop (vectorization width:4, interleaved count: 4) 와 같이 표시를 하고 있는데, 이는 오류나 경고 문구가 아니고, 해당 for-loop를 다음과 같이 처리한다는 의미입니다.

- vecterization width : 4
첫 번째 데이터를 처리하는 동안 i+1, i+2, i+3 번째 데이터를 미리 준비하거나 동시에 처리하여 CPU 유휴 시간을 없앤다는 의미입니다.
- interleaved count:4
이것은 한 번의 루프 회전에서 4회 분량의 작업을 묶어서 처리한다는 의미입니다.

SIMD는 apple silicon 에 포함된 NEON 이라는 유닛이 담당하는 것으로 M1의 NEON은 128비트 레지스터를 사용합니다. 따라서, 32비트 정수나 float 데이터 4개를 동시에 처리할 수 있습니다. 8bit char 라면, 16개를 한 번에 처리합니다. 따라서, SIMD를 사용하게 되면 명령어를 한번에 처리하기 때문에, CPU 부담이 줄고 처리속도는 배가 되며 전력효율이 좋아지게 됩니다.

-Db_lto=true 옵션
Meson 설정 시 `-Db_lto=true` 옵션을 사용하면 링크 타임 최적화를 활성화할 수 있습니다. 일반적인 컴파일러는 파일 단위로 최적화를 수행하지만, LTO를 적용하면 전체 프로젝트 프로젝트 단위로 코드를 분석합니다.

일반적으로 프로그램을 개발할 때는 여러 개의 c 파일로 구분되어 있습니다. 일반적인 compiler는 a.c , b.c, c.c 파일을 각각 a.o, b.o, c.o로 각각 컴파일합니다. 만일 a.c 에서 b.c에 있는 함수를 call 한다면 그 내부가 어떻게 생겼는지 알 수 없기 때문에 최적화에 한계가 있습니다. 즉, 그냥 이어 붙여서 최종 binalry를 만들게 됩니다. LTO를 적용하게 되면, Link 단계에서 모든 파일을 모아 놓고 파일 경계를 넘나들며 함수를 합치며(inlinig), 안 쓰는 코드는 제거하는 등 전체 프로젝트 단위로 최적화를 수행하게 됩니다. 이 과정을 거치면 함수 안에서 다른 함수를 call 하는 부분을 호출 오버해드를 없애고 코드를 하나로 합치고, 프로그램 전체 흐름을 분석하기 때문에 M1에 포함된 많은 수의 레지스터를 어떻게 효율적으로 나눠 사용할지를 최적화 결정하게 되며, 실행되지 않는 코드들이 있다면 해당 코드를 찾아내어 제거하기 때문에 파일크기를 줄일 수 있습니다.

단, 이를 위해 전체 코드를 분석하는 과정이 필요하므로 빌드 시간이 늘어나고, 빌드 과정에서 메모리 소모가 늘어나며. gdb 나 lldb 등으로 디버깅할 때 소스코드의 위치가 정확히 안 맞을 수 있습니다. 따라서 디버깅 과정에 있다면 LTO 옵션을 사용하지 않고 최종 release 단계에서만 적용하는 것을 추천합니다.

LTO 옵션은 모든 프로젝트에서 사용할 수 있는 옵션은 아닙니다. 라이브러리 프로젝트의 경우 LTO로 빌드하면 해당 라이브러리를 사용하는 다른 프로젝트와 컴파일러 도구 체인 버전이 다를 때 링크 오류가 발생할 수 있으므로 주의가 필요합니다. 따라서 디버깅 단계보다는 최종 릴리스 단계에서 적용하는 것을 권장합니다. 일부 프로젝트에서는 meson.build 에서 해당 옵션을 사용하지 말라고 경고 메시지를 내는 경우도 있습니다.

- - - - - - -

앱을 빌드할 때 Apple Silicon SoC에 맞춰 최적화를 한다는 것은 하드웨어의 잠재력을 100% 끌어내는 과정입니다. 특화된 레지스터 세트를 효율적으로 사용하고, 비순차적 실행(Out-of-Order execution) 특성에 맞춰 명령어를 재배열하며, 가속기 기능을 적극적으로 활용하게 됩니다.

macOS 앱들이 부드럽고 빠르게 동작하는 비결 중 하나는 이러한 하드웨어 최적화 빌드에 있습니다. Asahi Linux 사용자라면 직접 빌드하는 수고를 통해 이러한 성능 이점을 온전히 누려보시기 바랍니다.

Gemini 3.1 Pro 가 나왔네요? 이제 좀 쓸만해 졌나 ?

elsa in mac — Fri, 20 Feb 2026 23:28:15 +0900

2026년 02월 19일 어제죠 ?
Google에서 Gemini 3.1 Pro를 공개했습니다.

AI를 사용하는 분야는 사람들 마다 다르겠지만, 저는 물론 Coding Agent로 사용합니다. 대부분 terminal에서 Gemini-CLI를 사용하죠.

모델 Option을 살펴보니, 떡 하니 gemini-3.1-pro-preview 가 올라와 있더군요.
공식적인 발표자료를 보니, 모든 부문에서 탁월한 점수를 보여 줍니다.

음. 사실은 이런 자료는 별 의미는 없습니다. 경쟁 후보들은 많고, 발표하면 얼마 안가서 뒤집어지기가 다반사라. ㅎ

UPDATE: gemini-cli 에서 어제까지는 보였는데, 오늘은 또 해당 모델이 보이지 않는 군요. 아직은 안정화가 덜 되었나 봅니다.

Coding Agent로 여러가지를 써봤는데, 지금까지는 Top은 Claude의 Opus 4.6 입니다. 정말 소프트웨어 개발자의 의도를 잘 맞춰준다고 할까요? 깔끔하면서도 정곡을 콕콕 찌르는 협업의 맛이 기가 막힙니다.

반면, gemini는 뭐랄까. 말은 참 많고, 공손하기는 한데, 정작 coding 문제 해결 수준은 떨어집니다. 가끔은 정말 짜증날때가 많았죠. 구독을 하고 있는데, "이거 더 구독을 해야 해?" 할 정도로 엉망이었습니다. 전문성이 좀 떨어진다고 해야 하나...

이번에 3.1-pro 가 올라와서 오늘 잠깐 써 봤는데..
오호~ 버전 3 때 보다는 확실히 좋아진 것 같습니다. 우왕좌왕하지도 않고, 한번 말한 것 잘 기억하고, 성급하게 앞서나가지도 않으면서 호흡을 잘 맞춰줍니다. opus 4.6 이나 GLM-5 을 사용하면서 느꼈던 간결함이 살짝 보이는 것 같네요.

version 3 과 GLM-5 이나 Opus 4.6 와 비교를 해 보면, 가장 큰 차이는 어떤 소스코드를 최적화 검토를 시켜 볼 때인데, GLM 이나 Opus는 운영환경을 나에게 물어보고, 최적화가 더 필요한지 아닌지를 판단해 줍니다. 사용자가 아무리 최적화를 하라고 해도, 자신의 분석결과에 따라 더 이상은 최적화를 하지 않아도 된다고 응답하죠. 허나, gemini-3는 달랐습니다. 최적화해 달라고 하면 묻지도 따지지도 않고 언제나 최적화를 합니다. 최적화한 코드를 또다시 최적화해 달라고 하면 또 생각하고 최적화를 합니다. 최적화 요구를 몇 차례 반복하면 코드가 빙빙 돌아 제자리에 올 때도 있습니다. 이건 사실 신뢰를 깎아먹는 것입니다. 무한한 최적화란 최적화를 못한다고 하는 것과 같은 말이죠. 그런데, 이번 3.1-pro 버전은 더 이상 최적화가 필요 없다고 응답을 하는군요.

프로젝트의 운영환경이나 규모를 고려 하지 못하는 것도 지난 3.0 버전의 단점이었습니다. 예를 들어 칼슘은 뼈에 좋은 것이지만, 누군가에게는 독이 될 수도 있죠. 알고리즘을 분석하거나 새로운 알고리즘을 적용할 때 gemini 3은 사용자가 요구하는 알고리즘을 가져와 적용을 해 주었지만, 운영환경을 고려하지는 못했습니다. 빠르게 처리하는 알고리즘은 늘 좋은 것이지만, 모바일 환경에서 사용할 알고리즘이라면 처리속도 못지않게 프로세싱의 부하나 전력 소모에 대한 것도 고려를 해야 합니다. 수 백개의 데이터 범주에서 탁월한 로직이 있는 반면 수백만 개의 데이터 범주에서 탁월한 로직이 있습니다. 굳이 수 백개의 작은 데이터를 처리하는데 대규모 데이터 처리에 사용되는 로직을 가져다 쓰는 것은 적절할 리 만무합니다. 이런 것들을 gemini 3 에서는 잘 분별하지 못했었습니다. 이번 3.1 에서는 좀 고민을 하고 세심하게 검토하는 것 같습니다.

Opus나 GLM, Trinity 같은 모델은 계획단계에서 사용자의 의도가 분분명한 경우, interactive 하게 대화를 이어 나갑니다. "내 생각엔 네가 1,2,3 중 하나를 요구하는 것 같은데, 맞아? 셋 중에 하나 골라~" 이런 식이라면, gemini는 그냥 자기가 생각한 대로 밀어붙입니다. 한참을 수정하다가 보면 엉뚱하게 가고 있는 경우가 많았죠. 3.1에서도 이 부분은 타 모델에 비해 부족해 보입니다. 함수를 생성하여 넣지만, 함수원형은 빼먹는 경우도 있고, 코드 수정이나 추가 후에 빌드를 해보면, 다른 모델들은 거의 한 번에 깔끔하게 끝나는 반면, gemini 는 빌드 오류가 제법 나는 편입니다. 3.1 에서는 나름 완성도가 올라다가긴 했습니다.

좀 더 써봐야 겠지만, 이번엔 좀 제대로 잘 돌아갔으면 하네요.

Asahi Linux, Linux 6.19 진행보고서가 올라 왔습니다.

elsa in mac — Wed, 18 Feb 2026 21:33:59 +0900

2026년 2월 18일.

Asahi Linux 6.19 진행 보고서가 공식 블로그에 올라왔습니다.
진행 보고서란 현재 작업 중인 커널 6.19에 대해 어떤 작업들이 이뤄지고 있고, 어떤 기능들이 새롭게 추가될 것인지를 사용자들과 공유하는 리포트입니다. 제가 굳이 이렇게 포스팅을 하는 이유는, 이 복잡한 기술적 이야기들을 조금이라도 더 쉽게 풀어서 설명해보고 싶기 때문입니다. ^^

보고서에서 첫 번째로 언급하고 있는 것은 dp-alt(DisplayPort Alternative) mode 즉, USB-C 포트를 통해 비디오 신호를 직접 모니터에 전달하는 기술 구현과 관련된 부분으로, 이는 궁극적으로 별도의 변환기 없이 USB-C 케이블 하나로 모니터 연결, 데이터 전송, 전력 공급(Power Delivery, PD)을 동시에 해결하는 것입니다. 최근 Asahi Team은 Linux GitHub를 통해 dp-alt mode를 지원하는 Fairydust 브랜치를 릴리스했습니다. 아직 부족한 부분도 많고, 문제점들이 내포되어 있지만 Asahi Linux가 USB-C를 통해 외장 모니터를 연결할 수 있다는 가능성을 보여주는 중요한 이정표입니다. 이 브랜치는 일종의 Experimental Kernel의 성격이기 때문에 해당 브랜치에 대한 사용자들의 요청과 지원을 하지는 않는다는 점을 분명히 하고 있습니다.

일반적으로 USB-C 포트는 고속 데이터 전송 규격인 Thunderbolt를 지원해야 하고, 보통은 Thunderbolt 지원 안에 dp-alt mode가 포함되곤 합니다. 하지만 현재 Asahi Linux는 dp-alt mode를 먼저 구현했을 뿐, 아직 Thunderbolt를 완벽히 지원하는 단계는 아닙니다. 어떻게 보면 반쪽짜리인 셈이죠. 워낙 사용자들의 요청이 많았던 기능이라 별도 브랜치로 먼저 제공하게 된 것 같은데, Thunderbolt까지 완벽하게 지원하기 전까지는 공식 릴리스에 포함하지 않을 것으로 보입니다. 그래도 오랫동안 이 기능을 기다려온 분들에게는 USB-C로 모니터를 쓸 수 있다는 것만으로도 큰 축복이 아닐까 싶네요.

두 번째로 언급하고 있는 것은 Apple Silicon M3와 관련된 것으로 m1n1에 대한 디바이스 트리와 Linux Kernel Patch에 대한 것입니다. 기본적으로는 NVMe, Wi-Fi, USB3 등 기본적인 동작과 관련된 부분들에서 성공적인 작업이 수행되고 있으며 조만간 M3를 지원하는 공식적인 릴리즈가 나올 수도 있음을 암시합니다. 그러나, M3 GPU 구조가 이전 M1/M2 세대와 많이 다르기 때문에 이를 하드웨어적으로 제어하기 위한 리버스 엔지니어링이 진행 중으로, 현재 M3 지원에서는 GPU 가속 기능을 사용할 수 없고 소프트웨어 방식의 렌더링만 지원하고 있습니다. 따라서 M3에 대한 공식적인 지원이 언제 발표될 것인지는 알 수 없다고 합니다. "사용이 가능하다"와 "공개가 준비가 되었다"는 것은 다른 차원의 문제이기 때문입니다. 일반 응용 프로그램의 수준이라면 사용이 가능한 상태에서도 릴리스를 할 수 있겠으나, Linux Kernel이 갖는 무게감과 중요성은 단지 가능하다는 수준으로는 릴리스를 할 수 없습니다. 그래도 다행인 점은 그리 오래 걸리지는 않을 것이라고 하네요.

세 번째 주제는 MacBook Pro 14/16에서의 120Hz 지원입니다. 이것은 이전 포스트에서도 알려 드렸지요. 120Hz 주사율 지원을 Apple에서는 ProMotion이라는 비즈니스 용어로 사용하지만, 일반적으로는 그냥 VRR(Variable Refresh Rate, 가변 주사율)라고 부릅니다. 가변 주사율을 엔드 유저(End User)가 사용하기 위해서는 H/W적으로 지원해야 함은 물론, 화면을 구성하고 이를 VRR 타이밍에 맞춰 모니터로 뿌려주는 Compositor(합성기)가 이를 지원해야 합니다. 일단 Asahi Team에서는 120Hz 고정 주사율을 지원하는 것으로 시작한 것 같습니다.

네 번째 주제는 Linux DCP(Display CoProcessor | Display Control Processor) 드라이버의 리팩토링과 관련된 것입니다. DCP는 단순한 하드웨어 컨트롤러가 아니라 RTOS(Real Time OS, 실시간 운영체제)와 9MB에 달하는 대용량 펌웨어를 가지고 독립적으로 구동되는 보조 프로세서입니다. 주 프로세서가 화면에 그릴 내용을 넘겨주면, 이를 받아 실제 디스플레이 패널에 맞게 변환하고 송출하는 복잡한 과정을 DCP가 담당하고 있죠. DCP는 구체적으로 여러 레이어(layer)를 하나로 합쳐서 화면에 표시해주는 기능을 수행하며, 감마 보정, 색 공간 변환 및 색온도 제어 등을 처리합니다. 화면의 주사율을 제어하고 백라이트의 밝기 및 전력 효율을 제어합니다. 내장 패널인 eDP, 외부 출력인 HDMI, DisplayPort와의 통신도 DCP가 담당합니다.

Asahi Team에서 DCP를 다루기 힘든 이유는 이 DCP가 macOS에 최적화된 독자적인 통신 프로토콜을 사용하고 있기 때문입니다. 독자 프로토콜이기 때문에 기술 문서가 공개되어 있지 않고, 따라서 이를 리버스 엔지니어링(Reverse Engineering)해야 합니다. 더욱이 macOS의 버전이 업그레이드될 때마다 DCP 펌웨어의 구조나 통신 방식이 바뀌기도 하기 때문에 더욱 어려운 분야라고 할 수 있습니다.

Wayland Compositor를 구현하고 있는 필자 입장에서도 초기에 Asahi Linux가 "마우스 포인터에 대한 H/W 지원"을 하지 않는다는 것을 알았습니다. 전통적으로 GPU는 3가지 유형의 플레인(plane)을 제공합니다. 일반적으로 윈도우나 배경 화면 등을 표시하는 프라이머리 플레인(Primary plane)과 커서를 표시하기 위한 커서 플레인(Cursor plane)이 있고, 그 밖에 다른 특별한 목적으로 사용하기 위한 오버레이 플레인(Overlay plane)이 있습니다. Apple Silicon 하드웨어는 리눅스 표준 인터페이스에서 바로 쓸 수 있는 형태의 커서 플레인을 노출하지 않습니다. 그래서 Linux에서는 마우스 포인터를 프라이머리 플레인에 소프트웨어적으로 렌더링 하여 합성하여 표시합니다. 이것은 기술적으로만 보면, 굉장히 불합리적인 결과를 초래하게 됩니다. 실제적인 화면의 변화는 없는데, 단지 마우스 포인터가 이동했다는 이유로 전체 화면을 다시 합성하여 뿌려 주어야 하기 때문입니다. 만일 커서 플레인이 별도로 존재한다면, 프라이머리 플레인은 그대로 이전 장면을 사용하고 물리적으로 분리된 커서 플레인만 리프레시(refresh)해서 둘을 오버레이 해서 뿌려 주면 됩니다. 즉, 현재 Asahi Linux에서는 커서 플레인이 없기 때문에 어쩔 수 없이 마우스 포인터가 움직이는 족족 다시 합성을 해야 합니다.

필자는 wlroots라는 라이브러리를 커스텀해서 Asahi Linux의 남은 오버레이 플레인을 커서 플레인으로 사용하고 있기는 하지만, 이는 오버레이 플레인을 낭비하는 결과를 초래합니다. 다행히도 지금은 비디오 H/W 가속 디코딩(decoding) 기능이 아직 Asahi Linux에 구현되어 있지 않기 때문에 오버레이 플레인을 커서용으로 전용하여 사용하고 있지만, 이 기능이 구현되어 Asahi Linux가 오버레이 플레인을 비디오 출력에 사용한다면 그때는 또 Compositor와 관련된 로직을 변경해야 합니다. (전체는 아니더라도 부분적으로라도...)

결국 지금까지 M1/M2에서 GPU 가속을 구현한 것이 1차적인 성과였다면, 앞서 언급한 DCP의 수많은 기능을 온전히 구현해내는 것이 2차 구현이자 완성판으로 가는 길일 것입니다. 지금 그들은 그 길을 묵묵히 걷고 있는 것 같습니다. 궁극적으로 지금까지 미진했던 디스플레이관련 기능들, 성능 최적화 및 비디오 하드웨어 디코딩이나 웹캠 처리 같은 목표를 향해서 말이죠.

- - - - - - - - -

필자도 각 분야에 대한 기술적인 이해도는 깊지 않습니다. 너무나 전문적인 분야들이기 때문에 실제적으로 Asahi Team이 이뤄 나가는 일들이 얼마나 중요하고 어려운지 가늠하기 어렵습니다. 그들이 수년에 걸친 노력으로 얻어낸 결과물은 단 몇 줄로 사용자들에게 공개될 뿐입니다. 그래서 일반 사용자들은 그 기술적 깊이와 구현의 난이도를 쉽게 이해할 수 없습니다. 관련된 일을 하거나 전공을 하거나 기술을 이해하고 있는 분들이라면 그 성과가 얼마나 큰 것인지를 알 수 있겠지요.

결론적으로 그들은 잘 해나가고 있고, 느리지만 사용자들이 원하는 것들을 하나하나 만들어 내놓고 있습니다. 그리고 그 속도는 점점 빨라지고 있는 것 같습니다. 이 소중한 결과물을 누리고 있는 한명의 사용자로서 늘 그들을 응원하고 감사한 마음을 전하고 싶습니다.

Asahi Linux, Kernel 6.18.10-402 업데이트 릴리즈, Fairydust 브랜치 6.18.10+ 업데이트

elsa in mac — Mon, 16 Feb 2026 10:44:33 +0900

2026년 2월 16일, Asahi Linux의 6.18 대의 첫 번째 kernel 버전이 공식 릴리즈 되었습니다.

이번에 릴리즈된 kernel 버전은 6.18.10-402 입니다.
현재 kernel 의 stable 버전은 6.18.10 이고, Mainline(최신) 버전은 6.19 이며, Next 버전은 7.0으로 4월 중순에 릴리즈 되는 것으로 예정되어 있습니다.

6.18 버전은 2025년 LTS(Long Term Support) Kernel로 지정되어 있기 때문에, 2027년 12월까지 유지보수가 유지됩니다.

Asahi Linux와 관련된 6.18.10 의 주요 내용은 다음과 같습니다.

1. USB-C 업스트림,
USB-C 드라이버가 6.18 , 6.19 버전의 사양을 따르도록 Upstream 되었으며, 향 후 더 안정적인 연결을 보장할 수 있게 되었습니다.

2. HDMI SUspend 버그 수정
MacBook Pro의 HDMI 포트가 절전모드(Suspend) 상태에서 복귀할 때 정상적으로 동작하지 않던 버그를 수정.

3. Battery Control
macOS 26.x 버전의 최신 SMC Firmware에 맞춘 배터리 관리로직을 적용.

4. Hibernation(최대 절전 모드) 방지
아직은 정상적으로 지원되지 않아 오동작을 유발하는 최대 절전 기능을 명시적으로 막아 시스템의 안정성을 높임.

5. 120Hz ProMotion 지원
MacBook Pro 14/16 모델의 내부 디스플레이에서 120Hz의 주사율 사용 가능해졌습니다. 하지만, 이것은 Static 즉, 고정 주사율이며, VRR(Variable Refresh Rate, 가변 주사율)을 지원하지는 않습니다. VRR Promotion을 지원하기 위해서는 DCP(Display co-processor)를 제어할 수 있어야 하는데, 애플의 독자규격이기 때문에 이에 대한 완벽한 분석 및 지원(가변 타이밍 제어 등)이 필요합니다. 따라서, VRR까지 지원하는 것은 아직 과제로 남아 있습니다. (외장 디스플레이는 적용 안됨)

6. Pixel Format 확장
YCbCr과 30-bit ARGB(10비트 컬러) 지원이 추가되었으며, 내부 디스플레이의 색공간이 sRGB로 표준화되었으며, 기존에 ICC 프로파일로 보정하던 방식에서 벗어나 Kernel level에서 더 정확 한 색상을 지원하도록 수정됨.

7. 모듈 통합
디스플레이 드라이버들이 하나로 통합 되었으며, 기존에 norch 관련 설정도 apple_dcp.show_notch 에서 appledrm.show_notch 로 변경됨.

이 밖에도 Apple Silicon M3 칩셋 지원을 위한 코드들이 일부 반영되기 시작했으며, 리녹스 표준 시스템 정보를 위한 SMBIOS 지원과 관련된 준비단계가 포함되었습니다.

기존 사용자 분들 중에, notch 영역을 숨기서나 사용하고 싶다면, kernel arg에 다음과 같이 추가하면 됩니다.

# 노치를 보이게 설정 (기본값 확인 필요)
sudo grubby --update-kernel=ALL --args="appledrm.show_notch=1"

다음으로, 120Hz를 지원하는 지의 여부를 확인하기 위해서는 다음과 같이 테스트를 하면 됩니다.

weston-simple-egl -f

weston-simple-egl CLI는 sudo dnf install weston-demo를 설치하면 사용할 수 있으며, 표시되는 log가 120 fps 수준(+/- x fps)으로 출력되는지의 여부를 확인하면 됩니다.

weston-simple-egl 사용 예

한편, dp-alt mode를 지원하는 experimatal kernel branch 인 "Fiarydust" 도 6.18.10+로 업데이트 되었습니다.

새롭게 추가되거나 개선된 기능은 없으며, 금번 6.18.10-402 Kernel 수준에서 dp-alt mode 만 제공하는 수준의 patch입니다.

Fairydust kernel의 빌드 및 사용법은 여기를 참조하시기 바랍니다.

AI 잘 사용하고들 계십니까 ?

elsa in mac — Fri, 13 Feb 2026 01:13:32 +0900

AI 혁명,
우리들의 일상에 갑자기 찾아온 AI 환경..
여러분들은 AI를 자신의 업무와 일상에서 많이들 사용하고 계신가요 ? 아니면, 아직도 사용을 안 하거나 사용을 망설이시나요 ?

이번 포스트에서는 새로운 AI 시대에 걸맞게 필자의 프로그래밍 개발에 최근 2달여 동안의 AI 사용에 대한 느낌과 생각을 간단히 적어 보고자 합니다.

개인적으로는 Gemini Pro를 구독하고 있습니다.
원래는 웹 브라우저에서 무료 Gemini 쳇봇과 터미널에서 무료 Gemini CLI를 사용하고 있었는데, 1월 초에 들어서 꽤 똑똑해진 Gemini가 실질적으로 하고 있는 일에 도움이 될 정도의 수준이 되었다고 판단하여 구독을 하게 되었습니다.

결론부터 말씀드리자면, 개인적으로는 프로그램 작업에 정말 상당한 도움이 됩니다.
현재 Wayland Compositor를 주력으로 만들고 있으며, 많이 사용하는 오픈 소스들을 커스텀하는 데 Gemini-cli와 antigravity를 이용합니다. 뭐랄까? 마치 꽤나 수준이 높은 프로그래머를 옆에 두고 협업하고 있다는 착각이 들 정도로 좋습니다. Gemini가 코드 어시스턴트(Code Assistant)로서는 아직 최고 수준이 아니라고 하던데도 이 정도이니...

새로운 기능 추가, 기존 기능의 개선 및 변경, 버그 수정 및 코드 최적화에 도움을 받고 있으며, 로컬 Git 서버인 Gitea를 CLI에서 거의 원격으로 사용할 수 있어서 업무의 효율성과 집중력이 굉장히 높아졌습니다.

예를 들어, 코드를 수정하고 나면 Gemini에게 수정된 코드를 분석하여 커밋을 해달라고 요청합니다. Gemini는 코드를 Diff하고 어떤 내용인지를 파악한 후, 커밋 제목과 상세 내용을 요약하여 커밋합니다.

문제가 발생한 경우, Gemini와 의견을 나누면 이슈를 자동으로 등록해 줍니다. 해결 방안을 찾아내면, 해당 Issue에 자동으로 Comment를 추가하고, 문제가 해결되면 해당 이슈를 자동으로 닫아 줍니다.

Gitea의 이슈를 자동으로 관리하는 예..

커밋이 5개 이상 추가되었을 때는 별도로 요구하지 않아도 자동으로 새로운 태그를 만들고 릴리스합니다. 물론 릴리스에 포함될 노트도 자동으로 마크다운 파일로 생성한 후, 릴리스가 완료되면 해당 파일을 제거합니다.

AI 도구를 사용하기 전과 비교해 본다면 거의 3배 이상의 효율이 나고 있으며, 이 정도면 유료 구독하는 게 전혀 아깝지 않다고 판단됩니다.

이것은 어찌보면 매우 사소한 AI 사용의 한 예일 것입니다 만, 이정도의 경험만으로도 네...
프로그래밍 경력 30년 만에 신세계를 맛보고 있습니다.

최근에 미국 소프트웨어 관련 기업들의 주가가 곤두박질을 치고 있다고 하던데, 그 이유를 알 수 있을 것 같네요.

https://github.com/andrewmd5/dawn
은 터미널에서 실시간 마크다운 렌더링 기능을 지원하는 문서 작성 도구 앱인데, Vim 에디터를 주력으로 사용하고 있기에 Vim 모드가 지원되지 않는 에디터를 사용하는 것이 개인적으로 꽤 불편합니다.

그냥 Neovim에서 문서를 작성하면 되지 않느냐 하겠지만, 글쓰기의 집중도를 높이기 위해서 이 app을 사용하는 것이 더 적당하다고 판단했습니다.

이 오픈 소스를 받아서 에디터에 Vim 모드를 지원하도록 수정하는 데는 불과 2시간 밖에 걸리지 않았습니다. AI의 도움 없이 과거처럼 직접 수정했다면 소스 코드 분석하고 Vim 관련 기능을 구현하는 데 몇 주일은 걸렸을 것입니다. 기능을 구현하고 나서 나도 모르게 입에서 "와~" 소리가 저절로 나오더군요.

필자는 AI가 생성하거나 수정하는 코드들에 대한 리뷰를 정말 철저하게 합니다. 아무리 기능과 성능 구현을 AI가 해냈다 하더라도 그 코드가 적절한지, 다른 문제를 유발할 수 있는지의 여부를 확인합니다. 그럼에도 불구하고 코드를 수정하거나 로직을 재수정하는 빈도는 대략 5% 수준입니다. 20번 코드를 생성하거나 수정했을 때, 의도와 다르거나 적정성 및 최적화 수준이 떨어져서 재수정한 경우는 20번 중 1번 정도 입니다.

프로젝트에서 AI의 협업을 지속하게 되면, 해당 코드에 대한 이해도가 점점 상승하여 뒤로 갈수록 프로그램에 대한 작업효율이 더 가속화 됩니다.

이런 경험을 하면서 몇 가지 생각들이 자연스럽게 떠오릅니다.

프로그램 개발과 관련된 회사에서 과연 신입 사원을 뽑을 이유가 있을까?
> 적어도 앞으로는 프로그램잉 언어나 개발도구에 대한 숙련도나 경험 보다는 AI 도구 사용 및 AI 도구를 활용한 개발 프로세스의 숙련도가 오히려 채용 여부를 가름하는 기준이 될 것입니다.

특정한 기능의 프로그램이 필요하면 만들어 쓰면 되지, 굳이 돈 주고 사거나 개발을 의뢰할 이유가 있을까?
> AI를 능숙하게 사용할 줄 아는 유저라면 규모가 큰 앱이 아닌 이상 그냥 만들어 쓸 듯합니다.
> App Store라는 것은 과거의 유물로 전략할 수 있습니다. 누구나 쉽게 app을 만들 수 있는 시대가 도래하고 점점 더 빠르게 만들고 디버깅 할 수 있게 발전할 수록 app을 만들어 사용하는 "개인화 맞춤형 app 시대"가 빠르게 다가올 것입니다. app을 개발하고 App Store에 올리는 것은 그저 아이디어를 공개하는 것일 뿐입니다.

app 이라는게 앞으로 필요하기는 할까 ?
> 궁극적인 AI의 미래는 앱이라는 게 필요 없을 겁니다.

- - - - - - - -

흠... 정말로 현타가 온다는 말은 이럴 때 쓰는 건가 봅니다.
지금도 이런데 1년 후, 2년 후에는 어떻게 바뀌어 있을까요?

적어도 필자를 포함하여 과도기의 현세대가 AI를 사용하면서 느끼는 감정은 "굉장하다"는 것이지만, AI 세대 이전의 경험이 없는 미래 세대들에게 있어 AI는 어떤 의미가 될까요?

아직 사용을 망설이거나 사용을 고려하지 않고 있다면, 지금부터라도 써보고 배우셔야 합니다 . 역사적으로 새로운 변화의 물결이 찾아왔을 때 그 변화가 더 이상 예전으로 되돌아갈 수 없을 만큼의 threshold를 넘어서는 뉴노멀인 경우, 현실을 직시하고 보다 빨리 적응하는 사람만이 살아 남을 수 있습니다.

AI 혁명은 과거의 가치들를 무참하게 파괴할 것입니다. 물론 새로운 일자리와 새로운 가치를 만들어 내겠지만, 문제는 속도 입니다. 적어도 인간이 인간의 힘으로 만들어낸 새로운 변화는 시작과 과도기, 성숙기를 거치기 까지 짧게는 수 년에서 수 십년이 걸려왔기에 대응할 수 었었지만, AI 시대는 그 속도가 너무나 빠르다는 문제가 있습니다. 그리고 그 속도는 기술고도화와 맞물려 점점 빨라지고 있습니다. 오늘 세상에 내 놓은 노력의 결실이 불과 몇 시간, 몇 일만에 쓸모가 없어지거나 새로운 경쟁 상대에게 역전되어 버릴 수 있다는 속도... 과연 우리는, 기업들은 그 속도를 견딜 수 있을까요 ?

asahi linux, apple silicon M3 지원 빨라지나 ?

elsa in mac — Mon, 26 Jan 2026 20:43:16 +0900

오늘 reddit에 Asahi Linux 관련하여 기쁜 소식이 또 하나 들려 왔습니다.

M3 mac에서 Asahi Linux로 부팅을 하고, KDE Plasma를 실행한 스샷이 올라왔습니다. !!!

아마, 개발진 중 한 분이 올리신 것 같은데, 기본적으로 내장 SSD, 디스플레이, 키보드, 트랙패드가 지원되지만 LLVMpipe 즉, Software Rendering으로 실행한 것이라고 합니다. GPU 지원은 아직 안된다는 말이겠지요. 와.. 기대 이상으로 Asahi Team이 빠르게 작업하고 있는 것 같습니다.

Asahi Linux 공식 Kernel Github에 가 보면, 6.18.x , 6.19.x 그리고 6.20.x 까지 단계를 나눠 진행을 하고 있는 것으로 보이며, Thunderbolt에 대한 코드들이 올라오는 것을 보면, 2026년 올해, Asahi Linux에 많은 진전이 있을 것 같아 보이네요..

요즘 RAM 값이 뭐 컴퓨텨 한 대 값이던데, 집에 놀고 있는 구형 M3 mac 이 있고, Linux를 사랑하시는 분이라면 중고로 팔기 보다 추 후에 Linux 머신으로 사용하시면 좋을 것 같습니다.

Asahi Linux, DP Alt Mode를 지원하는 Kernel branch "Fairydust" 공개, kernel 빌드 방법 및 적용 결과

elsa in mac — Wed, 31 Dec 2025 13:15:20 +0900

본 포스트는 Fedora Asahi Remix를 기반으로 작성되었습니다.

2025년 12월 30일, 39C3에서 Asahi Team의 개발 멤버인 svan이 Asahi Linux - Porting Linux to Apple Silicon이라는 주제로 발표가 있었습니다. (이전 포스트 참고)

그리고, DP alt-mode(DisplayPort alternative mode)가 적용된 kernel source 코드가 공개되었습니다. 아직은 개발자 버전 소스코드라고 할 수 있겠죠.. 코드명은 Fairydust 입니다. 작명 센스가 돋보입니다.

Update : 2026.04.06
- fairydust 가 6.19.11+ 로 업데이트 되었습니다. 아래 글 내용에서 버전이 불일치 하는 부분들은 참고 하시기 바랍니다. (6.18.4+ 가 사용되는 부분들은 6.19.11+로 대신 사용해야 합니다.)

일단 결론적으로 해당 소스코드를 받은 후, 빌드하여 적용해 봤는데요.. USB-C 포트와 연결된 모니터가 잘 작동합니다. 아래는 결과입니다.

Kernel 버전은 6.18.4+ 로 표시가 됩니다.

결론적으로 6.18.x 정식 버전이 릴리즈 되면, 거의 100% USB-C 포트를 통한 외부 모니터를 연결하여 사용할 수 있을 것으로 보입니다. MacBook에서 Asahi Linux를 사용하는 사용자들에게는 정말 반가운 소식이 아닐 수 없습니다.

아래는 해당 kernel을 빌드하고 설치하여 사용하는 과정을 정리한 것입니다.

단, 아래의 절차에 따라 kernel을 빌드하고 사용하시기 전에 알아 두어야 할 점은 아직은 DP alt-mode를 사용할 수 있다는 수준이지, 일반 사용자들이 편리하게 사용할 수준은 아닙니다. 예를 들어, 부팅을 하면 화면이 들어오지 않습니다. 모니터를 껐다가 다시 켜야지만 화면이 들어 옵니다.(USB-C 케이블을 뺐다가 다시 꽃는 것이 아님) 이런 불편한 점이 있다는 점을 감안하고 검토하시기 바랍니다.

따라서, Kernel을 수정, 빌드, 설치에 경험이 없는 사용자라면 직접 해당 kernel을 빌드하고 사용하는 것이 대단히 위험할 수 있습니다. 단지 참고 사항으로만 보시기를 추천합니다.

Kernel 빌드 절차

우선, 필자는 M1 mac mini (2020 late, 8GB/256GB)의 기본 모델을 사용하고 있습니다. 아마 Asahi Linux를 사용할 수 있는 mac 중에 가장 기본 모델이라고 해도 무방할 것입니다.

일단, kernel을 빌드하여 사용하려면, 사용할 수 있는 여유 저장공간이 10GB 이상 남아 있어야 합니다. 소스코드 자체가 크고, 빌드과정에서 생성되는 object 파일 등의 중간 산출물이 거의 많기 때문입니다. 필자의 경우에는 Asahi Linux에 할당된 내부 저정공간은 60GB 이기 때문에, 대부분의 큰 작업은 외장 SSD(512GB)에서 합니다. Memory는 8GB 이상이어야 하며, 필자처럼 8GB 메모리라면 반드시 swap을 사용해야 합니다.

Kernel을 빌드하고 적용해 본 경험이 없는 사용자라면, 이 과정이 꽤나 어려울 수 있습니다. 진행과정에 대한 스샷이나 결과가 본인이 사용하는 mac에 따라 조금씩 상이할 수도 있다는 점을 유념하여 보시기 바랍니다.

우선, 빌드 환경은 kernel 6.17.12-400 하에서 진행했습니다.

그럼, 빌드 절차를 하나하나 알아봅니다.

우선, kernel 빌드에 필요한 의존성 패키지들을 설치해야 합니다.

sudo dnf groupinstall "Development Tools"
sudo dnf install git ncurses-devel flex bison openssl-devel elfutils-libelf-devel
sudo dnf install rust rust-src bindgen-cli clang llvm

asahi linux의 GPU 드라이버는 Rust로 작성되어 있기 때문에, rust 관련 패키지들도 설치가 되어 있어야 합니다.

패키지가 다 설치되었다면, 이제 fairydust kernel source를 받아야 합니다.

# 기본 소스코드 clone 
git clone -b fairydust --single-branch --depth 1 https://github.com/AsahiLinux/linux.git

# 소스코드 root로 이동
cd linux

다음으로 현재 사용 중인 kernel의 config 파일을 복사해야 합니다.
이 부분은 좀 신중해야 합니다. 만일 Fairydust의 버전과 현재 설치되어 사용중인 버전이 동일하다면 가장 좋습니다. Fedora는 현재 사용되는 가장 최근의 버전부터 이전 2개의 버전까지 포함하여 총 3개의 버전을 관리 합니다.

만일 Fairydust의 버전이 이 3개의 버전 중에 하나와 동일하다면 config 파일은 /lib/modules/<설치 kernel 디렉터리> 안에 있습니다. 그리고 이 config를 사용하면 됩니다.

위의 스샷을 보면, /lib/modules/6.18.10-402 버전의 폴더내에 config가 있는 것을 알 수 있습니다. 이 config는 현재 사용자가 사용하는 해당 kernel 의 config 입니다.

/boot 디렉터리에도 해당 kernel 의 config가 있지만, 이것은 보다 광의적인 옵션들을 포함하고 있습니다.

# Fairydust와 동일한 커널이 있다면
cp /lib/modules/<kernel 디렉터리>/config .config

# 만일 없다면 /boot 디렉터리의 config를 .config로 복사
cp /boot/config-6.17.12-400.asahi.fc43.aarch64+16k .config

만일, Fairydust의 버전이 업데이트 되었다면 예를들어, .config가 6.18.10 에서 사용된 config 였고, 현재 버전이 6.19.5 라면, 내부적으로 새롭게 추가된 kernel 옵션들이 있을 수 있습니다. 이 경우 업그레이드된 버전의 config 옵션을 merge 해 주는 것이 좋습니다.

scripts/kconfig/merge_config.sh -m .config arch/arm64/configs/asahi.config

다음으로 make menuconfig를 실행하여 Asahi Linux관련 GPU driver의 활성 여부를 확인합니다. 이 절차는 단지 확인만 하는 절치 입니다. /lib/moduels/<커널 버전>/config 를 사용할 수 있다면, 건너뛰어도 됩니다.

# menuconfig 실행 
make menuconfig

터미널에서 make menuconfig 를 실행한 장면

General setup -> Rust support 를 선택해 줍니다. 해당 라인에서 space키를 누르면 [ ] 가 [*] 로 바뀌게 됩니다. 그럼 선택이 된 것이죠. 변경을 완료했으면, tab키를 눌러 선택바가 Save에 가게 한 다음 Enter키를 눌러 .config에 저장합니다. 참고로, 만일 rust와 관련된 빌드 패키지가 설치되어 있지 않다면 해당 옵션은 보이지 않습니다. 당연히 Rust로 작성된 Driver들도 옵션에서 보이지 않게 됩니다.

save 를 선택한 경우의 스샷

저장을 했으면, <Exit> 를 선택하여 이전 화면으로 나갑니다. 그리고, 초기 메뉴에서 Device Drivers ---> Graphics support ---> Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) ---> Asahi (DRM support for Apple AGX GPUs) 의 옵션을 [ ] 에서 [ * ] 로 변경해 줍니다. [ ] 에서 space를 한번 누르면 [M]으로 바뀌고 다시 space를 누르면 [*] 로 바뀌게 됩니다.

다음으로, Asialinux Document의 kernel config 설명에 의하면, NVME_APPLE과 SPI_HID_APPLE_OF 항목은 안정성을 위해 kernel에 내장하는 것이 좋다고 권고하고 있습니다. 이를 위한 설정은 다음과 같습니다.

우선, NVME_APPLE을 설정하기 위해서는 Device Drivers --> SOC (System On Chip) specific Drivers --> Apple SoC drivers --> Apple SART DMA address filter의 옵션을 * 로 변경합니다. 그리고, 이어서 Device Drivers --> NVME Support --> Apple ANS2 NVM Express host driver의 옵션을 역시 *로 변경합니다.

다음으로, Device Drivers --> HID bus support --> SPI HID support --> HID over SPI transport layer for Apple Silicon SoCs 의 옵션을 역시 *로 변경합니다.

이제 <Save>를 선택하여 .config에 저장을 해 줍니다. 이제 <Exit> 를 연속으로 선택하여, menuconfig를 완전히 종료해 줍니다.

위의 옵션을 굳이 .config 파일에서 수정하지 않고, make menuconfig를 이용하여 수정하는 이유는 * 즉, kernel built-in 으로 변경할 때, 해당 옵션의 Depends on 항목들의 조건이 함께 부합해야 하기 때문입니다. 이 조건들이 맞지 않을 경우에는 .config에 해당 항목을 =y 로 변경한들 실제적으로는 변경이 되지 않은 것과 마찬가지 입니다. 이러한 이유로 make menuconfig를 통해 실제 변경이 될 수 있는지의 여부를 직접 확인하고 변경해야 합니다.

다음으로 아래와 같이 빌드 옵션을 disable 하고 업데이트된 .config를 이용하여 빌드 설정을 업데이트합니다.

# Debug 관련 기능을 off 
scripts/config --disable DEBUG_INFO 

# BTF(BPF Type Format) 생성하지 않음. 
scripts/config --disable CONFIG_DEBUG_INFO_BTF

# SBAT(Secure Boot) 관련 ZBOOT 비활성화 
scripts/config --disable CONFIG_EFI_ZBOOT


# 설정을 적용
make olddefconfig

make olddefconfig를 실행하면, 대략 아래와 같은 결과가 출력되게 됩니다. (아래 정보는 실제와 일부 상이할 수 있음.)

> make olddefconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/confdata.o
HOSTCC scripts/kconfig/expr.o
LEX scripts/kconfig/lexer.lex.c
YACC scripts/kconfig/parser.tab.[ch]
HOSTCC scripts/kconfig/lexer.lex.o
HOSTCC scripts/kconfig/menu.o
HOSTCC scripts/kconfig/parser.tab.o
HOSTCC scripts/kconfig/preprocess.o
HOSTCC scripts/kconfig/symbol.o
HOSTCC scripts/kconfig/util.o
HOSTLD scripts/kconfig/conf

#
# configuration written to .config
#

이제 kernel 및 kernel module을 빌드합니다.

make -j8

팔자의 m1 mac-mini는 총 8개의 CPU core가 있으므로, -j8을 사용했습니다. 사용하는 mac의 Core수가 다를 수 있으니 확인 후 적절한 core 수로 정의해 주면 됩니다.

kernel의 소스와 관련된 kernel modules들이 굉장히 많기 때문에 대략 20분 이상의 시간이 소요됩니다. 정상적으로 빌드가 완료되었다면..

정상적으로 빌드가 되었는지 확인

위의 스샷처럼 arch/arm64/boot 디렉터리 안에 Image와 Image.gz 파일이 생성된 것을 확인할 수 있습니다.

빌드가 잘 되었다면, 이제 설치를 해야 합니다.

설치는 빌드와 마찬가지로 linux (소스의 root) 디렉터리에서 합니다.

# kernel 모듈 설치 
sudo make INSTALL_MOD_STRIP=1 modules_install

kernel 모듈은 디버깅 심벌을 제거하기 위해 STRIP 옵션을 주어 위와 같은 명령으로 실행합니다. 결과는

스샷처럼 /lib/modules/ 디렉터리 밑에 6.18.4+ 라는 디렉터리가 생성되어 있고 그 안에 빌드한 kernel modules들이 포함되어 있는지를 확인하면 됩니다. 용량은 디버깅 심벌을 제거했으므로 대략 200 ~ 400MB 정도가 될 것입니다. (참고로 디버깅 심벌을 제거하지 않고 설치하면 6GB가 넘는 어머어마한 용량이 됩니다.)

다음으로 DTB(Device Tree)를 설치해야 합니다. 새로운 Kernel에는 기존 Kernel에는 없었던 Device 항목들이 추가되었을 수 있기 때문에, 커널이 H/W를 인식하기 위한 DTB 파일이 반드시 필요합니다.

# DTB 설치
sudo make dtbs_install INSTALL_DTBS_PATH=/usr/lib/modules/6.18.4+/dtb

#vsdo 설치 
sudo make vdso_install INSTALL_VDSO_PATH=/usr/lib/modules/6.18.4+/vdso

자 이제 마자믹으로 kernel 이미지를 설치합니다.

sudo make install

sudo make install을 실행하며, 관련 스크립트가 자동으로 /boot 디렉터리 내에 Kernel image를 복사하고, initramfs를 생성하며, GRUB 메뉴를 업데이트하여 새 kernel 항목을 추가하게 됩니다.

sudo make install이 완료된 후의 /boot 디렉터리 내부 구성은 아래와 같습니다. sudo

dtb는 /lib/modules/6.18.4+/dtb 디렉터리로 연결되며, initramfs-6.18.4+.img 가 생성되어 있는 것을 알 수 있습니다. symver 이나 system.map 은 필수요소는 아닙니다. vmlinuz-6.18.4+는 kernel 이미지입니다. 추가되었지요.

다음으로 dtb에 대한 symbolic link를 확인합니다.

cd /boot
sudo rm -Rf ./dtb
sudo ln -s /usr/lib/modules/6.18.4+/dtb ./dtb

그리고,마지막으로 사용된 .config 파일을 /boot 디렉터리에 복사합니다.

cd /boot
sudo cp -Rf <linux kernel source path>/.config config-6.18.4+

cd /lib/modules/6.18.4+
sudo cp -Rf <linux kernel source path>/.config config

config를 복사하는 이유는 어떤 app의 경우 config의 내용을 참조하고 kernel의 특정 옵션 설정이 어떻게 되어 있는가에 따라 정상실행 여부를 판단하는 경우가 있기 때문입니다.

다음으로, GRUB에 추가되었는지를 확인해 봅니다.

제일 상단에 Fedora Linux Asahi Remix (6.18.4+) 43 (Forty Three) 가 추가된 것을 확인할 수 있고, sudo grubby --default-kernel 명령을 사용하면, 현재 설정된 기본 부팅 kernel이 어떤 것인지를 확인할 수 있습니다.

원래는 기본 부팅 항목을 6.18.4+로 변경해야 하지만, 만일을 대비하여 일단 기본 부팅 항목은 기존의 6.17.12로 남겨 둡니다.

나중에 모든 검증이 끝나고 그대로 사용할 수 있겠다는 확신이 든다면.. default kernel을 변경하면 됩니다.

# default kernel 변경 
sudo grubby --set-default /boot/vmlinuz-6.18.4+

이것으로 fairydust kernel의 빌드 및 설치는 모두 끝난 것입니다.

이제, rebooting을 해서 kernel 6.18.4+로 부팅을 해 보면 됩니다. (아래 스샷은 fairydust 6.18.2+ 일때의 스샷임)

부팅을 해 보니, GRUB 메뉴에서 위의 스샷과 같이 6.18.4+가 표시되는 것을 알 수 있습니다. 해당 kernel을 선택하여 부팅을 해 줍니다.

유의사항

먼저, 아직 U-boot 나 GRUB 선택 상태에서는 USB-C 모니터를 지원하지 않습니다. 아직은 kernel에서만 지원을 하기 때문에 kernel 부팅이 완료되는 시점에서 USB-C 모니터에 화면이 표시됩니다. 따라서, kernel이 정상적으로 동작하는 것을 확인했다면.. GRUB default kernel을 6.18.4+로 변경하는 것을 추천합니다.

믈론, default kernel로 변경을 하더라도 글 도입부에서 언급했듯이, kernel 부팅이 완전히 완료된 시점 이 후에 모니터 전원을 Off -> On 해야 화면이 들어 오는 수준입니다. 필자는 모니터가 한 대 밖에 없기 때문에 HDMI + USB-C 로 듀얼 모니터 환경을 테스트 하지는 못했습니다. 이 경우에는 또 어떤 문제가 있을지 확인이 안되어 있다는 점도 고려해야 하며, MacBook 등 기타 다른 m1/m2 mac에서는 어떤 결과가 나올지도 확인이 되지 않았습니다.

mac mini 의 경우 두 개의 USB-C 포트가 있습니다. 하나에 모니터를 연결하고, 다른 나머지 한 포트에 USB-C hub 를 연결하고, 이 USB-C hub에 키보드와 마우스를 연결해서 사용하고 있는데, 부팅 중에 USB-C hub가 연결이 끊기는 경우도 있습니다. 이 때는 우선 USB-C 모니터를 사용 가능한 상태로 만든 후, USB-C hub 를 뺐다가 다시 연결하니 정상 동작했습니다.

또한, dp-alt mode 와 관련된 commit의 내용을 확인해 보면, USB-C 외부 모니터를 연결할 USB-C 포트가 mac 모델마다 정해져 있는 것 같습니다. 아래를 참고 하시기 바랍니다.

DP alt mode for Mac Mini M2 Pro
--------------------------------
the blessed port is the back right middle port 
(second closest USB-C port to the power connector).


DP alt mode for Mac Studio
--------------------------
the blessed port is the back left middle port
(second closest USB-C port to the power connector).


Blessed dp-altmode port is front left port on j314/j316/j414/j416.


Enable DP alt mode for the front left USB-C port of Macbook Air 13 
(M2,13/15-inch) and Macbook Pro (M2, 13-inch).
Can't easily enabled on the M2 Mac Mini since dcpext is used for the
HDMI port and dcp bringup is troublesome.


Enable DP alt mode for all M1 devices:
-------------------------------------
Mac Mini (M1): USB-C port next to the HDMI port
Macbook Pro (M1, 13-inch): front left USB-C port
Macbook Air (M1, 13-inch): front left USB-C port
iMac (M1, 2 USB-C ports): back left USB-C port
iMac (M1, 4 USB-C ports): back right middle USB-C port

필자의 경우에는 wayland compositor를 직접 만들어서 사용하고 있는데,

보는 바와 같이 /dev/dri 에 card0, card2, renderD128 장치가 있는 것을 알 수 있습니다. 기존 6.17에서는 card1, card2, renderD128 이였죠. 따라서, 사용하시는 WM 환경 설정에서 이 부분과 관련된 설정이 있다면, 이 설정을 변경해야 한다는 점도 살펴야 합니다. 장치명도 기존에는 USB-C로 연결할 경우 DP-1 으로 표시됩니다. 특정 설정에서 HDMI-A-1 등으로 설정된 것들이 있었다면, 이들 설정도 모두 DP-1으로 변경해야 정상적으로 동작한다는 점도 고려해야 합니다.

update : 2026.01.10
- fairydust가 6.18.4로 업데이트 되면서, /dev/dri 가 card0, card2, renderD128 에서 card1, card2, renderD128로 변경됨.

위의 스샷은 wayland compositor 실행 시의 debug log 인데요, 보면, HDMI-A-1 과 DP-1 두 개가 detection 되는 것을 알 수 있습니다. 기존 kernel에서는 HDMI-A-1 1개만 확인 되었었습니다.

또 다른 확인 방법은

위의 스샷과 같이 /sys/class/drm 에서 ls를 해 보면, DP-1 이 보여야 합니다.

- - - - -

그래도, 예상과는 달리 공개된 source가 꽤나 안정적이고, 여타 다른 부분에는 별 문제가 없다는 점이 인상적이지만 6.18 정식 버전이 릴리즈 되더라도 이 기능이 포함될지의 여부는 아직 미지수 입니다.

사실 2025년 올 해 기대했던 업데이트는 아니였는데, 극적으로 2025년 마지막날 이렇게 기대감을 체우게 되었네요. 굉징히 기쁘고, Asahi team 의 노고에 감사의 맘을 전하고 싶군요..

Asahi Linux, Apple Silicon M3 macbook 지원되나 ?

elsa in mac — Tue, 30 Dec 2025 07:21:17 +0900

2025년 12월 30일... 오늘자 Asahi Linux Reddit에 M3 MacBook 에서 Asahi Linux를 구동하는 스샷들이 올라왔습니다.

지난 포스트에서 공지한 바, Chaos Cummincation Conference(39C3) (youtube channel link) 의 마지막 날(4일차, 12월 30일) 에서 Asahi Team 맴버인 Svan 이 Hardware 분야에서 Asahi Linux - Porting Linux to Apple Silicon 이라는 주재로 발표를 하게 됩니다.

이번 발표에서는 차기 Porting 목표인 M3/M4/M5 에 대한 내용이 일부 발표가 될 예정인데요.. 이 발표에 사용될 내용이 일부 공개 된 것입니다.

지난 몇 주 동안 M3 및 M3 Pro 하드웨어에 대한 초기 설정 작업을 진행해 왔으며, 일단 Asali Linux 의 초기 포팅은 완료된 것으로 보입니다. 몇몇 해결되지 않았거나 최적화가 미흡한 부분들이 있기는 하다고 하나, M3에서 Linux를 구동할 수 있게 되었다는 소식은 반가운 소식이 아닐 수 없습니다.

보다 구체적인 내용은 해당 발표에서 언급이 있을 것 같군요.. 아직은 발표 영상이 올라오지 않았는데요.. 올라오는데로 또 새로운 소식을 전해 드리겠습니다.

- - - - - - -

UPDATE: 2025.12.30 22:40분, 39C3 발표 영상이 등록되었습니다. 아래 링크를 클릭하시면 발표 영상을 보실 수 있습니다.

https://media.ccc.de/v/39c3-asahi-linux-porting-linux-to-apple-silicon#t=910

Asahi Linux - Porting Linux to Apple Silicon

In this talk, you will learn how Apple Silicon hardware differs from regular laptops or desktops. We'll cover how we reverse engineered t...

media.ccc.de

발표는 Asahi Linux의 초기 프로젝트 시작단계 부터 어떤 Reverse Engineering 과정을 거처 Linux를 포팅했는지의 과정과 특히 USB와 관련부분이 왜 어려운지를 설명합니다.

그리고, 오늘의 깜짝 공개..!!! DIsplay 항목을 보면, USB-C 를 통해 외부 모니터를 연결한 것을 확인할 수 있습니다. 네... DP Alt Mode가 된다는 것이죠.. 와우 ~

USB 1/2 에 이어 USB3가 Upstream 되었기 때문에, USB 3.1(10Gbit/s) 과 USB 3.2 (20Gbit/s)를 지원할 것으로 예상됩니다. USB4인 thunderbolt 는 아직 잘 모르겠네요. kernel 버전이 6.18 인것을 확인할 수 있습니다. 아마 추가적인 보완 작업을 거쳐 6,18 이 공식 릴리즈되면, 사용여부를 확실하게 확인해 볼 수 있을 것 같습니다.

발표 끝에 M3/M4/M5에 대한 작업 및 계획에 대해 짧게 설명하고 있는데요, M3 포팅은 현재 Early Stage 단계로 GPU 가속은 아직 구현되지 않았고, 2026년에는 좀 더 구체적인 성과가 나올 수 있을 것 같다고 합니다. M4/M5는 아직 구체적인 일정은 없는 것 같군요.

이미지 화질개선 도구 - image upscaler (CLI)

elsa in mac — Sat, 20 Dec 2025 11:51:10 +0900

본 포스트는 Fedora Linux를 기준으로 작성되었습니다.

이번 포스트에서는 Vulkan API를 기반으로 local 환경에서 AI model을 사용하여 Image의 해상도를 높이고 화질을 개선하는 Image Upscaing 도구인 waifu2x ncnn Vulkan과 Real-ESRGAN에 대해 알아보겠습니다.

Waifu2x ncnn Vulkan

waifu2x ncnn Vulkan 은 이름에서 알 수 있듯이 Vulkan API 기반의 ncnn을 이용한 Upscaler입니다.

ncnn은 중국의 텐센트(Tencent)에서 개발한 모비일 및 임베디드 기기에 최적화된 고성능 신경망 추론 프레임워크로, nihui convolution neural network의 약자이며 우리말로 하면, "개발자 nihui가 만든 합성곱 신경망 네트워크"라는 의미가 됩니다.

기본 설계 단계부터 모바일 기기에서 사용할 목적으로 구현되었기 때문에 여타 다른 라이브러리에 의존하지 않고, 크로스 플렛폼을 지원하며, CPU 혹은 GPU를 선택적으로 사용할 수 있습니다. 덕분에 Processing Power가 높지 않은 일반 데스크 탑 수준에서도 image Processing을 비교적 빠르고 효과적으로 처리할 수 있습니다.

우선, 어느 정도 수준의 결과물을 뽑아낼 수 있는지 결과를 보도록 하겠습니다.

원본 이미지

upscale 결과 (2x)

위의 스샷을 보면, 원본 대비 2배로 업스케일된 결과물을 비교할 수 있습니다. 사진의 원본은 700x1000의 jpg 이미지이며, mac mini (2021) 에서 변환 시 대략 2초 정도가 걸립니다.

2배로 업스케일링을 한 결과이므로 이를 다시 원본 이미지 사이즈로 변경하면, pixel의 가독성이 높아지고, 노이즈가 제거되는 화질 개선 효과 때문에 보다 깨끗한 이미지를 얻을 수 있습니다.

좌측) 원본, 우측) 업스케일링 결과

Real-ESRGAN

Real-ESRGAN은 Upscaling과 함께, 열화된 이미지를 복원하는데 특화된 딥러닝 모델입니다. ESRGAN(Enhanced Super-Resolution GAN)이 특정 수학적 공식으로 만들어진 데이터 셋에서만 잘 작동하는 것과 달리 Real-ESRGAN은 현실 세계의 보다 불특정 한 이미지를 깨끗하게 복원하는 것을 목표로 구현된 모델입니다. 즉, 사진 등에 포함된 노이즈, 블러, 이미지 압축에 따른 노이즈등이 복합적으로 섞여 있는 것들을 High-Order Degration Model을 도입하여 매우 현실적인 수준에서 복원하는 것입니다.

특히, REal-ESRGAN에서 사용되는 animation video 모델은 에니메이션 이미지 복원에 특화되어 있습니다. 따라서, ncnn 보다 좀 더 깨끗하고 선명한 upscaling 결과를 보여 주는 것을 확인할 수 있습니다. 확대를 해 보면, 아래와 같습니다.

좌측) ncnn , 우측) Real-ESRGAN

아래는 다른 예시 입니다.

위로부터 아래로, 원본 -> ncnn -> real-esrgan

깨끗하긴 하지만, 일부분 음영이나 자연스러운 붓터치가 단순화되고 어느정도 왜곡되어 있다는 것을 알 수 있습니다. 대신 노이즈나 저수준의 해상도가 깔끔히 사라진 것을 알 수 있습니다.

대신, Model이 에니메이션 이미지에 특화되어 있기 때문에 일반 사진을 대상으로 upscaling을 했을 경우에도 결과가 애니메이션 같은 결과를 내어 줍니다.

굉장히 깔끔한 결과를 보여 주지만, 사진이라는 느낌은 많이 사라지고, 마치 사람이 그린 그림 같다는 느낌을 줍니다. 하지만, 이런 효과를 의도한 것이라면 결과는 만족스러울 것입니다.

원본 이미지의 상태가 좋을수록 결과물의 품질도 비례합니다.

빌드 방법

Real-ESRGAN은 ncnn 을 기반으로 만들었기 때문에, 빌드 방법은 동일합니다.

ncnn부터 보면,

git clone https://github.com/nihui/waifu2x-ncnn-vulkan.git
cd waifu2x-ncnn-vulkan
git submodule update --init --recursive

mkdir build
cd build

# macOS에서 Vulkan API를 사용하기 위해 MoltenVK 라이브러가 필요하며. 
# 프로그램 실행 시, 의존성을 실행 파일내에 내장. 
cmake -DUSE_STATIC_MOLTENVK=ON ../src

# macOS가 아닌 경우 
cmake ../src

# 빌드
cmake --build . -j 4

맨 마지막 build에서 -j 는 빌드할 core 수 이므로, 자신의 컴퓨터의 core 수에 맞게 조정하거나 그냥 4로 빌드하면 됩니다.

Real-ESRGAN은 절차는 동일하지만, git clone의 소스만 아래와 같이 변경하면 됩니다.

git clone https://github.com/xinntao/Real-ESRGAN.git

빌드가 성공적으로 완료되면, build 디렉터리 내에 waifu2x-ncnn-vulkan 실행파일이 생성됩니다. 파일이름이 길기 때문에 upscaler 같이 다른 이름으로 바꿔 쓰는 게 좋습니다. 그리고, 실행 파일도 PATH 디렉터리로 복사해서 어디서든 실행할 수 있도록 해 줍니다.

사용 방법

upscaler를 사용하려면, model 파일이 필요 합니다.

source 디렉터리애 model 이라는 디렉터리가 있는데, 이 디렉터리를 ~/.local/share/upscaler 와 같이 적당히 참조하기 쉬운 위치로 복사를 해 줍니다.

원본 image가 test.png 이고 이 파일을 upscaling 하고자 한다면, 다음과 같이 명령을 하면 됩니다.

# 원시파일         : test.png 
# 결과파일         : test_upscaled.png 
# scale           : 2배 
# 노이즈 감쇠      : level 2
# 적용할 모델 path : ~/.local/share/upscaler/models-cunet
upscaler -i test.png -o test_upscaled.png -s 2 -n 2 -m ~/.local/share/upscaler/models-cunet

필자의 경우에는 yazi file manager를 사용하고 있는데, yazi에 설정을 추가하면 보다 쉽게 사용할 수 있습니다. 아래는 yazi에 적용했을 경우의 사용 예시입니다.

yazi에서 image preview도 확인할 수 있기 때문에 사용하기 좋습니다. yazi에 적용하기 위해서는 아래와 같이 ~/.config/yazi.toml 설정파일을 수정합니다.

open-image = [
	{ run = 'simg %s1',         desc = "Open(simg)",               for = "linux" },
	{ run = 'run-swaybg %s1',   desc = "change background(awww)",  for = "linux" },
	{ run = 'upscaler_cmd %s1', desc = "upscaling(2x)",            for = "linux" },  # <---
]

위의 예시를 보면, upsclaer_cmd %s1 이 부분을 추가하면 됩니다. 그러면, yazi 실행 후 해당 이미지 선택상태에서 o(알파벳 O) 키를 누르면, 위의 예에서와 같이 어떤 옵션으로 image 파일을 열지 선택하는 contextual menu가 뜨게 됩니다. 거기서 upscaling(2x)를 선택하면 내부적으로 upscaler_cmd [이미지 path] 가 실행되게 됩니다.

upsclaer_cmd는 bash shell script로 아래와 같습니다.

#!/bin/bash

# 인자가 없는지 확인
if [ -z "$1" ]; then
  echo "사용법: $0 <입력파일>"
  exit 1
fi

# 입력 파일명과 확장자 분리
input_file="$1"
filename="${input_file%.*}"
extension="${input_file##*.}"

# 출력 파일명 생성 (예: test_upscaled.png)
output_file="${filename}_upscaled.${extension}"

# 모델 경로 설정
model_path="$HOME/.local/share/upscaler/models-upconv_7_anime_style_art_rgb"

# 명령 실행
upscaler -i "$input_file" -o "$output_file" -s 2 -n 2 -m "$model_path"

다음은 Real-ESRGAN의 사용방법에 대해 알아 봅니다. Real-ESRGAN도 빌드를 하면, build 디렉터리에 realesrgan-ncnn-vulkan 이라는 실행파일이 생성됩니다. 역시 이름을 적당히 수정하여 PATH 디렉터리에 복사해 주면 됩니다. real-esrgan 도 모델이 있어야 사용할 수 있는데, Github page에 가보면, 아래와 같이 portalble file를 다운로드할 수 있는 링크가 있습니다.

windows / Linux / macOS 이렇게 각 OS에 대한 링크가 있지요 ? 여기서 해당되는 링크를 클릭하면 다운로드를 합니다.

.zip 압축파일을 해제하면, 내부에 models 라는 폴더가 보입니다. 해당 model 디렉터리 자체를 역시 ~/.local/share/upscaler 디렉터리 밑으로 복사합니다.

필자의 경우에는 upscaler-realesrgan 이라고 실행 파일명을 변경했습니다.

옵션을 보면, ncnn 과 살짝 다릅니다. -n 옵션이 denoise가 아니고, model-name 입니다. esrgan의 경우에는 models라는 하나의 폴더 내에 여러 model이 다 포함되어 있기 때문에, 어떤 모델인지를 식별하는 식별자가 필요합니다. 사용 예는 그래서 다음과 같습니다.

# 원시파일         : test.png 
# 결과파일         : test_upscaled.png 
# scale           : 2배 
# 적용할 모델 path : ~/.local/share/upscaler/models-cunet
# model name      : realesr-animevideov3
upscaler-realesrgan -i test.png -o test_upscaled.png -s 2 -m ~/.local/share/upscaler/models-cunet -n realesr-animevideov3

역시, yazi에 넣고, shell scipt를 만들면 쉽게 사용할 수 있습니다.

- - - - - - - -

이번 포스트에서는 Chat-GPT나 Gemini 같은 AI 를 사용하지 않고, local 환경에서 작고 가벼운 그러나 image upscaliong에 특화된 AI model을 직접 사용하여 간단하게 image의 화질을 개선하면서 upscaling 하는 두 도구에 대해서 알아 봤습니다.

해당 도구들은 최신도구는 아니지만, 여전히 기능과 성능면에서 유효합니다. upscaling 관련해서는 무료로 사용할 수 있는 site들도 굉장히 많이 있습니다만, 해당 server로 이미지를 upload 해야 한다는 부담감이 있지요. local 환경에서 비교적 빠르게 원하는 만큼 반복해서 사용할 수 있다는 정점이 있고, 자주 쓰지 않는 기능인데 Photoshop 같은 무거운 유료 이미지 tool을 구매하거나 설치하고 배워야 하는 부담감도 없다는 것 또한 정점 입니다.

Firefox가 AI Browser가 된다고 ?

elsa in mac — Fri, 19 Dec 2025 08:54:26 +0900

몇일 전, 2025년 12월 14일.. Firefox가 AI Browser로 바뀔 것이다라는 소식이 올라오면서 인터넷 세상이 떠들썩합니다. Firefox의 모 회사 Mozilla Corporation의 임시 CEO였던 Laura Chambers를 대신하여 Mozilla에서 Firefox 총괄 관리자로 제직 중이었던 Anthony Enzor-Demeo가 신임 CEO로 발탁되었는데, 이 분이 올린 글이 발단이 된 것 같습니다.

해당 포스트의 제목은 "모질라의 다음 장: 세계에서 가장 신뢰받는 소프트웨어 기업을 만들다" 인데요.. 이 포스트에서 문제가 된 부분은 아래와 같습니다.

첫째, 우리가 만드는 모든 제품은 사용자가 제품 사용 방식을 스스로 결정할 수 있도록 해야 합니다. 개인정보 보호, 데이터 사용 방식, AI에 대한 설명은 명확하고 이해하기 쉬워야 하며, 제어는 간편해야 합니다. AI는 항상 선택 사항이어야 하며, 사용자가 언제든 쉽게 끌 수 있어야 합니다. 사용자는 특정 기능이 작동하는 이유와 그 기능을 통해 얻을 수 있는 가치를 명확히 알아야 합니다.

셋째, 파이어폭스는 단순한 브라우저를 넘어 신뢰할 수 있는 소프트웨어 생태계로 성장할 것입니다. 파이어폭스는 앞으로도 우리의 핵심 역할을 할 것이며, 최신 AI 브라우저로 발전하여 새롭고 신뢰할 수 있는 소프트웨어 포트폴리오를 지원할 것입니다.

네..
신임 CEO가 Firefox의 비전을 정의하면서 향 후 Firefox가 "최신 AI 브라우저로 발전할 것"이라는 것과 AI기능은 "사용자가 언제든 쉽게 끌 수 있어야 한다."라고 언급한 저 부분들이 논란의 핵심인 것 같습니다.

Firefox의 AI 도입과 관련하여 여론이 높은 이유는 전 세계 웹 브라우저 시장의 절대적인 점유율을 차지하고 있는 Chrome의 대안으로 Firefox를 많이 사용하고 있기 때문입니다.

인터넷에서 논란이 확산되자, Firefox에서도 여러 SNS 매체를 통해 논란에 반응 하고 있습니다.

Mozilla 웹 개발 관련 책임자인 Jake Archibald는 Amstodon에서, "아직 명확하지는 않지만 Firefox에 모든 AI기능을 완전히 비활성화 할 수 있는 옵션이 추가될 예정이다. 우리는 내부적으로 이것을 AI 킬 스위치라고 부른다. 분명 훨씬 덜 살벌한 이름으로 출시가 되겠지만, 그만큼 우리는 이 문제를 심각하고 절대적으로 받아들이고 있다"라고 언급했습니다.

그냥 있는 그대로 이해한다면, "Firefox는 AI Browser로 변모를 해 나아갈 것이고, AI기능은 기본적으로 활성화되어 있겠구나.."라고 해석될 수 있는 부분입니다.

AI 시대를 맞이하여, AI 웹 브라우저들이 속속들이 등장하여 경쟁하고 있고, 이에 따라 기존의 웹 브라우저들도 AI 기능을 포함하는 방향으로 나아갈 것입니다. AI 시대에 AI를 뺀 비즈니스 모델이란 생각할 수 없기 때문입니다. 세상이 그 방향으로 간다면 함께 가야 합니다.

다만, 일부 사용자들이 반감을 표출하는 이유는 AI 자체를 부정하거나 나쁜 것으로 인식하기 때문이 아니라, AI가 활성화되고 있는지의 여부를 쉽게 인지할 수 없고, 어느 범위까지 그리고 어떤 정보들을 어떠한 방법으로 AI가 접근할 수 있으며, 데이터들의 보관 및 활용 방법이 어떠한지 투명하지 않기 때문입니다. 그리고, 무엇보다 AI 사용 여부에 대한 사용자의 선택권이 보장되어야 한다는 것이 맹점입니다. 모든 사용자들이 AI 기능을 사용하는 것이 마냥 편리하고 좋다고 생각하지 않습니다. 어떤 사용자들은 AI 기능을 환영하겠지만, 또 다른 사용자들은 AI의 개입을 원치 않거나, 필요한 경우에만 선택적으로 사용하길 원합니다.

웹 브라우저는 컴퓨터에서 사용할 수 있는 수 많은 애플리케이션 중 하나가 아닙니다. 오늘날 컴퓨터를 사용하는 거의 모든 사용자들의 업무, 경제활동 및 행정 처리에서 필수적으로 사용할 수밖에 없는 매우 중요하고 민감한 도구 입니다. 그래서 무엇보다 보안이 철저해야 하고, 신임 CEO가 언급했듯이 투명해야 합니다. 하지만, 이것은 어디까지나 사용자 측면입니다. 비즈니스 즉, 기업 측면에서 보자면 전 세계의 모든 연령과 사회적 계층의 사용자들을 포괄적으로 분석하고 상업적인 측면에서 유용한 데이터를 얻을 수 있는 창구가 될 수 있는 것이 또 웹 브라우저입니다.

물론, 절이 싫으면 중이 떠나면 됩니다. 아직은 대안들이 있습니다. Chrome 이나 Firefox 두 거대 양 진영에 수많은 folk 버전의 custom 웹 브라우저들이 존재합니다. Chrome이나 Firefox가 AI 기능으로 무장한다면, 그래서 그게 불편하다면 다른 대안을 사용하면 됩니다. 하지만, 거대자본과 점유율을 장악하고 있는 몇몇 기업들이 전체적인 통제권을 쥐고 있고 언제든 자신들이 마음만 먹으면 생태계를 뒤흔들 수 있다는 점을 간과해서는 안됩니다.

- - - - - - - - -

일부 Folk 버전들은 의도와 기능, 최적화는 맘에 들지만 소수의 인원들이 관리/유지하는 경우도 많습니다. 사용자들은 신뢰할 수 있고 지속적으로 발전시킬 수 있으며, 악성코드나 악의적인 해킹등 사이버 범죄로 부터 안전하게 개인 정보를 보호해 주는 든든한 공신력 있는 기업이 만드는 앱 브라우저를 원합니다.

앞서 언급했듯이, AI 시대에 맞는 기능을 넣는 것 자체를 거부하고 싶지는 않습니다만, 신임 CEO가 언급하고 관계자들이 표명했듯이, 사용자들에게 선택권을 부여하고 투명하며 공개된 AI 기능이 될 수 있었으면 좋겠다는 생각을 해 봅니다.

Asahi Linux 6.18 진행 보고서가 올라왔습니다.

elsa in mac — Thu, 18 Dec 2025 16:55:19 +0900

2025년도 이제 중반으로 접어들고 있습니다.
방문하시는 모든 분들도 올 한 해 잘 마무리하시어 뜻깊은 한 해로 잘 마무리하시기를 바랍니다.

오늘 Asahi Linux 공식 블로그에 Kernel 6.18에 대한 진행 보고서가 등록되었습니다. 현재 릴리즈 된 최신 공식 kernel 버전은 6.17.12-400으로, 배포 날짜는 2025-12-14일입니다. 공식적인 일반 Linux Kernel의 최신판은 6.18입니다 만, Asahi Linux 용 Kernel은 아직 Upstream 되지 않은 요소들과 추가적으로 발생한 버그에 대한 수정코드를 포함하여 릴리즈 하므로 , 공식 Linux Kernel 발표보다는 늦게 릴리즈 되고 있다는 점을 상기할 필요가 있습니다. 따라서, 6.18에 대한 진행보고서가 발표되었다는 것은 조만간 6.18에 대한 릴리즈가 있다는 것이지, 현재 6.18 버전이 릴리즈 되었다는 것은 아닙니다.

그럼 kernel 6.18에 대해 올라온 진행보고서에 대해 간략히 정리를 해 봅니다.

첫 번째로 SMC의 하위 장치들에 대한 드라이버 통합작업을 진행 중이며, 이는 다음 버전인 6.19에 이미 업스트림되었다고 합니다. Linux에서는 SMC가 관리하는 장치들에 대해 hwmon 드라이버를 통해 각 하위 장치들의 전압, 전류, 전력 및 온도 정보들을 확인할 수 있습니다. 현재는 내부 구성 요소 중 일부만 표시가 되는데, 이는 sensros 명령으로 확인할 수 있습니다.

mac mini 에서 sensors를 통해 내부 구성품에 대한 온도 및 소모 전압, 전류, 전력 정보를 출력한 예

여기에는 Fan 속도 제어도 포함됩니다 만, 현재 kernel 버전에서는 사용자가 Fan 속도를 제어할 수는 없습니다. 아직 포함되지 않은 요소에는 전원버튼하고 맥북의 경우 Cover Switch 드라이버가 남아 있으며, 배터리 및 전원 공급 관리 드라이버는 macOS 26 Tahoe의 SMC Firmware 변경 사항에 대응하기 위한 수정이 필요하다고 합니다.

두 번째로 그동안 Downstream에서만 동작가능 했던 USB3 기능이 이제 공식 Linux Kernel에 포함되기 시작했다는 것입니다. Apple Silicon Mac에서는 USB-C 포트가 정상적으로 동작하기 위해 여러 컨트롤러들이 협력을 해야 합니다. Synopsis USB Controller는 실제 USB 데이터의 전송을 담당하는 컨트롤러이고, TI(Texas Instrument) USB-PD Controller는 USB-C를 통한 전력 공급 및 충전 협상을 담당하는 컨트롤러이며, ATCPHY(Apple Type-C PHY)는 USB의 물리계층 설정 및 신호 라우팅을 담당하는 장치입니다. 현재 Synopsis USB Controller와 TI USB-PD Controller는 이미 kernel에 병합이 완료되었지만, 마지막 ATCPHY 부분은 리뷰 중에 있습니다. 이 부분은 특별한 문제가 확인되지 않는다면 그대로 upstream에 병합이 될 것이고, 그렇다면 이제 USB와 관련되어서는 모든 요소들의 Upstream이 완료되게 될 것입니다.

USB-C와 관련된 Display-Alt Mode나 Thunderbolt 지원 등 구체적인 기능과 관련된 내용은 확인할 수 없으므로, 6.18이나 6.19에서 사용자들이 다중모니터나 TB 외장 저장장치를 사용할 수 있는지의 여부는 아직 확인할 수 없습니다. 해당 기기 및 기능에 대한 지원이 완료된다면 Asahi 팀에서 별도로 공지를 하게 될 것입니다.

세 번째는 현재 M2 Pro/Max MacBook 에서 마이크의 기본 기능을 사용할 수 있는 상태이지만, 일부 기능은 여전히 잘 동작되고 있지 않기 때문에 보완이 필요하다는 내용입니다. 해당 기능들의 정상동작이나 디버깅은 해당 기기에서 해야 하는데, Debuging이 매우 복잡하고 여러운과정이라는 점을 설명하고 있습니다. Github Sponsers와 OpenCollective를 통해 들어오는 후원금을 활용할 수 있는데, 징비 구매 및 이와 관련된 처리과정이 꽤 복잡하고 시간이 오래 걸리는 건가 봅니다. 장비 구매 및 사용에 최대 5주 이상 걸릴 수 있다고 하네요.. 기부금이 모이는데도 시간이 걸리고, 그걸 또 사용하는데도 시간이 걸리니 진행이 빠를 수 없다는 점을 사용자들이 이해해 달라고 당부하고 있습니다.

다음으로 12월에 있을 정례 카오스 커뮤니케이션 컨퍼런스(12/30)에서 Asahi Linux에 대한 발표가 있다고 합니다. 이 자리에서 많은 사용자들이 궁금하게 생각하는 M3/M4/M5 mac 지원과 관련된 내용들이 논의가 될 예정이라고 하니, 관심 있으신 분들은 생방송 라이브를 시청해 보시기 바랍니다. 물론 관련 내용은 추 후 포스트에서 정리를 해 드리겠습니다.

끝으로, Asahi Linux의 설치 방법 개선에 대한 긴 내용이 들어 있는데요. 현재는 MacOS에서 검증된 파티션 구조가 담긴 자체 제작된 Disk Image를 사용하여 사용자의 개입 없이 자동으로 설치하는 방법을 사용하고 있는데, 이것은 사용자가 설치과정에서 유발할 수 있는 실수를 배제하기 위해서입니다. mac의 내장 SSD에는 macOS를 구동하기 위한 Boot Loader, Firmware, 보정 및 보안 데이터들이 들어 있는데, 사용자가 실수로 이들 중 하나라도 날려버리면 mac기기 자체가 먹통이 될 수 있는 위험성이 있습니다. 따라서 Asahi Linux는 개발 초기부터 이러한 위험성을 배제하기 위해 현재와 같은 인스톨 방법을 적용했습니다. 하지만, 이 방법은 디스크 암호화 설정을 어렵게 하고, 배포판마다 통 이미지를 매번 새롭게 빌드해야 하는 번거로움이 있습니다.

Asahi 팀에서는 최종적으로는 Kernel, Mesa, Pipewire Apple Silicon mac과 관련된 모든 코드를 Upstream에 통합하여 어떤 리눅스 배포판이던지 Live ISO를 사용하여 설치할 수 있도록하는 것을 목표로하고 있다고 합니다. Fedora와 관련해서는 일반적인 그래픽 설치도구인 Anaconda를 사용하여 설치할 수 있도록 준비 중인데, 특히 Apple 의 툭수 UUID로 식별되는 macOS 관련 파티션을 숨겨서 사용자나 설치 도구가 해당 파티션을 아예 인식하지 않도록 보호하는 기능을 협업하고 있고, KDE와 관련해서도 Plasma Setup에 관련 기능을 추가하도록 협업하고 있는 것 같습니다.

- - - - - - - -

종합적으로 파악을 해 보자면, 6.18까지는 현재와 같이 계속 UPstream에 집중할 것이므로 실제 사용자 측면에서는 크게 변화된 차이점을 느낄 수 있는 부분은 없을 것으로 예상되며, kernel 6.19에서 구체적인 개선이 이뤄질 것으로 보여 집니다.

현재까지 알려진 Kenel 릴리즈 일정을 확인해 보면, 6.19 버전의 RC(Release Candidate)는 rc1이 2025년 12월 14일에 출시가 되었으며, 20206년 1월 중 RC7 까지 매주 일요일마다 릴리즈를 하고, 정식 출시는 2026년 2월 1일 혹은 2월 8일 배포하는 것으로 계획되어 있습니다. 따라서, Asahi Kernel의 경우 거기에 대략 1달을 추가혀여 2026년 2월 말이나 3월초에 릴리즈 될 것으로 예상이 됩니다. 다만, 변수가 있다면 Linux Kernel 의 경우 Linuxs Tovalds의 승인이 필요한데, 연말 연휴와 겹치기 때문에 1주일 정도는 지연이 발생할 수도 있습니다.

kernel 6.19에서 포함될 것으로 예상되는 Asahi Linux 관련 항목들을 대략적으로 정리하면 다음과 같습니다. hwmon을 통한 센서 데이터 지원, RTC 지원, 전원 버튼 및 덮개(Lid) 지원, DRM Color Pipeline API 도입으로 Apple Silicon의 고급 디스플레이 기능(HDR, 색상관리) 구현, Honeykrisp GPU 드라이버 성능 및 안정성 향상, DWC3 Controller 에 대한 Glue Layer Driver 병합 등입니다.

깔끔한 Web Interface를 지원하는 이미지 앱 - ImageMagick WebGUI (docker - selfhosted)

elsa in mac — Wed, 10 Dec 2025 21:41:19 +0900

본 포스트는 Fedora Linux를 기준으로 작성되었습니다.

이번 포스트에서는 Docker Container로 구동할 수 있는 있는 Self-Hosted 이미지 편집 앱인 ImageMagick WebGUI를 소개 합니다. 최근에 Github에 등록된 따끈한 프로젝트 입니다.

Web Interface이므로 웹 브라우저를 통해 사용할 수 있으며, 무엇보다 인터페이스가 깔끔하고 이쁩니다. 여기에 image 편집에 요구되는 대부분의 주요 기능들을 지원합니다. resize, crop, type 변환, filtering, Effect(Blur, Sharpen, Grayscale, Sepia, Brightness, Contrast, Saturation) , 워터마킹과 text 추가, rotation 및 flip 등을 지원하고, 여러 image 파일을 한꺼번에 처리할 수 있는 Batch Processing을 지원합니다.

Light / Drak theme를 지원하고 배경 제거, Auto Enhance 및 Smart Upscaling 에서는 AI를 지원하여, 빠르면서도 준수한 품질의 결과를 얻을 수 있습니다.

Test에 사용된 원본 이미지

Auto Enhance 기능을 반영한 결과물

2배, 4배로 upscaling을 처리하는데는 LANCZOS 알고리즘을 사용합니다.

실제 구동 예

설치 방법

구성은 Next.js 기반의 WebInterface를 지원하는 Frontend와 FastAPI REST API를 위한 Backend, Database는 PostgreSQL 을 사용하고, Queue System으로 Redis를 사용합니다. 설치는 Docker를 이용하는 방법과 Local 에서 빌드하고 실행할 수 있는 방법이 있는데, Host에 설치하는 것은 여러가지 Dependency들을 남길 수 있으니 Docker 사용을 추천합니다.

설치는 Docker Image를 사용하는 방법과 source로 부터 Docker Image와 Container를 빌드하는 방법 두 가지 중 선택하여 설치할 수 있습니다.

첫번째 방법은 Docker Image를 사용하는 것으로 방법은 다음과 같습니다.

# 프로젝트 디렉토리 생성 
mkdir imagemagick-webgui && cd imagemagick-webgui

# docker-compose file 다운로드 
curl -O https://raw.githubusercontent.com/PrzemekSkw/imagemagick-webui/main/docker-compose.example.yml

# 파일명 변경 
mv docker-compose.example.yml docker-compose.yml

#  Docker Image 설치 및 Container 실행 
docker compose up -d

두번 째 방법은 source로 Docker Image를 빌드하고 설치하는 방법 입니다.

git clone https://github.com/PrzemekSkw/imagemagick-webui.git
cd imagemagick-webgui
cp .env.example .env
docker compose up --build -d

팔자는 두 번째 방법을 사용했고, 빌드 및 설치 중에 특별한 문제는 발견되지 않았습니다. 한번에 매끄럽게 처리되었습니다. 위의 과정을 모두 마치면, imagemagick-webgui 디렉토리내의 .env.example 파일을 .env 파일로 복사 합니다.

.env 파일에서 우선 위의 스샷처럼 SECRET_KEY와 JWT_SECRET 만 임의의 문자열로 변경합니다.

# ImageMagick WebGUI Environment Variables
# Copy this file to .env and modify as needed

# Security - CHANGE THESE IN PRODUCTION!
SECRET_KEY=<이 부분을 변경>
JWT_SECRET=<이 부분을 변경>

# Require login to use the app (true/false)
# false : 로그인 하지 않아도 사용할 수 있음. 
REQUIRE_LOGIN=false

# Allow new user registration (true/false)
# Set to false to prevent new signups (only admins can create users)
ALLOW_REGISTRATION=true

# Database
DATABASE_URL=postgresql://imagemagick:imagemagick@postgres:5432/imagemagick

# Redis
REDIS_URL=redis://redis:6379/0

# Google OAuth (optional - see README for setup instructions)
GOOGLE_CLIENT_ID=
GOOGLE_CLIENT_SECRET=

# Upload limits (업로드 이미지 크기)
MAX_UPLOAD_SIZE_MB=500   

# Default processing settings
DEFAULT_OUTPUT_FORMAT=webp
# 기본 이미지 퀄리티 : 100% 수정 
DEFAULT_QUALITY=100

# ImageMagick limits
IMAGEMAGICK_TIMEOUT=30
IMAGEMAGICK_MEMORY_LIMIT=2GB

# History retention (hours)
HISTORY_RETENTION_HOURS=24

lazydocker 에서 보면, 아래와 같이 3개의 container가 있는데, 이 3개를 모두 실행시키면 사용할 수 있습니다.

Docker를 처음 사용히사는 분들을 위해 시작, 종료, 업데이트 명령은 다음과 같습니다. 터미널에서 명령을 내려 주면 됩니다.

# Container 실행 
docker compose start

# Container 중지 
docker compose stop 

# Container 업데이트 
docker compose up -d

개인적인 평가를 해 보자면, 배경 제거는 Image의 복잡도나 배경과 전경의 수준에 따라 호불호가 있을 것 같다는 생각 입니다.

배경 제거 실행 결과

배경 제거는 준수한 편이지만, 살짝 외각선이 뭉게지는 부분도 있습니다. AI 관련 기능은 향 후 각기 다른 AI Model로 변경할 수 있는 옵션이 생겼으면 좋겠다는 생각을 해 봅니다.

Linux와 함께한 2025년을 마무리 하며...

elsa in mac — Tue, 9 Dec 2025 23:09:43 +0900

어느덧 2025년도 막바지에 접어들었습니다.
방문하시는 모든 분들도 올 한해 잘 마무리하며 의미 있는 한 해가 되었기를 기원합니다.

블로그 조회수가 마침내 100만이 넘었습니다. 와...
유명 유튜버나 인플루엔서들의 올리는 영상하나 사진 하나의 하루 조회수 보다 작은 수치일 수도 있겠지만, 개인적으로는 그래도 올해 남긴 의미 중 하나입니다.

이번 포스트에서는 Linux를 사용하면서 느낀 2025년 한 해를 되돌아 보고자 합니다.

2024년 마지막 날.. 정말 가벼운 맘으로 사 놓고 잘 쓰지도 않던 mac mini에 Asahi Linux를 설치한 것이 나의 컴퓨터 환경에 전환점이 되었습니다. 사실 직업이 Embedded Linux를 사용하는 것이었기에 Linux 자체가 생소한 영역은 아니었지만, 일상에서 사용하는 컴퓨터의 OS를 Linux로 전환한 것은 Asahi Linux를 설치하면서부터였습니다.

Linux를 좀 더 편하고 실용적으로 활용하려면 X86 PC에 Linux를 설치해서 사용하는 것이 좋았겠지만, 온 집안에 있는 컴퓨터가 모두 mac 이다 보니 애초에 그럴 생각은 하지 못했지요. mac H/W에 aarch64 Processor다 보니, Linux를 설치했지만 안 되는 것도 많고 H/W를 모두 지원하지도 않았지만 Apple Silicon mac에 Linux를 bare metal로 설치해서 사용할 수 있다는 점은 지금 생각해도 여전히 매력적입니다.

Linux의 단점이자 장점은 모든 영역에서 Custom 즉, 사용자가 직접 모든 것을 설정하거나 변경할 수 있다는 것입니다. 자주 포스팅에서 논의 했지만, Linux로 전환하기 쉽지 않은 이유가 바로 학습곡선이 꽤 가파르다는 점 입니다. 손이 아주 많이 가고 알아야할 것들이 많은 것이 단점이지요. 반면, 시간을 많이 투자하고 Linux에 대해 알아간다면 나의 취향에 딱 맞는 나만의 운영화경과 workflow를 구축할 수 있습니다. 이것이 Linux를 쓰는 맛이죠.

이렇게 시작한 Linux 를 어느덧 2년째 사용하고 있습니다. 물론, 앞으로도 변함없이 Linux를 사용할 것 입니다.

2025년 전 세계의 가장 핫한 주제 중 하나는 부정할 수 없이 AI 였습니다. 올 해는 분명 AI의 시대가 시작되었음을 알리는 한 해 였다고 봐도 무방합니다. 갑자기 우리 생활 전반에 AI가 스며들고 있습니다. 인구감소문제는 AI를 가속화시키는 가장 큰 이유이기도 합니다. 아직 AI 회사들은 막대한 자본을 투자하며 1인자의 자리를 차지하기 위해 경쟁하고 있을 뿐, 의미 있는 실적을 보여주지는 못하고 있습니다. 결국, 인터넷이 그러했듯, 세상 모든 사람들의 삶 전반에 스며들어 의미 있는 이익을 창출하기 위해서는 운영체제 위에서 실행되는 서비스가 아닌 OS와의 통합이 이뤄져야 합니다. 아직, Big Tech들은 공격적으로 본심을 들어내고 있지는 않지만, OS와 Ai의 결합은 필연적으로 이뤄질 것이고, 2026년에 좀 더 구체화 될 것입니다.

문제는 사용자들이 AI의 편리함과 효율성을 원하기는 하지만, OS에 통합되는 것을 받아들일 수 있는가 하는 것입니다.

지금은 내가 원할 때, 필요한 정보를 AI 서비스에 넘겨주고, AI의 도움을 받아 그 결과를 받아 보는 수준 입니다만, OS에 통합이 된다면 얘기가 달라집니다. OS에 통합된 AI를 사용한다는 것은 나의 모든 정보와 이벤트를 AI와 공유한다는 것을 의미합니다. 그럴 필요가 없다면 굳이 AI가 OS에 통합될 이유가 없기 때문입니다.

사용자들마다 견해가 다르겠지만, 필자는 그런 OS를 사용하고 싶지 않습니다. AI를 사용하기 위해 나의 개인적인 모든 정보와 관심사, 행동 패턴 들을 공유하고 싶지 않습니다.

그래서, 필자에게 있어 2024년에 Linux를 선택하고 전환한 것은 단지 내가 원하는 운영환경과 Workflow를 만들고 싶다는 것이었다면, 2025년, 세상의 변화를 보면서 Linux는 어쩌면 현실에서 AI를 벗어날 수 있는 거의 유일한 도피처이지 않을까라는 생각을 갖게 하는 한 해였습니다.

지난 11월 18일 자 Ubuntu 기반의 Linux Distro 중 하나인 Zorin OS의 블로그에 올라온 포스트입니다. 버전 17에서 18로 업그레이드 후 1달 만에 100만 다운로드를 달성했다는 내용으로, 역사상 처음 있는 일이라고 합니다. Zorin OS는 Windows / macOS 사용자에게 익숙한 운영환경 제공이라는 것을 강점으로 내세우고 있는 Linux 배포판 중 하나인데, 이번 결과가 Windows 10의 지원 종료와 무관하지 않다는 것이 Zorin 내부의 분석 및 업계의 대체적인 견해입니다. Zorin OS 개발팀에 따르면, 이 기간 동안에 다운로드한 사용자 중 약 78%가 Windows PC를 사용하고 있었다고 합니다. 물론, 100만 이라는 숫자는 전 셰계 Windows 가 설치된 PC의 규모로 보면 매우 작은 수치일 수 있습니다. 하지만, 반대로 Linux 입장에서는 굉장히 큰 숫자임에는 분명합니다.

Windows 11으로의 업그레이드 대신 Linux를 검토했다는 것은 여러 가지 이유가 있을 것입니다. 오래된 PC라 WIndows 11로 업그레이드할 수 없기 때문일 수도 있고, H/W 업그레이드에 대한 비용이 부담되어서 일 수도 있습니다. 하지만, 다른 측면에서 Windows가 MS Copilot과 Recall이라는 AI 기능을 적극적으로 통합하려는 시도 때문이기도 합니다. 특히나 Recall 기능은 PC 화면을 수초 간격으로 캡처하고 filter기능을 통해 민감정보를 제외한 데이터를 로컬 저장소에 저장합니다. 원래 목적은 사용자가 과거에 수행한 작업을 기억하고 쉽게 되돌아볼 수 있도록 하는 것을 돕는다는 이유이지만 과도한 데이터 저장 및 분석에 의구심을 갖고 있는 사용자들도 많으며. 더군다나 민감정보라는 것은 국가나 민족마다 형식과 내용이 다양하고, 시간에 따라 달라질 수 있으며, 각 개인마다 기준의 차이가 있으므로, Filtering 한다는 말 자체의 신뢰성을 담보할 수 없으며, 컴퓨터가 더 이상 도구가 아닌 사용자를 감시의 대상으로 여기는 것 같다는 두려움도 있습니다. 한편으로 이렇게 저장된 정보는 해커들이 노리는 대상이 될 수도 있습니다. 이러한 우려와 논란이 부각되면서 MS는 기본설정을 꺼짐으로 변경했고, 사용자 인증을 통한 Recall DB 접근, NPU가 탑재된 Copilot+ PC에서만 작동하도록 하는 조치들을 우선 했지만, 중요한 것은 결국 그것이 Windows가 지향하는 목표라는 것입니다.

물론, macOS에서도 Apple Intelligence 가 아직은 미흡하지만, 경쟁 OS인 Windows와 유사한 방향으로 발전할 것임은 자명해 보입니다.

그렇다면, 정말 AI가 통합된 OS에 대한 우려감을 갖고 있는 사용자들이 Linux로 전환을 할 것인가 ? 라고 묻는다면, 거의 대부분은 그렇지 않을 것 같습니다. Linux는 파편화가 심하고, Kernel 일 뿐이며, 그 위에 쌓아 올리는 모든 운영체제로서의 사용자 환경을 제공하지 않습니다. 다양한 배포판이 존재하는 이유입니다. 그나마 설치할 수 있는 그 수 많은 배포판들도 맘에 안든다면 직접 환경을 구축해야 합니다. 앞서 언급했듯이, 그래서 Linux는 다른 여타 OS와 달리 배워야 할 것들 즉, 알아야 할 것들이 많습니다. 단순히 컴퓨터를 일상의 도구로 사용하고자 하는 사용자들에게는 여전히 어려운 OS 이고, 그래서 Linux로 전환하는 것은 말처럼 쉬운 일이 아닙니다.

자동차로 예를 들자면, WIndows나 macOS는 업계 전문가들이 사용자들의 요구와 트렌드에 맞춰 잘 만든 양산형 모델 자동차라고 볼 수 있습니다. 비용만 지불하면 자동차 열쇠를 받을 수 있고, 시동만 걸면 곧장 차를 운전할 수 있습니다. 반면, Linux는 자동차 차체만 제공할 뿐 나머지 부속들은 사용자 당신들이 알아서 조립해 사용하세요~ 라고 하는 것과 유사 합니다. 자동차에 관심이 많은 덕후라면 세상에 하나뿐인 나만의 슈퍼카를 만들 수도 있겠지만, 대부분의 사용자들은 조립할 수 없습니다. 부품이 어떤것들이 있는지 알아야하고, 조립하는 방법과 동작원리도 배워야 합니다. 수 많은 시행착오를 겪을 수도 있습니다.

물론, OS에 대한 AI의 기능 통합이 고도화되고, 이를 원치 않는 사용자들이 Linux에 대한 관심을 갖게 되는 비율이 점점 높아진다면, 일부 배포판에서는 그러한 사용자들이 Linux로 쉽게 전환할 수 있도록 하는데 더 많은 노력을 기울일 수도 있을 것 입니다. 당연히 산업계나 자본시장은 잠재적인 고객들이 시장 이탈을 원치 않기 때문에 늘 그래왔듯이 Linux를 지원하거나 하지는 않을 테지요.

시대의 흐름을 Linux라고 거스를 수는 없을 것입니다. Linux 에도 AI는 다양한 계층에서 사용되게 될 것이지만, 그 역시도 하나의 자동차 부품처럼 "당산이 원한다면 원하는 곳에 알아서 사용하세요~ 물론 필요 없다면 빼셔도 됩니다." 가 될 것입니다.

- - - - - - - - - -

필자도 AI를 전혀 사용하지 않는 것은 아닙니다. 특히 Google의 Gemini-CLI를 사용하면서 AI의 편리함과 효율성을 몸소 체험할 수 있는 한 해였지요. AI 생태계에서 일어나는 일들에 관심을 기울이고 공부하지만, 가급적 실생활에서 의존도를 높이지 않으려 노력합니다. 항상 일정한 거리를 두고자 노력합니다. 보조적인 수단으로만 도움을 받고자 노력합니다. 배움과 창작의 동기와 가치를 지키려 노력합니다.

그럼에도 불구하고, 거대자본과 권력의 힘으로 밀어붙이는 이 큰 물결은 결국 우리들 삶의 방식을 변화시킬 것이고.. 그래서 원하든 원치 않든 우리는 그 속에서 살아가게 되겠지요. 그 미래가 행복한 세상일런지는 아직 잘 모르겠습니다.

결코 가속페달에서 발을 떼지 않는 세상의 변화 속도를 걱정반 기대반으로 바라보면서,
세상이 조금은 천천히 생각과 고민을 좀 해가면서 나아갔으면 하는 바람을 가져 봅니다.

Linux에서 yazi를 사용할 때 zip 파일을 압축해제 하지 못하는 문제의 원인과 대처법

elsa in mac — Sun, 7 Dec 2025 19:29:33 +0900

이 포스트는 Fedora Linux를 기준으로 작성되었습니다.

오늘 .zip 압축 파일을 yazi로 압축 해제하려 하니, 압축 해제가 되지 않고, firefox(기본 웹 브라우저)가 실행되면서 해당 파일을 다운로드하겠냐고 물어보는 황당한 상황이 발생했습니다..

"어 이게 뭐지 ???"

평소에는 .zip 파일을 다룰 일이 없어서 이런 버그 현상이 있는지 조차 알지 못했는데, 오늘 알게 되었네요.. 이것은 fedora linux 혹은 기타 다른 linux에서도 동일하게 발생할 수 있는 내제적인 bug 이므로 동일한 증상을 겪고 있다면 내용을 확인하고 조치하시기 바랍니다.

문제점 파악

우선은 왜 yazi가 압축 파일을 압축파일로 인식하지 못하는지를 확인해야 했습니다. yazi 에서 tab 키를 누르면 현재 선택된 파일에 대한 파일의 유형을 확인할 수 있습니다.

위의 스샷을 보면, Mimetype: 에 application/octet-stream 이라고 표시가 됩니다.

Linux는 Windows와 달리 파일 확장자라는 개념이 없습니다. Linux에서 test.zip 이라는 것은 그냥 해당 파일의 이름 자체가 test.zip 일 뿐입니다. .zip은 확장자가 아니며 파일명의 일부일 뿐입니다.

그럼 Linux는 파일의 유형을 어떻게 식별할까? Linux에서는 파일의 magic number라는 것을 확인하는데, 파일들은 그 내부에 파일 유형에 따른 고유한 특정 비트열을 갖고 있습니다. 이것을 확인함으로써 해당 파일이 압축파일인지, 이미지 파일인지 아니면 일반 text 파일인지를 1차적으로 식별합니다. 그리고 2차적으로 MIME(Multipurpose Internet Mail Extensions) Type을 사용하여 파일의 유형을 식별하는데, 여기서 소위 말하는 확장자를 고려하게 됩니다. 물론 Linux에서는 파일명의 끝이 .txt 인지, .zip 인지 혹은 .png 인지를 보는 것이겠죠. 이것은 magic number로 파일의 유형이 식별되지 않을 때 보조적인 수단 입니다.

그럼, 위의 실제 상황에서 test.zip 파일은 파일명이 끝이 .zip 일 뿐 실제로는 .zip 파일이 아니었다는 건가?

yazi는 mime type을 이용하여 파일을 식별하도록 되어 있기 때문에 mime type이 잘못 식별되면 사용자가 기대하는 결과를 얻을 수 없습니다.

terminal에서 특정 파일의 mime type을 확인하려면 워의 스샷처럼 xdg-mime이라는 명령을 사용하면 됩니다. 역시 application/octet-stream 으로 식별이 됩니다.

하지만, 해당 파일을 unzip 으로 압축 해제해 보면 정상적으로 압축이 해제되므로 zip 파일은 맞는데, mime 유형은 zip으로 식별하지 않는 것이 문제 입니다.

원인은 file 명령의 버그

이거 왜 이런 걸까?
xdg-mime 은 내부적으로 file comand 를 사용하기 때문에 file의 문제가 있는 것이 아닐까 하는 생각이 들어 해당 github에 가 봤습니다.

이런 이런..
일부 zip 파일을 식별되지 않은 일반 data로 판단하는 버그가 있었고, 이 버그를 수정한 commit 이 있다는 것을 확인했습니다.

문제는 이 프로젝트의 정식 업데이트 반영 주기가 꽤나 길다는 것입니다. 버그를 식별하고 조치를 했지만, 각 Linux 배포판으로 업데이트가 안되어 있을 수 있다는 것이죠. 마지막 release가 2024년 11월 이였고, 그 이전의 기록을 보니, 대략 1년에 2번 정도를 업데이트 하는 것으로 파악이 되었습니다. 해당 commit가 2024년 12월 이니.. 1년 전인데.. 언제 Release가 될런지.. 하..

따라서, 이 문제를 해결하기 위해서는 해당 프로젝트의 소스코드를 다운로드하여 직접 빌드하고 기존에 설치된 file를 대치해야만 합니다.

# 최신 source 코드를 clone 합니다. 
git clone https://github.com/file/file.git

# 디레토리 변경 
cd file 

# 빌드  
autoreconf -fi
./configure 
make
sudo make install 

# 실행파일은 /usr/local/bin/file 임.

위의 절차대로 소스코드를 다운로드하고, 빌드를 하고 나면 /usr/local/bin/file 에 설치가 됩니다. 기존에 package manager로 설치한 file의 경로는 /usr/bin/file 이므로 해당 파일을 임시로 백업해 놓습니다.

# file 백업 
sudo mv /usr/bin/file /usr/bin/file-backup

기존의 file을 file-backup으로 변경했으므로, 이제 file은 /usr/local/bin/file 이 사용되게 됩니다.

터미널에서 test.zip 파일의 type을 다시 확인해 보니, 이제 정상적으로 zip 파일로 인식합니다.

yazi 에서도 MimeType 을 application/zip 으로 정상적으로 식별합니다.

- - - - - - - - -

zip 파일을 압축해제하는 방법은 사용자들의 환경에 따라 다를 수 있습니다. 직접 터미널에서 압축관리 프로그램으로 해제 할 수도 있고, KDE나 GNOME 같은 DE를 사용하신 다면, file manager GUI 에서 압축을 해제할 수도 있을 겁니다. file manager GUI 앱들은 파일명이 확장자를 mime으로 식별하는 방식을 사용한다면 이것이 문제가 안되었을 수도 있겠단 생각이구요.

yazi를 사용하시는 분들 중에 같은 문제를 겪고 있다면 도움이 되었으면 합니다.

Asahi Linux, kernel 6.17.9 가 공식 릴리즈되었습니다.

elsa in mac — Sat, 29 Nov 2025 23:20:53 +0900

지난 11월 9일 날 6.17의 test version이 등록된 후, 소식이 없길래, 6.17은 12월에 배포되는 것인가 했는데, 11월 29일 방금 전 공식 repository 저장소에 등록되었습니다.

이제, sudo dnf update로 등록된 kernel 6.17.9 버전으로 업데이트할 수 있습니다. 공식 6.17 릴리즈와 비교해 보면, 대략 1달 정도의 지연이 있었네요.

업데이트 후 rebooting 을 해 본 결과, 특별한 문제점은 발견되지 않았습니다.

kernel 6.17은 AMD 및 Intel 시스템에 대한 최적화와 파일 시스템의 성능 개선이 주요 업데이트 사항입니다.

AMD Ryzen 코어를 더 효과적으로 사용할여 혼합 코어 프로세스에서 workload를 지능적으로 분배 흠으로써, 전반적인 시스템의 응답성 및 에너지 효율성을 개선했으며, Intel 시스템에서 모든 CPU 코어에 대한 Schedualer의 SMP(Symmetric Multiprocssing) 지원으로 시스템 응답성이 항상 되었습니다. BTRFS 에서는 large-follo 지원과 defragmentation(조각모음) 중 압축을 제어하는 새로운 옵션이 추가되었으며, EXT4 에서는 Block 할당과 버퍼링 I/O에 대한 확장성과 성능이 향상되었으며, fallocatioe 2 플레그로 NVMe 및 SCSI SSD에서 불필요한 I/O 작업을 줄임으로써 SSD의 수명 연장에 도움이 될 수 있도록 향상되었습니다.

AMD Hybrid GPU SmartMux 지원기능이 도입되어 통합 GPU와 외장 GPU 간의 자동전환을 개선함으로써 불필요한 전력 소비를 줄이고 그래픽 성능에 대한 보다 부드러운 전환이 가능해 졌으며, Intel IPU7 앱켐 드리아버가 추가되어 최신 Intel 노트북의 카메라 기능이 개선되었습니다.

aarch64 에서는 시스템을 리부팅하지 않고도 커널 패치를 실시간으로 적용할 수 있는 Live Patching 기능이 도입되었습니다.

Applle Silicon 과 관련해서는 MacBook의 Touchbar 지원이 더욱 향상되었습니다.

kernel 6.17.9는 6.17의 공식 Stable 버전으로, mainline은 이미 6.18-RC7 이 나와 있는 상태입니다.

지난 포스트에서도 언급했듯이, Asahi Linux와 관련된 매우 많은 부분이 upstram 되었으며, 대부분은 아직 미 구현된 부분들에 대한 기본환경을 구축하는 것과 관련이 있습니다. 따라서, 이번 6.17 보다는 차기 버전인 6.18 혹은 그 다음 Major Update에서 미 지원 부분들에 대한 실제적인 구현이 반영될 수 있을 것으로 기대가 됩니다.

이번 kenel 6.17 과 관련되어 새로운 소식이나 추가적인 정보가 확인되면, 새로운 포스트로 업데이트 하겠습니다.

업데이트 후 별다른 문제없이 사용할 수 있다는 것에 대해 Asahi 팀의 그 동안의 노력에 감사의 맘을 전합니다.

Wayland 환경에서 사용가능한 Tablet지원 Whiteboard 앱 - drawy

elsa in mac — Sat, 15 Nov 2025 14:51:41 +0900

이 포스트는 fedora linux를 기반으로 적성되었습니다.

이번 포스트에서는 Linux Wayland 환경에서 Tablet을 활용할 수 있는 drawing Tool 인 drawy를 소개합니다.

Linux에서 특히나 Wayland 환경에서는 Tablet을 이용하여 white board 스타일로 간단히 drawing을 할 수 있는 앱이 거의 없습니다. 그나마 가장 완성도 높은 근접한 솔루션으로 web browser기반의 Excalidraw 가 있지요. 필자도 개인적으로는 self-hosting으로 이 앱을 사용해 오고 있었습니다. 한데, 오늘 github를 검색하던 중, 웹 인터페이스가 아닌 QT6 기반의 C++ 앱이 있는 것을 알게 되었습니다. 2025년 1월 2일 날 프로젝트가 등록되어 있으니. 1여 년의 준비를 끝으로 공개한 것 같습니다.

Github에는 x86_64용 appImage만 제공하기 때문에, aarch64 기반의 Linux를 사용하는 필자는 소스코드를 다운로드 받아 직접 빌드해서 사용해야 합니다.

빌드 및 실행

빌드 과정에서 몇 가지 문제가 있었기 때문에 해당 문제와 해결 방안을 써 봅니다. Github에서는 Compile을 하려면, QT6.9 이상이 설치되어 있어야 한다고 되어 있는데, CMakeLists.txt 파일을 보니, QT5를 참조합니다. 그러다 보니 compile 과정에서 오류가 발생하더군요. 그래서, QT6를 참조하도록 CMakeLists.txt 파일을 약간 수정해야 했습니다.

우선, OpenGLWidgets 패키지를 찾는 부분을, 아래와 같이 Qt6 6.10에서 Widgets과 OpenGL을 찾는 것으로 변경했습니다.

# 17라인 
# find_package(Qt${QT_VERSION_MAJOR} REQUIRED COMPONENTS OpenGLWidgets)
find_package(Qt6 6.10 REQUIRED COMPONENTS Core Gui Widgets OpenGL)

참고로 필자의 경우, 현재 QT6 6.10이 설치되어 있습니다.

다음으로, link libraries 설정 부분을 아래와 같이 수정했습니다.

# 56 라인 
# target_link_libraries(${PROJECT_NAME} PRIVATE Qt${QT_VERSION_MAJOR}::OpenGLWidgets)
target_link_libraries(${PROJECT_NAME} PRIVATE Qt6::OpenGL)

이렇게 수정을 한 후에, 아래의 명령을 통해 빌드를 진행했습니다.

# setup cmake 
cmake -B build -S . -DCMAKE_BUILD_TYPE=Release

# compile (build)
# -j 뒤에 빌드에 사용할 CPU core 수를 명시한다. ex) -j 8
cmake --build build --config Release -j

빌드가 정상적으로 이뤄지면 build 디렉토리에 "drawy" binary 파일이 생성됩니다. 해당 파일을 실행하면 아래와 같은 화면을 만나 볼 수 있습니다.

Drawy 실행 화면

인터페이스는 개발자의 언급한 것과 같이 Excalidraw와 유사합니다.

Zen 브라우저에서 실행한 Excalidraw 실행 화면

아래는 동영상 스샷.

Tablet의 기본기능도 잘 지원하는 것 같습니다. Tablet 사용 여부는 사용하는 Wayland DE나 Window Manager가 지원을 해 주어야 합니다.

약간의 커스텀

잘 동작을 하는 것을 확인했으니, 모니터에서 직접 drawing을 하는 Annotation 앱으로 활용할 수 있을 것 같다는 생각에 배경을 투명하게 바꾸기 위해 소스코드를 분석했습니다. 다행히 QT 기반이기 때문에 간단하게 Window의 배경을 투명하게 만들 수 있었습니다.

src/window/window.cpp 파일을 보면, 아래와 같이 MainWindow::에 대한 설정을 하는 코드가 있습니다.

# 35 라인 
MainWindow::MainWindow(QWidget *parent) : QWidget(parent) {
  // 배경을 투명하게 ---------------
  this->setAttribute(Qt::WA_TranslucentBackground);
  this->setWindowFlags(Qt::FramelessWindowHint);
  //-----------------------------

  this->m_applyCustomStyles();

  BoardLayout *layout{new BoardLayout(this)};
  Controller *controller{new Controller(this)};
  ApplicationContext *context{ApplicationContext::instance()};

TranslucentBackGround Attiribute와 framelessWindowHint Flags를 정의해 주면 기본적으로 Window를 투명하게 설정할 수 있습니다.

그리고, dark/light mode toggle 버튼에서 light mode는 개인적으로 사용하지 않기 때문에, light mode 시에 배경을 투명하게 설정하도록 했습니다. 이를 위해 src/common/constants.h 파일을 열고, 아래와 같이 Light Mode의 배경색상에 alpha 0를 추가해 줍니다.

# 40 라인 
#constexpr QColor lightBackgroundColor{248, 249, 250}; 
constexpr QColor lightBackgroundColor{248, 249, 250, 0};

이제 다시 빌드를 하고 확인을 하면, 아래와 같이 배경이 투명한 white-board를 사용할 수 있습니다.

Wayland WM에서 해당 toplevel에 대한 Pin 속성을 부여하고 필요할때, 다른 window 위에 중첩시키면 실시간으로 annotation을 할 수 있는 훌륭한 도구가 됩니다.

하지만, 당장은 사용자가 그린 결과물을 json 파일로 저장하거나 로딩만 할 수 있을 뿐, 이미지 파일로 exporting하는 기능은 아직 없습니다. 그래서, 스샷 앱을 이용하여 스샷을 찍는 수 밖에는 없습니다. 그리고, Text 입력에서 한글이 입력되지 않습니다. 한글 입력 기능도 코드를 수정을 해서 구현은 했는데, 이 부분은 검토를 좀 더 하고, 추 후에 Pull Requests로 upstream 될 수 있도록 요청을 해 볼 예정 입니다.

- - - - - - - - -

Linux에서 예전 Wacom tablet을 활용할 수 있는 앱이라는 측면에서 반갑고, C++ 기반으로 작성되어 안정적이면서도 처리속도가 매우 빠르고 부드럽게 반응합니다. github에 보시면 phase 3 단계를 진행 중이며, 조만간 PNG로 export 할 수 있는 기능이 추가될 것 같습니다. 아직은 EXcalidraw가 UI/UX 측면에서 뛰어나지만, 설치및 실행이 번거로운 단점이 있지요. 그리 대중적인 앱은 아니겠지만 또 해당 기능이 필요한 유저들에겐 기다려 왔던 앱일 수 있는 만큼 관심이 있으시다면 방문하시어 검토해 보시기 바랍니다.

가볍고 빠른 웹 브라우저 - Helium

elsa in mac — Sat, 15 Nov 2025 02:14:43 +0900

본 포스트는 fedora linux 환경에서 작성되었습니다.

이번 포스트에서는 최근 인터넷에서 주목받고 있는 웹 브라우저인 Helium을 소개합니다.

웹 브라우저는 우리 일상에서 아마 가장 많이 그리고 거의 대부분의 시간을 함께 하는 대표적인 app 이지요. 제각가 차별화된 기능과 편의성을 내세운 매우 많은 웹 브라우저들이 있습니다. 물론 가장 높은 사용자층을 갖고 있는 것은 Google의 chrome 일 것입니다.

어떤 웹 브라우저를 사용할 것인가 하는 것은 사용자들마다 나름의 주관적인 기준에 의해 선택되어지게 되는데, 필자의 경우에도 나름의 기준이 있습니다. 우선 가장 중요한 것은 "개인정보 보호"입니다. 가급적이면 웹 브라우저 사용과 관련된 정보들이 노출되거나 수집되지 않기를 원하지요. AI기능은 절대 내장되어 있으면 안 됩니다. 또한 내 의지와 관계없이 광고가 노출되는 것이 너무 싫습니다. 그래서 이를 효과적으로 차단할 수 있는 UBlock Origin 사용이 가능해야 합니다. 두 번째는 적은 리소스 사용입니다. 필자는 8GB RAM의 Mac Mini를 사용하고 있기 때문에 RAM이 넉넉하지 못합니다. 따라서 메모리 사용량이 적은 웹 브라우저를 선호합니다. 그리고 이왕이면 반응속도가 빠른 웹 브라우저가 좋겠지요. 그 밖의 웹 브라우저가 제공하는 편의기능은 옵션이라 생각하고 가급적이면 사용을 안 합니다. 간혹 특정 웹 브라우저들은 자사의 핵심 기능을 강제화 하는 경우가 있는데, 이러한 웹 브라우저는 아무리 좋아도 웬만하면 사용하지 않습니다.

Google의 Chrome은 Chromium이라는 오픈 소스 웹 브라우저를 기반으로 Google의 독점적인 기능과 서비스를 추가한 웹 브라우저입니다. 이 와는 정 반대로 Google 의존성을 거의 대부분 제거한 오픈 소스 프로젝트인 Ungoogled Chromium이라는 것도 있지요. Chromium 기반의 웹 브라우저는 이 밖에도 상당히 많이 존재합니다. Microsoft사의 Edge를 비롯하여 Brave, Vivaldi, Opera, Arc 등등도 모두 Chromium 기반의 웹 브라우저들입니다.

Helium은 UGC(UnGoogled Chromium)을 기반의 프로젝트로 "최고의 개인정보 보호화 편견 없는 광고 차단 기능을 기본으로 제공하며, Split View 기능, ad-ware 및 bloat, noise 없는, 사람에 의한 사람을 위한 완전한 Open Source"를 지향하는 웹 브라우저라고 소개하고 있습니다.

새로운 기능을 부가적으로 지원하는 것을 목표로 한다기보다는 반대로 불필요한 기능과 코드를 배제시키고 보다 가볍고 빠른 웹브라우저를 지향하는 프로젝트입니다. Google의 Menifasto V2를 지원하며, trackers, phishing website, ad block을 위해 uBlock Origin extension 및 filter을 기본적으로 탑재하고 있습니다. 따라서 빠르게 실행되고, RAM과 CPU 점유율이 작으며 응답속도가 높은 성능을 보여 줍니다. 팔지가 사용해 봐도 리소스 점유율도 양호하고 응답속도도 정말 빠릿빠릿합니다.

최초 실행, 옵션 설정

최초 실행 시 나타나는 Helium Serive Option 선택 화면

위의 스샷은 Helium을 최초 실행할 때 나타나는 Helium service Option 선택 화면 입니다. 제일 상단의 Allow Cneecting to Helium services 항목을 OFF 시키면 아래 모든 기능들이 모두 OFF 됩니다.

Proxy extension downdloads and updates
이 옵션은 Chrome Web Store에서 사용자가 extension을 설치 버튼을 누르면 해당 extension을 다운로드하고 자동으로 설치 및 업데이트 해주는 옵션 입니다. 일반적으로 Chrome Web Store에서 extension을 설치하게 되면, 사용자의 웹 브라우저, 지역, 다운로드 이력등등의 정보가 Google에 넘어가게 되는데, 이러한 정보가 넘어가는 것을 방지하면서 해당 extension을 설치할 수 있도록 하는 옵션 입니다.

Allow downloading the !bang list
Helium은 주소창에서 !(느낌표와) keyward를 키인하면 특정 웹 사이트를 기반으로 검색을 할 수 있는 서비스인 !bang 기능을 지원합니다. 예를 들어, !w 는 위키페디아에서의 검색을 의미합니다. 사용자가 위키에서 정보를 검색할 때 wikipedia에 접속 후 검색할 필요 없이, !w를 키인한 후 한칸 띄우고 검색어를 넣으면 곧바로 wikipedia의 해당 웹 페이지가 로딩되는 서비스 입니다. !r 은 raddit, !g은 google.. 뭐 이런식 입니다. 이 옵션은 이 bang 서비스에 필요한 list를 다운로드 하여 업데이트 할지의 여부를 선택하는 옵션 입니다.

Allow downloading filter lists for uBlock Origin
이 옵션은 uBlock Origin extension에 필요한 filter list를 다운로드 할지의 여부를 설정하는 것입니다.

Allow automatic browser update
Helium은 Ungoogled Chromium 기반의 Folk 버전이므로 Ungoogled Chromium과 같이 원칙적으로는 자동 업데이트를 지원하지 않습니다. 하지만, 이 옵션을 활성화 하면 Ungoogled Chromium과는 달리 업데이트 기능일 지원받게 됩니다. 이 기능은 아직은 지원되지 않는 것 같습니다. (in the future) 라고 붙어 있네요.

Allow downloading dictionary files for spell checking
스펠링 체크를 위한 사전 파일을 다운로드 받을지의 여부에 대한 옵션입니다. 굳이 speel check 기능이 필요치 않다면 OFF 시키면 됩니다.

Helium service 옵션에서 다음으로 넘어가면 위의 스샷과 같이 어떤 검색 엔진을 사용할지의 여부를 물어 봅니다. Ungoogle Chromium 에서는 주소창에서 직접 검색을 할 수가 없습니다. 기본적으로는 지원을 하지 않습니다. 물론 설정에서 지원하도록 설정할 수는 있는데, Google 검색은 또 빠져 있지요. Helium 에서는 첫 실행단계에서 이를 선택할 수 있도록 하고 있으며, 기본적으로 Google 검색도 선택할 수 있게 되어 있네요.

다음 화면은 bookmark, 검색 히스토리, extension을 기존에 사용하던 웹 브라우저여서 Helium으로 transfer할지를 묻는 화면 입니다. 동일한 chromium 기반이라면 bookmarks, history, extensions을 모두 trasfer 받을 수 있고, 다른 웹 엔진을 사용하는 브라우저라면 bookmark 와 history만 transfer 할 수 있습니다. transfer를 원치 않는다면 그냥 NEXT 버튼을 누르면 됩니다. 왠만하면 trasfer하지 않습니다.

마지막으로 기본(Default) 웹 브라우저로 설정할지의 여부를 묻습니다. 기본 선택이 YES 이므로 원치 않는다면 NO를 선택하고 Next 버튼을 눌러 줍니다.

특징

위의 스샷을 보면, 왼쪽은 Chromium 브라우저이고, 오른쪽이 Helium입니다. 화면 상단의 Tab bar와 주소창 영역이 Chromium 대비 높이가 낮게 설계되어 있어 보다 Minimal 한 인상을 갖게 됩니다.

큰 차이는 아니지만, 아래의 스샷을 보면, Helium 은 process id가 chrome으로 표시되며, 대략 700MB 정도의 메모리를 사용합니다. Chromium의 경우는 800MB의 메모리를 사용하는 것을 알 수 있습니다.

speed test 3.0 으로 속도 측정을 해 보면,

Chromium

Helium

스샷에서 볼 수 있듯이, 13.3과 15.3으로 15% 정도 더 높은 점수가 나오는 것을 볼 수 있습니다. 물론 이러한 수치들은 절대적인 값은 아닙니다. 컴퓨터의 환경에 따라 다르지요. 다만, 동일한 컴퓨터에서 보다 긍정적인 수치를 보여 준다는 정도로 이해하면 될 것입니다.

단점은 ?

그럼 단점은 없느냐?
첫 번째는 Ungoogled Chromium 기반이다 보니, 자동 업데이트 기능이 없습니다. 사용자가 직접 수동으로 업데이트를 해야 합니다. 앞서 언급했듯이 이 기능은 추후에는 지원할 것으로 보입니다.

두 번째는 DRM 콘텐츠를 이용할 수 없습니다. Netfix, Disney+, Spotify 나 Apple Music 같은 스트리밍 서비스를 이용할 수 없다는 것이죠. 이는 Widevine 인증을 받아야 하는데, 이게 꽤나 큰 비용이다 보니 이것은 향 후에도 지원하지는 않을 것으로 보입니다.

세 번째는 불필요한 요소와 기능 및 서비스를 지원하지 않기 때문에 나타날 수 있는 불편함 입니다. 이건 개인마다 다를 수 있는데, 패스워드 저장 및 자동입력, 클라우드 동기화 같은 기능들이 의도적으로 제거되어 있기 때문에 별도의 서비스를 이용해야 합니다. 필자의 경우에는 Docker를 이용한 Self-Hosting 서비스를 통해 Bookmark와 패스워드 관리 기능을 이용하기에 불편함이 없지만, 일반 사용자들은 이러한 기본 기능 부재가 불편할 수 있습니다.

네 번째로는 이 프로젝트가 두 명의 익명 개발자가 주관하고 있다는 점입니다. 물론 이 프로젝트는 여타 다른 프로젝트들과는 달리 특별한 기능이나 새로운 서비스를 추가하는 프로젝트는 아닙니다. 하지만, 웹 브라우저는 Folk 버전이라 하더라도 그 범위가 매우 방대한 프로젝트이기 때문에 대부분의 웹 브라우저 프로젝트들은 개발 인원도 많고, 그만큼 재정적인 지원도 뒷 받침되어야 합니다. Helium의 경우는 개발자의 신원도 익명이고 개발 참여 인원도 적기 때문에 아무리 Open Source라 하더라도 신뢰성 및 프로젝트 지속성을 담보하기에는 아직은 불안한 측면이 있다는 우려섞인 견해도 있습니다. 현재도 Widnows, macOS, Linux 버전이 각기 독립적으로 관리되고 있으며, 버전관리도 통합적으로 일관되게 되고 있지 않는 것으로 파악됩니다.

Comminity 전반에 걸친 이러한 신원 불명의 우려에 대해 제작자들도 공감하고 있는 듯 합니다. Reddit에 제작자 중 한 분이 익명으로 활동하고 있는 이유에 대해 설명을 했습니다.

내용인 즉슨, 한분은 러시아 인이고, 한분은 EU 국가의 국적을 갖고 있는데, 정부의 신원추적을 피하기 위한 불가피한 결정이였다고 하는군요. 프로젝트가 Open Souce이고, 빌드 및 배포가 자동화 되어 있는 만큼 크게 우려하지 않았으면 좋겠다고 당부하고 있습니다.

- - - - - - - - - -

깔끔한 디자인과 군더더기 없이 기본에 충실하면서 빠른 반응성을 강점으로 내세운 UGC 기반의 웹 브라우저로 첫인상은 꽤나 좋다고 평가할 수 있을 것 같습니다. 프로젝트가 좀 더 투명하고 조직적으로 운영되면서 사용자들에게 신뢰를 얻게 된다면, ARC나 Zen 프로젝트 수준의 평가를 받을 수 있을 것으로 기대해 볼 수 있을 것 같습니다.

DRM 문제로 OTT 등의 활용측면에서 다른 브라우저를 함께 병행해서 사용홰야 하는 불편함이 있지만, 일상적으로 사용할때는 Helium을 주력으로 사용하고 있습니다. 아직은 큰 불편함도 없고, 단점 보다는 장점이 큰 브라우저인 것 같습니다.

Asahi Linux의 Kernel 6.17 에 대한 진행 보고서가 올라왔네요.

elsa in mac — Fri, 24 Oct 2025 21:49:33 +0900

Fedora Linux의 차기 버전인 Fedora 43의 정식 릴리즈가 이번 달 말로 예정되어 있습니다. Fedora 43은 Linux Kernel 6.17이 포함될 예정이지요. Asahi Linux도 해당일에 같이 업데이트 릴리즈가 있었으면 합니다.

오늘 25/10/24 일, 방금전에 Asahi Linux Blog에 Kernel 6.17 관련 진행 보고서가 등록되었습니다. 간단히 어떤 내용인지 살펴봅시다.

우선, Linux Kernel에 대한 Upstream에 대한 내용입니다.

2022년 부터 논의되어 왔던, Apple의 M1/2 Aplle Silicon Chip에 대한 SMC(System Management Controller) 드라이버가 마침내 Linux Kernel에 Merge 되었다는 소식입니다. Linux Kernel에 SMC 드라이버가 포함되므로 인해, GPIO 컨트롤러 및 재부팅 컨트롤러 기능이 추가되었고, 따라서 이미 업스트림된 장치들이 정상적으로 재부팅될 수 있는 초석이 마련되었다고 합니다.

개인적으로는 M1 Mac Mini를 사용하면서 재부팅과 관련된 문제로 어려움을 겪은 적은 없었지만, M1/M2 SoC가 적용된 mac은 mac mini 만 있는 것이 아니고, mac book 이나 mac studio 도 있는 만큼 해당 기기에서는 문제가 있었을 수 있다고 생각됩니다. 이번 Upstream patch로 관련된 문제들이 해소되고, 보다 안정적으로 재부팅할 수 있는 여건이 마련된 것 같습니다.

다음으로 GPU 지원관련 내용입니다.
Linux는 GPU Kernel Driver가 Firmware로부터 필요한 정보를 얻는 방식을 결정하는 수단으로 Devicetree를 사용하는데, 관련된 Schema가 안정화되었고 관련 속성들이 Upstream Devicetree에 통합되었다고 합니다. 지금까지 꽤 오랜 시간 GPU관련 코드들이 Upstream 되어 왔는데, 이제 대부분이 마무리된 것 같습니다. Devicetree와 상호작용하는 GPU 드라이버 부분이 merge 됨에 따라 형 후, GPU와 관련된 수정이나 기능 추가 및 성능향상에 보다 유기적으로 대처할 수 있는 기반이 마련되었다고 볼 수 있을 것 같습니다.

이어서, M2 Pro/Max/Ultra 모델의 DART(Device Address Resolution Table) 지원이 추가되었다는 소식 입니다.
DART는 IOMMU(Input/Output Memory Management Unit)의 일종으로 Apple Silicon SoC에서 Peripheral(주변장치)나 Display Controller와 같은 IP(Intellectual Property: 재사용 가능한 지적 재산 설계) Block 이 DMA(Direct Memory Access)를 통해 Main Memory에 접근할 때, 이 장치들이 사용하는 논리적 주소를 실제 물리적인 주소로 mapping 해주는 역할과 메모리에 대한 접근 권한을 감시하고 차단하는 보안 방화벽 역할울 수행 하는 SoC 내부의 하드웨어 블록입니다. 통상적으로는 IOMMU라고 부르지만, Apple에서는 과거 PowerPC 기반 시스템에서 이를 DART라고 명명했지요..

정리하자면, DART를 지원하다는 것은 Apple Silicon이 관여하는 그러나 아직은 Asahi Linux에서 지원이 미비한 USB-C 디스플레이나 Video 가속기 같은 하드웨어 블럭에 보다 안정적으로 접근할 수 있는 기반을 마련하게 되었다는 의미로 볼 수 있을 것 같습니다. SMC의 나머지 기능 드리이버들, 예를 들어 Hardware Monitoring 기능, Lid Switch, 전원 버튼 상태, RTC(Real Time Clock) 같은 Hardware관런 드라이버들도 이를 기반으로 향 후 추가될 것 같습니다.

Asahi Linux 사용자들이 애타게 기다리고 있는 USB-C를 통한 외부 Monitor 연결과 관련된 USB patch에 대한 약간의 언급도 있는데, 최근에 Linux Kernel 의 USB 관련 부분에 대해 Asahi Linux 개발 팀이 DWC3 Glue layer Dirver 관련 Maliing List가 등록되었습니다. Glue Driver라는 것은 표준화된 하드웨어 드라이버와 특정 시스템의 고유한 특성을 갖는 기기를 연결하기 위한 드라이버를 의미 합니다. Apple Silicon SoC 내부에는 DWC3(DesignWare Controller 3)라는 IP Block을 기반으로 한 USB 컨트롤러가 포함되어 있는데, 여기에 Apple의 자체적인 고유 기능과 제어로직을 추가했지요. 그래서 이를 사용하기 위해서는 Glue Driver가 필요합니다. 이를 통해 USB 연결이 물리적인 계층인 PHY와 Type-C 컨트롤러 간의 순서 동기화 요구를 맞춰 줌으로써 정상적인 연결성을 보장하고 기능을 유지할 수 있게 할 수 있습니다. 예를 들어, 케이블 변경(연결/해제)을 감지했을 때 이와 관련된 어떠한 처리를 해야 합니다. 이를 올바르게 처리해주지 못하면 재 인식이 되지 않는다던가 시스템 동작에 영향을 미치게 되어 다시 부팅을 해야 하는 등의 문제가 발생할 수 있지요. 결론적으로 이를 통해 USB3, USB4에 대한 전송기능을 지원할 예정이라고 볼 수 있고. 향 후, Thunderbolt , DP-Alt 모드 지원이 진행될 것이다라고 볼 수 있을 것 같습니다.

다음은 m1n1과 관련된 것 입니다.
m1n1 은 M1 apple Silicon SoC를 위한 n1.. 즉, 첫번째 boot-loader라는 의미인데요. m1n1 저장소에 CI pipeline을 추가하여 UEFI 번들 빌드를 자동화했다고 합니다. 업데이트에 따른 자동 빌드가 되므로 효율성이 높아졌다고 볼 수 있을 것 같고, Fedora 이 외의 다른 배포판을 설치하는데 도움이 될 수 있을 것이라고 합니다. 또한 m1n1의 부팅 체인 중 ADT(Apple Device Tree) 처리코드를 Rust로 다시 작성하여, 기존 C코드로 작성된 비효율성과 안정성을 높일 수 있게 되었다고 합니다. m1ni은 Apple의 부팅 프로세스를 가로채어 제어권을 가져오는 역할을 합니다. 물론 부팅에 필요한 하드웨어 초기화 및 관련 드라이버 로딩도 핵심 역할입니다. 그리고 이 활성화된 하드웨어 기반 위에 U-boot를 로딩하게 되지요. 물론 m1n1과 U-boot은 이전과 동일하게 Mac의 내장 저장장치의 partiton에 설치가 되어야 합니다. 다만, 다른 배포판이 Apple Silicon을 지원하도록 배포판이 준비되었다면, UEFI-only 모드에서 USB를 통해 설치를 할 수 있는 것입니다.

그리고, 기존의 windows 애플리케이션 특히, 게임을 구동하는데 muvm 의존성을 탈피하여 WINE을 통해 직접 구동할 수 있게 되었다고 하는데, 게임은 제 관심분야가 아닌 만큼 설명 없이 skip 합니다. ^^ . 불 필요한 가상화 계층을 제거하고 거의 native에 가까운 수준으로 Windows 애플리케이션을 수행할 수 있는 단계에 이르렀다 정도로 정리합니다.

- - - - - - - -

정리를 해 보자면, 지난 1년 Asahi Team의 주요 개발자들의 이탈이 있었고, 그로 인해 한때 프로젝트가 중단되는 것 아니냐는 우려가 있었지만, 결론적으로는 프로젝트는 미래를 향해 한발 한발 나아가고 있는 것 같습니다. (다행이지요.)

팀에서 특별한 언급이 없는 것을 보면, Fedora 43의 공개와 함께 Asahi Linux도 지연 없이 업데이트가 될 것 같습니다. Linux Kernel에 대한 Upstream 이 안정화 단계로 진입했고 이는 개발자들이 그 동안 신경쓰지 못했던 부분들에 대한 개발에 집중할 수 있게 되었다는 것을 의미합니다. 내년에는 Thunderbolt, DP-alt 모드 지원, 그리고 M3 mac 지원이 될 수 있을지도 모른다는 기대감이 높아지네요.

최근, 애플에서는 macOS의 차기버전인 Tahoe를 발표 했습니다. 사용자들의 반응은 시큰둥 합니다. 물론 저는 업데이트하지 않았습니다. M1, M2 mac은 이미 최신 macOS를 품기에는 부족합니다. 이전 포스트에서 언급했듯, Liquid Glass에 대한 개인적인 반감이 있기도 하고 Sequoia에서 안정적으로 사용하고 있기 때문에 굳이 업데이트를 할 필요성을 못 느끼고 있지요.

최근 Apple을 보면 확실히 예전 같지 않다는 느낌을 지울 수가 없습니다. 물론, Apple 같은 초 거대 기업이 그 둥안 만들어 온 자사의 OS를 그렇게 허술하게 만들리는 없습니다. 그들의 지향하는 미래의 목표가 있을 것이고 Mobile, Desktop, 그리고 Wearable 을 아우르는 자사의 운영체제를 하나로 통합하려는 노력은 당연히 부작용을 낳게 됩니다. 단지 지향점이 데스크탑은 분명 아니기에 macOS에서 보다 두드러지는 것이겠지요. 그렇더라도 그 동안 잘 되던 기능에 문제가 생기거나 UI/UX 디자인이 사용자들에게 오히려 부담이 되면 안됩니다.

10명도 안되는 개발자들이 만들고 있는 Asahi Linux와 초 거대 기업 apple의 내 놓은 macOS Tahoe 를 보면서 참 뭐랄까.. 돈, 책임감.. 열정.. 미묘한 비교감 이랄까.. 암튼 그렇습니다.

레트로 감성 돋는 Cassette Player 데스크탑 앱을 만들고 있습니다. #2

elsa in mac — Sun, 12 Oct 2025 19:29:46 +0900

이 포스트는 Fedora Linux를 기반으로 작성되었습니다.

길게만 느껴졌던 2025년 추석 연휴가 오늘로 끝이네요 ?
다들 편안하고 힐링할 수 있는 시간들이 되었나 모르겠군요.

긴 연휴 동안 저녁시간에 짬을 내어 조금씩 개선을 해 나가고 있습니다. 프로젝트 목표가 Simulator이다 보니, 기본적으로는 카세트 플레이어에 대한 기술적/기능적 특성을 잘 파악하는 것이 중요합니다. 인터넷이 올라와 있는 많은 자료들을 조사하고 공부했습니다.

프로그램을 1인이 개발하는지 아니면 팀으로 개발하는지에 따라 프로젝트의 진행단계와 절차가 다르겠지만, 일반적으로는 프로젝트이 목표와 개념을 확립하고, 기능과 성능 목표의 수준을 정한 다음 UI 다지인을 스케치합니다. 여기에 사용자의 사용경험을 정립하는 UX를 결정하고, 이것이 결정되면 구현에 들어가죠.

기존의 Design이 목표와 맞지 않는 관계로 디자인부터 다시 해야 했습니다. 디자인 툴은 Linux를 사용하는 관계로 Adobe나 macOS의 sketch 같은 것은 사용하지 못하니, Linux에서 가용한 Lunacy를 이용했습니다. log-in 같은거 필요 없이, off-line을 사용할 수 있는 장점이 있습니다. 요즘 핫한 Figma과는 비견하기 어렵겠으나. 기본적인 Design Tool이 갖고 있는 대부분의 Interface를 갖고 있고, 기본적으로 대부분의 기능을 무료로 사용할 수 있는 cross-platform design tool 입니다. 배우기 쉽고 직관적이며 기능도 꽤 만족스럽습니다. X11 전용이므로, Wayland 기반 사용자라면 XWayland를 사용해야 합니다.

Lunacy를 이용한 디자인

카세트테이프를 구성하는 요소들을 다지인 하고, 이를 실제 앱 개발에서 방법과 절차를 정해서 통합합니다.

기본적으로 투명한 인터페이스를 갖고 있습니다. 보통 앨범을 폴더단위로 구분하여 관리하므로 해당 앨범 폴더에 cassette-cover.png 파일로 cover 이미지 파일을 넣어 놓으면 해당 폴더를 로딩할 때, 이미지 파일을 가져와 masking 하여 보여 줍니다.

그러면, 위와 같은 모습을 볼 수가 있죠. 한번은 번거롭지만 cover를 만들어 놓으면 다음부터 앨범을 로딩할 때, 이쁜 cover를 앨범별로 볼 수 있으니 괜찮을 것 같습니다. 원래는 음원 내부의 Tag에서 Album Cover를 읽어와서 Skin을 입히는 방법을 적용하려 했는데, 아직 몇 가지 기술적인 문제가 있어서 추후에 반영을 해야 할 것 같습니다.

컨트롤러는 mouse 이벤트를 이용하여 반응형으로 보이거나 감출 수 있도록 했습니다.

아무리 simulator를 지향한다 하더라도, 최소한의 편의성은 있어야 하기에 몇 가지 제한사항과 부가 기능들을 넣었습니다. 원래 물리적인 카세트테이프는 Side A와 Side B 중 전체 길이가 긴 것을 기준으로 테이프의 길이가 결정됩니다. 그래서 그 시절에는 앨범을 만드는 제작사에서 이 둘 간의 gap이 크지 않도록 각 곡의 play time을 조절했지요. 대부분의 곡들의 끝을 Fade-Out 처리한 것이 그런 이유일 것입니다. 하지만 완벽히 맞출 수는 없어서 Side A가 끝났을 때, Side B로 바꾸면 곡의 처음이 아닐 수 있지요. 그래서 Side를 바꾸면 처음으로 되감아야만 했습니다. 이건 좀 불편하더라고요. 그래서 앱에서는 Side A와 Side B를 완전 독립적으로 구분해서 Side A의 끝에서 Side를 바꾸면 Side B의 처음에서 시작하도록 했습니다.

Side 별 playlist

Side A/B 에서 Playlist를 확인하고, 원하는 트렉으로 곧바로 선택하여 플레이 할 수 있는 기능을 넣었습니다.

8밴드 EQ

간단한 8밴트 Equalizer 기능을 넣었고요.

LRC 자막파일 지원

.lrc 가사(lyrics) 파일이 있다면, 플레이 시, 아래쪽에 자막을 sync 하여 보여줄 수 있도록 했습니다.

그 밖에 Side가 끝나면 자동으로 뒷면으로 변경하는 Auto-Reverse 기능과 현재 플레이하고 있는 곡을 반복 재생할 수 있는 Repeat 기능, 그리고 Tape의 색상을 바꿀 수 있는 Color Theme 기능을 지원할 예정입니다. 구현 중에 있고요~

- - - - - - - - - -

최초에 예상했던 것보다 디자인도 바꾸고, 기능도 추가하다 보니 완성까지는 좀 더 시간이 걸릴 것 같네요.

과거 턴테이블과 카세트의 시대가 지고 CD가 대세로 자리 잡았던 젊은 시절, 개인적으로 수집해 놓은 CD들을 Ripping 해 놓은 것들이 꽤 많은데, CD는 적절한 시기에 대부분 처분했지만 Streaming 시대가 되다 보니 이것들을 지우지도 못하고 그렇다고 이걸 듣지도 않는 지경이 되어 버렸지요.. 이 프로젝트를 시작하게 된 계기입니다.

기능은 대부분 구현했지만, 성능 최적화, CPU/GPU 렌더링 자원 배분, Linux, macOS, windows에서의 설치 및 사용 검증 등 배포 전에 해야 할 몇 가지 것들이 남아 있습니다. 연휴라 시간이 많아 구현에 많은 시간을 할애 했지만, 이제 연휴도 끝난지라 시간을 내기가 어려우니.. 그래도...

올해 안에는 끝나겠죠 ?

레트로 감성 돋는 Cassette Player 데스크탑 앱을 만들고 있습니다. #1

elsa in mac — Sat, 27 Sep 2025 20:07:02 +0900

이 포스트는 Fedora Linux를 기반으로 작성되었습니다.

이번 포스트에서는 과거 Casette Player를 듣던 세대 혹은 Retro 감성을 좋아하는 분들을 위한 음막 플레이어를 하나 소개 해 볼까 합니다.

지금 나이로 40대 중후반 이후의 세대라면 아마 LP, Tape, CD, 그리고 오늘날의 Streaming 음원 서비스까지 음원과 관련된 거의 역사적인 모든 매체를 접해왔을 겁니다. 저도 그런 세대죠.

지금은 음악을 너무나 쉽고 빠르고 편리하게 듣고 즐길 수 있지만, 과거에는 쉽지 않았죠. 라디오 음악방송으로 새 노래를 접하게 되고, 음악이 맘에 들면 또 그 음반이 정발 되기를 기다려야 했고, 그나마 국내 정발이 되지 않으면 수입음반을 고가에 사거나 반대로 해적판 음원을 구입해야 했습니다. 음악을 듣는 즐거움도 있었지만, 자신이 좋아하는 음반을 수집하는 행복감도 한몫했었죠. 가끔은 그 시절이 참 그리워요.. ^^

각설하고.. 오늘 웹 서핑을 하다가 정말 우연히 HTML5 기반의 오디오를 플레이할 수 있는 Cassette Player를 보게 되었습니다. 등록 날짜가 2012년이니까.. 이것도 13년 전이네요..

웹 디자인 및 앱 개발 분야의 온라인 리소스 사이트인 Cordrops에 올라온 Old School Cassette Player with HTML5 Audio라는 것으로 HTML, CSS, Javascript로 구현된 Cassette Player 입니다. Demo 사이트에서 그 기능을 확인할 수 있는데요. 일종의 카세트 플레이어 Simulator(시뮬레이터)인 셈입니다. 정말 멋지게 잘 만들어져 있습니다. 개발자분이 존경스럽네요. 관련 기술에 대한 온라인 학습과정을 홍보하기 위한 포트폴리오로 등록한 것 같습니다. 그런데 소스코드까지 다운로드할 수 있지 몹니까.. 와...

해당 앱을 Downdload 한 후, 압축을 해제하고 Songs 폴더에 자신의 음원을 넣으면 local에서 자신의 음원을 플레이할 수 있습니다. 물론, 구조상 Local web-server 환경이 필요하지만, 조금만 수정하면 php 정도만 설치하고도 사용할 수 있습니다. 여하튼 이 이쁜 player를 웹 브라우저에서만 사용할 수 있다는 것이 좀 아쉽지요.

개발자분이 공개했을 때가 2012년 이니까. 당시에는 이것을 데스크톱 애플리케이션으로 만들 수는 없었을 것입니다. 다만, 그 다음 해인 2013년에 Javascript, HTML, CSS 기반의 데스크톱 애플리케이션을 만들 수 있는 ATOM Shell 이라는 프레임워크가 발표되었고.. 네~ 그것은 오늘날 우리가 알고 있는 Electron Framework라는 것입니다. 물론, Javascript, HTML, CSS 기반의 데스크톱 앱을 만들 수 있는 것은 Electron 만 있는 것은 아닙니다. Flutter나 Tauri , NW.js 등도 있지요.. Electron은 Chromium 전체를 App에 포함한다는 측면에서 다소 부담스럽고 자원소모량이 많다는 단점이 있지만 관련 기술 성숙도가 가장 좋고 높은 호환성과 안정적인 생태계를 갖고 있다는 장점도 있습니다.

개인적으로는 직접적으로 Electron App을 개발해 본 적은 없지만, 이미 기본 소스가 있고 Electron App을 만드는 것이 그리 어려운 것은 아니라는 것을 어깨 너머로 알고 있는지라, 다운로드 받은 소스로 Electron 데스크톱 App을 만들어 보기로 했습니다.

우선, 개발목표는 말 그대로 "레트로 감성 그대로의 Player를 만들자" 입니다. 워낙에 많은 음악 Player들이 세상에 나와 있고, 기능이나 편의성으로 보면 Spotify나 Apple Music 같은 거대 자본기업들의 Player가 대세인지라.. 그 수준을 따라가는 것은 의미가 없겠죠.. 편의기능은 최소화, 기능보다는 감성...

우선, 원래 소스는 mp3와 ogg 파일만 사용할 수 있도록 되어 있는데, ogg는 빼고 대신 flac 음원을 플레이할 수 있도록 수정을 했습니다. 이유는 필자가 갖고 있는 음원들이 약간의 mp3와 대부분 flac 음원이기 때문입니다. ^^

Front-Cover.png 파일을 이미지 편집 프로그램으로 살짝 다듬어서 플레이 중인 음반의 제목과 곡명을 overlay로 표시할 수 있도록 수정했습니다. 물론 그 기능도 추가했구요.

볼륨 Knob는 굳이 필요치 않을 것 같아서 빼버렸습니다. 대신, Odometer(주행 기록계)와 Odometer Reset 버튼을 추가했습니다. 과거 카세트 플레이어를 사용하셨던 분들이라면 Odometer가 뭔지는 아실 것입니다. LP 나 CD 처럼 사용자가 원하는 트랙(Track)으로 곧바로 Jump 할 수 없는 것이 테이프의 태생적 한계이자 특징이죠. 다음 트랙이나 이전 트랙으로 넘어가려면 Fast Forward(빨리 김기) 버튼이나 뒤로 감기(Rewind) 버튼을 눌러야 합니다. 이 기능은 그대로 넣었습니다. 트랙 List 기능을 넣지 않았기 때문에 실제 카세트처럼 다음 곡이나 이전 곡으로 가려면 빨리 감아야 합니다. ^^ 하지만, 딱 하나 불편한 것이 처음으로 가는 것입니다. 이건 너무 오래 감아야 해서 좀 불편하더라구요.. 그래서 Odometer Reset 버튼을 누르면 그냥 곧바로 처음으로 가도록 하는 기능을 추가했습니다.

카세트테이프를 앞/뒤로 뒤집는 것은 원래 소스코드에 있는 기능이라 그래로 사용하고, 웹의 배경은 깔끔한 게 좋은지라, 투명하게 처리했습니다. 태이프 아래 버튼들의 모음인 컨트톨러는 Mouse Hover기능을 넣어서 Focus를 받을 때만 나타나게 처리했습니다.

또 앱을 종료하고 다시 실행했을 때, 이전에 플레이 했던 딱 그 위치에 있어야 합니다. 카세트 특성이 그러하죠.. 그래서 마지막 플레이 사이드(Side A/B) 정보와 Odometer 정보를 저장하는 기능도 추가 했습니다.

코드 분석하고, 수정하고 기능 추가하고 테스트하고.. 대략 8시간쯤 걸린것 같은데..

완성된 모습은 아래와 같습니다.

좀 괜찮아 보이죠 ?
실제 동작하는 모습을 동영상으로 담아 봤습니다. 저작권 관계상 소리는 넣지 않았습니다. 원본 소스의 Simulation 효과나 버튼별 효과음의 수준이 너무 뛰어나서 결과도 매우 만족스럽습니다. 빨리 감기 할때 좀 덜덜거려 보이는데, 이건 동영상 Frame이 낮아서 그런거지 실제로는 훨씬 자연 스럽습니다. 원래 소스에서는 2배속으로 감는데 넘 느린것 같아 4배속으로 수정했습니다.

원래 카세트에서는 이전 곡이나 다음 곡을 탐색할 때, 뒤로 혹은 앞으로 감고 멈추고 플레이로 확인하고 또 뒤로 혹은 앞으로 감고 멈추고 확인하고 했었는데.. 이것도 좀 불편해서 앞으로 감거나 뒤로 감기 버튼을 눌러 놓으면 알아서 곡 시작이나 끝이 되었을 때, 자동으로 멈추도록 하는 기능을 넣었습니다. (이 기능은 카세트플레이어가 전성기 인 시절에 고급 기능 중에 하나였죠..)

아래 동영상은 데스크탑 전체에서 본 모습입니다. 이리저리 배치도 해보고.. 크기도 가늠해 볼겸., 27인치 4K 모니터 입니다.

이뻐요..

Electron App으로 만든 후, macOS에서도 확인을 해 봤는데, 특별한 문제는 발견되지 않았습니다. WIndows에서는 확인을 못 해 봤구요..

몇군데 다듬어 지지 않은 부분과 기능상 버그를 손 본 후에 Tauri 나 Flutter로도 만들어 볼 예정입니다.Elctron 과 비교해 보고 좀 더 나은 결과물로 결정을 해야 할 것 같습니다. PSD 파일도 있으니 좀 더 이쁘고 다양한 Face 이미지도 추가해서 선택할 수 있도록 하구요. 아마 추석 연휴가 끝나면 완성될 것 같은데, 개인적으로 사용하려고 만들고는 있지만 완성도가 좋고, 원하는 분들이 있다면.. 나눔 진행해 보겠습니다.

Manifast V2 지원이 중단된 Chromium v140.x 에서 Ublock Origin 계속 사용하는 팁

elsa in mac — Tue, 16 Sep 2025 21:31:01 +0900

지난 포스트에서 다루었던 적이 있었는데, Google 이 드디어 2025년 10월 Manifast V2에 대한 지원을 중단하고 V3로 업데이트됩니다. 일반 사용자들에게 이 업데이트가 주는 의미는 딱 하나 기존의 Ublock Origin을 더 이상 사용할 수 없다는 것인데요,

Ublock Origin은 Ad Blocker 기능이 주 핵심기능이지만, 각 사이트의 화면 구성 요소를 사용자가 감출 수 있는 기능을 함께 갖고 있다는 점에서 많은 사랑을 받고 있습니다. Linux 기준으로 버전 139까지는 사용할 수 있었는데, 최근에 업데이트된 버전 140에서부터 지원이 중단되었습니다.

Chromium v140.x 로 업데이트 후 실행한 모습 - Ublock Origin이 비활성화 되어 있으며, 활성화 할 수 없다.

위의 스샷은 Chromium을 v140.x 로 업데이트 한 후, 실행한 경우의 Extenstions 설정 화면입니다. 보면, 더 이상 Ublock Origin Extension을 사용할 수 없다는 안내문과 함께, 활성화 버튼이 잠겨 있는 것을 알 수 있습니다.

만일, Ublock Origin을 계속 사용하기를 원한다면, 세 가지 방법이 있습니다.

첫번째 방법은 아직 MV2를 지원하는 Firefox 혹은 Firefox folk 버전 또는 Chrome의 Folk 버전인 Edge, Brave 또는 Vivaldi 등과 같은 다른 웹 브라우저로 갈아타는 것입니다. 하지만, 늘 써오던 앱을 바꾼다는 것이 쉬운 결정은 아니지요.

두 번째 방법은 결론부터 말씀 드리자면, 이건 임시방편적인 방법이자, 이번 포스트의 주제와 관련된 팁입니다. 바로 Chromium v140.x 버전에서 차단된 "V2 차단기능"을 비활성화시키는 것으로, 업데이트된 v140.x 버전의 chromium에서 Ublock Origin을 계속 사용할 수는 있지만, 언젠가는 결국 완전히 차단될 방법 입니다.

방법은 간단합니다. Chromium 을 실행할 때, 아래의 옵션을 추가해서 실행해 주면 됩니다.

--disable-features=ExtensionManifestV2Unsupported,ExtensionManifestV2Disabled

Fedora Linux 기준으로 그리고 dnf로 chromium을 설치했다면, /usr/lib64/chromium-browser 디렉터리 밑에 있는 chromium-browser.sh 파일의 CHROMIUM_DISTRO_FLAGS를 아래와 같이 변경하면 됩니다.

CHROMIUM_DISTRO_FLAGS=" --enable-plugins \
                        --enable-extensions \
                        --enable-user-scripts \
                        --disable-features=ExtensionManifestV2Unsupported,ExtensionManifestV2Disabled	\
                        --enable-features=UseOzonePlatform  \
                        --ozone-platform=wayland  \
                        --enable-wayland-ime  \
                        --wayland-text-input-version=3	\
                        --enable-printing \
                        --enable-sync \
                        --auto-ssl-client-auth "

나머지 flag 들은 사용자의 상황에 맞게 설정하면 되는데, 중요한 것은 --disable-features .. 이 부분을 추가해 주면 됩니다. 이건 말 그대로 ManifestV2 Extenstion을 Disable 시키는 기능을 "비활성화시키는 것"입니다. /usr/lib64 는 시스템 디렉터리니까 수정하려면 sudo 를 사용해야 합니다. 수정을 했다면, chromium을 종료하고 다시 실행해 주면 Ublock Origin Extenstion이 다시 활성화 된것을 확인할 수 있습니다. 물론, Ublock Origin 개발팀에서는 Manifast V3에서 동작가능한 Ublock Origin Lite가 Chrome 앱 스토어에 등록되어 있지만, Ublock Origin과 동일한 수준의 것이 아닙니다.

마지막 세번째 방법은 --disable-feature.. 플래그를 사용할 수 있는 가장 최신의 chromium 설치 패키지를 백업받아 놓고 더 이상 업데이트를 하지 않는 방법입니다. Chromuim을 사용하기 위해서는 chromium 패키지와 chromium-common 패키지 이렇게 두 개의 패키지를 설치해야 합니다. Fedora의 경우에는 chromium 패키지, chromium-common 패키지 링크에서 다운로드 받을 수 있습니다.

sudo dnf downgrade로 roll-back 할 수도 있지만, 이건 어디까지나 repository에 과거의 버전이 남아 있을때나 가능한 것입니다. 바로 직전의 버전이 없거나 roll-back할 과거 버전이 꽤나 오래전의 것이라면 상황이 곤란할 수 있기 때문에, 신규 버전이 등록되었을 때 마다 패키지를 다운로드 받아 놓는 것이 좋습니다.

다운로드한. rpm 패키지는 dnf 패키지 관리자를 repository에서 패키지를 설치하듯 동일한 방법으로 설치하면 됩니다.

만일 설치 후에 추 후에 업데이트 버전을 다운로드하였다면.. 그냥 똑같이 sudo dnf install chromium....rpm 으로 설치하면 알아서 자동으로 업데이트해 줍니다.

유용한 TUI 도구들 (2025.09)

elsa in mac — Tue, 2 Sep 2025 19:56:29 +0900

이번 포스트에서는 기존에 GUI로 사용하던 블루투스제어기, PulseAudio 및 Pipewire 세션 관리자인 pavucontrol, 그리고 WiFi 설정을 위한 TUI/GUI 도구를 소개합니다.

Linux를 사용하면 Terminal Emulator를 거의 주로 사용하기 때문에 GUI 앱 보다는 CLI나 TUI 도구를 좀 더 선호하게 되는 경향이 있습니다. 일단 실행이 빠르고, 사용이 간편하며 CPU나 Memory 사용량을 극적으로 줄일 수 있기 때문이죠.

* Wi-Fi 관리자, nmgui (GUI) - github 링크

먼저 소개하는 도구는 Wi-Fi 관리도구인 nmgui 입니다. 이 도구는 TUI가 아니라 오히려 GUI입니다. WI-Fi 접속관리는 TUI 보다는 GUI 가 훨씬 직관적이고 편하기 때문입니다. ^^

GNOME이나 KDE 같은 Desktop Edition을 사용하는 분들은 GNOME/KDE등이 제공하는 제어창이나 위젯을 통해 Wi-Fi 연결/종료/변경 등을 할 수 있지만, Hyprland, Sway, I3, Niri 등의 Compositor를 사용하는 분들이라면 Wi-Fi 설정이 약간 어려울 수 있습니다. NetworkManager 등의 CLI를 사용해야 하는데, 직관적이지 않죠. 이런 분들에게 추천하는 Python GUI 앱입니다.

network-manager를 위한 python wrapper library인 nmcli 의 front-end GUI 앱이라고 볼 수 있는데요. 실행을 하면 위의 스샷과 같이 현제 위치에서 접속가능한 WI-FI SSID 목록을 확인할 수 있으며, 우측의 화살표 아이콘을 누르면 해당 SSID에 대한 접속/해제는 물론 해당 SSID에 대한 상세한 정보를 확인할 수 있습니다.

실행 시 마다 실시간 scanning을 하기 때문에 반응 속도는 약간 느리지만, WI-FI를 좀 더 쉽게 사용하고자 하는 분들에게 추천합니다.

* Bluetooth 기기 관리자, Bluetuih (TUI) - github 링크

GTK 앱인 Blueman-manager 과 싱크로율이 거의 100%에 가까운 TUI 도구입니다. 마우스를 지원하기 때문에 keymap이 익숙하지 않다면 우선 mouse를 이용하면 쉽습니다. 목록에 표시된 기기에서는 마우스 오른쪽 버튼을 클릭하면 GUI처럼 contexture-menu가 표시됩니다.

메모리 사용량은 blueman-manager의 1/5 수준입니다. Windows와 Linux를 지원하며, i386, x86_64, arm64 등의 프로세스를 지원합니다. release 링크에서 자신의 시스템과 일치하는 패키지를 다운로드 받아 사용하면 됩니다. 현재 alpha stage이지만, 사용하는 데는 큰 무리가 없습니다.

* Pipewire 대응 오디오 믹서, wiremix (TUI) - github 링크

PulseAudio Volume Controller인 pavucontrol 과 거의 동일한 인터페이스를 지원하는 TUI 도구입니다. 역시 mouse를 지원해서 화면 하단의 section 선택 변경이나, 각 node의 볼륨을 직관적으로 변경할 수 있습니다.

node의 오른쪽의 output 기기를 mouse로 클릭하면 출력기기를 변경할 수도 있습니다. 기존의 pavucontol을 사용하던 유저라면 쉽게 적응할 수 있습니다.

좌) pavucontrl, 우) wiremix

빌드된 바이너리 패키지를 제공하지 않기 때문에 직접 빌드하여 사용해야 하는 번거로움이 있습니다. 단, Arch Linux는 공식 패키지 Repo에 등록되어 있으므로, pacman -S wiremix 나 paru -S wiremix-git로 설치할 수 있으며, Nix 사용자는 nix run nixpkgs@wiremix로 추가할 수 있습니다. Gentoo 사용자는 emerge -av wiremix로 설치하면 됩니다. ubuntu, debian, fedora 등의 Linux 배포판을 사용하는 사용자들은 cargo로 직접 빌드하여 사용해야 합니다. 빌드와 관련된 내용은 github에서 확인하실 수 있습니다.

Asahi Linux, Kernel 6.16 릴리즈

elsa in mac — Mon, 1 Sep 2025 20:39:04 +0900

2025/09/01 일 현재 Asahi Linux Kernel 6.16 이 공식 업데이트 등록되었습니다.

Kernel 6.16의 주요 변경 사항은 다음과 같습니다.

* 파일 시스템 성능 향상
ext4 의 성능 패치로 대용량 테이터 처리 시, 최대 37% 수준의 성능이 향상되었으며, XFS에서는 여러 블록을 원자적으로 기록하는 기능이 추가되어 쓰기 작업 중 데이터 손일을 방지하고 안정성이 향상되었습니다.

* USB Audio Offload
USB 오디오 장치를 사용하는 경우, CPU 개입없이 직접 데이터 스트림을 처리할 수 있게 됨.

* Intel의 새로운 명렁여 확장 세트인 APX(Advanced Performance Extensions) 지원을 위한 초기화가 진행되었습니다. 이 기술은 범용 레지스터의 수를 두 배로 늘려 성능과 전력 효율을 향상시킬 수 있을 것으로 기대되는 기술입니다.

* NVIDIA GPU 지원
NVIDIA GPU에 대한 오픈소스 드라이버인 Nouveau에 엔비디아의 Hpooer 및 Blackwell GPU에 대한 지원이 추가되었습니다.

Asahi Linux와 관련해서는 GPU 드라이버 개선 및 업스트림 병합이 되었으며.. OpenGL 4.6 및 Vulkan에 대한 공식지원이 완성되었습니다. 전원관리 컨트롤러인 SPMI(System Power Management Interface) 컨트롤러 드라이버가 커널에 추가되었으며, MacBook의 경우 Suspend 및 절전모드 지원이 강화되었습니다. 이는 향후 USB-C와 관련된 기능을 향상시키는데 초석이 될 것입니다. 오디오와 관련된 패치가 일부적용되었으며, 다음 버전인 6.17에서 완성될 것으로 보입니다.

6.16에서는 두렷한 성능향상이나 기능구현에 초점이 있기보다는 그 관련 패치를 kernel에 Upstream 하는 수준의 기반을 마련하는 데 있다고 볼 수 있으며, 6.17에서 보다 구체적이고 실효적인 업데이트가 있을 것으로 기대됩니다.

업데이트 후, Direct Rendering Infrastruvture 파일명이 변경되었습니다.

업데이트 이전에는 card0 , card1, renderD128 이렇게 있었는데, card0 가 없어지고, 대신 card2가 생겼습니다.(M1 mac mini 기준) Hyprland나 sway 등 wayland compositor를 사용하시던 분들은 업데이트 후에 WLR_DRM_DEVICES 설정을 /dev/dri/card0 에서 /dev/dri/card2 로 변경해야 합니다. 보다 기술적으로 말하자면,

위의 스샷에서 보는 바와 같이 WLR_DRM_DEVICES를 display-sybsystem 용 device로 mapping 해야 합니다. mac 기종 마다 다를 수 있기 때문에, 위와 같이 /sys/class/drm 의 내용을 확인한 후, 수정해야 합니다. 이점 참고하시기 바랍니다.

그리고, sensors를 실행했을 때, 출력되는 내용에도 변경이 있습니다.

PA Semi SMBus adapter 가 인식이 됩니다 만. 아직 Fan 속도 제어는 할 수 없는 것 같습니다.

Asahi Linux의 Mesa Driver 개발자인 Alyssa Rosenzweig 사임.

elsa in mac — Wed, 27 Aug 2025 16:43:42 +0900

오늘은 Asahi Linux와 관련하여 슬픈 소식이 전해졌습니다.

Asahi Linux 개발 초기부터 함께 해 왔던 GPU Driver 개발자인 Alyssa Resenzweig가 자신의 블로그를 통해, Asahi Linux와 관련된 자신의 목표가 달성되었다며, 관련된 작업을 마치고 개발팀을 떠난다고 밝혔습니다.

누군가는 Apple Silicon에 Linux를 Bare Metal로 이식하고 사용할 수 있다는 것이 꿈같은 일이라고 했지만, Hackter Martin, Asahi Lina와 더불어 이를 가능케 하는데 주역이었던 Alyssa 등의 리버스 엔지니어들이 이를 가능케 했습니다. 정말 놀라운 프로젝트입니다.

Rosenzweig(로젠바이크)는 자신의 블로그 글에서

"저희는 꿈도 꾸지 못했던 성공을 거두었습니다. 제가 추가했던 도전들을 모두 해결했습니다. HoneyKrisp 드라이버는 Mesa에 완벽하게 구현되어 있습니다. 성능도 나쁘지 않습니다. Apple이 품고 있던 Vulkan에 대한 오해가 깨지면서, 이제 저의 작업을 기반으로 LunarG의 KosmicKrisp 프로젝트를 통해 Vulkan 이 macOS에 적용됩니다."
라고 적었습니다.

LunarG의 KosmicKrisp 프로젝트는 Apple의 Metal Graphics API에서 직접 Vulkan을 구현하는 프로젝트 입니다. 현존하는 MoltenVK는 Vulan API 호출을 Metal API로 번역하는 Vulkan-to-Metal Translation Layer 이죠. 이 프로젝트는 특히 Google과의 협업을 통해 macOS 환경에서 Android Emulator의 GPU 성능을 향상시키는 것을 목표로 하고 있으며, 최종적으로는 Mesa에 병합하게 될 것이라고 합니다.

- - - - -

Asahi Linux를 사랑하는 사용자들은 M1/M2를 넘어 M3/M4 mac에서도 Asahi Linux가 포팅 되기를 기대하며 응원하고 있지만, Open Source Project란 늘 그렇듯이 강제성도 없고, 개발자의 열정과 목표가 체워지만 그 생명을 다할 수 있다는 잠재적인 단점이 늘 있습니다. Asahi Linux를 매일같이 사용하는 사용자의 한 사람으로써, 그녀의 사임은 아쉽지만.. 목표를 달성했으니, 또 자신의 새로운 목표를 향해 가야 합니다. 남겨진 휼륭한 결과물은 또 누군가 이어받아 발전 시켜 나아가겠죠.

Asahi Linux, Kernel 6.15 릴리즈

elsa in mac — Mon, 25 Aug 2025 08:10:35 +0900

한국시각, 2025/08/25일 dnf 공식 package manager repository에 kernel 6.15 업데이트가 등록되었습니다.

X86_64 같은 다른 아키텍쳐 보다 꽤나 늦게 등록이 된 것인데요. 대략 1달 이상 지체된 것 같습니다. 아마도 내부적으로 테스트하고 검토하느라 시간이 걸린 것 같습니다.

이번 Kernel 6.15 는 많은 부분에서 개선이 이뤄진 것으로 알려져 있습니다.

Linux Kernel 6.15 버전은 비동기 인터페이스인 io-uring에 zero-copy receive) 기능이 추가 되었는데, 네트워크 데이터가 커널 메모리를 거치지 않고 Direct로 애플리케이션 메모리로 전달될 수 있기 때문에 성능 향상이 기대 됩니다. 스켸쥴러 정보를 이용하여 latency profiling(지연 시간 프로파일링)을 수행할 수 있는 기능이 추가되었고, AMD/Intel/NVIDIA의 최신 칩셋 지원이 추가되었습니다.

Asahi Linux와 관련해서는, Apple Silicon을 지원하기 위한 그래픽 스텍(Honeykrips)에 대한 Kernel Upstream이 완성되었구요. GPU 준가상화(paravirtualise)를 위한 DRM Native Context 지원이 강화 되어, VM(가성머신)에서 호스트의 GPU 드라이버의 Userspace Component를 실행할 수 있게 됨으로써, 가상머신 사용시 GPU 성능이 향상되게 됩니다.

M1/M2 MacBook 의 TouchBar 디스플에이 및 이에 대한 터치스크린 기능 지원이 추가되었고, HDMI 포트에 대한 HDMI 오디오 지원을 강화되었으며. (일부 모델은 여진히 오디오 glitch가 발생할 수 있음) USB3, 오디오 해드폰 잭, 백라이트, 전원관리등 그동안 미비했던 부분들에 대한 지원도 강화 되었습니다.

또한, Explicit Sync 가 이제 정상적으로 적용되었습니다.
Explicit Sync(명시적 동기화)는 Implicit Sync(암묵적 동기화)와 대비되는 것으로 그래픽 파이프라인 혹은 그래픽 스택에서 GPU와 CPU간의 작업 동기화를 명시적으로 관리하는 방법입니다. 불필요한 동기화 대기를 줄이고 프레임 렌더링 작업이 완전히 끝나지 않은 상태에서 다음 프레임을 준비할 수 있는 등 성능을 높힐 수 있어 GPU와 CPU의 병렬처리 성능 향상 및 시스템 전체의 지연시간을 최소화 할 수 있습니다. 또한 여러 layer를 합성할 때 각 layer의 동기화를 이룰 수 있어 보다 더 부드러운 화면을 표현할 수 있습니다.

- - - - -

M1/M2 mac 모델마다 지원여부나 기능활성화 여부가 각기 다를 수 있다는 점은 염두해 두시기 바랍니다.

Asahi Linux 관련해서는 Kernel 6.16 이 준비 중이고, 오늘 배포된 6.15에서 특별한 문제가 발견되지 않는다면, 이번달 말 혹은 다음달 초에는 6.16이 릴리즈 될 것으로 보입니다. Linux 전체적으로는 현재 6.16 버전이 사용중이며 6.17 RC 버전이 릴리즈 되어 있는 상태 입니다.

[Linux 초보 탈출] Linux Memory 관리 - zswap 에 대해 알아 봅시다.

elsa in mac — Sat, 23 Aug 2025 23:04:36 +0900

이 포스트는 Fedora Linux를 기준으로 작성되었습니다.

이번 포스트에서는 Linux에서 RAM Cache를 제공하는 Kernel 기능인 zswap에 대해 함께 알아보도록 하겠습니다.

Prologue

일반적으로 컴퓨터에서 애플리케이션을 실행하면 실행코드와 데이터 정보가 메모리로 상주하여 동작을 하게 됩니다. 바뀌 말하면 애플리케이션이 실행되기 위해서는 메모리를 사용해야 한다는 말입니다.

GUI 환경에서 Multitasking 이 기본인 오늘날에는 사용자의 workflow에 따라 매우 많은 프로그램들이 동시에 실행되어 사용되게 됩니다. 당연히 사용자가 실행한 이 모든 app 들은 제각각 자신들이 필요로 하는 만큼의 메모리를 사용하게 되므로, 컴퓨터의 가용한 메모리 용량은 점차 잠식되게 될 것입니다. 컴퓨터의 메모리 용량은 제한적이기 때문에 경우에 따라서는 메모리 용량보다 훨씬 많은 메모리 사용을 요구할 수도 있겠지요.

이렇게 애플리케이션의 메모리 사용량이 점점 증가하여 메모리의 한도를 초과하게 되면 컴퓨터는 애플리케이션을 더 이상 실행할 수 없는 상황이 되어 극단적인 판단을 하게 되는데, 시스템을 관장하는 중추적인 역할을 담당하는 Kernel 은 이러한 OOM(Out Of Memory)을 극복하기 위해 OOM Killer라는 메커니즘을 동작시켜, 메모리를 많이 사용하고 있는 프로세스를 강제로 종료하여 시스템 메모리 자원을 확보하게 됩니다. 시스템이 뻣어버리는 것보단 애플리케이션 하나를 종료시키는 것이 더 나은 선택이라고 보는 셈입니다.

메모리 부족에 대응하는 관리 기법

Disk Swap (디스크 스왑)
OOM killer 메커니즘이 극단적인 메모리 자원 확보 방법이라면, 예방적인 대응 전략도 있습니다. 즉, OOM이 발생하기 전에 평소에 사용빈도가 낮은 데이터 페이지나 수정되지 않은 파일 캐시(cache)를 디스크의 스왑 영역으로 이동시켜 RAM의 여유 공간을 확보하는 방법입니다. 우리는 이것을 Memory swap(스왑)이라고 하며, 가장 고전적인 방법입니다.

Cache라는 용어는 프랑스어의 cacher에서 유래한 것인데, "숨겨진 곳"이라는 뜻입니다. 컴퓨터 분야에서는 고속으로 데이터를 사용하기 위한 임시 저장소를 의미합니다. 컴퓨터에서는 데이터를 매우 다양한 저장장치에 저장합니다. CPU에 가까울수록 빠르게 데이터를 처리할 수 있지만, 그만큼 비싼 기술입니다. 반대로 CPU로부터 멀면 멀수록 속도는 느리지만 기술 비용은 저렴합니다. 오늘날 일반적인 컴퓨터는 L1, L2, L3 Cache라는 고속 메모리를 갖고 있습니다. 물론, 이들 cache memory는 대부분 CPU 칩 내부에 포함되어 있습니다.

CPU는 특정 메모리 주소에 접근하려 할 때, 만일 해당 데이터가 현재의 RAM에 없고 Swap 영역에 있다면 Page Fault가 발생하게 됩니다. 이 경우 Kernel 은 페이지 테이블을 참조하여 해당 페이지가 디스크의 swap 영역 어디에 있는지를 확인하게 되고, 해당 페이지를 다시 Memory로 불러와서 사용하게 됩니다. 만일 해당 페이지를 불러올 메모리 영역이 여전히 부족하다면, 다른 사용 빈도가 낮은 페이지를 swap 영역으로 보낸 후, 필요한 페이지를 불러오게 됩니다. 이렇게 메모리의 페이지를 디스크의 swap으로 보내는 것을 swap-out 이라고 하고, 반대로 필요해서 swap 영역에 보관되어 있던 데이터 페이지를 다시 메모리로 불러오는 것을 swap-in 이라고 합니다. 디스크 저장공간에 대한 이러한 I/O 는 메모리에 비해 매우 느리기 때문에 swap-in/out 이 발생할 경우 약간 버벅거리는 시스템 성능저하의 원인이 됩니다.

zram (지램)
Disk swap 은 일부 성능 저하를 감수하더라도 시스템의 안정성과 애플리케이션의 실행을 담보하는 방법입니다. 한 가지 고려를 해야 한다면 가급적 swap이 발생할 확률을 낮추어 전반적인 시스템 성능 저하의 발생 빈도를 줄이는 것이 좋겠죠. 그래서 나온 아이디어가 zram 입니다.

zram은 zero ram의 약자로 disk swap을 완전히 사용하지 않거나(zero) 최소화한다는 개념입니다. 원래 처음 개념이 나왔을 때는 compcache(compressed cache: 압축 케시)로 명명되었지만, kernel에 통합되면서 zram으로 변경되었습니다.

원래 이름 그대로 compress 즉, swap을 하는 대신, swap의 대상이 되는 메모리 페이지를 RAM 안에서 압축을 해 놓는다는 발상입니다. 메모리에서의 I/O(input/output, 입출력) 처리속도는 일반적인 디스크 저장장치와 비교할 수 없을 만큼 빠르기 때문에 압축 및 압축해제를 반복하더라도 디스크로 swap을 하는 것보다 훨씬 효율적이고 빠르게 처리할 수 있다는 것이 기본 아이디어입니다. 즉, zram은 swap을 대치하는 것이 아닌 swap을 보안하는 기술로 휴대폰 같은 모바일 기기나 임베디드 시스템 같이 NAND Flash Memory를 저장장치로 사용하는 기기가 등장하면서 나온 것입니다. NAND Flash Memory는 쓰기 작업에 취약하고 수명이 짧다는 단점이 있는데, 이런 환경에서 swap을 적용할 경우 기기의 수명단축 혹은 성능저하를 유발할 수 있었기 때문이었습니다.

zswap(지스왑)
명칭만 보면 zram + swap과 별반 다를 게 없는 기술처럼 보이지만, zram + disk swap을 사용하는 것과 zswap은 좀 다른 차이점이 있습니다. kernel 입장에서 볼 때 zram은 그 자체가 독립적인 장치입니다. 즉, RAM의 일부영역을 할당하여 Block Device를 생성하고, 이 Device를 swapon 명령을 이용하여 swap 영역으로 설정하는 방식입니다. 고전적인 swap을 Disk 장치를 사용함으로써 성능저하의 단점이 있다고 하니, "그럼 swap 장치를 RAM에 만들면 되겠네~"라는 개념입니다.

그러니까.. 시스템에 zram과 swap을 둘 다 활성화한 경우, 둘 다 swap 장치이이고 다만 swap의 우선순위만 일반적으로 zram이 disk swap 보다 우선되는 방식인 셈입니다. zram을 활성화한 경우, 메모리 부족상태가 발생 시, 우선 zram을 이용하여 메모리 상에서 데이터 페이지를 압축 보관합니다. 하지만, zram 마저도 가득 차게 되면, 그때 비로소 disk swap을 사용하게 됩니다. 즉, zram은 단순히 1차 swap의 역할인 셈입니다.

zswap은 compressed RAM Disk 장치가 아닌 compressed swap cache로 인식됩니다. zswap에서는 별도의 독립된 swap 장치를 만들지 않습니다. 디스크 swap 이 필요해지면 데이터 페이지를 swap으로 보내는 대신 마치 memory cache처럼 RAM에 할당된 자체 풀에 압축 저장합니다. 만일 swap cache 영역이 가득 찬 이후에도 여전히 swap 이 필요한 경우, 기 압축된 페이지를 디스크 swap으로 보내고 새롭게 swap 될 데이터 페이지를 압축하여 swap cache에 새롭게 등록하게 됩니다. swap 대상은 가장 사용빈도가 낮을 확률로 선택되기 때문에 가장 먼저 swap 된 데이터 페이지가 언제나 재 사용될 확률이 가장 낮은 것입니다. 따라서 zswap의 이러한 운영방식은 여전히 유효합니다.

zram + swap을 사용하는 경우, swap 장치가 2개로 보인다.

zswap + swap을 사용하는 경우, swap 장치는 1개로 보인다.

zram + swap에서는 1차 swap, 2차 swap 장치의 개념이기 때문에, 우선 1차 swap 인 zram을 먼저 사용하고 zram이 가득 차면 zram은 그대로 놔두고 2차 swap인 디스크 swap을 보조적으로 사용하는 방식입니다. 즉, 사용빈도가 비교적 더 높은 가장 최근의 데이터 페이지가 오히려 더 느린 디스크 swap 장치에 저장될 수 있다는 단점이 있는 것입니다.

zswap을 설정 방법

자, 그러면 zswap을 설장하는 방법에 대해 알아봅니다.

우선, zswap을 사용하기 위해서는 kernel이 이를 지원해야 하는데, 최소조건은 kernel 3.11 이상이어야 합니다. 최근의 kernel은 6.xx 이므로 거의 대부분의 Linux에서는 이를 사용할 수 있습니다. 다만, 커널을 빌드할 때 CONFIG_ZSWAP, CONFIG_ZPOOL 옵션으로 빌드가 되어 있어야 합니다. 물론, 이 역시도 Kernel 기본 옵션으로 빌드되기 때문에 문제가 없을 것으로 판단됩니다.

마지막으로 확인해야 할 것은 kernel booting 옵션입니다. kernel의 부팅 옵션에 zswap과 관련된 kernel parameter가 명시되어 있어야 하는데, 이를 확인하는 방법은 아래와 같습니다.

/etc/default/grub (fedora Linux 기준) 파일을 보면, 위의 스샷과 같이 GRUB_CMDLINE_LINUX에 zswap.enabled=1 이라고 되어 있는 것을 확인할 수 있습니다. 이것이 zswap을 사용하겠다는 파라미터가 됩니다.

그 밖에 zswap과 관련된 몇 가지 parameter들을 설정할 수 있는데, zswap.compressor는 압축기법을 어떤 것을 사용할 것인가를 명시하는 것으로 zstd, lz4, lzo 에서 선택할 수 있습니다. lz4가 압축/해제가 가장 고속이자만 대신 압축률이 낮고 반대로 zstd는 속도와 압축의 균형감이 가장 좋습니다.

zswap.max_pool_percent 는 전체 물리적인 메모리 용량 중 zswap 캐시로 몇 %를 사용할 것인가를 명시하는 것입니다. 예를 들어, 물리적인 RAM이 8GB이고, max_pool_percent를 20으로 설정했다면 1.6GB(8 x 0.2)를 zswap 캐시로 사용하겠다는 의미가 됩니다. 이 것은 RAM에서 1.6GB를 reserved(예약) 하겠다는 의미가 아니며, 최대치라는 것도 상기할 필요가 있습니다. 즉, kernel이 판단했을 때, swap 이 필요하다고 했을 때, 대상 데이터 페이지를 압축하고 이를 zswap 캐시에 채우게 됩니다. 만일 swap이 더 많이 발생하여 1.6GB를 모두 채우게 되면, 앞서 설명한 대로 가장 먼저 채워진 페이지부터 disk swap으로 이동하게 됩니다. 이 경우 kernel은 압축을 해제하여 disk swap으로 보내게 됩니다. 만일 disk swap 까지 이동할 필요가 없을 경우에는 RAM 내부에서 압축/압축해제가 고속으로 이뤄지게 될 것입니다.

물론 zswap 캐시가 체위지만 그만큼 RAM에서 애플리케이션이 사용할 메모리의 양은 줄어들게 될 것입니다. 따라서, max_pool_percent 값을 너무 크게 하면, swap 이 발생할 경우 애플리케이션이 사용할 메모리가 그만큼 작아지는 단점이 발생할 수 있습니다. 반대로 이 값을 너무 작게 잡으면 zswap을 사용하면서 기대하게 되는 저속 disk swap으로의 swap-in/out이 빈번히 발생하여 성능저하가 나타날 수 있게 됩니다.

그럼 어느 정도의 percent로 정하는 것이 좋을까 ??
이것 또한 절대적인 수치는 없습니다. 이것은 사용자 컴퓨터의 메모리 용량의 크기에 따라 다를 수 있으며 사용하는 app의 종류나 동시에 얼마나 많은 app을 사용할지에 따라 달라질 수 있습니다. 다만 앞서 언급한 장/단점의 상황을 고려할 때 10% ~ 20% 정도가 권고됩니다. 8GB 라면 800MB ~ 1.6GB 정도가 되겠네요.. 만일 RAM이 16GB이지만, 평소에 웹서핑이나 터미널 몇 개 띄우는 수준이라면 zswap을 사용할 필요조차 없을 수도 있습니다.

zswap.zpool 은 메모리 할당에 대한 할당관리자를 지정하는 것입니다. zmalloc은 일반적으로 호율적이고 인정적인 성능을 제공하는 기본값입니다.

zswap.accept_threshold_percent 는 zwap이 새로운 페이지를 캐시에 저장할지의 여부를 경정하는 임계값으로 zswap의 캐시가 accept_threshold_percent 보다 낮을 경우에는 swap 데이터 페이지를 압축하여 캐시에 체우지만, 이 값보다 더 크게 되면 압축하여 zswap 캐시에 추가하지 않고 그대로 disk swap으로 보내게 됩니다.

이해가 어려울 수 있으니 예를 들어 봅니다.
accept_threshold_percent를 50으로 설정했다고 가정을 해 봅니다. zswap 캐시가 max_pool_percent로 지정한 크기의 50% 미민일 경우에는 무조건 압축하여 zswap 캐시에 저장합니다. 하지만, threshold_percent를 초과하게 되면(=max_pool_percent의 50%를 초과) 이때부터는 압축효율을 테스트한 후에 압축효율이 높을 경우에는 zswap 캐시에 계속 추가하지만, 압축효율이 높지 않다고 판단하면 zswap에 넣지 않고 그대로 disk swap으로 보내게 됩니다. (이 경우도 아직 zswap 캐시는 max_pool_percent에는 도달하지 않았을 수 있음). 그리고 마침내 zswap 캐시가 max_pool_percent에 도달하거나 초과할 경우 가장 오래된 압축 페이지를 압축을 해제하여 disk swap으로 보내게 됩니다.

배포판에 따라서는 zswap이 기본적으로 활성화되어 있을 수 있습니다. zswap이 설정되어 동작 중인지를 확인하는 방법은 터미널에서 cat /sys/module/zswap/parameters/enabled 를 읽었을 때 Y 가 출력되면 동작중인 것이고, N 이 출력되면 비 활성화 되어 있는 것입니다.

만일 zswap이 활성화 되어 있지않아서, 활성화를 해야 한다면, 위에서 본 봐와 같이 /etc/default/grub 파일을 수정한 후, grub.cfg를 업데이트 하기 위해 아래와 같이 명령내린 후 rebooting 하면 됩니다.

zswap을 사용해야 하나 ?

zswap을 사용할지 말지의 여부는 앞서 설명에서처럼 사용자 컴퓨터의 RAM 용량 대비 사용환경에 따라 달라질 수 있습니다. 컴퓨터 RAM이 64GB 이지만, 평소에 메모리를 많이 소모할만한 큰 app을 실행할 일이 없다면 zswap은 물론 disk swap 조차도 활성화할 필요가 없을 것입니다. Linux라면 기본적으로 부팅했을 때 KDE나 GNOME 같은 Desktop Edition을 사용한다고 가정하더라도 아무리 많이 잡아먹어봤자 4~5GB 수준일 것이기 때문입니다.

하지만, 8GB 혹은 그 미만에서 KDE나 GNOME 같은 DE를 사용한다면 zswap을 충분히 고려해야 합니다. 필자의 경우에도 8GB mac mini를 사용하고 있기 때문에 KDE나 GNOME 같은 DE는 당연히 사용하지 않고 있고, Wayland Compositor를 직접 만들어 사용하고 있습니다. 그래서 웹브라우저에 3~5개 정도의 tab을 띄우고 터미널 2개와 GUI widget 3~4 개 정도를 띄우고 사용하는데 대략 2.5GB 정도의 여유가 있을 수준입니다. 물론 zswap을 필수로 사용해야 합니다. ^^

반대로 RAM이 16GB 라도 동영상 편집 app이나 image 관리 app, 혹은 고용량 게임, 혹은 LLM 같은 AI를 로컬로 돌리는 경우에는 RAM이 부족해질 수도 있습니다. 만일 게임 같이 규모가 큰 app을 실행했을 때 OOM이 발생해서 app이 강제 종료되거나 시스템이 불안해지는 경험을 했다면 이를 고려해야 합니다.

Asahi Linux, Apple Type-C PHY driver patchset 에 대한 RFC가 Linux kernel mailing list에 등록되었습니다.

elsa in mac — Fri, 22 Aug 2025 18:14:38 +0900

최근에 Asahi Linux와 관련된 매우 기쁜 소식이 전해 졌습니다.

포스트 제목 그대로 Asahi Linux Team에서 Apple Silicon Mac의 ATCPHY Kernel Driver patchset에 대한 RFC가 Kernel Mailing List에 등록되었습니다.

ATCPHY는 Apple Type-C Physical Layer의 약자로 apple silicon mac이 자체적으로 설계한 USB-C 포트 제어 칩을 의미합니다. 이 칩은 USB 2.0, USB 3.X, USB 4/Thunderbolt 및 DisplayPort 등의 프로토콜을 지원하는 것은 물론 이들 모든 인터페이스에 대한 Multiplexing을 처리합니다.

patchset이라는 것은 여러 개의 patch를 묶어 놓은 것을 의미하며, ATCPHY 칩을 Linux Kernel에서 인식하고 이를 올바르게 동작시킬 수 있는 코드 변경 사항들을 말하며, RFC(Request For Comments)를 등록했다는 것은 개발자 혹은 개발팀이 작성한 코드를 Linux Kernel에 공식적으로 포함시키기 전에 다른 Linux Kernel 개발자들에게 Kernel에 포함시킬 경우 문제가 없을지 검토와 피트백을 요청하는 중요한 절차입니다.

아직까지 Asahi Linux는 크게 3가지 정도가 부족합니다. 첫 번째는 동영상에 대한 H/W Encoding/Decoding, 두 번째는 USB4/Thunderbolt를 이용한 고속 외장 저장장치 사용여부, 그리고 마지막으로 USB-C를 통한 DP-Alt 모드를 이용한 Multi-Monitor 환경 구축 등이 그것이죠. DP-Alt(DisplayPort Alternate) 모드란 USB-C 케이블 하나로 데이터, 전력, 비디오 신호를 한꺼번에 전송할 수 있게 해주는 기능을 말합니다.

동영상에 대한 H/W 가속처리를 제외하고 나머지 두 가지는 서로 연관성이 있고, 이번 RFC가 이와 관련된 것이니 완성된 것은 아니지만 지금껏 기다려왔던 기대에 한 발짝 더 다가가고 있다는 그리고 본격적으로 관련 Driver 개발에 착수하고 있다는 긍정적인 신호라고 볼 수 있을 것 같습니다. 예상하기로는 실제로 완성되어 사용자들이 사용할 수 있기까지는 앞으로도 꽤 오랜 시간이 걸릴 것 같아서 빨라야 올해 말, 아니면 내년 중/후반은 되어야 하지 않을까 생각됩니다.

- - - - -

애플의 H/W는 다들 아시는 바와 같이 설계스펙이나 처리 프로세싱이 공개되지 않은 매우 폐쇄적인 시스템입니다. 그래서 공개되지 않은 기술적 요구사항을 스스로 해결해야 하는 어려움이 있고, 그로 인해 타 배포판들보다 구현정도나 진행속도가 느리다는 단점이 있지요. 하지만, 아이러니컬하게도 이러한 폐쇄성 때문에 Asahi Linux는 기타 다른 Linux 배포판과는 달리 설치가 간단하면서도 H/W 지원이 꽤나 안정적이고 최적화가 잘되어 있습니다. 그래서 M3 나 M4 칩을 사용하는 최신 mac에 대한 지원을 열망하는 이유이기도 하지요. 이번 ATCPHY 관련된 패치가 완성된다면, 그 후에나 본격적으로 M3/M4 mac 지원에 집중할 수 있을 것 같습니다.

Github를 통한 악성코드 배포를 주의하세요.

elsa in mac — Tue, 19 Aug 2025 20:56:45 +0900

최근 들어 macOS와 관련된 Github Open Project를 교묘하게 베낀 가짜 사이트를 통해 maleware를 배포하는 사이트들이 늘고 있어 주의가 필요해 보입니다.

사용자들이 많이 사용하는 사이트를 그대로 모사하여 만들어 피해를 주는 "피싱사이트" 와 유사한 방식입니다.

레딧에 올라온 PSA(Public Service Announcement:공익광고)글을 보면, macOS app 개발자가 발견하여 github에 제보한 것으로, 사용자들이 Github에 올라온 프로젝트를 무조건 신뢰해서는 안된다는 것을 경고하고 있습니다.

일단 Github을 단순 검색하여 방문하고 해당 app을 다운로드 받아서 설치 및 사용하는 것은 조심해야 합니다. 평소에 신뢰할 만한 링크를 통해 Github에 방문하는 것이 좋습니다. 대부분의 공개 앱이라면 우선은 각 OS의 패키지 관리자(package manager) 저장소에도 등록이 되어 있는지의 여부를 확인하고 있다면 패키지 관리자를 통해 설치 및 사용하는 것을 추천합니다. 패키지 저장소에 등록되면 해당 앱의 URL정보가 있기 때문에 보다 더 최신 버전을 사용하고자 한다면, 해당 URL로 방문하는 것이 안전합니다. macOS라면 app store, homebrew를 Linux라면 dnf, pacman, apt 등을 이용하세요. 적어도 공식 패키지 저장소에 등록이 되어 있다면 신뢰성이 높다고 볼 수 있습니다.

만일 Package Manger로 검색했을 때, 검색되지 않을 경우에는 Raddit 등에서 관련 앱에 대한 정보를 확인하는 것이 필요하고, 잘 알려지지 않은 앱의 경우 가급적 설치를 하지 않는 것이 좋습니다. 그래도 필요하다면 소스코드를 충분히 검토해 보는 것이 좋겠죠.

검색창에서 앱 이름으로 검색할 경우, 해당 Github 사이트가 Fork 사이트인지의 여부도 확인을 꼭 해야 하며, 특별한 사정이 없다면 업스트림(Upstream) 저장소로 이동하여 다운로드 받는 것이 좋습니다.

등록된지 꽤 시간이 경과했음에도 불구하고 commit 등의 project 활동이 없다면 이 또한 경계해야 합니다. 물론, 별점이 적거나 활동이 없다고 해서 모두 악의적인 사이트라고 단정지을 수는 없습니다. 하지만, 해당 앱에서 제시하는 기능이나 성능이 누가봐도 월등히 좋고 매력적이라면 당연히 인기도 많고 사람들의 review나 제안등이 높을 수 밖에 없습니다.

- - - - -

평소에 별 의심없이 Github을 사용해 왔더라도 최근에 유사한 사례들이 늘고 있다고 하니, 좀 더 경각심을 갖아야 될 것 같습니다.

Linux에서 Wayland Compositor를 사용하시나요? 그럼 고양이 한마리 들이세요.. - Bongo Cat Wayland Overlay

elsa in mac — Thu, 7 Aug 2025 20:17:59 +0900

2025년 8월 첫째 주, 최근 새로 개설된 따끈따끈한 Github Project 하나를 소개합니다.

프로젝트명은 제목처럼 Bongo Cat Wayland Overlay 입니다. Linux에서 Sway, Hyprland, DWM 등등의 Wayland Compositor 또는 Wayland 기반의 KDE (GNOME은 지원 안됨) 등에서 사용가능한 Keyboard 관련 EyeCandy 입니다.

Bongocat은 인터넷 밈(meme)의 한 종류로 탁자를 두 손으로 두드리는 흰 고양이를 묘사한 GIF 이미지 입니다. 이 이미지는 마치 봉고 드럼을 연주하는 것처럼 보이기 때문에 Bongo Cat 이라는 애칭이 붙었습니다.

Wayland Compositor는 개발자의 의도에 따라 매우 다양한 layer 계층을 만들 수 있는데, 표준으로 background, bottom, top, overlay 이렇게 총 4개의 기본 layer들을 갖고 있습니다. 실행할 GUI 앱을 어떤 Layer에 배치하느냐에 따라, 바탕화면처엄 always botoom 혹은 always top 으로 표시할 수 있는데, 프로젝트 명에 있듯이 가장 최 상위 층인 overlay layer에 배치됩니다.

설정파일을 통해 사용자가 사용하는 keyboard나 mouse의 device 파일을 정의해 주면, 해당 장치에서 입력이 들어 올때 마다, 고양이가 그에 맞춰 오른손/윈손을 두들기는 keyboard synced animation을 볼 수 있습니다.

원래 제작자는 waybar 같은 statusbar 앱의 가장차지레에 배치하여 사용할 의도로 기획하였지만, 필자는 waybar를 사용하지 않고 있을 뿐만 아니라, Wayland Compositor를 직접 만들어 사용하고 있기 때문에, 해당 프로젝트의 소스코드를 약간 수정해서 아래와 같이 Focused Windows의 상단 중앙에 배치되도록 했습니다. 매우 귀엽네요..

config 파일을 통해, 고양이의 크기 및 x,y offset, overlay 위치(top/bottom) 그리고, FPS 와 매핑할 정치등을 설정할 수 있습니다. 설치 및 실행과 관련된 dependencies, 설정 관련된 자세한 정보는 github에서 확인하실 수 있습니다.

waybar와 함께 사용하면서, waybar 영역에 위치하고자 할때는 waybar보다 나중에 실행해야 합니다. (wayland를 overlay로 사용하는 경우)

화면 상단이나, 하단이 아닌 특정 위치에 표시하고자 할 경우에는 설정파일에서 overlay_height를 화면의 height 크기, 그러니까 예를 들어 화면이 3840x2160 해상도라면, overlay_height=2160으로 한 후에, cat_x_offset과 cat_y_offset를 적당히 변경하여 배치하면 됩니다. opacity는 대부분 0(배경 완전 투명)으로 설정하고 사용하게 될 것입니다.

아직, 초기 단계라 multi-monitor 지원등이 미비하지만 단일 모니터나 노트북에서 Linux를 사용하는 분들이라면 별 문제는 없어 보입니다.

Mesa 25.2 릴리즈

elsa in mac — Thu, 7 Aug 2025 17:56:47 +0900

꽤 오랜만에 Asahi Linux와 관련된 포스팅을 하는 것 같습니다.

오늘(2025-08-07) Mesa 공식 소스 Regository에 Mesa 25.2.0 최신 버전이 새롭게 등록되었습니다.

이번 버전에서는 OpenGL은 물론 Asahi Linux의 HoneyKrisp Vulkan Driver와 관련된 성능개선 사항이 꽤 많이 추가된 것으로 확인되고 있습니다.

openGL 성능 태스트

소스코드를 다운로드 받아 빌드 및 업데이트한 후에 성능 비교를 해 봤습니다. 간단히 glmark2-wayland로 테스트를 해 봤는데요. 기존 버전인 Mesa 25.1.0의 glmark2 score는 2239점, 그리고 금번 25.2.0 버전의 점수는 2600점으로 대략 16% 정도 향상된 것으로 확인되고 있습니다.

Vulkan 쪽에 보다 많은 개선이 있는 것으로 파악되는 바, 게임 관련 쪽에서 좀 더 확실한 성능상 진전이 있을 것으로 예상을 해 봅니다. (필자는 게임을 하지 않아서 확인은 못 했습니다.) 관련된 보다 자세한 내용은 Asahi Linux 블로그의 Linux 6.16 진행 보고서를 참고 하시기 바랍니다.

아직은 Fedora 공식 Package Manager 상으로는 등록이 안되었는제, dnf로는 업데이트 확인이 안 되는데, 조만간 등록되어 올라오지 않을까 생각됩니다.

[Linux 초보 탈출] 리눅스 파일 시스템에 대해 알아 봅시다.

elsa in mac — Thu, 24 Jul 2025 21:58:26 +0900

본 포스트는 Fedora Linux를 기준으로 작성되었습니다.

이번 포스트에서는 리눅스 파일 시스템에 대해 알아보겠습니다.

리눅스의 파일 시스템 전체를 이해한다는 것은 굉장히 방대한 지식체계입니다. 이것을 블로그 글 한 두 개로 다 설명할 수는 없겠지요. 본 포스트에서는 WIndows나 macOS를 사용하다가 Linux로 입문하는 분들이 WIndows 나 macOS와는 파일 시스템에서 어떤 차이가 있고, 리눅스를 사용하기 위해 파일 시스템과 관련하여 기본적으로 알고 있어야 하는 중요한 몇 가지를 살펴보도록 하겠습니다.

- - - - -

파일 시스템(File System 혹은 Filesystem)이란 컴퓨터의 저장장치에 데이터를 저장하고 관리하는 체계를 의미하는데, 데이터 관리 체계라 함은 굉장히 광의적인 표현으로 기본적으로는 데이터를 물리적 저장장치에 기록하거나 읽어오는 방법, 기록 형식 및 규칙, 데이터의 무결성 유지 방안과 함께, 저장된 정보들을 체계적으로 분류하고 권한을 통제하는 일련의 규칙을 포괄하는 것이라고 볼 수 있습니다.

우리가 흔히들 "파일 시스템"이라는 말을 사용할 때는 두 가지 측면의 의미가 있는데, 일상에서 "이거 NTFS로 포맷해줘, 아니야 FAT으로 포맷해야 해~" 이런 말을 사용할 때, NTFS 나 FAT... macOS라면 APFS, HFS+ 등등을 흔히들 파일 시스템이라고 지칭합니다. 반면, Windows 파일 시스템, macOS 파일 시스템, Linux 파일 시스템이라고 표현할 때는 저-수준(Low Level) 기술 규칙과 고-수준(High Level) 기술 규칙을 포괄하는 의미가 됩니다.

FAT, NTFS, APFS, ext4 등등의 파일 시스템은 저-수준 기술규칙을 지칭하는 것으로 데이터를 어떠한 방법으로 물리저장장치에 기록하고 읽어오는지, 데이터 무결성을 어떻게 유지할지, 효율성과 성능을 위해 특별히 어떠한 기능을 지원할지에 대한 것입니다. 사용자 입장에서는 이러한 것들을 직접적으로 알 필요가 없습니다. 내가 저장한 데이터가 SSD나 하드디스크에 어떠한 형식으로 어디에 어떻게 기록되고 관리되는지 알 이유는 없습니다.

고-수준 기술 규칙이라 함은 저-수준 기술 규칙이 무엇이던 상관 없이 사용자에게 데이터들이 어떻게 조직하고 어떻게 보여줄지, 어떻게 읽고, 쓰고, 실행할지 등에 대한 논리적인 규칙을 의미합니다. Unix-Like 운영체제들은 FHS(Filesystem Hierachy Standard)라는 규칙을 따르며 어떠한 저-수준 파일 시스템을 사용하든 동일하게 적용됩니다.

Linux를 사용하는 유저들은 바로 이 FHS가 무엇인지를 알아야 합니다. 왜냐하면 사용자가 Linux를 사용하려면 Linux 파일 시스템 규칙에 따라 데이터를 저장하고 참조하며 관리해야 하기 때문입니다. 이 부분은 특히 WIndows만 사용해 오던 유저들이 Linux를 사용하게 되면, 생소한 파일시스템 때문에 사용 초기 어렵게 느껴지는 부분이기도 합니다.

macOS와의 차이점은 살펴보지 않나요? 라고 궁금해하실 수 있는데, macOS의 kernel인 Darwin은 Unix를 기반으로 만들어진 것입니다. Darwin은 Unix 표준인 POSIX(Portable Operationg System Interface)를 준수합니다. 이 표준을 준수한다는 것은 Unix의 동작방식을 따르고 있다는 것을 의미합니다. 구체적으로 Darwin은 BSD와 Mach micro-kernel을 차용한 결과물입니다. BSD(Berkeley Software Distribution)는 미국 버클리 대학에서 개발한 운영체제이고, Mach는 카네기 멜론 대학에서 개발한 Kernel이지요. 이러한 이유로 macOS의 파일 시스템은 저-수준 파일 시스템은 Linux와 다르지만, 고-수준 측면에서는 Unix나 Linux와 완전히 동일하지는 않지만 대체적으로 동일합니다. 반면, WIndows는 Unix-Like 운영체제와는 완전히 다른 파일시스템 체계로 만들어진 운영체제입니다.

Everything is a File

Everything is a file... "모든 것은 파일이다." 이것은 Unix-Like 운영체제(이하 Linux)의 핵심 철학 중 하니입니다. Linux에서는 모든 것은 파일로 취급됩니다. 우리가 다루는 이미지 데이터, Text 데이터, 오디오 데이터는 물론, 키보드, 마우스, 모니터, SSD, RAM, CPU 등의 물리적인 장치들 또한 Linux에서는 모두 file 일 뿐입니다. 당연히 파일들을 담고 있는 디렉터리도 특별한 정보를 담고 있는 파일일 뿐입니다. 그래서 일반 파일을 관리하는 것과 똑같은 방식으로 디렉터리를 관리하게 됩니다. 이것은 뒤에서 좀 더 자세히 알아보도록 하겠습니다.

반면, WIndows에서는 이미지 데이터, Text 데이터.. 등등이 파일이고, 키보드, 마우스, 모니터 등은 장치들입니다. WIndows에서는 키보드, 마우스 등의 장치를 사용자가 직접 수정하거나 읽어보거나 기록하거나 할 수 없습니다. 굳이 장치에 접근하고자 한다면 Registry라는 장치 데이터베이스에 접근하거나 장치 드라이버를 제어하는 API를 이용해야만 합니다. 우리가 사용하는 word 파일이나 jpg 파일처럼 장치를 취급할 수 없습니다. Windows에서의 폴더는 File이 아니라 Container입니다. 리눅스에서는 파일을 다루는 open(), read(), write() 같은 표준 시스템 Call로 FIle과 동일하게 Directiory를 취급할 수 있지만, Windows에서는 파일을 취급하는 API와 폴더를 취급하는 API가 각각 따로 존재합니다.

이러한 이유로 Linux의 파일 시스템은 통일성과 유연성이 좋습니다.

루트 파일 시스템

흔히들 Linux 파일 시스템을 루트(Root) 파일 시스템이라고 부르곤 히는데, 이것은 Linux의 파일 시스템이 단일 계층적 트리 구조( Single hierarchical tree structure)이기 때문입니다.

root는 Linux 파일 시스템에서 최상위 계층을 의미합니다. root를 제외한 모든 파일과 디렉터리, 장치들은 root 디렉터리의 아래(하위)에 존재하게 됩니다.

** Windows나 macOS 에서는에서는 파일들이 위치한 곳을 지칭하여 폴더(folder)라고 표현하지만, Linux에서는 디렉터리(Directory)라고 표현합니다.

/ 은 root 디렉터리를 의미하며, /home 은 root 디렉터리 하위의 home 디렉터리를 뜻합니다(home이 디렉터리인 경우). /home/elsa라는 표현은 root 디렉터리 밑에 home 디렉터리 그리고 그 밑에 elsa 디렉터리라는 의미가 되겠죠(elsa가 디렉터리인 경우), 이 경우 home은 elsa의 상위 디렉터리 혹은 부모 디렉터리(Parent Directory)라고 하고 home 입장에서 elsa는 하위 디렉터리 또는 자식 디렉터리(Child Directory)가 됩니다.

반면, Windows의 경우는 디스크 또는 파티션마다 각각의 root가 독립적으로 존재하는 다중 계층적 트리 구조(multiple hierarchical tree structure)입니다. Windows에서는 파티션 또는 디스크마다 C:, D: E: 등 각 드라이브 문자가 개별젹이고 독립적인 root가 되고, 그 이하에 계층적 폴더 구조로 구성됩니다.

그렇다면, Linux의 단일 계층적 트리 구조와 Windows의 다중 계층적 트리 구조의 장/단점은 무엇일까?

WIndows의 다중 계층 구조는 직관적이라는 장점이 있습니다. C:는 운영체제, D:는 사용자 데이터, E:는 게임, F: 멀티미디어 보관소.. 등등.. 그리고, 파티션 관리도 쉽습니다. 특정 디스크나 파티션이 구분되어 있기 때문에 해당 디스크/파티션을 제각기 개별적으로 취급할 수 있습니다.

반면, Linux와 같은 단일 계층 트리 구조의 장점은 통일성에 있습니다. 직관성보다는 논리성을 강조합니다. 디스크가 3개가 연결될 때 각 디스크는 사용자가 지정한 Directory에 mount 즉 연동됩니다. 파티션이던 디스크던 정해진 이름은 없습니다. 유저 마음입니다. 디스크도 파티션도 그저 파일일 뿐이기 때문입니다. 파일에 정해진 이름이란 있을 수 없습니다. 따라서 직관성은 떨어집니다. 디스크를 마운트 한 유저 당사자는 특정 디렉터리가 디스크의 Mount point라는 것을 알지만, 옆 동료나 다른 사람이 볼 때 어떤 게 일반 디렉터리이고 어떤 게 연결된 외장 SSD인지 특별히 확인하지 않는 이상 알 수가 없습니다. 직관성은 떨어지지만 파일로 root의 하위에 가지를 하나 덧붙이는 것일 뿐입니다. 통일성이 유지됩니다. 그리고 유연합니다. 어느 하위 디렉터리이든 원하는 곳에 디스크를 붙일 수 있습니다. Windows라면 C 드라이브는 C 드라이브일 뿐 D 드라이브 밑에 붙일 수 없습니다. 직관성은 좋지만, 유연성은 떨어집니다.

권한(permission)

파일 시스템에는 권한(permission)이라는 중요한 개념이 있습니다. 이건 Windows를 포함한 모든 운영체제가 갖고 있는 개념으로 보안과 안정성을 담보하는 핵심 요소입니다.

Linux는 3가지 권한 범주와 3가지 권한이 있습니다.

3가지 권한 범위는 소유자(Owner), 그룹(Groups), 기타(Others)로 구분되는데, 소유자 권한이란 말 그대로 임의의 파일에 대한 사용자 소유권을 의미합니다. 그룹 권한은 여러 명의 사용자들을 하나의 그룹으로 묶어 부여하는 권한이고, 기타권한이란 소유자나 그룹에 속하지 않는 나머지 사용자의 권한을 의미합니다.

3가지 권한이란 읽기(read) 권한, 쓰기(write) 권한, 그리고 실행(execute) 권한을 말합니다.

읽기 권한이란 파일의 내용을 읽을 수 있는 권한이고, 쓰기 권한이란 파일의 내용을 수정하거나 생성 및 삭제할 수 있는 권한을 의미하며, 실행권한이란 파일을 실행하거나 디렉터리로 들어갈 수 있는 권한을 의미합니다.

Linux의 모든 것은 파일이라는 것을 다시 한번 상기하면서... 그래서 모든 파일들은 3가지 범주와 3가지 권한에 대한 정보를 갖고 있으며, 사용자는 이를 확인할 수 있습니다.

이러한 파일속성에 관한 정보를 메타데이터(metadata)라고 부릅니다. 메타데이터의 의미는 "데이터의 데이터"라는 뜻인데, meta는 그리스어에서 유래한 접두사로 "~에 관한"이라는 의미이고, meta와 data를 띄어 쓰지 않고 하나의 단어로 사용합니다.

/home 디렉터리에서 ls 명령을 내리면, 위와 스샷처럼 해당 디렉터리의 파일 목록(서브 디렉터리도 파일이죠)을 확인할 수 있는데, 특별히 l(소문자 L)을 주면 metadata 정보를 확인할 수 있습니다.

elsa라는 디렉터리 파일을 보면, 앞에 drwxrwx---@ elsa 이렇게 표시되어 있는 것을 볼 수 있습니다.

d는 해당 파일이 directory라는 의미입니다. 일반 파일이라면 . 으로 표시됩니다. rwx는 각각 Read(읽기), Write(쓰기), eXecute(실행)의 의미입니다. 3개씩 권한을 표시하는 것인데 3묶음으로 되어 있으니, 첫 번째 묶음은 소유권(Owner), 두 번째 묶음은 그룹(Groups), 그리고 세 번째는 기타(Owners) 권한을 표시합니다.

그리니까, drwxrwx--- 는 d rwx rwx --- 로 구분될 수 있고, 소유권이나 Groups의 구성원은 모두 읽고, 쓰고, 실행(디렉터리의 경우 진입)할 수 있지만, Others(소유권자도 아니고 같은 그룹에 속한 사람도 아닌 사람)은 --- 즉, 읽을 수도, 쓸 수도, 실행할 수도 없다는 것을 알 수 있습니다.

@는 기본 속성이 이 외에 확장속성(Extended metadata)이 설정되어 있다는 표시입니다. 이것은 어떠한 종류의 저-수준 파일 시스템을 사용하고 있느냐에 따라 달라집니다. 확장속성에는 보안 콘텍스트, 코멘트, 제작자 정보 등이 포함되어 있을 수 있으며, getfattr이라는 명령으로 확인할 수 있습니다. 물론 "확장속성 정보를 담을 수 있다는 의미"이지 모든 파일에 확장 속성 정보가 있다는 의미는 아닙니다.

그러니까 위의 스샷을 보자면.. 나는 elsa로 로그인을 했기 때문에 elsa라는 디렉터리에는 진입을 할 수 있지만, link 디렉터리는 진입을 할 수 없다는 것을 알 수 있습니다. 왜냐하면 elsa는 link가 아니기 때문이며, link 입장에서 elsa는 others 권한이기 때문입니다.

기본 디렉토리(Essential Directories)

자 그럼, 이제 Linux의 기본 directory에 대해 좀 설펴 봐야겠습니다. 다른 포스트에서도 잠깐 언급한 바가 있지만 Linux는 몇 개의 배포판들이 존재합니다. Red Hat 계열, Debian(데비안) 계열, Arch(아치) 계열이 그것인데요, 많이 사용하는 Linux Mint나 Ubuntu는 모두 Debian 계열입니다. Ubuntu는 Debian을 기반으로 만든 것이며, Linux Mint는 Ubuntu를 기반으로 만든 배포판입니다. Fedora는 Red Hat 계열이죠. 배포판은 다르지만 모두 HFS를 따르기 때문에 기본 디렉터리 구조는 동일하다고 볼 수 있습니다 만, 약간의 미묘한 차이가 있습니다.

root 디렉터리에서 ls 명령을 내리면, root 디렉터리의 하위 디렉터리들을 확인할 수 있습니다. 위의 스샷에서 Volumes는 본인이 만든 디렉터리이니 제외입니다.

/boot 디렉터리는 부팅(booting)에 필요한 파일들이 위치하는 곳으로 Kernel Image와 boot loader 설정파일등이 이곳에 위치합니다.

/dev 는 device(장치)의 약자로 키보드, 마우스, 다스크, 모니터 등 컴퓨터와 연결된 입출력(I/O) 장치 파일들이 위치한 디렉터리입니다.

/etc 는 시스템 전체의 설정 파일들이 위치한 디렉터리입니다. 사용자 계정 정보, 네트워크, 시스템 서비스 등등의 설정파일들이 이곳에 있습니다.

/proc 은 process(프로세스)의 약자로 실행 중인 프로세스와 시스템 정보를 담고 있는 가상 파일 시스템으로 실제 파일이 물리적인 디스크에 저장된 것이 아니라 메모리에 Kernel 이 생성한 정보들입니다. 이곳에는 시스템 메모리, CPU, 네트워크 상태 등 다양한 시스템 정보들이 포함되어 있습니다. 따라서, 파일들의 크기가 0으로 보이기도 하지만, 파일을 읽어보면 정보가 표시됩니다. (kernel 이 생성한 실시간 정보)

/sys 는 system의 약자로 시스템 하드웨어 정보를 담고 있는 가상 파일 시스템입니다. /proc 과 마찬가지로 메모리에 존재하며 하드웨어를 제어하는 데 사용됩니다.

/run 은 runtime의 약자로, 시스템이 부팅된 후에 실행되는 프로그램들이 임시로 데이터를 저장하는 데 사용되는 공간입니다. 과거에는 /var/run 이렇게 /var 밑에 위치했었지만 지금은 독립적으로 존재합니다.

/bin 은 binary이 약자로 모든 사용자들이 공통으로 사용할 수 있는 기본 실행파일들이 위치하는 곳입니다.

/sbin 은 system binary의 약자이며, 시스템관리자인 root 만 사용할 수 있는 시스템 관리 프로그램들이 위치한 곳입니다.

/var 은 variable의 약자로 시스템이 부팅되고 운영되는 과정에서 자주 변하는 파일들이 저장되는 곳으로, log, mail, 데이터 베이스 등이 이곳에 저장됩니다.

/tmp 는 temporary의 약자로 임시 파일들이 저장되는 공간입니다. 해당 디렉터리의 내용들은 시스템이 종료되거나 재 부팅이 되면 자동으로 모두 삭제됩니다.

/usr 는 user로 착각하는 사람들이 많은데, Unix System Resources의 약자로 운영체제에 필요한 대부분의 프로그램과 라이브러리들이 설치되는 곳으로 /bin 또는 /sbin 보다 훨씬 많은 프로그램들이 있는 곳입니다. 최근 Linux 배포판들은 /bin, /sbin, /lib, /lib64 등을 별도로 두지 않고, /usr/bin, /usr/sbin, /usr/lib, /usr/lib64 등을 Symbolic Link로 구성합니다. 초기 Linux 시스템에서는 / 만 mount가 되고, /usr 는 나중에 mount 되는 환경이었기 때문에 부팅에 필요한 도구들을 /bin /sbin에 별도로 구성했습니다. 하지만, 현재는 시스템들이 빵빵하기 때문에 굳이 이렇게 구분하지 않습니다. 다만, 과거로부터 사용해 오던 유저들에게 익숙한 운영환경을 제공할 목적과 빠르게 접근할 수 있도록 Symbolic Link를 해 놓고 있습니다. 이것을 "usr-merge를 적용" 했다고 합니다. debian 계열에서는 usr-merge 하지 않고, 과거 전통적인 기본 디렉터리 구성을 하고 있어 차이가 있었지만, 최신 배포버전에서는 usr-merge를 적용하는 것으로 알고 있습니다.

/media 는 USB 드라이브나 CD-ROM 같은 이동식 미디어가 자동으로 마운트딜 때 사용하는 디렉터리입니다.

/mnt 는 관리자(root)가 수동으로 파일 시스템을 임시적으로 마운트 할 때 사용하기 위한 디렉터리입니다.

/opt 는 optional의 약자로 별도의 추가 소프트웨어를 설치하기 위한 곳입니다

/root 는 시스템 관리자인 root 계정의 홈 디렉터리입니다. 일반 사용자의 홈 디렉터리인 /home과 구분하고 있습니다.

/srv 는 서버에 대한 서비스 관련 데이터가 저장되는 곳으로 웹 서버의 데이터들이 이곳에 저장됩니다.

/home 은 일반 사용자 계정의 홈 디렉터리로 사용자의 홈 디렉터리는 /home의 하위에 계정(id)과 동일한 이름으로 생성됩니다.

절대경로, 상대경로

다음으로 절대경로(Absolute Path)와 상대경로(Relative Path)에 대해 알아봅니다.

절대경로, 상대경로는 Windows를 포함하여 거의 모든 대부분의 운영체제들이 지원하는 개념입니다. Linux와 Windows의 두드러진 차이점 중 하나는 경로를 구분하는 경로구분자(path separator)가 다르다는 건데, Windows의 경우에는 \(백 슬레쉬) 인 반면, Linux는 /(슬레쉬)를 사용합니다. 그리고 Root가 Windows는 C: D: 같은 Drive 이름을 포함한 C:\ 또는 D:\ 인 반면, Linux는 경로구분자와 동일한 / 를 사용합니다.

리눅스가 경로구분자를 / 로 사용한데에는 이유가 있습니다. 초기 Unix를 개발하던 개발자들은 당연히 모두 프로그래머들이었고, C언어를 사용했는데, C언어에서는 escape 문자로 \를 사용합니다. 예를 들자면 \n (new line) 혹은 \t (tab) 등등.. 그래서 경로를 \로 사용하게 되면, 경로와 espace를 식별할 수가 없게 됩니다. 그래서 경로구분자를 /로 사용하게 된 것입니다. 참고로 윈도우에서는 \ 를 경로구분자로 사용하기 때문에 C 언어를 사용할 때 동일한 문제에 봉착하게 되는데, Windows에서는 escape와 경로 구분자를 식별하기 위해 \\ 를 사용했습니다. c:\\new_folder 이렇게 말이죠.

그럼, Windows 개발자들은 \ 이 escpae 문자와 혼용시 문제가 된다는 것을 몰랐을까?
Windows는 MS-DOS를 계승한 것이고, MS-DOS는 Microsoft사가 Seatle Computer Products라는 회사에서 개발한 QDOS를 사 와서 업그레이드한 것입니다. QDOS는 CP/M 이라는 운영체제를 기반으로 했는데, 이 CP/M의 파일시스템이 경로구분을 \으로 사용했었기에, 이것이 자연스럽게 MS-DOS에서도 그대로 사용되었고, Windows에서도 그대로 사용하게 됩니다. 흔히들 MS-DOS는 빌 게이츠가 개발한 것으로 알고 계신 분들이 간혹 있는데, MS는 원래 BASIC 이라는 프로그래밍 언어를 개발 및 판매하던 회사였습니다. IBM이 1980년대 개인용 PC에서 사용할 운영체제를 물색하고 있었고, 당시 표준은 CP/M 이였지만 둘 간에 협상이 불발되면서 운영체제 공급을 마이크로소프트에 의뢰하게 되었지요. 이예 MS는 QDOS의 라이선스를 구매, 수정/보완하여 MS-DOS로 명명 IBM에 공급하게 됩니다. 물론 나중에 QDOS의 소유권을 아예 사 버리죠. MS-DOS이 대부분은 어셈블리어로 개발되었습니다.

절대경로란 최상위 지점(Root)로 부터 시작하여 현재의 위치에 이르는 모든 경로를 모두 표현하는 것을 말합니다. 흔히들 전체경로(full-path)라고도 부릅니다.

Windows 에서는 C:\Users\elsa\Documents\test.doc 이런 식이고 Linux 라면 /home/elsa/Documents/test.doc 이런 식입니다.

상대경로란 현재 디렉터리(폴더) 혹은 특정 기준점을 기준으로 표현한 경로를 말합니다.

예를들어 절대경로가 /home/elsa/documents/pdf 이고, elsa 가 현재 디렉터리라면,

documents 이 표현 자체가 현재 디렉터리를 기준으로한 하위 디렉터리를 의미하는 상대경로입니다. document/pdf 이것도 상대경로입니다. document/pdf/example.pdf 이것도 상대경로 표현입니다. 공통점은 현재 디렉터리가 기준이라는 점입니다.

현재 또는 상위 디렉터리를 의미하는 특별한 형태가 있는데, . 은 현재 디렉터리를 .. 는 상위 디렉터리를 의미합니다.

따라서, documents 는 ./documents 와 같고, ../link 는 절대경로 /home/link 와 같은 의미가 됩니다.

Linux에서 흔히 사용하는 디렉터리 관련 표현 중에 ~(tilde:틸드) 가 있는데요.. 이건 상대경로가 아닌 별칭(Alias) 혹은 단축(Abbreviation) 라고 합니다. 의미론적으로는 분명 "현재 사용자의 home 디렉터리"라는 상대경로를 의미하지만, ~ 은 Unix-like 운영체제의 표준요소가 아닌 Bash나 zsh 와 같은 shell 이 제공하는 편의 기능이기 때문입니다. 내부적으로 ~ 은 shell 에서 절대경로로 치환하게 됩니다.

따라서, shell과 직접적인 관련이 없는 순수 Linux 관련 기능에서는 ~를 이용한 경로표현을 허용하지 않는 경우도 있습니다.

파일 확장자

확장자는 파일이 어떤 종류의 파일인지를 식별하는 것으로 extension 이라고 부릅니다. windows에서는 이 확장자가 매우 절대적인 의미를 갖습니다. 확장자에 따라 Icon 도 바뀌고, 연결되어 열 수 있는 프로그램도 결정이 되기 때문입니다.

반면, Linux에서는 확장자라는 개념은 없습니다. 사용자가 파일의 종류를 직관적으로 식별하기 위해 또는 통념적인 파일네임 표현식에 따라 .zip .jpg 이렇게 붙이는 것이지, 이것이 windows의 그것처럼 동작하거나 인식되지 않습니다.

그럼 Linux에서는 파일의 종류를 어떻게 식별할까?
Linux에서는 파일들이 포함하고 있는 medata, Magic Number나 Shebang(쉬뱅), MIME-Type 등으로 식별을 합니다.

우선 실행 파일이나 데이터 파일이냐 하는 것은 파일의 metada에 해당 파일이 실행권한이 설정되어 있는지의 여부로 판단합니다. 실제 실행파일인지 데이터파일인지의 여부와 무관하게 실행권한이 있다면 실행할 수 있는 파일이고, 없다면 실행할 수 없습니다.

파일이 스크립트(script) 파일이고, Shebang이 명시되어 있다면, 해당 파일이 shell script 인지, python 코드인지를 식별할 수 있게 됩니다.

일반적인 데이터 파일들, 그러니까.. 음악 파일, 이미지 파일, 동영상 파일 등은 파일의 내용을 보고 파일 type을 구분합니다. Linux에서는 Magic Number라는 것이 있는데, 이는 특정 파일 형식이 시작 부분 혹은 특정 위치에 고정적으로 나타나는 고유한 바이트 시퀀스 혹은 특정값을 의미합니다. Linux는 이 magic number 데이터베이스를 갖고 있기 때문에, 해당 파일의 내용을 보고 해당파일이 어떤 파일인지를 식별합니다. 이 데이터베이스는 /usr/share/misc 디렉터리에 존재합니다.

아래 스샷을 보면, test1 이라는 디렉터리에 flac(오디오), mkv(동영상), jpg(이미지), test2(디렉터리) 이렇게 4개의 파일이 있는 것을 알 수 있습니다.

file 이라는 명령은 해당 파일의 Magic Number를 식별하여 어떤 파일인지를 알려주는 명령입니다.

JPEG 아미지 파일은 16진수 값으로 FF D8 FF E0 으로 시작하고, PDF 파일의 경우 ASCII 문자열로 %PDF로 시작합니다. 그리고 Zip 압축 파일의 경우 ASCII로 PK 로 시작을 합니다.

결론적으로 Linux에서는 사용자가 임의로 붙이는 .확장자 형식은 아무런 의미가 없습니다. 그저 이름의 일부일 뿐입니다. 사용자가 그냥 식별하기 위해서 이름을 그렇게 만든 것 이상의 의미는 없습니다.

리눅스에서는 또 MIME(Multipurpose Internet Mail Extenstions) Type이라는 것을 사용합니다. 이것은 원래 인터넷 환경에서 파일의 종류를 식별할 목적으로 사용되는데 xdg-open 과 같은 도구가 파일을 열 때 MIME 기준으로 해당 파일을 열 프로그램을 선택하게 됩니다. MIME type 은 다양한 운영체제에서 사용하는 것이기 때문에 파일명의 .txt 와 같은 표현을 조금은 고려합니다. 하지만 이는 Magic Number 분석으로 식별이 되지 않을 경우에 보조적으로 분석하는 것이지 본질적인 분석 요소가 아니며, 여전히 이름의 일부일 뿐이지 확장자는 아닙니다.

또, 일부 응용프로그램 단계에서 .확장자 처럼 파일이름 형식을 요구하는 경우가 있습니다.

가장 대표적인 것이 프로그래밍 언어 컴파일러 들로 예를 들어 C 언어 컴파일러의 경우 .c 를 c코드로 .h 파일을 헤더파일로 처리합니다. 프로그래밍 언어들 마다 제각기 자신들이 정한 네이밍 규칙이 있지요. 웹서버의 경우에도 .html 파일을 HTML 문서로 인식하고 .php 파일을 PHP 스크립트로 인식하여 처리합니다. 다만 이 경우에도 이들을 확장자로 인식한다기보단 파일명의 접미사(suffux)로 인식하는 것일 뿐입니다.

Linux에서는 실행파일이든 문서파일이던 이름과 type 간에 논리적인 연결성이 없습니다. 아무리 jpg 이미지 파일을 test.pdf 라고 하거나 test.mp3라고 바꿔도 Linux에서는 그저 jpg 이미지 파일로 식별합니다. 디렉터리 이름에 .mp3를 넣어도 디렉터리는 디렉터리일 뿐입니다.

반면, Windows에서는 확장자가 갖는 의미가 절대적입니다. jpg 파일의 확장자를 .zip으로 바꾸면 이를 압축파일로 인식합니다. 대신, 장점이라면 매우 직관적이라는 점을 들 수 있습니다. 실제로 파일의 내용을 들여다보지 않고도 해당파일이 어떤 파일인지를 식별할 수 있고 적절한 프로그램으로 열 수 있도록 연결할 수 있습니다.

macOS의 경우에는 Unix-like 운영체제로 근본적으로는 Linux와 동일하게 파일명을 식별하지만, 사용자 편의성, 다른 운영체제와의 차별화를 위해 WIndows와 같은 확장자 개념을 사용하고 있습니다. 그 증거는 Finder에서 확장자를 숨기거나 볼 수 있는 옵션이 있다는 점을 들 수 있습니다.

링크(Link)

자 이제 마지막 주제입니다. Link란 둘을 연결한다는 의미인데요, 파일시스템과 관련이 있으므로 파일과 파일을 연결한다는 의미가 될 겁니다. Linux에는 Soft Link와 Hard Link 이렇게 두 가지가 있습니다. Soft Link는 Symbolic Link 라고도 부릅니다.

Soft Link는 파일이나 디렉터리를 가르키는 포인터(Pointer) 또는 바로가기(Shortcut)을 의미하는데, 이는 Windows나 macOS에서도 있는 개념입니다. 실제 데이터를 갖고 있는 것이 아니라, 단순희 원본파일(혹은 디렉터리)의 위치를 가리키는 파일을 뜻합니다.

Linux의 파일들은 모두 inode라는 정보를 갖고 있는데, 이는 실제 저장장치에 저장된 데이터의 위치 정보 입니다. Soft Link는 독립적인 파일로 고유한 inode를 갖고 있어 별개의 파일로 인식됩니다.

Hard Link는 Soft Link처럼 자신이 데이터를 갖고 있는 것이 아니라 원본 파일을 가르키고 있다는 점에서는 동일하지만, 자신의 inode를 갖고 있는 것이 아니라 원본 파일의 inode를 똑같이 갖게 됩니다. 따라서, 운영체제 입장에서는 Hard Link 파일과 원본 파일은 사실상 동일한 파일로 간주합니다. Hard Link로 접근을 하던, 원본 파일로 접근을 하던 사용되는 실제 데이터는 동일한 것입니다.

Hard Link가 Soft Link와 다른 또 다른 특징은, 일반 파일은 Hard Link를 만들 수 있지만 디렉터리는 Hard Link로 만들 수 없다는 점입니다. /home/elsa 라는 디렉터리를 /home/elsa/test 라는 Hard Link로 만들게 되면, 디렉터리의 기본 개념이 무너지기 때문입니다. (이것을 "순환 참조 문제"라고 합니다.)

세 번째 차이점은 Hard Link는 동일한 저-수준 파일 시스템 혹은 동일한 파티션 내에서만 만들 수 있는데, Hard Link는 원본 파일의 inode를 공유하기 때문입니다. 이게 무슨 말이냐면, 서로 다른 저장장치 혹은 서로 다른 파티션은 물리적으로 별개의 장치로 인식하기 때문에 "다른 공간 동일 위치"가 존재하게 됩니다. 따라서 한 저장장치의 inode를 다른 장치에서 Hard Link로 지정할 수 있게 허용하게 되면, Hard Link 의 inode가 동일한 파티션 혹은 동일한 저장장치 내의 저장 위치인지 다른 저장장치 혹은 파티션의 저장위치인지를 판단할 수 없게 됩니다. 따라서 Hard Link는 동일한 파티션 내에서만 생성할 수 있도록 제한한 것입니다.

네 번째 차이점은 Soft Link는 원본 파일이 삭제되면 Soft Link가 더 이상 유효한 원본을 가르킬 수 없는 상태 즉, Danggling Link(끊어진 링크)가 되는 반면, Hard Link는 원본 파일이 삭제되더라도 원본 파일을 계속 가리킬 수 있습니다. 즉, 원본파일이 삭제되더라도 Hard Link에 inode가 남아 있기 때문에 실제로는 원본 데이터가 삭제된 것은 아닌 셈이 됩니다.

Soft Link의 가장 흔한 용도는 Shortcut(바로가기) 입니다. 원본 파일이 매우 복잡한 디렉터리에 포함되어 있을 때, 해당 원본 파일을 Symbolic Link로 만들면 매우 직관적으로 쉽게 원하는 곳에서 접근할 수 있습니다.

Hard Link는 잘 사용되지는 않자만 특정 디렉터리 내의 원본파일이 매우 중요해서 실수로 디렉터리가 삭제될 경우라도 파일이 삭제되지 않게 할 목적으로 사용됩니다. copy와 같이 물리적으로 원본데이터를 다른 곳에 똑같은 내용으로 저장하는 것이 아니기 때문에, 물리적은 저장공간을 부가적으로 소모하지 않으면서도 원본파일을 보호할 수 있게 됩니다. 물론, 부가적으로 Soft Link와 같은 shortcut 효과를 같이 얻을 수 있습니다.

Hard Link 사용 시의 단점이라면, 저장다용량 대비 사용된 용량을 계산할 때 혼란이 야기될 수 있다는 점입니다. 원본과 Hard Link 사이에는 "원본"과 "사본" 같은 개념이 없습니다. 둘 다 원본인 셈입니다. 정확한 저장공간 사용용량을 계산하기 위해서는 원본과 사본 중 어느 한쪽만 계산에 넣어야 합니다. 둘 다 동일한 크기를 표시하기 때문입니다. 그러니까 둘 다 계산에 포함하면 실제보다 더 많은 용량을 사용한 것처럼 잘못 계산될 것이고, 둘 다 계산에 넣지 않으면 실제보다 더 작은 용량을 사용한 것처럼 잘못 계산될 것입니다. 문제는 원본과 사본 개념이 없기 때문에 이를 적절히 식별할 방법이 없다는 것입니다.

Link는 ln 명령으로 생성할 수 있으며, Link 또한 파일이므로 다른 파일과 동일하게 rm 혹은 rmdir로 제거할 수 있습니다. ln -s 옵션을 사용하면 Soft Link를 생성하는 것이고, 그냥 ln 으로 Link를 만들면 Hard Link를 만드는 것입니다.

위의 스샷은 temp333 이라는 디렉터리에 포함된 3개의 파일을 ls -l 명령으로 확인한 것입니다.

원본파일은 test.txt 이고, symbolic-link 라는 파일은 test.txt의 Soft Link임을 알 수 있습니다. hard-link 파일은 text.txt의 Hard Link 인데, Soft Link 처럼 원본 파일이 무엇인지를 알려주지 않습니다. test.txt가 제거되더라고 물리적인 저장장치에서 데이터가 제거되는 것이 아니기 때문에 원본 파일이 뭔지 Hard Link 파일이 뭔지 알 필요가 없습니다. 다만, 왼쪽에 권한정보 -rw-r--r--. 2 elsa elsa .. 이렇게 된 것을 보면, symbolic-link 파일은 1 이자만, test.txt와 hard-link 파일은 2로 되어 있는 것을 확인할 수 있습니다. inode가 2개라는 의미로 원본파일에 대해 1개의 Hard Link 파일이 추가적으로 존재한다는 것을 알 수 있습니다. 또 한 가지 확인할 수 있는 것은 hard-link 파일도 3.1KB 크기이고, test.txt도 물론 3.1KB로 표시된다는 것입니다. 앞서 언급한 것처럼 사용자가 확인할 수 있는 디렉터리 크기나 파일의 사용용량은 정확하지 않을 수 있습니다.

- - - - -

글을 쓰다보니, 예상대로 꽤 길어 졌습니다.

우리가 Windows나 macOS를 처음 접했을 때, 해당 운영체제를 어떻게 사용할 수 있었는지를 돌이켜 보면, 대부분은 그냥 이것저것 사용하면서 경험적으로 사용법을 익히게 되지요, 하지만, 좀 더 효과적이고 깊이있게 사용하기위해서는 어느 순간에는 결국 기술적이고 학문적인 영역으로 들어가야 합니다.

Linux는 Windows나 macOS 만큼 불특정 사용자층을 배려한 OS가 아니기 때문에, WIndows나 macOS를 사용하던 분들이 Linux를 사용하고자 할 때, 꽤나 진입장벽이 높다고 느끼게 되고, 그래서 Linux는 사용하기 어렵다는 인식이 많은 것 같습니다.

열정을 갖고 Linux를 사용하고자 도전하는 분들에게 조금이나마 도움이 될 수 있었으면 합니다. ^^

[Linux 초보 탈출] 쉘(shell)에서 명령어의 입출력을 제어하는 pipe 그리고 redirection

elsa in mac — Tue, 22 Jul 2025 23:51:05 +0900

이번 포스트에서는 쉘(shell)에서 명령어(command)의 입출력(input/output)을 제어하는 pipe와 redirection이라는 개념에 대해 알아보도록 하겠습니다.

리눅스를 사용하다 보면, 자연스럽게 Terminal을 자주 그리고 오래 사용하게 됩니다. 이유는 대다수의 많은 도구들이 GUI 보다는 Text 기반의 CLI/TUI 들이기 때문이고. Linux를 사용하는 컴퓨터의 환경을 관리하거나 꾸미거나 하는 등등의 작업들이 대부분 terminal에서 이뤄집니다. 그래서 Linux를 잘, 그리고 능숙하게 사용하려면 Terminal을 잘 사용해야 하는데, "Terminal을 잘 사용한다"는 의미는 Terminal 프로그램을 잘 쓸 줄 안다는 의미보다는 Terminal에서 하고자 하는 작업을 능숙하고 빠르게 할 줄 알아야 한다는 의미입니다.

그러다 보니, Terminal 환경에 대한 것들을 이해할 필요가 있습니다. 앞으로 몇 차례 포스팅을 통해 Linux에 입문하고자 하는 분들을 위해 이러한 기초적인 것들을 다루게 될 것입니다.

shell

Linux를 설치하고 Termial 앱을 실행 시키면, 프롬프트가 표시되고 커서만 달랑 나오게 됩니다.

터미널을 실행 !

여기서부터 이제 뭔가를 해야 하는데.. 이것은 엄밀히 말하면 shell이라는 프로그램이 실행되어 있는 것입니다. 말하자면 Prompt와 커서가 Shell의 Inteface인 셈입니다.

우리가 컴퓨터를 사용한다는 것은 바꿔말하면 컴퓨터와 대화를 한다는 것이고, 대화를 한다는 것은 컴퓨터에게 명령하고 컴퓨터가 처리한 명령의 결과를 확인하는 과정이라고 볼 수 있습니다. 그런데 인간이 이해하는 언어와 컴퓨터가 이해할 수 있는 언어는 다르기 때문에, 이 둘 간의 중재자가 필요합니다. 사람이 이해할 수 있는 언어와 표현으로 컴퓨터에 요청하면 컴퓨터는 자신의 언어와 표현으로 대답을 하는데, 이것은 다시 인간이 이해할 수 있는 언어로 바뀌어야 합니다. 이러한 대화의 중재자 역할을 담당하는 것이 바로 shell입니다.

Shell의 사전적 의미는 누구나 알다시피 "조개껍질" 이라는 뜻입니다. 컴퓨터와 인간 사이에 대화의 중재자 역할을 담당하는 녀석의 이름을 왜 shell이라고 했을까?

운영채제의 핵심을 우리는 kernel이라고 부릅니다. Kernel의 사전적 의미가 "핵심" 또는 "씨앗" 이라는 의미이지요. 엄밀히 말해 우리가 부르는 Linux도 바로 이 kernel을 의미합니다. Kernel은 컴퓨터 하드웨어와 직접 소통하며, 메모리 관리, 프로세스에 대한 스켸쥴링, 입출력 처리등을 담당하는 운영체제(OS)의 가장 기본적이고 근본적인 역할을 수행하는 core 입니다. 누가 이 용어를 처음 사용했는지는 확실하지 않습니다. 조개의 핵심.. 즉, 조개의 가장 깊숙한 곳에 진주가 있고, 이것을 덮고 있는 것이 조개 껍질이라고 본다면, 진주는 kernel 이고 kernel을 덮고 있는 것이 바로 shell 이라고 볼 수 있습니다. shell 이라는 개념은 프랑스 국적의 컴퓨터 과학자인 루이 푸쟁이 1960년대 중반 Multics(멀틱스) 라는 운영체제를 개발하면서 shell이라는 용어를 처음으로 사용했습니다. 이후, Unix 운영체제에서 쉘에 대한 개념과 역활 그리고 기능이 더욱 발전하게 됩니다. Unix의 최초 shell은 1970년 초, Ken Thompson 이 만든 Thompson shell(sh) 이였고, 이 후 Stephen Bourne이 70년대 말 Bourne Shell(sh)을 통해 Script 기능을 대폭 강화 합니다. 이 후 다양한 shell들이 등장했고, 1989년에 Brian Fox가 GNU project를 위해 Bourne shell을 기반으로 Bash(Bourne Again SHell)을 개발하기에 이릅니다.

pipe

서두에 쉘에서 명령어의 입출력을 제어하는 기능에 pipe 가 있다고 언급을 했었지요.

Unix 운영체제가 개발되던 초창기, 개발자들은 Unix가 갖춰야 할 기능을 구현함에 있어 철학적인 개념 정립에도 매우 진지했습니다. Unix의 이러한 철학과 깊이 있는 개념 정립은 이후, 많은 OS에 영향을 주었고 오늘날 우리가 사용하고 있는 컴퓨터 운영체제의 기반이 되었습니다.

당시에는 대부분의 데이터들은 Text 기반의 문자열이었고, 만들어야 할 기능들이 꽤나 많았습니다. 당시 CPU의 성능도 Memory의 용량도 매우 작았기 때문에 지금처럼 하나의 프로그램에 다양하고 복잡한 기능을 다 담을 수가 없었습니다. 개발자들의 의욕과 열정이 과도하면 너무 많은 것들을 담으려 하는 경향이 있지요,

Unix 개발에 참여했던 벨 연구소(Bell Labs)의 Douglas Mcllroy(더글라스 메클로이)는 프로그램들이 오직 한 가지 특화된 기능에 집중하기를 원했습니다. 대신, 이러한 특화된 기능에 집중된 프로그램들을 상호 연결해서 궁극의 복잡한 문제를 해결하는 것이 모든 면에서 좋다고 판단을 했습니다. 대신 이렇게 상호 협업을 하기 위해서 프로그램들은 입력과 출력 모두에서 Text stream을 처리할 수 있는 기능을 필수적으로 갖추고 있어야 한다고 생각했습니다. 당시만 해도 한 프로그램이 출력은 임시 파일로 저장되고, 다른 프로그램이 그 저장된 임시 파일을 읽어와서 처리하는 식이였습니다. 당시의 저장장치는 지금처럼 빠르지도 않았기에 데이터를 처리하는 시간보다 파일에 저장하고 다시 읽어오는 시간이 더 길었습니다.

메클로이는 이러한 철학을 달성하기 위해 한 프로그램의 결과(출력)가 다른 프로그램의 입력으로 직접 연결될 수 있는 메커니즘을 구상하게 되는데, 이것이 바로 Pipe라는 개념입니다. pipe는 중간 단계인 결과를 저장하고 또다시 이 결과를 읽어 들이는 과정을 생략하고 메모리 상에서 직접 데이터를 보내고 받는 방법으로 기존의 방식보다 매우 효율적이고 효과적인 결과를 만들 수 있게 되었습니다.

쉘에서 pipe는 | 키를 사용합니다.

shift + \ = pipe

pipe를 사용하는 예를 하나 보겠습니다.

스샷을 보면, ls 명령으로 현재 디렉터리의 파일과 하위 디렉터리 목록을 볼 수 있는데요. 다음 prompt에서 아래와 같은 명령을 내린 것을 알 수 있습니다.

ls | grep ".txt" | sort

ls 명령을 수행하게 되면 현재 디렉터리의 파일몰록을 출력하게 되는데, 이 출력을 표준 출력장치인 terminal로 보내는 것이 아니고, pipe를 이용하여 grep 명령의 입력으로 보내게 됩니다. grep은 입력 문자열에 대해 사용자가 정의한 패턴에 해당하는 정보만 필터링하여 결과를 출력해 주는 명령어입니다. 그런데 그 출력을 역시 표준 출력장치인 termial로 보내지 않고, 다시 pipe를 통해 sort 명령의 입력으로 보냅니다. sort는 입력받은 문자열을 올림차순으로 출력합니다. sort 다음에는 pipe 가 없으므로 표준 출력인 terminal로 출력하게 됩니다.

또 다른 예를 하나 보겠습니다.

grim 은 화면을 screen capture 하는 도구입니다. -g 옵션을 주고 " " 안에 capture 할 영열에 대한 geometry 정보, 예를 들어 "100, 200, 800x600"로 명령을 내리면, x=100, y=100 위치에서 width(폭) 800, height(높이) 600 픽셀 영역을 캡처합니다. 그리고 - 는 캡처한 이미지를 파일로 저장하지 말고, 표준 출력으로 보내라는 의미입니다. swappy는 이미지 편집 GUI 프로그램으로 -f 는 이미지의 파일 경로를 지정하는 옵션이고 - 이므로 표준 입력으로부터 이미지 데이터를 읽어와 표시하라는 의미가 됩니다.

즉, 위의 명령을 실행하게 되면, slurp에 의해 화면에 + 모양의 마우스 커서가 나타나고 사용자는 capture 하고자 하는 영역을 드래그 앤 드롭하게 됩니다. slurp의 결과는 사용자가 선택한 영역에 대한 geometry 값이 출력되는데, 이 출력을 이용하여 grim 이 실체 해당 영역을 스크린 캡처하게 됩니다. 그 결과는 이미지 데이터이지만 파일로 저장하지 않고 표준 출력으로 보냅니다. pipe로 swappy로 보내라고 되어 있으니 swappy는 표준입력 즉, pipe를 통해 전달된 이미지 데이터를 받아 해당 이미지를 표시하게 됩니다.

말하자면, 저 한 줄이 screen capture 프로그램인 셈입니다.

grim -g "$(slurp)" - ❘ swappy -f - 의 결과

다른 예를 하나 더 보겠습니다.

ps 명령은 실행 중인 process의 목록을 출력해 주는 것인데, ps에 aux 옵션을 주면 현재 컴퓨터에서 실행 중인 모든 프로세스의 목록을 출력합니다. 이 결과는 pipe로 grep "omega"로 입력되고, grep은 이 목록 중에 omega가 포함된 line 만 필터링하게 됩니다. 그리고 그 필터링된 결과는 다시 pipe로 grep -v "grep"으로 보내지게 되는데, 이 명령은 해당 문자열 목록 중에서 "grep"이 포함된 라인을 제외시킵니다. 그리고 그 결과는 또다시 awk로 보내지게 되는데 awk는 한 문자열에서 공백으로 구분된 2번째 필드만 추출합니다. ps aux의 결과에서 두 번째 필드는 해당 프로세스의 ID 정보(PID)이므로 PID 정보로만 구성된 문자열 목록이 pipe로 다시 xargs kill로 보내지게 됩니다. 그리고 결국 해당 PID에 해당하는 프로세스들은 kill 명령에 의해 종료되게 됩니다.

정리하자면, 위의 명령어 셋은 "현재 실행 중인 프로세스 중에 omega가 포함된 프로세스들만 모두 종료시켜라"라는 의미가 됩니다.

마지막으로 pipe를 이용하는 예를 하나 더 보겠습니다.

du 명령은 현재 디렉터리에 포함된 파일들과 디렉터리의 크기를 표시해 주는 명령입니다. 그 출력 결과는 pipe로 sort로 전달되는데, sort는 입력받은 목록을 -r(reverse) 즉, 내림차순으로 정렬하고 그 결과를 pipe에 의해 head 명령으로 보냅니다. head는 입력된 문자열 목록 중 -n 10 즉, 처음부터 10개만 표시하게 합니다.

따라서, 위의 명령어 셋은 "현재 디렉토리의 파일을 크기를 기준으로 내림차순으로 정리하고 가장 크기가 큰 파일부터 10개의 정보만 표시해 줘"라는 것이 됩니다. 결과는 아래와 같습니다.

redirection

redirection의 사전적 의미는 방향전환입니다. 의미 그대로 redirection이라는 개념은 프로그램에 입력, 출력, 에러의 방향을 변경하는 것으로 일반적으로 입력과 출력은 모두 표준입력(stdin), 표준출력(stdout), 표준에러(stderr)로 표준입력은 키보드, 표준출력과 표준에러는 terminal 입니다.

표준입력과 표준출력은 이해를 하겠는데, 표준에러는 뭘까?
Unix와 Unix-like(Linux) 시스템에서 모든 프로그램은 실행될 때 3개의 데이터 스트림을 갖게 됩니다. 표준입력, 표준출력, 그리고 표준에러. 표준입력은 데이터를 읽어 들이는 통로로 기본은 키보드입니다. 표준출력은 프로그램의 정상적인 결과를 내보내는 통로로 Terminal이며, 파일 디스크립터(File Descriptor) 번호는 1입니다. 표준에러는 프로그램의 에러 메시지나 진단정보를 내보내는 통로로 표준출력과 동일한 Terminal이기는 하지만 파일 디스크립터 번호가 2입니다. 파일 descriptor란 입출력 자원(Input/Output resource)을 추적하고 관리하기 위한 식별표입니다.

경우에 따라서 이 표준입력과 출력을 바꿈으로써, 작업의 효율성을 높일 수 있게 되는데, redirection은 앞에서 잠시 언급했던 Unix 최초의 shell을 개발한 Bell 연구서의 Ken Thompson에 의해 제안되었습니다.

pipe가 프로그램들 간의 입력과 출력을 연결하는 것이라면, redirection은 단일 프로그램이 입력 혹은 출력의 방향을 변경하는 것으로 > (출력 redirection)와 < (입력 redirection)를 사용합니다.

ls는 현재 디렉터리(폴더) 의 파일과 서브 디렉토리 목록을 출력하는 명령인데, > files_list.txt라고 했으니, terminal로 출력하지 않고, files_list.txt라는 파일을 생성하고 해당 파일에 출력합니다.

만일, 실시간으로 log 데이터를 출력하는 프로그램이 있다고 해 봅시다. 출력이 끊임 없이 출력되기 때문에 이 결과를 실시간으로 저장하지 않는다면 나중에 데이터를 분석할 수 없을 것입니다. 이렬 경우 redirection 기능이 없다면 정말 끔찍하겠죠.

sort를 실행하면, 키보드로부터 데이터 입력을 대기 합니다. 사용자는 데이터를 키인하고 Ctrl+d 를 누르면 지금까지 입력한 데이터를 올림차순으로 정렬하여 결과를 출력합니다. 위의 스샷을 보면 < saved_data.txt 라고 되어 있으니, 입력을 키보드로 부터 받지 않고, saved_data.txt로부터 받게 됩니다.

위의 스샷을 보면, > 가 아니고 >> 을 사용하는 것을 알 수 있는데, >> 를 "표준 출력 추가 리디렉션"이라고 합니다. 즉, 좌측이 출력을 우측의 출력 끝에 추가하는 것으로, 위의 예는 test2.txt의 내용을 test1.txt의 맨 마지막 줄에 추가하라는 명령이 됩니다.

pingping이라는 명령은 없기 때문에 표준에러로 에러메시지를 출력하게 되는데, 앞서 언급했듯이 에러 메시지는 동일하게 terminal로 출력을 하지만 file descriptor가 2번 입니다. 즉, 2> 라는 의미는 표준에러 스트림만 error.log로 redirection 하게 됩니다.

예를 들어, 어떤 프로그램이 실행되면 정상 log와 오류 발생 시 오류 메시지가 terminal에 출력되게 될 터인데, 이 경우 모두 terminal에 출력을 하게 되므로 정상 메시지와 에러 메시지가 섞여 있게 되고, 나중에 log를 분석할 때 어디서 어떤 오류가 발생했는지를 찾는 게 힘들 수 있습니다. 이 경우 위와 같이 2> 를 사용하면 실행 중 발생하는 에러 메시지(file descriptor 2번)만 파일로 저장되기 때문에 분석이 훨씬 효율적일 수 있습니다. 만일 정상메시지와 오류메시지를 구분하여 모두 redirection 하고 싶다면 아래와 같이 하면 됩니다.

반면, 정상 메시지와 에러 메시지를 모두 하나의 파일로 redirection 하고 싶다면.. 아래와 같이 합니다.

ping > message.log로 명령을 내리게 되면, 에러 메시지는 빠진 정상 출력만 redirection 하게 됩니다.

예를 들어, 어떤 프로그램을 실행하면 엄청나게 많은 메시지들이 실시간으로 출력된다고 가정해 봅시다. 사실은 출력되는 메시지는 관심이 없는데 말이죠? 대부분의 프로그램들은 출력 메시지를 막는 옵션을 갖고 있는 경우가 많습니다. 하지만, 어떤 프로그램은 그런 옵션이 없다면?

이럴 경우에는 redirection 기능을 이용하여 표준출력과 표준에러를 terminal이 아닌 다른 곳으로 보내면 되겠죠? 그래서 Linux에서는 null 장치 혹은 blackhole 이라는 것을 갖추고 있습니다.

위의 스샷은 &> /dev/null 이므로, 표준출력과 표준에러 출력을 모두 null 장치로 보내게 됩니다. 따라서, 어떠한 메시지도 terminal에 출력되지 않게 됩니다. 정상 메시지만 보내고 싶다면 > /dev/null, 에러 메시지만 보내고 싶다면 ? 네 그렇쵸 2> /dev/null 해 주면 됩니다.

- - - - -

이번 포스트에서는 shell에서 사용하는 입출력제어의 대표적인 개념인 pipe와 redirection에 대해 살펴봤습니다. Linux를 사용하면서 여러 가지 문제에 봉착하고 그에 대한 해결책을 찾기 위해 AI의 도움을 받거나 혹은 Community에서 해답을 찾기 마련인데, pipe나 redirection과 관련된 표현이 나오더러도 이젠 이게 뭐지? 하지 않으실 수 있을 겁니다. ^^

Linux의 시대가 오고 있는가 ?

elsa in mac — Sun, 20 Jul 2025 23:57:50 +0900

2025년 7월..

어느덧 2025년도 중반을 돌아 하반기로 가고 있습니다.

오늘 오랜만에 Global 통계사이트인 statcounter에 가 보니, 놀라운 수치가 눈에 들어옵니다.

미국에서 Linux가 5%를 념겼습니다. 전체적으로는 4.1%로 크게 변화된 것은 없지만, IT의 중심인 미국에서 Linux의 market share가 올라가고 있다는 것은 고무적인 현상입니다.

제목이 좀 그렇기는 한데, 사실 Linux는 IT 시장에서 대단히 큰 위치를 차지하고 있습니다. 서버, 슈퍼 컴퓨터, 그리고 모바일(Android) 시장까지 말이죠. 단지 유독 Desktop Market 에서만은 Windows가 1탑의 위치를 차지하고 있는 것이 오늘날의 현실입니다 따라서, 포스팅 제목은 엄밀히 말하자면 " Linux Desktop 의 시대가 오고 있는가 ?" 라는 질문이 됩니다.

음.., 우리가 지켜봐야 할 것은 이미 지난 데이터가 아닙니다. 앞으로 일어날 변화이지요..
대부분 알고 계시리라 생각이 됩니다만, 2025년 10월 14일, Windows 10 이 공식적으로 발표된 2015년 7월 말로부터 10년 만에 포괄적인 지원을 중단합니다.

지원이 중단된다는 것은 더 이상의 기능/성능 업데이트가 없고, 기술 지원이 중단되며, 무엇보다 중요한 보안패치가 제공되지 않는 다는 것을 의미합니다. 일반 사용자들이야 별 문제가 되지 않을 수 있지만, 정부 행정망, 교육기관 및 단체, 공공 시스템 측면에서는 이게 만만한 일이 아닙니다. windows 10을 계속 사용은 할 수 있지만 보안 패치가 제공되지 않는다면, 실질적으로는 사용하기 어렵다고 봐야 합니다. 보험업계에서도 해킹이나 악성코드로 인한 피해를 보상하는 상품의 비용을 계산할 때, 기업이 WIndows 10을 계속 사용하고 있다는 것이 보험료를 높이는 이유가 될 수 있습니다. 물론 MS에서는 windows 11 무료 업데이트를 진행한다고 발표했지만, 말이 무료이지 windows 11의 요구조건에 충족되지 않는 수많은 컴퓨터들은 거저 준다고 해도 사용할 수 없습니다. 무조건 H/W 교체가 필요하다는 말입니다.

그럼 선택지가 없는 것인가 ?
아닙니다. 유료 확장 보안 업데이트(ESU:Extended Security Updates)를 구매하면 되는데, 1년 단위로 가격은 대략 30달러로 되어 있습니다. 이 마저도 언제 중단될지는 미지수입니다. 큰돈을 들여 H/W를 업그레이드 혹은 교체를 하고 Windows 11로 갈아타느냐, 아니면 년 단위 유료 보안 업데이트 옵션을 구매하며 계속 사용하느냐.. 선택의 시간이 다가오고 있습니다.

미국에 새 정부가 들어서면서 이른바 관세전쟁으로 전 셰계 국가들이 미국과의 마찰이 발생하면서, 지금까지는 영원한 우방이라고 생각했던 미국에 대한 시선이 점차 변해가고 있습니다. 이 예 유럽을 비롯한 각국 정부들은 이른바 "디지털 주권(Digital Sovereignty)"이라는 캐치프레이즈 하에 미국의 IT 솔루션 사용을 줄이려는 움직임을 보이고 있습니다. 그 이면에는 Windows와 Office의 대체제를 찾는 것으로 까지 확대되어가고 있지요.

전 세계 컴퓨터의 거의 대부분을 장악하고 있는 WIndows를 대신하기 위한 선택지는 많지 않습니다. macOS는 아예 H/W를 싸그리 교체해야 하기 때문에 비용이 만만치 않습니다. 그래서 가장 효율적인 대체제로 Linux가 부상하고 있습니다.

모바일 게임기 시장의 대표격인 steam 도 Windows 라이센스 비용 부담과 성능 향상을 위해 WIndows를 탈피해 Linux로 전환하려는 노력을 하고 있다는 것은 이미 공공연히 알려진 사실 입니다.

Linux는 어느 특정 기업이나 국가에 소속되어 통제되지 않기 때문에, 각 국가별로 전담부처를 만들어 차분이 준비한다면 정부 부처 시스템을 교체하는 것이 가능할지도 모릅니다. 물론, 각국 정부의 행정 시스템을 일시에 전면 교체한다는 것은 위험 부담이 너무 크기 때문에 현실적으로는 불가능 하지만, 중요한 것은 인식의 변화가 일어나고 있다는 점입니다. 가장 단순한 하위 정부 시스템부터 단계적으로 바꿔나가려는 노력이 조금씩 늘어나고 있습니다.

분명, Windows 10 의 지원중단 이벤트는 각국 정부와 산업계 그리고 소비자들 까지 전 세계적으로 꽤나 많은 영향을 미치게 될 것입니다.

일반 개인 사용자들의 관점에서는 좀 다를 수 있습니다. 일반 사용자들은 자신들이 사용하던 WIndows 컴퓨터에서 더 이상 업데이트가 없다는 메시지를 접하게 되면, Linux로 전환하는 것이 아니라 "이젠 컴퓨터를 바꿀 때가 되었구나" 라고 생각할 확률이 거의 99.5% 쯤 될 것 입니다. 아니면, 아예 동작을 하지 않는 것은 아니니 업데이트가 되던 말던 그냥 계속 그대로 사용할 것 입니다.

- - - - -

Windows 10의 지원중단이 Linux에게 전례 없는 기회가 될 수 있을까요?
AI의 발전이 상업적 OS에 깊숙히 접합되면서, 이러한 기류를 거부하는 유저들의 마지막 도피처로 Linux가 떠오를까요?

여전히 대 다수의 컴퓨터 사용자들은 전문적인 지식을 부담스러워 합니다. 컴퓨터는 그냥 전화기 같은 일상의 도구이지 이제 더 이상 그 이상의 특별한 기기가 아닙니다. Linux는 무료이고 관리를 하거나 사용자들의 물음에 대응하는 서비스도 없습니다. 무료라는 것은 그 만큼 품질이나 서비스가 떨어질 것이라고 생각합니다. WIndows 나 macOS 는 Update를 강요하는 측면이 있는데, 사용자들은 이를 불편함으로 받아들이는 측면도 있지만, 반대로 관리받고 있다는 안도감을 갖게되는 측면도 있습니다. 그런 측면에서 Linux는 그런 안도감을 기대할 수 없습니다. 개인 사용자들이 Linux로의 전환을 꺼리는 큰 이유 이지요.

관심과 사용자층이 늘어나는 것은 환영할만한 것이지만, LInux 진영이 그동안 지켜온 많은 소중한 정신들이 훼손되지 않고 긍정적인 방향으로 계속 발전해 나아갔으면 하는 바람을 가져 봅니다.

[Linux 초보 탈출] DNF (package manager)에 대해 알아 봅시다.

elsa in mac — Sun, 20 Jul 2025 22:16:11 +0900

이 포스트는 Fedora Linux를 기준으로 작성되었습니다.

리눅스를 처음 시작하는 유저들이 흔히 묻는 질문 중에 "리눅스 설치하고 가장 먼저 뭘 배워야 합니까?" 라고 묻습니다. 이때 제가 늘 하는 말은 "어떤 리눅스를 사용하는데? 아.. 그래? 그럼 XXX부터 배워야지~"라고 말해주곤 하는데, XXX가 뭐냐 하면 바로 해당 리눅스의 기본 패키지 관리자(Package Manager)를 배우라는 것입니다.

제 아무리 뛰어난 OS를 설치했다 하더라도 프로그램을 설치하거나 설치된 프르그램을 관리할지 모른다면 무슨 의미가 있겠습니까? 그래서 가장 먼저 배워야 할 것 중에 하나는 본인이 사용하는 리눅스 배포판의 기본 Package Manager에 대해 알아야 합니다.

이 번 포스트에서는 Redhat 계열의 리눅스에서 기본으로 사용되는 Package Manager인 DNF에 대해 알아봅니다. 설명을 하는 과정에서 Linux와 관련된 여러 가지 또 알아보게 될 것입니다.

DNF(Dandified YUM)

Linux에는 매우 다양한 배포판(distro) 이 존재합니다. 배포판은 영어로 Distribution 인데, 왜 Distro라고 쓸까 ? Distribution 이라고 표현하면 너무 딱딱하고 발음도 길어서, 짧고 발음하기 쉽게 distro라고 표현을 합니다. 영어권에서 -o로 끝나는 형태는 비공식 줄임말인 경우가 꽤 있습니다. combination의 줄임말 combo, limousine의 줄임말 limo 같은 것들이 있습니다.

흔히 개념적으로 볼 때, Linux라는 것은 원래는 운영체제의 핵심인 Kernel 만을 의미합니다. 하지만, 우리들이 사용할 수 있는 OS(운영체제)라고 하면 Kenrel 만 있는 것이 아니라 그 밖에 다양한 소프트웨어와 도구들이 있아야 하죠. 이렇듯 Kernel과 그 밖에 운영체제를 구성하기 위해 필요한 라이브러리들과 소프트웨어, 유틸리티 등등을 모두 포함하여 Linux 배포판이라고 칭합니다. 따라서 각각의 배포판들은 특화된 사용 목적, 타깃 사용자 층, 혹은 특정한 목표나 철학을 담아내기 위한 것들로 차별화되어 있습니다.

Linux 배포판을 구분할 때, 우리는 계열(Family) 그러니까 족보를 따지는데, 각 배포판의 근원(root)이 뭐냐 하는 것입니다. 대표적으로 Debain, Red Hat, Arch 등이 있습니다. 이 Root에서 뻗어 나온 것들이 Debian 계열에서는 Debian, Ubuntu, Mint, Pop!_OS, Kali 가 있고, Red Hat 계열의 대표적인 Distro에는 RHEL(Red Hat Enterprise), Fedora, CentOS, Rocky 등이 있으며, Arch 계열에서는 Arch, Manjaro, EndeavourOS 등이 있습니다.

각 배포판들은 나름의 패키지 관리자를 갖고 있는데, Debian 계열에서는 APT(Advanced Package Tool), Red Hat 계열에서는 DNF(Dandified YUM), Arch 계열에서는 Pacman(Package Manager)를 사용합니다.

Fedora를 사용하다가 Ubuntu를 사용할 때, 혹은 그 반대의 경우라도 가장 불편한 것 중에 하나가 바로 이 package manager가 바뀜으로 해서 느끼는 어색함인 경우가 많습니다.

정리를 해 보면, 이번 포스트에서 다룰 DNF package manager는 Red Hat 계열에서 사용하는 대표 package manager 인 것이죠.

DNF는 Dandified YUM의 약자입니다. 직역을 해 보자면 "세련된 YUM"이라고 할 수 있겠죠? 그럼 YUM은 뭐냐? DNF 이전에 Red Hat 계열에서 통용되던 package manager입니다. Red Hat 계열에서는 .rpm 확장자를 사용하는 package를 이용하는데, RPM은 Red Hat Package Manager의 약자로 macOS의 .pkg 나 Windows의 .msi 등과 같이 설치할 소프트웨어 세트와 함께 설치에 필요한 Meta Data(설치 지침, 의존성 정보)등을 포함하고 있는 파일입니다.

DNF는 YUM의 성능 개선 버전인 셈인데, YUM(Yellow Updater, Modified)은 그 전신인 Yellowdoc Linux에서 사용하던 Yellowdoc Updater 패키지 관리자(YUP)에서 유래한 것입니다. Yellowdoc Linux는 PowerPC에서 구동할 수 있는 Linux 배포판으로 당시를 회상해 보면, Apple의 Macintosh 나 Sony의 PS3 에서 사용했었습니다. 여기서도 RPM을 사용했었죠. 암튼, 이 YUP을 수정 업그레이드 시킨 것이 YUM 이였고.. 이를 계승하여 보다 복잡해진 의존성 문제 해결, 대량의 package의 신속하게 처리, 보다 적은 리소스 소모 등의 성능 및 기능 확장판이 바로 DNF 입니다. 과거부터 사용해 오던 사용자들을 배려하여 여전히 yum 명령을 사용할 수 있지만, 실질적으로 yum은 dnf에 symbolic link로 연결되어 있어 실제적으로는 dnf를 사용합니다.

yum은 /usr/bin 폴더에 위치하지만 실제로는 dnf의 symbolic link 이다.

패키지 관리자가 갖는 가장 강력한 장점은 의존성관련 처리를 해준다는 것입니다. dnf를 통해 특정 패키지를 설치하면 dnf는 패키지에 기록된 의존성 관련 정보를 확인하고 이를 이용하여 자동으로 해당 패키지를 사용하기 위해 필요한 관련 패키지들을 설치해 줍니다. 과거 이런 기능이 없었던 때에는 일일이 사용자들이 관련 패키지들을 설치하고 관리해야 했기 때문에 굉장히 힘들었었는데, dnf 가 이를 알아서 관리해 주기 때문에 굉장히 편리해진 셈입니다. 서로 다른 패키지들이 동일한 의존성 패키지를 필요로 할 때 만일 의존성 패키지의 버전을 서로 다르게 원할 경우라도 dnf 는 여러 버전의 패키지를 다 설치해 주고 관리합니다. 또한 사용자가 특정 패키지를 제거한 경우 dnf는 자동으로 의존성을 확인하고 필요 없어진 패키지들을 제거할 수 있는 정보를 제공할 수도 있습니다. 이런 각각의 내용은 아래에서 다시 다뤄보게 될 것입니다.

RPM(Red Hat Package Manager)

자, 그럼 .rpm 패키지 파일에 대해 좀 알아봅니다. DNF가 다루는 rpm 패키지에는 naming 규칙이 있습니다.

[name]-[version]-[release].[architecture].rpm

# name    : 패키지 이름 , - 을 사용하여 subpackage임을 명시
            ex) samba-devel
# version : 버전 
# release : name + version 을 사용하며, 다시 패키징할 때 번호를 1씩 증가
# architecture : 
  - x86_64  : 64비트 Intel/AMD 프로세서 
  - i686    : 32비트 Intel 호환 프로세사 
  - aarch64 : 64비트 ARM 프로세서 
  - ppc64le : 64비트 PowerPC 프로세서 
  - noarch  : 특정 아키텍쳐어 종속되지 않음(스크립트, 문서 등) 
  - src     : RPM 패키지 소스

상식 차원에서 Arm 은 회사 이름이고, ARM은 아키텍처(기술)를 지칭할 때 사용합니다. 우리나라 신문 기사를 보면, 회사를 지칭할 때 ARM을 쓰는 경우가 많은데, 이건 현재로선 잘못된 것입니다. 물론 완전 엉터리는 아닙니다. 왜냐면 과거에는 회사 이름도 ARM 이였기 때문입니다만, 2017년에 회사는 ARM Holdings를 Arm으로 변경했습니다.

그래서, 예를 들자면 .rpm 패키지는 아래와 같은 이름으로 배포가 됩니다.

nano-8.3-3.fc42.src.rpm

name        : nano 
version     : 8.3
release     : 3.fc2 - fedora 42 용 3번째 릴리즈
archtecture : src

rpm 패키지는 repository(저장소)를 통해 배포하는 것이 일반적입니다

Linux를 설치하면, 설치 디스크나 디스크 이미지에서 기본적은 패키지들을 설치한 후, 인터넷을 통해 배포판이 운영하는 공식 Repository를 통해 업데이트를 하게 됩니다. Fedora의 경우에는 updates, fedora 라는 공식 저장소를 운영하고 있으며, 새롭게 추가된 패키지, 업데이트 소식들을 전용 홈페이지를 통해 확인할 수 있습니다. 공식 저장소에 포함된 모든 패키지들은 Fedora가 엄격한 패키징 가이드라인(Packaging Guideline)을 준수, 철자한 Review를 통해 품질 보증(QA) 프로세스를 유지합니다. 이와는 별도로 Copr(Cool Other Package Repo)라는 커뮤니티 기반의 빌드 서비스 및 커뮤니티 저장소가 운영됩니다.

.rpm 패키지는 cpio라는 아카이브 형식을 갖춘 일종이 압축파일입니다 따라서, 만일 rpm 파일을 다운로드 받았다면 rpm2cpio와 cpio를 이용하여 .rpm 파일을 압축해제 할 수 있습니다.

rpm2cpio test.rpm | cpio -idmv

rpm2cpio 와 cpio를 이용하여 rpm 파일의 압축을 해제한 예

패키지 업그레이드, 검색, 설치, 제거

DNF 가 뭔지는 이 정도로 알아보면 될 것 같고, 그럼 이제 실제로 어떻게 사용하는지를 알아봐야겠습니다.

우선, dnf를 이용할 때는 항상 앞에 sudo 명령어를 붙입니다 sudo(superuser do) 는 사용자 권한을 갖는 유저가 일시적으로 root 권한을 얻어 특정 명령을 실행할 수 있도록 해주는 도구로 Linux 시스템의 권한 관리 및 보안 원칙을 준수하고자 하는 이유 때문입니다. 대부분의 패키지들은 시스템 파일들과 의존성이 있고 따라서 설치도 root 권한으로 접근 가능한 디렉터리에 설치하게 됩니다. 이런 이유로 일반적으로 package를 검색하거나 정보를 확인할 때는 sudo 를 사용하지 않고 dnf만 사용해도 무방하지만, 설치/업데이트/제거 등 실질적으로 변경을 가할 때는 sudo를 사용해야만 합니다.

sudo를 사용하면 보안관계상 사용자의 비밀번호를 물어보게 되는데, 이것이 불편할 수 있습니다. sudo를 사용할 때 비밀번호를 묻지 않게 하려면, 터미널에서 sudo visudo 명령으로 /etc/sudoers 파일을 열고, 해당 파일의 내용을 확인합니다.

파일 내용 중에 %wheel ALL=(ALL) NOPASSWORD: ALL 이 주석처리 되어 있다면, 주석을 제거하여 활성화시키고 저장합니다.

여기서 wheel 이라는 것은 특수 권한을 가진 사용자 그룹을 의미하는 용어입니다. Big Wheel에서 유래된 용어인데, 1970년대 초기 UNIX 시스템에서 사용하던 용어로 큰 영향력 또는 권력을 가진 사람을 의미하는 은어이며, 시스템에서 최고 관리자 권한을 가진 사용자를 지칭합니다. 따라서, 본인의 계정을 wheel 그룹으로 지정하면 sudo 명령을 사용하여 root 권한으로 실행할 수 있는 일들을 할 수 있습니다.

자신의 계정이 어떤 그룹에 포함되는지를 확인하려면 groups 이라는 명령어를 사용하면 확인할 수 있습니다.

groups 명령으로 자신이 어떤 그룹에 속해 있는지를 확인할 수 있다.

Fedora를 사용한다면, 기본적으로 사용자는 wheel 그룹으로 등록이 되어 있지만, 만약 wheel 그룹이 없다면 다음 명령으로 wheel 그룹에 등록할 수 있으며, 그룹 등록 후에는 logout -> login 해야 효력을 발생합니다.

sudo usermod -aG wheel <계정이름>

# 옵션 a : append (추가)
# 옵샨 G : groups 라는 의미

패키지 업데이트 : sudo dnf update (또는 upgrade)

가장 흔하게 많이 사용하는 것은 바로 설치된 패키지들을 update 하는 것입니다 sudo dnf update 명령을 내리면 dnf는 시스템에 설치된 repository를 통해 새롭게 업데이트된 패키지들이 있는지의 여부를 확인하고, 있으면 해당 정보를 읽어 온 후 사용자에게 알려 주게 됩니다.

sudo dnf update 의 예

업데이트 목록에는 package 이름과 버전, 자정소 위치, 그리고 설치 크기 정보를 제공합니다. 그리고 사용자에게 업데이트할지의 여부를 물어보게 되지요.

yum을 사용하던 시절에는 update와 upgrade가 별도로 존재했었지만 dnf 에서는 이 둘 간의 차이가 없으며, 내부적으로는 upgrade로 처리합니다. 일반 패키지를 대상으로 할 때는 update는 그냥 alias(별칭)인 셈입니다. 참고로 Debian 계열의 APT 에서는 update와 upgrade를 명확히 구분합니다. update는 패키지 저장소의 메타데이터(패키지 목록, 버전 정보 등)만 업데이트하고 실제 시스템의 패키지들을 업그레이드하지 않습니다. 실제로 본인의 컴퓨터에 설치된 패키지를 업데이트하려면 upgrade 명령을 사용해야 합니다. 따라서 ubuntu 사용자들은 먼저 update를 한 후, upgade를 해야 합니다.

하지만, dnf 에서는 구분이 없이 update 던 upgrade이던 동일하게 최신 저장소의 메타데이터를 확인하고 필요한 경우 다운로드하며, 설치된 패키지들을 최신 버전으로 업그레이드할 수 있는 인터페이스를 지원합니다.

다만, 시스템을 업그레이드할 경우에는 upgrade를 사용해야 합니다. 예를 들어 fedora 41 버전을 사용하고 있는데, fedora 42로 업그레이드를 한다면 이 때는 sudo dnf system-upgrade 라는 명령을 사용합니다.

dnf의 update가 갖는 특징은 새로운 패키지가 설치될 때는 알아서 종속성이 있는 패키지들을 자동으로 설치를 해 준다는 점

위의 스샷에서 처럼 sudo dnf update를 했을 때, 여러 개의 패키지가 업그레이드 대상으로 리스트 업 되었지만, 사용자는 특정 패키지만 선별적으로 update 할 수 있습니다.

sudo dnf update <패키지명> <패키지명>

위의 스샷을 예를 들자면, sudo dnf update를 했을 때, 제일 하단에 upgrade를 할 것인지 (y/N)로 물어보는데, 전체를 다 업그레이드하지 않고 특정 패키지만 우선 upgrade 하고자 한다면 N(no)를 선택하여 빠져나온 후, sudo dnf update NetwoekManager 이렇게 패키지 명을 정의해서 해당 패키지만 upgrade 할 수 있습니다. 물론 sudo dnf update fcitx5 fcitx5-hangul 처럼 package 명을 나열하면 해당 패키지들만 한 번에 upgrade 할 수 있습니다.

update 패키지 중에 kernel과 관련된 패키지의 경우 주의해야 할 것이 있습니다. kernel 패키지를 업데이트할 때는, 시간이 꽤 오래 걸립니다. 컴퓨터 환경에 따라 다르겠지만, 수 분 내지 수십 분이 걸릴 수도 있습니다. 커널 패키지는 설 치 후 스크립트(post-install scripts)가 꽤 많이 실행됩니다. 이유는 kernel 과 관련된 모듈, 드라이버, 펌웨어 등에 대한 설치 및 upgrade를 동반할 수 있기 때문입니다. 그래서 시간이 오래 걸린다고 중간에 중단을 시키거나 컴퓨터를 꺼 버리게 되면, 부팅이 되지 않는 황당한 일이 벌어질 수 있습니다. 온전히 upgrade가 마무리될 때까지 기다려야 하며, 끝난 후에는 아래처럼 kernel이 잘 등록되었는지 확인해야 합니다.

ls /boot 으로 /boot 폴더를 확인해 보면, kernel 버전 별로 6 종류의 파일이 존재하는 것을 볼을 알 수 있습니다. Fedora의 경우 만일을 위해 3개의 버전을 유지하며, 새로운 kerenl 이 업데이트되면, 가장 과거의 것부터 제거를 하고 항상 3개 버전을 유지합니다. 업데이트 후에 최신 업데이트 버전이 존재하지 않거나 일부만 포함되어 있다면, 절대 rebooting을 하지 말고 kernel을 다시 update 해야 합니다.

패키지 검색 : sudo dnf search <검색 키워드>

패키지를 검색할 때는 search 명령을 사용하면 됩니다. 검색 단계에서는 패키지 명을 정확히 모를 수 있으므로 자신이 찾고자 하는 검색어로 검색을 하면 됩니다.

vim 이라는 키워드로 검색을 한 경우

검색 키워드는 패키지 이름, 요약, 설명 등 패키지 메타데이터의 정보 전반을 근거로 검색하게 됩니다.

앞서 설명에서 검색의 경우에는 굳이 sudo를 붙이지 않아도 된다고 설명을 했었지만, 그래도 sudo를 사용하여 검색을 하는 것이 좋습니다. 이유는 sudo는 root 권한이고 sudo를 사용하지 않으면 일반 사용자 권한이기 때문입니다. 이게 뭔 소리냐 하면.. 어쩔 수 없이 패키지를 설치하려면 sudo 를 사용해야 하는데, 그럼 결국 관리할 패키지들의 정보는 root 계정의 저장소에 저장되고 관리된다는 것입니다. 그런데 dnf search를 명령하면 사용자 계정 권한으로 dnf package 정보를 가져오고 관리할 목적으로 사용자 계정 폴더에 또 정보를 저장하게 됩니다. 이건 시간도 오래 걸리고 정보를 이중으로 관리하는 셈이니 어차피 sudo로 설치할 것, 그냥 모두 root 권한으로 사용하는 것이 편하다는 것입니다.

패키지 정보 확인 : sudo dnf info <패키지 명>

설치 여부와 관계없이 특정 패키지의 정보를 확인하고 싶다면 info 명령을 사용하면 됩니다.

boxes-vim 이라는 패키지의 정보를 확인

위의 스샷처럼 info 명령 뒤에 패키지 명을 주면 해당 패키지에 대한 정보를 간략히 보여 줍니다. Available package라는 것은 "설치는 되어 있지 않으므로 설치를 할 수 있다"는 의미입니다. 이미 설치가 되어 있다면, Installed packages 라고 표시가 됩니다. 보시면 여러 항목들이 있지요. 대부분은 직관적으로 알 수 있는 항목들입니다.

특별히 Epoch(에포크)라는 게 있는데, 이 것은 버전 충돌을 방지하기 위해 만들아 놓은 특수 필드입니다. 만일 공식 패키지가 1.2.3 버전으로 릴리즈가 되었는데, 나중에 알고 봤더니 이 패키지에 문제가 있습니다. 예를 들자면 메타데이터가 잘못되었거나, 종속성 정보가 잘못되었거나 혹은 일부 파일이 빠져 있었다던가. 등등.. 해당 패키지의 upstream version은 바뀐 것이 없으니 버전을 바꿀 수는 없습니다. 하지만 문제를 해결한 버전이라면 이전 패키지의 업데이트 버전으로 배포하여야 하는데, 이럴 때 upstream 버전을 변경하 않고 배포판만 업해서 배포할 목적으로 이 필드가 존재합니다. 따라서, 대부분은 0 이거나 이 필드가 없습니다. 해당 필드가 존재하고 값이 0 이 아니라면 이전 배포 패키지에 뭔가 문제가 있어 다시 배포된 패키지라고 판단하면 됩니다.

패키지 설치 : sudo dnf install <패키지 명>

패키지를 새로 설치하려면 install 을 사용합니다.

nano 패키지를 설치하는 예

위의 스샷은 nano 라는 패키지를 설치하는 예입니다. 설치할 패키지가 nano 딱 한 개 인 것을 보면 추가적으로 설치할 종속성 패키지는 없는 것을 알 수 있습니다. 설치는 711 KiB 이고, 다운로드할 크기도 동일합니다. 하지만 실제 설치될 크기는 3 MiB 임을 알 수 있죠. 그리고, [y/N] 으로 사용자의 선택을 대기합니다.

여기서 또 상식 하나 알고 갑시다.
파일이나 저장장치의 크기를 말할 때, KB(킬로 바이트), MB(메가 바이트), GB(기가 바이트) 요렇게 표현을 하는데, 언제부턴가 KiB, MiB, GiB 등을 사용하게 됩니다. 컴퓨터는 2진법을 사용하기 때문에 전통적으로 1GB는 1024MB라고 알고 있었습니다. 반면 저장장치 제조사들은 이를 제정 규칙대로 10진법으로 표시했습니다. 원래 KB, MB, GB는 10진법이었기 때문입니다. OS에서 1024로 계산된 결과를 본 사용자들은 1TB 저장장치를 사서 컴퓨터에 달면 저장용량이 적게 표시되는 오해를 하게 되었고, 제조사를 상대로 소송전이 벌어지기도 했죠.. 100개의 사과를 4로 나누면 25이고, 5로 나누면 20 입니다. 표시는 25 또는 20으로 표시되지만 본질인 100개는 변함이 없지요. 그래서 결국 1990년대 후반, 이러한 혼란을 해결하고자 IEC(국제 전기 기술 위원회)에서 KiB, MiB, GiB 같은 이진 접두어를 제정하게 되었고, OS 에서 이를 구분하여 표시하게 됩니다. 물론 지금도 KB, MB,GB로 표시하는 OS들이 있고 여전히 일부에서 혼란은 계속되고 있지요..

자 다시 본론으로 돌아와서, 보통 default 값은 대문자로 표기합니다. [y/N] 이므로 사용자가 그냥 Enter키를 치면 설치를 하지 않겠다(No)가 됩니다. 따라서 설치를 하려면 y를 키인 하고 enter키를 처야 합니다.

설치

y를 키인하고 enter를 치면 위의 스샷처럼 해당 패키지를 설치합니다. 다운로드 > verify > Prepare > Installing > complete 과정으로 진행됩니다.

verify 단계에서는 파일의 무결성(Integrity)과 진위성(Authenticity)를 확인합니다. 이는 손상되거나 악성 코드가 삽입된 패키지가 설치되는 것을 방지하기 위한 단계입니다.

prepare transaction 단계는 실제로 설치를 하기 전 필요한 사전 작업을 수행하는 단계로 외존성 패키지를 마지막으로 확인하고 설치된 패키지들 과의 충돌 및 단종(Obsoletes) 문제가 있는지를 최종적으로 판단합니다. 어떤 파일을 어디에 설치할지, symbolic link를 만들어야 하는지의 여부, 설치 과정에서 어떤 스크립트가 실행어되어야 할지를 판단합니다. 이를 통해 설치 중에 설치가 중단되거나 오류가 발생되는 등의 무결성을 확정합니다.

Installing 단계는 실체로 패키지의 설치 파일들을 해당 위치에 복사하고 스크립트를 실행하여 서비스 활성화, 데이터베이스 초기화, 권한 및 소유권 설정 등의 처리를 하게 됩니다.

만일, repority의 공식 패키지가 아니고 사용자가 임의로 다운로드 받은 .rpm 파일을 install 하고자 한다면 어떻게 해야 할까 ?

공식 또는 비공식 repository가 아닌 .rpm 파일을 설치할 경우에도 동일하게 install 명령을 사용하면 됩니다.

keymapper 라는 rpm 패키지를 다운로드 받았다.

예를 들어 위의 스샷과 같이 keymapper rpm 패키지를 다운로드하였고 이를 설치하고 싶다면. 아래와 같이 명령합니다.

sudo dnf install ./keymapper-4.12.3-Linux-arm64.rpm

여타 저장소를 통한 패키지 설치와 동일하지만, 위의 스샷에서 보는 바와 같이 Repository가 commandline 으로 되어 있는 것을 알 수 있습니다. 이 외에 차이는 없고 동일하게 진행됩니다.

rpm 파일을 직접 설차한 패키지의 info

사용자가 직접 설치한 rpm 패키지의 info를 보면, 역시 From repository 필드가 commandline으로 되어 있는 것을 알 수 있지요.

그럼, 사용자가 직접 설치한 패키지는 어떻게 upgrade를 할까 ?
만일, 개발자가 다음 업데이트 버전을 배포했다면.. 그 버전을 다운로드한 후에 sudo dnf install.. 로 다시 install 을 하면 됩니다. 개별적으로 다운로드한 rpm은 update 정보를 확인할 수 없기 때문에 그냥 install을 하면 dnf 가 알아서 기존에 설치된 패키지와 비교를 하고 업데이트 버전이라는 것을 파악하게 됩니다. 따라서 자연스럽게 upgrade를 하게 됩니다.

패키지 제거 : sudo dnf remove <패키지 명>

기존에 설치된 패키지를 제거하고 싶다면 remove 명령을 사용합니다.

패키지 제거의 예

remove 명령을 내리면, 위의 스샷처럼 제거될 package 정보를 표시하고 사용자의 최종 결정을 대기합니다.

y를 키인하고 Enter를 치면, 이제 실제 제거를 수행하게 됩니다.

제거는 prepare, removing 두 단계로 진행됩니다. 각 단계는 install 단계와 동일한 기능을 수행한다고 보면 됩니다.

remove와 관련하여 좀 더 생각해 볼 것이 있습니다. 설치된 특정 패키지를 제거할 때, 의존성 때문에 함께 설치된 패키지들이 있을 수 있습니다. 그럼 해당 패키지를 제거하면 함께 설치되었던 의존성 패키지들도 함께 제거되는 것일까? 결론은 그럴 수도 있고 그렇지 않을 수도 있습니다. 만일 함께 설치되었던 의존성 패키지들이 다른 설치 패키지에서도 사용된다면 dnf는 이를 확인하고 해당 패키지는 제거 목록에서 제외합니다. 패키지 관리자를 사용하는 이점이 이런 데 있는 것이죠.

그럼 반대로, 어떤 패키지를 제거하는데, 해당 패키지를 설치할 때 의존성 패키지가 함께 설치된 적은 없습니다. 하지만 삭제할 패키지가 반대로 다른 설치 패키지에서 필요한 것이라면? 이럴 경우에는 해당 패키지가 제거됨으로써 영향을 받는 패키지들을 모두 삭제하려고 시도하게 됩니다.

codec2 패키지를 remove 하려고 시도한 경우

위의 스샷은 codec2라는 패키지를 remove 하는 경우를 보여 줍니다. codec2는 Audio/Video 프로그램들이 사용하는 codec으로 이 패키지를 제거함으로써 영향을 받는 패키지들을 제시하고 있는 것을 볼 수 있습니다.

Removing Dependent packages: 목록은 codec2와 매우 강력한 의존성을 가지고 있기 때문에 codec2를 제거하면 사용할 수 없어서 함께 제거를 할 것이라고 제안한 목록입니다. 스샷에는 없지만 Removing unused dependencies: 항목도 있는데, 이 섹션에 열거된 패키지 목록은 해당 패키지를 제거함으로써 시스템의 어떤 패키지도 사용을 하지 않게 되는 패키지(이를 보통 "orphan(고아)"라고 표현함) 목록입니다. codec2와 직접적인 의존성은 없지만, codec2를 제거함으로써 함께 제거되는 패키지들이 있을 수 있고, 이들을 다 제거하게 되면 아무도 사용하지 않게 되는 패키지들이 있다는 정보입니다.

따라서 이러한 패키지들은 웬만해서는 제거에 신중해야 합니다. 기존에 사용하던 다양한 영역에서 파급 효과가 대단히 크기 때문입니다. 설치는 가볍게 할 수 있지만, 제거는 신중해야 한다는 의미가 됩니다. 그럼에도 불구하고 해당 패키지를 제거해야 하는 피치 못할 사정이 있다면, 이 경우에는 dnf를 사용하지 않고 아래와 같이 rpm -e 명령을 사용해서 특정 패키지만 제거할 수 있습니다.

sudo rpm  -e --nodeps <패키지 명>

하지만, 이렇게 의존성이 높은 패키지를 제거할 경우 dnf에서는 꽤 혼란이 발생할 수 있습니다. 따라서 가급적이면 dnf로 관리된 패키지는 dnf로 계속 관리하는 것이 좋고 의존성이 높은 패키지는 그냥 놔두는 것을 권장합니다.

패키지 다운그레이드, 히스토리 관리

자 이제, 일반적인 사용이 아닌 좀 특별한 경우에 대해 알아봅니다.

패키지 다운그레이드 : sudo dnf downgrade <패키지 명>

어떤 패키지를 upgrade 했습니다. upgrade 하기 전까지는 문제가 없었는데, upgrade를 하고 나니 이전과 달리 뭔가 이상해졌습니다. 이럴 경우 이전 버전으로 되돌릴 필요가 있을 수 있는데, 이럴 때 downgrade를 할 수 있습니다.

우선, 해당 패키지로 downgrade를 할 경우 downgrade가 가능한 버전들이 무엇이 있는지를 확인할 필요가 있을 겁니다. 이럴 때는 list 명령의 --showduplicates 옵션을 사용합니다.

sudo dnf list --showduplicates <패키지 명>

스샷을 보면 chromium browser에 대해 list --showduplicates 옵션을 수행한 결과입니다.

현재 설치된 것은 138.0.7204.100-1 버전이고, 사용 가능한 다른 버전의 패키지가 두 개 더 있음을 알 수 있습니다. 6998 버전과 7204.157-1이죠. 흰색은 과거 버전이고 파란색은 다음 버전을 의미합니다.

만약 지금 설치한 138.0.7204 버전이 문제가 있어서 과거 버전으로 되돌아가고 싶은데, 만약 바로 직전의 버전으로 되돌아가고 싶다면 아래와 같이 downgrade 명령을 사용합니다.

sudo dnf downgrade <패키지 명>

downgrade의 예

스샷을 보면, 두 개의 패키지를 이전 버전으로 되돌릴 것임을 알 수 있습니다. 7204.100 버전을 6998.165 버전으로 되돌릴 것이라고 알려주고 있군요. 처리 과정에서 319 MiB가 소요되며, 298 MiB만큼 제거할 것이라고 합니다. 그래서 21 MiB만큼이 더 소요될 것이라 합니다.

만약 downgrade를 했는데, 여전히 문제가 있어서 그 이전 버전으로 더 되돌아가고 싶다면 동일하게 계속 downgrade 명령을 내리면 됩니다. 물론 패키지에 따라 바로 직전 버전까지만 관리되는 패키지도 있고, 꽤나 많은 이전 버전을 관리하는 경우도 있습니다. downgrade의 수준은 각 패키지마다 다를 수 있습니다.

자, 그러면 예를 들어 진짜 특정 패키지를 upgrade한 후에 문제가 발생하여 어쩔 수 없이 downgrade를 했다고 가정을 해 봅니다. 이 경우 sudo dnf update를 수행하면 해당 패키지의 다음 버전(문제가 된 그 버전)이 있다며 update 목록에 나타나게 될 것입니다. 이거 보기 싫다고 sudo dnf update를 안 할 수도 없고 말이죠. 이렇게 특정 패키지의 특정 버전을 배제하고 싶다면 update의 --exclude 옵션을 사용합니다.

sudo dnf update --exclude=<패키지 명>

--exclude=<패키지 명>을 하면 이후부터는 아예 해당 패키지는 업데이트가 있어도 표시를 해 주지 않습니다. 말 그대로 패키지 update에서 배제를 시키는 것입니다.

sudo dnf update --exclude=chromium 을 실행한 예

위의 예에서 볼 수 있듯이, --exclude=chromium 으로 update를 요청하면 skip 항목으로 잡혀서 해당 패키지는 update에서 배제시킬 수 있습니다. 하지만, 매 번 update를 확인할 때마다 --exclude 옵션을 다는 것도 귀찮자요.

패키지 버전 고정 : sudo dnf versionlock <패키지 명>

이럴 경우 versionlock 기능을 사용하면 편리합니다.

이 방법은 특정 패키지의 버전을 고정(lock)시키는 것으로, 이 기능을 사용하려면 plugins-core 패키지가 설치되어 있어야 합니다. 설치가 안 되어 있다면 아래와 같이 설치를 해 줍니다. (아마 기본으로 설치가 되어 있을 겁니다.)

sudo dnf install dnf-plugins-core

설치가 된 이후에는 다음과 같이 명령을 내려 특정 패키지의 버전을 고정할 수 있습니다.

sudo dnf versionlock add chromium

이 명령을 내리면, 현재 설치된 chromium 버전으로 lock 됩니다.

dnf의 versionlock 으로 패키지 버전을 고정시킨 예

스샷을 보면, chromium 패키지가 현재 사용 중인 138.0.7204.100 으로 lock 된 것을 확인할 수 있습니다. verlosionlock 의 목록은 list 명령으로 확인할 수 있습니다.

sudo dnf versionlock list

스샷을 보면, 2025-07-20일 17:45분에 chromium 패키지가 138.0.7204.100-1 버전으로 lock 되어 있는 것을 알 수 있습니다. 이렇게 versionlock 이 걸린 패키지는 sudo dnf update 명령을 내렸을 때, --excludes 옵션을 사용했을 떄와 동일하게 skip 목록으로 분리 되게 됩니다.

나중에 해제를 하고 싶다면

sudo dnf versionlock delete chromium

처럼, delete 명령을 내리면 됩니다.

패키지 설치 기록 확인 : sudo dnf list --installed

경우에 따라, 설치된 패키지 목록을 확인할 필요가 있을 수 있는데, 이 때는 list-installed 명령을 사용하면 됩니다.

sudo dnf list --installed

이 명령을 내리면 현제 설치된 모든 패키지 정보를 볼 수 있습니다.

사용자가 설치한 패키지 목록 확인 : sudo dnf repoquery --userinstalled

sudo dnf list --installed는 사용자가 설치한 패키지와 의존성 때문에 설치된 패키지들까지 포함하여 설치된 모든 패키지의 목록을 확인할 수 있습니다. 반면, repoquery 명령을 사용하면 사용자가 설치한 패키지 목록만 확인할 수 있습니다. 이 subcommand도 versionlock과 마찬가지로 dnf-plugins-core를 설치해야 사용할 수 있습니다.

이 명령이 갖는 의미는 의존성이 배제된 사용자가 직접 설치한 패키지 목록을 얻을 수 있다는 것으로, 이 목록을 이용하여 추후 다른 컴퓨터에 동일한 상태의 구성을 하거나 현재 사용하는 컴퓨터가 사용 불능 상태가 되어 다시 설치를 해야 할 경우 등에 요긴하게 사용될 수 있다는 것입니다.

설치 히스토리 확인 : sudo dnf history

dnf 는 처음 컴퓨터에 linux를 설치했을 때부터 현재까지의 모든 패키지 관련 기록을 모두 갖고 있습니다. 이는 history 서브 커멘드를 통해 확인할 수 있습니다.

sudo dnf dnf history list

sudo dnf history list 명령이 결과

가장 최근에 수행한 작업부터 표시를 해 주는데, 스샷에서 볼 수 있듯이 ID 번호, Command, 해당 명령을 수행한 날짜 그리고 그로 인해 변경된 package의 수를 표시해 줍니다. 각각의 작업을 Transaction(트렌젝션) 이라고 부릅니다.

가장 마지막에 처리한 트렌젝션에 대한 정보를 확인하려면 아래와 같이 sudo dnf history info 명령을 사용하면 됩니다.

sudo dnf history info

스샷에서 볼 수 있듯이, 언제 누가 어떤 package들을 설치, 제거, 업데이트했는지를 확인할 수 있습니다.

sudo dnf history info <ID>

sudo dnf history list 에서 확인한 특정 ID의 내용도 확인 가능 합니다.

sudo dnf history undo <ID>

undo 명령을 사용하면 해당 ID의 트렌젝션을 되돌립니다. 즉, 해당 트렌젝션에서 설치한 패키지는 제거하고, 제거한 패키지는 다시 설치합니다. 업데이트한 패키지는 반대로 다운그레이드됩니다.

sudo dnf history redo <ID>

redo는 ID에 해당하는 트렌젝션을 다시 수행합니다. undo와 마찬가지로 설치한 패키지는 설치를 제거한 패키지는 제거, 업그레이드한 패키지는 역시 동일하게 업그레이드합니다.

sudo dnf history rollback <ID>

rollback 은 ID 트렌젝션 "직전"의 상태로 시스템을 되돌립니다. 즉, ID 트랜젝션부터 현재까지 수행된 모든 DNF 작업들을 모두 최소하고 ID 트랜젝션이 완료된 직후로 시스템을 되돌립니다.

저장소 관리

이번 포스트의 마지막 주제입니다. dnf 저장소 관리는 어떻게 하는지 살펴봅니다.

우선, 저장소의 목록을 확인은 repolist 명령을 사용합니다.

sudo dnf repolist

sudo dnf repolist 수행 결과

--all 옵션을 추가하여 sudo dnf repolist --all 을 명령하면, 비활성화된 repo까지 모두 확인할 수 있습니다.

저장소 정보는 /etc/yum.repo.d 폴더에서 관리됩니다.

특정 repository를 활성화 혹은 비활성화하고 싶다면 해당 폴더의 해당 repo 파일을 직접 수정하면 됩니다.

파일을 root 권한 에디터로 열고 보면, 맨 아래에 enabled=1이라고 되어 있는데, 이 값을 0으로 바꾸면 disable 시킬 수 있습니다. 아예 repository를 제거하고 싶다면 해당 파일 자체를 삭제하면 됩니다만, 삭제할 경우 업데이트나 의존성 문제 등 혼란을 야기할 수 있는 만큼, 특별한 문제가 없다면 그냥 놔두는 것이 좋습니다.

- - - - -

글을 쓰다 보니 생각보다 꽤 긴 글이 되었네요.

서두에서도 말했듯이, Linux를 처음 설치하고 사용하는 유저 입장에서는 프로그램을 어떻게 설치하고 관리해야 하는지 방법을 익히는 것이 매우 중요하고 필수적입니다. 물론, Fedora Linux를 사용한다고 가정했을 때 패키지 매니저는 DNF만 있는 것은 아닙니다. Flatpak, Snap, AppImage 등등이 있으며, 직접 소스 코드를 빌드해서 설치할 수도 있습니다. npm, go, cargo, pip 등 특정 언어에 종속된 것들까지 매우 다양하죠. 이런 것들은 Linux를 사용해 가면서 자연스럽게 필요에 의해서 익히고 배우며 사용하게 될 것입니다. 하지만 DNF는 Red Hat 계열의 기본 패키지 매니저로서 반드시 사용할 줄 알아야 하는 것이니만큼 사용법을 충분히 익히는 것이 중요합니다.

[Linux 초보 탈출] systemd의 timer 유닛을 이용하여 주기적인 작업을 자동화 하자

elsa in mac — Sat, 19 Jul 2025 17:50:37 +0900

이 포스트는 fedora linux를 기준으로 작성되었습니다.

이번 포스트에서는 systemctl의 timer service를 이용하여, 주기적인 반복작업을 자동화하는 방법을 알아보겠습니다.

Linux에서 어떤 특정 작업을 매주 월요일, 혹은 매 시간, 또는 매 10분마다 반복하고 싶다면 어떻게 하면 될까 ? 이것이 이번 포스트에서 다루고자 하는 내용입니다. 방법은 다양하게 존재하지만, 이 번 포스트에서는 Systemd를 이용하여 이 주제를 다뤄 볼 것입니다.

systemd ?

간단하게만 소개.
Linux는 시스템 부팅 과정에서 시스템이 필요로 하는 각종 서비스, 관리자들을 실행 시키게 되는데, 이를 담당하는 역할자가 필요합니다. 과거에는 SysV Init 같은 것이 사용되어 오다가 이를 대처하기 위한 것으로 systemd가 부각되었으며, 오늘날 대부분의 Linux 배포판들은 이를 기본으로 사용하고 있습니다. 모든지 변경하면 장/단점이 생기게 마련 입니다만, 지금은 컴퓨팅 자원이 그렇게 빡빡한 때도 아니기에 거의 표준으로 자리 잡았습니다. 정리하자면, 시스템 및 서비스 관리자라고 할 수 있겠고.. 주요 역할로 병렬 부팅, 서비스 시작/중지/상태 관리, 서비스 간 의존성 중제, 시스템 상태 모니터링, 로깅 등등을 담당합니다.

Linux에서는 백그라운드로 실행되는 프로세스들을 통칭하여 "데몬" 이라고 부르며, 이러한 역할을 하는 프로세스들에 관례적으로 d를 붙입니다.(daemon), 배표적으로 httpd, sshd, syslogd 같은 것들이 있지요.

그럼 왜 하필 daemon 이냐 ?
여러 가지 썰이 있지만, 고대 그리스어의 Daimon(다이몬) 에서 유래되었다는 설이 유력합니다. 신과 인간 사이의 중재자 역할을 하는 존재라고..

systemd timer 서비스

무엇인가를 가장 빠르게 배우는 방법은 use case를 통해 실전에서 경험하는 것입니다. 과정을 이어가면서 그때그때 필요한 것들을 강조해 보죠.

systemd의 timer service는 사용자가 지정한 시간주기를 자동으로 반복하는 것입니다. 이번 포스트에서는 fedora linux의 package update를 10분마다 check 하고, 업데이트할 것이 있다면 이를 유저에게 통보하는 것을 예로 들어 보겠습니다. (실제로 제가 사용하는 것이기도 하구요..)

우선, systemd 서비스에는 root권한으로 관리되는 시스템 레벨과 사용자 레벨 둘로 나눠집니다. 우리는 사용자 레벨 서비스를 이용할 것입니다. 새로운 서비스를 만드는 방법은 단순하고 기계적인데, 우선 service에 대한 정의는 정해진 형식과 파일 naming 규칙을 따라야 하며, 해당 파일들이 위치할 곳은 ~/.config/systemd/user 라는 폴더입니다. 해당 폴더가 존재하지 않는다면 만들어 주면 됩니다.

timer 서비스는 .timer 라는 파일로 정의되며, 사용자가 정의한 일정한 주기에 실행할 서비스인 .service 파일을 정의해야 합니다. 이러한 파일들은 systemd 유닛 파일(unit file)이라고 부릅니다. 예를 들어, check_dnf_update 라면, check_dnf_update.timer 와 check_dnf_update.service 파일을 만들어야 한다는 것입니다. 여기서 주의할 점은 .timer와 .service의 이름이 동일해야 합니다. (확장자만 다를 뿐)

check_dnf_update.timer 분석

# check_dnf_update.timer
[Unit]
Description=10분마다 dnf update 체크

[Timer]
# OnCalendar=Mon *-*-* 00:00:00

# root service라면 systemd가 활성화된 직후, user 라면, login 한 시점 부터 경과된 시간
OnBootSec=1min
OnUnitActiveSec=10min
Persistent=false

[Install]
WantedBy=timers.target

위의 소스코드는 check_dnf_update.timer 의 내용입니다. 각 category 에는 들어갈 수 있는 옵션이 매우 다양하지만, 우리의 목적에 맞게 필요한 것만 간단히 정의합니다. unit file은 예약어에 대해 대/소문자를 엄격이 구분합니다. 띄어쓰기는 융통성이 있으니 꼭 붙여 쓸 필요는 없습니다.

[Unit] 의 Description 은 해당 서비스가 무엇인지를 기술합니다. 이건 기능적인 것은 아니니 원하는 내용을 기술하면 됩니다.

[Timer] 이 부분은 중요하겠죠.
만일, 달력(Calendar)을 기준으로 반복되는 작업일 경우 OnCalendar= 를 사용합니다. OnCalendar의 형식은 다음과 같습니다.

# 기본 형식
DayOfWeek  Year-Month-Day Hour:Minute:Second

# DayOfWeek : 요일 - Mon, Tue, Wed, Thu, Fri, Sat, Sun 
  # * : 모든 요일 
  # Mon..Wed : 월요일부터 수요일까지의 의미 
  # Mon,Thu,Sat : 월요일,목요일,토요일 만 이라는 의미 
  # 정의하지 않으면 * 와 동일 
    
#Year : 년도 
  # YYYY (예 2025)
  # * : 모든 년도 
  # 정의하지 않으면 * 와 동일 

#Month, Day : 월, 일 
  # 두 자리수, Year와 동일한 형식 
    
#Hour   : 시간 (24시간 형식으로 정의, 00 ~ 23), 생략하면 00시 
#Minute : 분 (00 ~ 59) , 생략하면 00분 
#Second : 초 (00 ~ 50) , 생략하면 00초

다음은 예시입니다.

*-*-* 08:00:00         : 매일 오전 8시 
*-*-* *:10:00          : 매시 10분
Mon *-*-* 12:00:00     : 매주 월요일 오전 12시 정각 
Sat,Sun *-*-* 14:30:00 : 매주 토요일과 일요일 오후 2시 30분 정각 
*-*-1 22:00:00         : 매월 1일 밤 10시 정각 
*-jul-16 14:00:00      : 매년 7월 16일 오후 2시 정각 
2025-10-11 15:30:0     : 2025년 10월 11일 오후 3시 30분 딱 1번만 실행

하지만, 단축어로 정의할 수도 있습니다.

hourly  : 매 시각 정각
daily   : 매일 자정 
weekly  : 매주 월요일 자정 
monthly : 매월 1일 자정 
yearly  : 매년 1월 1일 자정

그러니까. OnCalendar로 timer를 정의한다는 것은 절대적인 시간의 기준에서 반복할 주기를 정의하는 것입니다.

예를 들어, "컵퓨터가 부팅되고 나면 5분마다..."이런 요구사항은 절대적인 시간 기준이 없습니다. 컴퓨터가 부팅되는 것이 언제 될지는 아무도 모르는 것이기에 시간이 기준이 아니고 컴퓨터가 부팅되고 systemd가 해당 timer unit를 실행하면 그때부터 5분마다 이벤트가 발생하는 것입니다.

이렇듯 이전에 발생한 이벤트 시간을 기준으로 다음 이벤트 발생 시간을 정하는 주기의 경우에는 OnCalendar를 사용할 수 없습니다. 그래서 이런 경우에는 OnUnitActiveSec= 을 사용합니다.

# 단위는 초 입니다. 
60    : 60초 마다 
3600  : 1시간 마다 

# 단위를 변경하려면 접미사(suffix)를 붙여 명시적으로 정의하야 합니다. 
us,          : 마이크로 초 
ms           : 밀리 초 
s            : 초 (생략 가능) 
m, min       : 분 
h, hr, hours : 시간 
d, days      : 일 
w, weeks     : 주
M, months    : 월 
y, years     : 년

다음은 예시입니다.

# 접미사(suffix)를 사용할 때는 숫자와 띄어쓰면 안됨.

10       : 10초마다 
2h       : 2시간 마다 (3600초 경과)
30min    : 30분 마다 
4weeks   : 4주 마다 
10min25s : 10분 25초마다. (띄어쓰면 안됨!)

다음은 OnBootSec= 에 대해 알아봅니다. 이것은 꼭 정의를 해야 하는 것은 아닙니다. 옵션 사항이죠. 로그인을 한 후에 첫 번째 이벤트 실행을 정의하는 것으로 해석하면 됩니다. OnBootSec=1m 하면, "로그인한 후 1분 후에 첫 번째 실행" 이라는 의미가 됩니다. OnCalendar 를 사용한다면 굳이 정의할 필요가 없겠죠. OnUnitActiveSec 을 사용하는 경우라도 systemd의 timer 서비스가 시작되면 그 시각을 기준으로 첫 번째 이벤트 발생 시각을 결정하므로 굳이 필요하지 않습니다. OnBootSec 이 필요한 경우라면, "주기적인 발생 시점과 첫 번째 발생 시점을 다르게 하고 싶을 때"가 되겠죠.

다음으로 Persistent=true 에 대해 알아봅니다. 이것은 다음번 발생시각이 결정되고 다음 발생 시점을 대기하고 있는 과정에서 시스템이 중지되고 그 시간이 지났을 때에 어떻게 대처할 것이냐에 대한 정의입니다. 10분마다 이벤트를 발생하라고 설정을 해서, 첫 번째 이벤트가 발생하고 나면, timer는 다음 발생 시각을 계산해 놓습니다. 뭐.. 10분 후 이겠죠.. 그런데, 만일 사용자가 컴퓨터를 끄거나 혹은 정전이 되거나 해서 해당 이벤트 시각이 지나버렸을 경우, 다시 시스템이 부팅되거나 정상이 되었을 때 Persistent가 true 였다면 즉시 해당 이벤트를 실행하고 그 실행 시점을 기준으로 다음번 이벤트 시각을 정합니다. 내가 수행할 이벤트가 그런 성격의 것이라면 Persistent를 true로 하고, 꼭 그럴 필요는 없다면 생략해도 무방 합니다. 기본 값은 false 입니다.

여기서 주의할 점은 Persistent = true 로 했을 경우, 놓친 이벤트들을 정상화되었을 때 모조리 다 수행한다는 것입니다. 예를 들어, 1시간마다 이벤트를 실행하라고 했는데, 정전이 되고 5시간이 경과했다면, 시스템이 정상화되었을 때 놓친 5번을 순차적으로 즉시 반복 실행 합니다. 저녁까지 컴퓨터를 사용하고 잠자기 위해 저녁 10시에 컴퓨터 끄고 난 후, 다음날 저녁 10시에 컴퓨터 켜면 24번을 즉시 실행합니다. ^^

자~, 이제 마지막 섹션인 [Install] 부분입니다.

[Install] 은 해당 유닛 활성화와 관련된 것으로 시스템이 부팅되고 systemd 서비스가 개시되었을 때 해당 unit을 자동으로 실행하게 하려면 [install] 섹션을 정의해야 합니다.

예제를 보면 WantedBy= 가 명시되어 있는데, 이는 .target 유닛에 의해 원해진다(wanted)는 것을 의미합니다. 추후에 해당 unit에 대해 유저가 enable 혹은 disable 명령을 내릴 경우 해당 target 폴더에 내 unit의 symbolic 링크가 생성되게 됩니다.

예제에서는 WantedBy=timers.target 으로 정의했는데, timers.target은 시스템의 타이머 유닛을 관리하는 특수 타깃(Special Target)입니다 타이머 유닛을 시작하려면 반드시 이 target으로 정의를 해 주어야 합니다.

이 경우, 나 자신이 어떤 오류로 정상적으로 동작을 하지 않더라도 timer는 정상적으로 계속 진행되게 됩니다. 나만 동작을 안 할 뿐...

예제에서는 다루지 않았지만, WantedBy= 와 유사한 RequiredBy= 가 있습니다. 이 또한 WentedBy 와 기능은 같지만 의존성이 다릅니다. 말 그대로 target 이 해당 unit을 필요로 한다(Required)는 의미기 때문에 만일 어떠한 이유로든 내 Unit이 동작을 안 하거나 문제가 생기면 timers.target이 그 영향을 받고 , timers.target에 연결된 다른 유닛들도 영향을 받을 수 있습니다. 이건 그냥 참고로 알면 될 듯.

check_dnf_update.service 분석

자 이제, timer 유닛은 살펴봤고, 다음으로 service 유닛을 보겠습니다.

# check_dnf_update.service 

[Unit]
Description=dnf 업데이트 체크
After=network.target

[Service]
Type=oneshot
ExecStart=/home/elsa/.config/kwc/script/check-dnf-update.sh

# Wayland 환경에서 notify-send가 동작하기 위한 환경 변수
Environment=WAYLAND_DISPLAY=wayland-0
Environment=XDG_RUNTIME_DIR=/run/user/1000
Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus

타이머 유닛은 사용자가 정의한 주기에 서비스 유닛을 호출하는 역할을 수행합니다. Timer 유닛에서 그냥 실행할 action을 명시하면 되는 거 아니냐 할 수도 있겠지만, systemd 디자인 철학이 그러하지 않습니다. systemd 는 유닛들을 기능별로 명확하게 분리하여 설계를 해 놓았기 때문에, 자신의 역할에 따라 정의를 해 줘야 합니다. 이렇게 한 이유는 재사용성을 높이고 로깅 및 상태관리의 모호성을 줄이기 위한 것 입니다.

After= 지시어는 systemd 에게 해당 유닛이 어느 시점에 시작되어야 함을 알려주기 위한 것으로 dnf의 업데이트 정보를 확인하려면 무엇보다 네트워크가 사용가능한 상태이야야 하기 때문에 예시에서 처럼 network.target을 명시한 것입니다. 다만, 이것이 "반드시..." 라는 의미는 아닙니다. 즉, 종속성을 의미하지는 않는다는 의미입니다. network.target으로 networks가 활성화되든 말든 활성화되지 않았다고 내 할 일 하지 않겠다는 의미는 아닙니다. 다만, network.target이 나보다는 먼저 실행되어야 한다는 우선순위를 알려 주기 위한 것입니다. 보다 현실적으로 말하면, network.target 폴더에 등록된 service 유닛들을 systemd가 실행하지 않는 것입니다.

만일 종속성이 강조되어야 한다면, After 말고 Requires= 를 사용하면 됩니다. 이는 내가 시작되기 위해서는 반드시 다른 어떤 유닛이 실행된 상태여야 한다는 조건을 붙이는 것입니다. 따라서, 이 경우라면 해당 유닛이 시작에 실패하면 나도 실패하게 됩니다.

하지만, 실질적으로는 network가 준비가 되지 않으면, action을 하지 않습니다. 이유는 network.target이 network가 ready가 되어야 만 활성화되기 때문입니다. 즉, 네트워크가 사용가능 한 상태가 되기 전에는 after의 의미가 없기에 해당 서비스는 진행하지 않고 지연됩니다. 바꿔 말해 대기 상태에 있게 됩니다.

또 한 가지, service 유닛에는 timer 유닛에서와 같은 Persistent 지시어가 없습니다. Persistent는 timer 유닛에만 존재하는 지시어입니다. sevvice 입장에서는 network.target이 활성화 여부는 "네트워크가 아직 준비되지 않았다"는 정상상태의 범주에 있는 것이고, timer의 Persistent는 timer의 비정상여부에 대한 것만 관여하므로 service의 정상여부는 아무런 영향이 없습니다.

결론적으로 네트워크가 아직 준비가 안되었다면 대기, 준비가 되면 그때부터 서비스 시작.. 이렇게 되는 것입니다.

자, 이제 [Service] 섹션을 봅니다.

Type= 지시어에 oneshot이라고 정의되어 있습니다. Type= 은 서비스의 시작 방법에 관한 것입니다. oneshot은 구동 방식 중 하나로 ExecStart= 지시어에 지정된 명령이나 스크립트가 메인 프로세스라는 것을 systemd에게 알려 줍니다. 해당 명령이나 스크립트가 실행 되면 activating 상태로 전환하며, 실행이 종료되면 active가 되고, 특별한 옵션설정이 없는 한 즉시 inactive로 전환합니다. 즉, 단발성 서비스의 경우 정상적으로 실행되는 자체가 중요하며 실행이 정상적으로 완료되면 성공적으로 잘 처리했다는 의미로 active가 되지만, 결국 한 번만 실행되고 프로세스가 없어져야 하므로 즉시, inactive로 전환합니다.

반면, simpe typle 이 있는데, simple은 실행되면 계속 실행을 유지하는 프로세스에 적당합니다. 주로 백그라운드로 계속 실행되는 daemon 등이 이에 속한다고 할 수 있습니다. 따라서, simple은 실행되면 active가 되고, 종료되면 inactive 상태가 됩니다.

systemd는 ExecStart=에 명시된 프로세스가 시작(folked)되는 순간부터 해당 프로세스를 직접 추적 관리 합니다. 즉, running, stopped, failed 등 프로세스의 현재 상태, 프로세스 ID(PID), CPU/Memory 사용량, 로그등을 실시간 관리하며, 서비스가 예기치 않게 종료된 경우 설정에 따라 특정 조건에서 자동으로 재시작되도록 관리합니다.

ExecStart= 지시어는 말 그대로 실행할 대상입니다. 반드시 full path(절대 경로)로 정의해야 하며, 실행 권환이 잘 설정되어 있어야겠지요. 스크립트라면 첫 줄에 #!/bin.bash, #!/bin/python 등과 같은 shebang(서뱅)이 있어야 하며 없다면, python이나 lua 같은 스크립트를 실행할 때 /usr/bin/lua <lua script full path> 나 /usr/bin/python <python script full path> 처럼 해 줘야 합니다.

만일 명령어나 스크립트를 실행할 때 공백이 포함된 인자(argument)를 부여해야 한다면 "(따움표) 를 사용하여 인자가 어디서부터 이디까지인지를 확실하게 정의해야 합니다.

service 유닛은 제한된 환경 변수 세트에서 실행이 되기 때문에, 필요한 환경 변수가 있다면 넣어 줘야 합니다. 위의 예에서 도 notify-send 를 사용하기 위한 환경 변수를 지정한 것을 확인하실 수 있을 것입니다.

timer 등록 및 실행

자 이제 코드 분석을 알아봤고, 이제 이렇게 만들어진 것을 어떻게 등록하고 활성화하는지를 마지막으로 알아봅니다.

서두에 언급했듯이 user 영역에서 실행할 것이므로 ~/.config/systemd/user 폴더에 넣어야 합니다. 넣었다면 아래의 명령을 통해 enable 및 서비스 개시를 해 줍니다.

가장 먼저 할 것은 systemd에게 새로운 서비스가 있고, 이것을 내부 케시에 등록시키기 위한 작업으로 아래와 같이 daemon-reload를 명령해 줘야 합니다.

systemctl --user daemon-reload

systemd는 이 명령을 받아 user 레벨 시스템 서비스에 새로운 변화가 있다는 것을 알고, 새로운 유닛파일들을 검사하고 유효성을 판단하며 내부 케시에 등록을 합니다.

만일, 등록 이후에 .timer나 .service 파일을 수정하거나 삭제했다면 그때마다 이 명령으로 내려 줘야 합니다.

다음으로 할 것은 timer 유닛을 활성화 (enable) 시키는 것입니다.

systemctl --user enable check_dnf_update.timer

이 명령을 내리면 systemd는 ~/.config/systemd/user/timers.target.wants 폴더 내에 symbolic link(symlink)를 생성하게 됩니다.

마지막으로 timer 유닛을 실행해 줍니다.

systemctl --user start check_dnf_update.timer

이 명령을 통해 timer는 내부 지시어들에 정의된 바에 따라 timer를 즉시 활성화 하게 타이머를 작동하게 되며 서비스 유닛을 트리거할 준비를 하게 됩니다.

이 3단계에 대한 로그는 다음과 같습니다.

장상적으로 실행이 되었는지 해당 timer의 상태를 확인하려면 다음과 같이 명령하면 됩니다.

systemctl --user status check_dnf_update.timer

스샷을 보면, loaded 위치, active 상태, trigger 시각, tirigger 대상을 확인할 수 있습니다. 8분 남았다고 나와 있네요..

자 이렇게 해서 login 이 되고 나면 10분마다 dnf package manager의 새로운 업데이트 package 여부를 확인할 수 있는 timer 서비스를 성공적으로 완료했습니다. 특별한 일이 없는 이상 해당 서비스는 부팅이 되면 systemd에 의해서 자동으로 개시될 것입니다.

끝으로 실제로 dnf update 를 체크하는 shell script 소스코드를 보도록 하겠습니다.

#!/bin/bash

notify-send  -i /usr/share/icons/gnome/256x256/emotes/face-smile.png "dnf" "update를 확인합니다."

# dnf 명령어를 사용하여 업데이트 가능한 패키지 수를 체크합니다.
update_count=$(sudo dnf check-update --quiet | awk '{print NR}' | tail -n +2 | wc -l | awk '{$1=$1};1')

# update_count를 정수로 변환합니다.
update_count=$(echo "$update_count" | tr -d '[:space:]')
echo "${update_count}"

# 이전 값 파일 경로
update_count_file="/tmp/eww/update_count"
# 파일이 없으면 생성하고 초기값 0 설정
if [[ ! -f "$update_count_file" ]]; then
  mkdir -p "$(dirname "$update_count_file")" # 디렉터리 생성
  echo "0" > "$update_count_file"
fi

# 이전 값 읽기
previous_count=$(cat "$update_count_file")


# 값이 변경되었을 때만 사운드 재생
if [[ "$update_count" -ne "$previous_count" && "$update_count" -gt 0 ]]; then
  # 현재 값 저장
  echo "$update_count" > "$update_count_file"

  pw-play /home/elsa/.config/assets/incomming.mp3

  # 알림 표시
  # -t critical은 사용자가 클릭을 할 때까지 사라지니 않음
  # -i : icon 출력
  notify-send -u critical -i /usr/share/icons/gnome/256x256/apps/system-software-update.png "업데이트 알림" "${update_count}개의 패키지가 업데이트 가능합니다."
fi

이 코드가 실행되면, 우선 notification center로 "dnf update를 학인합니다" 라는 메시지를 전송합니다.

그리고, dnf 명령을 이용하여 실제로 새롭게 올라온 업데이트 패키지가 있는지를 검사합니다. 만일 새로운 패키지가 있다면 해당 항목이 몇 개인지를 출력합니다. 이 장보를 받아 /tmp/eww/update.count 파일에 기록합니다.

이유는 10분마다 주기적으로 검사를 하기 때문에 값을 저장하고 비교하지 않으면 매 10분마다 새로운 패키지가 있다고 메시지가 울릴 것 이기 때문입니다.

기록된 업데이트 개수와 방금 검사한 업데이트 개수를 비교하여 이전과 다르거나 0 이 아니라면 다시 notification center로 critical 메시지로 몇 개의 업데이트가 올라왔다고 메시지를 보내 줍니다.

일반 notification message와 critical message의 차이는 일반 메시지는 5초 후에 자동으로 사라지지만, critical 메시지는 사용자가 메시지를 마우스로 클릭하지 않는 한 화면에서 사라지지 않습니다.

그러면서 동시에 pw-play 명령을 이용하여, incoming.mp3 사운드 파일을 play 하여 청각적으로도 통지를 하게 합니다.

끝으로, systemd의 timer 유닛 목록과 관련된 정보를 한눈에 확인하려먼, systemctl --user list-timers --all 명령을 내리면 됩니다.

유용한 terminal CLI 도구들 (2025.07) #1

elsa in mac — Tue, 15 Jul 2025 22:50:12 +0900

2025.07월
Terminal 에서 사용할 수 있는 유용한 CLI Tool를 소개합니다. 포스트 제목에 #1 이 붙었다는 것은 소개할 것들이 좀 더 남았다는 것이니, 7월 말에 또 보자구요.

타자연습 - smassh

첫 번째 CLI 도구는 Terminal에서 타자 연습을 할 수 있는 smassh 입니다.

PYthon으로 작성된 도구로 terminal 기반이지만, mouse를 지원하고 군더더기 없이 깔끔하고 예쁜 화면을 보여 줍니다.

smassh 실행 화면

설치는

# 설치 
pip install smassh

# 실행 
smassh

종료는 ctrl-c ..

원하는 도시의 날씨를 확인하자 - yr

현시각 날씨 정보를 표시

yr는 특별한 설정 없이 설치 후 곧바로 사용할 수 있는 날씨확인 CLI도구입니다.
go언어로 적성되었기에 go로 빌드해서 사용하면 됩니다. 설치는 다음과 같습니다. macOS의 경우에는 brew로 빌드 없이 사용할 수 있습니다.

# macOS
brew tap timharek/top
brew install yr


# linux 
go install git.sr.ht/~timharek/yr/cmd/yr@latest

옵션으로는 now(현재 날씨), forecast(1시간 단위 10일간의 예상), today(현재 시각부터 1시간 단위), tomorrow(1시간 단위 내일 날씨) 등을 사용할 수 있습니다.

오늘의 날씨

S/W 프로젝트 Code Counter - scc

다음으로 소개할 CLI 도구는 S/W 개발에 도움이 될 만한 도구입니다. 프로그램을 작성하다 보면, 프로젝트의 구성파일이 어떤 언어로 구성되어 있고, 각 언어별 코드 라인수가 궁금할 때가 있습니다. 그리고, 대략 개발비용을 추산해야 할 경우도 있죠. 전통적으로는 cloc 나, tokei 같은 CLI 도구들을 많이 사용하는데, 이번에 소개해 드릴 scc는 보다 직관적이고 사용이 간단하며 종합적으로 확인할 수 있는 도구입니다.

scc 실행 예

위의 스샷만 봐도 직관적으로 무엇인지 딱 알 수 있습니다. 지금 개발하고 있는 프로젝트의 소스코드를 대상으로 돌려 본 건데, 개발비 가치가 60만 불, 개발 소요기간은 11개월, 개발인원은 4.7명 정도에 해당한다고 (ㅋㅋㅋ.오...). 그렇군요.. 실제로는 1인 개발이고, 2달 정도인데, 말이죠.. 일단 응답 속도가 매우 빠릅니다. 위의 스샷을 보면 알겠지만, 거의 100개가 넘는 파일을 분석하는데 명령을 내리자 거의 즉각적으로 결과가 나오네요.

설치 방법 및 다양한 옵션과 usecase를 github에 가면 홈페이지에서 확인하실 수 있습니다. 굉장히 전문적인 지식 베이스로 만들어진 CLI 도구입니다.

자주쓰는 명령어를 alias로 쉽게 말들자 - alman

다음 소개할 CLI도구는 alias를 쉽게 만들고 관리할 수 있는 alman(Intelligent Alias Manager)이라는 도구로 linux 및 macOS를 지원합니다.

terminal에서 명령어들을 사용하게 되면, history에 누적이 되게 되는데, alman은 history 혹은 사용자가 내린 명령라인을 추적, 통계를 통해 자주 사용하게 되는 명령라인을 sorting 합니다. 그리고, 사용자가 자주 사용하는 명령라인을 alias로 쉽게 만들 수 있도록 도와줍니다.

설치 방법은 Relase에서 다운로드하거나, cargo로 직접 빌드하여 사용할 수 있습니다. 빌드 방법은 다음과 같습니다.

# git clone 
https://github.com/vaibhav-mattoo/alman.git

# cd 
cd alman 

# build 
cargo build --release 

# binalry..
cd target/release

다운로드 받은 혹은 빌드한 binary를 path directory로 복사한 후, shell configuration을 해 줘야 합니다.

# Bash 사용자 , ~/.bashrc 파일에 추가 
eval "$(alman init bash)"

# reload configuration 
source ~/.bashrc 



# Zsh 사용자 , ~/.zshrc 파일에 추가
eval "$(alman init zsh)"

# reload configuration 
source ~/.zshrc 



# Fish 사용자, ~/.config/fish/config.fish 파일에 추가 
alman init fish | source

# reload configuration 
source ~/.config/fish/config.fish

처음 alman이 실행되게 되면 우선적으로 history의 정보를 참조하여초기화를 진행한 후, 이후부터는 사용자가 terminal에서 사용하는 명령라인을 인식하고 통계에 활용하게 됩니다.

보통 alias를 사용하는 이유는 복잡하고 긴 줄의 명령라인을 외우기에 어렵고 시간이 지나면 사용법을 몰라 다시 확인하는 번거로움이 있다 보니, 자주 사용하지 않더라도 중요한 명령라인의 경우 alias로 정의해 놓는 경우가 있습니다. 그러려면 일반적으로는 사용하는 shell의 설정파일을 에디터로 열고, alias를 직접 추가하거나 수정한 후, 다시 reload를 해야 하지요.

alman을 사용하면 매우 직관적으로 alias를 관리할 수 있습니다.
아래는 예 인데요, 필자의 경우에는 ghostty를 직접 빌드해서 사용을 하게 되며, ghostty를 빌드하기 위해서는 꽤나 길고 복잡한 명령라인을 사용해야 합니다.

# ghostty build command 
 ../zig build -p ~/.local -Doptimize=ReleaseFast -Dgtk-wayland=true -Dgtk-x11=false  -Dcpu=apple_m1 -Dtarget=native -Dstrip=true
 
 # alman을 이용해서 alias 추가 
 # gb 로 alias
 alman add -c "../zig build -p ~/.local -Doptimize=ReleaseFast -Dgtk-wayland=true -Dgtk-x11=false  -Dcpu=apple_m1 -Dtarget=native -Dstrip=true" gb
 
 # alias 확인 
 alman list 
 
 # 해당 alias 삭제 
 alman remove gb

아래는 위의 예에 대한 실제 스삿입니다.

추가, 삭제, 수정한 후에는 shell confoiguration을 reload 해 줘야 합니다. 그럼 즉시 해당 alias를 바로 사용할 수 있습니다.

그 밖에 다양한 옵션과 use case들은 해당 github에서 확인하시면 됩니다.

alias를 지정할 때 고민되는 한 가지가 alias 이름을 정하는 것인데, alman에는 사용자가 추가한 alias에 대해 alias 이름을 추천 제안하는 기능이 있습니다.

alman을 실행하고, c(change alias)를 한 후, list에서 변경하고자 하는 alias를 선택하면 위의 스샷처럼 alias suggestion 항목이 나타나게 됩니다.

alias 목록 편집은 alman tui 로 실행한 후, 아래 스샷 처럼, l(소문자 L)키를 누른 후 편집하면 됩니다.

alman tui로 실행한 모습

alman의 alias 저장 파일은 alman --help를 하면, 위치를 확인할 수 있습니다.

alias를 관리하기 위해 shell profile 을 수정할 필요없이 alias를 별도로 관리할 수 있다는 점이 장점으로, 필자처럼 alias를 많이 사용하는 사용자에게는 매우 유용한 도구가 아닐 수 없습니다.

압축파일 관리를 쉽게 - ouch

다음 CLI 도구는 압축파일을 쉽게 관리할 수 있는 ouch 입니다. 압축파일 종류는 정말 굉장히 많지요.

예를 들어 어디서 압축파일을 받았는데, 확장자가 .sz 입니다. (이게 뭐여 ??) 혹은 확장자가 .tar.xz.gz 뭐 이런 거.. 당황스럽지요.. (이거 뭘로 압축을 풀어야 하는 거야?)

대부분 각 확장자에 따른 압축관리 도구들이 존재합니다. 그런데, 이 각각의 압축파일을 해제하기 위해 일일이 다 익혀야 하고, 옵션도 알아야 하기에 꽤나 번거롭습니다. 가끔 사용하는데 기억하기도 어렵지요.. 그래서 정말 간단하게 사용할 수 있는 압축파일 관리 도구가 절실한데 ouch가 바로 그럼 CLI 도구입니다.

ouch를 사용하면 어떤 압축파일이던 간단하게 해제하고. 또 원하는 형식으로 압축할 수 있습니다.

압축파일 화장자는, .tar, .tar.gz, .7z, .gz, .xz, .lzma, .bz, .bz2, .bz3, .lz4, .sz, .zst, .rar, .br 을 지원합니다.

사용법은 너무나 단순합니다. 확장자가 뭐든 관계없이 압축을 해제하고 싶으면, decompress, 압축을 하고 싶으면 compress 를 사용하면 됩니다.

예를 들어, test.tar.gz 을 압축 해제 한다면, ouch decompress test.tar.gz 하면 됩니다.

test 라는 폴더가 있을 때, 이 폴더를 압축파일로 만들고 싶다면 compress를 하면 됩니다. ouch compress test test-folder.zip

그냥 압축파일의 확장자를 지정만 해주면 해당 type으로 압축을 합니다. 이보다 더 쉽고 편리한 것이 있을까...

압축을 해제하지 않고, 내용만 확인하고 싶다면 list 옵션을 사용합니다. ouch list test.tar.gz , tree형태로 확인하고 싶다면, 끝에 --tree 만 붙여 주면 됩니다. ouch list test.zip --tree

단지, shared library를 사용하는 압축 형식이 있기 때문에 실행을 했을 때 오류가 발생한다면 오류에 해당하는 runtime dependencies를 설치해 주면 됩니다. liblzma, libbz2, libbz3, libz 정도로 본인이 사용하는 Linux 배포판의 표준 package manager로 install 주면 되겠죠.. 처음부터 할 필요는 없고 특정 압축파일을 해제할 때 오류가 나타난다면 그때 대응하시면 됩니다.

Linux, macOS(apple silicon, intel), Windows 모두 지원하며, Rust로 작성되어 있으니, 필요하면 소스코드를 다운로드 받은 후, cargo build --release 로 빌드하시면 됩니다.

bluetooth 헤드폰/이어폰 사용 시, CAVA 와의 latency를 없애는 방법

elsa in mac — Tue, 15 Jul 2025 01:25:49 +0900

터미널 기반의 Cross-Platfom Audio Visualizer인 CAVA를 사용하신다면 참고해 보시기 바랍니다.

이 방법은 Fedora Linux에서 확인한 방법입니다.

음악이나 방송을 play하고, cava를 실행하면 오디오 신호에 따라 정확하게 반응하는 cava를 확인할 수 있습니다. 하지만, 만약 출력이 Bluetooth 헤드폰/이어폰 등으로 되어 있다면, 실제 Bluetooth 기기에서 듣는 음악 혹은 방송과 cava 간에 약간의 시간차가 발생한다는 것을 느낄 수 있습니다. 이것은 Bluetooth 수신장치의 출력지연(latency) 때문에 cava 가 실제 사용자가 듣는 소리보다 살짝 빠르게 반응하는 것처럼 보이기 때문입니다.

이 둘간의 latency를 없앨 수 없을까?

bleutooth 장치의 출력지연을 줄일 수는 없으니, cava로 표시되는 시각적 반응을 반대로 latency를 늘려서 둘 간에 동기화를 시키는 방법밖에는 없습니다.

이번 포스트는 CAVA의 출력에 인위적인 지연을 추가하여 무선 헤드셋과 동기화를 맞추는 방법에 관한 것입니다.

우선, cava에는 출력을 지연시키는 delay 옵션이 없습니다. 따라서, cava의 입력을 bluetooth monitor pipe에서 직접 받지 않고, 중간에 input 단을 하나 만들고 이 input 단에서 일부러 delay를 줘서 cava에 전달하는 방식을 사용하면 됩니다.

필자의 경우에 cava의 설정에서 [input] 단은 다음과 같이 설정되어 있습니다.

# ~/.config/cava/config 

[input]
method = pulse
source = bluez_output.AC_12_2F_D5_33_A0.monitor

cava가 오디오 신호를 capture 하는 방식이 pulse 이고, source는 bluz_output의 연결된 bluetooth 기기의 monitor 라고 되어 있는 것이죠.

위의 설정을 일단 주석처리(; 사용)하고,아래와 같이 fifo로 변경을 합니다.

; ~/.config/cava/config 

[input]
; method = pulse
; source = bluez_output.AC_12_2F_D5_33_A0.monitor

method = fifo 
source = /home/elsa/.config/cava/delay_fifo  ; full path로 명시해야 함
sample_rate = 44100

그리고, 위의 설정대로 /home/elsa/.config/cava/ 폴더 에 delay_fifo 라는 FIFO를 생성해 줍니다. /home/elsa 는 Fedora Linux에서 사용자 계정의 HOME directiory를 의미합니다. 본인에 맞게 수정해야 합니다.

mkfifo /home/elsa/.config/cava/delay_fifo

잘 만들어졌는지 확인하려면, 아래와 같이 stat을 확인해 보면 됩니다.

> stat ./delay_fifo
  File: ./delay_fifo
  Size: 0               Blocks: 0          IO Block: 4096   fifo
Device: 0,41    Inode: 16606164    Links: 1
Access: (0644/prw-r--r--)  Uid: ( 1000/    elsa)   Gid: ( 1000/    elsa)
Context: unconfined_u:object_r:config_home_t:s0
Access: 2025-07-15 00:54:46.730353315 +0900
Modify: 2025-07-15 00:54:46.784353073 +0900
Change: 2025-07-15 00:54:46.784353073 +0900
 Birth: 2025-07-14 23:00:00.204542896 +0900

중요한 것은 Access 에 0644/prw-r--r-- 로 되어 있다는 점.

이제, pulse의 source(bluetooth 장치의 monitor)로 부터 받아서 이를 delay를 줘서 /home/elsa/.config/cava/delay_fifo에 쏴 주는 방법만 알면 됩니다. 그럼 cava는 해당 fifo를 읽어서 예전처럼 오디오 신호를 분석하고 그에 따라 반응을 하게 될 것입니다.

방법은 ffmpeg을 사용하는 것입니다. 따라서, ffmpeg가 설치되어 있어야 합니다.

 ffmpeg -f pulse -i bluez_output.AC_12_2F_D5_9C_A0.1.monitor -af "adelay=200|200" -f wav - > ~/.config/cava/delay_fifo

참고로, Bleutooth 모니터 소스 이름을 확인하려면, 터미널에서 아래와 같이 명령을 실행합니다.

> pactl list sources short

56      alsa_output.platform-sound.HiFi__Headphones__sink.monitor       PipeWire        s32le 2ch 96000Hz       SUSPENDED
57      alsa_input.platform-sound.HiFi__Headset__source PipeWire        s32le 1ch 96000Hz       SUSPENDED
63      audio_effect.mini-convolver.monitor     PipeWire        float32le 2ch 48000Hz   SUSPENDED
10405   easyeffects_sink.monitor        PipeWire        float32le 2ch 48000Hz   SUSPENDED
10406   easyeffects_source      PipeWire        float32le 2ch 48000Hz   SUSPENDED
10551   bluez_output.AC_12_2F_D5_9C_A0.1.monitor        PipeWire        float32le 2ch 96000Hz   SUSPENDED
10552   bluez_input.AC:12:2F:D5:9C:A0   PipeWire        float32le 1ch 96000Hz   SUSPENDED

6번째 줄에 bluz_output_AC....monitor 가 있는 것을 알 수 있습니다. 이 이름을 그대로 사용하면 됩니다.

ffmpeg... 명령을 내리고, 다른 터미널 창을 열고 cava를 실행하면 Bluetooth 헤드폰으로 들리는 소리와 cava가 얼추 동기화가 이뤄졌다는 것을 확인할 수 있을 것입니다. 그래도 cava와의 동기화가 잘 맞지 않는 것 같다면 , adelay=200|200 이 부분의 값을 변경하면서 확인하면 됩니다. 200|200은 각각 좌/우 채널의 지연 시간을 의미하는 것으로 단위는 ms 입니다.

실제 사용 시에는 ffmpeg 와 cava를 한꺼번에 실행하도록 하는 것이 편리하므로, 아래와 같은 shell script를 만들어 사용하면 편합니다.

# run-cava.sh 

#!/bin/bash

FIFO="$HOME/.config/cava/audio_delay_fifo"

[[ -p "$FIFO" ]] || mkfifo "$FIFO"

ffmpeg -v quiet -f pulse -i bluez_output.AC_12_2F_D5_9C_A0.1.monitor -af "adelay=200|200" -f wav - > ~/.config/cava/delay_fifo &
cava

이 shell-script를 실행하면, ffmpeg는 백그라운드로 실행이 되고, cava가 실행되게 됩니다. 이 스크립트에서 주목할 부분은 ffmpeg -v quiet 옵션이 추가되었다는 점입니다. ffmpeg가 실행되면 실시간 메시지들이 stderr로 끊임없이 출력되게 되는데, 이를 방지하기 위한 것입니다.

- - - -

그 동안, 무선 이어폰이나 헤드셋으로 음악 감상을 하면서, cava와의 latency 때문에 cava를 사용하기 꺼려 하셨다면 참고 하시기 바랍니다.

Linux에서 사용가능한 GPU 가속을 지원하는 깔끔한 사진 편집/관리 도구 - RapidRAW

elsa in mac — Mon, 14 Jul 2025 20:19:32 +0900

이번 포스트에서는 Linux에서 사용가능한 사진 편집 및 관리 도구인 Open Source 프로젝트 RapidRAW를 소개합니다.

2025년 7월 초에 Github에 새롭게 등록된 따끈따끈한 오픈 소스 프로젝트입니다. 개발자가 18살로 자신의 사진편집 workflow를 위해 프로젝트를 시작했다고 합니다.(존경 스럽네요) React와 Rust로 개발되었으며, 궁극적으로 Adobe Lightroom을 대치할 대체제로 키우고 싶다는 목표를 제시하고 있습니다. 프로젝트를 개설한 지 2주 만에 1,600개의 star로 높은 지지를 받고 있습니다.

rapidRAW 시작화면

30MB 수준의 매우 작은 패키지로 구성되어 있지만, Linux, macOS, Windows를 모두 지원하는 Cross-Platform 도구로 깔끔하면서도 모던하며 직관적인 UI가 인상적입니다.

폴더 내 이미지 목록 뷰

프로젝트의 목표가 빠른 처리 속도 뿐만 아니라, 디지털 이미지 처리 및 카메라 기술에 대한 세부적인 요소들을 배우는데 도움이 되는 도구를 만드는 것으로, 안정성과 성능을 위해 Rust 언어로 Core를 개발하고, UI Frontend는 가볍고 Cross-Plafom을 지원하기 위해 Tauri를 적용했으며, 이미지 처리 파이프라인은 WGPU 및 WGSL 세이더를 사용한다고 합니다.

서진 편집 화면

편집 항목은 exposure, contrast, hightlight, shadow, whites, black 등과 같은 기본 사항에, white balance, tint, vibrance, saturation, color mixer, sharpening, noise reduction 등을 지원하고, Effects에서는 Clarity, Dehaze, Structure, Vignette, Grain 등을 제공합니다. 그 밖에 Crop, Masking, 그리고 시대의 흐름에 맞게 AI Tools도 지원할 것으로 보입니다.

실행 및 설치 파일은 Github Relase 에서 받을 수 있으며, 거의 매일 업데이트 배포판이 등록되고 있습니다.

Linux의 경우, 패키지 이름이 ubuntu로 되어 있어서 마치 ubuntu만 지원하는 것처럼 착각을 하기 쉬운데, 확장자가 .rpm .deb .AppImage 등으로 되어 있으니, 사용하는 Linux 배포판에 따라 해당되는 패키지를 다운로드 받아 설치하면 됩니다. 프로세스는 arm64, aarch64, x86_64, x64용으로 배포합니다. macOS의 경우 aarch64가 Apple Silicon 용이고, x64는 Intel 용 입니다.

rapidRAW로 보정한 결과

- - - -

이제 막 시작한 프로젝트이고, 개발자가 해당 분야의 전문가가 아니기 때문에 성능 최적화나 기능 확장에 얼마나 높은 수준의 경쟁력을 갖추게 될지는 살짝 의문이지만, 집단 지성의 힘을 끌어낼 수있는 Open Source Project인 만큼 앞으로 미래가 기대대는 프로젝트라고 평가하고 싶습니다. 관심이 있으신 분들은 한번 사용해 보시기 바랍니다.

Zen Browser를 투명하게....

elsa in mac — Fri, 27 Jun 2025 20:02:42 +0900

이번 포스트에서는 Zen Browser에 투명 theme를 적용하는 방법을 정리해 봅니다.

아래의 일련의 과정은 Asahi Linux (Fedora) 환경에서 사용한 것 입니다. 만일, 다른 OS를 사용하신다면 이점을 감안하고 참고하시기 바랍니다.

우선, 위의 스샷은 투명이기는 하지만, 부가적으로 blur 효과가 적용된 것입니다. zen browser 자체에서는 blur 효과를 줄 수가 없고 투명하게만 만들 수 있습니다. blur 효과는 OS에 따라 Window Manager나 Compositor에서 window blur를 지원해야 합니다. 필자의 경우에는 필자가 자체 제작한 Wayland Compositor를 사용하고 있기 때문에 위와 같이 blur를 사용할 수 있습니다. macOS, windows11은 기본 지원하고, Linux에서는 Hyprland나 혹은 KDE 등을 사용한다면 blur 효과를 사용할 수 있을 것입니다. theme 제작자의 말에 의하면 windows 10이나, GNOME에서는 적용하지 않거나 적용하더라도 자연스럽지 못할 수 있다고 하니 이 점도 참고하시기 바랍니다.

웹 브라우저를 투명하게 사용하려면, 두 가지가 필요합니다. 첫 번째는 웹 브라우저 자체를 투명하게 만들어야 하고, 두 번째는 방문하는 사이트의 배경을 투명하게 만들어야 하겠지요. 그래서 이 두 가지를 적용할 수 있는 방법이 필요 합니다.

우선 해당 Zen Browser를 투명하게 만들 Mod를 설치하기 위해 전용 add-on market 인 Sine을 설치해야 합니다. Sine github 의 release에서 자신의 OS에 맞는 실행파일을 다운로드 합니다.

Sine 설정화면

필자의 경우에는 asahi linux를 사용하고 있고, aarch64(arm64) 이므로, sine-linux-arm64를 다운로드하였습니다.

다운로드 파일을 실행하기 위해서는 터미널에서 exucute mode set을 해줘야 합니다.

chmod +x sine-linux-arm64

sone-linux-arm64를 터미널에서 실행하면 아래와 같은 절차로 zen browser에 설치를 하게 됩니다.

1번에서는 사용할 Browser를 선택합니다. 2번 질문에서는 zen의 버전을 선택하는데, 필자의 경우에는 twilight 버전을 사용하고 있기 때문에 twilight를 선택했지만, 그렇지 않다면 beta를 선택하면 됩니다. 3번 질문에서는 zen의 실행파일이 위치한 절대경로를 지정해 줍니다. 4번 질문에서는 사용자 id를 넣어 주고, 5번에서는 현재 zen이 사용하는 profile를 선택해 줍니다.

현재 사용 중인 profile은 Zen browser의 주소창에 about:support를 넣은 후, 아래와 같이 Ctrl+F를 눌러 "profile"를 검색하여 찾을 수 있습니다. 혹은 화면을 아래로 내려 Application Basics 항목에 보면 Profile Directory 항목에서 찾을 수 있습니다.

프로파일까지 지정을 했다면, 설치 혹은 제거를 선택하는 질문으로 넘어 갑니다.

러제거를 원한다면 yes를 넣어 주고, 설치를 한다면 그냥 enter키를 치면 됩니다. 그럼, 위의 스샷처럼 필요한 요소들을 zen에 inject 즉, 설치하게 됩니다. 설치가 끝나고, Enter anything to exit: 에서 enter키를 눌러 설치 프로그램을 종료합니다.

이제, Zen을 실행하고, 설정으로 가면 아래와 같이 Sine Mods 항목이 새롭게 등록이 된것을 알 수 있습니다.

만일, 모든 작업을 수행했지만, Sine Mods 가 메뉴에 나타나지 않는다면, 디렉터리의 권한 문제가 있을 수 있습니다.

위의 스샷에서 보는 바와 같이 ~/.zen/<프로파일 디렉터리>/chrome 에 들어 갔을 때, 서브 디렉터리 및 파일들의 소유자(owner)와 그룹(group)이 자신의 계정이 아닌, root 로 되어 있는지 확인하고 만일 root로 되어 있다면, sudo chown 명령을 이용하여 자신의 계정으로 변경해야 합니다. (ex) sudo chown -R elsa:elsa *

여러 Mod들이 보이는데, 여기서는 Transparent Zen 이라는 Mod를 설치해야 합니다. 아직 market에 등록이 되어 있지 않으므로 sameerasw/zen-themes/tree/main/TransparentZen 를 넣고 옆에 Install 버튼을 눌러 줍니다. 그러면, Transparent Zen Mod가 설치되게 됩니다.

위의 스샷에서 처럼 설치된 Transparent Zen mod의 설정 버튼을 누르고, 아래와 같이 설정 합니다.

각 항목에 대한 자세한 설명은 여기서 하지 않겠습니다.

Linux라면, 첫번째(Allow transparency)와 두 번째 항목(Allow transparency on linux)은 반드시 설정을 해야 합니다.

그리고, 투명화가 되었을 때 홈페이지에 표시되는 글씨들이 배경에 묻혀 가독성이 떨어질 수 있기 때문에, Enable custom background color for zen을 활성화하고, Set Custom background color를 #00000080으로 설정합니다. 000000은 검정색을 의미하며 80은 투명도로 50% 정도의 반투명을 의미합니다. (값은 Hex로 00 ~ FF, 80은 중간값)

이제 마지막으로 about:support 에서 아래와 같이 Clear startup cache. 를 눌러 cache를 초기화한 후,

Zen Browser를 종료 후 다시 실행해 줍니다.

그러면, 아래와 같이 완전 투명 대신 살짝 어두운 배경의 투명화면이 되게 됩니다.

그리고, 여기에 해당 OS의 windows compositor가 blur효과를 지원한다면, 다음과 같이 보이게 됩니다.

zen browser는 투명하게 만들었지만, 홈페이지를 방문하면 각 홈페이지들미다 배경설정이 제각기 다르기 때문에 페이지들이 투명하게 보이지 않습니다.

Google 페이지

따라서, 로딩할 페이지를 투명하게 보이게 하기 위한 방법이 필요한데, 이를 위해서 Zen Internet이라는 Add-on 이 필요 합니다. Zen Internet은 이름에서 알 수 있듯이 Zen Browser에서 유명한 Site들에 대한 Styling을 적용하는 Extension으로 기본 옵션으로 Transparency(투명화), Dark Reader, No folder(?) 의 속성을 제어할 수 있습니다. 우리가 필요한 것은 Transparency 기능 이겠죠.

Zen browser에서 Download File를 클릭하고, 설치를 합니다.

설치 후, 투명하게 보고 싶다면, 아래와 같이 Zen internet Extension Icon을 누르고, 적용을 활성화시켜 주면 투명이 적용됩니다.

Skip Styling for this site가 활성화 되어 있다면 꺼준다.

그러면 아래와 같이 투명으로 변하게 됩니다.

해당 싸이트에 대한 설정은 한 번만 변경되면, 이 후로는 변경을 바꾸지 않는 한 영원히 투명모드로 보이게 됩니다.

- - - - -

꽤 근사하죠?
투명에 blur 효과는 꽤나 CPU/GPU/MEMORY를 많이 낭비하는 비싼 눈요기거리 이기는 합니다만, 자신이 사용하는 컴퓨터 Resource가 빵빵하다 싶다면.. 이쁜 Browser를 사용하는 것도 나쁘지 않다고 봅니다.

필자의 경우에는 8GB/256GB의 2020 M1 Mac Mini에서 macOS 대신 Asahi Linux를 시용하고 있기 때문에, Resource가 그리 넉넉한 편은 아닙니다. 그래서 주력은 역시 Chromium을 사용하고 있지만, 가끔 아무것도 안하고 인터넷 서핑을 하거나 할때는 이 이쁜 Zen Browser를 사용합니다.

유용한 terminal CLI 도구들 (2025.06)

elsa in mac — Tue, 24 Jun 2025 23:19:32 +0900

이번 포스트에서는 Linux, macOS, Windows 등의 terminal에서 유용하게 사용할 수 있는 3rd-party open source CLI 도구들을 소개합니다. 타이틀에 굳이 년/월을 표시한 이유는 해당 CLI도구들이 언제고 그 생명을 다할 수 있기 때문입니다. 대략적으로 언제 시점을 기준으로는 아직 쓸만한 도구들이라는 것을 파악하기 위함입니다.

연결된 USB 장치를 간단히 확인활 수 있는 cyme

첫 번째로 소개할 CLI 도구는 PC의 USB Bus와 해당 Bus에 연결된 USB 장치들의 목록을 확인할 수 있는 cyme이라는 도구입니다.

cyme 실행

cyme --tree --headings --hide-buses 실행 예

원래 Linux에서 lsusb를 하면, usb 장치들에 대한 상세한 정보를 확인할 수 있기는 하지만, 굳이 복잡하고 상세한 정보가 필요치 않고 단순히 어떤 장치들이 어떤 Bus에 연결되어 있고, 해당 장치의 속도가 어느 수준인지 정도만 확인이 필요하다면 꽤 만족스러운 도구일 수 있습니다.

위의 스샷을 보면, 일단 이쁘고 직관적이죠. 2개의 Host에 4개의 장치가 연결되어 있는 것을 알 수 있습니다. 두 개는 USB 3.0으로 연결되어 있으며 ATA/ATAPI 장치니까. SSD 같은 외장저정장치 임을 알 수 있습니다. 그리고, 그 아래로 USB 2.o HUB를 통해 Archon AK47 키보드와 마우스가 연결되어 있는 것이 확인됩니다.

이 도구는 Rust로 작성되어 있으며, Window, Linux, macOS를 모두 지원합니다. 물론, 각 OS 마다 표시되는 정보의 수준이 조금씩 상이할 수 있습니다. 실제로는 굉장히 많은 옵션을 갖추고 있는데.. 위와 같은 결과를 얻으려면.. 아래의 명령을 수행하면 됩니다.

cyme --tree --headings --hide-buses

저의 경우에는 usbtree라는 명칭으로 alias를 선언하여 사용합니다.

docker container의 상태를 확인할 수 있는 ctop

두번째로 소개하는 도구는 실-시간으로 docker container들의 상태를 확인할 수 있는 ctop 입니다. terminal 기반 CLI 중에는 굉장히 많은 top(top of the list 또는 table of process)들이 존재합니다. htop, btop, ntop...

ctop 실행 예

최근에는 docker의 명성이 예전만 못하지만, 여전히 container 기반의 가상환경 솔루션으로 여전히 많은 사용자들이 docker를 사용하고 있지요. docker를 관리하는 가장 대표적인 도구로 lazydocker가 있지만, CPU나 RAM I/O등의 실-시간 상태를 확인하고 싶다면 ctop이 간단하고 좋습니다. 2022년 중반쯤 업데이트 진행이 중지되었지만, 지금 받아서 사용해도 전혀 문제가 없습니다. 물론 Linux, macOS, Windows를 모두 지원합니다. ? 키를 누르면, 사용할 수 있는 command의 종류와 설명이 나오니 참고하면 됩니다.

TUI 기반의 시계 ClockTemp

세 번째로 소개할 도구는 terminal에서 사용할 수 있는 디지털시계인 ClockTemp 입니다. 이름에서 알 수 있듯이 시계와 사용자가 지장한 위치(위/경도)의 온도를 기본으로 표시해 주는 도구입니다.

clocktemp 실행 예

기능키인 w(시계), c(달력), s(스톱워치), t(타이머) 로 모드를 전환할 수 있습니다. python으로 작성되어 있으며, 소스코드를 다운로드하고, install.sh를 실행하여 설치하면 됩니다. install.sh를 사용하고 싶지 않다면 script 폴더 안에 있는 cal.py, clock.py, clocktemp.py temperature.py 등 4개의 python를 특정 폴더에 넣고. clocktemp.py를 실행하면 됩니다. alias나 shell-script를 사용하면 좋습니다.

clocktemp.py -tf 24 -df dd/mm -tu c -s true -lat 37.5665 -lon 126.9780 -c cyan -b default

# -tf  : time format - 12/24
# -df  : date format - dd/mm (2자리 일/월/년)
# -tu  : temperature unit - c(섭씨)/f(화씨)
# -s   : 초를 표시할 것인가(true/false)
# -lat : 위도 (서울)
# -lon : 경도 (서울)
# -c   : 글자색
# -b   : 배경색(default:투명)

자신이 위치한 곳의 위/경도는 chatGPT에게 물어보면 됩니다. ^^ Desktop Environment를 사용하는 분들이라면 DE에서 사용할 수 있는 Widget을 사용할 수 있지만, DE를 사용하지 않는 분들에겐 유용한 도구가 될 수 있습니다. 나름 갬성 시계라고 할까요?

github 활동 상태를 확인할 수 있는 activity

github나 gitea 등 git을 이용하여 프로젝트를 가동하는 사용자라면 유용한 간단한 도구입니다. 일 년을 기준으로 해당 프로젝트의 작업활동 상태를 간단히 확인할 수 있는 activity 입니다.

activity 실행 예

git 프로젝트의 활동 정보를 볼 수 있는 도구들은 상당히 많지만, 매우 간단하고 깔끔한 인터페이스가 좋습니다.

main.cpp 파일 하나만 배포하므로, 직접 빌드를 해서 사용하애 합니다. 저의 경우에는 소스코드를 좀 수정해서 한글화 해서 사용하고 있습니다. 빌드하는 방법은 아래와 같습니다.

# 빌드
g++ -o activity main.cpp

path에 빌드한 실행 파일을 복사한 후, git 소스코드 폴더에서 activity를 실행하기만 하면 됩니다. 녹색의 짙기는 5단계로 구분되며, 하루 동안에 몇 번의 commit을 했는가의 여부에 따라 활동 수준이 달라집니다. 밝은 녹색일수록 commit을 많이 한 것입니다.

disk cleanup 도구 wiper

다음은 간단하게 폴더의 구성항목들을 확인하고 필요한 경우 해당 폴더나 파일을 삭제할 수 있는 도구인 wiper 입니다.

wiper 실행 예

macOS 및 Windows 용은 release로 배포를 하는데, linux용은 없네요.. 별도로 build를 해야 합니다. 소스코드 git clone 한 후,

cargo build --release

빌드된 바이너리는 target/release 폴더에 있으니 bin 폴더로 복사한 후 사용하면 됩니다. 크기순으로 sorting 할 수 있는 것이 가장 큰 장점이라고 할 수 있습니다. 간단하고 쉽게 사용할 수 있어 좋습니다. 정렬은 s, 해당 파일이나 폴더를 삭제하려면 d키를 연속으로 두번 누루면 됩니다.