특집 4부 - 테스터 편
‘품질’에 대한 자존심을 지켜라

박재홍｜프로젝트 전문가

제 날짜에 프로젝트를 완료했다고 해서 성공한 프로젝트라고 할 수 있을까? 품질이 보장되지 않은 소프트웨어는 사상누각에 불과하다. 따라서 최근 들어 소프트웨어 프로젝트에 있어 품질을 보증하기 위한 테스트의 중요성이 부각되고 있다. 특집 5부에서는 소프트웨어 프로세스 상에서 다양하게 실행되는 테스트에는 무엇이 있는지 기본적인 내용을 살펴보자. 또한 실제 SI 사례를 통해 현업에서 테스트가 어떻게 이뤄지고 있으며, 문제는 무엇인지 알아보고 이를 통해 실용주의적 테스트에 대해 고민해 볼 것이다.

6~70년대 성장 위주의 시대를 맞으며 건설 분야의 붐을 이루었듯이 90년대 후반 이후 각 업체의 인프라스트럭처(이하 인프라)인 IT 시스템을 구축하는 프로젝트는 봇물을 이루며 곳곳에서 터져 나왔다. 이제 금융, 제조, 서비스, 공공 등 대부분의 분야가 IT의 중요성을 인식하고 경영과 IT 전략을 동일한 수준으로 추진하게 되었다. 오히려 IT 전략과 인프라가 비즈니스를 선도해야 하는 상황이 온 것이다. 이로 인해 몇 억에서 몇 백억 원에 이르는 수많은 IT 시스템 구축 프로젝트가 다양한 방법과 기술로 발주되었고, 이는 소프트웨어 공학과 방법론 그리고 IT 기술의 발전을 재촉했다. 소프트웨어 공학은 IT 시스템을 만드는 전 과정에 대해 이론적인 토대를 제공했고 해당 프로젝트는 각각에 맞는 방법론을 채택하여 시스템 개발에 착수했다.

특히, 이 시기는 ‘납기는 생명, 품질은 자존심’이라는 제조업에서의 슬로건이 IT 분야에도 적용되어 개발 위주의 프로젝트 진행을 재촉했다. 하지만 많은 프로젝트들이 납기를 맞추는 것에 집중되었고 품질은 그 다음이었다. 그래서 품질을 PM(Project Manager)의 관점에서 관리할 수 있는 시간과 자원 그리고 이론적 바탕이 부족했다. 품질은 개발자의 몫이었던 것이다. 이런 한계를 가지고 진행된 프로젝트는 그랜드 오픈(Grand Open)을 맞으며 항상 시련을 겪기 마련이다. 납기를 제대로 지키기는 했지만 기능적, 비기능적 품질의 수준은 형편없었으니 말이다. 결국 고객은 테스트베드(실험자)가 되어 불편을 감수해야 했고, 시스템은 상당한 시일이 지나고 나서야 서서히 안정화되어 갔다. 그런 악순환은 오랫동안 지속됐다.

테스트, 테스터 시대의 도래

최근 들어 고객의 시선은 ‘품질’에 집중되기 시작했다. SI(System Integration) 업체들은 품질에 대한 고객의 요구(needs)를 알아차리고 이를 확보할 수 있는 다양한 개발 방법론을 각 사에 맞게 개발하기 시작했다. 더불어 글로벌 솔루션 업체들도 이를 지원할 테스트 툴을 개발하여 시장에 내놓기 시작했다. 품질을 납기와 동등하게 여기고 시스템의 완전성을 추구할 수 있는 시대가 온 것이다.

테스트는 고객과 프로젝트 팀원들에게 품질을 보여줄 수 있는 유일한 판단근거가 되며, 이를 통해 고객과 프로젝트 PM은 시스템 오픈에 대한 가능성을 타진하고 리스크(risk)를 사전에 예비한다. 이제 이를 가능하게 하는 시대가 되었으며, 테스트가 프로젝트 단계의 전면에 나타나기 시작했다. 이전의 보조적인 역할에서 프로젝트 성공의 열쇠를 지닌 핵심적인 활동(activity)이 된 것이다.

또한, 프로젝트 내에서 테스트를 책임지는 QA(Quality Assurance) 또는 테스트 관리자의 역할이 새롭게 제시되었다. QA는 기존의 QAO(품질관리자)의 영역에서 분리되어 테스트를 전문적으로 관리하고 주도하는 역할이다. 이로 인해 테스트는 프로젝트 내 PM, PL, QAO, TA, 분석설계자, 개발자로 나눠지는 역할에 추가되어 테스트 관리자 또는 QA가 진행하는 품질의 커다란 영역이 되었다. 또한 QA는 오픈에 대한 의사결정의 품질 근거를 제공하는 전문가가 되었다. 그리고 테스트가 시대를 만나면서 프로세스 측면의 방법론을 지원할 수 있는 다양한 툴이 제공되기 시작했다.

IT 시스템 구축 프로젝트가 착수되면 방법론에 대한 선정에 들어간다. 어떤 방법론을 쓸 것인가에 따라 예산과 인력 그리고 일정이 바뀔 수 있다. 그리고 이에 맞는 전문가 섭외가 들어간다. 이에 대응하기 위하여 SI 업체들은 방법론에 대한 연구를 끊임없이 진행한다. CMM(성숙도 평가모델), SPICE(소프트웨어 프로세스 심사) 등 국제적 품질기준에 맞는 방법론을 새로 정립하고 이를 증명할 프로젝트를 실행한다.

소프트웨어를 개발하고 구축하는 프로젝트의 품질을 보증하고 확보하기 위하여 분석/설계/개발/테스트 그리고 실행(live)하는 보편적인 프로젝트 단계마다 품질보증 프로세스를 심어 놓는다. 그러나 각각의 요구사항이 분석과 설계 단계에 어떻게 반영되고 있는지 확인하는 것은 감사자(auditor)의 개인적인 능력과 성향에 의존하기 마련이다. 단지, 유스케이스를 확인하고 컴포넌트를 검증하여 필요한 기능이 반영되어 있는 지를 확인하는 것뿐이다. 게다가 개발 단계가 되면 상황은 더욱 심각해진다. 개발자의 성향과 능력에 따라 프로그램 언어(language)로 코딩화되는 것을 확인하는 것은 더더욱 어렵다.

이젠 테스트가 나설 때이다. 테스트 전략을 다양하고 치밀하게 적용하여 완벽한 품질을 추구해야 한다. 단위 테스트, 통합 테스트, 회귀(regressive) 테스트, 부정(negative) 테스트, 크로스(cross) 테스트, 현장 테스트, 제품품질 테스트, 스트레스 테스트, 볼륨 테스트, 성능 테스트, 보안 테스트, 인수 테스트 등 수십 가지의 테스트 종류가 있다. 이를 다 수행하기에는 많은 자원과 인력 그리고 일정이 필요하다. 아무리 강조해도 지나치지 않는 게 테스트라지만 그렇다고 모든 테스트를 다 수행하려면 분석/설계/개발 비용보다 테스트 비용이 훨씬 많이 들 것이다. 배보다 배꼽이 더 큰 형상이 된 것이다.

따라서 테스트 전문가인 QA는 비용은 최소화하되 최상급의 품질을 확보할 수 있는 테스트 전략을 수립해야 한다. 솔루션 시장에는 다양한 도구와 툴이 제공된다. 테스트를 위한 수많은 통합도구와 휘황찬란한 기능을 가진 솔루션 도구들이 제공되고 있는 것이다. 지원은 충분하니 이젠 선택만이 남았다. 테스트 전문가의 다양한 테스트 전략만이 프로젝트의 성패를 좌우하는 최후의 보루이다. 프로젝트의 의사결정을 위한 중요정보의 제공자가 된 것이다.

고객은 납기뿐 아니라 최고의 품질도 함께 요구한다. 고객의 요구사항을 잘 분석하고 설계해서 개발을 잘 해야겠지만 이에 대한 검증의 데이터도 고객에게 제공해야 한다. 이를 통해 고객은 최종 의사결정을 할 수 있다. 테스트, 테스터 시대가 도래한 것이다.

테스트 전략은 프로젝트마다 다르다

테스트는 품질을 검증하는 활동이다. 반면에 품질을 보증하는 활동은 품질활동 방법론을 통해 이루어지며 예방차원으로의 접근인 반면 테스트는 품질을 검증하는 실질적인 감사의 도구로 사용된다. 품질을 검증하기 위한 테스트는 다음의 다섯 가지를 목표로 한다.

◆ 개발된 시스템이 고객의 요구사항과 설계사양을 만족시키는지 검증
◆ 컴포넌트와 프로그램들 간의 인터페이스가 설계 사양대로 이루어져 기능이 정상적으로 수행되고 있는지 검증
◆ 테스트 수행의 결과가 사전에 작성된 예상 데이터와 일치하는지 검증(일치하지 않는 경우 원인 도출)
◆ 테스트 결과에 따라 프로그램 또는 산출물에 포함된 결함을 파악하여 제거
◆ 개발 시스템 사이의 연계와 기존 시스템이 유기적으로 연계되어 업무처리 여부를 검증

이와 같은 품질 목표는 프로젝트팀에겐 언제나 요원한 일이다. 짧은 프로젝트 기간 내에 최고의 품질을 확보하는 것은 불가능하다. 그만큼 테스트 기간이 길어야 하는 데 주로 개발 위주로 프로젝트가 진행되기 때문이다. 물론, 오픈 후 유지보수로 넘어가게 되면 품질 목표는 자연스레 달성된다. 고객의 요구에 의해 시스템은 점점 안정을 찾아가고 마침내 프로젝트의 품질 목표가 유지보수 기간에 달성되고 마는 것이다. 이런 비정상적인 품질달성 현상이 현재 다양한 프로젝트에서 빈번이 발생하고 있다. 비용을 줄이고 품질을 높이는 전략적 테스트 계획은 불가능한가? 정답은 “가능하다”이다.

시스템의 특성에 따라 인트라넷 vs. 인터넷 , 기간계 vs. 정보계, 타 시스템 인터페이스 비교, 사용자 인프라 비교, 사용자 성향 비교(영업, 마케팅, 고객 등) 등으로 구분해보자. 그런 다음 단위 테스트, 통합 테스트, 성능 테스트 등 필수적인 테스트만 선택할 것인가? 아니면 여러 가지 타 테스트들 중에서 꼭 필요한 테스트만 포함시킬 것인가? 예를 들면, 인터넷 고객이 있는 경우 반드시 현장 테스트를 실시해야 한다. PC방, 고객 PC, 사무실 PC 등 다양한 고객의 접점을 고려하고 인프라까지 고려하며 현장 테스트를 실시해야 한다.

그리고 기간계 시스템인 경우 단위 테스트와 통합 테스트 그리고 회귀 테스트에 집중해야 한다. 단위 테스트와 통합 테스트로 이어지는 기능품질수준을 확보하기 위해 회귀적 방법을 도입, 단위 테스트부터 발생한 에러, 결함 등을 통합 테스트를 거쳐 인수 테스트까지 추적 관리해야 한다. 또한, 기간계의 특성상 최번시(peak time) 폭주를 견뎌낼 정도의 하드웨어를 갖추고 있어야 한다. 이를 해결하기 위한 것이 성능 테스트이다. 그리고 고객 정보와 인사 정보를 관리하는 시스템인 경우 반드시 보안 테스트를 실시해야 한다. 외부의 해커에 의해 해당 시스템이 뚫리는 경우가 발생하면 PM이 법적, 사회적 책임을 모두 다 져야하기 때문이다. 이처럼 다양한 환경(사용자, 하드웨어, 소프트웨어. 네트워크, PC 등)에는 다양한 테스트 전략이 적용되어야 한다. 선진 사례에서 발견한 적용 사례를 그대로 본인의 프로젝트에 적용하는 것은 실행하는 데 어려움은 없지만 한복에 넥타이를 매는 것 같이 어색하고 비효율적이다. 다시 말해 테스트 전략은 모든 프로젝트가 다 같지 않다. 단지 품질에 대한 기대수준, 방향 그리고 목표만 같다. 따라서 현장에서 활동하는 테스트 전문가의 활약에 기대와 함께 최적화된 전략을 기대해 본다.

<그림 1> 테스트 로드맵

다양한 테스트에 대한 이해는 필수

테스트는 정상에 있는 품질목표를 달성하기 위한 등산과 같다. 입구에서 시작해 산등성이를 지나 절벽을 오르면 정상에 도달할 수 있다. 하나하나의 과정을 반드시 이겨내야만 정상에 도달해서 환희, 기쁨, 만족감 등을 맛볼 수 있는 것이다

품질은 기능 품질과 비기능 품질로 나눈다. 기능 품질은 기능성, 작동성, 정합성 등 시스템의 기능을 테스트한다. 단위 테스트, 회귀 테스트, 부정 테스트, 통합 테스트, 크로스 테스트, 제품품질 검사, 인수 테스트, 현장 테스트 등을 기능 테스트로 분류한다. 비기능 품질은 주로 성능, 보안 등 인프라에 대한 품질을 말한다. 성능 테스트, 스트레스 테스트, 볼륨 테스트, 보안 테스트 등을 비기능 테스트로 분류한다.

단위 테스트

단위 테스트는 개발과 동시에 진행하여 개발 기간과 함께 종료한다. 개발자는 설계자가 설계한 대로 코딩을 하고 설계자와 함께 기능의 정확성을 확인한다. 소프트웨어가 작동하는 지 확인하기 위해 신규 또는 변경 코드만 따로 테스트하는 최초의 테스트 단계이며 이를 통해 내부 프로그램과 모듈 로직에 맞추어 프로그램 스펙을 검증하고 나아가 프로그램 로직을 검증한다.

단위 테스트의 검증 단계로 단위 모듈 테스트와 단위 화면 테스트를 수행하고, 모듈 테스트는 단위 모듈의 기본 처리를 검증하는 단계이며, 각 모듈에 구현된 기능의 정확성과 완전성을 검증한다. 화면 테스트의 범위는 단위 화면 내 버튼 기능이 모두 정상임을 확인한다.

회귀 테스트

