'프로그래밍' 카테고리의 글 목록 (7 Page)

Implementation (impl) 을 만들때 @Override 를 붙여야하는 이유 (0)	2016.09.23
Forward와 Include의 차이점 (0)	2016.09.23
Spring - Ioc & DI (0)	2016.09.23
StringUtils (0)	2016.09.23
Java Collection Framework (JCF) (0)	2016.09.23

Posted by 당구치는 개발자

프로그래밍/It 용어 2016. 8. 1. 14:31

스테레오타입(Stereotype) 개념

UML을 처음 접하면서 가장 명쾌하게 이해되지 않는 개념 중 하나가 바로 스테레오타입(stereotype)일 것이다. 사전을 찾아보면 "연판, 관례, 고정 관념, 상투적인 문구, ..." 등의 의미로 나오지만 이미 의미를 알고 있다면 그런 용어가 알쏭 달쏭할 수는 있지만 그것으로부터 의미를 이해하기에는 불가능해 보인다. UML 명세에 나와있는 설명은 더 어렵다. 모델링 타임에 정의된 새로운 메타클래스(metaclass)라는 등, 사용상의 구별(usage distinction)이라는 등 역시 이미 UML 하부구조를 알고 있어야 하는 설명들이다.

스테레오타입은 그 정의로써 이해하기에는 다소 마음에 와 닿지 않을 것이므로 먼저 예를 들어보자. 윈도우 기반의 UI를 가지고 있으면서 DB를 다루는 간단한 프로그램을 모델링 한다고 가정하자. 이 때 주로 UML의 클래스(Class)를 사용해서 모델링을 하게 될 것이다. 속성(Attribute)과 연산(Operation)도 넣고 서로 간의 연관(Association) 및 일반화(Generalization)도 사용해서 말이다. 이렇게 모델링을 하고 나면 새로운 욕구가 발생하게 될 것이다. GUI를 구성하는 부분과 DB를 구성하는 테이블, 그리고 기타 프로그램 내부의 순수 로직 부분 모두 다 그냥 단지 클래스(Class)로만 표현되고 있을 뿐이다. 이것들을 그저 GUI, Business Logic, Database로 구분해두고 싶어질 것이다. 이런데 이러 경우는 비단 이러한 예 뿐만 아니라 너무도 많이 발생한다. 즉, 각각의 요소들을 모델러(modeler)의 기준에서 별도의 분류를 두고 싶을 때 스테레오타입(stereotype)을 사용하게 된다.

스테레오타입이 왜 필요한가?

UML은 매우 범용적이고 일반적인 모델링 언어이다. 따라서, 어떠한 개념이라도 무리 없이 모델링이 가능하지만 반면에 어떠한 개념도 정확하고 명확하게 나타내기는 힘들다. 우리 인간이 사용하는 자연어(한국어, 영어, 일본어)등도 결국 일상 용어 외에 특정 학문 분야에서 사용될 때에는 부족함이 많기 때문에 새로운 용어가 탄생하고 기존의 단어에 새로운 의미가 부여되게 되는 것이다. 일상 용어의 "Thread"와 컴퓨팅 분야의 "Thread"는 단어는 같으나 이해되는 의미는 다르다. UML도 마찬가지로 그러한 태생적인 한계가 있으며 이를 극복하기 위한 방안이 모색되었는데 그것이 바로 UML의 확장 메커니즘(extension mechanism)인 것이다.

스테레오타입의 사용

