1
00:00:00,000 --> 00:00:04,000
요즘 코드를 쓰는 속도가 부쩍 빨라졌다는 생각을 자주 합니다.

2
00:00:04,000 --> 00:00:05,000
AI 도구와 자동화 덕분인데요.

3
00:00:05,000 --> 00:00:12,000
이렇게 빠르게 만들어지는 코드들 중에서, 과연 어떤 코드가 오랫동안 이해되고 수정될 수 있을지 궁금해졌습니다.

4
00:00:12,000 --> 00:00:16,000
이런 질문을 품고 집어든 책이 바로 존 아우스터하우트의 입니다.

5
00:00:16,000 --> 00:00:22,000
이 책은 복잡한 아키텍처 선언보다는, 매일매일 마주하는 소프트웨어 복잡성을 어떻게 관리할 것인가에 대한 이야기를

6
00:00:22,000 --> 00:00:24,000
담고 있습니다.

7
00:00:24,000 --> 00:00:30,000
책을 읽기 전에는 모듈을 나누는 '분리 원칙'과 예상치 못한 상황을 처리하는 '예외 처리'가 서로 다른 주제라고

8
00:00:30,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:45,000
이 책의 핵심 주장은 바로 이것입니다.

12
00:00:45,000 --> 00:00:52,000
모듈의 경계와 예외 처리는 모두, 그 코드를 사용하는 사람이 알아야 할 경우의 수를 줄이는 방향으로 설계되어야

13
00:00:52,000 --> 00:00:53,000
한다는 것이죠.

14
00:00:53,000 --> 00:00:59,000
저자는 이런 관점에서 '함께 두는 것이 더 나은 경우'와 '오류를 아예 존재하지 않도록 설계하는 방식'을

15
00:00:59,000 --> 00:01:00,000
이야기합니다.

16
00:01:00,000 --> 00:01:05,000
가장 인상 깊었던 부분은 '오류를 아예 없애도록 설계한다'는 개념이었습니다.

17
00:01:05,000 --> 00:01:11,000
단순히 예외 상황을 잘 잡아서 처리하는 코드를 늘리기보다는, 애초에 그런 오류 상태가 발생할 수 없도록 설계

18
00:01:11,000 --> 00:01:13,000
단계에서부터 고민해야 한다는 것이죠.

19
00:01:13,000 --> 00:01:20,000
이는 마치 병이 생기면 약을 먹는 것보다, 병에 걸리지 않도록 건강한 생활 습관을 만드는 것과 비슷하게

20
00:01:20,000 --> 00:01:21,000
느껴졌습니다.

21
00:01:21,000 --> 00:01:27,000
또, '특별한 경우'를 줄이는 설계가 호출자의 머릿속 분기를 줄인다는 인사이트도 크게 와닿았습니다.

22
00:01:27,000 --> 00:01:33,000
특수한 사례가 자꾸 생겨나 인터페이스를 복잡하게 만든다면, 그 특수 사례를 일반적인 규칙으로 흡수하거나 아예

23
00:01:33,000 --> 00:01:36,000
설계에서 제거할 수 없는지 먼저 고민해야 한다는 거죠.

24
00:01:36,000 --> 00:01:43,000
무조건적으로 코드를 쪼개는 것이 아니라, 공유하는 정보가 많거나 인터페이스가 단순해질 수 있다면 오히려 함께 두는

25
00:01:43,000 --> 00:01:47,000
것이 더 나을 수 있다는 점도 제 기존 생각을 흔들었습니다.

26
00:01:47,000 --> 00:01:53,000
결국, 이 책은 제게 '설계'라는 것이 거창한 선언이 아니라, 매일매일 작성하는 코드의 이름, 경계, 예외 처리,

27
00:01:53,000 --> 00:01:58,000
주석, 그리고 계층을 선택하는 순간순간에 스며들어 있다는 것을 일깨워 주었습니다.

28
00:01:58,000 --> 00:02:02,000
이 책을 읽고 나서 제 코드 리뷰 방식에도 변화를 주려고 합니다.

29
00:02:02,000 --> 00:02:09,000
이제부터는 단순히 '이 코드가 잘 작동하는가?'를 넘어, '이 코드를 다음으로 수정할 개발자가 무엇을 알아야

30
00:02:09,000 --> 00:02:11,000
하는가?'라는 질문을 던지게 될 것 같습니다.

31
00:02:11,000 --> 00:02:18,000
인터페이스가 노출하는 정보의 양, 즉 '표면적'을 줄이는 것이 좋은 설계의 핵심이라는 관점에서 코드를 보게 된

32
00:02:18,000 --> 00:02:19,000
거죠.

33
00:02:19,000 --> 00:02:26,000
이 책은 복잡한 소프트웨어 시스템을 다루는 개발자, 아키텍트, 그리고 AI가 생성하는 코드의 품질과 유지보수성에

34
00:02:26,000 --> 00:02:29,000
대해 고민하는 모든 분들에게 깊은 울림을 줄 것입니다.

35
00:02:29,000 --> 00:02:32,000
결론적으로 이 책이 제게 남긴 한 문장은 이렇습니다.

36
00:02:32,000 --> 00:02:38,000
좋은 경계는 코드를 예쁘게 나누는 선이 아니라, 그 코드를 사용하는 사람의 경우의 수를 줄이는 장치입니다.

37
00:02:38,000 --> 00:02:45,000
앞으로 AI 에이전트가 코드를 작성할 때, 이런 '경우의 수를 줄이는 설계 원칙'을 어떻게 검증 루프에 넣을 수

38
00:02:45,000 --> 00:02:45,000
있을지, 계속해서 고민해 봐야겠습니다.