n8n에서 Gmail, Google Sheets, Notion 같은 앱을 연결하려고 했는데 로그인 화면 뒤에 오류가 나오거나, 연결이 끝난 뒤에도 노드가 실행되지 않는다면 OAuth 설정의 한 부분이 맞지 않는 경우가 많습니다. 이 글은 특정 서비스 하나의 설정법이 아니라, Redirect URL·앱 권한·테스트 사용자·재연결을 어떤 순서로 확인하면 좋은지 정리한 가이드입니다.
먼저 이해할 것: OAuth 오류는 ‘n8n 문제’로 단정할 수 없습니다
OAuth는 n8n과 외부 서비스가 함께 처리합니다. n8n에서는 연결에 필요한 정보를 만들고, 외부 서비스의 개발자 콘솔에서는 OAuth 앱과 허용 주소·권한을 등록합니다. 따라서 오류가 나면 “어느 화면에서 멈췄는지”부터 구분해야 합니다.
| 멈춘 위치 | 먼저 볼 곳 |
|---|---|
| 외부 로그인 화면으로 넘어가지 않음 | Client ID, 인증 방식, 브라우저 팝업 차단 여부 |
로그인 뒤 redirect_uri_mismatch 또는 400 오류 |
OAuth Redirect URL의 정확한 일치 여부 |
access_denied 또는 권한 거부 |
동의 화면, 테스트 사용자, 요청한 권한 범위 |
| 연결은 됐지만 노드 실행에서 실패 | 필요 API 활성화, 토큰 만료·재연결, 노드별 권한 |
1. 가장 먼저: Redirect URL을 n8n에서 복사해 그대로 등록
Redirect URL은 외부 서비스가 로그인 후 사용자를 다시 n8n으로 돌려보내는 주소입니다. 가장 흔한 오류는 이 주소를 기억에 의존해 직접 입력하거나, http/https, 도메인, 포트, 마지막 경로 중 하나를 다르게 등록하는 것입니다.
- n8n에서 연결하려는 노드의 Credential 생성 화면을 엽니다.
- OAuth Redirect URL을 복사합니다.
- 외부 서비스의 OAuth 앱 설정에서 Authorized redirect URIs 또는 비슷한 이름의 항목에 그대로 붙여 넣습니다.
- 저장한 뒤 n8n에서 새로 로그인을 시작합니다.
주소는 한 글자라도 다르면 안 됩니다. 특히 셀프호스팅 환경에서 내부 주소·포트가 보이거나, 도메인을 HTTPS로 바꾼 뒤 예전 주소가 남아 있을 때 오류가 자주 생깁니다. Redirect URL을 바꿨다면 기존 인증 창을 다시 쓰지 말고, n8n에서 연결 절차를 새로 시작하세요.
2. n8n Cloud와 셀프호스팅의 차이를 구분
n8n Cloud에서는 일부 Google 노드에 대해 Managed OAuth2를 지원합니다. 이 경우에는 Credential 화면에서 Google 로그인만으로 연결할 수 있어, 별도 Google Cloud 프로젝트와 Client ID·Secret 설정이 필요하지 않을 수 있습니다.
반면 셀프호스팅이거나 Managed OAuth2 대상이 아닌 노드라면 Custom OAuth2를 사용합니다. 이 경우에는 외부 서비스 콘솔에서 OAuth 앱을 만들고, Client ID와 Client Secret을 n8n Credential에 입력합니다. 셀프호스팅에서는 n8n이 보여 주는 Redirect URL이 외부에서 접근 가능한 실제 주소인지도 확인해야 합니다.
내 컴퓨터에서만 개발할 때는 localhost 주소가 허용되는 서비스도 있지만, 운영 환경에서는 서비스가 요구하는 HTTPS·도메인 규칙을 따라야 합니다. ‘개발용 로컬 주소’와 ‘실제 운영 도메인’을 같은 OAuth 앱에 섞어 등록하기 전에는 해당 서비스의 정책을 확인하세요.
3. Google 연결에서 특히 자주 놓치는 세 가지
OAuth 동의 화면과 테스트 사용자
Google OAuth 앱을 External로 만들고 아직 Testing 상태라면, 콘솔에 직접 추가한 테스트 사용자만 연결할 수 있습니다. 본인 계정으로도 권한 거부가 난다면 현재 로그인한 Google 계정이 테스트 사용자 목록에 들어 있는지부터 확인하세요.
필요 API 활성화
로그인은 완료됐는데 Gmail·Drive·Sheets 노드가 권한 또는 API 관련 오류를 내면, Google Cloud 프로젝트에서 해당 API를 활성화했는지 확인합니다. 예를 들어 Sheets 작업을 하려면 OAuth 앱만 만드는 것이 아니라 Google Sheets API도 필요할 수 있습니다.
권한 범위를 과하게 요청하지 않기
처음에는 자동화에 꼭 필요한 최소 권한만 요청하세요. 나중에 더 넓은 권한이 필요해졌다면 노드 설정과 OAuth 동의 화면의 범위를 함께 검토하고, 연결을 다시 승인합니다. 필요 이상으로 넓은 권한은 검토·보안 부담을 키우고 사용자를 불안하게 만들 수 있습니다.
4. 연결이 한 번 됐는데 다시 실패할 때
OAuth 연결이 처음에는 됐지만 나중에 실행에서 실패한다면, 다음 순서로 점검하세요.
- n8n Credential이 여전히 연결 상태인지 확인합니다.
- 외부 서비스 계정에서 n8n 앱 접근 권한을 철회하지 않았는지 확인합니다.
- Client Secret을 새로 발급하거나 OAuth 앱 설정을 바꿨다면 Credential을 다시 연결합니다.
- 노드가 실제로 필요한 계정·드라이브·스프레드시트에 접근할 권한을 갖는지 확인합니다.
- Executions에서 정확히 어떤 노드가 어떤 메시지로 실패했는지 확인합니다.
무작정 Credential을 여러 개 만들기보다, 기존 연결 하나의 오류 메시지와 OAuth 앱 설정을 비교하는 편이 원인을 찾기 쉽습니다. 단, Client Secret이 노출됐다고 판단되면 기존 값을 폐기하고 새로 발급한 뒤 Credential을 교체해야 합니다.
5. 증상별 빠른 해결 표
| 증상 | 우선 조치 |
|---|---|
redirect_uri_mismatch |
n8n Credential의 Redirect URL을 다시 복사하고, 외부 콘솔의 허용 주소를 완전히 동일하게 수정 |
| ‘앱이 검증되지 않음’ 또는 접근 거부 | 동의 화면 상태·테스트 사용자·요청 범위를 점검 |
| 로그인 후 빈 화면 또는 연결이 끝나지 않음 | 팝업 차단 여부, 현재 로그인 계정, Redirect URL과 앱 유형 확인 |
| 연결 성공 후 API 오류 | 필요 API 활성화와 노드별 권한·대상 리소스 접근 권한 확인 |
| 셀프호스팅에서 내부 주소가 보임 | 외부 공개 주소·HTTPS·리버스 프록시·n8n 기본 URL 설정을 배포 방식에 맞게 점검 |
연결 전에 지켜야 할 보안 원칙
Client Secret, OAuth 코드, 액세스 토큰은 글·스크린샷·채팅에 복사하지 마세요. 화면을 공유할 때는 Credential 값과 토큰, 실행 기록 속 개인정보를 가립니다. 실제 고객 데이터로 첫 테스트를 하기보다, 본인 계정과 테스트용 파일·행을 써서 연결부터 검증하는 편이 안전합니다.
정리: 한 번에 모두 고치지 말고 경계를 나눕니다
OAuth 연결 오류는 대개 복잡해 보이지만, n8n이 보여 준 Redirect URL → 외부 콘솔의 허용 주소 → 로그인 계정·권한 → 노드 실행 기록 순서로 보면 해결 범위가 작아집니다. 먼저 n8n에서 표시한 값을 그대로 등록하고, 그 다음에 권한과 API를 확인하세요. 연결이 끝난 뒤에는 작은 테스트 데이터 한 건으로 노드 실행까지 검증하는 것이 좋습니다.
참고: n8n Google OAuth2 single service 공식 문서, n8n Google credentials 개요, n8n HTTP Request OAuth2 credentials 문서