비밀번호 없는 로그인: 비즈니스 앱용 매직 링크 vs 패스키

비즈니스 앱에서 “비밀번호 없음”이 실제로 의미하는 것

“비밀번호 없음”은 “보안 없음”을 뜻하지 않습니다. 사용자가 장기적으로 유지해야 할 비밀번호 문자열을 생성하거나 기억하지 않는다는 뜻입니다. 대신 로그인은 그들이 가진 것(기기, 이메일 인박스, 전화번호)이나 기기에 내장된 기능(생체 인증 등)으로 승인되며, 보통 링크, 코드 또는 암호화 키 같은 단기 증명으로 뒷받침됩니다.

비즈니스 앱에서는 목표가 실용적입니다: 비밀번호로 인한 두 가지 일상 문제를 제거하는 것. 사람들이 비밀번호를 잊어 재설정 요청을 하고, 재사용 때문에 피싱과 크리덴셜 스터핑이 효과적이라는 문제입니다. 이는 지원 티켓, 계정 탈취, 필요한 도구에 접근하지 못하는 직원들의 불만으로 이어집니다.

팀들이 보통 비밀번호를 제거하는 이유는 운영을 바꾸기 때문입니다:

• "비밀번호 재설정" 요청 감소
• 자격 증명을 훔치는 피싱 페이지에 노출 감소
• 온보딩 속도 향상(첫날부터 비밀번호 규칙 교육 불필요)
• 단기 계약직이나 시즌 직원에 대한 접근 관리가 깔끔해짐
• 웹과 모바일 전반에 걸쳐 더 일관된 로그인 경험

비밀번호 없는 방식은 또한 새로운 실패 모드를 가져옵니다. 로그인에 이메일을 사용하면 지연이나 스팸 필터링으로 최악의 순간에 접근이 막힐 수 있습니다. 전화에 의존하면 기기 분실이나 번호 변경으로 잠길 수 있습니다. 공용 리소스(예: 공유 인박스나 공장 층의 공유 전화)에 의존하면 ‘공유 계정’으로 흐르기 쉬워 감사 추적과 오프보딩에 문제가 생깁니다.

초기에 설정해야 할 기대치는 간단합니다: 모든 사용자, 기기, 근무 환경에 맞는 단일 방법은 없습니다. 대부분의 비즈니스 앱은 기본 로그인 방법과 복구를 위한 백업 방법을 함께 둡니다.

내부 도구나 고객 포털을 AppMaster 같은 플랫폼에서 개발하고 있다면, 로그인도 다른 핵심 기능처럼 계획하세요. 사용자가 누구인지, 어떤 기기를 쓰는지, 누군가 로그인할 수 없을 때 지원팀이 현실적으로 처리할 수 있는 범위를 결정하세요.

빠른 개요: 매직 링크, OTP 코드, 패스키

“비밀번호 없는 로그인”은 보통 사용자가 비밀번호를 생성하거나 기억하지 않고 자신임을 증명하는 것을 의미합니다. 주요 옵션은 매직 링크, 일회용 코드(OTP), 패스키입니다. 세 가지 모두 비밀번호 재사용을 줄이지만 실제 운영에서는 매우 다르게 작동합니다.

매직 링크는 이메일로 전송된 고유 링크를 통해 사용자를 로그인시킵니다. 링크는 보통 한 번만 유효하고 빠르게 만료됩니다. 사용자는 단순히 메일함을 열어 탭하면 되어 편리하게 느껴집니다. 단점은 인박스가 관문이 된다는 점입니다: 이메일 지연, 필터링, 또는 해당 기기에서 이메일에 로그인되어 있지 않으면 로그인에 실패합니다.

OTP 코드는 사용자가 입력하는 짧고 시간 제한된 숫자입니다. 이메일, SMS로 전달되거나 인증기 앱에서 생성될 수 있습니다. 이메일 OTP는 매직 링크와 같은 전달성 의존성을 가지지만 링크를 열 수 없을 때도 작동합니다. SMS OTP는 이메일이 느릴 때 도움이 될 수 있지만 비용이 추가되고 전화번호 탈취에 취약할 수 있습니다.

패스키는 전화, 노트북 또는 하드웨어 키에 저장되는 기기 기반 자격 증명입니다. 사용자는 지문, 얼굴 인식 또는 기기 PIN으로 확인합니다. 설정 후에는 가장 매끄러운 경험을 제공하고, 링크나 코드보다 피싱에 강합니다. 어려운 점은 복구입니다: 사람들은 기기를 잃거나 폰을 바꾸거나 공유 워크스테이션을 사용합니다.

