Power BI 새로 고침 실패: 게이트웨이·자격 증명·원본 점검
AI Editter
Power BI Desktop에서는 새로 고침이 되는데 서비스의 예약 새로 고침만 실패한다면, 같은 파일을 다시 게시하는 것부터 시작하지 마세요. Desktop은 내 PC의 경로·로그인·드라이버를 쓰고 서비스는 등록된 연결과 게이트웨이를 사용합니다. 실패 기록 → 연결 위치 → 자격 증명 → 데이터 형식과 처리량을 나눠 확인해야 재게시 후에도 반복되는 오류를 잡을 수 있습니다.
여기서는 가져오기 방식의 의미 체계 모델과 예약 새로 고침을 중심으로 설명합니다. DirectQuery의 조회 오류, 보고서 화면 갱신, 대시보드 타일 갱신은 같은 동작이 아닙니다.
1. 새로 고침 기록에서 실패 유형을 한 줄로 정리한다
Power BI 서비스의 작업 영역에서 의미 체계 모델을 찾고 새로 고침 기록을 엽니다. 최근 한 번만 보지 말고 마지막 성공 시각과 첫 실패 시각을 비교하세요. 오류 코드·실패 테이블·시작 및 종료 시각·Request ID 같은 진단 정보를 보관하되 연결 문자열과 개인정보는 공유 범위를 제한합니다.
| 기록의 특징 | 먼저 조사할 곳 | 추가로 비교할 변화 |
|---|---|---|
| 시작 직후 인증 실패 | 연결 자격 증명과 권한 | 암호 변경, 계정 잠금, 토큰 갱신 |
| 게이트웨이 연결 불가 | 게이트웨이 서비스·호스트·네트워크 | PC 절전, 재부팅, 프록시 변경 |
| 열 없음·형식 불일치 | 원본 스키마와 Power Query 단계 | 열 이름·날짜 형식·파일 양식 변경 |
| 오래 실행되다 timeout | 데이터 증가·원본 쿼리·리소스 | 처리 행 수, 동시 작업, 실행 시간 |
항목별 실제 오류의 의미는 Microsoft의 새로 고침 문제 해결 문서와 맞춰 봅니다. 모든 실패를 “게이트웨이 재설치”로 처리하면 원본 열 이름 변경 같은 원인은 남습니다.
2. 서비스에서 원본까지 도달하는 경로를 그린다
예를 들어 Desktop의 C:\Reports\sales.xlsx를 읽는 모델은 다른 서버에 설치된 게이트웨이에서 같은 경로가 존재하지 않을 수 있습니다. 개인 PC의 드라이브 문자와 게이트웨이 서비스가 접근하는 경로를 혼동하지 마세요. 공유 폴더를 쓴다면 게이트웨이가 실행되는 환경에서 경로와 서비스 계정 권한을 확인합니다.
- ① 의미 체계 모델의 Refresh 메뉴를 엽니다. 보고서 시각화의 새로 고침 버튼이 아니라 작업 영역의 해당 모델을 선택합니다.
- ② Schedule refresh를 선택합니다. 모델 설정으로 이동하면 Gateway and cloud connections에서 연결을 점검합니다. 아래 ③~⑦은 원인을 수정한 뒤 예약을 저장하는 순서입니다.
모델 설정의 Gateway and cloud connections에서 연결 상태와 매핑을 확인합니다. 게이트웨이가 온라인이어도 모델이 참조하는 서버·DB와 등록된 원본 정의가 맞지 않으면 사용할 수 없습니다. 하나의 모델에 여러 사내 원본이 있다면 일부만 등록해서는 충분하지 않습니다. 게이트웨이 문제 해결 문서에서 연결 정의와 원본 조건을 확인하세요.
3. 비밀번호를 바꾼 위치와 수정할 위치를 맞춘다
클라우드 원본의 로그인 정보는 모델 또는 연결 설정에서, 표준 게이트웨이로 관리되는 원본 자격 증명은 연결·게이트웨이 관리에서 수정할 수 있습니다. 회색으로 비활성화된 입력란이 보인다고 계정을 삭제할 필요는 없습니다. 연결의 소유자와 관리 권한을 확인해 실제로 자격 증명을 보관한 위치를 찾아야 합니다.
인증을 갱신한 뒤에는 해당 계정이 파일·폴더·DB 객체를 실제로 읽을 수 있는지도 검사합니다. 로그인 성공과 데이터 접근 권한은 다릅니다. 조직 계정 변경 후에는 원본 소유자, SharePoint 사이트 권한, 파일 이동 여부를 함께 점검하세요. 테스트 연결 성공 후 실제 새로 고침에서 실패할 수도 있으므로 최종 확인은 모델의 수동 새로 고침으로 합니다.
4. 엑셀 파일 한 개 때문에 전체 새로 고침이 멈추는 경우
폴더에서 여러 엑셀 파일을 합치는 모델을 예로 들면, 최신 파일 하나의 표 이름이 달라지거나 금액 열에 “미정”이 들어온 것만으로 변환 단계가 실패할 수 있습니다. 마지막 성공 이후 들어온 파일부터 비교하고 Power Query의 Applied Steps에서 어느 단계가 처음 실패하는지 확인하세요.
행을 모두 오류 무시로 처리하면 새로 고침은 성공해도 매출이 빠질 수 있습니다. 원본 파일명 열을 남겨 오류 행의 출처를 추적하고, 제외한 행 수와 금액 합계를 별도로 검증합니다. 기존 Power Query 폴더 파일 합치기 가이드의 스키마·중복 점검과 이어서 적용할 수 있습니다.
5. 성공 표시 이후에도 데이터 기준 시각을 확인한다
- ③ Time zone에서 시간대를 선택합니다. 한국 시각으로 운영한다면 UTC+09:00에 해당하는 시간대를 선택하고 표시명을 확인합니다. 화면 예시의 UTC를 그대로 사용하면 의도한 시각과 달라집니다.
- ④ 예약이 On인지 확인합니다. 꺼져 있을 때만 켭니다. 이미 On인 스위치를 다시 눌러 끄지 않도록 현재 상태를 읽으세요.
- ⑤ Refresh frequency에서 주기를 정합니다. 매일 실행할지 등 업무 주기에 맞게 선택합니다. 라이선스·용량에 따라 허용되는 예약 횟수가 다를 수 있습니다.
- ⑥ Time에서 실행 시각을 입력합니다. 시·분과 AM/PM을 함께 확인합니다. 한국 시간 오전 9시라면 ③에서 한국 시간대를 선택한 뒤 9:00 AM에 해당하도록 설정합니다.
- ⑦ Apply를 눌러 저장합니다. 설정을 다시 열어 값이 유지되는지 확인하고, 다음 예정 시각이 지난 뒤 Refresh history에서 실제 성공 여부를 확인합니다.
수동 새로 고침이 한 번 성공하면 예약이 활성화되어 있는지, 시간대와 예약 시간이 맞는지 확인합니다. 실패가 반복된 뒤에는 예약이 비활성화되어 있을 수 있습니다. 여러 모델이 같은 시각에 게이트웨이를 사용한다면 시간을 분산하고 원본 서버의 처리량도 함께 살펴보세요.
검증용 보고서에는 마지막 원본 데이터 시각, 수집 행 수, 핵심 합계를 두면 좋습니다. “새로 고침 완료”인데 어제 데이터가 보인다면 모델 갱신과 원본 파일 업데이트 시간을 따로 비교해야 합니다. 완료 조건은 수동 성공, 다음 예약 실행 성공, 기준 값 일치의 세 가지입니다. 게이트웨이 장애 알림만 받고 실제 데이터의 오래됨을 놓치지 않도록 운영 기준을 정해 두세요.