개발팁2011. 2. 23. 20:24
side by side 에러는 DLL 버전이 맞지 않는 경우 생기는 문제이다.

VS 2008을 업데이트 하다가 KB971092 업데이트를 적용하게 되면,
VC90 런타임의 버전이 9.0.30729.4184 로 올라가게 되는데,

빌드한 결과물을 다른 PC에서 실행하는 경우에 해당 DLL이 없으면 side by side 에러가 발생하게 된다.

이 경우 MS에서 배포하는 redistributable package 를 깔면 4184 버전의 DLL이 설치가 되는데,
문제는 이 패키지를 설치하는 경우 release 버전의 DLL만 설치된다는 것이다.

필요에 의해 debug 버전으로 빌드한 바이너리를 배포하는 경우에, 4184 버전의 debug DLL이 없어서 문제가 된다.


디버그 버전 배포시 문제 해결 방안으로는,

1. 4184 버전의 Debug DLL 배포
2. KB971092 uninstall
위 두가지 방법이 있는데,

2번 방법을 강력하게 추천하는 바이다.
Posted by 먹고사니
카테고리 없음2011. 1. 25. 18:13
Level 1 - 돈~
Level 2 - 기술
Level 3 - 사람


작년 말에 주말개념 상실, 출퇴근 개념 상실, 주야간 개념 상실, 수면 및 식사개념까지 상실하고 
미친듯이 한달정도 일하고 났더니,(다행스럽게도 일은 잘 끝났음)

대체 왜 이런 상황이 벌어지는지에 대해서 심각하게 고민을 해보게 되었다. 대체 왜......

일단 개인에 대한 고찰도 필요하겠지만, 현 시점에서는 개인이 속한 조직환경이 더 중요한 포인트라고 생각되어
본인이 생각하는 조직환경의 Level에 대해서 아래와 같이 생각해봤다.


Level 1 - 돈
   - 일단 자본주의 시스템이기때문에, 모든 것을 떠나서 지속적으로 돈을 벌 수 없으면 무조건 망하게 된다.
   - 기술도 없고 사람도 크지 않지만 용케 망하지 않는 회사들도 많은데, 일단 욕할 회사와 사장이 있는게 어디인가?
   - 아무리 기술있고 사람이 있어도 월급이 안나가면 답이 없다. 사장이 사람은 좋은데 회사가 망하면?
      또, 기술개발 하다가 회사 망하면 그것도 답 안나오는 얘기이다.


Level 2 - 기술
   - 일단 돈이 돌고 있다는 전제하에, 기술이 없으면 어느 순간부터 성장이 불가능해진다.
   - 기술로 돈을 벌 것인가? 사람을 노가다로 소모해서 돈을 벌 것인가?
   - 기술로 돈을 번 다는 것은, 인건비 노가다 이상의 부가가치를 창출함으로써, 연속적인 비즈니스를 가능하게 한다.
   - 즉, 기술이 없으면 매번 다른일로 노가다를 하니 항상 시간이 없게 되고, 시간이 없으니 또 기술확보를 못 하고,
     기술이 없으니, 또 노가다를 하는 악순환에 빠지게 되는 것이다.
   - 기술로 비즈니스를 하는 선순환의 경우, 그 반대로 노가다가 아닌 기술베이스로 움직이니 시간확보가 가능하고,
      또 시간확보를 함으로써 기술을 확장하고, 그 기술을 바탕으로 다음 비즈니스를 진행하게 된다.
   - 결국 기술기반이 제대로 확보가 되지 않는 비즈니스는 연속성을 확보할 수 없으며 일정 규모 이상을 뛰어넘을 수 없다.


Level 3 - 사람
   - IT기업에서 돈을 벌고 기술을 개발하는 것은 공장설비가 아닌 사람이다.
   - 사람이 다 떠나면 누가 돈을 벌고 누가 기술을 개발/확장 하겠는가?
   - 사람은 이성과 감성을 다 갖춘 복합적인 존재로써 보통 조직을 떠나는 경우, 이성적인 업무 문제보다는
      사람 사이의 트러블이나 개인이 회사에게 어떤 존재로 대접 받았는가에 대한 스스로의 감정문제의 경우가 더 많다.
   - 대접받고 싶은대로 대접하라는 황금률에 대한 진지한 고민이 필요한 시점이라고 생각한다.
   - 사람이 제대로 존재하지 않는 조직에 돈과 기술이 있더라도, 딱 거기까지이며 그 수준이상으로 도약하기 위해서는
     돈과 기술이 사람을 부리는 것이 아니라, 사람들이 돈과 기술을 부리는 조직이 되어야 한다.
  
     (사람이 살만한 조건 세가지는 따로 한번 정리할 예정)


돈과 기술 위에서, 사람이 살만한 조직은 어디에 꼭꼭 숨어있을까?

