동반자지 경찰이 아니다

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 영어원문  제안 및 의견 피드백

난이도 : 초급

Kunal Mittal, Executive IT Director, Consultant

2008 년 6 월 10 일

이 기사에서 엔터프라이즈 아키텍트와 함께 일할 때 IT 팀이 직면하는 몇 가지 근본적인 도전에 대해 배우고, 바람직한 결과를 내기 위해 프로젝트 출시 과정에서 엔터프라이즈 아키텍처 표준을 응용 프로그램 개발과 협력에 적용하는 방법을 살펴보겠습니다.

엔터프라이즈 아키텍처(EA)의 역할이 바뀌고 있다. 서비스 지향 아키텍처(SOA, Service-Oriented Architecture), 웹 2.0, 그리고 기타 기술 적용은 소프트웨어 시스템 구축 방법을 바꾸고 있다. 전통적인 EA 개념은 SOA와 웹 2.0 전에 나왔다. 이런 전통 개념은 기민한 서비스 기반 개발보다는 대규모 응용 개발 프로젝트에 좀 더 적합하다.

하지만 이 기사에서는 웹 2.0과 SOA 개발이 EA에 미치는 영향을 다루는 대신 대규모 조직에서 EA 팀과 최전방 IT 팀이 협력하는 과정에서 나타나는 몇 가지 근본적인 도전을 설명한다. 이 기사는 EA 조직 구성, 관리 방법에 대한 공통적인 문제점을 지적하고 EA를 조직화하는 방법을 조언한다. 웹 2.0과 SOA를 설명하면서 이 모든 문제점이 어떻게 복합적으로 나타나는지 함께 살펴보겠다.

책임없는 권력

강력한 EA 팀을 구축했다는 장점에도 불구하고 종종 비즈니스를 위한 응용 프로그램 배포와 해법을 책임진 프로젝트 팀원과 엔터프라이즈 아키텍트 사이에는 긴장감이 흐른다. 이런 긴장감은 어디서 비롯되었을까?

많은 조직에서 EA 팀은 스스로를 의사 결정권자나 프로젝트 팀 위에 군림하는 승인 기관으로 여긴다. EA 팀은 프로젝트 팀에게 기술 플랫폼, 버전, 인터페이스와 통신, 소프트웨어 개발 공정을 포함한 프로젝트의 여러 측면을 승인 받도록 요구한다. EA 팀은 또한 프로젝트 상태 점검을 요구하기도 한다. 가상 시나리오를 하나 살펴보자.

예제: 웹 서비스를 활용해 응용 프로그램 두 개 통합하기

단독형 J2EE(Java™ 2 Platform, Enterprise Edition) 응용 프로그램 사이에 벌어지는 모든 통신이 웹 서비스를 통해 이뤄져야 한다고 주장하는 EA 팀을 본 적이 있다. 표면적으로는 말이 되는 요구 사항처럼 보인다. 하지만 프로젝트 팀은 웹 서비스를 통합할 경우 응용 프로그램 둘 중 하나가 성능 서비스 수준 계약(SLA, Service Level Agreement)에 미달되리라고 판단했다. 프로젝트 팀은 시스템 내부에 있는 자료를 기준으로 응용 프로그램 한쪽에서 다른 자료에 대해 조인(join) 연산을 하기로 결정했다. 그리고 나서 사용자가 웹 페이지에서 검색을 수행할 때, (양쪽 시스템에서 뽑은 자료인) 조인된 자료를 포함한 검색 결과를 출력하도록 비동기적 자바스크립트와 XML을 결합한 AJAX를 사용한다.

이런 단순한 시나리오에서, 웹 서비스가 적절한 통합 메커니즘일까? 그럴지도 모르고 아닐지도 모른다. 엔터프라이즈 아키텍트는 SLA를 고려하지 않았고 웹 서비스 통합을 강제하려 했다. 프로젝트 팀은 어쩔 수 없이 웹 서비스로 갔지만, 품질 보증이나 사용자 테스트 과정에서 성능 SLA를 달성하지 못했다. 프로젝트 팀은 하루 열두 시간씩 강행군을 통해 SLA에 맞춘 응용 프로그램을 제 때 배포하려고 노력하는 이야기로 끝난다.

