프로젝트 폴더 구조 가이드: Mac 사용자를 위한 실전 정리법

프로젝트를 보내려는데 편집 가능한 파일은 데스크탑에 있고, 승인받은 PDF는 다운로드 폴더에 있고, 또 다른 내보내기 파일은 'Final_New'라는 폴더 깊숙이 묻혀 있습니다. 어떻게 된 일인지는 본인이야 짐작할 수 있겠죠. 하지만 이 프로젝트를 처음 여는 다른 사람은 알 수 없습니다.

쓸모 있는 프로젝트 폴더 구조는 이런 결정들이 기억에만 의존하지 않게 해 줍니다. 들어온 자료, 편집 중인 작업, 전달한 파일에 저마다 예측 가능한 자리를 주고, 프로젝트를 마무리할 때도 맥락을 잃지 않게 해 주죠. Mac에서는 이름과 폴더부터 시작하세요. 시각적인 단서는 기본 구조가 제대로 잡힌 다음에 더해도 늦지 않습니다.

템플릿을 복사해 최상위 구조 만들기 ​

아래에서 가장 비슷한 템플릿을 고르세요. 시작점으로 삼을 구성일 뿐, macOS가 강제하는 규칙은 아닙니다.

핵심은 입력, 편집 중인 작업, 결과물을 나누는 것입니다. 내려받은 참고 이미지는 작업 중인 디자인이 아니고, 내보낸 PDF는 편집 가능한 원본을 대신할 수 없으니까요. 이 역할들을 분리해 두면 다시 만들 수 있는 것과 반드시 보존해야 하는 것을 쉽게 구분할 수 있습니다.

Apple은 File System Programming Guide에서 더 근본적인 구분을 둡니다. /System에는 macOS를 실행하는 데 필요한 리소스가 들어 있어 수정하면 안 되고, /Users에는 사용자의 홈 디렉토리가 들어 있다는 것이죠. 프로젝트 루트는 운영체제 리소스 사이가 아니라 사용자가 관리하는 저장 공간에 두세요.

작업 방식에 맞춰 템플릿 고르기 ​

디자인 프로젝트라면 누구든 파일을 저장하기 전에 03_Source와 04_Working의 차이부터 정의하세요. 실용적인 관례는 받은 에셋과 재사용할 마스터는 Source에, 구성물과 진행 중인 수정본은 Working에 두는 것입니다. 이 차이를 명확하게 설명할 수 없다면, 모호한 저장 위치를 유지하느니 두 역할을 합치는 편이 낫습니다.

연구라면 들어온 데이터는 02_Data_Raw에 그대로 보존하세요. 가공한 데이터셋은 03_Data_Clean에 두고, 어떻게 만들었는지 기록해 둡니다. 그래야 분석을 수정할 때 누군가 원본 스프레드시트를 고쳤는지 추측하지 않아도 됩니다.

소프트웨어 개발은 번호 패턴에서 의도적으로 벗어나는 예외입니다. 저장소, 프레임워크, 빌드 도구가 기대하는 디렉토리 이름을 그대로 쓰세요. build는 자동 생성되는 결과물로 취급하고 버전 관리에서 제외하도록 설정하세요. 도구가 다른 위치를 기대하는 파일을 손으로 옮기면 안 됩니다.

클라이언트 작업에서는 Deliverables는 실제로 보낸 것을 뜻합니다. 후보 프레젠테이션은 전달하기 전까지 Working에 둡니다. 승인되지 않은 초안이 전달 기록처럼 보이는 일을 막아 줍니다.

Finder에서 프로젝트 만들기 ​

1. 영구적인 루트를 정하세요. 문서 폴더나 홈 폴더 안에 Projects 폴더를 만들고, 진행 중인 프로젝트를 거기에 모읍니다. 이유는 실용적입니다. 바쁠 때도 꼭 쓰게 될 목적지가 필요하거든요. 흔한 실수는 데스크탑에서 작업을 시작하고 나중에 정리하겠다고 약속하는 것입니다. 데스크탑 저장이 잘못은 아니지만, 임시 저장과 의도적인 정리를 헷갈리기 쉽게 만듭니다.

