1. 디자인 패턴

디자인 패턴이란 ?

프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 '규약' 형태로 만들어 놓은 것

1.1.1. 싱글톤 패턴 (singleton pattern)

하나의 클래스를 기반으로 단 하나의 인스턴스를 만들어 이를 기반으로 로직을 만든느 데 쓰이며, 보통 데이터베이스 연결 모듈에 많이 사용.

싱글톤 패턴의 장점

: 사용하기 쉽고 굉장히 실용적.

싱글톤 패턴의 단점

1. 테스트주도개발 (TTD(Test Driven Development)) 진행할 때 걸림돌이 됨. 단위 테스트는 서로 독립적이어야 하며 언떤 수서로든 실행할 수 있어야 하나, 싱글톤 패턴은 미리 생성된 하나의 인스턴스를 기반으로 구현하는 패턴으로 각 테스트마다 독립적인 인스턴스 생성이 어려움.

2. 모듈 간의 결합을 강하게 만들 수 있음. 이때 의존성 주입을 통해 모듈간의 결합을 느슨하게 만들어 해결 가능.

의존성 주입 (DI. Dependency Injection)

메인 모듈이 직접 다른 하위 모듈에 대한 의존성을 주기보다는, 중간에서 의존성 주입자(dependency injector)가 이 부분을 가로채, 메인 모듈이 간접적으로 의존성을 주입하는 방식

의존성 주입의 장점

1. 모듈들을 쉽게 교체할 수 있는 구조로 테승하기 쉽고 마이그레이션도 수월.
   ("마이그레이션"이란 ? 데이터나 소프트웨어를 한 시스템에서 다른 시스템으로 이동하는 것. ex. app/os 업그레이드)
2. 애플리케이션 의존성 방향 일관됨
3. 애플리케이션 추론이 쉬움
4. 모듈 간 관계들이 더욱 명확해짐

의존성 주입의 단점

1. 클래스(객체) 수가 늘어나 복잡성이 증가될 수 있음
2. 런타임 페널티 생길 수 있음

의존성 주입 원칙

상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않아야 하며, 둘 다 추상화에 의존해야 함. 이때 추상화는 세부 사항에 의존하지 말아야 함.

1.1.2 팩토리 패턴 (factory pattern)

객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴.
상속 관계의 두 클래스에서 상위 클래스가 중요한 뼈대를 결정, 하위 클래스는 객체 생성에 관한 구체적인 내용을 결정하는 패턴

팩토리 패턴의 장점

1. 두 클래스가 느슨한 결합을 가지며 상위 클래스에서는 인스턴스 생성 방식에 대해 전혀 알 필요가 없어 유연성 증가
2. 코드 리팩터링하더라도 한곳만 수정하면 되기에 유지 보수성 증가

예시 ?

new Object()
: 숫자를 전달하거나 문자열을 전달함에 따라 다른 타입의 객체를 생성하는 것. 즉, 전달받은 값에 따라 다른 객체를 생성하며 인스턴스의 타입 등을 정함.

1.1.3 전략 패턴 (strategy pattern)

정책 패턴(policy pattern)이라고도 하며, 객체의 행위를 바꾸고 싶은 경우 직접 수정하지 않고 전략이라고 부르는 '캡슐화한 알고리즘'을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 하는 패턴

ex) 웹 결제 시 어떤 아이템을 살때 LUNACard와 KAKAOCard로 사는 것을 구현. 결제 방식의 '전략'만 바꿔서 두 가지 방식으로 결제.

passport 전략 패턴

passport란 Node.js에서 인증 모듈을 구현할 때 쓰는 미들웨어 라이브러리. 여러 가지 '전략'을 기반으로 인증 가능. LocalStoragy 전략과 OAuth 전략 등을 지원. '전략'만 바꿔서 이증하는 것.

1.1.4 옵저버 패턴 (observer pattern)

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

• 주체 : 객체의 상태 변화를 보고 있는 관찰자
• 옵저버들 : 상태 변화에 따라 전달되는 메서드 등을 기반으로 추가 변화 사항이 생기는 객체들