직접 만들어야 하나? ㅎㅎ
Posted by 먹고사니
생산성2011. 1. 19. 17:21
1. GTD의 포인트는 스트레스를 받지 않는 상태에서 최대한의 효과성을 발휘하는 데 있다.


2. 인간의 정신에너지가 일정 용량이 있다고 가정했을 때, 머리속에 Things Done되지 않는 stuff 들이 가득하면,
    가용 공간이 줄어들게 되어 효율이 떨어진다고 보고, 모든 stuff들을 Getting Things Done시키자는 것이다.


3. 일단 stuff들이 getting things done 되어 머리속에서 off 되지 않는 포인트는 다음과 같다.

    - stuff 상태로는 공간만 차지하고 done 되지 않는다
    - stuff를 done 상태로 만들기 위해서, 해당 stuff를 분석해야 한다


4. 그렇다면, stuff들은 어떻게 제거해야하는 것일까?

    - 모든 stuff는 inbox로 들어온다. 그리고 inbox에서 하나씩 꺼내면서(개념적으로) 아래 프로세스를 밟는다.
    - 그리고 한번 inbox에서 꺼낸 stuff는 반드시 다시 inbox에 넣어서는 안된다.

    - 해야할 일이고 2분이내에 할 수 있는 일이라면 -> 그냥 해버리고 지운다
    - 그렇지 않다면, 적절한 시점과 상황에서 실행한다 (Next Action / Calendar / Waiting For)
    - 내가 할 일이 아니면 위임하고 기다린다 (위임/대기)
    - 한번에 끝나는 일이 아니라 여러단계의 과정을 거쳐야 한다면 별도로 관리한다 (프로젝트)
    - 일이 아니라 필요한 정보라면 참조자료로 따로 관리한다 (레퍼런스)
    - 이도 저도 아니면 과감히 버린다


5. 위와 같은 흐름을 거쳐서 머리속에 들어오는 stuff를 분류하고, 분류한 결과를 신뢰성 있는 외부 저장소에 저장한다.


6. 저장한 내용을 근거로 적절한 시점과 상황에서 하나씩 해결해 나간다.


7. 인간의 뇌는 평균적으로 기억하는 용도보다는 판단하는 용도로 구성되기 때문에, 믿을 만한 외부 저장소의 힘을 빌려서,
    뇌의 가용공간을 최대한 확보하여 효과적/효율적인 판단을 내리는데 사용한다.


8. 주간 리뷰를 통하여, 진행상황을 점검하고 필요없어진 항목을 삭제한다.


9. 이러한 프로세스를 통해, 정신에너지의 가용량을 최대한 확보하고 확보한 에너지를 성과로 전환하는데
    집중시킬 수 있게 된다.


10. 결국 inbox가 비어있고 각종 관리 리스트가 신뢰할 만한 저장소에 존재하는 경우,
    내가 모르고 있는 일은 없기 때문에, 상황이나 컨디션에 따라 각 관리 리스트를 참조하여 thing을 done시키거나
    아니면 그냥 놀고 있더라도 스트레스를 받지 않을 수 있게 된다.


11. TopDown방식과 비교했을 때 (비전부터 설정) GTD의 강점은 다음 비유가 잘 표현한다.

    - 비행기 활주로 : 매일 매일의 업무
    - 10000ft 상공 : 한번에 끝나지 않는 프로젝트
    - 20000ft 상공 : 현재 업무 책임범위
    - 30000ft - 50000+ ft 상공 : 연간, 3~5년간, 인생비전

    - 비행기가 이륙도 못하고 있는데, 인생비전을 보기는 어렵다는 것이다.


수정 - 2011.1.20 - 4번 항목 분류 삽입
Posted by 먹고사니
개발단상2009. 8. 1. 14:16

