CS 면접 바이블: Chapter 1 (4)

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

• 프록시 객체: 프록시 패턴이 적용된 객체

프록시 패턴

• 그림

• 대상 객체에 접근하기 전에 접근 흐름을 가로채는 중간 계층

• 요청을 필터링하거나 수정하여 대상 객체에 대한 접근 제어

• 객체의 기능을 보완하면서 보안성 강화

• 데이터 검증, 캐싱, 로깅 등에 활용

• 객체뿐만 아니라 프록시 서버에도 적용

프록시 서버에서의 캐싱

자주 사용하는 데이터를 캐시에 저장한 뒤, 동일한 요청이 들어오면 원격 서버에 다시 요청하지 않고 캐시의 데이터를 반환하는 방식

• 원격 서버 요청 횟수 감소
• 네트워크 트래픽 감소
• 응답 속도 향상

---

프록시 서버

• 클라이언트와 서버 사이에 위치하는 중간 서버
• 클라이언트가 프록시 서버를 통해 다른 네트워크 서비스에 간접적으로 접근하도록 중계

프록시 서버로 쓰는 nginx

• 비동기 이벤트 기반 구조의 웹 서버
• 적은 자원으로 다수의 연결을 효과적으로 처리
• 주로 Node.js 서버 앞단의 프록시 서버로 활용

"Node.js의 버퍼 오버플로우 취약점을 예방하기 위해서는 nginx를 프록시 서버로 앞단에 놓고 Node.js를 뒤쪽에 놓는 것이 좋다."
— Ryan Dahl

nginx를 앞단에 두었을 때의 장점

• 외부 사용자의 실제 서버 직접 접근 차단
• 중간 계층을 통한 보안 강화
• 실제 서버의 IP 및 포트 은닉
• 정적 자원의 gzip 압축
• 메인 서버 앞단에서 요청 로깅 가능

버퍼 오버플로우

버퍼의 크기를 초과하는 데이터가 입력되어 할당된 메모리 영역을 넘어 다른 영역까지 침범하는 현상

이 과정에서 다른 메모리의 주소나 값이 변경되어 보안 취약점으로 이어질 수 있음.

gzip 압축

DEFLATE 알고리즘을 기반으로 데이터를 압축하는 방식

• 데이터 전송량 감소
• 네트워크 사용량 감소
• 단, 압축·해제 과정에서 CPU 연산 비용 발생

따라서 전송량 감소 효과와 CPU 오버헤드를 고려하여 적용 필요

---

프록시 서버로 쓰는 Cloudflare

• 웹 서버 앞단에 위치하는 프록시 서버
• 사용자 요청을 먼저 Cloudflare가 받은 뒤 실제 웹 서버로 전달
• 외부 사용자가 실제 웹 서버에 직접 접근하는 것을 줄여 보안 강화
• 주로 DDoS 공격 방어, HTTPS 구축, 캐싱/CDN 등에 활용

DDoS 공격 방어

• DDoS는 짧은 시간 동안 서버에 대량의 요청을 보내 서비스를 마비시키는 공격
• Cloudflare가 실제 서버 앞단에서 트래픽을 먼저 검사
• 정상 사용자가 아닌 것으로 판단되는 의심스러운 트래픽을 자동 차단
• 필요에 따라 CAPTCHA 등의 검증을 통해 정상 사용자 여부 확인
• 공격 트래픽이 실제 서버까지 도달하는 것을 줄여 서버 부하 및 불필요한 클라우드 비용 감소
• Cloudflare의 대규모 네트워크와 캐싱을 활용하여 DDoS 공격 대응

사용자 ───────→ Cloudflare ───────→ 웹 서버
크롤러 ──────→     ↓
공격자 ──────→  트래픽 검사
                  ↓
             의심 트래픽 차단

HTTPS 구축

• HTTPS 사용을 위해서는 일반적으로 SSL/TLS 인증서가 필요
• Cloudflare를 프록시 서버로 사용하면 Cloudflare를 통해 HTTPS 연결 구성 가능
• 사용자와 Cloudflare 사이의 통신을 암호화하여 데이터 전송 보안 강화

CDN

• CDN(Content Delivery Network): 여러 지역의 서버에 콘텐츠를 캐싱하고 사용자와 가까운 서버에서 콘텐츠를 제공하는 네트워크
• Cloudflare가 이미지, CSS, JavaScript 등의 정적 콘텐츠를 캐싱
• 매 요청마다 원본 서버에 접근할 필요 감소
• 원본 서버의 트래픽 및 부하 감소
• 사용자와 가까운 서버에서 콘텐츠를 제공하여 응답 속도 향상

핵심적으로는 사용자 → 실제 서버로 바로 접근하는 구조에서
사용자 → Cloudflare → 실제 서버 구조로 변경하여 Cloudflare가 보안, 트래픽 제어, 캐싱 등을 대신 처리하는 방식

---

1.1.6 이터레이터 패턴

• 이터레이터(iterator)를 사용하여 컬렉션의 요소에 순차적으로 접근하는 패턴
• 자료구조의 내부 구조와 관계없이 동일한 인터페이스를 통해 순회 가능
• 배열, Map, Set처럼 서로 다른 자료구조도 같은 방식으로 순회 가능

