구로에 있던 회사가 판교로 이사가는 바람에 구로에서 고만 살고 판교근처로 이사해야됐다
그런데 판교 근처 방값이 넘사벽이었다
그러므로 싼데를 알아보다보니 모란역 주변이 좀 싼거같아보였다
회사 걸어가는데 한시간도 안 걸리고
그래서 덜컥 방을 얻었더니...

보신업계의 용산전자상가뻘인 모란시장이 (...)
입주하고나니
근처는 똥개, 흑염소, 닭 등을 취급하는 가게들로 즐비했다.
아무래도 실시간으로 잡아다가 팔거나 2차가공을 하는것으로 보였는데
문제는 실시간으로 개잡는소리, 개화염방사하는소리, 개태우는냄새 등등이 난다는것
개가 뭔죄여;;

뭐 이게 중요한게 아니고
보신탕을 먹는게 왜 중요한가?? 에 대한 고찰을 해보고자 한다.
몸이 허해서 위에서 열거한 보신재료를 먹어야 건강해진다는 이론은 대체 어디서 나온건지 모르겠다
이건 마치 병신같은 회사에 똑똑한 인재들을 잔뜩 뽑아서 병신화 시키는거랑 똑같다.
물론 똑똑한 인재가 병신이 될때까지는 회사가 이득을 취하겠다만,
병신같은 회사가 시키는 일이 안똑똑한 사람도 얼마든지 할 수 있는 일이라는게 문제라면 문제

보신재료의 퀄리티에 대해 논해보도록 하자.
진열장에서 죽음을 기다리는 보신재료님들의 마음가짐이라는게 과연 '똑똑한 인재'에 준하는 퀄리티일지는 생각해봐야 한다.
먼저우는 개가 먼저 죽는다는 것을 알게된 개들은 사람들이 아무리 지나다녀도 짖지 않고
밤이 되어야 죽음을 기다리던 슬픈 개들이 짖어댄다는걸 주인들은 아는지 모르는지
그런걸 잡아다 먹는 사람의 건강이 퍽이나 좋겠지말입니다.

건강해지려면 몸도 마음도 건강해야된다는말은 뻥이 아니지 말입니다
좋은 것을 먹는다는건 물론 중요하지만 좋은 마음가짐으로 산다는것도 중요하다는것을 알았으면 좋것다.

미싱공장으로 유명한 구로공단에서 일한지도 어언 이년
남들 미싱돌릴때 열심히 코딩을 했더랬다.

세상물정 모르는 젊은이들이 멋모르고 회사 차렸다가
쫄닥 망하고 F모사에 먹혔는데

결국 세상에 찌들어서 두손두발 다들었다는 엔딩같은건 아무래도 안 봤으면 좋겠다.

모두가 처음에는 이상에 도전하지만
그럴수록 서로에게 돌아오는건 상처뿐이겠다
그것을 견딜 줄 아는 개김성과 개겨야 할 때를 아는 지혜가 필요할 때.

판교에서는 부디 해피엔딩을 보게 되기를....!

2012년도 머 딱히 한거 없는데 벌써 석달이 지났다.
계획을 거창하게 세워봐야 아무일도 일어나지 않는다는걸 잘 알고 있기에
아무 계획도 안 세웠는데...
그게 잘하는 짓은 아닌거같다;;

그래도 새해는 새해인지라 계획을 안 세운건 아닌데
그게 너무 소박하고 티도 안 나는거라 머 굳이 반성까지 해야겠냐마는
별 생각없이 살면 소박한 계획조차 못 이루는 ㅄ이 되는거같단말이지.

보통 사람들은 개인 계획을 1년단위로만 설정한다 (1개월도 없고 1일도 없다...)
기업에서는 목표에 도달하는게 주 목적이기때문에 1년단위로만 계획을 설정하지 않는다.
1개월과 1년 사이의 단위 공백을 분기, 반기로 쪼개서 계획이 제대로 되어가는지 수정할건 없는지 재검토를 한다.

