'개발'에 해당되는 글 2건

  1. 2008.08.18 [수퍼개발자의 길 ①] 가슴의 꿈을 현실로 만드는 기술
  2. 2007.05.10 Elliptic curve cryptography (ECC)

[수퍼개발자의 길 ①] 가슴의 꿈을 현실로 만드는 기술

http://www.zdnet.co.kr/builder/dev/etc/0,39031619,39172030,00.htm


[수퍼개발자의 길 ①] 가슴의 꿈을 현실로 만드는 기술


양병규(빵집 개발자)   2008/08/15
[지디넷코리아]공 고를 졸업하여 전자제품을 만드는 회사에서 10여 년간 납땜을 하던 젊은이가 있었다. 결혼을 하고 되돌아보니 이미 나이는 스물아홉. 자신이 처해있는 전자제품 업체에서 하는 일에 대한 전망이란 캄캄한 곳에서 바늘귀보다 찾기 어려웠다.

회사를 그만둔 그는 꼬박 열 달 동안 방에 틀어박혀 공부와 코딩에만 매달렸다. 수입이 없으니 집안 사정이야 말할 것도 없었다. 그 와중에 아이까지 태어나고 보니 분유 값은커녕 한겨울 난방유를 살 돈이 없어서 보일러를 돌리지도 못했다. 찬데서 자다가 감기가 걸린 탓인지 몸이 불덩이처럼 뜨거운 아이를 데리고 병원에 다녀온 그는 간장 가게에서 간장 통 하나를 얻어, 그 통에 기름을 사다가 보일러를 돌렸단다. 10리터도 안 되는 그 기름 한통은 일주일간 세 가족을 따뜻이 해 줬단다.

60, 70년대 이야기가 아니다. 꼭 10년 전의 일이니 우리도 당시의 기억이 생생할 만큼 가까운 과거의 일이다. 이런저런 어려움을 이겨내며 가까스로 만들어낸 프로그램은 ‘준이네 비디오 대여점’이라는 비디오 대여점 프로그램. 이제 이 프로그램이 대박 복권이 되어 세 가족을 도와줄 거라 믿던 청년의 꿈이 산산조각 나는 데에는 그리 오래 걸리지 않았다.

프로그램을 PC 통신 서비스에 올려두고 판매를 기다렸지만 한 달이 지나도록 전화 한통 오질 않았다. 현장의 이해가 전혀 없이 만들어진 소프트웨어이다 보니 외면당하는 것이 당연했을 터다.

그렇다고 다시 원래의 직업으로 돌아갈 수는 없다고 결심한 청년은 하는 수 없이 자신의 프로그램을 디스켓에 담아 이력서와 함께 들고 다녔다. 어렵게 입사한 회사에서 받은 월급은 70만원. 전자회사에 다닐 때보다 훨씬 적은 돈이었지만 청년은 자신의 꿈을 놓치지 않았다.

10년 전 프로그래머가 되겠다는 꿈을 품고 세상에 도전한 빵집 개발자 양병규 씨의 이야기다. 당신의 가슴 속에는 어떠한 꿈이 있는가? 지금부터 양병규 씨가 터득해 온 꿈을 현실로 만드는 기술에 대해 알아보자.


소프트웨어 개발자에 있어서 직장생활은 어쩔 수 없이 선택해야하는 것일까? 물론 자기 사업이나 불안한 프리랜서 생활보다는 안정적인 직장생활을 원하는 사람도 있을 것이다. 하지만 직장생활을 하고 있는 개발자 중에는 그것이 좋아서라기보다는 분명한 자기 꿈이 있음에도 불구하고 현실적인 문제로 인해 어쩔 수 없이 직장생활을 하는 경우도 있다.

그런 개발자들에게 꿈을 이루기 위해 직장생활 속에서 할 수 있는 현실적인 방법 한 가지를 소개하고자 한다. 물론 대부분은 필자가 경험을 통해서 깨달은 사실이므로 누구에게나 적용될 수 있는 방법은 아닐 것이다.