회귀 테스트는 단위 테스트에서 시작해서 인수 테스트로 끝나는 테스트 전체기간 동안 결함의 추적성을 통제하여 한 번 발생한 결함은 다시 발생하지 않도록 점진적, 반복적으로 수행하는 것이다. 이를 위해 테스트 관리자는 형상관리 툴을 이용하여 단위 테스트, 통합 테스트, 인수 테스트 등 테스트 시 발생한 모든 결함들을 등록하고 반복적 테스트를 통해 기능의 완전성과 정확성을 높여 품질을 보증한다.

부정 테스트

부정 테스트는 사용자의 예기치 못한 조작방법에 대응하기 위해 일반적인 작동 프로세스를 무시하고 테스트 시나리오 없이 기능을 테스트를 하는 것이다. 조회 버튼을 백 번 연속해서 누른다든지 날짜가 들어가는 곳에 문자를 입력하거나 2월 30일과 같이 존재하지 않는 데이터를 입력하는 등 일반적인 사용자가 하지 않는 범위에 대해 테스트를 하는 것이다.

통합 테스트

통합 테스트는 기능 테스트 중 가장 중요하고 반드시 실시해야 하는 필수 테스트다. 어떤 프로젝트팀은 테스트 종류 중 오직 통합 테스트에만 집중하여 모든 결함과 오류를 수정하고 이 데이터를 근거로 오픈에 대한 의사결정을 한다. 통합 테스트 목적은 다음과 같다.

◆ 단위 테스트를 통과한 애플리케이션과 업무 기능의 인터페이스가 정상적으로 작동하는지를 검증한다.

◆ 이를 위해 통합 모듈의 기능, 화면과 연관된 업무 기능, 모듈 간의 인터페이스 검증 테스트 등에 대해 테스트와 평가를 한다.

◆ 고객이 제시한 테스트 시나리오를 바탕으로 하여 실행방법과 예상결과 등을 포함하는 테스트 케이스를 정의하고 그 기준에 의하여 통합 테스트를 진행한다.

◆ 통합 테스트를 위해 정의된 세부적 테스트 케이스가 고객의 테스트 시나리오의 요구조건을 모두 수용해야 하며 각 테스트 케이스의 실행이 예상결과와 일치해야 해당 케이스의 실행이 성공한 것으로 간주한다.

◆ 반드시 데이터 정합성에 대해 테스트를 진행해야 한다.

통합 테스트를 통해 많은 결함이 도출된다. 결함들은 난이도에 따라 분류되어 수정일정과 함께 개발자에게 넘겨진다. 분류는 다음과 같이 할 수 있다.

◆ 치명결함 : 애플리케이션 종료, 시스템 다운, PC 재부팅 등을 하여야 하는 결함

◆ 중결함 : 데이터의 정합성 불일치 또는 해당 업무(기능)을 정상적으로 진행할 수 없는 결함

◆ 경결함 : 일부 오류를 포함하고 있으나 처리가 가능한 결함

◆ 단순결함 : 해당 기능을 수행하는데 문제가 되지 않으나 사용자들의 에러를 유발시킬 수 있거나, 혼동할 수 있는 내용(예 : 불명확한 메시지 처리, 조회필드의 입력가능, 오타, 등)

<그림 2>는 일반적인 통합 테스트 계획과 수행절차이다.

크로스 테스트

크로스 테스트는 테스트 종류라기보다는 테스트 진행방법 중의 하나이다. 기능 테스트를 실행하는 데 고객에게만 테스트를 맡기지 말고 프로젝트 팀원 전원이 테스트를 함께 참여하여 서로의 것을 테스트하며 많은 결함과 오류를 발견하고자 하는 목적에서 만들어진 것이다. 크로스 테스트의 묘미는 본인이 개발한 것보다 타인이 개발한 프로그램에서 훨씬 많은 결함을 도출해낸다는 것이다.

제품품질 검사

제품품질 검사는 공인된 테스트 전문 업체를 통해 단기간에 개발된 시스템을 전수 검사를 하는 것이다. 품질 체크리스트를 기반으로 4~5명이 참여하여 기능에 대한 테스트를 수행한다. 이 때 투입된 전문가들은 부정 테스트에 대한 개인적 경험을 이용하기도 한다. 테스트 전문가들에 의해 실행되기 때문에 숨겨진 에러까지 발견하곤 한다.

<그림 2> 통합 테스트 수행절차

인수 테스트

인수 테스트는 고객이 개발된 시스템을 최종 인수하기 전 제공된 기능과 성능이 고객의 요구사항과 일치하는지를 고객이 주관하여 최종으로 실행하는 것이다. 실제 사용자를 기준으로 테스트가 진행됨으로 비즈니스 측면의 테스트가 진행된다. 일반적으로 고객의 통합 테스트에 대한 참여를 통해 발생한 에러에 대한 수정, 보완 등이 끝난 것을 확인한 경우 인수 테스트를 대체하곤 한다.

현장 테스트

현장 테스트는 실제 사용자의 인프라 환경과 역할에 따른 사용방법 등을 고려하여 선정된 사용자들의 사업장에서 이루어지는 실전 테스트이다. 홈페이지 등 인터넷 환경에서 불특정다수가 사용하는 시스템인 경우는 PC방도 예외가 아니다. 다양한 PC, OS, 네트워크 환경 등 여러 조합에 대한 선정을 통해 최대한 현장의 목소리를 듣고자 하는 것이다.

성능 테스트

소프트웨어의 효율성(응답속도, 처리량, 처리속도)을 테스트하는 것으로서 볼륨 테스트나 스트레스 테스트와 병행하여 수행될 수도 있다. 다량의 데이터를 조회하거나 수정하는 중요 프로그램에 대해 테스트를 수행하고 응답속도를 측정한다.

1. 주요 대상
­ 다량의 데이터를 편집하여 조회하는 중요 프로그램에 대해 테스트를 수행함

2. 수행절차
­ 테스트에 필요한 데이터를 준비함
­ 테이터를 편집/조회할 프로그램을 수행시켜 테스트를 수행함

볼륨 테스트

소프트웨어로 하여금 사용자가 요구한 만큼의 데이터 처리가 가능한 지를 테스트하는 것이다.

1. 주요 대상
­ 중요 마스터 데이터에 대해서는 테스트를 수행함
­ 다량의 데이터가 조회되거나 업데이트되는 화면으로 테스트를 수행함
­ 볼륨 테스트에는 매우 많은 비용이 필요하므로 필요 이상으로 과다한 테스트가 되지 않도록 시스템의 특성을 잘 고려하여 수행해야 함

2. 수행절차
­ 볼륨 테스트의 대상이 되는 테이타베이스에 사용자가 요구한 만큼의 데이터를 임의로 준비함
­ 해당 테이터를 입력, 또는 배치로 생성하는 애플리케이션을 수행하여 데이터의 정상처리 여부를 테스트함 　

스트레스 테스트

소프트웨어에 다양한 스트레스를 가해봄으로써 짧은 시간 동안에 많은 양의 데이터를 처리할 수 있는지를 테스트하는 것이다. 또한 분산처리 시 시스템 구성요소별로 스트레스가 적절히 분배되는지를 테스트한다.

1. 주요 대상
­ 하나의 데이터베이스에 많은 양의 데이터를 한 번에 입력/수정하거나, 여러 개의 데이터베이스에 다양한 데이터를 한 번에 입력/수정하는 프로그램에 대해 테스트를 수행함
­ 사용빈도가 높은 화면을 대상으로 테스트를 수행함

2. 수행절차
­ 테스트에 필요한 데이터베이스를 준비함
­ 프로그램이 처리 할 데이터를 준비함
­ 다수의 사용자가 동시에 데이터를 처리하는 경우 해당 테스트 환경을 준비함

보안 테스트

불법적인 소프트웨어 사용을 방지하는 테스트로서 자체의 보안체계가 완벽한 지를 테스트하는 것이다. 또한 적합한 권한을 가지지 않은 사람에게 자료나 정보가 제공되지 않는 것을 보장하기 위한 테스트이다.

1. 주요 대상
­ 전체 시스템에 대한 접근시 보안 상태와 개별적으로 보안이 정의된 프로그램에 대하여 테스트를 수행함

2. 수행절차
­ 보안이 정의된 프로그램을 파악함
­ 해당 프로그램을 다양한 방법(임의 패스워드 등)으로 테스트를 수행함

“죄 없는 자가 있다면 돌을 던져라”

국내 OO은행은 전사 DW(DataWarehouse)를 구축하기 위해 RFP(Request for Proposal)를 공지해 발주를 냈고 대형 SI와 글로벌 솔루션 업체들의 합종연횡을 통해 S사, 국내 H 솔루션사 컨소시엄과 EDW 구축 계약을 했다. 기간은 7개월, 은행 기간계의 여신, 수신, 외환, 공제, 증권 등 은행 내 모든 데이터를 추출, 정제, 로딩을 거쳐 DW를 구축하고 이의 활용을 위한 신 정보계 시스템을 구축하는 것이다.

박 대리는 여신파트 정보계 시스템 구축을 위한 웹 프로그램 담당자이다. 개발자로서 은행 여신업무에 대한 이해를 위해 현업 담당자(이하 현업)와 수차례에 걸쳐 인터뷰를 하고, 데이터 모델에 대한 분석과 설계, 애플리케이션 아키텍처에 대한 스터디와 연습을 통해 개발을 위한 준비 작업을 완료했다. 본격적인 코딩의 시간이 되었다. 2개월의 짧은 기간 동안 200여 개의 조회 화면을 개발해야 한다. 그리고 1개월의 통합 테스트를 거쳐 그랜드 오픈을 한다. 그러기 위해 PL(Project Leader)의 관리 하에 개발을 진행하는 동안에도 현업의 단위 테스트를 거쳐야 한다. 단위 테스트는 개발자의 몫이자 현업 고객이 해야 할 1차 기능 테스트이다.

하루에 화면 5개씩 SQL 쿼리를 짜고 웹 화면에 적용한다. 화면이 복잡하면 할수록 화면 변수에 맵핑해야 할 Input 변수가 많아진다. 개발된 화면에 대한 단위 테스트를 위해 박 대리는 기본적인 자가 기능 테스트를 거쳐 현업에게 단위 테스트를 의뢰한다. 정해진 테스트 프로세스에 의해 하루에 5개씩 개발이 완료된 화면을 현업에게 제공하고 현업은 테스트 후 테스트 결과를 피드백해야 한다.

그런데 고객인 이 차장은 테스트 프로세스를 무시하고 우선 자신이 요구사항에 적은 대로 개발해 놓으라고 한다. 그러면 시간을 갖고 천천히 테스트를 하겠노라고…. 고객의 요청사항인 만큼 맘 놓고 정해진 요구사항대로 휴일도 없이 열심히 개발하고 자가 단위 테스트를 했다. 드디어 2개월이 지나 화면 200여 개발을 다 완료했다. 박 대리는 뿌듯해했다. 이제 남은 건 통합 테스트다. 그리고 통합 테스트는 내일부터 시작이다. 그런데 이 차장이 박 대리가 개발한 화면을 놓고 볼멘소리를 하기 시작한다. 화면 한 개를 테스트했는데 OO은행의 자산이 10조밖에 안 되는데 박 대리가 만든 화면은 100조가 나왔다는 것이다. 박 대리는 이 차장에게 “차장님께서 말씀하신 요구사항대로 개발했다”고 말했다. 이 차장은 개발자인 박 대리의 능력을 믿었고 대충 이야기해도 제대로 알아듣고 개발한다고 생각했다고 한다.

그리고 박 대리는 PL로부터 “내일부터 통합 테스트인데 박 대리가 맡은 부분에 대한 단위 테스트를 진행해 주세요”라고 들었다. 눈앞이 캄캄했다. 남들보다 열심히 고군분투하며 앞서서 개발을 했고, 고객이 원하는 대로 진행했으며, PL에게 진행 상황에 대한 보고까지 하면서 열심히 개발에 매진했지만 박 대리는 통합 테스트에도 미치지 못하는 단위 테스트 불량 개발자였다. 박 대리는 눈물을 머금고 이 차장과 함께 단위 테스트를 다시 진행했다. 200여 화면에 대해 하나씩 기능에 대한 검증과 조건에 대한 검증 그리고 데이터에 대한 검증을 진행해 나갔다. 1개월이 흘러 다른 부분은 통합 테스트를 완료한 상태에서 오픈을 했고 박 대리가 맡은 부분은 오픈이 연기가 되어 통합 테스트를 보름간 더 진행했다. 프로젝트 팀원이 모두 철수한 후까지 박 대리는 미진한 통합 테스트를 진행했고, 결국 프로젝트 전체 납기에 영향을 줘 고객과의 약속도 지키지 못했다. 개발자인 박 대리는 과연 무엇을 잘못한 것일까? 고객의 요청사항을 무조건 들어준 것이 잘못인가? PL에게 보고도 했는데 왜 비난은 박 대리가 들어야 할까? 참으로 난감하다. 테스트는 과연 누구의 책임일까? 개발자인 박 대리는 열심히 개발한 죄밖에 없었을 텐데 말이다.

문제 예방을 위한 최선은 무엇인가

김 과장은 머리가 터질 지경이다. 이제 곧 일주일간의 통합 테스트를 시작해야 하는 데 아직 환경이 구축되질 않았다. 분명 2주일 전에 계획을 세우고 R&R(Role & Responsibility)을 정하고 체크리스트(Checklist)를 만들어 점검까지 했는데도 말이다.

현업에게 뭐라고 이야기해야 할까? 통합 테스트 환경을 구축하기로 한 담당자는 개발자들이 개발 소스에 대해 제대로 단위 테스트를 하지 않아 에러가 발생한다고 한다. 개발자들은 현업의 요구사항이 단위 테스트할 때 변경되어 적용하다가 그랬다고 한다. ‘그래, 통합 테스트의 이틀 지연이다’라고 결심한 김 과장은 고객에게 양해를 구하고, 에러가 발생한 단위 테스트를 집중적으로 해서 기능에 대한 보완을 한다.