** 주체와 객체를 따로 두지 않고 상태가 변경되는 객체를 기반으로 구축하기도 함. → 주체와 객체가 같을 수도, 따로일 수 있도 있음 [두 가지 경우]

ex) 트위터

주로, 이벤트 기반 시스템에 사용, MVC(Model-View-Controller) 패턴에도 사용.

프록시 객체를 통한 옵저버 패턴 구현

프록시 객체

어떠한 대상의 기본적인 동작(속성 접근, 할당, 순회, 열거, 함수 호출 등)의 작업을 가로챌 수 있는 객체.

js에서 프록시 객체는 두개의 매개변수를 가짐.

• target: 프록시할 대상
• handler: target 동작을 가로채고 어떠한 동작을 할 것인지가 설정되어 있는 함수

const handler = {
	get: function(target, name) {
		return name === 'name' ? `${target.a} ${target.b}` : target[name]
	}
}
const p = new Proxy({a: 'KUNDOL', b: 'IS AUMUMU ZAGNIN'}, handler)
console.log(p.name) // KUNDOL IS AUMUMU ZANGIN

위와 같이 a, b 속성을 가지고 있는 객체와 handler 함수를 배개변수로 넣고 p라는 변수를 선언. name 속성 등 특정 속성에 접근할 때 그 부분을 가로채서 어떠한 로직을 강제할 수 있는것이 프록시 객체

1.1.5 프록시 패턴과 프록시 서버

프록시 패턴 (proxy pattern)

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

프록시 패턴의 장점

1. 객체 속성, 변환 등을 보완
2. 보안, 데이터 검증, 캐싱, 로깅에 사용

프록시 서버 (proxy server)

서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램

프록시 서버로 쓰는 nginx

nginx ? 비동기 이벤트 기반의 구조와 다수의 연결을 효과적으로 처리가능한 웹서버. 주로 Node.js 서버 앞단의 프록시 서버로 활용.
→ 익명 사용자가 직접적으로 서버에 접근하는 것을 차단, 간접적으로 한 단계 더 거치게 만들어 보안 강화.

장점 ? 실제 포트 숨김 가능, 메인 서버 앞단에서의 로깅 가능.

CloudFlare

웹 서버 앞단에 프록시 서버로 두어 디도스 공격 방어나 https 구축에 쓰임. 의심스러운 트래픽이 많아지면 CAPTCHA 등을 기반으로 일정 부분 막아주는 역할 수행.

1. 디도스 공격 방어
   : 사용자가 접속하는 것이 아닌 시스템을 통해 오는 트래픽을 자동으로 차단하여 보호
2. HTTPS 구축
   : 서버에서 HTTPS 구축 시 인증서 기반으로 구축. 하지만 cloudFlare를 이용하면 별도의 인증서 절차 없이 손쉽게 구축 가능.

CORS와 프론트엔드의 프록시 서버

CORS (Cross-Origin-Resource Sharing)

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

주로 프론트엔드 서버를 만들어 백엔드 서버와 통신할 때 해당 에러 발생 많음. 이때 프록시 서버로 해결. → 프론트엔드와 백엔드 서버 포트 번호가 다르기 때문인데, 이때 프로시 서버를 둬서 프론트엔드 서버에서 요청되는 오리진을 127.0.0.1:12010 으로 바꿈.

1.1.6 이터레이터 패턴 (iterator pattern)

이터레이터를 사용해 컬렉션의 요소들에 접근하는 디자인 패턴.
여러 가지 자료형 구조와 상관없이 이터레이터라는 하나의 인터페이스로 순회 가능.

1.1.7 노출모듈 패턴 (revealing module pattern)

즉시 실행 함수 통해 private, public 같은 접근 제어자를 만드는 패턴

1.1.8 MVC 패턴

모델, 뷰, 컨트롤러로 이루어진 디자인 패턴. 세 가지 역할로 구분되어 각 구성 요소에만 집중하여 개발 가능.

MVC 패턴 장점

: 재사용성 & 확장성 용이

MVC 패턴 단점

: 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해짐

모델

애플리케이션의 데이터인 데이터베이스, 상수, 변수 의미
ex. 박스 위치 정보, 글자 내용, 글자 위치, 글자 포맷에 관한 정보를 모두 가지고 있어야함.
뷰에서 데이터를 생성하거나 수정 시 컨트롤러를 통해 모델을 생성, 갱신.

