관리형 서비스 제공업체(MSP)에게 문서는 단순히 있으면 좋은 것이 아니라 제품 그 자체입니다. Trupeer를 사용하면 무료 MSP 문서 템플릿으로 시작해 브랜드 가이드라인에 맞게 커스터마이징하고, 어떤 기술자든 바로 활용할 수 있는 영상 워크스루로 고객 문서를 전환하여 MSP 문서 작성에 드는 시간을 몇 시간씩 절약할 수 있습니다.

MSP 문서란 무엇이며, 내부 IT 문서와 무엇이 다른가요?

MSP 문서는 관리형 서비스 제공업체가 다른 조직의 기술을 운영하기 위해 기록하는 모든 것을 말합니다. 자산 레지스터, 네트워크 다이어그램, 자격 증명, 런북(runbook), 에스컬레이션 경로, 고객별 특이사항, 그리고 고객이 확인하는 보고서와 리뷰까지 포함됩니다.

구조적으로 내부 IT 문서와 달라지는 지점은 두 가지이며, 거의 모든 템플릿이 그 둘을 무시합니다.

첫째, 본인이 소유하지 않은 환경을 문서화합니다. 고객은 당신이 작성한 내용 중 일부에 대해 권리를 주장할 수 있고 나머지에는 권리가 없습니다. 이 구분은 상업적으로, 계약적으로, 그리고 관계가 끝나는 그날에까지 중요합니다.

둘째, 동일한 절차를 여러 환경에 동시에 문서화합니다. 내부 팀은 백업 복구 런북을 하나 작성합니다. MSP는 하나를 작성한 뒤, 아무도 완전히 기억하지 못하는 방식으로 서로 다른 서른, 마흔 개의 환경에서도 그 내용을 계속 정확하게 유지해야 합니다.

두 번째 문제는 MSP의 마진을 조용히 갉아먹는 문제이며, 그래서 이 페이지가 여기서 시작됩니다. 단일 환경 버전에서는 저희의 IT 문서 템플릿이 일반적인 케이스를 다룹니다.

왜 ‘한 개 런북’의 40개 복사본이 진짜 문제인가요

거의 모든 MSP가 같은 방식으로 시작합니다. 좋은 런북 세트를 만드세요. 고객을 온보딩하세요. 티켓을 처리하는 엔지니어가 한 곳에서 모든 것을 찾을 수 있도록 런북을 해당 고객의 폴더나 공간에 복사하세요. 그리고 반복합니다.

이건 충분히 합리적인 직관이며, 느린 재앙을 만들어냅니다. 서너 해 동안 서른여 개 고객을 상대하면 천 개가 넘는 문서가 생기고, 그 대부분은 서로 거의 비슷한 중복본이며, 어떤 복사본이 최신인지 알 방법이 없습니다.

문서가 나빠서 실패하는 게 아닙니다. 각 복사본은 만들어졌을 때는 정확했습니다. 실패의 원인은 이제 방법론의 개선을 서른 번 적용해야 하고, 누군가 급한 일에 투입되기 전까지는 다섯 번, 열 번 정도만 적용된다는 점입니다.

엔지니어가 다음에 하는 작업이 비용이 많이 듭니다. 환경과 맞지 않는 런북 때문에 기술자가 두 번이나 피해를 본 뒤에는 런북을 읽는 것을 멈춥니다. 대신 더 느리고, 일관성이 떨어지며, 티켓은 여전히 닫히기 때문에 리포팅에서는 완전히 보이지 않는 방식으로, 처음부터 원리로 다시 작업합니다.

따라서 MSP 문서 구조는 표준 업데이트가 ‘한 곳’에서 이루어지도록 만들어야 합니다. 아래 내용은 모두 그 전제에서 나옵니다.

Trupeer에서 이 템플릿을 커스터마이징하는 방법

1단계: 템플릿 섹션 열기

메인 내비게이션에서 템플릿 섹션으로 이동하세요.

2단계: 템플릿 선택 후 열기

