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

김정욱·2021년 5월 30일
DDDMAOOPSOASOLIDTDDcorsmsa
2

면접준비

목록 보기
6/6
post-thumbnail

컴포넌트 & 모듈

  • 컴포넌트
    • 실질적으로 동작되고 있는 개체(단위)
  • 모듈
    • 가장 상위에 위치하는 구현의 단위
    • 실질적으로 구현이 된 단위
    • 기능을 기준하여 분리된 단위

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)를 호출
profile
김정욱
Developer & PhotoGrapher
이전 포스트

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

0개의 댓글