Claude Code를 직접 만든 사람은 어떻게 쓸까. Anthropic의 Claude Code 개발 책임자 Boris Cherny가 자신의 AI 코딩 워크플로우를 공개했고, 개발자 커뮤니티에서 상당한 반향을 일으켰다. VentureBeat AI 보도에 의하면, 이 방식을 따르면 개발자 한 명이 소규모 엔지니어링 팀 수준의 아웃풋을 낼 수 있다고 한다. 처음엔 과장처럼 들린다. 그런데 실제 방법을 뜯어보면 납득이 간다. 소프트웨어 개발 분야에서 AI는 이미 단순한 코드 자동 완성 도구를 넘어섰다. Cherny의 워크플로우는 그 다음 단계가 어떤 모습인지를 구체적으로 보여준다.
AI를 비서 1명처럼 쓰면 안 된다
대부분의 개발자가 AI를 활용하는 방식은 단순하다. 질문 하나를 던지고, 답을 받고, 또 질문한다. 근본적으로 1:1 대화 구조에서 벗어나지 못한다. Cherny는 완전히 다른 방식을 택한다.
그는 터미널에서 Claude 인스턴스를 5개 동시에 실행한다. 각 탭에 1번부터 5번까지 번호를 붙이고, iTerm2의 시스템 알림 기능으로 각 인스턴스가 입력을 기다릴 때마다 알림을 받는다. 이건 그가 X 게시글에서 직접 밝힌 내용이다.
병렬 처리의 효과는 명확하다. 1번 AI가 테스트 스위트를 돌리는 동안, 2번은 레거시 모듈을 리팩토링하고, 3번은 문서 초안을 쓴다. 개발자는 코드를 직접 타이핑하는 대신, 각 AI 에이전트에 지시를 내리고 결과를 조율한다. 실시간 전략 게임에서 유닛을 운용하는 것과 비슷한 느낌이다. 사령관 역할이다. 로컬 터미널 외에도 claude.ai 웹에서 5~10개의 Claude 세션을 동시에 운영하며, ‘텔레포트’ 명령으로 로컬과 웹을 유연하게 오간다. 이렇게 환경을 세팅하면 개발자의 에너지 배분이 달라진다. 문법을 타이핑하는 데 쓰던 에너지가 고수준의 문제 해결과 아키텍처 설계로 이동한다. 이게 핵심이다.
왜 느린 모델 Opus 4.5를 고집하나
AI 개발에서 빠른 모델이 좋은 모델이라는 건 착각이다. Cherny는 Anthropic의 가장 무겁고 느린 모델인 Opus 4.5를 모든 작업에 쓴다. “내가 사용해 본 코딩 모델 중 최고”라는 게 그의 말이다.
이 선택의 배경에는 핵심적인 통찰이 있다. 현대 AI 개발의 진짜 병목은 AI가 코드를 생성하는 속도가 아니다. 개발자가 AI의 실수를 수정하는 데 드는 시간이다. 작고 빠른 모델은 초기 응답은 빠르지만, 오류가 많아 수정에 더 많은 사람의 시간이 들어간다. 반면 Opus 4.5 같은 고성능 모델은 초기 컴퓨팅 비용이 높더라도, 오류가 적고 도구 사용 능력이 뛰어나 전체적인 수정 시간을 대폭 줄인다. 컴퓨팅 비용을 더 내는 대신 수정 비용을 아끼는 구조다. 결과적으로 더 빠른 개발이 가능하다. 기업 기술 리더들에게 이 계산은 상당히 중요한 시사점을 준다.
AI 건망증을 고치는 CLAUDE.md 파일
AI의 고질적인 문제다. 어제 가르쳐 준 것을 오늘 또 모른다. 세션이 바뀌면 리셋이다. 기업의 코딩 스타일이나 아키텍처 결정 사항을 AI가 지속적으로 기억하게 하려면 어떻게 해야 할까.
Cherny 팀은 Git 저장소에 CLAUDE.md라는 파일 하나를 유지하는 방식으로 이 문제를 해결한다. 이 파일이 AI에게 전달되는 지속적인 지침서 역할을 한다. “Claude가 잘못된 작업을 할 때마다, 다음번에는 그러지 않도록 CLAUDE.md에 추가한다”고 그는 설명했다.
이 방식은 코드베이스를 스스로 교정하는 유기체처럼 만든다. PR을 리뷰하다가 AI가 만든 오류를 발견하면, 코드만 고치지 않는다. AI의 지침을 업데이트하도록 태그를 지정한다. 제품 리더 아카쉬 굽타(Aakash Gupta)의 표현이 딱 맞다. “모든 실수가 규칙이 된다.” 팀이 함께 AI를 쓰는 시간이 쌓일수록 AI 에이전트는 점점 그 팀의 방식에 맞게 다듬어진다.
반복 작업을 없애는 슬래시 명령어와 서브 에이전트
Cherny의 워크플로우에서 반복 작업은 슬래시 명령어로 처리한다. 프로젝트 저장소에 커스텀 슬래시 명령어를 추가해 복잡한 절차를 키 입력 한 번으로 끝낸다. 예를 들어 /commit-push-pr은 하루에 수십 번 호출하는 명령어다.
이 명령어 하나가 처리하는 일이 있다. git 명령어 입력, 커밋 메시지 작성, 풀 리퀘스트 열기 — 이 세 단계를 AI 에이전트가 자율적으로 처리한다. 수동으로 반복하던 버전 관리 작업 전체가 없어지는 셈이다. 이건 개발자가 지루한 절차에 쓰던 시간을 실제 문제 해결로 돌리는 핵심 전략이다.
서브 에이전트도 빼놓을 수 없다. 메인 작업이 끝나면 아키텍처를 정리하는 ‘코드 간소화(code-simplifier)’ 에이전트가 동작하고, 최종 배포 전에는 ‘앱 검증(verify-app)’ 에이전트가 엔드 투 엔드 테스트를 돌린다. 각 개발 단계를 전담하는 AI 페르소나들이다. 단순한 자동화가 아니라 개발 파이프라인 자체를 AI 에이전트 체인으로 재설계하는 것에 가깝다.
AI가 직접 검증하는 루프 — 코드 품질이 달라진다
AI가 코드를 만들고 끝. 이게 대부분의 방식이다. Cherny는 다르다. 검증 루프(verification loop)를 추가한다. 이 루프가 AI 생성 코드의 품질을 2~3배 끌어올린다고 그는 주장한다.
구체적으로 이렇다. “Claude는 Claude Chrome 확장 프로그램을 사용해 claude.ai/code에 적용하는 모든 변경 사항을 테스트한다.” AI가 브라우저를 직접 열어 UI를 확인하고, 코드가 작동하고 사용자 경험이 만족스러울 때까지 반복적으로 수정한다. 텍스트 생성기가 아니라 테스터로 동작하는 것이다.
이것이 뜻하는 바는 분명하다. AI에게 자신의 작업을 검증할 수단을 줘야 한다. 브라우저 자동화, 셸 명령어 실행, 테스트 스위트 실행 — 이 수단들이 AI를 단순한 코드 작성기에서 결과물 책임자로 바꾼다. 코드를 쓰는 것과 그 코드가 작동한다는 걸 스스로 증명하는 건 전혀 다른 일이다. 그 차이가 최종 결과물의 신뢰성을 바꾼다.
결국 개발자의 역할이 바뀐다
Boris Cherny의 워크플로우가 드러내는 건 도구의 변화가 아니다. 역할의 변화다. AI 코딩이 IDE 자동 완성 기능에 머물렀던 건 이미 지난 이야기가 됐다. 지금 AI는 개발 노동 그 자체를 위한 운영 체제로 기능한다.
이 변화는 개발자의 역할을 다시 정의한다. 직접 코딩하는 사람이 아닌, AI 에이전트 부대를 지휘하고 복잡한 시스템을 설계하며 AI의 학습을 돕는 전략가이자 아키텍트. AI를 보조 도구가 아닌 협업하는 워크포스로 인식하고 이 패러다임에 적응하는 개발자가 앞으로의 경쟁에서 실질적인 우위를 점한다. 예측이 아니다. 이미 진행 중인 현실이다.
출처: VentureBeat AI
AI리서치팀
Home-In-One AI리서치팀은 인공지능, 머신러닝, 생성형 AI의 최신 동향과 실용적 활용법을 연구합니다. ChatGPT, 클로드, 미드저니 등 AI 도구 비교 분석과 활용 가이드를 제공합니다.