오픈 이후가 진짜 시작입니다. 서비스는 계속 운영되면서 버그 수정, 기능 추가, 서버 관리가 필요합니다. 유지보수가 실제로 어떻게 진행되는지, 계약 방식과 자주 묻는 질문까지 함께 정리했습니다.
1. 유지보수의 세 가지 유형
- 버그·오류 수정 — 발견된 문제를 고치는 대응형 작업
- 기능 추가·고도화 — 서비스 성장에 맞춰 새 기능을 붙이는 작업
- 정기 운영 관리 — 서버, 보안, 라이브러리 업데이트 등 예방형 작업
세 유형은 성격이 완전히 다릅니다. 버그 수정은 예측이 어렵고 급하게 발생하는 반면, 기능 추가·고도화는 계획을 세워 진행할 수 있습니다. 정기 운영 관리는 당장 눈에 띄지 않지만 미뤄질수록 나중에 더 큰 작업으로 돌아오는 경우가 많습니다(예: 오래 방치된 라이브러리를 한 번에 업데이트하면 예상보다 훨씬 큰 작업이 됩니다). 계약을 맺을 때 이 세 가지가 각각 어떻게 다뤄지는지 구분해서 확인하시는 것을 권장합니다.
2. 계약 방식은 보통 두 가지입니다
월 단위로 일정 시간을 확보해두는 정기 계약 방식과, 필요할 때마다 건별로 요청하는 방식이 있습니다. 업데이트가 잦은 초기 서비스는 정기 계약이, 안정화된 서비스는 건별 대응이 더 효율적인 경우가 많습니다.
| 구분 | 정기 유지보수 계약 | 건별 대응 |
|---|---|---|
| 비용 예측 | 매달 고정 비용으로 예측 쉬움 | 요청 건에 따라 변동 |
| 대응 속도 | 확보된 시간 내에서 빠르게 처리 | 건마다 견적·일정 협의 필요 |
| 적합한 단계 | 업데이트가 잦은 초기~성장 서비스 | 변경이 드문 안정화된 서비스 |
| 여유 시간 처리 | 다음 달로 이월되거나 소진 방식이 다름(계약서 확인 필요) | 해당 없음 |
정기 계약이라도 매달 확보한 시간을 다 쓰지 못했을 때 이월되는지, 소멸되는지는 업체마다 다릅니다. 계약 전에 이 부분을 명확히 확인해두면 나중에 오해가 생기지 않습니다.
3. 대응 시간(SLA)을 미리 정해두기
- 긴급 장애(서비스 중단) 대응 시간
- 일반 버그 대응 시간
- 문의 접수 후 첫 회신까지 걸리는 시간
SLA는 계약서에 숫자로 명시되어 있어야 의미가 있습니다. "빠르게 대응하겠습니다"라는 표현만으로는 실제 장애 상황에서 무엇을 기대할 수 있는지 알기 어렵습니다. 예를 들어 "서비스 전체 중단은 접수 후 1시간 이내 착수, 4시간 이내 임시 조치"처럼 구체적인 숫자로 합의해두는 것이 좋습니다.
4. 인수인계 문서도 함께 챙기기
다른 회사가 만든 서비스를 넘겨받아 유지보수하는 경우, 코드와 서버 접근 권한뿐 아니라 그동안의 의사결정 배경까지 함께 전달받는 것이 중요합니다. 문서가 없다면 저희가 먼저 코드를 분석해 파악해드립니다.
| 확인할 항목 | 왜 필요한가 |
|---|---|
| 소스코드 저장소 및 접근 권한 | 가장 기본이지만, 권한 이관이 누락되어 뒤늦게 문제가 되는 경우가 많음 |
| 서버·도메인·API 키 등 인프라 정보 | 서비스가 실제로 어디서, 어떤 설정으로 돌아가는지 파악하는 데 필수 |
| 기획·설계 문서(있다면) | 왜 이렇게 만들어졌는지 배경을 알아야 잘못된 방향으로 수정하지 않음 |
| 알려진 이슈·기술 부채 목록 | 이관 직후 우선순위를 정하는 데 가장 큰 힌트가 됨 |
유지보수 범위, 처음부터 명확히 하기
유지보수 계약을 둘러싼 오해의 상당수는 "이것도 유지보수에 포함되는 줄 알았다"는 데서 시작합니다. 계약 전에 아래 기준으로 범위를 나눠보시면 이후 불필요한 논쟁을 줄일 수 있습니다.
- 보통 포함되는 것 — 기존 기능의 오류 수정, 서버·라이브러리 보안 패치, 간단한 문구·UI 조정
- 별도 협의가 필요한 경우가 많은 것 — 새로운 화면·기능 추가, 대규모 디자인 개편, 외부 서비스 신규 연동
"버그"와 "새 기능"의 경계가 모호한 요청도 종종 발생합니다. 이런 경우를 대비해, 애매한 요청이 들어오면 어떤 기준으로 판단할지(예: 기존 명세에 있던 동작인지 여부)를 미리 정해두면 서로 얼굴 붉힐 일이 줄어듭니다.
이미 운영 중인 서비스의 유지보수가 필요하시다면, 현재 상태를 진단하는 것부터 시작해드립니다.