Cloudflare 사용자 API 토큰 화면 개편: 계정 토큰과 무엇이 다를까요?

Cloudflare에서 새 사용자 API 토큰 만들기 화면을 열었는데 계정 토큰과 비슷해 보인다면, 먼저 토큰이 누구를 대신해 동작하는지 확인하세요. 2026년 11월 6일 바뀐 것은 사용자 토큰을 만들고 검토하는 화면입니다. 사용자 토큰은 여전히 만든 사용자를 대신합니다. 팀의 배포나 서비스 연동에 쓸 때는 화면의 모양보다 소유자, 필요한 자원, 읽기와 편집의 차이가 먼저입니다.

아래는 11월 9일 공식 변경 기록과 토큰 문서를 확인해 정리한 내용입니다. 실제 계정에 로그인해 토큰을 발급하거나 권한·IP 설정을 바꿔 시험하지 않았습니다. 표와 사례는 발급 버튼을 누르기 전에 무엇을 읽을지 설명하는 가상 검토 자료입니다.

새 화면에서 달라진 것과 그대로인 것

Cloudflare는 사용자 토큰 생성 화면을 계정 토큰 화면과 비슷한 흐름으로 바꿨습니다. 생성과 검토 과정이 정리됐고, 발급 전에 여러 정책을 화면에서 추가하거나 수정하고 제거할 수 있습니다. 만료 선택과 클라이언트 IP 제한도 같은 흐름에서 확인할 수 있어요. 설정할 칸을 더 알아보기 쉬워졌다는 소식입니다.

하지만 화면이 비슷하다고 토큰의 소유자가 달라지지는 않습니다. 공식 변경 기록은 사용자 토큰이 여전히 만든 사용자를 대신해 동작한다고 명시합니다. 개인의 허용 범위에서 잠깐 실행하는 작업과, 담당자가 바뀌어도 팀이 책임져야 하는 서비스 연동에는 다른 질문이 필요합니다. 누가 만들었는지만 적는 대신 누가 앞으로 관리할지, 교체가 필요할 때 누가 확인할지를 함께 적어 보세요.

공식 안내에서 사용자 토큰의 출발점은 My Profile의 API Tokens입니다. 계정 소유 토큰은 선택한 계정의 관리 화면에서 시작합니다. 화면의 언어나 메뉴 배치가 다르다면 새 버튼의 위치를 외우기보다 현재 어느 프로필 또는 계정에서 작업하는지 먼저 보세요. 특히 여러 계정을 관리한다면 대상 계정이 바뀌지 않았는지 검토하는 습관이 도움이 됩니다.

용도를 정할 때	가장 먼저 볼 것
개인이 잠깐 하는 조회나 스크립트	사용자 대신 실행해야 하는 작업인가요?
팀이 관리하는 계속 실행되는 연동	계정 소유 토큰과 해당 API 지원을 검토했나요?
사용자 토큰 화면이 새로 보임	화면 변경과 소유권 변경을 구분했나요?
계정 토큰 버튼을 찾을 수 없음	해당 계정과 생성 권한이 맞나요?

‘누구 소유인지’와 ‘무엇에 닿는지’를 나눠 보세요

토큰의 소유자는 어느 사용자나 계정에 연결되는지를 말합니다. 정책의 자원은 그 토큰이 어떤 대상에 접근하도록 허용하는지입니다. 여기에 읽기나 편집 같은 동작 권한이 붙습니다. 같은 화면에 나와도 세 질문은 서로 다릅니다. 예를 들어 사용자 토큰이라도 정책에서 특정 영역의 DNS를 읽도록 지정할 수 있습니다. 반대로 계정 소유라는 이유만으로 그 계정의 모든 작업이 허용된다고 볼 수는 없습니다.

가상의 경우로 서비스 한 곳의 DNS 레코드를 읽어 목록을 만드는 스크립트를 생각해 봅시다. 이 작업에는 일반적으로 내용을 편집할 권한을 검토할 이유가 없습니다. 공식 문서에는 특정 영역에 DNS 읽기만 주는 예가 있습니다. 우선 어느 영역을 읽어야 하는지와 읽은 값을 어디에 쓸지 적고, 두 번째 영역은 필요한 근거가 있을 때만 검토합니다. 대상이 하나인데 ‘전체 영역’을 고르는 편이 편하다는 이유로 범위를 넓힐 필요는 없어요.

