WEBVTT 00:00:04.001 --> 00:00:07.507 준비 됐나요? 00:00:08.922 --> 00:00:10.753 좋습니다. 00:00:22.778 --> 00:00:25.208 저기 빨간 점 보이나요? 00:00:30.020 --> 00:00:31.743 왜 빨간색일까요? 00:00:35.418 --> 00:00:36.934 위험해서라고요? 00:00:37.798 --> 00:00:41.339 마음에 드네요. "이봐! 나를 쿠바로 망명시켜줘." 00:00:43.073 --> 00:00:51.915 그래요. 이 레이저 때문에 공항에서 잡혀간 적도 있었지요. 00:00:51.988 --> 00:00:55.109 거기에는 "DANGER" 이라고 써 붙여 있었어요. 00:00:56.990 --> 00:00:59.148 그나저나 왜 빨간색 일까요? 00:01:01.035 --> 00:01:02.399 나는 초록색 레이저도 있습니다. 00:01:02.469 --> 00:01:05.432 모두 레이저 몇 개 정도는 있어야 해요. 00:01:06.280 --> 00:01:09.323 나는 항상 세 개는 들고 다닙니다. 00:01:11.184 --> 00:01:15.861 그 중 하나가 빨간색인데요. 가방에 배터리와 함께 들고 다닙니다. 00:01:15.901 --> 00:01:17.887 ... 00:01:18.277 --> 00:01:22.806 이 빨간색 레이저는 12달러면 살 수 있습니다. 00:01:24.341 --> 00:01:25.436 빨간색 레이저 보이지요? 00:01:25.460 --> 00:01:28.763 멋지지요? 여기 초록색도 있습니다. 00:01:30.029 --> 00:01:31.272 이 것도 좋아요. 00:01:33.062 --> 00:01:34.684 아주 밝지요. 00:01:34.752 --> 00:01:39.001 특별할 건 없지만 그래도 아주 밝아요. 00:01:39.075 --> 00:01:41.025 이 걸 살짝 개조할 수도 있습니다. 00:01:41.025 --> 00:01:44.585 레지스터 하나를 교체하면 00:01:44.595 --> 00:01:47.797 출력을 0.25와트로 높일 수가 있는데요. 00:01:47.847 --> 00:01:50.857 그러면 풍선 정도는 터트릴 수 있습니다. 00:01:51.668 --> 00:01:54.919 멋지지요. 펑! 00:01:57.124 --> 00:02:00.599 하지만 내가 제일 좋아하는 레이저는 이거입니다. 00:02:02.496 --> 00:02:05.139 왜냐하면 00:02:06.698 --> 00:02:12.734 저기 보이나요? 00:02:14.716 --> 00:02:19.295 작은 보라색 점. 저기 위에 보여요? 00:02:20.906 --> 00:02:24.869 어디 봅시다. 오! 밝게 잘 보이네요. 00:02:25.269 --> 00:02:27.833 여기 바로 위에요. 아주 밝게 잘 보입니다. 00:02:28.344 --> 00:02:31.192 하지만 저기에 비추면 잘 보이지 않아요. 00:02:31.445 --> 00:02:33.524 보이나요? 잘 안보입니다. 00:02:33.559 --> 00:02:35.886 여기에는 보이나요? 아니군요. 00:02:36.492 --> 00:02:39.445 음. 잘 안보여요. 00:02:39.477 --> 00:02:48.820 그런데 이런 걸 발견했어요. 00:02:51.325 --> 00:02:57.433 그냥 사인펜입니다. 레이저를 쏴도 특별히 달라지진 않네요. 00:02:57.465 --> 00:02:59.458 하지만 뚜껑을 보세요. 00:03:02.153 --> 00:03:05.457 노란색이네요! 00:03:05.529 --> 00:03:07.331 파란색이 아닙니다. 00:03:08.210 --> 00:03:11.093 저기 오랜지 색 부분 보이나요? 00:03:11.093 --> 00:03:13.747 잘 보세요. 조심스럽게 겨냥해야 합니다. 00:03:14.353 --> 00:03:17.780 오! 오랜지 색이에요! 00:03:17.838 --> 00:03:19.988 이건 어떤 레이저일까요? 00:03:22.060 --> 00:03:26.491 이 건 조금 다른 레이저입니다. 00:03:33.884 --> 00:03:41.141 내 안경은 햇빛을 받으면 렌즈가 짙어지는데요 00:03:44.719 --> 00:03:47.650 잘 보일지 모르겠지만 렌즈들이 모두 까매졌습니다. 00:03:47.688 --> 00:03:50.853 그렇지요? 여러분들이 안보이네요. 00:03:50.917 --> 00:03:53.470 이건 자외선 레이저입니다. 00:03:53.560 --> 00:03:57.504 하지만 자외선 레이저라고 팔지는 않아요. 아마존에서 17달러면 살 수 있습니다. 00:03:57.504 --> 00:04:01.100 보라색 레이저라고 팔고 있지만 거짓말입니다. 00:04:01.368 --> 00:04:06.948 보라색 레이저 보다 더 멋진 거에요. 자외선 레이저입니다. (역주: Ultra Violet Laser, Violet Laser) 00:04:06.948 --> 00:04:09.637 누구나 자외선 레이저 하나쯤은 있어야 해요. 00:04:09.703 --> 00:04:12.649 레이저 포인터로는 쓸모가 없지만 00:04:12.701 --> 00:04:16.997 안경에 작은 그림들을 그릴 수는 있어요. 00:04:18.598 --> 00:04:21.843 "안경에 이름을 썼어!" 00:04:24.672 --> 00:04:26.507 우야당간...... 00:04:29.240 --> 00:04:31.126 저기 코드를 보세요. 00:04:32.639 --> 00:04:34.428 어떤 코드인지 아는 사람있나요? 00:04:35.765 --> 00:04:38.325 안경 렌즈가 까매서 볼 수 가 없네요. 00:04:38.771 --> 00:04:40.798 어떤 코드인지 알겠나요? 00:04:42.267 --> 00:04:44.242 저건 PDP-8의 소스 코드입니다. 00:04:44.945 --> 00:04:48.863 1970년대의 소스코드는 저렇게 생겼었습니다. 00:04:48.928 --> 00:04:54.753 내가 20살 즈음에 저런 코드를 작성했었지요. 00:04:55.825 --> 00:04:58.618 20대 초반에도 그랬습니다. 00:05:00.074 --> 00:05:03.543 저 소스 코드를 보세요. 00:05:03.979 --> 00:05:06.305 어떤 의미인지 아는 사람 있나요? 00:05:07.940 --> 00:05:13.611 프로그램이 메모리에 로딩될 주소입니다. 00:05:15.334 --> 00:05:20.159 당시에는 소스 코드에 프로그램이 로딩될 주소를 명시했었습니다. 00:05:21.160 --> 00:05:23.551 이 프로그램은 메모리 주소 200에 로딩될 겁니다. 00:05:24.245 --> 00:05:26.996 그리고 데이터는 300에 저장됩니다. 00:05:27.042 --> 00:05:28.052 어떤가요? 00:05:28.669 --> 00:05:32.636 당연한거에요. 여러분은 프로그램이 어느 주소에 로딩될지 알아야 합니다. 00:05:32.668 --> 00:05:34.836 여러분 말고 또 누가 그걸 결정하겠어요? 00:05:34.905 --> 00:05:37.708 프로그래머가 메모리를 컨트롤 해야지요. 00:05:39.471 --> 00:05:41.323 이대로는 아무런 문제가 없습니다. 00:05:43.026 --> 00:05:45.572 다른 그림들도 보여드릴게요. 00:05:46.268 --> 00:05:50.080 어디 봅시다. 00:05:50.151 --> 00:05:55.087 이게 아니네요. 이 그림 말고 다른 게 있습니다. 00:05:56.140 --> 00:06:01.655 요즘은 문서를 열면 00:06:02.386 --> 00:06:09.623 같이 열렸던 문서들이 모두 같이 열려버려요. 00:06:10.509 --> 00:06:12.138 저장할 필요 없고요. 00:06:12.177 --> 00:06:14.630 이게 찾던 그림니다. 00:06:17.049 --> 00:06:20.356 여러분이 이런 개발 언어를 사용한다고 생각해보세요. 00:06:20.899 --> 00:06:23.826 그리고 이런 프로그램을 작성하는 거지요. 00:06:24.626 --> 00:06:28.010 이 프로그램은 여기에 위치합니다. 주소 200에서 시작하지요. 00:06:28.900 --> 00:06:32.107 여기 다른 사람이 작성한 서브루틴 라이브러리가 있습니다. 00:06:32.524 --> 00:06:35.145 그나저나 그 당시에는 서브루틴 라이브러리가 드물었지요. 00:06:35.229 --> 00:06:37.768 필요한 서브루틴은 직접 작성하곤 했습니다. 00:06:37.818 --> 00:06:45.607 몇 몇 사람이 아주 유용한 서브루틴을 작성한 후에야 사람들은 자신의 프로그램에 그 것들을 넣기 시작했습니다. 00:06:45.637 --> 00:06:50.378 "그냥 프로그램에 추가해서 같이 컴파일 합시다." 00:06:50.411 --> 00:06:51.663 보통 그런 방식으로 했지요. 00:06:51.695 --> 00:06:53.496 서브루틴의 소스 코드를 가져와서 내 코드와 합치는 거죠. 00:06:53.531 --> 00:06:55.465 그럼 어떤 문제가 있을까요? 00:06:58.735 --> 00:07:02.218 지금 우린 1970년대를 이야기하고 있습니다. 00:07:02.314 --> 00:07:05.566 그 당시 프로그램은 종이 테이프에 저장되었습니다. 00:07:06.124 --> 00:07:10.498 종이 테이프는 초당 50문자 정도를 저장했습니다. 운이 좋은 경우에요. 00:07:10.534 --> 00:07:19.939 그래서 소스 코드가 길어지면 컴파일 타임이 몇 분씩이나 길어지곤 했습니다. 00:07:20.346 --> 00:07:26.642 그러다 보면 서브루틴 라이브러리가 너무 길어서 같이 컴파일 하지 못하는 경우도 생깁니다. 00:07:26.642 --> 00:07:35.124 그런 경우는 서브루틴 라이브러리를 따로 컴파일 해서 메모리 주소 1200에 로딩합니다. 00:07:35.847 --> 00:07:42.367 메모리 주소 1200에 컴파일된 바이너리 파일을 로딩하는 겁니다. 00:07:42.417 --> 00:07:45.363 메인 프로그램은 메모리 주소 200에 로딩합니다. 00:07:45.396 --> 00:07:49.044 그리고 심볼 정보를 담은 작은 파일이 있어요. 00:07:49.122 --> 00:07:55.016 심볼을 보고 각 서브 루틴들이 어디에 로딩되어 있는지를 알 수 있습니다. 00:07:55.016 --> 00:08:03.131 예를 들어 Get 서브루틴이 205번지에 있고 Put 서브루틴이 210번지에 있다는 것을 알 수 있는 거지요. 00:08:03.518 --> 00:08:06.998 심볼 정보들은 프로그램과 함께 컴파일이 됩니다. 00:08:07.032 --> 00:08:09.907 서브루틴 라이브러리는 따로 로딩됩니다. 그리곤 잘 동작하겠지요. 00:08:12.236 --> 00:08:14.215 그럼 무엇이 문제일까요? 00:08:15.705 --> 00:08:19.428 프로그램 크기가 변하지 않는 경우가 있을까요? 00:08:20.839 --> 00:08:22.122 프로그램은 항상 커집니다! 00:08:22.634 --> 00:08:26.489 계속 커지다 보면...... 어디 봅시다. 00:08:28.017 --> 00:08:29.632 여기 다른 그림이 있어요. 00:08:34.783 --> 00:08:36.475 네 이겁니다. 00:08:40.664 --> 00:08:43.767 자! 메인 프로그램이 아주 커졌어요. 00:08:43.767 --> 00:08:47.278 서브루틴을 덮어 써버렸네요. 정상적으로 동작하지 않습니다. 00:08:49.171 --> 00:08:56.041 메인 프로그램이 서브루틴을 덮어써버렸지만 메인 프로그램은 그걸 모릅니다. 00:08:56.073 --> 00:09:02.337 메인 프로그램이 1205번지를 호출하면 서브루틴이 아닌 자기의 어딘가를 실행하게 됩니다. 00:09:02.577 --> 00:09:04.491 개발자도 어떤 상황인지 몰라요. 00:09:04.510 --> 00:09:08.095 한참 디버깅 한 뒤에야 깨닫습니다. "이런, 프로그램이 너무 커져버렸네!" 00:09:08.914 --> 00:09:11.360 그럼 어떻게 해결해야 할까요? 00:09:13.744 --> 00:09:17.567 여러분들은 프로그래머자나요? 잘 생각해보세요. 00:09:20.598 --> 00:09:23.282 서브루틴 라이브러리를 건너 뛰는 겁니다. 00:09:23.954 --> 00:09:27.486 서브루틴들을 피해서 메인 프로그램을 배치하고 실행하는 거지요. 00:09:28.322 --> 00:09:31.370 그런데 서브루틴 라이브러리도 점점 커집니다. 00:09:32.140 --> 00:09:39.809 그러고 나면...... 이 그림이 맞는지 봅시다. 00:09:39.842 --> 00:09:42.093 이건가? 네 맞습니다. 00:09:42.505 --> 00:09:45.243 그러고 나면 이런 문제가 생깁니다. 00:09:48.209 --> 00:09:50.504 실제 현장에서 발생하던 문제들입니다. 00:09:51.014 --> 00:09:53.910 이런 문제들을 해결해야만 했었습니다. 00:09:53.946 --> 00:09:55.702 어떻게 해결했는지 알겠나요? 00:09:59.595 --> 00:10:04.698 우리는 재배치할 수 있는 코드를 생각해냈습니다. 00:10:04.730 --> 00:10:10.495 "이봐, 프로그램을 절대 주소 값에 로딩하는 건 너무 문제가 많아." 00:10:10.528 --> 00:10:17.440 "코드에 프로그램이 로딩될 위치를 넣지 않고 컴파일 하는 방법이 필요해." 00:10:17.813 --> 00:10:20.630 "로더에게는 로딩할 위치를 따로 알려주는 거야." 00:10:21.435 --> 00:10:23.141 그러려면 또 다른 이슈가 있습니다. 00:10:23.632 --> 00:10:29.658 바이너리 파일이 순수한 바이너리가 아니게되는 것 입니다. 00:10:29.705 --> 00:10:38.706 어떤 숫자는 주소가 아니라 오프셋이라고 말해주는 정보가 바이너리에 추가되기 때문이지요. 00:10:39.030 --> 00:10:47.994 로더는 오프셋으로 표시된 모든 주소에 시작 주소를 더해야만 합니다. 00:10:49.321 --> 00:10:51.940 결과적으로 재배치 가능한 로더는 잘 동작했습니다. 00:10:51.988 --> 00:10:54.619 재배치 가능한 바이너리와 로더를 개발했습니다. 00:10:54.619 --> 00:10:57.034 하지만 새로운 문제가 생겼습니다. 00:10:57.234 --> 00:11:00.415 서브루틴이 어디에 있는지를 알아야만 했지요. 00:11:00.447 --> 00:11:05.737 서브루틴이 임의로 배치된다면 어떻게 로딩된 위치를 알 수 있을까요? 00:11:06.007 --> 00:11:11.043 결국 그 정보도 바이너리 파일에 추가되어야 합니다. 00:11:11.264 --> 00:11:19.687 처음에는 순수한 바이너리였던 파일이 점점 괴상한 파일이 되어 버립니다. 00:11:19.726 --> 00:11:21.301 파일안에 온갖 잡다한 것들이 들어가있지요. 00:11:21.372 --> 00:11:28.293 이제 바이너리 파일 안에는 서브루틴들의 이름이 들어가야 합니다. 00:11:28.357 --> 00:11:32.468 그리고 각 서브루틴이 어디에 로딩될지도 알려줘야 하지요. 00:11:32.523 --> 00:11:37.614 그리고 로더는 각 서브루틴을 어디에 로딩했는지 기억해야 합니다. 00:11:37.682 --> 00:11:42.622 그런 후에 프로그램에는 또 필요한 것이 있습니다. 00:11:42.694 --> 00:11:47.250 그건 이렇게 말하겠지요. "이봐, 난 이 프로그램들이 어디에 로딩될지 알아야겠어." 00:11:47.250 --> 00:11:53.432 "그리고 로더는 프로그램이 사용하는 서브루틴들을 링크해야 해." 00:11:57.322 --> 00:12:00.831 그 당시의 컴퓨터는 느렸습니다. 00:12:00.899 --> 00:12:02.548 디스크도 매우 느렸지요. 00:12:02.626 --> 00:12:04.539 메모리도 많지 않았습니다. 00:12:04.621 --> 00:12:08.102 디스크도 운이 좋으면 몇 MB 정도 가질 수 있었지요. 00:12:08.173 --> 00:12:14.636 디스크의 탐색 속도도 매우 느렸습니다. 00:12:14.673 --> 00:12:18.136 그래서 링크 시간이 아주 오래 걸렸지요. 00:12:18.201 --> 00:12:22.206 라이브러리가 늘어나면서 점점 더 심해졌습니다. 00:12:22.257 --> 00:12:23.743 프로그램이 더 많아지고 커지면서 00:12:23.784 --> 00:12:26.032 링크하는데에 한 시간도 걸렸습니다. 00:12:26.082 --> 00:12:28.448 여기 링크에 한 시간이나 걸리는 사람이 있나요? 00:12:28.480 --> 00:12:30.845 여기 80년대에서 일하는 사람이 있어요? 00:12:30.880 --> 00:12:32.694 이런! 지금도 그렇게 오래 걸린다고요? 00:12:32.776 --> 00:12:35.263 그럼 C++ 프로그래머겠군요. 00:12:36.524 --> 00:12:38.661 거기 셔츠에 써있어요. 00:12:38.701 --> 00:12:40.747 OSLO C++ User Group 이라고요. 00:12:41.137 --> 00:12:42.647 링크 시간이 너무 길어지는 문제는 00:12:45.358 --> 00:12:50.458 70년대에도 있었습니다. 그때 프로그램은 훨씬 작았었지만요. 00:12:50.500 --> 00:12:57.964 해결책은 로딩 중에 링크 단계를 제거하는 거였습니다. 00:12:57.964 --> 00:13:02.302 링크는 컴파일에 포함되어 두 번째 단계로 수행됐습니다. 00:13:02.302 --> 00:13:07.435 컴파일이 끝나면 모든 링크 정보가 포함된 재배치 가능한 파일이 만들어 졌습니다. 00:13:07.468 --> 00:13:10.141 결과적으로 프로그램 실행 시점에 로딩이 가능해졌습니다. 00:13:10.141 --> 00:13:12.488 속도도 상대적으로 빨랐습니다. 00:13:13.287 --> 00:13:17.964 그 후 여러 해 동안 이 방식이 유지되었습니다. 00:13:18.015 --> 00:13:24.358 먼저 컴파일 해서 바이너리 파일을 만들고 바이너리 파일들을 링크해서 실행파일을 만듭니다. 00:13:24.401 --> 00:13:26.497 그런 후에 실행 파일은 로딩할 수 있게 됩니다. 00:13:26.531 --> 00:13:29.877 90년대까지 그런 방식을 유지했어요. 00:13:29.942 --> 00:13:33.540 그러다 90년대에 변화가 생겼습니다. 00:13:33.588 --> 00:13:36.238 무어의 법칙입니다. 00:13:36.772 --> 00:13:38.009 무어의 법칙이 무엇이지요? 00:13:39.302 --> 00:13:43.558 프로세서는 18개월 마다 두 배씩 빨라진다는 것 입니다. 00:13:43.671 --> 00:13:52.960 1970년대부터 적용해봅시다. 당시의 프로세서는 0.5 MIPS 정도의 처리 능력을 가졌습니다. 00:13:53.640 --> 00:13:56.959 그런 게 1990년대까지 진행되었지요. 00:13:57.025 --> 00:13:59.999 그럼 20년이면 18개월이 몇 번이나 지난 것 이지요? 00:14:00.048 --> 00:14:02.176 18개월이 몇 번 이지요? 00:14:02.176 --> 00:14:03.981 대략 15번 정도네요. 00:14:03.981 --> 00:14:07.257 그럼 2의 15승 이네요. 00:14:08.369 --> 00:14:09.286 어디봅시다. 00:14:09.338 --> 00:14:11.523 2의 15승이면 얼마나 되지요? 00:14:11.602 --> 00:14:13.700 대략 32000 정도 향상된 거네요! 00:14:13.700 --> 00:14:15.171 실제로도 대략 비슷합니다. 00:14:15.223 --> 00:14:18.751 0.5MHz에서 2.8GHz로 증가했으니까요. 00:14:18.786 --> 00:14:21.746 음 90년대에는 1GHz 정도였겠지요. 00:14:21.787 --> 00:14:24.907 당시에는 디스크의 성능도 좋아졌습니다. 00:14:24.941 --> 00:14:27.232 디스크의 회전 속도가 빨라졌습니다. 00:14:27.300 --> 00:14:31.782 플래터에 저장되는 데이터도 훨씬 많아져서 헤드가 움직이는 거리도 짧아졌지요. 00:14:31.830 --> 00:14:38.692 용량이 수백MB나 되는 디스크도 나왔습니다. 00:14:40.512 --> 00:14:44.219 누군가 아주 좋은 아이디어를 냈습니다. 00:14:44.270 --> 00:14:46.157 아주 좋은 아이디어에요. 00:14:47.454 --> 00:14:50.440 "이제 링크를 따로 할 필요가 없겠는걸." 00:14:51.042 --> 00:14:54.378 "로딩할때 같이 링크해도 되겠네." 00:14:54.424 --> 00:14:56.582 ActiveX를 기억하나요? 00:14:56.621 --> 00:14:58.946 OLE는요? 00:14:59.546 --> 00:15:01.917 DLL이 무엇의 약어이지요? 00:15:04.119 --> 00:15:08.215 Dynamically Linked Library. 00:15:08.258 --> 00:15:11.120 로딩될 때에 링크된다는 뜻 입니다. 00:15:11.153 --> 00:15:14.817 링크 단계가 다시 로더에게 넘어갔습니다. 00:15:15.699 --> 00:15:19.203 그렇게 지금까지 이어져왔습니다. 00:15:20.762 --> 00:15:22.616 여기 닷넷 프로그래머 있나요? 00:15:23.668 --> 00:15:25.037 오! 아주 많군요. 00:15:25.070 --> 00:15:28.122 자바 프로그래머 손들어 보세요. 00:15:28.189 --> 00:15:29.952 얼마 없네요. 어떻게 된 거지요? 00:15:31.001 --> 00:15:35.314 어떻게 닷넷 개발자만 있나요? 아... 이 컨퍼런스가 닷넷 관련된 행사 인가요? 00:15:36.034 --> 00:15:41.840 닷넷에는 DLL이 있습니다. 00:15:41.872 --> 00:15:43.732 Dynamically Linked Libraries. 00:15:43.765 --> 00:15:45.922 자바에는 Jar 파일이 있습니다. 00:15:45.969 --> 00:15:50.940 Jar 파일도 결국 DLL입니다. 같은 의도로 만들어 졌지요. 00:15:51.780 --> 00:15:56.055 C++는...... MS 환경에서 작업을 하면 DLL을 사용합니다. 00:15:56.088 --> 00:15:58.850 UNIX 계열 환경에서 작업을 하면 Shared Library가 있는데요 00:15:58.850 --> 00:16:01.031 이 것도 역시 DLL과 동일합니다. 00:16:01.080 --> 00:16:05.131 지금도 동적으로 링크하는 방식이 일반적인데요 00:16:05.165 --> 00:16:07.867 이런 과정들을 거쳐 현재까지 왔습니다. 00:16:11.980 --> 00:16:13.626 DLL을 몇 개나 가지고 있나요? 00:16:15.342 --> 00:16:18.575 비주얼 스튜디오에서 작업하는 사람들 00:16:18.608 --> 00:16:20.415 솔루션에 프로젝트가 몇 개나 있나요? 00:16:21.315 --> 00:16:23.550 60개? 그다지 나쁘지 않네요. 00:16:23.550 --> 00:16:25.017 60개 보다 많은 사람? 00:16:25.060 --> 00:16:26.597 있군요. 00:16:26.635 --> 00:16:28.094 200개 이상 되는 사람? 00:16:30.942 --> 00:16:33.132 왜 그렇게 하는지 아나요? 00:16:33.215 --> 00:16:38.055 왜 소스 코드를 쪼개서 DLL들에 분산시켜 놓는지 아나요? 00:16:38.886 --> 00:16:40.692 질문을 다르게 해보겠습니다. 00:16:41.272 --> 00:16:43.624 어플리케이션을 배포할 때에 00:16:44.590 --> 00:16:50.366 모든 DLL을 모아서 한 묶음으로 배포하나요? 00:16:52.521 --> 00:16:57.677 그렇다면 왜 동적으로 링크하지요? 00:16:57.728 --> 00:16:59.395 정적으로 링크하세요. 00:17:00.269 --> 00:17:04.819 왜 굳이 동적으로 링크하지요? 모든 DLL을 모아서 00:17:04.887 --> 00:17:07.260 하나의 거대한 덩어리로 만들고 00:17:07.313 --> 00:17:10.358 그 덩어리를 디렉터리에 저장한 후에, "이게 우리 시스템이야" 00:17:11.996 --> 00:17:16.857 동적으로 배포 안 하는데 왜 동적으로 링크하지요? 00:17:17.540 --> 00:17:21.675 왜 동적 라이브러리가 생겨났지요? 00:17:21.742 --> 00:17:28.603 동적 라이브러리는 동적으로 배포하기 위해서 만들어진 겁니다. 00:17:29.093 --> 00:17:30.155 왜지요? 00:17:32.571 --> 00:17:35.630 네트워크 속도는 조금 있다 이야기 하겠습니다. 잠시만요. 00:17:35.676 --> 00:17:38.946 네트워크 속도로 인한 변화는 이야기할게 아주 많습니다. 00:17:38.996 --> 00:17:43.985 90년대에 한 고객이 있었습니다. 실행 파일 크기가 250MB 정도였는데요 00:17:43.985 --> 00:17:46.594 그 당시에는 아주 큰 프로그램이었습니다. 지금은 아니지만요. 00:17:47.267 --> 00:17:51.733 그 당시 250MB는 아주 큰 용량이었습니다. CD 한 장에 들어가지도 않았지요. 00:17:52.250 --> 00:17:57.127 CAD 프로그램이었지요. 포드 같은 회사에 납품했었습니다. 00:17:57.127 --> 00:18:01.548 포드는 이 프로그램으로 기어나 레버 등을 디자인했습니다. 00:18:02.876 --> 00:18:04.331 그 고객은 이 프로그램을 정적으로 컴파일 했지요. 00:18:05.035 --> 00:18:11.207 배포하기 위해 CD 여러장이 필요했습니다. 00:18:11.844 --> 00:18:15.109 소스 코드 한 줄이 수정되면 00:18:16.782 --> 00:18:26.422 다시 컴파일 하고 링크한 후에 모든 CD를 다시 구워서 고개들에게 전달해야 했습니다. 00:18:27.237 --> 00:18:29.756 얼마나 많은 비용이 들었을지 상상이 갈 겁니다. 00:18:31.981 --> 00:18:34.189 나는 90년대 중반에 거기에 갔었어요. 00:18:34.246 --> 00:18:36.615 그들을 만났습니다. 00:18:36.665 --> 00:18:44.005 당시에 그들은 실행파일을 여러 개의 DLL로 쪼개려고 하고 있었는데요. 00:18:44.262 --> 00:18:48.902 왜냐하면 여러 개의 DLL로 실행파일을 분리해 놓으면 00:18:48.902 --> 00:18:52.166 소스 코드가 한 줄 바뀌었을 때에 00:18:52.205 --> 00:18:56.740 관련된 DLL 하나만 배포하면 되기 때문이지요. 00:18:57.545 --> 00:19:01.125 이메일로 보낼 수 도 있었습니다. 그 당시에는 그것도 큰 일 이었지요. 00:19:01.168 --> 00:19:03.370 그 당시에 이메일로는 250MB 파일을 보낼 수 없었습니다. 00:19:03.439 --> 00:19:07.631 요즘에야 어렵지 않지만 00:19:07.703 --> 00:19:17.166 당시에는 250MB를 이메일로 보내는 건 불가능했습니다. 하지만 100KB 크기의 DLL을 보내는건 가능했지요. 00:19:17.219 --> 00:19:20.058 그 고객에겐 아주 바람직한 것이었습니다. 00:19:20.058 --> 00:19:22.188 몇 달을 노력을 해서 00:19:22.188 --> 00:19:24.972 어플리케이션을 잘게 쪼개서 00:19:25.010 --> 00:19:26.933 여러 개의 DLL로 만들었지요. 00:19:27.021 --> 00:19:29.465 그런 후에 치명적인 실수를 깨달았습니다. 00:19:30.557 --> 00:19:35.474 치명적인 실수는 시스템을 임의의 DLL들로 쪼개는 것이 00:19:35.474 --> 00:19:39.293 아무런 도움이 안 된다는 것 입니다. DLL들이 서로 서로 의존하는 상황이라면요. 00:19:40.189 --> 00:19:42.742 DLL들이 서로 의존하고 있는 상황이라면...... 00:19:51.828 --> 00:19:56.005 여기 스캇 마이어의 세미나에 들어갔던 사람 있나요? 00:19:56.091 --> 00:19:58.434 한 시간 전에 그가 한 연설이요. 00:19:58.466 --> 00:20:01.075 열쇠구멍 문제에 대한 이야기였지요. 00:20:01.126 --> 00:20:07.846 열쇠구멍 문제라는 것은 아무런 이유 없이 임의로 제약을 주는 것을 이야기합니다. 00:20:07.894 --> 00:20:09.813 그냥 임의로 사람들을 구속하는 겁니다. 00:20:09.849 --> 00:20:14.522 GUI를 예로 들면 00:20:14.572 --> 00:20:16.453 너무 작은 텍스트 박스를 본 적이 있지요? 00:20:16.521 --> 00:20:21.868 텍스트 박스에 내용을 많이 적었는데 크기를 조절 할 수 없는 경우 말이에요. 00:20:21.868 --> 00:20:25.885 심지어 스크롤도 불가능해서 잘 안 보이는 채로 입력한 적 있지 않나요? 00:20:25.930 --> 00:20:29.602 아니면 스크롤은 할 수 있지만 텍스트의 일부분이 가려지는 경우는요? 00:20:29.656 --> 00:20:34.728 이게 그가 말한 열쇠구멍 문제입니다. 00:20:34.795 --> 00:20:38.273 그런데 여기에서도 그런 문제가 있어요. 00:20:39.093 --> 00:20:43.362 "나는 항상 키보드로 작업을 해야 합니다. 5분이상 손을 떼고 있으면 안 되요." 00:20:43.412 --> 00:20:48.041 "너무 오래 손을 떼고 있으면 벌을 받게 되요." 00:20:52.043 --> 00:20:54.513 무슨 이야기를 하고 있었지요? 아 DLL. 00:20:54.513 --> 00:20:58.225 그래서 그 사람은 모든 DLL을 한 군데에 모았습니다. 00:20:58.276 --> 00:21:00.500 그런데 DLL들이 서로 서로 의존하고 있다는 것을 잊고 있었어요. 00:21:00.534 --> 00:21:04.391 원래 목표는 소스 코드 한 줄을 수정하면 00:21:04.423 --> 00:21:07.752 관련된 DLL 하나 만 배포하는 것 있었지요. 00:21:07.821 --> 00:21:12.386 '#includes.' C++ 개발자들은 내가 무슨 이야기하는지 알 겁니다. 00:21:12.450 --> 00:21:15.307 그런데 모든 '#includes' 들이 끔찍하게 얽혀있다는 것을 깨닫게 되었습니다. 00:21:15.358 --> 00:21:18.146 모두 다시 컴파일하고 다 같이 배포해야만 했던 거지요. 00:21:18.218 --> 00:21:19.680 결국 그들의 사업을 망했습니다. 00:21:22.666 --> 00:21:27.814 오늘 강연의 주제는 00:21:29.349 --> 00:21:31.336 컴포넌트에 대한 것 입니다. 00:21:31.381 --> 00:21:33.408 컴포넌트 레벨의 디자인 문제들 이지요. 00:21:33.480 --> 00:21:36.167 가장 먼저 해야 할 것은 '컴포넌트'에 대한 정의입니다. 00:21:36.213 --> 00:21:38.665 컴포넌트는 무엇인가요? DLL입니다. 00:21:39.475 --> 00:21:42.531 이제부터 말하는 컴포넌트는 DLL을 이야기하는 겁니다. 00:21:42.565 --> 00:21:47.002 특정한 종류의 DLL 입니다. 동적으로 배포가 가능한 DLL이요. 00:21:49.185 --> 00:21:52.573 동적으로 배포 가능한 DLL. 00:21:53.473 --> 00:21:55.929 왜 동적으로 배포해야 할까요? 00:21:56.816 --> 00:21:59.877 그건 소스 코드 한 줄이 변경되었을 때에 00:21:59.926 --> 00:22:03.113 다른 DLL은 그대로 두고 변경된 DLL 한 개만 배포하려고 이겠지요. 00:22:03.163 --> 00:22:05.399 'DLL 지옥'이 어떤 뜻이지요? 00:22:05.448 --> 00:22:09.273 Microsoft에서 자기들의 문제를 표현하기 위해 00:22:10.135 --> 00:22:12.442 정의한 용어입니다. 00:22:12.509 --> 00:22:17.506 그리고 닷넷이 나오면서 해결됐어야 했지요. 00:22:17.540 --> 00:22:22.185 그 문구 기억하나요? "닷넷이 DLL 지옥을 치료합니다." 00:22:22.185 --> 00:22:27.531 하하하! 치료하지 못했지요. 00:22:27.541 --> 00:22:32.285 DLL 지옥이란 수많은 컴포넌트들이 각각 다른 버전을 가지고 있을 때에 00:22:32.285 --> 00:22:35.084 서로 맞는 짝이 어떤 것인지 모르는 상태를 이야기합니다. 00:22:35.150 --> 00:22:38.669 그래서 Maven 같은 툴이 나왔지요. 00:22:38.742 --> 00:22:40.642 닷넷에는 어떤 툴을 사용하나요? 00:22:41.176 --> 00:22:45.925 여러 버전들의 DLL들을 관리해주는 툴 말입니다. 00:22:45.974 --> 00:22:50.143 이 DLL의 버전 1과 저 DLL의 버전 3을 같이 다운받을 수 있게 하는 툴이요. 00:22:50.176 --> 00:22:52.714 그런 툴이 있나요? 00:22:53.961 --> 00:22:54.957 너겟 이요? (역주: NuGet과 음식 너겟(Nugget)의 발음이 유사함) 00:22:54.957 --> 00:22:56.854 부드럽고 맛있는 치킨 너겟이요? 00:22:58.944 --> 00:23:00.720 됐습니다. 00:23:09.766 --> 00:23:17.987 화면의 저 그래프는 x의 제곱 그래프입니다. 00:23:18.477 --> 00:23:20.371 그냥 x의 제곱 그래프에요. 00:23:21.242 --> 00:23:23.102 하지만 다른 의미도 있습니다. 00:23:23.134 --> 00:23:29.186 저 Y 축은 시스템의 모듈 개수 입니다. 00:23:29.276 --> 00:23:33.748 모듈의 수에 따라서 가능한 의존 관계의 최대 개수입니다. 00:23:33.798 --> 00:23:38.206 모듈 개수가 선형적으로 증가할 때에 00:23:38.256 --> 00:23:40.969 의존 관계는 제곱에 비례해서 증가합니다. 00:23:44.473 --> 00:23:48.699 이론적으로 연관 관계의 최대 개수는 00:23:50.586 --> 00:23:54.750 모듈 수의 제곱에 비례합니다. 00:23:54.786 --> 00:24:01.275 물론 시스템의 모듈들이 서로 마구 마구 의존하게 만들지는 않을 겁니다. 00:24:02.578 --> 00:24:03.733 설마 그러고 있나요? 00:24:06.355 --> 00:24:08.209 그래프를 봅시다. 00:24:09.181 --> 00:24:19.898 모듈의 수에 따른 팀의 생산성을 보여주는 그래프입니다. 00:24:19.898 --> 00:24:24.953 그나저나 이건 그냥 x의 마이너스 제곱 그래프입니다. 00:24:25.389 --> 00:24:28.168 실제 데이터를 수집해서 만든 게 아닙니다. 00:24:28.935 --> 00:24:34.197 그간 겪어온 다양한 사례들을 생각하면서 임의로 만들어 본겁니다. 00:24:34.197 --> 00:24:38.003 시간이 지나면서 점점 개발 속도가 느려졌던 개발팀들을 생각하면서 말입니다. 00:24:38.035 --> 00:24:39.495 혹시 경험해본 적 있나요? 00:24:39.532 --> 00:24:42.367 초기에는 아주 빠른 속도로 개발을 하지요. 세상을 정복할 기세로 말입니다. 00:24:42.416 --> 00:24:45.923 하지만 1년 지난 후에는 늪지대를 지나는 것처럼 느려져 있지요. 00:24:46.366 --> 00:24:48.664 왜 느려졌는지도 몰라요. 00:24:48.721 --> 00:24:52.936 예전에는 1주일이면 가능했던 일이 이제 석 달은 필요합니다. 00:24:53.378 --> 00:24:58.136 그런데 막상 작업하면 버그가 너무 많이 생겨서 석 달도 부족해져요. 00:24:58.212 --> 00:25:04.435 개발 기간이 길어지다보면 나타나는 문제들입니다. 00:25:04.480 --> 00:25:09.831 그 원인 중 하나는 의존 관계가 많아지는 것 입니다. 00:25:10.571 --> 00:25:11.522 왜 그럴까요? 00:25:11.842 --> 00:25:20.778 저건 모듈 끼리 가질 수 있는 의존 관계의 최대치입니다. 00:25:20.823 --> 00:25:22.847 이건 최소의 경우이지요. 00:25:23.172 --> 00:25:28.910 연관된 모듈들은 서로 의존하기 마련입니다. 00:25:28.966 --> 00:25:32.231 트리 형태일 때가 의존도가 제일 적습니다. 00:25:32.231 --> 00:25:35.620 동적으로 링크한다면 더 적게 만들 수도 있겠지요. 00:25:35.620 --> 00:25:39.531 하지만 보통은 작은 수의 의존 관계를 갖게 됩니다. 00:25:39.573 --> 00:25:42.272 의존 관계가 몇 개 있지요? 1. 2. 3. 4. 5. 6. 00:25:42.272 --> 00:25:44.587 모듈 7개 중에 6개로군요. 00:25:44.627 --> 00:25:46.659 반면에 여기에는 00:25:46.659 --> 00:25:50.570 아마도 49의 절반인가 보군요. 00:25:50.570 --> 00:25:54.202 아니죠 그럼 너무 숫자가 적겠네요. 00:25:54.257 --> 00:25:58.264 그럼 그냥 49개인가요? 모르겠네요. 어쨌든 아주 많습니다. 00:25:58.349 --> 00:26:01.067 아마도 몇 인가의 제곱에 비례하겠지요. 00:26:01.133 --> 00:26:03.280 어쩌면 0.5 * (n^2 + 1) 일 수도 있겠습니다. 00:26:03.362 --> 00:26:04.893 뭐 그런 식이겠지요. 00:26:04.923 --> 00:26:07.859 어찌되었건 의존 관계의 수가 아주 많습니다. 00:26:07.892 --> 00:26:10.906 우리가 원하는 건 이게 아니라 저 트리 모양입니다. 00:26:10.974 --> 00:26:13.134 저렇게 만들기 위해서 노력을 많이 해야 합니다. 00:26:13.168 --> 00:26:21.088 그런데 어떤 얼간이가 이렇게 만들어버립니다. 00:26:24.111 --> 00:26:26.011 비주얼 스튜디오는 이런 걸 금지합니다. 00:26:27.014 --> 00:26:28.507 하지만 비주얼 스튜디오 솔루션 내에서만 해당되지요. 00:26:29.029 --> 00:26:34.189 비주얼 스튜디오 솔루션에 속한 프로젝트들은 순환 참조를 할 수가 없습니다. 00:26:34.243 --> 00:26:35.019 아주 바람직한 거지요. 00:26:35.086 --> 00:26:36.004 순환 참조를 막아주니까요. 00:26:36.473 --> 00:26:38.744 하지만 솔루션들 간에는 보장되지 않습니다. 00:26:38.778 --> 00:26:40.359 비주얼 스튜디오의 솔루션이 여러 개 있다면요 00:26:40.407 --> 00:26:45.270 서로 다른 솔루션에서 빌드된 것들을 링크한다면 여전히 순환 참조가 가능해집니다. 00:26:45.304 --> 00:26:50.766 저렇게 순환 참조를 만들면 그냥 의존 관계가 하나 늘어난 것처럼 보이지요. 00:26:51.385 --> 00:26:52.776 하지만 그냥 하나만 추가되는 게 아닙니다. 00:26:52.817 --> 00:26:57.299 왜냐하면 6번이 2번을 참조합니다. 1번도 2번을 참조하지요. 00:26:57.371 --> 00:26:59.139 의존관계는 전이됩니다. 00:26:59.230 --> 00:27:04.568 그래서 6번은 4번과 5번을 의존합니다. 그리고 6번은 3번과 7번을 의존하지요. 00:27:04.771 --> 00:27:06.851 결국 6번은 모든 모듈에 의존하는 셈입니다. 00:27:07.561 --> 00:27:13.921 그래서 순환 참조를 가지는 순간 의존관계의 수는 급격하게 늘어나게 됩니다. 00:27:21.943 --> 00:27:23.726 다시 n의 제곱 그래프입니다. 00:27:25.092 --> 00:27:28.693 동시에 C++ 컴파에 걸리는 시간의 그래프이기도 하지요. 00:27:28.759 --> 00:27:31.253 모듈을 추가함에 따라 00:27:31.352 --> 00:27:34.100 정적으로 링크한다면 컴파일 시간과 링킹 시간이 제곱에 비례해서 증가합니다. 00:27:34.100 --> 00:27:35.737 하지만 정적으로 링크하지 않는 경우에도 마찬가지입니다. 00:27:35.793 --> 00:27:39.881 컴파일 시간은 모듈 수의 제곱에 비례해서 증가합니다. 00:27:39.935 --> 00:27:44.671 모든 모듈들이 서로 의존하고 있다면 말입니다. 00:27:44.736 --> 00:27:52.241 '#include', import, using 구문들이 순환되게 참조하고 있다면 말입니다. 00:27:53.119 --> 00:27:58.560 그렇게 되어 있다면 컴파일 타임이 아주 크게 증가해버립니다. 00:27:58.594 --> 00:28:00.859 C++은 특히 더 그렇습니다. 00:28:00.949 --> 00:28:02.659 자바와 닷넷은 그렇지 않습니다. 00:28:03.917 --> 00:28:06.240 자바와 닷넷의 컴파일 시간은 다른 기준을 가집니다. 00:28:06.240 --> 00:28:12.053 C++ 과는 다른 방식으로 소스 코드를 참조합니다. 00:28:12.105 --> 00:28:15.349 자바와 닷넷은 선언문을 얻기 위해 바이너리 파일을 읽습니다. 00:28:15.385 --> 00:28:18.574 C++은 소스 파일을 읽지요. 00:28:18.615 --> 00:28:23.778 그래서 C++에선 순환 참조가 발생하면 대가를 치룹니다. 00:28:25.281 --> 00:28:27.059 매우 긴 컴파일 타임으로 말입니다. 00:28:27.125 --> 00:28:28.832 아주 심하게요. 00:28:28.900 --> 00:28:30.244 제곱에 비례해서 증가합니다. 00:28:30.292 --> 00:28:33.036 그래서 모듈이 몇 개 늘어나면 컴파일 타임이 두 배로 증가해버립니다. 00:28:33.036 --> 00:28:35.560 그래서 우린 뭔가 조치를 해야만 했습니다. 00:28:36.190 --> 00:28:38.804 워드 커닝햄이 누구인지 아는 사람 있나요? 00:28:39.549 --> 00:28:40.459 오. 몇 사람 있군요. 00:28:40.494 --> 00:28:41.964 좋습니다. 모르는 사람들을 위해서 설명하면 00:28:42.014 --> 00:28:43.392 워드 커닝햄은 위키를 개발한 사람입니다. 00:28:43.462 --> 00:28:46.579 워드 커닝햄이 위키를 개발했지요. 00:28:46.623 --> 00:28:51.552 그리고 캔트 벡을 도와 페어 프로그래밍과 테스트 주도 개발을 발명할 수 있게 했습니다. 00:28:51.637 --> 00:28:53.158 그리고 대부분의 애자일 방법들도요. 00:28:53.207 --> 00:28:57.016 워드 커닝햄이 누구인지 알아보세요. 아주 흥미로운 친구입니다. 00:28:57.049 --> 00:28:58.832 아주 오래 전에 그는 스몰 토크 프로그래머였는데요 00:28:58.877 --> 00:29:00.634 언젠가 물어봤습니다. 00:29:00.686 --> 00:29:03.304 "워드, 스몰 토크는 왜 사라진 거지?" 00:29:03.367 --> 00:29:10.085 그가 말했습니다. "스몰 토크는 너무 쉽게 엉망으로 만들 수 있어서 사라졌어." 00:29:10.834 --> 00:29:12.810 "너 같은 C++ 프로그래머들은" 00:29:12.846 --> 00:29:14.382 당시에 나는 C++ 프로그래머였습니다. 00:29:14.458 --> 00:29:16.678 "C++ 프로그래머들은 운이 좋은 거야." 00:29:16.729 --> 00:29:19.467 "네가 엉망으로 만들면 대가를 치루게 되거든." 00:29:19.960 --> 00:29:21.830 "스몰토크는 그러지 않았지." 00:29:23.425 --> 00:29:26.515 자바나 C#도 그러지 않습니다. 00:29:26.965 --> 00:29:28.502 대가를 치루지 않아도 됩니다. 00:29:28.570 --> 00:29:30.997 어렵지 않게 엉망으로 만들 수 있습니다. 00:29:31.368 --> 00:29:34.879 아주 복잡하게 엉키게 만들어버려도 깨닫지를 못해요. 00:29:34.910 --> 00:29:38.958 다행스럼게도 비주얼 스튜디오는 일부나마 순환 참조를 막아주지요. 00:29:44.173 --> 00:29:49.045 우리는 nLogN 수준의 생산성을 추구합니다. nLogN 이죠. 00:29:49.109 --> 00:29:52.376 n^2 대신에요. 00:29:52.776 --> 00:29:59.683 컴포넌트간의 의존관계는 이렇게 생산성에 큰 영향을 미칩니다. 00:30:01.753 --> 00:30:06.973 그리고, 1990년대와 2000년 사이에 큰 변화가 생겼습니다. 00:30:06.973 --> 00:30:10.136 네트워크 속도가 비약적으로 향상되었지요. 00:30:10.635 --> 00:30:15.790 요즘에는 1GB 크기의 파일을 받기는 어렵지 않습니다. 00:30:15.870 --> 00:30:17.661 1GB를 10초만에 업로드 할 수도 있지요. 00:30:17.726 --> 00:30:19.335 요즘엔 아주 쉬운 일이지만요 00:30:19.386 --> 00:30:21.706 예전에는 훨씬 어려웠습니다. 00:30:22.031 --> 00:30:28.315 그래서 예전에는 DLL을 하나만 배포하는게 유리하다고 생각했습니다. 00:30:28.535 --> 00:30:31.939 요즘에는 그냥 모두 모아서 한 덩어리로 배포하지요. 00:30:32.237 --> 00:30:35.835 왜요? 네트워크가 충분히 빨라져서 지요. 그냥 보내면 됩니다. 00:30:35.835 --> 00:30:40.311 많은 DLL들을 그냥 하나로 링크된 바이너리처럼 다룰 수 있습니다. 00:30:41.661 --> 00:30:43.208 그런데 또 다른 이슈가 있습니다. 00:30:44.215 --> 00:30:45.744 여기 팀으로 일하는 사람이 얼마나 있지요? 00:30:47.252 --> 00:30:49.511 그렇지요. 모두가 팀으로 일합니다. 00:30:50.551 --> 00:30:54.415 아침 8시에 출근을 했다고 생각해봅시다. 00:30:55.883 --> 00:30:59.277 디버깅할 프로그램이 있었어요. 00:30:59.346 --> 00:31:02.371 제대로 동작하도록 하루 종일 일했습니다. 00:31:02.488 --> 00:31:03.728 결국 퇴근 할 때엔 완벽하게 동작하게 만들었지요. 00:31:03.766 --> 00:31:04.907 체크인하고 퇴근을 합니다. 00:31:04.961 --> 00:31:07.271 그런데 다음 날에 출근해서 보니 동작을 하지 않았습니다. 00:31:07.328 --> 00:31:08.086 왜 그럴까요? 00:31:09.766 --> 00:31:12.402 누군가 당신보다 더 늦게 퇴근을 한 거지요. 00:31:13.452 --> 00:31:15.836 그 사람이 당신이 사용하는 뭔가를 수정한 것 입니다. 00:31:16.626 --> 00:31:21.774 그래서 다시 동작하도록 하루 종일 일했습니다. 00:31:21.774 --> 00:31:24.409 그리고 다음 날 출근해 보니 또 동작을 안 합니다. 00:31:24.523 --> 00:31:26.390 이런 문제가 얼마나 반복 될 수 있을까요? 00:31:27.398 --> 00:31:30.942 아주 오랜 기간 가능할 겁니다. 규모가 큰 팀에서는 항상 발생할 수 있는 일입니다. 00:31:31.048 --> 00:31:34.662 서로 서로 방해하게 되는 거지요. 00:31:34.745 --> 00:31:36.862 물론 이런 문제를 해결할 툴들이 있지요. 00:31:36.862 --> 00:31:38.921 소스 코드 관리 시스템이 있고요 00:31:38.921 --> 00:31:41.559 그 밖에도 수 많은 좋은 툴들이 있습니다. 00:31:41.799 --> 00:31:47.395 그럼에도 불구하고 제대로 관리하지 않으면 이런 문제는 계속 발생합니다. 00:31:47.814 --> 00:31:52.414 그럼 프로젝트는 어떻게 관리해야 할까요? 00:31:55.951 --> 00:31:57.741 여기에 원칙이 있습니다. 00:32:06.670 --> 00:32:10.849 Acyclic Dependencies Principle 이라고 부릅니다. (역주: 비 순환적인 의존관계의 원칙) 00:32:13.189 --> 00:32:18.585 이런 뜻 입니다. "컴포넌트를 여러 개 가지고 있다면" 00:32:18.618 --> 00:32:22.764 "순환 참조가 없도록 배열해야 한다." 00:32:22.849 --> 00:32:25.957 그래야만하는 이유는 여럿 입니다. 이미 하나는 이야기 했지요. 00:32:26.023 --> 00:32:30.402 컴파일 시간이요. 또 의존 관계로 의한 부하도 이야기 했지요. 00:32:30.402 --> 00:32:31.599 그리고 하나 더 있습니다. 00:32:33.727 --> 00:32:38.577 Alarm 모듈의 새로운 버전을 릴리즈하려고 합니다. 00:32:38.986 --> 00:32:43.013 Alarm 모듈을 담당하는 팀은 1.0 버전을 릴리즈하려고 작업 중입니다. 00:32:43.144 --> 00:32:48.812 Alarm 모듈은 다른 모듈을 사용하지 않습니다. 00:32:48.812 --> 00:32:52.349 따라서 자유롭게 릴리즈할 수 있지요. 00:32:52.401 --> 00:32:56.011 1.0 버전을 릴리즈하고 00:32:56.011 --> 00:32:58.006 1.1 버전 개발을 착수합니다. 00:32:58.896 --> 00:33:02.169 그런데 지금 Alarm 1.0 버전이 릴리즈되었니까 00:33:02.220 --> 00:33:05.977 Elevator 모듈과 Conveyor 모듈도 릴리즈할 수 있게 되었습니다. 00:33:06.916 --> 00:33:12.386 릴리즈 후에 두 모듈도 각각 1.1 버전 개발을 시작합니다. 00:33:12.419 --> 00:33:15.740 이제 Transport 모듈도 릴리즈 합니다. 00:33:15.776 --> 00:33:17.759 어떻게 돌아가는지 알겠지요? 00:33:17.806 --> 00:33:21.079 버전 넘버가 밑에서부터 타고 올라갑니다. 00:33:21.148 --> 00:33:27.448 1.0 버전이 밑에서 생성되면. 점 점 위로 전파되어 맨 위에까지 도달합니다. 00:33:27.497 --> 00:33:30.021 버전 넘버가 밑에서부터 위로 전파되는 거지요. 00:33:30.053 --> 00:33:32.633 자세히 보면 알게 될 겁니다. 00:33:32.633 --> 00:33:37.550 버전 넘버가 전파되는 경로는 빌드 순서와 동일합니다. 00:33:37.615 --> 00:33:42.422 의존 관계는 빌드 순서를 따라 전파됩니다. 00:33:43.318 --> 00:33:50.357 그런데 어떤 얼간이가 이런 짓을 합니다. 00:33:50.454 --> 00:33:52.601 누구지요? 00:33:52.703 --> 00:33:54.192 나에요. 내가 그랬어요. 00:33:54.303 --> 00:33:58.542 난 알람의 서브시스템을 담당하고 있는데 00:33:58.542 --> 00:34:02.255 컨트롤 패널 화면에 메시지를 표시해야만 해요. 00:34:02.329 --> 00:34:06.963 그런데 마침 컨트롤 패널에는 Display라는 펑션이 있더라고요. 00:34:06.963 --> 00:34:10.025 "오. 이걸 호출하면 되겠군." 하면서 사용했습니다. 00:34:10.025 --> 00:34:13.315 문제 없이 호출할 수 있었어요. 00:34:13.315 --> 00:34:17.092 컴파일 됐고, 동작도 문제 없었습니다. 00:34:18.482 --> 00:34:23.495 그런데 다음 날 사람들이 화가나서 내게 찾아왔지요. 00:34:23.542 --> 00:34:25.243 "도대체 무슨 짓을 한 거야?" 00:34:25.652 --> 00:34:32.592 "그냥 컨트롤 패널의 Display 펑션을 호출 했을 뿐이에요." 00:34:32.628 --> 00:34:34.553 "화면에 메시지를 뿌려야만 했거든요." 00:34:34.587 --> 00:34:35.763 "그렇게 하면 안되지!" 00:34:36.351 --> 00:34:37.908 왜 안되는 걸까요? 00:34:39.777 --> 00:34:41.172 우선 00:34:43.752 --> 00:34:47.603 저 모듈들은 어떤 순서로 빌드해야 할까요? 00:34:49.893 --> 00:34:52.737 원래는 밑에서부터 위로 빌드해야 합니다. 00:34:53.853 --> 00:34:55.666 그런데 지금은 밑이 없습니다. 00:34:55.717 --> 00:34:58.090 따라서 올바른 빌드 순서가 없습니다. 00:34:58.341 --> 00:35:01.242 컴포넌트 그래프에서 순환 관계가 있다면 00:35:01.608 --> 00:35:06.485 올바른 빌드 순서를 정할 수 없게 됩니다. 00:35:06.524 --> 00:35:11.136 따라서 시스템 동작도 정의할 수 없게 됩니다. 00:35:11.676 --> 00:35:14.992 "Undefined"가 무슨 뜻 이지요? "Undefined"의 정의가 무엇 인가요? 00:35:16.210 --> 00:35:17.867 정해진 조건에서만 동작한다는 것 입니다. 00:35:19.656 --> 00:35:24.308 "Undefined" 인 것은 배포 전에는 잘 동작합니다. 하지만 배포되고 나면 동작하지 않게 되지요. 00:35:25.442 --> 00:35:29.006 이런 순환참조가 있으면 시스템은 심각한 오류를 발생할 수 있습니다. 00:35:29.043 --> 00:35:30.945 자바에선 흔히 볼 수 있습니다. 00:35:31.044 --> 00:35:35.951 순환 참조가 있는 자바 시스템이 있다면...... 00:35:35.951 --> 00:35:37.061 빌드는 할 수 있지요. 00:35:37.093 --> 00:35:39.021 정확한 빌드 순서가 없더라도 말입니다. 00:35:39.129 --> 00:35:41.327 그런데 테스트를 돌리면 실패합니다. 00:35:41.540 --> 00:35:44.626 그런데 다른 순서로 빌드를 하면 00:35:44.661 --> 00:35:45.804 테스트가 성공하기도 합니다. 00:35:45.855 --> 00:35:49.166 테스트가 패스할 때까지 계속 빌드를 하는 회사도 본적이 있습니다. 00:35:54.627 --> 00:35:56.380 그런데 더욱 심각한 문제가 있습니다. 00:35:56.923 --> 00:36:03.659 Conveyor 모듈을 릴리즈 하려고 합니다. 00:36:03.690 --> 00:36:05.879 1.1 버전을 릴리즈 하려고 하지요. 00:36:05.911 --> 00:36:11.089 그러러면 Alarm 1.1 버전과 같이 테스트해야 합니다. 00:36:11.885 --> 00:36:17.858 하지만 Alarm 1.1 버전은 Control Panel 1.1 버전을 기다리고 있지요. 그리고 Control Panel 1.1 버전은 Transport 1.1 버전을 기다리고 있습니다. 00:36:17.904 --> 00:36:21.646 Transport 1.1 버전은 지금 릴리즈 하려는 Conveyor 1.1 버전을 기다리고 있습니다. 00:36:21.646 --> 00:36:27.729 그러므로 모든 소스코드를 한군데에 모으기 전에는 릴리즈 할 방법이 없어집니다. 00:36:27.818 --> 00:36:31.004 통합작업. 누구 기억하는 사람 있나요? 00:36:31.037 --> 00:36:32.305 통합작업의 즐거움이요. 00:36:32.354 --> 00:36:37.126 모든 시스템을 통합한 이후에 동작하게 하는 것 이지요. 00:36:37.945 --> 00:36:41.044 그러는 동안에는 모듈끼리 서로서로 얽히게 되지요. 00:36:41.354 --> 00:36:49.582 결국 아침에 출근했더니 코드가 동작하지 않는 문제가 다시 발생하게 됩니다. 00:36:50.164 --> 00:36:52.095 그런데 더 큰 문제가 있습니다. 00:36:52.717 --> 00:36:58.439 Conveyor를 테스트하려면 Alarm이 필요한데요 00:36:58.472 --> 00:37:02.409 Alarm은 Control Panel이 필요하고, Control Panel은 Revenue가 필요하고, Revenue는 데이터베이스가 필요합니다. 00:37:02.499 --> 00:37:06.248 그리고 데이터베이스는 45분이나 걸려서 로딩했더니 테스트하자마자 죽어버립니다. 00:37:06.528 --> 00:37:08.966 도저히 테스트를 실행할 수가 없어요. 00:37:09.026 --> 00:37:13.999 Conveyor 모듈 담당자들은 이야기 합니다. "대체 우리 모듈이 데이터베이스가 왜 필요한 거야!?" 00:37:14.150 --> 00:37:17.344 "음, 의존관계가 이상하게 꼬여서 데이터베이스가 필요한 거야." 00:37:17.504 --> 00:37:21.891 프로그램을 실행하고 로딩된 DLL 목록을 보면서 이상하게 여긴 사람 없나요? 00:37:21.891 --> 00:37:23.811 "내가 왜 이런 것들을 사용하지?" 00:37:23.849 --> 00:37:26.895 C++ 개발자 중에 링크 목록을 보고 놀랐던 사람 없나요? 00:37:26.999 --> 00:37:28.962 "왜 이런 것들이 링크 목록에 포함되어있는거야?" 00:37:29.005 --> 00:37:30.530 "내가 왜 이런 것들을 사용하는 거지?" 00:37:30.564 --> 00:37:32.993 순환 참조를 가지고 있기 때문입니다. 00:37:33.026 --> 00:37:34.532 그래서 잡스러운 것들이 이것 저것 끌려오는 거지요. 00:37:34.599 --> 00:37:42.656 그해서 첫 번째 원칙은 컴포넌트간에 순환 참조가 없어야 한다는 것 입니다. 00:37:42.695 --> 00:37:45.059 그럼 어떻게 해결할 수 있을까요? 00:37:45.835 --> 00:37:51.747 밑에 있는 모듈이 저 위에 있는 모듈의 펑션을 호출하려면요? 00:37:51.747 --> 00:37:53.107 어떻게 하겠습니까? 00:37:55.377 --> 00:37:57.370 음...... 컴포넌트를 하나 추가해도 되겠지요. 00:37:58.446 --> 00:37:59.868 가능한 방법 중 하나입니다. 00:37:59.939 --> 00:38:03.339 Control Panel 컴포넌트에서 클래스를 하나 떼어내서 00:38:03.373 --> 00:38:05.327 Display 컴포넌트에 추가합니다. 00:38:05.327 --> 00:38:07.961 Alarm 컴포넌트는 Display 컴포넌트를 호출할 수 있어요. 00:38:07.961 --> 00:38:10.255 Control Panel 컴포넌트도 Display 컴포넌트를 호출할 수 있습니다. 00:38:10.516 --> 00:38:12.199 이렇게 하면 순환 관계를 깰 수 있지요. 00:38:12.263 --> 00:38:14.242 일반적인 방법입니다. 00:38:14.287 --> 00:38:16.061 이 모든 컴포넌트들은 DLL이었지요? 00:38:16.114 --> 00:38:23.034 따라서 순환 관계를 추가되면 결국 DLL 수가 늘어나게 됩니다. 00:38:23.086 --> 00:38:24.603 아마도요. 00:38:25.019 --> 00:38:28.364 또 다른 해결 방법이 있습니다. 00:38:30.440 --> 00:38:33.076 Dependency Inversion을 사용하는 것이지요. 00:38:33.124 --> 00:38:40.010 인터페이스를 하나 만듭니다. Display 인터페이스요. 00:38:40.064 --> 00:38:42.278 Alarm 서브시스템에 추가합니다. 00:38:42.330 --> 00:38:44.778 그리고 Control Panel이 Display 인터페이스를 구현하게 합니다. 00:38:45.764 --> 00:38:48.321 그러면 의존 관계가 뒤집히게 됩니다. 00:38:49.643 --> 00:38:52.663 그리고 순환 관계도 선형으로 바뀝니다. 00:38:59.790 --> 00:39:01.324 객체지향은 무엇인가요? 00:39:04.009 --> 00:39:06.269 객체지향 프로그래밍이 무엇인가요? 00:39:08.802 --> 00:39:10.474 우리가 왜 좋아할까요? 00:39:10.538 --> 00:39:14.936 어쩌다 모든 프로그래밍 언어가 객체지향이 되었을까요? 00:39:14.936 --> 00:39:16.884 벌써 30년동안 사용하고 있습니다. 어떤 것인지는 알아야겠지요. 00:39:16.952 --> 00:39:18.560 (청중) 현실 세계를 모델링 할 수 있습니다. 00:39:18.560 --> 00:39:20.193 현실 세계를 모델링 할 수 있다. 감사합니다. 00:39:20.193 --> 00:39:22.727 내가 이렇게 답하라고 저 사람을 여러분 사이에 심어놨습니다. 00:39:22.727 --> 00:39:24.924 내가 저사람의 답변을 발기 발기 찢어버리려고요. 00:39:24.974 --> 00:39:26.852 아닙니다. 아주 터무니없는 이야기에요. 00:39:26.852 --> 00:39:31.641 객체지향이 실 세계를 모델 하기에 더 좋다는 생각은 말도 안됩니다. 00:39:31.712 --> 00:39:35.366 그건 오래 전에 어떤 사람이 꾸며낸 이야기입니다. 00:39:35.450 --> 00:39:39.479 관리자를 설득해서 1만2천 달러짜리 C++ 컴파일러를 사게 하려고요. 00:39:39.512 --> 00:39:42.092 그 것 말고는 관리자를 설득할 방법을 못 찾았기 때문에요. 00:39:42.144 --> 00:39:46.391 1만2천 달러. 초기 C++ 컴파일러는 매우 비쌌습니다. 00:39:46.391 --> 00:39:48.092 "1만2천 달러! 그 돈 주고 컴파일러를 사지는 않겠네." 00:39:48.092 --> 00:39:49.961 "하지만 그게 있으면 현실 세계를 더 잘 반영할 수 있습니다." 00:39:49.961 --> 00:39:53.086 "아! 그렇다면야......" 00:39:53.125 --> 00:39:57.739 실세계를 더 잘 반영한다는 것은 완전히 어리석은 생각입니다. 00:39:57.771 --> 00:40:04.560 객체지향이란게 그냥 데이터와 펑션들이 같이 모여있다는 것 이외에 뭐가 다를 게 있겠어요? 00:40:04.560 --> 00:40:06.822 캡슐화요. 좋습니다. 캡슐화. 00:40:06.822 --> 00:40:09.407 하지만 펑션들이 데이터 구조체를 가진다는 점은 00:40:09.407 --> 00:40:11.590 객체지향이 아닌 언어와 다를 게 있나요? 00:40:13.393 --> 00:40:15.497 쉽게 답하기는 어렵지요. 00:40:16.282 --> 00:40:18.067 어떻게 다를까요? 00:40:18.129 --> 00:40:21.940 네. 데이터 구조체를 펑션과 같이 넣어서 사용하고 있지요. 00:40:21.994 --> 00:40:23.659 하지만 항상 그래왔습니다. 00:40:24.161 --> 00:40:26.806 예전의 C 프로그래머도 항상 그래왔습니다. 00:40:27.058 --> 00:40:29.959 데이터 구조체도 항상 같이 있었죠. 00:40:29.959 --> 00:40:33.588 아주 유명한 책이 있었지요. "Algorithms plus data structures equals programs" 00:40:34.290 --> 00:40:36.530 데이터 구조와 펑션이 같이 동작합니다. 00:40:36.583 --> 00:40:39.288 객체지향에 특별할 것은 없습니다. 00:40:39.288 --> 00:40:43.754 하지만 객체지향으로 인해 가능해진 게 하나 있긴 합니다. 00:40:43.754 --> 00:40:45.537 예전에는 위험해서 잘 안 썼지요. 00:40:45.597 --> 00:40:47.267 다형성입니다. 00:40:47.304 --> 00:40:50.987 아주 사용하기 쉬운 다형성이지요. 00:40:51.024 --> 00:40:53.266 C에도 있긴 했습니다. 00:40:53.924 --> 00:40:57.898 하드웨어에 독립적인 모든 OS는 다형성의 예입니다. 00:40:57.947 --> 00:41:02.791 어떤 디바이스를 사용할지 모르고 프로그램을 작성할 수 있다면 00:41:02.862 --> 00:41:04.842 분명히 다형적인 특징을 사용하고 있는 것 입니다. 00:41:05.568 --> 00:41:08.694 하지만 대부분의 언어에서는 위험합니다. 00:41:08.762 --> 00:41:10.472 적어도 예전에는 그랬습니다. 00:41:10.472 --> 00:41:12.262 왜냐하면 펑션 포인터들을 만지작거려야 하거든요. 00:41:12.262 --> 00:41:13.533 항상 위험한 작업이었지요. 00:41:14.638 --> 00:41:18.563 객체지향의 도입으로 아주 편리하게 구현할 수 있게 되었습니다. 00:41:18.639 --> 00:41:20.773 특별히 다형성을 생각하지 않아도 됩니다. 00:41:20.773 --> 00:41:23.674 자바 같은 경우에는 모든 메소드가 다형적입니다. 00:41:23.674 --> 00:41:25.108 선택의 여지가 없지요. 00:41:25.175 --> 00:41:29.289 C#은 선택할 수 있습니다. virtual 키워드를 사용하면 되지요. 00:41:29.322 --> 00:41:35.234 C++ 프로그래머도 선택할 수 있지요. virtual 키워드를 사용하면 됩니다. 소멸자에는 반드시 써야 하지요. 00:41:35.871 --> 00:41:38.933 하지만 대부분 별로 신경을 쓰지 않아도 됩니다. 00:41:38.933 --> 00:41:42.007 모든 펑션들이 다형적이에요. 특별히 신경 쓰지 않아도 됩니다. 00:41:42.055 --> 00:41:42.936 왜 그럴까요? 00:41:44.166 --> 00:41:49.384 펑션이 다형적 특징을 가지고 있다면 뭔가 근사한 일이 생깁니다. 00:41:49.964 --> 00:41:55.192 컨트롤 흐름은 상위 클래스에서 하위 클래스로 향합니다. 00:41:55.242 --> 00:41:59.150 하지만 소스코드의 의존관계는 반대로 하위 클래스에서 상위 클래스로 향합니다. 00:41:59.828 --> 00:42:07.917 런타임 의존관계를 변경하지 않고도 소스코드의 의존관계를 뒤집을 수 있습니다. 00:42:07.917 --> 00:42:10.110 DLL을 어떻게 만들지요? 00:42:10.110 --> 00:42:11.872 컴포넌트는 어떻게 만드나요? 00:42:11.872 --> 00:42:13.614 다른 것들과 분리시켜서 만듭니다. 00:42:13.614 --> 00:42:16.954 하지만 런타임 의존관계는 유지해야 합니다. 00:42:21.441 --> 00:42:22.710 비주얼스튜디오 쓰는 사람들 00:42:24.865 --> 00:42:27.552 ReSharper 사용하나요? 00:42:28.532 --> 00:42:30.060 ReSharper 사용하는 사람? 00:42:30.091 --> 00:42:31.576 보세요. 모두가 사용합니다. 00:42:32.816 --> 00:42:35.606 비주얼스튜디오가 ReSharper에 대해서 아나요? 00:42:38.009 --> 00:42:38.645 아닙니다. 00:42:38.718 --> 00:42:42.338 비주얼스튜디오가 ReSharper를 호출하나요? 00:42:43.465 --> 00:42:44.725 그렇지요. 00:42:44.790 --> 00:42:49.106 컨트롤 흐름은 비주얼 스튜디오에서 Resharper로 향합니다. 00:42:49.106 --> 00:42:54.477 비주얼 스튜디오는 필요한대로 ReSharper의 펑션을 호출합니다. 00:42:54.477 --> 00:43:00.686 하지만 비주얼스튜디오 소스 코드는 ReSharper의 소스 코드에 의존하지 않지요. 00:43:00.686 --> 00:43:03.086 왜냐하면 의존 관계의 방향이 뒤집어졌기 때문이지요. 00:43:04.025 --> 00:43:09.912 어플리케이션이 어떤 걸 호출할지 모르는 상태에서도 00:43:09.945 --> 00:43:12.495 호출될 DLL들을 만들 수 있습니다. 00:43:12.527 --> 00:43:15.585 의존 관계를 뒤집어서 말입니다. 00:43:15.864 --> 00:43:17.072 의존 관계가 역전되는 거지요. 00:43:17.156 --> 00:43:19.280 이 것도 순환 참조를 해결하는 좋은 방법입니다. 00:43:19.652 --> 00:43:28.943 그럼 Control Panel은 Alarm 시스템에 플러그인이 됩니다. 00:43:29.025 --> 00:43:31.590 Alarm 시스템은 Control Panel에 대해서 모릅니다. 00:43:31.590 --> 00:43:35.765 Control Panel 은 플러그인이에요. 00:43:35.813 --> 00:43:38.609 Alarm 시스템은 어떤 플러그인이라도 사용할 수 있습니다. 00:43:38.609 --> 00:43:42.568 어떤 것이든지 이 Display 펑션을 구현할 수 있습니다. 00:43:42.568 --> 00:43:45.262 그러면 아주 많은 것들에 알람을 적용할 수 있는 거지요. 00:43:52.942 --> 00:43:55.184 어떤 것에 의존하겠습니까? 00:44:01.501 --> 00:44:04.620 안정적인 컴포넌트를 의존하겠습니까? 00:44:07.014 --> 00:44:08.996 아니면 불안정한 컴포넌트요? 00:44:10.785 --> 00:44:12.145 뻔한 질문입니다. 00:44:12.195 --> 00:44:17.812 누구나 안정적인 것을 의존하고 싶어합니다. 00:44:22.582 --> 00:44:25.278 그러면 안정적이라는 단어를 정의해봅시다. 00:44:28.542 --> 00:44:30.590 내 레이저 포인터는 안정적인가요? 00:44:34.332 --> 00:44:36.273 이건 변하지는 않지요. 00:44:38.883 --> 00:44:40.569 하지만 안정적인가요? 00:44:40.614 --> 00:44:43.667 안정성은 그렇다 아니다로 표현할 수가 없습니다. 00:44:43.732 --> 00:44:46.330 안정성은 지속적인 특징을 가집니다. 00:44:46.379 --> 00:44:50.612 그리고 변화 시키는 데에 필요한 일의 양으로 정의되지요. 00:44:50.657 --> 00:44:53.396 힘이 많이 필요하면 안정적인 것 입니다. 00:44:53.433 --> 00:44:56.250 조금의 힘으로도 변화시킬 수 있다면 불안정적인 것이지요. 00:44:56.301 --> 00:45:00.212 저건 불안정적 입니다. 00:45:00.283 --> 00:45:03.767 조금만 힘을 써도 상태를 변경시킬 수 있거든요. 00:45:03.825 --> 00:45:08.630 이건 안정적이라고 말하진 않겠습니다. 00:45:08.736 --> 00:45:11.505 뒤집는데 힘이 많이 들지 않겠거든요. 00:45:11.542 --> 00:45:14.952 그리고 여기 강단은 그다지 안정적이지 않은 것 같아요. 00:45:15.780 --> 00:45:18.945 조심해서 움직여야겠네요. 00:45:18.976 --> 00:45:21.597 다시 질문해보겠습니다. 00:45:21.632 --> 00:45:24.712 어떤 것을 의존하겠습니까? 00:45:24.766 --> 00:45:26.956 쉽게 변경되는 것에 의존하겠어요? 00:45:26.997 --> 00:45:28.735 아니면 잘 변경되지 않는 것에요? 00:45:28.774 --> 00:45:33.115 소스코드를 수정하는 경우라면 요? 00:45:33.725 --> 00:45:35.199 어떤 것에 의존 하겠습니까? 00:45:35.199 --> 00:45:39.812 소스 코드 변경하기 어려운 모듈에 의존할까요? 아니면 소스 코드를 변겨하기 쉬운 모듈에요? 00:45:42.290 --> 00:45:43.366 같은 답변입니다. 00:45:43.439 --> 00:45:45.699 변경하기 어려운 것에 의존해야 합니다. 00:45:45.731 --> 00:45:48.997 이유는 아주 간단합니다. 00:45:48.997 --> 00:45:51.956 문자열 클래스를 사용하기 꺼려지나요? 00:45:51.988 --> 00:45:52.725 아닙니다. 00:45:52.725 --> 00:45:54.946 왜지요? 00:45:54.946 --> 00:45:58.409 만약에 누군가가 문자열 클래스를 변경한다면 큰 대가를 지불할 겁니다. 00:45:59.679 --> 00:46:01.405 문자열 클래스를 사용하는 여러분 보다 훨씬 더 괴로울 거에요. 00:46:01.619 --> 00:46:04.157 그게 우리가 이야기하는 방정식입니다. 00:46:04.157 --> 00:46:06.488 어떤 모듈을 사용하는 조건은 다음과 같습니다. 00:46:06.528 --> 00:46:11.525 그 모듈이 변경됐을 경우 나보다 그 모듈의 개발자가 할 일이 더 많으면 사용합니다. 00:46:11.564 --> 00:46:13.814 그게 적절한 조건이에요. 00:46:13.854 --> 00:46:15.598 그런 경우엔 안심하고 사용할 수 있습니다. 00:46:15.598 --> 00:46:19.202 그 모듈이 잘 변경되지 않을 것 같거나 변경되더라도 그걸 변경한 나쁜 자식이 합당한 대가를 치루게 되는 경우 말입니다. 00:46:19.202 --> 00:46:25.356 그렇습니다. 우린 손쉽게 변경되는 것에 의존하지 않으려고 합니다. 00:46:27.384 --> 00:46:28.906 잘 생각해보세요. 00:46:28.906 --> 00:46:32.846 쉽게 변경되는 것에는 의존하지 않습니다. 00:46:34.594 --> 00:46:40.272 시스템을 설계할 때에 쉽게 변경할 수 있게 만드는 곳이 있나요? 00:46:42.648 --> 00:46:43.785 있습니다. 00:46:44.137 --> 00:46:49.977 시스템 중 어떤 부분이 가장 쉽게 변경될 수 있어야 하지요? 00:46:53.137 --> 00:46:54.321 GUI입니다. 00:46:56.888 --> 00:46:58.286 GUI는 쉽게 변합니다. 00:46:58.286 --> 00:47:01.589 특별한 이유 없이 바뀌기도 합니다. 00:47:01.622 --> 00:47:05.068 사람들은 그냥 느낌 만으로도 GUI를 변경하기도 하지요. 00:47:05.105 --> 00:47:07.851 제품 위원회에서 이야기합니다. 00:47:07.851 --> 00:47:09.743 "이봐, 우리 시스템은 좀 오래되 보여" 00:47:09.780 --> 00:47:11.500 그게 무슨 말인가요? 00:47:11.500 --> 00:47:14.542 "우리 시스템은 좀 오래되 보여. 디자인을 바꿔야겠어." 00:47:14.902 --> 00:47:19.376 "마케팅 팀에서 결정 났어. 완전 새로운 Look & Feel을 입히자고." 00:47:19.410 --> 00:47:21.035 "동작을 변경할 필요는 없고" 00:47:21.090 --> 00:47:22.895 "GUI의 Look & Feel 만 변경하는 거야." 00:47:22.927 --> 00:47:25.044 GUI는 쉽게 바꿀 수 있어야 합니다. 00:47:25.044 --> 00:47:28.509 GUI 모듈의 소스 코드는 쉽게 변경할 수 있어야 합니다. 00:47:28.549 --> 00:47:33.005 그 건 다른 모듈이 GUI 모듈에 의존하면 안 된다는 말이지요. 00:47:33.627 --> 00:47:36.668 어떤 모듈의 소스 코드도 GUI 모듈을 참조해선 안됩니다. 00:47:37.533 --> 00:47:41.976 GUI 모듈을 향하는 의존 관계가 없어야 합니다. 00:47:42.029 --> 00:47:45.183 GUI 컴포넌트가 어플리케이션의 다른 모듈들을 의존해야 합니다. 00:47:45.226 --> 00:47:48.528 다른 컴포넌트들은 GUI 컴포넌트에 의존하면 안됩니다. 00:47:49.110 --> 00:47:53.207 그렇지 않으면 결국 시스템의 GUI는 수정하기 어렵게 될 겁니다. 00:47:53.254 --> 00:47:56.567 시스템을 테스트하는 사람이 얼마나 되나요? 00:47:56.617 --> 00:47:57.882 자동화된 테스트요. 00:47:58.844 --> 00:47:59.910 GUI를 통해서요. 00:48:02.644 --> 00:48:03.858 두어 사람 있군요. 00:48:04.807 --> 00:48:06.618 GUI를 통해서 테스트를 한다고요. 00:48:07.383 --> 00:48:11.009 그렇다면 쉽게 변해야 하는 것에 의존하고 있는 것 입니다. 00:48:11.058 --> 00:48:13.231 그러면 결국 GUI 변경하기 어렵게 만들 겁니다. 00:48:13.296 --> 00:48:15.598 GUI를 통해서 시스템을 테스트를 한다면요. 00:48:15.667 --> 00:48:19.399 15,000개의 테스트를 GUI를 통해서 수행하는 고객이 있었습니다. 00:48:19.432 --> 00:48:20.850 앞에서 이야기한 그 고객입니다. 00:48:20.934 --> 00:48:22.070 그 망한 고객이요. 00:48:22.102 --> 00:48:25.786 GUI 기반의 15,000개의 테스트요. 00:48:25.838 --> 00:48:29.291 테스트가 너무 많아서 어떤 테스트인지도 모르고 있었지요. 00:48:29.324 --> 00:48:30.828 그냥 모두 패스해야 한다는 것만 알았지요. 00:48:30.863 --> 00:48:32.783 누군가 GUI를 변경한다면요 00:48:32.819 --> 00:48:35.233 테스트 케이스 중 1000개는 실패하겠지요. 00:48:35.283 --> 00:48:37.060 너무 많아서 수정하기도 힘들었겠지요. 00:48:37.108 --> 00:48:39.223 그래서 아주 간단한 규칙을 생각해냈습니다. 00:48:39.265 --> 00:48:40.797 무엇이었을까요? 00:48:40.851 --> 00:48:43.575 GUI는 변경하지 않는다! 00:48:43.611 --> 00:48:47.117 그들은 GUI를 변경하기 어렵게 만들었어요. 00:48:47.532 --> 00:48:51.696 테스트 케이스를 못쓰게 되는 경우도 있었겠지요. 00:48:52.566 --> 00:48:58.428 12 M/M를 투자해서 GUI를 통한 테스트 수트를 만들었다고 합시다. 00:48:58.468 --> 00:49:01.944 그런데 누군가 결정했어요. "GUI 디자인을 변경해야겠어." 00:49:01.984 --> 00:49:04.359 "기존 GUI를 걷어내고 새로운 GUI를 개발합시다." 00:49:04.404 --> 00:49:05.969 테스트들은 쓸모가 없어집니다. 00:49:06.000 --> 00:49:09.706 테스트 케이스를 다시 작성해야 합니다. 하지만 테스트할 시스템이 그 것만 있는 게 아니지요. 00:49:09.748 --> 00:49:11.771 GUI는 테스트하지 마세요. 00:49:11.809 --> 00:49:13.777 GUI를 통해서는 아무것도 하지 마세요. 00:49:13.777 --> 00:49:19.387 어떤 의존 관계도 GUI를 향해선 안됩니다. 00:49:19.450 --> 00:49:22.799 쉽게 변경하고 싶어하는 게 또 뭐가 있을까요? 00:49:22.881 --> 00:49:26.047 데이터베이스요. 00:49:26.047 --> 00:49:28.340 데이터베이스도 쉽게 변경하고 싶어하지요. 00:49:28.340 --> 00:49:32.347 어플리케이션을 엎어버리지 않고 데이터베이스를 변경 할 수 있기를 원합니다. 00:49:33.814 --> 00:49:37.646 어떤 의존 관계도 데이터베이스로 향하면 안되겠지요. 00:49:37.646 --> 00:49:40.613 아무 것도 데이터베이스를 의존하지 않게 해야 합니다. 00:49:40.681 --> 00:49:44.228 아무 것도 GUI를 의존하지 않게 해야 합니다. 00:49:46.310 --> 00:49:54.150 불안정적인 것은 의존하면 안됩니다. 00:49:54.701 --> 00:49:58.444 불안정성은 어떻게 측정 할 수 있을까요? 00:50:02.013 --> 00:50:03.818 저기 보이나요? 00:50:04.997 --> 00:50:06.322 저기 위에 있는 컴포넌트요. 00:50:06.750 --> 00:50:08.926 저건 안정적인가요? 아니면 불안정적인가요? 00:50:09.001 --> 00:50:13.261 많은 모듈들이 의존하고 있지요. 00:50:13.329 --> 00:50:15.624 자기가 의존하는 것은 없습니다. 00:50:15.687 --> 00:50:17.099 따라서 변경하기 어렵지요. 00:50:17.152 --> 00:50:20.353 변경을 하게 되면 다른 모듈들에도 영향을 미칩니다. 00:50:20.404 --> 00:50:24.940 따라서 저 컴포넌트는 다른 모듈들에 책임을 지게 되는 거지요. 00:50:25.010 --> 00:50:28.996 음 이 컴포넌트는 독립적이군요. 00:50:29.077 --> 00:50:30.892 다른 모듈을 의존하지는 않습니다. 00:50:30.892 --> 00:50:32.803 책임감있고 독립적입니다. 00:50:32.803 --> 00:50:33.852 마치 어른 처럼요. 00:50:36.724 --> 00:50:39.079 안정적이고 어른과 같습니다. 00:50:40.048 --> 00:50:41.089 저기 아래 컴포넌트를 보세요. 00:50:41.619 --> 00:50:44.444 많은 모듈들을 이용하고 있네요. 00:50:44.953 --> 00:50:46.787 저 컴포넌트를 이용하는 모듈은 없어요. 00:50:46.840 --> 00:50:48.367 책임질 필요가 없겠지요? 00:50:48.434 --> 00:50:49.643 그리고 의존적입니다. 00:50:49.682 --> 00:50:51.274 청소년과 같습니다. 00:50:52.014 --> 00:50:53.581 그리고 안정적이지 않습니다. 00:50:54.058 --> 00:50:57.624 서로 완전히 반대되는 컴포넌트들이지요. 00:50:57.683 --> 00:51:00.395 컴포넌트 종류의 양 극단이라고 할 수 있습니다. 00:51:00.429 --> 00:51:02.870 아주 안정적인 어른과 00:51:02.937 --> 00:51:06.786 아주 불안정적인 청소년이지요. 00:51:06.878 --> 00:51:09.071 불안정적인 것은 쉽게 변합니다. 00:51:09.154 --> 00:51:11.685 가능한 코드를 적게 넣어야겠지요. 00:51:12.391 --> 00:51:15.128 안정적인 것은 변경하기 어렵습니다. 00:51:16.378 --> 00:51:22.870 안정적인 정도를 측정할 수 있는 지표를 만들 수 있습니다. 00:51:22.902 --> 00:51:25.828 'I'라고 부를 거에요. 00:51:26.816 --> 00:51:33.597 'I' 는 다른 것을 이용하는 관계의 수를 00:51:33.669 --> 00:51:37.095 나를 이용하는 관계의 수와 다른 것을 이용하는 관계의 수를 더한 것으로 나눈 값입니다. 00:51:37.183 --> 00:51:40.231 곰곰히 생각해보면 00:51:40.263 --> 00:51:43.563 'I'는 0부터 1 사이의 값이라는 것을 알게 될 것 입니다. 00:51:43.647 --> 00:51:46.835 0은 안정적이고, 1은 불안정적입니다. 00:51:46.869 --> 00:51:50.026 0은 어른이고, 1은 청소년입니다. 00:51:50.092 --> 00:51:53.337 모두 의존 관계에 대한 이야기입니다. 00:51:53.370 --> 00:51:59.273 자 그럼 원칙을 다르게 표현해보겠습니다. 00:52:05.664 --> 00:52:13.948 컴포넌트는 자기보다 잘 변하지 않는 것에 의존해야 한다. 00:52:14.348 --> 00:52:21.748 다르게 말한다면, 의존 관계의 방향은 'I'가 감소하는 방향으로 향해야 한다. 00:52:21.827 --> 00:52:25.394 불안정성이 감소하는 것은 안정성이 높아지는 것 이지요. 00:52:25.426 --> 00:52:30.656 참조하는 수와 참조되는 수를 가지고 간단하게 확인할 수 있어요. 00:52:31.576 --> 00:52:36.733 순환 참조가 왜 나쁘지요? 00:52:37.981 --> 00:52:41.441 안정적인 것이 잘 변하는 것을 이용하게되기 때문입니다. 00:52:44.864 --> 00:52:48.128 그러면 새로운 문제가 생깁니다. 00:52:48.167 --> 00:52:49.920 뭐냐하면 00:52:54.953 --> 00:52:56.228 저 맨 밑에 있는 컴포넌트는 어떻지요? 00:52:57.662 --> 00:52:59.327 안정적인가요? 아닌가요? 00:53:01.337 --> 00:53:02.724 아주 안정적인 컴포넌트입니다. 00:53:02.774 --> 00:53:05.103 맨 밑에 위치하기도 하고 00:53:05.175 --> 00:53:07.800 많은 모듈들이 사용하고 있습니다. 00:53:08.595 --> 00:53:10.422 변경하기 아주 어려워요. 00:53:10.764 --> 00:53:14.927 저 컴포넌트를 수정하면 많은 모듈들이 영향을 받게 됩니다. 00:53:14.927 --> 00:53:18.348 그냥 버전 넘버만 바뀌었는데도 말입니다. 00:53:23.941 --> 00:53:29.017 저 밑에 있는 것들은 변경하기가 아주 까다롭지요. 00:53:30.887 --> 00:53:33.373 하지만 벗어날 방법이 있습니다. 00:53:33.725 --> 00:53:35.338 다형성을 사용하는 것 입니다. 00:53:36.750 --> 00:53:42.927 어떻게 하면 쉽게 확장되게 만들 수 있을까요? 00:53:43.791 --> 00:53:46.479 변경하기 까다로운 것이라도 말입니다. 00:53:48.710 --> 00:53:50.260 추상 클래스로 만드는 것 입니다. 00:53:51.098 --> 00:53:54.422 추상 클래스는 쉽게 확장할 수 있습니다. 00:53:55.209 --> 00:53:57.365 직접 수정하지 않고도 00:53:57.456 --> 00:54:00.423 시스템에 새로운 피처를 추가할 수 있습니다. 00:54:00.472 --> 00:54:05.741 새로운 기능을 파생 클래스에 담아서 말입니다. 00:54:06.201 --> 00:54:08.904 그래서 마지막 원칙은 다음과 같습니다. 00:54:09.760 --> 00:54:16.153 밑에 위치할 수록 더욱 추상적이어야 한다. 00:54:16.185 --> 00:54:18.480 저 위의 것은 구체적입니다. 00:54:18.513 --> 00:54:20.310 불안정하고 구체적이지요. 00:54:20.310 --> 00:54:23.135 저 밑의 것은 추상적이고 안정적입니다. 00:54:23.135 --> 00:54:30.237 저 트리를 따라 내려갈 수록 추상성은 점점 커져갑니다. 00:54:32.090 --> 00:54:39.393 추상성은 숫자로 표현될 수 있습니다. 00:54:39.425 --> 00:54:46.424 추상 클래스의 개 수를 컴포넌트의 전체 클래스 수로 나누는 것 이지요. 00:54:46.895 --> 00:54:50.355 그러면 0부터 1 사이의 'A' 값을 구할 수 있습니다. 00:54:50.355 --> 00:54:51.672 0은 구체적인 것 이고요. 00:54:51.708 --> 00:54:54.826 1은 모두 추상적인 것 입니다. 컴포넌트에 인터페이스 밖에 없는 거지요. 00:54:54.878 --> 00:54:58.622 그러면 아주 흥미로운 일을 할 수 있습니다. 00:54:58.698 --> 00:55:09.120 컴포넌트의 'A'와 'I'의 값을 합치면 1이됩니다. 00:55:09.152 --> 00:55:13.091 'A' 가 1이어서 추상적이거나 00:55:13.129 --> 00:55:15.504 'I'가 0이어서 안정적입니다. 00:55:15.541 --> 00:55:19.557 'I'가 0인 경우 불안정적이고 00:55:19.606 --> 00:55:21.130 'A'가 0인 경우 구체적입니다. 00:55:21.130 --> 00:55:23.375 'A'와 'I'를 합하면 1이됩니다. 00:55:23.423 --> 00:55:26.733 마법의 공식입니다. 'A' 더하기 'I'는 1입니다. 00:55:26.733 --> 00:55:30.863 저기 위에 추상적인 어른이 있지요 00:55:30.897 --> 00:55:33.340 다른 모두가 의존하고 있습니다. 안정적이란 말이지요. 00:55:33.378 --> 00:55:35.859 저기 아래에 청소년이 있습니다. 00:55:37.254 --> 00:55:41.781 다른 곳에서 사용하고 있지 않지요. 하지만 구체적입니다. 00:55:41.815 --> 00:55:43.602 이 것은 무엇인가요? 00:55:43.635 --> 00:55:47.142 'A'와 'I'의 합이 1인 것을 보여주고 있지요. 00:55:48.472 --> 00:55:53.458 컴포넌트들은 저 두 끝 지점에 위치하는 게 가장 이상적이겠지요. 00:55:53.499 --> 00:55:54.376 왜 그럴까요? 00:55:55.583 --> 00:55:59.496 여기 왼쪽 위에는 어떤가요? 00:56:00.981 --> 00:56:03.951 아주 추상적이지요. 아무 것도 의존하지 않습니다. 00:56:05.366 --> 00:56:08.097 인터페이스가 구현하는 모듈이 하나도 없는 경우이지요. 쓸모 없습니다. 00:56:08.729 --> 00:56:11.022 여기 쓸 데가 없는 것들입니다. 00:56:11.067 --> 00:56:14.316 컴포넌트를 저쪽에 위치하게 하면 안됩니다. 00:56:14.388 --> 00:56:15.600 그럼 여기 오른쪽 아래에는 어떤가요? 00:56:17.040 --> 00:56:19.658 아주 구체적입니다. 모두가 의존하고 있습니다. 00:56:20.230 --> 00:56:21.560 데이터베이스 스키마. 00:56:23.292 --> 00:56:25.212 구체적입니다. 모두가 의존하고 있지요. 00:56:25.262 --> 00:56:26.519 변경하면 아주 재미나겠지요. 00:56:27.371 --> 00:56:29.629 그렇지요? 여기 밑에 위치하면 안됩니다. 00:56:29.669 --> 00:56:31.019 아주 고통스러운 구역이에요. 00:56:31.713 --> 00:56:36.199 컴포넌트는 저 두 지점에서 가능한 멀리 위치해야 합니다. 00:56:36.199 --> 00:56:39.298 이상적으로는 컴포넌트를 여기 여기에 위치하면 좋겠지만 00:56:39.333 --> 00:56:42.253 그렇게 하면 컴포넌트가 까다로워집니다. 00:56:42.304 --> 00:56:45.450 그래서 최소한 이 선 위에 위치하도록 해야 합니다. 00:56:45.962 --> 00:56:48.414 아니면 선에 가깝게요. 00:56:48.914 --> 00:56:51.407 여기에서 마지막 측정 기준이 나옵니다. 00:56:52.574 --> 00:56:53.566 'D' 입니다. 00:56:54.316 --> 00:56:56.975 컴포넌트가 저 선에서 얼마나 떨어져있나를 의미합니다. 00:56:57.594 --> 00:57:02.086 'D'는 'A' 더하기 'I' 빼기 1의 절대값 입니다. 00:57:02.086 --> 00:57:04.714 계산하기 어렵지 않습니다. 00:57:04.714 --> 00:57:07.210 'D'는 0과 1사이의 값입니다. 00:57:07.460 --> 00:57:09.574 0은 선위에 있다는 뜻이고 00:57:09.607 --> 00:57:11.638 1은 저 나쁜 두 지점에 있다는 것 입니다. 00:57:12.111 --> 00:57:14.831 저 두 지점 중에 어느 쪽이냐는 절대값 기호를 빼면 알 수 있겠지요. 00:57:14.831 --> 00:57:16.361 뭐 상관 없습니다. 00:57:16.481 --> 00:57:22.408 'D'는 의존하는 관계와 의존되는 관계를 보고 알 수 있습니다. 00:57:22.437 --> 00:57:23.996 추상적인 정도를 측정하는 것 이지요. 00:57:24.075 --> 00:57:27.696 계산 자체는 어렵지 않습니다. 00:57:27.733 --> 00:57:33.595 컴포넌트가 저 선위에 있는지 보세요 00:57:34.044 --> 00:57:40.423 선 위에 있으면 추상적이고 의존되고 있지요. 00:57:41.387 --> 00:57:46.815 선 위에 없으면 추상적이지만 의존되고 있지 않은 것 입니다. 00:57:46.885 --> 00:57:49.023 아니면 아주 구체적인데 많이 참조되고 있는 것 입니다. 00:57:49.023 --> 00:57:50.361 둘다 아주 나쁜 거지요. 00:57:51.455 --> 00:57:55.190 많은 툴들이 이런 지표들을 자동으로 계산해줍니다. 00:57:55.261 --> 00:57:58.665 NDepend 써봤나요? NDepend도 이런 지표들을 계산해줍니다. 00:57:58.698 --> 00:58:02.580 대부분의 정적 분석 툴들이 00:58:02.658 --> 00:58:06.184 I, D 와 같은 지표들을 계산해줍니다. 00:58:06.255 --> 00:58:09.529 컴포넌트들의 지표 값들을 쉽게 확인할 수 있습니다. 00:58:09.568 --> 00:58:14.219 그리고 어떤 것들이 변경하기 쉬워야 할지 생각해보세요. 00:58:14.825 --> 00:58:17.924 변경하기 쉬운 것들은 청소년과 같은 것들입니다. 00:58:19.047 --> 00:58:23.650 변경하기 어려운 것은 성인과 같아야 하고 추상적이어야 합니다. 00:58:23.650 --> 00:58:27.629 구체적이고 청소년 같은 것 들은 변경하기 쉬워야 합니다. 00:58:28.283 --> 00:58:31.796 추상적이고 어른과 같은 것 들은 변경하기 어려워야 합니다. 00:58:32.967 --> 00:58:34.178 질문있나요? 00:58:36.316 --> 00:58:40.364 PDP-8 어셈블리 코드로 시작해서 여기까지 왔군요. 00:58:42.809 --> 00:58:44.617 질문 있나요? 없어요? 00:58:45.151 --> 00:58:45.653 좋습니다. 00:58:46.559 --> 00:58:47.809 이런 00:58:49.760 --> 00:58:51.276 괜찮습니다. 좋아요. 00:58:51.393 --> 00:58:56.854 (질문 중) 00:58:56.854 --> 00:58:57.486 네 00:58:57.486 --> 00:59:03.080 (질문 중) 00:59:03.080 --> 00:59:04.955 두 개의 버전이요. 00:59:04.955 --> 00:59:07.015 (질문 중) 00:59:07.015 --> 00:59:10.351 하나의 컴포넌트가 2개의 버전으로 존재하는 경우요. 아주 어렵지요. 00:59:10.540 --> 00:59:11.189 네 00:59:11.599 --> 00:59:15.284 같은 컴포넌트의 각각 다른 버전의 파일들을 한 시스템에 두지 마세요. 00:59:15.320 --> 00:59:16.923 그게 DLL 지옥입니다. 00:59:17.847 --> 00:59:19.909 다른 사람 있나요? 00:59:21.349 --> 00:59:24.025 String 클래스의 위치는 어디냐고요? 아주 아주 좋은 질문입니다. 00:59:24.025 --> 00:59:26.186 String 클래스는 저기에 위치합니다. 00:59:26.952 --> 00:59:31.841 최악의 자리지요. 하지만 아무도 변경하지 않습니다. 따라서 신경 쓸 필요 없습니다. 00:59:32.118 --> 00:59:35.767 오늘의 모든 이야기는 현재 개발중인 것에 해당됩니다. 00:59:35.809 --> 00:59:37.831 현재 변경 중인 것 이요. 00:59:38.061 --> 00:59:42.786 우리 라이브러리의 변경되고 있는 것들을 아주 유의해서 봐야 합니다. 00:59:42.786 --> 00:59:45.880 라이브러리 중에서 변경되지 않는 것이나 00:59:45.918 --> 00:59:49.029 변경되지 않는 오래된 라이브러리의 것 들은 00:59:49.066 --> 00:59:50.470 신경 쓸 필요가 없습니다. 00:59:50.513 --> 00:59:52.332 그 중 많은 것들이 저런 곳에 위치하겠지만 00:59:52.332 --> 00:59:53.456 괜찮습니다. 00:59:53.456 --> 00:59:54.923 저기에 위치하는 것은 없을 것 입니다. 00:59:55.733 --> 00:59:57.620 뭐 조금은 있을 수도 있겠지요 00:59:57.620 --> 00:59:59.589 죽은 코드를 제거해본 적 있나요? 00:59:59.624 --> 01:00:01.948 아무도 상속받지 않는 추상 클래스처럼요? 01:00:02.007 --> 01:00:04.869 네 실제로 조금은 있을 수 있겠어요. 01:00:04.901 --> 01:00:11.720 String, Vector, 그 밖의 라이브러리 등이 저기에 위치할 수 있겠습니다. 하지만 신경 쓸 필요 없습니다. 쉽게 변경되지 않을 테니까요. 01:00:11.756 --> 01:00:16.272 저 그래프로부터 제 3의 축이 여러분 쪽으로 향한다고 생각해보세요. 01:00:16.306 --> 01:00:18.368 그게 가변성에 대한 축입니다. 01:00:18.368 --> 01:00:21.573 이 화면의 그래프는 가변성이 1에 가까운 상황이죠. 01:00:22.123 --> 01:00:24.836 가변성이 0인 경우는 신경 쓸 필요가 없습니다. 01:00:26.136 --> 01:00:27.084 또 질문 있나요? 01:00:27.963 --> 01:00:29.200 저기 뒤에요.