소프트웨어의 Emacs화

지금은 대부분 미리 패키징된 전문 소프트웨어가 된 영역들을, 이제는 nerd들이 다시 가져와도 된다고 봄: 팟캐스트 앱, 음악 감상 앱, 피드 리더, Bluesky 클라이언트, 노트 앱, 데스크톱 북마크/나중에 읽기 앱, 채팅과 메신저, 시간 추적기, 레시피 관리자 같은 것들임
Claude로 대체품보다 나은 결과를 충분히 얻을 수 있음. 최고이거나 세계적으로 경쟁력 있는 앱은 아니어도, 자기만의 특이한 작업 방식에 훨씬 더 잘 맞는 앱은 만들 수 있음
Music.app은 쓰기 괴로운데, Apple은 이미 핵심 기능을 오래전에 MusicKit으로 빼냈음. 이제 진짜 제품은 MusicKit인데 왜 아직 Music.app을 쓰고 있는지 모르겠고, 이건 새로운 변화임

공통점은 데이터를 내가 소유하거나 최소한 접근 가능해야 한다는 것임. 회사들은 콘텐츠를 소유하고 접근 방식을 통제하는 폐쇄 정원을 만들기 좋아해서, 이런 개인화된 인터페이스를 불가능하게 만듦. 이제는 더 밀어붙여 되돌릴 수 있기를 바람

드럼 연습용 트랙을 듣기 위해 일회성 Android 음악 플레이어를 만들었음. 처음으로 자주 되돌아가야 하고, 속도를 낮춰야 하고, 선생님이 WhatsApp으로 보내준 파일을 열어야 하며, 최근 재생한 4~5개에 쉽게 접근해야 했기 때문임
F-Droid에는 이 조건을 모두 만족하는 앱이 없어서 그냥 APK를 직접 만들었음

LLM 시대 덕분에 소프트웨어 생산이 너무 쉬워져서, 모든 것이 .emacs 파일처럼 됐다고 봄. 즉 각 개인이 완전히 개인적이고 끝없이 커스터마이즈 가능한 소프트웨어 고치를 갖게 됨
OP의 표현처럼 기존 것을 설치하거나 배우는 것보다 자기 솔루션을 만드는 게 더 쉬워졌음
Lisp도 좋은 비유임. Lisp 매크로에 대한 오래된 비판은 모든 프로그래머가 자기만의 사적 언어로 바꿔버려서 남이 읽을 수 없게 된다는 것이었음
Mark Tarver의 2007년 글 "The Bipolar Lisp Programmer"도 떠오름: https://hn.algolia.com/?query=comments%3E0%20The%20Bipolar%20Lisp%20Programmer&type=story&dateRange=all&sort=byDate&storyText=none&prefix
그는 "brilliant bipolar mind"를 말했는데, 요즘 아이러니하게든 진지하게든 자주 나오는 AI psychosis와도 흥미롭게 맞닿아 있음
Tarver의 글 https://www.marktarver.com/bipolar.html에는 Lisp 커뮤니티의 "throw-away design"이 BBM에 딱 맞는다고 나옴. Lisp는 뭔가를 너무 쉽게 던져 만들 수 있어서, 각자가 자기 솔루션을 만들고 그게 자기에게 돌아가면 충분하다고 여김
반면 C/C++에서는 뭔가 의미 있는 것을 만들기가 너무 어려워 성취가 되고, 문서화하고 협업할 동기가 생김. 고용주 입장에서는 소통하고 문서화하며 함께 일하는 10명이, 대체하기 어려운 Lisp 해커 1명보다 매력적임
생산이 쉬워지면 소비가 병목이 되고, 공유가 어려워짐. .emacs 파일은 지문처럼 개인적이어서 조각을 가져올 수는 있어도 남의 것을 통째로 쓰고 싶지는 않음
이런 고치가 더 커스터마이즈될수록 남이 이해하거나 쓰고 싶어 하기가 더 어려워짐. 인지 비용도 크지만, 남의 옷을 입는 것처럼 불편함. 이것을 AI psychosis라기보다는 AI 유아론이라고 부를 수 있을 듯함
소프트웨어에서는 설정 관리가 어려운 부분이 되고 있음. 소스를 어떻게 공유하고 버전 관리할까? 소스가 무엇인가? 프롬프트인가? OP도 끝에서 코드보다 스크린샷과 프롬프트를 공유하자는 쪽으로 감
Show HN에도 생성된 코드가 더 이상 소스가 아니니 프롬프트를 공유하자는 시험 풍선을 띄웠지만, 아는 사람들에게 많은 반발을 받았음: https://news.ycombinator.com/item?id=47213630
GitHub가 받는 압력도 이런 흐름 때문일 수밖에 없음. 후계자가 어떤 모습일지는 불분명하지만 결국 필요해질 것임. 아직은 말 없는 마차 단계처럼 보임
더 중요한 건 팀워크임. 모두가 BBM이거나, 우리 각자가 자기만을 위해 24시간 생성하는 광적인 BBM 군단을 갖게 된다면 어떻게 함께 일할까? 고치끼리는 어떻게 소통하고 상호 운용될까? AI 유아론자들의 팀은 모순처럼 들림
AI 주도·에이전트식 개발의 최전선에 있는 팀과 스타트업들이 지금 이 문제를 실제로 겪고 있을 것임. 내 생성 코드와 네 생성 코드를 어떻게 합성하느냐 같은 문제임. 이런 마찰 때문에 생성 코드의 생산성 이득 일부는 다시 반납하게 될 가능성이 큼
아직 공개적으로 이런 얘기를 많이 하지 않는 게 아쉬움. 모두가 의무적인 기립박수 중 먼저 앉고 싶어 하지 않지만, 단점 없는 공짜 점심인 척하면 논의가 지루해지고 진화도 느려짐
새 도구로 가장 진지하고 앞선 작업을 하는 사람들이 단점을 말하지 않으면, AI가 소프트웨어 개발에 가치가 없다고 보는 냉소적인 쪽에만 단점 이야기가 남게 됨. 인류 멸망보다 버그 수 증가나 생산성 정체를 말하는 게 더 어려운 분위기임
실제로 무슨 일이 벌어지고 있는지, 사람들이 어떻게 대응하는지, 시간이 지나며 어떻게 변하는지 알고 싶음. 밋업 같은 데 가야 하나 싶음
관련 논문 제목도 "Easier to Write, Harder to Read"였음: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6726702

