Filee — 파일 변환을 드래그 한 번으로 끝내려는 오픈소스

웹이나 앱을 만들 때도, 회사 업무를 처리할 때도 이미지나 파일의 형식을 바꿔야 하는 순간은 늘 있었다. 그때마다 구글에서 변환기를 검색했다. 웹사이트에 파일을 올려 변환하기도 했고, 설치형 프로그램을 내려받아 쓰기도 했다.

익숙한 일이었지만 마음까지 편한 것은 아니었다. 다운로드 버튼 앞에서는 ‘이걸 설치해도 내 PC가 안전할까?’라는 생각이 들었다. 처음 보는 변환 사이트에 들어갈 때면 ‘이번에도 광고가 잔뜩 나오겠지’ 싶었고, 악성코드 걱정도 따라왔다. 실제로 문제가 생겼다는 이야기와는 별개로, 믿을 만한 도구인지 확신하지 못한 채 당장 필요하다는 이유로 사용해온 경험이다.

그러던 중 SNS에서 Filee를 소개하는 홍보 글을 봤다. 당시 내 눈에는 아직 널리 알려지지 않은 프로젝트였지만, 오픈소스라는 점과 파일을 끌어다 놓는 변환 방식이 눈에 들어왔다. 매번 변환기를 검색하던 내게는 그 제안이 작은 혁신처럼 느껴졌다.

Filee는 이 과정에 다른 답을 내놓는다. 파일을 끌면 커서 옆에 도넛 모양의 메뉴가 나타나고, 원하는 형식 위에 놓으면 변환을 시작한다. 익숙한 파일 관리 동작 안으로 변환 기능을 가져온 셈이다.

그 짧은 동작을 가능하게 하는 코드는 생각보다 넓다. 입력 제스처 감지, 파일 종류별 프리셋, 여러 엔진을 잇는 경로 탐색, 일괄 작업의 실패 처리까지 들어 있다. 이번 리뷰에서는 기능 목록을 넘어, 사용자의 수고를 줄이려는 선택이 코드 구조에 어떻게 이어지는지 살펴본다.

분석 기준은 2026년 10월 8일 확인한 main의 커밋 bcaf4b5570154324c9006c8840b87ca4f8be3c0e다. 소스와 프로젝트 문서를 바탕으로 작성했으며, 앱 실행과 실제 변환 결과 비교는 진행하지 않았다. 아래의 UX 설명은 문서와 구현에 근거한 분석이다.

---

왜 이 프로젝트를 살펴봤나

Filee를 더 살펴보고 싶었던 이유는 그 첫인상을 코드로 확인하고 싶었기 때문이다. 소스가 공개돼 있다는 점은 도구가 어떻게 동작하는지 들여다볼 기회를 준다. 내 컴퓨터에서 파일을 처리하는 방식과 커서 옆에서 시작하는 변환이, 그동안 느꼈던 불안과 번거로움에 어떤 답을 주는지 궁금했다.

특히 지원 확장자 수보다 변환을 시작하는 위치가 흥미로웠다. 사용자는 파일 관리자에서 이미 파일을 선택하고 있다. 그렇다면 변환도 그 자리에서 시작할 수 없을까?

이 질문은 인터페이스에만 머무르지 않는다. 사용자가 엔진을 고르거나 중간 파일을 만들지 않게 하려면 앱이 그 복잡함을 맡아야 한다. Filee는 커서 옆 메뉴와 자동 경로 탐색을 함께 구현해 이 문제에 접근한다.

한국어 사용자에게는 HWP와 HWPX를 다른 문서 형식으로 연결하는 시도도 흥미롭다. 이미지와 동영상 변환에 더해, 한컴오피스 없이 한글 문서를 읽고 다른 형식으로 내보내는 경로를 마련했다. 일상의 작은 불편을 출발점으로 삼되, 이를 해결하기 위한 기술적 선택은 깊이 살펴볼 만한 프로젝트다.

직접 사용해보기

[이미지 변환]

[동영상 변환]

프로젝트가 안내하는 기본 흐름은 간단하다. Windows에서는 Ctrl, macOS에서는 Option을 누른 채 파일을 끌고, 커서 위치에 나타난 메뉴의 목표 형식에 놓는다. 파일 종류에 따라 툴바가 달라지며, 품질이나 저장 위치 같은 반복 설정은 프리셋에 담는다. 우클릭 메뉴와 메인 창의 드롭 영역도 제공한다.

