AI 코딩 에이전트를 볼 때 요즘 제일 먼저 떠오르는 단어는 모델 이름이 아니다. 하네스다. 조금 전까지만 해도 관심은 Claude Code, Codex, Cursor, Antigravity, OpenCode 같은 도구 비교에 몰려 있었다. 누가 더 긴 작업을 버티는지, 누가 더 큰 diff를 잘 내는지, 누가 PR까지 밀어 넣는지가 뉴스였다.
근데 6월 첫째 주 흐름을 보면 질문이 바뀌고 있다. HackerNoon에는 AI에게 작업용 하네스를 줘야 한다는 글이 다시 돌았고, Security Boulevard 쪽 RSS에는 2026년 AI 코딩 에이전트 12종 비교 글이 올라왔다. 동시에 StepSecurity는 Miasma Worm이 Microsoft Azure Functions Action과 72개 저장소를 비활성화하게 만든 공급망 공격을 다뤘다. Infosecurity Magazine도 agentic development 시대에는 AI 코딩 도구에 보안이 내장돼야 한다는 이야기를 실었다.
처음엔 이 뉴스들이 따로 노는 것처럼 보였다. 하나는 생산성 팁이고, 하나는 도구 비교고, 하나는 공급망 공격이고, 하나는 보안 컨퍼런스 이야기다. 그런데 묶어서 보면 메시지는 꽤 단순하다. 이제 AI 코딩 에이전트는 “좋은 모델을 골라 쓰는 문제”가 아니라 “어떤 울타리 안에서 일하게 할지 정하는 문제”가 됐다.
이전에 AI 코딩을 천천히 쓰는 법을 쓰면서도 비슷한 얘기를 했다. AI가 코드를 많이 만든다고 팀이 바로 빨라지는 건 아니다. 누군가는 그 변경을 읽고, 의심하고, 테스트하고, 운영 사고 가능성을 상상해야 한다. 이번 글은 그 다음 단계다. 리뷰만 잘하는 것으로는 부족하고, 에이전트가 움직이는 작업장 자체를 설계해야 한다.
에이전트는 개발자가 아니라 작업자에 가깝다
좋은 답보다 안전한 작업 범위가 먼저다
AI 코딩 에이전트를 사람 개발자처럼 생각하면 기대치가 이상해진다. 사람은 회사 맥락을 알고, 권한의 무게를 알고, “이건 지금 하면 안 되겠다”는 감각을 갖는다. 물론 사람도 실수한다. 그래도 운영 DB에 붙기 전, 고객 데이터가 섞인 로그를 열기 전, 배포 버튼을 누르기 전에는 어느 정도 멈칫한다.
에이전트는 다르다. 에이전트는 주어진 목표를 끝까지 밀고 가는 쪽으로 설계된다. “테스트 고쳐줘”라고 하면 테스트를 고친다. “빌드 통과시켜줘”라고 하면 빌드를 통과시키려 한다. 이게 장점이면서 위험이다. 목표가 좁고 환경이 안전하면 생산성이 나온다. 반대로 목표가 넓고 권한이 크면, 에이전트는 너무 성실하게 위험한 일을 할 수 있다.
그래서 하네스가 필요하다. 여기서 하네스는 멋진 프레임워크 이름이 아니다. 작업 디렉터리, 권한, 네트워크, 시크릿 접근, 테스트 명령, 승인 조건, 롤백 기준을 묶은 실행 울타리다. “무슨 모델을 쓸까”보다 “이 모델이 실패해도 어디까지 망가질 수 있나”가 먼저다.
하네스 없는 에이전트는 자동화된 인턴이다
나는 에이전트를 자동화된 시니어 개발자라기보다, 아주 빠르고 지치지 않는 인턴에 가깝게 본다. 문서를 빨리 읽고, 파일을 빨리 고치고, 로그를 빨리 뒤진다. 대신 조직의 금지선은 모른다. 이 프로젝트에서 절대 건드리면 안 되는 파일, 고객사별 예외, 오래된 배포 스크립트의 함정, “이건 대표가 직접 확인해야 하는 변경” 같은 건 말해주지 않으면 모른다.
문제는 속도다. 사람이 모르면 물어본다. 에이전트는 물어보기 전에 여러 파일을 고치고, 새 브랜치를 만들고, 패키지를 설치하고, 때로는 외부 네트워크까지 친다. 그래서 에이전트 운영에서 중요한 건 똑똑함의 상한보다 사고 반경의 하한이다. 아무리 좋은 모델이어도 하네스가 없으면, 작은 오해가 너무 빨리 커진다.
이번 공급망 뉴스가 찝찝한 이유
공격자는 이제 에이전트의 습관을 노린다
StepSecurity가 다룬 Miasma Worm 이슈가 불편한 이유는 단순히 “또 공급망 공격이 있었네”가 아니기 때문이다. 보도에 따르면 Azure Functions Action과 다수 저장소가 비활성화됐고, 공격 서사는 AI 코딩 도구와 공급망의 연결을 정면으로 건드린다. 개발자가 직접 악성 코드를 붙이는 것보다, 자동화된 작업 루프가 오염된 패키지나 액션을 더 빠르게 받아들이는 그림이 더 무섭다.
요즘 개발 환경은 이미 자동화로 꽉 차 있다. 패키지 매니저가 있고, GitHub Actions가 있고, Dependabot이 있고, release bot이 있고, 이제 coding agent까지 있다. 각 도구는 혼자 보면 유용하다. 그런데 모두가 쓰기 권한, 토큰, 네트워크 접근을 조금씩 가지면 전체 시스템은 꽤 복잡해진다.
공격자는 이 복잡성을 좋아한다. 사람이 한 줄씩 읽는 코드보다, 자동화가 믿고 실행하는 경로가 더 효율적인 표적이 된다. 특히 에이전트가 “문제를 고치기 위해” 새로운 dependency를 추가하거나, CI 설정을 만지거나, 토큰이 필요한 명령을 실행할 수 있다면 더 그렇다.
공급망 보안은 이제 개발자 PC 안쪽 문제다
예전에 TrapDoor 공급망 공격을 보면서도 느낀 건데, 공급망 보안은 더 이상 registry나 CI 서버만의 일이 아니다. 개발자 로컬, 에이전트 작업 폴더, 브라우저 세션, CLI 토큰, 다운로드 폴더까지 연결된다. AI 코딩 도구가 이 모든 경로를 대신 만지기 시작하면 보안 경계는 더 안쪽으로 들어온다.
그래서 “에이전트가 코드를 잘 짜나”라는 질문만으로는 부족하다. “에이전트가 뭘 설치할 수 있나”, “어떤 환경 변수를 볼 수 있나”, “어떤 URL로 나갈 수 있나”, “실패했을 때 어떤 로그를 남기나”를 같이 봐야 한다. 이건 재미없는 체크리스트처럼 보이지만, 운영에서는 결국 이런 질문이 사고를 막는다.
내가 보는 최소 하네스
작업장은 복제 가능해야 한다
첫 번째는 격리된 작업장이다. 에이전트가 직접 main 작업 폴더를 만지는 순간 위험이 커진다. 최소한 별도 브랜치나 worktree, 컨테이너, 임시 디렉터리 중 하나는 있어야 한다. 실패하면 통째로 버릴 수 있어야 하고, 성공하면 diff만 남길 수 있어야 한다.
여기서 중요한 건 “되돌릴 수 있음”이다. 에이전트 작업은 실패를 전제로 설계해야 한다. 잘하면 좋고, 틀리면 빨리 폐기한다. 이 구조가 있으면 에이전트에게 조금 더 많은 시도를 맡길 수 있다. 반대로 폐기 구조가 없으면 작은 작업도 계속 긴장하면서 봐야 한다.
권한은 처음부터 작아야 한다
두 번째는 권한이다. 에이전트에게 처음부터 모든 토큰을 주면 안 된다. 읽기 권한, 쓰기 권한, 배포 권한, 결제/인프라 권한은 분리해야 한다. 특히 production secret, 고객 데이터, 클라우드 관리자 권한은 기본적으로 차단하는 쪽이 맞다.
이건 모델을 못 믿어서가 아니다. 모델이 너무 많은 일을 대신할 수 있기 때문이다. 도구가 강해질수록 권한은 작게 나눠야 한다. 작은 권한으로도 충분한 작업은 많다. 파일 수정, 테스트 실행, 문서 작성, 실패 로그 분석은 대체로 큰 비밀을 몰라도 된다.
테스트보다 먼저 금지선을 적어야 한다
세 번째는 금지선이다. “테스트 통과”만으로는 부족하다. 에이전트가 해서는 안 되는 행동을 명시해야 한다. 예를 들면 이런 식이다.
- 새 dependency 추가 전에는 이유를 남긴다.
- CI/CD 설정 변경은 별도 승인 없이는 커밋하지 않는다.
- secret, cookie, signed URL은 출력하지 않는다.
- 운영 DB에 쓰기 작업을 하지 않는다.
- 실패를 숨기기 위해 테스트를 삭제하거나 skip하지 않는다.
이런 문장은 너무 당연해 보인다. 근데 자동화에서는 당연한 게 제일 자주 빠진다. 사람에게는 상식인 선이 에이전트에게는 시스템 프롬프트나 체크리스트로 들어가야 한다.
CI는 마지막 심판이 아니라 중간 게이트다
에이전트에게 테스트 결과를 그대로 먹이면 안 된다
많은 팀이 “에이전트가 테스트 돌리고 고치게 하면 되지”라고 생각한다. 나도 그렇게 많이 쓴다. 근데 이 흐름에는 함정이 있다. 에이전트가 테스트 실패를 고칠 때, 정말 제품을 고치는지 테스트의 의미를 약하게 만드는지 구분해야 한다.
예를 들어 assertion을 느슨하게 바꾸거나, flaky test라고 판단해서 skip하거나, mock을 과하게 넓히면 빌드는 통과할 수 있다. 사람도 이런 유혹을 받는다. 에이전트는 더 빠르게 받을 수 있다. 그래서 CI 결과는 마지막 심판이 아니라 중간 게이트로 봐야 한다. 테스트 통과 뒤에도 diff 리뷰, 보안 스캔, 영향 범위 확인이 필요하다.
시크릿 스캔은 옵션이 아니다
에이전트 작업에서 특히 무서운 건 출력이다. 에러 로그를 붙여 넣다가 토큰이 섞일 수 있고, 브라우저에서 받은 signed URL을 증빙에 남길 수 있고, 설정 파일을 읽다가 필요 없는 값을 요약할 수 있다. 사람이면 “아 이거 가려야지”라고 생각할 수 있지만, 에이전트는 목표가 “증빙 남기기”면 너무 성실하게 다 남긴다.
그래서 secret scanning은 배포 직전 옵션이 아니라 작업 루프 안쪽에 있어야 한다. 커밋 전 스캔, 로그 redaction, evidence 파일 검사, PR 본문 검사까지 들어가야 한다. 특히 AI 에이전트가 이미지 생성, 배포 대시보드, Search Console 같은 브라우저 세션을 만질 때는 signed URL과 세션 정보가 섞일 여지가 생긴다.
사람 승인은 병목이 아니라 보험이다
모든 작업을 승인하자는 뜻은 아니다
사람 승인을 이야기하면 자동화가 느려진다고 느껴진다. 맞다. 모든 작업에 승인을 걸면 에이전트를 쓰는 의미가 줄어든다. 그래서 승인 게이트는 전부가 아니라 위험도 기준으로 걸어야 한다. 문서 수정, 테스트 추가, 작은 리팩터링은 자동으로 끝낼 수 있다. 반면 배포, 권한 변경, DB migration, CI 설정 변경, 외부 API 비용이 생기는 작업은 멈춰야 한다.
중요한 건 승인 버튼 자체보다 기준이다. 어떤 변경은 자동 merge 가능하고, 어떤 변경은 리뷰어가 봐야 하고, 어떤 변경은 보안 담당이나 운영자가 봐야 하는지 정해야 한다. 이 기준이 없으면 매번 감으로 판단하게 된다. 감은 피곤할 때 무너진다.
운영자는 에이전트의 속도가 아니라 경계를 설계해야 한다
AI 코딩 에이전트 시장은 계속 도구 비교로 갈 것이다. 그건 당연하다. 누가 더 빠른지, 누가 더 긴 컨텍스트를 버티는지, 누가 터미널을 잘 다루는지는 계속 중요하다. 하지만 실제 운영에서는 다른 질문이 더 오래 남는다.
이 에이전트는 어디까지 읽을 수 있나. 어디까지 쓸 수 있나. 실패하면 무엇을 남기나. 어떤 변경에서 멈추나. 어떤 증거를 보고 성공이라고 말하나. 이 질문에 답하지 못하면 좋은 모델을 붙여도 팀은 불안해진다.
나는 앞으로 작은 팀일수록 하네스를 먼저 만들어야 한다고 본다. 거창한 플랫폼이 아니어도 된다. 별도 worktree, 명확한 금지선, 테스트 명령, secret scan, 배포 전 확인, GSC나 운영 대시보드 같은 브라우저 작업의 redaction 규칙부터 시작하면 된다. 에이전트가 똑똑해질수록 이 울타리는 선택이 아니라 기본값에 가까워진다.
결국 핵심은 간단하다. AI 코딩 에이전트를 더 많이 쓰려면, 먼저 덜 위험하게 실패하게 만들어야 한다. 그게 없으면 자동화는 속도가 아니라 부채가 된다.