미니의 중소기업 전산실 이야기

긴 직장생활을 해오며 여러 번의 이직을 겪었다.
그리고 회사마다 중요하게 생각하는 부서가 각각 틀렸다.
하지만 내 생각은 어느 부서나 다 중요하다는 것이다.
어느 부서 하나만 문제가 생겨도 회사에는 심각한 문제가 생기기 때문이다.
쉽게 생각하면 사람의 몸에는 다양한 장기들이 존재한다.
심장, 뇌를 가장 중요하게 생각하지만 만약 장이 없으면 에너지를 받아들일 수 없고
폐가 없다면 숨을 못 쉴 것이고 간이 없다면 해독하는 작용을 할 수가 없다.
이처럼 하나하나의 장기들이 모여서 몸을 원활하게 움직이는 것이다.
회사도 마찬가지라고 생각한다.
각 부서들마다 고유 업무들이 있고 그것들이 협업을 통해 원활하게 돌아가야만 회사는 정상적으로 모든 시스템이 동작하게 된다.
하지만 오너나 특정 힘 있는 사람들에 의해서 특정 부서만 중요시되면 겉으로는 잘 돌아가는 것처럼 보이지만 회사 내 조직은 썩어 들어가게 된다.
그리고 이 작은 불씨가 부서 이기주의를 발생시키는 불씨가 되게 된다.
최근 들어 자기 부서는 중요한 부서니 먼저 챙겨줘야 된다.
자기 부서 인원은 유능하니 대우를 해달라.

이런 의견을 내는 부서가 있는데... ^^a 싸다구를 날리고 싶다!!
회사 내 모든 부서는 모두 유능하고 중요한 부서이며 서로 존중하고 협력해야 된다.
이 같은 기본 이치도 모르는 팀장이 맡은 부서는 앞날이 먹구름이라고 생각한다.
출근 중 문득 이런 생각이 들어서 글을 남겨보네요~~!!
그래서 전산팀은 모든 부서와 소통하는 만큼 모두에게 최선을 다하고 공평하게 지원하기 위해 노력하고 있네요!!

8년 전 처음 이 회사에 전산팀을 만들며 입사 후...
약 1년간 자체 프로그램 개발 완료 후 가동 후부터 마음대로 휴가를 가는 건 불가능한 일이 되었다.
특히나 이 프로그램 개발 후 공장 생산, 출하시스템까지 타 시스템과 연동을 진행하고 후부터는 전체 휴일이 아니고서는 쉬기 힘들었으며 쉬러 가더라도 노트북 가방을 꼭 메고 갔어야 됐다.

그래도 하나씩 자리를 잡아가며 업무 또한 늘어가게 되었고 팀원을 한 명 더 뽑으면서 2인 전산팀으로 운영되게 되었다.
그 직원과도 5년 가까이 같이 근무를 해오고 있네요.
그러면서 원칙은 철저한 업무에 공유였습니다.
나만 할 줄 안다는 것은 회사 내에서 큰 장점이 될 수도 있지만 큰 리스크가 되기 때문입니다.
내가 없으면 그 업무가 멈출 수도 있는 크나큰 리스크죠.
물론 10년 넘게 업무 하며 쌓은 모든 기술을 다 공유하고 이전할 수는 없습니다. 회사는 학교가 아니기에...
하지만 회사 내에 개발된 프로그램 및 관련 기술들, 데이터베이스 관리사항에 대해서는 도큐먼트화를 해놓고 부서 내부적으로도 스터디를 통해 공유가 꼭 되어야 합니다.
가장 중요한 건 그걸 인수인계하고 직원 교육을 시키며 구축한 사람은 더 깊이 알게 되고 머릿속에 각인된다는 것입니다.
또한 그로 인해 새로운 것에도 계속 도전하고 멈추지 않을 수 있습니다.
업무보고 또한 공유를 통해 전산팀 내부에 돌아가는 사정은 팀원들과 같이 공유하고 있으며 이로 인해 별도의 설명 없이도 기존 진행하는 프로젝트와 문제사항이 항상 공유되고 있습니다.
처음에는 좀 힘들고 어떤 분은 어렵게 쌓아온걸 굳이 공유할 필요가... 이렇게 생각할지도 모르지만...
기술 공유, 업무 공유로 인해 가장 좋은 건 자유로운 휴가입니다.
내가 없더라도 팀원들이 내 역할을 잘 메꿔 주기에 마음 편한 휴가를 즐길 수 있습니다.
지금도 휴일 뒤에 휴가를 이틀 붙여 ^^ 행복한 휴가를 보내고 있네요.
새벽에 잠을 깨서 생각하다가 문득... 내가 그렇게 업무 공유를 하지 않았으면... ㅎㅎㅎ 생각만 해도 싫네요!!
팀의 능력이 뛰어나지고 팀원들의 능력도 향상되는 장점도 있고 팀원 누구나 자유롭게 휴가를 쓰고 서로 백업을 할 수 있는 게 가장 좋은 거 같네요!!