다만 플랫폼마다 조건은 다르다. 현재 README는 Windows 10/11을 안내하고 macOS와 Linux를 미리보기로 표시한다. macOS는 손쉬운 사용 권한이 필요하고, 아직 공증되지 않은 빌드라는 안내가 있다. Linux의 전역 드래그 제스처는 X11에서 동작하며, Wayland에서는 드롭 영역이나 파일 관리자 메뉴를 이용한다. 자세한 설치 조건은 한국어 README를 참고할 수 있다.

CLI도 같은 엔진과 프리셋을 사용한다. 다음은 README의 사용 예다.

filee convert photo.heic --to jpg
filee convert *.png --to webp --quality 80 -o converted
filee formats heic

실사용 평가에서는 단순 이미지 변환의 조작 편의성과 복잡한 문서의 결과 품질을 나눠 확인할 필요가 있다. 특히 표와 그림이 있는 HWP를 DOCX로 바꿨을 때의 배치, 수식과 차트가 있는 스프레드시트를 PDF로 만들었을 때의 누락 여부는 별도의 검증 대상이다. 현재 글에서는 속도나 서식 재현율에 점수를 매기지 않는다.

가장 흥미로웠던 UX

도넛 메뉴의 의미는 모양보다 맥락에 있다. 사용자가 파일을 끌고 있는 바로 그 위치에 선택지를 제공한다. 파일 종류에 맞는 프로필로 메뉴를 구성하고, 실행할 수 없는 프리셋에는 이유를 표시하는 구조도 갖췄다. 사용자가 모든 변환 엔진의 지원 범위를 외우지 않아도 되게 하는 접근이다.

이 흐름에는 까다로운 순서 문제가 있다. 전역 입력에서 드래그 제스처를 감지하는 순간에는 아직 변환할 파일 목록을 모른다. Filee는 메뉴를 먼저 열고, 창의 DragEnter 이벤트에서 파일을 받아 프로필을 결정한다. 파일 관리자의 드래그가 이어지도록 메뉴 창은 투명하고 최상위에 놓되 활성화되지 않게 구성한다. 아키텍처 문서가 이 과정을 설명한다.

제스처 감지 코드에는 파일을 먼저 끌다가 나중에 수정키를 누르는 경우도 들어 있다. 사용 설명서대로만 움직이는 사람을 가정하지 않고, 실제 파일 관리 중 생길 수 있는 입력 순서를 받아들이려는 선택이다.

만드는 사람에게는 이 지점이 좋은 힌트다. 짧은 UX를 구현하려면 화면을 간단하게 그리는 것뿐 아니라, 사용자의 기존 동작을 끊지 않는 이벤트 처리까지 설계해야 한다.

저장소 구조

프로젝트는 C#과 .NET 10을 사용하며, 데스크톱 UI는 Avalonia로 구현했다. 주요 책임은 다음처럼 나뉜다.

핵심은 UI와 OS 연동을 변환 정책에서 분리했다는 점이다. 도넛 메뉴로 시작한 변환과 CLI로 시작한 변환이 같은 핵심 로직을 사용할 수 있다. 화면을 추가할 때마다 변환 처리까지 다시 만드는 부담을 줄이는 구조다.

변환 엔진은 어떻게 동작하나

Converter 추상화

각 변환기는 IConverter를 구현한다. 엔진 식별자, 직접 지원하는 변환 목록, 사용 가능 상태, 동시 실행 제한과 실제 변환 메서드가 하나의 계약에 들어 있다.

변환기는 자신이 할 수 있는 한 단계를 선언한다. 전체 변환 경로와 최종 출력 이름은 다른 계층이 맡는다. 예를 들어 PDF를 여러 이미지로 내보내는 엔진도 출력 경로 할당기를 통해 이름을 받고, 생성한 파일 목록을 반환한다. 입력 하나가 출력 여러 개가 되는 상황까지 계약에 포함한 것이다.

이 분리는 확장 방향을 명확하게 만든다. 새 엔진은 자기 변환에 집중하고, 작업 큐는 서로 다른 엔진을 같은 방식으로 호출한다.

RoutePlanner

RoutePlanner는 파일 형식을 노드로, 변환기가 제공하는 직접 변환을 간선으로 다룬다. 각 간선의 비용을 더해 Dijkstra 방식으로 경로를 찾으며, 현재 사용할 수 있는 엔진만 탐색에 참여한다. 사용자 엔진 우선순위도 추가 비용으로 반영한다.

대표적인 예는 HWP → HWPX → DOCX다. 각 단계가 연결되면 사용자는 중간 HWPX 파일을 직접 준비하지 않아도 된다. 개발자 역시 새 엔진을 추가할 때 가능한 모든 조합을 별도로 작성할 필요가 줄어든다.