보통 1년치 계획이 도루묵이 되는 시점이 3월과 4월사이이다 (...)
그게 한 분기랑 적절하게 시점이 맞아 떨어지는건 우연인가 우연이 아닌가;;
1분기가 끝나갈때 처음 세운 계획이 제대로 되가는지 돌아보지 않고있다면 올 한해도 망한 해나 다름 없는것 아닐까...

그래서 지금 1분기를 결산해보니...
시망의 기운이 느껴진다.......
4월부터는 새해라는 느낌으로다가 살아보는것이 어떻겠는가 생각해본다.

오늘도 뻘 창세기 이야기.

[등장인물]
야곱 : 지 횽아 등쳐먹었는데 신의 축복까지 다 받은 인물
에사우 : 야곱네 맏아들
이사악 : 얘네 아부지
레베카 : 사모님 (...)

[줄거리] (창세기 26장~)
이사악하고 레베카가 에사우와 야곱을 낳음
에사우는 성질 급한아이
야곱은 소심한아이
맏아들이 모든 축복을 받는 시절에 태어났는데
에사우는 그게 얼마나 중요한지 생각 안해봤고
야곱은 그게 얼마나 중요한지 알고 있었음
에사우가 배가 고파서 야곱한테 밥줘어~ 이랬더니
야곱이 맏형 고거 지한테 팔면 밥준다 그랬음.
에사우 흔쾌히 팔아버림
나중에 아부지 이사악 죽을때쯤 (늙어서 앞이 안보이는상태)
에사우보고 사냥해온거 요리해가지고 오면 축복해준다고함
에사우 사냥하러 길떠난다
야곱네엄마 레베카가 사냥한거같아보이는 요리를 만들어서 야곱보고 아부지한테 들고가라고함
야곱은 털 없고 에사우 털 조낸 많았는데 그것도 야곱한테 붙여서 위장시킴
아부지가 아들 생체검증 실행했는데 통과 (...)
그래서 야곱이 축복받음 (...)
나중에 에사우가 돌아와서 지랄하고 지랄해보지만
아부지는 이미 줬는데 머 어쩌냐는투로...

[정리]
맏아들의 권한을 $라고 치환하자.
세상에는 $를 가지고 태어나는 자와,
$를 가진 사람을 노리는 자가 있다.
$를 가지고 태어난 사람이 $를 중요하게 여기지 않으면 가진 $를 잃을 것이다.
$를 가지고 태어나진 않았지만 $의 가치를 잘 알고 있다면 다른사람의 $도 갖게 될 것이다.
내가 원래부터 가지고 있는 것들도 다시한번 돌아봐야 할 때

[정리2]
에사우는 천성이 화끈하지만 머리가 안돌아가서(=남자다워서) 아부지랑 친했고
야곱은 천성이 소심하지만 머리가 잘돌아가서(=안 남자다워서) 엄마랑 친했단다
에사우의 행실이 나아지지 않자 아부지도 에사우를 걱정했는데
야곱은 신과 겨룰정도의 화끈함도 갖게 된다.
자신의 부족한 능력을 채우기 위해 노력하는 사람은 이미 축복이 줄을 서 있는 사람이라는 이야기이다.

[$에 대한 민/형사상의 문제]
이미 저 둘은 $에 대한 양도를 끝낸 상태 (...구두합의만 했는지 계약서를 쓰고 공증을 받았는지는 쟤네사정)

[결론]
가족을 상대로한 막장 사기행각은 옛날부터 있었(...)

땜쟁이의 입장에서 바라 본 소프트웨어 설계 이야기를 해보고자 한다.
얼떨결에 소프트웨어 업계에서 일한지 몇 년 됐는데
그동안 소프트웨어 설계를 한다는 사람을 만나본 적이 없다.
설계라고 내놓은것이 고작 블록도 정도

