오디오 대본으로 따라가는 AI 코딩 작업 흐름의 분기점

23화 AI 코딩 작업 흐름의 분기점

방송 노트

2026년 5월, 세 가지 신호가 같은 주에 도착했습니다. Garry Tan이 공개한 gstack, Karpathy가 No Priors에서 설명한 개발 방식, OpenClaw 확산. 놀리지가 이 세 신호의 교차점을 32분 안에 정리합니다.

다룬 주제

• gstack의 23 슬래시 명령 중 가장 자주 쓰이는 5개: 명세 점검, 실행 확인, 화면 캡처, 직접 사용 점검, 코드 검토
• Karpathy 발언은 무엇을 뜻하나
• OpenClaw 확산 속도와 기존 개발 도구 생태계 비교 (10년 누적)
• 임베디드·안전 중요도가 높은·레거시 영역의 한계
• '1인 20인 팀' 명제와 Y Combinator W26 배치의 통계

다음 화 예고

다음 주 화요일 — JetBrains vs GitHub의 '슬래시 명령 표준화' 충돌 시나리오와 한국 개발자 도구 시장의 진입 가능성.

---

스크립트 (5턴)

장면 1 — 보다 (진행, 0:00~2:35)

안녕하세요, 놀리지 23화입니다. 오늘은 한 주의 신호 중에서도 세 개가 동시에 같은 방향을 가리킨 주입니다. 첫째는 Y Combinator CEO Garry Tan이 직접 공개한 gstack. 본인이 운영하는 1인 작업 흐름 도구입니다. 둘째는 Andrej Karpathy가 No Priors 팟캐스트에서 "직접 코드를 거의 치지 않는다"라고 던진 인용. 셋째는 OpenClaw가 GitHub에서 빠르게 확산된 일. 우리는 단순한 도구 출시가 아니라, 개발 방식이 실제로 바뀌고 있는지를 검증하려고 합니다. 정 박사님, gstack의 구조부터 시작해 주실 수 있을까요?

장면 2 — 정 박사 (전문가, 2:35~8:50)

네, gstack을 한 줄로 정리하면 "AI 코딩 도구가 에디터에서 슬래시 명령 셸로 무게중심이 옮겨간 첫 공개 사례"입니다. 23개 명령이 있는데, 핵심은 다섯 개예요. 명세 점검은 작업 의도를 7~10점 척도로 평가해서, 7점 미만이면 본문 차단을 합니다. 즉 '코드 짜기' 이전에 '의도 검증'을 강제하죠. 실행 확인은 변경된 앱을 실제로 띄워서 동작 확인. 화면 캡처는 화면 결과의 시각 캡처. 직접 사용 점검은 본인이 만든 제품을 본인이 쓰는 시나리오 자동화. 코드 검토는 변경 내용 자동 검토입니다. 이게 왜 중요하냐면 — Copilot이나 Cursor가 만든 패러다임은 '코드 생성'이었습니다. 그런데 gstack은 명확히 '코드 검증'에 무게중심을 둡니다. 생성은 LLM이 하고, 검증을 위한 명령어 인프라를 사람이 설계한다, 이 분업이 새로운 거예요.

장면 3 — 우 PM (실무자, 8:50~14:40)

1인 소프트웨어 서비스를 운영하는 입장에서 가장 인상적인 건 Karpathy의 그 한 마디였어요. "원하는 결과를 설명하면 모델이 코드를 작성한다. 나는 검토하고, 고치고, 방향을 잡는 쪽에 더 많은 시간을 쓴다." 처음 들었을 땐 '시니어 자랑'으로 들렸는데, 며칠 적용해 보니 다른 얘기더라고요. 그가 안 친다고 한 건 글자 키입니다. 키보드에서 무게중심이 글자 키에서 명령어 키로 옮겨갔다, 이게 핵심이에요. 제가 5월 한 달간 측정해 봤습니다 — 제가 직접 친 코드 라인 수는 평균 일 41라인에서 일 8라인으로 줄었어요. 대신 명령어를 입력한 횟수는 일 평균 19회에서 일 평균 47회로 늘었습니다. '타이핑이 줄었다'가 아니라 '타이핑의 종류가 바뀌었다'가 정확한 표현이에요. 그래서 우리 입장에서 새로 필요한 건 '슬래시 명령 가이드라인'입니다. 어떤 작업은 AI 자율, 어떤 작업은 휴먼 머지 필수, 이 경계가 매우 빨리 필요해질 거예요.

장면 4 — 한 변호사 (게스트, 14:40~21:10)

좋은 포인트입니다. 다만 거버넌스 쪽에서 보면 몇 가지 우려가 생깁니다. 첫째는 시니어의 검증력 출처. 우 PM님이 말씀하신 대로 '명령어로 일한다'는 게 가능한 이유는, 그 사람이 이미 글자 키 시대를 거쳐 검증력을 쌓았기 때문이에요. 그런데 처음부터 '명령어로 일하기'만 배운 주니어가 5년 뒤 시니어가 됐을 때, AI 출력의 결함을 알아차릴 수 있을까요? 이건 'AI 코딩 시대의 도제 시스템'이 새로 필요해진다는 뜻입니다. 둘째는 책임 소재. 임베디드, 의료, 금융 같은 안전 중요도가 높은 영역에서 AI가 짠 코드가 사고를 내면, 책임은 누가 지죠? 슬래시 명령 작업 흐름는 효율적이지만 '감사 기록'을 강제하지 않으면 위험합니다. 다행히 gstack의 코드 검토는 검토 강도를 명시하니까, 이걸 감사 로그로 남기는 패턴이 이번 분기 안에 표준화돼야 한다고 봅니다. 이번 분기가 거버넌스 윈도우입니다.

장면 5 — 보다 (진행, 21:10~32:04) — 마무리

네, 세 분 말씀을 정리하면 이렇습니다. 첫째, gstack의 23 슬래시 명령은 '코드 생성'에서 '코드 검증'으로 무게중심이 옮겨간 첫 공개 사례다. 둘째, Karpathy의 '코드 안 친다'는 글자 키에서 명령어 키로의 이동을 표현한 것이지, 일을 안 한다는 게 아니다. 셋째, OpenClaw 확산은 시장이 이미 '터미널 + AI'를 선택했다는 강력한 신호다. 넷째, 임베디드·레거시는 여전히 다르고, 시니어의 검증력 출처와 책임 소재라는 두 가지 거버넌스 이슈가 이번 분기 안에 풀려야 한다. 그래서 이번 주 의사결정 체크리스트는 세 가지로 정리합니다 — 즉시 OpenClaw 또는 Claude Code로 '버그 1개 → AI 패치 → AI 검증' 사이클 한 번 돌리기, 팀의 슬래시 명령 가이드라인 초안 만들기, '의도 작성량'을 새 핵심 지표로 추가하기. 자세한 본문은 놀리지 블로그에 정리돼 있고, 다음 주에는 JetBrains와 GitHub의 슬래시 명령 표준화 전쟁 가능성을 다룹니다. 들어 주셔서 감사합니다.

---

이 에피소드는 놀리지 공개 아카이브에서 음성 + 본문 + 챕터 타임스탬프를 함께 확인할 수 있습니다. 화자 4종: 01_charismatic / 07_cold_detective / 05_wise / 02_elegant.