Dev

Apr 12, 2026

마지막 업데이트 Apr 14, 2026

객체 지향 프로그래밍 가이드: OOP가 책임과 변경을 정리하는 방식

객체 지향 프로그래밍은 자주 “클래스와 객체를 쓰는 방식”으로 소개됩니다. 틀린 말은 아니지만, 왜 OOP가 중요한지, 왜 큰 시스템에서 계속 다시 등장하는지를 설명하기에는 너무 얕습니다.

좋은 OOP는 책임을 더 선명하게 나누고, 상태를 더 안전하게 보호하고, 변경이 한꺼번에 퍼지지 않도록 만드는 설계 방식에 가깝습니다. 핵심은 클래스 문법이 아니라 경계를 잘 세우는 데 있습니다.

이 글에서는 아래 내용을 다룹니다.

객체 지향 프로그래밍이 실제로 무엇을 해결하려는지
언제 OOP가 도움이 되고 언제 과한지
핵심 OOP 개념이 SOLID와 실무 설계에 어떻게 이어지는지

핵심만 먼저 말하면 이렇습니다. 프로그램이 더 이상 단순한 절차 나열이 아니라, 서로 협업하는 여러 부분으로 커지기 시작할 때 OOP의 가치가 커집니다.

객체 지향 프로그래밍이란 무엇인가

객체 지향 프로그래밍은 아래를 함께 가진 객체 중심으로 코드를 구성합니다.

상태
동작
다른 객체와의 협업

좋은 OOP에서 객체는 단순한 필드 묶음이 아닙니다. 시스템 일부의 행동을 책임지고, 자기 상태에 붙은 규칙을 스스로 지키는 단위입니다.

그래서 OOP의 핵심 질문은 아래에 더 가깝습니다.

이 데이터는 누가 소유하는가
누가 이 상태를 바꿀 수 있어야 하는가
이 판단은 어느 객체가 맡아야 하는가

이 책임 질문들이 class 키워드보다 더 중요합니다.

OOP는 어떤 문제를 풀려고 하는가

소프트웨어가 커질수록 자주 생기는 고통이 있습니다.

로직이 몇 개 함수에 과하게 몰리고
상태가 너무 많은 곳에서 바뀌고
한 변경이 무관한 부분까지 흔들고
누가 무엇을 책임지는지 흐려집니다

OOP는 이런 복잡성을 줄이기 위해 책임을 더 국소화하는 한 가지 방법입니다.

잘 적용되면 OOP는 아래에 도움이 됩니다.

관련 상태와 동작을 함께 두기
협업 관계를 더 명시적으로 만들기
우발적 결합 줄이기
불변식과 규칙을 객체 내부에 보호하기

이게 진짜 가치입니다.

작은 예시: 절차형으로 흩어지는 로직 vs 객체의 책임

장바구니가 느슨한 데이터로 관리된다고 해보겠습니다.

const cart = {
  items: [] as { price: number; quantity: number }[],
  total: 0,
};

function addItem(cart: typeof cart, price: number, quantity: number): void {
  cart.items.push({ price, quantity });
  cart.total += price * quantity;
}

function applyDiscount(cart: typeof cart, percent: number): void {
  cart.total = cart.total * (1 - percent);
}

단순하지만, 여러 함수가 장바구니 상태를 제각각 바꾸기 쉬운 구조입니다.

OOP 방식은 규칙 소유권을 장바구니 안으로 옮길 수 있습니다.

class ShoppingCart {
  private items: { price: number; quantity: number }[] = [];
  private discountPercent = 0;

  addItem(price: number, quantity: number): void {
    this.items.push({ price, quantity });
  }

  applyDiscount(percent: number): void {
    if (percent < 0 || percent > 100) {
      throw new Error('discount must be between 0 and 100');
    }

    this.discountPercent = percent;
  }

  getTotal(): number {
    const subtotal = this.items.reduce((sum, item) => sum + item.price * item.quantity, 0);
    return subtotal * (1 - this.discountPercent / 100);
  }
}

이제 객체는 데이터를 담는 통이 아니라, 그 데이터에 붙은 규칙까지 함께 지키는 주체가 됩니다.

이게 OOP가 하려는 일의 좋은 축약입니다. 소유권을 선명하게 만드는 것.

클래스보다 더 중요한 것

