AI가 만든 기능은 빠르게 완성되지만, 모든 사용자에게 한 번에 공개해도 되는지는 별개의 문제입니다. 로그인 방식 변경, 결제 버튼 개선, 추천 알고리즘, Q&A 자동 응답, 새 온보딩 화면처럼 사용자 흐름을 바꾸는 작업은 코드가 통과했다고 곧바로 안전해지지 않습니다. 특히 AI가 여러 파일을 동시에 수정한 기능은 예상하지 못한 경계 조건이 숨어 있을 수 있습니다. 그래서 VIBE 코딩에서 중요한 습관은 '완성 후 배포'가 아니라 '기능 플래그로 작게 열고 관측하면서 넓히기'입니다.

이 글의 문제는 하나입니다. 'AI가 만든 새 기능을 어떻게 기능 플래그, 점진 배포, 킬 스위치, 관측 지표, 롤백 기준으로 안전하게 공개할 것인가'입니다. 초보자에게는 기능 플래그를 '전등 스위치처럼 기능을 켜고 끄는 장치'라고 이해하면 됩니다. 실무자에게는 릴리스와 배포를 분리하고, AI 작업 범위를 작은 검증 단위로 제한하며, 문제가 생기면 코드 되돌리기 전에 노출을 즉시 줄이는 운영 패턴입니다.

핵심 결론

AI 기능 롤아웃의 핵심은 새 기능을 코드 병합 단위가 아니라 사용자 노출 단위로 관리하는 것입니다. 코드는 이미 배포되어 있어도 기능 플래그가 꺼져 있으면 일반 사용자는 보지 못합니다. 일부 내부 사용자, 1% 카나리, 특정 대상 세그먼트, 전체 사용자 순서로 노출을 넓히면 AI가 놓친 오류를 작은 범위에서 발견할 수 있습니다.

가장 실용적인 루프는 다음과 같습니다.

1. 기능을 만들기 전에 플래그 이름, 기본값, 대상 세그먼트, 킬 스위치 소유자를 정합니다.
2. AI에게 기능 구현과 플래그 경계 처리를 함께 맡기되, 플래그가 꺼진 기존 경로는 절대 바꾸지 말라고 제한합니다.
3. 테스트는 플래그 꺼짐, 내부 사용자 켜짐, 일반 사용자 켜짐, 권한 없는 접근, 오류 발생 시 기본 경로 복귀를 모두 검증합니다.
4. 배포 후에는 내부 사용자에게만 켜고 라이브 스모크를 실행합니다.
5. 오류율, 전환율, 응답 시간, 주요 이벤트 누락, 고객 문의 같은 관측 지표를 기준으로 카나리 비율을 올립니다.
6. 숫자로 정한 롤백 기준을 넘으면 코드 수정 전에 킬 스위치로 노출을 낮춥니다.
7. 안정화 후에는 플래그를 정리할 날짜와 제거 테스트를 남깁니다.

이 방식은 AI를 믿지 않는 절차가 아니라 AI의 장점을 안전하게 쓰는 절차입니다. AI는 구현과 테스트 초안을 빠르게 만들고, 사람은 노출 범위와 위험 기준을 결정합니다. 기능 플래그가 있으면 '배포했다'와 '사용자에게 공개했다'를 분리할 수 있고, 장애 대응도 코드 롤백보다 빠른 스위치 조작으로 시작할 수 있습니다.

왜 중요한가

AI가 만든 기능은 경계 조건에서 흔들린다

AI는 요구사항이 명확할수록 빠르게 기능을 만듭니다. 하지만 실제 서비스에서는 요구사항 밖의 사용자가 많습니다. 로그인하지 않은 사용자, 느린 네트워크, 오래된 브라우저, 권한이 애매한 계정, 이전 버전 쿠키, 부분적으로 실패한 API 응답, 모바일 화면, 이미 실험 중인 다른 기능과의 조합이 모두 경계 조건입니다. AI는 이런 조건을 전부 떠올리지 못할 수 있습니다.

