AI 관측성 계약 루프

AI에게 기능 구현을 맡기면 화면, API, 배치 작업은 빠르게 만들어집니다. 문제는 장애가 난 뒤에야 “무엇을 봐야 하지?”를 묻게 되는 순간입니다. 로그는 남아 있지만 요청 흐름을 잇는 값이 없고, 메트릭은 있지만 사용자가 느낀 실패와 연결되지 않고, 알림은 울리지만 롤백할 숫자 기준이 없습니다. 그러면 AI가 만든 기능은 배포 전에는 좋아 보였지만 운영 중에는 설명할 수 없는 검은 상자가 됩니다.

관측성 계약은 기능을 만들기 전에 “이 기능이 살아 있다는 증거를 어떤 로그 이벤트, 메트릭, 트레이스, 대시보드, 알림 임계값으로 확인할 것인가”를 먼저 합의하는 방식입니다. 초보자는 관측성을 “문제가 생겼을 때 볼 수 있는 계기판”으로 이해하면 됩니다. 실무자에게는 더 엄격합니다. 어떤 이벤트 이름을 남길지, 어떤 필드를 개인정보 마스킹할지, 어떤 상관관계 ID로 요청을 묶을지, 어떤 SLO와 오류 예산을 넘으면 카나리 배포를 멈출지까지 코드 변경의 일부로 다룹니다.

VIBE 코딩에서 관측성 계약은 AI 작업 지시서의 품질을 크게 바꿉니다. “결제 실패 처리를 구현해 줘”라고 말하는 대신 “결제 실패 처리와 함께 구조화 로그, 실패율 메트릭, 사용자 영향 대시보드, 알림 임계값, 롤백 기준을 추가하고 테스트로 검증해 줘”라고 지시합니다. 그러면 에이전트는 기능 코드만 만드는 것이 아니라 운영자가 확인할 증거까지 함께 남깁니다.

핵심 결론

AI 관측성 계약 루프의 핵심은 배포 후 질문을 배포 전 계약으로 바꾸는 것입니다. 장애가 난 뒤에 “로그가 어디 있지”, “이 오류가 몇 명에게 영향을 줬지”, “롤백해야 하나”를 찾는 대신, 구현 전에 관측성 계약을 작성합니다. 계약에는 로그 이벤트, 구조화 로그 필드, 상관관계 ID, 메트릭 이름, 대시보드 패널, 알림 임계값, 트레이스 범위, 샘플링 정책, SLO, 오류 예산, 카나리 배포 중단 조건, 개인정보 마스킹 규칙이 들어갑니다.

이 루프는 세 가지 산출물을 요구합니다. 첫째, 기능 요구사항 옆에 운영 질문을 적습니다. 예를 들어 “사용자가 초대 링크로 팀에 합류한다”라는 기능 요구사항 옆에 “초대 만료, 권한 없음, 중복 가입, 메일 발송 실패를 각각 어떻게 구분해 볼 것인가”를 둡니다. 둘째, 코드 변경과 함께 관측성 변경을 리뷰합니다. 로그가 너무 많거나, 메트릭 라벨이 폭발하거나, 개인을 식별할 수 있는 값이 노출되면 기능이 동작해도 통과시키지 않습니다. 셋째, 배포 후 스모크 테스트에서 화면만 보는 것이 아니라 대시보드와 알림 조건도 확인합니다.

좋은 관측성 계약은 “완벽한 모니터링”을 목표로 하지 않습니다. 처음부터 모든 것을 계측하려고 하면 개발 속도가 무너지고 비용이 커집니다. 대신 이번 변경이 깨질 때 가장 먼저 봐야 할 신호를 좁게 정합니다. 사용자 요청이 시작되고 끝났는지, 외부 서비스 호출이 실패했는지, 재시도 큐가 밀리는지, 성공률이 기존 기준보다 떨어졌는지, 오류 예산을 소비하고 있는지에 집중합니다. 좁지만 정확한 계기판이 넓고 흐릿한 로그 더미보다 훨씬 유용합니다.

왜 중요한가

AI가 만든 코드는 운영 증거가 빠지기 쉽다

AI 에이전트는 명시된 요구사항을 우선합니다. 요구사항이 “버튼을 누르면 알림을 보낸다”라면 버튼, 상태 변경, 알림 발송 코드는 잘 만들 수 있습니다. 그러나 운영자가 필요한 증거는 자동으로 생기지 않습니다. 알림 요청 ID가 남지 않거나, 발송 실패와 사용자 취소가 같은 오류로 뭉치거나, 성공률 메트릭이 없어 지난 배포와 비교할 수 없는 일이 흔합니다. 기능이 동작하는 것과 기능을 운영할 수 있는 것은 다른 문제입니다.

