루키의 보석함

이 글은 김수민님이 작성한 http://blog.naver.com/kimsumin75/20052758036 에서 가져왔습니다. 요즘 전산보안론을 배우고 있는데요.. 찾아보니 이해하기 쉽게 작성해 놓으셨더라구요.. DES 암호 알고리즘을 이해하는데 도움이 많이 됩니다. ================================================= 자 드디어 본격적으로 암호 알고리즘을 공부해 봅시다. DES 알고리즘을 들어가기 전에 블록 암호의 구조를 간단하게 살펴보도록 하겠습니다. 아래 사진은 IBM의 암호학자였던 Horst Feistel (독일) 의 사진입니다. 흐 .. 아무래도 사진을 보면 친숙해서 머리속에 더 잘 남을 것 같아 ... 하나 올려봅니다. ^^; [사진 1] Horst Feis..

지난 글에서 프로젝트 성공 요인 중 변경관리, 희의관리, 이해관계자, 변화관리에 대해서 살펴봤습니다. 이번에는 이슈화, 리스크관리, 인적자원, 현실과 지표의 괴리에 대해서 알아보겠습니다. 다시 한번 출처를 언급하면 2004년 월간 시사컴퓨터에 기고된 천장락 교수님의 글을 정리해서 옮겨놓은 것입니다. 5. 사소해 보이는 문제도 '이슈화' 하자 프로젝트를 진행하다가 여러 가지 사정으로 계획과는 다르게 진행되거나, 계획대로 진행하기가 곤란한 문제가 발생했을 때 이슈가 발생했다고 합니다. 또 어떤 것이라도 일정에 차질을 주게 되면 이슈로 인식해야 한다고 합니다. 이러한 이슈를 관리하는 절차는 다음 6단계로 되어 있다고 합니다. 이슈 발생 인지 -> 이슈 분류 -> 대응 방안 수립 -> 대응 방안 실행 -> 실행..

2004년 5월 ~ 12월까지 월간 시사 컴퓨터에 연재된 천정락 교수님의 프로젝트 성공 요인 분석이란 자료가 있습니다. 4년여의 시간이 지났지만, 아직도 현재 진행하고 있는 IT 프로젝트에도 도움이 되는 이야기 인 듯 하여 정리해서 옮겨 봅니다. 1. 업무 변경 관리로 프로젝트 성공률을 높이자. 첫번째로 이야기 한 것은 변경 관리입니다. 프로젝트의 범위나 현업의 업무가 변경된 경우, 의사결정자들과 프로젝트 수행자들이 모여 업무 변경 관리 위원회를 만들고 체크해 나가야 한다는 이야기 입니다. 방법으로는 업무가 변경될 때마다, 단계별로, 프로젝트 막바지에 변경하는 방식이 있는데요 변경될 때마다 하는 것은 번거롭고 프로젝트 진행을 더디게 할 수 있구요. 단계별로 수행하는 것은 프로젝트가 잠시 멈추게 되므로 미..

지난번에 위험(risk)의 원인, 식별, 위험관리 프로세스에 대해서 이야기했습니다. 위험이라고 하는 것은 드러나기 전에 처리하는 것이 가장 좋기 때문에 이런 위험 관리가 필요합니다. 실제로 위험이 발생한 이후 처리한다면 프로젝트에 타격도 그만큼 크겠죠.. 4. 위험 관리 그래서 이번에는 위험을 관리하는 방법에 대해서 먼저 살펴보도록 할께요.. 위험을 관리한다고 해서 모든 위험요소를 제거할 수는 없을 겁니다. 그러나 위험관리를 통해서 위험을 회피하거나 위험요인을 줄이거나 위험 발생시 비상대책을 수립하는데 도움이 될 수 있습니다. 이러한 위험관리에 대해서 정리해 봅니다. 1) 획득 (Procurement) 프로젝트 수행 중에 기술적인 위험요소가 발생한다면, 그런 기술을 가지고 있는 사람이나 조직을 구해서 해..

프로젝트가 실패하는 가장 큰 요인은 바로 발생할 수 있는 문제점들을 드러내서 함께 논의하지 않고 나중에 해결하면 되겠지... 하는 안일한 생각으로 방치하기 때문이지 않을까 합니다. 그래서 이러한 문제점을 체계적으로 관리할 수 있는 위험관리에 대해서 정리해보려고 합니다. 위험관리를 포함한 품질관리와 관련된 규격으로는 TL 9000이 있습니다. ISO 9000이란 규격은 많이 들어 보셨을 텐데요.. TL 9000은 ISO 9000에 비해 IT 분야에 특화되어 있고, 품질기획/프로젝트계획/구성관리계획등 계획에 초점을 맞추고 있습니다. Telecommunication Leader 9000의 약어로 QuEST 포럼에서 ISO 9001을 기반으로 1999년 제정했으며, IT 분야의 특성에 따라 하드웨어/소프트웨어/..

