퇴근5분전



구로디지탈 단지역에서 지하철로 환승하는데 늘 타는 자리에 걸린 액자의 글귀를 이제야 보게 되었네요...

기다리는 동안 읽어보았더니 왠지 모르게 퍼나르고 싶다는 생각이 들어 올립니다.

먹고 사는데 급급하다보니 아래 내용에 해당되는게 많은듯 한데요... 지금까지의 삶을 되돌아보는? 정도로

가볍게 읽어보심 좋을듯 ..




6 가지 불치병

사마천 사기 <편작열전>에는, 어떠한 명의라도 도저히 고칠 수 없는 고질병의 인간 정형으로,

육불치(六不治)를 말한다.

1.

환자가 교만하고 방자하여,

내 병은 내가 안다고 주장하는 환자는 못 고친다(驕恣不論於理, 一不治也)

내 병은 내가 안다고 하면서 제 주관적인 판단만 중요시하고, 정확한 의사의 진료와 충고를 따르지 않는

교만한 사람은 치료가 불가능하다.

2.

자신의 몸을 가벼이 여기고 돈과 재물만을 더욱 소중하게 여기면 못 고친다.(輕身重財, 二不治也)

몸은 세상에서 무엇과도 바꿀 수 없는 소중한 존재다.

돈과 명예만을 중시하여 몸을 가벼이 부린다면 이것 또한 불치병이다.

3.

음식을 제대로 가리지 못하는 사람은 고칠 수 없다. (衣食不能適, 三不治也)

옷은 추위를 견딜 정도면 적당하고, 음식은 배고픔을 채울 만하면 적당한 것인데,

지나치게 음식을 탐하고 편안한 것만 쫓는 환자는 어떤 명의라도 고칠 수 없다.

4.

음양의 평형이 깨져서 오장의 기가 안정되지 않는 사람은 고칠 수 없다.(陰陽幷藏 氣不定, 四不治也)

음양이 장기를 장악하여 혈맥의 소통이 단절되면,기가 불안정해져서 돌이킬 수 없는 상태로 진행되어 고칠 수 없다.

다섯째, 몸이 극도로 쇠약해져서 도저히 약을 받아들일 수 없게 되면 못 고친다.(形羸不能服藥, 五不治)

어떤 명약을 쓰더라도 그 약을 받아들일 만한 기본 체력이 없다면, 이것 또한 고치기 힘든 병이다.

6. 무속의 말만 믿고 의사를 믿지 못하면 영원히 못 고친다.(信巫不信醫, 六不治也)

일단 그 분야 전문가의 말을 들어야 한다. 제 몸에 대한 것이라고 제가 다 전문가가 결코 아니다.

편작은 이렇게 육불치(六不治)의 난치병을 말하면서,

이중 한 가지만 있더라도, 그 병은 자꾸 가중되면서,결국 누구도 고치기 힘들게 된다고 강조하고 있다.

(모셔온 글)

출처 : http://cafe.daum.net/achaban/HN6s/773?docid=1IpmN|HN6s|773|20110121095621&q=%BA%D2%C4%A1%BA%B4%20%BB%E7%B8%B6%C3%B5 ( [불치병 사마천] 으로 검색하면 나오는 링크중 하나입니다. )


 NCIS 가 둘다 시즌 종료가 되었네... 우~~

 음 스토리상 점점 약해져가는 지바!!  모사드 첨엔 완전 특공 같았는데...

계속 얻어맞고 다니네..



Fringe도 곧 끝날것 같고...

두 지구는 과연... 공멸할까? ... 궁금한데... 다음 스토리는...


CSI 마이애미 호레시오 반장 생사도 궁금하고... 트렁크녀도 궁금한뎅... 안나오넹.. 쯥!!!


미드 보느라 공부도 뒷전이고... 에헤헤...


'--- 취미 > 생각하기' 카테고리의 다른 글

책 4권 구입...  (0) 2011.07.22
불치병 _ 사마천  (0) 2011.06.15
[이래도 되는건가? ] 1박 2일의 불법 u턴...  (0) 2011.05.09
업무력 높이는 팁 5  (0) 2011.04.26
금산분리완화법이라...  (0) 2011.04.23


관련 기사 : http://www.newsen.com/news_view.php?uid=201105091118211001 

 이같은 장면이 논란이 되자 '1박2일' 나영석PD는 9일 오전 뉴스엔과 통화에서 "제작진의 완벽실수다"면서 "편집과정에서 걸렀어야 했는데 제대로 파악하지 못했다"고 힘없는 목소리로 실수를 인정했다.

기사 내용 중에 위 글이 있다.

 편집과정에서 걸렀어야 했다?  ... 그냥 좀 어이없다.

tv를 잘 안보기에 1박 2일은 거의 1년에 두세번 보면 많이 보는 편인데... 어젠 우연히 볼기회가 있어서 봤는데...