스테레오타입(stereotype)은 바로 UML 확장 메커니즘의 한 부분으로써 매우 중요한 역할을 수행하게 된다. 다시 한번 정리하면 "스테레오타입은 UML 모델링 요소들을 모델러의 기준에 따라 새로운 분류를 적용할 수 있도록 허용하는 메커니즘"이다. 따라서, 스테레오타입은 모델러 마음대로 정의해서 적용하면 되는 것이고 특별한 제약이나 규칙은 없다. 그리고 스테레오타입은 각 요소에 "<<" ">>" 사이에 이름을 부여하면 된다. 정확하게는 "<<", ">>"는 꺽쇠 괄호(angle-braket) 두개가 아니라 guillemets라 불리는 하나의 문자('«', '»')이다. 그러나, 통상적으로 이러한 문자를 사용하기가 불편하기 때문에 꺽쇠 괄호 두 개를 써도 무방하다.

스테레오타입은 위의 예에서 처럼 <<GUI>>, <<table>>과 같이 사용해도 되고, 특정한 플랫폼이나 프로그래밍 언어를 나타내기 위해 <<JavaClass>>, <<CORBAInterface>> 처럼 사용해도 된다. 아니면 특정 분야에서 사용되는 용어나 개념으로 표현하는 것도 좋은 예가 될 수 있다. 그러나 가급적 특정 기준을 두고 분류의 용도로 사용하는 것이 바람직하며 무조건적으로 부가적인 데이터들만 기입하는 방식은 좋은 사용의 예가 아닐 것이다. 예를 들어 클래스를 작성한 사람의 이름 <<minho>>, <<younghee>> 혹은 구현될 파일의 이름 <<DBAccess.java>>과 같이 사용하는 것은 그다지 좋은 방법은 아닐 것이다.

스테레오타입과 아이콘(Icon)

스테레오타입은 하나의 아이콘으로 표현될 수도 있다. 예를 들어 <<JavaBean>> 클래스를 콩 모양의 아이콘으로 나타내준다면 훨씬 보기에도 좋고 구별하기도 쉬울 것이다. UML은 이러한 확장이 가능하도록 허용하고 있다. 그리고 현대의 여러 툴들에서는 이를 지원하고 있기도 하다. <<table>>은 표 모양의 아이콘을, <<Database>>는 원통 모양의 아이콘을 사용할 수도 있는 것이다.

이렇게 아이콘을 사용할 수 있게 되다 보니 스테레오타입을 표현하는 방식에 몇 가지 선택사항이 생기게 되었다. 간단하게 생각해보더라도 <<JavaBean>>과 같이 텍스트 형식으로 나타내느냐 아니면 아이콘 형식으로 나타내느냐 혹은 둘 다를 나타내느냐 하는 선택을 할 수 있다. UML에서는 총 4가지의 옵션이 존재한다.

None : 스테레오타입을 나타내기 않음
Textual : 스테레오타입을 <<JavaBean>>과 같이 텍스트로 나타냄
Iconic : 콩 그림의 아이콘과 같이 아이콘으로 나타냄
Decoration : <<JavaBean>>과 콩 그림의 아이콘을 동시에 나타냄.

출처 : http://onjava.co.kr/75

'프로그래밍 > It 용어' 카테고리의 다른 글

도메인등록에 대한 모든 것, 도메인과 네임서버란 무엇일까? (0)	2016.09.23
도메인이란? (Domain) (0)	2016.09.23
트랜잭션 (0)	2016.07.11
Spring (스프링) (0)	2016.07.11
스택(Stack) (0)	2016.07.08

Posted by 당구치는 개발자

프로그래밍/It 용어 2016. 7. 11. 14:31

트랜잭션이란?

출처 : http://springmvc.egloos.com/495798

은행이나 금융권 개발 쪽 말을 들어보면 트랜잭션이란 말이 많이 나온다. 또 MySQL 이용자들이 InnoDB를 사용하는 가장 큰 이유도 트랜잭션을 지원하기 때문이라고도 한다. 굉장히 좋다는 건 뭔지 알겠는데 이름만 들어서는 도통 감이 안온다. 어느 정도냐면 필자가 트랜잭션이란 말을 처음 접했을 때는 트랜지스터처럼 뭔가를 쪼끄맣게 만드는 것이나 DB에서 상거래를 이용할 수 있게 하는 기술인 줄 알았다. 게다가 트랜잭션이란 코드에서 처리하는게 아니라 MySQL쿼리문만 처리가능한 기술이라고 말도 안되는 오해를 할 때도 있었다. 물론 모두 틀렸다. 트랜잭션에 대한 개념을 간략하게 설명하자면 다음과 같다.

