[지디넷코리아]마이크로소프트웨어의 ‘이럴 땐 이런 소프트웨어’ 코너를 통해 약 일년간 프로젝트 진행시 사용되는 소프트웨어들을 살펴봤다.

개발자가 다루어야 하는 소프트웨어라면 대부분 개발에 사용되는 언어와 관련한 도구들을 떠올리지만 실제 프로젝트에 있어서는 언어를 사용한 코딩보다 훨씬 큰 영역에 걸친 작업들이 필요하고 그 영역의 넓이만큼이나 다양한 소프트웨어 도구들이 제공되고 있다.

이런 시각에서 프로젝트 진행 중 해야 할 일들을 먼저 보고 이를 돕는 도구를 알아보는 일반적인 흐름에서 벗어나, 반대로 도구를 먼저 살펴보고 프로젝트 진행시 이런 일들을 해야 한다는 역전된 흐름으로 접근을 시도해 왔다. 이번 글에서는 지금까지 다루지 못했던 영역에 속한 소프트웨어이거나 타 소프트웨어와 함께 다루기에는 다소 이질감이 있어서 글에 싣지 못했던 소프트웨어들을 업무와 상관없이 살펴보고자 한다.

내 프로젝트의 규모는 얼마인가? FP Recorder Lite
프로젝트의 시작으로 봐야 하는 시점은 언제일까? SI 업체의 영업 담당자라면 영업과 관련한 정보를 전달받은 시점일 것이고, 발주 업체의 담당자라면 발주할 계획을 세우는 시점이 될 수도 있을 것이다. 원론적으로 이야기하면 소프트웨어에 대한 특정 요구가 발생한 시점이 프로젝트의 시발점이 될 것이다.

일반적으로 계약을 전후해서, 또는 요구사항 수집 단계를 전후해서 일정 수준 이상의 프로젝트 관리가 시작된다. 하지만 해당 프로젝트를 수행하는 것이 타당한지를 검토하는 작업이 이에 앞서 선행돼야 하고, 대부분의 타당성은 예상되는 ‘비용‘이라는 요인으로 판단될 수 있다. 수주/발주 관계에 있어서도 프로젝트의 규모와 비용은 중요한 의사결정 요인이다(전산 관련 직종에 발을 담그고 있는 직장인이라면 어떤 일을 하는 데 얼마나 드냐는 질문 한두 번 이상은 들어보았을 듯싶다).

이러한 비용을 산정하는 방법 중 전통적인 인/월 방식(Man/month), 코드 라인 수 기반 방식 등이 여전히 많이 사용되고 있으나 이들의 비용 산정 방법이 원시적이고 적합하지 못하다는 사실 또한 오래전부터 알려져 왔다. 이를 대체하는 방법으로 각광받고 있는 것이 기능 점수(function point) 산정 방식으로 최근 정부의 소프트웨어 사업 대가 산정도 기능 점수를 기준으로 변경됐다(이전의 소프트웨어 사업 대가 기준도 기능 점수의 개념은 일부 포함하고 있었다).

기능 점수는 생산해내는 코드의 양보다 소화해내야 할 요구사항 위주의 정보에 기인한다는 특성이 요구사항 중심의 프로젝트 관리가 강조되는 추세와 일맥상통한다는 점 등 많은 장점을 제공하고 있어 기능 점수를 도입하는 사례가 늘고 있는 상황이다. 기능 점수에 대한 상세한 정보는 참고자료를 참조하기 바란다.

기능 점수는 내부 파일(Internal Logical File : ILF), 외부 연계 파일(External Interface File : EIF)의 데이터 기능과 입력 기능(External input : EI), 출력 기능(External Output : EO), 조회 기능(External Inquiory : EQ)의 트랜잭션 기능의 수와 이에 대한 조정치를 반영해 프로젝트의 규모를 계량한다. 프로젝트라는 단어 자체에 세상에 동일한 프로젝트는 존재하지 않는다는 의미가 포함되어 있으니 유사한 사례에 대한 정보는 얻을 수 있으나, 진행하고자 하는 프로젝트에 대한 정확한 기능 점수를 제공하는 프로그램을 찾을 수는 없을 것이다.

