2017년 2월 18일 토요일
2017년 2월 16일 목요일
클라우드 시대에서의 맞춥법
옛날에는 사람을 판단하는 기준으로 '신언서판'을 삼았습니다. 용모, 언변, 문필, 판단이죠. 여기서 문필에는 글을 얼마나 반듯하게 쓰는지를 보았지만, 인터넷에서는 글씨체를 확인할 수가 없습니다. 그래서 이 기준은 이제 맞춤법으로 봐야 할거 같네요.
이제는 문서나 이메일을 쓸때 맞춤법은 그 사람을 판단할 때 중용한 기준입니다. 그래서 오히려 예전보다 더 맞춤법을 신경쓰고 조심하고 있습니다. 그런데 구글앱스를 사용해서 자료를 관리할때는 맞춤법에 약간은 고민을 해야 합니다. 테스트를 위해서 아래 3가지 메일을 만들었습니다.
메일 1 : 아버지가 방에 들어가셨습니다.
메일 2 : 아버지 가방에 들어가셨습니다.
메일 3 : 아버지가방에들어가셨습니다.
테스트 1 : '아버지' 검색 -> 1, 2 메일만 검색
테스트 2 : '가방' 검색 -> 2,3 메일만 검색
테스트 3 : '들어가' 검색 -> 검색안됨
테스트 4 : '방에' 검색 -> 1메일만 검색
단순한 테스트이지만, 몇년 지난 메일을 찾을 때 꼭 필요한 고려사항입니다. 한글을 검색할 때에는 형태소(의미있는 단어) 단위로 분석을 해서 그 기준으로 검색을 하는데 띄어쓰기나 중간단어 같은 경우에는 찾기 어려운 경우가 았습니다. 예를 들어 '조재영' 이라는 이름에서 '재영'으로 검색하면 메일을 못찾는 경우도 생길 수 있다는 의미입니다. 그러기 때문에 가끔씩은 검색을 위해서 맞춤법을 약간은 지키지 못하는 경우도 발생할 거 같네요. 메일을 찾아야 하니깐요.
이런 이유로 회사에서 문서 분류를 아주 정확하게 하는 곳에서는 문서 하나에 30개 정도의 태그를 다는 경우도 있습니다. (제약회사의 임상실험결과) 문서나 메일을 작성하면서 나중에 어떤 단어나 키워드로 검색을 할 것인지 생각을 해보고 테스트해서 그 기준에 맞춰서 글을 작성하는 것도 클라우드 시대에는 필요한 작업입니다. 왜냐고요? 클라우드는 용량제한이 없는 무한의 공간이기 때문이죠.
이제는 문서나 이메일을 쓸때 맞춤법은 그 사람을 판단할 때 중용한 기준입니다. 그래서 오히려 예전보다 더 맞춤법을 신경쓰고 조심하고 있습니다. 그런데 구글앱스를 사용해서 자료를 관리할때는 맞춤법에 약간은 고민을 해야 합니다. 테스트를 위해서 아래 3가지 메일을 만들었습니다.
메일 1 : 아버지가 방에 들어가셨습니다.
메일 2 : 아버지 가방에 들어가셨습니다.
메일 3 : 아버지가방에들어가셨습니다.
테스트 1 : '아버지' 검색 -> 1, 2 메일만 검색
테스트 2 : '가방' 검색 -> 2,3 메일만 검색
테스트 3 : '들어가' 검색 -> 검색안됨
테스트 4 : '방에' 검색 -> 1메일만 검색
단순한 테스트이지만, 몇년 지난 메일을 찾을 때 꼭 필요한 고려사항입니다. 한글을 검색할 때에는 형태소(의미있는 단어) 단위로 분석을 해서 그 기준으로 검색을 하는데 띄어쓰기나 중간단어 같은 경우에는 찾기 어려운 경우가 았습니다. 예를 들어 '조재영' 이라는 이름에서 '재영'으로 검색하면 메일을 못찾는 경우도 생길 수 있다는 의미입니다. 그러기 때문에 가끔씩은 검색을 위해서 맞춤법을 약간은 지키지 못하는 경우도 발생할 거 같네요. 메일을 찾아야 하니깐요.
이런 이유로 회사에서 문서 분류를 아주 정확하게 하는 곳에서는 문서 하나에 30개 정도의 태그를 다는 경우도 있습니다. (제약회사의 임상실험결과) 문서나 메일을 작성하면서 나중에 어떤 단어나 키워드로 검색을 할 것인지 생각을 해보고 테스트해서 그 기준에 맞춰서 글을 작성하는 것도 클라우드 시대에는 필요한 작업입니다. 왜냐고요? 클라우드는 용량제한이 없는 무한의 공간이기 때문이죠.
스마트폰으로 지도 리스트를 만들기
다른 사람과 정보를 공유해서 같이 일할때 가장 먼저 떠오르는 것은 문서이지만, 스마트폰의 성능이 좋아져서 위치나 다른 정보도 공유하기가 좋습니다. 오늘 소개해 드릴 기능은 일반 구글계정에서도 사용할 수 있는 기능으로 위치 정보를 공유하는 기능입니다.
구글 지도는 네이버나 다음 지도에 비해서 협업(Collaboration) 기능이 좋습니다. 즉, 여러명이 같은 지도로 작업을 할 수 있다는 의미입니다. 지도로 어떤 작업을 할 수가 있을까요? 가장 쉽게는 다음과 같이 방송대 지역 지도를 공유할 수 있습니다.
이 방식외에 최근에 기능이 추가되었습니다.
스마트폰 구글 지도를 실행합니다. https://play.google.com/store/apps/details?id=com.google.android.apps.maps
지명을 입력합니다. 아래에서는 '한국방송통신대'로 검색을 했습니다. 하단에 보면 신기능에 대한 기능 소개가 표시되고 있습니다.
제일 밑에 '새목록'을 선택합니다.
등록하고자 하는 목록 이름을 입력합니다.
'한국방송통신대'로 입력 되었습니다.
'한국방송통신대'로 작성된 목록에 학교 주소를 등록했습니다.
구글 지도에서 다음과 같이 내 장소를 확인할 수 있습니다.
부산지역대학도 추가했습니다. 이런식으로 모든 지역대학과 학습관을 추가할 수 있을겁니다.
물론 공유를 하기 위해서는 공유 옵션을 공개나 공유됨으로 변경해야 할것이고요.
2017년 2월 13일 월요일
2016년 스마트워크 실태조사
2016년 스마트워크 실태조사가 발표되었습니다. 해당 설문지 및 처리방법에 대해서 확인하지 못해서 아쉽지만, 인지도 및 운용효과 상승이 눈에 띕니다. 아무리 보안을 강해도 팀에서 카톡방 하나는 운영하시죠. 그리고 클라우드에 파일 하나는 보관합니다. 생각보다 모바일오피스는 많이 사용하는 것으로 조사되어 고무적이네요.
□ 미래창조과학부(장관 최양희, 이하‘미래부’)와 한국정보화진흥원(원장 서병조, 이하 ‘진흥원’)은 국내 민간분야 스마트워크 인지도와 이용 현황을 조사한「2016년 스마트워크 실태조사 결과」발표했다.
※ 스마트워크 : 시간과 장소를 기반으로 하는 전통적인 근무방식을 탈피하여 ICT기술을 활용하여 다양한 형태로 근무하는 방식
o 이번 스마트워크 실태조사는 상시근로자 5인 이상의 민간사업체 근로자 1,700명과 관리자 300명을 대상으로 온‧오프라인을 통해 실시되었다.
□ 2016년 민간분야 스마트워크 실태조사 결과의 주요내용은 다음과 같다.
o (스마트워크 인지도) 민간사업체 근로자의 스마트워크 인지도는 71.5%로 전년(66.6%) 대비 4.9%p 상승하였으며, 관리자의 인지도 89.1%로 근로자에 비해 높은 인지도를 보였다.
- 또한, 스마트워크를 운영하고 있는 기업의 관리자 98.5%가 스마트워크 운영 효과가 있다고 응답했으며 업무 효율성 증진, 업무 연속성 향상 등에서 효과가 크다고 응답하였다.
o (스마트워크 이용 유형) 스마트워크 이용 경험이 있는 근로자들이 가장 많이 이용한 스마트워크의 유형은 ▲모바일 오피스(스마트워크 이용자의 52.5%) ▲유연근무제(46.5%) ▲원격회의/원격협업(44.0%), ▲재택근무(36.5%) 순으로 나타났다.
o (스마트워크 이용자 만족도) 스마트워크 세부 근무유형별 이용자 만족도는 평균 67.6점으로 전년(65.5점) 대비 2.1점 상승하였으며,그 중 유연근무제가 70.2점으로 만족도가 가장 높았고, 재택근무(69.5점), 원격회의/원격협업(69.3점), 모바일 오피스(66.9점)의 순으로 조사되었다.
o (스마트워크 기업 운영 현황) 기업의 스마트워크 인식 평가는 모바일오피스(75.7점)와 유연근무제(74.6점)가 가장 높게 평가되었으나,실제 운영현황을 보면 모바일오피스(13.2%), 탄력근무제(5.3%), 재량근무제(2.3%) 등으로 기업체 단위에서의 스마트워크 운영률은 낮은 것으로 조사되었다.
- 이는 스마트워크를 운영하므로서 얻게 되는 수익 향상과 업무 효율성에 대한 영향력이 확인되지 않아 도입에 부담감을 느끼고 있는 것으로 분석되고 있다.
□ 미래부 송정수 정보보호정책관은 “노동 공간에 대한 구속력이 없는 고용형태가 증가하는 등 일하는 방식의 변화가 앞으로 제4차 산업혁명으로 더욱 가속화될 것으로 판단된다.”고 말하고
o “정부에서는 범사회적으로 일하는 방식 변화에 대한 관심이 고조되고 있는 점에 주목하여 민간분야에서 ICT기술을 활용한 스마트워크도입 지원과 인식제고 확산을 위해 노력하겠다.“라고 밝혔다.
출처 : http://m.msip.go.kr/mobile/cms/contentsView.do?cateId=mssm15_12&artId=1327969&pageNum=1
미래부,「민간분야 2016년 스마트워크 실태조사 결과」발표
- 스마트워크 인지도 71.5%로 전년대비 4.9% 상승 - 스마트워크 도입기업 98.5%로 운용효과가 있다고 응답 - 스마트워크 이용자 만족도 67.6점으로 전년대비 2.1점 상승 |
□ 미래창조과학부(장관 최양희, 이하‘미래부’)와 한국정보화진흥원(원장 서병조, 이하 ‘진흥원’)은 국내 민간분야 스마트워크 인지도와 이용 현황을 조사한「2016년 스마트워크 실태조사 결과」발표했다.
※ 스마트워크 : 시간과 장소를 기반으로 하는 전통적인 근무방식을 탈피하여 ICT기술을 활용하여 다양한 형태로 근무하는 방식
o 이번 스마트워크 실태조사는 상시근로자 5인 이상의 민간사업체 근로자 1,700명과 관리자 300명을 대상으로 온‧오프라인을 통해 실시되었다.
□ 2016년 민간분야 스마트워크 실태조사 결과의 주요내용은 다음과 같다.
o (스마트워크 인지도) 민간사업체 근로자의 스마트워크 인지도는 71.5%로 전년(66.6%) 대비 4.9%p 상승하였으며, 관리자의 인지도 89.1%로 근로자에 비해 높은 인지도를 보였다.
- 또한, 스마트워크를 운영하고 있는 기업의 관리자 98.5%가 스마트워크 운영 효과가 있다고 응답했으며 업무 효율성 증진, 업무 연속성 향상 등에서 효과가 크다고 응답하였다.
o (스마트워크 이용 유형) 스마트워크 이용 경험이 있는 근로자들이 가장 많이 이용한 스마트워크의 유형은 ▲모바일 오피스(스마트워크 이용자의 52.5%) ▲유연근무제(46.5%) ▲원격회의/원격협업(44.0%), ▲재택근무(36.5%) 순으로 나타났다.
o (스마트워크 이용자 만족도) 스마트워크 세부 근무유형별 이용자 만족도는 평균 67.6점으로 전년(65.5점) 대비 2.1점 상승하였으며,그 중 유연근무제가 70.2점으로 만족도가 가장 높았고, 재택근무(69.5점), 원격회의/원격협업(69.3점), 모바일 오피스(66.9점)의 순으로 조사되었다.
o (스마트워크 기업 운영 현황) 기업의 스마트워크 인식 평가는 모바일오피스(75.7점)와 유연근무제(74.6점)가 가장 높게 평가되었으나,실제 운영현황을 보면 모바일오피스(13.2%), 탄력근무제(5.3%), 재량근무제(2.3%) 등으로 기업체 단위에서의 스마트워크 운영률은 낮은 것으로 조사되었다.
- 이는 스마트워크를 운영하므로서 얻게 되는 수익 향상과 업무 효율성에 대한 영향력이 확인되지 않아 도입에 부담감을 느끼고 있는 것으로 분석되고 있다.
□ 미래부 송정수 정보보호정책관은 “노동 공간에 대한 구속력이 없는 고용형태가 증가하는 등 일하는 방식의 변화가 앞으로 제4차 산업혁명으로 더욱 가속화될 것으로 판단된다.”고 말하고
o “정부에서는 범사회적으로 일하는 방식 변화에 대한 관심이 고조되고 있는 점에 주목하여 민간분야에서 ICT기술을 활용한 스마트워크도입 지원과 인식제고 확산을 위해 노력하겠다.“라고 밝혔다.
출처 : http://m.msip.go.kr/mobile/cms/contentsView.do?cateId=mssm15_12&artId=1327969&pageNum=1
2017년 2월 9일 목요일
글로벌 칼럼 | 클라우드 프로젝트가 예산을 초과하는 4가지 이유
최근 클라우드 통합 기업을 상대로 비공식적 설문조사를 한 결과 매우 의외의 사실을 하나 발견했다. 고만 고만하고 정형화된 퀵 스타트 프로젝트야 그렇다 해도, 새로운 고객을 상대로 한 클라우드 컨설팅의 70%에서 수주 변경이나 비용 초과가 나타난 것으로 조사됐기 때문이다. 특히 프로젝트 규모가 클수록 비용이 초과될 가능성도 커졌다.
이에 대해 컨설턴트 탓을 할 수도 있고, 애초에 계산을 잘못했다거나 고객이 이상하다고 탓할 수도 있겠지만, 누군가의 탓을 한다고 문제가 사라지지는 않는다. 중요한 것은 고객과 업체 모두에게 고통을 안겨주는 상당히 심각한 문제가 존재한다는 것이다.
만약 클라우드 비용이 예상을 넘어섰다면 십중팔구 잘못된 기대치 설정이 이유일 것이다. 특히 고객은 자신의 요구사항이 실제보다 훨씬 적은 비용으로 실제보다 훨씬 쉽게 충족할 수 있다고 믿는 경향이 있다. 하지만 설령 이것이 사실이라고 해도 이 부분에 대해 어떻게 해 볼 방법은 없다. 그러니 이것 외에 비용 초과를 초래하는 원인이 무엇인지 살펴보고 대처방법을 찾는 것이 현명하다.
비용 초과를 부채질하는 4가지 요소
클라우드 프로젝트 대부분은 여러 가지 파트로 정확하게 나뉘어 운용되므로 예상과 실제 비용 사이에 차이가 크게 나는 일은 별로 없다. 하지만 이건 어디까지나 이상적인 이야기다. 주기적으로 비용 초과가 발생하는 프로젝트 분야는 다음과 같다.
1. 데이터 통합과 이전
데이터 통합과 이전은 마치 머리 둘 달린 괴물과 같다. 늪 한 가운데 빠질 때까지 무엇이 문제인지 모르고 지나치는 경우가 대부분이라 심각한 문제를 야기한다.
비용 초과는 데이터의 양과 데이터 소스에 비례한다. 표면적으로는 말끔해 보여도 포맷 문제, 부적합한 값, 의미론적 과적과 객체-모델(object-model)의 모호함 등 데이터 통합과 이전을 복잡하게 만드는 요소가 수두룩하다. 특히 지속적 통합이 요구되는 상황에서는 초반에 사용한 포인트-투-포인트 어댑터를 결국 미들웨어 시스템으로 대체해야 한다는 것을 알아채지 못할 수 있다.
해법: 이전 및 통합할 데이터의 양, 데이터 소스에 대한 비용편익 분석을 실시하고 현실적인 비용을 설정해야 한다. 프로젝트를 시작할 때 이전/통합/확인과 관련된 작업을 시작해 프로젝트가 한참 진행된 후에 놀라는 일이 없도록 하자. 데이터 이전과 통합이 프로젝트에 있어 가장 큰 부분을 차지할 수 있다는 점을 미리 고려해야한다.
2. 커스텀 코드
많은 기업이 프로젝트를 규정함에 있어 '코드 없이, 고정 관념의 틀을 깨는' 프로젝트가 되길 희망하지만 하루도 채 지나지 않아 이를 충족하는 것이 불가능하다는 것을 깨닫는다. 안타깝지만 컨설턴트 중에는 코드를 사랑하는 이들이 많기 때문에, 이들은 적극적으로 고객을 커스텀 코드의 세계로 인도하려 한다.
게다가 SFDC(Salesforce.com) 플랫폼의 훌륭한 코딩 환경은 사용자 인터페이스나 비즈니스 로직 측면에서 봐도 코딩을 더 매력적인 옵션으로 보이게 한다. 그러나 문제는 개발자 생산성과 코드 유지 비용이다. 커스텀 코딩은 표준 설정 방식보다 비용이 훨씬 많이 들어간다.
해법: 가능한 한 표준적인 시스템 기능과 기성 플러그인 제품을 이용하도록 노력한다. 요구 사항을 최대한 가용 자원에 맞도록 조정하고, 초기 배포 단계에서 코딩을 최대한 배제해 코더가 안정적인 플랫폼에서 작업할 수 있도록 해야 한다.
아이템 개발의 경우 보안 모델, 명령 설정, 배포/파트너 네트워크 등 조합적 확산을 유발할 수 있는 스트림 라인 프로세스와 비즈니스 룰에 위임해야 한다.
3. 보기 좋은 떡이 먹기도 좋다?
오리지널 SFDC 리포팅 엔진은 파워와 사용 용이성 간의 균형이 훌륭하지만, 최종 결과물은 거의 스프레드시트 수준에 그친다. 따라서 한 눈에 들어오는 보기 좋은 리포트를 원한다면 오리지널 SFDC 엔진만으로는 금세 한계에 부딪힐 것이다.
SFDC의 웨이브 리포팅 시스템은 더 강력하면서도 보기 좋은 리포트를 제공하지만, 이를 제대로 사용하려면 쿼리 코드를 써야 한다. 한걸음 더 나아가 깔끔한 포맷, 멀티 페이지 레이아웃, 자동 오피스 도큐먼트 생성 같은 작업까지 하려면 서드 파티 애드-온이 필요하다. 그러나 모든 프로젝트가 그렇듯 외양에 신경을 쓰면 쓸 수록 비용은 더 많이 들어간다. 최초 설치 비용뿐 아니라 사용자의 요구에 맞춰 이용하는 과정에서도 마찬가지다.
해법: 포맷과 개별 사용자의 수정 내용에 이르기까지 리포트의 모든 변수를 하나하나 빼놓지 말고 철저히 이해하고 구체화하라. 처음엔 10개를 생각했는데 알고 보니 100개 이상의 리포트가 필요하다면 그 사실을 빨리 알게 될수록 더 좋다.
액세스나 크리스탈 등 시스템 에뮬레이션(emulation)이 필요한 리포트가 있다면 업체에게 포맷과 예외 조건에 대한 주석을 달아 입력 데이터 샘플과 리포트의 결과물을 제시해야 한다.
4. 프로젝트 관리와 감사
이는 철저히 프로젝트 리더, 임원에 의해 주도되는 과정이어서 해당 관리자의 행위는 곧바로 비용 초과로 이어질 수 있다. 프로젝트에서 거리와 지연이 효율성과 경제성을 해치는 가장 큰 위협이라는 것은 익히 알고 있을 것이다. 필자는 여기에 '망설임'과 '(끝을 모르는) 재발견'을 추가하겠다. 우선 망설임(또는 우유부단함)은 프로젝트의 지연과 방향성 혼란을 야기해 경제성을 해친다는 점에서 명확한 문제이다.
'재발견'은 구체적인 설명이 필요하다. 끝을 모르는 발견이란, 바꿔 말해 요구 조건을 사전에 철저히 체크하지 못해, 작업 방향에 대한 잘못된 가정으로 인해, 그리고 신규 시스템 기능의 동작 방식을 제대로 예측하지 못해 발생하는 문제다. 범위 추가의 근본적인 원인이라고도 할 수 있다. 실제 현업에서 불충분한 사전 기획으로 인해 대규모 프로젝트에 50% 이상의 비용 추가가 발생하는 사고가 드물지 않게 발생한다.
해법: 사전 기획 기간을 보다 충분히 갖고 끝난 후에는 기능, 데이터를 함부로 추가하지 못하도록 철저하게 규정을 적용하자. 프로젝트 팀은 소규모로 빠듯하게 운영될수록 좋고, 컨설팅 기관의 참여도 한 곳으로 제한하는 것을 권장한다(사공이 많으면 배가 산으로 간다).
업무는 팀원 간의 신뢰를 쌓아가는 과정이다. 비판만 하는 구성원은 따끔히 정리하는 것이 좋다. 임원과 회계 담당자는 프로젝트에서 최대한 멀리 떼어놓는 것이 유리하며, 성대한 리뷰 미팅 역시 최소화할 필요가 있다. 팀원이 모호하고 임의적인 지표나 프로젝트 대시보드가 아닌 명확한 비즈니스 가치에 집중하도록 하는 것 역시 프로젝트 리더로서 노력해야 할 부분이다.
애자일이 중요한 이유
요즘 필자는 <실수와 실패의 경계선에서 배우다(Being Wrong-Adventures in the Margin of Error)>라는 책을 읽고 있다. 이 책을 읽기 전에는 <왜 전문가는 계속 우리를 실망시키는가(Wrong! Why Experts Keep Failing Us)>라는 책을 읽었다. 어쩌면 조금 질린 것일 수도 있지만, 그래도 필자는 여전히 비용 초과가 잘못된 예상, 파편화된 정보, 불완전한 요구사항과 신뢰의 부족 때문에 발생한다고 생각한다.
재미있는 것은, 양측이 모두 정확한 기대치를 세우고 실제 요구되는 사항에 대한 탄탄한 이해를 기초로 신뢰 관계를 쌓아나갈 수 있는 팔로우-온 프로젝트에서는 비용 초과가 훨씬 적게 발생한다는 것이다. 따라서 초기 프로젝트에 있어서는 클라이언트도, 컨설턴트도 프로젝트가 어느 정도 불확실성을 갖고 있음을 인정해야 한다.
왜냐하면 새로운 프로젝트에 임함에 있어 그 어느 쪽도 모든 것을 확신을 가지고 알지는 못하며, 시간과 돈을 들여 그에 대한 충분한 정보를 얻으려는 마음도 그다지 없기 때문이다. 프로젝트가 실제로 어떤 형태로 전개될 지 모른 채 서둘러 예산을 책정 받는 것이 현실에 더 가깝다. 그리고 실제 중반부가 지나서야 예상과 너무나 다른 전개에 당황하는 경우가 많다.
그렇다면 하이브리드 애자일 기술이 문제를 해결해 줄까? 그 생각은 접는 게 좋다. 그다지 도움이 되지 않기 때문이다. 진짜 '애자일'한 접근은 우리가 프로젝트에 대해 모르는 것이 많음을 인정하고, 프로젝트 결과의 범주를 유연하게 설정해 주어진 예산과 스케줄에 최대한 맞추는 것이다.
프로젝트를 진행하면서 예상치 못했던 변수가 발견됨에 따라 우선순위를 바꾸기도 하고, 고정된 (아마도 현실을 고려함 없이 설정된) 기준에 맞추기보다 비즈니스 가치를 극대화하는 데 더 초점을 맞춰야 한다.
제대로만 활용한다면, 프로젝트에 대한 애자일한 접근이야말로 '제 시간에, 예산에 맞춰'를 구호처럼 외치는 재무팀을 만족시키면서도 프로젝트 완성을 통해 사용자에게 가장 중요한 부분을 전달할 수 있도록 해 줄 것이다.
원문보기:
http://www.itworld.co.kr/news/103371#csidx82896ace6b590609fb09c2a872b1314
이에 대해 컨설턴트 탓을 할 수도 있고, 애초에 계산을 잘못했다거나 고객이 이상하다고 탓할 수도 있겠지만, 누군가의 탓을 한다고 문제가 사라지지는 않는다. 중요한 것은 고객과 업체 모두에게 고통을 안겨주는 상당히 심각한 문제가 존재한다는 것이다.
만약 클라우드 비용이 예상을 넘어섰다면 십중팔구 잘못된 기대치 설정이 이유일 것이다. 특히 고객은 자신의 요구사항이 실제보다 훨씬 적은 비용으로 실제보다 훨씬 쉽게 충족할 수 있다고 믿는 경향이 있다. 하지만 설령 이것이 사실이라고 해도 이 부분에 대해 어떻게 해 볼 방법은 없다. 그러니 이것 외에 비용 초과를 초래하는 원인이 무엇인지 살펴보고 대처방법을 찾는 것이 현명하다.
비용 초과를 부채질하는 4가지 요소
클라우드 프로젝트 대부분은 여러 가지 파트로 정확하게 나뉘어 운용되므로 예상과 실제 비용 사이에 차이가 크게 나는 일은 별로 없다. 하지만 이건 어디까지나 이상적인 이야기다. 주기적으로 비용 초과가 발생하는 프로젝트 분야는 다음과 같다.
1. 데이터 통합과 이전
데이터 통합과 이전은 마치 머리 둘 달린 괴물과 같다. 늪 한 가운데 빠질 때까지 무엇이 문제인지 모르고 지나치는 경우가 대부분이라 심각한 문제를 야기한다.
비용 초과는 데이터의 양과 데이터 소스에 비례한다. 표면적으로는 말끔해 보여도 포맷 문제, 부적합한 값, 의미론적 과적과 객체-모델(object-model)의 모호함 등 데이터 통합과 이전을 복잡하게 만드는 요소가 수두룩하다. 특히 지속적 통합이 요구되는 상황에서는 초반에 사용한 포인트-투-포인트 어댑터를 결국 미들웨어 시스템으로 대체해야 한다는 것을 알아채지 못할 수 있다.
해법: 이전 및 통합할 데이터의 양, 데이터 소스에 대한 비용편익 분석을 실시하고 현실적인 비용을 설정해야 한다. 프로젝트를 시작할 때 이전/통합/확인과 관련된 작업을 시작해 프로젝트가 한참 진행된 후에 놀라는 일이 없도록 하자. 데이터 이전과 통합이 프로젝트에 있어 가장 큰 부분을 차지할 수 있다는 점을 미리 고려해야한다.
2. 커스텀 코드
많은 기업이 프로젝트를 규정함에 있어 '코드 없이, 고정 관념의 틀을 깨는' 프로젝트가 되길 희망하지만 하루도 채 지나지 않아 이를 충족하는 것이 불가능하다는 것을 깨닫는다. 안타깝지만 컨설턴트 중에는 코드를 사랑하는 이들이 많기 때문에, 이들은 적극적으로 고객을 커스텀 코드의 세계로 인도하려 한다.
게다가 SFDC(Salesforce.com) 플랫폼의 훌륭한 코딩 환경은 사용자 인터페이스나 비즈니스 로직 측면에서 봐도 코딩을 더 매력적인 옵션으로 보이게 한다. 그러나 문제는 개발자 생산성과 코드 유지 비용이다. 커스텀 코딩은 표준 설정 방식보다 비용이 훨씬 많이 들어간다.
해법: 가능한 한 표준적인 시스템 기능과 기성 플러그인 제품을 이용하도록 노력한다. 요구 사항을 최대한 가용 자원에 맞도록 조정하고, 초기 배포 단계에서 코딩을 최대한 배제해 코더가 안정적인 플랫폼에서 작업할 수 있도록 해야 한다.
아이템 개발의 경우 보안 모델, 명령 설정, 배포/파트너 네트워크 등 조합적 확산을 유발할 수 있는 스트림 라인 프로세스와 비즈니스 룰에 위임해야 한다.
3. 보기 좋은 떡이 먹기도 좋다?
오리지널 SFDC 리포팅 엔진은 파워와 사용 용이성 간의 균형이 훌륭하지만, 최종 결과물은 거의 스프레드시트 수준에 그친다. 따라서 한 눈에 들어오는 보기 좋은 리포트를 원한다면 오리지널 SFDC 엔진만으로는 금세 한계에 부딪힐 것이다.
SFDC의 웨이브 리포팅 시스템은 더 강력하면서도 보기 좋은 리포트를 제공하지만, 이를 제대로 사용하려면 쿼리 코드를 써야 한다. 한걸음 더 나아가 깔끔한 포맷, 멀티 페이지 레이아웃, 자동 오피스 도큐먼트 생성 같은 작업까지 하려면 서드 파티 애드-온이 필요하다. 그러나 모든 프로젝트가 그렇듯 외양에 신경을 쓰면 쓸 수록 비용은 더 많이 들어간다. 최초 설치 비용뿐 아니라 사용자의 요구에 맞춰 이용하는 과정에서도 마찬가지다.
해법: 포맷과 개별 사용자의 수정 내용에 이르기까지 리포트의 모든 변수를 하나하나 빼놓지 말고 철저히 이해하고 구체화하라. 처음엔 10개를 생각했는데 알고 보니 100개 이상의 리포트가 필요하다면 그 사실을 빨리 알게 될수록 더 좋다.
액세스나 크리스탈 등 시스템 에뮬레이션(emulation)이 필요한 리포트가 있다면 업체에게 포맷과 예외 조건에 대한 주석을 달아 입력 데이터 샘플과 리포트의 결과물을 제시해야 한다.
4. 프로젝트 관리와 감사
이는 철저히 프로젝트 리더, 임원에 의해 주도되는 과정이어서 해당 관리자의 행위는 곧바로 비용 초과로 이어질 수 있다. 프로젝트에서 거리와 지연이 효율성과 경제성을 해치는 가장 큰 위협이라는 것은 익히 알고 있을 것이다. 필자는 여기에 '망설임'과 '(끝을 모르는) 재발견'을 추가하겠다. 우선 망설임(또는 우유부단함)은 프로젝트의 지연과 방향성 혼란을 야기해 경제성을 해친다는 점에서 명확한 문제이다.
'재발견'은 구체적인 설명이 필요하다. 끝을 모르는 발견이란, 바꿔 말해 요구 조건을 사전에 철저히 체크하지 못해, 작업 방향에 대한 잘못된 가정으로 인해, 그리고 신규 시스템 기능의 동작 방식을 제대로 예측하지 못해 발생하는 문제다. 범위 추가의 근본적인 원인이라고도 할 수 있다. 실제 현업에서 불충분한 사전 기획으로 인해 대규모 프로젝트에 50% 이상의 비용 추가가 발생하는 사고가 드물지 않게 발생한다.
해법: 사전 기획 기간을 보다 충분히 갖고 끝난 후에는 기능, 데이터를 함부로 추가하지 못하도록 철저하게 규정을 적용하자. 프로젝트 팀은 소규모로 빠듯하게 운영될수록 좋고, 컨설팅 기관의 참여도 한 곳으로 제한하는 것을 권장한다(사공이 많으면 배가 산으로 간다).
업무는 팀원 간의 신뢰를 쌓아가는 과정이다. 비판만 하는 구성원은 따끔히 정리하는 것이 좋다. 임원과 회계 담당자는 프로젝트에서 최대한 멀리 떼어놓는 것이 유리하며, 성대한 리뷰 미팅 역시 최소화할 필요가 있다. 팀원이 모호하고 임의적인 지표나 프로젝트 대시보드가 아닌 명확한 비즈니스 가치에 집중하도록 하는 것 역시 프로젝트 리더로서 노력해야 할 부분이다.
애자일이 중요한 이유
요즘 필자는 <실수와 실패의 경계선에서 배우다(Being Wrong-Adventures in the Margin of Error)>라는 책을 읽고 있다. 이 책을 읽기 전에는 <왜 전문가는 계속 우리를 실망시키는가(Wrong! Why Experts Keep Failing Us)>라는 책을 읽었다. 어쩌면 조금 질린 것일 수도 있지만, 그래도 필자는 여전히 비용 초과가 잘못된 예상, 파편화된 정보, 불완전한 요구사항과 신뢰의 부족 때문에 발생한다고 생각한다.
재미있는 것은, 양측이 모두 정확한 기대치를 세우고 실제 요구되는 사항에 대한 탄탄한 이해를 기초로 신뢰 관계를 쌓아나갈 수 있는 팔로우-온 프로젝트에서는 비용 초과가 훨씬 적게 발생한다는 것이다. 따라서 초기 프로젝트에 있어서는 클라이언트도, 컨설턴트도 프로젝트가 어느 정도 불확실성을 갖고 있음을 인정해야 한다.
왜냐하면 새로운 프로젝트에 임함에 있어 그 어느 쪽도 모든 것을 확신을 가지고 알지는 못하며, 시간과 돈을 들여 그에 대한 충분한 정보를 얻으려는 마음도 그다지 없기 때문이다. 프로젝트가 실제로 어떤 형태로 전개될 지 모른 채 서둘러 예산을 책정 받는 것이 현실에 더 가깝다. 그리고 실제 중반부가 지나서야 예상과 너무나 다른 전개에 당황하는 경우가 많다.
그렇다면 하이브리드 애자일 기술이 문제를 해결해 줄까? 그 생각은 접는 게 좋다. 그다지 도움이 되지 않기 때문이다. 진짜 '애자일'한 접근은 우리가 프로젝트에 대해 모르는 것이 많음을 인정하고, 프로젝트 결과의 범주를 유연하게 설정해 주어진 예산과 스케줄에 최대한 맞추는 것이다.
프로젝트를 진행하면서 예상치 못했던 변수가 발견됨에 따라 우선순위를 바꾸기도 하고, 고정된 (아마도 현실을 고려함 없이 설정된) 기준에 맞추기보다 비즈니스 가치를 극대화하는 데 더 초점을 맞춰야 한다.
제대로만 활용한다면, 프로젝트에 대한 애자일한 접근이야말로 '제 시간에, 예산에 맞춰'를 구호처럼 외치는 재무팀을 만족시키면서도 프로젝트 완성을 통해 사용자에게 가장 중요한 부분을 전달할 수 있도록 해 줄 것이다.
원문보기:
http://www.itworld.co.kr/news/103371#csidx82896ace6b590609fb09c2a872b1314
2017년 2월 8일 수요일
전 세계 이메일 65%가 스팸… 그중 10%는 ‘악성’
지난해 전 세계 이메일의 65%는 스팸 메일이라는 조사 결과가 나왔다. 스팸 메일 10개 중 1개는 사이버 공격에 악용될 수 있는 악성 메일인 것으로 분석됐다.
7일 글로벌 네트워크 업체 시스코가 발표한 ’2017 연례 사이버 보안 보고서’에 따르면 지난해 확인된 스팸 메일 발송량은 전체 이메일의 65%를 차지하며 2010년 이후 최고치를 기록했다.
스팸 메일 가운데 8∼10%는 이용자에게 정보유출 등의 피해를 줄 수 있는 악성 메일로 파악됐다.
스팸 메일 발송량은 보안 기술이 발전하면서 최근 수년간 안정적인 수준을 유지했지만, 최근 자동 발송 봇넷(botnet) ‘네커스(Necurs)’가 기승을 부리면서 급격히 늘었다.
해커들이 스팸 메일과 광고를 가장한 애드웨어 등을 앞세워 수익성이 좋은 기업들을 공격하면서 기업들의 피해는 커졌다.
시스코가 13개국 기업 약 3천여 곳의 최고 보안책임자(CSO)들을 대상으로 조사한 결과 지난 한 해 동안 사이버 공격을 당한 기업의 29%가 매출 피해를 봤고, 22%가 고객이 감소했다. 피해 기업의 50% 이상은 공개 조사를 받았고, 이로 인해 브랜드 평판에 타격을 입었다.
조사 대상 기업의 65%는 6∼50개에 달하는 보안 제품을 사용하고 있었지만, 관리에 어려움을 겪는 것으로 조사됐다.
시스코 코리아는 기업 피해를 막기 위해 보안에 우선으로 예산을 투입하고, 보안 효과를 측정할 수 있는 지표를 활용해 보안 프로세스를 꾸준히 점검하고 개선해야 한다고 조언했다.
2017년 2월 2일 목요일
글로벌 칼럼 | 클라우드가 실패하는 7가지 이유
가트너에 따르면, 2020년이 되면 정책적으로 클라우드를 사용하지 않는 기업은 현재 인터넷 없이 운영되는 기업만큼 드물어질 전망이다. IDG는 현재 기업의 70%가 하나 이상의 애플리케이션을 클라우드에서 실행 중이며 향후 12개월 내에 이 수치가 90%에 이를 것으로 예측했다. 즉, 2년이 지나면 클라우드를 사용하지 않는 기업은 희귀한 기업이 된다.
효율적으로 구축된 클라우드 환경은 민첩성, 비용 절감 등으로 이어질 수 있지만 잘못 구축된 환경은 클라우드가 제공하는 온갖 장점 못지않게 많은 문제점도 안게 된다. 따라서 클라우드 전략을 수립할 때 신중을 기해 클라우드 환경이 실패하는 다음의 7가지 주요 이유를 피해가야 할 것이다.
1. 모든 조건을 충분히 고려하지 않음
이름있는 유력한 클라우드 업체를 선택하면 분명 그 나름의 장점을 얻을 수 있지만 클라우드 조건을 충분히 살펴보기도 전에 섣부르게 업체부터 결정하는 기업이 많다.
처음 클라우드 벤더를 선택한 이후 다른 벤더로 바꾸기는 갈수록 더 어려워지고 있다. 따라서 클라우드 옵션을 평가할 때는 철저하게 해야 하며 향후 기업 환경이 어떻게 발전해야 하는지도 신중하게 고려해야 한다. 현재 업계의 추세가 멀티 클라우드를 향하고 있음을 감안하면 특히 중요한 부분이다.
2. 내부 불통
클라우드 도입 의사 결정이 중역 회의실과 사업부 수준에서 내려지는 경우가 많아지고 있다. 이른바 "섀도우 IT" 예산이 증가하면서 사업부가 직접 자체 클라우드 리소스를 조달할 수 있게 됐다.
그러나 많은 기업이 IT 팀과의 조율, 그리고 생산적인 클라우드 전략 커뮤니케이션에 어려움을 겪는다. 경영진은 커뮤니케이션 라인을 마련해 사업 운영 부서는 비즈니스 목표를 명료하게 밝히도록 하고, IT 팀이 이러한 목표를 현실적으로 달성하는 데 필요한 리소스를 평가할 수 있도록 해야 한다.
3. 새로운 기술을 익히지 않음
많은 IT 전문가에게 클라우드로의 전환은 새로운 기술, 스킬을 익혀야 함을 의미한다. 이를 위해서는 전체적으로 교육과 시간에 대한 투자가 필요하다. 무엇보다 IT 전문가는 구매, 구축, 관리할 적절한 클라우드 서비스를 논의하기 위해 비즈니스 목표와 요구 사항을 이해해야 한다.
지금 IT 전문가들은 가용한 클라우드 서비스가 무엇인지, 그러한 서비스가 조직에 어떤 이점을 제공하는지를 과거 어느 때보다 잘 이해해야 한다.
4. 너무 늦은 보안 구축
보안은 기업이 클라우드로 전환하면서 직면하는 문제 가운데 여전히 가장 높은 순위에 있다. 보안은 전환 첫 단계부터 구축해야 한다.
직원들의 연결 범위가 더 넓어지게 되므로 기업은 자사의 데이터를 보호하기 위해 가능한 모든 조치를 취해야 한다. 즉, IT는 첫 날부터 보안 위협에 대처하는 데 필요한 교육과 도구를 확보해야 한다.
이것이 모든 클라우드에서 공통적인 보안 전략이다. 기업은 클라우드 제공업체가 보호하는 대상과 회사의 팀이 보호하는 대상을 명확히 구분해 이해해야 한다.
5. 너무 빠른 전환 작업
클라우드로의 전환(migration)은 모든 팀이 전환의 각 단계에서 확신을 느낄 수 있도록 한 번에 하나의 비즈니스 영역씩, 느리게 진행해야 한다. 따라서 가장 중요도가 낮은 사업부부터 전환을 시작해 더 중요한 사업부에 대한 전환을 시작하기 전에 팀이 클라우드 환경 구축 프로세스에 익숙해지도록 해야 한다.
클라우드 전환은 시간이 걸리는 작업이다. 또한 클라우드 환경은 확장이 가능하도록 구축해야 한다. 너무 빨리 팀을 클라우드로 밀어 넣을 경우 전체 클라우드 인프라가 위험에 빠진다.
6. 제대로 되지 않은 비용 최적화
많은 기업이 클라우드의 가격 모델을 제대로 파악하는 데 어려움을 겪는데, 클라우드 투자의 35%가 낭비되는 비용이라고 추정된다. 기업에서 VM의 사용률이 떨어지고 더 이상 사용하지 않는 인스턴스에 비용을 지불하는 경우는 흔한 일이다. 이는 클라우드 유지보수 비용의 급격한 상승을 유발할 수 있다.
클라우드로 전환한다고 해서 무조건 막대한 예산이 필요한 것은 아니다. 그러나 클라우드 유지보수 전략을 신중하게 수립하지 않으면 경영진에게 그 정당성을 납득시키기 어려울 정도의 예산이 필요해지게 된다.
7. 새로운 기술 도입에 소극적
신기술은 기업에게 혁신을 위한 좋은 기회를 부여한다. 지금은 많은 IT 부서가 자동화, 머신러닝, 소프트웨어 정의 데이터 센터(SDDC) 등이 비즈니스에 부여하는 가능성을 주시하고 있다. 클라우드가 제공할 수 있는 기회를 온전히 활용하지 못하는 기업은 클라우드 혁명의 다음 단계에서 뒤쳐지게 될 것이다. editor@itworld.co.kr
원문보기:
http://www.itworld.co.kr/news/103257#csidxeed38b6643d3ee2b863ce6a565e19d3
효율적으로 구축된 클라우드 환경은 민첩성, 비용 절감 등으로 이어질 수 있지만 잘못 구축된 환경은 클라우드가 제공하는 온갖 장점 못지않게 많은 문제점도 안게 된다. 따라서 클라우드 전략을 수립할 때 신중을 기해 클라우드 환경이 실패하는 다음의 7가지 주요 이유를 피해가야 할 것이다.
1. 모든 조건을 충분히 고려하지 않음
이름있는 유력한 클라우드 업체를 선택하면 분명 그 나름의 장점을 얻을 수 있지만 클라우드 조건을 충분히 살펴보기도 전에 섣부르게 업체부터 결정하는 기업이 많다.
처음 클라우드 벤더를 선택한 이후 다른 벤더로 바꾸기는 갈수록 더 어려워지고 있다. 따라서 클라우드 옵션을 평가할 때는 철저하게 해야 하며 향후 기업 환경이 어떻게 발전해야 하는지도 신중하게 고려해야 한다. 현재 업계의 추세가 멀티 클라우드를 향하고 있음을 감안하면 특히 중요한 부분이다.
2. 내부 불통
클라우드 도입 의사 결정이 중역 회의실과 사업부 수준에서 내려지는 경우가 많아지고 있다. 이른바 "섀도우 IT" 예산이 증가하면서 사업부가 직접 자체 클라우드 리소스를 조달할 수 있게 됐다.
그러나 많은 기업이 IT 팀과의 조율, 그리고 생산적인 클라우드 전략 커뮤니케이션에 어려움을 겪는다. 경영진은 커뮤니케이션 라인을 마련해 사업 운영 부서는 비즈니스 목표를 명료하게 밝히도록 하고, IT 팀이 이러한 목표를 현실적으로 달성하는 데 필요한 리소스를 평가할 수 있도록 해야 한다.
3. 새로운 기술을 익히지 않음
많은 IT 전문가에게 클라우드로의 전환은 새로운 기술, 스킬을 익혀야 함을 의미한다. 이를 위해서는 전체적으로 교육과 시간에 대한 투자가 필요하다. 무엇보다 IT 전문가는 구매, 구축, 관리할 적절한 클라우드 서비스를 논의하기 위해 비즈니스 목표와 요구 사항을 이해해야 한다.
지금 IT 전문가들은 가용한 클라우드 서비스가 무엇인지, 그러한 서비스가 조직에 어떤 이점을 제공하는지를 과거 어느 때보다 잘 이해해야 한다.
4. 너무 늦은 보안 구축
보안은 기업이 클라우드로 전환하면서 직면하는 문제 가운데 여전히 가장 높은 순위에 있다. 보안은 전환 첫 단계부터 구축해야 한다.
직원들의 연결 범위가 더 넓어지게 되므로 기업은 자사의 데이터를 보호하기 위해 가능한 모든 조치를 취해야 한다. 즉, IT는 첫 날부터 보안 위협에 대처하는 데 필요한 교육과 도구를 확보해야 한다.
이것이 모든 클라우드에서 공통적인 보안 전략이다. 기업은 클라우드 제공업체가 보호하는 대상과 회사의 팀이 보호하는 대상을 명확히 구분해 이해해야 한다.
5. 너무 빠른 전환 작업
클라우드로의 전환(migration)은 모든 팀이 전환의 각 단계에서 확신을 느낄 수 있도록 한 번에 하나의 비즈니스 영역씩, 느리게 진행해야 한다. 따라서 가장 중요도가 낮은 사업부부터 전환을 시작해 더 중요한 사업부에 대한 전환을 시작하기 전에 팀이 클라우드 환경 구축 프로세스에 익숙해지도록 해야 한다.
클라우드 전환은 시간이 걸리는 작업이다. 또한 클라우드 환경은 확장이 가능하도록 구축해야 한다. 너무 빨리 팀을 클라우드로 밀어 넣을 경우 전체 클라우드 인프라가 위험에 빠진다.
6. 제대로 되지 않은 비용 최적화
많은 기업이 클라우드의 가격 모델을 제대로 파악하는 데 어려움을 겪는데, 클라우드 투자의 35%가 낭비되는 비용이라고 추정된다. 기업에서 VM의 사용률이 떨어지고 더 이상 사용하지 않는 인스턴스에 비용을 지불하는 경우는 흔한 일이다. 이는 클라우드 유지보수 비용의 급격한 상승을 유발할 수 있다.
클라우드로 전환한다고 해서 무조건 막대한 예산이 필요한 것은 아니다. 그러나 클라우드 유지보수 전략을 신중하게 수립하지 않으면 경영진에게 그 정당성을 납득시키기 어려울 정도의 예산이 필요해지게 된다.
7. 새로운 기술 도입에 소극적
신기술은 기업에게 혁신을 위한 좋은 기회를 부여한다. 지금은 많은 IT 부서가 자동화, 머신러닝, 소프트웨어 정의 데이터 센터(SDDC) 등이 비즈니스에 부여하는 가능성을 주시하고 있다. 클라우드가 제공할 수 있는 기회를 온전히 활용하지 못하는 기업은 클라우드 혁명의 다음 단계에서 뒤쳐지게 될 것이다. editor@itworld.co.kr
원문보기:
http://www.itworld.co.kr/news/103257#csidxeed38b6643d3ee2b863ce6a565e19d3
피드 구독하기:
글 (Atom)