[열린마당]정보화, 아키텍처로부터

　정보화의 성패는 큰 그림을 얼마나 잘 그리느냐에 달려 있다. 단위 시스템 개발에 앞서 조직의 비즈니스와 전략적 목표에 맞는 큰 그림을 우선 그리고 이에 입각해 해나갈 일들을 순서대로 하자는 뜻이다. 이에 우리나라 대부분의 조직에서도 지난 10여년 동안 정보계획수립(ISP)과 같은 노력을 빠짐없이 수행해왔다.

　이런 정보계획수립 노력을 통해 우리는 목표를 얼마나 달성했는가. 여기에 대한 대부분의 응답은 별로일 것이다. 여전히 시스템은 중복투자되고 시스템간의 상호운용성은 떨어지고, 정보기술의 변화에 따라 시스템을 재구축하는 등의 문제점은 계속 반복되고 있다. 애써서 만들어놓은 ISP 보고서는 아무도 찾지 않는 채로 책장에 자리잡고 있는 것은 아닌지.

　이 보고서에는 ‘구축해야 할 시스템은 이런 기술과 제품으로 구축하는 것이 좋다’는 식의 표현만 있지 우리가 나아감에 있어 지킬 만한 원칙과 기준, 모델, ‘주어진 목적을 달성하기 위한 여러가지의 시스템적 대안, 이들 여러 대안 가운데서 하나를 선정함에 있어 활용할 만한 참조모델과 판단근거 등이 빠져 있다. 이러다보니 몇달만 지나도 그 보고서의 내용은 더 이상 준거자료로 활용되기 힘들게 된다.

　그러면 이런 문제를 근본적으로 해결하기 위한 대안은 무엇인가. 바로 아키텍처 노력이다. 여기서 아키텍처란 조직의 전략적 방향과 정보기술이 변화하는 속도에도 불구하고 크게 변화되지 않을 요소들로 묘사해놓은 실체를 말한다. 앞에서 예로 든 원칙과 기준, 모델, 대안, 참조모델, 판단근거 등이 여기에 해당한다. 정보화 노력은 이런 아키텍처의 수립에서 시작해야 한다는 것이다.

　엔터프라이즈 아키텍처(EA)는 업무와 애플리케이션, 정보, 그리고 기술 아키텍처를 모두 포함하는 개념이다. 일각에서는 이 엔터프라이즈 아키텍처 대신 ITA라는 용어를 사용함으로써 정보기술 중심으로만 보고 업무부문을 의도적으로 배제하려는 시도가 있으나 이는 잘못하면 큰 오류를 불러일으킬 수 있다고 본다.

　예를 들면 조직 ‘갑’은 A시스템을, 조직 ‘을’은 B시스템을 각자 개발하려 한다고 하자. 기술적 관점에서는 A와 B시스템에 공통적으로 적용할 수 있는 기술구성 요소를 파악함으로써 시스템간의 상호연동성을 꾀할 수 있을 것이다. 그러나 더 우선되어야 할 것은 이 두 시스템이 따로 개발되어야 할 필요가 있는지를 검토하는 일이다. 이를 위해서는 각 시스템의 지원대상인 ‘갑’의 업무와 ‘을’의 업무를 검토해보고 만일 같은 종류의 업무라면 따로 구축할 필요없이 하나의 시스템으로 두 조직에 활용하면 된다. 이럴 경우 비용절감뿐만 아니라 상호운용성도 자동적으로 이뤄진다. 실제 미국 정부는 정보화 예산 배정시 유사한 업무를 갖고 있는 두개 이상의 기관에서 해당 업무를 위한 시스템의 구축을 위해 공동 프로젝트를 신청할 경우 최우선권을 주고 있다.

　사실 엔터프라이즈 아키텍처 노력에 대해 국내 공공기관 및 민간기업들 모두 상당한 부담감을 느끼는 것 같다. 한꺼번에 아키텍처의 모든 내용을 수립하기 위해서는 너무 많은 노력과 시간이 투입될 것으로 우려하는 것이다. 그러나 아키텍처 노력은 정도의 문제다. 가급적 바로 수립하고 적용할 수 있는 아키텍처 요소부터 정의하면 된다. 아키텍처 도입 노력을 법으로 의무화한 미국 정부와 같이 우리나라도 이런 시도를 해볼만 하다.

　최근 정부 일각에서 논의되고 있는 ‘공공 정보기술관리 혁신법’이 그런 성격에 해당된다고 볼 수 있다. 다만 이 법안의 내용은 엔터프라이즈 아키텍처의 근본 목적에 부합되게 구성돼야 할 것이다.

　정보화에 필요한 큰 그림은 몇사람에 의해 아무렇게나 그려진 그림이 아니라 조직적인 노력을 통해 잘 짜여진 틀 안에서 만들어진 구체적인 밑그림이 되어야 한다. 엔터프라이즈 아키텍처 노력은 바로 이와 같은 정보화 밑그림을 그리는 노력이다. 정보화를 정보기술 중심으로만 본다거나 또는 단위부처의 정보화 수준 향상에만 목적을 두어 부처간 정보화 연계 및 국민 입장에서 하나의 정부를 표방하는 전자정부의 효과적 구현에 기여하지 못하는 우를 범해서는 안될 것이다.

　

◆김성근 중앙대학교 전산정보처장 skim@cau.ac.kr