예시 코드

const mp = new Map()
mp.set('a', 1)
mp.set('b', 2)
mp.set('c', 3)

const st = new Set()
st.add(1)
st.add(2)
st.add(3)

for (let a of mp) console.log(a)
for (let a of st) console.log(a)

/*
[ 'a', 1 ]
[ 'b', 2 ]
[ 'c', 3 ]
1
2
3
*/

• Map과 Set은 서로 다른 자료구조
• 하지만 둘 다 이터러블(iterable)하기 때문에 for...of를 이용하여 동일한 방식으로 순회 가능
• 즉, 자료구조의 내부 구현을 알 필요 없이 이터레이터라는 공통된 방식으로 요소에 접근

이터레이터 프로토콜

이터러블 객체의 요소를 어떤 방식으로 순회할 것인지 정의한 규칙

JavaScript에서는 next()를 통해 다음 요소에 접근하며 일반적으로 { value, done } 형태의 결과를 반환

이터러블 객체

반복 가능한 객체

Symbol.iterator 메서드를 가지고 있어 for...of 등으로 순회할 수 있는 객체

ex) Array, Map, Set, String

---

1.1.7 노출모듈 패턴

• 즉시 실행 함수(IIFE)를 이용하여 외부에 공개할 변수와 숨길 변수를 구분하는 패턴
• 모듈 내부의 변수와 함수 중 필요한 것만 외부에 노출
• 정보 은닉과 캡슐화를 구현하는 데 활용

참고: 책의 설명처럼 과거 JavaScript에서는 private, public 접근 제어자를 직접 사용하는 방식이 제한적이었기 때문에 이러한 패턴이 많이 사용되었습니다.
현재 JavaScript 클래스에서는 #privateField와 같은 private class field도 지원합니다.

예시 코드

const pukuba = (() => {
  const a = 1
  const b = () => 2

  const public = {
    c: 2,
    d: () => 3
  }

  return public
})()

console.log(pukuba)
console.log(pukuba.a)

/*
{ c: 2, d: [Function: d] }
undefined
*/

• a, b

  • 외부로 반환되지 않음
  • 외부에서 직접 접근 불가능
  • private 역할

• c, d

  • 객체에 담아 외부로 반환
  • 다른 코드에서 접근 가능
  • public 역할

즉시 실행 함수 내부
│
├─ a, b → 외부에 노출 X → private
│
└─ c, d → return으로 노출 → public

• 노출모듈 패턴과 유사한 방식으로 모듈 내부 구현을 숨기고 필요한 기능만 외부에 공개 가능
• JavaScript의 CommonJS(CJS) 등의 모듈 방식에서도 모듈 외부에 필요한 값만 내보내는 개념 활용

public

클래스나 모듈 외부에서도 접근 가능한 범위

외부에서 자유롭게 변수나 메서드에 접근 가능

protected

클래스 내부와 해당 클래스를 상속받은 하위 클래스에서 접근 가능한 범위

일반적인 JavaScript에는 protected 접근 제어자가 문법적으로 직접 제공되지 않음

private

클래스나 모듈 내부에서만 접근 가능한 범위

외부에서 직접 접근할 수 없도록 데이터를 숨기는 데 사용

즉시 실행 함수(IIFE)

함수를 정의함과 동시에 즉시 실행하는 함수

별도의 함수 호출 없이 바로 실행되며, 함수 내부에 독립적인 스코프를 만들어 외부에서 변수에 직접 접근하지 못하게 할 수 있음.

(() => {
  // 실행할 코드
})()

---

1.1.8 MVC 패턴

• MVC 패턴은 Model, View, Controller로 애플리케이션을 분리하는 디자인 패턴
• 각 구성 요소의 역할을 분리하여 관심사의 분리(Separation of Concerns) 가능
• 각 영역에 집중해서 개발할 수 있어 유지보수, 재사용성, 확장성 향상
• 애플리케이션이 복잡해질수록 모델과 뷰 사이의 관계 및 전체 구조가 복잡해질 수 있음

모델

• 애플리케이션에서 사용하는 데이터와 데이터 처리 로직을 담당
• 데이터베이스의 데이터, 변수, 상수 등의 정보 관리
• 데이터의 상태를 저장하고 변경

예를 들어 화면에 사각형 박스와 글자가 있다면 모델에는 다음과 같은 정보가 포함될 수 있음.

• 사각형의 위치 정보

• 글자 내용

• 글자 위치

• 글자 인코딩 및 형식 등의 데이터

• 사용자가 데이터를 생성하거나 수정하면 컨트롤러를 통해 모델의 데이터가 생성 또는 갱신

뷰

• 사용자에게 보여지는 화면 및 UI 요소를 담당
• input, checkbox, textarea 등 사용자 인터페이스 요소 포함
• 모델의 데이터를 기반으로 사용자에게 화면을 표시
• 모델의 데이터를 직접 저장하기보다는 화면에 표현하는 역할에 집중
• 사용자의 입력이나 이벤트가 발생하면 이를 컨트롤러에 전달

