유지보수 계약으로 바꾼 1인 개발자의 일거리 정리 — 계속 만들기 위해 줄이는 일의 기준

혼자 만든 서비스를 운영하다 보면 새 기능을 만드는 일보다 이미 있는 기능을 설명하고 고치는 일이 더 많은 날이 옵니다. 저는 한동안 이 일을 모두 호의로 처리했습니다. 그러다 보니 사용자 한 명의 요청이 다음 주의 약속이 되고, 약속이 쌓일수록 정작 제품을 개선할 시간이 사라졌습니다.

이번 글에서는 서비스를 접을지 말지의 문제가 아니라, 어떤 일만 남기고 어떤 요청은 계약 밖으로 둘지 정리한 과정을 적어보겠습니다. 금액을 정답처럼 제시하기보다 범위와 응답 기준을 먼저 세우는 방법에 집중합니다.

유지보수와 신규 개발을 먼저 나눴습니다

같은 코드베이스에서 나온 요청이라도 성격은 다릅니다. 오류를 원래 동작으로 되돌리는 일은 유지보수이고, 새로운 화면이나 업무 규칙을 추가하는 일은 신규 개발입니다. 둘을 같은 창구에서 받으면 긴급도와 비용을 비교할 수 없게 됩니다.

저는 요청을 받을 때 먼저 ‘지금 없어서 문제가 생긴 것인지, 있던 것이 망가진 것인지’를 묻습니다. 이 질문 하나만으로도 지원 범위가 상당히 선명해졌습니다.

• 유지보수: 기존 기능의 오류 수정, 보안 패치, 배포 실패 복구처럼 서비스 약속을 지키는 일입니다.
• 개선: 사용성이나 성능을 높이지만 없어도 서비스가 멈추지 않는 일입니다.
• 신규 개발: 새로운 데이터·권한·화면을 추가해 설계와 테스트 범위가 커지는 일입니다.

계약서보다 먼저 지원 범위를 표로 만들었습니다

계약 문구를 멋지게 쓰는 것보다 실제로 무엇을 지원하는지 표로 만드는 일이 먼저였습니다. 표에는 요청 유형, 기본 응답 시간, 작업 시작 조건, 제외 조건을 적었습니다. ‘빠르게 처리’처럼 해석이 갈리는 표현은 사용하지 않았습니다.

예를 들어 장애는 접수 후 확인을 시작하지만, 기능 개선은 요구사항과 예상 시간을 합의한 뒤에만 시작한다고 분리했습니다. 이 구분이 있어야 야간 알림을 모두 긴급 작업으로 오해하지 않습니다.

구분기본 처리별도 합의

오류	재현·원인 확인·복구	데이터 복구나 외부 시스템 문제
보안	긴급 패치와 영향 공지	대규모 구조 변경
개선	간단한 문구·설정 수정	화면·권한·데이터 구조 변경

일을 줄이는 기준은 거절이 아니라 기록입니다

요청을 거절하는 말은 관계를 어렵게 만들 수 있습니다. 그래서 저는 요청을 받으면 바로 ‘이번 계약 범위에 포함되는가’, ‘다음 배포에 넣을 수 있는가’, ‘반복될 가능성이 있는가’를 기록합니다. 기록이 쌓이면 같은 설명을 매번 새로 하지 않아도 됩니다.

특히 반복되는 수작업은 별도의 도구나 문서로 바꿀 후보입니다. 한 번의 자동화가 모든 일을 해결하지는 않지만, 다음 요청에서 다시 판단할 비용을 줄여 줍니다.

• 남길 일: 서비스의 약속을 지키고 장애 위험을 낮추는 일입니다.
• 예약할 일: 가치가 있지만 지금의 운영 시간을 침범하는 개선입니다.
• 보낼 일: 계약 범위를 벗어나거나 다른 전문성이 필요한 일입니다.

혼자 운영할수록 응답 속도보다 예측 가능성이 중요합니다

혼자 운영하는 서비스가 대형 팀처럼 모든 요청에 즉시 답할 수는 없습니다. 대신 언제 확인하고, 어떤 조건이면 시작하고, 어디까지 완료하는지는 예측 가능하게 만들 수 있습니다. 사용자 입장에서도 빠른 답변 한 번보다 약속한 시각에 상태를 알려주는 것이 더 도움이 됩니다.

저는 주간 작업 시간을 먼저 고정하고 그 안에서 처리할 수 있는 양만 받습니다. 빈 시간이 생기면 기능을 더 받는 것이 아니라 문서와 테스트를 보강합니다. 지속할 수 있는 속도를 정하는 것이 결국 가장 큰 지원 기능이었습니다.