2개월간 진행한 PC 원격제어 프로그램 개발 프로젝트
누구나 한번쯤 써 봤을 원격제어 프로그램. 필자도 원격제어 프로그램의 대명사인 PC 애니웨어라는 소프트웨어를 써 본적이 있다. 이 프로그램을 처음 보는 순간 상당히 신기하기도 하고 한편으로는 직접 만들어보고 싶은 충동도 느껴졌다. ‘어떤 원리로 만들어진 것일까?’ 동공이 커지고 소름이 돋고 가슴이 두근거렸다.

필자 안에 탑재되어 있는 호기심 프로세서가 작동하기 시작한 것이다.

그러고 약 2년쯤 지난 뒤에 필자는 한 업체로부터 고객 지원용 원격 제어 프로그램을 개발해 달라는 의뢰를 받았다. 한국의 업체들이 다 그렇듯이 이 업체 또한 필자에게 무리한 프로젝트 기간을 제안했다. 2개월 만에 개발과 테스트까지 마쳐달라는 이야기였다. 개발팀 없이 필자 단신으로 개발해야 하는 상황이었다.

이 글을 읽고 있는 당신은 단신으로 원격제어 프로그램을 두 달 만에 버그 없이 만들 수 있겠는가? 필자 또한 보통의 경우라면 이런 프로그램을 두 달 만에 혼자서 개발할 수는 없다.

하지만 그 프로젝트를 진행하기로 계약하고 바로 작업에 들어갔다. 프로젝트는 딱 두 달 만에 전날 끝이 났다. 이 글을 읽으며 ‘미쳤군’이라고 생각했다면 그 생각이 옳다고 말해주고 싶다. 프로젝트란 절대로 이런 식으로 해서는 안 된다. 프로젝트가 진행되는 2개월간 필자는 단 한 번도 데모 프로그램을 업체에 전달해 주지 않았다.

일을 맡긴 업체나 담당자는 아마 불안하기 짝이 없었을 것이다. 프로젝트가 끝나가야 할 시기는 다가오는데 프로그램 모양 한번 못 봤으니 말이다. 하지만 필자는 별다른 초조함이나 두려움은 없었다. 두 달 안에 프로젝트를 끝낼 자신이 있었고 그런 자신감을 가질 수 있게 해 주는 비장의 무기가 있었던 덕분이다.

결국 프로젝트 마감 하루 전날에 완성된 프로그램을 보여주고 마지막 날 테스트를 진행하였다. 버그는 발견되지 않았으며 프로젝트는 단 하루의 오차도 없이 성공하여 서비스를 시작할 수 있게 되었다.

분명히 이런 상황은 엄청난 위험을 안고 있지만 필자는 단 2개월 동안 아무 문제없이 진행을 했고 결과 역시 만족스러웠다. 지금까지 필자가 진행했던 프로젝트 중에서 방금 소개한 원격제어 프로젝트와 필자가 직접 판매했던 도움말 저작 툴인 ‘헬프워드’ 그리고 ‘빵집’도 이와 유사한 방법으로 개발되었다.

이제부터 필자가 이처럼 터무니없는 기간에 프로젝트를 완성할 수 있도록 해 주는 비장의 무기에 대해 설명해 보려고 한다.

머리로 시작하고 머리로 완성하라.
소프트웨어 개발은 컴퓨터를 이용해서 작업한다. 그래서 대부분의 개발자들은 일단 컴퓨터 앞에 앉아야 업무가 시작된다. 설계, 코딩은 물론이고 디버깅하고 테스트하는 과정까지 모두 컴퓨터가 없이는 아무것도 할 수 없다. 너무나 당연하게 생각되는 이런 모습 때문에 직장 안에서 내 컴퓨터는 내 맘대로 할 수 없는 물건이 되어 버린다.

회사 일이 바쁜데 그 와중에 자기의 꿈을 위해서 자기가 만들고 싶은 것을 자유롭게 코딩을 하기란 여간 눈치 보이는 일이 아니다. 하지만, 만약에 소프트웨어 개발의 모든 과정을 머리로만 할 수 있다면 어떨까.

