[Web] RedKei.com 오픈~!!!

WebDB - 아시안웹DB정보사이트 레드케이 - RedKei.com

http://www.redkei.com/



크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/08/18 19:57 2009/08/18 19:57
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/4544

http://www.textyle.kr/





크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/07/30 09:40 2009/07/30 09:40
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/4495

[칼럼]보이는 UI, 보이지 않는 UX

얼마 전 국내 IT기업들이 사상 최대의 흑자라는 실적 발표가 나왔다. IT기업들의 제품들은 반도체, 휴대폰 등 정보통신 기기들이다. 우리나라는 눈에 보이는 기계는 세계적으로도 손색이 없을 만큼 잘 만든다. 하지만 그 기계들 안에서 작동하는 눈에 보이지 않는 SW는 세계적인 것으로 꼽을 만한 것이 별로 없다.



세계적인 게임기 닌텐도의 성공이 SW보다는 HW만 잘 만들면 된다고 믿는 사람들이 많다는 것이 씁쓸함을 더한다. 뿐만 아니라 애플 아이폰의 경쟁력을 오만가지의 SW의 다양성으로 비교하지 않고 하드웨어 스펙만으로 비교하는 것을 보면 우리나라 기업은 눈에 보이지 않는 가치보다는 눈에 보이는 것만 바라보는 수준에 머무른 기업들이 많다.



■ 보이는 UI 보이지 않는 UX

SW처럼 눈에 보이는 HW에 가려서 보이지 않는 것이 있다면 UI에 가려진 UX라고 할 수 있다. 그래서 UX를 다루는 사람들이 가장 경계해야 하는 것은 눈에 보이는 것만 디자인하려고 하고 인정하려는 자세다. 제목에 이미 나타나 있듯이 UI는 눈에 보이는 실체이지만 UX는 눈에 보이지 않는 것이기 때문이다. 다만 UX는 UI 디자인이라는 것으로 실체화되어 일부가 눈에 보일 뿐이다. UX의 실체가 무엇이길래 눈에 보이지 않는단 말인가?



■ 러브액츄얼리식 프로포즈가 먹혔던 이유

필자의 예전 컬럼에서 ‘UX는 러브액츄얼리식 프로포즈’라고 했다. 영화에서 그러한 프로포즈가 먹힌 이유가 무엇일까? 그 남자가 잘생겨서? 돈이 많아서? 아니면 스케치북 그림을 잘 그려서? 핵심은 프로포즈하는 ‘과정’에 있다.



진실한 자세로 그 여자의 마음에 한발한발 다가간 것이 그녀의 마음의 문을 열리게 한 것이다. UX는 프로포즈와 같은 과정이다. 스케치북과 같은 아이템은 UX를 실체화하는 과정에서 사용한 디자인적 도구일 뿐이다.



■ UX의 대상

UI는 보이는 것을 디자인하지만 UX는 보이지 않는 것도 디자인한다. UX는 어쩌면 보이지 않는 부분이 빙산처럼 더 클 수도 있다. 그래서 UX의 대상은 대체로 다음과 같이 정리해볼 수 있다.



1) Interaction: 사용자와 시스템 간의 상호 작용



2) Communication: 사용자와 시스템간의 소통 경로



3) Process: 작업 절차



4) Response: 사용자 조작에 대한 시스템의 메시지, 경고, 알림



5) Method : 인터페이스에 대한 사용 방법
- 출처: 2009.7, 제2회 한국SW아키텍트대회, UX의 X인터넷 적용 발표 中, 옥상훈



따라서 그러한 보이지 않는 것들로부터 것들을 UX를 실체화하기 위해서는 사용자의 행동을 많이 관찰해야 하고 여기서 최적화된 패턴을 도출해내는 작업이 필요하다.



예를 들면 수도꼭지 하나라도 물을 나오게 하는 방법, 물의 양을 조절하는 절차, 물의 온도에 따른 적절한 경고 메시지 등의 다양한 고려사항들이 존재한다. 이러한 것들이 수도꼭지와 관련된 UX의 인터렉션, 커뮤니케이션, 프로세스, 리스판스, 메쏘드에 해당한다.



■ 올바른 과정에서 올바른 결과가 나온다

‘방망이 깎는 노인’에서 보았듯이 충분한 시간을 두고 올바른 과정을 거쳐야 제대로 쓸만한 방망이가 나온다. 설렁탕 국물도 10분 동안 전자레인지에 데워 나온 것과 10시간 넘게 푹 끓여서 나온 국물 맛은 말할 것도 없다.



어떤 일이든 과정을 무시하면 그 무시한 것들이 어떻게든 잘못된 결과로 나타나게 되어있다. 급하다고 해서 과정을 무시하고 결과가 중요하다고 해서 과정은 아무렇게나 해도 된다는 생각을 가진 사람에게는 UX는 보이지 않는 허상일 뿐이다.



■ UX는 식스센스

영어 속담 중에 ‘Seeing is Believing’이란 말이 있다. 하지만 UX에서는 이러한 속담은 다음과 같이 고쳐야 맞을 것 같다. ‘Seeing invisible is creative’ 즉 보이지 않는 것을 보는 것은 창조적인 것이다. 영화 식스센스처럼 세상은 보이지 않는 곳에서 보이지 않는 것들간의 인터렉션으로 만들어지는 현상들이 얼마든지 있다.



