Pydantic로 구조짜기 (부제:Pydantic BaseModel은 immutable일까?)

Server/Python

Pydantic로 구조짜기 (부제:Pydantic BaseModel은 immutable일까?)

아상량 2025. 4. 10. 10:27

ORM 객체로 받은 뒤 Pydantic 모델로 변경할 수 있어?

ChatGPT의 말:

네, FastAPI + SQLAlchemy 환경에서 ORM 객체를 Pydantic 모델로 변경하는 것은 매우 일반적인 작업입니다. FastAPI는 이를 위해 pydantic 모델의 from_orm() 기능을 공식적으로 지원합니다.

✅ 전체 흐름 요약

1. SQLAlchemy ORM 객체 조회

→

2. Pydantic 모델 정의 (Config.orm_mode = True)

→

3. PydanticModel.from_orm(orm_instance) 로 변환

📌 예시 코드

🔹 1. SQLAlchemy ORM 모델

# models.py
from sqlalchemy import Column, Integer, String
from sqlalchemy.orm import declarative_base

Base = declarative_base()

class User(Base):
    __tablename__ = "users"

    id = Column(Integer, primary_key=True)
    name = Column(String)
    email = Column(String)

🔹 2. Pydantic 모델 정의 (※ 핵심: Config.orm_mode = True)

# schemas.py
from pydantic import BaseModel

class UserSchema(BaseModel):
    id: int
    name: str
    email: str
	
    model_config = {
        "from_attributes": True  # ✅ ORM 객체를 받아도 필드 추출 가능하게 함
    }
	# v1 버전
    # class Config:
    #     orm_mode = True  # ✅ 이게 꼭 필요합니다

🔹 3. ORM 객체를 → Pydantic 객체로 변환

from sqlalchemy import select
from models import User
from schemas import UserSchema

# ORM 객체 가져오기
stmt = select(User).where(User.id == 1)
orm_user = session.execute(stmt).scalars().first()

# Pydantic 모델로 변환
if orm_user:
    user_data = UserSchema.model_validate(orm_user)
    # v1
    # user_data = UserSchema.from_orm(orm_user)
    print(user_data.dict())

→ 결과:

{'id': 1, 'name': 'Alice', 'email': 'alice@example.com'}

🔄 리스트 변환도 가능

users = session.execute(select(User)).scalars().all()
# user_list = [UserSchema.from_orm(u) for u in users]

✅ FastAPI 라우터에서 바로 사용 가능

from fastapi import APIRouter, Depends
from sqlalchemy.orm import Session
from schemas import UserSchema

@router.get("/users/{user_id}", response_model=UserSchema)
def get_user(user_id: int, db: Session = Depends(get_db)):
    user = db.execute(select(User).where(User.id == user_id)).scalars().first()
    if user is None:
        raise HTTPException(status_code=404, detail="User not found")
    return user  # FastAPI가 내부적으로 from_orm 사용

response_model=UserSchema만 지정해주면 FastAPI가 자동으로 from_orm()을 호출합니다!

✅ 요약

목적방법

ORM 객체 → Pydantic 모델	MyPydanticModel.from_orm(orm_object)
리스트 처리	[Model.from_orm(o) for o in objects]
FastAPI 자동 변환	response_model=Model, Config.orm_mode = True

필요하시면 Pydantic v2 기준에서의 model_config, from_attributes() 기반 예제도 알려드릴게요 (v1과 구조 약간 다름). FastAPI 버전이나 Pydantic 버전에 따라 맞춰 드릴 수 있습니다!

나의 말:

orm 객체를 바로 parameter 로 전달하면서 관리하는 것 보다 Pydantic 로 관리하는게 더 안전한가?

ChatGPT의 말:

아주 핵심적인 질문을 해주셨습니다.
결론부터 말씀드리면:

✅ 네, 일반적으로는 Pydantic 모델을 통해 데이터 입출력을 관리하는 것이 더 안전하고 명확합니다.

왜 그런지 구체적으로 "왜 Pydantic을 쓰는 게 좋은가?", 그리고 "언제 ORM 객체를 직접 써도 되는가?" 를 기준으로 나눠서 설명드릴게요.

