서비스 정책 문서, 왜 자꾸 누락되나

최근 CS팀에서 문의가 하나 들어왔습니다.
"환불 정책이 어떻게 되나요"라는 질문에 상담원이 답을 못 해서 저한테 직접 물어본 거였어요.
그런데 저도 정확히 기억이 안 나서 문서를 뒤졌는데, 어디에도 최신 정책이 정리되어 있지 않았습니다.

서비스 정책 문서가 왜 이렇게 자꾸 누락되는지, 이번 기회에 원인을 좀 파봤습니다.

 

 

정책은 "기능"이 아니라서 우선순위에서 밀린다

 

기능 개발은 PRD가 있고, 일정이 잡히고, 완료되면 QA를 통과해야 배포됩니다.
그런데 정책은 이 프로세스 밖에서 결정되는 경우가 많았어요.
저희 팀에서도 "환불 기준을 7일에서 14일로 늘리자"는 결정이 회의 중에 구두로 이뤄졌는데, 이걸 문서화하는 작업은 누구의 담당 업무도 아니었습니다.
개발팀은 "저는 시스템 로직만 바꿨어요"라고 하고, 저는 "그건 CS팀이 정리해야 하는 거 아닌가요"라고 생각했고, CS팀은 "저희는 기획팀에서 문서를 받아야 안내할 수 있어요"라고 했습니다.
결국 셋 다 서로 미루다가 아무도 문서화하지 않은 채 몇 달이 지나버린 거죠.

 

 

구두로 결정된 것과 문서로 남은 것의 간극

 

돌이켜보면 저희 팀의 정책 변경은 대부분 슬랙 메시지나 회의 중 구두 합의로 이뤄졌습니다.
"이번부터는 이렇게 하자"는 말이 나오고 다들 고개를 끄덕이면, 그게 곧 정책이 됐어요.
문제는 이 결정을 나중에 찾아보려고 하면 슬랙 채널을 뒤지거나 그 자리에 있던 사람의 기억에 의존해야 한다는 겁니다.
저는 이 문제를 겪고 나서 "정책 변경 로그"라는 문서를 하나 새로 만들었습니다.
날짜, 변경 전 정책, 변경 후 정책, 결정한 사람, 결정한 이유를 한 줄씩 남기는 아주 단순한 표인데, 이것만으로도 나중에 "그때 왜 이렇게 바꿨더라"를 찾아보는 시간이 확 줄었습니다.

 

 

담당자가 명확하지 않으면 아무도 안 한다

 

정책 문서가 누락되는 가장 큰 이유는 결국 "이건 내 일이 아니다"라는 인식이었습니다.
기획자는 기능 명세를 쓰는 사람이고, CS팀은 문의에 답하는 사람이고, 법무팀은 계약서를 검토하는 사람이라는 인식이 강했어요.
그런데 정책 문서는 이 셋 중 누구의 전담 업무도 아니었기 때문에 항상 우선순위 맨 뒤로 밀렸습니다.
저희는 결국 회의를 열어서 "정책 변경이 결정되면 그 결정을 내린 회의의 주최자가 24시간 안에 정책 문서를 업데이트한다"는 규칙을 명시적으로 정했습니다.
담당자를 못 박아두지 않으면 결국 아무도 하지 않는다는 걸 여러 번의 시행착오로 배운 셈입니다.

 

 

정책 문서와 실제 시스템이 다르게 흘러가는 문제

 

또 하나 발견한 문제는, 정책 문서를 만들어놔도 시스템이 실제로 그 정책대로 동작하는지 검증하는 단계가 없었다는 겁니다.
저희가 "환불은 결제 후 14일 이내"라고 문서에 적어놨는데, 실제 시스템 로직은 여전히 7일로 되어 있던 적이 있었습니다.
이걸 발견한 것도 사용자 항의를 통해서였어요.
그 뒤로는 정책이 바뀔 때마다 "이 정책을 실제로 검증할 테스트 케이스"를 QA 체크리스트에 추가하도록 프로세스를 바꿨습니다.
문서만 고치고 시스템은 그대로 두는 일이 생기지 않도록, 정책 변경과 시스템 검증을 항상 같은 티켓으로 묶어서 관리하기 시작한 거죠.

 

 

버전 관리가 안 되면 옛날 정책이 계속 떠돈다

 

이 부분도 꽤 골치 아팠던 문제입니다.
정책 문서를 여기저기 흩어진 위키 페이지, 구글 문서, 심지어 예전 팀장님이 만들어둔 파워포인트 파일에 각각 다른 버전으로 저장해둔 걸 발견했어요.
CS 상담원이 검색해서 처음 나오는 문서를 참고했는데, 그게 1년 전에 업데이트가 멈춘 옛날 버전이었던 겁니다.
결국 저희는 모든 정책 문서를 하나의 위키 공간으로 통합하고, 옛날 파일은 전부 "보관용, 참고하지 마세요"라고 표시한 뒤 접근 권한 자체를 낮췄습니다.
문서가 여러 곳에 존재할 수 있다는 사실 자체가 혼란의 원인이라는 걸 이번에 제대로 깨달았어요.

 

정책 문서 누락은 특별히 대단한 시스템이 부족해서 생기는 문제가 아니었습니다.
담당자를 정해두고, 결정과 문서화를 같은 프로세스에 묶어두고, 문서를 한 곳에서 관리하는 습관만 있으면 대부분 해결되는 문제였어요.

저희 팀은 이번 일을 계기로 매달 마지막 주 금요일에 "정책 문서 점검"이라는 30분짜리 짧은 리추얼을 새로 만들었습니다.
그동안 바뀐 정책이 문서에 다 반영됐는지, 오래된 버전이 어딘가에 남아있지 않은지를 확인하는 시간이에요.

번거로워 보이지만, CS팀 상담원이 잘못된 정책을 안내해서 생기는 신뢰 손실을 생각하면 이 정도 수고는 확실히 감수할 만하다고 생각합니다.