'분류 전체보기'에 해당되는 글 1246건

MOSS 2007 기반으로 개발을 하거나, 기타 웹 어플리케이션을 만들면 꼭 들어가는 코드가 바로 JavaScript 이다.특히나 동적 웹을 구현을 하려면 특히 자주 활용하게 된다.
하지만, 그 Javascript의 동작이 올바른지 올바르지 않은지에 대한 판단을 하는 모습을 보면, 상당히 원시적으로 하는 경우를 많이 보게 된다. 일단 동작하는 화면을 보고, 그 결과물을 보고 현재 구성된 Javascript를 보고, 일부 수정하거나 MessageBox를 띄우고 결과물 보고..
이렇게 Javascript를 수정하는 경우 경험이 많은 개발자야 짐작과 동시에 문제점을 찾기라도 하지만, 웹 개발에 익숙치 않거나, 아예 문법 오류로 인해 Javascript 자체가 실행 안된 경우라면, 거의 좌절이다. 게다가, 웹 페이지 내에 직접 박아 넣은 Javascript라면 그럭저럭 짐작이라도 하는데, 다른 Javascript 소스를 include 한 경우라면, 이야기가 점점 꼬이기 시작한다. 뭐가 문제인지 짐작도 되지 않는다.
다행이, FireFox나 Google Chrome과 같은 웹브라우저에서는 자체적으로 혹은 외부 플러그인을 통해 디버깅이 가능하며 그 기능은 상상을 초월한다. 훌륭하다 못해 멋지기 까지 할 정도로 정확하게 값을 뽑아오며, 정확히 어느 파일의 어느 위치에 오류가 있는지 알려주며,  현재 상태 값을 보면서 정확한 오류 내용을 파악할 수 있다.

그러나, 우리나라 환경에서 개발하는, 그것도 새로 개발도 아니고, 기존 코드를 수정하는 입장인 경우, Javascript를 까보면, FireFox나, Chrome에서는 동작하지도 않는 경우가 허다하다. 특히나 ActiveX 같은 X 같은 플러그인 꽂은 곳은 아예 Gothem! 레벨. 결국 IE로 띄워 뭔가 디버깅을 시도해야 된다는 슬픈 일이 닥친다.

하지만, MS 기반, IE 온리 개발하는 곳에서는 일반적으로 Visual Studio를 이용한 .NET 개발이 주로 발생되는데, 이 경우 라면 해피하다. 여기서는 이 해피한 경우에 대처하는 좋은 방법을 알려드리려 한다.

1. IE 설정.

IE가 6.0으로 쫑 날 줄 알았으나, FireFox와 Chrome, 사파리 등의 웹 브라우저의 등장으로 위기감의 고조와 함께, 그 동안 계속되었던 6.0의 버그, 속도 문제등의 이유로 결국 7.0을 내 놓았다. 그러나, 7.0을 탑재한 Vista의 처절한 실패로 인해 Windos 7과 함께, 등장한 8.0 으로 업그레이드 되었다.

즉, 이제 IE는 6.0, 7.0, 8.0 이 혼재된 모습을 보이기 시작했다.

일단, 8.0을 기준으로 설명하며, 7,0이나, 6.0은 다른 곳을 찾아보거나, 짐작해서 옵션을 변경해야 할 것 같다.
IE를 실행 한 뒤, 인터넷 옵션을 띄우고, 인터넷 옵션에서 “고급”탭을 클릭해서 연다.

여러가지의 항목들 중 “스크립트 디버깅 사용 안함(기타)”, “스크립트 디버깅 사용 안함(Internet Explorer)”에 체크 되어 있는 것을 끄도록 한다.

2. 에러 페이지까지 가기.

Visual Studio가 깔린 PC에서 IE를 통해 먼저 에러가 발생하는 페이지까지 접근하도록 한다. 지금 필자에게는 마땅히 띄울 UI가 담긴 Page가 없으므로 에러가 발생하는 페이지를 띄우도록 할 것이다.

에러가 발생했다. 그러면 에러 페이지가 뜨는데, 여기서 체크 박스들을 없애고 “예(Y)”를 클릭한다.

위의 팝업이 안뜨면 브라우저의 왼쪽 아래에 있는 경고 표시를 클릭하면 볼 수 있다.

일단 “예(Y)”를 하면, IE에 등록된 Javascript 디버거들의 목록이 뜬다.

현재 필자는 변변한 디버거라고는 Visual Studio 정도지만, Office 2003~2007 을 전체설치하는 경우 Javascript 디버거가 별도로 설치될 수 있다. 또는 3rd Party 제품이 뜰 수도 있다. 다른 제품들은 각 제품의 설명을 보도록 하고, 여기서는 Visual Studio로 선택하도록 한다.

