에이전트가 짠 코드, 얼마나 믿을 수 있나
AI 코딩 에이전트가 SDLC 전 단계를 커버하기 시작했다. Addy Osmani가 공개한 agent-skills 레포는 spec, plan, build, verify, review, ship까지 24개 프로덕션 스킬을 패키징해 72.6k 스타를 받았다. 현대해상·LG유플러스·SK AX는 AWS의 AI-DLC 방법론으로 6시간 안에 요구사항 정의부터 구현까지 완료했다고 밝혔다. 숫자만 보면 에이전트 도입은 선택이 아니라 의무처럼 느껴진다.
그런데 같은 주에 dev.to에는 다른 이야기가 올라왔다. Cursor에게 로그인 엔드포인트를 짜달라고 했더니 교과서적인 SQL 인젝션 구멍이 달린 코드가 나왔다는 실증 리포트다. 코드는 정상 입력에서 완벽하게 작동했고, 코드 리뷰에서도 쿼리가 '읽기에는' 문제없어 보였다. 문제는 ' OR '1'='1 같은 페이로드를 넣어본 순간에야 드러났다.
왜 에이전트는 같은 실수를 반복하나
이 현상의 원인은 단순하다. AI 에이전트는 수백만 개의 튜토리얼과 StackOverflow 답변으로 훈련됐고, 그 예제 대부분이 템플릿 리터럴로 SQL을 조립한다. 짧고 읽기 쉽기 때문이다. 모델은 '가장 자주 본 패턴'을 재현할 뿐, 악의적인 입력을 상상하지 않는다. CWE-89로 분류되는 이 취약점은 에이전트가 게을러서가 아니라 구조적으로 '안전하지 않은 예제'를 더 많이 학습했기 때문에 발생한다.
이건 Cursor만의 문제가 아니다. GitHub Copilot이든 Claude Code든, 컨텍스트에 보안 제약이 명시되지 않으면 모두 같은 패턴을 반복할 가능성이 높다. 수정법은 간단하다. 사용자 입력을 SQL 문자열에 직접 끼워 넣지 말고, 파라미터화된 쿼리로 분리해 드라이버가 처리하게 하면 된다. 하지만 진짜 문제는 "왜 팀이 이걸 배포 전에 잡지 못했는가"다.
스킬셋은 완성됐다, 이제 검증 구조가 필요하다
Addy Osmani의 agent-skills가 72.6k 스타를 받은 이유는 단순히 저자의 명성 때문이 아니다. 이 레포에서 주목할 것은 verify 단계에 browser-testing-with-devtools와 security-and-hardening이 명시적으로 포함돼 있다는 점이다. 더 흥미로운 건 doubt-driven-development 스킬이다. 긴 세션 끝에 가정이 굳어진 시점에 의도적으로 '승인이 아니라 반증을 찾는' 신선한 리뷰어를 스폰하는 방식이다. SQL 인젝션 사례가 정확히 이 스킬이 예방하려는 시나리오다.
source-driven-development도 같은 맥락이다. 프레임워크별 결정은 모델의 기억이 아니라 공식 문서를 먼저 참조하게 한다. 에이전트가 '알고 있다고 생각하는 것'과 '실제로 안전한 것' 사이의 간극을 줄이는 설계다. 이 두 스킬은 레포를 설치하지 않아도 당장 팀 규칙으로 적용할 수 있다.
엔터프라이즈가 증명한 것: 속도는 구조에서 나온다
AI-DLC 사례에서 인상적인 건 6시간이라는 숫자보다 '단계마다 사람이 검토하는 절차가 포함돼 있다'는 SK AX 매니저의 발언이다. LG유플러스 담당자는 '문서를 보는 사람마다 해석이 달라지는 문제'를 AI-DLC가 해결했다고 했다. 둘 다 같은 이야기를 하고 있다. AI가 속도를 만들고, 구조가 품질을 보증한다는 것.
이게 핵심 시사점이다. AI-DLC가 보여준 모델은 에이전트에게 전권을 주는 게 아니라, 각 단계에서 사람이 검토·승인하는 게이트를 유지하면서 에이전트가 초안과 분석을 제공하는 구조다. Addy Osmani의 스킬셋이 excuse-preemption table—에이전트가 단계를 건너뛰려 할 때의 핑계와 반론을 명시한 구조—을 포함하는 것도 같은 철학이다. 에이전트는 스스로 멈추지 않는다. 팀이 멈출 지점을 설계해야 한다.
팀 리드가 당장 해야 할 세 가지
세 소스를 엮으면 실행 과제가 보인다.
첫째, 보안 게이트를 코드 생성 시점에 붙여라. SafeWeave나 semgrep 같은 pre-commit 훅을 Cursor·Claude Code에 연결하면 인터폴레이션 SQL이 생성되는 순간 플래그가 뜬다. 리뷰 단계까지 기다리지 말고 생성 직후 잡아야 한다.
둘째, 에이전트 스킬셋을 팀 컨텍스트에 맞게 조립하라. agent-skills를 통째로 켜는 건 비효율이다. 팀의 주요 스택에 맞는 스킬만 활성화하되, security-and-hardening과 doubt-driven-development는 어떤 팀이든 기본값으로 가져가는 게 맞다.
셋째, SDLC 단계별 human-in-the-loop 체크포인트를 명문화하라. AI-DLC 사례처럼 요구사항→설계→구현→검증 각 단계에 사람의 승인 없이는 다음 단계로 넘어가지 않는 규칙이 있어야 에이전트의 속도가 팀의 사고를 앞질러가는 상황을 막을 수 있다.
에이전트는 동료지만, 구조 없이는 위험한 동료다
솔직히 말하면, AI 코딩 에이전트의 스킬셋은 이미 팀 시니어 엔지니어 수준에 근접했다. Addy Osmani의 24개 스킬은 그 근거다. 문제는 에이전트가 '모르는 걸 모른다는 신호'를 보내지 않는다는 데 있다. SQL 인젝션 코드를 자신 있게 건네는 것처럼.
엔터프라이즈 팀들이 AI-DLC로 얻은 진짜 성과는 속도보다 '산출물의 일관성'이었다. 그 일관성은 에이전트가 만든 게 아니라, 에이전트가 따를 구조를 팀이 설계했기 때문에 나왔다. AI-First 전환의 출발점은 더 좋은 에이전트를 찾는 것이 아니라, 에이전트가 실수해도 팀이 잡아낼 수 있는 구조를 먼저 짜는 것이다.