1
00:00:00,000 --> 00:00:04,000
코드는 어떻게 시간이 지나도 같은 방향을 유지할 수 있을까요?

2
00:00:04,000 --> 00:00:12,000
AI 도구와 자동화가 코드를 더 빨리 만들어내는 요즘, 저는 어떤 코드가 오랫동안 이해되고 수정될 수 있을지 계속

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

4
00:00:13,000 --> 00:00:16,000
오늘 이야기할 책은 존 오스터하우트의 입니다.

5
00:00:16,000 --> 00:00:24,000
이 책을 읽기 전에는 유지보수라는 단어를 들으면, 이미 만들어진 코드를 고치거나 수정하는 일만을 떠올렸습니다.

6
00:00:24,000 --> 00:00:30,000
하지만 이 책은 유지보수를 코드 작성 이전의 설계 습관까지 확장해서 보라고 말합니다.

7
00:00:30,000 --> 00:00:37,000
저자 존 오스터하우트는 운영체제와 분산 시스템 연구, 그리고 Tcl/Tk 개발로 유명한 컴퓨터 과학자인데요.

8
00:00:37,000 --> 00:00:42,000
스탠퍼드 대학에서 소프트웨어 설계 교육을 오랫동안 이어왔습니다.

9
00:00:42,000 --> 00:00:50,000
그래서인지 이 책은 설계를 거창한 아키텍처 선언이 아니라, 우리가 매일 마주하는 복잡성을 관리하는 일상적인 행위로

10
00:00:50,000 --> 00:00:51,000
바라보게 합니다.

11
00:00:51,000 --> 00:00:59,000
특히 제가 인상 깊게 읽은 부분은 15장 '주석을 먼저 작성하라', 16장 '기존 코드 수정하기', 그리고 17장

12
00:00:59,000 --> 00:01:00,000
'일관성'이었습니다.

13
00:01:00,000 --> 00:01:04,000
이 세 챕터를 관통하는 저자의 핵심 주장은 이렇습니다.

14
00:01:04,000 --> 00:01:11,000
"유지보수성은 나중에 덧붙이는 품질이 아니라, 설계와 주석, 수정 습관, 그리고 일관성이 함께 만드는 시간의

15
00:01:11,000 --> 00:01:19,000
구조다." 이 말은 제게 유지보수가 단순히 코드를 '고치는' 일이 아니라, 코드를 '쓰는' 순간부터 시작되는

16
00:01:19,000 --> 00:01:21,000
책임이라는 것을 깨닫게 했습니다.

17
00:01:21,000 --> 00:01:26,000
가장 먼저 와닿았던 건 "주석을 먼저 작성하라"는 원칙이었습니다.

18
00:01:26,000 --> 00:01:27,000
저는 주석을 코드를 다

19
00:01:27,000 --> 00:01:30,000
쓰고 나서 설명을 덧붙이는 것이라고 생각했어요.

20
00:01:30,000 --> 00:01:36,000
그런데 저자는 주석을 설계의 스케치로, 심지어 설계 검증 도구로 활용하라고 말합니다.

21
00:01:36,000 --> 00:01:42,000
먼저 설명할 수 없는 인터페이스라면, 아직 설계가 덜 된 것일 수 있다는 거죠.

22
00:01:42,000 --> 00:01:46,000
이 관점은 주석을 바라보는 제 시각을 완전히 바꿔 놓았습니다.

23
00:01:46,000 --> 00:01:52,000
다음으로, "기존 코드를 수정할 때는 전략적 설계를 유지하라"는 조언도 기억에 남습니다.

24
00:01:52,000 --> 00:02:00,000
작은 변경일수록 설계 원칙이 무너지기 쉽다는 저자의 경고는, 저도 모르게 저질렀던 실수들을 돌아보게 했습니다.

25
00:02:00,000 --> 00:02:07,000
작은 패치 하나가 전체 구조를 무너뜨리지 않도록, 변경 중에도 항상 큰 그림을 잊지 말아야 한다는 교훈을

26
00:02:07,000 --> 00:02:08,000
얻었습니다.

27
00:02:08,000 --> 00:02:12,000
그리고 "일관성"에 대한 이야기도 흥미로웠습니다.

28
00:02:12,000 --> 00:02:16,000
비슷한 문제를 비슷한 방식으로 다루는 힘, 그것이 바로 일관성인데요.

29
00:02:16,000 --> 00:02:21,000
저는 일관성이 때로는 창의성을 저해한다고 생각하기도 했습니다.

30
00:02:21,000 --> 00:02:25,000
하지만 이 책은 일관성이 협업을 위한 '기억 압축'이라고 말합니다.

31
00:02:25,000 --> 00:02:31,000
반복되는 패턴은 독자의 예측을 돕고, 불필요한 인지 부하를 줄여준다는 거죠.

32
00:02:31,000 --> 00:02:36,000
이는 제가 글을 쓰거나 제품을 만들 때도 적용할 수 있는 중요한 원칙이었습니다.

33
00:02:36,000 --> 00:02:41,000
이 책을 읽고 나서 저는 제 작업 방식에 한 가지 변화를 주려고 합니다.

34
00:02:41,000 --> 00:02:44,000
바로 코드 리뷰 질문을 바꾸는 것입니다.

35
00:02:44,000 --> 00:02:48,000
기존의 "이 코드가 작동하는가?"에서 한발 더 나아가, "다음

36
00:02:48,000 --> 00:02:54,000
변경자가 이 코드를 수정하기 위해 무엇을 알아야 하는가?"라는 질문을 던져보려고 합니다.

37
00:02:54,000 --> 00:03:02,000
그리고 최근 제가 수정한 모듈 하나를 다시 살펴보며, 이 책에서 배운 주석과 일관성의 기준을 적용해볼 생각입니다.

38
00:03:02,000 --> 00:03:10,000
또한, AI 에이전트가 코드를 작성하는 시대에, 이 원칙들을 어떻게 검증 루프로 넣을 수 있을지 고민하는 것도 저의

39
00:03:10,000 --> 00:03:11,000
숙제가 되었습니다.

40
00:03:11,000 --> 00:03:16,000
이 책은 소프트웨어 개발자라면 누구나 한 번쯤 읽어보면 좋을 것 같습니다.

41
00:03:16,000 --> 00:03:24,000
특히 코드의 생명주기를 고민하는 분들, 그리고 AI가 생성한 코드의 품질을 어떻게 관리할지 고민하는 분들에게 많은

42
00:03:24,000 --> 00:03:27,000
인사이트를 줄 것이라고 생각합니다.

43
00:03:27,000 --> 00:03:35,000
결국 유지보수는 나중에 코드가 버티는 능력이 아니라, 처음부터 시간을 견디도록 쓰는 습관이라는 것을 이 책은 제게

44
00:03:35,000 --> 00:03:36,000
가르쳐 주었습니다.

45
00:03:36,000 --> 00:03:40,000
다음번에는 또 어떤 책이 제 생각의 지평을 넓혀줄지 기대되네요.