AI-네이티브 스타트업을 만드는 방법

• AI가 반복 업무를 야간에 처리하는 동안 창업자는 제품 개선에 집중하는 새로운 운영 모델로, 진짜 변화는 시간 사용이 아니라 회사가 학습·반복·진화하는 속도에 있음
• AI-네이티브 회사는 운영 모델 자체가 바뀌어, 적은 인원이 덜 조율하고 에이전트가 반복 작업을 실행하며 사람은 방향·취향·관계·검증·책임에 집중함
• 전환은 업무 매핑, 컨텍스트 시스템 구축, 가장 단순한 자동화 선택, 반복 업무의 스킬화, 품질을 판정하는 eval 작성, 주간 개선 루프 실행의 단계로 진행됨
• 모델은 매월 교체·개선되며 서로 비슷해지므로, 회사만의 자산은 컨텍스트와 eval 같은 운영 체계임
• 모두가 같은 모델을 쓰는 환경에서 진짜 해자는 규율(discipline), 즉 매주 업무를 매핑하고 컨텍스트를 쌓고 eval을 쓰고 루프를 돌리는 일관성에 있음

---

두 스타트업의 대비

• 같은 시장에서 같은 달에 창업한 두 회사를 오전 9시에 비교
  • 첫 번째 회사는 운영 리드가 밀린 지원 티켓을 처리하고, 분석가가 지난주 대시보드를 다시 만들며, 창업자는 아무도 해결 못 한 고객 통화 건으로 스탠드업 중 - 모두 어제의 문제를 수습하느라 제품은 정체
  • 두 번째 회사는 그 모든 일을 밤새 에이전트가 처리 - 티켓 분류, 대시보드 갱신, 통화 속 이탈 위험(churn risk) 표면화 완료, 창업자는 이미 문제를 고치고 팀과 제품을 개선 중
• 핵심 차이는 학습 속도로, 두 번째 회사가 매일 더 빨리 배워 수주·수개월·수년에 걸쳐 레버리지가 복리로 누적됨

1단계 - 업무 매핑 (Map The Work)

• 지난 2주간 반복된 업무를 모두 나열 - 고객 통화 노트, 리드 리서치, 아웃바운드 초안, 지원 분류, 제품 QA, 온보딩, 릴리스 노트, 투자자 업데이트, 주간 지표, 버그 재현, 채용 스크리닝, 인보이스 검토, 경쟁사 모니터링 등
  • 반복되면 인코딩 후보이며, 대부분 창업자 캘린더에 20~40개 항목이 존재
  • 초기 팀이 정직하게 나열하면 이미 루틴이던 10~15개를 발견

• 자율성 레벨 분류

  • L1은 사람 전용 - 전략적 결정, 최종 채용, 큰 환불, 법적 서명, 이사회 커뮤니케이션
  • L2는 AI 준비·사람 승인 - 투자자 업데이트 초안, 계약 레드라인, 가격 페이지 재작성, 지원 매크로
  • L3는 AI 실행·사람 감독 - 인바운드 분류, 미팅 노트 라우팅, 리드 보강, 테스트 생성
  • L4는 명확한 한계 안에서 자율 - 경쟁사 모니터링, 야간 리포트 생성, 알려진 벤더 인보이스 추출, 단순 이상 탐지

• 지루한 워크플로가 보통 승리

  • 주간 전략 메모처럼 그럴듯한 업무보다, 매일 반복되는 지원 태깅이 10배 자주 실행되어 더 많은 시간을 회수하고 깨끗한 정답 데이터를 제공 - 빈도가 명성을 이김
  • 첫 공략 대상은 빈번하고, 측정 가능하고, 되돌릴 수 있고, 실제 병목과 연결된 작업

• 자동화하면 안 되는 업무

  • 드물거나, 불명확하거나, 높은 신뢰가 필요하거나, 불안정한 업무는 제외
  • C.H. Robinson 팀은 하루 1만 건 이메일 분류를 L4로 밀었다가 감독이 불가능해 L2로 복귀 - 물량이 오분류 비용을 가림
  • 좋은 결과물이 무엇인지 설명 못 하면 인코딩 준비가 안 된 것이며, 한 번의 잘못된 출력이 고객 관계를 해칠 수 있으면 천천히 진행