하지만 요구사항에 근거하여 예상되는 기능들을 손으로 세고 계산기 혹은 스프레드시트 등을 이용해 점수를 계산하고, 조정치를 변경해보는 작업 등을 도와주는 프로그램은 여러 제품이 소개되고 있다. 이 중 무료로 사용할 수 있고 기능 점수에 대한 개념만 이해한다면 손쉽게 접근할 수 있는 소프트웨어가 FP Recorder Lite이다.

기능은 이름 그대로 기능 점수 FP를 기록하는 프로그램이다. 데이터 기능의 파일과 트랜잭션의 개수를 세고 조정치를 적용하는 간단한 도구이지만 기능 점수의 개념을 빠짐없이 반영하고 있고, 간단한 통계 정보까지 제공해주는 프로그램이다. 제작사에서 라이트 버전은 무료로 제공하며, 상용의 프로 버전을 판매하고 있다.

현재 기능 점수를 이용한 규모, 비용 산정과 관련한 CFPS라는 전문가 자격증이 있으며, 온라인 웹 기반 산정 프로그램 또는 컨설팅 서비스 등도 확산되고 있다. 기능 점수 관련 사이트에서 유사한 프로젝트 사례를 살펴보고, 도구를 이용해 직접 규모를 산정하는 것도 개발자가 스스로의 가치를 높이는 일이 될 것이다.

<화면 1> FP Recorder Lite의 실행 화면

ERD 채점관, Data Model Validator
관계형 데이터베이스를 데이터 저장소로 사용해본 개발자라면 ER-Win이라는 엔티티 관계 모델을 갖고 관계형 데이터베이스를 설계하는 프로그램을 직간접적으로 접해보았을 것 같다.

적어도 국내에서는 관계형 데이터베이스 설계 도구의 대명사가 되어버린 ER-Win이라는 프로그램을 판매하고 있는 CA의 데이터베이스 설계 관련 제품군을 살펴보면 Data Model Validator(이하 DMV)라는 프로그램이 포함되어 있다(이전의 제품명은 ER-Win Examiner였다). 이름 그대로 엔티티 관계 모델에 근거하여 설계한 데이터 모델이 적합하게 설계되었는지를 자동으로 평가하는 기능을 제공하는 프로그램이다.

관계형 데이터베이스 시스템 내에 한 손으로 셀 수 있는 개수의 테이블이 포함되고 이들의 관계가 비교적 간략하다면 손으로 설계하고, 검증하는 일이 그리 어렵지 않을 수 있을 것이다. 하지만 수 십 개의 테이블을 포함하는 업무 영역을 몇 개씩 지원하는 시스템이라면 설계에도 이를 지원하는 소프트웨어 도구의 힘을 빌리는 것이 당연시된다.

엔티티 관계 모델을 기반으로 설계를 지원하는 ER-Win, 비지오 등 많은 소프트웨어들이 일정 수준 이상의 규칙을 강제해 설계자로 하여금 기본적인 엔티티 관계 모델의 규칙을 따를 수 있도록 해 주지만, 여전히 정규화되지 않은 테이블과 관계들, 동일 속성에 대한 자료형의 차이, 관계 누락 등과 데이터베이스 제품의 특성을 고려해야 하는 물리적 설계 단계에서 발생할 수 있는 문제점 등은 여전히 포함할 수 있다. DMV는 이러한 설계상의 문제점과 취약점, 그리고 이상하다고 판단되는 부분들을 자동으로 찾아주는 소프트웨어이다.

ER-Win에서 설계된 ER-Win 파일 또는 데이터베이스 내에 테이블 등을 생성하는 스크립트를 읽어와 해당 모델에 대한 정규화, 자료형, 길이 등 컬럼 속성, 인덱스, 관계, 제약 조건 등을 자동으로 평가한다. DMV의 평가 결과 중 역정규화 결과, 읽기 전용의 코드 테이블 등과 같이 설계자가 의도적으로 수용하고자 한 규칙에서 벗어난 사항은 무시하고, DMV가 제공하는 보고서를 참고하면 설계한 데이터 모델의 문제점, 취약점 등을 살펴보고 이를 제거하는 것으로 보다 양질의 모델을 획득하고, 모델 평가에 필요한 기계적인 업무들을 컴퓨터라는 기계를 통해 수행할 수 있는 것이다.

