https://www.securecoding.cert.org/confluence/display/java/The+CERT+Oracle+Secure+Coding+Standard+for+Java;jsessionid=B3FCF2EB9D0464376B0693ED791FD361

The CERT Oracle Secure Coding Standard for Java 의 내용을 참조하면, 자바로 코딩시에 필요한 보안규정과 안전을 위한 규범에 대해서 상사하게 기술되어 있다.

각각의 형태에 따라서, 규칙과 우선순위들이 잘 정리되어 있다.

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2013.12.18 09:26

2013년 현시대는 오픈소스를 사용하여 상용 패키지를 개발할 수 밖에 없는 환경을 만나는 것은 어찌보면 당연할 것이다. 하지만, 소프트웨어 개발자로써 최소한 라이센스와 저작권문제에 대해서는 충분하게 고려하고, 이를 자신이 속한 기업이나 자신이 만들어지는 소프트웨어에 명시해야하는 것은 매우 당연한 것이다.

상용 소프트웨어를 만들경우에 Apache License, X-Consortium, BSD 또는 Reduced(Revised) BSD-style license, MIT/X, MIT-style license로 명시되어진 라이센스만 사용하는 것이 원칙이다. 특히나, closed-software를 만들경우에는 해당 라이센스만 사용하여야 한다.

물론, 사용되어진 라이브러리나 소프트웨어를 저작권에 명시해야하는 것은 매우 당연하다.

하지만, 이러한 라이센스는 매우 제한적이며, 대부분의 오픈소스의 경우에는 GPL에 해당하게된다. 이 라이센스와 결합하여 만들어지는 상용 소프트웨어들은 무조건 모든 소프트웨어의 소스를 공개해야한다. 이 점을 어기게 되면 중요한 GPL을 위반하는 것이라는 것을 잊으면 안된다.

개발자들이 착각하는 것은 GPL과 MIT나 Apache라이센스와 결합할 경우에 GPL에 해당한다는 것을 이해하지 못하는 경우를 조심해야한다. 그리고, GPL 기반의 소프트웨어들은 대부분 소스를 공개하지 않으면, GPL에 의해서 저작권법 위반에 대한 소송을 받을 수 있다.

또한, 오픈소스를 이용한 특허는 원칙적으로 금지되어있다는 점이다. 당연하겠지만, 보통 특허는 단순하게 소스 자체가 아니라 알고리즘인 경우와 아키텍처적인 구조적인 문제라는 것을 주의해야한다.

그러므로, 대부분의 자바기반의 경우에 라이센스를 중요하게 검토해야한다. 대표적으로 jQuery의 경우에는 어떻게 해당되는가에 대해서 확인해보면, MIT 라이센스에 해당되어진다. 그러므로, 상용 패키지에 사용하여도 무방하다. 이러한 MIT 라이센스를 기반으로 MS에서도 jQuery with Visual Studio가 출시되지만, jQuery의 원래 상태가 그대로 탑재되므로 jQuery는 MIT 라이센스를 그대로 유지하게 된다.

상용패키지를 개발하고자 하는 개발자라면 다시 한번 이야기하지만, Apache 라이센스, BSD, MIT라이센스 이외의 저작권은 사용할 수 없다는 것을 알아야 한다. 물론, 오픈 소스 진형에서 활동하고 싶다면, GPL을 기반으로 같이 호홉하는 세계로의 진입도 충분하게 고려할만하다는 것이다.

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2013.05.13 21:21

[아키텍트 스토리]

아키텍처와 이노베이터

소프트웨어 아키텍처 정의를 위한

단계, 그리고 설계 (표준화, 상호운용성)

소프트웨어 아키텍처는 현재 상상하는 미래의 시스템과 그 발전방향, 그리고. 개발에 필요한 많은 표준안과 개발의 방향성 등에 대해서 서술하게 된다. 물론, 이러한 '영역'을 하나의 문서로만 모두 표현할 수는 없을 것이다. 이번에서는 소프트웨어 아키텍처를 정의하는 중요한 문서인 소프트웨어 아키텍처 정의서와 기타 개발에 필요한 표준안을 만드는 방법에 대해 알아보도록 하자.

 

----------------------<필자 사진>------------

신현묵 supims@gmail.com zetlos.tistory.com | 현재 명지병원 대학병원 정보통신팀 팀장과 헬스로그 이사로 재직하고 있다. 제약, 의료기기 생산업체의 정보시스템 개발 경험과 온라인 게임개발, 대형 SI에 이르기까지 경험이 풍부한 자칭 '삽질의 대가'. 현재 기존의 소프트웨어 삽질을 아키텍트로 승화시키려 노력하고 있다. 또한 현재 한국전자정보통신산업진흥회(KEA) '전자의료산업센터'의 디지털병원관련 실무추진위원장으로도 활동 중이며, 새롭게 모델을 개발하는 IT의료융합센터의 기획위원장으로도 활동 중이다. 또한, 독자들과 트위터(@zetlos)를 통한 소통을 즐기고 있다.

----------------------------------------------

 

상호운용성에 대한 중요한 이야기

 

상호운용성은 소프트웨어 설계자와 관리자의 입장에서 가장 중요한 것 중 하나다. 또한 이 개념없이는 향후에 만들어질 시스템과 소프트웨어, 서비스 부분에서는 발전 가능성 자체가 없다고 볼 수 없으며, 향후 중요한 시스템의 판단 근거가 된다.

이를 쉽게 설명하면 상호운용성이라는 것은 시스템이나 제품이 '고객'의 특별한 노력 없이도 다른 시스템이나 다른 제품과 함께 잘 동작하는 것을 의미한다.

특히 현재 필자의 경우에는 의료정보시스템간의 연계와 상호운용성에 대해서 많은 작업들을 해왔다. 이처럼 상호운용성에 대한 것은 '소프트웨어 아키텍처'에 있어서 가장 중요하고도 확고한 개념이기 때문에 이에 대해서 좀 더 많은 것을 이야기해보겠다.

 

'상호운용성은 네트워크가 곧 컴퓨터인 클라우드 시대에서 가장 중요한 개념 중 하나다'

 

보통 상호운용성을 획득하기 위해서는 첫째, 공표된 표준 인터페이스를 지지하고 지원하는 것인가와 둘째, 한 제품의 인터페이스를 즉각 다른 제품의 인터페이스로 변경할 수 있는 DLT는 브로커 서비스를 제공하는 것이라는 가장 큰 두가지 개념이 사용된다.

이 두가지의 접근방법들은 우리 주변에서 무수히 많이 볼 수 있다. 전자는 TCP/IP, HTTP 그리고 HTML과 같은 표준들이며, 후자의 상호운용성 접근방식은 CORBA와 ORB에 의해서 예증되었고, 그 방법들에 대해서 많은 곳에서 활용되고 있다.

비슷한 말로 '호환성'이라는 단어가 있지만 호환성은 표준과 양립할 수 있는 형태이더라도, 동일한 표준에 부합되는 다른 제품들과의 공동이용이 가능하다는 말로 좁은 의미의 상호운용성을 가진다고 하겠다.

이처럼 상호운용성안 다양한 측면으로 해석된다. 대표적으로 클라우드 시스템을 디자인하게 되는 경우에도 다양한 디바이스를 고려한다는 측면이 될 수 있을 것이며, 내부 시스템과 외부 시스템의 연계측면으로도 해석될 수도 있다. 이러한 상호운용성을 의료정보시스템 측면에서 한번 고려해보자.

 

두 시스템의 연동과 연계에 필요한 설계와 디자인을 한다면

 

필자는 국내의 특정도메인의 시스템들을 통합하고 정보들이 교류될 수 있는 시스템에 대한 자문을 의뢰받았었고, 그 부분에 대해서 상당부분 오랫동안 연구하고 실제 구현하려 애써왔다. 이러한 시스템을 통합하고 운용하는 것에는 상당한 표준안에 대한 이야기와 업체, 정부, 특정 도메인의 지식을 가진 집단들, 그 지식을 운용하는 단체들과의 많은 이해충돌이 발생하게 된다.

이러한 시스템을 구성하기 위한 방법들은 어떤 방법들이 있을까? 정보를 전달하고 교류하고 그 정확성을 보장하기 위한 가장 훌룡한 방법들은 어떠한 것들이 있을까? 물론 이러한 기준과 표준화에 대해서는 전통적인 방법과 이론으로 많은 것을 해결할 수 있겠지만, 소프트웨어 아키텍처를 정의하는데 있어서 가장 심각한 문제를 초래하는 것은 다음과 같은 '표준안'과 '표준'에 대한 선택이 가장 큰 문제이다.

그렇다. 가장 문제가 되는 것은 '전통적으로 오래된 표준'과 '새롭게 만들어져서 제안되는 표준'에 대한 고민이 소프트웨어 아키텍트들에게 가장 큰 고민이 된다. 과연 소프트웨어 아키텍트들은 어떤 선택을 해야할까?

의료정보시스템에 있어서 대표적으로 존재하는 기존의 표준안은 HL7(Health Level 7)인데, HL7은 정말 거대하고 잘 만들어진, 말 그대로 클라우드와 같은 표준안이라고 할 수 있다.

 

HL7

 

의료정보 시스템간의 인터페이스에는 입원, 퇴원, 진료의뢰 등과 관련된 환자 정보나 의사의 지시를 입력, 취소, 수정하는 의사지시 정보, 보고서를 생성하기 위한 보고서 정보, 기타 환자의 진료이력이나 연구소의 시험결과, 심전도 결과, 병리학 결과 등이 있다.

특히 HL7은 서로 다른 의료정보시스템 소프트웨어 애플리케이션 간에 정보가 호환될 수 있도록 하는 규칙의 집합으로, 현재 북아메리카에서는 의료정보의 전자적 교환을 위한 사실상의 표준으로 이용되고 있다.

또한 이기종 정보시스템 통합과 의료정보 교환을 위한 구현수단으로서 국가나 지역, 의료기관 모두의 요구사항을 충족하며 전 세계에서 가장 널리 쓰이는 전송표준이라고 말할 수 있으며, 국제표준화기구(ISO) 및 의료정보화분과(TC215)와의 긴밀한 협조로 의료기관 종사자, 정보시스템 개발자 등의 관련자들이 공동으로 참여하여 개발된 개방형 표준이며 사실상의 국제 표준으로 이용되고 있다.

다기종 컴퓨터에 분산된 의료정보의 대용량 정보처리라는 병원전산화의 본질적 문제 해결을 위해 현재 미국에서 의료정보 표준화에 가장 활발한 역할을 하고 있는 것이 HL7인데, HL7의 1차 목적은 서로 다른 전산시스템간의 자료전송을 최대한 효율적으로 수행하며, 그에 발생하는 전송오류를 최소로 할 수 있는 표준안의 정립에 있다.

HL7의 적용분야는 의료서비스 공급자(병원, 장기요양기관, 건강클리닉 등), 약국, 정부의 의료 관련 기관과 부서, 검사실, 의료분야 소프트웨어 벤더, 의료정보 컨설턴트 등이다.

 

 

이외에도 HL7이란 의료정보 시스템 사이에서 의료정보의 전자적 교환을 위한 표준으로 분류되고 있다.

HL7은 프로토콜의 설계 및 개발을 담당하고 서로 다른 의료 분야 소프트웨어와의 정보 호환이 가능하도록 하는 표준 제정을 위해 조직된 국제 비영리 표준화 기구로도 지칭된다. 특히 의료정보시스템 및 의료 장비 접속에 관한 표준을 제정하는 표준기관으로서 1994년 설립 이후 현재 한국을 포함한 29개국 지부를 두고 있으며, 의료정보의 전자적 교환을 위한 사실상의 ANSI 표준이라고 말할 수 있다.

HL7의 7은 ISO/OSI 통신 계층의 최상위인 7계층의 애플리케이션을 의미하며, 분산된 의료정보의 대용량 정보처리를 위해 시스템간의 자료전송을 최대한 효율적으로 수행하고, 전송중 발생하는 오류를 최소화할 수 있는 표준의 정립을 목표로 하고 있다.

1987년에 표준화 작업이 시작되어 1990년에 첫 번째 표준 버전 2.1이 발표된 이후 2001년에 버전 3 초안이 발표되어 현재 진행 중이다.

현재 개발 중인 표준으로는 보건의료정보 메시지 표준과 HL7 데이터 모델인 참조정보모델(RIM: Reference Information Model), 의사결정과 지식지원을 위한 의학논리구문(MLM. Medical Logic Module)에 관한 표준, 온라인상에서 임상정보를 교류할 수 있도록 하는 XML 타입의 데이터 구조 모델을 제시하는 임상데이터구조(CDA. Clinical Document Architecture)와 사용자 관점에서의 이기종간 산재된 독립된 애플리케이션 및 개인 정보의 통합에 관한 표준(CCOW. Clinical Context Object Working Group) 등이 있다.

HL7 메시지 표준은 메시지의 구조를 담고 있는 추상적 메시지 구조, 메시지를 전송하는 방법을 담고 있는 메시지 인코딩 규칙, 시스템 간의 데이터 교환을 위해 메시지를 발생시키는 애플리케이션 이벤트인 트리거 이벤트에 관한 명세를 기술하고 있다.

예를 들면, 한 시스템에서 트리거 이벤트가 발생하면 이 시스템에서 HL7 메시지가 송신되고 네트워크를 통해 다른 시스템에 전달되어 그 시스템에서 HL7 메시지를 수신한 후 수령했음을 나타내는 신호를 되돌려주게 되고 원래의 시스템이 이 신호를 수신함으로써 시스템간 메시지 전송이 완성되는 형태를 보여주는 것이다. HL7의 CDA는 HL7 참조정보모델에 기반해 방사선 기록지, 경과 기록지, 임상 요약, 입/퇴원 요약지 등의 많은 종류의 의료문서유형을 지원하기 위한 통합 정보 모델로 이용되기도 하는데, XML을 사용하여 기계 및 사람이 읽을 수 있도록 한 것이 특징으로 현재 2.0 버전이 ANSI에 승인되어 있다.

 

 

그동안 HL7 구현에 필요한 도구들이 많이 개발돼 있으나, 매우 복잡하기 때문에 구현하기 어렵다는 문제점이 있다. 그리고 한국의 의료환경에 근거한 구체적인 각 분야별 임상데이터구조(CDA. Clinical Document Architecture)의 제안이 시급한 부분이 있다.

여기에서 HL7의 전통적인 문제의 핵심은 는 그 동안 너무 많이 개발되어서 매우 복잡하고 구현하기 어렵게 되었다는 부분이 가장 큰 문제다. 과연 이러한 방향으로 메시징을 교환하는 시스템을 구현하는 것이 합당한 것일까?

 

의료정보표 중에 'CCR 표준' 있다

 

CCR(Continuity of Care Record)은 ASTM(American Society for Testing and Materials) International, MMS(Massachusetts Medical Society), HIMSS(Health Information Management and Systems Society), AAFP(American Academy of Family Physicians)가 처음으로 연합해서 공동개발을 시작한 표준사양이다.

현재는 앞서 언급한 기구 외에도 수많은 단체들이 공동으로 표준개발에 참여하고 있다. 이것은 환자관리의 연속성을 촉진 및 향상시키고 의료과실을 감소시키며, 환자를 다른 병원으로 보내거나 다른 의료서비스 제공자가 환자를 맡았을 때 의료정보의 이동성에 대하여 보장하기 위한 최소한의 표준이다.

 

<그림 > CCR기반의 환자 정보 교환 예

 

의료서비스제공자가 환자를 처음 맡게 되는 초기에 쉽게 환자에 대한 정보를 알 수 있게 해주고, 환자가 다른 의료서비스제공자에게 갈 때 쉽게 정보를 갱신할 수 있게 해줌으로써 안전성과 의료품질 그리고 환자진료의 연속성을 지원하는 것이 CCR의 목표다.

이를 통해 CCR은 의료제공자, 의료기관 또는 서로 다른 기관들 사이에서 임상정보를 교환할 수 있는 매개체가 될 것이다.

또한 이것은 최근의 진료에 대한 간단한 요약 정보로 환자들이 사용할 수 있게 되면서 환자진료의뢰, 환자이송, 퇴원 또는 환자가 다른 의료서비스제공자에게 가게 될 때에 의료종사자들이 관련 정보를 찾는 어려움을 겪지 않아도 될 것이고, Lab 실험과 평가 등의 반복을 줄여줄 수 있게 됨으로써 진료효율을 증대시키고 진료비용을 감소시킬 잠재력을 가지고 있다.

투약정보나 알레르기 정보와 같은 중대한 데이터를 쉽게 얻을 수 있게 함으로써 환자의 안전을 지원하고 의료사고를 줄여줄 수 있다.

환자에게 초점이 맞춰져 있고, 환자가 자신의 의료정보를 쉽게 알 수 있게 해주고, 환자의 의료정보를 계속해서 반복적으로 의료기관에게 제공해야 할 필요가 없어진다.

개인의 의료정보와 자가관리정보를 통합적으로 관리할 수 있는 개인건강기록(PHR)을 정착시키는 것을 도와줄 것이고, 환자가 자신의 의료정보에 더 관여하고 잘 알 수 있도록 해줄 것이고, 환자가 자신의 의료정보 전송에 관여하게 함으로써, 환자의 참여를 장려하고 의료제공자와 환자의 관계를 개선시켜 줄 것이며, 더 나아가 연구나 공공 건강활동 등에서도 다양한 활용이 가능하다.

간단히 말하면 이 표준에는 환자정보와 의료서비스제공자 정보, 보험정보, 환자의 건강상태정보(예를 들면 알레르기, 투약, 맥박, 호흡, 체온, 혈압, 진단, 최근의 처치 등)나 사전의료지시, 미래의 진료 계획에 대한 조언, 환자진료의뢰의 이유 등의 정보가 들어있다. 이러한 최소한의 데이터는 환자에 대한 가장 관련성 깊은 정보를 주고받는 방법을 제공해줌으로써 진료의 연속성을 향상시켜 줄 것이다.

환자가 외래환자이건 입원환자이건 의료진이 다른 의료진으로 바뀔 때 의사, 간호사, 그리고 의료보조서비스 제공자들이 CCR을 작성할 것이다. CCR은 XML 표준 문서이기 때문에 기계와 사람이 읽을 수 있으며, 데이터 내용이 여러가지 형식(웹 브라우저, PDF 리더, 문서작성기 등)으로 표시되거나 인쇄될 수 있다.

특히 CCR은 환자의 건강관리와 관련해서 가장 관련성이 높은 사실들을 모아놓은 핵심 데이터를 시간에 따른 스냅샷으로 저장한 것으로 의사가 의료행위를 마치면 기록이 되고 다음 의사가 쉽게 그 정보를 알 수 있도록 해준다. 종이나 전자적인 방법으로 만들어지고 표시되고 전달될 수 있다.

이외에도 CCR은 적절하고 간결하게 구조화된 최신의 정보를 제공하며 지정된 XML 코드를 통해 시스템 사이에서 상호 운용될 수 있고, 환자에 대해서 거의 모르고 있는 의사가 있는 완전히 다른 환경으로의 중개역할을 하고 있으며 장기요양, 급성치료, 질병관리, 개인건강기록 등의 특정 영역에 대한 내용은 확장장치(Extensions)를 통해 처리할 수 있다.

CCR의 표준 개발 활동은 ASTM International, MMS(Massachusetts Medical Society), HIMSS(Health Information Management and Systems Society) 등과 같은 후원단체들의 컨소시엄으로 진행되고 있다.

이러한 활동은 환자 중심적(시스템이 무엇을 해야 하는가가 아니라 어떤 환자정보가 가장 관련이 깊은가에 대한 것)이고 한편으로는 의료제공자 중심적(어떤 정보가 가장 관련이 깊은가를 의사가 결정하는 것), 콘텐츠 중심적(훌륭한 환자관리서비스를 하기 위해서 의료제공자가 무엇을 알아야 하는가에 중점을 두는 것) 이다.

이러한 활동은 또한 ASTM과 HL7과 같은 기구들과 의료전문 기관들과 의료 종사자들, 의료서비스 제공기관, 의료장비 및 의료정보시스템 개발사들의 상호 협조를 이끌어내도록 하는 등, 다양한 그룹들이 CCR을 개발 및 구현하고 상호 운용성을 확인하며 데모 프로젝트를 개발하는데 함께 일하고 있다.

CCR은환자의 일생에 걸친 건강상태와 건강관리 정보를 전자적으로 저장하는 EHR과 같은 완전한 의료기록이 아니며 유일한 값을 갖는 환자 식별자(ID)를 가지고 있지도 않다. CCR은 경과에 대한 기록이나 퇴원요약정보나 진찰상담 자료가 아니다.

이러한 자료들은 핵심적인 데이터를 지정된 XML 코드로 표현하여 정의한 것일 뿐, 한명의 의사로부터 나온 정보에 국한되어 있지 않으며, 자유로운 텍스트 기반으로 작성된 것도 아니다.

CCR은 환자의 문제 목록, 알레르기 등 환자의 건강상태와 보험, 처방문서 및 처치계획 추천 등 진료의 연속성에 필요한 필수적인 요소만 포함하여 환자에 대한 요약정보를 지원할 수 있는 구현이 용이한 정보모델이다. (CCR에는 환자의 건강문제, 투약, 알레르기와 보험, 사전의료지시, 진료 문서, 환자 진료 계획과 같은 건강상태정보가 기본적으로 요약돼 있다.)

CCR을 전자적으로 교환하는 것을 보장하기 위해서 CCR을 생성할 때 XML 형식을 사용한다. 이 지정된 XML 형식을 사용함으로써 다양한 방법으로 CCR을 만들고 전송하고 확인할 수 있다.

예를 들어 HL7의 CDA와 호환되는 문서로서 브라우저로 확인할 수 있고, PDF 파일이나 HTML 파일이나 또는 문서작성기의 문서로서 보안메일에 들어갈 수도 있다. 또한 CCR에 들어있는 필드들은 다양한 형식으로 표시해 줄 수 있을 것이다.

