[활용] Claude Code, 스타트업은 다섯 가지 규칙으로 쓴다

Anthropic이 2026년 8월 20일 공개한 "The Claude Code guide for startups"(작성자 Michael Segner)를 정리합니다. 이 문서는 Anthropic이 Artemis Security, Cainex, Clay, ClickHouse, Cognition, Commure, Crosby, Emergent, Harvey, Heidi, Higgsfield, Omni, Parahelp, Translucent, Zingage 등 15개 안팎의 스타트업을 인터뷰해 뽑아낸 운영 원칙 모음입니다. 개별 기능 소개가 아니라 조직 운영 방식에 대한 가이드라는 점이 특징이고, 그래서 도구를 이미 쓰고 있는 팀에게 더 유용합니다.

원문이 앞세우는 수치부터 보겠습니다. 물론 벤더가 고른 성공 사례라는 점은 감안하고 읽어야 합니다.

회사	원문이 제시한 성과
ClickHouse	기능 출시량 30% 증가
Omni	엔지니어링 생산성 2~3배
Clay	버그 트리아지 100% 자동화
Artemis Security	주당 PR 6,000건 이상

원문은 이 회사들이 "10배 규모 조직처럼 출시한다"고 요약하면서, 그 방식을 다섯 가지 규칙으로 묶습니다.

규칙 1. 모두가 배포한다

첫 규칙은 개발의 진입 장벽에 대한 이야기입니다. 에이전틱 코딩이 첫 버전 수정의 문턱을 낮추면서, 비개발 직군이 직접 제품을 고치는 사례가 늘고 있다는 것입니다. Parahelp에서는 비개발 직원이 UI 변경을 배포하고, 법무 스타트업 Crosby에서는 변호사가 제품 개선을 직접 작성합니다. Heidi의 Thomas Kelly는 아이디어가 여러 중간 단계를 거치며 원래 의도를 잃는 전통적 전달 사슬이 무너진다고 표현합니다.

원문이 제안하는 실행 방법은 세 가지입니다.

첫째, 연결을 만듭니다. 팀에게 새 워크플로를 강요하는 대신 MCP나 CLI로 Claude를 기존 도구, 데이터베이스, API에 연결합니다. 원문의 표현대로 "Claude는 보이지 않는 것을 이해할 수 없습니다."

둘째, 프로토타입을 공식 절차에 올립니다. Clay는 분기별 리뷰에서 프로토타입이 정식 로드맵에 들어갈 수 있게 했고, 실제로 영업 조직 구성원이 웹사이트를 방문해 리드 폼을 채우고 응답 시간을 측정해 보고서를 만드는 에이전트를 직접 만들었습니다. Omni는 Claude로 만든 프로토타입 전용 슬랙 채널을 운영합니다.

셋째, 스킬을 공유합니다. 개발이 전사로 퍼질수록 표준이 흩어지기 쉬운데, 팀 표준과 맥락을 담은 재사용 가능한 지시 파일로 응집력을 유지하라는 것입니다. Emergent는 데이터베이스 위치와 스키마 정보를 담은 스킬 저장소를 GitHub에 두고 온보딩에 씁니다. 흥미로운 대목은 "약간 낡은 컨텍스트 파일"을 허용한다는 점입니다. 에이전트가 스스로 검증하고 고칠 수 있으면 된다는 태도입니다.

규칙 2. 지루한 일은 자동화한다

두 번째 규칙의 핵심 문장은 Artemis Security의 것입니다. "모두가 AI 제품을 만들려고 경쟁하지만, 회사가 실제로 돌아가는 방식을 다시 만드는 곳은 훨씬 적습니다." 이 회사는 개발 사이클의 "기계적인 80%"를 에이전트가 소유하는 구조로 운영합니다.

가장 구체적인 사례는 ClickHouse입니다. 불안정한 테스트를 고치는 에이전트와 누락된 테스트 커버리지를 찾는 에이전트, 이 둘이 저장소 기여자 순위 2위와 3위에 올라 있습니다. Commure에서는 한 엔지니어가 티켓 13개짜리 과제를 서브에이전트 병렬 실행으로 처리했는데, 에이전트마다 티켓 하나와 PR 하나를 맡는 방식이었습니다.

