IT로 세상을 이롭게

IT시스템의 구현은 현실세계와 밀접한 관련이 있다고 생각합니다.

짧지않은 기간동안 공부하고 경험한바를 바탕으로 마구 써내려가봅니다.

=========================================================================================

1. 조물주가 이 땅에 특별한 목적을 가지고 생명체를 창조해내었다면, 

프로그래머 역시 어떠한 목적이 있기 때문에 한 객체를 시스템내에서 창조한다.

창조된 생명체는 자신의 역할을 다할 책임이 있다.

2. 어떠한 생명체도 혼자서 모든 것을 수행하지는 못한다.

자신이 할 수 있는 것은 자신이 하고, 그 역할을 벗어나는 것은 전달하여 요청한다.

그리고 의사소통이 가능한 존재들끼리만 요청을 주고 결과를 받을 수 있다.

3. 자연세계에서 한 객체가 다른객체에게 간접적으로 영향을 받을지언정, 직접적으로 영향을 받는 경우는 거의 없다.

소프트웨어에서 역시 가장 이상적인 객체라 함은, 다른 객체에 의해서 영향을 받는 것이 최소화되며 자신의 창조목적을 다하는 것이 기본으로 본다. 가끔 특수한 경우가 있을 수는 있지만 빈번하게 발생한다면 이는 자연스럽지 못하다.

4. 생태계에서 어떤 객체가 자신의 life cycle을 최대화 시키기 위해서는 변화에 잘 적응해야만 한다.

변하는 부분과 변하지 않는 부분을 구분하고, 변하는 부분에 있어서는 최대한의 유연성을 발휘한다.

그러나 변하지 않는 부분에 대해서는 견고함을 최우선으로 삼는다.

최초에 설계된 유연성을 넘어서는 경우에는 변화를 수용하지 못하고 파괴의 순간을 맞이하는 것이 공통적인 부분이다. 이 세상에 영원한 것은 없다.

5. System을 우리는 계 라고 표현한다.

하나의 계는 여러가지 공통의 속성을 공유한다. 우리의 환경을 예로 들자면 비슷한 온도, 습도, 토양, 공기, 일조 를 공유하는 곳이다. 계 안에서는 여러 생물이 각자 평안함을 유지하면서 살게된다.

그러나 그 안의 공유하는 균형이 깨지는 순간 심각한 이상현상을 초래한다.

거꾸로 계 내에서 살던 생명체가 다른 계 로 이동하는 순간 동일한 행위를 보장하지는 못한다.

소프트웨어에서는 이러한 경계안 쪽을 시스템 안정성,표준선을 보장하는 최소의 단위로 본다.(boundary)

계는 계의 집합으로 구성된다. 각 생명체는 하나의 계를 유지하며, 여러 생명체가 모여서 생태계를 구성하며, 다양한 생태계가 모여서 지구를 구성하고 있다.

6. 어떠한 객체이던지 점진적으로 발전한다.

태어날때부터 모든 기능이 완벽한 생물은 없다. 성장하면서 주위의 변화를 습득하면서 점차 부분부분의 기능을 강화해나간다. 때로는 필요에 따라서 기능을 퇴화시키기도 하고, 특정기능을 발전시키기도 한다.

중요한 것은 이러한 점진적 발전을 위해서는 기능의 규모에는 관계없이 반드시 최소Set은 가지고 있어야 한다는 점이다. 기본적으로 머리,몸통,팔,다리는 있어야지, 팔만 있어서는 발전의 가능성조차 없다.

7. 연관성이 없는 객체는 없는 존재의 의미가 없으며, 비슷한 연관성을 가진 객체는 서로 라이벌이다.

직접적이던 간접적이던 객체들은 서로 연관성을 가지고 있다.

다른 객체와 연관성이 전혀 없이 홀로 있는 객체라면 그것은 이미 객체가 아니다. 사라진다.

이와는 반대로 서로 비슷한 연관성을 가진 객체가 있다면 이 객체들은 서로 라이벌이다.

어느 한순간이 되면 하나의 객체만 남게될 것이다.

=========================================================================================

이렇게 정리하다보면 각 객체를 특별하게 구분할 수 있는 요소는 결국 관계성으로 보입니다.

객체가 가지고 있는 하나하나의 기능에 집중해서 보다보면 큰 그림을 놓치게 되고요,

객체들이 살고있는 환경만 바라보게 되면 작은 그림을 놓치게 됩니다.

그래서 저는 시스템을 구축하거나 분석/설계 해야하는 업무를 수행할 때 아래와 같은 순서로 접근합니다.

1. 이 시스템의 목적은 무엇인가? 어디까지가 시스템의 범위인가?

