포항제철소가 개발자가 아닌 현장 직원을 대상으로 ‘바이브코딩(vibe coding)’을 도입하고, 한국제약바이오협회가 관련 교육을 열고, ESG·장애인 직업재활 분야에서까지 활용이 논의된다. 블록체인·핀테크 콘퍼런스(메타콘 2026)에서는 ‘돈이 될까, 어떤 툴을 써야 하나’라는 실무 질문이 정면으로 다뤄졌다. 여러 매체 보도를 교차해 보면 이건 특정 IT 기업만의 유행이 아니라 제조·제약·복지로 번지는 흐름이다. 그런데 사례를 백 개 나열해도 정작 ‘우리 회사가 도입해야 하나’라는 질문에는 답이 안 나온다. 이 글은 사례 대신 판단 기준을 준다 — 무엇이고, 왜 지금이며, 어디까지 되고, 도입 전 무엇을 따져야 하는지를 순서대로 정리한다.
바이브코딩이 뭐길래 현장 직원까지 코드를 만드나
바이브코딩은 ‘이런 기능이 필요하다’를 자연어로 설명하면 AI가 코드를 생성·수정하는 방식이다. 2025년 초 AI 연구자 안드레이 카파시(Andrej Karpathy)가 트위터에서 쓴 표현이 출발점으로, 요지는 ‘코드를 읽지 않고 결과만 보고 고쳐 나간다’는 개발 태도의 전환이다. 기존 방식이 문법·라이브러리·환경설정이라는 3중 진입장벽을 요구했다면, 바이브코딩은 그 장벽을 통째로 AI에 위임한다. 노코드/로우코드와 헷갈리기 쉬운데, 노코드가 ‘정해진 블록을 조립’하는 방식이라 화면 밖 요구는 못 만드는 반면, 바이브코딩은 실제 코드를 생성하므로 표현 범위는 넓지만 그만큼 검증 부담도 코드 수준으로 커진다.
확산 배경은 감성이 아니라 수급 불균형이다. 전문 개발 인력은 늘 병목인데, 현장에는 ‘엑셀 반복 작업 30분, 사내 데이터 조회 한 화면’이 아쉬운 실무자가 압도적으로 많다. 이런 자잘한 요구는 개발팀 우선순위에서 늘 뒤로 밀려 몇 주씩 대기하거나 아예 방치된다. 포항제철소 사례의 핵심은 ‘AI가 코딩을 대신했다’가 아니라, 그동안 코드로 만들어지지 못하고 사람 손으로 반복되던 업무의 제작 권한을 현장으로 옮겼다는 점이다. 여기서 흔한 오해 하나. 바이브코딩은 개발자를 없애는 기술이 아니라 ‘지금까지 만들어지지 못한 수요’를 새로 소화하는 저변 확대에 가깝다. 수십만 줄 규모의 기간계·제어 시스템은 여전히 전문 개발의 영역이고, 이 경계를 흐리는 마케팅 문구가 오판의 첫 단추다.
‘말만 하면 다 된다’와 실제 되는 범위를 가르는 선
‘말만 하면 GMP(우수의약품제조관리기준) 대응 시스템까지 만든다’류의 표현은 신호와 결과를 뒤섞은 것이다. 제약바이오협회가 교육을 연 것은 규제 산업도 이 기술에 관심을 둔다는 ‘신호’일 뿐, 규제 검증을 통과하는 ‘결과물’이 자동으로 나온다는 뜻이 아니다. GMP·의료기기·금융처럼 감사(audit)가 따르는 영역에서는 ‘누가, 어떤 근거로, 어떻게 검증했는지’의 문서화와 책임 소재가 코드 생성 속도보다 몇 배 더 중요하다. AI는 ‘동작하는 코드’는 빨리 만들지만 ‘검증 이력’은 만들어 주지 못한다.
적용 범위를 데이터·책임 두 축으로 나누면 판단이 단순해진다. 사내에서만 쓰고, 오류가 나도 되돌릴 수 있고, 규제 대상이 아닌 업무 — 데이터 집계 도구, 반복 자동화, 프로토타입 — 는 바이브코딩의 효율이 가장 크게 나타나는 ‘초록 영역’이다. 반대로 외부 고객 데이터·결제·인증·개인정보가 얽히거나 장애 시 안전·규제 리스크가 큰 업무는 ‘빨강 영역’으로, AI가 초안을 아무리 빨리 뽑아도 사람의 검토·테스트·보안 점검이 반드시 개입해야 한다. 실무에서 바로 쓸 3문 판정법은 이렇다. (1) 이 도구가 다루는 데이터가 사외로 나가는가, (2) 오류가 났을 때 누가 책임지고 고칠 수 있는가, (3) 규제·감사 대상 업무인가. 셋 중 하나라도 ‘그렇다’면 바이브코딩은 ‘초안 보조’로만 쓰고 검증 절차를 별도 설계해야 한다. 이 선을 안 그으면, 빨리 만든 대가를 사고로 치르게 된다.
툴 3분류와 ‘돈이 될까’ — 구독료가 아니라 총비용을 봐라
메타콘 2026에서 나온 ‘어떤 툴, 돈이 될까’는 도입 검토 조직이 가장 먼저 부딪히는 벽이다. 도구는 크게 세 갈래다. ①코드 편집기에 통합돼 기존 개발 흐름을 돕는 유형(Cursor, GitHub Copilot 계열) — 이미 개발팀이 있는 조직의 생산성 향상용, ②대화만으로 웹앱·화면까지 생성하는 유형(Replit, Lovable, Bolt 계열) — 비개발자의 사내 도구·프로토타입 제작용, ③범용 대화형 AI에 직접 요청하는 방식 — 가장 저렴하지만 배포·연동은 사람이 붙여야 함. 조직에 개발자가 있으면 ①, 현장 실무자가 스스로 만들게 하려면 ②가 대체로 맞는다.
비용은 ‘월 구독료’만 보면 반드시 과소평가한다. 편집기 통합형은 대략 1인당 월 10~20달러(약 1만5천~3만 원)대, 생성형 도구도 유사한 구독대에서 시작하지만, 실제 지출은 여기서 끝나지 않는다. 사용량이 늘면 API 토큰이 별도 종량 과금되고 — 대량 작업 시 구독료를 웃도는 경우도 흔하다 — AI가 만든 코드를 리뷰·수정하는 사람의 시간, 잘못 나온 결과물을 걷어내는 재작업 비용, 보안 점검 인력까지 합쳐야 총소유비용(TCO)이 나온다. 자주 빠지는 함정은 ‘도구를 깔면 생산성이 오른다’는 기대다. 개발 생산성 도구가 성과로 안 이어지는 전형적 이유는 도구 부재가 아니라 리뷰·배포·유지보수 프로세스의 부재다. 실용적 판단 순서는 이렇다 — 반복 빈도가 높고 실패해도 피해가 작은 업무 하나를 골라 소규모로 4~8주 적용하고, 절감된 시간을 실제로 측정한 뒤, 그 수치가 구독료+검토 비용을 넘어설 때만 대상을 넓힌다. ‘느낌상 빨라졌다’가 아니라 시간 수치로 검증되기 전엔 확대하지 않는 게 핵심이다.
도입 전 반드시 점검할 3대 리스크 — 보안·품질·유지보수
바이브코딩의 구조적 맹점은 ‘만든 사람이 코드를 완전히 이해하지 못한 채 쓴다’는 데 있다. 여기서 세 가지 리스크가 파생된다. 첫째 보안 — AI 생성 코드에는 하드코딩된 비밀번호·키, 검증 없는 외부 입력 처리, 허술한 권한 체크가 섞이기 쉽고, 비전문가는 이를 ‘동작하니까 됐다’며 지나친다. 둘째 품질 — 데모에선 멀쩡하다가 예외 입력·대용량 데이터·동시 접속에서 무너지는 경우가 흔하다. 겉보기 동작과 견고함은 다른 문제다. 셋째 유지보수 — 만든 사람이 퇴사하거나 쓰던 도구가 바뀌면, 아무도 내부를 모르는 ‘블랙박스 코드’가 조직에 쌓인다. 개인이 만든 도구가 조직 전체로 퍼지면 이 부채는 곱절이 된다.
그래서 도입 조직에는 최소한의 안전장치가 필요하고, 이건 도구를 사는 순간이 아니라 첫 결과물이 나오기 전에 갖춰야 한다. 체크리스트로 정리하면 ▲AI 생성 코드도 사람이 리뷰·승인하는 절차를 둘 것 ▲사내에서 만든 도구의 목록·용도·담당자를 대장으로 관리해 ‘섀도 IT'(관리 밖에서 자라는 도구)를 막을 것 ▲민감 데이터 접근 권한과 외부 전송을 기술적으로 차단할 것 ▲누가 만들었고 무엇을 근거로 검증했는지 기록을 남길 것. ESG·직업재활처럼 사회적 책임이 강조되는 영역에서 바이브코딩이 주목받는 이유도 결국 ‘더 많은 사람이 도구를 만들 수 있다’는 접근성 확장인데, 접근성이 넓어질수록 통제와 기록의 무게도 같이 커진다. 6개월~2년 관점에서 보면 이건 사라질 유행이라기보다 ‘누가 코드를 만들 수 있는가’의 경계를 넓히는 흐름이고, 승부를 가르는 건 도구 자체가 아니라 늘어난 생산물을 검증·관리하는 조직의 역량이다.
자주 묻는 질문
바이브코딩을 하면 개발자가 필요 없어지나요?
아닙니다. 사내 자동화·간단한 도구 제작 같은 저난도 영역은 비전문가도 만들 수 있게 되지만, 보안·규제·대규모 시스템은 여전히 전문 개발자의 설계와 검토가 필요합니다. 오히려 AI가 쏟아내는 코드를 검증·통제하고 블랙박스화를 막는 역할의 비중이 커집니다. ‘적게 짜는 개발자’가 아니라 ‘더 많이 검토하는 개발자’로 무게중심이 이동한다고 보는 편이 정확합니다.
코딩을 전혀 몰라도 바이브코딩을 시작할 수 있나요?
간단한 업무 자동화나 프로토타입 수준은 문법 지식 없이 대화형 도구(Replit·Lovable 계열 등)로 시작할 수 있습니다. 다만 결과물이 왜 그렇게 동작하는지 최소한의 이해가 없으면 오류가 났을 때 원인 파악과 보안 점검이 사실상 불가능합니다. 기본 개념 교육과 사람의 리뷰 절차를 함께 갖춰야 ‘만들 수는 있지만 고칠 수는 없는’ 상황을 피할 수 있습니다.
포항제철소나 제약 업계가 도입했다는데 우리 회사도 바로 도입해도 되나요?
업무 성격부터 구분해야 합니다. 사외로 데이터가 나가지 않고 실패해도 되돌릴 수 있는 반복 업무라면, 하나만 골라 4~8주 소규모로 적용하고 절감 시간을 측정해 보는 것을 권합니다. 반면 개인정보·결제·규제 대상 업무라면 검증·감사 절차를 먼저 설계한 뒤 초안 보조 용도로만 제한해야 합니다. 남이 도입했다는 사실보다 ‘우리 업무가 초록 영역인가 빨강 영역인가’가 판단 기준입니다.
바이브코딩 도구 비용은 실제로 얼마나 드나요?
편집기 통합형은 대체로 1인당 월 10~20달러(약 1만5천~3만 원)대에서 시작하지만, 이건 시작 금액일 뿐입니다. 사용량이 많아지면 API 토큰이 종량 과금돼 구독료를 넘기기도 하고, 여기에 생성 코드 검토·수정 인건비와 보안 점검 비용까지 더해야 실제 총소유비용(TCO)이 나옵니다. 구독료만 보고 판단하면 실비용을 크게 과소평가하게 됩니다.