✅ Pydantic 모델을 사용하는 이유 (추천되는 이유)

1. 명확한 스키마 정의 + 검증

Pydantic은 type, length, format 등을 자동으로 검증합니다.
잘못된 요청이 오면 API 레벨에서 빠르게 막을 수 있습니다.

class UserSchema(BaseModel):
    id: int
    name: str
    email: EmailStr  # 이메일 형식 자동 검증

→ 사용자가 email=123 이런 값 넣으면 422 Unprocessable Entity 응답

2. 보안상의 이유 (노출 방지 필드 제어)

ORM 객체를 바로 반환하면 민감한 데이터가 포함될 수 있음:

# User 모델에 password 필드 있음
user = db.query(User).first()
return user  # ❌ password가 포함될 수 있음

Pydantic은 어떤 필드만 반환할지 명시 가능:

class UserOut(BaseModel):
    id: int
    name: str

    class Config:
        orm_mode = True

3. 입력/출력을 명확히 분리 (In/Out)

예:

class UserCreate(BaseModel):
    name: str
    email: EmailStr

class UserOut(BaseModel):
    id: int
    name: str
    email: EmailStr

→ DB에 저장할 때는 UserCreate, 응답 보낼 땐 UserOut

4. 서로 다른 DB 모델/응답 구조 관리 가능

ORM에는 id, created_at, internal_flag 같은 필드가 많지만,
API에는 간결한 응답만 보내고 싶을 수 있음.
Pydantic으로 필요한 부분만 뽑아 전달 가능.

5. 테스트, 문서화, IDE 지원 강화

FastAPI는 Pydantic 모델 기반으로 자동 Swagger 문서를 생성합니다.
API 테스트 시 타입 힌트와 자동 완성이 훨씬 잘 됩니다.

❌ ORM 객체만으로 처리할 경우의 단점

문제점설명

검증 없음	잘못된 값도 그대로 통과됨
민감한 필드 노출 가능	비밀번호, 내부 정보 등 의도치 않게 포함될 수 있음
타입 예측이 어려움	응답 형식이 명확하지 않아 Swagger도 불완전
유지보수 어려움	스키마 변화 시 ORM과 API 로직이 강하게 결합됨

✅ ORM 객체를 직접 써도 괜찮은 경우

조건이유

내부 서비스/비공개 API	신뢰 가능한 환경에서의 효율 우선
관리자용 도구	UI에서 모두 감시/제어 가능할 때
간단한 스크립트, ETL 등	API 응답이 아닌 경우라면 덜 민감함

🎯 결론: 어떤 방식이 "안전"한가?

항목ORM 객체 직접 반환Pydantic 모델 사용

보안	❌ 위험 (필드 과다 노출 가능)	✅ 필요 필드만 선택 가능
검증	❌ 없음	✅ 타입, 형식, 제약 조건 검증
유지보수	❌ ORM과 강결합	✅ API 스키마 분리로 유연
Swagger 문서	❌ 명확하지 않음	✅ 자동 생성 & 명료
추천도	제한적 사용	✅ 공식 권장 방식

✍️ 추천 패턴 (FastAPI + SQLAlchemy)

입력: Pydantic Create/Update 모델
내부: SQLAlchemy ORM
출력: Pydantic Response 모델 + from_orm()

이렇게 3단 분리 구조가 가장 명확하고 확장성도 뛰어납니다.

필요하시면 여러 모델의 입력/출력 구조를 자동으로 만드는 유틸 패턴이나, Pydantic v2 기준 설계 방법도 알려드릴 수 있어요! 어떤 규모나 API 스타일을 원하시는지 알려주시면 딱 맞춰서 도와드릴게요.

FastAPI 랑 관계없이 db 연동&내부 로직 관점에서 알려줘

ChatGPT의 말:

아주 좋은 질문입니다.
FastAPI와 무관하게, 순수하게 DB 연동 및 내부 로직에서 ORM 객체를 바로 사용할지, Pydantic 모델을 통해 다룰지 고민하는 상황이라면,
그 판단 기준은 **"데이터의 역할과 경계 설정"**을 어디까지 명확히 하느냐에 달려 있습니다.

