146. 객체지향 분석 (OOA, Object-Oriented Analysis)

핵심 인사이트 (3줄 요약)

본질: 객체지향 분석(OOA)은 시스템을 함수(기능)와 데이터로 분리하던 과거의 구조적 방식을 폐기하고, 현실 세계의 사물이나 개념을 상태(Data)와 행동(Method)을 동시에 가진 **독립된 주체인 '객체(Object)'**로 추상화하여 분석하는 패러다임이다.

가치: 캡슐화, 상속, 다형성이라는 강력한 객체지향 메커니즘을 통해 소프트웨어 부품의 재사용성(Reusability)을 극대화하고, 요구사항 변경 시 파급 효과(Side Effect)를 최소화하는 극강의 유지보수성을 제공한다.

융합: OOA의 결과물은 UML(Unified Modeling Language)이라는 시각적 표준 언어로 그려지며, 이 분석 모델(Use Case, Class Diagram)은 다음 단계인 OOD(설계)와 OOP(Java, C++ 코딩)로 1:1 매끄럽게 번역되는 끊김 없는 소프트웨어 생명주기(SDLC)를 완성한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 객체지향 분석(Object-Oriented Analysis, OOA)은 사용자의 요구사항을 수집하고 분석하여 시스템 내에 존재해야 할 '객체'들을 식별해내고, 이 객체들 간의 관계(상속, 연관)와 메시지 교환(동적 행위)을 모델링하는 소프트웨어 공학 기법이다.
필요성: 1980년대까지만 해도 시스템은 '구조적 분석(DFD)'을 통해 데이터가 흘러가고 함수가 이를 가공하는 탑다운(Top-Down) 방식으로 쪼개졌다. 이 방식은 한 번 만들어진 코드를 다른 프로젝트에서 재사용하기 불가능했고, 데이터 구조(예: DB 컬럼)가 하나 바뀌면 시스템 전역의 수천 개 함수가 도미노처럼 터져버렸다(Ripple Effect). "부품(데이터+함수) 단위로 모듈을 독립시켜, 하나가 고장 나면 그것만 갈아 끼울 수 있고, 다른 프로젝트에 레고 블록처럼 들고 가서 조립할 수 있는 아키텍처"가 절실하게 요구되며 객체지향 혁명이 시작되었다.
💡 비유: 구조적 분석이 자동차 공장 전체를 하나의 거대한 '컨베이어 벨트(데이터 흐름)'로 설계하는 것이라면, 객체지향 분석은 타이어, 엔진, 핸들 같은 각각의 **'부품(객체)'**들을 먼저 정의하는 것입니다. 타이어 객체는 '공기압(Data)'과 '굴러가기(Method)'를 스스로 통제합니다. 엔진이 망가져도 타이어는 영향을 받지 않으며, 이 타이어 도면을 그대로 트럭이나 비행기 프로젝트에 재사용할 수 있습니다.
등장 배경:
1. 절차적 프로그래밍의 한계: C언어 등으로 짜인 수백만 줄의 코드가 스파게티처럼 엉켜 유지보수가 불가능해지는 '소프트웨어 위기' 2라운드 발생.
2. 객체지향 프로그래밍(OOP)의 부상: Smalltalk, C++, Java 등 객체지향 언어가 시장을 지배하자, 분석과 설계 단계에서도 동일한 '객체' 관점의 렌즈가 필요해졌다.
3. UML 천하통일: 1990년대 럼바우(Rumbaugh), 부치(Booch), 제이콥슨(Jacobson) 등 세 거장이 난립하던 표기법을 통합하여 UML(Unified Modeling Language) 표준을 발표하며 OOA는 개발 방법론의 제왕으로 등극했다.

