OneDrive 「파일 온디맨드」와 업무 앱 ── 플레이스홀더가 깨뜨리는 전제와 대책

「데스크톱에 저장한 CSV를 업무 앱이 읽지 못한다」, 「지금까지 잘 되던 가져오기 처리가 PC를 바꾼 뒤에 『파일을 찾을 수 없습니다』로 실패한다」, 「탐색기에는 파일이 보이는데 앱에서 열면 오류가 난다」── 최근 몇 년, 고객으로부터 이런 상담이 단골이 되었습니다.

조사해 보면 원인은 앱의 버그가 아니라, OneDrive의 「데스크톱·문서 자동 백업」(알려진 폴더 이동, KFM)과 「파일 온디맨드」인 경우가 적지 않습니다. 데스크톱의 실체는 C:\Users\<사용자명>\OneDrive\데스크톱으로 옮겨져 있고, 거기에 보이는 파일의 일부는 로컬에 실체가 없는 「플레이스홀더」입니다. 사용자도 정보시스템도 이 변화를 알아채지 못한 채 PC를 쓰고 있습니다.

즉 「로컬 디스크에 파일이 있다」는 업무 앱의 암묵적 전제가, 어느새 「파일은 클라우드에 있고 로컬에는 겉모습만 있다」는 전제로 바뀌어 있는 것입니다. 이 글에서는 중소기업 정보시스템 담당자와 Windows 앱 개발자를 대상으로, 플레이스홀더의 구조, 파일 속성으로 상태를 판정하는 방법, 업무 앱이 빠지기 쉬운 전형적인 함정, 개발 측·정보시스템 측 각각의 대책, 그리고 「파일이 읽히지 않는다」는 상담을 받았을 때의 원인 분리 절차까지를 Microsoft Learn의 1차 자료를 바탕으로 정리합니다.

flowchart TB
    accTitle: 업무 앱의 암묵적 전제가 바뀌는 모습
    accDescr: 로컬 디스크에 파일이 있다는 업무 앱의 암묵적 전제가, 어느새 실체는 클라우드에 있고 로컬에는 겉모습만 있다는 전제로 바뀌어 있다
    before["기존의 암묵적 전제"] --> b1["로컬 디스크에 실체"]
    after["바뀐 전제"] --> a1["실체는 클라우드에 있다"]
    a1 --> a2["로컬에는 겉모습만"]
    a2 -.-> note["플레이스홀더"]

그림 1: 「로컬에 실체가 있다」는 전제는, 어느새 「실체는 클라우드, 로컬은 겉모습만」으로 바뀌어 있다.

1. 먼저 결론

• 데스크톱·문서·그림은 KFM으로 C:\Users\<사용자명>\OneDrive\ 아래로 이동해 있는 경우가 있습니다. 새 PC 초기 설정에서 켜지기 쉽고, 조직에서는 정책으로 일괄 적용할 수도 있습니다. 고정 경로를 전제로 한 앱은 여기서 깨집니다.¹
• 파일 온디맨드는 현재 동기화 앱에서 기본으로 켜져 있습니다. 다른 장치나 Web에서 만든 파일은 로컬에 실체가 없는 「온라인 전용」 플레이스홀더로 보입니다.²³
• 플레이스홀더의 정체는 Cloud Files API(cldflt.sys 미니필터)가 관리하는 재분석 지점입니다. 탐색기와 파일 API 양쪽에서 평범한 파일로 보이고, 열면 자동으로 다운로드(하이드레이션)됩니다.⁴
• 상태는 파일 속성으로 판정할 수 있습니다. FILE_ATTRIBUTE_OFFLINE, RECALL_ON_DATA_ACCESS, PINNED, UNPINNED 등이 표식이며, attrib에서는 O·P·U 글자로 보입니다. 속성 확인만으로는 다운로드가 발생하지 않습니다.⁵⁶⁷
• 업무 앱의 전형적인 사고는 「열리지 않음」「느림」「속성 오판」「감시 이벤트 폭풍」「동기화와의 충돌」의 조합입니다. 오프라인이거나 OneDrive가 중지되면 하이드레이션이 실패하고, 일괄 처리는 모든 파일의 다운로드를 유발합니다.⁴⁸
• 앱 측 대책은 「플레이스홀더를 존중하는 것」입니다. 열거 시 속성으로 판정하고 함부로 열지 않기, 필요하면 FILE_FLAG_OPEN_NO_RECALL을 쓰기, 데이터 폴더를 OneDrive 아래에 두지 않기가 기본입니다.⁹¹⁰
• 정보시스템 측 대책은 「핀 운용」과 「정책으로 통제」입니다. 업무 폴더는 「이 장치에 항상 유지」로 실체를 보장하고, KFM과 파일 온디맨드는 그룹 정책/Intune으로 의도적으로 구성합니다. 스토리지 센스가 「쓰지 않는 파일을 온라인 전용으로 되돌리는」 동작도 한다는 점을 잊지 마십시오.¹¹¹²

한 문장으로 정리하면, 「탐색기에 보이는 파일」과 「로컬 디스크에 실체가 있는 파일」은 더 이상 같지 않다는 것입니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 16건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 무엇이 일어나고 있는가 ── KFM과 파일 온디맨드

2.1. 데스크톱은 더 이상 C:\Users\<사용자명>\Desktop이 아닐 수 있다

OneDrive 동기화 앱에는 「알려진 폴더 이동」(Known Folder Move, KFM)이라는 기능이 있습니다. 설정 화면에서는 「백업」, 「중요한 폴더를 백업」 등으로 표시되며, 켜면 데스크톱·문서·그림의 실체가 OneDrive 폴더 아래로 이동(리디렉트)됩니다.¹

새 PC의 초기 설정(OOBE)에서 Microsoft 계정이나 회사 계정으로 로그인하면 폴더 백업이 기본으로 제안되고, 그대로 진행하면 켜지는 구성이 널리 퍼져 있습니다. 조직에서는 「Windows의 알려진 폴더를 OneDrive로 자동 이동」(KFMSilentOptIn) 정책으로 사용자에게 아무것도 묻지 않고 일괄 적용할 수도 있습니다.¹¹¹

