한 사람과 한 순간
가장 먼저 도울 사람이 언제 이 문제를 겪는지 구체적으로 설명한다.
↗
Lecture blueprint
강의 목표와 전체 흐름
오늘의 목표는 새로운 개발 방법론을 하나 더 외우는 것이 아니다. AI가 구현의 많은 부분을 맡게 될 때도 사람이 끝까지 책임져야 하는 문제 선택 → 가치 판단 → 범위 결정 → 행동 검증을 연습하는 시간이다.
사용자가 얻을 변화
기능이 아니라 사용 전과 사용 후 무엇이 달라지는지 정의한다.
의도적으로 뺄 것
검증 전까지 만들지 않을 기능을 정해 제품의 질문을 선명하게 만든다.
행동으로 확인할 증거
좋다는 의견보다 실제 사용·재방문·예약 같은 강한 신호를 정한다.
| 경과 시간 | 분량 | 내용 | 진행 방식 |
|---|---|---|---|
| 00:00–00:10 | 10분 | AI가 다 만들 수 있다면 무엇이 문제인가 | 도발적 질문·개인 경험 |
| 00:10–00:25 | 15분 | 개발 방법론은 사라지는가 | 프롬프트·컨텍스트·명세·테스트 재해석 |
| 00:25–00:45 | 20분 | AI 시대에 인간에게 남는 것 | 문제 접근·판단·취향·신뢰 |
| 00:45–00:55 | 10분 | 휴식 | 질문 메모 받기 |
| 00:55–01:10 | 15분 | ‘모두를 위한 제품’이라는 함정 | MindLog·HCA 사례 비교 |
| 01:10–01:25 | 15분 | 6문장으로 제품의 이유 정하기 | 개인 작성·짝 피드백 |
| 01:25–01:35 | 10분 | 가장 중요한 가정과 증거 설계 | 검증 방법 선택 |
| 01:35–01:40 | 5분 | AI와 인간의 새로운 역할 분담 | 7일 행동 약속·마무리 |
| 01:40–02:00 | 20분 | 질의응답과 아이디어 클리닉 | 주제별 질문 |
오늘 강의의 관점
도구 사용법이나 유행하는 방법론을 나열하지 않는다. 20년 이상 데이터 시스템을 만들고 여러 AI 서비스를 직접 출시하면서 발견한 사실, 즉 구현이 쉬워질수록 문제를 고르는 능력과 현장을 이해하는 능력이 더 희소해진다는 점을 실제 사례로 다룬다.
1
00:00–00:10 · 10분
AI가 다 만들 수 있다면, 무엇이 문제인가
첫 10분은 기술 낙관론을 부정하는 시간이 아니다. 구현 능력이 평준화될수록 어떤 문제를 선택했는가가 더 중요해진다는 사실을 참가자가 스스로 발견하게 한다.
“누구나 비슷한 품질의 앱을 몇 시간 안에 만들 수 있다면, 내가 만든 앱을 사람들이 선택해야 할 이유는 무엇일까?”
무엇을 만들 수 있는가?
웹사이트, 앱, 자동화, 에이전트 가운데 지금 AI가 대신할 수 있는 일을 떠올린다.
무엇이 아직 어려운가?
코드 생성과 배포가 쉬워졌는데도 사용자가 생기지 않는 이유는 무엇인가?
나는 무엇을 더 잘 아는가?
내가 가까이에서 본 사람·현장·문제 가운데 AI나 일반 개발자가 놓치기 쉬운 것은 무엇인가?
발표자 노트 · 오프닝 멘트
“저 역시 지난 몇 년 동안 많은 서비스를 만들었다. 정식으로 출시한 것도 있고, 혼자 감탄하다가 멈춘 것도 많다. 최근에는 AI가 내 의도까지 어느 정도 알아서 구현하는 경험을 한다. 그래서 더 근본적인 질문을 하게 됐다. AI가 다 만들 수 있다면 나는 무엇을 해야 하는가?”
“오늘은 프롬프트 잘 쓰는 법을 가르치는 강의가 아니다. 기술이 계속 좋아져도 사람에게 남는 역할이 무엇인지, 그리고 여러분의 경험을 어떻게 제품의 차별점으로 바꿀지 함께 생각해 보겠다.”
2
00:10–00:25 · 15분
개발 방법론은 정말 사라지는가
사라지는 것은 방법론의 목적이 아니라, 사람이 그 절차를 일일이 수행하는 방식이다. AI가 내부에서 계획·검색·코딩·테스트를 수행해도 무엇이 맞는 결과인지는 저절로 정해지지 않는다.
| 방법론 | 점점 덜 중요해지는 것 | 끝까지 남는 핵심 |
|---|---|---|
| Prompt Engineering | 특정 표현과 주문 같은 요령 | 원하는 결과와 제약을 설명하는 능력 |
| Context Engineering | 자료를 사람이 매번 직접 넣는 작업 | 어떤 정보가 중요하고 믿을 만한지 판단하는 일 |
| Spec-driven | 코딩 전 수십 페이지 문서 작성 | 사용자·목표·범위·완료 조건 |
| Test-driven | 테스트 코드를 사람이 모두 먼저 작성 | 무엇이 맞고 틀린지를 정의하는 기준 |
| Harness | 모든 작업에 복잡한 에이전트 구조 적용 | 긴 작업에서 계획·기억·검증이 필요한지 판단 |
절차
작성·분해·테스트의 많은 부분을 AI가 대신하면서 방법론은 인터페이스 뒤로 숨는다.
기준
좋은 결과, 허용할 위험, 지켜야 할 경계를 정하는 일은 자동으로 생기지 않는다.
적응
실패가 관찰될 때만 필요한 구조를 추가하고, 모델이 좋아지면 다시 단순화한다.
방법론을 대하는 새로운 태도
방법론을 신앙처럼 지키지도, 모델이 좋아졌다는 이유로 모두 버리지도 않는다. 가장 강한 모델과 가장 단순한 방식으로 먼저 시도한 뒤, 실제 실패가 나타난 지점에만 명세·테스트·하네스를 추가한다.
3
00:25–00:45 · 20분
AI 시대에 인간에게 남는 것
구현 비용이 내려가면 제품의 희소성은 코드에서 다른 곳으로 이동한다. 인간의 역할은 AI보다 빨리 타이핑하는 것이 아니라, 현실의 의미를 읽고 선택의 결과를 책임지는 것이다.
현장 이해
특정 사람이 특정 순간에 겪는 불편을 관찰한다. 직접 경험, 관계, 직업적 맥락은 검색으로 쉽게 복제되지 않는다.
판단과 우선순위
무엇을 만들지보다 무엇을 만들지 않을지 정한다. 편리함·비용·안전·속도 사이의 충돌을 결정한다.
취향과 일관성
AI가 만드는 평균적으로 괜찮은 결과에 관점과 성격을 부여한다. 제품이 중요하게 여기는 것을 반복해서 드러낸다.
신뢰와 책임
정보가 틀렸을 때, 개인정보가 사용될 때, 누군가 손해를 볼 때 누가 어떤 원칙으로 대응할지 정한다.
차별점은 기능이 아니라 관계의 조합에서 나온다
문제에 대한 근접성얼마나 자주 직접 보거나 겪는 문제인가?
판단의 질무엇을 중요하게 보고 무엇을 버릴 것인가?
신뢰사용자는 왜 이 결과와 운영자를 믿어야 하는가?
실제 흐름과의 연결별도 앱을 배우지 않아도 기존 행동 속에 들어갈 수 있는가?
학습 속도사용자의 행동을 얼마나 빨리 관찰하고 수정할 수 있는가?
책임AI가 틀리거나 예상 밖의 일이 생겼을 때 누가 결정하는가?
차별점 = 문제에 대한 근접성 × 판단의 질 × 신뢰 × 사용자에게서 배우는 속도
발표자 노트 · 개인 경험 연결
데이터 엔지니어 경험만으로 만든 일반적인 AI 서비스와, HCA로 일하며 현장에서 본 문제를 바탕으로 만든 서비스가 어떻게 다른지 설명한다. 기술 역량만이 아니라 삶의 경험이 제품 자산이 되는 사례다.
참가자에게 “여러분이 가까이에서 본 문제 가운데 다른 개발자가 쉽게 모르는 것은 무엇인가?”라고 묻고 두세 명의 답을 듣는다.
Ⅱ
00:45–00:55 · 10분
휴식
화면에 남겨 둘 질문
“내가 가까이에서 본 문제 가운데 다른 사람이 쉽게 모르는 것은 무엇인가?” 질문을 화면에 남기고, 참가자는 자신의 경험을 한 문장으로 적는다.
4
00:55–01:10 · 15분
‘모두를 위한 제품’이라는 함정
모두가 사용할 수 있는 제품은 좋은 비전이 될 수 있다. 그러나 처음부터 모두를 대상으로 한 제품은 대개 아무에게도 절실하지 않다.
“누구나 생각을 기록하고 AI와 대화하는 앱”
대상도 상황도 넓어 기능 경쟁으로 흐르기 쉽다. 사용자가 지금 쓰는 메모·챗봇을 바꿔야 할 이유도 약하다.
“정리할 에너지가 없는 사람이 말 한마디로 다음 행동을 얻는 앱”
사용자·순간·변화가 보인다. 이 약속을 검증한 뒤 다른 사용자와 상황으로 넓힐 수 있다.
두 가지 실제 출발점
생각 정리가 필요한 구체적인 순간
이동 중이거나 지친 상태에서 긴 글을 쓸 수 없는 사람이 60초 안에 생각을 남기고, 핵심과 다음 행동을 확인한다.
업무 중 30초 안에 필요한 정보
워싱턴주의 Home Care Aide가 방문 돌봄 현장에서 규정과 절차를 빠르게 확인하고 안전하게 행동한다.
핵심 문장
“모두를 위한 것”은 출발점이 아니라 확장의 결과다. 한 사람의 구체적인 문제를 깊이 해결하고, 같은 문제가 다른 사람에게도 반복되는 것을 확인하면서 넓힌다.
5
01:10–01:25 · 15분
6문장으로 제품의 이유 정하기
AI에게 기능을 주문하기 전에 제품이 존재해야 할 이유를 여섯 문장으로 정한다. 이것은 긴 PRD가 아니라 인간이 내려야 할 결정의 최소 단위다.
1. 한 사람가장 먼저 도울 사람은 누구인가?
2. 한 순간그 사람은 언제 이 문제를 겪는가?
3. 한 문제지금 무엇 때문에 시간·돈·감정·기회를 잃는가?
4. 한 변화제품을 사용한 뒤 무엇이 달라져야 하는가?
5. 한 증거어떤 행동을 보면 가치가 있었다고 판단할 것인가?
6. 안 만들 것그 증거를 얻기 전까지 어떤 기능을 제외할 것인가?
[한 사람] ____________________이/가 [한 순간] ____________________할 때 [한 문제] ____________________ 때문에 겪는 어려움을 [한 변화] ____________________ 상태로 바꾸도록 돕는다. [한 증거] 우리는 사용자가 ____________________하는 행동을 보면 가치가 있다고 판단한다. [안 만들 것] 그 증거를 확인하기 전까지 ____________________은/는 만들지 않는다.
개인 작성과 짝 피드백
10분- 혼자 여섯 문장을 작성한다. 4분
- 짝에게 설명하고, 짝은 “왜 지금?”, “왜 이 사람?”, “왜 기존 방법으로 안 되는가?”만 질문한다. 4분
- 답하기 어려웠던 문장 하나를 고쳐 쓴다. 2분
발표자 노트 · 기능 목록을 받았을 때
참가자가 기능으로 답하면 기능을 지우게 하지 말고, 그 기능이 어떤 사람의 어떤 변화를 위해 필요한지 되묻는다. 핵심 흐름 전체가 검증에 필요하다면 한 번에 구현해도 된다.
문제는 여러 기능을 함께 만드는 것이 아니라, 확인하려는 가정과 무관한 기능을 계속 더해 제품의 질문을 흐리는 것이다.
6
01:25–01:35 · 10분
가장 중요한 가정과 증거 설계
여기서 중요한 가정은 보안 위험이라는 뜻이 아니다. 틀린 것으로 밝혀지면 제품을 만들 이유가 약해지는 사용자·가치 가정이다. 가정마다 필요한 증거가 다르므로 가장 싼 방법이 아니라 가장 적절한 방법을 고른다.
| 확인하려는 것 | 적절한 방법 | 강한 증거 |
|---|---|---|
| 문제가 실제로 자주 생기는가 | 최근 행동을 묻는 사용자 인터뷰 | 구체적인 사건, 반복, 손실 |
| 사용자가 흐름을 이해하는가 | 클릭 가능한 프로토타입 | 설명 없이 과업 완료 |
| 결과가 실제로 유용한가 | 사람이 일부를 대신하는 수동·반자동 파일럿 | 결과 사용, 재요청, 추천 |
| 반복 사용 이유가 있는가 | 완전한 핵심 흐름을 담은 최소 제품 | 자발적 재방문과 두 번째 행동 |
| 돈을 낼 만큼 중요한가 | 예약·선주문·유료 베타 | 실제 결제 또는 확정 예약 |
목업과 다르다
목업은 완성 화면의 모습을 보여주는 정적인 디자인이다. 클릭 가능한 프로토타입은 버튼과 화면을 연결해 사용 흐름을 체험하게 하지만 실제 데이터나 AI는 연결하지 않을 수 있다.
필요한 전체 흐름을 만든다
가정을 확인하는 데 ‘입력 → AI 정리 → 수정 → 저장 → 다시 열기’가 모두 필요하다면 한 번에 구현한다. 검증 전에는 페르소나·통계·알림·공유 같은 범위를 더하지 않는다.
1분 결정
1분내 제품을 만들 이유가 사라질 수 있는 가정 하나와, 그 가정을 가장 직접적으로 확인할 행동 증거 하나를 적는다.
7
01:35–01:40 · 5분
AI와 인간의 새로운 역할 분담
좋은 협업은 인간이 모든 절차를 직접 통제하는 것도, AI에게 모든 판단을 넘기는 것도 아니다. AI에게는 생성과 반복을 맡기고, 인간은 방향·기준·예외·책임을 소유한다.
- 대안과 패턴을 넓게 탐색한다.
- 화면·코드·테스트 초안을 만든다.
- 반복 작업과 오류 수정을 수행한다.
- 사용 데이터에서 가설을 제안한다.
- 누구의 어떤 문제를 풀지 선택한다.
- 허용할 위험과 지켜야 할 경계를 정한다.
- 사용자 행동을 보고 의미를 해석한다.
- 계속·수정·중단을 결정하고 책임진다.
AI 시대의 경쟁력은 더 잘 만드는 능력보다, 만들 가치가 있는 것을 알아보는 능력이다.
발표자 노트 · 마무리 전환
“프롬프트는 사라질 수 있지만 의도는 사라지지 않는다. 명세서는 짧아질 수 있지만 선택은 사라지지 않는다. 테스트 작성은 자동화될 수 있지만 성공 기준은 사라지지 않는다. 코드는 AI가 만들 수 있지만 무엇을 왜 만들지는 사람이 결정한다.”
Q&A에 들어가기 전, 참가자에게 앞으로 7일 안에 만날 사용자 한 명과 확인할 행동 하나를 적게 한다.
?
01:40–02:00 · 20분
질의응답과 아이디어 클리닉
질문을 특정 도구 사용법보다 아래 네 범주로 분류한다. 참가자의 아이디어를 대신 설계하기보다 다음 판단을 더 선명하게 만들어 준다.
내가 가까이에서 본 문제는 무엇인가
현장, 관계, 반복 관찰, 개인적 동기
무엇을 만들지 않을 것인가
범위, 우선순위, 가치 충돌, 책임
무엇을 보면 필요하다고 믿을 것인가
행동, 재사용, 예약, 결제, 추천
언제 더 넓은 사용자로 갈 것인가
반복 패턴, 공통 핵심, 개인화 경계
아이디어 클리닉 답변 공식
① 누구의 어떤 순간인지 좁힌다 → ② 기대하는 변화를 다시 말한다 → ③ 그 변화를 확인할 행동 증거를 고른다 → ④ 다음 7일에 실행할 한 가지를 정한다.
질문이 적을 때 사용할 준비 질문
- “AI가 사용자의 의도를 잘 이해한다면 명세가 정말 필요한가요?”
- “모두가 필요한 문제와 작은 타깃 문제 중 무엇을 선택해야 하나요?”
- “내 경험이 제품 차별점이 될 수 있는지 어떻게 알 수 있나요?”
- “좋다는 말과 실제 필요를 어떻게 구분하나요?”
- “AI가 더 좋아지면 지금 만든 앱이 기능으로 흡수되지 않을까요?”
- “처음 사용자 한 명은 어디에서 찾아야 하나요?”
✓
Take-home worksheet
AI 시대의 제품 판단 한 장
1. 한 사람가장 먼저 도울 사람은 누구인가?
2. 한 순간그 사람은 언제 이 문제를 가장 선명하게 겪는가?
3. 한 문제무엇 때문에 시간·돈·감정·기회를 잃는가?
4. 한 변화사용 전과 사용 후 무엇이 달라져야 하는가?
5. 현재 대안지금은 어떻게 해결하며 왜 충분하지 않은가?
6. 한 증거어떤 행동을 보면 가치가 있었다고 판단할 것인가?
7. 안 만들 것증거를 얻기 전까지 어떤 기능을 제외할 것인가?
8. 7일 행동누구를 만나 무엇을 관찰할 것인가?
마지막 30초
내가 다음으로 만들 기능은 ______이 아니다. 먼저 만나야 할 사람은 ______이고, 확인할 행동은 ______이다.