0:00:00.000,0:04:43.738 (4분45초 부터 시작, 실제 강연 주제는 11분 부터 시작) 0:04:46.478,0:04:50.376 뒤에 잘 들리나요? 0:04:50.785,0:04:56.304 저 뒤에도 잘 들리나요? 오케이 좋습니다.[br] 0:04:56.401,0:05:00.828 Um what is an electron?[br] 0:05:04.013,0:05:07.984 So part of atom, everybody knows that, I think[br] 0:05:08.290,0:05:17.718 It's um.. (Screams from other room) yeah I think so, . I think that's royal ???[br] 0:05:19.734,0:05:22.415 Um electron is part of atom[br] 0:05:22.604,0:05:32.113 it's carries a unit of electronic charge, negative charge, as oppose to a proton which carries a positive charge[br] 0:05:32.230,0:05:42.408 It apparently has ??? not very much, thousands of electron... very very small amount of mass[br] 0:05:42.922,0:05:55.041 And we think of it as a particle, although that misleading um.. electron actually behaves much more like a wave than like a particle[br] 0:05:55.041,0:05:58.778 why do we think of it as particle?[br] 0:05:58.780,0:06:08.906 and the reason we do that is that when electron interacts a location like a particle would[br] 0:06:09.151,0:06:16.302 when electron is moving through the space it does not moves the way a particle would[br] 0:06:16.418,0:06:21.498 moves as a wave and the wave has no location[br] 0:06:21.498,0:06:27.334 you look at an ocean wave, and ocean wave can be huge[br] 0:06:27.334,0:06:33.819 it has no distinct location it has well defined energy but no distinct location[br] 0:06:33.819,0:06:36.450 this is how an electron moves[br] 0:06:36.450,0:06:42.191 electrons obey a principle and it's a mistruster principle[br] 0:06:42.191,0:06:45.566 It's called the poly exclusion principle[br] 0:06:45.566,0:06:53.202 two electrons bound into the same system will not be in the same state[br] 0:06:53.202,0:06:57.328 for whatever reason they cannot be in the same state[br] 0:06:57.328,0:07:00.677 so if there are two electrons in an atom[br] 0:07:00.677,0:07:04.066 those two electrons must be different somehow[br] 0:07:04.066,0:07:07.709 now they might different in the direction of their spin[br] 0:07:07.709,0:07:10.899 an electron can spin to the left or spin to the right[br] 0:07:10.899,0:07:18.355 two electrons that have exactly same energy could fit together spinning one left and one right 0:07:18.355,0:07:21.442 there's no way to get a third one in there 0:07:21.450,0:07:28.412 so the next electron must have higher energy and then you can have two more 0:07:28.412,0:07:30.806 one spinning left one spinning right 0:07:30.806,0:07:34.769 but if you wanted to add another that would have to be something different about them 0:07:34.769,0:07:37.917 and you could arrange them differently in space 0:07:37.985,0:07:48.589 so you could have one group of two this way and another group of two this way and another group of two this way and one group of two in a sphere and that adds up the eight by the way. 0:07:49.633,0:07:57.677 most of our atoms that we know of have this need to have 8 electrons in their shells 0:07:57.690,0:08:07.827 The reason for that is just this nice little geometry. the sphere and then three rows and each one of those can contain two 0:08:07.827,0:08:12.868 have you ever thought about water? 0:08:12.868,0:08:16.880 I got some here. Fascinating substance 0:08:16.880,0:08:19.898 what's it made of? 0:08:20.484,0:08:25.082 two hydrogen atoms one oxygen atom[br]that's what makes a water molecule 0:08:25.472,0:08:28.076 and what's it shaped like? 0:08:28.076,0:08:33.482 Mickey mouse! yes, there is big oxygen in the middle and two little hydrogens forming the ears 0:08:33.482,0:08:42.437 The angle there is the result of (??) the shell arrangement. 0:08:42.437,0:08:46.772 What makes the hydrogen and oxygen stick together? 0:08:46.772,0:08:51.162 think of two atoms, two atoms covered by electrons, two electrons are parallel each other 0:08:51.162,0:08:56.287 what would make two hydrogens and an oxygen stick together? 0:08:56.287,0:09:03.380 And it turns out that if you take these two hydrogens and big oxygen you lay them next to each other 0:09:03.380,0:09:12.156 and you think of the electrons as waves, not particles, then where those waves like to be? 0:09:12.156,0:09:20.400 and those waves would like to be mostly between protons. Protons in hydrogen atom and protons in oxygen atom 0:09:20.400,0:09:25.099 So they will congregate those electron waves will congregate more 0:09:25.099,0:09:30.861 between two atoms, between three atoms actually, then everywhere else 0:09:30.861,0:09:34.964 they still go everywhere else that just that more likely to be between them 0:09:34.964,0:09:47.718 that means there's little extra negative charge between the atoms and that little extra negative charge to tracks the protons and that's covalent bonds 0:09:47.718,0:09:54.029 now if you take this Mickey mouse atom and you divide it in half 0:09:54.136,0:09:57.675 you find there's more negative charge above the one and below the one 0:09:57.675,0:10:02.000 cause all that negative charge likes to sit there between the two hydrogen atoms and oxygen atoms 0:10:02.000,0:10:08.075 So there's more negative charge on one side than the other which means that water molecule is a dipole 0:10:08.075,0:10:10.676 it is negative one side and positive on the other 0:10:10.676,0:10:12.702 this is why water is wet. 0:10:12.702,0:10:20.463 Water sticks to your hand because all the water molecules rotate to stick to the electrically charged surface of your skin 0:10:20.463,0:10:22.614 even though it is not very electrically charged 0:10:22.614,0:10:33.736 this is why water makes it good solvent because the little water molecules would rotate to attract to the parts of the other molecule that they want want to stick to 0:10:33.772,0:10:37.394 this is why water makes it a good cleanser 0:10:37.394,0:10:42.888 and this is why water will do one of the most wonderful things you can do with water[br]who's done this experiment? 0:10:42.888,0:10:51.704 You get a water faucet. You turn it on just so you get a really thin stream of water. Not very fast, just tiny stream of water 0:10:51.704,0:11:02.317 And then you get a balloon and you rub the balloon on your head. And then you hold the balloon close to that stream of water and watch the water bend towards the balloon 0:11:02.317,0:11:06.252 as all the water molecules turn around get it tracked the electric charge 0:11:06.252,0:11:09.585 물론 오늘의 발표 주제는 이게 아니지요.[br] 0:11:10.815,0:11:19.975 오늘 이야기할 주제는 "아키텍처, 잃어 버린 시간" 입니다.[br] 0:11:20.057,0:11:28.490 이 것은 클린 코드와 클린 디자인의 다음 단계에 대한 이야기입니다.[br] 0:11:28.535,0:11:33.876 클린 시스템 스트럭쳐에 대한 이야기 입니다.[br] 0:11:33.876,0:11:38.162 0:11:38.162,0:11:47.069 이 그림은 내가 10년 전에 작성했던 어플리케이션의 디렉터리 구조입니다.[br] 0:11:47.069,0:11:53.089 당시에 Rails를 배우고 있었지요. 여기 Ruby 프로그래머가 있나요? Ruby on Rails 프로그래머? 0:11:53.089,0:11:56.906 저쪽에 손 흔드는 사람이 한 명 있네요. 오케이.[br] 0:11:57.047,0:12:04.404 당시에 Rails를 배우면서 이 어플리케이션을 작성했는데 책의 내용을 따라 했습니다.[br] 0:12:04.404,0:12:09.735 0:12:09.767,0:12:13.839 책에서 이야기하는데로 그대로 작성했더니 이런 형태의 결과가 나왔습니다.[br] 0:12:13.839,0:12:20.077 만족스럽게 마무리했고 그뒤로 오랫동안 보지 않았지요. 0:12:20.140,0:12:27.376 그리고 한 3년 전에 내 아들한테 어플리케이션을 하나 작성해달라고 했습니다.[br] 0:12:27.376,0:12:32.325 그런데 작성된 어플리케이션을 보니 디렉터리 구조가 똑 같았어요.[br] 0:12:32.325,0:12:36.174 0:12:36.174,0:12:40.573 이 둘은 전혀 다른 어플리케이션이고 아무런 연관도 없습니다.[br] 0:12:40.614,0:12:45.121 그런데 디렉터리 구조는 똑 같아요. 이걸 보면서 왜 두 어플리케이션의 최상위 구조가 똑 같은지에 대해서 고민했습니다.[br] 0:12:45.121,0:12:52.868 0:12:52.868,0:12:56.646 이 둘은 전혀 다른 어플리케이션이거든요. 0:12:56.646,0:13:02.958 두 어플리케이션의 디렉터리 구조가 동일한 이유는 둘다 Rails 어플리케이션이기 때문이었습니다. 0:13:02.958,0:13:09.304 그러자 이게 왜 중요한지가 궁금해졌습니다. 0:13:09.304,0:13:20.673 Rails 같은 프레임워크가 얼마나 중요하길래 어플리케이션의 최상위 디렉터로 구조를 결정지어버리는 걸 까요?[br] 0:13:20.726,0:13:25.183 내가 생각한 이유는 바로 다음과 같습니다.[br] 0:13:25.986,0:13:34.191 웹은 전달을 위한 장치입니다. 웹은 I/O 채널이에요.[br] 0:13:34.191,0:13:37.913 웹 자체는 아키텍처적으로 중요하지 않습니다. 0:13:37.980,0:13:42.263 흔히 웹 어플리케이션을 작성한다고 생각하는데 그렇지 않습니다. 0:13:42.263,0:13:44.786 0:13:44.786,0:13:51.940 우리는 컨텐츠를 전달하는 어플리케이션을 작성하고 있는 것 입니다. 0:13:51.940,0:13:57.675 그러면 왜 I/O 채널이 그렇게 중요할까요?[br] 0:13:59.785,0:14:06.705 혹시 웹이 번성하기 시작한 시기를 기억하나요? 1980년대? 1990년대?[br] 0:14:06.705,0:14:13.833 얼마나 큰 변화였는지 기억하나요? 얼마나 모든 것이 근본적으로 변했는지 기억하나요? 0:14:13.833,0:14:19.872 그렇게 큰 변화는 없었습니다. 왜냐하면 실제로 그다지 새로운 것이 아니었기 때문이지요.[br] 0:14:19.872,0:14:26.511 우리는 단지 입력 소스로 부터 입력을 받고, 처리하고, 출력 소스로 내보내기만 했습니다.[br] 0:14:26.573,0:14:28.374 웹은 그냥 그런거에요.[br] 0:14:28.374,0:14:31.082 그런데 왜 왭이 모든 것들을 결정해버릴까요? 0:14:31.082,0:14:39.189 그래서 나는 건축에 대해서 생각해봤습니다. 건축 도면을 봤어요.[br] 0:14:40.649,0:14:49.599 저 건축 도면을 보세요. 저 위에 도서관이라는 글씨가 없더라도 깨닫는데 얼마 걸리지 않을 겁니다. 0:14:49.599,0:14:51.729 도서관이라는게 너무 명백하거든요.[br] 0:14:51.805,0:14:55.882 책장들이 많이 있고 책상도 많습니다.[br] 0:14:55.882,0:15:05.705 책상위에 컴퓨터도 보이고요 책을 대출하고 반납하는 곳도 보여요. 0:15:05.705,0:15:11.167 저 도면을 보고 도서관이라는 것을 알아채는데에 오랜 시간이 걸리지 않을 겁니다.[br] 0:15:11.167,0:15:15.704 다른 것도 봐볼까요? 저건 교회에요. 누가 봐도 교회지요.[br] 0:15:15.704,0:15:20.999 어쩌면 극장이라고 생각할 수 도 있겠지요. 극장이랑 교회는 공통 부분이 있으니까요.[br] 0:15:20.999,0:15:29.736 하지만 이건 분명히 교회입니다. 제단, 바깥의 교실, 0:15:29.736,0:15:31.703 분명히 교회지요. 0:15:31.703,0:15:42.315 이 건물의 아키텍처는 어떻게 지어지는지 이야기하지 않습니다. 0:15:42.315,0:15:49.020 이 건물의 아키텍처는 그 의도 이야기하고 있지요. 아키텍처라는 것은 의도에 대한 것 입니다. 0:15:49.020,0:15:56.016 하지만 저 Rails 어플리케이션들의 최상위 구조는 그 의도에 대해서 이야기하지 않고 있지요. 0:15:56.154,0:16:03.104 저 어플레케이션들은 스스로 Rails 어플리케이션이라는 것을 이야기하고 있습니다. 무언가 잘못되었어요. 0:16:03.104,0:16:05.902 그리고 이런 생각이 들었습니다. 0:16:05.902,0:16:15.087 이건 이미 알려진 문제인가? 이미 해결되었던 문제인가? 이 문제는 1992년에 Iva jacobson이 저술한 책에서 거론되고 해결되었었습니다. 0:16:15.087,0:16:20.638 이 책을 가진 사람이 있나요? 읽어 본 사람? 여기 한 사람있네요 또 없나요? 0:16:20.677,0:16:23.431 Object-Oriented Software Engineering. 아주 훌륭한 책이에요. 0:16:23.503,0:16:29.821 1992년에 출반된 책이지만 상관없어요. 책에 담긴 원칙들은 여전히 유효합니다. 0:16:29.916,0:16:37.212 부제를 보세요. 부제는 'A Usecase driven approach' 입니다. 0:16:37.212,0:16:45.107 유즈케이스 기억하는 사람 있나요? 1990년대에는 아주 아주 유명했었습니다. 0:16:45.107,0:16:54.199 실제론 너무 유명해서 수많은 컨설턴트들에 의해 본래의 의미가 변질되었었지요. 0:16:54.199,0:17:06.426 수많은 컨설턴트들이 자신의 유즈케이스 양식을 인터넷에 앞다퉈서 내놓았었지요. 0:17:06.426,0:17:15.840 그러더니 양식 자체가 매우 중요하게 여겨져 버렸어요. 우리는 그 표준 양식의 빈칸을 채우도록 강요받았지요. 0:17:15.840,0:17:23.318 유즈케이스의 이름, 입력값, 사전조건, 사후조건, 주액터, 부액터 등을 채워야했습니다. 0:17:23.318,0:17:29.726 0:17:29.726,0:17:38.276 우리는 모든 빈칸을 채워야만했고 결국 유즈케이스의 가장 중요한 점은 그 기능이 아니라 양식이 되버렸습니다. 0:17:38.306,0:17:44.214 그 시기의 절정 즈음에 에자일 운동이 시작되었습니다. 0:17:44.214,0:17:52.242 우리는 유즈케이스에 대한 이야기는 멈추고 유저 스토리에 대해 이야기했습니다. 유즈케이스에 대해서는 아무도 이야기하지 않게되었지요. 0:17:52.242,0:17:58.310 그래서 나는 이 책을 다시 읽어봤어요. 0:17:58.310,0:18:02.105 Jacobson이 쓴것들을 다시 기억해냈습니다. 0:18:02.168,0:18:11.409 여기 유즈케이스가 있습니다. 전형적인 Jacobson 스타일의 유즈케이스에요. 0:18:11.444,0:18:15.646 매우 작은 양식이에요. 0:18:15.646,0:18:24.568 '주문 생성'이라는 이름이 있네요. 주문 처리 시스템의 유즈케이스라고 생각해보세요. 0:18:24.568,0:18:31.952 입력 값으로 고객 아이디, 고객 연락처, 수신처 등이 보이네요. 0:18:31.952,0:18:37.657 여기에는 세부적인 내용은 없어요. 고객 아이디가 어떤 것인지 기술하지 않습니다. 0:18:37.657,0:18:40.146 숫자이건 문자열이건 상관없어요. 0:18:40.187,0:18:48.264 고객 연락처가 어떤 것인지 기술하지 않습니다. 아마도 이름 날자 주소등등 이겠지요. 0:18:48.328,0:18:51.560 하지만 세부사항들연 여기에 명시되어있지 않습니다. 0:18:51.599,0:18:55.268 여기 메인 흐름이 있네요. 0:18:55.268,0:19:04.557 메인 흐름은 유즈케이스를 만족시키기 위해 컴퓨터가 실행하는 단계들이에요. 0:19:04.557,0:19:11.037 첫 번째로 주문 담당자는 '주문 생성'을 요청합니다. 0:19:11.073,0:19:18.511 그리고 시스템이 데이터를 검증합니다. 어떻게 검증한다는 이야기는 안했지요? 어떻게든 검증을 하는지는 중요하지 않습니다. 그냥 검증을 한다는게 중요합니다. 0:19:18.575,0:19:23.542 세번째로 시스템이 주문을 생성하고 ID를 결정합니다. 0:19:23.542,0:19:29.089 아마도 어떤 데이터베이스 작업이겠지만 이야기는 안하겠습니다. 0:19:29.089,0:19:35.036 그리고 시스템은 담당자에게 ID를 전달합니다. 아마도 웹 페이지를 통해서겠지만 이야기는 안하겠습니다. 0:19:35.106,0:19:40.426 실제로 이 유즈케이스는 웹에 대해 아무런 이야기도 하지 않습니다. 0:19:40.426,0:19:44.456 이 유즈케이스는 어떤 I/O 채널을 통해서도 구현이 가능하겠지요. 0:19:44.456,0:19:53.606 이 유즈케이스는 콘솔 앱, 데스크탑 앱, SOA 앱, 아이폰 앱에서도 구현이 가능합니다. 0:19:53.606,0:19:59.609 유즈케이스는 I/O 채널을 모르기 때문에 가능한 것 입니다. 0:19:59.609,0:20:09.559 Jacobson은 유즈케이스를 오브젝트로 바꿀 수 있다고 했습니다. 0:20:09.559,0:20:19.878 Jacobson은 저것을 Control Object라고 불렀지만 MVC의 Controller와 헷갈릴 수 있으므로 Interactors라고 이름을 바꿨습니다. 0:20:19.878,0:20:26.239 어쩌면 유즈케이스라는 이름이 더 좋겠지만 그렇게 하지는 않았습니다. Interactors로 부르겠습니다. 0:20:26.239,0:20:38.028 Interactor 오브젝트는 유즈케이스를 구현합니다. 유즈케이스의 입력값을 입력 받아서 유즈케이스의 출력값을 출력합니다. 0:20:38.028,0:20:45.857 그리고 유즈케이스의 처리 흐름을 구현합니다. 0:20:45.857,0:20:54.166 밑에 설명을 보면 어플리케이션 별 비지니스 규칙들을 가진다고 되어있지요? 0:20:54.166,0:20:56.768 거기에는 두 종류의 비지니스 규칙이 있습니다. 0:20:56.768,0:21:06.166 먼저 글로벌할 비지니스 규칙이 있습니다. 모든 어플리케이션에 적용이 가능하지요. 0:21:06.166,0:21:11.695 그리고 개발중인 어플리케이션에만 해당하는 비지니스 규칙들이 있습니다. 0:21:11.695,0:21:22.020 예를 들어서 주문 입력 어플리케이션과 주문 처리 어플리케이션이 있다고 생각해봅시다. 0:21:22.020,0:21:29.693 둘 다 '주문'이라는 오브젝트가 있을겁니다. 그리고 그 주문 오브젝트들은 같은 비지니스 규칙을 가지고 있겠지요. 0:21:29.693,0:21:40.739 하지만 둘 중 하나의 어플리케이션만 주문 추가라는 유즈케이스를 가지고 있을 겁니다. 0:21:40.739,0:21:47.910 유즈케이스는 어플리케이션에 따라 다릅니다. 유즈케이스는 특정 어플리케이션에 종속되지요. 0:21:47.910,0:21:56.696 비지니스 규칙은 어플리케이션에 따라 다르지 않습니다. Entity 오브젝트에 종속됩니다. 비지니스 오브젝트라고 불려지기도 합니다. 0:21:56.727,0:22:01.325 나는 비지니스 오브젝트라는 말은 좋아하지는 않습니다. Jacobson 도 Entiry 오브젝트라고 불렀지요. 0:22:01.405,0:22:10.785 어플리케이션 비종속적인 비지니스 규칙들을 Entity 오브젝트에 넣고 Interactor가 Entity 오브젝트들을 관장합니다. 0:22:10.785,0:22:17.332 그런 후에 유즈케이스의 입력값과 출력값을 다른 유즈케이스에 전달하는 방법을 정합니다. 0:22:17.332,0:22:24.159 이 경우에는 인터페이스를 사용합니다. 그림에 객체지향 방식의 인터페이스로 표현을 했는데요. 0:22:24.159,0:22:31.266 Interactor는 인터페이스 하나를 사용하고 있고요 다른 하나의 인터페이스는 구현을 하고 있습니다. 0:22:31.266,0:22:38.233 Interactor가 구현하고 있는 것은 입력 인터페이스이고요 Interactor가 사용하고 있는 것은 출력 인퍼테이스입니다. 0:22:38.233,0:22:42.174 두 인터페이스와 Interactor 사이의 화살표가 같은 방향이지요? 이 것이 중요한 것 입니다!!!!! 0:22:42.174,0:22:45.106 이게 왜 중요한지는 조금 뒤에 이야기하겠습니다. 0:22:45.106,0:22:53.455 Jacobson은 이 세가지 오브젝트들을 자신의 아키텍처로 이야기했습니다. 0:22:53.455,0:22:57.683 자 그럼 이것들이 어떻게 작용하는지 봅시다. 0:22:57.683,0:23:02.934 일반적인 어플리케이션이 있습니다. 저기 있는 작은 사람이 유저입니다. 0:23:02.934,0:23:10.518 실제 사람이고요 이 사람이 전달 매커니즘을 통해서 시스템과 상호작용합니다. 0:23:10.518,0:23:13.561 전달 매커니즘은 웹일 수도 아닐수도 있겠지요. 아무런 상관 없습니다. 0:23:13.561,0:23:25.915 저 유저는 버튼이나 키보드를 사용해서 시스템이 데이터를 받아들이도록 합니다. 0:23:25.915,0:23:31.619 웹이건 다른 것이건 어떤 전달 메커니즘을 통하는지는 중요하지 않습니다. 0:23:31.619,0:23:37.030 시스템에 전달된 데이터는 Request Model이라는 것으로 변형됩니다. 0:23:37.030,0:23:39.844 Request Model은 순수한 데이터 구조입니다. 0:23:39.844,0:23:50.698 POJO나 POCO와 같은 순수 데이터 구조 입니다. 데이터가 어디에서 왔는지 모르고 웹과 아무런 연관도 없습니다. 0:23:50.698,0:23:52.764 0:23:52.764,0:23:56.904 메소드도 없는 단순한 데이터 구조입니다. 0:23:56.904,0:24:01.911 Public 데이터만 있는 구조로서 모든 입력값을 저장하게됩니다. 0:24:01.976,0:24:11.846 Request Model은 Interactor가 구현한 입력 인터페이스로 전달됩니다. 0:24:11.846,0:24:20.717 Interactor는 Reqeust Model을 받은 후에 데이터를 읽어 해석하고 0:24:20.717,0:24:26.778 작은 여러 커맨드들로 변환하여 Entity들에 보냅니다. 0:24:26.778,0:24:33.196 모든 비지니스 오브젝트들은 Entity로 호출되는 메소드들을 컨트롤합니다. 0:24:33.196,0:24:41.673 작업이 끝난 후에는 반대 방향으로 흘러갑니다. Interactor는 Entity들을 조회하여 변경사항을 확인합니다. 0:24:41.673,0:24:47.942 그 결과로 Result Model이라는 데이터 구조를 만들게됩니다. 0:24:47.942,0:25:01.338 Result Model은 또 다른 순수한 데이터 구조입니다. 단순한 POJO나 POCO이지요. 0:25:01.338,0:25:11.928 Result Model은 출력 인터페이스를 통해서 전달 매커니즘으로 전해집니다. 어떤 방법이 사용되건 출력 인터페이스를 통해서 유저에게 전달이 됩니다. 0:25:11.928,0:25:18.006 저건 다른 모든 어플리케이션들의 흐름이지요. 0:25:18.006,0:25:23.632 그럼 Interactor를 테스트할 수 있을까요? 0:25:23.632,0:25:24.772 매우 쉽겠지요? 0:25:24.772,0:25:30.610 입력 데이터 자료를 생성해서 Interactor를 호출하고 출력 데이터를 보면됩니다. 0:25:30.610,0:25:33.424 이걸 위해 웹 서버가 필요할까요? 0:25:33.424,0:25:40.663 아닙니다. Interactor는 단순히 POJO나 POCO만을 사용하기 때문이지요. 0:25:40.663,0:25:45.237 이걸 위해 데이터베이스가 필요할까요? 어쩌면 필요할 수도 있겠지요 하지만 이 문제는 조금 있다가 이야기하겠습니다. 0:25:45.237,0:25:50.665 전달 메커니즘이 없어도 테스트가 가능합니다. 0:25:50.665,0:25:56.218 전달 매커니즘이 웹 인가요? 상관 없습니다. Interactor를 테스트하는데에 웹 서버는 실행할 필요가 없어요. 0:25:56.218,0:25:58.291 테스트에는 웹 페이지도 역시 필요 없습니다. 0:25:58.291,0:26:07.206 시스템을 테스트 하는데에 처음 입력단 부터 마지막 출력단까지 확인안해도 테스트가 가능합니다. 0:26:12.286,0:26:14.110 MVC는 어떨까요? 0:26:14.110,0:26:18.936 MVC는 우리 모두가 해야만 하는 것 아닐까요? 0:26:20.206,0:26:28.683 MVC는 무엇의 약자이지요? Model View Controller 입니다. 그럼 누가 발명했나요? 0:26:28.683,0:26:35.480 저 사람입니다. 이제 나는 저사람의 이름을 잘못 발음할 겁니다. 당신들이 나모다 더 제대로 발음하겠지요. 0:26:35.480,0:26:41.514 어쨌든 이야기하자면 트릭뷔 륀스카욱. 당신들이 나보다 더 정확히 발음하겠지요.[br](역주: 트릭뷔 륀스카욱은 청중들과 마찬가지로 노르웨이 사람임.) 0:26:41.514,0:26:47.317 나는 저 사람을 만나봤습니다. 저 사람이 1970년대에 MVC를 발명한 사람입니다. 0:26:47.317,0:26:50.027 나흔 저 사람을 한 번 만났는데요, 2년전 여기 이 컨퍼런스에서 였습니다. 0:26:50.027,0:26:57.378 나는 강연자 라운지에서 전원 콘센트를 찾고 있었습니다. 그때 저 나이든 분이 내게와서 콘센트를 건네 줬습니다. 0:26:57.378,0:27:01.080 고개를 올려 보니 "트릭뷔 린스카욱!" 0:27:01.080,0:27:07.596 멀티냅을 주고 받는 사이에 서로 손가락이 스쳤어요! 0:27:07.596,0:27:13.075 나는 한동안 손을 안씼었답니다. 트뤽뷔 린스카욱. 0:27:13.075,0:27:19.293 몇 몇 사람이 나한테 와서 사진을 같이 찍었는데요, 나도 역시 비슷한 부류입니다. 0:27:21.423,0:27:27.284 70년대 말에서 80년대 초에 트뤽비 린스카욱은 Model View Controller라고 부르는 이 구조를 제시했습니다. 0:27:27.284,0:27:30.099 그는 스몰토크 플랫폼에서 이걸 만들었지요. 0:27:30.099,0:27:33.042 기본 개념은 매우 간단합니다. 0:27:33.042,0:27:36.704 비지니스 규칙을 담고있는 모델 오브젝트는 자신이 어떻게 유저에게 보여질지 전혀 모릅니다. 0:27:36.704,0:27:41.326 0:27:41.326,0:27:48.182 단지 순수한 비지니스 규칙입니다. 저기 아래에 있는 컨트롤러는 입력값들을 처리합니다. 0:27:48.182,0:27:59.586 컨트롤러는 입력 기기들을 쳐다 봅니다. 어떤 입력 기기인지는 중요하지 않습니다. 사용자의 행동들을 Model에 대한 커맨드들로 만듭니다. 0:27:59.586,0:28:01.094 그리고 View가 있지요. 0:28:01.094,0:28:06.610 View에는 쌍선으로 그려진 화살표가 있는데요. 옵저버 관계를 의미합니다. 0:28:06.610,0:28:15.161 View는 Model에 등록을 해놓습니다. 그리고 Model이 변경될 때 마다 View가 화면을 업데이트하도록 불리워집니다. 0:28:15.201,0:28:25.347 View는 Model의 컨텐츠를 표시하거나 전달하는 역할을 담당합니다. 0:28:25.347,0:28:35.495 이는 GUI에 아주 효율적입니다. 그리고 콘솔, SOA 등등에도 효율적으로 적용이 가능합니다. 0:28:35.495,0:28:40.718 입력을 컨트롤하는 것이 있고 (Controller)[br]프로세스를 컨트롤하는 것이 있고 (Model)[br]출력을 컨트롤하는 것이 있습니다. (View) 0:28:40.718,0:28:51.260 아마도 이름을 지어진 디자인 패턴인 MVC는 아주 작은 것에 사용하기 위한 것 이었습니다. 0:28:51.260,0:29:01.770 MVC는 버튼에 쓰일 수 있지요. MVC는 체크박스에도 쓰일 수 있습니다. 그리고 MVC는 텍스트 필드에도 쓰일 수 있습니다. 0:29:01.770,0:29:05.310 스크린에는 MVC가 쓰이지 않습니다. 0:29:06.600,0:29:14.920 아주 옛날부터 MVC는 비틀어지고 변형되어 왔습니다. 소프트웨어 분야에서 흔히 일어나는 일이지요. 0:29:14.920,0:29:23.961 어떤게 정말 좋은 것이라고 이야기되면 다른 모든 사람들이 모방을 합니다. 그리곤 완전히 다른 것에 같은 이름을 붙이고는 좋은 것이라고 주장합니다. 0:29:23.961,0:29:29.431 객체지향도 같은 현상이 생겼고, 구조, 오브젝트 에자일 등도 마찬가지였습니다. 0:29:29.431,0:29:37.781 어떤 이름이 무언가 좋은 것을 가리키고 있다면 다른 사람들이 그 이름을 자신의 것에 붙이고 자신의 것도 좋은 것이라고 합니다. 0:29:37.781,0:29:44.013 그건 MVC에도 발생했습니다. 요즘 MVC 프레임워크들이 많이 있지요. 0:29:44.013,0:29:50.485 그 MVC 프레임워크들은 원래 MVC와는 전혀 다릅니다. 트릭뷔 린스카욱의 MVC의 개념과 다릅니다. 0:29:50.485,0:29:54.416 아주 많이 달라요. 실제론 이렇게 생겼지요. 0:29:55.416,0:30:07.350 저기 많은 컨트롤러들이 있지요. 웹 환경에서는 저 컨트롤러들은 웹에 의해 작동됩니다. 0:30:07.350,0:30:12.779 저 구름 너머에 있는 웹 프레임워크지요. Rails 일지 Spring일지 어떤 것이든지 상관없어요. 0:30:12.779,0:30:21.848 어째됬건 그 복잡하고 끔찍한 URL을 전달해서 컨트롤러에 전달합니다. 0:30:21.848,0:30:27.079 웹으로 부터 받은 변수와 데이터를 컨트롤러에게 전달합니다. 0:30:27.079,0:30:33.950 그러면 컨트롤러들은 비지니스 오브젝트들에게 와서 어떤 일을 하라고 소리를 칩니다. 0:30:33.950,0:30:45.731 그리고 비지니스 오브젝트로 부터 데이터를 모아서 뷰에게 이야기합니다. 그러면 뷰들은 다시 비지니스 오브젝트들에게서 데이터들을 조회하고 화면에 표시합니다. 0:30:46.391,0:30:55.422 그러면 결국에는 비지니스 오브젝트들은 컨트롤러나 뷰가 가질법한 펑션들로 채워지며 결국 오염되게 됩니다. 0:30:55.422,0:31:05.373 펑션의 적절한 위치를 찾기가 힘들어져서 비지니스 오브젝트에 놓이면 안되는 펑션들을 비지니스 오브젝트에 구현하기도 합니다. 0:31:09.133,0:31:13.874 그럼 출력 쪽은 어떻게 처리할까요? 0:31:15.764,0:31:20.086 여기 Interactor는 일을 끝냈습니다. 0:31:20.086,0:31:32.300 유즈케이스를 끝내면서 데이터를 조회했지요. 생성된 Response Model을 출력 인터페이스를 통해서 막 전달하려는 시점입니다. 0:31:32.300,0:31:38.262 저 출력 인터페이스는 어떤 것이 구현할까요? Presenter라 불리우는 것 입니다. 0:31:38.262,0:31:44.851 Presenter의 역할은 순수 데이터 구조인 Response Model을 받아서 0:31:44.914,0:31:52.427 View Model이라는 또다른 데이터 구조로 변형시킵니다. 0:31:52.427,0:32:03.575 View Model은 출력의 모델입니다. 출력 값을 표현하는 것이고 여전히 순수한 데이터 구조입니다. 0:32:03.575,0:32:10.685 하지만 화면에 표가 있다면 View Model에도 표가 있을 겁니다. 0:32:10.753,0:32:17.424 화면에 텍스트 필드가 있다면 View Model에도 텍스트 필드가 있을겁니다. 0:32:17.490,0:32:28.201 화면의 숫자를 소수점 이하 두 자리수 까지만 표현하겠다면 ViewModel은 TrimToTwoDecimalPlaces와 ConvertIntToString라는 메소드를 가지게됩니다. 0:32:28.201,0:32:37.522 음수인 경우 괄호로 표현하게 되었다면 Presenter가 괄호를 붙여서 View Model에 저장을 하게됩니다. 0:32:37.596,0:32:43.097 메뉴 아이템들이 있다면 그 이름들도 View Model에 저장이 됩니다. 0:32:43.191,0:32:52.862 비활성화된 메뉴 아이템들은 회색으로 처리되어야 한다면 View Model에는 불린 값으로 저장이 됩니다. 0:32:52.862,0:33:05.357 화면에 표시되는 모든 것들은 View Model에 저장이 됩니다. 여전히 추상화된 방식으로요. 0:33:05.357,0:33:08.167 그리고는 View에 입력이 됩니다. 0:33:08.167,0:33:15.893 View는 멍청해요. View는 저것들과 아무런 관련이 없고요 단순히 View Model로 부터 데이터를 가져갑니다. 0:33:15.893,0:33:21.133 아무 것도 처리하지 않습니다. If 구문도 없고요 아마 테이블을 표시하기 위한 루프문 정도는 있겠지요. 이정도가 다 입니다. 0:33:21.133,0:33:29.606 View는 아주 멍청해서 신경쓸 이유가 없습니다. 일반적으로 테스트도 잘 안하지요. 어찌되었건 우리 눈으로 보게되니까요. 0:33:29.606,0:33:33.069 Presenter를 테스트 할 수 있을까요? 0:33:33.100,0:33:38.321 할 수 있지요. Request Model을 건넨 후에 View Model 데이터를 기다리면 됩니다. 0:33:38.321,0:33:43.797 Presenter를 테스트 할 때에 웹 서버가 실행되어야 할까요? 0:33:43.844,0:33:48.844 아니지요. 웹 서버가 없어도 모두 테스트할 수 있습니다. 0:33:48.844,0:33:53.198 스프링 같은 컨테이너들을 실행할 필요도 없지요. 0:33:53.198,0:33:55.956 그런 것 들을 실행하는 방법을 몰라도 됩니다. 0:33:55.956,0:33:59.520 그냥 평범한 데이터 구조체를 테스트하는 것 처럼 할 수가 있습니다. 0:33:59.520,0:34:06.612 그나저나 이게 목표입니다. 다른 아무것도 실행시키지 않고 가능한 많은 테스트를 하는 것 입니다. 0:34:06.612,0:34:13.095 30초에서 1분 정도나 걸려서 이 서저 저 서버를 시작시키지 않아도 됩니다. 0:34:13.095,0:34:21.176 다른 건 필요 없이 테스트만 실행할 수 있으면 됩니다. 저중 아무 것도 필요 없이 가능한 빠르게 착착착 끝내면 됩니다. 0:34:23.496,0:34:26.049 저게 합쳐 놓은 그림입니다. 0:34:26.049,0:34:32.487 Interactor는 입력 인터페이스를 통해 들어온 Request Model에서 데이터를 가져옵니다. 0:34:32.487,0:34:37.909 그리고 Response Model에 데이터를 담은 후에 출력 인터페이스를 통해 Presenter에게 전달합니다. 0:34:37.909,0:34:48.541 저기 검정색 선을 보세요. 저 선이 어플리케이션과 전달 매커니즘을 구분하는 선입니다. 0:34:48.541,0:34:54.756 그리고 검정선을 지나는 모든 화살표가 어플리케이션을 향하는 것을 보세요. 0:34:54.756,0:35:00.046 어플리케이션은 Controller나 Presenter에 대해 아무것도 모릅니다. 0:35:00.046,0:35:04.828 웹이나 I/O 채널에 대해 아무 것도 모릅니다. 0:35:04.828,0:35:10.755 I/O 채널은 어플리케이션에 대해 알고 있지만 어플리케이션은 I/O 채널에 대해 모르고 있습니다. 0:35:10.755,0:35:21.160 만약에 저 둘을 서로 다른 Jar 파일에 담는다면 어플리케이션 Jar 파일은 웹 Jar 파일을 전혀 의존하지 않게됩니다. 0:35:21.160,0:35:30.222 저 둘을 다른 Jar 파일에 담게되겠지요. 하나는 웹에 대한 Jar 파일이고 하나는 어플리케이션이 담긴 Jar 파일입니다. 0:35:30.222,0:35:33.517 그리고 어쩌면 또다른 I/O 매커니즘에 대한 Jar 파일을 만들 수도 있겠지요. 0:35:33.517,0:35:38.750 그리고 I/O 매커니즘을 변경하려면 그냥 Jar 파일만 바꿔치면 됩니다. 0:35:38.750,0:35:50.047 웹이라는 I/O 매커니즘을 플러그인이라고 생각하세요. 여기 .Net Sharp 사용자가 있나요? 0:35:50.085,0:35:54.910 여기 모두 .Net 개발자 아닌가요? 0:35:54.910,0:36:04.165 어떤 IDE를 사용하지요? IDE용 플러그인을 사용하나요? 0:36:05.885,0:36:14.954 IDE 개발자와 플러그인 개발자 중에 누가 상대방에 대해 알까요? 0:36:17.049,0:36:25.830 플러그인 개발자가 IDE 개발자를 알지요. IDE 개발자는 플러그인 개발자에 대해서 아무것도 모릅니다. 0:36:25.830,0:36:27.668 상관 안하지요. 0:36:27.716,0:36:35.500 둘 중에 누가 상대방에 피해를 줄 수 있을까요? 플러그인 개발자들이 비주얼 스튜디오를 해칠 수 있을까요? 0:36:35.500,0:36:42.543 여기 Resharper 쓰는 사람? Resharper 제작자들이 비주얼 스튜디오를 해칠 수 있을까요? 0:36:42.643,0:36:46.554 - (청중) 예![br]- (로버트 마틴) 아마 실행 중에 죽일 수는 있겠지요. 0:36:46.554,0:36:52.545 하지만 그렇다고 비주얼 스튜디오 개발자들이 대응을 해야 할까요? 0:36:52.545,0:36:58.895 MS의 개발자들이 JetBrains에게 신경 쓸까요? 0:36:58.895,0:37:02.410 아니지요! 그들은 JetBrains는 신경쓰지 않습니다. 0:37:02.483,0:37:10.232 그럼 MS의 개발자들이 JetBrains의 개발자들이 자신들을 따라오게 할 수 있을까요? 0:37:10.232,0:37:13.757 그렇지요! 0:37:13.757,0:37:17.791 그럼 여러분 어플리케이션에 대해 생각해봅시다. 0:37:17.791,0:37:25.851 어플리케이션의 어떤 파트가 어플리케이션의 다른 파트로 부터 보호되어야 할까요? 0:37:25.851,0:37:34.771 어떤 파트가 어플리케이션의 다른 파트의 변경에 따라 수정되어야 할까요? 어떤 파트가 다른 파트의 변경에도 영향을 받지 않아야 할까요? 0:37:34.771,0:37:38.838 답은 아주 간단합니다. 0:37:38.838,0:37:45.152 비지니스 규칙을 웹으로 부터 보호해야합니다. 0:37:45.152,0:37:49.706 웹을 비지니스 규칙으로 부터 보호하면 안됩니다. 0:37:49.706,0:37:59.528 웹에 어떠한 변경이 생겼더라도 비지니스 규칙에는 영향이 없어야 합니다. 아키텍처적으로 보장되어야 합니다. 0:37:59.528,0:38:06.710 저기 모든 화살표는 어플리케이션을 향하고 있습니다. 명심하세요. 저게 플러그인 아키텍처입니다. 0:38:07.680,0:38:11.912 이제 데이터 베이스에 대해 이야기해봅시다. 0:38:14.882,0:38:18.116 0:38:20.396,0:38:22.991 저 그림 속의 데이터베이스가 당신이 생각하는 것과 비슷한가요? 0:38:23.931,0:38:31.846 데이터베이스가 세상의 중심이고 어플리케이션은 변방에 위치한 아랫것들 인가요? 0:38:31.846,0:38:37.573 여기 DBA 있나요? 0:38:37.573,0:38:39.368 아! 없군요 좋습니다. 0:38:39.368,0:38:48.993 (??) 혹시 이런 DBA와 일 해본 경험 있나요? 어플리케이션은 구석으로 치워버리고, 스키마를 정해버리고, 데이터베이스만 우선시하는? 0:38:49.066,0:38:52.413 이게 여러분이 생각하는 데이터베이스인가요? 0:38:52.540,0:38:55.061 내 이야기의 요점은 이 것입니다. 0:38:55.135,0:38:57.389 데이터베이스는 디테일이에요. 0:38:57.389,0:39:00.753 아키텍처적으로 큰 의미가 없습니다. 0:39:00.885,0:39:05.017 데이터베이스는 그냥 저장소일 뿐입니다. 0:39:05.876,0:39:10.112 시스템에서 아키텍처적으로 중요한 것이 아닙니다. 0:39:10.112,0:39:12.791 비지니스 규칙과도 아무런 연관이 없지요. 0:39:12.791,0:39:17.263 설마 Stored Procedure로 비지니스 규칙을 구현했나요? 0:39:17.263,0:39:25.818 Stored Procedure에는 비지니스 규칙 대신 쿼리, 검증, 무결성 검증 등이 들어가야합니다. 0:39:29.898,0:39:32.519 그럼 왜 데이터베이스를 사용할까요? 0:39:34.219,0:39:40.744 왜 데이터베이스는 생겨났을까요? 오라클은 왜 존재할까요? 0:39:45.614,0:39:48.768 데이터베이스가 생기기 전에는 데이터를 어디에 저장했었을까요? 0:39:48.768,0:39:53.494 회전하는 디스크에 저장했었습니다. 여기 디스크 드라이버 개발해본 사람 있나요? 0:39:53.494,0:39:58.375 회전하는 디스크에 데이터를 입출력하는 프로그램을 개발해본 사람 있나요? 0:39:58.456,0:40:06.569 없나요? 0:40:06.569,0:40:10.454 디스켓? 그것도 마찬가지지요. 0:40:10.454,0:40:15.290 데이터를 디스크에 저장하고 읽는 것은 매우 어렵습니다. 왜지요? 0:40:15.290,0:40:18.183 디스크에 데이터가 저장되는 방식 때문입니다. 0:40:18.261,0:40:21.820 데이터는 디스크의 원형 트랙에 저장됩니다. 0:40:21.820,0:40:26.055 플래터 표면에 원형의 트랙이 있습니다. 플래터는 여러 개가 있을 수 있지요. 0:40:26.055,0:40:35.025 헤드가 트랙을 찾기위해 전/후로 움직입니다. 그러므로 원하는 트랙으로 해드를 움직여야 하지요. 0:40:35.066,0:40:38.941 그리고 디스크가 회전하면서 데이터를 읽게됩니다. 0:40:38.941,0:40:46.894 그 다음에 원하는 섹터를 찾아야 합니다. 트랙에는 50~60개의 섹터가 있고요 각각의 섹터는 4k 바이트의 데이터를 가지고 있습니다. 0:40:46.894,0:40:52.282 그러므로 디스크가 회전해서 원하는 섹터가 올때까지 기다렸다가 데이터를 읽어야 합니다. 0:40:52.282,0:40:57.368 그런 후에 섹터에 저장된 데이터에서 원하는 바이트를 찾아야합니다. 0:40:57.368,0:41:01.134 어렵습니다. 그리고 느려요. 0:41:01.144,0:41:05.141 제대로 작성하지 않으면 아주 아주 오래걸릴 수도 있습니다. 0:41:05.141,0:41:13.866 그래서 사람들은 이 문제를 전담할 시스템을 만들었습니다. 데이터베이스 말입니다. 0:41:15.106,0:41:17.502 그런데 변화가 생겼습니다. 0:41:17.502,0:41:28.339 여기 내 노트북 보이나요? 내 노트북은 500MB짜리 SSD가 있습니다. 디스크는 없어요. 놀랍지는 않지요? 0:41:28.339,0:41:30.936 여기 디스크를 가진 사람 있나요? 0:41:30.936,0:41:34.012 여기 회전하는 디스크를 가진 사람? 0:41:34.012,0:41:37.070 오! 진짜로요? 0:41:37.070,0:41:43.249 요즘 HDD를 사고싶은 사람은 없어요. SSD가 대세입니다. 0:41:43.249,0:41:50.126 어쩌면 서버룸에는 HDD가 있을지도 모릅니다. 하지만 거기도 조만간 없어질 겁니다. 0:41:51.019,0:41:55.998 앞으로 몇 년 후에는 HDD는 사라질 겁니다. 모든 것이 RAM으로 교체되겠지요. 0:41:56.081,0:41:59.719 RAM 말입니다. 0:41:59.719,0:42:04.421 RAM은 원하는 바이트를 직접 읽을 수 있습니다. 0:42:04.498,0:42:13.672 우리가 궁극적으로 추구하는 저장 매체는 무한한 용량의 비휘발성 RAM입니다. 0:42:13.672,0:42:17.634 우리가 궁극적으로 데이터를 저장할 매체이지요. 0:42:17.634,0:42:27.902 그렇게 직접 액세스할 수 있는 저장 매체가 있다면 왜 SQL을 써야만 할까요? 0:42:27.902,0:42:32.101 SQL은 어렵습니다. Table도 어렵습니다. 0:42:32.101,0:42:36.937 해시 테이블에서 데이터를 찾기보다 포인터로 바로 액세스하는 것이 좋겠지요? 0:42:36.937,0:42:44.662 지금도 그렇게 하고 있지 않나요? 테이블에 저장된 데이터를 읽어서 좀 더 사용하기 좋은 구조에 저장합니다. 0:42:44.662,0:42:49.298 그냥 우리가 사용하는 포멧 그대로 저장하면 어떨까요? 0:42:49.298,0:42:52.746 내가 오라클이라면 아주 겁이 날 겁니다. 0:42:52.801,0:42:57.280 내 존재의 이유가 서서히 사라지고 있거든요. 0:42:57.280,0:43:02.567 대규모 데이터베이스 시스템이란 개념은 점차 사라지고 있습니다. 0:43:05.317,0:43:10.279 그럼 어플리케이션을 이런 사소한 것으로 어떻게 보호할까요? 0:43:10.279,0:43:19.105 이런 사소한 데이터베이스는 모든 것을 결정해버리곤 하지요. 어쨌건 웹을 격리한 방법으로 어플리케이션을 데이터베이스로 부터 보호할 수 있습니다. 0:43:19.105,0:43:23.129 자 여기 또 하나 굵은 선을 그립니다. 0:43:23.198,0:43:30.444 자세히 보세요, 이 선을 지나는 모든 선은 어플리케이션을 향하고 있습니다. 0:43:30.444,0:43:35.554 데이터베이스는 어플리케이션의 플러그인이 되었지요? 0:43:35.554,0:43:38.924 이제오라클을 MySQL로 바꿀 수 있습니다. 0:43:38.924,0:43:42.706 아니면 MySQL을 버리고 CouchDB로 바꿀 수도 있지요. 0:43:42.706,0:43:47.465 아니면 CouchDB를 버리고 Datomic이나 다른 걸로 바꿀 수 있습니다. 0:43:47.465,0:43:50.248 데이터베이스를 플러그인으로 교체할 수 있습니다. 0:43:50.248,0:43:57.116 데이터베이스를 실제로 바꾸지 않을지도 몰라요. 하지만 그럴 수 있다는 것은 좋은 겁니다. 실제로 필요하지 않다고 해도 말입니다. 0:43:57.116,0:44:01.082 그럼 어떻게 하면될까요? 저 위에 인터페이스를 하나 더 두면 됩니다. 0:44:01.082,0:44:03.062 Entity GateWay라고 이름을 붙였습니다. 0:44:03.102,0:44:10.159 보통 Entity 하나당 하나의 Entity Gateway를 가집니다. Entity Gateway의 메소드들은 모두 쿼리 메소드들입니다. 0:44:10.159,0:44:14.247 모든 쿼리문에 해당하는 메소드가 존재합니다. 0:44:14.247,0:44:19.247 Entity Gateway의 구현부는 저 선 아래에 위치합니다. 0:44:19.247,0:44:23.128 구현부는 아마도 데이터베이스를 사용하겠지요. 0:44:23.128,0:44:29.917 자세히보세요. 데이터베이스에 관한 어떤 부분도 어플리케이션에 노출되지 않습니다. 0:44:29.917,0:44:39.838 그럼 Entity Object는 어디에서 올까요? 아마도 데이터베이스에서 읽어져 올라올겁니다. 테이블에 어떤 모양으로 저장되어있건 말이지요. 0:44:39.838,0:44:44.115 Entity Gateway의 구현체는 그 데이터들을 읽어 모아 Entity Object에 저장합니다. 0:44:44.115,0:44:47.673 그런 후에 저 선 넘어로 전달하는 거지요. 0:44:47.673,0:44:53.114 저 선을 넘어오면 어플리케이션에게 Entity Object가 되는 겁니다. 0:44:55.164,0:45:00.283 여기 Hibernate 쓰는 사람있나요? ORM 툴? 0:45:00.283,0:45:02.045 누구 쓰는 사람있어요? 0:45:02.066,0:45:06.983 ORM 툴은 저 그림에서 어디에 있을까요? 0:45:06.983,0:45:10.485 구현부에 있습니다. 저 선 아래지요! 0:45:10.485,0:45:16.176 저 선넘어에선 ORM 툴의 존재에 대해 아무것도 모릅니다. 0:45:16.176,0:45:21.664 혹시 비지니스 오브젝트에 어노테이션이 어트리뷰트들을 붙어있나요? 없애 버리세요! 0:45:21.664,0:45:25.465 비지니스 오브젝트들은 Hibernate 같은 툴과 직접적인 연관이 없어야합니다. 0:45:25.465,0:45:31.817 저 선 아래의 것들은 데이터베이스 등에 오염된 사람이 개발하게 하세요. 0:45:31.831,0:45:36.131 비지니스 오브젝트는 오염되지 않아야합니다. 왜일까요? 0:45:37.741,0:45:40.556 오브젝트란 무엇인가요? 0:45:43.106,0:45:45.360 천천히 이야기해봅시다. 0:45:46.610,0:45:54.363 오브텍트란 무엇인가요? 오브텍트는 퍼블릭 메소드들의 집합니다. 0:45:54.363,0:46:00.727 그 나머지는 알려져선 안됩니다. 그렇지요? 0:46:00.727,0:46:04.792 그 안에 데이타가 있을지도 몰라요. 하지만 그걸 볼 수 있으면 안됩니다. 모두 비밀입니다. 0:46:04.792,0:46:11.459 여러분의 관점에서 오브젝트는 메소드 덩어리입니다. 데이터 덩어리가 아닙니다. 0:46:11.459,0:46:13.618 오브젝트는 메소드 덩어리입니다. 0:46:13.618,0:46:17.075 그러므로 오브젝트는 행위에 대한 내용입니다. 0:46:17.075,0:46:20.863 그러므로 오브젝트는 비지니스 규칙에 대한 내용입니다. 0:46:20.863,0:46:23.213 데이터가 아닙니다. 0:46:23.213,0:46:26.228 아마도 안에 데이터가 있긴 하겠지요. 하지만 우리는 몰라요. 0:46:26.228,0:46:29.990 어떤 형태로 저장되는지 모릅니다. 알 필요도 없어요. 0:46:29.990,0:46:32.973 그럼 데이터 구조체는 무엇일까요?[br](역주: Object와 Data Structure를 구분하여 사용하고 있음) 0:46:32.973,0:46:40.606 데이터 구조체는 잘 알려진 데이터 요소들입니다. 누구에게나 공개되지요. 0:46:40.606,0:46:42.761 데이터 구조체에는 메소드가 없습니다. 0:46:42.761,0:46:44.779 데이터 구조체는 펑션이 없어요. 0:46:44.779,0:46:47.263 오브젝트와 데이터 구조체는 완전히 반대되는 것들입니다. 0:46:47.263,0:46:54.612 데이터 구조체는 공개된 데이터를 가지고 메소드가 없습니다.[br]오브젝트는 메소드를 가지지만 공개된 데이터가 없습니다. 0:46:54.612,0:46:56.112 정확하게 반대이지요. 0:46:56.112,0:47:00.133 ORM이란 말은 틀린말입니다. 0:47:00.175,0:47:03.339 오브젝트와 관계데이터는 매핑할 수가 없어요. 0:47:03.411,0:47:10.222 데이터베이스에서 나온 것은 데이터 구조체입니다. 데이터 구조체는 오브젝트에 매핑할 수가 없는 것 이지요. 0:47:10.268,0:47:12.452 서로 완전히 다른 것이기 때문입니다. 0:47:12.452,0:47:19.613 Entity에 저장되는 데이터는 어딘가에서 제공됩니다. 어딘지는 아무도 몰라요. 0:47:19.613,0:47:26.614 그리고 엔티티로 전달됩니다. 어떻게 전달되는지는 상관없어요. 0:47:26.615,0:47:31.151 그 엔티티 오브젝트들은 Hibernate가 생성하지 않습니다. 0:47:31.151,0:47:38.006 아마도 엔티티 오브젝트들은 Hibernate가 만든 데이터 구조체들을 사용하고 있을지도 몰라요. 어떻게 하는지는 관심없습니다. 0:47:38.006,0:47:45.239 저 검정선 아래의 Hibernate나 프레임워크에 대해선 아무 것도 몰라도 됩니다. 0:47:45.239,0:47:48.358 저 선 아래의 것들은 오엽될 수 있습니다. 0:47:48.358,0:47:54.559 저 선 위의 것들은 내 속살과 같이 소중한 것 입니다. 아주 소중하게 보호해야하는 것 이지요. 0:47:54.559,0:48:02.572 저 위의 것들은 비지니스 규칙들입니다. 나는 내 비지니스 규칙들이 프레임워크로 오염되지 않게 할겁니다. 0:48:02.572,0:48:09.793 프레임워크. 사람들은 자신들이 사용하는 프레임워크를 좋아합니다. 아주 멋지지요. 0:48:09.793,0:48:14.859 프레임워크는 많은 시간을 절감해준다고 생각합니다. 실제로도 그렇습니다. 0:48:14.859,0:48:21.820 하지만 프레임워크 제작자는 우리를 프레임워크에 종속되도록 유도합니다. 0:48:21.820,0:48:26.278 그들은 베이스 클래스를 만들어서 우리가 그것들을 상속해서 사용하기를 바랍니다. 0:48:26.278,0:48:32.477 프레임워크의 베이스 클래스를 상속하는 순간 우리는 벗어나지를 못합니다. 0:48:32.477,0:48:40.045 그 베이스 클래스에 아주 강하게 종속되는 거지요. 상속보다 더 강한 관계는 없습니다. 0:48:40.045,0:48:47.430 다른 사람의 베이스 클래스를 상속한다는 것은 아주 무거운 맹세를 하는 것과 같습니다. 0:48:47.493,0:48:52.156 반대로 프레임워크는 당신에게 아무런 맹세를 하지 않습니다. 0:48:52.156,0:48:54.684 비대칭적인 관계이지요. 0:48:54.684,0:49:02.244 프레임워크 제작자는 우리의 헌신으로 이익을 챙기지만 그들은 우리에게 어떤 책임도 지지 않습니다. 0:49:02.305,0:49:06.524 스스로 곰곰히 생각해보세요. 0:49:06.524,0:49:12.336 현명한 아키텍트는 저런 관계를 맺지않습니다. 0:49:12.336,0:49:20.705 현명한 아키텍트는 프레임워크를 비판적으로 접근합니다. 프레임워크가 일을 어렵게 만들 수 있다고 봅니다. 0:49:20.705,0:49:25.605 프레임워크는 우릴 종속시키려합니다. 하지만 그럴 순 없지요. 0:49:25.605,0:49:30.985 나는 비지니스 규칙과 프레임워크 사이에 경계선을 그을 겁니다. 0:49:30.985,0:49:39.477 내 비지니스 규칙이 Hibernate나 Spring 같은 프레임워크들에 종속되지않게 할겁니다. 0:49:39.477,0:49:43.966 나는 프레임워크를 이용할 겁니다. 아주 조심스럽게요. 0:49:43.966,0:49:49.822 왜냐하면 프레임워크 제작자는 내가 가장 중요하게 생각하는 것이 무엇인지 모르기 때문입니다. 0:49:55.672,0:50:03.334 Fitnesse는 나와 아들 그리고 몇 몇 사람이 오래 전에 만들었습니다. 0:50:03.334,0:50:06.533 여기 Fitnesse 쓰는 사람이 있나요? 오 많군요 좋습니다. 0:50:06.533,0:50:13.149 Fitnesse는 사용자 인수테스트를 작성하는 툴입니다. 0:50:13.188,0:50:17.576 위키 기반으로 개발되었지요. 위키 기반이라는 것이 중요합니다. 0:50:17.576,0:50:19.397 누가 위키를 개발했지요? 0:50:19.437,0:50:22.483 워드 커닝햄. 워드 커닝햄은 어떤 사람인가요? 0:50:22.483,0:50:26.765 위키 개발자! 하~ 그 것 보다 더 많습니다. 0:50:26.765,0:50:35.256 워드 커닝햄은 구루들의 구루입니다. 모든 구루들은 워드 커닝햄이 누구인지 압니다. 0:50:35.256,0:50:39.995 나처럼 컨퍼런스에 연사로 초빙되는 사람들은 모두 워드 커닝햄에 대해 알고있습니다. 0:50:40.028,0:50:42.006 우리는 워드 커닝햄을 리뷰합니다. 0:50:42.006,0:50:46.424 그가 에릭 감마에게 전화 걸어 이야기 했지요 0:50:46.424,0:50:49.760 "이봐 에릭, 디자인 패턴이란 책을 써보는거 어때?" 0:50:49.800,0:50:58.122 그는 캔트 백의 멘토이기도 했지요. 캔트 백에게 페어 프로그래밍, TDD, 에자일 개발 등을 가르쳤습니다. 0:50:58.122,0:51:06.937 당신이 소프트웨어의 역사를 유심히 본다면 아주 많은 곳에 그가 영향을 끼친 것을 알게될겁니다. 0:51:06.937,0:51:12.160 Fitnesse는 Wiki와 Fit를 기반으로 개발되었습니다. 둘다 워드 커닝햄의 발명품이지요. 0:51:12.204,0:51:16.212 오늘은 Wiki에 대해서만 이야기하겠습니다. 0:51:16.212,0:51:24.896 우리들은 Fitnesse를 자바로 개발하기로 결정했습니다. 12년이나 13년 전에요. 0:51:24.896,0:51:27.807 우리는 위키 형태로 만들기로 했습니다. 0:51:27.807,0:51:34.958 우린 처음에 생각했습니다. "위키 페이지들을 저장할 공간이 필요하겠군, 데이터베이스에 저장합시다. 어떤 데이터베이스가 좋을까" 0:51:34.992,0:51:41.925 그 당시에는 MySQL이 유일한 오픈소스 데이터베이스였습니다. 그래서 모두 MySQL에 저장하는 것으로 결정했지요. 0:51:43.245,0:51:50.880 그래서 MySQL을 설치하고 데이터 스키마를 정하려고 할 때에 누군가 이야기했습니다. 0:51:50.880,0:51:53.550 "지금 당장 할 필요는 없지 않겠어?" 0:51:53.550,0:51:58.793 "그건 나중에 하고 당장은 다른 문제들 부터 해결하는게 좋을 것 같아." 0:51:58.793,0:52:03.312 다른 문제들이란 위키 텍스트를 HTML로 변경하는 작업이었습니다. 위키의 기본 기능이지요. 0:52:03.382,0:52:07.185 위키에 입력한 텍스트들을 받아서 HTML로 변경하는 것 말입니다. 0:52:07.251,0:52:10.156 그런 변환 작업이 아주 많이 있었어요. 0:52:10.156,0:52:14.258 그래서 3개월 동안은 데이터베이스는 잊고 지냈습니다. 0:52:14.258,0:52:21.379 위키 텍스트를 HTML로 저장하기위해 우린 WikiPage라는 오브젝트를 만들었습니다. 0:52:21.414,0:52:22.968 저기 맨 위에 있지요. 0:52:22.968,0:52:29.995 추상 클래스인 WikiPage는 MockWikiPage가 구현하고 있습니다. 0:52:29.995,0:52:37.446 WikiPage는 데이터베이스 처럼 Load, Save 같은 펑션들을 가지고 있습니다. 0:52:37.490,0:52:40.028 하지만 실제 구현은 되어있지 않습니다. MockWikiPage의 Load/Save는 그냥 빈 껍데기입니다. 0:52:40.028,0:52:43.364 한 3달 동안 그런식으로 일했습니다. 0:52:43.364,0:52:49.177 모든 페이지 변환 코드가 끝난 후에 말했습니다. "자 이제 데이터베이스를 구동합시다." 0:52:49.177,0:52:52.039 "저 페이지들을 어딘가에는 저장해야만 해요" 0:52:52.070,0:52:54.670 누군가가 말했습니다. "글쎄 아직 데이터베이스는 없어도 될 것 같은데" 0:52:54.670,0:53:00.006 "대신에 변환된 페이지들은 메모리의 해시테이블에 저장해면 될 것 같아" 0:53:00.056,0:53:02.590 "아직은 디스크에 저장할 필요는 없지 않아?" 0:53:02.590,0:53:06.356 그럴 필요는 없었지요. 그때 단위테스트 작성하느라 바빴거든요. 0:53:06.356,0:53:14.871 그래서 우린 WikiPage를 구현하는 또 다른 클래스를 만들었습니다. InMemoryPage였지요. 우린 그 안의 해시테이블에 모든 것을 저장했습니다. 0:53:14.871,0:53:17.436 우린 그렇게 1년을 더 보냈습니다. 0:53:17.786,0:53:21.611 모든 데이터는 메모리에 저장하면서 계속 개발 했습니다. 0:53:21.611,0:53:24.294 드디어 Fitnesse가 동작을 했습니다. 0:53:24.744,0:53:27.280 디스크에 아무 것도 저장을 안하는 상태로요. 0:53:27.332,0:53:32.169 모든 테스트들이 매우 빠르게 완료되었습니다. 데이터 베이스가 없었거든요. 0:53:32.169,0:53:38.712 반면에 전원을 끄고나면 모든 것이 사라지는건 좀 불편했지요. 0:53:38.712,0:53:44.721 그러던 순간 드디어 누군가 말했습니다. "자 이제 데이터베이스를 구동할 시간이야. MySQL을 설치합시다." 0:53:44.721,0:53:46.664 그때 마이클 페더스가 같이 있었어요. 0:53:46.664,0:53:50.274 마이클이 이야기 했습니다. "글쎄 아직은 MySQL이 없어도 되지 않겠어?" 0:53:50.350,0:53:58.620 "실제 필요한 것은 저장하는 거잖아. 그냥 해시 테이블의 내용을 파일에 저장하는게 훨씬 간단하지 않겠어?" 0:53:59.260,0:54:06.860 좀 옹색하지만 한동안은 문제가 없어 보였습니다. 나중에 MySQL로 바꾸면되니까 일단 그렇게 했습니다. 0:54:06.860,0:54:11.112 그 뒤로 3개월간 계속 개발을 했습니다. 0:54:11.112,0:54:16.374 우린 들고다니면서 사람들에게 보여줄 수 있어서 좋았습니다. 실제 저장도 되었고요. 0:54:16.426,0:54:18.278 진짜 위키처럼 동작을 했지요. 0:54:18.551,0:54:27.959 3개월 뒤에 이야기했습니다. "데이터베이스가 필요 없겠는걸." 0:54:28.539,0:54:31.807 "잘 동작하는데. 파일에 저장해도 충분히 빨라" 0:54:31.879,0:54:33.691 "이거면 충분한데." 0:54:33.732,0:54:38.884 우린 아키텍처적으로 매우 중요한 결정을 최대한 연기했고 결국엔 결정할 필요가 없게 되었습니다. 0:54:38.884,0:54:43.799 데이터베이스는 아예 넣지 않았습니다. 그런데 실제로는 다른 누군가가 추가하긴 했었지요. 0:54:44.249,0:54:49.745 고객 중 한명이 와서 이야기 했습니다. "우린 데이터베이스가 필요합니다." 0:54:49.745,0:54:52.371 우린 물었지요 "왜요? 파일시스템으로도 잘 동작합니다." 0:54:52.495,0:54:59.032 그가 이야기했습니다. "회사 정책입니다. 모든 데이터는 데이터베이스에 저장되어야합니다." 0:54:59.032,0:55:04.115 누가 그렇게 이야기했는지는 모르겠습니다. 아마 데이터베이스 영업 사원의 능력이 아주 좋았나봅니다. 0:55:04.415,0:55:11.854 그래서 이야기했습니다. "진짜로 데이터베이스가 필요하다면" 0:55:13.624,0:55:24.208 "여기 WikiPage를 구현하는 MySQLPage를 만드세요. 그렇게만 하면 될겁니다." 0:55:24.251,0:55:27.162 바로 다음 날에 MySQL과 연동 작업은 끝났습니다. 0:55:27.162,0:55:31.468 우린 MySQL 연동 기능을 플러그인으로 배포했었는데요 아무도 사용하지 않아서 이젠 배포하고 있지 않습니다. 0:55:32.018,0:55:37.936 우린 아키텍처에 대한 의사결정을 미루고 미루고 또 미뤘습니다. 0:55:38.003,0:55:41.034 프로젝트가 끝날때까지 미뤘고 결국에는 하지를 않았습니다. 0:55:41.034,0:55:45.352 우리가 가장 먼저 했어야 했던 것인데 결국엔 하지를 않았어요. 0:55:45.352,0:55:49.120 결국 이런 결론이 나옵니다. 0:55:50.619,0:56:00.209 중요한 의사결정을 뒤로 미룰 수 있는 아키텍처가 좋은 아키텍처이다. 0:56:00.209,0:56:05.107 아키텍트의 목표는 결정을 안하는 것이에요. 0:56:05.147,0:56:12.618 가능한 많은 정보를 가진 상태로 결정을 할 수 있게 미루고 미루는 것 이지요. 0:56:12.618,0:56:21.953 모든 상위 결정들을 미룰 수 있도록 아키텍처나 코드 구조를 설계해야합니다. 0:56:21.953,0:56:28.929 어플리케이션의 아키텍처를 이야기할 때에 프레워크 이름들을 이야기 하지 마세요. 0:56:28.970,0:56:35.568 "어플리케이션의 아키텍처가 무엇입니까? 네 우린 SQL서버, MVVM, ..." 0:56:35.568,0:56:37.347 아키텍처에 대해 아무런 내용이 없는 이야기입니다. 0:56:37.347,0:56:40.744 단지 사용하는 툴들을 나열하는 것 뿐입니다. 0:56:40.744,0:56:43.011 그건 어플리케이션의 아키텍처가 아닙니다. 0:56:43.075,0:56:46.104 어플리케이션의 아키텍처는 유즈케이스들입니다. 0:56:46.104,0:56:50.460 어플리케이션의 유즈케이스들이 툴에 대해서 모르게 해야합니다. 0:56:50.460,0:56:54.847 저런 툴을 사용하는 것은 가능한 늦게 결정해야합니다. 0:56:54.847,0:57:02.270 웹이나 데이터베이스가 없이도 어플리케이션의 모든 부분을 실행 할 수 있어야 합니다. 0:57:02.270,0:57:07.483 어쩌면 어플리케이션 테스트를 위해 잠시동안 작고 심플한 웹 프레임웍을 쓸 수는 있겠지요. 0:57:07.483,0:57:12.177 간단하게 일부 화면을 볼 수 있게 말입니다. 거대한 웹 프레임워크를 구동하지 않고도요. 0:57:12.177,0:57:17.485 어쩌면 아주 심플한 데이터베이스를 사용할 수도 있겠지요. 단순히 데이터가 저장되는 것을 확인하려고요. 0:57:17.485,0:57:23.627 오라클 등으로 저런 작업을 하려면 라이센스 비용 처럼 이것 저것 복잡한 일들이 많습니다. 0:57:25.347,0:57:34.497 다음에 어플리케이션을 개발할 때에 어떤 결정들을 미룰 수 있는지 생각해보세요. 0:57:37.757,0:57:48.049 어플리케이션은 플러그인 구조여야합니다. 아키텍처는 플러그인 구조여야 합니다. 0:57:48.083,0:57:55.076 GUI, 데이터베이스, 프레임워크 같은 디테일들은 모두 유즈케이스의 플러그인이 되어야 합니다. 0:57:55.076,0:57:57.959 유즈케이스가 어플리케이션의 핵심입니다. 0:57:59.809,0:58:03.990 물론 고객은 웹 페이지를 보고 싶어하지요. 0:58:03.990,0:58:10.463 플러그인 아키텍처로도 역시 고객에게 웹 페이지를 보여줄 수 있습니다. 0:58:10.514,0:58:13.339 프레임워크에 큰 헌신을 맹세할 필요가 없습니다. 0:58:13.339,0:58:16.647 웹 프레임워크에 막대한 헌신을 맹세할 필요가 없습니다. 0:58:16.647,0:58:19.084 처음엔 작은 걸 보여두면 충분할 겁니다. 0:58:19.084,0:58:25.807 만약에 꼭 프레이워크를 사용하고 싶다면, 그렇게 하세요. 단 플러그인 구조는 유지하세요. 0:58:25.807,0:58:29.285 그래야 필요시 빠르게 대체가 가능합니다. 0:58:31.245,0:58:35.177 이제 마지막 주제입니다. 0:58:35.857,0:58:39.417 TDD. TDD에 대해선 이미 이야기 했지요. 0:58:41.737,0:58:45.463 감사합니다. 질문 있습니까? 0:58:47.635,0:58:50.950 잘 안보이네요. 밑으로 내려가보겠습니다. 0:58:54.550,0:58:56.664 여전히 안보이군요. 0:58:57.464,0:59:01.372 자 질문 있습니까? 0:59:01.372,0:59:04.449 손드는게 안보이니까 크게 이야기해주세요. 9:59:59.000,9:59:59.000 예 9:59:59.000,9:59:59.000 (질문 중) 9:59:59.000,9:59:59.000 오라클 같은 관계형 데이터베이스의 종말을 예고했는데 그 다음은 어떤 것이 될 거라고 생각하냐고요? 9:59:59.000,9:59:59.000 아주 좋은 질문입니다. 9:59:59.000,9:59:59.000 그냥 RAM으로 충분할지도 모르지요. 왜 데이터베이스를 대체할 것이 필요할까요? 9:59:59.000,9:59:59.000 RAM에 데이터를 구성하고 RAM의 데이터가 비휘발성이라면, 더 필요한게 있을까요? 9:59:59.000,9:59:59.000 하지만 더 필요한게 있다고 가정하고 이야기해봅시다. 9:59:59.000,9:59:59.000 그 다음은 어떤 것 일까요? 9:59:59.000,9:59:59.000 여기 CQRS에 대해 들어본사람 있나요? 9:59:59.000,9:59:59.000 네 조금 있군요. 9:59:59.000,9:59:59.000 CQRS는 참 흥미로운 아이디어입니다. 9:59:59.000,9:59:59.000 우리가 무한대의 고속 메모리를 가졌다고 생각해봅시다. 아주 빠른 RAM이요. 9:59:59.000,9:59:59.000 어쩌면 디스크일 수도 있겠지요. 9:59:59.000,9:59:59.000 상태 값을 저장할 이유가 있을까요? 9:59:59.000,9:59:59.000 그냥 트랜즈액션만 저장하면 되지 않을까요? 9:59:59.000,9:59:59.000 은행 계좌의 잔고를 저장하는 대신에 계좌를 생성한 트랜잭션을 저장하면 어떨까요? 9:59:59.000,9:59:59.000 은행 계좌의 이름, 주소, 잔고를 변경시키는 트랜잭션들이요. 9:59:59.000,9:59:59.000 왜 트랜잭션들을 저장한 후에 상태 값들을 재구성하면 어떨까요? 9:59:59.000,9:59:59.000 아마도 시간이 오래 걸린거라고 생각할겁니다. 9:59:59.000,9:59:59.000 맞아요. 하지만 CPU의 처리능력은 막강합니다. 9:59:59.000,9:59:59.000 이제는 할 수 있어요. 우린 거의 무한대의 처리능력과 메모리를 가지고 있습니다. 9:59:59.000,9:59:59.000 그냥 이벤트들만 저장하는건 어떨까요? 9:59:59.000,9:59:59.000 매우 흥미로운 아이디어라고 생각합니다. 9:59:59.000,9:59:59.000 이벤트들을 저장하면 아무 것도 삭제할 필요가 없습니다. 9:59:59.000,9:59:59.000 업데이트를 할 필요도 없지요. 9:59:59.000,9:59:59.000 CRUD 알지요? Create. Read. Update. Delete. 9:59:59.000,9:59:59.000 U와 D 두 글자를 잃어버리고 C와 R만 남게될 겁니다. 9:59:59.000,9:59:59.000 생성하고 조회하고. 업데이트나 삭제를 할 일이 없어집니다. 9:59:59.000,9:59:59.000 업데이트나 삭제를 안한다면 트랜잭션은 없어도 됩니다. 9:59:59.000,9:59:59.000 업데이트를 안한다면 동시성과 관련된 문제가 없어집니다. 9:59:59.000,9:59:59.000 아주 흥미롭지요. 9:59:59.000,9:59:59.000 이런 생각들을 기반으로 하는 프레임워크들이 있을까요? 네 있습니다. 9:59:59.000,9:59:59.000 몇 몇 개가 있습니다. 9:59:59.000,9:59:59.000 Write Only 데이터베이스들이지요. Write Once & Read Many Times. 9:59:59.000,9:59:59.000 지금은 이야기를 하지 않겠습니다만 웹에서 검색을 하면 나옵니다. 9:59:59.000,9:59:59.000 한 번 찾아보세요. 9:59:59.000,9:59:59.000 관계형 데이터베이스를 그런 것 들로 대체할지도 모르지요. 9:59:59.000,9:59:59.000 Couch나 Mongo DB로 교체할지도 모릅니다. 어떠면 새로 만들수도 있겠지요. 9:59:59.000,9:59:59.000 상관없어요. 대형 벤더에서 제공하는 것을 사용할 필요가 없습니다. 9:59:59.000,9:59:59.000 저 하늘위의 거대한 회사들이요. 9:59:59.000,9:59:59.000 저 하늘 위에서 말합니다. "그래 우리 데이터베이스 시스템의 사용을 허락하마." 9:59:59.000,9:59:59.000 그냥 DB를 만들어 써도 됩니다. 그렇게 어렵지 않아요. 9:59:59.000,9:59:59.000 다른 질문 있나요? 9:59:59.000,9:59:59.000 그렇게 하니까 잘 보니에요. 9:59:59.000,9:59:59.000 오케이. 또 다른 질문 없나요? 9:59:59.000,9:59:59.000 (누군가 질문 하는 중) 9:59:59.000,9:59:59.000 의사결정을 미루는 것이 어려울 때도 있는데... 9:59:59.000,9:59:59.000 가족이 있을때요? (청중들이 웃음) 9:59:59.000,9:59:59.000 가족 동반 휴가 처럼 여러 요소들이 같이 결정되는 것을 이야기하는 것 이지요? 결정이 필요한 것 중에 연기가 가능한 것들이 있습니다. 9:59:59.000,9:59:59.000 예를 들어, 어떤 언어로 개발을 할까? 와 같은 결정은 9:59:59.000,9:59:59.000 일찍 해야겠지요. 9:59:59.000,9:59:59.000 그렇지요? 뭔가 작성을 해야합니다. 9:59:59.000,9:59:59.000 데이터베이스가 있어야 한다는 것은 아마도 일찍 결정해야 할 겁니다. 9:59:59.000,9:59:59.000 웹 어플리케이션이어야 한다는 것도 일찍 결정해야 할 겁니다. 9:59:59.000,9:59:59.000 어떤 프레임워크를 사용할지 결정하는 것? 아닙니다. 9:59:59.000,9:59:59.000 가족 동반 휴가에 비유했었지요? 9:59:59.000,9:59:59.000 휴가로 어디를 갈지는 일찍 결정해야겠지요. 어떤 차 모델을 선택할지도 미리 결정해야 할까요? 9:59:59.000,9:59:59.000 6개월 전에 여행을 계획할 때에 미리 신차를 뽑아야 할까요? 9:59:59.000,9:59:59.000 여행 전에 차가 고장이 날지도 모릅니다. 9:59:59.000,9:59:59.000 차는 단순히 이동 수단입니다. 짐을 싣고 가족이 탈 수 있으면 충분한 거지요. 9:59:59.000,9:59:59.000 여행을 갈 수 있으면 되는 겁니다. 9:59:59.000,9:59:59.000 데이터베이스 시스템은 차와 같습니다. 여행의 초반에 미리 결정할 필요가 없는 거지요. 9:59:59.000,9:59:59.000 가장 최후까지 지연시킬 수 있습니다. 9:59:59.000,9:59:59.000 여행가기 전 날에 신차를 살 수도 있는 거지요. 9:59:59.000,9:59:59.000 왜요? 9:59:59.000,9:59:59.000 복권에 당첨될지도 모르지요. 9:59:59.000,9:59:59.000 어쩌면 아기가 태어나서 공간이 더 필요할지도 모릅니다. 9:59:59.000,9:59:59.000 여행가기 직전까지 여러 일들이 발생할 수 있습니다. 9:59:59.000,9:59:59.000 다른 질문 있나요? 9:59:59.000,9:59:59.000 네 저기 뒤에요. 9:59:59.000,9:59:59.000 (누군가 질문 중) 9:59:59.000,9:59:59.000 레거시 시스템은 어떻게 하냐구요?[br](역주: 에자일 세계에서 레거시 시스템은 단위 테스트가 없는 시스템을 의미함) 9:59:59.000,9:59:59.000 남은 시간으로 설명하긴 힘들겠군요. 9:59:59.000,9:59:59.000 그래서 한 단어로 답변하고. 그에 대해 설명하겠습니다. 9:59:59.000,9:59:59.000 점진적인 접근입니다. 9:59:59.000,9:59:59.000 사람들은 레거시 시스템을 없애 버리고 새로 개발하고 싶어합니다. 9:59:59.000,9:59:59.000 그렇게 하지 마세요. 9:59:59.000,9:59:59.000 보통 실패하게됩니다. 많은 시간과 돈을 낭비하고 말입니다. 9:59:59.000,9:59:59.000 시스템의 작은 부분을 선택한 후에 9:59:59.000,9:59:59.000 그 부분만 다시 작성하고 9:59:59.000,9:59:59.000 동작하게 만드세요. 9:59:59.000,9:59:59.000 결국 군데 군데 수정이 되겠지요. 하지만 수정된 부분은 원래 코드보다 개선됩니다. 9:59:59.000,9:59:59.000 그렇게 계속 반복합니다. 9:59:59.000,9:59:59.000 오랜 시간 동안 많은 노력을 기울여 점진적으로 개선이 될 것 입니다. 9:59:59.000,9:59:59.000 신규 기능을 추가할 때에도 같은 방법으로 합니다. 9:59:59.000,9:59:59.000 사실 단지 코드를 점진적으로 청소하는 작업입니다. 9:59:59.000,9:59:59.000 크게 변경하는 것은 하지 마세요. 위험합니다. 9:59:59.000,9:59:59.000 감사합니다. 다음에 봅시다. 9:59:59.000,9:59:59.000