┌─────────────────────────────────────────────────────────────┐
│          구조적 분석(DFD) vs 객체지향 분석(OOA) 아키텍처 철학 비교     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ [ ❌ 구조적 분석: 데이터와 행위의 분리 (Top-Down) ]                   │
│                                                             │
│         [함수 1] 입금() ────┐                                  │
│         [함수 2] 출금() ────┼──▶ [전역 데이터] "계좌 잔고 DB"      │
│         [함수 3] 이자계산() ──┘                                  │
│ 💥 문제점: 계좌 DB 구조가 1바이트라도 바뀌면, 입금/출금/이자계산 함수를     │
│           전부 뒤져서 코드를 뜯어고쳐야 한다. (유지보수 지옥)            │
│                                                             │
│ [ ✅ 객체지향 분석: 데이터와 행위의 캡슐화 (Bottom-Up) ]              │
│                                                             │
│        ╔══════════════════════════════════════╗             │
│        ║  "Account (계좌) 객체"                 ║             │
│        ║ ------------------------------------ ║             │
│        ║ - 잔고(balance): 외부 접근 절대 금지 🔒  ║             │
│        ║ ------------------------------------ ║             │
│        ║ + 입금(amount): 잔고를 안전하게 증가시킨다║             │
│        ║ + 출금(amount): 잔고 부족 시 에러 던짐  ║             │
│        ╚══════════════════════════════════════╝             │
│ 🌟 장점: 잔고(Data)를 숨기고 오직 공개된 함수(Method)로만 소통한다.        │
│          계좌 객체의 내부 로직이 바뀌어도 외부 시스템은 전혀 타격을 받지 않는다!│
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] OOA의 가장 위대한 아키텍처적 도약인 **캡슐화(Encapsulation)**와 **정보 은닉(Information Hiding)**의 본질을 보여준다. 구조적 방식에서는 데이터가 벌거벗은 채 전역에 노출되어 모든 함수가 데이터를 난도질했다. 객체지향 방식에서는 데이터(잔고)를 강철 금고(객체) 깊숙이 가두고, 오직 은행 창구 직원(공개 메서드)을 통해서만 입출금을 지시하도록 통제한다. 이 완벽한 단절(Decoupling) 덕분에 내부 금고 모델을 아날로그에서 디지털로 업그레이드해도 창구 밖의 고객(다른 모듈)은 그 변화를 전혀 눈치채지 못하고 평화롭게 서비스를 이용할 수 있다.

📢 섹션 요약 비유: 옛날엔 TV가 고장 나면 뚜껑을 열고 수많은 전선을 하나하나 납땜해야 했지만(절차적), 지금은 그냥 메인보드 칩(객체) 하나를 톡 뽑아서 새 칩으로 갈아 끼우면(캡슐화/교체) 1초 만에 수리가 끝나는 모듈형 전자제품과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

OOA의 4가지 핵심 원칙 (Core Principles)

객체를 식별하고 시스템을 빚어낼 때 지켜야 할 절대적인 철학이다.

원칙	영문	개념	아키텍처적 효과 (비유)
추상화	Abstraction	복잡한 현실 사물에서 당장 시스템에 필요한 핵심 속성만 뽑아내어 모델링하는 것. (예: 병원 앱의 '사람'은 혈액형이 중요하지만, 배달 앱의 '사람'은 주소가 중요함)	지하철 노선도 (진짜 지형을 무시하고 환승역만 단순화)
캡슐화	Encapsulation	데이터(속성)와 이를 조작하는 함수(메서드)를 하나의 보따리(클래스)로 묶고, 외부에는 리모컨 버튼(인터페이스)만 공개하는 정보 은닉.	TV 리모컨 (내부 회로를 몰라도 채널 버튼만 누르면 됨)
상속성	Inheritance	이미 만들어진 부모 객체의 속성과 행위를 자식 객체가 그대로 물려받아, 중복 코드를 제거하고 기능을 확장하는 재사용성.	설계도 복사 (자동차 도면을 복사해 바퀴만 키워서 트럭 제작)
다형성	Polymorphism	동일한 이름의 명령(메시지)을 내렸을 때, 메시지를 받는 객체에 따라 각자 다르게 동작하는 유연성. (오버라이딩, 오버로딩)	"울어!" 명령 (개는 멍멍, 고양이는 야옹, 소는 음메)

주요 객체지향 분석 방법론 (3대 거장)

UML로 통일되기 직전, 1990년대를 풍미했던 3대 분석 방법론이다. 기술사/감리사 시험의 단골 출제 키워드다.

