공포 마케팅
0. 학습 목표
이번 단계에서는 신입 개발자가 새로운 기술을 바라볼 때 가져야 할 올바른 관점을 학습합니다.
새로운 기술이 등장할 때마다 개발자는 다양한 메시지를 듣게 됩니다.
“이 기술을 모르면 앞으로 살아남을 수 없다.”
“AI 때문에 개발자는 곧 사라진다.”
“지금 당장 배우지 않으면 뒤처진다.”
이런 표현은 학습 동기를 주는 것처럼 보이지만, 실제로는 불안감을 자극하는 공포 마케팅에 가까운 경우가 많습니다.
이번 학습의 목표는 신기술을 무시하는 것이 아닙니다. 오히려 새로운 기술을 더 정확하게 이해하기 위해, 공포가 아니라 기준을 가지고 기술을 바라보는 관점을 갖는 것입니다.
| 학습 항목 | 내용 |
| 공포 마케팅 이해 | 신기술을 과장하거나 두려움으로 학습을 유도하는 방식을 이해합니다. |
| 기술 판단 기준 이해 | 기술 자체보다 사람의 필요, 문제 해결, 실질적 이득을 기준으로 봅니다. |
| 사례 분석 | Tesla FSD, 블록체인, 메타버스, 아마존 고, AI 사례를 통해 기술과 현실의 차이를 확인합니다. |
| 신입 개발자 관점 정리 | 모든 기술을 쫓기보다 기본기와 문제 해결력을 중심에 둡니다. |
1. 공포 마케팅의 문제
공포 마케팅은 사람의 불안감을 자극하여 행동을 유도하는 방식입니다.
개발 분야에서는 새로운 기술이 등장할 때마다 다음과 같은 형태로 나타납니다.
“이제 이 기술을 모르면 개발자로 살아남을 수 없다.”
“기존 기술은 모두 쓸모없어질 것이다.”
“새로운 기술이 사람의 역할을 완전히 대체할 것이다.”
물론 새로운 기술을 배우는 것은 중요합니다.
하지만 문제는 기술의 필요성과 맥락을 설명하지 않고, 불안감만 강조하는 방식입니다.
공포 마케팅은 신입 개발자에게 다음과 같은 문제를 만들 수 있습니다.
| 문제 | 설명 |
| 학습 기준 혼란 | 왜 배워야 하는지보다 안 배우면 큰일 난다는 감정이 먼저 생깁니다. |
| 기술 과대평가 | 새로운 기술이 모든 문제를 해결할 것처럼 오해하게 됩니다. |
| 기본기 약화 | 기초 원리보다 유행하는 기술 이름을 따라가는 데 집중하게 됩니다. |
| 자신감 저하 | 아직 성장 중인 신입 개발자가 불필요한 불안감을 느끼게 됩니다. |
2. 사례 기준 설명
다음 사례들은 특정 기술을 비난하기 위한 것이 아닙니다.
각 사례를 통해 기술적 가능성과 현실의 필요가 다를 수 있다는 점을 확인합니다.
사례1. Tesla FSD: 기술 기대와 실제 선택의 차이
Tesla FSD는 자율주행 기술에 대한 큰 기대를 모은 대표적인 사례입니다.
운전자의 부담을 줄이고, 더 편리한 이동 경험을 제공할 수 있다는 점에서 많은 관심을 받았습니다.
하지만 기술적으로 주목받는다고 해서 모든 사용자가 바로 선택하거나 적극적으로 사용하는 것은 아닙니다.
공개 자료를 기준으로 보면, Tesla의 2026년 1분기 활성 FSD 구독자는 약 128만 명이고,
누적 차량 인도량은 약 920만 대입니다.
단순 계산하면 전체 누적 차량 대비 활성 FSD 구독 비율은 약 13.9% 수준입니다.
다만 이 수치는 “FSD를 실제로 자주 사용하는 비율”이 아니라,
FSD를 유료로 사용 가능한 상태인 활성 구독 비율로 이해해야 합니다.
주의할 점
FSD 실제 사용률은 “구독 여부”와 다릅니다.
구독자가 매일 FSD를 사용하는지, 전체 주행거리 중 몇 %를 FSD로 주행하는지는 사용자별로 다를 수 있습니다.
또한 Tesla FSD는 누적 주행거리 100억 마일을 넘겼지만, 여전히 운전자의 감독이 필요한 FSD Supervised입니다.
즉, 소비자 차량에서 완전 무감독 자율주행이 일반화되었다고 보기는 어렵습니다.
| 구분 | 내용 |
| 활성 FSD 구독자 | 약 128만 명, 2026년 1분기 기준 |
| 누적 차량 인도량 | 약 920만 대, 2026년 1분기 기준 |
| 단순 구독 비율 | 약 13.9% |
| 해석 | 기술 관심은 크지만, 전체 사용자 중 유료 FSD를 선택한 비율은 제한적임 |
신입 개발자가 배워야 할 점:
기술이 혁신적이어도 가격, 신뢰성, 안전성, 법적 책임, 실제 필요성이 맞지 않으면 모든 사용자가 바로 선택하지는 않습니다.
사례2. 블록체인: 큰 기대와 제한적인 현실 적용
블록체인은 투명성, 보안, 탈중앙화라는 장점을 바탕으로 많은 기대를 받았습니다.
금융, 스마트 계약, 공급망, 디지털 신원 등 다양한 분야에서 활용 가능성이 이야기되었습니다.
하지만 실제 공개 수치로 확인되는 블록체인 활용은 아직 범용 생활 서비스보다
암호자산 거래, DeFi, 스테이블코인, 금융 인프라 쪽에 치중되어 있습니다.
예를 들어 2025년 1월부터 7월까지 스테이블코인은 전체 암호화폐 거래량의 약 30%를 차지했고,
같은 기간 거래량은 4조 달러 이상으로 분석되었습니다.
또한 법정화폐 담보 스테이블코인의 대부분은 미국 달러에 연동되어 있으며,
USDT와 USDC가 스테이블코인 시가총액의 약 93%를 차지합니다.
2024년 스테이블코인 거래량을 기준으로 보면, 전체 거래량 중 약 88%는 암호화폐 거래 페어, 차익거래, 유동성 이동에 가까운 활동으로 추정됩니다. 반면 실제 결제 목적은 약 5%, 토큰화 자산 결제는 약 3% 수준으로 추정됩니다.
| 활용 영역 | 비중 또는 수치 | 해석 |
| 스테이블코인 | 전체 암호화폐 거래량의 약 30% | 블록체인 활용 중 금융·거래 인프라 비중이 큼 |
| USDT / USDC | 스테이블코인 시가총액의 약 93% | 달러 기반 스테이블코인 중심으로 사용이 집중됨 |
| 거래·DeFi 관련 활동 | 스테이블코인 거래량의 약 88% | 실생활 결제보다 거래·차익거래·유동성 이동 비중이 큼 |
| 실제 결제 목적 | 약 5% 수준 추정 | 결제 가능성은 있지만 아직 주류 사용처라고 보기는 어려움 |
신입 개발자가 배워야 할 점:
블록체인은 가능성이 큰 기술이지만, 현재 실제 사용은 특정 영역에 치중되어 있습니다.
따라서 “모든 산업을 대체한다”는 말보다, 어떤 분야에서 실제 사용되고 있는지 수치로 확인하는 습관이 필요합니다.
사례3. 메타의 메타버스: 큰 비전과 현실 사용성의 간극
메타는 Facebook에서 Meta로 사명을 변경하며, 메타버스를 차세대 핵심 비전으로 제시했습니다.
메타버스는 가상공간에서 사람들이 만나고, 일하고, 배우고, 쇼핑하고, 콘텐츠를 즐기는
새로운 디지털 공간을 만들겠다는 시도였습니다.
하지만 이후 현실에서는 VR 기기 착용 부담, 높은 기기 가격, 콘텐츠 부족, 기존 스마트폰과 PC 서비스 대비 낮은 필요성 등의 문제가 드러났습니다.
실제로 Meta는 업무용 VR 협업 서비스인 Horizon Workrooms를 2026년 2월 16일 종료하기로 했고,
기업용 Meta Horizon 관리 서비스와 Quest 상업용 제품 판매도 중단하기로 했습니다.
또한 Horizon 경험과 AI 창작 도구를 모바일 중심으로 강화하는 방향이 언급되었습니다.
한편 Reality Labs는 여전히 막대한 손실을 기록하고 있으며,
Meta는 2026년에도 Reality Labs의 영업손실이 2025년과 비슷한 수준일 것으로 전망했습니다.
동시에 회사의 투자 우선순위는 AI 인프라와 Meta Superintelligence Labs 쪽으로 더 크게 이동하고 있습니다.
| 구분 | 내용 |
| 초기 기대 | VR 기반 가상공간에서 업무, 교육, 소통, 쇼핑, 엔터테인먼트 통합 |
| 현실의 문제 | 기기 착용 부담, 비용, 콘텐츠 부족, 반복 사용 이유 부족 |
| 전략 변화 | 업무용 VR 서비스 종료, AI·모바일·스마트글래스 중심으로 무게 이동 |
| 핵심 교훈 | 큰 투자와 비전이 있어도 사용자가 일상에서 필요성을 느끼지 못하면 전략은 수정될 수 있음 |
신입 개발자가 배워야 할 점:
기업이 강하게 밀어붙이는 기술이라도 시장의 실제 사용성과 필요성이 부족하면 방향이 바뀔 수 있습니다.
따라서 신기술을 볼 때는 기업의 홍보 문구보다 사용자의 반복 사용 이유를 확인해야 합니다.
사례4. 아마존 고: 계산 없는 매장의 가능성과 현실
아마존 고와 Just Walk Out 기술은 계산대를 거치지 않고 상품을 들고 나가면 자동으로 결제되는 매장을 목표로 했습니다.
기술적으로는 매우 인상적인 시도였습니다.
계산 대기 시간을 줄이고, 쇼핑 경험을 더 간단하게 만들 수 있었기 때문입니다.
하지만 실제 매장 확장은 기대만큼 이루어지지 않았습니다.
2023년에는 Amazon Go 29개 중 8개 매장 폐쇄가 보도되었고,
2025년 말~2026년 초에는 남은 Amazon Go 매장이 약 15~16개 수준으로 줄어든 상태였습니다.
이후 Amazon은 2026년 1월 공식 발표를 통해 Amazon Go와 Amazon Fresh 물리 매장을 폐쇄하고,
일부 매장을 Whole Foods Market으로 전환하겠다고 밝혔습니다.
Amazon은 Amazon-branded 물리 식료품 매장에서 대규모 확장에 필요한 차별화된 고객 경험과 경제 모델을 아직 만들지 못했다고 설명했습니다.
| 시점 | 매장 수 흐름 | 의미 |
| 2018년 | Amazon Go 일반 공개 | 계산 없는 매장이라는 새로운 오프라인 쇼핑 실험 시작 |
| 2023년 | 29개 중 8개 폐쇄 보도 | 초기 기대와 달리 일부 지역에서 확장성 문제 발생 |
| 2025년 말~2026년 초 | 약 15~16개 수준으로 축소 | 대규모 매장 확장 대신 제한적 운영 상태 |
| 2026년 | Amazon Go와 Amazon Fresh 물리 매장 폐쇄 결정 | Whole Foods와 온라인 식료품 배송 중심으로 전략 전환 |
대형 식료품 매장에서는 사용자가 장을 보면서 현재 금액, 할인, 구매 내역을 확인하고 싶어 하는 필요가 있었습니다.
즉, 계산대를 없애는 것이 항상 더 좋은 사용자 경험은 아니었습니다.
신입 개발자가 배워야 할 점:
기술적으로 가능한 것과 실제 사용자가 반복해서 선택하는 것은 다를 수 있습니다. 개발자는 “기술적으로 가능한가?”뿐 아니라 “고객이 실제로 더 편리하다고 느끼는가?”를 함께 생각해야 합니다.
사례5. AI: 개발자를 대체하는가, 역할을 바꾸는가?
최근 가장 큰 공포 마케팅 중 하나는 “AI가 개발자를 대체한다”는 표현입니다.
| 사례 | 확인 가능한 수치/사실 | 학습 메시지 |
| Tesla FSD | 활성 FSD 구독자 약 128만 명, 누적 차량 대비 약 13.9% | 기술 기대가 커도 실제 선택과 반복 사용은 가격·신뢰성·필요성에 좌우됨 |
| 블록체인 | 스테이블코인이 암호화폐 거래량의 약 30%, 스테이블코인 거래량의 상당 부분은 거래·DeFi 중심 | 범용 기술처럼 홍보되어도 실제 사용은 특정 영역에 집중될 수 있음 |
| 메타버스 | Horizon Workrooms 종료, 기업용 Quest/Horizon 판매 중단, AI·모바일·스마트글래스 중심 전환 | 기업의 큰 투자도 사용자의 반복 사용 이유가 부족하면 전략 수정으로 이어질 수 있음 |
| 아마존 고 | 2023년 29개 중 8개 폐쇄, 이후 약 15~16개 수준 축소, 2026년 물리 매장 폐쇄 결정 | 기술적으로 편리해 보여도 경제성·사용자 경험이 맞지 않으면 확장되지 못함 |
| AI | 코드 작성, 요약, 오류 설명 등에서 빠르게 활용 확대 | 개발자를 단순 대체하기보다 문제 정의·검토·책임 판단 역량의 중요성을 높임 |
AI가 개발 방식에 큰 변화를 가져오는 것은 맞습니다.
코드 작성, 오류 분석, 문서 요약, 예제 생성 등 많은 작업에서 AI는 강력한 도구가 될 수 있습니다.
공포 마케팅 관점에서는 이런 식으로 말할 수 있습니다.
“AI가 코드를 작성하니 개발자는 필요 없어질 것이다.”
“AI를 쓰지 못하면 개발자로 취업할 수 없다.”
하지만 여기서 중요한 질문은 “AI가 개발자를 없앨까?”가 아닙니다.
AI는 개발자의 일을 없애기보다 개발자의 일하는 방식을 바꿉니다.
3. 신기술을 바라보는 신입 개발자의 기준
신기술은 계속 등장합니다.
자율주행, 블록체인, 메타버스, 아마존 고, AI처럼 새로운 기술은 등장할 때마다 큰 기대를 받습니다.
하지만 기술이 새롭고 강력하다는 사실만으로는 충분하지 않습니다.
기술이 실제로 널리 사용되려면 사람의 필요를 해결해야 하고, 사용자가 체감할 수 있는 분명한 이득을 제공해야 합니다.
Tesla FSD는 운전 부담을 줄이는 자율주행 보조 기술로 기대를 받았지만,
가격, 신뢰성, 안전성, 실제 사용 필요성을 함께 고려해야 합니다.
블록체인은 탈중앙화, 투명성, 스마트 계약이라는 가능성을 보여 주었지만,
현실에서는 확장성, 비용, 규제, 사용자 경험의 영향을 받습니다.
메타버스는 가상공간에서 소통과 활동을 확장하려는 시도였지만,
기기 부담, 콘텐츠 부족, 반복 사용 이유 부족이라는 현실적 문제를 만났습니다.
아마존 고는 계산대 없는 자동 결제 매장을 시도했지만,
사용자는 여전히 구매 금액, 할인, 장바구니 내역을 확인하고 싶어 했습니다.
AI는 코드 작성, 오류 분석, 문서 요약, 테스트 코드 생성 등에서 개발자를 도와줄 수 있습니다.
하지만 AI가 개발자를 단순히 없애는 것이 아니라, 개발자가 일하는 방식을 바꾸고 있다는 점이 더 중요합니다.
| 기술 사례 | 기술적 기대 | 현실에서 확인할 점 |
| Tesla FSD | 운전 부담을 줄이는 자율주행 보조 | 가격, 신뢰성, 안전성, 실제 사용 필요성 |
| 블록체인 | 탈중앙화, 투명성, 스마트 계약 | 확장성, 비용, 규제, 사용자 경험 |
| 메타버스 | 가상공간 기반의 소통과 활동 | 기기 부담, 콘텐츠 부족, 반복 사용 이유 |
| 아마존 고 | 계산대 없는 자동 결제 매장 | 사용자의 구매 확인 욕구와 실제 쇼핑 습관 |
| AI | 코드 작성, 문서 요약, 업무 자동화 | 문제 정의, 책임 판단, 결과 검토는 여전히 개발자의 역할 |
1. 기술은 도구이고, 문제 해결이 목적이다
개발자는 기술을 사용하는 사람입니다.
하지만 더 정확히 말하면, 개발자는 문제를 해결하기 위해 기술을 선택하는 사람입니다.
따라서 신기술을 볼 때는 기술 이름을 먼저 보는 것이 아니라, 다음 흐름을 먼저 생각해야 합니다.
문제 이해 → 사용자 필요 파악 → 해결 방법 설계 → 필요한 기술 선택 → 결과물 구현
기술은 이 과정에서 사용되는 도구입니다. 도구가 먼저가 아니라, 해결해야 할 문제가 먼저입니다.
2. AI는 개발자를 없애는 것이 아니라 일하는 방식을 바꾼다
AI는 개발자의 모든 일을 대신한다기보다, 반복적이고 시간이 많이 걸리던 일부 작업을 빠르게 처리하도록 도와줍니다.
예제 코드 생성, 오류 메시지 설명, 반복 코드 작성, 문서 요약, 테스트 코드 초안 작성 같은 작업은 AI의 도움을 받을 수 있습니다.
하지만 AI가 반복 작업을 줄여 준다는 것은 개발자의 가치가 줄어든다는 뜻이 아닙니다. 오히려 개발자는 더 중요한 판단과 설계에 집중해야 합니다.
| 공포 중심 관점 | 올바른 개발자 관점 |
| AI가 코딩을 하니 개발자는 사라진다. | AI가 코딩을 도와주므로 개발자는 더 넓은 판단을 해야 한다. |
| 코딩 작업이 줄어들면 개발자의 가치도 줄어든다. | 반복 작업이 줄어들수록 문제 해결력과 설계 능력의 가치가 커진다. |
| AI가 만든 코드는 그대로 쓰면 된다. | AI가 만든 코드는 반드시 이해하고 검토해야 한다. |
| 기본기는 덜 중요해진다. | AI 결과를 판단하기 위해 기본기는 더 중요해진다. |
AI 시대의 개발자는 단순히 코드를 많이 작성하는 사람이 아닙니다.
이제 더 중요한 능력은 무엇을 만들어야 하는지 정의하고, AI가 만든 결과가 맞는지 판단하는 능력입니다.
문제 이해 → AI에게 요구사항 설명 → 초안 코드 생성 → 개발자 검토 → 수정 및 통합 → 테스트 → 배포 및 유지보수
AI가 초안 코드를 만들어 줄 수는 있지만, 그 코드가 실제 서비스에서 책임 있게 동작하는지 확인하는 일은 개발자의 역할입니다.
4. 인공지능이 바꾸는 개발자의 미래
최근 개발 분야에서 가장 많이 들리는 이야기 중 하나는 “AI가 개발자를 대체할 것이다”라는 말입니다.
하지만 아래 영상에서 다루는 핵심은 단순히 “AI가 코딩을 대신한다”는 이야기가 아닙니다.
더 중요한 변화는 AI가 개발자의 일을 없애는 것이 아니라,
개발자가 일하는 기본 단위와 작업 방식을 바꾸고 있다는 점입니다.
4.1. 영상 타임라인 요약
영상은 AI 시대의 개발자 역할 변화를 시간 순서대로 설명합니다. 단순히 코딩 속도가 빨라지는 변화가 아니라, 개발자가 어떤 방식으로 일해야 하는지가 바뀌고 있다는 점을 단계적으로 보여 줍니다.
| 시간 | 주제 | 핵심 내용 |
| 00:00 | 카파시가 뒤처졌다고 말한 이유 | AI가 단순히 코드를 잘 쓰는 수준을 넘어, 개발자가 일하는 기본 단위를 바꾸고 있음을 설명합니다. |
| 01:35 | Vibe Coding과 Agentic Engineering | 빠른 프로토타입 제작과 실제 서비스 품질을 관리하는 개발 방식의 차이를 설명합니다. |
| 05:06 | Software 3.0과 Context | 프롬프트와 컨텍스트로 LLM을 프로그래밍하는 시대가 되었음을 설명합니다. |
| 06:56 | MenuGen과 Software 3.0 | 앱의 역할이 기능 구현을 넘어 AI 워크플로우를 포장하는 방향으로 바뀔 수 있음을 보여 줍니다. |
| 08:34 | Verifiability와 Jagged Intelligence | AI 활용에서 중요한 것은 지능 자체보다 작업이 검증 가능한지 여부임을 강조합니다. |
| 10:37 | 테스트와 System Model | 겉보기에 동작하는 코드보다 시스템 전체 구조와 실패 상황을 이해하는 능력이 중요함을 설명합니다. |
| 12:22 | Agent-native Infrastructure | AI 에이전트가 실제 개발 환경에서 안정적으로 일할 수 있는 인프라의 필요성을 설명합니다. |
| 12:52 | 배포와 운영 경계 | AI가 코드를 만들 수 있어도 배포, 운영, 책임의 경계는 개발자가 관리해야 함을 설명합니다. |
| 13:28 | 이해는 아웃소싱할 수 없다 | 리서치와 코드 작성은 AI에게 맡길 수 있지만, 이해와 책임은 개발자의 몫임을 강조합니다. |
| 14:21 | 앞으로 개발자 격차가 나는 지점 | 앞으로는 타이핑 속도보다 이해의 깊이, 설계 능력, 검증 능력에서 개발자 간 격차가 커질 수 있음을 설명합니다. |
5.2. 00:00 카파시가 뒤처졌다고 말한 이유
영상의 시작에서는 안드레 카파시가 “프로그래머로서 이렇게 뒤처진 느낌은 처음”이라는 취지의 말을 한 이유를 설명합니다.
이 말은 단순히 AI가 코드를 빠르게 작성한다는 의미가 아닙니다.
더 중요한 의미는 개발자가 일하는 기본 단위가 바뀌고 있다는 것입니다.
기존 방식 : 함수 수정, 파일 작성, 오류 검색
AI 시대 방식 : 기능 구현, 테스트 작성, 수정, 배포 준비까지 작업 단위로 요청
과거에는 개발자가 함수 단위, 파일 단위로 직접 코드를 작성하고 수정했습니다.
하지만 AI 시대에는 “이 기능을 구현하고 테스트까지 해 봐”처럼 작업 전체를 AI에게 맡기는 방향으로 변화하고 있습니다.
코드는 더 빨리 만들어질 수 있습니다. 하지만 그 코드가 올바른 설계인지, 실제 서비스에서 안전하게 동작하는지 판단하는 책임은 오히려 개발자에게 더 중요해집니다.
5.3. 01:35 Vibe Coding과 Agentic Engineering
영상에서는 AI 코딩을 이해하기 위해 Vibe Coding과 Agentic Engineering을 구분합니다.
| 구분 | 설명 |
| Vibe Coding | 자연어 지시만으로 빠르게 앱이나 기능의 초안을 만드는 방식입니다. 코딩을 잘 모르는 사람도 프로토타입을 만들 수 있습니다. |
| Agentic Engineering | AI 에이전트를 활용하되, 스펙, 테스트, 검증, 실패 감지까지 포함해 실제 서비스 품질을 관리하는 개발 방식입니다. |
간단한 MVP나 프로토타입 수준에서는 Vibe Coding이 유용할 수 있습니다.
하지만 DB, 로그인, 결제, 권한 관리, 보안, 배포가 들어가는 순간 단순히 “일단 만들어졌다”로 끝낼 수 없습니다.
중요한 차이
Vibe Coding은 빠른 초안 제작에 강합니다.
하지만 실제 서비스 품질을 유지하려면 테스트, 검증, 실패 감지, 보안 기준이 포함된 Agentic Engineering이 필요합니다.
5.4. 05:06 Software 3.0과 Context
영상에서는 AI 시대의 개발을 Software 3.0이라는 관점으로 설명합니다.
| 구분 | 의미 |
| Software 1.0 | 사람이 직접 코드를 작성하는 방식입니다. |
| Software 2.0 | 데이터로 신경망을 학습시키는 방식입니다. |
| Software 3.0 | 프롬프트와 컨텍스트로 LLM을 프로그래밍하는 방식입니다. |
AI에게 일을 맡길 때 중요한 것은 단순히 말을 길게 하는 것이 아닙니다.
좋은 컨텍스트는 대화 내용을 계속 늘어놓은 일기장이 아니라, 작업 기준을 명확히 적은 계약서에 가까워야 합니다.
AI 에이전트에게 일을 맡길 때는 최소한 다음 세 가지를 명확히 해야 합니다.
| 조건 | 확인 내용 |
| 완료 조건 | 어떤 상태가 되면 작업이 끝났다고 볼 것인지 정합니다. |
| 금지 조건 | 수정하면 안 되는 파일, 사용하면 안 되는 방식, 피해야 할 변경을 정합니다. |
| 검증 조건 | 테스트, 실행 확인, 리뷰 기준을 정합니다. |
이 조건이 없으면 AI는 그럴듯한 결과를 만들 수는 있지만, 개발자가 원하는 방향에서 벗어날 수 있습니다.
5.5. 06:56 MenuGen과 Software 3.0
영상에서는 카파시가 만든 MenuGen 사례를 통해 앱의 역할 변화를 설명합니다.
MenuGen은 식당 메뉴판을 찍으면 음식 사진을 생성해 주는 앱입니다.
기존 방식으로 생각하면 프론트엔드, 백엔드, OCR, 이미지 생성 API 등 여러 구성 요소가 필요합니다.
하지만 AI 모델이 발전하면 일부 중간 단계는 모델 호출 하나로 흡수될 수 있습니다.
예를 들어 “메뉴판 사진 위에 음식 이미지를 바로 그려줘”와 같은 방식이 가능해질 수 있습니다.
그렇다고 앱이 사라진다는 뜻은 아닙니다.
앞으로 좋은 앱은 사람들이 직접 떠올리기 어려운 AI 작업 흐름을 사용하기 쉬운 형태로 포장하는 역할을 하게 될 수 있습니다.
앱의 역할 변화
앞으로의 앱은 단순히 화면과 기능을 제공하는 것을 넘어,
복잡한 AI 워크플로우를 사용자가 쉽게 활용할 수 있도록 돕는 경험의 포장지가 될 수 있습니다.
5.6. 08:34 Verifiability와 Jagged Intelligence
영상에서 강조하는 중요한 기준은 검증 가능성입니다.
AI는 코딩이나 수학처럼 정답, 테스트, 점수, 피드백이 명확한 영역에서 강점을 보입니다.
하지만 정답이 애매하거나 기준이 불명확한 영역에서는 결과가 들쭉날쭉할 수 있습니다.
이처럼 어떤 문제에서는 매우 똑똑해 보이지만, 다른 문제에서는 의외로 약한 모습을 보이는 특성을 Jagged Intelligence로 이해할 수 있습니다.
중요한 질문
“이 AI가 얼마나 똑똑한가?”보다
“이 작업은 검증 가능한가?”를 먼저 물어야 합니다.
검증 장치 없이 AI를 활용하면 겉보기에는 빠르게 결과물이 나올 수 있습니다. 하지만 시간이 지나면 오류, 보안 문제, 유지보수 문제로 이어질 수 있습니다. 이것은 결국 기술 부채가 됩니다.
5.7. 10:37 테스트와 System Model
AI 에이전트가 만든 코드는 문법적으로 틀릴 때보다, 겉보기에는 잘 돌아가는 것처럼 보일 때 더 위험할 수 있습니다.
예를 들어 로그인 이메일과 결제 이메일이 다를 때 권한이나 결제 기록이 어떻게 연결되는지, 사용자 데이터의 소유권은 어디에 있는지, 실패 상태에서는 어떤 처리를 해야 하는지 같은 문제는 단순 문법 오류보다 훨씬 깊은 문제입니다.
AI는 API 설정, 콜백 URL, 예제 코드 같은 표면적인 정보는 잘 찾을 수 있습니다. 하지만 개발자는 그 아래에 있는 System Model을 이해해야 합니다.
| System Model 요소 | 확인할 내용 |
| 권한 | 누가 어떤 데이터와 기능에 접근할 수 있는가? |
| 데이터 소유권 | 사용자 데이터는 누구에게 연결되고 어떻게 관리되는가? |
| 실패 상태 | 결제 실패, 로그인 실패, 네트워크 오류가 발생하면 어떻게 처리되는가? |
| 보안 경계 | 어디까지 사용자를 신뢰하고, 어디부터 검증해야 하는가? |
AI가 코드를 만들어 줄수록 개발자는 표면적인 코드보다 그 코드가 들어갈 시스템 전체를 더 깊이 이해해야 합니다.
5.8. 12:22 Agent-native Infrastructure
영상에서는 AI 에이전트가 실제 개발 과정에서 제대로 일하려면 그에 맞는 개발 환경과 인프라가 필요하다는 점도 다룹니다.
사람 개발자에게 맞춰진 도구만으로는 AI 에이전트가 안정적으로 작업하기 어려울 수 있습니다. 따라서 앞으로는 AI 에이전트가 코드를 읽고, 수정하고, 테스트하고, 피드백을 받을 수 있는 Agent-native Infrastructure가 중요해질 수 있습니다.
| 필요 요소 | 역할 |
| 명확한 작업 단위 | AI가 어디까지 수정해야 하는지 범위를 정합니다. |
| 자동 테스트 | AI가 만든 코드가 요구사항을 만족하는지 확인합니다. |
| 코드 리뷰 기준 | 코드 품질, 보안, 유지보수성을 검토합니다. |
| 실패 감지 구조 | AI 작업이 잘못된 방향으로 갔을 때 빠르게 발견합니다. |
즉, AI를 잘 쓰려면 단순히 AI 도구만 켜는 것이 아니라, AI가 안전하게 일할 수 있는 개발 구조를 함께 준비해야 합니다.
5.9. 12:52 배포와 운영 경계
AI가 코드를 만들 수 있다고 해서 배포와 운영의 책임까지 사라지는 것은 아닙니다.
실제 서비스에서는 코드 작성 이후에도 배포, 모니터링, 장애 대응, 보안 관리, 사용자 데이터 보호, 비용 관리 같은 운영 문제가 계속 발생합니다.
주의할 점
AI가 코드를 생성할 수는 있지만,
서비스 운영의 책임까지 대신 져 주지는 않습니다.
따라서 개발자는 AI가 만든 결과를 실제 서비스에 반영하기 전에 운영 환경에서 문제가 없는지 확인해야 합니다.
5.10. 13:28 이해는 아웃소싱할 수 없다
AI에게 리서치, 요약, 코드 작성, 테스트 초안 작성 같은 작업을 맡길 수 있습니다. 하지만 이해까지 맡길 수는 없습니다.
무엇을 만들어야 하는지, 왜 만들어야 하는지, 어디까지 AI의 결과를 믿을 수 있는지, 어떤 부분은 반드시 사람이 검토해야 하는지는 개발자가 이해하고 있어야 합니다.
You can outsource your thinking, but you cannot outsource your understanding.
생각의 일부는 AI에게 맡길 수 있지만,
이해까지 AI에게 맡길 수는 없습니다.
AI 시대 개발자의 병목은 타이핑 속도가 아닙니다. 이제 중요한 것은 이해의 깊이, 설계 능력, 검증 능력입니다.
5.11. 14:21 앞으로 개발자 격차가 나는 지점
영상의 마지막 부분에서는 앞으로 개발자 간 격차가 어디에서 생길지 설명합니다.
AI가 코드를 빠르게 만들어 주면 단순 타이핑 속도나 문법 암기만으로는 큰 차이를 만들기 어렵습니다. 오히려 앞으로는 다음 능력에서 개발자 간 격차가 커질 수 있습니다.
| 능력 | 설명 |
| 문제 정의 능력 | 무엇을 만들어야 하는지, 어떤 문제가 해결되어야 하는지 명확히 정리하는 능력입니다. |
| 컨텍스트 설계 능력 | AI에게 필요한 배경, 조건, 제한 사항을 정확히 전달하는 능력입니다. |
| 검증 능력 | AI가 만든 결과가 맞는지 테스트하고 확인하는 능력입니다. |
| 시스템 이해 능력 | 권한, 데이터 흐름, 실패 상태, 보안 경계를 이해하는 능력입니다. |
| 운영 책임 능력 | 배포 이후 발생하는 문제까지 고려하고 관리하는 능력입니다. |
신입 개발자가 배워야 할 점
AI 시대의 개발자는 단순히 코드를 많이 치는 사람이 아닙니다.
문제를 이해하고, AI에게 명확히 지시하고, 결과를 검토하고, 실제 서비스에 맞게 완성하는 사람이 되어야 합니다.
AI는 개발자를 없애는 기술이라기보다, 개발자가 더 높은 수준의 문제 해결자로 성장하도록 요구하는 기술입니다.