뒤에 잘 들리나요?

저 뒤에도 잘 들리나요? 오케이 좋습니다.

Um what is an electron?

So part of atom, everybody knows that, I think

It's um.. (Screams from other room) yeah I think so, . I think that's royal ???

Um electron is part of atom

it's carries a unit of electronic charge, negative charge, as oppose to a proton which carries a positive charge

It apparently has ??? not very much, thousands of electron... very very small amount of mass

And we think of it as a particle, although that misleading um.. electron actually behaves much more like a wave than like a particle

why do we think of it as particle?

and the reason we do that is that when electron interacts a location like a particle would

when electron is moving through the space it does not moves the way a particle would

moves as a wave and the wave has no location

you look at an ocean wave, and ocean wave can be huge

it has no distinct location it has well defined energy but no distinct location

this is how an electron moves

electrons obey a principle and it's a mistruster principle

It's called the poly exclusion principle

two electrons bound into the same system will not be in the same state

for whatever reason they cannot be in the same state

so if there are two electrons in an atom

those two electrons must be different somehow

now they might different in the direction of their spin

an electron can spin to the left or spin to the right

two electrons that have exactly same energy could fit together spinning one left and one right

물론 오늘의 발표 주제는 이게 아니지요.

오늘 이야기할 주제는 "아키텍처, 잃어 버린 시간" 입니다.

이 것은 클린 코드와 클린 디자인의 다음 단계에 대한 이야기입니다.

클린 시스템 스트럭쳐에 대한 이야기 입니다.

이 그림은 내가 10년 전에 작성했던 어플리케이션의 디렉터리 구조입니다.

당시에 Rails를 배우고 있었지요.
여기 Ruby 프로그래머가 있나요? Ruby on Rails 프로그래머?

저쪽에 손 흔드는 사람이 한 명 있네요. 오케이.

당시에 Rails를 배우면서 이 어플리케이션을 작성했는데 책의 내용을 따라 했습니다.

책에서 이야기하는데로 그대로 작성했더니 이런 형태의 결과가 나왔습니다.

만족스럽게 마무리했고 그뒤로 오랫동안 안 봤습니다.

그리고 한 3년 전에 내 아들한테 어플리케이션을 하나 작성해달라고 했습니다.

그런데 작성된 어플리케이션을 보니 디렉터리 구조가 똑 같았어요.

이 둘은 전혀 다른 어플리케이션이고 아무런 연관도 없습니다.

그런데 디렉터리 구조는 똑 같아요. 이걸 보면서 왜 두 어플리케이션의 최상위 구조가 똑 같은지에 대해서 고민했습니다.

이 둘은 전혀 다른 어플리케이션이거든요.

두 어플리케이션의 디렉터리 구조가 동일한 이유는 둘다 Rails 어플리케이션이기 때문이었습니다.

그러자 이게 왜 중요한지가 궁금해졌습니다.

Rails 같은 프레임워크가 얼마나 중요하길래 어플리케이션의 최상위 디렉터로 구조를 결정지어버리는 걸 까요?

내가 생각한 이유는 바로 다음과 같습니다.

웹은 전달을 위한 장치입니다. 웹은 I/O 채널이에요.

웹 자체는 아키텍처적으로 중요하지 않습니다.

흔히 웹 어플리케이션을 작성한다고 생각하는데 그렇지 않습니다. 우리는 컨텐츠를 전달하는 어플리케이션을 작성하고 있는 것 입니다.

그러면 왜 I/O 채널이 그렇게 중요할까요?

혹시 웹이 번성하기 시작한 시기를 기억하나요? 1980년대? 1990년대?

얼마나 큰 변화였는지 기억하나요? 얼마나 모든 것이 근본적으로 변했는지 기억하나요?

그렇게 큰 변화는 없었습니다. 왜냐하면 실제로 그다지 새로운 것이 아니었기 때문이지요.

우리는 단지 입력 소스로 부터 입력을 받고, 처리하고, 출력 소스로 내보내기만 했습니다.

웹은 그냥 그런거에요.