트랜잭션은 현대의 웹 보안에 있어서 매우 중요한 역할을 차지하며 DB와 JAVA 언어가 데이터를 주고 받는 과정에 원자성을 부여하는 수단을 일컫는다.

트랜잭션에 대해 잘 모르는 독자들은 이 말만 들어서는 트랜잭션이 뭔지 감이 안올 수도 있을 것이다. 필자도 트랜잭션이 뭔지 알고 나서야 이 말의 감을 잡았지 결코 위의 글을 읽고 "트랜잭션이란 정말 좋은 기술이구나. 나도 해봐야겠다!"라고 생각하진 않았으니 말이다.

과거에 트랜잭션이란 소수의 웹개발자들만이 공유하는 기술로 인식되곤 했다. 굉장히 고급기술이고 손이 많이 가는 작업인지라 트랜잭션이 일반화되지 않았을 때는 트랜잭션과 비슷한 기술인 프로시져를 더 선호할 때도 있었다. 물론 아직도 트랜잭션보다 프로시져를 선호하는 사람들이 존재한다. 하지만 이런 발달된 프레임워크 덕분에 트랜잭션을 이용하는 방법이 쉬워졌고 트랜잭션의 장점 또한 더욱 부각되면서 자바진영에서만큼은 프로시져보다 트랜잭션을 선호하는 추세이다.

그렇다면 트랜잭션과 프로시져란 무엇일까? 우리가 데이터베이스와 힘겹게 씨름하며 개발을 해가다보면 어느 순간 도저히 쿼리 한줄로는 끝낼 수 없는 상황에 부닥치게 되는데 이런 단일 쿼리로 해결할 수 없는 로직을 처리할 때 필요한 기술이 바로 트랜잭션이다. 먼저 트랜잭션을 설명하는데 있어서 가장 훌륭한 예제인 전자상거래를 살펴보도록 하자.

위의 예제는 우리가 한줄로 처리할 수 없는 쿼리의 가장 좋은 예이다. 먼저 쇼핑몰에서 상품을 구매할 때 회원의 잔여금액이 있는지확인하고 잔여금액이 상품가격보다 많을 때 선택한 상품을 구매하는 로직으로 넘어간다. 그리고 선택한 상품의 재고가 있는지 확인하여 재고가 있다면 회원의 잔여금액을 상품가격만큼 감소시키고 로직을 종료한다.

로직만 본다면 완벽한 것 같기도 하다. 근데 만약의 상황을 가정해보자. 예를 들어 선택상품구매 로직에서 Exception()이 발생하여 상품이 없음에도 있다고 된 것이다. 또는 잔여금액이 감소하는 찰나에 서버의 전원이 나가 상품을 구매해버렸는데 회원의 잔여금액은 감소하지 않는 상황 말이다. 이런 문제는 곧바로 엄청난 비용손실을 발생시킬 것이다. 예를 바꾸어 금융권 경우는 어떨까? 은행같은 곳에서 특정 입력 시에 발생하는 오류를 크래커가 알아내어 송금을 하여도 자신의 계좌에서 돈이 차감되지 않는 사실을 알게 됬다면? 그 누구도 이런 전자상거래는 이용하고 싶지 않을 것이다.

