최근 QNAP NAS에 치명적인 버그가 발생하였다.
사고 발생 당시 QNAP 사이트를 방문하고 여기저기 수소문했지만.... 이유를 찾을 수 없었다.

그러다 활동 중인 카페에 문제 글을 올렸는데 QNAP 공식 카페에서 댓글을 달아 답변을 확인할 수 있었다.
이번 사고는 MALWARE REMOVER 업데이트에서 발생한 버그로 인해 NAS가 먹통이 되는 증상이었다.
해결방법은 NAS를 껐다 켜는 단순한 작업이었지만 회사 내 여러 곳에 QNAP NAS를 배치한 입장에서 당혹스러운 일이었다.
일단 사고야 발생할 수도 있지만 이 내역을 QNAP 한글 홈페이지에 팝업이나 보안 공지사항에 올려 두었으면 빨리 해결이 되었을 텐데....
아쉬운 점이 많았다.
개인적으로 QNAP NAS 사용성이 좋아 회사 내 대부분에 NAS를 QNAP으로 사용하는데...
이번 사고로 신뢰도가 많이 내려갔다.
앞으로는 이런 사고에 대한 대처를 잘해 주었으면 좋겠다.
사고는 사전에 막을 수 있지만 발생한 사고에 대해 고객들이 빨리 확인하고 대처할 수 있는 시스템을 구축해 줬으면 좋겠다.

* 이번 발생한 버그에 대한 관련 원문
https://www.qnap.com/ko-kr/support/con_show.php?cid=158&ref=top_notification_bar

 

 

Posted by Midas Min™
,

최근 주위에 이직을 하신 분들이 꽤 많았다.
나 또한 이직을 통해 현재 다니는 회사로 오고.. 벌써 만 8년이다.
휴.. 되돌아보면... 여러 가지 풍파가 지나쳐 갔고. 8년 전 첫 출근하며 "잘할 수 있을까?"라고 생각한 것이 정말 엊그제 같은데... 벌써 8년이 지나갔네...
주위에 이직하시면서 자의에 의해서 더 높은 조건을 원해서 이직하신 분도 있고 불가피한 사유로 강제로 이직하게 된 분도 있으셨다.
사람이란 게 참 변화를 싫어하는 동물이다.
그래서 항상 쓰던 물건이나 작업 형태를 많이 고수하지 않는가?
그런데 정말 직장을 옮기는 것 큰 도박이라고 생각하다.
정말 잘 다니고 열쒸미 일하고 있었는데 회사 사정으로 인해 이직해야 되는 경우가 가장 황당한 경우이다.
나 또한 몇 번을 이직 경험이 있기에... 글을 남길 수 있는 것 같다.
항상 당당하게 살고 싶고 소신껏 살고 싶다.
그래서 나는 항상 이력서를 쓴다.
최소 6개월에 한 번 정도는 업데이트를 하고 간헐적으로 시장에 오픈하여 내가 갈 수 있는 회사가 어디까지인지 체크를 한다.
물론 정말 내가 이직하고 싶은 회사에서 오더가 들어오면 이직을 할 것이다.
평생직장이라는 것은 우리 부모 때의 일인 것 같다.
지금은 상황이 바뀌면 회사 또한 직원들을 버리고 변신할 수 있다.
난 반대도 맞다고 생각한다. 직원들의 일원으로서 최선을 다해 일해야 되는 것은 맞지만 본인도 미래를 위해 계속적인 공부를 하고 언제는 더 높은 곳으로 가기 위한 노력을 기울여야 한다.
그리고 정말 좋은 곳으로 이직 기회가 오면 과감히 움직여야 된다고 생각이 된다.

최근 이직하신 분들 중 미리 준비하신 분들은 본인이 원하는 자리를 찾아갔지만....
타의로 이직한 분들은 생계를 위한 선택을 할 수밖에 없었다.

^^;;; 최근 주위 분들이 이직을 하니... 나도 갑자기 이직이 하고 싶어 졌나... ^^ㅋ
연말이라.... 그런지.. 이직에 대해 글을 남겨 봅니다.

