# 플레인 텍스트는 수십 년 동안 이어져 왔고 앞으로도 남을 것 > Clean Markdown view of GeekNews topic #28900. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28900](https://news.hada.io/topic?id=28900) - GeekNews Markdown: [https://news.hada.io/topic/28900.md](https://news.hada.io/topic/28900.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-26T12:33:31+09:00 - Updated: 2026-04-26T12:33:31+09:00 - Original source: [unsung.aresluna.org](https://unsung.aresluna.org/plain-text-has-been-around-for-decades-and-its-here-to-stay/) - Points: 1 - Comments: 1 ## Topic Body - **모노스페이스 평문** 기반 다이어그램·UI 설계 도구가 다시 쓰이고 있으며, 텍스트 편집 인터페이스의 익숙함과 파일 형식의 **이식성**이 오래 지속될 힘을 줌 - Mockdown, Wiretext, Monodraw 같은 도구는 제한된 시각적 선택지를 유지하면서 **저강도 다이어그램**을 만들기 좋고, 소스 코드 안에 넣는 용도에도 맞음 - Mockdown은 웹과 모바일에서 바로 쓸 수 있고, Wiretext는 웹에서 동작하지만 **데스크톱 전용**이며, Monodraw는 **Mac 앱**으로 제공됨 - 1970~1980년대에 정점을 찍은 방식이 Turbo Vision 같은 TUI 계열을 떠올리게 하는 형태로 돌아오면서, 현대적 감각과 성능, **웹 접근성**, 마우스·트랙패드 조작성이 더해짐 - 컴퓨터 성능이 커질수록 스스로 **제약을 두는 작업 방식**이 더 유용해지고, 이런 평문 도구는 점점 더 **gen AI 진입점**으로도 쓰임 --- ### 평문 도구의 지속성 - **평문** 또는 “ASCII” 기반 다이어그램·UI 설계 도구로 [Mockdown](https://www.mockdown.design/), [Wiretext](https://wiretext.app/), [Monodraw](https://monodraw.helftone.com/)가 거론됨 - Mockdown은 웹에서 바로 동작하며 모바일도 지원함 - Wiretext는 웹에서 동작하지만 데스크톱에서만 사용할 수 있음 - Monodraw는 Mac 앱으로 제공됨 - 이런 도구는 **의도적으로 제한된 시각적 선택지**를 선호할 때, 소스 코드에 넣을 저강도 다이어그램을 만들 때, 그리고 점점 더 **gen AI 진입점**으로도 쓰임 - 1970~1980년대에 정점을 찍은 방식이 현대적으로 다시 살아나고 있음 - [Turbo Vision](https://www.google.com/search?q=turbo+vision) 같은 TUI 계열을 떠올리게 함 - 여기에 현대적 감각, 성능, 웹 접근성, 마우스와 트랙패드 조작성이 더해짐 - 제약을 두는 작업 방식 자체가 중요해지고 있음 - 컴퓨터 성능이 커질수록 스스로 제약을 걸어 작업을 더 쉽게 만드는 일이 이미 유용함 - AI 확산과 함께 자기 제약은 일을 더 어렵게 만드는 방향에서도 중요해짐 - **모노스페이스 평문**은 파일 형식의 이식성뿐 아니라, 인터페이스로서의 텍스트 편집이 널리 알려져 있고 강력하다는 점에서도 오래 지속될 힘이 있음 - [potent](https://unsung.aresluna.org/we-can-go-deeper-by-patterning-inside-of-our-pattern/) - Mockdown의 **ASCII spray**는 특히 재미있는 요소로 꼽힘 - 여기서 말하는 “ASCII”는 엄밀한 기술 용어라기보다, 반복 애니메이션을 통칭해 “GIF”라고 부르는 것과 비슷한 구어적 표현에 가까움 ## Comments ### Comment 56324 - Author: neo - Created: 2026-04-26T12:33:32+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47897681) - 예시로 **평문 회계**가 나온 게 반가웠음 **QuickBooks**에서 **Beancount+Fava**로 1인 사업자 장부를 옮겼는데 훨씬 만족스럽고, 텍스트 기반 청구서 시스템과 차량 주행거리 추적도 붙였으며 세금 상태가 있는 지출엔 증빙 문서가 반드시 연결되도록 validator도 넣어뒀음 QuickBooks보다 훨씬 빠르고 쓰기 쉽고 광고를 볼 필요도 없으며, git과 **RFC3161** 커밋 증명을 붙여서 언제 어떤 추가를 했는지 입증할 수 있고, 부주의한 텍스트 수정으로 기록이 사라질 일도 줄었고, 각 항목이 언제 만들어졌는지도 간단히 확인 가능함 핵심은 전부 plain text지만 원하면 브라우저에서도 다루도록 Fava 확장도 추가해뒀고, 그래프까지 되는 TUI Fava가 있으면 더 좋겠지만 웹 UI도 충분히 괜찮음 이제 회계사가 이걸 어떻게 볼지만 남았음 - **Beancount**를 처음 알게 됐는데 꽤 솔깃함 미국인이지만 다른 나라에서 일해서 **2개 통화**를 늘 다루는데, Gnucash에서는 다중 통화를 만족스럽게 처리하지 못해서 부부가 지금까지 텍스트 파일로 기록해왔음 포맷을 꽤 일관되게 써왔으니 Beancount로 옮길 때 변환 스크립트를 쓰거나 LLM 도움을 받아도 작업의 95%쯤은 자동화할 수 있을 것 같고, 파싱 못 하는 항목만 경고로 띄우면 될 듯함 나도 Beancount + Fava 쪽으로 갈 가능성이 큼 - 이건 내 **plain text accounting** 프로젝트들에 정말 좋은 자극이 됨 특히 **RFC3161 커밋 증명**을 어떻게 쓰는지 더 자세히 알고 싶음 커밋 작성자가 본인임을 보이기 위해 GPG로 서명하는 건 짐작되는데, 외부 타임스탬프 서비스와 외부 CA를 쓰는지, 아니면 자체 신뢰 체인을 만드는지 궁금함 회계 감사인이 장부 커밋의 진위를 요구하면 실제로 어떤 자료와 절차로 입증하게 되는지도 알고 싶음 - 이런 방식이 정말 좋음 내가 직접 단순한 파일 포맷을 만들 때도, 필요하면 **더 흔한 포맷**으로 어떻게 변환할지 항상 생각해둠 필요할 때 다른 사람에게 넘길 **탈출 경로**가 있다는 사실만으로도 마음이 편해짐 이 경우엔 회계사가 받아들일 만한 **CSV**로도 쉽게 바꿀 수 있을 것 같음 - 전성기가 1970~80년대였을 수는 있어도, **1990년대 초 DOS** 시절에도 아주 뛰어난 TUI가 많았음 Windows가 완전히 장악하기 전이었고, 대개 VGA 호환 그래픽 카드와 모니터가 있어서 해상도 높고 선명하며 글꼴까지 조절 가능한 텍스트 모드를 쓸 수 있었고 마우스도 있는 경우가 많았음 내가 자라며 익숙했던 게 바로 그런 환경의 **QBASIC**과 **EDIT.COM**이었음 심지어 당시 앱들 중엔 제대로 된 마우스 커서까지 구현한 것도 있었고, Bisqwit 영상이 그걸 잘 보여줌: [https://www.youtube.com/watch?v=7nlNQcKsj74]() - 그 시절 **Borland 코드 에디터**를 정말 좋아했음 Turbo-C, Turbo-Pascal 등에 들어 있던 그 편집기였는데, IDE라고 불러도 될 정도였음 텍스트 모드 **WordPerfect**, **WordStar**, **Lotus 1-2-3**도 상당히 훌륭했음 - 내 기준 **TUI의 정점**에 가까운 건 Norton Commander나 Midnight Commander임 - 오히려 **TUI의 전성기**는 지금이라고 봄 터미널과 설정 파일 중심으로 돌아가는 운영체제인 **Omarchy**를 보면 거의 낙원에 가까움 앞으로 기계와의 주된 인터페이스가 텍스트 기반 대화가 되는 세상으로 가면 이 흐름이 얼마나 더 멀리 갈지 기대됨 여기선 AI 얘기하면 싫어할 사람도 많겠지만, 나는 그 미래가 진심으로 기대됨 - 제목을 보고 본문과는 조금 다른 쪽으로 새어버렸는데, **plain text**가 단순하고 견고한 컴퓨팅의 기반이라고 믿는다면 Dylan Beattie의 **There's no such thing as plain text** 발표를 볼 만함 [https://www.slideshare.net/slideshow/theres-no-such-thing-as-plain-text-dylan-beattie/249952971]() 여러 컨퍼런스 영상도 쉽게 찾을 수 있음 - 영상을 아직 보진 않았지만 슬라이드만 보면 핵심 중 하나는 **인코딩** 문제 같아 보임 UTF-16LE와 UTF-16BE 같은 예시도 있고 다행히 이제는 **UTF-8**이 사실상 기본값이 돼서, 특별한 이유가 없는 한 대부분 문서는 UTF-8이라고 가정해도 됨 인코딩을 모르는 텍스트 파일을 받았을 때도 UTF-8일 확률이 99.7%쯤 된다고 봐서, 이제는 다시 **plain text라는 게 있다**고 말해도 된다고 느낌 - 슬라이드쇼만 봐서는 논지가 잘 안 잡힘 code page나 **UTF-16** 같은 것도 전부 plain text이지만 사실은 그렇지 않다는 이야기라면, 그 주장은 2026년 기준으로는 꽤 **시대에 뒤처진** 느낌임 이제는 UTF-8이 사실상 어디에나 있음 - 예전부터 그 표현을 써왔는데, 제대로 된 발표가 이미 있을 것 같다는 막연한 생각만 했었음 이런 자료가 실제로 있는 걸 보니 좋음 - 나는 그 주장에 **강하게 동의하지 않음** **Unicode**처럼 복잡하고 기묘한 시스템은 plain하다고 부를 수 없고, 지금도 많은 앱에서 Unicode 관련 문제가 자주 터짐 정말 어디서나 잘 동작하는 텍스트 시스템은 여전히 **ASCII**뿐이라고 보고, 그 정도는 돼야 plain text라고 부를 수 있다고 생각함 영어 위주로 제한된다는 뜻이지만 많은 환경에선 오히려 그게 자연스럽고, 나도 영어 원어민이 아니지만 그 입장을 옹호할 수 있음 - **Plain text**는 정말 좋음 내 메모 20년치 이상을 [https://github.com/nickjj/notes]()로 관리하고 있음 청구서도 7년 정도 [https://github.com/nickjj/invoice]()로 plain text 방식으로 처리해왔음 수입·지출 추적용으로는 [https://github.com/nickjj/plutus]()도 있고, 만족도가 아주 높음 이제는 은행 CSV만 내보내서 Plutus에 넣고, 몇 분 동안 카테고리만 조금 맞추면 장부가 끝남 이 방식으로 세금 신고도 2년째 처리하고 있음 - 텍스트는 **Lindy**함 시간의 시험을 버텼고, **SQL**이나 **TCP/IP**만큼이나 널리 퍼져 있음 Graydon Hoare의 오래된 글 **Always bet on text**도 떠오름 [1]: [https://news.ycombinator.com/item?id=8451271]() [2]: [https://graydon2.dreamwidth.org/193447.html]() - 여기서는 **HN**도 plaintext로 보나 궁금함 분명 사이트는 HTML과 하이퍼링크로 되어 있지만, 실제 사용감은 클릭 가능한 텍스트 인터페이스에 가까움 암호학적으로는 HTML도 ascii/utf-8로 인코딩되니 plaintext라고 할 수 있지만, MIME type에서는 **text/plain**과 **text/html**이 문서 구조와 스타일 정보를 구분함 터미널도 흔히 plaintext로 보지만 실제로는 사람이 바로 읽기 어려운 **escape sequence**로 메타정보를 담음 반대로 소셜 미디어에는 글 몇 줄이 들어간 이미지도 많은데, 최근 모바일 플랫폼은 이미지 속 텍스트를 인식해서 선택까지 가능하게 함 그렇다면 다른 요소 없이 텍스트만 박힌 이미지는 plaintext인가 하는 의문도 생김 결국 내가 묻고 싶은 건, 초기 구현 이후 수십 년이 지난 지금 **plaintext의 경계**를 어디에 그을지임 - HN은 그냥 일반적인 **HTML**이니 plaintext라고 불러도 무리는 없다고 봄 - 본문과는 좀 다른 얘기지만, **텍스트 문자 기반 통계 차트**가 떠오름 오래전에 DOS용 교육판 **MINITAB**을 썼는데, 텍스트 문자로 scatter diagram, dotplot, box-and-whisker plot을 그려줬음 순수 텍스트나 ASCII, 또는 DOS 선 그리기 문자를 옵션으로 쓸 수 있었던 걸로 기억함 정식 통계 검정으로 들어가기 전에 먼저 데이터를 탐색하게 하려는 취지였음 이런 식으로 제대로 된 **dotplot**을 터미널에서 그려주는 프로그램이 지금도 있는지 궁금함 - 이 Stack Overflow 스레드에 **터미널 플로팅 도구**가 꽤 잘 정리돼 있음 [https://stackoverflow.com/questions/123378/command-line-unix-ascii-based-charting-plotting-tool]() gnuplot, feedgnuplot, eplot, asciichart, bashplotlib, ervy, ttyplot, youplot, visidata가 나옴 그리고 AWK 책에도 멋진 **ASCII plot** 예제가 있음: [https://dn790008.ca.archive.org/0/items/pdfy-MgN0H1joIoDVoIC7/The_AWK_Programming_Language.pdf#page=148]() - **gnuplot dumb terminal mode**를 쓰면 될지도 모름 - 맨 위의 목록은 더 길어질 수 있음 [https://asciiflow.com/]() [https://asciidraw.github.io/]() 더 아는 도구가 있는지 궁금함 - **D2**가 작년에 **ASCII & Unicode 출력** 베타 지원을 추가했음 [https://d2lang.com/]() - [https://github.com/TheoKVA/ascii-box-editor]() 이름과 달리 ASCII가 아니라 **UTF-8 BOX DRAWING** 문자를 쓰는 비주얼 에디터임 서버도 설치도 필요 없고 브라우저에서만 동작하는 Javascript 방식임 - [https://xosh.org/text-to-diagram]()에 도구가 많이 정리돼 있음 - [https://monosketch.io]() - **M-x artist-mode**도 있음, Emacs에서 바로 쓸 수 있음 - plain text는 분명 좋지만, **구조화**가 필요해지는 순간 파일마다 매번 바닥부터 시작하게 됨 오래된 Unix 도구들을 즉흥적으로 조합해 plain text를 처리하는 방식에 향수를 느끼는 사람이 늘 있는데, 그런 접근은 임시 상황에서는 괜찮아도 **잘 명세된 포맷**을 대체하진 못함 - **XML, JSON, YAML, RDF, EDN, LaTeX, OrgMode, Markdown**처럼 구조화된 plaintext 포맷은 충분히 많음 줄 단위의 일반 텍스트로도 처리할 수 있고, 구조화된 데이터 변환도 가능하며, 이를 WYSIWYG처럼 렌더링해주는 클라이언트나 리더도 이미 갖춰져 있음