@ResponseBody

@ResponseBody를 명시하면 api 통신을 위해 MessageConverter에 데이터가 전송된다. 정확하게 알아보기 위해 명시하지 않았을 때와 비교해보자.

viewResolver

명시하지 않았을 때는 아래처럼 Controller가 리턴 값을 반환했을 때 viewResolver가 받아 처리한다. viewResolver는 클라이언트에게 반환해줄 View를 결정하는 역할을 한다.

1. Controller가 뷰 이름(예: "home")을 반환
2. ViewResolver는 설정에 따라 해당 뷰 이름을 물리적 뷰 경로(예: /WEB-INF/views/home.jsp)로 매핑
3. 매핑된 물리적 경로를 기반으로 View 객체를 생성
4. 생성된 View 객체는 클라이언트에게 적절한 HTML이나 템플릿을 렌더링

viewResolver는 View를 반환하기 때문에 MVC를 사용하는 템플릿 기반 웹 어플리케이션을 구현할 때 사용된다.

HttpMessageConverter

명시할 때는 아래처럼 HttpMessageConverter가 리턴 값을 받는다. HttpMessageConverter는 이름에서 알 수 있듯이 Http 통신 간의 메시지를 변환해주는 역할을 한다.

1. 컨트롤러가 반환하는 객체(예: List)를 HTTP 응답 메시지(예: JSON, String)로 변환
2. 클라이언트로부터 들어온 HTTP 요청 데이터를 Java 객체로 변환
3. 변환 작업은 Content-Type과 Accept 헤더를 기반으로 수행

역할에서 알 수 있듯이 데이터 교환이 주 목적으로, api 기반 서비스 구현에 사용된다.

Reference

스프링 입문 - 김영한

“Redux implements Flux”

Redux가 Flux라는 디자인 패턴을 실제로 구현한 구현체라는 것이다.

그래서 Flux 패턴을 공부하는 것이 추후 Redux를 빠르게 이해하는데 용이할 것이다.

Flux

Flux란 Meta에서 클라이언트 사이드 웹 어플리케이션을 위해 고안한 아키텍쳐이다.

Flux의 공식 Github 레포지토리에서는 Flux를 다음과 같이 정의하고 있다.

An application architecture for React utilizing a unidirectional data flow.

출처: https://github.com/facebookarchive/flux?tab=readme-ov-file

해석하면, ‘*단방향 데이터 흐름을 활용한 React용 어플리케이션 아키텍쳐*’이다.

여기서 제일 중요한 부분은 ‘단방향 데이터 흐름’이라는 키워드이다.

왜냐하면 당시의 Facebook이 MVC의 단점이라고 판단한 양방향 데이터 흐름을 해결하기 위해 Flux를 고안한 것이기 때문이다.

MVC란?

MVC란 Model-View-Controller의 약자로 데이터 및 논리 제어를 구현하기 위한 디자인 패턴이다.

MVC의 구조는 다음과 같다.

• Model: 데이터와 비즈니스 로직을 관리한다.
• View: 레이아웃과 화면을 처리한다.
• Controller: Model과 View로 명령을 전달한다.

Controller가 요청한 Data를 Model이 DB에서 불러와 요청에 응답하면, Controller가 해당 데이터를 View에 전송에 보여주는 형태이다.

중요한 것은 요청과 응답이 발생하여 데이터가 업데이트되면 View와 Model이 업데이트된다. 즉, View가 Model을 업데이트할 수도 있고, Model이 View를 업데이트할 수도 있다. 이를 다른 말로 양방향 데이터 흐름이라고 한다.

MVC의 문제점

Facebook이 단점으로 생각한 양방향 데이터 흐름이 문제가 되는 이유는 복잡도가 증가될 때 있다.

위 사진이 MVC의 문제점을 직관적으로 보여주고 있다.

양방향 데이터 흐름의 단점은 다음과 같다.

• 복잡도가 높아질 수록 업데이트 비용도 높아짐
• 복잡도가 높아질 수록 버그의 추적이 어려워 예측하기 어려운 코드가 됨

이러한 문제가 생기는 결정적인 이유는 요소 간의 의존도가 높기 때문이다. 위 사진과 같이 View와 Model은 상호의존적이기 때문에 한 요소의 복잡도가 올라가면 다른 요소의 복잡도도 올라간다. 그래서 어플리케이션이 복잡해지면 복잡해질수록 MVC의 구조가 무의미해진다.

FE(Front-end)에서 MVC를 적용하기 힘든 가장 큰 이유는 View가 메인이 되기 때문이다. MVC에서 View는 단순하게 요청한 데이터를 보여주는 결과에 불과하지만, FE에서는 View에서 발생하는 이벤트를 통제하는 것이 메인이기 때문에 MVC의 목적과는 모순된다. 그래서 실제로 FE에서 MVC를 구현해보면 View와 Model의 갯수가 증가함에 따라 Controller의 규모가 무지막지하게 커진다.

Flux의 구조

Flux는 MVC의 단점을 해결해기 위해 단방향 데이터 흐름으로 설계되었다.

• Action: 상태 변경 요청을 담은 JS 객체

    {
        type: '새로운 메시지 도착',
        payload: {
            id: ...,
            message: '오늘 점심 메뉴 뭐 먹을까?',
            threadId: ...,        
        }
    }

  • type: 액션 이름
  • payload: 데이터

• Dispatcher: 모든 데이터 변경 요청이 경유하는 중앙 허브

  • View로부터 Action을 받아 모든 Store들에게 전송
  • 내부에 상태 변경 로직이 존재하지 않음
  • Store 간 의존성 관리
    • Store A의 상태 변경 순서를 Store B 다음으로 미룰 수 있음

• Store: 어플리케이션 상태 및 로직 컨테이너

  • Dispatcher에서 전달된 Action을 통해서만 상태 변경
  • 상태가 변경되면 View에게 통지

• View: 상태에 따라 화면을 출력

  • Controller-View (React)
    • View와 Controller의 역할을 동시에 함
    • Store가 통지하는 상태 변경을 수신 받은 상태에 따라 View를 새로 렌더링
  • Dispatcher에게 Action 전달

Flux의 장점

• 단방향 데이터 흐름으로 구성하여 복잡성을 해결하였음
• 컴포넌트 간의 의존성을 줄여서 유지보수가 용이함
• 그로 인해 예측 가능성이 높아져 대규모 프로젝트에도 적합함

Reference

Meta Archive, flux, https://github.com/facebookarchive/flux?tab=readme-ov-file Facebook, Flux, https://haruair.github.io/flux/ mdn web docs, MVC, https://developer.mozilla.org/ko/docs/Glossary/MVC

JWT

JWT는 JSON Web Token의 약자로 Web 환경에서의 안전한 정보 전송을 위한 개방형 표준으로 JSON 객체 형태로 정의된다.

개발자가 정의한 JWT가 사용되는 경우는 다음과 같다.

• 권한 부여
  • 가장 일반적인 경우로 사용자가 로그인할 때 권한을 부여하는 목적으로 사용된다.
  • 로그인 이후 각 요청에 JWT가 포함되어 해당 토큰으로 허용된 경로, 서비스 및 리소스에 접근할 수 있다.
• 정보 교환
  • JWT는 당사자 간에 안전한 정보 전달을 위해서도 사용된다.
  • JWT는 서명된 키로 사용되기 때문에 사용자 인증에 용이하다.
  • Header와 Payload를 사용하여 변조 여부도 확인 가능하다.

Cookie vs Session/Cookie vs JWT

JWT 는 특히 사용자 인증 기능에 가장 많이 사용된다. 그래서 가장 많이 사용되는 인증 방식들을 한번 비교 해보았다.

Cookie

• 장점
  • 인증 테스트를 할 경우 및 간단한 앱을 만들때 빠르게 설계할 수 있음
• 단점
  • 보안에 매우 취약하여 해킹을 당하는 일이 빈번함
  • 용량 제한이 있어 많은 정보를 담을 수 없다. (용량이 커질수록 네트워크 부하가 심해져 성능 저하 문제가 발생할 수 있음)

Session/Cookie

• 장점
  • 매개가 되는 Cookie는 유의미한 값을 갖지 않음
    • Cookie는 Session Storage에서 가져온 Session ID를 담는 역할
    • 따라서, 계정정보를 담아 인증을 거치는 것보다 안전함
  • 각 사용자마다 고유한 Session ID가 발급되기 때문에 요청이 들어올 때마다 회원정보를 확인할 필요가 없음
• 단점
  • 세션 하이재킹 공격이 발생할 수 있음
    1. A 사용자의 HTTP 요청을 B 사용자(해커)가 가로챔
    2. B 사용자는 가로챈 HTTP 요청을 이용해 내부의 Cookie를 탈취함
    3. B 사용자가 탈취한 Cookie를 이용해 서버에 HTTP 요청을 보냄
    4. 서버는 B 사용자를 A 사용자로 오인하여 정보를 잘못 보냄
  • Session Storage를 서버에 구축해야 하기 때문에 사용자가 많아지는 경우 서버 부하가 발생할 수 있음

구조

JWT는 JSON 정보가 Base64Url로 인코딩된 형태가 점(.)으로 구분된 세 부분으로 구성되며, 각 부분은 다음과 같다.

• Header
• Payload
• Signature

세 부분이 각각 인코딩되어서 다음과 같은 형태를 띤다.

xxxxx.yyyyy.zzzzz

Header

Header는 일반적으로 해시 알고리즘(HMAC SHA256 또는 RSA 등)과 토큰 유형을 정의한다.