오늘부터 개발자들에게 밤샘야근을 지시한다. 어쩔 수 없다. 이틀 후에는 통합 테스트를 실시해야 한다. 고객이 최대의 관심사를 갖고 주시하고 있기 때문이다. 통합 테스트를 제대로 이행하지 못하면 오픈 지연으로 납기에 차질이 생긴다. 현업이 담당한 통합 테스트 시나리오를 점검한다. 엉망이다. 개발팀 담당자를 불러 시나리오에 대해 협의를 했느냐고 물어보았다. 현업이 물어보았지만 시나리오는 현업의 책임이라고만 이야기했단다. 현업은 가이드 없이 대충 작성하여 제출한 것이다. 큰일이다. 새로 작성하자니 시간이 없고 이대로 진행하자니 통합 테스트가 엉망일 것 같다.

현업과 사태를 해결하기 위한 회의를 했다. 현업은 자신 있게 말한다. “통합 테스트 시나리오가 없어도 현업들은 각자 생각한 대로 테스트 케이스를 만들어 테스트할 것이다. 굳이 문서로 작성할 필요가 없을 것 같다” 맞는 말이다. 하지만 이렇게 되면 현업이 생각하는 테스트의 범위, 비즈니스 로직, 데이터 등을 컨트롤할 수가 없다. 어떻게 할지 고민이다. PM과 상의를 한다. PM이 적정한 조정안을 제시한다. 그 안은 다음과 같다.

“상세한 통합 테스트 시나리오를 가지고 통합 테스트를 실시하지 않지만 현업이 직접 테스트한 결과에 대한 시나리오 및 테스트 결과는 문서로 작성하여 제출한다. 그리고 에러 발생시 결함 보고서를 제출한다”

현업은 잠깐 고민한 후 즉각 승낙한다. 이틀 후 통합 테스트는 실시되었다. 전쟁이다. 현업 담당자는 테스트를 실시하고 에러 발생한 즉시 개발자는 뛰어다닌다. 단위 테스트 시 해결됐던 에러도 다시 발생한다. 단위 테스트 시 발생하지 않았던 에러도 발생한다. 외부 인터페이스가 성공했다 실패했다 한다.

하루를 마치고 테스트 케이스와 결함보고서를 정리한다. 테스트 범위는 10%인데 결함은 무려 100개를 상회한다. 이제 개발자들과 회의를 진행한다. 우선, 에러를 단순결함과 중결함으로 구분한다. 단순결함에 대해 수정 조치를 먼저 하여 에러의 개수를 줄여나간다. 중결함은 이틀 정도 시간을 두고 개발자에게 해결을 지시한다. 벌써 12시가 넘어가고 있다. 내일 이틀째 통합 테스트가 기다리고 있다. 3일째가 되자 통합 테스트는 속도를 올려 진행된다. 테스트 범위가 벌써 70%를 상회한다. 에러는 점점 줄어든다. 이제 안정을 찾아가는 듯하다. 개발자들에게 에러 수정을 독려한다. 중결함이 아닌 단순결함들은 당일 수정 조치를 원칙으로 하고 개발자들을 독려한다. 현업들이 차츰 안정을 찾아간다. 오픈을 해도 된다는 낙관론이 생기기 시작한다. PM에게 보고한다. 통합 테스트가 오픈 수준에 맞추어 진행되고 있고 현업이 원하는 수준의 품질(quality)을 보장할 수 있을 것 같다. PM은 무뚝뚝하게 경고한다.

“김 과장, 자네 QA 역할이 뭔 줄 아나? QA는 에러가 발생하면 그때그때 신속하게 처리하도록 지시하는 게 아니라 에러의 발생을 애초부터 막는 것일세“

김 과장은 마음이 상했다. 그래도 최선을 다해 에러 발생시 신속하게 수정지시를 해서 고객의 마음을 조금은 돌려놓았는데 말이다. 김 과장은 고민한다. QA의 역할이 에러의 발생 방지라면 어떻게 에러 방지를 할 수 있을까? 그럼 개발 단계부터 QA의 주도가 필요할 것이다. 그리고 통합 테스트 시나리오는 누가 작성하는 게 맞을까? 분명 현업이 하는 것이 맞을 텐데 어떤 고객도 하겠다고 하질 않으니 그것이 문제이다. 어떻게 그들을 설득시켜야 할까? 현실과 이상의 커다란 간극, 이것이 딜레마이다.

등잔 밑이 어둡다, 모든 환경변수에 대해 고민하라

문제는 응답 속도이다. 고객은 응답속도의 기준치를 ‘3초 이내’로 제시했다. 개발해야 하는 모든 화면에 대한 응답속도를 3초 이내로 끌어내려야 한다는 것이다. 아키텍처 프레임워크는 검증된 것을 적용했으니 문제가 없는데 비즈니스 로직이 문제이다. 원하는 기능들이 복잡할수록 네트워크를 타고 전송되는 패킷의 양이 많아져 PC에서의 로딩 시간이 길어지면 3초 이내를 지키기는 거의 불가능에 가깝다. 하지만 어찌하랴 고객이 원하니 어쩔 수가 없다. 홍 과장에게 숙원 과제가 맡겨졌다.

우선, 성능 테스트를 실시해서 현재의 상황에 대한 문제점을 도출해야 한다. 그리고 도출된 문제점을 해결하기 위해 튜닝을 실시해서 고객의 기준치를 맞추어야 한다. 홍 과장은 시스템 엔지니어인 박 책임에게 성능 테스트 환경구성을 의뢰하고, 개발팀에게 만들어진 개발소스에 대한 테스트 빌드를 구성하기 위해 성능 테스트 계획을 세웠다. 성능 테스트 환경은 운영(production) 환경과 유사하게 구성이 되어야 한다. 운영체제와 소프트웨어 버전이 같아야 하고, 하드웨어 용량은 운영환경의 것을 이용하면 최고겠지만 그렇지 못할 경우는 성능 테스트계를 임시로 구성하여 2/3 정도의 크기로 갖추어 놓는 게 좋다.

시스템 엔지니어인 박 책임은 성능 테스트 환경구성에 대해 일정에 맞추어 설치를 완료하겠다고 약속했다. 다음은 성능 테스트 시나리오의 작성이다. 다행스럽게 통합 테스트에서 사용하던 통합 테스트 시나리오가 있어 이를 재활용하기로 한다. 다음은 목표 동시사용자 수의 설정이다. 성능 테스트를 통해 목표 동시사용자 수에 맞게 환경구성과 개발소스에 대한 튜닝이 이루어지면 된다. 구 시스템에 대한 월/주/일/시간대별 사용자 수를 추출하여 최번시(최고 피크시) 동시사용자 수를 설정했다. 다음은 성능 테스트 시나리오에 맞게 툴을 이용하여 스크립트 코딩을 한다.

드디어 1차 성능 테스트의 결과가 나왔다. 암담하다. 목표 동시사용자 수에 훨씬 미치지도 못하는 수치가 나왔고 응답속도는 10초를 상회한다. 하드웨어와 소프트웨어의 환경구성에 대한 파라미터를 재설정하고 개발팀에게는 소스 내 잘못된 SQL과 로직에 대하여 수정을 요청한다. 2차 성능 테스트를 실시한다. 2차에 비해 나아지기는 했지만 여전히 어이없는 수치이다.

개발팀과의 마라톤 회의를 통해 소스 내 모든 코드에 대한 점검을 실시한다. 개발자들은 스타일에 따라 코딩을 했다. 표준화를 강력히 요청했지만 표준화된 팁을 사용하지 않는 개발자가 대다수였다. PM에게 현상에 대한 보고를 하고 개발자들에게 표준화된 형태로 코드를 수정할 것을 지시했다.

3차 성능 테스트를 했다. 고객이 설정하고 요청한 목표 동시사용자 수와 응답속도를 만족하는 수치가 나왔다. 성공이다. 역시 성능에 대한 키는 개발자들이 쥐고 있었다. 기쁜 마음으로 성능 테스트에 대한 결과보고를 하고 오픈을 해도 좋다는 고객의 동의를 얻어냈다. 드디어 오픈하는 날이다. 시스템 가동과 함께 시스템에 대한 사용도가 올라간다. 그런데 이상하게도 응답속도가 제대로 나오지 않았다. 어떤 것은 10초를 넘는 것도 있었다. 큰일이었다. 분명 몇 차례에 걸친 성능 테스트를 통해 코드에 대한 튜닝, 파리미터에 대한 튜닝을 했고 고객의 목표치를 만족했는데 말이다.

본격적인 조사에 착수했다. 네트워크 환경과 PC의 성능차이가 원인인 듯 했다. 고객은 현장 응답속도 기준으로 3초를 요청했단다. 막막했다. 현장의 인프라를 고려하지 않고 성능 테스트를 한 것이다. 현재의 인프라를 마음대로 업그레이드할 수 없지만 환경변수에 대한 고려가 포함된 성능 테스트를 실시했어야 한다는 것이다. 사용자의 불만은 날마다 수십 개씩 접수되었다. 도저히 쓸 환경이 되지 않으니 이전 시스템을 사용하게 해달라는 요청도 있었다. 밤을 세워가며 고객과 현재의 문제점에 대한 대안을 논의했다.

사용자에게 PC의 업그레이드를 요청하고 네트워크 인프라 또한 네트워크 파트의 도움으로 취약 지역에 대한 증설을 하기로 했다. 홍 과장은 노력한 만큼 결과를 얻지 못했다고 풀이 죽어 있었다. PM은 그런 변수도 고려하지 않고 실험 환경 데이터에 대한 분석결과에 만족해 했다고 질책했다. 고객은 시스템 사용자를 기준으로 목표를 제시한다. 사용자에 대한 분석 없이 성능 테스트 시나리오를 작성하고 환경변수에 대한 고려 없이 성능 테스트를 실시했다고 불만을 토로했다. 성능 테스트는 왜 이리 복잡하고 어려운 것일까? 환경변수에 대한 고려와 함께 성능 테스트를 하는 것이 가능한가? 그런 것은 툴이 지원해 줄 수 있을까?

테스트의 미덕, 중용

그랜드 오픈이 한 달 앞으로 다가왔다. 이제 한 달만 지나면 프로젝트 팀원 50명이 7개월간 고생한 결과에 대해 평가를 받게 된다. 결코 팀원들의 노력이 헛되지 않도록 철저하게 오픈을 준비할 것이다. 지난 6개월 동안 시스템 구축을 위해 요구사항을 분석하고 컴포넌트를 추출, 설계를 하고 코딩을 해왔다. 그리고 500여 화면에 대한 단위기능의 개발과 병행하여 화면 중심의 단위 테스트와 모듈 중심의 단위 테스트를 실행해 왔다.

단위 테스트를 담당한 PL들이 테스트 프로세스를 잘 준수해줬고 현재, 통합 테스트와 함께 성능 테스트를 진행하고 있다. 통합 테스트와 성능 테스트를 마치면 대망의 오픈을 할 예정이다. 그런데 과연 통합 테스트와 성능 테스트만 잘 마치면 성공적인 오픈을 할 수 있는 것일까? 사용자에게 편리하게 화면 설계가 되었고, 응답속도도 3초 이내로 사용자 기대수준을 만족하고, 시스템 사용상의 불안정성도 제거한, 사용자가 만족하는, 성공적인 시스템을 오픈할 수 있는 것일까? PM으로써 리스크를 최소화하고 성공에 대한 확신을 줄 수 있는 테스트 결과에 대한 근거를 기반으로 고객이 인정하고, 우리 스스로가 인정할 수 있는 시스템을 제공해야 한다.

강 PM은 실로 오래간만에 소프트웨어 공학론을 펼쳤다. 테스트에 대한 부분을 세밀히 훑어봤지만 강 PM이 지금 필요로 하는 테스트와 검증방법은 찾아볼 수 없었다. 그저 통합 테스트와 성능 테스트를 열심히 하면 된다는 그런 내용들이었다. PL 회의를 소집했다. 현재 진행하고 있는 통합 테스트와 성능 테스트를 체계적이고 상세하게 진행하되 그 외 다른 테스트 방법론의 존재유무를 논의했다. 테스트 전문가인 박 대리가 부정 테스트와 회귀 테스트 그리고 현장 테스트에 대한 제안을 했다.

강 PM은 그 테스트들의 정의와 진행방법 그리고 효과에 대한 진지한 고민을 했고, 박 대리의 제안을 받아들이기로 결정했다. 더불어 고객들에게 다양한 테스트들을 실행함으로 얻을 수 있는 효과에 대해 자랑스럽게 이야기했다. ‘리스트 제거’, 다양한 테스트를 진행하는 궁극적인 목표인 것이다. 강 PM은 외부 테스트 요원들을 모집하고 그들에게 현재 진행하고 있는 테스트 시스템에 대해 테스트 시나리오를 무시한, 기발하고 스토리가 없는, 사용자 입장에서 할 수 있는 가능한 모든 부정적인 테스트를 요구했다.

어떤 이는 조회 화면을 수십 번 연속해서 눌렀고, 어떤 이는 조회 중간에 3초를 기다리지 않고 화면을 닫아 버리고, 어떤 이는 숫자를 넣어야 할 곳에 문자를 넣어 조회하고, 또는 날짜 조건 입력 시 백년의 기간을 조회해 보기도 하는 등 다양한 부정 시나리오가 쏟아져 나왔다.

조회화면을 동일한 조건에서 수십 번 연속해서 누르자 동일한 데이터가 아닌, 새로운 데이터가 계속 조회되었다. 조회조건은 동일한 데 수십 번 연속해서 누른다고 조회내용이 다르게 나오는 것이었다. 해당 개발자는 황당해 했다. 그렇게 사용하는 사용자는 없다는 것이다. 그래도 이런 결과가 나온 것은 코드상 로직의 문제가 있음을 제기했고 개발자도 검토를 해본 결과 자신이 그런 코딩을 했다는 것을 믿지 않는 눈치였다. 이런 부정 테스트에 대한 결과를 고객에게 설명하자 고객은 희색이 만연하여 시스템 품질에 대한 확신을 가지는 눈치였다.

