워드프레스 애플리케이션 비밀번호 발급과 사용법 정리

워드프레스를 조금 오래 쓰다 보면 관리 화면 밖에서 사이트를 건드려야 하는 일이 생깁니다. 스마트폰 워드프레스 앱으로 초안을 확인하거나, 백업 플러그인을 외부 저장소와 연결하거나, n8n 같은 자동화 도구로 글을 자동 발행하는 경우입니다. 이때 도구들은 대부분 “사용자 이름과 비밀번호를 입력하세요”라고 요구합니다. 여기서 관리자 로그인 비밀번호를 그대로 넣는 게 문제의 시작입니다.

애플리케이션 비밀번호는 바로 이 상황을 위해 워드프레스 코어에 들어간 기능입니다. 앱 하나마다 별도의 열쇠를 발급해 주고, 그 열쇠는 REST API 같은 외부 경로에서만 통합니다. 필요 없어지면 그 열쇠만 골라 폐기하면 됩니다. 발급 자체는 클릭 몇 번이면 끝나는데, 실제로는 “메뉴가 안 보인다”, “401이 떨어진다” 같은 지점에서 대부분 막힙니다. 그 갈림길까지 순서대로 정리했습니다.

한눈에 · HTTPS·REST API 응답 확인 → 사용자 > 프로필 하단에서 용도별 이름으로 발급 → curl로 users/me 인증 테스트 → 도구에 등록하고 환경변수로 분리 → 안 쓰는 항목 폐기

애플리케이션 비밀번호가 뭐고, 왜 계정 비밀번호를 쓰면 안 되나

외부 도구에 로그인 비밀번호를 넣는다는 건, 그 도구에게 사이트 전체 권한을 넘긴다는 뜻입니다. 자동화 서비스 계정이 털리거나, 노트북을 분실하거나, 설정 파일을 실수로 공개 저장소에 올리는 순간 사이트가 같이 넘어갑니다. 게다가 로그인 비밀번호를 바꾸면 그 비밀번호를 넣어둔 모든 도구가 한꺼번에 죽습니다.

애플리케이션 비밀번호는 이걸 쪼개 놓은 개념입니다. 도구마다 따로 발급하고, 사고가 나면 해당 항목 하나만 폐기하면 나머지는 그대로 동작합니다. 발급된 문자열로는 wp-admin 로그인이 되지 않기 때문에, 유출됐을 때의 피해 범위도 로그인 비밀번호보다 좁습니다.

로그인 비밀번호와 무엇이 다른가

가장 큰 차이는 통하는 경로입니다. 로그인 비밀번호는 wp-login.php로 들어가는 열쇠고, 애플리케이션 비밀번호는 REST API(/wp-json/)와 XML-RPC 같은 외부 인증 경로에서만 동작합니다. 그래서 이 문자열을 주워도 관리 화면에 직접 로그인은 못 합니다.

또 하나는 개수입니다. 로그인 비밀번호는 계정당 하나지만, 애플리케이션 비밀번호는 필요한 만큼 여러 개를 만들 수 있습니다. 워드프레스 5.6부터 코어 기능으로 들어왔으니 별도 플러그인 설치도 필요 없습니다.

어떤 도구들이 이 방식을 요구하나

모바일 워드프레스 앱, UpdraftPlus 같은 백업 도구의 원격 연동, n8n·Make·Zapier 같은 자동화 서비스, 그리고 직접 만든 업로드 스크립트가 대표적입니다. 요즘은 REST API 연동을 지원하는 서비스가 대체로 “Application Password”를 명시해서 요구합니다.

의외로 유용한 지점이 2단계 인증입니다. 2FA 플러그인을 켜두면 앱에서 로그인이 막히는 경우가 있습니다. 앱은 인증 코드 입력 화면을 처리할 방법이 없기 때문입니다. 애플리케이션 비밀번호는 2FA를 우회하는 별도 경로라서, 이럴 때 정석 해법이 됩니다.

발급 전에 확인할 세 가지

개념을 잡았으면 바로 발급 화면으로 가고 싶겠지만, 그 전에 환경을 세 가지만 봐 두면 시간을 아낍니다. 여기서 걸리면 애초에 발급 영역 자체가 화면에 나타나지 않기 때문입니다.

SSL이 없으면 메뉴가 안 뜬다