관측성 계약은 이 빈틈을 줄입니다. AI에게 “성공하면 무엇을 기록하고, 실패하면 무엇을 기록하고, 사용자가 영향을 받으면 어떤 메트릭이 움직여야 하는지”를 알려 줍니다. 특히 VIBE 코딩처럼 사람이 설계하고 AI가 구현하는 방식에서는 이 계약이 사람의 운영 경험을 코드에 주입하는 가장 짧은 통로가 됩니다.

장애 대응은 로그 양이 아니라 연결성으로 결정된다

로그가 많아도 요청 흐름이 끊기면 원인 분석은 어렵습니다. 프론트엔드 클릭, API 요청, 큐 작업, 외부 호출, 데이터 저장, 알림 발송이 각각 따로 기록되면 한 사용자의 실패를 끝까지 추적할 수 없습니다. 상관관계 ID는 이 흐름을 묶는 실입니다. 요청이 들어올 때 생성되거나 전달된 ID를 모든 로그 이벤트, 트레이스, 비동기 작업에 넣으면 “어느 단계에서 지연되었는가”를 빠르게 볼 수 있습니다.

메트릭도 연결성이 중요합니다. 단순 오류 수만 보면 사용자가 많은 날에는 항상 높게 보입니다. 성공률, 지연 시간 분위수, 큐 적체 시간, 외부 호출 실패율, 재시도 횟수, 사용자 영향 건수처럼 비율과 분포를 함께 봐야 합니다. 알림 임계값은 이 메트릭을 기준으로 정합니다. “오류 1건이면 알림”은 피로를 만들고, “아무도 안 보면 알림 없음”은 장애를 놓칩니다. 관측성 계약은 어떤 숫자가 움직이면 사람을 깨울지 미리 정합니다.

배포 판단은 느낌이 아니라 SLO와 오류 예산으로 해야 한다

AI가 만든 변경은 작아 보여도 실제 사용자 흐름에서는 예상보다 큰 영향을 줄 수 있습니다. 카나리 배포를 할 때 “왠지 괜찮아 보인다”로 판단하면 사고가 늦게 발견됩니다. SLO는 사용자가 기대하는 서비스 수준을 숫자로 표현합니다. 예를 들어 “초대 수락 API의 99%는 800ms 안에 끝나야 한다” 또는 “결제 웹훅 처리 실패율은 0.5% 미만이어야 한다”처럼 정합니다. 오류 예산은 일정 기간 동안 허용할 수 있는 실패 여유입니다.

관측성 계약에 SLO와 오류 예산을 넣으면 AI 코딩의 배포 루프가 더 안전해집니다. 카나리 배포 중 실패율이 기준을 넘으면 자동 또는 수동으로 멈추고, 롤백 기준에 맞으면 즉시 되돌립니다. 중요한 것은 이 기준이 배포 전에 합의되어야 한다는 점입니다. 장애가 난 뒤에는 사람마다 감정과 이해관계가 달라져 판단이 흔들립니다.

실제 작업 순서

1단계: 기능 요구사항 옆에 운영 질문을 붙인다

새 기능을 AI에게 맡기기 전에 기능 요구사항을 한 줄로 쓰고, 바로 아래 운영 질문을 붙입니다. 예를 들어 “사용자가 팀 초대 링크를 열어 가입한다”라는 요구사항이 있다면 다음 질문을 적습니다. 성공한 가입은 어떤 로그 이벤트로 남는가. 만료된 링크, 이미 가입한 사용자, 권한 없는 사용자, 메일 인증 미완료 사용자는 어떻게 구분되는가. 이 흐름의 지연 시간은 어떤 메트릭으로 보는가. 카나리 배포 중 어떤 숫자가 나빠지면 멈추는가. 개인정보 마스킹은 어디까지 필요한가.

이 질문은 길 필요가 없습니다. 중요한 것은 AI에게 “기능 완료”의 정의가 화면 표시와 테스트 통과만이 아니라 운영 증거까지 포함한다는 사실을 알려 주는 것입니다. 질문을 쓰면 구현 범위도 자연스럽게 좁아집니다. 이번 변경에서 필요한 로그 이벤트와 메트릭이 무엇인지 알 수 있고, 불필요한 전역 계측 욕심을 줄일 수 있습니다.