기능 플래그 없이 전체 공개하면 작은 경계 조건도 전체 장애가 됩니다. 반대로 플래그가 있으면 문제 범위가 제한됩니다. 내부 사용자 5명에게만 켜진 상태에서 오류가 나면 운영자는 조용히 끄고 원인을 찾을 수 있습니다. 1% 카나리에서 전환율이 갑자기 떨어지면 전체 매출을 잃기 전에 멈출 수 있습니다.

배포와 릴리스는 다르다

초보 개발자는 배포를 '사용자가 새 기능을 보는 순간'으로 생각하기 쉽습니다. 운영 관점에서는 다릅니다. 배포는 코드가 서버에 올라가는 일이고, 릴리스는 사용자가 기능을 경험하는 일입니다. 기능 플래그는 이 둘을 분리합니다. 코드를 미리 배포해도 플래그를 꺼두면 릴리스는 아직 일어나지 않습니다.

이 분리가 중요한 이유는 복구 속도입니다. 배포 롤백은 빌드, 배포 큐, 캐시, 마이그레이션, 의존 서비스 상태에 영향을 받습니다. 반면 잘 설계된 킬 스위치는 보통 몇 초에서 몇 분 안에 사용자 노출을 줄입니다. 특히 AI가 만든 변경이 여러 화면에 걸쳐 있을 때는 코드 롤백보다 기능 노출 차단이 먼저입니다.

AI에게 맡길 수 있는 것과 사람이 결정해야 하는 것이 다르다

AI에게 맡기기 좋은 일은 플래그 분기 구현, 테스트 케이스 초안, 관측 이벤트 이름 정리, 릴리스 노트 초안, 실패 시 복귀 경로 점검입니다. 사람이 결정해야 하는 일은 누가 먼저 볼지, 어떤 지표가 나빠지면 멈출지, 고객 영향이 얼마나 큰지, 플래그를 언제 제거할지입니다.

좋은 요청은 이렇게 생겼습니다. '새 추천 카드를 구현해줘'가 아니라 '추천 카드를 featureFlag.newRecommendationCard가 켜진 사용자에게만 노출하고, 꺼진 사용자는 기존 카드 흐름을 그대로 유지해줘. 내부 사용자, 5% 카나리, 전체 공개 단계별 검증 체크리스트와 오류율 2배 상승 시 킬 스위치 기준을 테스트에 반영해줘'입니다. 이 정도로 AI 작업 범위를 지정하면 AI가 디자인을 마음대로 넓히거나 기존 흐름을 깨뜨릴 가능성이 줄어듭니다.

실제 작업 순서

1단계: 플래그 계약을 먼저 쓴다

구현 전에 짧은 플래그 계약을 만드세요. 계약에는 이름, 기본값, 노출 대상, 소유자, 관측 지표, 롤백 기준, 제거 예정일이 들어갑니다. 이름은 기능 의미가 분명해야 합니다. 예를 들어 newCheckoutFlow, aiAnswerDraftReview, compactOnboarding 같은 식입니다. 단, 실제 코드에서는 팀의 명명 규칙을 따르되 공개 콘텐츠나 로그에 민감한 내부 프로젝트명을 넣지 않는 것이 좋습니다.

계약의 핵심 질문은 여섯 가지입니다.

• 기본값은 꺼짐인가, 켜짐인가? 위험이 있는 기능은 꺼짐이 기본입니다.
• 누가 먼저 보는가? 내부 사용자, 베타 그룹, 지역, 요금제, 무작위 카나리 중 하나를 고릅니다.
• 어떤 이벤트로 성공을 판단하는가? 클릭, 완료, 응답 시간, 오류율, 문의량처럼 측정 가능한 지표가 필요합니다.
• 어떤 숫자에서 멈추는가? 예를 들어 오류율이 기존 대비 2배, 결제 완료율 3% 이상 하락, p95 응답 시간이 1.5초 초과처럼 정합니다.
• 킬 스위치를 누르면 어떤 경로로 복귀하는가? 기존 화면, 기존 API, 읽기 전용 모드 중 하나가 명확해야 합니다.
• 언제 플래그를 제거하는가? 영구 플래그가 쌓이면 코드가 복잡해집니다.