UX도 단순히 눈에 보이는 아름다운 디자인이라고 간주하는 사람들에게는 시각적인 것에 즐거움에 불과하지만 보이지 않는 인터렉션을 발견하려고 하면 UX를 보는 새로운 식스센스가 움트기 시작할 것이다. 그리고 이 식스센스는 비즈니스적 가치를 발굴해내는 탐지기로 작용할 것이다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/07/29 14:04 2009/07/29 14:04
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/4491

핵심 함수, 선택, 결과 탐색

http://www.ibm.com/developerworks/kr/library/wa-jquery1/index.html

jQuery는 동적 RIA(Rich Internet Application)를 쉽게 만들기 위해 개발자가 고려하는 자바스크립트 라이브러리로 뜨고 있습니다. 브라우저 기반 응용은 데스크톱 응용을 계속해서 대체하고 있기에, 이런 라이브러리는 계속해서 활용 범위가 넓어질 것입니다. jQuery 연재물을 통해 jQuery 관련 지식을 얻고 웹 응용 프로젝트에 활용하는 방법을 익혀봅시다.

도입

jQuery는 웹 개발자를 위한 라이브러리 선택 과정에서 다른 자바스크립트 라이브러리 옵션과 간격을 벌리기 시작했으며, 클라이언트 쪽 개발을 쉽게 도와주며 RIA를 빠르고 효과적으로 만드는 방법을 찾고 있는 프로그래머의 관심을 한몸에 받고 있다. RIA 활용이 점점 더 세상에 널리 퍼짐에 따라, 개발을 돕기 위한 자바스크립트 라이브러리 활용도 함께 늘어날 것이다. RIA는 데스크톱에서 동작하는 응용과 비슷한 효과를 얻기 위해 CSS/자바스크립트/Ajax를 조합해 브라우저를 통해 동작하는 응용으로 (대충) 정의할 수 있다. 파이어폭스, IE, 사파리, 구글이 최근 선보인 새로운 크롬 브라우저에 추가된 최신 기능은 브라우저 내부 자바스크립트 엔진 속력을 높이는 데 초점을 맞추고 있다. 이렇게 하는 가장 중요한 이유는 브라우저 제조사가 우리에게 머지 않은 장래에 등장할 좀 더 매혹적인 RIA 보급을 장려하기 위해서다. 브라우저 회사들은 수만 행에 이르는 자바스크립트 코드를 포함하는 웹 페이지를 마음 속에 그리고 있으며, 시작부터 숙성되고 버그가 없는 라이브러리의 중요성을 강조한다.

따라서 웹 응용의 미래가 사람들을 몰두하게 만드는 풍부한 인터페이스로 이동함에 따라 웹 개발자는 점점 더 이런 작업을 쉽게 도와주는 도구로 방향을 바꾸고 있다. 지금 바로 사용할 수 있는 자바스크립트 라이브러리가 시중에 나와 있으며, 각각은 나름대로 장단점은 물론이고 열성파와 반대파도 있다. 기능 측면에서 우월성을 따지지 않는 이유는 궁극적으로 그다지 중요한 문제가 아니기 때문이다. 궁극적으로 어떤 라이브러리가 양으로 승부를 걸어 인기가 더 많은지를 고려해야 한다. 네 가지 가장 인기 있는 자바스크립트 라이브러리를 구글 트렌드 그래프로 살펴본 모습은 다음과 같다. 과거 6~8개월 동안에 jQuery가 자바스크립트 라이브러리 중에서 가장 인기를 끌고 있으며, 가파르게 성장중이다.


그림 1. 인기있는 자바스크립트 라이브러리를 구글 트렌
드로 추적한 결과



구인 시장에도 자바스크립트 라이브러리로 jQuery가 뜨고 있음을 확인할 수 있다. 경력 관리 네트워크인 Monster.com을 대충 살펴봐도 "jQuery" 관련 일자리가 113개가 나오는 반면에 YUI는 67개, ExtJS는 19개, mootools는 13개만 나온다.

jQuery 연재물 중 첫 번째 기사는 jQuery 문법, 설정 방법, 함수 호출 방법부터 살펴본다. 이 기사 후반부에는 라이브러리에 들어있는 핵심 함수를 탐험하고 DOM 탐색을 쉽고 직관적으로 가능하게 만드는 강력한 선택자와 필터 활용법을 탐험한다. 나중에 나오는 기사에서는 CSS 처리, 폼 제어, 텍스트 변경, Ajax 단순화, (모든 사람의 눈을 즐겁게 만들어주는) 애니메이션을 소개한다. jQuery에서 가장 흥미로운 기능은 플러그인 아키텍처로, 개발자가 jQuery 기능을 추가하도록 도와준다. 마지막 기사에서는 RIA 개발 과정을 완료하기 위해 활용 가능한 강력한 플러그인 몇 가지를 소개한다.

이 연재물은 자바스크립트 문법, CSS 문법, DOM 문법을 미리 알고 있는 독자를 염두에 둔다. 연재물을 읽기 전에 각각에 대한 문법을 다시 한번 기억할 필요가 있다면, 이 기사 참고자료 절에 실어 놓은 W3Schools를 강력하게 추천한다.




jQuery로 작업하기, Part 1: 브라우저로 데스크톱 응용 옮기기

jQuery로 작업하기, Part 1: 매개체로서의 JQuery: 플러그인을 사용하여 jQuery 함수를 작성하고 확장하기

jQuery로 작업하기, Part 2: 내일 나올 웹 응용을 오늘 구현해보자(사건, 속성, CSS)