다음 회귀 테스트는 단위 테스트에서 나온 결함을 기본 베이스라인(baseline)으로 설정하고, 통합 테스트, 성능 테스트까지 지속적으로 해당 결함에 대한 회귀 테스트를 실행하여 최종 테스트에 통과가 될 때까지 실행하도록 PL들에게 지시했고, PL들 또한 결함 발생에 대한 추적관리를 통해 ‘한 번 발생한 결함은 두 번 다시 발생하지 않는다’는 원칙을 고수하게 되었다.

마지막으로 현장 테스트를 위해 고객의 적극적인 협조로 업무별 종류, PC 사양의 종류, 네트워크 용량의 종류 등 다양한 케이스의 현장을 선정하고 동일한 시나리오를 통해 기능의 완전성과 응답속도의 차이를 측정하고 기준을 설정하여 해당 시스템에 대한 현장 사용자의 만족도를 예측할 수 있었다. 정말로 다양한 케이스에 따라 기능의 완전성에도 차이가 있었고, 응답속도의 차이 또한 천차만별이었다. 고객이 제시하는 ‘3초 이내’는 어떤 기준인지 고객의 기준을 명확히 하는 근거가 될 수 있었다.

이런 추가적인 비정형적인 테스트를 통해 고객은 시스템에 대한 신뢰를 가질 수 있었고, 프로젝트팀은 7개월의 고생이 헛되지 않는 성공적인 오픈을 할 수 있었다. 테스트 종류 몇 가지를 실행한 것뿐인데 고객은 결과에 대해 대만족스러워했고 시스템은 안정적인 운행을 하게 되었다. 그저 단위 테스트, 통합 테스트, 성능 테스트 등 정형적인 테스트만 수행했을 경우는 어떠했을까? 물론, 테스트의 종류가 많다고 고객이 신뢰를 하는 것은 아니다. 단지, 현재 진행하고 있는 방법론상의 테스트와 이를 보완할 수 있는 다양한 테스트를 함께 수행함으로써 완벽성을 기할 수 있는 크로스 체크 결과가 된 건 아닐까? 결함이 나오는 테스트가 올바른 테스트일까? 아니면 결함이 하나도 없는 테스트가 올바른 테스트일까? 테스트는 그 역할로 인해 항상 중용의 길을 걸어야 할 존재인 것이다.

모든 해답은 프로젝트 현장에 있다

테스트는 아무리 강조해도 지나치지 않는 활동이라고 했다. 대부분 프로젝트들은 필수적인 테스트(단위, 통합, 성능)만 선정하고 준비하고 실행하여 이를 통해 나온 결과만을 가지고 의사결정을 한다. 그리고 오픈 후 많은 문제에 직면하게 된다.

기능의 오류, 시스템의 불안정, 요구사항의 미반영, 사용자의 미숙 등 프로젝트 막바지에 테스트에 모든 인력과 정열을 집중했음에도 불구하고 예측하지 못한 결함들이 쏟아져 나온다. 이를 어떻게 해야 하는가? 어쩔 수 없는 것일까? 테스트에 아무리 집중해도 품질목표를 달성하는 것은 프로젝트에서는 불가능한 목표일까?

문제는 바로 프로젝트 현장에 있다. 필수적인 테스트들을 선택하고 집중하여 실행했지만 여기에는 많은 헛점이 있다는 것이다. 또한 좀 더 완벽한 품질을 달성하고자 한다면 시스템 특성에 맞는 테스트를 전략적으로 적용해야 하는 것이다. 다음은 테스트 종류별 잘못된 실행사례이다.

첫째, 단위 테스트를 개발자에게만 맡겨두고 그 결과를 인정하는 경우이다. 개발자는 본인이 코딩한 프로그램에 대해 해당 기능에 대한 소극적인 테스트에 임한다. 데이터는 알고 있는 데이터 1~2개 정도이고 다양한 조건에 대한 테스트는 개발자에게 기대하기 힘들다. 왜냐하면 그들은 방대한 개발물량이 있기 때문에 진척율에 쫓긴다. 이를 예방하기 위해 반드시 해당업무 PL이 개발자들이 실행한 단위테스트에 대한 확인테스트를 실행한 후 진척율에 반영하는 것이다.

둘째, 통합 테스트 수행 시 통합 테스트 시나리오를 고객이 미리 작성하지 않고 개발팀에서 형식적으로 간략하게 작성하는 경우이다. 이런 경우 고객은 자신의 머릿속 시나리오대로 테스트를 진행하고, 개발팀은 테스트 케이스에 대한 전체범위를 모르는 상태에서 테스트를 실행하는 고객의 수준과 태도에 따라 시스템 내 품질은 업무범위에 따라 고르지 못한 상태가 된다. 이런 경우, 프로젝트팀은 품질 목표를 달성할 수 없게 되고 고객에게 맡겨진 품질은 미궁 속으로 빠져들게 된다. 이를 예방하기 위하여 고객들에게 통합테스트가 시작되기 한 달 전에는 교육을 통해 통합 테스트 시나리오 작성의 당위성, 필요성에 대해 설득하고 합의를 이끌어 내어 반드시 통합 테스트 시나리오를 작성한 후 통합 테스트를 실행하는 것이다. 통합 테스트 시나리오는 초기 고객의 요구사항 정의서와 함께 고객의 요구사항이 반영된 최종 품질기대 문서이다. 셋째, 성능 테스트 수행 시 사용자 환경(PC, 네트워크 등)에 대한 고려 없이 성능 테스트 툴을 통해 나온 응답속도와 동시사용자 수에 대한 무비판적인 수용이다. 이런 경우 오픈 후 반드시 성능, 특히 응답속도에 대한 불편신고를 가장 많이 받는다. 성능 테스트는 시스템의 성능, 동시사용자 수 그리고 화면별 응답속도에 대한 객관적인 수치를 얻고자 한다.

이를 위해 TA(Technical Architect)는 운영환경과 유사하게 성능 테스트 환경을 구성하고 해당 프로그램들을 선정, 비율을 조정하여 테스트를 실행한다. 그리고 최번시 수용 가능한 동시사용자 수와 시스템 사용현황 그리고 응답속도를 데이터로 제시한다. 그리고 성능 테스트는 끝이다. 하지만 현장사용자의 IT 인프라 환경을 고려하지 않은 상태에서 제시한 데이터는 실험실 내에서의 테스트일 뿐이다. 그래서 반드시 현장 사용자의 IT 인프라 현황을 파악, 분석하여 다양한 조건의 테스트베드를 만들고 반드시 현장의 응답 속도를 측정한 후 튜닝을 실행하여 IT 인프라와 응답속도간 상관관계를 파악하여 오픈 후 응답속도에 대한 불편을 제거해야 한다.

넷째, 인터넷 시스템을 오픈하면서 현장 테스트를 실시하지 않는 경우이다. 물론 현장 테스트를 회사 내에서 실행하는 경우도 있지만 이는 요식행위이며 해당 인터넷 시스템을 사용하는 모든 고객의 장소를 분석하여 기능의 완전성, 응답속도의 적절성 등을 테스트해야 한다. 고객의 장소는 PC방, 고객의 집 PC 등이 있고 이 또한 오래된 PC방, 신장개업 PC방 그리고 여전히 윈도우 95/98 같은 운영체제를 사용하는 고객의 집 PC 등으로 세분화할 수 있다. 고객의 IT 인프라는 사용자의 특성에 따라 동일한 환경이 거의 없다. 그리고 인터넷에는 수많은 프로그램들이 쏟아져 나와 있어 해당 인터넷 시스템과 충돌이 나는 경우도 종종 발생한다.

이상과 같이 테스트는 그 종류가 많은 만큼 실행상의 허점이 곳곳에 널려 있다. 테스트 관리자는 전략 수립과 함께 실행계획 수립 시 예외조건을 빠트리지 않도록 주의를 기울이고 테스트는 결국 개발된 프로그램 전체를 대상으로 하기 때문에 테스트 범위는 이 시스템을 사용하는 모든 고객을 대상으로 한다고 생각하고 테스트 관리자는 예외가 없는 전수 테스트에 임해야 할 것이다.

개발 중심에서 테스트 중심으로

테스트가 시대를 만났다. 천대받던 시절을 이겨내고 테스트는 품질을 확인하고 검증하고 보증하는 중추적인 역할을 맡게 되었다. 이에 따라 많은 테스트 관련 툴들도 우후죽순처럼 시장에 쏟아져 나왔다. 이제 테스트는 프로젝트 라이프 사이클(PLC) 전 기간에 걸쳐 그 역할을 확대하고 있다. 테스트의 미래는 어떻게 될까? 가까운 미래를 예측해본다.

서기 2010년 7월, K은행 기간계 구축 프로젝트. 이 부장은 고객과의 요구사항 확정에 대한 협의가 끝나자 PL들에게 통합 프로젝트 관리 툴(이하 통관툴)에 요구사항을 직접 입력하도록 지시했다. 요구사항들은 연속적으로 번호가 붙여지며 관리를 위한 베이스라인으로 확정되었다. 분석/설계자 최 과장은 이에 대한 세부 협의를 통해 설계 스펙을 통관툴에서 확정한다. 그와 동시에 개발자가 지정되었다. 개발자인 김 대리는 통보된 스펙 대로 프로그램을 코딩하고 기능 테스트 시작 버튼을 누른다. 조회조건 입력을 요청한다. 테스트 데이터를 랜덤하게 선택하여 100개를 자동 입력한다.

통관툴은 만들어진 프로그램을 하나씩 하나씩 코드 레벨로 실행하며 에러와 권고 리포트를 생성한다. 코드에 대한 100% 커버리지로 테스트를 종료한다. 에러와 권고 리포트를 읽어보며 요청한 대로 코드를 수정한다. 재 테스트를 실시한다. 이젠 100% OK가 나왔다. 김 대리는 해당 프로그램을 통합 테스트로 이동하도록 선택한다. 통합 테스트 저장소(repository)는 테스트 관리자인 박 과장 관리 하에 통합 테스트가 가능한 시점을 알려준다. 박 과장은 1주일 전 통합 테스트 시나리오에 대한 고객과의 협의를 통해 미리 시나리오를 입력해 두었다. 박 과장은 통합 테스트 시작버튼을 누른다. 우선, 단일 기능은 완벽했다. 그리고 외부 인터페이스와의 테스트도 원활했다. 통합 테스트는 입력된 테스트 케이스 대로 자동으로 수행된다. 이에 따라 에러가 발생한 경우 에러 리포트와 해결방안이 자동으로 표시된다.

통합 테스트가 완료된 프로그램은 부정 테스트와 회귀 테스트하도록 선택한다. 통관툴은 정해진 방식대로 부정테스트를 실행하고 단위 테스트에서 발생했던 에러를 기준으로 회귀 테스트를 실행한다. 완벽하다. 이제 남은 건 성능 테스트이다. 해당 소스를 빌드하여 성능 테스트계에 이관하고 성능 테스트 버튼을 누른다. 10 유저, 100 유저 계속 유저수가 올라가며 성능 테스트가 실행된다. 150 유저가 되었을 때 응답속도가 2초가 되었다. 초기 세워둔 기준대로 성능 테스트는 대만족이다.

다음 현장 테스트 버튼을 누른다. 소스가 현장 테스트베드 시스템으로 이관된다. 조건이 다양하다. PC방, 고객집, 지방 격오지까지 선택이 가능하다. 필요한 조건을 선택하고 현장 테스트 버튼을 누른다. 시스템은 테스트가 실행되면서 다양한 결과를 보여준다. 결과를 분석하고 PC방에서의 응답속도가 저조함을 선택하고 충돌이 발생하는 프로그램을 찾아본다. 특정 회사의 메신저가 해당 시스템과 충돌이 나서 응답속도가 저조해졌다는 결과이다. 개발자인 김 대리에게 충돌이 나는 부분에 대해 수정을 요청한다. 김 대리는 소스분석을 통해 충돌지점에 대한 로직을 수정하고 다시 현장 테스트를 요청한다. 재 테스트를 실시한다. 이번엔 OK이다.

정해진 오픈은 앞으로도 한 달이 남았다. 만일에 발생할 수 있는 오류를 찾기 위해 박 과장은 퇴근하면서 통합 테스트, 부정 테스트, 회귀 테스트, 성능 테스트, 현장 테스트 등 모든 테스트에 대한 버튼을 실행한다. 통관툴은 해당 명령에 대해 수준을 올려가며 테스트를 진행한다. 앞으로 남은 한 달 동안 통관툴을 통한 테스트는 계속될 것이다.

미래의 테스트는 프로젝트 시작과 함께 시작될 것이다. 요구사항에 대한 정의가 설계에 반영되어 코딩이 되면 이에 대한 다양한 테스트가 자동으로 실행되어 에러 리포트를 쏟아 낼 것이다. 물론 요구사항을 입력하고 시나리오를 입력하는 수기의 과정은 필요할 것이다. 이에 대한 자동화는 가까운 미래가 아닌, 조금 먼 미래쯤이면 가능할 지 모르겠다. 테스트의 중요성은 이처럼 나날이 증가하고 있다. 프로젝트 초기단계부터 테스트를 위한 준비를 하는 것이다. 다시 말해 개발 중심의 방법론이 아닌, 테스트 중심의 방법론으로 대체가 될 것이다. 많은 솔루션 업체와 SI 업체를 중심으로 테스트를 통한 품질확보를 위한 최적의 프로젝트 방법론과 도구들을 쏟아낼 것이라고 기대해본다.

제공 : DB포탈사이트 DBguide.net

출처명: 마이크로소프트웨어 [2005년 12월]

VPN 개요 및 기술 분석

시그엔 정보보안기술팀

VPN, 안전한 통신 환경의 대안