2. 그 목적을 이루기 위해서 구성되고 있는, 또는 구성되어야 하는 컴포넌트는 무엇인가? 최소필요기능은 무엇인가?

3. 컴포넌트들이 보인다면 서로 관계는 어떻게 맺어야 하는가? 

4. 유사한 관계 혹은 충돌되는 관계는 없는가?

5. 컴포넌트안에는 구체적으로 어떤 객체들이 만들어져야 하는가? 얼마나 많이 만들어져야 하는가?

6. 이제는 보다 상세하게 각 객체들의 책임을 상세하게 정의해보자.

영화Matrix를 보면 아키텍트가 곧 창조주이죠.

이러한 모든 요소를 고려하여 각 객체들이 오래~ 행복하게~ 살수 있는 하나의 계를 구축해주는 것이 목표아니겠습니까. 만들어는졌으나 아무것도 하는일이 없는 객체, 혼자서 모든 일을 도맡아 하는 객체는 얼마나 힘들까요.

신처럼 처음부터 끝까지를 모두 완벽히 해낼 수 있다면 가장 이상적이겠지만 현실은 불가능입니다..

Spark관련 논문 Resilient Distributed Datasets 을 읽던 중 coarse-grained 와 fine-grained 의 내용이 있어서 간단히 정리를 해본다.

영어를 사용하는 문화권에서는 확실히 이해가 쉬울 듯 한데..

grain은 곡식을 하나하나의 낱알로 만드는 작업을 의미한다. 이 작업을 듬성듬성 크게 할지, 아니면 곱고 가늘게 할지에 따라서 coares와 fine으로 표현한다.

이를 소프트웨어 공학에서는 하나의 프로세스를 쪼개는 정도에 따라서 구분하는 정도로 사용한다.

1. Fine-Grained

잘게 쪼개는 것으로 예를 들면 다음과 같다.

타행이체의 경우 당행잔액조회 => 타행입금계좌 확인 => 타행으로송금 단계로 나눌 수 있고 이를 각각 메소드로 구성할 수 있다. 또한 이 기능들이 다양하게 활용된다면 메소드를 모아서 하나의 모듈로 만들 수 도 있어서 변경이 발생했을 때 보다 유연하게 개발할 수 있는 장점이 있다. 또한 유사하지만 다른 새로운 비지니스가 만들어 질 때 재사용을 통해서 보다 빠르게 구현할 수 있다.즉, Flexible System상에서 유용하다.

2. Coarse-Grained

덩어리로 작업한다.

타행이체의 경우 그냥 "타행이체" 하나 만들어서 사용한다. 일반적으로 EnterpriseApplicationDesign에서는 선호하지 않는 방식이지만 Distributed System상에서 유용하다.

그동안은 Java기반의 EnterpiseApplication을 주로 수행했기 때문에 1번이 많이 친숙하지만, 앞으로는 BigData를 위한 병렬처리쪽으로 구현이 필요한 경우(Spark,Akka등..) 가 생길 것 같아서 2번으로의 전환이 필요할 것 같다.

정리 및 첨언

최근 프로그래밍의 추세도 함수형 프로그래밍이라고 하는데 객체지향과 상반된다고 오해하는 경우가 있다. 

함수형 프로그래밍 = 순차적 프로그래밍 으로 보는 것은 옳지 않다.

내 생각에는 함수형 프로그래밍이라는 것은 수학적함수와 비슷한 개념으로 closure전달이 가능하다는 개념으로 보는 것이 더 낫지 않나 싶다. 대표적인 예를 scala로 볼 수 있다.

RDD논문을 보면 transformation에 대한 설명들이 나오는데 수학개념을 통해서 표현하면 매우 쉽게 이해할 수 있다. (ex, Map(a) => b ) 

Spark구현을 Scala로 한 것은 그 때문이 아닐까 혼자 생각해본다.

짧지 않은 IT생활을 하면서 얻었던 소중한 경험중에 하나는 Rebecca Wirfs-Brock에게 6개월간 강의를 들었던 것이다. 온/오프라인에 걸쳐서 업무와 병행하여 수강하는 것이(그것도 영어로 ㅜㅜ) 쉽지는 않았지만... 그 뒤로 Application Design을 보는 눈이 달라졌다고 생각한다.

하나를 만들더라도 재사용이 가능하게, 쉽게 확장이 가능하게

이를 위해서 배웠던, 어쩌면 이미 모두가 알고 있는 Designing Object-Oriented Software 에 대해서 차근차근 정리해보려고 한다.  (벌써 2년이나 지나서 가물가물 @.@)