flowchart TB
    accTitle: KFM이 켜지는 두 경로
    accDescr: 새 PC의 초기 설정에서 계정으로 로그인하면 폴더 백업이 기본으로 제안되고 그대로 진행하면 켜지며, 조직에서는 KFMSilentOptIn 정책으로 사용자에게 아무것도 묻지 않고 일괄 적용된다
    oobe["새 PC의 초기 설정"] --> signin["계정으로 로그인"]
    signin --> prompt["백업을 기본으로 제안"]
    prompt --> on1["그대로 진행하면 켜짐"]
    org["조직의 정책"] --> silent["KFMSilentOptIn"]
    silent --> on2["사용자에게 묻지 않고 일괄 적용"]
    on1 --> kfm["KFM 켜짐"]
    on2 --> kfm

그림 2: KFM은 초기 설정의 기본 제안이거나 조직의 자동 적용 정책으로, 알아채지 못한 채 켜진다.

까다로운 점은 탐색기에서의 겉모습이 거의 바뀌지 않는다는 것입니다. 셸의 알려진 폴더 API(SHGetKnownFolderPath나 .NET의 Environment.GetFolderPath)는 이동 뒤의 올바른 경로를 반환하므로, 규칙을 지켜 작성한 앱은 계속 동작합니다. 깨지는 것은 C:\Users\%USERNAME%\Desktop 같은 고정 경로를 설정 파일이나 코드에 박아 넣은 앱입니다. PC를 바꾼 뒤에 가져오기 처리가 「파일을 찾을 수 없습니다」로 실패하는 전형적인 패턴이 바로 이것입니다.

flowchart TB
    accTitle: KFM 이후 앱의 경로 해석은 어떻게 되는가
    accDescr: KFM으로 데스크톱 등의 실체가 OneDrive 아래로 이동한 뒤, 알려진 폴더 API를 쓰는 앱은 이동 뒤의 올바른 경로를 얻어 계속 동작하지만, 고정 경로를 박아 넣은 앱은 파일을 찾을 수 없습니다로 실패한다
    kfm["KFM 켜짐"] --> move["데스크톱 등의 실체가 OneDrive 아래로 이동"]
    move --> how{"앱의 경로 해석은?"}
    how -->|알려진 폴더 API| ok["이동 뒤의 올바른 경로를 얻어 동작 지속"]
    how -->|고정 경로 하드코딩| ng["파일을 찾을 수 없습니다"]

그림 3: KFM 이후에도 알려진 폴더 API를 쓰는 앱은 계속 동작하지만, 고정 경로를 하드코딩한 앱은 여기서 깨진다.

2.2. 파일 온디맨드 ── 보이는데 실체가 없다

또 하나의 주역이 「파일 온디맨드」(Files On-Demand)입니다. 켜진 환경에서는 OneDrive의 모든 파일이 탐색기에 보이지만, 내용은 열릴 때까지 다운로드되지 않습니다. 이 기능은 현재 동기화 앱에서 기본으로 켜져 있으며, Microsoft도 켠 채로 운용할 것을 권장합니다.²³

상태는 탐색기의 상태 아이콘으로 구분합니다.¹³

여기서 중요한 것은 가운데 상태입니다. 한 번 열어 로컬에 실체가 생긴 파일도, 사용자의 「공간 확보」 조작이나 뒤에서 다룰 스토리지 센스에 의해 다시 온라인 전용으로 돌아갈 수 있습니다. 「지난달에는 됐는데」라는, 재현하기 어려운 장애의 한 원인입니다.³¹²

stateDiagram-v2
    accTitle: 파일 온디맨드의 3상태와 전이
    accDescr: 온라인 전용 파일은 열면 로컬에서 사용 가능해지지만, 공간 확보 조작이나 스토리지 센스로 다시 온라인 전용으로 돌아가며, 핀한 파일만 자동 해제 대상 밖이 된다
    s1: 온라인 전용(구름 표시)
    s2: 로컬에서 사용 가능
    s3: 핀(이 장치에 항상 유지)
    s1 --> s2: 열기(하이드레이션)
    s2 --> s1: 공간 확보
    s2 --> s1: 스토리지 센스
    s1 --> s3: 이 장치에 항상 유지
    s2 --> s3: 이 장치에 항상 유지
    s3 --> s2: 핀 해제

그림 4: 파일 온디맨드의 3상태. 「로컬에서 사용 가능」은 자동으로 온라인 전용으로 돌아갈 수 있지만, 핀은 대상 밖이다.

3. 플레이스홀더의 정체 ── Cloud Files API와 재분석 지점

파일 온디맨드는 Windows 10 버전 1709에서 도입된 Cloud Files API(클라우드 파일 API)라는 OS 메커니즘 위에 구현되어 있습니다. 파일 시스템 측의 실무 부대는 cldflt.sys(서비스 이름 CldFlt, 「Windows Cloud Files Filter Driver」)라는 파일 시스템 미니필터이며, OneDrive는 이 API를 쓰는 「동기화 공급자」의 하나입니다.⁴⁷

플레이스홀더는 기술적으로 재분석 지점입니다. 파일 시스템 위에는 파일 이름·크기·타임스탬프 같은 메타데이터(약 1KB)만 있고, 내용 데이터는 없습니다. 앱이 파일을 열어 읽으면 미니필터가 요청을 감지해 동기화 공급자에게 데이터 전송을 지시하고, 다운로드가 끝날 때까지 기다린 뒤에 읽기가 진행됩니다. 이 가져오기를 하이드레이션, 반대로 로컬의 실체를 버리고 플레이스홀더로 되돌리는 일을 디하이드레이션이라고 합니다.⁴

sequenceDiagram
    accTitle: 플레이스홀더를 열었을 때의 하이드레이션
    accDescr: 앱이 플레이스홀더를 열어 읽으면 cldflt.sys 미니필터가 요청을 감지해 동기화 공급자에게 데이터 전송을 지시하고, 다운로드가 끝날 때까지 기다린 뒤에 읽기가 진행된다
    participant app as 업무 앱
    participant flt as cldflt.sys 미니필터
    participant sync as 동기화 공급자
    app->>flt: 열어 읽기 요청
    flt->>sync: 데이터 전송을 지시
    sync-->>flt: 다운로드 완료
    flt-->>app: 읽기가 진행됨