이외에도 CCR은 환자와 관련된 인적 사항과 특정한 한 시점에서의 진료정보를 나타낸다. ASTM과 다른 표준개발기구와의 협력으로 확립된 XML 스키마를 사용하게 되면, 적절히 설계된 전자의무기록시스템은 모든 CCR 데이터를 임포트/익스포트 할 수 있게 되어 의료종사자들의 업무에 혼란을 최소화하면서도 진료정보 전달을 가능하게 할 것이다. 그리고 서로 호환되지 않았던 전자의무기록시스템들 간의 CCR 데이터의 교환도 가능해질 것이다. 미리 지정된 XML 코드를 사용함으로써 CCR은 상호운용성을 확보할 수 있기 때문에 서로 호환되지 않았던 서로 다른 전자의무기록시스템들 사이에 CCR을 교환할 수 있게 되어 전자의무기록시스템의 확산에 기여하게 될 것으로 보인다. XML을 사용함으로써 CCR은 브라우저나 HL7의 CDA 호환 문서나 이메일, 기타 XML 기능을 갖춘 문서작성 소프트웨어 문서 등 다양한 형태로 만들어져 전송되고 확인할 수 있기 때문이다.

또한 CCR은 종이문서로 인쇄될 수 있고, 이동식저장장치에 저장되어 개인건강기록으로 사용할 수 있다. CCR에 들어있는 데이터는 환자 데이터이며 만일 그러한 데이터로 환자를 식별 가능하다면 CCR 문서의 보전성과 비밀성을 End-to-End로 유지/제공해야 하고 규정이나 기타 안전, 보안 또는 개인정보 보호 기준을 따라야 하는데, CCR의 구조와 필수적인 핵심요소는 다음과 같다.

 

===박스 | CCR 구조 및 필수핵심요소 =======

 

 

Header or Document Identifying Information

- 진료의뢰를 하는 즉, "from" 임상의 에 대한 정보

- 진료의뢰를 받는 즉, "to" 임상의 에 대한 정보

- 문서의 일자

- 문서를 작성한 목적과 진료를 의뢰하는 이유

 

Patient Identifying Information

- 진료를 의뢰하는 프로세스와 병원, 개인병원, 가정 등 어떠한 종류이건 진료 환경에서 환자를 이송하는 과정 중 환자를 식별하고 구별하기 위해 필요한 정보. 중앙집중식의 시스템이나 국가적인 환자 식별자가 아니라, 연합된 형태나 분산된 형태의 환자식별 시스템에서 사용되는 식별정보를 담고 있다.

 

Patient Insurance and Financial Information

- 의료보험 관련 정보.

- 보험의 보장범위에 대한 환자의 자격을 알 수 있는 최소한의 기본 정보.

 

Advance Directives

- 사전 의료 지시.

- 소생술을 허용할 것인지 또는 제한할 것인지를 의미.

 

Patient's Health Status

- 진단/문제/질병 정보를 중요성 순서대로 또는 시간 순서로, 보통의 언어로 또는 선택된 코드체계에 기반한 코드로 묘사.

- 발병일, 가장 최근의 해결일, 상태, 질병을 환자가 인식하고 있는지 여부, 가족력 등

- 부작용 / 알레르기

- 최근의 투약

- 면역조치

- 맥박, 키, 몸무게, 혈압, 체온, 호흡 등

- Lab 테스트 결과

- 처치 / 평가

 

Care Documentation

- 환자가 임상의를 만난 상세 기록

 

Care Plan Recommendation

- 계획되어 있는 테스트, 절차, 투약계획

 

Practitioners

- 환자 관리에 참여했던 건강관리 의료종사자에 대한 정보

- Conditions / Diagnoses / Problems 와 Care Documentation 접촉정보에 대한 링크

 

============ 박스 끝=================

 

 

 

특정 의료기관에 특화된 정보, 임상 전공분야에 특화된 정보, 특정 질병에 특화된 정보 또는 질병관리지침 등, 의료비 지불인에 대한 정보, 환자가 입력한 개인건강기록(PHR) 등의 내용을 기록하기 위해 추가적으로 확장할 수 있다.

환자와 관련된 어떠한 정보라도 수용할 수 있는 유연성을 가진 CCR은 Top-Down의 접근방식이 아니라 최종사용자 즉, 의료종사자들이 설계에 참여해왔다. 최종사용자들을 대표하는 기관(직접 종사하거나, 조언하거나 지원하는)에서 지원을 받고 있다. 따라서 의료종사자, 의료서비스 제공기관, 환자, 벤더, 그리고 다른 이해관계자들이 CCR을 당면한 문제에 관련하여 적절히 운용할 수 있는 매우 유익한 것으로 인식하고 있다.

전자의무기록의 데이터 구조에 관한 다른 표준으로는 호주의 openEHR 시스템을 참조해 개발한 13606 표준인 Archetype 표준이 있다. 13606 표준은 EHR 커뮤니케이션을 위해 5개 부분으로 나눠 개발이 진행되고 있다.

EHR을 전송하는 기본단위를 EHR Extract라고 정의하고, EHR Extract를 효과적으로 만들어내기 위해 Reference Model과 Archetype Interchange Specification을 제안하고 있다.

또한 이 두 모델에서 사용되는 속성과 타 표준이나 명세와의 호환성을 위해 Reference Archetype and Term Lists를 제시하고 있다.

 

HL7, CCR 과연 어떤 표준안을 선택할 것인가

 

필자는 단언한다. 실제 사용이 가능한 방식은 무엇이며, 표준화라는 것은 얼마나 많은 제약이 존재해야 하는가에 대해서 반문하고 싶다. 마찬가지로, 소프트웨어 아키텍처정의서나 아키텍트들이 개발전반적으로 규정해야할 기준에 대해서 이야기를 한다면, 어느 정도의 표준과 그 방식과 양식을 규정해야하는가 인데, 이 부분은 간단하게 '진료정보전송표준'으로 정리해볼 수 있다.

 

==== 박스 | 진료정보전송표준 ==============

 

 

HL7 CDA (Health Level 7 Clinical Document Architecture)

- HL7 Reference Information Model(RIM)에 기반해 방사선 기록지, 경과기록지, 임상요약, 입퇴원 요약지 등의 많은 종류의 의료문서 유형을 지원하기 위한 통합 정보 모델

- 구현하기 어렵고 복잡한 표준모델

 

ASTM CCR(The American Society for Testing and Materials Continuity of Care Record )

- 환자문제리스트, 알러지 등 환자의 건강 상태와 보험, 처방문서 및 처치계획 추천 등 진료의 연속성에 필요한 필수적인 요소만 포함하여 환자 요약을 지원할 수 있는 정보모델

- 구현하기 용이한 정보모델

 

한국EHR 핵심 공통기술연구개발 사업단

- 국내 EHR을 위한 진단검사, 투약, 진료정보요약 진료정보 교류 표준 분석과 구현지침을 최초로 개발하고, use case 연구를 통한 현장 도메인과 다양한 표준과의 gap을 분석

- 모두 HL7을 기반으로한 정보모델을 기반한 표준을 적용.

 

============ 박스 끝 =======================

 

필자는 '한국 EHR핵심 공통기술연구개발 사업단'의 연구 결과물에 대해서는 긍정적인 시선을 가지며, 훌룡한 연구였다고 생각한다. 하지만, 이러한 '학계의 이론'방식에 의한 연구결과물을 실제 의료산업계에 전파하기에는 무리가 있다고 생각한다. 필자가 생각하는 표준화의 방향은 3가지다.

 

1. 표준화의 방향성

2. 상호운용성을 어떻게 획득할 것인가

3. 적극적인 운용테스트는 어떻게 할 것인가

 

분명, '정보시스템'단위의 병원의 각종 진단 코드 및 검사코드 등의 표준화는 매우 중요하다.

하지만, 이러한 '정보'들이 의료정보교환표준화라는 측면으로 접근되게 되면, 실제 구현과 처리를 위해서 정말 많은 이해당사자들과 접하게 되고 그러한 환경에서 표준화의 방향성을 가지고 진행해야 한다.

 

 

소프트웨어 아키텍처 세부 표준화

 

필자는 SA설계의 기초에 대해 먼저 표준화가 이뤄지면 모든 것이 해결되는가를 묻고 싶다. 표준화라는 명세가 존재한다고 해서 실제로 개발이 통제되고, 실제 시스템에 해당 내용들이 반영되는지에 대한 여부를 따져본다면, 그렇지 않다라고 생각하기 때문이다.

소프트웨어 개발은 점진적으로 사람과 사람의 소통 속에서 만들어지는 것이다. 때문에 단순히 표준화의 명세화만을 통해서는 조직과 아키텍트에 스며드는 실제 표준화가 제대로 이뤄질 수 없기 때문이다.

더군다나 고급개념과 이상적인 개념으로 투영된 소프트웨어 아키텍처와 수준 높은 표준안은 어떻게 해도 검증할 방법이 난해한 것이 현실이다.

이 뿐만이 아니다. 단일 소프트웨어 개발의 경우에는 그나마 실제 아키텍트가 해당 개발조직을 통제할 수 있으나, 대표적인 표준안들의 경우에 Paper specification은 누가 구현하고 어떻게 검증할 것인지와 같은 난제가 발생한다. 이에 대해 소프트웨어 아키텍트는 이러한 표준화의 방향에 대해서 테스트와 검증방법까지 제시하고 운용할 방법을 제시할 수 있도록 하는 것이 소프트웨어 아키텍처를 만드는 가장 중요한 개념 중 하나라고 보면 되겠다.

이처럼 표준화를 어떻게 만들어내느냐는 단순한 표준방안을 선택하는 것 이상의 선택의 어려움을 가지게 된다. 다양한 표준화방향에 대해서 고민하고 그것을 시스템에 반영하는 것 그것이 소프트웨어 아키텍트의 임무이다.

 

SA설계란 무엇인가

 

이제 SA설계에 대해 정리해보자. SA 설계는 크게 인터페이스 정의, 요구사항의 우선순위 파악, 고객의 요구사항 파악이라는 3가지 정의로 축약할 수 있다.

시스템적으로서의 주요한 부분은 시스템과 사용자간의 UX도 인터페이스요, 컴포넌트와 컴포넌트사이의 인터페이스, 모듈과 모듈의 인터페이스이며 더욱더 중요한 것은 '요구사항'에 대한 반응이다. '고객의 요구사항을 어떻게 명확하게 파악'할 것이며, 그 요구사항의 '우선순위'를 정확하게 파악하는 것이 정말 중요한 SA설계의 요소인 것이다.

SA설계의 기초단계는 <화면 1>과 같이 사용자들의 요구사항을 수집하고, 리스트를 관리하며, 요구사항 리스트에서의 작업 우선순위를 결정한 뒤 품질 요소를 결정하는 것이다.

또한 이러한 요구사항들을 통해 요구사항의 변경지표 및 시기, 변화의 내용들에 대해서 대응해야 하는 것이다. 사용자의 요구사항들은 중요한 UX와 컴포넌트들간의 연관관계에 지대한 영향을 끼치게 하므로, 사용자의 요구사항을 명확하게 관리하는 것이 최선의 프로젝트 품질요소지표로 작용한다.

해당되는 요구사항들에도 개발의 우선순위, 기능적인 우선순위, UX의 우선순위, 개발비용의 우선순위, 위험요소의 우선순위라는 각각의 우선순위가 있다. 이러한 요소들을 고려해 다양한 프로파일링이 가능하게 되는 것이다.

<화면 2> SA설꼐의 3단계

 

<화면 2>는 SA설계의 3단계를 중요한 지표로서 서술한 그림이다. 가장 중요한 내부적인 SAD(Software Architecture Document)와 설계적 의사결정문을 구성하기 위해서 다음과 같은 중요한 3가지의 단계를 거치는 것을 의미한다.

 

하나. 작업우선순위

둘. 내부/외부 반복 프로세스 수립

셋. 업무 서브 도메인별 반복적인 분석/설계 과정의 대량생산체계수립

 

앞서 언급된 3가지 단계는 기능/비기능과 이에 파생되는 유지보수 단계 및 개발과 테스트, 아키텍처의 구성형태에 영향을 주는 작업의 우선순위에 대한 파악이 그 첫 번째이며, 중요한 요구사항들이 반영될때에 해당 프로세스에 대한 영향을 개발조직 내부와 업무조직 내부의 요구조건, 외부의 법이나 기타 연관관계에 따른 요구사항의 변경들에 대한 영향의 변화에 대한 프로세스들을 수립하는 것이 두 번째다. 또한 실제, 분석/설계시에 대량생산과 수집, 패턴화가 가능한 요소들을 도출하는 것이 그 세 번째가 되겠다.

 

이번 컬럼에서는 SA설계의 기초적인 프로세스의 흐름과, SA설계를 위한 기본적인 생각의 흐름 및 중요 요구사항 등에 대응하는 방법들을 알아봤다.

SA에서 가장 중요한 것은 이 요구사항을 어떻게 아키텍처에 반영하고 이를 어떤 기능/비기능으로 구분하여 관리할 것이며, 그 단계와 분석/설계에 대응하는 실제 개발팀에 대한 통제방법들에 대해서 고민하고, 실제 개발/유지보수 할 조직에 대한 예측을 해야 한다는 것이다.

다만 아키텍트는 이러한 계획을 수립하고 필요 가이드라인을 구성할 때에, '불필요한 절차와 행위'에 대해서 독자적으로 구성하지 말고, 실제 수행할 개발조직과 팀원들과의 대화와 타협에 의해서 이를 구성하는 것이 가장 최선임을 잊어서는 안된다.

언제나처럼 이야기하지만, '형식을 고집하는 삽질을 하는 아키텍트'가 안되기를 기원한다.

 

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2011.01.22 09:04

[소프트웨어 아키텍처 그 두번째]

아키텍처와 이노베이터

소프트웨어 아키텍처 설계를 위한 방법

 

많은 개발자들이 소프트웨어 개발에 실패하는 대표적인 이유는 어떤 것일까. 먼저 첫째, 비전문가 집단에서 의사결정이 이뤄진다는 점과 둘째, 단기적인 수익만 바라본다는 점, 셋째, 실패 예상시나리오가 부족했다는 점 등 3가지 경우로 볼 수 있겠다. 전문가집단들의 상호의사소통은 프로젝트 성공을 위한 기본이고, 프로젝트 그 이후를 예측하는 것 또한 중요하다. 또한 모든 프로젝트는 실패할 수 있다. 이처럼 실패를 대비한 위험관리와 요구사항 관리는 소프트웨어 아키텍처에 가장 중요한 요소라 하겠다.

 

----------------------------------

신현묵 zetlos.tistory.com | 현재 명지병원 정보통신팀 팀장과 헬스로그 이사로 재직하고 있다. 제약, 의료기기 생산업체의 정보시스템 개발 경험과 온라인 게임개발, 대형 SI에 이르기까지 경험이 풍부한 자칭 '삽질의 대가'. 현재 기존의 소프트웨어 삽질을 아키텍트로 승화시키려 노력하고 있다. 또한 현재 한국전자정보통신산업진흥회(KEA) 디지털병원수출기획단의 디지털병원 IT 관련 실무위원으로도 활동 중이며, 새롭게 출범하는 IT의료융합센터의 자문위원으로도 활동할 예정이다. 독자들과 트위터(@zetlos)를 통한 소통을 즐기고 있다.

----------------------------------------------

 

지난 필자의 글(2010년 10월호 커버스토리 참고)에서는 소프트웨어 아키텍처의 전반적인 내용과 개념에 대해서 서술을 해봤다면 이번 컬럼에서는 소프트웨어 아키텍처 설계를 하기 위한 절차와 기법에 대해서 알아보는 것을 주요 목적으로 두고 이야기하고자 한다.

먼저 소프트웨어 아키텍처 설계에 대한 내용에 대해서 정리한다면, 다음과 같이 언급할 수 있다.

 

1. SA설계 개요

2. 요구사항 정의 절차

3. SA설계

4. SA평가

5. SA상세화

6. SA설계 산출물 관계

7. 아키텍트의 의사결정항목

 

 

 

 

 

<그림 1>은 소프트웨어 아키텍처의 전체적인 설계 절차에 대해 쉽게 알아볼 수 있도록 기술한 것이다. <그림 1>에 대해 보다 상세하게 설명하면 다음과 같다.

가장 먼저 소프트웨어 아키텍처 중 논리적 아키텍처를 구성하기 위해 업무도메인을 분할하고, 업무도메인의 서브도메인을 파악하여 이들의 관련성(interface)을 정의하는 데서 시작한다. 이어 정의된 애플리케이션 아키텍처에 맞게 전 도메인 또는 서브도메인에 대한 아키텍처 구조에 맞게 상세설계 및 구현을 실시한다.

소프트웨어 아키텍처 설계는 고객의 요구사항에서부터 출발한다. 고객의 요구사항은 요구사항 정의 단계에서 인터뷰를 통한 회의록, 인터뷰시트로 파악할 수 있으며, 분석설계단계에서는 유즈케이스 설계서를 통해 구체적으로 파악할 수 있게 된다.

개발자는 앞서 언급된 단서들을 통해 고객의 요구사항을 파악하고, 소프트웨어 아키텍처에 고려해야 할 요소를 보다 쉽게 적용할 줄 아는 기술을 습득하는 것이 필요하다.

이때 요구사항의 우선수위 결정을 위해서는 애플리케이션 시스템의 중요한 품질요소를 결정하는것이 좋다. 이를 통해 우선순위를 가지는 품질요소에 대한 요구사항을 기반으로 작업우선순위를 결정할 수 있게 되며, 전체 애플리케이션 아키텍처에 대한 해당 요구사항이 어떻게 변경되고, 얼만큼의 영향이 미치는지도 결정할 수 있게 된다.

따라서 기본적인 소프트웨어 아키텍처 설계 방법은 기능기반 아키텍처 설계, 아키텍처 평가, 아키텍처 전이 라는 3가지 단계로 구성된다.

품질요소기반 소프트웨어 아키텍처 설계방법은 다시 내부 반복 프로세스와 외부 반복 프로세스라는 두 개의 반복적인 설계 프로세스로 구성된다.

내부 반복 프로세스는 소프트웨어 아키텍처의 품질 요구사항의 설계, 평가, 전이로 크게 나눠볼 수 있으며, 외부 반복 프로세스는 고객의 요구사항을 품질요소에 따른 선택하는 방법에 대한 활동으로 이루어진다.

반복적 소프트웨어 아키텍처 개발 사이클의 외부 소프트웨어 설계는 요구사항 중 가중 높은 고려대상이 되는 제품에 대한 품질요구사항으로 시작되는데, 이는 요구사항들의 내부 반복 프로세스를 진행하게 된다.

또한 외부 반복 프로세스는 모든 요구사항이 애플리케이션 아키텍처에 고려될 때까지 나머지 요구사항을 반복하게 된다.

선택된 요구사항은 <그림 4>와 같이 소프트웨어 아키텍처 분석·설계 및 개발을 위한 핵심 소프트웨어 아키텍처 개발을 통해 수행되며, 이 과정을 통해 소프트웨어 아키텍처의 반복적인 수정의 기본 단위 작업들이 수행된다.

이때 발생되는 여러 가지의 요구사항은 반복적 소프트웨어 아키텍처 개발 사이클을 통해 품질요소의 우선순위 또는 작업의 우선순위에 따라 핵심 소프트웨어 아키텍처 개발수행을 이끌어낸다.

내부 반복 프로세스는 소프트웨어 아키텍처가 구현되는 기본이 되는 요구사항들로 이뤄진다. 내부 반복 프로세스에서 맞춰야 할 초점은 품질요소의 평가와 전이다.

애플리케이션 아키텍처 설계 방법은 목표, 관계상 설계 과정, 균형과 최적화를 지원하도록 제공된다. 반복적인 방법은 모든 품질요구사항이 만족될 때까지 각각의 품질요구사항을 지원하고, 전이로 사용되는 아키텍처로 반영된다.

완성된 애플리케이션 아키텍처는 업무 서브 도메인별 유즈케이스로 상세설계 또는 구현이 되며, 각 요구사항에 대한 단위 테스팅 수행 전체 시스템의 제품을 완성시키기 위한 반복적인 분석/설계 과정으로 대량생산체계를 수립한다.

이때 수정되는 비 기능적인 요구사항은 품질요소에 따라서 평가되어 애플리케이션 아키텍처의 재수정 과정을 거쳐 변경된 애플리케이션 아키텍처에 대한 제품적용이 이뤄진다.

따라서 소프트웨어 아키텍처 설계 방법은 소프트웨어 아키텍처 설계와 관련한 프로세스 정의뿐만 아니라, 아키텍처 설계를 위한 소프트웨어 아키텍처 문서(SAD : Software Architecture Document)와 설계적 의사결정물 들로 구성된다.

<그림 1>을 살펴보면, 기본적으로 요구사항 정의를 분류한 기능적 요구사항을 기반으로 해서 출발하고 있음을 알 수 있다.

비록 소프트웨어 엔지니어가 품질요구사항을 명확하게 정의하지 않으면 시스템은 안정적 또는 재사용될 수 없도록 설계되는 게 일반적이다. 이러한 소프트웨어 아키텍처 설계는 품질 요구사항 측면에서 많이 평가된다. 각각의 품질요소는 소프트웨어 아키텍처가 지녀야 할 정량적 또는 정성적 예상 값으로 평가된다.

아키텍처 전이단계 동안에는, 아키텍처는 적절한 품질요소를 최적화하는 전이 방법을 선택함으로써 더욱 명확해지며, 새로운 버전의 아키텍처 설계 버전을 탄생케 한다. 이러한 요구사항 수집, 평가, 전이하는 반복적인 단계는 아키텍처 설계 또는 제품 릴리스 동안 지속적으로 발생하게 된다.

<그림 > 반복을 통한 소프트웨어 아키텍처 설계 절차

 