• 시작 구성

  • 1페이지와 3개 워크플로로 출발 - 개인(인박스 분류, 데일리 브리프, 투자자 업데이트 초안), 고객 대면(통화 종합, 티켓 분류, 리드 보강), 내부(테스트 생성, 인보이스 추출, 주간 지표 서술)
  • 동시에 너무 많은 실험은 주의를 분산시켜 20개의 미완성 파일럿을 만드는 가장 흔한 실패 모드 유발

2단계 - 컨텍스트 시스템 구축 (Build The Context System)

• 컨텍스트는 AI-네이티브 스타트업의 운영 기억(operating memory) 으로, 회사가 자신에 대해 아는 모든 것을 에이전트가 읽을 수 있는 곳에 보관
  • 모델은 교체 가능하지만 컨텍스트는 진짜 회사만의 자산 - 공동창업자처럼 일하는 에이전트와 혼란스러운 임시직처럼 일하는 에이전트를 가름
  • 출력 재작성에 검토보다 더 많은 시간이 든다면, 문제는 프롬프트나 모델이 아니라 에이전트가 회사를 충분히 모르는 것

• 주간 진단법

  • 대표 작업 하나를 워크스페이스 컨텍스트만 가진 새 에이전트에게 주고 다음 행동 3가지를 요청
  • 강한 제안이 2개 이상이면 컨텍스트가 제 역할, 일반적 답변 3개면 컨텍스트가 빈약해 프롬프트로 구제 불가

• Git 저장소 기반

  • 모든 팀원과 에이전트가 읽을 수 있는 공유 Git 저장소 하나로 시작 - 버전 관리·diff·사람과 에이전트 모두 읽기 가능·특정 벤더 런타임에 종속되지 않음
  • 7일차 워크스페이스는 CLAUDE.md, context/company.md, context/product.md, context/customers.md, context/lessons.md, 그리고 활성 작업용 GTD.md를 담은 단일 루트로 구성 가능
  • 손으로 쓴 40~60줄로 유지 - 피해야 할 것의 촘촘한 목록이 생성된 400줄의 잡문보다 우수

• 권한 경계로 분할

  • 성장하면 공유 회사 저장소 + 기능별 비공개 저장소(영업, 제품, 엔지니어링, 재무, 지원), 또는 프로젝트·고객별 비공개 저장소 + 회사 전체 공유 루트
  • 엔터프라이즈 규모에서는 자체 호스팅 Gitea, GitHub Enterprise, GitLab 같은 비공개 Git 서버로 디렉터리·저장소 단위 권한 부여
  • Block의 내부 하네스 Goose는 역할별 스코프로 동일 아티팩트 스트림을 읽으며, 스코프가 어긋나는 순간 공개 발언과 비공개 거래 컨텍스트를 섞기 시작 - 경계가 매우 중요

• 시스템에 들어가는 3종 데이터

  • 커넥터 - SaaS, API, MCP 서버, 이메일, 캘린더, CRM, 지원, 분석, GitHub, Linear, Stripe, 웨어하우스, 문서에서 외부 데이터 수집
    • 모든 커넥터는 식별자, 스코프 권한, 감사 로그, 관리되는 자격증명이 필요하며 그렇지 않으면 최대 보안 구멍이 됨 - Zitadel 같은 IAM 레이어가 식별 규율 담당
    • Anthropic의 MCP 코드 실행 작업은 서버 폴더 파일시스템 패턴으로 모든 도구 정의를 미리 로드하는 방식 대비 컨텍스트 사용을 약 15만 토큰에서 약 2천 토큰으로, 98.7% 절감
  • 회사가 생성하는 데이터 - 스펙, 고객 요약, 결정, 교훈, 프로젝트 노트, 운영 규칙, 기본은 Markdown
    • 가장 중요한 규칙은 원본(raw)과 정제본(distilled) 분리 - 통화 녹취가 원본, 그 통화에서 내린 결정·고객 이의·후속 담당자·갱신 위험이 정제본이며 에이전트가 실제 조회하는 대상
    • 결정 로그는 한 줄에 하나씩 append-only로 유지해 추론이 결론과 함께 따라가게 함
  • 데이터베이스와 스트림 - Postgres 제품 데이터, 웨어하우스 마케팅, 분석 이벤트처럼 원천이 이미 사는 곳
    • Markdown으로 맹목 복사하지 말고 DB를 원천으로 두며, 에이전트에 제한된 읽기 사용자 부여, 스키마를 에이전트용 파일(data-models/postgres.md)에 문서화, 허용 쿼리·쓰기를 명시
    • 기본적으로 에이전트가 프로덕션 데이터를 삭제 불가하게 설정 - 2025년 중반 Replit 사건(코딩 에이전트가 세션 중 프로덕션 DB를 지움)은 프롬프트 지시가 보안 경계가 아님을 상기시킴

