1
00:00:00,000 --> 00:00:05,000
The Pragmatic Programmer 5회차를 읽으며 계속 떠오른 말은 유연성입니다.

2
00:00:05,000 --> 00:00:09,000
그런데 이 책이 말하는 유연성은 추상화를 많이 넣는 것이 아닙니다.

3
00:00:09,000 --> 00:00:11,000
모든 미래를 예측하는 것도 아닙니다.

4
00:00:11,000 --> 00:00:17,000
변화가 들어오는 지점을 숨기지 않고, 그 변화가 전체 시스템을 부러뜨리지 않게 만드는 태도입니다.

5
00:00:17,000 --> 00:00:19,000
이 장은 Bend, or Break입니다.

6
00:00:19,000 --> 00:00:21,000
휘어지거나, 부러지거나.

7
00:00:21,000 --> 00:00:23,000
소프트웨어는 변화를 피할 수 없습니다.

8
00:00:23,000 --> 00:00:27,000
요구사항은 바뀌고, 팀은 바뀌고, 데이터는 바뀌고, 도구는 바뀝니다.

9
00:00:27,000 --> 00:00:32,000
문제는 변화가 온다는 사실이 아니라, 변화 하나가 너무 많은 곳을 동시에 흔드는 구조입니다.

10
00:00:32,000 --> 00:00:36,000
Law of Demeter는 이 문제를 인간관계처럼 느끼게 해줍니다.

11
00:00:36,000 --> 00:00:38,000
서로 너무 많이 알면 피곤합니다.

12
00:00:38,000 --> 00:00:39,000
코드도 그렇습니다.

13
00:00:39,000 --> 00:00:44,000
어떤 객체가 다른 객체의 내부 구조까지 줄줄이 알고 있다면, 작은 변경도 멀리 퍼집니다.

14
00:00:44,000 --> 00:00:47,000
좋은 모듈은 협력하지만 사생활을 캐묻지 않습니다.

15
00:00:47,000 --> 00:00:49,000
메타프로그래밍도 인상적이었습니다.

16
00:00:49,000 --> 00:00:53,000
설정과 정책을 코드 안에 박아두면, 바꾸기 위해 다시 배포해야 합니다.

17
00:00:53,000 --> 00:00:58,000
반대로 바뀔 가능성이 큰 규칙을 밖으로 꺼내면 시스템은 조금 더 휘어질 수 있습니다.

18
00:00:58,000 --> 00:01:01,000
이것은 AI 에이전트 하니스에도 그대로 적용됩니다.

19
00:01:01,000 --> 00:01:05,000
프롬프트, 도구 목록, 검증 규칙을 코드에 뒤엉키게 만들면 고치기 어렵습니다.

20
00:01:05,000 --> 00:01:08,000
블랙보드 개념도 지금 읽으면 새롭게 보입니다.

21
00:01:08,000 --> 00:01:14,000
여러 참여자가 하나의 공유 작업판을 보고 각자 기여하는 구조는 오늘날 multi-agent workflow와

22
00:01:14,000 --> 00:01:15,000
닮았습니다.

23
00:01:15,000 --> 00:01:21,000
중요한 것은 똑똑한 에이전트 하나가 아니라, 여러 도구가 안전하게 협력할 수 있는 공유 표면입니다.

24
00:01:21,000 --> 00:01:23,000
오늘의 적용은 세 가지입니다.

25
00:01:23,000 --> 00:01:29,000
긴 연쇄 호출을 줄이고, 환경별로 바뀌는 값을 설정으로 옮기고, 여러 단계가 공유하는 상태를 명시적 작업판으로

26
00:01:29,000 --> 00:01:30,000
만드는 것.

27
00:01:30,000 --> 00:01:33,000
휘어지는 시스템은 모든 것을 예측한 시스템이 아닙니다.

28
00:01:33,000 --> 00:01:35,000
바뀔 수 있는 지점을 숨기지 않은 시스템입니다.