문서 처리에서는 공통 문서 모델이 중요한 연결점이다. 여러 형식의 내용을 읽어 HWPX 또는 DOCX로 쓰고, HWPX는 rhwp를 통해 PDF로 렌더링할 수 있다. Filee가 외부 도구 호출에 더해 자체 문서 읽기·쓰기 구현을 갖춘 이유가 여기에 있다.

다만 경로의 비용은 실행 결과를 측정한 품질 점수가 아니다. 개발자가 정한 상대 비용과 사용자의 우선순위다. 최대 변환 단계도 3개로 제한한다. 자동 경로 선택은 사용자의 수고를 줄여주지만, 원본의 모든 서식을 보존한다는 보장은 별개의 문제다.

JobQueue

JobQueue는 작업을 순서대로 실행하고, 한 작업 안의 파일들은 병렬로 처리한다. 엔진마다 세마포어를 두어 동시 호출 수를 제한하므로, 파일 수만큼 외부 프로세스를 무작정 실행하는 구조는 아니다.

파일 하나가 실패하면 해당 결과를 기록하고 다른 파일의 처리는 이어간다. 전체 작업도 완료, 일부 오류를 포함한 완료, 실패, 취소로 구분한다. 일괄 변환에서는 단순한 성공 메시지보다 이런 상태 구분이 더 유용하다.

출력 경로를 잠금 안에서 예약하는 부분도 눈에 띈다. 병렬로 처리하는 파일들이 같은 출력 이름을 선택하는 충돌을 줄이기 위해서다. 중간 파일은 작업별 임시 폴더에 두고 처리가 끝나면 정리를 시도한다. 짧은 사용 흐름 뒤에 파일 관리의 현실적인 문제들이 들어 있다.

외부 변환 엔진

Filee는 ImageMagick 계열 이미지 처리와 자체 문서 처리 등 여러 구현을 활용하고, FFmpeg·LibreOffice·calibre·Ghostscript·Pandoc 같은 선택 엔진도 연결한다. 어떤 변환이 가능한지는 형식뿐 아니라 엔진의 설치 상태에 따라 달라진다.

현재 EngineEnvironment는 사용자 지정 경로, Filee가 제공하는 엔진, 시스템 설치본 순으로 탐색할 수 있게 구성돼 있다. 이미 설치한 도구를 재사용하면서 앱이 제공하는 버전도 활용하는 접근이다.

엔진 다운로드에는 SHA-256 검증과 임시 설치 폴더를 사용한다. 다운로드 도중 끊긴 상태를 완성된 엔진으로 취급하지 않으려는 장치다. 다만 최초 엔진 설치와 업데이트처럼 네트워크가 필요한 과정은 로컬 파일 변환과 구분해 이해해야 한다.

코드에서 좋았던 부분

가장 좋았던 점은 인터페이스의 단순함을 내부 책임 분리로 뒷받침했다는 것이다. UI는 작업을 시작하고 상태를 보여주며, 경로 탐색은 엔진 조합을 결정하고, 엔진은 한 단계의 변환에 집중한다. CLI가 같은 로직을 재사용하는 것도 이 구조의 실질적인 결과다.

입력 제스처를 UI 프레임워크와 분리한 상태 머신으로 구현한 점도 의미 있다. GestureDetector는 저수준 이벤트를 받아 드래그·길게 누르기·키 조합을 판별한다. UI를 띄우지 않고도 입력 순서에 따른 동작을 테스트할 수 있다.

자동 변환 폴더에서도 현실적인 예외를 다룬다. FolderWatcher는 생성 이벤트를 받자마자 변환하지 않고, 파일 크기와 수정 시각이 일정 시간 안정되는지 확인한다. 임시 확장자를 제외하고 macOS Finder의 복사 중 표시도 확인한다. 완성되지 않은 다운로드 파일을 먼저 변환하는 문제를 줄이려는 구현이다. 물론 잠시 멈춘 복사와 완전히 끝난 복사를 대기 시간만으로 항상 구분할 수는 없다.

이런 코드가 주는 영감은 구체적이다. 사용자가 누르는 버튼 수를 줄이는 만큼, 앱은 타이밍과 실패와 충돌을 더 세심하게 맡아야 한다.

아쉬웠던 부분

지원 형식이 많다는 사실과 변환 결과가 원본에 충실하다는 사실은 구분해야 한다. 공통 문서 모델은 여러 형식을 연결하기 좋은 기반이지만, 그 모델에 담기지 않는 정보는 다음 형식으로 전달하기 어렵다.

엔진 문서는 이러한 한계를 구체적으로 설명한다. 스프레드시트 변환은 수식의 캐시된 결과를 유지하지만 수식 자체와 차트 등은 보존하지 않는다. HWPX 읽기에서는 OLE 객체, 차트, 일부 도형과 그림 속성이 제외된다. PDF 텍스트 추출에도 OCR 기능은 없다.

