챕터 1 — "직접 코드를 거의 치지 않는다"가 무슨 뜻인가
2026년 5월의 셋째 주에는 이상한 일이 벌어졌다. 한 주에 세 가지 신호가 같은 방향을 가리켰다는 점이 이상한 게 아니라, 그 신호들이 이미 시장이 결정한 사실을 뒤늦게 공식화하는 데 가까웠다는 점이 이상했다.
첫 번째 신호는 Garry Tan이다. Y Combinator의 CEO이자, 한때 본인이 직접 코딩하던 시절의 흔적을 여전히 트위터에 남기는 사람. 그가 5월 22일 자신의 1인 헤드리스 QA 도구 gstack을 공개했다. 도구 자체보다 흥미로운 건 도구의 구조다. 에디터가 없다. 자동완성도 없다. 대신 23개의 슬래시 명령이 있다.
가장 자주 인용되는 다섯 개를 보면, 이 도구가 어떤 사람을 위해 설계됐는지가 명확해진다.
명세 점검은 작업의 의도를 7점에서 10점 척도로 평가한다. 7점 미만이면 본문 자체를 차단한다. 다시 말해, 품질이 의심되는 작업은 시작도 안 한다. 이런 게이트는 사람이 의식적으로 하기 어려운 일이다. 인간은 일단 시작하고 보는 본능이 있다. 그래서 자동화가 필요하다.
실행 확인은 변경된 코드를 실제로 띄워서 동작을 확인한다. 'PR이 통과한다'와 '실제로 동작한다'를 분리하는 것. 이 둘 사이의 간극을 깨달아 본 사람이라면 이 한 줄이 얼마나 큰 의미인지 안다.
화면 캡처는 화면 변경 결과를 시각적으로 캡처한다. 코드 리뷰의 절반은 시각 확인이다. PR 설명에 스크린샷을 안 넣어 본 시니어가 어디 있겠는가. 이게 자동화되는 순간, 리뷰 사이클이 3배 빨라진다.
직접 사용 점검은 본인이 만든 제품을 본인이 직접 쓰는 시나리오를 자동화한다. "내 제품을 내가 안 쓰면 누가 쓰나"라는 명제를 인프라로 만든 것. Garry Tan이 가장 강조한 명령이기도 하다.
코드 검토는 현재 변경 내용을 자동으로 검토한다. 검토 강도를 낮음에서 높음까지 선택할 수 있고, 높은 강도 모드는 의심스러운 부분까지 모두 짚는다. 휴먼 리뷰 전 첫 번째 거름망이다.
이 다섯 개 명령의 공통점은 무엇인가. 모두 '코드 생성'이 아니라 '코드 검증'에 관한 일이라는 점이다. GitHub Copilot의 첫 패러다임은 명확했다 — 자동완성과 자동생성. 그러나 gstack은 그 패러다임을 살짝 비틀어, 생성은 LLM이 알아서 하고, 사람은 검증 인프라를 설계한다는 분업을 제안한다.
여기서 두 번째 신호가 등장한다. Andrej Karpathy의 No Priors 인터뷰. 2026년 3월에 녹음됐고, 5월 셋째 주에 클립이 다시 소셜에서 회자됐다. 그가 던진 한 마디는 이렇다.
"원하는 결과를 설명하면 모델이 코드를 작성한다. 나는 검토하고, 고치고, 방향을 잡는 쪽에 더 많은 시간을 쓴다."
이 인용을 '시니어 자랑'으로 읽는 건 잘못이다. Karpathy가 말한 건 자신이 일을 안 한다는 게 아니다. 그가 직접 키보드로 입력하는 글자의 종류가 바뀌었다는 것이다. 글자 키에서 명령어 키로, 함수 정의에서 시스템 의도 기술로, 'def' 같은 키워드에서 'review/correct/steer' 같은 동작으로 무게중심이 이동했다는 의미다.
이게 왜 중요한가. 우리가 가진 직업의 정의가 도구에 묶여 있기 때문이다. '개발자'라는 직업은 30년 동안 'IDE 앞에 앉아 코드를 친다'는 행위와 단단히 결합돼 있었다. 그런데 만약 그 행위가 한 사람의 일과 시간의 10%로 줄어든다면, 나머지 90%는 무엇인가. Karpathy의 답은 단순하다 — 검토하고, 교정하고, 방향을 잡는 일. 검토하고, 교정하고, 조타한다.
세 번째 신호는 OpenClaw다. Claude Code의 공개형 소프트웨어 복제로 알려진 이 프로젝트는 5월 24일 GitHub에서 빠른 확산 스타 수를 기록했다. 비교 좌표를 보면 이 숫자의 의미가 명확해진다. VS Code의 GitHub 스타 수는 10년 누적 165,000개다. OpenClaw는 출시 6개월 만에 그 절대치를 넘어섰다.
이런 일은 자주 일어나지 않는다. 시장이 명확하게 "이쪽 방향이 맞다"라고 표를 던지는 순간이다. 그리고 OpenClaw의 핵심 화면는 — 에디터가 아니다. 터미널이다. 사람이 자연어로 의도를 던지면 AI가 코드를 짜고, 사람이 다시 자연어로 검증을 요청한다.
이 세 신호를 놀리지는 'AI 코딩의 개발 방식이 바뀌는 전환점'이라 부른다. 워드프레스가 나왔을 때도 마케팅은 "누구나 블로그를 만들 수 있다"였다. 그런데 진짜 가치는 운영 인프라와 플러그인 생태계에서 나왔다. 지금 AI 코딩 시장도 마찬가지다. "AI가 코드를 짠다"는 마케팅 문구 뒤에서, 진짜 인프라는 검증 자동화의 슬래시 명령 표준이 되고 있다.
물론 모든 코드가 이 패턴에 맞는 건 아니다. 임베디드와 안전 중요도가 높은 시스템은 다르다. 항공기, 의료 기기, 금융 코어는 여전히 인간의 검토가 필수다. 레거시 코드도 다르다. 20년 된 코드 묶음의 '왜 이렇게 짰는가'는 코드에 없을 때가 많고, AI는 그걸 추측만 할 수 있다.
그러나 가장 까다로운 우려는 다른 데 있다. 시니어의 검증력이 어디서 오는가라는 질문이다. Karpathy가 "코드를 안 친다"라고 말할 수 있는 건, 그가 이미 글자 키 시대를 충분히 거쳤기 때문이다. 그의 검증력은 직접 코드를 친 시간에서 나온다. 그렇다면 처음부터 '명령어로 일하기'만 배운 주니어가 10년 뒤 시니어가 됐을 때, AI 출력의 결함을 알아차릴 수 있을까. 이건 AI 코딩 시대의 새로운 도제 시스템이 필요해진다는 신호다.
이번 챕터의 결론은 두 가지다. 첫째, '에디터에서 코드를 친다'는 행위가 더는 개발의 본진이 아니다. 본진은 의도 기술과 검증으로 옮겨가는 중이다. 둘째, 이번 분기가 거버넌스 윈도우다. 슬래시 명령 작업 흐름의 감사 기록 표준, 시니어의 검증력을 어떻게 기를지에 관한 도제 체계, 그리고 안전 중요도가 높은 영역의 예외 규칙 — 이 세 가지를 이번 분기 안에 정리하지 못하는 팀은, 6개월 뒤 따라잡기 어려워진다.
다음 챕터에서는 JetBrains와 GitHub의 '슬래시 명령 표준화 전쟁' 가능성을, 그리고 한국 개발자 도구 시장이 이 흐름에 어떻게 진입할 수 있는지를 다룬다.
— 놀리지 위클리 다이제스트 2026-W22, Midnight Ink 호. 챕터 2~5는 EPUB / KDP / Ridi 정식판에서 만나실 수 있습니다.