이 상황은 LLM 생성 산문 문제와도 운이 맞음. GPT 5.5가 형편없는 글을 쓰는 건 아니지만, 그 글이 GPT 5.5가 쓴 것임을 알아차리는 순간 뇌가 "그냥 내가 GPT 5.5에 직접 물어보면 더 나한테 맞는 답을 얻을 수 있잖아" 모드로 전환됨
왜 LLM과의 특정 대화 산물을 읽고 있어야 하나? 대화 주제만 알면 내가 더 나은 대화를 하면 됨
이런 소프트웨어도 비슷함. 약간의 취향은 있겠지만, 대부분은 아이디어와 레시피가 중요함
월간 "Vibe HN" 스레드를 만들면 좋겠음

"기존 것을 설치하거나 배우는 것보다 자기 솔루션을 만드는 게 더 쉽다"는 말은 과해 보임. WhatsApp은 수십 초면 설치할 수 있고, 이 댓글 쓰는 데 그보다 더 오래 걸렸을 것임
그보다 짧은 시간에 맞춤 WhatsApp을 만드는 영상을 공유할 수 있는지 궁금함. 즉석에서 만든 메신저로 다른 사람들을 끌어들이는 문제는 시작도 안 했는데 말임

팀워크가 어떻게 되느냐는 방향에 동의함. 예전에는 팀에서 페어 프로그래밍과 그룹 프로그래밍을 했고 "Zoom office"도 있었음
이제는 "이 티켓을 Claude에 넣어볼게, 너는 Copilot으로 해보고 결과를 비교하자"거나 "내 투박한 결과로 PR을 만들 테니 너는 네 도구로 리뷰해"가 됐음. 솔직히 거의 무의미하게 느껴지고 페어 프로그래밍은 완전히 죽었음
여러 에이전트를 돌리고, 서로 다른 작업 트리에서 문제를 고치고, agents.md의 불일치를 고치는 모습을 누가 보고 싶겠나
스스로 운영되는 완전 자율 클라우드 파이프라인을 만들자고 밀고 있는데, 경영진은 조용히 눌러두려는 것 같음. 그게 실제로 날 수 있다는 게 증명되는 순간, 몇몇은 편한 자리를 잃을 게 분명하다는 단순한 이해가 있는 듯함