그림 5: 플레이스홀더 읽기는 미니필터가 동기화 공급자에게 데이터를 가져오게 한 뒤에 진행된다.

재분석 지점이라는 말을 들으면 「재분석 지점을 감지하면 특별 취급하는」 기존 코드와의 궁합이 걱정되지만, Cloud Files API는 호환을 위해 동기화 엔진과 %systemroot% 아래 프로세스 외에는 재분석 지점이라는 사실을 숨깁니다. 평범한 앱에서는 「열기만 조금 느린 평범한 파일」로 보이는 셈입니다. 이 철저한 투명성이 편리함과 동시에, 「앱이 알아채지 못한 채 전제가 깨지는」 원인이기도 합니다.⁴ 재분석 지점 자체의 구조는 「NTFS의 내부 구조」에서 설명합니다.

flowchart TB
    accTitle: 재분석 지점의 은폐와 보이는 모습의 차이
    accDescr: 플레이스홀더의 정체는 재분석 지점이지만 Cloud Files API는 동기화 엔진 등 이외의 프로세스에는 그 사실을 숨기므로, 평범한 앱에서는 열기만 조금 느린 평범한 파일로 보인다
    ph["플레이스홀더(재분석 지점)"] --> who{"연 프로세스는?"}
    who -->|동기화 엔진 등| raw["재분석 지점으로 보인다"]
    who -->|그 외 앱| plain["평범한 파일로 보인다"]
    plain -.-> note["열기만 조금 느려 보인다"]

그림 6: 재분석 지점이라는 사실은 동기화 엔진 등 외에는 숨겨지고, 평범한 앱에는 평범한 파일로 보인다.

탐색기 속성에서 보면 플레이스홀더는 「크기」에는 원래 크기가 표시되는데 「디스크 할당 크기」는 거의 0이라는 특징적인 모습을 보입니다. 「크기가 있으니 실체도 있을 것」이라는 생각은 여기서는 통하지 않습니다.

flowchart TB
    accTitle: 플레이스홀더 속성의 보이는 모습
    accDescr: 플레이스홀더는 탐색기 속성에서 크기에는 원래 크기가 표시되는데 디스크 할당 크기는 거의 0이 되어, 크기가 있으니 실체도 있을 것이라는 생각이 통하지 않는다
    prop["플레이스홀더의 속성"] --> size["크기는 원래 크기"]
    prop --> disk["디스크 할당 크기는 거의 0"]
    size -.-> trap["실체가 있을 것이라는 생각"]
    disk -.-> truth["로컬에 실체는 없다"]

그림 7: 플레이스홀더는 「크기」에 원래 크기가 나오는데 「디스크 할당 크기」는 거의 0이라는 모습을 보인다.

4. 파일 속성으로 상태가 드러난다

플레이스홀더의 상태는 일반적인 파일 속성으로 공개되어 있습니다. 주요한 것은 다음과 같습니다.⁵

명령 프롬프트의 attrib 명령은 이를 한 글자로 표시·설정할 수 있습니다. O가 오프라인 속성, P가 핀, U가 핀 해제입니다.⁶ OneDrive의 파일 온디맨드 상태와의 대응은 Microsoft 문서에서 다음과 같이 정리되어 있습니다.⁷

주의가 하나 있습니다. 상태 전환에는 순서가 있습니다. 온라인 전용(U) 파일을 「로컬에서 사용 가능」으로 만들고 싶을 때 -p만 실행해도 U가 붙은 채로 실체는 가져와지지 않습니다. Microsoft 문서도 일단 +p(항상 사용 가능)로 실체를 다운로드하게 한 뒤 -p하는 절차를 보여 줍니다.⁷ 기존 상태를 확실히 바꾸는 스크립트에서는 attrib +p -u처럼 반대쪽 속성도 동시에 떼는 편이 안전합니다.

flowchart TB
    accTitle: 온라인 전용에서 로컬에서 사용 가능으로 바꾸는 순서
    accDescr: 온라인 전용 파일에 attrib -p만 실행해도 U 속성이 남아 실체는 가져와지지 않으며, 먼저 attrib +p로 실체를 다운로드하게 한 뒤 -p하는 절차가 필요해진다
    u["온라인 전용(U)"] -->|attrib -p만| stay["U인 채로 실체는 가져와지지 않음"]
    u -->|attrib +p| pin["핀(실체를 다운로드)"]
    pin -->|attrib -p| local["로컬에서 사용 가능"]

그림 8: 온라인 전용에서의 전환은 먼저 +p로 실체를 가져온 뒤 -p하는 순서가 필요하다. PowerShell로 판정하는 예입니다. 속성만 보면 하이드레이션은 발생하지 않으므로, 조사나 일괄 확인에 안심하고 쓸 수 있습니다.

function Test-CloudPlaceholder {
    param([Parameter(Mandatory)][string]$Path)

    $value = [int](Get-Item -LiteralPath $Path -Force).Attributes

    [pscustomobject]@{
        Path               = $Path
        Offline            = ($value -band 0x00001000) -ne 0  # FILE_ATTRIBUTE_OFFLINE
        RecallOnDataAccess = ($value -band 0x00400000) -ne 0  # 내용이 전부 로컬에 있지 않음
        Pinned             = ($value -band 0x00080000) -ne 0  # 이 장치에 항상 유지
        Unpinned           = ($value -band 0x00100000) -ne 0  # 온라인 전용
    }
}

# 문서 폴더 아래 CSV를 일괄 확인(내용은 다운로드되지 않음).
# 경로는 알려진 폴더 API로 해석한다. 「문서」라는 표시 이름을 하드코딩하면,
# 실제 폴더 이름이 영어(Documents)인 환경이나 KFM 구성에 따라서는 존재하지 않는 경로가 된다
Get-ChildItem ([Environment]::GetFolderPath('MyDocuments')) -Recurse -Filter *.csv |
    ForEach-Object { Test-CloudPlaceholder $_.FullName } |
    Where-Object RecallOnDataAccess |
    Format-Table -AutoSize

