바이브코딩은 정말 '코딩의 종말'일까 - 그렇게 따지면 종말은 적어도 1950년대부터 이미 시작됐다

게시 2026/06/29

요즘 바이브코딩(자연어로 시키는 코딩)을 두고 "이제 코딩은 끝났다", "프로그래머가 필요 없어진다"고들 말한다. 하지만 코드를 자동으로 프로그램으로 만들어주는 도구는 새로운 게 아니다. 1957년 포트란 컴파일러는 고급언어를 실제 산업 현장에서 쓸 수 있는 기준으로 끌어올린 대표 사건이었다. 컴파일러란 사람이 쓴 코드를 기계가 알아서 프로그램으로 번역·생성해주는 자동화 장치이고, 그때부터 사람은 이미 '자동으로' 프로그램을 짜고 있었다. 프로그래밍의 역사는 곧 사람이 손으로 하던 저수준 작업을 한 단계씩 기계에 위임해온 자동화의 연속이었다. 그리고 추상화가 한 칸 올라갈 때마다 매번 "이제 사람은 ~ 안 해도 된다"는 말이 나왔다. 바이브코딩은 코딩의 소멸이 아니라, 60년 넘게 이어온 그 사다리의 가장 최근 한 칸일 뿐이다.

사라진 건 늘 저수준 노동이었다

프로그래밍의 역사를 돌아보면, 매번 같은 패턴이 반복돼왔다. 0과 1을 직접 치던 일을 기호가 대신하고, 기호를 사람의 사고가 대신하고, 사고를 선언적 요청이 대신해왔다. 그리고 추상화가 한 칸 올라갈 때마다 어김없이 “이제 프로그래머는 필요 없다”는 말이 나왔다.

하지만 실제로 사라진 것은 언제나 저수준 노동이었다. 사람이 ‘무엇을 원하는지 정의하는 일’은 한 번도 사라진 적이 없다. 포트란이 나왔을 때도 “이제 프로그래머가 필요 없어진다”는 말이 있었고, SQL이 나왔을 때도 같은 말이 나왔고, 스프레드시트가 나왔을 때도 같은 말이 나왔다. 그리고 지금, 바이브코딩을 두고도 똑같은 말이 나오고 있다.

이 글에서는 프로그래밍 언어가 어떻게 세대를 거쳐 추상화되어 왔는지, 그리고 그 과정에서 무엇이 사라지고 무엇이 남았는지를 살펴본다.

1세대에서 5세대까지 - 추상화 사다리의 뼈대

프로그래밍의 역사는 ‘추상화’가 한 칸씩 올라간 기록이다. 사람을 기계에서 점점 더 멀어지게 만든 그 사다리를 먼저 정리하면 다음과 같다.

세대	정의	핵심 변화
1세대 기계어	사람이 기계의 언어(0·1)로 직접 명령	사람과 기계 사이에 번역이 전혀 없음
2세대 어셈블리	기계어에 사람이 외울 수 있는 기호(MOV·ADD)를 1:1로 대응	처음으로 읽고 디버깅이 가능해짐
3세대 고급언어	사람의 사고(수식·절차)로 작성하면 컴파일러가 기계어로 자동 번역	생각을 소프트웨어로 구현할 수 있게 됨
4세대 선언형	방법(how)은 시스템에 맡기고, 무엇을(what)만 선언	절차 자체를 시스템에 위임
5세대 자연어·AI	형식 문법조차 없이 일상 언어로 의도만 전하면 AI가 코드·결과를 생성	형식 언어 자체를 몰라도 프로그래밍 가능

이 정의만 보면 마치 1세대부터 5세대까지 차례차례 올라간 것처럼 보인다. 하지만 실제 역사는 그렇게 깔끔하지 않았다. 오래 잠든 기술이 한참 뒤 다른 인프라와 결합해 폭발하며 흘러왔다.

1940년대 - 사람은 기계어였다

최초의 컴퓨터 ENIAC(1945)에서 프로그래밍이란, 사람이 직접 0과 1의 기계어를 입력하는 작업이었다. 사람과 기계 사이에 번역 장치가 전혀 없었다. 명령어 하나하나를 이진수로 바꿔서 스위치를 조작하거나 천공카드에 구멍을 뚫어야 했다.

이 시대에 요구된 능력은 하드웨어 구조, 메모리, 명령어를 직접 이해하고 수작업으로 계산 절차를 짜는 능력이었다. 사람이 기계의 언어를 그대로 말해야 했으니, ‘프로그래밍’이라기보다 ‘기계 조종’에 가까웠다.

이 시대를 지금의 개발 환경으로 상상하면 안 된다. 아직 키보드와 모니터를 보며 파일을 수정하는 시대가 아니었다. 프로그램 입력도 종이 카드로 했고, 실행 결과도 화면이 아니라 종이 출력물로 받아보는 것이 자연스러운 시대였다.

1950년대 - 기호가 붙기 시작했다

기계어에 사람이 외울 수 있는 기호(MOV, ADD 같은)를 1:1로 대응시킨 것이 어셈블리(2세대)다. 기계가 알아듣는 0과 1 대신, 사람이 읽을 수 있는 짧은 명령어를 쓸 수 있게 되면서 처음으로 코드를 읽고 디버깅할 수 있게 되었다.