2. 프로젝트에 알아보기 쉬운 이름을 주세요. 클라이언트 코드나 의미 있는 날짜에 짧은 설명을 붙여 Acme_Rebrand나 YYYY-MM_Acme_Rebrand처럼 짓습니다. 대화나 인수인계에서 실제로 쓰는 식별자를 고르세요. New_Project 같은 모호한 루트는 피하고, 한 클라이언트의 프로젝트를 여러 개 꾸준히 관리하는 경우가 아니라면 클라이언트 단계를 따로 두지 마세요.

3. 고른 행의 폴더를 만드세요. 번호가 붙은 템플릿은 두 자리 접두사 뒤에 밑줄을 붙입니다. 01은 관리, 브리프, 계약서로, 02는 참고 자료나 들어온 자료로, 03은 해당하는 경우 작업 콘텐츠로 쓰고, 그 뒤 번호에는 템플릿에 따라 분석, 결과물, 내보내기, 인보이스를 둡니다. 보관 처리한 자료용으로는 99_Archive를 따로 비워 두세요. 번호는 순서를 정할 뿐, 보편적인 분류 체계가 아닙니다.

4. 루트에 README를 쓰세요. 프로젝트의 목적, 담당자, 각 폴더에 무엇이 들어가는지 적습니다. 새로 온 사람이 오해하기 쉬운 구분, 특히 Source와 Working, Outputs와 Deliverables의 차이를 꼭 넣으세요. 흔한 실수는 폴더 목록만 적는 것입니다. 원본 데이터를 수정해도 되는지, 승인 기록은 어디에 있는지, 인수인계 기록은 어느 디렉토리에 있는지 같은 결정 사항을 설명하세요.

5. 빈 사본을 템플릿으로 저장하세요. 재사용하려고 보관하기 전에 프로젝트 고유의 에셋, 비공개 계약서, 클라이언트 정보를 지웁니다. 폴더 설명은 남기고, 담당자와 목적은 명확한 안내 문구로 바꿔 두세요. 진행했던 프로젝트를 정리하지 않고 그대로 복사하면 쓸모없는 파일과 낡은 전제가 다음 작업까지 따라옵니다.

가능한 모든 하위 폴더를 미리 만들어 둘 필요는 없습니다. 설명할 수 있는 목적지부터 시작하고, 실제 자료가 필요로 할 때 세부 구조를 더하세요. 템플릿은 반복되는 결정을 없애 주는 도구이지, 빈 카테고리를 일일이 뒤지게 하는 도구가 아닙니다.

마지막으로 Finder에서 열 보기 테스트를 해 보세요. 이름순으로 정렬하고 프로젝트 루트를 연 다음, 최상위 폴더를 순서대로 읽어 봅니다. 폴더를 하나하나 열지 않고도 들어온 자료에서 작업, 전달까지의 흐름을 설명할 수 있어야 합니다.

폴더 순서를 유지해 주는 이름 규칙 ​

이름은 열어 보지 않고도 근처 항목들을 구분하게 해 줘야 합니다. 원래 폴더 밖의 검색 결과에 나타나도 의미가 통해야 하고요.

저장할 때마다 규칙을 새로 만들지 말고, 간단한 체크리스트를 쓰세요.