아래에 순수 Python 애플리케이션의 내부 로직 관점에서 각각의 장단점과 기준을 정리해드릴게요.

✅ 전제 구분: ORM 객체 vs Pydantic 모델

항목ORM 객체Pydantic 모델

역할	DB 연동 및 영속성 관리	구조화된 데이터 표현, 검증, 포맷팅
예시	SQLAlchemy, Django ORM 등	Pydantic BaseModel 상속 클래스

✅ ORM 객체만 써도 충분한 경우

언제?

로직이 DB 중심적이고, ORM 모델이 그 자체로 도메인 객체 역할을 할 수 있을 때
데이터를 받아서 조회, 연산, 저장까지 하는 모든 작업이 ORM 안에서 끝날 때

장점

중복 정의 필요 없음 (User, Product 모델을 한 번만 정의)
DB와 직접 연결된 객체이므로 즉시 수정/저장 가능
데이터 수정 → session.commit() 으로 저장까지 자연스럽게 이어짐

예시

user = session.get(User, user_id)
user.balance += 1000
session.commit()

단점

입출력 데이터와 도메인 로직이 섞임 (ex. DB 내부 필드, 외부 API용 필드 경계 없음)
객체가 커질수록 테스트 어려움
불변 객체로 관리가 어려움 (예: undo/redo 처리 등)

✅ Pydantic 모델을 도입하면 좋은 경우

언제?

DB에서 불러온 ORM 객체를 도메인 계층과 분리하고 싶을 때
비즈니스 로직, 데이터 연산, 캐싱, 외부 시스템 전달 등을 따로 구성하고 싶을 때
여러 모델을 조합해서 추상적인 응답/입력 구조를 만들 때
불변 객체 기반의 로직 처리가 필요할 때 (이력, 델타 관리 등)

장점

명확한 DTO 구조가 생김
검증, 변환, 정제, 중복 제거 등의 처리를 중앙화 가능
ORM이 없거나 바뀌어도 로직 단의 스키마는 그대로 유지 가능
테스트 코드 작성이 더 쉬움 (단순 구조체처럼 사용 가능)

예시

class UserDTO(BaseModel):
    id: int
    balance: int
    is_vip: bool

def apply_reward(user: UserDTO) -> UserDTO:
    if user.is_vip:
        return user.copy(update={"balance": user.balance + 5000})
    return user

🔍 비교 요약: 내부 로직 중심 판단 기준

판단 기준ORM 객체 직접Pydantic 모델 사용

단순한 CRUD 중심 로직	✅ 적합	❌ 불필요한 추상화
로직이 복잡하고 테스트 필요	❌ 결합도 높음	✅ 테스트/단위 분리 용이
데이터 불변성/사본 관리	❌ 어려움	✅ copy(update=...)로 처리 용이
DTO/입출력/외부 연동 관리	❌ 취약	✅ 확장 가능
캐싱/분산 처리/비동기 메시지 전송	❌ 직렬화 힘듦	✅ dict(), json() 즉시 가능
성능 민감한 로직 (추가 추상화 비용 피해야 함)	✅ 빠름	⚠️ 약간의 오버헤드 있음

✅ 결론: 관심사의 분리가 필요한 순간부터 Pydantic 모델을 도입하라

"ORM 객체로 충분한가?"
→ DB 조작만 한다면 충분합니다.

"로직, 검증, 전달, 캐싱, 직렬화, 유효성, 다형성, 테스트까지 고려하는가?"
→ 그 순간부터는 Pydantic 같은 구조화된 모델을 도입하는 것이 코드의 안정성과 유지보수성 측면에서 훨씬 유리합니다.

✍️ 실무 팁

ORM = 영속성 + 스키마 정의
Pydantic = 상태/로직/전달용 데이터 구조

이 둘은 서로 다르며, 분리될수록 더 확장 가능한 설계를 만들 수 있습니다.

필요하시면 DDD 스타일에서 Pydantic을 어떻게 도메인 객체처럼 다루는지, 혹은 "ORM → DTO → 외부 메시지" 흐름 구성 예시도 드릴 수 있어요.
현재 어떤 종류의 로직을 설계 중이신지 알려주시면 거기에 맞는 권장 방식을 구체적으로 제안드릴게요!

