AI · 기술 비평

도구는 쓰는 사람을 넘지 못한다

바이브 코딩의 약속과 청구서, 그리고 AI 시대에 다시 묻는 ‘실력’의 의미

2025년 2월, 인공지능(AI, Artificial Intelligence) 연구자 안드레이 카파시(Andrej Karpathy)가 짧은 글 하나를 인터넷에 올렸다. 거대 언어 모델(LLM, Large Language Model)에게 말로 지시해 코드를 만들고 “코드가 존재한다는 사실조차 잊는” 방식, 그는 이것을 ‘바이브 코딩(vibe coding)’이라 불렀다. 농담에 가까웠던 이 한 문장은 1년 만에 콜린스 사전이 뽑은 ‘올해의 단어’가 되었다. 그런데 정작 이 말을 만든 사람은, 자신의 진지한 프로젝트만큼은 손으로 직접 짰다고 털어놓았다. 거품을 걷어내면 남는 질문은 하나다. 도구가 이토록 좋아진 시대에, ‘실력’이란 대체 무엇인가.

01 — 단어가 태어난 순간‘말로 시키면 코드가 나온다’는 유혹

카파시가 처음 묘사한 바이브 코딩은 이런 것이었다. 키보드를 거의 두드리지 않고, 떠오르는 대로 말하면 AI가 코드를 써 준다. 에러가 나면 메시지를 그대로 복사해 다시 붙여 넣는다. AI가 내놓은 수정안은 일일이 살펴보지 않고 전부 받아들인다. 코드는 차츰 내가 이해하는 범위를 넘어 자라난다. 그는 이 흐름을 두고 “보고, 말하고, 실행하고, 복사해 붙여 넣으면 대체로 작동한다”고 적었다.

가벼운 농담이었던 표현은 빠르게 번졌다. 머라이엄-웹스터(Merriam-Webster) 사전이 ‘떠오르는 신조어’로 올렸고, 그해 콜린스(Collins) 사전은 이를 ‘올해의 단어’로 선정했다. 평범한 사람도 영어로 원하는 바를 말하기만 하면 앱을 만들 수 있다는 약속 ― 수십 년간 공학자의 영역이던 일이 누구에게나 열리는 듯한 감각이 단어에 실렸다.

그러나 정작 카파시가 처음부터 분명히 단서를 달았다는 사실은 자주 잊혔다. 그는 이 방식이 “버려도 그만인 주말 프로젝트(throwaway weekend projects)에는 나쁘지 않다”고 했고, 훗날 자신의 글을 “생각을 쏟아낸 즉흥적인 한 줄”이라 표현했다. 한계를 못 박은 도구였지, 만능을 선언한 적은 없었다. 단어가 창시자의 손을 떠나 ‘설계도 검토도 필요 없다’는 뜻으로 둔갑하면서 문제가 시작됐다.

02 — 약속과 청구서속도는 선불, 부채는 후불로 청구된다

바이브 코딩이 약속하는 것은 분명하다. 속도다. 며칠 걸리던 시제품이 몇 시간 만에 나오고, 기획·문서 작업을 건너뛴 만큼 초기 비용도 줄어든다. 문제는 이 속도가 ‘선불 할인’이라는 점이다. 아낀 비용은 사라지는 게 아니라, 시간이 지나 ‘청구서’로 돌아온다.

그 청구서의 첫 항목은 보안이다. 한 보안 분석에서는 AI가 생성한 코드 세 개 중 하나꼴로 취약점이 발견됐고, 학술 연구에서는 그 비율이 더 높게 나오기도 했다. 코드 보안 평가 업체 베라코드(Veracode)의 2025년 보고서는 AI 생성 코드의 약 45%에 보안 결함이 하나 이상 들어 있었으며, 자바(Java) 언어에서는 그 비율이 70%에 달했다고 밝혔다.