마침 강호동이 불법 u턴을 하는 걸 봤다. 난 순간 저래도 되나?? 싶었던 내용이 기사화 되었길래 뭐라 했을까? 궁금해서 봤는데...  

  지킬생각은 안하고 저지른거 안나가게 했어야 한다니...   

 출처 : http://ringblog.net/1940 





지난 4월 8일 제가 운영하고 있는 두 개 회사의 직원들과 함께 워크숍을 다녀왔습니다.

2011/04/14 티엔엠미디어 2011 상반기 워크샵 후기 by Rita


우리 유쾌한 직원들과 달리 전 소심하고 박성광을 닮은 사람(뒤끝 작렬!)이라서 그런지 늘 직원들에게 진지(?)하려고 노력하는 편입니다.


하여튼 이날 직원들에게 여러가지 발표를 시켜놓고 CEO랍시고 점수나 매기는 못된 경영인이 되기 싫었는지 그동안 짧지만 작든 크든 여러 회사를 다녀 본 경험으로 직원들에게 업무력에 대한 이야기를 하고 싶었습니다. 그래서 급하게 자료를 만들었죠.


이른 바 업무력에 대한 이야기입니다.


resize_image





 

resize_image



세상에 문제 없는 회사는 없죠. 담배 피러 직원들끼리 삼삼오오 모여 있으면 없던 문제도 창조해내는 세상이 직장인의 세상입니다.


resize_image



회사 내에는 여러가지 문제가 상존하는데요. 이 문제는 사실 대부분 알고 있고 느끼고 있습니다. 하지만 이를 해결하기가 쉽지 않아요. 왜? 우린 다 바쁘니까요. 문제 해결에는 시간과 노력이 들어가는데 지금 우린 당장 해야 할 일이 참 많거든요.


resize_image



어찌나 많은지, 일의 양만 많은 것도 아니죠. 위에서 시킨 일 아래서 펑크낸 일, 바깥에서 제안 달라는 일 등... 일의 종류는 또 왜 이렇게 일관성이 없고 하나씩 해결하기 힘든 걸까요.


resize_image



더구나 문제를 다 인지하고 있는데 이 문제를 야기한 사람이 누구인지 이 문제를 해결해야 하는 사람이 누구인지도 모르네요. 미팅은 하고 있는데 누가 결론을 내려주는 사람인지도 몰라요. 문제제기만 두 시간 하다 미팅은 끝나고 다음주 미팅 스케줄만 잡습니다. 쉬운 일은 그냥 아무나 했으면 좋겠고 어려운 일은 정말 알아서 누군가 해줬으면 좋겠네요. 우리에겐 '리소스'가 부족합니다. 라고 사장님에게 외칩니다~!


resize_image



여기서 제가 그동안의 경험으로, 최소한 대표에게 잘 보이는 법이 아니라 남들에게 '일 잘하는 직원' 소리 좀 들을 수 있는 비법을 알려드리죠. 뭐 비법이라고 하기엔 좀 우습긴 합니다. '업무력'은 나의 '능력'에서도 '직장 내에서 문제를 해결하는 능력'에 관한 이야기입니다. 모르고 있던 이야기는 아닐 겁니다. 그러니 가볍게 '맞아, 맞아'를 외쳐가며 진행해보죠.


resize_image



우리의 미팅은 왜 이리 지루한 걸까요. 만일 미팅 자리에 리더가 있다면 그의 잘못이 가장 큽니다. 그가 빠른 결정을 하지 않기 때문에 다른 사람들이 지속적으로 산만한 문제제기와 대안을 놓고 토론을 합니다. 이 때 손쉬운 해결책은 책임자가 책임 있는 결정을 빠르게 하면 되는 겁니다.

우리의 미팅은 왜 이리 지루한 걸까요. 만일 미팅 자리에 리더가 있다면 그의 잘못이 가장 큽니다. 그가 빠른 결정을 하지 않기 때문에 다른 사람들이 지속적으로 산만한 문제제기와 대안을 놓고 토론을 합니다. 이 때 손쉬운 해결책은 책임자가 책임 있는 결정을 빠르게 하면 되는 겁니다.


하지만 반드시 리더가 참석한 회의가 늘상 있는 것은 아닙니다. 고객과의 실무자 미팅, 단순한 팀 미팅, 타 부서와의 사내 미팅, 일상적인 아이디어 쉐어링 미팅 등은 모두 결론 짓기 힘듭니다. 특히나 문제가 복잡하게 보이면 서로 문제 해결에 매달려 솔루션은 저만치 떼어 놓고 누구 탓인지만 이야기합니다.

기억하세요. 결정은 '속도'에 비례해 성과를 냅니다. 실제로 우리가 내린 빠른 결정은 빠른 실패를 줄 수 있지만 그만큼 회복과 수정의 시간도 확보할 수 있다는 장점이 있습니다. 그런데 느리게 내린 결정은 그냥 그것으로 끝입니다. 그래서 결과에 대한 리스크가 더 커지죠. 의식의 속도를 빠르게 갖고 '문제 분석'에 매달리기보다 '문제 해결'에 매달리세요.


