1
00:00:00,000 --> 00:00:06,000
The Pragmatic Programmer의 마지막 장은 개인의 습관을 팀과 프로젝트로 확장합니다.

2
00:00:06,000 --> 00:00:12,000
앞의 장들이 좋은 개발자의 태도를 말했다면, 8장은 좋은 팀이 그 태도를 어떻게 반복 가능한 운영 체계로 만드는지

3
00:00:12,000 --> 00:00:13,000
묻습니다.

4
00:00:13,000 --> 00:00:15,000
가장 먼저 떠오른 것은 자동화입니다.

5
00:00:15,000 --> 00:00:18,000
자동화는 단순히 시간을 아끼는 도구가 아닙니다.

6
00:00:18,000 --> 00:00:19,000
팀의 기억입니다.

7
00:00:19,000 --> 00:00:22,000
사람이 매번 기억해야 하는 절차는 언젠가 빠집니다.

8
00:00:22,000 --> 00:00:27,000
빌드, 테스트, 배포, 문서 생성, 블로그 발행 같은 반복 작업은 자동화될수록 팀의 실수가 줄어듭니다.

9
00:00:27,000 --> 00:00:29,000
테스트도 마찬가지입니다.

10
00:00:29,000 --> 00:00:32,000
테스트는 불신의 표현이 아니라 자신감을 만드는 장치입니다.

11
00:00:32,000 --> 00:00:37,000
가혹할 만큼 꾸준한 테스트는 개발자를 느리게 만드는 것이 아니라, 바꿀 수 있는 용기를 줍니다.

12
00:00:37,000 --> 00:00:40,000
특히 AI가 만든 코드가 늘어날수록 테스트는 더 중요해집니다.

13
00:00:40,000 --> 00:00:43,000
생성 속도가 빨라질수록 검증 하니스도 빨라져야 합니다.

14
00:00:43,000 --> 00:00:47,000
이 장에서 가장 좋아하는 문장은 결국 모든 것이 글쓰기라는 생각입니다.

15
00:00:47,000 --> 00:00:53,000
커밋 메시지, 이슈, 명세, 테스트 이름, README, 블로그 글은 모두 팀이 생각을 공유하는 방식입니다.

16
00:00:53,000 --> 00:00:56,000
글을 못 쓰는 팀은 설계를 오래 유지하기 어렵습니다.

17
00:00:56,000 --> 00:00:59,000
코드 밖의 문장이 흐리면 코드 안의 의도도 흐려집니다.

18
00:00:59,000 --> 00:01:01,000
기대 관리도 제품 품질의 일부입니다.

19
00:01:01,000 --> 00:01:04,000
사용자는 단순히 기능을 받는 것이 아니라 약속을 받습니다.

20
00:01:04,000 --> 00:01:10,000
무엇이 가능하고 무엇이 아직 아닌지, 언제 어떤 품질로 도착하는지 설명하는 능력은 개발의 바깥일이 아닙니다.

21
00:01:10,000 --> 00:01:12,000
마지막으로 자부심입니다.

22
00:01:12,000 --> 00:01:13,000
자부심은 완벽주의가 아닙니다.

23
00:01:13,000 --> 00:01:16,000
내가 만든 결과물에 이름을 걸 수 있는가를 묻는 태도입니다.

24
00:01:16,000 --> 00:01:23,000
오늘 내가 적용할 행동은 반복 작업 하나를 자동화 목록에 올리고, 테스트 실패를 팀의 학습 기록으로 남기고, 커밋

25
00:01:23,000 --> 00:01:25,000
메시지와 문서를 조금 더 읽히게 다듬는 것입니다.

26
00:01:25,000 --> 00:01:27,000
실용주의 프로젝트는 개인의 재능보다

27
00:01:27,000 --> 00:01:29,000
팀의 반복 가능한 운영 습관에 기대어 오래 갑니다.