{
    "alg": "HS256",
    "typ": "JWT"
}

Payload

Payload는 전달하고자 하는 데이터에 관한 내용이 포함된다.

데이터의 Key를 claim이라고 하며 세 가지 종류로 나뉜다.

• Registered claims (등록된 클레임)
  • 필수는 아니지만 사용이 권장되는 claim으로 압축을 위해 세 글자로만 구성된다.
  • iss (issuer), exp (expiration time), sub (subject), aud (audience) 등
  • 그 외의 claim: https://datatracker.ietf.org/doc/html/rfc7519#section-4.1
• Public claims (공개 클레임)
  • 사용자가 자유롭게 정의할 수 있는 claim이다.
  • 하지만 충돌을 피하기 위해 다음 두 가지 방식으로 정의해야 한다.
    • IANA JSON 웹 토큰 레지스트리 에서
    • 충돌 방지 네임스페이스를 포함하는 URI
• Private claims (비공개 클레임)
  • 당사자 간 정보 공유를 위한 맞춤형 claim
  • 사용을 동의한 당사자 간에 정보 공유를 위해 작성된다.

{
    "sub": "1234567890",
    "name": "John Doe",
    "admin": true
}

Signature

Signature는 인코딩된 Header, Payload와 Secret Key가 합쳐진 형태로 생성된다.

예를 들어, HMAC SHA256 알고리즘을 사용하는 경우 다음과 같은 방식으로 생성된다.

HMACSHA256(
    base64UrlEncode(header) + "." +
    base64UrlEncode(payload),
    secret)

세 부분이 각각 Base64Url로 인코딩되어 다음과 같은 형태로 보여진다.

jwt.io debugger를 사용해서 실제로 생성해볼 수 있다.

JWT의 문제

위에서 언급하였듯이 JWT는 만능이 아니다. 다른 인증 방식에 비하여 서버 부하가 적고, 보안에 강하기 때문에 많이 사용되고, 권장하는 방식이지만 무턱대고 사용하는 경우 큰 보안 이슈가 발생한다.

1. 알고리즘 지정

{
    "alg": "none",
    "typ": "JWT"
}

위와 같이 Header의 해시 알고리즘 부분을 “none”으로 해두는 경우이다.

어떤 멍청한 개발자가 이렇게 하냐 싶겠지만 생각보다 많은 사람들이 실수하는 부분이기 때문에 한번 더 확인하는 것을 추천드린다.

실제로 “none”을 집어넣고 해킹을 시도하는 경우도 존재하기 때문에 이를 방지하기 위해서 “none”인 경우를 걸러주는 로직도 구현할 필요가 있어보인다.

2. 유저 정보

JWT는 인코딩된 문자열이기는 하지만 디코딩이 매우 쉽다.

그렇기 때문에 JWT에는 절대로 민감한 유저 정보를 넣어서는 안되고, 해당 유저임을 확인할 수 있는 최소한의 정보만 넣어야 한다.

3. Secret Key 문제

Secret Key는 당연하게도 어렵게 만들어야 한다.

로그인에 필요한 비밀번호와 같은 것이기 때문에 유추가 쉬운 문자는 당연히 배제해야 하고, 최대한 길게 생성하고, 생성된 키는 철저하게 관리해야 한다.

이게 조금 불안하다 싶으면 많은 사람들이 사용하는 방법이 존재한다.

Private/Public Key Pair

생성과 검증에 필요한 공개 키와 비밀 키를 생성하는 것이다. 좀 더 쉽게 설명하자면 매우 풀기 어려운 수학적 문제(공개 키)와 출제자만 알고 있는 특정한 종류의 정보(비밀 키)를 생성한다. 문제(공개 키)를 풀면 원래의 메시지(비밀 키)를 해독할 수 있다.

이 방법을 사용하면 하나의 키를 사용할 때보다 키의 유출 위험이 줄어들고, 통신의 비밀성을 보장할 수 있다. 또한, 네트워크 규모가 커질수록 관리가 훨씬 용이해진다.

4. JWT 탈취

Session/Cookie 방식과 비슷하게 토큰을 탈취하는 경우가 발생할 수 있다. JWT는 클라이언트에서 관리되기 때문에 서버에서 이 문제를 해결할 수 있는 방법은 없다. 이를 방지하기 위해 유효기간이 존재하지만, 만료될 때까지 기다려야 한다는 문제가 있다. 그래서 이를 해결하기 위한 좋은 방법이 존재한다.

Access Token과 Refresh Token

기본적인 개념은 다음과 같다

• Access Token
  • 유효기간이 짧은 토큰(ex. 60일, 1시간)
  • API 통신에 사용됨
• Refresh Token
  • 유효기간이 긴 토큰(ex. 1년)
  • Access Token 갱신 시 사용됨

해당 방법을 사용한 통신 과정은 다음과 같다.

1. 로그인 인증에 성공한 클라이언트는 Refresh Token과 Access Token 두 개를 서버로부터 받는다.
2. 클라이언트는 Refresh Token과 Access Token을 로컬에 저장해놓는다.
3. 클라이언트는 헤더에 Access Token을 넣고 API 통신을 한다. (Authorization)
4. 일정 기간이 지나 Access Token의 유효기간이 만료되었다.
   1. Access Token은 이제 유효하지 않으므로 권한이 없는 사용자가 된다.
   2. 클라이언트로부터 유효기간이 지난 Access Token을 받은 서버는 401 (Unauthorized) 에러 코드로 응답한다.
   3. 401를 통해 클라이언트는 invalid_token (유효기간이 만료되었음)을 알 수 있다.
5. 헤더에 Access Token 대신 Refresh Token을 넣어 API를 재요청한다.
6. Refresh Token으로 사용자의 권한을 확인한 서버는 응답쿼리 헤더에 새로운 Access Token을 넣어 응답한다.
7. 만약 Refresh Token도 만료되었다면 서버는 동일하게 401 error code를 보내고, 클라이언트는 재로그인해야한다.

Refresh Token 탈취?

해당 방법은 Access Token 탈취 문제를 해결하고자 만든 것이기 때문에 Refresh Token에 탈취 문제를 해결한 것은 아니다. OAuth는 이를 해결하기 위해 Refresh Token Rotation을 제시한다.

클라이언트가 Access Token을 재요청할 때 Refresh Token도 새로 발급받는 것이다. 이렇게 하면 탈취된 Refresh Token은 더 이상 해당 사용자의 Token이 아니게 되는 것이기 때문에 탈취 위험에서 벗어날 수 있게 된다.

Reference

JWT, Introduction, https://jwt.io/introduction 코딩애플, JWT 대충 쓰면 님들 인생 끝남, https://www.youtube.com/watch?v=XXseiON9CV0 Wikipedia, 공개 키 암호 방식, https://ko.wikipedia.org/wiki/공개키암호_방식 OAuth, What Are Refresh Tokens and How to Use Them Securely, https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/

Hooks

Hook은 버전 16.8부터 새로 추가된 요소로, 기존 Class 바탕의 코드 없이 상태 값과 여러 React의 기능을 사용할 수 있는 요소이다.

Hook이라는 개념이 고안된 이유는 사용자들이 직면한 다음과 같은 문제들 때문이다.

1. 컴포넌트 사이에서 상태 로직을 재사용하기 어렵다.
   • React는 컴포넌트 간에 재사용 가능한 로직을 붙이는 방법을 제공하지 않았다.
   • 이전에는 render props, 고차 컴포넌트와 같은 패턴으로 해결하였지만, 이러한 패턴은 컴포넌트의 재구성을 강요하여, 코드의 추적을 어렵게 만들었다.
   • Hook은 계층의 변화 없이 상태 관련 로직을 재사용할 수 있도록 도와준다.
2. 복잡한 컴포넌트들은 이해하기 어렵다.
   • 각 생명주기 메서드에는 자주 관련 없는 로직이 섞여들어간다.
   • Hook을 통해 서로 비슷한 것을 수행하는 작은 함수의 묶음으로 컴포넌트를 나누는 방법을 사용할 수 있다.
3. Class의 this 키워드
   • React에서 Class를 사용하기 위해서는 Javascript의 this 키워드가 어떻게 작동하는지 알아야 한다.
     • 다른 언어와는 다르게 작동하기 때문에 코드의 재사용성과 구성을 매우 어렵게 만들었다.
   • Hook은 Class 없이 React 기능들을 사용하는 방법을 제시한다.

Hooks의 종류

1. useState

useState는 가장 기본적인 Hook으로 가변적인 상태를 지니고 있을 수 있게 해준다

useState의 구조

// const [state, 업데이트 함수] = useState(초기값);
const [count, setCount] = useState(0);

• parameter
  • state의 초기값을 인수로 가짐
• return
  • state와 함수를 포함한 배열을 반환함
  • 반환된 함수를 통해 state를 업데이트 할 수 있음

Example

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Number: {count}</p>
      <button type="button" onClick={() => setCount(count + 1)}>
        +
      </button>
      <button type="button" onClick={() => setCount(count - 1)}>
        -
      </button>
    </div>
  );
}

export default Counter;

버튼을 통해 count의 값이 변경되는 기능이 구현되어있다.

useState는 parameter로 state의 초기값을 받아 저장한다. 따라서 해당 코드에서는 count의 초기값이 0으로 주어지고, setCount 함수를 통해 count의 값을 변경 가능하다.

state는 당연하게도 컴포넌트의 state로 작용하기 때문에 값이 변경되면 실시간으로 리렌더링된다.

2. useEffect

useEffect는 컴포넌트가 렌더링 될 때마다 특정 작업을 설정할 수 있는 Hook이다.