무엇보다 이런 빠른 결정은 미팅 전, 또는 업무 개시 전 준비량과도 큰 관련이 있습니다. 풍부한 자료습득을 통한 통찰이 결정을 빠르게 하니까요. 그렇게 빠른 결정으로 작은 성과를 쌓아가면 직장 내에서 '능력자' 소리를 듣거나 '스마트한 사람' 정도는 평가를 받을 수 있습니다. 물론 경솔하다는 평가를 들을 수 있지만 '성과'가 그 부실함을 희석시켜줄 겁니다.


resize_image



상사에게는 이렇게 이야기하세요.

"팀장님, 오늘 미팅에서 나온 이야기를 내일 오전까지 정리해서 드리겠습니다. 그리고 실행 방안은 다음주 초까지 준비하겠습니다. 그 사이에 자료를 조사해야 해서요. 자료 조사가 늦어지더라도 다음주 수요일까지는 준비해드리겠습니다."

만일 당신이 팀장이라면 '어, 그래' 또는 '그래, 근데 좀 더 당겨봐'라고 대답하겠죠? 그렇다면 아래 처럼 이야기하면 어떨까요?

"팀장님, 만만치 않겠는데요. 시간이 많이 걸리겠습니다. 하는데까지 해보겠습니다만 아시다시피 자료 조사가 장난 아니거든요. 어쨌든 열심히 해보겠습니다."

팀장은 물어보겠죠. '그래서 언제까지 할건데?' 또는 '하겠다는 거야 말겠다는 거야?' 좀더 심하면 '싫으면 하지마'라고 쏘아붙일 수도 있겠네요.

업무 소통에 있어서 '시간'과 '마감'은 매우 중요한 '의미'를 내포하고 있습니다. 마감이 정해져 있고 마감을 지키는 습관을 갖고 있다면 그 준비 상황이나 완성도와는 상관 없이 '정해진 마감까지 일을 마치는 사람'으로 평가받을 수 있습니다. 하루나 이틀 늦어질 때도 반드시 마감을 지정하면 대부분의 사람들은 자기 일이 아니기 때문에 이해하고 넘어가는 경우가 많습니다. 하지만 말도 없이 그냥 늦어지면 일의 완성도와는 별개로 '게으름뱅이''능력부족' 등의 꼬리표를 달게 될겁니다.

저는 이 '마감'에 대해 매우 민감했습니다. 잡지는 기자들의 기회과 집필 취재 등을 통해 만들어지는데 완성도와는 상관 없이 정해진 날짜에 인쇄를 넘겨야 하거든요. 그것은 약속이고 그 약속을 지키지 못하면 그 잡지는 '휴간'을 거쳐 사실상 '폐간'의 수순을 밟습니다. 오죽하면 '데드라인'이라고 하겠습니까.

resize_image



함께 일할 때의 기록은 정말 중요합니다. 흔히 많은 회사에서 담당자가 자리를 비우거나 퇴사하고 나서 모든 협력 업체와의 일이 초기 세팅되는 경험을 하게 됩니다. 이는 뒤에 후임이 업무의 히스토리를 정확하게 인수인계 받지 못했을 경우입니다. 잘잘못을 따지기 위해 남기는 기록이 아니라 업무의 진행 과정을 일목요연하게, 최소한 검색해서 찾을 수 있을 정도의 게시판이나 위키를 확보하고 있는 조직이 나중에 더 큰 조직력을 발휘하게 됩니다. 기록하는 습관은 개인의 '업무력'에 있어서 매우 중요한 요소이면서 조직의 '생존'에 꼭 필요한 요소입니다.

또한 대부분 관리자 이상은 짧고 간결한 '결론'부터 듣길 원합니다. 만일 그 결론에 대한 모든 과정이 기록돼 있다면 나중에 관리자가 결정을 바꾸거나 판단이 흐려질 때 당시의 상황을 다시 끄집어 낼 수 있습니다. 반대로 기록이 없다면 우리는 어디서부터 어디까지를 이야기해야 할지 모르는 상황에 다시 닥치게 될 겁니다.

특히 외부인과의 미팅이 있은 후 미팅 보고는 꼼꼼하게 참석자까지 기록하고 뒷 부분에 요약겸 '개인 의견'을 첨부하면 업무를 장악하고 있다는 인상을 줄 수 있습니다. 그 개인 의견을 통해 상사가 새로운 결정을 내리거나 그대로 진행하게 된다면 그의 결정과 같다는 뜻이기 때문에 역시 그의 사내 가치는 상승할 겁니다.


resize_image



