wintiger's Life

난 사실 보험이란거에 대해 쓸데 없는 돈낭비라고 생각했던 사람이다.

20대 후반 7년동안 연락없던 고참이 갑자기 연락와서 3년전에 보험들라고 지속적으로 권유 끝에 가입했던 15,000원짜리 실손보험...흔히 얘기 하는 실비 보험이다.

 

옛 정도 있고 해서 실비 보험하나를 들었는데 보험가입은 10~20분도 안되서 완료가 되어 현재 3년 넘게 보험료를 내며 지내던중 목 디스크가 왔다.

다행이 그때 들었던 현대라이프 실손 보험으로 청구 하고자 방법을 알아려 그 고참형에게 연락했지만 연락이 두절되었고, 인터넷으로 알아보았으나....방법은 어디에도 없었다.

홈페이지에도 간편 청구서 메뉴가 있었지만, "404 Page Not Found" 만 뜰뿐이다...

 

너무도 답답하고 짜증이 났지만, 월요일 출근후 고객센터에 연락을 해도 묵묵부답...

"통화량이 많아 기다려 주시기...." 20분 넘게 기다림 끝에 받은 상담원에게 그동안의 불만을 토로 했으나, 상담원의 대답은 준비해야 할 서류에 대해

엄청나게 빠른속도의 설명으로 무슨무슨 서류를 준비하라는 내용이 랩 을 뿌려 댔다.

 

그래서 내가 그걸 다 알아듣지 못하니 메일로 보내달라고 했는데 메일에는 생년월일을 입력하라고 되어있어, 생년월일을 입력해도 암호화된 메일은 열수가 없었다....

 

이젠 인내심의 한계도 왔고, 나의 담당자는 연락도 되지 않고....

타 보험사는 간편하게 핸드폰 어플로도 보험료 청구가 되었으며, 굳이 상담원과 통화하지 않아도 인터넷으로 쉽게 보험료 청구가 가능 했다.

 

이놈의 현대라이프는 21세기의 보험사라고 믿을수 없을만큼 아날로그 방식의 업무처리이며,

보험료 청구 문서를 등기로 보내라고..?? 장난하나....직장인들이 그렇게 한가한줄 아는지,

아~무 생각없는 보험사로 보인다....

내 주변 모든 사람들에게 현대 라이프 보험에 대해 생각하고 있다면, 도시락 싸들고 다니면서 막을 생각이다.

 

보험에 대해서 잘 모르지만, 이런 쓰레기 같은 보험사는 절대 권유하고 싶지 않다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

누구나 다 같은 환경과 같은 차이인데 학연 지연으로 인해 튀고 있는 놈들.....

그나마 그중 몇몇이 시위를 벌이면 잡혀가는.....이런 말도 안되는 세상은 언젠간 없어지겠지...

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ㅎㅎ

 

 

한길을 고집하며, 최선을 다하고...어떤 시련과 고난이 와도 끝까지 메이져 클래스의 자존심을 지키는 한남자가 되길...

[펌]

[지디넷코리아]IT는 서버, 네트워크, 프로그램 및 사람과 같은 구성요소가 복합적으로 작용하여 사용자에게 서비스를 제공하게 된다. IT의 구성요소 중에 하나라도 결함이 발생하게 되면, 이것은 IT서비스의 중단이나 품질저하 또는 보안 사고 등을 유발할 수 있다. 

IT의 구성요소 중, 특히 ‘프로그램’은 사용자와의 직접적인 접촉을 담당하고 있으며, 사용자의 요청을 처리하고, 다른 IT구성요소와 커뮤니케이션을 하는 중요한 역할을 수행한다.  

사용자가 IT조직의 담당자를 접촉하지 않고 프로그램과 직접 대화(?)하는 경우, IT조직은 이러한 대화에 끼어들 여지가 없다. 오직 사용자와 프로그램간의 무언의 접촉만이 존재할 뿐이다. 사용자 입장에서도 본인이 요청한 결과를 프로그램이 제때 제공만 해준다면 프로그램이 다른 IT구성요소와 어떤 행위를 하는 지에 대해서는 알 수도 없고, 또 참견할 이유가 없다.  

