고른 화풍으로 오리지널 캐릭터를 여러 장 같은 사람으로 그려 내는 법을 정리합니다. 설정화와 고정 프롬프트, NovelAI·PixAI·Gemini 의 레퍼런스 기능, Civitai·PixAI 의 캐릭터 LoRA 학습, 그리고 생성 이미지의 이용 규칙과 저작권까지 다룹니다.
Posts for: #Ai
애니 화풍 AI 그림 가이드 Part 2: 화풍과 프롬프트
Civitai 에서 화풍 모델을 고르고 모델 페이지를 읽는 법, Danbooru 태그 프롬프트와 문장 프롬프트의 짜임, 모델별 품질 태그, 그리고 Claude·ChatGPT·Gemini 같은 범용 LLM 에게 프롬프트를 맡기는 요청문을 예시 캐릭터 하나로 정리합니다.
애니 화풍 AI 그림 가이드 Part 1: 서비스와 모델 지도
NovelAI(NAI), PixAI, Civitai, ChatGPT·Gemini 가 각각 무엇이고 어떻게 다른지, 그리고 Illustrious·NoobAI·Pony·Lumina·Anima 로 이어지는 애니메이션 그림 모델의 계보를 2026년 11월 기준으로 정리합니다.
로그라이크 연대기 Part 4: 한 판만 더
Slay the Spire 2 의 플레이어들은 2억 4천만 판을 했고 그중 4분의 3을 졌습니다. 지는 게 기본인 게임에 사람들이 계속 돌아오는 이유를 만든 사람들의 말과 몇 안 되는 연구로 따라가고, 스트리머가 판을 키운 사례와 작은 팀의 예산, Steam 에 쏟아지는 로그라이크 출시작, 그리고 AI 로 만든 게임 중에 로그라이크가 많다는 말을 자료에 대어 봅니다.
엉클 밥과 에이전트 Part 4: ub-mode
엉클 밥이 10월 25일에 공개한 에이전트 skill ub-mode 를 읽고, 3편과 같은 Gilded Rose 과제에 Claude Code 와 Codex 로 넣어 skill 만 둔 경우와 게이트를 더한 경우를 비교합니다. 그가 CLI 에이전트 대신 쓴다는 grokbot 이 무엇인지도 공식 문서로 확인합니다.
엉클 밥과 에이전트 Part 3: 규칙 파일 대신 게이트
엉클 밥의 규칙을 AGENTS.md 와 CLAUDE.md 에 자세히 적으면 그의 방식이 되는지 확인합니다. 2026년의 연구와 문서를 보고, Go 로 된 Gilded Rose 카타를 Claude Code 와 Codex 로 조건을 바꿔 가며 직접 돌려 규칙 파일과 Stop 훅 게이트, 역할을 나눈 에이전트 사슬을 비교한 뒤, 따라 할 수 있는 설정과 그 한계를 정리합니다.
엉클 밥과 에이전트 Part 2: swarm-forge
엉클 밥의 swarm-forge 는 역할별 에이전트를 tmux 와 git worktree 에서 돌리고 커밋으로 일을 넘깁니다. 구조와 헌법(constitution)을 코드로 읽고, Go 로 된 Gilded Rose 카타를 Claude 백엔드 두 개로 직접 돌려 단일 에이전트와 비교한 뒤, 팀에 들일 수 있는 도구인지 따져 봅니다.
엉클 밥과 에이전트 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 게시물과 저장소로 따라가고, 그 방식의 근거와 그가 스스로 드러낸 대가까지 정리합니다.
에이전트 하네스와 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 구독 과금과 들이지 않는 게 나은 경우까지 적습니다.
에이전트 하네스와 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 방침, 엉클 밥의 에이전트 원칙과 겹치는 지점, 그리고 보안과 운영 쪽의 약점까지.
에이전트 하네스와 Pi Part 2: 하네스 이전과 지금
사람이 채팅창과 에디터 사이를 복사·붙여넣기로 오가던 2022년에서, Claude Code·Codex CLI·Gemini CLI 가 나온 2025년, 그리고 managed agents·durable harness·agent OS 라는 이름이 쏟아지는 2026년 10월까지. 하네스를 대체하는 개념이 정말 나타났는지 1차 자료로 확인하고, 대체가 아니라 하네스가 놓이는 자리가 옮겨 가고 있다는 결론을 적습니다.
에이전트 하네스와 Pi Part 1: 하네스란 무엇인가
같은 모델이 Codex CLI 에서는 57.8%, 다른 하네스에서는 36.9% 를 받습니다. Claude Code·Codex·Pi 를 묶어 부르는 ‘에이전트 하네스’ 가 무엇인지, Simon Willison·LangChain·Birgitta Böckeler·OpenAI·Anthropic·Earendil 의 정의와 하네스를 이루는 부품, 그리고 하네스가 점수를 얼마나 바꾸는지를 정리한 4부작의 첫 편입니다.
번역글: 빌드냐 바이냐, 비용만의 문제가 아니다
Pragmatic Programmers의 Dave Thomas가 쓴 뉴스레터 ‘The Build or Buy Decision Isn’t Just About Cost’의 한국어 번역. AI가 코드를 대신 써 주는 시대에도 직접 만들기보다 가져다 쓰는 쪽이 나은 이유를 실전 검증, 유지보수, 의심, AI 지원의 공백이라는 네 가지 비용으로 짚습니다.
유재하 『사랑하기 때문에』 전곡 리뷰 Part 7: 유산, 그리고 1년 전 리뷰와의 비교
시리즈의 마지막 편입니다. 유재하가 떠난 뒤 아버지가 앨범 수익으로 세운 장학회와 1989년부터 이어진 유재하 음악경연대회, 1997년과 2017년의 헌정 앨범, 1998년 7위에서 2007년 2위, 2018년 1위로 올라간 명반 순위, 후배 음악인들의 실제 발언을 정리합니다. 그리고 1년 전 이 블로그에 Gemini 2.5 Pro 의 초안으로 실린 리뷰를 이번 시리즈의 자료와 주장별로 대조해, 무엇이 맞았고 무엇이 틀렸는지를 표로 남깁니다.
뉴컴의 역설 Part 3: 그런 예측자는 있을 수 있는가 — 뇌, 키보드, 칼뱅주의자, 그리고 AI
뉴컴의 역설은 “거의 틀리지 않는 예측자” 를 전제합니다. 그런 예측자는 있을 수 있을까요. 의식보다 먼저 움직인다는 뇌의 신호와 그 해석을 뒤집은 후속 연구, 사람이 무작위로 키를 누르지 못해 70% 넘게 들킨다는 간단한 프로그램, 결과를 바꿀 수 없는데도 좋은 결과의 “증거” 가 되려고 행동을 바꾸는 사람들, 행실이 구원의 표징이었던 칼뱅주의자, 그리고 2025년과 2026년의 AI 가 사람의 선택을 얼마나 맞히는지와 AI 스스로는 몇 상자를 고르는지까지 살펴보고, 마지막 편의 장면들을 가를 분류 흐름도를 그립니다.
DHH 의 Rails World 2026 키노트 Part 2: 옹호와 반박, 그리고 제3의 길
DHH 의 Rails World 2026 키노트에 쏟아진 반응을 Hacker News 스레드 두 개, 참석자와 커뮤니티 구성원의 블로그, GeekNews 댓글, 그리고 이틀 뒤 Aaron Patterson 의 폐막 키노트까지 모아 비판·옹호·절충의 세 갈래로 정리합니다. 쟁점은 AI 가 아니라 「Rails 는 어디 갔나」였습니다.
DHH 의 Rails World 2026 키노트 Part 1: 「연필을 내려놓아라」 — 그가 실제로 말한 것
2026년 9월 23일 Rails World 2026 개막 키노트에서 DHH 는 37signals 가 손으로 코드를 쓰는 일을 그만두었고, HEY 를 Rails 웹앱에서 네이티브 앱 6개와 Rust 백엔드로 다시 만들고 있다고 밝혔습니다. 한 시간짜리 연설을 챕터 순서대로 재구성하고, 그가 제시한 숫자들을 1차 출처와 대조합니다.
오목 엔진 Rapfi 해부 Part 5: Rapfi 로 오목·렌쥬 서비스를 만들 때
Rapfi 를 엔진으로 오목·렌쥬 서비스를 만들 때 고려할 점을 정리합니다. 서버·브라우저(WASM)·앱 배치에 따라 달라지는 GPLv3 의무, 상태를 가진 Piskvork 프로토콜을 다루는 프로세스 모델과 Go 래퍼, 판 크기와 렌쥬 오프닝 규정의 공백, 초보자용 난이도 설계의 함정, 자원·버전 관리까지 실측과 소스 근거로 짚습니다.
오목 엔진 Rapfi 해부 Part 4: 직접 빌드해서 돌려 보기
Rapfi 를 소스에서 빌드하고 Piskvork 프로토콜로 직접 대화해 봅니다. 탐색 로그 읽는 법, 같은 국면이 자유룰과 렌쥬에서 어떻게 달라지는지, 花月 주형의 Multi-PV 분석, STRENGTH 로 기력 낮추기, MCTS 탐색기, 파이썬으로 엔진 부리기까지 Apple M1 Max 에서 실제로 실행한 결과로 보여 줍니다.
오목 엔진 Rapfi 해부 Part 3: Rapfi 는 어떻게 수를 고르는가
Rapfi 의 소스 코드를 따라가며 한 수를 고르기까지의 의사결정 과정을 해부합니다. 선 패턴 16종과 네 방향 조합 14종으로 판을 읽는 법, 렌쥬 금수의 정확한 판정, 고전 평가와 NNUE(mix9svq)를 섞어 쓰는 방식, Stockfish 에서 가져온 알파-베타 탐색과 VCF 잎 탐색, 선택 사항인 MCTS, 시간 관리와 멀티스레드까지 정리합니다.