이 계약을 AI에게 먼저 주면 구현의 경계가 생깁니다. AI는 기능을 만드는 동시에 꺼짐 상태를 지키고, 테스트와 문서도 플래그 계약에 맞춰 작성할 수 있습니다.

2단계: 꺼짐 경로를 회귀 테스트로 잠근다

기능 플래그의 첫 테스트는 새 기능이 켜졌을 때가 아니라 꺼졌을 때입니다. 플래그가 꺼진 상태에서 기존 사용자 흐름이 변하지 않아야 합니다. 이 테스트가 없으면 AI는 새 기능을 만들면서 기존 조건문, 기본 UI, API 파라미터를 살짝 바꾸고도 통과할 수 있습니다.

최소 테스트 묶음은 다음과 같습니다.

• 플래그 꺼짐: 기존 화면, 기존 문구, 기존 API 호출 또는 기존 결과가 유지된다.
• 플래그 켜짐: 새 기능이 의도한 대상에게만 보인다.
• 권한 없음: 대상 세그먼트가 아닌 사용자는 새 기능을 볼 수 없다.
• 실패 복귀: 새 기능 API가 실패하면 기존 경로 또는 안전한 안내로 복귀한다.
• 관측 이벤트: 켜짐과 꺼짐을 구분할 수 있는 이벤트가 기록된다.

여기서 중요한 점은 테스트가 구현 디테일보다 사용자 결과를 검증해야 한다는 것입니다. 특정 컴포넌트 이름이 호출됐는지보다 사용자가 무엇을 보고 어떤 행동을 할 수 있는지를 확인하세요. AI에게도 '분기 함수가 호출되는지 말고, 플래그 상태별 사용자 결과를 테스트해줘'라고 요청하는 편이 좋습니다.

3단계: 배포 전에 킬 스위치 경로를 직접 연습한다

킬 스위치는 실제로 눌러본 적이 없으면 장애 때 믿을 수 없습니다. 로컬이나 프리뷰 환경에서 플래그를 켰다가 끄는 연습을 하세요. 끄는 순간 새 UI가 사라지는지, 진행 중인 사용자는 안전하게 안내되는지, 캐시 때문에 계속 보이지는 않는지, 서버와 클라이언트 상태가 어긋나지 않는지 확인합니다.

AI에게는 '킬 스위치를 끈 뒤 기대되는 사용자 결과를 표로 만들고, 놓친 캐시·상태·세션 조건을 찾아줘'라고 요청할 수 있습니다. 단, 최종 판단은 사람이 합니다. AI가 제안한 킬 스위치가 실제 운영 도구에서 몇 초 안에 반영되는지, 누가 권한을 갖는지, 야간에도 조작 가능한지는 팀 운영 환경에 따라 다릅니다.

4단계: 내부 공개와 라이브 스모크를 분리한다

배포가 성공하면 바로 카나리로 가지 말고 내부 사용자에게만 켭니다. 내부 공개의 목적은 실제 서버, 실제 브라우저, 실제 네트워크에서 화면이 뜨는지 확인하는 것입니다. 이때 라이브 스모크는 짧아야 합니다. 핵심 경로 접속, 기능 진입, 성공 동작, 실패 복귀, 브라우저 콘솔 오류, 네트워크 오류, 공개 금지어 노출 여부 정도면 충분합니다.

중요한 것은 라이브 스모크를 '통과하면 전체 공개'로 해석하지 않는 것입니다. 내부 스모크는 기능이 기본적으로 작동한다는 신호이고, 카나리 관측은 실제 사용자에게 가치와 안정성이 있는지 보는 단계입니다.

5단계: 카나리는 숫자 기준으로만 넓힌다

