1
00:00:00,000 --> 00:00:01,000
코드를 작성하다

2
00:00:01,000 --> 00:00:04,000
보면 문득 이런 질문이 들 때가 있습니다.

3
00:00:04,000 --> 00:00:11,000
인공지능 도구와 자동화가 코드를 더 빨리 만들어내는 시대에, 과연 어떤 코드가 오래 이해되고 수정될 수 있을까?

4
00:00:11,000 --> 00:00:15,000
그리고 그 코드를 만드는 과정, 즉 '설계'란 무엇일까?

5
00:00:15,000 --> 00:00:19,000
이 질문을 안고 존 오스터하우트의 이라는 책을 다시 펼쳤습니다.

6
00:00:19,000 --> 00:00:25,000
특히 이번 여섯 번째 독서 회차에서는 '두 번 설계하고, 이유를 남겨라'는 메시지가 깊이 다가왔습니다.

7
00:00:25,000 --> 00:00:31,000
책을 읽기 전 저는 '주석'이라는 것을 코드를 설명하는 부수적인 것으로 여기는 경향이 있었습니다.

8
00:00:31,000 --> 00:00:38,000
하지만 이 책은 주석의 역할을 단순히 코드 뒤에 붙는 설명이 아니라, '설계 이유를 보존하는 도구'로 끌어올릴

9
00:00:38,000 --> 00:00:40,000
것이라는 기대를 했습니다.

10
00:00:40,000 --> 00:00:47,000
또, '설계'라는 것이 거창한 아키텍처 선언이 아니라, 매일의 코드 작성 속에서 일상적으로 이루어지는 복잡성

11
00:00:47,000 --> 00:00:49,000
관리라는 점을 더 깊이 이해하고 싶었죠.

12
00:00:49,000 --> 00:00:53,000
이 책은 제가 가졌던 막연한 생각들을 명확하게 정리해주었습니다.

13
00:00:53,000 --> 00:00:57,000
핵심은 '보이지 않는 이유'를 드러내는 장치로서의 설계입니다.

14
00:00:57,000 --> 00:01:04,000
저자는 두 가지 중요한 원칙을 제시하는데, 하나는 '두 번 설계하라 Design it Twice'는 것이고, 다른

15
00:01:04,000 --> 00:01:09,000
하나는 '왜 주석을 남겨야 하는가 Why Write Comments?'입니다.

16
00:01:09,000 --> 00:01:17,000
'두 번 설계하라'는 말은 첫 번째 설계안을 정답이 아니라, 그저 비교를 시작하기 위한 하나의 '후보'로 취급하라는

17
00:01:17,000 --> 00:01:18,000
의미입니다.

18
00:01:18,000 --> 00:01:19,000
우리는 대개 처음

19
00:01:19,000 --> 00:01:22,000
떠오른 아이디어를 너무 쉽게 받아들이곤 하죠.

20
00:01:22,000 --> 00:01:29,000
하지만 이 책은 최소한 두 가지 설계안을 비교할 때 비로소 숨어있던 가정이 드러나고, 각 대안의 장단점이

21
00:01:29,000 --> 00:01:30,000
명확해진다고 말합니다.

22
00:01:30,000 --> 00:01:37,000
저 역시 여러 대안을 고민할 때야 비로소 제가 놓쳤던 부분들이 보였던 경험이 많기에, 이 부분에 깊이 공감했습니다.

23
00:01:37,000 --> 00:01:44,000
설계는 무언가를 '생성'하는 행위라기보다, 여러 가능성 중에서 가장 나은 것을 '비교하고 선택하는' 과정이라는

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

25
00:01:46,000 --> 00:01:49,000
그리고 '주석'에 대한 제 생각도 크게 바뀌었습니다.

26
00:01:49,000 --> 00:01:51,000
흔히 '좋은 코드는 스스로를 설명한다