2단계: 관측성 계약 표를 만든다

작은 표 하나로 충분합니다. 열은 신호 이름, 목적, 필수 필드, 금지 필드, 기준값, 검증 방법으로 둡니다. 신호 이름에는 invite.accept.started 같은 로그 이벤트, invite.accept.success 같은 성공 이벤트, invite.accept.failed 같은 실패 이벤트, invite_accept_latency_ms 같은 지연 시간 메트릭, invite_accept_failure_rate 같은 실패율 메트릭을 적습니다. 필수 필드에는 상관관계 ID, 사용자 유형, 결과 코드, 처리 단계, 소요 시간, 배포 버전을 넣습니다. 금지 필드에는 원문 이메일, 전화번호, 원문 토큰, 전체 요청 본문처럼 남기면 안 되는 값을 적습니다.

기준값은 처음에는 보수적으로 잡습니다. 예를 들어 실패율 1% 초과가 10분 지속되면 주의, 3% 초과가 5분 지속되면 롤백 검토, 지연 시간 p95가 기존 대비 두 배 이상이면 카나리 확대 중단처럼 씁니다. 이 숫자는 완벽하지 않아도 됩니다. 나중에 실제 트래픽을 보고 조정할 수 있습니다. 하지만 숫자가 아예 없으면 배포 중 의사결정이 감정에 의존합니다.

3단계: AI 작업 지시서에 구현과 계측을 함께 넣는다

AI에게 작업을 줄 때는 “기능 구현 후 로그도 추가”처럼 끝에 붙이지 않습니다. 기능 요구, 관측성 계약, 테스트 기대값을 한 묶음으로 줍니다. 예시는 다음과 같은 형태가 좋습니다. “초대 수락 흐름을 구현하되 시작·성공·실패 로그 이벤트를 구조화 로그로 남겨라. 모든 이벤트에는 상관관계 ID와 배포 버전을 포함하라. 원문 이메일과 원문 초대 문자열은 남기지 말고 개인정보 마스킹 규칙을 적용하라. 성공률, 실패율, 지연 시간 메트릭을 추가하고 카나리 배포 중단 기준을 문서화하라. 테스트에서는 성공, 만료, 중복 가입, 권한 없음 케이스의 로그 이벤트와 메트릭 증가를 검증하라.”

이렇게 쓰면 에이전트는 계측을 사후 장식으로 보지 않습니다. 코드 구조를 만들 때부터 요청 컨텍스트, 에러 분류, 결과 코드, 메트릭 라벨 수를 고려합니다. 특히 메트릭 라벨에는 주의가 필요합니다. 사용자 ID나 자유 텍스트 오류 메시지를 라벨로 넣으면 비용과 성능 문제가 생깁니다. 계약에서 허용 라벨을 미리 제한해야 합니다.

4단계: 테스트를 기능 테스트와 관측성 테스트로 나눈다

기능 테스트는 사용자가 원하는 결과를 확인합니다. 관측성 테스트는 운영자가 볼 증거를 확인합니다. 예를 들어 성공 케이스에서는 상태가 변경되는지와 함께 성공 로그 이벤트가 한 번 남는지, 상관관계 ID가 포함되는지, 성공 메트릭이 증가하는지 확인합니다. 실패 케이스에서는 오류 응답만 보지 말고 실패 원인이 분류되어 있는지, 재시도 가능한 실패와 사용자 입력 오류가 다른 코드로 기록되는지 확인합니다.

모든 로그 시스템을 실제로 띄워야 하는 것은 아닙니다. 테스트에서는 로거와 메트릭 수집기를 주입 가능한 작은 인터페이스로 두고, 실제 코드가 어떤 이벤트와 값을 보내는지 검증하면 됩니다. 중요한 것은 테스트가 “이 함수가 호출됐다” 수준에 머물지 않는 것입니다. 이벤트 이름, 필수 필드, 금지 필드 부재, 라벨 제한, 상관관계 ID 전달을 확인해야 합니다.

5단계: 대시보드와 알림 임계값을 배포 전 확인한다

기능이 통과해도 대시보드가 없으면 운영 준비가 끝난 것이 아닙니다. 최소 대시보드는 요청 수, 성공률, 실패율, p50·p95 지연 시간, 외부 호출 실패율, 큐 적체, 최근 배포 버전별 오류를 보여 주면 됩니다. 알림은 대시보드보다 더 좁게 둡니다. 모든 경고를 사람에게 보내지 말고 사용자 영향과 연결된 임계값만 선택합니다.

