1
00:00:00,000 --> 00:00:08,000
최근 제가 작업했던 코드들을 돌아보면, 어떤 부분은 건드리기가 너무 조심스럽고, 또 어떤 부분은 예상치 못하게 다른

2
00:00:08,000 --> 00:00:11,000
곳에 영향을 주어 당황스러울 때가 많았습니다.

3
00:00:11,000 --> 00:00:13,000
왜 이런 복잡성이 생기는 걸까?

4
00:00:13,000 --> 00:00:18,000
라는 질문을 품고, 존 오스터하우트의 이라는 책을 다시 펼쳐 들었습니다.

5
00:00:18,000 --> 00:00:24,000
특히 이번에는 3회차 독서인데, 과 에 대한 챕터를 깊이 들여다봤습니다.

6
00:00:24,000 --> 00:00:27,000
요즘 AI 도구들이 코드를 정말 빠르게 만들어내죠.

7
00:00:27,000 --> 00:00:34,000
그렇다면 결국 어떤 코드가 오래 살아남고, 이해하기 쉽고, 또 수정할 수 있는 코드가 될까?

8
00:00:34,000 --> 00:00:37,000
하는 질문이 제 머릿속을 떠나지 않았습니다.

9
00:00:37,000 --> 00:00:45,000
이 책을 읽기 전에는 캡슐화를 그저 '필드 접근을 막는 것' 정도로만 이해하고 있었는데, 은 모듈의 경계를 그리는

10
00:00:45,000 --> 00:00:48,000
방식에 대해 새로운 가설을 던져주었습니다.

11
00:00:48,000 --> 00:00:53,000
'숨겨야 할 대상은 데이터가 아니라, 바로 설계 결정이다'라는 가설이었죠.

12
00:00:53,000 --> 00:01:01,000
이 책은 설계를 거창한 아키텍처 선언이 아니라, 우리가 매일 마주하는 복잡성을 관리하는 일상적인 행위로 바라보게

13
00:01:01,000 --> 00:01:02,000
합니다.

14
00:01:02,000 --> 00:01:03,000
핵심은 이겁니다.

15
00:01:03,000 --> 00:01:10,000
은 단순히 코드를 감추는 기술이 아니라, '앞으로 바뀔 가능성이 높은 설계 결정을 모듈 내부로 밀어 넣는

16
00:01:10,000 --> 00:01:12,000
기술'이라는 거죠.

17
00:01:12,000 --> 00:01:17,000
그리고 은 하나의 설계 결정이 여러 모듈에 퍼져나가는 상태를 말합니다.

18
00:01:17,000 --> 00:01:23,000
이렇게 되면 어떤 부분을 수정했을 때, 그 변경이 어디까지 영향을 미칠지 알기 어려워지죠.

19
00:01:23,000 --> 00:01:25,000
또한 저자는 의 중요성을 강조합니다.

20
00:01:25,000 --> 00:01:31,000
특정 호출자에 묶이지 않는, 더 깊고 유연한 API를 지향해야 한다는 겁니다.

21
00:01:31,000 --> 00:01:35,000
이건 과도한 추상화가 아니라, 현실적인 범용성을 의미합니다.

22
00:01:35,000 --> 00:01:42,000
책을 읽으며 가장 크게 머리를 친 부분은, '무엇이 바뀔지 묻지 않으면, 무엇을 숨길지도 알 수 없다'는

23
00:01:42,000 --> 00:01:44,000
깨달음이었습니다.

24
00:01:44,000 --> 00:01:52,000
저는 그동안 코드를 짤 때 '이 필드는 private으로 할까, public으로 할까' 정도만 고민했던 것 같아요.

25
00:01:52,000 --> 00:01:55,000
하지만 이 책은 훨씬 근본적인 질문을 던집니다.

26
00:01:55,000 --> 00:02:01,000
'이 모듈의 어떤 결정이 미래에 변경될 가능성이 가장 높을까?' 그리고 을 '중복 코드보다

27
00:02:01,000 --> 00:02:05,000
더 조용한 중복 지식'이라고 표현한 부분이 인상 깊었습니다.

28
00:02:05,000 --> 00:02:14,000
눈에 보이는 코드는 중복을 찾아내기 쉽지만, 여러 모듈에 퍼져 있는 '동일한 지식'은 알아차리기 어렵고, 결국 변경

29
00:02:14,000 --> 00:02:16,000
비용을 엄청나게 높인다는 거죠.

30
00:02:16,000 --> 00:02:24,000
또 은 막연한 미래를 예측해서 미리 설계하는 것이 아니라, '현재 인터페이스를 단순화하는 데서 나온다'는 점도 제게

31
00:02:24,000 --> 00:02:25,000
큰 울림을 주었습니다.

32
00:02:25,000 --> 00:02:31,000
이 책의 관점을 제 작업에 적용해본다면, 질문이 완전히 달라질 것 같습니다.

33
00:02:31,000 --> 00:02:34,000
단순히 '이 코드가 작동하는가?'를 넘어, '다음

34
00:02:34,000 --> 00:02:41,000
변경자가 이 모듈을 수정할 때, 무엇을 알아야 하고, 무엇을 몰라도 되는가?'를 묻게 될 겁니다.

35
00:02:41,000 --> 00:02:49,000
결국 설계는 거창한 설계 문서가 아니라, 우리가 매일 선택하는 이름, 모듈의 경계, 예외 처리 방식, 주석, 그리고

36
00:02:49,000 --> 00:02:52,000
계층 구조 속에 사실을 다시금 깨닫습니다.

37
00:02:52,000 --> 00:03:00,000
최근 제가 작업했던 모듈 하나를 이 책의 기준으로 다시 들여다보고, 숨겨져야 할지, 불필요하게 노출되어 있는지

38
00:03:00,000 --> 00:03:01,000
고민해봐야겠습니다.

39
00:03:01,000 --> 00:03:07,000
이 책은 단순히 코드를 잘 짜는 기술을 넘어, 를 원하는 모든 개발자에게 추천하고 싶습니다.

40
00:03:07,000 --> 00:03:15,000
특히 '내 코드가 왜 이렇게 유지보수하기 어려운 걸까?'라는 질문을 자주 던지는 분들, 캡슐화나 모듈화에 대한

41
00:03:15,000 --> 00:03:19,000
기존의 이해를 확장하고 싶은 분들에게 큰 도움이 될 겁니다.

42
00:03:19,000 --> 00:03:24,000
결론적으로, 좋은 모듈은 이 아니라, 와 같다는 것을 배웠습니다.

43
00:03:24,000 --> 00:03:31,000
이런 관점에서, , 과연 어떤 설계 원칙을 검증 루프에 넣어야 할지, 또 다른 질문을 안고 다음

44
00:03:31,000 --> 00:03:31,000
책으로 향합니다.