[int]로 캐스트하는 이유는 .NET의 FileAttributes 열거형에 RECALL_ON_DATA_ACCESS 같은 이름이 정의되어 있지 않기 때문입니다. 숫자로 비트 연산하면 문제 없이 판정할 수 있습니다.

5. 업무 앱이 빠지는 함정

여기부터가 본론입니다. 플레이스홀더의 투명성은 평소에는 편리하지만, 업무 앱의 전형적인 처리 패턴과 겹치면 다음 여섯 가지 형태로 표면화합니다.

5.1. 열면 자동으로 다운로드가 돈다 ── 오프라인에서 「열리지 않음」

온라인 전용 파일을 열면 그 자리에서 하이드레이션이 시작됩니다. 온라인이고 작은 파일이면 알아채지 못할 속도지만, OneDrive가 중지·로그아웃·일시 중지된 때, 네트워크가 불안정한 때, 파일이 큰 때는 「존재하는데 열리지 않는 파일」이 됩니다. 오류는 ERROR_CLOUD_FILE_PROVIDER_NOT_RUNNING(0x8007016A, 「클라우드 파일 공급자가 실행되고 있지 않습니다」) 같은 클라우드 파일 계열 코드로 돌아오기도 하고, 앱 측 타임아웃으로 관측되기도 합니다.⁸

더 함정인 것은 File.Exists()에 해당하는 존재 확인이나 속성·크기 조회는 성공한다는 점입니다. 「존재 확인은 통과했는데 읽기에서 실패한다」는, 로컬 디스크의 감각으로는 설명이 안 되는 오류 패턴이 됩니다.

flowchart TB
    accTitle: 온라인 전용 파일 접근의 분기
    accDescr: 존재 확인이나 속성·크기 조회는 성공하지만, 내용 읽기는 하이드레이션이 시작되고, OneDrive가 가동 중이고 네트워크가 정상이면 읽을 수 있으나 그렇지 않으면 0x8007016A 등의 오류나 타임아웃으로 실패한다
    check["존재 확인·속성이나 크기 조회"] --> ok1["성공한다"]
    open["내용 읽기"] --> hyd["하이드레이션 시작"]
    hyd --> cond{"OneDrive 가동 중이고 네트워크 정상?"}
    cond -->|예| read["다운로드 후 읽을 수 있음"]
    cond -->|아니요| err["0x8007016A 등의 오류나 타임아웃"]

그림 9: 존재 확인은 성공하는데 읽기에서 실패할 수 있다. 성패는 OneDrive 가동 상태와 네트워크에 달려 있다.

5.2. 일괄 처리가 모든 파일의 다운로드를 유발한다

폴더 안의 모든 파일을 읽는 배치 처리, 해시 계산, 전문 검색, 독자 백업 처리 등을 OneDrive 아래에 겨누면, 건드린 파일 전부의 하이드레이션이 유발됩니다. 수 GB짜리 폴더라면 처리가 비정상적으로 느려질 뿐 아니라, 다운로드로 디스크를 압박하고, 용량이 작은 PC에서는 빈 공간 부족이 다른 장애를 부릅니다. 파일 온디맨드로 아끼려던 용량이 한 번의 전체 스캔으로 사라지는 셈입니다.

덧붙여, 사용자의 명시적 조작 없이 앱이 하이드레이션을 일으키면 Windows가 토스트 알림을 띄워 사용자에게 차단 선택지를 주는 경우가 있습니다. 여기서 차단되면 그 앱은 이후 다운로드에 계속 실패합니다(설정의 「파일 자동 다운로드」에서 해제할 수 있습니다). 「특정 PC에서만 가져오기가 실패한다」의 한 원인입니다.⁴

flowchart TB
    accTitle: 일괄 처리가 모든 파일의 다운로드를 유발하는 흐름
    accDescr: OneDrive 아래로의 일괄 처리는 건드린 모든 파일의 하이드레이션을 유발해 처리 지연과 디스크 압박을 부르고, 나아가 토스트 알림에서 사용자가 차단하면 이후 다운로드에 계속 실패한다
    scan["OneDrive 아래로의 일괄 처리"] --> touch["건드린 모든 파일을 하이드레이션"]
    touch --> cost["처리 지연과 디스크 압박"]
    touch --> toast["토스트 알림이 나올 수 있음"]
    toast --> block{"사용자가 차단?"}
    block -->|예| fail["이후 다운로드에 계속 실패"]
    block -->|아니요| cont["다운로드는 계속"]

그림 10: 일괄 처리는 모든 파일의 하이드레이션을 유발하고, 토스트 알림에서 차단되면 이후 실패가 이어진다.

5.3. 속성을 전제하지 않은 코드의 오동작

FILE_ATTRIBUTE_OFFLINE이나 RECALL_ON_DATA_ACCESS를 모르는 코드는 뜻밖의 곳에서 오동작합니다.

• 속성을 완전 일치로 판정하므로(attributes == FileAttributes.Archive 등) 플레이스홀더가 「예상 밖 파일」로 제외·오류 처리된다
• 백업·동기화 계열 도구의 제외 판정이 OFFLINE 속성을 「테이프에 이미 보관됨」으로 해석하고 건너뛴다(또는 반대로, 제외해야 하는데 모든 파일을 가져온다)
• 읽기 전용 검사나 아카이브 비트 조작이 속성 조합을 깨뜨린다

flowchart TB
    accTitle: 속성을 전제하지 않은 코드의 오동작 패턴
    accDescr: 플레이스홀더 속성을 모르는 코드는 완전 일치 속성 판정에 의한 제외나 오류 처리, OFFLINE 속성의 오해석에 의한 건너뛰기나 전 파일 가져오기, 속성 조합의 파괴라는 형태로 오동작한다
    code["속성을 전제하지 않은 코드"] --> m1["완전 일치 판정"]
    code --> m2["OFFLINE을 오해석"]
    code --> m3["속성 조작으로 조합을 깨뜨림"]
    m1 --> r1["예상 밖으로 제외나 오류"]
    m2 --> r2["건너뛰기 또는 전량 가져오기"]