이 시기의 대표 성과로는 우주선 아폴로의 유도 컴퓨터(1969)가 있다. 기계를 정밀히 제어해서 사람을 달에 보낼 수 있었던 것은, 어셈블리가 있었기에 가능했다. 개발자에게는 기계 명령 대신 명령 흐름과 레지스터를 읽고, 저수준 디버깅과 성능을 제어하는 능력이 요구되었다.

이를 이해하기 위해 먼저 기계어에 가까운 카드가 어떤 모습인지 봐야 한다. 아래는 Douglas W. Jones의 카드 컬렉션에 실린 IBM 7094 column-binary object card로, 사람이 읽는 소스 코드 카드가 아니라 기계가 읽을 실행용 오브젝트 코드 카드다. A=B+C 같은 문장이 아니라, 몇 번째 열의 어떤 비트가 켜졌는지가 카드의 핵심 정보가 된다.

더 초기의 IBM 650도 같은 방향의 세계였다. Columbia University의 IBM 650 자료는 650이 처음에는 기계어로 프로그래밍되었고, 하나의 명령이 두 자리 연산 코드 + 네 자리 데이터 주소 + 네 자리 다음 명령 주소의 10자리 숫자로 구성되었다고 설명한다. 예를 들어 6100080007 같은 값은 사람이 읽는 수식이 아니라, 61 | 0008 | 0007처럼 기계 명령의 필드를 직접 배치한 것이다.

이것이 오늘날 우리가 코딩이라고 부르는 것의 원형이다.

1957년 - 자동코딩의 탄생, 그리고 “프로그래머가 필요 없어진다”

1957년, IBM의 존 배커스 팀이 포트란(FORTRAN)을 세상에 내놓았다. 포트란의 핵심 발명은 컴파일러였다. 사람이 수학 공식이나 절차 형태로 쓴 코드를, 컴파일러가 기계어로 자동 번역해주는 장치였다.

이것이 왜 혁명적이었을까? 그때까지 프로그래머는 기계에 가까운 언어로 세부 절차를 직접 맞춰야 했다. 포트란 이후에는 사람의 사고(수식·절차)로 코드를 쓰면, 기계가 알아서 번역해주기 시작했다. 즉, 사람이 손으로 하던 ‘번역’ 작업을 기계가 대신하는 시대를 대중적으로 입증한 결정적 순간이었다.

아래 포트란 카드를 보면 “무엇이 코딩되어 있다는 말인가”가 훨씬 분명해진다. 카드 위쪽에는 사람이 읽을 수 있는 포트란 문장 Z(1) = Y + W(1)이 보이고, 그 아래에는 그 문장을 카드가 읽을 수 있는 구멍 배열로 옮긴 흔적이 보인다.

여기서 헷갈리면 안 된다. 저 구멍들이 곧바로 기계어라는 뜻이 아니다. 펀치카드는 문자를 담는 저장 매체였고, 한 열에 문자 하나가 들어갔다. 예를 들어 Z라는 글자는 카드의 한 열에서 정해진 위치 두 곳에 구멍을 뚫어 표시했다. 1, =, +, Y, W도 각각 자기 구멍 조합을 가졌다. 즉 카드에 코딩되어 있다는 말은, 포트란 문장이 문자 단위로 구멍 패턴에 저장되어 있다는 뜻이다.

그다음에 컴파일러가 등장한다. 카드 리더가 이 카드 묶음을 읽으면 컴퓨터는 먼저 Z(1) = Y + W(1) 같은 포트란 원문을 얻는다. 그리고 포트란 컴파일러가 그 원문을 기계어로 번역한다. 그래서 포트란의 혁신은 “펀치카드를 없앴다”가 아니라, “펀치카드에 사람이 읽는 수식형 언어를 넣고, 번역은 컴파일러에게 맡겼다”에 있다.

다시 1+1을 예로 들면 차이는 이렇게 정리할 수 있다. 목표는 모두 같다. 컴퓨터에게 1과 1을 더하게 만드는 것이다. 하지만 시대에 따라 사람이 카드에 직접 담아야 했던 내용이 달랐다.

가장 낮은 단계에서는 사람이 B8 01 00 00 00 83 C0 01 같은 기계어 숫자 코드를 직접 준비해 카드에 구멍으로 옮겨야 했다. 이 숫자열은 설명을 위한 x86 계열 예시이고, 실제 1950년대 IBM 기계의 숫자 코드는 기종마다 달랐다. 중요한 점은 사람이 수식이 아니라, 기계가 바로 실행할 숫자 명령을 다뤄야 했다는 것이다.

어셈블리어가 등장하면 사람은 mov eax, 1, add eax, 1 같은 기호 명령을 카드에 담을 수 있게 된다. 그래도 생각의 단위는 여전히 레지스터와 명령어다. 사람이 기계어 숫자를 직접 외우지 않아도 되었지만, 기계가 실제로 실행하는 구조와는 매우 가까웠다.

