에이전트를 활용하여 개발하는 모든 사람들은 같은 숫자를 쫓고 있습니다. 바로 아이디어를 병합된 풀 리퀘스트(pull request)로 얼마나 빠르게 가져갈 수 있느냐 하는 것입니다. 이 숫자는 이제 쉬운 문제입니다. 에이전트는 단 11분 만에 완전하고, 테스트되었으며, 그럴듯한 기능을 만들어낼 수 있습니다.
진짜 어려운 숫자는 다른 하나입니다. '언제쯤 이것이 올바른지 알게 될까?'
소프트웨어 공장이 실제로 해결해야 하는 것이 바로 그것입니다. 출력을 내는 것(이는 저렴합니다)이 아니라, 그 출력물을 신뢰하는 것입니다(이는 그렇지 않습니다). 그리고 신뢰는 더 나은 프롬프트에서 나오는 것이 아닙니다. 이는 무엇이 바뀌었는지, 그리고 여전히 작동하는지 빠르고 해석 없이 알려주는 도구에서 나옵니다.
따라서 이것은 도구 목록이 아닙니다. 공장에 들어가는 어떤 도구를 보더라도 제가 찾는 기준입니다.
1. 무엇이 변경되었는지 알려준다
무슨 일이 일어났는지 볼 수 없는 공장은, 무언가 고장 나는 순간 신뢰를 거두게 될 것입니다.
이는 **제품의 관측 가능성(observability)**에서 시작합니다: 트레이스(traces), 메트릭(metrics), 그리고 로그를 첫날부터 확보해야 하며, 이상적으로는 OpenTelemetry와 같은 개방 표준을 사용해야 데이터가 특정 벤더에 갇히지 않습니다. 에이전트가 변경 사항을 배포할 때, 사용자보다 먼저 프로덕션 환경에서 무엇을 했는지 알 수 있어야 합니다. 제가 이것을 가장 먼저 언급하는 이유는 대부분의 팀들이 이 부분을 미루기 때문이며, 이를 미룬다는 것은 모든 에이전트 변경 사항이 '눈 가리고' 진행된다는 의미입니다.
이는 공장 자체의 관측 가능성으로 이어집니다. 에이전트가 취한 모든 단계는 인간이 사람이 할 수 있는 속도로 읽을 수 있는 무언가를 남겨야 합니다: 티켓 댓글, 실행 보고서, 사양서(spec), 테스트가 실행되는 비디오 등입니다. 만약 변경 사항의 유일한 증거가 디프(diff)라면, 당신은 에이전트가 무엇을 만들었는지에 대한 의견을 검토하는 것이지, 실제로 무엇을 만들었는지를 검토하는 것이 아닙니다.
2. 결정론적이고 빠르다
에이전트는 아키텍처의 모든 규칙을 나열한 긴 마크다운 파일이 필요하지 않습니다. 실패하는 체크(checks)가 필요합니다.
산문으로 작성된 규칙은 제안일 뿐입니다. 린터(linter)에 의해 강제되는 규칙은 사실입니다. 저는 이전에 Prose does not beat determinism에서 이 점을 다룬 적이 있으며, 이는 전체 공장에도 적용됩니다:
- 첫 커밋부터 CI(Continuous Integration) 적용. 프로젝트가 '진지해질 때'가 아니라 첫 에이전트 풀 리퀘스트(pull request)를 할 때부터 필요합니다.
CONVENTIONS.md에 적었을 법한 규칙들을 위한 린터와 타입 체크(Linter and type checks).- 후크(hook)로 강제되는 커밋 컨벤션(Commit conventions): 이를 통해 에이전트가 작성한 커밋도 인간이 작성한 것과 동일하게 읽히고, 변경 로그(changelogs)가 자동으로 작성됩니다.
- 항상 실행되는 정적 분석(Static analysis that always runs): gitleaks와 같은 비밀 스캐닝(secret scanning), SonarCloud 같은 코드 분석 도구 등, 사용 중인 스택에 맞는 모든 것들. 이들은 지루하며, 바로 그 점이 중요합니다. 에이전트가 무언가를 기억하는지에 의존하지 않습니다.
마크다운(Markdown)은 여전히 역할이 있습니다. 그것은 **의도(intent)**를 기록합니다: 무엇이 합의되었고 왜 그랬는지. 체크(Checks)는 **규칙(rules)**을 기록합니다. 이 둘을 혼합하는 것이 바로 에이전트가 읽지만 절반만 따르고 아무도 검증할 수 없는 900줄짜리 지침 파일로 이어지는 방식입니다.
3. 변경하기에 충분히 간단해야 한다
아키텍처가 인간이 읽기에 쉬울수록, 에이전트가 작업하기도 쉽습니다. 그리고 작업하기 쉬울수록, 버리기(throw away)도 쉬워집니다.
마지막 부분이 매달 더 중요해지고 있습니다. 오늘 사용하고 있는 도구와 모델은 1년 뒤에 사용할 것이 아닐 것입니다. 부품 하나를 떨어뜨리고 교체할 수 없는 공장은 첫 번째 결정 주위에 서서히 석회화될 것입니다.
이것을 변경 가능하게 유지하는 두 가지 요소가 있습니다:
• 추측에 기반한 아키텍처를 피하라. 알고 있는 요구사항을 위해 구축해야 한다. "확장 가능하게 만들어 달라"는 요청을 받은 에이전트는 당신이 한 번도 겪어보지 않은 문제에 대한 프레임워크를 기꺼이 생성할 것이다.
• 가격 책정이 불가능한 종속성(lock-in)을 피하라. 호스팅 환경은 괜찮다. 중요한 것은 이탈하는 데 드는 비용이다. 만약 당신의 프레임워크가 배포 위치를 결정하거나, 테스트 러너(test runner)가 단일 플랫폼 내에서만 작동한다면, 당신은 원래 당신의 것이어야 할 결정을 그 의존성으로 비즈니스 모델을 삼는 누군가에게 넘겨준 것이다.
4. 스스로 품질을 증명하는 것
이것이 제가 가장 강력하게 적용하는 필터이며, 인기 있는 도구들을 가장 자주 배제하는 기준입니다.
만약 어떤 도구가 스스로 어떻게 검증하는지 보여주지 못한다면, 저는 그것을 사용하지 않습니다. 이는 AI 컴포넌트 자체에도 마찬가지로 적용됩니다: 스킬(skill), 플러그인(plugin), MCP 서버, 에이전트 프롬프트 등이 모두 해당합니다. 하나를 채택하기 전에 세 가지를 살펴봅니다:
- CI (지속적 통합): 변경 사항마다 무언가를 실행하는가, 아니면 새로운 버전만 나타나는가?
- 배포 방식: 버전이 지정되어 있고(Versioned), 변경 로그(changelog)가 있는지, 아니면 복사해서 사용하기만을 바라는 파일인가?
- 평가(evals): 해당 스킬이 한 번 이상의 실행을 거쳐 유용한 무언가를 수행했다는 증거가 있는가, 아니면 그저 "내가 시도해 봤는데 작동했어"라는 증거에 불과한가?
세 번째 항목은 아직 거의 아무도 갖추지 못한 것입니다. 저는 이 중요성에 대해 "I tried it and it worked" is not a test에서 글을 썼습니다.
인기에 대한 참고 사항: 이것은 제가 가장 많이 듣는 반론이기 때문입니다. 더 이상 인기는 사용 용이성의 대리 지표가 아닙니다. 왜냐하면 에이전트들이 문서를 읽어주기 때문입니다. 명확한 문서가 갖춰진 작고 잘 테스트된 도구는 시장 선두 주자만큼 에이전트에게 쉽게 채택될 수 있습니다. 인기는 여전히 유지보수 측면에서 중요합니다. 3년 후에도 그 존재를 유지하고 싶기 때문입니다. 이는 결정적인 표가 아니라, 동점일 때의 우위(tiebreaker)일 뿐입니다.
5. 사람이 검토할 수 있는 속도의 테스트
테스트는 신뢰를 얻거나 위조하는 곳이며, 에이전트들은 이를 매우 쉽게 만듭니다. 동일한 에이전트가 코드와 테스트를 모두 작성했을 때, 녹색 체크 표시(green tick)는 같은 모델의 의견이 두 번 표현된 것일 뿐입니다.
프론트엔드 테스트에서 제가 특별히 중요하게 생각하는 부분은 다음과 같습니다:
- 모든 시나리오가 목킹(mocked)되고 결정론적(deterministic)이어야 합니다. 그래야 에이전트 루프의 모든 반복에서 간헐적인 오류(flaking) 없이 스위트가 실행될 수 있습니다.
- 백엔드에 대한 계약 테스트(Contract testing)를 수행해야 합니다. 이를 통해 테스트가 의존하는 목킹 데이터가 실제 API와 동떨어지는 현상(drift away)을 방지할 수 있습니다.
- 사람이 볼 수 있어야 합니다. 각 테스트 실행의 짧은 비디오를 풀 리퀘스트에 첨부하면, 검토자가 30초 만에 수정 사항이 5분을 걸려 제안하는 내용을 파악할 수 있습니다.
제가 직접 작업하면서 구축한 것이 TWD이기 때문에 편향적일 수 있지만, 중요한 것은 도구가 아니라 기준입니다. 어떤 프레임워크를 사용하든, 이 세 가지 조건을 충족하는지 질문해야 합니다.
6. 체인에는 지름길이 없다 (The chain has no shortcuts)
위의 어떤 것도 이를 우회하는 팀에서는 살아남기 어렵습니다.
공장은 하나의 사슬(chain)입니다. 요청은 티켓이 되고, 티켓은 명세서가 되며, 명세서는 계획이 되고, 계획은 변경 사항이 되고, 그 변경 사항은 티켓을 통해 검증된 후 전달됩니다. 이 고리 중 하나라도 끊어지면(채팅에서 합의된 요구사항, 이슈 없이 푸시된 수정 사항, '그냥 해버리는' 영웅 개발자 등) 공장이 존재할 이유 전체를 잃게 됩니다. 바로 신뢰할 수 있는 기록입니다.
저는 이 과정을 법의학 용어인 **관리 사슬(chain of custody)**이라고 부르며, 이는 별도의 글로 다룰 가치가 있습니다.
또한 이것은 공장이 단순한 엔지니어링 프로젝트가 아니라는 것을 의미합니다. 제품(Product), 디자인, 그리고 이해관계자들은 모두 같은 체인 내에서 작업해야 하며, 그렇지 않으면 그 체인은 존재하지 않습니다. 이것이 가장 어려운 부분이며, 별도의 글로 다루었습니다.
단 하나의 질문
모든 것을 걷어내고 이 모든 도구에 동일한 질문을 던져야 합니다:
빠르고 결정론적으로 무엇이 변경되었는지, 그리고 여전히 작동하는지 알려줄 수 있는가?
만약 그렇다면, 인기가 있든 없든 공장에 포함되어야 합니다. 그렇지 않다면, 인기가 있든 없든 포함되어서는 안 됩니다. 그리고 이 답이 변한다면, 그것은 버려야 합니다. 재구축하는 것이 두려운 공장은 공장이 아니라 우연히 자동화된 레거시일 뿐입니다.