AI 상관관계 ID 디버깅 루프

AI에게 기능을 맡기면 화면은 빠르게 완성됩니다. 버튼도 보이고, API도 응답하고, 배경 작업도 돌아가는 것처럼 보입니다. 그런데 실제 사용자가 쓰기 시작하면 ‘가끔 저장이 안 된다’, ‘알림은 갔는데 화면에는 없다’, ‘결제는 성공했는데 상태가 대기 중이다’ 같은 애매한 장애가 생깁니다. 이때 로그가 흩어져 있으면 AI도 사람도 추측으로 움직입니다. 프론트엔드 콘솔, 서버 로그, 큐 워커 로그, DB 변경 이력, 외부 API 응답을 서로 다른 시간대와 다른 문장으로 뒤지다가 결국 ‘한 번 더 재현해 보자’로 끝납니다.

상관관계 ID 디버깅 루프는 이 문제를 해결하기 위한 VIBE 코딩 운영 습관입니다. 사용자의 한 행동 또는 한 자동화 실행에 correlation ID를 붙이고, 그 ID가 브라우저 이벤트, API 요청, 서버 핸들러, 백그라운드 작업, DB 변경, 알림 발송, 배포 로그까지 따라가게 만듭니다. 초보자는 이것을 ‘한 사건에 붙이는 송장 번호’로 이해하면 됩니다. 택배 송장 번호가 있으면 집화, 이동, 도착, 반송을 한 줄로 따라가듯이, correlation ID가 있으면 장애가 어느 단계에서 끊겼는지 증거로 확인할 수 있습니다.

핵심 결론

AI 상관관계 ID 디버깅 루프의 핵심은 “로그를 많이 찍자”가 아니라 “같은 사건을 끝까지 이어서 볼 수 있게 하자”입니다. 로그가 많아도 서로 연결되지 않으면 잡음입니다. 반대로 로그가 적어도 correlation ID, request ID, trace ID, user-visible action, status transition, error code, duration, retry count가 일관되면 장애 조사는 빨라집니다.

VIBE 코딩에서 이 루프는 특히 중요합니다. AI는 기능 단위를 빠르게 만들지만 운영 흐름 전체를 자동으로 설계하지는 않습니다. 화면 컴포넌트에는 console message를 넣고, API 라우트에는 다른 형식의 로그를 넣고, 워커에는 아무 로그도 넣지 않는 식의 불균형이 자주 생깁니다. 사람이 해야 할 일은 AI에게 ‘어떤 로그가 필요한가’를 자세히 지시하고, 그 로그가 실제로 같은 ID로 연결되는지 테스트하는 것입니다.

실전 목표는 간단합니다. 장애 제보 한 건을 받았을 때 10분 안에 다음 질문에 답할 수 있어야 합니다. 첫째, 사용자가 어떤 행동을 했는가. 둘째, 그 행동에 붙은 correlation ID는 무엇인가. 셋째, API는 어떤 입력을 받았고 어떤 응답을 냈는가. 넷째, DB 상태 전이는 어디까지 갔는가. 다섯째, 재시도나 큐 지연이 있었는가. 여섯째, 개인정보나 토큰을 노출하지 않고도 AI에게 줄 수 있는 재현 패킷이 있는가. 이 여섯 가지가 가능하면 디버깅은 감이 아니라 증거가 됩니다.

왜 중요한가

AI 생성 기능은 경계면에서 자주 실패한다

AI가 만든 기능의 첫 데모는 보통 happy path입니다. 버튼을 누르면 성공 메시지가 뜨고, 서버는 200을 돌려주고, 데이터는 저장됩니다. 하지만 실제 제품에서는 경계면이 더 많습니다. 사용자가 두 번 클릭할 수 있고, 모바일 네트워크가 끊길 수 있고, 백그라운드 작업이 늦게 실행될 수 있고, 외부 서비스가 부분 성공을 반환할 수 있고, 캐시가 이전 상태를 보여 줄 수 있습니다. 장애는 코드 한 줄보다 이런 경계면에서 많이 생깁니다.

경계면 장애는 로그 연결이 없으면 찾기 어렵습니다. 화면 로그에는 ‘저장 실패’가 있고 서버 로그에는 ‘timeout’이 있고 큐 로그에는 ‘retry scheduled’가 있어도, 이것이 같은 사용자의 같은 행동인지 모르면 원인 분석이 느려집니다. correlation ID는 흩어진 증거를 한 사건으로 묶습니다. 그래서 AI에게 ‘이 ID에 연결된 모든 로그를 보고 실패 단계를 판단하라’고 지시할 수 있습니다.