혹여 Visual Studio일지라도 이미 떠 있는 Visual Studio를 선택할 수 있는데, 가급적이면, 새 인스턴스 Visual Studio를 선택하도록 한다.

3. Visual Studio 에서 디버깅.

“새 인스턴스 Visual Studio XXXX”를 선택하고 “Y”를 클릭하면 Visual Studio가 뜬다. 이 때 디버깅을 하는 것은 iexplore.exe 자체. 무슨 프로세스를 걸던 간에 일단 띄워보면, 정확한 오류 메시지를 알려준다.

 
오류 보시고, 이번엔 “중단(B)” 버튼을 클릭한다.
그러면 소스가 보일 것이고, 어디서 오류가 났는지 볼 수 있다.

왼편에는 지금 오류가 난 페이지와 관련된 각종 Javascript 소스들과 Html 소스들이 쭉 나래비가 펼쳐질 것이고,
오른편에는 해당되는 소스가 보인다. 여기서 부터는 Visual Studio 만의 디버그 UI를 활용함으로써 충분한 기능을 발휘할 수 있다.

소스 자체에서 커서를 위로 올리면 인텔리센스의 또다른 기능인, 변수 값들을 볼 수 있으며, 조사식, 콜스택, 지역 변수 값들을 모두 보면서 진행할 수 있다. 한단계씩 실행할 수도 있다.

4. 고급 디버깅 - 중단점

꼭 오류가 나기 이전 단계에서 디버그를 시작하고 싶은 경우에는 중단점을 이용하면 된다.
자신이 원하는 곳에다 중단점을 걸고 진행하면 되는데, 이를 위해서는 항상 동일한 위치에서 오류가 발생해야 쉽게 적용 가능하다. 방법은 아래와 같다.

1. 자신이 원하는 위치에 중단점을 건다.(Visual Studio 버전에 따라 중단점을 걸게 되는 조건이 조금씩 다르다.)
  
2. 디버그를 끝까지 진행시킨다.(디버그에서 계속 버튼 – 디버깅이 멈춰진 곳에서 계속 진행하도록 하는 버튼)을 누르거나 선택하면 된다.)
   
3. 경고창으로 뜨는 메시지에 예외를 iexplore로 보내겠다는 메시지에 예(Y)를 선택한다.
  
4. 브라우저로 돌아와서, 다시 Refresh를 한다.

5. 그러면 자신이 중단점을 건 위치에 커서가 멈춰 있게 된다.
  

5. 줄이며.

사실 Visual Studio의 기능은 막강한 편이다. 최초 5.0, 6.0 같은 경우 Windows 기반 Application 제작에 비중이 실렸다면, Visual Studio 2003 부터 조금씩 조금씩 웹 쪽에 대한 기능이 실리기 시작했다. 특히 Visual Studio 2005 부터는 ASP 개발에 있어 그 편리성은 혁신에 가깝게 진행되었다.

최소한 위의 디버그 모드에 대한 기능은 2003보다는 2005가, 2005 보다는 2008에서 더 정확하게 확실하게 동작함을 알 수 있다. 다소 툴이 무거워 쉽게 접근하는건 무리겠지만, 웹 표준에 제대로 맞지도 않는 웹 개발을 특히나 유지보수를 하려고 한다면, IE를 쓰고, Visual Studio를 쓰는 강수를 노려야 되니… 뭐 억지로라도 쓰도록 한다.
일단 쓸 수 있는 환경(CPU나 RAM이나.. 개발자 PC의 성능 문제가 대부분)이라면, 나름 장점이 많은 도구이니, 활용하는데 큰 무리가 없으리라 본다.

UPDATE:

저 위의 방법은 Javascript가 오류가 난다는 가정하에서 하나씩 거는 방법이다. 만일 Javascript의 오류가 나지 않을때, 디버그를 걸어 확인하고 싶을 때까 있다.

그런 경우에는 소스 내에 "debugger;" 라는 줄을 추가하면 된다.

그러면 debugger 라고 적힌 줄에서 에러가 난 것 처럼 표시되고, 위의 방법대로 진행이 가능하다.

블로그 내 필자를 관리하는 방법을 설명합니다.

일단 scmaid.org의 관리자 페이지에 들어갑니다.

들어가는 방법은 아래 메뉴에 표시된 위치를 클릭하면 들어가집니다.

다음은, 관리자 화면으로 넘어갈때, ID/Password를 묻는데, (안 묻는다면 일단 Logout을 하시고 다시 들어기시기 바랍니다.) 그 안에 관리자 아이디와 암호를 넣습니다.
(아이디와 암호 부분은 이정호 선임을 통해 전달 받거나 하시면 됩니다.)

