IT 뉴스에서 ‘에이전트’가 부쩍 잦아졌다. 마이크로소프트는 비주얼 스튜디오 코드(Visual Studio Code)에 ‘에이전트 스킬(agent skills)’을 붙여 코파일럿(Copilot)의 작업 범위를 넓혔고, 텐센트(Tencent)는 코딩·에이전트 성능을 앞세운 차세대 모델을 공개했다. 국내에서는 NHN이 자연어 한 줄로 데이터를 분석하는 에이전트를 실험 중이고, 롯데 신동빈 회장이 직접 ‘바이브 코딩(vibe coding)’으로 에이전트를 만들었다는 소식까지 나왔다. 회사도 맥락도 제각각이지만 관통하는 축은 하나다. 코드를 ‘작성하는’ 도구에서 목표를 주면 스스로 여러 단계를 ‘수행하는’ 도구로 개발 환경의 무게중심이 옮겨가고 있다는 것.
이 글은 흩어진 사례를 하나의 지도로 묶는다. 무엇이 실제로 달라졌는지, 어떤 작업에 쓸 만하고 어디서 무너지는지, 도입을 검토한다면 무엇부터 계산해야 하는지를 ‘기술 자랑’이 아니라 판단 기준으로 정리했다. 결론부터 말하면, 문턱이 낮아진 것은 ‘만드는 일’이고 새로 생긴 문턱은 ‘검증하고 책임지는 일’이다.
‘자동완성’과 ‘에이전트’는 무엇이 다른가
2년 전 AI 코딩 도구의 대표 이미지는 ‘똑똑한 자동완성’이었다. 개발자가 함수 이름을 치면 뒷부분을 제안하는 방식으로, 어디에 어떻게 쓸지 판단과 조립은 사람 몫이었다. 지금의 ‘에이전트’는 층위가 다르다. VS 코드의 에이전트 스킬은 특정 작업 절차나 사내 도구 사용법을 재사용 가능한 ‘스킬’ 단위로 정의해 두면, AI가 상황에 맞는 스킬을 골라 여러 단계를 이어 처리하는 구조다. ‘한 줄 제안’이 아니라 ‘작업 위임’에 가깝다.
차이는 세 축으로 갈린다. 첫째는 범위다. 기존 도구가 한 줄~한 함수를 다뤘다면 에이전트는 파일 여러 개를 넘나들며 수정→실행→오류 확인→재수정을 반복한다. 둘째는 주도권이다. 사람이 매 단계를 지시하던 방식에서, 목표만 주고 중간 판단을 맡기는 방식으로 이동한다. 셋째는 연결성이다. 스킬·플러그인으로 사내 규칙이나 내부 API를 물리면 범용 모델이 우리 조직 맥락에서 움직인다. 여기서 초보자가 가장 크게 오해하는 지점이 ‘에이전트=완전 자동’이다. 실제로는 목표를 잘게 쪼개 주고 결과를 검수하는 사람이 여전히 필요하다. 자동화된 것은 ‘실행’이지 ‘판단’과 ‘책임’이 아니다. 오히려 단계가 길어질수록 중간에 잘못된 가정을 그대로 밀고 나가는 ‘자신만만한 오류’가 늘어, 검수 부담은 커지는 쪽에 가깝다.
바이브 코딩: 되는 영역과 무너지는 영역
‘바이브 코딩’은 정교한 문법 대신 ‘이런 걸 만들고 싶다’는 자연어 요청과 대화로 소프트웨어를 조립해 가는 방식을 부르는 말이다. 한 CIO 매체는 이를 두고 ‘개발팀에 전부 맡기던 시대가 끝나고 현업이 자급자족하는 흐름’이라 표현했고, 국내에선 대기업 총수가 직접 에이전트를 만든 장면까지 나왔다. 코딩을 배우지 않은 사람도 아이디어를 곧장 시제품으로 옮길 수 있게 됐다는 신호다.
관건은 기대와 현실을 ‘작업의 실패 비용’으로 나누는 것이다. 바이브 코딩이 잘 맞는 쪽은 사내 조회 화면, 반복 업무 자동화, 회의용 프로토타입처럼 틀려도 되돌릴 수 있고 요구사항이 단순한 작업이다. 반대로 결제·개인정보·대규모 트래픽·법적 책임이 걸린 서비스는 여전히 전문 개발과 정식 검증 영역이다. 현업이 만든 결과물을 넘기기 전 확인할 체크포인트는 순서가 있다. (1) 이 앱이 어떤 사내 데이터에 접근하는지 ‘권한 범위’부터 확인한다 — 화면에 안 보여도 뒤에서 전체 테이블을 읽고 있을 수 있다. (2) 보이는 화면이 아니라 ‘틀린 값을 자신 있게 내놓는’ 오류를 실제 데이터로 교차 검증한다. (3) 만든 사람이 부서를 옮기면 누가 고칠지 정한다. 문서 없이 쌓이는 ‘유령 앱’이 조직에 가장 흔히 남는 부채다. 정리하면, 만드는 문턱이 낮아진 만큼 ‘누가 검증하고 누가 관리하는가’라는 문턱이 새로 생겼고, 이 비용을 계산에 넣지 않으면 생산성은 착시가 된다.
모델 경쟁의 평가축이 바뀌었다: 텐센트·NHN이 말해주는 것
에이전트가 갑자기 쓸 만해진 배경엔 밑바탕 모델의 성능 향상이 있다. 텐센트가 코딩·에이전트 성능을 전면에 내세워 차세대 모델을 공개한 것은, 이 영역이 빅테크의 핵심 경쟁 무대가 됐다는 신호다. 눈여겨볼 것은 마케팅 문구가 아니라 ‘무엇을 잘한다고 주장하는가’다. 과거 경쟁이 ‘얼마나 그럴듯한 문장을 쓰나’였다면, 지금 축은 ‘여러 단계 작업을 끝까지 완수하나’, ‘도구를 정확한 인자로 호출하나’로 옮겨갔다. 이 평가축의 이동은 곧 실무 판단 기준의 이동이기도 하다 — 벤치마크 점수보다 ‘내 워크플로의 10단계 중 몇 단계에서 멈추나’를 직접 재보는 편이 정확하다.
NHN의 실험은 이 변화가 개발자만의 이야기가 아님을 보여준다. ‘코딩을 몰라도 자연어 한 줄로 데이터 분석’이라는 방향은, SQL이나 분석 도구를 모르는 현업도 질문만으로 결과를 얻게 하겠다는 것이다. 결과적으로 직무 역량이 재배치된다. ‘도구를 조작하는 능력’의 값어치는 내려가고, 좋은 질문을 설계하고 나온 결과를 의심·검증하는 능력의 값어치는 올라간다. 실무자가 붙잡을 기준은 하나다. AI가 뽑아 준 숫자는 ‘초안’이지 ‘결론’이 아니다. 데이터 분석은 특히 위험한데, 매끈한 표와 그래프가 오답을 그럴듯하게 포장하기 때문이다. 최소한 원본 대비 표본 몇 건을 손으로 대조하는 습관, 그리고 ‘이 숫자의 분모가 무엇인가’를 되묻는 절차가 없으면, 자동화는 잘못된 의사결정을 더 빠르게 퍼뜨리는 장치가 된다.
도입 전 반드시 따질 5가지 기준
도구가 좋아 보인다고 성과가 따라오진 않는다. 도구만 깔고 성과가 없는 조직이 흔한데, 원인은 대개 도구가 아니라 ‘연결’과 ‘검증’ 단계가 비어 있어서다. 검토한다면 아래 다섯 가지를 계산에 넣어야 한다.
| 기준 | 핵심 질문 | 흔한 함정 |
|---|---|---|
| 비용 | ‘월 얼마’가 아니라 ‘작업 한 건당 얼마’인가 | 에이전트는 한 작업에 수~수십 회 모델을 반복 호출해 자동완성보다 단위 비용이 훨씬 커짐 |
| 보안 | 접근 권한을 최소 범위로 좁혔나 | 편의를 위해 넓은 권한을 주면 권한 설계가 곧 보안 구멍이 됨 |
| 품질 | 누가 검토·승인하고 배포하나 | AI가 짠 코드의 결함 책임은 결국 배포한 조직·담당자에게 있음 |
| 유지보수 | 만든 뒤 누가 관리하나 | 문서·이해도 없는 자산이 빠르게 쌓여 방치됨 |
| 적합성 | 실패 비용이 낮은 작업부터 시작하나 | 첫 대상으로 핵심 서비스를 골라 리스크를 키움 |
이 다섯을 관통하는 원칙은 순서다. 실패 비용이 낮고 반복적인 작업부터 좁게 시작해, 권한·검증·책임 체계를 갖춘 다음 범위를 넓혀라. 예컨대 사내 문서 검색 봇이나 로그 요약처럼 틀려도 되돌릴 수 있는 일에서 6~8주 정도 운영하며 오류율과 실제 단위 비용을 측정한 뒤, 그 데이터를 근거로 다음 대상을 정하는 식이다. 6개월~2년 관점에서 이 흐름이 사라질 가능성은 낮지만, 혜택은 ‘도구를 산 조직’이 아니라 ‘검증 체계를 함께 만든 조직’에 돌아간다. 기술이 바꾸는 것은 일의 속도이고, 성과를 가르는 것은 그 속도를 검증이 따라잡느냐다.
자주 묻는 질문
바이브 코딩을 하면 개발자가 필요 없어지나요?
아닙니다. 사내 조회 화면·프로토타입처럼 실패 비용이 낮은 영역에서는 현업이 직접 만드는 폭이 넓어지지만, 결제·개인정보·대규모 트래픽처럼 안정성과 법적 책임이 걸린 서비스는 여전히 전문 개발과 정식 검증이 필요합니다. 개발자의 무게중심이 ‘코드 타이핑’에서 ‘설계·검증·리스크 관리’로 이동한다고 보는 편이 정확합니다.
AI 코딩 에이전트와 기존 코드 자동완성은 뭐가 다른가요?
자동완성은 사람이 치는 코드의 다음 한 줄을 제안하는 수준이라 판단과 조립은 사람 몫입니다. 에이전트는 목표를 주면 파일 여러 개를 넘나들며 수정→실행→오류 확인→재수정까지 여러 단계를 스스로 이어 시도합니다. ‘제안’과 ‘작업 위임’의 차이로 이해하면 됩니다. 단계가 길어질수록 사람의 검수 부담은 오히려 커집니다.
코딩을 몰라도 자연어로 데이터 분석이 정말 가능한가요?
NHN 등 여러 기업이 ‘자연어 질문으로 분석 결과를 얻는’ 방향을 실험 중이라 어느 정도는 가능해지고 있습니다. 다만 결과물은 ‘결론’이 아니라 ‘초안’입니다. 매끈한 표와 숫자가 오답을 그럴듯하게 포장하기 쉬우므로, 원본 대비 표본 몇 건을 직접 대조하고 ‘이 숫자의 분모가 무엇인가’를 되묻는 절차 없이 의사결정에 쓰면 위험합니다.
회사에 AI 에이전트를 도입할 때 가장 먼저 봐야 할 것은?
권한 범위, 단위 비용, 검증 절차입니다. 에이전트가 어떤 사내 데이터·시스템에 접근하는지 최소 권한으로 설계하고, 한 작업에 모델을 여러 번 반복 호출하는 특성상 ‘월 요금’이 아니라 ‘작업 한 건당 비용’으로 계산하며, 누가 결과를 검토·승인하고 유지보수하는지를 처음부터 정해야 합니다. 첫 대상은 실패 비용이 낮은 반복 업무로 좁게 잡는 것이 안전합니다.