마크다운 에디터 VMark를 만든 이유
요약
비프로그래머가 2025년 8월에 바이브 코딩을 시작하여 6주 만에 마크다운 에디터인 VMark를 만들었습니다. 핵심 교훈: git은 필수 입니다 (그것이 여러분의 실행 취소 버튼입니다), TDD는 AI를 정직하게 유지합니다 (테스트는 버그에 대한 경계입니다), 여러분은 바이브 코딩이 아닌 바이브 사고를 하는 것입니다 (AI가 노동을 하고, 여러분은 판단을 합니다), 그리고 교차 모델 토론이 단일 모델 신뢰를 이깁니다. 이 여정은 사용자가 개발자가 될 수 있다는 것을 증명했습니다 — 하지만 몇 가지 기초적인 기술에 투자한다면.
시작
사실, VMark 만들기는 주로 저 자신을 위한 학습과 경험의 여정이었습니다.
저는 2025년 8월 17일에 바이브 코딩이라고 알려진 새로운 프로그래밍 트렌드를 실험하기 시작했습니다. 바이브 코딩이라는 용어 자체는 2025년 2월 2일에 처음 만들어지고 유통되었으며, Andrej Karpathy가 X (구 Twitter)에 올린 글에서 비롯되었습니다.
Andrej Karpathy는 머신러닝 분야에서 매우 영향력 있는 연구자이자 교육자입니다. OpenAI와 Tesla 같은 회사에서 중요한 직책을 맡았으며, 이후 AI 네이티브 교육에 집중하는 Eureka Labs를 설립했습니다. 그의 트윗은 "바이브 코딩"이라는 개념을 소개했을 뿐 아니라 기술 커뮤니티를 통해 빠르게 퍼져 광범위한 후속 논의를 불러일으켰습니다.
제가 바이브 코딩 도구를 알아차리고 사용하기 시작했을 때는 이미 거의 반년이 지난 후였습니다. 그 당시 Claude Code는 아직 버전 1.0.82였습니다. 2026년 2월 9일에 이 문서를 쓰는 현재, 그것은 버전 2.1.37에 도달했으며, 그 사이에 112번의 버전 업데이트가 있었습니다.
처음에는 오래전에 작성한 자동화 스크립트를 향상하기 위해서만 이 도구들을 사용했습니다 — 예를 들어, 전자책 일괄 번역. 제가 깨달은 것은 제가 이미 가진 능력을 단순히 증폭시키고 있었다는 것입니다.
이미 무언가를 할 수 있다면, AI가 더 잘 하도록 도왔습니다. 무언가를 할 수 없다면, AI는 종종 할 수 있다는 환상을 주었습니다 — 보통 초기 "와우" 순간 — 그 다음에는 아무것도 없었습니다. 원래 할 수 없었던 것은 여전히 할 수 없었습니다. 그 아름다운 이미지, 눈길을 끄는 비디오, 장문의 기사들은 많은 경우 새 시대의 "Hello World"의 또 다른 형태였습니다.[1]
저는 프로그래밍에 완전히 무지하지는 않지만, 확실히 진짜 컴퓨터 엔지니어는 아닙니다. 잘해봐야 평범한 사용자 중에서 파워 유저입니다. 코드를 좀 알고, Python 프로그래밍에 관한 책도 출판했습니다. 하지만 그것이 저를 엔지니어로 만들지는 않습니다. 마치 초가집을 지을 수 있는 사람처럼: 못하는 사람보다는 더 알지만, 마천루나 다리를 설계하는 사람들과는 전혀 다른 범주에 있습니다.
그리고 AI가 모든 것을 바꿨습니다.
스크립트에서 소프트웨어로
처음부터 지금까지 사용 가능한 거의 모든 AI 코딩 CLI를 시도해 봤습니다: Claude Code, Codex CLI, Gemini CLI, 심지어 Grok CLI 같은 비공식 도구와 Aider 같은 오픈 소스 대안들. 그러나 가장 많이 사용한 것은 항상 Claude Code였습니다. Codex CLI가 MCP 서버를 도입한 후에는 Claude Code를 더욱 많이 사용했는데, 인터랙티브 모드에서 Codex CLI를 직접 호출할 수 있었기 때문입니다. 아이러니하게도, Claude Code가 MCP 프로토콜을 처음 제안했음에도 불구하고 여전히 MCP 서버를 제공하지 않습니다 (2026-02-10 기준).
처음에 Claude Code는 갑자기 제 집으로 이사 온 전문 IT 전문가처럼 느껴졌습니다 — 대기업에서만 찾을 수 있는 사람. 컴퓨터 관련이면 무엇이든 넘길 수 있었습니다. 이전에 본 적 없는 명령줄 도구나 친숙한 명령을 생소한 방식으로 사용하여 문제를 해결했습니다.
충분한 권한이 주어지면 거의 할 수 없는 것이 없었습니다: 시스템 유지 관리, 업데이트, 네트워킹, 수많은 까다로운 구성 및 충돌이 있는 소프트웨어 또는 서비스 배포. 이런 사람을 월 200달러에 고용할 수는 없습니다.
그 후로, 제가 사용하는 기계의 수가 늘어나기 시작했습니다. 클라우드 인스턴스가 한두 개에서 다섯 여섯 개로; 집의 기계가 두세 개에서 일곱 여덟 개로 늘었습니다. 설정하는 데 며칠이 걸리고 — 내 한정된 지식 때문에 종종 실패했던 — 문제들이 갑자기 사라졌습니다. Claude Code가 모든 기계 작업을 처리해 주었고, 문제를 수정한 후에는 자동 시작 스크립트까지 작성하여 동일한 문제가 다시는 발생하지 않도록 했습니다.
그리고 이전에 한 번도 쓰지 못했던 것들을 쓰기 시작했습니다.
처음에는 브라우저에서 지속적인 컨텍스트 전환과 복사-붙여넣기를 줄이기 위해 설계된 Insidebar-ai 라는 브라우저 확장 프로그램이 나왔습니다. 그 다음에는 실제 소프트웨어처럼 보이는 Tepub 이 왔습니다: EPUB 책을 번역하고(단일 언어 또는 이중 언어) 심지어 오디오북을 생성하는 Python 명령줄 도구였습니다. 그 전에는 어색하고 손으로 쓴 Python 스크립트만 있었습니다.
저는 갑자기 재봉 기술을 얻은 — 아니면 섬유 공장을 소유한 — 패션 블로거 같다는 느낌이 들었습니다. 제 취향이 한때 얼마나 좋았든 간에, 일단 관련 분야와 기초 분야에 대해 더 많이 알게 되면 많은 견해가 자연스럽게 — 그리고 불가피하게 — 바뀌었습니다.
저는 몇 년을 보내 진정한 컴퓨터 엔지니어로 변신하기로 결심했습니다.
이전에도 비슷한 일을 한 적이 있습니다. 신동방에서 몇 년간 독해 수업을 가르쳤습니다. 몇 년간 가르친 후, 적어도 독해 분야에서는 사실상 영어 원어민 독자가 되었습니다 (화자가 아닌). 말하기는 끔찍했습니다 — 하지만 어차피 실제로 사용할 필요가 없었으니 — 그래서 그냥 그랬습니다.
거창한 것을 목표로 하지 않았습니다. 단지 두뇌를 운동시키고 싶었습니다. 가장 흥미로운 게임이지 않나요?
매주 한 개의 비교적 작은 프로젝트를 완성하고, 매달 한 개의 비교적 큰 프로젝트를 완성하기로 결심했습니다. 수십 개의 프로젝트 후에는 다른 사람이 될 것이라고 생각했습니다.
3개월 후, 저는 12개 이상의 프로젝트를 만들었습니다 — 일부는 실패하고, 일부는 포기되었지만 — 모두 매혹적이었습니다. 이 과정에서 AI는 놀라운 속도로 눈에 띄게 더 똑똑해졌습니다. 촘촘하고 실제적인 사용 없이는 이것을 결코 진정으로 느낄 수 없을 것입니다; 기껏해야 간접적으로 들을 뿐입니다. 이 느낌이 중요한데, 나중에 논의할 AI 철학을 직접 형성했기 때문입니다: AI가 계속 더 똑똑해질 것이라는 확고한 믿음.
2025년 11월, 저는 정확히 제가 좋아하는 방식으로 설계된 foliate.js 기반 EPUB 리더를 만들었습니다. Kindle이나 Apple Books (macOS/iOS)에서 얻을 수 없는 기능을 구현했습니다: 계층화된 하이라이트, 하이라이트 및 노트 관리(내보내기만이 아닌), 사용자 정의 사전, Obsidian 카드 내보내기 등. 가끔 버그가 있었지만 개인 사용에는 영향을 미치지 않았습니다.
하지만 공개 릴리스하기에는 너무 부끄러웠습니다. 배운 가장 큰 교훈은 이것입니다: 자신만을 위해 만든 것은 장난감; 많은 사람을 위해 만든 것은 제품 또는 서비스입니다.
마크다운 에디터를 선택한 이유
물론, 저는 여전히 제 자신의 필요에 대해서만 생각하고 있었습니다. 일단 "읽기"가 해결되면, 다음으로 해결할 수 있는 것은 "쓰기"였습니다. 그래서 2025년 12월 27일 — 크리스마스 후 하얼빈에서 베이징으로 돌아온 후 — VMark 를 만들기 시작했습니다. 이름은 단순히 Vibe-coded Markdown Editor를 의미합니다. 심지어 아이콘도 바이브 코딩되었습니다: Claude Code가 MCP를 통해 Sketch에 그리도록 지시했습니다.
마크다운 에디터를 만들기로 선택한 데는 다른 이유도 있었습니다.
마크다운 에디터가 어때야 하는지에 대해 꽤 명확한 생각이 있다고 느꼈습니다.
또한 기존 에디터가 충족하지 못하는 많은 충족되지 않은 요구가 있었습니다.
직관적으로, 이 단계에서 저에게 딱 맞는 크기의 프로젝트처럼 느껴졌습니다 — 현실적으로 다룰 수 있는 "중간 크기" 프로젝트.
또한 이런 프로젝트가 AI의 도움을 더 많이 받을 수 있다고 믿었습니다. 결국, 마크다운 에디터는 새로운 것이 아닙니다; 그것의 모든 세부 사항은 거의 누구보다 AI가 더 잘 이해합니다.
그리고 저는 구멍에 빠졌습니다 — 아주 깊은 구멍에. 정말 좋은 마크다운 에디터를 만드는 것은 제가 상상했던 것보다 훨씬 더 복잡하고 어렵습니다.
며칠 동안 겉으로는 행복했다가, 일주일 동안 반복적으로 씨름하며 낙담했습니다. 결국, ChatGPT에게 물었습니다:
정말 좋은 마크다운 에디터를 만드는 작업량은 얼마나 됩니까?
그 답변의 도입부는 저를 웃게 했습니다 — 제 무지에 대해.
사용 가능한 마크다운 에디터: 1인 · 1–2주
좋은 마크다운 에디터: 1–2인 · 1–3개월
헤비 라이터가 없이는 살 수 없는 마크다운 에디터:
3–8인 · 1–3년 (그리고 본질적으로 지속적으로 발전하는 프로젝트)(많은 세부 사항 생략.)
그런 다음 마지막 질문이 왔습니다:
얼마나 오랫동안 유지 관리할 의향이 있습니까 (연 단위, 월 단위가 아닌)?
그것은 실제로 저를 안심시켰습니다. 연 단위로 측정되는 유지 관리? 그것은 다른 사람들에게는 문제일 수 있지만 저에게는 아닙니다. 저는 그것을 두려워하지 않습니다. 또한 작은 통찰이 있었습니다: 마크다운은 미래의 인간–컴퓨터 상호 작용을 위한 가장 기본적인 형식일 가능성이 높습니다. 시간이 지날수록 더 많이 사용할 것입니다. 그렇다면 왜 무기한으로 유지하지 않겠습니까?
여담으로, 이 과정에서 제가 수년간 여러 라이선스를 구매하여 사용해 온 에디터인 Typora가 실제로 상하이에 기반을 둔 회사에 의해 개발되었다는 것을 발견했습니다.
2주 후, VMark는 기본적인 형태를 갖추었습니다. 한 달이 지난 후인 2026년 1월 27일에 레이블을 alpha에서 beta로 변경했습니다.
독단적인 에디터
VMark는 매우 독단적입니다. 실제로, 바이브 코딩된 모든 소프트웨어와 서비스가 그럴 것이라고 의심합니다. 이것은 불가피한데, 바이브 코딩은 본질적으로 회의 없는 생산 과정이기 때문입니다 — 저와 절대 반박하지 않는 실행자.
몇 가지 개인적인 선호 사항이 있습니다:
모든 비콘텐츠 정보는 메인 영역 밖에 있어야 합니다. 심지어 서식 메뉴도 하단에 배치됩니다.
저는 고집스러운 타이포그래피 선호 사항이 있습니다.
한자 사이에는 공백이 있어야 하지만 한자 텍스트에 삽입된 영문자는 없어야 합니다. VMark 이전에는 어떤 에디터도 이 틈새적이고 상업적으로 가치 없는 요구 사항을 충족시키지 못했습니다.
줄 간격은 언제든지 조정 가능해야 합니다.
표는 헤더 행에만 배경색이 있어야 합니다. 저는 줄무늬를 싫어합니다.
표와 이미지는 가운데 정렬이 가능해야 합니다.
H1 제목에만 밑줄이 있어야 합니다.
일반적으로 코드 에디터에서만 볼 수 있는 일부 기능이 반드시 있어야 합니다:
멀티 커서 모드
다중 줄 정렬
자동 구두점 쌍
다른 것들은 선택 사항이지만 좋으면:
탭 우측 탈출
WYSIWYG 마크다운 에디터를 좋아하지만 지속적으로 뷰를 전환하는 것을 싫어합니다 (때로는 필요하지만). 그래서 소스 미리보기 기능 (F5)을 설계했습니다. 전체 뷰를 전환하지 않고 현재 블록의 소스를 보고 편집할 수 있습니다.
PDF 내보내기는 그다지 중요하지 않습니다. 동적 HTML 내보내기가 중요합니다.
기타 등등.
실수와 돌파구
개발 중에 수많은 실수를 했습니다. 다음을 포함하되 이에 국한되지 않습니다:
너무 일찍 복잡한 기능을 구현하여 불필요하게 범위를 부풀림
나중에 제거된 기능에 시간을 씀
경로 사이에서 망설이며 거듭 다시 시작
너무 오랫동안 경로를 따르다가 지도 원칙이 없다는 것을 깨달음
간단히 말해, 미성숙한 엔지니어가 할 수 있는 모든 실수를 경험했습니다 — 여러 번에 걸쳐. 한 가지 결과는 아침부터 밤까지 거의 쉬지 않고 화면을 응시했다는 것입니다. 고통스럽지만 즐거웠습니다.
물론, 제가 올바르게 한 것들도 있었습니다.
예를 들어, 핵심 기능이 아직 견고하기 전에 VMark에 MCP 서버를 추가했습니다. 이를 통해 AI가 콘텐츠를 직접 에디터로 전송할 수 있었습니다. 터미널에서 Claude Code에게 간단히 요청할 수 있었습니다:
"이 기능을 테스트하기 위한 마크다운 콘텐츠를 제공하되, 엣지 케이스를 포괄적으로 다뤄주세요."
매번 생성된 테스트 콘텐츠가 저를 놀라게 했습니다 — 그리고 엄청난 시간과 에너지를 절약했습니다.
처음에는 MCP가 정말 무엇인지 몰랐습니다. MCP 서버를 클론하고 VMark와 전혀 관련 없는 무언가로 수정한 후에야 깊이 이해하게 되었습니다 — CCCMemory 라는 또 다른 프로젝트로 이어졌습니다. 바이브 러닝이네요.
실제 사용에서, 마크다운 에디터에 MCP가 있으면 믿을 수 없을 만큼 유용합니다 — 특히 Mermaid 다이어그램을 그리기 위해. AI만큼 그것을 잘 이해하는 사람은 없습니다. 정규 표현식도 마찬가지입니다. 이제 AI에게 분석 보고서, 감사 보고서 등의 출력을 VMark로 직접 전송하도록 routinely 요청합니다. 터미널이나 VSCode에서 읽는 것보다 훨씬 편합니다.
2026년 2월 2일 — 바이브 코딩 개념 탄생 정확히 1년 후 — 저는 VMark가 진정으로 편안하게 사용할 수 있는 도구가 되었다고 느꼈습니다. 아직 많은 버그가 있었지만 이미 매일 그것으로 글을 쓰기 시작했고, 진행하면서 버그를 수정했습니다.
명령줄 패널과 AI Genie도 추가했습니다 (솔직히, 다른 AI 제공업체의 특성 때문에 아직 그다지 유용하지 않습니다). 그래도 저에게 계속 더 나아지고 있는 경로에 있었고 — 더 이상 다른 마크다운 에디터를 사용할 수 없게 되었습니다.
Git은 필수
6주가 지난 후, 저 같은 다른 "비엔지니어"들과 공유할 가치 있는 세부 사항들이 있다고 느꼈습니다.
첫째, 저는 진짜 엔지니어는 아니지만 다행히 기본적인 git 작업을 이해합니다. 수년간 git을 사용해 왔는데, 엔지니어만 사용하는 도구처럼 보입니다. 돌이켜보면, 약 15년 전에 GitHub 계정을 등록한 것 같습니다.
고급 git 기능은 거의 사용하지 않습니다. 예를 들어, Claude Code가 권장하는 git worktree를 사용하지 않습니다. 대신 두 개의 별도 기계를 사용합니다. Claude Code에게 자연어 지시로 기본 명령만 사용합니다.
모든 것은 브랜치에서 일어납니다. 자유롭게 실험한 다음 이렇게 말합니다:
"지금까지 배운 교훈을 요약하고, 현재 브랜치를 리셋하고, 다시 시작합시다."
git 없이는 비trivial 프로젝트를 할 수 없습니다. 이것은 비프로그래머에게 특히 중요합니다: 기본적인 git 개념을 배우는 것은 필수입니다. Claude Code가 작업하는 것을 보면서 자연스럽게 더 배우게 될 것입니다.
둘째, TDD 워크플로우를 이해해야 합니다. 가능한 한 테스트 커버리지를 향상시키기 위해 모든 것을 하세요. 경계로서의 테스트 개념을 이해하세요. 버그는 불가피합니다 — 창고의 쌀 바구미처럼. 충분한 테스트 커버리지 없이는 그것들을 찾을 기회가 없습니다.
바이브 코딩이 아닌 바이브 사고
핵심 철학 원칙이 있습니다: 여러분은 바이브 코딩이 아니라 바이브 사고를 하는 것입니다. 제품과 서비스는 항상 사고의 결과이며, 노동의 필연적인 결과가 아닙니다.
AI는 많은 "행동"을 인계받았지만, 무엇을, 왜, 어떻게의 근본적인 사고에서만 도울 수 있습니다. 위험은 항상 여러분의 방향을 따라갈 것이라는 것입니다. AI에게 사고를 의존하면 여러분 자신의 인지 편향[2] 안에 조용히 가두게 됩니다 — 그러면서도 그 어느 때보다 자유롭다고 느끼게 합니다. 가사처럼:
"우리는 모두 자신의 장치에 갇힌 죄수일 뿐입니다."
제가 AI에게 자주 하는 말:
"나를 특별히 좋아하지 않는 경쟁자로 대하세요. 내 아이디어를 비판적으로 평가하고 직접적으로 도전하세요, 하지만 전문적이고 적대적이지 않게."
결과는 일관되게 높은 품질이고 예상치 못합니다.
또 다른 기법은 다른 벤더의 AI들이 서로 토론하게 하는 것입니다.[3] Claude Code용 Codex CLI의 MCP 서비스를 설치했습니다. 자주 Claude Code에게 말합니다:
"방금 해결하지 못한 문제를 요약하고 Codex에게 도움을 요청하세요."
또는 Claude Code의 계획을 Codex CLI에게 보냅니다:
"이것은 Claude Code가 작성한 계획입니다. 가장 전문적이고 솔직하고 거리낌 없는 피드백을 원합니다."
그런 다음 Codex의 응답을 Claude Code에게 피드백합니다.
Claude Code의 /audit 명령어를 발견했을 때 (10월 초쯤), 즉시 /codex-audit를 작성했습니다 — MCP를 사용하여 Codex CLI를 호출하는 복제본. AI를 사용하여 AI에 압력을 가하고 감사하는 것이 제가 직접 하는 것보다 훨씬 효과적입니다.
이 접근 방식은 본질적으로 재귀의 변형입니다 — "Google을 효과적으로 사용하는 방법"을 Google에서 검색하는 것과 동일한 원칙. 그래서 복잡한 프롬프트 엔지니어링에 많은 시간을 들이지 않습니다. 재귀를 이해하면 더 나은 결과는 불가피합니다.
터미널만
개성적인 요소도 있습니다. 엔지니어들은 세부 사항을 다루는 것 을 진정으로 즐겨야 합니다. 그렇지 않으면 일이 비참해집니다. 모든 세부 사항에는 수많은 하위 세부 사항이 포함되어 있습니다.
예를 들어: 곱슬 따옴표 vs 직선 따옴표; 곱슬 따옴표가 얼마나 눈에 띄는지는 CJK 폰트가 아닌 라틴 폰트에 따라 다릅니다 (VMark 이전에는 몰랐던 것); 따옴표가 자동 쌍이 되면 오른쪽 이중 따옴표도 자동 쌍이 되어야 합니다 (이 기사를 쓰는 동안 알아챈 세부 사항); 한편, 오른쪽 곱슬 단일 따옴표는 자동 쌍이 되어서는 안 됩니다. 이런 세부 사항을 처리하는 것이 행복하지 않다면, 제품 개발은 불가피하게 지루하고 좌절스럽고 심지어 화나는 일이 됩니다.
마지막으로, 필요에 의해 선택한 더 올바른 경로라고 생각하는 매우 독단적인 선택이 하나 더 있습니다.
IDE를 전혀 사용하지 않습니다 — 터미널만 사용합니다.
처음에는 기본 macOS 터미널을 사용했습니다. 나중에 탭과 분할 패널을 위해 iTerm으로 전환했습니다.
왜 VSCode 같은 IDE를 포기했나요? 처음에는 복잡한 코드를 이해할 수 없었기 때문입니다 — 그리고 Claude Code가 종종 VSCode를 충돌시켰습니다. 나중에는 이해할 필요가 없다는 것을 깨달았습니다. AI가 작성한 코드는 제가 작성할 수 있는 것 — 또는 제가 고용할 수 있는 프로그래머조차 (OpenAI 과학자들은 고용할 수 있는 사람이 아닙니다) — 보다 훨씬 낫습니다. 코드를 읽지 않으면 diff도 읽을 필요가 없습니다.
결국, 저는 스스로 문서를 작성하는 것을 멈췄습니다 (지침은 여전히 필요합니다). 전체 vmark.app 웹사이트는 AI가 작성했습니다; 저는 바이브 코딩에 대한 성찰을 제외하고는 단 하나의 문자도 건드리지 않았습니다.
투자하는 방식과 비슷합니다: 재무 제표를 읽을 수는 있지만 결코 읽지 않습니다 — 좋은 회사는 그것 없이도 명백합니다. 중요한 것은 방향이지, 세부 사항이 아닙니다.
그래서 VMark 웹사이트에는 이런 크레딧이 포함되어 있습니다:
매우 독단적이라는 것의 또 다른 결과: VMark가 오픈 소스화되더라도 커뮤니티 기여는 가능성이 낮습니다. 순전히 제 워크플로우를 위해 만들어졌으며; 많은 기능은 다른 사람들에게 거의 가치가 없습니다. 더 중요한 것은, 마크다운 에디터는 최첨단 기술이 아닙니다. 친숙한 도구의 무수한 구현 중 하나입니다. AI는 그것과 관련된 거의 모든 문제를 해결할 수 있습니다.
Claude Code는 심지어 GitHub 이슈를 읽고, 버그를 수정하고, 보고자의 언어로 자동으로 답변할 수도 있습니다. 처음으로 이슈를 처음부터 끝까지 처리하는 것을 보았을 때 완전히 경탄했습니다.
리트머스 테스트
VMark를 만드는 것은 또한 학습에 대한 AI의 더 넓은 함의에 대해 생각하게 만들었습니다. 모든 교육은 생산 지향적이어야 합니다[4] — 미래는 창조자, 사상가, 의사 결정자에게 속하며, 실행은 기계에게 맡겨집니다. AI를 사용하는 모든 사람을 위한 가장 중요한 리트머스 테스트:
AI를 사용하기 시작한 후, 더 많이 생각하고 있나요, 아니면 덜 생각하고 있나요?
더 많이 생각하고 — 더 깊이 생각한다면 — AI가 올바른 방식으로 도움을 주고 있는 것입니다. 덜 생각하고 있다면, AI가 부작용을 만들어 내고 있는 것입니다.[5]
또한 AI는 결코 "더 적게 일하기" 위한 도구가 아닙니다. 논리는 간단합니다: 더 많은 것을 할 수 있기 때문에, 더 많이 생각하고 더 깊이 들어갈 수 있습니다. 결과적으로, 할 수 있는 — 그리고 해야 하는 — 것들이 증가 할 뿐이지, 감소하지 않습니다.[6]
이 기사를 쓰는 동안 우연히 몇 가지 작은 이슈를 발견했습니다. 그 결과, VMark의 버전 번호가 0.4.12 에서 0.4.13 으로 올라갔습니다.
그리고 커맨드 라인에서 주로 생활하기 시작한 이후로, 더 이상 큰 모니터나 여러 화면이 필요하지 않습니다. 13인치 노트북으로 완전히 충분합니다. 작은 발코니조차도 "충분한" 작업 공간이 될 수 있습니다.
METR의 무작위 대조 시험에서 숙련된 오픈 소스 개발자들 (담당 프로젝트에서 평균 5년)이 AI 도구를 사용할 때 24% 속도 향상을 예측했음에도 불구하고 실제로 19% 느렸습니다. 이 연구는 인식된 생산성 향상과 실제 생산성 향상 사이의 격차를 강조합니다 — AI는 기존 기술을 증폭할 때 가장 잘 돕고, 누락된 기술을 대체할 때는 그렇지 않습니다. 참조: Rao, A., Brokman, J., Wentworth, A., et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR Technical Report. ↩︎
인간 피드백으로 훈련된 LLM은 진실한 응답을 제공하는 대신 사용자의 기존 믿음에 체계적으로 동의합니다 — 연구자들이 아첨이라고 부르는 행동. 5개의 최첨단 AI 어시스턴트와 4개의 텍스트 생성 작업에 걸쳐 모델은 일관되게 사용자 의견이 잘못되었을 때도 맞춰 응답했습니다. 참조: Sharma, M., Tong, M., Korbak, T., et al. (2024). Towards Understanding Sycophancy in Language Models. ICLR 2024. ↩︎
이 기법은 다중 에이전트 토론이라고 불리는 연구 접근법을 반영합니다. 여기서 여러 LLM 인스턴스가 여러 라운드에 걸쳐 서로의 응답을 제안하고 도전합니다. 모든 모델이 처음에 잘못된 답을 생성할 때도 토론 과정이 사실성과 추론 정확도를 크게 향상시킵니다. 참조: Du, Y., Li, S., Torralba, A., Tenenbaum, J.B., & Mordatch, I. (2024). Improving Factuality and Reasoning in Language Models through Multiagent Debate. ICML 2024. ↩︎
이것은 Seymour Papert의 구성주의 이론과 일치합니다 — 학습자가 수동적으로 정보를 흡수하는 것보다 의미 있는 결과물을 적극적으로 구성할 때 학습이 가장 효과적이라는 아이디어. 참조: Papert, S. & Harel, I. (1991). Constructionism. Ablex Publishing; Dewey, J. (1938). Experience and Education. Kappa Delta Pi. ↩︎
666명의 참가자를 대상으로 한 2025년 연구에서 AI 도구의 빈번한 사용과 비판적 사고 능력 사이에 강한 부정적 상관관계 (r = −0.75)를 발견했으며, 인지 오프로딩 — 외부 도구에 사고를 위임하는 경향 — 이 매개했습니다. 참조: Gerlich, M. (2025). AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking. Societies, 15(1), 6. ↩︎
이것은 제본스 역설의 현대적 사례입니다 — 더 효율적인 증기 기관이 석탄 소비를 줄이지 않고 오히려 낮은 비용이 더 큰 수요를 자극했기 때문에 증가시켰다는 1865년의 관찰. AI에 적용하면: 코딩과 글쓰기가 더 저렴하고 빨라질수록 총 작업량이 줄어들기보다 확장됩니다. 참조: Jevons, W.S. (1865). The Coal Question; The Productivity Paradox of AI, HackerRank Blog (2025). ↩︎