그림 11: OFFLINE이나 RECALL 계열 속성을 모르는 코드는 제외·잘못된 건너뛰기·속성 파괴의 형태로 오동작한다.

Microsoft는 미니필터 개발자용 지침에서, RECALL_ON_DATA_ACCESS가 붙은 파일에 함부로 읽기·쓰기를 내지 말라고 명시합니다. 커널 드라이버를 대상으로 한 문서이지만, 「이 속성이 붙은 파일의 내용에 손을 대는 것 = 가져오기 비용이 발생한다」는 원칙은 사용자 모드 앱에도 그대로 해당합니다.¹⁰

5.4. FileSystemWatcher와 동기화의 상호작용

OneDrive 아래 폴더를 FileSystemWatcher로 감시하면, 사용자 조작뿐 아니라 동기화 앱 활동에 의한 이벤트도 대량으로 도착합니다. 다른 장치에서의 변경이 동기화될 때마다, 하이드레이션·디하이드레이션으로 속성이나 크기가 바뀔 때마다 Changed 이벤트가 발생할 수 있습니다. 나아가 감시해서 가져온 결과를 같은 폴더에 다시 쓰는 설계라면, 쓰기→업로드→속성 갱신→재이벤트라는 루프로 「변경 알림의 폭풍」이 됩니다. 이벤트 솎기와 실체 확인의 설계는 「FileSystemWatcher 실무 가이드」에서 다룬 그대로이지만, OneDrive 아래에서는 그 필요성이 한 단계 높아집니다.

flowchart TB
    accTitle: 감시와 되쓰기에 의한 변경 알림 루프
    accDescr: 변경 이벤트를 받은 감시 앱이 가져오기 결과를 같은 폴더에 되쓰면, 동기화 앱의 업로드와 속성 갱신이 다시 이벤트를 발생시켜 변경 알림의 폭풍이라는 루프가 된다
    ev["변경 이벤트"] --> proc["감시 앱이 가져오기"]
    proc --> write["같은 폴더에 되쓰기"]
    write --> up["동기화 앱이 업로드"]
    up --> attr["속성이나 크기가 갱신됨"]
    attr --> ev
    sync["다른 장치 변경의 동기화"] -.-> ev

그림 12: 가져오기 결과를 같은 폴더에 되쓰면, 동기화 앱의 활동이 재이벤트를 만드는 루프가 된다.

5.5. 배타 잠금 중의 동기화 충돌과 「복사」 파일

업무 앱이 파일을 배타 잠금으로 연 동안, 동기화 앱은 그 파일을 업로드도 갱신도 할 수 없습니다. 오래 잠금을 쥐는 앱(Access의 .accdb, 독자 형식의 데이터 파일, 로그 파일 등)을 OneDrive 아래에 두면 동기화 오류가 일상화됩니다. 반대로 여러 PC에서 같은 파일을 편집하면, 동기화 앱은 양쪽 판을 남기려 해서 PC 이름이 붙은 중복 파일이나 「~의 복사본」 같은 충돌 복사본을 만듭니다. 가져오기 처리가 「한 폴더 한 파일」을 전제로 하면 이 중복 파일에서 오동작합니다. 잠금 설계의 기본은 「파일 연계의 배타 제어 기초 지식」을 참조하십시오.

flowchart TB
    accTitle: 배타 잠금과 여러 PC 편집이 부르는 동기화 문제
    accDescr: 앱이 배타 잠금으로 연 동안은 동기화 앱이 갱신하지 못해 동기화 오류가 일상화되고, 여러 PC에서 같은 파일을 편집하면 충돌 복사본이 생성되어 한 폴더 한 파일 전제가 무너진다
    lock["앱이 배타 잠금으로 연다"] --> nosync["동기화하지 못해 동기화 오류가 일상화"]
    multi["여러 PC에서 같은 파일을 편집"] --> conflict["충돌 복사본을 생성"]
    conflict --> dup["PC 이름 붙음이나 「복사본」의 중복 파일"]
    dup --> bad["한 폴더 한 파일 전제가 무너짐"]

그림 13: 배타 잠금은 동기화 오류를 일상화하고, 여러 PC에서의 편집은 충돌 복사본에 의한 오동작을 부른다.

5.6. 바이러스 백신·검색 인덱서가 하이드레이션을 유발한다

파일 내용을 읽는 것은 업무 앱만이 아닙니다. 바이러스 백신의 전체 검사나 검색 인덱서도 플레이스홀더 내용에 손을 대면 하이드레이션을 유발합니다. Microsoft Defender 등은 RECALL_ON_DATA_ACCESS 속성이 붙은 파일을 주문형 검사 때 건너뛰는 구현이지만, 이는 제품 측 대응이며 모든 보안 제품이 같은 배려를 해 준다고는 할 수 없습니다. 「야간 검사마다 네트워크와 디스크가 꽉 찬다」, 「온라인 전용으로 두었던 파일이 다음날 아침 전부 실체화되어 있다」 같은 증상이 나오면 이 선을 의심합니다.¹⁴

flowchart TB
    accTitle: 보안 제품이나 검색 인덱서에 의한 하이드레이션 유발
    accDescr: 전체 검사나 검색 인덱서가 플레이스홀더 내용에 손을 댈 때, RECALL 속성을 배려하는 제품은 건너뛰지만, 배려하지 않는 제품은 모든 파일을 하이드레이션해 야간 대역 압박이나 아침 실체화를 부른다
    av["전체 검사나 검색 인덱서"] --> care{"RECALL 속성을 배려?"}
    care -->|배려하는 제품| skip["플레이스홀더를 건너뜀"]
    care -->|배려하지 않는 제품| hyd["내용에 손을 대어 하이드레이션"]
    hyd --> sym1["야간에 대역과 디스크가 꽉 참"]
    hyd --> sym2["아침이면 파일이 전부 실체화"]

그림 14: 속성을 배려하지 않는 검사는 모든 파일의 하이드레이션을 유발하고, 야간 부하나 아침 실체화로 나타난다.

6. 앱 개발 측의 대책 ── 플레이스홀더를 존중한다