작게 시험하고 다음 주에 다시 봅니다

생활과 일의 문제는 한 번에 해결되지 않습니다. 저는 새 원칙을 정할 때 먼저 일주일 동안 확인할 수 있는 행동으로 줄입니다. 예를 들어 일거리의 범위를 정리한다면 모든 계약을 다시 쓰기보다, 이번 주에 들어온 요청 세 건을 같은 표에 기록해 봅니다. 창작 경계를 세우는 경우에도 하루 전체를 바꾸지 않고 알림을 끄는 시각 하나만 정합니다. 작은 실험은 실패했을 때 비용이 작고, 성공했을 때 무엇이 영향을 주었는지 설명하기 쉽습니다.

실험이 끝난 뒤에는 결과를 성과와 실패로만 나누지 않습니다. 예상보다 쉬웠던 점, 예상보다 오래 걸린 점, 다른 사람에게 설명하기 어려웠던 점을 적습니다. 이 기록이 있어야 다음 주에 같은 실수를 반복하지 않고 조건을 조정할 수 있습니다. 다른 사람의 조언을 참고하더라도 내 생활과 서비스의 제약을 먼저 적어야 합니다.

• 현재 상태: 지금 어떤 일이 반복되고 무엇이 가장 자주 막히는지 사실로 적습니다.
• 작은 실험: 일주일 안에 확인할 행동 하나와 하지 않을 행동 하나를 정합니다.
• 관찰 신호: 시간·체력·집중·요청 수처럼 실제로 기록할 수 있는 신호를 고릅니다.
• 다음 결정: 계속·축소·중단 중 하나를 다음 회고에서 선택합니다.

다음 작업에서 다시 확인할 항목

한 번 적용한 방법이 언제나 같은 결과를 내는 것은 아닙니다. 사람과 서비스와 원고의 조건이 바뀌면 같은 원칙도 다른 판단을 요구합니다. 그래서 저는 글을 작성한 뒤 결론만 보관하지 않고, 결론이 성립한 조건과 다시 확인해야 할 조건을 함께 적습니다. 이 기록이 있으면 몇 달 뒤 글을 업데이트할 때 당시의 경험을 현재의 사실처럼 착각하지 않을 수 있습니다.

특히 버전·정책·가격·플랫폼 기능처럼 외부에서 바뀌는 내용은 조사한 날짜와 공식 문서의 주소를 남깁니다. 발행 시점에 문서가 달라졌다면 본문에 변경 사실을 표시하고, 직접 확인하지 못한 부분은 독자가 알 수 있도록 범위를 제한합니다. 경험을 공유하는 글도 다른 사람의 환경에 그대로 적용될 수 있으므로, 성공 사례보다 실패 조건을 함께 쓰는 편이 안전합니다.

마지막으로 이 글을 읽은 분이 바로 할 수 있는 행동은 하나로 줄입니다. 모든 항목을 한꺼번에 바꾸기보다 현재 상태를 기록하고, 작은 실험을 한 번 실행하고, 결과를 다시 적는 순서입니다. 그렇게 쌓인 기록이 다음 글의 소재가 되고, 처음의 판단을 더 정확하게 고쳐 쓰는 근거가 됩니다.

• 범위 표시: 이 글의 결론이 적용되는 환경과 적용되지 않는 환경을 구분합니다.
• 날짜 기록: 버전·정책·가격·문서를 확인한 날짜를 남깁니다.
• 실패 조건: 어떤 상황에서는 이 방법을 쓰지 말아야 하는지 적습니다.
• 작은 실행: 독자가 오늘 시도할 수 있는 가장 작은 행동을 고릅니다.
• 후속 기록: 실행 결과와 다음에 바꿀 조건을 별도 메모로 남깁니다.

이 기록을 나중에 다시 읽을 때는 결과만 보지 않고 당시의 조건도 함께 확인합니다. 조건이 달라졌다면 결론을 그대로 복사하지 말고 현재의 입력과 제약을 다시 적습니다. 그 과정을 거쳐야 이 글이 단순한 경험담이 아니라 다음 판단을 돕는 작업 기록으로 남습니다.

마치며

유지보수 계약은 일을 더 받기 위한 문서가 아니라, 혼자서도 약속을 지킬 수 있는 범위를 정하는 장치였습니다. 오늘 운영 중인 요청 열 개를 유지보수·개선·신규 개발로 나눠 보시면, 줄여야 할 일의 윤곽이 먼저 보일 것입니다.

참고한 문서: Google 사람 우선 콘텐츠 가이드 · GitHub 협업 흐름