작성일 2026.08.21수정일 2026.08.21작성 SOPBiz 운영자
매뉴얼·SOP
본문의 체크리스트와 기준표를 실제 업무에 맞게 조정해 사용합니다.

“완료했습니다”라는 보고만으로 일을 닫지 않고, 요청 범위·결과물·증거 위치·확인자·반려 사유를 한 장에 남기는 방법입니다. 체크 표시보다 제삼자가 같은 결과를 다시 찾고 통과 여부를 판단할 수 있는지가 완료의 기준입니다.

이번 글에서 직접 확인한 범위

결과물·상태 기록·대조표·승인 기록 네 가지 증거 유형, 통과·반려·보류 판정표, 13개 열과 8개 설명용 업무행을 구성했습니다. 파일 링크가 없는 완료, 확인자가 없는 승인, 반려 뒤 기한이 없는 행을 구분하도록 필수값을 대조했습니다.

가격 안내 파일을 고쳤지만 완료로 닫지 않는 예시

가격 안내 PDF에서 오래된 문장 한 줄을 바꾸는 업무를 가정합니다. 담당자가 새 파일을 저장했다는 사실만으로는 요청한 문장이 모두 바뀌었는지, 웹에 연결된 파일도 교체됐는지, 이전 링크가 남아 있지 않은지 알 수 없습니다. 완료 조건을 “지정한 세 문장 수정, 파일명에 버전 표시, 공개 링크에서 새 파일 확인, 이전 파일 보관 위치 기록”으로 나눕니다.

담당자는 파일 위치와 버전, 공개 링크, 확인 시각을 제출합니다. 확인자는 원본 요청과 새 파일을 나란히 보고 세 문장과 링크를 검사합니다. 두 문장만 고쳐졌다면 상태는 완료가 아니라 반려이며, 반려 코드는 “요청 범위 누락”, 필요한 재제출물은 “수정본과 새 확인 시각”입니다.

이 예시는 특정 사업장의 실제 성과가 아닙니다. 핵심은 확인자가 담당자의 작업 화면을 보지 않아도 같은 자료를 열어 결과를 재현할 수 있게 만드는 것입니다. 승인 기능이 없는 도구에서도 업무 ID, 증거 위치, 판정 시각, 확인자 네 값을 남기면 같은 원칙을 적용할 수 있습니다.

본문에서 확인한 공식 원문

  1. 2020 스크럼 가이드 한국어판

    “완료의 정의”가 결과 상태의 투명성과 공동 이해를 만드는 공식 개념임을 확인합니다. 본문에서는 작은 사업장용 완료표로 한정해 적용합니다.

  2. Google Drive 파일 승인 공식 도움말

    제출, 승인·거절, 승인된 버전 확인을 분리하는 제품의 공식 동작을 확인합니다. 계정 유형에 따른 기능 제한도 함께 봅니다.

  3. GitHub 이슈와 변경 결과 연결 공식 문서

    요청 항목과 실제 변경 결과를 연결해 종료 상태를 추적하는 공식 예를 확인합니다. 소프트웨어 업무에만 해당하는 기능은 일반화하지 않습니다.

각 링크는 2026.08.19에 접근 상태와 운영 주체를 확인했습니다. 개별 법률·안전·계약 판단이 필요한 사안은 해당 기관과 자격 있는 담당자의 최신 기준을 따릅니다.

완료의 뜻을 업무마다 한 문장으로 고정하기

완료 기준은 “열심히 검토함”이나 “이상 없음”처럼 태도를 설명하지 않습니다. 무엇이 만들어지거나 바뀌어야 하는지, 어느 범위까지 확인해야 하는지, 어떤 상태가 남으면 닫을 수 없는지를 씁니다. 예를 들어 고객 안내 수정은 초안 저장이 아니라 승인된 문장, 공개 위치 반영, 이전 문장 미노출까지 포함할 수 있습니다. 확인 기준: 2020 스크럼 가이드 한국어판.

큰 업무는 한 번에 완료로 만들지 않고 독립적으로 확인 가능한 단위로 나눕니다. 파일 제작, 링크 교체, 공개 화면 확인을 서로 다른 행으로 둘 수도 있습니다. 한 행에 여러 결과를 묶으면 일부만 끝났는데 전체가 완료로 보이므로, 확인자가 한 번에 예 또는 아니오로 판정할 수 있는 크기를 기준으로 쪼갭니다.

스크럼 가이드의 “완료의 정의”는 결과의 상태를 모두가 이해할 수 있게 투명하게 만든다는 참고 틀을 제공합니다. 이 글은 스크럼을 도입하자는 제안이 아니라, 작은 사업장의 반복 업무에도 공유된 완료 기준이 필요하다는 부분만 가져옵니다. 업종별 법정 검사나 전문 승인은 이 내부 기준표로 대신하지 않습니다.