개발자로서의 기본 방침은 플레이스홀더를 「깨진 파일」이 아니라 「가져오기 비용이 있는 파일」로 다루는 것입니다.

• 열거 시 속성으로 판정하고, 함부로 열지 않는다. 폴더 스캔에서는 먼저 속성(4장의 판정)으로 온라인 전용인지를 확인하고, 내용이 필요한 파일만 엽니다. 로그 수집·해시 계산·미리보기 생성처럼 「없어도 치명적이지 않은」 처리에는 플레이스홀더를 건너뛰는 선택지를 둡니다.

// .NET의 FileAttributes에 정의되지 않은 값은 숫자로 정의한다
const FileAttributes RecallOnDataAccess = (FileAttributes)0x00400000;
const FileAttributes RecallOnOpen       = (FileAttributes)0x00040000;

static bool IsCloudPlaceholder(FileAttributes attributes) =>
    (attributes & (RecallOnDataAccess | RecallOnOpen | FileAttributes.Offline)) != 0;

foreach (var file in new DirectoryInfo(watchFolder).EnumerateFiles("*.csv"))
{
    if (IsCloudPlaceholder(file.Attributes))
    {
        log.Warn($"{file.Name} 은(는) 온라인 전용이므로 이번에는 처리를 건너뜁니다");
        continue;
    }
    Import(file.FullName);
}

flowchart TB
    accTitle: 열거 시 속성으로 판정한 뒤에 여는 흐름
    accDescr: 폴더 스캔에서는 먼저 열거로 속성을 확인하고, 플레이스홀더면 건너뛰고 경고 로그를 남기며, 그렇지 않은 파일만 가져오기 처리를 실행해 함부로 하이드레이션하지 않는다
    enum["열거로 속성을 확인"] --> ph{"플레이스홀더?"}
    ph -->|예| skip["건너뛰고 경고 로그"]
    ph -->|아니요| imp["가져오기 처리를 실행"]
    skip -.-> note["내용이 필요한 파일만 여는 방침"]

그림 15: 열거 시 속성으로 판정하고, 플레이스홀더는 열지 않고 건너뛰어 함부로 하이드레이션하지 않는다.

• FILE_FLAG_OPEN_NO_RECALL은 「다운로드하지 않는다」는 보장이 아니라는 점에 주의한다. CreateFile에 이 플래그를 지정하면 「가져온 데이터를 로컬 스토리지에 되쓰지 않고 원격 쪽에 둔 채로 두어야 한다」는 의도를 나타낼 수 있습니다. 다만 이는 어디까지나 가져온 데이터를 로컬에 정착시키지 않기 위한 플래그이며, 내용을 읽으면 데이터 전송 자체는 발생합니다. 대역이나 지연 자체를 피하려면 속성·크기·타임스탬프만으로 끝낸다 ── 읽기 액세스를 요구하지 않는(액세스 권한 0으로 열기, 열거 결과의 메타데이터를 쓰기) 것이 가장 안전합니다.⁹

flowchart TB
    accTitle: FILE_FLAG_OPEN_NO_RECALL의 효과와 한계
    accDescr: FILE_FLAG_OPEN_NO_RECALL은 가져온 데이터를 로컬에 정착시키지 않기 위한 플래그이며, 내용을 읽으면 데이터 전송 자체는 발생하므로, 전송을 피하려면 속성 같은 메타데이터만으로 끝내는 것이 가장 안전해진다
    flag["NO_RECALL 플래그로 연다"] --> read["내용을 읽는다"]
    read --> transfer["데이터 전송은 발생한다"]
    transfer --> nolocal["로컬에는 정착하지 않는다"]
    meta["메타데이터만으로 끝낸다"] --> safe["전송이 발생하지 않아 가장 안전"]

그림 16: FILE_FLAG_OPEN_NO_RECALL은 로컬에 정착시키지 않을 뿐이며, 전송 자체를 피하려면 메타데이터만으로 끝낸다.

• 오류 메시지에 「OneDrive 아래입니다」라고 낸다. 읽기 실패 시 대상 경로가 %OneDrive% 아래인지를 확인해 메시지에 넣기만 해도 현장과 헬프데스크의 원인 분리 시간이 크게 줄어듭니다. 0x8007016A 같은 클라우드 파일 계열 오류를 감지하면 「OneDrive 상태를 확인하십시오」라고 안내하는 것이 이상적입니다.
• 앱의 데이터 폴더를 OneDrive 아래에 두지 않는다. KFM 환경에서는 「문서」도 OneDrive 아래입니다. 앱의 설정·데이터베이스·작업 파일은 %ProgramData%나 %LocalAppData%에 두고, 기본 저장 위치·가져오기 폴더의 기본값으로 데스크톱이나 문서를 고르지 마십시오. 어디에 무엇을 둘지의 판단은 「Windows 앱의 데이터 저장 위치를 고르는 방법」에 정리되어 있습니다.
• 사용자가 OneDrive 아래를 골랐을 때의 동작을 정해 둔다. 저장 위치를 사용자에게 고르게 하는 앱이라면, 고른 경로가 OneDrive 아래(환경 변수 OneDrive/OneDriveCommercial 경로 아래)일 때 경고하거나, 잠금 파일이나 DB 배치만은 거부하는 식의 설계 판단을 미리 명세에 넣습니다.

  7. 정보시스템 측의 대책 ── 핀과 정책으로 통제한다

정보시스템 입장에서는 「파일 온디맨드를 전부 끈다」가 아니라, 업무에 필요한 곳만 실체를 보장하는 운용이 현실적입니다.

• 업무 앱이 읽는 폴더는 핀한다. 탐색기 오른쪽 클릭에서 「이 장치에 항상 유지」를 고르거나, 이미징 스크립트에서 attrib +p -u <폴더> /s /d를 실행합니다(이미 온라인 전용화된 파일이 섞여 있어도 확실히 핀으로 바꾸려면 -u도 동시에 지정합니다). 핀된 파일은 실체가 로컬에 보장되고, 뒤에서 다룰 자동 온라인 전용화의 대상에서도 빠집니다.⁷²
• KFM과 파일 온디맨드는 「어느새 켜져 있었다」가 아니라 「의도적으로 구성」한다. 주요 정책(그룹 정책/Intune)은 다음과 같습니다.¹¹¹