“Effect”는 Side-Effect의 의미로 useEffect를 통해 부작용을 관리할 수 있다.

useEffect의 구조

// useEffect(callback 함수, dependency array)
useEffect(() => {
    console.log('useEffect 호출')

    // return () => {}
}, [key])

• parameter
  • callback 함수: 컴포넌트의 생명주기에 따라 실행되는 함수
    • 함수를 return 값으로 가질 수 있음
    • 마운트 될 때 (componentDidMount)
      • callback 함수가 return 이전까지 실행됨
    • 업데이트 될 때 (componentDidUpdate)
      • dependency array에 값이 포함되어 있으면, 해당되는 값이 업데이트 될 때 callback 함수가 return 이전까지 실행됨
      • dependency array가 빈 배열이면 실행되지 않음
    • 언마운트 될 때 (componentWillUnmount)
      • callback가 return하는 함수가 실행됨
  • dependency array(의존성 배열): callback 함수가 의존하는 값들이 포함되어 있음
    • 빈 배열일 경우에는 컴포넌트가 마운트 될 때, 즉, 처음 렌더링될 때만 함수가 실행됨

Example

import { useState, useEffect } from 'react';

function Welcome () {
    const [name, setName] = useState('');

    useEffect(() => {
        if (name == '') {
            alert('Welcome');
        } else {
            alert(`${name}님 환영합니다!`);
        }

        return () => { // optional
            alert('안녕히가세요!');
        }
    }, [name]);

    return (
        <>
            <input type="text" name="name" value={name} onChange{() => setName(name)} />
        </>
    )
}

export default Welcome;

input을 통해 입력한 이름을 alert 메시지로 출력하는 예제를 구현해보았다.

예제에서 useEffect가 실행되는 조건은 다음과 같다.

• 첫 마운트 시: ‘당신의 이름을 입력하세요’ 메시지가 alert됨
• name의 값이 변경될 때: ‘${name}님 환영합니다!’ 메시지가 alert됨
• 언마운트 시: ‘안녕히가세요!’ 메시지가 alert됨

3. useContext

useContext는 함수형 컴포넌트에서 Context를 보다 쉽게 사용할 수 있는 Hook이다.

Context는 React 내에서 전역 상태를 관리할 수 있는 방법 중에 하나이다. 전역 상태 관리란 말 그대로 state를 전역에서 관리하기 때문에 Props Drilling 문제를 해결할 수 있다.

import { createContext, useContext } from "react";

const ThemeContext = createContext("black");

function ContextSample() {
  const theme = useContext(ThemeContext);
  const style = {
    width: "24px",
    height: "24px",
    background: theme,
  };
  return <div style={style} />;
}

export default ContextSample;

4. useReducer

useReducer는 useState와 같이 state를 관리할 수 있는 Hook이다. useState와 다른 점은 state를 업데이트 하는 로직을 컴포넌트로부터 분리시키는 것이 가능하다는 것이다.

Redux를 알고 있다면 생각나는 그 reducer를 생각하면 편하다. 조금 다른 점은 Redux 에서는 액션 객체에 어떤 액션인지 알려주는 type 필드가 꼭 있어야 하지만, useReducer 에서 사용하는 액션 객체에서는 꼭 지니고 있을 필요가 없다.

useReducer의 구조

const reducer = (state, action) => { 
    // ...
}

// const [state, dispatch] = useReducer(reducer 함수, object)
const [state, dispatch] = useReducer(reducer, { value: 0 });

• parameter
  • reducer 함수: action이 정의된 함수
    • parameter로 state와 action을 가짐
    • state들이 어떻게 업데이트되는지에 대한 로직이 정의되어 있음
  • object: state들의 초기값이 저장된 object
• return
  • state와 dispatch가 포함된 배열이 반환됨
  • dispatch를 통해 state를 업데이트 할 수 있음

Example

import { useReducer } from "react";

function reducer(state, action) {
  switch (action.type) {
    case "INCREMENT":
      return { value: state.value + 1 };
    case "DECREMENT":
      return { value: state.value - 1 };
    default:
      return { value };
  }
}

function Counter() {
  const [state, dispatch] = useReducer(reducer, { value: 0 });

  return (
    <div>
      <p>Number: {state.value}</p>
      <button type="button" onClick={() => dispatch({ type: "INCREMENT" })}>
        +
      </button>
      <button type="button" onClick={() => dispatch({ type: "DECREMENT" })}>
        -
      </button>
    </div>
  );
}

export default Counter;

카운터 예제를 useReducer로 구현해보았다.

dispatch는 action을 인수로 가지며, action의 type 값을 통해서 로직을 선택할 수 있다. type이 달라질 때마다 카운터 값을 변경하는 방식이 달라지고 있다.

useReducer vs useState

• useState
  • 관리해야 할 state가 1개일 경우
  • 그 state가 단순한 숫자, 문자열 또는 boolean 값일 경우
• useReducer
  • 관리해야 할 state가 1개 이상, 복수일 경우
  • 혹은 현재는 단일 state 값만 관리하지만, 추후 유동적일 가능성이 있는 경우
  • 스케일이 큰 프로젝트의 경우
  • state의 구조가 복잡해질 것으로 보이는 경우

해당 Hook과 관련해서 더 자세하게 알고 싶다면, React의 상태 관리와 Redux에 대해 공부해보기를 권장한다.

5. useMemo

useMemo는 컴포넌트의 성능을 최적화 하는데 사용되는 Hook이다.

“Memo”는 memorization, 즉, ‘메모리에 넣기’를 의미한다. 프로그램이 동일한 계산을 반복해야 할 때, 이전에 계산한 값을 메모리에 저장함으로써 반복 수행을 제거하여 프로그램 실행 속도를 빠르게하는 기술이다.

useMemo의 구조

// const value = useMemo(callback 함수, dependency array)
const value = useMemo(() => {
    return calculate();
}, [item])

• useEffect의 구조와 비슷하게 생각하면 됨
• parameter
  • callback 함수: 렌더링될 때 실행되는 함수
    • useEffect와 동일하게 처음 렌더링될 때와 dependency array의 값이 업데이트될 때 실행됨
    • 다른 값에 의해 렌더링될 경우 메모리에 저장된 값을 재사용한다.
  • dependency array(의존성 배열): callback 함수가 의존하는 값들이 포함되어 있음
    • useEffect와 동일하게 빈 배열인 경우 처음 렌더링될 때 이후엔 callback 함수가 실행되지 않고 저장된 값을 재사용함

Example

import { useState } from "react";

function hardCalculate(number) {
  console.log("어려운 계산!");
  for (let i = 0; i < 99999999; i++) {} //생각하는 시간
  return number + 10000;
}

function easyCalculate(number) {
  console.log("쉬운 계산!");
  return number + 1;
}

function App() {
  const [hardNumber, setHardNumber] = useState(1);
  const [easyNumber, setEasyNumber] = useState(1);

  const hardSum = hardCalculate(hardNumber);
  const easySum = easyCalculate(hardNumber);

  return (
    <div>
      <h3>어려운 계산기</h3>
      <input
        type="number"
        value={hardNumber}
        onChange={(e) => setHardNumber(parseInt(e.target.value))}
      />
      <span> + 10000 = {hardSum}</span>

      <h3>쉬운 계산기</h3>
      <input
        type="number"
        value={easyNumber}
        onChange={(e) => setEasyNumber(parseInt(e.target.value))}
      />
      <span> + 1 = {easySum}</span>
    </div>
  );
}

export default App;

어떤 블로그의 예제를 들고와 봤다.

어려운 계산기와 쉬운 계산기를 구현한 예제이다.

어려운 계산기는 반복문을 99999999번 돌리고 값을 반환하기 때문에 숫자를 변경하면 1초 정도의 딜레이를 거친 후 값이 변경된다.

심지어 쉬운 계산기의 값을 변경해도 1초 정도의 딜레이를 거친 후 값이 변경된다.

그 이유는 쉬운 계산기의 input값을 변경하면 컴포넌트가 리렌더링되는데 이 때 내부의 변수들이 초기화되기 때문에 hardCalculate가 다시 실행되기 때문이다.

그렇다면 이제 useMemo를 통해 이를 방지해보자.

const hardSum = useMemo(() => {
    return hardCalculate(hardNumber)**;**
}, [hardNumber]);

이렇게 하면 처음 렌더링될 때 hardCalculate로 계산된 값이 메모리에 저장되기 때문에 hardNumber가 업데이트되지 않는 경우에는 딜레이를 거치지 않아도 된다.

6. useCallback

useCallback은 useMemo와 동일하게 memorization 기법으로 컴포넌트 성능을 최적화 시켜주는 Hook이다.

useMemo가 값을 저장하는 거라면 useCallback은 함수를 자체를 저장하는 거라고 이해하면 된다.

useCallback의 구조

// useCallback(callback 함수, dependency array)
useCallback(() => {
    return value;
}, [item]);

• parameter
  • callback 함수: 렌더링될 때 실행되는 함수
    • useMemo와 동일하게 실행됨
  • dependency array(의존성 배열): callback 함수가 의존하는 값들이 포함되어 있음
    • 이것도 useMemo의 dependency array와 동일함

Example

import { useEffect, useState, useCallback } from 'react';

function App() {
    const [number, setNumber] = useState(0);

    const someFunction = useCallback(() => {
        console.log(`someFunc: number: ${number}`);
        return;
    }, []);

    useEffect(() => {
        console.log("someFunction 이 변경되었습니다.");
    }, [someFunction]);

    return (
        <div>
            <input
                type="number"
                value={number}
                onChange={e => setNumber(e.target.value)}
            />
            <br />
            <button onClick={someFunction}>Call someFunc</button>
        </div>
    );
}