로그는 운영 데이터이면서 사용자 신뢰 장치다

사용자는 장애가 났을 때 기술적 설명보다 빠른 복구와 명확한 안내를 원합니다. 상관관계 ID가 있으면 운영자는 ‘저장 요청은 접수됐지만 알림 워커에서 실패했고, 데이터 자체는 보존되어 있다’처럼 영향 범위를 좁혀 말할 수 있습니다. 반대로 ID가 없으면 ‘확인 중’이라는 말만 반복하게 됩니다.

다만 로그가 많아지는 만큼 개인정보와 민감정보 보호가 중요합니다. 좋은 디버깅 루프는 원문 이메일, 전화번호, 주소, 결제 식별자, 토큰, 세션 값을 그대로 남기지 않습니다. 필요한 것은 값 자체가 아니라 사건을 추적할 수 있는 안전한 식별자와 상태입니다. AI에게 로그를 보여 줄 때도 마스킹된 재현 패킷만 전달해야 합니다.

승인 기준이 없으면 AI는 로그 작업도 과하게 만든다

AI에게 “로그 추가해 줘”라고만 말하면 모든 함수에 긴 문장을 넣거나, 사용자 입력 전체를 기록하거나, 운영자가 읽기 어려운 중복 로그를 만들 수 있습니다. 그래서 승인 기준이 필요합니다. 한 사용자 행동이 최소 한 개의 correlation ID를 만들고, 그 ID가 API와 워커까지 전달되며, 실패 시 error code와 stage가 남고, 민감정보가 노출되지 않으며, 테스트가 그 흐름을 검증해야 승인입니다.

이 기준은 작은 팀에서도 효과가 큽니다. 코드를 직접 다 이해하지 못해도 로그 계약을 확인하면 됩니다. ‘ID가 어디서 생성되는가’, ‘헤더와 작업 payload에 전달되는가’, ‘마스킹 규칙이 적용되는가’, ‘실패 시 검색 가능한가’를 보면 AI 작업의 품질을 판단할 수 있습니다.

실제 작업 순서

1단계: 추적할 사용자 행동을 하나로 좁힌다

처음부터 모든 기능에 추적 체계를 붙이려고 하면 실패합니다. 하나의 고통스러운 흐름을 고릅니다. 예를 들어 ‘질문 제출 후 자동 답변 생성’, ‘결제 완료 후 구독 권한 반영’, ‘파일 업로드 후 분석 결과 표시’, ‘관리자 승인 후 공개 페이지 반영’처럼 화면, API, 비동기 작업, DB 상태가 이어지는 흐름이 좋습니다.

선택한 흐름에 대해 사건의 시작과 끝을 정의합니다. 시작은 보통 사용자 클릭, 폼 제출, 웹훅 수신, 예약 작업 실행입니다. 끝은 사용자에게 보이는 성공 상태, 실패 안내, 재시도 대기, 롤백 완료 같은 상태입니다. 이 범위를 정하지 않으면 로그가 끝없이 늘어납니다.

2단계: correlation ID 계약을 문서가 아니라 테스트 가능한 규칙으로 쓴다

계약은 짧아도 됩니다. 예를 들어 ‘브라우저가 요청을 보낼 때 x-correlation-id가 없으면 서버가 생성한다’, ‘서버 응답에는 같은 ID를 돌려준다’, ‘큐 작업 payload에는 correlationId가 포함된다’, ‘모든 구조화 로그에는 stage, event, correlationId, status, durationMs가 있다’, ‘사용자 입력 원문과 인증 토큰은 기록하지 않는다’처럼 검증 가능한 문장으로 씁니다.

이 계약은 AI 작업 지시서의 핵심이 됩니다. AI에게 구현을 맡기기 전에 “아래 계약을 깨지 말고, 테스트가 실패하면 구현을 멈추고 이유를 보고하라”고 요구합니다. 특히 기존 로그 포맷이 있다면 그대로 유지하라고 명시합니다. 로그 이름이 매번 달라지면 검색과 대시보드가 깨집니다.

3단계: 구조화 로그 필드를 고정한다

