블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

지금까지 썼던 글들.

사는 이야기 | 2007. 8. 23. 11:51 | Posted by 조대협

Sep.07                    Write article of “Programming know-how by 12 java programming

                              Master” in Microsoftware magazine.

July.07                    Write article of “ESB to governance,technical guide for successful SOA”
                                 in Microsoftware magazine.

Mar.07                    Write article of “What is SOA?How to SOA?” in Microsoftware magazine

Dec.06                    Write article of “SOA implementation strategy with BEA product”

                              In Eweeks magazine

Nov.06                    Write article of “SOA development process” in Eweeks magazine

Aug.06                    Write article of ‘EAI strategy’ in eBizKorea magazine

Mar.06                     Write article of ‘Introduction of ALSB for enterprise’

in microsoftware magazine

Feb.05                    Write artifle of ‘Finding bottleneck & tuning in J2ee application’

                              in microsoftware magazine

Aug.04                    Write article for ‘JVM tuning’ in microsofware magazine

Mar.03 to May.07       Write about more than 14 technical article about BEA product & J2EE

                              (ex. Capacity planning, Deployment guide etc )

Mar.03 to May.07       Write about more than 50~60 technical tips about BEA product

                              in B.E.S.T. (BEA Korea Technical magazine)

Sep.03 to Nov.03      Write article for ‘Java Transaction Programming’

in programming world magazine

Jan.02 to Oct.02       Write article for ‘Mobile trend’ in LG Telecom website

Jun.01 to Oct.02       Columnist for ‘Java Q&A’ in programming world magazine

July.01 to Aug.01      Write article of ‘Java swing programming’

in programming world magazine

==
다음 글은 개발 과정 자동화에 대한글 (형상관리,빌드 자동화,배포 자동화,버그 트랙킹)에 대한 글을 써야 겠다. 시간나면 EP에 대한 글도..

'사는 이야기' 카테고리의 다른 글

맛있는 칼국수집  (0) 2007.09.10
안경  (0) 2007.09.07
앞으로 키워나가야 할것들...  (0) 2007.09.06
매운 굴 소스 삽겹살 구이  (0) 2007.09.05
지금까지 썼던 글들.  (0) 2007.08.23
요즘 관심 있게 보는것들  (0) 2007.07.25
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG 기고

댓글을 달아 주세요

아이언 세트..

사는 이야기/골프 | 2007. 8. 22. 14:33 | Posted by 조대협
몬가를 시작하면 장비병이 도지는것은 어쩔 수 없나보다.
골프 클럽은 연말에나 구입할 생각이지만..
그전에 클럽을 얻어 쓰거나 중고 클럽을 사용하는 것을 진지하게 고민중이다.
워낙 고가이다 보니 몸에 안맞는것 샀다가 고생할 수 도 있고..
클럽을 피팅한다는 이야기도 들었기에 심사 숙고해야할듯

유력선상에 올라있는것이 미즈노 MX-25나 JPX인데... 기회있을때 시타라도 한번(시타 할 솜씨나 되나?)해봐야 겠다.

'사는 이야기 > 골프' 카테고리의 다른 글

드라이버..  (0) 2007.09.28
구입한 아이언..  (0) 2007.09.28
스윙폼  (0) 2007.09.04
아이언 세트..  (0) 2007.08.22
똑딱샷  (0) 2007.08.07
운동시작..  (2) 2007.08.06
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

평가의 방법

IT 이야기/IT와 사람 | 2007. 8. 21. 18:46 | Posted by 조대협

오늘 인턴 사원 평가를 했다.
예전 팀장 시절에는 체계가 없어서 제대로된 평가를 한적이 없었는데.
오늘은 인턴사원이지만 평가를 하면서 시니어로써의 무게를 느껴봤다.

하나 얻은 교훈은 "피드백을 할때, 좋은 것을 80%, 나쁜것을 20%" 이야기 하라는 것이다.

맞는말인지, 의미는 잘 모르겠지만, 예전에 내가 평가를 받을때의 느낌을 생각해보면 맞는 말 같다. 사실 피드백에서 나쁜점들이 50%이상 나온다면, 이미 그 사람은 회사에서 존재하기 어려운 사람이 아닐까?
 '칭찬은 고래도 춤추게 한다'고, 업적을 찬양해서 일할 수 있는 동기를 부여하고, 부족한점은 메꿔 나가게 하는것이 메니져로써의 역할이 아닐까?

'IT 이야기 > IT와 사람' 카테고리의 다른 글

프로젝트를 가장 쉽게 망치는 방법  (0) 2008.07.14
이런 오픈소스 라이센스 정책이 있었으면 좋겠다..  (2) 2008.06.23
HP 비리...  (0) 2008.02.04
깨진 창문 이론  (1) 2007.10.30
프로와 아마추어의 차이  (2) 2007.09.06
평가의 방법  (1) 2007.08.21
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 천상 2007.10.26 14:50  댓글주소  수정/삭제  댓글쓰기

    밑의 사원이라면 열심히 하는것도 중요하지만
    그만큼 위에서 끌어주고 길을 잡아주는 사람이 어떻게 하느냐에 따라 그사람의
    재능과 능력을 이끌어낼수 있는 기회가 더 주어진다고 생각하네요 전.
    좋은 메니져가 되세요~~

EAI 도입 전략

아키텍쳐 /EAI | 2007. 8. 21. 16:29 | Posted by 조대협
한국 소프트웨어 진흥원 부탁으로 써줬던 기고인데,
EAI의 도입 전략에 대해서 설명했던 글이다.

==

Introduction strategy of EAI

 

2006 7 5

자바스터디 네트워크 (http://www.javastudy.co.kr)

 조대협 (bcho@bea.com)

 

1. EAI 가 필요한가?

 

전통적으로 기업의 애플리케이션들의 개발은 각 부서의 업무나 특정 업무의 요구 사항에 맞춰서 필요한 시기에 전사적인 기업 업무나 기존의 IT 시스템에 대한 고려 없이 독립적으로 개발되었다.

  , 고객 관리를 위해서 CRM이 개발이 되었고, 경영자의 데이터 분석을 위해서 DW 시스템이 개발이 되었고, 기업 내부의 전산화를 위해 그룹 웨어가 개발이 되었다.

 이런 각각의 애플리케이션의 개발은 개발 당시의 적합한 기술(?) 또는 주류가 되는 기술에 의해서 개발이 되었고 결과적으로 기업의 애플리케이션들은 각기 다른 기술로 구축이 되고, 데이터 또는 기능상의 불필요한 중복을 야기하게 되었다.

특히 1980년대를 거쳐 1990년에 이르기 까지, 메인프레임에서부터 C/S환경 인터넷 환경까지의 급격한 기술 변화를 거치면서, IT 시스템들의 플랫폼은 점점 더 다양화 되게 되었다.

 이로 인해서 점점 거대해지고 다양화된 IT 시스템에 대한 유지보수 및 중복 개발로 인한 비용이 증대하게 되었고, 이는 기업 시스템 운영의 하나의 문제점으로 대두 되게 된다.

 

이 시기에 경영자들은 각 부서간 협업과 업무 프로세스 개선을 통해서 기업의 전략을 신속하게 비즈니스에 반영하려는 시도를 하지만, 기존의 IT 시스템은 이미 독립적으로 개발이 되어서 연계성이 떨어지고, 비즈니스 요구 사항을 IT 시스템에 반영하려면 기존 시스템들에 대한 수정을 일일이 거쳐야 하기 때문에 민첩성이 떨어지게 되었다.

 

이런 이유로 기업의 애플리케이션들의 통합에 대한 필요성이 대두되게 된다.

 

2. EAI 의 개념

먼저 EAI의 개념에 대해서 간략하게 설명하기 위해서 간단한 예를 들어보자. 고객이 어떤 기업에 물건을 하나 주문하고, 구입하는 순서를 살펴보면 고객이 물건을 주문을 하면, 기업에서는 주문 내용을 시스템에 입력하고, 입금이 된 것을 확인한 다음에, 재고 관리 시스템을 조회해서 재고가 있는지를 체크한다. 재고가 없으면 다시 발주시스템을 통해서 협력사에 물품을 발주하고, 재고가 있으면 물류 시스템을 통해서 해당 물품을 출고 시키도록 하고 출고된 물품은 운송 추적 시스템을 통해서 고객에게 수령되기 까지 추적된다.

주문

입금확인

재고체크

출고

운송

발주

납품

수령

고객

기업

협력사

발주 시스템

주문 시스템

재고관리

물류 시스템

운송 시스템

 

 

 

 

 

 

 

 

 


< 그림 1. 주문 프로세스 예제 >

이 업무 프로세스에서 기업에서는 각기 독립된 다른 시스템에 접근해서 데이터를 입력해야 하고(주문,영업정보 etc), 때로는 중복된 데이터를 입력해야 하는 경우도 있을 것이고, 재고가 없어서 발주라도 했을 경우에는 발주자가 해당 물품이 납품이 되었는지 아닌지를 일일이 확인한 후에 출고를 시킬 수 있다.이렇게 다수의 인터페이스를 통해서 각각의 애플리케이션을 접근해야 하는 복잡성 때문에 업무의 효율이 급속하게 감소된다.

 만약에 이 각각의 시스템들이 유기적으로 결합되어 하나의 통합된 주문 처리 시스템으로 존재한다면 좀더 빠르고 신속하게 주문 이라는 업무에 대해서 대응을 할 수 있게 될것이다.

 이렇게 각기 다른 시스템을 통합해주고 유기적으로 연결 시켜주는 시스템을 EAI (Enterprise Application Integration)이라고 한다.

 

폭넓은 의미에서의 EAI는 전체 시스템 통합을 의미한다. Presentation Layer간의 통합, Application 간의 통합, Data 간의 통합을 모두 포함한 개념이지만, 현재 일반적으로 사용하는 EAI Application 간의 통합을 지칭한다. (참고: Presentation Layer간의 통합은 Enterprise Portal, Data간의 통합은 Data Integration Solution 등을 통해서 이루어 진다.)

 

3. EAI 모델과 단계별 도입 전략

 

EAI의 단계별 발전 모델로 분리했을 때 크게 3가지 모델로 분류할 수 있다.

1) P2P

가장 기본적인 형태의 EAI로 단위 애플리케이션을 1:1 로 연결한다.

기존의 전통적인 통합방법에서 가장 많이 사용한 형태로 간단한 애플리케이션간의 통합에서는 저비용으로 쉽게 구현을 할 수 있으나, 시스템의 통합 규모가 커짐에 따라서 관리상의 어려움과 함께 표준화되지 않은 인터페이스나 기술에 의한 통합이기 때문에 비용상의 문제가 함께 발생한다.

 

2) Hub & Spoke

현재 일반적으로 이야기 하는 EAI 시스템의 구조이다. EAI 솔루션이 Hub 형태로 단위 애플리케이션들을 EAI Hub에 연결하고, Hub를 통해서 애플리케이션간의 호출 및 통신을 하는 구조이다.

 중앙 집중된 Hub를 통해서 통합을 진행하기 때문에 중앙에서의 통제와 관리등이 가능하며, 중앙 Hub의 통합된 연결 인터페이스를 통해서 단위 애플리케이션의 업무간의 재사용성이 극대화 된다.

 기존에는 CORBA등의 ORB 형태의 Hub를 사용했으나, CORBA의 기술적인 난이도와, CORBA를 지원하지 않는 애플리케이션까지 통합하기 위해서 2000년대에 들어서는 전용 EAI Hub Adapter 로 조합된 형태의 EAI 제품군들을 주로 사용한다.

 

3) BPM based EAI

Hub&Spoke 방식이 애플리케이션간의 연결만을 뜻한다면, BPM Based EAI는 애플리케이션의 업무를 재배치 및 조합하여 새로운 업무를 빠르게 구현하여 비즈니스 요구사항에 빠르게 대응할 수 있는 민첩성을 제공한다.

 비즈니스의 요구가 바뀌었을 때 해당 요구에 대한 애플리케이션을 구현하기 위해서 다시 코딩을 하는 것이 아니라 비즈니스 프로세스상에서 기존 조합을 변경함으로써 요구 사항을 반영하여 빠르게 현업의 요구 사항을 IT에 반영할 수 있게 된다.

 

일반적으로 현재 EAI 솔루션은 Hub&Spoke 모델을 지칭하는 경우가 많지만 요즘에는 BPM을 포함한 EAI 모델을 지향하는 경향이 있다.

