32일차. IT 개념 정리

 

SOLID 원칙이란?

SOLID는 객체지향 프로그래밍(OOP)에서 유지보수성과 확장성을 높이기 위해 제안된 5가지 설계 원칙을 말합니다.
로버트 C. 마틴(Robert C. Martin, 흔히 '클린 코드'의 저자)이 정리한 개념입니다.

아래에서는 요약 → 상세 설명 → 예시 구조로 깔끔하게 정리해 드릴게요.

---

🔎 SOLID 5대 원칙 요약

약어원칙 이름핵심 의미

S	단일 책임 원칙 (Single Responsibility Principle)	클래스는 하나의 책임만 가져야 한다
O	개방-폐쇄 원칙 (Open/Closed Principle)	기능은 확장에는 열려 있고, 변경에는 닫혀 있어야 한다
L	리스코프 치환 원칙 (Liskov Substitution Principle)	자식 클래스는 부모 타입을 대체할 수 있어야 한다
I	인터페이스 분리 원칙 (Interface Segregation Principle)	불필요한 기능이 포함된 크고 뚱뚱한 인터페이스를 나눠라
D	의존 역전 원칙 (Dependency Inversion Principle)	상위 모듈은 하위 모듈에 의존하면 안 되고, 추상화에 의존해야 한다

 

S: 단일 책임 원칙 (SRP - Single Responsibility Principle)

이 원칙은 "하나의 클래스는 하나의, 오직 하나의 책임만 가져야 한다"고 이야기해요. 즉, 클래스를 변경해야 하는 이유는 단 하나뿐이어야 한다는 뜻입니다.  만약 한 클래스가 너무 많은 책임을 지게 되면, 한 기능을 수정했을 때 의도치 않게 다른 기능에까지 영향을 줄 수 있어서 유지보수가 매우 어려워질 수 있어요. 따라서 책임들을 잘게 쪼개어 분리하는 것이 중요하답니다.  예를 들어, 은행의 금리 계산 클래스가 수신(예금) 금리 계산과 여신(대출) 금리 계산을 동시에 담당하는 대신, 각각의 책임을 분리하여 개별 클래스로 만드는 것이 SRP를 잘 따르는 방법이 될 수 있어요. 

O: 개방-폐쇄 원칙 (OCP - Open-Closed Principle)

"확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다"는 원칙입니다.  이 말은 기존 코드를 수정하지 않고도 새로운 기능을 추가하거나 변경할 수 있도록 설계해야 한다는 의미예요. 새로운 요구사항이 발생했을 때 기존 코드를 건드리지 않고 새로운 코드를 추가하는 방식으로 기능을 확장할 수 있도록 설계하는 것이 목표입니다.

L: 리스코프 치환 원칙 (LSP - Liskov Substitution Principle)

"자식 클래스는 언제나 부모 클래스를 대체할 수 있어야 한다"는 원칙이에요. 즉, 부모 클래스의 객체가 들어갈 자리에 어떤 자식 클래스의 객체를 넣어도 프로그램의 동작이 원래 의도대로 문제없이 작동해야 한다는 뜻이랍니다. 다형성을 올바르게 활용하기 위한 중요한 지침이죠.

I: 인터페이스 분리 원칙 (ISP - Interface Segregation Principle)

"클라이언트는 자신이 사용하지 않는 메서드에 의존해서는 안 된다"는 원칙입니다. 다시 말해, 인터페이스를 너무 크고 범용적인 것으로 만들기보다는, 클라이언트의 용도에 맞게 작고 구체적인 여러 인터페이스로 분리하는 것이 좋습니다. 클라이언트가 불필요한 기능까지 한꺼번에 포함된 인터페이스를 구현하도록 강제하지 않기 위함이에요.

D: 의존관계 역전 원칙 (DIP - Dependency Inversion Principle)

이 원칙은 "고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 이들 모두 추상화에 의존해야 한다. 또한 추상화는 세부 사항에 의존해서는 안 되며, 세부 사항은 추상화에 의존해야 한다"고 설명합니다.  쉽게 말해, 구체적인 구현체(저수준 모듈)보다는 추상적인 개념(인터페이스나 추상 클래스)에 의존하여 설계해야 한다는 뜻이에요. 예를 들어, 커피를 제조하는 고수준 클래스가 특정 브랜드의 커피 머신이라는 저수준 구현체에 직접 의존하기보다는, '커피 추출 인터페이스'와 같은 추상화된 개념에 의존하면 나중에 다른 종류의 커피 머신으로 교체해도 고수준 클래스는 변경 없이 사용할 수 있습니다. 

