DHH 의 Rails World 2026 키노트에 쏟아진 반응을 Hacker News 스레드 두 개, 참석자와 커뮤니티 구성원의 블로그, GeekNews 댓글, 그리고 이틀 뒤 Aaron Patterson 의 폐막 키노트까지 모아 비판·옹호·절충의 세 갈래로 정리합니다. 쟁점은 AI 가 아니라 「Rails 는 어디 갔나」였습니다.

2026년 9월 23일 Rails World 2026 개막 키노트에서 DHH 는 37signals 가 손으로 코드를 쓰는 일을 그만두었고, HEY 를 Rails 웹앱에서 네이티브 앱 6개와 Rust 백엔드로 다시 만들고 있다고 밝혔습니다. 한 시간짜리 연설을 챕터 순서대로 재구성하고, 그가 제시한 숫자들을 1차 출처와 대조합니다.

Rapfi 를 엔진으로 오목·렌쥬 서비스를 만들 때 고려할 점을 정리합니다. 서버·브라우저(WASM)·앱 배치에 따라 달라지는 GPLv3 의무, 상태를 가진 Piskvork 프로토콜을 다루는 프로세스 모델과 Go 래퍼, 판 크기와 렌쥬 오프닝 규정의 공백, 초보자용 난이도 설계의 함정, 자원·버전 관리까지 실측과 소스 근거로 짚습니다.

Rapfi 를 소스에서 빌드하고 Piskvork 프로토콜로 직접 대화해 봅니다. 탐색 로그 읽는 법, 같은 국면이 자유룰과 렌쥬에서 어떻게 달라지는지, 花月 주형의 Multi-PV 분석, STRENGTH 로 기력 낮추기, MCTS 탐색기, 파이썬으로 엔진 부리기까지 Apple M1 Max 에서 실제로 실행한 결과로 보여 줍니다.

Rapfi 의 소스 코드를 따라가며 한 수를 고르기까지의 의사결정 과정을 해부합니다. 선 패턴 16종과 네 방향 조합 14종으로 판을 읽는 법, 렌쥬 금수의 정확한 판정, 고전 평가와 NNUE(mix9svq)를 섞어 쓰는 방식, Stockfish 에서 가져온 알파-베타 탐색과 VCF 잎 탐색, 선택 사항인 MCTS, 시간 관리와 멀티스레드까지 정리합니다.

알파-베타 탐색과 초경량 NNUE 로 CPU 에서 초당 수십만 노드를 읽는 Rapfi 와, 큰 신경망과 MCTS 로 GPU 에서 수천 번을 읽는 KataGo(오목판 KataGomo)를 비교합니다. 탐색·평가·하드웨어·학습·프로토콜·라이선스를 나란히 놓고, ‘어느 쪽이 더 강한가’ 라는 질문에 1차 출처가 실제로 답하는 범위가 어디까지인지 정리합니다.

현재 가장 강력한 오픈소스 오목·렌쥬 엔진인 Rapfi 를 다섯 편에 걸쳐 분석합니다. 첫 편은 2026년 기준 오목·렌쥬 오픈소스 생태계(엔진·GUI·프로토콜·대회)를 훑고, Rapfi 가 2018년 Gomocup 4위에서 2022년 이후 사실상 전 리그를 제패하기까지의 역사를 1차 출처로 정리합니다.

시리즈의 마지막 편입니다. 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 공식 문서와 실측 자료로 정리합니다.

시리즈 마지막입니다. 두 저자는 README 에서 같은 논점에 정반대로 답합니다. 한쪽은 프로세스 소유를 기능이라 부르고 다른 쪽은 결함이라 부릅니다. 외부에서 제기된 의식 비용 비판과 이 블로그의 기존 4부작이 같은 지점을 짚었다는 사실까지 정리하고, 언제 무엇을 쓸지 판단 기준을 제시합니다.

두 스킬셋은 TDD 에서 같은 말을 하지 않습니다. superpowers 는 리팩터링을 루프 3단계로 넣고 테스트 없이 쓴 코드를 삭제하라고 명령하며, mattpocock 은 리팩터링이 루프의 일부가 아니라고 못박고 테스트 지점을 사전 합의하라고 요구합니다. 구현·리뷰·디버깅·검증 단계를 원문으로 대조했습니다.

코드를 쓰기 전 생각을 정리하는 단계를 정면 비교합니다. superpowers 의 brainstorming 은 한 번에 한 질문씩 묻고 설계 문서를 커밋하며, mattpocock 은 같은 자리에 문을 세 개 두고 프론티어 단위로 묻고 아무것도 남기지 않습니다. 그리고 superpowers 에는 prototype 이 없습니다.

두 스킬셋의 가장 큰 차이는 스킬 내용이 아니라 발동 방식입니다. superpowers 는 SessionStart 훅으로 진입점 스킬 전문을 매 세션 강제 주입하고, mattpocock 은 훅이 0개에 25개 중 14개가 수동 전용입니다. 훅 스크립트를 해부하고 상시 토큰 비용을 실측했습니다.

코딩 에이전트 스킬셋 양대 산맥을 5부작으로 비교합니다. 1편은 지형도입니다. 두 저장소를 실제로 설치해 재 보니 총 분량이 2,949줄과 2,945줄로 거의 같았고, 차이는 크기가 아니라 배치였습니다. 단계별 대응표와 양쪽이 비워 둔 자리를 정리합니다.

사고의 외주화가 실행의 외주화로 넘어가면서 ‘검수 시점’이라는 것이 사라졌습니다. 검증이 병목이 되었고, 개인 최적과 집단 최적이 갈라졌고, EU는 고위험 규제를 16개월 미뤘습니다. 원문의 결론이었던 Co-pilot / Autopilot 이분법이 왜 더 이상 성립하지 않는지, 그리고 무엇으로 바꿔야 하는지 정리합니다.

원문이 제시한 네 가지 실행 지침을 2026년 근거로 채점합니다. ‘초안은 내가 쓴다’는 예상보다 훨씬 잘 버텼고, ‘30% 수정 룰’은 근거가 없어 폐기하며, ‘고유성 주입’은 전제 자체가 낡았습니다. 2026년 데이터가 반복해서 가리키는 단일 변수는 수정량이 아니라 질문의 형식입니다.

2026년 2월에 쓴 「사고의 외주화」는 근거가 하나도 없는 논평이었습니다. 6개월 사이 이 주제에 실증 데이터가 쌓였습니다. 당시 제기한 네 가지 문제를 2026년 자료로 다시 판정합니다. 하나는 메커니즘 설명이 틀렸고, 하나는 초점을 옮겨야 하며, 두 개는 수치가 붙어 오히려 강해졌습니다.