Posted by Midas Min™
,

최근에 큰일을 많이 겪으며....
이런저런 생각을 많이 해보는 것 같다.
물론 좀 더 어렸을 때 전산을 그만두고 다른 일을 할 생각을 안 한 건 아니었다.
그때도 고민 후에는 역쒸... 내가 할 일은 전산일 밖에 없구나 였다.
그렇게 결정하고 살아왔는데....

최근 은퇴한 선배들의 이야기를 들으며 고민이 된다.
아직 한참인 50대 초중반에 은퇴하신 분들이 한분씩 나오면서부터...
이제 40대 중반인 나에게도 남의 일이 아닌 것이다.
전산이란 게 참 아이러니하게 트렌드가 계속 바뀌어 아무나 접근할 수 없는 분야이기도 하지만...
반대로 계속적인 노력이 동반되지 않으면 금방 뒤처지고 마는 것이 가장 큰 문제이다.
은퇴한 선배님들도 프로그래머 출신이셔서 퇴직 후 바로 어렵지 않게 일하지 않을까 했지만....
전산실과 개발업체는 엄연히 틀린 것 같다.
프로그래밍 실력이 있더라도 그게 전부가 아니니 말이다.
한 선배분이 힘들어하는 모습을 보면서... 마음이 착잡해지네요.
그리고 투영된 것이 나중에 나의 모습이 이러지 않을까...
나는 어떤 준비를 해야 될까 라는 생각이 드네요!!

요즘 시장에 개발자가 없다고 난리인데...
아마도 젊은 개발자들 없다는 뜻인 거 같네요!!
저 또한 회사 내에서 성장동력을 잃으면 내쳐지겠죠.
회사에 발전도 중요하지만 개인에 발전이 동반되지 않으면 의미가 없는 것 같습니다.
본인의 희생으로 회사가 발전하더라도 그 발전에 필요한 인물에서 낙오되면 버려지는 것 또한 숙명인 거 같네요....
아침에 출근하면 이런저런 생각이 들어 글을 남겨보네요.

그래도 한 가지 확실한 건 은퇴시기를 늦추기 위해서는 끊임없는 자기 발전이 필요하단 거지요.
자신의 노하우와 뛰어난 프로그래밍 능력이 있다면 다소 나이가 많더라도 롱런이 가능할 거라는 생각은 아직 변함이 없네.... ^^;;;

Posted by Midas Min™
,

최근 지인 중 한 분이 ERP 개발업체 선정의 실수로 프로젝트 진행에 큰 어려움을 겪고 있다.
전산팀에 근무하며 자체 시스템 운영을 하고 있지만 모든 프로그램을 자체 개발하는 것은 불가능하다.
이로 인하여 외부 업체와 협업도 진행하고 때에 따라서는 전적으로 외주 개발을 맡기기도 한다.
그중에서도 기간계 시스템의 핵심인 ERP 교체 프로젝트는 가장 큰 프로젝트이다.
대부분의 업체는 업체 PT 및 제품 소개를 통해 현업의 요구사항을 100% 다 이행할 것처럼 제안을 하지만 실제 프로젝트에 들어가 보면 지켜지지 않는 경우가 매우 높다.
특히나 이 이행률이 낮아지는 경우에 업체를 선정한 전산팀에 원망에 화살이 날아드는 경우가 많다.
그러기에 개발 업체 선정은 매우 중요한 작업이다.
나 또한 5년 전 협업 개발하던 업체 담당자의 잦은 교체로 인하여 개발 스케줄이 딜레이 되며 고생을 하였다.
다행히 소규모 프로젝트였기에 지연은 있었지만 프로젝트는 성공적으로 마무리되었다.
하지만 ERP 교체와 같은 대형 프로젝트는 문제 발생 시 시간도 시간이지만 현업 담당자들이 불편이 크게 초래된다.
내 지인 또한 이 문제로 지금 엄청 큰 스트레스를 받고 있는 실정이다.
그래서 고민을 해 보았다. 어떻게 이런 업체 선정 실수를 줄일 수 있을까?

