I-3. Advanced Object-Oriented Design: 설계의 정석

 

 

 

 

 

Advanced Object-Oriented Design: 설계의 정석

수십~수백억대 프로젝트의 성패는 코딩 실력이 아니라 **'설계의 깊이'**에서 결정됩니다. 그 중심에는 **객체 지향(Object-Oriented)**이라는 거대한 패러다임이 있습니다.

1. 절차 지향 vs 객체 지향: "레시피인가, 요리사인가"

프로그램을 만드는 방식은 크게 두 가지로 나뉩니다.

구분	절차 지향 (Procedural)	객체 지향 (Object-Oriented)
핵심 관점	어떻게(How) 처리할 것인가? <순서>	누가(Who) 무엇을 할 것인가? <관계>
데이터와 함수	데이터 따로, 함수 따로	데이터 + 메서드 = 객체(Object)
설계 방식	하향식(Top-down): 큰 문제를 쪼갬	상향식(Bottom-up): 부품을 만들어 조립
비유	일련의 과정이 적힌 '요리 레시피'	스스로 움직이는 '전문 요리사들'의 협업

 

2. 객체(Object)의 본질: "현실을 프로그램으로 옮기는 법"

객체 지향이 강력한 이유는 현실 세계의 논리를 그대로 프로그램 세계로 가져올 수 있기 때문입니다.

 

• 속성(Attribute) → 필드(Field/변수): 객체가 가진 상태 (예: 자동차의 바퀴 개수, 계좌의 잔고)
• 행동방식(Behavior) → 메서드(Method/함수): 객체가 하는 행위 (예: 자동차의 시동 걸기, 계좌의 입금하기)

3. Why 객체 "지향(Oriented)"인가?

왜 우리는 객체에 '지향'이라는 단어까지 붙여가며 열광할까요?

• Why 객체(Object)? 데이터(상태)와 행위가 하나로 묶인 독립적인 단위이기 때문입니다. 덕분에 복잡한 수백억대 시스템도 작은 부품(객체)들의 조합으로 안정적으로 관리할 수 있습니다.
• Why 지향(Oriented)? 시스템의 **중심(Center)**을 어디에 두느냐의 문제입니다. 함수(기능) 중심이 아닌, 실제 일의 주체인 객체를 중심으로 설계할 때 변화에 가장 유연하게 대처할 수 있습니다.

★ AX/DX 시대의 설계 통찰: 기획자가 객체 지향을 알아야 하는 이유

AI가 코드를 대신 짜주는 시대, 기획자의 가장 큰 무기는 **'비즈니스를 객체 단위로 정의하는 능력'**입니다.

• 기획자 관점: 서비스의 구성 요소를 '순서'로만 나열하면 기획이 꼬이기 쉽습니다. 하지만 이를 **'회원 객체', '주문 객체', '결제 객체'**로 나누어 각각의 속성과 행위를 정의하면 개발자와의 소통 비용이 획기적으로 줄어듭니다.
• 영역의 확장: 기획자가 객체의 속성을 정의하면 개발자가 그 행동방식을 구현합니다. 이제 자바의 객체 지향 개념은 개발 언어를 넘어, 비즈니스 아키텍처를 설계하는 공통의 사고 도구가 되었습니다.

 

 

 

 

 

은닉화와 캡슐화(Encapsulation): 객체의 방어 기제

객체 지향 설계에서 가장 중요한 원칙 중 하나는 **"내 데이터는 오직 내가 가진 함수로만 처리한다"**는 것입니다. 이를 위해 자바는 캡슐화와 은닉화라는 두 가지 강력한 방어 막을 제공합니다.

 

1. 캡슐화(Encapsulation)란?

관련된 데이터(변수)와 함수(메서드)를 하나의 '캡슐'처럼 묶는 것을 의미합니다.

• 비유: 감기약 캡슐 안에 여러 성분의 가루약(데이터)이 들어있지만, 우리는 그 성분 비를 몰라도 캡슐(객체)을 삼키기만 하면 됩니다.
• 효과: 클래스 내부 구현을 숨기고 사용자에게는 필요한 인터페이스(버튼)만을 제공하여, 데이터를 신뢰성 있게 관리하고 오류를 최소화합니다.

2. 실전 예시: ATM(현금지급기) 프로세스

우리가 ATM을 사용할 때 내부 회로가 어떻게 돌아가는지 알 필요가 없는 것과 같습니다.

• 인터페이스 제공: 사용자는 '입금', '출금', '잔액 조회'라는 메서드(버튼)를 통해서만 기계와 소통합니다.
• 직접 접근 제한: 만약 사용자가 기계를 뜯어 balance 변수 값을 직접 수정하게 둔다면 금융 사고가 날 것입니다. 따라서 변수 값의 변경은 반드시 검증 로직이 포함된 메서드를 통해서만 가능하도록 설계해야 합니다.