• 고급 버전과 출처 추적

  • 구조화된 컨텍스트 그래프 - 에이전트가 조회하기 전 원본을 사람·회사·이의·약속·기능 요청·갱신 위험·후속·날짜·결정·소스 링크 등 엔티티와 관계로 처리
    • 녹취를 저장하는 대신 내용을 추출해 같은 사람·프로젝트의 통화를 체인으로 연결, "Vandelay Industries의 갱신 위험은?"에 정확한 발언 줄을 인용해 답변 가능
  • 모든 요약은 출처(녹취, 티켓, 커밋, 인보이스, DB 행)로 되짚을 수 있어야 함 - 출처가 없으면 검증 불가한 그럴듯한 요약이 쌓이고 첫 오답에서 에이전트 전체에 대한 신뢰가 붕괴
    • 출처가 있으면 에이전트는 감사 가능해져 팀원이 클릭 한 번으로 소스를 확인하고 이견을 수초 내 해결

3단계 - 가장 단순한 자동화 선택 (Choose The Simplest Automation)

• 모든 워크플로를 에이전트로 만들지 말 것 - 최고의 시스템은 스크립트, AI 보조 사람, 결정론적 워크플로, 에이전트의 혼합
  • 창업자의 역할은 품질 기준을 넘기면서도 안전하게 돌릴 수 있는 가장 가벼운 도구를 선택하는 것

• 도구별 적용

  • 스크립트 - 결정론적 단계(리포트 내보내기, CSV 변환, 테스트 실행, 링크 확인, JSON 검증, 주간 지표 팩 포매팅)
  • AI 보조 사람 - 회사를 떠나기 전 판단이 필요한 출력(투자자 업데이트, 창업자 이메일, 가격 카피, 계약 노트)
  • 워크플로 - 단계가 사전에 알려진 경우(통화 수집→요약→이의 추출→CRM 노트 작성→후속 생성), 엔진은 LangGraph, Temporal, Inngest, Prefect가 순서·재시도·관측성 담당
  • 에이전트 - 경로를 미리 정할 수 없는 경우(프로덕션 버그 조사, 시장 리서치, 비정상 지원 케이스, 엉킨 고객 계정)
    • Browserbase의 bb 에이전트는 Slack 대면 범용 에이전트로 작업마다 다른 스킬 파일과 스코프 권한을 로드 - 작업별 봇을 따로 만드는 것보다 우수(봇들이 시간이 지나면 서로 어긋나기 때문)

• 하네스(Harness) - 6단계 안전 레이어

  • Preflight - 에이전트가 토큰을 쓰기 전 컨텍스트와 권한 확인
  • Plan - 작업 분해 및 제안 단계 노출
  • Approve - 사람 또는 판정 모델 게이트가 나쁜 계획을 실행 전 차단
  • Execute - 작업 실행
  • Verify - 테스트·스키마·루브릭·예시로 출력 검증
  • Log - 다음 반복이 정답을 갖도록 일어난 일을 실행 파일에 기록

