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

5 days ago 9

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 작성이 멈추는 순간 회사의 복리 성장도 멈춤