StrongDM의 AI 팀은 코드조차 보지 않고 어떻게 제대로 된 소프트웨어를 만드는가

URL: https://simonwillison.net/2026/Feb/7/software-factory/

Title: StrongDM의 AI 팀은 코드조차 보지 않고 어떻게 제대로 된 소프트웨어를 만드는가

2026년 2월 7일

지난주 나는 Dan Shapiro가 다크 팩토리(The Dark Factory) 수준의 AI 도입이라고 부른, 인간이 코딩 에이전트가 만들어내는 코드를 아예 들여다보지도 않는 팀의 데모를 봤다는 이야기를 살짝 언급한 적이 있다. 그 팀은 StrongDM의 일부였고, 방금 그들이 Software Factories and the Agentic Moment에서 자신들이 어떻게 일하는지에 대한 첫 공개 설명을 공유했다.

우리는 소프트웨어 팩토리(Software Factory) 를 만들었다: 스펙 + 시나리오가 에이전트를 구동해 코드를 작성하고, 하네스(harness)를 실행하며, 인간 리뷰 없이 수렴(converge)하는 비-대화형(non-interactive) 개발 방식이다. [...]

kōan(선문답) 혹은 만트라 형태로 말하면:

• 왜 내가 이걸 하고 있지? (함의: 모델이 대신 해야 한다)

규칙 형태로는:

• 코드는 인간이 작성해서는 안 된다

• 코드는 인간이 리뷰해서는 안 된다

마지막으로 실무적 형태로는:

• 인간 엔지니어 1명당 오늘 최소 토큰에 1,000달러를 쓰지 않았다면, 당신의 소프트웨어 팩토리에는 개선 여지가 있다

이 중에서 의심할 여지 없이 가장 흥미로운 건 “코드는 인간이 리뷰해서는 안 된다”다. LLM이 비인간적인 실수를 얼마나 자주 저지르는지 우리 모두 알고 있는데, 그게 어떻게 도대체 말이 되는 전략일까?

최근 많은 개발자들이 2025년 11월의 변곡점—Claude Opus 4.5와 GPT 5.2가 등장하면서 코딩 에이전트가 지시를 얼마나 안정적으로 따르고 복잡한 코딩 작업을 수행할 수 있는지가 한 단계 넘어섰다는 시점—을 인정하는 걸 봤다. StrongDM의 AI 팀은 2025년 7월에, 더 이른 변곡점(Claude Sonnet 3.5 관련)을 기반으로 출범했다.

촉매는 2024년 말에 관측된 전환이었다: Claude 3.5의 두 번째 개정판(2024년 10월)부터 장기 지평(long-horizon)의 에이전트형 코딩 워크플로가 오류가 아니라 정확성(correctness) 을 누적(compound)하기 시작했다.

2024년 12월이 되자 Cursor의 YOLO 모드를 통해 모델의 장기 지평 코딩 성능은 명백해졌다.

그들의 새 팀은 “손으로 코딩한 소프트웨어는 없다(no hand-coded software)”라는 규칙으로 시작했다. 2025년 7월에는 급진적이었지만, 2026년 1월 현재 나는 숙련된 개발자들 사이에서도 이걸 채택하기 시작하는 경우를 꽤 많이 보고 있다.

그들은 곧바로 뻔한 문제에 부딪혔다. 손으로 아무것도 작성하지 않는다면, 코드가 실제로 동작한다는 걸 어떻게 보장할까? 에이전트에게 테스트를 쓰게 하는 것도, 그들이 속임수로 assert true 같은 걸 넣지 않는다는 전제하에서만 도움이 된다.

지금 소프트웨어 개발에서 가장 중대한 질문은 이것 같다. 구현과 테스트가 모두 코딩 에이전트에 의해 작성되는 상황에서, 어떻게 지금 만들고 있는 소프트웨어가 동작한다는 것을 증명할 수 있을까?

StrongDM의 해답은 시나리오 테스트(Scenario testing) (Cem Kaner, 2003)에서 영감을 얻었다. StrongDM의 설명은 이렇다:

우리는 시나리오(scenario) 라는 단어를, 엔드투엔드 “유저 스토리”를 표현하는 의미로 재정의했다. 시나리오는 종종 코드베이스 바깥에 저장되며(모델 학습에서의 “홀드아웃(holdout)” 세트처럼), LLM이 직관적으로 이해하고 유연하게 검증할 수 있다.

