스크린샷으로 SOP를 작성하는 방법

표준 운영 절차(SOP)는 반복되는 작업을 해당 역할을 맡은 누구가 수행하든 같은 방식으로 처리하는 방법을 정의합니다. 소프트웨어 단계에 스크린샷을 넣으면 한 달에 한 번 이하로 수행하는 작업에서 따라 하기가 특히 쉬워집니다.

이 글은 SOP에 포함해야 할 내용, 작업 지침과의 차이, Mac에서 Temposhot으로 단계를 캡처하는 방법을 다룹니다. 전체 글에서 하나의 예시를 사용합니다. 구독형 사업에서 지원 담당자, 청구 담당자, 재무 승인자가 처리하는 고객 환불 SOP입니다.

SOP란 무엇인가?

SOP는 반복 가능한 프로세스를 정의하는 관리 문서입니다. 목적, 범위, 관련 역할, 단계, 점검 항목을 포함합니다. 월말 마감, 고객 환불, 사용자 계정 해지, 릴리스 점검처럼 일관성이 중요한 작업에 사용합니다.

시각적 SOP는 소프트웨어 단계마다 스크린샷을 추가합니다. 문장으로 된 본문이 기준이 되고, 스크린샷은 해당 단계가 화면의 어디에서 일어나는지 보여줍니다.

프로세스에 SOP가 필요한 경우

모든 작업에 관리 문서가 필요하지는 않습니다. 다음 조건 중 하나 이상에 해당하면 SOP를 작성할 가치가 있습니다.

• 둘 이상의 사람이 작업을 수행해 사람마다 결과가 달라짐
• 분기별 등 드물게 실행되어 담당자가 정확한 화면을 기억하지 못함
• 실수가 금전이나 신뢰에 손실을 줌. 예: 잘못된 카드로 보낸 환불
• 감사인, 고객 계약, 규제 기관이 작업 방식을 요구함

예시의 환불 프로세스는 네 조건을 모두 충족합니다. 세 명이 관여하고, 월 약 40회 실행되며, 오류는 실제 금액의 환불로 이어집니다. 결제 대행사 계약에는 문서화된 환불 정책이 요구됩니다.

SOP와 작업 지침의 차이

두 용어는 혼용되는 경우가 많습니다. 차이는 상세 수준에 있습니다.

구분	SOP	작업 지침
범위	프로세스 전체, 여러 역할에 걸칠 수 있음	프로세스 안의 한 작업임
답하는 내용	무엇이 일어나고, 누가, 언제 하는지 정의함	한 작업을 정확히 수행하는 방법을 정의함
일반적인 길이	몇 페이지 분량과 연결된 작업 지침임	작업 하나, 단계별 설명임
스크린샷	개요용으로 선택 사용함	단계마다 하나

실무에서 시각적 SOP에는 짧은 작업 지침이 섹션으로 포함되는 경우가 많습니다. 긴 스크린샷 순서는 연결된 작업 지침으로 두는 편이 낫습니다.

환불 예시의 분리 방식

환불 SOP 본문은 두 페이지 분량입니다. 클릭 단위의 세부 내용은 프로세스가 거치는 시스템마다 하나씩, 총 세 개의 연결된 작업 지침에 있습니다.

이 분리는 유지보수 범위를 나눕니다. 청구 시스템에서 버튼 위치가 바뀌면 청구 작업 지침만 수정합니다. 금액 한도와 승인 규칙이 있는 SOP 본문은 그대로 둡니다.

프로세스 경계 정의

프로세스의 첫 이벤트와 마지막 이벤트를 각각 한 줄로 적습니다. 예: "환불 요청이 승인되면 시작한다. 고객이 환불 확인 메일을 받으면 끝난다." 이 경계 밖의 내용은 다른 SOP에 속합니다.

명확한 경계는 문서를 짧게 유지하고, 독자가 올바른 문서를 읽고 있는지 판단하게 합니다.

경계 사이의 이벤트 정리

첫 이벤트와 마지막 이벤트 사이에서 인계 지점을 순서대로 나열합니다. 인계 지점은 작업이 다른 사람이나 다른 시스템으로 넘어가는 곳입니다. 환불 프로세스에는 이벤트 5개와 인계 3회가 있습니다.

경계 조건을 엣지 케이스로 검증