뷰

inputbox, checkbox, textarea 등 사용자 인터페이스 요소.
모델이 가지고 있는 정보를 딸 ㅗ저장하지 않아 화면에 표시하는 정보만 가지고 있어야 함.

컨트롤러

하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할. 이벤트 등 메인 로직 담당.
모델, 뷰의 생명주기 관리 및 이들이 변경 통지를 받으면 해석하여 각 구성 요소에 해당 내용 전달.

1.1.10 MVVVM 패턴

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

뷰모델은 뷰를 더 추상화한 계층으로, MVC 패턴과 다르게 커맨드와 데이터 바인딩을 가지는 것이 특징. 뷰와 뷰모델 간 양방향 데이터 바인딩 지원. UI 별도 코드 수정 없이 재사용 가능. 단위 테스팅 쉽다는 장점 있음.

2. 프로그래밍 패러다임

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

함수형 프로그램ㅇ은 상태 값을 지니지 않는 함수 값들의 연속으로 생각할 수 있게 해줌.

프로그래밍 패러다임 ? "선언형" vs "명령형"

• 선언형 → 함수형
• 명령형 → 객체지향형 & 절차지향형

1.2.1 선언형과 함수형 프로그래밍

선언형 프로그래밍 (declarative programming)?

"무엇을" 풀어내는가에 집중하는 패러다임. "프고르갬은 함수로 이뤄진 것"이라는 명제가 담긴 패러다임.

함수형 프로그래밍

'순수 함수'들을 블록처럼 쌓아 로직 구현, 고차함수를 통해 재사용성 높인 프로그래밍 패러다임

( "고차함수"란 ? 함수가 함수를 값처럼 매개변수로 받아 로직을 생성할 수 있는 것)

1.2.2 객체지향 프로그래밍

객체들의 집합으로 프로그램의 상호 작용을 표현하며 데이터를 객체로 취급하여 객체 내부에 선언된 메서드를 활용하는 방식
많은 설계 시간이 필요하지만 처리 속도가 느린 편.

특징

1. 추상화 : 복잡한 시스템으로부터 핵심적인 개념 또는 기능을 간추려내는 것
2. 캡슐화 : 객체의 속성과 메서드를 하나로 묶고 일부를 외부에 감추어 은닉하는 것
3. 상속성 : 상위 클래스의 특성을 하위 클래스가 이어받아서 재사용하거나 추가, 확장하는 것. 코드의 재사용 측면, 계층적 관계 생성, 유지 보슈성 측면에서 중요
4. 다향성 : 하나의 메서드나 클래스가 다양한 방법으로 동작하는 것

오버로딩 & 오버라이딩

• 오버로딩 ? 같은 이름을 가진 메서드를 여러개 두는 것
• 오바링딩 ? 주로 메서드 오버라이딩을 의미하며 상위 클래스로부터 상속받은 메서드를 하위 클래스가 재정의 하는 것

설계 원칙

객체지향 프로그래밍 설계시 SOLID 원칙을 지켜야함

• S : 단일 책임 원칙
• O : 개방-폐쇄 원칙
• L : 리스코프 치환 원칙
• I : 인터페이스 분리 원칙
• D : 의존역전 원칙

1.2.3 절차형 프로그래밍

로직이 수행되야 할 연속적인 계산 과정으로 이루어져, 일이 진행되는 방식으로 코드 구현만 하면 되어 코드 가독성이 좋고 실행 속도가 빠름.

1.2.4 패러다임 혼합

비즈니스 로직이나 서비스의 특징을 고려하여 패러다임을 정해야함. 여러 패러다임을 조합하여 상황과 맥략에 따른 패러다임 장점을 취해 개발하는 것이 최적화 방법!

2. 네트워크

컴포튜 등의 장치들이 통신 기술을 이용해 구축하는 연결망

2.1 네트워크의 기초

네트워크 ? 노드와 링크가 서로 연결돼 리소스를 공유하는 집합을 의미

• 노드 ? 서버, 라우터, 스위치 등 네트워크 장치
• 링크 ? 유선 또는 무선

