사용자들의 Ajax 방식의 웹 환경에 경험이 많아지면서 일부분이라도 Ajax 방식의 애플리 케이션을 제작 해야 합니다.
하지만 시간도 없고 당장 구현도 해야 하니 다른 사이트나 강좌를 통해 코드 카피를 통해 구현 하는 것을 많이 봐 왔습니다.
웹 애플리케이션에 대한 Ajax를 적용한다는건 제가 경험 하기로는 단순한 사용자 UI의 변경을 의미 하는건 아니였습니다.
Ajax 애플리케이션은 시스템 전체에 영향을 주며, 아키텍처적 변경 부터 구현 알고리즘까지 모든 개발 과정과 사고에 영향을 주는 막대한 작업 이였습니다.
그렇다고 Ajax를 구현하기가 심히 어렵거나 비용이 많이 들어가는건 아닙니다.
다만 모든 기술이 그렇듯 사용하기 위해 그 기술에 대한 깊은 이해를 바탕으로 이용을 해야 합니다. 그렇지 못한 경우 그 기술이 양날의 검이 되어서 내게로 다시 돌아와 돌이킬수 없는 큰 상처를 남기기도 하지요 그래서 다음과 같은 Ajax의 개론에 대한 강좌를 팀 블로거로 가져 와 봤습니다.
물론 개론적인 것이지만 실무적으로 또는 더 깊이가 있는 내용을 원한다면, 지금은 서적및 Ajax에 대한 자료들이 넘쳐나니 개인적으로 충분이 구하실수 있다고 생각하고 아래 내용만 올려 드립니다.

작성자 네오비스

금주 Microsoft는 ASP.NET에서의 AJAX 개발을 위한 프레임워크였던 Atlas를 ASP.NET AJAX라는 이름으로 변경하고, 그 베타버전을 출시하였다. 단순히 웹 개발을 위한 프레임워크의 출시로 볼 수 있지만, 새로운 변화를 준비하는 Microsoft의 웹 개발의 관점에서다시 한번 생각해 보도록 하자. Microsoft는 2007년 1월 Windows Vista와 Office의 새로운 버전을준비하고 있다. 더불어 윈도우 라이브 닷컴을 통해 인터넷 서비스 기업으로의 영역 확대를 시도하고 있다. 얼마 전 국내에서는 Microsoft DevDays2006 행사를통해 윈도우 라이브 닷컴 가젯(플러그인 또는 작은 응용 프로그램) 콘테스트의 시상식을 가졌다. 일반 개발자들을 대상으로 한콘테스트의 의미도 있지만, Microsoft는 전세계 웹 개발자들에게 윈도우 라이브 닷컴의 존재와 매시업(mash-up) 형태의개방된 가젯 구조를 지원하고 있다는 것을 알리는데 더 큰 의미를 두었을 것이다. 다른 나라 개발자들의 작품을 살펴보고 싶다면 윈도우 라이브 닷컴 가젯 갤러리를 한번 방문해 보자.

ASP.NET AJAX로의 프레임워크 이름을 변경하다.
이번 프레임워크에서의 표면적인 큰 변화는 바로 ASP.NET AJAX로의 이름 변경이다. 지금까지 Atlas라는 이름보다는 보다직관적인 이름을 사용하여 개발자들이 쉽게 프레임워크의 기능을 이해하도록 배려하였다. 진작 이런 이름을 사용하였으면 더 좋았을것이지만 지금이라도 이렇게 변경해주니 그나마 바른 선택이라 생각한다.

더불어 기존 Atlas CTP 버전을 통해제공하던 프레임워크의 기능을 크게 3가지로 나누어 배포하고 있다. ASP.NET AJAX Core에 해당하는 ASP.NETAJAX 1.0 Beta, 기존 CTP 버전에서 제공하였지만 Core에 포함되지 않은 부가기능에 해당하는 ASP.NET AJAXCTP, 마지막으로 공개적으로 개발되고 있는 다양한 컨트롤을 제공하는 ASP.NET AJAX Control Toolkit이 이에해당한다. 여기서 한가지 주목할 부분이 바로 Control Toolkit이다. 지금까지 Microsoft는 모든 개발 툴 및컴포넌트를 자사에서 개발하였다. 그러나 이번 ASP.NET AJAX Control Toolkit은 외부로 공개하여 다른개발자들도 참여할 수 있도록 유도하고 있다. 이전에 비해 사뭇 달라진 그들의 모습을 볼 수 있는 대목이라 생각된다. 국내개발자들도 프로젝트 사이트를 통해 참여할 수 있으니 한번 살펴보도록 하자.