카나리 확대는 기분으로 하지 않습니다. '별문제 없어 보이니 100%'가 아니라, 미리 정한 지표가 기준 안에 있을 때만 1%, 5%, 25%, 50%, 100%처럼 넓힙니다. 이때 기존 흐름을 보는 대조군과 새 기능을 보는 실험군을 구분하면 전환율과 오류율 변화가 기능 때문인지 더 명확하게 판단할 수 있습니다. 지표는 기능 성격에 따라 다릅니다.

• UI 개선: 클릭률, 다음 단계 도달률, 콘솔 오류, 이탈률
• 결제 흐름: 결제 시작률, 완료율, 실패율, 결제 API 오류
• AI 응답 기능: 응답 성공률, 평균 대기 시간, 재시도율, 사용자 신고율
• 검색·추천: 결과 클릭률, 무결과 비율, 응답 시간, 품질 피드백
• 관리자 또는 운영 기능: 작업 성공률, 잘못된 상태 변경, 감사 로그 누락

AI에게는 카나리 단계별 체크리스트를 만들게 할 수 있습니다. 하지만 AI가 임의로 '안정적입니다'라고 결론 내리게 하지 마세요. 안정 여부는 숫자와 사용자 영향으로 판단해야 합니다.

6단계: 안정화 후 플래그 부채를 제거한다

기능 플래그는 안전장치지만 오래 방치하면 부채가 됩니다. 꺼짐 경로와 켜짐 경로가 영원히 공존하면 테스트가 늘어나고, 새 개발자가 어떤 경로가 진짜인지 헷갈립니다. 전체 공개 후 충분한 기간 동안 안정적이면 제거 작업을 별도 이슈로 잡으세요. 제거할 때도 AI에게 '항상 켜진 상태를 기본 경로로 만들고, 꺼짐 분기와 죽은 테스트를 정리하되 사용자 결과는 유지해줘'라고 요청합니다.

플래그 제거에도 검증이 필요합니다. 제거 전후로 핵심 테스트가 같아야 하고, 공개 페이지의 문구나 이벤트 이름이 갑자기 바뀌지 않아야 합니다. 기능 플래그는 만드는 것보다 정리하는 것이 더 중요할 때가 많습니다.

상황별 예시

예시 1: AI가 만든 새 온보딩 화면

상황은 이렇습니다. AI에게 초보자를 위한 3단계 온보딩 화면을 만들게 했습니다. 기존에는 가입 직후 대시보드로 바로 이동했습니다. 새 화면은 예쁘지만, 전체 공개하면 가입 완료율이 떨어질 수 있습니다.

이때 플래그 계약은 간단합니다. 기본값은 꺼짐, 내부 사용자와 신규 가입자의 5%에게만 켜짐, 성공 지표는 온보딩 완료율과 다음 화면 도달률, 위험 지표는 가입 후 이탈률과 브라우저 콘솔 오류입니다. 롤백 기준은 신규 가입 완료 후 대시보드 도달률이 기존 대비 3% 이상 하락하거나 치명적 콘솔 오류가 반복될 때입니다.

AI 작업 범위는 다음처럼 제한합니다. 새 온보딩 컴포넌트를 만들되 플래그 꺼짐 상태에서는 기존 대시보드 이동을 그대로 유지합니다. 온보딩 중 API 실패가 나면 사용자를 막지 말고 기존 대시보드로 이동할 수 있게 합니다. 테스트는 플래그 꺼짐, 내부 사용자 켜짐, 일반 사용자 꺼짐, 온보딩 완료, 실패 복귀를 검증합니다.

이렇게 하면 AI가 온보딩을 만들면서 가입 흐름 전체를 재설계하는 일을 막을 수 있습니다. 새 기능이 실패해도 킬 스위치로 기존 흐름으로 돌아갈 수 있습니다.

예시 2: AI 답변 초안 기능

Q&A 서비스에 AI 답변 초안 기능을 넣는다고 가정해봅시다. 위험은 답변 품질, 대기 시간, 부적절한 공개, 운영자 검수 누락입니다. 전체 공개보다 운영자 계정에만 먼저 켜는 것이 안전합니다.