jQuery로 작업하기, Part 2: 매개체로서의 JQuery: UI 프로젝트

jQuery로 작업하기, 3부: jQuery와 Ajax로 RIA 만들기: JQuery: 내일 나올 웹 응용을 오늘 구현해보자 Effects(모듈과 Ajax)

jQuery UI 라이브러리에서 지금까지 설명한 모든 위젯과 효과를 다운로드할 수 있다.

jQuery UI Demo 페이지에서 실제로 구현된 모든 위젯을 볼 수 있다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/07/20 15:48 2009/07/20 15:48
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/4463

[칼럼]SaaS, 대세론이 되기위한 조건
박재현 IT칼럼니스트 jaehyunpark.kr@gmail.com
2009.07.15 / PM 02:57SaaS, 클라우드 컴퓨팅

[지디넷코리아]SaaS(Software As A Service)는 오프라인을 통해 라이선스 단위로 거래되던 기존 소프트웨어 비즈니스 모델과 달리 온라인을 통해 소프트웨어를 이용하고 사용한 만큼 비용을 지불(Pay as you go)하는 모델이다.



이용자들 입장에서 SaaS는 인트라넷과 IT 시스템을 구축하는데 따른 위험을 줄일 수 있다. 관리 걱정 없이 언제 어디서나 해당 서비스에 접속하여 업무를 수행할 수도 있다. 딴데 신경쓰지 않고 핵심 사업과 업무에 만 집중하면 되는 것이다. 초기 투자 비용을 줄일 수 있으며 사용한 만큼 지불하면 되기 때문에 투자 대비 효과(ROI, Return Of Investment)가 높다는 것도 SaaS의 장점이다.

고객 입장 뿐만 아니라 업체 입장에서도 SaaS는 매력적이다. SaaS 업체는 안정적으로 예측가능한 고정 수익을 확보할 수 있을 뿐만 아니라 항상 고객과 함께 하기 때문에 적기에 시장에서 원하는 서비스나 기능을 추가할 수 있다. 개발과 지원, 판매와 마케팅 비용도 기존 소프트웨어 비즈니스 모델에 비해 저렴하다.



하드웨어 성능 증가와 가격 하락, 네트워크의 급속한 보급 등에 따른 클라우드 컴퓨팅 기술의 발전은 지금껏 SaaS의 미래를 장밋빛으로 예측하는데 부족함이 없었다. 실제 2003년 가장 최초로 SaaS라는 용어를 사용했던 가트너를 비롯해 여러 시장 예측 기관들은 앞다투어 SaaS 의 성공을 예견했었다.



그러나 현실은 순탄치만은 아닌 것 같다.



작년 12월 가트너가 미국과 영국에 있는 기업 333개를 대상으로 하여 조사해 이번에 발표한 'SaaS 사용 현황과 전망 보고서'에 따르면 향후 2년간 조사 대상 333개 기업중 58%가 현수준을 유지, 32%가 확장하겠다고 했으며 5%가 축소, 5%는 중단하겠다고 한다. 서비스를 확장하겠다는 기업보다 유지하겠다는 기업이 많다는 것은 현재 제공되는 SaaS 서비스에 문제가 있다는 것을 의미한다.



실제 가트너 보고서에 따르면 이러한 원인이 예상보다 높은 비용(42%), 그리고 기존 레거시 애플리케이션과 통합의 어려움(38%), 기술적 요구를 만족시키지 못함(33%) 등 사용자 만족도 측면에 있다고 분석했다.



또 SaaS 도입시 기업이 가장 중요시 여기는 점은 기술적 요구 사항 지원(46%), 보안(33%) 그리고 통합 용이성(29%), 사업부의 요구 사항 지원(29%)순으로 조사되었다.



지금껏 SaaS 업계는 비용적인 측면에서 SaaS가 기존 방식보다 저렴하며 , OpenAPI와 통합 플랫폼을 통해 기존 애플리케이션과 쉽게 통합할 수 있다고 주장해 왔다. 또 간단한 설정과 개방된 개발 환경을 통해 사용자가 원하는 요구 사항을 손쉽게 반영할 수 있다고 강조해왔다.



가트너 보고서에 따르면 이러한 SaaS업계의 주장이 현실과 괴리가 있음을 알 수 있다. 과연 이러한 문제를 어떻게 해석하고 해결해야 할까.



먼저 , 비용측면에서 SaaS 업체는 서비스 총소유비용(TCO,Total Cost of Owbership)을 줄여야 한다. 실제 소프트웨어 1종을 구매하면 해당 라이선스 구매 비용, 관리 비용, 업그레이드 비용, 기술 지원 비용, 유지보수 비용 등 전체 TCO는 구매 비용의 3~4배 정도가 된다고 알려져 있다. 이에 비해 SaaS는 라이선스 구매 없이 사용한 만큼 비용을 지불하면 될 뿐 관리,업그레이드,기술지원 등의 부가 비용 지불은 발생하지 않는 것이 정상적이다.



그러나 실제 현실은 그렇치 않은 것 같다. 많은 SaaS 업체들은 컨설팅 비용 등의 명목으로 고가의 비용을 요구하는 것으로 알려져 있다. 이러한 비용을 줄이거나 없애야 한다. 이를 통해 고객에게 직접적인 비용 절감 효과를 제공해야 한다.



