예시로 평문 회계가 나온 게 반가웠음 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 얘기하면 싫어할 사람도 많겠지만, 나는 그 미래가 진심으로 기대됨
영상을 아직 보진 않았지만 슬라이드만 보면 핵심 중 하나는 인코딩 문제 같아 보임
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라고 부를 수 있다고 생각함
영어 위주로 제한된다는 뜻이지만 많은 환경에선 오히려 그게 자연스럽고, 나도 영어 원어민이 아니지만 그 입장을 옹호할 수 있음
여기서는 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을 터미널에서 그려주는 프로그램이 지금도 있는지 궁금함
plain text는 분명 좋지만, 구조화가 필요해지는 순간 파일마다 매번 바닥부터 시작하게 됨
오래된 Unix 도구들을 즉흥적으로 조합해 plain text를 처리하는 방식에 향수를 느끼는 사람이 늘 있는데, 그런 접근은 임시 상황에서는 괜찮아도 잘 명세된 포맷을 대체하진 못함
XML, JSON, YAML, RDF, EDN, LaTeX, OrgMode, Markdown처럼 구조화된 plaintext 포맷은 충분히 많음
줄 단위의 일반 텍스트로도 처리할 수 있고, 구조화된 데이터 변환도 가능하며, 이를 WYSIWYG처럼 렌더링해주는 클라이언트나 리더도 이미 갖춰져 있음
Hacker News 의견들
예시로 평문 회계가 나온 게 반가웠음
QuickBooks에서 Beancount+Fava로 1인 사업자 장부를 옮겼는데 훨씬 만족스럽고, 텍스트 기반 청구서 시스템과 차량 주행거리 추적도 붙였으며 세금 상태가 있는 지출엔 증빙 문서가 반드시 연결되도록 validator도 넣어뒀음
QuickBooks보다 훨씬 빠르고 쓰기 쉽고 광고를 볼 필요도 없으며, git과 RFC3161 커밋 증명을 붙여서 언제 어떤 추가를 했는지 입증할 수 있고, 부주의한 텍스트 수정으로 기록이 사라질 일도 줄었고, 각 항목이 언제 만들어졌는지도 간단히 확인 가능함
핵심은 전부 plain text지만 원하면 브라우저에서도 다루도록 Fava 확장도 추가해뒀고, 그래프까지 되는 TUI Fava가 있으면 더 좋겠지만 웹 UI도 충분히 괜찮음
이제 회계사가 이걸 어떻게 볼지만 남았음
미국인이지만 다른 나라에서 일해서 2개 통화를 늘 다루는데, Gnucash에서는 다중 통화를 만족스럽게 처리하지 못해서 부부가 지금까지 텍스트 파일로 기록해왔음
포맷을 꽤 일관되게 써왔으니 Beancount로 옮길 때 변환 스크립트를 쓰거나 LLM 도움을 받아도 작업의 95%쯤은 자동화할 수 있을 것 같고, 파싱 못 하는 항목만 경고로 띄우면 될 듯함
나도 Beancount + Fava 쪽으로 갈 가능성이 큼
특히 RFC3161 커밋 증명을 어떻게 쓰는지 더 자세히 알고 싶음
커밋 작성자가 본인임을 보이기 위해 GPG로 서명하는 건 짐작되는데, 외부 타임스탬프 서비스와 외부 CA를 쓰는지, 아니면 자체 신뢰 체인을 만드는지 궁금함
회계 감사인이 장부 커밋의 진위를 요구하면 실제로 어떤 자료와 절차로 입증하게 되는지도 알고 싶음
내가 직접 단순한 파일 포맷을 만들 때도, 필요하면 더 흔한 포맷으로 어떻게 변환할지 항상 생각해둠
필요할 때 다른 사람에게 넘길 탈출 경로가 있다는 사실만으로도 마음이 편해짐
이 경우엔 회계사가 받아들일 만한 CSV로도 쉽게 바꿀 수 있을 것 같음
전성기가 1970~80년대였을 수는 있어도, 1990년대 초 DOS 시절에도 아주 뛰어난 TUI가 많았음
Windows가 완전히 장악하기 전이었고, 대개 VGA 호환 그래픽 카드와 모니터가 있어서 해상도 높고 선명하며 글꼴까지 조절 가능한 텍스트 모드를 쓸 수 있었고 마우스도 있는 경우가 많았음
내가 자라며 익숙했던 게 바로 그런 환경의 QBASIC과 EDIT.COM이었음
심지어 당시 앱들 중엔 제대로 된 마우스 커서까지 구현한 것도 있었고, Bisqwit 영상이 그걸 잘 보여줌: https://www.youtube.com/watch?v=7nlNQcKsj74
Turbo-C, Turbo-Pascal 등에 들어 있던 그 편집기였는데, IDE라고 불러도 될 정도였음
텍스트 모드 WordPerfect, WordStar, Lotus 1-2-3도 상당히 훌륭했음
터미널과 설정 파일 중심으로 돌아가는 운영체제인 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의 경계를 어디에 그을지임
본문과는 좀 다른 얘기지만, 텍스트 문자 기반 통계 차트가 떠오름
오래전에 DOS용 교육판 MINITAB을 썼는데, 텍스트 문자로 scatter diagram, dotplot, box-and-whisker plot을 그려줬음
순수 텍스트나 ASCII, 또는 DOS 선 그리기 문자를 옵션으로 쓸 수 있었던 걸로 기억함
정식 통계 검정으로 들어가기 전에 먼저 데이터를 탐색하게 하려는 취지였음
이런 식으로 제대로 된 dotplot을 터미널에서 그려주는 프로그램이 지금도 있는지 궁금함
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
맨 위의 목록은 더 길어질 수 있음
https://asciiflow.com/
https://asciidraw.github.io/
더 아는 도구가 있는지 궁금함
https://d2lang.com/
이름과 달리 ASCII가 아니라 UTF-8 BOX DRAWING 문자를 쓰는 비주얼 에디터임
서버도 설치도 필요 없고 브라우저에서만 동작하는 Javascript 방식임
M-x artist-mode도 있음, Emacs에서 바로 쓸 수 있음
plain text는 분명 좋지만, 구조화가 필요해지는 순간 파일마다 매번 바닥부터 시작하게 됨
오래된 Unix 도구들을 즉흥적으로 조합해 plain text를 처리하는 방식에 향수를 느끼는 사람이 늘 있는데, 그런 접근은 임시 상황에서는 괜찮아도 잘 명세된 포맷을 대체하진 못함
줄 단위의 일반 텍스트로도 처리할 수 있고, 구조화된 데이터 변환도 가능하며, 이를 WYSIWYG처럼 렌더링해주는 클라이언트나 리더도 이미 갖춰져 있음