이 SOLID 원칙들은 객체 지향 프로그래밍의 기반이 되는 중요한 개념들

 

---

📘 원칙별 자세한 설명

1) 단일 책임 원칙 (SRP)

클래스가 여러 일을 하면 결합도가 높아지고 수정 시 다른 기능까지 영향을 받습니다.
→ 한 클래스는 한 가지 역할만!

예시:
Order 클래스가 주문 생성 + 결제 처리 + 영수증 출력까지 담당하면 X
→ Order, PaymentService, ReceiptPrinter 등으로 분리하는 것이 바람직

---

2) 개방-폐쇄 원칙 (OCP)

기능을 확장해야 하면 기존 코드를 뜯어고치는 대신, 새 클래스를 추가해서 확장하는 방식으로 설계해야 한다는 의미입니다.

예시:
새로운 할인 정책 추가 시 기존 DiscountService를 수정하는 대신
DiscountPolicy 인터페이스를 만들고 NewYearDiscount, VIPDiscount 등을 추가

---

3) 리스코프 치환 원칙 (LSP)

부모 클래스를 사용하는 코드가 자식 클래스로 바꿔도 정상 작동해야 한다는 원칙입니다.

예시:
Bird 클래스에 fly()가 있는데, 날지 못하는 Penguin이 Bird를 상속하면? → LSP 위반
→ 인터페이스 분리 필요

---

4) 인터페이스 분리 원칙 (ISP)

"필요 없는 기능까지 억지로 구현하게 하지 마라."
즉, 큰 인터페이스를 여러 개의 작은 인터페이스로 나누라는 원칙입니다.

예시:
Animal 인터페이스 안에 run(), fly(), swim()이 모두 있으면
대부분의 동물은 불필요한 기능을 구현하게 됩니다.
→ Runnable, Flyable, Swimmable로 분리하는 것이 이상적

---

5) 의존 역전 원칙 (DIP)

상위 모듈(비즈니스 로직)이 하위 모듈(구현 세부사항)에 의존하면 변경에 취약해짐.
→ 고수준은 저수준에 의존하지 않고 둘 다 추상화에 의존해야 한다는 원칙입니다.

예시:
PaymentService가 KakaoPay 클래스에 직접 의존하면 다른 결제 수단 추가가 어려움
→ PaymentGateway 인터페이스를 만들고,
KakaoPay, NaverPay, CreditCard 등이 이를 구현하도록 설계

---

💬 한 줄로 정리하면?

SOLID는 코드가 커져도 유지보수하기 쉽게 만드는 객체지향 설계의 기본 철학입니다.

 

 

---

 

미들웨어(Middleware)란?

미들웨어는 이름에서 알 수 있듯이 '중간(Middle)'과 '소프트웨어(Software)'의 합성어입니다. 운영 체제와 애플리케이션 사이에 존재하며, 분산 컴퓨팅 환경에서 여러 컴퓨터나 시스템이 서로 원활하게 연결되고 데이터를 주고받을 수 있도록 도와주는 매개체 역할을 하는 소프트웨어예요. 

쉽게 비유하자면, 서로 다른 언어를 사용하는 두 사람이 대화할 때 통역사나 번역기가 필요한 것과 비슷해요. 각기 다른 기능을 하는 소프트웨어 컴포넌트나 시스템이 복잡한 과정 없이 소통할 수 있도록 중간에서 번역, 변환, 중개 등의 역할을 수행하는 것이죠.

미들웨어의 주요 역할

미들웨어는 단지 연결만 하는 것이 아니라, 시스템의 안정성과 효율성을 높이는 다양한 기능을 제공합니다.

