소프트웨어의 Emacs화

• AI 에이전트 덕분에 개인용 네이티브 앱을 몇 시간 안에 만들 수 있게 되면서, 소프트웨어가 Emacs식 맞춤 구성의 영역으로 이동하고 있음
• MDV.app은 macOS용 Markdown 뷰어로, 검색·SQLite FTS 색인·책갈피·목차·위치 기억을 몇 시간 만에 구현함
• Electron 앱이 각자 Chromium 사본을 들고 다니는 문제와 네이티브 UI 개발 난이도는 컸지만, Claude는 SwiftUI를 능숙하게 다룸
• Emacs 문화처럼 각자 불편을 해결하는 초특정 도구가 늘고, 완제품보다 아이디어·관찰·프롬프트의 가치가 커짐
• 에이전트 코딩은 사이드 프로젝트와 터미널 도구에 쓰기 좋은 UI를 붙이기 쉽게 만들며, 네이티브 UI 제작을 재미있는 일로 바꿔줌

Markdown 뷰어를 직접 만든 이유

• 소프트웨어 개발에서 Markdown은 LLM 이전부터 공용어처럼 쓰였고, 에이전트 이후 TUI 도구가 다시 늘면서 터미널에서 Markdown을 계속 스크롤해 읽는 경험이 더 견디기 어려워짐
• TUI Markdown 뷰어로는 Charm의 glow, Josh가 만든 Markless가 있고, Markless는 목차 탐색도 지원하지만 터미널은 대개 고정폭 글꼴이라 장시간 읽기에 피로함
• macOS에는 Obsidian, Typora, Bear 같은 그래픽 UI Markdown 편집기가 있고 읽기 좋지만, 모두 편집기라 .md 파일을 여는 순간 기존 편집 환경과 창 배치가 흔들림
• App Store의 Markdown 뷰어들은 처음에는 그럴듯해 보여도 실제로 쓰면 검색이 없거나, 인앱 구매가 있거나, 선택한 텍스트를 클립보드로 복사하지 못하는 문제가 드러남
• 2026년에는 적당한 뷰어를 계속 찾기보다, 원하는 Markdown 뷰어를 AI 에이전트로 생성할 수 있다는 판단으로 방향을 바꿈

Claude로 만든 MDV.app

• MDV.app은 App Store에서 찾은 전용 Markdown 뷰어보다 나은 수준까지 몇 시간 안에 만들어졌고, 실제 상호작용 시간은 약 30분이었음
• 오래된 MacBook에 Xcode와 git을 설정하고 Claude 환경을 잡았으며, Swift와 macOS 디자인 관련 도움을 찾아두는 사전 준비는 몇 주 전부터 진행돼 있었음
• MDV가 최고의 macOS 애플리케이션이거나 특별히 유능한 소프트웨어는 아니지만, 전용 macOS Markdown 뷰어로는 충분히 나은 편이고 생활 품질을 크게 개선함
• MDV의 주요 기능은 문서에서 텍스트 선택·복사, 고정 문자열 검색, 편집 가능한 기록의 모든 Markdown 파일에 대한 SQLite FTS 색인, 단축키 책갈피, 목차 탐색임
• 문서 사이를 오갈 때 위치를 기억하고 재시작 후에도 이어지며, 색상 테마와 읽기 좋은 타이포그래피를 제공해 .md 파일을 클릭하면 원하는 읽기 환경이 바로 열림

Electron의 한계와 네이티브 UI의 변화

• Signal 메시지가 올 때마다 화면이 깜빡이고, Signal 앱을 명시적으로 숨기기 전까지 멈추지 않아 미묘한 깜빡임이 편두통 직전까지 이어짐
• 이 현상은 Signal이 Electron 앱이기 때문이며, 겉보기에는 네이티브 macOS 앱 같지만 실제로는 Chromium 사본이 비밀 웹페이지를 렌더링하는 구조임
• 지난 10년 동안 나온 거의 모든 UI 앱이 각자 Chromium 사본을 들고 다니는 것처럼 보이며, Electron은 좋지는 않지만 충분히 괜찮은 선택지로 버텨왔음
• 진짜 네이티브 UI를 만드는 일은 역사적으로 어려웠고, 그 일을 맡길 보통 수준의 인력조차 찾기 어려웠으며, 유능한 macOS 네이티브 UI 개발자는 드물었음
• Claude는 보통 수준의 SwiftUI 개발자를 대체하는 정도를 넘어, 실제로 SwiftUI를 능숙하게 다루는 개발자로 여겨짐