따라서 복잡한 업무 문서는 결과를 열어 확인하는 과정이 필요하다. 변환 경로가 있다는 사실만으로 편집 가능성이나 배치 재현 수준까지 판단할 수는 없다. 프로젝트가 누락 항목을 문서화한 점은 좋지만, 사용자가 변환 전에 이 차이를 얼마나 쉽게 알 수 있는지는 실사용에서 확인할 부분이다.

문서와 구현의 동기화에도 틈이 있다. 분석 시점의 ENGINES.md에는 시스템 설치 엔진을 사용하지 않는다는 설명이 남아 있지만, README와 현재 코드는 시스템 설치본 탐색을 안내하고 구현한다. 설치와 결과 재현성에 영향을 주는 설명인 만큼 정리가 필요하다.

플랫폼 지원도 동일한 수준으로 받아들이기 어렵다. macOS·Linux는 미리보기이고 권한과 디스플레이 서버에 따른 제약이 있다. 도넛 제스처가 프로젝트의 핵심 경험인 만큼, 자신의 환경에서 그 경험이 가능한지 먼저 확인해야 한다.

오픈소스 프로젝트로서의 완성도

저장소에는 아키텍처 설명, 엔진별 제약, 새 변환기와 언어 추가 안내, 기여 문서와 서드파티 고지가 있다. 코드를 읽는 사람이 어디서 시작하고 무엇을 확장할지 찾을 수 있게 돕는다.

테스트 역시 경로 계획과 작업 큐에 그치지 않는다. 출력 경로, 폴더 감시, 문서 읽기·쓰기, UI 렌더링과 OS 연동을 다루는 테스트 파일이 있으며, CI에는 빌드·포맷 검사·테스트·설치 스크립트 확인이 구성돼 있다. 다만 외부 엔진의 존재 여부에 따라 건너뛰는 테스트가 있으므로, 테스트의 존재를 모든 지원 형식의 검증으로 해석해서는 안 된다. 이 리뷰에서도 테스트를 직접 실행하지 않았다.

프로젝트 자체는 MIT 라이선스지만 포함하거나 연결하는 구성요소는 각자의 라이선스를 따른다. 재배포나 제품 통합을 검토하는 개발자라면 서드파티 고지도 함께 읽을 필요가 있다.

소스와 문서 기준으로는 기능을 추가하는 방법뿐 아니라 배포와 실패 처리까지 고민한 흔적이 있다. 실제 안정성과 변환 품질에 대한 평가는 다양한 파일을 넣어보는 검증이 더해져야 한다.

이런 사람에게 잘 맞는다

Filee는 파일 관리자에서 이미지 형식 변경이나 반복 변환을 자주 수행하는 사람에게 검토할 만한 도구다. 문서를 외부 서비스에 업로드하지 않고 자신의 컴퓨터에서 처리하려는 사용자에게도 로컬 변환이라는 방향이 의미 있다. CLI와 감시 폴더는 반복 작업을 자동화하려는 사람에게 별도의 활용 지점을 제공한다.

개발자에게는 데스크톱 UX와 변환 파이프라인을 함께 살펴볼 수 있는 사례다. 특히 입력 감지와 UI의 분리, 공통 계약으로 엔진을 묶는 방법, 변환 가능성을 그래프로 확장하는 방법이 좋은 읽을거리다.

반면 수식·차트·복잡한 문서 배치를 그대로 유지해야 하는 작업에서는 지원 목록만 보고 선택하기 어렵다. 대표 파일을 먼저 변환해 자신의 요구 수준에 맞는지 확인하는 것이 좋다.

마치며

Filee의 흥미로운 시도는 파일 변환을 사용자가 이미 하던 동작 안으로 가져온 데 있다. 커서 옆 도넛 메뉴는 그 선택이 보이는 부분이고, 뒤에서는 경로 탐색과 작업 큐, 문서 모델이 엔진의 차이와 중간 단계를 맡는다.

이 프로젝트에서 만드는 사람이 얻을 수 있는 영감은 분명하다. 사용 경험을 짧게 만들려면 내부의 복잡함을 없애기보다, 적절한 책임에 맡겨야 한다. 사용하는 사람에게는 반복 설정과 앱 전환을 줄일 가능성을 보여준다.

다음으로 확인할 것은 그 짧은 동작이 실제 파일에서도 믿을 만한 결과로 이어지는지다. Filee는 그 질문을 던지고 코드를 따라가 볼 가치가 있는 오픈소스다.