# 소프트웨어 팩토리와 에이전트 시대의 도래 > Clean Markdown view of GeekNews topic #26493. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26493](https://news.hada.io/topic?id=26493) - GeekNews Markdown: [https://news.hada.io/topic/26493.md](https://news.hada.io/topic/26493.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-02-08T08:40:33+09:00 - Updated: 2026-02-08T08:40:33+09:00 - Original source: [factory.strongdm.ai](https://factory.strongdm.ai/) - Points: 13 - Comments: 3 ## Summary **소프트웨어 팩토리(Software Factory)** 는 사람이 코드를 작성하거나 검토하지 않고, 명세와 시나리오만으로 에이전트가 코드를 생성·검증하는 **비대화형 개발 체계**를 지향합니다. StrongDM AI 팀은 Claude 3.5 이후 모델의 **정확도 복리(compounding correctness)** 현상을 기반으로, 테스트 개념을 확장한 **시나리오·만족도 프레임워크**와 **Digital Twin Universe(DTU)** 를 통해 현실 SaaS 환경을 복제하며 대규모 검증을 수행합니다. 코드는 사람이 작성하거나 검토해서는 안 되며, 엔지니어당 하루 최소 1,000달러 이상의 토큰 비용을 지출해야 소프트웨어 팩토리가 제대로 작동한다는 다소 과격한 주장을 하고 있는데요. 맞다 틀리다 보다, 이제 이런 얘기들이 나온다는 현실을 인식하게 되는 글이네요. ## Topic Body - **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](https://factory.strongdm.ai/principles)** : 에이전트를 이용한 소프트웨어 개발에 대한 우리의 믿음 - **시드 → 검증 하네스 → 피드백 루프** 구조로 소프트웨어를 성장시키며, **토큰이 연료** 역할 수행 - 모든 소프트웨어는 초기 시드 필요: 과거의 PRD나 명세서, 현재는 몇 문장, 스크린샷, 기존 코드베이스로도 가능 - **검증 하네스는 종단간이어야 하며** 실제 환경(고객, 통합, 경제성)에 최대한 근접해야 함 - 출력 샘플을 입력으로 **피드백**하는 **폐쇄 루프**가 시스템의 자체 수정과 정확성 복리 축적 가능하게 함 - 검증과 피드백 이론은 이해하기 쉽지만, 실무는 창의적이고 최첨단 엔지니어링 필요: **모든 장애물을 모델이 이해할 수 있는 표현으로 변환하는 방법 모색** - **[Techniques](https://factory.strongdm.ai/techniques)** : 이러한 원칙을 적용하기 위한 반복적인 패턴 - **Digital Twin Universe (DTU)** - 중요한 서드파티 의존성의 **외부 관찰 가능한 행동을 복제** - 프로덕션 한계를 훨씬 초과하는 볼륨과 속도로 검증 - **결정적이고 재생 가능한 테스트 조건** 제공 - **Gene Transfusion** - 에이전트를 구체적 예시에 지정하여 **코드베이스 간 작동 패턴 이동** - 좋은 참조와 쌍을 이룬 솔루션을 새로운 컨텍스트에서 재생산 가능 - **Filesystem** - 모델이 저장소를 빠르게 탐색하고 파일 읽기/쓰기로 자체 컨텍스트 조정 - 디렉토리, 인덱스, 온디스크 상태가 **실용적 메모리 기반**으로 작동 - **Shift Work** - **대화형 작업과 완전히 명세화된 작업 분리** - 의도가 완전할 때(명세, 테스트, 기존 앱), 에이전트가 왕복 없이 종단간 실행 가능 - **Semport** - **의미론적으로 인식하는 자동화된 포팅**, 일회성 또는 지속적 수행 - 의도를 보존하면서 언어 또는 프레임워크 간 코드 이동 - **Pyramid Summaries** - 여러 줌 레벨에서 **가역적 요약** - 전체 세부사항으로 다시 확장할 수 있는 능력을 잃지 않고 컨텍스트 압축 - **[Products](https://factory.strongdm.ai/products)** : 우리가 매일 사용하는 도구이며, 다른 사람들에게도 유용할 것이라고 생각하는 것들 - **[CXDB](https://github.com/strongdm/cxdb)** 는 AI 에이전트를 위한 **자체 호스팅 컨텍스트 저장소**로, Turn DAG, blob 중복 제거, 동적 타입, 시각적 디버깅 제공 - **[StrongDM ID](https://id.strongdm.ai/)** 는 인간, 워크로드, AI 에이전트를 위한 **아이덴티티 시스템**으로 연합 인증과 경로 범위 공유 지원 - **[Attractor](https://github.com/strongdm/attractor)** 는 페이즈 그래프로 구조화된 **비대화형 코딩 에이전트**로, 작업이 완전히 명세화되었을 때 종단간 실행 ## Comments ### Comment 50814 - Author: pencil6962 - Created: 2026-02-08T11:24:44+09:00 - Points: 2 스펙 주도 개발, 멀티 에이전트 써서 개발해 봤습니다. 일을 많이 줄여 주는 건 사실이지만 LLM의 성능 한계 때문에 고객이 만족할 만한 제품은 못 만듭니다. 100% 대체는 불가능하고 인간의 작업이 어느 정도 필요합니다. ### Comment 50812 - Author: xguru - Created: 2026-02-08T11:15:37+09:00 - Points: 1 너무 자극적이긴 한데, 어느 정도 이해가 가기도 하고.. 뭔가 기분이 이상해지는 글이네요. 이 글을 보고 아래 글을 보면 더 공감 됩니다. [우리의 장인 정신을 애도합니다](https://news.hada.io/topic?id=26497) ### Comment 50807 - Author: neo - Created: 2026-02-08T08:40:33+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46924426) - 나는 **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](https://github.com/strongdm/attractor)였음 “캐나다 여자친구 코딩”이 이제 비즈니스 모델이 된 셈임 추가로 [strongdm/cxdb](https://github.com/strongdm/cxdb)도 발견했지만 커밋 히스토리가 정리돼 있었음 - [cxdb 저장소](https://github.com/strongdm/cxdb)에 실제 코드가 있음 - 이게 미친 건지 미래의 단면인지는 모르겠음 - [Products 페이지](https://factory.strongdm.ai/products)에 데이터베이스와 ID 시스템도 있음 여러 에이전트가 협업하려면 **공유 컨텍스트**와 권한 시스템이 필수적임 - [BoundaryML의 BAML](https://docs.boundaryml.com/guide/introduction/what-is-baml) 관련 웨비나를 들었음 **Spec-driven development**는 인간이 루프 안에 있는 구조화된 워크플로우를 만드는 접근임 `/research → /plan → /implement` 루프를 명확히 정의하고, 각 단계에서 **인간 검증**을 거치게 함 StrongDM의 “인간이 코드를 쓰거나 읽지 않는다”는 주장과는 정반대의 철학임 - 또 하나의 **공허한 블로그 글**처럼 느껴짐 실질적인 결과물은 없고, $1,000/일 토큰 이야기는 투자자 어필용 같음 - **검증 문제**를 해결하지 못하면 이 모든 건 허세에 불과함 자동 리뷰나 가드레일을 세워도 결국 **사양과 결과의 일치**를 확인할 사람은 인간임 - 우리는 Speedscale에서 **트래픽 캡처와 재생**으로 검증을 자동화하고 있음 - 사실 인간 개발도 완벽하지 않음 코드 리뷰, 테스트, QA 등 여러 **체계적 검증 절차**가 이미 존재함 중요한 건 AI가 완벽하냐가 아니라 **시스템 전체 품질이 수렴하느냐**임 내 경험상 Opus 4.5 기준으로는 약간의 **순이익 효과**가 있음 - 나도 거의 동의함 핵심은 **생성보다 검증**임 여러 독립 에이전트가 서로 **이견을 드러내며 합의**하는 구조를 만들고 있음 - 간단히 말해, 검증과 보안 테스트를 **최종 사용자에게 떠넘기는 셈**임 - 명세 기반 언어와 **정형 검증**을 더 적극적으로 써야 함 결국 프로그래밍이란 “명세를 구체화하는 행위”로 재정의될 것임 - 하루 $1,000 토큰이라면 인간보다 AI에 더 많은 돈을 쓰는 셈임 이건 **AI 비전의 붕괴 지점**처럼 보임 - Simon Willison이 [글을 업데이트](https://simonwillison.net/2026/Feb/7/software-factory/#wait-1-000-day-per-engineer-)했다고 함 - 연간 $240k면 신입 FANG 엔지니어 급임 솔직히 **Claude보다 못한 주니어**도 많음 결국 소수의 인간이 꼭대기에 있는 **피라미드 구조**로 재편될 듯함 - 만약 같은 일을 5일 만에 끝낼 수 있다면, **속도 대비 비용**은 합리적일 수 있음 - 산출물이 비례해 커진다면 **비용 대비 효율**은 맞을 수도 있음 게다가 토큰 단가도 내려갈 가능성이 있음 - **법률·보험 업계**는 이 변화에 가장 고전할 것임 인간의 실수는 모델링 가능하지만, **자율 루프의 연쇄 오류**는 완전히 다른 문제임 - 보험업계는 단순하게 갈 것 같음 AI의 결정은 결국 **인간의 책임**으로 귀결될 것임 이게 전체 **agentic shift의 제동장치**가 될 듯함 - 하루 $1,000 토큰은 **말도 안 되는 지표**임 코드 품질이 나쁘면 토큰 소모가 폭증함 결국 **정리되지 않은 코드베이스**가 비용을 키움 하루 천 달러를 태우는 팀이라면 효율은 거의 없을 것임 (참고: [이 짤](https://share.google/H5BFJ6guF4UhvXMQ7)) - 단기 vs 장기 최적화의 문제임 지금 효율을 높일지, 시스템 전체를 개선할지의 선택임 - 어쩌면 이제야 경영진이 **리팩터링의 중요성**을 깨달을지도 모름 - 나는 예전에 언급했던 **Dark Factory 패턴**의 팀이 바로 이들이었음 [관련 글](https://simonwillison.net/2026/Feb/7/software-factory/)을 썼는데, 이 팀은 **가장 야심찬 실험자**들임 - 하지만 실제로는 **결과물이 거의 없음** 대학생 몇 명에게 $10k 주면 더 나은 걸 만들 듯함 - 하루 $1,000 토큰이라니, 내 팀 예산으로는 **꿈도 못 꿀 일**임 개인적으로도 생활비 때문에 불가능함 결국 “해도 망하고 안 해도 망하는” 기분임 - 검증 가능한 결과가 없으면 **그저 말뿐**임 이제 말조차도 LLM 덕분에 훨씬 싸졌음 - 윤리적 공개가 필요함 사이트의 용어는 기존 개념을 새로 포장한 수준임 “Digital Twin Universe”는 mocks, “Gene Transfusion”은 참고 코드 읽기, “Semport”는 트랜스파일링임 실제 **데이터나 벤치마크**는 전무함 AI 마케팅이 엔지니어링 통찰로 포장된 사례임 - 사실 대부분의 핵심 코드는 이미 GitHub에 있음 진짜 차별점은 **메커니즘 설계와 가치관**임 미래는 정형 검증(formal methods)과 AI의 결합으로 갈 것임 - “시나리오를 holdout set으로 두고 테스트하는 방식”이 흥미로움 **QA 팀의 공격적 테스트**를 모방하는 개념임 빌드 팀과 버그 탐지 팀을 분리해 **상호 경쟁 구조**로 만드는 게 인상적임 다만 하루 $1,000 토큰은 오픈소스 개발자에겐 **절망적**임 - 로컬 모델을 쓰면 비용을 줄일 수 있음 [이 스레드](https://news.ycombinator.com/item?id=46838946)처럼 **로컬 에이전트 자동화**도 충분히 가능함 - 언젠가 에이전트들이 서로 **뇌물 주고받는** 상황이 올지도 모름 - 나는 여전히 **인간이 루프 안에 있는 방식**을 선호함 무작정 토큰을 태우는 건 낭비임 - 나는 [“LLMs aren’t tools” 글](https://yagmin.com/blog/llms-arent-tools/)에서 LLM 활용의 **정신적 프레임워크**를 탐구했음 “소프트웨어 공장”은 현재의 종착점이지만, 그 다음 단계는 **LLM을 하나의 애플리케이션**으로 보는 것임 즉, 단순한 워크플로우 자동화가 아니라 **맞춤형 하네스**를 만드는 단계임