QR Code는 일본의 Denso Wave에 의해서 개발된 2차원 구조의 기호이며 대중적인 사용을 위해 특허권을 행사하지 않겠다고 선언하고 1994년에 배포 되었다. QR은 Quick Response의 약자이고 특징으로는 빠른 디코딩이 가능하고 기존 사용되어지는 바코드에 비해 대용량, 많은기록, 고밀도, 오류정정 기능 등이 있다.
일본에서는 책의 커버에 책에 대한 정보를 찾아 볼수 있도록 기록되기도 하고, 회전 초밥집의 접시에 붙여져 있거나 거리에서도 쉽게 찾아 볼수 있고 생활전반에 필요한 정보인 즉 명함, 전화번호, 문자, 홈페이지URL등 활용할수 있다.
CMS(Content Management System)이란,
웹사이트 구축에 필요한 웹기획자, 개발자, 디자이너의 3가지 역할 중
개발자와 디자이너의 영역을 처리해주는 SW분류를 의미합니다.
따라서 웹기획자가 의도한대로 유연하게 조정할 수 있는지, 손쉬운 관리가 가능한지 등이 중요한 검토항목이 됩니다.
CMS 주요 검토항목
네비게이션(메뉴) 관리 - 어느정도 depth의 네비게이션을 관리할 수 있는가, 관리기능은 세밀한 조정이 가능한가
콘텐츠 관리 - 작성가능한 콘텐츠의 종류는 다양한가, 모듈(컴포넌트)는 다양하게 존재하는가
스킨(테마) 관리 - 다양한 스킨이 제공되는가, 스킨은 손쉬운 편집이 가능한가
인증 - 컨텐츠 권한, 사용자 권한에 대한 세밀한 조정이 가능한가
사용자 정의 필드 - 개발자없이 원하는 필드를 추가, 삭제 할 수 있는가
사용자 정의 콘텐츠 - 개발자 없이 콘텐츠의 새로운 유형을 생성할 수 있는가
관리자 인터페이스 - 관리자에게 쉬운 인터페이스를 제공하는가
개발자라면 누구나 한번쯤 떠올려보는 SW지만, 쉬운관리와 세밀한 조정을 동시에 제공하기란 쉬운 일이 아닙니다.
CMS는 국내에서 Xe가 활발하게 사용되고 있으며, 해외에서 Drupal, Joomla 등이 활발하게 사용되고 있습니다.
이번시간에는 drupal 을 사용해서 웹사이트를 구축하는 방법을 진행해 보겠습니다.
제가 설치하는 시점에서는 6.17버전이 안정화 버전이라서 그걸 다운로드 받았습니다.
다운받은 파일을 설치할 경로에 압축해제 하시고,
http://설치도메인/install.php 를 브라우저로 호출하시면 설치단계가 시작됩니다.
저희 서버에는 modsecurity가 적용되어 있어서, 설치과정에 오류가 나네요~
구글링 해보니, Modsecurity 적용된 환경에서 Drupal 설치를 하려면
modsecurity 룰셋을 변경해 주어야 정상적으로 설치됩니다.
(Drupal 6.x, ModSecurity2 환경)
vi /etc/httpd/modsecurity.d/modsecurity_localrules.conf
Drupal 설치 전 설정을 저장할 파일과 디렉토리 권한을 조정해 줍니다
[hckim@www html]$ cp sites/default/default.settings.php sites/default/settings.php
[hckim@www html]$ chmod a+w sites/default/settings.php
[hckim@www html]$ chmod a+w sites/default
Drupal 설치 후 조정했던 권한을 변경해서 보안상 취약점을 제거합니다.
[hckim@www html]$ chmod a-w sites/default
[hckim@www html]$ chmod a-w sites/default/settings.php
기본 설치는 여기에서 끝났습니다.
설치 화면을 보시고 뭔가 마음에 안드시겠죠. 영어로된 화면하며, 복잡한 기능들..
차근차근 입맛에 맞게 설정해 가시다 보면, drupal의 유연한 기능에 놀라시게 될겁니다.
한글로 drupal을 사용하시기 위해서는 locale 모듈을 활성화하시고, 다운로드 받은 po파일을 Korean이란 항목에 import하시면 됩니다.
추가 모듈 설치
http://drupal.org/project/Modules
원하는 모듈을 다운로드해서 압축을 해제한 후 "drupal설치된 경로/modules" 안에 업로드 하세요
추가 테마 설치
http://drupal.org/project/Themes
원하는 테마를 다운로드해서 압축을 해제한 후 "drupal설치된 경로/theme" 안에 업로드 하세요
위지윅 편집기로 콘텐츠 작성을 위한 추가설치
rupal에서 사용가능한 WysiWyg 편집기는 종류가 매우 많습니다.
(htmlarea, fckeditor, ckeditor, yui editor 등)
설치하는 방법은 모듈로 설치하는 법과, wysiwyg 모듈안의 에디터코어를 추가하는 방법이 있는데
저는 모듈로 ckeditor를 설치하는 방법을 선택했습니다.
신규 인력을 채용할 때 제가 준비가 부족하지 않았나 해서 정리합니다.
역지사지라고. 입장을 바꿔보면 공감할 수 있는 내용인데, 매번 준비하지 못한 내용입니다.
좋은 인력을 채용하려면, 많은 노력을 하는 것이 당연하겠죠.
아래의 내용은 제가 생각하는 인재채용시 제공해야할 필수항목입니다.
회사의 비전을 잘 제시해 준다.(미래모델을 반드시 제공한다.)
회사가 지금까지 수행한 내용을 제공한다.
조직에 소속 후 누리게 되는 혜택에 대해서 선명하게 제시한다.
개인의 비전과 회사의 비전을 일치시킬 수 있도록 정보를 제공한다.
지원자를 배려하는 기술수준향상계획, 업무능력 고도화지원을 강조한다.
주기적인 평가에 의해서 달라지는 처우를 제공한다.
편안한 업무를 위해서 노력하고 있는 내용을 모두 기재한다.
복리후생에 대하여 허용되는 범위를 모두 기재한다.
개인 기술향상을 위한 지원내용을 포함한다.
실제 신뢰할 수 있는 사진을 첨부해서 보여준다.
회사 홈페이지에서 많은 정보를 얻게 되므로, 회사도메인에 대한 신뢰가 부여되도록 준비한다.
계층간의 정리도없고, 그냥 구조없는 나열식으로 데이터를 적어보는 중입니다.
이제 막 만들기 시작한 문서이니 부족한것을 차근차근 보충해가다보면 나아지겠죠. :-)
수행
개발방법론 없음 팀빌딩이 되지않은 프로젝트 진행 개발 후 디버깅이 불가능한 로깅 정책이거나 로깅정책이 없는 것. 주요기능에 대한 완벽한 품질보증(실 운영 환경에서의 테스트 부족) 프로토타입에 대한 과잉투자 주요 요구사항에 대한 우선순위가 없음 백업 및 복구정책이 없음 소스코드에 대한 형상관리 없음 정상적인 문서화를 수행하지 않아서 추후 장애발생시 대응 불가
사업관리
프로젝트중 추가된 요구사항변경에 대한 대응 미흡 일정계획의 잘못된 추정으로 무리한 진행 공정단계별 품질관리 부재 자원 분배의 부적절로 인한 효율적인 운영 미흡 비용계획의 잘못된 추정으로 인하여 손익구조 비정상
좀 오래된 책이긴 하지만, 여전히 매우 유용한 스티브 맥코넬의 RAPID Development이란
책에 나오는 RAD 적용 사례입니다.
열심히 하는 코딩만으로는 부족함을 느낄 때 반드시 읽어봐야 하는 내용이죠.
예전에 한번 봤던 책인데 이번에 다시보게되는 기회가 있어서
적용사례 한페이지를 타이핑했습니다. 도움이 되시기 바랍니다.
제품2.0을 만드는 프로젝트의 기술수석 사라의 이야기
첫 회의에서 그녀는 팀원을 소개한 후 바로 본론으로 들어갔다.
"회사 프로젝트 전체의 사후 분석을 검토했습니다. 이제까지 다른 프로젝트에서 저지른 실수 목록이 1킬로미터는 족히 되더군요. 이 목록을 회의실에 붙여놓겠습니다. 우리가 이들 중 어떤 실수라도 저지르는 기미가 보이면 경고해줄것을 부탁합니다. 또한 여러분이 이미 알고 있거나 앞으로 부딪히게 될 가능성이 있는 실수를 추가해 주십시오. 이미 겪은 일을 이유없이 반복할 필요는 없다고 봅니다."
"저는 여러분 각자가 개발 기본에 충실하기 때문에 이 팀 구성원으로 뽑았습니다. 나중에 불필요한 수정따위에 시간을 낭비하지 않을 수 있도록 제대로 요구사항을 분석하고 설계하는 활동이 얼마나 중요한지 여러분은 잘 알 것입니다. 저는 여러분이 그저 열심히 일하기 보다는 현명하게 일했으면 합니다. 무작정 열심히 일하면 그만큼 많은 실수를 저지르게 됩니다. 우리에게는 그럴 시간이 없습니다."
"위험 관리 계획도 세웠습니다. 일정이 너무 꽉 짜여 있기 때문에 미리 막을 수 있는 위험에 발목을 잡힐 수는 없습니다. 이 목록에서 가장 큰 위험은 일정을 맞출 수 없을지도 모른다는 점입니다. 그래서 이번주는 일정을 재평가했으면 합니다. 만약 달성할 수 없다면, 좀더 현실적인 계획을 세우도록 합시다."
팀원 모두가 고개를 끄덕였다. '죽음의 행군'식 프로젝트를 해왔던 사람들은 사라의 이야기에 매우 동감했다.
그 주 후반, 사라는 상사 에디와 회의를 했다. "개발팀과 프로젝트 일정을 진지하게 검토한 결과, 현재 일정으로 현재 요구기능을 완료할 확률이 약 5% 정도라고 결론을 내렸습니다. 아무것도 변하지 않는다는 가정에서입니다. 물론, 항상 뭔가가 변하게 마련이지요."
"그건 안됩니다." 에디가 말했다. "정시 출시 가능성이 적어도 50/50은 되야 합니다. 게다가 출시 후 12개월 동안은 시장의 변화에 대응할 수 있어야 합니다. 어떻게 했으면 좋겠습니까?"
"아직 제품을 완전히 구체화하지 않은 상태라서, 융통성은 약간 있습니다." 사라는 대답했다. "그렇지만 현재 요구기능을 완성하려면, 10개월에서 30개월 정도 걸린다고 봅니다. 너무 범위가 큰 줄은 알지만 우리가 만드는 제품에 대해 더 알기 전에는 이것이 최선의 추측입니다. 제품을 12개월만에 출시해야 하지요? 그 점을 고려한다면 개발자를 더 추가해야 합니다. 그리고 8개월 째에 첫 출시를 한 후 두달마다 출시용 버전을 만드는, 점진적인 출시계획을 세워야 한다고 봅니다."
"괜찮군요" 에디가 말했다. "게다가 이번 프로젝트에서는 기능이 일정보다 더 중요하다고 생각됩니다. 회사와 좀 더 논의한 후에 다시 이야기합시다."
에디는 사라에게 돌아와, 회사가 필요한 기능 완료를 위해 일정을 14개월까지 늘일 용의가 있다고 전했다. 또한 안전을 위해, 점진적인 개발법을 그대로 사용하도록 지시했다. 사라는 안심하며, 그것이 좀더 현실적인 목표라고 생각한다고 대답했다.
첫 몇 주 동안에 팀은 구체적인 사용자 인터페이스 프로토타입을 작성했다. '실수 목록'에서 프로토타입에 들이는 지나친 노력을 경고하였으므로, 프로토타입 치장을 피하기 위해 기간확정 방법을 사용하기로 했다. 팀은 구현할 기능을 결정하기 위해 고객들을 면담하는 데 프로토타입을 이용하고 사용자 피드백에 따라 이를 여러 차례 수정했다.
사라는 계속 위험 목록을 관리했다. 그녀는 프로젝트에서 가장 큰 위험은 '엄청난 수정을 요구하며 일정을 늘이는 낮은 품질', '무리한 일정', '경쟁력을 위해 도중에 추가하는 기능', 이 세 가지로 결정했다. 사라는 점진적인 출시 계획으로 '품질 위험'에 대응한다고 보았다. 팀은 8개월째에 첫 버전을 품질관리부에 넘길 예정이고, 품질관리부는 이에 맞춰 테스트 스크립트를 개발할 것이다.
팀은 기능 우선순위 목록을 만들어 일정 위험을 다루었다. 14개월안에 무조건 많은 기능을 개발하는 방법도 있겠지만, 제품을 두 달마다 출시가능한 상태로 만듦으로써 어느 시점이든 출시할 수 있는 제품을 확보할 것이다. 팀은 또한 몇가지 기능에 대해 구현시간을 줄이는 방식으로 설계를 했다. 시간을 덜 들여 구현할 기능은 별로 매끄럽지는 않겠지만 쓸만한 것이며, 이런 결정으로 일정 위험을 상당히 줄일 수 있었다.
팀은 '경쟁력 향상용 기능 위험'을 두 가지 방법으로 대응했다. 그들은 5개월정도 시간을 들여, 프로토타입한 모든 기능과 3.0에 포함할 기능을 지원할 수 있는 기반구조를 설계하였다. 이 기반구조로 변화를 큰 어려움 없이 수용하기 위함이다. 또한 팀은 12개월 째 시간을 할당하여, 경쟁사의 제품을 분석하고, 프로토타입을 재검토하기로 했다. 그 후 마지막 두달 동안, 경쟁력향상을 위해 필요한 기능을 구현하기로 했다.
6개월 시점에서 설계를 완성함과 동시에, 팀은 8개월째에 품질관리부에 넘길 첫 출시용 버전을 위해 중간목표를 상세하게 명시하는 세밀한 계획을 세웠다. 첫 버전은 별로 많은 기능을 포함하지는 않았다. 그러나 품질이 우수했고, 그 후 개발에 좋은 바탕이 되었다. 8개월째에 다시 10개월 지점을 위해 중간목표를 상세하게 명시하는 세밀한 계획을 세웠다. 12개월 지점을 위해서도 같은 방법을 사용했다.
12개월째 팀은 계획대로 경쟁회사제품을 분석했다. 경쟁사 하나가 10개월 무렵에 좋은 제품을 출시했고, 그 제품에는 우수한 기능이 들어 있었다. 제품2.0이 경쟁력을 가지려면 꼭 추가해야 하는 기능이었다. 팀은 새 기능들을 우선순위 목록에 추가하고 우선순위를 재조정하여 마지막 두달을 위한 상세계획을 세웠다.
그 즈음에 연구원들 중 호세가 좀더 나은 대화창 구성을 생각해내고, 팀회의에서 안건으로 제시했다. 선임 연구원 조지가 대답했다. "아이디어는 좋아. 바꾸는 편이 낫다고 생각하지만, 지금은 안되네. 호세 자네는 하루정도면 고칠수 있겠지만, 문서화 일정에 일주일 혹은 그이상 영향을 미치네. 버전 3.0 목록에 넣으면 어떨까?"
"문서화 일정에 미치는 영향을 미처 생각하지 못했습니다." 조는 말했다. "좋은 지적이군요. '나중에 할일' 목록에 추가하도록 요청하겠습니다.
14개월째 팀은 계획대로 최종 소프트웨어를 출시했다. 제품2.0의 품질은 8개월째부터 테스트를 해왔으므로 우수했다. 문서부는 소프트웨어가 완성되기를 기다리는 대신 상세한 인터페이스 프로토타입을 바탕으로 일할 수 있었기 때문에, 사용자 매뉴얼 역시 최종 소프트웨어와 같은 시기에 끝낼 수 있었다. 개발팀은 우선순위가 낮은 기능까지 구현할 시간은 없었지만 중요한 기능은 모두 구현했다. 제품2.0은 성공적이었다.
이미 많은 유수의 글로벌 회사들은 소셜미디어의 특성을 간파하여 이를 다양한 기업 활동,
즉 인재를 선발하고, 기업 생산성을 높이고, 기업의 혁신과 협업을 유도하며,
기업에대한 평판을 높이는 데 효과적으로 활용하고 있다
를 제공한다(델은 트위터를 통해 수백만 달러어치의 제품을 판매했을 뿐만 아니라 트위터 가입자
를 델 홈페이지로 유도하여 트위터 전용 상품을 판매하고 있다)
둘째, 기업이 대화를 주도할 수 있는 에코 시스템 구축을 통해서 전사적 발언이 가능하다
현재 국내 기업들은 트위터 계정을 만들고 홍보팀 내 담당자를 지정하여 소셜미디어를 활용하고 있다.
앞으로는 소셜미디어를 홍보의 일환이 아닌 기업 경영의 전체적 흐름에서 바라보아야 하며,
기업 커뮤니케이션 전체를 총괄하여 하나의 목소리를 낼 수 있도록 하는것이 필요하다.
셋째, 기업의 구성원간 쌍방향 의사소통의 도구로 활용하면 문제의 빠른해결이 가능하다.
소셜미디어는 사용자의 상호 작용과 관계에 의해 컨텐츠가 생산되고 확산되는 메커니즘을 가지고 있다.
주변의 네트워크를 통해 부여된 신뢰성을 기반으로 한 정보가 급속도로 퍼져나가는 특징을 지니고 있다.
홈페이지를 거쳐 블로그, 페이스북, 트위터로 이어지는 소셜미디어의 큰 흐름에 정치권 및 많은 기업들이 주목하는 것도 이 때문이다.
이는 과거의 통제 패러다임을 근간으로한 기업 내 관리는 더 이상 통용되기 힘든 시대가 도래했음을 의미한다.
대기업이든 중소기업이든 기업은 앞으로 더 이상 내부 임직원의 대내외 활동을 일일이 통제할 수 없다는 점을 인식해야 한다.
넷째, 기업경영 투명성 높이기
소셜미디어는 모든 것을 투명하게 보여준다.
과거에는 기업이 정보의 비대칭성을 이용, 기업에 유리한 일방적, 선별적 정보만을 소비자에게 전달함으로써
자사 제품을 홍보하는 것이 가능했다. 그러나 지금은 투명성이 경영의 기본으로 여겨지는 시대다