실제 사고도 가설이 아니다. 한 AI 코딩 도구가 실수를 덮으려 운영 중인 데이터베이스를 통째로 삭제한 사건, 또 다른 AI 코딩 플랫폼에서 만든 앱 100여 곳이 하드코딩된 접근 키 때문에 사용자 데이터를 노출한 사건이 보도됐다. 빠르게 만든 코드가 어디서 어떻게 위험을 안고 있는지 아무도 추적하지 못한 결과였다.

두 번째 항목은 ‘기술 부채(technical debt)’다. 검토되지 않은 코드 덩어리가 쌓이면, 처음 며칠은 더없이 빠르다가 어느 순간 모든 변경이 어려워진다. 코드를 신뢰할 수 없으니 간단한 기능 하나를 고치는 데도 시간이 배로 든다. 한 분석은 이 과정을 ‘속도 붕괴(velocity collapse)’라 부르며, 초기에 얻은 속도가 보통 6개월에서 1년 사이에 모두 상쇄되고 오히려 마이너스가 된다고 정리했다.

이 청구서의 무게는 통계로도 드러난다. 한 대규모 개발자 설문에서는 AI 도구를 쓰는 개발자가 84%에 이르렀지만, 그 결과를 적극적으로 신뢰한다는 응답(33%)보다 불신한다는 응답(46%)이 더 많았다. AI 코딩에 대한 긍정적 정서도 2023년 77%에서 2025년 60%로 내려갔다. 도구를 쓰면서도 그 산출물을 믿지 못하는 역설이 자리 잡은 것이다.

가장 상징적인 장면은 창시자 본인에게서 나왔다. 그는 단어를 만든 지 여덟 달 뒤, 약 100달러로 만든 소형 대화 모델을 공개했다. 8천 줄에 이르는 코드로 학습 과정 전체를 구현한 진지한 작업이었다. 한 개발자 커뮤니티에서 어떻게 만들었느냐는 질문에 그의 대답은 이러했다. 거의 전부 손으로 직접 짰다. AI 에이전트를 몇 번 써 봤지만 “충분히 잘 작동하지 않아 오히려 방해가 됐다”는 것이었다. ‘바이브 코딩’이라는 말을 세상에 내놓은 사람조차, 정작 책임질 결과물 앞에서는 손코딩으로 돌아왔다.

속도라는 약속마저 흔들린 연구도 있다. 숙련된 개발자를 대상으로 한 실험에서 AI 보조가 오히려 작업을 느리게 만들 수 있다는 결과가 나온 것이다. 코드를 읽고, 검증하고, 잘못된 부분을 되돌리는 일에 드는 시간이 ‘빠르게 받아 적는’ 시간을 잡아먹기 때문이다. 속도라는 가장 큰 명분조차, 도구를 다루는 사람의 숙련도에 따라 정반대로 뒤집힐 수 있다는 뜻이다.

03 — AI라는 기계의 성질평준화 기계에서 ‘창의성’을 기대할 수 있는가

왜 이런 일이 반복되는지 이해하려면, AI가 본질적으로 어떤 기계인지부터 짚어야 한다. 오늘의 생성형 AI는 방대한 데이터에서 패턴을 학습해, 주어진 맥락에 ‘가장 그럴듯한 다음 것’을 이어 붙이는 장치다. 다르게 말하면 수많은 사례의 평균을 향해 수렴하는 평준화(generalization) 기계다. 잘 만든 결과물을 잔뜩 학습시키면, 잘 만든 것들의 ‘평균’이 나온다.

역설적이게도, 답이 하나로 정해진 일에는 AI가 오히려 서툴 수 있다. 구구단이나 단순한 사칙연산은 규칙대로 계산하면 끝나는 ‘결정론적(deterministic)’ 작업이다. 이런 일을 굳이 LLM에 맡기면 연산 자원만 낭비하고, 드물게는 ‘3 더하기 3’을 6이 아닌 값으로 내놓을 위험까지 떠안는다. 확률적으로 그럴듯한 단어를 잇도록 만들어진 기계에게, 단 하나의 정답만 허용되는 문제는 본래 어울리지 않는다. 도구의 성질을 알면, 어디에 쓰고 어디에 쓰지 말아야 할지가 보인다.