공학 설계에서 가장 먼저 고려되어야 하는 것은 최종 결과물의 스펙이다
그리고 각 블록에서 최종 결과물에 대한 경계조건에 따라 파라미터의 범위를 정하고
값의 범위를 넘어서면 구현 불가능한 것으로 판단하여 최종 결과물의 스펙을 조정하든지 불가능한 프로젝트라고 판단하든지 하면 되는 것이다. 제작에 들어가기 전에 이미 설계단계에서 제작 불가능한 이유를 제시할 수 있는 것이다.
그런데 그런거 본 적 없다. 일단 돌아가면 장땡이란다

열심히 삽질하고 안되면 여기저기 고치고 하는게 프로그래머들은 당연하다고 하지만
하드웨어 쪽 이야기를 해보자
일반적으로 하드웨어 제작은 소프트웨어 제작에 비해 시간과 비용이 더 많이 들어가므로 설계에 신경쓸 수 밖에 없다
그래서 설계 잘못하면 여러번 제작해야되는 번거로움이 있다 하겠다.
특히 반도체의 경우 샘플만 만드는데도 어마어마한 $가 깨지기 때문에... 엄..
하드웨어 설계는 공학 설계의 원칙을 따라야만 샘플을 여러번 제작하는 것을 막을 수 있다.
모든것이 돈이기 때문에 각 모듈(칩)의 매뉴얼에는 파라미터의 범위가 매우 상세하게 제시되어 있다.

소프트웨어의 경우 MSDN에 제시된 API래퍼런스엔 하드웨어 모듈 매뉴얼보다는 못미치지만 소프트웨어 업계 통틀어 가장 상세한 설명이 제시되어 있는데 그렇다는 말은 다른 모듈의 경우 매뉴얼이 없다시피 하다는게 일반적이라는 이야기이다.
즉, 이 모듈이 내가 원하는 기능들이 구현되어 있으며 최종 결과물의 요구사항과 부합하는지를 삽질하기 전까지는 알 수 없다는 이야기이다.

하드웨어 제작은 회로도가 없으면 PCB를 그리기도 힘들기 때문에 회로도를 먼저 그려야 한다.
하드웨어 모듈들 설명서도 다 구해야되고 파라미터 범위(소자값, 레지스터 값 등)도 다 결정해야하고 그래서 설계하다보면 문서만 잔뜩 쌓인다.
모니터 앞에서 씨름하는것보다야 좀 더 인간적인거 같은데.. 여튼
소프트웨어 개발에도 설계라는 개념이 좀 있었으면 좋겠다. 는게 하고싶은 말이다.
1. 최종 결과물의 스펙 (최종 결과물을 한 블록으로 보고 4번과 동일하게 작성)
2. 블록도
3. 각 블록간의 인터페이스
4. 인터페이스의 허용 파라메터 범위(입력값 범위, 동작 시간 요구 조건 등)
여기까지 설계가 되면 일정 계산과 업무 분담이 쉬워진다.
실제 구현자는
5. 내부 동작 로직
6. 테스트 조건
7. 테스트 결과
를 추가로 문서화 하면 된다. (칩 데이터시트마다 있는 내용들이다)
문제는 남의 모듈 갖다 써야하는 경우인데 이 경우라도 이미 경계조건이 정해졌으니 남의 모듈을 주어진 조건에만 맞추면 되므로 삽질과 디버그가 편해진다.
그러면 코드는 입력만 하면 되고 팀에 컴퓨터 한대만 있어도 코딩은 다 한다.
인수인계는 할필요도 없다 문서만 보면 끝난다.
문서쓰기 싫다고 코드를 이쁘게 짜는 삽질들은 좀 안했으면 좋겠다.
컴파일 한번에 천만원쯤 받으면 설계 잘 하려나...

형상관리도 문서로 다 해버리면 되고 인증이라도 받을라치면 쌓인 문서 그대로 주면 되니 할일 줄어들고
툴 이것저것 설치한다고 삽질하는거 보면 안습;;
아오 이제 삽질은 그만......
(세상에 언어가 어셈만 있었으면 세상은 문서로 넘쳐났을텐데..)