문장형 로그만 남기면 AI가 읽기에는 좋아 보여도 운영 검색에는 약합니다. 최소 필드는 구조화해야 합니다. 추천 필드는 correlationId, requestId, traceId, userAction, stage, event, status, errorCode, durationMs, retryCount, resourceType, safeResourceId입니다. 여기서 safeResourceId는 공개 가능한 내부 식별자 또는 해시된 값이어야 합니다.

stage는 흐름의 어느 구간인지 나타냅니다. browser_submit, api_validate, api_write, queue_enqueue, worker_execute, db_transition, notification_send, cache_revalidate 같은 값이 있을 수 있습니다. event는 그 단계에서 일어난 일입니다. started, succeeded, failed, retried, skipped, rolled_back처럼 제한된 단어를 쓰면 검색과 집계가 쉬워집니다.

4단계: 프론트엔드, API, 워커 전달 경로를 연결한다

브라우저에서 이미 correlation ID를 만들 수도 있고 서버에서 만들 수도 있습니다. 중요한 것은 한 번 정해진 ID가 다음 단계로 전달되는 것입니다. API 요청 헤더, 서버 내부 context, 큐 payload, 외부 API metadata, 알림 작업 payload에 같은 ID가 들어가야 합니다.

AI에게는 전달 경로를 그림처럼 설명합니다. “폼 제출에서 ID 생성 또는 수신 → POST 요청 헤더 → 서버 검증 로그 → DB 상태 전이 로그 → 큐 작업 payload → 워커 실행 로그 → 사용자 알림 로그 → 최종 응답 또는 상태 조회 로그”처럼 단계별로 써 줍니다. 이 지시가 없으면 AI는 API까지만 로그를 붙이고 워커를 놓치는 경우가 많습니다.

5단계: 실패 모드별 로그를 먼저 만든다

성공 로그보다 실패 로그가 더 중요합니다. 입력 검증 실패, 권한 실패, 중복 제출, DB 쓰기 실패, 큐 enqueue 실패, 워커 timeout, 외부 API rate limit, 캐시 갱신 실패, 부분 성공, 롤백 실행 같은 실패 모드를 미리 나열합니다. 각 실패는 errorCode와 recoveryHint를 가져야 합니다. recoveryHint는 public message가 아니라 운영자가 다음 행동을 판단하기 위한 안전한 힌트입니다.

예를 들어 결제 후 권한 반영 흐름이라면 payment_webhook_received, subscription_write_failed, entitlement_not_granted, retry_scheduled, manual_review_required 같은 event가 필요합니다. 이 이름이 안정적이면 AI에게 특정 event 주변 로그만 분석하게 할 수 있습니다.

6단계: 재현 패킷을 만든다

장애가 생겼을 때 AI에게 전체 로그를 던지면 위험하고 비효율적입니다. 대신 재현 패킷을 만듭니다. 재현 패킷에는 correlation ID, 발생 시각 범위, 사용자가 한 행동의 안전한 요약, 관련 stage 목록, 상태 전이, error code, retry count, 배포 버전 또는 commit marker, 브라우저와 서버의 핵심 로그 일부, 민감정보 마스킹 여부가 들어갑니다.

이 패킷은 사람과 AI가 함께 보는 조사 단위입니다. 원문 토큰, 쿠키, 인증 헤더, 개인 연락처, DB 연결 정보는 제외합니다. 사용자의 원문 입력이 필요할 때도 전체를 넣지 말고 길이, 언어, 파일 크기, 확장자, 유효성 결과처럼 원인 분석에 필요한 안전한 속성만 넣습니다.

7단계: 승인 전 검색 실험을 한다

구현이 끝났다고 바로 승인하지 않습니다. 테스트 환경에서 의도적으로 성공 1건과 실패 3건을 발생시킵니다. 그런 다음 correlation ID 하나로 모든 단계 로그를 찾을 수 있는지 확인합니다. 실패 3건은 검증 실패, 워커 실패, 외부 서비스 실패처럼 서로 다른 구간을 고르는 것이 좋습니다.

승인 조건은 명확해야 합니다. 한 ID로 검색했을 때 사건의 시작, API 검증, DB 변경, 큐 등록, 워커 실행, 최종 상태가 시간순으로 보이면 통과입니다. 실패 원인이 어느 stage에서 발생했는지 10분 안에 설명할 수 없으면 통과가 아닙니다.

상황별 예시

예시 1: 질문 제출 후 답변 생성이 가끔 멈춘다

