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

단순한 컨트롤인 TextBox 나 ListBox 같은 것은 그냥 쓰면 되는데, 복합 컨트롤을 만들 필요가 있는 경우 사용자 컨트롤을 만들어 사용하곤 한다. 즉 TextBox와 ListBox가 하나로 합쳐진 특수 목적 컨트롤 같은 것을 만들때다.

저렇게 컨트롤 안에서 동작만 되면 문제가 없는데, 만일 외부로 이벤트를 노출 시킬 필요가 있는 경우가 있다. 위의 그림을 예로 들면 아랫쪽이 ListBox인데, ListBox의 선택이 변경되는 경우 저 통짜 컨트롤을 쓰는 곳에서 그 이벤트를 받기 위해서 구성하는 경우다.

어떻게 해야 될까 고민을 하다가 링크 하나를 발견했다. ( http://www.akadia.com/services/dotnet_user_controls.html )

만드는 방법은 간단하다. 딱 두 줄에 해당하는 내용을 넣으면 된다.

public delegate void 이벤트이름Handler();
public event 이벤트이름Handler 이벤트이름;

위와 같이 구성하면 되는데, 위의 컨트롤에서 사용한 내용은 아래와 같다.

// 컨트롤 내부 소스
public delegate void SelectChangedHander(); 
event SelectChangedHander SelectChanged;

event로 SelectChanged 라는 이름으로 하고 밖에서 연결할 때 사용하는 끈 역할을 하는 Handler를 delegate(대리자)로 선언하여 처리하는 것이다. 그러면 밖에는 이 Handler를 통해 이벤트 가입을 하는 것이다. 가입방법은 예전에도 많이 봤던 그런 형태가 된다. ( 저 이벤트를 받을 메인 프로그램에 선언하는 그 형태. )

// 컨트롤을 사용하는 메인 프로그램 소스
this.categoryCtrl.SelectChanged += new CategoryCtrl.SelectChangeHander(this.categoryCtrl_SelectChanged);

그러면 컨트롤 측에서 이벤트를 발생을 어떻게 하는 걸까?
그 역시 간단하다.

이벤트 이름을 함수로 호출하듯 하면 된다.

// 컨트롤 내부 소스 중 이벤트가 발생되는 시점
if (SelectChanged != null)
   SelectChanged();

보면 뜬금 없이 SelectChage가 null 인지 체크하는 경우가 있는데, 컨트롤이 제대로 초기화되지 않은 상황에서 호출되는 불상사를 막기 위한 안전 장치이다. 무시해도 되긴 하지만, 가급적이면 저렇게 안전장치를 거는걸 권장한다.

자,위와 같이 구성했다면, 이렇게 된다.

컨트롤내부 실행 중

-> SelectChange() 함수 호출

-> SelectChanageHandler로 연결한 모든 부분에 이벤트 발송

-> SelectChangedHandler에 인자값으로 넘긴 함수를 호출
   (위의 예제로 있는 categoryCtrl_SelecChanged() 함수 같은거)

기존에는 그냥 만들어진 이벤트를 소비하기만 했다면 자신만의 이벤트로 작업을 한다면 이런 부분을 활용해 보는 것도 나쁘지 않을 것이다.(생각해보니, 이렇게 만들 수 밖에 없기는 하다.)

중간 중간 일음을 접하게 됐을때 종종 들었지만, 키로로 라는 사실은 전혀 모르고 음악만 들었던 것 같다. 그렇게 머릿속에만 남아 있던 그 음악들이, 우연히 정오군을 통해 징발한 시디들 중 키로로가 있었고, 그 음악을 듣다가 우연히 내 머릿속에 맴돌던 그 음악들이였다는 사실에 알게 되었다.

아직도 미숙한 레벨의 일어 실력이지만, 대충 대충 감으로만으로 대략적인 가사의 뜻은 듣는 정도. 영어로 말하는 가사 역시 그 정도 레벨. 그러다 보니 굳이 집중해서 듣기 보다는 그냥 멜로디 정도만 생각하는 정도랄까?

그러다가 조용히 코딩이 막히는 것이 있었고, 음악을 들으면서 멍하니 있다가 키로로 음악들을 쭉 뽑아 들어보았다. 정말 아무생각없이 그녀들의 음악을 가만히 들었다. 그녀들이 말하는 게 정확히 무엇인지는 모르겠다. 다만, 목소리와 멜로디 그리고 몇몇 익숙한 단어들로 이어지는 이야기.

아...

나에게 강력하게 호소하는 것도, 그렇다고 자기들의 만족감에 어쩔 줄 모르는 것도 아닌 그냥 이런것이죠.. 라고 말하는 기분이다.

갑자기 닥친 복잡한 상황들과, 막연한 미래에 대한 두려움, 망설임, 내가 하고 싶은 것에 대한 포기 등등... 이 모든 것들에 대해서 그냥 말해주는 것 같았다.

순간 볼 위로 흐르지는 않았지만, 찐한 기분에 눈에 물기가 가득해진다.

이제 와서 팬이라고 자칭하는 것도 웃기고, 그렇다고 그녀들을 좋아하게 된것도 아니지만, 지금까지 지낸 세월과 현재의 상황들은 그녀들의 노래가 어느정도 코드가 맞는 것 같다. 내가 정신없이 바쁠때 들을때, 먼 후에 이 음악들을 조용히 들었을때, 과연 같은 느낌을 가질 것 같지는 않지만, 조용히 나중에 또 들으면서 조용히 이런 저런 생각을 해봐야 겠다.

사람들은 각자 자신만의 꿈이 있습니다. 꿈이 없더라도, 최소한 자신이 이루고자하는 목표나 욕구들이 있습니다. 하다 못해 기본적인 생활적인 욕구를 가지고 있죠.

이런 사람들 중 일부는 자신만의 사업이나, 회사를 꾸려나가기도 합니다. 하지만, 대부분은 특정 회사에 취직하여 일정 급여를 받으며 일을 합니다. 그런데 여기서 특정회사에서 자신의 꿈을 이루려 노력하는 사람은 그렇게 많지 않습니다. 심지어는 자신의 능력이나, 사정에 맞지 않아 도리어 나가는 경우도 많습니다. 즉 회사가 바라보는 곳과 사람들 개개인이 바라보는 곳은 다를 수 밖에 없다는 것입니다.(물론 일치하시는 분도 있지만, 그렇지 많지 않다고 생각합니다.)

그렇다면 최소한 한 쪽은 양보를 해야 회사는 큰 문제 없이 돌아갈 것입니다. 대부분은 회사라는 조직에 맞추어 진행되는 경우가 많죠. 특히 급여를 통해 자신의 목표나 욕구로 환원 받는 경우가 많기 때문입니다.

하지만, 단순히 급여만을 보면서 일하기에는 무언가 부족함을 느낄 수 밖에 없습니다. 특히 만족감, 성취감. 이런 부분은 돈으로써 매꾸기에는 한계가 있다는 것입니다. 즉 개개인의 꿈에는 맞지 않지만, 최소한 회사가 바라고 꿈에 일부분이라도 보탬이 되어 스스로에게 대리 만족과 같은 충족감을 느끼는 것이죠.

작은 부분일지라도, 회사의 성공속에 자신의 노력이 뭍어 있다면 두고 두고 자랑거리로 남을 수 있을테니까요.

즉 회사는 각 개개인에게 회사가 바라는 길, 꿈을 제시할 수 있어야 하는데, 제가 생각하는 회사의 Vision은 바로 이 부분이라고 생각합니다. 각기 다른 능력과, 생각, 판단, 목표라 할지라도, 최소한의 공통 분모로써, 회사라는 조직을 통해 하나로 묶을 수 있는 부분이라는 것이죠.

예전 Day&Night라는 곳에서 일할 때, 그 때 사장이 새로 뽑으려는 분에게 비젼 부분에 대해 이렇게 답을 하더군요. "비젼은 단순히 회사가 제시하는 것이 아니라, 일하는 사람들이 모여 만드는 것이다."라고. 그 때는 옆에서 듣기만 했던 나 조차 동의를 하며 그렇구나,라고 생각했습니다.

하지만, 지금의 생각에서는 그 부분에 대해서 100% 동의가 안되더군요. 물론 회사내 구성원이 만들면 좋습니다. 하지만, 각기 다른 개개인이 만들기에는 어떻게 보면 중구난방이라는 것이죠. 각기 다른 능력에 각기 다른 생각과 각기 다른 목표인데, 어떻게 하나로 합쳐질까요?

즉 회사에서는 최소한의 Base가 될 중심 생각을 보여주어야 하고, 그게 바로 Vision이지 않을까라는 것이죠.

회사의 이념을 나타낼 수도 있고, 회사 내 분위기를 표현할 수도 있습니다. 직접적으로는 회사가 어떻게 돈을 벌 것인지도 되는 것이죠. 단지, 각 개인이 한데로 뭉쳐질 수 있는 그 무언가는 반드시 필요하며, 그것이 모두의 동의를 얻어 낼 수 있는 것이여야 한다는 것입니다.

모두가 개고생을 하면서도, 최소한 서로를 위로해주며 다잡아줄 수 있는 Vision이 있다면, 잠깐의 고통정도는 서로 감내해 줄 수 있을 것입니다.

단, Vision이 있더라도, 그 Vision의 가치는 개개인 마다 생각하는 것이 다릅니다. 즉 같은 Vision을 바라보더라도, 그 가치를 생각함이 다르다 보니 누구는 함께 고생하며, 누구는 중도에 포기하도 합니다. 최소한 함께 Vision을 바라보기를 원한다면, 항상 같이 있으면서 Vision의 가치에 대해서 말하며, 지금의 힘든 점을  최소화하도록 노력하고 Vision외의 부분에 고통 받지 않도록 노력해주는 그 누군가가 필요하다는 것입니다.

한 회사의 사장이 될 수 있으며, 한 부서의 부서장이 될 수 있으며, 한 프로젝트의 PM이 될 수 있습니다. 또는 한 팀의 팀장이나 팀원일 수도 있습니다. 이런 사람들이 Vision을 이야기하며 제시하며, 함께 고생을 한다면 아마도 지금과 같은 IT 모습은 아닐 것입니다. 3D 아니 4D ( 3D + Dreamless)의 꼴을 만들어 버린 SI도 Vision을 함께 공유하면서 그 끝의 달디 단 열매를 서로 잘 나누웠다면 말이죠....

밤새고, 주말 근무하고, 개인 생활 파탄내다가, 결국 닭집하거나, 농사일(닭집이나, 농사일이 쉽다는 것은 아닙니다. 이거 해보시면 -_-;;;; )하게 되곤 하죠. 즉 그냥 회사에 출근해서 시키는 일 죽도록 하다가 월급 달달이 받는데 그 또한 여의치 않게 되고, 나이 먹다 보니 이제 하드 코어한 프로젝트는 못뛰는... 불상사. 남는것은 관리직이나, 이제나 저제나 기술만 보다 사람 관리하려니 죽어나는 것이죠. Vision 없이 닥치는대로 일을 하다가 보니, 스스로에 대한 회의감까지 이르르면 사실 끝이죠.

너저분 길게 길게 적었지만, 최소한 저는 이렇게 생각합니다.

지금 IT하는 회사라면, 스스로에게 Vision이 무엇인지 되묻고 달리셨으면 합니다.

지금 있는 개발자들이 과연 무엇을 바라보면서 같이 달리고 있는지 이야기 하고 생각했으면 합니다.

전 직원에게 묻고자 한자리에 쏟아부어 보려고 노력하는데 안모인다고 주저하지 말고, 당장 옆의 친구 부터 하나씩 묻고 이야기하며 현재 상태를 생각해주었으면 합니다.

그래서 지금의 Vision을 정리하여 모든이에게 틈틈히 전달해주고, 그 목표 대로 가고 있는지 늘 지켜보셨으면 합니다. 그냥 단순히 돈 얼마 벌어왔네, 돈 얼마썼네, 니 월급 대비 얼마를 더 벌어와야 하는데 그거 아니네, 어디는 더 벌어왔네와 같은 단순한 돈이 아닌, 정말 같이 공감할 수 있는 그 회사만이 보여줄 수 있는 뚜렷한 목표/Vision이 있는지 지금이라도 다시 살펴보는 계기가 있었으면 합니다.

한여름의 더위에 짜증내면서 끄적여봤습니다.

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.

글 쓰던 중 응답글이 왔다.

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

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