여기서 다시 직장생활의 중요한 포인트가 나옵니다. 우리는 언제나 혼자 모든 일을 처리할 수 없습니다. 누군가와 일을 함께 나눠서 하게 됩니다. 그때 일의 초기부터 업무를 장악하려면 '내 일'을 먼저 찾아서 자원하는 것이 최고입니다. 때로는 오지랖 넓다는 비판을 받을 수 있지만 내가 잘 하는 일이고 반드시 성과를 낼 수 있는 일에 집중할 수 있다면 아주 좋은 일이겠죠. 사내에서 외국어 번역 일이 있는데 그나마 자신이 잘 할 수 있는 일임에도 상사가 시키기 전까지 손을 들지 않는다면 어떻게 비쳐지겠습니까.

어차피 해야 될 일은 빨리 자원하고 일단 나보다 특정 업무를 더 잘하는 사람이 있다면 그 사람을 추천하거나 그 사람에게 일을 넘기는 것이 좋습니다. 그래야 업무 성과도 좋고 서로 보람 있게 일할 수 있을테니까요. 그리고 서로 백업 플랜(조력 계획)을 짜두는 것도 좋습니다. 원래 A의 일이지만 B가 그 업무의 진행상황을 알면서 백업을 하는 것만으로도 회사에서 B는 두 가지 업무를 할 줄 아는 사람으로 비쳐집니다. 할 줄 아는 것이 많은 직원이 어디나 우대 받습니다. 상사는 늘 게으르거든요.

그리고 협업할 때 회의를 하면 기획을 하는데 대부분 실행에 집중하지 않고 현상에 집중하거나 과거 원인을 따져 들어가는 상황에 집중하게 되는데요. 이것은 아마도 업무를 서로 지금 배우고 있는 것 처럼 느껴지게 될 겁니다. 만일 상사가 있는 자리라면 '원인은 이렇구 저렇구'를 늘어놓는 것보다 '해결책'을 단도직입적으로 제시하고 그 해결책을 수행하기 위한 계획 마련까지 제언한다면 '카리스마'를 획득하거나 상사의 오른 팔인 '참모' 계급으로 등극할 수 있습니다.

resize_image



그리고 이건 업무력과는 직접적인 연관은 없어보입니다만 '직장생활'을 대한 '태도' 같은 것입니다. 물론 업무력과도 중요한 연관성을 갖고 있죠. 대부분의 직장에서 '문제'에 집중해서 해결책을 내놓는데 바쁘다보니 '우리가 누구이고 우리는 원래 무엇을 하기 위해 이 일을 하고 있는지'를 까먹게 됩니다.

가령 내가 지금 이 일을 하는 것은 궁극적으로 나의 2년 후 1억 연봉을 받기 위한 과정이다 라고 상상해보는 겁니다. 또는 2년 후 나는 창업을 해야 하기 때문에 지금 주어진 일과 해야 할 일과 내가 못하고 있는 일에 대해 감이 오기 시작할 겁니다.

그런데 무턱대고 '계획'을 잡으면 거의 전 인류가 경험한 '작심 3일'에 빠지게 됩니다. 작정한다는 것 자체가 아주 피곤한 일이거든요. 하지만 상상한다는 것은 다른 겁니다. 상상은 유희이며 오락이고 현재 나의 가치를 판단해주는 중요한 기준점이 되어줍니다. 동기 유발에도 좋죠.

최소한 2년 후에 우리 회사와 내가 어떤 모습일지 구체적으로 상상하는 직원이야말로 지금 무엇을 해야 할지에 대해 잘 알고 좀더 적극적으로 업무를 장악하려는 태도를 갖게 될 겁니다. 상상하는 직원은 늘 앞서갑니다.

아이러니하게도 우린 수없이 많은 계획을 세워보지만 계획대로 되는 것은 없고 패배의식만 일깨워주는 반복적인 경험을 하게 됩니다. 하지만 상상은 즐길 수 있는 유희이기 때문에 강박증 해소에도 좋습니다.

결국 우리 모두 다 먹고 살자고 하는 것이고 다 내가 행복하기 위해서 일하는 겁니다. 세상 너무 거룩하게 살지 맙시다. 남탓으로 일관하고 혼자만 거룩한 직원은 성과도 없이 미간 주름만 깊어집니다.

resize_image





출처 : http://ringblog.net/1940


 뭔지 알고 당하자...

거지같은 딴나라당 쉐끼들...  이것도 국회깡패들 데리고 처리하겠지..

 막퍼가래서 퍼왔다.

얼마 되지도 않는돈을 은행에 두면 안될것 같군...

에효...

2mb_82_4


 어제 메일쪽 확인하다가 클라우드 라는 메뉴가 보이길래 클릭!!

오.. 20G나 주네?  파일 버젼도 관리한다네??

이햐~~~  별로 쓸일은 없겠지??

티스토리와 연계되는게 있을까낭??? 훔... 직접 편집도 되려낭... 조금 다뤄봐야겠넹.


 음 답이 2 와 288로 나뉘고 있는 글을 몇일전에 보고 또봤넹...

