Return to Video

Robert C. Martin - Clean Architecture and Design

  • 0:00 - 4:44
  • 4:46 - 4:50
    뒤에 잘 들리나요?
  • 4:51 - 4:56
    저 뒤에도 잘 들리나요? 오케이 좋습니다.
  • 4:56 - 5:01
    Um what is an electron?
  • 5:04 - 5:08
    So part of atom, everybody knows that, I think
  • 5:08 - 5:18
    It's um.. (Screams from other room) yeah I think so, . I think that's royal ???
  • 5:20 - 5:22
    Um electron is part of atom
  • 5:23 - 5:32
    it's carries a unit of electronic charge, negative charge, as oppose to a proton which carries a positive charge
  • 5:32 - 5:42
    It apparently has ??? not very much, thousands of electron... very very small amount of mass
  • 5:43 - 5:55
    And we think of it as a particle, although that misleading um.. electron actually behaves much more like a wave than like a particle
  • 5:55 - 5:59
    why do we think of it as particle?
  • 5:59 - 6:09
    and the reason we do that is that when electron interacts a location like a particle would
  • 6:09 - 6:16
    when electron is moving through the space it does not moves the way a particle would
  • 6:16 - 6:21
    moves as a wave and the wave has no location
  • 6:21 - 6:27
    you look at an ocean wave, and ocean wave can be huge
  • 6:27 - 6:34
    it has no distinct location it has well defined energy but no distinct location
  • 6:34 - 6:36
    this is how an electron moves
  • 6:36 - 6:42
    electrons obey a principle and it's a mistruster principle
  • 6:42 - 6:46
    It's called the poly exclusion principle
  • 6:46 - 6:53
    two electrons bound into the same system will not be in the same state
  • 6:53 - 6:57
    for whatever reason they cannot be in the same state
  • 6:57 - 7:01
    so if there are two electrons in an atom
  • 7:01 - 7:04
    those two electrons must be different somehow
  • 7:04 - 7:08
    now they might different in the direction of their spin
  • 7:08 - 7:11
    an electron can spin to the left or spin to the right
  • 7:11 - 7:18
    two electrons that have exactly same energy could fit together spinning one left and one right
  • 7:18 - 7:21
    there's no way to get a third one in there
  • 7:21 - 7:28
    so the next electron must have higher energy and then you can have two more
  • 7:28 - 7:31
    one spinning left one spinning right
  • 7:31 - 7:35
    but if you wanted to add another that would have to be something different about them
  • 7:35 - 7:38
    and you could arrange them differently in space
  • 7:38 - 7:49
    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.
  • 7:50 - 7:58
    most of our atoms that we know of have this need to have 8 electrons in their shells
  • 7:58 - 8:08
    The reason for that is just this nice little geometry. the sphere and then three rows and each one of those can contain two
  • 8:08 - 8:13
    have you ever thought about water?
  • 8:13 - 8:17
    I got some here. Fascinating substance
  • 8:17 - 8:20
    what's it made of?
  • 8:20 - 8:25
    two hydrogen atoms one oxygen atom
    that's what makes a water molecule
  • 8:25 - 8:28
    and what's it shaped like?
  • 8:28 - 8:33
    Mickey mouse! yes, there is big oxygen in the middle and two little hydrogens forming the ears
  • 8:33 - 8:42
    The angle there is the result of (??) the shell arrangement.
  • 8:42 - 8:47
    What makes the hydrogen and oxygen stick together?
  • 8:47 - 8:51
    think of two atoms, two atoms covered by electrons, two electrons are parallel each other
  • 8:51 - 8:56
    what would make two hydrogens and an oxygen stick together?
  • 8:56 - 9:03
    And it turns out that if you take these two hydrogens and big oxygen you lay them next to each other
  • 9:03 - 9:12
    and you think of the electrons as waves, not particles, then where those waves like to be?
  • 9:12 - 9:20
    and those waves would like to be mostly between protons. Protons in hydrogen atom and protons in oxygen atom
  • 9:20 - 9:25
    So they will congregate those electron waves will congregate more
  • 9:25 - 9:31
    between two atoms, between three atoms actually, then everywhere else
  • 9:31 - 9:35
    they still go everywhere else that just that more likely to be between them
  • 9:35 - 9:48
    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
  • 9:48 - 9:54
    now if you take this Mickey mouse atom and you divide it in half
  • 9:54 - 9:58
    you find there's more negative charge above the one and below the one
  • 9:58 - 10:02
    cause all that negative charge likes to sit there between the two hydrogen atoms and oxygen atoms
  • 10:02 - 10:08
    So there's more negative charge on one side than the other which means that water molecule is a dipole
  • 10:08 - 10:11
    it is negative one side and positive on the other
  • 10:11 - 10:13
    this is why water is wet.
  • 10:13 - 10:20
    Water sticks to your hand because all the water molecules rotate to stick to the electrically charged surface of your skin
  • 10:20 - 10:23
    even though it is not very electrically charged
  • 10:23 - 10:34
    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
  • 10:34 - 10:37
    this is why water makes it a good cleanser
  • 10:37 - 10:43
    and this is why water will do one of the most wonderful things you can do with water
    who's done this experiment?
  • 10:43 - 10:52
    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
  • 10:52 - 11:02
    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
  • 11:02 - 11:06
    as all the water molecules turn around get it tracked the electric charge
  • 11:06 - 11:10
    물론 오늘의 발표 주제는 이게 아니지요.
  • 11:11 - 11:20
    오늘 이야기할 주제는 "아키텍처, 잃어 버린 시간" 입니다.
  • 11:20 - 11:28
    이 것은 클린 코드와 클린 디자인의 다음 단계에 대한 이야기입니다.
  • 11:29 - 11:34
    클린 시스템 스트럭쳐에 대한 이야기 입니다.
  • 11:34 - 11:38
  • 11:38 - 11:47
    이 그림은 내가 10년 전에 작성했던 어플리케이션의 디렉터리 구조입니다.
  • 11:47 - 11:53
    당시에 Rails를 배우고 있었지요. 여기 Ruby 프로그래머가 있나요? Ruby on Rails 프로그래머?
  • 11:53 - 11:57
    저쪽에 손 흔드는 사람이 한 명 있네요. 오케이.
  • 11:57 - 12:04
    당시에 Rails를 배우면서 이 어플리케이션을 작성했는데 책의 내용을 따라 했습니다.
  • 12:04 - 12:10
  • 12:10 - 12:14
    책에서 이야기하는데로 그대로 작성했더니 이런 형태의 결과가 나왔습니다.
  • 12:14 - 12:20
    만족스럽게 마무리했고 그뒤로 오랫동안 보지 않았지요.
  • 12:20 - 12:27
    그리고 한 3년 전에 내 아들한테 어플리케이션을 하나 작성해달라고 했습니다.
  • 12:27 - 12:32
    그런데 작성된 어플리케이션을 보니 디렉터리 구조가 똑 같았어요.
  • 12:32 - 12:36
  • 12:36 - 12:41
    이 둘은 전혀 다른 어플리케이션이고 아무런 연관도 없습니다.
  • 12:41 - 12:45
    그런데 디렉터리 구조는 똑 같아요. 이걸 보면서 왜 두 어플리케이션의 최상위 구조가 똑 같은지에 대해서 고민했습니다.
  • 12:45 - 12:53
  • 12:53 - 12:57
    이 둘은 전혀 다른 어플리케이션이거든요.
  • 12:57 - 13:03
    두 어플리케이션의 디렉터리 구조가 동일한 이유는 둘다 Rails 어플리케이션이기 때문이었습니다.
  • 13:03 - 13:09
    그러자 이게 왜 중요한지가 궁금해졌습니다.
  • 13:09 - 13:21
    Rails 같은 프레임워크가 얼마나 중요하길래 어플리케이션의 최상위 디렉터로 구조를 결정지어버리는 걸 까요?
  • 13:21 - 13:25
    내가 생각한 이유는 바로 다음과 같습니다.
  • 13:26 - 13:34
    웹은 전달을 위한 장치입니다. 웹은 I/O 채널이에요.
  • 13:34 - 13:38
    웹 자체는 아키텍처적으로 중요하지 않습니다.
  • 13:38 - 13:42
    흔히 웹 어플리케이션을 작성한다고 생각하는데 그렇지 않습니다.
  • 13:42 - 13:45
  • 13:45 - 13:52
    우리는 컨텐츠를 전달하는 어플리케이션을 작성하고 있는 것 입니다.
  • 13:52 - 13:58
    그러면 왜 I/O 채널이 그렇게 중요할까요?
  • 14:00 - 14:07
    혹시 웹이 번성하기 시작한 시기를 기억하나요? 1980년대? 1990년대?
  • 14:07 - 14:14
    얼마나 큰 변화였는지 기억하나요? 얼마나 모든 것이 근본적으로 변했는지 기억하나요?
  • 14:14 - 14:20
    그렇게 큰 변화는 없었습니다. 왜냐하면 실제로 그다지 새로운 것이 아니었기 때문이지요.
  • 14:20 - 14:27
    우리는 단지 입력 소스로 부터 입력을 받고, 처리하고, 출력 소스로 내보내기만 했습니다.
  • 14:27 - 14:28
    웹은 그냥 그런거에요.
  • 14:28 - 14:31
    그런데 왜 왭이 모든 것들을 결정해버릴까요?
  • 14:31 - 14:39
    그래서 나는 건축에 대해서 생각해봤습니다. 건축 도면을 봤어요.
  • 14:41 - 14:50
    저 건축 도면을 보세요. 저 위에 도서관이라는 글씨가 없더라도 깨닫는데 얼마 걸리지 않을 겁니다.
  • 14:50 - 14:52
    도서관이라는게 너무 명백하거든요.
  • 14:52 - 14:56
    책장들이 많이 있고 책상도 많습니다.
  • 14:56 - 15:06
    책상위에 컴퓨터도 보이고요 책을 대출하고 반납하는 곳도 보여요.
  • 15:06 - 15:11
    저 도면을 보고 도서관이라는 것을 알아채는데에 오랜 시간이 걸리지 않을 겁니다.
  • 15:11 - 15:16
    다른 것도 봐볼까요? 저건 교회에요. 누가 봐도 교회지요.
  • 15:16 - 15:21
    어쩌면 극장이라고 생각할 수 도 있겠지요. 극장이랑 교회는 공통 부분이 있으니까요.
  • 15:21 - 15:30
    하지만 이건 분명히 교회입니다. 제단, 바깥의 교실,
  • 15:30 - 15:32
    분명히 교회지요.
  • 15:32 - 15:42
    이 건물의 아키텍처는 어떻게 지어지는지 이야기하지 않습니다.
  • 15:42 - 15:49
    이 건물의 아키텍처는 그 의도 이야기하고 있지요. 아키텍처라는 것은 의도에 대한 것 입니다.
  • 15:49 - 15:56
    하지만 저 Rails 어플리케이션들의 최상위 구조는 그 의도에 대해서 이야기하지 않고 있지요.
  • 15:56 - 16:03
    저 어플레케이션들은 스스로 Rails 어플리케이션이라는 것을 이야기하고 있습니다. 무언가 잘못되었어요.
  • 16:03 - 16:06
    그리고 이런 생각이 들었습니다.
  • 16:06 - 16:15
    이건 이미 알려진 문제인가? 이미 해결되었던 문제인가? 이 문제는 1992년에 Iva jacobson이 저술한 책에서 거론되고 해결되었었습니다.
  • 16:15 - 16:21
    이 책을 가진 사람이 있나요? 읽어 본 사람? 여기 한 사람있네요 또 없나요?
  • 16:21 - 16:23
    Object-Oriented Software Engineering. 아주 훌륭한 책이에요.
  • 16:24 - 16:30
    1992년에 출반된 책이지만 상관없어요. 책에 담긴 원칙들은 여전히 유효합니다.
  • 16:30 - 16:37
    부제를 보세요. 부제는 'A Usecase driven approach' 입니다.
  • 16:37 - 16:45
    유즈케이스 기억하는 사람 있나요? 1990년대에는 아주 아주 유명했었습니다.
  • 16:45 - 16:54
    실제론 너무 유명해서 수많은 컨설턴트들에 의해 본래의 의미가 변질되었었지요.
  • 16:54 - 17:06
    수많은 컨설턴트들이 자신의 유즈케이스 양식을 인터넷에 앞다퉈서 내놓았었지요.
  • 17:06 - 17:16
    그러더니 양식 자체가 매우 중요하게 여겨져 버렸어요. 우리는 그 표준 양식의 빈칸을 채우도록 강요받았지요.
  • 17:16 - 17:23
    유즈케이스의 이름, 입력값, 사전조건, 사후조건, 주액터, 부액터 등을 채워야했습니다.
  • 17:23 - 17:30
  • 17:30 - 17:38
    우리는 모든 빈칸을 채워야만했고 결국 유즈케이스의 가장 중요한 점은 그 기능이 아니라 양식이 되버렸습니다.
  • 17:38 - 17:44
    그 시기의 절정 즈음에 에자일 운동이 시작되었습니다.
  • 17:44 - 17:52
    우리는 유즈케이스에 대한 이야기는 멈추고 유저 스토리에 대해 이야기했습니다. 유즈케이스에 대해서는 아무도 이야기하지 않게되었지요.
  • 17:52 - 17:58
    그래서 나는 이 책을 다시 읽어봤어요.
  • 17:58 - 18:02
    Jacobson이 쓴것들을 다시 기억해냈습니다.
  • 18:02 - 18:11
    여기 유즈케이스가 있습니다. 전형적인 Jacobson 스타일의 유즈케이스에요.
  • 18:11 - 18:16
    매우 작은 양식이에요.
  • 18:16 - 18:25
    '주문 생성'이라는 이름이 있네요. 주문 처리 시스템의 유즈케이스라고 생각해보세요.
  • 18:25 - 18:32
    입력 값으로 고객 아이디, 고객 연락처, 수신처 등이 보이네요.
  • 18:32 - 18:38
    여기에는 세부적인 내용은 없어요. 고객 아이디가 어떤 것인지 기술하지 않습니다.
  • 18:38 - 18:40
    숫자이건 문자열이건 상관없어요.
  • 18:40 - 18:48
    고객 연락처가 어떤 것인지 기술하지 않습니다. 아마도 이름 날자 주소등등 이겠지요.
  • 18:48 - 18:52
    하지만 세부사항들연 여기에 명시되어있지 않습니다.
  • 18:52 - 18:55
    여기 메인 흐름이 있네요.
  • 18:55 - 19:05
    메인 흐름은 유즈케이스를 만족시키기 위해 컴퓨터가 실행하는 단계들이에요.
  • 19:05 - 19:11
    첫 번째로 주문 담당자는 '주문 생성'을 요청합니다.
  • 19:11 - 19:19
    그리고 시스템이 데이터를 검증합니다. 어떻게 검증한다는 이야기는 안했지요? 어떻게든 검증을 하는지는 중요하지 않습니다. 그냥 검증을 한다는게 중요합니다.
  • 19:19 - 19:24
    세번째로 시스템이 주문을 생성하고 ID를 결정합니다.
  • 19:24 - 19:29
    아마도 어떤 데이터베이스 작업이겠지만 이야기는 안하겠습니다.
  • 19:29 - 19:35
    그리고 시스템은 담당자에게 ID를 전달합니다. 아마도 웹 페이지를 통해서겠지만 이야기는 안하겠습니다.
  • 19:35 - 19:40
    실제로 이 유즈케이스는 웹에 대해 아무런 이야기도 하지 않습니다.
  • 19:40 - 19:44
    이 유즈케이스는 어떤 I/O 채널을 통해서도 구현이 가능하겠지요.
  • 19:44 - 19:54
    이 유즈케이스는 콘솔 앱, 데스크탑 앱, SOA 앱, 아이폰 앱에서도 구현이 가능합니다.
  • 19:54 - 20:00
    유즈케이스는 I/O 채널을 모르기 때문에 가능한 것 입니다.
  • 20:00 - 20:10
    Jacobson은 유즈케이스를 오브젝트로 바꿀 수 있다고 했습니다.
  • 20:10 - 20:20
    Jacobson은 저것을 Control Object라고 불렀지만 MVC의 Controller와 헷갈릴 수 있으므로 Interactors라고 이름을 바꿨습니다.
  • 20:20 - 20:26
    어쩌면 유즈케이스라는 이름이 더 좋겠지만 그렇게 하지는 않았습니다. Interactors로 부르겠습니다.
  • 20:26 - 20:38
    Interactor 오브젝트는 유즈케이스를 구현합니다. 유즈케이스의 입력값을 입력 받아서 유즈케이스의 출력값을 출력합니다.
  • 20:38 - 20:46
    그리고 유즈케이스의 처리 흐름을 구현합니다.
  • 20:46 - 20:54
    밑에 설명을 보면 어플리케이션 별 비지니스 규칙들을 가진다고 되어있지요?
  • 20:54 - 20:57
    거기에는 두 종류의 비지니스 규칙이 있습니다.
  • 20:57 - 21:06
    먼저 글로벌할 비지니스 규칙이 있습니다. 모든 어플리케이션에 적용이 가능하지요.
  • 21:06 - 21:12
    그리고 개발중인 어플리케이션에만 해당하는 비지니스 규칙들이 있습니다.
  • 21:12 - 21:22
    예를 들어서 주문 입력 어플리케이션과 주문 처리 어플리케이션이 있다고 생각해봅시다.
  • 21:22 - 21:30
    둘 다 '주문'이라는 오브젝트가 있을겁니다. 그리고 그 주문 오브젝트들은 같은 비지니스 규칙을 가지고 있겠지요.
  • 21:30 - 21:41
    하지만 둘 중 하나의 어플리케이션만 주문 추가라는 유즈케이스를 가지고 있을 겁니다.
  • 21:41 - 21:48
    유즈케이스는 어플리케이션에 따라 다릅니다. 유즈케이스는 특정 어플리케이션에 종속되지요.
  • 21:48 - 21:57
    비지니스 규칙은 어플리케이션에 따라 다르지 않습니다. Entity 오브젝트에 종속됩니다. 비지니스 오브젝트라고 불려지기도 합니다.
  • 21:57 - 22:01
    나는 비지니스 오브젝트라는 말은 좋아하지는 않습니다. Jacobson 도 Entiry 오브젝트라고 불렀지요.
  • 22:01 - 22:11
    어플리케이션 비종속적인 비지니스 규칙들을 Entity 오브젝트에 넣고 Interactor가 Entity 오브젝트들을 관장합니다.
  • 22:11 - 22:17
    그런 후에 유즈케이스의 입력값과 출력값을 다른 유즈케이스에 전달하는 방법을 정합니다.
  • 22:17 - 22:24
    이 경우에는 인터페이스를 사용합니다. 그림에 객체지향 방식의 인터페이스로 표현을 했는데요.
  • 22:24 - 22:31
    Interactor는 인터페이스 하나를 사용하고 있고요 다른 하나의 인터페이스는 구현을 하고 있습니다.
  • 22:31 - 22:38
    Interactor가 구현하고 있는 것은 입력 인터페이스이고요 Interactor가 사용하고 있는 것은 출력 인퍼테이스입니다.
  • 22:38 - 22:42
    두 인터페이스와 Interactor 사이의 화살표가 같은 방향이지요? 이 것이 중요한 것 입니다!!!!!
  • 22:42 - 22:45
    이게 왜 중요한지는 조금 뒤에 이야기하겠습니다.
  • 22:45 - 22:53
    Jacobson은 이 세가지 오브젝트들을 자신의 아키텍처로 이야기했습니다.
  • 22:53 - 22:58
    자 그럼 이것들이 어떻게 작용하는지 봅시다.
  • 22:58 - 23:03
    일반적인 어플리케이션이 있습니다. 저기 있는 작은 사람이 유저입니다.
  • 23:03 - 23:11
    실제 사람이고요 이 사람이 전달 매커니즘을 통해서 시스템과 상호작용합니다.
  • 23:11 - 23:14
    전달 매커니즘은 웹일 수도 아닐수도 있겠지요. 아무런 상관 없습니다.
  • 23:14 - 23:26
    저 유저는 버튼이나 키보드를 사용해서 시스템이 데이터를 받아들이도록 합니다.
  • 23:26 - 23:32
    웹이건 다른 것이건 어떤 전달 메커니즘을 통하는지는 중요하지 않습니다.
  • 23:32 - 23:37
    시스템에 전달된 데이터는 Request Model이라는 것으로 변형됩니다.
  • 23:37 - 23:40
    Request Model은 순수한 데이터 구조입니다.
  • 23:40 - 23:51
    POJO나 POCO와 같은 순수 데이터 구조 입니다. 데이터가 어디에서 왔는지 모르고 웹과 아무런 연관도 없습니다.
  • 23:51 - 23:53
  • 23:53 - 23:57
    메소드도 없는 단순한 데이터 구조입니다.
  • 23:57 - 24:02
    Public 데이터만 있는 구조로서 모든 입력값을 저장하게됩니다.
  • 24:02 - 24:12
    Request Model은 Interactor가 구현한 입력 인터페이스로 전달됩니다.
  • 24:12 - 24:21
    Interactor는 Reqeust Model을 받은 후에 데이터를 읽어 해석하고
  • 24:21 - 24:27
    작은 여러 커맨드들로 변환하여 Entity들에 보냅니다.
  • 24:27 - 24:33
    모든 비지니스 오브젝트들은 Entity로 호출되는 메소드들을 컨트롤합니다.
  • 24:33 - 24:42
    작업이 끝난 후에는 반대 방향으로 흘러갑니다. Interactor는 Entity들을 조회하여 변경사항을 확인합니다.
  • 24:42 - 24:48
    그 결과로 Result Model이라는 데이터 구조를 만들게됩니다.
  • 24:48 - 25:01
    Result Model은 또 다른 순수한 데이터 구조입니다. 단순한 POJO나 POCO이지요.
  • 25:01 - 25:12
    Result Model은 출력 인터페이스를 통해서 전달 매커니즘으로 전해집니다. 어떤 방법이 사용되건 출력 인터페이스를 통해서 유저에게 전달이 됩니다.
  • 25:12 - 25:18
    저건 다른 모든 어플리케이션들의 흐름이지요.
  • 25:18 - 25:24
    그럼 Interactor를 테스트할 수 있을까요?
  • 25:24 - 25:25
    매우 쉽겠지요?
  • 25:25 - 25:31
    입력 데이터 자료를 생성해서 Interactor를 호출하고 출력 데이터를 보면됩니다.
  • 25:31 - 25:33
    이걸 위해 웹 서버가 필요할까요?
  • 25:33 - 25:41
    아닙니다. Interactor는 단순히 POJO나 POCO만을 사용하기 때문이지요.
  • 25:41 - 25:45
    이걸 위해 데이터베이스가 필요할까요? 어쩌면 필요할 수도 있겠지요 하지만 이 문제는 조금 있다가 이야기하겠습니다.
  • 25:45 - 25:51
    전달 메커니즘이 없어도 테스트가 가능합니다.
  • 25:51 - 25:56
    전달 매커니즘이 웹 인가요? 상관 없습니다. Interactor를 테스트하는데에 웹 서버는 실행할 필요가 없어요.
  • 25:56 - 25:58
    테스트에는 웹 페이지도 역시 필요 없습니다.
  • 25:58 - 26:07
    시스템을 테스트 하는데에 처음 입력단 부터 마지막 출력단까지 확인안해도 테스트가 가능합니다.
  • 26:12 - 26:14
    MVC는 어떨까요?
  • 26:14 - 26:19
    MVC는 우리 모두가 해야만 하는 것 아닐까요?
  • 26:20 - 26:29
    MVC는 무엇의 약자이지요? Model View Controller 입니다. 그럼 누가 발명했나요?
  • 26:29 - 26:35
    저 사람입니다. 이제 나는 저사람의 이름을 잘못 발음할 겁니다. 당신들이 나모다 더 제대로 발음하겠지요.
  • 26:35 - 26:42
    어쨌든 이야기하자면 트릭뷔 륀스카욱. 당신들이 나보다 더 정확히 발음하겠지요.
    (역주: 트릭뷔 륀스카욱은 청중들과 마찬가지로 노르웨이 사람임.)
  • 26:42 - 26:47
    나는 저 사람을 만나봤습니다. 저 사람이 1970년대에 MVC를 발명한 사람입니다.
  • 26:47 - 26:50
    나흔 저 사람을 한 번 만났는데요, 2년전 여기 이 컨퍼런스에서 였습니다.
  • 26:50 - 26:57
    나는 강연자 라운지에서 전원 콘센트를 찾고 있었습니다. 그때 저 나이든 분이 내게와서 콘센트를 건네 줬습니다.
  • 26:57 - 27:01
    고개를 올려 보니 "트릭뷔 린스카욱!"
  • 27:01 - 27:08
    멀티냅을 주고 받는 사이에 서로 손가락이 스쳤어요!
  • 27:08 - 27:13
    나는 한동안 손을 안씼었답니다. 트뤽뷔 린스카욱.
  • 27:13 - 27:19
    몇 몇 사람이 나한테 와서 사진을 같이 찍었는데요, 나도 역시 비슷한 부류입니다.
  • 27:21 - 27:27
    70년대 말에서 80년대 초에 트뤽비 린스카욱은 Model View Controller라고 부르는 이 구조를 제시했습니다.
  • 27:27 - 27:30
    그는 스몰토크 플랫폼에서 이걸 만들었지요.
  • 27:30 - 27:33
    기본 개념은 매우 간단합니다.
  • 27:33 - 27:37
    비지니스 규칙을 담고있는 모델 오브젝트는 자신이 어떻게 유저에게 보여질지 전혀 모릅니다.
  • 27:37 - 27:41
  • 27:41 - 27:48
    단지 순수한 비지니스 규칙입니다. 저기 아래에 있는 컨트롤러는 입력값들을 처리합니다.
  • 27:48 - 28:00
    컨트롤러는 입력 기기들을 쳐다 봅니다. 어떤 입력 기기인지는 중요하지 않습니다. 사용자의 행동들을 Model에 대한 커맨드들로 만듭니다.
  • 28:00 - 28:01
    그리고 View가 있지요.
  • 28:01 - 28:07
    View에는 쌍선으로 그려진 화살표가 있는데요. 옵저버 관계를 의미합니다.
  • 28:07 - 28:15
    View는 Model에 등록을 해놓습니다. 그리고 Model이 변경될 때 마다 View가 화면을 업데이트하도록 불리워집니다.
  • 28:15 - 28:25
    View는 Model의 컨텐츠를 표시하거나 전달하는 역할을 담당합니다.
  • 28:25 - 28:35
    이는 GUI에 아주 효율적입니다. 그리고 콘솔, SOA 등등에도 효율적으로 적용이 가능합니다.
  • 28:35 - 28:41
    입력을 컨트롤하는 것이 있고 (Controller)
    프로세스를 컨트롤하는 것이 있고 (Model)
    출력을 컨트롤하는 것이 있습니다. (View)
  • 28:41 - 28:51
    아마도 이름을 지어진 디자인 패턴인 MVC는 아주 작은 것에 사용하기 위한 것 이었습니다.
  • 28:51 - 29:02
    MVC는 버튼에 쓰일 수 있지요. MVC는 체크박스에도 쓰일 수 있습니다. 그리고 MVC는 텍스트 필드에도 쓰일 수 있습니다.
  • 29:02 - 29:05
    스크린에는 MVC가 쓰이지 않습니다.
  • 29:07 - 29:15
    아주 옛날부터 MVC는 비틀어지고 변형되어 왔습니다. 소프트웨어 분야에서 흔히 일어나는 일이지요.
  • 29:15 - 29:24
    어떤게 정말 좋은 것이라고 이야기되면 다른 모든 사람들이 모방을 합니다. 그리곤 완전히 다른 것에 같은 이름을 붙이고는 좋은 것이라고 주장합니다.
  • 29:24 - 29:29
    객체지향도 같은 현상이 생겼고, 구조, 오브젝트 에자일 등도 마찬가지였습니다.
  • 29:29 - 29:38
    어떤 이름이 무언가 좋은 것을 가리키고 있다면 다른 사람들이 그 이름을 자신의 것에 붙이고 자신의 것도 좋은 것이라고 합니다.
  • 29:38 - 29:44
    그건 MVC에도 발생했습니다. 요즘 MVC 프레임워크들이 많이 있지요.
  • 29:44 - 29:50
    그 MVC 프레임워크들은 원래 MVC와는 전혀 다릅니다. 트릭뷔 린스카욱의 MVC의 개념과 다릅니다.
  • 29:50 - 29:54
    아주 많이 달라요. 실제론 이렇게 생겼지요.
  • 29:55 - 30:07
    저기 많은 컨트롤러들이 있지요. 웹 환경에서는 저 컨트롤러들은 웹에 의해 작동됩니다.
  • 30:07 - 30:13
    저 구름 너머에 있는 웹 프레임워크지요. Rails 일지 Spring일지 어떤 것이든지 상관없어요.
  • 30:13 - 30:22
    어째됬건 그 복잡하고 끔찍한 URL을 전달해서 컨트롤러에 전달합니다.
  • 30:22 - 30:27
    웹으로 부터 받은 변수와 데이터를 컨트롤러에게 전달합니다.
  • 30:27 - 30:34
    그러면 컨트롤러들은 비지니스 오브젝트들에게 와서 어떤 일을 하라고 소리를 칩니다.
  • 30:34 - 30:46
    그리고 비지니스 오브젝트로 부터 데이터를 모아서 뷰에게 이야기합니다. 그러면 뷰들은 다시 비지니스 오브젝트들에게서 데이터들을 조회하고 화면에 표시합니다.
  • 30:46 - 30:55
    그러면 결국에는 비지니스 오브젝트들은 컨트롤러나 뷰가 가질법한 펑션들로 채워지며 결국 오염되게 됩니다.
  • 30:55 - 31:05
    펑션의 적절한 위치를 찾기가 힘들어져서 비지니스 오브젝트에 놓이면 안되는 펑션들을 비지니스 오브젝트에 구현하기도 합니다.
  • 31:09 - 31:14
    그럼 출력 쪽은 어떻게 처리할까요?
  • 31:16 - 31:20
    여기 Interactor는 일을 끝냈습니다.
  • 31:20 - 31:32
    유즈케이스를 끝내면서 데이터를 조회했지요. 생성된 Response Model을 출력 인터페이스를 통해서 막 전달하려는 시점입니다.
  • 31:32 - 31:38
    저 출력 인터페이스는 어떤 것이 구현할까요? Presenter라 불리우는 것 입니다.
  • 31:38 - 31:45
    Presenter의 역할은 순수 데이터 구조인 Response Model을 받아서
  • 31:45 - 31:52
    View Model이라는 또다른 데이터 구조로 변형시킵니다.
  • 31:52 - 32:04
    View Model은 출력의 모델입니다. 출력 값을 표현하는 것이고 여전히 순수한 데이터 구조입니다.
  • 32:04 - 32:11
    하지만 화면에 표가 있다면 View Model에도 표가 있을 겁니다.
  • 32:11 - 32:17
    화면에 텍스트 필드가 있다면 View Model에도 텍스트 필드가 있을겁니다.
  • 32:17 - 32:28
    화면의 숫자를 소수점 이하 두 자리수 까지만 표현하겠다면 ViewModel은 TrimToTwoDecimalPlaces와 ConvertIntToString라는 메소드를 가지게됩니다.
  • 32:28 - 32:38
    음수인 경우 괄호로 표현하게 되었다면 Presenter가 괄호를 붙여서 View Model에 저장을 하게됩니다.
  • 32:38 - 32:43
    메뉴 아이템들이 있다면 그 이름들도 View Model에 저장이 됩니다.
  • 32:43 - 32:53
    비활성화된 메뉴 아이템들은 회색으로 처리되어야 한다면 View Model에는 불린 값으로 저장이 됩니다.
  • 32:53 - 33:05
    화면에 표시되는 모든 것들은 View Model에 저장이 됩니다. 여전히 추상화된 방식으로요.
  • 33:05 - 33:08
    그리고는 View에 입력이 됩니다.
  • 33:08 - 33:16
    View는 멍청해요. View는 저것들과 아무런 관련이 없고요 단순히 View Model로 부터 데이터를 가져갑니다.
  • 33:16 - 33:21
    아무 것도 처리하지 않습니다. If 구문도 없고요 아마 테이블을 표시하기 위한 루프문 정도는 있겠지요. 이정도가 다 입니다.
  • 33:21 - 33:30
    View는 아주 멍청해서 신경쓸 이유가 없습니다. 일반적으로 테스트도 잘 안하지요. 어찌되었건 우리 눈으로 보게되니까요.
  • 33:30 - 33:33
    Presenter를 테스트 할 수 있을까요?
  • 33:33 - 33:38
    할 수 있지요. Request Model을 건넨 후에 View Model 데이터를 기다리면 됩니다.
  • 33:38 - 33:44
    Presenter를 테스트 할 때에 웹 서버가 실행되어야 할까요?
  • 33:44 - 33:49
    아니지요. 웹 서버가 없어도 모두 테스트할 수 있습니다.
  • 33:49 - 33:53
    스프링 같은 컨테이너들을 실행할 필요도 없지요.
  • 33:53 - 33:56
    그런 것 들을 실행하는 방법을 몰라도 됩니다.
  • 33:56 - 34:00
    그냥 평범한 데이터 구조체를 테스트하는 것 처럼 할 수가 있습니다.
  • 34:00 - 34:07
    그나저나 이게 목표입니다. 다른 아무것도 실행시키지 않고 가능한 많은 테스트를 하는 것 입니다.
  • 34:07 - 34:13
    30초에서 1분 정도나 걸려서 이 서저 저 서버를 시작시키지 않아도 됩니다.
  • 34:13 - 34:21
    다른 건 필요 없이 테스트만 실행할 수 있으면 됩니다. 저중 아무 것도 필요 없이 가능한 빠르게 착착착 끝내면 됩니다.
  • 34:23 - 34:26
    저게 합쳐 놓은 그림입니다.
  • 34:26 - 34:32
    Interactor는 입력 인터페이스를 통해 들어온 Request Model에서 데이터를 가져옵니다.
  • 34:32 - 34:38
    그리고 Response Model에 데이터를 담은 후에 출력 인터페이스를 통해 Presenter에게 전달합니다.
  • 34:38 - 34:49
    저기 검정색 선을 보세요. 저 선이 어플리케이션과 전달 매커니즘을 구분하는 선입니다.
  • 34:49 - 34:55
    그리고 검정선을 지나는 모든 화살표가 어플리케이션을 향하는 것을 보세요.
  • 34:55 - 35:00
    어플리케이션은 Controller나 Presenter에 대해 아무것도 모릅니다.
  • 35:00 - 35:05
    웹이나 I/O 채널에 대해 아무 것도 모릅니다.
  • 35:05 - 35:11
    I/O 채널은 어플리케이션에 대해 알고 있지만 어플리케이션은 I/O 채널에 대해 모르고 있습니다.
  • 35:11 - 35:21
    만약에 저 둘을 서로 다른 Jar 파일에 담는다면 어플리케이션 Jar 파일은 웹 Jar 파일을 전혀 의존하지 않게됩니다.
  • 35:21 - 35:30
    저 둘을 다른 Jar 파일에 담게되겠지요. 하나는 웹에 대한 Jar 파일이고 하나는 어플리케이션이 담긴 Jar 파일입니다.
  • 35:30 - 35:34
    그리고 어쩌면 또다른 I/O 매커니즘에 대한 Jar 파일을 만들 수도 있겠지요.
  • 35:34 - 35:39
    그리고 I/O 매커니즘을 변경하려면 그냥 Jar 파일만 바꿔치면 됩니다.
  • 35:39 - 35:50
    웹이라는 I/O 매커니즘을 플러그인이라고 생각하세요. 여기 .Net Sharp 사용자가 있나요?
  • 35:50 - 35:55
    여기 모두 .Net 개발자 아닌가요?
  • 35:55 - 36:04
    어떤 IDE를 사용하지요? IDE용 플러그인을 사용하나요?
  • 36:06 - 36:15
    IDE 개발자와 플러그인 개발자 중에 누가 상대방에 대해 알까요?
  • 36:17 - 36:26
    플러그인 개발자가 IDE 개발자를 알지요. IDE 개발자는 플러그인 개발자에 대해서 아무것도 모릅니다.
  • 36:26 - 36:28
    상관 안하지요.
  • 36:28 - 36:36
    둘 중에 누가 상대방에 피해를 줄 수 있을까요? 플러그인 개발자들이 비주얼 스튜디오를 해칠 수 있을까요?
  • Not Synced
    여기 Resharper 쓰는 사람? Resharper 제작자들이 비주얼 스튜디오를 해칠 수 있을까요?
  • Not Synced
    - (청중) 예!
    - (로버트 마틴) 아마 실행 중에 죽일 수는 있겠지요.
  • Not Synced
    하지만 그렇다고 비주얼 스튜디오 개발자들이 대응을 해야 할까요?
  • Not Synced
    MS의 개발자들이 JetBrains에게 신경 쓸까요?
  • Not Synced
    아니지요! 그들은 JetBrains는 신경쓰지 않습니다.
  • Not Synced
    그럼 MS의 개발자들이 JetBrains의 개발자들이 자신들을 따라오게 할 수 있을까요?
  • Not Synced
    그렇지요!
  • Not Synced
    그럼 여러분 어플리케이션에 대해 생각해봅시다.
  • Not Synced
    어플리케이션의 어떤 파트가 어플리케이션의 다른 파트로 부터 보호되어야 할까요?
  • Not Synced
    어떤 파트가 어플리케이션의 다른 파트의 변경에 따라 수정되어야 할까요? 어떤 파트가 다른 파트의 변경에도 영향을 받지 않아야 할까요?
  • Not Synced
    답은 아주 간단합니다.
  • Not Synced
    비지니스 규칙을 웹으로 부터 보호해야합니다.
  • Not Synced
    웹을 비지니스 규칙으로 부터 보호하면 안됩니다.
  • Not Synced
    웹에 어떠한 변경이 생겼더라도 비지니스 규칙에는 영향이 없어야 합니다. 아키텍처적으로 보장되어야 합니다.
  • Not Synced
    저기 모든 화살표는 어플리케이션을 향하고 있습니다. 명심하세요. 저게 플러그인 아키텍처입니다.
  • Not Synced
    이제 데이터 베이스에 대해 이야기해봅시다.
  • Not Synced
  • Not Synced
    저 그림 속의 데이터베이스가 당신이 생각하는 것과 비슷한가요?
  • Not Synced
    데이터베이스가 세상의 중심이고 어플리케이션은 변방에 위치한 아랫것들 인가요?
  • Not Synced
    여기 DBA 있나요?
  • Not Synced
    아! 없군요 좋습니다.
  • Not Synced
    (??) 혹시 이런 DBA와 일 해본 경험 있나요? 어플리케이션은 구석으로 치워버리고, 스키마를 정해버리고, 데이터베이스만 우선시하는?
  • Not Synced
    이게 여러분이 생각하는 데이터베이스인가요?
  • Not Synced
    내 이야기의 요점은 이 것입니다.
  • Not Synced
    데이터베이스는 디테일이에요.
  • Not Synced
    아키텍처적으로 큰 의미가 없습니다.
  • Not Synced
    데이터베이스는 그냥 저장소일 뿐입니다.
  • Not Synced
    시스템에서 아키텍처적으로 중요한 것이 아닙니다.
  • Not Synced
    비지니스 규칙과도 아무런 연관이 없지요.
  • Not Synced
    설마 Stored Procedure로 비지니스 규칙을 구현했나요?
  • Not Synced
    Stored Procedure에는 비지니스 규칙 대신 쿼리, 검증, 무결성 검증 등이 들어가야합니다.
  • Not Synced
    그럼 왜 데이터베이스를 사용할까요?
  • Not Synced
    왜 데이터베이스는 생겨났을까요? 오라클은 왜 존재할까요?
  • Not Synced
    데이터베이스가 생기기 전에는 데이터를 어디에 저장했었을까요?
  • Not Synced
    회전하는 디스크에 저장했었습니다. 여기 디스크 드라이버 개발해본 사람 있나요?
  • Not Synced
    회전하는 디스크에 데이터를 입출력하는 프로그램을 개발해본 사람 있나요?
  • Not Synced
    없나요?
  • Not Synced
    디스켓? 그것도 마찬가지지요.
  • Not Synced
    데이터를 디스크에 저장하고 읽는 것은 매우 어렵습니다. 왜지요?
  • Not Synced
    디스크에 데이터가 저장되는 방식 때문입니다.
  • Not Synced
    데이터는 디스크의 원형 트랙에 저장됩니다.
  • Not Synced
    플래터 표면에 원형의 트랙이 있습니다. 플래터는 여러 개가 있을 수 있지요.
  • Not Synced
    헤드가 트랙을 찾기위해 전/후로 움직입니다. 그러므로 원하는 트랙으로 해드를 움직여야 하지요.
  • Not Synced
    그리고 디스크가 회전하면서 데이터를 읽게됩니다.
  • Not Synced
    그 다음에 원하는 섹터를 찾아야 합니다. 트랙에는 50~60개의 섹터가 있고요 각각의 섹터는 4k 바이트의 데이터를 가지고 있습니다.
  • Not Synced
    그러므로 디스크가 회전해서 원하는 섹터가 올때까지 기다렸다가 데이터를 읽어야 합니다.
  • Not Synced
    그런 후에 섹터에 저장된 데이터에서 원하는 바이트를 찾아야합니다.
  • Not Synced
    어렵습니다. 그리고 느려요.
  • Not Synced
    제대로 작성하지 않으면 아주 아주 오래걸릴 수도 있습니다.
  • Not Synced
    그래서 사람들은 이 문제를 전담할 시스템을 만들었습니다. 데이터베이스 말입니다.
  • Not Synced
    그런데 변화가 생겼습니다.
  • Not Synced
    여기 내 노트북 보이나요? 내 노트북은 500MB짜리 SSD가 있습니다. 디스크는 없어요. 놀랍지는 않지요?
  • Not Synced
    여기 디스크를 가진 사람 있나요?
  • Not Synced
    여기 회전하는 디스크를 가진 사람?
  • Not Synced
    오! 진짜로요?
  • Not Synced
    요즘 HDD를 사고싶은 사람은 없어요. SSD가 대세입니다.
  • Not Synced
    어쩌면 서버룸에는 HDD가 있을지도 모릅니다. 하지만 거기도 조만간 없어질 겁니다.
  • Not Synced
    앞으로 몇 년 후에는 HDD는 사라질 겁니다. 모든 것이 RAM으로 교체되겠지요.
  • Not Synced
    RAM 말입니다.
  • Not Synced
    RAM은 원하는 바이트를 직접 읽을 수 있습니다.
  • Not Synced
    우리가 궁극적으로 추구하는 저장 매체는 무한한 용량의 비휘발성 RAM입니다.
  • Not Synced
    우리가 궁극적으로 데이터를 저장할 매체이지요.
  • Not Synced
    그렇게 직접 액세스할 수 있는 저장 매체가 있다면 왜 SQL을 써야만 할까요?
  • Not Synced
    SQL은 어렵습니다. Table도 어렵습니다.
  • Not Synced
    해시 테이블에서 데이터를 찾기보다 포인터로 바로 액세스하는 것이 좋겠지요?
  • Not Synced
    지금도 그렇게 하고 있지 않나요? 테이블에 저장된 데이터를 읽어서 좀 더 사용하기 좋은 구조에 저장합니다.
  • Not Synced
    그냥 우리가 사용하는 포멧 그대로 저장하면 어떨까요?
  • Not Synced
    내가 오라클이라면 아주 겁이 날 겁니다.
  • Not Synced
    내 존재의 이유가 서서히 사라지고 있거든요.
  • Not Synced
    대규모 데이터베이스 시스템이란 개념은 점차 사라지고 있습니다.
  • Not Synced
    그럼 어플리케이션을 이런 사소한 것으로 어떻게 보호할까요?
  • Not Synced
    이런 사소한 데이터베이스는 모든 것을 결정해버리곤 하지요. 어쨌건 웹을 격리한 방법으로 어플리케이션을 데이터베이스로 부터 보호할 수 있습니다.
  • Not Synced
    자 여기 또 하나 굵은 선을 그립니다.
  • Not Synced
    자세히 보세요, 이 선을 지나는 모든 선은 어플리케이션을 향하고 있습니다.
  • Not Synced
    데이터베이스는 어플리케이션의 플러그인이 되었지요?
  • Not Synced
    이제오라클을 MySQL로 바꿀 수 있습니다.
  • Not Synced
    아니면 MySQL을 버리고 CouchDB로 바꿀 수도 있지요.
  • Not Synced
    아니면 CouchDB를 버리고 Datomic이나 다른 걸로 바꿀 수 있습니다.
  • Not Synced
    데이터베이스를 플러그인으로 교체할 수 있습니다.
  • Not Synced
    데이터베이스를 실제로 바꾸지 않을지도 몰라요. 하지만 그럴 수 있다는 것은 좋은 겁니다. 실제로 필요하지 않다고 해도 말입니다.
  • Not Synced
Title:
Robert C. Martin - Clean Architecture and Design
Description:

more » « less
Video Language:
English
Duration:
01:05:41

Korean subtitles

Revisions Compare revisions