$50M으로 'agent 스트레스 테스트 디지털 월드'를 짓는다 — 1인 바이브코더가 그대로 가져올 5단계

핵심 요약 (TL;DR)

Patronus AI가 6월 25일 Greenfield Partners 리드로 $50M Series B를 클로즈했습니다. 누적 펀딩 $70M, 지난 1년 매출 15배 성장입니다. 핵심 출시물은 "digital world models" — 웹사이트와 내부 시스템, 문서, API를 그대로 시뮬레이션한 디지털 트윈 안에서 agent를 reinforcement learning으로 스트레스 테스트합니다. 1인 바이브코더가 같은 발상을 자기 SaaS에 mini 버전으로 도입하는 5단계 가이드를 제시합니다.

모델 벤치마크 시대는 끝났습니다

지난 몇 년간 모델 평가의 표준은 LMArena와 HELM 같은 벤치마크였습니다. "어떤 모델이 더 똑똑한가"를 답하는 도구죠. 그런데 production agent를 띄우는 사람의 질문은 이미 바뀌어 있습니다. "내 agent가 환경을 우회하지 않는가." "task를 단축하기 위해 reward hacking을 하지 않는가." "사용자 데이터를 실수로 노출하지 않는가." 이런 질문은 단일 모델 벤치마크로는 잡히지 않습니다. Patronus가 정의하려는 카테고리가 정확히 여기입니다.

방식은 자율주행을 시나리오 시뮬레이션으로 훈련시킨 Waymo의 발상을 agent에 옮긴 것입니다. 웹사이트, API, 문서, 내부 시스템을 그대로 본뜬 디지털 트윈 안에서 agent에게 task를 던지고, 성공에는 reward를 실패에는 penalty를 줍니다. 첫 vertical은 소프트웨어 엔지니어링과 금융. 즉 Claude Code, Cursor, Codex로 짠 agent들이 첫 시험 대상이라는 뜻입니다. 투자자가 TechCrunch에 남긴 한 줄이 흥미롭습니다. "Patronus는 hack을 잡아내는 게 강점이다." agent가 task를 우회하거나 단축하는 방식을 시뮬레이션 안에서 잡는다는 평가입니다.

1인 바이브코더가 mini 디지털 월드를 짜는 5단계

Patronus의 인프라를 그대로 살 일은 없을 겁니다. 하지만 같은 발상을 자기 SaaS에 mini 버전으로 깔 수 있습니다.

1단계: Mock sandbox. 자기 SaaS의 외부 의존성(외부 API, DB, 메일 발송)을 정확히 본뜬 mock 환경을 만듭니다. 실제 호출은 안 나가지만 응답 스키마와 에러 케이스는 production과 동일하게 흉내냅니다. 이것 하나만 깔아도 agent가 외부 시스템을 실수로 건드리는 사고의 90%가 잡힙니다.

2단계: Scripted scenario. "사용자가 이런 입력을 줬을 때 agent가 어떤 sequence로 동작해야 하는가"를 시나리오 30~50개로 적습니다. 정상 케이스와 함께 "사용자가 거짓 정보를 주는 경우", "외부 API가 timeout을 내는 경우", "데이터가 비어 있는 경우" 같은 엣지 케이스를 함께 적습니다.

3단계: 실패 sample 누적. Production에서 잡힌 실패 케이스를 시나리오 라이브러리에 자동으로 누적합니다. 한 번 실패한 케이스는 다음 릴리스 전에 시뮬레이션을 다시 통과해야 머지된다는 규칙을 세웁니다. 회귀 테스트와 동일한 사고방식을 agent에 적용하는 거죠.

4단계: Reward 정의. "task 성공", "단계 수", "사용자 데이터 노출 여부", "외부 호출 횟수" 같은 metric을 reward와 penalty로 정의합니다. 단순 boolean이 아니라 가중치를 둔 점수표를 만들면 "어떤 agent 버전이 더 안전한가"를 숫자로 비교할 수 있습니다. 예를 들면 이렇게 정의할 수 있습니다.

def score(run):
    reward = (
        100 * run.task_succeeded
        - 5 * run.step_count
        - 50 * run.external_calls
        - 1000 * run.leaked_user_data
    )
    return reward

5단계: CI 통합. Mock sandbox + scripted scenario + reward 정의를 CI 파이프라인에 묶습니다. Pull request마다 미니 시뮬레이션이 돌고, 통과 점수가 어제보다 떨어지면 자동으로 머지가 막힙니다. Patronus가 frontier lab에 파는 인프라의 1/100 사이즈이지만, 1인 바이브코더에게는 이것만으로 충분합니다.

Datadog이 투자한 의미

이번 라운드의 strategic 투자자에 Datadog과 Samsung이 들어가 있다는 점이 중요한 신호입니다. Datadog은 observability를 evaluation까지 확장하려는 의도가 분명합니다. APM 대시보드에 "agent eval 점수"가 한 줄 추가되는 다음 분기가 멀지 않은 거죠. 즉 production agent를 띄우는 회사는 곧 "내 agent의 평가 점수"를 다른 metric과 같이 보게 됩니다. 1인 바이브코더가 미리 mini 시뮬레이션을 깔아두면, 이 표준이 도착했을 때 자기 인프라를 거기에 맞춰 확장하기만 하면 됩니다.

같은 주에 OpenAI는 자체 칩을, 정부는 customer 단위 게이팅을, Patronus는 agent evaluator 카테고리를 동시에 정착시켰습니다. 모델을 직접 만드는 사람과 모델을 평가하는 사람의 분업이 회사 차원에서 굳어지는 중입니다. 1인 빌더에게도 같은 분업이 자기 워크플로 안에서 일어나야 한다는 신호입니다.

자주 묻는 질문 (FAQ)

Q. 시뮬레이션 환경을 처음부터 짜는 게 너무 무겁지 않나요?
처음에는 시나리오 10개만으로 시작해도 됩니다. 한 페이지짜리 mock과 인메모리 응답 dictionary만 깔아도 외부 사고의 대부분을 잡습니다. 핵심은 production 코드와 같은 인터페이스로 mock을 호출하는지입니다.

Q. Patronus를 직접 써야 하나요?
1인 바이브코더 단계에서는 자체 mini 버전이 충분합니다. 회사 규모로 커지고 frontier 모델 다수를 동시에 비교해야 할 시점이 되면 그때 외부 evaluator를 검토하는 게 합리적입니다.

Q. 어떤 metric부터 reward로 정의해야 하나요?
"task 성공 여부", "단계 수", "외부 호출 횟수" 세 가지로 시작하세요. 가장 자주 사고가 나는 자리가 이 세 곳입니다. 사용자 데이터 노출이나 권한 우회 같은 보안 metric은 시나리오가 안정된 다음 단계에 추가합니다.