1990년대 초반에 비즈니스 프로세스의 구축을 위한 BPR (Business Process Reengineering)이 대두 되었고, 포춘선정 500개 기업이 이 BPR을 도입하였지만 대부분의 결과는 실패로 돌아갔다. 이유는 staring from scratch 즉 기존의 애플리케이션의 기능들을 재 사용하는 것이 아니라 재구축 하는 곳에서부터 시작했기 때문인데, 그에 대한 대안으로 나온 것이 BPM (Business Process Modeling)이다. BPM은 기존의 애플리케이션의 기능들을 재사용하여 단위 애플리케이션들을 업무 흐름에 맞추어서 재배치 하는 것으로 기존 업무의 재 사용을 전제로 하는 만큼, EAI의 사상과 잘 매치가 된다.

 

BPM은 업무 프로세스를 재정의하고 구성하는 만큼 IT 부서에서 뿐만이 아니라 실제적인 업무와 그 흐름을 정의하는 경영부서와 함께 진행되어야 하며 Six sigma, ISO9000같은 비니지스 프로세스의 재 정립과 함께 진행한다면 좀더 큰 효과를 기대할 수 있다..

 

기업에서 통합을 고려하고 있다면 빅뱅식의 접근 모델 보다, 3가지 발전 모델을 단계적으로 도입하는 것이 통합에서 올 수 있는 혼란이나 부작용을 최소화 할 수 있다.

 

4. 성공적인 EAI 구현을 위한 전략

 

그러면 지금부터 성공적으로 EAI 시스템을 구축하기 위한 몇가지 전략에 대해서 알아보도록 하자.

 

1) 목표와 범위

먼저 애플리케이션을 통합하고자 하는 목적을 명확하게 정의해야한다. 통합하면 좋으니까 라는 막연한 목표보다는 고객 신상 정보와 고객 매출 정보 시스템을 통합하여 고객 관리 만족도를 높이겠다. 등의 구체적인 목표를 정해야만 프로젝트의 방향이 어긋나지 않는다.

다음으로는 정해진 목표를 이루기 위한 통합의 범위를 정한다.

종종 EAI 프로젝트를 보다보면 실패하는 원인중의 하나가 초반에 정의되지 않은 범위와 목표를 벗어나는 업무를 이번에 통합하는 김에 같이 하자 라는 등의 막연한 이유로 막판에 통합에 포함 시키려는 시도를 보게 된다. 그러나 이는 처음에 설계되었던 통합의 방향을 바꿀 수 있고, 새로운 통합 대상 시스템이 들어오게 됨으로써 프로젝트의 범위를 넓혀버릴 수 있다.

 먼저 설정된 목표와 범위만큼만 통합을하고, 확장은 다음 단계의 개발에 반영하는 것이 현명하다.

 단 해당 목표를 위한 통합의 범위를 지정했음에도 불구하고, 개발중에 목표 달성을 위해서 통합의 범위가 더 추가가 필요로 되는 경우가 있는데, 이는 프로젝트의 수행을 순차적 수행 모델이 아닌 반복적 (Iterative) 수행 모델을 통해서, 각 프로젝트 Milestone 별로 feed back을 받고 적절한 통합 범위를 조정하는 것이 필수적으로 필요하다.

 

2) 기존 시스템 인식

통합을 진행하면서 통합할 시스템의 기능적과 비기능적인 요소에 대한 검토가 필요하다.

 먼저 통합에 필요한 기능이 있는지 없는지 그리고 새로 추가해야하는 기능이 있는지 없는지를 검토하고 통합에 필요한 기능적 요건을 모두 만족할 수 있는지를 검토한 후 에,

 비기능적인 요소, 즉 해당 애플리케이션의 동시 사용자수, 평균 응답시간, 장애에 대한 대응 능력 SLA,Qos 등을 체크해야 한다.(대부분 기능적인 요소에 대해서는 꼼꼼하게 검토가 이루어지지만 이 비기능적인 요소에 대한 검토는 프로젝트시에 점검이 소홀한 경우가 많다.)

 예를 들어 5개의 애플리케이션을 통합하여 새로운 비즈니스 애플리케이션을 만든다고 했을 때, 4개의 애플리케이션의 평균 응답시간이 0.3 sec라도, 1개의 애플리케이션의 평균 응답시간이 5sec, 이 새로운 애플리케이션의 전체 응답 시간은 0.3*4 + 5 = 6.2초가 된다. 5sec가 걸리는 애플리케이션에 대한 증설이나 재개발 또는 EAI의 메세징 모델의 변경등을 통해서 비 기능적인 요소를 만족시킬 수 있도록 해야한다.

 

3) 부서간 협력과 EAI 팀의 지배력

EAI 프로젝트를 진행하면 가장 중요한점중의 하나가 협업이다.

EAI의 대상 시스템은 주로 다른 부서간의 업무가 되는 경우가 많고, 통합을 위해서 일부 애플리케이션에 대한 수정이나 가감 작업이 수행되는 경우가 많은데, 이 경우에 부서간의 대화 문제나 책임회피 등으로 이상적이지 않은 방향으로 시스템이 통합되는 경우가 있다.

 이를 해결하기 위해서 원할한 협력관계가 우선시되어야 하는 것은 물론이고, EAI 프로젝트를 진행하는 주관팀이 효과적인 EAI 아키텍쳐를 위해서 적절하게 해당 부서에 통합 업무를 분할하고 진행 요청할 수 있는 적절한 권한을 가져야 한다.

 

4) Simple is best

애플리케이션을 상호연동하다보면 나오는 문제점중의 하나가 트렌젝션 에 대한 범위 지정일 것이다. 트렌젝션의 연동은 애플리케이션에서 매우 중요하고 필수적인 요소라고 할 수 있지만 그만큼 복잡성이 높고, 쉽게 연동할 수 없는 부분이기도 하다.

 실제로 기업 통합의 시나리오를 살펴보면 전체 업무의 80~85% 정도가 트렌젝션 연계가 필요없는 경우가 많다. 불필요한 부분에 트렌젝션을 연계하여 시스템의 복잡성을 증가시키지 말고 필요한 부분에만 사용하도록 하자.

또한 2Phase Commit이나 XA 사용보다는 Logging을 이용하거나 보상 트렌젝션등을 이용하는 방법으로 시스템을 단순화 시키는 것이 시스템의 안정성과 성능 향상에 더 큰 도움이 된다.

 

5) 경영 지원

기업의 애플리케이션 통합은 IT 부서의 요구보다는 비니지스 조직의 요구사항에 의한 경우가 많다. 그 만큼 경영 부서에서 애플리케이션 통합에 대한 인식과 적절한 요구 사항을 도출 시키는 것이 중요하고, IT 부서와의 협업을 통해서 적절한 통합 범위와 프로젝트 단계를 설정하는 것이 중요하다.

 또한 BPM 기반의 통합의 경우 BPM 자체가 비니지스 조직에 의해서 도출 되는 만큼 비즈니스 프로세스의 개선 작업이 경영선에서부터 시작이 되어야 한다.

 

5. SOA EAI

 

현재의 애플리케이션 통합을 이야기 하자면 SOA를 빼놓을 수 없다. EAI SOA의 접근 방식은 어떤면에서는 매우 비슷하게 보이지만 각각이 고유한 특징을 가지고 있다.

 SOA의 접근은 서비스 지향적인 접근 방식이다. 서비스란, 애플리케이션의 API나 구현 단위를 뜻하는 것이 아니라, 비즈니스적인 의미를 가지고 있는 단위 컴포넌트 이며, 서비스의 호출은 플랫폼이나 특정 기술에 대한 종속성을 가지고 있지 않는다. (해당 시스템이 Tuxedo ATMI, CORBA로 개발되었던간에 사용자 입장에서는 공통된 표준 기술을 이용해서 호출이 가능하다)

 상품ID로 정보를 상품 정보를 데이터베이스에서부터 읽어온다. 는 기능이 애플리케이션적인 의미를 가진다면 상품 ID로 발주를 한다는 의미는 상품의 재고 상태 파악과 입금 정산, 운송을 함께 하는 기능으로 비즈니스적인 의미를 가지게 된다. 반대로 EAI는 애플리케이션의 각 API들을 연동하여 하나의 통합된 의미의 기능을 만드는데 그 목적을 가지고 있다.

 EAI는 이 비즈니스적인 의미를 가지는 서비스 자체를 구현하기 위해서 하단의 애플리케이션들을 통합하여 상위 개념으로 추상화하여 하나의 서비스를 구축하는데 사용되며 특히 트렌젝션 연결과 같은 Tightly Coupled 된 애플리케이션 통합에서는 SOA 함께 사용되어야 한다.

 SOA Reference Architecture를 보더라도, SOA의 인프라가 되는 ESB (Enterprise Service Bus)의 하단에 애플리케이션들을 통합하여 비즈니스 서비스화하여, ESB에 연결하는데, EAI 가 이 ESB의 하단에 위치하게 된다.

 

6. 결론

 

기존의 애플리케이션들은 각기 다른 요구사항에 따라서 독립적이고 상호적인 운영성이 고려되지 않은 상태에서 독립운영 되도록 설계가 되었다.

그러나 기업이 커지고 업무의 복잡성과 요구되는 민첩성이 증가함에 따라 애플리케이션 간에 서로 공유되어야 하는 정보와 애플리케이션의 필요성을 인식하면서 통합에 대한 필요성이 대두 되었고, 기업들은 이러한 자원들을 연결하여 능률적인 비즈니스 프로세스를 구현하기 위해서 EAI를 도입하고 있다.

 

EAI를 도입하기 위해서는 적절한 목표와 이를 위한 적절한 범위가 선정되어야 하며, 통합을 진행하는 과정은 업무의 성격과 시스템의 규모에 따라서 단계적으로 진행되어야 한다. 효과적인 통합을 위해서는 EAI를 추진하는 조직이 성공적인 EAI 시스템의 구축을 위해서 부서간의 통합을 통제할 수 있는 적절한 권한을 가져야 한다.

 

또한 기업의 업무 프로세스 자체를 혁신하고 이를 IT에 민첩하게 반영하기 위해서 BPM이 등장하였으며, BPM의 적용은 IT 조직뿐만이 아니라 경영조직의 지원이 함께 이루어져야 한다.

 

EAI 프로젝트는 다음단계로 이루어질 SOA를 지원하는 구조가 고려되어야 한다.

'아키텍쳐  > EAI' 카테고리의 다른 글

Apache Camel Error Handling  (0) 2013.02.20
Apache Camel Overview  (0) 2013.02.17
EAI (Enterprise Application Integration) 추진 전략  (2) 2009.07.16
ETL vs EAI  (0) 2009.06.16
EAI 도입 전략  (0) 2007.08.21
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

Java AP에서 Locking처리 방법은 Synchronized 를 사용하는 방법이 대표적인데
이 경우에는 하나의 JVM Instance 내에서만 동기화 처리가 가능하다.

시스템을 설계할때, 다중 인스턴스 구조의 부하 분산 환경을 고려한다면, 인스턴스내의 Locking 처리인지 아니면 인스턴스간의 Locking처리가 필요한지를 먼저 결정해야 하고, 인스턴스간의 Locking처리인 경우에는 DB나 아니면 기타 (RMI,JMS등) 방법을 사용하는 방식이 있다.

특히 DB의 Lock 처리 메커니즘을 생각할때 고려할 부분은
보통 다음과 같은 구조로 만드는 경우가 많다.
1: select LOCK
2: if( unlocked){
3: update set LOCK
4: }else { return "Lock이 걸려있음"}
5: 임계구역

그러나 이경우, 두개의 인스턴스 A,B가 있다고 했을때
A가 1을 수행하고 Lock이 없어서 Lock을 잡으려고 시도해서 2라인에 진입했다.
이때 B가 Lock체크를 하기 위해 1에 진입하였다면?
A가 아직 Lock을 잡기 전이기 때문에, 결과적으로 A,B 두개 모두 임계구역에 진입하게 된다. Single Instance인 경우에는 당연히 Synchronized처리로 해결하면 되겠지만,
Multi Instance 인경우 다음과 같은 방안이 있다.

1) select하기 전에 해당 row에 DBLock을 거는 방법
2) select하지 않고 update의 return값으로 체크하는 방법

1) 방안은 DB마다 다르기 때문에 별도로 설명하지 않고
2)의 방안을 보면
1: ret = stmt.exeucteUpdate("UPDATE LOCK");
2: if(ret == 0){ return "Lock이 걸려있음"}
3: 임계구역

