플랫폼 변환 간 파일 권한 및 소유권 보존

파일 변환은 보통 형식 충실도—시각적 또는 텍스트 콘텐츠가 변환 후 얼마나 잘 살아남는가—에 대해 논의됩니다. 그러나 많은 조직에 있어 파일을 둘러싼 보안 환경인 권한, 소유권, 확장 속성은 동등하게 중요합니다. 문서가 Windows 워크스테이션에서 Linux 서버로 이동하거나 클라우드 기반 변환기를 통과할 때, 이러한 접근 제어가 조용히 제거되어 민감한 데이터가 노출되거나 자동화된 워크플로가 중단될 수 있습니다. 이 가이드는 기본적인 권한 모델을 살펴보고, 변환 중에 왜 중요한지 설명하며, 이를 그대로 유지하기 위한 구체적이고 재현 가능한 기술을 제공합니다.

다양한 플랫폼의 권한 모델 이해

POSIX 권한은 Unix‑like 시스템에서 주류를 이룹니다. 모든 파일은 소유자 사용자, 소유자 그룹, 그리고 사용자·그룹·그 외에 대한 읽기·쓰기·실행 세 트리플을 가집니다. 최신 Linux 배포판은 POSIX ACL도 지원하여 클래식 3‑튜플을 넘어선 세밀한 항목을 설정할 수 있습니다.

Windows ACL은 더 표현력이 풍부합니다. 접근 제어 목록(Access Control List)에는 Access Control Entry(ACE) 시퀀스가 들어가며, 여기서는 사용자, 그룹 또는 Authenticated Users와 같은 내장 주체에 대한 허용·거부 규칙을 지정합니다. 각 ACE는 상속 플래그, 객체‑형식별 권한, 감사 설정 등을 포함할 수 있습니다.

두 플랫폼 모두 확장 속성(xattr)과 리소스 포크(macOS)와 같이 사용자 정의 메타데이터를 저장할 수 있는 방법을 제공합니다—예를 들어 “기밀”을 나타내는 사용자 정의 태그나 외부 시스템에서 사용하는 체크섬 등이 있습니다. 파일을 단순히 복사할 경우 대부분의 운영 체제는 이러한 속성을 보존하지만, 대부분의 순진한 변환 도구는 파일을 불투명한 바이트 스트림으로 취급하고 원시 데이터 이외의 모든 것을 버립니다.

변환 워크플로에서 권한이 중요한 이유

규제 준수 – GDPR, HIPAA 등은 데이터 취급 작업 전반에 걸쳐 접근 제어가 유지되어야 한다고 요구합니다(저장뿐 아니라).
운영 연속성 – 그룹 기반 실행에 의존하는 자동 파이프라인(예: data‑ingest 소유 파일을 처리하는 야간 작업)은 소유권이 사라지면 실패합니다.
위험 완화 – ACL이 제거되면 비공개 문서가 전 세계에 읽히는 파일이 되어 데이터 유출 위험이 커집니다.
감사 – 포렌식이나 e‑discovery 목적에서 원본 권한 상태는 증거 사슬의 일부이며, 이를 변경하면 감사 흐름이 무효화됩니다.

따라서 파일을 파일시스템, 컨테이너, 클라우드 서비스 간에 이동하는 모든 변환 파이프라인은 권한을 1급 시민으로 취급해야 합니다.

권한이 사라지는 전형적인 시나리오

1. Windows → Linux (SMB 또는 FTP)

Windows 공유에서 Linux 서버로 파일을 업로드하면 SMB 클라이언트가 보통 Windows 소유자를 로컬 사용자(대개 nobody)에 매핑하고 원본 ACL을 버립니다. FTP는 텍스트 기반 프로토콜이기 때문에 모든 메타데이터를 제거합니다.

2. 클라우드 기반 변환 서비스

대부분의 SaaS 변환기는 multipart/form-data POST를 받아 파일 내용을 읽고 변환한 뒤 결과를 반환합니다. 서비스는 페이로드를 원시 바이트로 취급하므로 OS 수준 권한 비트가 클라이언트 머신을 떠나지 않습니다. 다운로드 후 결과 파일은 수신 디렉터리의 기본 권한을 상속합니다. 예를 들어 convertise.app을 사용할 경우 업로드된 문서는 완전히 클라우드에서 처리되며 반환된 파일은 로컬 다운로드 폴더의 권한을 갖습니다.