업무 성격에 맞는 증거를 선택하기

문서 업무에는 파일 링크·버전·수정 위치가, 연락 업무에는 발송 시각·수신 채널·상태가, 수량 업무에는 기준 시각이 같은 대조표가 필요합니다. 모든 업무에 사진을 요구하면 개인정보와 저장 부담만 늘 수 있습니다. 증거는 결과를 판정하는 데 필요한 최소 범위로 고릅니다.

체크 표시 자체는 증거가 아닙니다. 누가 언제 체크했는지, 어떤 원본과 비교했는지, 체크 뒤 결과물이 바뀌지 않았는지를 확인할 수 있어야 합니다. 파일이라면 승인한 버전과 현재 공개 버전이 같은지 보고, 물리 상태라면 시간·구역·항목을 적어 다른 위치의 사진이 섞이지 않게 합니다.

증거 위치에는 개인 컴퓨터의 임시 경로나 담당자만 열 수 있는 대화방 대신 팀이 접근할 수 있는 공식 위치를 적습니다. 접근 권한이 제한돼야 하는 자료라면 원문을 넓게 공유하지 않고 업무 ID와 보관 위치, 접근 책임자만 기록합니다. 민감정보를 완료 증거로 복사하는 방식은 피합니다.

제출과 확인을 서로 다른 행동으로 남기기

담당자가 증거를 올린 시점은 “제출”이고, 조건을 대조한 뒤 통과를 결정한 시점이 “확인”입니다. 제출과 완료를 같은 상태로 쓰면 확인 대기 업무가 통계에서 사라집니다. 상태를 작업 중·확인 대기·통과·반려·보류처럼 나누고 각 상태의 다음 행동을 고정합니다. 확인 기준: GitHub 이슈와 변경 결과 연결 공식 문서.

작은 팀에서 항상 두 사람이 볼 수 없다면 가짜 검수자를 적지 않습니다. 영향이 작은 반복 업무는 담당자의 자기 점검과 주간 표본 검사를 조합하고, 고객 금액·공개 정보·안전처럼 영향이 큰 업무는 실제 권한자가 확인하도록 범위를 정합니다. 확인 방식 자체를 행마다 공개하면 책임을 과장하지 않아도 됩니다.

Google Drive의 공식 승인 도움말은 승인 요청, 승인·거절, 승인된 버전 확인처럼 제출과 판정을 분리하는 기능을 설명합니다. 해당 기능은 일부 계정에서만 제공되므로 기능이 없는 환경에서는 같은 필드를 표로 구현합니다. 특정 도구의 버튼이 아니라 제출본과 판정본을 연결하는 기록이 핵심입니다.

반려 사유를 재작업 가능한 코드로 쓰기

“다시 확인”, “부족함” 같은 반려 문장은 다음 행동을 만들지 못합니다. 요청 범위 누락, 잘못된 원본 사용, 버전 불일치, 증거 열람 불가, 확인 시각 누락처럼 원인을 분류하고 부족한 항목을 한 문장으로 적습니다. 사람의 성향이나 숙련도를 반려 사유로 쓰지 않습니다.

반려에는 담당자, 재제출 기한, 유지해야 할 기존 상태가 필요합니다. 공개 파일 교체가 반려됐다면 기존 승인본을 계속 노출할지, 새 파일을 임시로 내릴지 운영 기준에 따라 정합니다. 되돌릴 수 없는 변경은 실행 전에 승인받고, 이 완료표를 사후 책임 판단 도구로 오용하지 않습니다.

같은 반려 코드가 반복되면 담당자에게 주의를 주는 데서 끝내지 않고 요청서나 템플릿의 빈칸을 봅니다. “잘못된 원본”이 세 번 반복되면 공식 원본 링크가 여러 개인지 확인합니다. 완료표는 개인 평가표가 아니라 업무 구조의 누락을 찾는 기록으로 사용합니다.

증거의 버전과 보관 종료를 함께 관리하기

링크가 같아도 파일 내용이 바뀔 수 있으므로 버전명, 수정 시각, 승인 대상 범위를 적습니다. 승인 뒤 수정이 필요하면 기존 완료 행을 덮어쓰지 않고 새 업무 ID나 새 버전을 연결합니다. 그래야 어떤 상태를 기준으로 통과했는지 나중에 되짚을 수 있습니다.

증거를 영구 보관하는 것이 목표는 아닙니다. 운영 확인이 끝난 자료, 개인정보가 포함된 자료, 계약이나 법령상 별도 보관이 필요한 자료를 구분하고 보관 검토일을 둡니다. 실제 기간은 업종·자료 성격·내부 정책에 맞게 정하며, 이 글의 예시 날짜를 법적 기준으로 사용하지 않습니다.