작업하려는 템플릿을 클릭해 열어보세요.

3단계: 템플릿 보기 확장

필요한 경우 템플릿 보기를 확장해 전체 레이아웃과 세부 정보를 더 명확하게 확인하세요.

4단계: 템플릿 편집

선택한 템플릿을 수정하기 시작하려면 Edit을 클릭하세요.

편집기에서 다음을 할 수 있습니다:

• 새 섹션 추가

• 서식 규칙 정의 또는 업데이트

• 로고를 추가하고 위치 및 관련 설정을 조정

5단계: 커스터마이징한 템플릿 저장

필요한 모든 변경을 마친 후 Save를 클릭해 업데이트된 템플릿을 본인만의 템플릿으로 저장하세요.

6단계: 미리보기 및 템플릿 미세 조정

커스터마이징한 템플릿이 어떻게 보이는지 확인하려면 Preview를 여세요.

미리보기 화면에서 필요하다면 계속해서 직접 조정할 수 있으며, 템플릿이 원하는 그대로 정확히 표시되도록 할 수 있습니다.

MSP 문서 템플릿으로 다음을 할 수 있습니다:

• 문서 작성 시간 절약: MSP 운영에 맞게 구성된 구조로 빈 페이지를 건너뛰세요.

• MTTR 단축: 명확한 문서는 어떤 기술 지원에도 빠르게 도움이 됩니다.

• 브랜드 유지: Trupeer의 브랜드 키트를 사용해 로고, 글꼴, 색상을 적용하세요.

• 기술자 온보딩을 더 빠르게: 명확하고 영상 기반 문서로 신규 기술자가 빠르게 적응합니다.

• 감사 대응 준비 유지: 내장 섹션이 SOC 2, ISO 27001 및 고객 감사를 지원합니다.

• 글로벌 팀에 도달: 한 번의 클릭으로 MSP 문서를 65+개 언어로 번역하세요.

훌륭한 MSP 문서는 관리형 서비스 비즈니스를 확장 가능하게 만드는 핵심입니다. 이 템플릿을 사용해 모든 고객, 모든 시스템, 모든 절차를 명확하고 일관되게 담아보세요.

표준은 한 번만 문서화하고, 편차만 기록하세요

하나의 표준 라이브러리. 각 문서의 한 벌 복사본. 버전이 관리되고, 소유되며, 방법론이 존재하는 유일한 장소입니다.

그 다음 고객별로는, 그 고객이 표준과 어디에서 다른지 기록하는 짧은 문서 하나만 두고, 그 외에는 아무것도 추가하지 않습니다. 편집이 들어간 런북 복사본이 아닙니다. 예외 목록입니다.

고객 편차 레지스터가 핵심입니다. 고객이 다른 백업 제품을 사용한다면 그건 한 줄입니다. 방화벽 벤더가 다르면 한 줄입니다. 재무 담당 이사가 야간/주말 외 작업에 대한 승인을 반드시 해야 한다면 한 줄입니다. 레지스터에 없는 모든 것은 정의상 표준이므로, 엔지니어는 폴더 하나를 뒤지며 ‘그 안의 복사본이 최신일까?’를 찾는 대신 두 문서를 읽게 됩니다.

레지스터는 계속 작게 유지됩니다. 실제로 성숙한 고객은 대략 8~20줄 정도에 머무르며, 한 번 작성해보면 보통 어디에도 기록되지 않았던 편차 3~4개가 드러납니다.

또 하나의 이점도 나중에 나타납니다. 고객에 대해 표준이 아닌 모든 것을 짧게 정리한 목록은 매우 좋은 영업 및 마진 문서가 됩니다. 편차가 바로 시간이 흘러가는 지점입니다.

고객 편차 레지스터와 여기에 들어갈 내용

편차당 한 줄, 다섯 개 필드.

무엇이 다른가요. 표준과 비교해 명시합니다. 예: “백업은 표준 Veeam이 아니라 Datto입니다”처럼, “Datto를 사용합니다”가 아니라 표준 대비로 적습니다.