개발자들에게 선택의 폭을 넓혀주는 ASP.NET AJAX
AJAX기반의 웹 페이지를 만든다는 것은 개발자들에게 있어 더 많은 코드작업을 요구한다고 이해하면 된다. 보다 멋진 화면을 위해비동기처리니 클라이언트에서의 자바스크립트 코드 작업에 지금도 고생하고 있는 그들이다. 그러나 ASP.NET AJAX는 기본적으로AJAX 기반의 웹 페이지 개발에 있어 서버상의 ASP.NET의 특징과 클라이언트의 스크립트 특징을 통합하여 제공하려는 목적이있다. 즉 ASP.NET 서버 사이드 개발과 함께 클라이언트 스크립팅을 통합하여 제공하고 있다. 대부분의 AJAX 기반의 웹개발이 클라이언트 또는 서버 중 하나에 집중되어 있는데 반해 ASP.NET AJAX는 개발자들이 사용하기 편한 방식을 선택하여응용 프로그램을 제어할 수 있도록 클라이언트/서버 모두를 위한 툴을 지원하고 있다.

그러므로 개발자들은 보다쉬운 코딩 방식을 선택하여 ASP.NET 기반의 AJAX 웹 페이지를 구축할 수 있는 것이다. 예를 들어 AJAX 서버 컨트롤을이용하면, ASP.NET 웹 페이지(*.aspx)에서의 어떠한 자바스크립트 코드 작업 없이 단순한 컨트롤의 추가만으로 페이지의일부가 렌더링되는 AJAX 스타일의 페이지를 만들 수가 있다. 바로 서버 컨트롤과 ASP.NET AJAX 프레임워크가 페이지실행을 위한 클라이언트 스크립트를 자동으로 만들어주기 때문에 가능한 코딩 방법인 것이다. AJAX 스타일의 웹 개발에서 큰문제로 대두되고 있는 개발 생산성 문제를 어느 정도 해결해 줄 것으로 기대되는 부분으로 가장 큰 매력이 될 것이다.

[그림 1] 서버 중심의 응용 프로그램 모델


[그림 2] 클라이언트 중심의 응용 프로그램 모델



Microsoft는 윈도우 라이브 닷컴에서 보듯이 서비스 시장으로의 확대를 준비하고 있다. 이런 준비와 함께 웹 개발자들을 위한 새로운프레임워크와 프로그램을 제공할 예정이다. 또한 그들이 제작하는 웹 페이지에 이런 기술들을 사용하여 개발자들에게 신뢰를 주고,개발자들에게 보다 쉬운 개발환경과 생산성을 제공하여 입지를 굳건히 하려고 노력하고 있다. 이와 함께 자신들과 동일한 개발플랫폼을 사용하는 사이트를 확대하기 위한 노력도 ASP.NET AJAX를 통해 알 수 있다. 

웹 2.0 시대로넘어오면서 PHP, Ruby 같은 언어들이 보다 더 많이 주목을 받고 있다. 국내 시장만 들여다보더라도 과히 PHP의 전성시대인것 같다. 서버 점유율로만 보더라도 이전에도 PHP가 국내 웹 개발 시장의 대세였다. 이런 국내 환경에서 Microsoft가지금까지의 부진을 만회할 수 있을지 앞으로의 행보가 궁금하다. 모든 개발은 주어진 환경과 상황에 맞게 그 플랫폼이 선택되고,구현되어야 한다고 필자는 믿고 있다. 잠시 자신의 개발 플랫폼 이외의 다른 개발 플랫폼을 들여다 보는 여유를 가져보는 것은어떻겠는가? 더불어 국내에서 보다 활발하게 웹 2.0스러운 사이트가 개발되기를 바라며, ASP.NET AJAX를 이용한 좋은사이트들이 많이 생겨 ASP.NET AJAX 공식 사이트에서 소개되기를 기대해본다.

녹색 성장과 소프트웨어

얼마전의 우리 정부는 연 7% 의 고속 성장 목표에서 환경을 생각하는 녹색성장 정책으로 국가의 정책을 변경하였습니다.

녹색성장이란 저탄소 산업을 육성하여 경제와 산업 성장에 있어서 탄소 연료 소비를 최소화하고 이산화 탄소 등 환경 공해 물질을 억제하여 지구를 환경 파괴로 부터 지키기 위한 산업 성장을 말합니다.

물론 현 정부가 녹색성장의 동력으로 원자력에 의존하는 부분 등 미숙한 부분도 있지만, 심각한 수준에 있는 지구의 환경 파괴 상태를 본다면, 정말 기쁘고 반가운 소식이 아닐 수 없습니다.

