IT SOP는 기술 운영을 일관되고, 안전하며, 규정을 준수하도록 유지하는 데 핵심입니다. Trupeer를 사용하면 무료 IT SOP 템플릿으로 시작해 브랜드 가이드라인에 맞게 커스터마이즈하고, AI SOP 생성기로 각 절차를 명확한 비디오 워크스루로 바꿔 IT SOP 작성에 드는 시간을 몇 시간이나 절약할 수 있습니다.

IT SOP란 무엇이며, 그 양옆에는 무엇이 있는가

표준 운영 절차(SOP)는 반복되는 작업에 대한 문서화된 실행 순서로, 전문가가 아닌 유능한 누군가를 대상으로 합니다. 또한 두 사람이 이를 그대로 따라 하면 동일한 결과가 나오도록 충분히 구체적이어야 합니다.

그 양옆에는 두 개의 문서가 있고, 그것들이 SOP와 계속 혼동됩니다.

정책은 규칙과 경계를 정합니다. 예를 들어 특정 임계값을 초과하는 구매는 승인이 필요하다고 말합니다. 하지만 어떤 버튼이 구매 주문을 올리는지까지는 말하지 않습니다. 정책은 드물게 바뀌며 거버넌스의 승인을 받습니다. “must”와 “may not”을 쓰고 있다면 그것은 정책을 쓰는 것이며, 대신 정책 문서에 넣어야 합니다.

런북(runbook) 또는 절차의 방법(method of procedure)은 단일 변경에 대한 단 한 번의 실행을 말하며, 종종 타이밍이 포함되고 한 번의 야간 작업을 위해 작성됩니다. 사용한 뒤에는 아카이브합니다. SOP는 런북이 빌려 가는 재사용 가능한 요소입니다. 작업이 롤백 윈도우가 있는 일회성 컷오버라면 SOP가 아니라 절차의 방법이 필요합니다.

SOP는 그 사이에 있습니다. 규칙은 다른 곳에 있고, 캘린더도 다른 곳에 있으며, 남는 것은 이번 주에 실제로 보유한 시스템에서 실제로 작업이 어떻게 수행되는지입니다.

어떤 팀에나 적용되는 이 문서의 범용 버전을 원한다면, SOP 템플릿이 표준 구조를 다룹니다. 이 페이지는 절차가 IT 절차일 때 무엇이 달라지는지 설명합니다.

IT SOP가 다른 모든 종류와 다른 이유

레스토랑 SOP, HR SOP, 창고 SOP는 앞으로도 5년 뒤에 사람이 계속 수행할 작업을 설명합니다. 누군가는 항상 고객을 맞이하고 재고를 확인할 것입니다.

하지만 IT 절차는 그렇지 않습니다. 대부분은 사람이 더 이상 하지 말아야 할 작업을 설명합니다. 계정 프로비저닝, 키 로테이션, 파일 복원, 볼륨 크기 조정, 큐 비우기, 공유 드라이브에 대한 액세스 권한 부여—이 모든 것은 처음에는 사람의 절차로 시작하지만, 팀이 제대로 운영된다면 결국 스크립트, 셀프서비스 작업, 또는 질문 자체를 불가능하게 만드는 플랫폼의 설정으로 끝납니다.

즉, IT SOP 라이브러리는 두 가지를 동시에 의미합니다. 하나는 지침 세트이고, 다른 하나는 팀이 손으로 수행하는 모든 작업의 목록(인벤토리)입니다. 두 번째 용도가 더 가치 있지만, 템플릿이 그 항목을 요구하지 않기 때문에 거의 아무도 활용하지 않습니다.

그래서 이 템플릿은 다른 SOP 템플릿에는 없는 필드를 추가합니다. 각 절차는 자신의 미래에 대한 판정을 담고, 라이브러리는 정확성만이 아니라 그 판정들을 기준으로 검토됩니다. 1년에 SOP 40개를 작성하고 그중 12개를 삭제하는 팀은 40개를 작성하고 전부 40개를 유지하는 팀보다 더 잘하고 있으며, 템플릿은 그 사실을 드러내야 합니다.

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