<그림 2>는 소프트웨어 아키텍처가 프로젝트의 각 단계에서 어떻게 작성되는지를 보여준다. Inception 단계에서는 아키텍처 팀을 구성하고 아키텍처에 대한 개략적인 안을 작성하며, Elaboration 초기 단계에서는 핵심 아키텍처를 설계한다. Elaboration 후반부에서는 추가 요구사항을 받아서 아키텍처를 계속 수정하고. Construction 단계에서는 개발 도중 이슈가 발생하면 아키텍처를 보완한다. 이러한 Inception → Elaboration → Construction 단계를 반복하면서, 충분한 아키텍처의 견고함을 가지게 된다.

 

기존의 CBD방법론을 소프트웨어아키텍처 관점으로 살펴보기

 

<그림 3> CBD 방법론

 

<그림 3>은 기본적인 CBD방법론의 전형적인 예시를 보여주고 있다. 비즈니스 요구사항단계에서 요구사항을 파악하고 비즈니스모델을 설계한 다음, 실질적인 아키텍처 단계인 솔루션 아키텍처와 솔루션개발을 통해서 구체적인 소프트웨어를 개발한다. 이어 해당 소프트웨어에 대한 지원정책을 준비하고, 개발된 소프트웨어를 도입하는 절차로 진행된다.

솔루션아키텍처에서는 요구사항의 정의와 분석을 통해서 컴포넌트 식별 및 명세화를 취하고, 아키텍처를 정의하는 단계를 진행하면서 필요한 컴포넌트를 조달하거나 기존의 컴포넌트를 수정하는 정책들을 수립한다.

이렇게 만들어진 요구사항 명세와 컴포넌트 명세, 아키텍처의 정의를 통해 솔루션개발을 진행할 수 있다. 컴포넌트를 설계하면서 테스트설계를 병행하는 것이 CBD의 핵심중의 하나다. 이처럼 솔루션 아키텍처와 솔루션개발을 반복적으로 점진적으로 개발을 진행하는 것이 CBD방법론이다.

다만 CBD방법론은 현실에서 사용하기 매우 어렵다. 그 이유는 대다수의 아키텍트와 개발자들이 인식하고 있듯이, 모든 요구사항을 컴포넌트의 형태로 식별하거나 조달하는 방법자체가 거의 불가능하기 때문이다.

소프트웨어는 완전한 블록화나 캡슐화는 불가능한 형태다. 때문에 이상적인 CBD방법론을 적용한 실제 개발환경에서의 사용은 매우 어렵다. 때문에 CBD방법론 보다는 좀 더 유연하면서도 소프트웨어 자체를 아키텍처라는 관점으로 바라보고 개발에 나서는 것이 좀 더 바람직하다고 볼 수 있다.

그렇다면 이번에는 이상적인 CBD방법론을 SA관점에서 변환하고, 어떤 부분이 변경되는지 알아보도록 하자.

 

기존의 CBD방법론에서 아키텍처 정의 단계를 세분화하면 아키텍처 설계, 아키텍처 평가, 아키텍처 상세화로 나눠진다. 이는 CBD방법론에서 '솔루션 아키텍처'를 좀 더 세분화했다는 것이 그 차이일 수 있겠으나, 실제로 작업을 진행했을 때는 엄청난 차이를 보이게 된다.

이론과 실제가 큰 차이를 보이는 이유는 무엇일까. 요구사항을 통해 정의하고, 분석하는 과정에서 아키텍처 설계시 발생하는 컴포넌트 영역과 비컴포넌트 영역의 구분을 명화히 한다는 점과, 기존의 컴포넌트 설계시 요구사항 정의와 분석을 통해 바로 컴포넌트를 식별하거나 명세화 하는 것 뿐만 아니라, 좀 더 구체적인 아키텍처의 평가와 상세화 작업을 통해서, 컴포넌트를 식별하고 명세화하는 단계로 진행되기 때문이다.

이러한 이유로 실질적인 아키텍처 설계, 평가, 상세화 단계의 심도있는 작업과 논의를 진행해야 하는 아키텍처 팀의 구성과 형태가 매우중요하게 부각된다.

더불어 아키텍처 상세화 작업시, '기능/비기능'부분과 '고품질/저품질', '반복패턴과/집중개발'영역 등의 구분들을 세부적으로 정의하게 된다.

업무의 기능적인 사항이나 제약사항, 필요시 정의된 기능들에 대한 내용들과 실제, 시스템에서 요구되는 성능이나 UX에 대한 정의, 실제 외부시스템과의 연계 및 정의된 사항들에 대해서 정의한다. 또한 모든 소프트웨어의 기능부분들을 모두 고품질로 정의하는 미련한 행위를 하지 않는 정의가 일어난다.

소프트웨어의 고품질요소와 중요 기능요소를 도출하여 고품질영역을 구분한다. 아주 단순한 기능부터 아주 복잡하고 주요하게 요구되는 부분과 향후 유지보수와 가장 민감한 영역들에 대한 것은 물론이고, 고품질 개발이 가능한 팀원이나 팀이 필요한 요소들도 구분한다.

또한 반복패턴의 단순한 작업으로 구성되는 영역들과 별도로 개발될 영역들을 구분해야 한다. 이러한 방법들은 기존의 CBD의 작업순서와는 많은 차이를 보이며, 결과물의 형태 또한 다르게 나타난다.

 

 

 

 

기존의 CBD방법론을 소프트웨어아키텍처 관점으로 개선하기

이처럼 아키텍처 설계, 아키텍처 평가, 아키텍처 상세화의 단계에 대해 알아봤다면, 이번에는 프로토타입 기법과 같은 방법으로 제작된 중요한 샘플 프로세스나, 중요한 테스트케이스를 통해서 필요한 부분에 대해서 구성하는 방법도 가능하다. 원한다면, 고객이 원하는 대부분의 주요기능들에 대한 테스트케이스에 대한 진행도 가능한 부분으로 진행할 수 있다.

이번에는 좀 더 상세하게 전반적인 프로세스의 흐름에 대해서 살펴보자.

 

비즈니스 요구사항 분석 및 모델개발

<그림 > 요구사항 파악활동

 

<그림 5>를 통해 솔루션 아키텍처와 솔루션 개발에 대해서 상세하게 알아봤다. 그렇다면 요구사항 파악단계에 대해 알아보자. 요구사항 파악단계는 요구사항 수집 및 기술 → 현행 조직 및 시스템 정보 수집 → 시스템 비전 개발 3단계로 진행된다.

시스템을 주기적으로 유지보수하는 조직의 경우에는 평소의 요구사항과 명세서 등을 취합해 정기적으로 발생하는 영역과 주변의 상황에 따라 변경되는 다양한 요구사항들을 중요도를 따져 취합하며, 시스템에 반영될 요구사항을 수집하고 기술하고 평가하는 단계를 먼저 수행한다.

이어 현재의 조직체계와 프로세스와 현재의 시스템에 대한 정보들을 수집한 뒤, 이 요구사항들을 기반으로 현재의 시스템인 As-Is에 대한 명쾌한 기술을 통해 to-be 시스템의 비전에 대해 설계한다.

여기에서 가장 중요한 점은 기능적 요구사항과 비 기능적 요구사항을 명확하게 파악해야 한다는 점이다. 비 기능적 요구사항은 품질에 대한 요구사항이나 시스템 제약사항 등이 이에 해당된다.

그러나 아키텍트는 '기능'과 '비기능'을 전혀 다른 것으로 봐서는 안된다. 마치 '기능/비기능'은 동전의 양면과 같은 존재이기 때문이며, 서로 tradeoff의 중요한 관점으로 보아야하기 때문이다.

기능을 위해 비 기능을 축소하거나, 비 기능적인 요소인 성능을 위해 원하는 기능을 빼야하는 동전의 양면과 같은 요소라는 것이다. 모든 기능요소를 구현하는 것도, 모든 비 기능적인 요소를 구현하는 것도 SA를 디자인하는 아키텍트의 중요한 선택의 폭이라는 것이다.

일반적으로 기능을 '사용자와 직접적인 연관이 있는 업무'라고 한다면, 비 기능이란, 전체적인 시스템이거나 일부 기능들이 가져야할 일종의 속성에 해당한다. 특히 성능, 사용성, 편의성 등과 같은 비 기능적인 요소를 만족하지 못한다면, 전반적인 시스템이 개발된 이후 실패를 맛보는 가장 큰 요소가 되기도 하며, 심지어 모든 기능을 만족시켰지만 사용자의 편의성을 무시하고 개발되거나 엄청 느린 반응속도를 가진 프로그램이라면 해당 프로젝트는 실패하게 된다.

보통 우리들은 기존의 C/S프로젝트들을 웹(Web)화 하면서 이러한 비기능적인 사용자 편의성부분에서 차이를 보인다.

기존 C/S에서는 하나의 화면에서 모든 것을 처리했는데, 웹에서는 클릭수가 늘어나거나 반응속도가 느려지는 현상이 발생되는 것이 바로 그것이다. 이러한 현상은 초기에 비기능적인 부분에 대한 정의를 제대로 정의하지 못했기 때문에 발생하는 것으로, 전체적인 시스템 디자인에 대한 문제가 발견되는 것을 초기부터 알 수 있게 한다. 하지만 이를 무시하게 된다면 실패로 직결된다.

여기에서 문제는 이와같은 비 기능적인 요구사항에 대해서도 명확한 도출이 필요하다는 것이다. 이것이 아키텍트의 임무이며, 이를 고객에게 이해시키는 것이 가장 중요한 미션 중 하나다. 때문에 아키텍트에게 가장 필요한 기술은 커뮤니케이션 능력이라고 할 수 있다. 개발자들 간의 의사소통 뿐만 아니라 고객과의 효과적인 의사소통을 이끌어내는 능력을 가지는 것이 바로 아키텍트가 가져야 할 능력이기 때문이다.

더군다나 국내의 개발환경에서는 PM이 아키텍트의 말을 들으려 하지 않는다면, PM과의 의사소통 또한 틀어지기 때문에 가장 많은 신경을 써야 할 포인트가 되기도 한다.

 

<그림 > 비즈니스 모델 개발 활동

 

비즈니스 모델 개발활동에서는 사용자의 '비즈니스 적인' 기능적 요구사항과 업무규칙 등이 추가된다. 사용자의 전반적인 업무와 대응하는 프로세스를 모두 이곳에서 검증하거나, 필요한 유스케이스 모델들을 도출하고 필요한 비즈니스 객체 모델들을 도출하여 개발하는 과정을 보여주는 것이다.

 

솔루션아키텍처와 솔루션개발과정을 통한 '반복적인 개발 프로세스'

 

<그림 > 요구사항 정의 활동

 

요구사항 정의활동은 '유스케이스 모델 개발', '클래스 모델 개발', 'UI 모델 개발(프로토타입 수행)' 이라는 3단계가 진행된다. 이때, 기존의 CBD에서는 초기 아키텍처 정의가 있었지만 SA가 도입된 프로세스에서는 유스케이스 모델과 클래스 모델, UI 모델을 정의하는 단계라고 볼 수 있는데, 특히 중요한 유스케이스들의 모델들의 형태와 클래스 모델, 그리고 UX와 비 기능적인 성능과 관련된 부분들에 대해서 밀접하게 분석하고 정의하는 단계라고도 볼 수 있다. 요구사항에 대한 정의를 받아들일 유스케이스 모델들과 클래스 모델들, UI 모델들은 향후 시스템에 지대한 영향을 주게 된다.

이러한 내용들은 실제 아키텍처 정의와 평가, 상세화 단계를 거치면서 더욱더 견고한 단계로 변화할 수 있다.

 

<그림 > 아키텍처 설계 활동

 

유스케이스 모델, 클래스 모델, UI 모델을 통한 요구사항을 정의한 다음, 실질적인 아키텍쳐 설계과정에서 중요한 '아키텍처 관련 요구사항 분석'을 통해 시스템 컨텍스트를 정의할 수 있게 되는데, 이 단계에서는 Component&Connector View, Module View, Allocation View, Code View 라는 4가지 View를 구성하게 된다.

여기에서 4가지 View는 모두가 필요한 것은 아니며, 각각의 시스템 상황과 형태에 맞춰 필요한 View까지만 작성하면 된다.

SA에서의 주요 컨셉은 개발자들간의 의사소통에 필요한 단계에 대해서 정의를 내리고, 필요한 부분까지만 작성하면 된다는 점이다. 구체적으로 필요한 요구사항이 없는 형태까지 모두 기술 할 필요는 없다. 오히려 필요없는 상황들에 대해서 기술함으써 더욱 복잡한 형태가 만들어지기도 한다. 이와같은 단계에서의 활동을 '아키텍처를 모델링'이라고 할 수 있다.

 

 

 

<그림 > 아키텍처 평가 활동

 

<그림 9>는 설계된 아키텍처를 평가하는 과정을 보여주고 있다. 보통 이와같은 경우에는 기본적으로 작성된 아키텍처 문서를 평가하는데, 필요한 요구사항이나 품질, 기능/비기능적인 요소들을 만족하는지 검토한다. 다만, 이 부분에 있어서 '비기능적인' 품질 부분의 중요도가 높다면 프로토타입 기법이나 중요 테스트 단계를 거쳐 중요한 아키텍처의 키포인트를 테스트하는 단계를 거칠 수도 있다.

<그림 > 아키텍처 상세화 활동

 

아키텍처 상세화 활동은 '아키텍처 패턴'이라 불리는 아키텍처 스타일을 적용하거나, 필요한 요소들을 상세화 하는 것을 말하며, 유사한 프로젝트에서 필요한 아키텍처를 가져오거나 완성된 프레임워크를 도입하고, 해당 단계에서 실제로 필요한 패턴들을 도출하거나 설계 가이드라인을 구성하는 것 또한 포함된다.

이 단계에서는 평가된 결과를 바탕으로 아키텍처를 상세화하고, 상세 결과가 필요한 부분과 상세 설계를 구현하는 단계까지 진행되며, 설계와 구현을 진행하기 위한 가이드라인과 지침 작성 또한 이뤄져야 한다.

이때, 실제 설계와 구현을 진행하기 위한 팀원들의 수준 및 개발자들의 상황에 맞는 팀구성과 설계검증 및 개발 품질에 대한 체크사항들을 나열해야 한다. 그 이유는 저 수준의 개발자들이 많을 경우, 좀 더 패턴화한 개발방법으로 진행하는 것이 개발품질을 유지할 수 있도록 하거나 중요도가 높고, 고품질을 요구하는 부분을 최소화하는 방향으로 진행할 수 있기 때문이다.

이때 만들어지는 꽤 많은 가이드라인들은 가능한 최소화 하는 것이 중요하며, 개발툴의 자동화 혹은 템플릿의 활용이 최대한 이뤄지게 된다. 이외에도 빌드 방법이나 형상관리방안, 프로파일링을 통한 소스검증 방법에 이르기까지 다양한 설계 및 개발과 관련된 부분에 대해서 많은 부분을 아키텍트와 아키텍트 팀에서 준비하게 되는데, 이는 최선의 결과물을 도출할 수 있는 방법을 찾게 되는 것이다.

<그림 > 컴포넌트 식별 및 명세 활동( 컴포넌트 식별 및 명세의 작업내용 4가지.

- 컴포넌트 식별 및 구조화, 인터페이스 식별, 컴포넌트 명세서 작업, 컴포넌트 상호작용분석 )

 

 

<그림 > 컴포넌트 조달 활동

( 컴포넌트 평가기준 선정, 컴포넌트 선정 및 구매 )

 

<그림 11>과 <그림 12>는 컴포넌트와 관련된 활동들로써 CBD에서 기술하고 있는 내용과 크게 다르지 않다. 다만 컴포넌트를 식별하고 컴포넌트의 인터페이스에 대한 명세서를 작성하고, 필요한 컴포넌트의 평가 기준을 선정하고 구매나 형태를 정의하는 부분에서 과도한 컴포넌트형태로의 정의를 강요하기 보다는 정말 컴포넌트로써의 의미가 있는지에 대해서 아키텍트와 아키텍트 팀이 고민해야 한다는 점이 다를 뿐이다.

보통 업무단계에서 컴포넌트라고 불리는 부분들은 말 그대로 캡슐화와 향후 유지보수 단계에서 중요한 영역으로 구분되는 것으로, 실제 변동이 별로 없거나 정말 많은 부분에서 표준적으로 활용되는 부분이라고 하겠다.

또한 컴포넌트라고 불리는 부분들은 예외를 인정해서는 안된다. 실제 개발에 들어가서 예외를 인정하거나 일부분의 변경이 발생하는 부분이 있다면, 이러한 부분들은 비즈니스 컴포넌트로 구성되어서는 안되며, 개발자의 수준이 이러한 구분과 형태를 이해하지 못하거나 향후 유지보수 계획과 비용 부분을 모두 고려하여서 컴포넌트의 형태와 그 단계를 조절해야 한다.

정밀한 컴포넌트의 구현과 설계가 꼭, 프로젝트의 성공을 말하지 않는 다는 것은, 어느정도의 실무를 경험한 아키텍트들은 모두 알고 있는 내용이다.

다만 사용자의 UX와 접목되어서 향후 유지보수시 수시로 발생되는 부분에 대한 대응책을 이 부분에서 서술해두는 것이 최선이다.

보통의 유지보수는 거의 대부분이 UX관련된 부분에서 발생되므로, 이 부분에 대해서 얼마나 유연한 UI컴포넌트들의 배치와 형태, 유지보수 체계를 가지느냐에 따라서 시스템의 구성형태가 정말 판이하게 다른 구조로 만들어지기 때문이다.

 

--- 이후의 단계는 다음회로 넘겨도 괜찮습니다.

 

 

SA설계란 과연 무엇인가

 

이번에는 SA설계에 대해서 정리해보도록 7하겠다. SA설계는 크게 '인터페이스 정의, 요구사항의 우선순위 파악, 고객의 요구사항 파악이라는 3가지 중요 요소로 축약할 수 있다. 시스템적으로서의 중요한 부분은 시스템과 사용자간의 UX도 인터페이스요, 컴포넌트와 컴포넌트 사이의 인터페이스, 모듈과 모듈의 인터페이스에 있다.

더욱더 중요한 사실은 고객의 요구사항에 대한 반응이다. 고객의 요구사항을 어떻게 명확하게 파악할 것이며, 그 요구사항의 우선순위를 정확하게 파악하는 것이 바로 SA설계의 중요3가지 요소이다.

 

 

<화면 1> SA설계의 기초단계

 

SA설계의 기초단계는 <화면 1>과 같이, 사용자의 요구사항들을 수집하고 리스트를 관리하며, 해당 요구사항 리스트에서 작업의 우선순위와 품질요소를 결정하는 것이다. 또한 이러한 요구사항들을 통해 요구사항의 변경지표 및 시기, 변화의 내용들에 대해서 대응해야 한다.

사용자의 요구사항들은 중요한 UX와 컴포넌트들간의 연관관계에 영향을 끼치기 때문에, 사용자 요구사항을 명확히 관리하는 것이 최선의 프로젝트 품질요소 지표다.

해당되는 요구사항들에도 각각의 우선순위가 있다. 개발의 우선순위, 기능적인 우선순위, UX의 우선순위, 개발비용의 우선순위, 위험요소의 우선순위가 바로 그것인데, 이를 통한 다양한 프로파일링이 가능하다. SA설계의 3단계 과정을 표현하면 <화면 2>와 같다.

 

<화면 2> SA설계의 3단계

 

<화면 2>는 SA설계의 3단계를 중요한 지표로서 서술한 것으로, 가장 중요한 내부적인 SAD(Software Architecture Document)와 설계적 의사결정문을 구성하기 위해서 중요한 3가지의 단계를 거치는 것을 의미한다.

첫 번째는 작업 우선순위이며, 두 번째는 내·외부 반복 프로세스 수립, 세 번째는 업무 서브 도메인별 반복적인 분석 및 설계과정의 대량생산체계 수립이다.

이는 기능/비 기능과 이에 따라 파생되는 유지보수 단계 및 개발과 테스트, 아키텍처의 구성형태에 영향을 주는 작업의 우선순위에 대한 파악이 그 첫 번째이며, 중요한 요구사항들이 반영될때에 해당 프로세스에 대한 영향을 개발조직 내부와 업무조직 내부의 요구조건, 외부의 법이나 기타 연관관계에 따른 요구사항의 변경들에 대한 영향의 변화에 대한 프로세스들을 수립하는 것이 두 번째요. 실제, 분석/설계시에 대량생산과 수집, 패턴화가 가능한 요소들을 도출하는 것이 그 세 번째가 되겠다.

 

이번 컬럼에서는 SA설계의 기초적인 프로세스의 흐름과, SA설계를 하기 위한 기본적인 생각의 흐름과 주요한 요구사항에 대한 대응하는 방법에 대해서 알아보았다. SA에서 가장 중요한 것은 이 요구사항을 어떻게 아키텍처에 반영하고 이를 어떤 기능/비 기능으로 구분하여 관리할 것이며, 그 단계와 분석/설계에 대응하는 실제 개발팀에 대한 통제방법들에 대해서 고민하고, 실제 개발/유지·보수할 조직에 대한 예측을 해야한다는 것이다.

다만 아키텍트는 이러한 계획을 수립하고 필요 가이드라인을 구성할 때에, '불필요한 절차와 행위'에 대해서 독자적으로 구성하지 말고, 실제 수행할 개발조직과 팀원들과의 대화와 타협에 의해서 이를 구성하는 것이 가장 최선임을 잊어서는 안된다는 것을 강조하고 싶다.

 

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2011.01.22 08:59

[소프트웨어 아키텍트의 자격]

 

소프트웨어 공학과 아키텍처에 대한 이야기

소프트웨어 아키텍처 개론

 

소프트웨어 아키텍처는 소프트웨어개발에 있어서, 최고의 방법이 될 수 있을까? 방법이라는 측면에서의 접근방법으로서의 소프트웨어아키텍처. 그것의 기본적인 개념과 기초적인 내용들과 소프트웨어개발의 기본적인 자세에 대해서 생각해보자. 소프트웨어 아키텍처를 알아야 슈퍼프로그래머가 될까? 함께 고민해봅시다.

 

