객체는 무엇으로 이루어져 있는가

객체·개체·함수

객체(Object) = 속성 + 기능, 개체(Entity) = 객체 − 기능(저장만 된다), 함수(Function) = 객체 − 속성(변화만 일으킨다)입니다.

비유로 외우면 반드시 다시 헷갈리므로, 이 뺄셈식으로 판별하는 것이 이 절의 핵심입니다.

객체·개체·함수

개체(D, data)는 데이터베이스(PostgreSQL 테이블)에 저장만 되고, 객체(M, model)는 백엔드 메모리의 파이썬 클래스로 저장+변화를 겸합니다.

MVC에 D(개체)를 앞에 붙이면 'Model이 DB인가 객체인가'라는 흔한 혼란이 사라집니다 — Model은 메모리 위의 객체, Data는 DB 안의 개체입니다.

관계·구조

메모리 절약 때문입니다. 인스턴스 1,000개를 만들 때 필드(각자 다른 값)는 Heap에 개별로 두지만, 메서드(모두 똑같은 코드)까지 인스턴스마다 복사하면 메모리가 1,000배로 늘어납니다.

그래서 메서드는 Method Area에 하나만 두고 모든 인스턴스·스레드가 공유하고, 지역 변수는 스레드마다 Stack에 따로 둡니다.

관계·구조

인스턴스를 만드는 코드가 생성자(__init__) 안에 있으면 연관관계(HAS-A) — 객체와 함께 사는 동안 유지되며 Heap에 필드로 저장됩니다.

일반 메서드 안에 있으면 의존관계(USES-A) — 메서드가 끝나면 사라지며 Stack에 지역변수로 저장됩니다. UML에서는 실선과 점선으로 구분됩니다.

동기·비동기

'기다림'입니다. 한 건을 처리하는 시간 자체는 동기든 비동기든 같지만, 비동기는 기다리는 동안 다른 일을 할 수 있어 전체 처리량이 늘어나는 것입니다.

I/O 대기(DB 조회, API 호출 등)에는 크게 도움이 되지만, CPU 계산(실제로 일하는 중)에는 도움이 되지 않습니다.

패턴

DIP(의존성 역전 원칙)·IoC(제어의 역전)·DI(의존성 주입)·포트&어댑터가 결국 전략 패턴과 같은 한 가지, 즉 '쓰는 쪽은 인터페이스만 알고 실제 물건은 밖에서 넣어준다'를 서로 다른 맥락(원칙/프레임워크/구현기법/아키텍처)에서 부르는 이름이기 때문입니다.

런타임에 전략을 교체할 수 있는 유연성, 상속 대신 조합으로 OCP를 지키는 것, DI와의 연관성 세 가지가 꽃이라 불리는 이유입니다.

패턴

싱글톤이 맞는 세 조건 — 여러 개 있으면 안 됨(유출 지점이 늘어남), 만드는 비용이 비쌈(.env 검증을 매번 할 필요 없음), 상태를 공유해야 함(키가 갱신되면 전체가 같이 바뀌어야 함) — 을 전부 만족하기 때문입니다.

다만 남용하면 사실상 전역 변수라 테스트 간에 상태가 새기 쉬워, 현대 코드는 DI 컨테이너로 '하나만 만들어 주입'하는 쪽을 더 선호합니다.

구조·배포

하나는 '코드를 어디에 보관하나'(저장소 축), 다른 하나는 '서버를 어떻게 띄우나'(배포 축)를 묻는 서로 다른 질문이라 네 조합이 전부 가능합니다.

AI 코딩 도구 관점에서는 모노레포가 전체 코드베이스의 맥락을 한눈에 보여줘 활용이 유리하고, 멀티레포는 저장소 간 단절로 전체 흐름을 이해하기 어렵습니다.

구조·배포

하나의 빌딩(서버) 안에 살되 내부에 명확한 벽(모듈 경계)을 세워두는 것이라, 물리적 관리는 하나로 단순화하면서 논리적 독립성은 유지합니다.

나중에 특정 모듈만 트래픽이 몰리면 그 벽을 따라 떼어내기만 하면 MSA가 됩니다 — MSA로 갈 준비를 해둔 채 시작하는 전략입니다.