카나리 배포를 한다면 관측성 계약에 따라 확인 순서를 정합니다. 먼저 트래픽이 들어오는지 봅니다. 다음으로 성공률과 지연 시간이 기준 안에 있는지 봅니다. 그다음 특정 오류 코드가 튀지 않는지 봅니다. 마지막으로 로그 샘플을 열어 개인정보 마스킹과 상관관계 ID가 제대로 들어갔는지 확인합니다. 여기까지 통과해야 카나리 비율을 늘립니다.

6단계: 배포 후 회고에서 계약을 갱신한다

첫 계약은 틀릴 수 있습니다. 실제 장애를 겪어 보니 필요한 필드가 빠졌거나, 알림 임계값이 너무 민감하거나, 대시보드 패널이 많아도 핵심이 안 보일 수 있습니다. 그래서 배포 후 회고에서 관측성 계약을 업데이트합니다. 어떤 질문은 바로 답할 수 있었고, 어떤 질문은 로그가 부족했는지 적습니다. 다음 AI 작업 지시서에 이 교훈을 반영합니다.

이 단계가 반복되면 팀의 운영 지식이 프롬프트와 테스트에 축적됩니다. 같은 유형의 기능을 만들 때마다 더 나은 관측성 기본값을 재사용할 수 있고, AI 에이전트가 만든 코드도 운영팀의 언어에 맞춰집니다.

상황별 예시

결제 실패 처리 기능

결제 실패 처리는 관측성 계약이 특히 중요합니다. 사용자에게는 “결제가 실패했습니다”로 보이지만 내부 원인은 카드 거절, 인증 실패, 네트워크 지연, 외부 결제사 장애, 중복 요청, 금액 불일치처럼 다양합니다. 이 원인을 하나의 failed로만 남기면 장애 대응이 느려집니다. 계약에는 payment.attempt.started, payment.attempt.authorized, payment.attempt.failed, payment.webhook.received, payment.webhook.reconciled 같은 로그 이벤트를 둡니다. 필수 필드는 상관관계 ID, 결제 단계, 결과 코드, 금액 범주, 결제사 응답 분류, 배포 버전입니다. 금지 필드는 카드 번호, 원문 인증 값, 원문 사용자 식별 값입니다.

메트릭은 결제 시도 수, 승인 성공률, 결제사별 실패율, 웹훅 지연 시간, 조정 실패 건수를 봅니다. 알림 임계값은 결제사 장애와 사용자 입력 오류를 구분해야 합니다. 카드 거절이 늘었다고 바로 장애 알림을 보내면 노이즈가 됩니다. 반면 웹훅 조정 실패가 일정 시간 기준을 넘으면 매출과 권한 부여에 직접 영향을 주므로 빠르게 확인해야 합니다. 롤백 기준은 “새 배포 버전에서 결제 성공률이 이전 1시간 기준 대비 2%p 이상 하락하고 결제사 전반에서 재현될 때”처럼 구체적으로 잡습니다.

AI 요약 배치 작업

배치 작업은 사용자 화면보다 조용히 깨지기 쉽습니다. AI 요약 배치가 실패하면 당장 화면이 500을 내지 않아도 다음 날 콘텐츠가 비어 있거나 오래된 정보가 남습니다. 관측성 계약에는 batch.summary.started, batch.summary.item.completed, batch.summary.item.failed, batch.summary.finished 이벤트를 둡니다. 메트릭은 처리 대상 수, 성공 수, 실패 수, 평균 처리 시간, 큐 대기 시간, 재시도 횟수, 모델 응답 오류 분류를 포함합니다.

샘플링도 다르게 생각해야 합니다. 요청량이 많은 API에서는 모든 세부 로그를 남기면 비용이 커질 수 있지만, 하루 몇 번 도는 배치에서는 실패 항목을 더 자세히 남기는 편이 유리합니다. 단, 원문 콘텐츠나 사용자 입력 전문을 로그에 남기면 안 됩니다. 개인정보 마스킹과 길이 제한을 적용하고, 필요한 경우 내부 식별자 대신 해시 또는 짧은 참조 값만 남깁니다. 대시보드는 “마지막 성공 시각”과 “현재 데이터 신선도”를 반드시 보여 줘야 합니다. 배치 작업은 실패율보다 신선도 지표가 더 중요할 때가 많습니다.

추천·검색 기능