럼바우 (Rumbaugh) 방법론 (OMT: Object Modeling Technique)
- 분석 절차가 가장 체계적이라 가장 많이 출제된다. "객동기(객체-동적-기능)" 순서로 분석한다.
- 객체 모델링(Object) ➔ 동적 모델링(Dynamic) ➔ 기능 모델링(Functional) 순서로 진행.
- 객체 모델: 시스템의 정적 구조(ERD 같은 클래스 도면)를 그린다.
- 동적 모델: 상태 변화와 제어 흐름(상태 변화도, State Transition Diagram)을 그린다.
- 기능 모델: 데이터 흐름과 프로세스(DFD)를 그린다.
부치 (Booch) 방법론
- 시스템을 거시적(Macro) 개발 프로세스와 미시적(Micro) 개발 프로세스로 명확히 분리한다.
- 클래스와 객체들의 관계를 풍부한 도형 도구로 표현하는 데 집중했다.
제이콥슨 (Jacobson) 방법론 (OOSE: Object-Oriented Software Engineering)
- "유스케이스 (Use Case)" 개념을 최초로 창안한 위대한 방법론이다.
- 시스템 외부의 사용자(Actor) 관점에서 시스템이 제공해야 할 서비스(Use Case)를 도출하여 분석의 뼈대로 삼는다. 현대 애자일(Agile) 요구사항 분석의 모태가 되었다.

📢 섹션 요약 비유: 집을 지을 때, 럼바우는 '뼈대-전기배선-수도관' 순서의 체계적인 공사 매뉴얼을 썼고, 부치는 집안의 '가구 배치와 동선'을 꼼꼼히 그렸으며, 제이콥슨은 가족들이 "거실에선 TV를 본다, 주방에선 밥을 먹는다"라는 '사용 시나리오'를 먼저 적어두고 집을 설계한 천재들입니다.

Ⅲ. 융합 비교 및 다각도 분석

비교 1: 럼바우 OMT 모델링 3단계 딥다이브

가장 중요한 럼바우의 3단계 분석물을 명확히 비교한다.

단계	모델명	목적 (What to answer?)	산출물 도면 (Diagram)	현대 UML 대응
1단계	객체 모델링 (Object)	"이 시스템엔 어떤 사물들이 존재하고 서로 어떻게 연결되어 있는가?"	객체 다이어그램, 클래스 다이어그램	Class Diagram
2단계	동적 모델링 (Dynamic)	"시간의 흐름에 따라 객체들의 상태(State)가 언제 어떻게 변하는가?"	상태 다이어그램 (State Transition)	Statechart / Sequence
3단계	기능 모델링 (Functional)	"데이터가 입력되면 어떤 연산을 거쳐 결과물이 출력되는가?"	자료 흐름도 (DFD)	Activity / Use Case

(암기 팁: 럼바우는 "객-동-기" 순서로 분석한다)

과목 융합 관점

