wintiger's Life

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ㅎㅎ

[펌]

[지디넷코리아]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 파일이 튀어나온다...ㅎㅎ

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

저번편에서는 과도한 압박이 실제로 어떤 부정적인 영향을 미치는지 알아보았습니다.

 

뭐 '좀비는 헤드샷'이라는 명쾌한 답을 제시해 주신 분들도 있고 스스로 좀비라고 자책하시는 분도 있었습니다.

 

제가 보기엔 스스로 좀비라고 자책하시는 분들은 약간의 보균자일뿐 아직 좀비는 아니실테니 걱정 안하셔도 될듯 합니다.(사실 진정한 좀비라면 이런 생각 이나 고민 자체를 하지 않습니다.)

 

사실 좀비는...

 

드마르코 형님의 책에서는 간단하게 나왔지만 많은 분들의 이해를 돕기위해 강조하였는데 의외로 좀비에 꽂히신 분들이 많아서 이걸 어떻게 풀어야 할지 많이 고민이 됩니다.

 

일단 이번엔 전편에 이어서 빨리 빨리와 압박을 실제로 구현하기 위해 관리자들이 저지르는 대표적인 바보짓 두개를 언급해 보겠습니다.

 

 

좀비들을 만들어내는 마스터(관리자)가 되는 법

 

---

 

첫번째는 공격적인 일정입니다.

 

6개월 짜리 일을 3개월로 줄이는 것이지요.

 

여기엔 두가지 부수적인 것을 동반하는데 바로 잘못된 믿음과 일정에 대한 책임입니다.

 

- 잘못된 믿음

 

많은 관리자들이 지니는 것인데 6개월 짜리 일을 3개월로 줄여서 하라고 해놓고 실제로 7개월이 걸리면 스스로를 합당화 시키는 것입니다.

 

바로 그나마 3개월로 줄이고 압박을 했기에 7개월로 잘 끝난것이라고요.

이게 되게 웃긴게 대부분의 관리자들이 신참시절에

'최대한 불가능한 일정을 세우고 거기에 분투하는 것은 결단코 손해 볼 수 없다라는 것이 옳다'

고 배운다는 것입니다.

 

근데 이것이 말이 안된다는 것은 소프트웨어가 아닌 건축으로 비유해보면 쉽게 이해 가능합니다.

 

건축을 예로 들자면 30일의 공사기간과 5명의 인력이 필요한 일을 50명으로 3일만에 하라고 한다면 아무도 가능하다고 하는 사람이 없을 것입니다.

 

최소한 기초 공사를 하는 기간이 필요하며 콘크리트 바를 시간도 필요한데 이건 단순히 사람만 늘리고 일정을 압박한다고 해서 해결되지 않습니다.

 

또한 결과로 보면 실제로는 훨씬 많은 비용을 치르게 되는 것이지요.

 

 

- 일정에 대한 책임

 

결국 일정은 지연되고 제대로 지켜지지 않습니다. (사실 제대로 된 일정이 아니기에 지키는 것이 불가능합니다.)

 

이때 관리자들은 책임을 모면하기 위해 그일을 수행하는 사람에게 책임을 돌리게 됩니다.

 

'아 왜 이 친구들은 일정을 제대로 못 맞추는 걸까?'

'이 사람들은 왜 이리 일을 못할까' 라고요.

 

일정을 못맞춘 이유가 일정 자체에 있음을 인정하지 못하고 오직 직원들이 일을 못한 탓이라고 생각합니다.

 

근데 일정을 맞추지 못한것은 잘못된 일정이기 때문인 경우가 많습니다.

 

일정이란 제대로 계획하는 것에 목적이 있는 것이지 단순히 목표만을 정하는 것이 아니기 때문입니다.

 

 

 

 

두번째는 바로 초과 근무 입니다.

 

일정이 지연되기 시작할때 관리자들이 직원들에게 강요하는 것은 바로 초과근무 입니다.(여기에는 이미 많은 분들이 이를 갈고 있을것이라 생각합니다.)

 