1) 너무 작은 규모 업체는 거른다.
   물론 규모가 작은 업체라도 잘할 수 있지만 작은 충격에도 회사가 도산하는 경우가 많다. 
   도산하는 경우 참 난감해진다.
   프로젝트 비용 조금 아끼려고 하다가 평생 고생하는 수가 생긴다.

2) 이전 프로젝트 진행 결과 리뷰를 요청한다.
   이전 진행했던(동종 업체 시스템 구축 사례) 프로젝트에 대해 리뷰를 요청하고
   진행하며 발생했던 문제점 및 해결 방법에 대해 경청한다.
   일단 모든 게 원만하게 해결됐다는 업체의 거짓말은 믿고 거르기 바란다.
   회사 내 소규모 프로젝트 진행 시에도 각 부서 간의 의견 차이로도 많은 문제가 발생한다.
   프로젝트 진행하며 발생했던 문제점을 투명하게 오픈하고 어떤 방식으로 해결했거나 아직도 개선을 위해
   노력하고 있는 부분이 꼭 필요한다.
3) 도입 업체 담당자 미팅
   만약 아는 지인을 통해 만날 수 있다면 최고이긴 하지만..
   그게 여의치 않을 경우에는 제안 업체에게 요청하여 미팅 자리를 요청해라.
   단 가능하면 업체 담당자를 제외하고 별개로 미팅 자리를 요청하기를 바란다.
   아주 독한 사람이 아닌 이상에는 업체 담당자가 옆에 와 있는데 단점을 조목조목 전달해 줄 사람은 없을 것이다.
   혹시나 불가피하게 제안 업체 담당자와 같이 만난다면 인사 시 받은 명함으로 나중에 약속을 별도로 잡고
   꼭 만나보기를 바란다.

아.. 이 정도인 것 같네요 ^^;;;
가능하면 동종업체 전산팀 사람들과 모임을 만드는 것을 강추해 드립니다.
대부분 동종업계에 설루션 제공업체는 정해져 있기 때문에 그런 모임이 있을 경우에 업체 정보 공유는 매우 큰 도움이 됩니다.
이상 출근하다 갑자기 생각이 들어 끄적끄적해 보았네요!!

Posted by Midas Min™
,

작년에 이 유머를 보고 설마!! 했었다.
공식적으로 윈도우10 이후에 새로운 운영체제는 당분간 안 나올 거라는 확신이 있어서 그랬는지..
여기저기서 나오는 유머를 듣고는 무시를 했지만...
몇 달 전 프리뷰 버전을 받아서 설치해서 테스트를 해보고... ^^a
아... 곧 있으면 헬게이트가 열리겠구나 라는 생각이 들었다.
당장 내년부터 도입해야 되는 PC를 어떻게 해야 될지 고민을 해야 된다.
다행히도 윈도우10 -> 11은 무상 업그레이드가 가능하기에....
윈도우10 PRO 탑재 모델만 검증 후 도입을 하면 당분간은 문제가 없을 것 같지만...
( 물론 이것도 명확히 정책이 나온 후 진행은 해야 된다. 말이 바뀌는 경우가 있어서... )
회사에서 사용하는 여러 가지 애플리케이션 호환성 테스트 및 오작동 프로그램에 대한 대책을 세우려면...

ㅡoㅡ 악~~~!! 당분간은 죽었네요 ^^;;;
이 트윗이 참.... 힘들게 하네요..ㅎㅎ 그래도 할 일은 해야겠쥬~~~!!

Posted by Midas Min™
,

