StrongDM 사례로 보는 AI 소프트웨어 팩토리와 디지털 트윈 테스트

핵심 요약

StrongDM은 "인간이 코드를 쓰거나 리뷰하지 않는다"는 극단적 원칙으로, LLM 에이전트만으로 대형 소프트웨어를 개발하는 실험을 진행하고 있다.

이들은 코드와 테스트를 모두 에이전트가 작성하는 상황에서 신뢰성을 확보하기 위해, 시나리오 기반 검증과 디지털 트윈(서비스 복제) 우주라는 독특한 테스트 체계를 구축했다.

이 방식은 비용이 크지만, 향후 개발자가 "코드를 짓는 사람"에서 "코드를 짓는 시스템을 설계·감독하는 사람"으로 바뀌는 미래를 보여준다.

소프트웨어 팩토리와 다크 팩토리 개념

StrongDM이 시도하는 구조는 말 그대로 "소프트웨어 공장"이다.

사양 문서와 시나리오만 주어지면, 에이전트들이 코드 작성, 테스트 실행, 수정·개선을 자동으로 반복하면서 최종 결과물까지 도달하려고 한다.

여기서 인간은 공장 속 작업자가 아니라 라인 전체를 설계하고 지켜보는 공장 관리자에 가깝다.

Dan Shapiro가 언급한 "Dark Factory"는 사람이 눈으로 코드를 보지도 않는, 불이 꺼진 공장 같은 상태를 뜻하며, StrongDM은 이 수준에 최대한 가까이 가려 한다.

"코드는 인간이 쓰지도, 리뷰하지도 않는다" 원칙

StrongDM 팀은 아예 규칙으로 "코드는 인간이 작성해서는 안 되며, 코드 리뷰도 인간이 해서는 안 된다"는 제약을 걸었다.

즉, 개발자는 설계와 요구사항, 시나리오, 시스템 구조를 정의할 뿐, 실제 구현과 검토는 전부 에이전트에게 맡긴다.

이는 단순한 자동화가 아니라, 인간이 개입하기 쉬운 구멍을 일부러 막아 둠으로써 "에이전트만으로 어디까지 가능한가"를 실험하는 강한 형태의 제약 실험이다.

이 원칙 때문에 가장 어려운 문제가 생긴다. 인간이 코드를 보지 않는다면, 그 결과물을 어떻게 믿을 수 있을까 하는 신뢰성의 문제다.

LLM 코딩 능력의 전환점과 맥락

이 실험은 모델 성능이 일정 수준을 넘었기 때문에 가능해졌다.

작성자는 2025년 11월, Claude Opus 4.5와 GPT 5.2가 나오면서 "에이전트가 복잡한 코딩을 장기적으로 수행하는 능력"이 크게 안정되었다고 본다.

StrongDM 팀은 그보다 조금 앞선 2024년 말, Claude 3.5(특히 10월 버전)에서 "시간이 길어질수록 오류가 쌓이는 게 아니라, 오히려 정답에 수렴하는" 장기 코딩 흐름을 관찰했다.

이 전환점 이후, "에이전트가 큰 시스템 전체를 짓는 것"이 실험 단계를 넘어 진지하게 고려할 수 있는 옵션이 되었다.

시나리오 기반 검증과 'satisfaction' 개념

코드와 테스트를 모두 에이전트가 만든다면, 단순한 단위 테스트 성공 여부만으로는 신뢰할 수 없다.

StrongDM은 여기서 "시나리오 테스트"라는 오래된 개념을 변형해 사용한다.

시나리오는 하나의 끝에서 끝까지 이어지는 사용자 이야기다. 예를 들어 "새 직원이 입사해, Okta 계정이 생성되고, 슬랙과 Jira 권한이 자동으로 부여되는 과정 전체"처럼 실제 사용자의 행동을 따라가는 서사다.

이들은 성공을 "테스트가 전부 통과했는가?" 같은 이진 기준 대신, 여러 시나리오를 반복 실행했을 때 "사용자가 만족할 것 같은 결과가 나왔을 확률", 즉 만족도(satisfaction)를 측정한다.

많은 궤적(여러 차례 실행된 시나리오 결과)을 보고, LLM이 "이건 사용자 입장에서 만족스러웠다/불만족스러웠다"를 판단해 비율을 계산하는 식이다.

시나리오를 '홀드아웃 세트'로 다루는 아이디어

핵심은 시나리오를 코드베이스 바깥, 에이전트가 직접 볼 수 없는 곳에 따로 보관한다는 점이다.