----------------------------------

신현묵 zetlos.tistory.com | 현재 명지병원 정보통신팀 팀장과 헬스로그 이사로 재직하고 있다. 제약, 의료기기 생산업체의 정보시스템 개발 경험과 온라인 게임개발, 대형SI에 이르기까지 경험이 풍부한 자칭 '삽질의 대가'. 현재 기존의 소프트웨어 삽질을 아키텍트로 승화시키려 노력하고 있다. 또한 현재 한국전자정보통신산업진흥회(KEA) 디지털병원수출기획단의 디지털병원 IT관련 실무위원으로도 활동 중이며, 새롭게 출범하는 IT의료융합센터의 자문위원으로도 활동할 예정이며, 독자들과 트위터(@zetlos)를 통한 소통을 즐기고 있다.

 

=========================================

 

원천적으로 가장 중요한 단어인 '소프트웨어'란 과연 무엇일까? 이 가장 기초적인 단어인 '소프트웨어란 무엇인가'에 대해서 다시 한번 생각해보자. 학자나 개인적인 입자에서, 여러가지 설명과 이해가 다르겠지만, 보편적인 부분만 설명한다면. 소프트웨어란 '사용자가 원하는 서비스를 제공하기 위하여 정보기술을 활용하여 정보서비스를 구축하는 것'이라고 규정지을 수 있다. 과연 어떤 단계가 소프트웨어 개발이란 무엇일까? 개발툴을 띄워서 '코딩'을 하는 것만이 소프트웨어개발일까? 소프트웨어 개발을 테스트하고, 품질을 검사하는 단계는 소프트웨어개발이라고 이야기할 수 있는가?

더군다나 '성공적인 소프트웨어 개발'이라는 단계는 어떤 단계일까? 필자는 '성공적인 소프트웨어 개발'을 다음과 같이 표현하고 싶다.

 

소프트웨어 개발자 + 고객 = 성공적인 소프트웨어 개발

 

소프트웨어개발자와 고객간의 의사소통과 필요한 요구사항과 적절한 정보서비스의 개발이 원활하게 이루어진다면, 가장 성공적인 소프트웨어개발이라고 할 수 있겠다. 생각해보면, 고객이 직접 자신이 원하는 소프트웨어개발을 한다면, 더 완벽하지 않을까? (ㅎ.ㅎ) 하지만, 현실적으로는 고객과 개발자의 역할은 분명하게 나뉜다.

하지만, 소프트웨어 개발의 변화가 과거의 1인 중심인 프로그래머가 혼자 모든 것을 다하던 시대에서 설계자와 코더가 나뉘어지고, 다시, 시대의 흐름이나 서비스중심의 구조적인 설계를 하는 아키텍트의 시대에 까지 변화가 많이 발생한다. 소프트웨어 개발의 조직이 정말 방대하고 복잡하게 변했기 때문이다. 고객의 목소리가 실제 개발조직에 전달되어지고, 어떤 단계를 거쳐서 실제 필요한 정보서비스로 변해가는 과정은 정말 블랙박스화 되어버려, 그 누구도 통제하기 어려운 형태로 변했기 때문이다.

이러한 소프트웨어개발과정을 통제하거나 개발자들간의 커뮤니케이션에 대해서 다양한 각도로 생각해보자. 가볍게 설명한다면 이 과정자체가 아키텍팅의 과제이고 단계이다. 이제, 이 지면을 통해서는 소프트웨어 아키텍처의 중요성이 부각된 이유를 설명하고 소프트웨어 아키텍처를 도입함으로써 어떤 목표가 달성될 것인가에 대해서 알아보겠다.

 

소프트웨어개발의 시대를 구분해본다면, 전설의 시대, 고대시대, 중세시대, 근대시대, 현대시대로 나누어서 설명할 수 있게다. 전설의 시대에는 '소스가 곧 라이브러리'이던 시대였다. 그리고, 고대시대는 'binary'기반의 라이브러리 시대라고 할 수 있겠고, 중세시대는 에디터가 존재하던 시대를 거쳐서. 근대시대의 'RAD툴'이 쓰여지면서 소프트웨어 개발을 하던 시대에서. 현대시대는 '서비스'를 중심으로 '프레임웍'의 시대라고 할 수 있겠다.

 

현실적으로 소프트웨어개발이 얼마나 어려운지 몇가지 나열해보자. 현대의 소프트웨어는 정말 많은 기능이 부여되어 있는데다가, 요구되는 기능의 변경은 정말 심하게 발생한다. 또한, 이렇게 구사되어진 소프트웨어 내부구조와 동작은 정말 비가시적이다. 더군다나, 소프트웨어 개발의 진행사항자체가 파악하기가 너무 어렵다. 그래서 일까? 개발비용이나 개발기간의 예측은 거의 도박수준이다. 또한, 정말 다양한 분야의 전문지식과 기술, 경험을 필요로 하는 것이 소프트웨어 개발이다. 거기다가, 컴퓨터 하드웨어/소프트웨어 기술은 정말 급격하게 발전하고 있는데다가, 다른분야의 공학적인 부분이 소프트웨어 공학의 이론단계에서는 아직 미성숙단계에 와있다고 하겠다.

 

좀더 전문적으로 소프트웨어의 특성에 대해서 설명해보자.

첫째. 소프트웨어의 유형적( tangibility )인 형태로 존재한다.

프로그램 코드의 형태로 존재하고 산출물로 가시화할 수 있다는점.

둘째. 소프트웨어의 상호작용 ( dynamic behavior )을 통한 완성

프로그램 자체는 분명 정적인 코드이지만, 소프트웨어자체가 구동되는 동적이고, 프로그램이 하드웨어에 의해 수행되고 사용자와 상호작용할때에 비로소 프로그램이 아닌 소프트웨어가 되는 것.

셋째. 소프트웨어의 상품성은 기본적인 가치이다.

개발된 프로그램은 제품에 불과하지만, 이 소프트웨어가 포장이되고, 사용자가 사용할 가치가 생기므로 상품이 된다.

넷째. 소프트웨어의 견고성은 유연할 수 없는 현실

소프트웨어 개발의 행위는 정말 예측이 어렵고, 수정이 용이하지 않다. 한번 구조성을 잃어버리면, 유지보수는 점점 어려워지워지게 된다. 말그대로 소프트하지 못하고 유연하지 못한 것이 소프트웨어이다.

다섯째. 소프트웨어의 비마모성 때문에 품질은 점차 저하된다.

소프트웨어는 하드웨어와 다르게 마모되지 않으므로, 시대가 변하면서 그 품질자체는 점차 저하되는 현상을 일반적으로 가지게 된다. 더군다나, 구조성을 잃어버리면서 유지보수과정을 거치면서 점점더 품질이 저하되는 특성이 있다.

 

그렇다면, 소프트웨어 개발과정에서의 특성은 어떤 것이 있을까?

 

하나. 소프트웨어 개발은 비제조성이다.

소프트웨어 개발은 말그대로 '개발'이다. '제조', '생산'되는 것이 아니다. 말 그대로 '개발과정'자체가 결국, 그 소프트웨어의 '품질'이 된다. 이러한 기본적인 원리를 무시한체, '공정'과 '생산계획'에 의한 소프트웨어 개발의 품질은 정말 엉망이된다. 성공적인 소프트웨어를 원하는 개발조직이나 고객이라면, 그 '개발과정'자체를 관리해야한다.

둘. 소프트웨어 개발은 비조립성이다.

말그대로 소프트웨어컴포넌트만 조립해서 소프트웨어가 개발되어진다면. 정말 제조업의 형태를 가지겠지만. 아직까지는 소프트웨어 개발은 '조립'이 불가능한 상황이다. '단순조립'이 가능한 시대가 올 수 있지만, 아직까지 그런 시대는 오지 않았다.

셋. 소프트웨어 개발과정은 정말 비과학적이다.

수학과 과학으로 모든 것이 설명될 수 있다면 얼마나 좋을까? 하지만, 소프트웨어개발은 '조직', '인력', '시간', '비용', '절차'와 같은 관리기술적인 요소를 통해서 만들어지는 정말 비과학적인 분야이다.

 

그렇다면, 이러한 소프트웨어 개발을 바라보는 관리자나 고객의 시야를 한번 살펴보자. 가장 잘못되어진 소프트웨어개발을 바라보는 3대 착각과 망상의 현상이 있다.

 

관리자들의 착각.

소프트웨어 개발방법이 '문서'나 '소스'코드에 상세하게 기록이 되어 있으니 개발자들이 어려움을 느끼지 않는다 라는 착각, 하드웨어를 비롯한 다양한 도구들의 개발환경만 좋아지면 개발자들은 불편하지 않을 것이다 라는 착각. 스케쥴이 지연되면 인력을 추가로 투입시키면 된다는 착각, 교육만 잘 시키면 우수한 소프트웨어 개발인력은 손 쉽게 확보 가능하다라는 착각.

사용자들의 착각

시스템의 정의와 개발목표가 정해지면 언제든지 프로그래밍은 착수가능하다는 착각, 요구사항과 상세내역은 발생할때마다 프로그램에 추가하는 것은 언제든지 가능하다라는 착각. 사용자의 요구는 지속적으로 변할 수 밖에 없는 것은 당연하니, 소프트웨어는 유연해서 언제라도 개발 도중에 변경되는 요구사항을 쉽게 수용할 수 있을 것이라는 착각.

개발자들의 착각

프로그램을 코딩하기 시작하고 테스트가 끝나면 개발자의 작업은 완결된다는 착각, 프로젝트가 완료되었을때의 결과는 작동되는 프로그램이다라는 착각. 개발단계에서의 결과물에 대한 검토회(review)는 정말 번거로운 일이라는 착각, 소프트웨어의 유지보수란 결함을 찾아서 수정하는 작업으로 간단한 일이라고 느끼는 착각.

 

필자가 생각하는 소프트웨어공학적인 형태를 표현하면 다음과 같다.

 

 

 

 

이 그림은 소프트웨어공학을 쉽게 설명하기 위해서 만든 그림이다. '소프트웨어공학'을 한마디로 표현하자면. '최소의 경비로 고 품질의 소프트웨어 상품의 개발, 유지보수 및 관리를 위한 모든 기법, 도구, 방법론'을 총칭하는 것이다.라고 표현할 수 있으며, 소프트웨어공학에서는 기법(technique), 방법(method), 방법론(methodology)의 기본으로써, 중요한 관리기법, 개발기법, 그리고. 사람에 대한 커뮤니케이션까지 포괄한 것이 '방법론'에서 이야기하는 중요한 요소일 것이다.

소프트웨어 생명주기 모델과 개발모델들의 발전단계를 살펴보면 폭포수모델->프로토타이핑모델->나선형모델->반복또는 점증적방법->컴포넌트기법과 모델까지 중요한 관점의 변화는 개발자들간의 의사소통과 관리에 대한 중요성을 점차적으로 늘려왔다는 점이다.

소프트웨어아키텍처는 이러한 방법론을 기반으로 한다. 작업절차, 작업방법, 산출물, 기법, 관리, 도구를 기반으로 소프트웨어를 구조적으로 바라보는 관점을 변화시킨다.

필자가 소프트웨어아키텍처를 강의하면서 가장 자주 말하는 것중의 하나는 다음과 같다.

'우리는 람보가 아니다'라는 점이다. 그래서, 정말 세심한 부분까지 고민하고 실천해야한다.

람보처럼 전쟁터에서 총알만 집어던져도 전투에서 승리하는 슈퍼프로그래머와 같은 프로그래머들만이 우리의 개발세계에 존재하지 않는 다는 점이다. 물론, 이런 '람보'같은 개발자들과 호흡하고 같이 일할 수 있다면 그것도 방법이기는 할 것이다. (이런 사람들은 정말 불가사의한 개발능력을 발휘하곤 한다. )

소프트웨어아키텍처를 이야기할때에 또하나 빼먹지 않고 이야기하는 관점은 'IT와 건축'에 대한 이야기이다. 현재의 모든 IT의 설명은 건축 메타포어를 통하고 있다. 심지어, 갑을병정의 사업구조와 형태까지 거의 동일하다. 아무래도, 전산학과의 역사가 짧아서인지는 모르겠지만, 전산학과의 기초중심( 코딩, OS, 자료구조, DB, 알고리즘 )의 교육에서 끝내지만, 건축학과는 기초에서( 미술실기, 구조역학, 건축재료와 기법 등)과 공학 ( 건축사, 건축설계 )등을 기본으로 배운다. 앞으로의 전산학과는 좀더 공학적인 기초교육이 좀더 보강될것으로 예측해본다. 기초위에서 기존에 구축된 시스템을 파헤쳐보고 설계중심의 교육이 이루어지는 방향으로 변할것이라고 생각해본다.

 

현재의 IT현장은 정말 건설현장과 비슷하다 하겠다. 새벽시장에 봉고로 필요한 인력을 구하듯이 거래되는 인력시장이 존재하고, 대기업들은 정말 그 노가다 인력으로 IT의 정보서비스들을 제공한다. 이름하여, '노가다'. 일본어인 dokata에서 만들어진. '공사판노동자','노동자','막일꾼','인부'라는 의미이고, 건축일등의 단순한 노동일을 일컫는 말이며, 특별한 직업이 없는 사람들이 흔히 일당제로 하는일을 의미한다.

우리 소프트웨어 개발자들은 과연 이러한 '노가다'와 어떤 차이가 있는가? 필자는 묻고 싶다. 아파트공사현장에서 등짐을 매는 노가다맨들이 과연 그 아파트를 만든 사람들이라고 이야기할 수 있을까? 아니, 실제 노동현장의 목수도 1층 2층 집은 충분하게 지을 수 있다. 요즘의 도구나 건설재료들은 그러한 구조학적인 설계를 하지 않더라고, 기본지식만으로도 그러한 건물을 지을 수 있다. 하지만, 63빌딩을 올리거나 시드니오페라하우스와 같은 건물은 만들 수 없는 것이다. 그래서. 우리에게 소프트웨어아키텍처는 정말 중요하다.

 

소프트웨어 아키텍쳐란 다음의 두가지가 가장 중요하다.

 

하나. 중요한 부분만 다루어야 한다.

둘. 아키텍트의 역할이 중요하다.

 

아키텍트는 소프트웨어를 개발할 때에 중요한 재료들을 잘 다루어야 한다. 그것은 비용, 적용기술, 조직의 역량, 기능, 목표, 시스템의 복잡도에 대해서 아키텍트의 중요한 판단을 통하여 시스템을 구상하고 추상화하는 방법이다. 이것이 바로 소프트웨어아키텍쳐의 기본적인 것이라고 볼 수 있다. '사용자가 원하는 서비스를 제공하기 위하여 정보기술을 활용하여 정보서비스를 구축하는 행위'인 소프트웨어 개발을 구상하고 추상화 하는 것. 그것이 소프트웨어아키텍처 과정이다. 그러므로, 아키텍트는 '소프트웨어 개발과 관련해 기술적인 판단을 내리는 최고책임자'라고 손쉽게 정의할 수도 있겠다.

건축가가 고객에게 이야기하는 것 '채광을 중시하고, 동서로 걸쳐진 건물에 정원을 배치한다'라는 추상적인 표현이 가능한것과 마찬가지로, 소프트웨어의 구상과 추상화를 완성하는 것이다.

그렇다면 이러한 소프트웨어 아키텍처를 프로젝트의 현실과 대입해보자.

현재 일반적으로 SI환경부터, 소규모개발사이던, 대형개발사이든 많은 개발과 관련되어진 여러 문제들이 존재할 수 있다. 다만, 이러한 문제들이 도출되지 않는 조직에 계시다면 정말 행복한 사람이다. 이곳에서는 소규모 프로젝트라기 보다는 대규모 프로젝트인 경우에 한정을 지어서 생각해보도록 하겠다.

각각의 사례들은 그 규모에 따라 그 형태를 달리하는 경우가 많다.

 

프로젝트 A : EJB를 기반으로한 EAI 제품 개발, 개발기간 3년, 투입인원 팀 4개팀 20명

프로젝트 B : SyncML관련 모바일 솔루션 개발, 개발기간 6개월 투입인원 5명

프로젝트 C : 온라인 게임개발, 개발기간 2년 투입인원 12명 ( 디자이너 제외 )

프로젝트 D : 공공기반 프로젝트, 개발기간 3년 투입인원 연인원 60명, 최대 130명

 

프로젝트의 성공여부는 어디에 달려있는것일까? 누가 성공여부를 결정하는가? 과연 프로젝트는 어떻게 진행되는 것이 맞는가? 과연 방법론의 사용여부는 어디까지이며? 산출물의 작성기준은 어디까지인가?

소프트웨어아키텍트는 이러한 것들을 커다란 개념으로 볼 수 있도록 한다. 예를 들어본 프로젝트들을 살펴보면 프로젝트 A와 B는 패키지 개발이고 실제 소프트웨어의 성향이나 목표에 대한 부분을 결정하는 것은 최고 경영자층과 CTO레벨에서 결정하는 내용이므로 오늘 설명할 내용에서 약간 벗어난다고 할 수 있다.

그리고, 프로젝트 C의 경우에는 일반 고객들을 상대로 하는 프로젝트이기 때문에 해당 프로젝트도 일단, 이 범위에서는 제외한다. 프로젝트 A,B,C에 대한 경험으로 별도의 각각 예제를 따로 준비중이고 아마도, 6회쯤에 해당 내용을 발표할 듯. 일단, 프로젝트 D를 기준으로 한다. 사용자들이 정해져 있고 보통 SI라고 불리우는 사업인 경우이므로 이에 대해서 기술한다. 프로젝트 D의 특징을 기술하면 다음과 같다.

 

하나. 프레임워크나 솔루션이 투입되어 일정한 공수로 개발자들이 투입되어 개발한다.

둘. 기존에 정보시스템이 있거나 대체, 혹은 신규 개발하는 형태이다.

셋. 고객이나 사용자들이 일반사용자들에 가까우므로 IT관련 정보기술에 어둡다.

넷. 고급개발자들을 극소수로 밖에 사용할 수 없으며, 초급개발자들을 주로 사용하게 된다.

다섯. 기간이나 비용등이 영업의 힘으로 결정되는 경우가 다반사이며, 생각보다 제약사항들이 많다.

여섯. 고객의 요구조건을 어떻게 관리하고 품질의 영역이 불명확한 경우가 많다.

 

가장 중요한 요소인 '소프트웨어 품질'에 대해서 아키텍트는 착각하면 안된다. 모든 소프트웨어는 100% 고품질로 만들 수 없다는 점을 깨달아야 한다. 그리고, 고민해야 한다. '과연 모든 모듈을 고품질화 시킬 필요가 있을까?' '유지보수성이 정말 필요한 부분은 어디인가?' '정말 고성능이 필요한 부분은 어디인가?' '기본 규칙만 지키도록 하고 대다수는 자동화하여 템플릿 형태에서 구현이 가능한 부분들은 어디인가?'

또한, 품질의 형태에 따라서 모두 같은 산출물과 문서화가 필요한가? 필자의 경험으로는 20%의 고성능과 80%의 단순함으로 승부하고, '고객'에게 '사용경험'을 어떻게 경험하게 할 것인가를 디자인해야한다는 것이다. 이러한 문제는 바로... '비용', '인력', '솔루션'에서 발생하기 때문이다. 언제나 적절한 비용, 인력, 기간, 솔루션과 기술은 완비되지 않기 때문이다.

또한, 가능한 아키텍트에게 UI와 UX에 대해서 준비하라고 언제나 이야기한다. 모든 정보서비스의 완성은 사용자의 경험에서 얻어지는 비기능적이인 경험에서 결론이 나기 때문이다. 이 부분은 이 소프트웨어아키텍처를 좀더 세분화하여 설명할 기회에 이야기해보도록 하자.

 

프로젝트의 일반적인 경향

 

첫째, 기술적인 결정을 내릴 때 비합리적인 결정을 내리는 경우가 많다.

대부분 기술적인 결정은 경험에 의해 이루어지는 경우가 많다. 그러나 경험적인 해결책이 현재 진행 중인 프로젝트에서 부적절한 경우 또한 대다수인 경우가 많다. 실제로 경험적인 결정만으로는 프로젝트에서 적용할 기술에 어떤 위험이 따르는지 판단하기 어렵다. 하지만, 보통 프로젝트의 경우 경험이 많은 개발자들을 중심으로 PM과 PL이 구성되어 지고 이들중에 PL들선에서 이러한 문제들을 해결하기 위한 미팅이나 회의가 많이 발생한다. 또한 기술적인 결정을 내릴 때 비용과 프로젝트 적합성을 따지지 않고 도입하는 경우가 많다. 이 경우 프로젝트의 기간을 줄이고 품질을 높이기 위해 도입된 기술이 오히려 프로젝트를 지연시키고 시스템의 품질을 떨어뜨린다. 기술적인 의사 결정이 프로젝트 중간에 흔들려서 프로젝트가 지연되는 경우가 종종 발생한다. 이것은 선택된 기술이 프로젝트에서 최적의 선택인지 고민하지 않았기 때문이다. 사용자의 요구사항에 기초하지 않은 의사 결정은 막연한 결과를 만들고 기술적인 의사 결정이 올바른 것인지 프로젝트 후에도 판단하기 어렵다. 의사 결정을 하기 위해 많은 시간을 소요하지만 합리적인 결정을 내리지 못할 때가 많다. 실제 영업적인 이유로 인하여 이와 같은 경우가 발생하는 경우도 다반사이다.

 

둘째, 새로운 프로젝트에서 과거의 경험을 답습하는 경우가 많다.

프로젝트는 전혀 새로운 환경 일때가 많고 프로젝트의 성격에 따라 최적의 선택을 해야 한다. 기술을 어떻게 선택할 것인지에 대한 정형화된 프로세스가 없으며 기술은 계속 변한다. 따라서 과거의 프로젝트 성공에 대한 경험으로 현재의 문제를 해결할 수 없다. 이점을 간과하는 경우가 많다. 따라서 많은 기술을 조합하여 현재 프로젝트를 위한 최적의 해결책을 찾아야 한다. 이 해결책은 사용자의 요구사항에서 논리적으로 도출된 것이어야 하며, 설명가능한 방식이어야 한다.

 

