전문적인 인공지능 프로젝트 디렉터리 구조

final.ipynb, final2.ipynb, really_final.ipynb처럼 이름 붙인 노트북이 쌓이면 인공지능 프로젝트는 무너집니다. 일관된 디렉터리 구조는 프로젝트를 읽기 쉽고 재현 가능하게 하며 협업하기 좋게 만듭니다.

이 단원에서는 널리 사용되는 쿠키커터 데이터 사이언스 구조를 다룹니다.

원시 입력이 덮어써지지 않도록 처리 단계에 따라 데이터를 분리합니다.

• data/raw/ — 원본이며 변경할 수 없는 소스 데이터
• data/processed/ — 정제되어 모델에 바로 사용할 수 있는 데이터
• data/interim/ — 중간 변환 결과

data/raw는 읽기 전용으로 취급합니다. 항상 이 폴더에서 다른 모든 데이터를 다시 생성할 수 있어야 합니다.

데이터의 유일한 사본이 정제 과정의 버그로 손상되면 프로젝트를 되살릴 수 없습니다. data/raw를 그대로 유지하면 처리된 모든 파일을 작업 흐름을 다시 실행하여 재현할 수 있습니다.

처리된 출력은 버려도 되지만, 원시 데이터는 절대 훼손해서는 안 됩니다.

notebooks/에는 탐색 및 보고서 작성용 노트북을 저장합니다. 일반적으로 단계별 번호와 작성자의 이니셜을 붙입니다. 예를 들어 1.0-mk-eda.ipynb와 같이 이름을 지정합니다.

노트북은 탐색에 사용하고, 재사용 가능한 논리는 src/로 옮겨야 합니다.

src/에는 가져올 수 있는 파이썬 코드가 책임별로 나뉘어 들어 있습니다.

• src/data/ — 데이터를 불러오고 처리하는 스크립트
• src/features/ — 특징 공학
• src/models/ — 학습 및 예측 코드
• src/visualization/ — 그래프 및 보고서

특징 공학과 모델링을 별도의 모듈로 유지하면 여러 이점이 있습니다. 특징 코드를 단위 테스트하고, 여러 노트북에서 재사용하며, 데이터 준비 코드를 다시 작성하지 않고도 모델을 교체할 수 있습니다.

models/에는 직렬화된 학습 모델 산출물(예: model.pkl, model.joblib)을 저장합니다. 이는 소스 코드가 아니라 출력 결과입니다.

대용량 모델 파일은 일반적으로 깃에 저장하지 말고, 대신 DVC나 객체 스토리지로 관리해야 합니다(다음 단원에서 다룹니다).

reports/에는 사람이 읽는 생성 결과를 저장합니다. 그래프는 reports/figures/에 저장하고, 최상위 수준에는 보고서 문서를 둡니다. 이러한 결과는 코드로 생성하므로 다시 만들 수 있습니다.

다음 프로젝트 수준의 파일로 프로젝트를 완성합니다.

• requirements.txt 또는 environment.yml — 의존성
• config.yaml — 하이퍼파라미터 및 경로
• README.md — 프로젝트의 내용과 실행 방법
• .gitignore — 깃이 건너뛸 항목

이를 모두 합치면 깔끔한 인공지능 프로젝트는 다음과 같은 모습입니다.

매번 이 구조를 손으로 만들 필요는 없습니다. 쿠키커터 데이터 사이언스 템플릿을 사용하면 한 번의 명령으로 전체 구조의 뼈대를 만들 수 있습니다.

데이터 제공자로부터 원본 CSV를 다운로드합니다.

전문적인 인공지능 프로젝트 구조를 배웠습니다.

• data/raw(변경 불가) 및 단계별 데이터를 위한 data/processed
• 탐색을 위한 notebooks/, 재사용 가능한 코드를 위한 src/features 및 src/models
• 산출물을 위한 models/, 출력 결과를 위한 reports/
• 루트에 구성 파일, 의존성 파일, README, .gitignore 배치
• 즉시 구조의 뼈대를 생성하는 쿠키커터 데이터 사이언스

다음 주제: 인공지능 프로젝트에서 깃을 효과적으로 사용하는 방법입니다.