외주 인수인계가 잘 끝났다고 사인오프까지 받았는데, 정작 문제는 운영이 시작된 뒤에 드러나요. 사인오프 직후의 운영 초기 구간은 구조적으로 가장 취약해요. 알람 라우팅이 아직 발주자 쪽으로 넘어오지 않았고, 어떤 지표가 무너졌을 때 누가 일어나는지도 정해져 있지 않거든요. 결제 webhook 재시도 누락, RDS 커넥션 풀 고갈, OAuth 토큰 만료, 로그인 실패율 급등 같은 장애는 이 구간에 터지면 발견 자체가 늦어요. 외주사는 이미 다른 프로젝트로 들어갔고, 발주자는 알람을 받지 못하는 상태니까요. 장애가 없어서 조용한 것과, 장애를 볼 눈이 없어서 조용한 것은 인계 직후에 겉으로 구분되지 않아요.
이게 4월 27일에 다룬 인수인계 12자산이 운영 단계에서 부족한 이유예요. 코드와 클라우드 명의는 받았는데, 그 시스템이 '지금' 잘 돌아가는지 누가 어떻게 보고 누가 새벽에 일어나는지가 합의되지 않았거든요. 자산 목록은 정적이고, 운영은 동적이에요. 넘겨받아야 할 것은 파일과 계정만이 아니라 판단 기준과 당번표예요.
2026년 5월 7일에 다룬 보안 점검 8가지 항목과 5월 9일에 다룬 데이터·DB 인계 7단계가 외주 인계 자산을 정리한다면, 이 글은 그 자산이 운영 단계에서 살아 있게 만드는 '운영 표준 8가지'를 30일 안에 합의하는 가이드예요.
인계 분쟁은 코드가 넘어가는 시점에 터지지 않아요. 코드 이관은 눈에 보이고 체크리스트로 확인되니까요. 분쟁이 실제로 드러나는 곳은 운영이 시작된 뒤예요. 그때가 되어야 "무엇이 정상인가"와 "누구 책임인가"에 합의가 없었다는 사실이 표면으로 올라와요. 반복적으로 관찰되는 패턴은 다음 4가지예요.
이 4가지는 인계 분쟁에서 반복적으로 관찰되는 원인이에요. 공통점은 전부 운영 단계에 가서야 확인된다는 점이고, 그래서 잔금 정산 전에는 아무도 문제를 제기하지 않아요. 특히 비상 대응 단가와 월 호출 캡을 사전에 정해두지 않으면, 잔금 정산이 끝난 뒤에도 추가 청구를 둘러싸고 협상이 다시 열려요. 이미 계약이 종료된 상태에서 시작하는 협상이라 기준이 없고, 그래서 양쪽 다 자기 숫자를 부르게 돼요.
"잘 돌아간다"를 숫자로 만들어요. 최소 4개 SLI를 정의하세요.
각 SLI는 측정 도구·대시보드 URL·에러 버짓(error budget)을 명시해요. SLO가 없으면 외주사는 "버그가 아니다", 발주자는 "약속과 다르다"가 영원히 평행선이에요. 반대로 SLO가 있으면 대화가 짧아져요. 에러 버짓을 다 썼는지 아닌지로 판정되니까 감정이 개입할 자리가 줄어들어요.
인계 후 첫 30일은 외주사·발주자가 동시에 알람을 받아요. 31일 차부터 발주자만 받거나, 외주사가 시간당 단가로 비상 대응을 잇는지 합의해야 해요. 여기서 핵심은 라우팅 변경을 인계 체크리스트의 한 줄로 박아두는 거예요. 알람 수신자가 외주사 채널로만 남아 있으면 발주자는 장애를 실시간으로 볼 방법이 없어요.
이 표 한 장이 없으면 새벽 3시에 누가 일어나는지 모릅니다. 그리고 라우팅을 바꾼 다음에는 반드시 테스트 알람을 한 번 쏴서 실제로 도착하는지 확인하세요. 설정을 바꿨다는 사실과 알람이 도착한다는 사실은 다른 이야기예요.
외주 인계 시점에 다음 5개 런북을 받으세요. 각 런북은 1페이지 / 4단계 / 실행 가능한 명령 포함이 원칙이에요.
5월 9일 데이터·DB 인계 가이드에서 다룬 30분 롤백 런북이 RB-05의 표준이에요. RB-01~04는 5월 7일 보안 점검 가이드의 인시던트 24h 보고 SLA와 맞물려서 운영해야 해요. 런북을 받을 때는 문서 존재 여부가 아니라 실행 가능성을 확인하세요. 명령어에 들어가는 계정·권한이 발주자 쪽에 없으면 그 런북은 종이일 뿐이에요.
등급마다 응답 시간·복구 SLA·보고 의무가 달라요.
이 4등급이 합의되지 않으면 외주는 "P2"로 보고, 발주자는 "P0"로 인식하는 미스매치가 생겨요. 이 미스매치가 기술 문제로 끝나지 않는 이유는 보고 의무 때문이에요. 결제·인증·개인정보가 얽힌 중대 사고는 전자금융거래법과 PIPA에 따라 정해진 기한 안에 보고해야 하는데, 등급 합의가 없으면 그 사건을 중대 사고로 부를지부터 갈려요. 등급을 다투는 동안 보고 기한 자체가 지나가는 게 가장 나쁜 시나리오예요. 그래서 등급표에는 "누가 등급을 확정하는가"까지 적어야 해요. 판정 주체가 비어 있으면 표가 있어도 시계는 흘러가요.
운영의 눈이 없으면 SLO도 알람도 의미가 없어요. 인계 시점에 다음 5종을 받으세요.
5종을 인수할 때 도구 이름만 받고 끝내면 안 돼요. 각 도구의 권한 owner, 결제 수단, 토큰·API 키 만료일까지 한 표로 정리하세요. 결제 카드와 토큰이 외주사 명의로 남아 있으면 만료 시점에 그 도구가 조용히 끊겨요. 문제는 그때 이미 알람이 죽은 상태라는 거예요. 관측성이 끊긴 것 자체는 장애가 아니라서 아무 알람도 울리지 않고, 다음 장애가 났을 때에야 눈이 감겨 있었다는 걸 알게 돼요. 그래서 이 표에는 만료일과 함께 갱신 담당자를 같이 적고, 만료 30일 전 캘린더 알림까지 걸어두는 게 맞아요.
인계 30일 안에 외주사와 함께 다음 4가지 드릴을 30분씩 돌리세요.
드릴의 목적은 시스템 검증이 아니라 인계 검증이에요. 발주자 쪽 사람이 런북만 보고 실제로 복구까지 가는지를 봐야 해요. 외주사 엔지니어가 옆에서 손을 대는 순간 그 드릴은 실패한 거예요. 드릴 비용은 외주 견적의 1~2%로 잡아두세요. 30분 드릴 4번이 새벽 3시 분쟁 1건보다 훨씬 싸요.
운영 단계에서 비용이 새는 방식은 장애와 달라요. 종량제 인프라와 LLM 토큰은 사용량이 폭주해도 서비스가 멈추지 않아요. 멈추지 않으니 알람도 울리지 않고, 예산 알람과 하드 캡이 없으면 다음 달 청구서가 나올 때까지 아무도 모릅니다. 개발 단계에서는 트래픽이 작아 문제가 드러나지 않다가, 운영으로 넘어가 실사용자와 배치 작업과 재시도 루프가 붙는 순간 곡선이 바뀌어요. 인계 시점에 다음 4가지를 정해두세요.
알람만 걸고 캡을 안 거는 실수가 흔해요. 알람은 사람이 봐야 작동하는 장치라서 새벽과 주말에는 무력해요. 금액이 커질 수 있는 항목에는 반드시 자동으로 멈추는 하드 캡을 같이 걸어두세요.
외주 사인오프 후 30·60·90일은 외주가 시간당 단가로 비상 대응을 책임지는 표준 SLA를 박으세요.
이 한 장이 없으면 외주는 "이미 끝났다", 발주자는 "왜 안 일어나냐"가 분쟁이 됩니다. 단가와 캡을 계약 시점에 적어두면 잔금 정산 이후에 열리는 협상이 사라져요. 협상할 게 없어야 관계가 유지돼요. 4월 12일 유지보수 계약 가이드와 같이 묶어서 합의하세요.
외주 인계의 진짜 끝은 잔금 사인오프가 아니라, 새벽 3시 결제 webhook이 멈췄을 때 누가 일어나고 어떤 명령을 치는지가 한 장에 정리된 시점이에요. 8가지 표준은 그 한 장을 30일 안에 만들기 위한 목록이에요.
SLO·온콜·런북 인수 표준 셋업이 막히면 포텐랩 상담에서 무료 1시간 점검을 받을 수 있어요. 인계 자산 표준(SLI·SLO 4종, RB-01~05 런북 5종, P0~P3 SLA 1페이지)이 그대로 따라옵니다. 97% 수행완수율과 Notion 기반 투명 협업으로 운영 30일 안에 자리 잡을 수 있어요.
코드 이관은 눈에 보이고 체크리스트로 확인되지만, 분쟁은 운영이 시작된 뒤에 드러납니다. 그때가 되어야 '무엇이 정상인가'와 '누구 책임인가'에 합의가 없었다는 사실이 표면으로 올라와요. 넘겨받아야 할 것은 파일과 계정만이 아니라 판단 기준과 당번표입니다.
알람 라우팅이 아직 발주자 쪽으로 넘어오지 않았고, 어떤 지표가 무너졌을 때 누가 일어나는지도 정해져 있지 않기 때문이에요. 외주사는 이미 다른 프로젝트로 들어갔고 발주자는 알람을 받지 못하는 상태입니다. 장애가 없어서 조용한 것과 장애를 볼 눈이 없어서 조용한 것은 이 시점에 겉으로 구분되지 않아요.
기준이 없으면 같은 상태를 두고 한쪽은 정상, 다른 쪽은 장애라고 부르게 됩니다. SLO가 없으면 외주사는 '버그가 아니다', 발주자는 '약속과 다르다'가 영원히 평행선이에요. 반대로 SLO가 있으면 에러 버짓을 다 썼는지 아닌지로 판정되니 대화가 짧아지고 감정이 개입할 자리가 줄어듭니다.
최소 네 가지를 정의하세요. 가용성(메인 페이지 200 응답 비율), 지연(API p95 응답 시간), 결제 성공률(결제 webhook 성공률), 로그인 성공률(인증 성공률)입니다. 각 지표마다 측정 도구·대시보드 URL·에러 버짓을 함께 명시해야 나중에 확인이 가능해요.
인계 후 첫 30일은 외주사와 발주자가 동시에 알람을 받고, 31일 차부터 발주자만 받거나 외주사가 시간당 단가로 비상 대응을 잇는지 합의합니다. 라우팅 변경을 인계 체크리스트의 한 줄로 박아두세요. 그리고 바꾼 다음에는 반드시 테스트 알람을 한 번 쏴서 실제로 도착하는지 확인해야 합니다. 설정을 바꿨다는 사실과 알람이 도착한다는 사실은 다른 이야기예요.
네. 단가와 월 호출 캡을 사전에 정해두지 않으면 잔금 정산이 끝난 뒤에도 추가 청구를 둘러싸고 협상이 다시 열립니다. 이미 계약이 종료된 상태에서 시작하는 협상이라 기준이 없고, 그래서 양쪽 다 자기 숫자를 부르게 돼요.