프로그램을 만든 IT조직 역시, 사용자가 특별한 불만을 제기하지 않는다면 사용자와 프로그램간의 커뮤니케이션이 잘 되고 있는 것으로 믿게 된다. 이러한 믿음은 프로그램을 사용자가 사용하는 운영환경에 출시하기 전에 충분하게 테스트를 했다고 IT조직이 믿는데(또는 믿고 싶은데) 근거한다.  

정말 프로그램들은 믿을만한가?  

사용자들도 자신들이 사용하는 프로그램이 안전한 방법으로 처리되어 결과를 제공하는 것으로 믿고 싶어한다. 그러나 IT에 종사하는 사람들은 IT조직의 수준에 따라 프로그램 신뢰도가 천차만별이라는 것을 알고 있으며, 함량 미달의 프로그램들로 인한 문제점들을 직간접적으로 경험해 오고 있다.  

■누더기 프로그램의 출현

국내 대부분의 IT조직들은 개발자 이외에는 프로그램 소스를 들여다 보지 않는 경향이 있다. 프로그램에 대한 테스트조차도 만들어진 프로그램을 이것 저것 클릭해보면서 사용자 입장에서 ‘작동’되는 지를 확인하는 데 그치는 경우가 많다.  

오래 사용돼 온 프로그램들 중에는 사용자 입장에서 작동은 되지만 처리 속도가 유달리 느리거나 뭔가 이상하다는 느낌을 주는 프로그램들이 있다. 특히 사용자 업무의 잦은 변경으로 빈번하게 프로그램 수정이 일어난데다, 개발자가 자주 바뀐 경우 미심쩍은 프로그램이 발생할 가능성이 높다.  

이런 프로그램의 소스를 들여다보면 ‘누더기’ 프로그램임을 발견할 수 있다. 누더기 프로그램이란 장황하게 긴 프로그램 소스 목록을 가지고 있다. 이에 개발자는 어떤 의도로 소스를 만들었는지를 타 개발자가 이해하기 어렵고, 이런 이유로 후임 개발자는 프로그램의 전체적인 맥락을 파악해서 수정하는 것이 아니라 임시방편으로 전임 개발자의 기존 소스에 덧대는 방식으로 유지해 온 프로그램들을 지칭한다.  

■누더기 프로그램의 이면  

누더기 프로그램은 IT조직의 바람직하지 못한 개발 관행의 폐해를 고스란히 담고 있다. 프로그램은 개발자의 개인 소유가 아님에도 불구하고, 프로그램을 만든 개발자 이외에는 프로그램을 이해하기가 매우 어렵다. 개발자가 평생 자신이 만든 프로그램을 돌보는 것이 아니라면 기본적으로 프로그램은 인수인계가 가능해야 한다.  

그러나 상당수 IT조직에서는 프로그램을 개발하면서 지켜야 하는 개발 원칙이 없거나 불분명한 경우가 많다. 프로그램 소스의 한 줄 한 줄은 나름의 이유가 존재한다. 개발원칙과 같은 서로의 약속이 없다면 수 백 줄 이상으로 자라나게 되는 프로그램 소스에 대해, 어떤 요구사항을 기반으로 개발자가 소스를 만들어낸 것인지를 파악하는 것은 매우 어렵다. 후임 개발자가 퇴직한 개발자들을 계속 귀찮게 하는 것도 이러한 상황 때문에 발생한다.  

■개발 자원과 시간의 부족  

IT조직 내에 누더기 프로그램을 탄생하게 만드는 이런 상황은 당연히 개발자의 잘못이 아니다. 해당 프로그램을 담당하는 개발자 이외에는 프로그램 개발 프로세스 내에서, 프로그램 소스를 열어서 검토할 수 있는 능력을 가진 사람을 배치하지 못하는 IT조직의 비용 문제가 그 원인 중 하나다.  

타인이 만든 프로그램 소스를 검토하기 위해서는 충분한 개발 경력을 갖춘 개발자가 필요하다. 그러나 이런 개발자를 프로그램 소스를 검토하는 데 전적으로 투입하는 것은 과다한 투자라고 생각하는 경향이 IT조직에 존재한다.  