2라고 하는 사람의 말도 이해는 되는데

수학 못하는 난 기억하고 있는 것만 적용하면 288인뎅..

내가 생각하고 있는 문제 풀이.

 9 + 3 이 먼저 계산되고 12가 된 후

나누기 곱하기 어차피 나오는 순서대로 계산을 한다.

48을 2로 나누고 * 12를 하게 되는데.

2가 나오는 배경은 48/( 2 * (9 + 3) ) 요렇게 계산해야된다고 하는데...

내가 전자과라 크게 수학에 대한 법칙들은 잘 모르지만.

저렇게 계산되려면 적어도 위처럼 괄호로 운선순위에 대한 구분은 해야되는게 아녔나?

댓글들은 많이 봤지만... 역시 수학은 어렵다인가? ..?

기사중의 댓글에 생전 첨보는 글이 있었는데 다시 찾기 힘드넹...

그러면 계산기는 어떻게 계산할까?

입력은 모두 48 / 2 ( 9 + 3 ) 으로 한다.

다음에서 검색한 계산기:
48/2(9+3) = 288

구글계산기 : 
(48 / 2) * (9 + 3) = 288 이렇게 변환 해 버리고 답이 나온다.

MS에서 받은 계산기 프로그램 :
역시나 288



계산기 프로그램 Download :
http://www.microsoft.com/downloads/ko-kr/details.aspx?FamilyID=9caca722-5235-401c-8d3f-9e242b794c3a

음.. 다른건 중간에 * 생략이 불가능해서 테스트가 안됨...
우~!!!

이렇게 되면 목소리 큰넘이 이기는건가? 후후

기사를 검색하다보니 똑같은 기사가 참 많다는걸 느꼈다. 죄다 토시하나 안틀리고 복사~... 그냥 발행처만 다르다.

ㅋㅋ

이어서.............

관심이 가서 글을 더 찾아보니
http://bbs2.agora.media.daum.net/gaia/do/kin/read?bbsId=K157&articleId=63329 이런 글이??

음.. 인수분해처럼 해야된다?

2( 9 + 3 ) 을 먼저 계산하고 그값으로 42을 나눈다라... 중1때 배운다라... 이건 뭐 20년전껄 어찌 기억하누..

찾아보자!!

음... 흥미로운점을 발견했다.

48/  2( 9 + 3) 은 ( 18 + 6 ) 으로 앞에 2를 공통인수로 봐야 한다라는 것이네...

"논리연산이 산술연산보다 우선합니다. "  라고 말하는 글이다.
http://bbs1.agora.media.daum.net/gaia/do/debate/read?bbsId=D003&articleId=4293639 

또한 카시오 계산기로 계산한 것을 이미지로 찍어놨네... 음 그럼 ms 계산기를 다시 만들어야 겠군..

따져보면..
1. 48 / 2( 9 + 3 )  곱하기 생략 조건이 2를 공통인수로 봐야 한다.
2. 연산자 순서대로 계산해야 한다.

이 둘의 차이점인가?? 재미있다. 

중학1년 문자와 식이란걸 찾아 보면
- 공통인수는 괄호앞으로 뺀다. 
- 나누기(÷)는 분수형태로 바꾸고 곱하기(*)는 생략한다.

이걸 적용하면 왠지 1번이 맞겠지? ... 오~  처음과 다른 답이라... 재미있네...  

출근하면서 생각해 보니! 음.. 놓친게 있다.
"논리연산이 산술연산보다 우선합니다. " <-- 이거에 대한 근거제시가 윗글에는 없다!

근거가 뭘까?? 
해서 글을 찾아보니
http://crasher.egloos.com/19776 
여기엔
"그렇다면 논리연산자와 산술연산자가 같이 쓰이면?

산술이 먼저입니다."

라고 기술하고 있다

그렇다면 48 / 2 를 먼저 계산한 후 법칙을 적용하면 24 * 9 + 24 * 3 이 된다.


http://tandol.pe.kr/docs/Program/vbs/ko_230.htm
"괄호 안의 연산은 언제나 괄호 밖의 연산보다 먼저 수행되지만, 괄호 안에서는 일반적인 연산자 우선 순위를 따릅니다."

"둘 이상의 유형에 속하는 연산자를 가진 식에서는 산술 연산자, 비교 연산자, 논리 연산자 순으로 계산합니다. "


http://zvezda.styx.in/xe/?mid=Fortran&document_srl=245&sort_index=readed_count&order_type=desc

내용 :
연산자의 종류와 순서
연산자는 크게 산술연산자(arithmetic), 관계연산자(relational), 논리연산자(logical) 세종류로 나눌 수 있으며,
계산순서는 산술연산을 먼저 하고, 다음 관계연산, 그리고 논리연산을 제일 마지막에 수행한다.
생략...


고로 위 2라고 증명한 글은 틀렸다? 라고 봐도 되겠지?