보관 위치를 바꾸거나 파일을 정리할 때는 완료표의 링크가 끊어지지 않는지 확인합니다. 원본을 삭제해야 한다면 삭제 권한자와 복구 가능성을 먼저 검토하고, 기록상 증거가 사라진다는 이유만으로 완료 사실을 새로 꾸미지 않습니다. 필요한 경우 판정 요약과 변경 이력만 남깁니다.

표본 검사로 완료 기준 자체를 고치기

매주 통과 업무 몇 건을 다시 열어 증거가 실제로 보이는지, 다른 사람이 같은 판정을 내릴 수 있는지 확인합니다. 모든 행을 재검수해 운영을 무겁게 만들기보다 고객 영향, 반복 반려, 새 담당자 업무를 우선 표본으로 고릅니다. 표본 기준과 선택 이유도 기록합니다. 확인 기준: GitHub 이슈와 변경 결과 연결 공식 문서.

통과 뒤 오류가 발견되면 담당자의 확인 실수만 보지 않고 완료 조건이 모호했는지 점검합니다. 조건에 없는 항목을 사후에 책임으로 돌리지 말고 다음 버전의 기준에 추가합니다. 반대로 아무 판단에도 쓰이지 않는 증거는 삭제 후보로 표시해 제출 부담을 줄입니다.

GitHub 공식 문서는 작업 항목과 변경 결과를 연결해 진행 상태와 종료 관계를 확인하는 예를 제공합니다. 소프트웨어 도구를 쓰지 않는 사업장도 같은 원리로 요청 ID와 결과물, 확인 기록을 연결할 수 있습니다. 링크가 있다고 자동으로 품질이 보장되는 것은 아니며 최종 판정 조건은 사업장이 정합니다.

완료 증거와 판정 기준표

완료 증거와 판정 기준표
업무 유형 필수 결과 적합한 증거 통과 조건 반려 예시
문서 수정 승인된 새 버전 파일·버전·수정 위치 요청 범위와 공개본 일치 문장 누락·버전 불명
고객 안내 정확한 발송·게시 원본 위치·발송 시각 승인 문장과 채널 일치 오래된 원본 사용
수량 확인 기준 시각의 대조값 원장·실측·차이 기록 단위와 기준 시각 일치 단위 혼용·재계수 없음
파일 배포 열리는 최종 파일 배포 링크·해시·열기 시험 권한·형식·버전 통과 링크 접근 불가
현장 점검 지정 구역 정상 상태 구역·시각·체크 결과 멈춤 조건 없음 다른 구역 증거

표의 값은 양식과 판정 순서를 검토하기 위한 설명용 예시입니다. 실제 운영값으로 교체한 뒤 사용합니다.

수정해서 쓰는 작업표

업무 완료를 말이 아닌 증거로 확인하는 완료 기준표 CSV 내려받기

13개 열과 설명용 예시 8행입니다. 실제 고객·거래·성과 정보를 포함하지 않으며 UTF-8 한글 표시와 열 수를 검수했습니다.

실행 전 마지막 대조

  • 업무 시작 전에 완료 조건이 정해졌는가
  • 한 행이 한 번에 판정 가능한 크기인가
  • 결과물과 증거 위치·버전이 연결되는가
  • 제출 시각과 확인 시각이 분리됐는가
  • 실제 확인자와 확인 방식이 적혀 있는가
  • 반려 사유가 재작업 행동으로 이어지는가
  • 민감정보를 불필요하게 증거로 복사하지 않는가
  • 보관 검토일과 기준 수정일이 있는가

판정이 갈릴 때 확인할 답

작은 업무도 모두 확인자가 필요하나요?
항상 두 사람을 배정할 필요는 없습니다. 영향이 작은 업무는 자기 점검과 표본 검사를 쓸 수 있지만, 어떤 방식으로 확인했는지는 숨기지 않습니다. 금액·고객 공지·안전처럼 영향이 큰 업무는 실제 권한자가 확인하도록 별도 기준을 둡니다.
사진 한 장이면 완료 증거로 충분한가요?
사진이 업무 범위, 시각, 위치와 연결되고 판정할 상태가 보여야 합니다. 고객 얼굴·연락처·결제정보가 들어가면 필요한 증거보다 위험이 커질 수 있으므로 최소 범위만 기록합니다.
통과한 업무에서 나중에 오류가 나오면 어떻게 하나요?
기존 판정을 지우지 말고 새 오류 ID와 연결합니다. 당시 완료 조건을 충족했는지, 조건 자체에 빈칸이 있었는지를 분리해 다음 버전과 재검토 범위를 정합니다.
SOPBiz 운영자

작은 사업자의 반복 업무를 문서, 도구, 운영 루틴으로 정리합니다. 책임 운영자가 글의 수정 요청, 검수 기준, 정책 고지를 관리합니다.

콘텐츠 작성 기준 보기