동일한 속성에 대해 키 관계가 지정되지 않은 설계상의 실수 또는 일부러 키 관계를 지정하지 않은 동일한 속성들의 자료형과 크기, 기본 값 등을 일일이 찾아내 비교하는 것은 결코 창의적이라고는 할 수 없는 일이다. 수 십 페이지의 문서에서 타이핑 실수, 또는 외래어의 한글 표기가 일관성 있게 한글로 표기되었는지 등을 살펴보는 일과 비슷한 일일 수 있다.

DMV는 데이터 모델에 대한 평가라는 기능뿐만 아니라 이 평가를 신속하게 해준다는 생산성을 겸비한 소프트웨어라 할 수 있다. 또 DB2, MS SQL 서버, 오라클 등 상용 데이터베이스 제품의 특성을 고려한 평가를 수행하므로 익숙하지 않은 데이터베이스를 대상으로 데이터베이스의 물리적 설계를 수행하는 경우에도 큰 도움을 받을 수 있는 소프트웨어이다.

둘 이상의 데이터베이스에서 에러 없이 실행되는 생성 스크립트라도 해당 데이터베이스 제품의 특성을 충분히 반영하고 있지 못한 부분이 있다면 DMV를 통해 일정 수준 이상 확인 가능하다. 프로젝트의 한 단계를 끝내고 돌아봄 없이 다음 단계로 넘어간다면 프로젝트의 전체를 살펴보고 간다고 할 수는 없을 것이다. 테스트라는 단계를 거치며 소프트웨어의 품질이 높아지듯이 데이터 모델 설계라는 한 단계를 마치고 이를 평가해 볼 수 있는 DMV 같은 도구들을 운용하는 것 또한 품질을 획득하고 보장하는 하나의 수단이 되어 줄 것이다.

<화면 2> DMV의 실행 화면

<화면 3> DMV의 보고서 화면

MDA 모델을 J2EE 컴포넌트로, AndroMDA
최근 들어 마소에서도 MDA(Model Driven architecture)에 관한 기사를 자주 접할 수 있게 되었다. 시스템 설계자 또는 프로그래머의 시각에서 바라본 MDA에 내포된 설계에 대한 구현이 곧 프로그래밍이고 이런 이유로 설계도를 그리면 자동으로 생성되는 실행 코드에 대한 논의와 시도, 문자 그대로 그리는 프로그래밍에 대한 이야기가 결코 근래 들어 나오는 이야기들은 아니다.

오히려 객체지향, 컴포넌트 기반 기술의 발달과 높은 수준의 프레임워크, 또는 표준화된 아키텍처를 제공하는 개발 환경의 등장 등에 힘입어 개발자는 설계를 하고 실행 프로그램은 컴퓨터가 만들어내는 일이 근래에 현실로 다가왔다고 하는 것이 더 정확할 것이다. 최근의 CASE(Computer Aided Software Engineering) 도구들도 J2EE 또는 닷넷 환경에 기반하여 모델을 그리면 실행 코드를 생성하는 기능들을 제공하는 추세이다.

AndroMDA(홈페이지에 안드로메다 성운의 이미지가 포함되어 있는 것으로 봐서는 안드로메다라고 읽지 않을까 싶다)를 한마디로 정의하면 UML로 작성된 모델에 기반하여 J2EE 실행 코드를 자동으로 생성해주는 코드 생성 프레임워크라고 할 수 있겠다. 프로그램 이름에 MDA라는 단어를 포함하고 있고 MDA 도구를 표방하고 있는 소프트웨어라 MDA 개념을 이야기했지만, 코드 생성 프레임워크라는 기능을 위주로 살펴본다면 프로그램에 대한 보다 쉬운 이해가 가능할 것이다.