스스로 확인

객체(Object) = 속성 + 기능, 개체(Entity) = 객체 − 기능, 함수(Function) = 객체 − 속성입니다.

스스로 확인

클래스는 디스크, 인스턴스는 메모리(RAM)에 있습니다.

스스로 확인

메모리 절약 때문입니다. 필드(각 인스턴스마다 다른 값)는 Heap에 개별로, 메서드(모든 인스턴스가 똑같은 코드)는 Method Area에 하나만 두고 공유합니다.

스스로 확인

__init__ 안이면 연관관계(HAS-A, Heap에 필드로 저장되어 객체와 함께 삶), 일반 메서드 안이면 의존관계(USES-A, Stack에 지역변수로 저장되어 메서드가 끝나면 사라짐)입니다.

스스로 확인

비동기가 도움이 되는 것은 기다리는 시간(I/O 대기)이 있을 때인데, CPU 연산은 기다리는 게 아니라 실제로 계속 일하는 중이기 때문입니다.

스스로 확인

다섯 가지가 모두 '쓰는 쪽은 인터페이스만 알고, 실제 물건은 밖에서 넣어준다'는 같은 한 가지를 각자 다른 맥락(패턴·원칙·프레임워크·기법·아키텍처)에서 부르는 이름입니다.

스스로 확인

여러 개 있으면 유출 지점이 늘고, 매번 만드는 비용이 비싸며(.env 검증), 키가 갱신되면 전체가 같이 바뀌어야 하는 상태 공유가 필요하기 때문입니다.

스스로 확인

모노레포는 '코드를 어디에 보관하나'(저장소 축), 모놀리식은 '서버를 어떻게 띄우나'(배포 축)를 묻는 서로 다른 질문이라 네 조합이 전부 가능합니다.

스스로 확인

기초가 아니라 거점·저장소라는 뜻입니다. 야구의 루(base)처럼 나갔다가 돌아오는 안전한 지점을 가리킵니다.

자주 하는 실수

다른 단어입니다. Entity(개체) ↔ Object(객체)로 영어로는 완전히 다릅니다.

자주 하는 실수

클래스 정보는 실행 시 Method Area로 올라오지만, 원본은 디스크의 .py 파일입니다.

자주 하는 실수

하나만 있고 모든 인스턴스가 공유합니다. 메모리 절약을 위해서입니다.

자주 하는 실수

한 건의 처리 시간은 동일합니다. 기다리는 동안 다른 일을 할 수 있어 처리량이 늘어나는 것입니다.

자주 하는 실수

CPU 계산에는 효과가 없습니다. I/O 대기에만 도움이 됩니다.

자주 하는 실수

저장소 축과 배포 축이 다릅니다.

자주 하는 실수

패턴은 추상(해결 방식), 아키텍처는 구상(실제 구조)입니다.

자주 하는 실수

미국식으로는 거점·저장소를 뜻합니다.

자주 하는 실수

규모에 따라 다릅니다. 소규모엔 모듈러 모놀리식이 유리합니다.

자주 하는 실수

사실상 전역 변수라서 테스트가 어려워집니다.

용어

상속(IS-A), 연관(HAS-A), 의존(USES-A)입니다.

용어

프로덕트·프로젝트는 디스크에, 프로그램·프로세스는 메모리에 있습니다.

용어

프로그램이 실제로 실행되고 있는 시간과 그 환경입니다.

용어

프로세스 안에서 실제로 코드를 실행하는 최소 단위입니다.

용어

메모리 위의 입체적인 객체를 디스크에 저장하기 위해 일렬로 늘어뜨리는 과정입니다.

용어

비즈니스 로직과 실제 저장 기술 사이를 연결하며, '어떻게 저장할지'의 복잡한 로직을 숨기고 단순한 인터페이스만 제공하는 것입니다.

용어

Method Area는 클래스 정보·메서드 코드·클래스 변수(공유), Heap은 인스턴스(참조하는 쪽끼리), Stack은 지역 변수(스레드마다 각자)입니다.

용어

클래스 변수는 실행 시 디스크에서 Method Area로 로드되고, 인스턴스 변수는 실행 중(런타임)에 Heap에 동적 생성됩니다.