일반적인 혼합 구성은 다음과 같습니다:

• 알려진 기기에서는 기본 로그인으로 패스키 사용
• 새 기기나 복구 시 이메일 또는 SMS OTP를 폴백으로 제공
• 극단적 사례(퇴사자, 공유 인박스 등)는 관리자 헬프데스크의 초기화 사용

AppMaster 같은 플랫폼에서 내부 도구를 만든다면, 로그인은 보안과 지원 작업량의 혼합으로 다루세요. "최고"의 방법은 사용자가 최악의 월요일 아침에도 신뢰성 있게 완료할 수 있는 방법입니다.

신경 써야 할 보안 트레이드오프

핵심 보안 질문은 단순합니다: 공격자가 현실적으로 무엇을 훔칠 수 있고, 실제 직원이 그것을 얼마나 쉽게 건네줄 수 있는가?

피싱 저항력(누가 속아넘어가는가)

패스키는 일반 사용에서 피싱 당하기 가장 어렵습니다. 로그인은 실제 앱이나 사이트에 묶여 있고, 읽어서 다른 페이지에 입력할 수 있는 코드에 의존하지 않기 때문입니다. OTP 코드(SMS나 인증기)는 사회공학에 가장 취약합니다. 매직 링크는 중간 수준입니다: 공격자가 이메일 스타일을 모방하면 많은 사람들이 클릭할 수 있습니다.

유용한 비교는 공격자가 무엇이 필요한지 묻는 것입니다:

• 매직 링크: 사용자 이메일 인박스에 접근(또는 전달 규칙 제어) 필요
• 이메일 OTP: 사용자 이메일 인박스 접근 필요
• SMS OTP: SIM 스왑, 통신사 탈취, 또는 전화와 알림 접근 필요
• 패스키: 신뢰된 기기 접근 및 잠금 화면을 우회할 방법(또는 동기화된 패스키 계정 접근) 필요

피해를 줄이는 세션 기본 사항

강력한 로그인이 있어도 헐렁한 세션 처리로 망가질 수 있습니다. 다음 기본값을 일찍 정하고 웹과 모바일에서 일관되게 유지하세요:

• 링크/코드의 짧은 유효 기간(시간이 아닌 분)
• 일회용 사용, 새 코드 발급 시 이전 코드 무효화
• 분명한 철회(모든 세션 로그아웃, 기기 권한 회수, 토큰 회전)
• 위험 이벤트(새 기기, 새 위치, 권한 변경)에 대한 추가 확인

관리자와 지원 플로우는 숨어 있는 위험입니다. 헬프데스크 직원이 "그냥 이메일 변경"이나 "검증 건너뛰기"로 누군가를 차단 해제할 수 있다면 그 경로는 악용됩니다. 내부 금융 승인 포털 같은 경우, 공격자는 설득력 있는 지원 채팅 한 번으로 이메일을 바꾸고 매직 링크를 수신할 수 있습니다. 복구와 관리자 작업에는 감사 가능한 단계가 필요하며, '도움' 권한과 '계정 탈취' 권한을 분리하세요.

이메일 전달성: 이메일 기반 로그인에 숨겨진 비용

매직 링크나 이메일 OTP 같은 이메일 기반 로그인은 간단해 보이지만 전달성은 가장 큰 운영 비용이 될 수 있습니다. 가장 흔한 지원 티켓은 "비밀번호를 잊어버렸어요"가 아니라 "이메일을 못 받았어요"입니다.

지연과 누락은 보통 스팸 필터, 엄격한 기업 게이트웨이, 사용자 메일박스 규칙에서 발생합니다. 3분 늦게 도착한 매직 링크는 단순히 성가실 뿐만 아니라 반복 요청, 잠금, 사용자가 지원팀에 받은 이메일 스크린샷을 공유하는 상황을 촉발할 수 있습니다.

발신자 평판은 대부분의 팀이 생각하는 것보다 더 중요합니다. 도메인이 로그인 이메일을 보낼 권한이 있고 메시지가 변경되지 않았음을 증명해야 합니다. 일반적인 구성 요소는 SPF(누가 보낼 수 있는가), DKIM(메시지 서명), DMARC(검사가 실패했을 때의 처리)입니다.

