'써봤다'와 '붙였다'는 다른 말이다
AI 코딩 도구를 '쓴다'는 사람은 많아졌다. 하지만 실제 워크플로우에 '붙였다'는 사람은 여전히 드물다. Claude Code 탭을 열어 질문을 던지는 것과, 내 서버가 새벽 2시에 스스로 버그를 고치고 Telegram으로 리포트를 보내도록 연결하는 것은 전혀 다른 이야기다. 최근 수집된 세 가지 실제 사례는 그 간극을 어떻게 메울 수 있는지를 구체적으로 보여준다.
사례 1: $100짜리 구독으로 자가치유 서버 만들기
dev.to에 공개된 사례에서 멕시코의 한 개발자는 GCP 위에서 6개의 프로덕션 서비스를 운영하며 새벽 장애라는 오래된 악몽을 안고 있었다. 그가 찾은 해법은 새로운 플랫폼 도입이 아니었다. 이미 쓰고 있던 Claude Code Max 플랜($100/월)의 CLI 기능 중 하나인 claude -p—비대화형 실행 모드—를 발견한 것이 전부였다.
핵심 인사이트는 단순하다. claude -p는 추가 API 키 없이 기존 세션을 그대로 사용한다. 여기에 프로젝트별 Python MCP 서버(24개 툴, 읽기·쓰기·Git·PM2·테스트·컨텍스트의 6개 카테고리)를 붙이자, Telegram 메시지 한 줄이 곧 프로덕션 수정 명령이 됐다. !pmo tacos-api: fix the null check in ventas.js를 보내면 Claude가 로그를 읽고, 문제 라인을 찾고, 최소한의 수정을 적용하고, 서비스를 재시작한 뒤 결과를 리포트한다.
보안 설계도 인상적이다. MCP 레이어에서 경로 탈출과 민감 파일 접근을 원천 차단하고, 에이전트 레이어에서 동시 실행을 1개로 제한하며, 시스템 프롬프트(autocorrect.md)에서 .env와 크리덴셜 수정을 금지한다. CLI 레이어에서는 실행당 $2.00 예산 상한을 걸어 토큰 루프를 막는다. 4개의 동심원이 독립적으로 실패를 감지하는 구조다. 실제 운영 데이터에서 Claude가 실행된 7회는 100% 성공이었다—실패 2건은 에이전트 자체가 아닌 인프라 코드 버그였다.
또 하나 주목할 기능이 있다. --session-id와 --resume를 이용한 1시간 세션 공유다. 10시에 아키텍처를 설명시키고, 10시 5분에 엔드포인트 추가를 요청하면 Claude는 같은 컨텍스트 위에서 작업을 이어간다. LangChain 튜토리얼 어디에도 나오지 않는, CLI를 직접 파야 발견할 수 있는 기능이다.
사례 2: Cursor의 Composer와 Agent를 구분해 쓰는 법
Cursor가 VS Code 기반 에디터라는 사실은 많은 사람이 안다. 하지만 Composer와 Agent를 언제 각각 써야 하는지를 명확히 이해하는 사람은 적다. dev.to의 실용 가이드는 이 구분을 날카롭게 제시한다.
Composer는 '당신이 루프 안에 있을 때' 쓴다—리팩토링이나 피처 단위 변경처럼 diff를 빠르게 리뷰할 수 있는 작업. Agent는 '더 긴 자율 루프'를 위한 것—검색, 터미널 실행, 레포 전체 탐색이 필요한 작업. 적합한 도구 선택이 결과의 품질을 결정한다.
실용적인 습관으로 강조되는 것은 세 가지다. 첫째, 테스트와 타입을 항상 그린 상태로 유지할 것—에이전트는 코드를 빠르게 쓰지만 조직의 컨벤션을 추측하지 못한다. 둘째, 브랜치 보호와 CI는 사람 기여자와 동일하게 적용할 것—에이전트도 PR 프로세스를 거쳐야 한다. 셋째, 태스크를 좁게 정의할 것—"API 이름 변경 후 콜 사이트 업데이트"가 "더 좋게 만들어줘"보다 훨씬 나은 결과를 낳는다. 에이전트는 명확한 계약이 있을 때 강하다.
사례 3: 실행 비용 붕괴 이후의 사고 전환
GeekNews에 공유된 한 개발자의 회고는 가장 날것에 가깝다. Claude Code 월 구독 이후 3D AR 필터, RAG 챗봇, 뉴스레터 자동화를 '사전 지식 없이' 몇 시간 만에 구현했다는 경험담—그리고 그 이후 찾아온 예상치 못한 질문들.
"아이디어는 싸고, 실행은 더 싸다." 2년 전까지 타겟 정의·기술 검토·디자인·일정 산정의 검증 사이클이 수개월 걸렸다면, 이제는 노트북 한 대와 물 한 컵으로 몇 시간 안에 작동하는 제품이 나온다. 병목이 개발 속도에서 홍보와 리텐션으로 완전히 이동했다.
흥미로운 것은 빠른 구현이 '학습'을 건너뛰게 만든다는 자각이다. "코드를 한 줄도 들여다보지 않고 개발했으니 학습이 될 리 없다"는 솔직한 인정. 동시에 "어디 들어가게만 해주면 하루종일 회사에 붙어서 개발하고 있을 자신은 있다"면서도 불확실한 미래에 손이 떨린다는 고백—AI 시대 개발자의 정체성 고민을 날것 그대로 드러낸다.
세 사례가 가리키는 하나의 방향
세 사례를 나란히 놓으면 공통된 패턴이 보인다. AI 코딩 에이전트를 진짜 워크플로우에 붙이는 사람들은 도구를 '쓰는' 것에서 멈추지 않는다. 그들은 도구를 구조로 연결한다.
첫째, 기존 구독과 인프라를 새로운 방식으로 재조합한다. 자가치유 서버 사례에서 핵심 인사이트는 새 도구 도입이 아니라 claude -p라는 숨겨진 플래그 하나였다. 이미 가진 것을 더 깊이 파는 것이 출발점이다.
둘째, 에이전트의 자율성과 인간의 리뷰 사이에 명확한 경계를 설계한다. Cursor 가이드가 강조하는 브랜치 보호와 CI, 자가치유 서버의 4계층 보안 모델은 모두 '에이전트가 어디까지 혼자 결정할 수 있는가'를 구조적으로 정의한다.
셋째, 빠른 실행 이후의 병목을 직시한다. 실행 비용이 붕괴되면 개발 속도 자체는 더 이상 경쟁 우위가 아니다. 진짜 질문은 '무엇을 만들 것인가', '누가 쓸 것인가', '왜 계속 돌아올 것인가'로 이동한다.
지금 당장 해볼 수 있는 것
AI 에이전트를 워크플로우에 붙이고 싶다면, 거창한 아키텍처 설계보다 작은 연결 하나에서 시작하는 것이 빠르다. 반복적으로 하는 작업 하나를 골라 claude -p나 Cursor Agent에게 비대화형으로 맡겨보는 것—그 첫 연결이 구조의 출발점이 된다. 도구가 동반자가 되는 순간은, 탭을 열어 질문을 던질 때가 아니라 내 흐름 안에 단단히 묶어놓았을 때다.