용어

Field는 논리적·추상적 경계(데이터 칸)이고, Area는 물리적·가시적 경계(구역)를 뜻합니다.

용어

무엇을 조작하느냐입니다 — 생성(객체를 만드는 행위), 구조(구조 변경), 행위(객체 간 행위 변경)입니다.

용어

전략은 '무엇을 할 것인가'(장기·거시), 전술은 '어떻게 할 것인가'(단기·미시)를 결정합니다.

용어

소전략은 GoF 디자인 패턴(객체 수준), 중전략은 아키텍처 패턴(서브시스템), 대전략은 시스템 아키텍처(거시 구조)입니다.

용어

① 출력 포트 정의 ② 영속성 어댑터 구현 ③ 데이터 매핑 ④ 의존성 주입입니다.

용어

DB 엔티티를 도메인 계층까지 끌고 들어오는 것으로, 이러면 도메인과 인프라를 분리한 구조의 의미가 없어져 막아야 합니다.

용어

전략 패턴, 팩토리 패턴, CQRS, 데이터 매퍼/DTO입니다.

용어

DDD(도메인 주도 설계)입니다. 보편적 언어로 모델과 비즈니스 개념을 일치시킵니다.

용어

절차지향은 데이터와 함수가 분리되고, 객체지향은 데이터와 함수를 하나로 묶은 '객체' 간의 상호작용입니다.

용어

관련 있는 데이터(속성)와 그 데이터를 처리하는 도구(기능)를 하나로 묶는 것입니다.

용어

모노레포 + MSA 배포입니다.

용어

전체 코드 맥락 파악(Full Context Visibility), 효율적인 지식 검색(RAG), 영향도 분석(Impact Analysis)입니다.

용어

인프라 단순화(그릇의 통합), 소통 비용 절감(메모리 호출), AI 시너지(한곳에 모인 정보 분석)입니다.

용어

표준 보일러플레이트와 공통 모듈 분리, API Contract 엄격 정의, API Gateway 도입, 분산 추적+중앙 로깅, 모노레포+Docker 이미지화입니다.

용어

하나의 시스템 안에서 서비스 특성에 따라 서로 다른 DB를 쓰는 전략입니다.

용어

업무 연관성, 유일한 식별자, 다수의 인스턴스, 프로세스 이용, 속성 포함, 관계 존재입니다.

용어

어떤 단어가 어디에 있는지를 빠르게 찾는, 단어 → 문서 위치를 거꾸로 저장한 색인 구조입니다.

용어

추출(Extraction), 변환(Transformation), 로딩(Loading)입니다.

용어

정제(중복 제거), 정비(빈 정보 채우기·오류 수정), 표준화(새 규칙에 맞게 형식 변경)입니다.

용어

결제·주문·회원 관리처럼 무결성이 절대적이면 RDBMS, 로그·캐시·콘텐츠·관계망처럼 유연성과 확장성이 중요하면 NoSQL입니다.

용어

Document(MongoDB), Key-Value(Redis), Wide-Column(Cassandra), Graph(Neo4j)입니다.

용어

확장 가능성(비정형·벡터 데이터 처리), 표준 준수(SQL 표준·DDD 모델 반영), 엔터프라이즈 신뢰성(RedHat과의 통합)입니다.

용어

브라우저→라우터는 JSON 텍스트, 라우터→유스케이스는 Schema 객체(검증), 유스케이스→리포지토리는 DTO(DB 구조를 모르게), 리포지토리→DB는 ORM Entity(테이블 구조에 맞춤)로 각 경계의 목적이 다르기 때문입니다.

용어

객체는 화물, API는 선로, Axios는 기관차, REST는 교통 법규에 대응됩니다.

용어

같은 구조가 크기만 바꿔 반복되기 때문에, 하나를 제대로 이해하면 아직 안 배운 것도 추론할 수 있다는 점에서 연결됩니다.

용어

도메인(핵심 로직)이 어떤 DB를 쓰는지 전혀 모르게 만드는 것입니다.

용어

복잡한 객체에서 순수한 값만 뽑아 전송 가능한 형태로 변환한 것입니다.