이것들이 있어도 발송 패턴 때문에 문제가 생길 수 있습니다. 사용자가 "다시 보내기"를 다섯 번 누르면 특히 회의나 근무조 교대 후 많은 직원이 동시에 로그인하면 스팸 발송자로 보일 수 있습니다.

속도 제한과 재시도 정책이 필요합니다. 정당한 사용자를 가두지 않으면서 반복 전송을 늦추세요. 현실적인 설정은 보통 짧은 재전송 쿨다운, 가시적인 타이머, "스팸함 확인" 힌트, 차단된 인박스를 위한 폴백(예: SMS OTP나 패스키)을 포함합니다. 또한 반송, 차단, 전달 시간을 로깅하고 지원 친화적인 오류 메시지로 문제를 명확히 표시하세요.

내부 도구를 만든다면 기업 필터링이 진짜 시험입니다. 어떤 부서는 이메일을 잘 받지만 다른 부서는 전혀 못 받을 수 있습니다. AppMaster 같은 플랫폼은 이메일 흐름을 빠르게 연결하는 데 도움이 될 수 있지만, 장기적으로는 전달 모니터링과 우아한 폴백 설계가 필요합니다. 그렇게 하면 "이메일 못 받음"이 매일 벌어지는 화재 진압이 되지 않습니다.

SMS OTP: 도움이 될 때와 해로울 때

SMS 일회용 코드는 간단하게 느껴집니다: 전화번호 입력, 문자 수신, 코드 입력. 사용자가 패스키를 쓸 준비가 안 되었거나 이메일이 신뢰할 수 없을 때 이 단순함이 큰 장점입니다.

첫 번째 문제는 전달입니다. 문자는 국가와 통신사에 따라 도착률이 균일하지 않습니다. 로밍은 지연이나 차단을 일으킬 수 있고, 일부 기업용 폰은 알 수 없는 발신자를 필터링합니다. 번호 변경도 흔합니다. 사용자는 통신사를 바꾸거나 SIM을 잃거나 오래된 번호를 계정에 묶어둘 수 있고, 이로 인해 '빠른 로그인'이 지원 티켓이 됩니다.

보안은 더 큰 문제입니다. SMS는 전화번호에 대한 제어를 증명할 뿐 사람 자체를 증명하지 않습니다. 그로 인해 다음과 같은 문제가 생깁니다:

• SIM 스왑 공격으로 코드가 공격자에게 전달될 수 있음
• 가족 요금제나 공유 기기로 메시지가 다른 사람에게 노출될 수 있음
• 재사용된 번호로 인해 새 소유자가 이전 계정의 코드를 받을 수 있음
• 잠금 화면 미리보기로 근처 사람이 코드를 볼 수 있음
• 도난당한 폰이 SIM이 활성화된 상태라면 여전히 SMS를 받을 수 있음

비용과 신뢰성도 고려해야 합니다. 각 로그인 시도는 유료 문자 메시지를 트리거할 수 있고, 일부 팀은 출시 후에야 비용을 인지합니다. SMS 제공자나 통신사도 장애가 있을 수 있습니다. 교대 시간에 문자가 실패하면 헬프데스크가 사실상 로그인 시스템이 됩니다.

그렇다면 언제 SMS가 적합할까요? 보통 기본 출입구가 아니라 폴백으로 사용하세요. 예를 들어 읽기 전용 디렉터리에 대한 저위험 역할이나 사용자가 이메일이나 패스키에 접근할 수 없을 때 최종 복구 옵션으로 적합합니다.

실용적인 접근법은 SMS를 복구용으로 예약하고, 민감한 작업(지급 정보 변경, 새 기기 추가 등)에는 추가 확인을 요구하는 것입니다.

실제에서의 패스키: 매끄러운 로그인, 까다로운 복구

모든 것이 정상일 때 패스키는 훌륭합니다. 사용자는 "로그인"을 탭하고 Face ID나 Touch ID로 확인(또는 기기 PIN 입력)하면 됩니다. 비밀번호를 오타 낼 일도, 복사/붙여넣을 코드도 없고 피싱도 훨씬 어렵습니다.

문제는 최악의 날에 드러납니다. 폰을 잃고, 노트북을 교체하고, 새 기기를 사용하려는 사람이 이전 기기에 접근할 수 없을 때입니다. 패스키 상황에서 "비밀번호를 잊었다"는 "나를 증명할 방법이 기기 없이 어떻게 있는가"가 됩니다.