워드프레스는 기본적으로 HTTPS가 아닌 사이트에서 애플리케이션 비밀번호 기능을 숨깁니다. Basic 인증은 아이디와 비밀번호를 요청 헤더에 담아 보내는 방식이라, 암호화되지 않은 연결에서는 그대로 노출되기 때문입니다. 사이트 주소가 http://로 시작하면 프로필 하단에 발급 영역이 아예 표시되지 않습니다.

예외는 로컬 개발 환경입니다. localhost나 .local 같은 주소는 워드프레스가 로컬로 판단해 기능을 열어 줍니다. 실제 도메인인데 안 보이면 십중팔구 SSL 문제입니다. 설정 > 일반에서 워드프레스 주소와 사이트 주소가 https://로 저장되어 있는지 먼저 보세요.

내 권한으로 발급이 되는지

자기 계정의 애플리케이션 비밀번호는 편집자, 작성자, 기여자도 발급할 수 있습니다. 다만 다른 사람 계정의 것을 만들려면 관리자 권한이 필요합니다. 자동화 전용 계정을 따로 만들어 그 계정의 비밀번호를 발급하려면 관리자로 로그인해야 한다는 뜻입니다.

세 번째는 REST API가 살아 있는지입니다. 보안 플러그인이나 호스팅 방화벽이 /wp-json/ 경로를 막아둔 경우가 생각보다 흔합니다. 발급은 되는데 인증이 안 되는 상황의 절반쯤이 여기서 나옵니다. 터미널에서 한 줄로 확인할 수 있습니다.

curl -I https://example.com/wp-json/

HTTP/2 200 이나 HTTP/1.1 200 OK 가 돌아오면 정상입니다. 403이면 차단, 404면 REST API가 꺼져 있거나 퍼머링크 설정 문제입니다. 아무 응답 없이 멈추면 방화벽 쪽을 봐야 합니다.

관리자 화면에서 발급하는 순서

환경 확인이 끝났으면 실제 발급입니다. 경로는 짧습니다. 관리 화면에서 사용자 > 프로필로 들어가 아래로 스크롤하면 ‘애플리케이션 비밀번호’ 영역이 있습니다. 다른 계정 것을 만들려면 사용자 > 전체 사용자에서 해당 계정을 클릭해 편집 화면으로 들어가면 같은 영역이 나옵니다.

입력 칸은 ‘새 애플리케이션 비밀번호 이름’ 하나뿐입니다. 여기에 용도를 적고 ‘새 애플리케이션 비밀번호 추가’ 버튼을 누르면 바로 문자열이 나옵니다.

이름을 대충 지으면 나중에 못 지운다

이름 칸을 test나 app1로 채우는 분들이 많습니다. 하나만 쓸 때는 문제가 없지만, 도구가 넷다섯 개로 늘어난 뒤에 하나를 폐기하려고 보면 어느 게 무엇인지 알 수가 없습니다. 잘못 지우면 돌던 자동화가 조용히 멈춥니다.

n8n-포스팅, 노트북-백업, 아이폰-앱처럼 도구 이름과 용도를 함께 적어 두는 게 나중에 폐기 판단을 훨씬 쉽게 만듭니다. 발급 목록에는 이름과 함께 생성일, ‘마지막 사용’ 일시, 마지막으로 사용된 IP가 표시됩니다. 이 정보가 꽤 유용합니다. 쓰지 않는 도구인데 어제 사용 기록이 있거나, 낯선 IP가 찍혀 있으면 유출을 의심할 근거가 됩니다.

화면을 벗어나면 다시 볼 수 없다

발급 직후 나오는 문자열은 이런 형식입니다.

abcd EFGH 1234 ijkl MNOP 5678

네 글자씩 여섯 묶음, 공백을 포함해 24자입니다. 워드프레스가 사람이 옮겨 적기 쉽게 끊어 놓은 것입니다. 이 화면을 새로고침하거나 다른 페이지로 이동하면 다시 볼 수 없습니다. 데이터베이스에는 해시로만 저장되기 때문에 복구할 방법도 없습니다. 잊었으면 폐기하고 새로 발급하는 게 유일한 길입니다.

공백을 지워야 하는지 묻는 경우가 많은데, 워드프레스는 인증할 때 공백을 제거하고 비교합니다. 그래서 대체로 공백을 포함한 원본 그대로 넣어도 통과합니다. 다만 도구 쪽에서 입력값을 이상하게 잘라내는 경우가 있어서, 실패하면 공백을 뺀 24자 → 20자 형태로도 한 번 시도해 보는 편이 좋습니다.