어떤 표준 문서에 영향을 주나요. 참고 문서입니다. 런북을 읽는 엔지니어가 여기로 안내받을 수 있어야 합니다.

이유. 고객 선호, 이전 제공업체로부터 물려받은 사항, 준수(컴플라이언스) 요구사항, 기술적 제약. 이 필드는 편차를 제거할 가치가 있는지 판단합니다.

언제부터이며, 언제 검토하나요. 날짜입니다. 온보딩 시 물려받은 편차는 아무도 다시 확인하지 않기 때문에 수년간 지속되는 경우가 많습니다.

노력 또는 리스크. 비용이 얼마나 드는지에 대한 짧은 메모입니다. 이 필드는 레지스터를 기술 문서뿐 아니라 상업 문서로도 바꿔줍니다.

고객을 지칭하는 헤더, 이 레지스터가 작성되는 표준 라이브러리 버전, 계정 소유자를 추가하세요. 레지스터는 분기마다 검토합니다. 이유도 비용도 없는 편차는 표준화 후보이며, 그 작업은 보통 MSP가 할 수 있는 문서화 중 가장 높은 수익을 냅니다.

MSP가 실제로 필요로 하는 문서: 카테고리별

대부분의 MSP는 첫 번째와 다섯 번째 줄에는 강하고 세 번째 줄에는 약한데, 이는 정확히 거꾸로입니다. 세 번째 줄이 두 번째 줄을 ‘사용 가능하게’ 만들기 때문입니다.

이 중 두 개는 자체 템플릿이 있어 그대로 쓰는 것이 좋습니다. 자격 증명과 라이선스 인벤토리는 저희의 애플리케이션 및 자격 증명 레지스터에 자연스럽게 들어가며, 런북 자체는 저희의 IT SOP 템플릿에서 사용하는 구조를 따릅니다.

무료 MSP 문서 템플릿: 구축을 위한 표준 라이브러리

여기서 복사하세요. 이것은 최소 표준 라이브러리이며, 대부분의 MSP가 기대하는 것보다 더 작습니다.

온보딩 팩. 디스커버리 체크리스트, 사이트 감사, 자산 캡처, 자격 증명 캡처, 편차 레지스터 초기 작성, 첫 달 리뷰. 문서 1개로, 고객별로 한 번 실행합니다.

런북(반복 작업당 1개). 백업 복구, 사용자 생성 및 비활성화, 메일박스 복구, 엔드포인트 재구축, 비밀번호 재설정, VPN 액세스, 프린터 배포, 인증서 갱신, 패치 예외. 모든 것을 다 커버하려고 하기보다, 티켓을 가장 많이 만드는 10개 작업부터 시작하세요.

에스컬레이션 및 온콜. 티켓이 어떻게 에스컬레이션되는지, 각 티어에서 누구를 호출하는지, 무엇이 긴급 상황인지, 그리고 야간/주말 외 승인 규칙.

장애 및 변경. 장애 후 리뷰 형식, 그리고 고객 인프라에 대해 계획된 변경을 위한 절차 방법 형식.

고객에게 제공하는 보고서. 월간 보고서, 분기 비즈니스 리뷰, 사이트 감사 출력물. 고정 형식이며 고객 데이터만 채워 넣습니다.

오프보딩 팩. 고객이 받는 것, 당신이 보관하는 것, 어떤 형식으로, 언제까지. 필요해지기 전에 작성합니다.

편차 레지스터 템플릿. 위의 다섯 개 필드.

여기로 복사하세요. 런북 10~15개와 상시 문서 6개면 작업 가능한 라이브러리입니다. 먼저 런북 40개를 쓰려는 본능이 대부분의 MSP 문서화 프로젝트가 2개월 차에 멈추는 이유입니다.

내부 및 외부 MSP 문서, 그리고 누가 소유하는가

