에이전트를 도입하면 생산성이 오른다. 이건 이제 논쟁거리가 아니다. 문제는 그다음 질문이다. 얼마나 믿고 맡길 수 있는가? 최근 세 가지 영역에서 구체적인 증거가 쌓이고 있다. 메모리, 보안, 그리고 팀 구조. 세 축을 함께 보면 에이전트 신뢰 가능성의 실제 윤곽이 드러난다.
1. 에이전트는 같은 실수를 반복한다
dev.to에 올라온 한 글은 AI 코딩 에이전트의 가장 비싼 실수는 처음 틀리는 게 아니라 이미 고친 것을 다음 세션에서 또 틀리는 것이라고 짚는다. 개발자가 왜 그 마이그레이션 패턴이 스테이징을 깨는지 설명했다. 에이전트가 고쳤다. 세션이 끝났다. 이틀 뒤, 새 세션의 에이전트는 같은 제안을 한다. 아무 일도 없었다는 듯이.
이 문제의 본질은 컨텍스트 윈도우 크기가 아니다. 글에서는 이를 '흉터 조직(Scar Tissue)'의 부재로 표현한다. 프롬프트에 파일을 더 넣고 문서를 더 붙이는 건 컨텍스트를 늘리는 것이지, 에이전트가 무언가를 학습하게 만드는 게 아니다. 컨텍스트는 에이전트에게 '지금 주변에 뭐가 있는지'를 알려주지만, 흉터 조직은 '왜 그 선택이 실패했는지'를 기억하게 한다. 이 둘은 전혀 다른 것이다.
AI-First 팀 리빌딩 관점에서 이 문제는 즉각적으로 실행 가능한 설계 질문으로 바뀐다. 프로젝트별 실패 이력—"이 패키지는 Vercel 네이티브 의존성 문제로 사용 불가", "이 미들웨어는 어드민 라우트 보호 중이니 건드리지 말 것"—을 어디에, 어떤 형식으로 누가 관리할 것인가. 에이전트의 메모리 레이어를 설계하지 않으면, 팀은 같은 수정을 반복하며 신뢰를 소모한다.
2. LLM 보안 스캔은 한 칸만 본다
Anthropic이 발표한 LLM 기반 소스코드 보안 가이드는 실용적이다. 위협 모델링 → 샌드박스 → 탐지 → 검증 → 트리아지 → 패치의 6단계 루프, 탐지와 검증을 별도 에이전트로 분리하는 구조는 실제 팀에서 쓸 수 있는 방식이다. SQL 인젝션, 버퍼 오버플로우, 입력값 미검증 같은 패턴 인식 가능한 소스코드 결함 탐지에는 LLM이 실질적으로 유효하다.
그런데 같은 dev.to 글에서 지적하듯, 이 가이드가 '소스코드 보안'이라는 프레이밍을 쓰는 순간 나머지 세 영역이 보이지 않게 된다. 공개된 S3 버킷은 소스코드 취약점이 아니다. IAM 역할이 다른 역할을 assume하고 민감한 버킷을 읽을 수 있는 복합 경로는 각각의 코드에선 아무 문제가 없다. CDN에는 올바른 public 설정이 고객 데이터 버킷에 적용되면 침해가 된다. 이 세 가지는 LLM이 소스코드를 아무리 잘 스캔해도 잡을 수 없다.
보안 문제는 사실 네 개의 서로 다른 영역으로 나뉜다. 애플리케이션 코드, 애플리케이션 설정, 인프라 코드(Terraform 등), 실제 배포된 인프라 상태. 각각 다른 도구가 필요하고 다른 방식으로 변한다. AI-First 팀이 보안 파이프라인을 설계할 때 'LLM 코드 스캔을 붙였으니 됐다'고 판단하는 순간, 나머지 세 칸이 맹점이 된다. 어떤 도구가 어떤 칸을 커버하는지 명시적으로 매핑해두지 않으면, 보안 커버리지에 구멍이 생긴다.
3. 고용 구조는 이미 바뀌고 있다
숫자부터 보자. 2023~2025년 사이 미국의 'computer programmer' 직군 고용은 27.5% 감소했다. 2024년 엔트리레벨 기술직 채용은 전년 대비 25% 줄었다. Stanford 디지털경제연구소에 따르면 22~25세 소프트웨어 개발자 고용은 2022년 정점 대비 약 20% 하락했다.
그런데 같은 기간 'software developer' 직군—아키텍처, 설계, 시스템 통합, 기술 의사결정을 포함하는—은 0.3% 감소에 그쳤다. BLS는 2034년까지 이 직군이 15~18% 성장할 것으로 전망하고 있다. AI 엔지니어 수요는 연평균 20.78% 성장률로 2030년까지 1,172만 개 역할이 생길 것으로 예측된다.
이건 제거가 아니라 압축이다. 명세를 코드로 변환하는 루틴 작업은 자동화되고 있다. 그 위에 앉아 있는 아키텍처, 오케스트레이션, 판단 업무는 확장되고 있다. 시니어 엔지니어 한 명이 Claude Code를 쓰면 이전에 세 명이 하던 일을 처리할 수 있다. 레버리지가 생긴 것이다.
단, 여기서 냉정하게 봐야 할 숫자가 하나 있다. METR 2025 통제 실험에서 AI 도구를 사용한 숙련 개발자들은 19% 더 느려졌다. 도구의 역량 문제가 아니다. AI 생산성 향상은 접근 권한만으로 생기지 않는다. AI를 다루는 기술이 필요하다. 팀 리빌딩에서 이 지점을 놓치면 도구를 도입해도 실질적 레버리지를 얻지 못한다.
세 축이 가리키는 하나의 질문
메모리, 보안, 역할 변화—세 영역의 증거가 수렴하는 지점은 결국 같다. 에이전트를 신뢰하는 것과 에이전트를 검증하는 것은 다른 행위다. 에이전트가 반복 실수를 하지 않으려면 팀이 실패 이력을 구조화해야 한다. 보안 커버리지에 구멍이 없으려면 어떤 도구가 어떤 칸을 담당하는지 명시해야 한다. 레버리지를 실제로 얻으려면 AI를 다루는 능력을 팀 전체에 체계적으로 쌓아야 한다.
낙관은 필요하다. 에이전트의 잠재력은 실재한다. 하지만 팀 리빌딩에서 낙관이 검증을 대체하는 순간, 에이전트의 실패는 조용히 쌓인다. 지금 당장 팀에 던져야 할 질문은 세 가지다. 에이전트의 반복 실수를 기록하고 있는가. 보안 도구가 커버하는 칸과 못 커버하는 칸을 구분하고 있는가. AI 도구 도입 후 실제로 빨라졌는지 측정하고 있는가. 이 세 질문에 답이 없다면, 신뢰는 아직 이르다.