직장생활을 하면서 가지게 될 수 있는 자투리 시간이란 넉넉지 않다. 하지만 무언가 생각할 수 있는 시간은 생각보다 많다. 출퇴근 시 지하철 안에서 혹은 회의 중, 식사시간에도 프로젝트가 조금 여유 있다면 회사의 프로젝트 소스코드를 펼쳐놓고 코딩을 하면서, 아니면 화면을 디자인하면서 머리로는 자기만의 소프트웨어를 개발하고 있을 수도 있다.

약간씩 생기는 여유 시간에 머리로 내가 꿈꾸는 일이나 프로젝트에 대한 것들을 생각하고, 또 이것이 1년이나 2년쯤 쌓이게 되면 상당히 많은 양의 연구가 된다.

생각하기 위해 필요한 것
그럼 어떻게 생각하면 좋을 것인가? 가이드가 없는 생각은 공상이 되어버리기 십상이다. 필자가 제안하고자 하는 생각은 바둑의 수와 같다. 제조업체에서의 공정과도 같으며 건축가에게는 시공법과도 같다. 바둑의 수, 공장의 공정, 건축의 시공법은 모두 방법이나 절차 등을 정의한 것이다.

실제로 프로 바둑 기사들은 수년전의 대국도 기억하고 있고 제조업체의 라인 장들은 수 년 전에 생산한 제품의 제작 과정을 다 기억하고 있다. 건축가들은 자신이 설계한 모든 건축물의 구조를 모조리 기억하고 있다.

그런 능력은 비단 과거를 기억하게 만든 것에 그치지 않고 현재하고 있는 일과 미래에 해야 할 일을 머리만으로 미리 시뮬레이션 해 볼 수 있는 능력으로 발전한다. 물론 소프트웨어를 개발하는 일이 꼭 그것들과 같을 수는 없다. 개발과 생산은 엄연한 차이가 있다. 하지만 개발도 결국은 기존의 경험과 지식을 토대로 새로운 방법을 고안해 내는 것에 불과하다.

개발자가 그들처럼 세월이 흘러도 자신이 개발한 소스코드를 기억하고 새로운 프로젝트를 머리로 미리 시뮬레이션 할 수 있으려면 최소한 개발 방법은 명확하게 정의되어 있어야 한다.

물론 OOP나 디자인패턴과 같이 일반화 되어있는 개발 방법론들도 매우 훌륭한 역할을 할 수 있다. 필자가 생각하기에는 그것들보다도 더 구체적으로 방법론이 정의되어 있어야 한다.

한 클래스 내에서 또 다른 클래스를 생성해서 사용하는 것을 무엇이라고 하며 변수 명을 정하는 기준이나 상속을 하는 이유 등 상당히 자세한 부분까지 방법과 기준이 정의되어 있어야 한다. 물론 그것들 모두에게 일일이 이름을 지어주기란 쉽지 않으므로 뜬 구름 잡듯이 이름 없이 기억하고 있어도 좋다.

중요한 건 그렇다는 사실 자체다. 그런 것은 평소에 열심히 실력을 갈고 닦는 수밖에 없을 것이다.

생각 시작하기
생각은 무한정 할 수 있을 것 같지만 현실 세계에서는 꼭 그렇지만은 않다. 지하철 안에서는 내릴 때가 되었는지를 자주 확인해야하며 직장에서는 열심히 생각하고 있는데 전화가 오거나 옆 사람이 말을 시킬 수도 있다. 그런 상황에서는 방금 한 생각도 잊을 수 있으며 아주 짧은 시간, 수초에 불과한 시간을 활용해서 무언가를 골똘히 생각하는 것은 어렵다.

그러므로 생각을 시작할 때는 ‘앞으로 몇 분간에 걸쳐서 무슨 생각을 하겠다’고 계획을 세우고 생각을 시작하는 것이 좋다.

