이 과정을 학습하는 방법
특별한 감사
이 튜토리얼의 핵심 기여자와 테스터는 칭화대학교 선전국제대학원 학생들입니다. 실제 학습과 조작 과정에서 계속 문제를 찾고, 제안하고, 수정에 참여해 주신 덕분에 강의가 더 명확하고 믿을 만하며 초보자의 실제 필요에 가까워졌습니다. 👉 전체 기여자 보기
예전에는 소프트웨어를 만드는 문턱이 높았습니다. 아이디어를 실행 가능한 프로그램으로 바꾸기 전에 프로그래밍 언어, 개발 도구, 많은 기술 지식을 배워야 했습니다. 대규모 언어 모델과 AI 코딩 도구는 이를 바꿨습니다. 이제 사람은 자연어로 의도를 설명하고 AI에게 코드 생성, 화면 구성, 기능 수정을 부탁할 수 있습니다.
Vibe Coding에서 제품 만들기로
Vibe Coding이라는 표현은 2025년 2월 2일에 등장했습니다. AI 연구자 Andrej Karpathy는 사람이 자연어로 원하는 것을 말하고, 실행 결과를 본 뒤 대화와 수정을 이어 가며, 처음부터 모든 코드를 직접 작성하고 이해하고 관리하지 않아도 되는 새로운 개발 방식을 이렇게 표현했습니다.
Vibe Coding이란 무엇인가요? 간단히 말해 “말로 프로그래밍하기”입니다. 아이디어를 설명하고, AI가 프로그램을 만들게 하고, 실행한 뒤 대화로 계속 다듬습니다.
가장 먼저 생긴 변화는 “코드를 못 쓰니 시작할 수 없다”는 장벽을 더 많은 사람이 넘게 된 것입니다. 프로그래밍 경험이 없어도 몇 분 만에 작은 게임, 웹페이지, 시연 가능한 프로토타입을 만들 수 있습니다.
이는 큰 변화입니다. 사람과 컴퓨터의 소통이 엄격한 프로그래밍 문법에서 자연어로 넓어지고 있습니다.
하지만 실행되는 데모를 쉽게 만들수록 새로운 질문이 생깁니다.
- 만들 수 있는 것이 아니라 무엇을 만들어야 하는가?
- 누구의 문제를 해결하며, 그 사람이 정말 필요로 하는가?
- AI가 만든 첫 버전을 안정적이고 이해하기 쉬우며 계속 수정 가능한 제품으로 어떻게 바꿀까?
- 내 컴퓨터에서만 실행하지 않고 사용자에게 어떻게 전달할까?
- 사용, 피드백, 결제로 실제 가치를 만들었다고 어떻게 증명할까?
Vibe Coding은 학습을 없애지 않았습니다. 배울 내용을 바꾸고 요구 수준을 높였습니다.
코딩만 보면 목표는 코드를 실행하는 것입니다. 제품을 만든다면 문제에서 결과까지 전체 과정에 책임을 져야 합니다.
Coding: 만들 수 있는가?
Build Product: 만들 가치가 있는가, 누가 쓰는가, 어떻게 전달하며, 효과가 있음을 어떻게 아는가?
Vibe Coding은 이 과정의 출발점이지 종착점이 아닙니다. 먼저 빠르게 무언가를 만든 뒤 문제 선택, 수요 검증, 해결안 설계, 제품 제작, 사용자 접촉, 결과에 따른 반복을 배웁니다.
이 과정이 정말 키우려는 능력은 무엇인가요?
AI 코딩 도구 사용법만 배우는 과정이 아닙니다. 문제를 찾고, 수요를 검증하고, 직접 제품을 만들고, 실제 사용자에게 전달하고, 결과에 따라 개선할 수 있는 기초적인 프로덕트 엔지니어(Product Engineer)가 되도록 돕습니다.
왜 지금 프로덕트 엔지니어가 필요한가요?
프로덕트 엔지니어는 2026년에 갑자기 생긴 직업이 아닙니다.
Intercom은 이미 2018년에 Product Engineer를 제품 주인의식을 가진 엔지니어라고 설명했습니다. 다른 사람이 설계한 기능을 구현하는 데 그치지 않고 고객을 이해하고 제품 판단에 참여하며 자신이 전달한 제품을 계속 개선합니다.
AI는 “만드는” 비용을 크게 낮추고, 과거 여러 역할이 나누어 하던 일을 엔지니어가 맡을 기회를 늘렸습니다. 대규모 모델과 코딩 에이전트를 이용하면 한 사람이 프로토타입, 화면, 프런트엔드와 백엔드, AI 연결, 테스트, 배포를 넘나들 수 있습니다. 역할은 “코드를 끝낸다”에서 더 나아가 사용자를 직접 이해하고, 해결안을 검증하고, 사용을 이끌고, 비즈니스 결과에 책임지는 쪽으로 넓어집니다.
“제품에 참여”에서 “결과에 책임”으로
실제 시점을 통해 이 변화를 살펴봅시다.
| 시기 | 회사와 역할 | 역할이 보여 주는 변화 |
|---|---|---|
| 2018년 5월 | Intercom: Product Engineer | 엔지니어도 제품을 이해하고 고객을 만나며 제품의 발전 방향을 함께 결정한다 |
| 2026년 2월 | Hamilton AI: Product Engineer | 고객과 직접 이야기하고 한 번의 대화를 사용 가능한 제품으로 바꾸어 실제 사용자에게 검증한다 |
| 2026년 6월 | Alma: Product Engineer - AI | 한 사람이 에이전트, 백엔드, 화면을 만들고 변호사와 고객의 사용을 관찰한다 |
| 2026년 7월 | Harper: Product Engineer | 영업, 지원, 보험 인수 현장에 들어가 기능 출시뿐 아니라 전환율 같은 지표에 책임진다 |
| 2026년 8월 | Paradigm: Product Engineer, Applied AI | 투자, 연구, 운영 팀에서 문제를 찾고 내부 및 오픈소스 제품을 만든다 |
| 2026년 8월 기준 | OpenAI: Forward Deployed Engineer | 문제 발견, 기술 계획, 시스템 제작, 운영 배포까지 책임지고 사용률과 업무 영향으로 성공을 측정한다 |
여러 산업의 실제 역할 더 보기
항공, 법률, 보험, 금융 규제, 생명과학, 산업, 기업 서비스, AI 인프라에 걸친 사례입니다.
| 게시 시기 | 회사와 역할 | 완성해야 하는 과정 |
|---|---|---|
| 2026년 2월 | Sphinx: Product Engineer | 고객 대화에서 기회를 선택하고 빠르게 프로토타입과 테스트를 진행해 결과로 로드맵에 영향을 준다 |
| 2026년 3월 | Hyperscale: Founding Forward Deployed Engineer | 기술 조사, PoC, 현장 구현, 기업 영업에 참여한다 |
| 2026년 4월 | Sphere: Founding Forward Deployed Engineer | 고객 발견부터 배포까지 진행하고 고객 요구를 공통 제품 능력으로 만든다 |
| 2026년 5월 | Avent: Founding Forward Deployed Engineer | 고객 업무를 이해하고 코드를 쓰고 시스템을 연결하며 성공적인 도입에 책임진다 |
| 2026년 5월 | Tamarind Bio: Founding Forward Deployed Engineer | 첫 기술 대화, 파일럿, 운영 배포, 확장, 데모, 영업 과정을 다룬다 |
| 2026년 6월 | Protege: Forward Deployed Engineer, New Verticals | 초기 고객 요구에서 새 사업을 만들고 성공한 방식을 플랫폼 능력으로 남긴다 |
| 2026년 6월 | Dataleap: Founding Forward Deployed Engineer | 기업 현장에서 중요한 흐름을 찾고 에이전트를 만들고 연동하고 고객에게 사용법을 가르친다 |
| 2026년 6월 | Collinear AI: Product Engineer | 백엔드, 프런트엔드, API, 사용자 경험, 테스트, 운영 품질을 넘나든다 |
| 2026년 7월 | Restate: Forward Deployed Engineer | PoC, 운영 준비, 배포에 책임지고 일회성 전달을 반복 가능한 방식으로 만든다 |
| 2026년 8월 기준 | Scale AI: Forward Deployed Engineer, GenAI | 기술 고객과 직접 일하고 전체 개발과 빠른 실험으로 제품 로드맵에 영향을 준다 |
조사 시점
이 페이지는 2026년 8월 9일에 정리했습니다. 날짜가 있는 Ashby 채용은 공개 채용 데이터의 publishedAt을 사용했고, 날짜를 제공하지 않는 회사 페이지는 확인 날짜를 기준으로 했습니다. 채용이 끝나면 페이지가 사라질 수 있습니다.
위 내용은 실제 역할 몇 가지를 관찰한 것이며 전체 고용 시장의 통계가 아닙니다. AI 네이티브 회사와 작은 제품 팀에서 나타나는 능력 방향을 설명할 뿐, 모든 회사가 제품, 디자인, 개발, 영업의 전문 분업을 없앤다는 뜻은 아닙니다.
이러한 역할은 어떻게 달라지고 있나요?
- 일의 출발점: 작성된 요구를 기다리지 않고 사용자와 업무 현장에 들어가 문제를 찾는다.
- 프로토타입의 역할: 기술을 보여 주는 데 그치지 않고 빠르게 사용자에게 전달해 판단을 검증한다.
- 엔지니어링 범위: 한 기술 모듈에서 화면, 백엔드, AI, 배포, 사용자 경험으로 넓어진다.
- 성공 기준: “기능 출시”에서 사용률, 효율, 전환율, 매출, 실제 영향으로 바뀐다.
- 영업과의 관계: 일부 프로덕트 엔지니어는 데모, PoC, 고객 도입에 참여해 기술로 가치를 증명한다.
여기서 “영업할 줄 안다”는 모든 사람이 전통적인 영업 사원이 되어야 한다는 뜻이 아닙니다. 제품이 필요할 사람을 찾고, 문제를 이해하고, 해결책을 보여 주고, 사용을 권하고, 계속 사용할지 또는 비용을 낼지 확인하는 능력입니다.
Product Engineer, FDE, OPC는 어떤 관계인가요?
세 개념은 같은 능력 사슬에 있지만 같은 것은 아닙니다.
| 개념 | 무엇인가 | 주요 현장 | 어디까지 책임지는가 |
|---|---|---|---|
| Product Engineer | 제품과 엔지니어링을 결합한 역할 | 제품 팀 내부 | 문제와 해결안에서 출시, 사용자 피드백, 비즈니스 지표까지 |
| FDE(Forward Deployed Engineer) | 프로덕트 엔지니어링을 고객 현장으로 확장한 역할 | 기업 고객, 실제 업무, 운영 환경 | 고객 발견, PoC, 연동, 배포, 사용, 확장, 때로는 영업 과정까지 |
| OPC(One-Person Company) | 한 사람이 주도하는 회사 운영 방식이며 직함이 아님 | AI 에이전트, 자동화, 외부 서비스로 한 사람이 제품을 운영 | 시장, 제품, 마케팅, 영업, 전달, 지원, 현금 흐름까지 |
순서대로 승진해야 하는 경력 사다리가 아니라, 같은 프로덕트 엔지니어링 능력이 다룰 수 있는 범위의 차이입니다.
점점 커지는 세 개의 원으로 이해할 수 있습니다.
Product Engineer: 올바른 제품을 실제로 만든다
FDE: 제품을 고객 현장에 넣어 결과를 만든다
OPC: 같은 능력으로 완전한 사업을 운영한다
FDE: 엔지니어가 고객 현장에 들어갑니다
FDE는 소프트웨어 설치만 하는 구현 담당자도, 시연만 하는 사전 영업 엔지니어도 아닙니다. AI 회사의 FDE는 보통 네 가지를 함께 합니다.
- 고객과 함께 가장 해결할 가치가 큰 문제를 찾는다.
- 빠르게 프로토타입이나 PoC를 만들어 기술과 사업 가치를 증명한다.
- 운영 코드를 작성하고 고객의 실제 데이터와 업무 흐름에 연결한다.
- 사용 결과를 관찰하고 반복되는 요구를 공통 제품 능력으로 만든다.
2026년 8월 기준 OpenAI는 여러 국가와 도시에서 FDE를 채용하고, 운영 사용률, 측정 가능한 업무 영향, 제품과 모델 로드맵을 바꾸는 현장 피드백을 성공 기준으로 제시했습니다. FDE는 일부 기업 소프트웨어 회사의 특별한 방식에서 AI 도입의 중요한 역할로 넓어지고 있습니다.
OPC: 한 사람도 “디지털 팀”을 가질 수 있습니다
여기서 OPC는 법적인 1인 회사만 뜻하지 않습니다. One-Person Company: 한 사람이 중심이 되어 소프트웨어, AI 에이전트, 외부 인프라를 활용하고 과거 여러 사람이 하던 일을 수행하는 회사 운영 방식입니다.
AI가 전부 자동 운영하는 “무인 회사”도 아닙니다. 창업자는 시장을 판단하고, 책임지고, 사용자를 만나고, 중요한 결정을 해야 합니다. AI는 업무를 배정할 수 있는 디지털 팀에 가깝습니다.
이 흐름은 AI에서 시작된 것이 아닙니다. 독립 개발자 Pieter Levels는 Nomads.com, Remote OK, Photo AI, Interior AI 등을 오랫동안 혼자 만들고 운영했다고 소개합니다. AI는 디자인, 개발, 콘텐츠, 분석, 지원까지 범위를 넓히지만 제품 가치는 결국 실제 시장에서 검증해야 합니다. Pieter Levels의 프로젝트 기록
2025년 Microsoft Work Trend Index는 AI 에이전트를 만들고, 위임하고, 관리하는 사람을 Agent Boss라고 불렀습니다. 31개국 31,000명을 조사했으며, 리더의 81%는 향후 12~18개월 안에 에이전트를 AI 전략에 중간 또는 깊은 수준으로 통합할 것으로 예상했습니다. Microsoft 2025 Work Trend Index
2025년 6월 Wix는 자연어 앱 개발 플랫폼 Base44를 약 8천만 달러에 인수했습니다. Base44가 엄밀한 OPC는 아니지만, 데이터베이스, 인증, 배포처럼 여러 전문 역할이 필요했던 일이 대화형 제품 안에 묶이고 자동화되는 중요한 조건을 보여 줍니다. Wix 인수 발표
“첫 1인 유니콘이 언제 나올까”는 아직 예측이며 이미 일어난 사실이 아닙니다. 초보자에게 더 중요한 현실은 한 사람이 적은 자금과 작은 팀으로 제품을 더 빠르게 검증하고, 작지만 실제 수익을 내는 사업을 운영할 수 있다는 것입니다.
왜 세 경로를 함께 설명하나요?
제품 팀에 들어가든, FDE가 되든, OPC를 시도하든 출발점은 같습니다. 실제 문제를 찾고, 가장 작은 제품을 만들고, 사용자에게 전달하고, 가치를 설명하고, 사용과 결제 결과에 따라 반복합니다.
따라서 이 과정은 서로 떨어진 직함이 아니라 하나의 제품 순환을 훈련합니다.
문제 발견 → 수요 검증 → 해결안 설계 → 제품 제작 → 사용자 전달 → 가치 설명 → 결과 관찰 → 반복 개선
AI에게 코드를 쓰게 하는 것은 첫 단계입니다. 실제로 쓸 수 있는 제품은 더 많은 질문을 만듭니다.
- AI에게 깔끔하고 유지하기 쉬운 코드를 쓰게 하려면?
- 흩어진 코드를 실행 가능한 앱으로 묶으려면?
- 앱을 실제로 공개해 사람이 사용하게 하려면?
- 텍스트 생성과 이미지 이해 같은 AI 기능을 제품에 넣으려면?
- 사용자가 정말 필요로 하고 비용까지 낼 수 있는지 어떻게 확인할까?
이 질문의 답을 과정에서 순서대로 배웁니다.
학생, 교사, 의사, 작업자, 기술을 전혀 모르는 사람도 첫 제품 프로토타입을 시작하기 전에 몇 년 동안 프로그래밍을 배울 필요는 없습니다.
| 현재 역할 | 이 과정이 도와주는 일 |
|---|---|
| 학생 | 과제, 대회, 창업 프로젝트를 직접 만든다 |
| 직장인 | 반복 작업을 자동화하고 효율을 높이며 부업도 시도한다 |
| 프로덕트 매니저 / 디자이너 | 아이디어를 데모로 만들고 실제 사용자에게 전달한다 |
| 창업가 / 중소기업 운영자 | 큰 팀을 꾸리기 전에 적은 비용으로 MVP를 검증한다 |
| 교사 / 교육자 | 교육 도구, 수업 자료, 자동 문제를 만든다 |
| 의사 / 변호사 / 전문가 | 전문 업무를 자동화하고 개인 효율 도구를 만든다 |
| 누구나 | AI로 생활과 업무의 구체적인 문제를 해결한다 |
AI는 구현 비용을 낮추지만, 제품 가치는 실제 문제를 찾고 해결책을 사용자에게 전달할 수 있는지가 결정합니다.
성장 경로: “AI 사용”에서 “프로덕트 엔지니어”로
첫 경험
AI 코딩 체험
Stage 1
프로덕트 엔지니어 입문
Stage 2
풀스택 프로덕트 엔지니어
Stage 3
AI 프로덕트 엔지니어 / 기술 책임자
이 전체 학습 경로를 지나면 다음 능력을 얻습니다.
- Vibe Coding 개발 능력: AI 코딩 도구를 능숙하게 사용하고 문법 암기보다 AI를 잘 안내해 품질 좋은 코드를 만든다.
- 풀스택 개발 기술: UI, 프런트엔드, 데이터베이스, API, 로컬 개발, 클라우드 배포까지 다룬다.
- AI 기능 연결: 텍스트, 이미지, 음성의 멀티모달 API를 연결하고 이후 RAG 같은 기술로 지능형 제품을 만든다.
- 제품과 운영 사고: 사용자 조사, 수요 분해, MVP, 반복, 결제, 사용자 관리까지 배운다.
학습 후 무엇을 할 수 있나요?
Stage 1: 첫 제품 프로토타입 만들기
프로그래밍을 전혀 모르거나 조금 알지만 자신 없는 사람을 위한 단계입니다. 많은 이론부터 배우지 않고, 만들면서 AI에게 코드를 쓰게 하고 오류를 고치는 법을 익힙니다.
이 단계를 마치면:
- AI 코딩 도구로 웹앱 하나를 독립적으로 완성할 수 있습니다.
- 제품 아이디어를 클릭하고 조작할 수 있는 프로토타입으로 바꿀 수 있습니다.
- 이미지 생성이나 지능형 대화 같은 AI 기능을 넣을 수 있습니다.
- 오류가 생겼을 때 원인을 조사하고 해결할 수 있습니다.
한마디로 실행되고 다른 사람에게 보여 줄 수 있는 것을 만들게 됩니다.
작은 게임으로 AI 코딩을 체험한 뒤 도구로 코드 작성과 오류 수정을 배웁니다. 단순한 페이지에서 상호작용하는 여러 페이지 앱으로 나아가고, AI 기능을 추가하고, 마지막에는 독립 프로젝트를 완성합니다.
왜 프로젝트 방식으로 훈련하나요?
현실 업무의 어려움
실제 직장에서는 목표만 주어지고 완성된 문서, 기존 틀, 상세 요구가 없는 경우가 많습니다.
상사나 고객: xxx를 만들고 yyy 효과를 달성해야 합니다.
문서? 준비된 프레임워크? 상세한 요구서? 없는 때가 많습니다.
실제 업무는 불확실한 환경에서 처음 보는 문제를 해결하는 일입니다. 요구는 모호하고 경계는 바뀌며 표준 답은 없습니다. 자료를 찾고, 실험하고, 프로토타입을 만들고, 반복한 뒤 실행되고 쓸 수 있으며 배포 가능한 해결책을 전달해야 합니다.
이 과정은 안전한 환경에서 그 경험을 미리 제공합니다.
- 조금 어려운 프로젝트로 문제 분해, 해결안 설계, 자료 찾기를 연습합니다.
- 지나치게 단순화하지 않은 코드로 중간 규모 코드베이스를 읽고 바꾸는 법을 배웁니다.
- 아이디어에서 출시까지 전체 과정을 통해 실제 제품의 0에서 1을 경험합니다.
단기에는 힘들 수 있지만, 책임지는 힘, 불확실성 속에서 길을 찾는 힘, AI를 데모가 아닌 실제 제품으로 만드는 힘을 길러 줍니다.
질문의 기술: AI 시대의 기본 능력
질문은 기본 능력입니다. 같은 코드와 오류라도 어떻게 묻는가가 답을 거의 결정합니다. 막연한 설명을 받을지, 실행 가능한 단계를 받을지가 달라집니다.
습관 만들기: AI에게 묻는 일을 개발 과정의 일부로 두세요. 모르거나 막히면 바로 질문합니다.
왜 꼭 필요한 능력인가요?
- 현실에는 완전한 문서가 드뭅니다: 모호한 요구, 미완성 코드, 흩어진 오류를 만납니다.
- AI는 곁의 교사이자 동료가 됩니다: 좋은 질문은 고품질 페어 프로그래밍을 만듭니다.
- 소통이 능력의 상한을 정합니다: 중요한 맥락과 출력 조건을 많이 줄수록 답을 쓰기 쉽습니다.
흔한 실수: “왜 오류야?”만 물으면 추측이 돌아옵니다. 맥락을 채워야 실행 가능한 방법을 얻습니다.
AI에 정보를 주는 방법: 스크린샷과 복사
둘 다 가능하지만 쓰임이 다릅니다.
| 방법 | 적합한 상황 | 핵심 요구 |
|---|---|---|
| 복사하여 붙이기 | 오류 스택, 로그, 코드, 설정, API 응답 | 관련 내용을 온전히 주고 한 줄만 잘라 보내지 않기 |
| 스크린샷 | UI 배치, 조작 문제, 도구에서 버튼을 못 찾는 경우 | 주변 맥락도 찍고 중요한 곳을 표시하며 한 문장 덧붙이기 |
⚠️ 중요한 조건
모든 AI가 이미지 입력을 지원하는 것은 아닙니다. 스크린샷으로 소통하려면 이미지를 이해하는 멀티모달 모델이 필요합니다. Claude, GPT-4V/GPT-4o, Gemini, Qwen, ERNIE Bot 등이 있습니다.
사용 중인 AI가 이미지를 받지 못한다면 스크린샷을 이해하지 못합니다. 대신 글을 복사하여 전달하세요.
AI가 잘 설명하도록 만드는 프롬프트
답만 받지 않고 이해하고 싶다면 이런 지시가 도움이 됩니다.
학습용 예시
- “이 개념을 먼저 다섯 문장으로 설명하고, 이해했는지 확인할 질문을 해 주세요.”
- “이 오류가 왜 생겼는지 자세히 설명해 주세요.”
오래 해도 해결되지 않아 포기하고 싶어요
지속하는 방식이 맞지 않을 수 있습니다. 혼자 버티지 말고 저자와 조교에게 시도한 방법, 구체적으로 막힌 곳, 현재 마음을 솔직히 이야기하세요. 방향을 조금 바꾸거나 빠진 지식 하나를 채우면 다시 진행할 수 있습니다.
튜토리얼 설계가 불합리하다고 느껴요
저자에게 연락하고, Issue를 만들고, 수업이나 커뮤니티에서 의견을 주세요. 불명확한 곳, 경험이 좋지 않은 곳, 시간을 낭비한 곳을 구체적으로 말해 주세요. 솔직한 피드백은 다음 학습자의 시행착오를 줄입니다.