‘AX(AI 전환)’가 올해 국내 기업의 경영 구호가 됐다. SK온은 업무마다 AI 에이전트를 붙이는 ‘AX 드라이브’를 내걸었고, 국방과학연구소(ADD·Agency for Defense Development)는 자체 AI ‘애디’로 이른바 ‘바이브 코딩(vibe coding)’을 시도한다고 밝혔다. 콘텐츠 플랫폼 리디(RIDI)는 개발 조직 바깥의 직원까지 코딩 에이전트로 업무를 바꾸고 있다고 알렸다. 방향은 한쪽이다. 문제는 기대와 현실이 같은 속도로 움직이지 않는다는 점이다. ‘누구나 코드 없이 소프트웨어를 만든다’는 기대와, 같은 시기 업계에서 나온 ‘반도체가 있어도 전기가 없어 AI를 못 돌린다’는 경고는 둘 다 사실이다. 이 간극을 구분하지 못한 채 도구부터 사면, AX는 예산만 태우고 지표는 그대로인 프로젝트로 끝난다. 이 글은 여러 사례에서 사실과 수치만 추려, 이 변화가 ‘어떤 조건에서 의미가 있고 어디서 멈추는지’를 순서대로 정리한다.
‘바이브 코딩’이 자동완성과 결정적으로 다른 한 가지
‘바이브 코딩’은 사람이 자연어로 원하는 결과를 설명하면 AI가 코드를 생성·수정하는 방식을 뜻한다. 몇 년 전의 자동완성 도구와 겹쳐 보이지만, 결정적 차이는 ‘작업 단위’다. 과거 도구가 커서 위치의 한 줄~한 함수를 제안하는 데 그쳤다면, 코딩 에이전트는 하나의 요구사항을 받아 여러 파일을 오가며 고치고, 테스트를 실행하고, 실패하면 원인을 되짚어 다시 시도하는 반복 루프까지 스스로 돈다. 사람이 ‘문장 하나’를 받던 자리에서 ‘작업 하나’를 넘겨받는 셈이다. 앤트로픽(Anthropic)이 “코딩을 몰라도 업무 전문가라면 개발자 못지않게 AI를 쓸 수 있다”고 말한 근거도 여기 있다. 문법 지식보다 ‘문제를 정확히 정의하고 결과가 맞는지 판별하는 힘’이 더 희소해졌다는 뜻이다.
바로 이 지점에서 첫 오해가 생긴다. ‘코딩을 몰라도 된다’가 ‘검증을 몰라도 된다’로 번역되는 순간이다. 비개발자가 만든 자동화는 데모에서 잘 도는 것처럼 보여도, 예외 입력·권한 범위·데이터 정합성에서 조용히 틀린다. 화면상 성공했는데 뒤에서 중복 정산이 쌓이는 식이다. 그래서 실행 전 최소 세 가지를 끊고 가야 한다. 첫째, 결과물이 건드리는 데이터가 개인정보·사내 기밀인지부터 분류한다. 둘째, ‘한 번 돌아간 것’과 ‘매일 안정적으로 도는 것’은 다른 문제이므로, 정상·비정상·경계값 입력을 섞어 반복 테스트한 뒤에야 자동 실행에 올린다. 셋째, 사람이 안 봐도 되는 작업(사내 문서 초안, 로그 정리)과 반드시 사람이 봐야 하는 작업(고객 발송, 정산, 대외 공개)을 미리 갈라 적용 범위를 못 박는다. 이 선을 긋지 않으면 생산성 도구가 사고의 진원지로 바뀐다.
SK온·ADD·리디, 같은 ‘AX’라도 온도가 다른 이유
같은 ‘AX’라는 단어를 써도 세 곳의 목표와 전제는 다르다. SK온의 ‘업무마다 에이전트를 붙인다’는 방향은 특정 부서 실험이 아니라 프로세스 전반에 AI를 끼워 넣겠다는 전사 전략에 가깝다. 리디의 ‘비개발자도 코딩 에이전트로’는 개발 조직 바깥의 기획·운영 직군까지 도구를 확산시키는 데 무게가 실려 있다. ADD는 성격이 또 다르다. 국방 연구라는 보안 민감도가 극단적으로 높은 영역에서 외부 클라우드 모델 대신 ‘자체 AI(애디)’를 쓴다는 점이 핵심으로, 데이터를 밖으로 내보낼 수 없는 조직이 왜 자체 모델·폐쇄망을 감수하는지를 보여준다. 즉 하나는 ‘범위’, 하나는 ‘사용자층’, 하나는 ‘데이터 통제권’이 관전 포인트다.
이 세 갈래를 겹쳐 보면 남의 사례를 우리 기준으로 바꿀 축이 잡힌다. 축은 둘이다. (1) ‘누가 쓰는가’—개발자 중심이면 도구 성능이 성패를 가르지만, 전 직원 확산형이면 도구보다 사용 규칙과 감사 로그 설계가 먼저다. 누가 무엇을 실행했는지 추적이 안 되면 확산은 곧 통제 불능이 된다. (2) ‘데이터 민감도’—높을수록 자체 구축(온프레미스·전용 모델) 비용을 감수해야 하고, 이때 초기 구축비는 SaaS 구독형보다 몇 배로 벌어질 수 있다. 여기서 흔한 함정이 ‘남들이 하니 우리도’식 조급증이다. 파일럿에서 반복 업무 한두 개의 처리 시간을 눈에 띄게(예: 30% 이상) 줄인 근거도 없이 전사 확대부터 하면, 얻는 것은 성과가 아니라 혼란의 확산이다. 성숙도를 건너뛴 확산은 되돌리는 비용이 도입 비용보다 크다.
진짜 병목은 GPU가 아니라 ‘전기’와 ‘청구서’다
AI 도입을 논할 때 시선은 대개 모델 성능과 소프트웨어에 쏠린다. 그러나 산업 차원에서 부상한 제약은 훨씬 물리적이다. ‘반도체가 있어도 전기가 없어 AI를 못 판다’는 지적처럼, 병목은 칩 공급을 넘어 전력과 데이터센터 용량으로 옮겨가고 있다. 대규모 학습·추론은 전력을 상시 대량으로 먹고, 이는 곧 클라우드 사용료와 데이터센터 입지·전력 계약이라는 새 경쟁 변수로 되돌아온다. 그래서 기업 경쟁력을 ‘누가 더 좋은 모델을 쓰느냐’가 아니라 ‘누가 안정적인 연산 자원과 전력을 확보하느냐’로 봐야 한다는 관점이 힘을 얻는다. 인프라가 전략의 종속변수가 아니라 독립변수가 됐다는 얘기다.
이 거대 담론은 실무자에게 청구서로 내려오는 순간 아주 구체적이 된다. 핵심은 에이전트의 비용 구조가 챗봇과 다르다는 점이다. 챗봇은 질문 1회에 응답 1회지만, 에이전트는 요청 하나를 처리하려 탐색→수정→테스트→재시도로 모델을 여러 번 호출한다. 같은 작업이라도 호출 횟수가 몇 배로 뛰니 종량 과금에서 비용이 선형적으로 늘지 않는다. 그래서 두 가지를 미리 건다. (1) 도입 전 ‘월 예상 요청 건수 × 요청당 평균 호출 횟수’로 비용을 시뮬레이션하고, 파일럿 첫 달 실제 청구서와 대조해 오차를 잡는다. 초기 추정이 실제의 절반에 그치는 일이 흔하니, 첫 추정치를 그대로 예산에 넣지 않는다. (2) 무제한 자동 실행 대신 사용량 상한과 경보를 설정한다. ‘구독료만 내면 끝’이라는 오해가 위험한 이유가 여기 있다. 종량 구조에서는 잘못 짜인 에이전트 하나가 무한 재시도로 하루 만에 예산을 태울 수 있다.
도구를 깔아도 성과가 없는 이유, 그리고 6개월~2년의 진짜 변화
생산성 도구를 들이고도 지표가 그대로인 데는 반복되는 이유가 있다. 도구는 깔았는데 ‘어떤 업무를, 어떤 기준으로, 누가 책임지고’ 바꾸는지가 비어 있는 경우다. AI 에이전트는 규칙이 분명하고 자주 반복되는 일에서 강하고, 맥락이 매번 달라지고 판단 책임이 무거운 일에서는 오히려 사람의 검토 부담을 키운다. 그래서 첫 대상은 ‘자주 반복되고, 규칙이 명확하며, 틀려도 즉시 되돌릴 수 있는’ 업무여야 한다. 사내 문서 요약, 반복 데이터 정리, 코드 초안 생성이 이 조건에 맞고, 인사 평가·법적 판단·대외 발표처럼 실패 비용이 큰 영역은 최종 결정이 아니라 보조 자료를 만드는 수준으로 묶어 둔다. 순서를 뒤집으면 가장 위험한 곳에서 가장 먼저 사고가 난다.
6개월~2년 관점의 진짜 변화는 도구가 아니라 ‘직무의 무게중심’에서 온다. 개발자는 코드를 한 줄씩 쓰는 사람에서, 에이전트가 만든 결과를 검증·설계·통합하고 책임지는 사람으로 이동할 가능성이 크다. 비개발 직군에서도 평가 기준이 ‘도구를 얼마나 다루느냐’에서 ‘문제를 얼마나 정확히 정의하고 결과를 얼마나 잘 의심하느냐’로 옮겨간다. 반대편의 과장도 함께 경계해야 한다. ‘전 직원이 개발자가 된다’는 서사는 접근성이 낮아졌다는 사실은 맞게 설명하지만, 검증·보안·유지보수 책임까지 사라진다는 뜻은 아니다. 오히려 만드는 사람이 늘수록 검토하고 책임지는 역할의 값이 오른다. 결론은 단순하다. 이 기술이 좋으냐 나쁘냐를 묻기 전에, 우리 조직의 어떤 업무가 ‘반복적이고, 검증 가능하고, 실패 비용이 낮은가’를 먼저 지도로 그리는 일이 먼저다. 그 지도 없이 도구부터 사면, AX는 끝내 구호로 남는다.
자주 묻는 질문
비개발자가 코딩 에이전트로 만든 결과물, 검토 없이 실무에 바로 써도 되나요?
작업의 실패 비용에 따라 다릅니다. 사내 문서 초안이나 반복 데이터 정리처럼 틀려도 즉시 되돌릴 수 있는 일은 바로 활용해도 무리가 적습니다. 반면 고객 발송, 정산, 개인정보를 다루는 자동화는 반드시 사람이 최종 검토하고, 자동 실행에 올리기 전 정상·비정상·경계값 입력을 섞어 반복 테스트해야 합니다. ‘코딩을 몰라도 된다’가 ‘검증을 안 해도 된다’는 뜻은 아니라는 점이 핵심입니다.
AI 에이전트 도입 비용은 월 구독료만 보면 되나요?
아닙니다. 에이전트는 요청 하나를 처리하려 탐색→수정→테스트→재시도로 모델을 여러 번 호출하기 때문에, 챗봇과 달리 종량 과금에서 비용이 급증할 수 있습니다. 도입 전 ‘월 요청 건수 × 요청당 평균 호출 횟수’로 시뮬레이션하고, 파일럿 첫 달 실제 청구서와 대조해 초기 추정 오차를 잡으세요. 사용량 상한과 경보 설정은 선택이 아니라 필수입니다.
‘반도체가 있어도 전기가 없어 AI를 못 판다’는 말은 무슨 뜻인가요?
AI 인프라의 병목이 칩 공급을 넘어 전력·데이터센터 용량으로 옮겨가고 있다는 의미입니다. 대규모 학습·추론은 전력을 상시 대량으로 소모하고, 이는 클라우드 비용 상승과 연산 자원 확보 경쟁으로 이어집니다. 그래서 기업 경쟁력을 모델 성능만이 아니라 안정적 연산·전력 확보 능력까지 포함해 봐야 한다는 관점입니다.
전사 AX를 서둘러 확대하면 왜 위험한가요?
성숙도를 건너뛴 확산은 성과보다 혼란을 키우기 때문입니다. 파일럿에서 반복 업무 한두 개의 처리 시간을 뚜렷하게(예: 30% 이상) 줄인 근거가 없다면, 사용 규칙·감사 로그가 부실한 상태로 사고 범위만 넓히게 됩니다. 되돌리는 비용이 도입 비용보다 클 수 있으므로, 검증된 업무부터 단계적으로 넓히는 편이 안전합니다.