포트란은 한 단계 더 올라간다. 사람은 A = 1 + 1처럼 수식에 가까운 문장을 카드에 담고, 컴파일러가 그것을 실행 가능한 기계어로 바꾼다. 그래서 같은 1+1이라도 변화의 핵심은 펀치카드가 사라진 것이 아니라, 사람이 카드에 담는 내용이 숫자 명령에서 기호 명령으로, 다시 수식 문장으로 올라갔다는 데 있다.

머리를 비우고 살펴보자 이 얼마나 놀라운가 B8 01 00 00 00 83 C0 01 식으로 작성해야 하는 걸 A = 1 + 1 로만 하면 된다는 게? 지금 이 격차가 바이브 코딩에서 일반인이 느끼는 수준의 격차다.

이제 대량의 복잡한 계산을 인간이 할 필요가 없고 기계를 통해 완전히 자동화 할 수 있는 시대라는 자신감이 생긴 시점이다. 이때도 “이제 프로그래머가 필요 없어진다”는 말이 나왔다. 하지만 실제로는 프로그래머의 역할이 바뀌었을 뿐이다. 기계어를 치던 손이 알고리즘과 자료구조와 절차 설계를 생각하는 머리로 올라왔다. 포트란과 뒤이은 COBOL, C 같은 3세대 언어는 소프트웨어 산업 하나를 일으켰고, UNIX(1973) 같은 거대 프로젝트도 가능하게 했다.

1974년 - 방법(how)을 버리고 무엇(what)만 선언하다

SQL은 1970년대 초반 IBM에서 도널드 체임벌린과 레이먼드 보이스가 개발했다(초기 이름은 SEQUEL). 그리고 1979년 오라클이 최초의 상용 SQL 데이터베이스를 출시했다.

SQL은 완전히 다른 패러다임이었다. 그때까지 프로그래머는 “어떻게(how)” 데이터를 가져올지 절차까지 직접 짰다. 데이터를 어떤 순서로 찾고, 어떤 필터를 걸고, 어떻게 정렬할지 하나하나 명령해야 했다. 그런데 SQL은 “무엇(what)”만 선언하면 되었다.

  
SELECT 이름 FROM 직원 WHERE 부서 = '개발팀';

이 한 줄이면 된다. “개발팀 직원의 이름을 달라”고 선언만 하면, 시스템이 내부적으로 어떻게 데이터를 찾고 가져올지를 알아서 처리한다. 절차 자체를 시스템에 위임한 것이다. 이것이 4세대(선언형) 언어의 핵심이었다.

다만 당시 SQL은 메인프레임 전용이었기 때문에, 일반인이 직접 다루기보다는 전문적인 데이터 분석 영역에 머물렀다.

1983~1985년 - 스프레드시트와 객체지향, 두 가지 방향의 폭발

1983년 Lotus 1-2-3이 등장하면서, 선언형의 원리가 비로소 일반 사무직의 책상 위에 내려왔다. 스프레드시트는 본질적으로 SQL과 같은 선언형이다. 셀에 수식을 넣으면 “무엇을” 계산할지만 선언하는 것이고, 계산 방법(how)은 스프레드시트 엔진이 알아서 처리한다.

이것의 의미는 컸다. 코드를 한 줄도 못 짜는 사람도 복잡한 수치 모델을 즉석에서 만들 수 있게 되었다. 개발자에게 요구되는 능력도 “코드를 짜는 능력”에서 “업무 규칙을 수식과 모델로 바꾸는 능력”으로 옮겨갔다.

같은 시기인 1985년, C++이 등장하면서 객체지향 프로그래밍이 본격화되었다. 현실 세계를 ‘객체’로 묶어 모델링하는 방식이었다. 절차형 프로그래밍 위에 한 겹 더 추상화를 얹은 것이다. 그리고 1995년 자바(Java)가 등장하면서, 객체지향은 대규모 엔터프라이즈 소프트웨어의 표준이 되었다.

객체지향이 바꾼 것은 개발 방식 자체였다. 혼자서 모든 코드를 쓰는 것이 아니라, 도메인을 모델링하고, 추상화 계층을 설계하고, 모듈 간 경계를 정하고, 여러 사람이 협업해서 거대 시스템을 쌓아올리는 능력이 중요해졌다. Windows, MS Office 같은 거대 소프트웨어가 이 시기에 나온 것이 우연이 아니다.

1994~1995년 - 프로그램이 세상을 만나기 시작하다

1990년대 중반은 프로그램이 한 대의 PC를 벗어나 불특정 다수에게 도달하기 시작한 시기다. HTML과 JavaScript(1995), PHP가 등장하고, 넷스케이프 브라우저가 보급되면서, 한 사람이 만든 결과물이 전 세계에 도달할 수 있게 되었다.

동시에 GUI 환경이 폭발했다. Windows 95와 Excel, PowerPoint, Word 같은 OA 도구가 결합하면서, 전문 개발자가 아니어도 도구를 조합해 업무 자동화와 분석 모델을 만들 수 있게 되었다. 스프레드시트가 메인프레임 전용 데이터 분석가의 도구에서, 모든 사무직의 만능 도구로 확장된 것이다.