몇 달 전 전산업무 요청 건으로 프로그램 수정 개발을 의뢰를 했다.
1개 부서가 하던 일을 각각 파트에 따라 검수할 수 있도록 3 부서가 협업을 하는 시스템 개발을 요청했다.
전산팀에서는 약 1달간의 개발 일정을 잡고 개발을 지난달 말 완료를 하고 8월 초 오픈을 했다.
휴가 기간이 있었기에 약 1주 반 정도 사용을 한 상태인데...
요청을 했던 담당자가 연락이 왔다.
원래대로 돌려달라고.....
그래서 이유가 궁금하여 물어보니 특정부서 1곳이 시스템화가 되었는데도 빠른 처리를 안 한다는 것이었다.
그래서 다음 프로세스로 진행을 못하다 보니 전보다 사용하기에 더 어려워졌다고.

일단 통화를 하며 담당자에게 말을 했다.
분명 똑같은 문제 때문에(특정부서가 업무를 딜레이 시키는 문제) 이 시스템 구축을 요청했는데
동일한 문제로 시스템을 원복 시켜달라고 한다면 바뀌는 게 아무것도 없을 것이다.
그리고 시스템 수정 작업은 보고가 올라가야 되고 원인에 대해 보고가 돼야 된다.

결국 나는 해당 담당자에게 팀장하고 먼저 상담을 하고 문제가 되는 부분에 대해 정리하여 해당 부서에
협조 요청을 해라.

사람들은 그렇게 쉽게 변하지 않는다.
기존에 메일로 전달받던걸 시스템화한다고 해서 그 사람이 자동으로 움직이지 않는다.
그 사람들이 움직일 수밖에 없는 환경을 만들어야 된다.
그렇지 않으면 어떤 방법을 쓰더라도 항상 동일한 문제 때문에 고생할 것이다.

오늘 미팅을 통해 최종적인 결과를 정리하여 진행해야 되는데...
내 생각은 지연되는 부서가 정신 차리고 제대로 처리해야 된다고 생각이 든다.
투명하게 문제 사항을 정리해서 보고하고 압력을 가해 문제를 해결하려고 하는데 잘 해결되겠죠.

Posted by Midas Min™
,

사회 초년생 때 그렇게 주임이라는 직급이 부러울 수가 없었다.
왜냐하면 내가 사원이었으니까. 우에 있는 선배인 주임님이 그렇게 부러웠었다.

하지만 세월이 흘러 이제 관리자가 되고 나니...
회의가 든다.
특히 오래된 조직일수록 깐깐한 직급 관리에 능력에 상관없이 연차수를 채워야 진급에 대상이 되고 어떤 이는 연차수를 채웠어도 진급하기에는 이르다고 판단한다.
결정적으로는 너무 주관적인 입장에서 진급이 결정되고 내가 그 결정하는 사람 한 명이 되고 나니 꼭 이렇게 해야 되는가 라는 생각이 든다.
나도 차장, 부장이 되면 정말 좋은 줄 알았다.
그런데... 진급을 할 때마다 나를 대하는 직원들이 틀려지기 시작했다.
아무래도 직급이라는 뒤에 버티고 있어 저 사람한테는 말도 조심해야지...
본사에서 온 관리 자니까 쉽게 말 걸면 안 돼.... 머 이런 느낌이 있는 것 같다.
최근 부서원 진급문제도 고민이고 해서 선배형에게 문의를 하였다.
IT에서 제일 잘 나가는 게임업체에서는 어떻게 하고 있을까 ^^;;;
역시나... 거기는 사원부터 사장까지 전부다 님이었다.
이름도 아니고 닉네임을 부른다고 했다. ^^ㅋ 아.. 세상이 틀려졌구나 라는 생각이 들었다.
그리고 각 팀에는 팀장 역할을 하는 리더들이 있었는데... 그건 봉사직이었다.
리더가 그 팀 내 최고 연봉을 받는 것도 아니고 자신이 가진 능력에 따라 그리고 업무 특성에 따라 리더가 정해지는 것 같았다.
아무래도 리더가 해야 할 일이 있기에 그에 대한 약간의 보상은 있지만... ^^;; 서로 부담스러워하는 자리라고....
그리고 수평적인 구조가 되니 자기 일에 대한 책임감이 말도 못 하게 틀려졌다고 한다.
그전에 근무하시던 곳은 우리와 같은 직급체제이다 보니 윗 상사에게 기대는 현상이 많았는데...
지금은 그런 게 없다고 했다. 자기가 맡은 업무는 모두 책임지고 완수하지 않으면... 당근 연봉협상에서 큰 불이익이... ^^;;;