데이터베이스 (DB): OOA 단계에서 만들어진 '클래스 다이어그램(Class Diagram)'의 클래스들은 DB 설계 페이즈(Logical/Physical Design)로 넘어가면 거의 1:1로 RDBMS의 테이블(Table)이 되고, 클래스의 속성(Attribute)은 테이블의 컬럼(Column)이 된다. 이때 객체지향의 복잡한 상속(Inheritance) 관계를 2차원 평면 테이블로 억지로 욱여넣으면서 발생하는 충돌 현상을 **임피던스 불일치(Impedance Mismatch)**라 하며, 이를 마법처럼 해결해 주는 미들웨어가 바로 ORM(JPA, Hibernate)이다.
클라우드 & 마이크로서비스 (MSA): 과거 OOA는 하나의 거대한 모놀리식(Monolithic) 성을 짓기 위한 도구였으나, 현대 MSA 환경에서는 OOA 철학이 확장된 **도메인 주도 설계(DDD, Domain-Driven Design)**가 백엔드 아키텍처의 제왕이 되었다. "어느 객체들끼리 끈끈하게 묶여야(Bounded Context) 하는가?"를 분석하여 그 경계선을 칼로 자르면 완벽하게 독립적인 마이크로서비스(API 서버) 하나가 뚝딱 탄생하게 된다.
📢 섹션 요약 비유: 클래스(객체) 다이어그램이 '붕어빵 틀 도면'이라면, 데이터베이스 테이블은 다 구워진 붕어빵들을 겹겹이 쌓아두는 2차원 '진열대'입니다. 입체적인 틀(객체)을 평면 진열대(DB)에 어떻게 끼워 맞출지 고민하는 것이 백엔드 아키텍처의 가장 큰 숙제입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 다형성(Polymorphism)을 활용한 결제 시스템 리팩토링: 신입 개발자가 쇼핑몰 결제 로직을 짜며 if(type == "CARD") 카드결제(); else if(type == "BANK") 무통장결제(); else if(type == "POINT") 포인트결제(); 처럼 지저분한 하드코딩 분기문을 짰다. 사장님이 "카카오페이 추가해!"라고 지시할 때마다 이 핵심 로직을 뜯어고치다 버그가 터져 매출이 날아갔다.
- 판단: 구조적 사고에 갇힌 전형적인 안티패턴이다. 아키텍트는 OOA 관점에서 시스템을 분석하여 Payment라는 부모 인터페이스(추상 객체)를 뽑아내고, 그 안에 pay()라는 빈 껍데기 메서드를 선언한다. 그리고 자식 객체들(CardPayment, KakaoPayment)이 상속받아 각자 자기만의 pay()를 구현(Overriding)하게 만든다. 메인 로직은 그냥 payment.pay() 한 줄만 호출(다형성)하면 끝난다. 카카오페이가 추가되어도 기존 로직은 0.1줄도 건드리지 않고 새로운 블록만 꽂아 넣는 개방-폐쇄 원칙(OCP)의 기적이 일어난다.
시나리오 — OOA 기반 도메인 분리(Bounded Context) 실패로 인한 스파게티 MSA: 차세대 시스템 구축 시 "객체지향 분석을 완벽하게 했다"며 쇼핑몰의 모든 부서가 쓰는 공통된 거대 User 객체(클래스)를 설계했다. 이 객체 안에는 로그인 정보, 주문 내역 100건, 배송지 5곳, 장바구니 리스트가 전부 주렁주렁 매달려 있었다. 회원가입 서버가 배포를 할 때마다 배송 서버와 결제 서버가 같이 죽는 커플링(Coupling) 재앙이 터졌다.
- 판단: 추상화(Abstraction) 원칙을 어긴 무지성 통합의 폐해다. 인증 도메인의 User 객체는 'ID/PW'만 가지면 되고, 배송 도메인의 User 객체는 '집 주소'만 가지면 된다. 똑같은 '사람'이라도 문맥(Context)에 따라 전혀 다른 미니 객체로 찢어서 분석(DDD 철학)해야만 MSA 시스템이 결합도를 끊고 독립적으로 숨을 쉴 수 있다.

  ┌─────────────────────────────────────────────────────────────┐
  │         실무 아키텍처: 다형성을 통한 개방-폐쇄 원칙(OCP) 구현 로직    │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ [❌ 절차적 분석의 지옥 (If-Else 폭탄)]                             │
  │ function processPayment(Payment type) {                     │
  │     if (type == CREDIT_CARD) card.process();                │
  │     else if (type == PAYPAL) paypal.process();              │
  │     else if (type == APPLE_PAY) apple.process(); ◀─ 신규 추가 시│
  │     // 💥 새 결제수단 생길 때마다 이 핵심 파일이 계속 수정됨(위험!) │
  │ }                                                           │
  │                                                             │
  │ [✅ 객체지향 분석의 기적 (다형성과 캡슐화)]                           │
  │                                                             │
  │ 1. 인터페이스 (추상화 도면)                                    │
  │    interface PaymentMethod {  void pay();  }                │
  │                                                             │
  │ 2. 각 객체는 자신의 결제 로직만 캡슐화하여 구현                      │
  │    class CardPayment implements PaymentMethod { pay() {...} }│
  │    class ApplePayment implements PaymentMethod { pay() {...} }│
  │                                                             │
  │ 3. 결제 메인 로직 (영원히 수정되지 않음!)                        │
  │    function processPayment(PaymentMethod method) {          │
  │        method.pay();   ◀─ 🌟 다형성(Polymorphism) 발동!      │
  │    }                                                        │
  │                                                             │
  │ ✅ 판단: 비트코인 결제가 추가되어도? 그냥 BitcoinPayment 클래스만 새로│
  │ 만들어서 끼워 넣으면 끝! 메인 함수는 1바이트도 수정되지 않는다. (OCP 달성)│
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 객체지향 분석(OOA)과 설계(OOD)가 만나 탄생하는 가장 위대한 아키텍처 패턴인 "다형성을 이용한 의존성 역전(SOLID의 OCP, DIP 원칙)"을 직관적으로 보여준다. 구조적 사고방식(상단)은 "내가 무엇을 해야 하는지"를 일일이 분기문으로 제어하려 하므로 시스템이 딱딱하게 굳어버린다. 반면 객체지향 사고방식(하단)은 "리모컨 버튼(pay())을 누를 테니, 카카오페이든 애플페이든 너희 객체들이 각자 알아서 행동해라"라고 책임을 위임한다. 이 거대한 패러다임의 역전 덕분에 현대 앱(App)들의 눈부신 무중단 업데이트와 기능 확장이 가능해졌다.