시간이 부족한 것도 누더기 프로그램의 존재를 유지하게 만드는 원인이다. 적정한 수준을 가지는 프로그램을 만들기 위해 소요되는 시간을 무시하고 철야를 불사하며 개발자를 밀어붙이는 IT조직에서는 양질의 프로그램을 기대할 수 없다. 
 

■개발 프로세스의 한계  

IT조직의 프로그램 개발 프로세스는 ‘사용자요청->승인->소스코딩->테스트->승인->운영이관’의 순서를 기본으로 한다. IT조직의 규모나 특성에 따라 프로그램 개발 프로세스를 좀더 복잡하게 또는 요약된 형태로 운영된다.  

프로그램 개발 프로세스를 얼핏 보면 역할 및 책임이 분리돼서 프로그램이 잘 관리되는 것처럼 보이지만, 실제로는 소스코딩 이후의 전 단계에 있어, 프로그램 소스의 내용은 개발자 혼자만이 독점하고 있는 경우가 많다.  

승인이나 테스트 과정의 검증은 프로그램의 정상적인 작동에만 초점을 맞추어서 확인하는 관계로, 프로그램 소스 자체의 품질을 들여다 보는 ‘디테일’까지는 접근하지 못하고 있다는 것이다.  

■프로그램 소스와 보안 

프로그램 소스는 IT조직이 가지고 있는 보안의 ‘아킬레스건’이다. 대부분의 IT조직은 보안을 강화하기 위해 서버, 네트워크 및 데이터베이스 부분의 보안솔루션 도입에 투자를 집중하고 있다. 하지만 개발자가 프로그램 내부에 나쁜 의도의 소스를 삽입하는 경우와 같이 프로그램 소스 차원에서의 악의적인 행위에 대해서는 특별한 대응방법이 없는 실정이다. 
 

보안 측면에서 프로그램 소스 차원의 악의적인 행위를 차단하기 위해서는, 개발자가 작성한 프로그램을 소스 수준까지 들여다 보고 한 줄 한 줄의 소스가 정당하다는 것을 확인한 이후에만 운영환경에서 사용할 수 있도록 허용해야 한다. 

하지만 국내 IT조직은 대부분 프로그램 소스를 들여다 보고 있지 않고 있으며, 더 심각한 문제는 개발자에게 개발환경과 운영환경 모두를 접근할 수 있도록 허용하고 있다는 점이다. 나쁜 의도를 가진 개발자에게 이러한 상황은 완전 범죄를 보장해준다.  

나쁜 의도를 가진 개발자는 사용자가 프로그램 화면상에서 볼 수 있는 부분을 프로그래밍한 다음, 사용자들에게는 특별한 리액션이 없고 몰래 작동하는 프로그램 소스를 추가로 프로그래밍할 수 있다. 개발자는 혹시라도 프로그램 소스 검토를 할까 봐 승인 받을 때는 사용자가 요청한 부분만 포함된 프로그램소스에 대해서 승인 요청을 할 수 있다.  

개발환경과 운영환경 모두를 접근할 수 있는 개발자는 승인 이후에 몰래 작동하는 프로그램 소스가 포함된 다른 버전의 프로그램을 운영환경에 올리면 그만이다. 누가 알겠는가? 추후에라도 승인 프로그램이 운영환경의 프로그램과 동일한 것이라는 것을 검증하는 IT조직은 거의 드물기 때문에 이러한 시도가 적발될 가능성은 거의 없다.  

■프로그램 소스 검토의 혜택 

IT조직은 누더기 프로그램이나 보안의 문제를 해결하기 위해서는 프로그램 소스 검토 활동을 일상 활동으로 정착시켜야 한다. 프로그램 소스 검토 활동을 수행할 여유 개발자가 없다면 옆의 동료 개발자가 검토하도록 하는 방법이라도 적용할 필요가 있다.  

프로그램 소스 검토 활동이 일상화 되면 IT조직은 누더기 프로그램 제거와 보안 문제의 해결뿐만 아니라 여러 가지 추가적인 이득을 얻을 수 있다.  

