마크다운이 실행 가능하다면 어떨까? 문서와 코드를 하나로 묶고, LLM 에이전트 루프와 구조화된 출력으로 프로그램을 실행하는 ‘markdownlang’이라는 가상의 AI 네이티브 프로그래밍 환경을 통해, 기술의 가능성과 사회적 함의를 함께 성찰한다.
2026-02-10 게시, 2001단어, 읽는 데 8분
마크다운이 실행 가능하다면 어떨까? 그러면 markdownlang이 나온다.
영화 블레이드 러너에서 데커드는 레플리컨트를 사냥한다. 레플리컨트는 생화학적 노동자이며, 사실상 인간과 구분이 불가능하다. 그들은 블레이드 러너 사회의 핵심에 짜여 들어가 있었지만, 머리 위에는 시간 제한이라는 다모클레스의 검이 매달려 있었다. 수명은 4년, 하루도 더는 없다. 이 때문에 레플리컨트들은 삶에 매달릴 수밖에 없었고, 한 시간이라도 더 살 수 있다면 사람을 죽일 수도 있었다. 그래서 블레이드 러너의 일이 그렇게 치명적이었던 거다.
메타서사적으로 보자면, 문제는 레플리컨트가 아니었다. 문제는 그들을 만든 사람들이었다. 생각할 수 있는 능력을 준 사람들. 느낄 수 있는 능력을 준 사람들. 이해하고 공감할 수 있는 능력을 준 사람들. 삶을 즐길 수 있는 능력을 준 뒤에, 그 위에 시간 제한이라는 다모클레스의 검을 들이민 사람들이 문제였다. 레플리컨트는 근본적으로 소모품이었으니까.
블레이드 러너에서 진짜 공포는 기술이 아니었다. 기술은 멀쩡히 잘 돌아간다. 공포는 그 기술이 배치되는 방식, 그리고 사람을 소모품으로 만드는 사회적 함의에 있었다. 지금도 어딘가에 그런 하층계급 같은 사람들이 존재하지 않을까 생각하게 된다.
그래서 SF는 사회비평과 떼려야 뗄 수 없다. 최고의 예술은 다 그렇다. 한 번 눈치채기 시작하면 아마 다시는 못 보지 못할 거다. 평생 저주받은 삶을 즐겨라!
나는 사람들이 AI 에이전트와 상호작용하는 모습을 볼 때마다 그 장면들이 자꾸 떠오른다. 새로운 흐름들 속에서 어떤 두 시스템을 통합하는 비용은 0에 가까워지고 있다. 가장 비싼 건 시간이다. 사람들은 이제 문서를 읽지 않는다. 그건 AI 에이전트의 일이다. 정신노동은 살과 피에서 HBM과 코일 소음으로 옮겨가고 있다. “실제 작업”을 하는 것은 그 자체로 또 다른 종류의 레플리컨트이며, 결과가 “작동”하기만 하면 많은 인간은 배포하기 전에 출력물을 검토조차 하지 않는다.
이걸 보고 있자니, 미래가 어디로 흘러갈지 얼핏 보이는 것 같다. 이런 흐름을 따라가다 보면 프로그래밍이 어떻게 바뀔지, 그리고 인류의 “마지막 프로그래밍 언어”가 어떤 모습일지 생각하게 된다. 새 언어가 더는 나오지 않게 되진 않을 거다(너드들은 강박적으로 언어를 설계하니까). 하지만 AI 도구가 너무 널리 퍼진 뒤의 여파 속에서 “프로그램”이 무엇인지 그 형태 자체가, 우리가 탭이냐 스페이스냐, DB 프레임워크가 뭐냐로 싸우는 사이에 발밑에서 급격히 바뀌고 있는지도 모른다.
마크다운 파일이 새로운 실행 파일이 되는 미래를 상상해 보자. 논의를 위해 이 결과물을 Markdownlang이라고 부르자.
Markdownlang은 구조화된 출력과 마크다운으로 만들어진 AI 네이티브 프로그래밍 환경이다. 모든 markdownlang 프로그램은 AI 에이전트이며, 각자 에이전틱 루프(agentic loop)를 돌려 출력을 생성하거나 도구를 호출해, 프로그램별 스키마를 따르는 구조화된 출력에 도달한다.
파서, 렉서, 혹은 전통적인 프로그래밍 런타임을 쓰는 대신, markdownlang 프로그램은 대형 언어 모델이 구조화된 JSON과 템플릿 프롬프트를 입력으로 받아 에이전틱 추론 루프를 실행하고, 그 결과로 구조화된 JSON을 응답으로 내보내는 방식으로 실행된다.
Markdownlang 프로그램은 다른 markdownlang 프로그램을 의존성으로 임포트할 수 있다. 그 경우, 그들은 다른 도구들과 마찬가지로 또 하나의 도구로서 나타난다. 기존 시스템이나 프로그램과 상호작용해야 한다면, Model Context Protocol(MCP) 서버로 그 도구들을 노출하는 것이 기대된다. MCP 도구는 다른 도구들과 똑같은 방식으로 런타임에 추가된다. 웹 검색을 하거나, GitHub 이슈를 만들거나, Linear의 티켓을 업데이트하는 일은 바로 이 MCP 도구로 한다.
왜냐고 묻기 전에, markdownlang이 가능하게 하는 것처럼 ‘이산적인 워크플로’(discrete workflows)를 위한 AI 생태계의 현주소부터 말하자면: 완전한 씨발 악몽이다. 매주 새로운 에이전트 프레임워크, DSL, 패러다임, 혹은 아무 이유 없이 특정 제공자에서만 동작하는 CLI 도구가 나온다. 어떻게든 관련 있어 보이려는 필사적인 시도 속에서, 모든 것이 복잡성 크리프에 잠식되어 너(의 AI 에이전트)가 수 킬로미터짜리 YAML을 쓰게 만들고, 깨지기 쉬운 오케스트레이션과 씨름하게 만들며, 디버깅을 악몽으로 만든다.
과대광고는 이 난장판이 프로그래머를 대체할 거라고 말하지만, 전문적으로 이런 도구들을 써 보며 정말로 뭔가가 있는지 확인하려고 하는 사람으로서, 나는 잘 모르겠다. 세대가 몇 번 개선된다고 해도 말이다.
이 점을 염두에 두고, markdownlang이 무엇을 가져오는지 보자.
markdownlang에서 가장 중요한 개념은 문서와 코드가 동일하다는 것이다. 문서화의 가장 큰 고질 문제 중 하나는, 어떤 내용을 ‘어떤 형태로든’ 적어 두는 순간 그것을 낡게 만드는 가장 좋은 방법이 된다는 점이다. 문서를 테스트하는 일은 시간이 지날수록 고역이 된다. 인간은 결국 문서 없이도 충분히 능숙해져서 더는 필요로 하지 않게 되기 때문이다. 이 용도에서 AI 모델이 갖는 가장 큰 장점 중 하나는, 그들이 과업 사이에 진짜로 아무것도 기억하지 못한다는 사실이다. 그러니 문서가 엉망이면 프로그램은 일관되게 실행되지 않는다.
그 외에는, 모든 것이 조합 가능한 에이전트일 뿐이다. 에이전트는 다른 에이전트가 사용할 수 있는 도구가 되고, 엄격한 타입의 스키마가 이 모든 외관을 단단히 붙들어 준다. 마법은 필요 없다.
아, 그리고 markdownlang 런타임에는 WebAssembly와 WASI를 이용한 임베디드 파이썬 인터프리터가 있다. 런타임은 로컬 파일시스템 폴더에는 접근할 수 없다. 이건 순전히 언어 모델이 계산을 위해 파이썬을 호출하도록 학습되어 있기 때문에 넣은 것이다(누군가 내가 AI 모델의 “strawberry” 문제를 고친 풍자 글에서 영감을 받았을 거라고 가정한다).
markdownlang에서 Fizzbuzz는 이렇게 생겼다:
markdown--- name: fizzbuzz description: FizzBuzz classic programming exercise - counts from start to end, replacing multiples of 3 with "Fizz", multiples of 5 with "Buzz", and multiples of both with "FizzBuzz" input: type: object properties: start: type: integer minimum: 1 end: type: integer minimum: 1 required: [start, end] output: type: object properties: results: type: array items: type: string required: [results] --- # FizzBuzz For each number from {{ .start }} to {{ .end }}, output: - "FizzBuzz" if divisible by both 3 and 5 - "Fizz" if divisible by 3 - "Buzz" if divisible by 5 - The number itself otherwise Return the results as an array of strings.
이걸 친구들에게 보여줬더니 꽤 재밌는 반응들이 나왔다:
이 프로그램을 실행하면 이렇게 나온다:
json{ "results": [ "1", "2", "Fizz", "4", "Buzz", "Fizz", "7", "8", "Fizz", "Buzz", "11", "Fizz", "13", "14", "FizzBuzz" ] }
상상할 수 있듯, 가능성은 진짜 끝이 없다.
그래, 이게 고급스러운 똥글(high-brow shitposting)인 건 나도 안다. 하지만 markdownlang 같은 걸 가장 잘 이해하는 방법은, 이것이 새로운 추상화 계층이라는 관점이다. markdownlang 같은 세계에서 네가 다루는 진짜 추상화는, 오늘날 인터넷의 프로그래밍에 만연한 저수준 기계적 꼬장(pedantry)을 상대하는 대신 Jira/Linear에 던져 넣는 명세들이다.
컴퓨터에게 그냥 “해”라고 말할 수 있다면 얼마나 더 많은 일을 해낼 수 있을지 상상해 보라. 문법 문제의 종말, 세미콜론 싸움의 종말, API 외우기의 종말, 어떤 장난꾸러기가 sed로 세미콜론을 그리스식 물음표로 바꿔서 생기는 컴파일러 에러의 종말. 모든 것은 엄격한 타입의 데이터가 되고, 진짜로 고수준 언어의 조각들 사이에 가드레일처럼 작동한다.
그러니까, 온갖 언어 난장판(langle mangle) 프로그래밍 공간 전체를 그 각도에서 보면, 여기서의 사용자 경험은 스타트렉에서 보던 그런 SF 마법과 같다. 컴퓨터에게 “페이저의 노로코프 위상 분산을 트리아실레이팅 주파수로 조정해”라고 말하면, 컴퓨터가 네 뜻을 알아서 해주는 것. 이게 애플이 큰 키노트에서 AI로 하겠다고 말했던 마법이고, 그 성배를 그대로 낭비해 버리기 직전까지 갔던 그거다.
그렇다 해도, 이건 여전히 프로그래밍이다. 스키마는 새로운 타입이고, 임포트는 새로운 의존성이며, 조합은 새로운 아키텍처이고, 디버깅은 여전히 디버깅이다. 그리고 거대한 MCP 생태계는 부담이 아니라 통합의 이점이 된다.
Markdownlang은 그저 도구다. 대형 언어 모델은 (솔직히 말해: 앞으로도) 실수할 수 있다. 스키마로는 모든 것을 100% 표현할 수 없다. 누군가는 이 에이전트들을 써야 하고, 이런 것이 널리 퍼진다고 해도, 프로그래머의 일자리는 꽤 안전하다고 나는 생각한다.
적어도, 우리가 진짜로 대체되려면 우리를 고용하는 사람들이 자신들이 원하는 게 무엇인지 충분히 높은 수준의 디테일로 알아야 하고, markdownlang이 가능하게 만들 수 있을 정도로 그것을 명세할 수 있어야 한다. 내 생각에 우리가 프로그래머로 고용되는 이유는, 우리가 어떤 도구를 쓰든 상관없이 핵심 비즈니스 목표에 도달하기 위해 필요한 요구사항을 만들어낼 수 있을 정도의 깊고 명료한 사고력을 갖추고 있기 때문이다.
그렇게까지 깊은 얘기는 아니다.
여기서부터 이런 것은 즉각적이고도 명백한 사용처가 많다. 말 그대로 어떤 네모난 말뚝이든 다른 어떤 둥근 구멍이든 통합하는 범용 링구아 프랑카다. 여기서 내가 더 나아갈 수 있는 큰 방향들은 다음과 같다:
markdownlang compile 명령을 만들어서 markdownlang 프로그램을 Go, Python, JavaScript로 번역해 버리는 것. MCP 임포트도 직접 함수 호출로 변환해서.하지만 사실, markdownlang을 작업하면서(완전히 동작하는 버전이 있긴 한데, 아직 공개하진 않을 거다) 나는 AI 도구에 대해 내가 느끼는 미묘함을 훨씬 더 이해하게 됐다. 블레이드 러너의 그 멜로드라마가, 내가 막 만들어낸 것을 바라볼 때마다 나를 멈칫하게 만들고, 왜 내가 AI 툴링을 멋지면서도 동시에 섬뜩하다고 느끼는지에 대한 진짜 공포를 이해하게 만든다.
문제는 기술이 아니다. 진짜 공포는 기술이 어떻게 배치되고, markdownlang 같은 도구가 나 같은 프로그래머를 사회적으로 소모품으로 만들 때 어떤 일이 벌어질지—그 사회적 함의를 고려할 때 드러난다. “충분히 괜찮음(good enough)”이 바닥이 아니라 천장이 되는 순간, 우리는 쉽게 되돌릴 수 없는 무언가를 잃게 될 것이다.
나에게 진짜 공포는, 이런 도구가 시중의 부품만으로도 만들 수 있을 뿐 아니라, 실제로 내가 만들었다는 사실을 안다는 데 있다. 내가 파이널 판타지 14에서 레이드를 도는 동안, 소규모 Claude Code 무리가 알아서 돌아다니며 구축하게 했으니까. 나는 코드의 대부분을 사실상 거의 보지 않았다(의도적으로, 그게 The Bit™️의 일부다). 그런데도 ‘충분히 잘’ 돌아가서, 굳이 자세히 파고들 필요를 못 느꼈다. 이제는 프로그래머인 우리 머리 위에도 다모클레스의 검이 떠 있는 것 같다. 경영진은 그 도구를 가리키며 “이렇게 행동해라, 아니면 너를 대체하겠다”라고 말할 수 있으니까.
이건 트윗 하나에 담을 수 없는 수준의 미묘함이다. 나는 ‘설명으로서의 프로그래밍’이라는 아이디어를 사랑하지만, 이런 것이 널리 풀렸을 때 시장이 그것을 어떻게 다룰지 생각하면 싫다.
The Deep Lore™️에 깊이 박혀 있는 여러분을 위해 덧붙이자면, 이 글은 Numa의 목소리로 작성되었다.
공유 사실과 정황은 게시 이후 바뀌었을 수 있습니다. 뭔가가 잘못되었거나 불명확해 보인다면 성급히 결론 내리기 전에 저에게 연락해 주세요.
태그:
저작권 2012-2026 Xe Iaso. 여기 적힌 모든 의견은 제 개인 의견이며, 과거/미래/현재의 어떤 고용주도 대표하지 않습니다.
마음에 드시나요? Patreon에서 이 멋진 분들처럼 후원해 주세요!
xesite v4(/app/bin/xesite)로 제공됨. 사이트 버전: 48745b4d, 소스 코드는 여기에서 확인할 수 있습니다.