이제 관리자 화면을 볼 수 있는데, 그 중, 네트워크 –> 필진 목록을 클릭해주세요.

(만일 IE 8.0에서 메뉴가 제대로 보이지 않으면 주소 줄 옆의 호환성 보기 아이콘( )을 클릭하세요!)

필진 목록을 클릭하면 필진 목록이 보이는데, 여기에 모든 기능이 담겨 있습니다.

직접 페이지를 띄워서 테스트를 하셔도 되고, 화면을 보시면서 익혀도 됩니다.

1. 필진 초대하기.

팀 블로그이기 때문에, 필자가 1인이지 않습니다. 여러 사람이 동시에 글을 올릴 수 있습니다. 그러나 공개 게시판과 같은 형식이 아니기 때문에, 특정 인에 대해서만 필진으로 등록하게 됩니다. 여기서 중요한 것은 필진의 이메일 주소가 반드시 필요합니다. 또한 이메일 주소 자체가 ID이기 때문에, 반드시 올바른 이메일 주소여야만 합니다.

먼저 관리자는 초대장 부분에 있는 “받는 사람” 필드에 E-Mail 주소를 넣습니다.

그 외의 부분은 필요한 만큼만 채우시면 됩니다. 그리고 초대장을 발송하세요.

그러면 받는 사람에게 다음과 같은 메일이 옵니다.  메일 안에 “블로그 바로가기”라는 링크를 클릭하시면 됩니다.

클릭하면 아래와 같은 화면이 뜹니다.(자동으로 생성된 암호로 로그인됩니다.)

필명에다가 자신의 별명이나 이름을 씁니다. 저 이름으로 글 쓸 때마다 박히니, 가명을 쓰셔도

되고, 진명을 쓰셔도 되고, 별명을 쓰셔도 무방합니다.  그리고 그 아래의 “저장하기” 버튼 클릭하시구요.

다음은 비밀번호 있는 부분에 있는 부분에서 “새로운 비밀번호” “비밀번호 확인” 부분에 자신만의 암호를 넣어주세요.

만일 이 부분을 안채우시면 암호를 알 길이 없습니다.(자동으로 만들어진 비밀 번호이여서, 관리자도 알 수 없습니다.)

입력 후 “저장하기” 버튼을 클릭하세요.

나머지는 그대로 두세요!

이렇게 필진을 등록하시면 됩니다.

2. 필진 관리하기.

필진 관리는 관리자 권한에서만 가능합니다.

관리로는 필진의 권한 설정과 필진 삭제 정도의 기능이 있습니다.

그 모든 처리는 표 안에서 다 됩니다.

필진 관리를 하기 위해서는 관리자 페이지에서 네트워크 –> 필진 관리로 일단 들어갑니다.

권한 부분의 설정은 관리자, 글관리가 있는데,

이중 최소한 글 관리에 체크를 해주시기 바랍니다.

체크하는 순간 알아서 저장 적용됩니다.

마찬가지로 필진을 빼고 싶은 경우 사용자 제외를 클릭하시면 됩니다.

(삭제된 필진의 글은 모두 관리자로 넘어가게 됩니다.)

** 이 분류는 오로지 개인적인 경험과 직접 대면해서 만난 사람들을 관찰한 결과일 뿐입니다. 과학적인 통계를 통한 값이 아닙니다. 그러므로 절대적인 참조 할만한 데이터는 아닙니다.게다가 개인적으로 가지고 있는 전체적인 분류로 해서 사람을 규정짓는 짓은 무척 싫어하는 편입니다.(혈액형 별 사람 성격 규정짓기 등등). 단지 모든 사람들을 바라 볼 때 틀이 없다보면 머리가 복잡해지기 때문에 아주 가끔 제 멋대로 사용하기는 합니다.

** 그냥 머리속에서만 이리저리 연산만하고 기억했다가, 여친님께 설명하면서 정리한 내용입니다.

전산 1 세대.

