1
00:00:00,000 --> 00:00:02,000
프로젝트는 첫 커밋에서 시작하지 않습니다.

2
00:00:02,000 --> 00:00:06,000
The Pragmatic Programmer 7장은 그보다

3
00:00:06,000 --> 00:00:12,000
훨씬 전, 질문을 만들고 요구사항을 읽고 제약을 다시 보는 순간부터 프로젝트가 시작된다고 말합니다.

4
00:00:12,000 --> 00:00:14,000
이 장은 코딩 전의 사고법에 가깝습니다.

5
00:00:14,000 --> 00:00:16,000
가장 먼저 남은 말은 요구사항입니다.

6
00:00:16,000 --> 00:00:19,000
요구사항은 누군가 완성품으로 건네주는 것이 아닙니다.

7
00:00:19,000 --> 00:00:21,000
땅속에서 캐내야 하는 것입니다.

8
00:00:21,000 --> 00:00:24,000
문서에 적힌 문장은 대화의 끝이 아니라 흔적입니다.

9
00:00:24,000 --> 00:00:29,000
사용자가 진짜로 하려는 행동, 피하려는 위험, 이미 감수하고 있는 불편을 다시 물어야 합니다.

10
00:00:29,000 --> 00:00:32,000
불가능한 퍼즐을 다루는 태도도 중요했습니다.

11
00:00:32,000 --> 00:00:36,000
어떤 문제는 정말 어려워서 막히지만, 어떤 문제는 질문을 잘못 잡아서 막힙니다.

12
00:00:36,000 --> 00:00:40,000
제약 하나를 고정된 사실로 받아들이면 답이 없습니다.

13
00:00:40,000 --> 00:00:43,000
하지만 그 제약을 질문으로 바꾸면 다른 길이 보입니다.

14
00:00:43,000 --> 00:00:47,000
Not Until You're Ready라는 태도는 특히 마음에 남았습니다.

15
00:00:47,000 --> 00:00:51,000
준비되지 않았다는 감각을 무조건 게으름으로 보면 안 됩니다.

16
00:00:51,000 --> 00:00:53,000
때로는 정보가 부족하다는 신호입니다.

17
00:00:53,000 --> 00:00:55,000
물론 영원히 준비만 해서는 안 됩니다.

18
00:00:55,000 --> 00:01:01,000
하지만 설명할 수 없는 불편함이 있다면, 그것은 프로젝트가 아직 풀지 않은 질문을 가리킬 수 있습니다.

19
00:01:01,000 --> 00:01:04,000
명세의 함정도 지금의 AI 작업과 연결됩니다.

20
00:01:04,000 --> 00:01:07,000
명세가 길어도 검증으로 이어지지 않으면 문서 창고가 됩니다.

21
00:01:07,000 --> 00:01:12,000
좋은 명세는 사람과 에이전트가 같은 기준으로 움직이게 하는 하니스가 되어야 합니다.

22
00:01:12,000 --> 00:01:15,000
요구사항, 예시, 테스트, 완료 조건이 연결되어야 합니다.

23
00:01:15,000 --> 00:01:20,000
오늘의 적용은 새 기능 전에 사용자의 실제 행동 세 가지를 적는 것입니다.

24
00:01:20,000 --> 00:01:23,000
불가능해 보이는 제약 하나를 질문으로 바꾸는 것입니다.

25
00:01:23,000 --> 00:01:24,000
그리고 명세 문서마다

26
00:01:24,000 --> 00:01:26,000
검증 방법을 붙이는 것입니다.

27
00:01:26,000 --> 00:01:29,000
프로젝트 전의 좋은 질문은 프로젝트 중의 수많은 회의를 줄입니다.