우리 같은 제조업체에서 문화가 맞을까 라는 생각이 들긴 하지만 이미 진행하는 업체들도 있으니 참고해서 우리도 한번 도전해 보는 것은 어떨까 라는 고민이 든다.
참 어렵고도 힘든 게 인사라... 특히나 진급에 대한 파장력도 크기에...
묵묵히 일하는 사람들의 사기도 꺾을 수 있는 만큼 보다 합리적인 체제로 변해야 된다고 생각이 든다.
아침부터 참 생각 많은 날이네요!!

부하직원, 상사보다는 서로 동등한 직원으로 평등하게 생각하는 날이 빨리 왔으면 좋겠네요.

Posted by Midas Min™
,

어제 미팅하다 든 생각이 있어 글을 남겨 보네요!!

전부터 공공 OPEN API에서 사업자 휴폐업 정보를 제공해줬음 하는 생각이 있었는데...
계속 관심을 가지고 보았지만 기능이 생기지 않자 포기하고 있었습니다.
그런데 금주 화요일 퇴근하는데 지인한테서 연락이 왔습니다.
공공 OPEN API로 드디어 사업자의 휴폐업 정보 서비스가 오픈되었다는 것이었습니다.
지인이 있는 회사에서 해당 API를 이용해 ERP 정보를 업데이트하려고 하는데 기술적으로 가능한 부분인지에 대해서 문의를 해왔습니다.
당연히 XML, JSON 방식으로 통신만 하면 실시간으로 데이터 체크가 가능하니 당연히 기술적으로 가능하다.
그러니 지인 회사 전산팀에 문의하여 진행하며 될 것이라고 답변을 주었습니다.
그리고 다음날 데이터를 API 정보를 확인 후 팀원에게 데이터 링크를 건네며 관련 부서와 협의하여 업무 개선을 진행해 보라고 지시하였습니다.
그리고 목요일 오후 2주간 업무 진행사항을 위해 미팅을 진행하는데 사업자 휴폐업 정보 검토 건에 대한 건이 사라지고 없었습니다.
저는 담당자에게 왜 그 정보를 활용하지 않느냐고 문의를 하자.
담당자와 대화를 나누었는데 국세청 들어가서 검색하거나 세금계산서 업체를 통해 월 1회씩 확인을 한자는 답변이 돌아왔다.
그 답변을 듣고서 다시 반문을 했다.
혹시 그 정보를 이용해 매일 새벽 전 거래처 점검 후 폐업되거나 변동된 거래처만 추려서 아침마다 레포팅을 해주면 어떨까?
이렇게 반문을 하자 담당자는 꿀 먹은 벙어리처럼 대답을 못했다.
항상 전산팀은 업무 자동화나 리스크 관리 자동화를 고민하라고 지시했지만....
쉽게 정착되지는 않네요!!
어제 미팅을 진행하며 아쉬웠던 부분이라 오랜만에 글을 남겨봅니다.
저 또한 예전에는 이처럼 생각하지 못했겠지라고 생각하며.... ^^;;;

Posted by Midas Min™
,

오늘 팀원과 미팅 중 있었던 일이다.
영업 프로그램 개발을 담당하는 직원으로 잘못 처리된 주문건으로 세금계산서가 국세청으로 전송되어 데이터를 건들 수 없는 상태가 된 건이었다.
영업관리 담당 직원과 원인을 파악해 문제를 어떻게 해결할 것인지 검토하는 단계에서 중간 미팅을 가졌으며 미팅 중 이 주문서가 발행되자마자 꼭 계산서가 발행되어야 되는지에 대해 문의를 했다.
그래서 왜 바로 발행되지 모른다고 하자 꼭 이렇게 처리되어야 되는 건지, 바로 계산서 발행하는 사유가 있는지 체크를 요청했다.
그러자 제가 그쪽 부서 팀장도 아닌데 이런 것까지 상대에게 요구해야 되는 건가요? 라며 반문을 했다.
아... 나랑은 생각이 틀리는구나 라는 생각이 들었다.