TV,인터넷, 라디오, 신문, 잡지, 영화 등 모든 미디어들은 현재의 지구 상태를 매우 심각한 상태로 보고 하며, 우리에게 경고를 주고 있습니다.

하바드, 캠브리지 등 세계의 대학과 그곳의 석학들도 우리에게 심각하게 경고합니다.

하지만 아직 아무도 지구 환경에 대한 긍정적인 영향을 소프트웨어가 큰 부분에 있어 작용한다는 것에 대해서 이야기하지 않는 것 같습니다.

물론 제가 업으로 삼고 있는 것이 소프트웨어 개발이라 좁은 관점에서 사고한 이론인지 모르겠습니다.

하지만 지구의 심각한 문제가 인류가 그동안 사용한 화석 연료로 인한 것이였다면, 현 위기를 벗어날 길은 소프트웨어의 극단적 사용이라고 생각합니다.

인류는 산업 혁명 이후 양적 성장과 크기의 확장에만 매달려 왔습니다. 더 많이, 그리고 더 빠르고, 더 높고, 더 무겁고, 더 크고 등 팽창 위주의 성장이였습니다.

아인슈타인의 진리적 이론인 E=MC^2 에 따르면 질량이 무거우면 에너지의 양이 크다, 즉 인류가 그동한 추구한 확장적 성장에 따라 계속 발전한다면 점점 사용하는 에너지의 양은 늘어나며, 지구의 파괴는 더욱 빨리 질 것입니다.

결국 우리는 지금까지의 관습을 모두 버리고 더욱 작고, 더욱 느리고, 더욱 가벼운 축소의 성장을 이루어야 지금의 위기에서 벗어 날 수 있을 것입니다.

축소의 성장에는 너무나 많은 난관이 있습니다. 크게 만드는 것 보다 작게 만드는 것은 너무나 많은 노력이 들어 갑니다. 또 한 물리적으로 사물을 축소한다는 것은 한계가 있습니다.

자동차를 생각해보십시오. 가끔 모토 쇼에 1인승 미래 자동차가 나옵니다. 실제 오토바이 크기 만큼 작은 차들이지요. 그럼 자동차를 그이상 작게 만들려면 가능할까요?

사람도 타야 하고, 엔지도 있어야 하고, 짐도 실어야 하니까 아마 힘들것 같습니다.

그럼 어떻게 탈것을 더욱 축소 시키면서 발전 시킬 수 있을까요?

여기서 우리는 확장적성장의 패러다임을 버려야 합니다. 자동차를 가볍고 작게 만들것이 아니라 자동차의 목적인 이동을 작고 가볍게 만들어야 한다는 생각을 해야 합니다.

불과 10년 사이에 홈쇼핑, 인터넷 쇼핑이 몇 백배 성장하며, 우리의 생활 양식마저 바꿔 놓고 있습니다.

모든게 It기술과 소프트웨어의 눈부신 발전 때문이지요. 그런데 그런점 생각해보셨습니까? 홈쇼핑과 인터넷 쇼핑 때문에 차량 운행량이 얼마나 줄었을까?

과거 홈쇼핑, 인터넷 쇼핑이 아예 없던 시절 우리는 물건을 사기 위해 시장이나, 백화점 등 물건을 판매하는 곳까지 직접 이동하여야 했습니다.

심지어 지역 특삼물이나, 특별한 물건을 사기 위해 몇십 몇백 킬로미터를 이동해야 할때도 있었습니다.

하지만 지금은 어떻습니까? 저의집에서 제주도의 옥돔을 구매할 수 있습니다.

얼마 전에는 수천 킬로미터가 떨어진 미국의 상점에서 책을 주문 했습니다.

만약 그 책을 사기 위해 비행기를 타고 차를 타고 직접 이동했다면 어마어마한 에너지를 사용하여 그 책을 구매한 것이 될 것입니다.

위에서 말한 아인슈타인의 E=MC^2의 법칙으로 생각 해보면 제가 몸무게가 90kg 정도나가고, 위 법칙에 적용받을 수 있는 속도로 이동한다면 에너지의 양은 음....상상을 초월 하는 (참고로 답을 구할 수 있는 분은 구해 보세요 공식은 : E = 90 kg * (3 * 10^8 m/s) ^2) 에너지 양이 나옵니다.