추천과 검색은 정답이 하나가 아니어서 관측성 계약이 더 중요합니다. “결과가 나왔다”만으로는 품질을 알 수 없습니다. 로그 이벤트에는 query.received, query.normalized, search.executed, recommendation.generated, result.clicked, zero.result 같은 흐름을 둡니다. 메트릭은 무결과 비율, 클릭률, 평균 결과 수, 지연 시간, 캐시 적중률, 특정 필터 조합의 실패율을 봅니다.

이때 라벨 폭발을 조심해야 합니다. 사용자가 입력한 검색어를 그대로 메트릭 라벨로 쓰면 라벨 수가 무한히 늘어납니다. 계약에는 허용 라벨을 언어, 필터 유형, 결과 상태, 배포 버전처럼 제한된 값으로 정의합니다. 원문 검색어는 로그에도 조심스럽게 다뤄야 합니다. 검색어에 개인정보나 민감한 문장이 들어갈 수 있기 때문입니다. 필요하다면 길이를 줄이고, 위험 패턴을 마스킹하고, 샘플링 비율을 낮춥니다.

브라우저 알림 또는 웹훅 연동

브라우저 알림과 웹훅은 외부 환경에 영향을 많이 받습니다. 사용자가 알림 권한을 거부했는지, 구독이 만료되었는지, 외부 서비스가 일시적으로 실패했는지, 내부 서명 검증이 막았는지 구분해야 합니다. 관측성 계약에는 webhook.received, webhook.verified, webhook.rejected, notification.subscription.expired, notification.sent, notification.delivery.failed 같은 이벤트를 둡니다. 메트릭은 검증 실패율, 발송 성공률, 만료 구독 정리 수, 재시도 큐 길이, 공급자별 실패율을 포함합니다.

롤백 기준도 사용자 영향과 연결합니다. 예를 들어 알림 발송 실패율이 높아져도 원인이 만료 구독 정리라면 즉시 롤백할 필요가 없을 수 있습니다. 반면 새 배포 이후 검증 실패율이 갑자기 올라가고 정상 웹훅까지 차단된다면 카나리 배포를 멈춰야 합니다. 이런 구분은 계약 없이는 배포 중에 즉흥적으로 판단하기 어렵습니다.

실수와 주의점

가장 흔한 실수는 로그를 많이 남기면 관측성이 좋아진다고 믿는 것입니다. 로그 양이 많아도 이벤트 이름이 일관되지 않고, 필수 필드가 빠지고, 상관관계 ID가 없으면 장애 때 쓸 수 없습니다. 좋은 로그 이벤트는 짧고 반복 가능하며 결과 코드가 명확합니다. “error happened”보다 “invite.accept.failed”가 낫고, “message: unknown”보다 “failure_reason: expired_invite”가 낫습니다.

두 번째 실수는 메트릭 라벨에 자유로운 값을 넣는 것입니다. 사용자 ID, 이메일, URL 전체, 검색어, 오류 메시지 전문을 라벨로 넣으면 비용과 성능이 악화되고 개인정보 위험도 커집니다. 라벨은 제한된 집합이어야 합니다. 결과 상태, 오류 분류, 기능 이름, 배포 버전, 지역 또는 플랫폼처럼 미리 정의된 값만 쓰는 편이 안전합니다.

세 번째 실수는 알림 임계값을 너무 낮게 잡는 것입니다. 모든 실패에 알림을 보내면 사람은 알림을 무시하게 됩니다. 알림은 사용자 영향, 지속 시간, 비율, 새 배포와의 상관관계를 함께 봐야 합니다. 예를 들어 실패 1건보다 실패율 3%가 5분 지속되고 카나리 버전에 집중되는 경우가 더 중요합니다. 반대로 너무 높은 임계값도 위험합니다. 작은 서비스에서는 10건의 실패가 큰 사용자 영향을 뜻할 수 있으므로 트래픽 규모에 맞춰 조정합니다.

네 번째 실수는 개인정보 마스킹을 나중으로 미루는 것입니다. 로그와 트레이스는 복제되고 검색되고 장기 보관될 수 있습니다. 한번 남긴 민감 정보는 제거가 어렵습니다. 관측성 계약에 금지 필드를 반드시 포함하고, 테스트에서 금지 필드가 이벤트에 포함되지 않는지 확인합니다. 개발자가 보기 편하다는 이유로 원문 요청을 남기는 습관은 AI 코딩 루프에서 더 위험합니다. AI는 예시를 따라 반복하기 때문입니다.

