Making Codebases Agent Ready – Eno Reyes, Factory AI
소프트웨어 2.0 시대의 핵심 - 검증 가능성(Verifiability)
Factory AI는 2년 반 전 설립 당시부터 “소프트웨어 엔지니어링의 자율성(Autonomy) 구현”을 미션으로 삼았다. 이는 단순한 버즈워드가 아니라, AI 에이전트가 실제로 소프트웨어 개발에서 작동할 수 있는 환경을 만드는 구체적인 과제다.
Andrej Karpathy는 최근 트윗에서 Software 2.0의 핵심을 “검증 가능성”에서 찾았다. 현재 최전선 모델들은 검증 가능한 작업(Verifiable Tasks)을 대량으로 활용하는 포스트 트레이닝(Post-training)을 통해 구축되고 있다. 이는 AI 시스템이 해결할 수 있는 문제의 경계가 결국 두 가지 요소의 함수라는 것을 의미한다: (1) 명확한 목표(Objective)를 명시할 수 있는가, (2) 가능한 솔루션 공간(Solution Space)을 탐색할 수 있는가.
전통적인 소프트웨어 개발은 순수한 명세(Specification)를 통해 이루어졌다. 알고리즘의 입력은 X이고 출력은 Y라는 식으로 정확히 정의하는 방식이다. 하지만 AI 자동화의 관점에서 사고방식을 전환하면, 명세가 아닌 검증(Verification)을 통한 자동화라는 새로운 가능성이 열린다.
검증의 비대칭성(Asymmetry of Verification)
Jason의 블로그 포스트에서 언급된 “검증의 비대칭성”은 컴퓨터 과학의 고전적 개념인 P vs NP 문제와 연결된다. 많은 작업들이 해결하기는 어렵지만 검증하기는 훨씬 쉽다는 특성을 가진다.
특히 흥미로운 “검증하기 쉬운 문제(Easy-to-verify Problems)“들은 다음과 같은 특징을 공유한다:
- 객관적 진실(Objective Truth): 명확한 정답이 존재한다
- 빠른 검증(Quick Validation): 검증 프로세스가 신속하게 완료된다
- 확장 가능성(Scalability): 여러 검증을 병렬로 처리할 수 있다
- 낮은 노이즈(Low Noise): 검증 성공률이 매우 높다
- 연속적 신호(Continuous Signal): 단순한 이진(Binary) 결과가 아니라 30%, 70%, 100% 정확도처럼 연속적인 피드백을 제공한다
소프트웨어 개발은 고도로 검증 가능한(Highly Verifiable) 영역이다. 이것이 바로 현재 소프트웨어 개발 에이전트가 세계에서 가장 발전된 AI 에이전트인 이유다. 지난 20~30년간 축적된 자동화된 검증 인프라 - 단위 테스트(Unit Tests), 통합 테스트(End-to-end Tests), QA 테스트 - 가 존재하기 때문이다.
이 검증의 경계는 계속 확장되고 있다. Browserbase 같은 회사들과 컴퓨터 사용 에이전트(Computer Use Agents)들은 복잡한 시각적 변화나 프론트엔드 변경사항을 검증하는 것을 더욱 쉽게 만들고 있다. OpenAPI 스펙을 통한 문서화(Documentation) 자동화 역시 검증 가능한 영역이다.
코드베이스 검증 체크리스트 - 8가지 기둥
전문 소프트웨어 엔지니어에게는 당연해 보이는 질문들이지만, AI 에이전트 시대에는 훨씬 더 깊이 파고들어야 한다:
- 린터(Linters): 코드 포맷을 자동으로 검증하는가?
- 테스트 커버리지(Test Coverage): 얼마나 많은 코드가 테스트되는가?
- 빌드 안정성(Build Stability): 빌드가 매번 성공하는가?
- 문서화(Documentation): OpenAPI 스펙 같은 자동화된 문서가 있는가?
- 타입 검사(Type Checking): 정적 타입 검증이 이루어지는가?
- 통합 테스트(Integration Tests): 컴포넌트 간 상호작용이 검증되는가?
- 코드 리뷰 자동화(Automated Code Review): 코드 품질 기준이 자동으로 체크되는가?
- 배포 검증(Deployment Validation): 프로덕션 배포 전 검증이 자동화되어 있는가?
하지만 여기서 한 걸음 더 나아가야 한다. 단순히 린터가 있다는 것만으로는 충분하지 않다. 린터가 얼마나 독선적(Opinionated)인가? 코딩 에이전트가 생성한 코드가 항상 시니어 엔지니어 수준의 품질을 자동으로 달성할 만큼 엄격한가?
AI 슬롭(AI Slop)이 삽입되면 실패하고, 고품질 AI 코드가 삽입되면 통과하는 테스트가 있는가? 대부분의 코드베이스는 이러한 추가적인 검증 레이어가 부족하다. 왜냐하면 인간 개발자들은 자동화된 검증 없이도 이런 부분을 잘 처리하기 때문이다.
많은 기업의 테스트 커버리지는 50~60% 수준이다. 인간이 수동으로 테스트하기 때문에 이 정도면 충분하다. 빌드가 3번 중 1번꼴로 실패해도, 모두가 은밀히 싫어하지만 아무도 큰소리로 말하지 않는다. 이것이 대규모 코드베이스의 현실이다.
심지어 44,000명 이상의 엔지니어를 보유한 초대형 조직에서도 50~60% 수준의 기준이 받아들여지는 것이 일반적이다. 대부분의 소프트웨어 조직은 실제로 이 정도 수준에서도 확장이 가능하다. 인간 개발자에게는 이것이 문제없다.
하지만 AI 에이전트를 소프트웨어 개발 라이프사이클에 도입하기 시작하면 - 단순히 대화형 코딩만이 아니라 리뷰, 문서화, 테스팅 전반에 걸쳐 - 이러한 낮은 기준이 에이전트의 능력을 망가뜨린다.
대부분의 사람들은 충분한 검증이 갖춰진 코드베이스에서 작동하는 AI 에이전트만 경험했을 것이다. 현재 세계 최고 수준의 기업들은 실제로 매우 엄격한 검증 기준을 도입했으며, 이는 그들이 에이전트를 활용하는 능력이 평균적인 개발자보다 훨씬 뛰어나다는 것을 의미한다.
개발 패러다임의 전환 - 명세 주도 개발(Specification-driven Development)
전통적인 개발 루프는 다음과 같다:
- 문제 이해(Understanding)
- 솔루션 설계(Designing)
- 코딩(Coding)
- 테스팅(Testing)
하지만 엄격한 검증 시스템이 갖춰진 환경에서 에이전트를 사용하면 이 프로세스가 변화한다:
- 제약 조건 명시(Specifying Constraints): 어떻게 검증받고 싶은지, 무엇이 만들어져야 하는지 명시
- 솔루션 생성(Generating Solutions): 목표에 맞는 솔루션을 생성
- 검증(Validation): 자동화된 검증 + 인간의 직관으로 검증
- 반복(Iteration): 루프를 계속 반복
이러한 전통적 개발에서 **명세 주도 개발(Specification-driven Development)**로의 전환이 모든 도구들에 스며들고 있다. 다양한 도구들이 “스펙 모드(Spec Mode)”, “플랜 모드(Plan Mode)“를 도입하고 있으며, 아예 이런 명세 주도 흐름을 중심으로 설계된 IDE도 등장하고 있다.
이 두 가지 - (1) 고도의 검증 시스템, (2) 명세 주도 개발 - 를 결합하면 신뢰할 수 있고 고품질의 솔루션을 구축할 수 있다.
조직이 내려야 할 전략적 선택
조직이 내릴 수 있는 최선의 결정은 무엇인가?
선택지 A: 45일간 시장의 모든 코딩 도구를 비교하고, SWE-bench 정확도가 10% 더 높다는 이유로 특정 도구를 선택하는 것
선택지 B: 조직의 관행을 변경하여 모든 코딩 에이전트가 성공할 수 있게 만들고, 개발자들이 선호하는 도구를 선택하게 하거나 솔직히 여러 훌륭한 도구 중에서 자유롭게 고르게 하는 것
검증 기준이 확립되면 훨씬 더 복잡한 AI 워크플로우를 조직에 도입할 수 있다. PR이 합리적으로 성공적인지, 프로덕션을 확실히 깨뜨리지 않을 코드인지 자동으로 검증할 수 없다면, 여러 에이전트를 병렬로 실행하는 것은 불가능하다. 대규모 현대화 프로젝트를 여러 하위 작업으로 분해하는 것 같은 최전선 수준의 작업을 AI로 수행하는 것도 불가능하다.
단일 작업 실행 - 즉, “이걸 완료해 주세요, 정확히 이렇게 해 주세요, 이렇게 검증하세요”라는 단순한 작업 - 이 거의 100%에 가깝게 작동하지 않는다면, 조직 규모에서 이러한 더 복잡한 것들을 성공적으로 사용하는 것은 잊어버려도 된다.
코드 리뷰 같은 다른 도구들도 마찬가지다. 정말 고품질의 AI 생성 코드 리뷰를 원한다면, AI 시스템을 위한 문서화가 필요하다.
물론 에이전트들은 점점 더 똑똑해질 것이다. 린터나 테스트를 실행해야 할 때를 더 잘 판단하게 될 것이다. 명시적인 포인터가 없을 때도 솔루션을 더 잘 찾게 될 것이다. 검색 능력도 향상될 것이다.
하지만 에이전트들은 검증 기준을 허공에서 무작위로 생성하는 능력은 절대 갖지 못할 것이다. 이것이 바로 소프트웨어 개발자가 소프트웨어 구축 프로세스에 계속 깊이 관여할 것이라고 믿는 이유다. 개발자의 역할은 소프트웨어가 자라나는 환경과 정원을 큐레이팅하는 것으로 전환된다. 제약 조건을 설정하고, 자동화를 구축하고, 이러한 자동화에 지속적으로 독선성(Opinionatedness)을 주입하는 것이다.
만약 회사가 위에서 언급한 8가지 검증 기둥을 최소한이라도 모두 갖추지 못했다면, 조달 사이클이나 특정 도구를 사는 것과는 완전히 별개로 할 수 있는 일이 많다는 뜻이다.
Factory AI의 솔루션 - 체계적 개선 프레임워크
Factory AI는 조직들이 이런 작업을 하도록 돕는다. 명확한 방법론이 존재한다:
1단계: 분석(Analysis)
8가지 자동화 검증 기둥에서 현재 어느 위치에 있는지 분석한다. 린터가 있는가? 린터가 얼마나 좋은가? agents.md 파일(거의 모든 코딩 에이전트가 지원하는 오픈 스탠다드)이 있는가?
2단계: 체계적 개선(Systematic Enhancement)
다양한 검증 기준을 체계적으로 개선한다.
3단계: 차별화된 분석(Differentiated Analysis)
어떤 도구를 누가 사용하는지 알려주는 툴링이 있다면, 다음과 같은 질문을 할 수 있다: “코딩 에이전트가 시니어 개발자에게는 충분히 신뢰할 수 있지만, 주니어 개발자들은 실제로 완전히 사용할 수 없는 것 아닌가?”
그리고 그 이유가 주니어 개발자들이 더 무능하거나 도구 사용법을 모르기 때문이 아니라, **자동화된 검증이 없는 틈새 관행(Niche Practices)**들이 존재하기 때문임을 발견하게 된다.
Google이나 Meta와 여전히 규모가 큰 2,000명의 엔지니어링 조직의 차이는 무엇인가? 차이는 사실상 제로 컨텍스트를 가진 신입 개발자가 가서 YouTube의 경계선을 약간 더 둥글게 만드는 변경사항을 배포할 수 있고, 그것이 어느 정도 확신을 가지고 10억 사용자를 위한 YouTube를 다운시키지 않을 것이라는 점이다. 이것이 가능한 이유는 그 코드가 배포되기 위해 거쳐야 하는 엄청난 양의 검증 때문이다.
자기 강화 피드백 루프(Self-reinforcing Feedback Loop)
현재 우리가 가진 큰 차이점은 코딩 에이전트가 정확히 어디에 이러한 갭이 있는지 식별하고, 실제로 그 수정사항을 치료할 수 있다는 것이다.
코딩 에이전트에게 “린터가 충분히 독선적이지 않은 곳을 찾아줄 수 있나?”라고 물어볼 수 있다. 코딩 에이전트에게 테스트를 생성하도록 요청할 수 있다.
Factory AI의 엔지니어 Alvin은 이런 말을 했다: “슬롭 테스트(Slop Test)가 테스트가 없는 것보다 낫다.” 이것은 약간 논란의 여지가 있지만, 여기서 주장하고 싶은 것은 단순히 무언가가 거기에 있다는 것만으로도 - 변경사항이 올바를 때 통과하고 원하는 스펙과 어느 정도 정확하게 일치하는 것만으로도 - 사람들이 그것을 개선하고 업그레이드할 것이며, 다른 에이전트들도 실제로 이러한 테스트를 인지한다는 것이다. 패턴을 따라갈 것이다.
더 독선적으로 만들수록, 사이클이 더 빠르게 계속된다.
조직이 생각해야 할 것은: 우리 조직에서 어떤 피드백 루프를 위해 최적화하고 있는가?
더 나은 에이전트가 있다면: → 환경을 더 좋게 만든다 → 그러면 에이전트가 더 좋아진다 → 그러면 환경을 더 좋게 만들 시간이 더 생긴다
이것이 조직이 투자할 수 있는 새로운 개발자 경험(DevEx) 루프이며, 이는 조달하는 모든 도구에 혜택을 줄 것이다. 코드 리뷰 도구든, 코딩 에이전트든, 기타 무엇이든 모두 혜택을 받는다.
이는 리더로서 소프트웨어 작업에 투자할 때의 멘탈 모델을 전환시킨다.
현재 엔지니어링 프로젝트에 대한 운영비용(OpEx)은 “더 많은 사람이 필요하다”는 식의 투입이다. 이 문제를 해결하려면 10명이 더 필요하다는 식이다.
하지만 이제 투자할 수 있는 또 다른 것은 이러한 추가 인력이 훨씬 더 성공적이 되도록 하는 환경 피드백 루프다. 이 피드백 루프는 엄청난 가치를 가질 수 있다. 왜냐하면 코딩 에이전트가 이것을 확장할 수 있기 때문이다.
제품 외부에서 할 수 있는 일
이 모든 것이 말하는 것은: 제품 자체 외부에서 이러한 시스템을 가능하게 하기 위해 할 수 있는 일이 많다.
최고의 코딩 에이전트는 실제로 이러한 검증 루프를 활용할 것이다. 만약 코딩 에이전트가 린터, 테스트 등을 proactively 찾지 않는다면, 결국 그것은 검증 기준을 찾는 에이전트만큼 좋지 않을 것이다.
게다가 조직이 이런 것들을 생각할 때, “여기 내 의견이 있고, 소프트웨어가 이렇게 만들어졌으면 좋겠다”고 말할 수 있는 사람이라면, 그것은 전례 없이 능력을 확장시킨다. 독선적인(Opinionated) 엔지니어 한 명이 실제로 전체 비즈니스의 속도를 의미 있게 변화시킬 수 있다 - 이것을 진지하게 받아들이고 측정하고 체계적으로 개선할 방법이 있다면.
미래 비전 - 완전 자동화된 개발 사이클
AI가 어디로 가고 있는지, 오늘날 우리가 어디에 있는지 생각해 보면, 소프트웨어 개발 에이전트를 사용하는 여정에서 여전히 정말 초기 단계다.
다음과 같은 세상을 원한다고 상상해 보자:
- 고객 이슈가 들어온다
- 버그가 제출된다
- 티켓이 집어진다
- 코딩 에이전트가 그것을 실행한다
- 피드백이 개발자에게 제시된다
- 개발자가 승인을 클릭한다
- 코드가 병합되고 프로덕션에 배포된다
- 이 피드백 루프가 1~2시간 안에 완료된다
이것은 가능할 것이다. 우리 모두는 이런 완전 자율적인 흐름에 대해 회의적이지만, 이것은 오늘날 기술적으로 실현 가능하다(Technically Feasible).
제한 요소는 코딩 에이전트의 능력이 아니다. 제한 요소는 조직의 검증 기준이다.
결론 - 5~7배 생산성의 원천
이것은 오늘 투자하면 조직을 1.5배, 2배가 아니라 진짜 5배, 6배, 7배로 만들 수 있는 투자다.
이것은 말하기 쉬운 일이지만, 불행한 이야기이기도 하다. 왜냐하면 이것은 투자해야 한다는 의미이기 때문이다. AI가 마법처럼 그냥 줄 것이 아니다. 이것은 조직으로서 내려야 하는 선택이다.
지금 이 선택을 한다면, 엣지 속도(Edge Velocity) 측면에서 상위 1~5% 조직에 속하게 될 것이며, 이 분야의 다른 모든 사람을 능가할 것이다.
이런 종류의 것에 투자하기를 강력히 권한다.