단계를 쓰기 전에 특이한 사례 세 가지를 경계 줄에 대입합니다. 전화로 요청한 환불은 여전히 "요청 승인"에서 시작하므로 경계 안에 있습니다. 결제 대행사가 자체적으로 취소한 환불은 승인 단계를 거치지 않으므로 경계 밖에 있습니다. 원래 카드 대신 기프트 카드로 환불하는 경우는 경계 안에 있지만 별도의 예외가 필요합니다.

두 경계 줄 밖의 이벤트는 각자의 SOP를 가집니다. 요청이 환불 자격을 갖추었는지 판단하는 일은 상위의 정책 결정입니다. 나중에 들어오는 차지백 처리는 별도의 분쟁 프로세스입니다.

입력, 역할, 사전 조건 나열

단계 앞에 프로세스가 시작되기 위해 참이어야 하는 조건을 나열합니다.

• 입력: 담당자가 가지고 있어야 하는 문서, ID, 승인 항목임
• 역할: 각 부분을 수행하는 사람, 승인자, 통보 대상임
• 접근 권한: 필요한 시스템과 권한 수준임
• 일정: 마감 기한 또는 주기임. 예: "매월 3번째 영업일까지"

입력이 없는 독자는 아홉 번째 단계가 아니라 첫 페이지에서 이를 알게 되어야 합니다.

환불 예시의 사전 조건

환불 SOP는 체크리스트로 시작합니다. 청구 담당자는 어떤 시스템도 열기 전에 이를 읽고, 항목이 하나라도 빠지면 작업을 중단합니다.

시스템과 역할별 접근 권한 나열

접근 문제는 되돌릴 수 없는 첫 단계 이후, 절차 중간에 프로세스를 멈추게 합니다. 환불 SOP는 시스템마다 역할별로 필요한 권한을 나열합니다. 그래서 첫 클릭 전에 권한 누락을 찾을 수 있습니다.

시스템	지원 담당자	청구 담당자	재무 승인자
헬프데스크	티켓 편집	티켓 읽기	티켓 읽기
청구 대시보드	없음	환불 처리	읽기 전용
재무 원장	없음	없음	항목 생성

역할은 이름이 아니라 직무명으로 작성

"Ana가 환불을 처리한다"라고 쓰면 Ana가 팀을 옮기는 날 문장이 맞지 않게 됩니다. "청구 담당자가 환불을 처리한다"라고 쓰고, 역할과 사람을 연결하는 명부는 별도로 관리합니다. 그러면 담당자가 바뀌어도 SOP를 새로 개정하지 않아도 됩니다.

현재 프로세스 실행과 단계 캡처

현재 실제로 하는 방식대로 프로세스를 기록합니다. 기록은 정기적으로 작업하는 사람이 맡습니다. 실제 프로세스가 돈을 이동시키거나 고객 기록을 바꾸는 경우에는 테스트 계정이나 샘플 계정을 사용합니다.

1. 실행 설정

   Action Capture 페이지(Command+3)에서 Configure를 엽니다. Parse clicked elements를 켜고 제목 템플릿을 Click "[[element-name]]"으로 설정합니다. Mark clicked area도 켭니다.

2. Action Capture 시작

   Start Action Capture를 선택합니다. 앱 사이를 오가는 프로세스에는 Active Window를, 고정된 영역에는 Capture Area를 선택합니다.

3. 프로세스 실행

   승인된 각 클릭은 클릭 직전의 화면을 저장합니다. 처리 후 상태가 바뀌는 화면처럼 클릭이 필요 없는 화면에는 Capture now 또는 Shift+Command+2를 사용합니다.

4. 부수 작업 중 일시 정지

   이메일이나 채팅을 확인하려고 프로세스를 떠날 때는 Pause capture를 선택합니다. 돌아오면 Resume capture를 선택합니다.

5. 캡처 종료

   Finish capture를 선택합니다. 단계마다 한 페이지씩 있는 Document가 편집기에서 열립니다.

편집기에서 각 제목을 동사로 시작하고 조작 대상의 이름을 쓰도록 고칩니다. 조건은 Page description에 씁니다. Action Capture 가이드에서 캡처 대상을 설명합니다.

환불 기록에 사용한 설정

환불 프로세스는 헬프데스크, 청구 대시보드, 재무 원장의 세 앱을 거칩니다. Active Window는 각 클릭을 받은 창을 따라가므로, 미리 창을 고르지 않아도 한 번의 실행으로 세 앱을 모두 기록합니다.