• 접두사를 일관되게 쓰세요. 자릿수가 섞이면 순서 목록을 유지하기 어렵습니다. 나쁜 예: 1_Admin, 02_References, 3_Working. 좋은 예: 01_Admin, 02_References, 03_Working.
• 예측 가능한 구분 기호를 고르세요. 의미 있는 단어 사이에는 밑줄을, 날짜나 코드 안에서는 하이픈을 씁니다. 나쁜 예: Acme / Brand & Web. 좋은 예: Acme_Brand_Web.
• 날짜는 큰 단위부터 작은 단위 순으로 쓰세요. 시간순 정렬이 중요하면 YYYY-MM-DD를 씁니다. 나쁜 패턴: DD-MM-YYYY_Review. 좋은 패턴: YYYY-MM-DD_Review.
• 구별해 주는 단어가 눈에 띄게 하세요. 임의의 글자 수 제한을 두는 대신 군더더기를 없앱니다. 나쁜 예: All_The_Working_Documents_For_The_Acme_Rebrand. 좋은 예: Acme_Rebrand_Working.
• 불필요한 문장 부호는 피하세요. 일반 문자, 숫자, 밑줄, 하이픈이 스크립트에서 다루기 쉽습니다. 나쁜 예: Client's Draft (Approved?). 좋은 예: Acme_Proposal_v03.
• 하나의 역할에는 하나의 용어만 쓰세요. 같은 목적지를 뜻하면서 Exports, Output, Rendered를 번갈아 쓰지 마세요. 나쁜 예: Exports와 Exported_Files라는 형제 폴더. 좋은 예: 문서로 정리된 05_Exports 하나.
• 버전과 승인을 분리하세요. 나쁜 예: logo FINAL new 2.ai. 좋은 예: 편집 가능한 마스터의 보관 위치로 정해 둔 03_Source 안의 Acme_Logo_v03.ai. 승인은 Final을 또 붙이지 말고 전달 기록에 남기세요.

이름은 신중하게 바꾸기 ​

버전 번호는 수정본을 식별할 뿐, 승인을 증명하지 않습니다. 마찬가지로 Old라는 폴더는 내용물이 대체된 것인지, 반려된 것인지, 참고용으로 남긴 것인지 알려 주지 않습니다.

좋은 이름은 항목을 설명합니다. 좋은 기록은 그 항목에 무슨 일이 있었는지 설명합니다.

파일을 복사하고, 동기화하고, 보관해도 이름의 의미는 유지됩니다. 색상과 아이콘만으로는 그 역할을 해낼 수 없습니다.

이미 쌓여 있는 파일이라면 Mac에서 파일 이름 일괄 변경하기 가이드에서 설명한 것처럼 미리보기를 먼저 확인하는 방식을 쓰세요. 변경을 적용하기 전에 중복된 대상 이름과 연결된 파일이 없는지 확인하세요.

프로젝트 폴더는 만들 때 이름을 정하고, 범위가 바뀌지 않는 한 그대로 유지하세요. 이름을 바꿨다면 이전 이름과 이유를 README에 기록합니다.

폴더, 태그, 스마트 폴더는 각자 하는 일이 다릅니다 ​

폴더는 도서관의 서가이고, 태그는 책에 붙인 포스트잇입니다. 스마트 폴더는 조건에 맞는 책을 서가에서 빼내지 않고 한자리에 보여 주는 저장된 검색이죠.

이 구분이 중요한 이유는 우리가 서로 다른 질문에 답하고 있기 때문입니다. 이건 어디에 속하지? 무엇을 신경 써야 하지? 어떤 것들을 모아서 보고 싶지? Apple의 Finder 정리 안내서도 중첩 폴더, 태그, 스마트 폴더를 항목을 정리하고 찾는 서로 보완적인 방법으로 설명합니다.

빈 폴더를 만든다고 아무것도 이동하지는 않습니다. 표에서 짚은 차이는, 파일 정리는 항목의 물리적 위치를 바꾸지만 태그와 저장된 검색은 그렇지 않다는 점입니다.

고정된 보관 위치와 변하는 보기 구분하기 ​

클라이언트 프레젠테이션을 준비한다고 해 봅시다. 편집 가능한 덱은 프로젝트의 Working 폴더에 둡니다. 피드백을 기다리는 동안에는 검토 태그를 붙이고, 검토가 끝나면 지웁니다.