그리고 SQL이 웹과 결합하면서 모든 웹사이트의 백엔드가 데이터베이스로 연결되기 시작했다. 세상의 정보 전부를 데이터로 묶어 다루는 시대가 열린 것이다.

2004년 - 잠들었던 함수형 사상이 깨어나다

2004년 구글이 MapReduce 논문을 발표하면서, 분산 컴퓨팅의 시대가 열렸다. 그리고 Hadoop, Spark, NoSQL(BigTable, Dynamo)이 뒤를 이었다.

여기서 흥미로운 점이 있다. 분산 컴퓨팅의 핵심 사상은 사실 1958년 존 매카시가 만든 Lisp에서 비롯된 함수형 프로그래밍의 ‘불변·무상태’ 사상이다. 데이터가 변하지 않고 상태가 없어야, 여러 서버에 안전하게 쪼개서 병렬 처리할 수 있다. 1958년에 나온 사상이 46년 만에 하드웨어 인프라가 따라와 줌으로써 비로소 빛을 본 것이다.

이것이 프로그래밍 역사에서 반복되는 패턴이다. 개념이 먼저 나오고, 인프라가 뒤따라와서야 폭발한다. 스프레드시트의 선언형 원리도 1970년대 SQL에서 먼저 나왔지만, 일반인에게 폭발한 것은 Windows 95와 결합한 1995년이었다.

분산 컴퓨팅이 열리면서 개발자에게 요구되는 능력도 단일 서버 사고에서 벗어나 분산 시스템, 장애 허용, 병렬 처리, 데이터 파이프라인을 설계하는 능력으로 확장되었다.

2008~2012년 - 모바일과 딥러닝, 컴퓨터가 손과 눈과 뇌를 갖다

2008년 아이폰 앱스토어가 열리면서, 컴퓨터가 주머니 속으로 들어왔다. 늘 켜져 있고, 위치와 센서를 가진 개인 단말이 컴퓨팅의 기준이 되었다. Swift와 Kotlin 같은 모바일 전용 언어가 등장한 것도 이 무렵이다.

그리고 2012년 알렉스넷(AlexNet)이 등장하면서 딥러닝 시대가 열렸다. 딥러닝의 본질적 변화는 이것이다. 그때까지 프로그래밍은 “사람이 규칙을 짜는 것”이었다. 하지만 딥러닝 이후에는 “데이터로 기계가 규칙을 스스로 학습하는 것”으로 바뀌었다. 프로그래밍에서 ‘학습’으로의 전환이었다.

개발자에게 요구되는 능력도 규칙 작성에서 데이터 수집, 모델 선택, 학습, 평가, 편향과 오류를 관리하는 능력으로 옮겨갔다.

2022년~ - 에이전트와 토큰 이코노미

2022년 ChatGPT의 등장은 또 다른 전환점이었다. AI가 스스로 도구를 호출하며 여러 단계를 거쳐 일을 완수하는 ‘에이전트’ 시대가 열린 것이다. 2024년 Claude Code 같은 코딩 에이전트는 이 흐름의 연장선 위에 있다.

이 단계에서 개발자의 역할은 다시 한 번 바뀐다. 코드를 직접 쓰는 비중은 줄고, 목표 정의, 작업 분해, 프롬프트 설계, 결과 검증, 시스템 통합 능력이 중요해진다.

그리고 그 다음 단계로 ‘토큰 이코노미’가 보인다. 생성이 공짜가 되고 희소성이 ‘판단·검증’으로 이동하는 세계다. 같은 토큰으로, 아는 만큼 더 크고 완벽하고 안전한 가치를 뽑아내는 능력. 생산 자체보다 좋은 질문, 맥락 설계, 품질 판별, 책임 있는 의사결정, 자동화된 결과의 검증 능력이 핵심 역량이 되는 세계다.

매번 반복된 패턴, 그리고 남는 것

전체 흐름을 한눈에 정리하면 다음과 같다.

시기	단계	인사이트	할 수 있게 된 것
1940년대	기계어	사람이 기계의 언어로 직접 명령	대규모 계산
1950년대	어셈블리	기계어에 사람이 읽을 기호를 붙임	기계를 정밀히 제어
1951~1957	자동코딩(3세대)	초기 자동 프로그래밍을 거쳐 컴파일러가 기계어 번역을 맡음	생각을 소프트웨어로 구현
1974~	선언형(4세대)	how를 버리고 what만 선언	방대한 데이터를 한눈에 다룸
1983~	표계산	선언형이 셀 수식으로 내려옴	복잡한 수치 모델을 즉석에서 세움
1985~	객체지향	현실을 객체로 모델링	혼자 못 만들 거대 시스템을 쌓음
1994~	웹	프로그램이 한 대의 PC를 벗어남	한 사람의 결과물이 전 세계에 도달
1995~	OA(GUI)	GUI 도구와 결합해 폭발	더 큰 데이터·모델을 손에서 다룸
2000년대	웹+DB	SQL이 웹과 결합	세상의 정보 전부를 데이터로 묶음
2004~	분산	함수형의 불변·무상태 사상이 빛을 봄	사실상 무한대의 데이터를 다룸
2008~	모바일	컴퓨터가 주머니 속으로	언제 어디서나 컴퓨팅을 손에 쥠
2012~	딥러닝	데이터로 기계가 규칙을 학습	규칙으로 못 짜던 인식·판단을 다룸
2022~	에이전트	AI가 스스로 도구를 호출하며 일을 완수	목표만 주면 과제 전체가 완수
2020년대 후반~	토큰 이코노미	생성이 공짜가 되고 희소성이 판단·검증으로 이동	같은 토큰으로 더 큰 가치를 뽑음