팀워크의 한 예로 프로그래머와 연구자들이 함께 UNIX SYSTEM을 만든 방식이 있음: https://www.cs.dartmouth.edu/~doug/reader.pdf
UNIX는 제품이 아니라 도구를 만들고 실제 문제를 해결하기에 최적화된 환경이었고, C로 도구를 작성했음. 그동안 BBM들은 Boston에서 Lisp에 바빴겠지만
C++는 완전히 다른 이야기이고, 거기에는 IDE가 필요함

Emacs가 그런 성질을 갖는 건 Lisp를 쓰기 때문임. 프로그래머들이 전부 직접 만들기 시작하는 일반적 경향은 Lisp에서 관찰됐고, The Lisp Curse라고 불렸음
저주인 이유는 프로그래머들이 협업을 멈추기 때문임. 모두가 자기 탑에 갇힌 마법사가 되고, 전체 진보가 멈추며 암흑기가 옴

LLM 시대 덕분에 개인 소프트웨어를 만든 것은 맞음
하지만 솔직히 Emacs를 쓴 시간이 개인 소프트웨어를 만드는 법을 가르쳐주지는 않았음. 내 Emacs 설정은 극도로 깨지기 쉬웠고, Windows와 macOS에서 함께 쓰려 하자 악몽이었음
대학 프로젝트는 org-mode와 어떤 워크플로를 섞어 아름다운 LaTeX 파일을 만드는 괴상한 조합으로 작성했는데, 지금 다시 컴파일하는 법은 설명할 수 없음. 시도한다면 LLM에게 그대로 LaTeX로 번역하게 할 것 같음
내 삶에는 가능한 한 유지보수가 적었으면 하고, 모든 것을 직접 만드는 것이 항상 그 목표와 맞지는 않음
NETFX 애플리케이션을 Rust로 다시 쓴 적은 있음. 설치 시간이 20분 걸리는 게 짜증났기 때문임: https://github.com/bevan-philip/wlan-optimizer

15년 동안 Linux, Windows, macOS에서 같은 Emacs 설정을 써왔음. 솔직히 내 컴퓨팅 생활에서 제일 좋은 것임

"삶에 유지보수가 가능한 한 적었으면 한다"는 말이 무슨 뜻인지 솔직히 잘 공감이 안 됨
프로그래머의 일상 업무는 로컬, 원격, 클라우드, 임베디드 등 컴퓨터 시스템의 동작을 바꾸는 것임. 요구사항은 변하고, 범위는 흔들리고, 문제 공간은 진화하며, 퇴적은 피할 수 없음
언어 스택, 데이터 타입, 포맷, CLI와 웹 도구, 프로토콜, 패러다임, 오픈소스와 독점 앱 사이를 계속 이동해야 함
그래서 계속 적응해야 하고, 내 제어 평면도 변화에 맞춰야 함. 핵심은 자동화임. 작은 성가심은 전부 자동화할 수 있고 해야 함. 이는 워크플로를 끝없이 변형하는 일, 즉 도구의 지속적 유지보수지만, 고역스러운 반응형 유지보수는 아님
프로그래머이면서 자기 자신을 위해 계속 소프트웨어를 만들고 싶지 않다는 건 착각임. 식당에서는 불을 켜지만 집에서는 칼도 안 잡겠다는 요리사와 같음
Emacs는 요리사의 집 부엌임. 유지보수에는 고장 수리와 변화 추적 같은 반응형 유지보수, 그리고 이해가 진화하는 데 맞춰 도구를 빚는 생성형 유지보수가 있음. 프로그래머는 전자를 싫어하고 후자에 끌려야 함
Emacs는 도구와 일이 같은 기질을 공유하기 때문에 생성형 유지보수에 거의 유일하게 잘 맞음
Emacs가 "설정에 일이 너무 많다"는 불평은 흔하지만, 보통 "가치를 얻기 전에 투자하고 싶지 않다"는 뜻임. 이는 장기적으로 현명한 전략이 아님. Emacs를 커리어와 평생의 총 유지보수 부담을 줄이는 보편 도구로 보는 편이 맞음