27
00:01:51,000 --> 00:01:54,000
self-documenting'는 말을 듣곤 합니다.

28
00:01:54,000 --> 00:01:58,000
저 역시 이 말에 현혹되어 주석을 소홀히 한 적이 많습니다.

29
00:01:58,000 --> 00:02:06,000
하지만 책은 명확한 코드가 '무엇'을 하는지는 보여줄 수 있지만, '왜' 그렇게 했는지, '어떤 대안을 고려하다가

30
00:02:06,000 --> 00:02:11,000
지금의 방식을 선택했는지'와 같은 의도와 맥락까지는 말해주지 못한다고 지적합니다.

31
00:02:11,000 --> 00:02:17,000
좋은 주석은 코드의 내용을 중복해서 설명하는 것이 아니라, 설계 판단의 '장기 기억'이라는 것이죠.

32
00:02:17,000 --> 00:02:24,000
미래의 내가, 혹은 동료가 코드를 이해하고 수정해야 할 때, 가장 필요한 정보는 바로 이 '이유'와 '맥락'이라는

33
00:02:24,000 --> 00:02:25,000
겁니다.

34
00:02:25,000 --> 00:02:30,000
이 책을 읽고 난 뒤, 제 작업 방식에 한 가지 중요한 변화를 주려고 합니다.

35
00:02:30,000 --> 00:02:33,000
바로 '코드 리뷰'의 질문을 바꾸는 것입니다.

36
00:02:33,000 --> 00:02:38,000
단순히 "이 코드가 잘 작동하는가?"에서 멈추는 것이 아니라, "이 코드를 다음

37
00:02:38,000 --> 00:02:44,000
변경자가 이해하고 수정하려면 무엇을 알아야 하는가?"라는 질문을 던져보기로 했습니다.

38
00:02:44,000 --> 00:02:48,000
그리고 그 답을 주석이나 짧은 문서 형태로 남기는 연습을 해보려고 합니다.

39
00:02:48,000 --> 00:02:56,000
이는 마치 '아키텍처 결정 기록 Architecture Decision Record'를 코드 가까이에 남기는 것과

40
00:02:56,000 --> 00:02:57,000
연결된다는 생각도 들었습니다.

41
00:02:57,000 --> 00:03:05,000
새로운 모듈을 설계하거나 기존 코드를 수정할 때, 최소한 하나의 다른 설계안을 고민하고, 그 비교 과정을 짧게라도

42
00:03:05,000 --> 00:03:07,000
기록하는 습관을 들이는 것이죠.

43
00:03:07,000 --> 00:03:12,000
이 책은 매일 코드를 작성하고 수정하는 개발자들에게 특히 의미 있는 책이라고 생각합니다.

44
00:03:12,000 --> 00:03:20,000
또, 코드 리뷰를 통해 동료의 성장을 돕고 싶은 리더들, 그리고 인공지능 자동화 시대에 인간 개발자의 역할과 가치에

45
00:03:20,000 --> 00:03:22,000
대해 고민하는 모든 분께 권하고 싶습니다.

46
00:03:22,000 --> 00:03:26,000
결론적으로, 이 책이 저에게 남긴 한 문장은 이렇습니다.

47
00:03:26,000 --> 00:03:33,000
"설계의 품질은 첫 아이디어의 반짝임보다, 대안을 비교하고 그 이유를 남기는 습관에서 나온다." 이 문장을

48
00:03:33,000 --> 00:03:34,000
곱씹으며, 다음

49
00:03:34,000 --> 00:03:35,000
독서 질문을 던져봅니다.

50
00:03:35,000 --> 00:03:42,000
"인공지능 에이전트가 코드를 작성할 때, 과연 이런 '이유'와 '대안'의 흔적을 어떻게 효과적으로 남길 수

51
00:03:42,000 --> 00:03:45,000
있을까?" 그리고 그 흔적이 미래의 나에게 어떤 질문을 던지게 될까요?