[CS 공부] 디자인 패턴과 프로그래밍 패러다임

백엔드 취준생·2026년 1월 21일

CS공부

목록 보기
14/14

0. 라이브러리와 프레임 워크

공통점

  • 공통으로 사용될 수 있는 특정한 기능들을 모듈화

차이점

  • 네이밍 규칙의 차이, 사용자의 자율성 차이

디자인 패턴

프로그램을 설계할 때 발생할 수 있는 문제점들을 객체 간의 상호 관계들을 이용하여 해결할 수 있도록 하나의 규약 형태

1 싱글톤 패턴

하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴

예시

  • DB연결 모듈
  • new Object

장점

  • 인스턴스 생성 비용 감소

단점

  • 의존성 높아짐
  • TDD 걸림돌 → 독립적인 인스턴스 수행 어렵
  • 모듈간의 결합 강해짐 → 의존성 주입 필요 Why? 결합 느슨하게 할 필요가 있음

1) 의존성 주입

의존성 주입자가 간접적인 의존성을 주입하는 방식 → 디커플링

ex) 헥사고날 아키텍처

장점

  • 쉽게 교체할 수 있음
  • 테스팅 쉬워짐
  • 마이그레이션 수월

단점

  • 클래스 늘어남 → 복잡성 증가

의존성 주입 원칙

상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않아야 합니다.

2. 팩토리 패턴

상위 클래스가 중요한 뼈대를 결정하고 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴

예시

  • Enum, Map을 통해 쉽게 구현 가능 + 팩토리 패턴은 객체 생성 패턴입니다.
  • 결론적으로는 직접 만드는 경우보다는 스프링 부트에서 자동으로 해주는 경우가 더 많습니다.

장점

  • 느슨한 결합 → 상위 클래스와 하위 클래스가 분리되어 있음
  • 많은 유연성 → 상위 클래스에서는 인스턴스 생성 방식에 대해 전혀 알 필요가 없음
  • 유지 보수성 증가 → 객체 생성 로직이 따로 떼어져 있기 때문에 코드 리팩토링할 때 한 곳만 수정 가능

3. 전략 패턴

객체의 행위를 바꾸고 싶은 경우 직접 수정하지 않고 캡슐화한 알고리즘을 컨텍스트 안에서 상호 교체가 가능하게 만드는 패턴

예시

  • 결제 로직, 로그인 로직 , 파일 업로드 로직 등 → 비즈니스 로직에서 변경 가능한 예시들

1) passport의 전략 패턴

전략 패턴을 활용한 라이브러리, node.js의 인증 모듈을 구현할 때 쓰는 미들웨어 라이브러리

  • LocalStrategy 전략 → 서비스 내 회원가입된 아이디와 비밀번호를 기반으로 인증하는 방식
  • OAuth 전략 → 페이스북, 네이버 등 다른 서비스 기반 인증

4. 옵저버 패턴

주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메소드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 패턴

→ 주체? 객체의 상태 변화 관찰자, 옵저버들? 객체의 상태 변화에 따른 추가 변화 사항이 생기는 객체들

예시

  • 팔로우/팔로워 기능
  • 이벤트 기반 시스템에 사용
  • MVC 패턴 → model 변경 사항 뷰에 알려주고 컨트롤러에서 작동

1) 상속과 구현

상속(extends) → 일반 클래스 or 추상 클래스

  • 자식 클래스에서 추가 및 확장을 할 수 있는 것
  • 재사용성, 중복성의 최소화가 이루어짐

구현(implements) → 인터페이스

  • 부모 인터페이스를 자식 클래스에서 재정의하여 구현
  • 메소드를 재정의하여 구현해야 함

2) 프록시 객체

어떠한 대상의 기본적인 동작의 작업을 가로챌 수 있는 객체

  • 타겟: 프록시할 대상
  • 핸들러: 프록시 객체의 타겟 동작을 가로채서 정의할 동작들이 정해져 있는 함수

속성에 대한 접근을 가로채서 변환하는 객체

5. 프록시 패턴

대상 객체에 접근하기 전 그 접근에 대한 흐름을 가로채 대상 객체 앞단의 인터페이스 역할을 하는 패턴

장점

  • 객체의 속성, 변환 등을 보완

예시

  • 보안, 데이터 검증, 캐싱, 로깅에 사용
  • 프록시 서버에 활용

1) 프록시 서버

클라이언트에서 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램

1-1) nginx

  • 비동기 이벤트 기반 구종와 다수의 연결을 효과적으로 처리 가능한 웹서버
  • node.js 서버 앞단의 프록시 서버로 활용
  • node.js 버퍼 오버 플로우 취약점을 예방하기 위해 nginx 사용하는 게 좋다

장점

  • 보안성 강화 → 익명 사용자의 직접적인 서버로의 접근 차단
  • nginx 프록시 서버는 실제 포트 숨길 수 있음
  • gzip 압축하거나 메인 서버 앞단에서의 로깅 할 수 있다.

1-2) CloudFlare

분산된 서버에서 시스템의 콘텐츠 전달을 빠르게 할 수 있는 CDN 서비스

장점

  • 디도스 공격 방어 → 시스템을 통해 오는 트래픽을 자동으로 차단 → 방화벽 대시보드 제공
  • HTTPS 구축 → 별도의 인증서 설치 없이 구축 가능

1-3) CORS