export default App;

위 코드도 어떤 블로그의 예제를 빌려왔다. useEffect를 이용해 callback 함수가 memorization된 것을 확인하는 예제이다.

useCallback의 callback 함수는 처음 렌더링될 때 실행되고 메모리에 저장된다. useCallback의 denpendency array가 빈 배열이기 때문에 이후에는 메모리에 저장된 callback 함수를 재사용하게 된다. 따라서, useEffect의 callback 함수는 마운트될 때 이후에는 실행되지 않는다.

7. useRef

useRef는 저장공간 도는 DOM요소에 접근하기 위해 사용되는 Hook이다.

Example1 - 변수 관리

!codesandbox[fpp7l2?view=editor+%2B+preview&module=%2Fsrc%2FApp.js]

위 코드도 특정 블로그의 예제를 들고 온 것이다.

useState, useRef 그리고 let 키워드를 사용해서 세 가지 형태의 변수를 정의한 것이다. 그리고 각각 세 가지 버튼으로 해당 변수들의 값을 증가시킬 수 있다.

직접 실행해보면 각각의 특징이 다음과 같다.

• stateCount: useState로 선언된 변수로 값이 증가될 때 실시간으로 렌더링된다.
• refCount: useRef로 선언된 변수로 증가될 때 렌더링되지 않고, 렌더링되도 값이 유지된다.
• varCount: 일반적인 javascript 변수로 렌더링될 때 값이 초기화된다.

여기서 알 수 있는 것은 useRef의 값은 유지되지만 업데이트 시 렌더링되지 않아서 변수를 관리하는데 용이하다.

Example 2 - DOM 지정

import { useRef } from 'react';

function App() {
    const inputRef = useRef();

    function focus() {
        inputRef.current.focus();
        console.log(inputRef.current);
    }

    return (
        <div>
            <input ref={inputRef} type="text" />
            <button>Login</button>
            <button onClick={focus}>focus</button>
        </div>
    )
}

useRef로 선언된 변수는 DOM 요소를 지정할 수 있다.

React에서는 javascript의 querySelector 대신 useRef를 사용해서 DOM 요소를 지정하는 것이 가능하다.

Reference

React, Hook의 개요, https://ko.legacy.reactjs.org/docs/hooks-intro.html Hayoung, React Hook :: useReducer에 대해 알아보기, https://velog.io/@iamhayoung/React-Hooks-useReducer에-대해-알아보기 김진영, [React] useMemo란?, https://velog.io/@jinyoung985/React-useMemo란 sohyeon kim, [React] 다시 한번 useCallback을 파헤쳐보자, https://velog.io/@hjthgus777/React-다시-한번-useCallback을-파헤쳐보자

Lifecycle

React에는 Lifecycle 즉 생명주기가 존재한다. 정확하게는 컴포넌트의 생명주기가 존재한다고 해야한다. React 내에서 컴포넌트는 생성, 수정, 제거의 과정을 거치도록 설계되었다.

우리가 Lifecycle에 대해 다루는 이유는 당연히 컴포넌트을 명확하게 통제할 수 있기 때문이다. 또한, React를 하면서 반드시 사용하는 Hook에 대한 이해도 더 직관적으로 할 수 있다.

Lifecycle의 분류

Lifecycle은 크게 세 가지로 나눌 수 있다.

• 생성될 때 (마운팅)
• 업데이트 할 때 (업데이팅)
• 제거 할 때 (언마운팅)

마운트

컴포넌트가 DOM에 생성되기 전까지의 Lifecycle 이벤트 들이다.

consturctor(props)

class의 생성자를 의미한다. class가 생성될 때 한 번 호출되며, 컴포넌트의 state 설정이 필요한 경우 constructor에서 진행한다.

class MyComponent extends React.Component {
    constructor(props) {
        super(props) // 상속 받을 경우 가장 먼저 와야함

        /* 1. state 초기화 */
        this.state = {
            // ...
        }

        /* 2. 인스턴스에 이벤트 메서드 바인딩 */
        this.onClick = this.onClick(this)
    }

    onClick() {
        console.log(this)
    }
}

export default MyComponent

static getDerivedStateFromProps(props, state)

최초 생성 시와 업데이트 시 사용되는 메서드이며, static 이기 때문에 this를 사용할 수 없다.

렌더링될 때 매번 실행되므로 유의하여 컴포넌트를 작성해야 한다.

이 메서드는 props에 의해 state가 변경되어야 할 경우인데, 드물게 사용한다고 한다. 이 Lifecycle 이벤트를 사용하는 경우라면 다음과 같은 경우인지 확인하고, 다른 대안으로 작성하는 것을 권장한다.

render()

모든 컴포넌트가 반드시 구현해야하는 메서드로 return 값으로 다음 중 하나를 반환해야 한다.

• React element: JSX 문법으로 작성된 메서드
• 배열과 Fragment: 여러개의 React element를 반환
• Portal: 루트 노드 외 별도의 DOM 트리에 자식 element를 렌더링
• 문자열 및 숫자: 텍스트 노드로서 렌더링
• Boolean 또는 null

componentDidMount()

컴포넌트가 DOM 트리에 마운트 된 이후 실행된다. 외부에서 데이터를 불러오기 적절한 위치이며, 데이터에 대한 구독도 설정하기 적절한 위치이다.

업데이트

컴포넌트가 생성되고, props 또는 state가 업데이트될 때 발생한다.

shouldComponentUpdate(nextProps, nextState)

React는 props 및 state가 변경될 때마다 render 함수를 실행하는 것을 기본으로 하고 있다. 이 메서드는 boolean을 return하는데 값에 따라 결과가 나뉜다.

• true일 때: 리렌더링
• false일 때: 리렌더링되지 않음 (render(), componentDidUpdate() 함수가 호출되지 않음)

값에 따라 리렌더링되지 않는 경우도 있기 때문에 성능최적화가 필요한 경우에 사용한다.

getSnapshotBeforeUpdate(prevProps, prevState)

가장 마지막으로 렌더링 된 결과가 DOM에 반영되었을 때 호출된다. 채팅화면의 Scroll 위치 조정할 때처럼 DOM 업데이트 이후 결정된 화면에 대한 조작이 필요할 때 사용한다. 여기서 return 되는 값은 componentDidUpdate의 세번째 인자로 전달된다.

componentDidUpdate(prevProps, prevState, snapshot)

최초 렌더링시에는 호출되지 않고, 업데이트가 일어난 직후에 발생하는 이벤트이다. DOM 조작이나 이전 props와 비교하여 네트워크 요청을 보낼지 결정하기에 좋은 위치이다.

언마운트

컴포넌트가 DOM에서 제거(UnMounting) 될 때 발생한다.

componentWillMount

컴포넌트가 DOM에서 제거되기 직전에 호출되는 이벤트이다. 여기서는 구독해제, 네트워크 요청 취소 등 메모리 누수 방지에 대한 처리를 진행한다.

Reference

React, State and Lifecycle, https://ko.legacy.reactjs.org/docs/state-and-lifecycle.html veloport, LifeCycle Method, https://react.vlpt.us/basic/25-lifecycle.html

개발을 하다보면 한번쯤은 듣는 개념이다. 그때마다 매번 의미를 찾아보고 이해해보려하지만, 항상 잊어리는 녀석이라 이번에 제대로 정리해보려고 한다.

깊게 알아보기 전에 우선 단어로 접근해보자.

‘REST’라는 단어에 “~가득한, 아주 ~하는” 등의 의미를 나타내는 ‘ful’이라는 접미사가 붙은 형태이다.

해석하면 ‘아주 REST한 API’가 된다. 좀 더 알기 쉽게 의역하자면, REST의 원칙을 잘 따르는 API라는 의미이다.

결론적으로 REST를 이해하면 RESTful API를 이해할 수 있다.

REST

REST(Representational State Transfer)란 월드 와이드 웹(WWW)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. … 엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음이다.

출처: https://ko.wikipedia.org/wiki/REST

단순하게 말하자면 네트워크 아키텍처의 한 종류이다.

“Representational State Transfer”의 약자로 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.

즉, 자원의 표현에 의한 상태를 송수신하는 모든 행위들을 정의하는 것이다. 여기에서 “자원”, “표현”, “행위”는 REST를 구성하는 요소들을 의미한다.

REST의 구성 요소

1. 자원(Resource): URI
   • 모든 자원에는 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
   • 자원을 구별하는 ID는 ‘/groups/:group_id’와 같은 HTTP URI 이다.
   • Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
2. 행위(Verb): HTTP Method
   • HTTP 프로토콜의 Method를 사용한다.
   • HTTP 프로토콜은 GET, POST, PUT, DELETE와 같은 Method를 제공한다.
3. 표현(Representation of Resource)
   • Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다.
   • REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있다.
   • JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적이다.

위 세 가지 요소로 REST를 구체적으로 정의하면 다음과 같다.

HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.

JSON, XML 등의 표현으로 서버에 저장된 자원은 HTTP URI를 통해 조작할 수 있고, 해당 자원을 조작하는 행위는 HTTP Method로 정의된다는 것이다.

REST의 원칙

RESTful API를 이해하는데 구성 요소만큼 중요한 것이 원칙이다.