• 가드레일은 코드와 설정에 (프롬프트 아님)

  • "프로덕션 데이터를 삭제하지 마"라는 프롬프트는 보안 경계가 아님
  • 협상 불가 항목 - 실행·일일 비용 상한, 재시도 상한, 최대 도구 호출 깊이, 에이전트별 스코프 자격증명, 승인 없는 프로덕션 쓰기 금지, 코드 자동 머지 금지, 전 함대 킬 스위치
  • 2025년 내내 발생한 재귀 생성 사건(에이전트가 자식 에이전트를 계속 호출)은 하네스가 따라잡기 전까지 실제 비용을 발생 - 상한은 모델이 지시를 무시할 기회 전, 런타임에 두어야 함

4단계 - 스킬과 eval 인코딩 (Encode Skills And Evals)

• 여기까지는 모두 준비이며, 반복 업무를 스킬로 인코딩하고 eval로 채점하는 것이 회사를 매주 조금씩 복리로 성장시키는 엔진
  • 스킬은 반복 작업을 위한 재사용 지침 + 예시 - 두 번 손으로 실행 후 반복되는 부분을 인코딩
  • 모든 스킬은 명확한 형태 필요 - 범위, 입력, 로드할 컨텍스트, 절차, 출력 형식, 예시, 에스컬레이션 규칙, 소유자, 실행 로그
  • 무엇을 받고·반환하고·언제 도움을 청하고·누가 유지하는지 적혀 있지 않으면 그것은 스킬이 아니라 긴 프롬프트

• 스킬 템플릿 예시 (customer-call-synthesis)

  • Scope: 녹취 확보 후 영업 통화 / Inputs: 녹취, 계정 기록, 제품 컨텍스트, 진행 중 기회
  • Load: ICP, 가격, 제품 로드맵, 이의 분류 체계 / Steps: 사실 추출→이의 군집화→위험 식별→후속 작성
  • Output: CRM 노트·고객 브리프·기능 요청·다음 행동 / Examples: 예상 노트가 달린 이전 통화 3건
  • Escalate: 법적·보안 이슈, 이탈 위험, 엔터프라이즈 가격 / Owner: revenue lead / Eval: 예상 추출 필드가 달린 과거 통화 30건

• 창업자 친화 스킬부터 시작

  • 고객 통화 종합 - 원본 녹취에서 이의, 기능 요청, 위험, 약속, 다음 행동 추출
  • 인박스 분류 - 투자자·고객·채용·운영 메시지 정렬 및 앞 3종 답장 초안
  • 투자자 업데이트 - 지표와 결정에서 서술 작성 후 양쪽 인용
  • 가격 페이지 분석 - 라이브 페이지를 최신 고객 이의 로그와 비교
  • 주간 지표 서술 - 무엇이 바뀌고·깨지고·점검할지 설명
  • 테스트 생성 - 스펙을 테스트와 초안 PR로 전환

• eval의 3개 레이어 (순서대로 누적)

  • 첫째, 손 라벨링 정답 - 사람이 실제 예시에서 좋은 출력이 무엇인지 표시
  • 둘째, 결정론적 검사 - 비용 제로에 명확한 판정 제공(스키마 유효성, 소스와 일치하는 숫자, 해석되는 링크, 존재하는 인용, 통과하는 테스트)
  • 셋째, LLM 판정 - 결정론적 검사가 닿지 못하는 부분만(글 품질, 감정, 브리프 부합 여부), 작고 빠른 모델로 충분하되 신뢰 전 사람 표시 예시로 보정 필요

• 사례 연구: 고객 통화 종합

  • 과거 통화 30건을 revenue lead가 표시 - 중요한 사실, 이의, 위험, 후속
  • 결정론적 확인 - 이름·계약상 금액·후속 날짜의 주(week) 정확성, 그리고 브리프가 통화처럼 들리는지는 LLM 판정이 담당
  • 약 50회 실행 후 보통 같은 두 가지가 깨짐 - 3명 이상 통화에서 화자 추적 실패, 또는 서로 다른 두 이의를 하나로 병합 - 이를 클러스터 단위로 고쳐 일관 동작까지 재작성