전체 창을 A4 페이지 한 장에 축소하면 큰 원형 표시가 더 잘 보입니다. Show cursor in shortcut captures를 켜면 수동 단축키로 추가한 단계에도 포인터가 표시됩니다. 독자가 한 필드만 확인해야 하는 상태 화면에서 도움이 됩니다.

기록 세션의 진행 방식

청구 담당자는 샌드박스 주문 하나로 환불을 한 번에 기록했습니다. 시작 전에 세션을 계획하여 불필요한 탐색 클릭이 기록에 들어가지 않도록 했습니다.

키보드를 쓰면 세션이 짧아집니다. 아래 단축키는 Temposhot 창으로 전환하지 않고 기록을 제어합니다.

SOP용 제목과 설명 편집

Click "Issue refund" 같은 초안 제목은 "주문 페이지에서 Issue refund를 선택합니다."처럼 지시문으로 고칩니다. 조건은 Page description에 씁니다. 예: "승인된 금액을 입력하고 주문 총액은 입력하지 않습니다." 설명은 내보내기 설정에 따라 PDF에서 이미지 앞 또는 뒤에 인쇄됩니다.

실제 고객 데이터가 보이는 페이지는 모두 제거합니다. 샌드박스 주문에는 대부분 없지만, 헬프데스크 사이드바에는 실제 고객의 최근 티켓이 보일 수 있습니다. 내보내기 전에 Framing으로 자르거나, Blur(Pro)로 해당 영역을 가립니다.

긴 워크플로를 작은 가이드로 나누기

기록이 약 15개에서 20개 단계를 넘으면 자연스러운 구분점을 찾습니다. 역할 간 인계, 대기 시간, 다른 시스템으로의 전환이 그런 지점입니다. 각 부분을 독립된 가이드로 만들고, SOP에서 순서대로 링크합니다.

짧은 가이드는 수정하기 쉽습니다. 시스템 하나가 바뀌면 긴 문서 전체가 아니라 가이드 하나만 교체합니다.

23단계 기록을 나눈 방법

환불 기록으로 페이지 23개가 생성되었습니다. 그중 4개는 실수 클릭이었습니다. 헬프데스크 검색창 클릭 2회와 툴팁 클릭 2회입니다. 나머지 19개 페이지는 시스템이 바뀌는 지점에서 깔끔하게 나뉘었습니다.

Temposhot에는 하나의 Document를 여러 개로 나누는 명령이 없습니다. 대신 같은 캡처 세션에서 부분을 만듭니다. Documents에서 **Capture History…**로 새 Document를 만들고, 세션을 펼쳐 시스템 하나의 프레임만 포함합니다. 각 부분마다 이 과정을 반복합니다.

제목, 프레이밍, 주석 편집은 분할한 뒤 새 Document마다 합니다. 원본 Document에서 먼저 한 편집은 그 Document에만 남습니다. 각 Document가 이미지 사본을 따로 보관하기 때문입니다.

SOP 절차에서 부분 링크하기

SOP의 절차 섹션은 작업 지침을 순서대로 나열하고, 각 지침을 수행하는 역할을 함께 적습니다. 독자는 목록을 훑어 자신의 역할을 찾고, 해당 지침만 엽니다.

1. 지원 담당자가 WI-FIN-014-A로 주문을 조회함 (6단계)
2. 청구 담당자가 WI-FIN-014-B로 환불을 처리함 (8단계)
3. 재무 승인자가 WI-FIN-014-D로 원장 항목을 기록함 (5단계)

각 링크 옆의 단계 수는 기대치를 정합니다. 8단계 지침에서 9단계에 도달한 독자는 무언가 잘못되었다는 것을 알 수 있습니다.

실행 단계 제한에 대비하기

무료 요금제에서는 Action Capture 실행이 5단계 뒤에 멈추며, 그때까지 저장된 단계는 그대로 남습니다. 따라서 23단계 기록에는 Temposhot Pro가 필요하거나, 시스템마다 5단계 미만의 짧은 실행을 여러 번 해야 합니다. 짧은 실행은 앞서 설명한 분할을 자연스럽게 만들므로 SOP에 잘 맞습니다.

관리 항목, 예외, 중단 조건 추가

처리 프로세스 문서는 문제가 생겼을 때 할 일을 포함해야 완결됩니다.