기기간 사용도 생각보다 복잡합니다. 패스키는 생태계 내에서 동기화될 수 있지만 팀은 종종 혼합되어 있습니다: iOS와 Android 폰, Windows 노트북, 공유된 Mac, 계약자 기기 등이 섞여 있습니다. 공유 작업용 기기는 특히 까다로운데, 키오스크나 교대 컴퓨터에 패스키를 저장하고 싶지 않기 때문입니다.

실용적인 정책은 속도와 복구의 균형을 맞춥니다:

• 사용자당 여러 패스키 허용(업무용 폰 + 개인 폰, 또는 폰 + 노트북)
• 온보딩 시 두 번째 패스키를 추가하도록 요청
• 최소 하나의 폴백 방법(검증된 이메일 매직 링크나 인증기 스타일 OTP) 유지
• 비즈니스 계정을 위한 관리자 지원 복구 플로우 제공(감사 로그 포함)
• 공유 기기에 대한 규칙 정의(저장된 패스키 대신 단기 세션 사용)

예: 창고 감독관이 공유 태블릿을 사용한다고 합시다. 개인 폰에서는 패스키가 완벽하지만 공유 태블릿에서는 단기 세션과 두 번째 요소를 요구할 수 있습니다. AppMaster로 앱을 빌드한다면, 복구, 감사, 역할 기반 관리자 재설정 등을 로그인 플로우와 함께 제품 요구사항으로 조기에 모델링하세요.

단계별: 앱에 맞는 로그인 방법 선택하기

로그인을 하는 사람이 누구이고 그들이 무엇을 하는지부터 시작하세요. 관리되는 노트북을 가진 직원은 패스키를 편하게 쓸 수 있지만, 공유 기기에서 일하는 계약직은 일회용 코드가 필요할 수 있습니다. 최선의 설정은 보통 하나의 기본 방법과 하나의 폴백이지, 모두를 혼란스럽게 하는 세 가지 옵션이 아닙니다.

다음 질문을 순서대로 검토하세요:

• 사용자 그룹은 누구인가(직원, 고객, 관리자, 계약직)와 그들이 실제로 쓰는 기기는 무엇인가?
• 기본 로그인 방법은 무엇이고, 기본이 실패할 때 폴백은 무엇인가?
• 사용자가 폰을 잃거나 이메일을 바꾸거나 기기에 접근할 수 없을 때 복구 경로는 무엇인가?
• 수용 가능한 남용 수준(위험과 지원 부담)은 어느 정도인가?
• 사건 발생 후 어떤 것을 증명해야 하는가(로그와 감사 기록)?

다음으로 명확한 시간 창을 설정하세요. 매직 링크는 빨리 만료되어야 하지만 너무 빠르면 앱을 전환하는 동안 사용할 수 없습니다. OTP 코드는 짧게 유지하고 재전송 쿨다운을 설정해 무차별 시도와 인박스 스팸을 줄이세요.

또한 반복 실패 시 어떻게 할지 결정하세요: 일시적 잠금, 단계별 인증 강화, 수동 검토 등.

로깅은 선택 사항이 아닙니다. 성공한 로그인, 실패한 시도(사유 포함), 이메일/SMS 전달 상태(전송, 반송, 지연)를 캡처하세요. 이는 전달성 문제를 가시화하고 지원팀이 "보냈나요?"에 대해 추측하지 않게 합니다.

마지막으로 지원 스크립트를 작성하세요. 직원이 신원을 어떻게 확인할지(예: 사원 번호 + 관리자 확인), 무엇을 변경할 수 있는지(이메일, 전화, 기기)를 정의하세요. AppMaster에서 이를 만든다면, 이러한 규칙을 인증 흐름 및 비즈니스 프로세스에 조기에 매핑해 웹과 모바일 전반에 걸쳐 복구가 일관되게 이루어지도록 하세요.

예시 시나리오: 혼합 기기를 사용하는 내부 포털

교대 인수인계, 사건 노트, 재고 요청, 승인 등을 다루는 운영 포털을 50명의 직원과 소수의 계약자가 사용한다고 상상해 보세요. 사람들은 하루에 여러 번 로그인하고 종종 책상, 창고, 트럭 사이를 이동합니다.

