소프트웨어 팩토리와 에이전트 시대의 도래
(factory.strongdm.ai)- StrongDM AI팀은 코드를 보지 않고도 고품질 소프트웨어를 만드는 Software Factory 개념을 주장
- 명세/시나리오 기반으로 에이전트가 코드를 작성하고, 테스트 하네스를 실행, 인간의 검토 없이 수렴하는 비대화형 개발 방식
- 코드는 사람이 작성하거나 검토해서는 안 되며, 엔지니어당 하루 최소 1,000달러 이상의 토큰 비용을 지출해야 소프트웨어 팩토리가 제대로 작동함
- Claude 3.5 2차 개정판(2024년 10월)부터 장기 에이전트 코딩 워크플로우가 오류 누적 대신 정확성을 복리로 축적하기 시작하며 비대화형 개발 가능성이 확인됨
- 기존 테스트 개념을 확장해 시나리오(scenario) 와 만족도(satisfaction) 를 도입, LLM이 사용자 만족도를 확률적으로 평가하는 체계 구축
- Digital Twin Universe(DTU) 를 통해 Okta, Jira, Slack 등 주요 SaaS를 복제해 대규모 검증을 수행하며, 프로덕션 한계를 초과하는 볼륨과 속도로 시나리오 검증 가능
- 에이전트 시대는 소프트웨어 경제학을 근본적으로 변화시켜, 과거에는 경제적으로 불가능했던 고충실도 SaaS 복제본 구축이 이제 일상적 작업이 됨
Software Factory 개념
-
명세(specs) 와 시나리오(scenarios) 가 에이전트를 구동해 코드를 작성하고 검증하는 비대화형 개발 체계
- 인간의 코드 작성 및 리뷰를 금지하고, 모든 개발 과정을 에이전트가 수행
- 하루 엔지니어당 1,000달러 이상의 토큰 사용량을 기준으로 효율성을 측정
- 이 접근법은 인간의 개입 없이 코드가 자동으로 생성·검증·수렴하는 자율적 소프트웨어 생산 환경 구축을 목표로 함
StrongDM AI 팀의 출범
- 2025년 7월 14일 StrongDM AI 팀이 결성되어 비대화형 개발 실험을 시작
- 참여자: Jay Taylor, Navan Chauhan, Justin McCarthy(공동 창립자 겸 CTO)
- 2024년 말 Claude 3.5(10월 개정판) 이후 장기적 코드 작성의 정확도가 향상되어, 반복적 오류 누적 대신 정확도 축적(compounding correctness) 이 가능해짐
- Cursor의 YOLO 모드를 통해 모델의 장기 코드 작성 능력이 명확히 드러남
- 이전 모델에서는 LLM을 코딩 작업에 반복 적용 시 오해, 환각, 구문 오류, 버전 DRY 위반, 라이브러리 비호환 등 모든 종류의 오류가 누적되어 앱이 "붕괴"했음
- Anthropic의 업데이트된 모델과 YOLO 모드가 결합되며 비대화형 개발 또는 성장한 소프트웨어의 첫 가능성 확인
핵심 원칙: 손 떼기
- AI 팀의 첫날 첫 시간에 헌장 수립, 가장 중요한 원칙: "코드는 사람이 직접 작성하면 안 됨"
- 초기에는 단순한 직관과 실험: 손으로 코드를 전혀 작성하지 않고 얼마나 멀리 갈 수 있는가?
- 처음에는 한계 봉착, 테스트 추가 후 진전 시작
- 에이전트가 즉각적 작업에 집착하며 지름길 선택: return true로 좁게 작성된 테스트는 통과하지만 실제 원하는 소프트웨어로 일반화되지 않음
- 단순 테스트만으로는 부족, 통합 테스트, 회귀 테스트, 종단간 테스트, 행동 테스트로 확장 필요
테스트에서 시나리오와 만족도로 전환
- 에이전트 시대의 반복 주제: 새로운 언어 필요, "테스트"라는 단어가 불충분하고 모호함
- 코드베이스에 저장된 테스트는 코드에 맞춰 게으르게 재작성되거나, 코드가 테스트를 사소하게 통과하도록 재작성될 수 있음
- 시나리오라는 용어를 재정의: 엔드투엔드 사용자 스토리를 나타내며, 코드베이스 외부에 저장(모델 훈련의 "홀드아웃" 세트와 유사), LLM이 직관적으로 이해하고 유연하게 검증 가능
- 성장시키는 소프트웨어 자체가 에이전트 컴포넌트를 포함하므로, 성공 여부를 단순한 불리언 값 대신 확률적·경험적 만족도(satisfaction) 로 전환
- 만족도: 모든 시나리오를 통과한 관찰된 궤적 중 사용자를 만족시킬 가능성이 있는 비율 정량화
Digital Twin Universe를 통한 시나리오 검증
- 이전 체제에서는 통합 테스트, 회귀 테스트, UI 자동화로 "작동하는가?" 를 판단
- 기존 신뢰할 수 있던 기법의 두 가지 한계 발견:
- 테스트가 너무 경직적: 에이전트로 코딩하고 LLM과 에이전트 루프를 설계 프리미티브로 구축하므로, 성공 평가에 종종 LLM-as-judge 필요
- 테스트가 보상 해킹에 취약: 모델의 부정행위에 덜 취약한 검증 필요
-
Digital Twin Universe(DTU) 가 해답: 소프트웨어가 의존하는 서드파티 서비스의 행동(behavioral) 클론
- Okta, Jira, Slack, Google Docs, Google Drive, Google Sheets의 트윈 구축, API, 엣지 케이스, 관찰 가능한 행동 복제
- DTU를 통해 프로덕션 한계를 훨씬 초과하는 볼륨과 속도로 검증 가능
- 라이브 서비스에 대해서는 위험하거나 불가능한 실패 모드 테스트도 가능
- 속도 제한 도달, 남용 탐지 트리거, API 비용 누적 없이 시간당 수천 개의 시나리오 실행 가능
비전통적 경제학
- DTU를 통한 성공은 에이전트 시대(Agentic Moment)가 소프트웨어 경제학을 근본적으로 변화시킨 여러 방식 중 하나를 보여줌
- 주요 SaaS 애플리케이션의 고충실도 클론 생성은 항상 가능했지만 경제적으로 실현 불가능했음
- 여러 세대의 엔지니어가 테스트용 CRM의 전체 인메모리 복제본을 원했지만, 관리자에게 제안조차 하지 않음(거절 예상)
- 소프트웨어 팩토리 구축자는 의도적 순진함(deliberate naivete) 실천 필요: Software 1.0의 습관, 관습, 제약을 찾아서 제거
- DTU를 통해 6개월 전에는 상상할 수 없었던 것이 이제는 일상적 작업으로 루틴화
다음 읽어볼 것들
-
Principles : 에이전트를 이용한 소프트웨어 개발에 대한 우리의 믿음
- 시드 → 검증 하네스 → 피드백 루프 구조로 소프트웨어를 성장시키며, 토큰이 연료 역할 수행
- 모든 소프트웨어는 초기 시드 필요: 과거의 PRD나 명세서, 현재는 몇 문장, 스크린샷, 기존 코드베이스로도 가능
- 검증 하네스는 종단간이어야 하며 실제 환경(고객, 통합, 경제성)에 최대한 근접해야 함
- 출력 샘플을 입력으로 피드백하는 폐쇄 루프가 시스템의 자체 수정과 정확성 복리 축적 가능하게 함
- 검증과 피드백 이론은 이해하기 쉽지만, 실무는 창의적이고 최첨단 엔지니어링 필요: 모든 장애물을 모델이 이해할 수 있는 표현으로 변환하는 방법 모색
-
Techniques : 이러한 원칙을 적용하기 위한 반복적인 패턴
-
Digital Twin Universe (DTU)
- 중요한 서드파티 의존성의 외부 관찰 가능한 행동을 복제
- 프로덕션 한계를 훨씬 초과하는 볼륨과 속도로 검증
- 결정적이고 재생 가능한 테스트 조건 제공
-
Gene Transfusion
- 에이전트를 구체적 예시에 지정하여 코드베이스 간 작동 패턴 이동
- 좋은 참조와 쌍을 이룬 솔루션을 새로운 컨텍스트에서 재생산 가능
-
Filesystem
- 모델이 저장소를 빠르게 탐색하고 파일 읽기/쓰기로 자체 컨텍스트 조정
- 디렉토리, 인덱스, 온디스크 상태가 실용적 메모리 기반으로 작동
-
Shift Work
- 대화형 작업과 완전히 명세화된 작업 분리
- 의도가 완전할 때(명세, 테스트, 기존 앱), 에이전트가 왕복 없이 종단간 실행 가능
-
Semport
- 의미론적으로 인식하는 자동화된 포팅, 일회성 또는 지속적 수행
- 의도를 보존하면서 언어 또는 프레임워크 간 코드 이동
-
Pyramid Summaries
- 여러 줌 레벨에서 가역적 요약
- 전체 세부사항으로 다시 확장할 수 있는 능력을 잃지 않고 컨텍스트 압축
-
Digital Twin Universe (DTU)
-
Products : 우리가 매일 사용하는 도구이며, 다른 사람들에게도 유용할 것이라고 생각하는 것들
- CXDB 는 AI 에이전트를 위한 자체 호스팅 컨텍스트 저장소로, Turn DAG, blob 중복 제거, 동적 타입, 시각적 디버깅 제공
- StrongDM ID 는 인간, 워크로드, AI 에이전트를 위한 아이덴티티 시스템으로 연합 인증과 경로 범위 공유 지원
- Attractor 는 페이즈 그래프로 구조화된 비대화형 코딩 에이전트로, 작업이 완전히 명세화되었을 때 종단간 실행
스펙 주도 개발, 멀티 에이전트 써서 개발해 봤습니다. 일을 많이 줄여 주는 건 사실이지만 LLM의 성능 한계 때문에 고객이 만족할 만한 제품은 못 만듭니다. 100% 대체는 불가능하고 인간의 작업이 어느 정도 필요합니다.
너무 자극적이긴 한데, 어느 정도 이해가 가기도 하고.. 뭔가 기분이 이상해지는 글이네요.
이 글을 보고 아래 글을 보면 더 공감 됩니다.
우리의 장인 정신을 애도합니다
Hacker News 의견들
-
나는 Digital Twin Universe 개념에 공감함
내 코드베이스도 외부 서비스 통합이 많아서 테스트 시 외부 호출을 막으면 거의 아무것도 검증할 수 없었음
그래서 Okta, Jira, Slack, Google Docs 등처럼 각 API의 가짜 구현체를 만들어 테스트함
다만 UI까지 복제하진 않고 API 동작만 흉내냈음 -
“엔지니어 1인당 하루 $1,000 토큰을 안 쓰면 개선 여지가 있다”는 말은 너무 비현실적으로 들림
이게 진짜 주장인지 의심스러움-
계산해보면 연간 약 $250k 수준임
만약 AI가 그만큼의 생산성을 낸다면 합리적일 수도 있음
현실적으로는 두 명의 주니어 엔지니어 정도의 효율일 듯함
결국 인간은 리드 역할로 계획과 검증만 담당하게 될 것 같음
과장된 낙관론이긴 하지만 완전히 미친 얘기는 아님 -
나는 월 $20짜리 Claude, OpenAI 구독만 쓰고 있음
토큰 다 쓰면 산책하거나 책 읽음
가속주의자는 아니지만 그래도 일은 충분히 함 -
나는 StrongDM 팀 중 한 명임
하루 $1,000 토큰을 쓰는 건 쉽지만, 생산적으로 쓰는 건 어렵다는 게 핵심임 -
이건 단순한 허세처럼 보임
“우린 너희보다 더 AI에 앞서 있다”는 신호 보내기 같음 -
글을 읽으며 민망함을 느꼈음
기존의 mocks나 시뮬레이션 테스트를 “혁신”처럼 포장한 느낌임
그래도 이들이 비용 구조를 솔직히 드러낸 점은 인정함
-
-
나는 그들의 사이트에서 실제 코드나 제품을 찾고 있었음
유일하게 찾은 건 strongdm/attractor였음
“캐나다 여자친구 코딩”이 이제 비즈니스 모델이 된 셈임
추가로 strongdm/cxdb도 발견했지만 커밋 히스토리가 정리돼 있었음-
cxdb 저장소에 실제 코드가 있음
-
이게 미친 건지 미래의 단면인지는 모르겠음
-
Products 페이지에 데이터베이스와 ID 시스템도 있음
여러 에이전트가 협업하려면 공유 컨텍스트와 권한 시스템이 필수적임 -
BoundaryML의 BAML 관련 웨비나를 들었음
Spec-driven development는 인간이 루프 안에 있는 구조화된 워크플로우를 만드는 접근임
/research → /plan → /implement루프를 명확히 정의하고, 각 단계에서 인간 검증을 거치게 함
StrongDM의 “인간이 코드를 쓰거나 읽지 않는다”는 주장과는 정반대의 철학임 -
또 하나의 공허한 블로그 글처럼 느껴짐
실질적인 결과물은 없고, $1,000/일 토큰 이야기는 투자자 어필용 같음
-
-
검증 문제를 해결하지 못하면 이 모든 건 허세에 불과함
자동 리뷰나 가드레일을 세워도 결국 사양과 결과의 일치를 확인할 사람은 인간임-
우리는 Speedscale에서 트래픽 캡처와 재생으로 검증을 자동화하고 있음
-
사실 인간 개발도 완벽하지 않음
코드 리뷰, 테스트, QA 등 여러 체계적 검증 절차가 이미 존재함
중요한 건 AI가 완벽하냐가 아니라 시스템 전체 품질이 수렴하느냐임
내 경험상 Opus 4.5 기준으로는 약간의 순이익 효과가 있음 -
나도 거의 동의함
핵심은 생성보다 검증임
여러 독립 에이전트가 서로 이견을 드러내며 합의하는 구조를 만들고 있음 -
간단히 말해, 검증과 보안 테스트를 최종 사용자에게 떠넘기는 셈임
-
명세 기반 언어와 정형 검증을 더 적극적으로 써야 함
결국 프로그래밍이란 “명세를 구체화하는 행위”로 재정의될 것임
-
-
하루 $1,000 토큰이라면 인간보다 AI에 더 많은 돈을 쓰는 셈임
이건 AI 비전의 붕괴 지점처럼 보임-
Simon Willison이 글을 업데이트했다고 함
-
연간 $240k면 신입 FANG 엔지니어 급임
솔직히 Claude보다 못한 주니어도 많음
결국 소수의 인간이 꼭대기에 있는 피라미드 구조로 재편될 듯함 -
만약 같은 일을 5일 만에 끝낼 수 있다면, 속도 대비 비용은 합리적일 수 있음
-
산출물이 비례해 커진다면 비용 대비 효율은 맞을 수도 있음
게다가 토큰 단가도 내려갈 가능성이 있음
-
-
법률·보험 업계는 이 변화에 가장 고전할 것임
인간의 실수는 모델링 가능하지만, 자율 루프의 연쇄 오류는 완전히 다른 문제임- 보험업계는 단순하게 갈 것 같음
AI의 결정은 결국 인간의 책임으로 귀결될 것임
이게 전체 agentic shift의 제동장치가 될 듯함
- 보험업계는 단순하게 갈 것 같음
-
하루 $1,000 토큰은 말도 안 되는 지표임
코드 품질이 나쁘면 토큰 소모가 폭증함
결국 정리되지 않은 코드베이스가 비용을 키움
하루 천 달러를 태우는 팀이라면 효율은 거의 없을 것임
(참고: 이 짤)-
단기 vs 장기 최적화의 문제임
지금 효율을 높일지, 시스템 전체를 개선할지의 선택임 -
어쩌면 이제야 경영진이 리팩터링의 중요성을 깨달을지도 모름
-
-
나는 예전에 언급했던 Dark Factory 패턴의 팀이 바로 이들이었음
관련 글을 썼는데, 이 팀은 가장 야심찬 실험자들임-
하지만 실제로는 결과물이 거의 없음
대학생 몇 명에게 $10k 주면 더 나은 걸 만들 듯함 -
하루 $1,000 토큰이라니, 내 팀 예산으로는 꿈도 못 꿀 일임
개인적으로도 생활비 때문에 불가능함
결국 “해도 망하고 안 해도 망하는” 기분임 -
검증 가능한 결과가 없으면 그저 말뿐임
이제 말조차도 LLM 덕분에 훨씬 싸졌음 -
윤리적 공개가 필요함
사이트의 용어는 기존 개념을 새로 포장한 수준임
“Digital Twin Universe”는 mocks, “Gene Transfusion”은 참고 코드 읽기, “Semport”는 트랜스파일링임
실제 데이터나 벤치마크는 전무함
AI 마케팅이 엔지니어링 통찰로 포장된 사례임 -
사실 대부분의 핵심 코드는 이미 GitHub에 있음
진짜 차별점은 메커니즘 설계와 가치관임
미래는 정형 검증(formal methods)과 AI의 결합으로 갈 것임
-
-
“시나리오를 holdout set으로 두고 테스트하는 방식”이 흥미로움
QA 팀의 공격적 테스트를 모방하는 개념임
빌드 팀과 버그 탐지 팀을 분리해 상호 경쟁 구조로 만드는 게 인상적임
다만 하루 $1,000 토큰은 오픈소스 개발자에겐 절망적임-
로컬 모델을 쓰면 비용을 줄일 수 있음
이 스레드처럼 로컬 에이전트 자동화도 충분히 가능함 -
언젠가 에이전트들이 서로 뇌물 주고받는 상황이 올지도 모름
-
나는 여전히 인간이 루프 안에 있는 방식을 선호함
무작정 토큰을 태우는 건 낭비임
-
-
나는 “LLMs aren’t tools” 글에서 LLM 활용의 정신적 프레임워크를 탐구했음
“소프트웨어 공장”은 현재의 종착점이지만, 그 다음 단계는 LLM을 하나의 애플리케이션으로 보는 것임
즉, 단순한 워크플로우 자동화가 아니라 맞춤형 하네스를 만드는 단계임