stmt.executeUpdate는 update에서 반영된 레코드수를 리턴하기 때문에 이미 lock에 대한 update가 된경우에는 0을 리턴한다.
※ 그러나 JDBC 드라이버에 따라서 executeUpdate에 대해서 update에 대한 리턴값이 무조건 0인경우가 있을 수 있기 때문에 반영전에 테스트를 필요로 한다.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

About SOA

아키텍쳐 /SOA | 2007. 8. 20. 11:19 | Posted by 조대협

2007년 7월 6일 포스팅 글
==
이번에도 SOA기고를 하나 하긴 했는데. 맨날 했던 말이 그말인것같다.
한번 더 고민 한점이 있다면 한국에서만 유달리 SOA가 전파되지 않는다는 것이다.
근래의 N社에 입사해서 시스템들의 구성들을 이야기 들어보면, SOA의 필요성이 인식이된다. 비단 Enterprise만이 아니라 service업체에서도 개개의 서비스들을 XML형식으로 통신하는 구조가 많이 있는데, 중앙에서 통제되지 않고, XML-RPC, WebService, XML-HTTP 등등 프로토콜이 각각이고 Granuality도 각각이며, UDDI와 같은 Dictionary도 없는것 같다.
흔히들 말하는 공통 서비스들이 그것이 될테인데. 이미 SOA의 1차적 개념을 가지고 접근을 하고 있으나 SOA적인 접근을 이루는 경우는 많지 않다.

현재 IT 시스템들은 SOA와 같은 서비스 통합의 개념이 필요할 정도로 이미 성숙하였고 (Process Oriented SOA나 Event Driven SOA는 별게 겠지만..) 어떠한 형태로든지 제공이되고 있다.

그렇다면 왜? SOA가 도입이 되지 않을까?
첫번째는 SOA가 무엇인지 모르는 이해의 부족에서 온다.
현 업무 시스템의 구조가SOA가 필요함에도 불구하고, 이를 다른 방향으로 각각의 부서에서 독립적으로 개발하고 있다.
이를 해결하기 위해서는 각 개발 부서에서 SOA에 대한 이해를 충분히하고 도입 여부를 결정해야 하며, 공통 개발팀이나 Evengelist 그룹에서 SOA 기술에 대한 적극적인 홍보에 나서야 한다.

두번째는 경영진의 인식 부족이다.
SOA개념이 좋다는 것은 알고 있고 무엇인지도 이제는 대충 알고 있으리라 본다. 거버넌스도 이미 알고 있을듯 하지만, 문제는, 이 SOA가 장기적인 플랜이 필요하고 강제적인 중앙 통제가 필요하다는 것을 인식하지 못하는것 같다. SOA를 IT전략으로 체택하고 장기적으로 SOA를 적용해야 하는데 단기 위주의 프로젝트구조에서는 이것이 힘들다는것.

특히나 첫번째에 언급한것처럼 Evangelist의 부재로 인한 점이 하나의 문제점인데.
SOA는 하나의 IT 비젼이기 때문에 말단 개발자까지도 SOA에 대한 기본 개념을 파악하고 회사의 SOA 전략을 IT전략으로 인식해야 한다. 그래야 제대로 된 Service를 만들 수 있고, Loosely Coupled등의 개념을 적용하고 Governance에서 필요한 각각의 절차에 맞추어 일할 수 있는데, 개발자들에게 SOA는 하나의 귀찮은 개념으로 치부 되는것이 아닌가 싶다.

요즘들어서 Peopleware에 대한 생각을 많이 하는데, SOA 도입의 문제점은 기술보다는 사람이 문제가 아닌가 싶다.

얼마전에 K이사님이 조언해주신말중에 하나가
리더와 지도자의 차이중의 하나이다.
"사람을 통제하려고 하지 말고, 잘할 수 있도록 도와주는것이 리더와 지도자의 차이"라는 말을 요즘 생각하고 있는데. 언뜻 생각을 바꿔 보니 SOA 의 도입 방식도 거버넌스와 같이 지나치에 지도자적인 방향이 아닐까?
 각 이해당사자들이 SOA의 필요성을 인식하고 하나의 비젼으로 생각한다면 의외로 한국에서 SOA의 도입이 쉬워질 수 도...

 Do you want to introduce SOA into your company?
Make your customer to raving fan of SOA..!!

'아키텍쳐  > SOA' 카테고리의 다른 글

2008년 SOA 전망  (0) 2008.01.10
Next Enterprise  (0) 2007.12.21
What is SOA? How to SOA?  (1) 2007.09.04
SOA & Agile  (0) 2007.09.04
About SOA  (2) 2007.08.20
SOA에 대한 기술적 접근  (2) 2007.08.20
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. ChiefTree 2007.08.20 22:26  댓글주소  수정/삭제  댓글쓰기

    역시.. Evangelist에 대해 더 알고 싶어서 검색 했더니.. 조대협님 블로그가 나오네요.ㅋㅋ ^^ 오늘 귀한 조언 감사합니다. 덕분에 개발 과정과 그 상위의 개념까지도
    쉽게 이해가 됐어요~* N사에서 인턴하면서 조대협님께 정말 많은 걸 배워갑니다.^^

  2. 초보 개발자 2007.08.21 11:01  댓글주소  수정/삭제  댓글쓰기

    N사 인턴님 대단 하단 말 밖에 나오지 않네요.
    저도 저 단어는 오늘 처음 듣는지라..... 부끄럽네요.
    저런 좋은 인적 환경에서 인턴 생활 한다는게 참 부럽기도 하네요.
    다 노력의 결과 겠죠?
    인턴님께 안 뒤질려면... 막말로... 피똥 싸게 열심히 해야 겠네요.

SOA에 대한 기술적 접근

아키텍쳐 /SOA | 2007. 8. 20. 10:55 | Posted by 조대협

월간 마이크로소프트웨어 2007년 7월호 기고 내용

==
“ SOA는 무엇이고, SOA를 준비하기 위해서 무엇을 해야 할까? 그리고 SOA 시스템을 구축하기 위해서는 어떤 기술을 준비해야 할까 ? ”

수년간 많은 벤더와 매체를 통해서 SOA라는 단어를 들어보고, 웹서비스, ESB, BPM, Governance와 같이 SOA와 관련된 주요 키워드들에 대해서 접해왔을 것이다. 그러나 정작 시스템을 어떻게 SOA화 해야하는지 심한 경우에 SOA 자체가 무엇인지 조차 이해하지 못하는 경우도 많다.

 이 글에서는 SOA의 올바른 이해와 함께, SOA 시스템 구축에 용이한 기술에 대해서 알아보도록 하겠다. 

  1. SOA란 무엇인가?

 SOA란, 기존의 애플리케이션들의 기능들을 비즈니스적인 의미를 가지는 기능 단위로 묶어서 표준화된 호출 인터페이스를 통해서 서비스라는 소프트웨어 컴포넌트 단위로 재 조합한 후, 이 서비스들을 서로 조합(Orchestration)하여 업무 기능을 구현한 애플리케이션을 만들어내는 소프트웨어 아키텍쳐이다. 

SOA의 단계적 발전 모델

필자가 SOA를 이야기 할 때 빼놓지 않고 이야기 하는 것 중의 하나가 SOA의 발전 모델이다.  
초기의 SOA는 시스템을 서비스화하여 이를 묶어서 하나의 통합 시스템으로 구축하는 통합 중심의 SOA모델이었다. 이 모델은 P2P형식으로 서비스를 묶는 것에 중점을 두었으며 특히 이 기종간의 통합이 주요 목적이었다. 이런 초기적인 SOA 모델을 Fundamental SOA라고 이야기 한다.

이런 SOA모델이 발전함에 따라서 P2P형식일 경우 서비스간의 연결이 거미줄처럼 연결되어 통제가 불가능하게 되고, 서비스의 변경에 따라 그 서비스를 사용하는 다른 시스템에 영향도가 증가해서 시스템의 유연성이 떨어지게 되었다. 이를 보완하기 위해서 서비스의 연계 구조를 중앙에 Hub를 넣어서 중앙 집중형 구조로 변경하고 업무의 변화에 따라서 변화 내용을 반영하는 서비스 (Intermediary service)를 추가한 모델을 Networked SOA라고 한다.

기업의 업무 환경이 급속하게 변화함에 따라 서비스를 묶어서 구현한 업무 프로세스의 변경이 잦아지게 되는데, 이 잦은 업무 변화를 빠르게 반영하고 또한 현업과 IT조직간의 업무 정의에 대한 커뮤니케이션을 쉽게 하기 위해서 도입되는 것이 BPM이다. 이러한 BPM도입을 통해서 SOA시스템에 민첩성을 추가한 SOA구조가 Process Oriented SOA이다. 

간략하게 SOA의 개념과 발전 모델에 대해서 설명을 하였는데 이는 SOA를 개발하는데 유용한 기술의 발명 단계와도 관련이 있기 때문이다.  

좀더 자세한 설명은 http://blog.javastudy.co.kr/bcho/entry/What-is-SOA-How-to-SOA 문서를 참고하기 바란다 

  1. SOA 관련 기술

 웹서비스를 사용하면 SOA라고 말할 수 있을까? ESB를 사용하고 있으면 SOA 시스템이라고 말할 수 있을까?

 대답은 NO! 이다. SOA는 앞에서도 설명했듯이 시스템을 개발하기 위한 하나의 아키텍쳐이며 개념이다. 웹서비스나 ESB는 SOA개념을 구체화 하기 위한 요소 기술이나 솔루션에 불과하다. 이러한 기술들은 SOA 아키텍쳐를 구현하고 고민하면서 필요에 의해서 선택되거나 개발된 솔루션이다. 그래서 기술을 선택할 때 원래 이러한 기술이 나오게 된 이유 즉, 필요성에 대한 인식을 하지 못하면, 잘못된 기술을 선택하는 결과를 낳을 수 있다. 

“SOA에 대한 이해를 통해서 기술과 솔루션의 필요성을 인식한다.”

SOA를 구축하기 위한 몇가지 유용한 기술에 대해서 소개한다. 

  1. 업무 도메인에 대한 이해

“조엘 온 소프트웨어”를 보면 소프트웨어를 크게 4가지 종류로 나눈다. 기업용 소프트웨어, 서비스 소프트웨어, 패키지, 엔터테인먼트 소프트웨어 종류로 나뉘어 진다.

패키지는 MS-Office처럼 패키징이 되서 판매되는 소프트웨어를 말하고 엔터테인먼트는 게임이나 MP3 등과 같은 성격의 소프트웨어를 말하며 서비스 소프트웨어는 블로그, 카페, 인터넷 포탈과 같은 B2C 형식의 소프트웨어를 말한다.

 이 4가지 분류에서 현재 SOA가 적용되기 적절한 것은 기업용 소프트웨어와 서비스 소프트웨어 이다. 물론 소프트웨어 인프라가 발전이 되면 MS-Office에서 맞춤법 검사나 폰트등이 서비스 형태로 인터넷에서 제공될 수 있지만, 현재로써는 SOA가 적용되기에는 다소 이르다고 볼 수 있다.특히 현재 주류를 이루는 SOA는 기업용 소프트웨어는 업무 복잡도가 높고 시스템간의 복잡한 연계가 많아 SOA 사용시에 여러 장점이 많으며, 비용에 민감한 구조가 SOA의 장점에 부합하기 때문이다. 상대적으로 서비스 소프트웨어의 경우 은행 계좌 이체와 같은 Critical한 업무가 적으며 복잡도나 변화도가 낮기 때문에, SOA의 개념을 변형하여 WEB 2.0에서 OPEN API의 개념으로 구현하고 있다.

SOA를 적용하기 위해서는 적용하고자 하는 업무가 이 4개의 소프트웨어 종류중에 어느것에 해당하는지를 인식할 필요가 있다. 

  1. XML

 XML은 SOA의 서비스의 메시지를 정의하는데 매우 유용한 기술이다. 유연성과 가독성이 높고 플랫폼에 종속적이 아니다. 이런 이유로 현재의 SOA의 대부분이 XML을 이용하여 서비스의 메서드를 정의하고 있다. XML 문서 정의 기술 자체와, XML의 항목을 쉽게 얻어올 수 있는 XPath, XML의 문서 형식을 정의하기 위한 XML Scheme, DTD, XML 문서를 변환하기 위한 XSLT, XML 문서의 내용을 마치 데이타베이스의 SQL처럼 쿼리하기 위한 XQuery등이 현재의 SOA에서 주로 사용되는 XML 관련 기술이다.

