시리즈의 마지막 편입니다. Claude Code 의 /model·opusplan·서브에이전트 모델 고정·effort, Codex 의 /model·config.toml 프로파일·plan_mode_reasoning_effort·서브에이전트 모델 같은 실제 전환 수단을 정리하고, 언제 한 칸 올리고 내릴지의 에스컬레이션 규칙, 구독 한도를 일주일 단위로 배분하는 법, 팀 단위 거버넌스, 그리고 한 장짜리 암기표로 마무리합니다.

사다리의 아래쪽을 다룹니다. Opus 5 와 GPT-5.6 Sol 이 2026년 여름 이후 구현 단계의 기본값이 된 가격 구조, Sonnet 5 와 Terra 가 충분해지는 조건, Haiku 4.5 와 Luna 가 맡는 읽기·테스트·문서·커밋 같은 일, 낮은 티어에 effort 를 올려 쓰는 요령과 그 반론, 그리고 아래 티어의 실패 모드(코너 커팅, 컨텍스트 한계, 서브에이전트 지원 여부)를 막는 방법을 정리합니다.

Claude Fable 5.1 과 GPT-6 Astra 같은 고가 티어를 써야 하는 네 자리(계획·설계, 모호한 문제와 난제 디버깅, 위험한 변경의 리뷰, 장시간 자율 작업)와 쓰면 안 되는 자리를 공식 문서·실측·커뮤니티 증언으로 가립니다. 고가 모델을 상시 실행자가 아니라 “부르는” Advisor 패턴의 실측 수치, 주간 한도 50% 규칙, Astra 를 medium 에서 시작하라는 실사용 조언까지 다룹니다.

바이브 코딩 세션을 탐색·계획·구현·디버깅·리뷰·정리의 여섯 단계로 나누고, 단계마다 토큰이 소비되는 모양과 실수의 대가가 어떻게 다른지 살핍니다. 그 위에 Anthropic·OpenAI 공식 문서, 테크블로거, Hacker News·X 실사용자가 각 단계에 권하는 티어를 한 표로 모으고, “항상 최고” 와 “공격적으로 낮춰라” 두 진영이 어디서 갈리는지 정리합니다.

Claude Code 의 Fable·Opus·Sonnet, Codex 의 Astra·Sol·Terra 세 티어를 작업 단계에 따라 바꿔 쓰는 전략을 다루는 5부작의 첫 편입니다. 2026년 9월 기준 공식 가격표를 검증하고, “토큰 단가” 와 “작업당 비용” 이 왜 다른지, effort 와 프롬프트 캐시가 모델 티어보다 큰 비용 레버인 이유를 Anthropic·OpenAI 공식 문서와 실측 자료로 정리합니다.

서울대 이재욱 교수 인터뷰에 대한 반론을 2026년 최신 자료로 재검증합니다. 무너진 반론 하나를 먼저 밝히고, 속도가 새는 곳, 격차의 진짜 원인, Naur와 Bainbridge라는 두 사각지대를 다룹니다.

서울대 이재욱 교수 인터뷰의 후반부 — 학생이 “중간 배달원"이 되는 문제, 컴공에 가야 하는 이유, 미래 개발자의 안목, 비전공자를 위한 조언 — 을 학습과학과 고용 데이터로 검증합니다.

서울대 이재욱 교수의 “코딩도 과제도 AI가 다 하는 시대” 인터뷰를 챕터별로 정리하고, 각 주장에 대한 외부 근거를 붙여 검증합니다. 1부는 코딩 현장의 변화, 코드 작성 자동화, 바이브 코딩의 한계를 다룹니다.

에이전트가 코드를 대신 쓰는 시대에 어떤 개발방법론이 살아남고 어떤 것이 의미를 잃었는지, Kent Beck, Birgitta Böckeler, Simon Willison 등이 2025-2026년에 남긴 1차 자료를 바탕으로 정리합니다.

2025년 8월, AI 코딩 시대의 5가지 잠재적 위험을 정리한 글을 썼습니다. 7개월이 지난 지금, AI agent의 코딩 능력은 비약적으로 발전했고 개발자들의 의존도는 비교할 수 없을 만큼 높아졌습니다. 당시 제기했던 우려들을 다시 꺼내 들고, 여전히 유효한 것과 퇴색된 것, 그리고 새롭게 등장한 그림자들을 짚어봅니다.

진 킴(Gene Kim)과 스티브 예지(Steve Yegge)가 집필중인 책, ‘VIBE CODING: BUILDING PRODUCTION-GRADE SOFTWARE WITH GENAI, CHAT, AGENTS, AND BEYOND’ 의 현재까지 공개된 목차와 서문 내용을 알아봅니다.

바이브 코딩은 요즘 소프트웨어 개발의 시대정신일지 모르지만, AI와 함께 바이브를 타는 것이 늘 좋은 것만은 아닙니다. 다음은 지나치게 낙관적인 바이브 코더들이 실패할 수 있는 9가지 방법입니다.

최근 증강 코딩을 사용하여 B+ 트리 라이브러리를 구축하려는 야심 찬 프로젝트에서 좋은 마무리를 지었습니다. 그 결과물은 BPlusTree3 - Rust 및 Python으로 구현된 성능 경쟁력이 있고, 어쩌면 프로덕션에 즉시 사용 가능한 구현입니다. 저는 친구와 앉아 저의 이야기를 나누고 GenAI 시대의 프로그래밍 미래에 대해 무엇을 시사하는지 생각해 보았습니다.

Claude, Gemini, GitHub Copilot과 같은 LLM(거대 언어 모델) 기반 코딩 도구들은 이제 단순히 코드 스니펫을 자동 완성해주는 수준을 넘어, 우리의 생각을 논리적으로 설명하면 프로젝트 전체의 구조를 짜고 방대한 양의 코드를 순식간에 만들어냅니다. 생산성의 혁신이라 부를 만한 이 변화는 분명 경이롭습니다. 하지만 이 강력한 도구에 과도하게 의존하기 시작하면서, 우리는 이전에 겪어보지 못한 새로운 종류의 문제들에 직면하고 있습니다. 밝은 빛이 강할수록 그림자도 짙어지는 법입니다. 이 글에서는 LLM 기반 코딩에 대한 의존이 개발자 개인과 팀에 미칠 수 있는 5가지 잠재적 위험을 심도 있게 다뤄보고자 합니다.

이 글에서는 LLM을 활용한 Vibe-Coding 시대에 Go 언어가 가지는 장점들을 알아봅니다.

서버가 과부하되었다는 소식이 들려왔습니다. 사람들은 왜 Gemini CLI에 그렇게 열광하는 걸까요? 우리는 이미 웹과 데스크톱에서 사용할 수 있는 ChatGPT와 Claude, 그리고 Cursor와 Windsurf 같은 코딩 AI 도구, 심지어 Lovable과 V0 같은 바이브 코딩 도구까지 가지고 있습니다. 터미널 기반의 새로운 CLI 기반 AI가 이 시장에 어떤 영향을 미칠 수 있을까요?