나의 말:

그런데 그 데이터를 내부적으로 payload 처럼 전달해야 해. 분기처리 할 거라서. 전달받은 함수에서 update 도 해야하고

ChatGPT의 말:

아주 핵심적인 상황입니다.

💡 요구사항 요약:

DB에서 가져온 데이터를 내부적으로 payload처럼 전달
분기 처리에 사용하고,
전달받은 함수 내에서 update도 가능해야 함

이럴 때는 다음 질문이 핵심입니다:

❓ 전달하는 "payload"는 불변이어야 하나요, 아니면 수정 가능해야 하나요?

유형설명

불변 (immutable)	복사본을 만들어 상태 관리, copy(update=...)
가변 (mutable)	전달받은 곳에서 payload.balance += 1000 같은 직접 수정

✅ 1. mutable payload가 필요할 때 (→ ORM 객체 사용이 실용적)

예: ORM 객체 그대로 전달, 수정, 저장

def process_reward(user):  # SQLAlchemy ORM 객체
    if user.is_vip:
        user.balance += 1000

user = session.get(User, user_id)
process_reward(user)
session.commit()

장점

ORM 객체를 그대로 사용하므로 성능과 직관성 좋음
DB 반영도 자연스러움

단점

객체가 DB 연결 상태라서, 추후 불변 관리, 직렬화, 캐싱에 부적합
의도치 않은 부작용(side effect) 발생 가능

✅ 2. 불변 payload + update 추적이 필요할 때 (→ Pydantic 추천)

예: Pydantic 객체 사용 + copy(update=...) 방식

from pydantic import BaseModel

class UserPayload(BaseModel):
    id: int
    balance: int
    is_vip: bool

def process_reward(payload: UserPayload) -> UserPayload:
    if payload.is_vip:
        return payload.copy(update={"balance": payload.balance + 1000})
    return payload

# ORM → Pydantic 변환
user = session.get(User, user_id)
payload = UserPayload.from_orm(user)

# 처리
updated = process_reward(payload)

# 다시 ORM에 반영
user.balance = updated.balance
session.commit()

장점

로직에서 불변성 유지 → 예측 가능하고 안전
각 처리 단계에서 로그, 히스토리, 비교 용이
테스트가 매우 쉬움
내부 처리 중간에 JSON 직렬화하거나 메시지 큐 전송도 쉬움

✅ 하이브리드 구조: ORM을 파라미터 + DTO 생성 + DTO 수정 후 ORM에 반영

def process(user: User):
    payload = UserPayload.from_orm(user)
    updated = payload.copy(update={"balance": payload.balance + 1000})
    user.balance = updated.balance

➕ 로직은 Pydantic 객체로 안전하게 처리하고,
➕ DB는 ORM 객체로 반영하는 방식입니다.

🚦 최종 선택 기준

필요사항권장 방식

단순 수정, 저장 목적	ORM 객체 사용
복잡한 분기, 중간 상태 기록, 테스트, 불변 데이터 흐름	Pydantic
둘 다 쓰고 싶다	Pydantic으로 분기 처리 → ORM에 반영

🧠 실무 설계 팁

비즈니스 로직은 데이터 로딩/저장과 분리하는 것이 유지보수에 매우 좋습니다.
불변 모델(Pydantic)은 상태를 명시적으로 다루고, 테스트와 추적이 쉬운 장점이 있습니다.
ORM은 어디까지나 "DB 반영 도구"이지, 로직 표현에 적합하진 않습니다.

📦 원하시면 process_xxx(payload: DTO) → 변경사항만 추출 → apply_to_model(model, dto) 같은 일반화된 구조도 만들어드릴 수 있어요.

현재 payload가 어떤 필드를 갖고 있고 어떤 업데이트가 필요한지 알려주시면 실제 코드 예시로 정리해드릴게요!

나의 말:

def process(user: User):
    payload = UserPayload.from_orm(user)
    updated = payload.copy(update={"balance": payload.balance + 1000})
    user.balance = updated.balance