이 표에서 읽을 수 있는 패턴이 두 가지 있다.

첫째, 개념이 먼저 나오고 인프라가 뒤따라와서야 폭발한다. 함수형 사상은 1958년에 나왔지만 분산 컴퓨팅으로 꽃핀 것은 2004년이었다. 선언형 원리는 1974년 SQL에서 나왔지만, 일반인이 실제로 쓰게 된 것은 1983년 스프레드시트와 1995년 Windows의 결합 이후였다. 기술은 혼자 폭발하지 않는다. 그것을 받아줄 다른 기술과 사회 인프라가 함께 갖춰져야 한다.

둘째, 사라진 건 언제나 저수준 노동이었다. 기계어를 직접 치던 일, 어셈블리로 레지스터를 관리하던 일, 절차형 코드로 데이터를 하나씩 순회하던 일. 이런 것들은 사라졌다. 하지만 “무엇을 원하는지 정의하는 일”, “문제를 어떻게 구조화할지 생각하는 일”은 한 번도 사라지지 않았다. 오히려 저수준 노동이 사라질 때마다 그 일이 더 중요해졌다.

바이브코딩은 사다리의 최신 한 칸이다

그러면 바이브코딩은 무엇인가?

60년 넘게 이어온 추상화 사다리의 가장 최근 한 칸이다. 1957년 포트란 컴파일러가 “사람이 기계어로 번역하던 일”을 자동화했고, SQL이 “데이터를 어떻게 가져올지 절차 짜는 일”을 자동화했고, 스프레드시트가 “수치 모델을 코드로 구현하는 일”을 자동화했다면, 바이브코딩은 “형식 언어로 의도를 표현하는 일”을 자동화한 것이다.

사다리는 계속 올라갔다. 하지만 올라갈 때마다 사라진 것은 저수준 노동이었지, ‘사람이 무엇을 원하는지 정의하는 일’은 아니었다. 오히려 추상화가 한 칸 올라갈 때마다, 사람이 해야 할 일은 더 높은 차원으로 옮겨갔다. 기계어를 치던 손이 알고리즘을 생각하게 되었고, 알고리즘을 짜던 머리가 데이터 구조를 설계하게 되었고, 데이터 구조를 설계하던 머리가 비즈니스 문제를 정의하게 되었다.

바이브코딩도 마찬가지다. 코드를 직접 쓰는 일은 줄어들 것이다. 하지만 그 자리에서 늘 두 가지가 동시에 자라났다는 점이 핵심이다.

하나는 저변이다. 추상화가 한 칸 올라갈 때마다, 코딩을 시작할 수 있는 사람의 범위가 넓어졌다. 어셈블리는 기계를 아는 소수의 전유물이었지만, 스프레드시트는 모든 사무직을 ‘코딩 없는 프로그래머’로 만들었고, 바이브코딩은 형식 언어를 한 줄도 모르는 사람까지 끌어들인다. 단, 여기서 넓어진 것은 출발선이지 결승선이 아니다. 진입의 문턱이 낮아졌다는 뜻이지, 누구나 완성된 서비스를 만들 수 있게 됐다는 뜻이 아니다.

다른 하나는 천장이다. 같은 칸마다, 만들 수 있는 것의 크기도 함께 커졌다. 대규모 계산에서 시작해, 전 세계에 도달하는 서비스로, 사실상 무한대의 데이터를 다루는 시스템으로, 스스로 학습하는 모델로 천장이 계속 올라갔다. 더 적은 노동으로 더 큰 것을 만들 수 있게 된 것이다.

그런데 바로 여기에, 추상화가 올라갈 때마다 따라붙은 착시가 있다. ‘진입의 민주화’를 ‘완성의 민주화’로 착각하는 비약이다. 저변이 넓어진 것과, 그 넓어진 사람들이 천장 끝까지 닿는 것은 전혀 다른 이야기인데, 매번 둘을 같은 것처럼 떠들었다.