내 생각은 아무리 정성 들여 프로그램 개발한다고 해도 버그는 발생하게 되고 계속적인 개선 작업을 필수적이다.
간헐적으로 발생하는 문제라고 해서 무시할게 아니라 문제점을 찾아내고 최선을 해결책을 찾아 내야만 동일한 문제로 시간을 다시 투입하는 경우가 발생하지 않는다.
내 생각은 이런데.... 의견의 충돌이 있었다.
물론 내 성격이 괴팍하여 내부서 니부서 상관하지 않고 해결방법을 찾는데 방법을 가리지 않는다.
그건 내 스타일이고 결과를 찾는 방법은 본인의 방식대로 해보라고 다시 요청을 했다.

모든 일에 정답은 없지만 문제가 생긴 건은 꼭 해결을 하고 넘어가야 된다고 생각이 된다.
그렇지 않으면 계속 발생하는 문제에 짓눌려 아무것도 못하고 만다고 생각이 된다.
여러분의 생각은 어떠신가요??

Posted by Midas Min™
,

출근하다 문득 생각이 들어 글을 남기네요!!
개발 작업을 하다 전산실에 처음 근무를 하게 되면서 기존에 안 하던 시스템 모니터링을 수행하게 되었습니다.
그 당시 전산팀에는 총 5명이서 근무를 하였고 제가 막 입사한 막내였습니다.
입사 후 1달 정도 지났을 때 서버 모니터링 업무를 인수인계받고 매일 아침, 저녁으로 모니터링을 수행하였습니다.
근데 문제는 프로그램 개발업체에서 프로그램 개발 좀 해보고 데이터베이스 다뤄봤을 뿐이지 서버를 딱히 스터디한 적이 없었습니다.
한마디로 자동차 정비 경험 없는 사람한테 엔진오일이 정상인지 엔지에서 이상한 소리가 안 나는지 브레이크 패드가 많이 남았는지 조향 장치에 문제가 없는지 등의 점검 작업을 시킨 것입니다.
거꾸로 초보자한테 가장 중요한 회사 메인시스템 점검을 시킨 거죠.
그때는 그게 틀린 건지 맞는지도 모르고 그냥 시키니까 하는 거였죠.
로그를 보며 왜 이게 이런 거지??? ^^a 의문만 가지고 보고 네이버 검색해서 안 나오면 그냥 패스하는 수준이었죠.

그리고 경력이 쌓이고 제가 전산실에서 중간관리자가 되면서... 생각이 바뀌게 되었습니다.
모든 사고의 대부분은 아주 작은 전조증상을 수반하여 발생되게 됩니다.
그 전조증상을 발견하냐 못하냐에 따라 대응의 판도가 완전히 뒤바뀌게 됩니다.
매일 해야 되는 일이라 이런 거는 막내가 하는 게 맞겠어의 업무가 아니라 사고 방지를 위해서 이 부분은 경력자가 체크를 하고 후임이 어느 정도 교육과 경험이 생겼을 때 인수인계해야 되는 것 같습니다.
그리고 해당 업무를 위해서 많은 스터디가 필요한 건 필수사항이고요.
가끔 주위를 보면 문제가 생기고 그걸 모니터링하던 신입직원이 책임지는 사례를 몇 번 본건 같네요.
만약 시스템 모니터링과 같이 중요한 업무를 맡겨야 된다면 그에 걸맞은 스터디와 인수인계를 꼭 진행 후 맡기는 게 전산팀의 안정적인 운영을 위해 꼭 필요하다고 판단되네요.

Posted by Midas Min™
,