Sun Developer Network 공식 블로그

 

많은 사람들이 IT업종을 선망하고 종사하고 있다. 하지만 알만한 사람은 IT를 3D업종이라고 말한다. (아마도 IT종사자들이 프로젝트의 공기에 쫓겨 밤샘 작업을 밥 먹듯이 한 덕분에 생긴 말 일 것이다.) 혹자는 신기술을 습득하기 위해서 평생 공부해야 하는 업종이라고 말한다. 즉, 경험으로 축적된 기득권이 인정되지 않는다. 날마다 엄청난 신기술이 쏟아져 나오고 있으며, 분야가 다르면 달나라 얘기인가? 할 때도 간혹 있을 것이다.
그럼 IT업종에 종사하란 말이야? 말란 말이야? 하고 의문이 생길 수 있을 것이다. 결론은, 그래서 매력 있고 아직 할 분야가 많은 곳이라고 말하고 싶다.

16년간 현장을 뛰고 있는 필자의 경험들이 자바로 시작한 여러분 혹은 IT의 여러 분야에 일하고 있는 여러분께 ‘이런 길도 있네… 이렇게도 될 수 있겠네.’ 라는 Case study도 되고 '할 수 있다'는 작은 용기가 되었으면 한다. COBOL시대에 IT를 시작한 선배로서 그로부터 시작된 경험이 이 험한 세상을 헤치고 나아갈 밑바탕이 되니 말이다. (기술이 아니라 경험이 말이다.)
앞으로 기술(Technology)은 더욱 급변할 것이다. 하지만 그 기술과 같이할 사람은 예나 지금이나 비슷한 것 같다. 그래서 어찌 보면 사람을 대하는 기술이 더욱 중요한 시대이다. 그러므로 IT를 글자 그대로 Information Technology로만 이해하면 '너무 순진한 접근이다'라고 감히 얘기할 수 있다.

각설하고…일단 나의 경험을 얘기하겠다.
IT에 발을 담그는 대부분의 신입 사원들은 프로그래머 혹은 개발자라는 직함을 달고 시작할 것이다. 즉 어떤 개발언어, 개발툴을 사용하든지 코딩이라는 걸 가장 먼저 시작하는 것이다. 나 역시 선배들이 작성한 프로그램 설계서를 받아 들고 설계서에서 원하는 output을 만들기 위해 if then/else와 do while문과의 씨름이 시작되었다. 난 전산 비전공자이라(혹 이 글을 읽는 분들 중 전산 비전공자가 있다면 위로 받으세요… 우린 성공할 수 있어요!! ^ ^) 컴퓨터 내부에서 프로그램의 요구사항(request)을 받아 처리해 주는 대상(Server)에 대해 너무나도 궁금하였다. (아마도 이런 나의 호기심이 나를 프로그래머에서 DB전문가로써의 도약을 가능하게 한 것인지도 모른다.) 특히 방대한 데이터를 수록하고 있는 DBMS가 어떻게 동작하는지, 어떤 구조로 되어 있는지, 어떻게 동작하여 프로그램에서 요구하는 데이터를 주는지 등 알고 싶은 것이 무척이나 많았다.

DB전문가

1990년은 RDBMS(그때 IBM의 DB2을 처음 사용하였다.) 사용이 초창기였으므로 이것저것 영어 매뉴얼을 뒤지며 어렵게 어렵게 공부하며 프로그래머가 볼 수 있는 DB분야부터 공부하였다. 지금식으로 말하면 query tuning(SQL tuning)과 query plan의 생성원리 및 해석 등에 관해 먼저 공부한 뒤 점점 DB engine core까지 공부하게 되었다. 급기야 같은 회사 내에 RDBMS를 지원하는 팀으로 자리를 옮겨 개발자에서 DB지원 엔지니어로의 변화에 성공하였다. 대부분의 팀원들이 DB관련한 고객지원을 맡았지만 공교롭게도 개발자였다는 이력으로 프로젝트에서 DBA나 DB성능튜닝 및 데이터 모델링까지 맡는 행운(?)이 겹쳐 엄청난 고생을 마다하지 않았지만 그 경험이 지금 나의 밑바탕이 되었다.

