Django DB 연동, 하드코딩에서 데이터베이스로 전환하는 구조와 프롬프트 전략 3가지

Django DB 연동은 단순히 코드를 바꾸는 작업이 아니다. 데이터를 다루는 방식 자체를 바꾸는 구조적 전환이다. 하드코딩 상태에서는 데이터가 코드 안에 박혀 있다. DB 연동 이후에는 데이터가 코드 밖에 저장되고, 코드는 그것을 꺼내오는 역할만 한다.

이 글에서는 하드코딩에서 Django DB 연동으로 전환할 때 실제로 어떤 구조가 바뀌는지를 먼저 설명하고, 이 작업을 AI에게 요청할 때 쓴 프롬프트 전략을 함께 정리한다.

하드코딩 데이터의 한계 — 언제 DB가 필요해지는가

하드코딩이란 데이터를 코드 안에 직접 적어두는 방식이다. 처음 프로젝트를 시작할 때는 빠르고 편하다. 문제는 데이터가 바뀔 때 생긴다.

예를 들어 장비 목록을 이렇게 관리하고 있다고 가정해보자.

# views.py — 하드코딩 상태
def equipment_list(request):
    equipments = [
        {'name': 'Pump-A', 'status': '정상', 'last_checked': '2024-01-10'},
        {'name': 'Pump-B', 'status': '점검중', 'last_checked': '2024-01-08'},
    ]
    return render(request, 'equipment/list.html', {'equipments': equipments})

데이터를 추가하거나 수정하려면 코드를 직접 열어야 한다. 웹 화면에서 입력한 데이터는 저장되지 않고 사라진다. 서버를 재시작하면 원래 상태로 돌아간다.

하드코딩의 한계는 아래 세 가지로 압축된다.

이 세 가지 한계가 느껴지는 시점이 Django DB 연동이 필요한 시점이다.

하드코딩 → DB 전환, 무엇이 바뀌는가

전환의 핵심은 하나다. 데이터의 위치가 코드 안에서 DB로 이동한다.

코드는 그대로다. UI(HTML/CSS/JS)도 그대로다. 바뀌는 것은 views.py가 데이터를 가져오는 출처다.

[하드코딩 구조]
브라우저 요청 → views.py → 코드 안의 리스트 → HTML 렌더링

[DB 연동 구조]
브라우저 요청 → views.py → DB 조회 → HTML 렌더링

views.py 입장에서는 데이터를 어디서 꺼내오느냐만 달라진다. HTML 템플릿은 어디서 온 데이터인지 모른다. 그냥 받은 데이터를 화면에 뿌릴 뿐이다. 이것이 “UI는 건드리지 않는다”는 원칙이 성립하는 이유다.

Django가 이 전환을 쉽게 만들어주는 이유는 ORM 때문이다. ORM(Object-Relational Mapping)은 파이썬 코드를 SQL로 자동 번역해주는 통역 계층이다. Equipment.objects.all()이라고 쓰면 Django가 내부적으로 SELECT * FROM equipment를 실행한다. 개발자는 SQL을 몰라도 파이썬으로 DB를 다룰 수 있다.

Django DB 연동의 3단계 흐름

Django DB 연동은 순서가 있다. 순서를 지키지 않으면 오류가 난다.

1단계 — models.py: 테이블 구조를 정의한다

models.py는 DB 테이블의 설계도다. 파이썬 클래스 하나가 테이블 하나가 되고, 클래스의 속성이 테이블의 열(Column)이 된다.

# models.py
from django.db import models

class Equipment(models.Model):
    name = models.CharField(max_length=100)    # 장비 이름
    status = models.CharField(max_length=50)   # 상태
    last_checked = models.DateField()          # 마지막 점검일자

    def __str__(self):
        return self.name

이 클래스를 작성하는 것만으로 DB 테이블이 생기지는 않는다. 3단계 마이그레이션까지 완료해야 실제 테이블이 만들어진다.

2단계 — views.py: 데이터 출처를 DB로 바꾼다

하드코딩 리스트를 ORM 조회 코드로 교체한다. 딱 이 부분만 바뀐다.

# views.py — DB 연동 후
from django.shortcuts import render
from .models import Equipment

def equipment_list(request):
    equipments = Equipment.objects.all()  # 하드코딩 리스트 → DB 조회로 교체
    return render(request, 'equipment/list.html', {'equipments': equipments})

하드코딩 상태의 리스트가 Equipment.objects.all() 한 줄로 대체된다. HTML 템플릿은 수정할 필요가 없다.

데이터를 저장하는 Insert 로직도 같은 방식이다.

def equipment_create(request):
    if request.method == 'POST':
        Equipment.objects.create(
            name=request.POST.get('name'),
            status=request.POST.get('status'),
            last_checked=request.POST.get('last_checked')
        )
        return redirect('equipment_list')
    return render(request, 'equipment/create.html')

Equipment.objects.create()가 SQL의 INSERT INTO 역할을 한다. 폼에서 넘어온 데이터를 받아 DB에 저장한다.

3단계 — 마이그레이션: 설계도를 DB에 반영한다

models.py 작성이 끝나면 터미널에서 아래 두 명령어를 순서대로 실행한다.