IT 시장의 전반적인 침체에도 불구하고 시장에서 호평을 받으며 활발히 도입되고 있는 솔루션을 꼽는다면 단연 VPN(Virtual Private Network, 가상사설망)이 그 선두에 있다. VPN 기술은 그 기본 개념이 소개된 이후로 뛰어난 비용절감 효과와 보안 신뢰성을 무기로 꾸준히 그 영역을 넓혀갔다. 특히, 국내 환경은 전세계적으로 가장 발달된 xDSL 인프라를 기반으로 브로드밴드(Broadband) VPN 솔루션이 활발하게 도입되고 있다. 이러한 시점에서 기업 환경 VPN 실전 구축 가이드라는 주제로 총 4회에 걸쳐 VPN의 기본 개념과 특징, 구현기술 등을 살펴보자. 또한 기업 환경에서 VPN을 구축할 때 필수적인 가이드라인과 VPN의 과거와 현재, 차세대 VPN 솔루션의 기술과 전망, 그리고 주요 분야에서의 적용 성공사례 등을 소개하고자 한다.

시그엔 정보보안기술팀(박광청 과장, 이규호 대리, 조은영 대리)

연재목차
1회(이번호) VPN 개요 및 기술 분석
2회(2004년 2월호) VPN 구성 사례
3회(2004년 3월호) VPN 실전 구축 가이드
4회(2004년 4월호) VPN 미래와 향후 전망

VPN 개요

전 세계적으로 인터넷과 네트워크 환경이 급성장하면서 각 기업체나 조직의 비즈니스 영역도 전통적인 오프라인에서 온라인 환경으로 급속히 변화했다. 이는 곧 수많은 전산 자원의 도입과 이들 간의 물리적, 논리적 연결이 필요하게 되었다. 이러한 환경 변화에서 본사와 지사 간의 연결 시 필연적으로 발생하는 비용 문제와 보안 문제를 동시에 해결하고 신뢰성 있는 통신을 위한 대안으로 VPN이 각광받고 있는 것이다.

VPN은 인터넷과 같은 공중망(Public Network)을 이용해 사설 전용망의 효과를 얻는 기술로서, 이를 구현하기 위한 하드웨어 및 소프트웨어의 집합체라 정의할 수 있다.

VPN은 현재 IT 기술 중에서 가장 주목받고 있는 기술 중 하나인데, 실제 그 개념과 역사는 짧지 않다. 그러나 과거에는 각 제조사별로 독자적인 VPN 기술을 선보였기 때문에 표준화가 진행되지 않았고, 무엇보다 VPN 기술의 안정성과 성능이 충분히 검증되지 않아 그리 활발하게 도입되지 않았다.

반면 최근에는 VPN 기술이 IPSec(IP Security) 프로토콜로 표준화되고, 많은 도입 기업에서 VPN의 보안성과 신뢰성이 검증됨에 따라 원격지 네트워크를 안전하고 비용 효율적으로 연결할 수 있는 솔루션으로 인정받기 시작했다. VPN이 현재 시장에서 각광받으며 폭넓게 도입되고 있는 주요 이유는 다음과 같다.

■ 비용 절감 : VPN은 낮은 비용으로 고비용의 전용선을 대체함으로써 비용 절감 효과가 탁월하다.
■ 신뢰성 있는 보안 통신 지원 : VPN은 표준화된 기술로서 개방적인 인터넷 하부 구조와 암호화 및 인증 프로토콜을 이용하여 전송되는 모든 데이터에 대해 신뢰성 있는 통신을 보장한다.
■ 다양한 환경에 유연한 적용 가능 : 기업의 비즈니스 영역이 확장됨에 따라 비즈니스 파트너나 고객과의 상호 접속 요구도 지속적으로 증대하고 있는데, 기업 네트워크가 인트라넷(Intranet), 엑스트라넷(Extranet)으로 확장되더라도 VPN은 유연한 적용이 가능하다. 이와 함께 점차 증가하는 재택 근무자나 파견 근무자는 물론 무선 단말기를 이용하는 모바일(Mobile) 접속 요구도 수용할 수 있다.
■ 타 보안 장비와 상호 운영성이 뛰어남 : VPN은 침입차단시스템(Firewall)이나 침입탐지시스템(Intrusion Detection System : IDS) 등의 타 보안 장비와 상호 운영성이 뛰어나며, 이들 솔루션과 통합되어 더 높은 수준의 보안체제를 구축할 수 있다.

VPN 분류

가) 접속 방식에 따른 분류

VPN은 접속 방식과 그 범위에 따라 인트라넷 VPN, 엑스트라넷 VPN, 그리고 원격 접속 VPN으로 분류할 수 있는데, 오늘날 실제 업무 환경에서는 각 방식이 혼재하고 있는 경우가 많다.

인트라넷 VPN : 인트라넷 VPN은 본사와 지사 간 네트워크 연결에 VPN을 적용한 것으로 원격지 접속(Site-to-Site) VPN 형태이다. 전사적으로 일관된 VPN 보안 정책 적용이 가능하다는 장점이 있다.

엑스트라넷 VPN : 엑스트라넷 VPN은 본사와 사업 파트너 혹은 고객 간의 네트워크 연결에 VPN을 적용한 것으로, 비즈니스 영역 확대나 기업 간 인수합병(M&A) 등으로 인해 최근 많이 도입되고있는 구성 방식이다. 엑스트라넷 VPN은 서로 다른 조직 간의 신뢰를 기반으로 하므로 보안 정책이나 설정상 오류로 인한 위협 등에 주의가 필요하다. 특히, 이기종 장비들 간에 VPN을 구성하는 경우가 많으므로, 실제 도입에 앞서 장비 간 호환성이나 정책 설정, 운영상 이슈 사항에 대한 검증 등 다소 복잡한 절차가 따른다.

원격 접속 VPN : 원격 접속 VPN은 본사와 원격지의 허가 받은 사용자 간의 네트워크 연결에 VPN을 적용한 것이다. 사용자들은 VPN 클라이언트 소프트웨어와 다이얼-업(Dial-up) 혹은 xDSL 접속을 이용해 안전하게 본사 네트워크에 접속한다.

최근에는 이러한 원격 접속 VPN의 번거로움을 대체할 수 있는 솔루션으로 SSL (Secure Socket Layer) 기술을 응용한 SSL VPN이 주목받고 있는데, 이에 대해서는 차후 연재에서 상세히 살펴보기로 하겠다.

나) 적용 방식에 따른 분류

VPN 적용 방식에 따른 분류는 이미 도입된 장비에 추가로 VPN 기능을 구현하는 방식과 전용 장비를 이용하는 방식, 그리고 별도의 관리 서비스(Managed Service)를 이용하는 방법 등이 있다.

침입차단시스템 기반 VPN 적용 : 기존에 도입된 침입차단시스템에 소프트웨어나 하드웨어적인 방법으로 암호화 모듈을 추가하여 VPN을 구현할 수 있다. 이 경우 별도의 장비 도입 없이 VPN 구성이 가능하므로, 관리 일원화와 비용 절감의 장점이 있다. 하지만 동일 기종 시스템에서만 구현이 가능하고, VPN 프로세스의 암호화/복호화 처리에 따른 부하로 인해 침입차단시스템 기능 자체가 영향을 받을 수 있으므로 트래픽 부하가 많은 곳에서는 권장하지 않는 방법이다. 대표적인 예가 체크포인트 방화벽에 암호화 모듈을 추가하여 VPN을 구성하는 것으로 현재 출시되는 대부분의 침입차단시스템은 이러한 방식을 지원한다.

라우터 기반 VPN 적용 : 라우터에 암호화 처리를 할 수 있는 소프트웨어나 하드웨어 모듈을 추가하여 VPN을 구성할 수도 있다. 이 경우에도 별도의 장비 구매 없이 VPN 구성이 가능한 장점이 있으나, VPN 프로세스로 인해 라우팅 기능 자체가 성능 저하될 수 있다는 점이 단점이다. 대표적으로 시스코 라우터의 IOS 기반에서 소프트웨어적으로 VPN을 구현하거나, 별도의 하드웨어 암호화 모듈(VPN Encryption Card)을 추가하여 VPN을 구현하는 것이다. 현재 출시되는 대부분의 시스코 라우터는 이러한 기능을 지원한다.

VPN 전용 장비 : 현재 가장 일반화된 방법으로 높은 VPN 성능과 안정성을 보장할 수 있다. 특히, 다중 터널링(Multi-Tunneling)이나 클러스터링(Clustering)을 이용한 고가용성(High Availability : HA) 구성 및 회선 이중화와 같은 다양한 고급 기법 구현이 가능하다. 대표적인 예로 노키아의 IP 시리즈, 노텔의 익스트라넷 스위치, 시스코의 콘센트레이터 시리즈 등이 있으며, 국내 제품으로는 퓨쳐시스템의 시큐웨이슈트, 어울림정보기술의 시큐어웍스 시리즈, 그리고 시그엔의 아이섹 게이트웨이 시리즈 등이 있다.

매니지드 VPN 서비스 : 이 방식은 최근에 많이 도입되고 있는 방식으로, 주로 회선망을 보유하고 있는 ISP에서 기존 회선망이나 별도 장비를 활용하여 VPN 서비스를 제공하는 것이다. KT의 엔텀 VPN과 데이콤의 MVP 서비스가 여기에 속한다. 네트워크 차원에서 VPN 서비스를 제공하므로 고객 입장에서는 별도의 장비 도입 비용이나 유지보수 및 관리 비용이 절약된다는 것이 장점이다. 하지만 서비스 이용 금액이 다소 높은 편이며, 고객 고유의 요구 사항을 원활하게 반영하지 못한다는 단점도 있다.

지금까지 몇 가지 VPN 적용 방식을 살펴보았는데, 과거에는 VPN 장비 자체가 고가였기 때문에 전용 장비 방식보다 침입차단시스템이나 라우터 기반 방식이 많이 고려되었다. 그러나 성능이나 안정성의 문제로 인해 널리 도입되지 않았다. 하지만 현재는 기술의 발전으로 인한 지속적 가격하락으로 대부분 VPN 전용 장비를 이용하여 구성하는 것이 일반적인 추세이다.

VPN 보안 기술

VPN의 기본 개념은 터널링(Tunneling)으로, 시작 지점에서 목표 지점까지 가상 터널을 생성하고, 생성된 터널을 안전하게 관리하는 암호화/인증 프로토콜 및 키 관리 프로토콜이 VPN의 핵심 기술이라고 할 수 있다.

터널링 기술

VPN에서 터널링은 외부로부터 어떠한 영향도 받지 않고 안전하게 정보를 전송할 수 있는 가상의 연결로서, 사전에 약속된 특별한 프로토콜로 세션을 구성, 타 사용자나 외부로부터 안전하게 보호받는 기술이다.

터널링은 캡슐화(Capsulation), 전송(Transmission), 그리고 디캡슐화(Decapsulation) 과정을 포함하며, 기본 개념은 그림 6과 같다.

VPN 프로토콜

VPN 프로토콜의 주요 역할은 패킷 캡슐화, 터널 생성 및 관리, 그리고 암호화 키 관리 등이 있는데, 이러한 대표적인 기술로 PPTP, L2F, L2TP, VTP, IPSec, SSL 등과 같은 다양한 프로토콜이 있다. VPN 터널링 프로토콜은 터널이 형성되고 운용되는 계층(Layer)에 따라 그림 7과 같이 구분되는데, 오늘날 대부분의 VPN 터널링 기술은 2계층과 3계층, 그리고 4계층에서 구현된다.

과거에는 대부분의 VPN 제조사들이 시장 지배력을 강화하기 위해 고유의 독자적인 터널링 기술을 사용함으로써 동일 벤더 제품 간에만 호환성을 갖는 폐쇄적 성격을 갖고 있었다. 하지만 현재는 IPSec이나 SSL 등과 같은 표준화된 터널링 기술을 수용하여 이기종 장비 간 VPN 구성도 가능하다.

2계층 터널링

OSI 참조 모델에서 데이터링크 계층인 2계층 터널링 기법은 가장 보편적인 형태로 대부분 IPSec 이전의 VPN 기술로 IP나 IPX 패킷을 PPP에 캡슐화한 후, 다시 터널링 프로토콜로 캡슐화하는 형태를 사용한다. 2계층 터널링 기법은 비용면에서 효율적이며, 다중 프로토콜 전송, 원격 네트워크 접속 기능을 제공한다. 그러나 자체적으로 신뢰성 있는 보안 수준을 제공하지 못하므로, 다른 계층의 프로토콜과 복합적으로 사용되는 특성이 있다. 대표적인 예로 PPTP, L2TP, 그리고 L2F와 같은 프로토콜이 있다.

① PPTP : PPTP(Point-to-Point Tunneling Protocol)는 마이크로소프트, 쓰리콤, 어센드 등으로 구성된 PPTP 포럼에서 제안한 프로토콜. 기존 다이얼업 접속에 사용되는 PPP 프로토콜을 그 모델로 하고 있으며, PPP 프레임을 IP 데이터그램으로 캡슐화하여 인터넷을 통해 전송하는 방식을 사용한다. PPTP는 터널 관리에 TCP 연결을 사용하며, 터널 데이터에 GRE(Generic Routing Encapsulation) 캡슐화 PPP 프레임을 사용하므로, TCP/IP 외에 NetBEUI와 같은 프로토콜도 지원한다. 또한 사설 LAN 네트워크에서도 사용이 가능하다. PPTP는 주로 원격접속 VPN에 적합한 방식으로 기존의 RAS(Remote Access Service) 접속에 비해 효율적이다. 마이크로소프트 윈도 NT4나 주요 서버 제품군에 탑재되었으나, 최근에는 IPSec VPN으로 인해 많이 사용되지 않는 추세이다. PPTP는 프로토콜 번호 47번과 TCP 1723 포트를 사용한다.

② L2F : L2F(Layer 2 Forwarding)는 시스코에서 독자적으로 제안한 기술로 IP나 ATM, 프레임릴레이 네트워크를 사용한다. 액세스 서버가 접속 트래픽을 PPP로 프레임화하고 WAN 접속을 통해 L2F 서버나 라우터로 전송하는 방식으로 동작한다. L2F는 PPTP나 L2TP와는 달리 사용자가 별도의 소프트웨어를 필요로 하지 않으나, 데이터 암호화 기능이 미약하고, 상호 호환성이 떨어진다는 단점이 있다.