이를 프로그램에서 처리하기 위한 자바 관련 기술로는 XML 파싱 기술인 JAXP 등이 있으며 요즘에는 XML 문서와 JAVA 객체를 복잡한 Parsing API를 사용하지 않고 상호 변환해주는 XML to Java 기술이 있으며, J2EE에서는 JAXB가 표준에 포함이 되어 있고 그 외에도 Castor와 같은 비표준 기술이 있다.

  1. 웹서비스

 SOA의 서비스를 구현하기 위해서는 표준화된 인터페이스를 통해서 서비스를 제공해야 한다. 이를 위해 인터페이스 표준화 기술이 필요한데, 주로 언급되는 것이 웹서비스이다. CORBA, RMI 또는 XML/HTTP등과 같은 프로토콜을 사용해도 되지만 웹서비스가 SOA에 있어서 주목을 받는 이유는 XML 기반이기 때문이다. 웹서비스는 다른 프로토콜에 비해서 비교적 쉽고 .NET, JAVA 와 같은 개발 플랫폼에 상관없이 모든 솔루션에서 호환성이 뛰어나기 때문에, SOA의 표준 인터페이스로 많이 사용된다.

 웹서비스 표준은 WS-I을 기본으로 하고 있고, 트렌젝션이나 로깅 관리, 메세징 (Sync ,Async ,Reliable)등의 부가적인 기능을 제공하기 위해서 WS* (Webservice extension)이라는 확장 표준을 정의하고 있다.

웹서비스 적용에 있어서 주의 할 점은 표준을 지원하는 방법이 벤더나 솔루션 마다 다르다는 것이다. 예를 들어 Reliable Meassaging의 경우, Vendor에서 웹서비스를 이용한 Reliable 메세징을 지원한다고 해서, WS-Reliable Messaging의 표준을 따르지는 않는다. Reliable Messaging의 표준이 나온지 얼마 되지 않지만, 각 Vendor는 각자의 고유 방법으로 Reliable Messaging을 지원하다가 표준이 나온 후 표준 기반의 Reliable Messaging을 지원하기 때문에, 이러한 기능들을 어떤 표준이나 구현방법으로 웹서비스에서 지원하는지에 대한 확인이 필요하다. 

  1. CBD (Component Based Development)

 SOA에서 가장 중요한 것 중 하나는 서비스의 정의 방법이다.

SOA의 서비스 정의를 다시 살펴보면, “기존의 애플리케이션들의 기능들을 비즈니스적인 의미를 가지는 기능 단위로 묶어서..” 와 같이 기능을 비즈니스적인 의미를 갖는 컴포넌트로 묶는데 있다.

이 서비스 컴포넌트의 단위를 Fine-grained (작은 단위)로 묶을 것이냐? Coarse-grained(큰 단위)로 묶을 것이냐? 는 SOA에서 중요한 하나의 설계 포인트가 된다.

Fine grained로 서비스를 나눴을 경우에는 각각 서비스의 의미는 정확해지지만 많은 서비스들이 존재하기 때문에 관리가 어려워지는 결과를 낳게 되며, Coarse grained한 서비스는 각개의 서비스기능을 사용하기 위해서 큰 서비스 컴포넌트를 사용해야 하기 때문에, 효율성의 문제가 생긴다.

비즈니스 업무를 효과적으로 서비스 컴포넌트로 추출하기 위해서는 방법론이 필요한데, 현재에는 SOA를 위한 명확한 방법론이 많지 않다. 벤더나 컨설팅 업체마다 SOA 방법론이라는 것을 제공하고는 있지만, 필자의 개인적인 생각으로는 충분하지 않고 추상적이거나 학문적이라는 생각이 든다.

서비스 역시 소프트웨어 관점에서 보면 하나의 소프트웨어 컴포넌트이고, 컴포넌트에 대한 분석 설계를 하기 위한 방법론으로는 대표적으로 CBD (Component Based Development)가 있다. 비단 CBD가 아니더라도 비즈니스 업무를 적절하게 서비스로 맵핑 시키고 그 서비스의 크기(Granuality)를 결정하는 것은 SOA에 있어서 매우 중요한 기술 요소가 된다. 

  1. Integration

 SOA 시스템은 서비스를 조합하여 업무를 구현해야 한다. 이 과정에서 이기종이나 타시스템간의 트렌젝션을 보장해야 하는 경우가 있다. 이런 경우에는 서비스를 묶어서 하나의 트렌젝션으로 구현하거나 또는 시스템들을 묶어서 트렌젝션을 보장하는 하나의 서비스를 구현하는 두가지 방법이 있다.

 전자의 경우 서비스에 트렌젝션을 보장하기 위한 기술이 필요한데, WS*-Transaction과 같은 기술이 있지만, 아직 일부 벤더에서만 제공하고 있다. 웹서비스를 통해서 트렌젝션을 묶을 경우 XML과 HTTP 통신등의 부하로 인해서 트렌젝션 처리에 대한 속도문제가 대두될 수 있다.

후자의 경우에는 시스템간을 통합하는 방법으로 여러가지 방안이 있겠지만 현재 자주 사용되는 아키텍쳐로는 EAI (Enterprise Application Integration)을 통해서 시스템을 통합하는 방법이 있으며, 트렌젝션 관리를 위한 요소 기술로는 JTA,JTS와 같은 트렌젝션 관리와, 이 기종 시스템들을 표준화된 인터페이스로 연계 하기 위한 Connector 아키텍쳐인 J2CA등이 있다. 

  1. ESB

 SOA 시스템의 규모가 커져가고, 오가는 메시지의 포맷이 다양화 되면서, P2P형식의 단순 통합형태의 SOA에서 버스를 중앙에 둔 SOA 시스템이 고안되었고, 이를 구현한 구현체가 ESB(Enterprise Serbvice Bus)이다. ESB의 초기 디자인시의 기능은 들어오는 표준메세지에 대한 변환,라우팅,모니터링등의 기본적인 기능만을 가지고 있었으나, 근 1~2년간 Legacy 시스템을 연동할 수 있는 기능, 메시지 통신 방법을 Async나 Reliable 메세징을 지원하는 기능들이 추가되는등 매우 빠르게 발전하고 있으며, 요즘에서는 SOA 2.0이나 EDA (Event Driven Architecture)라는 개념을 부가하여, 새로운 형태의 ESB 제품을 계속해서 출시되고 있다..

ESB는 SOA 시스템에서 척추와 같이 중요한 기능을 하고 있으며, SOA의 솔루션 중 가장 중요한 솔루션으로 인식되므로 ESB의 발전되는 기능에 대해서 지속적으로 알아둘 필요가 있다. 

  1. BPM

서비스를 조합한 업무의 구현이 복잡해지고, 기업의 환경이 빠르게 변화함에 따라 그 속도에 따른 업무 변화를 요구하므로 신속하게 서비스를 조합하고 변경할 필요성이 생겼다.

이런 요구를 반영하기 위해서 BPM이 SOA에 사용되기 시작했다. SOA에서는 BPM 솔루션을 사용하는데, BPM을 이용해서 업무를 조합하는 것은 솔루션을 사용하면 되지만 좀더 중요한 것은 업무를 어떻게 BPM으로 구현하는 가이다. 

  1. Enterprise Portal

여러 시스템을 SOA로 통합함에 따라 사용자 인터페이스에 대한 통합 역시 필요하게 되는데, 사용자 인터페이스에 대한 통합이 Enterprise Portal이다. 업무 화면에 대한 통합, 권한 통제, Single Sign On등의 문제를 해결할 수 있다.

이미 많은 시스템에서 SOA를 이용 여부와 상관없이 Enterprise Portal을 통해서 업무를 하나의 UI로 통합하고 있다. Enterprise Portal은 비교적 간단하게 프로젝트를 진행할 수 있지만 특히 여러 시스템을 동시에 호출해서 하나의 UI에 보여주는 만큼 성능에 대한 깊은 고려가 필요하다. 

  1. RIA & AJAX

WEB 2.0이 나오면서 화두가 되고 있는것중에 하나는 RIA (Rich Internet Application)이다. 기존의 단순한 HTML 기반의 화면 UI에서 벗어나서 마치 GUI 애플리케이션과 인터페이스를 웹브라우져에서 제공할 수 있다.

현재 RIA 기술로 많이 사용되는 것은 AJAX,Adobe Flex이다. Applet이나 Active X를 이용해도 RIA 를 구현할 수 는 있지만, Applet이나 Active X는 다운로드에 소요되는 시간이 길고, Platform Dependency를 가지고 있기 때문에 AJAX나 Flex가 널리 사용된다.

특히 AJAX나 Flex는 XML 기반으로 메시지를 처리하고 HTTP 프로토콜을 사용하기 때문에 웹서비스를 사용하는 SOA에는 매우 쉽게 적용할 수 있기 때문에, SOA의 RIA 기술로써 유용하게 사용될 수 있다.

이미 국내의 통신사와 보험회사의 프로젝트에서 AJAX 기반의 RIA 클라이언트가 사용되었으며, 업무 시스템 역시 XML/HTTP 인터페이스 기반의 SOA 1단계 레벨로 구현되었다.

기업의 업무가 복잡해지고 빠른UI처리와 여러UI 기능이 필요함에 따라 RIA의 요구가 증가하게 되었고, 특히 XML,HTTP에 친밀한 AJAX나 Flex 기반의 RIA기술을 SOA에 유용하게 적용할 수 있다. 

  1. Governance

Governance는 소프트웨어 프로젝트의 기획에서부터 개발 운영까지의 모든 과정의 통제를 이야기 한다. Governance 역시 SOA 이전부터 등장한 개념이지만, SOA의 등장과 함께 중요시되는 이유는 SOA의 특징중의 하나는 전체 시스템을 하나의 SOA 거대 시스템으로 묶기 때문에 전체 프로젝트를 관리할 수 있는 방법이 필요하기 때문이다.

Governance는 작게는 형상관리, 배포 관리, 프로젝트 관리에서부터 기업의 장기적인 IT전략의 수립 기술의 전도에 까지 전반적인 IT환경에 대한 관리를 필요로 하기 때문에 프로젝트 관리와 전략 수립에 대한 준비가 필요하다. 