1단계: 템플릿 섹션 열기

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

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

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

3단계: 템플릿 보기 확장

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

4단계: 템플릿 편집

편집(Edit)을 클릭해 선택한 템플릿을 수정하기 시작하세요.

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

• 새 섹션 추가

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

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

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

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

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

커스터마이즈한 템플릿이 어떻게 보이는지 확인하려면 미리보기(Preview)를 여세요.

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

IT SOP 템플릿을 사용하면:

• 작성 시간 절약: IT 절차에 맞게 구성된 구조로 빈 페이지를 건너뛰세요.

• 감사 대응 준비 유지: SOC 2, ISO 27001 및 유사 감사에 대응할 수 있도록 내장 섹션을 제공합니다.

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

• IT 팀 교육: SOP를 IT 교육 비디오와 함께 활용하세요.

• 절차 표준화: 모든 IT SOP에 동일한 템플릿을 사용하세요.

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

처분(disposition) 필드

헤더에 기록된 세 가지 판정이며, 분기마다 검토합니다.

자동화. 절차는 결정론적이며 그 안에 판단이 없습니다. 또한 엔지니어링할 가치가 있을 만큼 충분히 자주 실행됩니다. 키 로테이션, 승인된 요청에서 계정 프로비저닝, 인증서 갱신, 백업 검증, 로그 로테이션, 표준 크기 조정 작업. 막연한 의도가 아니라 목표 분기를 정하세요. SOP는 자동화가 출시될 때까지 계속 살아 있으며, 그 후에는 자동화와 함께 썩어 가도록 방치되지 않고 삭제됩니다. 이것이 바로 두 개의 경쟁하는 진실의 원천을 만들어 내는 실수입니다.

요청자에게 전달. 절차는 결정론적이지만 팀 밖의 누군가가 그것을 수행하길 원합니다. 그리고 IT가 관여하는 유일한 이유는 버튼이 권한 뒤에 있기 때문입니다. 비밀번호 셀프서비스, 그룹 멤버십 요청, 라이선스 할당, 일반적인 소프트웨어 설치. 여기서의 작업은 스크립트가 아니라 셀프서비스 경로에 더해 잡 에이드(job aid)가 포함되어 있어, 무엇을 해야 하는지가 명확해집니다. SOP는 그 경로에 대한 명세가 됩니다.

사람이 유지. 진짜 판단이 필요하며, 자동화는 절감하는 것보다 더 많은 비용이 들 정도로 드물거나, 또는 그 결정에 대해 사람이 책임져야 할 만큼 결과가 중대합니다. 사고 트리아지, 수용(용량) 관련 결정, 벤더와 협상해야 하는 모든 것, 시스템 상태가 아니라 비즈니스 상태에 따라 올바른 조치가 달라지는 모든 경우.

결정하려면 실행 빈도에 평균 소요 시간을 곱해 연간 몇 시간인지 구한 다음, 규칙으로는 인코딩할 수 없는 판단이 어떤 단계에서 필요한지 확인하세요. 판단이 없는 연 60시간은 산술만으로도 자동화 후보입니다. 판단 호출이 세 번 포함된 연 4시간은 아무리 지루하게 느껴져도 사람의 영역으로 남습니다.

템플릿 구조

여기서 복사하세요. 헤더 블록에는 대부분의 SOP 템플릿이 생략하는 필드가 들어 있습니다.

헤더. SOP 번호와 제목. 예를 들어 “메일박스 복원 프로세스”가 아니라 “삭제된 메일박스를 복원”처럼 동사로 시작해 작성합니다. 소유자. 검토자. 생성일. 마지막 검증일. 이는 누군가가 마지막으로 이 절차를 실행해 단계가 여전히 현실과 일치함을 확인한 날짜를 의미하며, 누군가가 문구를 편집한 날짜가 아닙니다. 처분(disposition)과 목표 분기. 실행 빈도와 평균 소요 시간. 필요한 액세스(실제 역할 또는 그룹 이름으로 명시). 접촉한 시스템. 되돌리기 가능 여부(예/아니오).