템플릿은 시작을 돕지만 검토를 대신하지 않습니다. Cloudflare는 템플릿에 미리 정해진 정책이 들어 있다고 안내합니다. DNS 편집 템플릿이 익숙하더라도, 읽기 업무에서는 그 권한이 과할 수 있습니다. 문서상 대부분의 권한에서 편집에는 생성·조회·수정·삭제·목록 기능이 포함될 수 있고, 읽기에는 조회와 해당되는 목록만 포함됩니다. 세부 범위는 선택한 권한에 맞춰 봐야 합니다.

정책을 여러 개 넣을 수 있다면 요약도 한 줄씩 읽으세요. 예를 들어 읽기 전용 정책 하나가 있어도, 같은 토큰에 별도 정책이 붙어 있다면 전체 발급 범위를 그 한 줄만으로 설명할 수 없습니다. 발급 전에 ‘이 줄은 어떤 작업을 위해 필요한가’와 ‘무슨 자원에 적용되는가’를 물어보세요. 삭제하거나 범위를 줄일 근거가 명확하면 만들기 전에 조정하는 편이 이해하기 쉽습니다.

같은 DNS 업무라는 이름 아래에서도 ‘현황을 보여 주는 보고서’와 ‘배포할 때 레코드를 반영하는 작업’은 나눠 볼 만합니다. 앞의 작업은 읽기 결과가 맞는지 확인하는 것이 목적이고, 뒤의 작업은 변경할 자원과 승인 기준을 따로 확인해야 합니다. 문서나 보고서에서 둘을 같은 작업이라고 부르면 보고서에도 편집 권한이 있어야 한다고 오해하기 쉽습니다. 새 토큰을 만들지 않아도 두 작업의 실제 입력과 결과를 한 줄씩 적어 권한 차이를 드러낼 수 있습니다.

여러 계정에 비슷한 이름의 도메인이 있는 팀이라면, 영역 이름을 잘 적는 것만으로 검토를 끝내지 마세요. 공식 가이드가 계정과 영역 식별자를 먼저 찾으라고 안내하는 이유를 작업 계획에 반영할 수 있습니다. 검토할 사람이 대상 계정과 영역을 같은 것으로 이해했는지 확인하고, 시범 환경과 운영 환경을 각각 구분해 적으세요. 이 절차는 이름이 비슷한 자원에 작업을 요청하는 실수를 발견하기 위한 제안입니다.

만료와 IP 제한은 권한과 다른 질문입니다

만료는 언제까지 쓸지를, 클라이언트 IP 제한은 어디에서 온 요청을 허용할지 검토하는 조건입니다. 두 조건을 설정한다고 토큰의 편집 권한이 읽기로 바뀌지는 않습니다. 읽기만 필요한 작업이라면 먼저 읽기로 좁히고, 이어서 기간과 요청 출발지를 별도로 정하는 편이 분명합니다. 공식 안내는 만료와 IP 필드를 선택 가능한 제한으로 설명합니다. 항상 특정 값이 자동으로 걸린다고 가정하지 마세요.

가령 회사 자동화의 요청 출발지와 담당자 노트북의 출발지가 다르다면, 같은 토큰을 두 곳에서 임의로 함께 쓰는 설계부터 검토할 필요가 있습니다. IP 제한을 쓰려는 팀은 실행 위치와 네트워크 담당자가 승인한 출구 주소를 알아야 합니다. 임시 변경이나 예비 실행 환경을 포함해야 할지, 주소가 안정적인지도 확인하세요. 실패를 피하려고 범위를 넓히는 결론을 내리기 전에 실제 요청 위치가 맞는지 확인하는 것이 먼저입니다.

발급 전 적어 둘 질문	검토에서 얻고 싶은 답
이 토큰이 할 일은 무엇인가요?	읽기·편집 중 필요한 동작 한 가지부터
어느 자원에만 필요한가요?	해당 계정 또는 영역의 구체적인 범위
언제까지, 어디서 실행하나요?	승인된 만료·요청 위치·검증 방법
누가 관리하고 교체하나요?	책임자, 승인, 원래 흐름을 복구할 기준

개인 스크립트에서 팀 서비스로 넘어가는 순간

처음에는 담당자 혼자 실행하는 작은 스크립트였는데, 어느 날 팀의 정기 배포가 그 스크립트에 의존하게 될 수 있습니다. 이때는 기존 개인 토큰에 편집 권한을 더하는 것보다 운영 책임이 달라졌는지부터 보는 것이 좋습니다. 공식 문서는 사용자 토큰을 사용자로 동작하는 일회성 작업에, 계정 소유 토큰을 계정이 관리할 연동에 검토하도록 설명합니다. 다만 어떤 API에 쓸지와 해당 계정에서 실제 지원하는 권한을 문서로 대조해야 합니다.