생각을 구체화하는 기술
어떤 기능이나 절차, 혹은 구조를 생각할 때에는 최대한 그것과 유사한 형태를 일상에서 찾는 것이 빠르고 기억하기 쉽다. 예를 들어서 서버에서 데이터베이스를 가져오는 과정을 쌀통에서 쌀을 가져 오는 것으로 기억하고, 가져온 데이터를 분석하는 과정을 밥 짓는 과정으로 기억하고, 화면에 출력하는 과정은 밥상을 예쁘게 차리는 것으로 기억하고 사용자로부터 입력 받는 과정은 밥이니 반찬을 뜨는 과정으로 기억하자.

이런 과정에서 중요한 점이 하나있는데 실제 코딩에서의 처리 방법을 최소한 한번 이상은 생각해봐야 한다는 것이다. 그렇지 않으면 자칫 소프트웨어에서와 자신이 생각한 비유가 논리적으로 모순이 될 수도 있기 때문이다.

생각은 단어보다는 그림을 이용하는 것이 좋다. 동그라미 네모 등 평범한 모양보다는 별이나 도넛, 연필 등 생활 속에서 자주 접하는 모양이 좋다. 생각하기 좋은 것을 이용하여 비유적으로 생각하는 것이 좋으나 앞서 설명한 것처럼 실제 코딩이나 화면 디자인을 같이 병행하여 두 가지 생각을 동시에 진행하는 것이 좋다.

성과로 연결하기 위한 생각의 중단
그렇게 생각이 진행되면 어느 순간 중단해야 할 때가 온다. 그 순간이 비교적 여유 있는 순간 일 수도 있겠지만 갑작스러운 순간 일 수도 있다. 생각은 시작하는 것보다는 중단하는 것이 더 중요하다. 생각을 중단하는 것은 곧 성과를 정리하는 것과 같으므로 중단을 잘 하지 못하면 성과가 무용지물로 돌아갈 수도 있다.

생각을 중단 할 때 가장 중요한 것은 정리되는데 까지만 기억을 하고 열심히 생각했으나 정리가 잘 안 되는 내용들이나 애매해서 다시 생각해야하는 내용들은 모두 잊어야 한다. 그냥 가만히 있으면 시간이 지나서 저절로 잊혀 지길 바라는 것이 아니라 의식적으로 ‘방금 한 생각은 모두 없었던 걸로 하자’라고 정리를 해야 한다.

그래서 다음에 또 생각을 시작할 때 어디부터 시작해야 하는지를 짧은 시간에 결정할 수 있어야 한다. 생각 중단하기에서 두 번째로 중요한 것은 검토해봐야 할 부분이나 검증이 필요한 내용과 같이 어떤 결정을 내리기 위해 직접 해봐야 할 과제가 있을 때 그것들을 정리하는 일이다. 물론 시간이 없으므로 대략 제목만 빨리 정리한다.

머리 이외의 저장소에 생각 정리하기
천재가 아닌 다음에야 아무리 좋은 생각도 시간이 지나면 잊게 마련이다. 바쁜 업무와 야근에 시달리다보면 방금 전에 뭘 하려고 인터넷 익스플로러를 열었는지조차 기억나지 않는데, 잠깐씩 구체화시켜 놓은 생각 따위는 기억날 리가 없다.

필자의 경우 어느 정도 생각을 하고 정리가 되면 그 내용을 대략적으로 작은 수첩에 정리한다. 비록 작은 수첩이지만 그 기능은 마이크로소프트 오피스 2007 부럽지 않게 기능은 빵빵하다.

글씨 입력되지, 그림 그려지지, 표도 그려지지, 부팅 안 해도 되지 따지고 보면 어느 것 하나 안되는 게 없다. 한 가지 안되는 게 있다면 복사(Ctrl+C)나 붙여넣기(Ctrl+V) 기능이 없다는 것이다. 필자의 경우는 그 대안으로 작은 포스트잇을 이용한다.