트랜잭션이란 바로 이런 문제를 해결하기 위해 탄생한 기술력이다. 2개 이상의 쿼리를 하나의 커넥션으로 묶어 DB에 전송하고 이 과정에서 어떠한 에러가 발생할 경우 자동으로 모든 과정을 원래 상태로 돌려놓는다. 그야 말로 All Or Nothing 전략이다. 프로시져도 같은 맥락이긴 하지만 차이점은 로직을 Java에서 처리하는게 아니라 DB상에서 처리한다. 과거 트랜잭션 구현이 어렵고 프로시져 구현이 더 간편했을 때만 하더라도 많은 웹어플리케이션이 비지니스 로직을 Java가 아니라 DB에서 처리하는게 유행했던 시절도 있었다.

좀 황당한 사실이긴 하지만 진짜다. 혹자는 이 때는 일컬어 자바의 암흑기라고도 한다. 자바 프로그래머들이 고작 하는 거라곤 DBA(DataBase Administrator)가 짜준 로직을 호출하고 결과값을 대충 조작해 리턴해주는게 대부분이었다. 이런 개발 방식에서는개발자가 DBA님을 상전 받들 듯이 모셔야 하며 모든 로직을 구현하는데 있어 DBA님이 선사하신 프로시져를 감사한 마음으로 사용하다가 만에 하나 오류가 발생하면 이게 프로시져의 문제인지 내 코드의 문제인지 밤잠설치며 고민하다가 은근슬쩍 DBA님에게 커피라도 한잔 마치면서 넌지시 물어봐야 했던 것이다.

심지어 현장에 투입된 신입프로그래머들은 웹어플리케이션마다 제각각으로 짜진 난해한 프로시져들을 완전히 습득하기 전엔 키보드에 손도 못올릴 때가 있었다. 그 뿐이던가. 초기에 가난한 벤쳐회사가 MySQL을 이용해 서비스를 하다가 어느 정도 성장해 Oracle 같은 유료 데이터베이스로 교체할 때, 또는 하나의 웹어플리케이션에 2개 이상의 데이터베이스를 사용할 때에는 그야말로 개발자와 DBA가 서로 멱살을 움켜지며 매일같이 댄싱파티를 열어대는 장관이 연출될 때도 있었다.

왜냐하면 자바는 mysql 커넥터에서 oracle 커넥터로 라이브러리만 교체해주면 그만이지만 DBA들은 기존의 DB에 있는 프로시져들을 몽땅 새로운 DB에 옮겨 주어야 했기 때문이다. 게다가 옮기는 과정에서 생기는 오타나 데이터베이스 제품마다 다른 성질로 발생하는 문제까지 테스트 하자면 개발자들은 연이어 발생하는 트러블 때문에 모든 다시 코드를 뜯어봐야 했고 수정해주어야만 했다.

그러나 이제 트랜잭션 기술의 발달로 이런 문제는 옛날 일이 되었다. 물론 프로시져가 트랜잭션보다 속도가 빠르다는 이유로 아직도 프로시져를 사용하는 그룹이 있긴 하다. 하지만 서버의 퍼포먼스 향상과 기술이 발달로 그런 속도차는 극단적인 상황이 아닌 이상 미미한게 사실이다.

다시 본론으로 돌아가자면 트랜잭션은 하나 이상의 쿼리에서 동일한 Connection 객체를 공유하는 것을 뜻한다. 이게 뭔말인가 하면 Java에서 DB로 연결할 때는 java.sql.Connection이란 객체를 이용하는데 이 Connection 객체에는 setAutoCommit(자동커밋)이라는 메서드가 존재한다. 이 메서드와 연결된 autoCommit 객체는 true란 기본값을 가지고 있으며 한번의 연결 이후 자동으로 커넥션을 커밋해 종료시켜준다. 근데 트랜잭션을 이용하려면 이 자동커밋을 false로 바꾸고 수동커밋으로 변경해야만 한다. 즉 이용자가 직접 커넥션에 대해 커밋과 롤백을 해준다는 뜻이다.

Commit(커밋) : 해당 Connection의 요청을 완료하고 특별한 에러가 없다면 결과를 DB에 반영한다.