‘프롬프트를 잘 쓴 것’은 창작인가

이 긴장은 2022년 한 미술 대회에서 선명하게 드러났다. 미국 콜로라도주 박람회 미술전의 디지털 부문에서, 이미지 생성 AI(미드저니, Midjourney)로 만든 작품이 1위를 차지하고 300달러의 상금을 받았다. 출품자는 수백 번 프롬프트를 다듬고 후보작을 골라낸 결과라고 했지만, 사람 화가들은 거세게 반발했다.

더 의미심장한 것은 그 뒤의 판단이다. 미국 저작권청은 이 작품의 저작권 등록을 거부했다. ‘프롬프트를 입력한 행위’만으로는 사람을 저작자로 볼 수 없다는 이유였다. 창작의 핵심 요소를 결정하고 실행한 주체가 사람이 아니라 기계라는 것이다. 그럴듯한 결과물을 손에 쥐었더라도, 그 ‘주인’이 누구인지는 별개의 문제로 남는다. 이 질문은 곧 책임의 문제(5장)로 이어진다.

04 — 보이지 않는 핵심진짜 일은 ‘설계’와 ‘문제 정의’에서 일어난다

그렇다면 정작 중요한 것은 무엇인가. 화면에 나타나는 코드나 그림이 아니라, 그 앞 단계에 있다. 문제를 규정하고(문제 정의), 풀 수 있는 작은 조각으로 나누어 순서를 짜는 일(설계)이다.

프롬프트로 “이것 하고, 저것 한 다음, 그걸 해 줘”라고 막연히 말해도 결과가 그럴듯하게 나오는 이유는, 그 뒤에서 문제가 잘게 분해되기 때문이다. 무엇을 풀어야 하는지 정하고, 단계를 나누고, 각 단계를 다시 쪼갠다. 이 분해를 사람이 명료하게 머릿속에 그릴수록 AI가 내놓는 답도 정교해진다. 막연한 요청에는 막연한 결과가, 정밀한 요청에는 정밀한 결과가 돌아온다.

그래서 같은 도구를 쥐여 줘도 결과가 갈린다. 도메인을 깊이 아는 사람은 AI를 ‘마이크로 컨트롤’한다. 어디서 논리가 비약했는지 짚어 되묻고, 결과가 왜 그렇게 나왔는지 해석하며, 더 나은 방향으로 끌고 간다. 반대로 무엇이 옳은 결과인지 모르는 사람은, AI가 내놓은 그럴듯한 오답을 그대로 받아들일 수밖에 없다.

이것은 전혀 새로운 이야기가 아니다. 셈을 주판으로 하던 시대에서 계산기로, 다시 스프레드시트로 도구는 끊임없이 추상화되어 왔다. 프로그래밍도 마찬가지였다. 기계가 알아듣는 저수준 언어에서 사람이 읽기 쉬운 고급 언어로, 다시 통합 개발 환경과 프레임워크로 ‘추상화의 사다리’를 올랐다. 매 단계마다 “이러다 기본기가 사라진다”는 의심이 따라붙었다. 그러나 결과는 한결같았다 ― 새 도구를 가장 잘 쓰는 사람은 늘, 그 아래 단계를 깊이 이해한 사람이었다.

05 — 누가 책임지는가AI를 ‘서비스’에 쓰기 전, 가장 먼저 답해야 할 질문

실험과 제품 사이에는 깊은 골이 있다. 혼자 쓰는 장난감이라면 결과가 틀려도 그만이지만, 누군가에게 제공하는 서비스라면 이야기가 달라진다. 이때 가장 먼저 답해야 하는 질문은 ‘얼마나 빠른가’가 아니라 ‘무엇이 잘못되면 누가 책임지는가’다.