대부분의 가이드가 내리는 구분은 내부 vs 고객에게 제공하는 문서로, 톤을 결정하는 데 유용합니다. 더 중요한 구분은 ‘소유권’이며, 오프보딩 시점에서 현실이 됩니다.

대체로(계약과 관할에 따라 달라질 수 있지만) 고객의 데이터는 고객의 것입니다. 고객의 장비를 설명하는 자산 레지스터, 네트워크 토폴로지, 자격 증명, 라이선스 권한, 구성(configuration) 등이 여기에 해당합니다. 당신은 그것을 소유하는 것이 아니라 서비스 제공업체로서 보관합니다.

당신의 방법은 당신의 것입니다. 표준 런북, 보고서 형식, 구축 표준, 가격 모델, 내부 절차까지 포함됩니다. 고객이 떠난다고 해서 당신의 런북 라이브러리에 대한 권리가 고객에게 생기지는 않습니다.

편차 레지스터는 그 사이에 애매하게 놓이기 때문에, 계약서에 명시적으로 이름을 붙일 가치가 있습니다. 편차 레지스터는 고객의 환경을 설명하므로 고객의 것이라고 주장할 근거가 있지만, 당신의 표준을 기준으로 작성되기 때문에 ‘마스킹된 버전’이 필요하다는 주장도 가능합니다.

이 문제는 종료 시점에서가 아니라 서비스 계약서에 서면으로 정리하세요. 이 페이지는 법률 자문이 아니며 계약과 관할에 따라 입장이 달라질 수 있으니, 문서 소유권 및 반환 조항은 변호사가 검토하도록 하세요. 한 번 처리하는 데는 한 시간이 듭니다. 아래처럼 오프보딩 중에 처리하면 훨씬 더 많은 비용이 듭니다.

문서 1,360개와 오래된 런북 9개를 가진 MSP

Thornbury IT는 22명의 직원(그중 9명이 엔지니어)으로 서른네 명의 고객에게 관리형 서비스를 제공했습니다. 매 온보딩마다 런북 세트를 새 고객의 공간에 복사했는데, 4년차가 되자 고객당 대략 40개 문서, 총 1,360개 정도가 되었습니다.

문제는 장애(인시던트) 중에 드러났습니다. 한 엔지니어가 한 고객의 복구 런북을 따라 실패한 백업을 처리했습니다. 그 런북에는 Veeam 작업 명명 규칙이 참조되어 있었습니다. 고객은 14개월 전에 이미 다른 백업 제품으로 옮겼습니다. 표준 런북은 업데이트되었지만, 해당 고객 폴더의 복사본은 업데이트되지 않았습니다.

이후 그들은 12개 고객의 복구 런북을 샘플링했습니다. 9개는 현재 표준과 달랐고, 그 9개 차이 중 5개는 의도된 변경이 아니라 단순히 오래되어 생긴 것이었습니다.

정량적으로 측정된 비용은 처리 시간에서 발생했습니다. 전체 비즈니스에서 평균 티어2 처리 시간은 47분이었습니다. 런북이 오래된 고객의 경우 71분이었는데, 해당 계정의 엔지니어들이 문서를 더 이상 신뢰하지 않게 되어 매번 직접 다시 계산했기 때문입니다.

별도로, 3년차에 한 고객이 떠나면서 문서를 요청했습니다. Thornbury는 고객 폴더를 보냈는데, 그 폴더에는 고객의 자산 레지스터와 자격 증명이 섞여 있는 상태에서 고객만의 표준 런북도 함께 들어 있었습니다. 누구도 그 경계를 그어본 적이 없었습니다. 고객이 무엇을 받을 자격이 있는지에 대한 논쟁은 6주가 걸렸고 양쪽 회사의 변호사가 모두 참여했습니다.

재구축에는 한 사람의 시간으로 한 달이 걸렸습니다. 하나의 표준 라이브러리, 단일 복사본, 버전 관리. 고객별로는 편차 레지스터만. 레지스터의 중앙값 길이는 11줄이었습니다.