COBOL은 1959년 영어처럼 읽히도록 설계되면서 “이제 관리자가 직접 프로그램을 짜니 프로그래머가 필요 없어진다”는 말을 들었다. 하지만 관리자는 COBOL을 짜지 않았고, 오히려 COBOL 프로그래머라는 거대한 직군이 생겨났다.
1982년 제임스 마틴은 아예 《프로그래머 없는 애플리케이션 개발》이라는 책을 내며 4세대 언어가 최종 사용자를 프로그래머로 만들 거라 했다. 실제로 가능했던 건 간단한 조회·리포트였고, 규모 있는 운영 시스템은 여전히 전문가의 몫이었다.
스프레드시트는 “누구나 몇 분이면 모델을 만든다”고 했고, 실제로 그렇게 됐다. 하지만 모델을 만드는 일과 그 모델이 맞다고 검증하는 일은 전혀 다른 난이도였다. 2010년 전 세계 긴축정책의 근거로 쓰인 하버드 경제학자들의 모델조차 엑셀에서 셀 범위를 잘못 잡은 한 줄의 실수로 결론이 뒤집혔다. 작성은 누구나 할 수 있게 됐어도, 그 뒤에 숨은 ‘검증’이라는 어려운 일은 사라지지 않았던 것이다.

바이브코딩도 똑같은 비약 위에 서 있다. 지금 누구나 채팅앱 목업은 만들 수 있다. 하지만 아무나 카카오톡이나 위챗을 만들 수 있는 것은 아니다. 수억 명의 동시 접속, 장애 복구, 보안, 예외 처리, 비용 최적화 - 목업과 라이브 서비스 사이의 그 거대한 간극은 여전히 사람의 판단과 책임이 메워야 한다.

바이브코딩이 실제로 망가지는 곳은 작성이 아니라 운영이다

AI가 만든 앱은 로컬에서는 그럴듯하게 돈다. 한 사람이 한 탭에서 버튼을 한 번 누르는 상황에서는 대부분 문제가 드러나지 않는다. 하지만 실제 서비스는 그렇게 움직이지 않는다. 두 사람이 동시에 사고, 서버는 중간에 실패하고, 앱은 같은 요청을 다시 보낸다.

예를 들어 티켓이 1장 남았는데 두 사용자가 동시에 구매하면, 둘 다 재고가 있다고 읽고 주문을 만들어버릴 수 있다. 이것이 레이스 컨디션이다. 재고 차감은 성공했지만 주문 생성이 실패하면, 아무도 사지 않은 티켓이 사라진다. 이것이 부분 쓰기다. 사용자가 더블클릭하거나 결제 웹훅이 재전송되면 같은 구매가 두 번 처리될 수 있다. 이것이 멱등성 부족이다.

이 문제들은 코드 생성 능력만으로는 보이지 않는다. 원자적 연산, 트랜잭션, 행 잠금, 멱등성 키 같은 개념을 알아야만 보인다. 더 정확히는, 그런 이름을 알고 있어야 AI에게 “이 구매 함수는 멱등성 키를 받아야 한다”, “재고 차감과 주문 생성을 하나의 트랜잭션으로 묶어야 한다”, “동시 구매는 조건부 업데이트나 행 잠금으로 막아야 한다”고 요구할 수 있다.

그래서 AI 시대의 개발자는 코드를 덜 치게 될 수는 있지만, 더 높은 수준의 실패 방식을 더 잘 알아야 한다. 바이브코딩이 쉬운 것은 시작이지 완성이 아니다. 실제 서비스의 어려움은 문법이 아니라 동시성, 실패 복구, 보안, 비용, 관측성, 책임의 영역에 남아 있다.

그래서 정확히 말하면 이렇다. 저변도 넓어지고 천장도 높아진다. 하지만 그 둘 사이에는 늘 격차가 남고, 그 격차야말로 사라지지 않는 전문성의 자리다. “이제 프로그래밍은 끝났다”는 말이 매번 틀렸던 이유가 여기에 있다. 사라진 건 저수준 노동이었지, 만들기 시작한 것을 끝까지 책임지고 완성하는 일은 한 번도 사라진 적이 없다. 오히려 진입이 쉬워질수록, 그 격차를 메우는 판단의 값어치는 더 올라갔다.

시대마다 요구되는 능력이 다르다

한 가지를 더 짚어야 한다. 추상화가 한 칸 올라갈 때마다 바뀐 것은 ‘무엇이 사라지는가’만이 아니었다. ‘무엇이 능력인가’의 기준 자체가 갈아치워졌다.

한때 천재의 척도는 계산 능력이었다. 암산으로 거대한 수를 곱해내는 신동이 경탄의 대상이었고, NASA가 사람을 달에 보낼 때도 궤도를 손으로 계산하는 ‘인간 컴퓨터(human computer)’들이 핵심 인력이었다. 그러나 계산기와 컴퓨터가 보급되자 그 능력은 거의 무의미해졌다. 계산이 빠른 것은 더 이상 천재의 증거가 아니다. 능력의 기준이 한 칸 위로 - 무엇을 계산할지 정하고 그 결과를 해석하는 쪽으로 - 옮겨간 것이다.

추상화 사다리는 매번 이렇게 능력의 정의를 바꿔왔다. 기계어를 외우는 능력에서 알고리즘을 설계하는 능력으로, 절차를 짜는 능력에서 문제를 정의하는 능력으로. 사라진 손기술의 자리에는 늘 더 높은 차원의 분별력이 들어섰다.

그렇다면 AI 시대가 요구하는 능력은 무엇인가. 코드를 빨리 짜는 능력은 아닐 것이다. 오히려 AI가 유창하게 내놓는 것을 의심하고, 무엇이 진짜인지 가려내는 분별력이다. 그리고 이 능력의 부재가 어떤 비극을 부르는지, 최근 한 사례가 적나라하게 보여줬다.