• Server-Client(클라이언트/서버 구조)
  • 자원이 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트가 된다.
    • REST 서버: API를 제공하고, 비즈니스 로직 처리 및 저장을 책임진다.
    • 클라이언트: 사용자 인증이나 콘텍스트 등을 직접 관리하고 책임진다.
• Uniform Interface(인터페이스 일관성)
  • URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
  • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
• Stateless(무상태)
  • 각 요청 간 클라이언트의 콘텍스트가 서버에 저장되어서는 안 된다.
  • 서버는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.
• Cacheable(캐시 처리 가능)
  • WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다.
• Layered Syste(계층화)
  • 클라이언트는 REST API 서버만 호출한다.
    • 클라이언트는 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없다.
  • REST 서버는 다중 계층으로 구성될 수 있다.
    • API Server는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있다.
• Code on demaned (optional)
  • 서버로부터 스크립트를 받아서 클라이언트에서 실행한다.

REST API, RESTful API는 “자원, 표현, 행위”들이 포함되고, 해당 원칙들을 충족하는 API인 것이다.

그럼, REST는 어떤 이유로 고안 되었을까?

그 이유는 다양한 클라이언트들의 등장으로 인한 애플리케이션 분리 및 통합을 위해서 였다.

서버 프로그램은 크롬, 엣지, 사파리 등 여러 종류의 브라우저에 더해 각기 다른 아키텍쳐로 구성된 모바일 디바이스를 대응할 필요가 있어졌다.

이러한 멀티 플롯폼에 대한 대응을 위해서 클라이언트/서버 간 사이에 설계된 아키텍쳐가 필요했고, REST에 수요가 증가한 것이다.

그럼 이러한 REST를 기반으로 고안된 REST API란 어떤 것일까?

REST API

API란 뭘까?

API는 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘입니다. … Application Programming Interface의 줄임말로, API의 맥락에서 애플리케이션이라는 단어는 고유한 기능을 가진 모든 소프트웨어를 나타내며, 인터페이스는 두 애플리게이션 간의 서비스 계약이라고 할 수 있습니다. 이 계약은 요청과 응답을 사용하여 두 애플리케이션이 서로 통신하는 방법을 정의합니다.

출처: https://aws.amazon.com/ko/what-is/api/

REST API는 REST 기반으로 구현된 서비스 API라는 의미이며, API의 정의에 의하면 클라이언트와 서버가 REST의 원칙이 따라 서로 통신하는 방법을 정의한 것이라고 할 수 있다.

REST API 기본 설계 규칙

REST API 설계 시 가장 중요한 항목은 다음 2가지로 요약할 수 있다.

1. URI는 정보의 자원을 표현해야 한다.
2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

이것만으로는 어려우니 구체적으로 알아보자.

URI는 정보의 자원을 표현해야 한다. (리소스명은 동사보다 명사를 사용)

GET /members/delete/1

위와 같은 방식은 REST를 제대로 적용하지 않은 URI이다. URI는 자원을 표현하는데 중점을 두어야 하며, delete와 같은 행위에 대한 표현이 들어가서는 안된다.

자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현

위의 잘못된 URI를 HTTP Method를 통해 수정해 보면

DELETE /members/1

다음과 같이 된다.

회원정보를 가져올 때는 GET, 회원 추가 할 때는 POST를 사용한다.

회원 정보 조회

GET /members/show/1 (x)
GET /members/1 (o)

회원 추가

GET /members/insert/2 (x) - GET 메서드는 리소스 생성에 맞지 않는다.
POST /members/2 (o)

[참고] HTTP Method는 다음과 같은 역할을 수행한다.

위와 같은 방식으로 URI은 자원, HTTP Method는 행위만을 정의하는 것이 REST API의 기본 규칙이다.

REST API 설계 규칙

1. 슬래시 구분자(/)는 계층 관계를 나타내는데 사용한다.

    http://restapi.example.com/houses/apartments

2. URI 마지막 문자로 슬래시(/)를 포함하지 않는다.

   • URI에 포함하는 모든 글자는 리소스의 유일한 식별자로 사용되어야 한다. (URI가 다르면 리소스도 달라져야 함)

   • 혼동 방지를 위해 경로 마지막에는 슬래시(/)를 사용하지 않는다.

     http://restapi.example.com/houses/apartments/ (x)
     http://restapi.example.com/houses/apartments (o)

3. 하이픈(-)은 URI 가독성을 높이는데 사용한다.

4. 밑줄(_)은 URI에 사용하지 않는다.

5. URI 경로에는 소문자가 적합하다.

   • RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문이다.

6. 파일확장자는 URI에 포함하지 않는다.

   • REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다.

   • 대신 Accept header를 사용한다.

     http://restapi.example.com/members/soccer/345/photo.jpg (x)
     
     GET /member/soccer/345/photo HTTP/1.1 Host:restapi.example.com Accpet: image/jpg (o)

7. 리소스 간에는 연관 관계가 있는 경우

   • /리소스명/리소스ID/관계가 있는 다른 리소스명

     GET : /users/{userid}/devices # (일반적으로 소유 'has'의 관계를 표현할 때)

[참고] 응답상태코드

• 1xx: 전송 프로토콜 수준의 정보 교환

• 2xx: 클라이언트 요청이 성공적으로 수행됨
• 3xx: 클라이언트는 요청을 완료하기 위해 추가적인 행동을 취해야 함
• 4xx: 클라이언트의 잘못된 요청
• 5xx: 서버쪽 오류로 인한 상태코드

RESTful API

그럼 RESTful API란 뭘까?

‘RESTful’은 아까 처음에 정의하였듯이 ‘아주 REST한’이라는 의미이다.

REST API에 확장된 개념으로 보다 REST를 REST 답게 쓰기 위한 개념이다.

RESTful API의 목적

‘이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것’

RESTful한 API를 구현하는 근본적인 목적은 성능이 아닌 이해도 및 호환성을 높이는 것이다. 따라서, 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.

RESTful 하지 못한 경우

• Ex1) CRUD 기능을 모두 POST로만 처리하는 API
• Ex2) route에 resource, id 외의 정보가 들어가는 경우(/students/updateName)

글을 마치며

정작 중요한 RESTful API는 많이 다루지 않았는데, 그것은 본질적으로 REST API와 다르지 않기 때문이다. 그럼에도 RESTful한 것이 중요한 이유는 직관적인 소통을 위함에 있다. REST는 결국 좋은 소통을 위해 고안된 개념이다. REST를 RESTful하지 못하게 사용하는 것, 즉, 어렵게 REST를 사용하는 것은 복잡하게 소통하는 것이므로 REST를 사용하지 않는 것이나 다름없다. 그렇기 때문에 RESTful을 개념자체를 알고 이해하는 것이 중요하다. RESTful API이야말로 서버에서 쉽게 데이터에 액세스할 수 있는 웹 애플리케이션을 구축하는 가장 좋은 방법이기 때문이다.

Reference

Wikipedia, REST, https://ko.wikipedia.org/wiki/REST heejeong Kwon, [Network] REST란, REST API란, RESTful이란?, https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html 팬도라, Jersey를 활용한 RESTful 이해하기, https://judo0179.tistory.com/13 The Postman Team, ‘What Is a REST API? Examples, Uses, and Challenges’, https://blog.postman.com/rest-api-examples/ aws, 애플리케이션 프로그래밍 인터페이스(API)란 무엇인가요?, https://aws.amazon.com/ko/what-is/api/

패러다임이란 한 시대의 사람들의 견해나 사고를 근본적으로 규정하고 있는 테두리로서의 인식의 체계, 또는 사물에 대한 이론적인 틀이나 체계를 의미하는 개념이다.

출처: https://ko.wikipedia.org/wiki/패러다임

프로그래밍 패러다임이란 말 그대로 프로그래밍의 패러다임 형태를 정의하는 것이다. 이것은 프로그래머에게 프로그래밍의 관점을 갖게 해 주고, 결정하는 역할을 한다. 각각의 프로그래밍 언어들은 서로 다른 프로그래밍 패러다임을 지원하며, 다수의 패러다임을 지원하는 경우도 존재한다.

프로그래밍 패러다임은 크게 두가지 종류로 나뉜다.

• 절차형 프로그래밍(Imperative programming)
  • 절차적 프로그래밍(Procedural programming)
  • 객체지향적 프로그래밍(Object-oriented programming)객체 기반의 패러다임
• 선언형 프로그래밍(Declarative programming)
  • 함수형 프로그래밍(Functional programming)
  • 논리형 프로그래밍(Logic programming)
  • 리액티브 프로그래밍(Reactive programming)

Functional Programming

함수형 프로그래밍은 자료 처리를 수학적 함수의 계산으로 취급하고 상태와 가변 데이터를 멀리하는 프로그래밍 패러다임의 하나이다. 함수의 응용을 강조하며, 계산가능성, 결정문제, 함수정의, 함수응용과 재귀를 연구하기 위해 개발된 형식체계인 람다 대수에 근간을 두고 있다.

출처: https://ko.wikipedia.org/wiki/함수형_프로그래밍

함수형 프로그래밍이란 순수 함수(pure function)를 조합하고 공유 상태(shared state), 변경 가능한 데이터(mutable data) 및 부작용(side-effects)을 피하여 소프트웨어를 만드는 프로세스다.

개념이 좀 어려워 보이는데 하나씩 풀어서 해석해보자.

순수 함수(Pure functions)

순수 함수는 다음과 같다

• 같은 입력이 주어지면, 항상 같은 출력을 반환
• Side Effect가 없음. (외부 상태를 변경하지 않음)

입력에만 의존하고 외부의 상태를 변경하지 않으며, 동일한 입력에 대해 항상 동일한 출력을 반환한다.