그럼 집에서 그 책을 인터넷을 통해 구매했다고 한다면, 실제 이동한 것은 저희 집에서 미국의 그 상점의 서버까지 연결된 라인을 통해 이동한 전자들 뿐 일 것입니다. 물론 초당 몇 MB 이상씩 이동을 시켜겠지만, 전자의 개당 무게는1 kg * (3 * 10^8 m/s) ^2 이 정도이니 아무리 수많은 전자를 이동시켜 이용했다고 하더라도 사용에너지의 양은 비교가 되지 않습니다.

물론 지금의 말은 검증된 것도 아니고 또 현실적이지도 않습니다. 단순히 아인슈타인의 E=MC^2 이라는 이론을 이용하여 극단적으로 이야기 한 것 뿐입니다.

하지만 우리는 소프트웨어를 사용하므로 기존에 비효율적이었고 낭비의 요소가 많았던 이동을 개선한 것은 사실입니다.

우리 주변에는 이런 것 뿐 아니라 소프트웨어를 이용하여 에너지를 훨씬 작게 사용하여 기존의 방식과 동일한 효과를 보는 일들이 많을 것입니다.

지구가 위기에 처해진 것은 분명한 사실 인 것 같습니다. 작년에 충격적이었던 엘고어의 “불편한 진실” 이라는 영화가 생각납니다.

우리에게 불편한 진실이지만, 진실은 진실 입니다. 인류 모두가 힘을 모아 지금의 위기를 슬기롭게 해결 해야 합니다.

여기에 소프트웨어 개발을 담당하고 있는 우리도 역시 동참하여 우리의 힘으로 지구를 구할 수 있는 길을 연구하고 고민하여 위기에 처한 지구를 구하는 일에 힘을 보태어야 할 것 입니다.

ㅋㅋ 200% 동감

우리는 DataBase에 대한 데이터 조회를 할때 보통 'MY','my'는 같은 결과 로 조회 된다는걸 알고 있습니다.
하지만 이런 방식의 데이터 다루기가 문제가 발생 한다는 것을 깨닭았습니다.
가령 애플리케이션 상의 사용자 ID가 있고 사용자를 ID를 통해 인증 한다고 하십다.
그런데 업체의 요구 사항이 대소문자가 틀리면 다른 사용자라고 간주 해달라고 했습니다.
C# 이나 C++등 애플리케이션 측의 구현에서는 전혀 문제 될게 없는 요구 사항입니다.
하지만 사용자의 ID가 User 테이블의 UserID 라는 PRIMARY KEY 로 설정 되어 있다면 애플리케이션에 심각한 문제 가 됩니다.
사용자는 'MY' UserID를 가지는 사용자를 등록 하고 그후 'my' UserID 를 가지는 사용자를 생성 할려고 할때 DB는 PRIMAry KEY 충돌로 예외를 발생 시킬 것 이기 때문입니다.
이 문제는 MS SQL DataBase 최초 설치시 설정한 문자셋(character set) 설정이 Korean_Wansung_CI_AS 설정 되었기 때문입니다.
여기서 Korean 은 한글을 나타내며, Wansung 는 정렬 규칙(완성형)을 타나냅니다.
CI 는 case-insensitive  의 약자로 즉 대소문(case)를 구분 하지 않겠다는 것 입니다.
AS 는 accent-insensitive 를 나타 내며 액센트를 구분 하지 않는다 뜻 입니다.(한글에서는 별 의미 없습니다.)
위와 같이 초기에 설치 한 문자셋이 대소문을 구분 하지 않는다는 것 이였고 이 결정은 설치시 모든 테이블과 컬럼에 적용이 됩니다.
SQL Server 7.0 까지만 해도 문자셋은 전체 DB에 영향을 끼쳤으며, 그로 인해 문자셋을 바꾸는 작업이 테이블이나 칼럼 단위로 지정 되지 못했으며, 변경 자체도 상당히 까다로웠습니다.
하지만 MS SQL 7.0 이후 부터는 문자셋 설정이 컬럼 단위로 설정 가능하도록 되었고 우리는 이기능을 사용하면
대소문 구분으로 인한 애플리케이션의 문제를 해결 할 수 있을것 입니다.

alter table [table_name] alter column [agent_id] varchar(16) collate Korean_Wansung_CS_AS

위와 같은 Alter Table 문으로 해당 컬럼에 대한 문자셋 을 변경 할 수 있으며 위의 문자셋은 해당 컬럼에 대해 CS(case-sensitive)를 활성화 함으로 MY 와 my 는 개별적 데이터 로 생성 될 수 있습니다.
물론 조회 시도 MY 와 my는 완전히 틀린 데이터로 취급이 되기 때문에 변경후 해당 컬럼의 사용에 대한 각별한 주의 가 필요 합니다.