트리거. 이 절차를 시작하는 이벤트 또는 요청. 사람이 자신이 범위(scope)에 해당하는지 판단할 수 있을 만큼 정확하게 서술합니다.

다음의 경우 실행하지 마세요. 절차가 잘못되는 조건. 이 섹션은 단계가 하는 것보다 더 많은 사고를 예방합니다.

사전 조건. 1단계 전에 확인되어야 하는 액세스, 승인, 정보, 기타 모든 것. 소비자 체크(consumer check)도 포함하세요. 즉, 방금 변경하려는 대상에 의존하는 다른 시스템, 작업 또는 통합이 무엇인지 명시합니다. 이에 답할 수 없다면, 답이 “없음(none)”이 아니라 “알 수 없음(unknown)”입니다.

단계. 번호를 매기고 각 단계마다 하나의 액션만 작성하며, 각 액션 옆에 기대 결과를 적습니다. 어떤 단계에 관찰 가능한 결과가 없다면, 그 단계는 단계가 아니거나 성공이 무엇인지 아직 결정하지 않은 것입니다.

검증. 마지막 단계의 반복이 아닙니다. 검증은 결과가 실제로 발생했는지에 답해야 하며, 변경이 닿는 가장 긴 사이클을 포함해야 합니다. 야간 배치, 복제 지연, 캐시 만료, 크론 스케줄, 하위 동기화. 동기 테스트만으로 검증된 절차는 생애 첫 10초만 검증된 것입니다.

롤백. 되돌리는 방법과, 되돌릴 수 없는 시점.

에스컬레이션. 누구에게, 어떤 경로로, 그리고 무엇을 알려야 하는지.

변경 기록. 날짜, 누가, 무엇이 변경되었고 왜 변경되었는지. 세 줄이면 충분합니다.

작동 예시와 그 비용

Brightmoor Insurance는 “결제 게이트웨이 서명 키를 로테이션”이라는 절차를 90일마다 한 번씩 실행했습니다. 6단계였고, 2023년에 작성된 뒤 사고 없이 14번 실행되었습니다.

3월의 화요일, 엔지니어가 14:20에 이를 작업했습니다. 게이트웨이 포털에서 새 키를 생성하고, 이를 구성 저장소(config store)에 추가한 뒤, 구성을 배포하고, 결제 서비스를 재시작하고, 샌드박스에서 테스트 결제가 성공하는지 확인한 다음, 기존 키를 폐기했습니다. 모든 단계가 완료되었습니다. 샌드박스 결제는 성공했습니다. 티켓은 14:35에 “로테이션 완료” 메모와 함께 종료되었습니다.

02:10에 야간 프리미엄 수집 배치가 인증에서 실패했습니다. 이 배치는 동일한 서명 키를 사용했는데, 그 키는 구성 저장소로 마이그레이션되지 않은 서버의 별도 구성 파일에 보관되어 있었습니다. 해당 서버는 마이그레이션 이전부터 존재했고, 마이그레이션을 수행한 누구도 그 서버가 존재한다는 사실을 알지 못했기 때문입니다.

총 4,100건의 자동이체(직접이체) 수집이 전송되지 않았습니다. 실패는 06:40에 재무팀이 오전 정산을 실행했을 때 발견되었습니다. 수집은 11:00까지 다시 처리되었지만, 야간 편지 발송 작업은 이미 영향을 받은 모든 고객에게 실패한 수집 통지서를 생성해 둔 상태였고, 콜센터는 이후 이틀 동안 380통의 전화를 받았습니다. 네 명이 이 일에 이틀을 썼고, 사과 메일링도 추가로 보냈습니다.

SOP는 틀리지 않았습니다. 6단계 모두 정확했고, 모두 따라 실행되었습니다. 다만 실패한 이유는 두 가지였는데, 둘 다 문서 작성상의 실수가 아니라 구조적인 문제였습니다. 첫째, 이 키를 소비하는 시스템이 무엇인지 묻는 사전 조건이 없어서, 두 번째 소비자가 3년 동안 보이지 않았습니다. 둘째, 검증이 샌드박스 호출이었는데, 이는 14:32에 결제 서비스가 정상임을 증명했지만, 12시간 더 실행되지 않을 배치 작업에 대해서는 아무것도 증명하지 못했습니다.