지금까지 간단하게나마 SOA 구축에 유용한 몇가지 기술에 대해서 살펴보았다. 필자가 “필요한”이 아니라 “유용한”이라는 단어를 선택한 이유는 SOA를 구축하는데 정해진 기술이나 방법론은 없다. SOA는 아키텍쳐이며 개념일 뿐이고, 이를 효과적으로 구축하는 것은 개발자의 몫이며, 적절하게 필요한 기술을 선택하여 SOA를 구축하는 것이 중요하기 때문이다. 

    SOA가 활성화되지 않는 이유. 

    비단 필자많이 아니라 많은 사람들이 “왜? SOA가 활성화 되지 못할까?”에 대한 많은 의문들을 가지고 있을것이라고 본다.

    SOA의 개념을 도입한 시스템은 1996년대부터 개발되어서 운영되고 있고 그 사례 또한 다양하다. 이런 사례들이 있다면 불가능한 프로젝트가 아닐텐데 왜 SOA가 활성화 되지 못할까? 

    * 경영자들의 인식 부족 

     필자는 가장 큰 원인을 “SOA에 대한 이해 부족”과 “Governance”조직의 부재라고 생각한다.

    국내의 SOA도입을 시도하는 기업의 담당자들과 이야기를 해보면 SOA의 개념이 무엇인지 ESB가 무엇인지를 제대로 이해하고 있는 사람이 드물다. 설사 SOA의 개념을 제대로 이해하고 있는 사람을 만나더라도 실무 개발자일 경우가 많다.

    SOA는 EJB등과 같은 구체성을 가지고 있는 기술이 아니라 개념이며 하나의 전사적인 IT경영전략이다. 그래서 실무진에서부터의 제안이 아니라 경영진의 장기적인 전략과 의지를 가지고 위에서부터 수행해야 하는 문제임에도 불구하고, 국내 경영진들은 SOA에 대한 개념과 의지가 약하다.

    국내의 IT 관련된 책임자들은 빨리 현업의 서비스를 개발해주고 안정적으로 운영할 수 있고 적은 비용을 초점으로 두며 특히나 단기적인 성과에 많이 집착을 하게 된다.

    국내에서 전사포탈(Enterprise Portal)이 기업에서 확산되는 이유는 통합에 대한 이슈를 수용하면서도 가장 짧은 시간내에 가시적인 성과를 보여주기 때문에 SOA에 비해서 높은 확산을 보이고 있는것이라고 생각한다.

    그러나 SOA로 시스템을 구축하면 단기적인 성과를 보기 어렵다. 초반에 SOA에 관련된 인프라를 구축하고, 기존 시스템을 서비스화하기 위해서는 많은 비용이 소요되지만 이러한 초기투자는 초기보다는 장기적인 관점에서 효과를 낼 수 있는것이기 때문에 선뜻 인프라에 대한 투자가 어렵다.

    또한 SOA는 하나의 업무가 아니라 궁극적으로는 전사적인 업무를 하나의 SOA시스템으로 묶는것이기 때문에, 기존의 부서나 프로젝트 단위의 통제 모델이 아니라 전체 시스템과 프로젝트에 대한 전사적인 통제조직이 필요하다.(Governance)

    그러나 국내에서는 부서간의 커뮤니케이션 문제와 부서간의 파워게임(?) 때문에 전사적인 통제 조직이 하부 조직을 관리하기가 어렵다.

    SOA Governance 조직이 있는 경우도 드물거니와, 있다하더라도 그에 충분한 통제 권한과 비용이 지원되는 경우가 드물다. 경영자가 SOA를 도입해서 그만한 효과를 보고자 한다면 그에 상응하는 의지를 가져야 하지 않을까? 

    이런상황에서 어떻게 해야 기업에서SOA를 도입할 수 있을것인가?

    SOA에 도입에 의한 가시적인 성과에 대한 공감을 이끌어 내야 한다.

    필자의 글중에 SOA 도입 방법론에서 설명한 내용중에, SOA의 첫 프로젝트에 대한 중요성을 언급한 내용이 있다. SOA의 첫 프로젝트는 가장 관심을 받는 프로젝트이며 SOA의 필요성과 장점을 필역할 수 있는 프로젝트이여야 한다. 그래서 SOA로 구현한 첫 프로젝트는 그에 대한 성과는 높이 평가되어야 하며 실패하지 말아야 한다.

    성공적인 SOA를 위해서는 첫 프로젝트를 선택하는 것이 매우 중요하며 “기업의 핵심 업무중 가시성이 높고 상대적으로 위험도가 낮은 업무를 선택”해야한다. 

    * 벤더의 SOA

    하나 또 집고 넘어가고 싶은 것이 벤더 들에서 이야기 하는 SOA이다.

    Messaging 시스템을 개발하던 벤더는 SOA 시스템중 메세징에 중점을 둔 ESB를 이야기 하면서 ESB가 SOA의 전부인 것 처럼 이야기하고, BPM이 강점인 벤더는 BPM이 SOA의 전부인 것 처럼 이야기 한다. SOA의 원래 개념보다는 벤더들의 제품과 자사의 장점에 맞춰서 SOA를 제각각 해석이 되고 그것이 전체 SOA인 것 처럼 이야기 한다.

    어떤 벤더들은 SOA를 할려고 하면 Governance도 해야하고 ESB도 있어야 하고 EAI,EP등등 모든 솔루션들을 다 이야기 한다. 틀린말이라고는 하지 않겠지만, 한꺼번에 그런 솔루션들을 도입한다고 해서 SOA화가 될까? 물론 가능은 하겠지만, SOA는 그런 솔루션을 당장에 도입하지 않더라도 단계적으로 차근차근 발전 시키면서 기업 업무에 필요한 솔루션을 선택해서 성숙 시켜나갈 수 있다.

    SOA를 도입하고자하는 기업이 SOA에 대한 이해를 하는데 어려운 점중에 하나가 이러한 벤더들의 SOA를 자체적으로 해석하고 포장한 것 때문이 아닐까?

    SOA를 제대로 수행하기 위해서는 벤더들에게 이끌려가지 말고, SOA를 적절히 이해해서 필요한 솔루션을 벤더들에게서부터 선택할 수 있는 수준의 SOA 자체에 대한 이해가 필요하다.

'아키텍쳐  > SOA' 카테고리의 다른 글

2008년 SOA 전망  (0) 2008.01.10
Next Enterprise  (0) 2007.12.21
What is SOA? How to SOA?  (1) 2007.09.04
SOA & Agile  (0) 2007.09.04
About SOA  (2) 2007.08.20
SOA에 대한 기술적 접근  (2) 2007.08.20
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 초보 개발자 2007.08.21 10:55  댓글주소  수정/삭제  댓글쓰기

    안녕하세요.
    전에 전직 문의 메일 드렸던 사람 입니다.
    지금 계획하고 있는 여러가지 것들 중에 하나가...
    이 직업 그만 두기 전에.. 꼭 SOA 관련 개발을 한번 해 보고 싶다는 것이었습니다.
    요즘.. 시간 날때마다.. SOA 관련 문서를 읽고 있지만...
    무엇을 어디서 부터 준비해야 할지... 막연히...
    뭔가.. 팟 하고.. 와 닿는 느낌이 없었습니다.
    아직 SOA가 뭔지는 모르지만.. 참 좋은 글이라는 느낌이 오네요.
    감사 합니다.

  2. 조대협 2007.08.21 11:43 신고  댓글주소  수정/삭제  댓글쓰기

    이 BLOG에는 옮기지 않았습니다만
    예전에 작성해놓은 글중 "What is SOA? How to SOA?"라는 글이 있습니다.
    인터넷에서 검색하시면 나올겁니다. 전체 개념을 정리 해놓은 글이니까는 참고해보시기 바랍니다.
    수고하세요

업그레이드된 개발자 되기

프로그래밍/프로그래밍팁 | 2007. 8. 20. 10:51 | Posted by 조대협

월간 마이크로소프트웨어 9월에 기고한글
짧은 시간에 작성해서 완성도는 낮지만 고려해서 읽어주세요.

==

시점의 변화

 

소프트웨어 개발은 컴퓨터를 가지고 개발자가 하는 작업이다. 그러나 좀더 깊게 생각해보면 소프트웨어 개발은 결국 사람과 사람이 하는 작업이다.

 소프트웨어 개발 작업을 하는 데 있어서, 기술적인 면이 아닌 생각하고 일을 하는 면에서 조금 관점을 변화시켜야 할것들을 살펴보자.

 

1.       지금 무엇을 하고 있는가?

소프트웨어 개발 프로젝트뿐만 아니라, 지금 하고 있는 일의 의미와 목적에 대해서 생각해 본적이 있는가? 모든 일에는 그 목적을 위해서 제때 적절한 사람이 해야 할 일이 있기 마련이다.

 일을 하다 보면, 일에 대한 목적과 원래 의미는 잊혀지고 전혀 엉뚱한 이슈에 많은 시간을 낭비하는 경우가 많다. (원래 목적과는 상관없는 이슈로 삼천포로 빠져서  몇 시간씩 회의를 해본 일이 있다면 쉽게 이해할 수 있지 않을까?)

소프트웨어 프로젝트의 실패 원인중의 대부분은 무엇을 왜 만들고 있는가, 고객의 요구 사항을 제대로 파악하지 못하는데 있다.

프로젝트 중반에 오픈을 앞두고, 고객의 수정사항은 늘어가고, 기능적인 면보다는 화면 디자인의 색이나 폰트 사이즈에 더 민감한 것이 고객이다. 또한 대부분의 고객은 자신이 원하는 바가 무엇인지 제대로 알지 못하는 경우가 많지만, 고객 자신이 좋아하고 좋아하지 않는 것에 대해서는 정확하게 알고 있다.

 성공적인 프로젝트를 위해서는 가장먼저 고객의 요구 사항을 적절하게 파악하는 것이 중요하다.

UML Use Case Diagram이나 스토리보드등이 매우 효율적으로 사용될 수 있으며, 간단한 HTML또는 RIA(FLEX etc) 4GL (VB)로 만든 기능이 없는 스토리 위주의 샘플 애플리케이션은 고객의 요구 사항을 수집하는데 매우 좋은 도구가 될 수 있다. 복잡한 비즈니스 프로세스가 있는 업무의 경우에는 BPA등의 도구를 사용하여 워크플로우를 시각화 시켜놓으면 복잡한 흐름을 일목요연하게 정리할 수 있다.

이런 도구들을 이용하여 수집한 요구사항에 대해서 고객으로부터 확인을 받아놓는다면, (회의록에 대한 싸인이나, 위의 산출물에 대한 고객확인을 받아 놓는 것) 이러한 요구 사항에 따라 스케쥴된 일정에 새로운 변경 사항이 가미되었을 경우에, 합당하게 개발 비용과 시간을 요구할 수 있을 것이다.

소프트웨어 개발 프로젝트는 고객의 요구 사항만 제대로 파악하고 있어도, 80%는 성공한것이다.

 

* TAG: 요구사항 분석,Use case diagram, sample software, 복잡한 비즈니스 프로세스, 워크플로우, BPA

 

2.       닭 잡는데 소 잡는 칼 사용하기

모든 기술 역시 그 태생에 목적과 이유를 가지고 있다.

소프트웨어 개발에서 중요한 점 중에 하나가, 현재 소프트웨어 개발 규모와 요구사항에 맞게 적절한 기술을 사용하는 것이다. 일반적으로 개발자들은 기술적인 호기심에 의해서 신기술에 대한 도입에 대한 욕심이 많다. 매니져는 매니져 나름데로 신기술을 적용한 시스템이라는 업적을 원한다.

 그러나 그런 기술들은 그만큼의 습득 시간과 비용을 요구한다.

예를 들어 몇 년전 EJB 붐이 일었을 때, 많은 사이트들이 값비싼 WAS를 도입해서 개발을 한적이 있다. EJB는 분산 컴포넌트와 트렌젝션의 보장이 가장 큰 장점이다. 정작 이런 사이트들에서 그런 고차원적인 트렌젝션 처리가 필요한 경우가 얼마나 있었을까? 그 당시 많은 사이트들이 고가의 WAS를 도입했음에도 불구하고 WAS를 단순한 JSP/Servlet 컨테이너 수준정도로 밖에 사용 못하거나, EJB역시 단순한 POJO식의 Business Object 이상으로 사용하지 못한 경우를 많이 봤다.

 

요즘 같이  JSTL,WebWork,Struts,Spring,OR Mapper,AOP …etc 와 같은 각종 오픈소스 프레임웍과 새로운 개념들이 난무하는 세상에서 잘못하면 신기술에 대한 욕심으로 무리한 선택을 할 수 있다. 프레임웍과 기술은 도구일 뿐이다. 아무리 좋은 도구라도 사용법을 제대로 알지 못한다면, 이런 도구들을 오히려 소프트웨어 프로젝트에 해가 될 수 있다.

 어린아이에게 크리스마스 선물로 망치를 선물해주면, 어린아이는 그때부터 망치질할 곳만 찾아다니게되고, 친구따라 강남간다고 너도나도 이야기하는 기술들에 대해서는 한번즘 공부해보고 싶은 욕심이 들게 마련이다.

 그러나 한번더 생각해보자,  소프트웨어 개발을 위해서는 시스템 기능과 요구사항에 적합한 적절하고 사용하기 쉬운 기술이 선택되어야 하며, 기술을 도입하는데에는 그만한 도입에 대한 비용 (구입비용 뿐만 아니라 교육과 습득 시간에 대한 비용)이 고려되어야 한다.

 

*  TAG : 오픈소스, 개발자와 메니져의 욕심, 도구는 도구일뿐, 적절한 도구 사용하기

 

3.       Simple is best. Easy is best.!!

모든 기계가 그렇듯이, 복잡한 기계일수록 고장이 잘난다.

소프트웨어도 마찬가지이다. 복잡한 아키텍쳐일수록 문제가 생겼을 경우에 디버깅하기가 어렵고, 변경 사항이 생겼을 때 반영하기가 어렵다. 디자인 패턴으로 무장한 컨설턴트가 와서 시스템을 온통 디자인패턴으로 도배해놓을 수 도 있다. 그렇지만 그것을 디버깅해야 하는 것은 그 컨설턴트가 아니라 개발자 여러분이다. (디자인 패턴이 나쁘다는 것은 아니다. 불필요한 패턴 사용으로 시스템의 복잡도를 올리는 것에 대한 이야기다.)

 가능하면 시스템은 간단하게 설계하자, 고수가 설계한 시스템일 수 록 단순하고 고장이 작다.

 