첫 번째는 프로그램 개발자의 개발 능력이 급격하게 향상된다.  

사실 개발자는 혼자서 터득한 방법으로 프로그램을 만들어왔다. 그러나 다른 개발자의 프로그램 소스를 검토하는 과정에서 본인이 해왔던 프로그램 기법이 완전하지 않다는 것을 깨닫게 되고 다른 개발자의 좋은 프로그래밍 기법을 벤치마킹 하게 된다.  

두 번째는 프로그램 자체의 품질 수준이 높아진다.  

제조업의 경우, 과거 장인의 능력에 의존해서 제품을 만들던 시절에는 장인의 반발로 인해 장인이 만든 제품을 다른 사람이 평가하는 활동이 불가능했다. 장인이 독자적으로 만든 제품은 장인의 컨디션에 따라 품질이 들쭉날쭉 할 수 밖에 없었고 이것은 제품의 전반적인 품질을 저하시키는 원인이 되었다. 국내 제조업의 경우, 제품에 대한 품질 평가를 독립적으로 평가하기 시작하면서부터 제품의 품질이 좋아지기 시작했고 현재는 글로벌 최고 수준을 유지하고 있다.  

IT조직이 동료나 제3자에 의한 프로그램 소스 검토 활동을 정착시킨다면 양 쪽의 건전한 긴장 관계로 인해 프로그램의 품질 수준이 현격하게 높아지는 것을 경험하게 된다.  

세 번째는 프로그램의 장애가 줄어든다.  

프로그램 소스 검토 활동이 일상화되면, 여러 개발자를 거친 프로그램일지라도, 프로그램 소스에 대한 설명이나 로직이 명쾌해지기 때문에 프로그램의 수정을 자신 있게 할 수 있다. 프로그램 수정이 일어나는 부분이 다른 프로그램이나 IT구성요소에 어떤 영향을 미치는지를 파악하기 쉽기 때문에, 프로그램으로 인한 오류나 장애가 현격하게 줄어든다. 

■프로그램 소스에 대한 관심 필요
 
국내 IT조직들이 IT수준을 높이기 위해 많은 노력을 하고 있다는 것을 알고 있다. 하지만 그런 노력들 속에는 프로그램 소스에 대한 관심이 포함되어 있지 않다는 것을 느끼고 있다.  

수준이 높은 IT조직은 예외 없이 프로그램 소스 검토 활동을 수행하고 있다. 또 글로벌 IT 프로젝트에서는 프로젝트 기간과 프로젝트 이후에 프로그램 소스의 품질을 어떻게 보장할 것인가를 매우 중요한 항목으로 다루고 있다.  

국내 IT조직들이 높은 수준의 IT서비스를 제공하기를 원하고 국내 IT 시장에서 좋은 IT 품질로 생존하기를 원한다면, 이제 프로그램 소스와 관련된 활동을 시작해야 하는 시점이 아닌가 생각한다.

저는 뼈를 깍아 이것을 알게 되었습니다.
저 처럼 뼈를 깍아 아시기 보다 먼저 알아 살이 되시길 기원합니다.

간단하게 제가 이해한 대로 설명하도록 하겠습니다.

함수원형
PostMessage(HWND, hmsg, WPARAM, LPARAM)
SendMessage(HWND, hmsg, WPARAM, LPARAM)

PostMessage
PostMessage의 경우 메세지를 전달하게 되면 해당 윈도우의 메세지 큐에 추가 시킨 후 바로 리턴 한다고 합니다. 메세지 큐에 처리할 메세지가 쌓여있을 경우 언제 실행될지 모른다고 합니다.
예)
int a = 0;
PostMessage(hWnd,LB_ADDSTRING,0,(LPARAM)"포스트메세지")
a = 1;
초기 a값은 0 입니다. 그리고 포스트 메세지로 리스트에 포스트메세지란 문자를 추가 시키고 있습니다. 윈도우 큐에 메세지가 쌓여 있다면 리스트에 포스트 메세지란 문자가 추가 되기전 a 값은 1로 변경되어 있을 겁니다.