• 관리 항목: 단계가 올바르게 수행되었는지 확인하는 점검임. 예: "상태가 Refunded로 표시됨."
• 예외: 알려진 변형과 처리 방법임. 예: "주문이 90일보다 오래되었으면 수동 환불 SOP를 따름."
• 중단 조건: 작업을 멈추고 에스컬레이션해야 하는 조건임. 예: "금액이 요청과 다르면 작업을 멈추고 재무팀에 문의함."

되돌릴 수 없는 작업 전의 페이지에는 경고를 추가합니다. 짧은 Text 라벨(T)이나 확인 버튼 주변의 Rectangle(R)은 화면을 어지럽히지 않고 주의를 끕니다.

독자가 실행할 수 있는 예외 문장 쓰기

예외는 트리거, 조치, 담당자를 모두 밝힐 때만 유용합니다. 모호한 문장은 위험한 순간에 독자가 추측하게 만듭니다.

되돌릴 수 없는 단계를 스크린샷에 표시

청구 시스템의 환불 확인 대화상자는 실행 취소를 지원하지 않습니다. 해당 페이지에는 Confirm refund 주변에 빨간색 Rectangle을 그리고, "여기서는 되돌릴 수 없음"이라는 4어절의 Text 라벨을 붙여 위험을 표시합니다. 세 작업 지침 모두에서 경고 색상을 하나로 유지해, 의미를 한 번만 익히면 되도록 합니다.

시각적 SOP 구조 사용

1. 제목, SOP ID, 버전, 시행일, 담당자를 적음
2. 목적과 범위(프로세스 경계)를 정의함
3. 역할과 책임을 정의함
4. 입력, 접근 권한, 사전 조건을 나열함
5. 절차: 스크린샷이 포함된 연결 작업 지침을 둠
6. 관리 항목, 예외, 중단 조건을 정의함
7. 관련 문서를 나열함
8. 개정 이력을 기록함

각 작업 지침은 Export PDF로 내보냅니다. Pro에서는 PDF 대화상자가 표지, 단계 번호, 페이지 번호를 추가하고, 설명을 각 스크린샷 앞이나 뒤에 배치합니다. 표지에는 SOP ID와 버전을 적습니다. 내보내기 가이드에서 다른 형식을 확인할 수 있습니다.

환불 SOP의 머리말

예시의 첫 섹션은 다음과 같습니다. 각 줄은 감사인이나 신규 입사자가 가장 먼저 묻는 질문 하나에 답합니다.

• 제목: 고객 환불임
• SOP ID와 버전: SOP-FIN-014, 버전 3임
• 시행일: 승인 후 다음 달 첫날임
• 담당자: 청구팀장임
• 목적: 승인된 환불 요청을 5영업일 이내에 원래 결제 수단으로 환불함
• 범위: 승인된 환불 요청부터 고객 확인 메일까지임

목적 문장에 숫자를 의도적으로 넣었습니다. "5영업일 이내"는 SOP에 측정 가능한 관리 항목을 부여하며, 월간 보고서에서 기한을 넘긴 환불 건수를 셀 수 있습니다.

인쇄용 작업 지침의 PDF 설정

청구 담당자는 월간 대사 작업을 위해 인쇄한 작업 지침을 책상 옆에 둡니다. 세로 방향 A4는 바인더에 맞습니다. 설명을 이미지 앞에 두면 조건이 스크린샷보다 먼저 보입니다.

표지에는 Document 제목과 단계 수가 먼저 나옵니다. 따라서 Document 제목에 "WI-FIN-014-B Issue a refund v3"처럼 ID와 버전을 넣습니다. 이 설정을 바꾸려면 Pro가 필요합니다. 무료 요금제에서는 PDF가 기본값을 사용합니다. 용지는 A4, 방향은 Landscape이고, 표지, 단계 번호, 페이지 번호가 켜진 상태입니다.

SOP와 작업 지침 패키지 구성

SOP 본문과 작업 지침 PDF를 문서 관리 시스템에 함께 저장합니다. 일관된 파일명 규칙은 각 작업 지침을 상위 SOP와 연결합니다.

WI-FIN-014-C는 만료된 카드 예외를 다루며 별도의 실행으로 기록했습니다. 따라서 패키지에는 세 시스템에 걸친 작업 지침이 네 개 있습니다. 파일마다 버전이 다른 것은 의도한 결과입니다. 원장 지침은 첫 배포 이후 한 번, 청구 지침은 세 번 바뀌었으며, 각 파일이 자체 번호를 가집니다.

SOP 테스트와 유지보수 담당 지정

