1
00:00:00,000 --> 00:00:04,000
코드를 작성하거나 리뷰할 때, 가끔 이런 질문을 던지곤 합니다.

2
00:00:04,000 --> 00:00:11,000
"왜 이렇게 복잡해졌을까?" 특히 요즘처럼 AI 도구와 자동화가 코드를 더 빨리 만들어내는 시대에는, 단순히

3
00:00:11,000 --> 00:00:18,000
'작동하는 코드'를 넘어, "어떤 코드가 오래 이해되고 수정될 수 있을까?" 하는 질문이 더욱 중요해지는 것

4
00:00:18,000 --> 00:00:19,000
같습니다.

5
00:00:19,000 --> 00:00:25,000
오늘 제가 이야기할 책은 스탠포드의 컴퓨터 과학자 존 오스터하우트 교수의 입니다.

6
00:00:25,000 --> 00:00:32,000
이 책은 저에게 '설계'를 거창한 아키텍처 선언이 아니라, 일상적인 복잡성 관리의 문제로 다시 읽게 만들었습니다.

7
00:00:32,000 --> 00:00:33,000
처음

8
00:00:33,000 --> 00:00:40,000
이 책을 집었을 때는, 코드를 어떻게 하면 더 깔끔하게 나눌 수 있을까 하는 막연한 기대를 가지고 있었습니다.

9
00:00:40,000 --> 00:00:45,000
흔히들 코드를 여러 계층으로 나누면 설계가 좋아진다고 생각하기 쉽잖아요.

10
00:00:45,000 --> 00:00:52,000
그런데 이 책은 단순히 '나눔' 그 자체보다, '나뉜 계층들이 과연 어떤 의미를 가지는지'를 묻고 있었습니다.

11
00:00:52,000 --> 00:00:55,000
읽기 전의 가설이 흔들리는 순간이었죠.

12
00:00:55,000 --> 00:01:00,000
이 책, 특히 제가 집중했던 7장과 8장의 핵심 메시지는 두 가지로 압축할 수 있습니다.

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:18,000
대신, 각 계층은 사용자가 완전히 다른 수준에서 생각하게 만드는, 새로운 사고 단위를 제공해야 한다는 거죠.

16
00:01:18,000 --> 00:01:24,000
예를 들어, 우리는 웹 페이지를 볼 때 브라우저의 내부 구현이 어떻게 되어 있는지 일일이 알 필요

17
00:01:24,000 --> 00:01:27,000
없이 '페이지'라는 추상화 위에서 생각합니다.

18
00:01:27,000 --> 00:01:29,000
이것이 바로 좋은 계층 분리의 예시죠.

19
00:01:29,000 --> 00:01:32,000
책에서는 이를 라고 부르며 경고합니다.

20
00:01:32,000 --> 00:01:37,000
이름만 다를 뿐, 거의 그대로 호출을 넘기는 얕은 계층들은 사실 추상화가 아닙니다.

21
00:01:37,000 --> 00:01:45,000
메서드 수가 아무리 늘어나도 코드를 이해하기 쉬워지지 않는다면, 그건 설계에 문제가 있다는 신호일 수 있습니다.

22
00:01:45,000 --> 00:01:49,000
이름만 다른 래퍼는 그저 조직도일 뿐, 새로운 가치를 주지 못하는 거죠.

23
00:01:49,000 --> 00:01:53,000
둘째 핵심은 "복잡성을 아래로 당겨라"는 원칙입니다.

24
00:01:53,000 --> 00:02:00,000
좋은 모듈이나 라이브러리는 복잡한 작업을 스스로 떠맡아, 그것을 호출하는 상위 코드를 최대한 단순하게 만듭니다.

25
00:02:00,000 --> 00:02:02,000
사용자는 그 복잡성을 직접 다룰 필요

26
00:02:02,000 --> 00:02:07,000
없이, 간결한 인터페이스를 통해 원하는 기능을 쓸 수 있게 되는 겁니다.

27
00:02:07,000 --> 00:02:11,000
마치 좋은 API가 내부의 복잡한 노동을 숨겨주듯이 말이죠.

28
00:02:11,000 --> 00:02:18,000
하위 모듈이 어려운 일을 기꺼이 맡아주는 것, 이것이 바로 인터페이스 설계의 핵심이라고 책은 강조합니다.

29
00:02:18,000 --> 00:02:21,000
이러한 메시지들은 저에게 깊은 인상을 남겼습니다.

30
00:02:21,000 --> 00:02:28,000
특히 "새 계층은 어떤 새로운 생각을 제공해야 존재할 자격이 있는가?"라는 질문은 제 코드 리뷰 방식에 큰 변화를

31
00:02:28,000 --> 00:02:29,000
가져왔습니다.

32
00:02:29,000 --> 00:02:34,000
예전에는 단순히 "이 코드가 작동하는가?"에 초점을 맞췄다면, 이제는 "다음

33
00:02:34,000 --> 00:02:42,000
변경자가 이 코드를 봤을 때 무엇을 알아야 하는가?" "이 계층이 새로운 사고 단위를 제공하는가?"를 먼저 묻게

34
00:02:42,000 --> 00:02:43,000
됩니다.

35
00:02:43,000 --> 00:02:50,000
설계는 어떤 거창한 선언문이 아니라, 우리가 매일 작성하는 코드의 이름, 경계, 예외 처리, 주석, 그리고 계층을

36
00:02:50,000 --> 00:02:54,000
선택하는 순간들 속에 녹아 있다는 것을 깨달았습니다.

37
00:02:54,000 --> 00:03:01,000
최근에 작업했던 모듈 하나를 다시 열어보고, 이 책의 기준에 따라 점검해보려는 작은 실험도 계획하고 있습니다.

38
00:03:01,000 --> 00:03:05,000
과연 '패스스루' 메서드는 없는지, 복잡성은 잘 당겨져 있는지 말이죠.

39
00:03:05,000 --> 00:03:13,000
이 책은 단순히 코드를 잘 쓰고 싶은 개발자뿐만 아니라, 팀 내 코드의 품질과 유지보수성을 고민하는 모든 개발자,

40
00:03:13,000 --> 00:03:17,000
특히 시니어 개발자들에게 큰 울림을 줄 것이라고 생각합니다.

41
00:03:17,000 --> 00:03:24,000
AI가 코드를 빠르게 생산하는 시대에, '좋은 코드'의 본질이 무엇인지 고민하고 싶은 분들이라면 꼭 한번 읽어보시길

42
00:03:24,000 --> 00:03:25,000
권합니다.

43
00:03:25,000 --> 00:03:29,000
오늘의 독후감을 한 문장으로 정리하자면 이렇습니다.

44
00:03:29,000 --> 00:03:36,000
"계층은 많아질수록 좋은 것이 아니라, 서로 다른 생각을 제공할 때만 깊어진다." 그리고 여전히 저에게 남은 질문이

45
00:03:36,000 --> 00:03:37,000
있습니다.

46
00:03:37,000 --> 00:03:45,000
AI 에이전트가 코드를 작성할 때, 이 '계층의 깊이'와 '복잡성 하향'이라는 원칙을 어떻게 로 넣을 수 있을까요?

47
00:03:45,000 --> 00:03:46,000
다음

48
00:03:46,000 --> 00:03:48,000
독서에서 이 질문에 대한 힌트를 찾아볼 수 있기를 기대해 봅니다.