덱을 따로 만든 Needs_Review 트리로 옮길 필요는 없습니다. 그러면 덱의 위치가 임시 상태에 좌우되고, 협업하는 사람들이 이전 위치에서 파일을 찾아 헤맬 수 있거든요.

스마트 폴더는 더 넓은 질문에 답합니다. 진행 중인 프로젝트 전체에서 최근에 수정한 PDF를 모으거나, 업무 태그가 붙은 파일을 보여 줄 수 있습니다. 전체 파일을 그대로 재현하지 말고, 결과가 특정 작업을 돕도록 조건을 다듬으세요.

이런 보기를 뒷받침하는 탐색 요령은 Mac Finder 팁에서 더 볼 수 있습니다. 작업에 맞는 보기를 고르세요. 위치를 추적할 때는 열 보기를, 모양으로 에셋을 알아볼 때는 시각적인 미리보기를 쓰면 됩니다.

주의 표시는 아껴서 쓰기 ​

모든 것에 긴급이 붙어 있으면 긴급은 쓸모가 없어집니다. 각 동작 태그를 붙일 자격이 무엇인지, 누가 떼는지 정해 두세요. 그렇지 않으면 어제의 우선순위가 영원한 장식이 됩니다.

집중을 유지하는 것 자체가 어렵다면, Jan Kutschera의 ADD가 있는 창업자를 위한 정리 팁이 개인 정리에 대해 생각해 보는 데 보완이 되는 자료입니다. 태그는 라벨을 고민하지 않고 붙일 수 있을 만큼 적게 유지하세요.

이 판단 규칙을 쓰세요. 답이 프로젝트 기간 중에 바뀐다면 태그를, 프로젝트가 끝날 때까지 그대로라면 폴더를 쓰세요. 그 위치들을 가로지르는 재사용 가능한 보기가 필요하면 스마트 폴더를 쓰면 됩니다.

구조가 무너지기 전까지 얼마나 깊이 중첩할까 ​

깊이는 습관이 아니라 찾는 데 필요한 만큼 정하세요. 별도 폴더는 사람들이 이해하는 방식으로 검색 범위를 좁혀 줄 때 가치가 있습니다. 그저 Project, Files, Assets라는 이름의 컨테이너를 하나 더 얹는 것뿐이라면 효용이 떨어지죠.

논문 Evaluate, Reorganize, and Share는 의미 기반 정리가 사용자가 정확한 경로를 외우지 않고도 위치를 추론하도록 돕는다고 설명합니다. 새 단계를 추가할 때 던질 올바른 질문이 바로 그것입니다. 그 이름이 남은 선택지를 더 분명하게 만드는가?

아래 다이어그램은 트리가 커질수록 쌓이는 탐색 비용을 보여 줍니다.

각 단계에 역할 주기 ​

아래는 측정된 한계가 아니라 제안하는 구성입니다. 프로젝트 루트 아래의 단계를 세고, 유용한 구분을 나타낼 때만 단계를 추가하세요.

협업하는 사람의 이름을 붙인 폴더가 그 자체로 무언가를 보호해 주지는 않습니다. 보호가 필요하다면 접근 권한을 따로 설정하세요.

Working, Concepts, Campaign, Digital, Social, Approved, Revised, Export 아래 깊숙이 묻힌 가상의 경로를 떠올려 보세요. 이걸 04_Working/Social/Acme_Campaign_v03.ai로 평평하게 만들고, 생성된 전달용 사본은 지정된 내보내기 위치에 둡니다. 결정마다 폴더를 만들지 않아도 파일 이름이 수정본을 식별해 줍니다.

클릭 수가 아니라 검색 성공 여부로 테스트하기 ​

동료에게 참고 에셋, 편집 가능한 파일, 승인 기록, 전달한 결과물, 보관된 수정본을 찾아 달라고 부탁해 보세요. 어디서 머뭇거리는지 지켜보고, 그럴듯한 파일이 아니라 올바른 항목을 찾았는지 기록합니다.