SOP를 작성한 사람이 옆에서 도와주지 않고 지켜보는 가운데, 프로세스를 해본 적 없는 사람이 테스트 계정으로 SOP를 따라 합니다. 질문이 나올 때마다 빈틈이 하나씩 드러납니다.

그다음 담당자 한 명을 지정하고, 검토일을 정하고, 검토 트리거를 나열합니다. 예: 시스템 업데이트, 정책 변경, 사고. 문서는 기록한 Mac에 로컬로 저장되므로, 담당자는 원본 Document를 그 Mac에 보관하고 변경할 때마다 다시 내보내야 합니다.

첫 테스트에서 발견한 내용

신규 지원 담당자가 샌드박스 주문으로 환불 SOP를 따랐습니다. 20분 동안 질문이 세 개 나왔습니다. 티켓의 어디에 주문 ID가 나타나는지, 세금을 환불해야 하는지, 청구 대시보드에서 "부분 환불"이 무엇을 뜻하는지였습니다. 각 질문은 편집으로 이어졌습니다. 티켓 헤더를 프레이밍한 스크린샷, 세금에 관한 예외 한 줄, 페이지 설명의 문장 하나입니다.

수정 후 테스트를 다시 실행합니다. 질문이 없는 두 번째 테스터는 SOP가 승인 준비가 되었다는 신호입니다.

환불 SOP의 검토 트리거

청구팀장은 검토 트리거 네 가지를 정리했습니다. 이 중 하나라도 발생하면 10영업일 이내에 검토를 시작합니다.

• 청구 대시보드 또는 헬프데스크가 작업 지침에 포함된 화면을 변경함
• 환불 정책이 바뀜. 예: 90일 기간 변경
• 고객에게 환불 오류가 전달됨
• 다른 트리거 없이 6개월이 지남

원본 Document를 담당자와 함께 보관

각 작업 지침은 담당자의 Documents 라이브러리에 있는 Document입니다. 청구 시스템이 바뀌면 담당자는 WI-FIN-014-B를 열고, **Capture new images…**로 바뀐 화면을 캡처한 뒤, 이전 페이지를 삭제하고 다시 내보냅니다. 이미 내보낸 PDF는 자동으로 갱신되지 않으므로, 문서 관리 시스템의 파일을 교체하고 버전 번호를 올립니다.

자주 묻는 질문

모든 SOP 단계에 스크린샷이 필요한가?

소프트웨어 단계에는 각각 스크린샷 하나를 넣으면 도움이 됩니다. "고객에게 전화함" 같은 소프트웨어 외 단계에는 스크린샷이 필요 없습니다.

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

시스템 변경, 정책 변경, 사고가 발생할 때마다 검토합니다. 그 밖에는 조직이 정한 주기에 따라 검토하며, 보통 연 1회에서 2회입니다.

SOP와 체크리스트의 차이는 무엇인가?

체크리스트는 확인할 항목을 나열합니다. SOP는 프로세스, 역할, 단계를 설명합니다. 많은 SOP가 체크리스트로 끝납니다. 스크린샷 튜토리얼 체크리스트를 참고합니다.

실제 고객 데이터가 있는 SOP를 기록할 수 있는가?

테스트 계정이나 샌드박스 계정이 있다면 그곳에서 기록합니다. 단계가 실제 운영 환경에서만 존재한다면 Framing으로 페이지를 자르고, 내보내기 전에 Blur로 나머지 세부 정보를 가립니다. Capture History에서 받은 캡처 ZIP에는 항상 편집되지 않은 원본 프레임이 들어 있으므로, 대신 Document 내보내기를 공유합니다.

작업 지침 하나는 얼마나 길어야 하는가?

스크롤을 되돌리지 않고 끝낼 수 있을 만큼 짧아야 합니다. 예시의 세 지침은 각각 5단계에서 8단계입니다. 15단계를 넘으면 인계 지점이나 시스템 변경을 찾아 그곳에서 나눕니다.

문서 관리 시스템에는 어떤 파일을 넣어야 하는가?

각 작업 지침을 내보낸 PDF와, 평소 사용하는 형식의 SOP 본문입니다. Temposhot Document는 담당자의 Mac에 편집 가능한 원본으로 남습니다.

클릭을 명확한 단계별 가이드로 바꾸기

Action Capture는 절차를 한 번 기록하고, SOP에 사용할 순서가 있는 편집 가능한 단계를 제공합니다. Temposhot 다운로드에서 앱을 받아 현재 방식 그대로 프로세스를 캡처합니다.