시스템 이관 계약의 기간이 끝나면서 과업이행확인서를 마감해야 했다. 계약에는 상품 등록부터 인수 실사까지 12개 과업이 있었고, 각각이 끝났는지를 양쪽이 같은 문서로 확인해야 했다. 여기서 정할 것은 「끝났다」를 무엇으로 판정하느냐였다. 이 기준이 흐리면 끝난 줄 알았던 일이 계약 뒤에 다시 돌아오고, 그 비용을 누가 질지 다투게 된다.
Table of contents
Open Table of contents
배경 — 12개 과업과 두 번의 판
과업은 상품 등록·출고 처리·결제 로직 수정·클라우드 인프라 이전·계정과 자산 이관·앱 프론트 수정·양수도 지원·운영 지원·카드 데이터 이관·앱 스토어 배포·결제 장애 대응·인수 실사의 12개였다. 확인서는 계약 기간 중간에 한 번 썼고, 기간이 끝나는 날 최종판으로 대체했다. 중간판에서 미완이던 행은 최종판에서 그 결말만 적었다. 증빙의 모양은 과업마다 달랐다. 클라우드 인프라 이전은 1세대 Cloud Functions 44개를 모두 nodejs22 런타임으로 옮긴 배포 시각이 증빙이었고, 앱 프론트 수정은 iOS 1.10.16 과 Android versionCode 425 로 Google Play 와 App Store 에 낸 판이 증빙이었다.
판단 — 완료의 기준을 무엇으로 둘 것인가
기준을 잡는 방법은 두 가지가 있었다.
- 담당 축이 「끝났다」고 보고한 것을 완료로 적는다
- 증빙이 있는 것만 적는다. 커밋 해시·PR 번호·배포 digest 와 시각·스토어 버전·보고서 경로 중 하나 이상이 붙어야 하고, 조사만 하고 조치가 남은 것은 완료로 적지 않는다
2번을 고른 이유는 확인서가 양쪽이 서명하는 문서이기 때문이다. 보고만으로 적으면 「끝났다」의 뜻이 축마다 달라지고, 계약 뒤에 같은 일을 두고 다른 기억이 맞선다. 반면 보고 대신 증빙을 붙이면 상대도 같은 GitHub 커밋과 스토어 판을 열어 확인할 수 있다. 대가는 손이 많이 든다는 점이다. 앱 행 하나를 갱신하는 데도 Play Console 의 프로덕션 출시 내역과 versionCode, 그 판을 낸 release 브랜치의 커밋을 하나씩 대조했다. 자격증명·계좌번호·카드번호·고객 개인정보는 적지 않고, 계정과 주문은 건수로만 적었다.
해결 — 남은 것을 다섯 갈래로 나눈다
완료 기준을 엄격하게 잡으면 「남은 것」이 생긴다. 그것을 「미완」 한 칸에 몰아 두면 누가 언제 무엇을 해야 하는지가 사라진다. 그래서 남은 것을 성격별로 다섯 갈래로 나눴다.
| 갈래 | 뜻 |
|---|---|
| A | 바로 고쳐 운영에 낼 수 있음(제안만 하고 배포하지 않음) |
| B | 배포 대기 — 이미 편성되고 승인됨 |
| C | 배치가 진행 중 |
| D | 넘겨받는 쪽이나 외부가 해야 하는 영역 |
| E | 계약 범위 밖 — 유지보수로 넘김 |
예를 들어 Android 는 다음 판이 Play 정책상 targetSdk 를 올려야 하는 판이었고, 그 뒤 판에 실을 수정은 출시가 계약 종료 뒤가 되므로 E 로 분류했다. 계정·자산 이관처럼 넘겨받는 쪽이나 외부가 실행해야 하는 일은 D 로 넘겼다. 갈래가 정해지면 인계받는 쪽은 D 를 자기 할 일로, E 를 새 계약의 범위로 바로 읽을 수 있다.
결과 — 증빙 기준이 줄인 분쟁 여지
- 판정의 근거. 12개 과업 모두 증빙과 함께 완료로 적혔다. 그중 양수도 지원의 대량 안내 메일은 발송을 마친 통수(364,510통)까지 증빙으로 남았다
- 분쟁 위험. 「조사만 한 것」을 완료에서 빼, 계약 뒤에 끝났는지를 다툴 여지를 줄였다
- 인계의 형태. 남은 일이 A~E 로 갈라져 인계 문서에 그대로 옮길 수 있게 됐다. 받는 쪽은 할 일과 새 계약 범위를 따로 볼 수 있다
정리
- 계약 과업의 완료는 보고가 아니라 증빙으로 판정한다. 상대도 같은 증빙을 열어 볼 수 있어야 한다
- 조사만 하고 조치가 남은 것은 완료로 적지 않는다. 그것이 뒤의 분쟁을 막는다
- 남은 일은 한 칸에 몰지 않고, 누가 언제 할 일인지가 드러나게 성격별로 나눈다
- 같은 일은 한 번만 적는다. 중간판 뒤의 결말과 새 수행분을 섞지 않아야 대조가 된다