LLM이 개인 소프트웨어를 만들 만큼 충분하다면, 그걸 유지보수할 만큼은 충분하지 않다는 뜻인가?

"도구를 만들 시간이 없다고 말하는 사람이야말로, 도구를 만들지 않을 여유가 없는 사람이다"

Emacs나 VIM 설정은 단순한 텍스트 파일이라 평범한 편집기로 열고 필요에 맞게 고칠 수 있으며, 어디에 무엇이 있는지도 알 수 있음. 내 VIM 설정은 20년 됐고, 12년 전에는 수동 패키지 관리를 버리고 플러그인 관리자를 쓰기 시작했을 뿐임
여기에는 게이트키퍼도, 의존성도 없음
반면 지금 방식은 제3자 기업에 20200달러를 내거나, 로컬 실행을 위해 꽤 강한 GPU가 필요하고, 텍스트 파일에 지시를 넣고 원하는 대로 될 때까지 계속 수정해야 함
스스로 의존성을 추가하는 것이고, 사람이 리뷰하기 어려울 정도로 뒤엉키면 그 의존성은 강한 의존성이 될 것임. 비싼 GPU든 주주를 만족시켜야 하는 회사로 데이터를 보내는 것이든 마찬가지임
이 둘이 어떻게 다른지, 우리가 치르는 진짜 대가가 무엇인지 구분해야 함

UI 애플리케이션을 만드는 사람들이 한계를 정하는 것 외에는 게이트키퍼가 없다는 뜻인가?

개인 소프트웨어, 즉 자기 자신을 위해 프로그램을 작성한다는 발상은 1960년대 가정용 컴퓨팅의 원래 비전이었음
PC가 정확히 예상되지는 않았지만, 모두가 집에 컴퓨터 단말기를 두고 필요한 일을 하기 위한 프로그램을 작성하리라는 생각이 있었음. 프로그래밍이 누구나 배울 수 있을 만큼 쉬워질 것이라고 상상했음
아직 거기까지는 아니지만 LLM 덕분에 가까워지고 있음

아직 가지 않은 길은 HyperCard, Visual Basic, Macromind Director, Flash 같은 것들이 완전히 꽃피는 방향임
비전문가가 잘 설계된 구성 요소와 이해하기 쉬운 은유를 갖춘 저작 환경에서 흥미로운 소프트웨어를 만들 수 있다는 생각임. 우발적이거나 과잉 설계된 복잡성의 층은 걷어낸 상태여야 함
이 비전에서도 소프트웨어에는 신중한 논리적 사고가 필요하지만, 그 사고를 실행 코드로 옮기는 번거로움이 훨씬 줄어듦. 도구 체인과 빌드 시스템 악몽도 없음
대신 우리는 너무 강력한 모델을 만들어 복잡한 주문을 대신 되뇌고 재조합하게 했음. 하지만 복잡성은 여전히 남아 있고, 비전문가에게는 여전히 불투명함
그래도 LLM이 그 복잡성을 일부 제거하는 데 도움을 줄 수도 있음. LLM이 생성한 소프트웨어를 개인이 쉽게 이해하고 직접 수정할 수 있는 방향은 아직 가능하며, LLM 세계와도 잘 보완될 수 있음

컴퓨터를 쓴다는 것이 곧 컴퓨터가 나를 위해 프로그램을 만드는 것을 포함하게 될 거라고 여러 친구들에게 말했지만 비웃음을 샀음
이건 가능 여부의 문제가 아니고, 시기도 길어야 10년, 아마 훨씬 더 빠를 것임. 이미 코딩을 모르는 친척들이 이런 일을 하고 있음
이 미래의 컴퓨팅은 정말 사랑스럽고, 엄청나게 힘을 실어주는 방향임

지금 그 지점에 와 있다고 느낌. 문제가 생길 때마다 "이걸 위해 앱을 바이브 코딩할까?"라고 묻고 있음
현재 Swift 앱은 1.5만 줄이고, 그중 테스트가 5000줄, 구현이 1만 줄임. 이제 거의 끝났고, 필요한 일은 함. 20시간 걸렸음
Swift를 해본 적이 없어서 직접 만들었다면 개인적으로 500시간은 걸렸을 것 같음