물론 클립보드처럼 사본이 만들지는 것은 아니고 기록했다가 맘에 안 들어서 다시 기록하거나 혹은 한 예제를 이런 저런 방법으로 정리해 볼 때에 그 예제를 포스트잇에 기록한다. 그리고 이 내용을 다시 기록해야 할 때 포스트잇을 떼어서 필요한 부분에 옮겨 붙이는 방법으로 재활용한다. 그래서 수첩은 쫙~ 찢어 버리기 좋게 스프링이 있는 수첩을 이용한다.

그렇게 정리된 생각들이 1년이 지자면 꽤 많은 양이 된다. 서두에 밝힌 원격제어 프로젝트의 경우에는 이런 방법으로 정확히 2년을 생각했다. 화면을 캡처하는 방법과 화면 이미지를 압축하는 방법, 압축된 데이터를 소켓으로 전송하는 방법, 서버와 클라이언트를 동기화 하는 방법 등등 모든 과정을 하나씩 떼서 소제목을 붙여서 생각했다.

전체 구조도 하나의 소제목으로 생각해서 각 소 제목 간에 의존성을 없애서 한 가지 생각을 하는데 다른 부분을 참조해야하는 일이 적도록 했다. 결국 프로젝트에 사용된 2개월의 기간은 단순히 코딩만 하는 기간인 셈이었다.

생각을 할 때부터 부분씩 떼서 했으므로 코딩, 디버깅도 부분적으로 한다. OOP가 저절로 될 것은 불 보듯 훤한 일. 버그가 줄어드는 이유도 여기에 있다.

어떤가? 당신이 만들고 싶었던, 언제나 꿈꾸던 프로그램이 있다면 눈앞의 바쁜 업무나 복잡한 잔무들을 탓할 것이 아니라 조금씩 그 꿈을 구체화 시켜보고 싶지 않은가? 참 이상하게도 수첩에 모아둔 생각들은 절대로 그 주인을 배신하는 법이 없어서 시간이 지나면 지날수록 그 꿈에 점점 더 다가가도록 만들어준다.

이런 방법으로 작은 수첩하나를 가슴에 품고 자신의 생각들을 차곡차곡 쌓아가다 보면, 방금 산 복권을 양복 주머니에 넣고 희망찬 모습으로 걸어가는 모습의 복권 포스터 주인공 못지않게 희망찬 하루하루를 살 수 있을 것이다. 수첩이 하나씩 늘어갈 수록 이 복권의 당첨 확률과 일의 능률도 따라 올라간다.

생각하는데 도움을 주는 유틸리티들
역시 가장 좋은 방법은 눈으로 볼 수 있는 것이 가장 좋다. 앞서 예를 들었던 쌀통에서 쌀을 퍼 와서 밥을 짓는 과정을 보자. 사무실 파티션에 예쁜 주방을 배경으로 자신이 좋아하는 연예인이 있는 사진과 멋지게 차려진 식탁 사진 등 자신이 생각하고 있는 내용의 그림이나 사진을 붙여놓고 틈만 나면 그 생각을 해보자. 아마도 많은 도움이 될 것이다.

컴퓨터의 바탕화면도 상당히 많은 도움이 될 수 있다. 벽의 사진이나 컴퓨터의 바탕화면은 전체적인 구조나 일부분의 구조를 반복적으로 생각하여 완벽한 모습을 갖추게 하는데 많은 도움이 된다. <화면 1>과 <화면 2>는 현재 필자가 사용하고 있는 두 개의 바탕화면이다. 노트북에 듀얼모니터를 쓰고 있는데 각 모니터 마다 다른 바탕화면을 쓴다.

<화면 1> 필자가 사용하고 있는 바탕화면-1


<화면 2> 필자가 사용하고 있는 바탕화면-2


두 개의 바탕화면은 서로 밀접한 관계가 있다. 바닷가에 있는 키트와 그 위에 있는 건물들, 또 한 화면에는 금방이라도 음악소리가 흘러 나올듯한 턴테이블 돌아가는 모습. 이 턴테이블은 다른 화면에 있는 건물 안에 있다. 과연 필자는 어떤 상상을 하고 있을까 독자 여러분이 알아 맞혀 보는 것도 좋을 듯하다.