입문자는 자주 문법 질문부터 떠올립니다.

클래스는 언제 써야 하지
상속은 언제 하지
메서드는 어디에 둬야 하지

물론 중요하지만, 더 본질적인 질문은 아래입니다.

이 책임은 어디에 있어야 하지
이 상태는 누가 지켜야 하지
이 객체는 다른 것들과 어떻게 협업해야 하지
한 부분을 바꿔도 전체를 덜 흔들 수 있나

이 질문이 정리되지 않으면, 클래스를 많이 써도 좋은 OOP가 되지는 않습니다.

OOP를 유용하게 만드는 핵심 개념

아래 개념들은 같은 큰 목표를 돕기 때문에 자주 함께 배웁니다.

캡슐화

상태와 그 상태를 지키는 규칙을 함께 둡니다.

추상화

구현 잡음 대신 적절한 수준의 개념을 드러냅니다.

다형성

호출자는 하나의 안정된 메시지를 쓰고, 동작 차이는 계약 뒤로 숨깁니다.

조합

상속 계층에 모든 걸 밀어 넣기보다, 필요한 행동을 부품처럼 조합합니다.

이것들은 단어 암기가 아니라 변경 경계를 만드는 도구들입니다.

OOP가 특히 잘 맞는 경우

OOP는 보통 아래 상황에서 힘이 좋습니다.

상태와 규칙이 있는 엔티티가 의미 있게 존재한다
상태와 그 상태에 대한 비즈니스 규칙을 함께 두는 편이 낫다
여러 부분의 협업이 점점 복잡해진다
변경 압력이 커져서 경계 품질이 중요해진다

그래서 아래 같은 시스템에서 자주 쓰입니다.

비즈니스 애플리케이션
백엔드 서비스
도메인 규칙이 점점 늘어나는 장수 코드베이스

언제 OOP가 과할 수 있는가

모든 문제에 OOP가 정답은 아닙니다.

아래 상황에서는 과한 구조가 될 수 있습니다.

작은 일회성 스크립트
단순한 데이터 변환 파이프라인
상태도 적고 장기적 변경 압력도 작다
객체를 도입해도 소유권이 더 선명해지지 않는다

좋은 엔지니어링은 “항상 OOP”가 아니라, 현재 문제를 가장 잘 설명하는 구조를 고르는 일입니다.

자주 하는 오해

1. 클래스를 쓰면 자동으로 OOP를 잘하는 것이다

그렇지 않습니다. 클래스 기반 코드 안에서도 책임은 얼마든지 엉킬 수 있습니다.

2. OOP의 핵심은 상속이다

현대 설계에서는 깊은 상속보다 조합이 더 안전하고 유연한 경우가 많습니다.

3. OOP는 현실 세계를 그대로 흉내 내는 것이다

도메인 은유가 도움이 될 때도 있지만, 더 중요한 것은 소프트웨어 책임을 잘 나누는 것입니다.

4. OOP는 언제나 유지보수성이 가장 좋다

경계를 잘 만들 때 그렇습니다. 객체를 잘못 설계하면 절차형 못지않게 엉킬 수 있습니다.

OOP로 풀기 전에 보는 체크리스트

아래 질문이 도움이 됩니다.

이 부분에는 의미 있는 상태와 규칙이 있는가
상태와 행동을 함께 두면 혼란이 줄어드는가
현재 설계에서 ownership이 흐린가
시스템이 커지면서 협업 경계가 더 중요해졌는가

대답이 대부분 “그렇다”면 OOP가 좋은 선택일 가능성이 큽니다.

FAQ

Q. OOP와 SOLID는 같은 말인가요?

아닙니다. OOP는 더 넓은 프로그래밍/설계 접근이고, SOLID는 그 위에서 많이 쓰는 설계 원칙 묶음입니다.

Q. 입문자는 클래스부터 배워야 하나요, 책임부터 봐야 하나요?

책임부터 보는 편이 훨씬 좋습니다. 누가 무엇을 가져야 하는지가 정리되면 클래스 구조는 자연스럽게 따라옵니다.

Q. 요즘 소프트웨어에서도 OOP가 여전히 중요한가요?

그렇습니다. 패러다임을 섞어 쓰더라도 책임, 상태 보호, 협업 경계는 여전히 핵심 설계 문제입니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.