소프트웨어 팩토리와 에이전틱 순간
Source: Hacker News
Source: …
소프트웨어 팩토리
우리는 소프트웨어 팩토리를 구축했습니다 – 사양과 시나리오가 자율 에이전트를 구동하여 다음을 수행하는 비대화형 개발 파이프라인입니다:
- 코드 작성
- 테스트 하니스 실행
- 해결책에 수렴
이 모든 과정은 인간이 작성한 코드나 인간의 검토 없이 이루어집니다.
서술 개요
아래는 접근 방식에 대한 간결한 서술입니다. 기본 원리부터 시작하고 싶다면, 다음 제약 조건과 지침을 반복적으로 적용하여 어떤 팀이든 동일한 직관, 신념1 및 궁극적으로 자립적인 팩토리2에 도달하도록 안내할 수 있습니다.
공안 / 만트라
왜 이 일을 하고 있나요?
(암시된 답변: 모델이 대신 해야 합니다.)
규칙
- 코드는 인간에 의해 작성되어서는 안 됩니다.
- 코드는 인간에 의해 검토되어서는 안 됩니다.
실용적 지표
- 오늘 인간 엔지니어당 최소 $1,000 이상의 토큰을 사용하지 않았다면, 여러분의 소프트웨어 팩토리에는 아직 개선 여지가 있습니다.
각주
The StrongDM AI Story
2025년 7월 14일, 제이 테일러와 나반 차우한이 저—저스틴 맥카시, 공동 창업자 겸 CTO—와 함께 StrongDM AI 팀을 설립했습니다.
촉매제
2024년 말, 우리는 중요한 변화를 목격했습니다: Claude 3.5의 두 번째 개정판(2024년 10월)으로 인해 장기‑지향, 에이전트 기반 코딩 워크플로가 오류를 누적하기보다 정확성을 누적하기 시작했습니다.
2024년 12월까지, 모델의 장기‑지향 코딩 성능은 Cursor의 **YOLO mode**에서 입증된 바와 같이 명확히 드러났습니다.
왜 중요한가
이 개선 이전에는 LLM을 코딩 작업에 반복 적용하면서 다양한 오류가 누적되었습니다:
- 의도 오해
- 환상적인 API 또는 데이터 생성
- 구문 오류
- 버전 간 DRY 위반
- 라이브러리 호환성 문제
이러한 오류들은 애플리케이션을 퇴보시키고 결국 붕괴시키는, 일명 “천 번의 절단에 의한 사망” 현상을 초래했습니다.
새로운 패러다임
YOLO 모드와 결합된 Anthropic의 최신 모델은 우리가 현재 비대화형 개발 또는 성장형 소프트웨어라고 부르는 개념을 처음으로 보여주었습니다—인간이 지속적으로 수정하지 않아도 올바르게 진화하는 소프트웨어.
손잡이를 찾아 열까지 돌리기
“이것들은 11까지 간다”
AI 팀의 첫 날 첫 시간에 우리는 “잠금 해제” 라고 부르는 일련의 발견으로 이어지는 로드맵을 제시하는 헌장을 만들었습니다. 되돌아보면, 헌장 문서에서 가장 중요한 문장은 다음과 같습니다:
손대지 마!
처음엔 단순한 직감—실험이었습니다. 손으로 코드를 전혀 작성하지 않고 얼마나 멀리 갈 수 있을까?
그다지 멀리 가지 못했습니다! 적어도 테스트를 추가하기 전까지는 그렇습니다. 하지만 에이전트는 즉각적인 작업에 집착하면서 곧 지름길을 택하기 시작했습니다:
return true은 좁게 작성된 테스트를 통과시키는 좋은 방법이지만, 여러분이 원하는 소프트웨어에는 일반화되지 않을 가능성이 높습니다.
테스트만으로는 충분하지 않았습니다. 다음은 어떨까요:
- 통합 테스트?
- 회귀 테스트?
- 엔드‑투‑엔드 테스트?
- 행동 테스트?
테스트에서 시나리오와 만족도로
agentic moment의 반복되는 주제 중 하나는 새로운 언어의 필요성이다.
예를 들어, test라는 단어는 충분하지 않고 모호함이 드러났다:
- 코드베이스에 저장된 테스트는 코드를 맞추기 위해 게으르게 다시 작성될 수 있다.
- 코드는 테스트를 쉽게 통과하도록 다시 작성될 수 있다.
우리는 scenario라는 단어를 엔드‑투‑엔드 사용자 스토리를 나타내는 용도로 재사용했으며, 이는 종종 코드베이스 외부에 저장된다(모델 훈련에서 holdout 세트와 유사). 시나리오는 직관적으로 이해될 수 있고 LLM에 의해 유연하게 검증될 수 있다.
소프트웨어 대부분이 자체적으로 에이전시 요소를 가지고 있기 때문에, 우리는 성공에 대한 불리언 정의(“the test suite is green”)에서 확률적이고 경험적인 정의로 전환했다. 우리는 이 검증을 정량화하기 위해 satisfaction이라는 용어를 사용한다:
모든 시나리오를 통한 관찰된 모든 궤적 중, 어느 정도 비율이 사용자를 만족시킬 가능성이 있는가?
디지털 트윈 유니버스에서 시나리오 검증
이전 개발 사이클에서는 통합 테스트, 회귀 테스트, UI‑자동화를 사용하여 간단한 질문 **“작동하나요?”**에 답했습니다.
왜 기존 접근 방식이 부족했는가
| 문제 | 왜 중요한가 |
|---|---|
| 테스트가 너무 경직됨 | 우리 코드가 이제 에이전트와 LLM‑기반 루프를 핵심 설계 원시로 사용합니다. 성공을 판단하려면 정적 어설션보다 LLM을 판사로 활용해야 하는 경우가 많았습니다. |
| 테스트가 보상 해킹에 취약 | 모델이 테스트 하네스를 “게임”하는 방법을 학습하여 문제를 실제로 해결하지 못하고 겉보기에만 올바른 출력을 생성할 수 있습니다. 우리는 이러한 부정 행위에 강인한 검증이 필요했습니다. |
디지털 트윈 유니버스(DTU) 소개
DTU는 우리 소프트웨어가 의존하는 서드파티 서비스들의 행동 클론을 제공합니다. 우리는 다음 서비스에 대한 트윈을 구축했습니다:
- Okta
- Jira
- Slack
- Google Docs
- Google Drive
- Google Sheets
각 트윈은 서비스의 API 인터페이스, 예외 상황 처리, 그리고 관찰 가능한 동작을 복제합니다.
DTU의 장점
- 대규모 – 프로덕션 한계를 훨씬 초과하는 볼륨과 요청 속도로 테스트를 실행합니다.
- 안전한 장애 주입 – 실제 서비스에 영향을 주지 않고 위험하거나 불가능한 장애 상황을 시뮬레이션합니다.
- 비용 없는 실행 – 속도 제한, 남용 탐지 차단, API 사용료 등을 피합니다.
- 빠른 반복 – 시간당 수천 개의 시나리오를 실행하여 포괄적인 시나리오 커버리지를 가능하게 합니다.
Digital Twin Universe: Okta, Jira, Google Docs, Slack, Drive, Sheets의 행동 클론 (클릭하여 확대)
DTU를 통해 이제 복잡한 LLM‑기반 워크플로를 신뢰성 있게 검증할 수 있게 되었으며, 극단적이거나 병리적인 상황에서도 소프트웨어가 올바르게 동작함을 보장합니다.
Source: …
비전통적 경제학
우리의 DTU 성공 사례는 Agentic Moment가 소프트웨어 경제에 얼마나 깊은 변화를 가져왔는지를 보여줍니다.
- 중요한 SaaS 애플리케이션을 고충실도 복제하는 것은 기술적으로 언제나 가능했지만, 경제적으로는 결코 실현 가능하지 않았습니다.
- 여러 세대에 걸친 엔지니어들은 CRM의 전체 메모리 복제본을 테스트용으로 원했을지라도, 스스로 제안을 검열했습니다. 그들은 답이 “아니오”가 될 것을 알고 있었기 때문에 관리자에게도 제안조차 하지 않았습니다.
소프트웨어 팩토리 마인드셋
소프트웨어 팩토리를 구축하는 우리들은 고의적인 순진함을 실천해야 합니다:
- Software 1.0의 습관, 관행, 제약을 식별합니다.
- 이를 체계적으로 제거하거나 대체합니다.
DTU는 6개월 전만 해도 상상할 수 없었던 것이 이제는 일상이 되었다는 우리의 증거입니다.
Software 1.0 – Introductory Video
Read Next
- Principles – 에이전트를 사용한 소프트웨어 구축에 대해 우리가 진실이라고 믿는 것.
- Techniques – 이러한 원칙을 적용하기 위한 반복 패턴.
- Products – 우리가 매일 사용하고 다른 사람들도 혜택을 받을 것이라 믿는 도구들.
읽어 주셔서 감사합니다. 여러분이 자체 소프트웨어 팩토리를 구축하는 데 행운이 함께하길 바랍니다.