AI-First 팀이 속도를 올리는 동안, 조용히 쌓이는 부채가 있다. SQL Injection이 통과된 PR, 프롬프트 한 줄로 우회되는 에이전트 권한, 그리고 AI가 실무를 대체하면서 흔들리는 팀 구조. 세 문제는 각기 다른 레이어에서 발생하지만, 근원은 하나다. 속도는 설계했는데 신뢰는 설계하지 않았다.
AI가 만드는 보안 버그는 '다른 종류'다
dev.to에 공개된 오픈소스 도구 hallint는 이 문제를 정면으로 겨냥한다. ESLint 같은 전통적인 린터는 인간이 작성한 코드의 문법 오류를 잡도록 설계됐다. 하지만 LLM이 생성하는 버그는 결이 다르다. 문법적으로 완벽하고, 로컬에서도 잘 돌아가고, 코드 리뷰에서도 무난히 통과된다. 문제는 프로덕션에서 터진다.
hallint가 타깃으로 삼는 패턴은 AI 코딩 어시스턴트가 반복적으로 저지르는 실수들이다. const API_KEY = "sk-abc123"처럼 소스에 박힌 시크릿, 템플릿 리터럴로 조합된 SQL 쿼리, CRUD 라우트에서 빠진 인증 미들웨어, 그리고 가장 교묘한 패턴—try/catch가 토큰 오류를 삼키고도 next()를 호출해 미인증 요청을 조용히 통과시키는 'auth masking'. 이건 주니어 개발자가 실수로 빠뜨리는 수준이 아니다. AI가 '그럴듯한 코드'를 생성하는 과정에서 구조적으로 반복되는 실패 모드다.
도구 자체는 단순하다. npx @asyncinnovator/hallint-cli ./src 한 줄로 스캔할 수 있고, CI/CD 파이프라인의 머지 게이트로 붙이는 것도 가능하다. Regex 패턴 매칭, AST 분석, 옵션으로 LLM 기반 시맨틱 분석까지 3단 레이어로 구성됐다. 현재 11개 룰을 지원하며 MIT 라이선스로 공개돼 있다. 내가 봤을 때 이 도구의 가치는 기능보다 관점에 있다. "AI가 생성한 코드에는 AI에 특화된 린터가 필요하다"는 전제 자체가 맞다.
에이전트 권한, 프롬프트가 아니라 코드로 박아야 한다
보안 버그보다 더 근본적인 문제가 있다. AI 에이전트에게 어떤 행동을 허용할지 여전히 시스템 프롬프트로만 관리하는 팀이 많다. "이메일을 함부로 보내지 마라", "파일을 삭제하기 전에 확인해라"—이런 지시는 모델의 기분에 따라 지켜지거나 무시된다. Prompt Injection 공격 앞에서는 더욱 무력하다.
dev.to에서 소개된 접근법은 명확하다. 권한 정책을 코드로 작성하고, 에이전트 런타임과 실제 툴 실행 사이에 위치시켜라. 구조는 간단하다. 읽기 전용 도구는 허용, 사이드 이펙트가 있는 도구는 명시적 승인 필요, 알 수 없는 도구는 기본 차단. 특히 세 번째 룰이 핵심이다. 기본 허용 정책은 새 도구가 추가될 때마다 조용히 취약해진다.
프로덕션 수준의 설계라면 승인 플래그 하나(userApproved: true)보다 더 정밀해야 한다. 수신자, 본문 해시, 만료 시각까지 포함한 승인 레코드를 만들고, 실행 직전에 비교하는 구조가 필요하다. 사용자가 team@example.com에게 메일 하나를 승인했다고, 에이전트가 수신자를 바꿔서 재사용할 수 있어선 안 된다. 승인은 재사용 가능한 토큰이 아니라 단일 액션에 스코프된 일회성 레코드여야 한다.
이 패턴의 진짜 이득은 디버깅에서 나온다. 정책이 에이전트 런타임 밖에 분리돼 있으면, 액션이 차단됐을 때 "밸리데이션 실패인가, 승인 누락인가, 만료인가"를 로그로 구분할 수 있다. 정책이 프롬프트 안에 섞여 있으면 모든 실패가 불가사의한 에이전트 동작으로 보인다. 정리하면: 프롬프트는 행동을 안내하고, 코드가 권한을 집행한다.
조직도가 바뀌는 속도가 코드보다 빠르다
하버드 비즈니스 스쿨과 INSEAD의 공동 연구는 AI 네이티브 스타트업이 일반 스타트업보다 평균 25% 적은 인력으로 동등한 기업 가치를 만들어내고 있다고 분석했다. 포인트하운드는 직원 4명으로 75만 명의 사용자를 커버한다. 매출이 10배 늘어도 추가 채용은 2명 정도면 충분하다는 게 CEO의 예측이다. 이건 채용을 덜 하는 게 아니라, AI 에이전트가 실무를 구조적으로 흡수한 결과다.
연구에서 주목할 포인트는 조직 계층의 변화다. 신입 인력과 관리자급이 각각 약 15% 줄었고, 승진 단계도 단순해졌다. AI 에이전트가 반복 실무를 맡으면서 주니어가 하던 일이 사라지고, 그 위를 감독하던 중간 관리 계층도 얇아진다. 오프딜이 처음부터 신입을 대거 채용하지 않은 이유도 여기 있다. 기존 방식을 답습하는 순간, 프로세스 혁신의 기회를 잃는다.
테크 리드 입장에서 이 숫자는 조직 설계를 다시 생각하게 만든다. AI 도구를 기존 팀에 얹는 방식으론 25% 효율화를 따라잡기 어렵다. AI를 전제로 업무 흐름 자체를 재설계해야 한다는 게 연구진의 결론이고, 실제로 대형 테크 기업들—아마존, 메타, 마이크로소프트까지—이 방향으로 움직이고 있다.
세 레이어를 동시에 잡아야 한다
hallint는 코드 레이어의 신뢰 구조다. 에이전트 권한 정책은 런타임 레이어의 신뢰 구조다. AI 네이티브 조직 재설계는 팀 레이어의 신뢰 구조다. 이 세 가지는 별개의 문제가 아니다. AI-First 팀이 속도를 지속적으로 유지하려면 세 레이어를 동시에 설계해야 한다.
속도는 구조 없이도 낼 수 있다. 하지만 그 속도는 결국 보안 사고, 에이전트 오작동, 조직 혼란으로 반환된다. 코드 생성이 쉬워질수록 신뢰 구조 설계는 더 명시적이어야 한다. AI가 짠 코드를 검증하는 파이프라인, 에이전트 권한을 코드로 집행하는 정책, AI를 전제로 설계된 팀 구조—이 세 가지가 갖춰졌을 때 비로소 AI-First 팀의 속도는 지속 가능해진다.