★ AX/DX 시대의 설계 통찰: "신뢰할 수 있는 부품 만들기"

AI가 시스템의 많은 부분을 자동으로 생성하는 시대일수록, 각 객체가 독립적으로 자신을 보호하는 캡슐화의 가치는 더욱 빛납니다.

• 기획자 관점: 서비스의 비즈니스 규칙(예: "잔액은 마이너스가 될 수 없다")을 메서드 내부에 감춤으로써, 기획서의 의도가 개발 단계에서 오염되지 않도록 보장합니다.
• 개발자 관점: 내부 로직을 수정하더라도 외부로 노출된 인터페이스가 변하지 않는다면, 다른 팀의 코드에 영향을 주지 않고 안전하게 시스템을 고도화할 수 있습니다.

 

 

 

상속(Inheritance): 가문의 유산과 효율적 확장

상속은 한 클래스가 가진 **속성(변수)과 행동방식(메서드)**을 다른 클래스가 고스란히 물려받아 기능을 구현하는 기술입니다. 이를 통해 우리는 이미 검증된 코드를 재사용하며 새로운 기능을 빠르게 덧붙일 수 있습니다.

1. 부모와 자식: "설계도의 계승"

• 부모 클래스 (Super Class): 자신의 멤버(속성과 기능)를 물려주는 상위 클래스입니다.
• 자식 클래스 (Sub Class): 부모로부터 유산을 물려받아 새롭게 탄생한 하위 클래스입니다.
• 효과: 코드의 재사용성과 확장성을 획기적으로 높여, 거대 프로젝트의 유지보수를 한결 수월하게 만들어 줍니다.

2. 절대 원칙: "IS-A 관계의 성립"

상속은 단순히 '기능이 비슷해서' 쓰는 도구가 아닙니다. 자바 설계의 정석은 **"자식은 부모의 일종이다(IS-A)"**라는 논리가 완벽히 성립할 때만 상속을 허용합니다.

• 올바른 예: 고양이는 포유류의 일종이다 (Cat is a Mammal) .
• 인사이트: 이 논리가 깨진 상속은 나중에 거대한 시스템을 무너뜨리는 부실 공사의 원인이 됩니다.

▶▷ AX/DX 시대의 설계 통찰: "표준화된 유산의 힘"

기획과 개발의 경계가 AI로 인해 허물어지는 지금, 상속의 개념은 **'비즈니스 표준의 확립'**과 직결됩니다.

• 기획자 관점: 서비스 기획 시 모든 기능을 새로 정의할 필요가 없습니다. "기본 주문"이라는 부모 객체를 잘 설계해두면, "선물하기 주문"이나 "정기 배송 주문"은 부모의 속성을 상속받아 차별화된 기능만 추가하면 됩니다. 이것이 바로 기획의 재사용성입니다.
• 개발자 관점: 상속을 통해 공통 로직을 부모 클래스에 모아두면(추상화), 수백억대 프로젝트에서 수천 개의 클래스가 존재하더라도 단 한 곳의 수정으로 전체 시스템의 규칙을 바꿀 수 있는 강력한 통제력을 얻게 됩니다.

★ 결론: "상속은 코드를 복사하는 것이 아니라, 개념을 확장하는 것이다"

부모의 유산(Code)을 물려받되, 자식만의 고유한 개성(Extension)을 더하는 상속은 자바를 진정한 객체 지향 언어로 만드는 핵심 장치입니다.

 

 

 

다형성(Polymorphism): 하나의 이름, 다양한 얼굴

다형성이란 그리스어에서 유래한 말로 **'많은 형태를 가지고 있다'**는 뜻입니다. 자바에서는 상속 관계를 이용해 하나의 인터페이스나 부모 클래스가 여러 가지 실제 구현체로 동작하는 것을 의미합니다.

 

다형성을 구현하는 두 가지 핵심 날개

1. 메서드 오버로딩(Overloading): 한 클래스 내에서 새로운 기능을 추가하는 '수평적' 확장입니다.
2. 메서드 오버라이딩(Overriding): 부모에게 물려받은 내용을 자식에 맞게 바꾸는 '수직적' 재정의입니다.
3. 다형적 변수(Polymorphic Variable): 부모 타입의 변수가 다양한 자식 객체를 가리킬 수 있는 유연함을 의미합니다.

 

구분	오버로딩 (Overloading)	오버라이딩 (Overriding)
핵심 설명	한 클래스 내에서 같은 이름의 메서드를 여러 개 정의	상속 관계에서 부모의 메서드를 가져와 재정의
관계	한 클래스 내 (수평적)	상속 관계 (수직적)
매개변수	반드시 달라야 함	반드시 같아야 함
결정 시점	컴파일 시점 (Static Binding)	런타임 시점 (Dynamic Binding)
비유	메뉴판의 '보통/곱빼기' 옵션	가업(레시피)을 물려받아 업그레이드

 