내가 가진 기술이나 관리 중인 프로그램을 오픈하는 것에 대한 두려움이 있을지 모르지만 1개를 내어주면 2개를 얻게 되어 있습니다 ^^

어제 주간회의 때 임원분께서 전산팀의 본질을 물어보셨다.

-_-a 전산 업의 본질은 멀까...
주저리주저리 대답을 했지만 너무 길다. 딱 잡아서 어떻게 설명할래?
하셨다.. -_-a 말문이 막혔다.
그리고 나와서 곰곰이 생각해 보았다.
전산의 본질은 무얼까....
고민하다. 3단어가 떠올랐다.
신뢰, 신속, 안정 이 3가지가 전산을 표현하지 않을까 라는 생각이 들었다.
신뢰는 전산시스템의 데이터 결과는 항상 정확해서 신뢰할 수 있어야 되고

신속은 전산시스템은 항상 빠르게 데이터 처리해 결과를 보여주어야 되며
안정은 전산시스템은 항상 안정적으로 운영되어야 한다. ( 모든 시스템은 백업 및 이중화를 통해 안정적 운영 )
업의 본질에 대한 질문을 받으면 우리 부서의 본질은 이렇지 않을까 고민을 해보네요.
머.. 이건 정답이 없는 문제이기에...
여러 분들은 어떻게 생각하시나요?

오늘도 출근하다 주절주절 글을 남겨 보네요!!
타 전산팀 분들과도 교류도 많고 하다 보니 여기저기서 주워듣느게 많네요.
오늘 하고 싶은애기는 "데이터베이스 관리 어떻게 관리하시나요?"입니다.

저는 여러 업체를 거치며 오라클, MSSQL을 주로 다루었습니다.
MYSQL 및 기타 데이터베이스도 다루었지만 깊이 있게 공부한 데이터베이스는 2개이고 이중 MSSQL이 주력 데이터베이스 툴입니다.
지금도 관리를 하고 있고요.
운이 좋게도 저번 회사를 다니며 팀장님이 많은 교육 참여 기회를 주셨고 운 좋게도 정원혁 씨가 진행하는 데이터베이스 튜닝 과정 및 운영과정을 들을 수 있었습니다.
그리고 내가 전산팀장이 되면 한번 관리를 제대로 해보겠다고 생각이 들었습니다.
SQL SERVER 기능 중에 보면 유지관리계획이라는 것이 있는데 이를 사용하지 않는 사람들이 너무 많았습니다.
대부분 DATABASE를 설계할 때 인덱스를 구성하면 끝나는 줄 알고 있습니다.
이 인덱스 및 옵티마이저가 활용하는 통계에 대한 업데이트를 무시하고 운영하고 있습니다.
그리고 항상 속도 관련 트러블 이슈가 발생하면 그때야 체크를 하기 시작하죠.
물론 이렇게 관리한다고 해서 느려지는 것을 100% 막을 수는 없습니다.
( 기하급수적으로 늘어나는 데이터를 어쩔 수 없으니까요. )
하지만 이렇게 익 덱스를 재구성하고 통계를 월 단위로 업데이트하는 것만으로도 상당한 성능 향상 효과를 가지고 옵니다.
현재 자사에서 가장 큰 데이터베이스를 5년째 운영 중인데 가동 시점과 현재도 중요 프로세스에서 반응 속도의 거의 차이 없이 유지가 되고 있습니다.
물론 하드웨어가 좋아져서 문제가 발생 안 한 것일 수도 있지만 똑같은 설루션 쓰는 타업체와 비교해도 속도가 빠르다는 것은 해당 유지보수 작업이 효과를 발휘하는 거겠지요.
그리고 가능하면 핵심 쿼리는 주기적으로 테스트하며 동작 시간을 체크해 보는 것도 좋은 방법입니다.
오라클에도 비슷한 기능이 있기에 본인 업무가 개발이 주가 아니라 운영이라면 이 부분에 관심을 가져 보시기 바랍니다.
작은 노력으로 굉장히 큰 효과를 거둘 수 있습니다.
^^;;; 관련 기술에 대한 부분은 검색하면 워낙 많은 자료가 나오기에 여기까지 설명하겠습니다.