③ L2TP : L2TP(Layer 2 Tunneling Protocol)는 PPTP와 L2F의 장점만을 결합한 기술로 PPP를 기반으로 하고 있으며, IETF에서 산업표준(RFC 2661)으로 정의한 프로토콜이다. L2TP는 주로 IP, IPX, NetBEUI 트래픽을 암호화하고 IP 헤더로 캡슐화하여 인터넷이나 X.25, 프레임릴레이나 ATM 네트워크를 통해 전송한다. IP를 데이터그램 전송에 사용할 경우 인터넷에서 터널링 프로토콜로도 사용할 수 있다. 현재 RAS와 라우터를 비롯한 대부분의 NAS(Network Access Server) 장비는 기본적으로 L2TP 기능을 지원하며 프레임릴레이 네트워크에서도 사용이 가능하다.

3계층 터널링

네트워크 계층인 3계층 터널링 기법은 데이터링크 계층이나 애플리케이션 계층과는 독립적으로 동작하며 안전하고 신뢰성 있는 방법을 제공한다. 대표적인 프로토콜로 VTP(Virtual Tunneling Protocol)와 IPSec(IP Security)이 있다. 특히, IPSec은 보안에 취약한 IP 프로토콜에서 안정성 있는 서비스를 제공하기 위해 IETF 워킹그룹에서 표준(RFC2401-2412)으로 제정한 보안 프로토콜로 현재 VPN의 핵심 프로토콜이라 할 수 있다. IPSec에 대한 자세한 내용은 뒷부분에서 살펴보도록 하겠다.

그 외 상위 계층

앞서 살펴보았던 VPN 기술들은 2계층 혹은 3계층에서 동작하는데, 몇몇 기술들은 그 상위 계층에서 동작하거나 애플리케이션과 결합되어 암호화 통신을 지원하기도 한다. 대표적인 예로 웹 환경에서 데이터 암호화를 구현하는 SSL(Secure Socket Layer) 프로토콜과 세션 계층에서 동작하는 SOCKv5, 그리고 애플리케이션 계층에서 동작하는 PEM(Privacy Enhanced Mail) 등이 있다.

IPSec

IPSec은 IETF 워킹그룹에 의해 제안되고 표준화(RFC2401-2412)된 보안 프로토콜로 스푸핑이나 스니핑 공격에 취약한 IP 프로토콜의 보안상 문제점을 해결하고 네트워크 계층에서의 보안성을 보장하기 위한 목적으로 개발됐다. IPSec은 네트워크 계층에서 암호화를 수행하기 때문에 원격지 VPN 구성뿐 아니라 원격 접속 VPN까지 완벽히 지원하며, 타 VPN 프로토콜과는 달리 애플리케이션과 독립적으로 구현이 가능한 장점을 갖고 있다.

IPSec은 암호화 부분을 처리하기 위한 ESP 헤더와 인증 부분을 처리하기 위한 AH 헤더, 그리고 암호화 키를 관리하기 위한 키 관리 부분으로 구성되어 있다. IPSec은 TCP/IP 스택보다 낮은 계층으로, 이 계층은 각 컴퓨터의 보안 정책과 송·수신자가 협상한 보안 결합에 의해 제어된다. 또한 보안 정책은 필터와 보안 규칙들로 정의된다.

① ESP : ESP(Encapsulation Security Payload)는 IP 페이로드(Payload) 데이터의 도청을 방지하고 데이터 기밀성을 보장하기 위해 VPN 터널 종단간에 협상된 키와 암호화 알고리즘으로 데이터 암호화와 인증 및 무결성 서비스를 제공하는 역할을 한다.

② AH : AH(Authentication Header)는 IP 헤더와 전송 헤더 사이에 위치하는 인증 헤더로서, 인증과 무결성을 검증하는 역할을 한다. 내부에 포함된 인증 데이터와 일련번호를 기반으로 송신자 확인과 메시지가 전송 중 변조·훼손되지 않았음을 검증하고 재실행 공격을 방지하는데 사용된다.

③ IKE : IKE(Internet Key Exchange)는 IETF 워킹그룹에서 ISAKMP (Internet Security Association & Key Management Protocol)를 기반으로 Oakley 키 알고리즘을 결합하여 SA의 협상과 키 교환 메커니즘을 제공하기 위해 제안한 표준 프로토콜(RFC2409)이다. 현재 대부분의 VPN 장비와 벤더에서는 IKE를 기본 키 교환 프로토콜로 채택하고 있다. 터널링을 구현하려는 두 시스템은 IKE에 의해 인증 및 데이터 보안 방법을 협상하고, 상호 인증을 수행한 데이터 암호화에 사용할 공유키(Session Key)를 생성하게 된다.

④ DOI : 터널링을 구현하려는 두 시스템은 IKE에 의해 정의된 암호화 프로토콜이나 인증 프로토콜과 같은 다양한 값들을 교환하는데, DOI(Domain of Interpre tation)는 IKE가 프로토콜로부터 정의된 값을 어떻게 해석할 것인지에 대한 내용을 담고 있다.

다양한 VPN 적용 기법

지금까지 살펴본 다양한 터널링 기법을 응용한 IP 기반 VPN 기술들은 주로 인터넷 같은 공용 네트워크 인프라를 기반으로 터널링을 구현하고자 하는 종단간에 VPN 장비를 설치하여 구성하는 것이 일반적이다.

IP VPN 기술들은 비교적 저렴한 비용으로 높은 보안성을 얻을 수 있으며, 도입이나 변경이 용이하다는 장점이 있다. 하지만, 기본적으로 트래픽 관리 기능이 미약해 일정 성능을 보장하거나 QoS (Quality of Service)를 구현하기가 쉽지 않으며, 인터넷을 인프라로 구성하므로 시간 지연에 민감한 음성 데이터나 VoD 같은 동영상 데이터 서비스에는 적당하지 않다는 단점이 있다.

따라서, 이러한 정보들의 신뢰성 있는 전송을 위해서는 IP VPN 방식보다 신뢰성 있는 새로운 기법들이 필요하며, 이러한 새로운 기술들을 적용하면 기존의 인터넷 기반 VPN 기술의 단점을 극복할 수 있다. 현재, 이러한 새로운 기술로는 주로 ISP나 대규모 회선망을 보유하고 있는 사업자들이 제공하는 ATM 기반 VPN과 최근에 주목받고 있는 MPLS VPN이 있다.

ATM 기반 VPN

ATM(Asynchronous Transfer Mode : 비동기 전송방식)은 LAN 백본이 FDDI를 거쳐 고속 이더넷으로 이전하는 과정에서 새롭게 등장한 기술로서 데이터를 고정 길이(53byte)의 셀(Cell) 단위로 구분하여 전송하는 전용 접속(Dedicated) 방식 스위칭 기술이다.

셀은 ATM상에서 만들어지는 53바이트(48byte Data+5byte Header)의 작은 크기로 기존의 이더넷(1500byte)이나 FDDI(4500byte)에 비해 전송에 유리하며, 각 데이터를 정해진 대역폭을 통해 전송하므로 네트워크 레벨에서 QoS를 보장할 수 있는 장점이 있다.

ATM 기반 VPN 기술은 이러한 ATM 인프라와 가상 회선(Virtual Circuit : VC) 기능을 사용하여 VPN을 구성하는 기법을 말하며, 전용 회선처럼 완전 메시(Full-mesh) 형태로 종단간 가상 채널 및 가상 경로를 설정한다.

ATM 기반 VPN 기술은 ATM의 망관리기능 및 보안성을 유지하면서 ATM 셀뿐 아니라, IP 패킷 및 Non-IP 패킷을 모두 전송할 수 있으므로 음성 및 데이터망의 통합 관점에서도 강력한 기능을 제공할 수 있다. 또한, ATM 환경에서 기본적으로 제공하는 QoS 기능을 이용하여 멀티미디어 서비스와 같은 실시간 데이터를 수용할 수 있으므로 ISP 입장에서는 다른 방식에 비해 특화된 서비스를 제공할 수 있다는 장점이다. 그러나, ATM 장비 자체가 고가이며, 각 기업체 단말기와의 접속을 위한 PVC(Perma nent Virtual Circuit) 서비스 비용이 상대적으로 비싸다는 단점이 있다.

MPLS VPN

MPLS(Multi Protocol Label Switch ing)는 IETF와 ATM 포럼을 중심으로 개발된 2계층 스위칭 기법과 3계층 라우팅 기술을 접목한 새로운 스위칭 기법으로 고정된 길이(4byte)의 레이블(Label)을 이용하여 고속 라우팅을 구현한다. 네트워크 송수신 패킷에 레이블을 부여하고 스위칭 장비에서 이 레이블을 읽어 패킷의 전송 경로를 결정함으로써, 패킷 지연 시간을 대폭 감소할 수 있다. 이외에 자체적으로 트래픽 관리 기법이나 VPN, 그리고 QoS 기능 지원이 뛰어나다는 것이 특징이다.

MPLS VPN은 MPLS 기술을 IP VPN에 적용한 기술로서 라우터와 네트워크를 기반으로 VPN 서비스 제공이 가능하다. MPLS가 제공하는 트래픽 관리 기술을 기반으로 기존 IP VPN의 취약점인 서비스 품질과 안정성 문제를 극복할 수 있어 ISP에게는 새로운 부가 서비스로 주목받고 있다. 현재 MPLS 기술은 IETF가 주도하고 있으며, 이더넷을 중심으로 ATM 네트워크를 수용하는 방향으로 발전하고 있는데, 인터넷의 문제점인 대역폭 증가, 라우팅 증가, QoS 문제를 해결할 수 있는 현실적인 대안으로 인식되고 있다. 특히, MPLS 기반 VPN 서비스는 고정된 길이의 레이블을 이용하여 데이터를 전송하므로 ATM 셀과 IP 패킷 모두 수용 가능하며, 따라서 기존 ATM 기반 VPN에서의 IP와 ATM의 복잡한 주소 변환 체계가 필요 없다는 장점을 지니고 있다.

MPLS VPN은 기존의 IP VPN 방식이나 IP over ATM 방식에 비해 많은 장점을 가지고 있으므로, 향후에는 MPLS 네트워크가 점차 이들 기술을 흡수하거나 대체해 나갈 것이라는 전망이 우세하다.

브로드밴드 VPN

최근 국내외적으로 VPN의 비용 효율성과 안정성이 검증됨에 따라 활발한 도입이 이루어지고 있다. 특히 국내의 VPN 환경은 전 세계적으로 유래가 없을 정도로 발달한 xDSL 인프라를 기반으로 xDSL/케이블 인프라를 이용한 브로드밴드 VPN이 주를 이루고 있다.

브로드밴드(Broadband) VPN은 접속 방식으로 기존의 전용선 대신 xDSL, 케이블, 위성 통신 등과 같은 다양한 초고속 인터넷 접속 기술을 이용하여 VPN을 구성하는 방식으로, 제한된 속도 내에서 회선의 안정성을 보장하는 전용선 VPN과 비교되는 개념이다.

xDSL이나 케이블 환경은 전용선과 비교했을 때 월등한 가격 대비 성능을 보여주지만 회선 자체의 안정성과 신뢰성은 전용선에 비해 불안하므로, 실제 기업 환경에 도입 시 전용선보다 회선 장애가 많이 발생하는 것이 사실이다. 따라서, 안정적인 브로드밴드 VPN 환경 구축을 위해서는 이러한 회선 불안정성을 극복할 수 있는 특화된 기술이 필요하다. 현재 국내 환경에서 주로 사용되고 있는 기술들과 안정적인 브로드밴드 VPN 환경을 구축하기 위한 절차 및 초고속 인터넷 회선 도입 시 유의 사항, 그리고 분야별 성공 사례 등은 다음 호에서 자세히 살펴보도록 하겠다.

VPN 확장성 및 향후 전망

앞서 살펴본 바와 같이 초기의 VPN은 주로 원격 접속 VPN 형태로, 몇몇 제조사에서 제공하는 장비나 운영체계에서 제공하는 제한된 기능으로 운영되었다. 이후 VPN 프로토콜이 점차 IPSec으로 표준화되면서 원격지 VPN 형식으로 급속히 확장되기 시작했다. 그러나 대다수가 기존 전용선의 고비용 구조를 해결하기 위해 VPN을 도입하고 있으며, 기존 애플리케이션을 연장하여 운영하는 수준에 머무르고 있다. 이는 IP VPN 기술이 별도의 장비를 사용하지 않는 한 QoS와 같은 안정된 성능을 제공하지 못하기 때문이다. 따라서 현재까지도 IP VPN 인프라에서 시간에 민감하거나 VoIP 데이터나 일정한 대역폭을 필수적으로 요구하는 애플리케이션을 적용하기에는 한계가 있다. 이러한 부분들은 차세대 VPN 기술이 해결해야 할 과제이다.

그러나, 향후 IPv6가 일반화되고 IP상에서 트래픽 제어 기술이 발전하게 되면 VoVPN(VoIP over VPN)이나 VPN 기반에서 멀티미디어 서비스 운영이 가능해질 것으로 보이며, 이미 몇몇 VPN 장비들이 부분적으로 이러한 기능들을 제공하고 있다.

IPSec은 현재 IPv4 체계에서는 옵션으로 제공되나 IPv6에서는 기본적으로 제공되고 있다. 기술의 발전으로 하드웨어 성능이 향상되면서 향후에는 스위치나 라우터 같은 네트워크 장비에서 기본적으로 수용할 가능성이 크다. 특히, IPSec VPN과는 별도로 MPLS VPN이나 VPN 운영, 관리 비용을 절감할 수 있는 매니지드 VPN 서비스, 그리고 원격 접속 환경에 적합한 SSL VPN 기술 등 다양한 VPN 기술들도 나름대로의 영역을 만들면서 독자적으로 발전할 것으로 예상된다. 또한, 무선 모바일 환경이 일반화됨에 따라 유선뿐만 아니라 무선 네트워크상에서의 데이터 보안을 위한 WVPN(Wireless VPN) 기술과 효율적인 키 분배와 관리를 위한 PKI와의 연동 기술도 꾸준히 관심의 대상이 되고 있다.

이번 호에서는 VPN의 개요와 주요 기술, 그리고 다양한 VPN 구성 기법들을 간략히 살펴보았다. 다음 호에서는 각 분야별 VPN 구성 사례와 주요 적용 성공 사례에 대해 소개하겠다.