RollBack(롤백) : 해당 Connection 수행 중 예기치 않은 에러가 발생하였다면 모든 과정을 취소하고 DB를 Connection이 수행되기 이전상태로 변경한다.

물론 스프링의 트랜잭션 기술을 이용하면 이런 과정을 직접 해줄 필요는 없다. 스프링은 단 몇줄의 코드만으로 다이나믹 프록시와 AOP라는 기술을 통해 크게는 인터페이스 단위에서 클래스, 작게는 메서드까지 세분화하여 트랜잭션을 컨트롤할 수 있게 한다. 거기다 애노테이션 기술로 @Transactional을 설정하는 것만으로도 메서드 또는 클래스, 인터페이스까지 트랜잭션 설정이 가능하게 해준다.

우리는 여러 오픈소스 개발자들의 노력 덕분에 트랜잭션을 편리하게 이용할 수 있게 됬으며 금융권, 상거래에도 문제없이 비지니스 로직의 주도권을 찾아올 수 있게 되었다. 다음 장에서는 본격적으로 스프링의 트랜잭션에 대해 다뤄보도록 하겠다. 마지막으로 덧붙이자면 우리가 이처럼 트랜잭션 쉽게 구현할 수 있고 또 이용할 수 있다면 이젠 트랜잭션도 선택이 아닌 필수 사항이 되어야만 한다. 감당할 수 있는 에러라도 발생하지 않도록 하는 것이 가장 현명한 처사 아니겠는가!

by 거짓말

'프로그래밍 > It 용어' 카테고리의 다른 글

도메인이란? (Domain) (0)	2016.09.23
UM Stereotype ( 스테레오타입 개념 ) (0)	2016.08.01
Spring (스프링) (0)	2016.07.11
스택(Stack) (0)	2016.07.08
DRM (0)	2016.07.08

Posted by 당구치는 개발자

프로그래밍/It 용어 2016. 7. 11. 14:02

스프링이 도대체 뭐란 말인가?

출처 : http://springmvc.egloos.com/487497

본 문서를 읽는 독자들에게 부탁하나 하노라면 토비의 스프링 3와 함께 읽어주길 바란다. 많은 부분이 이 책에서 인용되었고 필자 또한 책을 읽고 이해가 가지 않는 부분에 대해 적어놓는 형태인지라 책과 함께 블로그를 읽는다면 큰 도움이 될 것이라 생각되기 때문이다.

---------------------------------------------------------------------------------------------------------------

[이게 필자가 알고 있는 컨테이너]

토비의 스프링은 다음과 같이 말한다. 스프링은 거대한 컨테이너임과 동시에 Ioc/DI를 기반으로 하고 있는 거룩한 존재이며 서비스 추상화를 통해 삼위일체로 분리되는 3단 변신로봇이라고 한다. 이럴수가! 뭔말하는지는 하나도 모르겠지만 일단 말만 들어도 엄청난데다 가격까지 공짜다. 게다가 이걸 쓰는 사람들마다 칭찬 또 칭찬 일색이니 궁금해서 참을 수가 없다.

근데 말이다…. 필자는 스프링의 지독한 뉴비이므로 여기서 뉴비답게 눈치없게 한번 굴어보려 한다. 일단 스프링이 대단하고 무지 엄청나다는 건 알겠는데…. 컨테이너는 뭐고 IoC/DI는 뭐란 말인가? 평생 살면서 컨테이너란 위의 사진같은 것 밖에 모르는데… 그리고 서비스 추상화? 난 아직 서비스가 뭔지도 모르겠다.

컨테이너란?

컨테이너란 당신이 작성한 코드의 처리과정을 위임받은 독립적인 존재라고 생각하면 된다. 컨테이너는 적절한 설정만 되있다면 누구의 도움없이도 프로그래머가 작성한 코드를 스스로 참조한 뒤 알아서 객체의 생성과 소멸을 컨트롤해준다. 거기다 컨테이너를 이용함으로써 얻게되는 이득은 어마어마 하며, 이런 강력한 기능을 무료로 이용할 수 있다는 점 또한 엄청나다.

