1
00:00:00,000 --> 00:00:05,000
코드를 작성하는 일이 점점 더 빨라지는 요즘, 우리는 어떤 질문을 던져야 할까요?

2
00:00:05,000 --> 00:00:10,000
단순히 빨리 만드는 것을 넘어, '잘 만드는 것'의 기준은 무엇일까요?

3
00:00:10,000 --> 00:00:17,000
저는 최근 존 오스터하우트 교수의 "A Philosophy of Software Design"이라는 책을 읽으며 이

4
00:00:17,000 --> 00:00:19,000
질문에 대한 답을 찾아봤습니다.

5
00:00:19,000 --> 00:00:25,000
AI 도구가 코드를 뚝딱 만들어내는 시대에, 과연 어떤 코드가 오랫동안 살아남고, 다음

6
00:00:25,000 --> 00:00:28,000
사람이 쉽게 이해하고 수정할 수 있을지 궁금했습니다.

7
00:00:28,000 --> 00:00:35,000
솔직히 저는 늘 소프트웨어 설계가 멋진 아키텍처 다이어그램이나 정교한 디자인 패턴 선택의 문제라고 생각했죠.

8
00:00:35,000 --> 00:00:37,000
하지만 이 책은 그보다

9
00:00:37,000 --> 00:00:40,000
훨씬 근본적인 질문을 던지며, 제 가설을 흔들어 놓았습니다.

10
00:00:40,000 --> 00:00:46,000
저자 오스터하우트 교수는 소프트웨어 설계의 핵심을 '복잡성'과의 싸움으로 정의합니다.

11
00:00:46,000 --> 00:00:53,000
즉, 좋은 설계란 무엇인가를 더 많이 추가하는 기술이 아니라, 오히려 무엇을 줄이는 기술이라는 거죠.

12
00:00:53,000 --> 00:00:57,000
책은 복잡성을 단순히 코드의 양이나 기능의 많음으로 보지 않습니다.

13
00:00:57,000 --> 00:01:04,000
대신 개발자의 '인지 부하', 즉 코드를 이해하고 수정할 때 드는 '머릿속 부담'으로 측정해야 한다고 말합니다.

14
00:01:04,000 --> 00:01:07,000
이 인지 부하가 곧 설계의 부채가 된다는 것이죠.

15
00:01:07,000 --> 00:01:13,000
이 책을 읽기 전까지 저는 복잡성을 그저 '어렵다'는 감각적인 문제로만 생각했습니다.

16
00:01:13,000 --> 00:01:17,000
하지만 책은 복잡성을 '장기적인 비용'으로 명확히 인지하게 했습니다.

17
00:01:17,000 --> 00:01:22,000
마치 재무적인 부채처럼, 복잡성이 쌓이면 미래의 생산성을 갉아먹는다는 사실을요.

18
00:01:22,000 --> 00:01:25,000
특히 '변경 증폭'이라는 개념이 와닿았습니다.

19
00:01:25,000 --> 00:01:32,000
작은 수정 하나가 예상치 못하게 많은 곳에서 추가적인 변경을 요구하며 작업 시간을 잡아먹는 경험, 다들 한 번쯤

20
00:01:32,000 --> 00:01:34,000
있으실 겁니다.

21
00:01:34,000 --> 00:01:41,000
제 코드에서도 이런 증상이 어디까지 번지는지, 그리고 왜 번지는지 먼저 파악해야 한다는 깨달음을 얻었습니다.

22
00:01:41,000 --> 00:01:48,000
그리고 '인지 부하'는 단순히 개인의 능력 문제가 아니라, 시스템 설계의 문제라는 통찰은 저에게 큰 충격이었습니다.

23
00:01:48,000 --> 00:01:51,000
좋은 코드는 그저 실행만 되는 코드가 아니라, 다음

24
00:01:51,000 --> 00:01:56,000
사람이 이해하고 수정하는 데 드는 비용이 낮은 코드여야 한다는 거죠.

25
00:01:56,000 --> 00:02:01,000
이건 단순히 개인의 숙련도를 넘어, 팀 전체의 생산성과 직결되는 문제였습니다.

26
00:02:01,000 --> 00:02:05,000
저는 이 책을 읽고 나서, 코드 리뷰 질문을 바꿔보기로 했습니다.

27
00:02:05,000 --> 00:02:08,000
"이 코드가 잘 작동하는가?"에서 "다음

28
00:02:08,000 --> 00:02:11,000
변경자가 이 코드를 수정하려면 무엇을 알아야 하는가?"로요.

29
00:02:11,000 --> 00:02:18,000
설계는 거창한 아키텍처 문서에만 존재하는 것이 아니라, 매일 우리가 선택하는 변수 이름, 함수 경계, 주석

30
00:02:18,000 --> 00:02:21,000
하나하나에 스며들어 있다는 것을 깨달았습니다.

31
00:02:21,000 --> 00:02:28,000
최근 작업했던 모듈 하나를 다시 보면서, '변경 증폭'이나 '인지 부하'의 관점에서 얼마나 개선할 수 있을지

32
00:02:28,000 --> 00:02:30,000
실험해볼 생각입니다.

33
00:02:30,000 --> 00:02:34,000
숨겨진 의존성은 없는지, 모호한 부분은 없는지 꼼꼼히 살펴보려고 합니다.

34
00:02:34,000 --> 00:02:41,000
이 책은 특히 실무에서 코드를 작성하고 유지보수하는 개발자분들, 그리고 코드 리뷰를 통해 동료들과 함께 더 나은

35
00:02:41,000 --> 00:02:45,000
설계를 고민하는 팀 리더분들에게 큰 울림을 줄 것 같습니다.

36
00:02:45,000 --> 00:02:52,000
단순히 기능 구현을 넘어, '오래가는 코드'를 만들고 싶은 분이라면 꼭 한번 읽어보시길 권합니다.

37
00:02:52,000 --> 00:02:59,000
마치 좋은 건축가가 건물의 아름다움뿐 아니라 사용자의 편의와 유지보수 용이성을 고민하듯이, 이 책은 소프트웨어

38
00:02:59,000 --> 00:03:01,000
건축가의 기본적인 철학을 제시합니다.

39
00:03:01,000 --> 00:03:05,000
결국, 소프트웨어 설계는 코드를 멋지게 꾸미는 일이 아니라, 다음

40
00:03:05,000 --> 00:03:12,000
사람이 덜 헤매게 만들어서 우리 모두의 장기적인 생산성을 높이는 일이라는 한 문장으로 정리할 수 있겠습니다.

41
00:03:12,000 --> 00:03:15,000
저는 이제 또 다른 질문을 안고 다음

42
00:03:15,000 --> 00:03:16,000
책으로 향합니다.

43
00:03:16,000 --> 00:03:22,000
AI 에이전트가 코드를 작성할 때, 이 '복잡성 관리' 원칙을 어떻게 검증 루프에 넣을 수 있을까요?

44
00:03:22,000 --> 00:03:27,000
아니면 AI 자체가 복잡성을 줄이는 새로운 설계 방식을 제시할 수 있을까요?

45
00:03:27,000 --> 00:03:29,000
여러분의 생각은 어떠신가요?