이 코드의 흐름이랑 개념을 중심으로 자세히 설명해줘

ChatGPT의 말:

훌륭한 질문입니다.
이 코드는 ORM과 Pydantic을 분리하여 역할별로 책임을 나누는 실용적인 패턴입니다. 아래에 흐름, 개념, 설계 철학까지 단계별로 자세히 설명드릴게요.

🔍 전체 코드

def process(user: User):
    payload = UserPayload.from_orm(user)
    updated = payload.copy(update={"balance": payload.balance + 1000})
    user.balance = updated.balance

🧱 주요 구성 요소

요소설명

User	SQLAlchemy ORM 객체 (DB와 직접 연결됨)
UserPayload	Pydantic 모델 (검증과 데이터 표현용)
.from_orm()	ORM 객체 → Pydantic 모델 변환
.copy(update={...})	Pydantic 객체를 수정한 사본을 생성 (불변성 유지)
user.balance = ...	최종적으로 ORM 객체에 반영 → DB 반영 가능

🔁 단계별 흐름 분석

✅ 1. payload = UserPayload.from_orm(user)

ORM 객체 → Pydantic 객체 변환
이 단계에서 user 객체의 데이터가 복사되어 UserPayload라는 독립된 불변 데이터 객체로 표현됩니다.
Pydantic은 입력 값에 대한 검증, 타입 보장을 제공합니다.

💡 이 과정을 통해 "DB 객체를 직접 조작하지 않고, 깨끗한 데이터 표현용 객체로 다룸" → 비즈니스 로직 분리의 첫걸음

✅ 2. updated = payload.copy(update={"balance": payload.balance + 1000})

payload는 불변(frozen) 객체입니다. 값을 직접 바꿀 수 없습니다.
대신 .copy(update={...})를 사용해 수정된 새 객체를 반환합니다.

📌 불변 구조의 장점:

원본 데이터를 보호하면서도 변경 가능
순수 함수처럼 상태 변경을 안전하게 다룰 수 있음
테스트나 디버깅 시 추적이 쉬움

✅ 3. user.balance = updated.balance

비즈니스 로직 결과(updated)를 다시 **ORM 객체(user)**에 반영하는 단계입니다.
이 시점에서 ORM 객체를 수정하면, 이후 session.commit()으로 DB에 반영 가능합니다.

📌 이렇게 하면:

로직의 실행과 DB 반영을 명확히 분리할 수 있습니다.
로직 자체는 ORM에 종속되지 않기 때문에 테스트, 추론, 로깅이 쉬워짐

🎯 이 패턴의 설계적 가치

1. 관심사 분리 (Separation of Concerns)

User는 DB를 다루는 객체
UserPayload는 로직을 다루는 객체
역할이 분리되어 명확하고 안전한 코드가 됩니다.

2. 테스트 용이성

process() 함수는 Pydantic 객체 기반의 순수 함수처럼 쉽게 테스트 가능
ORM 객체 없이도 유닛 테스트 가능

def test_process():
    payload = UserPayload(id=1, balance=1000, is_vip=True)
    result = process_payload(payload)
    assert result.balance == 2000

3. 예측 가능성과 불변성

Pydantic 객체는 기본적으로 불변에 가까운 방식으로 동작 → side effect 방지
디버깅 시 흐름 추적이 용이함

4. 리팩터링 내성

DB 필드가 바뀌어도 DTO만 바꾸면 됨
외부 API 구조, 내부 정책 분기 등이 복잡해져도 로직 계층이 독립되어 있어 유연함

📦 확장 예시

def process_reward(user: User):
    dto = UserPayload.from_orm(user)
    updated = apply_reward(dto)
    user.balance = updated.balance

→ 이렇게 분기 로직도 분리 가능

✅ 요약

구문개념이점

.from_orm(user)	ORM 객체 → 로직용 구조체	데이터 검증 및 독립 처리
.copy(update=...)	불변 객체 변경 방식	안전한 상태 관리
user.balance = ...	로직 결과 → ORM 반영	DB와 로직 명확히 분리

📌 정리하자면:

"Pydantic은 로직과 상태 표현을 위한 안전한 중간 매개체이고,
ORM은 저장을 위한 실체적 수단이다."