이 경우, 웹 서버로 가자고 요구 사항을 강제하거나 결정을 내린 엔터프라이즈 아키텍트는 어디에 있는가? 대부분 흔적도 없이 사라졌다. 이게 바로 책임없는 권력이라는 고전적인 예다.

말도 안 되게 들릴지도 모르겠다. 하지만 여러분이 성숙한 EA와 함께 좀 더 큰 조직 내부에서 일해 온 프로젝트 팀원이라면, 아마도 익숙한 이야기로 들릴지도 모르겠다. 자문해 보자. 엔터프라이즈 아키텍트가 이런 문제를 해결하기 위해 내 옆에 앉아있지 않은 이유가 도대체 무엇일까?

해법: 소매를 걷어붙이고

해법은 단순하다(물론 행동보다 말은 쉽다). 엔터프라이즈 아키텍트는 권력과 프로젝트 배포라는 두 가지 임무를 맡아야 한다. 엔터프라이즈 아키텍트는 응용 프로그램 아키텍트와 나머지 응용 프로그램 팀처럼 프로젝트 배포에 책임을 져야 한다. 이런 임무는 단순히 표준 활용 정의와 강제에 그치지 않고, 더욱 중요하게는 프로젝트 팀이 이런 표준으로 일하도록 돕는 데 있다. 엔터프라이즈 아키텍트는 이런 시나리오에서 프로젝트 팀을 돕는 작업을 등한시해서는 절대 안 된다.

표준을 생성하고 모델링하고 문서화하는 작업만으로 충분하지 않다. 오히려 엔터프라이즈 아키텍트라면 표준을 적게 정의할지라도 프로젝트 팀의 결과물의 일부로 개발 팀을 지원할만큼 충분한 시간을 들였는지 확인해야 한다. 엔터프라이즈 아키텍트는 프로젝트 팀과 한 곳에서 일하거나 프로젝트 팀을 만나러 여행을 다닐 필요가 있다. 엔터프라이즈 아키텍트는 항상 개발자 옆에 있으면서 비즈니스, 기술, 정치적인 측면에서 개발 중인 프로젝트의 모든 측면을 완벽하게 이해해야 한다.

권한과 권력은 영향력에서 나온다. 엔터프라이즈 아키텍트는 프로젝트 팀과 튼튼한 관계를 맺어야 하며, 프로젝트 팀은 아키텍트를 진짜 동반자로 생각해서 문제가 발생했을 경우에 프로젝트 팀과 함께 작업하기를 기대해야 한다. 이런 접근 방법은 자연스럽게 엔터프라이즈 아키텍트의 핵심이 영향력과 권력이라는 사실을 이끌어낸다.

다음에 또 다른 가상 시나리오를 하나 소개하겠다.

예제: 응용 프로그램을 서비스로 정의하기

이번 예제는 EA 팀이 SOA에 대해 이야기를 시작하는 시나리오다. 새롭고 규모가 큰 프로젝트가 눈앞에 다가오고, 엔터프라이즈 아키텍트는 SOA를 선전할 기회로 여겼다. 엔터프라이즈 아키텍트는 이 응용 프로그램이 나머지 조직에 서비스를 제공하도록 서비스 형태로 만들기를 바랐다. 표면적으로 이성적인 기대다. 하지만 종종 엔터프라이즈 아키텍트는 프리사이즈 접근 방법을 제안한다. 엔터프라이즈 아키텍트는 요구 사항과 프로젝트 비즈니스 원동력을 이해하는 데 시간을 들이지도 않았으며, 세부 사항에 발을 담그지도 못했다. 프로젝트 개발 팀이 짜증을 낸 이유는 서비스를 제공하고 사용하는 이유와 방법에 대해 질문을 했을 때 회의에 참석한 아키텍트가 잠자코 있었기 때문이다. 개발자 관점에서 보면, 엔터프라이즈 아키텍트는 이론적으로 열심히 떠들지만 제품 인도 관련 압박이나 우선 순위는 이해하지 못한 듯이 보인다.