2.1.1 처리량과 지연 시간

좋은 네트워크란 ? 많은 처리량을 처리할 수 있으며 지연 시간이 짧고 장애 빈도가 적으며 좋은 보안을 갖춘 네트워크!

처리량

성공적으로 전달된 데이터의 양을 의미

단위로는 bps(bits per second) 사용. 초당 전송 혹은 수신되는 비트 수.
처리량은 사용자가 많이 접속할 때마다 커지는 트래픽, 네트워크 장치 간 대역폭, 네트워크 중간에 발생하는 에러, 장치의 하드웨어 스펙에 영향 받음.

지연시간

요청이 처리되는 시간. 어떤 메세지가 두 장치 사이를 왕복하는 데 걸린 시간.
매체 타임(유선/무선), 패킷 크기, 라우터의 패킷 처리 시간에 영향 받음.

2.1.2 네트워크 토폴리지와병목 현상

네트워크 토폴리지

노드와 링크가 어떻게 배치되어 있는지에 대한 방식 혹은 연결 형태 의미

1. 트리 토폴로지 : 계층형 토폴리지로 트리 형태

   • 장점 ? 노드 추가, 삭제가 쉬움
   • 단점 ? 트래픽 집숭 시 하위 노드에 영향을 미침

2. 버스 토폴로지 : 중앙 통신 회선 하나에 여러 갱의 노드가 연결되어 공유하는 구성, 근거리 통신망에 사용

   • 장점 ? 설치 비용이 적고 신뢰성이 우수, 통신 회선에 노드 추가/삭제가 쉬움
   • 단점 ? 스푸핑 가능. ("스프핑"이란 ? LAN 상에서 송신부의 패킷을 송신과 관련없는 다른 호스트에 가지 않도록 하는 스위칭 기능을 마비시키거나 속여서 특정 노드에 해당 패킷이 도록 처리하는 것)

3. 스타 토폴로지 : 중앙에 있는 노드에 모두 연결된 네트워크 구성

   • 장점 ? 노드 추가 및 에러 탐지 쉼움. 패킷의 충돌 발생 가능성 적음. 어떠한 에러든 쉽게 발견 가능, 장애 노드가 중앙이 아닌 다른 노드에 영향 끼치는 확률이 낮음.
   • 단점 ? 중앙 노드에 장애 발생시 전체 네트워크 사용 불가, 설치 비용 고가

4. 링형 토폴리지 : 각각의 노드가 양 옆의 두 노드와 연결하여 전체적으로 고리처럼 하나의 연속된 길을 통해 통신을 하는 망 구성 방식

   • 장점 ? 노드 수 증가해도 네트웤상 손실이 거의 없고 , 충돌이 발생되는 간으성이 적고 노드 고상 발견이 쉬움.
   • 단점 ? 네트워크 구성 변경이 어렵고 회선에 장애가 생기면 전체 네트워크에 영향 미침

5. 메시 토폴로지 : 망형 토폴로지, 그물망처럼 연될어 있는 구조

   • 장점 ? 한 단말 장치에 장애 발생 시 여러 갱의 경로가 존재해 트래픽 분산 처리 가능
   • 단점 ? 노드의 추가가 어렵고 구축&운영 비용이 비쌈

토폴로지가 중요한 이유 ?

병목 현상 발생시 원인을 빠르게 찾을 수 있음. 관리자는 네트워크 토폴로지의 생김새를 파악하여 병목 현상 해결 가능.

2.1.3 네트워크 분류

규모를 통해 분류 가능!

1. LAN (Local Area Network)
   사무실과 개인적인 소유 가능한 규모. 근거리 통신망을 의미. 전송 속도가 빠르고 혼잡하지 않음.

2. MAN (Metropolitan Area Network)
   서울시 정도의 대도시 지역 네트워크. 넓은 지역에서 운영되며 속도는 평균, LAN보다는 더 많이 혼잡.

3. WAN (Wide Area Network)
   광역 네트워크이며 국가 혹은 대륙 규모에서 운영. 전송 속도 낮으며, MAN보다 더욱 혼잡.

출처 : 면접을 위한 cs 전공지식 노트 (주홍철 지음, 출판사 길벗)