• 사례 연구: 아웃바운드 리드 분류

  • 과거 리드 300건을 창업자가 ICP 적합 여부 yes/no로 표시
  • 기계적 확인 - 실재 회사 여부, 웹사이트 로드, 직원 수 기입 / 나머지는 ICP 설명 대비 LLM 판정
  • eval이 갖춰지면 오픈소스 프롬프트 진화 루프(GEPA, DSPy)가 라벨 대비 분류 프롬프트를 밤새 재작성 - 창업자는 최종 프롬프트를 읽지 않으며 eval 판정만이 중요

• eval 성숙 5단계

  • 1. 예시 하나 수동 점검 → 2) 작성된 루브릭으로 소수 사례 채점 → 3) 그 루브릭을 과거 20~300건에 적용 → 4) 에이전트가 본 적 없는 홀드아웃 세트로 테스트 → 5) 스킬이 움직이려던 비즈니스 지표 추적

• 출시 후 좋은 상태 유지 - 매주 6개 숫자

  • 수용률(acceptance rate), 오버라이드율, 실행당 비용, 사이클 타임, 검토 시간, 사건 수
  • 수용률이 핵심 - 약 70% 미만(사소한 편집은 수용으로 계산)이면 자율성 레벨을 올릴 준비가 안 된 것
  • 수용률이 낮을 때 프롬프트 재작성은 거의 정답이 아니며, 보통 네 가지 중 하나 - 런타임에 컨텍스트 추가, 스킬 범위 좁히기, 파일에 작동 예시 추가, 맡지 말았어야 할 케이스에 대한 명확한 에스컬레이션 규칙 작성

5단계 - 팀을 AI-네이티브로 (Make The Team AI-Native)

• 창업자가 먼저 시작 - 팀을 새 운영 방식으로 옮기는 가장 빠른 길은 회사 맥락 안에서 라이브로 보여주는 것
  • 캘린더·인박스·Slack에서 밤새 끌어온 아침 브리프, 어제 통화의 고객 종합, 스펙 대비 에이전트가 연 테스트 PR, 마지막 지표 팩으로 만든 투자자 업데이트 초안을 시연
  • 목표는 캘리브레이션 - 에이전트 레이어가 할 수 있는 것과 없는 것을 직접 보는 것
  • Jack Dorsey는 2025년 내내 매일 아침 수 시간 이 도구들을 직접 다룬 뒤 Block을 재편 - 거대한 효율화 구조조정으로 이어졌고 결정은 에이전트를 직접 써본 리더십에서 나옴

• 첫날부터 설치, 온보딩은 산출물로 종료

  • 모든 팀원이 첫 세션에서 그날 배포 가능한 산출물(정리된 고객 브리프, 지원 매크로, 테스트 PR, 가격 페이지 비평)을 들고 나옴 - 실제 작업을 만들지 못하는 교육은 다음 주면 잊힘
  • Ramp의 Glass 도구는 매 온보딩 세션이 새 사람의 스킬·아티팩트 1개를 공유 라이브러리에 추가하며 끝나는 규칙으로 3개월 만에 일일 사용자 20명에서 약 700명으로 증가

• 사람의 역할은 커짐

  • 사람은 시스템을 설계하고 관계를 소유하고 출력을 판단하고 책임을 짊 / 에이전트는 실행 담당
  • 좁은 작업만 돌리는 팀원은 이 모델에서 노출되며, 판단을 지침·예시·eval로 바꾸는 사람은 이전보다 더 가치 있음

• 채용도 변화

  • 역할을 여는 기준이 높아짐 - 예전에 채용이 필요하던 일부가 이제 스킬이므로, 진짜 사람이 필요한 일에만 새 역할 배정
  • 채용 시 잡지식 대신 주어진 시간 안에 손으로 못 끝낼 큰 프로젝트를 주고 에이전트를 어떻게 지휘하는지 관찰 - 판단·취향·에이전트가 빗나갈 때 복구하는 능력을 봄
  • 실제 예 - 분석가는 3시간 안에 소스 수집·증거 추출·다듬어진 브리프까지 실제 리포트, 엔지니어는 하루 안에 실제 제품 표면 복제 또는 스펙 기반 내부 도구 제작(테스트 포함), 그로스 채용자는 50~100개 회사 대상 시장 맵·캠페인 계획(스크래핑·군집화·작성·우선순위) - 모두 시간 내 손으로 완료 불가가 핵심