일반적으로 규모가 큰 프로젝트에서 DBA는 PM의 참모역할을 수행하여야 하며 품질보증 팀과도 밀접하게 협력하여야 한다. 모든 프로젝트에서 발생하는 품질 상의 위험요소를 줄이기 위해서는 설계과정이 중요한데, 특히 DB분야는 논리설계(데이터 모델링)논리설계와 그 모델을 물리적으로 시스템에 잘 반영하여 구축하여야 한다. 이름하여 물리설계를 통한 DB구축 작업이다. 항상 그러하듯이 고객의 요구사항은 시도 때도 없이 변경된다. 이를 최대한 데이터 논리 모델에 빠짐없이 잘 반영하고 유연하게 모델을 만들어 최대한 변화에 적응하도록 설계해야 된다. 그래야 개발자들이 Table schema가 왕창 바뀌어 겪어야 하는 엄청난 수정 작업을 막을 수 있고 두고 두고 잘 사용할 튼튼한 DB구조를 만들어야 한다.
DB설계는 정답이 없다. 하지만 시간이 지날수록 잘된 설계와 못된 설계는 개발 및 유지보수에 엄청난 영향을 미친다. 잘못 지어진 집에 아무리 지지대를 세우고 시멘트를 덧바른들 무슨 소용이 있을까? Query튜닝으로 성능을 극복하는 것도 한계가 있음을 명심하자. 이 글을 읽는 DBA지망생들 잘 기억해 두시기를…

IT운영 프로세스 컨설턴트

DB전문가로서의 역할에서 난 또 새로운 변화를 시도하였다. IT운영 프로세스 컨설팅이라는 새로운 일을 시작하였다. 이제 우리는 IT도 서비스라고 부르는 시대에 살고 있다. 많은 기업들이 IT부서를 자신의 핵심역량에서 제외시키고(IT부서가 핵심 역량이든, 아니든) 이를 외부에서 조달하는 아웃소싱 정책을 고려하고 일부 도입하고 있다. 우리의 고객은 자신들이 원하는 수준의 IT서비스를 보장 받기 위하여 IT지원업체와 SLA(Service Level Agreement)를 맺고 그에 상응하는 돈을 지불한다. IT지원업체와 고객은 정기적으로 SLA에 준하는 서비스가 제공되었는지를 평가하고 있다. (SLA관련 분야도 향후 많은 전문 인력이 필요한 곳이다.)

이러한 IT서비스를 고객이 바라는 수준, 하나의 예로 서비스 가용성(24시간 X 365일 동안 비즈니스와 관계된 업무 중단이 발생하지 않는 가동상황을 유지) 99.6%을 만족하기 위해서는 크게
1. 무정지 서비스를 위한 아키텍쳐설계
2. 무정지를 위한 신 기술 적용
3. 통합운영 관리 체계 구축
등을 들 수 있다.
이 중 IT운영 프로세스 컨설팅은 '3. 통합운영관리 체계 구축'과 밀접한 관계가 있다.
IT서비스의 라이프사이클을 보면 고객의 요구에 의해 설계 -> 개발 -> 테스트 -> 가동 -> 운영 -> 유지보수 기간을 거쳐 최종 폐기될 때까지의 인생을 산다. 이 모든 단계에는 관련 프로세스(절차)가 있으며 이 중 운영단계를 중심으로 IT운영에 필요한 프로세스들을 진단하고 정립하는 컨설팅이 IT운영관리 컨설팅의 일이다. 참고로 요즘 ITIL(IT Infrastructure Library)를 기반으로 하는 IT운영관리 컨설팅이 뜨고 있다.

IT운영관리 컨설팅을 하려면 IT라이프 사이클을 이해하고 각 단계별로 필요한 프로세스와 프로세스간의 관련성을 잘 이해하여야 하며 IT조직과 인력에 대한 깊은 이해도 필요하다. 물론 IT 아키텍쳐 분석 능력과 관련 요소기술까지도 섭렵하면 금상첨화이다. 고객 시스템이 Mainframe구조이거나 Client/Server 구조이거나 Web형태 혹은 혼합형으로 제공되더라도 IT운영 프로세스는 동일하게 적용되어야 한다. 그러므로 이러한 구조들에 대해 충분히 이해해야 한다.