전산 업계 최초로 뛰어든 세대를 대표합니다. 혹은 막 붐이 일어나고 대개 IMF 전 부터 전산업을 계속 하셨던 분들이 많습니다. 이 분들은 매우 회사 중심적인 사고를 가진 분들이 많습니다. 그래서 그런지 회사 소사에 민감합니다. 만일 9시 출근이라고 할때, 6시까지 술을 마셨으면 당연히 8시 50분까지는 출근합니다. 사우나를 가던 목욕탕을 가던 잠깐 눈을 붙이더라도 반드시 저 시간에 맞추어 나가려고 노력에 긴장을 더합니다. 게다가 전산업의 3D가 된 이유인 잦은 야근 부분도 대부분 이 분들의 작품이 많은 편입니다. 밤늦게 까지 하더라도 아예 밤을 새더라도 반드시 수행업무는 쫑을 내야 합니다. 이유야 어떤 것이든 기저에는 회사 중심 생각이 무척 강한편입니다. 게다가 개인적으로 아주 중요한 것들이 있다고 해도 회사일이면 일단 뒤로 미룹니다. 만일 배우자가 세대 차이가 나는 경우(이런 회사 중심적 사고를 이해하지 못하는..) 이혼하는 경우도 발생합니다.회식자리를 무척 즐깁니다. 전사든, 팀이든 개인적인 모임이든 적극적으로 참여하려고 노력하는 편입니다, 특히 업무 후 술자리에 모여 각종 영웅담(?)을 쏟으며 그날의 즐거움/괴로움을 마무리합니다. 술을 잘 못마셔도 꼭 그런자리에는 안 빠지려 노력합니다. 또한 회사에서 필요로 하는 것이 무엇인지에 대해서 관심이 많습니다. 환경에 대한 작은 부분에서 부터, 회사 자체의 체질 개선이나 조직에 대한 헌신적인 모습을 많이 보여주게 됩니다. 현재는 대부분이 이런 분이 경영진쪽에 있거나, PM, PL레벨에서 작업을 많이 하고 있습니다.

전산 2 세대

IMF 직후 많이 등장한 세대로 봅니다. IMF 전에 신입으로 있었던 경우도 있습니다. 이 분들은 대개 업무자체를 집중적으로 바라봅니다. 회사의 사정은 이차 문제이고 제일 중요한 것은 업무의 Success 입니다. 즉 최종 결과물에 상당히 구애받는 경우가 많습니다. 결과에 상당히 비중을 싣다보니 그 업무의 과정은 그렇게 중요하지 않습니다. 업무 기간과 최종 요청 내역이 명확하면 그에 맞게 수행한 하면 되기 때문에 그 중간에는 어떻게 진행하던 크게 개이치 않는 경우가 많습니다. 출/퇴근 시간은 고무줄에 가깝고, 프로젝트 종료 후에는 휴가등을 중요합니다. 또한 개인 소사가 있는 경우, 프로젝트에 큰 영향이 없다면 개인적인 소사를 먼저 수행하는 경우가 많습니다. 즉 업무는 중심이지만, 회사 사정은 크게 개이치 않습니다. 대개 이 부류 속의 세대인 경우 업무 예측이 중요한 변수로 작용하기 때문에 초기에는 무척 고생들을 한 케이스가 많습니다. 업무가 언제까지 끝낼지 어떻게 끝낼지가 명확해야 이런 형태가 가능하기 때문이죠. 또한 일을 일찍 끝내야 나머지 개인시간이 남는다는 생각이 강해 업무 프로세스에 관심이 많고, 어떻게 효율적으로 끝낼지를 더욱 고민하는 경우가 많습니다. 술자리나, 담배등을 태우는 자리를 자주 갖지만, 대개 전사(회사 전체)레벨의 모임 보다는 현재 속한 팀을 중심으로 하는 것을 즐기는 편입니다. 현재는 대부분 이런 분은 PM,PL, 혹은 현업 수행하는 분들이 많습니다.

전산 3 세대.

21세기 이후에 많이 보게된 세대로 봅니다. 회사나, 업무 보다는 급여, 복지 부분을 1순위로 바라봅니다. 물론 1세다나, 2세대도 급여, 복지를 보기는 하지만, 최소한 3세대는 이 부분이 1순위에 올라간 점이 큰 차이입니다. 극단적으로 표현하면 회사나, 업무는 단지 돈을 받기 위한 댓가정도에 불과하게 생각하는 경우가 많습니다. 일단 닥친 일을 대먼저 마무리해서 당장에 귀찮은 일이 없기를 바라는 경우가 많습니다. 그래서 회사의 개선이나, 업무의 개선을 고민하기 보다는 개인적인 사정에 대해서 더욱 많이 생각하며 고민하는 경우가 많습니다. 그러므로 회사나, 팀의 회식같은 자리 보다는 마음에 맞는 동료들과 어울리는 것을 즐깁니다. (대개 상사보다는 입사 동기등을 만나는 것을 선호) 끼리문화를 주도하는 경우가 많습니다. 그러다 보니 전산 업무에 대한 3D라는 인식이 제일 강합니다. 권리적인 부분(자유로운 활동, 출/퇴근 부분, 권한)에 대해 2세대들에 대한 동경은 있지만, 그에 따른 의무 부분에 대해서는 간과하는 경우가 많은 경우가 있습니다. 가끔 브레임스토밍을 할 때 엉뚱한 발상들이 튀어나오기도 하고, 신선한 판단들을 자주 보여주지만 이 부분은 대개 상사가 없거나, 매우 친근한 상사가 있는 경우만 나오는 경우가 많습니다. 현재 대부분 이런 분들은 현업을 수행하는 분들에서 많이 봅니다.

