"웹사이트를 만들겠습니다."
"감사를 진행하겠습니다."
"캠페인을 운영하겠습니다."
각 문장은 사실일 수 있지만, 고객이 실제로 무엇을 구매하는지 충분히 명확하게 설명하지는 않습니다.
웹사이트에 디자인이 포함되나요? 화면은 몇 개인가요? 구현도 포함되나요? 감사는 무엇을 기준으로 완료됐다고 하나요? 캠페인에 자료 제작도 포함되나요? 필요한 입력 자료는 누가 제공하나요? 작업 중간에 고객이 범위를 바꾸면 어떻게 되나요?
좋은 서비스 설명은 이런 질문을 수행 단계로 미루지 않고 협업이 시작되기 전에 줄입니다.
좋은 서비스 설명은 결과, 측정 가능성, 명확한 경계에 집중합니다
성과 중심 서비스에 관한 현재 미국 Federal Acquisition Regulation은 일을 수행하는 방법이나 단순한 시간 수를 지정하기보다 필요한 결과를 중심으로 작업을 설명하도록 권고합니다. 또한 측정 가능한 수행 기준을 언급하며, 목표 설명에는 목적, 범위, 수행 기간과 장소, 배경, 필요한 결과, 운영상 제약 등의 요소를 포함합니다. [1]
영국 정부의 Digital, Data and Technology Playbook도 명확하고 결과 중심의 요구사항을 권장합니다. 미리 기술적 해결책을 정하기보다 사용자와 해결해야 할 문제에 집중하도록 명시적으로 안내합니다. [2]
영국의 최신 위험 배분 및 가격 접근법 지침은 수행 지표가 측정 가능하고 객관적이어야 하며, 공급자는 실제로 영향을 줄 수 있는 결과에 대해서만 책임져야 한다고 설명합니다. [3]
이 자료들은 공공 조달 환경을 다루며 모든 서비스에 적용되는 보편적 양식은 아닙니다. 그러나 중요한 원칙을 보여 줍니다. 좋은 업무 범위는 기대 결과, 그 결과를 평가하는 방법, 책임의 경계를 명시해야 합니다.
서비스 설명은 서로 다른 세 가지 역할을 합니다
좋은 설명은 동시에 다음을 도와야 합니다.
고객 - 무엇을 받고, 무엇을 받지 않으며, 자신이 무엇을 제공하거나 처리해야 하는지 이해합니다.
전문가 - 책임의 경계, 가정, 새로운 요청이 범위 변경으로 전환되는 지점을 정의합니다.
양측 - 합의한 작업이 완료되었다고 합리적으로 판단하는 방법을 공유합니다.
설명이 이 역할 가운데 하나만 잘 수행한다면 분쟁이나 서로 다른 해석이 생길 여지가 여전히 클 수 있습니다.
좋은 서비스 업무 범위의 10가지 요소
1. 문제 또는 목적
먼저 왜 이 서비스가 필요한지 설명하세요.
고객이 목적을 이해하기 전에 도구나 작업 목록부터 제시하지 마세요.
예를 들어:
"분석, 보고서, 이벤트 설정."
보다는:
"사용자가 양식의 어느 단계에서 가장 많이 이탈하는지 신뢰할 수 있는 자료를 확보하여 팀이 개선이 필요한 지점을 식별할 수 있도록 하는 것이 목적입니다."
가 더 명확합니다.
이는 해결책을 미리 강제하기보다 필요와 결과를 설명하라는 영국 Digital, Data and Technology Playbook의 원칙과 일치합니다. [2]
2. 기대 결과
목적은 **"왜?"**에 답하고, 결과는 **"작업이 끝났을 때 무엇이 존재하거나 어떤 상태가 되어야 하는가?"**에 답합니다.
결과의 예:
- 완성된 문서,
- 작동하는 기능,
- 적용된 설정,
- 결론을 포함한 완료된 조사,
- 준비된 자료 묶음,
- 정해진 요약을 포함한 완료된 세션.
성과 중심 서비스에서 FAR는 요구사항을 주로 필요한 결과로 설명하며 수행 방법 자체만으로 정의하지 않습니다. [1]
그렇다고 전문가가 통제할 수 없는 사업 결과까지 모든 서비스가 보장해야 한다는 뜻은 아닙니다. 전문가는 합의한 범위에서 캠페인을 시작하는 것을 약속할 수 있지만, 매출 30% 증가 보장은 공급자가 통제할 수 없는 여러 요인에 좌우될 수 있습니다.
3. 범위에 포함되는 작업
업무 범위에는 합의에 포함되는 구체적인 작업 항목을 적어야 합니다.
예를 들어 웹사이트 프로젝트라면:
- 현재 웹사이트 분석,
- 정보 구조 설계,
- 정해진 수의 화면 디자인,
- 모바일 버전,
- 승인된 디자인 구현,
- 기본 인수인계 문서.
목표는 가능한 한 긴 목록을 만드는 것이 아닙니다. 작업 시작 전에 노력과 기대에 큰 영향을 주는 핵심 항목을 명확히 하는 것이 목적입니다.
4. 구체적인 납품물
업무 범위는 무엇을 하는지 설명하고, 납품물은 고객이 실제로 무엇을 받는지 설명합니다.
예:
- 원본 파일,
- 정해진 형식의 보고서,
- 작동하는 모듈,
- 코드 저장소,
- 그래픽 자료 묶음,
- 녹화 파일,
- 문서,
- 권고사항 목록,
- 설정된 환경에 대한 접근 권한.
결과의 형태가 중요하다면 명시하세요. **"보고서"**는 두 쪽짜리 글일 수도 있고, 분석, 우선순위, 사례를 포함한 상세 문서일 수도 있습니다. 이름만으로는 항상 충분하지 않습니다.
5. 검수 기준
검수 기준은 합의한 결과가 요구사항에 맞게 전달되었다고 무엇을 기준으로 판단할지를 설명합니다.
예를 들어:
- 완전성,
- 합의한 명세와의 일치,
- 특정 형식,
- 지정한 기기 또는 환경에서의 작동,
- 특정 분류의 오류 수 상한,
- 완료 시간,
- 정해진 품질 기준.
FAR는 성과 중심 서비스 계약의 수행 기준이 측정 가능해야 하며, 실제 수행을 평가할 수 있도록 구성되어야 한다고 요구합니다. [1]
영국의 위험 지침도 지표가 객관적이고 공급자가 영향을 줄 수 있는 결과와 관련되어야 한다고 설명합니다. [3]
따라서 **"고객이 만족할 것"**이라는 기준은 구체적이고 관찰 가능한 결과에 연결된 기준보다 훨씬 덜 유용합니다.
6. 고객의 책임과 제공 자료
서비스는 상대방의 행동에 의존하는 경우가 많습니다.
고객이 다음을 제공해야 하는지 명시하는 것이 좋습니다.
- 시스템 접근 권한,
- 콘텐츠 또는 자료,
- 데이터,
- 브랜드 정보,
- 결정과 승인,
- 연락 담당자,
- 시험 환경,
- 정해진 기간 안의 답변.
고객 측 자료 부족으로 작업이 중단될 수 있다면 그 사실을 분명하게 써야 합니다.
전문가가 실제로 통제할 수 없는 행동까지 통제하는 것처럼 일정 책임을 작성해서는 안 됩니다.
7. 가정과 의존 관계
가격과 일정은 특정 가정이 성립할 때만 유효한 경우가 많습니다.
예:
- 기존 데이터베이스에 접근할 수 있고 정상 작동함,
- 고객이 제공 자료에 필요한 권리를 보유함,
- 외부 시스템에 작동하는 연결 방식이 있음,
- 과거 데이터 이전이 필요하지 않음,
- 언어 버전 수가 미리 정해져 있음,
- 지정된 한 사람이 의사결정을 담당함.
GAO의 신뢰할 수 있는 비용 추정 가이드는 명확한 범위, 기술적 기준, 규칙과 가정, 위험과 불확실성 분석을 건전한 추정 절차의 중요한 요소로 다룹니다. [7]
작은 서비스가 대규모 계획용 절차를 그대로 적용할 필요는 없습니다. 하지만 원칙은 유용합니다. 추정이 실제로 성립하지 않을 수도 있는 조건에 의존한다면 그 조건을 밝혀야 합니다.
8. 범위에서 제외되는 항목
제외 항목은 약한 제안의 표시가 아닙니다. 오히려 약속의 경계가 잘 정의되어 있다는 뜻일 수 있습니다.
고객이 서비스에 포함된다고 오해하기 쉬운 항목은 포함되지 않는다고 명시하는 것이 좋습니다.
예:
- 사용권 구매,
- 콘텐츠 제작,
- 유료 이미지,
- 번역,
- 출시 후 유지관리,
- 다른 시스템에 대한 작업,
- 무제한 수정,
- 외부 서비스 비용.
전문가가 하지 않는 모든 일을 나열할 필요는 없습니다. 가장 유용한 제외 항목은 고객이 현실적으로 서비스의 일부라고 생각할 수 있는 것입니다.
9. 일정, 단계, 소통
진행이 고객의 승인이나 자료 제공에 좌우된다면 일정은 **"약 2주"**보다 더 구체적이어야 합니다.
다음을 명확히 할 수 있습니다.
- 어떤 시점부터 일정을 계산하는지,
- 중간 단계가 있는지,
- 어떤 결정으로 각 단계가 끝나는지,
- 고객의 답변이 일정에 영향을 줄 때 응답 기한은 얼마인지,
- 지연을 어떻게 알리는지,
- 최종 검수는 어떻게 진행하는지.
간단한 서비스라면 몇 문장으로 충분할 수 있습니다. 큰 협업에서는 단계가 양측에게 무엇이 완료되었고 다음에 무엇이 필요한지 이해하는 데 도움을 줍니다.
10. 범위 변경, 추가 작업, 가격
좋은 서비스 설명은 작업 시작 후 새로운 요구가 생겼을 때 어떻게 처리하는지도 설명해야 합니다.
실무 규칙은 간단해도 됩니다.
"설명된 범위를 벗어나는 작업은 시작 전에 새로운 범위, 일정에 미치는 영향, 추가 가격이 있다면 그 금액을 확인해야 합니다."
또한 다음을 명확히 하는 것이 좋습니다.
- 가격 방식,
- 가격 또는 계산 방법,
- 결제 규칙,
- 발생할 수 있는 추가 비용,
- 추가 수정 회차의 규칙.
이 규칙이 변경 자체를 없애는 것은 아닙니다. 변경을 처음 약속이 몰래 확대되는 것이 아니라 의식적인 결정으로 만듭니다.
예: 같은 종류의 서비스를 나쁘게 설명한 경우와 잘 설명한 경우
필요 이상으로 작업 방식을 규정하지 마세요
명확한 업무 범위가 전문가의 모든 작업 단계를 미리 통제해야 한다는 뜻은 아닙니다.
영국 Digital, Data and Technology Playbook은 해결책을 과도하게 구체화하는 것을 경고하며, 결과 중심 요구사항은 공급자에게 문제를 더 효과적으로 해결할 방법을 제안할 여지를 줄 수 있다고 설명합니다. [2]
FAR도 작업 방법을 세세하게 규정하기보다 필요한 결과를 설명하는 방식을 선호합니다. [1]
따라서:
"웹사이트는 지정한 기기에서 합의된 사용 시나리오를 올바르게 지원해야 한다"
는 기술 자체가 중요한 제약이 아닌 경우 구현 방법을 자세히 강제하는 것보다 더 적절한 요구사항일 수 있습니다.
물론 보안, 규정 준수, 연동, 기술 표준 때문에 방법 자체가 중요한 서비스도 있습니다. 그런 경우에는 방법을 명시해야 합니다.
전문가가 통제할 수 없는 결과를 약속하지 마세요
범위를 정할 때는 다음 두 가지를 구분해야 합니다.
전문가의 직접적인 작업 결과 와 다른 요인에도 좌우되는 사업 성과.
전문가는 다음을 약속할 수 있습니다.
- 합의한 범위에서 캠페인을 준비하고 시작함,
- 분석을 수행함,
- 정해진 수의 자료를 제공함,
- 정의된 기준을 충족하는 기능을 구현함.
반면 매출, 고객 수, 검색 순위처럼 시장, 예산, 제품, 고객의 행동, 외부 시스템에 영향을 받는 결과를 보장할 때는 훨씬 신중해야 합니다.
영국의 최신 위험 배분 지침은 공급자가 자신이 영향을 줄 수 있는 결과에 대해 책임을 져야 한다고 명시합니다. [3]
좋은 설명은 책임을 약하게 하지 않습니다. 실제로 통제 가능한 곳에 책임을 둡니다.
업무 범위는 서비스의 위험과 복잡성에 비례해야 합니다
모든 서비스에 여러 쪽짜리 문서가 필요한 것은 아닙니다.
간단한 작업은 몇 문단으로 핵심 정보를 모두 설명할 수 있습니다. 큰 프로젝트에서는 같은 사고방식을 상세 명세, 일정, 검수 기준, 공식 변경 절차로 확장할 수 있습니다.
세계은행이 공개한 Terms of Reference 예시는 문서가 컨설팅 서비스 요구사항과 발주자의 기대를 명확하게 표현하고, 구체적인 프로젝트와 현지 상황에 맞게 조정되어야 한다고 설명합니다. [4]
핵심은 길이가 아닙니다. 빠진 정보가 현실적으로 가격, 일정, 책임, 기대 결과를 바꿀 수 있는지가 중요합니다.
서비스 설명과 계약은 항상 같은 것은 아니지만 정보는 일관되어야 합니다
웹사이트나 프로필의 서비스 설명은 계약 과정의 한 부분일 수 있습니다. 구체적인 법적 의무는 국가, 거래 유형, 당사자의 지위, 판매 방식에 따라 달라집니다.
EU의 사업자와 소비자 간 거래에서 공식 Your Europe는 계약 전 정보로 서비스의 주요 특성, 요금을 포함한 총가격, 결제 및 수행 방식, 해당되는 경우 계약 기간 등을 제시합니다. [5]
EU의 사업자용 안내는 소비자 계약의 표준 조건이 공정해야 하고, 소비자가 경제적 영향까지 이해할 수 있도록 명확하고 이해하기 쉬운 언어로 작성되어야 한다고 설명합니다. [6]
이 요구사항은 EU의 특정 소비자 거래에 관한 것입니다. 모든 기업 간 거래나 다른 관할권에 자동으로 적용해서는 안 됩니다.
이 글은 서비스 설명을 위한 편집 가이드이며 계약서 양식이나 법률 자문이 아닙니다.
서비스를 공개하기 전에 확인할 12가지 질문
1. 고객은 서비스가 해결하려는 문제 또는 목적을 이해하는가?
2. 최종 결과가 명시되어 있는가?
3. 범위에 포함되는 항목이 명확한가?
4. 고객은 구체적으로 무엇을 받는지 알고 있는가?
5. 완료 여부를 합리적으로 평가할 방법이 있는가?
6. 고객이 제공하거나 처리해야 할 것이 명확한가?
7. 중요한 가정이 드러나 있는가?
8. 혼동하기 쉬운 명백한 제외 항목이 설명되어 있는가?
9. 일정과 단계가 양측의 의존 관계를 반영하는가?
10. 범위가 변경되면 어떻게 되는지 명확한가?
11. 가격, 가격 방식, 추가 비용이 적절한 시점에 제시되는가?
12. 설명이 전문가가 통제할 수 없는 결과를 약속하지 않는가?
좋은 범위라면 양측이 서비스에 대해 같은 의미로 설명할 수 있습니다
좋은 설명을 확인하는 가장 간단한 방법이 있습니다.
읽은 뒤 고객과 전문가가 다음 질문에 거의 같은 답을 할 수 있어야 합니다.
무엇을 달성해야 하는가? 무엇을 할 것인가? 고객은 무엇을 받는가? 무엇이 포함되지 않는가? 고객은 무엇을 해야 하는가? 작업 완료를 어떻게 판단하는가? 범위가 바뀌면 어떻게 하는가?
답이 일치하면 가격과 일정에도 훨씬 좋은 맥락이 생깁니다.
답이 다르다면 문제는 수행 과정에서 처음 생기는 것이 아닙니다. 서비스 설명 단계에서 이미 시작된 것입니다.
출처 및 추가 읽을거리
[1] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
출처 열기
[2] UK Government - The Digital, Data and Technology Playbook
출처 열기
[3] UK Government - Risk Allocation and Pricing Approaches Guidance Note
출처 열기
[4] World Bank - Sample Consultants Terms of Reference
출처 열기
[5] Your Europe - Contract information: what you should know before buying
출처 열기
[6] Your Europe - Contracts with consumers
출처 열기
[7] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
출처 열기
방법론 참고: 각 출처는 적용 범위가 다르며 하나의 공통 서비스 설명 표준을 구성하지 않습니다. 이 글은 결과 중심, 측정 가능성, 명확한 범위, 가정, 공급자가 통제할 수 있는 요인에 대한 책임, 고객에게 투명한 정보 제공이라는 실제로 뒷받침되는 원칙만 사용합니다.