python manage.py makemigrations
python manage.py migrate

makemigrations는 설계 도면을 그리는 단계고, migrate는 실제 공사를 실행하는 단계다. 두 명령어를 모두 실행해야 비로소 DB에 테이블이 생긴다.

이 작업을 AI에게 맡길 때 쓴 프롬프트 전문

아래는 실제로 사용한 Django DB 연동 요청 프롬프트다. 구조를 그대로 보여주는 것이 설명보다 직접적이다.

나는 현재 Django 기반의 웹 프로젝트를 진행 중이야.
기존에는 하드코딩된 데이터를 사용했지만, 이제 실제 DB를 연동하려고 해.

요구사항은 다음과 같아.

1. UI는 건드리지 말 것
   기존 프론트엔드(HTML/CSS/JS) 구조는 그대로 유지해줘.

2. DB 연동 로직만 구현해줘
   - models.py: 장비이름, 상태, 마지막 점검일자를 포함하는 모델 클래스를 작성해줘.
   - views.py: DB에서 데이터를 조회(Select)하고 저장(Insert)하는 로직을
     기본 뷰 함수에 어떻게 적용할지 수정된 코드를 보여줘.
   - 명령어: 마이그레이션을 수행하기 위한 터미널 명령 순서를 알려줘.

3. 설명 방식
   코드 변경 부분에 대해 "왜 이렇게 DB와 연동되는지"
   개념 위주로 간단히 설명해줘.

현재 Django 버전은 4.2야.
이 버전과 호환되는 방식으로 코드를 작성해줘.

이 프롬프트가 효과적인 이유는 구조에 있다. 단순히 “DB 연동해줘”가 아니라, 작업 범위·파일별 요구사항·설명 방식·버전 정보를 모두 포함했다.

프롬프트 설계의 3가지 핵심 원칙

위 프롬프트를 분해하면 Django DB 연동 요청에서 반복해서 써먹을 수 있는 3가지 원칙이 나온다.

원칙 1 — 작업 범위를 먼저 선언한다

“UI는 건드리지 말 것”이 프롬프트의 첫 번째 요구사항이다. 이 한 줄이 AI의 작업 영역을 정확히 제한한다. 범위를 선언하지 않으면 AI가 HTML까지 수정하거나 불필요한 파일을 추가로 생성하는 경우가 생긴다. 바이브 코딩 경험이 쌓일수록 이 선언의 중요성을 더 실감하게 된다.

원칙 2 — 파일 단위로 요구사항을 쪼갠다

“DB 연동해줘” 한 줄보다 “models.py는 이렇게, views.py는 이렇게, 명령어는 순서대로”처럼 파일 단위로 나눠서 요청하면 AI의 응답 정확도가 올라간다. 파일명을 명시하면 AI가 어느 파일을 수정해야 하는지 혼동하지 않는다. 실제로 이 프롬프트에서 settings.py라고 표기한 부분이 있었는데, AI는 정확히 views.py를 수정해야 한다고 맥락을 파악해서 처리했다. 하지만 파일명은 처음부터 정확하게 지정하는 것이 더 안전하다.

원칙 3 — 개념 설명을 함께 요청한다

“왜 이렇게 DB와 연동되는지 개념 위주로 설명해줘”를 함께 요청하면 코드만 받는 것이 아니라 작동 원리를 이해하면서 진행할 수 있다. 코드를 복붙해서 실행하는 수준에서 벗어나, 다음 수정이나 오류 대응을 스스로 할 수 있는 기반이 만들어진다. Django ORM 구조를 미리 알고 있으면 이 설명이 훨씬 빠르게 흡수된다.

그리고 Django 버전 명시는 선택이 아니다. ORM 문법과 설정 방식이 버전마다 다를 수 있기 때문에, 버전 정보 없이 요청하면 호환되지 않는 코드가 나올 수 있다.

핵심 요약

하드코딩에서 Django DB 연동으로의 전환은 데이터의 위치를 코드 안에서 DB로 옮기는 작업이다. UI는 바뀌지 않는다. views.py가 데이터를 꺼내오는 출처만 바뀐다.

전환은 3단계 순서로 진행한다. models.py로 테이블 구조를 정의하고, views.py에서 ORM 조회·저장 코드로 교체하고, makemigrations → migrate로 DB에 반영한다.

AI에게 이 작업을 요청할 때는 작업 범위 선언, 파일 단위 요구사항, 개념 설명 요청 이 세 가지를 프롬프트에 반드시 포함시킨다. 이 구조가 갖춰진 프롬프트와 그렇지 않은 프롬프트의 결과물 품질은 확연히 다르다.

[링크 제안]

Django DB 연동 전에 ORM 개념부터 잡고 싶다면 먼저 읽어두면 좋다.

• ORM 이란 무엇인가 — Django로 DB를 다루는 3가지 핵심 원리

프롬프트 설계를 더 체계적으로 발전시키고 싶다면 이 글을 이어서 읽어보자.

• 메타 프롬프팅 — AI에게 답을 달라기 전에 내 생각을 먼저 검증받아라

Django 공식 문서에서 ORM과 마이그레이션 전체 레퍼런스를 확인할 수 있다. Django 공식 문서

FAQ