1편 — Django는 대체 뭘 대신 해주나
🎬 지난 이야기
0편에서는 이 연재가 왜 존재하는지 이야기했습니다. AI가 코드를 짜줄 수 있어도, "왜 동작하는지 모른 채로 쓰면 왜 깨졌는지도 모른다"는 것이었죠. 이 연재는 바로 그 간극을 메우기 위해, AI가 생성해준 Django 코드를 한 줄씩 통역해드리는 것을 목표로 합니다. 자, 이제 첫 번째 코드 더미 앞에 서 봅시다.
😵 Cursor에서 "Django로 게시판 만들어줘"라고 입력했더니, 눈 깜짝할 사이에 폴더와 파일이 쏟아졌던 경험 있으시죠? 그런데 막상 그 폴더를 열어보면 이런 생각이 드셨을 겁니다.
"나는
settings.py를 건드린 적도 없는데, 서버가 어떻게 뜨는 거지?"
"이manage.py는 누가 쓰라고 만든 거야?"
오늘은 바로 이 질문에 답합니다. 핵심 한 마디로 미리 드리자면, Django는 웹 서비스를 만들 때 매번 반복해서 짜야 하는 코드들을 이미 만들어 두고 기다리고 있습니다. 여러분은 그냥 갖다 쓰면 됩니다.
🤖 AI가 짜준 코드
AI에게 내린 프롬프트:
"Django 프로젝트 시작하는 명령어랑 그 결과 폴더 구조 알려줘"
AI가 알려준 명령어:
django-admin startproject config .
python manage.py startapp community
그러면 폴더가 이렇게 생깁니다:
my_project/
├── manage.py
├── config/
│ ├── __init__.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
└── community/
├── __init__.py
├── admin.py
├── apps.py
├── models.py
├── views.py
└── migrations/
🔍 한 줄씩 통역
manage.py — 만능 리모컨
이 파일은 Django 프로젝트 전체를 조종하는 리모컨입니다. 직접 열어서 편집할 일은 거의 없지만, 터미널에서 python manage.py runserver처럼 이 파일을 통해 Django에게 명령을 내립니다. 리모컨의 버튼을 누르면 TV가 켜지는 것처럼, manage.py를 통해 서버를 켜고, 데이터베이스를 설정하고, 테스트를 돌립니다.
config/ 폴더 — 건물 관리실
config/는 건물 전체의 관리실 같은 역할을 합니다. 이 안에 있는 파일들이 프로젝트 전체의 규칙을 정합니다.
-
settings.py: 건물 관리규정 문서입니다. "어떤 앱을 쓸 건지", "데이터베이스는 어디에 있는지", "언어는 뭔지" 같은 프로젝트 전체 설정이 여기 모여 있습니다. AI가 자동으로 채워줬지만, 나중에 데이터베이스를 연결하거나 배포할 때 직접 손대게 될 파일입니다. -
urls.py: 건물 입구의 안내판입니다. "2층은 게시판, 3층은 마이페이지"처럼, 어떤 주소(URL)로 들어오면 어떤 페이지를 보여줄지를 여기서 지정합니다. URL 경로를 등록하는 라우팅 파일이라고도 부릅니다. -
wsgi.py: 건물과 외부 도로를 이어주는 진입로입니다. 실제 인터넷 서버에 배포할 때 Django가 웹 서버와 대화하는 방식을 정의합니다. 처음에는 건드릴 일이 없으니, "그런 게 있구나" 정도만 알아두세요.
community/ 폴더 — 기능 담당 부서
startapp community 명령으로 생긴 이 폴더가 실제 게시판 기능이 들어갈 공간입니다. 건물로 치면 "게시판 담당 부서 사무실"입니다.
models.py: 게시글 데이터를 어떤 모양으로 저장할지 정의하는 설계도입니다. 3편에서 본격적으로 다룹니다.views.py: 실제로 "어떤 화면을 보여줄지"를 처리하는 직원입니다.admin.py: Django가 자동으로 만들어주는 관리자 페이지에 뭘 보여줄지 설정합니다. 이것도 Django가 자동 제공하는 기능 중 하나입니다.
__init__.py — 빈 파일인데 왜 있나요?
이 파일은 내용이 비어 있어서 당황스럽죠. "이 폴더는 Python 패키지입니다"라고 Python에게 알려주는 표지판 역할만 합니다. 직접 건드릴 일은 없습니다.
⚠️ 자주 깨지는 지점
1. settings.py에 앱을 등록 안 했을 때
startapp community로 폴더는 만들었지만, settings.py에 등록하지 않으면 Django가 그 앱의 존재를 모릅니다. 이런 에러가 납니다:
django.db.utils.OperationalError: no such table: community_post
해결책은 settings.py의 INSTALLED_APPS 목록에 'community'를 추가하는 것입니다:
# config/settings.py
INSTALLED_APPS = [
...
'community', # 이 줄을 추가해야 Django가 앱을 인식합니다
]
2. config .의 점(.)을 빼먹었을 때
django-admin startproject config .에서 마지막 .은 "현재 폴더에 만들어줘"라는 뜻입니다. 점을 빼면 config/config/ 처럼 폴더가 중첩되어 생겨서 나중에 경로 설정이 꼬입니다. AI가 짜준 명령어 그대로 복사할 때도 점을 꼭 확인하세요.
🎮 직접 해보기
미션: 지금 자신의 프로젝트 폴더를 열고, config/settings.py 파일을 찾아 INSTALLED_APPS 목록을 확인해보세요. 거기에 어떤 앱들이 이미 등록되어 있는지 살펴보고, 'django.contrib.admin' 같은 항목들이 "Django가 자동으로 제공하는 기능들"이라는 걸 눈으로 확인해보세요.
혹시 settings.py를 열었더니 뭔가 수상한 설정이 보인다거나, 앱 등록을 어디에 해야 할지 모르겠다면 테크창 Q&A 게시판에 스크린샷과 함께 질문해주세요. 같이 보면 금방 해결됩니다.
⏭️ 다음 편 예고
다음 편에서는 urls.py라는 안내판이 실제로 어떻게 "이 주소로 들어오면 이 화면을 보여줘"라는 연결을 만들어내는지, AI가 짜준 URL 패턴 코드를 한 줄씩 해부해드립니다.
📚 시리즈: AI가 짜준 Django, 이제 알고 씁니다 · 1편 (총 9편 중)
테크창 연구팀 | 인천대학교 창의인재개발학과 전공심화연구모임
본 칼럼은 AI 보조로 작성되었으며, 코드·예시는 학습용입니다.
댓글 (0)
아직 댓글이 없습니다. 첫 번째 댓글을 작성해보세요!