발급한 비밀번호를 실제로 넣어보기

문자열을 받았으면 다음은 “이걸 어디에 넣나”입니다. 실제로 가장 많이 막히는 지점이 여기입니다. 인증 방식은 HTTP Basic 인증이고, 아이디 자리에는 워드프레스 사용자 이름(이메일이 아니라 로그인 아이디)을, 비밀번호 자리에는 발급받은 문자열을 넣습니다.

curl 한 줄로 되는지 먼저 확인

도구 설정 화면에서 씨름하기 전에, 터미널에서 인증이 되는지부터 확인하는 게 시간을 아낍니다. 내 계정 정보를 돌려주는 엔드포인트가 테스트용으로 적당합니다.

curl -u "myadmin:abcd EFGH 1234 ijkl MNOP 5678" \
  https://example.com/wp-json/wp/v2/users/me

성공하면 아래처럼 내 계정 JSON이 돌아옵니다.

{"id":1,"name":"myadmin","url":"","description":"","link":"https://example.com/author/myadmin/","slug":"myadmin","roles":["administrator"],...}

이 한 줄이 통과하면 워드프레스 쪽 준비는 끝난 것이고, 남은 문제는 도구 설정에 있다고 보면 됩니다. 실패하면 다음 중 하나가 옵니다.

{"code":"incorrect_password","message":"...","data":{"status":401}}
{"code":"rest_not_logged_in","message":"현재 로그인되어 있지 않습니다.","data":{"status":401}}

incorrect_password는 아이디나 비밀번호가 틀린 것입니다. 사용자 이름에 이메일을 넣었거나, 문자열을 복사할 때 앞뒤 공백이 섞인 경우가 대부분입니다. rest_not_logged_in은 성격이 다릅니다. 인증 정보가 서버까지 도달하지 않았다는 신호이고, 뒤에서 따로 다룹니다.

설정 파일 대신 환경변수

모바일 워드프레스 앱은 로그인 화면에서 ‘사이트 주소 입력’ 방식을 고르고, 아이디와 비밀번호 칸에 발급받은 문자열을 넣으면 됩니다. n8n은 WordPress 노드의 Credential에 Username / Password 두 칸이 있고, 여기가 그대로 애플리케이션 비밀번호 자리입니다. 백업 플러그인이나 배포 도구도 대개 ‘Application Password’ 라벨을 달아 두었습니다.

직접 스크립트를 만든다면 문자열을 코드에 박지 마세요. 스크립트에 하드코딩하고 Git에 올려서 사고 나는 패턴이 정말 흔합니다. 환경변수로 빼두는 게 가장 간단합니다.

export WP_USER="myadmin"
export WP_APP_PASS="abcd EFGH 1234 ijkl MNOP 5678"

curl -u "$WP_USER:$WP_APP_PASS" https://example.com/wp-json/wp/v2/users/me

크론으로 돌리는 스크립트라면 환경변수가 상속되지 않아 실패하는 경우가 있습니다. 이 부분은 crontab 작성법 정리, 등록해도 안 돌아가는 이유까지에 정리해 두었습니다. 그리고 도구가 여럿이면 도구마다 따로 발급하세요. 하나를 폐기해도 나머지가 살아 있는 게 이 기능의 존재 이유입니다.

안 될 때 원인별로 짚어보는 순서

여기까지 했는데 인증이 안 통하면, 원인은 대체로 정해져 있습니다. 위에서부터 순서대로 지워 나가는 게 빠릅니다.

증상	유력한 원인	확인·조치
발급 영역이 안 보임	HTTPS 미적용, 플러그인이 기능 차단	사이트 주소가 `https://`인지, 보안 플러그인 설정 확인
`401 incorrect_password`	아이디·문자열 오타	사용자 이름(이메일 아님) 확인, 공백 유무 바꿔 재시도
`401 rest_not_logged_in`	Authorization 헤더가 서버에서 잘림	`.htaccess`에 헤더 전달 규칙 추가
`403 rest_forbidden`	인증은 성공, 권한 부족	계정 역할 확인(구독자→작성자 이상)
`404 rest_no_route`	경로 오타 또는 REST 차단	엔드포인트 확인, 퍼머링크 저장

헤더가 잘리는 문제