IT운영관리 컨설팅은 DB를 중심으로 시스템에 대한 좁고 깊은 나의 경험을 IT전반에 걸친 다양한 경험과 기술을 필요로 하는 IT Architect로써 꿈을 꾸게 했다.

IT Architect

'Architect' 참 생소한 용어이다. IT 프로젝트에서 Architect라는 역할을 본 적이 있는가? 아님 IT조직에서 그런 역할을 본 적이 있는가? 최근 EAP(Enterprise Architecture Planning)을 도입한 국내 몇몇 기업에서 그런 역할을 하는 사람이 있다고는 하지만 필자도 직접 만나 본 적은 없다. 'Architect'란 '건축가,설계자'라는 사전적 의미가 있다. 즉 건축물을 짓기 위한 설계도를 만드는 사람이다. 설계도란 '짓고자 하는 건물을 약속된 기법으로 표현하여 누구나 가 이해할 수 있게 제작한 것' 이다. 이를 IT에 적용해 보아도 무방할 것이다. 즉 IT의 Architect란 IT의 설계도(Architecture: 기업의 IT구조를 Top-down으로 추상화 하여 묘사한 것)를 만드는 사람이다.

내가 봐도 너무 어려운 정의들이다. 독자들에게 쉽게 이해될 수 있게 Architect 필요성을 살펴보자. 신기술의 폭주, 기업들간의 경쟁이 심화, 계속 짧아지는 제품의 라이프사이클, 비즈니스의 복잡성 증대 등은 IT 프로젝트의 성공을 점점 어렵게 만들고 있다. 그렇기 때문에 각각의 기술 요소들에 대한 충분한 지식과 경험을 바탕으로 프로젝트 전반에서 비즈니스 요구사항에 부합하는 최적의 기술적인 판단을 수행하는 역할이 필요하다. 아마도 이런 역할을 Architect 해야 되지 않을까?

Architect는 시스템의 모든 중요한 구성 요소들을 이해하고 있으며 또한 구성 요소간 상호 작용을 이해해야 한다. 물론 각 부분별로 미세한 곳까지 알 필요는 없다. 중요한 것은 시스템의 핵심을 이해하고 그것들이 원활하게 유기적으로 상호 작용할 수 있는 아키텍처를 구축하는 것이다. 잘 설계된 시스템의 아키텍처는, 프로젝트의 시작부터 성공의 가능성을 증대 시켜 준다. 하지만 잘못 설계된 아키텍처는 반드시 프로젝트의 고통을 유발하며, 그 하위 요소들에 쏟은 모든 노력, 그리고 엔지니어 및 개발자의 개인적 희생에도 불구하고 프로젝트의 실패를 가져오게 될 것이다. 이것이 아키텍처의 중요한 점이다.

꿈꾸는자 꿈은 이루어진다

'Architect' 개발자로서, DB전문가로서, IT운영관리 컨설턴트로서의 내가 지금 꿈꾸고 있는 타이틀이다. 아직까지 IT Architect를 위한 특별한 교육과정이나 Career Path가 있지는 않다. 하지만 IT에 대한 넓은 분야의 다양한 경험을 배경으로 끊임없는 기술 습득과 IT에 대한 열정이 있어야 한다고 생각한다.
제대로 된 Architect가 되는 것이 얼마나 어려운 길인가를 어렴풋이 알고 있다. 하지만 분명 목표로 삼기엔 충분히 가치가 있는 분야이다.

꿈꾸는 자에게 꿈은 이루어진다.
여러분들도 자신의 꿈을 위하여 지금의 어려움과 고생을 마다하지 말라. 실전에서 몸으로 부딪치고 익혀라 그리고 이론으로 다져라. 어떤 분야든 현재의 위치에 만족하지 말고 변화하고 도전하라.
그것이 다 꿈을 이루는 토양이 됨을 잊지 말자.

2005년도는 꿈을 꾸는 자, 꿈을 이루기 위해 한 걸음 다가가는 해가 되기를 바란다.