3. 메타데이터 보존 없이 압축 해제

디렉터리를 zip으로 묶어 전송하고, 내부 파일을 변환한 뒤 다시 압축 해제하는 경우가 흔합니다. zip 형식은 Unix 권한을 저장할 수 있지만, 많은 사용자가 -X 플래그를 비활성화한 상태로 압축을 풀어 비트가 사라지고, Windows ZIP 유틸리티는 이를 전혀 무시합니다.

변환 중 권한을 보존하는 전략

a. 메타데이터를 유지하는 아카이브에 파일을 감싸기

가장 간단한 방법은 권한 데이터를 명시적으로 기록하는 아카이브에 원본 파일을 넣고, 가능하면 아카이브 자체를 변환하는 것입니다. 지원되는 포맷 예시:

tar – --preserve-permissions(-p) 옵션 사용. --acls 옵션을 주면 UID/GID, 모드 비트, POSIX ACL을 저장합니다(GNU tar).
pax – POSIX 표준 아카이브로 확장 속성을 저장할 수 있습니다.
7‑zip(.7z) – -sacl 스위치를 사용하면 Windows ACL을 기록합니다.

아카이브를 보존함으로써 개별 파일마다 권한을 재적용할 필요가 없어집니다.

b. 권한 메타데이터를 별도로 내보내고 재수입하기

변환 대상 포맷이 권한 비트를 담을 수 없을 때(예: DOCX → PDF) 변환 전에 보안 서술자를 사이드카 파일로 내보냅니다.

# POSIX ACL을 JSON 파일로 내보내기
auditctl -a always,exit -F arch=b64 -S chmod,chown -k perm_export
getfacl -R /data/incoming > perms.acl

변환 후, 짧은 후처리 스크립트를 실행해 저장된 ACL을 새로운 파일에 경로 기준으로 다시 적용합니다.

c. 메타데이터를 존중하는 변환 도구 사용

일부 CLI 유틸리티는 권한 복사를 위한 옵션을 제공합니다.

pandoc(문서 포맷) – --preserve 플래그로 파일 모드 비트를 유지합니다.
ffmpeg – metadata 플래그를 복사할 수 있지만 UNIX 권한은 전파하지 않으므로 -map_metadata와 조합해 태그를 유지합니다.
이미지 변환 시 ImageMagick의 convert는 -strip 옵션(메타데이터 제거)이 있지만 기본적으로 파일 모드를 건드리지 않습니다. -strip을 피하고 -set filename:original을 사용하면 이후 권한 복원에 도움이 됩니다.

d. 스크립팅 언어를 활용한 프로그래매틱 재적용

Python 등은 os.chmod, os.chown, os.setxattr API를 제공합니다. 범용 재적용 루틴 예시:

import json, os, pwd, grp

with open('perms.json') as f:
    perms = json.load(f)

for rel_path, meta in perms.items():
    dst = os.path.join('converted', rel_path)
    os.chmod(dst, meta['mode'])
    uid = pwd.getpwnam(meta['owner']).pw_uid
    gid = grp.getgrnam(meta['group']).gr_gid
    os.chown(dst, uid, gid)
    for attr, value in meta.get('xattrs', {}).items():
        os.setxattr(dst, attr, value.encode())

메타데이터를 휴대 가능한 JSON 포맷으로 저장하면 Windows(pywin32를 통한 ACL)와 Linux 양쪽에서 동일 스크립트를 재사용할 수 있습니다.

엔드‑투‑엔드 워크플로 예시