즉, 이름 그대로 정해진 값만 순수하게 반환할 뿐 그 이외의 어떤 것도 변경하지 않는 함수를 말한다.

function add(a, b) {
    return a + b;
}

// 동일한 input에 해당되는 동일한 output을 반환
console.log(add(3, 5)); // output: 8
console.log(add(3, 5)); // output: 8

공유 상태(Shared state)와 불변성(Immutability)

함수형 프로그래밍에서는 공유 상태를 피하고, 데이터의 불변성을 유지한다. 이는 한 번 생성된 데이터는 변경되지 않으며, 새로운 데이터를 생성할 때 기존 데이터를 변경하는 대신 새로운 데이터를 반환한다.

이렇게 말해도 어려우니까 좀 더 쉽게 설명해보겠다.

값에 의한 호출(Call by value) vs 참조에 의한 호출(Call by reference)

프로그램이 메모리에 저장된 값을 호출하는 방식은 두 가지가 있다.

• 값에 의한 호출: 메모리에 저장된 값만을 호출하는 방식
• 참조에 의한 호출: 메모리에 할당된 공간 즉, 주소를 참조하는 방식

‘값에 의한 호출’은 저장된 값을 복사하여 가져오기 때문에 실제 값에는 영향이 가지 않지만, ‘참조에 의한 호출’은 값이 저장된 메모리 주소를 가져와 실제 값에 영향을 미친다.

함수형 프로그래밍에서는 두 가지 방식 중 ‘값에 의한 호출’을 사용한다.

한가지 예를 들어 보겠다.

function foo(str) {
    return str.substring(0, 2);
}

foo 함수는 문자열의 2번째 글자까지 반환해주는 함수이다. 즉, 문자열을 수정하여 반환해준다.

const str = "Hello, World";

foo(str); // output: He

foo 함수는 ‘str’ 변수를 수정하여 ‘He’라는 값을 반환하였다. 이제, 기존의 str을 출력해보자.

console.log(foo(str)); // output: He
console.log(str); // output: Hello, World

처음 할당한 값이 그대로 반환된 것을 볼 수 있다.

함수형 프로그래밍에서는 값에 의한 호출을 사용하기 때문에 기존에 값이 그대로 저장된 것을 볼 수 있다. 만약, 참조에 의한 호출을 사용하였다면 값이 ‘He’로 변경되었겠지만, 그렇지 않기 때문에 변경되지 않았다.

이제 아까했던 말을 다시 보자.

함수형 프로그래밍에서는 공유 상태를 피하고, 불변성을 유지한다고 했었다.

• 공유 상태를 피하다 → 공유하지 않는다 → 함수와 값을 공유하지 않는다
• 불변성을 유지한다 → 값의 변경이 없다

함수는 값을 공유하지 않기 때문에 실제 값에 영향을 미치지 않고, 이것은 값을 변경하지 않는다는 말과 같다. 즉, 한번 생성된 데이터는 변경되지 않으며, 새로운 데이터가 생성될 때는 기존의 데이터를 유지한 채 새로운 데이터를 반환한다.

부작용(Side Effects)

흔히 아는 그 말과 비슷하다. 말 그대로 어떤 것이 기대하는 효과 외에 나타나는 부수적인 효과를 의미한다. 보다 프로그래밍적으로 이야기하자면 부작용은 함수가 외부의 상태를 변경하거나 다른 부수 효과를 발생시키는 것을 말한다.

순수 함수에 특징에서 말했던 부작용이 없다는 의미는 외부의 상태를 변경하는 등의 다른 부수 효과를 발생시키지 않아 예측된 결과만을 반환한다는 의미이다. 함수형 프로그래밍에서는 이러한 부작용을 최소화하여 코드를 예측 가능하고 안정적으로 유지한다.

이를 보다 깊게 이해하기 위해서는 클로저라는 개념을 알아야 한다.

클로저(Closure)

“A closure is the combination of a function and the lexical environment within which that function was declared.”

클로저는 함수와 그 함수가 선언됐을 때의 렉시컬 환경(Lexical environment)과의 조합이다.

출처: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures

위에서 이야기 하는 렉시컬 환경은 함수가 정의된 스코프에서 사용할 수 있는 변수들의 집합을 나타낸다.

말이 좀 어려운데 쉽게 이야기 하자면 함수를 정의할 때 그 함수 내에서 사용할 수 있는 변수들의 집합을 말하는 것이다.

흔히 이야기 하는 전역 변수, 지역 변수가 위에서 이야기 하는 내용과 이어진다.

let globalNum = 1;

function scope1 () {
    let num = 2;

    console.log(num, globalNum);
}

function scope2 () {
    let num = 3;

    console.log(num, globalNum);

    num++;
    globalNum++;
}

scope1(); // output: 2, 1
scope2(); // output: 3, 1
scope1(); // output: 2, 2

scope1과 scope2는 사용할 수 있는 변수가 각각 정해져 있다.

• globalNum은 함수 밖에서 선언되어 모든 함수가 사용할 수 있다. 흔히 이것을 전역 변수라고 한다.
• num은 각각의 함수 내에서 선언되었기 때문에 선언된 함수 내에서만 사용할 수 있다. 흔히 이것을 지역 변수라고 한다.

지역 변수인 num들은 해당 함수 안에서만 영향을 미치지만, 전역 변수인 globalNum은 함수 외부적으로 영향을 미치는 것을 볼 수 있다.

함수들이 해당 변수들을 사용할 수 있는 이유는 클로저가 해당 변수들을 사용할 수 있는 범위를 지정하고 기억하였기 때문이다.
그렇다면 클로저와 부작용이 어떤 관계가 있는 것일까?

클로저는 함수형 프로그래밍에서 부작용을 줄일 수 있는 도구로 작용한다. 클로저가 함수가 영향을 미칠 수 있는 범위를 지정하여 외부로의 주는 영향을 차단하기 때문이다. 또한, 클로저가 생성됨을 알고 있기 때문에 우리는 함수가 미치는 영향을 예측할 수 있다.

즉, 클로저를 통해 부작용을 예측할 수 있고, 최소화할 수 있는 것이다.

• 함수의 테스트가 쉽고 가독성이 좋음
• 함수들 간의 결합, 조합이 간결해지며, 익명 함수를 사용할 수 있음
• 코드 재사용성이 높음
• 깔끔하고 유지보수가 용이함

Reference

Wikipedia, Programming paradigm, https://en.wikipedia.org/wiki/Programming_paradigm

Wikipedia, 함수형 프로그래밍, https://ko.wikipedia.org/wiki/함수형_프로그래밍

MDN Web docs, Closure, https://developer.mozilla.org/ko/docs/Web/JavaScript/Closures

Dico’s_footPrint.log, [Javascript] Functional Programming(함수형 프로그래밍), https://velog.io/@grinding_hannah/JavaScript-Functional-Programming함수형-프로그래밍

지난 시간에 공부했듯이 Git으로 프로젝트를 관리할 때는 브랜치로 관리한다. 브랜치를 활용하여 손쉽게 백업하고 분할 작업이 가능하도록 하여, 보다 안전하고 효율적으로 작업할 수 있다.

그렇다고 무턱대고 브랜치를 생성하다보면 각 브랜치의 역할을 구분하기가 불가능해지면서 작업이 난잡해지기 때문에 결국에는 대참사로 이어질 가능성이 있다.

우리는 이것을 방지하기 위해 생성할 브랜치의 역할을 미리 명시할 필요가 있다.

Git Workflow

Git Workflow는 브랜치를 사용하는 규칙들을 명시해둔 개념이며, 대표적으로 Git Flow, Github Flow, Gitlab Flow 가 있다.

Git Flow

가장 대표적인 브랜치 전략로 대규모 프로젝트에 적합하다.

5가지 종류의 브랜치로 관리된다.

• master(main): 제품으로 출시될 수 있는 브랜치
• develop: 다음 출시 버전을 개발하는 브랜치
• feature: 기능을 개발하는 브랜치
• release: 이번 출시 버전을 준비하는 브랜치
• hotfix: 출시 버전에서 발생한 버그를 수정하는 브랜치

master는 배포된 상태의 버전이 포함되어 있기 때문에 프로젝트의 원본이 저장된 브랜치라고 할 수 있다.

develop은 원본 파일을 수정하는 것은 위험하기 때문에 만들어진 복사본으로 실질적인 메인 브랜치 역할을 한다.

feature는 말그대로 기능을 개발하는 브랜치이다. 예를 들어, 로그인 기능을 추가하고 싶다고 한다면 ‘feature/login’ 이라고 생성하여 기능을 개발한다.

release는 develop에서 개발된 기능들을 출시하기 전에 테스트를 위해 사용되는 브랜치이다. QA 등을 release 브랜치에서 진행하고, 정상적으로 완료되면 master 브랜치에 merge된다.

hotfix는 치명적인 버그가 발생한 경우 빠르게 대응하기 위해 master 브랜치에서 생성하여 사용한다.

Git Flow는 Vincent Driessen이 2010년 블로그에 올린 A successful Git branching 이라는 글이 인기를 끌며 현재까지 가장 대중적으로 사용하고 있는 전략이다. 안정성과 신뢰성을 바탕으로 설계된 프로세스의 명확성 때문에 많은 프로젝트에서 사용 되었다. 하지만, 장점이 명확한 만큼 한계점도 명확하다.

Git Flow의 한계

Vincent Driessen이 해당 글을 올린지 10년이 지난 2020년에 포스팅 위에 반성의 글(Note of Reflection)을 적는다. 누군가가 블로그에 잘 요약해두어서 가져와 봤다.