우리가 키우는 소프트웨어 상당 부분 자체가 에이전트적(agentic) 구성요소를 갖고 있기 때문에, 우리는 성공을 불리언으로 정의(“테스트 스위트가 초록이다”)하는 방식에서 확률적이고 경험적인 방식으로 전환했다. 우리는 이 검증을 정량화하기 위해 만족도(satisfaction) 라는 용어를 사용한다. 모든 시나리오를 통과하는 모든 관측된 궤적(trajectory)들 중, 어느 비율이 유저를 만족시킬 가능성이 있는가?

시나리오를 홀드아웃 세트처럼 다룬다는 아이디어—소프트웨어를 평가하는 데 쓰되, 코딩 에이전트가 볼 수 있는 곳에는 저장하지 않는다는 것—은 정말 매력적이다. 이는 외부 QA 팀이 공격적으로 테스트하는 전통적 방식(비싸지만 품질 보장에 매우 효과적인 방식)을 흉내 낸다.

그리고 여기서 StrongDM의 디지털 트윈 유니버스(Digital Twin Universe, DTU) 개념으로 이어진다. 내가 본 데모에서 가장 강한 인상을 준 부분이다.

그들이 만들고 있던 소프트웨어는 연결된 여러 서비스 묶음(suite) 전반에서 사용자 권한을 관리하는 데 도움을 주는 것이었다. 이것만으로도 눈에 띄었다. 보안 소프트웨어는 ‘리뷰되지 않은 LLM 코드’로 만들어질 것이라고 기대하는 마지막 분야이기 때문이다!

[디지털 트윈 유니버스는] 우리 소프트웨어가 의존하는 서드파티 서비스들의 행동(behavior)을 복제한 클론이다. 우리는 Okta, Jira, Slack, Google Docs, Google Drive, Google Sheets의 트윈을 만들어 그들의 API, 엣지 케이스, 관측 가능한 동작들을 복제했다.

DTU를 통해 우리는 프로덕션 한도를 훨씬 초과하는 볼륨과 속도로 검증할 수 있다. 라이브 서비스에 대고는 위험하거나 불가능한 실패 모드도 테스트할 수 있다. 레이트 리밋에 걸리지 않고, 어뷰즈 탐지를 촉발하지 않으며, API 비용을 누적하지 않은 채 시간당 수천 개의 시나리오를 실행할 수 있다.

Okta, Jira, Slack 등의 중요한 부분을 어떻게 클론하나? 코딩 에이전트로 한다!

내가 이해한 바로는 핵심 요령이 이랬다. 해당 서비스 중 하나의 전체 공개 API 문서를 에이전트 하네스에 통째로 덤프하고, 그 API의 모방품(imitation)을 자체 포함(self-contained) 된 Go 바이너리로 만들게 한다. 그리고 시뮬레이션을 완성하는 데 도움이 되도록 그 위에 간단한 UI를 덧씌우게 할 수 있다.

업데이트: DTU 제작자 Jay Taylor가 Hacker News에 이와 관련한 추가 맥락을 올렸는데, DTU와 공식(정전, canonical) SaaS 서비스 사이의 높은 충실도(fidelity)를 보장하기 위한 핵심 프롬프팅 전략을 공유했다.

반복 가능한 전략으로 이어진 초기 핵심 통찰이 하나 있었다. DTU와 공식 정전 SaaS 서비스 사이의 높은 수준의 충실도를 보장하기 위해서:

가장 널리 쓰이는 공개 레퍼런스 SDK 클라이언트 라이브러리들을 호환성 타깃으로 삼고, 언제나 목표는 100% 호환성으로 둔다.

그들만의 독립적인 서비스 클론—레이트 리밋이나 사용량 쿼터에서 자유로운—을 갖게 되자, 시뮬레이션된 테스터 군단은 마음껏 난리를 칠 수 있게 됐다. 시나리오 테스트는 새 시스템이 만들어지는 동안 계속 실행되는 에이전트용 스크립트가 되었다.

아래는 그들의 Slack 트윈 스크린샷인데, 테스트 과정이 어떻게 작동하는지(서로 다른 시뮬레이션 시스템들에 접근 권한이 곧 필요해질 시뮬레이션 Okta 사용자들의 흐름이 어떻게 보이는지)를 보여준다.

Slack의 일부를 유용하게 클론해 빠르게 띄울 수 있다는 능력은, 새 세대 코딩 에이전트 도구들이 얼마나 파괴적인지 보여준다.

중요한 SaaS 애플리케이션의 고충실도 클론을 만드는 일은 언제나 가능했지만, 경제적으로는 불가능했다. 여러 세대의 엔지니어들이 테스트를 위해 CRM의 완전한 인메모리 복제본을 원했을 수도 있지만, “그걸 만들자”는 제안을 스스로 검열하며 접었을 것이다.

