1
00:00:00,000 --> 00:00:01,000
안녕하세요.

2
00:00:01,000 --> 00:00:04,000
책을 읽고 난 뒤, 무엇이 남았는지 이야기하는 시간입니다.

3
00:00:04,000 --> 00:00:09,000
요즘 AI가 코드를 뚝딱 만들어내는 시대에, 개발자에게는 무엇이 중요할까요?

4
00:00:09,000 --> 00:00:15,000
단순히 최신 기술을 아는 것보다, 어떤 사고 습관과 운영 기준을 가져야 할지, 저는 늘 고민하고 있습니다.

5
00:00:15,000 --> 00:00:21,000
이런 질문을 안고, 앤드류 헌트와 데이비드 토마스의 『실용주의 프로그래머』 두 번째 읽기를 시작했습니다.

6
00:00:21,000 --> 00:00:22,000
사실 처음

7
00:00:22,000 --> 00:00:26,000
이 책을 집었을 때는, 좀 오래된 조언들이 모여 있을 거라고 예상했어요.

8
00:00:26,000 --> 00:00:32,000
하지만 읽으면 읽을수록, 이 책은 최신 도구에 대한 이야기가 아니라, 오래도록 변치 않는 개발자의 운영 체계,

9
00:00:32,000 --> 00:00:38,000
그러니까 '소프트웨어를 어떻게 바뀔 수 있게 만들 것인가'를 묻고 있다는 걸 깨달았습니다.

10
00:00:38,000 --> 00:00:43,000
기술의 변화 속도가 빨라질수록, 오히려 이런 본질적인 질문이 더욱 중요해지는 것 같아요.

11
00:00:43,000 --> 00:00:48,000
이번 두 번째 읽기에서 제가 가장 집중했던 부분은 바로 '중복을 줄이고 바뀔 수 있게 만들기'였습니다.

12
00:00:48,000 --> 00:00:54,000
책은 좋은 설계란 오늘의 답을 박제하지 않고, 내일의 변경권을 남겨두는 것이라고 말합니다.

13
00:00:54,000 --> 00:01:00,000
우리가 만드는 소프트웨어가 처음부터 완벽할 수 없다는 것을 인정하고, 변화에 유연하게 대응할 수 있는 힘을 어디에

14
00:01:00,000 --> 00:01:03,000
남겨둘 것인가에 대한 깊은 통찰을 제공하죠.

15
00:01:03,000 --> 00:01:06,000
특히 제 마음을 사로잡았던 세 가지 개념이 있습니다.

16
00:01:06,000 --> 00:01:07,000
첫째는 'DRY' 원칙입니다.

17
00:01:07,000 --> 00:01:14,000
흔히 "똑같은 코드를 두 번 치지 마라"는 표면적인 조언을 넘어, '지식의 단일 출처'를 지키는 원칙이라는 거죠.

18
00:01:14,000 --> 00:01:19,000
같은 정책이나 규칙이 여러 장소에서 서로 다르게 자라나는 것이, 똑같은 코드가 두 번 있는 것보다

19
00:01:19,000 --> 00:01:22,000
훨씬 위험하다는 말에 정말 공감했습니다.

20
00:01:22,000 --> 00:01:28,000
프로젝트에서 여러 팀원이 각자의 방식으로 동일한 규칙을 해석하고 구현할 때 생기는 혼란을 떠올려보면, 이 원칙의

21
00:01:28,000 --> 00:01:30,000
중요성을 더욱 실감하게 됩니다.

22
00:01:30,000 --> 00:01:31,000
둘째는 '직교성'입니다.

23
00:01:31,000 --> 00:01:35,000
한 부분의 변화가 다른 부분을 흔들지 않게 만드는 힘을 말하는데요.

24
00:01:35,000 --> 00:01:40,000
특히 AI 에이전트 개발에 몰두하고 있는 제게는 이 '직교성'이 아주 와닿았습니다.

25
00:01:40,000 --> 00:01:46,000
도구, 프롬프트, 데이터, 검증 로직이 서로 엉켜 있으면, 에이전트가 한 번 실패할 때 전체 루프가 무너지는 경험을

26
00:01:46,000 --> 00:01:47,000
자주 하거든요.

27
00:01:47,000 --> 00:01:54,000
각 요소를 독립적으로 나눌 수 있어야만, 문제가 생겼을 때 고치기도 쉽고, 새로운 기능을 추가하기도 용이하다는 것을

28
00:01:54,000 --> 00:01:55,000
다시 한번 깨달았습니다.

29
00:01:55,000 --> 00:01:57,000
마지막으로 '트레이서 불릿'입니다.

30
00:01:57,000 --> 00:02:00,000
이건 완성본이 아니라 방향 감각을 잡는 데 쓰인다고 해요.

31
00:02:00,000 --> 00:02:06,000
완벽한 계획서보다, 아주 얇더라도 실제로 작동하는 흐름을 먼저 만들어 현실과 부딪혀보라는 이야기입니다.

32
00:02:06,000 --> 00:02:13,000
저도 블로그 자동화 작업을 할 때, 처음부터 모든 기능을 완벽하게 만들려 하기보다, 입력부터 배포까지의 핵심 흐름을

33
00:02:13,000 --> 00:02:16,000
먼저 얇게 뚫어보면서 방향을 잡아야겠다고 생각했습니다.

34
00:02:16,000 --> 00:02:21,000
계획은 언제든 바뀔 수 있지만, 작동하는 피드백은 우리에게 가장 빠르게 현실을 알려주니까요.

35
00:02:21,000 --> 00:02:26,000
이 책을 읽고 나서, 저는 제 작업 방식에 한 가지 변화를 주기로 했습니다.

36
00:02:26,000 --> 00:02:32,000
현재 진행 중인 프로젝트에서 중복된 지식이 숨어 있는 파일 두 곳을 찾아내고, 그것들을 하나의 명확한 출처로

37
00:02:32,000 --> 00:02:33,000
통합하는 작업을 할 예정입니다.

38
00:02:33,000 --> 00:02:40,000
그리고 불확실한 기능을 개발할 때는, 일단 프로토타입과 실제 제품 코드를 분리해서, 미래의 변경 가능성을 열어두는

39
00:02:40,000 --> 00:02:41,000
태도를 유지하려고 합니다.

40
00:02:41,000 --> 00:02:45,000
『실용주의 프로그래머』는 단순히 개발 기술을 알려주는 책이 아닙니다.

41
00:02:45,000 --> 00:02:52,000
새로운 기술에 휘둘리지 않고, 자기만의 탄탄한 개발 철학을 세우고 싶은 분들, 그리고 변화하는 환경 속에서 유연하게

42
00:02:52,000 --> 00:02:56,000
대처하는 방법을 고민하는 모든 분들에게 큰 의미가 있을 책이라고 생각합니다.

43
00:02:56,000 --> 00:03:00,000
좋은 설계는 오늘의 답을 박제하지 않고, 내일의 변경권을 남겨둡니다.

44
00:03:00,000 --> 00:03:05,000
AI가 코드 대부분을 생성하는 시대에, 실용주의 개발자의 책임은 과연 어디로 이동할까요?

45
00:03:05,000 --> 00:03:06,000
다음

46
00:03:06,000 --> 00:03:10,000
독서에서 이 질문에 대한 답의 실마리를 찾아보려 합니다.

47
00:03:10,000 --> 00:03:11,000
오늘도 책과 함께 좋은 하루 보내세요.

48
00:03:11,000 --> 00:03:11,000
감사합니다.