1,360개의 문서는 40개의 표준 문서와 34개의 레지스터로 바뀌어 총 74개가 되었습니다. 티어2 처리 시간은 모든 계정에서 44분으로 수렴했습니다. 그리고 오프보딩 팩은 그 이후로 계약서에서 정의되었습니다. 고객은 자산 레지스터, 자격 증명, 다이어그램, 그리고 편차 레지스터를 받으며, Thornbury는 표준 라이브러리를 보유합니다.

GitHub에 무료 MSP 문서 템플릿이 있나요?

네, 그리고 현실적인 기대를 가지고 살펴볼 만합니다.

여기서 찾을 수 있는 것은 런북 컬렉션에 대한 커뮤니티 리포지토리, 문서가 내장된 PowerShell 스크립트 라이브러리, 마크다운 기반 문서 프레임워크, 그리고 가끔은 채용 또는 마케팅 목적으로 MSP가 공개한 전체 문서 구조까지입니다. 마크다운이나 docs-as-code와 함께 MSP 런북 또는 IT 문서를 검색하면 대부분이 드러납니다.

그 리포지토리에서 실제로 유용한 것은 구조와 커버리지입니다. 유능한 MSP가 유지하는 런북 목록은 여러분의 체크리스트로 삼기 좋습니다. 반대로 콘텐츠는 자주 유용하지 않은데, 런북은 특정 도구 스택에 맞춰져 있고, 다른 사람의 백업 제품과 RMM에 대한 복구 절차는 템플릿이라기보다 ‘실제 사례에 가까운 예시’에 더 가깝기 때문입니다.

주의할 점은 두 가지입니다. 상업용 문서 라이브러리에 무엇이든 포함하기 전에 라이선스를 확인하세요. 허용형 라이선스가 흔하긴 하지만 보편적이지는 않습니다. 그리고 실제 고객 식별자, 네트워크 상세 정보, 자격 증명처럼 보이는 어떤 것도 포함된 리포지토리는 절대 그대로 가져오지 마세요. 이런 것들은 공개 리포지토리에서 생각보다 더 자주 발견되지만, 그럴수록 더더욱 그러면 안 됩니다.

또 하나는 docs-as-code 접근 자체(즉, 버전 관리에서의 마크다운)인데, 이는 MSP에게도 정당한 옵션이며 단일 복사본 문제를 우아하게 해결합니다. 다만 약점은 시간에 쫓기는 엔지니어가 리포지토리에 커밋하지 않는다는 점이라, 도입의 제한 요인이 도구가 아니라 ‘사람의 실행’이 되는 경우가 많습니다.

MSP 문서 소프트웨어와 벤더 락인 문제

MSP를 대상으로 한 문서 플랫폼은 직접 만들기 어려운 것들을 잘 처리합니다. 구조화된 자산 관계, RMM 및 PSA와의 통합, 감사 추적이 포함된 자격 증명 처리, 그리고 권한으로 분리된 고객별 데이터 구성이 그것입니다.

트레이드오프는 문서가 그들의 데이터 모델에 맞춰 형태가 잡힌다는 점입니다. 그리고 다시 ‘사용 가능한 형태’로 꺼내오는 것은 영업 과정이 시사하는 것보다 훨씬 더 나쁜 경우가 많습니다. 보통 내보내기는 엔지니어가 실제로 사용하는 ‘읽을 수 있는 문서’가 아니라, 레코드 묶음 형태가 됩니다.

커밋하기 전에 확인할 만한 질문은 두 가지입니다. 관계와 첨부파일까지 포함해, 다른 제품을 다시 구매하지 않더라도 여전히 사용 가능한 형식으로 모든 것을 내보낼 수 있나요? 그리고 고객 전반에 적용되는 단일 표준 문서를 유지할 수 있나요, 아니면 모델이 고객별 복사본을 강제해 이 페이지에서 다루는 바로 그 문제가 다시 발생하나요?