머신러닝에서 학습에 쓰지 않고 평가에만 쓰는 '홀드아웃 세트'처럼, 이 시나리오들은 개발보다 검증 단계에만 사용된다.

이렇게 하면 에이전트가 "테스트 코드까지 포함된 레포 전체"를 보며 자기에게 유리하게 맞춰 버리는, 일종의 치팅을 줄일 수 있다.

결국 개발 과정에서 에이전트가 알고 있는 조건과, 나중에 품질을 평가하는 조건이 분리되기 때문에, 실제 사용자에 더 가까운 검증이 가능해진다.

디지털 트윈 유니버스: 외부 SaaS의 복제 세계

StrongDM이 만든 가장 인상적인 구조는 "디지털 트윈 유니버스(Digital Twin Universe)"다.

이것은 Okta, Slack, Jira, Google Docs, Drive, Sheets 등 외부 SaaS를, 내부에서 마음껏 쓸 수 있는 복제 버전으로 구현한 세계다.

실제 서비스 대신 이 복제본에 대량의 요청을 보내며 테스트하면, 요금 폭탄, 레이트 리밋, 보안 시스템 오탐 같은 현실 제약 없이 수많은 실패 케이스를 시도해 볼 수 있다.

권한 관리처럼 보안에 민감한 시스템도, 실제 회사의 Slack·Okta에 손대지 않고 "쌍둥이 환경"에서 마음껏 깨뜨려 보며 검증할 수 있다.

디지털 트윈 구현 전략: 문서+SDK 호환

이 많은 복제 서비스를 어떻게 만들까? 여기서도 코딩 에이전트가 핵심 역할을 한다.

StrongDM은 각 SaaS의 공개 API 문서를 에이전트에게 통째로 주고, 해당 API를 그대로 흉내 내는 Go 바이너리를 만들게 한다. 여기에 간단한 UI까지 얹어 완전한 실험 환경으로 만든다.

여기서 중요한 프롬프트 전략이 하나 더 있다.

각 SaaS의 인기 있는 공식/레퍼런스 클라이언트 SDK를 "호환성 기준"으로 삼고, "이 SDK가 정상 동작할 정도로 100% API 호환을 맞추라"고 지시하는 방식이다.

즉, 문서만 읽고 모사하는 것이 아니라, 실제 널리 쓰이는 클라이언트 코드가 문제 없이 돌아가는지를 기준으로 디지털 트윈의 충실도를 검증하는 것이다.

비대화형 코딩 에이전트 'Attractor'와 개발 흐름

StrongDM은 이 공장의 핵심 엔진인 코딩 에이전트를 'Attractor'라고 부른다.

흥미로운 점은, Attractor의 공개 저장소에는 코드가 없고, 오직 매우 자세한 사양 문서만 있다는 것이다. 사용자는 이 사양을 자신의 에이전트(예: Cursor, Claude, GPT 등)에 먹여서 직접 구현하게 되어 있다.

이 방식 자체가 StrongDM 철학을 상징적으로 보여준다. "우리는 코드 대신 설계를 공개하고, 코드는 당신의 에이전트가 알아서 짓게 하라"는 메시지에 가깝다.

Attractor는 사람-에이전트가 대화하며 수정하는 인터랙티브 모드가 아니라, "사양→코드→테스트→수정" 사이클을 에이전트끼리 자동으로 굴리는 비대화형 개발 흐름을 지향한다.

cxdb: 대화와 도구 실행을 위한 AI 컨텍스트 저장소

StrongDM은 또 다른 핵심 구성 요소로 'cxdb'라는 AI 컨텍스트 저장소를 공개했다.

cxdb는 에이전트가 주고받은 대화, 호출한 도구의 입력과 출력, 중간 산출물 등을, 변경 불가능한 DAG(그래프) 구조로 저장한다.

이는 단순 로그를 넘어, "이 결과물이 어떤 생각과 어떤 도구 호출의 연쇄를 통해 나왔는지"를 추적할 수 있는 전체 계보를 만들어 준다.

에이전트 기반 개발에서는 이런 계보가 중요하다. 에이전트가 실수했을 때 어디서 논리가 꼬였는지, 어떤 프롬프트와 도구 조합이 효과적이었는지 분석하는 데 큰 도움이 되기 때문이다.

Gene Transfusion, Semports, Pyramid Summaries 기법

StrongDM은 자신들이 사용하는 몇 가지 기법에 이름을 붙여 공유한다.

