AI 시대의 작은 작업실
혼자 또는 작은 팀이 AI와 함께 일하는 방식을 기록하는 열린 시리즈입니다. 코딩 에이전트, 문서화, 자동화, 제품 운영, 실패한 실험, 오래 유지하기 위한 작업 시스템까지. 완성된 정답보다 실제로 해본 과정과 고민을 나눕니다.
참여 안내
이 시리즈는 누구나 참여할 수 있습니다. AI를 어떻게 업무에 붙였는지, 어떤 문서나 규칙이 도움이 됐는지, 어디서 실패했는지, 작은 팀이 어떻게 더 오래 만들 수 있을지에 대한 글을 환영합니다. 거창한 성공담이 아니어도 됩니다. 시행착오, 실험 기록, 작업 노트도 충분히 좋습니다.
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 코딩 에이전트를 계속 쓰다 보면 프롬프트보다 더 자주 문제가 되는 지점이 있다. 작업 습관이다. 처음에는 모델이 더 똑똑해지면 해결될 문제처럼 보인다. 그런데 실제 프로젝트에 붙여서 여러 번 돌려보면 비슷한 문제가 계속 나온다. 프로젝트 지침을 읽었다고 하지만 실제로는 열어보지 않는다. 요구사항이 모호한데 구현부터 시작한다. 코드 위치를 정하지 않고