아래 내용은 KLDP 에서 몇 해 전 사용자 스토리에 대한 개발자 분께서 남겼던 질문에 대한 대답을 한번 해 본 것 입니다.

Q: 지금 사용자 스토리를 읽고 있습니다. 몇 년 전에 XP를 읽고 느꼈던 감동이 다시 오더군요. 그때도 지금도 고민되는 문제점이 있습니다. 제가 XP를 처음 접할 때 저는 벤처기업에 있었고 개발이 상당히 어렵게 진행되고 있었습니다. 대표적으로 회사가 상하로 나누어져 위에서는 개발자를 재촉하고 개발자는 수동적으로 따라가는 구조였습니다. 저는 그때 개발팀을 이끌고 있었고, 그래서 그런 현실이 안타까웠습니다. XP를 읽고 한번에는 안되겠지만 점차 적용을 해야겠다고 생각하고 개발자들과 회의 시간에 XP를 알렸습니다. 그런데 그때의 개발팀의 멤버는 아주 비관적인 말을 했지만 저도 답변을 할 수가 없었고, 지금도 마찬가지 입니다.

"스토리를 만드는 것이 일을 크게 하는 것이 아닌가?. 주어진 데로 하는 것도 쉽지 않은데 스토리를 작성해서 일이 커질 경우 개발 비용을 고스란히 개발팀이 떠 안아야 한다."

이렇게 요약을 할 수 있는데요. 이 부분에 대해서 어떻게 생각하시는 지요? 예를 들면 지금 제가 개발 업체를 다니고 있고, 이번에 우리 회사가 카드회사의 새로운 프로젝트를 맡았다고 할 경우에, 이미 제안서와 요구사항에 의한 비용산출이 끝난 이후 개발팀이 투입이 될 것입니다. 개발팀의 팀장은 XP를 이용하고자 했습니다. 카드회사의 새로운 프로젝트를 사용하는 사용자를 만나 미팅을 해서 프로젝트를 좀더 효과적으로 성공시킬 수 있는 아이디어를 도출할 수 있었습니다. 새롭게 도출된 결과는 카드 회사입장에서 상당히 장점이 있는 것으로 카드 회사는 제가 다니는 회사와 협의를 하게 될 것입니다.

이때 제가 다니는 회사에서 "왜 긁어 부스럼을 만들 어냐?"라는 말이 나올 수 있습니다. 많은 경우 아이디어는 일을 크게 하는 경우를 많이 봤습니다. 이런 경우에, 반복 주기에 고객의 의견을 반영함으로써 프로젝트의 완성도는 좋아지지만 점차 발생하게 되는 비용의 문제는 어떻게 해결해야 하는지요? 외국의 경우, 반복 주기마다 계약된 금액이 변경될 수 있나요?. 또는 국내 프로젝트에서는 어떤가요? 계약사항이 있는데도 "갑"이라는 이유로 요구사항을 변경하는 경우도 비일비재한데, 개발팀이 스토리 확장 및 변경에 관한 비용 문제를 어떻게 이겨내야 할까요?

 

A : 제 경험과 생각으로는 어차피 XP 나 기타 다른 Agile Process 가 아닌 전통 적인 개발 방법론을 사용하더라도 사용자의 기대 수준과 기획 시 계획의 차이는 해결해야 할 문제 인 것 같습니다. 프로젝트의 계약 시 보통 아주 세부적인 사항까지 계약하지는 않습니다. 개발 되는 시스템의 목적과 용도 에 입각해서 세부 사항은 숨기고 고객의 필요한 요구사항을 충족 시킬 것이라는 계약만 이루어 질 뿐입니다. 가령 계약이 기존의 이미 존재하는 시스템을 도입하여 프로그램의 세부 적인 구성을 고려하여 계약 되게 되더라도 실제 개발에서의 고객 요구 사항은 계약 내용과 상이한 점이 존재 할 수 밖에 없습니다. 그렇다고 고객의 요구를 무시하고 계약 되로 개발 할 수는 없죠? 그래서 소프트웨어 프로젝트의 개발 동안 PM 들은 계속 고객과 회사 등 프로젝트 전반에 걸쳐 이해관계가 있는 곳과 조율과 이해를 구하게 되는데 전통적인 개발 방식에서는 이 능력은 전적으로 PM의 역량에 의존하는 경향이 입니다(술로 해결하는 사람들도 많죠ㅡㅡ;;).

