[면접 대비] 이것 저것(etc)

김정욱·2021년 5월 30일

DDD MA OOP SOA SOLID TDD cors msa

면접준비

목록 보기

6/6

컴포넌트 & 모듈

컴포넌트

실질적으로 동작되고 있는 개체(단위)

모듈

가장 상위에 위치하는 구현의 단위

실질적으로 구현이 된 단위

기능을 기준하여 분리된 단위

C++ & Java 차이점

(ref : https://m.blog.naver.com/PostView.nhn?blogId=ws6263&logNo=100198938111&proxyReferer=https:%2F%2Fwww.google.co.kr%2F)

설계 목표

C++ : 속도, C와의 하위 호환성에 집중

Java : 보안과 빠른 이식성에 집중

메모리 관리

: C++은 C를 포함하여 하위 포환성을 유지하기 위해 메모리 관리 제어, 포인터, 전처리기 같은 기능을 컨트롤 하게 했다. 하지만, java에서는 이렇게 여러 버그를 일으키는 기능을 없애거나 메모리관리 같은 부분은 GC(Garbage Collection)이 대신 해준다.

C++

Heap / Stack 모두 할당 가능

메모리 해제를 프로그래머가 수동으로 해야함(소멸자 이용)

Java

GC(Garbage Collection)이 자동으로 관리

실행 과정

컴파일 : 개발자가 작성한 소스코드를 기계가 이해할 수 있는 언어로 변환하는 과정

빌드 : 소스코드 파일을 실행 가능한 형태의 산출물로 만드는 일련의 과정(컴파일 + 링크 등등 과정 포함)

C++ --> 각 OS에 맞춰 실행파일이 생성

컴파일러가 오브젝트 코드를 생성한 후, 링커가 필요한 라이브러리를 링크해서 실행 가능한 파일 생성

오브젝트 코드, 실행 파일은 OS에 맞는 기계어로 컴파일 된다

Java --> JVM에서 실행 가능한 파일 생성 --> OS에 독립적

개발자가 자바 소스코드 작성(.java)

자바 컴파일러(javac)가 컴파일 해서, 자바 바이트 코드(.class) 생성

JVM의 클래스 로더(Class Loader)가 링크 등의 과정을 거치고 JVM에 메모리에 올린다

JVM에서 명령어 단위로 가져와서 파일을 실행

다중상속과 연산자 오버로드

C++

다중상속 가능

연산자 오버로딩 가능

Java

다중상속 불가능 --> 인터페이스로 어느정도 대체 가능

연산자 오버로드 불가능

인자 전달 방법의 차이

C++

기본적으로 객체를 값으로 전달 (Call By Value)

Java

기본적으로 객체를 reference로 전달(Call By reference)

OOP(객체지향 프로그래밍) 3요소 5원칙

3요소

캡슐화(Encapsulation) == 정보 은닉

객체의 속성(data fields)과 행위(methods)를 하나의 클래스라는 캡슐에 묶는 것

은닉된 정보로의 접근은 접근지정자(public/protected/private 등)를 통해서만 조작 가능

캡슐화는 원본 데이터를 유지하며 보존, 보호하기 위해 존재

상속(Inheritance) == 재사용 + 확장

상위 클래스의 특성을 하위 클래스에서 물려받는 것을 말하고 하위 클래스에서는 더 필요한 속성을 확장해서 사용할 수 는 것

다형성(Polymorphism) == 사용 편의

하나의 객체가 여러 가지 형태를 가질 수 있는 것을 의미

오버로딩(Overloading)
: 매개변수, 리턴타입을 다르게 해서 같은 이름의 함수를 다양하게 정의하는 것(메서드 중복)

오버라이딩(Overriding)
: 부모로부터 받은 메소드를 자식 객체에서 재정의하는 것(메서드 재정의)

5원칙

5가지 원칙

SRP(Single responsibility Principle)
: 단일 책임 원칙

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

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

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

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

OCP / DIP가 가장 중요!

1. SRP(Single responsibility Principle)

단일 책임 원칙

한 클래스는 하나의 책임만 가져야 한다
('하나의 책임'이라는 것은 모호한 면이 있음
--> 문맥과 상황에 따라 다름)

즉, 핵심은 변경이 있을 때 파급 효과가 적어야 한다는 것!
(UI변경 / 객체의 생성과 사용 분리 등)

2. OCP(Open/Closed Principle)

개방-폐쇄 원칙

S/W 요소는 확장에는 열려있으나 변경에는 닫혀있어야 한다

핵심은 다형성을 활용하는 것

새로운 구현체를 사용한 확장은 열어두면서, 기존 코드의 변경은 닫혀있게 해야 한다

3. LSP(Liskov Substitution Principle)

리스코프 치환 원칙

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 함

자동차 인터페이스에서 액셀은 앞으로 가라는 기능 이라는 정확성을 만족시켜야 우리가 믿고 쓸 수 있음

즉, 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다!

다형성을 지원하기 위한 원칙

인터페이스를 구현한 구현체를 믿고 사용하려면 필요한 원칙

4. ISP(Interface Segregation Principle)

인터페이스 분리 원칙

특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스 하나보다 낫다

자동차 인터페이스 -> 운전 / 정비 인터페이스로 분리!

인터페이스가 명확해지고, 대체 가능성이 높아진다.

5. DIP(Dependency Inversion Principle)

의존관계 역전 원칙

코드가 구현클래스에 의존하지 말고, 인터페이스에 의존해야함

즉, 코드는 역할(Role)에 의존해야 한다!

프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안된다"

추상 메서드 / 추상 클래스 / 인터페이스

추상(abstract) 메서드

선언부만 작성하고 구현부는 작성하지 않은 채로 남겨둔 메서드

abstract 키워드를 메서드에 사용

반드시 오버라이딩해서 자식 클래스에서 구현하도록 하는 목적을 가짐

추상(abstract) 클래스

추상 메서드를 포함한 클래스

new를 통해서 인스턴스화 할 수 없다

인터페이스(interface)

추상 클래스의 일종

추상클래스보다 추상화 정도가 높아서 추상 메서드만 가질 수 있음

따라서 인터페이스를 상속받은 클래스는 반드시 모든 메서드를 구현해야 한다

인터페이스는 다중 상속이 가능하다

작성 규칙

선언시 class 대신 interface 키워드 사용

멤버 변수에는 public static final이 붙음

메서드 앞에는 public abstract가 붙음 (다른 접근지정자 사용 X)

상속(extends) vs 구현(implements)

상속

클래스를 상속, 공통된 부모를 가지는 것끼리 묶음. is-a 관계

클래스에서 클래스의 다중 상속은 불가능, 클래스에서 인터페이스 다중 구현은 가능

구현

인터페이스(interface)를 구현하는 것, can-do 관계

반드시 인터페이스의 모든 메소드를 구현해야 함

인터페이스는 인터페이스의 다중 상속이 가능

TDD(Test-Driven Development)

ref :
https://m.blog.naver.com/suresofttech/221569611618
https://mangkyu.tistory.com/143
https://gmlwjd9405.github.io/2018/06/03/agile-tdd.html

개념

테스트코드를 먼저 작성 한 후 개발에 들어가는 개발 방식

테스트가 개발을 이끌어 나간다

결정과 피드백 사이의 갭을 조절하기 위한 테크닉 (갭이 크면 문제!)

결정 : 코딩을 하면서 생기는 다양한 방법들을 결정하는 것

피드백 : 성공/실패 라는 정확한 결과

일반적으로 TDD를 하면서 작성하는 테스트 코드는 '단위 테스트'

TDD cycle

TDD는 Red, Green, Refactor이라는 하나의 주기를 가지며 테스트 목록을 추가/수정하며 진행된다

Red : 먼저 실패하는 테스트 코드를 작성하고, 실패하도록 만들어 실패 상태(Red)를 확인

Green : 빠른 시간 내에 테스트가 통과하는 프로덕션 코드를 작성

Refactor : 코드의 리팩토링을 통해 Clean up 과정을 수행

필요성(장점)

테스트 코드에는 개발자의 개발 과정(어떤 고민 / 어떤 의사결정)이 나와있다
--> 정해진 결과를 통해 개발의 방향성을 확실하게 가져갈 수 있다

여러 상황에 대한 예외처리를 함께 작성하기 때문에 결함이 줄어든다

객체 지향적인 코드 개발을 하게 된다
--> 테스트의 용이성을 위해 각각의 기능들에 대해 철저히 구조화 시켜서 작성
--> TDD의 목적인 코드의 재사용성을 보장하며 객체지향적으로 작성하게 됨
--> 깨끗한 코드 작성이 가능

TDD를 적용하기 어려운 이유

개발시간 증가

기존 개발의 흐름을 완전히 바꿔야 하기 때문

TDD를 하는 방법에 정확한 정답이 있는 것 처럼 틀이 정해져 있다고 생각된다 (핵심)
--> 너무 도구 / 규칙에 집착하기 때문

단위 테스트 & 통합 테스트

ref : https://mangkyu.tistory.com/143

단위 테스트(Unit Test)

하나의 모듈을 기준으로 독립적으로 진행되는 가장 작은 단위의 테스트

하나의 기능 혹은 메소드 정도로 이해될 수 있음

일반적으로 TDD를 할 때 작성되는 테스트 방식

통합 테스트(Integration Test)

모듈을 통합하는 과정에서 모듈 간 호환성을 확인하기 위해 수행되는 테스트

캐시나 데이터베이스 등 연관된 모든 컴포넌트를 연결해야 한다

실제 애플리케이션을 실행시켜서 테스트가 진행되기 때문에 속도가 느리다

단위 테스트 작성의 필요성

해당 부분만 독립적으로 테스트하기 때문에 어떤 코드를 리팩토링하여 빠르게 문제 여부를 확인할 수 있음

테스팅에 대한 시간과 비용을 절감

새로운 기능 추가시에 수시로 빠르게 테스트 가능

리팩토링 시에 안정성을 확보

단위 테스트의 문제점 & Stub

단위 테스트를 진행하기 위해서도 대부분은 결국 다른 객체들과 메세지를 주고 받아야 한다

임시적으로 테스트에 필요한 Mobk Object(가짜 객체)같은 Stub이 필요함

DDD(도메인 주도 설계)

DDD(Domain-Driven Design)

모두의 프로젝트 이해와 커뮤니케이션 수단의 통일성(도메인)을 만들어 기획자부터 개발자까지 프로젝트 커뮤니케이션 코스트 낭비를 최소화하기 위한 설계방법론

이로인해 프로젝트는 기획에서 설계까지 원하는 방향으로 잘나갈 것을 기대하는 설계 방법론

도메인

소프트웨어로 해결하고자 하는 문제 영역

도메인 모델

특정 도메인을 개념적으로 표현한 것

도메인 모델을 사용하면 여러 관계자들(개발자, 기획자, 사용자)이 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는데 도움이 된다

도메인 모델 패턴

도메인 규칙을 객체 지향 기법으로 구현하는 패턴

비즈니스 로직을 도메인에 직접 작성하는 방식(도메인에 데이터와 프로세스가 같이 존재)

객체간 관계를 맺을 수 있어, 제약하거나 로직의 단순화에 도움

하지만 객체들간의 설계가 수반되어야 하기에 모델 구축이 어려움

DDD(도메인 주도 설계) 아키텍처 구조

Web Layer

흔히 사용하는 컨트롤러와 뷰 템플릿의 영역 (인터셉터 등 외부요청과 응답도 포함)

Service Layer

트랜잭션, 도메인 간 순서 보장을 해주는 역할

일반적으로 컨트롤러와 DAO의 중간 영역에서 사용

Repository Layer

실제 Database와 같은 데이터 저장소에 접근하는 영역

DAO에 해당

Domain Model

개발 대상에 해당하는 '도메인'을, 모든 사람이 동일한 관점에서 이해할 수 있고 공유할 수 있도록 단순화 시킨 것 ( == 도메인 모델)

실제 비즈니스 로직이 수행되는 곳

트랜잭션 스크립트 vs 도메인 모델 패턴

로직 패턴

마틴 파울러라는 사람이 비즈니스 로직을 처리하는 2가지 패턴을 정의함

트랜잭션 스크립트와 도메인 모델 패턴이 그 두 예시

책임지는 쪽이 Domain Level이냐, Script Level이냐에 따라 구분

트랜잭션 스크립트

개념

하나의 트랜잭션으로 구성된 로직을 단일 함수 또는 단일 스크립트에서 처리하는 구조

service 계층 내부에 비즈니스 로직을 모두 작성하는 방식

장점

구현이 쉽다

모듈화를 잘 구현한다면 높은 효율을 낼 수 있다

단점

비즈니스 로직이 복잡해질수록 난잡한 코드가 된다

도메인 모델 패턴에 비해 중복된 코드가 많이 발생

도메인 모델 패턴

개념

객체 지향 분석 설계에 기반해서 구현하고자 하는 도메인의 모델을 생성하는 패턴

도메인 내부에 데이터와 프로세스(비즈니스 로직)가 함께 존재

장점

객체 지향에 기반한 재사용성, 확장성, 유지보수가 좋다

단점

하나의 도메인 모델을 구축하는데 많은 노력이 필요 (구축이 힘듬)

MA vs SOA vs MSA

ref : https://wonit.tistory.com/487

MA(Monolithic Architecture)

개념

하나의 서비스 또는 애플리케이션이 하나의 거대한 아키텍처를 가지는 방식

장점

개발이 비교적 쉽다

쉽게 고가용성 서버 환경을 만들 수 있다(같은 애플리케이션으로 하나 더 만들면 됨)

End-to-End 테스트가 용이 (MSA경우 테스트에 필요한 서비스를 모두 각자 동작시켜야 함)

단점

한 프로젝트의 규모가 너무 커지면, 애플리케이션 구동시간, 빌드, 배포 시간이 너무 길어짐

조그마한 수정사항이 있어도 전체를 다시 빌드하고 배포를 해야 함

많은 양의 코드로 인해 유지보수가 힘들다

일부분의 오류가 전체에 영향을 미친다

SOA(Service Oriented Architecture)

개념

서비스 지향 설계 방식

서비스 단위의 개발을 하여 개발된 서비스를 공유(ESB를 통해)하고 재가용성과 유연성을 확보하는 방식

서비스들의 재사용성 향상이 지향점

장점

서비스 단위로 모듈을 분리하여 결합도가 낮은 아키텍처가 된다

버스 형태에 연결만 가능하다면 확장성과 유연성이 증가된다

단점

결국 하나의 DB(저장소)를 사용해서 근본적인 의존성은 해결되지 못함

비즈니스에서 실 성공 사례가 매우 드물다

MSA(Micro Service Architecture)

개념

마이크로 서비스 설계 방식

작은 단위인 MS(Micro Service)로 분리하여 독립적으로 빌드, 배포가 가능하도록 구성

REST API를 통해 느슨하게 연결되기 때문에 각 서비스는 모두 독립성이 강하다

장점

추가 및 수정사항이 있을때, 마이크로서비스만 빠르게 빌드, 배포가 가능

해당 기능에 효율적인 기술, 언어들을 선택할 수 있음

일부분의 오류가 전체 서비스 자체에 영향을 주지 않게 할 수 있음

단점

서비스가 분산되어 있어서 유지보수가 힘들다

무조건적으로 상호 간 서비스를 호출하는 코드가 추가되어 통신 관련 오류가 더 잦다

전체 테스트가 MA에 비해 불편하다

SOA와 MSA

공통점

응집된 비즈니스 집합을 여러개의 서비스 집합으로 나누어 개발하는 구성
(MSA에서 나누는 서비스는 SOA에서 나누는 서비스보다 규모가 훨씬 작다)

차이점

MSA는 SOA와 다르게 서비스 별 저장소를 분리하여 다른 서비스가 저장소를 직접 호출하지 못하게 캡슐화 함

MSA는 SOA와 다르게 REST API같은 가벼운 개방형 표준을 사용하여 느슨하게 연결
(SOA는 ESB / SOAP 등의 사용으로 인해 서비스간 결합도 증가)

함수형 프로그래밍

ref :
http://ruaa.me/why-functional-matters/
https://mangkyu.tistory.com/111

프로그래밍 패러다임

프로그래밍 패러다임(Programming Paradigm)은 프로그래머에게 프로그래밍의 관점을 갖게 하고, 코드를 어떻게 작성할 지 결정하는 역할을 한다

프로그래밍 패러다임은 크게 아래와 같이 구분된다

명령형 프로그래밍 : 어떻게(How) 할건지를 설명 --> 알고리즘 명시 O, 목표 명시 X

절차지향 프로그래밍 : 수행되어야 할 순차적인 처리과정을 포함하는 방식(C, C++)

객체지향 프로그래밍 : 객체들의 집합으로 프로그램의 상호작용을 표현(C++, Java)

선언형 프로그래밍 : 무엇(What)을 할 것인지 설명 --> 알고리즘 명시 X, 목표 명시 O

함수형 프로그래밍 : 순수 함수를 조합하고 소프트웨어를 만드는 방식(클로저 등)

(필요한 개념들) 부수 효과(Side effect) & 1급 객체 & 순수 함수

부수 효과(Side effect)

변수의 값이 변경됨

예외나 오류가 발생하며 실행이 중단됨

콘솔 또는 파일 I/O가 발생됨

객체의 필드값을 설정함

1급 객체

변수나 데이터 구조 안에 담을 수 있는 객체

파라미터로 전달을 할 수 있는 객체

반환값(return value)으로 사용할 수 있는 객체

할당에 사용된 이름과 무관하게 고유한 구별이 가능한 객체

함수형 프로그래밍에서 함수는 1급 객체로 취급받기 때문에 유연하고 다양하게 사용될 수 있음

순수 함수(Pure Function)

개념

부수 효과(Side effect)를 제거한 함수

동일한 입력에 항상 같은 값을 반환하는 함수(바뀔 일이 없음)

장점

함수 자체가 독립적이며, Side-effect가 없어서 Thread에 안정성을 보장받을 수 있음

Thread에 안정성을 보장받아 병렬 처리를 동기화 없이 진행할 수 있음

함수형 프로그래밍 등장

명령형 프로그래밍을 기반으로 개발했던 개발자들은 소프트웨어의 크기가 커짐에 따라, 복잡하게 엉켜있는 스파게티 코드를 유지보수하는 것이 매우 힘들다는 것을 느끼게 됨

모든 것을 순수 함수로 나누어 문제를 해결하는 기법인 함수형 프로그래밍에 관심을갖게 됨

결과적으로, 작은 문제를 해결하기 위한 함수를 작성하여 가독성을 높이고 유지보수를 용이하게 됨

함수형 프로그래밍 개념

순수 함수를 조합해서 소프트웨어를 만드는 방식

작은 문제를 해결하기 위한 함수를 작성(순수함수)

대입문이 없는 프로그래밍(변수를 항상 상수로 받아서 변경이 없음)

함수형 프로그래밍 필요성

동시성 프로그래밍
: 여러 스레드가 동시에 공유 데이터에 접근하더라도, 순수함수의 사용으로 불변성을 가지기 때문에 동시성과 관련된 문제를 원천적으로 봉쇄

가독성 향상
: 작은 문제를 해결하기 위한 함수를 통해 핵심 코드의 가독성이 올라간다

함수형 프로그래밍 예시

기존 코드
public static int evenSum() {  
   int sum = 0;
   for (int i = 1; i <= 100; i++) {
      if ( i % 2 == 0)
         sum += i;
   }
   return sum;
}
함수형 프로그래밍 코드
/* 훨씬 코드가 간결해짐 */
public static int evenSum() {  
   return IntStream.rangeClosed(1, 100)
         .filter(i -> i % 2 ==0)
         .reduce(0, (l, r) -> l + r);
}

CORS

ref :
https://velog.io/@josworks27/CORS-%EA%B8%B0%EC%B4%88-%EA%B0%9C%EB%85%90
https://velog.io/@wlsdud2194/cors

개념

교차 출처 리소스 공유를 하도록 허용하는 체계

이와 반대되는 개념으로 Same-Origin Policy 가 있음

웹은 기본적으로 보안상의 이유로 같은 Origin끼리만 통신하게 제한

Origin ?

도메인과 비슷하지만 프로토콜과 포트 정보를 명시하는 점이 다르다

도메인(domain) : naver.com

오리진(origin) : https://www.naver.com:포트번호

SOP(Same-Origin Policy)의 필요성

웹 시큐리티의 중요한 정책 중 하나로 Same-Origin Policy가 있는데, 이것은 Origin사이의 리소스 공유에 제한을 두어 다음 2가지를 예방한다

XSS(Cross-Site Scripting)
: 악의적인 Script를 삽입해서 정보를 탈취 --> Cookie내에 인증정보 탈취

CSRF(Cross-Site Request Forgeries)
: XSS로 획득한 정보를 통해서 유저가 의도하지 않은 request를 서버에게 보내는 것

CORS를 위한 HTTP request

CORS를 하기 위한HTTP request를 2가지 유형으로 분류하여 처리

단순 요청(Simple Requests)

비 단순 요청(Non-Simple Requests)

2가지 요청 유형에 따라서 클라이언트 / 서버 에서 HTTP request / response가 다르기 때문에 원리를 알아 둘 필요가 있음

단순 요청 처리 과정

[클라이언트]

HTTP request 헤더에 Origin : [client의 origin] 필드 추가

[서버]

HTTP response 헤더에 'Access-Control-Allow-Origin : [client의 origin]' 을 추가해서 보냄
(* 으로 입력하면 모든 도메인에 대해 요청을 허락한다는 것으로 간주할 수 있음)

비 단순 요청 처리 과정

[클라이언트]

사전 요청(preflight request)을 보내서 서버측과 통신이 가능한지 전송
(preflight request는 브라우저가 알아서 해주므로, 개발자가 직접하지 않아도 됨)

HTTP request header에 2가지 필드가 추가하면 preflight request가 된다

Access-Control-Request-Method : POST(예시)

Access-Control-Request-Headers: Content-Type,API-Key(예시)

[서버]

사전 요청(preflight request)에 대한 응답으로 허용할 origin, method, header, cache 정보들을 보내주어 전송 가능함을 확인

HTTP response header에 4가지 필드가 추가되어야 한다

허용할 origin : Access-Control-Allow-Origin : [client origin]

허용할 method : Access-Control-Allow-Methods: PUT, DELETE, GET, POST

허용할 headers
: Access-Control-Allow-Headers: API-Key,Content-Type,If-Modified-Since,Cache-Control

캐싱 정보(명시 시간동안은 preflight request 필요 X)
: Access-Control-Max-Age: 86400

그래서 개발자는 뭘해야 하는데?

클라이언트 개발자

보통 CORS처리를 서버측에서 하므로 따로 할일은 없음
(필요한 상황에 request에 포함될 필드는 브라우저가 자동으로 삽입해주기 때문)

하지만, 서버측 코드를 수정하지 않고 클라이언트쪽에서 proxy설정을 통해 이것을 처리할 수도 있음
(proxy를 통해서 same-origin의 요청으로 바꾸어서 통신을 가능하게 할 수 있음)

서버 개발자

클라이언트의 origin이 다른 경우, 요청을 처리하기 위해서 Access-Control-Allow-Origin 필드를 HTTP response headers 필드에 삽입해서 보내줘야 한다

추가

Node.js
: Cors 모듈을 가져와서 app.use()를 통해 추가해주면 됨
(매번 직접 response header에 추가해줄 순 없으니 모듈을 사용하자!)
--> 보통 Access-Control-Allow-Origin : *로 모든 origin 요청을 처리하도록 하는데 이것은 보안적으로 취약하기에 직접 client의 origin을 추가하는 option을 사용하는 것이 좋다 (CSRF 공격 대비)

Spring Boot
: @CrossOrigin 사용해서 origin을 추가

CORS인 경우 HTTP request에 쿠키가 자동 추가되지 않는다?

같은 Origin인 경우 자동으로 쿠키가 http request에 추가되지만,다른 Origin인 경우 추가적으로 설정이 필요하다

[클라이언트] : HTTP request headers에 withCredentials : true 추가

[서버] : HTTP response headers에 Access-Control-Allow-Credentials : true 추가

인증(Auhentication) vs 인가(Authorization)

인증(Auhentication)

클라이언트가 자신이 주장하는 사용자와 같은 사용자인지를 확인하는 과정

쿠키 / 세션 / 토큰은 인증을 하기 위한 수단들이다

인가(Authorization)

권한을 부여하는 것

차이 이해

인증을 거친 사용자에 대해 우리는 인가(권한 부여)를 해주는 것이다

Token 저장위치(feat. XSS, CSRF)

ref :
https://r4bb1t.tistory.com/38
https://velog.io/@yaytomato/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%90%EC%84%9C-%EC%95%88%EC%A0%84%ED%95%98%EA%B2%8C-%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%B2%98%EB%A6%AC%ED%95%98%EA%B8%B0

개요

웹 서비스에서 데이터를 저장할 수 있는 공간은 3개로 분류

쿠키(Cookie)

웹 스토리지(Web Storage)

로컬 스토리지(Local Storage)

세션 스토리지(Session Storage)

일반적으로 쿠키(Cookie)와 로컬 스토리지(Local Storage)중 선택하게 된다

쿠키(Cookie)

쿠키는 HTTP 통신의 무상태성을 보완해주기 위해 나온 것

서버가 보낸 data를 최대 4KB까지 저장하는 공간

서버에서 접근할 수 있는 것이 가장 큰 특성 !

HTTP Request시 자동으로 포함된다는 특징이 있음

httpOnly설정을 추가하여 JavaScript의 접근을 막을 수 있음
(Script를 이용하는 공격인 XSS를 예방 / CSRF공격에는 노출)

secure 설정을 추가하여 반드시 HTTPS통신을 하게되면 네트워크에서 토큰정보가 탈취되는 것을 막을 수 있음

로컬 스토리지(Local Storage)

서버에서 접근할 수 없음

persistent cookies와 비슷!

반 영구적으로 저장 가능

5 ~ 10MB의 크기를 갖는 공간

JS로 쉽게 접근할 수 있기 때문에 XSS에 취약

세션 스토리지(Session Storage)

서버에서 접근할 수 없음

session cookies와 비슷! --> 세션을 위한 저장 공간

세션이 종료되면 모두 삭제 (브라우저 종료시 삭제됨)

5 ~ 10MB의 크기를 갖는 공간

정리

보안이 크게 중요하지 않다면 로컬 스토리지(Local Storage)도 나쁘지 않은 선택이 될 수 있다

일반적으로는, 쿠키(Cookie)에 secure + httpOnly옵션을 사용을 많이 체택하는 것 같다
(여전히 보안 취약점은 가지고 있음 --> 완벽한 보안 방법은 없다ㅠㅠ)

다른 방법들

CSRF Token을 사용 --> Spring Security에서 권장

refresh token / access token을 사용하여 access token 시간 짧게 설정

등 정말 여러가지 방법이 있음

디자인 패턴(Design Pattern)

ref :
https://gmlwjd9405.github.io/2018/07/06/design-pattern.html

개념

소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴

종류

생성(Creational) 패턴 : 객체 생성과 관련된 패턴

추상 팩토리(Abstract Factory)
: 구체적인 클래스에 의존하지 않고, 연관되거나 의존적인 객체의 조합을 만드는 인터페이스를 제공하는 패턴

팩토리 메서드(Factory Method)
: 객체 생성 처리를 서브 클래스로 분리해 처리하도록 캡슐화하는 패턴

싱글턴(Sigleton)
: 하나의 객체는 하나의 인스턴스를 가지는 패턴

구조(Structural) 패턴 : 클래스나 객체를 조합해 큰 구조를 만드는 패턴

컴포지트(Composite)
: 복합 객체와 단일 객체를 구별 없이 다루게 해주는 패턴

데코레이터(Decorate)
: 객체의 결합을 통해 기능을 동적으로 유연하게 확장할 수 있는 패턴

행위(Behavioral) 패턴 : 객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴

옵서버(Observer)
: 한 객체의 상태 변화에 따라 다른 객체의 상태도 연동되도록 일대다 객체 의존 관계를 구성하는 패턴

스테이트(State)
: 객체의 상태에 따라 객체의 행위 내용을 변경해주는 패턴

스트래티지(Strategy)
: 행위를 클래스로 캡슐화해 동적으로 행위를 자유롭게 바꿀 수 있게 해주는 패턴

템플릿 메서드(Template Method)
: 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴

커맨드(Command)
: 실행될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를 설계하는 패턴

MVC / Front Controller / Adapter 패턴

MVC 패턴

디자인 패턴 중 구조와 관련한 패턴 중 하나

Model / View / Controller 로 각 역할에 맞추어 분리한 구조

Model : View에 보여질 데이터를 가지고 있는 Object

View : Model에 있는 데이터를 통해 User에게 보여주는 부분

Controller : 요청에 대한 처리 및 비즈니스 로직을 수행하는 부분
(보통 비즈니스 로직을 수행하거나 트랜잭션, 도메인 간 순서 보장을 위해 Service를 따로 둠)

장점

분리를 통해 각자 역할에 집중할 수 있게 한다

유지보수성, 애플리케이션 확장성, 유연성이 증가

Front Controller 패턴

디자인 패턴 중 구조와 관련한 패턴 중 하나

사용자의 요청을 처리하는 하나의 컨트롤러(Front Controller)를 통해 개발 및 유지보수의 효율성을 올리는 패턴

기존 MVC 패턴에서는 사용자의 요청을 처리하기 위해 각자 Servlet을 생성 및 관리하였으며, forward 중복, viewPath중복 등이 발생
--> 공통으로 사용자의 요청을 처리하는 컨트롤러(Front Controller) 도입

Adapter 패턴

디자인 패턴 중 구조와 관련한 패턴 중 하나

서로 다른 인터페이스를 사용하기 위해 중간 Adapter를 두어 해결하는 패턴

장점

유연성이 증가

확장성이 증가

스프링 MVC 구조

MVC 패턴 + Front Controller 패턴 + Adapter 패턴

MVC 패턴

Model / View / Controller 각 역할로 나누어서 유지보수 용이

Front Controller 패턴

매번 요청을 처리하기 위한 서블릿 생성/삭제 등 관리를 각자 하는 것은 비효율적
--> 서블릿 관리, viewPath관리 등 공통으로 처리하기 위해 Front Controller 도입

Adapter 패턴

다양한 종류의 인터페이스를 처리하기 위해 Adapter를 추가해서 유연성 증가
--> HandlerAdapter를 통해서 실제 Handler(Controller)를 호출

김정욱

Developer & PhotoGrapher

이전 포스트

[면접 대비] 이것 저것(etc)

면접준비

컴포넌트 & 모듈

C++ & Java 차이점

설계 목표

메모리 관리

실행 과정

다중상속과 연산자 오버로드

인자 전달 방법의 차이

OOP(객체지향 프로그래밍) 3요소 5원칙

3요소

5원칙

1. SRP(Single responsibility Principle)

2. OCP(Open/Closed Principle)

3. LSP(Liskov Substitution Principle)

4. ISP(Interface Segregation Principle)

5. DIP(Dependency Inversion Principle)

추상 메서드 / 추상 클래스 / 인터페이스

추상(abstract) 메서드

추상(abstract) 클래스

인터페이스(interface)

상속(extends) vs 구현(implements)

TDD(Test-Driven Development)

개념

TDD cycle

필요성(장점)

TDD를 적용하기 어려운 이유

단위 테스트 & 통합 테스트

단위 테스트(Unit Test)

통합 테스트(Integration Test)

단위 테스트 작성의 필요성

단위 테스트의 문제점 & Stub

DDD(도메인 주도 설계)

DDD(Domain-Driven Design)

도메인

도메인 모델

도메인 모델 패턴

DDD(도메인 주도 설계) 아키텍처 구조

트랜잭션 스크립트 vs 도메인 모델 패턴

로직 패턴

트랜잭션 스크립트

도메인 모델 패턴

MA vs SOA vs MSA

MA(Monolithic Architecture)

SOA(Service Oriented Architecture)

MSA(Micro Service Architecture)

SOA와 MSA

함수형 프로그래밍

프로그래밍 패러다임

(필요한 개념들) 부수 효과(Side effect) & 1급 객체 & 순수 함수

함수형 프로그래밍 등장

함수형 프로그래밍 개념

함수형 프로그래밍 필요성

함수형 프로그래밍 예시

CORS

개념

SOP(Same-Origin Policy)의 필요성

CORS를 위한 HTTP request

단순 요청 처리 과정

비 단순 요청 처리 과정

그래서 개발자는 뭘해야 하는데?

인증(Auhentication) vs 인가(Authorization)

인증(Auhentication)

인가(Authorization)

차이 이해

Token 저장위치(feat. XSS, CSRF)

개요

쿠키(Cookie)

로컬 스토리지(Local Storage)

세션 스토리지(Session Storage)

정리

디자인 패턴(Design Pattern)

개념

종류

MVC / Front Controller / Adapter 패턴

MVC 패턴

Front Controller 패턴

Adapter 패턴

스프링 MVC 구조

[CS 정리] 데이터베이스(DataBase)