Don't call me names! 언뜻 보면 "내 이름을 부르지 마라" 일 것 같지만, 실제 의미는 "욕하지 마라", "약올리지 마라" 라는 뜻으로 사용되는 문장입니다. names가 복수가 아닌 단수형인 name으로 사용되었다면 이름이라는 의미 그대로 쓰였겠지만, 복수가 되면서 여러개의 이름 즉, 별명으로 보기 때문에 위와 같은 뜻이 되었을 거라고 합니다. 이름이라는 것은 하나의 고유한 의미를 가져야 합니다. 그리고 이름을 지어준다는 것은 그 객체(물체이건 상황이건)에 생명력을 불어넣는 계기가 됩니다. 빅무(Big Moo)라는 책에 나오는 이야기 인데요.. 뉴턴이 중력을 발견해서 유명해진 것으로 알고 있지만, 실제로 뉴턴이 발견한 것은 미적분과 반사 망원경이라고 합니다. 뉴턴은 미적분과 연금술 연구에..

구글맵을 시작으로 지도 매쉬업은 이제 보편화되어 많은 사이트에서 사용하고 있는 듯 합니다. ProgrammableWeb에서 3 Ways to Improve Your Map Mashup을 보다가 국내의 지도 매쉬업들과 연관해서 어떻게 하면 보다 나은 지도 매쉬업을 만들 수 있을까 해서 정리해 봅니다. 저도 미니맵 매쉬업이라는 주소 검색을 통해 위치를 찾고, 해당 지도의 URL이나 HTML 코드를 가져다가 Email, 블로그에 사용할 수 있는 매쉬업을 만들어보기는 했는데요.. (실제 사용하는 분들은 거의 없는 현실입니다. -.-) 단순히 지도만 보여주는 매쉬업 서비스로는 한계가 있는 것이 분명한 듯합니다. 그렇다면 어떤 요소들이 있어야 할까요? 1. 테마 정보와 연계해야 한다. 첫번째로 생각해 볼 수 있는 ..

소셜 네트워크 서비스로 유명한 Facebook에서 모바일용 프로그램을 내놓았네요.. BlueWhaleMail 이라는 것인데요.. 모바일에서도 email 뿐만 아니라 Facebook에서 제공하는 각종 SNS 관련 정보들을 볼 수 있다고 하네요.. 먼저 동영상을 한번 보시죠.. 음.. 원문을 대략 살펴보니.. iPhone이나 Black Berry와 같은 스마트폰이 아니어도 사용할 수 있다고 하는 것 같은데요.. 결국 서비스들이 웹에서 모바일로 점차 이동해 가는 분위기 인 듯 합니다. Facebook과 관련된 또 하나의 소식이 있네요.. 웹에서 많이 사용하는 서비스로 Facebook이 2위를 차지했네요.. 그런데 여기에서 살펴보니 역시 1위는 Email 이네요.. 아직까지는 소셜네트워크의 파워가 Email을 ..

구글의 번역을 활용한 서비스들이 점차 늘어나고 있는 듯합니다. 현재까지의 번역 수준은 안습(?)이지만, 앞으로 향상될 거라는 기대 속에 이를 활용한 서비스 모델이 등장하는 것 같네요.. 초기의 기계 번역에 비해서는 대략적인 의미파악은 되니 일취월장한 것이라 볼 수 있겠지요.. 오늘 소개할 서비스는 RSS를 각국의 언어로 번역해서 보여주는 서비스인 Mloovi 입니다. 사용법은 매우 간단한데요.. RSS Feed 주소를 입력하면 지정한 언어로 나타납니다. 로딩하는데 약간의 시간이 걸리기는 하지만, 그럭저럭 괜찮아 보이네요.. ^^ 아마도 저처럼 영어 울렁증이 있는 사람들에게는 외국 블로그를 살펴보는데 조금이나마 도움이 될 것 같습니다. 그래서 자주 가는 사이트인 Ajaxian의 사이트를 지정해서 돌려봤습니..

Ajax 인 프랙티스 - 데이브 크레인 외 지음, 일래스틱웨어 외 옮김/위키북스 이제 기본적인 Ajax 호출 방식을 사용하는 개발자는 없을 겁니다. Prototype, DWR, Scipt.aculo.us 등의 서드 파티 프레임워크를 주로 사용하죠.. 이런 프레임워크에 대해 잘 정리되어 있는 책입니다. 문제를 제시하고 이를 풀기 위한 솔루션을 설명하는 형태로 구성되어 나중에 찾아서 활용하기도 쉽게 되어 있습니다. 다만, 너무 많은 내용을 다루려다 보니.. 내용이 좀 어렵게 느껴집니다. JSON, prototye, event, class 등 다양한 자바스크립트의 기능들을 제대로 이해해야만 소스를 파익할 수 있습니다. 솔직히 소스 코드를 보는 데 정신이 없더군요.. 하지만, 한번쯤 쭉 읽어보면 왠만한 자바스크..