하지만 XP 프로세스에서는 계약과 현실의 차이를 고객이 조율하게 함으로 그 과정에 발생 할 수 있는 오해와 갈등을 이해와 화해의 수준으로 해결 하고 있습니다.
고객은 프로젝트 자원을 더 널리지 않고 범위를 가지고 변경된 요구사항을 조정하게 되며, 고객의 요구사항이 변화게 되더라도 결국 개발사의 전체적 비용은 초과 되지 않습니다. 즉 다시 계약 할 필요가 없죠(정말 이거 행복 합니다. 고객에게 추가 계약 이야기 하기는 정말 싫습니다.ㅜㅜ)
여기서 가장 중요한 것은 XP의 프로세스에서는 고객에게 가장 가치가 있는 스토리가 먼저 구현되고 프로젝트 전반에 걸쳐 다듬어 지며, 프로젝트가 완료되기 전 빠른 시간에 고객의 손에 넘어 간다는 것 입니다. 범위의 조정으로 계약 예산의 뒤쪽에 있는 즉 지정된 예산안에 처리가 되지 못하는 스토리들은 고객에게 상대적으로 먼저 수행되고 개발된 스토리보다 덜 중요한 스토리 이며, 개발사가 전체 스토리를 모두 구현하지 못하더라도 최소한의 계약 사항에 명시된 고객에게 제공해야 할 가치는 성공할 수 있는 것입니다.
전체를 망치겠습니까? 우리가 할 수 있는 중요한 몇 개라도 잘 하시겠습니까?ㅎㅎ

sumer 왈 : 그런데 여기서 한가지 문제가 더있을 수 있습니다. 고객의 고집 입니다. 결국 사용자 스토리를 이용한 XP 개발 방법에서는 고객의 이해와 협조 를 요구 하게 되는데요 PM 또는 대고객 업무를 당담하고 있는 책임자가 고객과의 관계 또는 고객의 이해를 끌어 내지 못 했을 경우 아주 심각한 위기에 쳐 하게 됩니다.
실제 이번에 6개월 정도 진행한 이랜드 시스템즈의 소극장 예매 시스템의 경우 고객의 이해를 받지 못 했습니다.
고객은 모든 자신들의 요청이 반영되기를 원했고 시간도 엄수하기를 원했습니다. 그리고 비용 추가도 거부 했죠
결국 계획은 무산 되고 계약도 슬그머니 숨어 버렸으며, 개발자는 개발 중반에 계약기간 완료로 프로젝트에서 빠져버리는 무시무시 한 상항이 왔습니다.
솔직이 저 를 포함한 프로젝트 팀(고개도 포함 입니다.^^) 엄청난 마음의 고생을 했고 서로의 갈등이 많이 깊어 졌습니다.
왜 이런 일이 일어 났을까 ? 생각 해보면 이유는 단 하나 였습니다. 당시 PM은 고객 쪽에 끌려 다니고 있었습니다.
결국 개발쪽의 일정 위험 신호나 요구사항에 대한 타협 의견 등은 모두 무시 되었고, PM은 단 한마디로 그런 위험 사항을 정리 해벼렸죠! '밤새워서 라도 다 해주세요!'
그 한마디에 개발자들의 사기는 물론 개발 프로세스를 적용할 수 조차 없는 그냥 개발자들에게 늦은 퇴근 강요하고 달래고 주말 근무 요청하고 뭐 이런 씩으로 프로젝트 관리가 변질 되어 버렸습니다.
절대 PM 이나 프로젝트에 대한 관리를 책임 지시는 분은 저런 실 수를 하지 않기 바랍니다.

행복한 하루 되세요!

앞전에 글에서 닷넷의 형에 대해서 간략히 이야기 해보고 더 진행 한다고 했는데 아직 못하고 있네요 ㅡㅡ
이러니 블로거가 활성화 되지 않는 것 같습니다.
잛은시간에 강의에 맞먹는 글을 쓰기는 힘들 것 같고 또한 일방적인 전달 방식의 지식은 별로 유용하지 못 할 것 같아. 오늘은 그냥 같이 고민해 보아야 할 문제에 대해서 여러분의 의견을 듣고 싶습니다.
객체 지향 언어 에서는 모든 문제는 선택의 문제만 있고 딱이 이거다라는 답이 없습니다.
물론 프로그램을 처음 하시는 분이나 선택 차체가 어려운 분은 다른 사람의 지식을 모방하는 수준에서 프로그램을 하겠지만 이것 또한 잘못 된건 아니라고 생각 합니다.
다만 모방과 카피를 통해 프로그램을 하더라도 기본적인 문제에 대한 고민은 같이 해봐야 할 것 같습니다.
다시 한번 말씀드리지만 정답은 없습니다. 다만 자신의 생각과 논리에 의거한 선택이 있을 뿐입니다. 가벼운 마음으로 오늘의 문제인 변수에 대해서 자유롭게 말씀해주세요