두 번째 질문은 생각보다 더 많은 제품을 배제하게 만듭니다. 플랫폼이 고객별 복사본을 강제한다면, 표준 라이브러리는 그 밖에 더 단순한 형태로 보관하고, 플랫폼은 고객 환경 데이터에만 사용하세요. 플랫폼이 실제로 잘하는 것이 바로 그것이기 때문입니다. 저희의 지식 베이스 템플릿은 표준 라이브러리가 어디에 있든 그 구조화를 다룹니다.

고객이 떠나면 문서는 어떻게 되나요?

오프보딩 단계에서 문서 품질이 드러납니다. 보통은 이미 불만이 있는 사람들에게서요.

팩(pack)을 계약서에 정의하세요. 합리적인 입장은 고객이 자산 레지스터, 네트워크 다이어그램, 라이선스 인벤토리, 자격 증명을 안전하게 이전받고, 편차 레지스터 및 고객이 비용을 지불한 문서들을 납품물로 받는다는 것입니다. 당신은 표준 런북, 보고서 형식, 내부 절차를 유지합니다.

같은 조항에서 기간과 형식을 정하세요. “문서는 제공될 것입니다”라고만 쓰면 분쟁이 시작됩니다. 30일과 지정된 형식이 일반적입니다.

자격 증명 핸드오버는 스프레드시트가 아니라 적절한 프로세스로 진행하고, 무엇이 언제 이전되었는지 기록하세요. 나중에 어떤 항목이 접근되더라도 그 기록이 양측을 보호하기 때문입니다.

이탈이 내부가 아니라 다른 제공업체로의 이전이라면, 문서 덤프(document dump)보다 구조화된 핸드오버가 훨씬 저렴합니다. 그리고 저희의 지식 이전 SOP에는 그 방법이 정리되어 있습니다.

MSP 문서 템플릿을 PDF로 받을 수 있나요?

PDF는 이 중 두 가지에는 맞고, 나머지에는 맞지 않습니다.

고객에게 제공하는 문서에는 맞습니다. 월간 보고서, 분기 리뷰, 사이트 감사 출력물입니다. 이 문서들은 특정 시점의 스냅샷이므로 고정하는 것이 맞고, 고객에게 전달될 때는 브랜드가 반영되어야 합니다.

런북, 편차 레지스터, 자산 레지스터에는 맞지 않습니다. 이들은 모두 변경되며, 모두 검색 가능해야 합니다. 위의 ‘실제 사례’에서처럼 PDF 런북 라이브러리는 더 느린 버전이 됩니다. PDF는 독자에게 “최신이 아닙니다”라고 말해줄 수 없기 때문입니다.

표준 라이브러리는 엔지니어가 실제로 압박 속에서 검색할 방식대로 사용하고, 한 벌만 유지하세요. 고객 납품물의 경우에는 별도로 관리하지 말고, 그 소스에서 PDF를 생성하세요.

모든 고객에 걸쳐 표준 라이브러리를 최신 상태로 유지하는 방법

전체 구조는 표준 라이브러리가 실제로 제대로 유지 관리되어야 하며, 보통 그렇지 않은 이유는 런북을 업데이트하려면 이미 사용 방법을 알고 있는 도구에 대해 누군가 스크린샷을 찍고, 자르고, 다시 써야 하기 때문입니다.

Trupeer AI는 그 대부분을 제거합니다. 엔지니어가 한 번 카메라로 작업을 수행하면, 출력물은 이미 단계와 화면이 갖춰진 포맷된 런북이 되어 검토할 준비가 됩니다. 직접 쓰는 대신 검토만 하면 됩니다. 런북 10개를 새로 고치는 데 걸리던 시간이 분기가 아니라 하루가 됩니다.

기록하세요. 브랜드를 입히세요. 번역하세요. Trupeer하세요.