제약 조건은 대부분의 실제 팀처럼 복잡합니다. 일부 역할은 주간 교대에 따라 공유 이메일 별칭을 사용합니다. 현장 근로자는 셀룰러 서비스가 불안정하고, 일부 구역은 실내에 신호가 없습니다. 관리자들은 주로 iPhone을 사용하고 빠른 로그인을 기대합니다. 계약자는 수시로 교체되므로 접근을 쉬운 방식으로 부여하고 철회해야 합니다.

이 상황에서 실용적인 설정은 다음과 같습니다:

• 직원 기본값으로 패스키 사용(속도와 피싱 저항의 적절한 조합)
• 새 기기나 패스키가 없을 때 폴백으로 이메일 OTP 제공
• SMS는 복구용으로만 제한(이메일 접근이 어려운 일부 사용자만 허용해 SIM 스왑 위험과 비용을 줄임)
• 공유 역할은 공유 인박스 대신 별도 계정 사용, 포털 내부는 역할 기반 접근
• 분실 기기 복구 경로를 명확히 하고 최종 단계는 새 패스키 재등록으로 마무리

이 방식이 효과적인 이유: 직원은 대부분의 경우 원터치 로그인으로 빠르게 접근하고, 폴백은 새 폰, 잊어버린 노트북, 통신 불량 같은 이상한 날들을 커버합니다. 계약자는 이메일 OTP만 사용하게 해 개인 기기 패스키에 의존하지 않게 할 수 있습니다.

30일 후 성공 지표는 관리자의 차단된 로그인 감소, OTP가 주로 백업이라 "이메일 못 받음" 불만 감소, 패스키로 인해 재설정 티켓 감소 등입니다. AppMaster 같은 플랫폼에서 포털을 빌드하면 인증과 메시징 흐름을 빠르게 연결하고 실제 지원 데이터를 기반으로 조정하기 쉬워집니다.

지원 티켓과 위험을 만드는 흔한 실수

대부분의 비밀번호리스 롤아웃 실패는 지루한 이유 때문입니다: 데모에서는 잘 되지만 실제 사용자가 엣지 케이스를 만나면 지원이 폭주합니다.

매직 링크 관련 빈번한 문제는 유효기간을 너무 길게 주는 것입니다. 링크가 몇 시간(또는 며칠) 유효하거나 여러 번 사용할 수 있으면 전달 가능한 키가 됩니다. 사람들은 이메일을 동료에게 전달하거나, 잘못된 기기에서 링크를 열거나, 인박스 검색으로 오래된 링크를 불러옵니다. 짧은 유효 기간과 일회용 사용은 이 위험을 줄이고 “왜 다른 사용자로 로그인되었나요?” 같은 티켓을 줄입니다.

OTP 로그인은 재전송을 무제한으로 허용할 때 문제가 됩니다. 사용자가 "재전송"을 연타하면 이메일 제공자는 급증을 스팸으로 인식하고 이후 이메일이 스팸으로 분류될 수 있습니다. 그러면 사용자는 더 많이 재전송하고 전달성이 더 악화됩니다. 짧은 쿨다운, 명확한 타이머, 시간당 시도 상한을 적용하세요.

또 다른 실수는 로그인 컨텍스트에 바인딩하지 않는 것입니다. 어떤 앱은 "휴대폰에서 링크를 클릭하고 노트북에서 계속하기"를 허용해도 되지만, 민감한 내부 도구는 그렇지 않을 수 있습니다. 민감한 도구의 경우 매직 링크나 OTP 흐름을 시작한 같은 브라우저 세션에 바인딩하거나 기기 변경 시 추가 확인을 요구하는 편이 안전합니다.

가장 비용이 많이 드는 실수는 실제 복구 경로를 건너뛰는 것입니다. 사용자가 기기를 잃거나 교체하면 팀은 즉흥적으로 관리자에게 채팅으로 로그인을 승인해달라고 요청합니다. 이것은 곧 심각한 신원 확인 문제로 발전합니다.

혼란을 막는 간단한 정책:

• 짧은 유효 기간의 일회용 매직 링크(분 단위)
• 재전송 및 IP/사용자별 속도 제한
• 민감한 역할에 대한 기기 변경 규칙과 단계별 확인
• "관리자에게 물어보기"에 의존하지 않는 문서화된 복구 흐름과 감사 로그