EA 조직을 운영하는 엔터프라이즈 아키텍트나 책임자가 이 글을 읽고 있다면, 아마도 우스꽝스러울지도 모르겠다. 여기서 든 예제는 너무 한쪽으로 치우치지 않았는가? 프로젝트 개발 팀 입장에서도 한 쪽으로 치우쳤다고 생각할지 모르겠다고?

아닌 쪽에 돈을 걸겠다. 이런 시나리오를 너무나 자주 보아왔으며, 프로젝트 팀이 비슷한 문제점으로 EA 조직을 불평하며, 정말로 심각한 문제점이라고 말하는 확신에 찬 목소리도 들었다. 여러 포천 500 회사가 이런 문제점을 다양하게 경험하고 있다.

그렇다면 이런 시나리오를 어떻게 고쳐야 하나?

해법: 비즈니스 이해

EA 팀 각 성원이 비즈니스를 이해해야 한다. 또한 비즈니스가 발전함에 따라 EA 표준과 관례도 따라서 발전해야 한다는 사실을 인식해야 한다. 비즈니스 발전은 IT 전략 변화를 포함해야 하며, 이렇게 해서 아키텍처 전략을 결정하는 데 도움을 줘야 한다.

여기서 핵심 단어는 프로세스, 지원, 방향 맞추기다. 엔터프라이즈 아키텍트는 개발 팀에 프로세스를 제공한다. 엔터프라이즈 아키텍트는 또한 이런 개발 팀을 지원할 필요가 있으며, 전략과 목표에 대해 각 프로젝트 이면에 있는 비즈니스 원동력과 방향을 맞춰야 한다.

이제 주제를 바꿔 전형적인 IT 조직이 실제 어떤 식으로 가야 할 방향과 반대 방향으로 움직이고 있는지 살펴보자.

위로

EA가 비즈니스와 방향을 맞추지 못한다

내가 인터뷰한 대다수 EA 팀은 비즈니스보다 기술에 좀 더 초점을 맞추는 듯이 보인다. EA 팀은 전략적인 IT 계획을 세우거나 비즈니스 부문 관련자와 인터뷰부터 시작하지만, 비즈니스 도입보다는 기술 도입을 우선하는 선에서 끝난다. 많은 EA 팀은 자료 센터 전략을 정의하고, 전자편지나 디렉터리 기술 도입, 획득, 기타 등등을 하느라 더 많은 시간을 보낸다. 오해하지 말기 바란다. 이런 기술 도입은 적절한 주의가 필요한 핵심 부문이다. 하지만 EA 관점에서 바라보면, 이런 기술 도입은 전술이지, 전략이 아니다.

또 다른 경우로, 나는 EA 팀이 로드 맵, 표준, SOA 전략을 정의하느라 고생하는 모습을 봤다. 이는 IT 조직에서 또 다른 중요한 활동 분야긴 하지만 이런 작업을 한다고 해서 진짜 EA 조직을 가치있게 만들까? 이런 작업은 IT에 영향을 미치지, 비즈니스에 직접 영향을 미치지 못한다.

누가 이런 과업을 수행하야 하며, EA 팀은 무엇을 해야 하나?

이는 올바른 대답이 없는 어려운 질문이다. 엔터프라이즈 아키텍트가 직전에 설명한 기술 활동과 기술 프로젝트에 참여하지 말하야 한다고 이야기하지는 않겠다. 이런 기술 활동은 반드시 필요하다. 하지만 기술 활동이 엔터프라이즈 아키텍트 임무의 전부가 되어서는 안 된다. 사람, 시간, 돈을 투입해 이런 기술 활동만 한다면 스스로를 엔터프라이즈 아키텍트라고 부르기가 민망하다. 만일 이런 작업을 반드시 진행해야 한다면, 이 기사 앞에서 설명한 문제점을 피하자.