저는 항상 매주 수요일 방송되는 골목식당을 빼놓지 않고 보고 있습니다.

저희 부모님이 예전에 자영업을 했던 기억 때문에 공감 가는 부분도 많지만...
회사 생활이나 자영업이나 어차피 원리와 규칙은 같다는 생각이 들어서 많은 것을 배울 수 있어서입니다.

대부분의 사람들은 골목식당을 보면서 주방을 점검할 때 장사하는 분들이 저런 것도 제대로 청소하지 못하고 하네.

음식을 만드는데 노력을 하지 않네 등의 지적을 많이 합니다.
노력 없이 성공할 수 없다며 제대로 노력하지 않는 가계들을 보면 혀를 차게 되지요.

그런데 거꾸로 생각해 보면 우리는 회사생활에서 얼마나 노력을 하시나요?

내 업무를 개선하기 위해 항상 연구하고 노력하고 관련 자료를 찾아보고 실험적인 시도를 해보시나요?

관련 내공을 쌓기 위해 관련 외부 교육을 듣거나 관련 서적을 구입해서 연구하시나요?

제 주위 분들에게 여쭈어 보았지만 대부분 그렇게 하지 않았고 저 또한 그렇게 까지 하지는 못했습니다.
저 또한 그렇게 노력하려고 연초 계획은 세우지만 연중이 되면 세웠던 계획조차 까먹게 되더군요.
그런데 이번 5월 5일에 방송분을 보며.... 느끼는 부분이 많았습니다.

통닭집 사장님이 지난주 방송에서 닭똥집 레시피를 백 대표님이 전수해 주었습니다.
그리고 이번 주에 배우 레시피로 열심히 만들었고 작가분들과 같이 시식을 했는데 그 맛이 안 나고 제대로 튀겨지지 않는 것이었습니다.
그리고 사장님은 수십 번 계속적으로 튀겨 보았지만 결과는 마찬가지로 모두 실패였습니다.
그리고 결국은 백 대표님이 다시 통닭집을 방문하게 되었고 통닭집 사장님에게 한번 해보라고 하시며 뒤에서 지켜보았습니다.
그리고 튀김 상태를 체크 후 원인을 찾아내었습니다.
해당 원인은 닭똥집에 튀김옷을 입히기 전에 미끌미끌한 닭똥집이 튀김옷을 제대로 받아들이지 못하니 튀김가루를 한번 묻혀서 튀기는 방식으로 레시피를 만들어 준 것이었습니다. 그런데 통닭집 사장님은 이 개선책을 대충대충 하였던 것입니다. 튀김가루가 아깝다고 생각이 되었는지 조금만 투입 후 주걱으로 휙휙 젖은 후 튀김옷을 입혀 튀겼고 백 대표님은 큰 그릇에 튀김가루를 수북이 넣은 후 그곳에 닭똥집을 넣고 손으로 꼼꼼히 바른 후 채를 이용해 한번 털어주었습니다.
문제는 레시피를 만들어 줄 때 백 대표님이 이 부분을 설명하며 가르쳐 준 방법이었다는 거지요.