문. 로컬 변수와 필드 변수 를 어떻게 사용하십니까?

* 질문이 막연 합니다 ^^ 우리가 클래스를 구성 할때 특정 상태나 데이터의 전달을 위해서 변수를 사용합니다. 객체지향의 클래스에서 사용하는 변수는 특성상 로컬 변수와 클래스 필드로 나눌 수 있습니다.
그럼 여러분은 과연 어떻게 로컬 변수 와 클래스 필드의 사용을 결정 하십니까?

모두에게 행운이

VS2005 SP1의 설치 옵션으로 시간은 단축 했지만
이번에는 디지털 서명 확인 오류가 발생했다.
물론 위 내용은 설치 옵션 사용에서 밝혀 뜻이 설치 옵션으로 설치시 아무런 메시지 없이 설치가 되지 않아 정상적인 방법으로(무려 2시간) 설치 과정에서 나온것이다.(삽질 이였다. quiet 모드로 설치 해도 로그 파일은 지정한 장소에 남는다 해당 로그에서 오류가 발생했는지 확인하면된다.)

각 설 하고 위 내용은 http://support.microsoft.com/kb/925336/ko 에 문서화 되어 있다.
참 어이가 없는게 원인이 MSI 패키지나 MSP 패키지의 서명 정보를 확인 하는데 필요한 연속의 가상 메모리 공간이 부족해서 나온다고 한다.
이런! VM 에 1.5G 를 활당 했는데도 메모리 공간이 부족하다?
그럼 메모리를 더 줘야 하나?
결코 그런유의 버그가 아니다. 위 링크의 문서 맨 아래 쪽에  참고 에 보면 컴퓨터에 RAM을 더 추가해도 문제가 해결 되지 않는다는 문구 ㅡㅡ;
쓰발 Windows Installer 의 서명 확인 알고리즘에 문제가 있는것이다.

위 문서에서는 3가지의 해결 방법을 제시 하고 있는데 첫번째가 핫 픽스(KB925336) 적용이다. 핫픽스는 2003 용으로 으로 만 있기 때문에 XP 등에서 적용이 불가능 하다. 또한  문서 상에도 핫 픽스를 신뢰 하지 못하는 느낌이 강하게 온다.('특정 문제가 발생하는 시스템에만 핫픽스를 적용해야 합니다.')
그래서 이방법은 패스

두번째 방법은 NT 계열 OS에 모두 적용할 수 있는 방법으로 Register 수정 방법을 제시 하고 있다. HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers
에 PolicyScope 의 값을 1로 변경하고, msiserver 를  서비스를 죽인다.
그런데 위 방법으로도 해결이 안될수 있다는 문구 가 있다.
당연이 misserver 서비스를 죽여 버리니 해당 서비스에 종속적인 패키지는 설치 되지 않겠지 ㅡㅡ 또 성공후에는 수정한 레지스트리 키와 서비스를 다시 원상 복구 해야 한다.
귀찮고 성공할지도 모르고 그래서 이방법도 패스

이제 이문제를 해결 할수 있는 방법은 단 하나 남았다.
먼저 관리 도구에서 로컬 보안 정책으로 가 소프트웨어 제한 정책을 만들고 개체유형에서 강요를 선택한다.
로컬 관리자를 제외한 모든 사용자를 선택 해서 확인하고 재부팅후 설치 한다.

물론 로컬 보안 정책은 도메인 환경 등 때문에 불가능 할 수도 있지만 그럴때는 SA 와 의논한 후 해당 방법을 적용한다.

설치후는 변경내용을 원상 복귀 하기 바란다.

VS 2005 Sp1 설치하는 과정이 너무 오래 걸린다.
마소에서는 전혀 이 문제에 대한 해결책을 제시할 의사가 없는게 분명하고
그렇다고 설치 시 마다 스트레스 받아가며 돌아버릴 것 같은 몇시간을 보내기 싫어서
다른 방법을 찾아보니 명령창에서 다음 속성을 이용하여 설치파일을 실행하면 30분 이내에 끝난다.^^ 주여 감사합니다.
다만 진행 로그나 오류 등은 나오지 않으니 설치후 VS2005  정보에서 RTM 이 아닌  SP 버전이 적용되었는지 확인 해야 할 것이다.

start /wait VS80sp1-KB926605-X86-KOR.exe /quiet /L*v+ VS80sp1-KB926605-X86-KOR.log