플래그는 aiDraftAnswerReview처럼 기능 목적이 분명해야 합니다. 대상 세그먼트는 운영자 또는 내부 검수자입니다. 관측 지표는 초안 생성 성공률, 평균 생성 시간, 검수 후 게시 비율, 사용자가 보는 최종 답변 오류 신고율입니다. 롤백 기준은 생성 실패율 10% 초과, 평균 대기 시간 15초 초과, 검수 없이 공개되는 흐름 발견 같은 숫자와 사건 기준으로 정합니다.

AI에게 구현을 맡길 때는 '초안은 검수 전까지 공개 페이지에 노출하지 않는다'는 제약을 강하게 넣어야 합니다. 기능 플래그가 켜져도 공개 사용자에게 보이는 결과는 검수 완료 전까지 동일해야 합니다. 테스트도 공개 페이지에 초안 문구가 나오지 않는지 확인해야 합니다.

예시 3: 결제 버튼 문구와 순서 변경

결제 흐름은 작은 UI 변경도 매출에 직접 영향을 줍니다. AI가 버튼 문구와 가격 카드 순서를 개선했다면, 성공 지표는 클릭률보다 결제 완료율입니다. 클릭은 늘었는데 완료율이 떨어질 수 있기 때문입니다.

이 경우 카나리는 낮은 비율로 시작합니다. 1%에서 오류율과 완료율을 보고, 기준 안에 있으면 5%, 25%로 올립니다. 롤백 기준은 결제 API 오류율 상승, 완료율 하락, 특정 브라우저에서 결제 버튼 비활성화 같은 구체적 조건입니다. AI에게는 버튼 문구 테스트뿐 아니라 결제 시작부터 완료까지의 라이브 스모크 목록을 만들게 하세요.

실수와 주의점

첫 번째 실수는 기능 플래그를 단순 조건문으로만 보는 것입니다. 조건문은 시작일 뿐입니다. 운영 가능한 플래그에는 대상 세그먼트, 관측 지표, 킬 스위치, 제거 계획이 필요합니다. 이 네 가지가 없으면 안전장치가 아니라 복잡한 if문만 늘어난 것입니다.

두 번째 실수는 플래그 기본값을 켜짐으로 두는 것입니다. 위험이 낮은 시각적 변경은 켜짐 기본값도 가능하지만, 사용자 데이터·결제·권한·AI 응답·온보딩에 영향을 주는 기능은 꺼짐 기본값이 안전합니다. AI에게도 기본값을 명확히 지정해야 합니다. 그렇지 않으면 AI가 개발 편의를 위해 켜짐 상태를 기본으로 둘 수 있습니다.

세 번째 실수는 킬 스위치가 실제 장애를 막는다고 착각하는 것입니다. 킬 스위치가 클라이언트 캐시에 오래 남거나, 서버 분기와 클라이언트 분기가 다르거나, 이미 시작된 작업을 멈추지 못하면 복구가 늦어집니다. 스위치를 끈 뒤 사용자 결과가 어떻게 바뀌는지 반드시 연습해야 합니다.

네 번째 실수는 카나리 대상을 너무 작게 잡고 성공을 선언하는 것입니다. 내부 사용자 3명이 문제를 못 봤다고 일반 사용자에게 안전한 것은 아닙니다. 내부 스모크는 기술적 작동 확인이고, 카나리는 실제 행동 지표 확인입니다. 둘을 섞으면 잘못된 결론이 나옵니다.

다섯 번째 실수는 지표를 너무 많이 보는 것입니다. 대시보드에 숫자가 많으면 좋아 보이지만, 롤아웃 결정에 쓰는 지표는 3~5개면 충분합니다. 오류율, 핵심 전환율, 응답 시간, 사용자 신고 또는 문의, 특정 이벤트 누락 정도로 시작하세요. 중요한 것은 숫자 자체보다 미리 정한 멈춤 기준입니다.

여섯 번째 실수는 플래그를 영구 설정처럼 방치하는 것입니다. 오래된 플래그는 테스트 조합을 폭발시키고 AI에게도 혼란을 줍니다. AI가 코드를 읽을 때 어떤 분기가 현재 경로인지 모르기 때문입니다. 전체 공개 후 안정화 기간이 지나면 플래그 제거를 반드시 작업 목록에 넣으세요.

