SYDE
SYDESYDESYDEAI는 우리의 직업을 없앨 수 있을까?
1970년대, 길거리에 현금자동입출금기(ATM)가 처음 깔렸을 때 사람들은 은행원이라는 직업이 멸종할 것이라며 호들갑을 떨었습니다.
하지만 기묘하게도 은행원의 수는 그 후 수십 년간 오히려 폭발적으로 늘어났죠.
기계 덕분에 지점 유지비가 싸지자, 은행들이 동네마다 지점을 더 많이 내고 은행원을 대거 채용했기 때문입니다.
은행원들의 진짜 대학살은 그로부터 30년 뒤, 스티브 잡스가 사람들의 주머니 속에 '아이폰'을 쥐여주며 비로소 시작되었습니다.
데이비드 옥스(David Oks)가 최근 자신의 블로그를 통해 꼬집은 이 서늘한 역사는, 단순히 과거의 경제학 패러독스가 아닙니다.
지금 에디터를 켜놓고 "AI 덕분에 주말 개발 속도가 10배 빨라졌다"며 환호하는 우리 메이커들이, 얼마나 섬뜩하고 순진한 착각에 빠져 있는지 적나라하게 경고하는 명세서에 가깝습니다.
우리가 AI를 쥐고 짓고 있는 사이드프로젝트와 커리어가 단순한 'ATM'인지 아니면 생태계를 파괴할 '아이폰'인지, 그 냉혹한 진실의 민낯을 들여다보겠습니다.
데이비드 옥스는 기술이 인간의 노동을 대체하는 방식을 두 가지 패러다임으로 명확하게 나눕니다.
첫 번째는 바로 ATM 모델입니다.
ATM은 은행원이라는 '기존의 은행 지점 패러다임' 안에서, 그들이 하던 현금 출납이라는 '특정 작업(Task)'만을 빠르고 싸게 자동화했어요.
노동의 빈 공간에 자본(기계)을 쑤셔 넣은 것에 불과했죠.
결과적으로 지점이라는 틀 자체가 유지되었기 때문에, 사람들은 여전히 대출 상담을 받으러 은행을 찾았고 은행원은 역할만 바꾼 채 살아남았습니다.
지금 수많은 1인 개발자나 기획자들이 챗GPT나 커서를 대하는 태도가 정확히 이렇습니다.
"Next.js 보일러플레이트 코드를 순식간에 짜주네!", "API 연동 문서를 10초 만에 요약해 주네!" 라며 환호하죠.
하지만 이것은 기존의 '소프트웨어 개발'이라는 단단한 틀 안에서 단순 반복 작업만을 자동화하는, 전형적인 ATM식 접근법에 불과합니다.
진짜 무서운 파괴는 아이폰(스마트폰)이 모바일 뱅킹 앱을 대중화하면서 벌어졌습니다.
아이폰은 은행원의 업무 속도를 높여준 것이 아닙니다. 유저들이 '은행 지점에 굳이 가야 할 이유' 자체를 완벽하게 없애버렸죠.
'지점 방문'이라는 패러다임 자체가 스마트폰 속으로 증발해 버리자, 수십 년간 굳건했던 은행원 고용률은 절벽 아래로 곤두박질쳤습니다.
특정 작업을 기존 틀 안에서 조금 더 잘하는 것(ATM)은 인간을 대체하지 못하지만, 그 작업이 존재해야 할 이유 자체를 지워버리는 완전히 새로운 패러다임(아이폰)은 인간을 가차 없이 시장에서 지워버립니다.
의료나 건설처럼 물리적 제약과 마찰(Friction)이 극심한 산업은 여전히 AI를 ATM처럼 보조 도구로만 쓸 확률이 높습니다.
하지만 우리 메이커들이 몸담고 있는 이 IT 생태계는 어떨까요?
코드라는 순수한 데이터로만 이루어진 이 판에서는, AI가 기존의 앱 개발과 배포 패러다임 자체를 붕괴시키는 '아이폰'의 역할을 하는 속도가 타 산업에 비해 압도적으로 빠르고 파괴적일 수밖에 없습니다.
이 묵직한 통찰은 오늘도 모니터 앞에서 코드를 깎고 있는 우리 제너럴리스트 메이커들에게 아주 날카로운 질문 두 가지를 던집니다.
첫째, 당신이 만들고 있는 서비스는 유저의 기존 일상을 조금 더 낫게 만드는 ATM입니까, 아니면 아예 그 일상의 공식을 바꿔버리는 아이폰입니까?
단순히 "기존 툴보다 UI가 예쁘고 렌더링이 조금 더 빨라요" 수준의 기능적 개선은, 거대한 AI의 파도 앞에서 그 어떤 해자(Moat)도 구축하지 못합니다.
둘째, 메이커로서 당신의 포지셔닝은 안전합니까?
AI가 프론트엔드와 백엔드를 전부 찍어내는 세상에서, 플러터(Flutter) 위젯의 상태 관리를 기가 막히게 하고 FastAPI로 서버를 남들보다 30분 빨리 띄우는 '은행원의 빠른 손놀림'은 더 이상 강력한 무기가 되지 못합니다.
결국 살아남는 것은 "어떤 문제를 해결하기 위해, 아예 기존의 방식을 뒤엎는 완전히 새로운 구조를 어떻게 설계할 것인가"를 고민하는 시스템적 통찰력뿐입니다.
거대한 패러다임의 붕괴 앞에서 우리는 무엇을 기획하고 어떻게 실행해야 할까요?
단순한 속도전을 멈추고 당장 적용해야 할 3가지 생존 전략을 짚어드립니다.
🚫 작업의 개선이 아닌 '필요의 제거' 기획하기:
이번 주말에 추가하려던 신규 기능이 "유저의 클릭을 한 번 줄여주는 것"이라면 잠시 멈추세요.
"유저가 이 클릭 자체를 아예 안 해도 원하던 결과물을 얻게 만들려면 프로세스를 어떻게 박살 내야 할까?"라는 질문으로 피벗(Pivot)해야 진짜 10배의 가치가 폭발합니다.
🧠 '도구 숙련도'에 집착하는 시간 버리기:
특정 프레임워크의 최신 업데이트나 언어의 문법을 달달 외우는 건, 기존 은행 지점 안에서 최고참 은행원이 되려는 발버둥과 같습니다.
Supabase나 Firebase를 엮어내는 지루한 인프라 세팅은 AI에게 전적으로 위임해 버리고, 메이커의 뇌 용량은 오직 유저가 지갑을 여는 '행동 신호'와 비즈니스 로직을 설계하는 데에만 쏟아부으세요.
🚜 '마찰(Friction)'이 극심한 도메인으로 침투하기:
개발자들끼리만 쓰는 세련된 IT 툴만 만들지 마세요.
오프라인 커뮤니티, B2B 물류, 보수적인 행정 등 기존의 관성과 마찰이 가장 극심한 산업에 과감히 소프트웨어를 들이밀어 보세요.
낡은 관행이 남아있는 곳일수록 AI가 아이폰으로 진화하기까지 시간이 걸리며, 민첩한 소규모 메이커 팀이 깃발을 꽂고 시장을 독식할 수 있는 블루오션이 펼쳐집니다.
💡 코딩 속도를 자랑하는 시대는 끝났습니다. 이제는 무엇을 파괴할 것인가를 상상해야 합니다.
"해본 적 있으시죠?" 식의 뻔한 위로와 공감 대신, 오늘은 데이비드 옥스의 아주 냉정하고 뼈 아픈 통찰을 그대로 빌려와 보았습니다.
저 역시 가끔은 AI가 짜준 깔끔한 코드를 보며 내 실력이 늘었다고 착각하곤 하지만, 사실 우리는 그저 성능 좋은 ATM 기계를 옆에 두고 타이핑을 치는 은행원일지도 모릅니다.
진정한 제너럴리스트 메이커라면 주어진 틀 안에서 속도를 뽐내는 것에 만족해선 안 됩니다.
은행을 통째로 주머니 속에 넣어버린 아이폰처럼, 기존의 상식을 완전히 소멸시키는 뾰족한 기획만이 우리를 구원할 유일한 열쇠니까요.
🔗 원본 글 링크:
https://davidoks.blog/p/why-the-atm-didnt-kill-bank-teller첫 번째 댓글을 남겨보세요!