그런데 왜 왭이 모든 것들을 결정해버릴까요?

그래서 나는 건축에 대해서 생각해봤습니다. 건축 도면을 봤어요.

저 건축 도면을 보세요. 첫 눈에 도서관 도면이라고 생각이 안들어도 깨닫는데까지 얼마 걸리지 않을 겁니다.

도서관이라는게 너무 명백하거든요.

책장들이 많이 있고 책상도 많습니다.

책상위엥 컴퓨터도 보이고요 책을 대출하고 반납하는 곳도 보여요.

저 도면을 보고 도서관이라는 것을 알아채는데에 오랜 시간이 걸리지 않을 겁니다.

다른 것도 봐볼까요? 저건 교회에요. 누가 봐도 교회지요.

어쩌면 극장이라고 생각할 수 도 있겠지요. 극장이랑 교회는 공통 부분이 있으니까요.

하지만 이건 분명히 교회입니다. 제단, 바깥의 교실,

분명히 교회지요.

이 건물의 아키텍처는 어떻게 지어지는지 이야기하지 않습니다.

이 건물의 아키텍처는 그 의도 이야기하고 있지요. 아키텍처라는 것은 의도에 대한 것 입니다.

하지만 저 Rails 어플리케이션들의 최상위 구조는 그 의도에 대해서 이야기하지 않고 있지요.

저 어플레케이션들은 스스로 Rails 어플리케이션이라는 것을 이야기하고 있습니다. 무언가 잘못되었어요.

그리고 이런 생각이 들었습니다.

이건 이미 알려진 문제인가? 이미 해결되었던 문제인가? 이 문제는 1992년에 Iva jacobson이 저술한 책에서 거론되고 해결되었었습니다.

이 책을 가진 사람이 있나요? 읽어 본 사람? 여기 한 사람있네요 또 없나요?

Object-Oriented Software Engineering. 아주 훌륭한 책이에요.

1992년에 출반된 책이지만 상관없어요. 책에 담긴 원칙들은 여전히 유효합니다.

부제를 보세요. 부제는 'A Usecase driven approach' 입니다.

유즈케이스 기억하는 사람 있나요? 1990년대에는 아주 아주 유명했었습니다.

실제론 너무 유명해서 수많은 컨설턴트들에 의해 본래의 의미가 변질되었었지요.

수많은 컨설턴트들이 자신의 유즈케이스 양식을 인터넷에 앞다퉈서 내놓았었지요.

그러더니 양식 자체가 매우 중요하게 여겨져 버렸어요. 우리는 그 표준 양식의 빈칸을 채우도록 강요받았지요.

유즈케이스의 이름, 입력값, 사전조건, 사후조건, 주액터, 부액터 등을 채워야했습니다.

우리는 모든 빈칸을 채워야만했고 결국 유즈케이스의 가장 중요한 점은 그 기능이 아니라 양식이 되버렸습니다.

그 시기의 절정 즈음에 에자일 운동이 시작되었습니다. 우리는 유즈케이스에 대한 이야기는 멈추고 유저 스토리에 대해 이야기했습니다. 유즈케이스에 대해서는 아무도 이야기하지 않게되었지요.

그래서 나는 이 책을 다시 읽어봤어요.

Jacobson이 쓴것들을 다시 기억해냈습니다.

여기 유즈케이스가 있습니다. 전형적인 Jacobson 스타일의 유즈케이스에요.

매우 작은 양식이에요. '주문 생성'이라는 이름이 있네요. 주문 처리 시스템의 유즈케이스라고 생각해보세요.

입력 값으로 고객 아이디, 고객 연락처, 수신처 등이 보이네요.

여기에는 세부적인 내용은 없어요. 고객 아이디가 어떤 것인지 기술하지 않습니다.

숫자이건 문자열이건 상관없어요.

고객 연락처가 어떤 것인지 기술하지 않습니다. 아마도 이름 날자 주소등등 이겠지요.

하지만 세부사항들연 여기에 명시되어있지 않습니다.