원문이 권하는 도구는 두 가지입니다. 하나는 Code Review(리서치 프리뷰)로, PR에 자동 리뷰를 돌리고 발견 사항마다 심각도를 붙이는 관리형 다중 에이전트 서비스입니다.

다른 하나는 Claude Tag(퍼블릭 베타)입니다. CI/CD 실패나 온콜 대응의 1차 대응자로 슬랙에 배치하는 방식인데, Anthropic 내부에서는 장애 발생 시 Claude가 보통 15분 안에 첫 상황 보고를 올린다고 합니다. Datadog과 Grafana 접근 권한을 가진 서비스 계정을 쓰고, 지시사항은 스킬로 GitHub 저장소에 두어 팀이 함께 다듬습니다.

규칙 3. 신뢰하되 검증한다

자동화의 규모를 키우려면 검증 장치가 먼저 있어야 한다는 규칙입니다. 가장 솔직한 증언은 Zingage의 Victor Hunt에게서 나옵니다. "초기에 Claude에게 완전한 자율성을 줬더니 AI가 하는 일을 했습니다. 그럴듯한 코드를 빠르게 출시했지만, 맞아 보이면서 실제로는 아닌 방식으로 우리 아키텍처에서 이탈했습니다. 그래서 모든 불변 조건을 적었습니다. 이 팀이 생각하는 방식 567줄입니다."

원문의 처방은 네 가지입니다. 아키텍처 제약을 루트 CLAUDE.md에 두고, 자율 작업에는 정지 조건이 있는 루프를 쓰고, 핵심 사용처마다 검증된 질문과 답 쌍으로 골든 셋을 유지하고, 훅을 결정론적 하드 게이트로 씁니다. 루프 설계는 이 시리즈의 이전 글 "[활용] Claude Code, 프롬프트가 아니라 루프를 설계하라"에서 자세히 다뤘으므로 여기서는 넘어갑니다.

의료 코딩 스타트업 Cainex의 사례가 이 규칙의 실체를 보여줍니다. 의료 코딩 오류는 청구와 컴플라이언스 사건이기 때문에, 감사자가 모델의 추론 과정을 보며 코드에 코멘트를 달고, Claude가 진단이나 시술 같은 범주별로 교정을 반영하고, 골든 셋과 무작위 샘플로 백테스트하는 검증 루프를 돌립니다. CTO Uriah Israel의 원칙이 인상적입니다. "사례가 아니라 원칙을 고치십시오." 개별 오답을 땜질하지 말고 지시의 원리를 수정하라는 뜻입니다.

규칙 4. 다시 짓기를 전제로 짓는다

모델 능력이 계속 바뀌므로 영구적인 것은 거의 없다고 보고, 재구축 자체를 경쟁력으로 삼으라는 규칙입니다. Clay의 Kareem Amin은 "만들고, 다시 만들고, 또 다시 만듭니다. 네 번째로 만들 때쯤이면 필요한 것을 전부 알게 되어 제대로 만든다"고 말합니다. Cognition의 Walden Yan은 더 직설적입니다. "지금 AI를 만드는 삶의 방식은, 오늘 만든 것이 6개월에서 1년 안에 폐기될 가능성이 높다는 사실을 받아들이는 것입니다."

주목할 부분은 Commure의 기술 부채 정의입니다. "재구축은 새 경로가 출시됐을 때가 아니라 옛 경로가 사라졌을 때 끝납니다." 철거 작업은 지루하고 기능을 출시하지 않아 우선순위 싸움에서 늘 밀렸는데, 이제는 엔지니어가 "전면 배포된 모든 피처 플래그에 대해 플래그와 관련 코드를 제거하는 PR을 열어라"는 스킬 하나를 실행하는 것으로 처리합니다.