흥미로운 부분은 그들이 다음에 무엇을 했는지입니다. 일곱 번째 단계를 추가하겠다는 본능이 있었죠. 하지만 실제로 그들이 한 일은 사고가 강제로 컴파일하게 만든 소비자 인벤토리를 구축한 것이었고, 그 인벤토리가 생기자 로테이션은 자동화할 수 있게 되었습니다. 절차는 다음 분기에 예정된 작업으로 출시되었고, SOP는 삭제되었습니다.

문서의 가장 가치 있는 산출물은 지침 자체가 아니었습니다. 지침이 필요로 한다는 것이 드러난 인벤토리였고, 처분(disposition) 필드가 바로 팀이 장애 이후가 아니라 의도적으로 그 항목을 찾게 만드는 요소입니다.

형식(포맷)과 IT 작업에 어떤 것을 사용할지

대부분의 가이드는 4가지 SOP 형식을 나열하고 선택은 사용자에게 맡깁니다. IT 작업에서는 보이는 것보다 선택지가 더 좁습니다.

단계별(step-by-step)은 시작과 종료가 명확한 선형적인 운영 작업에 적합합니다. 복원, 프로비저닝, 로테이션, 배포. 이것이 대부분의 IT SOP이며, 위에서 가정한 구조 형식입니다.

플로우차트 또는 의사결정 트리는 진단에 적합합니다. 다음 액션은 방금 확인한 내용에 따라 달라지기 때문입니다. 사고 트리아지, 연결 장애, 성능 조사. 이러한 항목을 번호 목록으로 강제하지 마세요. 번호는 존재하지 않는 순서를 암시하고, 사람들은 어차피 그 순서를 따라가 버립니다.

체크리스트는 변경 전/후 확인에 적합합니다. 여기서는 순서보다 완전성이 더 중요합니다. 하나를 대체하기보다는 단계별 절차와 함께 사용하세요.

계층형(hierarchical)은 절차가 환경 또는 티어에 따라 실제로 분기될 때만 적합하며, 보통 하나의 제목 아래에 사실상 두 개의 절차가 섞여 있다는 신호이기도 합니다.

90분 만에 작성하기

실제 시스템에서 작업을 정상 속도로 수행하는 화면을 녹화하고, 진행하면서 무엇을 확인하는지 말로 설명하세요. 이 녹화본이 초안입니다.

녹화본에서 단계들을 작성한 다음, 이동만 하느라 실제로 수행하지 않은 단계는 모두 삭제하세요. 남은 각 단계에 기대 결과를 추가합니다. 트리거와 “다음의 경우 실행하지 마세요” 섹션은 마지막에 작성하세요. 그 단계들이 존재해야 그곳에 무엇이 들어가야 하는지 알 수 있기 때문입니다.

그다음 작업을 해 본 적 없는 누군가에게 전달하고, 도와주지 않은 채 그대로 따라 하게 지켜보세요. 그들이 멈추는 모든 지점은 누락된 단계이거나 가정된 지식입니다. 그런 부분을 수정하고, 마지막 검증일을 오늘로 설정한 뒤 게시하세요.

이미 알고 있는 절차라면 90분은 현실적인 시간입니다. 다른 사람의 지식으로부터 문서화하는 절차라면 그 시간을 두 배로 잡는 것이 일반적이며, 지식 전달 SOP는 그 대화를 구조화하는 데 도움이 됩니다.

먼저 작성할 IT SOP는 무엇인가

중요해 보이는 것부터가 아닙니다. 한 번에 세 가지 기준에서 높은 점수를 받는 것들을 작성하세요. 자주 실행되고, 잘못되면 피해가 크며, 현재는 한 사람의 머릿속에만 존재하는 상태입니다.