장기간의 초과근무로 발생하는 부정적인 결과는 다음과 같습니다.

 

- 품질의 저하
- 개인의 탈진
- 이직의 증가
- 정상 근무 시간의 낭비

 

네가지 모두 엄청나게 안좋은 결과 입니다.

 

이 부분은 다른 여러글에서도 많이 언급되고 있고 알고 계시리라 보이기에 설명은 하지 않도록 하겠습니다.

 

일정지연과 초과근무의 두가지 원투펀치를 맞게 되면 많은 직원들이 좀비로 변하게 됩니다.

 

즉 많은 직원들이 살아있는 시체들로 구성된 조직이 되는데 이런 조직은 갑갑하고 무기력한 느낌으로 가득차게 됩니다.(겪어 보신분들은 알고 계시리라 생각됩니다.)

 

일단 좀비를 안만드는 관리자가 되기 위해서는 위의 두가지 오류, 공격적인 일정과 장기간의 초과 근무를 지양하시면 됩니다.

 

 

 

그리고 아래의 내용을 참고하시기 바랍니다.

 

잘못된 압박을 행하는 방법들 (좀비 마스터의 핵심적인 스킬들)

 

- 완료일에 대한 부담을 준다.

- 추가 업무를 시킨다.

- 초과 근무를 장려한다.

- 실망할 경우 화를 낸다.

- 한 부하직원의 놀랄 만한 성과를 다른 부하직원들 앞에서 칭찬한다.

- 엄청난 성과를 제외한 모든 실적에 비판적인 태도를 취한다.

- 모든 직원에게 대단한 뭔가를 기대한다.

- 눈에 띄는 모든 시간 낭비를 꾸짖는다.

- 원하는 행동 및 결과를 장려하기 위해 사소한 인센티브 제도를 시행한다.

 

---

 

사실 뭐 여러 글들을 쓰곤 있지만 현재 잘못된 길을 향하고 있는 많은 관리자 분들이나 팀장분들이 바뀌긴 힘들 것이라 생각합니다.

 

어떤 사람의 마음가짐이나 행동 그리고 믿음을 바꾸기가 결코 쉽지 않다는 것은 요즘들어 특히나 느끼고 있으니까요.

 

제가 조금이라도 바라는 것은 이글을 읽고 현재 문제가 있다고 느끼는 많은 직원 분들이 나중에 관리자나 높은 위치에 이르렀을때 똑같은 오류나 실수를 범하지 않았으면 하는 것입니다.

 

비록 위에서 부터 바꾸진 못해도 조금씩 아래가 바뀌면서 올라가다 보면 언젠가는 위도 바뀔날이 오겠죠~

 

처음 글을 쓰기 느린자들을 위한 변명을 시작할때는 슬랙이 필요한 이유와 장점에 대하여 쓰기 위해서 시작했는데 이게 너무 일이 커졌네요...ㅡ.ㅡ;

 

 

일단 슬랙을 말하기 위한 내용의 핵심은 아래 그림과 같습니다.

 

 

 

효율성과 효과에 대한 단상

 

 

 

그림에서 오른쪽에 있는 퍼즐을 제대로 맞출수 있는 분은 좀 알려주시기 바랍니다.

 

근데 사실 오늘날 기업에서 강조하는 극단적인 효율성을 그림으로 표현한 것이 오른쪽의 그림입니다.(왼쪽은 정상적인 형태이고요.)

 

너무나도 효율성을 강조한 나머지 각종 문제를 해결할 수 있는 여유 공간 마저 없애버린 것입니다.

 

저 문제를 해결할 수 있는 여유 공간을 확보하자는게 슬랙의 요지라고도 볼 수 있습니다.

 

저런 공간을 없애는건 정말 말도 안되는것 같지만 실제로는 저런짓을 하는게 사람들이지요.

 

 

다음편에서는 조금더 효과적인 방법인 슬랙에 대해 전반적으로 적어 보도록 하겠습니다. (이 시리즈는 3편으로 마무리 짓도록 해야 겠습니다.)

- by 강태원(Meteor) -