도구 측면의 권고는 git worktree로 운영 버전을 유지한 채 격리된 사본에서 재구축을 돌리고, 사소하지 않은 재작성은 플랜 모드로 시작해 코드 작성 전에 접근법부터 제안받으라는 것입니다.

규칙 5. 프로토타입, 도그푸딩, 프로덕션화

마지막 규칙은 플라이휠에 대한 것입니다. AI로 만드는 경험이 모델 능력에 대한 이해를 키우고, 그 이해가 다시 AI 제품을 좋게 만든다는 순환입니다. Omni는 Claude Code가 RAG 파이프라인 대신 파일 기반 접근을 쓰는 것을 보고 자사 제품에서도 복잡한 RAG 구성을 피했다고 말합니다. Emergent는 자사 앱 빌더가 Anthropic 모델을 쓰기 때문에, 제품에서 이상 동작이 보이면 Claude Code로 로컬 재현을 해서 모델 문제인지 하네스 문제인지 빠르게 가려냅니다.

전형적 경로는 내부 에이전트를 Claude Code로 만들고, 내부에서 충분히 써본 뒤, 검증된 것만 Claude API나 SDK로 고객 대면 제품에 올리는 것입니다. ClickHouse는 SQL 콘솔 에이전트와 AI SRE를 이렇게 만들었고, "고객의 AI 경험을 움직이는 도구 자체가 부분적으로 AI로 만들어졌다"고 표현합니다.

체크리스트

원문 말미의 체크리스트를 요약하면 다음과 같습니다.

규칙	실행 항목
모두가 배포한다	MCP나 CLI로 원천 데이터 연결, 사내 플러그인 마켓플레이스, 하위 디렉터리별 CLAUDE.md, 절차형 워크플로는 스킬로
지루한 일 자동화	Code Review 설정, Claude Tag를 CI/CD와 온콜에 투입, 서브에이전트 병렬 분석과 상호 검증
신뢰하되 검증	불변 요구사항은 루트 CLAUDE.md에, 장기 작업은 루프로, 평가 셋 유지, 훅을 하드 게이트로
다시 짓기 전제	git worktree로 격리 재구축, 재작성은 플랜 모드부터
프로토타입에서 프로덕션으로	내부 제작, 내부 사용, 검증 후 고객 제품 승격

기업 관점에서 보면

이 가이드에서 한국 기업이 눈여겨볼 대목은 화려한 수치가 아니라 규칙 3입니다. Zingage의 567줄 불변 조건 문서와 Cainex의 골든 셋 운영은, 에이전트 자동화의 성패가 도구가 아니라 조직이 자기 기준을 문서로 적어낼 수 있느냐에 달려 있음을 보여줍니다. 국내 도입 현장에서 흔히 보는 실패는 도구를 먼저 사고 기준 문서화를 뒤로 미루는 순서입니다. 그럴듯한 코드가 빠르게 쌓이다가 아키텍처 이탈이 감당 불가능해지는 경로는 회사 규모와 무관하게 재현됩니다. 비용 관리 관점의 함정은 이전 글 "[활용] Claude Code, 같은 작업인데 왜 비용이 다르게 나오는가"에서 다룬 그대로입니다.

규칙 1도 국내 조직에는 생각보다 무거운 과제입니다. 비개발 직군이 배포까지 가려면 권한, 리뷰 절차, 책임 소재를 먼저 정리해야 하고, 이는 교육과 제도 설계의 문제입니다. 코텍시스는 바이브코딩과 업무 자동화 교육에서 이 순서를 강조합니다. 도구 사용법보다 CLAUDE.md와 스킬로 팀 표준을 적어내는 훈련, 검증 루프를 먼저 세우는 훈련이 실제 도입 성과를 가릅니다. 관련 교육은 https://cortexys.team/ko/ax/training/claude 에서 확인할 수 있습니다.

출처

• The Claude Code guide for startups, Michael Segner, Anthropic, 2026-08-20: https://claude.com/blog/claude-code-guide-for-startups