유지보수를 하면서 가장 많이 겪은 갈등은 실력 문제가 아니었습니다. "지난번에 말씀드린 그거요"에서 시작되는 갈등이었습니다.
카카오톡으로 요청을 받던 시절, 저희도 고객사도 같은 문제를 겪었습니다. 요청은 대화 사이에 묻히고, 어디까지 처리됐는지는 서로의 기억에 의존하고, 담당자가 바뀌면 히스토리가 통째로 사라졌습니다. 그래서 요청 채널을 전용 게시판으로 옮겼습니다. 이 글은 그 과정에서 배운 것과, 지금도 유효한 원칙을 정리한 것입니다.
30초 요약
- •카톡의 문제는 속도가 아니라 '검색되지 않고 남지 않는다'는 점입니다. 빠른 대신 기록이 사라집니다.
- •유지보수 분쟁의 대부분은 요청 누락에서 발생합니다. 실력보다 기록 구조가 만족도를 결정합니다.
- •좋은 요청에는 '어디를·무엇을·왜'가 들어갑니다 — 이 셋이 있으면 되묻기 없이 바로 착수할 수 있습니다.
- •이력이 쌓이면 유지보수가 데이터가 됩니다 — 무엇이 반복되는지 보이면 근본 원인을 고칠 수 있습니다.
카톡이 편한 이유, 그리고 무너지는 지점
먼저 인정할 것은 인정하겠습니다. 카카오톡은 빠릅니다. 스크린샷을 바로 붙일 수 있고, 대표님이 이동 중에도 한 줄 남길 수 있습니다. 요청을 남기는 순간의 마찰이 가장 낮은 채널이라는 점에서는 이길 수 있는 도구가 없습니다.
문제는 요청을 남긴 다음부터입니다.
- •묻힙니다 — 요청 사이에 일상 대화가 섞이면 며칠 뒤 스크롤로 찾아야 합니다. 스크린샷은 유효기간이 지나면 열리지도 않습니다.
- •상태를 알 수 없습니다 — 접수됐는지, 작업 중인지, 끝났는지를 확인하려면 매번 물어야 합니다. 물어보기 미안해서 안 묻고, 안 묻다가 오해가 쌓입니다.
- •사람에 종속됩니다 — 고객사 담당자나 저희 담당자가 바뀌면 이전 히스토리가 사라집니다. 왜 그렇게 만들었는지 아무도 설명할 수 없게 됩니다.
- •요청 범위가 흐려집니다 — 대화 흐름에서 "이것도 같이"가 자연스럽게 붙습니다. 나중에 무엇이 계약 범위였는지 양쪽 기억이 달라집니다.
이 네 가지는 성실함으로 해결되지 않습니다. 채널의 구조 문제이기 때문입니다.
게시판으로 옮기며 정한 세 가지 원칙
① 요청은 한 곳에서만 받는다
채널을 나누면 반드시 한쪽이 누락됩니다. 그래서 급한 건 연락은 따로 받더라도, 작업 요청 자체는 반드시 게시판에 기록으로 남기는 것을 원칙으로 했습니다. 접수 시각이 남아야 착수 시간 약속도 의미가 생깁니다.
② 상태를 고객이 직접 볼 수 있게 한다
"그거 어떻게 됐나요?"라는 질문이 나오는 것 자체가 프로세스의 실패입니다. 접수·작업 중·완료 상태를 고객사가 언제든 확인할 수 있으면 그 질문이 사라집니다. 확인을 위한 커뮤니케이션이 없어지는 것만으로 양쪽 시간이 크게 절약됩니다.
③ 이력은 계약이 끝나도 남는다
1년 전 왜 그 섹션을 그렇게 바꿨는지, 어떤 요청 때문이었는지가 남아 있으면 이후 판단이 빨라집니다. 유지보수의 자산은 작업물이 아니라 판단의 기록입니다. 이건 제작 단계에서도 같은 원칙으로 일합니다 (EasySpark가 웹사이트 제작을 진행하는 방식).
작업이 빨라지는 요청 쓰는 법
채널을 바꾸는 것만으로 다 해결되지는 않았습니다. 요청의 내용 자체가 모호하면 결국 되묻게 되고, 그 왕복에서 하루가 갑니다. 실무에서 되묻지 않아도 되는 요청에는 공통적으로 세 가지가 들어 있습니다.
- 1.어디를 — 페이지 주소와 섹션. "메인 세 번째 섹션"보다 캡쳐본과 URL을 붙이는 것이 정확합니다. 모바일에서 본 문제라면 그 사실도 함께 적어주세요.
- 2.무엇을 — 바꿀 내용. 텍스트는 최종 문구를 그대로 적어주시는 것이 가장 빠릅니다. "이 문장 좀 다듬어주세요"는 취향 확인에만 며칠이 걸립니다.
- 3.왜 — 목적. 이게 가장 자주 빠지고, 가장 중요합니다. "버튼을 빨간색으로"보다 "문의 전환이 낮아서 눈에 띄게"가 낫습니다. 목적을 알면 색상 말고 더 나은 방법을 제안할 수 있기 때문입니다.
특히 '왜'가 담긴 요청은 유지보수를 대행에서 파트너십으로 바꿉니다. 시키는 대로만 하는 관계에서는 아무도 더 나은 답을 내놓지 않습니다.
기록이 쌓이면 유지보수가 데이터가 됩니다
요청 이력이 반년쯤 쌓이면 패턴이 보입니다. 어떤 페이지에서 수정 요청이 반복되는지, 어떤 유형의 작업이 가장 많은지가 드러납니다.
예를 들어 특정 섹션의 문구 수정 요청이 매달 반복된다면, 그건 수정할 일이 아니라 CMS로 빼서 고객사가 직접 관리하게 만들 일입니다. 이 판단은 기억이 아니라 기록에서만 나옵니다. 반복 요청이 사라지면 같은 플랜으로 더 가치 있는 작업을 할 수 있게 됩니다.
반대로 요청이 특정 시기에 몰린다면 그 시기 전에 미리 준비하는 방식으로 바꿉니다. 유지보수를 대응에서 예방으로 옮기는 출발점이 기록입니다. 이 관점은 유지보수는 '고치는 일'이 아니라 '안 무너지게 하는 일'에서 더 깊이 다뤘습니다.
이건 저희만의 이야기가 아닙니다
사내에 웹 담당자를 두고 직접 운영하시는 경우에도 같은 문제가 생깁니다. 대표님이 카톡으로 던진 수정 요청을 담당자가 놓치고, 담당자가 퇴사하면 아무 기록도 남지 않습니다. 채널을 정하고 기록을 남기는 것은 외주 여부와 무관한 운영의 기본입니다.
직접 운영과 외주 사이에서 고민 중이시라면 시간과 비용으로 계산한 비교를, 웹 프로젝트가 실패하는 더 근본적인 이유가 궁금하시다면 이 글을 함께 보시면 맥락이 이어집니다.
자주 묻는 질문
급한 건도 게시판에만 올려야 하나요?
장애처럼 즉시 대응이 필요한 상황은 별도 채널로 바로 알려주셔도 됩니다. 다만 그 경우에도 내용은 게시판에 남깁니다. 급한 건일수록 나중에 "무엇을 어떻게 조치했는지"가 중요해지기 때문입니다.
게시판에 요청 쓰는 게 카톡보다 번거롭지 않나요?
처음 몇 번은 그렇게 느껴집니다. 다만 실제로 시간이 드는 쪽은 요청을 쓰는 3분이 아니라, 되묻고 확인하고 다시 설명하는 왕복입니다. 형식이 정해져 있으면 그 왕복이 사라져서 전체 시간은 오히려 줄어듭니다.
요청 이력은 계약이 끝나면 어떻게 되나요?
고객사의 자산이므로 요청하시면 정리해 전달해 드립니다. 다음 담당자나 다른 파트너에게 넘길 때 이 기록이 있는 것과 없는 것의 차이가 큽니다.
수정 요청 건수는 어떻게 세나요?
요청 하나가 곧 1건입니다. 다만 "이 세 페이지의 연락처를 같은 내용으로 바꿔주세요"처럼 하나의 목적을 가진 작업은 묶어서 1건으로 봅니다. 애매한 경우에는 착수 전에 먼저 안내드리고 진행합니다. 건수와 착수 시간 기준은 스파크 케어 플랜에 명시해 두었습니다.
함께 읽으면 좋은 글
- •유지보수는 '고치는 일'이 아니라 '안 무너지게 하는 일'입니다
- •방치된 프레이머 사이트를 넘겨받으면 가장 먼저 하는 3가지
- •프레이머 유지보수, 직접 할까 외주를 맡길까
- •웹사이트 제작 프로젝트가 실패하는 가장 큰 이유
정리하며
유지보수의 만족도는 작업 실력보다 '요청이 사라지지 않는가'에서 갈립니다. 카톡을 쓰지 말자는 이야기가 아니라, 요청만큼은 남는 곳에 쌓자는 이야기입니다. 그 기록이 반년만 쌓여도 무엇을 근본적으로 고쳐야 할지가 보입니다.
요청이 흩어져서 관리가 안 되고 계시다면 상담 신청에서 현재 운영 방식을 알려주세요. 채널부터 정리하는 것만으로 해결되는 경우도 많습니다. 저희 운영 방식은 스파크 케어에서 보실 수 있습니다.
이 글은 EasySpark 허수진 대표의 실무 내용이며, 조직 규모와 운영 방식마다 다를 수 있어 결과를 보장하지 않습니다. 요청 프로세스 정리가 필요하시다면 편하게 상담 신청해주세요.