기법(techniques) 페이지도 볼 만하다. 디지털 트윈 유니버스 외에도, 에이전트가 기존 시스템에서 패턴을 추출해 다른 곳에서 재사용하도록 하는 유전자 수혈(Gene Transfusion), 한 언어의 코드를 다른 언어로 직접 이식(port)하는 Semports, 에이전트가 짧은 요약을 빠르게 열거(enumerate)하고 필요할 때 더 자세한 정보로 확대(zoom in)할 수 있도록 여러 수준의 요약을 제공하는 피라미드 요약(Pyramid Summaries) 같은 용어들도 소개한다.

StrongDM AI는 소프트웨어도 몇 가지 공개했는데, 방식도 그에 걸맞게 색다르다.

github.com/strongdm/attractor는 그들의 소프트웨어 팩토리 핵심에 있는 비-대화형 코딩 에이전트 Attractor다. 그런데 이 저장소(repo)에는 코드가 아예 없다. 대신 소프트웨어 스펙을 아주 꼼꼼하게 설명한 마크다운 파일 3개만 있고, README에는 “이 스펙을 원하는 코딩 에이전트에 넣어라”라는 메모가 있다!

github.com/strongdm/cxdb는 좀 더 전통적인 형태의 공개로, Rust 16,000줄, Go 9,500줄, TypeScript 6,700줄로 구성되어 있다. 이건 그들의 “AI 컨텍스트 스토어(AI Context Store)”로, 대화 기록과 도구 출력(tool outputs)을 불변(immutable) DAG에 저장하는 시스템이다.

이건 내 LLM 도구의 SQLite 로깅 메커니즘과 비슷하지만 훨씬 더 정교하다. 여기서 아이디어를 좀 유전자 수혈해와야 할지도 모르겠다!

미래를 엿본 걸까?#

나는 10월에 초대받은 소규모 방문자 그룹의 일원으로 StrongDM AI 팀을 방문했다.

Justin McCarthy, Jay Taylor, Navan Chauhan으로 이루어진 3인 팀은 불과 3개월 전에 결성됐는데, 이미 코딩 에이전트 하네스의 동작 데모, 6개 서비스 정도에 대한 디지털 트윈 유니버스 클론, 시나리오를 따라 움직이는 시뮬레이션 테스트 에이전트 무리(swarm)까지 갖추고 있었다. 그리고 그 데모는, 한 달 뒤 에이전트 코딩을 눈에 띄게 더 신뢰할 수 있게 만든 Opus 4.5/GPT 5.2 출시 이전의 일이었다.

그건 소프트웨어 개발의 한 가지 가능한 미래를 엿본 느낌이었다. 소프트웨어 엔지니어가 코드를 직접 만드는 데서, 코드를 만드는 시스템을 만들고(그리고 반쯤 모니터링하는) 쪽으로 이동하는 미래. 다크 팩토리.

잠깐, 엔지니어 1인당 하루 1,000달러?#

이 포스트의 첫 공개 버전에서는 이 디테일을 대충 넘겼지만, 꽤 진지하게 주목할 만하다.

이런 패턴들이 정말로 엔지니어 1명당 월 2만 달러를 예산에 추가한다면, 내게는 흥미가 훨씬 떨어진다. 그러면 이건 소프트웨어 개발 방식 얘기라기보다 비즈니스 모델 연습이 된다. 이 방식으로 개발하는 막대한 오버헤드를 감당할 수 있을 만큼 충분히 수익성 있는 제품 라인을 만들 수 있느냐?

경쟁자가 코딩 에이전트 몇 시간만으로 당신의 최신 기능을 복제할 수 있는 상황이라면, 지속 가능한 소프트웨어 비즈니스를 만드는 모습도 완전히 달라진다.

나는 이 패턴들이 훨씬 더 낮은 비용으로도 적용될 수 있기를 바란다. 개인적으로 나는 월 200달러짜리 Claude Max 플랜만으로도 다양한 에이전트 패턴을 실험할 공간이 충분하다고 느낀다. 물론 나는 24/7 QA 테스터 스웜을 돌리고 있진 않지만!

토큰 비용으로 수천 달러를 태우지 않을 팀이나 개인에게도 StrongDM에서 배울 건 많다고 생각한다. 특히 내가 집착하는 질문은 이것이다. 에이전트가 만들어낸 코드의 모든 줄을 사람이 리뷰하지 않고도, 에이전트가 자신의 코드가 동작한다는 것을 증명하려면 무엇이 필요할까?