많은 EA 팀이 비즈니스 최전방에 위치한 팀이 고부가가치를 창출하는 프로젝트를 출시하기 위해 협력하는 대신 자료 센터 전략을 정의하고 전자편지나 디렉터리 기술 도입과 획득에 더 많은 시간을 쓰고 있다. 팀원은 비즈니스 리더와 IT 팀원과 좀 더 강한 유대 관계를 맺어야 한다. 동반자지, 경찰로 생각해서는 안 된다. EA 팀의 입지는 비즈니스 의사 결정을 도와주는 일련의 도구와 서비스를 정의하는 데 있다.

날이 저물 무렵 EA 팀은 비즈니스 전략과 IT 구현 사이에 가교가 되어 있어야 한다.

위로

SOA가 적합할까?

SOA는 IT가 변화하는 비즈니스 주변 상황을 받아들이기 위한 기술이다. SOA 이면에 숨은 핵심 원동력은 비즈니스 기민성이다. 이런 생각에 동의한다면, 비즈니스를 지원하기 위해 EA는 비즈니스와 더불어 끊임없이 성장해야 함에 동의하는 셈이다. 엔터프라이즈 아키텍트는 비즈니스 아키텍처에서 일어나는 발전을 지원하기 위해 IT 전략을 끊임없이 새롭게 모델링하는 전문가가 되어야 한다.

SOA 세상에서(특히 웹 2.0 SOA에서), 여러분은 딱딱하게 굳어진 EA 프로세스, 지침, 프레임워크, 방법론이 저항받는 모습을 지켜보게 된다. 이런 저항을 극복하는 최선의 방법으로 엔터프라이즈 아키텍트가 기민한 방법으로 프로세스와 프레임워크를 정의하고 개발 팀과 동반자 관계를 맺도록 만들어야 한다. 여기서 내가 강조하고픈 내용은 프레임워크, 프로세스, 방법론, 통치 정책은 하나도 빠짐없이 본래부터 변화가 가능해야 하며 SOA, 웹 2.0, 그리고 다음에 나올 기술을 포용해야 한다는 점이다.

참고자료

• 최신 웹 2.0 기술을 적용하는 회사에 대해 알아보자.
  
  

• IBM 제품 평가판: DB2®, Lotus®, Rational®, Tivoli®, WebSphere®와 같은 응용 개발 도구와 미들웨어를 직접 다뤄보자.

• Inside Architecture Blog: EA가 웹 2.0을 활성화하는 방법을 읽어보자.
  
  
• EA와 웹 2.0에 대해 배우자.
  
  
• developerWorks 블로그를 읽어보고, developerWorks 공동체에 참여하자.
  
  

필자소개

		Kunal Mittal은 자바 기술, J2EE, 웹 서비스 기술 분야에서 전문 컨설턴트로 활약한다. Mittal은 이 주제에 대해 여러 책을 함께 집필했고, 집필에 도움을 줬다. Mittal은 소니 픽쳐스 엔터테인먼트를 위한 도메스틱 TV IT 그룹에서 관리자로 근무하고 있다. 여기서 Mittal은 해당 부서를 위해 기술 아키텍처와 응용 프로그램 관리를 책임지고 있다. 여가 시간에 Mittal은 IBM developerWorks에 기고하고, SOA 분야에서 컨설팅을 하며, 개인 비행기를 운전한다. 더 많은 정보가 필요하다면 웹 사이트인 www.kunalmittal.com이나 전자편지인 kunal@kunalmittal.com을 활용하기 바란다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

이 문서 북마킹 하기 mar.gar.in naver eolin del.icio.us

위로