소스 파일 수집 – /project/source 디렉터리.
권한 내보내기 – UID/GID, 모드, Windows ACL SDDL 문자열을 기록하는 작은 Go 유틸리티로 perms.json 생성.
tarball 생성 – tar -cvpf source.tar /project/source (-p 플래그가 정확한 모드 비트를 저장).
tarball 업로드 – curl -F file=@source.tar https://api.convertise.app/convert?to=zip 등으로 변환 서비스에 전송. 서비스는 각 문서를 변환하지만 아카이브는 유지합니다.
아카이브 추출 – 목적 호스트에서 tar -xvpzf converted.zip(Linux) 혹은 Windows에서 7z x -sacl converted.zip.
ACL 재적용 – 앞서 만든 perms.json을 Python 스크립트에 입력하여 적용.

그 결과, 보안 관점에서 원본과 동일하게 동작하는 변환 파일 세트를 얻을 수 있습니다.

테스트 및 검증

변환 실행 후 권한이 기대와 일치하는지 확인합니다:

체크섬 비교 – 변환 전후 각각 파일에 대해 SHA‑256을 계산해 내용 무결성을 확인하고, getfacl -c(Linux) 또는 icacls(Windows) 출력 문자열을 해시해 권한 해시를 비교합니다.
자동 회귀 테스트 – CI 파이프라인에 단계 추가: 고정 디렉터리를 복사·변환하고 stat -c "%a %U %G" 결과가 기준과 일치하는지 검증.
감사 로그 – 조직에서 감사 로그가 필요하면 권한 내보내기·재적용 시점과 변환 ID를 함께 기록합니다. 이는 보안 메타데이터 추적성을 요구하는 다수 규제 프레임워크를 만족합니다.

엣지 케이스 및 특별 고려사항

암호화 파일

파일 시스템 수준에서 암호화된 경우(예: Windows BitLocker, Linux eCryptfs) 변환 서비스는 기본 권한을 볼 수 없습니다. 권장 방법은 안전한 스테이징 영역에 복호화한 뒤 ACL을 보존하면서 변환하고, 결과를 다시 암호화하는 것입니다.

스트리밍 변환

파일을 직접 바이너리(ffmpeg -i - -f mp4 -)에 스트리밍하는 파이프라인에서는 원본 파일이 스트림 시작 이후 디스크에 남지 않으므로 권한 비트를 복사할 수 없습니다. 해결책은 파일 디스크립터 복제: 소스를 열어 fstat로 모드를 저장하고, 변환이 끝난 뒤 출력 파일에 chmod로 적용합니다.

크로스‑플랫폼 경로 정규화

Windows는 역슬래시와 대소문자 구분이 없고, Unix는 대소문자를 구분합니다. 사이드카 메타데이터와 변환 파일을 매핑할 때는 os.path.normcase(Windows) 또는 os.path.realpath(POSIX)를 사용해 경로를 정규화합니다.

권한‑안전 변환 체크리스트

소스 권한 모델 식별(POSIX, Windows ACL, macOS xattr).
변환 전 권한 메타데이터를 휴대 가능한 형태로 내보내기.
파일을 번들링해야 한다면 메타데이터를 저장하는 아카이브 포맷 선택.
메타데이터를 자동으로 보존하는 변환 도구 선호(필요시 명시적 옵션 사용).
변환 후 스크립트 자동화를 통해 권한 재적용.
체크섬 기반 테스트로 내용·ACL 모두 일치 확인.
내부 실행 매뉴얼에 프로세스 문서화하여 감사자에게 제공.

결론

파일 변환은 흔히 “새 파일이 동일하게 보이는가?”라는 질문으로 축소됩니다. 보안·규제 환경에서는 “새 파일이 동일한 접근 제어를 유지하는가?”도 반드시 포함되어야 합니다. 권한을 명시적 데이터로 취급해 내보내고, 페이로드와 함께 운반하고, 변환 후 재설정함으로써 콘텐츠 충실도와 보안 태세를 동시에 만족하는 파이프라인을 구축할 수 있습니다. Windows 데스크톱에서 Linux 기반 아카이브 시스템으로 PDF를 옮기든, convertise.app과 같은 클라우드‑퍼스트 변환 서비스를 이용하든, 이 실천법은 편리함을 포기하지 않으면서도 예측 가능하고 감사 가능한 결과를 제공합니다.

플랫폼 변환 시 파일 권한 및 소유권 보존