답은 288이네.. 그럼 2라고 증명한 사람들은 뭐가됨? .. 음... 228일까? 2일까???


또하나 찾아봤다. http://ruliweb.daum.net/ruliboard/read.htm?table=cmu_yu02&num=837999

댓글들이 재미있다.

음... 2이든 288이든 저런 계산은 하지 않을테니까. 만약 계산을 한다면 () 로 우선순위를 좀더 명확히 하겠지?

답은 수학자들 몫이고...

다만, 난 프로그래머로써 이 문제에 대해 다양한 의견들을 보고 싶었고 또 보았다.

그거 누가(서울대수학교수) 그랬데~~ 라고 넘어갈 수 도 있는 것이고...

바로 위 링크에 답글 중 옮겨놓고 싶은 글... 모든 학문이 그렇겠지? 내가 하고 있는 이 일도 계속 변화 하고 있고...

곰이씨
미령 // 비단 수학 뿐 아니라 모든 학문이 이런 특이한 경우 '보편적으로 전해져 내려오던 방법' 혹은 '대부분의 사람(학자)들이 옳다고 인정하는 경우'로 풀이합니다 대신 나중에 그것보다 나은 계산 방법이나 증명이 나오면 과거의것을 미련없이 버리고 좀 더 나은 방법 혹은 옳다고 증명 된 방법으로 변해가는게 학문이죠.


  객체지향론을 처음 읽고 되새기며 설계에 반영하며 또다시 객체지향관련 서적을 찾으면서도 볼때마다 새롭게 느

껴진다랄까? 하나의 객체에 대해 바라보는 시각에 차이로 그 구성이 달라지듯 위 문제도 그렇지 않을까?

  배운데로, 자기가 아는 내용대로 그 기준의 잣대를 들이대고 답이라고 하듯 객체도 자신의 기준대로 구성해놓고

옳다구나 하는 ...


 
이만 여기서 쫑치자.. 일해야지...








 출처 http://cafe.daum.net/silverdoor/uE/24934?docid=pX|uE|24934|20110106101353&q=%BE%E7%C6%C4%20%B3%EB%B7%A1 

 안그래도 Mp3 듣던게 질려가는데 오늘 보니 양파가 노래를 내었다고 하니..

1집부터 테입/ CD사모았던 생각이...  테잎은 공간때문에 청산했지만 cd는 아직도...

좋은거 많이.. 많이 내주길... 평생 들어줄테니까...

30년 후쯤? 가요무대에 나올까나? 나도 울 부모님처럼 가요무대를 보고 있을까나? ..  

- 12월 초 ~ 2월 말 까지  프로젝트를 직접 진행하며 개발까지의 과정을 담아본다.

 운영에 올릴 준비를 해야 했다. 이 문제는 프로젝트 시작하면서부터 생각했던 내용으로써 소스에 대해 수정부터 일이었다. 기존 소스에 직접 타이핑을 할 수 없기에 이를 복사하고 가상디렉토리를 잡아놓고 개발소스와 별도로
작업을 하였지만, 이것을 다시 개발 소스로 옮겨놓고 테스트를 해야 하는데 무작정 파일을 덮어쓸수도 없다. 
 개발 하는중에 유지보수 된 소스가 어떤 부분인지 모르기에 직접 하나하나 옮겨야 했다.

 다음과 같은 처리를 하였다. 내가 작업하는 소스단에는 작업하는 내내 동일한 이름으로 주석을 달아 두었다.
개발에 옮길 때는 이 동일한 이름으로 전체 검색을 해서 리스트가 나오는 대로 개발소스로 옮겼다. 

 1월 31일 모두 옮기고 2월 1일 테스트를 마쳤다. ( 그럭저럭... 개발에서는 오류가 안나는듯 하였다. )
그러나 2월 1일 오후 KCC내부 회의를 통해 오픈이 연기가 되었는데 21일!! 이런... ㅡ.,ㅡ;; 2월2일 부터 6일까지는 설 연휴로써 ... 그 이후 유지보수를 통해 업로드 되는 소스가 ... 운영에 섞여 들어가면 안되므로... 연휴중에 몽땅 다시 원복시켰다.

 그리고 연휴가 끝나고 KCC에서 잠깐 테스트 및 버그를 수정하다가 본사에 복귀했다. 2월 18일부터 일주일간 운영에 반영하기 위해 다시 KCC를 찾았다. 운영에 일괄 반영하기 위해 만들어두었던 개발 툴을 정비하고 기존 운영소스를 백업하고 SP도 백업하고.. 운영준비를 마쳤다. 19일 토요일. 악몽이 시작되었다.

 SP를 모두 운영에 반영하고 난 후 web.Config를 수정, 개발툴로 운영에 소스를 일괄 덮어쓰기로 덮었다.
