L01 — Django 프로젝트 구조와 settings 환경 분리

1. 파일 주고받기 — SFTP / Cyberduck

로컬 컴퓨터와 서버 사이에 파일을 주고받는 방법부터.

• FTP(File Transfer Protocol) / SFTP(Secure FTP) = 파일을 주고받는 프로토콜이다.
• Cyberduck 같은 클라이언트로 SFTP 연결을 하면, 로컬 → 서버로 파일을 올리고(업로드) 서버 → 로컬로 파일을 받을(다운로드) 수 있다.
• 예전에는 업로드가 안 돼서 Cyberduck 을 꼭 써야 했지만, 지금은 VS Code(원격 연결)로 다운로드·업로드가 다 된다. 그래서 요즘은 Cyberduck 을 잘 안 쓴다.
• FTP 는 코드 안에서도 서버 → 다른 서버나 다른 IP 로 파일을 보낼 때 쓸 수 있다. "이런 프로토콜이 있다" 정도만 알아두면 된다.

2. 서버에 있는 standarda-template / standarda-core

• 서버 홈 디렉토리(ubuntu)에 standarda-template, standarda-core 폴더가 실제로 있다.
• cookiecutter 로 새 프로젝트를 만들 때는 보통 GitHub 의 standarda-template 레포를 당겨온다. (서버 로컬에 있는 것도 당길 수 있지만, 헷갈릴까 봐 로컬 사본은 지워뒀다.)
• standarda-template 업데이트 방법: 서버에서 standarda-template 코드를 수정한 뒤(스킬·백로그 등 추가) push 한다. 변화가 생기면 자동으로 push 되게 해뒀기 때문에 항상 최신 버전이 유지된다.

3. Django 프로젝트 구조 — 앱들 + 루트(설정) 앱

템플릿 구조 = 우리 프로젝트 구조다. (.claude/, GitHub 설정, 그리고 cookiecutter 의 {project_slug} 폴더)

• Django 는 백엔드 프레임워크다. 폴더 구조가 "앱(app)" 단위로 나뉜다.
• 예를 들어 accounts, export_web, emails, profiles, projects, sms — 이게 전부 Django 앱이다.
• 프로젝트를 처음 셋업하면 프로젝트 이름과 똑같은 이름의 앱 폴더가 하나 생긴다(예: export_web).
• 이 루트 앱은 다른 앱들과 달리 한 가지가 더 있다 — settings 폴더를 가지고 있다.

{프로젝트명}/            ← 루트 앱 (프로젝트 이름과 동일)
├── settings/           ← ★ 이 앱에만 있다
├── urls.py
├── wsgi.py
└── ...
accounts/  profiles/  projects/  emails/  sms/  export_web/   ← 일반 Django 앱들

4. settings 는 파일이 아니라 "패키지"

• 원래 Django 의 settings 는 settings.py 파일 하나다.
• 우리는 이걸 파이썬 패키지(폴더 + __init__.py)로 만들었다. 폴더 안에는:

settings/
├── __init__.py     # 환경에 따라 무엇을 로드할지 고르는 곳
├── base.py         # 공통 설정
├── local.py        # 개발 환경
└── production.py    # 운영 환경

5. __init__.py — 환경에 따라 무엇을 로드하나

# {프로젝트명}/settings/__init__.py
if os.environ.get('{프로젝트명대문자}_PRODUCTION') == 'True':
    load_dotenv(_BASE_DIR / '.env.production', override=True)
else:
    load_dotenv(_BASE_DIR / '.env', override=True)

from .base import *           # 공통을 먼저 다 가져옴

if os.environ.get('{프로젝트명대문자}_PRODUCTION') == 'True':
    from .production import *  # 운영이면 production 으로 덮어씀
else:
    from .local import *       # 아니면 local

• 로직은 단순하다: PRODUCTION 이면 base + production, 아니면 base + local.
• _BASE_DIR: 파이썬 pathlib 의 Path 로 src/(루트) 폴더를 가리킨다. Path(__file__) 에서 부모를 세 번 거슬러 올라가면 src/ 다. src/ 가 항상 프로젝트의 루트(베이스) 폴더다.
• from .base import * 의 * 는 와일드카드 — 해당 모듈에 있는 모든 값을 다 가져온다는 뜻이다.

6. .env / .env.example

• .env.example: 템플릿을 당기면 같이 생성된다. "이 형식대로 채워 넣어라" 는 견본이다.
• 이걸 복사해서 .env 를 만들고, API 키 · ALLOWED_HOSTS · 비밀번호 등을 쫙 채워서 쓴다.
• .env.production.example 도 있다. 나중에 배포(deploy) 할 때 이걸 복사해 .env.production 을 만든다. (지금은 비어 있다.)