Git-Flow는 등장하고 10년 넘게 표준처럼 자리잡고, 더 나아가 마치 만병통치약처럼 사용되었다. 현재는 Git으로 관리되는 인기있는 유형의 소프트웨어가 웹 어플리케이션으로 이동하고 있다. 웹 어플리케이션은 일반적으로 롤백되지 않고, 지속적으로 제공(Continuous Delivery)되므로 여러 버전의 소프트웨어를 지원할 필요가 없다.

웹 어플리케이션은 내가(Vincent Driessen) 10년전 블로그 글을 쓸때에는 염두해둔 소프트웨어 유형이 아니다. 팀이 소프트웨어를 지속적으로 제공한다면, Git Flow 대신 Github Flow와 같은 더 단순한 워크플로우를 채택할 것을 제안한다.

그러나 명시적으로 버전을 관리해야하는 소프트웨어를 개발한다면, 여전히 Git Flow가 적합할 수 있다.

간단하게 말해서 CI/CD 파이프라인에는 적합하지 않다는 의미이다. 명시적으로 버전을 관리해야 하는 오픈소스 라이브러리/프레임워크, 스마트폰 어플리케이션 등의 프로젝트에는 적합하지만, 웹 같이 단일 버전이 지속적으로 제공되어야 하는 프로젝트의 경우에는 병렬적으로 버전을 지원할 필요가 없기 때문에 비 효율적이라는 것이다. 그래서 그 경우에는 보다 단순한 workflow를 사용할 필요가 있다.

Github flow

Vincent Driessen이 언급한 Github Flow는 이름 그대로 Github 환경에서 사용하기 적합한 브랜치 전략이다.

2가지 종류의 브랜치로 운영되기 때문에 상당히 단순하다

• Master: 메인 브랜치로 모든 커밋이 빌드되어 있음
• Topic: 새로운 기능 개발과 버그 수정을 위한 브랜치

Git Flow 기준으로 develop, release는 없애고, feature, hotfix를 topic이라는 하나의 브랜치로 묶었다.

Master 브랜치

가장 큰 특징이자 Github Flow가 강제하는 유일한 사항은 Master 브랜치는 항상 Stable해야 한다는 것이다. Master의 모든 커밋은 언제 배포하든 문제 없어야 하고, 언제든 브랜치를 새로 만들어도 문제가 없어야 한다. 따라서, Master 브랜치의 모든 커밋은 빌드가 되고, 테스트를 통과해야한다.

Topic 브랜치

Topic 브랜치의 이름은 기능을 설명하는 명확한 이름으로 네이밍한다. 예를들어, user-content-cache-key, submodules-init-task 등과 같이 말이다.

또 다른 특징은 Topic 브랜치의 모든 커밋은 기능이 완성되지 않았더라도 꾸준히 Push 한다는 것이다. 이것은 곧 구성원끼리의 끊임없는 커뮤니케이션을 가능하게 해준다. 또한, 이것은 Github의 PR과 이어진다.

Pull Request

Github에는 PR(Pull Request)라는 기능이 존재한다. 브랜치끼리 비교하여 변경내역을 보여주는 기능이다. 개발자들은 개설된 PR에서 코드리뷰를 주고 받고, Merge여부를 결정한다. PR을 통해 자연스로운 코드 리뷰가 가능해진다.

GitLab Flow

단순하여 출동에 대처하기 힘든 Github Flow의 단점을 보완하기 위해 나온 전략이다.

4가지 종류의 브랜치로 운영된다.

• master: Git Flow의 develop와 동일한 역할로 개발 단계의 코드가 포함된 브랜치이다.
• feature: 특정한 기능을 구현하는 브랜치로, 구현이 완료되면, master 브랜치로 PR을 날린다.
• production: Git Flow의 master 브랜치와 동일한 역할로 배포될 코드가 포함된 브랜치이다.
• pre-production: 배포 전에 테스트를 위한 브랜치로, 정상적으로 완료되면 production과 master 브랜치로 PR을 날린다.

가장 큰 장점은 pre-production 브랜치로 테스트함으로써 안정성을 확보함과 동시에 내장된 CI/CD 파이프라인을 제공하여 배포를 자동화할 수 있다는 점이다.

안정성이 확보된 프로젝트에서는 Github Flow가 더 효율적이지만, 더 복잡하거나 큰 규모의 프로젝트에서 Github Flow보다 더 효율적이다.

Reference

나동호, 2017.08.30, 우린 Git-flow를 사용하고 있어요, https://techblog.woowahan.com/2553/

Vincent Driessen, 2020.03.05, A successful Git branching model, https://nvie.com/posts/a-successful-git-branching-model/

Hudi, 2022.08.03, Git 브랜치 전략 (feat. Git Flow, Github Flow), https://hudi.blog/git-branch-strategy/

Github, https://githubflow.github.io/

이전 장에서 언급하였듯이 이번 장에서는 branch라는 것을 다루어볼 것이다.

개발을 하다보면 코드를 여러 개로 복사하여 작업하여야 하는 경우가 생긴다. 예를 들어, 현재 배포된 서비스에서 새로운 기능을 추가하고 싶을 때, 원본 코드 위에서 작업을 하면 손상될 가능성이 있기 때문에 안전하게 복사본 위에서 작업을 한다. 이러한 경우가 많기 때문에 대부분의 DVCS는 이러한 기능을 제공하는데, Git의 branch 모델은 특히 강력한 기능을 제공한다.

branch 생성

$ git branch 브랜치명

새로운 branch를 생성하기 위해서는 branch라는 옵션 뒤에 브랜치명을 입력하면 된다.

테스트를 위해 파일을 하나 만들었다. 잘 작동하고 있는 웹페이지에 이쁜 스타일을 적용하고 싶다. 하지만 원본 파일 위에 수정하면 불안하기 때문에 branch를 하나 만들어서 작업할 것이다.

생성한 branch로 변경하고 싶으면 switch 옵션을 사용하면 된다.

$ git switch 브랜치명

현재 branch가 master에서 style로 잘 변경되었다. 이제 안전하게 작업할 수 있을 것 같다!

‘style’ branch에서 style.css 파일을 하나 만들고 커밋까지 해보았다.

이 상태에서 다시 ‘master’ branch로 이동하면 어떻게 될까?

놀랍게도 style.css 파일이 존재하지 않는다는 표시가 뜬다. 이렇게 branch는 작업 공간 자체를 분할 해주어서 쉽게 백업이 가능하도록 한다.

이쁘게 잘 수정된 것 같으니 이제 원본 프로젝트에 적용해보고 싶다. 그러기 위해선 원본 branch로 이동해야 한다.

$ git switch master

$ git merge 브랜치명

merge 옵션 뒤에 병합된 브랜치명을 입력하면 현재 브랜치에 병합된다.

master branch에도 style.css가 정상적으로 추가 되었다.

Conflict

merge할 때는 주의할 점이 있다. 바로 같은 부분을 편집하는 경우이다. 위의 경우 style.css라는 새로운 파일을 작업한 것이기 때문에 상관없지만, 같은 파일의 같은 라인을 편집한 경우 conflict가 발생한다.

직접 확인해보기 위해 index.html의 h1 안의 텍스트를 수정해보겠다.

이 상태에서 merge를 해보자

그러면 다음과 같이 h1부분에서 충돌이 일어났다고 표시가 된다. 컴퓨터는 어떤 것을 기준으로 merge 할지 판단할 수 없기 때문에 conflict에는 수동으로 수정을 해주어야 한다.

수정 이후에는 동일하게 git에 add, commit, push 해주면 된다.

Git은 가장 많이 사용되는 DVCS(분산 버전 관리 시스템)이다. 기존의 델타 방식 시스템과 다른 점은 데이터를 스냅샷의 스트림처럼 취급한다는 점이다. 변경 사항이 생길 경우 변경된 부분만 저장하는 것이 아닌 파일 시스템 전체를 저장한다. 이러한 스냅샷들이 모여서 시간의 흐름에 따라 변경된 내용을 추적하는 방식으로 데이터를 관리 한다.

Git의 장점은 다음과 같다.

로컬 명령

거의 모든 명령이 로컬 파일과 데이터만 사용하기 때문에 네트워크가 없는 환경에서도 작업이 가능하다. 히스토리 조회나 커밋을 할 때도 로컬 파일 내에서 할 수 있기 때문에 네트워크가 없는 환경에서도 순조롭게 작업이 가능하다.

병렬 개발

위의 장점에서 이어지는 항목인데, 네트워크 환경이 없는 곳에서 개발이 가능한 이유는 병렬 개발이 가능하기 때문이다. Git에는 브랜치라는 기능이 존재하는데, 이를 활용하면 각각의 독립적인 개발 라인을 하나의 프로그램으로 병합하는 것이 가능하다.

시작하기

Github

Git을 사용하기 위해서는 로컬 파일을 저장하는 저장소가 필요하다. 이는 ‘Github’이라는 서비스가 수행하는데, 이를 사용하기 위해서는 Github.com에 먼저 가입하여야 한다.

GitHub: Let’s build from here

위 링크를 통해 Github에 가입하면 다음과 같은 화면이 나온다.

Github을 통해 프로젝트를 관리하기 위해서는 우선 각 프로젝트를 관리할 repository(저장소)가 필요하다. 좌측의 New 버튼을 누르면 새로운 repository를 만들 수 있다.