CORBA라는 기술을 들어본적이 있는가? CORBA는 분산객체 기술로 이기종간의 통신이 가능하고 트렌젝션을 보장하는 등의 기능을 가진 기술로 소개될 당시에 모든 프로그램들은 CORBA로 개발될 줄 알았다. 모두들 CORBA를 공부하고, 몇몇 프로젝트는 CORBA로 구현이 되었다. 그러나 CORBA가 지금 널리 사용되고 있을까?

 좋은 기술이나 개념은 천재의 머릿속에서 나올 수 있다. 그러나, 사용하는 사람은 천재보다는 범인이 사용하게 된다. 천재들의 수준에 맞춰 개발된 기술들이 범인들이 쉽게 사용할 수 있을까?

 인기 있게 널리 오래 사용되는 기술은 대부분 개념을 이해하기 쉽고 사용하기 쉬운 기술이다.  정말 고수들이 만들어내는 각종 이론들로 무장한 시스템들이 아니라, 이해하기 쉬운 시스템이다.

 

* TAG : 간단할 수 록 튼튼하다. 쉬운 기술이 널리 퍼진다.

 

4.       깊게.. 그리고 넓게..

기술을 깊게 공부해야 하는 것은 당연한 이야기이지만,지식의 깊이와 폭에 대한 균형이 필요하다는 이야기다.

 예를 들어, Socket 프로그래밍을 할 때, JAVA의 경우 Multiplexing성능이 떨어지기 때문에, C언어로 MultiPlexer를 구현하고 JNI로 연결하면 훨씬 더 좋은 성능을 낼 수 있다.

 화면이 많고 권한 처리가 복잡한 엔터프라이즈 솔루션의 경우에는 Enterprise Portal과 같은 솔루션을 선택하면 시행착오를 줄이면서 양질의 소프트웨어를 만들어 낼 수 있다.

 SAP CRM등을 통합할 때, 모두 자신이 강점이 언어로 개발 할 수 있지만, 그보다는 EAI솔루션을 사용한다면 쉽고 성능 좋은 시스템 통합을 이끌어 낼 수 있다.

 어느정도 수준의 개발자라면, 고객의 요구사항을 구현하는 것은 어려운 일은 아니라고 본다.

그러나 이미 구현되어 있는 솔루션이나 오픈소스에 아키텍쳐에 대한 지식이 있다면 처음부터 구현하는 것 보다 그것들을 이용해서 주어진 시간과 비용 내에서 시행착오를 줄이고 양질의 소프트웨어를 만들어 낼 수 있다.

 

* TAG : 이미 있는 것들 찾아보기, 활용하기, 폭넓은 지식 가지기

 

5.       마일 스톤

마일 스톤이란 이정표라는 뜻으로 프로젝트 일정중의 중요시점으로 생각하면 된다. 예를 들어 요구 사항 분석 완료 시점, 각각 컴포넌트 완성 시점, 릴리즈 시점, 알파,베타 테스트 시기 등이 이에 속한다.

 마일스톤을 설정하는 이유는 마일스톤전의 작업에 대한 검증을 통해서 발생한 문제를 다음 단계까지 전파시키지 않기 위해서 문제를 찾아내고 확인하기 위함이며, 요즘의 개발 방법론들이 잦은 Release Feed Back등을 강조하는 것 역시 잦은 마일 스톤을 설정함으로써 문제를 가능한 한 빨리 발견하고 풀어내기 위함이다.(불확실성의 제거)

 마일 스톤이 설정된 주기는 각각이 전체 프로젝트에 대한 미니프로젝트가 되며, 각 마일스톤시 필요한 최소한의 산출물에 대한 정리와 검증(확인을 통한 문제 발결)이 뒤따라야 한다.

정확한 마일 스톤을 설정한다면, 소프트웨어 개발 프로젝트에서 발생할 수 있는 위험 요소를 줄이는 데 큰 도움이 될것이다.

 

 

나만의 도구를 갖추자

소프트웨어 개발에 있어서 IDE Debugger와 같은 툴은 생산성에 지대한 영향을 준다. 개발자라면 적어도 자기가 가지고 다니는 도구세트는 하나 있어야하지 않을까? 여기서는 이미 많이 알려진 IDE Debugging툴보다, 소프트웨어 프로젝트에 필요한 각종 자동화 도구에 대해서 간략하게 소개한다.

 

1.       소스 관리

일주일전에는 잘 돌아가던 모듈인데 일주일동안의 작업 내용이 반영된 후에는 몬가 문제가 생겼다. 어떻게 해야할까? 어느 부분을 수정했는지 알 수 있다면 좀더 빨리 문제의 원인을 밝혀낼 수 있지 않을까?

 운영중인 시스템이 새로운 코드를 반영한 후에 문제가 생겼다. 수정한 부분을 찾는 것보다 이전의 소스 코드로 원상복귀 하는 것이 운영을 정상화 하는데 더 빠르다. 그렇다면 예전에 개발한 소스는 어디에 있을까?

 고객별로 릴리즈한 버전이 많은데 A고객의 이슈를 해결한 버전은 도대체 어느 버전일까?

여러 사람이 협업 작업을 한다면, 공통으로 소스코드는 어떻게 관리해야 할것인가?

소스를 한곳에서 중앙 집중 관리하고, 협업을 가능하게 해주며, 소스에 대한 변경 내역을 관리할 수 있도록 해주는 것이 소스 관리 시스템이다.

 널리 사용되고 있는 무료 소스 관리 시스템은 CVS SubVersion이 있다.

 

TAG : 소스 관리, CVS,SubVersion

 

2.       빌드 도구

빌드는 소프트웨어 개발에서 항상해야 하는 작업이다. (물론 JSP ASP등의 스크립트 언어로만 개발한다면 모르겠지만.) 컴파일하고 기다리고 결과가 나오면 검증하고 에러가 없으면 릴리즈(또는 배포)하고 항상해야 하는 반복적인 작업이다.

 에러가 발생하지 않는 상황이라면 특별하게 할일도 없다. 우리가 빌드를 기다리는 것은 혹시나 있을지 모르는 에러에 대해서 대비하기 위해서 일뿐 빌드와 배포는 커맨드들을 반복해서 입력하는 단순작업에 해당한다.

 이런 단순작업을 내가 아닌 누군가가 해준다면, 그 시간에 코드를 최적화 하거나 좋은 소프트웨어 구조로 리펙토링을 하는등의 생산적인 작업을 할 수 있지 않을까?

 그 누군가가 바로, 빌드 자동화이다.

기본적인 도구로는 make,ant,maven과 같이 커맨드들을 조합하여 빌드를 해주는 도구가 있고,

여기에, Daily Build (Daily Build의 중요성은 여기서 언급하지 않더라도, 조엘 온 소프트웨어 와 같은 유수 개발 관련 서적에서 이미 많이 언급되어 있다.)나 스케쥴에 따른 빌드나 Release 버전 생성을 자동으로 수행해주는 빌드 자동화 소프트웨어가 있다. 이러한 소프트웨어들은 빌드 배포에 대한 스케쥴링뿐만 아니라, 자동화된 릴리즈 버전 생성등이 가능하고, 빌드중의 에러에 대해서 담당자에게 SMS 또는 EMAIL등으로 ALERT을 해주는 기능을 가지고 있기 때문에, 대규모 협업 프로젝트에서 매우 유용하게 사용될 수 있다.

 대표적인 공개 소프트웨어로는 Cruise Control, Ant Hill 등이 있다. Cruise Control Text 기반의 도구로 매우 강력한 빌드 자동화 기능을 제공하지만 Text 기반이기 때문에 다소 사용하기가 어렵다. Ant hill의 경우에는 Web UI를 제공하기 때문에 상대적으로 상용하기는 쉽지만 대신 Cruise Control과 같은 강력한 기능을 제공하기는 어렵다.

그리고, 빌드 과정중에 빌드된 컴포넌트가 제대로 작동하는지 여부를 자동으로 테스트하기 위해서 JUnit과 같은 테스트 프레임웍이 있다.

 

 빌드 자동화는 ant와 같은 빌드 도구,JUnit과 같은 테스트 도구, 그리고 Cruise Control등과 같은 빌드 자동화 도구로 구성이 되고, 빌드와 릴리즈(배포)를 수행함으로써, 시간 절약은 물론 품질에 대한 향상까지 기대할 수 있다.

 

*  TAG: ant,maven,cruise control,anthill,JUnit

 

3.       테스트 도구

 

테스트와 QA(Quality Assurance)에 대한 중요성은 언급하지 않더라도 이미 잘 인식하고 있으리라 믿는다. 테스트의 종류에는 컴포넌트별 단위 테스트, 시나리오에 따른 기능 테스트, 적절한 용량을 커버하고 성능을 낼 수 있는지를 검증하는 부하 테스트, 그리고 장애에 대한 대처 능력을 시험하는 장애 테스트등이 있다.

 그 중에서 테스트팀이나 QA팀이 아닌 개발자들이 일반적으로 수행할 수 있는 테스트로는 컴포넌트별 단위테스트와 부하테스트가 있다.

 단위테스트는 소프트웨어 개발 주기중 테스트 단계에서뿐만이 아니라 개발단계 중간에서도 컴포컴포넌 제작될 때 마다, 모듈의 기능을 검증하여 버그를 예방할 수 있다.

단위테스트는 JUnit등의 단위 테스트 자동화할 수 있으며, 위에서 설명한 바와 같이, 빌드절차에 자동화하여 포함하여 빌드때마다, 개발한 컴포넌트의 기능의 이상 여부를 검증할 수 있다.

 부하테스트는 소프트웨어의 비기능적인요소인 성능이나 용량을 측정하는데 사용되는데, 개발자 단계의 부하테스트를 통하여, 알고리즘의 최적화 여부나 과부하시에 장애 (Dead Lock, Lock 대기 현상,CPU 과점유)를 검증할 수 있다.

 부하테스트 도구로는 상용으로 머큐리의 Load Runner가 널리 사용되며, 무료 도구로는 Microsoft MS-Stress, Apache 오픈소스 그룹의 JMeter등이 있다.

 이러한 테스트에서 가장 중요한 것은 장애나 오류를 발생할 수 있는 시나리오를 추출해내고 이를 테스트에 적절하게 반영하는 것이다.

 여기서는 간단하게 기능적 비기능적 테스트에 대한 간단한 도구만을 소개했지만, 테스트 방법론이나, 테스트를 위한 조직 구조에 대한 고려등 여러가지 고려할 사항이 많다.

 

TAG: 단위 테스트, 기능 테스트,성능 테스트,JUnit,MS Stress, JMeter, Load Runner

 

4.       커뮤니케이션 도구

팀원간의 작업 배분, 이슈에 대한 기술적인 토론, 고객의 변경된 요구 사항의 반영 내용, 그리고 버그에 대한 이슈 등. 이런 이슈들을 해결해나가는 것이 개발이라고 할 수 있다.

보통 이런 이슈들은 회의나 이메일 전화등을 통해서 이루어지는데, 각각의 이슈에 대해 서로 이야기한 내용과, 협의한 내용들에 대해서 문서화하여 추후에 이슈에 대해서 어떻게 대처를 하고 소프트웨어 코드에 반영을 했는지를 추적해야할 경우가 있다.

 또는 현재 소프트웨어 개발에 몇가지 이슈가 남아 있으며, 이슈의 중요도별로 남아 있는 것들은 몇 개인지 각 이슈를 해결하는데 소요된 시간은 얼마인지를 측정하는 것은 프로젝트 관리에서 중요한 비중을 차지 한다.

 이런 이슈에 대한 추적과 커뮤니케이션을 가능하게 해주는 것이 Issue Tracking 시스템이다. 이슈를 오픈하고, 관련된 사람을 추가하며, 이슈에 대한 진행 상황과 중요도를 기입함으로써 현재 시스템에 대한 이슈가 어떤 것이 있고, 진행되고 있는 상태를 쉽게 관리할 수 있게 해준다.

해당 이슈가 반영된 버전을 기입하여, 어느 버전에 문제가 있는지 해결되었는지를 판단하게 해서, 적절한 Release 버전을 판단할 수 있도록 한다.

그리고 이슈가 해결 되었을때는 SubVersion과 같은 소스 관리 시스템에서 이슈를 해결한 Revision Number Issue Tracking 시스템에 기입하여, 이슈를 어떤 식으로 소스코드에 반영하였는지를 추적할 수 있도록 한다.

 주로 버그 관리에 많이 사용되는데, 그 외에 개발의 요구 사항을 반영하는데에도 응용할 수 있다. 대표적인 소프트웨어로는 BugZilla, JIRA와 같은 소프트웨어가 있다.

 

 TAG : Issue Tracking System, Bugzilla, JIRA

 

