사용자가 필요로 하는 것 설명하기
사용자가 필요로 하는 것 설명하기 · 5분
대부분의 AI 교육은 더 나은 프롬프트를 작성하는 방법을 가르칩니다. 이는 훌륭한 제품을 만드는 데 필요하지만 충분하지는 않습니다. 이 레슨은 전체 Description Chain을 다룹니다: 복잡한 인간의 요구에서 AI가 실행할 수 있는 정확한 지시로 이어지는 경로이며, 빌더는 매 단계에서 번역가 역할을 합니다.
한국어 대본
- 00:00지난 모듈에서는 어떤 도구를 사용하기 전에 문제를 이해하는 데 실제 시간을 들였습니다.
- 00:10문제 설명을 작성하고, 인수 테스트를 작성했으며, 무엇을 직접 맡고
- 00:14무엇을 AI에 위임할지 결정했습니다. 이제 그 모든 내용을 AI가 실제로 행동으로 옮길 수 있는
- 00:20무언가로 바꿔야 합니다. 대부분의 AI 교육에서는 설명을 프롬프트 엔지니어링으로 다룹니다. 하지만
- 00:25여기서는 이 작업을 다르게 접근해, 명확하게 정의한 문제를 해결하는 데 도움이 되는 설명의 모든 측면을
- 00:30고려합니다. 설명은 높은 수준의 역량이며
- 00:35모델마다 달라질 수 있는 팁과 요령보다 오래 지속되어 계속 유효합니다.
- 00:43빌더의 도구함에 있는 여섯 가지 기능을 떠올려 보세요. 구현 전에
- 00:48사용자 요구를 정의해야 합니다. 전체 그림은 다음과 같습니다. 도구함의 기능과 직접 연결된 네 단계가 있으며
- 00:53빌더가 번역자 역할을 하면서
- 00:56각 단계의 중심이 됩니다.
- 00:57이미 작업 중인 프로젝트를 사용해 보겠습니다.
- 00:59첫 번째 단계는 사용자 목소리입니다.
- 01:01실제 사람이 실제로 말하는 내용입니다.
- 01:04예를 들어, 병원에 가기 전에 대기 시간을
- 01:06확인하고 싶다고 말할 수 있습니다.
- 01:08말투와 감정에 주목하세요. 말하지 않은 컨텍스트도 담겨 있습니다.
- 01:11화자는 소리 내어 말하지 않았습니다.
- 01:12이미 2시간이 지났고
- 01:14차 안에 아이가 있으며
- 01:15이 병원과
- 01:17도시 반대편의 응급 진료 중 하나를 고르고 있다는 사실입니다.
- 01:19공감 능력을 활용해 연결하고 관찰하세요.
- 01:21사용자가 말하지 않은 내용과
- 01:23사용자 목소리는 가공되지 않은 재료일 뿐입니다.
- 01:25사실이지만 아직 구현할 수 있는 형태는 아닙니다.
- 01:28따라서 두 번째 부분은 제품 요구사항입니다.
- 01:31여기서는 가공되지 않은 사용자 요구를
- 01:33측정 가능한 범위로 구체화합니다.
- 01:35예를 들어 환자는
- 01:37모바일 친화적인 웹페이지에서 예상 대기 시간을 확인할 수 있고
- 01:395분마다 업데이트될 수 있습니다.
- 01:41방금 무엇을 했는지 보입니까?
- 01:42결정을 내렸습니다.
- 01:44모바일 친화적이며 앱은 아닙니다.
- 01:46정확한 시간이 아니라 예상 시간입니다.
- 01:48실시간이 아니라 5분마다입니다.
- 01:51각각은 공감 작업에서 배운 내용을 바탕으로 내린 중요한 결정입니다.
- 01:56매우 명확하고 구체적인 기준을 마련하면 구현 단계에서 AI가 더 잘 작업하도록 도울 수 있습니다.
- 02:03세 번째 부분은 기술 사양입니다.
- 02:05이제 실제로 만드는 단계에 들어갑니다.
- 02:07예를 들어 웹 앱이 병원 API에서 대기 데이터를 가져와 반응형 UI로 표시하고, 5분 간격으로 새로 고칩니다.
- 02:15이것은 구현할 수 있습니다.
- 02:16엔지니어가 실제로 읽고 개발을 시작할 수 있습니다.
- 02:19AI도 마찬가지입니다.
- 02:20하지만 여전히 여지가 있다는 점에 주목하세요. 어떤 스택을 사용할지, 오류를 어떻게 처리할지, AI가
- 02:26AI가 중단되면 어떻게 할지까지입니다. 네 번째 단계는 AI 지침입니다. 제약 조건과 예외 사례를 포함해 구체적이고 컨텍스트에 맞게
- 02:32명확하게 정의해야 합니다. 사용하는 스택과 데이터 형태, 데이터가 없을 때 할 일까지
- 02:38통과해야 하는 테스트도 포함합니다. AI가 확인할 수 있는 구체적인 항목을 제공하는 것이 중요합니다.
- 02:43이렇게 하면 AI가 더 효과적으로, 더 오래 작업할 수 있습니다. 이것이 중요한 이유는 다음과 같습니다. 문제의
- 02:49모든 측면을 신중하게 설명하는 빌더가 AI에서 가장 좋은 결과를 얻습니다.
- 02:54설명이 사려 깊을수록 출력이 좋아집니다.
- 02:58AI는 사용자가 말하지 않은 내용을 들을 수 없습니다.
- 03:00AI는 예상 시간이 올바른 요구사항인지 결정할 수 없습니다. 정확한 시간을 제시하면
- 03:06병원 직원이 그 시간을 지켜야 한다는 압박을 받아 불안해할 수 있기 때문입니다.
- 03:08환자가 대기 시간을 확인하는 동안
- 03:12이동 중이기 때문에 반응성이 중요하다는 사실도 알 수 없습니다.
- 03:14그런 내용은 알고 있습니다.
- 03:15AI에 필요한 내용을 설명할 때 이러한 내용을 그대로 전달해야 합니다.
- 03:20때때로 이 변환 과정이 어긋나면 특정 유형의 실패가 발생합니다.
- 03:25코드는 작동하지만 제품은 작동하지 않는 경우입니다.
- 03:28테스트는 통과하지만 사용자는 여전히 불만족스럽습니다.
- 03:31이는 버그가 아니라 설명의 실패이며, 대개 프롬프트보다 앞선 단계에서 발생합니다.
- 03:37따라서 빌더의 업무에서 큰 부분은 실제로 포렌식 작업입니다.
- 03:40만든 것이 목표를 빗나가면 원인을 거슬러 추적합니다.
- 03:44사용자가 처음부터 무엇을 필요로 하는지
- 03:47제대로 듣지 못한 사용자 이해 실패였습니까?
- 03:48사용자의 말을 듣기는 했지만 범위를 잘못 정한 요구사항 실패였습니까?
- 03:53요구사항은 실제로 맞았지만 기술적 변환 과정에서
- 03:58무언가를 놓친 사양 실패였습니까?
- 03:59아니면 앞 단계는 모두 탄탄했지만 AI에 지시를 잘못한 프롬프트 실패였습니까?
- 04:05그럼 만들기 전에 한 가지 아이디어를 더 살펴보겠습니다.
- 04:07지난 모듈에서 작성한 인수 테스트도 설명의 한 형태이며, 어쩌면 가장
- 04:12강력한 형태일 수 있습니다.
- 04:13잘 작성된 테스트는 의도를 설명하며, 통과하거나
- 04:18실패하기 때문에 잘못 해석할 수 없습니다.
- 04:19프롬프트와 함께 여러 테스트를 AI에 전달하면, 무엇을
- 04:24만들어야 하는지만 알려 주는 것이 아니라 성공 여부를 어떻게 알 수 있는지도 알려 주는 것입니다.
- 04:27그러면 돌려받는 결과가 달라집니다.
- 04:29따라서 이 모듈에서는 클리닉 프로젝트를 활용해 AI를 위한 자세한 설명을 작성합니다. 제품 요구사항,
- 04:34기술 사양, 테스트, 프롬프트를 작성한 다음, 이
- 04:40코스에서 처음으로 실제로 빌드합니다.
- 04:42클리닉 환자 역할을 맡은 사람에게 무엇을 빌드하는지 시연하고, 두 가지 질문을 하게 됩니다. 첫째,
- 04:48테스트가 통과했습니까? 둘째, 사용자가 만족합니까? 첫 번째 답이 예
- 04:54이고 두 번째가 아니더라도 실패가 아닙니다. 이 모듈에서 일어날 수 있는 가장 유용한 일입니다. 이는
- 04:59테스트가 잘못된 대상을 설명했다는 뜻이며, 이제 체인의
- 05:04어느 지점을 살펴봐야 하는지 정확히 알 수 있습니다.
- 05:06이제 시작하겠습니다.
핵심 요점
- Description Chain은 사용자의 목소리를 요구사항, 기술 사양, AI 지시로 연결합니다. 프롬프트 엔지니어링은 그중 하나의 연결 고리일 뿐입니다.
- 빌더는 매 단계에서 번역가입니다. AI는 사용자가 말하지 않은 것을 들을 수 없습니다.
- 작동하지만 제품이 제대로 작동하지 않는 코드는 설명 실패입니다. 상류에서 어느 연결 고리가 끊어졌는지 찾아보세요.
- 테스트는 가장 정밀한 형태의 설명입니다. 테스트는 통과했지만 사용자가 불만족스럽다면, 잘못된 의도를 설명한 것입니다.
- 모든 단계에는 이전 단계가 대신 내려주지 않은 판단이 필요합니다.
실습
클리닉 대기 시간 프로젝트, 2부
지난 레슨에서 멈췄던 바로 그 지점부터 다시 시작합니다. 문제 개요, 위임 계획, 수락 테스트를 꺼내세요.
1단계: 제품 요구사항 작성하기
한 단락으로 작성하세요. 문제 개요에서 사용자 요구를 가져와 측정 가능한 것으로 범위를 정하세요. 모든 형용사는 여러분이 방어할 수 있는 결정이어야 합니다. "빠르다"라고 쓴다면, 얼마나 빠른지 쓰세요. "간단하다"라고 쓴다면, 주차장에서 휴대폰으로 확인하는 환자에게 간단함이 무엇을 의미하는지 설명하세요.
2단계: 기술 사양 작성하기
반 페이지로 작성하세요. 무엇이 만들어지고 어떻게 구조화되는지 설명하세요. 구성 요소의 이름을 붙이세요. 그것들이 서로 어떻게 통신하는지 이름을 붙이세요. 여기서는 AI를 증강 모드로 사용하세요: 제품 요구사항을 공유하고, 기술적 접근 방식을 제안하도록 요청한 다음, 제약 조건에 맞지 않는 부분에 대해 반박하세요.
3단계: 테스트를 정교하게 다듬기
이전 레슨의 수락 테스트를 다시 살펴보세요. 각 테스트가 코드가 통과하거나 실패할 수 있는 것이 되도록 다시 작성하세요. 최소 두 가지 엣지 케이스를 추가하세요: 클리닉이 문을 닫았을 때, 데이터가 없을 때, 대기 시간이 0일 때 어떤 일이 일어나는지.
4단계: AI 프롬프트 작성 및 빌드하기
사양을 작동하는 코드로 바꾸는 지시를 작성하세요. 제약 조건, 스택 선택, 테스트를 포함하세요. 첫 번째 버전을 빌드하세요.
5단계: 시연하기
파트너를 찾으세요. 그들은 클리닉 환자 역할을 합니다 — 아픈 아이가 있고 10분의 시간이 있습니다. 빌드한 것을 건네주고 사용하는 모습을 지켜보세요. 아무것도 설명하지 마세요. 돕지 마세요.
테스트는 통과했나요? 환자는 만족했나요? 이 답변들이 일치하지 않는다면, 체인의 어느 연결 고리로 돌아가야 할까요?
레슨 돌아보기
- Description Chain에서 어떤 번역 단계가 가장 자연스럽게 느껴지나요? 어떤 단계를 서둘러 넘어가는 경향이 있나요?
- 클리닉 시연에서, 의도한 것과 파트너가 경험한 것 사이의 가장 큰 차이는 어디에 있었나요?
다음 단계
다음 레슨에서는 설명에서 판별로 넘어갑니다. 여러분은 무언가를 만들었고 코드는 실행됩니다 — 이제 문제는 그것이 실제로 좋은지입니다.