AppMaster에서 개발한다면, 이러한 항목들을 사후 작업이 아니라 제품 요구사항으로 취급하세요. 이들은 보안 태세와 지원 부담 모두를 결정합니다.

출시 전 빠른 체크리스트

비밀번호 없는 로그인을 출시하기 전에 "지원 티켓" 관점으로 빠르게 점검하세요. 대부분의 문제는 암호학 문제가 아니라 타이밍, 전달, 복구 문제입니다.

시간 제한부터 시작하세요. 매직 링크나 일회용 코드는 위험을 줄일 만큼 빨리 만료되어야 하지만 느린 이메일, 약한 셀 신호, 앱 전환으로 실패하지 않을 정도로 충분히 길어야 합니다. 예를 들어 5분을 선택했다면 실제 인박스 지연과 실사용자 테스트를 해보세요.

출시 전 체크리스트:

• 링크와 코드의 현실적인 만료 규칙 설정, 만료 시 명확한 오류 표시
• 재전송 쿨다운과 계정 차단 규칙 추가, 지원팀용 문서화(몇 회 시도, 대기 시간)
• 최소 두 가지 복구 경로 제공(예: 패스키 + 이메일 OTP)으로 분실 폰으로 인한 잠금 방지
• 누가 언제 어떤 방법으로 로그인했는지, 전달 상태(전송, 반송, 지연, 실패) 등 감사 기록 캡처
• 관리자 및 고위험 작업 보호(지급 정보 변경, 관리자 추가, 데이터 내보내기 등은 재인증 요구)

작업 하나로 리허설하세요: 동료에게 새 기기로 로그인하게 하고, 가득 찬 인박스 상태, 비행기 모드 상태에서 접근을 시도하게 한 뒤 기본 기기를 "잃어버린" 상태로 복구하게 해보세요. 그 여정이 혼란스럽다면 사용자는 티켓을 열 것입니다.

AppMaster에서 만든다면 이러한 이벤트(로그인 시도, 전달 결과, 단계별 요청)를 어디에 기록할지 계획해 디버그를 추측 없이 할 수 있게 하세요.

다음 단계: 파일럿, 측정, 개선을 빠르게 반복하기

비밀번호 없는 로그인은 체크박스가 아니라 제품 변화로 다루세요. 소규모 파일럿으로 시작하세요: 한 팀, 하나의 기본 방법(예: 패스키), 하나의 폴백(예: 이메일 OTP). 문제가 생겼을 때 사람들과 대화할 수 있을 만큼 작게, 그러나 실제 패턴을 볼 수 있을 만큼 충분히 크게 그룹을 유지하세요.

처음부터 무엇이 "작동"인지 정의하고 측정하세요. 가장 유용한 지표는 단순합니다: 전달 실패(반송 또는 지연된 이메일, 수신되지 않은 SMS), 평균 로그인 시간(탭 후 앱 진입까지), 지원 티켓과 주요 원인, 잠금 및 복구 요청, 그리고 로그인 시작 후 중도 이탈률입니다.

그다음에는 서류상으로 좋은 것보다 실제 배운 것에 기반해 제어 장치를 추가하세요. 이메일 링크가 지연되면 인박스 배치 개선과 링크 만료 단축을 하고, SMS OTP가 남용되면 속도 제한과 단계별 검사를 추가하세요. 패스키가 공유 기기에서 혼란을 준다면 "다른 방법 사용" 옵션을 명확히 표시하세요.

루프를 짧게 유지하세요: 매주 작은 개선을 배포하고 이유를 평이한 언어로 기록하세요. 예: "전달된 링크 전달성 문제로 인해 매직 링크 만료를 30분에서 10분으로 줄였습니다." 같은 문장.

직접 앱을 만드는 경우 AppMaster는 이러한 변경을 빠르게 테스트하는 데 도움이 됩니다: UI 빌더에서 인증 화면 설정, 사전 구축된 모듈로 이메일/SMS 전송, 비즈니스 프로세스 편집기에서 규칙(속도 제한, 재시도, 복구 단계) 제어 등으로 전체를 다시 작성하지 않고 조정할 수 있습니다.

파일럿이 안정적이면 팀별로 확장하세요. 데이터가 안전하게 폴백을 제거할 수 있음을 보여줄 때까지 폴백을 유지하세요. "이제 제거해도 되겠다"는 느낌으로 하지 마세요.