Posts for: #Ai

로그라이크 연대기 Part 4: 한 판만 더

Slay the Spire 2 의 플레이어들은 2억 4천만 판을 했고 그중 4분의 3을 졌습니다. 지는 게 기본인 게임에 사람들이 계속 돌아오는 이유를 만든 사람들의 말과 몇 안 되는 연구로 따라가고, 스트리머가 판을 키운 사례와 작은 팀의 예산, Steam 에 쏟아지는 로그라이크 출시작, 그리고 AI 로 만든 게임 중에 로그라이크가 많다는 말을 자료에 대어 봅니다.

[Read more]

엉클 밥과 에이전트 Part 3: 규칙 파일 대신 게이트

엉클 밥의 규칙을 AGENTS.md 와 CLAUDE.md 에 자세히 적으면 그의 방식이 되는지 확인합니다. 2026년의 연구와 문서를 보고, Go 로 된 Gilded Rose 카타를 Claude Code 와 Codex 로 조건을 바꿔 가며 직접 돌려 규칙 파일과 Stop 훅 게이트, 역할을 나눈 에이전트 사슬을 비교한 뒤, 따라 할 수 있는 설정과 그 한계를 정리합니다.

[Read more]

엉클 밥과 에이전트 Part 2: swarm-forge

엉클 밥의 swarm-forge 는 역할별 에이전트를 tmux 와 git worktree 에서 돌리고 커밋으로 일을 넘깁니다. 구조와 헌법(constitution)을 코드로 읽고, Go 로 된 Gilded Rose 카타를 Claude 백엔드 두 개로 직접 돌려 단일 에이전트와 비교한 뒤, 팀에 들일 수 있는 도구인지 따져 봅니다.

[Read more]

엉클 밥과 에이전트 Part 1: 코드를 읽지 않는 이유

“My current strategy is to not read any of the code written by my agents.” 『Clean Code』 의 Robert C. Martin 이 2026년 7월에 쓴 문장입니다. 그가 열 달 동안 에이전트와 일하며 만든 방식, Agentic Discipline 을 그의 X 게시물과 저장소로 따라가고, 그 방식의 근거와 그가 스스로 드러낸 대가까지 정리합니다.

[Read more]

에이전트 하네스와 Pi Part 4: Pi 를 옆에 두기

“안녕” 한마디에 Pi 1.4.0 은 6천 자, Codex CLI 0.160 은 3만 6천 자, Claude Code 2.1 은 6만 2천 자를 모델에게 보냈습니다. Claude Code·Codex 로 일하는 개발자가 Pi 를 옆에 두면 무엇이 달라지는지, 컨텍스트를 들여다보는 extension, 파일로 다루는 세션, 프롬프트 대신 훅으로 막는 보호 경로, 스크립트용 print 모드를 직접 돌려 본 결과로 정리하고, Claude 구독 과금과 들이지 않는 게 나은 경우까지 적습니다.

[Read more]

에이전트 하네스와 Pi Part 3: Pi 라는 하네스

“Pi is a minimal agent harness.” libGDX 를 만든 Mario Zechner 가 Claude Code 에 지쳐 2025년에 시작하고 Earendil 이 2026년 4월에 인수한 Pi 를 소개합니다. 시스템 프롬프트와 도구 네 개로 버티는 설계, 일부러 넣지 않은 sub-agent·plan mode·권한 팝업, 그 빈자리를 채우는 extension·skill·세션 트리, 1.0 에서 뒤집은 MCP 방침, 엉클 밥의 에이전트 원칙과 겹치는 지점, 그리고 보안과 운영 쪽의 약점까지.

[Read more]

에이전트 하네스와 Pi Part 2: 하네스 이전과 지금

사람이 채팅창과 에디터 사이를 복사·붙여넣기로 오가던 2022년에서, Claude Code·Codex CLI·Gemini CLI 가 나온 2025년, 그리고 managed agents·durable harness·agent OS 라는 이름이 쏟아지는 2026년 10월까지. 하네스를 대체하는 개념이 정말 나타났는지 1차 자료로 확인하고, 대체가 아니라 하네스가 놓이는 자리가 옮겨 가고 있다는 결론을 적습니다.

[Read more]

에이전트 하네스와 Pi Part 1: 하네스란 무엇인가

같은 모델이 Codex CLI 에서는 57.8%, 다른 하네스에서는 36.9% 를 받습니다. Claude Code·Codex·Pi 를 묶어 부르는 ‘에이전트 하네스’ 가 무엇인지, Simon Willison·LangChain·Birgitta Böckeler·OpenAI·Anthropic·Earendil 의 정의와 하네스를 이루는 부품, 그리고 하네스가 점수를 얼마나 바꾸는지를 정리한 4부작의 첫 편입니다.

[Read more]

번역글: 빌드냐 바이냐, 비용만의 문제가 아니다

Pragmatic Programmers의 Dave Thomas가 쓴 뉴스레터 ‘The Build or Buy Decision Isn’t Just About Cost’의 한국어 번역. AI가 코드를 대신 써 주는 시대에도 직접 만들기보다 가져다 쓰는 쪽이 나은 이유를 실전 검증, 유지보수, 의심, AI 지원의 공백이라는 네 가지 비용으로 짚습니다.

[Read more]

유재하 『사랑하기 때문에』 전곡 리뷰 Part 7: 유산, 그리고 1년 전 리뷰와의 비교

시리즈의 마지막 편입니다. 유재하가 떠난 뒤 아버지가 앨범 수익으로 세운 장학회와 1989년부터 이어진 유재하 음악경연대회, 1997년과 2017년의 헌정 앨범, 1998년 7위에서 2007년 2위, 2018년 1위로 올라간 명반 순위, 후배 음악인들의 실제 발언을 정리합니다. 그리고 1년 전 이 블로그에 Gemini 2.5 Pro 의 초안으로 실린 리뷰를 이번 시리즈의 자료와 주장별로 대조해, 무엇이 맞았고 무엇이 틀렸는지를 표로 남깁니다.

[Read more]

뉴컴의 역설 Part 3: 그런 예측자는 있을 수 있는가 — 뇌, 키보드, 칼뱅주의자, 그리고 AI

뉴컴의 역설은 “거의 틀리지 않는 예측자” 를 전제합니다. 그런 예측자는 있을 수 있을까요. 의식보다 먼저 움직인다는 뇌의 신호와 그 해석을 뒤집은 후속 연구, 사람이 무작위로 키를 누르지 못해 70% 넘게 들킨다는 간단한 프로그램, 결과를 바꿀 수 없는데도 좋은 결과의 “증거” 가 되려고 행동을 바꾸는 사람들, 행실이 구원의 표징이었던 칼뱅주의자, 그리고 2025년과 2026년의 AI 가 사람의 선택을 얼마나 맞히는지와 AI 스스로는 몇 상자를 고르는지까지 살펴보고, 마지막 편의 장면들을 가를 분류 흐름도를 그립니다.

[Read more]

DHH 의 Rails World 2026 키노트 Part 2: 옹호와 반박, 그리고 제3의 길

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

[Read more]

DHH 의 Rails World 2026 키노트 Part 1: 「연필을 내려놓아라」 — 그가 실제로 말한 것

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

[Read more]

오목 엔진 Rapfi 해부 Part 5: Rapfi 로 오목·렌쥬 서비스를 만들 때

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

[Read more]

오목 엔진 Rapfi 해부 Part 4: 직접 빌드해서 돌려 보기

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

[Read more]

오목 엔진 Rapfi 해부 Part 3: Rapfi 는 어떻게 수를 고르는가

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

[Read more]