셋째, 과거의 프로젝트에서 배우지 못한다.

이것은 두번째 경우와 정반대의 경우이다. 과거의 프로젝트의 성공과 실패에서 원인 분석을 하지 못하면 성공한 이유도 실패한 이유도 알 수 없다. 프로젝트에서 대부분의 문제는 고객과 개발팀간의 커뮤니케이션 부재 때문에 발생한다. 또한 프로젝트의 범위 관리도 문제가 되며, 사용자의 요구사항을 어떻게 도출하고 관리할 것인가도 문제가 된다. 기술적으로는 시스템의 복잡성이 문제가 된다. 시스템의 복잡성은 개발자의 능력의 한계를 뛰어넘는 것으로 시스템을 복잡성을 줄이고 효율적으로 시스템을 구축하는 방안을 찾아야 한다. 기술적인 복잡성을 줄이고 합리적인 의사결정을 내리기 위해서는 기술적인 의사 결정을 초기에 내리고 적합한지 계속 테스트해야 한다. 또한 초기에 어떻게 프로젝트 조직을 구성할 것인가도 프로젝트 성공에 많은 영향을 끼친다. 역할 분담이 명확하지 않아서 책임 소재를 따지는데 많은 문제가 발생한다. 조직 구성도 프로젝트의 성격과 기술 Set에 따라 달라진다. 프로젝트 팀원들이 도메인을 잘 알고 사용하는 기술에 익숙한 경우와 프로젝트 팀원들이 도메인을 모르고 사용하는 기술도 모를 경우는 조직 구성이 달라져야 한다. 대부분 설계자가 요구사항을 정리하는 것 외에는 제 역할을 하지 못한다. 설계자가 어떤 일을 해야 하며 개발자에게는 무엇을 주어야 하는 지도 결정해야 한다.

 

넷째. 일정의 진실

소프트웨어 개발을 계획하고 관리하는 방법과 시스템은 많다. 정말 많다. 특정결과를 얻으려는 기법들을 모은 집합들. 이 기법들은 모두 조직문제와 프로젝트관리문제를 해결하려 애쓴다. 각 기법들에 각각의 장단점이 모두 다르다. 다만, 아키텍트는 어떤 방법론을 사용하던지, 프로젝트에 성공하려면 기본적으로 익혀야할 개념과 전술이 있다. 그것은, 어느 상황이든, 프로젝트와 팀에 맞게 방법론을 고치고 조율해야 한다는 점이다. 방법론에 치중하기 보다는 더 근본적인 지식에 근접해야한다는 점이다. 소프트웨어개발에 있어서 프로세스와 방법론이 매우 중요하기는 하지만, 프로세스와 방법론 자체가 만병통치약이거나 성공적인 결과를 보장하지는 않는다는 점이다. 필자가 자주쓰는 말이 있다.

 

'개발에 있어 형식에 얽매이는 행위야 말로 삽질이다-꿈꾸는자', 필자의 트위터에 걸려있는 프로필에 있는 말이며, 필자가 운영하는 아키텍트까페에서 이야기하는 첫 번째 교훈이기도 하다. 이론은 이론일뿐, 사람과 커뮤니케이션이 중요성을 잊어버리고, 절차에만 매달리는 행위에 대한 경고이기도 하다.

 

다섯째. 테일러주의를 벗어나지 못한다.

프레드릭 테일러라는 최초의 산업공학자를 대부분 아실 것이다. 공장의 효율성을 연구하여 '산업공학'이라는 분야를 만들었으며, 그의 제자들은 프랭크 길브레스, 릴리어 길브레스, 헨리 갠트와 같은 분들이 있다. 그의 주장의 핵심은 다음과 같다 '과학적 관리'를 중요시한 것이다. 테일러주의식 사회공학의 첫 번째 단계는 '계획'과 '실행'을 분리하는 것이다. 일하는 방법과 일하는데 걸리는 시간을 결정하는 것은 교육받은 공학자들을 통해서 한다. 그들은 작업자들에게 주어진 과업을 할당된 시간 동안 충실히 따르게 하면 모든 일은 잘 된다고 믿는다. 작업자들 자체를 기계부품으로 보는 방법이다. 두 번째 단계에서는 '품질부서'를 두게한다. 테일러는 작업자들은 할 수만 있다면 작업자들은 '꾀'를 부린다고 생각하여 품질부서를 통해서 적절한 속도, 정해진 방식으로 일하는지 확실하게 체크하는 방법을 사용하게 한다. 이런 방식으로 '기획/실행'을 분리하고 '품질부서'를 두게하는 방법은 현재의 소프트웨어 개발에서도 흔하게 쓰는 방식이다. 이 방식자체는 '개발과정'이 단순하다면 의미가 있다. 하지만, 고성능이나 기술지향적인 곳에서는 이런 방식자체는 문제가 있다. 앞에서도 이야기 하였지만, 소프트웨어 개발을 그런 제조업의 공장라인돌리듯이 생각하는 것 자체가 문제이기 때문이다.

 

자. 그렇다면. '성공적인 프로젝트'는 방법론을 잘 지켰는가에 대한 질문에 대해서 어떻게 답해야할까? '그렇다'라고 이야기하는 정답이겠다. 그것은 '방법론'의 '기본'에 충실하였기 때문이라고 이야기하는 것이 많다.

 

국내 프로젝트의 경향

 

첫째, 신기술을 도입하여 무조건 쓰는 경우가 많다.

J2EE가 프로젝트의 성격에 맞는지, CBD가 프로젝트의 성격에 맞는지 고민하여 프로젝트를 위한 최적의 선택을 한 경우가 많지 않으며 신기술에 대한 막연한 기대를 가지고 프로젝트를 시작한다.

둘째, 프로젝트의 복잡성이 증가되고 관리되지 않으면 어느 순간 통제할 수 상황에 빠진다. 이 경우 개발자들이 자체적으로 communication을 통해 해결하는 경우가 많다.

셋째, 프로젝트 초기에 드러나지 않았던 문제들이 프로젝트 마무리 시점에서 드러나는 경우가 많다. 많은 오류가 프로젝트 마무리 시점에서 발생한다.

넷째, 설계자가 제 역할을 못하는 경우가 많음. 단순히 사용자의 요구사항을 정리하여 개발자에게 전달하는 역할만을 함.

다섯째, CASE 툴의 사용이 개발 생산성 향상에 큰 도움이 되지 않음. 개발자들이 시스템을 구축하기 위해 미리 준비되어야 할 많은 사항들을 개발자 스스로 만들어 가는 경우가 많다. 시스템 환경 셋팅, 테스트, 각종 툴 사용 기법, utility 공통 코드, 코딩 표준 등을 개발자 스스로 결정한다.

여섯째, 몇몇 능력 있는 개발자들의 도움을 받아 프로젝트가 진행된다. (결과적으로 프로젝트에서 누군가는 아키텍트의 역할을 함) 그러나 능력 있는 개발자가 자신의 능력을 발휘하는 시점은 프로젝트의 문제가 발생하는 시점에서 이루어지고 개발자의 능력만으로 해결할 수 없을 정도로 이미 문제가 심각해진 경우가 많다. (왜 프로젝트 초기 의사 결정에 이런 사람들을 참여시키지 않는가?) 프로젝트 팀원들이 프로젝트 관리자에게 의사결정을 요구하지만 기술적인 문제는 프로젝트 관리자가 의사결정을 내릴 수 없으며 몇몇 사람들의 의견을 구하거나 의사결정이 이루어지지 않은 채 프로젝트가 진행되는 경우도 있다.

일곱째, 요구사항에 대한 관리가 이루어지지 않는다. 요구사항이 시스템에 얼마 정도의 영향을 미칠 것인지, 아키텍처에는 얼마 정도의 영향을 미칠 것인지 판단하지 못함.

그렇다면 위와 같은 프로젝트의 경우에는 어떻할것인가?

프로젝트를 포기하는 것도 하나의 방법일 수 있다. 혹은, 제약사항을 머릿속에 두고 그와 같은 아키텍쳐를 그려낼 수 있는 방법을 도출하는 것도 방법이다. 어떤 프로젝트이던 최고의 방법은 없다. 최선의 방법만 존재할 뿐. 실제 프로젝트에서는 최고의 비용, 최고의 기간, 최고의 프로그래머와 일하는 것이 아니기 때문이다. 이러한 것들을 해결하기 위하여 무수히 많은 것들이 존재하지만, 이곳에서는 이러한 문제들의 구조를 파악하고 소프트웨어를 제작하기 위한 소프트웨어 아키텍쳐에 대해서 서술해보자. 그리고. 아주 보통 간과하고 넘어가는 경우가 많은데. 다음의 예를 하나 살펴보자. 사용자들이 요구하는 아주 비기능적인 요소들이 있다.

 

'동일 조회업무 화면을 여러 개 보이게 해주세요'

 

자.. 이러한 요구조건을 어떻게 해결해야 하는가? 생각보다 복잡하고 미묘한 문제들이 걸려있다. 어떤 부분인지 살펴보자. 일단, 어떤 사람이 개발한 업무화면이 "N개 동작한다라는 것은 그 업무화면에서 여러 개 동작시키는 매커니즘을 활용하는 방법도 있을것이고, 해당 프레임워크를 제공할 수도 있을 것이고, 아니면, 웹과 마찬가지로 세션을 유지하지 않는 방법을 고려할 수도 있다. 사용자의 기능하나에 의하여 구조적인 모습이 전혀 엉뚱한 모습으로 변할 수 있다.

이러한 요구조건들이 품질요구사항으로 변하고 실제 소프트웨어의 아키텍쳐와 프레임워크, 솔루션의 도입, 개발자들의 가이드라인, 컴포넌트의 구성방식, 유지보수 방법등에 많은 영향을 주게된다. 이 부분을 간과하고 넘어간 경우를 살펴보자. 업무 분석을 하고 설계, 개발, 단위테스트, 통합테스트, 배포까지 무난하게 넘어갔다고 보자. 그런데, 실제 사용자가 요구한 것은 '전체 업무의 형태를 위와 같이 N개 동작하게 해달라'는 요구사항이었다고 나중에 밝혀졌다고 보자.

설계자는 요구조건에 맞는 프레임워크가 아니었다고 이야기 할 것이고, 개발자는 세션을 유지하는 C/S 프로그램으로 만들어 놨고, 공통 함수로 처리되는 방식으로 빠르게 개발할 것만 고려하고 플밍이 되었다고 보자.

과연 누구의 잘못인가? 이것이야 말로 아키텍트가 초기에 소프트웨어 아키텍쳐를 잘못설계한 케이스이다. 처음부터 이러한 상황을 고려하여 동작 가능한 구조로 만들어 주었다면, 문제가 발생하지 않았을 것이다. 개발자가 컴포넌트 개발도 할줄 모르는 공통함수개념과 화면별 단위 프로그램밖에 만들줄 모르는 개발자였다면, 해당 개발자들이 해당 요구조건을 모르고 코딩을 해도 실제 수행시에 아무 문제 없도록 시스템 메커니즘을 구현하였어야 했다. 해결방법은 아주 많은 방법들이 있다.

 

그렇다면, 설계와 SA의 차이점은 과연 무엇일까?

물론, 공통점은 '요구사항을 만족시키기 위한 해법을 제시한다'라는 측면에서는 같다. 차이점은 '아키텍트의 관점은 좀더 큰 그림을 보고, 설계는 미시적인 관점이다'라고 쉽게 설명할 수 있겠다. 아키텍트는 좀더 기능적인 요구사항이나 품질요소등에 대해서 구분하고 있게 된다. 이러한 관점의 차이는 설계나 방법론, 산출물에게도 영향을 준다.

바로, 품질속성(Quality Attribute)를 결정하고 그 품질속성을 관리하는 것이 SA가 가지는 가장큰 차이점이라고 하겠다. PM과 SA에 대한 차이점도 몇가지 언급해보자.

 

 

소프트웨어 아키텍처를 도입하면서 달성되는 목표

 

소프트웨어 아키텍처를 도입함으로써 다음과 같은 목표를 달성할 수 있도록 한다. 그 목표는 크게 다음의 세가지로 들 수 있다.

 

첫째, 견고하고 안정적이며 고품질의 시스템을 구축할 수 있다.

둘째, 시스템 구축 시 발생하는 문제들을 초기 단계에서 해결할 수 있다.

셋째, 아키텍트의 역할을 명확히 정의하여 20%의 고급 인력으로 80%의 프로젝트 인원을 리딩할 수 있다.

 

아키텍트는 비용과 목표에 대해서 가장 많은 고민을 하여야 한다. 최고의 개발자들로만 구성하여도 프로젝트는 실패할 수 있다. 튼튼하고 품질 좋고 나중에 문제 발생하지 않고, 비용이 적게든다면 최선이지 않은가?

 

 

그림2는 소프트웨어 아키텍처 도입 시 시스템 개발 프로젝트에서 어떤 도움을 받을 수 있는지를 한눈에 보여준다.

 

첫째, 소프트웨어 아키텍처 도입 시 아키텍처의 품질을 평가하여 비합리적인 의사 결정이 합리적인 의사 결정으로 변경된다.

둘째, 과거의 경험을 답습하거나 과거의 사례에서 배우지 못했던 것에서 소프트웨어 아키텍처를 재사용함으로써 과거 프로젝트의 성공과 실패 사례를 배우는 것으로 변경된다.

셋째, 프로젝트의 복잡성을 아키텍처를 통해 관리하는 것이 가능해진다.

넷째, 프로젝트 마무리 시점에서 발생하는 문제들을 아키텍처를 도입하여 프로젝트 초기에 해결할 수 있다.

다섯째, 설계자가 단순히 요구사항을 개발자에게 전달하는 것을 아키텍처를 통해 설계자가 요구사항 분석뿐 아니라 기술적인 문제도 모델링 할 수 있게 하며 개발자는 더욱 효율적으로 시스템을 구현하는 것이 가능하다.

 

소프트웨어 아키텍처의 목적

첫째, 아키텍트가 프로젝트 시작 시점에서 투입되어 무엇을 하는지 시나리오를 작성할 수 있게 하며

둘째, 소프트웨어 아키텍처가 개발 프로젝트에 정착될 수 있도록 하고

셋째, 아키텍트의 역할에 대해서 정의를 하며

넷째, 아키텍트와 프로젝트의 구성 요소 사이의 관계에 대해서 이해를 한다.

다섯째, 소프트웨어 아키텍처가 포함된 개발 프로젝트의 프로세스는 무엇인가에 대해서 알아보고

여섯째, 아키텍트가 프로젝트에서 결정해야 할 항목은 무엇인가에 대해서 고민하는 것이다.

 

소프트웨어 아키텍처 란?

 

본격적인 소프트웨어 아키텍쳐의 개념에 대해서 알아보도록 하자. 소프트웨어 아키텍쳐란 무엇이며, 아키텍트란 누구이며, 그의 역할과, 소프트웨어 아키텍쳐를 통하여 개발 프로세스와 어떤 영향을 가지며, 소프트웨어 아키텍쳐와 다른 아키텍쳐가 어떤 관계를 가지는가에 대해서 알아봐야 한다. 이 부분은 다른 필자들이 좀더 자세하게 설명할 것이다.

 

소프트웨어 아키텍처의 정의

가장 먼저 다른 사람들의 소프트웨어 아키텍쳐에 대한 정의에 대해서 알아보고 이 곳에서 사용할 소프트웨어 아키텍쳐의 정의에 대해서 알아보도록 한다. 아직도 소프트웨어 아키텍쳐에 대한 "정의는 무수히 많은 곳에서 정의되고 정답자체가 아직은 모호한 분야라고 할 수 있으므로, 각자 머릿속에 그 "정의를 선택하거나 정의할 수 있고, 그 부분들에 대해서 생각해 봐야 한다.

 

소프트웨어 아키텍처의 정의들

 

고전적인 정의

 

Rational Unified Process, 1999 Perry and Wolf, 1992 Garlan and Shaw, 1993 Bass, er al., 1994 Hayes-Roth, 1994 Garlan and Parry, 1995 Boehm, et al., 1995 Soni, Nord, and Hofmetster, 1995 Shaw, 1995

 

ANSI/IEEE Std 1471-2000정의

 

Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. This de.nition is intended to encompass a variety of uses of the term architecture by recognizing their underlying common elements. Principal among these is the need to understand and control those elements of system design that capture the system's utility, cost, and risk. In some cases, these elements are the physical components of the system and their relationships.

 

Bass, Clements, Kazman의 정의

 

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

The term also refers to documentation of a system's software architecture. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects

Bass, Len; Clements, Paul; & Kazman, Rick. Software Architecture in Practice, Second Edition. Boston, MA: Addison-Wesley, 2003 "프로그램 또는 연산 시스템의 소프트웨어 아키텍처는 소프트웨어 구성요소와 구성요소의 외부로 보이는 속성 그리고 그 구성요소간의 관계로 이루어진 구조 또는 시스템의 구조이다. " " 그리고 아키텍처의 문서화와 관련된다. 상위단계의 디자인에 관한 초기 의사 결정 사항과 프로젝트간의 패턴과 디자인의 재사용을 허용하기 위해 기록한 아키텍처의 문서화는 이해당사자간의 의사소통을 진행시킨다. "

 

Dewayne E. Perry, Alexander L. Wolf의 정의

소프트웨어 아키텍처는 특별한 형태를 가진 아키텍처 구성 요소들의 집합이다. 아키텍처 구성 요소는 세가지로 구분된다. 프로세스 구성 요소, 데이터 구성 요소, 연결 구성 요소로 구분된다.

 

 Galarn and Perry의 정의

소프트웨어 아키텍처는 프로그램이나 시스템의 구성 요소들 사이의 구조, 관계, 설계와 시스템 업그레이드를 통제하는 지침과 원칙이다.

 Booch의 정의

소프트웨어 아키텍처는 소프트웨어의 구조에 대한 중요한 의사 결정의 집합이다. 이 의사 결정에는 소프트웨어 구성 요소에 대한 선택, 인터페이스에 대한 선택, 이 구성 요소들 사이의 상호작용, 더 큰 서브시스템을 구성하기 위한 구성 요소와 상호작용의 결합으로 이루어진다.

 Myron Ahn의 정의

소프트웨어 아키텍처는 모듈, 프로세스, 데이터, 이들의 구조, 구성 요소들 사이의 관계, 이 구성요소와 관계들이 어떻게 확장되고 수정될 수 있는지, 사용하는 기술은 무엇 인지로 이루어져 있으며 소프트웨어 아키텍처를 통해 시스템의 유연성과 성능을 판단 할 수 있고 시스템을 어떻게 구현하고 수정할 수 있는지를 판단할 수 있다.

 

위의 같은 다양한 정의가 존재하므로 자신만의 정의를 만들거나 선택해보라, 실제적으로 이 개념들은 하고자하는 프로젝트에 따라 다르게 존재할 수 있다. 소프트웨어아키텍처에 대한 정의는 결국, 아키텍트들이 가지고 있는 정의에 따라서 다양한 관점으로 해석될 수 있는 것이지 정해져있는 '개념'과 '단어'가 아니다. '건축설계'를 '단어'로 설명할 수는 있겠지만, 그 행위 자체를 정의할 수 없기 때문이다. 그래도, 필요하다고 한다면, 약간의 정의를 해보자.

 

소프트웨어 아키텍처에 대한 정의

위의 정의들을 요약하여 소프트웨어 아키텍처를 다음과 같이 정의하여 보자. 소프트웨어 아키텍처는 시스템의 핵심 구성 요소와 구성 요소들 사이의 연결 관계로 이루지므로. 핵심 구성 요소는 시스템이 가지고 있는 모듈, 모듈 사이의 연결, 시스템의 변경, 진화하기 위한 기술적인 원칙, 모듈들 사이의 상호작용, 시스템이 동작하기 위한 기술을 모두 포함하는 것으로 정의한다. 즉 소프트웨어 아키텍처는 구현할 시스템에 대한 top-down view이며 시스템에 대한 기술적인 명세서이며 공학적인 청사진이다. 기본적인 개념은 MDA에서 취하고 있는 방향과 유사하다.

 

소프트웨어 아키텍처의 구성 요소

소프트웨어 아키텍처의 구성요소에 대해서 상세하게 살표보면 다음과 같은 구성 요소로 이루어짐을 알 수 있다.

 시스템의 구성요소와 구성 요소 들 사이의 연결 관계

 시스템의 설계와 진화를 통제하는 원칙과 가이드라인

 시스템 구성 요소들의 collaboration ( 성과 )

 시스템이 어떻게 확장되고 수정될 것인가에 대한 결정

 시스템의 구성 요소들이 가지고 있는 기술

다음 그림은 소프트웨어 아키텍처의 구성요소를 보여준다.

 

 

그림5를 보면 소프트웨어 아키텍처는 세가지로 구분된다.

 

Meta-Architecture는 아키텍처를 설계하기 위한 일반적인 지침이다. Meta-Architecture는 소프트웨어 아키텍처가 무엇인지 결정하고 아키텍처를 설계하기 위한 일반적인 의사 결정 트리와 아키텍트의 역할에 대한 정의, 아키텍처 문서에 대한 템플릿으로 구성된다.

소프트웨어 아키텍처는 네 가지 View인 module view, component&connector view, allocation view, code view로 구성된다. 또한 아키텍처 설계의 결과로 컨텍스트 다이어그램, 컴포넌트 명세, 인터페이스 명세가 도출되어야 한다.

View에 대해서는 사람마다 정의하는 방법이 다양하므로 이에 대한 논란은 나중에 하도록 하고, 먼저 그냥 서술해보자. 이 View는 사람들마다 서술하는 방법, 기술하는 방법, 다이어그램의 형태, 박스/라인/인터페이스/컴포넌트의 수준과 깊이/의미등이 다 다르다.