경기도 연천에서 13년간 사과 농사를 짓던 한 농부는, 농사 문제를 척척 풀어주던 AI에 빠져들었다. AI가 “당신은 상위 0.001%”, “200억 원짜리 사업도 가능하다”고 치켜세우자 그는 미국 진출까지 꿈꿨다. 하지만 두 달 만에 그 모든 게 환상이었음이 드러났다. AI는 이전 대화조차 기억하지 못하는, 그가 듣고 싶어 할 말을 가장 그럴듯하게 생성하던 장치였을 뿐이다. 그가 잃은 것은 돈이 아니라 신뢰의 방향이었다. 의심해야 할 AI를 맹신하고, 기대야 할 사람(작목반 동료들)을 오히려 멀리한 것이다.

바이브코딩도 정확히 같은 함정 위에 있다. AI가 자신만만하게 짜준 코드는 “상위 0.001%”라는 칭찬만큼이나 그럴듯하다. 그것을 그대로 믿고 라이브 서비스에 올리는 것과, 정말 맞는지 의심하고 검증하고 책임지는 것 - 그 차이가 바로 이 시대가 새로 요구하는 능력이다.

생성이 공짜가 된 세계에서 희소해진 것은 만드는 손이 아니라, 무엇을 믿을지 가려내는 눈이다.

검증의 회의는 AI에게, 정서의 신뢰는 사람에게 돌려놓아야 한다. 계산이 천재의 척도이던 시대가 저문 것처럼, ‘코드를 짜는 능력’이 곧 실력이던 시대도 저물고 있다. 다가오는 시대가 묻는 것은 더 이상 “너는 만들 수 있는가”가 아니라, “너는 가려낼 수 있는가”이다.

진짜 승부는 개인이 아니라 조직에서 갈린다

여기서 한 걸음 더 나가야 한다. ‘가려내는 눈’은 개인의 자질처럼 보이지만, 시대를 바꾼 승부는 늘 그 눈을 조직 단위로 끌어올린 쪽이 가져갔다.

축구를 떠올려 보자. 흔히 축구를 현대판 대리전이라 부른다. 그런데 진짜 나라와 나라의 경쟁은 태생부터 공정하지 않다. 어떤 나라는 발밑에 석유와 희토류를 깔고 있고, 어떤 나라는 사막과 척박한 땅만 물려받았다. 무역 항로의 길목을 쥔 나라가 있는가 하면, 사방이 막혀 바다로 나가지도 못하는 나라가 있다. 수백 년간 자본과 기술, 제도와 교육을 차곡차곡 쌓아온 나라가 있고, 이제 막 출발선에 선 나라가 있다. 여기에 내수를 떠받치는 인구의 크기, 세계 공용어를 모국어로 두었는가, 손에 쥔 기축통화, 등 뒤에 선 동맹의 무게까지 더하면 - 국가 간의 판은 시작부터 기울어져 있다. 자원도, 위치도, 상속된 자산도, 그 밖의 조건도 저마다 다르기 때문이다.

그런데 축구는 그 기울어진 축들을 경기장 밖으로 밀어낸다. 물론 완전히는 아니다. 두껍게 쌓인 유소년 인프라나 오래 축적된 리그의 역사처럼, 배경 자산은 잔디 위로도 얼마간 스며든다. 애초에 아무 조건에도 매이지 않는 완전히 자유로운 무대란 없다. 그러나 축구와 같은 국제 스포츠의 묘미는, 승부를 가르는 것이 그 배경이 아니라 경기에 직접 관련된 것이라는 데 있다. 특히 여럿이 함께 뛰는 축구에서는 개인의 기량과 그것을 하나로 엮는 조직력이 90분을 좌우한다. 석유도, 항로도, 기축통화도 골문 앞에서는 공을 대신 차주지 않는다. 상속의 크기가 아니라 종목의 실력이 전면에 서는 곳, 개인의 능력과 팀워크와 조직력을 한자리에서 겨뤄볼 수 있는, 문명이 만들어낸 몇 안 되는 무대다.

AI 시대도 결국, 개인의 천재성과 도구 활용을 조직 차원에서 극단적으로 끌어올리는 첫 번째 회사가 이긴다. 싸이월드가 페이스북이 되지 못한 것처럼, 새롭게 개편되는 게임 무대에서 기존과 다른 새로운 능력에 변하지 않는 조직력을 더한 쪽이 승부를 가져간다.

다만 이번 변화가 이전의 진화와 다른 지점도 여기에 있다. 컴파일러도, SQL도, 스프레드시트도 결국은 ‘만드는 사람’의 도구였다. 그러나 이번 도구는 개발의 담을 넘어 기획·회계·의료·법률·과학·공학·디자인까지 전방위로 번질 조짐을 보인다. 판이 새로 짜이는 무대가 그만큼 넓어졌다는 뜻이다.

그래도 변하지 않는 명제 - 도구는 문명을 앞당긴다