이 규칙은 보통 동일한 시작 세트를 드러냅니다. 액세스 및 신원 절차(조인/리브, 권한 상승, 공유 계정 처리). 백업 및 복원(대부분의 팀이 백업은 문서화했지만 복원은 문서화하지 않은 경우가 많습니다). 사고 선언 및 에스컬레이션(누가 호출할 수 있는지 포함). 가장 자주 건드리는 시스템에 대한 변경 및 릴리스 단계. 인증서 및 키 로테이션. 엔드포인트 재구축과 자산 인수인계.

리브(퇴사자 처리)와 복원은 가장 안정적으로 문서화되지 않은 것으로 드러나는 두 가지이며, 즉흥적으로 처리할 때의 비용이 가장 큰 두 가지이기도 합니다.

여기에 작성하는 모든 내용은 그것을 설명하기보다 시스템 인벤토리를 가리켜야 합니다. 이를 위한 올바른 장소는 애플리케이션 및 자격 증명 레지스터이고, 더 넓은 시스템 설명은 IT 문서에 들어가야 합니다.

라이브러리 검토하기

분기마다 목록을 놓고, 각 항목에 대해 세 가지 질문을 해보세요.

최근 6개월 내에 검증되었나요? 즉, 누군가 실제로 실행했나요. 검증되지 않은 절차는 없는 것보다 더 나쁩니다. 사람들은 그것을 믿기 때문입니다.

처분(disposition)이 바뀌었나요? 작년에 드물던 절차가 이제는 매주 실행된다면 자동화 영역으로 이동한 것입니다.

무엇이든 출시(배포)되었나요? 그 절차 뒤의 작업이 자동화되었거나 인수인계되었기 때문에 이번 분기에 삭제된 SOP를 세어 보세요. 이 숫자가 3분기 연속으로 0이라면, 라이브러리는 작업 세트가 아니라 단순한 파일링 작업이 되어 버린 것입니다.

빼야 할 것

변경되는 것들의 스크린샷. 즉, 벤더가 일정에 따라 업데이트하는 모든 인터페이스입니다. 스크린샷은 문구보다 문서를 더 빨리 구식으로 만들고, 사람들이 SOP를 신뢰하지 않게 되는 가장 큰 이유가 됩니다. 화면의 위치가 아니라 대상의 이름으로 목표를 설명하세요.

시스템이 왜 그런 방식으로 작동하는지에 대한 설명. 진짜 호기심은 괜찮지만, 문서화에는 들어갈 수 있어도 절차에는 들어가면 안 됩니다. 큐가 밀리는 동안 누군가가 읽는 절차에 넣으면 안 된다는 뜻입니다.

승인 규칙과 임계값. 이것들은 정책입니다. 하나의 숫자가 바뀔 때마다 14개의 문서를 절차에 중복해 업데이트해야 한다면 비효율적입니다.

작성 대신 절차를 녹화해 기록하기

SOP 라이브러리를 만드는 데 가장 느린 부분은 무엇을 쓸지 결정하는 일이 아니라 타이핑입니다. 그리고 기억에 의존해 작성한 절차는, 작성자가 수년 전에 알아차리지 못하게 된 “두 번의 클릭”이 항상 빠져 있습니다.

Trupeer AI는 화면 녹화를 문서화된 절차로 바꾸므로, 위의 90분 방식은 단 한 번의 진행으로 축소됩니다. 작업을 한 번만 녹화하면, 단계별 가이드가 이미 작성된 단계와 함께 제공되고, 보고 싶어 하는 사람들을 위한 비디오가 제공되며, 또한 지식 베이스에(자체 브랜딩으로) 문서가 생성됩니다.

녹화하세요. 브랜딩하세요. 번역하세요. Trupeer하세요.

이 모든 작업을 위해 SOP creator가 만들어졌고, documentation은 절차와 시스템 설명을 함께 유지하며, 번역은 “해 뜨는 대로” 팀이 각자의 언어로 동일한 절차를 읽게 해줍니다. 설정 지침은 문서 템플릿 설정 가이드에 있습니다.

자주 묻는 질문