• 반복적으로 되돌아간다면 카테고리 이름이 서로 겹친다는 신호입니다.
• 형제 폴더를 전부 열어 본다면 분류가 찾는 작업과 맞지 않는다는 신호입니다.
• 오래된 수정본을 찾았다면 버전이나 전달 기록을 살펴봐야 한다는 신호입니다.

불필요한 단계는 공유 인수인계를 복잡하게 하고 백업 대상 선택을 점검하기도 어렵게 만듭니다. 완벽하게 대칭인 트리가 깔끔해 보인다는 이유로가 아니라, 내용이 정당화할 때만 하위 폴더를 더하세요.

아무것도 망가뜨리지 않고 색상과 아이콘 레이어 더하기 ​

색이 입혀진 바인더 책등은 그 바인더를 눈에 띄게 해 줍니다. 안에 무엇이 들었는지는 여전히 라벨이 알려 주고요. 폴더 꾸미기도 마찬가지로 작동해야 합니다. 한눈에 알아보는 단서이지, 공식 기록이 아닙니다.

실제 폴더에 빗대면 이 구분이 쉽게 보입니다.

수명 주기 단계에는 색상 계열을, 콘텐츠 역할에는 아이콘을 고르세요. 두 차원은 함께 쓸 수 있습니다. 작업 중인 영상 폴더라면 진행 중 작업 색상에 필름 아이콘을 쓰면 됩니다.

작고 반복 가능한 규칙 적용하기 ​

프로젝트마다 완전히 다른 시각 언어를 주지 마세요. Finder를 훑어볼 때 필요한 구분에만 의미 있는 차이를 두세요.

Apple이 문서화한 확장 속성은 파일 시스템 항목이 연관된 메타데이터를 가질 수 있다는 사실을 확인해 줍니다. 폴더의 겉모습도 그런 종류의 보조 정보로 취급하세요. 프로젝트 내용이나 디렉토리 위치와는 별개입니다.

Tintd의 Folder Watcher는 지정한 위치에 새로 생긴 폴더를 감지해, 이름에 맞는 색상과 아이콘을 자동으로 적용합니다. 일괄 편집기로는 선택한 여러 폴더에 아이콘을 한꺼번에 적용할 수 있고, 개별 변경은 Finder의 마우스 오른쪽 클릭 메뉴에서 할 수 있습니다. 꾸민 폴더는 언제든 한 번의 클릭으로 원래 macOS 아이콘으로 되돌릴 수 있고요.

폴더의 아이콘이나 색상을 바꾸는 것은 순전히 외형상의 변화입니다. 안에 있는 파일이나 하위 폴더에도, 그 경로에도 영향을 주지 않습니다.

아래 영상은 시각 레이어를 적용하는 방법을 보여 줍니다.

다른 Mac과 다른 도구까지 고려하기 ​

사용자 지정 폴더 아이콘은 각 Mac에 로컬로 저장되므로, 팀이 쓰는 Mac마다 아이콘 설정을 따로 해야 합니다. 모두가 똑같은 모습을 볼 거라고 가정하지 말고, 매핑 규칙은 서면 안내로 배포하세요.

이 접근 방식에 대한 더 폭넓은 설명은 시각적 파일 관리자 가이드를 참고하세요. 여기서 짚을 구분은 빠른 인식과 믿을 만한 해석의 차이입니다. 익숙한 아이콘은 디렉토리를 알아보는 데 도움이 되지만, 새로 온 사람에게는 여전히 이름과 문서로 정리된 목적이 필요합니다.

메타데이터를 버리는 도구로 복사, 동기화, 보관하면 꾸밈 정보가 사라질 수 있습니다. 겉모습에 의존하기 전에 실제 인수인계 방법으로 테스트하고, 시각적 규칙이 무엇을 뜻하는지는 README에 기록으로 남겨 두세요.

분기별 아카이브 점검으로 구조 유지하기 ​