*위 와 같이 quiet 모드로 설치를 해도 로그 정보는 기록 됩니다.
다만 ??.log 의 위치를 해당 설치 파일과 틀린 디스크에 저장 하시면 실행 속도를 높일 수 있습니다.
설치 후 log 의 마지막 라인에 '설치가 잘 끝났습니다' 라는 메시지가 있으면 정상적으로 설치 가 완료 된 것 입니다.

앞전 boxing 과 upboxing에서 값 형식 과 참조 형식에 대한 언급이 있었습니다.

그럼 값 형식과 참조 형식이란 무엇 일까요?

닷넷 프레임워크에서 형식이 무엇 인지 알기 위해 먼저 닷넷 프레임워크의 형식의 모든 것인 Common Type System(이하 CTS) 을 살펴 봐야 합니다..

CTS 란 런타임에서 형식을 선언하고 사용 및 관리하는 방법을 정의할 뿐 아니라 언어 간 통합에 대한 런타임 지원의 중요한 부분을 차지 합니다.

위 내용은 msdn 의 CTS 의 개요 내용입니다.

Boxing , unboxing 또한 CTS에서 제공하는 기능입니다.

CTS 의 가장 중요한 역할은 실제 애플리케이션이 실행 할 때 애플리케이션의 형식(type)의 사용과 관리를 하는 것 입니다.

형식(type)이란 런타임시 메모리 공간에 탑재될 데이터의 형태를 말 합니다.

가령 int 형의 변수를 선언하여 실제 구동하게 되면, 런타임에서는 선언된 int을 사용하기 위해 CTS가  OS에게 메모리 상에 32bit 크기의 공간을 요청 하게 됩니다.

그렇게 OS에게 요청 된 것은 OS의 알고리즘에 따라 추상적인 메모리공간이 활당 되게 되며 활당된 메모리 공간에 데이터를 바인딩 하게 됩니다.

또한 메모리상의 바인딩 데이터를 사용할때도 CTS 는 적당한 방법으로 데이터를 해석하여 사용가능하도록 합니다.

부동소수점 형태의 경우 32bit 크기의 메모리공간을 요청하지만 사용방법은 int 형과 완전이 틀립니다. Int 의 경우 32bit 전체 공간에 정수를 저장 하지만 부동소수점 형 은 32bit 공간중 일부 구간을 소수점 이하 자리를 위한 공간으로 사용하게 됩니다.

소수점 이하 몇자리 까지 사용할 건지에 따라 정밀도라 부르며, 닷넷에서 지원하는 부동 소수점 형태는 msdn 을 참조 하면 정확하게 확인 할수 있다.

이처럼 CTS는 메모리의 사용과 관리에 관한 일을 주 임무로 하고 있습니다.
그리고 CTS는 형 안정성을 추구 하기도 합니다. 형 안정성은 형의 사용에 있어서 문제가 발생 할 수 있는 코들를 컴파일러 에서 확인 가능하도록 하며, 최악의 경우에도 런타임시 예외나 오류의 발생으로 혹시 있을지 모를 데이터의 손상을 막아 주는 기능 입니다.

모든 소프트웨어 컴파일러 및 개발 언어들은 자체의 Type System을 제공 하고 있으며, 각 형태는 언어 마다 특이 점들이 많습니다.

루비 같은 경우 모든 타입을 참조형으로 보며, 타입들의 변환이 매우 자유로운 환경을 제공 하고, 자바 스크립트 같은 경우 형의 선언 없이 사용가능한 방법을 제공 하기 도 합니다.

닷넷 이전까지의 Type System 은 프로그램 언어의 컴파일러 기능으로 각 언어별 정수를 나타내는 int 형이라고 할지라도 그 사용 방법이나 관리 방법의 차이로 호환이 불가능 했습니다.

하지만 닷넷 에서는 Type System을 프레임워크의 기능으로 탑재 하여 각 닷넷을 지원하는 언어들이 아무런 문제없이 서로의 데이터 형을 이용 가능 하도록 하였습니다.

그래서 앞에 Common이 붙은 거겠죠.

이렇게 CTS가 사용 및 관리한는 형은 크게 값 형과(value Type) 과 참조 형(Reference Type) 으로 분류 할 수 있습니다.

대충 CTS가 무엇인지 설명 드렸습니다만 Type System에 관련된 내용은 컴파일러 및 OS와 프로그램의 런타임과도 많은 관련이 있어 자세히 설명 하지 않았습니다.(사실 설명하기에는 아직 제 지식이 …) 그럼 다음 시간에 CTS의 값 형식에 대해서 알아 보겠습니다.

모두에게 행운이 있기를…