라이브러리
프로그래밍언어, 각종코드, 관련동향, 논문 등의 저장소
IT Library (284)
[기업 환경에 닷넷 적용하기] ⑤ 닷넷 개발에서 UML과 케이스 툴의 사용

[기업 환경에 닷넷 적용하기] ⑤ 닷넷 개발에서 UML과 케이스 툴의 사용

 

연재순서
1.
제대로 된 컴포넌트를 위한 프리젠테이션 레이어 설계하기
2.비즈니스 로직 레이어 설계와 물리적 구현을 위한 필요 사항
3.엔터프라이즈 솔루션 패턴 해부하기
4.닷넷의 웹 프리젠테이션 패턴
5.닷넷 개발에서 UML과 케이스 툴의 사용

 

얼마 전 필자는 한 통의 전화를 받았다. 통화 내용은 닷넷 환경에서 작성된 ASP. NET 웹 응용 프로그램이 클라이언트의 CLR 버전을 알 수 있느냐는 내용에 대한 질문이었다. 간단한 질문이라 Request 객체의 Brawser 속성 중 ClrVersion에 액세스하면 알 수 있다는 답변을 하고 전화를 끊었다. 전화를 끊고 나서 떠오른 의문은 ‘ASP.NET 웹 응용 프로그램에서 클라이언트의 CLR 버전을 알 필요가 있을까?’라는 것이었다. 윈폼으로 작성된 프로그램을 클라이언트로 다운받아 실행하는 것이 아니라면, ASP.NET 응용 프로그램이 동작하기 위해 CLR이 필요한 경우는 거의 없기 때문이다.

나중에 이어진 전화 통화에서, “ASP.NET 응용 프로그램이 동작하기 위해 클라이언트에 CLR이 필요한 경우는 거의 없다. 정말 없다고 봐도 무방하다”고 말했고, 전화를 받은 실무 담당자는 “우리 회사에는 윈도우 98이나 심지어 윈도우 95 운영체제가 설치된 여러 대의 컴퓨터가 동작하므로 안심할 수 없다”라고 했다. 필자는 아무런 문제가 없다고 했지만, 담당자는 “선생님께서는 책만 보고 공부하시니 실무에서 발생할 수 있는 여러 문제에 대한 이해가 부족하다. 실무에서 소프트웨어가 동작하다 보면 어떠한 문제가 발생할지 모른다”고 반박했다.

몇 년간 필드에서 근무하는 사람들을 만날 기회가 많았는데, 닷넷 환경에 대한 것이나 프로젝트 관련 이야기를 하다 보면 다음과 같은 이야기를 종종 듣게 된다.


“실무에서는 그렇게 못합니다.”
“그게 좋은 방법이긴 한데 실무에서는 그렇게 못하죠.”
“실무에서는…”
“실무에서는…”


이론적으로 부족하다보니 지기 싫어서 실무 핑계를 댄다고 생각할 수도 있지만, 어쩌다가 한 번씩은 무시당한다는 느낌이 들 때도 있다. 그럴 때 다음과 같이 반문한다.


“실무에서는 1+1이 3이 됩니까?”


정해진 아키텍처 기반으로 잘 정의되어 구성된 프레임워크, 이를 구성하는 디자인 패턴과 개발 방법론, 그리고 개발을 위한 케이스 툴 등 다 좋은 이야기라고 한다. 하지만 대부분 인력과 시간에 시달리는 실무 개발 환경에서 아직은 요원하다고 말한다. 하지만 훌륭한 이야기이고 좋은 말이며 그게 맞는지는 알고 있다면 왜 하지 않는가?

ASP.NET 응용 프로그램에서 코드 비하인드(Code-Behind) 파일의 코드가 5000라인을 넘어가는 재사용 불가능한 프로그램을 매번 작성하는 것보다는 바른 객체지향 기법으로 잘 설계된 프레임워크를 한 번 만들어놓고 그것을 사용하는 것이 장기적으로 볼 때 좋다. 아니 그렇지 않더라도 몇 번 정도의 프로젝트만 한다고 해도 훨씬 유리하다.

사용자 삽입 이미지
<화면 1> 비지오를 셋업하면 VS>NET 2003의 프로잭트 메뉴에 비지오 메뉴가 추가된다.


아키텍처 또는 프레임워크를 제대로 설계하기 위해서는 아무래도 코드를 직접 작성하면서 하는 것보다는 다이어그램으로 그려가면서 하는 것이 작업 효율도 높아지고 보기도 좋으며, 팀 단위 개발에 있어 많은 장점을 가져올 수 있다. 처음 비주얼 스튜디오 닷넷(이하 VS.NET)이 공개됐을 때 순공학과 역공학이 가능한 닷넷 기반에서의 케이스 도구는 비지오(Visio) 밖에 없었고 사실 너무 불편했다. 시간이 흐르면서 볼랜드 투게더, 래쇼날 로즈 등의 케이스 도구가 VS.NET에 플러그인 되었고, 비주얼 스튜디오 2005에서는 아예 케이스 도구가 기본 기능으로 추가되었다. 이제, 본격적으로 닷넷 환경에서 사용할 수 있는 케이스 도구들에 대해 알아보자.

비지오 2003
MS 비지오 2003은 닷넷 환경이 처음 공개됐을 때 코드 역공학과 순공학이 가능한 것만으로 여러 개발자들 사이에서 화제가 됐던 제품이다. 볼랜드 투게더 또는 래쇼날 로즈와 비교했을 때 그 기능이 단순하고 미비하기 짝이 없지만, MS는 장기적으로 닷넷 환경에서 사용되어야 하는 여러 다이어그램들을 구성하고 사용하기 위한 도구로 비지오를 선택했던 것 같다. 비즈토크 서버의 초기 버전들에서 오케스트레이션을 구성하기 위한 드로잉 도구도 비지오 인터페이스를 가지고 있었고, 여러 오피스 제품들에서 다이어그램을 작성하기 위한 도구도 비지오 인터페이스를 가지고 있었다.

볼랜드 투게더나 래쇼날 로즈 등의 도구는 코드의 변화 또는 다이어그램의 변화를 실시간으로 서로 적용시켜 주지만 비지오는 그렇지 않다. 비지오는 <화면 1>과 같이 작성된 역공학 작업에서 작성된 코드를 리버스 엔지니어링 하면 비지오 파일을 생성한다. 물론 실시간 동기화는 불가능하다.

사용자 삽입 이미지
<화면 2>비지오의 클래스 다이오그램 드로잉과 역공학 UML 관련 메뉴


비지오에서 작성된 다이어그램을 VS.NET로 순공학하는 것 역시 가능하다. 역공학에서와 마찬가지로 다이어그램과 소스코드 간의 실시간 동기화는 불가능하고, 작성된 다이어그램을 역공학하면 새 VS.NET 프로젝트를 생성하거나, 소스코드를 수동적으로 생성한다.

비지오는 이러한 역공학과 순공학 이외에도 표준 UML이 제공하는 거의 모든 다이어그램들을 제공하고 VS.NET과 병행 작업을 진행할 수 있게 한다. 또한 템플릿을 이용한 여러 다이어그램을 작성할 수 있도록 지원하는데, UML의 거의 모든 표준 다이어그램뿐만 아니라 데이터베이스 다이어그램(순공학과 역공학이 가능하다), 블럭 다이어그램 등을 작성할 수 있는 기능들을 제공한다.

비주얼 스튜디오 2005 팀 스위트
비주얼 스튜디오 2005가 베타 2를 통해 그 모습을 드러내고 있다. 6개월 전에 받았던 비주얼 스튜디오 위드비 팀 시스템(Visual Studio Whidbey Team System)이 비주얼 스튜디오 2005 팀 스위트 베타 2로 이름이 바뀌었는데 이전 버전의 VS.NET들과는 확연히 변했다. 비주얼 스튜디오 2005는 5년 전, ‘2001년에 개발 환경의 패러다임 시프트’라고 불리었던 VS.NET의 등장만큼이나 큰 변화를 가져올 듯하다. 여기서는 비주얼 스튜디오 2005에서 지원하는 케이스 도구들에 대해 한번 살펴보자.

사용자 삽입 이미지
<화면 3> 비주얼 스튜디오 2005의 클래스 다이어그램


반드시 필요한 도구만 제공한다
사실, 래쇼날 로즈나 볼랜드 투게더 같은 것을 케이스 도구라고 부를 수 있는데 이들 도구는 특정 개발 방법론(예를 들어 UP(Unified Process)와 같은)을 기반으로 한 요구사항 분석 등의 개념 설계 단계, 클래스 다이어그램 등의 논리 설계 단계를 자동화 도구로 분석하고 응용 프로그램에 적용할 수 있게 되어 있다. 하지만 단적으로 말하면 비주얼 스튜디오 2005 팀 스위트는 이러한 절차적인 설계 단계들을 지원하지 않는다. 비주얼 스튜디오 2005는 MS에 따르면 ‘꼭 필요한’ 도구들만을 제공한다.

필자도 많은 개발 프로젝트들을 수행하면서 문서화를 위해 여러 케이스 도구들을 사용했다. 케이스 도구들을 사용해 다양하게 그려진 여러 다이어그램들을 깔끔하게 문서화하려고 노력하고, 실제로 그렇게 했지만 프로젝트가 종료된 시점에서 보면 언제나 작성된 문서들과 실제 소프트웨어와의 차이는 있었다. 사용하는 여러 케이스 도구들이 다이어그램과 소스코드의 동기화를 지원하여 소스코드와 클래스 다이어그램이 다르다든지 하는 문제는 웬만해서는 발생하지 않았다.

하지만 유스케이스 다이어그램 또는 활동 다이어그램 등은 100% 분석된 요구사항으로 작업할 수 없는 환경에서 개발을 진행하다 보면 요구사항은 변하기 마련이다. 그리고 변한 요구사항을 소스코드에 먼저 적용한 다음 유스케이스에 반영하는 작업들을 반복하게 된다.

결국은 처음 작성할 때는 그렇게 자랑스럽고 훌륭해 보이던 다이어그램들이 프로젝트가 꽤 진행된 시점에서는 무용지물이 된다. 만약, 고집 센 PM이 있었다면 프로젝트의 진행을 조금 늦추는 한이 있더라도 작성된 문서와 코드를 일치시키는 작업을 따로 진행하겠지만 이는 소프트웨어 개발의 라이프 사이클을 지연하게 된다.

가슴에 손을 얹고 생각해보면, 필자 역시 유스케이스 다이어그램을 제대로 그리거나 메쏘드를 작성하기 위해 모든 메쏘드의 활동 다이어그램을 작성한 적은 없다. 적당히 프로젝트의 개요 정도만을 파악하기 위해 VS.NET이 아닌 다른 케이스 도구를 실행하여 다이어그램을 그리고(또는 연습장에 손으로 그려서 그려진 다이어그램을 여러 장 복사해두기도 했다) 그 다이어그램과 프로젝트를 동기화하는 것이 아닌 코드를 작성할 때 ‘참고’하는 정도로 진행한 프로젝트가 꽤 된다(정석은 아니겠지만 프로젝트의 빠른 진행에 꽤 도움은 됐다).

하지만 반드시 있어야 되는 것은 있는 법이다. 1+1은 항상 2이고, 꽁수를 쓰더라도 1+1의 결과로 나온 2를 기반으로 적당한 꽁수를 펼쳐야 제대로 된 소프트웨어가 만들어진다. 기업용 응용 프로그램을 작성하는 프로젝트라면 당연히 응용 프로그램의 아키텍처 정도는 작성해야 하고, 작성된 아키텍처는 활동 다이어그램이나 클래스 다이어그램처럼 프로젝트가 진행되면서 적당히 변경될 수 있는 성질의 것이 아니다. 응용 프로그램 아키텍처는 한 번 지정되면 반드시 그 아키텍처를 강제해야 소프트웨어의 재사용성과 가용성을 기대할 수 있게 된다. 하나의 컴포넌트라도 여러 계층에 걸쳐 작성된다면 전체 응용 프로그램을 재사용할 수 없게 되는 최악의 경우가 발생할 수 있다.

비주얼 스튜디오 2005는 이런 식으로 ‘반드시 필요한 도구만 제공하겠다’는 철학을 가지고 있는 듯하다. 즉 반드시 필요해서 작성했다면 작성된 다이어그램대로 소프트웨어의 개발이 진행되어야 한다는 것이다. 비주얼 스튜디오 2005는 새로운 여러 디자인 도구를 지원하는데, 새로운 디자인 도구는 클래스 디자이너(class designer)와 분산 시스템 디자이너(distributed system designers)로, 분산 시스템 디자이너는 긴밀하게 통합된 4개의 도구 그룹으로 구성된다.

사용자 삽입 이미지
<그림 1> 응용 프로그램 아키텍처


이들 4개의 도구는 응용 프로그램 연결 디자이너(application connection designer), 논리적 데이터센터 디자이너(logical datacenter designer), 시스템 디자이너(system designer), 배포 디자이너(deployment designers)로 구성되고, 이들 중 응용 프로그램 디자이너와 클래스 디자이너는 시스템과 구성 요소의 그래픽 디자인 지원과 코드 생성 지원 등 주요 특성을 공유한다. 모든 디자이너는 볼랜드 투게더와 래쇼날 로즈가 그러하듯이 양방향 동기화를 지원한다.

응용 프로그램 아키텍처의 정의
예를 들어, 지난 1회 연재에서 설명했듯이 응용 프로그램은 <그림 1>과 같은 구조를 가져야 한다고 하자. 그러면 응용 프로그램 작성을 위해 참여하는 모든 개발자들이 응용 프로그램의 구조를 따라 작성해야 한다(물론 이런 아키텍처를 지켜 나가려면 케이스 도구들보다 능력 있는 PM의 올바른 팀 구성이 우선된다).

아키텍처대로 응용 프로그램을 구성한다면, 프리젠테이션 계층을 구성하는 ASP.NET 웹 응용 프로그램, 비즈니스 컴포넌트를 구성하는 클래스 라이브러리 응용 프로그램, 데이터베이스 연결을 담당하는 응용 프로그램, 서비스 인터페이스를 구성하는 웹 서비스 응용 프로그램 등의 여러 응용 프로그램 솔루션이 구성되고, 이 솔루션 하나에 구성된 여러 응용 프로그램들은 연결을 가진다. 비주얼 스튜디오 2005는 닷넷 개발에 필요한 이런 응용 프로그램의 구성 연결들을 작성할 수 있는 다이어그램을 제공한다. 그 다이어그램이 바로 응용 프로그램 연결 디자이너 (application connection designer)이다.

사용자 삽입 이미지
<화면 4> 응용 프로그램 다이어그램 추가
사용자 삽입 이미지
<화면 5> 응용 프로그램 다아이어그램이 추가된 모습


비주얼 스튜디오 2005에서 솔루션을 하나 작성했다면, 가장 처음 만나게 되는 디자이너가 바로 이 응용 프로그램 연결 디자이너이다. 응용 프로그램 연결 디자이너는 솔루션을 오른쪽 클릭하고 「Add… New Item…」을 선택하여 구성할 수 있다. 솔루션에 응용 프로그램 다이어그램이 추가되면 <화면 5>와 같은 디자인 창을 보여준다.

<그림 1>의 응용 프로그램 아키텍처를 보면 웹 응용 프로그램은 웹 서비스인 서비스 인터페이스에 연결되어 동작한다. 응용 프로그램 디자이너는 다이어그램에 추가할 수 있는 여러 도구들을 제공하는데 제공되는 도구상자에서 ASP.NET 웹 서비스를 선택하고 디자인 창으로 드래그하여 응용 프로그램 간의 연결을 공유할 수 있게 한다. ASP.NET 웹 서비스를 선택하고 디자인 창으로 드래그&드롭한 후, 두 응용 프로그램의 엔드 포인트(end point)를 서로 연결해주면 두 응용 프로그램이 연결된다.

사용자 삽입 이미지
<화면 6> 연결된 두 응용 프로그램
사용자 삽입 이미지
<화면 7> 추가된 비지니스 로직 계층 컴포넌트 응용 프로그램


응용 프로그램 아키텍처를 계속 구성하기 위해 다음 절차를 계속 진행해보자. 응용 프로그램 아키텍처는 모델을 구성하기 위해 두 개의 컴포넌트를 사용한다. 하나는 비즈니스 컴포넌트이고, 다른 하나는 비즈니스 엔티티이다. 복잡한 전자상거래를 수행하는 기업용 응용 프로그램이라면 비즈토크 웹 서비스(Biztalk WebService)를 추가해서 사용할 수도 있다. <그림 1>은 두 응용 프로그램을 일반적인 클래스 라이브러리 응용 프로그램으로 작성하므로 도구 상자에서 Generic Application을 선택하여 다이어그램에 추가하고, Generic Endpoint를 삽입한 후, 같은 방법으로 연결하여 사용할 수 있다.

마지막으로 데이터 연결이 필요하다. 데이터 연결은 도구상자의 ExternalDatabase를 선택하고 다이어그램에 삽입하여 사용할 수 있다. ExternalDatabase 구성 요소를 다이어그램에 추가하면 비주얼 스튜디오 2005는 어떤 데이터베이스에 어떻게 연결할 것인지에 대한 정보를 요구한다. 적당한 정보를 입력해주면 데이터베이스와의 연결이 완성된다.

이러한 아주 간단한 방법으로 응용 프로그램의 아키텍처를 정의할 수 있는데, 완료된 응용 프로그램 다이어그램은 <화면 8>과 같다.

작성된 응용 프로그램 아키텍처는 여러 컴포넌트의 구성을 알려주는 여러 형태의 다이어그램을 대신할 수 있다. 적당히 주석을 붙여준다면, Business Context 다이어그램도 대체할 수 있다. 이러한 개발 방법은 개발자와 분석가/설계자의 활동 영역을 확연하게 구분해 줄 수 있다. 이런 도구는 반드시 여러 직종의 사람들이 모인 팀 단위의 기업용 설계에서 문서를 찾아 보관하고 문서의 버전을 일일이 확인하는 등의 작업을 확연히 줄여준다.

사용자 삽입 이미지
<화면 8> 작성된 응용 프로그램 다이어그램
사용자 삽입 이미지
<화면 9>시스템 다이어그램


이렇게 작성된 응용 프로그램 아키텍처를 응용해서 각 하위 시스템을 설계할 수 있게 한다. 비주얼 스튜디오 2005는 시스템 다이어그램을 지원하는데, <화면 8>에서와 같이 작성된 여러 응용 프로그램을 분산 응용 프로그램에서 하나의 배포 단위인 시스템을 구성하고 조직할 수 있도록 도와준다.

비주얼 스튜디오 2005에는 클래스 다이어그램이나 배포 다이어그램 같은 많은 새로운 기능들이 포함되어 있다. 필자가 원고를 작성하고 있는 중에, 모 학교에서 동작하는 응용 프로그램이 동작하지 않는다는 연락을 받고 에러를 해결하러 다녀온 적이 있다. 오류는 커넥션 풀(connection pool)이 꽉 차서, 더 이상의 데이터 연결을 작성할 수 없다는 오류였다.

정석대로라면 응용 프로그램의 아키텍처를 제대로 설계하고 커넥션 풀링을 하나의 컴포넌트에다 위임하여 위기 상황에 즉시 대처할 수 있도록 구조를 개선해야 한다. 하지만 우선 급한 불부터 끄고 봐야 한다고, 모든 페이지와 데이터 패치를 한 다음 닫히지 않는 데이터리더 개체들을 일일이 찾아 닫아야 했다. 제대로 된 아키텍처를 기반으로 설계됐다면 이런 오류는 발생하지도 않았을 것이고, 하나의 응용 프로그램을 수정하는 것만으로 전체 프로그램의 오류가 해결됐을 것이다.

다른 도구는 필요한가?
닷넷 개발에서 반드시 비주얼 스튜디오 2005를 사용해야 하는 것은 아니다. 케이스 도구라는 것은 자동차 수리 장비와 같은 것이다. 수 없이 많은 도구들 중에 자기 손에 가장 맞고 사용하기 편한 것 하나만을 골라 사용하면 된다. 래쇼날 로즈가 편하면 그것을 쓰면 되고, 개발 방법론이 UP가 편하다면 UP를 선택하여 사용하면 된다. 꼭 옮겨 올 필요가 있을까 하는 고민은 자바가 처음 등장했을 때 C++ 개발자들의 고민과 같은 맥락이다.

필자는 비주얼 스튜디오 2005가 있더라도 다른 도구 하나 정도는 필요하다고 생각한다. 하지만 그 도구가 꼭 래쇼날 로즈나 볼랜드 투게더 같이 UP 개발 방법에 필요한 모든 도구들을 다 제공하는 무거운 것일 필요는 없다. 몇 장의 종이와 연필, 지웠다 다시 쓰기 위한 지우개면 충분하다.

좋은 변화는 계속되야 한다
얼마 전 간단한 ATL 프로젝트를 수행하기 위해 비주얼 스튜디오 6.0을 설치하고 사용했는데, 5년간 VS.NET을 사용한 필자에게는 고역 같은 일이었다. 우선 인텔리센스 기술의 초기 시점이라 코드를 작성하기가 너무 불편했다(디버거 또한 불편했다). 세상 모든 것은 진화하기 마련이고, 개발 도구 또한 세상 어떤 개체들보다 빨리 진화한다.

비주얼 스튜디오 2005를 접해본 주위의 개발자들이나 학생들은 한숨부터 쉬고 시작한다. 완전히 새로 배워야 되는 것이 아니냐는 것이다. 가끔 필자도 너무 빨리 변화하는 IT를 업으로 삼은 것을 후회할 때도 있다. 『비주얼 스튜디오 2005 베타 2에서 변화한 8532가지』라는 문서를 받을 때면 다 그만두고 머리 깎고 산으로 들어가고 싶어지는 것이다. 하지만 등대가 보이는데 가까운 암초에 배를 댈 수는 없는 법. 그 등대가 구원의 길을 제공한다면 그 등대의 이름이 자바이건, 닷넷이건, 다른 기술이건 상관없다. 기술은 날이 갈수록 변화하고 개발은 갈수록 재미있어지고 있다. 부디, 이런 좋은 변화가 계속 되기를 바란다.@

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

 

김상훈 (동명정보대학 정보기술원 연구원)

2005/09/21

 

사용자 삽입 이미지

 

 

 

 

원문 :http://www.zdnet.co.kr/builder/dev/dotnet/0,39031607,39139648,00.htm

  Comments,     Trackbacks
[기업 환경에 닷넷 적용하기] ④ 닷넷의 웹 프리젠테이션 패턴

[기업 환경에 닷넷 적용하기] ④ 닷넷의 웹 프리젠테이션 패턴

 

연재순서
1.제대로 된 컴포넌트를 위한 프리젠테이션 레이어 설계하기
2.비즈니스 로직 레이어 설계와 물리적 구현을 위한 필요 사항
3.엔터프라이즈 솔루션 패턴 해부하기
4.닷넷의 웹 프리젠테이션 패턴
5.닷넷 개발에서 UML과 케이스 툴의 사용

 

현재의 웹 프로그래밍 환경은 HTML 태그로 하이퍼 링크와 그림만을 입력하던 예전과는 판이하게 틀리다. 변화가 없는 HTML 페이지가 사용자와 상호 작용하여야 하는 경우가 발생하자 CGI (Common Gateway Script)가 등장했다. Perl 또는 C언어로 작성되는 CGI는 사용자의 입력에 따라서 동적인 페이지를 생성했다. 하지만 재 사용 가능한 코드를 쓰기가 거의 불가능에 가까웠고, GGI 프로그래밍은 복잡한 프로그래밍 환경을 만족시키지 못했다. 그 후에 등장한 프로그래밍 모델은 페이지 기반 개발이었다.

ASP또는 PHP로 대표되는 페이지 기반 개발은 여러 계층으로 동작하던 CGI의 복잡성을 줄여주었다. 하지만, 페이지가 갈수록 늘어나고 작성해야 하는 페이지의 수가 말도 못하게 늘어남에 따라 페이지 기반 개발 방식은 프레임워크 기반 방식으로 발전했다. 튼튼하게 제작된 프레임워크는 페이지에 발생하는 복잡함을 줄이는 대신 자신이 대신해 주었다. 프로그래머가 해야 하는 일은 줄어들었다.

사용자 삽입 이미지
<그림 1> 웹 프로그래밍 환경의 변화


프레임워크가 등장함에 따라 페이지를 어떻게 작성할 것인지에 대한 프로그래머의 선택권은 한없이 넓어졌다. 페이지 내에 스크립트를 그대로 유지하는 페이지 기반 프로그래밍 모델을 그대로 사용할 수도 있고, Java의 태그 라이브러리와 ASP.NET의 코드-비하인드를 사용하여 페이지 수준에서 프리젠테이션 로직과 페이지 로직을 구분할 수도 있게 되었다. 소프트웨어의 아키텍처를 정립하고 튼튼한 설계를 기반으로 개발을 시작하는 것은 과도한 복잡성과 중복성을 줄이기 위해서 인데, 웹 응용 프로그램 개발에서 사실상 가장 많이 중복되는 부분은 페이지에서 표현되는 프리젠테이션 계층의 로직들이다. 이런 중복된 내용을 비즈니스 로직 계층으로 옮겨 표현할 수도 있지만, 그렇게 처리한다면 비즈니스 로직 계층의 복잡도가 너무 증가하게 된다.

가장 좋은 방법은 프리젠테이션 계층의 컴포넌트들을 설계하고 이를 재 사용하기 위한 적당한 정도의 복잡성을 가지게 설계하는 것이다. 마이크로소프트의 Enterprise Solution Pattern using Microsoft.net에서는 그 “적당한” 복잡도에 대한 6가지의 질문을 준비하고 그 질문에 대한 대답으로 패턴을 제시한다.

사용자 삽입 이미지
<표 1>


위의 <표 1>은 Enterprise Solution Pattern using Microsoft.net에서 제시하는 질문과 질문에 대한 답으로서의 디자인 패턴이다.

Enterprise Solution Pattern using Microsoft.net은 연구되고 발표된 거의 모든 디자인 패턴을 참고 한다. 디자인 패턴의 교본이라 불리는 GoF의 디자인 패턴을 이해하지 않고서는 웹 프리젠테이션 패턴을 이해하기 힘들다. MVC 패턴은 Observer 패턴을, Page Controller 패턴은 GoF의 패턴중 Template Method 패턴을, Front Controller 패턴은 GoF의 패턴중 Command 패턴을 응용하고 있기 때문이다. 이러한 패턴에 익숙하지 않은 독자들이라면 다시 한번 GoF의 디자인 패턴을 살펴 보기를 바란다. <그림 2>는 웹 프리젠테이션 패턴의 패턴 클러스터이다. (패턴 클러스터에 대해서는 지난 달 연재를 살펴보기 바란다.)

사용자 삽입 이미지
<그림 2> 웹 프리젠테이션 패턴의 패턴 클러스터


MVC (Model-View-Controller) 패턴
해결책의 쌍으로서 MVC 패턴을 생각해보면 질문은 다음과 같다.


“개별적인 영역을 쉽게 수정하기 위해서 웹 응용 프로그램의 사용자 인터페이스 기능을 어떻게 모듈화 할 것인가?”


질문이 너무 추상적인 것 같이 느껴진다. 질문을 해설해보면 주로 다음과 같은 문제라고 생각할 수 있다.

① HTML 페이지를 설계하는 것과 비즈니스 로직을 설계하는 것은 거의 모든 경우에 다른 기술이 필요하다. 이는 웹 디자이너와 프로그래머의 고질적은 의견 대립을 발생시키는 문제이기도 하다. 빼어난 웹 디자인 실력과 고급 프로그래밍 실력을 모두 갖춘 사람은 흔하지 않다. MVC 패턴은 두 가지 영역에 대한 개발을 분리할 수 있다.

② 같은 데이터에 대한 다른 표현이 종종 발생한다. MVC 패턴은 같은 데이터를 서로 다르게 보여지도록 디자인 할 수 있다.

③ 웹 기반 응용 프로그램은 비즈니스 로직 보다 사용자 인터페이스가 자주 바뀐다. (페이지의 리뉴얼이 일어날 경우 비즈니스 로직은 전혀 변화가 없는 경우가 허다하다) MVC 패턴은 비즈니스 로직의 변화 없이 사용자 인터페이스의 변화를 가능하게 해 준다.

④ 리치 클라이언트용 웹 응용 프로그램이 PDA용 웹 응용 프로그램으로 마이그레이션 될 경우, 사용자 인터페이스가 크게 변화한다. 이러한 장치 의존적인 작업이 일어날 경우, MVC 패턴은 비즈니스 로직의 변화 없이 작업을 완료할 수 있게 한다.

MVC 모델은 Model - View - Controller 3 가지 클래스로 역할을 구분하도록 프리젠테이션을 설계하는 기법이다. GoF의 디자인 패턴[1]에 의하면, MVC 패턴을 다음과 같이 설명한다.


“MVC는 세 가지 객체로 이루어진다. 모델은 응용 프로그램 객체이며, 뷰는 스크린에 모델을 디스플레이 하는 방법이며, 컨트롤러는 사용자 인터페이스가 사용자 입력에 반응하는 방법을 정의한다.”


사용자 삽입 이미지
<그림 3> MVC 클래스 구조
MVC 패턴에서 얻을 수 있는 가장 핵심적인 장점은 뷰와 컨트롤러는 모델의 의존하지만 모델은 뷰와 컨트롤러에 의존하지 않는다는 것이다. 이런 장점으로 인해 실제 객체들이 존재하는 모델 계층의 클래스들이 프레젠테이션과 별도로 작성되고 테스트 될 수 있다.

ASP.NET 에서의 구현
사실상, ASP.NET은 전형적인 이벤트 드리븐 방식을 사용한다. ASP.NET은 HttpHandler 클래스가 전방에서 동작하여 모든 페이지들에 대한 요청을 처리하고 발생하는 이벤트를 처리하는 이벤트 지향적인 방법을 선택하고 있어 Front Controller나 Page Controller등의 향상된 설계 기법을 이미 내장하고 있다고 봐도 무방하다. ASP.NET에서 MVC의 구현은 HttpHandler 같은 컨트롤러의 구현과 별 상관없이 (혹은 그 존재를 모르더라도), ASP.NET이 지원하는 Code-Behind 기능을 사용하여 할 수 있게 된다. 모델이 뷰에 의존하지 않게 설계하는 것이 MVC의 목적이라고 한다면, Code-Behind의 사용으로 그러한 목적을 훌륭하게 달성할 수 있다.

다음 그림과 같은 페이지를 디자인 한다고 하자. 페이지는 Page_Load 이벤트 핸들러에서 책의 타입을 로드하여 드롭다운 리스트에 보여주고, 버튼의 이벤트에 반응하여 데이터그리드컨트롤에 바인딩한다.

사용자 삽입 이미지
<그림 4> 예제 페이지


ASP.NET에서 <그림 4>와 같은 페이지를 제작하는 것은 아주 다양한 방법으로 할 수 있다. 우선, 가장 쉬운 방법은 <코드 1> 과 같이 In-Line 코드를 쓰는 것이다. 모든 내용을 하나의 파일안에 써서 로직과 뷰를 단순히 <Script> 태그로 구분한다.

<코드 1> 한 파일에 세 역할을 모두 집어넣은 단일 ASP.NET 페이지
사용자 삽입 이미지

<%@ Import Namesace=”System.Data.SqlClient” %>
  <body>
    <Script Language=”C#” Runat=”Serve” />
    void Page_Load(object sender, EventArgs e) {
      // 데이터베이스에 연결하여 데이터를 반환받음
    }
    void btn_Click(object sender, EventArgs e) {
      // 버튼 클릭 이벤트에 반응하여 데이터를 반환받음
    }
    </Script>
    <form id="Solution" method="post" Runat="Server">
      <h3>Titles</h3>
      Select a Titles:<br>
      <asp:DropDownList id="titlesSelect" runat="Server" />
      <asp:Button Runat="Server" Text="Submit" id="Button1" name="Button1" />
      <p>
        <asp:DataGrid id="myDataGrid" Runat="Server" />
  </form>
  </P>
</body>
사용자 삽입 이미지

위 코드는 패턴에 있는 Model, View, Controller 세 가지 역할을 모두 담당한다. 다만, 구분하지 않을 뿐이다. View의 역할은 HTML로 표시된다. 페이지는 잘 동작하고, 독립적이며 직관적이다. 작은 응용 프로그램이거나 페이지가 자주 변경되지 않는 경우라면 아주 권장할 만한 생산성 뛰어나고 쉬운 개발 방법이라 할 수 있다. 하지만, 여러명이 동시에 작업을 진행하는 경우, (대표적으로 웹 디자이너와 프리젠테이션 로직 개발자가 같이 작업을 병행하는 경우)와 사용된 데이터 액세스 코드를 재 사용하고 싶은 경우, 위와 같은 설계라면 거의 작업이 불가능하다. 이런 문제에 당면했다면, Code-Behind를 사용하여 리팩토링 할 수 있다. Visual Studio.net을 사용하지 않았기 때문에, Page 지시문에서 CodeBehind 대신 Src를 사용했다.

<코드 2> Code-Behind 리팩토링 한 View 페이지 (.aspx 페이지)
사용자 삽입 이미지

<%@ Page language="c#" Src="CodeBehind.aspx.cs" AutoEventWireup="false" Inherits="CodeBehind1.CodeBehind" %>
<HTML>
  <HEAD>
    <title>Solution
  </HEAD>
  <body>
    <form id="Solution" method="post" Runat="Server">
      // 동일한 View 코드
  </body>
</HTML>
사용자 삽입 이미지


<코드 3> CodeBehind 리팩토링한 코드 비하인드 코드
사용자 삽입 이미지

using System;
using System.Data;
using System.Data.SqlClient;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace CodeBehind1
{
  public class CodeBehind : System.Web.UI.Page
  {
    protected System.Web.UI.WebControls.DropDownList titlesSelect;
    protected System.Web.UI.WebControls.Button Button1;
    protected System.Web.UI.WebControls.DataGrid myDataGrid;

    private void Page_Load(object sender, System.EventArgs e)
    {
      f (!Page.IsPostBack) {
        // 데이터베이스에 연결하여 데이터를 반환받음
      }
    }

  // OnInit 이벤트 핸들러 및 InitializeComponent() 메소드

  public void SubmitBtn_Click(object sender, System.EventArgs e)
  {
    // 버튼 클릭 이벤트에 반응하여 데이터를 반환받음
  }
  }
}
사용자 삽입 이미지

위 리팩토링에서 <코드 2>에는 WebForm 컨트롤들과 HTML 태그만이 존재하여 View 와 다른 역할들을 구분한다. <코드 3>에는 Model과 Controller 역할을 수행하는 코드들이 들어있다. 이렇게 설계된 페이지에서는 페이지가 데이터베이스에 액세스하기 위한 어떠한 코드들도 가지고 있지 않기 때문에 데이터베이스 코드가 변경된다거나 페이지의 디자인이 변경된다 하더라도 서로 간섭받지 않게 된다.

코드-비하인드 기능이 3-Tire 구조 아키텍처를 사용하기 위한 프리젠테이션 계층과 비즈니스 로직 계층을 강제 구분하는데 사용된다는 말이 있었는데, 그렇게 정확한 이야기는 아니다. ASP.NET의 코드-비하인드는 위에서 보듯이 View 역할과 다른 역할들을 구분할 수 있도록 하는데 주로 사용될 수 있다.

주어진 질문에서 해결되지 않은 것은 로직을 재 사용하는 것이다. 기술적으로는 Code-Behind 코드의 재 사용이 가능하지만 현실적으로는 거의 불가능하다. 특히 Visual Studio.net을 사용해서 이런 작업을 해본 경험이 있는 개발자라면 하나의 코드-비하인드 파일을 여러 개의 뷰 파일이 공유해 쓰는 것은 거의 불가능하다는 것을 알 것이다. 이 경우에 대한 답이 바로 MVC 패턴을 사용하는 것이다.

위의 코드-비하인드 리팩토링에서 뷰를 표현하는 aspx 페이지는 수정할 부분이 없다. <코드 3>의 코드-비하인드 페이지가 모델과 컨트롤러 두 가지 역할을 담당하는데, 모델과 컨트롤러의 역할을 구분해 주어 모델의 코드를 재 사용할 수 있게 하는 것이다.

데이터베이스에 액세스하는 로직을 가지는 모델 클래스를 생성한다.

<코드 4> MVC 리팩토링에서 Model
사용자 삽입 이미지
using System;
using System.Data;
using System.Data.SqlClient;

public class Model {
  public static DataSet GetTypes() {
    // 데이터베이스에 액세스하여 책의 타입 정보를 데이터셋으로 반환한다.
  }

  public static DataSet GetTitles(string typeID) {
    // 데이터베이스에 액세스하여 타입에 해당하는 책 정보를 반환한다.
  }
}
사용자 삽입 이미지

Page 클래스를 상속하는 CodeBehind 클래스는 다음과 같이 역할이 수정된다.

<코드 5> MVC 리팩토링에서 Controller
사용자 삽입 이미지

public class CodeBehind : System.Web.UI.Page {
  protected System.Web.UI.WebControls.DropDownList titlesSelect;
  protected System.Web.UI.WebControls.Button Button1;
  protected System.Web.UI.WebControls.DataGrid myDataGrid;

  private void Page_Load(object sender, System.EventArgs e) {
    if (!Page.IsPostBack) {
// 모델 클래스의 GetTypes() 메소드 호출 결과를 컨트롤에 바인딩
    }
  }

    // OnInit 이벤트 핸들러 및 InitializeComponent() 메소드

  public void SubmitBtn_Click(object sender, System.EventArgs e)
  {
    // 모델 클래스의 GetTitles () 메소드 호출 결과를 컨트롤에 바인딩
  }
}
사용자 삽입 이미지

ASP.NET에서 MVC 모델을 고려하여 설계하면 다음과 같은 장점들을 얻는다.

  • 페이지 간의 의존성이 감소한다.

  • 메소드의 재 사용성이 증가한다.

  • 동시 작업을 진행할 수 있다.

  • 테스트가 용이하다.

    하지만 모든 장점에는 단점이 따라오는 법이다. MVC의 단점은 파일과 코드가 추가된다는 것이다. 필자가 참여했던 모 프로젝트에서, 경험 있는 닷넷 개발자가 다음과 같이 이야기 하는 것을 들은적이 있다. 당시 필자는 어차피 디자이너가 닷넷을 잘 모르니 M-VC로 프로젝트를 진행하는 것이 차라리 효율적이라고 주장하고 있었다.

    “제가 전에 참여했던 닷넷 프로젝트에서, VS.NET을 사용했었는데, 디자이너에게 1주일쯤 닷넷을 가르치고 Code-Behind로 개발하는 것이 아주 효율적이었습니다”

    필자도 수긍을 했고, 디자이너도 닷넷을 배우겠다고 자청하여 1주일쯤 디자이너에게 WebForm 사용법을 가르친 후 (DataGrid 컨트롤과 DataList 컨트롤의 사용법을 익히느라고 디자이너가 꽤 고생을 하긴 했다) VS.net을 사용하여 MVC 패턴을 적용하여 진행된 프로젝트는 꽤 성공적으로 진행되었다. 디자이너는 aspx 작업을 하고, 개발자는 컨트롤의 이름만 알면 동시 작업을 진행할 수 있었다. 기업형 응용 프로그램 개발에서 MVC 패턴의 장점을 잘 보여주는 단적인 예였다.

    Page Controller
    패턴 클러스터에서 Page Controller 패턴은 MVC 패턴과 같은 레벨에 놓여 있다. Page Controller 패턴은 MVC 패턴에 기반한다. Page Controller 패턴을 질문 ? 해결책의 쌍으로서 Page Controller 패턴을 생각해보면 질문은 다음과 같다.

    “코드를 복사하지 않으면서 재 사용이 가능하고 융통성있는 약간 복잡한 웹 응용 프로그램을 어떻게 작성할 것인가?”

    역시 질문이 너무 추상적이다. 질문을 해설해보면 주로 다음과 같은 문제라고 생각할 수 있다.

    ① 예를 들면, 게시판에 글을 쓰는 동작을 하고 나면 고쳐진 게시판의 리스트 페이지로 이동한다. 웹 기반의 전자메일 응용 프로그램에서 메일을 발송하고 나면 고쳐진 받은 편지함 페이지로 이동한다. 이러한 이동은 거의 정적이고, 같은 방식으로 동작한다. 세부적인 동작은 틀리지만, 사용자의 행위는 동일하다. 사용자의 행위가 동일함에도 불구하고 여러 개의 컨트롤러에 개별적인 코드를 써서 MVC 패턴의 단점인 복잡성을 그대로 둘 것인가?

    ② MVC 패턴의 단점중의 하나는 파일의 개수가 증가하여 여러 개의 파일을 따로 컨트롤러를 따로 테스트 해야 한다는 것이다. 여러 개의 사용자 인터페이스를 동일한 타입의 컨트롤러가 관리한다면 테스트가 훨씬 용이해 질 수 있다.

    ③ ASP.NET의 이벤트 모델은 고정되어 있다. 따라서, 거의 모든 페이지가 유사한 방식으로 렌더링 된다. 사용자 인증을 검증하고, 쿼리 문자열로부터 Request 정보를 얻어내고 같은 헤더와 꼬리말을 사용한다. 이러한 작업을 하나로 묶어 복잡성을 줄일 수 있을 것인가?

    이런 질문의 해결책으로 Page Controller 패턴이 제시된다. 만약, 다음과 같은 상황에 직면했다고 생각해 보자. 웹 응용 프로그램이 7개의 게시판을 가지고 있다. 게시판은 공지사항, 뉴스, QnA, 공개 게시판 등인데 동작하는 방식은 완전히 같다. 게시판의 디자인은 수시로 변하는 등의 이유로 MVC 패턴을 응용하여 설계 하였다.

    그렇다면, 각 게시판의 글 쓰기 페이지와 리스트 보기 페이지 등의 동작은 완전히 같다. 이런경우, 각 게시판별로 각각의 뷰 페이지와 컨트롤러를 작성하는 것은 부담이 되고 또한 테스트 하기 곤란해 진다. (물론, 하나의 페이지가 모든 게시판을 처리하도록 작성할 수 있으나, 웹 페이지 디자인 등의 문제로 그렇게 처리하기가 곤란한 상황이라고 가정하자) 이런 경우, Page Controller 패턴의 사용을 고려해 볼 수 있다는 이야기다.

    모든 게시판에서 글 수정하기 페이지를 작성할 때, 페이지의 모든 컨트롤러는 다음과 같은 기능들을 구현한다.

    <코드 6> Controller
    사용자 삽입 이미지

    public class Modify_Article : System.Web.UI.Page {
      // 전역변수 (WebForm 컨트롤들)
      int no;

      private void Page_Load(object sender, System.EventArgs e) {
        // 쿼리스트링으로 전달된 값 처리
        no = Int32.Parse(Request.Params["no"].ToString());
        GetArticle(no);
      }

      override protected void OnInit(EventArgs e) { ... }
      private void InitializeComponent() { ... }

      private void GetArticle(int no) {
        // 글을 가져와서 컨트롤에 바인딩
      }

      private void Modify_Article(object sender, System.EventArgs e) {
        Model.Modify_Article(no); // 글 수정
        Response.Redirect("ListPage.aspx"); // 리스트 페이지로 이동
      }
    }
    사용자 삽입 이미지

    위와 같이 같은 방식으로 동작하는 컨트롤러를 여러 개 작성하는 것은 좋지 않은 해결책이 된다. 이를 위해서, 공통적인 동작을 하는 페이지 컨트롤러를 작성하고, 같은 동작을 하는 컨트롤러를 집중화 해서 요청에 대한 중앙 집중적인 처리를 담당할 수 있도록 하는 것이 유리해진다. 개선된 컨트롤러들은 <그림 5>와 같은 방식으로 설계될 수 있다.

    사용자 삽입 이미지
    <그림 5> Page Controller 패턴을 이용한 설계 개선

    <그림 5>의 클래스 다이어그램에서 BoardController 클래스는 다음과 같은 코드로 구현된다.

    <코드 6> BoardController 클래스의 구현
    사용자 삽입 이미지

    public class BoardController : System.Web.UI.Page {
      protected void Page_Load(object sender, System.EventArgs e) {
        no = Int32.Parse(Request.Params["no"].ToString());
        GetArticle(no);
      }

      #region Web Form 디자이너에서 생성한 코드
      override protected void OnInit(EventArgs e) {
        InitializeComponent();
        base.OnInit(e);
      }

      private void InitializeComponent() {
        this.Modify_Article.Click +=
        new System.EventHandler(this.Modify_Article_Click);
        this.Load += new System.EventHandler(this.Page_Load);
      }
      protected virtual void GetArticle(int no) { }

      protected virtual void Modify_Article_Click(object sender, System.EventArgs e){}
    }
    사용자 삽입 이미지

    <그림 5>의 클래스 다이어그램에서와 같이, NoticeModify.aspx 페이지에 작성된 뷰와 모델을 컨트롤하는 컨트롤러 NoticeModify 클래스는 공통적인 구현을 포함하는 BoardController를 상속하고, GetArticle() 메소드와 Modify_Article_Click() 이벤트 핸들러를 오버라이드 하는 간단한 코드만으로 전체 컨트롤을 중앙 집중화 할 수 있다. BoardController 클래스의 Page_Load 이벤트 핸들러가 GoF 디자인 패턴[1]의 Template Method 역할을 하는 것이다. GoF의 디자인 패턴에서는, Template Medhod가 추상 메소드로 구현되고 기본 클래스가 추상 클래스이지만 ASP.NET에서는 Page를 상속하는 클래스가 추상 메소드가 될 수 없으므로, 가상 메소드로 구현하여야 한다.

    <코드 7> NoticeModify 컨트롤러
    사용자 삽입 이미지

    public class NoticeModify : BoardController {
      protected override void GetArticle(int no) {
        // Notice 모델에서 글을 가져와서 컨트롤에 바인딩한다.
      }

      protected override void Modify_Article_Click(object sender, System.EventArgs e) {
        // Notice 모델에 액세스하여 글을 업데이트 한다.
      }
    }
    사용자 삽입 이미지

    Page Controller 패턴을 사용하면 다음과 같은 장점을 얻을 수 있다.
  • 간단히 구현할 수 있다. 전체 컨트롤러를 중앙 집중화하는 Front Controller와는 달리 Page Controller 패턴은 하나의 동적인 페이지가 하나의 컨트롤러에 의해서 처리되므로, 간단함을 유지할 수 있다. 그러므로 Page Controller는 어느 정도 복잡한 웹 응용 프로그램에 적당하다.

  • ASP.NET이 제공하는 컨트롤러를 그대로 활용하여 일관된 개발 방향을 유지할 수 있다. 실저적으로 ASP.NET은 HttpHandler에 컨트롤러를 구현하고 있으므로, 기본적인 컨트롤러를 사용할 수 있다.

  • Template Method 패턴을 활용하므로 공통적인 구현에 대한 재사용성이 증가한다. 또한, 객체지향의 상속성을 이용하므로 쉽게 확장할 수 있다. 헬퍼 클래스를 사용하여 기능을 확장할 수도 있다.

    당연히, 단점도 있는법, Page Controller 패턴은 다음과 같은 단점을 가진다.

  • 객체 지향의 오랜 논란인 상속 트리가 깊어진다는 치명적인 단점을 가지고 있다.

  • 복잡한 응용 프로그램에 사용하면 감당할 수 없을 정도로 꼬인다는 단점이 있다.

    이런 문제를 해결하기 위해서, 전체 컨트롤러를 중앙 집중화 하는 Front-Controller 패턴을 사용할 수 있다. Front Controller 패턴과 Observer 패턴등은 조금 복잡한 클래스 구조를 가지게 되므로 다음 연재에서 닷넷 개발에서 UML과 케이스 툴을 사용하는 방법과 함께 생각해 보도록 하겠다.

    마치면서
    얼마 전, 마이크로소프트 리서치에서 F#이라는 새 언어를 본 적이 있다. (새 언어가 아니고 이전부터 연구되던 언어이긴 하다) 필자는 대학원 시절, 석사학위 논문 주제로 C#에서 Generics의 구현을 연구한 적이 있는데, 그때 많이 참조한 부분이기도 하다. F#은 ML을 기반으로 작성된 함수형 언어인데, 닷넷 환경에서는 COM을 위한 스크립트 언어 정도로 쓰이면 아주 강력할 것 같다는 느낌을 받았다.

    같이 근무하는 다른 연구원님들과 그런 이야기를 하다가, F#이라는 언어가 쓸모 있다고 해도 과연 C#이나 VB같은 언어들이 익숙한 개발자들에게 받아들여 질 수 있을까에 대해서 생각했다. 필자의 스승이기도 한 책임 연구원님은 특유의 어투로 “안 사용하면 말고.. 쓰고 싶으면 쓰고…” 라고 이야기 했지만 필자는 좋은 것이 있으면 반드시 사용해서 더 좋은, 제대로 된 응용 프로그램을 만들어야 한다는 쪽이다.

    개발자들도 의사고시 같은 시험이 생겨서 인턴, 레지던트 과정을 거쳐서 개발자 개업도 하고 하는 환경이 와야 우리나라 IT가 제대로 될 것 같다는 우스갯 소리도 했다. 새로운 피쳐가 등장하고 새로운 기법이 등장하였다고 반드시 그것을 사용해야 한다는 법은 없다. 하지만, 개발자들은 유수의 기업과 뛰어난 개발자 / 학자들이 연구한 산출물을 연구해 봐야 한다는 의무감을 가져야 한다고 생각한다. Enterprise Solution Pattern같은 뛰어난 결과들을 실제 개발에 응용하지는 않더라도 이러한 기법이 있더라 하는 것을 알고만 있는 것으로도 훨씬 더 훌륭한 구조를 가지는 뛰어난 프로그램을 작성할 수 있는 법이다.

    허준 같은 의원들의 의무가 환자들을 치료하고 보살피는 것이라면, 개발자들의 의무는 좋은 프로그램을 작성하는 것이다. 날로 떨어지는 개발자들에 대한 대우와 바쁜 일정이 그런 기본적인 의무감 마저 상실하게 하는 것 같아 씁쓸하긴 하다.@

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

    김상훈 (동명정보대학 정보기술원 연구원)

    2005/09/07

     

    사용자 삽입 이미지

     

     

     

     

    원문 :http://www.zdnet.co.kr/builder/dev/dotnet/0,39031607,39139339,00.htm

      Comments,     Trackbacks
    홈네트워크 IPv6 시범 서비스

    홈네트워크 IPv6 시범 서비스

     

    수행기관 : (주)퓨처시스템

     

    1. 개요

    기존 홈네트워크 시범사업에서 설치되었던 IPv4 전용 홈 게이트웨이를 IPv6지원용으로 교체하여 서비스 접근성과 효과성이 큰 VoIPv6 서비스와 홈 시큐리티 분야에서 많이 이용하는 웹캠(네트워크 카메라)을 통한 모니터링 기능을 IPv6 망에서 지원하고, 일반 소비자들에게 IPv6 웹 서비스 접속 기능을 제공하여 IPv6에 대한 이해 및 확산을 유도

    주요 제공 서비스

     •  VoIP 폰을 이용한 IPv6 기반의 인터넷전화 서비스
     •  IPv6 네트워크 카메라를 활용한 원격 모니터링 서비스
     •  한국전산원 IPv6 포털 서비스를 포함한 IPv6 접속 및 컨텐트 서비스

     

    2. 시범 서비스 구성

    사용자 삽입 이미지

     

    3. 주요 IPv6 서비스

    사용자 삽입 이미지

     

    4. IPv6/IP4 Ready 홈게이트웨이

    주요기능

     •  다양한 IPv4 망에서 IPv6 터널링 구현
     •  IPv4/IPv6 Dual Stack 구현
     •  고품질 무선랜(802.11 a/b/g) 기능 제공
     •  다양한 서비스 포트 제공
     •  다양한 프로토콜 지원(S-Cube, LNCP 등)
     •  Multi Ethernet 포트 지원
     •  L2 Switch를 이용한 Traffic control 제공

    사용자 삽입 이미지

     

    5. VoIPv6 폰 서비스

    주요기능

     • IPv6 VoIP 폰이 댁내에 제공되는 최초의 서비스 모델
     • 댁내에 설치될 VoIP 폰의 형태에 따라 유 · 무선 VoIP 폰을 선택하여 사용가능
     • IPv6 망을 통해 Gate Keeper와 연동, 전화 요금은 Calling Card 방식 사용

    사용자 삽입 이미지

     

    6. IPv6 네트워크 카메라 서비스

    주요기능

     • 네트워크 카메라를 이용한 홈 모니터링 서비스는 IPv4/IPv6를 모두 제공
     • 댁내 외부망 환경이 유동인 경우에도 서비스 가능

    사용자 삽입 이미지

     

    7. IPv6 웹 서비스

    주요기능

     •댁내의 IPv4/v6 Dual Stack을 제공하는 PC에서 IPv6 웹사이트에 접속

    사용자 삽입 이미지

     

      Comments,     Trackbacks
    다양한 애플리케이션 향연을 보장하는 IPv6
    [특집] 다양한 애플리케이션 향연을 보장하는 IPv6

     

    출처 : 온더넷 7월호

     

    IPv6 시대가 도래하면 무한대의 IP 어드레스 덕분에 다양한 경험이 가능할 것으로 보인다. 각양각색의 장비에서 인터넷에 접속할 수 있는 것은 기본이고, 보안이나 QoS 등 다양한 서비스를 보장받을 수 있다는 장점을 갖는다. IPv6 망 구축과 동시에 연구되고 있는 주요 이슈인 와이브로, 홈 네트워크, VoIP, 텔레매트릭스, RFID에서 IPv6는 어떤 역할을 하는지 알아본다.


    김영미기자

     

    무한개의 IP를 제공하는 IPv6 망의 특성에 따라 다양한 서비스를 활용할 수 있는 기회를 포착할 수 있게됐다. 현재 시점에서 미래의 서비스를 직접 사용해 보고 그 장점을 경험할 수 있다면, 사용자들은 IPv6에 대한 이해를 좀더 쉽게 할 수 있을 것으로 보인다. 현재 정부의 IT839 전략을 기반으로, 와이브로, 홈네트워크, VoIP, 텔레매틱스, RFID, BcN에서 IPv6가 어떤 역할을 하는지 자세히 알아본다. 이로서 IPv6의 장점을 누누이 설명하는 것보다는 쉽게 IPv6를 이해할 수 있을 것이다.

     

    와이브로

     

    와이브로(WiBro)는 무선 초고속 서비스(Wireless Broadband Service)의 약자로, 현재 가정에서 즐기고 있는 초고속 인터넷을 무선 영역으로 확장시켜, 언제 어디서나 자유롭게 인터넷 환경을 즐길 수 있도록 만들어준 서비스다. 기존의 이동 전화 기반 무선 인터넷 서비스는 서비스 지역과 이동성에서는 우수하지만, 서비스 요금이 높고, 전송 속도가 느리며 기대 이하의 품질과 불편한 인터페이스를 가지고 있어 사용자의 욕구를 완전히 충족시키지 못했다. 기존의 무선 LAN 서비스도 고속의 전송속도를 지원하고 있으나, 핫스팟 위주의 옥내 기반으로 구축돼 서비스 범위가 협소하고 ISM(Industrial, Scientific, Medical) 대역 특성상 전파 간섭 등의 취약점이 많았다. 와이브로 서비스는 2.3GHz 대역의 주파수를 사용해 도심 지역에서 대중 교통 수단의 주행 속도의 이동성을 보장하고 현재 가정에서 사용하는 초고속 인터넷과 유사한 수준의 전송속도인 1Mbps∼3Mbps로 인터넷을 이용할 수 있다.

     

     

    IPv6의 자동 어드레스 설정 기능 활용

     

    따라서 와이브로의 이동성을 지원하기 위해 모바일 IP가 필요한데, 모바일 IPv6를 이용하면 다음과 같은 장점이 있다.

     

    첫째, IPv6 체계로는 거의 무한에 가까운 어드레스를 만들어 낼 수 있다. 따라서 모든 이동 단말은 IP 어드레스를 가질 수 있고, 향후에는 더 많은 단말이 추가되거나 네트워크가 커져도 영향을 받지 않는다.

     

    둘째, 자동 어드레스 설정 기능을 이용할 수 있다. 각 단말이 통신하기 위해서는 자신이 사용할 IP 어드레스를 얻어야 하는데, 이를 위해 별도의 프로토콜을 사용하지 않고도 자동으로 쉽게 어드레스를 얻을 수 있다. 따라서 이 기능을 이용하면 이동시에 접속을 관리하는 FA(Foreign Agent)가 필요없으므로 쉽게 자신의 위치 정보를 구성할 수 있고 편리하게 무선 접속을 할 수 있다. 


    셋째, IPv6는 확장성이 뛰어나 IPv4에서 필수 사항인 FA가 필요없으므로, 망을 확장하거나 향후에 장비를 도입할 때에도 추가 비용이 발생하지 않으며, 홈 네트워크나 RFID 등의 대규모 서비스가 도입될 경우에도 이종 통신망 간의 연동이 쉽다.

     

    넷째, 와이브로에서는 IPv6의 라우팅 최적화 기능을 이용할 수 있다. 기존의 모바일 IPv4에서는 선택적으로 라우팅 문제를 해결하는 기능을 이용할 수 있었지만, 모바일 IPv6에서는 기본적으로 라우팅을 효율적으로 하는 기능을 포함한다. 다섯째 보안 기능이 강화된다. IPv4에서 보안성을 유지하기 위해서는 별도의 프로토콜이나 프로그램을 이용해야 하지만, IPv6에서는 기본적으로 인증, 보안 헤더와 IPSec이 존재하므로, 쉽게 보안 기능을 이용할 수 있다. 

     

     

     

    홈 네트워크

     

    홈 네트워크 서비스는 가정내 PC를 비롯한 정보 가전기기를 유선 또는 무선의 네트워크로 연결해 인터넷과 데이터 공유, 스캐너와 프린터 등의 주변기기 공유와 상호 제어를 할 수 있는 서비스다. 이로써 인터넷이나 휴대용 정보 단말기를 이용해, 외부 네트워크에 접속해 시간, 장소에 구애받지 않고 자유롭게 가정의 TV, 냉장고, 에어컨, DVD 플레이어, 디지털 카메라 등의 디지털 가전기기를 원격으로 제어할 수 있다.


    이같은 홈 네트워크로 구성된 디지털 홈 환경에서는 각 가전기기가 항상 접속할 수 있어야 하고, 양방향 서비스를 제공해야 하며, 독립적으로 수행할 수 있어야 한다. 따라서 모든 가전기기는 IP를 가지는 것이 바람직해 IPv6를 적용해야 홈 네트워크를 쉽게 구성할 수 있다. IPv6는 어드레스 자동 설정 기능이 있어, 가전기기나 네트워크에 접속할 때 별도의 어드레스 설정없이 바로 접속할 수 있다. 따라서 사용자는 복잡한 설정없이 가전기기를 설치하기만 하면 플러그 앤 플레이 기능으로 홈 네트워크에서 서비스를 이용할 수 있다.

     

     

    인증받지 않은 사용자 접근 제어

     

    홈 네트워크의 특성상 보안 기능 역시 매우 중요하다. 홈 네트워크 기기들로만 이뤄진 내부 네트워크 뿐만 아니라 외부 접속에 대해서도 철저한 보안 기능이 요구된다. 외부에서 인증 받지 않은 사용자가 가전기기들을 악의적으로 제어하거나 개인의 사생활 정보를 유출하는 등, 보안 기능이 완비되지 않은 홈 네트워크는 언제나 많은 위험 요소에 노출돼 있다. IPv6는 기본적으로 IPSec이라는 보안 기능을 탑재하고 있으므로, 보안 네트워크를 쉽게 구축할 수 있다.


    홈 네트워크에 접속해서 서비스를 이용하기 위해서는 각 장비들은 이동성을 기본으로 지원해야 한다. 사용자는 언제 어디서나 서비스를 이용할 수 있어야 하기 때문이다. 모바일 IPv6를 이용하면, 이동성을 쉽게 지원할 수 있으며, 아무때나 접속할 수 있다. 또한 다수의 가전기기들이 홈 네트워크를 구성하고 있을 때에는 네트워크의 효율을 높이기 위해 라우팅을 최적화하는 것이 바람직하다. 라우팅을 효율적으로 하기 위한 별도의 프로토콜을 사용하지 않고도 IPv6를 이용하면, 효과적인 라우팅 기능을 구현할 수 있다. 또한 IPv6는 인접 장비와 서비스 탐지 기능을 기본적으로 제공할 수 있다. 네트워크가 스스로 장치와 서비스를 탐지해 통신한다는 것은 사용자 입장에서 보면, 그만큼 사용자가 서비스를 편리하게 이용할 수 있다는 것을 의미한다. 이런 기능은 Neighbor Discovery 프로토콜을 이용해 실현할 수 있다.

     

     

    KOREAv6에서 홈 네트워킹 사례 시연

     

    국내에서 IPv6가 본격적으로 홈 네트워킹을 지원한 것은 지난 2004년 7월부터다. KOREAv6 사업의 일환으로 국내 IPv6 망을 통합한 전국망을 활용해, 일반 이용자 대상의 IPv6 시범 서비스와 IPv6 장비와 서비스 시험을 운영해 10개의 시범 서비스에 35개의 기관이 참여해 2004년 12월 31일까지 진행됐다. 홈 네트워크 서비스와 관련한 KOREAv6 시범 서비스는 씨브이네트와 KTF가 있다.


    씨브이네트는 896세대, 500여 명 규모의 FTTH 환경의 시범 아파트에 IPv6 VoD 서비스와 IPv6 웹 카메라 서비스를 제공하는 가정내 IPv6 시스템, 응용 서비스 도입과 이용 활성화 과제를 수행했다. 이 시범 서비스를 통해 사용자에게 IPv6를 이용할 수 있는 기회를 제공하고 VoD 서비스, 웹 카메라 서비스 등 가정의 네트워크 기기가 IPv6로 이뤄져 사용되는 다양한 서비스를 검증해 볼 수 있는 기회가 됐다.


    KTF는 IPv6 모바일 홈 네트워크 시범망 구축과 시범 서비스 과제를 수행했다. IPv6 CDMA 시험망에서 PDA를 이용한 홈 네트워크 제어 시범 서비스와 IPv6 무선 LAN 환경에서 PC를 이용한 홈 네트워크 제어 시범 서비스, IPv6 WCDMA 시험망 환경에서 PDA를 이용한 홈 네트워크 제어 시범 서비스 등이 이뤄졌다.  서비스 이용자는 PDA 등의 모바일 단말기로 가정 내의 전등, 가스 밸브, 컨센트, 전동커튼 등 가전기기를 제어할 수 있었다. 이 시범 서비스를 통해 IPv6 기반의 홈 네트워크 상용화 기반을 마련하고 서비스를 검증하며 문제점과 해결방안을 도출해 낼 수 있을 것이다.

    사용자 삽입 이미지

     

     

    VoIP


    VoIP는 PSTN처럼 회선에 근거한 전통적인 프로토콜이 아니라, 아날로그 멀티미디어 신호를 디지털 형태의 음성 정보로 변환 후 패킷으로 전송한다. 점차 PSTN이 사라지고 All IP 네트워크가 되면 실제 IP가 전화번호의 역할을 대신할 것이다. IPv4 환경에서 VoIP를 이용하면 어드레스 부족 문제뿐만 아니라 사용자 인증, 시그널링 메시지, 미디어 스트림에 대한 보안 문제와 NAT(Network Address Transration) 이용시 애플리케이션 적용 문제, 네트워크의 음질 저하 문제가 발생한다. VoIP에 IPv6를 적용하면 이와 같은 문제를 해결할 수 있다.


    VoIP 전화기가 많이 보급될수록 그만큼 많은 IP가 요구되므로 IPv6가 필요하다. 만약 IPv6를 이용하지 않고 NAT를 이용해 어드레스 부족 문제를 해결하면 NAT로 인해 VoIP 서비스에 문제가 발생한다. NAT는 대부분의 프로토콜이 통과하지 못하기 때문에, NAT 내부에 위치한 단말기에서 공인 네트워크로 패킷을 전송할 수 있지만, 공인 네트워크의 데이터는 NAT 내부로 전송될 수 없다. 이는 VoIP 뿐만 아니라 다른 인터넷 애플리케이션을 이용하는 것에도 문제가 된다. IPv6를 이용해 어드레스 부족 문제를 해결하면 NAT로 인한 문제는 쉽게 해결할 수 있다.


    IPv4에서는 보안을 구현하기 위해서는 IPSec, VPN, SSL 등이 별도의 프로토콜을 이용해야 하지만 IPv6는 기본적으로 IPSec이 제공되므로 보안을 구현하기 쉽다. VoIP에서는 사용자의 ID와 패스워드 등이 포함되는 시그널링 메시지와 실제 미디어 스트림, 그리고 사용자 인증 부분에 보안이 필요한데, 이들 데이터들은 VoIP 서버와 단말기 간에 IPv6를 사용함으로써 쉽게 보호할 수 있다.

     

    일정 수준의 QoS 유지해야 하는 VoIP 

     

    VoIP 미디어 데이터는 실시간으로 처리돼야 하고 서비스마다 차별적으로 대역폭을 할당해 서비스를 이용하는 동안 일정한 수준의 QoS를 유지할 수 있어야 한다. IPv4에서는 QoS를 제공하기 위해 패킷의 헤더에 ToS(Type of Service)라는 8비트 필드가 규정돼 있으나 필드가 너무 작고 라우팅시 라우터에서 사용되지 않으며, 여러 가지 문제가 있어 실제로 사용되지 않는다. IPv6에서는 멀티미디어 데이터를 규칙적으로 전달할 수 있도록 고품질 경로를 설정하고, 데이터그램을 그 경로에 연관되도록 허용한다. 이는 고정 지연 시간내에 정보 전달을 보장하고, 데이터의 손실률을 자동으로 점검해준다. 또한 빈번한 라우터 변경을 피하도록 한다. 따라서 IPv4에서 문제가 됐던 네트워크의 음질 저하 문제를 비교적 간단하게 해결할 수 있다.


    VoIPv6는 20004년 우리나라를 비롯한 일본, 유럽 등에서 관심을 가지고 다양한 애플리케이션 기술을 개발했다. 2003년 한국전산원은 VoIPv6 관련 기술들을 개발하고 VoIPv6 시범 서비스를 제공했는데, 이는 PDA가 무선 LAN 환경에서 VoIPv6를 이용할 수 있도록 SIPv6 기반의 VoIPv6 단말과 모바일 IPv6, 고속 핸드오프(Fast handoff) 등 여러 기술을 사용했다. 이미 2004년에는 IPv6 도입을 촉진하기 위해 KOREAv6 시범 서비스가 7월부터 시작돼 삼성전자 등 3개 업체가 VoIPv6 서비스를 수행했다. 이 시범 서비스는 IPv6를 이용한 IPv6 인터넷 서비스와 PDA형 단말을 이용한 화상 통화 기능 VoIPv6 서비스, 무선 LAN IP 폰, PDA형 단말을 통합한 VoIPv6 서비스를 제공하며, IPv6 기반의 유무선, 음성 데이터 통합 서비스 활성화에 기여할 것으로 보인다.

     

     

     

    텔레매틱스

     

    텔레매틱스 서비스는 통신(Telecommunication)과 정보자동화(Infomatics)가 조합된 말로, 휴대폰과 같은 통신 기술과 컴퓨터의 정보처리 기술을 연계해 제공되는 정보 서비스 체계이다. 하지만 일반적으로는 이동통신 네트워크를 이용한 자동차용 차세대 정보 제공 서비스를 의미한다. 텔레매틱스는 위치 확인 시스템과 무선 통신망을 이용해 자동차 운전자에게 교통 안내, 긴급 구난 정보를 제공하고 동승자에게 인터넷, 영화, 게임 등 인포테인먼트 서비스를 제공한다. 따라서 이전의 자동차 내비게이션과는 달리 양방향 통신을 지원하는 실시간 정보 서비스가 이뤄진다. 텔레매틱스 서비스는 자동차, 이동통신단말, GPS, 소프트웨어, 컨텐츠, 방송 등 다양한 산업 분야에 엄청난 파급효과를 미칠 것으로 예상된다. 

     

     

     

    RFID

     

    RFID(Radio Frequency Identification)는 전자칩을 부착하고 무선 통신 기술을 이용해 사물의 정보를 확인하고, 주변 상황의 정보를 감지하는 센서 기술이다. 정통부는 2004년 2월 u-센서 네트워크 구축 기본 계획을 통해 언제 어디서나 어떤 사물과도 정보를 주고 받는 유비쿼터스 네트워크 구현을 국가 전략으로 추진하게 됐는데, u-센서 네트워크 핵심 기술이 바로 RFID 기술이다. 현재 상용화돼 있는 RFID 태그는 생산에서 판매에 이르는 전 과정의 정보를 초소형 IC 칩에 내장시켜 이 정보를 근거리 무선 통신 등으로 활용하는 수준이지만, 앞으로 RFID 기술의 발전으로 기본적인 사물 인식뿐만 아니라 주변의 환경 정보를 탐지하고 얻은 정보를 네트워크를 통해 교환하는 USN(Ubiquitous Sensor Network)으로 발전할 것이다.


    RFID 리더는 네트워크와 연결돼 정보를 처리하거나 인증하는 역할을 하므로, 각각 많은 수의 IP 어드레스를 필요로 한다. RFID 활용 서비스에 IPv6를 적용하면 향후 각종 응용 분야를 구현하기 쉬워진다. 또한 RFID는 앞으로 기본적인 사물 인식 정보뿐만 아니라 다양한 주변 상황 정보까지 전송하는 역할을 한다. RFID가 USN의 핵심 기능을 수행하기 위해서는 IPv6가 절대적으로 필요하다. IPv6를 적용함으로써 다수의 RFID가 IPv6 어드레스 체계를 가지고 개별적으로 정보를 전달할 수 있으며, 적절한 사용자만이 정보를 얻을 수 있는 보안 문제를 해결하기 쉽다. 또한 통신 과정에서 효율을 높이고 무선 통신에서의 장점까지 활용할 수 있다. 텔레매틱스나 홈 네트워크 등의 대규모 서비스와 연동하는데에도 IPv6가 효과적이다.

     

    사용자 삽입 이미지

     

    BcN

    BcN(Broadband convergence Network)은 통신, 방송, 인터넷이 융합된 품질 보장형 광대역 멀티미디어 서비스로, 언제 어디서나 끊김없이 안전하게 이용할 수 있는 차세대 통합 네트워크다. 디지털 정보 기술의 발전으로 음성, 데이터, 영상, 멀티미디어 등 모든 형태의 정보는 디지털화되고 컴퓨터의 소형화, 다기능화, 컴퓨팅 파워의 증대 등으로 저비용, 대용량 정보 처리가 가능하다. 또한 네트워크 기술과 성능의 발전으로 그 적용 범위도 가전, 자동차, 영상, 컨텐츠, 센서 등 거의 모든 분야로 확대됐다.


    IPv6는 기존의 인터넷 보다 보안성이 뛰어나고 이동성을 지원하는 QoS에 대한 고려가 가능하다. 이는 BcN이 추구하는 광대역 통합 망의 기본 기술이다. 모든 데이터가 BcN을 기반으로 전송된다면, 이동성과 품질은 IPv6를 이용해 쉽게 구현될 수 있다. 또한 BcN 환경에서 보안 침해가 일어날 경우에는 그 피해가 광범위하게 확산될 우려가 있으나 IPv6는 기본적으로 보안성이 뛰어나므로 이를 쉽게 해결할 수 있다.


    향후 대부분의 네트워크는 IP를 수용하면서 인터넷은 모든 정보통신 서비스를 제공하는 종합 전달 망으로 성장할 전망이다. 그리고 IPv6는 음성, 데이터와 유선, 무선의 통합과 통신, 방송의 융합을 추진하는 BcN 구축의 기반이 될 것이다. All-IP 시대를 준비하기 위해서는 IPv6는 선택 사항이 아니라 필수 사항이 될 것이다

      Comments,     Trackbacks
    [기업 환경에 닷넷 적용하기] ③ 솔루션 패턴 해부하기

    [기업 환경에 닷넷 적용하기] ③ 솔루션 패턴 해부하기

     

    연재순서
    1.제대로 된 컴포넌트를 위한 프리젠테이션 레이어 설계하기
    2.비즈니스 로직 레이어 설계와 물리적 구현을 위한 필요 사항
    3.엔터프라이즈 솔루션 패턴 해부하기
    4.닷넷의 웹 프리젠테이션 패턴
    5.닷넷 개발에서 UML과 케이스 툴의 사용

     

    디자인 패턴은 양날의 검이다. 최근 들어 특히 패턴을 최대한 반영하지 않은 것이 차라리 좋은 설계라는 말이 공공연히 나돌고 있으며, 안티 패턴 웹 사이트도 생겨나고 있다.

    하지만 패턴은 엔터프라이즈 솔루션을 설계하고 작성할 때 그리고 결정 사항들을 효율적으로 공유하기 위한 목적으로 사용될 때 프로젝트의 성공에 기여할 수 있는 훌륭한 선물이 된다. 이번 호에서는 닷넷 기반 기업용 응용 프로그램의 설계와 구현에서 사용될 수 있는 디자인 패턴들에 대해 살펴보자.

    디자인 패턴은 버클리 대학 명예 교수이자 건축가인 크리스토퍼 알렉산더에 의해 처음 제안된 개념이다. 알렉산더 교수는 패턴을 다음과 같이 정의했다.

    “각각의 패턴은 우리를 둘러싸고 있는 환경에서 반복적으로 나타나는 특정한 문제와 그에 대한 해결책을 설명한다. 그리고 그 해결책은 계속 사용될 수 있기 때문에 동일한 과정을 반복할 필요가 없다.”

    알렉산더 교수는 여러 책을 저술했는데, 『The Timeless Way of Building』과 『A Pattern Language』등에서 그의 세계관을 철학적으로 풀어냈다. 소프트웨어 설계에서 나타나는 패턴은 결국 건축가인 알렉산더 크리스토퍼의 아이디어에서 나온 것이며, 켄트 벡과 커닝헌에 의해 소프트웨어 세계로 끌어들였고, 에릭 감마를 위시한 네 명의 일당들(Gangs of Four, 이하 GoF)이 전산에서의 디자인 패턴을 정리했다. 곧, 소프트웨어 전문가들은 패턴의 가치를 디자인 경험을 공유하기 위한 언어로 인식하였다.

    엔터프라이즈 솔루션들은 매우 복잡하다. 또한 솔루션이라도 시간과 의뢰인에 따라 시시각각 변화하는 요구사항을 모두 만족하기에는 거의 불가능하다. 지금 설계 또는 작성하고 있는 솔루션의 요구사항이 어떻게 변화할지 정확하게 예측하지는 못한다 하더라도 앞으로의 변화에 대해 적응하고 확장 가능할 수 있도록 작성되어야 한다. 그렇다면 설계자 또는 개발자는 어떻게 설계하고 코드를 작성하는 것이 좋은 설계인지에 대해 의문이 생기게 된다. 지금 작성하고 있는 설계 문서 또는 코드가 바른 설계인지 나쁜 설계인지 믿을 수 없다는 것이다.

    이런 경우, 설계자에게 오아시스 같은 해답을 내려줄 수 있는 것이 바로 ‘디자인 패턴’이다. 문제를 해결하기 위한 간단하고 작은 메커니즘에서 시작하여 크고 복잡한 시스템으로 결합되는 형태의 여러 디자인 패턴들은 경험 많은 개발자들과 설계자들의 노력 및 시행착오 속에서 정립된 것이고, 그들의 갖은 노하우에서 비롯된 귀중한 지식들이자 산출물이다.

    누군가 이름붙인 특정 디자인 패턴을 그대로 도입한다고 해서 문제가 곧 해결되는 경우는 드물지만, 디자인 패턴들은 좋은 설계와 코드 구현의 올바른 가이드가 되어줄 수 있다. 또한, 패턴은 간단한 메커니즘을 문서화할 수 있어 업데이트와 후임 개발자들의 소중한 교육 자료로 활용될 수 있다.

    디자인 패턴은 마이크로소프트(이하 MS) 플랫폼 기반 개발에서는 그다지 중요한 역할을 해오지 않은 것 같아 보였다. 하지만 주로 객체지향 환경에 맞춰진 디자인 패턴을 비주얼 베이직에서 활용하는 방법에 대한 연구 등이 활발하게 이뤄졌고, GotDotNET 등의 여러 커뮤니티에서는 몇 해 동안 시스템 아키텍처와 소프트웨어의 개발에 적용되는 패턴들을 발견해 왔다. 또한 MS는 여러 고객과 파트너 기업, 그리고 내부 개발자들의 피드백에 의해 MS 플랫폼에 특화된 디자인 패턴들을 정리할 필요가 있다고 느꼈다. 그 산물이 바로 ‘엔터프라이즈 솔루션 패턴(Enterprise Solution Patterns)’이다.

    MS는 몇 년 전에 닷넷 엔터프라이즈 아키텍처 센터(.NET Enterprise Architecture Center)를 통해 이 디자인 패턴들을 정리해서 공개했고, MSDN 웹 사이트의 「Enterprise Solution Patterns Using Microsoft.NET(참고자료)」을 통해 이를 확인해 볼 수 있다. 여기서는 단지 이 패턴들을 정리 요약하고, 이런 패턴들을 적용해 설계 및 작성해 본 경험을 풀어보고자 한다. 필자가 참여한 몇몇 기업용 응용 프로그램에서 이 패턴들은 솔루션의 재사용성과 확장 가능성을 높이는데 커다란 기여를 했다. 이번 호에서는 이러한 엔터프라이즈 솔루션을 작성하기 위한 패턴이 어떻게 구성되는지에 대해 알아보도록 한다.

    디자인 패턴 책을 달달 외운다?
    먼저 디자인 패턴과 관련해서 겪은 몇 번의 황당한 얘기들로 시작해 보자. 필자가 근무하는 기관에서 개발자를 고용하기 위해 공고를 내고 몇 번의 면접을 실시했다. 면접을 본 몇몇 개발자들에게 디자인 패턴에 대해 아느냐고 물어봤다. 한 개발자는 당연한 듯이 “그건 기본 아닙니까?”라고 당당하게 얘기하기에 패턴 기반 프로그래밍의 경험이 아주 풍부할 것으로 생각하고 이야기를 계속 진행하다보니, 그가 이야기하는 디자인 패턴은 웹 디자인을 이야기하는 것이었다. 다른 개발자는 디자인 패턴이라는 말이 나오자마자 GoF의 『디자인 패턴』에 나오는 패턴의 이름들을 좔좔 외워댔다. 디자인 패턴의 이름을 다 외우고 있는 건 좋은데, 어떤 경우에 어떤 패턴을 적용했느냐는 질문에는 대답하지 못하고, 다음과 같은 대답이 돌아왔다.


    “그냥 책 사서 책대로 코드만 짜봤습니다”


    패턴 기반 개발 경험이 많은 개발자들은 패턴을 익히는 것은 바둑에서 정석을 익히는 것과 같다고 이야기한다. 바둑에서 정석의 이름을 외우거나 내용을 암기하는 것은 실전에 아무런 도움이 되지 못하듯이 패턴의 기계적 학습은 실무에 아무런 도움을 주지 못한다고 이구동성으로 이야기한다. GoF는 소프트웨어 디자인 패턴을 다음과 같이 이야기한다.

    “설계 패턴은 객체지향 시스템 안에서 반복해 등장하는 설계와 관련된 문제들을 해결하기 위한 일반적인 기법에 이름을 붙이고 동기를 부여하고 설명을 한다. 그것은 문제와 해결책을, 그리고 그 해결책을 언제 적용해야 하는지, 적용한 결과는 무엇인지 등을 설명한다. 또한 실질적인 구현에 대한 힌트와 예제도 제공한다. 해결책은 문제를 해결하기 위한 필요한 객체와 클래스를 일반적인 방식으로 배치한다. 해결책은 주어진 문제를 특정한 문맥 안에서 해결하기 위해서 다듬어지고 구현된다(참고자료)”

    중요한 것은 패턴의 이름이나 구현된 코드가 아니라 그 이름이 담고 있는 내용이라는 것이다. 패턴은 소프트웨어의 설계에서 어떤 문제에 직면했을 때, 그 문제가 주어진 환경 내에서 반복하여 발생되는 것이라면, 그 문제를 기술하고 그 문제에 대한 솔루션을 제시해주는 역할을 한다. 패턴 기반 프로그래밍에서 가장 중요한 것은 특정 패턴이 어떻게 생겼느냐, 그 패턴의 이름은 무엇이냐, 그 패턴에 참여하는 객체들은 어떤 역할로 구성되느냐 하는 것이 아니고 당면한 문제가 무엇인지를 파악하는 것이다.

    패턴은 어떠한 환경에서 자주 발생하는 문제들을 해결하기 위한 솔루션을 제시하고, 그 솔루션은 문제를 해결하기 위해서 함께 동작하는 두 개 이상의 클래스, 객체, 서비스, 프로세스, 서비스, 쓰레드, 컴포넌트, 노드 등이 유기적으로 엮여 있는 간단한 메커니즘일 뿐이다.

    설계 패턴들은 ‘문제-해결책’의 쌍으로 제공되고 이해되어야 한다. 특히 디자인 패턴을 처음 접하는 개발자들은 어떠한 문제를 해결하건 간에 설계 패턴을 활용해야 한다는 강박증에 사로잡혀 있는 경우가 많다. 하지만 설계 패턴을 적용하지 않고도 해결할 수 있는 그것을 적용하지 않는 것이 바람직한 설계가 되는 경우가 대부분이다. 문제를 파악하는 것이 설계에서 가장 중요한 요소가 되고, 어떠한 패턴을 적용할 것인지는 그 다음에 생각할 문제가 되어야 한다.

    MS의 「Pattern & Practice」에서는 시스템 내의 모든 쿼트(Quote)들을 관리하는 프로그램의 예를 설명하면서singleton 패턴을 예로 들어 설명한다. 전체 시스템에서 인용부호는 수도 없이 등장한다. 쿼트 하나를 관리하기 위해서 하나의 인스턴스를 생성하는 것은 틀림없는 낭비이다. 이런 경우, 시스템 내의 모든 인용부호는 오직 하나의 클래스 인스턴스에서만 관리되도록 설계되어야 한다. 이 문제에 대한 간단한 해결책은 다른 클래스가 해당 클래스를 생성할 수 없도록 생성자가 Private인 QuoteManager 클래스를 생성하도록 설계하는 것이다. 이런 식의 ‘문제-해결책’의 쌍으로서 Singleton 패턴을 살펴보자.


    ◆ 상황 : 초기화 과정을 제어함으로써 클래스에 대한 액세스를 제어한다.
    ◆ 문제 : 응용 프로그램은 전역적으로 접근되거나 유지되어야 하는 특정한 형식의 데이터를 포함한다. 동시에, 종종 이 데이터 형식은 시스템 내에서 고유하다. 어떻게 하면 클래스에 대한 액세스 가능한 인터페이스를 제공하면서 시스템 내의 인스턴스의 수를 제어할 수 있을까?
    ◆ 솔루션 : 클래스는 단일 인스턴스를 생성하고 해당 인스턴스에 대한 전역적인 액세스를 제공해야 한다. GetInstance라는 정적 메쏘드가 반환하는 Singleton 클래스의 정적 인스턴스를 포함하는 클래스를 생성한다.


     

    사용자 삽입 이미지
    <그림 1> 클래스 설계


    여러 설계 패턴들은 이러한 문제-해결책 형태로서의 쌍으로 인식되어야 한다. 예로 보여준 Singleton 패턴을 닷넷 기반 개발에 적용하여 사용하는 방법은 무엇일까? 그것은 닷넷 개발자들이 알아서 해야 할 일이다. <그림 1>과 같이 설계된 구조라면 구현하는 것은 그리 어렵지 않다. 패턴 기반 개발에서 가장 중요한 것은 문제를 제대로 파악하는 것이다. 어떤 패턴을 적용하여 개발할 것인가 하는 것은, 문제가 제대로 파악된 다음에 생각해야 한다.

    패턴의 추상화 수준
    설계 패턴을 공부하기 위해 가장 많이 접하게 되는 책, 설계 패턴의 바이블이기도 한 GoF의 『디자인 패턴』은 주로 코드 차원에서의 설계 패턴들을 다루고 있다. 앞에서 예로 들었던 Singleton 패턴 역시 코드 수준에서 생각할 수 있는 패턴들이다. 그래서 설계 패턴이라고 하면 GoF가 정리한 패턴 위주의 코드 수준 활용을 생각하기가 쉬운데, 응용 프로그램의 추상화 수준이 여러 단계 이듯이 설계 패턴에서의 추상화 수준도 존재한다. 다음과 같은 상황에 처해있다고 하자.

    상황 :크고 복잡한 시스템을 다루고 있으며, 시스템을 분해하여 복잡성을 관리하고자 한다.

    이 상황에서 시스템 복잡성을 어떻게 관리할 것인가 하는 것이 문제로 던져진다. 솔루션을 잘 작성하기 위해 다음과 같은 문제를 제시할 수 있다.

    질문 :유지 보수 가능, 재사용성, 확장성, 견고성, 보안과 같은 기능적인 요구사항들을 만족하기 위하여 응용 프로그램을 어떻게 작성할 것인가?

    원망같이 들리는 저 ‘어떻게’를 위하여 수없이 많은 개발자들이 밤 새워가며 고민들을 했을 것이다. 이 문제를 해결하기 위해 제시되는 것은 의존성 관리와 상호 교환이 가능한 컴포넌트의 사용이라는 간단한 방법이다. 이 문제는 『Pattern & Oriented Software Architecture』에 소개된 Layers 패턴을 적용하여 해결할 수 있다.

    해결책 :솔루션을 계층 집합으로 구성한다. 각 계층은 반드시 응집되어야 하고 동일한 추상화 수준이어야 한다. 각 계층은 아래 계층과 느슨한 결합(Loosely Coupled)으로 이루어져야 한다.

    사용자 삽입 이미지
    <그림 2> Layers 패턴


    구현은, 물론 특정 플랫폼 하에서 개발하는 개발자들의 몫이 된다. 닷넷 플랫폼 기반 개발이라면 이러한 구현은 너무도 간편하게 할 수 있다. 이러한 높은 수준의 메커니즘은 앞에서 예제로 살펴본 Singleton 패턴의 메커니즘보다 훨씬 복잡하다(물론 GoF의 여러 패턴 중에서 Singleton 패턴이 가장 간단한 구조를 가지고 있긴 하다).

    Layers 패턴의 경우, 장점은 계층화된 조직이 소스 코드의 변경 효과를 코드가 속한 계층에 국한시켜, 전체 시스템에 영향을 주는 것을 막아준다. 이는 각 계층 간의 의존성 관계를 잘 설계함으로서 가능해진다. 각 계층 내의 독립적인 컴포넌트들이 시스템의 다른 영역들과의 충돌을 방지해 주는 메커니즘을 가지게 된다. Layers 패턴은 일반적으로 네트워크 프로토콜, 시스템 소프트웨어, VM 등과 같은 분야에 활용된다.

    하지만 Layers 패턴이 모든 문제를 해결해 주지는 못한다. 특히, 기업용 응용 프로그램 분야에서 개발자들은 비즈니스 로직을 효율적으로 관리할 수 있도록 해야 하고, 데이터베이스와 같이 복잡하고 가변적이며 비싼 리소스를 활용해야 한다. 비즈니스 솔루션들은 비즈니스 로직을 효율적으로 사용하고 데이터베이스 리소스를 관리하는 것이 관건이 되므로 Layers 패턴은 기업용 응용 프로그램을 작성할 때 당면하는 문제에 대한 해결책이 되어 줄 수가 없게 된다. 그러면 다음과 같은 상황에 직면한다.

    상황 :응용 프로그램을 구성하기 위해서 계층을 사용하는 비즈니스 솔루션을 작성하고 있다.

    상황에 직면하면 다음과 같은 문제가 제시된다.

    문제 :비즈니스 로직을 재사용하고 융통성 있는 배포를 제공하며 데이터베이스와 같은 리소스에 효율적으로 연결하기 위하여 응용 프로그램을 어떻게 구성할 것인가?

    해결책은 여러 가지 생각해 볼 수 있겠지만, 이러한 문제에 대한 해결책을 제시해 주는 패턴은 Therr-Layered Application 패턴이다.

    해결책 :프리젠테이션, 비즈니스 로직, 데이터액세스라는 3계층을 생성한다. 각 계층은 다음과 같이 구성한다.


    ◆ 프리젠테이션 계층 - 뷰와 관련된 모든 컴포넌트를 이 계층에 위치시킨다.
    ◆ 비즈니스 계층 - 비즈니스 로직을 구현하는 모든 컴포넌트들을 이 계층에 위치시킨다.
    ◆ 데이터 액세스 계층 - 데이터베이스 클라이언트 액세스와 헬퍼 클래스들을 포함한 모든 데이터베이스 관련 코드를 이 계층에 위치시킨다.


    각 계층을 구성할 때 주의 사항은 다음과 같다.


    ◆ 비즈니스 로직의 컴포넌트는 잘 알려진 인터페이스(닷넷의 예를 들면 리스트를 표현하는 IList 인터페이스 등)를 구현하게 구성하여 각 계층 간의 통합 가능성과 교체 가능성을 높이도록 설계한다.
    ◆ 데이터 액세스 계층은 리소스를 관리할 때 커넥션 풀링을 처리할 수 있어야 하며, 비즈니스 계층의 컴포넌트들과 상호의존 관계를 가져서는 안된다.


     

    사용자 삽입 이미지
    <그림 3> Three Layered Application 패턴


    이런 구현은 너무도 당연시 되는 구조이지만 문제를 생각하지 않고 무조건 이런 구조를 따라 설계하거나, 이런 문제가 제시됨에도 불구하고 이러한 구조를 따르지 않는 경우가 허다하다. 무조건 이러한 패턴을 따르는 것이 정답이라는 것은 아니지만, 경험 많고 능력 있는 개발자들이 정리한 이러한 패턴에 따라 문제를 해결하는 것이 대부분의 경우 정답이 되어준다.

    잊지 말아야 할 것은 패턴과 패턴 응용 프로그램을 잘 구분해야 한다는 것이다. 패턴 그 자체가 응용 프로그램일 수는 없다. 패턴은 문제-해결책 쌍으로서의 일반화된 해결책일 뿐이다. 그 문제의 해결책인 패턴을 응용하여 작성된 프로그램이 패턴 응용 프로그램이 된다. 패턴은 일반화된 문제 해결책 모음이고, 특정 요구사항을 특정 패턴을 사용하여 특정한 문제를 해결한 것이 패턴 응용 프로그램이라는 것을 알고 설계해야 한다.

    Three-Layered Application 패턴을 조금 응용하면 더 확장성 높은 응용 프로그램을 만들 수 있다. 최근 크게 이슈화되고 있는 웹 서비스 응용 프로그램을 생각해 보자. 작성한 응용 프로그램을 스마트 클라이언트에서 동작하게 한다거나 언제, 어디서든 실행될 수 있는 웹 서비스 응용 프로그램으로 확장해야 할 필요가 있을 때, Three-Layered Application 패턴을 활용하기가 곤란해진다. 그렇다면 다음과 같은 질문이 대두된다.

    문제 :응용 프로그램이 매우 유동적인 소스로부터 데이터와 논리적인 요소들을 제공하고 사용하기 위해서 응용 프로그램을 어떻게 구성해야 할까?

    해결책은 Three-Layered Service Application 패턴이 제시한다. 문제 해결을 위해서 비즈니스 계층이 서비스를 제공하는 Service Interface들을 제공하는 것이다. 또한, 유동적인 데이터 소스로부터 데이터를 제공받기 위해서 데이터 액세스 컴포넌트들이 아닌 서비스 에이전트 컴포넌트들로부터 소스를 제공받을 수 있도록 설계하는 것이 해결책이다.

    해결책 :응용 프로그램의 로직을 전체 시스템 기능의 일부를 제공하는 협력 서비스 집합으로 분해시킨다. 다음으로 도메인 계층에서 내부 구현에 독립적인 각각의 서비스에 대한 Service Interface를 명시한다. 마지막으로 다른 서비스 제공자와 커뮤니케이션하기 위하여 Service Agent를 사용하기 위해서 데이터 액세스 계층을 확장한다.

    사용자 삽입 이미지
    <그림 4> Three-Layered Services Application 패턴


    Three-Layered Service Application 패턴은 연재 첫 회에서 살펴보았던 응용 프로그램 아키텍처의 구조와 거의 일치한다. 물론, 응용 프로그램의 요구사항이 유동적인 소스로부터 데이터를 제공받거나 유동적인 클라이언트에 서비스를 제공하는 경우가 아니라면 Three-Layered Application 패턴으로 충분하다.

    패턴 클러스터
    지금까지 살펴본 바와 같이 Three-Layered Services Application 패턴은 Three-Layered Application 패턴에서 확장되었고, Three-Layered Application 패턴은 Layers 패턴에서 확장되었다. Layers 패턴의 변형은 응용 프로그램의 계층화에 대한 공통적인 접근 방법을 표현하는 패턴 클러스터를 구현한다. 패턴 클러스터링은 이러한 상황에서 그룹지어질 때 유사한 패턴 간의 논리적인 그룹화를 의미하게 된다. 패턴을 굳이 그룹화하여 분류할 필요는 없지만, 이런 클러스터된 패턴의 개념은 전체 응용 프로그램을 구성하기 위해 패턴 뷰를 확장하고 솔루션 영역에서 유사한 개념을 설명하는 패턴 클러스터를 명시할 때 상당히 유효할 뿐만 아니라, 프로젝트에 새로 투입되는 개발자의 교육 자료로도 훌륭히 활용된다.

    사용자 삽입 이미지
    <그림 5> Layers 패턴에서 확장되는 패턴 클러스터


    GoF가 정리한 디자인 패턴을 살펴보면 각 패턴들은 생성, 구조, 동작 등의 세 집합으로 분류된다. 객체를 생성하는 작업을 위해서라면 추상 팩토리 패턴이나 singleton 패턴을, 구조를 결정해야 한다면 Composite 패턴이나 Facade 패턴을, 동작을 결정하는 작업이라면 Visitor 패턴이나 Observer 패턴을 사용할 수 있다.

    또한 각각의 패턴들은 다른 패턴들과 관계를 가지고 여러 가지의 패턴을 묶어 다른 하나의 패턴으로 사용하기도 한다. Observer 패턴은 MVC(Model-View-Controller) 패턴의 일부분을 구현하기 위해서 사용되고, Command 패턴은 Front Controller 패턴의 일부 구현에 사용된다. 이런 패턴들 간의 관계가 없다면, 엄청난 패턴의 바다에서 표류하게 될 가능성이 높다. 객체지향 프로그램 개발자들이 패턴을 받아들인 이유는 패턴이 관계들을 기술할 수 있기 때문이다.

    이렇듯이 패턴 간의 관계를 도표화하면 하나의 패턴에서 그와 관련된 다른 패턴을 찾아 응용 프로그램을 구성하는데 큰 도움을 준다. 하지만 응용 프로그램을 작성하기 위해 어디에서 어떻게 시작해야 할지에 대해서는 알려주지 않는다. 하지만 단순히 분류에 그치지 않고 <그림 5>처럼 패턴을 클러스터링하면, 어떤 패턴에서 응용 프로그램을 시작하여야 할지를 잘 알 수 있게 된다. MS의 「Patterns & Practices」에서는 현재 크게 다섯 가지의 패턴들을 분류한다.


    ◆ Enterprise Solution Patterns Using Microsoft .NET
    ◆ Data Patterns
    ◆ Integration Patterns
    ◆ Describing the Enterprise Architectural Space Testing Software Patterns


    가장 유명하며, 가장 많이 활용되는 Enterprise Solution Patterns using Microsoft .NET에서는 현재 <표 1>과 같은 패턴 클러스터들을 구분하고 있다.

    사용자 삽입 이미지
    <표 1> Enterprise Solution Patterns using Microsoft .NET의 패턴 클러스터


    또 반드시 알아야 할 것은, 각 패턴들은 서로 다른 추상화 수준에 존재한다는 것이다. 개발자는 수없이 많은 페이지에 대한 요청을 중앙 집중화하기 위하여 Front Controller 패턴을 가장 효율적으로 구성하는데 관심이 많겠지만, 설계자는 Layers 패턴을 사용할 것인지 Three-Layered Application 패턴을 사용할 것인지에 관심이 많을 것이다. MS의 「Pattern & Practice」에서는 이러한 서로 다른 추상화 수준에서의 분류를 패턴 그래프를 이용해서 세 가지 계층으로 구분한다.

    사용자 삽입 이미지
    <그림 6> 추상화 수준(출처 :참고자료)


    Architecture 수준의 패턴은 MS의 「Architecture Center(참조자료)」을 참조하기 바란다.

    구현 수준 패턴
    패턴의 집합들을 <그림 6>과 같이 세 가지 추상화 수준으로 나누면 개발에 참여하는 설계자, 개발자 등의 다른 사용자 그룹이 자신의 전문적인 기술에 관련된 패턴을 쉽게 찾아볼 수 있게 된다.

    모든 언어 또는 플랫폼에서 사용할 수 있는 패턴들이 아닌, C#이나 닷넷 플랫폼 같은 특화된 언어 또는 환경 특화된 패턴을 idiom이라고 부른다. MS의 Enterprise Solution Patterns Using Microsoft .NET에서는 모든 응용 프로그램 개발 단계를 아우르기 위한 집약적인 시스템을 위해서 구현 수준 설계 패턴들을 정리했다. Enterprise Solution Pattern에 등장하는 거의 모든 패턴들은 구현 수준의 패턴에 해당한다. Enterprise Solution Pattern의 한 클러스터인 Web Presentation Pattens 다음 패턴들은 모두 구현 수준의 패턴들이다.


    ◆ MVC 패턴
    - 문제 : 개별적인 부분을 쉽게 수정하기 위해서 웹 응용 프로그램의 사용자 인터페이스 기능을 어떻게 모듈화 할 것인가
    ◆ Page Controller 패턴
    - 문제 : 코드 중복을 피하여 재사용과 융통성을 갖기 위해서 어느 정도 복잡한 웹 응용 프로그램에 대한 컨트롤러를 구성하기 위한 최상의 방법은 무엇인가?
    ◆ Front Controller 패턴
    - 문제 : 코드 중복을 피하여 재사용과 융통성을 갖기 위해서 아주 복잡한 웹 응용 프로그램에 대한 컨트롤러를 구성하기 위한 최상의 방법은 무엇인가?
    ◆ Intercepting Filer 패턴
    - 문제 : 웹 페이지 요청에 대하여 공통적인 선행 처리와 후행 처리 단계를 어떻게 구현할 것인가?
    ◆ Page Cache 패턴
    - 문제 : 자주 요청되지만 생성하기 위해서 엄청난 시스템 리소스를 소비하는 동적으로 생성되는 웹 페이지의 응답 시간을 어떻게 줄일 수 있을 것인가?
    ◆ Observer 패턴
    - 문제 : 다른 클래스에 의존하기 않고 다른 객체의 상태가 변경되었음을 어떻게 알릴 수 있을까?


    각 패턴의 상세한 사항들은 다음 호에서 상세히 알아보도록 한다.

    연구된 모든 패턴은 닷넷에서 구현된다
    경험 많은 개발자라면 프로그램을 설계할 때 예전에 했던 일을 그대로 반복하고 있다는 느낌을 받을 때가 많다. 경험이 축적되면, 그 경험을 살려서 다음 개발에 적용할 때가 있다. 설계 패턴(디자인 패턴)은 이러한 경험과 내공을 정리한 것에 지나지 않는다.

    학생들이 프로젝트를 진행할 때 if문으로 점철된 너무 복잡한 코드를 쓰는 경우가 많다. 그런 경우 필자는 “이런 경우에는 이런 패턴을… “ 이라는 말로 코드 개선을 요구한다. 보통 학생들은 디자인 패턴이라는 말이 나오면 한숨부터 쉬게 된다. 너무 어렵다는 것이다. 하지만 디자인 패턴은 결코 어려운 것이 아니다. 디자인 패턴이 어렵게 느껴지는 이유는 문제를 파악하려 하지 않고 패턴만을 외우려 하기 때문이다. 꼼꼼한 요구사항 분석으로 문제들을 파악했다면, 패턴 응용 프로그램을 작성하는 것은 전혀 어려운 일이 아니고, 조금 더 많은 생각으로 아주 재사용성과 활용성 높은 프로그램을 작성할 수 있게 된다.

    2년쯤 전, 필자는 어떤 솔루션을 구축하면서 Page Controller 패턴을 활용했다. 코드를 본 다른 회사의 개발자는 “이거 닷넷 구조가 아니고 자바 구조군요 이런 건 처음 봅니다. 아주 재미있네요”라고 이야기했다. 이상하게도 닷넷 개발자들은 디자인 패턴 같은 것은 자바 쪽에서 사용되는 것이라고 생각하는 경우가 많다.

    심지어 국내 굴지의 개발사 사장님은 “자바는 천재들이나 하는 것이고 닷넷은 아무나 할 수 있는 것이므로 닷넷을 하는 게 좋다”라는 망언(?)까지 하셨다.

    연구된 모든 패턴들은 닷넷 환경에서 제대로 구현하고 있고, MS는 커뮤니티를 운영하고 조합하면서 연구된 기술들을 활용하여 닷넷 플랫폼에 특화된 패턴들을 내 놓았다. 이런 패턴들은 별 다른 의심의 여지없이 닷넷 기반 응용 프로그램 개발에 사용될 수 있고, 좋은 성능과 높은 확장성을 기대할 수 있다. MS가 이번에는 제대로 하고 있는 것 같다.@

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

     

    김상훈 (동명정보대학 정보기술원 연구원)

    2005/08/24

     

    사용자 삽입 이미지

     

     

     

     

    원문 :http://www.zdnet.co.kr/builder/dev/dotnet/0,39031607,39136897,00.htm

      Comments,     Trackbacks
    터널 브로커를 이용한 IPv6 고정주소 시범 서비스

    터널 브로커를 이용한 IPv6 고정주소 시범 서비스

     

    수행기관 : (주)유미테크

     

    1. 개요

    IPv4에서 IPv6주소체계로 전환하는 과도기 환경 속에서 두 주소체계의 호환성을 보장해 줄 수 있는 기술 및 장비의 보급으로 국내 인터넷 공간에서 IPv6 주소체계 사용을 확대하고 IPv6 기반의 차세대 인터넷 주소 환경에 대한 기술적 선점 효과와 더불어 제반 운영 노하우 및 인프라를 기반으로 IPv6의 국제적 주도권을 확보하기 위한 기반 제공

     •  현재 해외 업체가 보유한 터널 브로커(Tunnel broker) 관련 기술의 국산화로 기술 자립
     •  IPv4를 사용하는 수천만 호스트들을 간편하게 IPv6로 전환할 수 있도록 유도
     •  Native IPv6로 완전 전환되기까지 IPv4 기반 위에서 안정적인 IPv6 서비스를 가능하게 함

    사용자 삽입 이미지

     

    2. 터널 브로커 개발에 따른 주요 장점

    내홈의 터널 브로커를 이용할 경우 DDNS 기능과 결합된 IPv6 터널 브로커에 의해 OS 제약 문제와 고정된 터널링 IP 위의 문제를 해결 가능

     

    3. 내홈 시범서비스 시스템 구축 및 서비스 제공

    포털에서 할 수 없는 한계점을 극복 • 구현하고 퍼스널 PC에서의 장점을 구현하는 서비스
    고정 IP가 필요함에도 불구하고 유동 IP를 사용하는 고객들을 대상으로 IPv6 보급과 동시에 테스트 하기 위한 서비스를 시작

     

    4. 시범 서비스 망 구성 계획

    일반 고객을 대상으로 다음과 같은 망을 구축한 후 내홈 포탈 서비스 시스템을 설치
    일반 고객에게 클라이언트 프로그램을 배포하여 IPv6 시범 서비스를 제공

    사용자 삽입 이미지

     

    5. 서비스 제공 계획

    o 내홈 서버팩 인스톨 프로그램
       - 내홈 서버팩을 다운로드 받아 자동으로 설치할 수 있는 프로그램

    o IPv6 TSP 클라이언트 프로그램
       - 윈도우 2000/XP에서 자동으로 터널 브로커와 연결한 후 IPv6 터널을 형성,
          IPv6를 사용할 수 있도록 한 프로그램

    o 자카르타 톰캣 웹서버
       - 파워 블로그, 파일 공유, VNC 원격제어 등을 제공하기 위한 웹서버

    o 내홈 파워 블로그
       - 기존 포탈서비스에서 구현할 수 없었던 블로그 포탈로 고객이 직접 구현

    o VNC 원격 제어 프로그램
       - 원격 제어 프로그램으로 내홈 서버팩에서 이를 이용하여 서비스 구현

    o 파일 공유 프로그램
      - 고객이 자신의 내홈 서버팩이 설치되어있는 컴퓨터에 접속하여 파일 공유

     

    사용자 삽입 이미지

    [ IPv6 Nehom의 주요 기능 ]

     

     

      Comments,     Trackbacks
    [특집]IPv6 사례로 본 네트워크 장비별 활용법
    [특집]IPv6 사례로 본 네트워크 장비별 활용법

     

    출처 : 온더넷 7월호

     

    IPv6 전환 기술인 듀얼스택, 터널링, 변환 등을 실제로 적용한 사례는 한국전산원이 운용하는 6NGIX, 6KANet과 한국전산원 원내망을 들 수 있다. 이 사례를 바탕으로 네트워크 장비를 어떻게 IPv6 망에 적용해 활용하고 있는지 알아본다.


    김진대_한국전산원 차세대인터넷팀

    2001년에 구축된 6NGIX(IPv6 Next Generation Internet eXchange)는 국내외 IPv6 망을 상호 연동시키기 위한 IPv6 기반 인터넷 교환 노드이며, 6KANet(IPv6 Korea Advanced Network)은 공공기관과 연구기관에 IPv6 인터넷 서비스를 제공하는 IPv6 가입자망이다. 이는 한국전산원과 그외 국내 산학연 기관이 공동으로, IPv6 기술 개발을 독려하고 국내외 차세대 네트워크 구축 산업과의 연계를 통한 공동 연구 기반을 조성해 IPv6 관련 기술을 시험하고 안정성을 검증하기 위함이다. 2005년 6월말 현재 6NGIX 연동기관은 21개이며, 6KANet 연동기관은 53개이다. 6NGIX와 6KANet외에도 한국전산원은 2003년부터 원내망에 IPv6를 도입해 다양한 IPv6 애플리케이션을 자체적으로 적용해 테스트하고 있다. 이같은 사례를 바탕으로 지속적으로 업그레이드되고 있는 IPv6 전환 기술과 장비별 활용 방법에 대해 자세히 알아본다.

     

    IPv6 전환 기술 적용 사례, 6NGIX·한국전산원 원내망

    한국전산원 원내망은 (그림 1)의 좌측처럼 백본 라우터에서 듀얼 스택으로 IPv6 네트워크를 구성하는 방법도 있으나, 기존에 구성된 네트워크 인프라에 대한 영향을 최소화하고 업무 영역이 다른 부서와의 마찰을 최소화하기 위해 우측의 그림처럼 별도의 IPv6 전용 라우터를 설치해 IPv4 트래픽과 IPv6 트래픽의 경로를 분리해 사용했다. 좀 더 자세한 구성도는 (그림 2)로, 개인이 사용하는 PC부터 백본 스위치 구간은 IPv6와 IPv4 트래픽이 동시에 오가고 백본 스위치에서 IPv6와 IPv4 트래픽이 분리된다.

    이때 생각지 못한 문제점이 발생했는데, 각층의 워크 그룹 스위치는 IPv6 기능이 지원되지 않아 IGMP 스누핑이 enable돼 있는 상태에서는 하단의 PC에서 IPv6 어드레스를 자동 할당받을 수 없고 반드시 IGMP 스누핑 기능을 disable 시켜야만 정상적인 IPv6 통신을 할 수 있다.

    2004년 여름에 6NGIX 성능 고도화를 추진해 6NGIX와 6KANet 백본 구간 성능을 개선하는 작업이 이뤄졌다. 기존 6NGIX용 백본 라우터는 IPv6 패킷을 처리할 수 없으며, 기가비트 인터페이스에서 IPv6 트래픽에 대해 핑 손실이 발생했기 때문이다. 또한 6NGIX 백본 스위치는 워크그룹 스위치나 IX의 백본 스위치로 확장성과 성능이 매우 낮았다.

    2004년 KOREAv6 시범 사업 수행 등으로 기가비트 이더넷을 통한 신규 포트가 증가될 것으로 예상됐으며, KOREAv6 시범사업, IPv6 포털 사이트, P2P와 같은 신규 서비스 개시로 인한 대량의 트래픽 유입이 예상됐다. 기존에 사용하던 IPv6 파이어월은 OpenBSD 기반의 PC 파이어월로, 운영체제에서 기본 기능만 제공돼 정책 설정 등 기타 관리 상의 어려움이 있었다. 또한 IPv6 포털 사이트 대외 오픈시 사용자가 폭발적으로 늘어날 경우 외부 해킹과 유해 트래픽이 대량으로 침투하면 대처할 수 없을 것으로 예상됐으며, 단일 장비로 구성돼 있어 파이어월이 장애를 일으키면 수동으로 절체해야하는 불편함이 있었다.

    사용자 삽입 이미지

    사용자 삽입 이미지

     

    6NGIX 성능 고도화 작업 실시

    이같은 문제점을 해결하기 위해, IPv6 패킷을 하드웨어 방식으로 처리할 수 있으며 라우터 기능을 가진 고성능 백본 스위치를 도입해 기가비트 회선을 연동했으며, KOREAv6, IPv6 포털사이트 등으로 인한 IPv6 트래픽 증가에 대처할 수 있도록 했다. 또한 백본 스위치 중심으로 네트워크 구조를 개편했으며 백본 구간 라우팅 프로토콜을 기존에 사용하던 RIPng보다 더욱 안정적인 OSPFv3를 적용해 네트워크 성능을 향상시켰다.

    백본 구간을 기가비트 이더넷으로 구성해 IPv6 포털, KOREAv6 등으로 인한 트래픽 급증시 백본에서의 병목 현상이 일어나지 않을 정도의 충분한 대역폭을 확보했다. 상용 IPv6 파이어월과 파이어월 관리 서버를 도입해 정책 설정이나 관리 등 관리자의 편의성과 관리의 안정성을 증가시켰으며, VRRP를 이용한 이중화 구성으로 파이어월 장애 발생시 자동으로 절체할 수 있도록 만들어 네트워크의 안정성을 증대시켰다.

    또한 기가비트 이더넷을 수용할 수 있는 파이어월을 도입해 IPv6 서버팜으로 향하는 트래픽 증가시 파이어월에서의 병목현상 발생하지 않도록 했으며, 늘어나는 IPv6 트래픽 안에서 해킹과 유해 트래픽을 효율적으로 차단할 수 있게 됐다(그림 3). 6NGIX와 6KANet 백본 구간에서 IPv6 멀티캐스트와 IPv6 QoS 적용 시험을 실시해 향후 새로운 IPv6 응용 서비스를 6NGIX나 6KANet에 적용하거나 다른 연구 기관들과 공동으로 관련 연구를 수행할 수 있는 기반을 마련했다.

    사용자 삽입 이미지

     

    전환 기술 관련 장비 설정법

    6NGIX와 6KANet 백본 라우터는 모두 듀얼스택 방식으로 서비스를 제공하고 있다. 다음은 6KANet 가입기관 일부에 대한 백본 라우터 설정을 보여주는데 한 인터페이스에 IPv4와 IPv6가 동시에 적용돼 있음을 확인할 수 있다.

    ae0 {
            vlan-tagging;
            unit 32 {
                description XXYY;
                vlan-id 32;
                family inet {
                    address 203.233.X.Y/30;
                }
                family inet6 {
                    address 2001:2b8:2:XX::YY/127;
                }
            }
    -------------------(중략)----------------
            unit 54 {
                description YYXX;
                vlan-id 54;
                family inet {
                    address 203.233.Y.X/30;
                }
                family inet6 {
                    address 2001:2b8:2:Yf::XX/127;
                }
            }

    2004년 초에 6KANet 가입 기관 중 서울 시립도서관을 중심으로 기존에 사용하던 전용회선을 (그림 4)처럼 ATM 메트로 방식으로 전환하는 작업을 수행했다. 이때 IPv4에 대해서는 아무런 문제가 없는데 IPv6에 대해서는 백본 라우터가 BR 모드만 지원해 가상 LAN 번호와 PVC(Permanent Virtual Circuits) 번호를 서로 매칭 시킬 수 없었다. 결국은 (그림 4)처럼 중간에 ATM 인터페이스를 가진 3계층 스위치를 설치해 해결했는데 이런 부분이 IPv6 적용시 유의해야 할 부분이다. 별생각없이 IPv4에 대해서는 당연히 동작하기 때문에 IPv6에 대해서도 문제없이 동작할 것으로 기대하고 접근하다가 장비를 추가로 도입해야만 하는 상황이 발생할 수도 있다. 따라서 필요로 하는 장비 스펙이나 지원하는 기능에 대한 정확한 정보  입수와 사전 시험 수행까지 해보는 노력이 반드시 필요하다.

    사용자 삽입 이미지
    사용자 삽입 이미지

    사용자 삽입 이미지

     

    6to4 클라이언트 단말 설정 방법

    클라이언트에서의 6to4 어드레스는 IPv6 라우터로부터 라우터 광고(Router Advertisement)를 받지 못할 때 생성된다. 라우터 광고를 수신해 IPv6 프리픽스가 설정된다면 글로벌 어드레스를 자동 생성하고 6to4 어드레스는 생성하지 않는다.

    ·윈도우 2000/XP

    윈도우 2000에서는 마이크로소프트에서 제공하는 'service pack 1'과 'IPv6 development Kit'를 차례로 설치한 후, '제어판→네트워크 연결→로컬 영역 연결→속성→설치→프로토콜'에서 'Microsoft IPv6 Protocol'을 선택해 설치하면 IPv6 스택을 설치한다. 만약 윈도우 2000 단말이 라우터 광고를 받지 못한다면 6to4 어드레스를 설정한다. 6to4 어드레스가 설정된 후에는 다음과 같은 방법에 따라 6to4 터널링을 설정한다.

    1) 시작   실행  cmd (enter) 순서대로 실행   ; '명령 프롬프트'를 실행한다.
    2) c:\6to4 cfg -R 203.254.38.130   ; 터널 종단점의 IPv4 호환 어드레스 ::203.254.38.130를 이용해 터널 종단점을 설정한다.
    3) c:\ipv6 rtu ::/0 2/::203.254.38.130 pub life 1800

    ·윈도우 계열에서의 IPv6 관련 설정은 대부분 '명령 프롬프트'에 의해 이뤄진다. 
    ·6to4 터널링 설정을 위해서 우선 터널 종단점을 설정하고, 터널 종단점으로 라우팅을 설정한다.

    윈도우 XP는 '명령 프롬프트'에서 'ipv6 install'을 입력하면 IPv6 스택이 올라가고 윈도우 2000과 같이 프리픽스가 설정돼 있지 않다면 6to4 어드레스로 설정된다. 어드레스 설정이 끝나면 다시 '명령 프롬프트' 창에서 'netsh interface ipv6 6to4 set relay 203.254.38.130 enable'을 입력해 IP 어드레스가 203.254.38.130인 터널 종단점을 설정한다.

    1) 시작   실행  cmd (enter) 순서대로 실행    ; '명령 프롬프트'를 실행한다.
    2) netsh interface ipv6 6to4 set relay 203.254.38.130 enable   ; IP 어드레스가 203.254.38.130인 터널 종단점을 설정해 준다.

    윈도우 XP에서의 IPv6 관련 설정은 윈도우 2000보다 안정적이고 간단하다.

     

    ISATAP 터널링 설정 방법

    ISATAP(Intra-Site Automatic Tunnel Addressing Protocol)는 IPv6 망에 연결된 IPv4 망에서 IPv4/v6 듀얼 호스트가 IPv6 통신을 연결하는 터널링 기법이다. 6to4와 달리 ISATAP은 사이트에 할당된 프리픽스를 사용해 통신하는데, 프리픽스를 제외한 64비트의 인터페이스 식별자는 '0000:5EFE'가 전반부의 32비트를 채우고 뒤의 32비트는 IPv4 어드레스로 설정한다. 시스코 라우터 설정 방법은 다음과 같다.

    1) Router(config)# interface Ethernet 0     ; 'ethernet 0' interface 설정 목록으로 들어간다. 
    2) Router(config-if)# ip address 1.1.1.1 255.255.255.0 ; IPv4 어드레스를 설정한다.
    3) Router(config-if)# exit    ; 'ethernet 0' interface 설정에서 빠져 나온다.
    4) Router(config)# interface Tunnel 0   ; tunnel 0 interface 설정으로 들어간다.
    5) Router(config-if)# tunnel source ethernet 0  ; 터널의 송수신이 'ethernet 0'로 통해서 이뤄지게 한다.
    6) Router(config-if)# tunnel mode ipv6ip isatap  ; 터널링 모드를 ISATAP으로 설정한다.
    7) Router(config-if)# ipv6 address 2001:0DB8::/64 eiu-64 ; IPv6의 프리픽스를 설정한다.
    8) Router(config-if)# no ipv6 nd suppress-ra   ; 라우터 광고를 통해 프리픽스를 단말들에게 알리도록 한다.

    기본적으로 6to4를 설정하는 방법과 동일하며, 다만 'tunnel mode ipv6ip 6to4'를 이용해 터널링 방식을 ISATAP으로 설정했다. 마지막 명령어는 'no ipv6 nd suppress-ra' 라우터 광고를 통해 프리픽스를 단말에 알리도록 설정하는 것이다.
    윈도우 XP 클라이언트 설정 방법은 다음과 같다.

    1) 시작   실행  cmd (enter) 순서대로 실행  ; '명령 프롬프트'를 실행한다.
    2) c:\ ipv6 rlu 2 203.254.38.129   ; ISATAP 터널 종단점을 설정한다.

    '명령 프롬프트'에서 'ipv6 install'를 입력하면 IPv6가 설정되며, 설정과 동시에 'Automatic Tunneling Pseudo-Interface'에 ISATAP이 설정된다. ISATAP 설정이 끝나면 'ipv6 rlu 2 [ISATAP 터널 종단점의 IPv4 어드레스]'를 입력해 ISATAP으로 전송되는 패킷들이 터널 종단점으로 갈 수 있도록 한다.

     

    IPv4 UDP 통신 이용한 전환방법, Teredo

    Teredo는 현재 드래프트 0번까지 제출된 기술로서 아직 많은 논의가 필요하다. 따라서 이 글에서는 Teredo에 대한 개념과 구성 요소까지만 설명한다. Teredo는 NAT 환경에서 IPv4/v6 듀얼 스택 단말이 IPv4 UDP 통신을 이용해 IPv6 통신 연결을 사용하는 터널링 기법이다. 현재까지 나와 있는 터널링 기법 중 유일하게 NAT 환경에서 IPv6 통신을 지원하는 기법으로, 향후 활용 범위가 넓을 것으로 평가된다.

    Teredo 어드레스는 Teredo 프리픽스, Teredo 서버의 IPv4 어드레스, 프래그(flag), 은닉 외부 포트 (Obscured External Port), 은닉 외부 어드레스(Obscured External Address)로 구성된다. Teredo 프리픽스는 IANA에 의해 길이 32비트의 3FFE:831F::로 할당됐다. Teredo 서버의 IPv4 어드레스에는 Teredo 기법을 사용하기 위해 필요한 Teredo 서버의 IPv4 어드레스가 들어간다. 그 뒤에는 16비트의 프래그가 오는데 이는 Teredo와 연동할 NAT 기법의 종류에 따라 달라진다. 은닉 외부 포트 번호에는 단말의 통신 포트 번호로 0xFFFF와 XOR이라고 기입되고, 은닉 외부 어드레스에는 단말의 IPv4 어드레스가 16진수로 변환돼 설정된다. (그림 6)은 Teredo 어드레스를 표현한 것이다.

    Teredo를 사용해 통신을 하기 위해서는 Teredo 클라이언트, Teredo 서버, Teredo 릴레이가 필요하다(그림 7). Teredo 클라이언트는 IPv6 망에 존재하는 IPv6 단말과 Teredo 릴레이를 통해 통신하고자 하는 단말로, Teredo 통신 연결의 초기화를 위해 Teredo 서버와 통신한다. Teredo 서버는 IPv4와 IPv6 모두에 연결돼 있으며, 기본 기능은 Teredo 클라이언트가 다른 Teredo 클라이언트 혹은 IPv6 전용 단말과 통신하기 위한 초기화 작업을 한다. Teredo 릴레이는 NAT를 거쳐서 전송된 Teredo 패킷을 IPv6 패킷으로 변환해 IPv6 망으로 전달하는 역할을 담당한다.
    윈도우 XP의 Advanced Networking Pack을 설치하기 위해서는 윈도우 XP 서비스 팩 1을 우선 설치해야 한다. Advanced Networking Pack은 마이크로소프트의 홈페이지에서 다운로드 받을 수 있다.

    1) 시작   실행  cmd (enter) 순서대로 실행   ; '명령 프롬프트'를 실행한다.
    2) netsh interface ipv6 set teredo client teredo.ngix.ne.kr 60 34567  ; 단말이 teredo.ngix.ne.kr의 어드레스를 갖는 Teredo 서버를 사용하고, 60초마다 재설정하면서 34567번 포트를 이용해 통신하도록 설정한다.

    지금까지 IPv6 네트워크를 구축하기 위한 장비 설정법이나 전환 사례를 살펴봤다. 아직은 IPv6 기능이 일반화되지 않아 IPv6 전환시 예상치 못한 문제점이 발생하는 경우가 많은데 네트워크 관리자의 입장에서 IPv6 장비를 도입할 때 유의할 점을 정리해 보면 다음과 같다.

    첫째, 아직은 IPv6 MIB 제공하지 않는 장비가 많으므로 IPv6 트래픽 모니터링이 가능한지 확인해야 한다. 둘째, 구현된 IPv6 관련 기능에 대한 사전 검증시험이 필요하다. IPv4에서는 당연히 되는 기능이 IPv6에서는 안되는 경우도 많고 장비 소개 문서나 로드맵 상에는 지원된다고 나와있으나 실제 확인해 보면 지원되지 않는 기능이 더러 있으므로 검증 시험이 반드시 필요하다. 셋째, 여러 업체의 유사 장비에 대한 상호 기능을 비교해 꼭 필요한 장비를 선택해야 한다.

    사용자 삽입 이미지
    사용자 삽입 이미지

      Comments,     Trackbacks
    Iperf를 이용한 IPv6 네트워크 성능 측정

    Iperf를 이용한 IPv6 네트워크 성능 측정

     

     

    IPv6 네트워크를 구성하고, IPv6 네트워크의 성능이 어느정도 나오는지 궁금한 경우가 많다. 이러한 궁금증을 해결하는 방법으로는 ping을 이용한 패킷 손실율 측정, FTP를 이용한 대용량 파일 전송 테스트 등의 고전적인 방법으로 테스트를 실시할 수 있다.

     

    본 문서는, 대용량 데이터 전송을 통한 IPv6 네트워크 성능 측정 도구인 Iperf를 이용한 IPv6 네트워크 성능 측정 방법에 대해 설명을 한다. Iperf는 누구나 이용할 수 있는 비상용 네트워크 성능 측정도구로, IPv4/IPv6 네트워크를 모두 지원한다.


     

    1. Iperf 홈페이지

     

    아래 그림과 같이 NLANR/DAST 홈페이지에서 Iperf 관련 정보를 제공하고 있다.

    다운로드 URL :http://dast.nlanr.net/Projects/Iperf

     

    사용자 삽입 이미지

     

     

     

    2. Iperf의 다운로드

     

    Iperf는 아래 그림처럼 Linux, FreeBSD, OpenBSD, Solaris, Windows 등의 OS를 지원하고 있으며, 본 문서에서는 Windows OS 버전의 Iperf를 이용할 예정이다.

     

    사용자 삽입 이미지

     

    만약 Windows 환경을 이용하지 않는다면, 자신에 OS 맞는 바이너리 코드를 다운로드 받거나, 소스코드를 컴파일하여 이용할 수 있다.

     

     

    3. Iperf 설치

     

    다운로드 받은 Microsoft Windows 바이너리 코드(iperf-1.7.0-win32.exe)를 실행하고 적절한 곳에 압출을 풀면, 아래 그림과 같이Iperf.exe파일과 도움말 파일(DOC 폴더)이 생성된다. 이후 별도의 설치과정 없이 바로 Iperf.exe 파일을 이용하여 IPv6 네트워크 성능테스트를 실시할 수 있다.

     

    사용자 삽입 이미지

     

     

    4. Iperf의 실행 옵션

     

    우선 Iperf.exe 파일을 바로 실행하지 않고, Iperf.exe -h 명령을 실행하여 지정할 수 있는 옵션을 알아보자.

     

    명령 :: iperf.exe -h

     

    사용자 삽입 이미지

     

    Iperf는 Client-Server 방식으로 동작을 하기 때문에 클라이언트 모드를 지정하는 옵션( -c )과 서버 모드를 지정하는 옵셥( -s )이 있다. 즉, 클라이언트에서 전송하는 대규모 데이터를 서버에서 전달받아 소요된 시간을 이용하여 대역폭을 계산하게 된다.

     

    그리고, IPv4 모드 대신 IPv6 모드로 동작하기 위해서는 -V 옵션을 지정해야 한다.

     

     

    5. Server 모드로 Iperf 실행

     

    Server 모드로 Iperf를 실행하게 되면, 클라이언트로부터 데이터 전송을 기다리게 된다. 아래 그림처럼 iperf.exe -s -V 명령을 실행하면 IPv6 TCP 포트 5001을 이용하게 된다.

     

    명령 :: iperf.exe -s -V

     

    사용자 삽입 이미지

     

     

    6. Client 모드로 Iperf 실행

     

    이제 Iperf 서버로 데이터를 전송할 Client를 실행해야 한다. 이때 Server가 실행되는 단말이 아닌 별도의 단말에서 Client를 실행시켜야지만 제대로된 네트워크 테스트가 이루어 진다.

     

    Client 모드로 실행하기 위해서는iperf.exe -c [서버의 IPv6 주소] -V명령을 실행한다.

    ** 참고 :: [ ] 는 생략 가능

     

    아래 그림에서는 Iperf 서버가 2001:2b8:2:fff3::300 호스트에서 동작하고 있기 때문에 [서버의 IPv6 주소]를 2001:2b8:2:fff3::300 으로 지정하였다. 그리고 IPv6 환경에서 테스트를 하므로 -V 옵션을 추가로 지정하였다.

     

    명령 :: iperf.exe -c [2001:2b8:2:fff3::300] -V

     

    사용자 삽입 이미지

     

    위 그림에서 보면 [2001:2b8:80:11:9d8e:3923:b47a:2756] Client와 [2001:2b8:2:fff3::300] 서버의 5001 포트가 연결되었다는 것을 알 수 있으며, 약 10초간의 네트워크 성능 테스트 결과, 약 39.6Mbits/sec 정도의 성능이 나왔음을 확인할 수 있다.

     

     

    7. 기타 옵션 사항

     

    만약 특정 시간동안의 대역폭 정보를 보다 자세히 확인하고 싶은 경우 -i 옵션을 이용할 수 있다. 만약 1초간의 대역폭 성능을 확인하기 위해서는 -i 1 옵션을, 5초간의 대역폭 성능을 확인하기 위해서는 -i 5 옵션을 이용한다.

     

    아래 그림은 1초간의 대역폭 성능을 10초 동안 확인하는 예이다.

     

    사용자 삽입 이미지

     

    또한, 10초간의 성능 측정이아닌 20초간의 성능을 측정하기 위해서는, -t 20 옵션을 이용한다.

     

    사용자 삽입 이미지

     

     

     

      Comments,     Trackbacks
    IPv6 도입의 필수 요소, IPv4/IPv6 변환 기술 ①
    [특집] IPv6 도입의 필수 요소, IPv4/IPv6 변환 기술 ①

     

    출처 : 온더넷 7월호

     

     이제 IPv6로의 전환의 필요성에 대해서는 두말할 필요가 없는 상황이다. 하지만 기존의 IPv4 네트워크를 한순간에 모두 IPv6로 전환한다는 것은 불가능한 일이다. 이에 따라 IPv4와 IPv6 네트워크 간에 통신할 수 있도록하는 변환 기술에 대한 요구가 늘고 있다. 주소 변환과 터널링 등 다양한 기술을 통해 IPv4와 IPv6 간의 네트워킹을 가능케하는 IPv4/IPv6 변환 기술에 대해 알아보자.

    김진규 | 한국전산원 차세대인터넷팀

     IPv6는 IPv4에 비해 비교할 수 없을 만큼 커다란 주소공간을 가지고 있기 때문에, 유비쿼터스 네트워크를 구축하는 데 있어 필수라 할 수 있다. 그러나 기존의 인터넷을 IPv6 주소로 한순간에 바꿀 수는 없다. 전세계적으로 복잡하고 광대하게 퍼져있는 IPv4 인터넷을 한순간에 바꾸는 것은 거의 불가능하며, 커다란 혼란을 야기할 수 있을 것이다. 2005년 현재를 포함해 향후 4~5년 간은 IPv4 주소와 IPv6 주소가 공존할 것이기 때문에 두가지 주소를 변환해주는 기술이 필요할 것은 자명하다. 이에 많은 인터넷 전문가들이 IPv4/IPv6 변환 기술(Transition mechanism) 개발과 표준화를 상당부분 진행해 왔다. 변환 기술은 애플리케이션과 네트워크 차원으로 나눌 수 있다. 애플리케이션 차원의 변환 기술은 BIS, BIA 등이 있고, 네트워크 변환 기술은 다시 터널(Tunnel)과 주소 변환으로 나눌 수 있다. (표 1)은 변환 기술의 개요를 보여준다.

     

    사용자 삽입 이미지

     

    전환에 앞서

     

    지금까지 IPv4에서 IPv6로의 자연스러운 이전을 지원해주는 IPv6 전환 메커니즘에 대한 많은 연구가 이뤄졌다. 그러나 IPv6 네트워크로의 이전을 위해서는 다음과 같은 제약사항을 고려해야 한다.

     

    · IPv6가 IPv4와 자연스럽게 호환(변환)되지는 않는다.
    · 현재 수천만 개의 호스트가 IPv4 방식으로만 동작중이다.
    · 상당기간 IPv4와 IPv6는 상호 공존할 것이다.

     

    이런 제약사항을 고려할 때, 당분간은 IPv4와 IPv6가 공존할 것이라는 데는 모두가 공감하고 있다. 때문에 이 시기에 IPv4와 IPv6를 전환하는 기술은 네트워크 운영시 아주 중요한 요소가 될 것이다. 현재, IPv4/IPv6 전환 기술은 다양하게 소개되고 있으며, 네트워크의 형태에 따라 적용방법은 서로 다르다.

     

    향후 구축될 IPv6 네트워크는 IPv4/IPv6 듀얼(dual) 네트워크, 혹은 IPv6 전용(native) 네트워크 형태로 구성될 것이다. 이때 내부의 IPv6 네트워크와 외부의 다른 IPv6 네트워크, 혹은 IPv4 네트워크와의 통신을 위해서는 IPv4와 IPv6가 혼재한 시나리오가 가능하며, 이같은 IPv4/IPv6의 공존 상황에서 두 네트워크 간의 통신이 자연스럽게 이뤄지도록 하는 기술이 바로 IPv6 전환 메커니즘이다. 전환 메커니즘은 기본 IPv6 전환 메커니즘, IPv4/IPv6 변환 메커니즘, 향상된 터널링 메커니즘으로 구분되며 각각의 메커니즘 아래에 (표 2)와 같이 여러 변환 기술이 있다.

     

    사용자 삽입 이미지



    기본 IPv6 전환 메커니즘

     

    기본적인 전환 메커니즘으로는 IPv4/IPv6 듀얼스택(Dual-Stack)과 IPv6-in-IPv4 터널링 기술이 있는데, 이 중 IPv4/IPv6 듀얼스택에 대해 먼저 알아보겠다.

     

    · IPv4/IPv6 듀얼스택(Dual-Stack)

     

    IPv6 단말이 IPv4 단말과 호환성을 유지하는 가장 쉬운 방법은 IPv4/IPv6 듀얼스택을 제공하는 것이다. IPv4/IPv6 듀얼스택 단말은 IPv4와 IPv6 패킷을 모두 주고받을 수 있는 능력이 있다. IPv4 패킷을 사용해 IPv4 노드와 직접 호환되고, IPv6 패킷을 사용해 IPv6 노드와도 직접 호환된다. 노드에서 서로 프로토콜에 적합한 패킷의 변화를 수행하는 방안이다. (그림 1)은 듀얼스택의 개념을 보여준다.

     

    사용자 삽입 이미지

     

    IPv4/IPv6 듀얼스택 노드는 두 프로토콜을 모두 지원하기 때문에 IPv4 주소와 IPv6 주소로 모두 설정할 수 있다. IPv4/IPv6 듀얼스택 노드는 IPv4 메커니즘(예 : DHCP)을 사용해 그 IPv4 주소를 얻고, IPv6 프로토콜 메커니즘(예 : 상태 비보존형 주소 자동설정)을 사용해 IPv6 주소를 얻을 수 있다.

     

    듀얼스택 노드의 DNS는 호스트 이름과 IP 주소간 매핑을 위해 IPv4와 IPv6에 모두 사용된다. AAAA라는 DNS 자원 레코드 유형이 IPv6 주소를 위해 사용된다. IPv4/IPv6 듀얼스택 노드는 IPv4, IPv6 노드와 직접 호환될 수 있어야 하므로 IPv4 A 레코드는 물론이고, IPv6 AAAA 레코드도 처리할 수 있는 주소 해석기 라이브러리(DNS Resolver Library)를 제공해야 한다. IPv4/IPv6 듀얼스택 노드의 DNS 주소해석기 라이브러리는 AAAA와 A레코드를 모두 처리할 수 있어야 한다. 주소해석기 라이브러리는 IPv6 주소를 가진 AAAA 레코드와 IPv4 주소를 가진 A 레코드를 모두 조회해 그 노드와의 통신에 사용된 IP 패킷 버전에 영향을 미치기 위해 응용에 반환되는 결과를 필터링하거나 순서를 정할 수 있다.

     

    · IPv6-in-IPv4 터널링

     

    IPv6/IPv4 단말과 라우터는 IPv6 데이터그램을 IPv4 패킷에 캡슐화해 IPv4 네트워크를 통해 터널링할 수 있다. 즉, 터널링은 기존의 IPv4 인프라를 활용해 IPv6 트래픽을 전송하는 방법을 제공하며 (그림 2)와 같이 동작한다.

     

    사용자 삽입 이미지

     

    IPv6-in-IPv4 터널링 방법은 크게 설정 터널링(Configured Tunneling) 방식과 자동 터널링(Automatic Tunneling) 방식으로 구분된다. (그림 3)은 설정 터널링 방식과 자동 터널링 방식을 나타내는 그림이다.

     

    설정 터널링 : 6Bone에서 주로 사용하는 방법으로 두 라우터간(혹은 호스트간)의 IPv4 주소를 통해 수동으로 정적 터널을 설정하는 방식

     

    자동 터널링 : IPv4-호환(IPv4-Compatible) 주소를 이용해 매뉴얼한 설정없이 IPv4 구간을 통과할 때면 IPv4 호환 주소에 내포돼 있는 IPv4 주소를 통해 자동으로 터널링을 설정하는 방식이다.

     

    사용자 삽입 이미지

     

    IPv4/IPv6 변환 메커니즘

     

    IPv4/IPv6 변환 메커니즘은 헤더 변환 방식(Header Conversion)과 전송 릴레이 방식(Transport Relay), 애플리케이션 계층 게이트웨이 방식(ALG, Application Level Gateway)으로 크게 구분할 수 있다.

     

    · 헤더 변환 방식

     

    헤더 변환은 IPv6 패킷 헤더를 IPv4 패킷 헤더로 변환하는 것이며, 또는 그 역순으로 변환하는 것이다. 이때 만일 필요하다면 패킷 무결성을 유지하기 위해 체크섬(check sum)을 조정(또는 재계산)하는 것을 가리킨다.

     

    헤더 변환은 IP 계층에서의 변환으로, IPv4 패킷을 IPv6 패킷, 또는 그 반대로 변환하는 것으로써 규칙은 SIIT(Stateless IP/ICMP Translation : IP 네트워크에서 IPv6 패킷과 IPv4 패킷을 상호 변환하는 기술)에서 정의하고 있다. 헤더 변환방식은 주로 NAT-PT(Network Address Translation - Protocol Translation) 방식으로 구현되며, NAT-PT는 SIIT에 기반을 둔 헤더 변환 방식의 전형적인 예다(그림 4).

     

    사용자 삽입 이미지

     

    헤더 변환은 다른 방식에 비해 속도가 빠르다는 장점이 있는 반면, NAT(Network Address Translation)와 마찬가지로 IP계층 변환에 따른 제약점을 가지고 있다. 대표적인 제약점으로 DNS, ALG, FTP와 같이 응용 프로토콜에 내장된 IP계층 주소 변환의 어려움을 들 수 있으며, 이를 위해 DNS, FTP, ALG와 같은 별도의 응용 게이트웨이를 추가로 구현해야 한다.


    더욱이 IPv4-IPv6 헤더 변환시, IPv4 패킷은 여러 개의 IPv6 패킷으로 쪼개져 전송되는데, 이는 IPv6의 헤더 길이가 IPv4의 헤더보다 일반적으로 20바이트 더 크기 때문이다. 또한 IPv4에서의 ICMP 내용을 ICMPv6로 상호 교환할 수 없다. 애플리케이션 계층에서 발생하는 문제를 근본적으로 해결하기 위해서는 해당 프로토콜의 애플리케이션을 새롭게 개발해야 한다.

     

    · 전송 릴레이 방식

     

    전송 릴레이는 TCP, UDP/IPv4 세션과 TCP, UDP/IPv6 세션을 중간에서 릴레이하는 것을 가리킨다. 이 방법은 전송 계층에서 변환하는 방식으로, 예를 들어 전형적인 TCP 릴레이 서버는 다음과 같이 작동한다.

     

    TCP 요청이 릴레이 서버에 도착하면, 네트워크 계층은 목적지가 서버의 주소가 아닐지라도 TCP 요청을 TCP 계층으로 전달한다. 서버는 이 TCP 패킷을 받아 발신 호스트와 TCP 연결을 한다. 그 다음 서버는 실제 목적지로 TCP 연결을 하나 더 만든다. 두 연결이 구축되면 서버는 두 연결 중 하나에서 데이터를 읽어 데이터를 나머지 하나의 연결에 기록한다. 전송 릴레이에는 각 세션이 IPv4와 IPv6에 각각 밀폐돼있기 때문에 프래그먼트나 ICMP 변환과 같은 문제는 없지만 응용 프로토콜에 내장된 IP 주소의 변환과 같은 문제는 여전히 남아있다. 전송 릴레이 방식으로는 TRT와 SOCKS 게이트웨이 방식이 있으며, 애플리케이션 계층으로는 BIS, BIA가 있으나 실제 네트워크 구축 시 활용 빈도가 적기 때문에 자세한 설명은 생략한다.

     

    · 애플리케이션 계층 게이트웨이 방식

     

    애플리케이션이 IPv4와 IPv6 두 프로토콜을 모두 지원하는 경우에는 두 프로토콜 간에 변환 메커니즘이 사용될 수 있다. 트랜잭션 서비스를 위한 ALG는 사이트 정보를 숨기고 캐시 메커니즘으로 서비스의 성능을 향상시키기 위해 사용된다. 이 방법은 애플리케이션 계층에서 변환하는 방식으로, 각 서비스는 IPv4/IPv6 별로 각각 독립적이기 때문에 헤더 변환에서 나타나는 단점은 없지만, 각 서비스를 위한 ALG는 IPv4와 IPv6 모두에서 실행될 수 있어야 한다. 대표적인 ALG 방식의 예는 IPv4/IPv6 웹 프록시인 SQUID 등을 들 수 있다. 이 방식은 ALG의 성능에 따라서 서비스의 품질이 결정된다.

     

    향상된 터널링 메커니즘

     

    IPv4/IPv6 변환을 위한 향상된 터널링 메커니즘에는 DSTM(Dual Stack Transition Mechanism), 6to4, 터널 브로커, ISATAP(Intra-Site Automatic Tunnel Addressing Protocol) 등이 있다.

     

    · DSTM

     

    DSTM은 IPv6가 널리 확산되었을 때 사용될 수 있는 방식이다. IPv6 단말은 IPv6 네트워크뿐만 아니라 IPv4 단말과도 통신할 필요가 있다. 듀얼스택 전환 메커니즘(Dual Stack Transition Mechanism, DSTM)은 임시의 IPv4 주소를 IPv6 노드에 제공하는 방법과, IPv6 네트워크 내에서 동적 터널을 사용한 IPv4 트래픽 전송, 그리고 이 전환 메커니즘에 필수적인 지원 인프라에 대해 정의된 일련의 프로세스와 아키텍처를 제공한다.

     

    DSTM은 필요한 경우 IPv4 주소를 듀얼 IP 계층 호스트에 지정한다. 그러면 IPv6 호스트가 IPv4 전용 호스트와 통신할 수 있게 되거나 IPv4 전용 애플리케이션이 IPv6 호스트에서 수정되지 않고 실행될 수 있다. 이같은 할당 메커니즘은 IPv6 패킷 내부에서 IPv4 패킷의 동적 터널링을 수행하고, IPv6 네트워크의 DSTM 도메인 내에서 순수 IPv4 패킷의 노출을 억제하는 능력과 연관돼 있다. 그리고 IPv6 라우팅 테이블만 있으면 라우터가 IPv6 네트워크를 통해 IPv4 패킷을 이동할 수 있으므로 IPv6 네트워크 관리가 간단하다. (그림 5)는 DSTM의 개념을 설명하는 그림이다.

     

    사용자 삽입 이미지

     

    · 6to4


    6to4는 하나 이상의 유일한 IPv4 주소를 갖고 있는 IPv6 전용 사이트에 ‘2002:IPv4 주소::/48 단일 IPv6 프리픽스’를 할당해 외부 IPv6 네트워크와 자동 터널링을 가능하도록 하는 메커니즘을 가리킨다. 6to4의 목적은 순수 IPv6를 지원하지 않는 광역 네트워크에 연결된 고립된 IPv6 사이트나 호스트가 자동 터널링 방식을 통해 다른 IPv6 도메인이나 호스트와 통신하도록 하는 것이다. 이 방식을 사용해 연결된 IPv6 사이트나 호스트는 IPv4 호환 주소 또는 설정 터널링을 필요로 하지 않는다.

     

    · 터널 브로커

     

    아직까지 대부분의 6Bone 네트워크는 수동으로 설정된 터널을 사용해 구축된다. 이 방법의 단점은 네트워크 관리자의 관리 부담이 많다는 점이다. 관리자는 각 터널마다 광범위한 설정을 수동으로 수행해야 한다. 이 관리 오버헤드를 줄이는 방법 중의 하나가 바로 터널 브로커 메커니즘이다. 터널 브로커(Tunnel Broker) 개념은 터널 브로커라는 전용 서버를 구축, 사용자의 터널 요청을 자동으로 관리하는 방법이다. 이 방법은 IPv6로 연결된 호스트의 증가를 활성화시키고 초기 IPv6 네트워크 제공자들이 그들의 IPv6 네트워크에 쉽게 접근할 수 있도록 해주는 데 유용할 것으로 예상된다.

     

    · ISATAP

     

    ISATAP은 주로 IPv4 기반의 인트라넷에서 IPv6 노드를 점증적으로 배치할 수 있는 간단하고 확장성 있는 방법을 제공한다. 6to4와 큰 차이점은 6to4가 /48 주소를 할당해, 할당 받은 노드가 서브네트워크를 구성할 수 있으나 ISATAP은 /64 단위로 하나의 단말에 IPv6 주소를 부여해 통신하도록 설계된 방법이라는 것이다. ISATAP은 64비트 EUI-64 인터페이스 식별자와 표준 64비트 IPv6 주소 프리픽스(Prefix)를 이용한 글로벌 유니캐스트 주소 포맷을 기반으로 한다. 이 접근법은 IPv6 게이트웨이와 공통 데이터링크를 공유하지 않는 듀얼스택 노드가 사이트 내에서 IPv4 라우팅 인프라를 통해 IPv6 메시지를 자동 터널링 함으로써, 글로벌 IPv6 네트워크에 결합할 수 있도록 한다. ISATAP 주소 자동 설정을 위해 두 가지 오프링크 IPv6 게이트웨이의 자동 탐색방법이 제공된다. 이 접근법에서는 경계 게이트웨이에서 하나의 동일한 프리픽스 주소를 사용하므로 전체 사이트 통합시 확장 문제없이 사이트 내에 대규모 배치가 가능하다.

      Comments,     Trackbacks
    OpenBSD와 pf(Packet Filter)를 이용한 PC 방화벽 구성

    OpenBSD와 pf(Packet Filter)를 이용한 PC 방화벽 구성

     

     

    IPv6 서비스를 제공하거나 이용하는 과정에서 OS에서 제공하는 단말 수준의 방화벽뿐만 아니라, 네트워크 전체를 보호하기 위한 별도의 방화벽의 필요성이 제기되고 있다. 특히, 상용방화벽중 IPv6를 지원하는 방화벽은 2004년부터 출시되기 시작하였으나, 그 수가 매우 적은 실정이다.

     

    따라서, 본 문서에서는 OpenBSD와 PF(Packet Filter) 소프트웨어를 이용하여 IPv6 지원 PC 방화벽을 구성하는 방법을 간단하게 설명하고자 한다.

     

     

    1. 필요 요소

     

    OpenBSD에서 방화벽을 구성하기 위해서는 2개 이상의 네트워크 인터페이스가 필요하다. 만약 라우터(router) 기반의 방화벽을 구성할 경우 2개의 인터페이스(랜카드)만 필요하며, 브릿지(bridge) 형태의 방화벽을 구성할 경우 3개의 네트워크 인터페이스가 있으면 편리하다.

     

    라우터 형태로 방화벽을 구성할 경우 네트워크 구성에 일부 변경이 필요하기 때문에,본 문서에서는 기존 IPv6 네트워크의 구성을 변경하지 않고 IPv6 방화벽을 적용하기 위해 브릿지(bridge) 형태의 IPv6 방화벽을 구성한다.특히 브릿지 형태의 경우 외부에서는 IPv6 방화벽 존재 자체가 드러나지 않기 때문에 보안상 더욱 유리하다.

     

    브릿지 모드에서는 2개의 네트워크 인터페이스는 In-bound, Out-bound 경로로 이용되며, 나머지 1개의 네트워크 인터페이스는 원격 관리용도로 이용할 수 있다. 만약 원격 관리를 하지 않고 시리얼 포트 또는 로컬 콘솔에서 관리를 한다면 2개의 네트워크 인터페이스만 있어도 된다.

     

    최소 하드웨어 요구사항

     

  • 133MHz or higher x86 class processor
  • 64 MB of RAM
  • 1 GB hard drive
  • 2 NICs ( 인텔 또는 3COM 랜카드 권장, 본 문서에서는 Intel 10/100 랜카드 이용 )
  • OpenBSD 3.6 or higher ( 현재 버전은 3.7 )

     

    아래 그림처럼 OpenBSD를 이용한 브릿지 형태의 방화벽은 라우터와 라우터 사이 또는 라우터와 스위치 사이에 위치하며, 브릿지를 통과하는 패킷을 통제한다.

     

    사용자 삽입 이미지

     

    2. OpenBSD 설치

     

    OpenBSD 웹사이트의 문서를 참고 하여 OpenBSD를 설치한다.

    참고 문서 ::http://www.openbsd.org/faq/faq4.html

    참고 문서 :: OpenBSD_install [다운로드]

     

    ** 어떤 소프트웨어 패키지를 선택해야 할지 잘 모를 경우 전체 설치를 선택함

     

    설치과정에서 OS 파티션 및 네트워크 인터페이스 설정이 끝난 뒤 쉘 프롬프트가 나타나면 브릿지 인터페이스를 구성할 수 있다.

     

     

    3. 브릿지 인터페이스 구성

     

    OpenBSD의 브릿지는 OSI 7 Layer 중 Layer 2 계층에서 동작을 하며, 동시에 브릿지를 통과하는 패킷의 Layer 3, Layer 4 데이터를 필터링 할 수 있다.

     

    우선, 브릿지 구성을 위해 양 네트워크 인터페이스(Inbound, Outbound) 사이트의 IP 패킷 포워딩을 가능하게 해야 한다. OpenBSD의/etc/sysctl.conf파일의 내용 중 'net.inet.ip.forwarding=1' 항목과 'net.inet6.ip6.forwarding=1' 항목의 주석을 제거한다.

     

    변경 전 :: #net.inet.ip.forwarding=1

                   #net.inet.ip6.forwarding=1  

         

    변경 후 :: net.inet.ip.forwarding=1   ( 주석 제거 )

                   net.inet6.ip6.forwarding=1  ( 주석 제거 )

     

    다음으로 두 개의 네트워크 인터페이스를 이용하여 브릿지 인터페이스를 구성해야 한다.

     

    두 개의 네트워크 인터페이스를fxp0fxp1이라고 가정하고 (인텔 NIC의 경우 fxp0, 1, 2 형태의 이름으로 네트워크 인터페이스가 생성되며, 타 NIC의 경우 이름이 다름) 아래와 같은 명령을 실행한다.

     

    # fxp0 인터페이스의 변경 및 시작

       ifconfig fxp0 delete

       echo 'up' > /etc/hostname.fxp0

     

    # fxp1 인터페이스의 변경 및 시작

       ifconfig fxp1 delete

       echo 'up' > /etc/hostname.fxp1

     

    # 브릿지 인터페이스의 생성 및 시작

       echo 'add fxp0 add fxp1 up' > /etc/bridgename.bridge0

     

    ** bridge 설정과 관련하여 위 명령을 실행해도 bridge 인터페이스가 정상적으로 동작하지 않는 경우, 직접 /etc 디렉토리에 bridgename.bridge0 파일을 만들고 아래와 같은 내용을 추가한다.

        add fxp0

        add fxp1

        up

    이제, 시스템을 재시작하고 ifconfig -a 명령 실행 결과를 확인해 보면 아래와 유사한 bridge 인터페이스 정보를 확인할 수 있으며, 브릿지 인터페이스가 정상 동작하고 있음을 알 수 있다.

    bridge0: flags=41<UP,RUNNING> mtu 1500

     

    4. pf 활성화

     

    pf(Packet Filter)는 OpenBSD 3.0부터 제공되는 패킷 필터링 도구이며, 기본 시스템 설정에서는 비활성화되어 있다.

     

    pf를 활성화기 위해서는 /etc/rc.conf 파일을 아래와 같이pf=NO를 pf=YES로 수정한다.

    # set the following to "YES" to turn them on
    rwhod=NO
    nfs_server=NO             # see sysctl.conf for nfs client configuration
    lockd=NO
    amd=NO
    pf=YES                        # Packet filter / NAT
    portmap=NO                # Note: inetd(8) rpc services need portmap too
    inetd=YES                    # almost always needed
    check_quotas=YES        # NO may be desirable in some YP environments
    krb5_master_kdc=NO     # KerberosV master KDC. Run 'info heimdal' for help.
    krb5_slave_kdc=NO       # KerberosV slave KDC.
    afs=NO                        # mount and run afs

    수정후 시스템을 재시작해야지만, pf가 동작한다.

     

    기타 pf 관련 설정항목에는 아래와 같은 것이 있다.

    # miscellaneous other flags
    # only used if the appropriate server is marked YES above
    savecore_flags=                          # "-z" to compress
    ypserv_flags=                             # E.g. -1 for YP v1, -d for DNS etc
    yppasswdd_flags=NO                 # "-d /etc/yp" if passwd files are in /etc/yp
    nfsd_flags="-tun 4"                     # Crank the 4 for a busy NFS fileserver
    amd_dir=/tmp_mnt                      # AMD's mount directory
    amd_master=/etc/amd/master      # AMD 'master' map
    syslogd_flags=                           # add more flags, ie. "-u -a /chroot/dev/log"
    pf_rules=/etc/pf.conf                  # Packet filter rules file
    pflogd_flags=NO                        # add more flags, ie. "-s 256"

    afsd_flags=                                # Flags passed to afsd
    shlib_dirs=                                 # extra directories for ldconfig, separated
                                                     # by space

     

    위 내용에서pf_tule=/etc/pf.conf항목은 pf 규칙을 정의한 파일을 지정하는 항목이며,pflogd_flags=NO는 pf 관련 로그 기록 여부와 관련된 항목이다.

     

     

    5. pf 기본 규칙 정의

     

    pf 관련 패킷 필터링 규칙을/etc/pf.conf파일에 적용하기 이전에, 방화벽 규칙을 정해야 한다. 우선 본 예제에서는 브릿지 모드로 동작하기 때문에, 하나의 인터페이스에 대해서만 방화벽 규칙을 적용하면 된다.

     

    fxp0를 외부 네트워크와 연결된 인터페이스로 가정하고, fxp1을 내부 네트워크와 연결된 인터페이스로 가정한다면, fxp0의 inbound, outbound 트래픽에 대한 규칙을 정의한다.

     

    - 외부에서 들어오는 IPv4/IPv6 패킷중 ssh와 http는 웹서버(1.1.1.2, 2001:aaaa::2)에만 허용

    - 외부에서 들어오는 IPv6 패킷중 ftp는 FTP 서버(2001:aaaa::3)에만 허용

    - 외부에서 들어오는 IPv4 패킷중 DNS Lookup은 DNS 서버(1.1.1.4)에만 허용

    - ICMP, ICMP6는 모두 허용함

    - Loopback 관련 트래픽은 모두 허용함

    - 외부에서 들어오는 IPv6-in-IPv4 터널 패킷은 모두 허용함

    - 내부에서 외부로 나가는 모든 트래픽은 허용함

    - 외부에서 들어오는 모든 트래픽의 상태를 추적함(Keep State)

    - 내부에서 나가는 모든 트래픽의 상태를 추적함(Keep State)

    - Drop된 패킷에 대한 로그를 남김(Log all dropped packet)

     

     

    6. pf.conf 파일의 편집

     

    우선 OS 설치후 /etc/pf.conf 파일을 열어보면 아래와 같다. 간단하게 의미를 파악해 보자.

     

    사용자 삽입 이미지

     

    ext_if="fxp0"항목은 외부 인터페이스를 정의한 것이고,int_if="fxp1"은 내부 인터페이스를 정의한 것이다.

     

    pass in log quick on $ext_if all 의 의미는 $ext_if(fxp0)로 들어오는(in) IPv4 패킷에 대해 로그를 기록하고(log) 이 조건을 만족하면 더 이상 아래부분의 필터링 조건을 확인하지 않고(quick) 바로 통과(pass) 시킨다는 의미이다.

     

    pass out log quick on $ext_if all의 의미는 $ext_if(fxp0)에서 나가는 IPv4 패킷에 대해 로그를 기록하고 이 조건을 만족하면 더 이상 아래부분의 조건을 확인하지 않고 바로 통과 시킨다는 의미다..

     

    pass in log quick inet6 all의 의미는 외부에서 들어오는 모든 inet6, 즉 모든 IPv6 패킷을 통과시킨다는 의미이며, pass out log quick inet6 all 의 의미는 외부로 나가는 모든 IPv6 패킷을 통과시킨다는 의미이다.

     

    이처럼 pf.conf 파일 작성 규칙에 따라 자신이 원하는 패킷을 제어할 수 있다.

     

    구체적인 pf.conf 파일 작성법은관련 문서를 참고 하기 바람

     

     

    6. pf 세부 규칙(rule) 설정

     

    그러면, [5. pf 규칙 정의] 항목에서 설정한 필터링 규칙을 실제 작성하고 시스템에 적용해보자.

     

    /etc/pf.conf 파일에 들어갈 내용

     

    #######################################################################

    ## 브릿지를 중심으로 외부 인터페이스는 fxp0이므로

    $ext_if="fxp0"

     

    ## 브릿지를 중심으로 내부 인터페이스는 fxp1이므로

    $int_if="fxp1"

     

    ##패킷을 정규화 시키기 위해

    scrub in

     

    ## 브릿지 모드에서는 하나의 인터페이스만 통제를 하면 되므로, 외부 인터페이스는 통제를

    ## 하고, 내부 인터페이스는 모두 통과 시킴

    ## (특별하게 inet, inet6을 정의하지 않으면 IPv4, IPv6 모두 해당됨)

    pass in log quick on $int_if all
    pass out log quick on $int_if all keep state

    ## 악의적인 패킷을 걸러내기 위해
    # ipv4
    block in log quick inet proto tcp all flags FS/FS
    block in log quick inet proto tcp all flags /FSRPAU
    # ipv6
    block in log quick inet6 proto tcp all flags FS/FS
    block in log quick inet6 proto tcp all flags /FSRPAU

    ## Loopback 인터페이스(lo0)와 관련된 패킷은 모두 통과
    pass in quick on lo0 all
    pass out quick on lo0 all keep state

    ## ICMP, ICMP6 관련 패킷은 모두 허용
    pass in log quick on $ext_if inet proto icmp from any to any keep state
    pass in log quick on $ext_if inet6 proto icmp6 from any to any keep state

    ## 만약 ICMP6 관련 패킷을 모두 차단하면, IPv6 네트워크 동작에 문제가 발생할 수 있다.
    ## 예) RA 메시지를 못받는 경우

    ## 외부에서 들어오는 IPv4/IPv6 패킷중 ssh와 http는 웹서버(1.1.1.2, 2001:aaaa::2)에만 허용
    pass in log quick on $ext_if inet proto tcp from any to 1.1.1.2  port { 22, 80 } keep state

    pass in log quick on $ext_if inet6 proto tcp from any to 2001:aaaa::2  port { 22, 80 } keep state

     

    ## 외부에서 들어오는 IPv6 패킷중 ftp는 FTP 서버(2001:aaaa::3)에만 허용

    pass in log quick on $ext_if inet6 proto tcp from any to 2001:aaaa::3  port 21 keep state

     

    ## 외부에서 들어오는 IPv4 패킷중 DNS Lookup은 DNS 서버(1.1.1.4)에만 허용

    pass in log quick on $ext_if inet proto tcp from any to 1.1.1.4 port 53 keep state

    pass in log quick on $ext_if inet proto udp from any to 1.1.1.4 port 53 keep state

     

    ## 외부에서 들어오는 IPv6-in-IPv4 터널 패킷은 모두 허용함
    pass in log quick on $ext_if inet proto 41 from any to any keep state

     

    ## 외부에서 들어오는 모든 트래픽의 상태를 추적함(Keep State)

    ## 내부에서 나가는 모든 트래픽의 상태를 추적함(Keep State)
    block in log quick on $ext_if inet all
    pass out log quick on $ext_if inet all keep state
    block  in log quick on $ext_if inet6 all
    pass out log quick on $ext_if inet6 all keep state

     

    #######################################################################

     

     

    7. 테스트

     

    pf 관련 설정이 제대로 적용되고 있는지, pf 기능이 정상동작하고 있는지 확인하기 위해서는pfctl명령을 이용한다.[pfctl 참고 사이트]

     

    pf.conf 파일의 로딩 :: pfctl -f /etc/pf.conf

    pf 기능의 시작 :: pfctl -e

    pf 기능의 중지 :: pfctl -d

    pf 룰셋(규칙) 보기 :: pfctl -s rule

    pf 관련 통계보기 :: pfctl -sa

     

    또한, tcpdump를 이용하여 pf의 동작상태를 확인할 수 있다.

     

    tcpdump -i pflog0

     

     

    이상으로 pf를 이용한 IPv6 방화벽 구성에 대해 아주 간단히 알아 보았다. 위 내용은 오직 예제이며, 실제 사이트에 적용하기 위해서는 보다 구체적이고 정밀한 방화벽 룰 설정이 필요할 것이다.

     

    보다 상세한 내용은 아래 참고문서를 참고 하기 바란다.

     

     

    참고문서

    - Daemon News  HOWTO Transparent Packet Filtering with OpenBSD [다운로드]

    - Firewalling IPv6 with OpenBSD's pf (packet filter) [다운로드]

    - OpenBSD_install [다운로드]

    - OpenBSD Resources  how-to  invisible_firewall [다운로드]

     

  •   Comments,     Trackbacks
    IPv6 적용을 위한 현황분석 방법
    [IPv6 강좌] IPv6 적용을 위한 현황분석 방법

    출처 : 온더넷, 2005년 6월호

    이번호에는 IPv6 전환시 가장 기초가 되는 자원의 조사를 통해 현황을 분석하는 방법을 자세하게 알아본다. 자세하고 기본적인 자원의 조사가 바탕이 돼야 보다 세밀한 IPv6 전환에 대한 설계가 가능하며, 전환 후 업무의 중단이나 장애가 없는 견고한 IPv6 네트워크를 구축할 수 있을 것이다.


    김진규 | 한국전산원/차세대인터넷팀

    IPv6로의 성공적인 전환을 위해서는 현재 사내 네트워크와 시스템 등에 대한 현황 분석과 이를 단계적으로 전환하기 위한 설계방안을 마련해야 한다. 각 회사별로 사내 네트워크 와 시스템의 특수성이 반영돼야 하므로 해당 기업 또는 부서의 영역별로 업무 특징을 고려해 표본 부서를 선정하고, 선정된 표본 부서를 대상으로 전환 점검 체계에 따라 전환 점검표와 점검 양식을 우선적으로 적용하는 절차가 필요하다.
    표본 부서에서 전환 점검 체계를 적용해서 수집된 정보는 데이터베이스화해 다른 부서, 나아가 회사 차원의 IPv6 전환시 활용할 수 있도록 한다. 이를 위한 전환 점검 지침을 개발함으로써 실제 IPv6 전환 전략, 모델 설계, 실제 전환 단계까지 전 영역에 대한 기반을 마련할 수 있으며, 궁극적으로 성공적인 IPv6 전환을 구현할 수 있을 것이다.


    IPv6 전환 점검 절차


    IPv6 전환 점검 절차는 IPv6로의 전환을 위한 표본 부서를 우선 선정하고, 해당 표본 부서의 IT 담당자와 공동으로 계획, 추진한다. 또한 표본 부서를 통해 영역별 참조모델을 제시하고, 향후 전사적인 IPv6 전환에 있어서 전환 모델과 방향을 제시한다. (그림 1)은 IPv6 전환 점검 절차에 대한 흐름도다.

    사용자 삽입 이미지

    전환계획서와 지침서를 개발하기 위해 전환 프로세스 정의, 양식표 개발과 수집 정보 활용계획을 수립하고, 표본 부서를 선정한다. 표본 부서를 대상으로 전환 점검 양식표를 작성해 일정과 예산을 산정하며, 이런 기본 방침을 기반으로 전환 영향을 평가하고 단계별 전환 계획서와 지침서를 개발해 제시한다.

    자원 항목별 분류

    IPv6 도입을 위한 자원 점검 절차 중 첫 번째 단계는 자원 항목별 분류다. 전사적인 규모의 IPv6 도입 모델과 전략에 관한 연구를 위해서는 자원에 대한 분류가 필요하며, 일반적으로 ▲네트워크 장비 ▲단말 장비 ▲소프트웨어 ▲운영관리 ▲보안 ▲주소 ▲기타와 같은 자원 항목 분류를 사용한다.

    이렇게 대분류를 끝내고 나서, 각 항목별로 세부항목을 나눠, 보다 세밀한 IPv6 지원여부를 확인 점검한다.

    ·네트워크 자원
    네트워크 자원은 인터넷과 인트라넷을 구성하는 2계층 장비에서 7계층 장비까지의 모든 장비를 대상으로 조사해야 하며, ▲라우터 장비(인터넷 연동 라우터, 인트라넷 연동 라우터, 기타) ▲스위치 장비(2∼7계층 스위치) ▲NAT 장비 ▲AP(Access Point) 장비 ▲CDN 장비(캐시 등) ▲게이트웨이 장비(VPN 등)

    ·단말 자원
    클라이언트(데스크톱, 노트북 등), 서버 (인터넷용, 업무용), Non-PC(PDA, 스마트폰, OA기기 등), 음성/영상 기기(화상회의 등)

    ·소프트웨어
    OS(윈도우, 유닉스, 리눅스 등), 데이터베이스(오라클, 인포믹스, MS-Sql, Mysql 등), 사내 애플리케이션 서비스(ERP 등), 상용 애플리케이션 서비스(웹, 메일 등)

    ·운영관리
    인증, DNS/DHCP, EMS/NMS, 모니터링/제어계측기기

    ·보안
    파이어월/IDS/IPS, IPSec, PKI

    ·주소 자원
    사설 주소, 공인 주소

    ·기타
    이용자에 대한 교육 등

     

    이상과 같이 자원이 2단계까지 세부적으로 분류되면, 다음 작업으로 각각의 분류된 자원에 대한 수집 방안 표준을 마련해야 한다.


    자원 점검을 위한 기초 자료 수집 방안


    자원 항목별 분류가 끝났으면 이제는 IPv6로의 전환을 위해 자원별 IPv6 전환이 가능한 장비의 현황을 파악하고, 각 항목별 지원 장비형태에 따라 자원을 체계화한다. 향후 전사적인 IPv6로의 원활한 전환을 위해 중요한 자료가 되므로 체계적인 데이터베이스화가 필요할 것이다. (그림 2)는 항목별 점검 순서를 나타낸 것으로, 전체 자원별 IPv6 지원 방안 지침서로 활용했다.

    사용자 삽입 이미지

    자원에 대한 IPv6 지원 방안 지침서를 바탕으로 항목별/자원별 점검에 대한 순서는 다음과 같다.

    ·대상 자원에 대한 구성 자료를 수집한다.

    ·자원 형태에 따라 하드웨어와 소프트웨어로 분류해 IPv6를 지원하기 위한 자료를 다양한 경로를 통해 조사해 체계화한다.

    ·구현과 적용 사례를 조사 분석한다.

    ·자원에 대한 기초 자료 수집과 조사를 완료한 후, 장비별/자원별 상세 분석에 착수한다 (장비별 지원현황, 정상 구동 유무, 고려사항 등).


    항목별 자원의 체계화

    IPv6 도입을 위한 자원 점검 절차 세 번째 단계로 항목별 자원의 체계화가 필요하다. (그림 3)은 자원 항목별 IPv6 지원 방안을 마련하기 위한 데이터 활용 체계를 나타낸 것이다. 항목별 활용방안을 위해 수집정보를 체계화(데이터베이스화), 자동화하며, 각종 통계 자료를 유형별로 세분화해 향후 기업의 전사적인 IPv6 전환시 정보 자료로 활용한다.

    사용자 삽입 이미지

    수집 정보의 활용을 위한 체계적인 데이터베이스화는 데이터 종류에 따라 통계자료, 구성 자료, 매뉴얼 자료 등으로 나눠 로우 데이터를 정리해 구성한다. 데이터베이스화 모델은 웹페이지와 데이터베이스화해 정리 보관하며, 자원 항목별로 IPv6 지원을 위한 방안을 함께 마련한다. 향후 전사적 IPv6 도입에 따른 중복 업무를 피하기 위해 각 부서별 또는 본사와 지점 등의 유형과 자원의 종류에 따라 체계적으로 데이터베이스화 업무를 수행한다.
     

    자원 점검

    점검을 위해서는 자원 항목을 분류하고 해당 자원 항목별 장비를 분류할 필요가 있다. 또한 분류된 장비에 대한 세부적인 특징 조사가 필요하다. 여기서는 해당 장비의 특이사항에 대한 점검이 요구되는데, 이에 대한 개념도는 (그림 4)와 같다.

    사용자 삽입 이미지

    자원 점검을 위한 프로세스는 장비점검을 위한 개념도를 구체화하고 절차화한 것으로 "자원 분류   장비별 분류   장비관리 부분 조사   장비 특징 조사   특이사항 조사"로 이뤄진다.

    자원 점검을 위한 프로세스의 첫번째 단계는 해당 회사(또는 단위 사업부서)의 자원에 대한 분류다. IPv6 도입 자원을 선정하고 선정된 자원을 분류 기준(네트워크, 애플리케이션 서비스, 시스템 자원)에 따라 체계적으로 분류한다.

    분류된 자원은 목적이나 용도에 따라 세분화돼 장비별로 분류하고, 장비의 제조회사, 도입일 또는 취득일, 담당자 등의 일반적인 사항을 조사해 IPv6 도입시 활용하도록 한다. 또한, 제조회사의 제공 정보와 기술정보 습득 등의 다양한 경로를 통해 장비사양, 운영체제, 기능 등의 상세한 부분까지 조사한다. 마지막으로 특정 장비에 대해 IPv6 관련 자료나 특이사항을 기록해 해당 기업의 전사적인 IPv6 전환에 있어 특이사항 등으로 반영할 수 있도록 한다.

    항목별 장비 분류가 확인되면 장비에 대한 IPv6 지원 여부와 지원 장비의 특징 등을 조사하는데, 이런 장비 점검에 대한 프로세스는 (그림 5)와 같다.

    사용자 삽입 이미지

    자원 점검을 위해 자원의 항목별 분류를 확인하고, 장비나 애플리케이션 서비스의 IPv6 지원 여부와 버전을 점검한다. IPv6를 지원하는 경우는 장비나 애플리케이션 서비스 명칭, 장비 사양 등을 조사하고, IPv6 지원 항목의 종류와 추가 모듈, 변경이 필요한 모듈은 어떤 것들이 있는지 확인한다. 마지막으로 해당 장비나 애플리케이션 서비스의 IPv6 표준을 얼마나 지원하는지와 각 장비의 특이사항을 조사한다.

    또한, 장비에서 IPv6를 지원하지 않는 경우에는 IPv4 장비나 애플리케이션 서비스를 고려해 IPv6 지원을 위한 개발이나 계획 등을 조사하고 장비나 애플리케이션 서비스의 명칭과 사양을 함께 조사한다. 이때, 네트워크 장비가 2계층 장비로 사용된다면, IPv6 전환에 대해 고려할 필요는 없다.


    자원 항목별 점검 목록


    지원 항목별 점검 목록은 다음과 같다.

    ·IPv6 지원을 위한 버전 확인(IPv6 지원 시스템 운영체제 버전 확인, IPv6 지원 네트워크 장비의 운영체제 확인).
    ·IPv6 지원을 위한 하드웨어 사양(IPv6 지원을 위한 최소의 하드웨어 사양, IPv6 지원을 위한 장비 명칭 조사).
    ·IPv6 지원을 위해 변경되거나 추가되는 모듈의 종류.
    ·IPv6 기본 설치를 위한 가이드라인(명령어).
    ·IPv6 특징을 지원하기 위한 설치 가이드라인(명령어).
    ·IPv6 설치 제거를 위한 가이드라인(명령어).
    ·IPv6 지원을 위한 특징 비교 분석(IPv6 특징을 지원하는 항목별 비교 분석).
    ·표준을 수용하는 범위 조사
    ·지원하는 RFC의 종류 조사
     

    자원 점검을 위한 분류

    자원 점검을 위해 하드웨어 부문과 소프트웨어 부문으로 구분해 분류할 필요가 있다. 하드웨어는 네트워크와 시스템 부분, 소프트웨어는 애플리케이션 서비스와 운영체제 등을 포함한다. 먼저 하드웨어 점검을 위한 프로세스를 살펴보면, 네트워크 장비로는 라우터와 스위치가 있으며, 단말 장비에는 데스크톱 PC, 노트북, 서버 등이 있다. (그림 6)은 이들 하드웨어 장비에 대한 점검 프로세스이다.

    사용자 삽입 이미지

    하드웨어 시스템(네트워크 장비와 단말 시스템)의 점검을 위해 우선 해당 하드웨어 시스템의 용도에 따라 영역코드를 부여한다. 해당 하드웨어 시스템의 영역코드 분류에 따라 취득일, 제조업체, 모델명, 담당자 등에 대한 정보를 조사한다. 또한, IPv6 지원을 위한 기본적인 지원 모듈과 기능, 지원 표준, 확장 모듈과 특이사항에 대해 조사해 데이터베이스화해야 한다.

    이번에는 소프트웨어 점검을 위한 절차를 살펴보자. 소프트웨어의 점검은 네트워크 장비와 단말 장비에서 각각 이뤄진다. 네트워크 장비는 장비별 운영체제를, 단말 장비는 PC와 서버 시스템의 운영체제와 기타 주요 애플리케이션 서비스(파이어월, 웹서버, DNS, 메일서버 등)에 대해 수행한다. (그림 7)은 IPv6 지원을 위한 장비의 소프트웨어 점검 절차이다.

    사용자 삽입 이미지


    점검 양식

    전사적인 IPv6 전환시 자원의 항목별 점검을 위해서는 일정한 양식표가 필요한데, 이들 양식표는 네트워크 장비, 단말 장비, 서버 장비별로 각각 다르다.

    (표 1)은 네트워크 자원의 IPv6 지원 여부를 점검하기 위한 점검 양식표다. 물론 해당 회사의 특성에 따라 다를 수 있지만 여기서는 가장 일반적으로 사용할 수 있는 점검양식을 제시한다.

    사용자 삽입 이미지

    (표 2)는 단말 및 서버 자원의 IPv6 지원 여부를 점검하기 위한 점검 양식표다. 이 부분도 마찬가지로 각 회사의 특성에 따라 다를 수 있지만 가장 일반적인 방법을 적용할 수 있는 표를 예시로 작성했다.

    사용자 삽입 이미지

    이번호에는 IPv6 전환시 가장 기초가 되는 자원의 조사를 통해 현황을 분석하는 방법을 자세하게 알아봤다. 이런 자세하고 기본적인 자원의 조사가 바탕이 돼야 보다 세밀한 IPv6 전환에 대한 설계가 이뤄질 수 있으며, 전환 후 업무의 중단이나 장애가 없는 견고한 IPv6 네트워크를 구축할 수 있을 것이다. 실제 사례를 통한 설계와 전환방법은 다음호에 소개하겠다.

      Comments,     Trackbacks
    [기업 환경에 닷넷 적용하기] ② 비즈니스 레이어 설계·구현

    [기업 환경에 닷넷 적용하기] ② 비즈니스 레이어 설계·구현

     

    연재순서
    1.제대로 된 컴포넌트를 위한 프리젠테이션 레이어 설계하기
    2.비즈니스 로직 레이어 설계와 물리적 구현을 위한 필요 사항
    3.엔터프라이즈 솔루션 패턴 해부하기
    4.닷넷의 웹 프리젠테이션 패턴
    5.닷넷 개발에서 UML과 케이스 툴의 사용

     

    기업용 응용 프로그램뿐 아니라 모든 컴포넌트 기반 프로그래밍에서 가장 중요한 비중을 차지하는 계층이 비즈니스 계층이다. 데이터나 프리젠테이션 계층의 컴포넌트는 응용 프로그램의 형태에 따라 존재하지 않을 수도, 프로세스가 해당 계층을 거치지 않고도 동작할 수 있다.

    하지만 비즈니스 계층의 컴포넌트는 어떠한 상황에서 실행되는 프로세스라도 결코 피해갈 수 없다. 비즈니스 계층의 컴포넌트를 설계하기 위해서는 '상태가 없는(Stateless) 동작으로서의' 의미로 비즈니스를 인식하는 것이 중요하다. 이번 글에서는 엔터프라이즈 솔루션 아키텍처에서 비즈니스 계층을 구성하는 컴포넌트를 제대로 설계하기 위한 여러 권장사항과 설계 기법들을 알아본다.

    프로젝트가 진행될 때 가장 크게 고려되는 사항은 ‘비즈니스 로직을 어떻게 설계할 것인가?’이다. 특히 프리젠테이션 계층에서 제공하는 사용자 컴포넌트들이 풍부한 닷넷 환경에서는 닷넷 프레임워크가 제공하는 컴포넌트들을 거의 그대로 사용하고, 요구사항 분석에 따른 업무의 흐름을 담당하는 비즈니스 로직 계층을 어떻게 구성할 것인가가 주 관건이 된다.

    MVC를 확연하게 구분할 수 있는 환경을 제공하는 프리젠테이션 계층과 달리, 닷넷에서는 비즈니스 로직 계층을 구성할 수 있는 어떤 자동화된 방법이나 구조를 특별히 제공하지는 않는다. 그렇다면 비즈니스 로직 계층에 존재하는 컴포넌트들을 어떻게 개발해야 하는지가 프로젝트의 성패를 가늠하는 가장 중요한 문제가 되는데, 이럴 때 컴포넌트를 ‘어떻게’ 구성해야 하는지에 대한 훌륭한 해답이 바로 닷넷 엔터프라이즈 아키텍처이다.

    닷넷 엔터프라이즈 솔루션 아키텍처 기반에서 비즈니스 로직 계층 컴포넌트들의 구성과 데이터 액세스 계층에서 컴포넌트의 구성을 알아보자.

    비즈니스 계층 컴포넌트의 구성
    사실상 기업용 응용 프로그램의 핵심은 응용 프로그램이 제공하는 비즈니스 기능이라 할 수 있다. 기업용 응용 프로그램의 존재 이유는 바로 이런 비즈니스들을 어떻게 자동화할 것인가에 있다고 해도 과언이 아니다(사실 컴포넌트의 공식 명칭은 ‘비즈니스 컴포넌트’이다). 3-티어 구조의 응용 프로그램에서 비즈니스 컴포넌트 계층에 존재하는 컴포넌트들은 프리젠테이션 계층의 사용자 프로세스 컴포넌트나 컨트롤러의 호출로 일단의 프로세스를 수행한다. 닷넷 엔터프라이즈 솔루션 아키텍처에서 비즈니스 컴포넌트 계층 컴포넌트는 <그림 1>과 같은 구조로 구성된다.

    사용자 삽입 이미지
    <그림 1> 비즈니스 계층 컴포넌트

    <그림 1>에서 알 수 있듯이 비즈니스 계층은 굳이 나누자면 세 종류의 역할을 하는 컴포넌트들로 구성된다. 비즈니스 엔티티 역할을 하는 컴포넌트는 표현되는 데이터를 포함하는 객체들로 이뤄진다. 비즈니스 컴포넌트 역할을 하는 컴포넌트는 비즈니스 엔티티 컴포넌트에 포함된 객체를 생성하고 동작들을 지정하며, 데이터 액세스 로직 컴포넌트를 호출하는 동작과 비즈니스 엔티티 객체의 상태를 변경하는 등의 오퍼레이션을 담당한다. 비즈니스 워크플로우 역할을 하는 컴포넌트는 분산 트랜잭션 또는 분산 시스템에서 프로세스의 수행이 완료될 때까지 비즈니스 작업을 조율하고 상태를 저장하는 등의 여러 동작을 수행한다. 서비스 인터페이스는 당연히 GOF 디자인 패턴에서의 전형적인 Facade 역할을 담당한다.

    <그림 1>의 비즈니스 계층에서 계층 구성이 가장 단순한 경우를 생각해 보자. 비즈니스 엔티니 컴포넌트와 비즈니스 워크플로우 없이 비즈니스 컴포넌트만 사용하는 경우다. 닷넷 환경이 도입되기 이전의 ASP 개발 환경에서 즐겨 사용하던 방법으로서, 비즈니스 엔티티 컴포넌트로 ADO가 제공하는 레코드셋 등의 개체를 사용한다. 비즈니스 컴포넌트에는 데이터베이스에 액세스하여 레코드셋을 만들어 내고, 프리젠테이션 계층 역할을 하는 ASP 페이지에 레코드 셋을 넘겨줘 페이지에 보이게 하는 경우였다.

    닷넷 프로그래밍이 국내에 처음 소개되던 무렵에는 비즈니스 컴포넌트를 COM 개체가 아닌 닷넷 어셈블리로 컴파일하여 사용하는 경우가 많았다. 필자 역시 웹 개발에서 레지스트리에 등록된 COM 개체를 유지 보수하기 위해 IIS를 내렸다 올렸다 했던 환경에서 운영 환경에 특정 컴포넌트를 물지 않는 닷넷 환경의 편리함에 감탄한 적이 있다.

    가장 단순한 경우의 컴포넌트 구성이 반드시 틀렸다는 것은 아니다. 항상 주장하는 말이지만 닭 잡는 데는 닭 잡는 칼을 써야 하고 소 잡는 데는 소 잡는 칼을 써야 한다. 간단한 구조의 응용 프로그램이라면 이와 같이 구성하는 것이 개발 사이클이나 유지 보수성 등의 측면에서 훨씬 뛰어날 수도 있다. 하지만 기업용 응용 프로그램이라면 이야기가 달라진다. 세션 또는 닷넷에서 제공하는 추상화된 개체인 HttpContext, HttpModule 등을 사용하여 사용자를 관리하고, 수시로 변하는 데이터를 수많은 클라이언트가 열고 있는 경우라면 어떨까? 앞에서 이야기한 가장 간단한 형태의 컴포넌트 구성은 개발 당시의 생산성 측면에서나 유지 보수성, 성능 등의 모든 면에서 복잡도가 증가하게 된다.

    가장 복잡한 경우는 여러 서비스를 이용하거나 분산 시스템 기반에서 응용 프로그램을 작성하는 것이다. 수없이 많은 클라이언트들이 응용 프로그램을 사용하고 분산 트랜잭션과 분산 서비스에서 비즈니스 워크플로우를 제어해야 한다면 비즈니스 엔티티 컴포넌트는 물론, COM+나 비즈토크 오케스트레이션(Biztalk Orchestration) 등을 사용하는 비즈니스 워크플로우를 모두 구성하는 것이 바람직하다. 물론, 모든 컴포넌트에는 서비스 인터페이스가 존재하여 프리젠테이션 계층 컴포넌트에서 직접 호출을 추상화하여 제공하는 창구가 필요하다.

    단순하게 생각해 보자
    새로운 기술이나 이론 등을 접할 때 가장 당황스러운 것은 새로운 용어를 접할 때이다. <그림 1>에서 등장하는 새로운 용어들로 인하여 장애를 느끼는 독자라면 <그림 2>를 보자. 컴포넌트의 구성은 그 컴포넌트가 어떠한 일을 해야 하는지를 결정하는(그 역할에 따라 구성하는) 것이 가장 바람직하다. <그림 2>는 비즈니스 계층의 컴포넌트들이 어떠한 역할을 해야 하는지를 잘 설명한다.

    사용자 삽입 이미지
    <그림 2> 비즈니스 계층 컴포넌트들의 역할

    응용 프로그램 망/흐름 제어로 설명된 비즈니스 워크플로우 프로세스의 역할부터 알아보자. 이 역할을 하는 컴포넌트는 가장 쉽게 생각해 여러 대의 다른 역할을 하는 엔터프라이즈 서버로 구성됐거나 다른 도메인에 존재하는 다른 기업 간의 프로세스 흐름에서(B2B 또는 EAI 프로젝트에서) 그 망을 구축하고 프로세스의 흐름을 제어한다. 언뜻 분산 처리를 담당할 수 있는 COM+와 MSDTC를 떠올릴 수 있지만 COM+ 또는 MSDTC는 동작의 역할을 하는 비즈니스 컴포넌트에서 사용되고(물론 COM+ 또는 MSDTC가 이런 역할을 할 수 없다는 것은 아니다. 하지만 엔터프라이즈 솔루션 아키텍처에서 비즈니스 워크플로우는 그런 분산 트랜잭션보다는 더 넓은 의미에서 비즈니스 워크플로우를 포함한다), 주로 이 역할을 담당하게 되는 것은 비즈토크 오케스트레이션이다.

    <그림 2>에서 동작으로 설명된 비즈니스 컴포넌트의 가장 주된 역할은 데이터를 받아들이고 반환하는 것이다. 비즈니스 컴포넌트는 캡슐화를 이용해 구현되는 높은 추상을 가지는 응용 프로그램의 동작을 구현한다. 비즈니스 컴포넌트를 통해 프리젠테이션 계층에서 응용 프로그램을 사용하는 사용자가 어떤 데이터 저장소를 사용하는지, 어떤 서비스를 이용하여 데이터를 처리하는지 등의 정보를 캡슐화해 좀 더 편리한 프로그래밍 인터페이스를 제공한다.

    중요한 것은 비즈니스 컴포넌트는 상태(state)를 가져서는 안 되며, 단순히 동작만을 제어해야 한다는 것이다. 프리젠테이션 계층의 컨트롤러나 사용자 프로세스 컴포넌트에서 호출되는 비즈니스 컴포넌트는 그 사용이 매우 빈번하고 복잡한 프로세스의 흐름을 가질 수 있으므로 비즈니스 컴포넌트가 특정 상태를 가지고 프로세스를 제어한다면 컴포넌트를 여러 사용자가 공유할 수 없게 된다.

    데이터는 반드시 각 사용자 별로 유지돼야 하므로 비 연결 지향의 ADO.NET 개체를 주로 사용하는 비즈니스 엔티티 컴포넌트가 상태를 가질 수 있거나 또는 반드시 가져야 하는 것과는 달리, 비즈니스 컴포넌트는 상태를 가질 수 없도록 설계돼야 한다. 비즈니스 컴포넌트는 데이터의 제어를 위한 동작이 주가 됨으로, 트랜잭션을 시작하고 관리할 수 있는 역할을 반드시 할 수 있어야 한다. 대부분의 응용 프로그램에서 트랜잭션의 시작은 주로 비즈니스 컴포넌트 역할의 개체들이 담당하게 되며, SQL 서버나 ADO.NET의 트랜잭션 지원 개체들이 트랜잭션 제어를 위해 사용되고, 분산 서버 환경이라면 엔터프라이즈 서비스를 이용하여 COM+와 MSDTC를 사용하게 된다.

    <그림 2>에서 데이터로 표현된 비즈니스 엔티티는 데이터를 표현하는데 사용된다. 비즈니스 엔티티 컴포넌트의 인스턴스는 비즈니스 컴포넌트의 호출로 생성되며, 호출된 비즈니스 컴포넌트의 트랜잭션이 종료되기 전까지 상태를 서버 또는 클라이언트에서 유지하면서 사용된다. 비즈니스 엔티티 컴포넌트가 데이터를 표현하는 것이므로 닷넷 기반 프로그래밍에서는 ADO.NET이 제공하는 여러 포맷, 즉 데이터 리더, 데이터 셋, 형식화된 데이터 셋, XML 문서 등을 주로 사용할 수 있다. 물론 프로그래머가 직접 디자인한 사용자 정의 개체도 사용될 수 있다.

    가장 권장되는 방법은 모든 데이터를 내부에 캡슐화하거나 데이터에 대한 특정한 행위를 필요로 하지 않는 경우 XML 문서나 ADO.NET이 제공하는 데이터 셋을 사용하는 것이다. 비즈니스 엔티티 컴포넌트는 스냅샷 데이터를 가져 정보의 로컬 캐시를 유지한다. 이러한 로컬 캐시를 데이터베이스의 데이터와 동기화하기 위한 Update 메쏘드 등을 제공해 줄 필요가 있다.

    마지막으로 서비스 인터페이스는 전형적인 Facade로 동작하게 디자인한다. 응용 프로그램의 비즈니스 계층 컴포넌트들이 서비스로서 노출시켜야 하는 경우라면 서비스 인터페이스 역할의 컴포넌트를 반드시 포함해야 한다. 서비스 인터페이스 컴포넌트를 추가했다면 다른 응용 프로그램의 서비스 에이전트들이 서비스를 이용할 수 있도록 할 수 있다. 서비스 인터페이스를 XML 웹 서비스로 구현하여 다양한 플랫폼의 응용 프로그램이나 다양한 장비에서 동작하는 응용 프로그램들이 같은 서비스를 사용할 수 있도록 할 수 있다.

    어떨 때, 어떻게 구현해야 하는가?
    앞서 언급했지만 100번을 강조해도 모자람이 없는 말이 바로 ‘닭 잡는 데는 닭 잡는 칼을, 소 잡는 데는 소 잡는 칼을’ 쓰는 것이다. 응용 프로그램의 아키텍처는 간단하면 간단할수록 좋다(그렇다고 모델 1 기법이 가장 좋은 방법이라는 말은 결단코 아니다. “응용 프로그램이 복잡해진다고 생각되는 그때 클래스를 추가하라”는 말을 기억하자). 엔터프라이즈 솔루션 아키텍처에서 <그림 1>과 같은 다이어그램을 제공한다고 해서 반드시 그 구조를 지켜야 한다는 것은 절대 아니다.

    응용 프로그램의 아키텍처를 설계하는 사람은 그 응용 프로그램의 역할과 복잡도를 충분히 파악하여 아키텍처를 구성해야 한다. 정답은 없다. 물론, 수학적인 공식을 사용해 요구사항 분석에 따른 역할을 파라미터로 복잡도를 분석하고 아키텍처를 설계하는 툴을 만들 수는 있다. 하지만 프로젝트라는 것이 시시각각으로 변하고 인프라의 환경에 따라 아키텍처는 유연하게 반응해야 하는 것이므로 적당한 관점에서 탄력적으로 운용될 수 있는 아키텍처를 설계하는 것이 중요하다.

    비즈니스 워크플로우 컴포넌트
    비즈니스 워크 플로우는 주로 비즈토크 오케스트레이션으로 구현되며, 다른 벤더의 솔루션이나 프로그래머가 개발한 사용자 정의 컴포넌트로도 구현될 수 있다. 다음과 같은 경우에 비즈니스 워크플로우를 포함하여 구성할 수 있다.

    ◆ 복잡한 단계의 비즈니스 트랜잭션을 처리하는 경우 :트랜잭션의 깊이가 너무 깊어지면 비즈니스 컴포넌트만으로는 감당할 수 없는 경우가 많아진다. 비즈니스 트랜잭션이 여러 서비스와 연동하는 경우에 프로세스의 각 단계를 내부에 캡슐화하는 비즈니스 컴포넌트를 작성하고 비즈니스 워크플로우가 비즈니스 컴포넌트를 조정하도록 하는 것이다. 소매 응용 프로그램에서 주문을 진행하는 프로세스의 경우가 대표적인 것이다.

    ◆ 장기 트랜잭션을 포함하는 프로세스를 관리하는 경우 :트랜잭션의 깊이가 깊지는 않더라도 처리되는 프로세스의 기간이 길어지는 경우가 있다. B2B 솔루션에서 파트너 업체와의 주문 처리 등이 이런 경우인데, 주문 처리에서 입고 처리까지가 하나의 트랜잭션으로 관리돼야 하는 경우, 즉 워크플로우의 상태를 장기간 유지해야 하는 경우에 비즈니스 워크플로우를 포함해 구성하는 것을 고려할 수 있다. 비즈토크 오케스트레이션은 이러한 비즈니스 워크플로우를 처리할 수 있도록 디자인되었다.

    ◆ 비즈토크 서버와 응용 프로그램간의 어댑터나 커넥터를 구성하여 서비스 에이전트와 통신하는 경우 :응용 프로그램이 비즈토크 서버와 통신해야 하는 경우 비즈토크 서버의 발신 데이터를 수신하여 비즈니스 엔티티를 생성하거나 데이터베이스에 입력하는 경우 등의 프로세스가 발생한다. 또한 여러 비즈토크와 통신하는 경우에 이러한 제어를 추상화하기 위한 비즈니스 워크플로우 프로세스가 필요하다.

    비슷한 절차가 필요하지만 다음과 같은 경우에는 비즈니스 워크플로우를 생략하고 비즈니스 컴포넌트만으로 구현할 수 있다.

    ◆ 비즈니스 흐름이 상태를 유지할 필요가 없는 경우 :상태를 유지하는 흐름이 아닌 단순 스탭으로만 이뤄지는 단일 서버의 프로세스라면 워크플로우 프로세스 없이 비즈니스 컴포넌트의 메쏘드를 순차적으로 호출함으로써 해결할 수 있다.

    ◆ 비즈니스 트랜잭션이 단일 트랜잭션으로 구성되는 경우 :하나의 트랜잭션으로 모든 절차를 완료할 수 있는 경우라면 비즈니스 워크플로우 프로세스를 구현할 필요가 없다.

    ◆ 데이터 구조를 직접적으로 액세스하는 경우 :비즈니스 워크플로우 프로세스는 자신이 상태를 가지고 비즈니스 컴포넌트를 컨트롤하는 절차를 수행하므로 비즈니스 컴포넌트가 사용하는 비즈니스 엔티티의 데이터에 직접 액세스하는 경우에는 사용이 까다로워진다.

    ◆ 장기적인 흐름 컨트롤이 아닌 로직에 대한 상세 컨트롤인 경우 :비즈니스 워크플로우는 비즈니스 컴포넌트가 운영하는 여러 절차를 추상화한 프로세스를 운영하므로 로직에 대한 상세 컨트롤에서는 사용하기가 어려워진다.

    비즈니스 워크플로우에서 반드시 고려해야 하는 점은 가격대 성능비적인 차원이다. 비즈토크 오케스트레이션은 어떠한 비즈니스 프레임워크보다 훌륭하게 동작하지만, 마이크로소프트(이하 MS)가 판매하는 엔터프라이즈 서버 제품군들 중 가장 가격이 높은 서버에 속하며, 그 전문가를 고용하는 가격 또한 가장 비싼 편에 속한다. 비즈니스 컴포넌트만을 사용하여 워크플로우를 구성하는 것이 서버를 도입하는 것보다 비용/기간 면에서 저렴하다면, 굳이 비즈니스 워크플로우를 포함하여 아키텍처를 설계하지 않아도 된다.

    비즈니스 컴포넌트
    비즈니스 컴포넌트는 어떠한 상황에서도 반드시 존재해야 하는 컴포넌트이다. 닷넷 환경이 처음 도입됐을 때 ASP.NET의 코드 비하인드 파일이 이런 비즈니스 컴포넌트 역할을 한다고 설명하는 경우가 많았으나 코드 비하인드 파일은 MVC 모델에서의 컨트롤러 역할을 수행해야 하고, 비즈니스 로직은 비즈니스 컴포넌트에서 구현해야 한다. N-티어 구조 응용 프로그램에서 각 계층은 느슨한 결합도로 조합되어 각 계층의 컴포넌트가 변화더라도 다른 계층의 컴포넌트에는 영향을 주지 않는 구조로 디자인되어야 한다. 코드 비하인드는 닷넷 아키텍처상 독립된 비즈니스 계층의 컴포넌트로 동작하는 것이 불가능하다.

    비즈니스 컴포넌트는 이미 존재하는 로직을 캡슐화하는 수준 높은 추상화를 제공하고, 변화 가능한 존재하는 비즈니스 기능들을 조합하는 등의 역할을 수행해야 한다. 객체지향 개발 방법에서 여러 디자인 패턴들을 응용하여 비즈니스 컴포넌트를 작성함으로써 이러한 빠른 변화에 능동적으로 대처할 수 있는 높은 추상성과 유지 보수성을 가지는 응용 프로그램을 작성할 수 있게 된다.

    비즈니스 컴포넌트를 작성할 때 절대로 간과하면 안 되는 것이 트랜잭션의 지원이다. 비즈니스 컴포넌트는 비즈니스 엔티티의 상태를 관리 및 수정하고 생성하는 역할을 담당할 수 있다. 따라서 비즈니스 엔티티 또는 데이터베이스에 존재하는 데이터의 일관성과 무결성을 지키기 위해 트랜잭션을 반드시 고려해서 작성해야 한다. 비즈니스 컴포넌트에서 트랜잭션 처리는 크게 두 가지로 고려될 수 있다. ADO.NET의 ITransaction 개체를 사용하여 트랜잭션을 처리하거나 또는 여러 서버로 구성된 응용 프로그램의 경우 COM+가 이용하는 MSDTC를 사용한다.

    비즈니스 컴포넌트를 작성할 때 주의해야 하는 것은 앞서 이야기했듯이 컴포넌트에 상태가 있어서는 안된다는 점이다. 비즈니스 컴포넌트 팩토리에서 언급한 컴포넌트 인스턴스의 3대 원칙을 그대로 준수해야 하는 진짜 컴포넌트가 이 비즈니스 컴포넌트가 된다. 상태가 없고 메시지 패싱을 원칙으로 하는 등의 비즈니스 컴포넌트의 기본 원칙에 따라 작성돼야 한다. 비즈니스 컴포넌트의 설계 권고 사항은 다음과 같다.

    ◆ 가급적이면 메시지 기반의 통신을 사용한다.

    ◆ 서비스 인터페이스로 노출된 프로세스에서 메쏘드가 두 번 호출되거나, 같은 인자 값을 가지며 같은 방식의 메시지가 전달되었을 때 데이터의 무결성을 유지할 수 있도록 설계되어야 한다 :서비스 인터페이스로 노출된 프로세스는 페이지의 리로드나 같은 서비스의 동시 사용 등으로 인해 같은 식별자를 가지는 데이터를 두 번 사용하거나 여러 명이 동시에 사용하게 되는 경우가 빈번하게 일어난다. 이럴 때를 대비할 수 있는 처리를 해야 하는데, 가장 좋은 방법은 아예 이런 프로세스를 원천적으로 봉쇄하거나 메시지 큐 등을 사용하여 직렬화하고 검증하는 등의 정책이 필요하다.

    ◆ 비즈니스 컴포넌트는 어떤 서비스 사용자의 컨텍스트에서도 사용될 수 있도록 한다 :펫샵 3.0을 설치해 본 독자라면 겪어봄직한 이야기이다. 펫샵은 데이터베이스 연결 문자열을 Web.Config 파일에 암호화하여 저장한다. 암호화된 연결 문자열에는 Trusted Connection을 사용하도록 설정되어 있다. 이런 설정으로 인해 데이터베이스 연결에서 오류가 발생하는 경우를 봤을 것이다. 이 때 impersonate 속성을 설정해 줘 응용 프로그램에 접근하는 사용자를 ASP.NET으로 인격화(Impersonation)하는 방법을 사용하면 데이터베이스에는 접근 가능하지만 필요한 어셈블리를 로드할 수 없다는 오류를 만나게 된다. 윈도우의 사용자 권한 정책과 데이터베이스의 연결 등의 여러 문제를 고려해 어떤 사용자라도 특별한 인격화 과정을 거치지 않고 비즈니스 컴포넌트에 접근할 수 있도록 설계해야 한다.

    ◆ 입력 매개변수와 반환 값은 일관성 있는 포맷으로 선택하고 유지한다 :반환 값으로 ADO.NET에 포함되어 있는 DataSet 개체 또는 스키마가 지정된 XML 파일 등을 사용하는 것이 가장 바람직하며, 비즈니스 엔티티에 사용자 정의 컴포넌트를 사용할 경우 일관된 정책 수립이 필요하다.

    ◆ 트랜잭션 격리 수준에 신경써라 :트랜잭션 격리 수준에는 정말 정답이 없다. 데이터베이스에서 데드락을 막을 수 없듯이 격리 수준은 파악된 요구사항에 따라 적절히 수립하는 수밖에 없다. 어이없는 경우는 트랜잭션 하에서 여러 명령이 수행되도록 작성하고, 수행되는 명령에서 오류가 발생하는 경우에 대한 처리를 잊어버리는 경우다. 이럴 때는 격리 수준이 ReadCommetted로 설정됐다면 데이터베이스에서 강제로 트랜잭션을 종료하기 전까지 데이터는 잠기게 된다. 어렵지 않고 기본적인 수준의 권고사항이지만 이 때문에 발생하는 어이없는 오류가 한 번씩 생기기 마련이다.

    펫샵의 예를 보자. 지난 글에서도 살펴봤듯이 펫샵은 잘 설계된 아키텍처에 따라 구성된다. 펫샵의 구조는 <그림 3>에서 살펴볼 수 있듯이 엔터프라이즈 솔루션 아키텍처의 원칙을 그대로 따른다(비즈니스 워크플로우는 존재하지 않는다).

    사용자 삽입 이미지
    <그림 3> 비주얼 스튜디오 닷넷의 속성창에서 본 펫샵 응용 프로그램 구조


    <그림 3>은 아키텍처 기반으로 구현된 응용 프로그램의 예를 들어 설명하기 위해 앞으로 계속 참조할 것이므로 유심히 봐두길 바란다. 전체 솔루션에 포함된 11개의 프로젝트 중 BLL 프로젝트가 비즈니스 컴포넌트에 해당한다. BLL 컴포넌트는 여러 개의 파일로 구성되어 있고, 작성된 클래스들은 비즈니스 컴포넌트 작성 권고사항에 따라 작성되었다. <그림 4>의 클래스 다이어그램에서도 알 수 있듯이 상태가 없는 오퍼레이션만을 가지고 있는 것을 알 수 있다.

     

    사용자 삽입 이미지
    <그림 4> BLL 컴포넌트의 클래스 다이어그램

    펫샵은 주문 처리를 위해 분산 데이터베이스를 사용한다. 분산 데이터베이스의 트랜잭션은 닷넷의 엔터프라이즈 서비스를 사용한다. <리스트 1>은 분산 트랜잭션을 위해 엔터프라이즈 서비스를 사용하는 OrderInsert 클래스의 소스코드이다. 주문을 수행하는 Insert 메쏘드에서 주문 처리를 위한 주문 정보 데이터베이스와 재고 관리를 위한 재고 정보 데이데이터 베이스 등 두 데이터베이스에서 분산 트랜잭션을 처리한다.

     <리스트 1> OrderInsert 클래스의 소스코드
    사용자 삽입 이미지
    using System;
    using System.Collections;
    using System.EnterpriseServices;
    using System.Runtime.InteropServices;
    using PetShop.Model;
    using PetShop.IDAL;

    namespace PetShop.BLL {
      [Transaction(System.EnterpriseServices.TransactionOption.Required)]
      [ClassInterface(ClassInterfaceType.AutoDispatch)]
      [ObjectPooling(MinPoolSize=4, MaxPoolSize=4)]
      [Guid("14E3573D-78C8-4220-9649-BA490DB7B78D")]
      public class OrderInsert : ServicedComponent {
        private const string ACID_USER_ID = "ACID";
        private const string ACID_ERROR_MSG = "ACID test exception thrown for distributed transaction!";

        protected override bool CanBePooled() {
          return true;
        }

        [AutoComplete]
        public int Insert(OrderInfo order) {
          // 주문 정보 데이터베이스 입력
          IOrder dal = PetShop.DALFactory.Order.Create();
          int orderId = dal.Insert(order);
          // 재고 정보 데이터베이스 처리
          Inventory inventory = new Inventory();
          inventory.TakeStock( order.LineItems);

          if (order.UserId == ACID_USER_ID)
            throw new ApplicationException(ACID_ERROR_MSG);

          return orderId;
        }
      }
    }
    사용자 삽입 이미지

    <리스트 2>는 주문 정보를 반환하는 아주 썰렁한 클래스 OrderRead 클래스의 소스코드이다. 어렵고 복잡하게 짠 코드가 잘 작성된 것은 아니라는 점을 확연히 보여준다. GetOrder 메쏘드는 잘 알려진 정수형의 파라미터를 받아들이고 주문의 정보를 표현하는 비즈니스 엔티티 컴포넌트에 포함된 OrderInfo 객체를 반환하도록 디자인되었다.

     <리스트 2> OrderRead 클래스 소스코드
    사용자 삽입 이미지
    using System;

    //References to PetShop specific libraries
    using PetShop.Model;
    using PetShop.IDAL;

    namespace PetShop.BLL {
      public class OrderRead{
        public OrderInfo GetOrder(int orderId) {
          if (orderId < 1)
            return null;
          IOrder dal = PetShop.DALFactory.Order.Create();
          return dal.GetOrder(orderId);
        }
      }
    }
    사용자 삽입 이미지

    <리스트 2>의 GetOrderInfo 메쏘드에는 if (ordered < 1)이라는 조건절이 포함되어 있다. 이는 주문 정보 번호가 유효한지 아닌지를 검사하는 유효성 검사를 수행하는 코드다. 비즈니스 컴포넌트는 프리젠테이션 계층의 컴포넌트가 아닌 다른 계층의 컴포넌트들, 즉 서비스 인터페이스, 다른 비즈니스 컴포넌트 등에서도 호출할 수 있으므로 이러한 유효성 검사는 반드시 필요하다. 다음은 비즈니스 컴포넌트의 구현에서 지켜야 하는 규칙들이다.

    ◆ 트랜잭션의 시작점이 된다. 비즈니스 컴포넌트가 참여하는 트랜잭션을 지원해야 한다.
    ◆ 입력과 출력에 대한 유효성을 검사할 수 있어야 한다.
    ◆ 데이터 액세스 로직을 호출하여 데이터를 가져오거나 갱신할 수 있어야 한다.
    ◆ 설치된 서비스 에이전트를 통하여 외부 서비스를 호출할 수 있어야 한다.
    ◆ 비즈니스 워크플로우를 초기화할 수 있어야 한다.

    <그림 5>는 다른 비즈니스 컴포넌트와 상호 작용하는 전형적인 비즈니스 컴포넌트의 모습을 보여준다.

    사용자 삽입 이미지
    <그림 5> 비즈니스 컴포넌트

    그리고 비즈니스 컴포넌트가 작성될 때는 흐름 제어를 위한 패턴인 순차 호출식의 파이프라인 패턴과 이벤트 호출식의 이벤트 패턴이 사용된다. 일반적으로 비동기적인 서비스를 포함하고 있으면 파이프라인 패턴을, 모든 활동의 초기 값이 동일하고 각 활동 간에 메시지 패싱이 필요 없을 때 이벤트 패턴을 사용한다.

    비즈니스 엔티티 컴포넌트
    비즈니스 엔티티는 전체 아키텍처를 고려할 때 반드시 필요한 사항은 아니다. 기업용 응용 프로그램에서 데이터가 존재하지 않는 경우는 없겠지만, 특히 ASP.NET 응용 프로그램에서 사용자 정의 비즈니스 엔티티를 작성하지 않고 ADO.NET에 포함된 데이터 셋이나 XML 문서를 사용하는 경우도 많다. 데이터 셋은 복잡한 정보를 포함할 수 있어 굳이 사용자 정의 비즈니스 엔티티를 포함하지 않아도 되며, 데이터 셋은 XML로 바로 변환할 수 있어 작업 및 문서 기반으로 프로젝트를 진행할 수 있기 때문이다.

    사실 거의 모든 기업용 응용 프로그램에서 비즈니스 엔티티를 사용한다. 일반적으로 상태를 표현하는 정보를 사용자 정의 엔티티에 포함한다. 사용자 정의 비즈니스 엔티티 컴포넌트 내의 객체는 상태를 표시하기 위한 전역변수 등의 데이터와 복잡한 데이터를 표현하기 위한 컬렉션이나 데이터셋을 포함한다. 이후 포함된 이들 컬렉션과 데이터셋 등의 개체를 프로퍼티로 지정하도록 설계하여 구현된 비즈니스 엔티티 컴포넌트가 자신을 호출하는 사용자 프로세스 컴포넌트 또는 비스니스 컴포넌트 등에 노출시켜 주는 기법을 사용한다.

    다시 <그림 3>의 펫샵 모델을 살펴보자. 펫샵에서는 Model 컴포넌트가 비즈니스 엔티티 컴포넌트로 사용된다. 전형적인 모델을 보여준다. <그림 6>은 Model 컴포넌트의 클래스 다이어그램이다.

    사용자 삽입 이미지
    <그림 6> Model 컴포넌트의 클래스 다이어그램

    <그림 6>의 클래스 다이어그램에서 알 수 있듯이 비즈니스 엔티티 컴포넌트는 단순히 자신을 생성하는 생성자만을 포함하고 있을 뿐 어떤 동작도 포함하고 있지 않다. 비즈니스 엔티티 컴포넌트는 MVC 모델에서 Model 역할을 담당하게 되는데, 모델은 단순히 데이터로서 존재해야지 데이터베이스에 직접 접근하거나 트랜잭션을 초기화해서는 안 된다. 비즈니스 컴포넌트에 의해 생성이 불가피하거나 비즈니스 컴포넌트의 로직이 불필요하게 복잡해 질 경우에는 데이터 액세스 로직 컴포넌트를 이용하는 것이 바람직하다. 비즈니스 엔티티는 어떤 잠재적인 행위를 가지고 단지 데이터를 표현하는 용도로서만 사용돼야 한다. 비즈니스 엔티티 컴포넌트의 설계 권고사항은 다음과 같다.

    ◆ 사용자 정의 엔티티 구현이 반드시 필요한지를 면밀한 요구사항 분석을 통해 파악한다 :사용자 정의 엔티티를 구현하는 것은 복잡성의 증가로 인한 개발 비용 상승을 가져올 수 있다. 필요하지 않다면 굳이 작성할 필요가 없지만, 작성하는 것이 비즈니스 컴포넌트의 코드 가독성과 복잡성을 떨어뜨리는 효과를 가져 오기도 한다.

    ◆ 사용자 정의 비즈니스 엔티티가 필요하다면 객체지향의 특성을 이용해서 다형적으로 구현한다 :공통 타입을 정의하고, 기본 클래스 또는 인터페이스의 서브타입으로 설계하여 비즈니스 컴포넌트의 개발 부담을 덜 수 있도록 설계해야 한다.

    ◆ 컬렉션이나 구조체 대신 데이터 셋이나 XML 문서를 내부적으로 유지한다 :데이터 셋이나 XML 문서는 복잡한 데이터를 표현할 수 있다. 또한, 닷넷 프레임워크의 Collections 프레임워크는 다형적으로 아주 잘 설계되어 있으므로 여러 사용자의 부담을 줄일 수 있다.

    ◆ 비즈니스 엔티티 인터페이스를 디자인하고 공용 속성을 제공한 후 구현은 서브 클래스에 위임하는 공통적인 다형성을 사용한다 :엔티티의 속성에 대한 프로퍼티, 엔티티가 포함하는 컬렉션 접근자, Load, Save, Validate등의 컨트롤 메쏘드와 속성을 정의하여 구현한다.

    ◆ 내부 데이터를 표현하는 메타데이터로부터 자유롭게 설계한다 :XSD 스키마 처럼 유효성 검사 규칙을 분리하여 외부 호출자가 규칙에 영향을 미치지 않도록 설계한다.

    ◆ 데이터베이스 액세스에 대한 일관성을 유지한다 :모든 데이터 액세스는 데이터 액세스 로직에 일임한다.

    제대로 된 소프트웨어를 먼저 생각하자
    필자가 코스매니저로 있는 정보기술원의 닷넷 5기 과정에서 최종 프로젝트로 닷넷 기반의 개인용 블로그 솔루션을 개발하고 있다. 욕심으로는 무버블 타입 같은 수준의 높은 추상성을 가지는 개인용 블로그를 독촉했지만 취업 등의 여러 이유로 인해 테터툴즈(Tatter tools) 수준의 블로그 솔루션이 개발될 듯하다.

    블로그에는 트랙백과 RSS를 포함해야 하는데 9개월 정도 공부한 한 학생이 이틀 만에 구현했다. 다른 사이트나 책을 참조하는 것 같지 않았고 수업 시간에 공부한 적도 없는데 금방 구현한 것이다. 닷넷은 워낙에 좋은 성능과 많은 기능들을 가진 플랫폼이라 RSS의 개념 정도만 파악하면 쉽게 구현할 수 있다.

    국내 닷넷 커뮤니티를 돌아다니다 보면 사용자 지정 컨트롤을 만들어서 배포도 하고 소스도 공개하는 것들을 많이 볼 수 있다. 하지만 공개되는 소스코드들의 수준이 그렇게 뛰어나지도 않을 뿐더러, 그렇게 만들어진 사용자 정의 컨트롤들이 어떻게 사용될 수 있을지 의심스럽다. 국내 유명한 닷넷 커뮤니티들을 돌아다니다가 외국의 오픈소스 커뮤니티와 비교해보면 한숨이 저절로 난다.

    닷넷 플랫폼에서 개발하고 있는 여러 개발자들은 다음과 같은 질문을 스스로 던져볼 필요가 있을 것 같다. ‘닷넷이 정말 뛰어난 플랫폼인가?’ 그렇다고 스스로에게 대답을 했다면 ‘왜 뛰어난 플랫폼인가?’를 다시 한번 생각해 봐야 한다. 단순히 생산성이 좋아서? 그렇다고 생각했다면 그 사람은 틀림없는 초보 개발자이거나 단순 코더 밖에 되지 않는다. “닷넷 플랫폼이 어떤 이유에서 뛰어나다고 말할 수 있는가?”라는 질문에 대한 대답을 이전의 ASP나 PHP 개발과 비교해 “편해서”, “개발 환경이 좋아서”라는 대답들이 머리에 먼저 떠오른다면 조금 더 깊이 있는 공부가 필요하다.

    어쩌면 내 게시판에서 RSS를 돌려볼 수 있을 것은 중요한 문제가 아니다. 잘 파악된 요구사항을 기반으로 이러한 요구사항을 만족하기 위해 RSS가 어떤 역할을 할 수 있는가? RSS가 전체 아키텍처에서 다른 컴포넌트들과 어떻게 유기적으로 조합될 수 있는가? 등 이런 것들이 훨씬 중요하다.

    소스포지(sourceforge.net)에서 Liferay 엔터프라이즈 포탈이라는 오픈소스 솔루션을 검색하고 웬만하면 한번 써보기 바란다. 3년간 다섯 명의 개발자가 개발했다는 이 솔루션을 보면 닷넷의 최전방에 서 있다는 필자로서는 저절로 한숨이 난다.

    닷넷 환경에서는 왜 이런 솔루션이 나오지 않는가? 이런 환경을 쉽게 구축하기 위한 모든 인프라는 이미 닷넷 플랫폼에 모두 들어 있다. “국내에서는 솔루션을 만들어 봤자 안 팔려”라는 말을 하기 전에 먼저 소프트웨어를 제대로 만들어 보겠다는 생각을 해야 한다. 물론, 그런 솔루션은 튼튼한 기반 아키텍처 위에 구축될 수 있고, 닷넷 엔터프라이즈 솔루션 아키텍처는 튼튼한 반석이 되어준다.@

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

     

    김상훈 (동명정보대학 정보기술원 연구원)

    2005/08/10

     

    사용자 삽입 이미지

     

     

     

     

    원문 :http://www.zdnet.co.kr/builder/dev/dotnet/0,39031607,39137358,00.htm

      Comments,     Trackbacks
    You've got to find what you love - 스티브 잡스 - 스탠포트 졸업식 연설

    Stanford Report, June 14, 2005


    "You've got to find what you love," Jobs says

    This is the text of the Commencement address by Steve Jobs, CEO of Apple Computer and of Pixar Animation Studios, delivered on June 12, 2005.

    이것은 2005년 6월 12일에 애풀컴퓨터와 픽사 애니메이션 스튜디오의 CEO인 스티븐 잡스의 졸업식 연설문입니다.

     

    I am honored to be with you today at your commencement from one of the finest universities in the world.

    저는 오늘 전세계에서 최고 대학 중 하나인 스텐포드 대학 졸업식에 여러분과 함께하게 되어 영광입니다.

     

    I never graduated from college. Truth be told, this is the closest I've ever gotten to a college graduation. Today I want to tell you three stories from my life. That's it. No big deal. Just three stories. 

     저는 대학을 졸업하지 못했습니다. 진실을 말하면, 이번이 대학 졸업식에 가장 가까이 온 것입니다. 오늘 저는 제 삶에서 3가지 얘기를 하려고 합니다.

     

    The first story is about connecting the dots.
    첫번째 얘기는 점들을 연결하는 것에 관한 것입니다.

     

    I dropped out of Reed College after the first 6 months, but then stayed around as a drop-in for another 18 months or so before I really quit. So why did I drop out?

    저는 리드 컬리지를 첫 6개월동안 다닌 후 자퇴했습니다. 하지만 정말 자퇴하기 전에 그 후 18개월동안 청강생으로 주위에 머룰렀습니다. 왜 제가 자퇴를 했을까요?

     

    It started before I was born. My biological mother was a young, unwed college graduate student, and she decided to put me up for adoption. She felt very strongly that I should be adopted by college graduates, so everything was all set for me to be adopted at birth by a lawyer and his wife. Except that when I popped out they decided at the last minute that they really wanted a girl. So my parents, who were on a waiting list, got a call in the middle of the night asking: "We have an unexpected baby boy; do you want him?" They said: "Of course." My biological mother later found out that my mother had never graduated from college and that my father had never graduated from high school. She refused to sign the final adoption papers. She only relented a few months later when my parents promised that I would someday go to college.

    제가 태어나기 전 내 어머니(생모)는 젊고, 결혼도 하지 않은 대학 졸업생이어서 저를 입양시키기로 결정했습니다. 어머니는 제가 대학 졸업자에 의해 양자삼아주기 강하게 원하셨고, 태어나면 변호사와 그의 부인에게 입양되도록 모든 것이 준비되었습니다. 내가 출생했을 때 그들이 여아를 정말 원한다는 결정을 한 것을 제외하고는 말이죠.

     

    And 17 years later I did go to college. But I naively chose a college that was almost as expensive as Stanford, and all of my working-class parents' savings were being spent on my college tuition. After six months, I couldn''t see the value in it. I had no idea what I wanted to do with my life and no idea how college was going to help me figure it out. And here I was spending all of the money my parents had saved their entire life. So I decided to drop out and trust that it would all work out OK. It was pretty scary at the time, but looking back it was one of the best decisions I ever made. The minute I dropped out I could stop taking the required classes that didn't interest me, and begin dropping in on the ones that looked interesting.

    17년 후 저는 대학에 입학했습니다. 하지만 순진하게 스텐포드만큼이나 비싼 대학을 선택했고, 노동계층인 부모님의 모든 돈이 내 대학 등록금으로 소진되었습니다. 6개월 후 저는 대학에서 가치를 발견치 못했습니다. 저는 제가 뭘하고 싶은지, 어떻게 대학이 문제를 해결하도록 도울 수 있을지 몰랐습니다. 그리고 저는 대학에서 내 부모님이 전 생애를 통해 벌었던 모든 돈을 쓰고 있었습니다. 그래서 저는 자퇴를 결심했고, 모두 잘 될 것이라는 것을 믿었습니다. 그 순간은 무척 두려웠었지만, 뒤돌아보면 그것은 내가 한 최고의 결정 중 하나였습니다. 학교를 그만둔 그 순간 저는 관심 없었던 필수 과정들을 이수하지 않을 수 있었고, 관심 있어 보이는 과정들을 청강하기 시작했습니다.

     

    It wasn't all romantic. I didn't have a dorm room, so I slept on the floor in friends' rooms, I returned coke bottles for the 5¢deposits to buy food with, and I would walk the 7 miles across town every Sunday night to get one good meal a week at the Hare Krishna temple. I loved it. And much of what I stumbled into by following my curiosity and intuition turned out to be priceless later on. Let me give you one example:

    모두 낭만적인 것은 아니었습니다. 기숙사도 없었고, 친구 집의 바닥에서 잠을 잤고, 먹을 음식을 사기위해 콜라병을 모아 5센트씩 모았고, 매주일 밤에 일주일에 한번 훌륭한(좋은) 음식을 먹기 위해 헤어 크리쉬나 사원까지 기꺼이 7마일을 걷곤했습니다. 그 일을 매우 사랑했습니다. 그리고 나의 호기심과 직관을 따름으로 나를 당황하게 만든 많은 것들이 후에는 가치없는 것임을 깨닫게 되었습니다. 한 가지 예를 들겠습니다.

     

    Reed College at that time offered perhaps the best calligraphy instruction in the country. Throughout the campus every poster, every label on every drawer, was beautifully hand calligraphed. Because I had dropped out and didn't have to take the normal classes, I decided to take a calligraphy class to learn how to do this. I learned about serif and san serif typefaces, about varying the amount of space between different letter combinations, about what makes great typography great. It was beautiful, historical, artistically subtle in a way that science can't capture, and I found it fascinating.

    그 당시에 리드 대학은 우리나라에서 (아마도) 최고의 서법강좌를 제공했던 것 같습니다. 전 캠퍼스의 모든 포스터, 모든 서랍의 라벨은 아름답게 쓰여져 있었습니다. 제가 자퇴하고 정규과정을 수강하지 못했기 때문에 서법을 어떻게 하는지 배우기 위해서 서법 강좌를 수강하기로 결정했고, 저는 serif[(M, H등의 글자에서상하의획에 붙인) 가는장식선, 세리프 ]와 san serif 서체를 배웠습니다. 즉 다른 글자 조합간의 총 공간을 변경하는 것에 관해, 무엇이 서체를 멋지게 만드는 가에 대해 배웠습니다. 이것은 과학이 따라잡을 수 없는 아름답고, 역사적이고 예술적으로 미묘한 것이었고 저는 그것에서 매력을 발견했습니다.

     

    None of this had even a hope of any practical application in my life. But ten years later, when we were designing the first Macintosh computer, it all came back to me. And we designed it all into the Mac. It was the first computer with beautiful typography. If I had never dropped in on that single course in college, the Mac would have never had multiple typefaces or proportionally spaced fonts. And since Windows just copied the Mac, its likely that no personal computer would have them. If I had never dropped out, I would have never dropped in on this calligraphy class, and personal computers might not have the wonderful typography that they do. Of course it was impossible to connect the dots looking forward when I was in college. But it was very, very clear looking backwards ten years later.

    이러한 어떤 것도 내 삶에서 실제적인 적용에 대한 소망을 갖게 하지 못했습니다. 그러나 10년 후 우리가 처음 메켄토시 컴퓨터를 처음 디자인할 때, 그것은 나에게 큰 도움이 되었습니다. 그래서 우리는 맥에 모든 것을 디자인해 넣었습니다. 맥은 아름다운 활자(typography)를 가진 최초의 컴퓨터가 되었습니다. 만약 내가 대학에서 그 과정을 청강하지 않았더라면, 맥은 결코 다양한 서체와 균형 잡힌 자간을 띄운 글자체를 가지지 못했을 것입니다. 윈도우스가 맥을 모방했기 때문에, 개인용 PC가 글자체를 가지지 않은 것이 없는 것처럼 보입니다. 만약 제가 학교를 그만두지 않았다면, 저는 결코 이러한 서체 강좌를 수강하지 못했을 것입니다. 그리고 개인용 컴퓨터들은 아름다운 글자체를 가지지 못했을 것입니다. 물론 내가 대학에 있을 때에는 점들을 앞쪽을 보면서 연결하는 것이 불가능했습니다. 그렇지만 10년이 지난 후 뒤쪽을 돌아보니 아주 아주 명료했습니다.

     

    Again, you can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something - your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.

    다시 말해서, 점들을 앞쪽을 보면서 연결할 수 없습니다. ; 점들을 뒤쪽을 보면서만 연결할 수 있습니다. 그래서 그 점들이 어느 정도 당신의 미래에 연결될 수 있다는 것을 신뢰해야 합니다. 여러분은 무엇인가를 신뢰해야 합니다. 즉 실질, 운명, 삶, 카르마(인연, 숙명) 그 무엇이든. 이런 접근법은 결코 저를 낙담시키지 못했고, 내 삶의 모든 차이를 만들었습니다.

     

    My second story is about love and loss.

    두번째 얘기는 사랑과 상실에 관한 것입니다.

     

    I was lucky? I found what I loved to do early in life. Woz and I started Apple in my parents garage when I was 20. We worked hard, and in 10 years Apple had grown from just the two of us in a garage into a $2 billion company with over 4000 employees. We had just released our finest creation - the Macintosh - a year earlier, and I had just turned 30. And then I got fired. How can you get fired from a company you started? Well, as Apple grew we hired someone who I thought was very talented to run the company with me, and for the first year or so things went well. But then our visions of the future began to diverge and eventually we had a falling out. When we did, our Board of Directors sided with him. So at 30 I was out. And very publicly out. What had been the focus of my entire adult life was gone, and it was devastating.

    저는 운이 좋았습니다. 저는 제가 즐겨할 수 있는 일을 빨리 발견했습니다. Woz와 저는 20세에 아버지의 차고에서 APPLE을 시작했습니다. 우리는 열심히 일했고, 10년만에 애플은 차고의 2명에서 4000명의 직원을 가진 20억불 회사로 성장했습니다. 우리는 우리가 만든 최상의 창조물 -매킨토시-을 1년 더 빨리(29세에) 출시했습니다. 그리고 저는 서른이 되었습니다. 그리고 나서 저는 해고를 당했습니다. 당신이 만든 회사에서 어떻게 해고될 수 있냐구요? 글쎄요, 애플이 성장함에 따라 우리는 저와 회사를 잘 경영할 수 있는 매우 재능있는 누군가를 고용했고 첫해 일은 잘 진행되었습니다. 하지만 미래에 대한 우리의 비젼이 갈라지기 시작했고, 결과적으로 사이가 틀어지게 되었습니다. 그렇게 되었을 때 이사회는 그를 지지했고, 저는 나이 30세 해고를 당했습니다. 아주 공식적으로 해고를 당한 것이죠. 내 전 젊음을 집중했던 것은 사라졌고, 파괴되었습니다.

     

    I really didn't know what to do for a few months. I felt that I had let the previous generation of entrepreneurs down - that I had dropped the baton as it was being passed to me. I met with David Packard and Bob Noyce and tried to apologize for screwing up so badly. I was a very public failure, and I even thought about running away from the valley. But something slowly began to dawn on me? I still loved what I did. The turn of events at Apple had not changed that one bit. I had been rejected, but I was still in love. And so I decided to start over.

    저는 수개월 동안 무엇을 어떻게 해야 할지 알지 못했습니다. 이전 세대 사업가들을 낙담시킨 것처럼 즉 내게 전달된 바톤을 떨어뜨린 것처럼 느꼈습니다. 저는 데이빗, 패커드과 밥 로이스를 만나서 일을 그르치게 한 것에 대해 사과하려고 했습니다. 저는 공적으로 실패했고 심지어 벨리(실리콘?)에서 도망칠 생각까지 했습니다. 하지만 천천히 제게 새벽이 오고 있었습니다. 저는 여전히 제가 한 것을 사랑했습니다. 애플에서의 일련의 사건은 조금도 변화되지 않았습니다. 저는 거절당했지만 여전히 열정이 있었습니다. 그래서 저는 다시 시작하기로 결정했습니다.

     

    I didn't see it then, but it turned out that getting fired from Apple was the best thing that could have ever happened to me. The heaviness of being successful was replaced by the lightness of being a beginner again, less sure about everything. It freed me to enter one of the most creative periods of my life.

    저는 당시에는 알지 못했지만 애플에서 쫓겨난 것은 저에게 있어 가장 최선의 것이었음을 알게 되었습니다. 성공에 대한 중압감이 다시 시작하는 사람의 가벼움으로 바뀌었고, 모든 것에 대해 덜 확신하게 되었습니다. 이러한 것들이 저를 제 삶에서 가장 창의적인 기간 중 하나로 자연스럽게 들어가게 했습니다.

     

    During the next five years, I started a company named NeXT, another company named Pixar, and fell in love with an amazing woman who would become my wife. Pixar went on to create the worlds first computer animated feature film, Toy Story, and is now the most successful animation studio in the world. In a remarkable turn of events, Apple bought NeXT, I retuned to Apple, and the technology we developed at NeXT is at the heart of Apple's current renaissance. And Laurene and I have a wonderful family together.

    다음 5년 동안, 저는 NeXT라는 회사와, Pixar라는 또 다른 회사를 시작했습니다. 그리고 제 부인이 된 굉장한 여성과 사랑에 빠지게 되었습니다. Pixar는 세게 최초 Computer animated feature 영화인 토이스토리를 창조해냈고, 현재는 세계에서 가장 성공적인 애니메니션 스튜디오가 되었습니다. 주목할만한 일련의 변화로 애플은 NeXT사를 샀고, 저는 애플로 돌아오게 되었습니다. NeXT에서 개발된 기술은 애플의 현재 르네상스에 핵심에 있습니다. 그리고 로렌스와 저는 멋진 가족을 만들었습니다.

     

    I'm pretty sure none of this would have happened if I hadn't been fired from Apple. It was awful tasting medicine, but I guess the patient needed it. Sometimes life hits you in the head with a brick. Don't lose faith. I'm convinced that the only thing that kept me going was that I loved what I did. You''ve got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven't found it yet, keep looking. Don't settle. As with all matters of the heart, you'll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don't settle.

    만약 제가 애플에서 해고되지 않았더라면 이런 어떤 일도 발생하지 않았을꺼라고 확신합니다. 지독하게 쓴 약이었지만 저는 환자에게 그런 약이 필요한 것임을 압니다. 때때로 삶이 당신의 머리를 벽돌로 치게 됩니다. 믿음을 잃지 마십시오. 저는 저를 계속 유지하게 하는 유일한 것이 제가 한 것을 사랑하는 것임을 확신합니다. 당신이 사랑하는 것을 찾으십시오. 사랑하는 사람에게 하는 것처럼 일에도 진실하십시오. 여러분의 일이 삶의 많은 부분을 채울 것입니다. 진정으로 만족할 수 있는 유일한 길은 우리가 믿는 일을 하는 것이 위대한 일이라는 것입니다. 그리고 그러한 위대한 일을 하는 것이 여러분이 하는 일을 사랑하는 것입니다. 아직까지 발견하지 못하셨다면, 계속해서 찾으십시오. 안주하지 마세요. 마음의 문제들을 따라가다 보면 언젠가 발견케 될 것이라는 것을 알게 될 것입니다. 어떤 위대한 관계처럼, 세월이 흐르면 점점 좋아지게 됩니다. 찾을 때까지 계속 찾으시고 안주하지 마세요.

     

    My third story is about death.

    세번째 이야기는 죽음에 관한 것입니다.

     

    When I was 17, I read a quote that went something like: "If you live each day as if it was your last, someday you'll most certainly be right." It made an impression on me, and since then, for the past 33 years, I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.

    제가 17세였을 때 “매일 매일을 당신의 마지막 날처럼 사세요, 그러면 언젠가는 당신은 가장 확실하게 내가 옳았어”와 같은 인용문을 읽게 되었습니다. 제게는 인상적이었고, 그 이후로 지난 33년동안 저는 매일 아침 거울을 보면서 제 자신에게 “오늘이 내 생애 마지막 날이라면, 내가 오늘 하고자 하는 것을 하길 원하는가?”라고 자문합니다. 그리고 연속으로 많은 날 동안 “아니오”라고 대답하게 될 때, 저는 무엇인가를 바꾸어야 할 필요가 있음을 압니다.

     

    Remembering that I'll be dead soon is the most important tool I've ever encountered to help me make the big choices in life. Because almost everything ? all external expectations, all pride, all fear of embarrassment or failure - these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart.

    곧 죽게 될꺼라는 것을 기억하는 가장 중요한 즉 제가 삶에서 큰(중요한) 선택을 하도록 돕는 우연하게 마주친 도구입니다. 왜냐하면 거의 모든 것 - 외부적인 기대들, 자신감, 창피함 또는 실패의 두려움- 이런 것들은 죽음의 면전에서 진실로 중요한 것만 남긴 채 사라져 버리고 맙니다. 곧 죽게 될꺼라는 것을 기억하는 것은 여러분이 뭔가를 잃게 될꺼라는 생각의 덫을 피하게 하는 제가 아는 최선의 방법입니다. 여러분은 이미 벌거벗었고, 마음을 따르지 않을 이유가 없습니다.

     

    About a year ago I was diagnosed with cancer. I had a scan at 7:30 in the morning, and it clearly showed a tumor on my pancreas. I didn't even know what a pancreas was. The doctors told me this was almost certainly a type of cancer that is incurable, and that I should expect to live no longer than three to six months. My doctor advised me to go home and get my affairs in order, which is doctor's code for prepare to die. It means to try to tell your kids everything you thought you'd have the next 10 years to tell them in just a few months. It means to make sure everything is buttoned up so that it will be as easy as possible for your family. It means to say your goodbyes.

    1년전쯤, 저는 암 진단을 받았습니다. 저는 오전 7:30에 정밀조사를 받았고, 분명하게 췌장에 종양이 있음을 확인했습니다. 저는 심지어 췌장이 무엇인지도 알지 못했습니다. 의사들은 제게 이것은 치료할 수 없는 형태의 암이라는 것을 말해줬고, 저는 3개월에서 6개월 정도 살 수 있음을 기대해야 했습니다. 제 의사는 집에 돌아가서 일들을 정리하라고 조언했고, 그것이 의사의 죽음에 대한 준비절차였습니다. “그렇게하는 것은 단지 수개월내에 제가 앞으로 10년동안 자녀들에게 하려고 했던 모든 것을 해야 하는 것을 의미합니다. 모든 것을 완벽하게(아래에서 위까지)해서 가족에게 가능한 쉬운 것이 되게 하는 것을 의미합니다.

     

    I lived with that diagnosis all day. Later that evening I had a biopsy, where they stuck an endoscope down my throat, through my stomach and into my intestines, put a needle into my pancreas and got a few cells from the tumor. I was sedated, but my wife, who was there, told me that when they viewed the cells under a microscope the doctors started crying because it turned out to be a very rare form of pancreatic cancer that is curable with surgery. I had the surgery and I'm fine now.

    저는 그런 진단을 받고 하루종일 보냈습니다. 그날 저녁 저는 검사를 했습니다. 즉 목으로 들어가서 위를 통해서 창자속으로 들어가는 내시경을 했습니다. 제 췌장에 바늘을 넣어서 종양으로부터 세포 몇개를 취했습니다. 저는 차분했지만 함께 있던 아내는 의사들이 현미경으로 세포를 검사하면서 소리치기 시작했다고 제게 말했습니다. 왜냐하면 이것은 수술로 치료가 가능한 아주 특이한 형태의 췌장암으로 판명되었기 때문입니다. 저는 수술을 받았고, 현재 건강합니다.

     

    This was the closest I've been to facing death, and I hope its the closest I get for a few more decades. Having lived through it, I can now say this to you with a bit more certainty than when death was a useful but purely intellectual concept:

    이것이 제가 죽음에 직면했던 가장 가까운 것이었고, 이것이 앞으로 수십 년 동안 가장 가까웠던 것이기를 바랍니다. 이 일을 통해서, 저는 현재 여러분께 죽음은 유용한 것이지만, 순수하게 지적 개념이었을 때보다 좀더 확실하게 말할 수 있습니다.

     

    No one wants to die. Even people who want to go to heaven don't want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because Death is very likely the single best invention of Life. It is Life's change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true.

    누구도 죽기를 원치 않습니다. 심지어 천국을 가길 원하는 사람조차도 죽어서 그곳에 도달하길 원치 않습니다. 하지만 죽음은 우리 모두가 공유할 최종 목적지입니다. 누구도 비켜갈 수 없습니다. 또 그렇게 되어야 합니다. 왜냐하면 죽음은 삶의 유일한 최고 발명품이기 때문입니다. 그것은 삶을 변화시키는 대리인입니다. 그것은 새로운 것들을 위해 길을 만들기 위해 오래된 것들을 치우는 것입니다. 바로 지금 새로운 것은 여러분입니다. 그렇지만 현재로부터 멀지 않은 어느날 여러분은 점차 오래된 것이 되어 치워지게 될 것입니다. 너무 극적인 것 같아 미안하지만 완전한 사실입니다.

     

    Your time is limited, so don't waste it living someone else's life. Don't be trapped by dogma - which is living with the results of other people's thinking. Don't let the noise of other's opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.

    여러분의 시간은 제한되어있습니다. 그래서 다른 어떤 사람의 삶을 사는 것처럼 시간을 낭비하지 마세요. 다른 사람들의 생각의 결과로 살아가는 독단에 빠지지 마세요. 내면의 소리를 소멸시키는 다른 사람들의 의견을 허락하지 마세요. 그리고 무엇보다 중요한 것, 여러분의 마음과 직관을 따르는 용기를 가지세요. 여러분은 이미 어느 정도 여러분이 진정 되고 싶어 하는 것이 무엇인지 알고 있습니다. 그 외의 것은 부차적인 것입니다.

     

    When I was young, there was an amazing publication called The Whole Earth Catalog, which was one of the bibles of my generation. It was created by a fellow named Stewart Brand not far from here in Menlo Park, and he brought it to life with his poetic touch. This was in the late 1960's, before personal computers and desktop publishing, so it was all made with typewriters, scissors, and polaroid cameras. It was sort of like Google in paperback form, 35 years before Google came along: it was idealistic, and overflowing with neat tools and great notions.

    제가 어렸을 대 “The Whole Earth Catalog"라고 불리던 놀라운 출판물이 있었습니다. 그것은 우리세대에 바이블과 같았습니다. 그 출판물은 여기서 멀지 않은 Menlo park의 Stewart Brand라는 분에 의해 창조되었습니다. 그리고 그는 거기에 그의 시적인 솜씨를 더해 생명을 불어넣었습니다. 이때는 개인용 컴퓨터와 데스크탑으로 출판되기 이전인 1960년대 후반이었습니다. 출판물은 타자기, 가위, 폴라로이드 카메라로 모두 만들어졌습니다. 이것은 종이 형태로 만들어진, 구글이 사용되기 35년 전의 종이형태의 구글이었습니다. 이상적이었고 간결한 도구와 위대한 개념들이 흘러넘쳤습니다.

     

    Stewart and his team put out several issues of The Whole Earth Catalog, and then when it had run its course, they put out a final issue. It was the mid-1970s, and I was your age. On the back cover of their final issue was a photograph of an early morning country road, the kind you might find yourself hitchhiking on if you were so adventurous. Beneath it were the words: "Stay Hungry. Stay Foolish." It was their farewell message as they signed off. Stay Hungry. Stay Foolish. And I have always wished that for myself. And now, as you graduate to begin anew, I wish that for you.

    스튜터트와 그의 팀은 “The Whole Earth Catalog"를 수차례 발행했고, 그 과정을 개설하면서 최종본을 발행했습니다. 그 때가 1970년대 중반이었고 저는 여러분의 나이였습니다. 그 최종본의 뒤쪽 커버에는 이른아침 시골 길 사진이 있었고, 만약 당신이 모험심이 강했더라면, 히치하이킹하는 당신 자신을 발견했을지도 모릅니다. 그 그림 아래에 ”배고픈 채로, 어리석은 채로 머물라“라는 구절이 있었습니다. 이것이 그들이 발행을 마치면서한 고별 메시지였습니다. 그리고 저는 항상 내 스스로를 그렇게 되길 바랬습니다. 그리고 현재 졸업으로 새롭게 시작하는 여러분이 그렇게 되길 바랍니다.

     

    Stay Hungry. Stay Foolish.

    배고픈 채로, 어리석은 채로 머물라.

     

    Thank you all very much.

    고맙습니다.

     

     

    사용자 삽입 이미지
     MyBrainz...#1

    예병일님이 발행하는 "예병일의 경제노트" 메일링 7월 18일자에 붙어서 온 전문과 번역문입니다. 번역에는 "예병일의 경제노트"의 식구인 춘천에 사시는 "김현중"님의 작품입니다. 다시 한번 좋은 글 감사 드립니다.

     

    원문인 경제노트 메일링글은이곳(http://blog.naver.com/mybrainz/140015177062)에서 보실 수 있습니다.

     

    영문 원문은 스탠포트대학의 웹사이트중이곳(http://news-service.stanford.edu/news/2005/june15/jobs-061505.html) 곳에서 보실 수 있습니다.

     

    사용자 삽입 이미지
     MyBrainz...#2

    동영상으로 졸업식 연설문 한번 들어 보실레요?


    출처 : Stanford News Service
    http://news-service.stanford.edu/news/2005/june15/videos/51.html

     

     

    사용자 삽입 이미지
     MyBrainz...#3

    아래 이미지들은 졸업식 행사 사진중 스트브 잡스 사진 몇컷...

    사용자 삽입 이미지

    Commencement speaker Steve Jobs (holding documents) departs Stanford Stadium with, from left, the Rev. Scotty McLennan, Provost John Etchemendy and Board of Trustees Chairman Burt McMurtry, among other university officials.

    (출처 :http://news-service.stanford.edu/news/2005/june15/slideshow/grad-061505-22.html)

     

    사용자 삽입 이미지

    Steve Jobs, CEO of Apple Computer and Pixar Animation Studios, delivered the the Commencement address June 12, 2005.

    (출처 :http://news-service.stanford.edu/news/2005/june15/slideshow/grad-061505-20.html)




      Comments,     Trackbacks
    매일을 인생의 마지막 날처럼, stay hungry, stay foolish의 자세로
    사용자 삽입 이미지
    사용자 삽입 이미지
    2005년 7월 18일 월요일

    매일을 인생의 마지막 날처럼, stay hungry, stay foolish의 자세로

    (예병일의 경제노트, 2005.7.18)

    When I was 17, I read a quote that went something like: "If you live each day as if it was your last, someday you''ll most certainly be right."
    It made an impression on me, and since then, for the past 33 years, I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?"
    And whenever the answer has been "No" for too many days in a row, I know I need to change something.

    On the back cover of their final issue was a photograph of an early morning country road, the kind you might find yourself hitchhiking on if you were so adventurous.
    Beneath it were the words: "Stay Hungry. Stay Foolish."
    It was their farewell message as they signed off. Stay Hungry. Stay Foolish. And I have always wished that for myself. And now, as you graduate to begin anew, I wish that for you.

    Stay Hungry. Stay Foolish.

    스티브 잡스의 '스탠포드대학 학위수여식 연설문' 중에서 (2005.6.12)



    애플의 창업자 스티브 잡스는 매일 아침 거울을 보며 자신에게 물었습니다.
    “오늘이 내 생애의 마지막 날이라면, 나는 내가 오늘 하려 하는 것을 하길 진정으로 원하는가?”
    그리고 "아니다"라는 대답이 여러번 나오면, 무언가를 바꿔야한다고 깨닫곤 했습니다.
    그는 17세였을 때 “매일 매일을 당신의 마지막 날처럼 사세요"라는 글을 본 이후 매일 그렇게 자신에게 질문을 던졌습니다.

    누구도 죽음을 피할 수는 없습니다. 하지만 대부분의 사람들은 그 사실을 인식하지 않고 살아갑니다. 영원히 살 것처럼 살아갑니다.
    내가 '곧'(soon) 죽을 것이라 생각하며 살아갈 수 있다면(1개월 후, 10년 후, 50년 후도 결국은 '곧'입니다), 세상은, 삶은 많이 다르게 다가올 것 같습니다.
    실패에 대한 두려움, 창피함, 헛된 욕심... 대부분의 고민들은 그 죽음 앞에서는 사라져버릴 것이고, 나의 '내면'의 목소리에 따라 결정하고 살아갈 수 있을 겁니다.

    대사가 정확히 기억은 나지 않지만, '죽은 시인의 사회'라는 영화에서 키팅 선생님(로빈 윌리암스)이 학생들에게 벽에 걸려 있는 선배들의 옛 사진을 보여주며 말합니다. 모두들 젊고 당당한 모습들이지만, 지금 이들은 모두 죽어 흙이 되었다고.

    스티브 잡스도 사회에 갓 진출하는 스탠포드 대학 졸업생들에게 죽음에 대해 말했습니다.
    "그것(죽음)은 새로운 것들을 위해 길을 만들기 위해 오래된 것들을 치우는 것입니다. 지금 새로운 것은 여러분입니다. 하지만 멀지 않은 어느날 여러분은 점차 오래된 것이 되어 치워지게 될 것입니다. 너무 극적인 표현이라 미안하지만 사실입니다."

    스티브 잡스는 오늘이 내 생애의 마지막 날이라 생각하며 나의 내면이 원하는, 내가 진정 원하는 것을 찾으라고 말합니다.
    그리고 그가 젊은 시절 접했던 문구를 소개합니다.
    "Stay Hungry. Stay Foolish."

    내가 진정 원하는 것을 이루기 위해 항상 배고프고 허기진 적극적인 자세로 임하자. "이 정도면 됐다"고 안일하게 만족하며 지내지 말자.
    그리고 그것을 이루기 위해 작은 이익에 타협하지 말고 바보처럼 고지식하고 우직하게 살아가자.

    매일 매일을 인생의 마지막 날처럼, 그리고 'Stay Hungry. Stay Foolish'라는 자세를 견지하며 살아갔으면 좋겠습니다.

    * * *

    1. 내일(19일 화요일) 저녁 7시 경제노트 오프라인 첫 모임이 열립니다.
    등록해주신 300분께는 오늘 참석 확인 메일을 보내드렸습니다. 사정이 생겨서 불참하시는 분들이 많을 경우, 대기자로 등록해주신 분들께 순서에 따라 참석가능 메일을 보내드리도록 하겠습니다.

    2. 내일 모임에서 '자원봉사자'로 도와주실 수 있는 가족분이 계시면 댓글로 알려주시면 고맙겠습니다. 30분 전에 오셔서 현장 안내를 도와주시면 되겠습니다.

    3. 춘천에 계신 김현중 가족님께서 스티브 잡스의 연설문을 번역해서 보내주셨습니다.
    김현중 가족님의 글을 보고, 오늘 스티브 잡스의 연설문을 다시 한번 되새겨 보았습니다. 다른 분들께도 도움이 될 것 같아 아래에 번역문을 첨부합니다.
    경제노트 가족들을 위해 귀한 시간을 내서 번역을 해주신 김현중 님께 진심으로 감사드립니다.

    * * *

    보내주신 내용의 전문을 읽다가 문득 번역을 해 보고 싶은 생각이 들어 번역을 해 보았습니다. 짧은 영어라 부분부분 좀 어색한 부분도 있을테지만 최선을 다했습니다.
    매번 값진 글들에 감사하고, 101가지 비타민은 두고두고 보고픈 좋은 책입니다.
    좋은 저녁되세요.

    Stanford Report, June 14, 2005
    ''You''ve got to find what you love,'' Jobs says

    This is the text of the Commencement address by Steve Jobs, CEO of Apple Computer and of Pixar Animation Studios, delivered on June 12, 2005.
    ( 이것은 2005년 6월 12일에 애풀컴퓨터와 픽사 애니메이션 스튜디오의 CEO인 스티븐 잡스의 졸업식 연설문입니다. )

    I am honored to be with you today at your commencement from one of the finest universities in the world.
    I never graduated from college. Truth be told, this is the closest I''ve ever gotten to a college graduation. Today I want to tell you three stories from my life. That''s it. No big deal. Just three stories.
    (저는 오늘 전세계에서 최고 대학 중 하나인 스텐포드 대학 졸업식에 여러분과 함께하게 되어 영광입니다. 저는 대학을 졸업하지 못했습니다. 진실을 말하면, 이번이 대학 졸업식에 가장 가까이 온 것입니다. 오늘 저는 제 삶에서 3가지 얘기를 하려고 합니다)

    The first story is about connecting the dots.
    (첫번째 얘기는 점들을 연결하는 것에 관한 것입니다.)

    I dropped out of Reed College after the first 6 months, but then stayed around as a drop-in for another 18 months or so before I really quit. So why did I drop out?
    (저는 리드 컬리지를 첫 6개월동안 다닌 후 자퇴했습니다. 하지만 정말 자퇴하기 전에 그 후 18개월동안 청강생으로 주위에 머룰렀습니다. 왜 제가 자퇴를 했을까요?)

    It started before I was born. My biological mother was a young, unwed college graduate student, and she decided to put me up for adoption. She felt very strongly that I should be adopted by college graduates, so everything was all set for me to be adopted at birth by a lawyer and his wife. Except that when I popped out they decided at the last minute that they really wanted a girl. So my parents, who were on a waiting list, got a call in the middle of the night asking: "We have an unexpected baby boy; do you want him?" They said: "Of course." My biological mother later found out that my mother had never graduated from college and that my father had never graduated from high school. She refused to sign the final adoption papers. She only relented a few months later when my parents promised that I would someday go to college.
    (제가 태어나기 전 내 어머니(생모)는 젊고, 결혼도 하지 않은 대학 졸업생이어서 저를 입양시키기로 결정했습니다. 어머니는 제가 대학 졸업자에 의해 양자삼아주기 강하게 원하셨고, 태어나면 변호사와 그의 부인에게 입양되도록 모든 것이 준비되었습니다. 내가 출생했을 때 그들이 여아를 정말 원한다는 결정을 한 것을 제외하고는 말이죠)

    And 17 years later I did go to college. But I naively chose a college that was almost as expensive as Stanford, and all of my working-class parents'' savings were being spent on my college tuition. After six months, I couldn''t see the value in it. I had no idea what I wanted to do with my life and no idea how college was going to help me figure it out. And here I was spending all of the money my parents had saved their entire life. So I decided to drop out and trust that it would all work out OK. It was pretty scary at the time, but looking back it was one of the best decisions I ever made. The minute I dropped out I could stop taking the required classes that didn''t interest me, and begin dropping in on the ones that looked interesting.
    (17년 후 저는 대학에 입학했습니다. 하지만 순진하게 스텐포드만큼이나 비싼 대학을 선택했고, 노동계층인 부모님의 모든 돈이 내 대학 등록금으로 소진되었습니다. 6개월 후 저는 대학에서 가치를 발견치 못했습니다. 저는 제가 뭘하고 싶은지, 어떻게 대학이 문제를 해결하도록 도울 수 있을지 몰랐습니다. 그리고 저는 대학에서 내 부모님이 전 생애를 통해 벌었던 모든 돈을 쓰고 있었습니다. 그래서 저는 자퇴를 결심했고, 모두 잘 될 것이라는 것을 믿었습니다. 그 순간은 무척 두려웠었지만, 뒤돌아보면 그것은 내가 한 최고의 결정 중 하나였습니다. 학교를 그만둔 그 순간 저는 관심 없었던 필수 과정들을 이수하지 않을 수 있었고, 관심 있어 보이는 과정들을 청강하기 시작했습니다.)

    It wasn''t all romantic. I didn''t have a dorm room, so I slept on the floor in friends'' rooms, I returned coke bottles for the 5? deposits to buy food with, and I would walk the 7 miles across town every Sunday night to get one good meal a week at the Hare Krishna temple. I loved it. And much of what I stumbled into by following my curiosity and intuition turned out to be priceless later on. Let me give you one example:
    Reed College at that time offered perhaps the best calligraphy instruction in the country. Throughout the campus every poster, every label on every drawer, was beautifully hand calligraphed. Because I had dropped out and didn''t have to take the normal classes, I decided to take a calligraphy class to learn how to do this. I learned about serif and san serif typefaces, about varying the amount of space between different letter combinations, about what makes great typography great. It was beautiful, historical, artistically subtle in a way that science can''t capture, and I found it fascinating.
    (모두 낭만적인 것은 아니었습니다. 기숙사도 없었고, 친구 집의 바닥에서 잠을 잤고, 먹을 음식을 사기위해 콜라병을 모아 5센트씩 모았고, 매주일 밤에 일주일에 한번 훌륭한(좋은) 음식을 먹기 위해 헤어 크리쉬나 사원까지 기꺼이 7마일을 걷곤했습니다. 그 일을 매우 사랑했습니다. 그리고 나의 호기심과 직관을 따름으로 나를 당황하게 만든 많은 것들이 후에는 가치없는 것임을 깨닫게 되었습니다.
    한 가지 예를 들겠습니다. 그 당시에 리드 대학은 우리나라에서 (아마도) 최고의 서법강좌를 제공했던 것 같습니다. 전 캠퍼스의 모든 포스터, 모든 서랍의 라벨은 아름답게 쓰여져 있었습니다. 제가 자퇴하고 정규과정을 수강하지 못했기 때문에 서법을 어떻게 하는지 배우기 위해서 서법 강좌를 수강하기로 결정했고, 저는 serif[(M, H등의 글자에서상하의획에 붙인) 가는장식선, 세리프 ]와 san serif 서체를 배웠습니다. 즉 다른 글자 조합간의 총 공간을 변경하는 것에 관해, 무엇이 서체를 멋지게 만드는 가에 대해 배웠습니다. 이것은 과학이 따라잡을 수 없는 아름답고, 역사적이고 예술적으로 미묘한 것이었고 저는 그것에서 매력을 발견했습니다.)

    None of this had even a hope of any practical application in my life. But ten years later, when we were designing the first Macintosh computer, it all came back to me. And we designed it all into the Mac. It was the first computer with beautiful typography. If I had never dropped in on that single course in college, the Mac would have never had multiple typefaces or proportionally spaced fonts. And since Windows just copied the Mac, its likely that no personal computer would have them. If I had never dropped out, I would have never dropped in on this calligraphy class, and personal computers might not have the wonderful typography that they do. Of course it was impossible to connect the dots looking forward when I was in college. But it was very, very clear looking backwards ten years later.

    Again, you can''t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something - your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.
    (이러한 어떤 것도 내 삶에서 실제적인 적용에 대한 소망을 갖게 하지 못했습니다. 그러나 10년 후 우리가 처음 메켄토시 컴퓨터를 처음 디자인할 때, 그것은 나에게 큰 도움이 되었습니다. 그래서 우리는 맥에 모든 것을 디자인해 넣었습니다. 맥은 아름다운 활자(typography)를 가진 최초의 컴퓨터가 되었습니다. 만약 내가 대학에서 그 과정을 청강하지 않았더라면, 맥은 결코 다양한 서체와 균형 잡힌 자간을 띄운 글자체를 가지지 못했을 것입니다. 윈도우스가 맥을 모방했기 때문에, 개인용 PC가 글자체를 가지지 않은 것이 없는 것처럼 보입니다. 만약 제가 학교를 그만두지 않았다면, 저는 결코 이러한 서체 강좌를 수강하지 못했을 것입니다. 그리고 개인용 컴퓨터들은 아름다운 글자체를 가지지 못했을 것입니다. 물론 내가 대학에 있을 때에는 점들을 앞쪽을 보면서 연결하는 것이 불가능했습니다. 그렇지만 10년이 지난 후 뒤쪽을 돌아보니 아주 아주 명료했습니다. 다시 말해서, 점들을 앞쪽을 보면서 연결할 수 없습니다. ; 점들을 뒤쪽을 보면서만 연결할 수 있습니다. 그래서 그 점들이 어느 정도 당신의 미래에 연결될 수 있다는 것을 신뢰해야 합니다. 여러분은 무엇인가를 신뢰해야 합니다. 즉 실질, 운명, 삶, 카르마(인연, 숙명) 그 무엇이든. 이런 접근법은 결코 저를 낙담시키지 못했고, 내 삶의 모든 차이를 만들었습니다.)

    My second story is about love and loss.
    (두번째 얘기는 사랑과 상실에 관한 것입니다.)

    I was lucky ? I found what I loved to do early in life. Woz and I started Apple in my parents garage when I was 20. We worked hard, and in 10 years Apple had grown from just the two of us in a garage into a $2 billion company with over 4000 employees. We had just released our finest creation - the Macintosh - a year earlier, and I had just turned 30. And then I got fired. How can you get fired from a company you started? Well, as Apple grew we hired someone who I thought was very talented to run the company with me, and for the first year or so things went well. But then our visions of the future began to diverge and eventually we had a falling out. When we did, our Board of Directors sided with him. So at 30 I was out. And very publicly out. What had been the focus of my entire adult life was gone, and it was devastating.
    (저는 운이 좋았습니다. 저는 제가 즐겨할 수 있는 일을 빨리 발견했습니다. Woz와 저는 20세에 아버지의 차고에서 APPLE을 시작했습니다. 우리는 열심히 일했고, 10년만에 애플은 차고의 2명에서 4000명의 직원을 가진 20억불 회사로 성장했습니다. 우리는 우리가 만든 최상의 창조물 -매킨토시-을 1년 더 빨리(29세에) 출시했습니다. 그리고 저는 서른이 되었습니다. 그리고 나서 저는 해고를 당했습니다. 당신이 만든 회사에서 어떻게 해고될 수 있냐구요? 글쎄요, 애플이 성장함에 따라 우리는 저와 회사를 잘 경영할 수 있는 매우 재능있는 누군가를 고용했고 첫해 일은 잘 진행되었습니다. 하지만 미래에 대한 우리의 비젼이 갈라지기 시작했고, 결과적으로 사이가 틀어지게 되었습니다. 그렇게 되었을 때 이사회는 그를 지지했고, 저는 나이 30세 해고를 당했습니다. 아주 공식적으로 해고를 당한 것이죠. 내 전 젊음을 집중했던 것은 사라졌고, 파괴되었습니다.)

    I really didn''t know what to do for a few months. I felt that I had let the previous generation of entrepreneurs down - that I had dropped the baton as it was being passed to me. I met with David Packard and Bob Noyce and tried to apologize for screwing up so badly. I was a very public failure, and I even thought about running away from the valley. But something slowly began to dawn on me ? I still loved what I did. The turn of events at Apple had not changed that one bit. I had been rejected, but I was still in love. And so I decided to start over.
    (저는 수개월 동안 무엇을 어떻게 해야 할지 알지 못했습니다. 이전 세대 사업가들을 낙담시킨 것처럼 즉 내게 전달된 바톤을 떨어뜨린 것처럼 느꼈습니다. 저는 데이빗, 패커드과 밥 로이스를 만나서 일을 그르치게 한 것에 대해 사과하려고 했습니다. 저는 공적으로 실패했고 심지어 벨리(실리콘?)에서 도망칠 생각까지 했습니다. 하지만 천천히 제게 새벽이 오고 있었습니다. 저는 여전히 제가 한 것을 사랑했습니다. 애플에서의 일련의 사건은 조금도 변화되지 않았습니다. 저는 거절당했지만 여전히 열정이 있었습니다. 그래서 저는 다시 시작하기로 결정했습니다.)

    I didn''t see it then, but it turned out that getting fired from Apple was the best thing that could have ever happened to me. The heaviness of being successful was replaced by the lightness of being a beginner again, less sure about everything. It freed me to enter one of the most creative periods of my life.
    (저는 당시에는 알지 못했지만 애플에서 쫓겨난 것은 저에게 있어 가장 최선의 것이었음을 알게 되었습니다. 성공에 대한 중압감이 다시 시작하는 사람의 가벼움으로 바뀌었고, 모든 것에 대해 덜 확신하게 되었습니다. 이러한 것들이 저를 제 삶에서 가장 창의적인 기간 중 하나로 자연스럽게 들어가게 했습니다. )

    During the next five years, I started a company named NeXT, another company named Pixar, and fell in love with an amazing woman who would become my wife. Pixar went on to create the worlds first computer animated feature film, Toy Story, and is now the most successful animation studio in the world. In a remarkable turn of events, Apple bought NeXT, I retuned to Apple, and the technology we developed at NeXT is at the heart of Apple''s current renaissance. And Laurene and I have a wonderful family together.
    (다음 5년 동안, 저는 NeXT라는 회사와, Pixar라는 또 다른 회사를 시작했습니다. 그리고 제 부인이 된 굉장한 여성과 사랑에 빠지게 되었습니다. Pixar는 세게 최초 Computer animated feature 영화인 토이스토리를 창조해냈고, 현재는 세계에서 가장 성공적인 애니메니션 스튜디오가 되었습니다. 주목할만한 일련의 변화로 애플은 NeXT사를 샀고, 저는 애플로 돌아오게 되었습니다. NeXT에서 개발된 기술은 애플의 현재 르네상스에 핵심에 있습니다. 그리고 로렌스와 저는 멋진 가족을 만들었습니다.)

    I''m pretty sure none of this would have happened if I hadn''t been fired from Apple. It was awful tasting medicine, but I guess the patient needed it. Sometimes life hits you in the head with a brick. Don''t lose faith. I''m convinced that the only thing that kept me going was that I loved what I did. You''ve got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven''t found it yet, keep looking. Don''t settle. As with all matters of the heart, you''ll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don''t settle.
    (만약 제가 애플에서 해고되지 않았더라면 이런 어떤 일도 발생하지 않았을꺼라고 확신합니다. 지독하게 쓴 약이었지만 저는 환자에게 그런 약이 필요한 것임을 압니다. 때때로 삶이 당신의 머리를 벽돌로 치게 됩니다. 믿음을 잃지 마십시오. 저는 저를 계속 유지하게 하는 유일한 것이 제가 한 것을 사랑하는 것임을 확신합니다. 당신이 사랑하는 것을 찾으십시오. 사랑하는 사람에게 하는 것처럼 일에도 진실하십시오. 여러분의 일이 삶의 많은 부분을 채울 것입니다. 진정으로 만족할 수 있는 유일한 길은 우리가 믿는 일을 하는 것이 위대한 일이라는 것입니다. 그리고 그러한 위대한 일을 하는 것이 여러분이 하는 일을 사랑하는 것입니다. 아직까지 발견하지 못하셨다면, 계속해서 찾으십시오. 안주하지 마세요. 마음의 문제들을 따라가다 보면 언젠가 발견케 될 것이라는 것을 알게 될 것입니다. 어떤 위대한 관계처럼, 세월이 흐르면 점점 좋아지게 됩니다. 찾을 때까지 계속 찾으시고 안주하지 마세요.)

    My third story is about death.
    (세번째 이야기는 죽음에 관한 것입니다.)

    When I was 17, I read a quote that went something like: "If you live each day as if it was your last, someday you''ll most certainly be right." It made an impression on me, and since then, for the past 33 years, I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.
    (제가 17세였을 때 “매일 매일을 당신의 마지막 날처럼 사세요, 그러면 언젠가는 당신은 가장 확실하게 내가 옳았어”와 같은 인용문을 읽게 되었습니다. 제게는 인상적이었고, 그 이후로 지난 33년동안 저는 매일 아침 거울을 보면서 제 자신에게 “오늘이 내 생애 마지막 날이라면, 내가 오늘 하고자 하는 것을 하길 원하는가?”라고 자문합니다. 그리고 연속으로 많은 날 동안 “아니오”라고 대답하게 될 때, 저는 무엇인가를 바꾸어야 할 필요가 있음을 압니다.)

    Remembering that I''ll be dead soon is the most important tool I''ve ever encountered to help me make the big choices in life. Because almost everything ? all external expectations, all pride, all fear of embarrassment or failure - these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart.
    (곧 죽게 될꺼라는 것을 기억하는 가장 중요한 즉 제가 삶에서 큰(중요한) 선택을 하도록 돕는 우연하게 마주친 도구입니다. 왜냐하면 거의 모든 것 - 외부적인 기대들, 자신감, 창피함 또는 실패의 두려움- 이런 것들은 죽음의 면전에서 진실로 중요한 것만 남긴 채 사라져 버리고 맙니다. 곧 죽게 될꺼라는 것을 기억하는 것은 여러분이 뭔가를 잃게 될꺼라는 생각의 덫을 피하게 하는 제가 아는 최선의 방법입니다. 여러분은 이미 벌거벗었고, 마음을 따르지 않을 이유가 없습니다.)

    About a year ago I was diagnosed with cancer. I had a scan at 7:30 in the morning, and it clearly showed a tumor on my pancreas. I didn''t even know what a pancreas was. The doctors told me this was almost certainly a type of cancer that is incurable, and that I should expect to live no longer than three to six months. My doctor advised me to go home and get my affairs in order, which is doctor''s code for prepare to die. It means to try to tell your kids everything you thought you''d have the next 10 years to tell them in just a few months. It means to make sure everything is buttoned up so that it will be as easy as possible for your family. It means to say your goodbyes.
    (1년전쯤, 저는 암 진단을 받았습니다. 저는 오전 7:30에 정밀조사를 받았고, 분명하게 췌장에 종양이 있음을 확인했습니다. 저는 심지어 췌장이 무엇인지도 알지 못했습니다. 의사들은 제게 이것은 치료할 수 없는 형태의 암이라는 것을 말해줬고, 저는 3개월에서 6개월 정도 살 수 있음을 기대해야 했습니다. 제 의사는 집에 돌아가서 일들을 정리하라고 조언했고, 그것이 의사의 죽음에 대한 준비절차였습니다. “그렇게하는 것은 단지 수개월내에 제가 앞으로 10년동안 자녀들에게 하려고 했던 모든 것을 해야 하는 것을 의미합니다. 모든 것을 완벽하게(아래에서 위까지)해서 가족에게 가능한 쉬운 것이 되게 하는 것을 의미합니다.

    I lived with that diagnosis all day. Later that evening I had a biopsy, where they stuck an endoscope down my throat, through my stomach and into my intestines, put a needle into my pancreas and got a few cells from the tumor. I was sedated, but my wife, who was there, told me that when they viewed the cells under a microscope the doctors started crying because it turned out to be a very rare form of pancreatic cancer that is curable with surgery. I had the surgery and I''m fine now.
    (저는 그런 진단을 받고 하루종일 보냈습니다. 그날 저녁 저는 검사를 했습니다. 즉 목으로 들어가서 위를 통해서 창자속으로 들어가는 내시경을 했습니다. 제 췌장에 바늘을 넣어서 종양으로부터 세포 몇개를 취했습니다. 저는 차분했지만 함께 있던 아내는 의사들이 현미경으로 세포를 검사하면서 소리치기 시작했다고 제게 말했습니다. 왜냐하면 이것은 수술로 치료가 가능한 아주 특이한 형태의 췌장암으로 판명되었기 때문입니다. 저는 수술을 받았고, 현재 건강합니다.)

    This was the closest I''ve been to facing death, and I hope its the closest I get for a few more decades. Having lived through it, I can now say this to you with a bit more certainty than when death was a useful but purely intellectual concept:
    No one wants to die. Even people who want to go to heaven don''t want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because Death is very likely the single best invention of Life. It is Life''s change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true.
    (이것이 제가 죽음에 직면했던 가장 가까운 것이었고, 이것이 앞으로 수십 년 동안 가장 가까웠던 것이기를 바랍니다. 이 일을 통해서, 저는 현재 여러분께 죽음은 유용한 것이지만, 순수하게 지적 개념이었을 때보다 좀더 확실하게 말할 수 있습니다. 누구도 죽기를 원치 않습니다. 심지어 천국을 가길 원하는 사람조차도 죽어서 그곳에 도달하길 원치 않습니다. 하지만 죽음은 우리 모두가 공유할 최종 목적지입니다. 누구도 비켜갈 수 없습니다. 또 그렇게 되어야 합니다. 왜냐하면 죽음은 삶의 유일한 최고 발명품이기 때문입니다. 그것은 삶을 변화시키는 대리인입니다. 그것은 새로운 것들을 위해 길을 만들기 위해 오래된 것들을 치우는 것입니다. 바로 지금 새로운 것은 여러분입니다. 그렇지만 현재로부터 멀지 않은 어느날 여러분은 점차 오래된 것이 되어 치워지게 될 것입니다. 너무 극적인 것 같아 미안하지만 완전한 사실입니다.)

    Your time is limited, so don''t waste it living someone else''s life. Don''t be trapped by dogma - which is living with the results of other people''s thinking. Don''t let the noise of other''s opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.
    (여러분의 시간은 제한되어있습니다. 그래서 다른 어떤 사람의 삶을 사는 것처럼 시간을 낭비하지 마세요. 다른 사람들의 생각의 결과로 살아가는 독단에 빠지지 마세요. 내면의 소리를 소멸시키는 다른 사람들의 의견을 허락하지 마세요. 그리고 무엇보다 중요한 것, 여러분의 마음과 직관을 따르는 용기를 가지세요. 여러분은 이미 어느 정도 여러분이 진정 되고 싶어 하는 것이 무엇인지 알고 있습니다. 그 외의 것은 부차적인 것입니다.)

    When I was young, there was an amazing publication called The Whole Earth Catalog, which was one of the bibles of my generation. It was created by a fellow named Stewart Brand not far from here in Menlo Park, and he brought it to life with his poetic touch. This was in the late 1960''s, before personal computers and desktop publishing, so it was all made with typewriters, scissors, and polaroid cameras. It was sort of like Google in paperback form, 35 years before Google came along: it was idealistic, and overflowing with neat tools and great notions.
    (제가 어렸을 대 “The Whole Earth Catalog"라고 불리던 놀라운 출판물이 있었습니다. 그것은 우리세대에 바이블과 같았습니다. 그 출판물은 여기서 멀지 않은 Menlo park의 Stewart Brand라는 분에 의해 창조되었습니다. 그리고 그는 거기에 그의 시적인 솜씨를 더해 생명을 불어넣었습니다. 이때는 개인용 컴퓨터와 데스크탑으로 출판되기 이전인 1960년대 후반이었습니다. 출판물은 타자기, 가위, 폴라로이드 카메라로 모두 만들어졌습니다. 이것은 종이 형태로 만들어진, 구글이 사용되기 35년 전의 종이형태의 구글이었습니다. 이상적이었고 간결한 도구와 위대한 개념들이 흘러넘쳤습니다.)

    Stewart and his team put out several issues of The Whole Earth Catalog, and then when it had run its course, they put out a final issue. It was the mid-1970s, and I was your age. On the back cover of their final issue was a photograph of an early morning country road, the kind you might find yourself hitchhiking on if you were so adventurous. Beneath it were the words: "Stay Hungry. Stay Foolish." It was their farewell message as they signed off. Stay Hungry. Stay Foolish. And I have always wished that for myself. And now, as you graduate to begin anew, I wish that for you.
    Stay Hungry. Stay Foolish.
    Thank you all very much.
    (스튜터트와 그의 팀은 “The Whole Earth Catalog"를 수차례 발행했고, 그 과정을 개설하면서 최종본을 발행했습니다. 그 때가 1970년대 중반이었고 저는 여러분의 나이였습니다. 그 최종본의 뒤쪽 커버에는 이른아침 시골 길 사진이 있었고, 만약 당신이 모험심이 강했더라면, 히치하이킹하는 당신 자신을 발견했을지도 모릅니다. 그 그림 아래에 ”배고픈 채로, 어리석은 채로 머물라“라는 구절이 있었습니다. 이것이 그들이 발행을 마치면서한 고별 메시지였습니다. 그리고 저는 항상 내 스스로를 그렇게 되길 바랬습니다. 그리고 현재 졸업으로 새롭게 시작하는 여러분이 그렇게 되길 바랍니다. 배고픈 채로, 어리석은 채로 머물라. 고맙습니다.)

    춘천에서 경제노트 가족 김현중
      Comments,     Trackbacks
    “Coalition Summit for IPv6“

    “Coalition Summit for IPv6“


    1. 행사 개요

      o 기간 : 2005. 5. 22 ~ 5. 29
      o 장소 : 하얏트호텔, Reston, 미국

    2. 주요 행사 내용

     □ Coalition Summit for IPv6 주요 발표 내용

        o 각국 군사 및 IPv6 관계자 500여명이 등록하였으며 각국의 군사 담당자, 정부관계자 및
           산업체 CEO/CTO 등 40명이 발표

        o미국은 DoD, 육해공군의 3성장군 및 장교, 국무부, 해양시스템국, 등 Director, 미연방의회
           하원, 그리고 시스코, 주니퍼, MS 등 산업체의 CEO/CTO 등이 IPv6 추진 현황을 발표하였음
            - 미군의 IPv6 추진은 DoD가 미군 전체의 IPv6 추진전략 및 가이드를 제공하고
               육해공군은 세부 IPv6 이행 방법을 수립하여 추진
            - 2003년부터 DoD는 IPv6 추진을 결정

    사용자 삽입 이미지

     

            -미군은 네트워크 중심 전술망 구축, 이동성, 보안, QoS 등 IPv6의 장점 활용, 동맹군과의
               연합작전 능력 향상 등을 위하여 IPv6 도입

               ※ IPv6의 Mobility를 이용한 Mobile space, Mobile Air, Mobile Land, Mobile Sea 구축


    사용자 삽입 이미지

     

            - 또한 육-해-공군간 서로 다른 시스템을 IPv6 도입과 함께 표준화 하고자 함
               (Lt. Gen., U.S Joint Forces Command(합참))
               . 40여명(DoD, 육-해-공군 각 10여명)의 IPv6 전략 수립 전담인력을 확보
            - 시스코, 주니퍼, MS 등 주요 산업체에서는 IPv6 상용화 및 미군의 IPv6 전환 지원을
               위하여 라우터, 보안제품, 가상전투게임 등 개발
            - 국방부를 포함한 연방 24개 부처에 IPv6 도입촉구(하원 정부개혁위원회의장, Tom Davis)
               . 국방부는 현재 IPv6 도입 계획 및 전환 모델 등이 수립되어 있으나 나머지 23개 부처는
                 IPv6 도입이 저조함
               . 타 부처도 국방부와 같은 구체적인 IPv6 도입 계획 및 비즈니스모델 수립이 필요함 강조
            - 기타 석유유통시스템, 긴급관리시스템(Emergency Management System) 등에
               IPv6 적용 필요성 발표
               . 경찰, 병원, 소방서 등 긴급을 요하는 agency를 위하여 IPv6 기반 긴급 관리시스템을
                 도입하는 Metronet6 프로젝트 계획 발표

        ※ 공군의 IPv6 추진 체계 예시
           - DoD의 정책 및 Guide에 따라 공군은 AF CIO, AFSN, AF Testing Facilities, AF R&D 등에
              세부 IPv6 추진 업무를 할당
           - 공군은 IPv6전환 관리 계획 v2.0, 공군 IPv6 전환 관리 가이드 등을 완성하고 전환 비용
              산정 완료, Pilot program과 R&D 시험 장소 그리고 장비 등을 확정하였음

    사용자 삽입 이미지

    < AF의 IPv6 추진 체계 >

    사용자 삽입 이미지

    < 공군 IPv6 전환관리 계획 >

        ※ 육군은 DoD의 기준아래 제조업체들이 육군의 IPv6 도입을 지원할 수 있도록 RFI(Request for Information)를 제작 중이며 DoD가 2008년부터 IPv6 도입하려 하지만 2013년 이후부터나 IPv4 기능을 Deactivating할 수 있을 것으로 예상함(John Shipp, Army's Director of technical architecture, applications, operations and space)

     

        o유럽은 기술 개발을 2005년 종료하고 이후는 IPv6 가이드북 제작, 홍보 등을 통한
           상용화(Procurement) 추진
            - EU는 123M유로를 투입하여 기술개발, 상호운용성 시험(이상 90M 유로)를 완료하였고
               2.5Gbps급 시험망 구축(33M 유로)을 2005년까지 종료 예정(Director of EC)
              . IPv6 상용화는 군사 및 연구분야부터 시작될 것으로 예상

     

    사용자 삽입 이미지

    < EU의 IPv6 로드맵 >

            -NATO는 회원국간 상호운용성을 확보하고 이동성 등 IPv6 장점을 군에 활용하기 위하여
               1996년부터 IPv6 관련 프로젝트(INSC, CFBLNet) 수행

                ※ INSC(Interoperable Network for Secure Communication)
                   - 보안통신을 위한 상호운용성 확인 프로젝트
                ※ CFBLNet : Combined Federated Battle Lab Network : 연합전을 위한 가상전투망

    사용자 삽입 이미지

    < NATO 참가국 >

            - 독일연방군(Bundeswehr)의 IT 시스템에 IPv6를 적용(2007년부터), 미국 등 동맹국과의
               연합작전 및 육해공군 협력작전 효율향상 추진(독일 Liaison Office의 Assistant Director)

     

    사용자 삽입 이미지

    < 독일 연방군의 IPv6 로드맵 >

    사용자 삽입 이미지

    < 독일군의 IT Framework >

     

        o일본 및 한국은 선도적으로 IPv6를 추진하고 있음
            - 일본 정부는 2010년 모든 기기를 네트워크로 연동하는 u-Japan 구축을 목표로 하고
               있으며 u-Japan의 기본주소인 IPv6 검증 추진
            - 2003년, 2004년에는 병원, 지자체, 가정 등 다양한 분야의 실증시험을 통하여
               IPv6로 전환시 문제점 등을 파악하였음
            -
    2005년에 병원, 빌딩자동관리 등 7개 실증시험을 통하여 IPv6를 통한 비용절감,
               성능향상, 강화된 확장성 등을 확인 예정

            - 파나소닉, 마츠시타, 요코가와, Freebit, 히다찌 등 일본 제조사들은 IPv6 상용 제품 출시

            

    사용자 삽입 이미지

                  

              

    사용자 삽입 이미지

                                                   < 2005년 IPv6 실증 시험 계획 >

     

    사용자 삽입 이미지

     

                                                  < 일본의 IPv6 제품 현황 >

     

            - NTT, Freebit 등에서 IPv6 기반 VoIP 서비스(9개월 동안 2만명 가입자 모집) 및
               멀티케스트 영상 서비스 제공

                           

    사용자 삽입 이미지

     

     

        o한국은 IT839 전략을 수립하여 체계적인 IT 발전을 꾀하고 있으며 이중 핵심 인프라인
           IPv6의 활성화를 위해 노력 중
           - 한국정부는 IPv6 보급촉진 기본계획을 수립하고 이에 따라 기술개발, 시범사업, 홍보 등을
              통하여 체계적으로 IPv6 추진중
           - 올해 시범사업은 공공기관 VoIPv6 시범사업 등 6개 추진 예정
           - 또한 한국 국방부의 IPv6 지원 사업 및 시범사업 추진 예정

              ※ 한국정부의 IPv6 추진 성과 및 계획은 정보통신부의 조관복 사무관이 발표하였으며
                  많은 참석자들이 관심을 가지고 경청하였음
                   - 발표 이후 IPv6 시험운영 결과 및 IPv6 시범사업 동영상 파일 등에 대한 요구 및
                      한국의 정부 주도 IT 전략(CDMA, 초고속 인터넷, IPv6 등)의 성공 요인에 대한
                      질문 등이 있었음
                   - 한국 유비쿼터스 드림 전시관 및 KIESv6 전시관 방문 방법 등에 관한 질문이 있었음

                  

    사용자 삽입 이미지


        o기타
           - Mobility for IPv6, IPv6 Multicast 등 IPv6 신기술 개발 현황 및 IETF의 주요 IPv6 표준화
              현황 등이 발표되었음
           - IPv6기반 Mobility는 host mobility, Network Mobility 그리고 Ad-hoc mobility로
              구분할 수 있으며 NATO INSC 프로젝트에서는 Network Mobility 및 Ad-hoc Mobility를
              검증하였음(2004~2005)

           

    사용자 삽입 이미지

                                                              < IPv6 Mobility의 종류 >

                   

    사용자 삽입 이미지

                                                       < INSC의 IPv6 Mobility의 종류 >

     

           -IETF에서 IPv6 기본 표준 제정은 거의 완료되었으나 기존 표준안의 문제점 개선에 관한
              표준화는 계속 진행중

           -
    Tutorial 세션을 통하여 미군 등 IPv6가 생소한 이들에게 IPv6 교육

     

     □ Coalition Summit for IPv6 주요 전시내용

       o 21개 기관에서 전시에 참가
          - 파나소닉, 루슨트, NTT, Spirent, sunset, 시스코, MS, IXIA, SDSU SITI, IPv6 Promotion
             Council, Gilder Technology Report, Charmed, Extreme, Houston, Global Crossing,
             Juniper, Agilent Technologies, Hexago, SAIC

       o 주요 전시물
          - 파나소닉 IPv6 네트워크 카메라
          - NTT 센서를 활용한 바람, 공기 점검 시스템
          - 루슨트 DHCPv6 소프트웨어 및 IPv6 네트워크 장비
          - 시스코 IPv6 관련 서적 등

                                     

    사용자 삽입 이미지

                                                       < NTT - 원격 센서 제어 >

     

                                            

    사용자 삽입 이미지

                                                    < 파나소닉 - 네트워크 카메라 >

     

     □ 행사 관련 회의

      o International ISP Meeting
        - 일   시 : 5월 24일(화), 2005, 1:30 - 2:30
        - 장   소 : Hyatt Regency, Reston, VA
        - 참석자 : Virginia ISP 협회 회원사 및 각 국의 ISP 담당자 30여명
        - 주요 내용
         . 세계 각국의 대형 ISP들이 모여 언제부터 정부를 포함한 고객에게 IPv6 서비스를
           제공할지에 대해 토의
         . Forrester Research에 따르면 160만조달러에 해당하는 시장에 대한 접근방법에 대해 토의

      o DISA의 IPv6 Transition 담당자와 한국 정부(정보통신부 및 산하기관) 담당자간 회의
        - 일  시 : 5월 26일(목), 2005, 4:45 - 6:45
        - 장  소 : Hyatt Regency, Reston, VA
        - 주요 내용
         . 한국과 미국의 IPv6 추진 현황에 대하여 정보 교류
         . 미군은 DoD 중심으로 육해공군 지도부에서 적극 IPv6를 추진하고 있으며 40여명이
           IPv6 추진 계획 수립에 투입되어 있음
         . 그러나 DoD 중심으로 추진된 IT 계획 중 실패한 사례가 많으며 미군의 IPv6 적용 성공
           여부는 군 하부조직의 IPv6 적용 여부에 달려 있음
           (OSI의 실패 및 VoIP의 성공 사례를 예시로 듬)
         . 기타 DISA에서 유비쿼터스드림체험관, KIESv6 방문을 요청하였음

      o Coalition Embassy Military Liaison Meeting
        - 일  시 : 5월 25일(수), 2005, 1:45 - 2:45
        - 장  소 : Hyatt Regency, Reston, VA
        - 참석자 : DoD 및 덴마크 장군 등 각 국의 대사관 군사 대변인, IPv6 전문가 20여명
        - 주요 내용
         . DoD의 IPv6 추진 필요성 및 추진 현황 발표
         . 각 국의 군이 IPv6 추진시 중복 예산 투입을 방지하고 상호 협력할 수 있는 방안 협의
         . IP 주소 시점에 대한 이슈로 각 국마다 이견이 있었음

                                      

    사용자 삽입 이미지

     

    □ 기타

      o GAO(Government Accountability Office)
         연방정부에 IPv6 보급을 촉구하는 보고서 배포(GAO-05-471, 2005.5)
         - IPv6 장점 조사 : 풍부한 주소개수, 쉬운 네트워크 관리, 보안 등
         - IPv6 보급을 위해 고려해야 할 보안 계획 등 제시
         - 국방부의 IPv6 추진 현황 제시 및 나머지 23개 연방 기관의 IPv6 추진이 저조함을 지적

            <23개 연방부처의 IPv6 도입 현황>
              o 22개 기관은 IPv6 Business 사례를 발굴하지 않음
              o 21개 기관은 IPv6 전환계획이 없음
              o 22개 기관은 IPv6 전환시 소요 비용이 없음

                           

    사용자 삽입 이미지

     

    4. 종합의견 및 시사점

      o 미국은 국방부가 전략망과 전술망 등에 IPv6 도입을 적극 추진함으로써 산업체에 IPv6 시장
         제공 및 활성화에 기여
         - 이번 행사는 미국의 각 군별 3성 장군이 직접 IPv6 추진 현황을 발표하는 등 미군의
            IPv6에 대한 관심을 실감할 수 있었음
         - 일반 참석자들도 군복을 입은 군인들이 다수를 차지하는 등 군의 깊은 관심을 확인하였음

                            

    사용자 삽입 이미지

      o 또한, 미국 GAO(의회 감사원)에서는 DoD를 제외한 23개 부처의 IPv6 적용 현황을 조사하고,
         미비한 부처의 IPv6 도입을 촉구함
         - 기타 하원 의원, 국무부, 미국 가전 협회 등 관공서 공무원들이 IPv6 필요성을 강조하는 등
            IPv6에 대한 미국인 정부의 관심을 확인할 수 있었음

      o 시스코, 주니퍼, MS 등에서는 선도적으로 IPv6 제품 개발을 수행함으로써 국방부 등 수요자가
         IPv6 도입을 결정할 수 있는 계기를 제공하였고, 지속적으로 미군의 IPv6 전환을 지원

      o IPv6 추진에 대한 전체적인 공감대 형성에도 불구하고 IPv6 도입 시기에 대해서 부정적인
        의견이 일부 있었음
        - DoD의 CIO인 Linton Well 2세는 이라크 및 아프카니스탄의 전시 상황이 IPv6 도입 시기를
           지연시킬 수도 있음을 경고
        - Spirent의 Bill Kine는 정부 주도 보다는 Killer app.에 의한 시장 주도가 확실한 IPv6 전환
           방법이며 아직은 해당 Killer app.이 없다고 주장

      o IPv6 전시행사는 제품보다는 브로셔 위주로 진행되어 현실감이 부족하였으며, 발표 및
         전시 등에 우리나라의 참여가 미국, 유럽, 일본 등에 비하여 저조하여 많은 아쉬움을 남겼음

      Comments,     Trackbacks
    IPv6 FTP 서버 운영

    IPv6 FTP 서버 운영

     

     

    IPv6 기반의 네트워크 환경에서 대용량 파일 전송을 위해, IPv6 FTP 서버를 운영할 수 있다. IPv6 FTP 서버를 운영하기 위해서는 IPv6 접속을 지원하는 FTP 서버를 설치하고 IPv6 접속을 지원하는 FTP 클라이언트를 활용하면 된다.

     

    IPv6 지원하는 OS 환경에 내장된 FTP 클라이언트는 대부분 IPv6를 지원하며(예: Windows XP, 2003 내장 FTP 클라이언트, RedHat Linux 9 내장 FTP 클라이언트 등), FTP 접속을 지원하는 FTP 서버에는 pureftpd, ProFTPD 등이 있다.

     

    ** IPv6 지원 FTP 서버에 대한 자세한 내용은www.deepspace6.net을 참고

     

    본 문서에서는 Windows를 지원하는 Gene6 FTP Server(G6 FTP Server)를 이용하여 Windows XP/2003 환경에서 IPv6 기반의 FTP 서버 설치 및 동작에 대해 알아본다.

     

     

    1. G6 FTP Server 다운로드

     

    http://www.g6ftpserver.com/en/download사이트에서 FTP 서버 프로그램을 다운로드 받는다.

     

    ** 위 링크가 동작하지 않으면여기에서 다운로드 받기 바랍니다.

     

    사용자 삽입 이미지

    [G6 FTP Server 홈페이지]

     

     

     

    2. G6 FTP Server의 설치

     

    다운로드 받은 설치파일을 실행하고, 설치마법사를 진행시키면, 아래 그림과 같은 관리자 계정 설정 창이 나타나는데 적절한 관리자 계정과 암호를 설정한다.

     

    사용자 삽입 이미지

    [관리자 계정 설정]

     

     

    3. G6 FTP Server Administrator 로그인

     

    FTP 서버의 설치가 완료되면 자동으로 아래 그림처럼 로그인 창이 나타나고, 관리자 암오를 입력하면 G6 FTP Server Administrator에 로그인하게 된다.

     

    사용자 삽입 이미지

    [관리자 암호 입력]

     

    로그인 정보를 보면, 현재 로컬 시스템에 FTP 서버가 운영되고 있다는 것을 알 수 있다.

     

    사용자 삽입 이미지

    [ 관리자 메뉴 ]

     

     

     

    4. FTP 서비스를 위한 서비스 도메인 설정

     

    현재 FTP 서버만 설치가 되었지, 실제 외부 서비스를 위한 서비스 도메인이 설정되지 않았다. 아래 그림처럼 Local Machine을 클릭하면Domains항목이 타나난다.

     

    사용자 삽입 이미지

    [ Domains 항목 선택 ]

     

    Domains 항목을 선택 >> 마우스 오른쪽 버튼을 클릭 >>New Domain  항목을 선택하면 아래 그림과 같이Domain Wizard가 실행된다.

     

    사용자 삽입 이미지

    [ Domain Wizard 실행 화면 ]

     

    우선 적절한 도메인 명(여기서는 IPv6)을 입력하고 'Next'를 클릭하면 아래 그림처럼 도메인이 FTP 서비스에 이용할 IP 주소를 입력하는 창이 나타난다.

     

    사용자 삽입 이미지

    [ 서비스에 이용할 IP 주소 입력 ]

     

    만약 여기서 특정 IPv4 주소나 *(와일드카드, wildcard)를 입력하면 IPv4로만 서비스가 되므로, 아래 그림처럼 반드시 자신의 시스템에 생성되어 있는 IPv6 주소를 입력한다.

     

    사용자 삽입 이미지

    [ 시스템에 생성된 IPv6 주소 입력 ]

     

    자신의 시스템에 생성되어 있는 적절한 IPv6 주소는 아래 그림처럼'시작 >> 실행 >> cmd'를 입력하여 명령 프롬프트를 실행하고ipconfig 명령을 실행하면 확인할 수 있다.

     

    아래 그림에서는 2001:2b8:80:11:209:6bff:fee3:f8be 이며 Native IPv6 환경이다.

     

    사용자 삽입 이미지

    [ ipconfig 명령을 이용하여 시스템의 IPv6 주소 확인 - Native IPv6 ]

     

    만약 6to4의 경우 아래 그림과 같은 IPv6 주소가 표시된다.

     

    사용자 삽입 이미지

    [ ipconfig 명령을 이용하여 시스템의 IPv6 주소 확인 - 6to4 Tunneling ]

     

    계속 설치를 진행한 뒤, 아래 그림처럼 Anonymous 사용자 계정을 설정하고 마법사를 종료한다.

     

    사용자 삽입 이미지

    [ anonymous 계정 설정 ]

     

     

     

    5. IPv6 FTP 서버의 동작 여부 확인

     

    설정 마법사가 종료되면 아래 그림과 같은Domain Setting정보화면이 나타난다.

     

    사용자 삽입 이미지

    [ Domain Settings 화면 ]

     

    여러 항목 가운데,Secure >> IP binding 항목을 클릭하면 아래과 같이 FTP 서비스에 이용하는 IP 주소의 정보가 나타난다.

     

    사용자 삽입 이미지

    [ Secure - IP binding 선택 화면 ]

     

    위 그림과 같이 IPv6 주소가 나타나면 된다.(가운데 줄이 그어져 있더라고 서비스에는 이상 없음)

     

    네트워크 차원에서 IPv6 FTP 서버가 정상동작하는 것을 확인하려면 아래 그림처럼 명령 프롬프트에서 netstat -an 명령을 실행하여 해당 IPv6 주소의 21 포트가 Listening 되고 있는지 확인한다.

     

    사용자 삽입 이미지

    [ netstat -an 명령 - 21번 포트 Listing 확인 ]

     

     

    6. 외부 접속 테스트

     

    FTP 서버의 동작을 보다 확실하게 확인하기 위해서는 IPv6 지원 FTP 클라이언트를 이용하여 IPv6 FTP 서버에 접속을 해본다.

     

    외부 IPv6 단말에서 아래 그림과 같이 IPv6 FTP 서버에 접속을 한다. 아래 예에서는 Windows XP 내장 FTP 클라이언트를 이용하였다.

     

    사용자 삽입 이미지

    [ 외부 단말에서 IPv6 FTP 서버 접속 ]

     

    이때, FTP 서버에서 netstat -an 명령을 실행하면 아래 그림처럼 21번 포트로 IPv6 FTP 접속이 되었음을 확인할 수 있다.

     

    사용자 삽입 이미지

    [ netstat -an 명령 실행 결과 - 21 포트로 연결되었음을 확인 ]

     

    또한, G6 FTP Server의 관리자 화면에서도 IPv6 FTP 접속 정보를 확인할 수 있다.

     

    사용자 삽입 이미지

    [ Activity 정보 화면 ]

     

    사용자 삽입 이미지

    [ Log 정보 ]

     

      Comments,     Trackbacks
    [IPv6 강좌] IPv6 프로토콜 구조와 IPv4와의 비교

    [IPv6 강좌] IPv6 프로토콜 구조와 IPv4와의 비교

    출처 : 온더넷, 2005년 4월호

    IPv6로 망을 구축하거나 기존의 망을 전환하기 위해서는 IPv6 주소체계와 구조를 알아야 한다. 예를 들면 기존에 202.15.6.1 형태로 표현된 32비트 IPv4 주소 프로토콜을 대체해 128비트의 새로운 주소 프로토콜이 사용되는 것이다. IPv6의 탄생 배경과 필요성에 대해서는 지난호에서 이미 상세히 설명했으므로 이번호에는 IPv6 프로토콜의 구조와 IPv4와의 차이점에 대해서 알아보자.

    염창열 | 한국전산원 차세대인터넷팀 선임연구원

    인터넷 데이터는 일정한 형태를 이뤄 전달된다. 이를 패킷이라고 부르는데 패킷의 구조는 (그림 1)과 같이 IP 헤더, TCP/UDP 헤더, 애플리케이션 헤더 그리고 이용자 데이터 영역으로 분류된다.

    사용자 삽입 이미지

    IPv6 헤더는 (그림 2)와 같이 버전, 트래픽으로 이뤄진다. 각 필드에 대해 간단히 설명하면, 버전(version, 4비트)은 패킷이 IPv4인지 IPv6인지 IP 프로토콜의 버전을 알려주는 필드다. 트래픽 클래스(Traffic Class, 8비트)는 QoS에서 사용되는 필드로 패킷의 우선 순위 등을 나타낸다. IPv4의 CoS 필드와 동일하다. 플로우 레이블(Flow Label, 20비트)은 IPv6에 신설된 필드로 플로우를 구분해 플로우별 패킷 처리를 가능하게 해주는 QoS 관련 필드다. 이에 대한 세부적인 활용 방안은 IETF에서 아직도 협의중이다. 페이로드 길이(Payload Length, 16비트)는 IPv6 헤더의 길이를 알려주고 넥스트 헤더(Next Header, 8비트)는 IP 헤더 다음에 어떤 확장 헤더가 올지 혹은 확장 헤더없이 UDP/TCP가 올지를 알려준다. 홉 리미트(Hop Limit, 8비트)는 IPv4의 TTL 값으로 루프(Loop) 방지를 위해 사용되며, 소스 어드레스(128비트)/도착지 어드레스(128비트)는 출발지/목적지 주소다.

    사용자 삽입 이미지

    (그림 3)과 같이 IPv6 헤더는 IPv4와 비교해 그 길이는 길어졌지만, 헤더 규격이 단순화 돼 처리 효율은 높아졌다. 왼쪽의 IPv4 헤더에서 현재 많이 사용하지 않는 'Flags' 'Fragment offset' 'Options and padding' 'checksum' 등의 필드는 붉은색 동그라미와 같이 삭제되거나 뒤에 설명할 확장 헤더로 넘겼고, 나머지 필드는 그 규격을 개선했다. 뿐만 아니라 플로우 레이블과 같이 추가 필드를 정의해 플로우별 데이터 처리를 가능케했다.

    사용자 삽입 이미지

    IPv6 헤더에서 정의하지 못했으나 인터넷 데이터 전송을 위해 필요하다고 생각되는 부가 기능에 대해서는 확장헤더를 통해 구현했다. 확장헤더는 IPv6 헤더와 TCP/UDP 헤더 사이에 (그림 4)처럼 위치한다.

    사용자 삽입 이미지

    (그림 5)는 확장 헤더의 종류와 그 기능을 설명하고 있으며, 이를 통해 IPv4보다 보안(IPsec), 이동성(Mobile IPv6) 등을 강화할 수 있었다.

    사용자 삽입 이미지

     

    IPv6 주소 형식
    IPv4 주소는 10진수 형태로 A.B.C.D와 같이 4개의 점으로 구분돼 표현되지만, IPv6 주소표현 형태는 16진수 형태로 X:X:X:X:X:X:X:X와 같으며, 여기서 X는 16비트 크기로 네 개의 16진수로 표현된다.

    예) 2002:2ABC:DEF0:1234:5678:90AB:CDEF:1234

    IPv6 주소는 128비트로, IPv4의 32비트와 비교해서 4배가 길기 때문에 IPv4처럼 10진수로 표현하면 길이가 너무 길어질 수 있다. 그러나 IPv6 현재 주소표시 형태로도 길이가 길기 때문에 다음과 같이 주소 축약 형식을 채택하고 있다. '0'의 숫자 열을 압축하는 형식으로써 '::'은 '0'의 16비트 그룹이 이어진 것을 의미한다.

    예) 2002 : 0 : 0 : 0 : 0 : 0 : 0 : 99 은 다음과 같이 표현됨
    → 2002 :: 99

    다음과 같이 IPv4와 IPv6 노드의 혼합 환경을 취급하는 형식도 정의했다.

    예) X: X: X: X: X: X: d. d. d. d

    여기서 'X'는 16비트, 4개의 16진수 값이고, 'd'는 8비트 10진수 값이다. d.d.d.d는 표준 IPv4 주소 표현이다.

    예 1) 2002 : 0 : 0 : 0 : 0 : 0 : 202.1.2.3 → 2002::202.1.2.3
    예 2) 0 : 0 : 0 : 0 : 0 : 1234 : 10.1.2.3 → :: 1234:10.1.2.3

    IP 주소는 네트워크 영역과 호스트 영역으로 나뉜다. IPv4에서는 주로 마스크(mask)를 사용하거나 '/(프리픽스 길이)'로 네트워크 영역과 호스트 영역을 구분했다. IPv6에서는 주소 길이가 길어 마스크 방식을 사용하기는 어려워 '/(프리픽스 길이)' 방식을 사용한다. 즉 주소 중 왼쪽부터 (프리픽스 길이)라고 표시된 길이의 비트만큼이 네트워크 영역이고 나머지 부분이 호스트 영역이 된다.
    예를 들어, 2002:123::5/16에서 네트워크 영역은 2002이고, 호스트 영역은 123::5이다. 또한 이 주소를 통해 2002 프리픽스를 같은 네트워크의 규모는 2112이다.
    IPv4에서는 네트워크 영역과 호스트 영역의 규모를 A, B, C 클래스로 구분한다. (그림 6)과 같이 상위 4비트에 따라 크게 A, B, C 클래스로 구분되며, 각각의 클래스에 따라 호스트를 수용할 수 있는 네트워크 규모가 결정된다. A클래스는 1개의 네트워크당 224개의 호스트 주소를 할당할 수 있으며, B클래스는 1개의 네트워크당 216개의 호스트 주소, C클래스는 1개의 네트워크당 28개의 호스트 주소를 할당할 수 있다.

    사용자 삽입 이미지

    그러나 IPv6 주소는 이런 클래스 구분이 없다. 다만, 국가 주소 관리 기구가 통신업체에게 /32 크기의 주소를 할당해 주고 통신업체는 이를 자사 고객에게 /41 혹은 /48 크기로 할당해준다.

     

    IPv6 주소의 종류
    IPv6의 주소 종류로는 (그림 7)과 같이 유니캐스트(unicast), 애니캐스트(anycast), 멀티캐스트(multicast)가 있다. IPv4와 비교해 브로드캐스트 주소가 없어졌으며(브로드캐스트 주소의 기능을 멀티캐스트에서 포함하고 있음), 애니캐스트 주소가 새로 생성됐다. 기존 IPv4가 유니캐스트, 멀티캐스트, 브로드캐스트로 구분되는 것과 마찬가지지만, 길어진 주소의 구조화된 사용을 위해서 이와 같이 바뀌게 됐다. 이들 3종의 주소에 대한 설명은 다음과 같다.

    ·유니캐스트 주소
    단일 인터페이스를 지정하며 유니캐스트 주소로 보내진 패킷은 그 어드레스에 해당하는 인터페이스에 전달된다.

    ·애니캐스트 주소
    여러 노드에 속한 인터페이스의 집합을 지정하며, 애니캐스트 주소로 보내진 패킷은 그 어드레스에 해당하는 인터페이스 중 하나의 인터페이스에 전달된다. 현재는 멀티캐스트 주소에 그 기능이 포함돼 있어서 거의 사용하지 않는다.

    ·멀티캐스트 주소
    여러 노드에 속한 인터페이스의 집합을 지정하며, 멀티캐스트 주소로 보내진 패킷은 그 어드레스에 해당하는 모든 인터페이스에 전달된다. IPv6에는 브로드캐스트 주소는 없고, 그 기능은 멀티캐스트 주소로 대체됐다. 현재 어드레스 공간의 15%는 초기 할당됐고, 나머지 85%는 미래를 위해 예약돼 있다.

    사용자 삽입 이미지

     

    유니캐스트 주소
    단일 인터페이스를 지정하며, 유니캐스트 주소로 보내진 패킷은 그 어드레스에 해당하는 인터페이스에 전달된다. IPv6에서 유니캐스트 주소를 할당하는 여러 가지 형태가 있다. (그림 8)은 유니캐스트 주소 구조의 예를 나타낸다.

    사용자 삽입 이미지

    예를 들어 2001:2b81:33bb::1234/32의 경우 상위 32비트 2001:2b81은 서브넷 프리픽스(subnet prefix)가 되며, 하위 96비트인 33bb::1234는 인터페이스 ID가 된다. 유니캐스트 주소의 예는 다음과 같다.
    LAN이나 IEEE 802 MAC 주소를 갖는 환경에서의 일반적인 유니캐스트 주소의 구조는 (그림 9)와 같다. (그림 9)에서 48비트 인터페이스 ID는 IEEE 802 MAC 주소로, IPv6 주소가 설정된다.

    사용자 삽입 이미지

    유니캐스트 주소에는 'Global' 'Linklocal' 'Loopback' 'unspecified' 'IPv4 mapped' 'IPv6 compatible' 등으로 구분된다. Global IPv6 주소는 글로벌하게 라우팅되는 일반적인 주소다. 글로벌 주소는 왼쪽 3개의 비트가 모두 0으로 시작된다. Linklocal 주소는 같은 링크 상에서만 사용되는 주소로 (그림 10)처럼 왼쪽이 FE80으로 시작된다.

    사용자 삽입 이미지

    Loopback 주소는 (그림 11)과 같이 ::1, unspecified 주소는 (그림 12)와 같이 ::0으로 표기되며, 네트워크 상에서 자기 자신의 주소, 정해지지 않는 모든 주소 등으로 사용된다. IPv4 mapped 및 IPv4 compatible 주소는 모두 IPv4 주소를 IPv6 주소로 표현하는 방법으로 전자는 애플리케이션에서, 후자는 네트워크상 터널 주소로 활용된다.

    사용자 삽입 이미지

    사용자 삽입 이미지

     

    애니캐스트 주소
    여러 노드들에 속한 인터페이스의 집합을 지정하며 애니캐스트(Anycast) 주소로 보내진 패킷은 그 어드레스에 해당하는 인터페이스 중 하나의 인터페이스에 전달된다. 전달되는 인터페이스는 라우팅 프로토콜의 거리 측정에 의해 같은 애니캐스트 주소를 갖는 인터페이스 중에서 가장 거리가 짧은 인터페이스에 전달된다. 애니캐스트 주소는 유니캐스트 주소 공간으로부터 할당됐고, 유니캐스트 주소 구조를 갖는다. 따라서 애니캐스트 주소는 그 형태만으로는 유니캐스트 주소와 구별할 수 없다. IPv6 애니캐스트 주소는 IPv6 패킷의 소스 주소로 사용될 수 없다. 애니캐스트 주소 구조는 (그림 13)과 같다.

    사용자 삽입 이미지

    사실 애니캐스트 주소 개념은 IPv4에도 존재한다. IPv4 상에서도 루트 DNS의 미러(Mirror) 서버에는 애니캐스트 주소가 할당돼 로드밸런싱 등의 용도로 사용됐다. 하지만 IPv4의 애니캐스트 주소는 IPv6와 달리 특정 영역 192.88.99.0/24이 사용된다.

     

    멀티캐스트 주소
    여러 노드에 속한 인터페이스의 집합을 지정하며 멀티캐스트 주소로 보내진 패킷은 그 주소에 해당하는 모든 인터페이스에 전달된다. 멀티캐스트 주소는 주소의 상위 8비트가 FF(11111111) 값을 가짐으로써 유니캐스트 주소와 구별된다. 멀티캐스트 주소 구조는 (그림 14)와 같다.

    사용자 삽입 이미지

    멀티캐스트 주소는 여러 종류가 있는데, (표 1)에 자주 사용되는 주소를 나열하면 다음과 같다.

    사용자 삽입 이미지

     

    ICMPv6
    IPv6로 전환하기 위해 ICMP의 기능 또한 변화가 필요하다. ICMPv6는 패킷을 처리하면서 발생하는 오류(Error)나 현상에 대한 정보 전달 등을 수행한다. IP 헤더 다음에 ICMPv6가 오는지는 넥스트 헤더(Next header) 필드값(58)을 통해 확인할 수 있다. (그림 15)는 ICMPv6의 구조를 보여주고 있다.

    사용자 삽입 이미지

    IPv6에서는 주소 자동설정, MTU 발견(discovery) 기능, 주소중복확인(DAD) 등이 필수로 정의돼 있기 때문에 ICMPv6에서도 이를 지원할 수 있도록 변화가 필요했다. 이런 요구로 변화된 ICMPv6와 기존의 ICMPv4간의 차이는 (표 2)에서 비교하고 있다.

    사용자 삽입 이미지

      Comments,     Trackbacks
    [IPv6 강좌] IPv4/IPv6 전환 위한 여러 가지 방법들

    [IPv6 강좌] IPv4/IPv6 전환 위한 여러 가지 방법들

    출처 : 온더넷, 2005년 5월호

    IPv6가 IPv4에 비해 아무리 장점이 많다해도 기존의 인터넷을 IPv6 주소로 한순간에 바꿀 수는 없다. 광범위하게 퍼져 있는 IPv4 기반의 인터넷을 한순간에 바꾸는 것은 거의 불가능한 일이다. 이 때문에 IPv6 망으로 전환할 때 현실적인 제약사항을 고려한 IPv4/IPv6 전환방법이 필요한 것이다. 이번호에는 이에 대해 알아본다.


    이재준 | 한국전산원 차세대 인터넷팀

    IPv4/IPv6 전환에는 다음과 같은 제약사항이 있다.

    ·IPv6는 IPv4와 자연스럽게 호환(변환)되지 않는다.
    ·현재 수천만 개의 호스트가 IPv4 방식으로만 동작하고 있다.
    ·IPv4를 한꺼번에 IPv6로 전환할 수는 없다.

    이런 제약사항을 고려할 때, 당분간은 IPv4와 IPv6가 공존할 것이라는 데는 모두가 공감하고 있다. 때문에 이 시기에 IPv4와 IPv6를 전환하는 기술은 네트워크 운영시 아주 중요한 요소가 될 것이다. 현재, IPv4/IPv6 전환기술은 다양하게 소개되고 있으며, 네트워크의 형태에 따라 그 방법은 달리 적용될 수 있다.

    IPv4와 IPv6 전환의 핵심은 네트워크 라우팅 관점에서의 전환 방법이지만, 운영체제 차원의 IPv6와 IPv4 적용, 애플리케이션에서의 IPv6 주소를 변환하는 프로그래밍 기술 등도 중요하다. 이번 기고에서는 주로 네트워크 라우팅 관점에서 IPv6/IPv4의 전환 방법에 대해 살펴보고, 운영체제 차원의 IPv6/IPv4 전환에 대해서는 간략하게 소개하겠다.

     

    IPv6/IPv4 전환 메커니즘

    향후 구축될 IPv6 망은 IPv4/IPv6 듀얼(dual) 망, 혹은 IPv6 전용(native) 망 형태로 구성될 것이다. 이때 내부의 IPv6 망과 외부의 다른 IPv6 망, 혹은 IPv6 망과 IPv4 망과의 통신을 위해서는 IPv4와 IPv6가 혼재한 시나리오가 가능하다. 이 같은 IPv4/IPv6의 공존 상황에서 두 네트워크 간의 통신이 자연스럽게 이뤄지도록 하는 기술이 바로 IPv6 전환 메커니즘들이다. IPv6/IPv4 전환 메커니즘은 다음과 같다. 

    ·기본 IPv6 전환 메커니즘
     - IPv4/IPv6 듀얼 스택
     - IPv6-in-IPv4 터널링

    ·IPv4/IPv6 변환(translation) 메커니즘
     - NAT-PT(Network Address Translation Protocol Translation)
     - SIIT(Stateless IP/ICMP Translation)
     - TRT(Transport Relay Translator)
     - SOCKS 게이트웨이
     - BIS(Bump-in-the-Stack)
     - BIA(Bump-in-the-API)

    ·향상된 터널링 메커니즘
     - 6to4
     - 터널 브로커(Tunnel Broker)
     - DSTM(Dual Stack Transition Mechanism)
     - ISATAP(Intra-Site Automatic Tunnel Addressing Protocol)

     

    IPv4/IPv6 듀얼 스택

    기본 IPv6 전환 메커니즘 중에서 가장 먼저 IPv4/IPv6 듀얼 스택에 대해 알아보자. IPv6 단말이 IPv4 단말과 호환성을 유지하는 가장 쉬운 방법은 IPv4/IPv6 듀얼 스택을 제공하는 것이다. IPv4/IPv6 듀얼 스택 단말은 IPv4와 IPv6 패킷을 모두 주고받을 수 있는 능력이 있다. IPv4 패킷을 사용해 IPv4 노드와 직접 호환이 되고, IPv6 패킷을 사용해 IPv6 노드와도 직접 호환된다. 이는 노드에서 서로 프로토콜에 적합한 패킷의 변화를 수행하는 방안으로, 110v/220v 전원을 동시에 지원하는 전자제품에 비유할 수 있다. (그림 1)은 듀얼 스택 개념도다.

    사용자 삽입 이미지

    IPv4/IPv6 듀얼 스택 노드는 양쪽 프로토콜을 모두 지원하기 때문에 IPv4 주소와 IPv6 주소로 모두 설정할 수 있다. IPv4/IPv6 듀얼 스택 노드는 IPv4 메커니즘(예: DHCP)을 사용해 해당 IPv4 주소를 얻고, IPv6 프로토콜 메커니즘(예: 상태 비보존형 주소 자동설정)을 사용해 IPv6 주소를 얻을 수 있다.
    듀얼 스택 노드의 DNS는 호스트 이름과 IP 주소간 매핑을 위해 IPv4와 IPv6에 모두 사용된다. 이때 AAAA라는 DNS 리소스 레코드 유형은 IPv6 주소용으로 사용된다. IPv4/IPv6 듀얼 스택 노드는 IPv4나 IPv6 노드와 직접 호환될 수 있어야 하므로 IPv4 A 레코드는 물론이고, IPv6 AAAA 레코드도 처리할 수 있는 주소해석기 라이브러리(DNS Resolver Library)를 제공해야 한다.
    IPv4/IPv6 듀얼 스택 노드의 DNS 주소해석기 라이브러리는 AAAA와 A레코드를 모두 처리할 수 있어야 한다. 주소해석기 라이브러리는 IPv6 주소를 가진 AAAA 레코드와 IPv4 주소를 가진 A 레코드를 모두 조회해, 해당 노드와의 통신에 사용된 IP 패킷 버전에 영향을 미치는 결과를 필터링하거나 순서를 정할 수 있다.

     

    IPv6-in-IPv4 터널링

    IPv6/IPv4 단말과 라우터는 IPv6 데이터그램을 IPv4 패킷에 캡슐화해 IPv4 망을 통해 터널링할 수 있다. 즉, 터널링은 기존의 IPv4 인프라를 활용해 IPv6 트래픽을 전송하는 방법을 제공하며 (그림 2)와 같이 동작한다.

    사용자 삽입 이미지

    IPv6-in-IPv4 터널링 방법은 크게 설정 터널링(configured tunneling) 방식과 자동 터널링(automatic tunneling) 방식으로 구분된다. 설정 터널링은 6Bone에서 주로 사용하는 방법으로, 두 라우터 간(혹은 호스트간) IPv4 주소를 통해 정적으로(수동으로) 터널을 설정하는 방식이다. 자동 터널링은 IPv4 호환 주소를 이용해 수동 설정 없이, IPv4 구간을 통과할 때면 IPv4 호환 주소에 내포돼 있는 IPv4 주소를 통해 자동으로 터널링을 설정하는 방식이다. (그림 3)은 설정 터널링 방식과 자동 터널링 방식을 나타내는 그림이다.

    사용자 삽입 이미지

     

    IPv4/IPv6 변환 메커니즘 : 헤더 변환

    앞서 IPv4/IPv6 변환 메커니즘에는 NAT-PT, SIIT, TRT, SOCKS 게이트웨이, BIS, BIA 등이 있다고 말했다. 이중에서 NAT-PT, SIIT는 헤더 변환방식에 속한다. 헤더 변환은 IPv6 패킷 헤더를 IPv4 패킷 헤더로 변환하거나 또는 그 역순으로 변환하는 것이다. 이때 만일 필요하다면 패킷 무결성을 유지하기 위해 체크섬(checksum)을 조정(또는 재계산)하는 과정이 필요하다.

    헤더 변환은 IP 계층에서의 변환으로, IPv4 패킷을 IPv6 패킷, 또는 그 반대로 변환하는 것으로, 규칙은 SIIT에서 정의하고 있다. SIIT는 IP 네트워크에서 IPv6 패킷과 IPv4 패킷을 상호 변환하는 기술이다. 헤더 변환방식은 주로 NAT-PT라는 방식으로 구현되는데, NAT-PT는 SIIT에 기반을 둔 헤더 변환방식의 전형적인 예이다. 이는 (그림 4)와 같이 동작한다.

    사용자 삽입 이미지

    헤더 변환은 다른 방식에 비해 속도가 빠른 장점이 있는 반면, NAT(Network Address Translation)와 마찬가지로 IP 계층을 변환함에 따른 제약을 갖고 있다. 대표적인 제약점으로는 DNS, ALG, FTP와 같이 애플리케이션 프로토콜에 내장된 IP 계층 주소변환이 어렵다는 점을 들 수 있다. 이를 해결하기 위해서는 DNS, FTP, ALG와 같은 별도의 애플리케이션 게이트웨이를 추가로 구현해야 한다. 더욱이 IPv4-IPv6 헤더 변환시 IPv4 패킷은 여러 개의 IPv6 패킷으로 쪼개져 전송되는데, 이는 IPv6의 헤더 길이가 IPv4의 헤더보다 일반적으로 20바이트 더 크기 때문이다. 또한 IPv4에서의 ICMP 내용을 ICMPv6로 상호교환할 수 없다는 한계도 있다. 애플리케이션 계층에서 발생하는 문제를 근본적으로 해결하기 위해서는 해당 프로토콜을 위한 애플리케이션 프로그램을 개발해야 한다.

     

    IPv4/IPv6 변환 메커니즘 : 전송 릴레이와 ALG

    IPv4/IPv6 변환 메커니즘 중 전송 릴레이 방식에 속하는 것에는 TRT, SOCKS 게이트웨이, BIS, BIA 등이 있다. 전송 릴레이는 TCP, UDP/IPv4 세션과 TCP, UDP/IPv6 세션을 중간에서 릴레이 하는 것을 말한다. 이 방법은 전송 계층에서 변환하는 방식으로, 전형적인 TCP 릴레이 서버는 다음과 같이 작동한다.

    TCP 요청이 릴레이 서버에 도착하면, 네트워크 계층은 목적지가 서버의 주소가 아닐지라도 TCP 요청을 TCP 계층으로 전달한다. 서버는 이 TCP 패킷을 받아, 발신 호스트와 TCP 연결을 한다. 그 다음 서버는 실제 목적지로 TCP 연결을 하나 더 만든다. 두 연결이 구축되면 서버는 두 연결 중 하나에서 데이터를 읽어 와 나머지 하나의 연결에 기록한다.

    전송 릴레이에는 각 세션이 IPv4와 IPv6에 각각 밀폐돼 있기 때문에 프래그먼트나 ICMP 변환과 같은 문제는 없지만, 애플리케이션 프로토콜에 내장된 IP 주소의 변환과 같은 문제는 여전히 남아있다. 전송 릴레이 방식으로는 TRT와 SOCKS 게이트웨이 방식이 있으며, 애플리케이션 계층으로는 BIS, BIA가 있다. 그러나 이들은 실제 망 구축시 활용 빈도가 적기 때문에 자세한 설명은 생략하겠다.

    ALG(Application Level Gateway)는 IPv4나 IPv6 두 프로토콜을 모두 지원하는 경우에 두 프로토콜 간의 변환 메커니즘에 사용할 수 있다. 트랜잭션 서비스를 위한 ALG는 사이트 정보를 숨기고 캐시 메커니즘으로 서비스의 성능을 향상시키는 데 사용된다. 이 방법은 애플리케이션 계층에서 변환하는 방식으로, 각 서비스는 IPv4/IPv6별로 각각 독립적이기 때문에 헤더 변환에서 나타나는 단점은 없다. 하지만 각 서비스를 위한 ALG는 IPv4와 IPv6 모두에서 실행될 수 있어야 한다. 대표적인 ALG 방식의 예는 IPv4/IPv6 웹 프록시인 SQUID 등을 들 수 있다. 이 방식은 ALG의 성능에 따라서 서비스의 품질이 결정된다.

     

    향상된 터널링 메커니즘

    향상된 터널링 메커니즘에는 6to4, 6 터널 브로커, DSTM, ISATAP 등이 있다. 6to4는 하나 이상의 유일한 IPv4 주소를 갖고 있는 IPv6 전용 사이트에, 2002:IPv4주소::/48 단일 IPv6 프리픽스를 할당해, 외부 IPv6 네트워크와 자동 터널링을 가능하도록 하는 메커니즘을 가리킨다. 6to4의 목적은 순수 IPv6를 지원하지 않는 광역 네트워크에 연결돼 있는 고립된 IPv6 사이트나 호스트가 자동 터널링 방식을 통해 다른 IPv6 도메인이나 호스트와 통신하도록 하는 것이다. 이 방식을 사용해 연결된 IPv6 사이트나 호스트는 IPv4 호환 주소 또는 설정 터널링을 필요로 하지 않는다.

    아직까지 대부분의 6Bone 네트워크는 수동으로 설정된 터널을 사용해 구축된다. 이 방법의 단점은 네트워크 관리자의 관리부담이 많다는 점이다. 관리자는 각 터널마다 광범위한 수동설정을 수행해야 한다. 이 같은 관리 오버헤드를 줄이려는 방법 중 하나가 바로 터널 브로커 메커니즘이다. 터널 브로커 개념은 터널 브로커라는 전용 서버를 구축, 사용자의 터널 요청을 자동으로 관리하는 방법이다. 이 방법은 IPv6로 연결된 호스트의 증가를 활성화시키고, 초기 IPv6 네트워크 제공자들이 보다 쉽게 그들의 IPv6 네트워크에 접근할 수 있도록 한다.

    DSTM은 IPv6가 널리 확산됐을 때 사용할 수 있는 방식이다. IPv6 단말은 IPv6망 뿐만 아니라 IPv4 단말과도 통신할 필요가 있다. DSTM은 ▲임시(temporary)의 IPv4 주소를 IPv6 노드에 제공하는 방법과 ▲IPv6 네트워크 내에서 동적 터널을 사용한 IPv4 트래픽 전송 ▲전환 메커니즘에 필수적인 지원 인프라에 대해 정의된 일련의 프로세스와 아키텍처를 제공한다. DSTM은 필요한 경우 IPv4 주소를 듀얼 IP 계층 호스트에 지정한다. 그러면 IPv6 호스트가 IPv4 전용 호스트와 통신할 수 있게 되거나, IPv4 전용 애플리케이션 프로그램이 IPv6 호스트에서 수정되지 않고 실행될 수 있다.

    이 할당 메커니즘은 IPv6 패킷 내부에서 IPv4 패킷의 동적 터널링을 수행하고, IPv6 네트워크의 DSTM 도메인 내에서 순수 IPv4 패킷의 노출을 억제하는 능력과 연관돼 있다. 그리고 IPv6 라우팅 테이블만 있으면 라우터가 IPv6 네트워크를 통해 IPv4 패킷을 이동할 수 있으므로 IPv6 네트워크 관리가 간단하다. (그림 5)는 DSTM 개념을 설명하는 그림이다.

    사용자 삽입 이미지

    ISATAP(Intra-Site Automatic Tunnel Addressing Protocol)는 보다 간단하게 IPv4 기반의 인트라넷에서 IPv6 노드를 점증적으로 배치할 수 있도록 하는 방식으로, 확장성이 보장된다. 6to4와 큰 차이점은 6to4가 /48 주소를 할당해 할당받은 노드가 서브 네트워크를 구성할 수 있도록 했으나, ISATAP은 /64 단위로 하나의 단말에 IPv6 주소를 할당해 통신하도록 설계된 방법이라는 것이다.

    ISATAP는 64비트 EUI-64 인터페이스 식별자와 표준 64비트 IPv6 주소 프리픽스(Prefix)를 이용한 글로벌 유니캐스트 주소 포맷을 기반으로 한다. 이 접근법은 IPv6 게이트웨이와 공통 데이터링크를 공유하지 않는 듀얼 스택 노드가, 사이트 내에서 IPv4 라우팅 인프라를 통해 IPv6 메시지를 자동 터널링 함으로써, 글로벌 IPv6 네트워크에 결합할 수 있도록 한다. ISATAP 주소 자동설정을 위해 두 가지 오프링크 IPv6 게이트웨이의 자동 탐색방법이 제공된다. 이 접근법에서는 경계 게이트웨이에서 하나의 동일한 프리픽스 주소를 사용하므로 전체 사이트 통합시 확장에 대한 걱정없이 사이트 내에 대규모 배치가 가능하다.

     

    운영체제 차원의 IPv6/IPv4 전환

    IPv6가 사용자단까지 파고 들기 위해서는 IPv6를 지원하는 장비들이 많아야 한다. 특히 운영체제 기반에서 IPv6를 지원하면 그 운영체제 위에서 실행되는 많은 애플리케이션 또한 IPv6를 지원하기 쉽다. 이번 강좌에서는 PC에서의 IPv6 지원 현황과 PDA 등의 단말기에서의 IPv6 지원 현황에 대해 알아본다.

    현재 PC에서 가장 많이 사용되는 마이크로소프트의 윈도우 운영체제는 각 버전별로 IPv6 지원 여부가 다르다. 최신의 운영체제일수록 IPv6를 잘 지원하고 있지만, 요즘은 잘 사용하지 않는 윈도우 98의 경우는 IPv6를 지원하지 않는다. 이 경우에 IPv6를 이용하는 애플리케이션을 완벽하게 사용할 수 없으므로, 운영체제의 업그레이드를 반드시 고려해야 한다. (표 1)은 현재 사용 가능한 윈도우 버전별 IPv6 지원 현황이다.

    사용자 삽입 이미지

    마이크로소프트는 2006년 출시 예정인 차기 운영체제(코드네임 : Longhorn)에 기본적으로 IPv6를 탑재할 것이라고 밝혔으로, IPv4 기능을 제거하고 IPv6만 사용할 수 있도록 설정하는 기능도 포함될 예정이다.

    그럼, 윈도우 이외의 운영체제는 어떨까. 현재 많은 운영체제 개발회사들이 IPv6를 지원할 수 있도록 노력하고 있으며, 실제로 최신 버전의 운영체제라면 대부분 IPv6를 지원하고 있다. (표 2)는 윈도우 이외의 운영체제들이 IPv6를 지원하고 있는 현황을 나타낸 것이다.

    사용자 삽입 이미지

    휴대용 단말기가 발전함에 따라 그 기능 또한 점점 다양화되고 있다. 앞으로 모든 단말기가 IP를 내장하게 될 것으로 예상되며, 더 많은 기능을 수행하려면 PDA와 같은 휴대용 단말기도 IPv6를 지원해야 한다. 휴대용 단말기에 사용되는 운영체제들은 아직은 대부분 IPv6를 지원하고 있지 않다. 설령 운영체제 수준에서 지원한다 하더라도 그것을 필요로 하는 애플리케이션이 거의 없으므로, IPv6를 지원하는 모듈을 제거하는 경우가 많다. (표 3)은 PDA에서 사용되는 각종 운영체제에서 IPv6를 지원하는 현황을 나타낸 것이다.

    사용자 삽입 이미지

    지금까지 IPv4에서 IPv6로의 전환시 필요한 여러 요소들과 고려 사항을 살펴봤다. 물론 이번 강좌에서는 언급하지 않았지만 애플리케이션에서의 고려사항들도 존재한다. 하지만 IPv6 전환의 첫 번째 단계는 네트워크 차원에서의 전환이기 때문에 그에 따르는 사항을 정확하게 알아두는 것이 좋다.

      Comments,     Trackbacks
    Windows XP SP1, SP2, Windows 2003에서 IPv6관련 ipconfig 명령 이용법
    Windows XP SP1, SP2, Windows 2003에서 IPv6관련 ipconfig 명령 이용법

     

    Windows XP와 Windows 2003에서 공식적으로 IPv6를 지원하면서 ping, ipconfig, netstat 등 네트워크 관련 명령어에 IPv6 관련 기능이 추가되었습니다.
    ** Windows XP 오리지널 버전에서는 ipconfig 명령으로 IPv6 정보의 확인이 불가능합니다.
    ** Windows XP SP1 이후 버전부터 가능합니다.

    본 문서에서는 IP 주소 설정을 확인하는 도구인 ipconfig 명령의 IPv6 관련 기능을 알아보겠습니다.

     

    1. ipconfig 명령의 실행 방법

    시작 >> 실행 >> cmd입력하면명령 프롬프트가 나타납니다.[그림1,2]

    명령 프롬프트에서 ipconfig 명령을 입력합니다.[그림3]

    사용자 삽입 이미지

    [그림1]

    사용자 삽입 이미지

    [그림2]

    사용자 삽입 이미지

    [그림3]

     

    2. 시스템의 IPv6 주소 및 default gateway 확인

    IPv6 스택이 설치된 상태에서 ipconfig 명령을 입력하면, 아래 그림처럼 시스템에 생성된 IPv6 주소가 표시됩니다. 아래의 예는, 초고속 인터넷 환경이기 때문에 Native IPv6 주소 없이 ISATAP 터널링 IPv6 주소가 생성되어 있습니다.[그림4]

    사용자 삽입 이미지

    [그림4]

     

    3. 모든 네트워크 인터페이스에 대한 상세 정보 확인

    각 네트워크 인터페이스에 대한 상세 정보를 확인하려면ipconfig -all명령을 이용합니다.
    ipconfig -all 명령을 이용하면 IPv6 DNS 정보를 추가로 확인할 수 있습니다.[그림5]

    ipconfig -all 명령 실행결과

    사용자 삽입 이미지

    [그림5]

     

    4. IPv6 DNS Cache 관련 정보 확인

    Windows에서는 DNS 쿼리의 효율성을 위해 DNS Cache가 존재합니다.ipconfig -displaydns명령을 이용하여 시스템에 캐시된 IPv6 DNS 정보를 확인할 수 있습니다.[그림6]

    ipconfig -displaydns 명령 실행결과

    사용자 삽입 이미지

    [그림6]

    위 그림에서 보면www.vsix.net에 대한 IPv6 DNS 정보중 AAAA Record는 2001:2b8:1::100이고 TTL이 76014임을 알 수 있습니다. 또한 album.vsix.net에 대한 IPv6 레코드가 2001:2b8:1::110 임을 알 수 있습니다.

     

    5. IPv6 DNS 캐시 정보의 삭제

    경우에 따라 테스트 또는 개발 과정에서 기존의 IPv6 DNS 캐시를 삭제해야 할 경우가 발생합니다. 혹은 DNS 서버로 부터 새로운 DNS 정보를 받아오기 위해서는 DNS 캐시를 삭제할 수 있습니다.

    ipconfig -flushdns명령을 이용하여 IPv6 DNS 캐시를 삭제할 수 있습니다.

    ipconfig -flushdns 명령 및 ipconfig -displaydns 명령 수행 결과

    사용자 삽입 이미지

    [그림7]

    위 그림에서 보면 ipconfig -flushdns 명령을 통해 IPv6 DNS 캐시가 삭제되었음을 알 수 있습니다.

     

    이상으로 ipconfig, ipconfig -all, ipconfig -displaydns, ipconfig -flushdns 명령의 이용 방법을 알아 보았습니다. 위 명령을 통해 시스템의 IPv6 주소 확인, DNS 정보 확인 및 삭제가 가능합니다.

      Comments,     Trackbacks
    [IPv6 강좌] 프롤로그 : 차세대 인터넷

    [IPv6 강좌] 프롤로그 : 차세대 인터넷 ①

    출처 : 온더넷, 2005년 3월호

    IPv4 주소의 한계성을 극복하고, 홈네트워크 서비스의 발전 기반을 마련할 IPv6로의 전환은 중요한 당면 과제 중 하나로 등장했다. 총 10회에 걸친 강좌를 통해 IPv6 네트워크 구축을 위한 여러 사항을 살펴본다. 이번호는 그 첫회로 IPv6의 특징과 IPv6로의 전환을 해야 하는 이유 등에 대해 소개한다.



    김진규 | 한국전산원 차세대인터넷팀 김진규

    유비쿼터스, 홈네트워크, RFID/USN과 같은 용어가 최근 들어 언론에 자주 오르내리고 있다. 이들은 상호보완적인 용어인데, 모든 사물이 인지되며 통신이 가능한 상태의 기술 수준을 이야기 하는 것이다. 그러면 이런 기술이 궁극적으로 구현되기 위해 가장 먼저 필요한 것은 무엇일까.

    여러 가지 답이 있겠지만, 가장 적절한 답은 통신 대상을 하나하나 구별할 수 있는 '구분자'이다. 그러면 이런 구분자가 세계적으로 통일되도록 하려면 어떻게 해야 하나. 답은 '주소체계'가 만들어져야 한다는 것이다.

    현재 전세계적으로 가장 효율적인 주소체계는 무엇일까. 그것은 바로 IP(Internet Protocol)이다. 우리가 IP라고 얘기하는 현 인터넷 주소의 정확한 명칭은 IPv4이다. 그러면 현재의 IPv4를 그대로 사용하면 우리가 가려고 하는 다음 세상이 올 수 있을까. 결론은 '궁극적으로 보아서 불가능 하다'이다. 이번호에서는 '왜 불가능한지'에 대해 알아보자. 그 이유가 바로 '왜 IPv6로 가야하는지'에 대한 답이 될 것이다.

     

    IP 주소 부족문제 해결할 IPv6

    인터넷은 전세계 수억 대의 컴퓨터와 그 이상의 개인·기업 사용자로 연결된 세계 최대의 통신 네트워크로, 단순히 컴퓨터와 컴퓨터를 연결하는 초기의 통신 네트워크의 차원을 벗어나 현재는 모든 개인을 하나로 묶는 광범위한 정보 인프라의 역할을 하고 있다.

    이렇게 인터넷이 점점 고도화 되면서 우리가 직접사람을 만나서 수동으로 처리했던 모든일들이 인터넷을 통해서 처리될 수 있는 환경으로 진행하고 있다. 다양한 애플리케이션의 급격한 발전에 따라서 전 지구상의 모든 사물에 대해서도 통신을 가능케 할 수 있는 유비쿼터스 네트워크의 개념도 생성됐다.

    그러나 현재 사용하고 있는 32비트 IPv4 주소는 약 43억(232) 개의 주소 개수를 가지고 있다. 여기에 더해 초기의 비효율적인 할당으로 인해 유효한 주소 개수마저 급격하게 줄어들고 있다. 이렇게 IP 환경은 한정적인 주소를 갖고 있음에도 불구하고, 인터넷 호스트, 이동전화(IMT-2000, CDMA, PCS 단말 등), 스마트 정보가전(인터넷 TV, 스마트 오븐, 냉장고 등), 가정에서의 인터넷 접속 단말(ADSL, 케이블 네트워크 등) 수는 계속 증가하고 있어서 주소 부족 문제가 심각하게 대두되고 있다.

    물론 주소 부족 문제를 해결하기 위한 임시적인 해결책으로 기존 IPv4 주소 공간을 효율적으로 재구성하는 CIDR(Classless Inter-Domain Routing), NAT(Network Address Translator), DHCP(Dynamic Host Configuration Protocol) 등을 이용한 방식도 사용되고 있다. 하지만 이런 방법은 점점 증가하는 주소 개수의 요구를 근본적으로 해결해 주지는 못하기 때문에 인터넷 주소 제공과 관리를 위한 장기적이고 궁극적인 해결방안이 필요하다.

    신 주소체계인 IPv6 주소는 128비트로, 약 3.4 1038(2128)개의 주소를 생성할 수 있다. IPv6는 IP 주소의 부족 문제를 해결할 수 있을 뿐만 아니라 품질제어, 보안, 자동네트워킹 등 다양한 서비스 제공이 용이한 차세대 주소체계다. 따라서 아직도 지속적으로 증가하고 있는 인터넷 사용자와 유비쿼터스 네트워크의 개념에 따라서 발생하는 제품 하나하나에 대한 구분을 위해 필요한 주소의 고갈 문제를 해결하기 위해 차세대 인터넷 주소 방식인 IPv6로 전환하는 것이 반드시 필요하다.

    당장의 문제해결을 위해 변환 방식을 쓸 수 있지만 궁극적으로는 항상 병목현상이 발생할 가능성과 서로 다른 체계의 주소방식이 가져올 수 있는 비효율성을 고려한다면 IPv6로의 전이는 가장 합리적인 선택이다.

    지금 인터넷은 새로운 시대의 요구사항을 충족시키길 원하고 있다. 통신·방송 융합, 유·무선 통합, BcN(Broadband convergence Network), 홈네트워크, 사물의 정보화와 같이 모든 사물이 상호 통신할 수 있는 유비쿼터스 네트워킹 환경을 지원해야 하기 때문에 다른 대안이 없다고 할 수 있다.

    물론 당장의 이익이 중요한 사업자들은 IPv4를 이용해 새로운 서비스를 가능케하는 장비와 서비스들을 생산하려 할 것이다. 그러나 이런 것은 앞서 이야기 했던 것과 같이 국가적 차원에서, 아니 전세계적인 차원에서 너무나 큰 낭비다. 그래서 정부차원에서 IPv6로의 전이의 틀을 만들고 있으며, 통신업체들을 유도해 나가고 있다. 이는 단기적인 이익보다는 궁극적이고 국가적인 차원의 이익을 위한 선택이 되는 것이다.

     

    IP의 역사

    IPv6는 IPv4의 뒤를 잇는 차세대 인터넷 프로토콜로, 기존 프로토콜과의 융통성과 호환성을 충분히 고려해 개발됐다. 차세대 인터넷 프로토콜은 1992년 IETF에서 IPng 활동으로 시작돼 1994년 7월 'IPng 권고안'이 만들어 지게 된다.

    IPv6는 IPv4로부터 그 내용을 승계받으면서 발전된 것으로 기존의 IPv4의 기능 중 이용할 수 있는 것은 계속 이용하고 현재와 미래상황을 고려할 때 비효율적인 것은 제거하는 방향으로 설계됐다. (그림 1)은 차세대 인터넷 프로토콜의 변천 과정이다.

    사용자 삽입 이미지

    (그림 1)에 나타난 것과 같이 IP는 버전 0에서 버전 3까지는 외부로 공식적으로 할당되지 않았으며, 우리가 현재 이용하는 인터넷 주소체계는 버전 4다. 이후 IPv5부터 IPv9까지 다양한 버전이 제시됐으나 현재 IPv6가 IPv4의 대안으로 1994년에 채택돼 이때부터 IPv6의 표준화가 본격적으로 진행됐다.

     

    IPv6의 대략적인 특징

    IPv6는 'Internet Protocol version 6'의 약자로, '차세대인터넷 주소체계 통신 프로토콜'로 명명되고 있으며, IETF를 통해 표준화가 진행되고 있다. 현재 기본적 스펙에 대한 표준은 대부분 완료됐으며, 일부 IPv6 고기능 프로토콜은 표준화 완성 단계에 있다(이동성 지원 및 다자간 통신 지원 기술 등).

    IPv6의 특징으로는 IP 주소의 크기가 32비트에서 128비트로 증가됨으로써 주소 공간이 확장됐을 뿐만 아니라 주소 범주의 정의, 생존시간 설정, 주소 자동 설정과 애니캐스트 지원 등 활용 범위도 대폭 증대됐다. 또한 헤더의 크기가 커졌음에도 불구하고 간략화와 고정화된 기본헤더 형식을 사용해 처리 속도 역시 개선됐다. 그 외에도 IPv6는 인증, 데이터 무결성, 데이터 기밀 유지를 지원하기 위한 확장 헤더를 정의하고 있어 보안을 위한 서비스 제공이 쉽다.

    사용자 삽입 이미지

    (표 1)은 IPv4와 IPv6 특성을 비교한 것이다. IPv4의 경우 대략 43억 개의 주소 할당능력을 갖는 반면, IPv6는 약 43억×43억×43억×43억 개의 거의 무한대인 주소를 할당할 수 있기 때문에 현재 부족한 IP 주소 할당 문제를 해결할 수 있을 것이다.

    보안 기능으로 IPv4의 경우 IPSec 프로토콜을 별도로 설치해야 하나 IPv6인 경우 추가 프로토콜을 설치할 필요 없이 내재된 보안 기능을 사용할 수 있다. IPv4의 경우 QoS의 처리는 QoS의 일부 지원으로 품질보장이 곤란했으며, IPv6에서는 QoS 지원을 위한 헤더내의 기능 추가로 인해 고품질의 서비스를 제공할 수 있게 됐다. 또한 IPv6에서는 기본헤더 크기의 감소로 인해, 패킷의 보다 빠른 처리가 가능해진다. IPv6의 주요 특징은 다음과 같다.

    ·확대된 주소 공간
    우선 IPv6는 128비트 체계를 채택하기 때문에 이론적으로 주소개수는 2128개다. 이 수치는 매 초마다 10억 대의 컴퓨터가 새롭게 인터넷에 연결돼도 거의 무한대에 가깝도록 사용할 수 있는 용량으로, IPv4에서 문제가 됐던 주소 고갈 문제를 근본적으로 해결했다. 또한 주소 구조 계층의 레벨(Level) 수가 증가하였기 때문에 새로운 주소를 정의할 수도 있고, 멀티캐스트 주소뿐 아니라 애니캐스트 주소도 가능하게 됐다(물론 현재는 애니캐스트 주소를 사용하지 않는 추세다).

    ·보안성 확보
    IPv4에서는 패킷 스위치 네트워크에서 단순한 데이터의 이동만을 고려해 제작한 것이기 때문에, 보안은 아예 무시하고 설계됐다고 해도 과언은 아니다. 이 때문에 IPv4는 보안 기능을 첨가하는 IPSec이라는 패치 형태의 프로토콜을 별도로 설치해야 하지만, IPv6는 이런 문제를 근본적으로 해결하기 위해 IPSec을 프로토콜 내에 탑재해 보안기능을 수행하도록 설계됐다.

    ·단순화된 헤더형식
    IPv4에서의 복잡한 헤더 형식을 IPv6에서는 단순화했다. IPv6에서 중요하지 않은 필드와 옵션 필드를 IPv6 헤더 다음에 있는 확장 헤더로 옮김으로서 오버헤드를 최소화, 단순화했다. 또한 주소 필드로 인한 전체 기본 헤더의 길이는 IPv6보다 2배 확장된 40바이트이지만, 전체 필드 수를 8개로 단순화시킴으로써 오히려 처리 속도를 개선하는 효과를 얻을 수 있다. 이런 이유로 IPv4 헤더와 IPv6 헤더는 상호운용이 안되기 때문에 연결 호스트나 라우터가 IPv4와 IPv6 모두를 구현 가능해야 한다.

    ·QoS를 보장하기 위한 개선
    IPv6는 송신자가 QoS 또는 실시간 서비스와 같은 특별 처리를 요청하는 특정 트래픽 흐름에 속하는 패킷을 식별하기 위해 레이블링(Labeling)을 통해 QoS를 지원해준다. 이는 처음부터 품질을 고려하지 않은 IPv4의 단점을 적극적으로 개선한 것이다.

     

    IPv6의 도입 이유

    지금까지 IPv6의 특징을 살펴봤다. 그럼 이제부터는 IPv6를 도입해야 하는 보다 구체적인 이유에 대해 좀 더 자세히 살펴보자.

    ·IPv4 주소 한계성에 대한 해결책
    가장 먼저 IPv4 주소의 한계성을 해결할 수 있다는 점이다. 현재 국내에서 보유하고 있는 IPv4의 주소 개수는 약 3000만개이나 향후 무선 인터넷 통신망과 인터넷 정보가전의 도입에 따라서 IP 주소의 수요가 폭발적으로 증가해 2010년경에는 2∼4억 개의 IP 주소가 필요한 것으로 추정된다. IPv4 주소로는 급증하는 주소(Public IP Address)의 수요를 충족시킬 수 없으며, IPv6 주소체계의 도입이 절실히 요구된다.

    ·All-IP 환경이 가능한가
    (그림 2)와 같이 인터넷은 데이터 서비스 뿐만 아니라, 전화, 방송 등 기존의 정보통신서비스를 전송할 수 있는 기술적 기반을 이미 확보한 상태다. 이동통신망의 경우에는 유선 ISP 망과 연동이 용이하도록 2005년 이후에 IPv6를 적용하고 2010년 이후에는 All-IPv6망으로 진화할 전망이다. 대부분의 유선 네트워크는 IPv6를 수용하면서 인터넷은 모든 정보통신 서비스를 전송하는 종합 전달망으로 발전할 전망이다.

    - IP over Everything : 모든 전송기술에 인터넷을 적용
    - Everything over IP : 모든 서비스를 인터넷을 통해 제공

    사용자 삽입 이미지

    따라서 All-IP 시대를 준비하기 위해서는 현재의 IPv4 체계로는 서비스 수용에 한계가 예상되므로 IPv6 도입은 필수적이다.

    ·홈네트워크 서비스의 발전 기반 마련
    PC 주변장치의 다수 보유, 정보가전의 등장과 가입자 망의 전송속도 향상에 따라 홈네트워크를 구축할 필요성이 증대되고 있다. LAN, PLC(Power Line Communication), RF(Radio Frequency) 등을 활용한 홈네트워크에 PC, 냉장고, TV 등의 장비를 연결해 다양한 응용 서비스를 제공한다. 향후 홈네트워크가 활성화될 경우 IP 주소의 필요성은 급격히 증가할 것이며, IPv6는 선택이 아닌 필수 요건이 될 것이다. 인터넷을 통해 정보가전 기기들에 접속하고 통제하기 위해서는 모든 정보가전기기에 고정형 공인 IP주소를 적용하고 이를 통해 효율적인 통신이 이루어져야 한다.

    ·유비쿼터스 서비스 발전 기반 마련
    유무선 통합망을 기반으로 해서 모든 단말과 장비들을 대상으로 모든 사물과 컨텐츠에 접근이 가능하며 다양한 멀티미디어를 복합적으로 응용한 유비쿼터스 서비스의 등장이 예상된다. 이러한 유비쿼터스 서비스들이 큰 틀에서 제대로 진행될 수 있도록 진행하기 위해서는 IPv6가 필요하다.

    어떤 방안이든 항상 문제점은 존재한다. 다음호부터 진행될 연재에서는 기존의 시스템을 모두 바꿔 일시에 순수 IPv6(native-IPv6)로 가는 것은 현실적으로 어렵기 때문에 듀얼스택(Dual-Stack)을 고려한 전환방법을 살펴볼 것이다. 이런 상황에서 IPv6가 IPv4에 비해서 늘어난 헤더의 길이로 인해서 소프트웨어적으로 처리할 경우 생기는 성능저하 문제가 존재할 수 있다. 하지만 이런 문제는 하드웨어적인 처리가 가능한 칩이 개발되고 있으며, 이를 통해 중형의 라우터 수준까지는 성능상의 문제가 발생하지 않는 수준에 이르렀다.

      Comments,     Trackbacks