프로젝트 폴더 구조는 살아 있는 시스템입니다. 새로운 협업자, 수정된 결과물, 예상치 못한 원본 자료가 처음엔 합리적이던 구성을 덜 쓸모 있게 만들 수 있습니다.

애리조나 대학교의 데이터 정리 가이드는 원본과 작업 파일을 분리하고 자료가 어떻게 정리되어 있는지 문서로 남기라고 뒷받침합니다. 이것을 한 번 해 놓고 다시 보지 않는 설정 작업이 아니라, 계속 이어지는 책임으로 삼으세요.

아래 수명 주기를 점검 리듬으로 활용하세요.

책임이 바뀌면 프로젝트도 옮기기 ​

• 수집에서 진행 중인 작업으로: 들어온 자료의 목적과 담당자를 파악했다면 알맞은 카테고리로 옮깁니다.
• 진행 중인 작업에서 검토로: 단계가 끝나거나, 협업자가 합류하거나, 사람들이 자료를 계속 잘못 정리할 때 구성을 점검합니다.
• 검토에서 전달로: 승인된 결과물을 확정하고, 넘겨준 사본을 정확히 그대로 보관합니다.
• 전달에서 아카이브로: 담당자가 진행 중인 의무가 모두 끝났음을 확인하면 보관 처리합니다.
• 아카이브에서 삭제로: 해당 보존 요건이 끝나고 책임 담당자가 폐기를 승인한 뒤에만 삭제합니다.

아카이브는 백업이 아니고, 둘 중 어느 쪽도 삭제 허가를 의미하지 않습니다. 이 결정들은 따로 다루세요.

README에 정리 담당자를 정해 두세요. '팀' 같은 모호한 표현 말고 실제 사람의 이름으로 적습니다. 그 사람이 재구성을 승인하고 무엇이 바뀌었는지 기록하면, 협업자들이 공유 경로를 제각각 다시 설계하는 일이 없습니다.

분기별 점검 실행하기 ​

현재 최상위 구조를 템플릿과 비교한 다음, 예외를 살펴보세요.

• 어긋난 부분 해결: 링크, 스크립트, 협업자의 의존 관계를 확인한 뒤 불분명한 추가 항목의 이름을 바꿉니다.
• 빈 구조 정리: 내용물을 살펴본 뒤 불필요한 빈 폴더는 삭제하고 겹치는 카테고리는 합칩니다.
• 끝난 작업 보관: 완료된 프로젝트 전체를 상위 레벨의 99_Archive나 아카이브 볼륨으로 옮깁니다.
• 맥락 보존: 프로젝트의 상태, 담당자, 전달 위치, 보존 지침을 적은 날짜가 있는 README를 남겨 둡니다.

프로젝트를 자기 자신의 아카이브 하위 폴더 안으로 옮기지 마세요. 내부 아카이브는 제작 중 대체된 자료에, 상위 아카이브는 완료된 프로젝트에 쓰세요.

계획을 시각적으로 세운다면 Walling의 시각적 노트 작성 인사이트가 결정을 기록하는 보완적인 방법을 알려 줍니다. 거기서 나온 결정은 다시 프로젝트 기록으로 가져오세요.

일관성이 모든 곳의 깊이가 같다는 뜻은 아닙니다. 쓸모 있는 예외는 남기고, 더 이상 도움이 되지 않는 카테고리는 없애세요. 오늘 반복되는 분기별 점검 일정을 만들고, 지금 진행 중인 프로젝트의 완료 후 점검 일정도 잡고, 이번 주 안에 다음 프로젝트를 위한 깨끗한 템플릿을 저장해 두세요.

Tintd는 직접 정의한 구조 위에 사용자 지정 폴더 색상과 아이콘을 더해 줍니다. 기존 폴더에는 일괄 제어를, 새 폴더에는 자동 스타일링을 제공하죠. Tintd에서 진행 중인 작업, 결과물, 아카이브에 일관된 시각적 단서를 주세요. 안에 있는 파일은 건드리지 않습니다.