낙타는
위기를 맞으면
술수를 쓰지 않고 도전한다.
정공법으로 승부수를 던지는 것이다.
땡볕에 쉴 그늘도 없을 때 낙타는 오히려
얼굴을 햇볕 쪽으로 마주 향한다. 햇볕을 피하려
등을 돌리면 몸통의 넓은 부위가 뜨거워지지만
마주 보면 얼굴은 햇볕을 받더라도 몸통
부위에는 그늘이 만들어져서 어려움은
오히려 줄어들기 때문이다.
- 최형선의《낙타는 왜 사막으로 갔을까》중에서 -
* 우리도 이따금 사막을 헤맵니다.
모래는 뜨겁고 땡볕은 더 뜨겁습니다.
몸을 돌려 땡볕을 피하느냐, 아니면 낙타처럼
정면으로 땡볕에 맞서느냐, 선택의 기로입니다.
정면으로 도전하면 새로운 길이 열립니다.
사막도 아름답습니다.
Modern Javascript : web2.0과 함께 자바스크립트 개발에 초점이 맞춰졌다. 다양한 OpenAPI 개발환경이 구축되고, 다양한 모바일 디바이스에서 HTML5로 Application을 개발할 수 있기 때문에 브라우저들은 HTML5기술을 수용하기 위해 경쟁 중이며, 다양한 자바스크립트 라이브러리들이 나오고 개발되어지고 있다. HTML5는 기존의 문서기반 정보를 탐색하기위한 방식에 불과했다면, HTML웹환경에서 Application platform을 그대로 가지게 된 것이고 API를 가지고 HTML5기능을 접목시키면 기존에 데스크탑에 있었던 application을 Web에서 그대로 구현 가능해진 것이다.
JavaScript + Html5 + Ideas, Libraries, Tool, API = Marketplace
2. Javascript ▷ zepto.js 는 모바일을 위한 자바스크립트 라이브러리. jQuery 와 호환되는 문법을 사용하지만 jQuery보다 가벼운 용량이어서 용량에 대한 부담을 줄여준다. ▷ 서버사이드 자바스크립트 node.js는 구굴크롬의 V8엔진을 사용하며, 대용량 서버에 적용할수록 기존 서버에 비해 좋은 효율을 보여준다. 자바스크립트로 서버의 모든 기능들을 활용할 수 있도록 계속 개발되어지고 있다. ▷ 브라우저가 아닌 서버/데스크탑 어플을 자바스크립트로 작성하기 위한 Common.js 란 스펙이 있는데, 이는 node.js를 따르고 있고 그 외에도 CommonJS를 통한 많은 시도들이 되어지고 있다. ▷ CoffeeScript 자바스크립트로 컴파일되는 간단한 언어 .: 나 { 가 없는 영어와 같은 간단한 문법을 사용하는데, 문법이 간결해지고 더 빠르게 실행될 수 있도록 컴파일 해주기 때문에 익숙해지면 굉장히 유용하다.
3. Responsive Web Design ▷ 다양한 사이즈의 해상도에 자동으로 대응하기 위한 웹페이지 제작 방법 - Screen Size, Platform, Orientation에 반응
4. Web App Stores ▷ Crome Webstore https://chrome.google.com/webstore : 구글에서 payment 부분을 개발해놓았기 때문에 웹앱 개발자들이 자신이 만든 앱을 쉽게 팔아 수직을 얻을 수 있는 환경이 생겼다는 점에서 큰 의미 ▷ GetJar http://www.getjar.com/ : 멀티플랫폼 앱스토어, 모든 플랫폼의 앱을 동시에 취급,판매한다. Getjar 는 사용자의 단말정보를 저장하여 사용자에게 필요한 앱만을 리스트에 보여주어 사용자가 신경쓰지 않고 편하게 사용 할 수 있다.
5. Hybrid App ▷ Native App 과 WebApp의 기술을 합친 형태. ▷ 외형은 네이티브, 내용은 웹앱으로 만든것을 말한다. ▷ 멀티플렛폼이 가능한 장점이 있으나, 네이티브 대비 웹부분의 속도가 문제가 되기도 한다. ▷ Hybrid App의 범위 : 서버에 접속해서 웹앱을 실행하는 방식부터 NativeApp내에서 약간의 WebView를 사용하는 방식까지 해당되는 범위가 넓고, 업데이트가 잦은 부분은 웹으로 구현하면 관리에 용이하다. ▷ Hybrid App 개발방법. : 작업은 웹앱으로 모두 마친 뒤에 Appspresso,PhoneGap, Titanium같은 프레임웍으로 감싸준다. 프레임웍에서 Device 기능을 컨트롤 할 수 있는 기능을 제공하여 이용할 수 있다.
2011년 3월. 요근래 드는 궁금증들. 스마트폰, 스마트패드 많이들 얘기하지만, 정말 사용자와 요구수요자의 차이는 어느 정도일까? 막상 사지는 않으면서 이미 만들어낸 여론때문에 뭔가 써봐야 할거 같고, 하나쯤은 있어야 할꺼 같은 심리인가? 모바일웹, 모바일앱의 차이를 아는 사람은 얼마나 될가? 웹 표준화를 얘기하지만, 과연 이해할 수 있을까? 네이버 뉴스벤더들이 다 외부사이트들이라서 네이버에서 뉴스 클릭시 외부사이트로 이동. 표준화가 되어 있지 않고 난잡한 광고와 뭔가 프로그램을 설치하려는 많은 행위들에 의해 스마트폰이나 스마트패드에서 끊김이 생긴다. 사용이 어렵다. 그런 뉴스만 좋아하는 이용자라면 스마트패드를 좋아할까? 의문스럽다. 스마트열풍으로 인해 생각지 못했던 소비가 많이 생겨난 것도 사실이다. 그런 것들이 가게 경제에 미치는 영향은? 어제 저녁 뉴스에도 나왔지만, 스마트폰 통신료가 비싸다. 비싼 줄 알면서 다 구입하고, 지금 그런 말을 뉴스에서 떠드는건 뭘 바라는걸까? 난 다만 통신료가 가변적으로 형성되서 가격이 내려가길 바랄뿐이다. 하지만, 더 큰 통신료나 뭔가 소비를 위해 미리 밑밥을 깔고있는건 아닐까 라는 생각이 없어지지 않는다.
맥북사용자도 심심치 않게 볼수 있게 됐는데,이미 트렌드가 된지 오래다. 한순간에 치기에 의해서 과소비를 하지 않기를 바랄뿐.
모바일웹을 모바일앱으로 바꿀수 있는 프로그램들이 있지만, 아이폰용은 맥북에서만 사용가능하다. 결국 맥북이 대세인가? 윈도우는 맥을 수용할수 없고, 맥은 윈도우도 수용이 가능하니 달리 방법이 없지 않겠는가? 특히 신규 노트북 구매자라면. 노트북만 사용한지 2006년부터니까 한참 됐구나.
순간의 분위기에 휩쓸리기 보다는 나에게 필요한게 뭔지, 내 생활패턴이 어떤지 먼저 알아야 하지 않을까?
2011.03.26~03.27 강원도 속초 대포항을 다녀왔다. 토요일 슈슈가 근무여서 아침에 박물관에 출근시키고, 집에서 쉬다가 올초부터 생각했던 동해에 대한 열망에 속초행을 결심하게 됐다. 오전에 국립민속박물관에서 지난번에 복원한 "오촌댁"도 구경하고. 국립민속박물관의 오전은 외국인을 발디딜곳이 없구나. 외국같아.
오후 6시 민속박물관에서 슈슈를 픽업하여, 종로 2가에서 버거킹 햄버거 구매. 참고로 난 네비게이션이 없다. 덕분에 을지로를 돌아 왕십리를 지나서 강변북로타고 천호대교로. 토요일 저녁이라 차 엄청 막힌다. 천호대교에서 서울춘천간 고속도로로 이동. 이제 미시령 터널도 개통이 되어 서울에서 속초까지 엄청 빨라졌다. 12년 전에 속초를 갔었는데, 머구리들과 함께. 춘천고속도로를 진입하니 엄청 어둡다. 아니나 다를까 견인차가 막 달리더니 얼마 지나지않아 로드킬을 목격했다. 뭔가 큰 동물을 치어서 차가 한대 서있고 그 옆에 견인차들이 있었는데, 얼핏 봤지만 뭔가 큰 노루같은... 에고~ 밤에 어두운 고속도로를 달리는건 쉽지 않은 일이다. 특히 산간도로는 더욱더~ 새 도로라서인가 금방 동홍천(춘천간고속도로 종점, 곧 양양까지 개통예정)을 지났다. 동홍천을 나오니 국도 분위기의 고속도로 46번 도로를 타고 가는데, 중간중간 신호가 있어서 나름 시간이 걸린다. 12선녀탕 인근을 지나 한계령과 미시령 사이. 한계령은 양양가는길이고, 속초는 미시령이다. 옛 미시령 도로는 폐쇄됐고, 미시령 터널을 통과한다. 통행료 3000원,. 현금 준비하자. 긴 미시령 터널을 지나면 울산바위전망대 근처인데, 속초의 야경이 한눈에 들어온다. 감탄의 아우성을 지를 준비 하시고 미시령 터널을 나가시기 바란다. 우린 밤 9시 10분경 통과했는데, 아이폰 사진으로는 담을 수 없었다. 한참을 내리막을 가야 하기때문에 기어를 1단에 놓고 내려갔다. 그렇게 속초외곽을 달려 대포항에 도착하는가 했는데, 외옹치항으로 돌아들어가는 길을 네이버지도가 알려준다. 그냥 대포항으로 직진할껄. 외옹치항으로 들어가는 길 진입로에 펜션및 모텔이 있어서 여기에서 숙박을 해결해야 겠다는생각. 대포항과 얼마 멀지 않아서 방을 잡고 걸어서 가도 될 정도이다. 다음엔 꼭 그렇게. 외옹치에서 대포항으로 진입하는데, 길이 좁아서 바로 나와버렸다. 대포항 끝방향이었는데, 뭔가 생선과 조개를 구워먹는 포장마차가 좋아보였다. 다음엔 꼭 먹으리. 예전 대포항 1주차장은 공사중이었는데, 그 옆에 1주차장이 새로 있으니 일단 파킹. 대포항으로 들어가는 입구에 새우튀김집이 즐비하다. 조금들어가면 줄서서 기다리는 새우튀김집이 있는데, 아마 이집이 맛집인가보다. 튀김은 조명아래에서 더욱 맛있어 보인다. 포장을하면 종이컵하나와 포장간장을 주기때문에 일단 들어갈때 작은 새우튀김으로 한봉지 사서 먹으면서 다니는것도 좋을거 같다. 차 때문에 회집은 들어가지 않고 구경만 쭉 하고, 비단멍게, 새우튀김 큰거, 오징어 순대 하나를 사서 숙소를 찾아서 출발. 1 주차장 맡은편에 편의점이 있어서 미리 먹을거 좀 사갔다. 외옹치항 입구쯤에 있는 숙소에 여정을 풀고 속초에서의 하루를 마쳤다.
다음날 아침(2011.03.27). 일어나자마자 씻고 나서는데, 설악의 설경이 눈에 들어오는 것이 아닌가. 병풍을 두른것 처럼 속초를 감싸안고 있는 설악이 저 멀리 보이는데, 지난 밤 지나올때는 몰랐다.
일단 인근의 속초 해수욕장을 들러 푸른바다와 모래사장 한번 밟아 주시고. 인증샷! 인근의 진전사지3층석탑과 진전사부도를 보러 가기로 했다. 각각 국보, 보물로 지정. 물치항인근을 지나 올라가는데, 군부대가 엄청 크게 있었다. 신기하다. 한참을 올라가다보니 진전사지3층석탑을 볼수 있었다. 역시 다녀보면 옛 절터는 정말 풍수지리가 좋다. 지금은 차로 올수 있지만 에전은 오솔길이지 않았을까? 여기 터를 잡은 걸보면 옛선인들의 능력이 참 대단함을 느낀다. 그리고, 조금 더 올라가면 전진서부도가 있는데, 진전사를 복원하고 있는 중이더라. 왠 하얀개가 와서 반기는 바람에 옷은 흙으로 범범. ㅋㅋ 아직 어린 개같던데 심심한가보다.
다시 미시령으로 향하는 중 대포항 입구의 대게사랑에서 대게해장국과 물회를 먹고. 미시령터널로 이동. 중간에 종합관광안내소에서 안내지도물을 챙겼다.
역시나 가는길은 그렇게 멀게 느껴지지않았다. 미시령을 지나, 백담사 인근을 지나고. 함참을 다가보니 큰 강이 나오면서 38선휴개소라는게 있길래 쉬었더니, 소양강이란다. 정말 크구나하는 생각과 소양강 처녀는 이제 어딨나?
인제를 지나고, 춘천서울간 고속도로 진입. 서울까지는 쭉쭉 가더라. 서울도착 2시. 속초가는게 남해가는것 보다 훨씬 가깝다. 이제 남해를 가야할 차례이다.
소프트웨어 개발의 모든 것(김익환,전규현 지음. 페가수스)를 읽고 나서 중요한 몇 구절을 남겨본다.
요구사항의 중요성 소프트웨어 시스템 구축에서 가장 여려운 부분은 무엇을 구축할 것인지를 정확하게 판단하는 것이다. 그러나. 구현을 시작하기 전에 요구사항을 완벽하게 파악하는 것이 불가능한 경우가 많다. 그렇다고 해서 요구사항 개발에 소홀해서는 안 된다. 시간이 허락하는 한 최대한 많은 정보를 파악하는 것이 좋다. 잘못된 요구사항은 많은 재작업 비용을 필요로 한다. 재작업 비용은 일반적으로 전체 개발 비용의 30~50%에 이르는 것으로 알려져 있다. 요구사항 오류로 인한 재작업 비용은 전체 재작업 비용의 70~85%에 이른다. 잘못된 요구사항, 부족한 요구사항은 일정을 지연시키며 많은 추가 비용을 발생시킨다. 완벽하게 상세한 요구사항이 가장 좋은 요구사항은 아니다. 요구사항은 이해하기 쉽게 간결함을 추구해야 한다. 간결하지만 충분히 설계, 구현할 수 있어야 한다. 그리고 요구사항 문서는 모든 관련자가 충분히 검토해야 한다. 요구사항 오류는 개발 단계가 지나가면 지나갈수록 그 수정비용이 기하급수로 증가한다. 유지보수 단계에서 비용이 더 드는 것으로 알려져 있다. 충분히 검토하여 오류가 없는 요구사항을 만드는 것이 프로젝트를 성공으로 이끄는데 가장 필요한 핵심이다.
코딩자세 : 소프트웨어를 잘 구현하기 위해서는 코딩을 함에 있어 반드시 지켜야 할 것들이 있다. * 회사의 코딩표준을 철저히 지켜야 한다. * 버그가 발견되면 그 즉시 버그를 고쳐라. * 발견된 버그가 재현이 안 된다고 해서 버그가 사라진 것이 아니다. * 문제 없이 작동하고 있는 코드를 괜히 정리하려고 하지 마라. * 문제가 해결될 때까지 이렇게 저렇게 마구 고치지 마라. * 코딩 작업을 작게 나누어서 코딩, 빌드, 테스트를 자주 반복하라. * 중요하지 않은 버그는 하나도 없다.
회사의 코딩표준을 지켜야 하는 이유. * 소스코드의 작성법을 통일하여 개발자들끼리 서로 코드를 더 쉽게 이해할 수 있게 한다. * 개발자가 바뀌어도 빠른 시간 안에 소스코드를 파악 할 수 있게 한다. * 흔히 저지르기 쉬운 사소한 실수를 방지하여 제품의 품질을 높인다.
품질관리 소프트웨어프로젝트에서 품질은 소프트웨어가 얼마나 요구사항을 잘 만족시키고 있는가의 정도이다. 품질은 전적으로 테스트에만 의존하는 것이 아니다. 잘 만들어진 프로젝트 계획, 잘 분석된 요구사항, 각 단계의 철저한 리뷰, 체계적인 테스트 등 프로젝트 전 과정에 걸친 일련의 활동들이 모여서 제품의 품질을 보장하게 된다. 많은 개발자들이 소프트웨어의 품질에 큰 관심을 두지 않는다. 현재 프로젝트를 끝내고 빨리 새로운 프로젝트를 하고 싶어한다. 현재의 문제는 유지보수에서 해결할 수 있을 것으로 생각하기도 한다. 이러한 생각은 제품의 품질을 떨어뜨리고, 제품을 제 때에 출시하지 못하게 만들기도 한다. 품질을 포기하고 제때 출시된 제품은 정시 출시에 대한 의미조차 없다. 고객들은 제품의 품질을 계속 기억할 것이고, 추후 더 나은 제품에 대한 기억이 사라지지 않을 것이다. 일반적으로 소프트웨어의 유지보수에 개발 지용의 2~5배가 지불된다고 알려져 있다. 최초에 낮은 품질로 출시된 제품은 유지보수 비용을 지속적으로 증가시킨다. 유지보수 비용을 간과하면 장기적으로 제품의 수익성에 심각한 저하를 가져올 수 있다. 그럼에도 불구하고 소프트웨어 개발 시에 유지보수에 대해 신경을 쓰지 못하는 경우로 다음과 같은 것들이 있다.
* 당장 프로젝트가 발등에 떨어진 불이라서 유지보수에 대해서는 신경 쓸 겨를이 없다. * 유지보수는 다른 개발팀이 맡을 것이므로 신경 쓰지 않는다. * 경험이 별로 없어서 유지보수에 많은 비용이 드는지 몰랐다. * 유지보수에 비용이 얼마나 드는지 정확하게 따져본 적이 없다.
제품의 품질을 유지보수 기간으로 넘길 것이 아니고, 지금 바로 품질에 대해서 신경을 쓰는 것이 경제적으로 더 바람직하다.
리스크 관리 리스크 계획 중 개발자가 퇴사할 징후가 보일때 다음과 같은 대응책을 마련할 수있다. * 개발자가 퇴사하지 않도록 노력한다. * 개발자가 퇴사하더라도 보충할 개발자를 미리 사내에서 물색해 놓는다. * 사내에서 보충할 개발자를 찾지 못하면, 외부 채용 활동의 준비 단계를 해 놓는다. 즉, 채용공지를 하고 이력서를 분석하여 채용자 후보를 미리 물색해 놓는다. * 해당 개발자이 모듈을 다른 개발자와 많은 부분 공유하도록 계획한다. * 아예 해당 개발자를 프로젝트에서 제외하고 진행한다.
동기 유발 요인 : 프로젝트에서 개발자의 동기를 유발하는 요인에는 다음과 같은 것들이 있다. * 목표설정, 성취감, 성장가능성, 개인생활의 보장, 포상.
프로젝트 팀이 하는 작업 리스트 * SRS 작성 및 검토 * 소프트웨어 아키텍처 설계 논의 * 소프트웨어 컴포넌트와 인터페이스 논의 * 소프트웨어 설계 리뷰 * 소스코드 리뷰 * 결함 추척 및 해결 * 중요 이슈 논의 * 유지보수
성공하는 팀의 특징 * 훌륭한 기술리더가 있다. * 도전적이고 실천가능한 목표와 비전을 공유하고 있다. * 실력 있고 헌신적인 팀원들로 구성되어 있다. * 팀원들간에 서로 신뢰한다. * 팀원들간에 의사소통이 원활하다. * 팀이 적절한 권한과 자율성이 있다. * 팀워크를 유지하기에 알맞은 팀이다.
실패하는 팀 * 비전이 공유되어 있지 않다. * 팀원들간에 서로 신뢰하지 않는다. * 팀원들 간 의사소통이 원활하지 않다. * 문제 팀원 방치.
필자의 경험에 의하면 프로젝트를 망치는 길은 지뢰밭과 같이 많아도 성공하기 위한 비법은 없다. 기본에 충실하고 기초와 문화가 각각 개발자들 몸에 배어서앞에서 언급된 여러 활동들이 종합적으로 자연스럽게 이루어 질 때 소프트웨어 프로젝트 성공이 좀더 가까워 질 것이다.
개발자들은 가장 먼저 * SRS를 작성해야 한다고 생각하고, * SRS를 작성하면서 모든 관련자와 철저히 리뷰를 하고, * 프로젝트 관리자는 개발자들과 함께 1,2일 단위의 상세 일정을 작성하고, * 테스트팀은 SRS를 보고 테스트 Suite를 만들기 시작하고, * 개발 리더들은 화이트보드나 종이를 펼쳐놓고 아키텍처에 대해 토론을 하며, * 구현 시 모든 소스코드는 당연히 리뷰를 하고, * 개발자는 매일 스스로 일정을 업데이트하고, * 소스코드 작성은 일일빌드가 깨지지 않으면서 이루어지며, * 소스코드관리시스템과 버그관리시스템을 효과적으로 사용하며, * 알파, 베타 단계 별로 모든 프로젝트 관련자들이 유기적으로 움직이며, * 일정에 맞춰 완성도 있는 품질의 제품을 출시한다.
위와 같은 활동들이 당연하다고 생각되고 몸에 배어야 한다. 이러한 것들을 규칙만으로 통제를 해서는 달성하기 어렵고 한꺼번에 모두 다 습득하기도 어렵다. 하나씩 익혀서 몸에 배었을 때 소프트웨어 프로젝트를 성공하는 원리가 보이기 시작하고, 좋은 제품을 만들 수 있을 것이다.
당신 마음 속의 해결되지 않은 모든 것에 대해 인내하라. 잠긴 방처럼, 외국어로 씌어진 책처럼 의문 자체를 사랑하려 하라. 답을 구하지 말라. 당신이 답대로 살 수 없겠기에 답은 올 수도 없다. 요지는 모든 것을 살아내는 것이다. 지금은 의문을 품고 살라. 그러다 보면 자기도 모르게 서서히, 답 속에 살게 될 날이 올 것이다.
- 라이너 마리아 릴케의《젊은 시인에게 보내는 편지》중에서 -
* 눈앞에 펼쳐진 일들이 도무지 이해가 안 될 때가 있습니다. 감정이 앞서고 누군가에게 물어서라도 해답을 알고 싶죠. 그러나 이제는 좋은 것이든, 나쁜 것이든 열심히 살아내야 하는 것임을 알아갑니다. 인내하며, 긍정할 것을 믿으며 그렇게 기다려갈 겁니다.
(0) 
(0)
