‘AI가 코드를 짜준다’는 말은 이제 뉴스거리도 아닙니다. 그런데 같은 날 나온 소식이라도, 개발자 편집기에 붙는 자동완성, 기업 ERP에 붙는 업무 에이전트, 공무원이 직접 조립하는 행정용 에이전트는 층위가 완전히 다릅니다. 이걸 뭉뚱그려 읽으면 ‘결국 뭐가 달라지나’가 흐려지고, 도입 판단도 감으로 흐릅니다. 이 글은 개인 도구 → 운영·보안 마찰 → 인력·역량 논쟁 → 기업·공공 확산이라는 네 갈래를 하나의 흐름으로 묶어, 각각 어떤 조건에서 의미가 있고 어디서 오해가 생기는지를 기준으로 정리합니다.
관통하는 축은 하나입니다. 작업의 단위가 ‘사람이 한 줄씩 치는 코드’에서 ‘에이전트가 통째로 실행하는 작업’으로 옮겨가고 있다는 것. 자동완성은 사람이 운전대를 잡은 채 방향지시를 받는 수준이지만, 에이전트는 파일을 읽고 명령을 연쇄 실행하고 외부와 통신하는 ‘실행 주체’입니다. 이 차이를 잡고 봐야 아래 네 조각이 같은 방향의 다른 단면이라는 게 보입니다.
개인용 코딩 도구: ‘켜는 기능’이 아니라 ‘세팅하는 환경’
초기 도구는 편집기 안에서 다음 줄을 추천하는 자동완성이었습니다. 지금은 저장소 전체를 인덱싱하고, 여러 파일을 동시에 고쳐 커밋 직전까지 끌고 가는 ‘개발환경’으로 넘어갔습니다. 그래서 ‘설치하면 끝’이 아니라 최소한 편집기 확장 설치 → 구독·인증 → 프로젝트 인덱싱 → 컨텍스트(어떤 파일·폴더를 모델이 보게 할지) 지정까지가 한 세트입니다. 첫 세팅에 보통 30분 안팎이 들고, 이 단계를 건너뛴 채 ‘왜 엉뚱한 코드를 주냐’고 불평하는 경우가 초보자에게 가장 흔합니다.
도입 전 반드시 계산할 지점은 세 가지입니다. 첫째, 비용이 구독제인지 사용량제인지. 개인 정액 구독은 예측 가능하지만, API 토큰 과금이나 좌석제 팀 라이선스는 인원과 호출량에 따라 요금이 몇 배로 튑니다. ‘한 달에 몇 명이, 얼마나 자주 부르는가’를 먼저 추산하고, 상시 사용 인원이 늘면 정액 좌석제가 유리한 구간이 오는지 비교해야 합니다. 둘째, 컨텍스트 한계. 모델이 볼 수 있는 범위(토큰)는 유한해서, 저장소가 이 한도를 넘으면 ‘열려 있는 파일 + 인덱싱된 일부’만 참고합니다. 수십만 줄짜리 레거시에서 제안 품질이 급락하는 이유가 이것이고, 대형 코드일수록 관련 파일을 직접 열어주는 ‘컨텍스트 큐레이션’이 사람의 몫으로 남습니다. 셋째, 생성물은 검증된 코드가 아니라 초안이라는 점. 문법이 그럴듯해 보여도 프로젝트 규칙과 어긋나거나 조용한 버그를 품을 수 있어, 생성량이 늘수록 오히려 테스트·리뷰의 비중이 커집니다. 정리하면 도입의 최소 조건은 ‘써보는 것’이 아니라 세팅 30분과 검증 루틴 확보입니다.
정상 작업이 ‘공격’으로 잡힌다: 새로 생긴 운영 마찰
뜻밖의 함정은 기능이 아니라 운영에서 터집니다. 클로드 코드류 에이전트는 짧은 시간에 파일 수십 개를 읽고 쓰고, 셸 명령을 연쇄 실행하며, 패키지를 받으려 외부와 통신합니다. 문제는 이 행동 패턴이 EDR·이상행위 탐지 입장에서 랜섬웨어의 대량 파일 접근이나 데이터 유출 스크립트와 통계적으로 구별하기 어렵다는 데 있습니다. 사람이 손으로 할 땐 초당 한두 동작이던 것이 에이전트에선 수십 동작으로 뛰니, 탐지 규칙의 임계값을 넘겨 정상 작업이 차단·격리되는 오탐이 보고됩니다. 도구가 나빠서가 아니라, 속도와 규모가 기존 방어선의 전제를 벗어났기 때문입니다.
대응은 순서가 있습니다. (1) 도입 전 그 도구가 어떤 계정으로 돌고, 어떤 폴더에 접근하며, 어떤 도메인과 통신하는지를 먼저 문서화합니다 — 이걸 모르면 예외 처리도 근거 없이 하게 됩니다. (2) 여기서 최악의 선택이 ‘귀찮으니 보안 솔루션을 끄는’ 것인데, 진짜 위협까지 함께 눈감는 셈이라 오탐보다 훨씬 위험합니다. (3) 대신 프로젝트 폴더와 필수 도메인만 최소 권한으로 허용하고, 홈 디렉터리 전체나 자격증명 경로처럼 넓은 화이트리스트는 피합니다. (4) 오탐 로그를 2~4주 모아 규칙을 점진적으로 튜닝합니다. 개인·소규모 팀이라도 최소한 ‘이 도구가 내 어떤 폴더와 어떤 외부 주소에 닿는가’는 파악하고 시작해야, 나중에 사고가 났을 때 원인 추적이 가능합니다.
‘팀 규모는 중요하지 않다’는 선언, 어디까지가 사실인가
한 게임 엔진 기업(유니티) 경영진은 AI 코딩 에이전트를 근거로 ‘팀 규모가 더는 핵심 변수가 아니다’는 취지의 발언을 공개적으로 내놨습니다. 방향은 흐름과 맞습니다. 보일러플레이트, 테스트 코드 초안, API 마이그레이션처럼 정답에 가까운 반복 작업은 에이전트가 상당 부분 떠맡을 수 있어, 같은 인원이 더 넓은 범위를 커버하는 일은 실제로 일어나고 있습니다. 다만 이 선언이 성립하는 구간은 ‘만드는 단계’에 한정된다는 게 핵심입니다.
초기 결과물을 소수로 빨리 뽑는 것과, 그 결과물을 몇 년간 안정적으로 유지·보수하는 것은 전혀 다른 문제입니다. 에이전트 생성 코드가 쌓일수록 ‘아무도 깊이 이해하지 못하는 코드’가 늘고, 품질 편차와 책임 소재가 함께 커집니다. 그래서 6개월~2년 관점에서 바뀌는 건 ‘개발자가 필요 없어진다’가 아니라 요구 역량의 이동입니다. 한 줄씩 짜는 능력의 몸값은 내려가고, 요구사항을 명확히 정의하는 능력, 에이전트에 맡길 작업과 사람이 반드시 지킬 작업(보안 로직·결제·데이터 정합성)의 경계를 긋는 판단, 그리고 생성물을 검증·통합하는 능력의 몸값이 올라갑니다. 경영진의 문장을 곧장 ‘인원 감축 근거’로 직역하면 유지보수 인력을 먼저 줄였다가 몇 달 뒤 기술부채로 되갚는 함정에 빠지기 쉽습니다. 감축 신호가 아니라 재배치 신호로 읽는 편이 정확합니다.
기업·공공으로 번지는 에이전트: 오라클과 행안부가 보여주는 확산 구조
변화는 개발 도구를 넘어 업무 플랫폼으로 넘어갑니다. 오라클은 자사 기업용 애플리케이션(퓨전)에서 에이전트를 만들고 운영하는 ‘스튜디오’를 고도화하며, 재무·인사·공급망 같은 실제 프로세스에 에이전트를 붙이는 쪽으로 갑니다. 공공에서는 행정안전부가 ‘AI 정부 실험실’ 성격의 환경에서 현업 공무원이 직접 업무용 에이전트를 조립하는 시범을 가동했습니다. 두 사례의 공통점은 에이전트를 ‘개발자 전용 도구’가 아니라 ‘업무를 아는 현업이 스스로 만드는 도구’로 위치시킨다는 점입니다. 노코드·로우코드 흐름이 에이전트와 만나는 지점이 바로 여기입니다.
현업이 직접 만든다는 건 진입장벽을 낮추지만, 동시에 검증받지 않은 자동화가 조직 곳곳에 늘어난다는 뜻이기도 합니다. 그래서 확산 속도만큼 관리 설계가 따라붙어야 합니다. 실무 체크포인트는 (1) 에이전트가 건드리는 데이터의 민감도 등급 구분 — 사내 공개 문서와 개인정보·인사 데이터는 접근 권한부터 분리, (2) 잘못된 자동 처리에 대한 사람의 승인 게이트와 롤백 장치 — 특히 대외 발송·지출·삭제처럼 되돌리기 어려운 동작은 사람 승인 필수, (3) 만든 사람이 부서를 옮기거나 퇴직한 뒤의 유지보수 주체를 문서로 지정하는 것입니다. 흔한 오해가 ‘현업이 만드니 IT 부서 부담이 준다’는 것인데, 실제로는 거버넌스·보안 검토 부담이 초기에 오히려 늘어납니다. 공공·기업 환경에서 성패를 가르는 기준은 ‘누가 만들었는가’가 아니라 ‘누가 책임지고 유지하는가’입니다.
자주 묻는 질문
AI 코딩 도구를 쓰면 코드 리뷰를 안 해도 되나요?
아닙니다. AI 생성 코드는 검증이 끝난 결과가 아니라 초안입니다. 문법은 그럴듯해도 프로젝트 규칙과 어긋나거나 조용한 버그·보안 취약점을 품을 수 있어 테스트와 사람 리뷰 책임은 그대로 남습니다. 오히려 생성량이 늘수록 리뷰가 병목이자 품질의 마지막 방어선이 됩니다.
클로드 코드 같은 도구를 쓰는데 보안 솔루션이 자꾸 차단합니다. 어떻게 해야 하나요?
에이전트는 짧은 시간에 대량으로 파일을 읽고 명령을 연쇄 실행해 이상행위 탐지의 임계값을 넘기 쉽습니다. 솔루션을 끄는 건 진짜 위협까지 방치하는 최악수입니다. 먼저 도구의 실행 계정·접근 폴더·외부 통신 대상을 문서화하고, 프로젝트 경로와 필수 도메인만 최소 권한으로 허용한 뒤, 2~4주 오탐 로그를 모아 규칙을 점진적으로 조정하세요.
AI 코딩 에이전트가 발전하면 개발자 채용이 줄어드나요?
반복 작업 수요는 줄지만 ‘개발자 불필요’로 직결되진 않습니다. 바뀌는 건 요구 역량입니다. 코드 작성보다 요구사항 정의, 에이전트에 맡길 범위와 사람이 지킬 경계 설정, 생성물의 검증·통합·유지보수 비중이 커집니다. 만드는 단계는 빨라져도 유지보수와 책임은 여전히 사람의 몫이라, 오히려 이 역량을 갖춘 사람의 가치가 올라갑니다.
현업 담당자가 직접 AI 에이전트를 만드는 방식은 안전한가요?
진입장벽을 낮추는 장점 뒤에 검증받지 않은 자동화가 늘어난다는 리스크가 있습니다. 접근 데이터의 민감도 등급 분리, 되돌리기 어려운 동작(발송·지출·삭제)에 대한 승인·롤백 장치, 만든 사람이 떠난 뒤의 유지보수 주체 지정이 함께 갖춰져야 안전합니다. ‘누가 만들었나’보다 ‘누가 책임지고 유지하나’가 핵심 기준입니다.