제가 최근 일독한 소프트웨어 공학에 대한 좋은 블로그에서 (http://allofsoftware.net)

Copy & Paste의 종말 이라는 글을 읽고, 여러가지 생각들이 떠올랐습니다.

제가 남긴 댓글은 아래와 같습니다.

http://allofsoftware.net/77#comment610946

제가 생각하는 copy&paste의 문제는 이해부족에서 온다고 생각합니다.

체계적으로, 기존에 다른 사람이 작성한 코드를 분석하지 못했기때문에,
(이유는 여러가지가 있겠죠? 실력부족, 문서화안됨, 스파게티코드, 시간부족 등)
기존에 잘 돌던코드는 그대로 두고 플러스 알파만 내가 했다... 뭐 이런거 아닐까요?

또 비슷한 측면에서,
자신이 작업하던 코드의 경우에도, 설계가 세밀하게 진행되지 않은 상태에서,
일단 만들어보면서 얼기설기 작업해나가다 보면,
적절한 타이밍에 리팩토링 시기를 놓쳐버린 상태가 되는 경우가 있습니다.

시간비용 + 귀차니즘 때문에, Copy&Paste로 떡칠이 되기 시작하는 거죠.


마지막으로는 코딩스타일에서 올 수 있겠네요.
현재 제가 주로 작업하는 분야가 C언어를 사용한 임베디드 분야 (wipi등)쪽 인데,
판단문과 분기문이 수도 없이 떡칠되기 시작하면서, 소스가 주렁주렁 ㅎㅎㅎ

state머신이나 적절한(펑션포인터등 사용) 분기체계가 아닌,
switch-case, if-else 등으로 관성이 붙어버리는 거죠.

이상태에서 상용으로 소스는 릴리즈나가고 -_-;;;;;
대형 리팩토링 했다가는(이것도 안습) 되던 소스도 망가지고,
고객사에서는 최대한 손대지 말고 요거 하나만 고쳐달라고 하죠.

저희는 견디다 못해서....
고객사에서 version 2 만들자고 할때, 그쪽 목적은 기능개선, UI개편이었는데,
저희내부에서 아키텍처 부터 다시 잡아서 첨부터 다시 만들었습니다.

후우... 그나마 이제는 좀 살만해졌네요.

며칠전부터, 이 블로그를 처음부터 정주행하고 있는데,
오늘 정주행 완료하고 나니까, 현실적으로 와 닿는 얘기들이 왜이리 많은지요 ㅠㅠ

계속 분발해야겠습니다.

현실적 고민이 뭍어나오는 좋은 글들 감사합니다.

p.s. 3일에 걸쳐 블로그글을 다 읽고 났더니.. 진작에 신경쓸걸 하는 울컥한 마음에, 댓글이 횡설수설 합니다. 양해부탁드립니다.

결국 이러한 copy&paste 하나만 보더라도,
개발팀과 개발자의 현재 상태가 바로 드러나게 되는군요.

이 글을 시작 삼아서,
열심히 고민도 하고, 흔적도 남기도록 하겠습니다.

Posted by 먹고사니
책읽기2007. 12. 17. 22:27

읽은 시간 ... 약 3개월..

책을 참 오랬동안 읽었다. 학교 생활과 회사 생활의 병행.. 미국출장 등과 엮이면서,
시간이 많이 지난 듯 하다. 게다가 책의 활자도 작고 내용도 많은 편이라 더 그런 것 같다.

이책은 Independent Software Vendor, 즉 독립 소프트웨어 개발사에 대한 저자의 경험과
의견을 종합한 것이다. 국내 현실로 보면, 중소규모 혹은 1인 벤처 IT 회사에 해당할 것이다.

(국내 현실상, 이러한 ISV는 흔치 않은 편이다.)

하지만, 소프트웨어와 관련한 중소규모 회사에서 정말 공감이 갈 만한 부분을 많이 다루고 있다.

사람, 마케팅, 포지셔닝, 가격책정, 법적인 문제, 문화, 재무, 세일즈 등등 ...

특히 재미있었던 점은,
저자인 에릭싱크는 작은 규모의 회사에서는 프로그래머보다는 개발자가 더 필요하다고 말하는 것이다.
저자의 정의에 따르면 프로그래머는, 오직 코딩과 구현에만 집중하는 사람이고,
개발자는, 개발전반과 관련한 문서, 고객응대, 마케팅, 설계, 개발환경, 테스트 등에 모두 익숙한 사람이다.

그러한 이유는 프로그래머로써만 존재할 수 있는 회사는 아주 큰 규모의 회사가 아니면 가능하지
않다는 것이다. 전체를 통찰할 수 있는 능력이 필요하다고나 할까..

하여간, 재미있는 책이다.

Posted by 먹고사니
책읽기2007. 9. 17. 04:32
2007.9.16 ~ 2007.9.17

The Universal Computer Ther Road from Leibniz to Turing

단숨에 읽어 내려갔다.

현대 컴퓨터의 기원을 찾아, 3세기간의 여정을 보여준다.

컴퓨터 저변에 깔린 논리구조가 어떻게 확립되어 왔는지 볼 수 있으며,
결론적으로, 컴퓨팅 머신의 power는 현재 수학의 한계와 그대로 맞닿아 있다는,
평소의 나의 생각을 다시 확인하게 되는 기회였다.

Turing 과 von Neumann의 훌륭한 이론 체계가 우리를 구속하고 있을지는 몰라도,
수학자가 아닌 engineer의 입장에서는, 그 안에서 생존해야 하지 않겠는가...

논리학과 집합론, 수학사 등은 내 나이 35가 되기전에 꼭 접해보고 싶은 과제이다.
이 책을 읽으면서 그런 마음이 더 굳어지게 되었다.

Posted by 먹고사니