모두가 독자 앱이나 파일 시스템을 갖게 되면 공통 파일 형식이 사라질까 봐 걱정됨. 그렇게 되면 이전이나 협업이 고통스러워짐
우리 대부분이 게으르기 때문에 아마 그렇게까지 가지는 않겠지만, 분명 고려할 만함

앞으로는 모두가 자기만의 초특화 앱을 갖거나, 같은 앱 안에서도 서로 다른 UI와 시각화를 갖게 되는 일이 커질 것 같음
애플리케이션이라는 개념 자체가 훨씬 더 유동적이 됨
앱이 동적 언어로 만들어졌다면 사용자가 직접 코드를 다시 쓰고 완전히 새로운 기능을 추가하게 하지 않을 이유가 없음

기사 본문과 직접 관련은 없지만, 터미널이 거의 항상 고정폭이라 긴 글을 읽기에 피곤하다는 말에는 동의하지 않음. 개인적으로는 고정폭 글꼴로 긴 글을 읽는 게 훨씬 편함

저자가 흥미로운 지점을 짚었음. 작동하는 변수는 도구를 만드는 난이도, 게시하는 난이도, 남에게 주는 유용성, 게시했을 때의 사회적 보상, 의존성을 추가하는 부정적 유인임
기성 솔루션을 찾기 어려워지는 정도는 누군가 만들어야 하는 비용과 누군가 게시 방법을 알아내야 하는 비용에 따라 올라감. 반대로 커뮤니티에 유용할수록 사람들이 알려주기 때문에 찾기 쉬워짐
만드는 난이도와 게시 난이도가 크게 다르면, 특히 만드는 쪽이 훨씬 높으면 사람들은 직접 만들고 잊어버리는 경향이 있음. 게시 쪽이 낮으면 문제 해결책은 더 적어짐
둘 다 낮고, 남에게 주는 유용성과 사회적 보상이 의존성 비용보다 높으면 leftpad 같은 상황이 생김. NPM의 많은 패키지가 높은 유용성과 보상, 낮은 의존성 비용으로 구성됨
Emacs Lisp에서는 예전에는 만드는 난이도가 높았지만 지금은 낮고, 학습 곡선을 넘으면 게시 난이도도 낮음. 유용성, 보상, 의존성 비용도 어느 쪽으로든 높지 않음
그러면 도구가 있는지 찾아보기도 전에 그냥 만들어버리는 시나리오가 생김. VSCode나 예전 Eclipse는 게시 난이도가 높아서 달랐음
나보다 젊은 누군가가 이걸 논문 주제로 세상에 내놓을 것 같음

이 글은 LLM 코딩이 가져올 아직 실현되지 않은 변화 하나를 암시함. 이제 Electron/React Native를 버리고, LLM이 Figma·와이어프레임·동작 명세를 각 플랫폼의 진짜 네이티브 앱으로 변환하게 할 수 있지 않을까?
CRUD 앱이라면 API 명세와 UI 목업, 심지어 이미 구현된 플랫폼의 화면 사진만으로도 꽤 멀리 갈 수 있음. 이런 잘 정의된 작업은 LLM이 잘하는 종류임. 동등성 테스트도 상당 부분 자동화할 수 있어야 함
"언젠가 Android도 추가할지도"나 "Mac/Linux 사용자가 충분하지 않다"는 핑계가 아직 남아 있을까? iOS 앱에서 비밀번호 재설정 같은 덜 쓰는 흐름을 구현하지 않고 임의의 WebView를 띄우는 것도 정당화될까?
기기 안에 사소하지 않은 로직이 있는 앱도, LLM은 Go나 Rust처럼 교차 컴파일이 쉬운 언어로 다시 쓰는 데 꽤 가능성을 보여줬음

가능함. 지금도 되고, 정말 잘 됨
더 자극적으로 말하면, 이 시점에 왜 SwiftUI를 배워야 하는가? 대부분의 작업에서 SwiftUI 전문성은 "Microsoft Word를 아주 깊게 배우기"와 비슷한 범주에 들어감
그런 시간을 들이는 사람들을 존중하지만, 그렇게 하든 안 하든 결과 차이는 밀리미터 단위에 가까움
프로그래밍 전반에 대해 그렇게 생각하는 건 아님. 다만 이제 어떤 언어들은 전문화할 이유가 더 복잡해졌다고 봄