거짓말같이 이 방법만 바꾼 후 다시 튀긴 닭똥집 튀김은 맛있는 맛을 되찾을 수 있었습니다.
그런데 만약 백 대표님이 가지 않았다면 그 사장님이 이 방법을 다시 찾을 수 있었을까요?

우리도 회사일을 하다 보면 이런 경우를 다반사로 보게 됩니다.
업무에 대한 지식이 짧다 보니 해당 일 데 대한 문제점을 제대로 집어내지 못하고 주위에서 맴돌며 해결하지 못하고 쩔쩔매는 상황이 간헐적으로 보이죠.

이 부분은 자신 업무에 대한 공부가 부족하기 때문이고 노력하지 않기 때문입니다.
여러 번 도전해보고 실패해봐야 문제를 바라보는 눈을 가질 수 있게 됩니다.

백 대표님은 산전수전 다 겪으며 엄청난 노력과 공부를 했고 그로 인해 문제를 꿰뚫어 보는 능력이 생긴 거 같습니다.

이번 주 골목식당을 보며 나는 언제쯤이나 저런 안목을 가질 수 있을까 라는 생각이 들며... 이 글을 작성해 보네요.
앞으로 좀 더 많은 책을 읽고 프로그래밍 공부도 더 노력해야 될 거 같네요!!

자기반성을 하게 만드는 골목식당이네요~~^^;;;

몇 년 전부터 윈도우10 PC 도입을 진행해왔고 작년 구입 PC부터 메모리를 8기가를 기본으로 채택했다.
그 이전에 들어온 PC는 메모리 4기가로 구입이 되었다.
대부분 사용자가 문서작성 위주의 작업을 해기 때문에 문제가 생기지 않았는데...
올초 업데이트 후 문제가 생기기 시작했다.
몇몇 사용자가 문제를 얘기했고 다행히 스페어로 보유 중이던 메모리 추가를 통해 메모리 부족 증상으로 확인했다.
이후 바로 기안을 하여 본사,공장 PC에 대한 메모리 업그레이드 작업을 했다.
느려진 PC를 사용하면서 왜 느린지 모르는 직원도 있었으며 새 PC 구매한 거 같이 좋아하는 직원도 있었다.
하기야 스마트폰도 12기가씩 메모리가 탑재되는 세상에....
4기가는 작은거 같긴 하다. 그래도 현재 기본형으로 4기가 탑재 모델이 많이 판매되고 있으니 이건 문제인 듯하다.

별거 아닌 메모리 구입하여 업그레이드를 해주면서 뿌듯한 기분이 들어 글을 남겨본다.
오히려 프로그램 개발할 때와는 다른 만족감이 생기기에 글까지 쓰게 되네요.
업그레이드 후 만족하는 직원들을 보는 것만큼 기분 좋은 일이 있을까요 ^^;;;

개발 업체에서 일하다가 전산실 생활을 한지만 벌써 10년 하고도 한참 넘어갔다.
그 사이에 가장 많이 변한 부분은 개발 인프라인 것 같다.
C/S 중심의 개발에서 웹기반 개발로 패러다임이 바뀐 것이고
그리고 그 중앙에는 스마트폰과 태블릿이라는 신형 병기의 탄생이 있었다.
벌써 아이폰이 발표한지도 오랜 시간이 지났다.
아직도 잡스가 연단에 서서 세상을 바꾸는 아이폰을 발표한 PT가 눈에 선하다.
어찌 보면 우리는 전산 실안에 안정된 직장을 가지고 있다는 생각에 세상이 변해가는 거에 너무 둔감해지는지도 모르겠다.
하지만 우리는 그렇게 있으면 안된다.
아이폰 발표 전까지 전 세계를 주름잡던 노키아....
요즘 친구들은 노키아 얘기하면 폰 만드는 업체인지도 모를 것이다.
기업도 트렌드를 따라가지 못하면 도태되고 역사의 저편으로 사라지게 된다.