다섯 번째 실수는 대시보드를 만들고 아무도 보지 않는 것입니다. 대시보드는 배포 절차와 연결되어야 합니다. 배포 체크리스트에 어떤 패널을 몇 분 동안 볼지, 어떤 숫자를 기준으로 카나리 확대를 결정할지, 어떤 조건에서 롤백할지 적습니다. 그래야 대시보드가 장식이 아니라 의사결정 도구가 됩니다.

검증 체크리스트

관측성 계약이 제대로 적용되었는지 확인할 때는 다음 질문을 순서대로 봅니다. 기능의 주요 성공·실패 흐름마다 로그 이벤트가 있는가. 각 로그 이벤트에는 상관관계 ID, 결과 코드, 처리 단계, 배포 버전이 있는가. 구조화 로그 필드 이름이 일관되는가. 원문 개인정보나 원문 비밀 값이 남지 않도록 개인정보 마스킹이 적용되었는가. 메트릭은 요청 수, 성공률, 실패율, 지연 시간, 외부 호출 실패율, 큐 적체처럼 의사결정에 필요한 신호를 담는가. 라벨은 제한된 값만 쓰는가.

다음으로 운영 판단 기준을 봅니다. 대시보드는 사용자가 실제로 겪는 흐름을 보여 주는가. 알림 임계값은 사용자 영향과 지속 시간을 함께 반영하는가. SLO와 오류 예산이 이번 기능과 연결되어 있는가. 카나리 배포 중 어떤 숫자가 나빠지면 확대를 멈출지 적혀 있는가. 롤백 기준은 “느낌상 불안함”이 아니라 실패율, 지연 시간, 특정 오류 코드 증가, 사용자 영향 건수처럼 숫자로 되어 있는가.

테스트도 확인합니다. 성공 케이스와 실패 케이스에서 예상 로그 이벤트가 발생하는가. 상관관계 ID가 비동기 작업까지 전달되는가. 금지 필드가 이벤트에 없는가. 메트릭이 올바른 라벨로 증가하는가. 샘플링이 적용되는 경로에서는 중요한 오류가 샘플링 때문에 사라지지 않는가. 배포 스모크에서는 화면 응답뿐 아니라 대시보드 신호와 로그 샘플도 확인하는가.

마지막으로 비용과 유지보수를 봅니다. 이벤트 이름과 메트릭 이름이 팀에서 이해할 수 있는가. 너무 많은 패널을 만들지 않았는가. 알림 담당자가 명확한가. 오래된 대시보드를 제거하거나 갱신할 책임이 있는가. 관측성은 한 번 추가하면 계속 관리해야 하는 운영 자산입니다. 작은 계약으로 시작하되, 실제 장애와 배포 회고를 통해 계속 다듬어야 합니다.

다음 단계

첫 번째 다음 단계는 현재 만들고 있는 기능 하나를 골라 관측성 계약 표를 작성하는 것입니다. 이미 배포된 큰 시스템 전체를 한 번에 계측하려고 하지 마세요. 다음에 AI에게 맡길 작은 변경 하나, 예를 들어 초대 수락, 결제 실패 처리, 알림 발송, 검색 필터, 요약 배치 같은 흐름을 고릅니다. 그 기능의 성공·실패 로그 이벤트, 메트릭, 대시보드, 알림 임계값, 롤백 기준을 한 장으로 적습니다.

두 번째 단계는 AI 작업 지시서 템플릿에 관측성 항목을 넣는 것입니다. “구현 범위”, “테스트 범위” 옆에 “관측성 계약”을 추가합니다. 에이전트에게 이벤트 이름, 필수 필드, 금지 필드, 메트릭, 알림 기준을 명시하고, 테스트에서 이를 검증하라고 요구합니다. 이렇게 하면 매번 따로 기억하지 않아도 운영 증거가 기본 작업 범위에 들어갑니다.

세 번째 단계는 배포 체크리스트에 대시보드 확인 시간을 넣는 것입니다. 카나리 배포 후 5분, 15분, 30분에 어떤 패널을 볼지 정합니다. 기준을 넘으면 누가 어떤 명령으로 롤백할지 적습니다. 이 절차가 있으면 AI가 만든 코드도 사람이 책임질 수 있는 운영 루프 안으로 들어옵니다. VIBE 코딩의 목표는 AI에게 많은 코드를 쓰게 하는 것이 아니라, 사람이 검증하고 운영할 수 있는 변화를 빠르게 만드는 것입니다.