먼저 모델을 작성한다. 모델 작성은 IBM Rational Rose, 볼랜드의 Together 등 CASE 도구에서 UML로 작성한다. AndroMDA에서 이러한 CASE 도구의 고유 파일을 읽어들이는 것은 아니며 CASE 도구에서 XMI(XML Metadata Interchange) 표준에 따라 UML의 내용을 XMI 포맷 파일로 저장하고, AndroMDA는 XMI 포맷 파일을 해석해 템플릿과 XDoclet 코드 생성 엔진을 이용해 JBoss 등의 실행 환경에 탑재할 수 있는 클래스, 빈 등을 자동으로 생성해낸다.

이미 AndroMDA와 유사한 기능을 제공하는 어찌 보면 이를 능가하는 유명 업체의 CASE 도구들이 있고, 오픈소스의 경우도 OpenMDX 등 MDA 도구 소프트웨어들이 속속 소개되는 상황에서 AndroMDA에 대한 글을 싣는 이유는 AndroMDA 또한 오픈소스프로젝트로 진행되고 있고, UML을 통한 모델 작성에서 실행 코드 생성까지의 전 기능을 제공하는 상대적으로 무거운 소프트웨어가 아닌 코드 생성이라는 적은 범위의 목적에 충실하고 다른 영역은 다른 소프트웨어에게 맡기는 작음과 가벼움을 담고 있는 소프트웨어이기 때문이다.

AndroMDA의 현재 버전은 2.1X대이며 3.0 버전을 향해 가고 있다. 3.0 버전에는 모델 수준에서의 리팩토링, EJB 지원 강화, JDO(Java Data Object), 이클립스 내에서의 코드 생성 수행 등의 기능이 포함될 것으로 알려져 있다.

<화면 4> AndroMda 홈페이지의 동작 방식 설명 화면

KDE 환경의 UML 모델링 도구, Umbrello
AndroMDA의 경우 UML 모델이 어떤 프로그램에서 그려졌는가와 무관하게 XMI 포맷 파일을 통해 모델 정보를 전달받는다고 설명했다. 또한 결과로 만들어지는 클래스, EJB 파일들은 OS로부터 자유롭다고 할 수 있는 자바 실행 파일들이다. 굳이 윈도우 환경에 국한하지 않아도 될 법한데, 문제는 윈도우 환경에서 UML 모델 작성을 가능하게 해주는 프로그램들 위주로 시장이 형성되어 있다는 점이다.

리눅스에서 동작하는데 전혀 문제없는 실행 파일을 작성하기 위해 리눅스에서 모델을 작성할 수 있는 도구는 빈약한 것이 현실이다. Umbrello는 KDE 환경의 UML 모델링 도구로 KDE 환경이 구현된 리눅스 또는 유닉스에서 UML 모델링을 수행하고자 하는 개발자들에게 유익한 도구가 되어 줄 것이다. 상용의 UML 모델링 도구와 비교하면 연계, 부가 기능 등이 부족한 것은 사실이나 모델링 작업을 독립적으로 수행하는 데에는 부족함이 없는 오픈소스 프로그램이다.

초기 버전의 C++, 자바, PHP 코드 생성 기능에 더해 현재 버전(글을 쓰는 현재 1.3 베타 버전이 소개되어 있다) Perl, 파이썬, Ada, 자바스크립트, IDL 코드 생성 기능을 제공하며, 앞서 언급한 XMI 표준 지원 기능, SVG 포맷 파일 저장 기능 등을 포함하고 있다. XMI 지원 기능의 경우 아직 완전하지는 않은 상황으로 타 UML 모델링 프로그램과 자료 호환시 문제점들이 이야기되고 있는 상황이다(Umbrello에서 생성된 XMI 파일을 AndroMDA에서 테스트해본 것은 아님을 밝혀둔다). 1.3 정식 버전이 릴리즈되는 시점이면 이런 문제점들도 해결되기를 기대해 본다.