튼튼한 소프트웨어를 만드는 관점 갖추기

마지막으로 실제 개발을 할 때, 생각해야할것 몇가지만 짚고 넘어가도록 하자.

 

1.       개발자는 메모리로부터 자유로울 수 없다.

자바언어가 나오면서 개발자들은 malloc free (C언어에서 메모리를 할당하는 함수) 에서부터 자유로워졌다. Garbage Collector라는 강력한 기능이 자동으로 메모리를 관리해준다.

그렇다면 진정 우린 메모리에서 자유로울 수 있을까?

 32 Bit 머신을 가정했을 때, 32 Bit 머신의 프로세스당 메모리 사용량은 2^32=4G이다. 여기서 Unix의 경우 이중 2GB는 공유 메모리 영역이고 실제 자바가 사용할 수 있는 것은 2GB이다.

이중에서 Class Method가 올라가는 Perm영역역이 대략 64~256M 그리고 JVM자체가 로딩되는 메모리 영역을 다 합하면, 실제로 자바 애플리케이션의 Heap Size는 최대 1.5~1.7GB 내외이다.

그 영역 안에서도 애플리케이션의 기본적으로 꾸준히 사용되는 영역이 400~500M라면, 일반적으로 1G 안에서 프로그래밍을 해야한다는 이야기다.

 종종 장애를 일으키는 코드를 보면 SQL 에서 select한 결과를 메모리에 유지하게 하였는데, select record 수가 많아서, 메모리 부족현상을 일으키거나, 메모리 사용량이 매우 많아서 잦은 Garbage Collection으로 시스템의 성능이 떨어지는 것을 어렵지 않게 볼 수 있었다.

 물론 64Bit JVM이 출시되고 GC의 성능이 좋아지면서 메모리에 대한 부담이 덜어져가는 것은 사실이지만, 소프트웨어를 개발한다면 항상 메모리 사용에 대한 고려를 가지고 시스템을 설계해야 한다.

* TAG: 메모리 신경 쓰기

 

2.       성능에 대해 고민하기

성능에 대해서 개발자들 만큼 민감한 사람들이 또 있을까? 인터넷 문서들을 봐도 튜닝에 대한 문서들은 빠지지 않고 인기문서중 하나이다.

 그렇지만, 코드는 정말 최적의 성능을 낼 수 있도록 구현 되어 있을까?

직접 작성한 코드를 1~2User 기반에서 테스트 했을때는 잘 돌아간다. 그렇지만 실환경이 1~2User가 아니라 여러명의 동시접속자를 지원하는 서비스라면?

 SQL 문장이나 잘못된 Synchronized처리등은 실환경이나 동시 사용자가 많지 않으면 성능에 영향을 주지 않는다.

 성능에 대한 좋은 가이드와 프로그래밍 방법은 항상 고민해야 하는 문제이고, 거기에 성능에 대한 검증을 어떻게 할것인지를 고려해서 코드를 만들어보는 것은 어떨까?

컴포넌트 별로 테스트시에 Profiler APM-Application Performance Management Tool등을 이용하면 도움이 되고 간단한 부하테스트를 더한다면 성능상에 문제가 있는 코드가 아닌지 좀더 쉽게 검증 할 수 있다. 물론 어느정도 경험이 쌓인다면 이런 도구 없이도 코딩시에 성능에 문제가 되는 코드의 대부분은 걸러낼 수 있겠지만 말이다.

 

* TAG:성능 고려하기, 성능 테스트, Profiler,APM

 

3.       로깅 습관화

결함(Defect)이 없는 소프트웨어는 있을지 몰라도, 문제(Bug)가 없는 소프트웨어는 존재하지 않는다.

그러면 문제가 있을때 어떻게 빨리 발견하고 해결할 방법을 대비해야한다.

그런 방법중의 하나가 디버깅을 위한 LOGGING 처리이다.

LOGGING은 장애나 문제가 없을 때는 그다지 소용이 없는 코드이고 시간 낭비 처럼 보일 수 있지만. 잘 되어 있는 LOGGIN은 문제 해결 시간을 줄이는 데 큰 도움을 준다.

 그렇다고 LOGGING이 범람해서는 안된다. LOG 메시지도 비즈니스 로직처럼 설계가 필요하다.

(실제로 많은 LOGGING 메시지 때문에 운영 시스템에서 DISK IO를 많이 유발하여 성능 저하가 된 케이스를 종종봤다.)

 적절한 로깅에 대한 설계와 반영에 대한 습관을 들여놓도록 하자.

 

* TAG:Logging,Debugging

 

4.       장애 회피 코드 만들기

장애를 피해간다는 것은 정말 어렵다. 장애를 피할 수 있다면 버그가 발생하지 않을 것이다.

장애를 피하려면, 여러가지 상황을 예측해서 만들어 회피 코드를 만들 수 있겠지만, 예측 가능하다면 장애가 아닐 것이다.

그렇다면 어떻게 장애 회피 코드를 만들것인가? 장애에 대한 대처는 직접 장애를 겪어본 사람들의 경험에서부터 나온다. 그렇다고 장애에 강건한 코드를 만들기 위해서 몇 년동안 쫓아다닐 수 도 없는일이고. 답은 장애 경험에 대한 공유이다.

 WAS와 같은 미들웨어나 솔루션들은 이런 장애에 대해서 대처할 수 있는 방안들을 이미 제품안에 넣어놓았기 때문에 그만한 비용을 주고 구입하는 것이다.

 이러한 솔루션을 도입하는 방법이 있는 한편, 필자가 추천하는 것은 매주 진행할 수 있는 기술회의이다. 매주 기술회의를 하면서, 운영이나 개발상에서 겪었던 문제에 대해 공유를 한다면, 여러명의 경험을 한꺼번에 습득할 수 있을것이다.

 필자도, 지난회사에서 5년 가량을 매주 기술회의에 참석했다. 그때 얻었던 경험들은 덕택에 문제에 장애에 대한 시야기 달라지고 그에 대한 대처 방안도 다양해졌다.

 

* TAG: 장애 회피, 솔루션 도입, 기술 공유 회의

 

5.       기본기부터 충실하자.

무엇보다 기본기에 충실하자. 대학교 학부에서 배우는 자료구조,알고리즘,이산수학,공업수학,통계이론,운영체제 등등. 쓰지 않을 것 같지만 실제로 소프트웨어 개발과 시스템을 이해하는데 필수적이고 많이 필요하다.

 얼마전 인턴사원에게 Unix명령어중 tail(파일의 끝에서부터 지정된 라인수를 순차적으로 읽어오는 명령어) java로 구현하는 퀴즈를 낸적이 있었다.

대부분 전체 File Full Scan한후, 라인수를 Count한후, 다시 처음부터 지정된 라인수만큼 Skip  다음 읽는 알고리즘을 이야기 했다. 다른 누구는 전체를 메모리에 읽은후 다시 Count해서 출력하겠다라는 사람도 있었다.

만약 파일크기가 4G이고, 메모리가 1G라면? 전체를 한꺼번에 읽는 것은 불가능할것이다.

저장 매체가 Disk나 메모리처럼 직접 Access가 불가능한 Tape과 같은 순차Access만 가능한 매체라면, 100만 라인의 문서에서 끝에 100라인을 읽기 위해서 Tape 전체를 2번이나 Scan해야 한다.

 답은 seek 명령어를 써서 끝에서부터 순차적으로 읽어온다면 IO를 많이 줄일 수 있다. (실제로 필요한 만큼만 끝에서부터 파일포인터를 이동시킨후 다시 읽어내려오면 되니까는 전체 파일을 스캔할 필요가 없다.)

 누구나 개발자라면 기능적 요구 사항에 맞춰서 소프트웨어를 만들어낼 수 는 있다. 고수와 일반 프로그래머의 차이는 기능적 요구 사항을 구현해내는가 아닌가가 아니라, 비기능적인 요구사항(성능,장애,자원의 효율적인 배분)을 잘 구현해 내는 사람이라고 본다. (물론 커뮤니케이션이나 협업,일정 관리등에 있어서도 뛰어나야 겠지만.)

 이런 비기능적 요구사항에 대한 구현은 컴퓨터 공학의 기본이 튼튼한 사람일수록, 고품질로 구현할 수 있다.

 

 

 

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. onjo 2007.08.22 01:23  댓글주소  수정/삭제  댓글쓰기

    좋은 글 잘 보고 갑니다.. 개발자가 아닌 기획자/관리자들에도 이해될 수 있게 잘 쓰신 것 같습니다.

  2. 제갈량 2008.06.12 16:42  댓글주소  수정/삭제  댓글쓰기

    오~옷! 좋을 글 보고 갑니다. 감동! 감동! 샤방! 샤방!
    + 장애복구도 추가해 주세요..
    아무리 잘해도 장애는 생기기 마련, 장애가 생기면 장애 상태를 감지하고, 초기화를 하는 등 방법으로 복구하는 것도 좋은 방법입니다.
    장애회피가 가능하다면 필요없겠지만, 장애회피가 험난한 과정이라면, 장애복구도 대안입니다.

  3. 양완수 2010.07.07 10:10  댓글주소  수정/삭제  댓글쓰기

    안녕하세요 .
    허락해주신다면 좋은글인것같아 출처포함하여 MSword를 통해 사내 배포하려합니다.
    항상 감사합니다.
    ywsaau77@gmail.com

  4. 헐.. 2015.01.14 20:39  댓글주소  수정/삭제  댓글쓰기

    고... 고수다. 고수가 낙타낳았다!!!

  5. 대박 2017.09.12 17:56  댓글주소  수정/삭제  댓글쓰기

    와..... 엄청나다 이런팁들은 어디서 배우신거죠??

무료 차트 API

프로그래밍/LIBS | 2007. 8. 10. 17:17 | Posted by 조대협
http://www.jfree.org/jfreechart/index.html

이건 TAG LIB를 사용한 CHART
http://cewolf.sourceforge.net/new/index.html
참고 URL
http://kin.naver.com/knowhow/entry.php?d1id=8&dir_id=8&eid=vGCOsa5MVosiI0qSThp9zu97rnFzUNdK&qb=amZyZWVjaGFydA==

'프로그래밍 > LIBS' 카테고리의 다른 글

Bouncy Castle  (0) 2013.03.15
Fuse 관련  (0) 2011.08.02
XDoclet 간단 예제..  (0) 2007.09.11
무료 차트 API  (0) 2007.08.10
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

Bytecode instrument with Weblogic

카테고리 없음 | 2007. 8. 8. 16:42 | Posted by 조대협
http://besee.sourceforge.net/extension/weblogic.html

디버깅할때 매우 유용하겠다.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG APM, 성능

댓글을 달아 주세요

DateFormat과 String에 대한 성능

카테고리 없음 | 2007. 8. 8. 16:26 | Posted by 조대협
1. SimpleDateFormat
SimpleDateFormat은 기본적으로 성능이 좋지 않다. Apache common.lang의 FastDateFormat을 사용하는것이 좋고,
FastDateFormat 객체를 생성할때는 DefaultTimeZone과 Locale을 명시적으로 지정해주지 않으면 매번 시스템에서 읽어오기 때문에 성능 저하가 올 수 있다.

2. new String
new String역시, Locale을 필요로 한다. 지정해주지 않으면 DefaultLocale을 사용하는데, 이 역시 성능 저하를 유발하기 때문에, 사용시 반드시 DefautLocale을 명시적으로 정해주는것이 좋다.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

똑딱샷

사는 이야기/골프 | 2007. 8. 7. 19:07 | Posted by 조대협

'사는 이야기 > 골프' 카테고리의 다른 글

드라이버..  (0) 2007.09.28
구입한 아이언..  (0) 2007.09.28
스윙폼  (0) 2007.09.04
아이언 세트..  (0) 2007.08.22
똑딱샷  (0) 2007.08.07
운동시작..  (2) 2007.08.06
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

운동시작..