컨트롤러

• 모델과 뷰 사이를 연결하는 역할
• 사용자의 요청과 이벤트 처리
• 요청을 해석하여 적절한 모델을 호출
• 모델의 처리 결과를 기반으로 적절한 뷰 선택
• 모델과 뷰의 흐름 및 생명주기 관리

사용자
  ↓ 요청
Controller
  ↓
Model
  ↓ 처리 결과
Controller
  ↓
View
  ↓
사용자에게 화면 표시

즉,

• Model → 데이터
• View → 화면
• Controller → 요청 처리 및 Model·View 연결

---

MVC 패턴의 예: Spring MVC

• MVC 패턴을 기반으로 웹 애플리케이션을 개발할 수 있도록 지원하는 Spring의 웹 프레임워크
• HTTP 요청 처리, 데이터 전달, 화면 반환 등을 편리하게 구현 가능
• 애너테이션을 이용하여 사용자의 요청 값을 쉽게 전달받을 수 있음

@GetMapping("/users/{id}")
public String getUser(
        @PathVariable Long id,
        @RequestParam String name) {
    ...
}

주요 애너테이션

• @RequestParam

  • 쿼리 파라미터 값 처리

• @RequestHeader

  • HTTP Header 값 처리

• @PathVariable

  • URL 경로에 포함된 값 처리

@PathValue가 아니라 @PathVariable이 정확한 명칭입니다.

Spring MVC의 장점

• 요청 값의 바인딩과 검증을 편리하게 처리

• 잘못된 요청을 쉽게 검증 가능

  • ex) 숫자가 필요한 값에 문자열이 전달된 경우

• Controller, Service 등의 코드를 분리하여 재사용성과 유지보수성 향상

• 단위 테스트 및 통합 테스트 용이

• 리디렉션 및 요청 처리 흐름 구현 용이

핵심

MVC는 애플리케이션을 데이터(Model) / 화면(View) / 제어 로직(Controller)으로 분리하여 각 구성 요소의 역할을 명확하게 만드는 패턴입니다.

---

1.1.9 MVP 패턴

• MVC 패턴에서 파생된 디자인 패턴
• MVC의 Controller가 Presenter로 변경된 구조
• Presenter가 View와 Model 사이에서 데이터를 전달하고 UI 로직을 처리
• View와 Presenter가 1:1 관계를 가지는 경우가 많아 MVC보다 결합도가 높은 편

View ↔ Presenter ↔ Model

• Model → 데이터 및 비즈니스 로직
• View → 사용자에게 보여지는 화면
• Presenter → View의 요청을 받아 Model을 처리하고 결과를 View에 전달

Presenter

View와 Model 사이에서 중간 역할을 하며, 화면에 표시할 데이터와 UI 관련 로직을 처리하는 계층

---

1.1.10 MVVM 패턴

• MVC의 Controller가 ViewModel로 변경된 디자인 패턴
• Model, View, ViewModel로 구성
• Command와 Data Binding을 활용
• View와 ViewModel 사이의 데이터 바인딩을 통해 상태 변화가 UI에 자동 반영
• UI와 비즈니스 로직의 분리가 쉬워 재사용성과 테스트 용이성 향상

View ↔ ViewModel ↔ Model

뷰모델

• View를 추상화하여 View에 필요한 상태와 동작을 관리하는 계층
• Model의 데이터를 View가 사용하기 적합한 형태로 가공
• View가 직접 Model을 다루지 않도록 중간 역할 수행

---

MVVM 패턴의 예: Vue.js

• MVVM과 유사한 구조를 활용하는 대표적인 프런트엔드 프레임워크
• 반응성(Reactivity)을 기반으로 데이터 변경 시 화면을 자동 갱신
• computed, watch 등을 이용하여 반응형 데이터 처리 가능
• 데이터 값을 변경하면 연결된 UI가 자동으로 변경
• 컴포넌트 기반으로 재사용 가능한 UI 구성 가능

const count = ref(0)

count.value++

• count 값이 변경되면 이를 사용하는 화면도 자동으로 갱신
• HTML 템플릿과 데이터를 연결하여 UI 구성 가능

Command

사용자의 클릭, 입력 등 여러 UI 동작을 하나의 실행 가능한 액션으로 추상화하는 방식

View가 직접 로직을 수행하지 않고 ViewModel에 정의된 동작을 실행하도록 구성

Data Binding

화면에 표시되는 데이터와 애플리케이션의 데이터를 연결하는 기법

데이터가 변경되면 View에도 변경 사항이 자동으로 반영됨.

양방향 데이터 바인딩

ViewModel → View뿐만 아니라 View → ViewModel 방향으로도 값이 자동 반영되는 방식

ViewModel 변경 → View 변경
View 변경 → ViewModel 변경

Vue.js에서는 대표적으로 v-model을 통해 양방향 데이터 바인딩을 구현할 수 있음.

핵심 차이

• MVC → Controller가 Model과 View 연결
• MVP → Presenter가 View와 직접 연결되어 UI 로직 처리
• MVVM → ViewModel과 View를 데이터 바인딩으로 연결