기술적으로 고객의 레거시 애플리케이션과 통합할 수 있는 현실적인 방안도 제공해야 한다. 기업이 보유하고 있는 많은 레거시 애플리케이션은 보통 비표준 API를 사용한다. 이러한 애플리케이션을 SaaS 서비스에 보다 손쉽게 연결할 방법을 제공해야 한다. 단순히 SOAP과 Rest 방식의 OpenAPI 를 제공하는 것만으로는 통합이 어렵다.



과거 대용량 메일 발송 SaaS 서비스를 이용한 적이 있었다. 이 서비스를 이용하기 위해서는 고객 DB를 연계해야 만 했는데 가능한 방법이 2가지였다. 하나는 배치 방법으로 스프레드시트에 고객 파일을 넣어서 FTP로 보내는 방법이었고 다른 하나는 고객 DB를 열어 주는 것 이었다. 별 수 없이 고객 DB를 열어 줄 수 없어 배치 방법을 사용했지만 정말 황당한 상황에 끔찍한 결정이었다.



만약 이런 경우 해당 업체가 레거시 시스템을 연동하기 위한 서비스 연계 모듈을 제공했다면 쉽게 해결 할 수 있었을 것이다. 이 연계 모듈을 고객 방화벽내에 설치한 후 레거시 DB 시스템을 연계하고 아웃바운드 보안 연결을 통해 고객 정보를 전달할 수 있다. 특히, 해당 고객 정보를 별도로 저장하지 않고 바로 활용한 후 삭제함으써 보안성을 높일 수 도 있다. 이렇듯 고객의 현실에 기반한 해결 방안을 제공해야 한다.



빌링 SaaS 서비스 업체인 OpSource는 바로 이러한 방법을 사용하여 레거시 응용 시스템을 빌링 서비스와 연계한다. Opsource는 고객에게 에이전트 SW를 제공한다. 이 에이전트 SW는 고객 방화벽 내에 위치하면 레거시 시스템으로 부터 고객 정보와 고객의 사용 정보 등을 안전하게 빌링 서비스에 제공하여 빌링 요청을 처리한다. 이처럼 기존의 레거시 애플리케이션을 효율적으로 통합할 창의적인 방법을 제공해야 한다.



SaaS 입장에서 고객의 기술적 요구를 만족시키지 못한다는 것은 동전의 양면일 수 밖에 없다. SaaS는 규모의 경제가 달성됐을 때 성공한다. 다시 말해, 고객이 어느 정도 수준에 도달했을 때 수익을 내며 그 임계치를 넘는 순간 수익율은 가파르게 증가한다.



그러나 증가하는 고객에 비례해서 증가하는 고객의 기술적 요구 사항에 따라 시스템에 손을 댈 수 도 없다. 개별 요청에 따라 시스템에 손을 대는 순간 일관되게 서비스를 개발하느 것이 어려워진다. 마치 과거 SI에 기반한 솔루션 구축 사업과 별 차이가 없어진다.



현재 SaaS에서는 이러한 고객 요구 사항을 수용할 방법으로 사용자가 원하는 데이터 필드를 서비스에 추가하여 자신이 원하는 서비스를 구성할 수 있게 해주는 메타 데이터 기술을 제공한다. CRM 업체인 Salesforce와 Netsuite 같은 업체들은 자신의 SaaS 서비스와 데이터를 기반으로 한 개발 플랫폼을 제공하기도 한다.



그러나 이러한 방법은 자신의 플랫폼을 중심으로 애플리케이션을 개발하는 것이지 고객의 SaaS 서비스 자체에 대한 기술적 요구사항을 수용하기 위한 방법은 아니다. 그러나 긍정적인 면에서 이러한 고객의 기술적,기능적 요구 사항을 수용하는 과정은 SaaS 서비스를 강화하는 데 있어 큰 밑거름이 될 것이다.



실제, 이 달 7월 12일 베타 꼬리표를 뗀 구글 앱스는 2년 동안 175만 개의 기업이 사용하는 과정에서 많은 시행착오를 겪었다. 이 과정에서 구글앱스는 중소기업 뿐 만 아니라 대기업에서 구글 앱스를 사용할 때 필요한 기능과 기업이 이미 사용하고 있는 레거시 애플리케이션과의 통합을 위한 기능을 추가했다. 실제 , LDAP 동기화 기능인 구글 앱스 디렉터 싱크 기능을 제공함으로써 기존 익스체인지 서버나 도미노 서버의 사용자 정보를 연동 가능하게 해주었다. 이 기능은 과거 구글이 합병한 이메일 보안 및 아카이빙 전문업체인 포스티니를 통해서 개발한 것이다.



물론 구글 앱스가 기업의 모든 기술적 요구사항을 만족시킨다고 말할 수는 없다. 하지만 기존의 기업 고객이 원하는 것을 미리 파악하고 이 부분을 해결하기 위한 노력이 없다면 결코 고객을 만족시킬 수 없으며 다가갈 수 없다는 것을 잘 보여준다고 할 수 있다. 이러한 측면에서 구글은 아주 영리한 SaaS 공급자이다.



이구동성으로 국내 소프트웨어 업계의 고사위기에 대해 이야기 하고 있다. SaaS야 말로 기존 대형 SI 회사들의 거미줄에 걸려있는 국내 소프트웨어 업체들이 정당한 대가를 받고 자립할 수 있는 대안중 하나이다. 그러나 성공적인 SaaS 서비스를 위해서는 "개방 전략"이 필요하다. 업체간에 연동과 기술 공유, 그리고 기존 레거시 시스템 연동을 위해 플랫폼을 개방(Open)하며 실제 이를 이루기 위해 진정한 위한 오픈 마인드를 가져야 한다.