전산 1.5세대.

2.5세대 혹은 3세대 성향을 가진 분들이 1세대의 분들의 영향을 받아 발전한 형태라고 봅니다.(물론 개인적은 다른 경험도 있습니다.) 회사에서 주는 봉급에 대한 댓가라는 생각은 가지고 있지만, 일단 회사에 최소한 해주어야 된다는 기준점이 강한 편입니다. 특히 출.퇴근 부분과 같은 회사에 보여주는 외형적인 모습을 중요하게 생각합니다. 또한 개인적인 소사가 있는 경우에도 가급적 회사쪽으로 기우는 편입니다. 게다가 대가를 명확히 주고 받고 싶어하기 때문에 일이 없는 경우 제일 큰 스트레스를 받는 경우가 많습니다. 일단 어떤일이든 회사에 도움이 되는 일을 해야 된다는 생각을 많이 갖는 편입니다. 업무를 효과적으로 하기보다는 최대한 회사를 배려해서 진행하는 경우도 많이 보입니다. 하지만, 1세대가 해주는 절대적인 충성은 없습니다. 대개 이정도는 해주어야지라고 생각은 하지만, 내심 억울하게 생각하거나 별도 보상을 요구하는 경우가 많습니다. 1세대와 2세대 사이에 있는 경우가 많기 때문에 그 사이에서 받는 스트레스를 못견디는 경우도 있지만, 대개 세대 차이에 대한 전령역할을 주로 수행하는 경우가 많습니다. 모임 부분에서도 전사레벨의 모임보다는 역시 팀 단위의 모임을 선호합니다. 술자리를 선호하며 역시 영웅담(?)을 많이 이야기 합니다.

전산 2.5세대.

3세대의 성향을 가진 분들 중에 2세대 분들의 영향을 받은 분들이 대개 이 수순을 밟게 됩니다. 2세대의 형태를 프로페셔날 하다고 규정짓고 그에 맞게 활동하는 경우가 많습니다. 업무보다는 개인적인 사정이 무척 중요하지만, 그렇다고 업무 부분을 내팽겨쳐두지는 않습니다. 특히 업무에 대해서 구애를 받는 경우도 종종 보이게 됩니다. 2세대가 가진 의무 부분에 대해서도 한번더 신경써서 진행하기 때문에 업무적인 효율을 중시하기도 합니다. 끼리 문화를 중시합니다. 특히나 전사 모임이나, 팀 모임을 꺼리는 경우가 많습니다. 하지만 의무로써의 희생으로 생각하여 억지춘향처럼 내색 없이 참여를 많이들 합니다. 회사 사정은 거의 생각을 안합니다. 회사의 조건에 대한  직접적인 압력이나 제시가 없다면 대개 무시 됩니다. 그래서 그런지 3세대 만큼이나 2.5세대도 이직율이 높은 편입니다. 전산업에 대해 3D라고 판단하는 경우도 많습니다.

저를 굳이 분류를 한다면 1.5세대에 가깝습니다. 물론 저 틀에 정확히 들어 맞지는 않습니다만... 제 여친은 2세대에 가깝구요. 개인적으로는 2세대를 무척 동경합니다만 ㅎㅎ.

P.S 다시 한번 강조하지만, 억지로 자신을 특정 틀에 맞추어 보려고 하지마시고, 또한 이 틀이 틀렸다 맞았다는 그냥 넘어가주시기 바랍니다. 또한 위의 세대는 어떻게 보면 현재 처한 Role에 영향이 강한 경우도 있습니다..보통 20대는 신입, 30대는 중간 현업 및 관리자, 4~50대는 상위 관리자, 경영자 이다보니 역할이 틀려서 그럴 수 있다는 것입니다. 각 세대가 나이를 먹음으로써 3세대 였던 사람이 1세대가 될 수 있으며, 1세대인 사람이 크나큰 마음의 상처를 받고 3세대의 특성을 갖을 수 있다는 것이죠. 단지 저런 세대 차이가 있다는 생각을 한번 돌이켜 생각해보면서 이야기가 어디서 잘 안풀리는 지를 생각해보시는데 조금 도움이 될까 적은 것 분입니다.