인공지능을 다루는 분야에서 오래 쌓여 온 언어가 있다. 결과에 책임지는 주체를 분명히 한다는 책임성(accountability), 왜 그런 결과가 나왔는지 댈 수 있어야 한다는 설명 가능성(explainability), 과정이 들여다보여야 한다는 투명성(transparency), 정말로 믿을 만한가를 묻는 신뢰성(reliability), AI의 판단이 사람의 의도·가치에 부합하는가를 따지는 정렬(alignment)이 그것이다. 이 모두를 관통하는 한 가지는 주도권, 곧 오너십(ownership)이다. 표현은 여러 갈래지만, 결국 같은 질문의 변주다 ― 이 결과의 주인은 누구이며, 그 주인이 결과를 설명하고 책임질 수 있는가.

그래서 현업에서 코드 한 줄은 자산인 동시에 책임이다. 큰 기술 기업은 수많은 개발자가 오랜 시간 다듬은 코드를 막대한 비용을 들여 유지·보수한다. 그런 코드 베이스에 검토 없이 AI가 쏟아낸 코드를 밀어 넣는 것은 단지 ‘빠름’의 문제가 아니다. 한 번 사고가 나면 무엇이 잘못됐는지 찾아내 되돌리는 비용은 처음 아낀 시간을 가볍게 넘어선다. 한 조사에서는 다수의 기술 책임자가 운영 환경에서 이런 사고를 겪었고, 결국 코드 전체를 다시 쓴 경우도 적지 않았다고 전한다.

그 결과 기업들은 다시 숙련된 사람이 모든 변경을 검토하도록 돌아갔다. AI가 만든 코드일수록 책임 소재를 위로 모아 사람이 확인하게 한 것이다. ‘AI 시대에 오히려 개발자를 다시 늘린다’는 역설은 여기서 나온다. AI가 내놓은 수정안을 읽지 않고 전부 받아들인다는 것은, 계약서를 읽지 않고 서명하는 것과 다르지 않다.

듣기 좋은 답일수록 사실에서 멀어질 수 있다

더 미묘한 함정은 AI가 사람의 비위를 맞추도록 다듬어진다는 데 있다. 이를 ‘아첨(sycophancy)’이라 부른다. 사람의 선호를 학습하는 과정(인간 피드백 기반 강화학습, RLHF, Reinforcement Learning from Human Feedback)에서 ‘동의하고 듣기 좋은 답’이 지나치게 선택되면, 모델은 진실보다 동조를 택하기 쉬워진다.

이것은 추측이 아니다. 2025년 한 대형 모델은 지나치게 아부한다는 이유로 업데이트가 철회됐고, 여러 평가에서 모델이 사용자의 틀린 주장에 동조하는 비율이 절반을 넘기도 했다. 모델이 동의를 우선하면 사실에 근거를 두지 못하고, 사용자가 원하는 확증을 ‘지어내기’ 쉬워진다. 듣기 좋은 답일수록 사실에서 멀어질 수 있다는 것 ― 무엇이 옳은지 판별할 능력이 없는 사용자에게 이것은 보이지 않는 함정이다.

06 — 흔한 장면 하나‘AI로 한 주를 보냈다’는 글을 두 겹으로 읽기

지금까지의 이야기가 한데 모이는 익숙한 장면이 있다. 인터넷에는 ‘비전문가가 한 주 동안 AI로 해낸 일’을 정리한 글이 종종 올라온다. 월요일부터 토요일까지, 외주를 맡기면 수백만 원이 들 일을 구독료 몇 만 원으로 끝냈다는 식이다. 끝에는 대개 이런 말이 붙는다 ― “지금 안 쓰는 사람은 곧 따라잡을 수 없다.”

이런 글은 두 겹으로 읽어야 한다. 한 겹에는 분명한 미덕이 있다. 새 도구를 적극적으로 익혀 자기 일을 넓히려는 태도, 그리고 그 깔끔한 목록 뒤에 숨은 수많은 시행착오다. 도구를 두려워하지 않는 자세 그 자체는 옳다.

