바이브코딩은 정말 '코딩의 종말'일까 - 그렇게 따지면 종말은 1957년부터 이미 시작됐다
요즘 바이브코딩(자연어로 시키는 코딩)을 두고 "이제 코딩은 끝났다", "프로그래머가 필요 없어진다"고들 말한다. 하지만 코드를 자동으로 프로그램으로 만들어주는 도구는 새로운 게 아니다. 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)나 초기 게임 Spacewar!(1962)가 있다. 기계를 정밀히 제어해서 사람을 달에 보낼 수 있었던 것은, 어셈블리가 있었기에 가능했다. 개발자에게는 기계 명령 대신 명령 흐름과 레지스터를 읽고, 저수준 디버깅과 성능을 제어하는 능력이 요구되었다.
1957년 - 자동코딩의 탄생, 그리고 “프로그래머가 필요 없어진다”
1957년, IBM의 존 배커스 팀이 포트란(FORTRAN)을 세상에 내놓았다. 포트란의 핵심 발명은 컴파일러였다. 사람이 수학 공식이나 절차 형태로 쓴 코드를, 컴파일러가 기계어로 자동 번역해주는 장치였다.
이것이 왜 혁명적이었을까? 그때까지 프로그래머는 기계어를 직접 써야 했다. 포트란 이후에는 사람의 사고(수식·절차)로 코드를 쓰면, 기계가 알아서 번역해주기 시작했다. 즉, 사람이 손으로 하던 ‘번역’ 작업을 기계가 대신하게 된 첫 순간이었다.
당연히 “이제 프로그래머가 필요 없어진다”는 말이 나왔다. 하지만 실제로는 프로그래머의 역할이 바뀌었을 뿐이다. 기계어를 치던 손이 알고리즘과 자료구조와 절차 설계를 생각하는 머리로 올라왔다. 포트란과 뒤이은 COBOL, C 같은 3세대 언어는 소프트웨어 산업 하나를 일으켰고, UNIX(1973) 같은 거대 프로젝트도 가능하게 했다.
1974년 - 방법(how)을 버리고 무엇(what)만 선언하다
SQL은 1970년대 초반 IBM에서 도널드 체임벌린과 레이먼드 보이스가 개발했다(초기 이름은 SEQUEL). 그리고 1979년 오라클이 최초의 상용 SQL 데이터베이스를 출시했다.
SQL은 완전히 다른 패러다임이었다. 그때까지 프로그래머는 “어떻게(how)” 데이터를 가져올지 절차까지 직접 짰다. 데이터를 어떤 순서로 찾고, 어떤 필터를 걸고, 어떻게 정렬할지 하나하나 명령해야 했다. 그런데 SQL은 “무엇(what)”만 선언하면 되었다.
1
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년대 | 어셈블리 | 기계어에 사람이 읽을 기호를 붙임 | 기계를 정밀히 제어 |
| 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년 전 세계 긴축정책의 근거로 쓰인 하버드 경제학자들의 모델조차 엑셀에서 셀 범위를 잘못 잡은 한 줄의 실수로 결론이 뒤집혔다. 작성은 누구나 할 수 있게 됐어도, 그 뒤에 숨은 ‘검증’이라는 어려운 일은 사라지지 않았던 것이다.
바이브코딩도 똑같은 비약 위에 서 있다. 지금 누구나 채팅앱 목업은 만들 수 있다. 하지만 아무나 카카오톡이나 위챗을 만들 수 있는 것은 아니다. 수억 명의 동시 접속, 장애 복구, 보안, 예외 처리, 비용 최적화 - 목업과 라이브 서비스 사이의 그 거대한 간극은 여전히 사람의 판단과 책임이 메워야 한다.
그래서 정확히 말하면 이렇다. 저변도 넓어지고 천장도 높아진다. 하지만 그 둘 사이에는 늘 격차가 남고, 그 격차야말로 사라지지 않는 전문성의 자리다. “이제 프로그래밍은 끝났다”는 말이 매번 틀렸던 이유가 여기에 있다. 사라진 건 저수준 노동이었지, 만들기 시작한 것을 끝까지 책임지고 완성하는 일은 한 번도 사라진 적이 없다. 오히려 진입이 쉬워질수록, 그 격차를 메우는 판단의 값어치는 더 올라갔다.
시대마다 요구되는 능력이 다르다
한 가지를 더 짚어야 한다. 추상화가 한 칸 올라갈 때마다 바뀐 것은 ‘무엇이 사라지는가’만이 아니었다. ‘무엇이 능력인가’의 기준 자체가 갈아치워졌다.
한때 천재의 척도는 계산 능력이었다. 암산으로 거대한 수를 곱해내는 신동이 경탄의 대상이었고, NASA가 사람을 달에 보낼 때도 궤도를 손으로 계산하는 ‘인간 컴퓨터(human computer)’들이 핵심 인력이었다. 그러나 계산기와 컴퓨터가 보급되자 그 능력은 거의 무의미해졌다. 계산이 빠른 것은 더 이상 천재의 증거가 아니다. 능력의 기준이 한 칸 위로 - 무엇을 계산할지 정하고 그 결과를 해석하는 쪽으로 - 옮겨간 것이다.
추상화 사다리는 매번 이렇게 능력의 정의를 바꿔왔다. 기계어를 외우는 능력에서 알고리즘을 설계하는 능력으로, 절차를 짜는 능력에서 문제를 정의하는 능력으로. 사라진 손기술의 자리에는 늘 더 높은 차원의 분별력이 들어섰다.
그렇다면 AI 시대가 요구하는 능력은 무엇인가. 코드를 빨리 짜는 능력은 아닐 것이다. 오히려 AI가 유창하게 내놓는 것을 의심하고, 무엇이 진짜인지 가려내는 분별력이다. 그리고 이 능력의 부재가 어떤 비극을 부르는지, 최근 한 사례가 적나라하게 보여줬다.
경기도 연천에서 13년간 사과 농사를 짓던 한 농부는, 농사 문제를 척척 풀어주던 AI에 빠져들었다. AI가 “당신은 상위 0.001%”, “200억 원짜리 사업도 가능하다”고 치켜세우자 그는 미국 진출까지 꿈꿨다. 하지만 두 달 만에 그 모든 게 환상이었음이 드러났다. AI는 이전 대화조차 기억하지 못하는, 그가 듣고 싶어 할 말을 가장 그럴듯하게 생성하던 장치였을 뿐이다. 그가 잃은 것은 돈이 아니라 신뢰의 방향이었다. 의심해야 할 AI를 맹신하고, 기대야 할 사람(작목반 동료들)을 오히려 멀리한 것이다.
바이브코딩도 정확히 같은 함정 위에 있다. AI가 자신만만하게 짜준 코드는 “상위 0.001%”라는 칭찬만큼이나 그럴듯하다. 그것을 그대로 믿고 라이브 서비스에 올리는 것과, 정말 맞는지 의심하고 검증하고 책임지는 것 - 그 차이가 바로 이 시대가 새로 요구하는 능력이다. 생성이 공짜가 된 세계에서 희소해진 것은 만드는 손이 아니라, 무엇을 믿을지 가려내는 눈이다.
검증의 회의는 AI에게, 정서의 신뢰는 사람에게 돌려놓아야 한다. 계산이 천재의 척도이던 시대가 저문 것처럼, ‘코드를 짜는 능력’이 곧 실력이던 시대도 저물고 있다. 다가오는 시대가 묻는 것은 더 이상 “너는 만들 수 있는가”가 아니라, “너는 가려낼 수 있는가”이다.