1
00:00:00,000 --> 00:00:03,000
요즘 코드를 작성하는 속도는 그 어느 때보다

2
00:00:03,000 --> 00:00:04,000
빠릅니다.

3
00:00:04,000 --> 00:00:08,000
AI 도구들이 순식간에 수많은 코드를 만들어내죠.

4
00:00:08,000 --> 00:00:15,000
그런데 이렇게 빠르게 생산된 코드 중, 얼마나 많은 코드가 오랫동안 이해되고, 또 수정될 수 있을까요?

5
00:00:15,000 --> 00:00:21,000
저는 이 질문을 가지고 존 오스터하우트의 '소프트웨어 설계 철학'을 다시 펼쳐 들었습니다.

6
00:00:21,000 --> 00:00:29,000
스탠퍼드 대학교 컴퓨터 과학자이자 Tcl/Tk 개발자로 잘 알려진 존 오스터하우트는, 설계를 거창한 아키텍처 선언이

7
00:00:29,000 --> 00:00:32,000
아니라 매일 마주하는 복잡성을 관리하는 일로 바라봅니다.

8
00:00:32,000 --> 00:00:36,000
특히 이번 독서에서는 '명백한 코드가 유행보다

9
00:00:36,000 --> 00:00:38,000
강하다'는 9번째 회차에 집중했습니다.

10
00:00:38,000 --> 00:00:42,000
책을 읽기 전, 제 안에는 이런 가설이 있었습니다.

11
00:00:42,000 --> 00:00:49,000
아무리 좋은 방법론이나 최신 도구라 해도, 그것만으로는 설계의 품질을 자동으로 보장하지 못할 것이다.

12
00:00:49,000 --> 00:00:55,000
오히려 유행하는 방법론들이 언제 설계를 돕고, 또 언제 설계를 가리는지, 그 기준이 궁금했습니다.

13
00:00:55,000 --> 00:00:57,000
이 책의 핵심 주장은 명확합니다.

14
00:00:57,000 --> 00:01:00,000
좋은 코드는 '명백해야' 한다는 것이죠.

15
00:01:00,000 --> 00:01:06,000
읽는 사람이 적은 추론으로도 코드의 정확한 동작과 의도를 예측할 수 있어야 한다는 겁니다.

16
00:01:06,000 --> 00:01:14,000
그리고 유행하는 모든 방법론과 패러다임은 이 '명백성'이라는 기준을 통과할 때에만 비로소 진정한 도움이 된다고

17
00:01:14,000 --> 00:01:15,000
말합니다.

18
00:01:15,000 --> 00:01:22,000
결국, 설계는 복잡성을 줄이는 일이고, 명백성은 그 복잡성을 측정하는 가장 중요한 척도가 되는 셈입니다.

19
00:01:22,000 --> 00:01:26,000
이 책은 단순히 '무엇이 좋다, 나쁘다'고 단정하지 않습니다.

20
00:01:26,000 --> 00:01:32,000
대신, 우리가 당연하게 여기던 많은 것들을 '명백성'이라는 렌즈로 다시 보게 만듭니다.

21
00:01:32,000 --> 00:01:37,000
예를 들어, 객체 지향 프로그래밍, OOP는 강력한 도구임에 틀림없습니다.

22
00:01:37,000 --> 00:01:45,000
하지만 상속이 깊은 계층을 만들고 분산된 상태가 암묵적인 규칙을 늘릴 때, 오히려 복잡성을 키울 수 있다는 저자의

23
00:01:45,000 --> 00:01:47,000
지적에 깊이 공감했습니다.

24
00:01:47,000 --> 00:01:51,000
패러다임은 원칙이 아니라 도구일 뿐이라는 깨달음이죠.

25
00:01:51,000 --> 00:01:53,000
유닛 테스트나 TDD도 마찬가지입니다.

26
00:01:53,000 --> 00:02:00,000
품질을 높이고 회귀를 막는 데 필수적이지만, 테스트 자체가 좋은 설계를 자동으로 만들어주지는 않습니다.

27
00:02:00,000 --> 00:02:07,000
테스트 가능성은 좋은 설계의 신호일 수는 있어도, 충분조건은 아니라는 점을 다시 한번 상기시켜 주었습니다.

28
00:02:07,000 --> 00:02:11,000
디자인 패턴 역시 공통의 언어를 제공하지만, 문제보다

29
00:02:11,000 --> 00:02:16,000
패턴이 앞서면 단순히 장식에 불과할 수 있다는 경고도 인상 깊었습니다.

30
00:02:16,000 --> 00:02:21,000
이 책을 읽고 나서, 제 머릿속에 가장 크게 남은 질문은 이것입니다.

31
00:02:21,000 --> 00:02:22,000
'다음

32
00:02:22,000 --> 00:02:30,000
변경자가 이 코드를 봤을 때, 무엇을 얼마나 알아야 할까?' 이제 코드 리뷰를 할 때 '이 코드가 작동하는가?'를

33
00:02:30,000 --> 00:02:37,000
넘어, '이 코드가 얼마나 명백한가?', '이 코드를 이해하기 위해 얼마나 많은 추론이 필요한가?'를 묻게 될 것

34
00:02:37,000 --> 00:02:39,000
같습니다.

35
00:02:39,000 --> 00:02:46,000
설계는 거창한 회의나 문서가 아니라, 우리가 매일 선택하는 이름, 경계, 예외 처리, 주석, 그리고 코드의 계층

36
00:02:46,000 --> 00:02:50,000
속에 녹아 있다는 것을 다시 한번 깨닫게 됩니다.

37
00:02:50,000 --> 00:02:57,000
이 책은 최신 기술 스택이나 방법론을 맹목적으로 쫓기보다, 본질적인 설계의 가치에 대해 깊이 고민하고 싶은

38
00:02:57,000 --> 00:02:59,000
개발자에게 강력히 추천합니다.

39
00:02:59,000 --> 00:03:06,000
특히 애자일, TDD, 디자인 패턴 등 다양한 방법론을 접하면서도, '과연 이게 최선일까?'라는 의문을 품었던

40
00:03:06,000 --> 00:03:09,000
분들에게 명쾌한 기준을 제시해 줄 것입니다.

41
00:03:09,000 --> 00:03:12,000
결국, 유행은 설계를 대신하지 못합니다.

42
00:03:12,000 --> 00:03:19,000
오직 읽는 사람이 덜 추론해도 되는, 즉 '명백한 코드'만이 오래 살아남는다는 메시지를 가슴에 새깁니다.

43
00:03:19,000 --> 00:03:27,000
저는 이제 제가 작성하는 코드베이스에서 이 '명백성'의 레드 플래그가 어디에 가장 뚜렷하게 보이는지 찾아보려

44
00:03:27,000 --> 00:03:27,000
합니다.