비밀값(키·비번)은 settings 코드가 아니라 .env(개발) / .env.production(운영) 에 둔다.

7. 왜 dev / prod 를 나누나

.env 와 production 을 구분하는 이유는, 개발 환경과 운영 환경이 실제로 다르기 때문이다.

• 서버 IP 가 다르다: 개발 서버는 43.200.38.93, 앞으로 운영 서버는 52.79.132.206 에서 관리한다.
• 그래서 ALLOWED_HOSTS 주소부터 달라진다.
• DB 가 다르다: Django 프로젝트는 기본적으로 PostgreSQL 과 연결돼 있다. 개발 서버에는 개발용(로컬) PostgreSQL 이, 운영 서버에는 운영용 PostgreSQL 이 깔려 있고, 각각 연결해야 한다.
• API 키가 다르다: 예를 들어 LLM API 키도 개발용 키는 우리 키, 운영용 키는 고객사 키가 된다.

→ 그래서 환경마다 달라지는 값들을 따로따로 관리한다.

8. 요청이 들어오면 무슨 일이 — settings 로딩 흐름

브라우저 (도메인 입력)
  → DNS 가 도메인 → IP 조회        (예: meetings.popupstudio.ai → 43.200.38.93)
  → 그 서버의 포트로 요청 도착       (현재 dev 서버에 배포됨, 예: :8024 에서 Django 가 대기)
  → Django 가 settings/__init__.py 를 "제일 먼저" 읽음
       → os.environ 에서 {프로젝트명대문자}_PRODUCTION 확인
       → 없으면 else → .env + base + local
       → 있으면(True)        → .env.production + base + production

• os.environ.get(...) 은 시스템(OS) 환경변수를 읽는다. 리눅스에서 그 값들은 /etc/environment 파일에 들어 있다.
• 그래서 코드는 dev/prod 양쪽에 똑같은 한 벌이 올라가고, 갈림은 서버가 만든다 — dev 서버엔 그 키가 없어서 local, 운영 서버엔 {프로젝트명대문자}_PRODUCTION=True 가 박혀 있어서 production 으로 뜬다.
• 결과적으로 settings 의 구성은:
• 개발: base.py 의 모든 내용 + local.py 의 모든 내용
• 운영: base.py 의 모든 내용 + production.py 의 모든 내용

9. base.py 에 들어가는 "공통" 설정

두 환경이 똑같이 쓰는 것은 전부 base.py 에 한 번만 넣는다. 강의에서 짚은 항목:

• Django 기본 앱: admin, auth, sessions, messages, staticfiles
• 설치한 라이브러리: rest_framework(DRF), django_extensions 등
• 미들웨어: CSRF, security, 요청/응답·HTTP 세션 관리 등
• ROOT_URLCONF(루트 URL), 템플릿 엔진, WSGI 애플리케이션
• 패스워드 검증기, LANGUAGE_CODE, TIME_ZONE, USE_TZ
• static / media 파일 저장 위치, 사용할 User 모델
• SendGrid API 키, Google OAuth client id, 로깅 설정

10. local 과 production 은 실제로 뭐가 다른가

반대로 환경마다 달라져야 하는 것만 local.py / production.py 로 갈린다.

Django 앱은 자기를 서빙하는 IP/도메인으로 들어오는 요청만 처리한다. 그래서 ALLOWED_HOSTS 에 그 주소들이 들어가 있어야 한다.

오늘 정리 + 다음

• 정리: 요청이 들어오면 Django 는 (앞단의 WSGI 다음에) URL 을 핸들링하는데, 그 전에 settings 가 조립된다. settings 에서 공통이 아닌 — 환경별로 갈려야 하는 값(DB · 도메인 · IP 등) — 을 local / production 으로 분리해두고, 처음 settings 가 로드될 때 환경변수(PRODUCTION 여부)에 따라 둘 중 하나를 불러온다.
• 개발 서버에서 개발할 때: base + local
• 사용자가 운영 URL 로 들어오면: base + production
• 흔한 함정: "분명히 저장했는데 DB에 없다" → 십중팔구 로컬 DB에 저장됐는데 운영 DB를 보고 있는 것. (요즘은 거의 없는 일이긴 하다.)
• 다음 시간: settings 관련해서 좀 더 디테일하게 설명할 예정.
• 자습 권장: 시간 날 때 Django settings 원리를 직접 한번 찾아보기.