SendMessage
SendMessage의 경우 전달 즉시 윈도우 프로시져로 전달되어 실행된다고 합니다. 메세지 큐에 쌓는것이 아니라 바로 실행하는 것이죠.
예)
int a = 0;
SendtMessage(hWnd,LB_ADDSTRING,0,(LPARAM)"포스트메세지")
a = 1;
PostMessage와 같은 예제 입니다. 하지만 이 예제는 리스트 박스에 포스트메세지가 추가 되기 전에는 a값이 절대로 1로 변경되지 않습니다.


제가 이해한 내용을 바탕으로 작성하기에 잘못된 내용이 있을수도(?) 있다. ㅋㅋ

#include <stdio.h>
#include "string.h"

void main()
{
 unsigned char m_SendDataBufferTemp[10];
 short int intTemp = 0x1CFF;

 int i=0;

 for(i=0; i<10; i++)
 {
  m_SendDataBufferTemp[i] = 0x01;
 }

 memcpy(&m_SendDataBufferTemp[1], &intTemp, sizeof(intTemp));

 for(i=0; i<10; i++)
 {
  printf("\n m_SendDataBufferTemp[%d] = %x", i, m_SendDataBufferTemp[i]);
 }

 printf("\n shortint size = %d", sizeof(short int));
 printf("\n unsigned char size = %d", sizeof(unsigned char));
}


동한씨가 나에게 물어서 위와 같이 코딩을 하게 되었다....
헌데, 데이터 표출을 해보니...SendDataBufferTemp[1] = FF,  SendDataBufferTemp[2] = 1C 이렇게 저장이 되더군...
너무 어처구니가 없어서...이것저것 찾아봤더니...

<Endian - 메모리 저장 순서를 규정>

  cpu마다 메모리에 데이터를 저장시킬 때 방식이 다르다.
Intel x86 같은 경우에는 Little-endian 방식을 채택, Sun, 모토로라계열은 Big-endian 방식을 채택하였다.

  Little/Big-Endian의 차이는 논리적 메모리 공간에 그 메모리 폭(어떤 메모리건 논리적 메모리 공간의 폭은 모두 1 Byte)을 넘어서는 Data를 저장할 때 발생한다. 예를들어 0A0B라는 Word Size의 Hexadecimal 데이터를 11000H의 메모리에 저장한다고 해보자.
위에 그림에서 알 수 있듯이 1 Byte 단위로 끊었을 때,

하위 데이터인 0B가 하위 메모리 공간인 11000H에 저장된다. 하나의 메모리 공간(1 Byte)을 다 채웠으므로 다음 주소로 넘어가서,
상위 데이터인 0A가 상위 메모리 공간인 11001H에 저장된다.

이것이 Little-endian이다.

Big-endian은 반대로

상위 데이터인 0A가 하위 메모리 공간인 11000H에 저장된다. 하나의 메모리 공간(1 Byte)을 다 채웠으므로 다음 주소로 넘어가서,
하위 데이터인 0B가 상위 메모리 공간인 11001H에 저장된다.

한마디로 말하자면, 위와 같은 방식으로 논리적 메모리 공간에 저장되는 데이터의 순서 차이일 뿐이다.

- Little Endian : 가독성이 좋고, 대소 비교가 빠르다.
- Big Endian : 산술연산이 빠르다

사족으로 이 방식이나 CPU의 종류에 따라 stack에 push, pop하는 방식(Stack Pointer를 증가시키고 감소시키고하는 방식) 또한 다르다
논리적 메모리 공간 / 물리적 메모리 공간에 대해서 정리할 것.

이라고 한다.....
아~놔...난 왜 이런걸 지금에서야 알았을까....대학교 네트워크수업때 배우는거라는데 난 그수업 C 맞아서 그런건가...ㅡㅡ;

ToYcon.exe 파일을 실행시키면 박스모양의 프로그램이 뜨는데...

거기에 그냥 마우스로 JPG 파일을 끌어다 놓으면 알아서 해당경로에 ico 파일이 튀어나온다...ㅎㅎ

프로그램의 마지막 대미를 장식하는 아이콘...유용하게 쓰게 될지도...ㅎㅎ