이 패턴은 **도메인 주도 설계(DDD)**나 Clean Architecture에서도 많이 사용됩니다.

필요하시면 DTO → ORM 자동 반영 유틸 함수, 혹은 로그/감사 추적을 위한 확장 패턴도 알려드릴게요!

class UserPayload(BaseModel):
    id: int
    balance: int
    is_vip: bool

이 Pydantic 객체의 어떤 부분에 의해서 "독립된 불변 데이터 객체" 가 된다는거야?

ChatGPT의 말:

훌륭한 질문입니다.
질문하신 요지는 다음과 같습니다:

UserPayload는 그냥 BaseModel을 상속받았을 뿐인데,
왜 "독립된 불변 데이터 객체"처럼 취급하냐?
실제로 불변(frozen)도 아닌데?

정확한 지적이고, 여기에 대해서는 Pydantic의 기본 동작 방식과 불변성 추상화의 개념적 관점에서 설명드리는 것이 핵심입니다.

✅ 결론부터 말하자면:

UserPayload는 엄밀히 말해 진짜로 immutable 객체는 아닙니다.
하지만 Pydantic의 copy(update=...) 메커니즘을 사용함으로써,
불변 객체처럼 "다룰 수 있다"는 점에서 불변성의 모델링 수준 추상화를 제공합니다.

🔍 1. 기본 상태: Pydantic BaseModel은 mutable

u = UserPayload(id=1, balance=1000, is_vip=True)
u.balance = 2000  # ✅ 변경 가능

→ frozen=True로 설정하지 않는 한, UserPayload는 가변 객체입니다.

✅ 2. 그럼에도 왜 "불변 객체처럼 다룰 수 있는가?"

바로 이 메서드 때문입니다:

new_u = u.copy(update={"balance": u.balance + 1000})

원본을 수정하지 않고, 수정된 복사본을 리턴
즉, Pydantic은 내부 값을 직접 바꾸는 방식보다 copy()를 통한 데이터 흐름을 권장
이로 인해 불변 객체처럼 다루는 코딩 스타일과 철학이 자연스럽게 적용됨

✅ 3. "불변 객체처럼 다룬다"의 의미

측면설명

상태 관리	원본을 보존하고 새 객체를 만들어 변경
버그 방지	원본 객체가 수정되지 않으므로 side effect 없음
테스트 용이	입력 → 출력 명확, 참조 공유 이슈 없음
함수형 스타일	pure function처럼 동작 가능함

🔒 4. 진짜로 완전 불변(frozen)으로 만들고 싶다면?

class UserPayload(BaseModel):
    id: int
    balance: int
    is_vip: bool

    class Config:
        frozen = True

또는 Pydantic v2에서는:

class UserPayload(BaseModel):
    id: int
    balance: int
    is_vip: bool

    model_config = {"frozen": True}

이렇게 하면 실제로 속성 변경 자체가 불가능해집니다:

u = UserPayload(id=1, balance=1000, is_vip=True)
u.balance = 2000  # ❌ TypeError: "UserPayload" is frozen and does not support item assignment

🧠 요약

질문답변

UserPayload는 기본적으로 불변인가?	❌ 아니요, 기본은 mutable
그런데 왜 "불변 객체처럼 다룰 수 있다"고 말하는가?	copy(update=...) 패턴 덕분에 불변 객체처럼 데이터 흐름이 예측 가능하고 안전하게 설계 가능
실제로 불변으로 만들 수 있나?	✅ Config.frozen = True 또는 v2의 model_config = {"frozen": True} 사용
그럼 원래 패턴은 왜 좋다고 보는가?	상태를 명시적으로 바꾸고, side effect 없이 분기 처리·로그 추적·테스트가 쉬움

필요하시면 mutable/frozen 상태를 구분해 로직을 자동 생성하거나, 상태 변경 히스토리를 추적하는 DTO 패턴도 설계해드릴 수 있어요! 어떤 스타일의 불변성이 중요한지 알려주시면 거기에 맞춰 도와드릴게요.

저작자표시 비영리 변경금지 (새창열림)