과거 필자는 국내 그룹웨어 시장의 대부분을 차지하고 있던 업체와 결제 시스템을 연동하기 위한 제휴를 진행한 적이 있었다. 막대한 개발비를 요구하였으며 고압적인 자세때문에 협상에 애를 먹었었다. 결론적으로 울며 겨자먹기 식으로 상당한 금액을 주고 SDK를 받아 연동을 했었다. 얼마 후 반대의 상황이 발생했었다.



필자가 경영하던 회사의 제품을 사용하던 고객이 해당 그룹웨어를 도입했는데 이 때는 반대로 해당 그룹웨어를 필자의 제품에 연동을 해야 했었다. 마치 복수하듯이 기존에 요청했던 금액보다 휠씬 많은 금액을 요구했었다. 실제 곰곰히 생각해 보면 어느 누구도 얻은 것 없었다. 물론, 대형 SI 회사는 여전히 수익을 챙겼었지만.



만약 서로 간에 합리적인 제휴를 통해 솔루션을 연계하고 이를 바탕으로 고객에게 보다 질 높은 솔루션을 제공했다면 분명 더 많은 것을 얻었을 것이다. 마찬가지로 지금 태동하는 SaaS도 무엇보다도 앞서 언급한 것들이 요구된다 할 수 있다. 분명 SaaS의 미래는 밝으나 그 아침은 그냥 오는 것은 아니다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/07/19 14:05 2009/07/19 14:05
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/4459

[칼럼]사용자 통지를 사소하게 다루는 IT조직들-1
최영석BSI코리아 심사위원 YoungSug.Choi@bsigroup.com
2009.07.17 / AM 09:38최영석

[지디넷코리아]국내 IT조직들을 관찰하면서 꼭 다루고 싶었던 문제점들 중에 하나가 ‘사용자 통지’에 대한 것들이다. 사용자 통지를 단순히 IT조직의 ‘친절함’을 사용자들에게 과시하는 정도로만 이해하고 있는 IT조직들이 아직도 많다.



통지를 제때 받지 못하거나, 전달에 실패하는 경우, 사용자들은 IT를 이용해서 본인의 업무를 처리하는 데 큰 불편을 겪거나, 불필요한 시간을 허비하게 된다. IT를 비즈니스와 연결시키는 큰 그림도 중요하지만, 실제 비즈니스 활동을 수행하는 사용자들이 IT를 사용함에 있어 겪는 불편함을 최소화하는 것도 중요하다는 것을 강조하고 싶다.



통지 시점, 통지 내용, 통지 대상자 및 통지 방법 등의 통지 활동 전반에 산재해 있는 문제들로 인해 사용자들을 지속적으로 소외(?)시키거나, 불만을 제기하게 만들고 있는 일부 IT조직에 대해 알아보자.
지면상 2회로 나누어서 다루어 보겠다.



■통지란 무엇인가?



통지(Notification)는 필요한 사람들에게 적절한 시기에 약속된 방법으로 정보를 알려주는 활동이다.



서비스 분야에서는 주로 접수 여부와 처리 결과를 알려주는 활동을 얘기하지만, IT분야에서는 장애와 변경과 같은 사건들이 발생하는 경우에도 통지가 일어나게 되므로, 일반적인 서비스 분야보다는 좀더 넓고 복잡하다고 할 수 있다.



통지는 발생하는 동기에 따라서 수동적인(Reactive) 통지와 적극적인(Proactive) 통지로 나누어 볼 수 있다.
수동적인 통지는 사용자의 요청이나 장애가 발생한 이후에 확인(confirmation)이나 정보공유의 목적으로 정보를 사용자에게 전달하는 것을 의미한다. 적극적인 통지는 사용자의 요청이나 장애가 발생하지 않았더라도, 사용자에 영향을 주는 사건이 발생했거나 발생할 것으로 예측되는 경우, 사용자들에게 미리 정보를 알려주는 적극적인 활동이다.



IT를 둘러싸고 발생하는 ‘사건’에 따라서는 ‘사용자 요청’에 대한 통지와 ‘변경 및 장애’에 대한 통지로도 나누어 볼 수 있다. ‘사용자 요청’에 대한 통지는 사용자에게 접수 확인, 진행 상태 및 이슈사항에 관련된 정보를 전달하는 것을 의미한다.



‘변경 및 장애’에 대한 통지의 경우는 사용자들에게 변경과 장애의 발생 사실, 진행 상태 및 이슈사항에 관련된 정보를 전달하는 활동으로 볼 수 있겠다.



■‘확인’ 통지가 부실한 경우



수동적인 통지이면서 사용자 요청에 관련된 ‘확인(confirmation)’ 통지는 가장 기본적인 통지 활동이라고 볼 수 있다. 패밀리레스토랑에 가서 주문을 할 때, 또는 계산할 때 우리는 ‘확인’ 통지를 경험한다. 주문한 내용을 접수하는 종업원이 주문내용을 ‘다시 한번’ 불러주거나, 계산 시 현금을 받은 경우 얼마를 받았다라고 굳이(!) 알려준다.



이렇게 귀찮을 정도로 확인을 해주는 이유는 무엇일까?