사는 이야기/골프 | 2007. 8. 6. 13:56 | Posted by 조대협
작년부터 벼르고만 있던 골프를 오늘부터 시작하기로 했다.
후배한테서 채도 하나 받아놓고...
계속 생각만 하고 있었는데..
아내의 전폭적인 지원에 힘입어서.. 골프 장갑도 사고.. 골프화도 준비했다...
회사 근처에 골프 레슨도 신청해놨고...
몸치인 내가 잘할 수 있을까도 걱정이 되지만..
건강을 위해서도. 그리고 앞으로 일을 위해서도 배워놓을 필요가 있을것 같다..
금전적인 부담이 많이 되는 운동이라서 많이 망설이기는 했지만..어짜피 시작해야할거라면 빨리 시작하는게 좋을것 같아서 시작은 했고, 더군다나 아내의 전폭적인 지원 덕분에 조금이나마 마음 편하게 시작할 수 있는것 같다..
 어여 아내도 건강해져서 같이 연습장을 다닐 수 있었으면 하는데.. 조금 시간이 걸릴것 같아서 미안한 마음이 좀 없지 않다.. 휴가때 가까운 중국에서 골프라도 치고오면 좋으련만..

'사는 이야기 > 골프' 카테고리의 다른 글

드라이버..  (0) 2007.09.28
구입한 아이언..  (0) 2007.09.28
스윙폼  (0) 2007.09.04
아이언 세트..  (0) 2007.08.22
똑딱샷  (0) 2007.08.07
운동시작..  (2) 2007.08.06
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG 골프, 시작

댓글을 달아 주세요

  1. ace 2007.08.06 20:44  댓글주소  수정/삭제  댓글쓰기

    골프에 입문하신 것을 축하드립니다.
    거의 운동이라고는 안해본 저도 마흔이 넘어서 배운 골프에 푹 빠져 살고 있습니다.
    다른 격렬한 운동과는 달리 몸에 큰 무리가 갑작스레 오지도 않고
    그렇다고 쉽지도 않은 (사실 골프가 운동중 가장 어려운 운동이 아닐까 생각합니다.)
    그야말로 무궁무진한 세계입니다.
    제 경험에 의하면 처음 배우실때 조금 힘이 드실지 모르겠습니다만 1년 정도만 힘쓰시면 그다음부터는 평생 운동으로 간직할 수 있습니다.
    다시한번 입문 축하드리며 좋은 나날 되시길 빕니다.

  2. 조대협 2007.08.07 16:21  댓글주소  수정/삭제  댓글쓰기

    누구신지는 모르겠지만 블로그에 들러주셔서 감사합니다.
    골프가 예상외로 재미있는 운동 같아서 흠뻑 빠져 들것 같습니다.
    축하 말씀 고맙습니다.

Liferay 포탈

엔터프라이즈 솔루션/포탈 | 2007. 7. 30. 12:25 | Posted by 조대협

자바 기반 EP에 대한 오픈 소스를 찾던중.
자바 서비스넷에서 이상부씨가 답변해주신 글.
==

제목 : Re: liferay ep 가 좋지 않을까요?
글쓴이: 이상부(guest) 2007/07/29 21:49:53 조회수:25 줄수:15 
아무래도 아파치포탈은 UI가 좀 부실합니다.
liferay enterpise portal은 보셨는지요? (아마보신거 같은데, 보셧다면 왜 apache포탈을
선택하셧나요? 궁금@@)
퀄리티 우수하여 프로덕트에 가깝습니다.
UI도 미려하고, 아작스를 지원하며, 사용층도 뚜렸하게 많습니다.
(소스포지닷넷의 포털부문 다운로드 3위)
사용해보시면 만족하실 겁니다. 외국쪽에는 레퍼런스가 확연히 많지만
한국은 잘모르겠네요.
포탈은 몇번 벤치마크 해봤지만, 라이프레이만한게 없습니다.
아참, 그리고 당근 오픈소스이구요.

금방 들러보니 4.3버전이 나왔군요. 한글도 이젠 잘 지원하네요.
데모에서 확인하세요~
http://www.liferay.com/
==
유료 Support도 가능한것 같고. 한번 써볼만한 포탈인것 같다.
시간나면(?) 한번 해볼만할듯.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG EP, LIFERAY

댓글을 달아 주세요

  1. 2008.08.15 14:01  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

 final static int MAX_CACHE_SIZE=20;
 static Map cache
  = new LinkedHashMap(MAX_CACHE_SIZE,0.75f,true){
     private static final long serialVersionUID = 1;
     @Override
     protected boolean removeEldestEntry (Map.Entry eldest) {
             return size() > MAX_CACHE_SIZE;
    }
   };
 private synchronized void putCache(String userId,List <ContactList> list){
  cache.put(userId, list);
 }
 private synchronized List<ContactList> getCache(String userId){
  return (List<ContactList>)cache.get(userId);
 }

생각보다 꽤나 유용하다...
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

JUnit 사용법

ALM/Test Automation | 2007. 7. 25. 12:46 | Posted by 조대협
http://blog.naver.com/goethe1004?Redirect=Log&logNo=80034140150
퍼온글.

'ALM > Test Automation' 카테고리의 다른 글

DBUnit 예제  (1) 2007.08.27
단위 성능 테스트  (0) 2007.08.24
단위 테스트 방법  (0) 2007.08.24
테스트의 종류  (0) 2007.08.24
DbUnit  (0) 2007.08.24
JUnit 사용법  (0) 2007.07.25
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG eclipse, junit

댓글을 달아 주세요

요즘 관심 있게 보는것들

사는 이야기 | 2007. 7. 25. 12:44 | Posted by 조대협
SVN,ANT,JUNIT,Cruise Control,Anthill
관심있게 보고있는건지 봐야할건지 모르겠다만
요즘 보는 책은 Pragmatic Project Automation.
이어서 봐야할것들이 SVN,JUNIT 이런 순서일것 같네...
엔지니어 생활만 하다가 개발 할려니까는 낮설어~~

'사는 이야기' 카테고리의 다른 글

맛있는 칼국수집  (0) 2007.09.10
안경  (0) 2007.09.07
앞으로 키워나가야 할것들...  (0) 2007.09.06
매운 굴 소스 삽겹살 구이  (0) 2007.09.05
지금까지 썼던 글들.  (0) 2007.08.23
요즘 관심 있게 보는것들  (0) 2007.07.25
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

기술 기술..

IT 이야기/트렌드 | 2007. 7. 25. 10:48 | Posted by 조대협
BEA를 떠나서 현재 프로젝트를 통해서 몇가지 오픈 소스를 접하고,
나름 개발 환경에 대한 고민도 하고 있다.

WebWork,Log4J,Spring,IBatis
이정도 써봤나?

자바서비스넷이나 OKJSP를 봐도, 요즘 오픈 소스에 대한 회의론이 심심치 않게 등장한다.
개념적으로는 모두 훌륭한 소프트웨어들이다. 그러나... 사용해본 결과는 과연 생산성이 높냐? 에 대해서는 한번쯤 의문을 제기 해본다.
 오픈소스 기반이기 때문에 체계적인 교육이나 시스템화된 리소스를 구하기가 쉽지 않고,
오픈소스 역시 하나의 기술이며 플랫폼이기 때문에 적응 시간이 걸리는것은 마찬가지라는 것이다.
 생산성의 증가 역시 IDE나 기타 툴의 도움이 없다면, 많은 CONFIG 파일만 양산해낼뿐 크게 도움이 될까에 대해서는 아직 의문이다.

벤더들의 마케팅에 의해서 기술의 선택이 휘둘렸다면, 요즘은 오히려 오픈소스라는 간판을 내건 새로운 벤더들에게 휘둘려 가는것이 아닐까?

위의 오픈소스들을 사용하면서 느끼는것이, 기술의 원천적인 이해 없이 빨리 구현에 사용하기 위해서 쓰다보니 내 코드 역시 엉망이 되어간다. 마치 예전 고객사들에서 만든 말도 안되는 EJB코드를 보는 느낌이라고나 할까... 개발자 각자의 기술력의 문제라기 보다는 기술 검토-->이해-->적용 이라는 기본적인 절차 없는 "적용"에만 급급한 개발 프로세스의 문제는 아닐까?

'IT 이야기 > 트렌드' 카테고리의 다른 글

자바 기술 트렌드 분석 - 2. OR Mapping  (1) 2009.04.30
자바 기술 트렌드 분석 - 1. MVC  (1) 2009.04.30
구글  (0) 2007.11.21
요즘 개발의 트렌드  (0) 2007.09.04
EJOSA (Enterprise Java Open Source Architecture)  (0) 2007.08.27
기술 기술..  (0) 2007.07.25
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요


==
1. HTTPD 소스를 다운로드한다.
=> wget http://mirror.apache-kr.org/httpd/httpd-2.0.59.tar.gz

2. 압축을 푼다.
=> tar zxvf httpd-2.0.59.tar.gz
=> cd httpd-2.0.59

3. 다음과 같이 configuration을 설정하여 모듈을 빌드한다.
=> ./configure --prefix=/home1/jwkang/proxy --enable-module=so --enable-modules=all --enable-mods-shared=all --enable-deflate --with-zlib=/usr/lib/ --enable-proxy --enable-cache --enable-mem-cache --enable-file-cache --enable-disk-cache

4. 빌드를 한다.
=> make

5. 모듈이 만들어졌는지 확인한다.
./modules 디렉토리에 mod_cache.so, mod_file_cache.so, mod_mem_cache.so가 있는지 확인한다.

6. 설치를 한다.
=> make install

7. /env/apache2/cache 디렉토리를 생성한다.
=> mkdir /env/apache2/cache

8. 캐쉬 서버 설정을 한다. /env/apache2/conf/vhost-proxy.conf 파일에 다음을 추가한다.
LoadModule cache_module modules/mod_cache.so
<IfModule mod_cache.c>
  #LoadModule disk_cache_module modules/mod_disk_cache.so
  <IfModule mod_disk_cache.c>
    CacheRoot /env/pahache2/cache
    CacheSize 256
    CacheEnable disk /book
    CacheDirLevels 5
    CacheDirLength 3
  </IfModule>
  LoadModule mem_cache_module modules/mod_mem_cache.so
  <IfModule mod_mem_cache.c>
    CacheEnable mem /book
    MCacheSize 4096
    MCacheMaxObjectCount 100
    MCacheMinObjectSize 1
    MCacheMaxObjectSize 2048
  </IfModule>
</IfModule>

==
Proxy 서버와 함께 이용할때 유용하고, 특히 WebService등에서 변화 주기가 낮은 서비스에 대해서 이 Cache 기능을 사용하면 성능 향상에 도움이 될것 같다.

예를 들어 SOA시스템에서 서적 정보 조회,공지 사항 조회등과 같은 업데이트 주기가 긴 컨텐츠의 경우에는 막강 효과가 있지 않을까?

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 조대협 2007.07.24 16:24  댓글주소  수정/삭제  댓글쓰기

    아마. EP를 구축할때 서브 시스템에 대한 포틀릿 렌더링 타임이 많이 걸리는데.
    이걸 적용하는건 어떨까?
    포틀릿 자체에 캐슁 기능이 있어서 효용성이 떨어질까?
    코드 변경 없이 시스템 설정만으로 가능하다는것은 메리트가 있는데...
    왠지 EP와 Apache Proxy+Cache는 어느정도 효과가 있을듯.

  2. 조대협 2007.07.26 14:11  댓글주소  수정/삭제  댓글쓰기

    disk cache 사용시 cache directory를 만들어주고 httpd process user 가 write할 수 있는 권한을 줘야한다.

매니저 --> 리더
상황을 있는 그대로 본다 --> 상황의 가능성을 본다
일방 커뮤니케이션 --> 쌍방 커뮤니케이션
과정 계발 --> 인간 계발
일을 올바로 하자 --> 옳은 일을 하자
침체 --> 소생,성장
통치 중시 --> 관계 중시
방향 제시 --> 자유와 창의성 중시
패러다임 추종 --> 패러다임 전환 추구
제한된 시야 --> 넓은 시야
효율 중시 --> 효과 중시
종속되려고 애쓴다. --> 따라 잡으려고 애쓴다.
사실중시 --> 개념 중시
현실 중시 --> 가능성 중시
능력을 위임한다 --> 권한을 부여한다.
주어진 조건하에서 일한다. --> 조건을 계발하려고 노력한다.
구조 중시 --> 융통성 중시
받아들인다. --> 믿고 맡긴다.
안정성 추구 --> 과도기성 혼란은 적극적으로 수용

==
아직 배울께 많구만.. 읽으면서 어찌나 찔리던지.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. Jerry 2007.08.05 18:12  댓글주소  수정/삭제  댓글쓰기

    짧지만 강렬하구만...