그러면 이러한 화면이 나오는데, 여기서는 이름과 공개 여부만 설정해주면 된다. 그 아래 나머지는 추후에 설정이 가능하기 때문에 지금은 신경쓰지말자

repository를 생성하면 다음과 같은 화면이 나온다.

우리는 여기서 가장 위에 ‘.git’으로 끝나는 주소만 잘 기억하고 있으면 된다.

Git 설치

Git - Downloads

위 링크로 들어가면 Git을 다운로드 할 수 있게 안내해준다.

Windows

Download for Windows

MacOS

Download for Mac

$ brew install git

Mac은 homebrew로 설치하면 된다.

Linux/Unix

Download for Linux/Unix

Linux/Unix는 버전에 맞는 명령어를 입력하여 설치한다.

Git config

본격적으로 Git을 사용하기 이전에 가장 먼저해야 될 것이다. 설치한 Git에 Github Account 정보를 등록하여야 서버 저장소와 연동이 가능하다. 최초 한번만 설정하면 이후 Git을 사용할 때 매번 지정하지 않아도 된다.

$ git config --global user.name "User Name"
$ git config --global user.email "Example@example.com"

이후 아래 명령어로 잘 등록되었는지 확인할 수 있다.

$ git config --list

Git init

config가 완료되었다면 아까 만들어둔 repository에 파일을 업로드할 준비를 할 순서이다.

먼저, 이용할 로컬 저장소로 이동한다. 아까 만든 repository에 업로드 될 파일들이 존재하는 곳이다.

이동하였다면 다음 명령어를 입력해준다.

$ git init

git init은 해당 디렉토리를 로컬 저장소로 지정해주는 명령어다. Git이 해당 디렉토리를 지켜보면서, 내부 파일들의 추가, 수정, 삭제 등을 감지할 수 있게 된다.

다음은 리모트 저장소를 연결하여야 한다.

$ git remote add origin repository-address

repository-address부분에 아까 기억하라고 했던 그 주소(~.git)를 입력하면 된다.

Git add

다음은 로컬 저장소 안의 파일들을 스테이지 위에 올릴 차례이다.

여기서 스테이지라는 용어가 나오는데, 이를 알기 위해서는 Git에서의 세 가지 상태를 먼저 알아야 한다.

Git의 세 가지 상태

💡 Git의 세 가지 상태 (출처: https://git-scm.com/book/ko/v2/시작하기-Git-기초)

Git은 파일을 Commited, Modified, Staged 이렇게 세 가지 상태로 관리한다.

• Committed란 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미한다.
• Modified는 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않는 것을 의미한다.
• Staged란 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태를 의미한다.

Git의 공식 사이트에서는 세 가지만 언급하고 있지만, 좀 더 명확하게 이해하기 위해서는 unmodified 상태를 추가하여 네 가지 상태로 이해하는 것이 좋다. 로컬 저장소에서 파일이 관리되는 순서는 다음과 같다.

1. Working Directory에 존재하는 파일을 수정 (unmodified → modified)
2. 수정된 파일을 스테이징하여 Staging Area에 올림 (modified → staged)
3. 스테이징한 파일들을 커밋하여 Repository에 기록함 (staged → commited)

위에서 스테이지 위에 올린다는 의미는 수정된 파일 즉, modified 상태인 파일을 Staging Area에 올린다는 의미이다. 우리는 이것을 스테이징(staging)이라고 한다.

$ git add .

# or

$ git add 파일명

add 다음의 ‘.’은 모든 파일을 의미한다. 특정 파일만 스테이지 위에 올리고 싶으면 ‘.’ 위치에 해당 파일명을 적으면 된다.

Git Commit

드디어 커밋을 해볼 차례이다!

커밋이란 수정되기 전 파일로부터 수정된 후 파일이 되기까지의 변경 이력을 기록해 놓는 것이라고 할 수 있다.

위에서 언급했듯이 staged 상태인 파일들을 커밋하면 commited 상태로 변경되며, repository에 기록된다.

-m 이라는 옵션을 사용하면 커밋 메시지를 적을 수 있는데, 여기에 자신이 어떤 파일을 어떻게 수정했는지 기록할 수 있다.

$ git commit -m "커밋 메시지"

로컬에서 그동안의 커밋 내역들을 보고 싶으면 다음 명령어로 확인하면된다.

$ git log

Git Push

커밋된 파일들은 리모트 저장소에 업로드할 수 있다.

# git push (리모트 저장소 별칭) (브랜치명)
$ git push origin master

마지막에 브랜치명은 다음 파트에 좀 더 자세하게 설명하겠지만, 일반적으로 처음 생성하면 master 또는 main 이라는 이름으로 생성된다.

결과적으로 잘 업로드 된 것을 볼 수 있다.

Reference

Git, 1.3 시작하기 - Git 기초, https://git-scm.com/book/ko/v2/시작하기-Git-기초

‘버전 관리(Version Control)’는 파일 변경 사항을 시간에 따라 기록하고, 필요할 때 특정 버전을 다시 호출할 수 있는 시스템을 일컫는 말이다.

간단하게 설명하자면 동일한 정보에 대해 여러 버전을 정의하고 관리하는 것을 의미한다.

소프트웨어 엔지니어링 내에서는 소프트웨어의 소스 코드의 변경 사항을 추적한 내역을 ‘버전 관리’라고 칭한다.

✏️ 형상 관리와 버전 관리

• 버전 관리(Version Control): 동일한 정보에 대한 여러 버전을 관리
• 형상 관리(Configuration Management): 소프트웨어의 변경사항을 체계적으로 관리

형상 관리는 버전 관리를 포함한 소프트웨어 프로젝트와 관련된 모든 변경 사항을 관리한다는 개념이다. 실무에서는 명확하게 구분되어 있지 않고 대체로 비슷한 의미로 사용된다고 한다.

버전 관리는 왜 필요한가?

버전 관리를 하는 이유는 다음과 같다.

1. 히스토리 추적 및 관리 소프트웨어의 이전 버전(이력)을 흔히 히스토리라고 한다. 버전 관리 시스템은 필요한 경우 특정 버전으로 쉽게 롤백할 수 있는 기능을 제공한다. 이를 통해 추가, 수정, 삭제 과정에서 발생할 수 있는 예측 불가능한 위험을 줄일 수 있어 대규모 개발 과정을 보다 안전하게 이끌어나갈 수 있다.

2. 백업 및 복구 히스토리 추적이 쉽다는 것은 곧 백업 및 복구가 쉽다는 말과 동일하다. 예상치 못한 이슈가 발생하였을 때 되돌릴 수 없는 경우 이미 검증된 버전으로의 롤백을 통해 안전하게 상태를 복구할 수 있다.

3. 협업에 필수적 프로젝트에서 버전 관리가 사용되는 가장 큰 이유이다. 대부분의 프로젝트는 여러 명의 개발자가 협업하는 형태로 진행된다. 각각의 개발자들은 할당된 일부 기능들을 따로따로 개발하고 하나의 버전으로 합치는 과정으로 이어진다. 버전 관리 시스템은 이러한 작업 환경을 보다 안전하고 효율적으로 만들어준다. 협업 시 흔히 발생하는 충돌을 방지할 수 있고, 이 충돌을 쉽게 해소할 수 있으며 다른 개발자의 작업 내역을 쉽게 확인할 수도 있다.

버전 관리 시스템

1. 로컬 버전 관리 로컬에서 버전을 관리하기 위해 많은 사람이 디렉토리로 파일을 복사하는 방법을 사용한다. 매우 간단하기 때문에 자주 사용하지만, 실수로 작업하던 디렉토리를 삭제하거나 잘못 수정, 복사할 수 있는 리스크가 있다. 이러한 이유로 오래전에 로컬 VCS라는 것을 만들었다. 이 VCS는 간단한 데이터베이스를 사용해서 파일의 변경 정보를 관리했다.

2. 중앙집중식 버전 관리(CVCS) 로컬 VCS는 1인 개발 시엔 용이하지만 다른 개발자와 함께 작업할 때 사용하기엔 한계가 있다. 그래서 이를 위해 개발된 것이 CVCS(중앙집중식 VCS)이다. CVS, Subversion, Perforce 같은 시스템은 파일을 관리하는 서버가 별도로 있고, 클라이언트가 중앙 서버에서 파일을 받아서 사용(Checkout)하는 방식으로 이루어진다. 이러한 방식은 누가 무엇을 하고 있는지 알 수 있기 때문에 관리자가 프로젝트를 꼼꼼하게 관리할 수 있다는 장점이 있다. 하지만, 중앙 서버에서 문제가 발생하는 경우에는 프로젝트 전체가 중단되고, 백업할 수 있는 방법이 없기 때문에 최악의 경우 모든 히스토리를 잃게 되는 치명적인 단점이 존재한다.

3. 분산 버전 관리 시스템 이런 치명적인 단점을 보완하기 위해 고안된 시스템이 DVCS(분산 버전 관리 시스템)이다. Git, Mecurial, Bazaar, Darcs가 대표적인데, 이들은 저장소를 히스토리와 더불어 전부 복제한다. clone이라고 불리우는 복제물로 백업이 가능하다. 또한, 대부분의 DVCS 환경에서는 리모트 저장소가 존재하기 때문에 사람들은 동시에 다양한 그룹과 다양한 방법으로 협업할 수 있다.

   
   

Reference

Git, 1.1 시작하기 - 버전 관리란?, https://git-scm.com/book/ko/v2/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-%EB%B2%84%EC%A0%84-%EA%B4%80%EB%A6%AC%EB%9E%80%3F

Configuration Management, https://en.wikipedia.org/wiki/Configuration_management