‘확인’ 통지는 요청자가 본인이 요청한 내용이 접수되었는지를 확신하게 해주는 좋은 실행사례 중의 하나다. 식당에서 추가적인 주문을 했을 때 종업원의 ‘확인’ 통지가 없는 경우, 계속 기다려야 하는 지 아니면, 다시 한번 외쳐야(!)하는지 고민한 경험을 떠올려 보면 이해를 할 수 있다.



‘확인’ 통지와 관련하여 국내IT조직의 현실을 살펴보자. 우선 사용자 요청을 전문적으로 처리하는 ‘서비스데스크(Service desk)’의 유무에 따라 ‘확인’ 통지의 적용 여부가 극명하게 갈린다.



서비스데스크가 없는 IT조직의 경우, 통지 활동 전반이 불규칙적이다. 이들 조직은 사용자의 요청을 접수하는 IT담당자가 ‘개발자’나 ‘운영자’와 같은 엔지니어인 경우가 대부분이고, 사용자 요청을 접수하고 통지하는 활동들을 대부분 ‘구두’로 처리하고 있다.



국내정서로 볼 때, IT엔지니어가 사용자 요청에 대해 친절하게 확인을 해주는 모습은 여전히 어색하며, 구두로 처리되는 접수 및 통지 활동은 IT담당자의 기억력이나 꼼꼼함에 의존할 수 밖에 없다.



서비스데스크가 있는 IT조직도 ‘확인’ 통지가 원활하지 않는 경우가 있다. 이들 조직의 대부분은 사용자 요청의 전 과정을 IT시스템으로 관리하고 있다. 하지만 일부 IT조직들은 IT시스템에는 ‘확인’ 통지 기능이 없거나, 있어도 사용하지 않고 있다는 사실을 발견하게 된다. 그 이유를 살펴보면, ‘확인’ 통지의 필요성을 이해하지 못하거나, ‘그런 것까지, 왜?’라는 다소 시니컬한 인식이 깔려있다는 것을 느끼게 한다.



■사용자 문의와 통지 관련 사례

사용자 문의에 대한 IT조직의 ‘통지’ 활동이 실제 어떻게 일어나고 있고 문제점이 무엇인지를 간단한 사례를 통해 알아보자. 한 사용자가 IT조직으로 전화를 했다. 본인이 사용하는 응용시스템에서 특정 값을 입력하면 에러가 발생한다고 한다. 입력기능이 처리가 되어야만 자신의 업무가 종료된다는 말을 덧붙였다.



접수한 IT직원은 사용자에게 접수내역에 대한 ‘확인’통지를 하고 IT조직의 내부의 개발자에게 문의한 결과 임시로 처리할 수 있는 방법을 알아냈으며, 이 문제를 근본적으로 해결하기 위해서는 응용시스템의 수정이 필요하다는 것을 확인했다.



IT직원은 임시로 처리할 수 있는 방법과 향후 응용시스템에 대한 수정될 것이라는 사실을 사용자에게 통지한 후, 요청 건을 종료 처리하였다.



1주일 후 동일한 사용자로부터 또 전화가 왔다. 언제까지 임시 처리 방법으로 사용해야 하는 지를 문의하였다. 상담원은 다시 개발자에게 확인하였고, 이미 응용시스템의 수정이 이틀 전에 완료되었다는 사실을 알게 되었고 정상적인 방법으로 응용시스템을 사용하면 된다는 내용으로 사용자에게 ‘통지’하였다.



■통지의 ‘연속성’ 문제



위의 사례에서, IT직원은 기본적인 ‘확인’ 통지와 ‘임시 처리 방법’에 대한 통지를 정상적으로 수행했다. 하지만 사용자가 임시 처리 방법을 언제까지 사용할 것인지, 즉 IT내부적으로 응용시스템의 수정이 완료되는 시점에 대해서는 미리 ‘통지’하지 않았다.



여기에서 통지의 ‘연속성’문제가 발생한다. 통지의 ‘연속성’은 ‘사용자 입장’에서의 궁금함과 불편함이 완전히 종료될 때까지, 필요한 정보를 적절한 시점에 사용자에게 전달하는 것을 의미한다.



위의 사례의 경우, 통지의 연속성을 보장하기 위해서는 ‘확인’통지-> ‘임시처리방법’통지->’문제완전해결’통지까지를 연속적으로 사용자에게 제공하여야 한다. 이 사용자는 언제까지 임시처리방법의 불편함을 감수해야 하는지가 궁금했으나, 이에 대한 IT조직의 통지가 없어서 이틀간의 업무 손해(?)를 떠안은 후에 결국 전화를 하게 된 사례다.



이처럼 사용자입장에서 연속적이지 않는 통지는, 또 다른 불만을 야기하거나, 기존 통지를 위한 IT조직의 ‘노력’을 평가절하시킬 수 있다.



■통지의 연속성을 어떻게 보장할 것인가?



IT내부의 프로세스를 잘 이해하고 있는 사람은 눈치챘겠지만, 위와 같은 통지의 연속성 문제를 해결하기 위해서는, IT 내부적으로 두 가지 문제를 해결해야 한다.



첫째는, 위와 같은 사용자 문의 건은 ‘문제완전해결’통지 전까지는 IT직원이 해당 요청 건을 종료하지 않아야 한다. 접수한 IT직원과 상위 관리자는 항상 ‘열려’있는 상태의 요청 건에 대해서만 관심을 가지고 처리하기 때문이다. 사용자 통지가 원시(!)적인 IT조직의 경우는 ‘확인’통지 이후 사용자 문의 건을 종료시키기도 한다.