rest_not_logged_in이 계속 나오면 서버가 Authorization 헤더를 PHP로 넘겨주지 않는 상황입니다. 아파치를 CGI나 FastCGI 방식으로 돌리는 환경에서 자주 발생합니다. 아이디와 비밀번호는 맞는데 워드프레스가 그걸 받아보지도 못하는 것이니, 문자열을 몇 번 다시 넣어도 해결되지 않습니다.

.htaccess 파일에 헤더를 환경변수로 넘겨주는 규칙을 추가하면 대부분 풀립니다. 워드프레스 설치 폴더의 .htaccess 최상단, # BEGIN WordPress 위에 넣으세요.

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

이게 안 통하면 아래를 대신 시도합니다.

RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [E=HTTP_AUTHORIZATION:%1]

.htaccess를 서버에서 직접 고쳐야 한다면 vi 편집기, 딱 이 10개 명령만 알면 서버에서 안 막힙니다가 도움이 됩니다. 둘 다 효과가 없으면 서버 설정에서 .htaccess 재정의가 막혀 있을 가능성이 큽니다. 이때는 호스팅 쪽에 “REST API Basic 인증용으로 Authorization 헤더가 PHP에 전달되도록 설정해 달라”고 요청하는 게 빠릅니다. Nginx + PHP-FPM 환경은 대개 이 문제가 없습니다.

보안 플러그인이 범인일 때

403 rest_forbidden은 성격이 다릅니다. 인증 자체는 성공했는데 그 계정에 권한이 없다는 뜻입니다. 구독자 계정으로 글을 쓰려 할 때 나옵니다. 계정 역할을 작성자 이상으로 올리면 해결됩니다.

404 rest_no_route는 엔드포인트 오타이거나 REST API가 막힌 경우입니다. /wp-json/wp/v2/posts를 /wp-json/v2/posts로 잘못 적는 실수가 흔합니다. 퍼머링크 구조 문제라면 설정 > 고유주소에서 아무것도 바꾸지 않고 ‘변경 사항 저장’만 눌러도 풀리는 경우가 있습니다.

Wordfence, iThemes Security(Solid Security) 계열은 XML-RPC 차단 옵션에 REST API 제한이 묶여 있는 경우가 있습니다. 플러그인을 잠깐 비활성화해서 curl 결과가 달라지는지 보면 범인을 특정할 수 있습니다. 코드 레벨에서 wp_is_application_passwords_available 필터로 기능을 껐다면 발급 영역 자체가 사라지니, 발급 UI가 안 보일 때는 이 필터도 의심 대상입니다.

운영하면서 지킬 것들

일단 돌아가기 시작하면 신경을 끄기 쉽습니다. 그런데 발급해 놓고 방치한 애플리케이션 비밀번호가 나중에 취약점이 됩니다. 몇 가지만 습관으로 만들어 두면 됩니다.

최소 권한 계정 분리

가장 효과가 큰 건 자동화 전용 계정을 따로 만들고 필요한 최소 권한만 주는 것입니다. 글 발행만 필요하면 작성자(Author) 권한으로 충분한 경우가 많습니다. 관리자 계정의 비밀번호가 유출되면 플러그인 설치나 사용자 추가까지 가능하지만, 작성자 계정이면 피해가 글 영역으로 제한됩니다.

쓰지 않는 항목은 즉시 폐기하세요. 발급 목록의 ‘취소’ 버튼 하나면 끝나고, 되돌릴 수 없으니 이름을 잘 확인하고 누르면 됩니다. 그리고 애플리케이션 비밀번호에는 만료 기한이 없습니다. 시스템이 알아서 무효화해 주지 않으니, 반년이나 1년 주기로 갈아끼우는 규칙을 스스로 정해 두는 편이 낫습니다. 참고로 사용자 계정을 삭제하면 그 계정에 딸린 애플리케이션 비밀번호도 전부 무효가 됩니다.

다른 인증 방식과 비교

REST API 인증에는 다른 선택지도 있습니다. 상황에 따라 갈리니 한 번 비교해 두면 판단이 쉽습니다.

항목	애플리케이션 비밀번호	JWT 플러그인	OAuth 2.0
설치	코어 내장(5.6+)	플러그인 설치·설정 필요	플러그인 + 앱 등록 필요
난이도	낮음	중간	높음
만료 관리	없음(수동 폐기)	토큰 만료·갱신 지원	만료·갱신·스코프 지원
권한 범위	계정 권한 전체	계정 권한 전체	스코프로 제한 가능
적합한 상황	내 도구, 서버 스크립트, 모바일 앱	프런트엔드 SPA, 토큰 갱신 필요	제3자 앱에 권한 위임

