🧩 ORM(Object-Relational Mapping)이란?

ORM은 객체지향 세계(클래스/객체)와 관계형 DB 세계(테이블/행)를 이어주는 통역 시스템이다. 🌉
개발자는 Python 객체를 다루듯이 코드를 작성하고, ORM은 그걸 SQL로 번역해서 DB에 요청하고 결과를 다시 객체로 복원한다.

---

🧠 왜 ORM이 필요할까?

애플리케이션은 보통 객체로 사고한다.
User, Post, Comment 같은 것들을 클래스/객체로 표현한다. 🧱
그런데 DB는 테이블/컬럼/행으로 저장한다. 즉, 둘은 기본 철학이 다르다.

이 차이를 흔히 객체지향 vs 관계형 DB의 패러다임 불일치라고 부른다. (Object-Relational Impedance Mismatch) ⚡

객체지향 세계                          관계형 DB 세계
------------------                  ------------------
User 객체 (속성+행동)                   users 테이블 (데이터)
user.email = "a@b.com"               UPDATE users SET email='a@b.com' ...
user.team.name                       SELECT ... JOIN teams ...

"점(.)으로 탐색"                        "JOIN으로 조립"

ORM은 이 불일치를 줄이기 위해 등장했다. 즉, 객체를 중심으로 개발하되 DB와의 연결은 자동화하는 도구다. 🛠️

---

🆚 ORM 없이(직접 SQL) vs ORM 사용

1) ORM 없이: SQL → 결과(튜플/딕셔너리) → 수동 매핑

ORM 없이 DB를 쓰면 보통 이런 흐름이 된다.

[흐름]
1) SQL 문자열 작성
2) cursor.execute(...)
3) fetchone()/fetchall()
4) row를 객체로 직접 변환 (수동 매핑)
5) 필드 추가/변경 시 SQL + 매핑 코드 함께 수정

# (예시) 직접 SQL + 수동 매핑
import pymysql

conn = pymysql.connect(host="localhost", user="root", password="1234", db="mydb")
cursor = conn.cursor()

cursor.execute("""
    SELECT member_id, name, team_id
    FROM members
    WHERE member_id = %s
""", (1,))

row = cursor.fetchone()  # (1, "jay", 10) 같은 형태

class Member:
    def __init__(self, member_id, name, team_id):
        self.member_id = member_id
        self.name = name
        self.team_id = team_id

member = Member(row[0], row[1], row[2])
print(member.name)

cursor.close()
conn.close()

문제는 여기서부터다. 😵‍💫
테이블이 늘고, 관계가 복잡해지면 매핑 코드가 폭발한다. 컬럼 하나 추가해도 SQL/매핑/테스트가 같이 흔들린다.

상황	ORM 없이 생기는 일
컬럼 추가/변경	SQL 수정 + 매핑 코드 수정 + 관련 로직 영향 범위 확대
JOIN 증가	SQL이 길어지고 재사용 어려움, 조회 목적마다 쿼리 파편화
도메인 로직 확장	비즈니스보다 DB 연동 코드가 더 많아지는 현상

---

2) ORM 사용: 클래스 정의 → ORM이 SQL 생성/실행 → 객체로 반환

ORM을 쓰면 개발자는 "테이블" 대신 "클래스"를 중심으로 코드를 작성한다. 🧑‍💻
ORM은 내부에서 SQL을 만들고 실행한 뒤 결과를 객체로 돌려준다.

[흐름]
1) 클래스(모델) 정의  = 테이블 매핑 정보
2) session.get/query  = 조회 의도만 표현
3) ORM이 SQL 생성/실행
4) 결과를 객체로 구성해서 반환
5) 수정은 객체 변경 → ORM이 UPDATE로 변환

# (예시) SQLAlchemy 스타일 의사 코드 (개념 보여주기용)
# 실제 설정/엔진/세션 생성은 프로젝트 구조에 따라 달라진다

class Team:
    id: int
    name: str

class Member:
    id: int
    name: str
    team: Team   # FK 숫자가 아니라 "객체 참조"처럼 다룬다

member = session.get(Member, 1)         # PK로 조회 (ORM이 SELECT를 만든다)
print(member.name)

