컬럼뷰 탐색기 build vs buy 기록
GeekNews에 SpanFinder라는 프로젝트가 올라왔다. “윈도우 탐색기가 답답해서 만든 맥 스타일(Miller Columns) 파일 탐색기.” 맥 Finder의 컬럼뷰를 WinUI 3로 옮긴 개인 오픈소스였다. 첫 반응은 단순했다 — “어, 이거 나도 필요한데.”
바로 따라붙은 질문이 있었다. “그럼 그냥 기성품을 쓰면 되는 거 아닌가?”
후보를 나열하고, 손으로 만져봤다
SpanFinder를 바로 깔지 않았다. 기존에 자리잡은 기성품이 있을 테고, 그 스펙트럼을 먼저 봐야 “그냥 써도 되는 영역”인지 아닌지가 보인다. 먼저 유명한 후보를 정리했다.
| 후보 | 컬럼뷰 | 비고 |
|---|---|---|
| files-community/Files (OSS) | 일급 시민 | 윈도우 OSS 탐색기, 기능 많음, README 첫 스크린샷이 miller-columns.gif |
| OneCommander | 지원 | 무료/유료 두 트랙, 듀얼 패널 위주 |
| Total Commander | 중심 아님 | 듀얼 패널 사고방식 |
| Directory Opus | 가능 | 가격↑, 기능 너무 많음 |
OneCommander를 실제로 깔고 30분 정도 만져봤다. 결론은 빨랐다.
너무 복잡하고 불편함. 그냥 기존 파일 탐색기랑 비슷하게 생겼으면 좋겠음. 거기에 컬럼뷰가 기본일 뿐이고.
OneCommander는 “강력한 파일 매니저” 진영의 사고방식으로 만들어진 도구다. 패널, 액션, 메뉴, 단축키가 이미 너무 많고, 처음 켜면 어디부터 봐야 할지 모르겠다. 내가 원하는 건 정확히 그 반대였다 — Windows Explorer를 그대로 두고 메인 뷰만 컬럼으로 바꾼 것.
이 시점에 build vs buy의 답이 또렷해졌다. 기성품들은 모두 “파일 매니저”의 자장 안에 있는데, 내가 원하는 건 “탐색기 + 컬럼뷰”였다. 두 사고방식은 기능 차이가 아니라 정체성 차이다. 기성품을 길들여서 내가 원하는 모양으로 만드는 비용이, 처음부터 작게 만드는 비용보다 오히려 클 수 있다.
MVP를 충분히 작게 깎을 수 있는가
“직접 만든다”는 건 보통 시간 비용이 큰 결정이다. 정당화하려면 범위가 충분히 작아야 한다. 그래서 먼저 MVP를 깎았다.
꼭 필요한 것
- Miller Columns 메인 뷰
- 키보드 네비게이션
- 시스템 아이콘 (탐색기 그대로)
- 사이드바 (Quick access 정도만)
- 브레드크럼
일단 빼는 것
- 파일 더블클릭으로 자동 실행 (단축키나 작업표시줄 핀으로 띄워서 쓰면 됨)
- 테마 (라이트만)
- FTP/SFTP, Git 통합, 압축 해제 등
- “문서/사진/음악/동영상” 같은 분류 사이드바 항목
이렇게 깎으니 진짜 작아졌다. 메인 윈도우 1개, 컬럼 컨트롤 1개, 파일 시스템·아이콘 서비스 각 1개. 며칠 안에 굴러가는 MVP가 나올 규모다.
“Windows Explorer의 감촉”을 그대로 내기 위해 WPF + Win32 조합을 택했다. 여기서 build 결정이 떨어졌다.
셸 컨텍스트 메뉴 — 어른의 우회
build 도중에 판단이 필요했던 순간이 있다. 우클릭 컨텍스트 메뉴 얘기다.
윈도우 탐색기에서 우클릭하면 7-Zip, VS Code, “Open with…” 같은 셸 확장이 줄줄이 뜬다. 이걸 ColumnFinder에서도 그대로 보여주려면 윈도우의 셸 컨텍스트 메뉴 COM 인터페이스를 거쳐야 한다. 처음엔 이게 당연한 목표였다 — 탐색기 느낌을 내려면 우클릭도 탐색기랑 같아야지.
몇 번을 고쳐도 수렴이 안 됐다. 직접 COM을 다루는 경로는 access violation이 뜨면 .NET에서 catch 자체가 안 되는 영역이라 디버깅이 밑 빠진 독이었고, OSS들이 쓰는 Vanara.Windows.Shell로 갈아타도 특정 확장자에서 강종이 났다. 셸 확장 중 누군가(아마 특정 에디터의 익스텐션)가 죽이는 거였는데, 이건 내가 잡을 수 있는 범위가 아니었다.
여기서 질문을 바꿨다. “모든 셸 확장을 다 띄우는 것”이 ColumnFinder의 정체성에 꼭 필요한가? 아니었다. 내가 매일 우클릭에서 실제로 쓰는 건 열기/잘라내기/복사/붙여넣기/이름변경/삭제 정도고, 나머지는 어쩌다 한 번이다. 그래서 자체 메뉴 6개 + “탐색기에서 보기” fallback으로 방향을 틀었다. 7-Zip이나 VS Code 익스텐션이 필요하면 “탐색기에서 보기”를 눌러서 그 파일이 선택된 채로 진짜 탐색기를 열면 된다. 특수 케이스는 OS에게 위임.
사이드 프로젝트의 정체성은 “내가 쓸 만한 도구”이지 “완벽한 도구”가 아니다. 며칠짜리 디버깅을 한 시간짜리 우회로 닫았다. 기술적으로 풀 수 있는 문제를 기술로 푸는 대신 요구사항을 움직여 푸는 판단이 사이드 프로젝트에선 더 자주 옳다.
정리: 판단의 기준
오늘의 판단을 되돌아보면 기준은 네 가지였다.
- 기성품의 사고방식과 내가 원하는 것의 사고방식이 일치하는가. 같은 기능을 다른 사고방식으로 제공하면, 길들이는 비용이 만드는 비용보다 클 수 있다. ColumnFinder의 경우 “탐색기 + 컬럼뷰” vs “강력한 파일 매니저”의 정체성 차이가 결정적이었다.
- MVP를 충분히 작게 깎을 수 있는가. “내가 안 쓸 기능을 다 빼고도” 의미 있는 도구가 되는가. 답이 yes면 build의 비용이 작아진다.
- 기성품을 손으로 진짜 만져봤는가. 스크린샷과 README로 build/buy를 결정하면 안 된다. OneCommander를 셋업해서 30분 만져본 게 결정적 분기였다. “이건 내 사고방식이 아니구나”는 손으로만 알 수 있다.
- 기술로 못 풀 땐 요구사항을 움직여본다. 셸 컨텍스트 메뉴는 “모든 셸 확장을 다 띄우는 게 정말 필요한가”로 질문을 바꾸니 한 시간짜리 우회로 닫혔다. 사이드 프로젝트에선 기술적 완결성보다 내가 안 쓸 범위를 쳐내는 판단이 더 자주 옳다.
사이드 프로젝트의 매력은 본인이 안 쓰는 기능 한 줄도 안 들어가는 것이다. ColumnFinder도 그 원칙으로 가져가려고 한다.