둘째는, 사용자 문의 건을 해결하기 위해 응용시스템 수정이 완료되었다는 사실이, 접수한 IT직원에게 적절한 시기와 방법으로 ‘통지’되어야 한다. 이것은 IT조직내의 ‘사용자 요청 프로세스’와 ‘변경 프로세스’간의 인터페이스가 긴밀해야만 가능하다. IT직원을 통해 사용자 요청이 변경프로세스로 전달되고, 사용자 요청을 해결하기 위한 변경이 진행되며, 이 과정에서 변경의 ‘상태’를 포함한 정보가 다시 사용자 요청 프로세스를 거쳐, 최초 접수한 IT직원에게 전달되는 흐름이 일관성 있게 유지되어야 한다.



언급한 사례 이외에도 다양한 통지의 연속성 문제들을 만나게 된다. 이들 사례들을 근본적으로 해결하기 위해서는 IT내부 프로세스를 긴밀하게 가져갈 수 밖에는 없다는 사실을 알아야 한다. 다음 칼럼에서는 ‘통지로부터 ‘소외’되는 사용자’에 대한 이야기를 해 보겠다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/07/19 13:54 2009/07/19 13:54
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/4458

Google'Analytics - (2009.6.01~7.13)







크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/07/14 11:29 2009/07/14 11:29
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/4447

국내
건설산업에서 PMIS는 아직도 매우 일천한 수준인 것으로 관측되고 있습니다. 현재 건설업계에서는 몇몇의 대형 건설업체가 사업관리시스템을
개발, 적용하고 있지만 아직 그 성과에 대한 분석결과가 구체적으로 공개되지 않고 있으며, 개별기업 단위의 시스템으로 개발되었기 때문에 전체
건설산업으로 확산되는 속도가 매우 더딘 형편입니다. 또한 일부 IT업체를 중심으로 건설공사관리 및 건설업체 업무용 소프트웨어들이 다수 개발되어
있기는 하지만, 미국에서 나타나는 형태와 같은 건설사업관리를 위한 ASP 전문업체들의 Project Web-Hosting, 보다 전문화되고
업무통합적인 PMIS(Project Management Information System) 솔루션의 개발, 보급은 아직 활성화되고 있지
못합니다. 이러한 현상은 국내 건설업계의 PMIS에 대한 인지도가 아직 미흡하고 또한 국내의 PMIS 개발 현황, 관련 ASP업체 및 그 기능
등에 대한 고찰이 부족하기 때문인 것으로 판단됩니다.



다음은
국내에서 PMIS를 도입한 사례입니다. 참고하시기 바랍니다.

Ⅰ. 서울시 지하철건설본부
【사 업 명】자료처리 및 프로그램(PMIS) 개발
【사업 기간】2000년 9월 ~ 2001년 12월(15개월)
【사 업 비】427백만원
【사업 수행】보림정보시스템(단독 수급)
【사업 목적】
현재 개발 시범운영하고 있는 PMIS에 대하여 전산환경 변화에 적응하고 의사결정
지원기능을 강화하며 공사, 안전, 품질, 비용 등 지하철 건설사업에 대한 종합적이고 과학적인 정보관리로 건설행정의 능률화를 도모하고 나아가 대민
서비스의 질적 향상과 시정 경쟁력을 제고하는데 기여
【사업 내용】
- 건설사업관리시스템 분석/설계/개발/현장적용
- 일반현황/공정관리/공사관리/설계관리/변경관리
- 품질관리/안전관리/민원분쟁관리/보상관리/계약관리/예산관리
- 시운전/감리/현황판/현장문서관리/자료관리/시스템관리
- 관리자조회시스템
【활용 내용】
서울시지하철건설본부에서 수행하는 9호선 건설, 3호선/7호선 연장 건설과 시설개량사업 및 편의시설개선 사업 등의
건설사업관리에 대한 적용
【주요적용기술】
- 방법론 : 관리기법/1
- H/W 환경 : SUN E350, HP Net Server
- S/W 환경 : DELPHI, MIDAS, ORACLE, APACH, JAVA, JSP - N/W 환경 : TCP/IP



Ⅱ. 한국토지공사
【사 업 명】 CITIS기반 건설사업관리시스템(PMIS) 구축
【사업 기간】 2003년 1월 ~ 2004년 9월(20개월)
【사 업 비】 1,732백만원
【사업 수행】 포스데이타와 보림정보시스템(공동수급)
【사업 목적】
한국토지공사의 New Vision인 “국가 토지경영의 최고기업”달성을 위해
인터넷 기반의 전자문서 교환체계를 활용한 건설사업 전과정을 종합적이고 체계적으로 관리할 수 있는 건설사업관리시스템을 구현하여 건설업무의 효율성을
극대화하고 건설산업의 품질향상 도모를 목적으로 함.
【사업 내용】
- 표준분류체계 구축(사업/공종/내역/자료/문서자료분류체계 등)
- 건설사업관리시스템 구축(기획/조사설계/시공/사후관리/사업관리/전자문서교환체계)
- 파일럿시스템 구축 및 실증
【활용 내용】
현재 20여개 지구 80여개 현장이 건설사업관리시스템(PMIS)을 활용하여 현장의 건설사업관리를 하고 있음 【주요적용기술】
- 방법론 : 관리기법/1
- H/W 환경 : HP SuperDom
- S/W 환경 : Oracle RDBMS V9i/Oracle9i
AS/Viewer/GAUCE/XecureWeb
- N/W 환경 : TCP/IP