사용자가 질문을 제출하면 화면은 ‘접수됨’을 보여 주지만 공개 답변이 늦게 나타나는 상황을 생각해 봅니다. correlation ID가 없으면 운영자는 제출 API, 답변 워커, 공개 페이지 캐시를 따로 확인해야 합니다. ID가 있으면 qna_submit 흐름에서 api_write는 성공했지만 queue_enqueue가 실패했는지, worker_execute가 timeout인지, answer_publish는 성공했지만 cache_revalidate가 실패했는지 바로 나눌 수 있습니다.

AI에게 줄 재현 패킷에는 질문 원문 전체가 필요하지 않습니다. safeQuestionId, submittedAt, contentLength, language, moderationStatus, queueStatus, workerAttemptCount, publicVisible 상태만 있어도 충분한 경우가 많습니다. 이렇게 하면 개인정보와 민감한 문장을 줄이면서도 원인 분석이 가능합니다.

예시 2: 배포 후 일부 사용자만 저장 실패를 본다

배포 직후 일부 모바일 사용자가 저장 실패를 본다면 브라우저, API, DB 로그가 모두 필요합니다. correlation ID가 응답 헤더로 내려오면 고객 문의 화면에도 ‘문의 코드’로 표시할 수 있습니다. 사용자가 그 코드를 알려 주면 운영자는 특정 사건만 추적합니다.

이 경우 stage는 browser_submit, api_validate, api_write, response_returned로 시작하고, 모바일 환경 정보는 userAgent 전체가 아니라 deviceClass, browserFamily, networkHint처럼 안전하게 요약합니다. 실패가 특정 브라우저에서만 발생하면 AI에게 해당 조건의 재현 테스트를 추가하게 합니다.

예시 3: 웹훅은 성공했는데 내부 상태가 바뀌지 않는다

외부 서비스 웹훅은 운영자가 직접 재현하기 어렵습니다. 그래서 수신 시점에 providerEventId와 correlation ID를 매핑해야 합니다. providerEventId 자체가 민감하거나 재사용 위험이 있으면 해시 또는 안전한 내부 ID로 저장합니다.

로그는 webhook_received, signature_verified, dedupe_checked, state_transition_started, state_transition_succeeded 또는 failed를 남깁니다. 중복 웹훅이면 duplicated_skipped를 명시합니다. 그러면 AI가 ‘웹훅이 안 왔다’와 ‘왔지만 중복 처리로 건너뛰었다’와 ‘상태 전이에서 실패했다’를 구분할 수 있습니다.

예시 4: 백그라운드 작업이 재시도하다가 비용을 폭발시킨다

AI 기능은 외부 모델 호출이나 이미지 처리처럼 비용이 드는 작업을 많이 만듭니다. 워커가 실패할 때마다 같은 입력을 무제한 재시도하면 비용이 커집니다. correlation ID와 retryCount, costEstimate, stopReason을 남기면 비용 장애도 디버깅할 수 있습니다.

승인 기준에는 retryCount가 일정 값을 넘으면 stopped 상태로 전환하고 운영자 검토가 필요하다는 규칙을 넣습니다. AI에게는 “재시도는 최대 3회, 같은 correlation ID의 누적 비용 추정치가 임계값을 넘으면 더 호출하지 말고 manual_review_required 로그를 남겨라”라고 지시합니다.

실수와 주의점

민감정보를 로그 품질로 착각하지 않는다

가장 위험한 실수는 원인을 찾기 쉽게 하려고 원문 입력, 인증 헤더, 쿠키, 토큰, 결제 식별자, 이메일, 전화번호를 그대로 남기는 것입니다. 이것은 디버깅이 아니라 사고의 씨앗입니다. 좋은 로그는 충분히 설명적이지만 복원 불가능한 형태여야 합니다. 필요하면 해시, 길이, 타입, 상태, 범위, 검증 결과를 남깁니다.

AI에게도 명확히 금지해야 합니다. “사용자 원문과 secret은 로그에 남기지 말고, 마스킹 helper를 통과한 safe fields만 기록하라”는 문장을 작업 지시에 넣습니다. 리뷰 때는 로그 추가 코드만 따로 보며 민감정보 필드가 없는지 확인합니다.

ID 이름을 여러 개로 흩뜨리지 않는다

