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

2
00:00:03,000 --> 00:00:05,000
그럴 때마다

3
00:00:05,000 --> 00:00:07,000
저는 이런 질문을 던지곤 합니다.

4
00:00:07,000 --> 00:00:15,000
'과연 어떤 코드가 오래 이해되고, 또 수정될 수 있을까?' 빠르게 작동하는 것만큼이나, 시간이 흘러도 그 본질을

5
00:00:15,000 --> 00:00:18,000
잃지 않는 코드를 만드는 것이 중요하다고 생각했거든요.

6
00:00:18,000 --> 00:00:26,000
그래서 저는 존 아우스터하우트의 『A Philosophy of Software Design』, 이 책을 다시

7
00:00:26,000 --> 00:00:27,000
펼쳤습니다.

8
00:00:27,000 --> 00:00:34,000
특히 마지막 장들, 성능 설계와 설계 원칙, 그리고 피해야 할 '레드 플래그'들을 다루는 부분이었죠.

9
00:00:34,000 --> 00:00:37,000
책을 읽기 전에는 이런 가설을 가지고 있었습니다.

10
00:00:37,000 --> 00:00:44,000
'성능 최적화는 결국 설계 원칙과 충돌할 수밖에 없지 않을까?' 빨리 만들려면, 어딘가 복잡해지거나 설계의

11
00:00:44,000 --> 00:00:48,000
아름다움을 포기해야 할 때가 있다고 생각했거든요.

12
00:00:48,000 --> 00:00:55,000
하지만 이 책의 저자, 스탠퍼드 대학교의 존 아우스터하우트 교수는 저의 이런 고정관념을 흔들어 놓았습니다.

13
00:00:55,000 --> 00:00:59,000
그는 성능 역시 '복잡성'의 문제로 봐야 한다고 말합니다.

14
00:00:59,000 --> 00:01:04,000
즉, 성능을 개선하는 과정도 결국 복잡성을 줄이는 방식이어야 한다는 거죠.

15
00:01:04,000 --> 00:01:11,000
이 책에서 제가 가장 깊이 공감했던 문장 중 하나는 "측정하기 전에는 수정하지 마라"는 것이었습니다.

16
00:01:11,000 --> 00:01:16,000
우리는 흔히 '여기가 느릴 거야'라는 추측만으로 코드를 뜯어고치곤 하죠.

17
00:01:16,000 --> 00:01:20,000
하지만 저자는 정확한 측정을 통해 진짜 병목을 찾아야 한다고 강조합니다.

18
00:01:20,000 --> 00:01:25,000
근거 없는 최적화는 오히려 불필요한 복잡성만 남길 수 있다는 거죠.

19
00:01:25,000 --> 00:01:29,000
그리고 '핵심 경로'의 중요성도 다시 한번 깨달았습니다.

20
00:01:29,000 --> 00:01:36,000
시스템 전체의 속도를 지배하는 그 핵심적인 흐름을 먼저 파악하고, 그곳을 중심으로 설계를 해야 한다는 겁니다.

21
00:01:36,000 --> 00:01:44,000
중요하지 않은 부분을 아무리 최적화해봤자, 전체 성능에는 큰 영향을 주지 못하고 오히려 코드를 더 알아보기 어렵게

22
00:01:44,000 --> 00:01:47,000
만들 뿐이라는 지적에 고개를 끄덕였습니다.

23
00:01:47,000 --> 00:01:51,000
가장 인상 깊었던 건, 설계 원칙에 대한 저자의 관점이었습니다.

24
00:01:51,000 --> 00:01:56,000
그는 설계 원칙이 단순히 외우는 '표어'나 '체크리스트'가 아니라고 말합니다.

25
00:01:56,000 --> 00:02:02,000
대신, '복잡성의 냄새를 반복해서 감지하는 루프'가 되어야 한다고 강조하죠.

26
00:02:02,000 --> 00:02:09,000
마치 좋은 의사가 환자의 증상을 끊임없이 살피듯, 개발자도 자신의 코드에서 복잡성의 신호를 지속적으로 포착하고

27
00:02:09,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:26,000
변경자가 얼마나 쉽게 이해하고 수정할 수 있을까?'를 먼저 묻게 됩니다.

31
00:02:26,000 --> 00:02:33,000
설계는 특별한 의식이나 거창한 선언이 아니라, 우리가 매일 작성하는 이름, 경계, 예외 처리, 주석, 그리고 계층

32
00:02:33,000 --> 00:02:36,000
선택 속에 녹아 있다는 것을 깨달았어요.

33
00:02:36,000 --> 00:02:41,000
그래서 저는 최근에 제가 수정한 모듈 하나를 다시 열어보려 합니다.

34
00:02:41,000 --> 00:02:48,000
이 모듈의 '핵심 경로'는 무엇이었는지, 그리고 불필요한 복잡성을 유발하는 성능 최적화 시도는 없었는지, 책에서

35
00:02:48,000 --> 00:02:52,000
배운 관점으로 다시 한번 꼼꼼하게 들여다볼 생각입니다.

36
00:02:52,000 --> 00:02:57,000
이 책은 단순히 성능 좋은 코드를 만드는 방법을 알려주는 기술서가 아닙니다.

37
00:02:57,000 --> 00:03:05,000
소프트웨어 설계의 본질에 대해 깊이 고민하고 싶은 분들, 특히 성능 개선과 설계 사이에서 균형을 잡는 데 어려움을

38
00:03:05,000 --> 00:03:09,000
느끼는 개발자들에게 큰 울림을 줄 것이라고 생각합니다.

39
00:03:09,000 --> 00:03:14,000
AI 시대에 좋은 코드가 무엇인지 성찰하고 싶은 분들에게도 강력하게 추천하고 싶어요.

40
00:03:14,000 --> 00:03:18,000
결국 이 책이 저에게 남긴 한 문장은 이것입니다.

41
00:03:18,000 --> 00:03:25,000
"특정 패턴을 따르기보다, 복잡성을 감지하고 줄이는 루프를 끊임없이 돌려라." 그렇다면 이제 새로운 질문이

42
00:03:25,000 --> 00:03:26,000
남습니다.

43
00:03:26,000 --> 00:03:32,000
AI 에이전트가 코드를 작성할 때, 이 복잡성 감지 루프를 어떻게 검증 과정에 포함시킬 수 있을까요?