▶▷ AX/DX 시대의 설계 통찰: "표준화된 명령, 다양한 결과"

AI가 비즈니스 로직을 자동 생성하는 AX/DX 환경에서 다형성은 **'시스템의 범용성'**을 결정짓는 핵심 지표입니다.

• 기획자 관점: "결제하기"라는 하나의 기획(메서드 이름)만 있으면 됩니다. 실제 결제 수단이 '카드'든 '네이버페이'든 '비트코인'이든, 시스템은 다형성을 통해 적절한 구현체(오버라이딩)를 찾아 실행합니다. 기획자는 상세 구현이 아닌 추상적 흐름에 집중할 수 있게 됩니다.
• 개발자 관점: 다형적 변수를 활용하면, 새로운 결제 수단이 추가되어도 기존의 결제 처리 코드를 한 줄도 고칠 필요가 없습니다. 이는 수백억대 프로젝트에서 수정 비용을 최소화하고 결합도를 낮추는 결정적인 역할을 합니다.

 

 

 

 

 

추상 클래스 vs 인터페이스: 설계의 격을 결정하는 두 도구

복잡한 시스템을 설계할 때, 우리는 모든 것을 처음부터 새로 만들지 않습니다. 대신 **공통의 유산(추상 클래스)**을 물려받거나 **글로벌 규격(인터페이스)**을 준수함으로써 효율성을 극대화합니다.

1. 추상 클래스(Abstract Class): "가문의 유산과 가업"

• 의미: is-a (~은 ~이다) 관계를 나타내며, 미완성된 메서드(추상 메서드)를 포함한 클래스입니다.
• 핵심: 공통된 조상을 공유한다는 뜻으로, 부모가 가진 상태(변수)와 일반 기능을 물려주되 핵심적인 기능만 자식이 직접 구현하도록 강제합니다.
• 비유: **'라면 가문의 비법 가업'**입니다. 물 끓이기나 면 넣기는 부모가 다 가르쳐 주지만(일반 메서드), 가장 중요한 '특제 소스 배합'만은 자식이 각자의 가게 특성에 맞게 직접 만들어야 하는 것과 같습니다.

2. 인터페이스(Interface): "표준 규격과 자격증"

• 의미: can-do (~을 할 수 있다) 관계를 나타내며, 메서드의 이름(규격)만 정의된 '완전한 설계도'입니다.
• 핵심: 혈통이 무엇인지는 중요하지 않습니다. "이 기능을 할 줄 알면 이 규격대로 움직여라!"라고 계약하는 것과 같습니다.
• 비유: **'USB 포트 규격'**입니다. 제조사가 어디든, 마우스든 선풍기든 상관없습니다. 'USB 규격'에만 맞으면 컴퓨터에 꽂아 쓸 수 있는 범용성이 핵심입니다.

 

구분	추상 클래스 (Abstract Class)	인터페이스 (Interface)
개념	미완성 설계도	기본 설계도
관계(속성)	is-a (~은 ~이다)	can-do (~을 할 수 있다)
다중 상속	불가능	가능
상속 키워드	extends	implements
사용 시기	공통 필드와 메서드가 많을 때	전혀 다른 종류의 클래스들에게 공통 기능을 부여할 때

 

▶▷ 계층 구조로 보는 실전 아키텍처

• 추상 클래스의 힘: '생명체(Creature)' 하위에 '동물(Animal)'과 '물고기(Fish)'라는 혈통을 타고 내려오며 공통된 특성을 물려줍니다.
• 인터페이스의 확장성: '앵무새(Parrot)'는 동물이지만 날 수 있고(Flyable), 대화할 수 있습니다(Talkable). 고래(Whale)는 물고기 혈통은 아니지만 헤엄칠 수 있습니다(Swimmable).

이처럼 **혈통(상속)과 능력(인터페이스)**을 적절히 조합하는 것이 현대 자바 설계의 핵심입니다.

★ AX/DX 시대의 전문가 한 마디: "설계가 곧 소통입니다"

AI가 코딩을 돕는 시대일수록 기획자와 개발자는 **'개념의 위계'**를 잘 잡아야 합니다.

• 기획자 관점: 서비스의 본질(추상 클래스)이 무엇인지, 그리고 타 서비스와 연결될 규격(인터페이스)이 무엇인지 명확히 정의하면 프로젝트의 리스크가 획기적으로 줄어듭니다.
• 개발자 관점: 단순히 코드를 짜는 것이 아니라, 어떤 것을 '가업(Inheritance)'으로 남기고 어떤 것을 '자격증(Interface)'으로 관리할지 결정하는 아키텍트의 시야를 가져야 합니다.