02
2장: 문제점 추적
1. 문제점의 수명주기
* 사용자 -> 제작사 문제점 보고
* 문제점 재현
* 문제 상황 격리
* 코드에서 결함을 찾고 교정
* 교정 결과물을 사용자에게 돌려줌
--> 수명주기의 조직화 필요
1. 문제점이 드러나 있는지 (소프트웨어에 결함이 존재)
2. 가장 심각한 문제점은 무엇인지 (심각도 순서대로 교정 필요)
3. 과거 문제점 사례발생 여부 (기존의 해결책 이용 가능성)
[ 대규모 디버깅 공정을 어떻게 조직화할 것인가? ]
2. 문제점 보고
* 문제점 보고 (Problem Report) == 변경요청 == 버그리포트
* 문제점 보고에 쓸데없지 않은 것만 포함시켜야 함
--> 그러기 위해서 '유관사실'만을 판별하고, 구체적 항목으로 목록화
* 문제점 보고에 포함시켜야 할 내용 (기본원칙)
¤ 제품 릴리즈 (제품버전번호 or 기타 고유식별자)
¤ 운영 환경 (운영체제 버전) --> 일반화(다른 운영환경도 테스트)
¤ 시스템 자원 (CPU 부하,디스크 용량 , 메모리 ..)
¤ 문제점 내력(History)
¤ 기대되는 행동에 대한 서술 (~했어야 했는데, 안했다)
¤ 실제 일어난 행동(증상)
- 최대한 중립적
- 사실만을 기술
¤ 한 줄짜리 요약문 (문제의 핵심 포착)
- 개발자가 문제점 측정시의 심각도 기초
- 로그 파일 등
- 문제점: 사용자가 자신의 정보 유출을 꺼림
3. 문제점 관리
* 한번에 오직 한 사람만 문제점 문서를 다루어야 한다.
- 버전 관리 시스템에서는 분리 병합
* 이전의(교정된) 문제점에 대한 내력이 사라진다.
- 버전 관리 시스템에서는 변경 내력 유지 가능
* 규모 가변성이 없다.
- 하나의 통합된 문서 형태로 관리가 가능해야 함.
---> 그러기위해서, 문제점 데이터베이스에 모든 문제점 보고들을 저장
ex) BugZilla
4. 문제점 분류
# 각 애트리뷰트별로 문제점을 분류
* 심각도 (Severity) - '차단, 치명, 주요, 보통, 부차, 사소' 레벨이 부여
* 우선순위 (Priority) - 개발/문제해결 공정을 조절하는 핵심 기준
* 식별자 (identifier) - 특정 문제점 지칭용
* 주석 (comment) - 문제환경 정보 기입 / 해결책 논의
* 통지
- 문제점보고시 이메일주소 첨부 --> 문제점보고 변경시 자동통지 받음
# 이상적인 제품은 심각한 문제점을 모두 고친 후에 출시 되어야 함.
5. 문제점 처리
* Unconfirmed (아직 누구도 재현해 보지 않은 상태)
* New (문제점 보고가 있어야 유효함 , 유관 사실이 포함되어 있어야 함)
* Assigned (개발자에 배정됨)
* Resolved (해소됨)
* 처리결과
- fixed
- Invalid (문제점이 아니거나 유관 정보가 없음)
- Duplicate
- WONTFIX (교정 불가)
- WorksForme(재현 불가)
- VERIFIED (교정 후 검증 성공)
- Close (제품의 새 릴리즈가 만들어짐)
- Reopen (동일 문제 발생시는, new가 아닌 reopen)
6. '문제점 추적' 관리
* 문제점 정리/보관자는?
* 문제점 보고 분류자는?
* 우선순위 설정자는?
- 문제점 발생 가능성
- 영향을 받는 사용자수
- 피해 가능성
* 문제점 처리자는?
* 문제점 종결자는?
* 문제점 수명주기는?
7. '문제점 == 요구사항'
* 문제점은 개발 과정에서 사용 가능
* 요구사항이 주요 문제점
* 요구사항에 따른 중요도 선정
* 계통구조를 지원 해야 함 (세분화 지원)
8. 중복의 관리
* 최대한 많은 사실을 포함
* 중복을 찾기 위해서는 최대한 적은 사실들이 바람직
* 교정의지 없는 문제점: 개발자가 더이상 지원의사 없음 (BugZilla: Won't Fix)
- 오래된 딱 한번 발생한 문제점
- 오직 내부에서만 발생한 문제점
9. 문제점과 교정의 연계
* 개발자가 버전별 소스/도구를 사용가능 해야함
--> 그래야만 개발자 PC에서 재현 가능
* 임의의 구성(형상)을 언제라도 재현할 수 있어야 함
* 소프트웨어 형상관리는 버전 관리 시스템을 이용
10. 문제점과 테스트의 연계
* 실패한 테스트와 문제점을 어떻게 동기화할 것인가?
* 테스트 결과와 문제점 보고를 분리하도록 권장
- 테스트 결과는 자주 생성됨.
- 테스트는 결과를 굳이 어딘가에 저장할 필요가 없음
- 테스트 실패 시 만일 즉시 교정 가능하면 기록의 필요가 없음.
* 테스트 케이스들은 문제점 보고를 퇴물로 만든다.
* 문제점 발생시 재현 가능한 테스트 케이스를 작성
- 도구 -
벅질라 (www.bugzilla.org)
모질라의 벅질라 사용예 (bugzilla.mozilla.org)
phpBugTracker: 상대적으로 가벼운 버그추적 시스템 (phpbt.sf.net)
그밖에... Trac / IssueTracker / SourceForge / GForge ...
연습문제는 나~중에 실제로 디버깅 할 일 있을 때 직접 풀어보자 ~~~!
22
이것은 이번주 월요일까지 2주간 공부한 "프로그램은 왜 실패하는가"의 내용을 요약한 것입니다.. (1장~4장: 바로바로 복습하면서 계속 편집을 수정해가다 보니 게시물이 길어지기에.. 각 장별로 나누어야겠습니다^^)
아니 뭐... 사실은 다다음 스터디 때 발표해야 하기 때문에 연결되는 앞부분 내용을 이해하기 위해 간단히 복습하면서 정리만 한 것입니다.
요약은 이제껏 발표하신 분들이 올려주신 프리젠테이션 자료를 아주 조금 더 간추린 정도입니다.
저는 4월16일에 7장을 발표하는데, 큰일 났습니다. ㅎ_ㅎ;
잘 할 수 있을지...... 게다가 저는 실무자가 아닌데 디버깅 툴 동영상은 또 어찌 만들라는 ~~~... 시련입니다.
1장: 실패는 어떻게 일어나는가
1. 결함 ------> 실패
* 프로그래머가 결함(감염 발생할 수 있는 코드 일부)을 만듬
- 예측 불가능 / 복수의 모듈간에 인터페이스 비호환
* 결함에서 감염이 발생 (반드시 발생하는 건 아님, 가능성)
* 감염의 확산
* 실패의 발생 (실패: 프로그램 실행시 겉으로 드러나는 오류)
2. 시공의 디버깅
* 디버깅 7단계 (TRAFFIC)
Track (문제 추적)
Reproduce (실패 재현)
Automate (자동화, 단순화)
Find (감염원 탐색)
Focus (감염원 후보에 촛점)
Isolate (감염사슬 격리)
Correct (결함 정정)
- 문제를 추적하고 다시 일으켜보고, 자동화하여 탐색한 후 가능성있는 후보에 촛점을 맞추고 원인으로 보이는것을 격리한 후 정정한다.
* 실패 발생 원인은 F.F.I 에서 발견하게 된다.
* 시간/공간 조사 (온전-->감염으로 전이가 언제/어떻게? ; 디버깅 목표임)
- 변수/참조 수가 늘수록 탐색해야할 시공간 방대
- 확실한 지점 (온전한 초기점 / 일부가 감염된 지점)
- 온전과 감염의 분리, 유관과 무관의 분리
* 의존 사슬: 실패에서부터 이전 변수값들로 이어지는 의존 관계 사슬
* 프로그램 코드/상태 구조화: 함수,모듈,객체..
3. 프로그램이 이상해요
* 실패 경로: 결함(Defect) --> 감염(Infection) --> 실패(Failure)
* 최초 버그 1947.09.09 하바드 마크 II, 나방이 끼어 죽음
* 프로그램 결함은 프로그래머로 인함.
4. 실패 ---> 교정
* 문제점 추적: 문제보고서를 기록/보관하는 일
- 실패과정도 문제재현 절차에 포함
* 복잡한 프로그램의 경우, 실패 재현의 자동화 필요 (사람이 일일이 재현하기 힘듬) - (3장,5장)
* 감염원 후보 찾기
- 출력이 0이 되는 원인 찾는다
- 연역(7장)이 어려울 때는, 실패 과정 관찰(8장)
- 가능성의 영역을 좁혀나감 (수사 과정)
- 프로그램 실행 도중의 상태관찰 수단 필요
* 유력 후보 감염원에 촛점 맞추자
* 감염원 격리
* 결함 정정 : 이렇게 수정한 후 실패가 안 나타나면, 역시나 그 결함이 실패원인이었음이 입증됨.
5. 자동화 디버깅 기법
* 입력 단순화 (델타디버깅 - 5장)
* 프로그램 슬라이스 (오류 연역 - 7장): 프로그램 실행시 발생 가능/불가능한 사건을, 코드로부터 도출 (추상 ---> 구체)
* 상태 관찰 (사실 관찰 - 8장): 디버거 이용, 프로그램의 특정 상태에 정지시켜 관찰 가능 / 프로그램 변경이나 리컴파일 없이 실행중 관찰 가능
* 상태 감시 (8장): 상태 일부가 실행도중 어떻게 변하는지 관찰 (변수의 감염 순간 포착 가능)
* 단언 (기대의 단언 - 10장): 관찰값/의도값 비교, 함수나 프로그램 전체에서 성립해야 하는 불변식
* 비정상 (비정상 검출 - 11장): 정상/실패 실행간의 차이로부터 비정상을 식별해냄.
* 인과 사슬 (인과사슬의 격리 - 14장): 프로그램 상태에 델타디버깅 적용. 인과관계 원인이 반드시 오류는 아님, 실패요인을 좁혀나갈 수 있다.
* 여러 기법 종합 사용 (결함 고치기 - 15장): 앞의 언급한 다양한 기법들을 연동
* 기타 (실패추적-2장, 자동검사-3장, 실패재현-4장, 여러추론기법결합-6장, 실패원인체계적탐색-12장)
6. 용어 비교/차이
(1) 버그: 사람이 제어가능하거나, 사람에게 책임이 없는 '어떤 것' 암시 / 의미 불분명 / 프로그램의 부정확한 상태,코드,동작 모두를 구분없이 두루두루 지칭하여 혼동을 일으킴 (원인과 증상의 모호)
(2) 결함: 부정확 코드
(3) 감염: 부정확 상태
(4) 실패: 눈에 보이는 수행/동작 버그
# 코드 --> 상태 --> 실행 (버그 발견시, 버그 추적, 버그 교정)
따라서, 용어 의미 불분명으로 혼란스러움,, 아래와 같이 고치면...
# 결합 --> 감염 --> 실패 (실패 발견시, 감염 추적, 결함 교정)
(5) 결점: 전반적 설계/구조 결함 (결함보다 심각)
# 버그: 프로그래머가 그저 짜증스러움에서 대충 뭉뚱그려 사용하는 표현
- 정확한 용어선택으로 실패 근원을 구체화
- 버그라는 용어는 웬지 소프트웨어에 이유없이 자동발생하는 것처럼 느껴짐
- 오류/잘못: 웬지 명백한 인간만의 잘못인 듯한 뉘앙스
- 결함/감염: 반드시 인간의 실수만은 아닌 듯한 느낌, 불필요한 죄책감 모면
- 도구 -
Algorithmic and Automatic Debugging Home Page
http://www.cs.nmsu.edu/~jeffery/aadebug.html
15
Billy Hollis
Elysian Consulting
2004년 3월 24일
요약: 최근 수 년간 웹 응용 프로그램에 지대한 관심이 모아지면서, 클라이언트의 향상과 함께 클라이언트 쪽 개발에 대해 다시 연구해야 할 필요성이 대두되었습니다. Microsoft 지역 담당 이사들이 저술하는 이 새 칼럼 .NET in the Real World에서 Billy Hollis가 스마트 클라이언트에 대해 설명하고 현재 스마트 클라이언트를 사용하여 응용 프로그램을 빌드하는 방법을 설명합니다(6페이지/인쇄 페이지 기준).
관련 서적
오래 전에는 스마트 클라이언트를 메인프레임이라고 불렀습니다. 나이가 많지 않은 사용자는 이러한 시기를 기억하지 못할 수도 있습니다. 이 메인프레임의 작동 방식에 대해 간단히 살펴보겠습니다. 당시, 거대한 메인프레임 시스템은 모든 처리를 수행했습니다. 이 시스템은 정보 페이지를 어셈블하여 터미널이라는 장치로 보냈습니다. 가장 일반적인 터미널 유형은 3270이었습니다.
터미널은 단순한 장치라고 할 수 있었습니다. 그 처리 기능에 대해서는 얘기할 것이 없습니다. 사용자가 터미널로 수행할 수 있는 작업이라고는 데이터 필드를 채우고 화면을 탐색하는 것뿐이었습니다.
데이터 페이지 작업을 마친 후 터미널에서 단추를 누르면 페이지의 정보가 다시 메인프레임으로 전송됩니다. 그러면 메인프레임에서는 페이지의 정보를 받아 처리하고 새 페이지로 내보낼 수 있도록 준비합니다.
이후 PC가 출현하여 네트워크에 연결된 이후에야 메인프레임보다 효과적인 작업을 할 수 있게 되었습니다. PC의 처리 기능을 사용하여 사용자 인터페이스를 보다 지능적으로 만들고 사용자의 작업 방식에 대해 기억하게 만들 수 있습니다. 그러면 사용자가 더욱 효율적이고 생산적으로 작업할 수 있습니다.
이렇게 새로운 시스템 유형이 탄생했습니다. 이 시스템의 가장 큰 장점은 사용자의 PC와 거대한 중앙 컴퓨터에 효과적으로 작업을 배포할 수 있다는 점입니다. 이러한 점으로 인해 서버라는 새 이름이 생겼습니다. 이 클라이언트-서버 시스템은 PC와 대형 중앙 시스템에서 각각 최상의 작업을 수행할 수 있게 합니다. 클라이언트-서버는 대부분의 메인프레임을 대신하게 되었고 사용자들도 이 클라이언트-서버를 더 선호하게 되었습니다. 사용자가 생산적이고 즐거운 작업을 할 수 있는 길이 열린 것입니다.
그런 다음 인터넷이 출현했습니다. 처음에 인터넷은 단지 정적 하이퍼링크 페이지를 검색하는 데만 사용되었습니다. 그러나 젊은 층 사용자들이 인터넷을 통해 많은 작업을 수행할 수 있다는 평가를 보이기 시작했습니다. 즉, 인터넷에서 응용 프로그램을 실행하고 모든 처리를 수행하는 대규모 중앙 웹 서버를 사용할 수 있습니다. 또한 페이지를 사용자에게 전송하면 페이지를 받은 사용자는 브라우저에서 이 페이지를 보면서 탐색하거나 데이터를 입력할 수 있습니다. 그런 다음 사용자가 단추를 눌러 페이지의 정보를 다시 대규모 시스템으로 전송하면, 이 시스템에서는 해당 정보를 처리하고 다시 새 페이지를 전송합니다. 이와 같은 모든 작업이 인터넷을 통해 가능해진 것입니다.
브라우저에는 지능적 기능이 많지 않았습니다. 즉, 브라우저는 PC에서 이 브라우저를 실행하는 것 외에는 아무것도 수행하지 않는 "씬 클라이언트"로 간주되었습니다. 그리하여 20년 전의 메인프레임보다 훨씬 많은 처리 기능을 갖춘 PC가 아날로그 방식 3270 터미널로 퇴화되었습니다.
이같이 엄청난 수준의 역행이 발생하게 된 이유는, 다른 대부분의 분야에서와 마찬가지로 "비용" 때문이었습니다. Microsoft에서는 브라우저 기반 시스템을 통해 처음으로 전 세계 사용자가 Microsoft 시스템에 액세스할 수 있게 했으며, 이는 큰 발전이었습니다. 새로운 사용자가 시스템에 액세스할 수 있게 하는 데는 기본적으로 비용이 전혀 들지 않았습니다.
"리치 클라이언트" 또는 "스마트 클라이언트"라는 대안을 위해서는 일부 특수 소프트웨어를 사용자 시스템에 설치해야 했습니다. DOS 시기에는 이 작업이 쉬웠습니다. 소프트웨어를 복사해 놓기만 하면 실행되었습니다. 그러나 사실상 브라우저와 거의 같은 시기에 COM이 나타났고 DLL이라는 용어가 대두되었습니다. 그리하여 우리는 소프트웨어를 사용자 컴퓨터에서 실행하는 것을 포기했으며, 다른 방법을 수행할 여력이 없었기 때문에 브라우저만을 사용했습니다. 아무 것도 없는 것보다는 무엇인가 있는 게 나았기 때문이죠. 성능이 좀 떨어지더라도 수행할 여력이 되는 대안을 실행하는 편이 아무 것도 실행하지 않는 것보다는 낫다는 뜻입니다.
그러나 여기서 발상을 전환해 보겠습니다. 소프트웨어를 사용자 시스템에 배포하는 비용이 브라우저를 사용할 때처럼 비용이 전혀 들지 않는 것에 아주 가까울 정도로 저렴하게 줄어든다고 가정해 봅시다. 그러면 어떤 현상이 발생할까요?
First Law of Software Development에서 Billy가 언급하는 의견은 다음과 같습니다. 사용자 수가 프로그래머 및 기술 지원 담당자 수보다 많습니다. 사용자가 있기 때문에 우리 시스템이 존재하는 것입니다. 사용자가 지능적인 응용 프로그램 소프트웨어 인터페이스를 사용할 수 있게 되어 작업을 보다 효율적으로 수행할 수 있음을 알게 된다면, 불편한 인터페이스를 더 이상 사용하지 않게 될 것입니다. 또한, 응용 프로그램 인터페이스를 위해서가 아니라 하이퍼링크 페이지를 검색하기 위해 디자인된 프로토콜을 사용하여 만들어진 페이지에 만족하지 못할 것입니다. 금방 불편이나 싫증을 느끼게 될 것이라는 의미입니다.
가능성을 고려해 보십시오. 시스템에 천 명의 운영자가 있을 경우, 스마트 클라이언트 소프트웨어를 통해 운영자 작업 효율성이 단 5% 정도만 상승한다 해도 비용 절감 효과는 엄청날 수 있습니다. 직원 한 명당 비용이 5만 달러라고 가정할 때, 천 명의 운영자에 대해 생산성이 5% 향상될 경우 50명의 운영자에 해당하는 비용인 2백 5십만 달러가 절약됩니다. 또한 여기에는 보다 낮은 학습 비용과 오류 비율, 사용자의 혼란과 스트레스 등의 감소 및 기타 스마트 클라이언트 소프트웨어의 제품별 잠재 감소 비용이 포함되어 있지 않습니다. 더구나, 상승률 5%는 매우 낮게 잡은 수치입니다. 작업에 따라 10%에서 20%까지 생산성이 향상되는 경우도 드물지 않습니다.
선택
이 분석이 정확하다면 소프트웨어 개발 및 IT 분야의 의사 결정권자들이 선택을 하는 데 있어 큰 영향을 미칠 수 있을 것으로 보입니다. 어렵지 않게 스마트 클라이언트를 받아들이는 사용자도 있겠지만, 거부감을 느끼는 사용자도 있을 것입니다. 또한 선택한 전략이 득이 될 수도 있고 실이 될 수도 있습니다.
브라우저 기반 소프트웨어에 크게 의존하는 1990년대 방식을 고수할 수도 있습니다. 속해 있는 업계 및 조직이 신기술로 전환하는 속도에 따라, 이러한 전략을 문제 없이 채택할 수도 있습니다. 그러나 기술이 경쟁력을 좌우하는 빠르게 변화하는 업계에서 이러한 전략은 업무 자체에 큰 위험을 초래할 수 있습니다. 조직의 기술 관련 실무 담당자가 "이 브라우저 기반 방식은 쓸모가 없습니다. 사용자에게 인기도 없을 뿐더러 사용자의 작업 속도도 떨어뜨리고 있습니다. 사용자가 작업을 보다 신속하고 효율적으로 수행할 수 있도록 하고 회사의 비용을 크게 줄여 주는 지능적인 사용자 인터페이스가 포함된 다른 시스템으로 바꾸는 것이 좋겠습니다. 이미 늦었는지도 모르겠군요. 지금 당장 바꿔야겠습니다."라고 할 수도 있고, "부서 관리자를 변경하기로 결정했습니다"라고 말하는 더 나쁜 상황이 발생할 수도 있습니다.
이러한 상황을 원하지는 않으시겠죠? 그렇다면 스마트 클라이언트 사용을 고려해 보십시오. 먼저, 새로 작성하는 응용 프로그램을 사용할 500명의 사용자가 구식 브라우저 인터페이스를 사용하도록 할 것인지 아니면 새롭고 뛰어난 지능적 사용자 인터페이스를 사용하도록 할 것인지를 결정해야 합니다. 이 결정을 통해 수백 또는 수천 사용자의 생산성을 향상시키고 비용을 크게 절감할 수 있는 소프트웨어를 만들 수도 있습니다. 당신이 만든 인터넷 응용 프로그램에 대해 사용자들이 찬사를 보낼 수도 있다는 것입니다.
시작하기
현명한 선택을 하려면 스마트 클라이언트 개발의 장단점에 대해 파악해야 합니다. 스마트 클라이언트 아키텍처가 작동하게 만드는 데는 다음과 같은 4가지 주요 기술이 필요합니다.
- 지능적 클라이언트 소프트웨어를 만들기 위한 폼 패키지
- 로컬 네트워크 또는 인터넷에서 스마트 클라이언트와 중앙 서버 간에 데이터를 교환하기 위한 데이터 전송 기술
- 인터넷에서 다양한 경우에 스마트 클라이언트 소프트웨어를 클라이언트 컴퓨터에 배포하기 위한 수단
- 악의적인 액세스로부터 시스템을 보호하기 위한 보안 기술
현재, 이러한 기능을 모두 사용할 수 있는 플랫폼은 Microsoft .NET Framework입니다. Microsoft .NET Framework이 유일한 분산 스마트 클라이언트 시스템용 플랫폼은 아니지만, Java 등의 다른 플랫폼보다 크게 앞서 있습니다. 위의 각 분야에서 .NET 기능을 살펴보고, .NET이 다른 플랫폼에 비해 앞서 있는 이유를 알아보겠습니다.
클라이언트의 폼
.NET Framework에는 현재 사용 가능한 가장 발전된 폼 엔진 중 하나인 Microsoft Windows Forms가 포함되어 있습니다. 이 폼은 완전한 객체 지향이며 Microsoft 및 타사의 다양한 비주얼 컨트롤을 포함합니다. 또한 Microsoft Visual Studio 개발 환경에는 뛰어난 비주얼 디자이너가 포함되어 있으므로 Windows Forms 인터페이스를 신속하게 만들 수 있습니다.
Windows Forms의 이벤트 중심 방식과 상태 정보를 필요한 만큼 로컬에 저장할 수 있는 기능을 사용하면 사용자 인터페이스의 응답 능력을 크게 향상시킬 수 있습니다. 파생 데이터 입력 작업에는 해당 작업을 위해 특별히 만들어진 인터페이스를 사용할 수 있습니다. 정교한 데이터 유효성 검사는 데이터가 정확한지 확인하기 위해 페이지를 다시 로드할 필요 없이 처음부터 올바른 데이터를 사용할 수 있게 합니다. 물론 브라우저에서도 이러한 작업 중 일부를 수행할 수 있습니다. 그러나 이러한 작업을 수행하는 데는 불필요한 다량의 프로그래밍 작업이 수반됩니다.
Windows Forms 인터페이스에는 자습서 창, 도구 설명, 투명한 도움말 폼, 사용자가 해당 동작을 수행할 수 있도록 하는 동적 컨트롤 등이 포함될 수 있습니다. 또한 Windows Forms 인터페이스는 일반적으로 해당 웹 페이지보다 빠르게 개발할 수 있습니다.
Microsoft에서는 이러한 기술 영역에 많은 투자를 하고 있습니다. 이미 차세대 UI 기술이 발표되었습니다. 이 프로젝트의 코드 이름은 "Avalon"이며, 현재 개발 중에 있는 다음 Microsoft Windows 릴리스(코드 이름 "Longhorn")의 일부입니다. Avalon에는 브라우저에서는 사실상 불가능한 일부 새로운 사용자 상호 작용 방식을 포함하여 사용자 인터페이스의 응답 능력을 향상시키는 많은 기능이 추가될 예정입니다.
이러한 기술을 활용하려면 개발자는 사용자 인터페이스 디자인 원칙에 대해 보다 자세히 파악해야 합니다. 지금까지 단순히 브라우저 기반 프로그래밍만 수행한 개발자는 UI 디자인에 대해 익혀야 할 사항이 많다는 사실을 모르고 있을 수도 있습니다. 응답 능력이 뛰어나고 지능적인 인터페이스를 작성하는 방법을 알아야 시스템에 이러한 인터페이스를 포함할 수 있습니다.
여기에는 한 가지 제한 사항이 있습니다. Windows Forms는 .NET Framework의 일부이기 때문에 Windows 플랫폼에서만 사용할 수 있습니다. 그러나 일반적으로 그러하듯이 조직에서 클라이언트 워크스테이션에 대해 Microsoft Windows Server System™을 표준으로 지정한 경우 이러한 사항은 문제가 되지 않습니다.
데이터를 필요로 하는 응용 프로그램
대부분의 회사 및 상용 응용 프로그램은 일반적으로 일부 중앙 서버에 저장되어 있는 데이터를 조작합니다. 실용적인 스마트 클라이언트 응용 프로그램이라면 서버에서 클라이언트로 데이터를 가져와서 클라이언트에서 데이터를 변경한 다음 다시 데이터를 서버로 보낼 수 있어야 합니다.
Microsoft의 최신 데이터 액세스 기술인 Microsoft ADO.NET은 바로 이러한 시나리오를 위해 디자인되었습니다. 이전의 데이터 액세스 모델과는 달리, ADO.NET은 분산적으로 사용하기 위해 만들어졌습니다. 서버에서 데이터의 XML 기반 컨테이너를 만들어 클라이언트로 전송할 수 있습니다. 클라이언트는 컨테이너를 통해 서버에 대한 연결을 유지하지 않은 상태로 데이터에 대한 작업을 수행하여 데이터를 변경 및 추가한 다음 컨테이너를 다시 서버로 보낼 수 있습니다.
클라이언트와 서버 컴퓨터 간에 데이터를 실제로 전송하는 데 사용할 수 있는 주요 기술에는 두 가지가 있습니다. 하나는 웹 서비스입니다. 웹 서비스의 장점에는 구현 및 구성의 용이성, 많은 종류의 서버에 대한 상호 호환성 등이 있습니다. 적합한 데이터 컨테이너를 만드는 데는 약간의 작업이 더 필요하지만 웹 서비스는 Microsoft 서버가 아닌 서버와도 호환될 수 있습니다.
사용자 응용 프로그램에 관련된 모든 시스템에서 Microsoft .NET을 실행할 수 있는 경우에는 .NET 원격 기술을 사용할 수도 있습니다. 이 기술에는 성능 및 보안상의 장점이 있지만, 구성하기는 더 어렵습니다. 내부 사용자를 위한 대규모 스마트 클라이언트 시스템은 종종 원격 기술을 사용하지만 조직 외부에 있는 사용자가 사용하는 시스템은 웹 서비스를 많이 사용합니다.
두 가지 경우에서 모두 스마트 클라이언트 응용 프로그램은 브라우저 기반 시스템보다 훨씬 지능적으로 데이터를 처리할 수 있습니다. 예를 들어, 스마트 클라이언트에서 서버와의 연결이 끊길 경우 서버를 다시 사용할 수 있을 때까지 데이터의 로컬 복사본을 유지할 수 있습니다. 스마트 클라이언트 응용 프로그램은 온라인 및 오프라인 시나리오에 맞게 해당 동작을 동적으로 조정할 수 있습니다.
낮은 배포 비용
처음에 글을 시작할 때 스마트 클라이언트 시스템의 배포 비용을 브라우저 기반 시스템만큼 저렴하거나 거의 비슷하게 만드는 경우의 결과에 대해 언급했습니다. 브라우저 기반 응용 프로그램은 각 추가 사용자에 대해서는 사실상 배포 비용이 들지 않으므로, 이 응용 프로그램보다 배포 비용을 훨씬 저렴하게 만들기는 어렵습니다. 그러나 경쟁력을 갖출 정도로 스마트 클라이언트 배포 비용을 줄일 수는 있습니다. 또한 스마트 클라이언트를 사용하면 생산성 향상을 통해 많은 비용을 절약하게 될 수도 있으므로 약간의 추가 배포 비용은 경제적으로 무리가 없습니다.
배포 비용을 줄이는 주요 기술은 .NET Framework의 복사 및 실행(copy-and-run) 기능입니다. COM에서처럼 시스템 구성 요소를 등록하기 위한 복잡한 절차가 필요하지 않습니다. 구성 요소를 디스크에 복사하기만 하면 나머지 작업은 Framework에서 수행합니다. 또한 여러 DLL 버전을 함께 실행할 수 있으므로 호환되지 않는 DLL 문제가 없어집니다.
제한된 형식의 자동 인터넷 배포가 이미 .NET Framework에 포함되어 있으며, 보다 고급 버전인 코드 이름 "ClickOnce"가 다음 버전에 포함될 예정입니다. 또한 복사 및 실행(copy-and-run) 방법을 활용하여 자체 업데이트 응용 프로그램을 쉽고 저렴하게 만들 수 있는 사용자 지정 배포 시스템을 간편하게 만들 수 있습니다.
브라우저 기반 응용 프로그램을 실행하려면 브라우저를 클라이언트 시스템에 설치해야 하는 것과 마찬가지로, .NET 기반 스마트 클라이언트를 실행하려면 .NET Framework를 클라이언트 컴퓨터에 설치해야 합니다. 현재 Windows XP, Windows 2000, Windows 98/Me 등 대부분의 클라이언트 컴퓨터에서 사용하는 운영 체제에서는 .NET Framework가 자동으로 설치되지 않기 때문에 추가 작업이 필요합니다. 그러나 이러한 운영 체제에서 .NET Framework를 무료로 설치할 수 있습니다. Microsoft에서는 이후의 운영 체제 제품에 .NET Framework를 포함시킬 예정이므로 앞으로 새 버전의 운영 체제가 출시되면 .NET Framework를 쉽게 접하게 될 것입니다. 사실 Microsoft에서는 이미 Microsoft Windows Server™ 2003에 .NET Framework를 포함시켰습니다.
완벽한 보안
지난 몇 년간 사용자들은 인터넷에 악의적인 사용자들이 많다는 사실을 알게 되었으며, 그리하여 시스템의 보안을 더욱 강력하게 유지하고자 했습니다. 그러나 분산 스마트 클라이언트 시스템에는 확실히 새 보안 기능이 필요합니다.
다행히도 .NET Framework는 엄격한 보안 원칙 하에 디자인되었습니다. 버퍼 오버런과 같은 취약점을 제거하는 것 외에 코드 액세스 보안이라는 새로운 형식의 보안 기능이 추가되었습니다. 이 기능은 코드 출처, 코드 작성자 등 코드에 대한 정보를 기반으로 코드에 보안 권한을 부여합니다. 이 보안 기능은 일반 사용자 기반 보안을 기준으로 하며, 코드를 다시 한 번 보호해 주는 역할을 합니다.
클라이언트와 서버 시스템 간의 인터페이스를 보다 주의 깊게 제어할 수 있으며 시스템의 실행 가능 부분에서 필요한 권한만을 받을 수 있기 때문에 적절히 디자인된 스마트 클라이언트 시스템은 일반 브라우저 기반 시스템보다 안전하다고 할 수 있습니다. 그러나 이러한 고급 보안을 디자인하려면 새로운 기술과 개념을 배워야 합니다.
작업 계획
스마트 클라이언트로의 전환을 서두를 필요는 없습니다. 앞으로 2년 내라면 괜찮습니다. 물론, 그 전에 경쟁사가 먼저 전환하지 않아야겠지만요. 사용자는 아직 이러한 실정을 잘 파악하지 못하고 있습니다. 또한 적절한 비용으로 배포하기 위해서는 .NET Framework를 클라이언트 컴퓨터를 설치해야 합니다.
그러나 이는 일시적일 뿐입니다. 앞으로 몇 년이 지나면 스마트 클라이언트 응용 프로그램이 많은 브라우저 기반 응용 프로그램을 대신하게 될 것이라고 확신합니다. 저만 해도 이미 5명의 고객이 스마트 클라이언트 응용 프로그램으로 전환하겠다고 했으며 그 결과에 대해 큰 기대를 하고 있습니다.
그러나 전환 시 전혀 부담이 없는 것은 아닙니다. 개발자는 새롭게 배포된 아키텍처와 새 기술을 배워야 합니다. 또한 대부분의 경우 개체 지향 개발 및 사용자 인터페이스 디자인에 대해 익숙해져야 합니다.
브라우저 기반 개발을 배우는 데 5년이라는 시간을 투자한 개발자는 변경하기를 원하지 않을 수 있습니다. 그들은 그러한 시간을 거쳐 이미 당대 최고의 개발자가 되었기 때문입니다. 그러나 모든 기술에는 전성기와 쇠퇴기가 있으며, 보다 새로운 기술로 대체됩니다. 오랫동안 특정 시나리오에 사용된 브라우저 기반 응용 프로그램에 대해 살펴보면서 브라우저 기반 개발의 전성기는 이미 지났다는 확신을 가지게 되었습니다. 어떤 기술이 최신 상태에서 구식이 되는 데는 시간이 걸릴 수 있지만, 이는 시간이 지남에 따라 반드시 나타나는 현상이기 때문입니다. 스마트 클라이언트를 사용할 수 있도록 준비하십시오!
관련 서적
Windows Forms Programming in C# 
.NET in the Real World
CLR (Common Language Runtime)
CLR은 마이크로소프트의 .NET 프레임웍의 일부로서, 지원되는 언어 중 어떤 하나로 작성된 프로그램이 공통의 객체지향형 클래스를 공유할 수 있도록 해주는 실행 관리 프로그램이다. CLR은 자바 언어로 컴파일된 프로그램을 실행시키기 위해 썬 마이크로시스템즈가 제공하는 자바 가상머신에 어느 정도 비교될만하다. 마이크로소프트는 자사의 CLR을 하나의 "관리 실행 환경"이라고 지칭한다. CLR용으로 컴파일된 프로그램은 반드시 해당 언어 고유의 실행 환경만을 고집하지 않으며, 윈도우2000이나 윈도우XP가 돌아가는 시스템이라면 어디서라도 실행될 수 있다.
비주얼 베이직, 비주얼 C++ 또는 C# 언어를 쓰는 프로그래머들이 자신들의 프로그램을 이식 가능 실행 파일 내에서 CIL이라는 중간 형태의 코드로 컴파일하고 나면, 이를 CLR을 통해 관리하고 실행시킬 수 있다. 프로그래머가 컴파일할 때 그에 관한 서술적 정보를 지정하면, 이 정보는 컴파일된 프로그램과 함께 메타데이터로서 저장된다. 컴파일된 프로그램 내에 저장된 메타데이터는, 사용된 언어의 종류와 버전, 그리고 그 프로그램에 필요한 클래스 라이브러리는 무엇인지 등에 관한 정보를 CLR에게 알려 준다. CLR은 한 언어로 작성된 클래스의 인스턴스가 다른 언어로 작성된 클래스의 메서드를 호출할 수 있게 해주며, 자투리 모으기와 예외 처리 및 디버깅 서비스 등도 제공한다.