마지막으로, 기능 플래그는 보안 권한을 대체하지 않습니다. 플래그는 노출과 릴리스를 조절하는 장치이고, 권한 검사는 사용자가 무엇을 할 수 있는지 결정하는 보안 장치입니다. 대상 세그먼트가 아니면 UI를 숨기는 것만으로 충분하지 않습니다. 서버에서도 권한과 데이터 접근을 검증해야 합니다.

검증 체크리스트

아래 체크리스트는 AI 기능을 공개하기 전 최소 게이트로 쓰기 좋습니다.

AI에게 검증을 맡길 때는 체크리스트를 그대로 붙여넣기보다, 이번 기능에 맞는 판단 지표를 채우게 하세요. 예를 들어 '새 검색 결과 정렬 기능의 롤아웃 체크리스트를 위 형식으로 만들되, 성공 지표는 결과 클릭률, 무결과 비율, p95 응답 시간, 신고율로 제한해줘'처럼 구체화합니다. 그러면 AI가 일반론을 반복하지 않고 실제 기능에 맞춘 검증표를 만듭니다.

또 하나의 좋은 검증은 '플래그 꺼짐 스냅샷'입니다. 새 기능을 만들기 전에 기존 화면과 핵심 동작을 테스트로 고정합니다. 이후 AI가 새 코드를 넣어도 플래그 꺼짐 테스트가 깨지면 기존 사용자를 건드린 것입니다. 이 테스트는 작은 프로젝트에서도 효과가 큽니다.

다음 단계

첫 번째 다음 단계는 현재 만들고 있는 AI 기능 하나를 골라 플래그 계약을 작성하는 것입니다. 거창한 시스템이 없어도 됩니다. 작은 설정 값, 내부 사용자 조건, 환경별 기본값, 수동으로 끌 수 있는 스위치부터 시작할 수 있습니다. 중요한 것은 기능을 켜고 끄는 의사결정이 코드 배포와 분리되어야 한다는 점입니다.

두 번째는 AI 프롬프트에 롤아웃 조건을 포함하는 습관을 들이는 것입니다. '구현해줘' 대신 '플래그 꺼짐 경로 유지, 대상 세그먼트 제한, 실패 복귀, 관측 이벤트, 롤백 기준, 제거 계획을 포함해줘'라고 요청하세요. 이 한 문장만으로도 AI가 만드는 코드와 테스트의 품질이 달라집니다.

세 번째는 팀이나 개인 프로젝트에 표준 롤아웃 단계표를 두는 것입니다. 예를 들어 내부 100%, 외부 1%, 5%, 25%, 50%, 100%처럼 기본 단계를 정하고, 각 단계에서 보는 지표와 대기 시간을 정합니다. 기능마다 단계가 달라질 수 있지만 기본값이 있으면 장애 상황에서 즉흥 판단이 줄어듭니다.

네 번째는 플래그 정리일을 캘린더나 작업 목록에 남기는 것입니다. 안전하게 공개한 기능도 정리하지 않으면 다음 AI 작업의 복잡도를 올립니다. 안정화된 플래그는 제거하고, 테스트는 항상 켜진 최종 경로 기준으로 단순화하세요.

VIBE 코딩의 목표는 AI에게 더 많은 권한을 주는 것이 아니라, AI가 만든 변화를 더 작은 위험 단위로 다루는 것입니다. 기능 플래그와 점진 배포 루프를 쓰면 AI의 속도는 유지하면서도 사용자에게 닿는 실패 범위를 줄일 수 있습니다. 새 기능이 클수록 먼저 물어보세요. '이 기능은 어떻게 끌 수 있는가, 누구에게 먼저 보여줄 것인가, 어떤 숫자에서 멈출 것인가.' 이 세 질문에 답할 수 있으면 AI가 만든 기능도 운영 가능한 제품 변화가 됩니다.