| 목적 | 정책(레지스트리 값) | 효과 | | — | — | — | | 파일 온디맨드 통제 | Use OneDrive Files On-Demand(FilesOnDemandEnabled) | 켜면 신규 사용자는 기본 온라인 전용. 끄면 기존형 전량 동기화 | | KFM 일괄 적용 | Silently move Windows known folders to OneDrive(KFMSilentOptIn) | 사용자 조작 없이 데스크톱 등을 이동 | | KFM 금지 | Prevent users from moving their Windows known folders to OneDrive(KFMBlockOptIn) | 알려진 폴더 이동을 금지 | | KFM 해제 금지 | Prevent users from redirecting their Windows known folders to their PC(KFMBlockOptOut) | 사용자에 의한 해제를 금지 | | 팀 사이트 용량 절감 | Convert synced team site files to online-only(DehydrateSyncedTeamSites) | 동기화된 팀 사이트를 온라인 전용화(실체가 사라지는 방향으로 작동함에 주의) |

• 스토리지 센스의 움직임을 파악해 둔다. 스토리지 센스(Storage Sense)에는 일정 일수 동안 열리지 않은 클라우드 파일을 자동으로 온라인 전용으로 되돌리는 기능이 있고, 정책(ConfigStorageSenseCloudContentDehydrationThreshold)으로 일수를 구성할 수 있습니다. 기본값은 0(자동으로는 되돌리지 않음)이지만, 사용자가 설정 화면에서 켠 경우나 용량이 작은 단말을 위해 조직에서 구성한 경우에는 「지난주까지 열리던 파일이 구름 표시로 돌아가 있다」가 정상 동작으로 일어납니다. 핀된 파일은 대상 밖이므로, 여기서도 「업무 폴더는 핀」이 통합니다.¹²²

flowchart TB
    accTitle: 스토리지 센스에 의한 자동 온라인 전용화의 분기
    accDescr: 스토리지 센스의 자동 해제에서는 핀된 파일은 대상 밖으로 실체가 유지되고, 핀되지 않은 파일은 일정 일수 열리지 않으면 온라인 전용으로 되돌아간다
    ss["스토리지 센스의 자동 해제"] --> pin{"핀되어 있는가?"}
    pin -->|예| stay["대상 밖으로 실체를 유지"]
    pin -->|아니요| old{"일정 일수 열리지 않았는가?"}
    old -->|예| dehyd["온라인 전용으로 돌아감"]
    old -->|아니요| keep["실체를 유지"]
    ss -.-> def["기본값 0에서는 자동으로는 되돌리지 않음"]

그림 17: 스토리지 센스는 일정 일수 열리지 않은 파일을 온라인 전용으로 되돌리지만, 핀은 대상 밖이다.

• 파일 온디맨드 무효화는 영향을 가늠한 뒤에. FilesOnDemandEnabled를 끄면 기존형 전량 다운로드 동기화가 되지만, 디스크 소비와 첫 동기화의 대역 부하가 뛰어오릅니다. Microsoft는 켠 채로 둘 것을 권장하며, 무효화는 「대상 사용자의 데이터 양이 작다」, 「디스크에 여유가 있다」를 확인한 한정적인 조치로 보아야 합니다.¹¹²
• 지원 절차에 넣는다. 「데스크톱의 파일이 읽히지 않는다」는 문의 템플릿에 다음 장의 원인 분리 절차를 넣어 두면, 담당자가 바뀌어도 대응 품질이 맞춰집니다.

  8. 원인 분리 절차 ── 「파일이 읽히지 않는다」는 상담을 받으면

상담을 받으면 위에서부터 확인합니다.

응급 조치는 대상 폴더를 오른쪽 클릭해 「이 장치에 항상 유지」를 고르는 것(또는 attrib +p /s /d)입니다. 이것으로 실체가 로컬에 맞춰지고 업무는 재개할 수 있습니다. 그 위에서 항구 대책으로 6장(앱 측)과 7장(정보시스템 측) 중 어디에 본질적인 원인이 있는지를 판단하십시오.

flowchart TB
    accTitle: 응급 조치에서 항구 대책으로의 흐름
    accDescr: 응급 조치로 대상 폴더를 이 장치에 항상 유지로 두면 실체가 로컬에 맞춰져 업무를 재개할 수 있고, 그 위에서 본질적인 원인이 앱 측인지 정보시스템 측인지를 판단해 항구 대책으로 나아간다
    aid["응급 조치로 핀"] --> restore["실체가 로컬에 맞춰짐"]
    restore --> resume["업무를 재개"]
    resume --> judge{"본질적인 원인은?"}
    judge -->|앱 측| dev["6장의 대책으로"]
    judge -->|정보시스템 측| ops["7장의 대책으로"]

그림 18: 응급 조치는 핀으로 실체를 맞춰 업무를 재개하고, 항구 대책은 앱 측인지 정보시스템 측인지를 판단해 진행한다.

덧붙여, 여기까지 확인했는데 「경로는 OneDrive 아래가 아니다」, 「플레이스홀더도 아니다」라면 공유 폴더나 경로 길이 등 다른 계통의 단골 원인으로 갑니다. 「네트워크 드라이브와 UNC 경로의 함정」, 「MAX_PATH와 Windows 경로·파일 이름의 함정」이 이어지는 지도가 됩니다.

9. 정리

