프로그램 개발 업체, 계약 전 유지보수 구조부터 안 보면 오픈 후 더 답답해집니다
프로그램을 새로 만들 때는
대부분 납품 전까지만 생각하게 됩니다.
기획이 잘 되고 있는지,
개발 일정은 맞는지,
오픈은 언제 가능한지 같은 것들 말입니다.
그런데 실제로는 오픈 이후가 더 중요해지는 경우가 많습니다.
프로그램은 오픈 이후부터 진짜 운영이 시작됩니다
실제 사용자가 붙기 시작하면
개발 단계에서는 보이지 않던 문제들이 하나씩 드러나기 시작합니다.
특정 브라우저에서만 화면이 깨지거나,
동시 접속자가 많아질 때 갑자기 속도가 느려지거나,
특정 조건에서만 데이터 저장이 꼬이는 식의 문제는
운영하면서 발견되는 경우가 많습니다.
그래서 프로그램 개발 업체를 고를 때
포트폴리오나 가격만 보고 결정하면
나중에 예상보다 더 큰 불편을 겪을 수 있습니다.
유지보수 계약 구조를 먼저 확인해야 합니다
특히 많이 놓치는 부분이 유지보수 계약 구조입니다.
오코랩스에 재개발 문의를 주시는 분들 중에도
이전에 맡긴 프로그램 개발 업체와 연락이 끊겼다는 이야기를 자주 하십니다.
납품은 이미 끝났고,
잔금도 다 지급했고,
오픈도 정상적으로 했는데
한 달쯤 지나 오류가 하나 생기면
그때부터 연락이 잘 안 되는 경우가 있다는 겁니다.
메신저 답변이 늦어지고,
전화가 잘 연결되지 않고,
결국 문제는 생겼는데 처리 기준이 없는 상태가 되어버립니다.
유지보수 조건을 계약 단계에서 제대로 확인하지 않으면, 오픈 후 문제가 생겼을 때 기준 없이 답답한 상황이 반복될 수 있습니다.
하자 보수 기간과 범위는 문서로 남겨야 합니다
유지보수 계약에서 가장 먼저 봐야 하는 건 하자 보수 기간입니다.
하자 보수 기간은
오픈 후 일정 기간 안에 발견된 오류를
무상으로 수정해주는 구간입니다.
보통 1개월에서 3개월 사이로 잡는 경우가 많지만,
중요한 건 기간 숫자만이 아닙니다.
그 기준이 계약서에 명시되어 있는지가 훨씬 중요합니다.
이 내용이 없으면 나중에 오류가 생겼을 때
이게 하자인지, 추가 요청인지 해석이 달라집니다.
의뢰사는 당연히 수정해줘야 한다고 생각하고,
프로그램 개발 업체는 새로운 요청이라며 추가 비용을 말할 수 있습니다.
이런 다툼은 대부분 처음에 기준이 없어서 생깁니다.
그래서 하자 보수 기간과 그 범위를 문서로 명확하게 적어두는 것이 중요합니다.
하자 보수 이후의 유지보수 방식도 봐야 합니다
그런데 사실 더 중요한 건 하자 보수 기간이 끝난 뒤입니다.
프로그램은 한두 달만 쓰고 끝나는 게 아니기 때문에
장기 운영에서 어떤 방식으로 유지보수 비용이 붙는지가
프로그램 개발 업체를 고르는 진짜 기준이 되기도 합니다.
유지보수 구조는 보통
건당 청구, 월정액, 시간제처럼 나뉘는 경우가 많습니다.
유지보수 계약 방식별 차이
- 건당 청구: 수정이 필요할 때마다 따로 견적을 내는 방식
- 월정액: 매달 일정 비용을 내고 정해진 범위 안에서 대응받는 방식
- 시간제: 실제 사용한 작업 시간만큼 비용을 내는 방식
건당 청구는 작은 수정은 가볍게 대응할 수 있지만
수정 빈도가 잦아지면 생각보다 비용이 빠르게 커질 수 있습니다.
월정액은 안정적일 수 있지만
중요한 건 어디까지 포함되는지입니다.
텍스트 수정만 포함되는지,
기능 수정도 가능한지,
서버 관리까지 포함되는지에 따라 체감 차이가 매우 큽니다.
시간제는 실제로 사용한 작업 시간만큼 비용을 내는 구조입니다.
수정 빈도가 많지 않고
가끔 필요한 대응만 있는 시스템에는 오히려 합리적일 수 있습니다.
결국 어떤 구조가 맞는지는
지금 시스템이 어떤 방식으로 운영될지에 따라 달라집니다.
소스코드 소유권도 반드시 확인해야 합니다
또 하나 반드시 확인해야 할 것이 소스코드 소유권입니다.
이 부분은 처음엔 크게 와닿지 않을 수 있지만
나중에 프로그램 개발 업체를 바꾸거나
내부에서 직접 관리하려는 시점이 오면 차이가 크게 드러납니다.
납품 받은 프로그램의 소스코드가 누구에게 귀속되는지
계약서에 명확하지 않으면
나중에 다른 업체에 유지보수를 맡기기도 어렵고,
직접 수정하려고 해도 손을 못 대는 상황이 생길 수 있습니다.
소스코드는 납품과 함께 전달되는지, 개발 문서도 같이 받는지, 계약서에 명확하게 적혀 있는지를 꼭 확인해야 합니다.
담당자 연속성도 운영 안정성에 영향을 줍니다
프로그램 개발 업체를 고를 때
담당자 연속성도 생각보다 중요합니다.
처음 개발을 했던 사람이
이후 유지보수까지 이어서 보는지,
아니면 오픈 이후에는 전혀 다른 팀으로 넘어가는지도 반드시 물어봐야 합니다.
개발한 사람과 유지보수 담당자가 다르면
문제 발생 시 코드를 다시 파악하는 시간이 길어질 수 있습니다.
그러면 급한 오류가 생겼을 때
바로 수정되는 게 아니라
파악 중이라는 답변만 며칠 이어질 수도 있습니다.
특히 운영 중인 프로그램은
오류 하나가 업무 전체를 멈추게 할 수도 있기 때문에
오류 발생 시 대응 시간과 담당자가 어떻게 이어지는지까지
계약 전에 확인해두는 것이 좋습니다.
계약 전 꼭 확인해야 할 유지보수 항목
- 하자 보수 기간이 있는지
- 하자 보수 범위가 어디까지인지
- 유지보수는 건당, 월정액, 시간제 중 어떤 방식인지
- 소스코드 소유권은 누구에게 있는지
- 오류 발생 시 대응 시간과 담당자는 어떻게 정해지는지
결국 프로그램 개발 업체를 고를 때
견적서에 유지보수 관련 항목이 없다면
그 계약은 절반만 정리된 상태일 가능성이 큽니다.
포트폴리오가 좋아 보여도 유지보수 구조가 약하면
오픈 후 더 피곤해질 수 있습니다.
반대로 처음부터 이 기준이 선명한 프로그램 개발 업체는
문제가 생겼을 때도 훨씬 덜 흔들립니다.
오코랩스도 프로그램 개발을 진행할 때
처음부터 유지보수 구조를 함께 정리합니다.
하자 보수 기간, 운영 이후 대응 방식, 소스코드 전달,
오류 대응 기준까지 문서로 잡아두어야
오픈 이후에도 기준이 흔들리지 않기 때문입니다.
프로그램 개발 업체를 알아보는 중이라면
가격과 기능만 보지 마시고
유지보수 계약 구조부터 꼭 같이 확인해보셔야 합니다.
오픈은 시작일 뿐이고,
실제로 중요한 건 그 이후에도 계속 움직이는 시스템을
누가 어떻게 책임지느냐이기 때문입니다.
프로그램 개발 업체, 계약 전 유지보수 구조부터 안 보면 오픈 후 더 답답해집니다
프로그램을 새로 만들 때는
대부분 납품 전까지만 생각하게 됩니다.
기획이 잘 되고 있는지,
개발 일정은 맞는지,
오픈은 언제 가능한지 같은 것들 말입니다.
그런데 실제로는 오픈 이후가 더 중요해지는 경우가 많습니다.
실제 사용자가 붙기 시작하면
개발 단계에서는 보이지 않던 문제들이 하나씩 드러나기 시작합니다.
특정 브라우저에서만 화면이 깨지거나,
동시 접속자가 많아질 때 갑자기 속도가 느려지거나,
특정 조건에서만 데이터 저장이 꼬이는 식의 문제는
운영하면서 발견되는 경우가 많습니다.
그래서 프로그램 개발 업체를 고를 때
포트폴리오나 가격만 보고 결정하면
나중에 예상보다 더 큰 불편을 겪을 수 있습니다.
유지보수 계약 구조를 먼저 확인해야 합니다
특히 많이 놓치는 부분이 유지보수 계약 구조입니다.
오코랩스에 재개발 문의를 주시는 분들 중에도
이전에 맡긴 프로그램 개발 업체와 연락이 끊겼다는 이야기를 자주 하십니다.
납품은 이미 끝났고,
잔금도 다 지급했고,
오픈도 정상적으로 했는데
한 달쯤 지나 오류가 하나 생기면
그때부터 연락이 잘 안 되는 경우가 있다는 겁니다.
메신저 답변이 늦어지고,
전화가 잘 연결되지 않고,
결국 문제는 생겼는데 처리 기준이 없는 상태가 되어버립니다.
유지보수 조건을 계약 단계에서 제대로 확인하지 않으면, 오픈 후 문제가 생겼을 때 기준 없이 답답한 상황이 반복될 수 있습니다.
하자 보수 기간과 범위는 문서로 남겨야 합니다
유지보수 계약에서 가장 먼저 봐야 하는 건 하자 보수 기간입니다.
하자 보수 기간은
오픈 후 일정 기간 안에 발견된 오류를
무상으로 수정해주는 구간입니다.
보통 1개월에서 3개월 사이로 잡는 경우가 많지만,
중요한 건 기간 숫자만이 아닙니다.
그 기준이 계약서에 명시되어 있는지가 훨씬 중요합니다.
이 내용이 없으면 나중에 오류가 생겼을 때
이게 하자인지, 추가 요청인지 해석이 달라집니다.
의뢰사는 당연히 수정해줘야 한다고 생각하고,
프로그램 개발 업체는 새로운 요청이라며 추가 비용을 말할 수 있습니다.
이런 다툼은 대부분 처음에 기준이 없어서 생깁니다.
그래서 하자 보수 기간과 그 범위를 문서로 명확하게 적어두는 것이 중요합니다.
하자 보수 이후의 유지보수 방식도 봐야 합니다
그런데 사실 더 중요한 건 하자 보수 기간이 끝난 뒤입니다.
프로그램은 한두 달만 쓰고 끝나는 게 아니기 때문에
장기 운영에서 어떤 방식으로 유지보수 비용이 붙는지가
프로그램 개발 업체를 고르는 진짜 기준이 되기도 합니다.
유지보수 구조는 보통
건당 청구, 월정액, 시간제처럼 나뉘는 경우가 많습니다.
건당 청구는 작은 수정은 가볍게 대응할 수 있지만
수정 빈도가 잦아지면 생각보다 비용이 빠르게 커질 수 있습니다.
월정액은 안정적일 수 있지만
중요한 건 어디까지 포함되는지입니다.
텍스트 수정만 포함되는지,
기능 수정도 가능한지,
서버 관리까지 포함되는지에 따라 체감 차이가 매우 큽니다.
시간제는 실제로 사용한 작업 시간만큼 비용을 내는 구조입니다.
수정 빈도가 많지 않고
가끔 필요한 대응만 있는 시스템에는 오히려 합리적일 수 있습니다.
결국 어떤 구조가 맞는지는
지금 시스템이 어떤 방식으로 운영될지에 따라 달라집니다.
소스코드 소유권도 반드시 확인해야 합니다
또 하나 반드시 확인해야 할 것이 소스코드 소유권입니다.
이 부분은 처음엔 크게 와닿지 않을 수 있지만
나중에 프로그램 개발 업체를 바꾸거나
내부에서 직접 관리하려는 시점이 오면 차이가 크게 드러납니다.
납품 받은 프로그램의 소스코드가 누구에게 귀속되는지
계약서에 명확하지 않으면
나중에 다른 업체에 유지보수를 맡기기도 어렵고,
직접 수정하려고 해도 손을 못 대는 상황이 생길 수 있습니다.
소스코드는 납품과 함께 전달되는지, 개발 문서도 같이 받는지, 계약서에 명확하게 적혀 있는지를 꼭 확인해야 합니다.
담당자 연속성도 운영 안정성에 영향을 줍니다
프로그램 개발 업체를 고를 때
담당자 연속성도 생각보다 중요합니다.
처음 개발을 했던 사람이
이후 유지보수까지 이어서 보는지,
아니면 오픈 이후에는 전혀 다른 팀으로 넘어가는지도 반드시 물어봐야 합니다.
개발한 사람과 유지보수 담당자가 다르면
문제 발생 시 코드를 다시 파악하는 시간이 길어질 수 있습니다.
그러면 급한 오류가 생겼을 때
바로 수정되는 게 아니라
파악 중이라는 답변만 며칠 이어질 수도 있습니다.
특히 운영 중인 프로그램은
오류 하나가 업무 전체를 멈추게 할 수도 있기 때문에
오류 발생 시 대응 시간과 담당자가 어떻게 이어지는지까지
계약 전에 확인해두는 것이 좋습니다.
결국 프로그램 개발 업체를 고를 때
견적서에 유지보수 관련 항목이 없다면
그 계약은 절반만 정리된 상태일 가능성이 큽니다.
포트폴리오가 좋아 보여도 유지보수 구조가 약하면
오픈 후 더 피곤해질 수 있습니다.
반대로 처음부터 이 기준이 선명한 프로그램 개발 업체는
문제가 생겼을 때도 훨씬 덜 흔들립니다.
오코랩스도 프로그램 개발을 진행할 때
처음부터 유지보수 구조를 함께 정리합니다.
하자 보수 기간, 운영 이후 대응 방식, 소스코드 전달,
오류 대응 기준까지 문서로 잡아두어야
오픈 이후에도 기준이 흔들리지 않기 때문입니다.
프로그램 개발 업체를 알아보는 중이라면
가격과 기능만 보지 마시고
유지보수 계약 구조부터 꼭 같이 확인해보셔야 합니다.
오픈은 시작일 뿐이고,
실제로 중요한 건 그 이후에도 계속 움직이는 시스템을
누가 어떻게 책임지느냐이기 때문입니다.