Excel에 무료 IT SOP 템플릿이 있나요?

Excel은 절차를 담기엔 그릇이 맞지 않고, 라이브러리를 담기엔 적합한 그릇입니다. 제목, 소유자, 마지막 검증일, 처분, 실행 빈도, 연간 시간, 목표 분기 같은 열을 포함해 모든 SOP를 나열하는 한 장의 시트를 만드세요. 이 시트가 분기 검토를 가능하게 합니다. 실제 절차 자체는 버전 이력과 검색이 가능한 어딘가에 있어야 합니다.

Word 버전도 있나요, Word 문서를 무료로 다운로드할 수 있나요?

위의 헤더 블록과 섹션 제목은 Word 또는 Google Docs에 그대로 붙여 넣어 집 구조로 사용할 수 있도록 작성되어 있습니다. 다운로드를 제한하는 게 없다는 뜻이기도 하며, 즉 템플릿과 사용자 사이에 폼이 없습니다. 채워 넣은 버전을 매번 다시 복사하지 말고, 부서의 시작 지점으로 저장하세요.

PDF 버전도 있나요?

절차가 검증된 후에는 직접 내보내기(Export)하면 됩니다. PDF는 서명 승인된 절차를 감사 목적으로 배포할 때 적합하며, 작업 문서로는 적합하지 않습니다. 아무도 편집할 수 없는 절차는 제자리에 오래되어 버리기 때문입니다.

무료로 다운로드할 수 있나요?

구조, 처분(disposition) 필드, 작동 예시는 모두 무료이며 제한이 없습니다. 그대로 사용하고, 편집하고, 자신의 이름으로 출처 표기 없이 본인 템플릿 라이브러리에 넣으세요.

무료 SOP 생성기가 있나요?

네, 그리고 생성기는 초안 단계에서 정말 유용합니다. Trupeer AI의 SOP creator는 화면 녹화를 바탕으로 절차를 구성합니다. 즉, 단계는 사용자의 기억에서 오는 것이 아니라 시스템에서 가져옵니다. 어떤 생성기를 쓰든 생성기가 제공할 수 없는 부분은 처분, 소비자 체크, 검증 윈도우이므로, 그것들은 직접 추가해야 한다고 생각하세요.

팀을 위한 SOP 형식은 어떻게 만들 수 있나요?

한 가지 구조를 선택하고, 실제 절차 3개에 맞게 채운 다음, 템플릿이 표현하기 위해 싸워야 했던 부분이 무엇인지 멈춰서 살펴보세요. 한 번 조정한 뒤 고정하세요. 형식을 계속 다듬는 팀은 절차를 쌓지 못합니다. 매번 새 SOP가 나오면 문서의 형태에 대한 논쟁이 콘텐츠보다 먼저 시작되기 때문입니다.

가장 좋은 SOP 템플릿은 무엇인가요?

팀이 계속 검증해 두는 템플릿이 가장 좋습니다. 구조는 소유권과 검토 날짜보다 훨씬 덜 중요합니다. 누군가가 지난달에 실행한 단순한 6개 섹션 SOP는, 작성된 이후 아무도 열어보지 않은 복잡한 SOP보다 낫습니다.

IT SOP는 얼마나 길어야 하나요?

대부분의 경우 단계는 한 화면이면 충분합니다. 단계가 15개 정도를 넘어가면, 보통 절차가 두 개로 나뉘어 있거나 잘라내야 할 탐색(네비게이션) 내용이 포함되어 있는 경우가 많습니다. 헤더, 사전 조건, 검증은 필요한 만큼 길어도 됩니다. 이런 부분이 사고를 막아 주기 때문입니다.

IT SOP는 얼마나 자주 검토해야 하나요?

각 절차는 최소 6개월마다 실행해 검증하고, 라이브러리 전체는 분기마다 처분(disposition) 필드를 기준으로 검토하세요. 액세스, 키 또는 복원과 관련된 모든 것은 더 짧은 주기로 검토해야 하며, 사고에 관련된 모든 절차는 사고가 종료되기 전에 다시 검증해야 합니다.