난 우리 전산실 직원들도 똑같다고 생각한다.
과거에 인프라를 이루던 C/S 개발 툴인 C#, 델파이, 비주얼 베이직, 델파이만 다룰 줄 알고 DBMS만 능숙하게 다루면 먹고살 걱정이 없다고 생각했는데...
10년 전부터 이슈가 되던 HTML5, JQUERY, 부트스트랩 등의 여러 가지 기술이 발전하고
브라우저가 HTML5 완벽히 지원하면서 노 리플래쉬 사이트가 당연하게 되었으며
웹으로도 업무용 프로그램 개발에 벽이 허물어졌다.
그리고 우리 직원들은 PC가 아닌 태블릿, 스마트폰, 노트북으로 이동을 하며 5G 통신망을 통해 애플리케이션을 사용하는 시대를 살게 되었다.
이제는 우리도 변하지 않으면 설 자리가 점점 줄어드는 것 같다.
물론 우리가 외부 개발자들처럼 설루션 정도의 시스템 개발을 힘들지만 사내 업무처리 프로그램 정도는 개발할 능력을 보유해야 향 후 설루션을 도입하더라도 기술을 알고 도입을 할 수 있을 것이다.
그래서 불행히도 계속 공부해야 되는 삶인 것 같다....

아침에 출근하다 문득 이런 생각이 들어 글을 남겨보네요~~!!

전산팀으로 일하다 보면 95% 이상의 일은 현업부서의 업무를 서포트하기 위한 일이다.
그리고 한부서가 아닌 여러 부서 간의 협업이 필요하기에 회의는 필요하다.
그런데 한가지 재미있는 점이 있었다.
회의를 하자고 하는데 회의에 내용에 대해 미리 공지해 주지 않는다.
나는 회의를 들어가기 전까지 회의 주제에 대해 검토 한번 못해보고 들어가게 된다.
그리고 회의에 들어가 갑자기 훅 들어오는 질문에 대해 갑자스런 답병을 해야 되고 회의는 그런 이유로 인하여 지연되게 된다.

10분이면 끝날 회의가 30분 심지어는 1~2시간동안 결말을 못 짓고 지연되게 된다.
그래서 다년간 회의 참석을 하고 최근들어서는 개선안을 정해놓고 최대한 지키려 노력하고 있다.

[회의 시작전 공지 메일에 명시한 내용]
1. 회의 참석자들에게 회의 내용에 대한여 정리한 메일은 최소 회의 2시간 전이나 1~2일 전에는 미리 통지한다.
2. 회의 참석자들명단과 회의장소, 시간을 명시하여 전달한다.
3. 관련 참고자료가 있으면 꼭 첨부하여 참석자들이 미리 검토를 하고 올 수 있도록 한다.

위와 같이 메일을 미리 보내 놓으면 참석자들은 본인이 답변할 내용을 미리 준비해 올 것이며 서로 의견이 안 맞는 내용만 조율하면 빨리 회의를 마무리할 수 있다.
그리고 제일 중요한것은 회의가 끝난 후 최대한 빠른 시간 내에 회의 내용을 정리하여 참석자들에게 결고를 통지해준다.
사람은 망각의 동물이라 애기했던 내용을 금방 까먹는다.
되도록 회의를 주관했던 사람이 정리를 해서 메일을 보내주고 혹시나 잘못된 부분에 대한 피드백을 받으면 최대한 빨리 조정해서 전달해주기를 바란다.
이를 통해 반복적인 회의를 줄일 수 있고 불필요한 회의를 할 필요가 없다.
다들 내 아까운 시간을 들여 왜 회의 결과 메일을 보내냐고 묻겠지만.... 이게 내 시간을 가장 절 양하는 방법인 것 같다!!
해본 적인 없다면 한번 해보시기 바랍니다!!