테스트 시나리오대로 테스트를 하는데 개발과 전혀 다른 상황들이 발생하였다. 우선 Agent가 정상동작을 안하는게
가장 큰 문제가 되었다. 이런 저런 것찾아보다 안되서 쉬는 동료들에게 저녁이 다되어 전화를 넣어서 헬프 요청을 했다. ㅠㅠ ... 아... 파일만 덮어주면 될 줄 알았더니.. 
 한밤중에 겨우 Agent가 돌기 시작했다. 어쩔수 없이 택시를타고 집에 와서 잠만 자고 다시 출근... 테스트 시나리오를 이용해서 KCC직원분이 테스트 하고 난 버그 잡는데 몰두하고 있었다. 겨우 겨우 문제점들 잡고 수정해서 운영서버 1개에 대해 반영을 완료했다. 서버가 2개라서 하나더 해야되었고.. 저녁 늦게 겨우 운영에 반영을 마쳤으나
버그를 다 못잡고 일부 눈에 안뛸만한 것들을 남겨두고 퇴근하고 오픈 당일날 나머지 처리를 하며 추가되는 버그나 요구사항들을 작업하며 그렇게 프로젝트를 마치게 되었다.

 지금은 다시 본사에 복귀해서 유지보수 업무를 하면서 kcc 추가작업들을 진행 하며 유지보수와 관련된 인수인계 문서를 만들고 있다. 

프로젝트를 하면서 ...
1. KCC건설 경영지원부 직원분들 엄청 열심히 일한다. 대~박... 난 절대 그렇게 일 못할 것 같음.
   돈을 많이 주나보다 라고 추측하고 있음.
2. 추워 죽는줄 알았다. 특히 월요일... 발에 동상... 여름에 간질 간질 하겠군..
3. 처음 맡아본 PM 겸 개발... 느낀바가 많다.

처음 맡아본 PM...

길고 길게 쓴 감상문?은 원래 이내용을 담기위함인데...

이번 프로젝트는 해볼 수 있는것에 대해 최대한 해본것 같다. 물론 조금은 아니 많이 부족했지만... 본래 2개월 아닌 3개월쯤이었으면... 조금은 아쉬운...? 결국엔 일정이 밀려서 3개월이 되어버린...? 으흐흐???

1. 문서에 대한 거부감?이 조금은 사라졌다. 무분별하게 만들었던 문서들이 여전히 눈에 딱 들어오는 문서는 아니지만 그전에 대충 쓰던 문서보다는 괜찮아진것 같고. 조금더 노력해보면 되겠지..

2. 개발 분석 및 설계에 대해 중요성을 다시 경험하였다. 요구사항을 정리하며 아무것도 모르는 소스를 보며
추가할 부분을 찾고 정의하고 몇번이나 시뮬레이션을 해보아는데, 덕분에 추가할 소스량이 확 줄어서 좋았다.
물론 개인적인 프로그램 만들때도 늘 설계 분석 개발인데... 가끔은 설계부분에서 헤어나오지 못하는 상황이 발생할 때가 있는데, 그땐 역시 직접 타이핑하는게 좋을때가...

3. 2달짜리는 절대로 들어가지 않는다! 다시 프로젝트를 내보내면 심각하게 이직을 고민해봐야되겠네...


앞으로... 올해는 참 할일이 많은데... 어쩐다.
방통대? 영어? 재산불리기? 그리고 일? ... 후~  일단 노력해보는수밖에..

아참 자격증... 이걸 따야 하다니.. 별문제도 없드만... 이딴걸로 돈이 오르락 내리락 하다뉘...
개떡 같은 한국 IT.

End...

- 12월 초 ~ 2월 말 까지  프로젝트를 직접 진행하며 개발까지의 과정을 담아본다

  전자 결재쪽을 본사에서 맡아서 처리하고는 있었지만... 처리가 여의치 않은지 몇가지 대응방법을 들고 부장님이 오셔서 회의도 하시고, 물론 난 계속 보안 관련해서 작업을 진행중이었지만...

 왠지 혼자 파견와서 우리측 프로그램 문제가 터져서 계약이 Power 여도 거의 프로젝트처럼 일하고 있으니...

뷰어가 만들어졌기에 이번엔 관리자 페이지를 만들기 시작하였다. 간단히 예상 테스트 시나리오를 정리 후
ui간단히 그려보고 바로 코딩에 들어갔다. 여기서 또한번 절망이...

 기존 프레임웍의 리스트뷰는 데이타를 가져와서 Xml 형태로 변환하고 미리 폼에 정의된 Xsl로 스타일을 입히게 되어있는데, 아~ 한숨만 나왔다. XML은 알아도 XSL은 ... 책만 봤지 어떻게 쓰여지는지 잘 몰랐기에... 여기서 처음 봤는데 무작정 가져다 쓸 수 도 없는 상황인지라 그냥 리피터로 작업을 하기 시작했으나 또 걸리는구나!