Ⅲ. 서울시 건설안전본부
【사 업 명】 건설사업관리정보시스템(C-PMIS) 구축
【사업 기간】 2004년 1월 ~ 2004년 12월(12개월)
【사 업 비】 594백만원
【사업 수행】 보림정보시스템과 공관프로테크(공동수급)
【사업 목적】
본 사업은 서울시 건설안전본부가 “도로건설/유지관리 전문기관”으로서의 위상을 확립하기
위해 표준분류체계를 기반으로 인터넷을 통한 전자적 업무처리와 현황정보의 취합/축적이 가능한 발주자용 건설사업관리정보시스템 구축 사업으로
도로건설사업 전 과정(Life Cycle)을 종합적이고 체계적으로 관리함으로써 의사결정의 신속화, 업무추진의 정확화를 통해 도로건설업무의
효율성을 극대화하고 건설산업의 품질을 향상시키는 것을 목적으로 함.
【사업 내용】
- 표준분류체계 구축(사업/공종/내역/자료/문서/자원분류체계 등)
- 건설사업관리시스템 구축(기획/조사설계/시공/사후관리/사업관리/전자문서교환체계)
【활용 내용】
현재 강남순환도시고속도로 건설사업을 비롯한 27여 개 건설사업에 시범적용 중이며 건설현장에서는 건설사업관리시스템을
활용하여 현장의 건설사업관리를 하고 있음
【주요적용기술】
- 방법론 : 관리기법/1
- S/W 환경 : Oracle RDBMS V9i/Oracle10g AS/GAUCE/XecureWeb - N/W 환경 : TCP/IP



Ⅳ. 농업기반공사
【사 업 명】 농업기반공사 사업관리시스템(KPMS) 구축
【사업 기간】 2005년 7월 ~ 2006년 12월(18개월)
【사 업 비】 1,338백만원
【사업 수행】 보림정보시스템과 한국인프라(공동수급)
【사업 목적】
본 사업은 농업기반공사의 건설사업관리부문 정보화에 대한 마스터플랜을 수립하고 이를 토대로
건설사업관리 구성요소에 대한 표준화, 新건설사업관리 업무프로세스 개선, 인터넷 기반의 공사(公社)사업관리시스템을 구현함으로써 公社업무의 효율성
증대와 건설공사의 품질 향상은 물론 지식경영 및 전략경영의 기반을 조성하는데 목적이 있음.
【사업 내용】
- 농업기반시설 건설사업관리 마스터 플랜 수립
- 파일럿시스템 구축 및 운영평가
- 표준분류체계 수립(사업/공종/시설물/사업비/문서자료/자원분류체계 등)
- 건설사업관리시스템 구축(사이버상황실/사업관리/공사관리/사후관리/전자문서교환체계) 【주요적용기술】
- 방법론 : e-Karico방법론 중 CBD방법론과 관리방법론
- S/W 환경 : Oracle RDBMS V9i/Oracle AS 10g/마이플렛폼(MiPlatform)/XecureWeb - N/W 환경 : TCP/IP

이 지식은 SERI포럼의 열린지식존 > 지식SOS에 올라온 회원 답변글입니다.



크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/07/10 10:57 2009/07/10 10:57
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/4438

중앙정렬 사이트에서 좌/우측에 배너를 위치시킬때 사용한다.

FireFox에서는 픽셀값을 숫자형으로 형변환해서 적용해야 실행된다는 점을 유념하자.





<html>
<body onresize="javascript:centerWindow();" onload="centerWindow();">
<script language="JavaScript">
<!--
function centerWindow() {
var xMax = document.body.clientWidth, yMax = document.body.clientHeight;

var xOffset = (xMax-200)/2+20, yOffset = (yMax-150)/2+40; 
//중심에서 오른쪽으로 20, 아래로 40픽셀에 항상 위치하는 레이어
var divMenu = document.getElementById('Layer1').style;
divMenu.top = parseInt(yOffset) + 'px';
divMenu.left = parseInt(xOffset) + 'px';
}
//centerWindow(); 
//-->
</script>

<div id="Layer1" style="position:absolute; left:200px; top:80px; width:200px; height:150px; z-index:1"> 
<table width="200" border="0" cellspacing="0" cellpadding="0">
<tr>
<td align="center" bgcolor=#FFFFFF style="border:#808080 1px solid;" height=150>
<span style="font-family:굴림; font-size:9pt">
항상 중심에 뜨는 <br>
레이어 샘플입니다.</span><br>
<img src="http://www.google.co.kr/images/logo_sm.gif" width="150" height="55" alt="배너"> 
</td>
</tr>
</table>
</div>
</body>
</html> 

크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/07/03 16:41 2009/07/03 16:41
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/4422

소프트웨어 아키텍처 교육 공고

한번 받아 보고 싶은 교육 중 하나!

한국생산성본부 IT비즈니스센터 : http://www.kpcit.or.kr/

>
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기

Posted by 홍반장

2009/07/03 10:10 2009/07/03 10:10
Response
No Trackback , No Comment
RSS :
http://tcbs17.cafe24.com/tc/rss/response/4421

« Previous : 1 : ... 32 : 33 : 34 : 35 : 36 : 37 : 38 : 39 : 40 : ... 101 : Next »

블로그 이미지

- 홍반장

Archives

Recent Trackbacks

Calendar

«   2024/11   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Statistics Graph

Site Stats

Total hits:
240000
Today:
652
Yesterday:
712