허나 소수의 독립심 강하고 줏대있는 사람들은 내가 잘 알지도 못하는 프로그램을 무작정 써야 한다는 것에 반감을 살 수도 있다. 게다가 프로그래머가 다른 라이브러리에 의존하지 않고 직접 코드를 작성해나간다면 완성된 프로그램에 대한 이해도 또한 상상을 초월할 것이다. 혹은 인간이 그렇게 줏대없이 프로그램만 의존하다가 터미네이터나 매트릭스 같은 세상이 되버리면 어떡하냐고 필자에게 따질 수도 있는 것이다.

만약 이러저러한 이유로 컨테이너를 거부하겠다면 필자는 굳이 사용하지 않아도 상관은 없다고 말하겠다. 진심으로 실력만 된다면사용자가 직접 컨테이너를 만들어써도 상관은 없다.

그러나 직접 컨테이너를 구현해보고자 키보드에 손을 올렸다면 아마 배보다 배꼽이 더큰 컨테이너의 어마어마한 기능에 입이 쩍벌어질 것이다. 빈정상하라고 하는 말은 아니지만 사실 당신이 구현하고자 하는 코드와 컨테이너의 구현 코드는 비교도 안될 정도로 수준차가 어마어마하다. 그러므로 코드의 이해가 당장 힘들어지고 뭐가뭔지 모르겠더라도 일단 막강한 기능을 제공하는 컨테이너를 이용하기로 하자.

다시 말하지만 프로그래머가 작성한 코드는 컨테이너를 사용하게 됨으로서 프로그래머의 손을 떠나 컨테이너의 영역으로 떠나버리게 된다. (정확히 말하자면 컨테이너가 맘대로 객체를 생성하는 게 아니라 프로그램을 이용하는 이용자의 호출에 의해 컨테이너가 동작하게 되는 구조이다.) 여하튼 컨테이너를 이용한다면 우리의 골치아픈 문제는 다 컨테이너 알아서 해주므로 쓸데없는 버그나 난해한 과제들에 골치 아파질 이유가 없어진다. 당신은 컨테이너의 기능을 이용하고 사용 중 오류가 있으면 일단 무조건 개발사 탓을 하면 되므로 회사에서 짤릴 가능성까지 어느 정도 낮아진 셈이다!

내친 김에 당신이 필자와 같은 初뉴비라면 임기응변을 위해서라도 반드시 스프링의 개발자와 자바의 개발자 정도가 누군지는 알아두어야 한다. 이런걸 미리미리 알아둬야 나중에 직장 상사가 괜한 버그로 트집을 잡을 때 무조건 이 사람들 탓으로 돌릴 수 있게 된다.

자바의 아버지, 제임스 고슬링 - 선 마이크로시스템즈라는 회사와 함께 자바라는 언어를 탄생시키는데 혁혁한 공을 세운 인물이며 SUN이 오라클로 인수된 뒤 얼마 지나지 않아 회사를 퇴임하고 현재 구글에서 근무 중이다. 개인적으로 C와 UNIX를 만든 데니스 리치 다음으로 훌륭한 프로그래머라고 생각한다.

스프링 혁명가, 로드 존슨 - 프로그래밍 계의 락스타같은 존재라 할 수 있다. 그가 한 유명한 말로 "항상 프레임워크 기반으로 접근하라"라는 말이 있는데 이 말은 곧 당신이 한 클래스에서 DB에 넣고 빼는 등 온갖 짓거리로 코드를 짜고 있다면 당신이 어디가서 프로그래밍의 프자도 꺼내서는 안된다는 말이다.

당신은 이 서블릿 클래스가 몇시몇분몇초에 호출될지 정확히 알고 있는가?

