AI 에이전트가 코드를 짜는 속도는 빨라졌지만, 에이전트가 '무엇을 알고 있는가'와 '무엇을 믿어도 되는가'를 설계하는 일은 여전히 개발자 몫이다. 최근 잇따라 나온 두 가지 실증 사례는 이 사실을 다른 각도에서 동시에 가리키고 있다. 하나는 에이전트에게 넘기는 컨텍스트 품질의 문제이고, 다른 하나는 에이전트가 제안하는 의존성의 신뢰 경계 문제다.
AGENTS.md, LLM이 써주면 안 되는 이유
dev.to에 올라온 연구 분석에 따르면, AGENTS.md를 LLM이 자동 생성하면 8개 설정 중 5개에서 태스크 성공률이 오히려 낮아졌다. 태스크당 단계 수는 늘어났고 추론 비용은 올라갔지만 품질 향상은 없었다. 직관에 반하는 결과지만, 원인을 뜯어보면 납득이 간다. 모델은 '이 프로젝트'를 모른다. 그래서 어느 프로젝트에나 통할 법한 일반 모범 사례를 채워 넣는다. 에이전트가 이미 알고 있는 내용을 다시 말해주는 셈이니, 파일이 길어질수록 노이즈만 늘어나는 구조다.
진짜 가치는 오직 개발자만 아는 맥락에 있다. 고통스러운 버그를 겪고 나서야 채택한 컨벤션, 비자명한 이유로 절대 건드리면 안 되는 디렉터리, 특정 플래그가 붙어야만 작동하는 커맨드—이런 것들은 모델이 추론으로 만들어낼 수 없다. 자동화가 도움이 되는 지점은 딱 하나다. 헤딩 구조와 감지된 툴링을 뼈대로 스캐폴딩해주는 것. 그 이후의 살은 개발자가 직접 붙여야 한다. 테스트 기준은 간단하다. 이 파일이 '어느 프로젝트에도 붙일 수 있는가'—그렇다면 다시 써야 한다.
SBOM이 답하지 못하는 질문
두 번째 사례는 공급망 보안이다. 같은 dev.to에 게재된 글에서 저자는 AI 코딩 에이전트가 npm 패키지를 제안할 때의 구조적 맹점을 짚는다. 에이전트는 패키지 이름이 실재하든, 환각이든, 타이포스쿼팅이든 동일한 확신으로 추천한다. 그리고 현재 팀 대부분이 의존하는 SBOM과 CVE 스캔은 npm install 이후에 작동한다. 어제 등록된 악성 패키지는 CVE가 없다. 스캔은 정직하게 '문제없음'을 반환하고, postinstall 훅은 이미 실행이 끝난 뒤다.
저자가 제시하는 해법은 개념적으로 단순하다. npm install이 실행되기 전에, 에이전트가 제안한 패키지 이름을 검증하는 사전 게이트를 둔다. 검증 기준은 CVE 데이터베이스가 아니라 프로벤넌스—이미 검증된 스냅샷(vouched snapshot)에 있거나, 잘 알려진 베이스라인에 정확히 일치하는가다. expresss는 express와 한 글자 차이지만 결과는 DENY다. 정적 차단 목록이 아니라 '기본 거부, 검증된 것만 허용(default-deny)'의 원칙이 이 게이트의 핵심이다.
두 문제가 가리키는 같은 방향
표면적으로 이 두 이슈는 달라 보인다. 하나는 에이전트에게 넘기는 지시문의 품질 문제이고, 다른 하나는 에이전트가 돌려주는 결과물의 신뢰 문제다. 그런데 구조를 보면 같은 문제다. AI 에이전트는 모르는 것을 그럴싸하게 채운다. AGENTS.md에서는 일반론으로 채우고, 패키지 추천에서는 존재하지 않거나 위험한 이름으로 채운다. 두 경우 모두 '그럴싸함'이 실제 검증을 대체하는 것처럼 보이게 만든다는 점에서 동일한 구조적 취약점이다.
프론트엔드 개발자 관점에서 이건 생산성 대화가 아니라 설계 대화다. 에이전트를 얼마나 빠르게 돌리느냐보다, 에이전트가 작동하는 경계를 어디에 어떻게 그느냐가 결과물의 품질과 안전성을 결정한다. AGENTS.md의 수동 작성은 귀찮은 예외적 작업이 아니라 에이전트 루프의 입력 품질을 보장하는 설계 행위다. 사전 설치 게이트 역시 보안 팀의 영역이 아니라, 에이전트를 의존성 결정에 투입하는 순간 개발 워크플로우 설계에 포함돼야 하는 체크포인트다.
지금 당장 적용할 수 있는 것
두 연구가 공통으로 제안하는 실천 방향은 간단하다. 첫째, AGENTS.md는 스캐폴딩만 자동화하고 프로젝트 고유 맥락은 손으로 채운다. '이 파일이 다른 프로젝트에도 그대로 붙을 수 있는가'를 리트머스 테스트로 쓴다. 둘째, AI 에이전트가 의존성을 제안하는 워크플로우라면 npm install 이전에 이름 기반 프로벤넌스 검증 단계를 CI에 삽입한다. CVE 스캔을 없애는 것이 아니라, 그 앞에 '이름이 신뢰할 수 있는가'를 묻는 레이어를 하나 더 추가하는 것이다.
에이전트가 더 똑똑해질수록 역설적으로 이 경계 설계의 중요성은 커진다. 그럴싸함의 품질이 올라갈수록, 사람이 그걸 그냥 받아들일 가능성도 높아지기 때문이다. 지금 이 시점에 필요한 건 더 나은 모델 선택이 아니라, 에이전트가 모르는 것을 모른다고 인정하게 만드는 구조—즉 개발자가 직접 그은 입력 경계와 출력 검증선이다.