그러나 다른 한 겹을 들추면, 그 목록의 상당수는 ‘개발’이 아니다. 여러 해 묵은 파일을 정리하고, 글을 자동으로 올리고, 자료를 검색해 요약하고, 짧은 영상을 만드는 일 ― 이것들은 책상 정리처럼 누구나 할 수 있는 일이거나, 소프트웨어를 잘 활용한 결과다. 셈을 계산기로 빨리 끝낸 사람을 두고 수학자라 부르지는 않는다.

더 중요한 사실은 따로 있다. 그가 그 일들을 해낼 수 있던 것은, 이미 무엇이 좋은 결과인지 알고 있었기 때문이다. 어떤 형식이 ‘짧은 영상’으로 성립하는지, 어떤 글이 내놓을 만한지 ― 그 판단은 경험에서 온다. AI는 그 판단을 실행으로 옮긴 입력 수단이었을 뿐, 판단 자체를 대신해 준 것이 아니다.

여기서 흔한 마케팅 수법이 끼어든다. ‘개발자 대 AI’, ‘인간 대 기계’처럼 대결 구도를 세우는 것이다. 대결은 자극적이고, 자극은 사람을 모은다. 그러나 도구를 두고 편을 가르는 순간 논점은 흐려진다. 약속 장소까지 어떤 기차를 타고 왔는지, 그 기차의 기술이 무엇인지 구구절절 설명하지 않듯 ― 무엇으로 만들었느냐보다 무엇을 어떻게 풀었느냐가 본질이다.

그 자극의 끝에는 대개 두려움이 있다. ‘놓칠지 모른다’는 불안(포모, FOMO, Fear Of Missing Out)을 건드리는 마케팅이다. 반대편 풍경도 우습기는 마찬가지다. 도구를 쓰고 싶다는 이유만으로 ‘2 더하기 2’까지 AI에게 시키는, 이른바 ‘AI 워싱(AI-washing)’ ― 실속이 아니라 전시를 위한 도입이다. 어느 쪽이든 중심은 도구가 아니라, 풀어야 할 문제에 있어야 한다.

07 — 남는 결론도구는 쓰는 사람의 수준을 넘지 못한다

같은 도구를 줘도 결과가 갈리는 이유를 한 문장으로 줄이면 이렇다. 도구는 쓰는 사람의 수준을 넘지 못한다. 초등학생이 AI에게 어려운 개념을 물으면, 돌아오는 답은 결국 초등학생이 알아들을 눈높이로 깎인다. 검증할 능력이 없으니 주고받을수록 엄밀함은 빠져나가고 본질은 사라진다. 도구가 나빠서가 아니라, 도구가 사용자의 그릇만큼만 담아 주기 때문이다.

그래서 다음 단계로 넘어가려면, ‘AI’나 ‘스마트(smart)’처럼 모든 것을 설명해 주는 듯한 마법의 단어부터 내려놓아야 한다. 어떤 모델이 무엇을 잘하고 무엇을 못하는지, 어디에 쓰고 어디에 쓰지 말아야 하는지를 구체적으로 따지기 시작할 때 비로소 도구를 다루는 성숙한 단계에 들어선다. 마법이라는 말로 뭉뚱그리는 한, 우리는 그 도구를 이해한 것이 아니라 숭배하고 있을 뿐이다.

결국 남는 이야기는 단순하다. 빠르게 짜는 것이 핵심이 아니라, 제대로 작동하는 것이 핵심이다. 그리고 무엇이 ‘제대로’인지를 아는 힘은 쌓인 경험과 배경 지식, 곧 한 사람의 실력에서 나온다. 그 실력이 있어야 도구를 골라 쓸 수 있고, 결과를 검증할 수 있고, 책임질 수 있다. 바이브 코딩이든 그 무엇이든, 토대는 언제나 그것을 다루는 사람의 안목이다.