서버가 웹 브라우저에서 리소스를 로드할 때 다른 오리진을 통해 로드하지 못하게 하는 HTTP 헤더 기반 매커니즘

  • 프록시 서버를 둬서 프론트엔드 서버에서 요청되는 오리진을 127.0.0.1:3000으로 바꾼다.
  • 127.0.0.1 → 루프백 IP(본인 IP)

6. 이터레이터 패턴

iterator를 사용하여 collection의 요소들에 접근하는 패턴

  • 자바 스크립트에서는 다른 자료 구조인 set, map임에도 똑같은 for a of b라는 이터레이터 프로토콜을 순회할 수 있음

이터레이터 프로토콜 → 이터러블한 객체들을 순회할 때 쓰이는 규칙

이터러블한 객체 → 반복 가능한 객체로 배열을 일반화한 객체

7. 노출모듈 패턴

  • public: 클래스에 정의된 함수에서 접근 가능하며 자식 클래스와 외부 클래스에서 접근 가능한 범위
  • protected: 클래스에 정의된 함수에서 접근 가능, 자식 클래스에서 접근 가능하지만, 외부는 접근 불가능
  • private: 클래스에 정의된 함수에서 접근 가능, 자식, 외부 접근 불가능
  • 즉시 실행 함수: 함수를 정의하자마자 바로 호출, 초기화 코드, 라이브러리 내 전역 변수의 충돌 방지 등에 사용

8. MVC패턴

모델, 뷰, 컨트롤러로 이루어진 패턴

  • 예시로 리액트가 있음

장점

  • 각자의 구성 요소에만 집중해서 개발 가능
  • 재사용성과 확장성이 용이

단점

  • 복잡성 증가할수록 모델과 뷰의 관계가 복잡해짐

모델

  • 데이터 → 데이터베이스, 상수, 변수
  • 뷰에서 데이터 생성, 수정 시 컨트롤러를 통해 모델을 생성하거나 갱신해야 함

  • 사용자 인터페이스 요소 → 모델을 기반으로 사용자가 볼 수 있는 화면
  • 따로 데이터를 저장하지 않아야 함
  • 변경사항은 컨트롤러에 전달해야 함

컨트롤러

  • 모델과 뷰를 잇는 다리 역할, 이벤트 등 메인 로직 담당
  • 모델과 뷰 생명 주기 관리
  • 모델이나 뷰의 변경 통지를 해석하여 구성 요소에 해당 내용 알림

9. MVP패턴

컨트롤러가 프로젠터로 교체된 패턴

  • 더 강한 결합 → 뷰와 프로젠터는 일대일 관계

10. MVVM 패턴

컨트롤러가 뷰모델로 바뀐 패턴

  • 커멘드와 데이터 바인딩을 가짐
  • 뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원
  • UI 별도의 코드 수정 없이 재사용 살 수 있음
  • 단위 테스팅하기 쉬움
  • 예시로 Vue.js가 있음

프로그래밍 패러다임

프로그래머에게 프로그래밍의 관점을 갖게 해주는 역할을 하는 개발 방법론

1. 객체지향 프로그래밍

객체들의 집합으로 프로그램의 상호 작용을 표현하며 데이터를 객체로 취급하여 객체 내부에 선언된 메소드를 활용하는 방식

특징

  • 추상화: 복잡한 시스템으로부터 핵심적인 개념 또는 기능을 간추려내는 것
  • 캡슐화: 객체의 속성과 메소드를 하나로 묶고 일부를 외부에 감추어 은닉하는 것
  • 상속성: 상위 클래스의 특성을 하위 클래스가 이어받아서 재사용하거나 추가, 확장하는 것 → 코드 재사용, 계측적인 관계 생성, 유지 보수라는 장점이 있음
  • 다형성: 하나의 메소드나 클래스가 다양한 방법으로 동작하는 것 → 오버로딩, 오버라이딩이 있음

오버로딩

  • 같은 이름을 가진 메소드를 여러개 두는 것
  • 메소드의 타입, 매개변수의 유형, 개수 등으로 여러개를 둘 수 있음
  • 컴파일 중에 발생하는 정적 다형성

오버라이딩

  • 상위 클래스로부터 상속받은 메소드를 하위 클래스가 재정의하는 것
  • 런타임 중에 발생하는 동적 다형성

객체지향 설계 원칙

  • 단일 책임 원칙(SRP): 모든 클래스는 각각 하나의 책임만 가져야 한다.
  • 개방-폐쇄 원칙(OCP): 유지 보수 사항이 생긴다면 코드를 쉽게 확장할 수 있도록 하고 수정할 때는 닫혀 있어야 하는 원칙 → 기존 코드를 변경하지 않으면서도 확장은 쉽게 할 수 있어야 한다.
  • 리스코프 치환 원칙(LSP): 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
  • 인터페이스 분리 원칙(ISP): 하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스를 만들어야 하는 원칙
  • 의존 역전 원칙(DIP): 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 원칙 → 상위 계층은 하위 계층의 변화에 대한 구현으로 부터 독립해야 함

절차형 프로그래밍

수행되어야 할 연속적인 계산 과정으로 이루어진 프로그래밍

장점

  • 코드의 가독성이 좋으며 실행 속도가 빠름 → 계산이 많은 작업에 쓰임

→ 포트란을 이용한 대기 과학 관련 연산 작업, 머신 러닝의 배치 작업이 해당 됨

단점

  • 모듈화하기가 어렵고 유지 보수성이 떨어짐

참고자료

면접을 위한 CS 전공 지식 노트

profile
코딩하는 대학생

0개의 댓글