requestId, traceId, correlationId가 모두 필요한 시스템도 있지만, 작은 제품에서는 이름이 너무 많으면 오히려 혼란스럽습니다. 최소한 사용자 행동을 잇는 대표 ID 하나를 정하고, 나머지는 외부 관측 도구와 연결할 때만 사용합니다.

AI가 파일마다 다른 이름을 만들면 검색성이 무너집니다. 어떤 파일은 correlation_id, 어떤 파일은 requestID, 어떤 파일은 trace라고 쓰면 같은 사건을 찾기 어렵습니다. 계약에 표준 필드명을 적고 테스트에서 필드 존재를 확인합니다.

성공 로그만 보고 승인하지 않는다

성공 흐름은 대체로 잘 보입니다. 문제는 실패 흐름입니다. 검증 실패, 권한 실패, 외부 API 실패, DB timeout, 재시도 중단, 롤백 실행 같은 상황에서 로그가 남지 않으면 실제 장애 때 쓸 수 없습니다. 승인 전에는 의도적으로 실패를 만들어야 합니다.

특히 AI가 만든 예외 처리 코드는 catch에서 모든 오류를 같은 메시지로 감싸는 경우가 있습니다. 이렇게 되면 errorCode와 stage가 사라집니다. catch 블록은 원인을 숨기지 말고 안전하게 분류해야 합니다.

로그가 제품 동작을 느리게 만들지 않게 한다

모든 요청에 과한 동기 로그 전송을 넣으면 성능이 나빠집니다. 사용자 응답 경로에서는 최소 구조화 로그만 남기고, 무거운 분석은 비동기 또는 샘플링으로 보내는 편이 좋습니다. 다만 실패 로그와 상태 전이 로그는 샘플링 없이 남기는 것이 안전합니다.

운영 기준도 필요합니다. 로그 보존 기간, 검색 인덱스 비용, 개인정보 마스킹 범위, 장애 조사 후 삭제할 임시 패킷 위치를 정합니다. 좋은 디버깅은 많이 저장하는 것이 아니라 필요한 증거를 안전하게 오래 볼 수 있게 하는 것입니다.

AI에게 줄 지시 예시

구현 지시 예시

다음 지시문은 그대로 복사해 쓰기보다 프로젝트 용어에 맞게 조정합니다.

질문 제출 후 자동 답변 생성 흐름에 correlation ID 기반 디버깅 루프를 추가하라. 한 사용자 제출마다 correlationId를 생성하거나 요청 헤더에서 수신하고, API 응답 헤더와 본문 요약에 같은 ID를 포함하라. API 검증, DB 저장, 큐 등록, 워커 실행, 답변 저장, 공개 상태 전환, 캐시 갱신 단계마다 구조화 로그를 남겨라. 모든 로그에는 correlationId, stage, event, status, durationMs, retryCount, safeResourceId를 포함하라. 사용자 질문 원문, 인증 헤더, 쿠키, 토큰, DB 연결 정보, 개인 연락처는 기록하지 말라. 실패 모드는 validation_failed, queue_enqueue_failed, worker_timeout, model_call_failed, publish_failed, revalidate_failed로 분류하라. 테스트는 성공 1건과 실패 3건에서 같은 correlationId로 사건을 추적할 수 있음을 검증하라.

이 지시에서 중요한 점은 구현 범위와 금지 범위가 함께 있다는 것입니다. AI에게 “로그를 추가하라”가 아니라 “어떤 흐름에, 어떤 필드로, 어떤 실패 모드를, 무엇은 기록하지 않고, 어떤 테스트로 승인할지”를 줍니다.

조사 지시 예시

장애가 이미 발생했을 때는 다른 지시가 필요합니다.

correlationId가 abc123이라고 가정하고, 제공된 마스킹 로그 패킷만 사용해 사건 타임라인을 작성하라. 각 stage의 started, succeeded, failed, retried 이벤트를 시간순으로 정리하고, 최초 실패 stage와 사용자 영향 범위를 추정하라. 로그에 없는 사실은 추측하지 말고 ‘증거 없음’으로 표시하라. 원인 후보를 최대 3개로 제한하고, 각 후보마다 확인할 추가 로그 또는 테스트를 제안하라. 롤백이 필요한 조건과 계속 조사해도 되는 조건을 분리하라.

조사 지시는 AI의 환각을 줄입니다. 로그에 없는 사실을 만들지 말라고 말하고, 후보 수를 제한하고, 추가 증거를 요구하게 만들면 디버깅이 훨씬 안전해집니다.

