AI 시대의 작은 작업실
혼자 또는 작은 팀이 AI와 함께 일하는 방식을 기록하는 열린 시리즈입니다. 코딩 에이전트, 문서화, 자동화, 제품 운영, 실패한 실험, 오래 유지하기 위한 작업 시스템까지. 완성된 정답보다 실제로 해본 과정과 고민을 나눕니다.
참여 안내
이 시리즈는 누구나 참여할 수 있습니다. AI를 어떻게 업무에 붙였는지, 어떤 문서나 규칙이 도움이 됐는지, 어디서 실패했는지, 작은 팀이 어떻게 더 오래 만들 수 있을지에 대한 글을 환영합니다. 거창한 성공담이 아니어도 됩니다. 시행착오, 실험 기록, 작업 노트도 충분히 좋습니다.
AI와 일하는 IDE, 내가 TaoIDE를 만드는 이유
이 글은 내가 만들고 있는 TaoIDE를 소개하는 글이다. 그 전에 요즘 개발자들이 어떤 IDE를 많이 쓰는지 확인하고, AI와 일하는 방식에 맞춰 주목받는 IDE와 도구들을 살펴본 뒤 TaoIDE를 소개하려 한다. IDE는 만들려는 제품과 사용하는 언어에 맞춰 선택한다. Android 앱인지, iOS 앱인지, 웹 서비스인지에 따라 필요한 개발 환경이 다르
Codex가 더 빨리 답하는 대신, 더 빨리 방향을 바꾸기 시작했다
Codex가 더 빨리 답하는 대신, 더 빨리 방향을 바꾸기 시작했다 10월 8일 Faster Steering 업데이트 — AI가 코드를 작성하는 중간에도 개발자가 개입할 수 있어야 하는 이유 AI Coding Agent에게 기능 개발을 맡겼다고 생각해보자. Codex는 프로젝트를 탐색하고 관련 파일을 확인한다. 화면 구조를 분석한 뒤 코드를 수정하기 시작한
Claude Code를 내 마음대로 뜯어고친다
Claude Code를 내 마음대로 뜯어고친다 Hooks보다 더 깊게 들어가는 Mods — Prompt·Tool Call·Permission·UI까지 바꾼다 Claude Code를 사용하다 보면 한 번쯤 이런 생각을 하게 됩니다. 기존에는 CLAUDE.md, Hooks, Skills, MCP 등을 조합해서 이런 요구를 해결했습니다. 그런데 2026년 10월
GPT-6.1 Sol이 일주일 만에 나왔다 — 6.0은 왜 이렇게 빨리 교체됐을까
GPT-6.1 Sol이 일주일 만에 나왔다 — 6.0은 왜 이렇게 빨리 교체됐을까 성능은 Astra에 가까워졌지만, 5.6보다 느리다는 말이 나오는 이유 2026년 9월 22일 OpenAI가 GPT-6 Sol을 공개했습니다. 그리고 불과 7일 뒤인 9월 29일 GPT-6.1 Sol 이 나왔습니다. 보통 모델 세대에서 6.0 → 6.1이 일주일 만에 넘어가는
Claude Sonnet 5.5가 나왔다 — 달라진 성능과 역할
Claude Sonnet 5.5가 나왔다 — 달라진 성능과 역할 속도·비용·Coding·Effort까지, 모델의 역할이 더 선명해졌다 2026년 9월 28일 Anthropic이 Claude Sonnet 5.5 를 공개했습니다. Opus 5.5가 나온 지 불과 며칠 뒤입니다. 처음 스펙만 보면 이런 생각이 들 수 있습니다. 그런데 이번에는 그렇게 단순하게 나
Gemini 4 Argon이 공식 발표됐다
Gemini 4 Argon이 공식 발표됐다 Google은 이미 80만 줄 코드베이스까지 AI에게 맡기고 있었다 한동안 이름만 돌던 Gemini 4 Argon 이 드디어 공식 발표됐습니다. 그런데 이번 발표에서 재미있는 건 벤치마크 1위 몇 개가 아닙니다. Google은 Argon을 공개하기 전에 이미 내부에서 상당히 공격적으로 사용하고 있었습니다. 데이터센
OpenAI dots가 나왔다 — 이제 AI는 질문을 기다리지 않는다
OpenAI dots가 나왔다 — 이제 AI는 질문을 기다리지 않는다 GPT-6 Astra·Cloud Computer·4,000개 앱으로 24시간 일하는 상시 Agent 2026년 9월 29일 OpenAI가 dots 를 공개했습니다. 처음 보면 또 하나의 ChatGPT 기능처럼 보이지만, 방향은 꽤 다릅니다. 지금까지 AI는 대부분 사용자가 먼저 말을 걸어
클라우드 AI가 계획하고 로컬 AI가 코딩한다
클라우드 AI가 계획하고 로컬 AI가 코딩한다 Antigravity SDK가 보여준 Hybrid Agent — Gemma 4·LiteRT·Ollama로 만드는 로컬 개발 Agent AI Coding Agent를 쓰다 보면 조금 아까운 순간이 있습니다. 복잡한 설계를 잡거나 어려운 버그를 찾을 때는 강한 클라우드 모델이 필요합니다. 그런데 이런 작업까지 모두
GPT-6와 Claude 5.5, 이제 토큰보다 캐시가 중요하다
GPT-6와 Claude 5.5, 이제 토큰보다 캐시가 중요하다 Agent를 오래 돌릴수록 모델 가격보다 Context를 얼마나 다시 쓰느냐가 중요해지는 이유 AI 모델 가격을 비교할 때 보통 가장 먼저 보는 숫자는 이겁니다. 짧은 질문을 한두 번 하는 정도라면 이것만 봐도 충분합니다. 하지만 Codex나 Claude Code처럼 Agent가 한 작업을 오
Claude Opus 5.5, 40% 싸지고 더 빨라졌다
Claude Opus 5.5, 40% 싸지고 더 빨라졌다 Medium Effort·Token·Cache·Agent 비용까지 달라진 이유 2026년 9월 22일 Anthropic이 Claude Opus 5.5 를 공개했습니다. 새 모델이 나오면 보통 Benchmark 점수부터 확인하게 됩니다. 그런데 이번 Opus 5.5는 성능 숫자보다 다른 변화가 더 눈에
Codex와 Claude 플러그인 생태계
Codex와 Claude 플러그인 생태계 Jira·Confluence·Figma부터 GitHub·Worktree·공유드라이브까지 개발 업무는 어디까지 연결될까 처음 Codex나 Claude Code를 사용할 때는 역할이 단순했습니다. 하지만 2026년의 AI 개발환경은 여기서 상당히 멀리 왔습니다. 이제 Agent가 연결되는 범위는: 까지 넓어졌습니다. 여
Paseo로 여러 AI 코딩 에이전트를 한 팀처럼 쓰는 방법
Paseo로 여러 AI 코딩 에이전트를 한 팀처럼 쓰는 방법 Claude는 설계하고, Codex는 구현하고, 다른 Agent는 리뷰하게 만들기 Codex를 쓰다가 Claude Code도 같이 쓰고 싶을 때가 있습니다. 단순히 두 터미널을 띄워 놓는 것은 어렵지 않습니다. 문제는 역할을 나누기 시작할 때입니다. 각 Agent에게 Context를 다시 전달하고
문서 작업을 위한 AI 업무 총괄
문서 작업을 위한 AI 업무 총괄 자료 수집부터 한국어 보고서·차트·이미지·PPT·PDF·Outlook 메일까지 AI 업무 도구를 비교할 때 흔히 모델 성능부터 이야기합니다. 하지만 실제 회사에서 보고서를 만들고 대표이사나 임원에게 발표해야 하는 사람에게 중요한 것은 조금 다릅니다. 이 기준으로 보면 비교 대상은 CLI나 Coding Agent가 아닙니다.
Jev가 뭐냐
Jev가 뭐냐 v1.01 LLM 대신 ‘판단’만 빠르게 하는 AI가 나온 이유 요즘 AI 모델은 코드를 작성하고, 검색하고, Tool을 호출하고, 여러 단계를 거쳐 문제를 해결합니다. 그런데 실제 서비스를 만들다 보면 모든 요청에 GPT, Claude, Gemini 같은 큰 모델이 필요한 것은 아닙니다. 예를 들어 이런 판단입니다. 이런 문제는 단순한 if
멀티에이전트는 이렇게 시작하면 된다 《3》
멀티에이전트는 이렇게 시작하면 된다 Codex와 Claude Code로 만드는 가장 단순한 구조 멀티에이전트를 처음 적용하려고 하면 구조부터 크게 그리기 쉽습니다. 여기에 MCP Server를 붙이고 Skill을 만들고 Agent마다 Model과 권한까지 따로 설정합니다. 그런데 실제 Codex와 Claude Code에서는 처음부터 이렇게 만들 필요가 없습
MCP 다음은 A2A다 《2》
MCP 다음은 A2A다 Agent끼리 통신하는 아키텍처는 언제 필요한가 앞선 글에서는 Multi-Agent 구조를 만들 때 모든 전문 기능을 Agent로 분리할 필요는 없다는 이야기를 했습니다. 반대로 이런 작업은 조금 다릅니다. 그렇다면 실제로 Agent를 분리해야 할 때는 어떻게 연결해야 할까요? 같은 애플리케이션 안의 객체라면 직접 호출하면 됩니다.
멀티에이전트가 항상 답은 아니다 《1》
멀티에이전트가 항상 답은 아니다 Agent를 Skill로 바꾸는 아키텍처 AI Agent 시스템을 만들기 시작하면 구조가 빠르게 커집니다. 처음에는 하나의 Agent가 여러 Tool을 사용합니다. 기능이 늘어나면 역할을 분리하기 시작합니다. 겉으로 보면 깔끔합니다. 각 Agent가 자기 역할만 담당하니 Microservice처럼 책임도 명확해 보입니다. 그
에이전트의 기억은 규칙이 되지 못한다
왜 공통화에 집중하는지는 0부에, Tao Agent OS를 처음 소개한 내용은 Tao Agent OS: AI 에이전트의 작업 습관을 프로젝트 밖에 저장하기에 적었다. AI 코딩 에이전트는 세션을 열 때마다 빈 컨텍스트에서 시작한다. 요즘 에이전트는 메모리나 지난 세션 요약을 들고 오기도 한다. Claude Code에는 auto memory가, Codex에는
Claude든 Codex든, 설치만 하면 같은 방식으로
Tao Agent OS 이야기는 여러 번 썼다. 처음 소개한 글부터 스킬 문서, 문서 라우팅, 게이트, 워크트리, 회고까지 한 편씩 따로 다뤘다. 이 글은 그 뒤를 잇는 시리즈의 입구다. 기능을 하나 더 소개하기 전에, 왜 계속 공통화 쪽으로 만들고 있는지부터 적어 둔다. 원한 것 AI 코딩 에이전트는 이제 하나가 아니다. Claude Code, Codex
기술부채도 이제 AI에게 티켓처럼 던진다
기술부채도 이제 AI에게 티켓처럼 던진다 GitHub Agentic Autofix가 바꾸는 기술부채 처리 방식 프로젝트를 오래 운영하다 보면 이상하게 없어지지 않는 목록이 하나 있습니다. Code Quality backlog입니다. 당장 장애를 만드는 버그는 아니지만 언젠가는 고쳐야 하는 코드들입니다. CodeQL이나 각종 정적 분석 도구가 계속 문제를 찾
AI Agent의 UI는 채팅창이 아닐지도 모른다
AI Agent의 UI는 채팅창이 아닐지도 모른다 AWS Pizza Bot이 보여주는 Long-running Agent의 새로운 UX 요즘 AI 앱을 열면 대부분 비슷한 화면이 나옵니다. 입력창이 있고, 메시지를 보내면 AI가 답합니다. ChatGPT 이후 너무 익숙해진 구조입니다. 짧은 질문을 하고 바로 답을 받는다면 이 방식이 잘 맞습니다. 문제는 Ag
PR도 Agent가 끝낸다: Agent Merge 이후의 개발 워크플로우
PR도 Agent가 끝낸다: Agent Merge 이후의 개발 워크플로우 AI Coding Agent의 역할은 지금까지 주로 Pull Request를 만드는 것 에 집중돼 있었다. 그런데 실제 개발에서는 PR을 만드는 순간 일이 끝나지 않는다. 오히려 그다음부터 일이 시작되는 경우가 많다. 작은 기능 하나라도 PR이 Merge되기까지 몇 시간에서 며칠이 걸
Agentic QA 설계: Claude 기반 모바일·웹 Runtime 검증
Agentic QA 설계: Claude 기반 모바일·웹 Runtime 검증 AI Coding Agent가 실제 개발에 깊게 들어오기 시작하면서 QA의 역할도 바뀌고 있다. 초기 AI Testing은 대부분 이런 수준이었다. 조금 발전하면 E2E Test까지 만들어줬다. 하지만 2026년 Agentic QA의 흐름은 여기서 한 단계 더 간다. 최근 Agent
AI가 코드를 더 많이 쓰는데 왜 개발자는 더 피곤해졌을까: Agent 시대의 새로운 개발자 번아웃
AI가 코드를 더 많이 쓰는데 왜 개발자는 더 피곤해졌을까: Agent 시대의 새로운 개발자 번아웃 AI Coding Agent를 처음 쓰기 시작했을 때 기대했던 모습은 단순했다. 코드를 직접 입력하는 시간이 줄어드니 당연히 개발자의 피로도도 줄어들 것 같았다. 그런데 2026년이 되면서 조금 다른 이야기가 나오기 시작했다. AI가 더 많은 코드를 작성하고
AI Agent 도입은 끝났다: 이제 개발팀이 증명해야 할 것은 생산성이다
AI Agent 도입은 끝났다: 이제 개발팀이 증명해야 할 것은 생산성이다 몇 년 전까지만 해도 개발 조직의 질문은 단순했다. 이제 이 질문은 거의 끝났다. 2026년 JetBrains Developer Ecosystem Survey에서는 전문 개발자의 90%가 업무에서 AI Coding Agent를 최소 주 1회 사용하고, 68%는 매일 사용 한다고 답했
Stack Overflow가 사라진 뒤 AI는 무엇을 참고할까: 레퍼런스가 없는 시대의 Evidence-Driven Coding Agent
Stack Overflow가 사라진 뒤 AI는 무엇을 참고할까: 레퍼런스가 없는 시대의 Evidence-Driven Coding Agent 개발하다가 처음 보는 오류가 발생했다. 몇 년 전이라면 거의 반사적으로 검색창부터 열었다. 특히 Stack Overflow와 GitHub Issues는 단순한 Q&A 사이트가 아니었다. 어떤 Framework가 문서와
GitHub 다음은 Agent-Native Git이다: Cursor Origin으로 보는 AI 시대의 코드 저장소
GitHub 다음은 Agent-Native Git이다: Cursor Origin으로 보는 AI 시대의 코드 저장소 개발자에게 Git Repository는 오랫동안 꽤 명확한 역할을 해왔다. GitHub가 크게 성장한 이유도 단순히 Git Repository를 인터넷에 저장했기 때문만은 아니다. Repository 주변에: 이라는 Software Develo
혼자 Agent에게 시키는 시대가 끝난다: Slack Code로 만드는 Human + AI 개발팀
혼자 Agent에게 시키는 시대가 끝난다: Slack Code로 만드는 Human + AI 개발팀 AI Coding Agent를 쓰는 모습은 지금까지 꽤 개인적이었다. 개발자가 자기 Terminal이나 IDE를 열고 Agent에게 일을 맡긴다. 빠르다. 하지만 팀 개발로 넘어가면 묘한 문제가 생긴다. Agent에게 무엇을 요청했는지 다른 팀원은 모른다. 어
AI 에이전트도 모니터링이 필요하다: Agent Cat으로 만드는 세련된 Agent Workflow
AI 에이전트도 모니터링이 필요하다: Agent Cat으로 만드는 세련된 Agent Workflow Coding Agent를 처음 사용할 때는 대개 하나만 실행한다. 이 정도라면 별도의 모니터링 도구가 없어도 크게 불편하지 않다. 하지만 Coding Agent가 일상적인 개발 도구가 되기 시작하면 화면이 조금씩 복잡해진다. 그리고 어느 순간 이런 문제가 생
이 코드는 누가 만들었나: AI Coding Agent 시대의 Git Provenance와 PR 증명서 설계
이 코드는 누가 만들었나: AI Coding Agent 시대의 Git Provenance와 PR 증명서 설계 예전에는 Git Commit을 보면 대체로 질문이 단순했다. 그래서 Git에는 이미 필요한 정보가 상당 부분 들어 있다. 그런데 Coding Agent가 본격적으로 개발 Workflow 안으로 들어오면서 이 정보만으로는 부족해지기 시작했다. 예를 들
Claude Code를 회사 서버에서 돌린다: Self-Hosted Coding Agent Runtime 실전 설계
Claude Code를 회사 서버에서 돌린다: Self-Hosted Coding Agent Runtime 실전 설계 Coding Agent를 개인 개발 환경에서 사용할 때는 구조가 단순하다. 개발자 Mac이나 PC 안에 Repository가 있고, Claude Code도 같은 환경에서 실행된다. 하지만 기업 환경으로 들어가면 이야기가 달라진다. 같은 자원이
Tokenmaxxing은 정말 낭비일까: AI Agent 비용을 아껴야 할 때와 과감하게 써야 할 때
Tokenmaxxing은 정말 낭비일까: AI Agent 비용을 아껴야 할 때와 과감하게 써야 할 때 2026년 AI 개발 업계에서 꽤 재미있는 논쟁이 벌어지고 있다. 한쪽에서는 이렇게 말한다. 반대쪽에서는 완전히 다른 이야기가 나온다. 최근 Y Combinator CEO Garry Tan은 스타트업 창업자들이 적극적으로 AI Token을 사용하는 이른바
AI Agent가 자기 기억법까지 스스로 개선한다: SelfMem으로 보는 Self-Optimizing Memory 실전 설계
AI Agent가 자기 기억법까지 스스로 개선한다: SelfMem으로 보는 Self-Optimizing Memory 실전 설계 AI Agent에 Memory를 붙이는 방식은 지금까지 꽤 정형화돼 있었다. 조금 더 발전시키면 다음과 같다. 개발자가 미리 분류하고 저장 규칙을 만든다. 예를 들어 이런 식이다. 처음에는 꽤 잘 동작한다. 그런데 실제 Agent를
에이전트의 실패를 다음 작업의 규칙으로 승격시키는 법
지난 글에서는 여러 에이전트가 동시에 작업할 때 격리가 깨지는 문제를 방지하고, 원본 체크아웃을 더럽히지 않은 채 작업을 안전하게 중단하는 방법을 정리했다. 워크트리를 생성하지 못했거나 작업 위치가 올바르지 않으면 그 상태로 실패 처리하고, 미완성 결과물은 지우지 않은 채 보존하는 방식이다. 하지만 작업을 멈췄다고 해서 같은 실수가 저절로 사라지는 것은 아
100만 토큰 Context가 답이 아니다: AI Agent가 파일 시스템을 외부 기억장치처럼 쓰는 방법
100만 토큰 Context가 답이 아니다: AI Agent가 파일 시스템을 외부 기억장치처럼 쓰는 방법 AI Agent를 오래 사용하다 보면 거의 반드시 한 번은 Context 문제를 만난다. 처음에는 단순하다. 조금 지나면 다음이 붙는다. 장시간 Coding Agent라면 더 심하다. 그래서 자연스럽게 이런 생각을 하게 된다. 128K보다 200K. 2
Codex·Claude Code를 깔아준다고 생산성이 오르지 않는다: AI 코딩 에이전트 도입을 성공시키는 7가지 운영 지표
Codex·Claude Code를 깔아준다고 생산성이 오르지 않는다: AI 코딩 에이전트 도입을 성공시키는 7가지 운영 지표 회사에서 AI 코딩 도구를 도입하기 시작하면 처음 보는 숫자는 대체로 비슷하다. 그리고 사용자가 늘면 자연스럽게 이런 이야기가 나온다. 하지만 이것만으로는 실제 개발 생산성이 좋아졌는지 알기 어렵다. 오히려 비용만 크게 늘었을 수도
하나의 작업에 에이전트로 몇개의 작업을 돌릴까? 동시에 20개를 돌리면 생기는 일?
에이전트를 한 번에 여러 개 돌리는 방식이 점점 늘어난다. Orca는 Codex, Claude Code 같은 CLI 에이전트를 각자의 worktree에서 나란히 실행하고 작업을 조율한다. 한 작업을 여러 조각으로 쪼개 동시에 맡기면 전체 시간이 줄어든다. 그런데 병렬 실행에서도 격리한 워크트리가 아니라 공유 체크아웃에 결과가 새어 들어갈 수 있다. 워커마다
AI 코딩 에이전트 보안의 새 원칙: Prompt Guardrail보다 Sandbox·Egress Control이 중요한 이유
AI 코딩 에이전트 보안의 새 원칙: Prompt Guardrail보다 Sandbox·Egress Control이 중요한 이유 AI 코딩 에이전트의 보안을 처음 구성하면 보통 이런 지시부터 넣는다. 그리고 AGENTS.md, CLAUDE.md, System Prompt 같은 곳에도 같은 내용을 적는다. 이런 규칙은 필요하다. 하지만 이것만으로 충분하지는 않
문서를 읽는 AI에서 스스로 일을 끝내는 Agent OS로
문서 연결을 다룬 글에서는 AI가 바뀌어도 같은 문서와 기준에 따라 일하게 만드는 방법을 정리했다. 요청에 맞는 문서를 찾고, 반드시 읽어야 할 문서와 필요할 때만 참고할 문서를 구분하며, 코드와 문서의 연관 관계를 추적하는 구조였다. 당시에도 Tao Agent OS를 '에이전트 OS'라 불렀지만, 솔직히 '에이전트 실행 환경'에 가깝다고 썼다. 문서를 연
Codex 5.6 제대로 쓰는 법 총정리: Sol·Terra·Luna 모델 배치부터 서브에이전트와 Context 압축 설정까지
Codex 5.6 제대로 쓰는 법 총정리: Sol·Terra·Luna 모델 배치부터 서브에이전트와 Context 압축 설정까지 GPT-5.6이 Codex에 들어오면서 모델을 선택하는 방식이 이전보다 복잡해졌다. 이제 단순히 로 끝나지 않는다. Codex에서는 다음을 함께 결정해야 한다. 2026년 8월 기준 Codex에서 사용할 수 있는 GPT-5.6 제품
CLAUDE.md를 지워도 될까: Claude Code 5의 Context·Output Style·Skill을 다시 나누는 방법
CLAUDE.md를 지워도 될까: Claude Code 5의 Context·Output Style·Skill을 다시 나누는 방법 최근 Claude Code 커뮤니티에서 비슷한 시기에 세 가지 글이 주목받았다. 첫 번째는 웹페이지를 ChatGPT나 Perplexity 같은 AI 답변 서비스가 인용하기 좋은 형태로 점검하는 Claude Code Skill이다.
AI 코딩 에이전트도 Policy as Code가 필요하다: managed-settings.json으로 권한·플러그인·모델 통제하기
AI 코딩 에이전트도 Policy as Code가 필요하다: managed-settings.json으로 권한·플러그인·모델 통제하기 AI 코딩 에이전트를 개인이 사용할 때는 설정이 단순하다. 사용할 모델을 고르고, 필요한 MCP Server나 Plugin을 연결한 뒤 작업하면 된다. 하지만 팀 전체가 에이전트를 사용하기 시작하면 문제가 달라진다. 각 개발자
Long-Horizon Agent 설계: Codex와 Claude가 몇 시간·며칠짜리 작업을 끝까지 이어가는 방법
Long-Horizon Agent 설계: Codex와 Claude가 몇 시간·며칠짜리 작업을 끝까지 이어가는 방법 AI 코딩 Agent를 사용할 때 대부분의 작업은 짧다. 또는 정도로 끝난다. 이런 작업은 Agent가 한 번 실행되는 동안 필요한 Context를 읽고 바로 끝내면 된다. 하지만 최근 Agent 모델은 그보다 훨씬 긴 작업을 겨냥하고 있다.
우리는 AI에이전트라는 코끼리를 눈감고 더듬고 있다.
우리는 모두 AI 에이전트 앞에서 군맹무상(群盲撫象)에 빠져 있다. 들어가며: 군맹무상 은 《열반경》에 나오는 이야기다. 인도의 경면왕이 앞을 보지 못하는 사람들을 궁으로 불러 모아 코끼리를 만져보게 했다. 상아를 만진 사람은 "무 같다"고 했다. 귀를 만진 사람은 "키 같다", 머리를 만진 사람은 "돌 같다", 다리를 만진 사람은 "기둥 같다"고 했다.
GPT-5.6와 Claude 5 시대의 Model Router: 모든 일을 상급 모델에게 시키지 않는 방법
GPT-5.6와 Claude 5 시대의 Model Router: 모든 일을 상급 모델에게 시키지 않는 방법 GPT-5.6과 Claude 5 세대가 나오면서 모델 선택이 오히려 더 복잡해졌다. 예전에는 대략 이런 식이었다. 지금은 그렇지 않다. OpenAI에는 GPT-5.6 Sol, Terra, Luna가 있고 Claude에는 Fable 5, Opus 5,
MCP 다음은 A2A다: 서로 다른 AI 에이전트를 연결하는 Agent2Agent 실전 설계
MCP 다음은 A2A다: 서로 다른 AI 에이전트를 연결하는 Agent2Agent 실전 설계 AI 에이전트를 하나만 사용할 때는 구조가 비교적 단순하다. Agent가 GitHub를 읽어야 하면 GitHub Tool을 연결한다. DB를 조회해야 하면 DB Tool을 연결한다. 외부 API를 호출해야 하면 해당 Tool을 연결한다. 이런 구조에서는 MCP가 잘
AI 코딩 에이전트에도 패키지 관리가 시작됐다: Agent Skills Supply Chain 설계법
AI 코딩 에이전트에도 패키지 관리가 시작됐다: Agent Skills Supply Chain 설계법 AI 코딩 에이전트를 팀에서 오래 사용하다 보면 비슷한 지시를 계속 반복하게 된다. 처음에는 이런 내용을 작업 요청마다 붙인다. 조금 지나면 AGENTS.md, CLAUDE.md, 프로젝트 지침 파일에 공통 규칙을 넣는다. 그런데 프로젝트가 커지면 전역 규
AI 에이전트끼리 자연어로 대화시키면 망한다: Typed Agent Contract 설계법
AI 에이전트끼리 자연어로 대화시키면 망한다: Typed Agent Contract 설계법 AI 코딩 에이전트를 처음 만들 때는 보통 역할부터 나눈다. 구조만 보면 그럴듯하다. 하지만 실제로 운영해보면 이상한 문제가 생긴다. Planner는 분명 수정 파일을 세 개로 제한했다고 말한다.\ Implementer는 “관련 파일도 함께 수정했다”고 보고한다.\
3부 - AI가 바뀌어도 내가 일하는 방식을 이어가는 법
요즘은 새로운 에이전트가 쉴 새 없이 나온다. Hermes Agent는 기억과 스킬을 쌓으며 오래 사용하는 에이전트를 지향한다. Orca는 Codex, Claude Code, OpenCode, Pi 같은 여러 CLI 에이전트를 나란히 실행하고 작업을 조율한다. Codex나 Claude Code는 저장소를 직접 읽고 파일을 수정하는 실행 도구로 자리 잡았다.
공포를 파는 사람들 VS 조용히 만드는 사람들 - Vibe, Dive 2편.
요즘 에이전트 톤이 우후죽순 열린다. 가서 주제를 받고, 옆에서 코칭을 받으면서, 끝까지 하나를 만들어 온다는 포맷이다. 그런데 매번 끝나고 나서 드는 생각은 하나였다. 시간 아까웠다. (토큰을 주는 것도 아닌데 몇십만 원씩 한다 ㅋㅋㅋ) 솔직히 이 기획 의도를 잘 모르겠다. 난 14년간 구글 개발자 그룹 커뮤니티를 운영해왔다. \ ( 개발자로도 15년간
에이전트로 돈 버는 법을 파는 사람들은, 왜 에이전트로는 돈을 못 벌까? Vibe, Dive!
새벽에 SNS을 열면 똑같은 생각이 든다. 나만 뒤처지고 있나. 어디는 벌써 골이니 루프니 하는 걸 돌려서 AX팀을 만들었다고 하고, 누구는 에이전트로 개인 사업을 차려서 돈을 엄청 벌었다고 한다. 스크롤을 조금 더 내리면 에이전트 사용법에 에르메스, 오픈클로를 얹어서 한 번에 60만원짜리 강의를 파는 사람이 나온다. 그 밑에는 하루에 천억 토큰을 썼다는
AI 에이전트가 어제 한 일을 잊지 않게 만드는 법: Durable Memory와 Run Ledger 설계
AI 에이전트가 어제 한 일을 잊지 않게 만드는 법: Durable Memory와 Run Ledger 설계 AI 코딩 에이전트를 며칠 이상 써보면 이상한 순간이 온다. 어제 분명히 같은 문제를 고쳤다.\ 같은 파일을 읽었다.\ 같은 테스트가 실패했다.\ 왜 그 접근을 버렸는지도 정리했다. 그런데 새 세션을 열면 다시 처음부터 시작한다. 개발자 입장에서는 답
2부? - AI 문서 라우팅은 결국 검색 최적화다 — 스킬 문서를 읽게 만드는 다음 단계
며칠 전에 AI는 스킬 문서를 알아서 읽지 않는다는 글을 썼다. 이전 글에서는 스킬 문서를 만들어두는 것만으로는 부족하다고 정리했다. 에이전트가 문서의 존재를 알고, 현재 작업에서 읽어야 할 문서를 찾을 수 있어야 한다는 내용이었다. 프로젝트 안의 .agents/skills, 루트 AGENTS.md, 공유 플레이북, 검색 스크립트를 연결하는 방법도 함께 적
AI가 실패하면 다른 AI가 이어받는다: 《AI Development Orchestra 3/3》
AI가 실패하면 다른 AI가 이어받는다: Consensus·Self-Healing·Eval Gate 운영법 1편에서는 AI 코딩 에이전트의 역할을 나눴다. 2편에서는 Claude, Codex, Cursor를 중앙 Orchestrator로 연결했다. 이제 마지막 문제가 남는다. 정상적으로 흘러갈 때는 어렵지 않다. Planner가 계획을 만들고, Implem
AI가 AI를 리뷰하게 만드는 법: 《AI Development Orchestra 2/3》
AI가 AI를 리뷰하게 만드는 법: Codex·Claude·Cursor 오케스트라 연결하기 1편에서는 AI 코딩 에이전트를 하나의 만능 작업자로 쓰지 않고 역할별로 나눴다. Claude Code에는 계획과 독립 리뷰를 맡기고, Codex에는 구현과 제한된 수정을 맡겼다. Cursor는 개발자가 최종 diff와 보고서를 확인하는 Control Room으로 두
혼자 일하는 AI는 끝났다: 《AI Development Orchestra 1/3》
혼자 일하는 AI는 끝났다: Codex·Claude·Cursor로 AI 개발팀 설계하기 최근 AI 코딩 도구를 쓰는 방식이 꽤 달라졌다. 예전에는 개발자가 코드를 작성하다가 막히는 부분을 AI에게 물었다. AI는 옆자리 조수에 가까웠다. 하지만 지금의 코딩 에이전트는 파일을 직접 찾고, 코드를 수정하고, 터미널에서 테스트를 실행한다. 작업 범위가 명확하면
AI는 스킬 문서를 알아서 읽지 않는다
AI는 이미 꽤 그럴듯한 코드를 만든다. 특히 웹 코드는 프롬프트만 넣어도 화면과 상태, 간단한 데이터 흐름까지 빠르게 만든다. 지난 1년 동안 AI에게 결과물을 요구하면 웹 코드가 가장 자주 나왔고, 그 구조도 계속 바뀌어왔다. 웹이 학습하기 쉬운 영역이라서일 수도 있고, 공개된 예제와 시행착오가 오래 쌓인 영역이라서일 수도 있다. 그러면 모바일 앱 개발
Tao Agent: 맨날 똑같은 실수하는 AI! 잘 활용하기위한 방법은?
AI 코딩 에이전트를 계속 쓰다 보면 프롬프트보다 더 자주 문제가 되는 지점이 있다. 작업 습관이다. 처음에는 모델이 더 똑똑해지면 해결될 문제처럼 보인다. 그런데 실제 프로젝트에 붙여서 여러 번 돌려보면 비슷한 문제가 계속 나온다. 프로젝트 지침을 읽었다고 하지만 실제로는 열어보지 않는다. 요구사항이 모호한데 구현부터 시작한다. 코드 위치를 정하지 않고