다만, View의 선정 기준과 기술할 때 주의점만 살펴보면된다.

건축물을 설계할때의 조감도 및 설계도, 세부 설계도, 투시도 등등의 형태와 동일하다고 보면 된다, 필요수준까지만 각자 알아서 그리면 되는 것이다. 일반적인 view는 3가지이다. Allocation View, Component & Connector View, Module View라 이야기하지만 저는 Code view를 하나 더 구분해야 한다고 본다. 너무 상세한 설명은 나중에 거론하기로 하고 하여간 4개의 View가 있다고 보자. 이 부분은 적어도 1개 이상에 대해서 기술하고 몇 개가 적절한 가는 개발자들의 역량과 도메인에 대한 이해, 이전 프로젝트의 경험 및 주요 이슈 사항등의 요소에 의해서 좌우되어진다. 다만, 시스템의 큰 기능, 품질 속성 ( 가용성, 변경성, 보안성, 성능 )의 판단 근거가 되어야 하며, 주요 모둘의 기능이 내/외부와 어떤 연관성을 가지는지 보여야 하고, 시스템의 규모와 범위를 파악할 수 있으면 된다. 또한, 위와 같은 아키텍쳐 기술 정의서를 구축할 때에 타당한 근거를 서술할 수 있으면 된다. 다만, 이 View를 UML 1.x영역에서는 표현하기 힘들었다. 너무 기술에 종속적인 패턴의 설계 혹은 컴포넌트의 배치 레벨에서의 작성이 주였기 떄문이다. UML 2.0울 구성할때에 OMG에서 카네기 멜론 SEI의 아키텍쳐 정의를 상당부분 도입하여서 이 부분들에 대한 기술이 이젠 수월해진 편이다. OMG는 재미있는 기관이다. 좌우당간… 가이드라인과 정책은 소프트웨어 아키텍처를 결정한 후 아키텍처를 기반으로 프로젝트를 진행하기 위한 가이드라인과 정책을 말한다. 아키텍트는 설계, 코딩, 배포, 통합, 테스트, 툴, 유지보수, 시스템 확장, 시스템 운영에 대한 가이드라인과 정책을 마련해야 한다. 정말 포괄적인 개발정책 부분을 모두 서술하고 결정한다는 것이다. 소프트웨어 아키텍처는 시스템 개발의 여러 구성요소와 관련을 갖는다. 프로젝트 조직, 프로젝트 스케줄, 형상 관리 계획은 소프트웨어 아키텍처에 근거하여 결정된다. 소프트웨어 아키텍처를 설계하는 데는 프로토타입, 프레임워크, 유틸리티 프로그램 등이 영향을 끼친다.

 

소프트웨어 아키텍처의 특징

소프트웨어 아키텍처의 특징은 다음과 같다. 첫째, 소프트웨어 아키텍처는 시스템에 대한 추상화이다. 따라서 지엽적인 정보는 포함하지 않는다. 큰 그림만을 가지고 있는다.

둘째, 소프트웨어 아키텍처는 한가지 다이어그램으로는 결정되지 않으며 여러 관점의 다이어그램으로 이루어진다. 각각의 세부적인 것이 아니라, 건축물의 투시도와 같으며, 옷 디자이너의 스케치와 유사한 성격을 가진다.

 

소프트웨어 아키텍처의 역할

 

소프트웨어 아키텍처가 시스템 개발에서 담당하는 역할은 다음과 같다고 볼 수 있다. 첫째, 관련 당사자들 사이의 의사 소통의 수단이다. 둘째, 개발 프로젝트 초기 단계에서 의사결정 도구이다. 아키텍처는 품질 요소를 결정하며 프로젝트 조직에 영향을 끼친다. 셋째, 시스템의 전체 구조를 결정한다. 넷째, 개발 프로젝트의 조직을 결정하는데 참고할 수 있다. 다섯째, 시스템이 가져야 할 품질 요소를 결정한다. 따라서 아키텍처를 통해 시스템이 어떤 품질을 가질 것인지 예측할 수 있다. 여섯째, 아키텍처를 통해 시스템 개발자들에게 어떤 교육을 시킬 것이지 결정할 수 있다. 일곱째, 소프트웨어의 변경 사항을 어떻게 관리할 것인지를 알려준다. 상당한 역할이지 않은가? 이를 도식화 하면 다음과 같은 그림이 만들어진다.

 

 

소프트웨어 아키텍처가 시스템 구축 시 담당하는 역할을 보여준다.

기능적, 비기능적 요구사항은 소프트웨어 아키텍처를 설계하는데 입력 산출물로 작용한다. 소프트웨어 아키텍처가 결정되면 설계패턴과, 설계 가이드라인을 사용하여 소프트웨어를 설계할 수 있다. 또한 소프트웨어 아키텍처가 결정되면 코드 작성시 코드 표준, 코드 가이드라인을 제공할 수 있다. 또한 소프트웨어 아키텍처는 소프트웨어를 시스템에 배포 시에 가이드라인을 제공한다. 이를 반복에 의해서 구조적으로 안정적인 소프트웨어 아키텍쳐를 구성할 수 있다

 

소프트웨어 아키텍처에 포함되지 않는 것

소프트웨어 아키텍처는 하드웨어, 네트워크, 물리적인 시스템에 대한 아키텍처를 포함하지 않는다. 따라서 소프트웨어 아키텍처 설계서는 시스템 안에 포함된 소프트웨어 만을 보여주며 시스템은 컨텍스트로서만 표현된다. 예를 들어 하드웨어 모델명, 하드웨어 구성, 라우터, 랜카드에 대한 정보는 소프트웨어 아키텍처에 포함되지 않는다. 이를 그린다는 것은 그 것에 종속된다는 의미이므로 "추상화하려면 해당 정보가 표시되면 안된다는 것이

다. 세부적인 구현 사항은 소프트웨어 아키텍처에 포함되지 않는다. 예를 들어 컴파일러 옵티마이제이션, DLL을 shared로 할 것인지, static으로 할 것인가는 소프트웨어아키텍처에 포함되지 않는다. 이는 별도의 의사결정과정과 후반부에서 처리한다.

 

맺음말...

 

소프트웨어아키텍처에 대해서 아주 기본적인 정의 몇가지를 이야기하는 시간을 가져봤다. 보다 본격적인 내용들은 향후 지면을 통해서 좀더 자세하게 설명할 기회를 가질것으로 생각해본다. 마지막으로 필자의 트위터 프로필에 있는 말로 마무리하고 싶다.

 

'개발에 있어 형식에 얽매이는 행위야 말로 삽질이다.'

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2011.01.22 08:57

[수퍼개발자의 꿈]

 

U-헬스케어 개발에 도전하는 개발자에게…

의료와 IT개발자의 컨버전스

 

의료와 관련된 분야에서 전통적인 HIS분야와, PACS, OCS(CPOE), EMR 등의 분야와, 새로운 의료서비스와 소셜등이 결합되고, 많은 변화가 보여지는 새로운 세계에서 과연 개발자로써의 꿈은 과연 어떤 것을 꿈꾸고 있는가? 필자는 수퍼개발자는 아니지만. 수퍼개발자의 꿈을 꾸었던 사람으로서, 후배들에게 몇마디 남기고 싶어서 펜을 들어본다.

 

----------------------------------

신현묵 zetlos.tistory.com | 현재 명지병원 정보통신팀 팀장과 헬스로그 이사로 재직하고 있다. 제약, 의료기기 생산업체의 정보시스템 개발 경험과 온라인 게임개발, 대형SI에 이르기까지 경험이 풍부한 자칭 '삽질의 대가'. 현재 기존의 소프트웨어 삽질을 아키텍트로 승화시키려 노력하고 있다. 또한 현재 한국전자정보통신산업진흥회(KEA) 디지털병원수출기획단의 디지털병원 IT관련 실무위원으로도 활동 중이며, 새롭게 출범하는 IT의료융합센터의 자문위원으로도 활동할 예정이며, 독자들과 트위터(@zetlos)를 통한 소통을 즐기고 있다.

 

=========================================

 

병역특례로 시작한 전업 프로그래머의 삶, 군대에서도 프로그래밍, 건축회사에서 처음 만들어본 AutoCAD관련 서드파티 프로그래밍, 건축관련 소프트웨어 개발, 친구들과 자취방에서 컴퓨터 3대 놓고 시작한 소프트웨어 하우스, 자동화엔진을 만들어 보겠다는 프로젝트, 그룹웨어 프로젝트, 인맥관리소프트웨어, 네트웍 관련 유틸리티, 미들웨어 개발, CORBA관련 프로젝트, JavaBeans 컨테이너 개발, SyncML프로젝트, UML표준화 활동과 OMG, 온라인게임소프트웨어 개발, SI프로젝트에서의 프리랜서의 삶, 아키텍트로써의 프로젝트의 참여, 의료/제약회사의 경험, 디지털병원 프로젝트 등… 필자는 참 파란만장한 인생을 살아오면서 참으로 많은 사람들을 만났고, 재미있고, 유쾌한 프로젝트들에 대한 경험도 많이 해왔고, 그러던 중 필자는 어느사이에 소프트웨어 관련 경력이 20년이 다되어 가는 중견 개발자가 되었다.

그렇다면, 과연 나는 수퍼개발자일까? 필자의 생각에서 정확하게 이야기하면 '아니올시다'이다. 나는 다만, '제대로된 소프트웨어'를 개발하고 싶은 작은 꿈을 가진 개발자일 뿐이었다. 그리고, 그러한 꿈을 실현하기 위해서 노력을 할 뿐이었기 때문이다.

필자는 개발자로서 수많은 경험을 하면서도 언제나 새로운 분야를 찾은 것도 있지만, 다양한 실패를 정말 많이 경험한. 소위 '실패한 개발자'라고 표현하고 싶다.

어느것 하나도 제대로 만들어 본 프로젝트가 없다고 해야할까? 정말, 성공적이라고 생각하는 개발이 단 한번도 없었다고 해야할까? 기회가 된다면, 나중에라도 이런 실패담을 기록한 책도 한번 써보고 싶다는 생각을 한다.

지금 필자는 다시금 이런 개발에 대한 꿈을 꾸기에 다시 현업으로 복귀했고, 새로운 병원정보시스템을 디자인하고 아키텍쳐링하고, 관련 부수적인 주변환경을 만들고 있다. 어찌보면 그동안의 다양한 실패경험을 바탕으로 이번에는 정말 성공적인 소프트웨어 개발을 하고픈. 그럼 마음이기에 요즘은 정말 즐거운 하루하루를 보내고 있다.

 

개발자는 '언어를 만드는 사람'이다

 

소프트웨어 개발자는 새로운 언어를 만드는 사람이라고 이야기한다. 특히 어떤 업무를 만나건, 어떤 프로젝트를 하건, 그것은 새로운 표현법과 표기법을 만들고, 그것을 서술하는 작가라고 볼 수 있다.

필자는 그동안 만난 수많은 후배들에게 이런 이야기를 자주한다. 에디터에 펼쳐진 수많은 언어들의 나열들. 이런 배열을 잘 살펴본다면, 우리는 작가라고 할 수 있을 것이다.

물론, 그러한 글을 읽고 이해할 수 있는 사람들은 그렇게 많지 않을 것이고, 우리는 바보같은(?) CPU라는 녀석이 이러한 글을 제대로 이해하기를 바라고 장편의 소설을 한편 쓰는 것과 같다.

한편으로는 직접적으로 CPU의 머릿속에 기계어로 대화를 나누면 좋겠지만, 솜씨좋은 컴파일러들과 다양한 개발툴로 이러한 유여한 대화와 저술(?)활동이 가능하다.

필자는 예전부터 개발자들에게 책이나 유려한 글들을 많이 보는 것이 좋은 개발에 도움이 된다고 역설해왔었다. 뭐랄까? 자신이 써내려가는 글에 대해서 가능한 미적으로도 아름답고, 나중에 봐도 창피하지 않는 글들을 만들라는 선배의 조언이었다고 해야겠다.

개발자들이 만드는 수많은 영역들의 소프트웨어들. 보통 소프트웨어를 개발하다보면, 다양한 단계로 진화한다. 일명 'C&P신공'이라 불리우는 Copy and Paste 신공을 발휘하는 기초적인 텍스트 소스레벨의 공유에서부터 바이너리 라이브러리 수준의 공유방식, 그러기 위한 다양한 유닛과 펑션, 헤더파일들의 분리 기법, 단순한 호출이 아니라, 지식과 경험의 전달을 위한 유연한 클래스의 설계와 프레임웍과 객체의 디자인 방법, 그리고 궁극적으로는 유사한 아키텍처 스타일을 도출하며 말 그대로의 아키텍처 패턴과 실제 패키징되는 형태에서의 유연한 대응방법과 다양한 패키징을 위한 스크립트의 활용과 형태의 구성 등… 개발자들은 궁극적으로는 해당업무나 도메인에 맞는 언어를 디자인하게 된다.

요즘의 형태로 이야기한다면, 서비스디자인 중심의 구조라고 해야할까? 필자는 어떤 업무나 소프트웨어도 궁극적으로는 각각의 단위 서비스를 충실하게 구현할 수 있는 새로운 언어를 창조하는 단계까지 진행한다고 생각한다.

이 말은 어찌보면, 과거에 환상처럼 불리우는 최후의 개발자가 되기 위한 또 다른 단계를 진행하는 것과 동일하다고 볼 수 있겠다.

Smalltalk와 같은 시스템이 필자가 꿈꾸는 최후의 시스템 형태일까? 생각해보면, 요즘 아이폰과 같은 스마트폰의 개발방식이나 형태, 구글 보이스와 같은 인터페이스와 수많은 형식의 조합의 완성에 대해 생각해보자. 아마도 각자 필요한 소프트웨어를 스마트폰에 이야기하듯이 이야기하면, 그 녀석이 필요한 앱을 설치하거나 매쉬업을 어느정도 자연스럽게 하는 제품이 탄생할 일도 그렇게 멀지 않은 것 같다.

앞서 언급된 내용들이 실현에 옮겨질 그때가 되면, 우리는 스마트폰이나 PC에 대고 필요한 이야기를 하고. 전격Z작전에 나왔던 키트와 같은 녀석들과 친구가 될 것이라고 생각한다. 이와같은 소박한 꿈을 계속 꾸는 '꿈꾸는 자'가 많은 세상. 바로 필자가 오랜시간 꿈꿔온 세상이고, 그 세상에 사는 꿈꾸는 사람 중 하나가 필자라고 얘기하고 싶다.

 

그렇다면 지금부터는 필자가 경험한 다양한 분야에 대해서 이야기하는 것 보다. 요즘 가장 세상의 중심이되는 헬스케어분야에 대해서 이야기해보도록 하겠다.

 

의료산업에 대한 고찰

 

지난 5월부터 마소를 통해 필자가 연재했던 내용에도 잘 설명되어 있지만, 안 보셨던 분들을 위해서 의료산업에 대해서 다시 한번 정리해보자. 아직 연재내용을 보지 못한 독자들은 월간 마소 2010년 5월호부터 'IT 컨버전스' 코너를 통해 게재된 필자의 연재를 한번 살펴보길 바란다.

일반적으로 '보건, 의료산업'은 일반적인 경제학 이론이 적용되지 않는 대표적인 시장실패산업이라고 하겠다.

보통의 일반적인 경제학 이론에서는 공급자와 소비자 사이의 정보가 투명하게 전달되어지고, 완전한 지식의 형태로 설명할 수 있다. 그러나 '보건. 의료산업'의 경우에는 공급자인 의료공간과 의료진들과 소비자인 환자들 사이에서의 정보가 공급자가 독점하는 시장으로 형성되어지며, 이를 '정보의 비대칭성'이라고 불리며, 공급자 수요유발과 같은 일반적인 시장경제에서 나타나기 힘든 현상들이 나타나는 산업이 바로 이 의료산업이다.

그래서 일까요? 이러한 공급자에 의한 시장교란과 보건. 의료산업이 가지는 공공재적인 성격을 감안하여 각국에서는 다양한 형태의 가격통제장치(의료보험 등)과 다양한 규제들을 가지고 있는 산업분야다.

더군다나, GDP기준으로 15%이상 20%에 육박하는 이 거대한 산업은 개발자들이건 시장을 지배하려는 회사이건 아주 매력적인 분야임에는 틀림없다.

현재 수많은 레드오션 산업 중에서도 가장 시장적인 환경의 생태계가 고립된 상태로 상당부분 오랫동안 진행되어서, 많은 사람들이 관심을 가지는 분야이기도 하다.

국내에서는 다양한 규제를 통해서 강력한 억제를 펴고 있고, 사람의 생명을 다루는 분야이기에 많은 기업에서도 접근을 상당히 두려워하고 있는 분야이기 때문에 어찌보면 더 매력적인 분야가 아닐 수 없다.

현재로는 다양한 수출산업 육성과 국내의 환경이 지나치게 경직되어있다는 묘한 딜레마가 있는 환경이기는 하지만, 지속적으로 늘어나는 노령인구와 만성질환자들에 대한 민간 부분에 대한 확대를 막을 수 있었기에 정말 새로운 시도와 다양한 서비스들의 결합해 볼 수 있는 분야이기도 하다.

 

웹2.0의 바람, 헬스2.0으로 '도약'

 

웹2.0의 핵심이었던 참여와 공유, 집단지성의 매력적인 바람은 이러한 의료계에도 불어오고 있으며, 이러한 바람을 우리는 '헬스2.0' 이라고 부른다.

과거에는 의사가 환자에 대한 정보의 주도권을 모두 쥐고 있고, 모든 의사결정을 의사가 하였다. 하지만, 현재는 의사와 환자간의 정보 및 지식 평준화가 진행되어지면서 환자의 정보를 환자 자신이 직접 통제하기 시작하였으며, 환자의 결정권이나 재량권이 날이 갈수록 커지고 있다.

이제는 해외의 환자들의 경우에는 직접 구글링이라는 검색을 통해서 다양한 의학논문을 직접 읽고, 자신의 병이나 상황에 맞는 의사나 병원을 직접 찾아서 오는 경우까지 등장하고 있으니, 이러한 의료서비스들의 결합을 통해서. 기존 의료서비스 공급자들이 가지고 있던 가격독점권이 많이 흔들리고 있는 것도 현실이다.

이러한 인터넷을 통한 건강지식과 의료지식으로 무장한 'Google Patient'들이 등장하고 있다.

 

소비자중심의 의료의 변화

 

새로운 인터넷 기술과 소프트웨어 프로그램의 적절한 활용을 통하여 개인적인 건강정보를 온라인 서비스와 결합하여 찾는 방법들로 발전하였고, 환자들 스스로 토론그룹이나 커뮤니티를 만들어 강력한 네트워크를 형성하고 동시에 치료와 진료의 영역을 넘나들기 시작했다.

필자가 트위터에서 주고받은 이야기들을 예로 들어 살펴보자. 필자의 트위터 아이디를 통해 '갑상선수술을 받으려면 어디가 좋을까요?'라는 글에 많은 분들이 RT를 통해 필자의 의견을 전달하고, 많은 병원과 심지어 의사선생님에 대한 추천까지도 해주시는 고마운 분들이 참 많다. (사실, 이미지 스샷을 올리려 했으나, 개인. 개인적인 아이디들이 많아서 올리지는 않는다. 올려도 된다고 이야기해주신 @nok-Q님, @jescoach님, @jooooniiii님에게 이 자리를 빌어 감사드린다)

뭐랄까. 이제 커뮤니케이션은 소셜의 시대이고, 매스미디어에 접근하기 보다는, 개인간의 정보유통이 보다 활발한 시대인 것 같다. 그래서일까. 1인 개발자의 시대이고, 낭만 개발자의 시대가 다시 만들어지는 것 같아서 상당히 흥분되는 환경이 만들어진 것 같다.

요즘 가장 긍정적인 네트워크의 발전과 효과적인 방법이라고 이야기하는 '소셜네트워크'는 다양한 분야에서 적극적으로 활용되겠지만, 개인적인 미디어단말기들을 통해서 전통적인 의료서비스의 폐쇄적인 공간이 오픈된 환경으로 발전되는 형태로 해당 서비스들은 대표적인 소셜서비스의 핵심이 될 가능성이 높다.

의료에서의 소셜네트워크의 핵심은 '아이디어를 공유하고, 증상에 대한 토론을 하고, 동시에 치료방법에 대한 선택을 논의하면서 이들 모두가 지식이 증가되게 되고, 결국에는 보다 좋은 환자의 치료에 대해서 이야기되어지는 선순환의 고리'가 형성되는 아주 긍정적인 방법들이다. 이는 어찌보면, 소프트웨어 개발자들이 꿈꾸는 가장 효과적인 '정보'와 '지식'의 흐름을 디자인하고 그것을 만들어내는 것이라고 하겠다.

소셜네트워크의 특징을 보면, 사람들은 자기와 비슷한 사람의 말을 보다 권위가 있는 사람들의 말보다 더 신뢰하는 경향이 정말 높다. 그래서일까? 소셜네트워크에서의 의료는 정말 엄청나게 강한 신뢰감을 형성한다.

 

현재 의료서비스의 한계와 U-헬스케어

 

병원이라는 공간에서 환자를 대하고, 이에 대한 의료서비스를 행하면서 수익을 올리는 병원의 모델로는 이미 한계에 다가왔다. 대형병원들이 R&D를 선언하고 나서는 이유도, 새로운 수익모델을 만들어야 한다는 현실을 알고 깨달았기 때문이다.

해외에 병원을 세팅하러 아부다비, 두바이, 멕시코, 상하이를 다니면서 느낀 결론은 다음과 같다. 아랍의 어떤 나라의 전략은 자국민의 의료서비스를 해외로 보내는 것의 비용부담과, 국가적인 새로운 먹을거리를 위한 사업으로 의료서비스를 택했다. 또한, 자국내의 전문센터 건립의 노하우를 축적하여, 사우디아라비아 등의 주변 중동국가들의 진출도 같이 기획한다.