닷넷용 ORM 도구, Olero
ORM(Object Relational Mapping : 데이터베이스 모델링 방법의 하나인 Object Role Modeling과 약자가 같다)은 객체를 관계형 데이터베이스에 영구히 저장하고자 할 때 발생하는 불일치를 해결 또는 고려하여 객체 정보 유실 없이 관계형 구조 속에 저장되도록 하는 업무라 할 수 있다.

단순히 생각하면 객체가 갖는 속성을 테이블의 속성으로 일대일 맵핑이 가능할 것 같으나 적지 않은 불일치가 발생한다. 예를 들면 학생이라는 객체와 수업이라는 객체를 고려하면 한 학생이 여러 수업을 들을 수 있고, 수업에는 여러 학생이 참여할 수 있으며, 경우에 따라서는 동일한 수업을 2회 이상 듣는 학생이 있을 수도 있다.

이러한 복잡한 다대다 관계라면 객체의 경우 Array와 같은 자료형으로 수업 목록 또는 수강생 목록을 가지고 있을 수 있으나 관계형 테이블에는 하나의 컬럼에 하나의 속성만 저장할 수 있다. 물론 OODBMS를 저장소로 사용하거나, ORDBMS를 제공하는 Array 자료형으로 컬럼 속성을 지정하거나, N:M 관계를 1:N,M:1 관계를 갖는 관계 엔티티를 추가해 해결할 수도 있다.

하지만 분명한 것은 객체지향 애플리케이션의 객체(object)와 관계형 데이터베이스의 객체(entity)가 일대일로 대응하지는 않으며 객체 정보, 상태를 영구히 저장하기 위해 관계형 데이터베이스를 사용하고자 하는 경우는 분명히 맵핑 작업을 수행해 주어야 한다는 점이다. 자바의 경우 JDO 혹은 EJB를 지원하는 다양한 ORM 도구들이 소개되고 있고, IDE 환경을 제공하는 대부분의 프로그래밍 도구들 또한 이를 지원한다.

반면 닷넷의 경우 상대적으로 이러한 도구들이 적은 편인데, 자바와 다르게 데이터를 담는 객체가 ADO.NET 형태로 거의 확정되어 있는 것도 도구들이 적은 하나의 이유가 될 것 같다. Olero는 닷넷 전용의 ORM 도구로 여러 형태로 데이터를 다룰 수 있는 자바 환경에 익숙한 개발자가 본다면 상대적으로 제한적인 닷넷의 데이터 접근 코드를 자동으로 생성하고, 스토어드 프로시저 등의 재사용이 가능하도록 해주는 기능 등을 제공하는 컴포넌트 정도로 Olero를 인식할 수도 있겠으나 Olero 홈페이지에 인용한 가트너 그룹의 주장처럼 프로그램의 40%를 차지하는 데이터 접근 관련 코드를 자동 생성하는 것만으로도 충분한 가치가 있는 프로그램이다. 현재는 오픈소스 프로젝트로 개발이 진행되고 있다.

<화면 5> Olero 홈페이지의 샘플 코드 화면

전문가다운 개발자를 꿈꾸며
‘이럴 땐 이런 소프트웨어’를 통해 줄기차게 이야기해온 것이 개발자는 알아야 할 것이 정말 많다는 것이었다. 일반적으로 전문가 혹은 스페셜리스트라고 하면 ‘한 우물을 깊게 판 사람’을 지칭하는 듯하다. 하지만 소프트웨어 개발자로서 전문가라고 불리기 위해서는 다른 영역의 전문가들이 파는 깊이만큼 여러 영역에 지식의 우물을 파야 한다.

게다가 영역과 영역간의 관계, 비유하자면 우물 아래의 지하수의 흐름까지 알고 있어야 한다. 공부하는 개발자로서의 모습을 잃지 않는 것이 전문가로서 인정받을 수 있는 개발자의 첫 번째 조건이 아닐까 하는 생각과 함께 글을 마친다. @

* 이 기사는 ZDNet Korea의 자매지인 마이크로소프트웨어에 게재된 내용입니다.