여기 메인 흐름이 있네요. 메인 흐름은 유즈케이스를 만족시키기 위해 컴퓨터가 실행하는 단계들이에요.

첫 번째로 주문 담당자는 '주문 생성'을 요청합니다.

그리고 시스템이 데이터를 검증합니다. 어떻게 검증한다는 이야기는 안했지요? 어떻게든 검증을 하는지는 중요하지 않습니다. 그냥 검증을 한다는게 중요합니다.

세번째로 시스템이 주문을 생성하고 ID를 결정합니다. 아마도 어떤 데이터베이스 작업이겠지만 이야기는 안하겠습니다.

그리고 시스템은 담당자에게 ID를 전달합니다. 아마도 웹 페이지를 통해서겠지만 이야기는 안하겠습니다.

실제로 이 유즈케이스는 웹에 대해 아무런 이야기도 하지 않습니다. 이 유즈케이스는 어떤 I/O 채널을 통해서도 구현이 가능하겠지요.

이 유즈케이스는 콘솔 앱, 데스크탑 앱, SOA 앱, 아이폰 앱에서도 구현이 가능합니다.

유즈케이스는 I/O 채널을 모르기 때문에 가능한 것 입니다.

Jacobson은 유즈케이스를 오브젝트로 바꿀 수 있다고 했습니다.

Jacobson은 저것을 Control Object라고 불렀지만 MVC의 Controller와 헷갈릴 수 있으므로 Interactors라고 이름을 바꿨습니다.

어쩌면 유즈케이스라는 이름이 더 좋겠지만 그렇게 하지는 않았습니다. Interactors로 부르겠습니다.

Interactor 오브젝트는 유즈케이스를 구현합니다. 유즈케이스의 입력값을 입력 받아서 유즈케이스의 출력값을 출력합니다.

그리고 유즈케이스의 처리 흐름을 구현합니다.

밑에 설명을 보면 어플리케이션 별 비지니스 규칙들을 가진다고 되어있지요?

거기에는 두 종류의 비지니스 규칙이 있습니다.

먼저 글로벌할 비지니스 규칙이 있습니다. 모든 어플리케이션에 적용이 가능하지요.

그리고 개발중인 어플리케이션에만 해당하는 비지니스 규칙들이 있습니다.

예를 들어서 주문 입력 어플리케이션과 주문 처리 어플리케이션이 있다고 생각해봅시다.

둘 다 '주문'이라는 오브젝트가 있을겁니다. 그리고 그 주문 오브젝트들은 같은 비지니스 규칙을 가지고 있겠지요.

하지만 둘 중 하나의 어플리케이션만 주문 추가라는 유즈케이스를 가지고 있을 겁니다.

유즈케이스는 어플리케이션에 따라 다릅니다. 유즈케이스는 특정 어플리케이션에 종속되지요.

비지니스 규칙은 어플리케이션에 따라 다르지 않습니다. Entity 오브젝트에 종속됩니다. 비지니스 오브젝트라고 불려지기도 합니다.

나는 비지니스 오브젝트라는 말은 좋아하지는 않습니다. Jacobson 도 Entiry 오브젝트라고 불렀지요.

어플리케이션 비종속적인 비지니스 규칙들을 Entity 오브젝트에 넣고 Interactor가 Entity 오브젝트들을 관장합니다.

그런 후에 유즈케이스의 입력값과 출력값을 다른 유즈케이스에 전달하는 방법을 정합니다.

이 경우에는 인터페이스를 사용합니다. 그림에 객체지향 방식의 인터페이스로 표현을 했는데요. Interactor는 인터페이스 하나를 사용하고 있고요 다른 하나의 인터페이스는 구현을 하고 있습니다.

Interactor가 구현하고 있는 것은 입력 인터페이스이고요 Interactor가 사용하고 있는 것은 출력 인퍼테이스입니다.

두 인터페이스와 Interactor 사이의 화살표가 같은 방향이지요? 이 것이 중요한 것 입니다!!!!!

이게 왜 중요한지는 조금 뒤에 이야기하겠습니다.