다시 본론으로 돌아와 스프링과 더불어 대표적인 컨테이너를 예로 들자면 톰캣과 같은 WAS(Web Application Service)를 들 수 있다. 우리가 열심히 작성한 서블릿을 써줄지 말지는 톰캣이 결정하므로 당연히 컨테이너 아닌가. 혹여나 그래도 이해가 가지 않는다면… 그냥 당신이 쓰고 있는 코드가 도통 언제 호출될지도 감이 안오는 막막한 상태라면 올바르게 컨테이너를 이용하고 있다고 하자. 그런 의미에서 컨테이너는 당신의 사수나 수석 프로그래머라고 할 수 있다. 내가 쓴 코드를 그 사람들이 써줄지 말지는 모르는 일이니 말이다.

IoC/DI란?

IoC/DI란 Inversion of Control과 Dependency Injection의 줄임말이다. 한글로 번역하면 제어의 역전, 의존적 주입이라고 하는데 목에 힘을 좀 빼고 솔직히 말하자면 살다살다 한글로 번역까지 했는데 이해 못할 말이 튀어나올 줄은 몰랐다. 그래서 나름 좀… 쪽팔려도 뉴비의 표현으로 바꾸자면 "대신 해줌(IoC)"과 "미리 찜해 놓음(DI)"라고 잠시 명칭을 정정하도록 하겠다.

일단 IoC란 무엇인가? 당신이 위의 컨테이너의 설명글을 꼼꼼히 읽어왔다면 IoC는 지금 당신이 생각하고 있는게 맞다. 바로 컨테이너다. 컨테이너는 당신이 작성한 코드 컨트롤(객체의 생성과 소멸)을 대신 해주는데 IoC덕분에 우리는 미친 사람마냥 언제 호출될지도 모르는 코드를 마음껏! 칠 수 있게 되었다.

사실 IoC는 스프링만의 코딩방식은 아니고 다른 프레임워크에서도 사용되는 방식인데 굳이 스프링만 우리는 IoC 방식이라고 목이 힘주어 강조하는 이유는 스프링은 정말 철저하게 IoC 방식을 써먹었다는 것이다. 그러므로 우리가 여기서 얻을 수 있는 결론은 어디가서 스프링 좀 안다고 IoC가 스프링만의 고유한 방식이라고 떠벌리면 안된다는 것일테다.

그렇다면 DI란 또 무엇인가? 이것은 마치 당신이 받아먹기도 전에 미리 받아먹겠노라고 선언하는…, 주는 놈은 생각도 않았는데 먼저 말부터 꺼내놓는 파렴치한 코딩방식이라고 할 수 있다. 예를 들어 당신이 조촐한 회식으로 사장님과 중국집을 갔는데 당당히 "저는 짜장면 안먹고 양장피 먹겠습니다."라고 선언한다면 당신은 DI개념이 아주 확실한 프로그래머인 셈이다.

게다가 사실 DI 마저도 스프링만의 고유한 방식은 아니라는 거다. DI란 전설과도 같은 프로그래밍 예언서 GoF 중에서 가장 유명한 전략패턴을 일종의 프레임워크 처럼 편리하게 사용할 수 있도록 만든 것이라 할 수 있는데 스프링은 이런 전설로만 알아오던 전략패턴을 뉴비마저도 산소 호흡하듯 능수능란하게 사용하게끔 편리화하였다.

좀 더 구체적으로 DI에 대해 말하자면, DI방식으로 코드를 작성한다면 현재 사용하고 있는 객체의 메서드가 어떻게 작성되었는지 알 필요가 없으며 솔직히 그 클래스가 기능을 잘 구현했는지 조차도 알 필요가 없다. 그저 당신이 확인할 사항은 클래스의 기능을 추상적으로 묶어둔 인터페이스만 갖다 쓰면 그만이다. 나머지는 스프링에서 찜한 걸 연결시켜줄테니 말이다.