요즘 가끔 틈이 나면 Windows Mobile App을 만들어 보려고 시도하고 있다.
과거에는 PDA라는 형태로 나온 제품들을 위해 만들다 보니, 거의 Windows Form을 기반으로 작성하는 경우가 많았었다. 그래서 Visual Studio에서 제공되는 가장 기초적인 도구들, Form, Button, TextBox 등등을 이용해서 구성하는 경우가 많았다.

하지만, WM 6.5가 발표되고, 터치기반의 App이 늘어나면서 그 UI가 예전 UI로는 더 이상 승부걸기가 힘들었다.
특히나 Touch 기반의 UI는 그 특성상 터치 Action이 생겨(그 Action들을 유행시키는 것은 바로 iPhone) 그에 상응 하는 형태로 만들어 줄 필요가 있었다.

하지만 개인적인 능역으로 단순하게 바로 바로 만들기는 무리.
왼쪽/오른쪽으로 쓸듯이 움직이면 페이지가 전환되고,
맨 상단에 버튼으로 “이전” 같은 UI나, 긴 바처럼 만들어진 버튼들 등등…
하나하나 새로 만들 생각하면 머리가 지끈지끈 했다.
그러다가, 간혹 상용/공개 App 보다보면 iPhone과 유사한 UI를 가진 App들을 자주 보게 된다.
그래서 이 App들은 도데체 어떻게 탄생한 것인가 고민도 참 많이 한 것 같다.
이것 저것 찾아보기도 하고 꾸며보기도 했지만, 실력 미달로 찾지도, 만들지도 못했다.

그러다가 어제 우연히 찾을 수 있었다.