• KFM에 의해 데스크톱·문서·그림의 실체는 C:\Users\<사용자명>\OneDrive\ 아래로 이동해 있는 경우가 있습니다. 고정 경로를 전제로 한 앱은 여기서 깨집니다. 알려진 폴더 API로 해석하는 것이 첫걸음입니다.
• 파일 온디맨드는 기본으로 켜져 있고, 로컬에 실체가 없는 플레이스홀더가 흔히 존재합니다. 플레이스홀더는 Cloud Files API(cldflt.sys)의 재분석 지점이며, 열면 자동으로 하이드레이션됩니다.
• 상태는 파일 속성(OFFLINE / RECALL_ON_DATA_ACCESS / PINNED / UNPINNED)으로 판정할 수 있고, attrib에서는 O·P·U로 보입니다. 속성 확인만으로는 다운로드가 발생하지 않습니다.
• 업무 앱의 사고는 오프라인 시 하이드레이션 실패, 일괄 처리에 의한 전량 다운로드, 속성을 전제하지 않은 코드, FileSystemWatcher와 동기화의 상호작용, 배타 잠금과 동기화의 충돌, 보안 제품에 의한 하이드레이션 유발이라는 형태로 나타납니다.
• 앱 측은 「속성으로 판정하고 함부로 열지 않기」, 「데이터 폴더를 OneDrive 아래에 두지 않기」, 「오류 시 OneDrive 아래임을 전하기」가 기본입니다.
• 정보시스템 측은 「업무 폴더의 핀」과 「KFM·파일 온디맨드·스토리지 센스의 정책 통제」로 의도한 상태를 만듭니다.
• 원인 분리는 경로→attrib→OneDrive 가동→네트워크→빈 공간→기록 순으로 기계적으로 진행할 수 있습니다.

다음에 「파일은 있는데 읽히지 않는다」는 상담을 받으면, 먼저 이렇게 다시 물으십시오.

그 파일은 정말 로컬 디스크에 있는가. 아니면 클라우드의 겉모습만 그곳에 있는가.

관련 기사

• Windows I/O의 심층(제5회) ── NTFS의 내부 구조: MFT부터 이해하는 파일 시스템
• FileSystemWatcher 실무 가이드 - 누락과 중복 대책
• 네트워크 드라이브와 UNC 경로의 함정 ── 업무 앱에서 파일 서버(공유 폴더)를 다루는 실무
• 파일 연계의 배타 제어 기초 지식 - 파일 잠금과 원자적 claim의 베스트 프랙티스
• Windows 앱의 데이터 저장 위치를 고르는 방법 ── SQLite / JSON / 레지스트리 / Access 판단표
• MAX_PATH와 Windows 경로·파일 이름의 함정 ── 260자 제한, 예약 이름, 끝 점, 대소문자

관련 상담 영역

합동회사 코무라소프트는 「지금까지 잘 되던 가져오기 처리가 PC를 바꾼 뒤에 동작하지 않는다」, 「특정 PC에서만 파일이 읽히지 않는다」 같은 OneDrive·클라우드 스토리지가 얽힌 업무 앱 장애 조사, 플레이스홀더를 전제로 한 파일 처리·감시 처리의 설계와 수정, KFM·파일 온디맨드 환경에서의 저장 위치 설계 리뷰를 다룹니다. 현상 원인 분리부터여도 괜찮으니 편하게 상담해 주십시오.

• Windows 앱 개발
• 장애 조사·원인 분석
• 기술 상담·설계 리뷰
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

데스크톱에 둔 CSV를 업무 앱이 「파일을 찾을 수 없습니다」라고 하며 읽지 못합니다. 왜인가요?

많은 경우 데스크톱 폴더 자체가 OneDrive의 「알려진 폴더 이동(KFM)」으로 C:\Users\<사용자명>\OneDrive\데스크톱 아래로 옮겨졌거나, 파일이 온라인 전용 플레이스홀더가 된 상태입니다. 앱이 C:\Users\<사용자명>\Desktop 같은 고정 경로를 전제로 하면 이동 뒤에 파일을 찾지 못합니다. 경로가 맞아도 OneDrive가 중지되었거나 네트워크가 불안정하면 온라인 전용 파일은 열리지 않을 수 있습니다. 먼저 대상 경로가 OneDrive 아래인지 확인하고, attrib으로 U(온라인 전용)가 있는지 보십시오. 응급으로는 오른쪽 클릭의 「이 장치에 항상 유지」로 실체를 로컬에 확보할 수 있습니다.

프로그램에서 온라인 전용 파일인지 판정할 수 있나요?

있습니다. 온라인 전용 플레이스홀더에는 FILE_ATTRIBUTE_OFFLINE이나 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS(0x00400000) 같은 속성이 붙으므로, 파일 속성을 조사하면 내용을 다운로드하지 않고 상태를 판정할 수 있습니다. 속성 조회나 폴더 열거만으로는 하이드레이션(다운로드)이 발생하지 않습니다. .NET에서는 FileAttributes에 정의가 없는 값도 있으므로 정수로 캐스트한 뒤 비트 연산으로 판정합니다. 내용을 읽지 않고 열어야 한다면 CreateFile의 FILE_FLAG_OPEN_NO_RECALL 같은 수단도 있습니다.

파일 온디맨드를 끄면 문제가 해결되나요?

무효화는 최후의 수단으로 보십시오. 끄면 동기화 대상의 모든 파일이 로컬로 내려가므로 디스크 용량과 첫 동기화의 네트워크 부하가 커지고, Microsoft도 켠 채로 운용할 것을 권장합니다. 실무에서는 업무 앱이 읽는 폴더만 「이 장치에 항상 유지」(핀)하는 편이 유연합니다. 더 근본적으로는 앱의 데이터 폴더와 가져오기 폴더를 OneDrive 관리 아래에 두지 않는 설계로 고치는 것이 확실합니다.

「이 장치에 항상 유지」로 했는데 어느새 구름 표시로 돌아가는 파일이 있습니다. 왜인가요?

먼저 attrib으로 그 파일에 정말 핀(P 속성)이 붙어 있는지 확인하십시오. 핀된 파일은 스토리지 센스의 자동 온라인 전용화 대상이 아니지만, 핀하지 않고 열기만 한 「로컬에서 사용 가능」 파일은 스토리지 센스 설정이나 정책에 따라 일정 기간 뒤에 온라인 전용으로 돌아갈 수 있습니다. 사용자 자신의 「공간 확보」 조작이나, 팀 사이트를 온라인 전용화하는 정책(DehydrateSyncedTeamSites)으로도 구름 표시로 돌아갑니다. 업무상 반드시 로컬이 필요한 폴더는 폴더 단위로 핀해서 운용하십시오.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.