오랜만에 질문 올립니다.
미리 말씀드리지만 전 프로그래밍이나 IT와는 전혀 무관하고 단지 컴에 관심있는 일반 직딩임을 밝힙니다.
우리회사에 여러가지 전산시스템이 있는데, 그중 한개 시스템의 관리자가 저입니다.
R&D 사업관리시스템인데요...
3년 정도 시스템 개발하고 보완하고 고도화하는데 꾸준히 투자해 왔습니다.
그것이 2008년 하반기에 완료되었습니다.
그런데 아직도 버그가 많이 존재하고 일반사용자들(연구원들)은 시스템 사용하기가 너무 복잡하고
어렵다고 불평하고 있으며, 저는 저나름대로 스트레스를 많이 받고 있습니다.
(이모티콘 사용불가가 너무 아쉽군요)
왜냐하면, 원래 이시스템의 관리 업무가 제가 아니라 다른 분이었는데 딴데로 가셔서 얼떨결에 제가 맡은 겁니다.
제 업무는 이것말고 훨씬더 중요한(하다고 생각되는) 업무가 아주 많습니다.
올해엔 그만할 때도 된 것같은데, 아직 고쳐야할 부분이 많네요.
그런데, 시스템 개발업체는 너무 영세하고, 그나마 이 시스템 개발한 엔지니어는 퇴직했고,
사장님은 계속 돈얘기만 합니다.
머, 제가 공짜로 고쳐달라는 이야기는 한 적이 없습니다만, 시스템 개발후 1년은 유지보수를 해야된다고 알고 있는데...(그게 2009년 하반기 까지 인가 가물가물 하네요...쩝)
내년에 DB 통합하면서 또 시스템에 대폭적으로 손을 대야 할지도 모른다고 하구요.
제가 궁금한 것은
한업체가 닷넷으로 개발한 시스템을 다른 업체가 시스템을 일부 수정하거나 보완이 가능한가요?
필요하다면, 올해까지 유지 보수 계약을 적당한 선에서 계약하고 내년에 시스템 손댈때엔 다른 업체에 맡길 생각이 있습니다.
시스템을 완전히 새로 갈아엎는 것은 아니고 여기 시스템에서 조금 확장해볼까 생각하는데...
퇴직한 개발자 엔지니어가 다시 맡을 수 있을 지는 모릅니다.
아마 전혀 다른 업체와 엔지니어가 될 수도 있습니다.
전혀 다른 업체가 손을 댈수 있습니까?
1년에 몇천만원씩 몇년간 만들어온 시스템이지만, 그래도 확 갈아엎기엔 아깝습니다.
제가 이쪽에 관심이 있는 것은 사실이지만, 구체적으로 이야기하려니 너무 뒤죽박죽이네요.
오프모임에서 소주한잔 하면서 여쭙고 싶기도 합니다만, 우선 게시판에 질문글 올려 봅니다.
아... 사장님 너무 맘에 안듭니다.
시스템 개발의 최종 목적은 유저들이 좀더 편리하게 사용하고,
좀더 효율적으로 업무를 수행하며, 체계적으로 나아가기 위해서라고 이해하고 있는데요..
이 시스템은 유저는 불편하고, 시스템은 에러메시지나 내뱉고,
문제 생기면 해결해줄 사람도 없고, 일을 더 복잡하게 만들어 버리는 군요.
확 갈아엎어버리고 싶습니다.
이것만 신경쓴다면 머라도 해볼텐데, 그것도 불가능하고,...
하도 답답한 마음에 글올려 봤습니다.
몇자 적으니 정리는 어느정도 되는 군요.
좋은 주말 되세요.
그럼 이만.
영세한 업체의 단점이 그거죠. 기존에 알고 있던 엔지니어가 나가면 추후 유지보수가
거의 불가능에 가깝게 되버리는 문제점이 있습니다.
현재의 시스템을 다른 업체에 의뢰해서 파악하고 나서 차츰 수정하는 것보다
새로 그 업체에서 만들어내는게 비용 및 시간에서 유리하지 않을까 싶습니다.
예전 그런 경우를 봤습니다만 기존 업체에서 엔지니어 나가고 나서 인수인계 안되고 하다가
결국엔 그 유지보수 업체 위약금 물고 쫓겨났습니다. 기존 시스템은 임시로 그냥 사용하다가
추후엔 다 갈아엎고 새로 만들었는 걸로 알고 있습니다.
가능하시면 유지보수 보다는 신규가 더 나을 듯 합니다.
소스가 없다면, 그것 개발 한 분이나 그 소스 가지고 있는 업체에서 진행이 가능 합니다.
확실한 설계서가 없는 다음엔 리모델링보다는 새로 짓는 것이 더 나을수도 있거든요.
저도 닷넷쪽 프로그램을 하고 있지만, 업체에 들어가면 종종 그런 일을 맡고 있습니다.
예전 시스템은 놔두고 문제 부분만 새로 만들어서 인터페이스만 시키는 방향으로 처리하고 있습니다.
현업이 나름대로 내부구조를 잘 파악하고 있는 곳은 안심하고 처음부터 뜯어고치는 것이 가능한데
대개는 난 전혀 아는 것이 없으니 알아서 하세요. 하는 경우가 많아서요. ^^
- 윗분들 말처럼 몇몇 간단한(그렇다고 판단되는)기능수정은 IT밥좀 먹은 사람이라면 그렇게 어렵지는 않을것입니다.
- 그렇지만 가장 중요한것은 어느정도 규모이상의 서비스는 개발자의 영역보다는 그 업무를 잘 파악하고 있는 기획자를 가지고 있는가가 중요하게 됩니다.
그냥 대충 기간 맞춰 - 그것도 항상 못 맞추지만 - 모양만 번지르하고 쓰기 힘들게 만들어 놓는 경우가 대부분입니다.
좋은 개발자 만나서 새로 만드는 걸 권하고 싶은데.
저희도 얼마전에 정부 보조금 받아서 만들었는데, 쓰지도 못하고 있습니다.
소프트웨어를 하드웨어 번들로만 인식해온 계약상의 갑이 지금도 여전히 있고, 하청에 재하청에 인건비를 후려치는 산업구조도 좋은 개발자를 떠나도록 만들어왔지요. 제일 답답한 건 나날이 복잡한 컴퓨팅환경에서 좋은 개발자보다도 좋은 설계자는 더더욱 희귀하도록 만든 것이지요. 아키텍트가 없다고 할 것만 아니라, 제대로된 모델러나 분석가는 더더욱 없습니다.
그저 짬밥만 먹었다고, 진급해서 관리자 대열에 들어섰다고 무조건 분석, 설계, PM 하면 된다고 생각하는 한심한 세태가 진짜 전문가를 만들지 못하도록 한 것이지요.
물건너 미쿡 땅에선 분석가나 모델러가 유망직종 2, 3위를 하는 마당에 우리땅에선 그런 직업이 뭐하는 거냐고 비아냥 대는 대기업 간부와 관료들을 갑이니까 참아야 한다고 삭이고 있지요. 애플과 구글에게 밀리는 진정한 이유가 이런 삽질 사고방식을 가진 인간들이 갑이고 관료들이기 때문입니다.
일반적으로 하드웨어 시스템 구축과 소프트웨어 시스템 구축이 방법이나 목적에서 많이 다릅니다.
가시적인 하드웨어와 달리 방대한 량의 소스코드가 있는 소프트웨어의 경우, 유지보수는 결코 간단하지 않습니다.
원래 제작자가 아닌 다른 소프트웨어 프로그래머가 유지보수가 가능하냐는 질문에는 대부분 쉽지 않다고 답변을 해야 할 것입니다. 이유는 복잡성에 있습니다.
흔히 업무용 시스템을 구축하는 프로젝트는 총책임자인 프로젝트 매니저, 업무와 요구사항을 분석하는 시스템 분석가, 하드웨어와 소프트웨어 전체의 기술적 책임을 담당하는 아키텍트, 그외에 DBA 또는 각 분야별 전문엔지니어들로 멤버가 구성이 되어 진행합니다.
이 중에서 분석가가 업무와 시스템 양쪽을 모두 알고 있고, 실제 시스템 설계를 겸하는 경우가 많습니다.
흔히 소프트웨어 프로젝트의 산출물이라고 부르는 것에는 실행코드 외에도 소스코드와 관련 설계문서들이 모두 포함되어야 합니다. 소스코드가 있으면 유지보수가 가능하다고 하는 것은 소스코드의 분량이 많지 않고, 업무가 단순한 경우에는 가능할 수도 있습니다. 하지만, 실제 많은 시스템들이 소스코드는 확보하지만, 설계 관련 문서를 확보하지 못하거나 부정확한 설계문서를 갖고 있는 경우가 대부분입니다. 문서도 제때 업데이트가 되지 않으면 도움은 커녕 오히려 혼란만 주는 불필요한 경우도 있을 수 있습니다.
요컨데, 설계문서도 제대로 없고, 소스코드에는 주석도 제대로 달려있지 않다면, 그 소스를 보고 시스템 세부사항을 모두 이해하고 새로히 추가 또는 변경을 하는 작업에는 많은 시간과 인력이 투입되기 마련일 것입니다. 결국 인건비가 얼마나 들어갈지 곰곰히 잘 계산해 봐야 하는 문제가 생깁니다.
많은 경우, 남의 소스코드를 보고 파악을 하는 경우는 드뭅니다. 이유는 잘 짜여진 소스라면 읽기가 즐겁지만, 대충대충 납기시간에 쫓겨 만들어진 소스코드를 읽는 것은 결코 쉽지 않고 많은 훈련과 시간과 노력이 필요합니다. 그래서 흔히 프로그래머들 사이에는 남이 반쯤 만들다가 둔 소스를 고쳐서 완성하느니 처음부터 혼자서 새로 만드는 것이 훨씬 시간상 빠르다는 말을 자주 듣게 됩니다. 남의 생각을 이해하면서 업무요구사항도 충족시키느니, 아예 업무요구사항에 집중해서 처음부터 자신의 로직을 세우는 것이 훨씬 더 빠르다는 것이지요.
물론 원칙상 다른 프로그래머가 유지보수를 맡아도 금새 적응할 수 있도록 소스를 만들어야 하지만, 사람이기 때문에 개인차도 심하고 현실상 개발조직의 문화도 문제가 있는 등으로 인해 어렵습니다. 물론 요즘 닷넷과 같은 소스들은 예전에 비하면 분량은 많이 줄어들어서 이전과 비교하면 부담이 상대적으로 줄어들기는 했습니다. 그러나 시스템의 크기가 얼마인지 모르니 정확한 것은 달라질 수 있겠지요. 그리고 유지보수를 맡는 프로그래머의 실력이 어떠냐에 따라서도 천차만별이라고 할 수 있습니다.
유지보수인가 아니면 추가개발인가에 대해서도 분명히 구분을 지어야 할 것입니다. 단순 유지보수와 달리 추가개발은 업무 추가 또는 변경으로 인해 소프트웨어 코드의 추가가 일정량 이상이면 새로운 프로젝트로 봐야 합니다.
어차피 시스템도 일정한 수명이 있으므로 가동기간이 몇년이 지나면 새로히 구축하는 것도 방법일 것입니다.