서비스 정책 vs 기능 정의, 헷갈리는 경계

 

최근에 팀 내부에서 꽤 오래 이야기가 오간 주제가 있었습니다.
"이건 정책이야, 기능이야?"라는 질문이었는데, 별거 아닌 것 같았는데 막상 파고드니 회의가 세 번이나 이어졌어요.
정리해두면 저 말고 다른 팀에도 도움이 될 것 같아서 글로 남겨봅니다.

 

저희 서비스에 "환불 가능 기간"을 조정하는 이슈가 있었어요.
개발팀은 이걸 코드 레벨의 기능 변경으로 보고 티켓을 만들었고, 저는 이걸 정책 문서에 먼저 반영해야 한다고 생각했습니다.
문제는 둘 다 맞았다는 거예요.
환불 가능 기간이라는 규칙 자체는 정책이지만, 그 규칙을 시스템이 어떻게 계산하고 화면에 어떻게 보여주는지는 기능이었거든요.
이 둘을 하나의 티켓에 뭉쳐놓으니까, "이거 언제 배포돼요?"라는 질문에 아무도 명확히 답을 못 하는 상황이 됐습니다.

 

몇 번의 회의 끝에 저는 이렇게 구분하기로 했습니다.
정책은 "무엇을 허용하고 무엇을 금지하는가"에 대한 규칙이고, 기능은 "그 규칙을 사용자가 어떻게 경험하는가"에 대한 구현입니다.
예를 들어 "환불은 구매 후 7일 이내에만 가능하다"는 정책이고, "환불 신청 버튼을 누르면 남은 일수를 보여주고, 기간이 지나면 버튼을 비활성화한다"는 기능이에요.

이 구분이 왜 중요하냐면, 둘의 변경 주기와 담당자가 다르기 때문입니다.
정책은 법무, 운영, 사업 쪽 판단이 얽혀 있어서 변경 승인 절차가 무겁고, 기능은 상대적으로 팀 내부에서 빠르게 결정할 수 있는 영역이에요.
이걸 하나의 문서, 하나의 티켓으로 섞어두면 승인 절차가 무거운 부분 때문에 가벼운 기능 개선까지 다 같이 묶여서 지연되는 일이 생깁니다.
저희가 겪었던 문제가 정확히 이거였어요.

 

그 뒤로 저는 새 이슈가 들어오면 먼저 "이게 규칙 변경인가, 구현 변경인가"를 스스로 물어보는 습관을 들였습니다.
규칙 변경이면 정책 문서를 먼저 업데이트하고 관련 부서 승인을 받은 뒤에 기능 티켓을 만들고, 구현 변경이면 곧바로 기능 티켓으로 넘깁니다.
이렇게 나누고 나서부터는 "이거 왜 이렇게 오래 걸려요"라는 질문에 "정책 승인 단계에 있다" 혹은 "개발 진행 중이다"라고 명확하게 답할 수 있게 됐어요.

물론 경계가 애매한 경우도 여전히 있습니다.
예를 들어 "환불 버튼의 문구를 어떻게 쓸 것인가"는 기능처럼 보이지만, 문구가 사용자에게 오해를 줄 수 있는 수준이면 이것도 정책 검토가 필요한 영역이 될 수 있어요.
그래서 저는 팀에 "애매하면 일단 정책 담당자에게 한 줄로라도 물어보자"는 원칙을 세워뒀습니다.
과하게 보일 수도 있지만, 나중에 "이거 우리끼리 정한 거 아니냐"는 이야기가 나오는 것보다는 훨씬 낫더라고요.

 

돌아보면 이 혼란의 근본 원인은 저희 문서 구조에 정책과 기능이 구분 없이 뒤섞여 있었다는 데 있었습니다.
정책 문서를 따로 만들고, 기능 문서는 그 정책을 참조하는 형태로 링크만 걸어두는 식으로 바꾸고 나서야 이런 혼란이 줄어들었어요.
작은 정리처럼 보이지만, 이후로 "이거 정책이야 기능이야" 하는 질문 자체가 회의 시간을 잡아먹지 않게 된 걸 보면 확실히 효과가 있었습니다.

비슷한 혼란을 겪는 팀이 있다면, 일단 문서를 물리적으로 분리해보는 것부터 시작해보라고 권하고 싶어요.