전산을 주 업으로 하는 회사의 경우야 틀리겠지만...
대기업을 제외하고는 전산팀은 아주 소규모 조직입니다.
2~3인으로 이루어진 전산팀이 많으며 1인 전산팀도 의외로 많습니다.
이렇게 팀원도 작업 혼자 일하는 경우도 있다 보니 가장 문제는 의논할 사람이 없다는 것입니다.
저도 몇년 전까지 1인 전산을 몇 년간 하며 가장 힘든 부분이었습니다.
그래도 전에 다니던 사람들과 전산을 하던 인맥이 있어 물어보고 상담을 했지만...
그건 노멀한 전산에 대한 부분만 가능하고 업종에 국한되어 쓰이는 부분은 정말 답이 없었습니다.
그래서 시작한 모임 만들기가... 2년 전 성공하여 지금은 탄탄한 모임으로 발전하였고...
여러 선배님과 후배들이 같이하는 모임이 되었고!!
무슨 일이든 터놓고 논의하는 모임으로 발전이 되었습니다.
단순히 모임하나만 생긴 것이 아니라 나의 든든한 버팀목으로 발전하였습니다.
아직도 혼자 고민하거나 회사내 팀만 고민을 해결하려고 하고 있다면...
같은 산업군 전산실의 모임을 만들어 보시기 바랍니다.
같은 고민을 하고 같은 고생을 하는 사람들이 모여서 고민하면 정말 높은 시너지 효과를 낼 것입니다~~!!
출근하다 문뜩 생각이 나서 글을 써보네요~~!!

최근 특정부서의 요청으로 정신없이 바쁜 하루하루를 보내고 있네요!!

스케줄에 없던 개발이라 그 파트를 담당하는 직원도 힘들고 관련 미팅에 참석하고 스케줄을 조정해야 되는 저도 힘드네요!!

이 또한 해야 되는 일이기에 갑자기 끼어든 일에는 짜증이 나지만 잘 처리해야 되는 일이기도 하죠!!

저와 마찬가지고 빠듯한 일정에 쫓기는 팀원에게 하필이면 이럴 때 꼭 유지보수하는 프로그램에 문제가 생깁니다.
그 팀원도 바쁜 마음에 그렇게 했을꺼라 생각하지만...

갑자기 질문할것이 있다고 해서... 그럼 얘기 해보라고 하니까..

잠깐 와서 자기 모니터를 봐야된다고 합니다.
그래서 팀원에 자리로 가서 프로그램을 보았는데...

문제에 대한 데이터 분석, 그리고 왜 에러가 났는지에 대한 검토도 없이...
이거 왜 이래요? 그런 질문을 하는 것입니다.
참고로 전 질문하는걸 좋아합니다. 질문에 대한 답변을 해주면 저도 발전하고 그걸 듣고 업무에 응용하는 팀원도 발전을 하니까요.
하지만 최악은 아무런 검토도 하지 않고 팀장한테 답을 찾으려는 담당자는? 

제가 없을때 문제 터지면 전화할 건가요? 그건 아니죠.
결국은 질문하는 타이밍과 본인이 꼭 해야되는 데이터 리뷰가 빠져서 회의실로 끌려 들어와 제 잔소리를 들었죠.
그리고 제가 왜 이러는지는 본인 밑에 후임을 가리킬 때 알 거 같네요!!
아마다 본인 생각에는 "아  그냥 말해주면 되지 구지 이렇게까지 해야 돼?" 생각이 들겠지만...
혼자서 자랍할 수 없게 만들어 버리는 것은 저는 최악이라고 생각합니다.
제가 팀장이지 선생님은 아니거든요 ^^;;;

나름 저와 같이 일하면서 많이 실력이 늘은 친구라고 생각하는데.. 어제는 좀 실망스러웠네요!!
잘 갈고 닦아서 좋은 개발자로 발전했으면 하는 마음에 글을 남겨보네요!!