에이전트가 코드를 짜고 PR까지 올리는 시대가 이미 시작됐다. 문제는 '에이전트가 할 수 있느냐'가 아니라 '팀이 어떤 구조 위에서 에이전트를 돌리느냐'다. 최근 dev.to에 연달아 올라온 세 편의 글—Voice-to-PR 파이프라인 설계(DevMentor), Spec-Driven Development, 그리고 Anthropic Eugene Yan의 AI 보안 검증 프레임워크—은 각각 독립된 주제처럼 보이지만, 하나의 에이전트 루프를 구성하는 연속된 레이어를 다루고 있다. 기획 스펙 → 코드 생성 → 보안 검증. 이 순서를 설계하지 않은 팀은 에이전트를 '동료'가 아니라 '통제 불가능한 실행자'로 경험하게 된다.
레이어 1: 에이전트에게 던지기 전에 스펙을 먼저 결정하라
가장 먼저 직면하는 문제는 생각보다 단순하다. 에이전트는 명세되지 않은 결정을 스스로 채운다. Spec-Driven Development를 다룬 글의 저자는 검색 바 하나를 에이전트에게 맡겼다가 디바운스 없이 키 입력마다 API를 때리는 구현을 받아들었다. 틀린 코드가 아니다. 그냥 내가 원하는 제품이 아닌 코드였을 뿐이다.
핵심 통찰은 이렇다. AI 에이전트는 명세된 것을 구현하는 게 아니라, 명세되지 않은 것을 학습 데이터의 최빈값으로 채운다. AND 필터인지 OR 필터인지, URL이 업데이트되는지, 빈 쿼리에서 전체를 보여주는지 아무것도 보여주지 않는지—이 결정들은 제품의 결정이지 에이전트가 알아서 해도 되는 것이 아니다. 해법은 거창하지 않다. 에디터를 열기 전에 마크다운 파일 하나에 모든 상태와 인터랙션의 예상 동작을 표로 정리하는 것이다. BDD의 철학을 인프라 없이 실행하는 방식이다.
팀 차원에서 이게 중요한 이유는 단순히 에이전트 출력 품질 때문이 아니다. 스펙을 먼저 쓰는 행위 자체가 팀이 제품 결정을 코드 생성 이전 단계로 끌어올리는 프로세스를 강제한다. 스펙 없이 에이전트를 돌리면 리뷰어는 항상 이미 묻혀버린 결정을 사후에 파헤치는 작업을 하게 된다. 그건 리뷰가 아니라 역공학이다.
레이어 2: 스펙이 있으면 에이전트 루프를 완전히 위임할 수 있다
스펙이 확정된 다음 단계가 Voice-to-PR 파이프라인이다. DevMentor 아키텍처가 흥미로운 이유는 단순히 음성으로 코드를 생성하기 때문이 아니다. 이 파이프라인이 풀려는 문제는 'LLM이 코드 한 조각을 잘 쓰느냐'가 아니라 '에이전트가 전체 엔지니어링 워크플로우를 소유할 수 있느냐'다.
구조적으로 주목할 설계 포인트는 세 가지다. 첫째, 리포지토리 전체를 컨텍스트 윈도우에 때려 넣는 대신 파일 계층·의존성 그래프·API 엔드포인트를 의미 단위로 인덱싱해 현재 태스크에 필요한 정보만 검색한다. 이건 앞서 다룬 '에이전트 컨텍스트 관리' 문제의 실전 구현이기도 하다. 둘째, 코드를 바로 생성하지 않고 실행 계획을 먼저 만든다. JWT 인증 하나도 미들웨어 생성 → 토큰 검증 → 로그인 엔드포인트 수정 → 프라이빗 라우트 보호 → 통합 테스트 → 문서 업데이트 순서로 분해한다. 계획이 있으면 실패 지점이 특정된다. 셋째, 셀프 커렉션 루프가 내장되어 있다. 첫 시도에 완벽한 코드를 기대하는 게 아니라, 테스트 실패 → 에러 로그 분석 → 수정 계획 → 재작성 → 재테스트의 반복 구조를 설계한다. 다만 무한 루프를 막기 위한 재시도 한계, 에러 클러스터링, 상태 추적은 반드시 팀이 직접 설계해야 한다.
이 아키텍처가 Spec-Driven Development와 연결되는 지점은 명확하다. 레이어 1에서 확정한 스펙 파일이 LLM 플래너의 입력이 되면, 에이전트가 '숨겨진 결정'을 임의로 채울 여지가 사라진다. 스펙은 단순히 문서가 아니라 에이전트 루프의 제약 조건이 된다.
레이어 3: PR 올리기 전, 보안 검증을 파이프라인 안으로 끌어들여라
에이전트가 코드를 짜고 PR을 올릴 수 있다고 해서 그 코드를 바로 머지해도 된다는 뜻은 아니다. AI Engineer World's Fair 보안 트랙에서 Anthropic의 Eugene Yan이 발표한 내용은 이 지점을 정확히 짚는다. AI가 보안 취약점을 찾고 패치를 만드는 속도는 5개월마다 두 배씩 빨라지고 있다. Mozilla가 2025년 4월 단 한 번의 번들로 423개 패치를 릴리즈했는데 이는 2025년 전체 패치 수보다 많다. 속도가 빨라진 만큼 검증 없이 나가는 패치의 리스크도 비례해서 커진다.
Yan이 제안한 6단계 프레임워크는 위협 탐지 → 샌드박스 PoC → 과거 이슈 대조 → 독립 검증 → 트리아지 → 패치 순서로 구성된다. 팀 입장에서 이를 PR 파이프라인에 통합할 때 핵심은 두 가지다. 첫째, AI가 탐지하지 못하는 것은 단일 취약점이 아니라 낮은 위험도의 버그들이 연결되어 만들어지는 복합 익스플로잇이다. 에이전트는 개별 패턴에 강하지만 체인 공격 시나리오에는 여전히 사람의 눈이 필요하다. 둘째, 검증 단계는 파이프라인 끝이 아니라 중간에 있어야 한다. PR이 올라온 다음 보안 검토를 하는 게 아니라, 에이전트가 코드를 완성하고 커밋하기 전에 보안 검증 단계가 루프 안에 포함되어야 한다.
시사점: 세 레이어가 연결될 때 에이전트는 동료가 된다
세 기사를 하나의 파이프라인으로 조립하면 구조가 명확해진다. 스펙 확정 → 에이전트 루프 실행 → 보안 검증 → PR. 이 순서에서 각 레이어는 다음 레이어의 입력 품질을 결정한다. 스펙이 없으면 에이전트 루프는 방향 없이 돌고, 보안 검증이 루프 밖에 있으면 속도와 리스크가 같이 올라간다.
팀이 내일 당장 적용할 수 있는 최소 단위는 이렇다. 첫째, 에이전트에게 태스크를 던지기 전에 SPEC.md를 먼저 쓴다. 모든 상태와 엣지 케이스를 테이블로 정리하는 데 20분이면 충분하다. 둘째, 에이전트가 생성한 코드는 테스트 러너와 린터를 거치는 셀프 커렉션 루프를 통과한 다음에 커밋된다. 이 루프에 재시도 한계와 실패 메모리를 반드시 설계한다. 셋째, PR 전 보안 검증 단계를 파이프라인 안에 명시적으로 배치한다. 자동화 도구로 1차 스캔을 하되, AI가 놓치는 복합 취약점에 대한 사람 리뷰를 트리아지 단계로 구조화한다.
에이전트 자동화의 성패는 모델 성능보다 파이프라인 설계에서 갈린다. 빠르게 PR을 올리는 에이전트가 목표가 아니라, 팀이 신뢰할 수 있는 PR을 올리는 에이전트가 목표다. 그 신뢰는 스펙, 루프, 검증 세 레이어가 순서대로 붙어 있을 때 생긴다.