6단계 - 스타트업을 피드백 루프로 운영 (Run As A Feedback Loop)

• AI-네이티브 스타트업은 매주 운영 체계를 개선 - 처음으로 돌아가 다시 시작
  • 리뷰가 다룰 것 - 에이전트가 한 일, 사람이 오버라이드한 지점, 실패한 eval, 누락된 컨텍스트, 좁혀야 할 스킬, 죽일 워크플로, 자율성 레벨을 올릴 워크플로

• 동시에 두 루프 실행

  • 이너 루프 - 기존 작업 개선(실행당 비용↓, 사이클 타임↓, 사건↓, 아티팩트당 검토 시간↓)
  • 아우터 루프 - 다음을 탐색(신규 고객 세그먼트, 제품 아이디어, 가격 변경, 파트너십, 경쟁사 움직임, 규제 변화, 이탈 위험), 백그라운드 에이전트가 후보를 24시간 공급하고 사람이 추격 대상 선택

• 소프트웨어 팩토리 (이너 루프의 가장 큰 부분)

  • 사람이 스펙과 테스트를 쓰고 에이전트가 그에 맞춰 구현, 결정론적 검사는 스스로 돌고 머지 전 사람이 검토
  • 수용 기준이 명확하고 영향 범위가 작은 곳부터 시작 - 테스트 생성, 의존성 업그레이드, 마이그레이션, 내부 도구, 통합 스캐폴드, QA 스크립트, 보안 자동 수정
  • 두 가지 하드 룰 - 어떤 것도 자동 머지되지 않음, 어떤 에이전트도 프로덕션에 쓰지 않음
    • Cursor조차 대규모 자율 클라우드 에이전트를 돌리면서도 2026년 초까지 머지에 사람 검토 게이트 유지 - 이 게이트가 나머지를 안전하게 확장하게 함

• 시장 학습 시스템 (아우터 루프)

  • 통화 기록, 이의 추출, 기능 요청 군집화, 경쟁사 추적, 사용 변화 관찰, 지원 패턴 읽기, 잃은 거래 연구
  • 발견을 가설로 전환 후 가장 강한 것을 테스트 - 고객 대화, 랜딩 페이지 테스트, 제품 실험, 데이터에 대한 새 쿼리
  • 에이전트가 제안하고 사람이 선택 - 전략의 제안과 결정을 모두 에이전트에 맡기면 무난한 합의로 정착하거나 가장 올리기 쉬운 지표를 언덕 오르듯 최적화함

• 회사 차원 자기 개선의 핵심 = eval 작성 능력

  • 수백 개 예시를 좋음/나쁨으로 손 라벨링하고 eval을 만들어 프롬프트 진화 루프에 연결 - GEPA, DSPy 같은 프레임워크가 작은 반영 모델로 프롬프트 변이를 제안하고 eval이 라벨 세트에서 순위를 매겨 승자를 배포, 반복
  • 창업자는 eval을 쓰고 실패 클러스터를 읽되, 진화된 프롬프트는 쓰지도 읽지도 않음
  • 발목을 잡는 것은 에이전트 역량이 아니라 좋음의 기준을 인코딩할 수 있느냐 - 코딩은 도움이 되나 병목이 아니며, 출력을 신뢰성 있게 좋음/나쁨으로 표시할 수 있는 도메인 전문가가 전체 루프를 돌릴 수 있음
  • eval은 하중을 지탱하는 핵심 아티팩트이며, eval 작성이 멈추는 순간 회사의 복리 성장도 멈춤

결론

• 천재나 큰 팀이 필요한 것이 아니라 업무를 매핑하고 컨텍스트를 쌓고 eval을 쓰고 매주 루프를 돌리는 규율이 필요 - 모두가 같은 모델을 쓰는 지금, 운영 체계가 비밀 무기