'Gene Transfusion'은 기존 시스템에서 패턴(아키텍처, 에러 처리 방식, API 설계 등)을 뽑아 다른 프로젝트에 이식하는 것을 뜻한다. 마치 유전자를 추출해 다른 생명체에 옮기는 비유다.

'Semports'는 코드의 의미를 유지한 채, 한 언어에서 다른 언어로 이식하는 포팅을 가리킨다. 기존 포팅처럼 줄줄이 재작성하기보다, 에이전트가 의미 레벨에서 구조를 이해하고 대응 언어로 다시 구축하는 방향에 가깝다.

'Pyramid Summaries'는 같은 정보에 대해 여러 단계의 요약을 계층 구조로 만들어 두는 방식이다. 에이전트는 먼저 짧은 요약들만 훑으며 전반을 파악하고, 필요할 때 긴 요약이나 원문으로 "줌인"해 들어간다.

이런 기법들은 본질적으로 "에이전트가 더 큰 코드베이스와 복잡한 맥락을 잘 다루게 하기 위한 정보 구조화 전략"으로 볼 수 있다.

비용 문제와 비즈니스적 함의

StrongDM 팀은 "엔지니어 1인당 하루 1,000달러 정도의 토큰 비용을 쓰지 않으면, 아직 최적화 여지가 있다"는 식의 도발적인 기준을 제시한다.

이 수준이면 엔지니어 한 명당 월 2만 달러에 가까운 추가 비용이 들기 때문에, 순수 기술 관점에서는 흥미롭더라도 비즈니스 측면에서는 매우 무거운 선택이 된다.

이런 고비용 구조에서는, 이 방식을 쓴 덕분에 제품 출시 속도나 품질이 얼마나 압도적으로 좋아지는지, 그리고 그것이 시장에서 충분한 수익으로 돌아오는지가 핵심 질문이 된다.

또한, 누군가가 어려운 방식으로 힘들게 만든 기능을, 다른 회사가 몇 시간의 에이전트 작업으로 복제할 수 있는 시대라면, "기능 자체"보다 "데이터, 배포, 고객 관계, 브랜드" 같은 다른 경쟁 요소가 더 중요해질 수 있다.

개발자의 역할 변화와 실용적 시사점

이 실험은 개발자의 역할이 바뀌고 있음을 보여준다.

앞으로 개발자는 직접 코드 줄을 치는 사람이라기보다, "에이전트가 코드를 어떻게 쓰고 검증하도록 할지"를 설계하는 시스템 디자이너이자 감독관의 역할이 커질 가능성이 높다.

개인이나 작은 팀이 StrongDM처럼 하루에 수천 달러를 쓰기는 어렵지만, 몇 가지 아이디어는 바로 참고할 수 있다. 예를 들어,

에이전트에게 코드와 테스트를 모두 맡기더라도, 실제 사용자 시나리오(입사, 탈퇴, 주문 취소, 환불 등)를 별도로 정의해 두고, 이 시나리오를 기준으로 결과물을 점검하는 습관을 들일 수 있다.

또한, 중요한 외부 서비스가 있다면, 최소한 일부 핵심 API만이라도 간단한 "미니 디지털 트윈"을 만들어 놓고, 실서비스를 건드리지 않고 공격적으로 테스트해 보는 것도 현실적인 응용이 될 수 있다.

인사이트

StrongDM 사례는 "사람이 코드를 안 써도, 잘만 설계하면 상당히 복잡한 시스템까지 만들어질 수 있다"는 가능성을 보여준다.

하지만 동시에, 신뢰성을 확보하려면 시나리오 기반 검증, 디지털 트윈, 컨텍스트 저장소, 정보 구조화 등 주변 인프라가 엄청나게 중요하다는 점도 드러난다.

지금 당장은 비용과 위험 때문에 모든 팀이 이 수준의 자동화를 따라 할 수는 없지만, "사람이 하는 일은 무엇이고, 에이전트가 할 일은 무엇인가?"를 재정의하는 훈련을 시작하는 것만으로도 큰 이득을 얻을 수 있다.

현실적인 시작점은 간단하다. 사용자 시나리오를 텍스트로 명확히 적어 두고, 에이전트가 작성한 코드에 대해 "이 시나리오 관점에서 결과가 정말 만족스러운가?"를 계속 묻는 것부터 시작해 볼 수 있다.

출처 및 참고 : How StrongDM’s AI team build serious software without even looking at the code