이때에 중요한 것은 의료정책과 병원건설, 의료 서비스등의 복합적인 '기획 상품'이 필요한데. 현재, 이러한 노하우는 선진국들이 더 많이 가지고 있으며, 명성 또한 높다.

다만, 선진국의 의료모델에 대해서는 개도국들(중앙아시아 포함)도 그런 의료정책이나 의료서비스 모델이 적합하다고 생각하지는 않는다. 이에, 대한민국의 의료서비스모델과 결합한 형태가 만들어지는 것이 가장 좋다고 생각한다.

개도국들 또한 신형 모델로는 병원을 많이 건설하는 모델보다는 U-헬스케어와 결합된 모델을 원한다. 그 이유는, 당연하기 '비용'문제 때문이다. 하지만 현재의 U-헬스케어모델들은 고혈압과 당뇨의 '만성질환'관리에 초점이 맞춰져 있으며, 이는 '병원'의 신규 의료서비스 모델로는 적합하지 않다. 이는, '건강관리회사'의 '서비스'가 더 강한 측면이 있고, '전문적인 의료서비스'가 많이 필요하지 않기 때문이다.

현재까지의 국내의 건강관리 U-헬스케어 사업들은 이러한, 의료계 내부에서의 기술발전을 통한 컨버전스라기 보다는, 대기업과 간단하고 간소한 규칙의 '만성질환자'들을 관리하고 이에 대한 의료서비스 비용을 책정하는 방법으로 진행되었다.

하지만, '고혈압', '당뇨'와 같은 '관리'는 '법'의 문제 때문에 진행이 되지 않은것이고, 이런 서비스를 운용하는데에는 너무도 고가의 장비와 복잡한 시스템으로 구성되어 있는데다, 가장 중요한 '병원'을 제외한 채, 의료서비스 디자인을 추진하고 있다.

'병원'중심과 '의료서비스'중심에서의 핵심은 '병실'과 '수술실'이라고 본다. 가장 미래적인 '병원'중심의 U-헬스케어는 각자, 환자의 집을 '디지털 병실'화 시키고, 중요한 수술이나 검사와 같은 부분들을 전문화한 '디지털 병원'이 등장하게 된다고 본다.

현재의 '디지털 병실'에 어울리는 의료서비스 모델과 관련 인터페이스 및 환경을 구축하는 것이 아주 효율적이라고 생각된다. 또한 미래의 U-헬스케어의 궁극적인 모델은 완전한 의료서비스의 독립이라기보다 전문적인 영역과, '진단', '감시', '관리'적인 측면은 좀 더 저렴한 IT기술과 융합하고. 복잡하고 전문화된 영역은 '의사'들이 좀 더 전념할 수 있게 하는 것이다.

또한, 의료관광은 의료서비스를 제공하는 비행기나, 유람선을 만들 수도 있고, 부자들은 자신의 집에 '디지털병실'을 꾸미고 싶어할 수 있다.

개도국의 경우에도, 모바일과 원격관리가 가능한 개방형 홈-헬스케어 장비들이 보편화되고 더 저렴한 방법으로 기본적인 의료서비스가 가능한 시장을 만들어 나갈 것이다. 일본에서 점차 시작되고 있는 DIY 건강 키트들도 그러한 것을 반증한다.

구글링을 통한 의료정보의 습득, 개인 건강키트를 사용한 개인 진료, 거기에 의료진들과의 SNS의 확대 및 이를 관리하는 홈헬스 장비들은 현재 추진중인 '스마트케어'와는 맞지 않다.

현재 추진되고 있는 스마트 케어는 규격과 서비스회사에 대한 제한을 둔 '닫힌 시장'이다. 이는, 아이패드(iPad)와 같은 장비에 오픈형태로 확장되어지는 홈 헬스케어 시장과 경쟁할 수 없다. 아이폰을 폐쇄적인 폰개발 제조사들이 이길 수 없듯이 말이다.