고객에게 제공하는 자료에서는 브랜딩이 상업적으로 중요하며, 브랜드 키트를 사용하면 고객이 받는 보고서와 가이드가 템플릿에서 나온 것처럼 보이지 않고, 마치 여러분에게서 나온 것처럼 보이게 됩니다. Documentation 및 technical documentation는 표준 라이브러리와 고객 환경 기록을 함께 유지하며, SOP creator는 런북 자체를 다룹니다. 설정 안내는 문서 템플릿 설정 가이드에 있습니다.

자주 묻는 질문

PDF로 된 무료 MSP 문서 템플릿이 있나요?

이 페이지의 구조는 모두 무료로 복사할 수 있으며, 합리적인 분리는 런북과 레지스터는 검색 가능한 형태로 유지하고, 고객에게 제공하는 보고서는 PDF로 내보내는 것입니다. 제한된 다운로드도 없고, 폼도 없습니다. 참고용으로 표준 라이브러리의 PDF가 필요하다면, 별도로 유지 관리하지 말고 현재 라이브 복사본에서 생성하세요.

가장 좋은 무료 MSP 문서 템플릿은 무엇인가요?

가장 좋은 세트는 ‘최신 상태로 유지할 수 있는 것’ 중 가장 작은 것입니다. 티켓이 가장 많이 발생하는 영역을 커버하는 런북 10~15개, 온보딩 팩, 에스컬레이션 문서, 편차 레지스터 형식, 그리고 고객에게 제공하는 보고서 형식 3가지를 포함하세요. 템플릿 라이브러리는 표준과 고객별 예외를 분리하는지 여부로 판단해야 합니다. 그 부분이 30개 고객을 유지할 수 있는지를 결정하기 때문입니다.

MSP는 문서를 어디에 보관해야 하나요?

고객 환경 데이터는 RMM 및 PSA와 통합되고 자격 증명을 올바르게 처리하는 플랫폼에 있어야 합니다. 표준 라이브러리는 엔지니어가 가장 빠르게 검색할 수 있는 곳에 있어야 하며, 같은 플랫폼일 수도 있고 더 단순한 무언가일 수도 있습니다. 결정적인 질문은 그 플랫폼이 모든 고객에 적용되는 ‘한 문서’를 유지할 수 있게 해주느냐입니다.

신규 고객 온보딩 시 문서를 얼마나 제공해야 하나요?

표준 라이브러리는 제공하지 않고, 고객의 환경 데이터는 모두 제공해야 합니다. 실제로 고객이 온보딩에서 가치 있게 여기는 납품물은 자산 레지스터, 네트워크 다이어그램, 그리고 무엇을 발견했고 무엇을 권장하는지에 대한 간단한 요약입니다. 온보딩 시 런북을 보내는 것은 흔한 직관이지만, 상업적 수익 없이 여러분의 방법론을 그대로 넘겨주는 셈이 됩니다.

고객은 우리가 고객의 시스템에 대해 작성한 문서를 소유하나요?

대개 고객 데이터는 ‘예’, 여러분의 방법은 ‘대개 아니요’이며, 경계는 종료 시점에서 논쟁하기보다 서비스 계약서에 명시되어야 합니다. 자산 레지스터, 다이어그램, 자격 증명, 구성(configuration)은 고객의 재산을 설명합니다. 여러분의 표준 런북과 보고서 형식은 여러분의 지적 재산입니다. 계약과 관할에 따라 입장이 달라질 수 있으니, 해당 조항은 여러분의 변호사가 검토하도록 하세요.

엔지니어가 문서를 건너뛰지 않게 하려면 어떻게 해야 하나요?

먼저 표준 라이브러리를 신뢰할 수 있게 만드세요. 엔지니어가 문서를 건너뛰는 이유는 읽는 것을 싫어해서가 아니라, 이전에 틀린 적이 있었기 때문입니다. 단일 복사본 문제를 해결하고 처리 시간을 수렴시키면, 행동은 그 자체로 바뀝니다. 티켓 종료 시점에만 문서 업데이트를 요구하는 방식은 라이브러리가 업데이트할 가치가 있을 때 한 번만 제대로 작동합니다.