Fluid 라는 프로젝트로 codeplex에 게재된 UI Framework 였다.
( http://fluid.codeplex.com/ )

바로 내가 찾던 UI.

지금은 이것을 어떻게 써야 되는지 파악 중에 있다.
이 UI Framework에 익숙해지면 그 때 부터 슬슬 개발을 하도록 해야 겠다.

기업의 중심적인 최대 목적은 이윤추구이다. 혹여나 자원봉사 및 무료 지원 같은 것은 어디까지나 이미지적인 개선 - 영업적인 광고 효과 - 을 위한 밑석이니..당연한 귀결일지도..
A/S도 어떻게 보면 자원봉사의 성격이 강하기 때문에, 잘 알해주려고 한다.
많은 기업들이 자원봉사임을 알면서도 A/S에 노력을 기울이는 이유는 바로 이미지 관리 때문이다.
그러기에 최초의 이미지를 더욱더 강렬하게 시장을 지배하고 픈 인터파크의 약진을 볼때...
E-Book A/S는 당연히 될 것이라고 생각했다.

사실 이번에 비스킷에게서 은근히 기대한 부분은 바로 책 A/S이다.
종이책과는 다르게 발간한 이후에도 책을 수정하여 올려 처리할 수 있다는 그 강점이 있다.
혹여나 오탈자가 생기든, 책 제본에 오류가 있던 간에 관련 출판사와 협의 후
수정한 뒤, 필요시 다시 다운로드 받으면 해결 할 수 있는 그런 시스템이 될 줄 알았다.

그러나... 예전에 구입해서 본 판타지 소설의 화려한 오탈자!. 소설 객주에서 장(章) 자체가 덩어리로 잘못 박힌 문제..
이번엔 만화책의 조그만한 화면...

요 근래 그런 오류들을 연달아 내면서 내 눈에 띄기 시작하니..분통이 터졌다.

일단, 소설의 오탈자와 객주의 문제부분은 아래와 같은 답변이 왔다. 

뭐.. 어떻게 보면 그냥 대변인이니까.. 뭐라 할말은 없지만.. 검토 후 수정이라...
의도는 아니겠지만, 왠지.. 에효... 라는 생각이 든다. 어떤게 문제인가라는 적극적인 태도가 아니고,
신고하시면 수정해주겠다...다. 게다가, 비스킷에서는 Page 라는 개념이 없다.
어디 즈음을 도데체 어떻게 말하라는 것인지...이에 대해서 간단한 언급후 답변은...

즉.. 책의 문제점을 알려주시려면 쪽수와 목차를 말해달라고 한다. 객주 보면 알겟지만, 목차가 2개~3개 밖에 없다. 실제 내용은 그 목차의 장에서 거의 중앙 즈음 된다. 그래서 목차 포기. 그렇다면 쪽수.
쪽수를 알려주려고 보니.. 쪽수가 없다. 이 낭패....
그래서 그 사실을 알려주었는데... 뭐 내가 쪽수고 나발이고 알려줄 수 있는 방법이 없다고 하자...
알아서 찾아본다고 했다.

결국 E-Book 내용 확인하는 사람이라면, 일도 많고, 일 자체에 장인정신이 없으신 분이리시라면, 분명 건성으로 통독을 하실 것이고..문제 없음으로 넘어갈 것 같다는 생각이 문득 든다..

자~ 이 문제는 어쨌던 나중에 업데이트를 한다고 하니.. 뭐 그건 그렇게 넘어가자.

이번 건은... 좀 쑈크.

아니.. 만화가. 저렇게. 화면 여백은 도데체.. 뭐하자는 플레이?!

그래서 비스킷 양에게 의문을 제기.. 그 결과 값은..

양해라...

흠.. 양해라..

오픈 베타 무료 게임서버 임대업도아니고.. 왠 양해. 즉각적인 수정 약속이나, 하다 못해 사과의 글이
먼저 나오는게 아닌가? 저거 무료로 받은 책이면.. 당연히 양해를 한다.
하지만, 나름 가격있는것 냅따 지르듯 샀는데, 저렇게 받으면... 쇼크지 않을까?
그런데 그 내용의 결과는... 흠...

여튼.. 실망감 가득 몇마디를 비스킷양에게 던져놨다.
뭐 비스킷 양은 단순한 메신저/대변인 역할이니 뭐라 더 할 말도 없고, 따지고 싶지는 않다.
하지만, 이젠 솔직한 심정으로는 비스킷을 통해 책사는게 아깝다는 생각 뿐이다.

큰 돈 내고 산 물건이나 서비스는 장점 보다 단점이 훨씬 많이 보이게 된다.
돈을 내고 받는 당연한 기대치를 만족치 못하니 당연히 단점이 많을 수 밖에..
그럴 수록 더욱더 신경쓰면서 관리를 해야 할 판국일텐데....

일단, 조금 더 지켜보도록 한다.
미운놈에게 떡하나 더 준다는 속담대로 살지 말아줬으면 한다.
나쁘게 굴고 진상을 피워야 대응해 주는 그 따위 글러먹은 대기업 서비스 정신 더 이상 갖지 말고...
문제점을 언급했으면 즉각적으로 대응할 수 있도록 노력 좀 기울여 줬으면 한다.

PS.

글 쓰던 중 응답글이 왔다.

실망 가득한 마음으로 쓴 몇마디 후 온 답글이였다.
역시 미운놈에게는 저렇게 대응이 제대로 오는것 같다.
(제대로인지는 모르겠지만, 그 뒤에서 무슨 생각을 갖고 쓴것인지는 모르겠지만...)

사실 처음 부터 저렇게 나왔으면 이런 글 쓸일도 없었고, 그냥 넘어갈 일이였다.
여튼 저 답변 마저도 이제는 더욱 삐딱하게 바라보게 됬다.

개인적인 짐작이고 억측일뿐이지만..

만일 최소한 진정한 나로호 엔지니어라면, 이번 발사는 조금더 신중히 조정했으리라 조심스럽게 짐작한다.

이번 발사 후 오류 발생의 주요한 원인은 아직 밝혀지지도 않았을 뿐더러, 무엇하나 뚜렷하게 보여주지 않기 때문에(이명박 정권 흐름과 유사) 어디까지나 억측에 불과하겠지만,

이번에 소방 장비 오류로 인해 발사 중지 후 단 24시간 만에 재개 되었다는데 놀라움을 금치 않을 수 없었다.더욱이 발사 절차도 변경할 정도로 무척 다급하게 진행된 발사 준비 작업이였기에 더더욱 의야함밖에는 가질 수 없었다.

아마도 이런 문제점이 있는 상황에서 일반적인 엔지니어라면 분명 발사 자체를 연기하거나 막고, 조금 더 명확하고 신중하게 문제점을 파악하며, 최초 발사 계획한 그대로 Rule에 맞추어 차근 차근 발사했을 것이다. 굳이 쏘고 싶다고 해도 “미쳤냐!!!!!”로 일축하고 당장 발사 스위치에 손가락 부러뜨리더라도 일단 막고 차근 차근 문제 역추적 부터하고 그 문제점을 더욱 깔끔하게 발표하지 않았을까?

그래서 더욱더 의심스러운 것은 정치적인 냄새 그득하며 모든 것을 이벤트화 시키려고 노력하시는 과기부 쪽이다. 아마도 누군가 발사를 조금 더 연기 한 후 명확한 상태 분석을 먼저 요처한 것을 과기부에서는 연기에 따른 지연 책임을 막기 위해 서둘러 끝내려는 의도지 않을까 싶다. 과기부가 아니라더라도, 최소한 이번 발사에 대한 관리 측에서 무쟈게 쪼아 대면서 억지 진행한 기분이 든다.

사람마다 문제점에 대한 접근 방식이 틀리다. 그래서 조금더 긍정적인 시각으로 바라보면서 성공적인 비전을 갖도록 진행하여 문제를 보다 빠르게 살펴보고 일부 허용치 부분에 대하여서는 빠르게 대처하며 마무리 지을 수는 있다. 하지만, 이 로켓 하나 만드는데 쓰는 비용과 발사에 따른 비용들을 생각한다면 그런  정치 공약같은 진행 방식보다 더욱 보수적이며 비판적이고 초현실주의로써 업무를 진행했어야 하지 않을까? 허용오차 +/- 10%라고 하더라도 +/- 0에 가깝게 되도록 더 자세히 살펴보고 측정하고 산정하며 마지막 발사 -1초에서도 언제든 브레이크 할 수 있을 준비를 해야 하지 않을까?

만일 내 멋대로의 억측대로 엔지니어들의 우려와 걱정을 뒤로 한체 정치적인 순간 순간에 대한 판단으로 이번 건을 저질렀다면 진짜.. 내 세금 너무도 아깝게 날려 먹은 거 아닌가? 미래 우주 공학이고 나발이고 최초 인적 네트워크 부터 판을 다시 짜올려야 될 것이다.

짧지만 각종 TV 방송과 웹 포털의 데이터들을 보면 해외 우주 사업 진행 진척 따위를 맞추기 보다 현재 부분에 대한 명확화가 먼저 선결되어야 할 것 같다.

여기마저도 정치적인 색을 뒤집어쓴 제멋대로 보수주의자들이 판을 치고 있는 거 아닌지 걱정된다.

판 다시 짜올리면서 정리할 생각이 아니면 이번 3번짜 발사는 일단 반대 1표다!

아침에 조금 더 서둘러 집을 나서 투표를 했다.
새벽 6시 부터 투표가 가능했지만, 그 즉시 투표하기는 그렇고,
결국 8시 즈음에 한 것 같다.

그러나 역시 우려했던대로, 6종류의 사람을 고르는 것에 한계가 있었고,
심지어 뭐하는 자인지 조차 알 길이 없었다.
고작 받은 것은 선관위에서 보낸 찌라시 정도...

뭐 그걸로 일단 낙착된 일부만 기억하고, 나머지는 벽보에 붙은 자들의
얼굴중 하나를 택해서 선택했다.

뭐 선거 전에 딴나라당 싫다! 뭐다 하면 잡혀갈까 두려워서
말은 못했지만, 일단 이번 투표때는 한나라당에 대해 적힌 것들은 전부 피했다.
더욱이 교육감 부분은 더욱 집중해서 보았는데,
집권 여당 쪽 사람 처럼 보이거나, 강남권 물을 좀 들이 마신 분들이라면
전부 빼버렸다. 아무생각없이 뽑으면 10중 8, 9는 지금 대통령 처럼
10명의 사람 중 단 2~3명만을 생각하는 사람일테니까.... 더욱더 신중해 질 수 밖에 없었다.
가뜩이나 요즘 애들이 줄었는데, 교육부분에서 10명중 7~8명을 챙기는게 아니라,
오로지 2~3명만 신경 쓸듯한 사람이라면 진절머리 난다.

일단 전반적으로 긍정적인 가닥은 잡힌 것 같다.
개인적으로는 아직 마음에 안드는 결과이지만...
그건 그것...

이제 과연 국가는 어떻게 돌아갈지, 내가 사는 지역은 어떻게 움직일지...
가만히 관찰한다. 그리고 다음을 바라본다.

지금까지 cafe24 를 이용하여 유료 호스팅 서비스를 사용하고 있었다.

1년에 6000원이니 나름 저렴한 가격인지라, 잘 활용해 왔다.

특히나 Linux 기반으로 되어 있었고, PHP4에 PHP Zend 엔진도 얹어져 있어

나름 속도도 보장되었다.

처음에는, 작은 저장 공간은 사진 보관에 처절한 약점을 노출했다.

이 부분은 Flicker나, Google의 Picasa 등을 이용해서 어떻게든 해쳐왔다.

그러나, Traffic Over 부분은 해결 불가.

이번달(2010년 5월)까지 트래픽 Reset으로 쓴 돈만 2~3만원은 넘는듯..

(한번에 250원인데.. 합치니... 어마어마..)

결국 참다 참다 못해 옮겼다.

전에 "고프로" 님께서 티스토리에 초청장은 한장 주셔서~

그 덕분에 무사 안착. Data Backup 후 Data Import 하니 완벽 복원!

그 결과 그대로 이번에 옮겨 왔다!

이제 당분간은 Traffic 걱정없이 여기서 눌러 앉아야 겠다!

ㅎㅎ