아래 그림은 위의 글로만 써놓은 전략패턴과 DI에 대해 정말 간단히 예제로 만든 코드이다.

먼저 말했듯 DI는 스프링만 가지고 있는 고유의 기능이 아니므로 자바의 오브젝트 단위에서도 DI의 구현이 가능하다. 먼저 StrategyPatternService 클래스를 보면 sp라는 객체는 인터페이스 객체인 StrategyPattern로 선언되었으며StrategyPattern의 메서드인 dependency_injection()를 호출하고 있긴 하다. 그러나 객체 생성 과정에서 객체 sp에 StrategyPatternImpl 클래스를 주입시켜버림으로써 결과적으로 객체 sp는 StrategyPatternImpl의 dependency_injection()이란 메서드를 호출해버리고 말았다는 것이다.

그러므로 위에서 말했듯이 당신은 인터페이스의 메서드만 이용하더라도 위와같이 구현부는 나중에 주입을 통해 해결하므로 획기적인 분업과 동시에 구현 클래스를 쉽게 교체할 수 있다는 장점을 얻게 된다. 물론 스프링은 위의 이미지와 같이 단순한 방식으로 주입하진 않는다. 주입 방식에만 클래스 형태와 XML형태 2가지가 있으며 그 세부적으로도 어마어마하게 많은 방식으로 DI를 할 수 있다.

가끔 스프링을 쓰다보면 이런 다양한 방식이 진짜 편리와 우수한 기능을 위해서인지… 아니면 일부러 사용자를 헷갈리게 하려는 건지 분간이 안갈 때가 종종 있다. (개인적으로 로드 존슨이 프로그래머들을 편집증으로 몰아가기 위해 꾸민 음모가 아닌가 싶다…)

여하튼 IoC/DI의 개념을 요약하자면 정신나간듯 언제 사용될 지도 모르는 코드를 쳐대면서(IoC) 동시에 사용하고 있는 코드가 뭔지도 모르면서 일단 갖다 쓰는(DI) 획기적이고 진보적인 프로그래밍 작성방식이라 이해하면 되겠다.

서비스 추상화란?

솔직히 지금 DI를 설명하면서 서비스 추상화에 대한 부분까지 함께 설명해버렸다. 간략하게 개념에 대해서만 설명하자면 토비의 스프링의 일부분을 발췌하는 것이 좋을 듯 싶다.

추상화란 하위 시스템의 공통점을 뽑아내서 분리시키는 것을 말한다. 그렇게 하면 하위 시스템이 어떤 것인지 알지 못해도, 또는 하위 시스템이 바뀌더라도 일관된 방법으로 접근할 수가 있다.

그렇다. 우리는 위의 간단한 DI예제에서 StrategyPattern이란 인터페이스로 기능을 분리시킴으로서 하위시스템, 즉 클래스가 그 무엇으로 교체되더라도 해당 메서드는 반드시 존재할 것이란 보장을 받은 셈이다. 당신이 위의 모든 글을 읽고서도 아직 잘 이해가 가지 않는다면 지금 당장은 이러한 것을 과연 어떻게 구현해낼까에 대해 고민하지 않아도 된다. 사실 그것을 알아나가는 과정이 바로 스프링을 공부하는 과정이기 때문이다.

다만… DI예제의 과정, 즉 인터페이스를 구현하고 주입하는 과정이 이해가 가지 않는다면 당신은 자바에 대한 기본기가 매우 부족한 것이니 자바의 정석을 펼치고 객체지향개념부터 다시 필독하고 읽어보길 바란다.

'프로그래밍 > It 용어' 카테고리의 다른 글

UM Stereotype ( 스테레오타입 개념 ) (0)	2016.08.01
트랜잭션 (0)	2016.07.11
스택(Stack) (0)	2016.07.08
DRM (0)	2016.07.08
잡다한1 (0)	2016.07.08