검증 체크리스트

기능 승인 전 체크

• 한 사용자 행동에 하나의 correlation ID가 생성되거나 수신되는가.
• API 응답, 서버 로그, 큐 payload, 워커 로그, 최종 상태 로그가 같은 ID를 공유하는가.
• stage와 event가 제한된 이름으로 기록되는가.
• 실패 모드별 errorCode와 retryCount가 남는가.
• 사용자 원문, 인증 토큰, 쿠키, DB 연결 정보, 외부 서비스 인증값이 로그에 남지 않는가.
• 성공 1건과 실패 3건을 테스트로 재현했는가.
• 재현 패킷이 마스킹되어 AI에게 안전하게 전달 가능한가.
• 검색 실험에서 10분 안에 최초 실패 stage를 설명할 수 있는가.

운영 중 체크

• 최근 장애 제보에 문의 코드 또는 correlation ID가 붙는가.
• 같은 ID로 검색했을 때 타임라인이 시간순으로 정렬되는가.
• 중복 제출, timeout, rate limit, cache failure가 서로 다른 event로 구분되는가.
• retry count와 stopReason이 비용 폭주를 막는가.
• 로그 볼륨이 급증했을 때 샘플링과 보존 정책이 적용되는가.
• 새 AI 작업이 기존 로그 필드명을 바꾸지 않았는가.

중단/승인 기준

승인 기준은 ‘기능이 동작한다’보다 좁고 강해야 합니다. 다음 조건을 만족하면 승인할 수 있습니다. 첫째, 대표 흐름에서 correlation ID가 끝까지 전달됩니다. 둘째, 실패 모드가 stage와 errorCode로 분리됩니다. 셋째, 민감정보가 로그와 재현 패킷에 없습니다. 넷째, 테스트와 수동 검색 실험으로 한 사건의 타임라인을 재구성할 수 있습니다. 다섯째, 장애가 재발했을 때 롤백 기준과 계속 조사 기준이 숫자 또는 상태로 정해져 있습니다.

중단 기준도 분명해야 합니다. 로그에 인증 헤더, 쿠키, 토큰, 개인 연락처, 결제 원문 같은 민감정보가 발견되면 즉시 중단합니다. correlation ID가 API까지만 있고 워커나 DB 상태 전이에 전달되지 않으면 승인하지 않습니다. 실패 로그가 모두 unknown_error로 합쳐져 있으면 승인하지 않습니다. 재시도가 무제한이거나 비용 임계값이 없으면 승인하지 않습니다. 검색 실험에서 최초 실패 stage를 10분 안에 설명하지 못하면 다시 설계합니다.

롤백 기준은 제품 상황에 따라 다르지만 예시는 이렇습니다. 새 로그/추적 코드 배포 후 API 오류율이 1%포인트 이상 증가하거나, p95 응답 시간이 20% 이상 늘거나, 로그 전송 실패가 사용자 응답 실패로 전파되거나, 민감정보 로그 가능성이 발견되면 즉시 비활성화 또는 롤백합니다. 반대로 로그 누락만 있고 사용자 기능은 안전하다면 기능을 유지하되 추적 보강 작업을 우선순위로 올릴 수 있습니다.

다음 단계

첫 적용은 가장 자주 문제 되는 하나의 흐름으로 시작하세요. 기능을 새로 만들 때보다 이미 운영 중인 흐름에 붙이는 것이 효과를 빠르게 보여 줍니다. 지난 한 달 동안 ‘원인 확인이 오래 걸렸던’ 장애나 문의를 하나 고르고, 그 흐름에 correlation ID 계약, 구조화 로그, 실패 모드, 재현 패킷, 승인 기준을 추가합니다.

그 다음에는 AI 작업 템플릿에 이 루프를 넣습니다. “새 기능을 만들 때는 correlation ID 전달 경로와 실패 로그를 함께 설계하라”는 문장을 기본 지시로 둡니다. 모든 기능에 거대한 관측 플랫폼을 붙일 필요는 없습니다. 하지만 사용자 행동이 API, DB, 큐, 외부 서비스, 캐시를 지나간다면 최소한 한 사건을 끝까지 추적할 수 있어야 합니다. 그것이 AI로 빠르게 만든 제품을 실제 운영 가능한 제품으로 바꾸는 기준입니다.