계정 소유 토큰을 만들 수 있는 조건도 따로 있습니다. 공식 계정 토큰 문서는 API Token Provisioning 권한 또는 Super Administrator 상태를 설명합니다. 계정 구성원은 자신의 계정 권한 범위 안에서만 계정 토큰에 권한을 줄 수 있다고 안내합니다. 메뉴가 없을 때 개인 계정으로 우회하거나 더 큰 권한을 빌려 쓰는 대신, 해당 업무와 대상 자원을 적어 기존 승인 절차에 전달하세요.

기존에 정상 동작하는 토큰을 교체하는 일은 새 화면을 둘러보는 일과 다릅니다. 팀의 비밀 저장소에 어떤 실행 환경이 연결돼 있는지, 새 자격 증명이 승인된 범위에서 확인되기 전에 이전 것을 해제하지 않도록 순서를 정해야 합니다. 오래된 토큰을 언제 회수할지와 누가 실제 실행 결과를 확인할지도 계획에 넣으세요. 변경 직후에 실패했다고 원래 값을 채팅이나 작업 기록에 붙여 넣어 확인하는 방법은 피해야 합니다.

마지막 요약에서 비밀값 대신 확인할 것

Cloudflare의 공식 문서에서는 생성 전 요약에서 돌아가 수정할 수 있고, 생성하면 비밀값이 한 번만 표시된다고 안내합니다. 요약을 읽을 때는 소유자, 정책, 자원, 동작, 만료, IP 제한을 한 줄씩 확인하면 됩니다. 공유용 검토표에는 토큰의 목적과 범위만 기록하세요. 실제 토큰이나 비밀값이 표시된 화면은 보고 자료에 포함할 필요가 없습니다.

실제 전환을 맡은 팀이라면 먼저 ‘사용해야 하는 요청 하나가 승인된 환경에서 되는지’와 ‘필요 없는 자원까지 열리지 않도록 범위가 맞는지’를 별도 질문으로 남겨 보세요. 토큰 상태를 확인했다는 것과 업무 동작이 올바르다는 것은 같은 검수가 아닙니다. 이 글은 실계정의 승인·시험을 대신하지 않습니다. 가상의 조회 업무를 예로 든 이유는 토큰을 직접 만들지 않고도 설계의 빈칸을 찾을 수 있기 때문입니다.

예를 들어 요약에 필요한 권한이 잘 보이는데도 배포가 실패했다면, 그 실패가 권한 때문에 났다고 단정하지 마세요. 승인된 실행 환경이 실제로 올바른 비밀 저장소를 참조하는지, 요청 출발지가 계획과 맞는지, 어떤 응답을 받았는지를 각각 확인할 일입니다. 변경이 없던 이전 작업과 비교할 때는 차이가 난 지점 하나만 먼저 찾습니다. 원인 확인 없이 정책을 넓히면 문제는 남고 접근 범위만 커질 수 있습니다.

자주 나오는 질문

새 화면이 보이면 기존 사용자 토큰이 계정 소유로 바뀐 건가요? 공식 공지는 생성과 검토 화면의 변경을 다룹니다. 사용자 토큰이 계속 사용자를 대신한다고 설명하므로 화면만 보고 기존 토큰의 소유권이 변했다고 판단할 근거는 없습니다.

만료를 짧게 잡으면 편집 권한이 넓어도 괜찮나요? 기간과 권한의 목적은 다릅니다. 토큰이 유효한 동안 어떤 자원에 어떤 작업을 할 수 있는지부터 확인해야 합니다. 다른 서비스도 발급과 적용 범위가 다릅니다. GitHub Desktop의 짧은 수명 토큰과 기존 세션을 다룬 글은 별도 제품의 변경 사례입니다.

개인 연습이라면 꼭 실제 토큰을 발급해야 하나요? 정책을 읽는 연습은 가상 자원과 권한표만으로도 할 수 있습니다. 실제 발급이 필요한 경우에는 조직에서 허용한 계정과 용도, 저장 장소, 검증 절차를 먼저 확인하세요. 학습을 이유로 기존 운영 범위를 바꿀 필요는 없습니다.

확인한 공식 자료

2026년 11월 9일 Cloudflare 11월 6일 변경 기록, API 토큰 생성 가이드, 계정 소유 API 토큰 문서를 확인했습니다. 화면의 동작과 권한 요건은 공식 설명을 바탕으로 했으며, 사용자별 화면 제공 상태나 기존 연동의 정상 동작을 직접 확인한 결과는 아닙니다.

토큰의 소유자·자원·동작과 기간·요청 위치를 나누어 보는 자체 개념도입니다.