도입 체크리스트

기술적: 유스케이스(Use Case) 분석 시, 고객의 모든 요구사항을 "명사(객체)"와 "동사(행위)"로 명확하게 발라내고, 불필요한 조사나 수식어는 과감히 쳐내어 시스템에 진정 필요한 핵심 객체(Entity) 후보군 10개 내외로 압축해 냈는가?
운영·보안적: 캡슐화를 핑계로 getter/setter를 떡칠해 놓아, 외부에서 객체의 데이터를 마음대로 끄집어내어 조작하는 가짜 객체지향(빈약한 도메인 모델, Anemic Domain Model)을 설계하지는 않았는가? (진짜 객체지향은 데이터를 달라고 하지 말고, 객체에게 일을 하라고 명령(Tell, Don't Ask)해야 한다).

안티패턴

절차적 코드를 억지로 클래스로 감싸기 (God Object): Manager, Controller, Util 같은 이름을 가진 거대한 클래스 1개를 만들어 놓고, 그 안에 시스템의 모든 5천 줄짜리 로직 함수를 때려 박아 넣는 행위. 껍데기만 class일 뿐 내부는 1970년대 C언어 절차적 코딩과 완벽히 똑같은 최악의 안티패턴(전지전능 객체)이다. 시스템은 수십 개의 작고 독립된 객체들의 소통으로 쪼개져야 한다.
📢 섹션 요약 비유: "가짜 객체지향"은 사장이 직원들의 일거수일투족을 마이크로 매니징(Getter/Setter)하며 지시하는 숨 막히는 회사이고, "진짜 객체지향"은 사장이 각 부서 전문가(객체)들에게 "결과물만 언제까지 내놔(Message/Method)"라고 믿고 맡기는 완벽한 자율 분업형 회사입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	구조적 분석 (Top-Down)	객체지향 분석 (Bottom-Up 캡슐화)	개선 효과
정량	타 프로젝트 로직 재사용률 10% 미만	부품화된 객체 클래스 재사용	소프트웨어 개발 코드 라인 재사용률 50% 이상 폭증
정량	DB 변경 시 전역 스크립트 수정 필요	객체 내부만 수정하면 끝 (은닉)	비즈니스 로직 변경 시 파급 효과(Ripple Effect) 수십 배 단축
정성	설계도와 소스 코드 구조가 완전히 다름	UML 설계도 ➔ Java 코드로 1:1 직역	분석-설계-구현(SDLC) 간의 끊김 없는 심리스(Seamless) 통합 달성

미래 전망

도메인 주도 설계 (DDD)로의 진화: OOA의 1990년대 철학은 2000년대 후반 에릭 에반스의 '도메인 주도 설계(DDD)'로 진화하며 궁극의 깨달음에 도달했다. 데이터와 기능을 묶는 단순한 객체 개념을 넘어, 현실 세계의 복잡한 비즈니스 규칙(Domain) 자체를 코드의 중심에 놓고, 보편적 언어(Ubiquitous Language)를 통해 기획자와 개발자가 완벽히 소통하는 클라우드 MSA 시대의 바이블이 되었다.
함수형 프로그래밍(FP)과의 타협: 상태(State)를 내부 공간에 숨겨둔다는 객체지향의 미덕은, 수천 개의 스레드가 동시에 접근하는 동시성(Concurrency) 환경에서 치명적인 교착 상태(Deadlock)를 낳는 부작용을 일으켰다. 이에 현대 스칼라(Scala), 코틀린(Kotlin) 같은 언어 환경에서는 OOA의 거시적 모듈 구조는 차용하되, 불변(Immutable) 데이터와 순수 함수를 강제하는 '함수형 프로그래밍' 패러다임을 섞어 쓰는 하이브리드 진화가 일상화되었다.

참고 표준

UML (Unified Modeling Language) 2.x: OMG(Object Management Group)에서 관리하는 객체지향 분석/설계의 전 세계 공식 사실상 표준 시각 언어
SOLID 원칙: 로버트 C. 마틴이 정리한 객체지향 시스템을 견고하게 유지하기 위한 5대 설계 원칙

구조적 분석이 "소프트웨어는 순차적으로 흐르는 기계의 컨베이어 벨트"라고 믿었던 시대의 투박한 철학이었다면, 객체지향 분석은 "소프트웨어는 스스로 생각하고 행동하는 수많은 유기체(객체)들이 살아 숨 쉬며 소통하는 거대한 생태계"라는 아름답고 복잡한 패러다임 시프트다. 비록 그 추상화의 깊이 탓에 초심자들이 UML과 객체 철학을 깨우치는 데 오랜 허들을 겪지만, 일단 이 '객체라는 레고 블록'의 시야를 장착하고 나면 수백만 줄의 거대한 클라우드 시스템도 단 몇 개의 작은 상자 조립으로 단순화해 낼 수 있는 위대한 아키텍트의 능력을 얻게 된다.

📢 섹션 요약 비유: 피자를 만들 때 옛날 방식(구조적)은 밀가루 반죽부터 굽기까지 10명의 요리사가 순서대로 달라붙는 일방통행 공장이었다면, 객체지향은 도우 전문가(객체), 소스 전문가(객체), 토핑 전문가(객체)가 각자의 비법을 숨긴 채(캡슐화) 완벽하게 구워낸 결과물만 조립하는 미슐랭 3스타 레스토랑의 주방입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
UML (Unified Modeling Language)	난립하던 OOA 방법론(럼바우, 부치, 제이콥슨)의 도면들을 전 세계 공통의 다이어그램 표준으로 통일시킨 객체지향의 공식 언어다.
캡슐화 (Encapsulation) & 정보 은닉	남이 내 데이터를 함부로 건드리지 못하게 꽁꽁 싸매고(은닉), 외부에는 안전한 버튼(메서드)만 공개하는 객체지향 철학의 최우선 방어벽이다.
다형성 (Polymorphism)	하나의 리모컨 버튼(메서드 이름)을 눌러도 TV, 에어컨, 라디오가 각자 다르게 작동하게 만드는 유연성으로, 개방-폐쇄 원칙(OCP)의 마법 지팡이다.
Use Case (유스케이스)	제이콥슨이 창안한 모델로, "시스템 안쪽의 코드가 아니라 바깥쪽의 고객(Actor) 입장에서 이 시스템이 무슨 서비스 가치가 있는가"를 먼저 정의하는 OOA의 출발점이다.
DDD (Domain-Driven Design)	객체지향 분석의 철학을 마이크로서비스(MSA)라는 클라우드 시대에 맞게 재해석하여, 거대한 비즈니스를 작고 단단한 문맥(Bounded Context)으로 쪼개는 최신 설계 사상이다.

👶 어린이를 위한 3줄 비유 설명

옛날에는 로봇 장난감을 통째로 하나로 만들어서, 팔이 부러지면 로봇 전체를 버려야만 했어요 (구조적 분석).
객체지향 분석은 로봇을 '팔 부품', '다리 부품', '머리 부품(객체)'으로 쪼개서 블록처럼 조립하는 방법이에요!
이렇게 설계하면 팔이 고장 났을 때 팔 블록만 새것으로 쏙 빼서 갈아 끼우면 되고(캡슐화), 이 튼튼한 다리 블록을 공룡 로봇을 만들 때 다시 갖다 쓸 수도 있어서(재사용) 개발자 아저씨들이 엄청 좋아한답니다!