print(member.team.name)                 # 관계 탐색 (필요하면 JOIN/추가 쿼리)

핵심은 이거다. 🎯
SQL을 "직접 작성"하는 시간이 줄고, 대신 객체 모델링과 로직에 집중하게 된다.

---

🧾 ORM이 실제로 해주는 일 (핵심 기능 5개)

기능	무슨 의미인가	개발자가 체감하는 변화
✅ 매핑 자동화	테이블 ↔ 클래스, 행 ↔ 객체 변환	row[0], row[1] 같은 수동 매핑 제거
✅ SQL 생성	조회/저장 의도를 SQL로 변환	반복 SQL 작성 감소, 실수 감소
✅ 관계 관리	FK를 객체 참조처럼 사용	member.team.name 같은 탐색 가능
✅ 변경 감지	객체 변경 사항을 추적	값 바꾸면 UPDATE 자동 발생 가능
✅ 캐시/일관성(Identity Map)	같은 PK는 같은 객체로 관리(세션 단위)	같은 데이터를 여러 객체로 다루며 꼬이는 문제 감소

---

🧩 다이어그램

[직접 SQL]
Python 코드
  |
  |  1) SQL 문자열 작성
  v
DB Driver (pymysql 등)
  |
  |  2) SQL 전송
  v
Database
  |
  |  3) row(튜플/딕셔너리) 반환
  v
Python 코드
  |
  |  4) row → 객체 수동 변환
  v
도메인 객체 사용


[ORM]
Python 코드 (객체 중심)
  |
  |  1) "의도"만 표현(session.get / query)
  v
ORM (SQL 생성 + 매핑 + 변경 감지)
  |
  |  2) SQL 생성/실행
  v
Database
  |
  |  3) 결과 수신
  v
ORM
  |
  |  4) row → 객체 자동 변환
  v
도메인 객체 사용

---

⚠️ ORM을 쓰면 무조건 좋은가?

아니다. ORM은 만능이 아니다. 대신 트레이드오프가 있다. 🔁

1) N+1 문제

관계를 점(.)으로 편하게 탐색하다가, 반복문 안에서 매번 추가 조회가 발생하면 쿼리가 폭발한다. 💥

[예시 상황]
members 100명 조회 (1번)
for member in members:
    member.team.name 접근 (팀을 100번 추가 조회)

총 101번 쿼리 = 1 + 100  → 이것이 N+1의 전형적 형태

해결은 보통 "한 번에 가져오게" 만드는 전략(조인 로딩/프리패치 등)을 선택하는 방식으로 한다. ORM을 쓰면 이런 성능 이슈를 더 쉽게 만들 수도 있고, 반대로 더 쉽게 해결할 수도 있다.

2) 복잡한 보고서/통계 쿼리

복잡한 GROUP BY, 윈도우 함수, 대용량 통계 쿼리는 ORM보다 SQL이 더 직관적인 경우가 많다. 📊
이럴 땐 ORM을 쓰더라도 "Raw SQL"을 섞는 선택을 하기도 한다.

---

🧪 ORM을 잘 쓰는 핵심 감각

• 🔍 ORM은 SQL을 숨기는 도구가 아니라 SQL을 생성하는 도구다
• 🧾 그래서 ORM을 쓰더라도 생성되는 SQL을 보는 습관이 중요하다
• 🚦 성능 이슈는 대부분 "조회 전략"에서 터진다 (lazy/eager, join/prefetch)
• 🧱 도메인 모델(클래스 설계)이 잘 되어야 ORM의 이점이 극대화된다

---

📌 요약

키워드	핵심 문장
ORM	객체지향 코드와 관계형 DB 사이를 연결하는 통역 시스템이다
ORM 없이	SQL 작성 + 결과 수동 매핑이 반복되어 코드가 비대해지기 쉽다
ORM 사용	클래스 중심으로 개발하고 SQL 생성/매핑/변경 감지를 자동화한다
주의점	N+1 같은 조회 전략 문제를 이해해야 한다

결론✨
ORM은 개발자가 SQL을 덜 쓰게 해주는 도구가 아니라, 객체 중심으로 안전하게 DB를 다루게 해주는 구조다.