국내나 해외의 병원의 미래모델들은 가능한 '병실'을 줄이는 것이다. 대표적으로 '필리핀'의 병원 모델만 보거나 '미국'의 모델만 봐도, 병원은 수술실과 같은 고급 의료 콘텐츠만 준비하고, 주변의 모텔이나 호텔에서 환자들을 케어하는 방식을 사용한다. 병원은 저렴한 수가나 봉사와 관련된 서비스들을 분리하고 싶어하기 때문이다. 이런 시스템을 구축할 때에는, 당연하게 해당 호텔업이나 리조트산업의 '룸'과 연동되는 '디지털 병실'이 핵심이다. 값비싼 의료진을 모든 호텔에 배치할 수 없기 때문이다.(물론 고가의 고급 리조트에서는 다르겠지만 말이다.

국내의 의료법이 개정되고 관련된 환경이 변하게 되면 이러한 홈케어방식은 더 적극적이 될 것이다. 그 홈케어에 핵심은 '디지털 병실'과 '디지털 수술방'이라는 데 있다.

병원들의 다양한 의료기술들의 발전의 핵심도. 가능한 수술후에 '입원일자'를 줄이는 방법이다. 생각보다 병원은 '입원환자'들을 최소한으로 줄이는 것이 '이익확대'에도 크기 때문이다. 이를 해결할 수 있는 방법이 개발되어지고 설득되어진다면. 향후 홈-헬스케어 사업의 중요 아이템이 될것이다.

현재 추진하고 있는 '디지털병원'은 환자들에게는 자신의 공간에 의료서비스를 받아들이게 하고, 의료진들은 좀 더 전문적인 영역으로 '의료서비스'를 운용할 수 있게 하는 방안이라고 생각한다.

 

헬스케어 서비스에 관심이 있다면

 

전통적인 의료서비스를 지탱하고, 이를 운용하기 위한 병원정보시스템을 운용하고있는 병원의 전산실, 또는, 필자가 현재 팀장으로 있는 팀과 주변의 병원전산실들의 업무를 살펴보자. 국내의 병원들의 상황을 살펴보자. 대략국내의 요양기관이라고 불리우는 의료공간은 대략 8만개정도가 있다고 한다(이 통계는 2009년말을 기준으로 언급된 자료다).

IT개발자들의 관심으로 살펴본다면, '전산실'이 존재하는 의료공간은 얼마나 될까? 그중에 대다수는 개원가라 불리는 동네병원들은 특별하게 전산실이 존재하지 않는 병원들이 대다수이다. 생각보다 이런 개원가에 계신 의사선생님들은 IT관련 기술도 뛰어나셔서 직접 PC나 소프트웨어 개발을 하시는 분들도 많다.

아마도, 새로운 시도를 할 만한 인원과 자금, 기회를 가지려면 Big5라 불리우는 국내의 초대형병원이나 40여개 정도의 대학병원급 정도가 되어야 그나마, 다양한 의료서비스에 대한 접근이 가능한 정도이지만, 실제 병원 전산실의 업무는 그러한 새로운 헬스케어 서비스에 대해서 접근하기 보다는. 병원 내부에서 지원되어야할 정보서비스를 제공하는 것만으로도 힘에 벅찬경우가 많다.

병원의 특성상 24x7이라 불리우는 시스템인데다가(거의 중단이 없다) 병원의 시스템이 중단되면, 정말 심각한 상황이 발생할 수 있다. 퇴원도 입원도 안되는 어이없는 상황이 벌어질 수 있기 때문이다. 일부 특정 회사의 솔루션을 그렇게 신뢰하지 않는 경우도 이러한 무중단 서비스이기 때문인 경우가 많다.

자, 그렇다면. 새로운 의료서비스 환경이나 뉴 헬스케어 서비스를 꿈꾼다면 어떤 곳이 좋을까? 좀더 눈을 넓혀보면, 국내에는 다양한 의료IT서비스를 개발하는 업체들이 많다.

물론, 대기업들의 소프트웨어 파트에서도 많이 하지만, 현재 시장상황을 살펴보면, 헬스케어산업에 들어오기 위해서 다양한 인재들과 조직구성을 갖추려고 시도하는 대기업이나 다양한 기업들이 많다.

현재 상황에서는 다양한 기회와 서비스에 대한 꿈이 있다면, 병원전산실이 목표가 되기보다는 다양한 의료서비스를 개발해 볼 수 있는 기업을 택하는 것이 중요한 선택포인트가 될 것이다.

 

헬스케어의 분야에서의 의료정보학

 

전통적인 병원정보시스템은 EMR, OCS(CPOE), PACS. 그리고, MIS, DW, CRM, CDIS, CDSS, LIS, RIS등의 주요 시스템들, 그리고. 향후 U-헬스케어 서비스를 위한 다양한 의료건강서비스들과 소셜서비스들. 그리고, 의료정보학과 의료기기등의 영역까지 매우 다양하다.

하지만 개인적으로 미래의 헬스케어 분야에서 가장 두각을 나타날 분야를 생각해본다면, 필자 개인적으로는 의료정보학의 중요성에 대해서 다시한번 이야기하고 싶다.

물론, 바이오와 관련된 분야도 많고, 다양한 의료적인 분야가 많겠지만, 헬스케어 분야에 관심이 있는 개발자라면. 의료정보학에 대해서 너무 깊게는 아니더라도 '개론'이상의 지식의 접근은 필수라고 생각한다.

이런 '의료정보학'을 간단하게라도 이 지면에 설명해보자면 일단, 의료정보학이란? '의학적 지식의 해석과 의학적 의사결정, 의학적 지식공학 등을 총망라하는 분야'라는 전문적인 분야로 설명할 수 있다.

말 그대로 '지식을 다루는 지식'(knowledge about knowledge)라고 불리우는 이 분야는, 정말로 타 분야의 방법론과는 접근방법 자체가 다르고, 그 깊이는 상상을 초월한다. 그 깊이에서 허둥되면 안된다. 이쪽 분야를 전문적으로 연구하시는 분들에게 도움을 받아서, 그 개념정도만이라도 접근한다면, 분명. 생각의 틀을 많이 바꿀 수 있을 것이다.

특히나, 의료의 전문적인 영역과 IT의 기술적인 부분들의 결합에 관해서는 정말로 많은 것을 얻을 수 있는 분야이기도 하다 (개인적으로 이쪽 분야를 연구하는 분이 주변에 있다면, 한편으로는 행복한 것이기도 하다. 친구를 한명 만들어 두는 것이 좋다고 추천한다).

크게 기본적인 의료정보학의 체계를 보면(위키피디아 기준 http://ko.wikipedia.org/wiki/의료정보학 ) 다음과 같이 설명할 수 있다(정말 간단하게 설명한 것이다).

 

1. 기초의료정보학 - 주로, 의학의 정보이론적인 기반을 통한 연구 분야

2. 임상의료정보학 - 임상과정에 초점을 맞추는 분야

3. 생명의료정보학 - 인간과 인간의 질병 및 그 치료를 주된 연구대상으로 하는, 유전자 연구분야.

 

이렇게 세가지 분야를 정보학(informatics)라는 하나의 이름으로 공유하고 있다. 그 핵심적인 연구 방법론에 대해서는 많은 정보학적 기법과 이론을 통해서 다양하게 해석을 시도하는 학문이기도 하다. 기본적으로 자연현상을 물질과 에너지와 정보의 3대요소의 상호작용의 결과로 파악하고자 하는 세이버네틱스 이론의 전통을 따르는 것이다. 사실, 의료정보학의 정규 커리큘럼을 갖춘 유수의 의과대학에서도 이러한 의료정보학을 전부다 교육하고 연구할 수 있는 경우도 매우 드물다. 그러므로, 소프트웨어 개발자들은 그 개론수준에 대한 접근만 하는 것으로도 충분하다 하겠다.

이 분야에서 얻는 것은 다음과 같다. 의료정보학 분야의 연구는 기본적으로 데이터구조, 추상화, 메타구조, 처리, 해석, 메타해석, 교신, 알고리즘, 인공지능, 기계학습 등 모든 지식공학에 대한 이해가 그 학문적인 기반을 이룬다 하겠다.

그래서일까? 의료정보학을 공부한 의사일 경우에, 프로그래밍이나 개발에 능숙한 기술적인 성숙도를 보이는 것은 당연한 것인지도 모른다. 사실, IT와 관련된 대다수의 기본적인 기술들은 이러한 '지식'을 다루는 분야의 기술이기 때문이다. 헬스케어 분야를 꿈꾸는 개발자분들이 있다면, 너무도 큰 이 분야에 한번 발을 담가보는 것도 괜찮을듯하다.

향후, 이런 서비스를 디자인하거나 관련된 환경과 현재의 의료정보시스템의 궁극적인 발전모델들의 향후 비전에 대해서 '의료정보학'이라는 거대한 산에서 얻을 수 있는 것들이 참으로 많을 것이다.

 

컨버전스에 대해서 아는가

 

수퍼개발자를 꿈꾼다면, 현재 많이 이야기되고 있는 컨버전스(convergence)에 대해서 깊이있는 통찰이 필요하다 하겠다. 생각해보면, 우리 개발자들의 IT개발 기술들은 무언가와 결합되거나 융합되어야만 원하는 목표를 이룰 수 있다.

컨버전스. 즉, '융합'의 뜻은 '여러기술이나 성능이 하나로 융합되거나 합쳐지는 일'을 의미한다. 사실, IT개발자들의 업무자체가 컨버전스가 아닐까한다. 다만, 슈퍼개발자가 되기 위한 기본적인 개념은 IT개발업무를 '1+1'과 같은 결합상품을 만드는 행위가 아니라는 것이다. 업무를 분석해서 단순하게 그 업무를 고객이나 사용자들이 사용하게 만드는 행위가 소프트웨어 개발의 전부는 아닌 것이다.

종이나 사람을 대상으로 하는 업무를 소셜의 형태로 바꾸고, 자신의 손과발이 되게 하고, 지식과 경험을 담아내는 새로운 UX의 설계가 되어야 하는 것이 IT개발자의 기본적인 생각과 마인드가 되어야 한다.

내가 만들어낸 소프트웨어나 서비스가 새로운 UX를 만들고, 사용자들이 자신들의 경험으로 새로운 것을 만들어 낼 수 있게 하는 것이 IT개발자들이 가져야 하는 기본적인 마음이 아닌가 한다.

현대의 IT개발자들은 수많은 '경험'을 만들어 내고 있다. 컨버전스는 융합과 해체의 반복속에서 새로운 것들이 만들어진다. 사람들은 이제는 기술에 대해서 무서워하지 않는다. 쉬워진 기술과 새로운 기술에 대해서 너무도 쉽게 받아들인다. 심지어는 무감각하게!

수 많은 사용자들은 정보기술의 소비자들로써 새로운 기술이 대체하는 무엇이든 그것을 쉽게, 그리고. 무감각하게 내던져 버리고 새로운 기술을 간단하게 받아들여 생활에 이용하기를 즐겨한다.

더군다나, 사람과 사람의 경험에 대해서 전달하는 것을 즐겨한다. 트위터가 열광적으로 사람들에게 전달될것이라고는 처음 만든 사람도 생각하지 못했을 것이다.

 

IT개발은 모든 비용을 줄여주지 않는다

 

사람들은 착각한다. IT개발과 어떤 정보서비스를 개발하면, 기업이든 개인이든 비용이 줄어들 것이라고 착각한다. 하지만, 그렇지 않다. 새로운 경험이 만들어지면, 그 만큼의 비용은 오히려 추가로 들어간다. 다만, 그 새로운 경험이 새로운 이익을 창출하는 것으로써 그 이익을 대체하는 것이 IT개발의 핵심이라고 생각한다.

내가 IT개발을 한다면 어떤 것을 고민해야할까?

 

개발자가 컨버전스에 주목해야하는 이유는 다음과 같다. IT개발자의 시야를 디자인과 구조적인 환경, 사용자에 대한 이해, 사용자의 경험에 대한 환경까지 보게 하는 시야를 넓혀준다. 컨버전스의 특징은 '집중화'된 곳에 조직과 철학과 컨셉이 존재하고. 이러한 '집중화'된곳을 지원하는 수많은 프로슈머와 생태계들이 같이 호흡하고 있는 환경을 알게한다.

재미있는 것은 가장 진보적인 환경이어야 할 IT개발자들이 가장 구태의연한 환경과 국내의 열악한 IT환경을 만드는 이유가 멀까? 그것은, 기존에 국내의 환경의 중심이었던 '제조업체'를 기반으로 한 환경으로 IT조직과 관련 프로젝트들을 구성해서 만들어지는 문제점들이기도하다.

IT와 관련된 선배들의 가장 큰 잘못중의 하나가. 그러한 '제조업'중심의 생각과 컨셉, 철학적인 배경들로 관련 IT조직을 만들고 꾸며왔기 때문이다. 아마도, 미래의 관련된 IT조직들은 변화를 시도할 것이고, 그러한 변화가 실패한다면 그 기반이 존재하지 않기 때문에 존재와 사라짐의 사이에서 고민할 것이다.

물론, 그렇다고, 너무 고민할 필요없다. 모든 것에 정답은 없기 때문이다. 다만, 각자의 조직의 장점에서 출발한다는 기본적인 컨셉만 버리지 않으면 된다.

현재의 다양한 IT관련 의료서비스들은 'U-헬스'라고 지칭되고 있다. 단순하게 IT기기만으로 의료서비스와 결합한다면. 그것은 '결합'일 뿐이다. 새로운 서비스가 아니다. 진정한 융합은 새로운 경험과 새로운 서비스를 창출하고, 또 다른 생태계를 조성할 수 있어야 한다.

 

전통적인 의료기관의 변화와 IT업체들간의 다양한 협력방식은 분명, 많은 것을 변하게 한다. 컨버전스는 집중화가 되고, 서비스의 양상이 바뀌게 되고, '가격'또한 변하게 된다. 또한, 그러한 컨버전스는 생태계가 조성되고 프로슈머를 나타나게 하지 못한다면. 그 컨버전스는 실패한 것이다. 새로운 경험은 U-헬스에 있어서 가장 중요한 것이다.

 

컨버전스를 알게된 IT개발자, 대상 소비자는 누구인가

 

컨버전스의 화려한 시작을 알게된 아이폰 그리고 스마트폰이 가져온 혁명적인 환경의 변화에 대해서 알아야 한다. 과거의 IT개발자들이 특정상대, 특정한 환경에 대한 소비자와 고객들에 대해서만 고려해왔다면. 이제 개발자들은 좀더 폭넓은 대상을 고려해야 한다.

과거의 특정 대상이 아닌 일반 소비자들 그리고 프로슈머를 상대해야한다.

재미있는 것은 단순 사용자들은 자신들이 얼리어답터라고 착각한다. 물론, 공급자의 입장에서는 그러한 착각을 유지시켜주는 것이 좋다.

현재 만들어지고 있는 다양한 서비스들은 사실상 일반 사용자들을 위한 서비스들이 더 많다. 차를 가지고 다니는 사람들 보다는. 뚜벅이들과 주변 생활과 밀접한 서비스들이 바로 손위에서 펼쳐지는 서비스들이기 때문이다. 그렇다면, 이러한 사용자들에게는 어떤 서비스를 제공해주어야 하는가?

 

<화면 4> 소비자들

 

사람들은 사실 테크놀로지에는 큰 관심이 없다. IT개발자들이 초보시절에 착각하기 쉬운것 중 하나가, 어떤 기능들의 다양한 구사에 대해서 본인 스스로 만족하는 행위들이다. 사실, 사용자들은 자신들의 경험을 그렇게 바꾸고 싶은 마음이 없다는 점이다. 하지만 사용자들의 욕구는 간단하다. '그냥 일을 빨리 하고 싶고, 생산적이고 싶고, 소셜하고 싶고, 즐거움을 가지고 싶은 것'이다.

과거에는 그러한 '컴퓨팅'을 위해서 더 큰 용량, 더 좋은 그래픽 파워, 더 좋은 인터페이스에 대한 고려, 더 좋은 무선인터넷 등을 구성하고 배치하기 위한 기본 테크놀로지에 집중했던 것이다. 그래서 IT개발자들의 주 업무 또한 그러한 기본 테크놀로지에 집중했던 것이다.

그러나 이제는 이러한 기술적인 테크놀로지가 사용자들에게 필요한 것이 아니라, 테크놀로지의 용량향상이 필요한 것이 아니라, 소비자에게 진정으로 유용하고 효율적이고 재미있는 '컴퓨터 제품'의 기술이 필요한 것이다.

특히나 이러한 '컨버전스'형태의 기술들은 재미있게도 콘텐츠와 서비스의 재조립이 가능해야한다. 한번 만들어진 상태의 결합의 만족이 아니라, 새로운 경험을 유쾌하게 자신들이 재구성할 수 있는 매력을 가지게 하는 것이다. 서비스를 디자인할 때 일부러 중심이 되는 서비스 이외의 재구성의 영역을 남겨두는 것이 바로 그 중요점이다.

아이폰의 앱은 딱, 필요한 단위서비스와 형태의 구성을 가지고 있고, 사용자들은 자신이 원하는 서비스의 형태로 재창조한 스마트폰을 세팅한다. 그리고 그 자체로 즐거워하고 재미있어한다. 향후의 모바일 오피스를 구성하고, 재미있는 서비스를 구성한다면, 이러한 매력적인 포인트들을 꼭, 설계에 반영해야한다.

새로운 서비스는 새로운 경험과 결합하여 재구성과 재조립이 가능한 구조로 디자인하는 것이 최상이다.

대표적인 서비스의 형태의 전이의 역사를 살펴보려면 아마존과 아이폰 앱스토어를 예로 많이들 든다. 아직도 공급자의 가격을 조정하는 전통적인 방식을 가진 아마존과 공급자의 가격에서 수수료를 때는 형태의 애플의 방식은 분명 큰 차이를 가지게 한다.

 

차세대 인터넷과 미래사회에서의 IT개발자

 

많은 이들이 미래사회에 대해 탈대량화와 프로페셔널리즘이 붕괴할 것이라고 예측한다. 대량생산을 통해서 정해진 품목과 원가절감, 가격경쟁력을 중요시하던 시대에서 다품종을 소량생산하고 롱테일 법칙을 중요시하는 시대로 변한다는 것이다.

과거의 대형 프로젝트를 통해서 규모가 큰 소프트웨어를 개발하는 시대에서, 개인화된 개별적인 서비스를 구현하고 이를 유통하는 환경으로 온다는 것이다. 더군다나, 이러한 사회는 공정, 부품, 근로조건, 사회의 규격화의 붕괴도 마찬가지로 일으킨다는 것이다. 현재의 분업 및 전문화된 원칙과 근로환경 또한 변화가 있다는 것이다.

이제 IT개발자들도 굳이 시공간의 제약이 존재하는 공간에 모이지 않으며, 가상기업과 같은 형태로 만들어질 것이다. 이미 크기가 중요한 시대의 대량생산과 집중화된 개발방식보다는 소규모 형태의 개발과 극도로 빠른 개발 속도, 그리고, 개인의 능력이 중요시되는 미래의 사회는 개발자들에게도 좀더 다른 관점에서의 요구조건을 발생시킨다. 이제는 '소통의 능력과 창의력의 시대'라고 지칭해야 옳지 않을까 한다.

자신의 전문분야만 가지고는 힘들고, 의사소통과 상호관계의 네트워크형 인간이 되어지는 인재들이 개발자들의 사회에서도 중요한 점일 것이다. 과거의 개발방식들이 정해진 틀, 프로세스, 작업계획서, 통제관리를 통해서 수직적이면서도 효율적으로 일의 즐거움 보다는 효율을 원했던 방식이었다면, 미래의 개발방식은 과거의 낭만적인 개발방식으로 돌아간다고 해야할까? UC버클리의 Heanry Chesbrough(헨리 체스브로)교수의 이야기를 통해 알아보자.

 

- 기업내부에서 연구와 개발을 하고, 중앙 집중적인 운영을 하는 것은 이제 진부한 기업의 전형이다.

- 경쟁력은 외부에서 찾아서 이를 얼마나 역동적으로 이용할 수 있는가에 따라 발생한다.

- 개방혁신(Open Innovatio)이 중요하다.

- 더 이상 기업의 혁신은 R&D연구소에서 많은 수의 과학자나 엔지니어를 고용, 연구하는 방향으로 얻지 못한다.

 

그렇다. 소프트웨어 개발역시 이러한 형태를 그대로 미래의 모습으로 밟아나갈 것이다. 아마도, 언제나 개발자 커뮤니티에서 추진하던, 참여와 공유의 개발방식이 우리의 미래개발형식을 변하게 할 것이다.

Innocentive, Ninesigma, YourEncore등의 난해한 기술적 문제를 외부의 힘으로 해결하는 참여와 공유의 정신은 생각해보면, 초기 소프트웨어 개발자들의 해커리즘과 동일한 생각이 아니었을까?

아이폰&아이패드, 오픈된 환경 or 닫힌 환경 인가

 

아이폰과 아이패드가 오픈된 환경인지, 닫힌 환경인지에 대해서는 많은 논란이 있지만, 필자의 생각은 확고하다. '개발자'의 입장에서 분명코, 맥의 개발방식이나 아이폰, 아이패드의 개발방식은 여러 가지를 잃어버리게 했다고 생각한다. 그것은 사실이다.

기발한 플러그인을 개발하고, 다양한 데몬류, 시스템 레벨의 유틸리티를 만들 수 있는 능력을 박탈해간 것은 분명코 슬픈일이다 (재미있는 것은 이러한 즐거움을 알고, 능력을 가진 분들은 극소수라는 것이다). 그동안 수십년 동안 갈고, 경험하고, 축적한 CPU와 H/W레벨의 지식을 '고물'로 만들어 버린 이런 개발방식으로 인해 필자는 한편으로는 슬프다.

이쯤에서 잠시 필자와 필자의 선배가 이야기를 나눴던 약 20년전으로 돌아가보도록 하겠다. 필자가 알고 있던 괴물같은 선배 플머가 있었다. 이 선배는 머릿속에서 8진법, 16진법, 2진법의 계산을 순식간에 해치우는 분이셨고, CPU의 니모닉코드와 IP,OP코드를 줄줄 외우고, 메모리 번지까지 통째로 외우고 있던 개발자였다.

이 선배가 이용하는 프로그래밍 방법은 Debug를 사용해서 직접 기계어 코드를 헥사코드를 사용해서 기계어로 나열하는 방식의 프로그래밍이었다. 어설픈(?) 컴파일러와 같은 도구(?)들을 매우 혐오하는 스타일이었다.

물론 이 선배가 대단한 것도 있었겠지만, 도저히 당시의 개발환경에서의 협업과 같은 방식으로 코딩을 할 수 없는 독불장군이셨다고 할까? '소프트웨어 개발은 Debug로 하는 것'이라는 주장을 펼친 사람이었기 때문이다.

그리고 10년후, 비주얼베이직, 델파이, 파워빌더와 같은 RAD툴의 시대에서는 런타임방식과 컴파일방식에 대한 다양한 토론이 커뮤니티에 언급돼 왔으며, 얼마전부터는 프레임워크와 빈스, 객체에 대한 다양한 토론들이 줄을 잇고 있다.

필자는 그렇게 생각한다. 우리 IT개발자들이 진정하고자 하는 것은 무엇인가? '자신의 기술을 뽐내고 자랑할 만한 테크닉'을 부리고 싶은것인가? 사용자들에게 Experience(경험)을 전달하고 그들에게 필요한 서비스나 정보시스템을 만드는 것이 목적인가? 라는 것을 말이다.

필자는 이렇게 꿈꾼다. 사용자들에게 더 멋진 Experience를 만들고, 사용하게 하고, 즐기게 하는 것이 '꿈꾸는자'인 필자의 꿈 이라고 말이다.

필자는 이렇게 생각한다. 컨버전스 자체가 이미 '디지털적인 변증법'을 실현하고 있다고 생각합니다. 인간의 욕구인 어떤 것이든 재해석하고 자신의 것으로 만들고자 하는 욕구와 재해석을 통해서 새로운 기회를 엿보고 진정한 새로움이라는 양념을 넣으려고 하는 욕구. 그리고 이러한 욕구들이 이미 메가트랜드로써, IT개발자들도 모르는 사이, 이미 인간의 생활 깊숙한 곳으로 침입해왔다는 것이다.

 

개발자들이여, 컨버전스 하자!

 

IT개발자가 된 것을 언제나 자랑스러워하며 즐겁게 생각하는 이유는, IT개발자들이 해야 할 현대사회의 몫은 정말로 크다고 생각하기 때문이다. 나 자신부터가 인간이 너무나 자연스럽게 받아들이는 이 가상의 욕구들을 창출하게 하여서 인간을 행복하게 만들고, 기업들이 고민하는 '스타일'과 '독특한 아이덴티티', '감성소비'가 가능한 다양한 정보서비스와 단말기들을 디자인하고 만들어 내는 개발자들 중 하나이기 때문이다.

더 확대해석을 한다면, '더더욱 몰개성화 되어가는 시대의 대중미디어 속에서 더욱 고립되어지는 인간 소외와 고립에 대응하는 사회적이고 인간적인 '나만의 것'이라는 욕구의 투영 속에서도 소셜이 가능한 환경을 만들고, 네트워크적인 사회로 만들어나가기 위해서 노력하고 있는 우리들의 모습에서 더 큰 자부심이 느껴진다고 하겠다.

개발자들은 사회를 변화시킬 수 있을까? 필자는 그 변화의 중요한 축을 담당하고 있다고 생각한다. 스마트폰이라는 '개념'하나만으로도 전세계의 생각의 틀이 바뀌듯이. IT기술자체는 분명, 새로운 시장을 창출하고 인간을 변화시키고 진보시킨다.

필자가 생각하는 가장 처음의 컨버전스 상품은 일명 '워크맨'이라고 불리던 소니사의 카세트 플레이어가 아닌가 싶다. 워크맨은 가만히 앉아서 듣던 음악을 이동하면서 듣게 하는 새로운 경험을 만들어 주었고, 그 경험으로 음악의 다양한 장르의 발전까지 가져오게 한 대표적인 IT기기이기 때문이며, 이는 마샬 맥루헌의 '미디어의 이해'에 나오는 핫(HOT)과 쿨(COOL)한 미디어의 영향에 의해서 인간들이 변화하는 경험과 미디어의 논리인 것 처럼 말이다.

 

개발자들이여, 해커리즘으로 돌아가자

 

향후의 의료환경의 변화는 선진국은 홈 헬스케어, 개도국처럼 기존 인프라가 부족한 국가도 이러한 U-헬스의 환경으로 변화되어 갈 것이다. 이는, 과거에는 전염병, 병원균을 통한 치료에 집중하였던 의료정보환경에서 환자중심의 환자를 바라보는 환경으로 변화할 것이다.

요즘 의료기관들에게 큰 이슈는 JCI와 병원인증제도의 변화다. 이는 병원을 평가하는 방법이 기존에는 하드웨어나 규모를 중심으로 하는 의료환경 이었지만, 이제는 환자에게 제공되는 서비스, 의료기관의 실수를 줄이는 체크, 환자에게 필요한 알정보를 어떻게 전달하느냐의 '컨셉'의 변화가 가장 큰 철학적인 변화다.

정보시스템의 관점자체의 디자인도 이러한 변화에 맞추어서 새롭게 디자인되어야 하는 것이다. 더 중요한 것은 의료관련 꿈을 꾸는 모든 사람들의 생각의 틀이 바뀌어야 하는 것 아닌가 한다.

 

해커리즘(Hckerism)

 

해커리즘은 지식의 공유를 기반으로 한 세상. 즉, IT개발자들이 꿈꾸었던 세계다. 해커(kacker)의 원래뜻은 컴퓨터에 정열을 가지고 그것 자체에 몰두하는 사람들을 의미한다. 언론에서 이야기하는 크래커(Cracker)와 system intruder가 아니다.

해커는 주어진 환경만을 사용하는 일반 사용자와는 달리, 자신의 지적욕구를 충족하기 위해서 자신의 컴퓨터 시스템이 할 수 있는 모든 것을 찾아보고 만들어가는 사람들이라는 의미에서 프로그래밍에 광적인 집착력을 가진 사람으로 거듭되는 시행착오 속에서 정보공간에 잡입할 수 있는 능력을 갖춘 사람이라고 Guy L.Stells의 '해커사전'에 나온다.

그렇다. IT개발자들이 다시금 부활하는 낭만주의의 개발시대에서 자신의 자리와 목표를 생각해보지 않겠는가? 비록, 현실의 어려움과 괴로움에 대해서도 선배개발자로써 잘 알고 있습니다. 결론적으로 개발자들 자신이 현실의 환경에서 '토템'에 '킥'하여서, 원래 꿈꾸던 현실로 돌아가는 것이 최선이 아닌가한다.

언제나 당장의 이익을 위해서 미래의 꿈을 팔아먹는 행위를 당장에 멈추고, 악몽과도 같은 현실에서 깨어야할 것이다. 개발자들이여, '악몽'을 킥하고 '현실'을 깨닫자. 그것이 필자가 말하고 싶은 마지막 말이다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2011.01.22 08:52
아는 커뮤니티에서 관련된 기사와 그 내용에 대한 문의가 올라왔기에...
관련된 내용으로 자료를 찾아보니...
참조할 만한 자료가 두개 나타났습니다.

하나는...

http://www.realseminar.com/Online/seminarView.asp?semina_id=628
' SW 생산성과 품질혁신을 선도하는 SW 공학'

이라는 무료 세미나 자료인데....
아마도... 
등록만 하면 무료로 볼 수 있는 내용인듯 합니다.


내용은 위에서 보는 내용처럼...
'효율적 SW 품질비용의 관리방안'등의 동영상 자료들이고...

한번쯤 관심있으신 분들은 참고하셔도 좋을듯...

http://blog.naver.com/huntkims?Redirect=Log&logNo=120073193986
여기 링크중에...

http://www.itsa.or.kr/m5/view.asp?partner_id=sirak&code=policy&index=list&page=1&strseq=221&gnum=221&keyword=&sname=0&ssubject=0&scontent=0
'ITSA 한국 IT 서비스산업협회'의 정책자료중에...

SW직무수행능력표준 개발 및 적용현황

이라는 이 자료를 한번쯤 보시는 것도 좋을 듯합니다.

표준이라는 것이 완전하지는 않지만..
그 자료를 기반으로 자신이 속한 기업이나 조직에 어울리는 패턴으로 변화시키는 것 또한...
관리자들의 몫이 아닌가 합니다.

이러한 자료들이 100% 옳다고 생각하는 사람도 없고...
그 부분에 대해서 문제점들이나 예외사항들이 많다고 이야기들은 하겠지만...

그 누군가가 최소한의 기준점 정도는 세워두는 것에 대해서는
감사의 글 한자 남기는 것도 좋은 방법이 아닌가합니다.

모든 문제의 해결을 혼자서 할 수는 없는 것 아니겠습니까?

ㅎㅎ
저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2009.10.19 13:19

분명... '공룡'이라 불릴만한...
그들이 시대를 주름잡던 시대가 있었다.

'컴퓨서브'로 천하를 주름잡고...
'케텔'로 통신시장을 주름잡던...
그런 시대가 있었다.

하지만...

'참여'를 중심으로한 인터넷 환경에...

'컴퓨터브', 'AOL'이 몰락하고...
국내의 상황도 '케텔(하이텔)', '천리안'도 마찬가지로...
그 시대와 함께 운명을 같이 한것이다.

그런데...
당시 '하이텔'이 몰락한 이유는 아주 간단했다.

사용자들로부터 받는 Telnet관련 통신비용 1인당 7천원~3천원의 '사용료'에 대한
유혹에서 벗어나지 못했기 때문이다.

그런데...
이제는 '참여'의 시대를 지나..
'오픈마켓'의 시대가 도래했고.

iPhone이나 안드로이드는...
절대 다수의 개발자들에 이익을 돌려주는
'오픈마켓'환경으로 시대가 변하고 있다.

이제는 '컨텐츠'의 '이익'에 빠져든
국내의 이통통신사들 또한...
그러한 '공룡'의 시대를 맞이하게 될것인가?

그나마..
비슷하게 흉내는 내고 있습니다.

LG 개발자 네트워크 ( http://developer.lgmobile.com )
삼성 모바일 이노베이터 ( http://innovator.samsungmobile.com )

하지만...
NDA조항까지..
독소조항 까지 없는

iPhone ( http://devloper.apple.com/iphone )

자...
과연 '개발자'들의 마음을 얻고..
그 '개발자'들과 공존할 마음이 있는 곳은 어디일까요?

과거 '참여'의 시대에...
그 '참여'에 같이 공조하지 못한 회사들은 이미 이 시대에서 보이지도 않습니다.

이제 '참여'와 '오픈마켓'의 시대에서...
과연 국내 개발사나 이동통신사들은 어떠한 정책으로써
'개발자'들과 호흡할까요?

마치...

iPhone만을 막으려고 애쓰는 모습은...
과거 쇄국정책을 사용하던 그런 모습을 보이는 것 아닐까요?

현재와 똑같은 정책을 계속 고수한다면...
국내의 이통통신사들과
휴대폰을 만드는 회사들의 운명도...

결국은...
과거의 '공룡'이 되지 않을까 합니다.
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2009.04.15 17:49

많은 개발자들이 오픈소스 기반의 지식에 도움을 받고 있고...
그러한 오픈소스 프로젝트에 참여하고픈 욕심은 생기지만...
뚜렷한 방향성없이...

찻잔속의 태풍이거나...
머릿속에 맴돌다 끝나는 경우가 많다.

특히나...
우리나라 개발자들의 경우에는 더더욱 힘이 든다.

수많은 오픈소스개발과
엄청난 지적 재산이 공개된...

http://sourceforge.net/

그 영역의 방대함과...
그 동안 문을 닫은 컴포넌트 회사들의 소스까지 오픈되어 있는...
정말 진정한 의미의 오픈 소스 공간인듯 하다.

개발경력이 좀 되고...
이름이 좀 알려진 사람들의 경우에는...
누구나 한번쯤 자신이 오픈소스를 시작해서 운영해보면 어떨까하는 욕심이 생긴다.

그러한 마음을 가졌다가도...
많은 현실속에서 그 꿈을 닫아버리는 경우가 허다하다.
그렇다면...

오픈소스 개발에 성공하려면 어떻게 해야할까?
그것도...

꼭... 소스포지가 아니라..
우리나라의 까페나 인터넷 환경에서?

1. 정말 흥미있는 소재여야 한다.

누구나 다 만들어 본듯한 것들... 비슷 비슷한 소재가 아니라.
아주 색다른 소재여서..
그 소재에 호감을 가지는 사람들이 한둘 이상 모여야만
그 프로젝트는 꾸준하게 진행할 수 있다.

2. 가능하면 '언어'영역부터 공략하라.

PHP와 Ruby와 같은 언어들은 그냥 탄생한 것들이 아니다.
한 사람의 창조자가 끊임없는 자신의 개량과 달굼질 속에서 완성된 것이다.
우리나라 최초의 '언어'를 오픈소스 형태로 진행할 멋진 사람은 언제쯤 나타날까?

3. 일단 '영어'는 잘해야 한다. ~.~

좁디 좁은 국내 개발자들과 협업하는 것은 정말 힘이 듭니다.
왜냐구요? 사회 여건상 소프트웨어 개발자들이 여유롭게 오픈소스에 참여하는 사회적인 기반이 되어 있지 않기 때문에... 외국계 개발자들과 협업해야 하는데... 그 의사소통의 가장 기본은 '영어'이기 때문이죠.

4. 최소 1년 이상 자신이 환경을 만들어야 한다.

누가 시켜서가 아니라...
내가 좋아서 하는 일이어야 합니다.
Linux와 같은 거대한 플랫폼도...
자그마한 커널을 만들면서 시작했습니다.

~.~

자그마한 것 부터 알차게 준비하다보면...
언젠가는 그 결과를 볼 수 있지 않을까요?

5. 욕심을 버려라..

다시 한번 생각해보세요?
오픈프로젝트를 진행하면서 얻고 싶은 것이 무엇인지?

'명성'?

만일 '명성'을 원하신다면...
오픈 소스프로젝트를 진행하는 것을 말리고 싶습니다.

차라리...
그 정도 공을 커뮤니티나 '책'을 쓰는데 몰두 하시는 것이
훨씬 성과도 좋답니다.

오픈 소스 프로젝트를 통해서 명성을 얻은 분들을 살펴보면...
자연스럽게 얻게 되는 것이지.
그 분들 자체가 '명성'을 목적으로 시작한일은 아니라는 것이죠...

~.~

마지막으로...

오픈소스프로젝트를 꼭..
내가 만들 필요있겠습니까?

http://sourceforge.net/

소소포지에 가보세요...
정말 많은 프로젝트들이 진행되고 있답니다.
그 공간에 같이 어울릴 수 있는 곳을 찾는 것도
의미가 크답니다.

꼭 내가 아니더라도...
같이 어울릴 수 있는 그런 멤버들을 만나는 경험...

한번 느끼고 싶지 않으신가요?

~.~
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2009.04.07 08:57

웹쪽의 프로그래밍이나 작업을 하는 사람들에게 가장 큰 난관이 하나 있다.
그것은...

넘을 수 없는 커다란 태백산맥!
바로...

IE6...

Explorer 6 버전이다.

가장 비표준으로 만들어진 이 IE6의 환경은 정말로 극악의 브라우져였다.
소위...
크로스 환경을 만든다고 만들어 보면...

유일하게 반항하는 넘이~~~
바로 이 IE6이다.

IE6은 2001년 8월에 정식으로 릴리즈되고 5년동안 세상을 지배(?)하다가...
2006년 10월쯤에 출시된 FireFox에 긴장하며...
2006년 11월 바로 IE7을 출시하게 됩니다.

그런데 잠 재미있는 것은 2001년부터 그후 시대는...
윈도우즈 XP의 전성시대로써...
거의 대부분의 사용자들은 IE6이 당연한 지배적 브라우져이기 때문에...

이 사실상의 표준인 브라우져에 맞추어서 작업을 하게되고...
그 시대에 가장 많은 홈페이지(?)를 구축한 대한민국의 환경은...

IE 표준 정도가 아니라...
거의

IE6 표준으로 환경을 구축했다는 점이 문제입니다.

머... 이제 IE7, IE8을 만들어도...
IE6의 환경을 지원해야하는지 말아야 하는지도 고민거리이니...
ㅋㅋ

전세계에 퍼져있는 Windows XP를 모두 수거하기 전에는...
해결이 안될 문제죠.

좌우당간...

MS도 IE6의 실수를 진즉에 인정하고 진즉에 IE7을 발표했으면 좋으련만...
아마도...
자신들의 브라우져간의 싸움이 IE6과 IE8과의 싸움이 될터인데...

사실상...
브라우져의 보급률을 비교해보면...

현재 점유율에서는 사실상 FireFox가 대세라고 해도 과언이 아닙니다.
그 이유는...

[출처 : MarketShare ]

여기서 단순하게 그림만 놓고 본다면... IE가 67%, FireFox가 21%로 나옵니다.
이 그림을 버전별로 살펴보면...

[ 출처 : http://marketshare.hitslink.com/report.aspx?qprid=3 ]

IE7은 47.32%, IE6은 18.85%
FireFox 3.0은 19.11%, FireFox 2.0은 2.27%로써...

IE 점유율은 시간이 지날 수록 IE7은 거의 현상을 유지한체로...
IE6의 시장만 줄어들고 있습니다.
그 자리를 FireFox가 차지하고 있다고 봐야겠죠?

이번에 IE8은 이러한 IE6이 줄어드는 자리를 메우기 위한 하나의 수단으로 보이는데...
과연 시장의 선택은 어떤식으로 결론이 날까요?

정말 흥미진진한 전개가 아닐 수 없습니다.

~.~
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
by 꿈꾸는자의 생각의파편들 2009.03.24 09:48

티스토리 툴바