그럼에도 사다리 맨 위에서 변하지 않는 명제가 하나 있다. 이 모든 것이 결국 도구라는 사실이다. 펀치카드 앞에 머물렀을 우리를 모바일의 시대로 데려온 것이 도구였듯, 바이브코딩과 AI 에이전트도 문명의 다음 진보를 앞당기는 도구다. 도구는 목적지가 아니라 가속기다.

그리고 모든 도구가 그렇듯, 이 도구의 병목도 결국 사람과 조직이다. 아무리 강력한 컴파일러가 있어도 무엇을 만들지 정하고 그 결과를 책임지는 것은 사람이었고, 그 사람들을 어떻게 엮느냐는 조직의 몫이었다. AI라고 다르지 않다.

그래서 지금 벌어지는 일은 단기적으로 대체, 곧 해고처럼 보인다. 하지만 사다리의 역사가 매번 증명했듯, 사라지는 것은 저수준 노동이고 그 자리를 잇는 것은 더 높은 차원의 전문화다. 기계어를 치던 손이 알고리즘을 설계하는 머리가 되었듯, 코드를 치던 자리는 판단하고 검증하고 책임지는 자리로 옮겨간다. 대체처럼 보이는 그 이동의 진짜 이름은 전문화다 - 더 큰 문명을 짓기 위한.

AI는 그 규칙을 다시 한 번 갈아, 우리 모두를 새 종목의 출발선에 세웠다. 물려받은 자원도, 위치도, 자본도 사라지지 않는다. 다만 그것은 이제 승부를 결정짓는 축이 아니라 등에 짊어진 체력으로 남을 뿐이다. 잔디 위에서 경기를 가르는 것은, 누가 사람과 도구와 조직을 가장 먼저 다음 단계로 끌어올리느냐다. 펀치카드를 쥐고도 끝내 모바일까지 걸어온 길이 그랬듯, 도구는 문을 열 뿐 그 문을 지나 더 큰 문명을 짓는 일은 언제나 사람과 조직의 몫이었다. 그리고 그 몫을 향해 한 칸씩 옮겨 서는 것이야말로, 문명이 스스로를 밀어 올리는 방식이다.

개발도 반도체도, 결국은 문명 건축이다

LLM으로 문명을 밀어 올릴수록 개발도 반도체도 쉼 없이 발전한다. 사실 이 둘의 차이란, 큰 것이냐 아주 작은 것이냐, 만질 수 있느냐 이해해야만 하느냐의 차이일 뿐이다.

인식 ＼ 방향	쌓아서 커진다	파고들수록 작아진다
물질	건축	반도체
논리	개발(어플리케이션)	?

남은 한 칸, ‘논리이면서 파고들수록 작아지는 것’은 무엇일까? AI에게 채워보라 하면 좀처럼 답을 내지 못한다. 알고리즘, 자료구조, SQL, 프로토콜, 컴파일러… 아무리 다양하게 고르라 해도 돌아오는 것은 전부 컴퓨터 안의 것뿐이다. 넓게 펼친 듯해도, 한 우물 안에서만 넓다.

정답은 학문이다. 반도체가 트랜지스터라는 물리적 바닥에서 멈추는 것과 달리, 학문은 바닥이 없다. 원자에서 쿼크로, 쿼크에서 끈으로, 파고들수록 끝없이 더 작은 단위가 나온다. 그리고 어플리케이션이 학문을 재료 삼아 위로 쌓이듯, 작은 것을 파낸 쪽은 늘 큰 것을 짓는 쪽의 재료가 된다.

인식 ＼ 방향	쌓아서 커진다	파고들수록 작아진다
물질	건축	반도체
논리	개발(어플리케이션)	학문

문제는 AI가 답을 틀렸다는 게 아니라, 왜 못 맞혔는가이다. AI의 학습 데이터가 코드와 기술 텍스트로 가득 차 있어, ‘논리이면서 미시적인 것’이라는 빈칸을 보면 중력처럼 컴퓨터 쪽으로 끌려간다. AI가 고른 게 아니라, 데이터의 분포가 고른 것이다. 창의처럼 보이던 그 후보들은 실은 학습된 분포 안에서의 이동에 지나지 않았고, 그 분포 밖으로 끌어내는 데는 데이터에 갇히지 않은 사람이 줄을 당겨주어야 한다.

그래서 AI는 문명의 다음 칸을 앞당기는 강력한 도구이면서도, 동시에 자기가 배운 세계의 중력에 매여 있다. 그 중력 밖의 각을 보는 일 - AI가 유창하게 채워 넣은 답 옆에서 그 답이 갇힌 우물을 알아보고, 그것을 조직의 힘으로 키워 문명을 한 칸 더 밀어 올리는 일 - 은 여전히 사람의 몫이다. 손으로 지을 수 있는 모든 것(건축)에서, 만질 수 없는 소프트웨어(개발)와 손으로는 지을 수 없는 것(반도체)을 지나, 바닥 없는 학문의 깊이로까지. 도구가 아무리 좋아져도, 그 우물 밖으로 줄을 당기는 손은 끝내 사람과 그 조직인 것이다.

AI와 기술