제공 : DB포탈사이트 DBguide.net

RTTI(Run-Time Type Info.) 라는 주제 또는 C++ 표준 클래스인 type_info 클래스 또는 MFC의 CRuntimeClass를 보시면 원하시는 답변을 얻으실 수 있습니다.

런타임 시 단순히 클래스의 형 정보 뿐아니라(RTTI & 런타임 객체 생성) 클래스의 상속관계, 멤버 변수, 멤버 함수 등등의 정보를 자세히 알아내기, 런타임 시 멤버 함수 접근 또는 멤버 함수 실행 등등을 가능하게 해주는 프로그래밍 기법을 리플렉션 패턴(Reflection Pattern) 이라고 합니다.
(정확히는 리플렉션 패턴으로 구현하는 기능 중 일부라고 해야합니다만)

Java나 .NET 에서는 C++ 보다 더 진화된 형태의 리플렉션 패턴을 언어레벨에서 구현하고 지원해줍니다. 따라서 몇몇 C++ 개발자들이 매우 단순한, 리플렉션 패턴에서 가장 기초적인, RTTI 형태만 지원해주는 C++ 의 한계를 극복하고자 조금 더 진본된 리플렉션 패턴을 제공해주는 라이브러리를 개발하였고 일부는 프리웨어로 공개되어 있습니다. QT (상용), VCF (소스포지), LibReflection (코드프로젝트) 등등이 있습니다. C++언어 레벨에서 지원하는게 아니라서 특수한 상속관계나 매크로를 통해서 리플렉션 패턴을 지원하기때문에 사용이 조금 번거롭기는 하지만 C++ 언어에서 지원하는 단순 RTTI 수준이 아닌 조금 더 진보한 리플렉션 패턴을 사용할 수 있게해줍니다.

CDMA2000 1X 서비스는 기존의 IS-95A, IS-95B 망에서 진화한 IS-95C망을 이용하여 기존 IS-95 A/B 망에서 지원하였던 속도인 14.4Kbps나 56Kbps 보다 훨씬 빠른 최고 144Kbps로 무선인터넷이 가능한 서비스이다.

따라서, CDMA 2000 1x서비스를 통해 기존의 음성 및 WAP 서비스품질의 향상은 물론 각종 멀티미디어

서비스(AOD, VOD 등)의 제공도 가능하게 된다.

USB 충전겸용 데이터 통신 케이블이 CDMA2000 1X의 속도를 지원한다는 것은 휴대폰을 가지고  144Kbps의 속도로 인터넷을 사용할 수 있다는 이야기다. 기존의 시리얼 케이블과 가장 두드러지는 차이점으로 ADSL보다는 느리지만 모뎀보다 2.5배의 속도로 언제 어디서나 인터넷을 사용할 수 있다는 것은 상당한 매력이 있다. 또한 앞으로나올 IMT-2000의 모든 속도를 지원하기 때문에 한번구입후  재구입에 따른 금전적인 부담이 없다.

* IS-95A, IS-95B 라는 것은 기지국 망의 명칭이다. IS-95B망의 경우 무선 데이터 통신속도를 64Kbps까지 낼 수 있으며 CDMA2000 1X의 망인 IS-95C의 경우 144Kbps의 최대속도를 갖는다. 따라서 CDMA2000 1X의 휴대폰이 있다고 해도 그지역에 IS-95C망이 설치되어 있지 않으면 지역망에 의존하여 IS-95B나 IS-95A로 접속이 된다.

 

<표> IS95A/95B/95C와 IMT-2000의 주요 사양 비교.
IS-95C는 IMT-2000과 같이 다양한 기능을 제공하면서 IS-95B에 비해 높은 데이터 송수신을 보장한다

  1. 웹 표준(XHTML/CSS)

  2. 브라우저 지원(Firefox.Safari)

  3. 유니코드(UTF-8)

  4. 논리 주소체계(Logical URL)

  5. 컨텐츠 신디케이션(RSS/Atom,RDF)

  6. 오픈API (REST,SOAP,Web Service)

  7. 집단지성 (Folksonomy, Tag)

  8. 가벼운 서비스 프레임웍(Python, Ruby on Rails)

  9. 풍부한 사용자 경험(Ajax, Flex)

  10. 확장기능(Firefox Extentions, Widget)

         [출 처: 윤석찬 @Web2.0 Conference, 2006.3]

SOAP과 RDF

원격 프로시져 호출을 넘어서..

난이도 : 초급

Uche Ogbuji, 컨설턴트, Fourthought, Inc

2002 년 2 월 01 일

이 글을 통해 RDF 모델에서 정보를 교환하는데 SOAP이 사용될 수 있는 방법들이 검토된다. RDF 모델의 기본적인 데이터를 PC 교환이나 RDF/XML 직렬화 형식에서 모델의 부분들을 직접 전달하는데 필요한 SOAP 인코딩으로 변환하는방법을 연구한다.

SOAP은 저수준 인터넷 프로토콜을 통해 XML payload를 전송하는데 쓰이는 전송 프로토콜이다. 1.2 이전의 전송 스팩은 프로그래밍 언어 구조체의 직렬화로 연동된 XML의 기본 인코딩에 빌트인되었다. 그와같은 인코딩은 원격 프로시져 호출(RPC) 시스템의 요소이다. RPC 인코딩의 다른 예제는 "구(classic) RPC의 External Data Representation (XDR)이고 CORBA의 Common Data Representation (CDR)이 있다. 이와 같이 유사한 것들로 인코딩을 번들한 결과 SOAP은 명확히 애플리케이션 프로그래밍 느낌을 띠게되고 일반적인 데이터 교환의 유용성은 의심스러워졌다.

초기의 "SOAP의 향기"는 많은 논란을 일으켰다. 우선, 혼합 전송과 데이터 인코딩은 통신에 있어서 매우 어지러운 접근방식이다. 수십년동안 네트워킹 관례로 되어있는 레이어드 프로토콜을 무시한 것이다. 결국, HTML 마크업 스팩은 HTTP 스팩으로 삽입되지 않는다. 두 번째, 탁월성을 위해 RPC 비슷한 인코딩을 선택한다면 SOAP을 이상한 지점에 놓는 것이다; 이것은 이전 XML RPC 메커니즘 보다 좀 더 강력한 힘을 가지고 있지만 실제로는 덜 효과적이다. XML의 수다스러움과 HTTP, SMTP 등과 같은 좀 더 일반적인 아키텍쳐 때문이다. 차세대 RPC 로서 SOAP의 유일한 장점은 Microsoft와 CORBA 진영을 통합했다는 것이다; 이는 중요하지만 SOAP이 반드시 약속해야할 부분은 아니다.

RPC로서의 SOAP의 한가지 중요한 결과는 그와 같은 시스템이 일반적으로 차세대 EDI 의 야망을 가진 웹 서비스에게는 완벽히 맞지 않는다는 점이다. 만일 웹 서비스가 네트워크를 통한 새로운 방식의 비지니스가 된다면 프로그래밍 언어 API의 레벨이 아닌 비지니스와 합법적 요청의 레벨에서 통신하는 전송 메커니즘을 필요로 한다. 그리고 국제적 전자 비지니스 통신을 위한 시스템을 만드는데 XML을 사용하는 것이 목적인 ebXML 이니셔티브는 몇몇의 다른 영향력있는 곳과 마찬가지로 SOAP 사용을 주저하게 한다.

그 이후로 상황은 많이 안정되었다. SOAP 1.2은 특별한 인코딩 의존성을 다소 탈피했고, 대부분의 프로들은 ebXML을 포함하여 SOAP을 사용하고 있다. 대부분의 SOAP 구현은 여전히 특별한 SOAP 인코딩을 독점적으로 사용하고 있지만 점점 개방될 것이다. 광범위한 인코딩 선택을 위해 플러그인 아키텍쳐를 이용하여 좀더 다양한 통신 문제를 다루게 될 것이다. 그중 하나의 문제는 메테데이터를 교환하는 것이다.

Resource Description Framework (RDF)은 그와 같은 메타데이터 교환을 해결하는 몇 가지 도구를 갖춘 모델링 시스템이다. 이 글에서는 그와 같은 메타데이터의 인코딩을 위해 어떻게 RDF가 SOAP과 함께 사용될 수 있는지를 검토한다. 또한 RDF에 인코딩된 데이터 인스턴스가 어떻게 직접적으로 SOAP 인코딩으로 변환하지 않고 직접 전송될 수 있는지도 검토한다. SOAP과 RDF에 익숙해져야 한다. (참고자료). IBM developerWorks XML 존의 Thinking XML 칼럼을 참조하기 바란다.

RDF라는 멋진 배

RDF를 갖추고 있을 경우 한 시스템에서 또 다른 SOAP으로 옮기기 위해 할 수 있는 일을 설명하겠다. Thinking XML 칼럼에서 소개한 지속적인 이슈 추적 프로젝트에서 예제를 들어 설명하겠다. 한 시스템에 추가된 이슈의 상세한 부분을 하나의 원격 머신으로 교환하기 원한다고 해보자. 이것은 분산화된 이슈 트래커의 기초가 될 수도 있다. RDF 직렬화에서 이슈가 어떻게 보이는지의 예제는 Listing 1에 나와있다.

Listing 1: RDF/XML serialization

 <?xml version="1.0"?> <rdf:RDF xmlns:it="http://rdfinference.org/schemata/issue-tracker/"

  xmlns:dc="http://purl.org/dc/elements/1.1#" 

 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 

 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" 

 xml:base="http://rdfinference.org/versa/issues"> 

 <it:issue rdf:ID="0101"> <dc:relation rdf:resource="http://rdfinference.org/versa/0/2"/> 

 <dc:identifier>0101</dc:identifier> 

 <dc:creator rdf:resource="mailto:uche.ogbuji@fourthought.com"/> 

 <dc:date>2002-01-27</dc:date> <dc:title>Data type conversions</dc:title> 

 <dc:description>Not all the data type conversions listed make sense. 

 In particular the question of how to convert numeric types to resources and vice versa 

 require much thought.</dc:description> </it:issue> </rdf:RDF> 

이것은 웹 서비스에 대해 발생한 예제 이슈이다. 이슈 그 자체는 URI http://rdfinference.org/versa/issues#0101에 의해 구분된다. 이는 문서의 기본 URI를 받아서 이슈를 나타내는 유형화된 노드에서 rdf:ID 속성에 의해 주어진 것 처럼 조각을 추가하는 것이다. 문서 요소의 기본 URI는 xml:base 속성을 사용하여 http://rdfinference.org/versa/issues 처럼 주어진다. 그런다음 이슈 자체에 대한 여러 문장을 만들면서 Dublin Core의 dc:relation 메타데이터 태그를 사용하여 이슈가 참조할 리소스를 주는 것이 중요하다. 또한 친근한 디스플레이를위해 이슈의 전체 URI를 단축한 식별자, 이슈의 작성자, 제출 날자, 간단한 제목, 설명등을 제공한다.

가장 중요한 문제는 어떻게 이것이 추상적 RDF 모델로 변환되는 지가 중요하다. 예를 들어, 그림 1은 RDF 시각화 툴로 만들어졌다. Dan Brickley의 온라인 RDF visualizer를 사용하여 비슷한 그래프를 만들 수 있다.

그림 1: 샘플 RDF 모델의 그래프

이제 SOAP 메시지로 이 모델을 전송하는 두 가지 방법을 살펴보자; 우선 SOAP 인코딩으로 변환하고 그 다음 직접 RDF에서 인코딩 한다.

SOAP 인코딩 사용하기

우선, 전송에 필요한 메소드를 이해해야 한다. 여러분이 정의한 RDF는 데이터 묶음이고 메시지로 데이터 묶음을 전송하는 것이다. 이 데이터를 받은 사람이 무엇을 할것인지에 따라 이름을 정한다. 이 경우 원격 서버에 추적할 새로운 이슈가 있다는 것을 알린다. 그래서 newIssue 메소드를 호출했다. 이제부터 여러분은 SOAP 인코딩을 사용하고 있다는 것을 주목하고 메소드 이름을 RPC용 SOAP 바인딩을 가진 프로그래밍 언어에 적합하도록 맞추어야 한다.

그런다음 새로운 이슈 객체를 전송할 방법을 찾아야 한다. 새로운 객체의 ID와 속성을 전송하는 방법이 있다. 기본적으로 새로운 이슈 객체의 각 속성을 없애고 메시지 매개변수로 변환한다. SOAP 인코딩은 타입 정보로 가득 차있기 때문에 각 매개변수를 type (Listing 2 참조)으로 꾸며야 한다.

Listing 2: newIssue SOAP message

  http://www.w3.org/2001/12/soap-envelope">

 <env:Body> <itsoap:newIssue env:encodingStyle="http://www.w3.org/2001/12/soap-encoding" 

 xmlns:itsoap="http://rdfinference.org/schemata/issue-tracker/soap" 

 xmlns:it="http://rdfinference.org/schemata/issue-tracker/" 

 xmlns:dc="http://purl.org/dc/elements/1.1#" 

 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

 xmlns:xs="http://www.w3.org/2001/XMLSchema"> 

 <dc:identifier xsi:type="xs:nonNegativeInteger">0101</dc:identifier> 

 <dc:relation xsi:type="xs:anyURI">http://rdfinference.org/versa/0/2</dc:relation> 

 <dc:creator xsi:type="xs:anyURI">mailto:uche.ogbuji@fourthought.com</dc:creator> 

 <dc:date xsi:type="xs:date">2002-01-27</dc:date> 

 <dc:title xsi:type="xs:string">Data type conversions</dc:title> 

 <dc:description xsi:type="xs:string">Not all the data type conversions listed make sense.

 In particular the question of how to convert numeric types to resources and vice versa 

 require much thought.</dc:description> </itsoap:newIssue > </env:Body> </env:Envelope> 