그럼 페이지는 ... 보니 그것도 리스트뷰에 구현이 되어있었다. 그냥 페이지도 만들자!!

 관리자 페이지를 만들면서 객체 트랜젝션 로직을 직접 설계해봤다. 이유는 SQL만으로 되는게 아니고 Exchange 에 Shell명령을 던져주고 나서 Sql 처리를 해야되는데 이게 트랜젝션 처리를 해야되니...


 
 관리자 페이지까지 만들었고 Csv로 다수의 대상자를 등록처리하는 부분까지 처리를 끝내고보니 12월도 끝나가고 있었다. 기존 게시판등 개발에 들어갔어야 했는데... 아... 머리속이 점점 복잡해진다.

 그리고 새해를 맞이 하였다. 2011년 내 나이도 34... 빈털터리... 지금껏 뭐했나 싶은... 그런 기분으로 출근해서 
일을 다시 시작했다. 게시판 관련해서 작업은 예상대로 일찍 끝이 났다. 예상 테스트 시나리오 작성 후 개발을 시작해서 예상대로 크게 복잡한 로직이 없다 보니 의외로 빨리 처리가 끝이났고, 다음단계로 넘어갔다.

 1월이 되어서도 결재쪽 Agent는 계속해서 이슈가 되어 있었고 본사에서도 열심히 ...  밤새가며 ...

 결재쪽 관련 작업을 시작해서 게시판과 같은 처리로 처음엔 그렇게 쉽게 끝나는듯 했으나... ActiveX가 기능이 안되는 것들이 있었다. 기본적으로 작성한 테스트 시나리오대로는 맞지만 kcc직원분이 테스트 해주니 여기저기 구멍이 나타났고 그중 ActiveX가 하나 안되는 것이 발견되었다. ActiveX의 업그레이드를 본사에 요청하고 나머지 작업을 이어나갔으나 워낙 겹겹이 있는 javascript를 따라다니다 보니... 허망하기 그지 없는 또 10줄 코딩에 30분씩 따라가는 상황이 반복되었다. 걸쳐있는 모든 함수에 다 구현할순 없어서 중요한 부분 부분들을 찾고 찾다보니 어쩔수 없이 시간을 흘려보내며 소스 흐름을 쫒아가고 있었다. 

 별보고 출근해서 별보고 퇴근하기를 반복하고 있었다. 이게 왠 때아닌 야근불사인가? 귀찮은데... 잘못 들어왔다. 이런 플젝이면 들어오면 안되는건데... 라고 되세기며... 그래도 PM으로 온건데 끝을 봐야지... 하면서 작업을 서두르고 있었다. 어쩔수 없이 밀린 일정이라도 조금 잡아보려했으나... 조금씩 조금씩 처음 예상대로 안되었다.

 1월 첫째주가 끝나갈 무렵 세째주부터는 현장 테스트를 해야된다를 말이 나왔다. 메일만 있으면 그나마 하겠는데
문서관리가 또 있어서... 본사에 지원요청을 하였다. 문서관리는 뭐 게시판처럼 하면 될것 같았지만 지금까지 해왔던 것처럼 기존 프레임웍을 몰라 헤매다 보면 시간을 얼마나 잡아먹을지 모르기에 요청을 했다. 문서관리라도 도와주면 될것 같았으니까... 본사에서 3일 지원와서 문서관리와 게시판을 처리해주고 복귀 하였다. 그동안 난 메일관련된 개발을 끝내갔다. 

 현장 테스트를 하기전 kcc직원분과 하나 하나 기능 테스트부터 다시 처음부터 해나갔다. 조금씩 나오는 문제점들
바꿨으면 하는 요청들과 함께 일거리가 불어났다. 현장테스트에 이상없이 진행할수 있게는 해줘야지 하며...
체크 리스트를 만들어가며 문제를 하나씩 풀어갔다. 현장 테스트 하기 바로 전날 밤꼴딱 새버렸다.
 새벽 2시쯤 끝낼수 있을것 같아요가... 5시가 되어버렸던것이다. 밤새니 집중이 안되고 ... 뭐 그런 상황이랄까?
kcc직원분은 밤새고 현장으로 출장가셨다.

 현장테스트는 3일간 이뤄졌고 개선되어야 할 사항 버그등을 가져오셔서 또 회의에 들어갔다.
새로들어온 내용들을 무조건 컷트할 수는 없고, 어차피 kcc에 들어오기전 업무에 대한 정의가 없던 것을 만든것이라 요구사항이 바뀔수밖에 없으니 적절히 보안과 관련해서 정책에 맞는지 체크하면서 개선될 내용들을 추려서
또 다시 작업에 들어갔다. 오픈일이 2월 초 였기에 개선된 내용들을 몽땅 처리하려면 시간이 빠듯했다. 
 거기에 2월 초에 설이 끼어 있어서 연휴가 끝나면 바로 오픈일!

오픈을 위해 이런 저런 처리를 마치고 오픈을 위한 테스트를 1월 말 테스트하면서 버그를 수정해간다. ...

To be...