Emacs 문화가 소프트웨어 전반으로 새어 나오는 방식

• MDV는 설치해서 쓰라고 권하는 완제품이라기보다, Emacs 사용자가 반짝이는 .emacs 설정을 보듯 아이디어를 훔쳐 더 나은 것을 만들 대상으로 보는 편이 맞음
• Emacs 문화에서는 오래 쓰는 사용자들이 elisp로 텍스트 편집에서 시작한 개인적 불편을 해결하는 애플리케이션을 만들고, 그 도구들은 텍스트 편집기가 해야 할 합리적 범위를 넘어 확장됨
• /r/emacs는 Product Hunt식 제품 홍보보다 보여주기 문화에 가깝고, 널리 쓰이는 elisp 패키지도 있지만 Magit을 제외하면 각자 더 반짝이는 버전으로 다시 만드는 경향이 큼
• Emacs 문화의 약점은 Magit을 제외한 패키지들이 대체로 못생기고 느리며, elisp를 오래 겪은 뒤에야 발견 가능한 나쁜 사용자 경험을 갖는다는 데 있었음
• AI 에이전트는 이 문화를 Emacs 밖으로 밀어냈고, 화면과 입력에 접근할 수 있으면 네이티브 UI를 안정적으로 만들 수 있게 되면서 네이티브 UI가 전문적으로 포장된 프로그램의 영역에서 개인 맞춤 구성의 영역으로 이동함

개인용 네이티브 도구의 가능성

• Emacsification된 소프트웨어는 대부분 만든 사람에게만 유용한 개인 소프트웨어이고, .emacs 안에 남은 낡은 elisp 프로그램들처럼 잊히는 도구가 많아질 것임
• 가끔은 이런 프로그램이 경계를 넘어 여러 사람이 설치할 만큼 유용해질 수 있지만, 그때도 가장 중요한 것은 배포된 산출물이나 소스 코드가 아닐 수 있음
• 에이전트가 SwiftUI 코드를 모두 작성했다면, 소스 코드를 자세히 읽는 것보다 “이런 것도 만들 수 있고 잘 작동한다”는 아이디어와 관찰이 더 중요해짐
• 이런 종류의 소프트웨어에서는 소스 코드보다 프롬프트가 더 가치 있을 수 있으며, 직접 소프트웨어를 굴려 만드는 데 익숙한 사람에게는 모든 것이 기술적으로뿐 아니라 실용적으로도 프로그래밍 가능해짐
• 에이전트로 만든 소프트웨어를 “빌드한다”고 부르기에는 들인 노력이 적어 보이고, 실제 감각은 갑자기 훨씬 더 설정 가능해진 플랫폼 위에서 구성(configuring) 하는 것에 가까움
• AI를 쓰는 개발자들은 몇 년 동안 쌓아둔 무작위 사이드 프로젝트를 마침내 끝내고 있음
• 이제 그런 초특정 도구들도 단지 완성되는 데 그치지 않고 쓰기 좋은 UI를 가질 수 있으며, 이는 Emacs의 어설픈 UI를 감수해야 한다는 기존 이유 일부를 약화함
• 터미널 앱을 훨씬 쉽게 개선할 수 있는 가능성이 커졌고, iostat나 여러 호스트에 걸친 iostat, bpftrace 같은 도구도 더 이해하기 쉬운 형태로 만들 수 있음
• Brendan Gregg가 bpftrace 터미널 시각화를 위해 감수해야 했던 복잡함은 이제 그대로 참을 필요가 없고, 실제로 직접 만든 예시도 있음
• 취약점 연구자로서 2026년 상반기의 에이전트 코딩 기반 익스플로잇 개발 발전은 흥미로웠지만, 대다수에게는 두려움이 따르는 변화였고, 네이티브 UI를 만드는 일이 재미있어졌다는 변화는 순수하게 좋은 소식에 가까움
• 자기 문제에 맞춘 지나치게 구체적인 도구를 만들고 잠시 즐긴 뒤 공유하거나, 더 낫게는 스크린샷과 사용한 프롬프트를 공유하길 권함