모든 값들은 SOAP 인코딩 규칙이 요구하는 대로 엘리먼트의 내용에 위치된다. 여기에는 RDF의 리소스로서 마킹된 값들도 포함하고 있다. 그리고 anyURI데 이터 타입에 주어진다. 이것은 URI 레퍼런스인 값들 뿐만아니라 전체 URI도 허용한다는 것을 주목하자. 그와 같은 모든 메시지가 이 포맷을 갖고 있다면 메시지 엘리먼트에 대한 XML 스키마 정의를 내림으로서 매번 데이터 타입을 반복해야 하는 필요를 없앨 수 있다. Listings 3 과 Listing 4 는 그와 같은 schemata의 조각들이다.

Listing 3: newIssue SOAP message element용 schema fragment

 <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">

  <env:Body> <itsoap:newIssue env:encodingStyle="http://www.w3.org/2001/12/soap-encoding" 

 xmlns:itsoap="http://rdfinference.org/schemata/issue-tracker/soap" 

 xmlns:it="http://rdfinference.org/schemata/issue-tracker/" 

 xmlns:dc="http://purl.org/dc/elements/1.1#" > 

 <dc:identifier>0101</dc:identifier> 

 <dc:relation>http://rdfinference.org/versa/0/2</dc:relation> 

 <dc:creator>mailto:uche.ogbuji@fourthought.com</dc:creator> 

 <dc:date>2002-01-27</dc:date> <dc:title>Data type conversions</dc:title> 

 <dc:description>Not all the data type conversions listed make sense. 

 In particular the question of how to convert numeric types to resources and vice versa 

 require much thought.</dc:description> </itsoap:newIssue > </env:Body> </env:Envelope> 

Listing 4: newIssue SOAP message parameter elements용 schema fragment

 <!-- with target namespace = http://purl.org/dc/elements/1.1# --> 

 <xsd:element name="identifier" type="xsd:nonNegativeInteger"/> 

 <xsd:element name="relation" type="xsd:anyURI"/> 

 <xsd:element name="creator" type="xsd:anyURI"/> 

 <xsd:element name="date" type="xsd:string"/> 

 <xsd:element name="title" type="xsd:string"/> 

 <xsd:element name="description" type="xsd:string"/> 

이러한 것들은 SOAP 메시지를 Listing 5 처럼 단순하게 만든다.

Listing 5: 인라인 타입의 데코레이션이 없는 newIssue SOAP message

 <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">

  <env:Body> <itsoap:newIssue env:encodingStyle="http://www.w3.org/2001/12/soap-encoding" 

 xmlns:itsoap="http://rdfinference.org/schemata/issue-tracker/soap" 

 xmlns:it="http://rdfinference.org/schemata/issue-tracker/" 

 xmlns:dc="http://purl.org/dc/elements/1.1#" > 

 <dc:identifier>0101</dc:identifier> 

 <dc:relation>http://rdfinference.org/versa/0/2</dc:relation> 

 <dc:creator>mailto:uche.ogbuji@fourthought.com</dc:creator> 

 <dc:date>2002-01-27</dc:date> <dc:title>Data type conversions</dc:title> 

 <dc:description>Not all the data type conversions listed make sense. 

 In particular the question of how to convert numeric types to resources and vice versa 

 require much thought.</dc:description> </itsoap:newIssue > </env:Body> </env:Envelope> 

미가공(raw) RDF 보내기

이 글을 시작하면서 언급했지만 SOAP을 사용하기 위해서 SOAP 메시지를 RPC 형식으로 바꿀 필요는 없다. RPC 통합 필요성을 절감하는 것이 아니라면 데이터를 보내고 이를 원격 시스템에서 자유롭게 프로세스하는 접근 방식을 취할 수 있다. SOAP을 위한 공식적인 RDF 인코딩은 없지만 이 논의는 RDF와 SOAP의 규약과 규정에 근거한 것이다.

가장 단순한 접근 방식은 rdf:RDF 엘리먼트를 SOAP 바디의 하나의 상위 레벨 엘리먼트로 만드는 것이다. (Listing 6).

Listing 6: RDF와 같은 SOAP 메시지

 <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"> <env:Body> 

 <rdf:RDF env:encodingStyle="http://rdfinference.org/rdfws/soap-encoding" 

 xmlns:it="http://rdfinference.org/schemata/issue-tracker/" 

 xmlns:dc="http://purl.org/dc/elements/1.1#" 

 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 

 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" > 

 <it:issue rdf:about="http://rdfinference.org/versa/issues#0101"> 

 <dc:relation rdf:resource="http://rdfinference.org/versa/0/2"/> 

 <dc:identifier>0101</dc:identifier> 

 <dc:creator rdf:resource="mailto:uche.ogbuji@fourthought.com"/> 

 <dc:date>2002-01-27</dc:date> <dc:title>Data type conversions</dc:title> 

 <dc:description>Not all the data type conversions listed make sense. 

 In particular the question of how to convert numeric types to resources and vice versa 

 require much thought.</dc:description> </it:issue> </rdf:RDF> </env:Body> </env:Envelope> 

인코딩 ID가 사용되고, http://rdfinference.org/rdfws/soap-encoding 는 비표준이고 기본적으로 RDF/XML을 SOAP 메시지 바디로 직접 임베딩하는 것을 명령하고 있다. 메시지 형식과 단순한(plain) 형식 사이의 한 가지 주요한 차이점은 rdf:about 이 이슈 리소스를 구분하기 위해 사용된다는 점이다. SOAP 전송을 위해 RDF 모델을 직렬화하는 중요한 원칙이 있다: 인라인 선언을 피하는 것이다. xml:base을 사용하여 ID에 대한 기본 위치를 고정할 수 있다면 그와같은 원칙은 불필요하다. 하지만 인라인 전송 리소스의 생명주기와 소유권을 위한 어떤 분명한 의미를 상상하기는 힘들다. 어떤 상황에서도 피할 수 없다.

위로

결론

SOAP과 RDF가 상호작동할 수 있는 방법에 있어서 다른 접근방식들이 있다. 실제로 이것은 RDF 사용자들이 웹 서비스를 발견할 때 지속적으로 흥미를 가져가는 부분이다. 자세한 내용은 참고자료 부분을 참조하기 바란다. XML 기반 데이터를 직렬화하는 일반적인 시스템은 웹 서비스 세계를 더욱 풍요롭게 만들것이다.

■ 웹표준의 중요성

 - 윈도 비스타 출시를 앞두고 웹 표준과 어긋나는 데다 보안문제에 취약점을 갖고 있는 액티브X 방식을 무분별하게 적용해온 국내 웹 사이트 운영자와 이들 웹 사이트를 이용해온 인터넷 사용자들이 혼란

 - 공공기관과 민간기업 등이 운영하고 있는 국내 웹 사이트 대부분이 웹 표준을 준수하지 않은데서 기인

 - 웹 표준 준수와 이를 통한 웹 접근성 보장의 중요성이 꾸준히 지적돼 왔지만, 웹 사이트 개발자나 운영자 모두 이에 대해 별다른 신경을 쓰지 않은 부작용이 이번 사태로 이어졌다는 것이 전문가들의 지적

  - 대부분의 정부 공공기관, 금융기관 웹 사이트가 IE만 지원하고, 웹 표준을 지키는 다른 웹 브라우저를 제대로 지원하지 않음

 - 특정 OS와 브라우저에 종속된 기술로 개발되는 것은 정보 이용권을 제약

 - 향후 웹 기반 융합이 이뤄질 경우 모바일, 가전, 멀티미디어 기기의 임베디드 솔루션 등 산업 전반에 기술종속 우려가 제기

 - 공공기관 웹 사이트 평가지침에 웹 표준 준수 지표가 포함돼 있음에도 이처럼 잘 지켜지지 않는 것은 웹 사이트 운영 담당자나 용역 개발업체들이 표준 준수 필요성에 대한 인식이 부족하고, 표준기술 개발에 대한 정확한 방법론을 알지 못하기 때문

■ 웹표준화

  - 월드 와이드 웹 브라우저와 서버 기술의 표준화

 - W3C:하이퍼텍스트생성언어(HTML), 하이퍼텍스트전송규약(HTTP) 등의 표준화를 수행하고 있고 웹 접근성을 보장하기 위한 각종 표준을 제시

■ 웹 접근성

 - 누구든지 어떤 기술을 통하든지 쉽게 웹 사이트를 이용할 수 있도록 보장

 - 장애인과 노인 등 어떤 사용자도 일반인과 동등하게 인터넷 정보에 접근할 수 있도록 보장

 - 리눅스나 매킨토시 운영체제(OS) 사용자, 그리고 파이어폭스, 오페라 등 어떤 브라우저 사용자들에게도 인터넷 정보에 접근할 등등한 기회

■ 웹접근성 향샹방안

 - 웹 접근성에 대한 법과 제도를 의무화하고 인증마크 제도를 운영

 - 웹 접근성 지침을 모든 웹 사이트 운영자가 준수하도록 의무화

 - 인식제고는 물론, 관련 기술 연구, 법ㆍ제도 개선 등이 필요

오늘 전자신문 6면 한쪽 귀퉁이에 "텔레매틱스 활성화를 위해"라는 기사가 있읍니다.

전자 신문을 상세히 본다고 해도 놓치기 쉬운 장소에 위치해있죠.

신문사도 비즈니스를 하는 기업이기때문에 돈이 안되는 기사는 메인 타이틀을 절대로 크게

하지 않습니다. 즉 기업에서 받는 돈만큼 타이틀은 커질수 밖에 없읍니다.

그래서 예비 기술사들이 전자신문,디지털타임즈,디지털데일즈를 매일 1시간 이상보아도

볼만한 내용이 없다고 푸념합니다.

바로 신문의 이러한 속성을 이해하고 숨어잇는 내용을 빨리 찾는것이 전자신문을 속독하는

방법입니다

일단 내용을 보면 아래와 같습니다.

----------기사 -------------------------------------------------------------------

텔레매틱스 시장 활성화를 위해 물류, 택배, 자동차 보험 등 이종 산업과의 협력이 추진돼야 한다는 의견이 제시, 눈길을 끌고 있다.

지난 7일 텔레매틱스산업협회 주최로 제주 라마다 호텔에서 열린 ‘2006년 정기총회 및 춘계 워크숍’에서는 텔레매틱스 시장 활성화를 위한 다양한 방안이 제시됐다.

전문가들은 이종산업간 컨버전스가 빠르게 진행되고 있으며, 텔레매틱스 분야도 단순한 교통정보 제공에서 벗어나 물류, 택배 등 이종산업과의 협력에서 돌파구를 찾아야 한다고 주문했다.

백 원장 코리아텔레매틱스 사장은 “텔레매틱스 서비스 활성화를 위해선 현재 자동차 운전자에 제한된 시장을 이동통신 서비스 사용자로 확대해야 된다”며 “이를 위해 버스, 지하철 등 대중교통을 이용하는 시민들이 휴대폰에서 교통정보를 쉽게 이용할 수 있는 새로운 비즈니스 모델 개발이 필요하다”고 밝혔다

안병구 KTF 팀장은 “수익창출을 위해선 이종산업간 협력관계 구축이 절대적으로 필요하다”고 전제한 뒤 “보험, 차량정비 등 자동차 후방 산업분야에서의 사업모델 발굴이 또 다른 대안이 될 수 있다”고 제안했다.

배효수 텔레매틱스산업협회 국장은 “컨버전스 비즈니스로 관심 영역을 확대해 나갈 계획”이라며 “이를 위한 첫 사업으로 오는 5월 아랍에미리트에서 한국홈네트워크산업협회(HNA)와 공동으로 로드쇼에 참가할 것”이라고 밝혔다.

정통부도 텔레매틱스 2차 시범사업을 비롯해 u-IT839 과제인 텔레매틱스 산업 육성을 약속했다.

조경식 정통부 과장은 “텔레매틱스는 u사회안전망 사업 등 새롭게 추진하는 분야에서 활용할 수 있다”며 “투자를 지속적으로 늘려나갈 것”이라고 밝혔다.

한편 텔레매틱스 서비스가 도입된 지 5년이 흘렀지만, 현재 서비스 사용자는 50여 만명에 불과하다. 이는 지난 2003년 예측치 96만명에 절반 수준이다

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

보시는 것처럼 내용을 보면 별것 없읍니다.
대부분의 예비 기술사님들이 뻔한 내용이라고 한번 훑어보고 버리지요..

하지만 전 여기서 내용전체를 스크랩하지 않고 위에 밑줄 그은 것처럼 스크랩을 합니다

즉

=============텔레매틱스 시장 활성화 방안======

- 물류, 택배, 자동차 보험 등 이종 산업과의 협력이 추진

- 자동차 후방 산업분야에서의 새로운 비즈니스모델 발굴

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

남들은 버리는 내용에서 위의 두줄만 스크랩한겁니다.

그럼 이를 어디에 써먹는지 방법을 알려드리겠읍니다.

텔레매틱스가 10점이든 25점이든 시험에 나오면 활성화 방안은 반드시 기술해야합니다.

문제에서 이를 직접물어보면  III단락에 들어가지만

일반적으로 마지막 단락에 넣게됩니다.

이때 대부분 아래와 같이 목차를 잡죠.

예)

I. 텔레매틱스 활성화 방안

 가. 정부측면

 나. 기업측면

 다. 사용자 측면

혹은

 가. 정부측면

 나. 자동차 회사측면

 다. 이통사 측면

물론 이것말고도 여러 의견이 나올수 있읍니다.

전 위것으로 아래와 같이 잡습니다

I. 텔레매틱스 활성화 전략( 혹은 텔레매틱스 활성화를 위한 본인의 발전적 제언)

 가. 컨버전스 차원에서 활성화 방안

    - 물류, 택배, 자동차 보험 등 이종 산업과의 협력이 추진

 나. 텔레매틱스 정책 측면에서 활성화 방안

   - 자동차 후방 산업분야에서의 새로운 비즈니스모델 발굴

 다. 통합조직 신설을 통한 활성화 방안

   - 정부,자동차, 이통사 그리고 후방 산업분야가 참여한  한시적 통합 조직 신설

즉 "다"는 "가"와 "나"를 혼합하여  자신의 견해를 강하게 어필하는 것입니다.

결론적으로 남들은 버리는 기사내용을 위와같이 요긴하게 사용합니다