혼자 쓰는 자동화나 백업 도구라면 애플리케이션 비밀번호가 가장 합리적입니다. 별도 설치가 없고 폐기가 즉각적이니까요. 여러 사용자에게 권한을 나눠 주거나 토큰 수명을 관리해야 하는 서비스를 만든다면 JWT나 OAuth를 봐야 합니다.

자주 묻는 질문

애플리케이션 비밀번호를 잊어버렸는데 다시 볼 수 있나요?

볼 수 없습니다. 발급 직후 화면에 한 번만 표시되고, 데이터베이스에는 해시된 값만 남습니다. 워드프레스 자체도 원본 문자열을 모릅니다. 해당 항목을 폐기하고 새로 발급하는 것이 유일한 방법입니다. 이때 그 문자열을 쓰던 도구에도 새 값을 다시 넣어 줘야 합니다.

공백을 빼고 입력해도 되나요?

대부분 됩니다. 워드프레스가 인증 과정에서 공백을 제거하고 비교하기 때문입니다. 그래서 abcdEFGH1234ijklMNOP5678 형태로 붙여 써도 통과합니다. 다만 도구 쪽 입력 파싱이 의심되면 공백을 포함한 원본 그대로 다시 시도해 보세요. 어느 쪽이 되는지는 도구마다 다릅니다.

이걸로 wp-admin 로그인도 되나요?

안 됩니다. 애플리케이션 비밀번호는 REST API와 XML-RPC 같은 외부 인증 경로에서만 동작하도록 설계되어 있습니다. wp-login.php에 이 문자열을 넣으면 로그인이 거부됩니다. 유출됐을 때 관리 화면까지 넘어가지 않는다는 점이 이 방식의 장점 중 하나입니다.

2단계 인증을 켜뒀는데 쓸 수 있나요?

됩니다. 오히려 그럴 때 쓰라고 있는 기능입니다. 2FA 플러그인은 wp-login.php 흐름에 인증 코드 단계를 끼워 넣는데, 앱이나 스크립트는 그 화면을 처리할 방법이 없습니다. 애플리케이션 비밀번호는 별도 경로라서 2FA와 무관하게 통과합니다.

무료 호스팅에서도 되나요?

REST API를 막아두지 않았다면 됩니다. HTTPS 지원 여부와 /wp-json/ 접근 가능 여부가 관문입니다. 앞에서 쓴 curl -I https://example.com/wp-json/로 200이 오는지 먼저 확인하세요. 403이나 404가 오면 호스팅이나 보안 설정이 차단하고 있는 것이고, 이 경우 애플리케이션 비밀번호를 발급해도 쓸 수 없습니다.

정리: 순서대로 확인할 체크리스트

한 화면에서 되짚을 수 있게 순서만 압축했습니다.

사이트 주소가 https://인지 확인 — 아니면 발급 영역이 안 보입니다
curl -I https://example.com/wp-json/ 로 200 응답 확인
사용자 > 프로필 하단 ‘애플리케이션 비밀번호’에서 용도가 드러나는 이름으로 발급
표시된 24자 문자열을 즉시 복사 — 화면을 벗어나면 끝입니다
curl -u "아이디:문자열" .../wp-json/wp/v2/users/me 로 인증 테스트
rest_not_logged_in 이 나오면 .htaccess에 SetEnvIf Authorization 규칙 추가
통과하면 도구 설정 칸에 등록, 스크립트라면 환경변수로 분리
발급 목록에서 ‘마지막 사용’ 일시와 IP를 가끔 확인
쓰지 않는 항목은 취소 버튼으로 폐기

curl 테스트는 통과했는데 특정 도구에서만 실패한다면, 그 도구에 입력한 사이트 URL을 다시 보세요. 끝에 슬래시가 붙었는지, /wp-json까지 넣어야 하는 칸인지 아니면 도메인만 넣는 칸인지가 도구마다 다릅니다. 여기서 어긋나면 rest_no_route가 떨어집니다.

인증이 통했다면 다음은 실제로 API를 호출해 글을 올리는 단계입니다. 엔드포인트 구조와 본문 작성 방식은 워드프레스 REST API로 글 자동 등록하기, 인증부터 발행까지에서 이어집니다.