참고로 인터넷에서 필자의 이름으로 검색해보면 과거의 노트북 배경화면을 찾아 볼 수 있다. 그 화면에는 화면 중앙에 키트만 있었다. 지금은 그 생각이 확장된 상태이다.

현실에서 벗어나서 꿈을 이루고 싶다면 생각부터 하자
지면 관계상 딱 한 가지 ‘생각하자’만 정리해봤다. 하지만 서두에서 밝힌 것처럼 OOP 등 기술적인 실력을 쌓고, 열심히 공부하고 작은 것부터 하나씩 생각부터 하는 습관을 기르는 것이 중요하다. 그렇지 않으면 아무리 좋은 생각이라고 구체화되기보다는 공상이 되게 마련이다.

아무리 어려운 기술이라도 그것을 자신의 것으로 만드는 대에는 대략 3년 정도면 충분하다. 필자가 과거에 했던 헬프워드와 원격제어 프로젝트는 모두 2년 정도 생각한 후 작업에 착수한 경우다.

약 2~3개월 정도마다 생각한 것을 정리하기 위해 간단하게 샘플을 만들어 보고 테스트를 해보는 작업을 했었다. 그런 경험으로 봤을 때 대략 2년 정도 생각하면 물건 하나 만들 수 있다. 도합 5년이면 충분하다. 해 볼만 하지 않은가? @

'Computing' 카테고리의 다른 글

훌륭한 프로그래머의 딜레마  (0) 2008.09.19
한국 SW는 레드오션인가?  (0) 2008.09.08
Filezilla Server 한글문제 해결  (0) 2008.05.27
메모리 누수 디버깅  (0) 2007.10.18
메모리 할당한 부분 찾기  (0) 2007.10.18

Elliptic curve cryptography (ECC)

요즘에 알바를 살짝 하고 있는데.. 이게 좀 골때리는 내용이다..
Elliptic curve cryptography (ECC) 라고 하는 분야인데.. 암호학 쪽이다.

최근 들어서 뜨고 있는 알고리즘같은데... 내용이 꽤 어렵다.
private key를 알면 public key를 생성할 수 있고
public key로는 private key를 쉽게 알아낼 수 없다. (이게 핵심)

이 ECC는 수학적인 graph 모델을 사용해서 양쪽 key를 생성할수
있도록 하고 있다.  그러나 RSA와는 다르게 message를 encryption하는
방식은 제공하고 있지 않다. (거의 확실한듯...)

그래프에서 base point가 존재하고 private point
(정확하게는 point가 아니라 distance정도..)를 찍으면 public point를
계산해낼수있다.  하지만 public point와 base point만으로는 private point를
역으로 계산해내기 어렵다. (불가능에 가깝다고 봐야겠지...)

뭐 여러모로 쓸모있는 알고리즘이 될듯 싶지만... 하드웨어로 구현하기엔
만만치 않아보인다. ㅎㅎㅎ

http://en.wikipedia.org/wiki/Elliptic_curve_cryptography

Digital Signatures
    * ECDSA: Elliptic Curve Digital Signature Algorithm
    * ECPVS: Elliptic Curve Pintsov Vanstone Signatures
    * ECNR: Elliptic Curve Nyberg Rueppel

Key Agreement
    * ECMQV: Elliptic Curve Menezes-Qu-Vanstone
    * ECDH: Elliptic Curve Diffie-Hellman

Encryption
    * ECIES: Elliptic Curve Integrated Encryption Standard


'Computing' 카테고리의 다른 글

Ubiquitous 연구 동향  (0) 2007.05.30
안티스파이웨어 랭킹 리뷰  (0) 2007.05.22
samba에서 user  (0) 2007.05.17
zeroboard 설치  (0) 2007.05.11
Ubuntu 7.04 server 설치중...  (0) 2007.05.11
prev 1 next