1. 데이터 교환 및 통합: 서로 다른 시스템이나 애플리케이션이 데이터를 쉽게 주고받고 통합할 수 있도록 돕습니다. 
2. 분산 컴퓨팅 지원: 네트워크를 통해 연결된 여러 컴퓨터들 간의 통신을 관리하며, 분산된 환경에서 애플리케이션이 안전하고 효율적으로 작동하도록 지원합니다. 
3. 보안 및 인증: 데이터의 보안을 강화하고, 사용자나 시스템의 접근 권한을 관리하는 역할을 할 수도 있습니다.
4. 트랜잭션 관리: 여러 작업이 하나의 단위로 처리되도록 하여 데이터의 무결성을 유지하는 데 기여합니다.
5. 메시징: 비동기적으로 메시지를 주고받는 기능을 제공하여 시스템 간의 유연한 연동을 가능하게 합니다.
6. 플랫폼 지원: 애플리케이션 개발을 지원하기 위한 관리형 도구 및 리소스 체계를 제공합니다. 런타임 환경, 웹 서버, 콘텐츠 관리 시스템(CMS), 컨테이너 등이 그 예시가 될 수 있습니다. 

미들웨어의 예시

일상에서 흔히 접하는 웹 서비스에도 미들웨어가 많이 활용되고 있어요.

• 데이터베이스 미들웨어: 데이터베이스와 애플리케이션 사이에서 데이터를 주고받는 역할을 합니다. (예: JDBC, ODBC)
• 웹 미들웨어(WAS - Web Application Server): 웹 서버와 웹 애플리케이션 사이에서 동적인 콘텐츠를 처리하고 데이터베이스 연동 등을 담당합니다. (예: Apache Tomcat, Nginx, Node.js의 Express.js 같은 프레임워크도 넓은 의미에서 미들웨어 역할을 합니다.)
• 메시지 지향 미들웨어 (MOM - Message-Oriented Middleware): 시스템 간의 비동기 메시지 통신을 담당합니다. (예: Apache Kafka, RabbitMQ)

---

스토어에서 게이트웨이로 연결할건데 유레카랑 디스커버리 중에 어디로 연결해야 좋아?

 

✅ 결론: 스토어는 디스커버리 서버(Eureka Server) 에 등록하고

✅ 게이트웨이는 디스커버리(Eureka) 를 통해 스토어를 찾는다.

즉 연결 대상은 유레카(Eureka Server) 야.

---

🔎 왜 Eureka = Discovery Server 인가?

• “유레카(Eureka)”는 넷플릭스에서 만든 서비스 디스커버리 서버의 이름이야.
• “디스커버리”는 개념이고, Eureka는 그것의 구현체야.

따라서 “유레카와 디스커버리 중에 어디에 연결하냐?”는 질문은
사실상 유레카 서버에 등록하는 것이 맞다는 의미가 돼.

 

대상해야 하는 일

Store 서비스	Eureka(=Discovery Server)에 “등록”
Gateway	Eureka에서 Store 서비스 주소 “조회” 후 라우팅

👉 그래서 스토어는 유레카에 연결해야 한다.
👉 “디스커버리”는 개념적 이름이고, 실제 구현체가 Eureka.

 

스토어(Store) 서비스에서 게이트웨이(Gateway)로 직접 호출할 건지 고민 중이라면, 결론부터 말하면 거의 대부분의 경우 Eureka(또는 다른 서비스 디스커버리)로 등록된 서비스 이름을 통해 Gateway로 호출하는 게 훨씬 더 좋습니다. 직접 IP나 호스트명으로 Gateway를 하드코딩하는 건 절대 비추천이에요.

왜 Eureka(서비스 디스커버리)를 통해 Gateway를 호출해야 할까?

 

항목Gateway 직접 호출 (직접 URL)Eureka + Ribbon/Feign (서비스 이름으로 호출)

 

고가용성 (HA)	Gateway가 여러 대 띄워져도 하나의 주소만 알면 장애 시 수동 변경 필요	자동으로 살아있는 Gateway 인스턴스로 라우팅
배포/스케일링 편의성	Gateway 재배포 시 IP 변경 → Store도 재배포 필요	Gateway가 1대든 10대든 Store 코드는 그대로
MSA 표준 방식	anti-pattern	Spring Cloud 표준 방식 (Service Discovery + Client-side LB)
Circuit Breaker 연계	어렵거나 별도 구현 필요	Hystrix/Resilience4j와 자연스럽게 연계 가능
관제/모니터링	각각의 호출을 별도로 추적해야 함	서비스 이름 단위로 통합 모니터링 (Zipkin, Sleuth 등)