들어가며
최근 회사 업무를 진행하면서, 업무 중 발생한 파일을 관리하는 방법에 대해서 고민해보게 되었다. 온라인 업무를 진행하면 파일은 필연적으로 발생하게 되어 있다. 이것을 빠르고 정확하게 전달하며 관리하는 것은 사무실에서 일하는 사람에게 꼭 필요한 능력이다. 나만의 파일 저장 패턴을 구축해보기로 한다.
현재 나의 상황
나의 상황은 개발자이며, 관리해야하는 파일은 기획자에게 넘어온 기획 문서, 디자이너에게 받은 디자인 문서, 개발자 분들이 나눠 공유하는 API 설계 문서 등이다. 이 문서들은 수시로 바뀌며, 언제 무엇이 바뀌었는지 따라가면서(추적하면서) 파일을 잘 관리하는 것이 관건이다.
최근 문서들은 온라인 공유 문서라서 여러 사람이 같은 문서를 동시에 열고 편집할 수 있다. 하지만 두 사람이 같은 곳을 동시에 고치면 한 사람의 수정이 다른 사람의 수정을 덮어쓰는 충돌이 일어날 수 있고, 같이 수정하는 과정에서 기존에 적혀 있던 내용이 지워져(휘발되어) 다시 찾을 수 없게 되기도 한다. 공유 문서 하나에만 기대면 이렇게 사라진 예전 내용을 돌아볼 곳이 없다. 그래서 받은 문서를 시점마다 내 쪽에 따로 저장해 두는 개인 파일 관리가 꼭 필요하다고 생각했다.
나만의 파일 명명 규칙
파일을 잘 관리하는 방법은 몇가지 방법이 있다고 생각했다.
- 나에게 전달된 문서는 보안에 문제가 되지 않으면 저장한다. (무엇이 보안에 문제가 되는지의 기준은 이 글에서 정하지 않았다)
- 파일을 생성할 때 파일의 이름은 1번 정하면 수정하지 않는다.
- 파일에는 저장한 날짜가 필수적으로 들어간다.
- 파일에는 저장한 버전이 들어간다.
- 프로젝트마다 폴더를 나눈다.
- 파일은 1개만 따로 분리해도 사용자가 열기전에 내용을 알 수 있어야한다.
2번과 4번을 같이 지키려면, 문서가 고쳐져 버전이 오를 때 기존 파일의 이름을 바꾸는 게 아니라 날짜와 버전이 다른 새 파일을 하나 더 저장하게 된다. 그래서 예전 버전 파일이 그대로 남는다.
위의 내용을 고안해서 만들어낸 나의 명명 규칙은 이렇게 작명하기로 했다.
YYYY-MMDD_PROJECT_CATEGORY_FILENAME_VERSION.확장자
대문자 단어는 그 자리에 실제 값을 넣으라는 뜻이다. 각 자리에 들어가는 값은 이렇다.
YYYY-MMDD— 저장한 날짜.YYYY는 연도 4자리,MM은 월 2자리,DD는 일 2자리다. 2025년 4월 23일이면2025-0423이 된다PROJECT— 프로젝트 이름CATEGORY— 문서 종류. 아래 「폴더 카테고리」의 이름(기획, 디자인, 기술명세 등)이 들어간다FILENAME— 문서 이름VERSION— 버전.V0_1은 버전 0.1,V1_2는 버전 1.2다. 점 대신 밑줄(_)로 썼다확장자— 파일 종류를 나타내는 확장자 (md,pdf,xlsx등)
이렇게 정리하면 파일을 저장한 날짜와 버전을 바로 알 수 있을 뿐더러 어떤 프로젝트의 어떤 업무에서 사용하는 파일인지 바로 알 수 있어 편리 할것으로 예상한다. 폴더 정리도 프로젝트와 카테고리별로 정리하면 되니 아주 편리할 것이다. 한 동안 이렇게 정리해 사용해 보기로 한다. 이 글을 쓴 시점에는 아직 실제로 써 보기 전이라, 이 문단의 「편리할 것」은 기대이고 결과가 아니다.
파일 정리 예시
작명 규칙의 예시를 통해 빠르게 습득하고, 이해하는 시간을 가져 보았다. 예시의 GGOGIT은 PROJECT 자리에 넣은 프로젝트 이름이다.
2025-0423_GGOGIT_기획_기능정의서_V0_1.md2025-0424_GGOGIT_디자인_와이어프레임_V1_0.pdf2025-0425_GGOGIT_기술명세_API목록_V1_2.xlsx
첫 번째 줄을 자리별로 끊어 읽으면 이렇다. 2025년 4월 23일(2025-0423)에 저장한, GGOGIT 프로젝트(GGOGIT)의 기획 문서(기획) 중 기능정의서(기능정의서)이고, 버전은 0.1(V0_1)이며, 마크다운 파일(.md)이다.
버전 번호에서 앞자리와 뒷자리를 각각 언제 올리는지는 이 글에서 정하지 않았다.
폴더 카테고리
개발자가 만날 수 있는 폴더 카테고리는 아래와 같을 것으로 예상한다. GPT가 추천해준 폴더들은 아래와 같은데 모두 사용할 것 같지는 않다. 하지만 정리해 보기로 한다. 문서 종류 하나하나의 뜻은 링크로 넘기고, 여기서는 「어떤 폴더에 무엇이 들어가는가」만 본다.
- 기획: 기능정의서, 요구사항 정의서, 스토리보드 등 초기 구상 문서
- 디자인: 와이어프레임, UI 시안, 프로토타입 등
- 회의록: 회의 요약, 액션 아이템 정리
- 기술 명세(명세는 무엇을 어떻게 만들지 정해 적은 문서다): API 명세, 시스템 아키텍처, 기술 스택 설명 등
- 개발: ERD, 코드 샘플, 설정 파일 설명 등
- 테스트: 테스트 케이스, 테스트 결과 정리
- 운영(서비스를 내놓은 뒤 계속 돌아가게 관리하는 일): 배포 매뉴얼, 운영 정책, 장애 대응 문서
- 매뉴얼: 사용자 매뉴얼, 관리자 가이드 등
- 이슈 정리: 버그 리포트, 이슈 로그(해결해야 할 문제를 적어 둔 기록), 해결 방법 등
- 버전 관리: 변경 이력, git 전략(브랜치를 어떻게 나누고 합칠지 같은 git 사용 규칙), 릴리스 노트 등
- 보안: 인증/인가 정책, 보안 이슈 대응 문서
- DB정의: 테이블 정의서, 인덱스 정의, 쿼리 최적화(더 빠르게 고치는 일) 노트 등
- 스크립트(여러 명령을 파일 하나에 모아 순서대로 실행하게 만든 것. 셸 스크립트 참고): 배포 스크립트, 초기화 스크립트 등
- 자동화: CI/CD 파이프라인 정의, 스크립트 설명서
- 회고: 프로젝트 회고, 개인 피드백, 기술 회고 등
- 자료조사: 참고 자료, 레퍼런스 모음(본보기로 삼을 다른 서비스 · 문서의 예), 벤치마킹 내용
- 프레젠테이션: 발표자료, 설명용 PPT
- 교육자료: 온보딩 문서, 개발자 교육 자료
- 라이센스: 소프트웨어 라이센스, 오픈소스 사용 규칙등
이 리스트 중에서 개발자가 자주 사용할 문서는 기획, 디자인, 개발, 운영, 테스트, 문서화 정도로 예상한다. 이 중 「문서화」는 위 목록에 없는 이름이다. 이때 어느 카테고리를 가리켰는지는 적어 두지 않았다.
폴더 샘플 구조
위의 내용을 정리해서 나온 폴더구조를 작명해보면 아래와 같다. 맨 위 project-root/는 프로젝트 하나의 맨 바깥 폴더라는 뜻으로 붙인 자리 이름이고, 실제로는 프로젝트 이름을 넣는다.
project-root/
│
├── 01_기획/
│ ├── 요구사항정의서/
│ │ └── 2025-0423_GGOGIT_기획_요구사항정의서_V0_1.md
│ ├── 기능정의서/
│ │ └── 2025-0424_GGOGIT_기획_기능정의서_V0_2.md
│ └── 스토리보드/
│ └── 2025-0425_GGOGIT_기획_스토리보드_V0_1.pdf
│
├── 02_디자인/
│ ├── 와이어프레임/
│ │ └── 2025-0426_GGOGIT_디자인_메인화면_V1_0.pdf
│ ├── UI시안/
│ └── 아이콘시안/
│
├── 03_개발/
│ ├── ERD/
│ │ └── 2025-0427_GGOGIT_개발_ERD초안_V1_0.pptx
│ ├── 설정정의/
│ └── 코드샘플/
│
├── 04_기술명세/
│ ├── API명세/
│ │ └── 2025-0428_GGOGIT_기술명세_API목록_V1_1.md
│ ├── 시스템아키텍처/
│ └── 보안정의/
│
├── 05_테스트/
│ ├── 테스트케이스/
│ └── 테스트결과/
│
├── 06_운영/
│ ├── 배포매뉴얼/
│ └── 장애대응/
│
├── 07_회의록/
│ └── 2025-0429_GGOGIT_회의록_주간회의_V0_1.docx
│
├── 08_이슈정리/
│ ├── 버그리포트/
│ └── 해결기록/
│
├── 09_교육자료/
│ ├── 온보딩/
│ └── 기술회고/
│
└── README.md
그림을 위에서부터 따라가면 이렇다.
├──와└──는 폴더 안에 든 항목을 가리키는 선이다.└──는 그 폴더의 마지막 항목이다- 프로젝트 폴더 바로 아래에 카테고리 폴더(
01_기획/부터09_교육자료/까지)가 있다. 이름 앞의01_~09_번호는 명명 규칙에는 없던 것으로, 이 구조를 그리면서 붙였다. 왜 이 순서인지는 이때 적어 두지 않았다 - 카테고리 폴더 아래에 문서 종류별 폴더(
요구사항정의서/,와이어프레임/등)가 한 단계 더 있다. 앞에서 「프로젝트와 카테고리별로」 나눈다고 했던 것보다 한 단계 깊다 - 그 안에 명명 규칙대로 지은 파일이 들어간다.
.docx는 워드,.pptx는 파워포인트 파일이다 - 맨 아래
README.md는 이 프로젝트 폴더가 무엇인지 소개하는 파일이다
이 구조는 앞의 카테고리 목록과 몇 군데 어긋난다. 자주 쓸 것으로 고른 것은 여섯 개인데 구조에는 기술명세 · 회의록 · 이슈정리 · 교육자료까지 아홉 개가 들어갔다. 목록에서 「DB정의」에 있던 테이블 정의와 가까운 ERD는 03_개발/에, 따로 있던 보안은 04_기술명세/보안정의/에, 「회고」에 있던 기술 회고는 09_교육자료/에 들어갔다. 와이어프레임 폴더 안의 파일은 FILENAME 자리에 문서 종류 대신 내용(메인화면)을 넣었다. 이 글을 쓸 때 이런 차이를 어떤 기준으로 정했는지는 적어 두지 않았다.
이런식으로 폴더의 구조가 그려진다. 이것은 개인적으로 프로젝트를 관리할 때는 아주 좋은 구조로 판단된다. 다른 정리 방법과 견주어 본 것은 아니고, 날짜 · 버전 · 프로젝트 · 카테고리를 파일 이름과 폴더만 보고 알 수 있다는 점에서 그렇게 판단했다. 앞으로 이렇게 프로젝트를 관리해 보기로 한다.
자신만의 철학을 만들어가는 중입니다.
댓글남기기