온라인 모각코 서비스를 만들고 싶어졌다

네부캠 멤버십을 진행하면서 프로젝트 주제를 정해야 했다. 팀원 네 명의 공통된 생각은 하나였다.

네부캠이 끝나도 우리가 계속 사용할 서비스를 만들자.

우리는 회의를 할 때 Figjam을 활용했고, 서로의 말에 엄청나게 적극적으로 리액션을 하며 회의를 하자는 규칙을 세웠다.

아래는 적극적인 회의의 흔적이다

회의를 3주 동안 매일 회의만 8~9시간 하니까, 갈수록 서로 예민해지는 경향이 있었다.

특히, 자신이 낸 아이디어가 reject 당할 때, 그 이유가 합리적이어도 가슴이 아픈 건 어쩔 수 없는 것 같다.

네 명 모두가 말한 ‘네부캠이 끝나도 우리가 계속 사용할 서비스’에 도달하는 건 생각보다 쉽지 않았다.

회의는 크리스마스 연휴 전까지, 큰 소득 없이 이어졌다.

다행히 크리스마스 연휴가 겹치면서 머리를 식힐 시간이 생겼고, 연휴가 지난 뒤 한 주 동안 서로의 생각을 천천히 맞춰가며 팀 분위기도 다시 정상화할 수 있었다.

그렇게 3주의 고난 끝에, 드디어 서로가 만족할 만한 프로젝트 주제가 나왔다. 정말 다 같이 기뻐했고, 그 이후의 기획은 놀라울 정도로 빠르게 진행됐다.

네이버 부스트캠프 과정을 거치며 밤을 정말 많이 샜다. 그때마다 Slack 한편에 켜져 있던 동료들의 ‘초록색 상태 표시줄’을 보며 묘한 위안과 힘을 얻곤 했다.

“나만 이 시간에 깨어 있는 게 아니구나.” 그 파란불 하나가 이상하게 큰 힘이 됐다.

그래서 생각했다.

‘개발자의 성취를 더 직관적으로 보여주고, 같은 공간에서 함께 몰입하고 있다는 감각을 전해줄 수 있는 서비스가 있으면 좋지 않을까?’

그걸 우리가 직접 만들어보기로 했다.

그렇게 탄생한 서비스가 “잔디 심고 갈래? (Commit Please)”다.

우리는 단순히 접속하는 것보다, 개인과 공동의 성취를 확인할 수 있으면 좋겠다고 생각했다.

그래서 포인트를 모아 펫을 뽑을 수도,

자신의 개별 Task를 Todo 리스트로 관리할 수도,

자신의 날짜별 활동을 추적할 수도,

자신의 활동으로 맵을 변화시킬 수도 있게 만들어보았다.

전세계 개발자들과도 함께하고 싶은 마음이 있어, 국제화를 지원하여 외국 커뮤니티에도 홍보하고 있다. 인도, 유럽 등에서도 가끔 와주신다 ㅎㅎ

아래는 감사하게도 서비스에 실제 접속해주신 사용자 분들의 모습이다.

잔디 심고 갈래? (Commit Please)에 접속해서 함께 서로의 원동력이 되어보는 건 어떨까?

비동기 처리 방식 이란 어떤 작업이 끝날 때까지 기다리지 않고, 다음 작업을 먼저 수행하는 방식을 말한다.

웹 개발에서의 비동기 처리

웹 개발에서 비동기 처리는 주로 서버와 통신하는 작업에서 사용된다.

이는 서버에 데이터를 요청하고 응답을 받는 데는 시간이 걸리기 때문이다.

만약 동기 방식으로 처리한다면, 서버에서 응답이 올 때까지 웹페이지가 멈춰버리게 될 것이다.

이 때문에 사용자는 아무것도 할 수 없는 상태가 된다.

하지만 비동기 방식을 사용하면, 서버에 데이터를 요청해놓고 웹페이지는 멈추지 않고 계속해서 사용자 입력을 받거나 다른 작업을 처리할 수 있다.

서버에서 응답이 오면, 그 때 받은 데이터를 이용해 화면을 업데이트하는 식으로 작동한다.

JS 비동기 처리 방식의 진화와 비교

세 가지 주요 방식이 존재한다.

1. Callback (초기 ~ 2015년)
2. Promise (2015년 ES6)
3. Async / Await (2017년 ES8)

1. Callback

가장 오래된 방식이며, 다른 함수의 인자로 전달되어 특정 작업이 완료된 후 호출되는 함수이다.

사용 예시

// 전형적인 콜백 패턴
function fetchUser(id, callback) {
    setTimeout(() => {
        const user = { id, name: '홍길동' };
        callback(null, user);
    }, 1000);
}

// 사용법
fetchUser(123, (error, user) => {
    if (error) {
        console.error('에러 발생:', error);
        return;
    }
    console.log('사용자:', user);
});

단점

콜백 지옥 이 발생할 수 있다.

콜백 지옥 이란 비동기 작업이 여러 개 중첩될 때, 콜백 함수가 계속해서 깊어지는 현상을 말한다.

코드가 마치 피라미드처럼 안쪽으로 들여쓰기되어 가독성이 매우 떨어지고, 유지보수가 어려워지는 문제를 일으킨다.

예를 들어, 세 개의 비동기 작업을 순서대로 실행해야 한다고 가정해보자.

1. 사용자 정보를 가져온다.
2. 가져온 사용자 정보로 게시물 목록을 가져온다.
3. 가져온 게시물 목록으로 댓글을 가져온다.

이러한 로직을 콜백 함수로 구현하면 다음과 같이 코드가 깊어진다.

// 첫 번째 비동기 함수: 사용자 정보 가져오기
getUser(userId, function(user) {
  // 두 번째 비동기 함수: 게시물 목록 가져오기
  getPosts(user.id, function(posts) {
    // 세 번째 비동기 함수: 댓글 가져오기
    getComments(posts[0].id, function(comments) {
      console.log(comments);
      // 작업이 더 많아지면 들여쓰기는 끝없이 깊어진다
    });
  });
});

이러한 문제를 해결하기 위해 Promise 와 async / await 가 등장하게 된다.

2. Promise

Promise는 기존의 콜백 함수 방식이 가진 '콜백 지옥' 문제를 해결하기 위해 도입되었다.

Promise는 비동기 작업의 최종 완료 또는 실패를 나타내는 객체이다.

즉, 미래에 어떤 결과를 반환하거나 오류가 발생할 것을 약속하는 객체라고 생각하면 된다.

Promise의 세 가지 상태

Promise는 비동기 작업의 진행 상황에 따라 다음 세 가지 상태 중 하나에 속합니다.

1. 대기(pending): 비동기 작업이 아직 완료되지 않은 초기 상태
2. 이행(fulfilled): 비동기 작업이 성공적으로 완료된 상태 (resolve 호출됨)
3. 거부(rejected): 비동기 작업이 실패한 상태 (reject 호출됨)

한 번 fulfilled 또는 rejected 상태가 되면, 다시 pending 상태로 돌아갈 수 없다.

사용 예시

// Promise 생성
const myPromise = new Promise((resolve, reject) => {
  // 비동기 작업 (예: 2초 후 완료)
  setTimeout(() => {
    const isSuccess = true;
    if (isSuccess) {
      resolve("작업 성공! 🎉"); // 성공 시 resolve 호출
    } else {
      reject("작업 실패! 😭"); // 실패 시 reject 호출
    }
  }, 2000);
});

// Promise 사용
myPromise
  .then((result) => {
    // 성공적으로 이행되면 실행
    console.log(result); // "작업 성공! 🎉" 출력
  })
  .catch((error) => {
    // 거부되면 실행
    console.error(error); // "작업 실패! 😭" 출력
  })
  .finally(() => {
    // 성공/실패 여부와 관계없이 항상 실행
    console.log("작업이 끝났습니다.");
  });

장점

• 가독성 향상: then()과 catch() 메서드를 체인처럼 연결하여 비동기 코드를 순차적으로 읽을 수 있게 해준다.
• 쉬운 오류 처리: catch() 메서드를 통해 비동기 작업 도중 발생하는 모든 오류를 한 곳에서 처리할 수 있어, 에러 핸들링이 간결해진다.

단점

Promise는 콜백 지옥 문제를 해결했지만, 여전히 몇 가지 문제점이 있다.

• 복잡한 체이닝
  • 여러 개의 Promise를 순차적으로 처리해야 할 때, .then() 메서드를 계속해서 연결하는 체이닝(Chaining) 방식은 코드를 읽기 어렵게 만들 수 있다.
  • 특히 체인이 길어지면 중간 에러 처리용 catch가 많이 생겨서 가독성이 급격하게 저하될 수 있다.
• 불필요한 중첩
  • 모든 .then() 블록 안에 새로운 코드를 작성해야 하므로, 여전히 어느 정도의 들여쓰기가 발생합니다. 콜백 지옥만큼 심하지는 않지만, 코드가 깊어질수록 가독성이 떨어질 수 있다.

Callback 에서의 시나리오로 예시 코드를 살펴보자.

1. 사용자 정보를 가져온다.
2. 가져온 사용자 정보로 게시물 목록을 가져온다.
3. 가져온 게시물 목록으로 댓글을 가져온다.

// 가상의 API 호출 함수 (Promise 반환)
function getUser(userId) {
console.log('1. 사용자 정보 가져오는 중...');
return new Promise(resolve => setTimeout(() => resolve({ id: userId, name: 'Alice', posts: [101, 102] }), 1000));
}

function getPosts(postIds) {
console.log('2. 게시물 목록 가져오는 중...');
return new Promise(resolve => setTimeout(() => resolve([{ id: 101, title: '첫 번째 글' }, { id: 102, title: '두 번째 글' }]), 1000));
}

function getComments(postId) {
console.log('3. 댓글 목록 가져오는 중...');
return new Promise(resolve => setTimeout(() => resolve(['댓글 1', '댓글 2']), 1000));
}

// Promise 체이닝 시작
getUser('user123')
.then(user => {
// 첫 번째 작업 결과(user)를 다음 작업에 전달
return getPosts(user.posts);
})
.then(posts => {
// 두 번째 작업 결과(posts)를 다음 작업에 전달
return getComments(posts[0].id);
})
.then(comments => {
// 최종 결과 출력
console.log('✅ 최종 댓글:', comments);
})
.catch(error => {
console.error('❌ 오류 발생:', error);
});

중첩 구조에서 가독성이 저하될 것이라는게 명확해 보인다.

3. async / await

async/await는 이러한 Promise의 단점을 해결하고 비동기 코드를 동기 코드처럼 읽고 쓸 수 있도록 만든 문법이다.

사용 예시

// 가상의 API 호출 함수 (Promise 반환)
function getUser(userId) {
  console.log('1. 사용자 정보 가져오는 중...');
  return new Promise(resolve => setTimeout(() => resolve({ id: userId, name: 'Alice', posts: [101, 102] }), 1000));
}

function getPosts(postIds) {
  console.log('2. 게시물 목록 가져오는 중...');
  return new Promise(resolve => setTimeout(() => resolve([{ id: 101, title: '첫 번째 글' }, { id: 102, title: '두 번째 글' }]), 1000));
}

function getComments(postId) {
  console.log('3. 댓글 목록 가져오는 중...');
  return new Promise(resolve => setTimeout(() => resolve(['댓글 1', '댓글 2']), 1000));
}

// async 함수 선언
async function fetchData() {
  try {
    // 1. await 키워드로 Promise가 완료될 때까지 기다림
    const user = await getUser('user123');

    // 2. await 키워드로 다음 Promise가 완료될 때까지 기다림
    const posts = await getPosts(user.posts);

    // 3. await 키워드로 마지막 Promise가 완료될 때까지 기다림
    const comments = await getComments(posts[0].id);

    // 4. 모든 작업이 끝난 후 최종 결과 출력
    console.log('✅ 최종 댓글:', comments);

  } catch (error) {
    // try-catch로 모든 에러를 한 곳에서 처리
    console.error('❌ 오류 발생:', error);
  }
}

// 함수 호출
fetchData();

장점

• 우수한 가독성
  • 비동기 코드가 동기 코드처럼 위에서 아래로 흐르는 직선적 구조처럼 보인다. (코드 읽는 순서와 실행 순서가 그대로 일치함)
  • Promise 의 경우, 체인이 길어질 수록 가독성이 좋지 않다는 단점이 있었고, 이를 보완

단점

1. 동시성(Concurrency) 처리 주의 필요

   await는 Promise가 완료될 때까지 코드가 일시 정지한다는 특징 때문에, 여러 비동기 작업을 동시에 병렬적으로 처리하는 데 불리하다.

   예를 들어, 서로 의존성이 없는 3개의 API를 호출하는 상황이라고 가정했을 때, await 를 다음과 같이 사용했다고 가정해보자.

    async function sequentialFetch() {
      const result1 = await fetch('api/data1'); // 1초 소요
      const result2 = await fetch('api/data2'); // 1초 소요
      const result3 = await fetch('api/data3'); // 1초 소요
      // 총 3초 소요
    }

   총 3초의 시간이 소요된다.

   해당 문제를 해결하기 위해, Promise.all() 을 사용하면 모든 fetch 가 한 번에 실행되도록 해서, 1초 의 시간이 소요되게 할 수 있다.

    async function parallelFetch() {
      // Promise.all()을 사용해 모든 fetch가 동시에 실행되도록 함
      const [result1, result2, result3] = await Promise.all([
        fetch('api/data1'),
        fetch('api/data2'),
        fetch('api/data3')
      ]);
      // 총 1초 소요
    }

   단, Promise.all()은 서로 의존성이 없는 여러 개의 비동기 작업을 동시에(병렬로) 실행할 때 사용하는 메서드이고, 의존성이 없는 관계에 적합하다.

   만약, A의 결과가 B에 필요한 경우, B는 A가 끝날 때까지 기다려야만 시작할 수 있다면, 이런 관계를 의존 관계라고 부른다.

   이 경우에는 병렬 처리가 불가능하며, await를 사용한 순차적 처리가 더 자연스럽고 적합하다.

   작업 간의 의존성이 있다면 async / await 를 통해 코드의 가독성을 확보하는 것이 좋고,

   작업 간의 의존성이 없다면 Promise.all() 을 사용해 모든 작업을 동시에 실행하는 것이 훨씬 빠르고 효율적이다.

2. 에러 처리 범위 제한

   try-catch는 해당 블록 내의 에러만 처리할 수 있어,

   비동기 작업이 여러 함수에 분산되어 있을 때 에러 처리가 복잡해질 수 있다.

     // 에러 처리가 복잡해지는 경우
      async function complexOperation() {
        try {
          const step1 = await operation1(); // 여기서 에러 발생 가능
        } catch (error) {
          // operation1의 에러만 처리
        }
   
        try {
          const step2 = await operation2(); // 여기서도 에러 발생 가능
        } catch (error) {
          // operation2의 에러만 처리
        }
      }

Map

• 키-값 쌍을 저장할 수 있는 내장 객체이다.
• 삽입 순서를 보장한다.

주요 메서드 및 속성

• set(key, value) : 구현해야하는 put() 과 동일
• get(key) : 구현해야하는 get() 과 동일
• has(key) : 구현해야하는 containsKey() 와 동일
• delete() : 구현해야하는 remove() 와 동일
• clear() : 구현해야하는 clear() 와 동일
• size : 구현해야하는 size() 와 동일

Map vs HashMap

JS 에서는 HashMap이 없기 때문에(Map이 곧 HashMap), Kotlin에서의 둘의 차이를 알아보자.

Map 은 인터페이스이고 따라서 내부 구현이 되어있지 않다. HashMap은 이 인터페이스를 기반으로 해시 함수 와 해시 테이블 을 사용해 내부 구현을 한 구현체 인 것이다.

그래서 사실 본질적인 차이 Map은 인터페이스이고 HashMap은 구현체이다 라는 것이다.

HashMap 동작 순서

1. hashCode() 메서드를 호출해 정수형 해시값을 얻는다.
2. 해당 해시값을 바탕으로 내부 해시 함수가 추가 연산(비트 마스킹, 재해싱) 등을 수행한다.
3. 2번 동작을 통해 해시 테이블 내 저장할 위치(버킷 인덱스) 를 결정한다.

해시함수

먼저, 해시 함수 란 키 -> 고정 길이의 숫자(해시값) 으로 변환하는 함수이다.

결국, 키를 해시 테이블의 인덱스로 빠르고 균등하게 변환 하는 것이 목적이다.

좋은 해시 함수의 조건

효율적이고 효과적인 해시 함수는 다음과 같은 조건을 만족해야 한다.

해시값이 모든 버킷에 고르게 분포되어야 각 버킷이 적절히 사용되어 충돌이 적고, 조회 및 삽입이 빠르다고 한다.

해시맵 구조상 버킷 사이즈

해시맵은 내부에 여러 개의 저장 공간을 가진 배열 을 가지고 있다.

그리고, 이 배열의 각 칸을 버킷 이라고 부른다.

예를 들어, hash = [ [], [] ] 은 2개의 빈 배열(버킷) 이 있고, 이 배열의 길이가 버킷 사이즈 를 의미한다.

구현 함수

• clear() : 전체 맵을 초기화한다.
• containsKey(String key) : 해당 키가 존재하는지 여부에 따라 boolean 결과를 리턴한다.
• get(String) : 해당 키와 매치되는 값을 찾아 리턴한다.
• isEmpty() : 비어있는 맵인지 Bool 결과를 리턴한다.
• keys() : 전체 키 목록을 [String] 배열로 리턴한다.
• put(String key, String value) 키-값을 추가한다.
• remove(String key) : 해당 키에 있는 값을 삭제한다.
• size() : 전체 아이템 개수를 리턴한다.

구현 전 고민

• 버킷 개수가 많을 수록, 충돌 확률이 감소할 텐데, 그렇다면 적절한 버킷 개수를 어떻게 구성할 것인가?
  • 초반에 적당한 버킷 개수로 시작하고, 재해싱을 통해 버킷 수를 늘리고 기존에 저장된 키들을 다시 해시해서 재배치해야 할 것같다.
• 초반에 적합한 버킷 개수는 몇일까?
  • Java, Kotlin의 초기 버킷 개수는 16개라고 한다. 기본적으로 버킷 개수는 2의 거듭제곱을 선호한다고 하는데,비트 연산 을 통해 성능을 비약적으로 개선할 수 있기 때문이라고 한다.
• 재해싱을 하기 위한 트리거 조건은 몇으로 설정할까?
  • 보통 loadFactor(부하율) = 엔트리 수 / 버킷 수 가 0.75 를 초과하면, 다음 엔트리를 추가할 때 재해싱 트리거를 발생시킨다고 한다. 이것을 채택하자.
  • 재해싱시 배열 크기는 2배로 증가시킬려고 한다.
• 기존 Map은 Map.get(key) 를 통해서, 값을 찾았다. 그런데 만약 hash = [ [1, 2], [4] ] 처럼 구조가 생겼다면, 어떻게 키 값과 비교하면서 값을 도출할 수 있는가?
  • hash [ [ [key, value], [key value] ] , [ ] ... ] 와 같이, key 값도 같이 저장해서 순회할 수 있도록 해보자.
• 버킷의 개수가 충분하다고 해도, 특정 버킷에 값이 쏠릴 수 있을 것이다. 어떻게하면 버킷에 균등하게 값을 삽입할 수 있을 것인가?
  • 좋은 해시 함수 설계가 필요.
  • 입력값이 조금만 달라도 완전히 다른 해시값이 나와야 함.
  • 패턴 있는 값들이 들어와도 특정 영역에 편중되지 않아야 함.
• 삭제가 많아서, 빈 버킷이 많이 생겼을 때도 재해싱이 필요할까?
  • Java에서는 삭제 후 자동 축소는 하지 않는다고 한다. 전부 삭제시에는 clear 을 사용하고, 애초에 엄청난 양의 메모리가 남을 만큼 삭제를 하지 않기 때문인 이유도 있다고 한다.
• 버킷의 크기가 2의 승수로 늘어나다보면 엄청나게 커질텐데, 최대 크기를 몇으로 제한해야할까?
  • Java에서는 1 << 30 으로 제한한다. (약 10억 7천만)
• JS의 Map에서 size는 메서드가 아니라 속성이지만, O(1) 시간에 접근가능하다. 어떻게 이게 가능할까?
  • size 를 클래스 멤버로 관리하여, put 을 할 때마다 1씩 늘려주면 된다.

구현 설정 값

JS의 Map 객체는 내부 구현 세부사항을 명확히 규정하지 않았기 때문에, Java 나 Kotlin 을 참고해서 작성했다.

• 버킷 초기 값 : 16
• 재해싱 트리거 : loadFactor(부하율) = 엔트리 수 / 버킷 수 > 0.75 초과시, 다음 엔트리 추가할 때.
• 재해싱시 배열 크기 증가분 : 2배
• 버킷 내부 구조 : [key value]
• 내부 요소 삭제시 재해싱 여부: X
• 버킷 최대 크기 : 1 << 30

메서드를 구현할 때 고려했던 사항들

hashCode(String key)

해시 값을 반환하는 함수이다.

자바에서의 hashCode 의 내부 구조를 살펴보니, 해시 계산에 소수를 쓴다는 것을 확인했다.

해시 계산에 소수를 쓰면 충돌 확률이 줄고, 분포가 균등해진다 는 이유라고 한다.

또한, Java의 창시자 중 한 명이 실험을 통해 31이 가장 적당하다고 판단했다고 한다.

그래서 나도 31 을 해시 계산에 사용했다.

그리고, Java의 int 는 32비트 정수인데, hashCode() 도 int 값을 반환하기 때문에, JS 에서의 64비트를 32비트 int화 할 필요가 있어서 | 0 연산도 추가했다가, 음수 값이 나오길래 >>> 로 대체했다.

getIndex(String key)

hashCode 를 통해 가져온 해시 값을 버킷 총 개수로 나눈 나머지를 통해 인덱스를 구하는 함수이다.

hash 값은 >>> 로 인해 반드시 양수이고, % 연산만 잘 사용하면 되므로 구현이 어렵지 않았다.

isNeedReHashing()

loadFactor(부하율) = 엔트리 수 / 버킷 수

loadFactor > 0.75 라면, 리해싱이 필요하다는 의미로, boolean 을 반환하도록 했다.

put(String key, String value)

기존 key가 있다면 대체를하고 기존 key에 해당하는 버킷 마지막에 삽입하면 문제없이 구현이 가능할거라 생각했다.

JS에서 제공하는 Map 의 Set 메서드는, 반환 값으로 this 를 전달하여 메서드 체이닝을 지원하도록 하기 때문에, 나도 이와 같이 this 를 반환하도록 했다.

remove(String key)

JS에서 제공하는 Map 의 delete 메서드는 반환 값으로 boolean 을 제공하기 때문에, 여기서도 이 형식을 따랐다.

clear()

clear 을 구현하면서 버킷 크기를 초기로 돌릴까, 아니면 리해싱 이후의 크기를 유지할까 고민이 많았다.

JS나 Java에서는 리해싱 이후의 크기를 유지하고, clear 한 뒤 다시 많은 데이터를 넣을 가능성이 있기에 돌리지 않는 것이 기본 세팅이라고 한다.

메서드 명세

구현 코드

class HashMap {
  #INITIAL_CAPACITY = 16;
  #MAX_BUCKET_SIZE = 1 << 30;
  #MAX_LOADFACTOR = 0.75;
  #RESIZE_FACTOR = 2;
  #INPUT_ERROR_MESSAGE = "[ERROR] 초기 값 형태는 [['key', 'value'], ['key', 'value']] 와 같은 형태여야 합니다.";

  #size;
  #bucketSize;
  #buckets;

  constructor(initialValue = []) {
    this.#bucketSize = this.#INITIAL_CAPACITY;
    this.#buckets = [];
    this.#size = 0;

    for (let i = 0; i < this.#bucketSize; i++) {
      this.#buckets[i] = [];
    }

    this.#validateInitialValue(initialValue);

    for (const [key, value] of initialValue) {
      this.put(key, value);
    }
  }

  /**
   * 전체 맵을 초기화한다.
   */
  clear() {
    this.#buckets = [];
    for (let i = 0; i < this.#bucketSize; i++) {
      this.#buckets[i] = [];
    }

    this.#size = 0;
  }

  /**
   * 해당 키가 존재하는지 여부에 따라 boolean 결과를 리턴한다.
   * @param {string} key
   */
  containsKey(key) {
    return this.get(key) !== undefined;
  }

  /**
   * 해당 키와 매치되는 값을 찾아 리턴한다.
   * @param {string} key
   */
  get(key) {
    const idx = this.#getIndex(key);
    const bucket = this.#buckets[idx];

    for (const pair of bucket) {
      if (pair[0] === key) return pair[1];
    }

    return undefined;
  }

  /**
   * 비어있는 맵인지 Bool 결과를 리턴한다.
   */
  isEmpty() {
    return this.size() === 0;
  }

  /**
   * 전체 키 목록을 [String] 배열로 리턴한다.
   */
  keys() {
    const keys = [];

    for (const bucket of this.#buckets) {
      for (const pair of bucket) {
        keys.push(pair[0]);
      }
    }

    return keys;
  }

  /**
   * 키-값을 추가한다.
   * @param {string} key
   * @param {string} value
   */
  put(key, value) {
    if (this.#isNeedReHashing()) {
      this.#rehash();
    }

    const idx = this.#getIndex(key);
    const bucket = this.#buckets[idx];

    for (const pair of bucket) {
      if (pair[0] === key) {
        pair[1] = value;
        return this;
      }
    }

    bucket.push([key, value]);
    this.#size++;

    return this;
  }

  /**
   * 해당 키에 있는 값을 삭제한다.
   * @param {string} key
   */
  remove(key) {
    const idx = this.#getIndex(key);
    const bucket = this.#buckets[idx];

    for (let i = 0; i < bucket.length; i++) {
      if (bucket[i][0] === key) {
        bucket.splice(i, 1);
        this.#size--;
        return true;
      }
    }

    return false;
  }

  /**
   * 전체 아이템 개수를 리턴한다.
   */
  size() {
    return this.#size;
  }

  /**
   * 배열 크기를 2배로 증가하고 기존 요소를 재할당한다.
   */
  #rehash() {
    const oldBuckets = this.#buckets;
    const nextBucketSize = this.#RESIZE_FACTOR * this.#bucketSize;

    if (nextBucketSize > this.#MAX_BUCKET_SIZE) return;
    this.#bucketSize = nextBucketSize;
    this.clear();

    for (const oldBucket of oldBuckets) {
      for (const [key, value] of oldBucket) {
        this.put(key, value);
      }
    }
  }

  /**
   * 해시 값을 도출한다.
   * @param {string} key
   */
  #hashCode(key) {
    let hash = 0;

    for (let i = 0; i < key.length; i++) {
      hash = (31 * hash + key.charCodeAt(i)) >>> 0;
    }

    return hash;
  }

  /**
   * 해시 값에 따라 버킷 인덱스를 반환한다.
   * @param {string} key
   * @returns
   */
  #getIndex(key) {
    const hash = this.#hashCode(key);
    return hash % this.#bucketSize;
  }

  #isNeedReHashing() {
    return (this.size() + 1) / this.#bucketSize > this.#MAX_LOADFACTOR;
  }

  #validateInitialValue(initialValue) {
    if (initialValue.length > 0) {
      if (typeof initialValue !== "object") {
        throw new Error(this.#INPUT_ERROR_MESSAGE);
      }

      if (!initialValue.hasOwnProperty("length")) {
        throw new Error(this.#INPUT_ERROR_MESSAGE);
      }

      for (const init of initialValue) {
        if (init.length !== 2 || typeof init[0] !== "string" || typeof init[1] !== "string")
          throw new Error(this.#INPUT_ERROR_MESSAGE);
      }
    }
  }

  printBucketSize() {
    console.log(this.#bucketSize);
  }
}

try {
  const hashMap = new HashMap();
  const hashMap2 = new HashMap([["홍길동", "24"]]);

  hashMap.printBucketSize(); // bucketSize : 16

  hashMap.put("1", "val1");
  hashMap.put("2", "val1");
  hashMap.put("3", "val1");
  hashMap.put("4", "val1");
  hashMap.put("5", "val1");
  hashMap.put("6", "val1");

  console.log(hashMap.keys()); // [1, 2, 3, 4, 5, 6]

  hashMap.remove("1");
  hashMap.remove("2");
  hashMap.remove("3");

  console.log(hashMap.keys()); // [4, 5, 6]

  hashMap.put("7", "val1");
  hashMap.put("8", "val1");
  hashMap.put("9", "val1");
  hashMap.put("99", "val1");
  hashMap.put("11", "val1");
  hashMap.put("22", "val1");
  hashMap.put("33", "val1");
  hashMap.put("44", "val1");
  hashMap.put("55", "val1");
  hashMap.put("66", "val1");
  hashMap.put("77", "val1");
  hashMap.put("88", "val1");

  hashMap.printBucketSize(); // bucketSize : 32

  console.log(hashMap.isEmpty()); // false

  hashMap.clear();

  console.log(hashMap.isEmpty()); // true
} catch (err) {
  console.log(err);
}

순수 함수란?

순수 함수 는 아래 두 가지 조건을 만족하는 함수다.

1. 항상 동일한 입력에 대해 동일한 출력을 반환
2. 함수 외부 상태에 영향을 주지 않고, 외부 상태에 의존하지 않음

각각의 조건을 예시와 함께 살펴보자

1. 항상 동일한 입력에 대해 동일한 출력을 반환

입력값이 같다면 언제 호출하든 결과가 같음을 보장한다는 의미이다. 예를 들어, f(2) === 4 였다면, 몇번이고 실행해도 무조건 4가 나와야 한다.

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

2. 함수 외부 상태에 영향을 주지 않고, 외부 상태에 의존하지 않음

외부의 변수를 변경하지 않고 (즉, 부작용이 생길 우려가 없음), 외부 변수나 I/O(파일, 네트워크 등)에 의존하지 않는다는 의미이다.

아래 예시는 외부 변수 counter을 함수 내에서 변경하므로 순수 함수가 아니다.

let counter = 0;
function increase() {
  counter++;
  return counter;
}

이것을 순수 함수로 변경하면 다음과 같아진다.

function increase(counter) {
  return counter + 1;
}

다음처럼, taxRate 라는 외부 상태에 의존하여, 해당 외부 상태가 변경되면 결과도 바뀌는 함수도 순수 함수가 아니다.

function calculatePrice(price) {
  return price + price * taxRate;
}

taxRate 도 매개변수로 주어져야 순수 함수라고 할 수 있다.

function calculatePrice(price, taxRate) {
  return price + price * taxRate;
}

순수 함수의 장점

• 1번 조건에 의해 항상 결과가 같아서 예측 가능하다는 장점이 있고, 연쇄 효과로 테스트와 디버깅이 쉬움
• 다른 곳에서도 쉽게 재사용이 가능
• 부작용이 없음을 보장하기 때문에 안전하게 병렬 실행하거나 결과를 캐시할 수 있음

불변성(Immutability)

불변성 이란 값이 한번 정해지면 절대로 바뀌지 않는 성질 을 의미한다.

불변성을 지키지 않은 예시

let user = { name: "도현" };
user.name = "길동";

이 예시는 기존 객체의 속성을 직접적으로 변경했기 때문에, 불변성을 깨는 방식이라고 할 수 있다.

불변성을 지킨 예시

let user = { name: "도현" };
let newUser = { ...user, name: "길동" };
user = newUser;

위 코드에서는 기존 user 객체는 변경되지 않고, 전개 연산자(...user)를 통해 복사된 새로운 객체에 name 값을 변경해 newUser를 생성한다.

즉, 기존 객체는 그대로 유지되며, 새로운 객체를 만들어 값을 바꾸는 방식이기 때문에 불변성을 지키는 예시라고 할 수 있다.

단, user = newUser는 변수 user가 새로운 객체를 가리키도록 참조가 바뀐 것일 뿐, 기존 객체 자체는 변경되지 않았다는 점에서 불변성을 유지한 것이다.

불변성을 지키지 않으면 어떤 문제가 발생할 수 있는가

1. 예측 불가능한 상태 변화

만약, 하나의 객체를 다른 곳에서 공유하고 있다고 해보자. 어느 한 곳에서 객체를 직접 수정했다면, 다른 쪽에도 영향이 갈 것이다.

결국 코드가 점점 스파게티처럼 꼬일 수 있다.

const user = { name: "도현" };
const copied = user; // 다른 파일에서 사용중이라고 가정

copied.name = "길동";
console.log(user.name); // "도현" 을 예상했으나 "길동" 출력

2. React에서의 렌더링 문제

React는 상태 변화가 일어났는지를 판단하고, 만약 그렇다면 리렌더링을 한다.

그런데, 기존 객체를 직접 수정하게 되면, 객체의 참조가 변경되지 않아 변경으로 간주하지 않고, 리렌더링도 발생하지 않는다.

따라서, 상태 기반 UI 프레임워크(예: React)에서는 상태의 불변성을 지켜야 변경 사항을 정확하게 감지하고, 올바르게 리렌더링할 수 있다.

이처럼 불변성과 순수 함수는 예측 가능하고 안정적인 코드를 작성하는 데에 중요한 역할을 한다.

참조 투명성(Referential Transparency)

어떤 표현식을 그 결과 값으로 바꿔도 프로그램의 동작이 변하지 않는 특성을 의미한다.

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

const x = add(2, 3); // 항상 5 반환

위 예시에서 add(2, 3)을 언제든지 5로 바꿔도 프로그램 동작에 전혀 영향을 주지 않는다.

이럴 때 우리는 해당 표현식이 참조 투명성(referential transparency)을 만족한다고 말한다.

그리고 함수가 순수 함수라면 자연스럽게 참조 투명성을 갖게 된다.

참조 투명성 덕분에 코드를 읽고 추론하기가 훨씬 쉬워진다.

함수형 표현 (Functional Expression)

함수형 표현은 함수를 값처럼 다루는 방식을 말한다.

즉, 함수를 변수에 할당하거나, 다른 함수의 인수로 전달하거나, 함수의 반환값으로 사용할 수 있다는 뜻이다.

함수형 표현의 특징

1. 일급 객체 (First-class)

함수가 숫자, 문자열 등 다른 데이터 타입과 동등하게 취급된다는 의미다.

즉, 변수에 저장하고, 인자로 전달하며, 반환값으로 사용할 수 있다는 특성이 있다.

2. 익명 함수 (Anonymous Function)

이름이 없는 함수를 정의할 수 있다.
주로 즉시 실행되거나 다른 함수의 인수로 전달될 때 유용하다.

3. 클로저 (Closure)

자바스크립트의 중요한 특성 중 하나다.

함수가 선언 당시의 스코프(환경)를 기억하여, 함수가 해당 스코프 밖에서 호출되어도 그 내부 변수에 접근할 수 있게 해준다.

4. 고차 함수 (Higher-order Function)

고차 함수는 함수를 인자로 받거나, 함수를 반환하는 함수를 말한다.

function greet(name) {
  return `Hello, ${name}!`;
}

function sayHello(fn, name) {
  console.log(fn(name));
}

sayHello(greet, "도현"); // Hello, 도현!

함수형 표현의 종류

1. 함수 선언문 (Function Declaration)

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

함수 이름을 사용해 독립적으로 선언하는 방식이다.

2. 함수 표현식 (Function Expression)

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

함수를 변수에 할당하는 방식으로, 익명 함수 또는 이름 있는 함수 모두 가능하다.

3. 화살표 함수 표현식 (Arrow Function Expression)

const add3 = (a, b) => a + b;

화살표 함수는 function 키워드 대신 =>를 사용하는 간결한 함수 표현 방식이다.

this 바인딩 방식이 일반 함수와 다르며, 콜백 함수나 짧은 로직에서 자주 사용된다.

함수 선언문 vs 함수 표현식 vs 화살표 함수

세 가지 표현 방식의 가장 큰 차이점은 호이스팅(Hoisting)이다.

함수 선언문

• 자바스크립트 엔진이 컴파일(해석) 단계에서 함수 전체를 메모리에 등록한다.
• 따라서 선언 이전에 호출해도 에러 없이 실행된다.

console.log(foo()); // 3

function foo() {
  return 3;
}

함수 표현식 / 화살표 함수

• const, let으로 선언된 변수는 호이스팅되지만 초기화 전까지 접근할 수 없다.
• 초기화 이전에 접근하면 ReferenceError가 발생한다.
• 이를 TDZ(Temporal Dead Zone)라고 부른다.

console.log(func1()); // ReferenceError

const func1 = function () {
  return 3;
};

const func2 = () => 3;
console.log(func2()); // 3

함수 표현식은 함수를 값으로 만들어 변수에 할당하는 코드이기 때문에
런타임에 이르러서야 함수가 생성된다.

함수 표현 방식별 호이스팅 및 호출 가능 여부

함수형 표현의 예시

1. 변수에 함수 할당

const greet = function (name) {
  return `안녕하세요 ${name} 님!`;
};

console.log(greet("도현"));

greet 변수에 익명 함수가 할당되었고, 이 함수를 greet() 형태로 호출할 수 있다.

2. 다른 함수의 인수로 전달 (콜백 함수)

function operate(a, b, callback) {
  return callback(a, b);
}

const add = function (x, y) {
  return x + y;
};

const multiply = function (x, y) {
  return x * y;
};

console.log(operate(5, 3, add)); // 8
console.log(operate(5, 3, multiply)); // 15

operate 함수는 세 번째 인자로 함수(callback)를 받는다.
이처럼 다른 함수에 인수로 전달되는 함수를 콜백 함수라고 한다.

3. 함수의 반환값으로 사용

function createMultiplier(factor) {
  return function (number) {
    return number * factor;
  };
}

const multiplyByTwo = createMultiplier(2);
const multiplyByTen = createMultiplier(10);

console.log(multiplyByTwo(5)); // 10
console.log(multiplyByTen(5)); // 50

createMultiplier 함수는 다른 함수를 반환한다.
즉, 고차 함수(Higher-order Function)이다.

4. 즉시 실행 함수 표현 (IIFE: Immediately Invoked Function Expression)

(function () {
  const message = "즉시 실행되는 함수입니다";
  console.log(message);
})();

이름 없는 함수를 정의하자마자 즉시 호출하는 패턴이다.
주로 스코프를 격리하거나 초기화 코드를 실행할 때 사용된다.

함수형 표현의 장점

• 모듈성과 재사용성 증가
  → 함수를 독립적인 단위로 만들어 다양한 곳에서 재사용할 수 있다.

• 높은 유연성
  → 함수를 동적으로 생성하고 전달할 수 있어 코드의 유연성이 높다.

• 코드의 간결성
  → 특히 화살표 함수와 함께 사용될 때 더 간결한 코드 작성이 가능하다.

• 테스트 용이성
  → 순수 함수와 함께 사용될 경우, 예측 가능한 동작으로 테스트가 쉬워진다.

함수형 프로그래밍 (Functional Programming)

함수형 프로그래밍은 프로그래밍을 함수의 조합으로 구성하는 선언형(Declarative) 프로그래밍 패러다임이다.
상태(state)와 변경(mutation)을 최소화하고, 순수 함수와 고차 함수를 중심으로 코드를 구성한다.

함수형 프로그래밍의 핵심 철학

• 무엇을 할 것인가(What)를 설명
  → 명령형(imperative)은 "어떻게 할 것인가(How)"를 설명
• 데이터와 동작을 함수로 추상화
• 부작용(side effects)을 줄이고 예측 가능한 코드 작성

주요 개념

1. 순수 함수 (Pure Function)

2. 불변성 (Immutability)

3. 고차 함수 (Higher-order Function)

4. 일급 객체로서의 함수

5. 함수 합성 (Function Composition)

작은 함수들을 조합해 더 복잡한 기능을 만드는 것.

const add2 = (x) => x + 2;
const mul3 = (x) => x * 3;

const compose = (f, g) => (x) => f(g(x));

const addThenMul = compose(mul3, add2);

console.log(addThenMul(4)); // (4 + 2) * 3 = 18

6. 커링 (Currying)

하나의 인자만 받는 함수를 연속적으로 호출해 최종 결과를 만드는 기법.

function multiply(a) {
  return function (b) {
    return a * b;
  };
}

const double = multiply(2);
console.log(double(5)); // 10

함수형 프로그래밍의 장점

• 코드 예측 가능성 증가 (순수 함수 덕분)
• 테스트와 디버깅이 쉬움
• 재사용성과 조합성 향상
• 상태 관리가 쉬워 버그 발생률 감소
• 병렬 처리, 비동기 처리에 유리

주의할 점 / 단점

• 너무 과도하게 함수만 사용하면 가독성이 떨어질 수 있음
• 성능 면에서 부작용을 허용하는 방식보다 느릴 수 있음 (ex. 불변성 유지로 인한 복사 비용)

자바스크립트와 함수형 프로그래밍

자바스크립트는 함수형 프로그래밍을 지원하는 멀티 패러다임 언어다.
다음과 같은 내장 함수로 함수형 스타일 코드를 쉽게 작성할 수 있다:

• map, filter, reduce
• forEach, find, some, every
• 화살표 함수 ()=>{} (간결한 표현)
• Object.freeze() (불변 객체 생성)

const numbers = [1, 2, 3, 4];

const doubled = numbers.map((n) => n * 2); // [2, 4, 6, 8]
const evens = numbers.filter((n) => n % 2 === 0); // [2, 4]
const sum = numbers.reduce((acc, cur) => acc + cur, 0); // 10

정리

함수형 프로그래밍은 복잡한 상태 관리와 부작용을 줄여 더 안정적이고 유지보수하기 좋은 코드를 만드는 데 매우 유용하다고 할 수 있겠다.

스택 영역

스택 영역은 함수 호출시 사용되는 메모리 공간으로, 함수 호출과 관련된 지역변수 와 매개변수 리턴 주소 함수 호출 컨텍스트 가 저장된다.

스택은 프로세스 시작 시 운영체제가 고정된 크기로 한 번 할당한다. 따라서, 스택 크기는 고정되어 있고, 런타임에 변경할 수없 다.

운영체제가 프로세스 시작 시 정해진 크기(예: 1MB, 8MB 등)를 할당하고, 너무 많은 재귀 호출이나 큰 지역 변수 배열을 선언하 게 되면 Stack Overflow 가 발생하게 된다.

힙 영역

힙 영역은 프로그래머가 명시적으로 동적 메모리를 할당하는 공간으로, 주로 new, malloc 등과 같은 명령어를 통해 런타임중 에 메모리를 할당하고 해제한다.

이 영역은 크기가 고정되어 있지 않고, 프로세스가 사용할 수 있는 가용 메모리 공간 내에서 유동적으로 확장된다.

C / C++ 에서의 힙 메모리는 힙 메모리는 개발자가 직접 할당하고 해제해야 하며, 메모리 해제를 누락할 경우 메모리 누수 (Memory Leak)가 발생할 수 있다.

반면, 가비지 컬렉터(GC)가 있는 Java, JavaScript, Python 등 은 개발자가 직접 메모리를 해제하지 않아도, 사용하지않 는 객체를 자동으로 감지하여 메모리를 해제해준다.

힙은 스택과 반대 방향(낮은 주소 → 높은 주소)으로 메모리를 확장하며, 스택과 힙이 서로 침범하지 않도록 주의해야 한다.

동적배열, 객체, 콜백 등과 같이 크기가 유동적이고 생명 주기가 함수 호출보다 긴 데이터들을 저장하는 데 적합하다.

Data 영역(BSS, GVAR)

프로그램이 실행될 때 생성되고 프로그램이 종료되면 시스템에 반환되며, 전역변수, 정적변수, 배열, 구조체 등이 저장된다.

BSS 영역(Block Started by Symbol)은 초기화되지 않은 전역 변수와 정적 변수가 저장되는 공간이다.. 메모리 시작 시 0으로초 기화된 상태로 할당된다.

GVAR(Global Variable) 영역은 보통 전역 변수를 의미하는 용어로, 초기화된 전역 변수들이 저장되는 데이터(Data) 영역과 초 기화되지 않은 전역 변수들이 저장되는 BSS 영역 둘 다를 포함하는 더 넓은 개념이다.

결론적으로 GVAR 영역 = 데이터 영역(초기화된 전역 변수) + BSS 영역 이고, GVAR 영역 안에 BSS 영역이 포함되어 있는 것이다.

두 영역 모두 실행 시점에 RAM에 할당되어 프로그램이 동작하는 동안 사용된다.

TEXT 영역

프로그램이 실행될 때 생성되고, 프로그램이 종료되면 시스템에 반환되는 메모리 영역으로, 실행할 코드(명령어)가저장되는 공간이다.

TEXT 영역에는 컴파일된 기계어 코드가 위치하며, 보통 읽기 전용으로 설정되어 코드가 실행 중에 변경되지 않는다. 이 영역은함 수, 루프, 조건문 등 프로그램 로직을 수행하는 명령어들이 포함되어 있다.

TEXT 영역은 실행 파일에서 고정된 크기로 할당되며, 프로세스가 시작될 때 메모리에 적재된다.

스택 영역과 하는 일이 비슷해보이지만 다르다.

TEXT 영역은 프로그램이 무엇을 할 것인가에 대한 명령어(코드)를 저장하는 영역이라면,

STACK 영역은 현재 무엇을 하고 있는가에 관한 정보를 저장하는 영역이다.

JVM(Java Virtual Machine) 은 실행 코드를 직접 메모리에 기계어 형태로 저장하지 않고, 바이트코드 형태로 관리하며, 별도의 코드 영역(Code Area)에서 실행을 관리합니다.

Node.js, 브라우저(JavaScript 엔진) 등 자바스크립트 런타임 역시 전통적인 TEXT 영역 대신, 함수 객체와 스크립트 코드 등을위 한 별도의 코드 영역을 사용합니다.

리눅스는 뭐고 유닉스는 뭔데?

일단, 리눅스와 유닉스 둘 다 OS인 것은 알고 있다. 수도없이 들어본 리눅스 와 유닉스 지만, 둘의 차이점을 모르기에 알아 보고 정리하기로 했다.

유닉스

유닉스는 1969년 AT&T 벨 연구소 에서 개발된 운영체제이다.

유닉스.. 그래서, 왜 만들어졌는데?

MIT, GE, Bell Labs가 함께 만든 MULTICS 라는 프로젝트가 있었다고 한다. 이 프로젝트는 다중 사용자(멀티 유저), 다중 작업(멀티태스킹)이 가능한 운영체제를 개발하는 것이 목표였다.

하지만, 구현이 복잡하고 매우 느린 탓에, 개발 시간이 지연되었고 결국 개발 비용이 너무 늘어났다.

그래서 AT&T는 MULTICS 프로젝트에서 1969년에 탈퇴하게 되었고, 이 문제를 해결할만한 OS를 만들고자 하였다.

그래서 나온것이 MULTICS의 반대 개념인 UNICS(Uniplexed Information and Computing System) 이다. 이후 철자가 UNIX 로 바뀌었다.

MULTICS 가 복잡한 다중 사용자 환경(멀티 유저, 엄격한 보안 권한 분리) 을 목표로 했다면, UNIX는 상대적으로 단순한 멀티유저 자원으로 시작했다.

멀티 유저 자원 이라 함은 여러 사용자가 컴퓨터 시스템을 동시에 사용할 때, CPU, 메모리와 같은 자원을 나눠 쓰게 되는데 이런 자원을 관리하는 모든 시스템과 기법을 일컫는다.

MULTICS 가 사용자마자 세밀한 권한을 부여하고, 접근을 제어한다면,
UNIX 는 사용자 계정과 비밀번호로 간단히 구분하는 방식을 채택했다고 보면된다.

AT&T 에서 개발한 초기 UNIX 는 어셈블리어로 작성되었는데,
1972년 Dennis Ritchie 가 C언어를 개발한 이후, 1973년 유닉스가 C언어로 재작성되었다.

C언어로 재작성된 UNIX는 이식성이 높고 유지보수하기 쉬운 운영체제가 되었다.

유닉스의 철학은 모든 것은 파일이다, 작고 단순한 프로그램을 조합하라 이며, 이후 LINUX, BSD macOS 에도 이어졌다고 한다.

리눅스

리눅스는 1991년 리누스 토르발스(Linus Torvalds)가 개발한 운영체제 커널이다.

리눅스.. 그래서, 왜 만들어졌는데?

리눅스는 당시 상용 운영체제들이 비싸고, 폐쇄적이며, 제한적인 기능만 제공하는 문제를 해결하고자 만들어졌다. 이는 당시 UNIX도 가지고 있던 문제점이었다.

특히, MINIX라는 교육용 유닉스 계열 운영체제에 영감을 받아, 더 자유롭고 확장 가능한 운영체제를 목표로 했다.

리누스 토르발스는 개인 프로젝트로 시작했으나, 이후 전 세계 개발자들이 참여하는 오픈소스 프로젝트로 발전하였다.

리눅스 커널은 유닉스(UNIX)의 철학과 설계를 계승하면서도, 자유롭게 수정·배포할 수 있는 GPL(General Public License) 하에 공개되었다.

리눅스의 주요 특징

• 오픈 소스(Open Source) : 누구나 코드를 보고, 수정하고, 배포할 수 있음
• 유닉스 철학 계승
• 모듈화된 커널 구조 필요에 따라 기능을 추가하거나 제거할 수 있는 모듈 시스템 지원
• 다중 사용자 및 다중 작업 지원 멀티태스킹, 멀티유저 기능이 강력함
• 광범위한 하드웨어 지원 PC부터 서버, 임베디드 시스템까지 다양한 하드웨어에서 동작
• 풍부한 배포판과 커뮤니티 우분투, 페도라, 데비안, 레드햇 등 다양한 배포판이 존재
• 서버 운영체제, 클라우드 인프라, 모바일(안드로이드), IoT 등 다양한 분야에서 활용되며, 세계 IT 환경에 지대한 영향을 미쳤다.

다음 두 코드를 살펴보자.

export default function App() {
  const [count, setCount] = useState(0);

  return (
    <div>
      {count}
      <button onClick={() => setCount((c) => c + 1)}>Increment Count</button>
    </div>
  );
}

const init = () => 0;

export default function App() {
  const [count, setCount] = useState(init);

  return (
    <div>
      {count}
      <button onClick={() => setCount((c) => c + 1)}>Increment Count</button>
    </div>
  );
}

첫 번째 코드는 상태 초기 값을 바로 0으로 전달한다. 두 번째 코드는 init 이라는 함수를 전달하여 상태를 초기화한다.

지금처럼 0을 반환하는 경우 성능 차이가 없지만, 만약 init 함수 내에 무거운 계산이 포함되어 있다면?

그럴 때 지연 초기화 를사용하면 무거운 초기값 계산을 꼭 필요한 시점까지 미룰 수 있어 초기 화면 렌더링 성능 향상에 도움이 된다.

useReducer 는 세 번째 매개변수로 지연 초기화에 필요한 함수를 받는데, 다음과 같다.

const [state, dispatch] = useReducer(reducer, 0, init);

init() 처럼 함수를 호출한 값을 전달하는 것이 아니라, 함수 자체를 전달해야 한다는걸 꼭 기억하자.

본 포스팅은 한 입 크기로 잘라먹는 타입스크립트 강의를 참고하여 작성했습니다. 문제가 될 소지가 있다면 댓글로 알려주세요. 바로 수정하겠습니다.

유틸리티 타입

유틸리티 타입 이란, 제네릭, 맵드 타입, 조건부 타입 등의 타입 조작 기능을 이용해 자주 사용되는 타입변환 패턴을 미리 정의해 놓은 타입을 말한다.

자주 유틸리티 타입을 살펴보고, 구현 코드도 이해해보자.

조건부 타입 기반

Exclude<T, U>

T에서 U를 제거하는 타입이다.

사용 예시

type A = Exclude<string | boolean, boolean>;
// A : string

string | boolean 타입에서 boolean 을 제거하므로, A의 타입은 string이 된다.

구현 코드

type Exclude<T, U> = T extends U ? never : T;

T가 U를 확장하는 타입이라면 never 을, 아니라면 T 타입을 반환하도록 해서, U 타입만 제거해줄 수 있다.

Extract<T,U>

T에서 U를 추출하는 타입이다.

사용 예시

type B = Extract<string | boolean, boolean>;
// B : boolean

string | boolean 타입에서 boolean 을 추출하므로, B의 타입은 boolean이 된다.

구현 코드

type Extract<T, U> = T extends U ? T : never;

T가 U를 확장하는 타입이라면 T 를, 아니라면 never 타입을 반환하도록 해서, T 타입만 추출해줄 수 있다.

ReturnType<T>

함수의 반환값 타입을 추출하는 타입이다.

사용 예시

function funcC() {
  return "hello";
}

type ReturnA = ReturnType<typeof funcC>;
// ReturnA : string

funcC 의 반환 값이 string 이고, 따라서 ReturnA 의 타입은 string이 된다.

구현 코드

type ReturnType<
  T extends (...args: any) => any
> = T extends (...args: any) => infer R
  ? R
  : never;

T extends (...args: any) => any 은 T 가 어떤 함수 타입 이어야 한다는 제약 조건을 명시한다.

T extends (...args: any) => infer R ? R : never; 은 T가 함수 타입이라면 반환 타입을 R로 추론하고, 그렇지 않으면 never를 반환한다는 의미이다.

맵드 타입 기반

아래 Post 타입을 기반으로 이해해보자.

interface Post {
  title: string;
  tags: string[];
  content: string;
  thumbnailURL?: string;
}

Partial<T>

특정 객체 타입의 모든 프로퍼티를 선택적 프로퍼티로 바꿔주는 타입이다.

사용 예시

const draft: Partial<Post> = {
  title: "제목은 나중에",
  content: "초안",
};

Post 의 tags는 필수 프로퍼티였지만, 선택적 프로퍼티로 바뀌었기 때문에 생략해도 무방한 모습이다.

구현 코드

type Partial<T> = {
  [key in keyof T]?: T[key];
}

맵드 타입과 ? 키워드를 이용해 구현한다.

Required<T>

특정 객체 타입의 모든 프로퍼티를 필수 프로퍼티로 바꿔주는 타입이다.

사용 예시

const withThumbnailPost: Required<Post> = {
  title: "아무 post",
  tags: ["ts"],
  content: "",
  thumbnailURL: "https..",
};

thumbnailURL 은 선택적 프로퍼티였지만, 해당 유틸리티 타입을 사용해 필수 프로퍼티가 되었다.

구현 코드

type Required<T> = {
  [key in keyof T]-?: T[key];
};

선택적 프로퍼티를 나타내는? 을 제거한다(-) 라는 의미로, -? 를 사용해 구현한다.

Readonly<T>

특정 객체 타입의 모든 프로퍼티를 읽기 전용 프로퍼티로 만들어주는 타입이다.

사용 예시

const readonlyPost: Readonly<Post> = {
  title: "보호된 게시글",
  tags: [],
  content: "",
};

readonlyPost.content = ""; // error!!

모든 속성이 읽기 전용으로 지정되어, 수정을 하려고 하면 에러가 발생한다.

구현 코드

type Readonly<T> = {
  readonly [key in keyof T]: T[key];
};

맵드 타입과 readonly 키워드를 이용해 구현한다.

Pick<T, K>

객체 타입 T로부터 지정한 프로퍼티 K 만 추출하는 타입이다.

사용 예시

const legacyPost: Pick<Post, "title" | "content"> = {
  title: "엣날 글",
  content: "옛날 컨텐츠",
};

Post 타입에서 title 과 content 타입만 추출한 모습이다.

구현 코드

type Pick<T, K extends keyof T> = {
  [key in K]: T[key];
};

K extends keyof T : K는 반드시 T의 키의 일부여야 한다는 제약조건

Omit<T, K>

객체 타입 T 에서 지정한 프로퍼티 K를 제외하는 타입이다.

사용 예시

const noTitlePost: Omit<Post, "title"> = {
  content: "",
  tags: [],
  thumbnailURL: "",
};

Post 타입에서 title 속성만 제외한 모습이다.

구현 코드

type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>;

K extends keyof T : K는 반드시 T의 키의 일부여야 한다는 제약조건 Exclude<keyof T, K> : T의 키 중에서 K를 제외한 키만 추출 Pick<T, Exclude<keyof T, K>> : T 에서 K를 제외한 키들만 골라 새로운 타입으로 구성

Record<K, V>

동일한 패턴을 갖는 객체 타입을 정의하는 타입이다.

사용 예시

type Thumbnail = Record<"large" | "medium" | "small", { url: string }>;
// type ThumbnailLegacy = {
//   large: {
//     url: string;
//   };
//   medium: {
//     url: string;
//   };
//   small: {
//     url: string;
//   };
// };

구현 코드

type Record<K extends keyof any, V> = {
  [key in K]: V;
};

K extends keyof any : K가 어떤 객체의 키 타입임을 명시한다.

본 포스팅은 한 입 크기로 잘라먹는 타입스크립트 강의를 참고하여 작성했습니다. 문제가 될 소지가 있다면 댓글로 알려주세요. 바로 수정하겠습니다.

타입을 조작하는 도구에는 제네릭 인덱스드 액세스 타입 keyof 연산자 Mapped(맵드) 타입 템플릿 리터럴 타입 조건부 타입 이 있다.

타입을 조작 한다는 것은 기존 타입을 기반으로 새로운 타입을 만들거나, 타입에 대한 어떤 조건이나 연산을 적용해 타입의 형태를 바꾸는 것을 말한다.

하나씩 살펴보자.

타입 조작 방법

제네릭

함수, 클래스, 인터페이스 등을 선언할 때, 타입을 고정하지 않고, 파라미터처럼 받아서 사용할 수 있게 하는 문법이다. 제네릭이 타입 조작 방법에 해당하지 않는다고 생각할 수도 있는데, 문맥에 따라 타입이 동적으로 결정되기 때문에 타입 조작에 해당한다.

제네릭 클래스 예시

class List<T> {
  constructor(private list: T[]) {}

  push(data: T) {
    this.list.push(data);
  }

  pop() {
    return this.list.pop();
  }

  print() {
    console.log(this.list);
  }
}

const numberList = new List([1, 2, 3]);
numberList.pop();
numberList.push(4);
numberList.print();

numberList.push('2'); // error!!

const stringList = new List(["1", "2", "3"]);
stringList.pop();

인덱스드 액세스 타입

객체, 배열, 튜플 타입에서 특정 프로퍼티 혹은 요소의 타입을 추출하는 타입이다. 복합하고 큰 타입에서, 필요한 작은 타입으로 추출하여 쓸 수 있다.

예를 들어, 다음과 같은 코드가 있다고 해보자.

interface Post {
  title: string;
  content: string;
  author: {
    id: number;
    name: string;
  };
}

const post: Post = {
  title: "게시글 제목",
  content: "게시글 본문",
  author: {
    id: 1,
    name: "홍길동",
  },
};

function printAuthorInfo(author: { id: number; name: string }) {
  console.log(`${author.name} - ${author.id}`);
}

printAuthorInfo 함수에서 매개변수 author 에 대한 타입을 {id : number; name: string} 의 형태로 정의했다. 그런데 만약, author 의 내부 구조가 바뀐다면, 일일이 수정해줘야 하는 상황이 발생한다.

이런 상황에서, 인덱스드 액세스 타입을 통해 해결할 수 있다.

function printAuthorInfo(author: Post['author']) {
  console.log(`${author.name} - ${author.id}`);
}

Post['author'] 과 같이 타입을 지정해주면, Post 라는 타입의 author 속성의 타입이 추출된다. 그래서 이후 author 구조가 변경되어도, 알아서 타입이 추출되기 때문에 따로 수정해줄 필요가 없게된다.

여기서 주의할 점은,Post['author']에서 'author' 은 리터럴 타입이어야 하며, 변수 값은 사용할 수 없다는 것이다. 즉, 아래와 같이 코드를 작성하면 오류가 발생한다.

const author = 'author'
type Author = Post[author]; // error!!

인덱스 부분에는 반드시 리터럴 타입이 와야 하며, 일반 변수를 사용하면 오류가 발생하니 주의하자.

keyof 연산자

프로퍼티의 키들을 모두 스트링 리터럴 유니온 타입으로 추출하는 연산자이다.

아래 코드를 보자.

interface Person {
  name: string;
  age: number;
}

const person: Person = {
  name: "홍길동",
  age: 26,
};

function getPropertyKey(person: Person, key: "name" | "age") {
   return person[key];
}

getPropertyKey(person, "name"); // 홍길동

getPropertyKey() 함수는 Person 타입 객체와 해당 객체의 키중 하나를 받아, 해당 키에 해당하는 값을 반환하는 함수이다.

만약, Person 타입에 키가 많이 추가 되었다면? 혹은, 기존 타입이 수정되어야 한다면? 매개변수에 일일이 추가해주거나 수정해줘야 하는 번거로움이 생길 것이다.

이럴 때, keyof 연산자를 사용하면 해결할 수 있다.

function getPropertyKey(person: Person, key: keyof Person) {
   return person[key];
}

두 번째 함수는 keyof 연산자를 사용해 타입 변경에 유연하게 대응할 수 있다.

Mapped(맵드) 타입

기존의 객체 타입으로부터 새로운 객체 타입을 만드는 타입이다.

다음 코드를 보자.

interface User {
  id: number;
  name: string;
  age: number;
}

interface PartialUser {
  id?: number;
  name?: string;
  age?: number;
}

// 한명의 유저 정보를 업데이트
function updateUser(user: PartialUser) {
  // update
}

updateUser({
  // id :1,
  // name: :'이도현'
  age: 25,
});

코드를 살펴보면, User 타입이 존재하고, 해당 타입의 객체를 update 할 수 있는 함수가 존재한다. 그런데, update는 부분적으로 이루어질 수 있기에, 기존 User 의 속성이 전부 선택적 프로퍼티 인 PartialUser을 새로 정의했다.

User 타입의 길이가 길어질 수록, 두 배로 코드가 늘어나기에 비효율적으로 보인다. 이를 Mapped 타입 을 통해 해결할 수 있다.

type PartialUser = {
  [key in "id" | "name" | "age"]?: User[key];
}

코드가 생소할 수 있는데 풀이하면 다음과 같다. [key in "id" | "name" | "age"]? : key가 'id', 'name', 'age' 일 수 있고, 선택적 프로퍼티임. User[key] : 해당 key에 대응하는 속성의 타입을 의미한다. 예를 들어 key 가 'id' 라면, User['id'] 인 number가 된다.

즉, key 에 어떤 값이 들어갈 수 있는지를 표현하고, 그것을 User[key] 를 통해 value를 정의한 것이다.

앞서서 "id" | "name" | "age" 와 같은 스트링 리터럴 유니온 타입은 keyof 를 통해 대체 가능하다고 했다. 만약, 모든 key 에 대해서 새로운 타입을 재정의할 것이라면 아래와 같이 코드를 작성하면 더욱 간단하게 표현 가능하다.

type PartialUser = {
     [key in keyof User]?: User[key]; 
}

템플릿 리터럴 타입

스트링 리터럴 타입을 기반으로, 정해진 패턴의 문자열만 포함하는 타입이다.

type Color = "red" | "black" | "green";
type Animal = "dog" | "cat" | "chicken";

// type ColoredAnimal = 'red-dog' | 'red-cat' | ...

두 타입이 있고, 두 타입을 합친 패턴의 새로운 타입인 ColoredAnimal 을 만들고자 하는 상황이라고 가정하자.

그럼 아래와 같이 작성 가능하다.

type ColoredAnimal = `${Color}-${Animal}`;
// -> type ColoredAnimal = "red-dog" | "red-cat" | "red-chicken" | "black-dog" | "black-cat" | "black-chicken" | "green-dog" | "green-cat" | "green-chicken"

조건부 타입

조건부 타입 은 조건에 따라 타입을 다르게 지정할 수 있는 문법이다.

type A = number extends string ? string : number;

해당 예제는 number 타입이 string 타입을 확장한다면 A의 타입을 string 으로, 그렇지 않다면 number 타입으로 설정하라는 의미이다.

제네릭과 함께 사용한다면, 더 유용하게 사용할 수 있다.

제네릭과 조건부 타입

만약, 매개변수로 text 를 입력받고, 해당 값이 문자열이면 공백을 제거하여 반환하는 함수를 만든다고 가정하자.

function removeSpaces<T>(text: T): T extends string ? string : undefined {
  if(typeof text === "string") {
    return text.replaceAll(" ", "");
  } else {
    return undefined;
  }
}

이 코드는 제네릭을 통해, T가 string 타입이라면 반환 타입도 string 으로, 그렇지 않다면 undefined로 지정하려고 했다. 하지만, 함수 구현부에서는 조건부 타입의 결과를 컴파일 타임에 알 수 없기 때문에 타입 오류가 발생한다.

각 반환문에서 as any 타입 단언을 통해 해결할 수도 있겠지만, 타입 안전성을 해칠 우려가 있다.

이럴 때 오버로드 시그니처 를 사용하면, 구현부에서도 조건부 타입의 결과를 추론할 수 있게 할 수 있어 유용하다.

function removeSpaces<T>(text: T): T extends string ? string : undefined;
function removeSpaces(text: any) {
  if (typeof text === "string") {
    return text.replaceAll(" ", "");
  } else {
    return undefined;
  }
}

분산적인 조건부 타입

조건부 타입을 유니온 타입과 함께 사용했을 때, 각 유니온 멤버에 분산적으로 적용되게 하는 문법이다.

type StringNumberSwitch<T> = T extends number ? string : number;

let c: StringNumberSwitch<number | string>; // c : number | string;

얼핏보면 number | string 타입이 number 타입을 extends 하지 않기 때문에, c의 타입은 number 타입이라고 생각할 수 있다.

조건부 타입을 유니온 타입과 함께 사용하면 유니온 타입 그 자체로 타입 변수에 할당되지 않고, 각각 분리되어 할당되게 된다.

다시 말해 아래처럼 동작하는 것이다.

let c : StringNumberSwitch<number> | StringNumberSwitch<string>

다른 예시를 하나 더 살펴보자.

let d: StringNumberSwitch<boolean | number | string>;

해당 예시를 뜯어서 살펴보면 다음과 같다.

1단계

StringNumberSwitch<boolean> |
StringNumberSwitch<number>  |
StringNumberSwitch<string> 

2단계

number |
string |
number

결과

number | string
// never 타입은 공집합 타입이기 때문에 유니온 타입에서 사라짐

조건부 타입과 infer

infer 는 inference(추론하다) 의 약어로, 조건부 타입 내에서 타입을 임시 변수로 추론할 때 사용합니다.

만약, 특정 함수에서 반환하는 타입을 추론해야 하는 상황이 있다고 가정해보자.

type FuncA = () => string;
type FuncB = () => number;

type ReturnType<T> = T extends () => infer R ? R : never;

type C = ReturnType<FuncA>; // C : string
type D = ReturnType<FuncB>; // D : number

infer R은 조건이 참일 경우, 함수 반환 타입을 R로 추론해 사용할 수 있도록 한다.

본 포스팅은 한 입 크기로 잘라먹는 타입스크립트 강의를 참고하여 작성했습니다. 문제가 될 소지가 있다면 댓글로 알려주세요. 바로 수정하겠습니다.

타입 좁히기

타입 좁히기 란 조건문 등의 분기 로직을 통해 복수의 타입이 가능한 값을 구체적인 단일 타입으로 좁히는 것을 말한다.

언제 필요한가?

함수의 매개변수가 union 타입인데, 분기별로 매개변수의 메서드를 사용해야 한다거나, 매개변수의 속성 값을 사용할 때와 같은 상황에 필요하다.

function func(value: number | string) {
  value.toFixed(); // error!!
}

위와 같은 상황에서, value가 어떤 타입인지 정확히 좁혀지지 않았기 때문에, number 타입 메서드인 toFixed() 를 사용하면 에러가 나는 것이다.

어떻게 사용하나?

타입스크립트가 변수의 타입을 좁히도록 도와주는 도구를 타입 가드 라고 한다. 이 타입 가드 를 적절히 사용하여 타입을 좁힐 수 있다.

typeof

typeof 를 통해 해당 타입이 어떤 타입인지 알아낼 수 있다.

function func(value: number | string) {
    if(typeof value === "number") {
      console.log(value.toFixed());
      // value : number
    } else if(typeof value === "string") {
      console.log(value.toUpperCase());
      // value : string
    }
}

이렇게 if 문과 typeof 를 이용해 분기를 나눈다면, 해당 블록 내에서 각각 좁혀진 타입으로 인식하게 된다. 이렇게 되면 각 타입의 메서드를 사용해도 문제가 없다.

본문과는 관계 없는 이야기지만, 타입스크립트에서는 typeof를 타입 정의에 사용하면 기존과 다른 동작을 수행한다.

const person = {
  name: "홍길동",
  age: 26,
};

type Person = typeof Person;

// 다음처럼 타입이 추출된다.
// type Person = {
//    name: string;
//    age: number;
// }

이렇게 사용하면, person 객체의 타입을 뽑아내서 새로운 타입으로 정의할 수 있다.

instanceof

instanceof 는 왼쪽 값이 오른쪽 클래스(생성자 함수)의 인스턴스인지 확인하고 맞다면 true를, 아니라면 false를 반환한다.

type Person = {
  name: string;
  age: number;
};

function func(value: Date | null | Person) {
    if(value instanceof Date) {
      // value : Date
    } //else if(value instanceof Person) {
      // error!!
    //}
}

여기서 주의할 점은, 사용자 정의 타입인 Person은 클래스가 아닌 타입이기 때문에, 주석 처리된 부분처럼 사용할 수 없다는 점이다. Date 는 JS 내장 클래스이기 때문에 가능하다.

그렇다면, 사용자 정의 타입은 어떤 식으로 확인할 수 있을까?

in

in 키워드는 지정한 속성의 이름이 객체 자체 또는 그 객체의 프로토타입 체인에 존재하면 true를, 그렇지 않다면 false를 반환하게 한다.

type Person = {
  name: string;
  age: number;
};

function func(value: number | Person) {
  if (typeof value === "number") {
    value.toFixed();
  } 
  else if ("age" in value) {
    // value : Person
  }
}

age 속성이 Person 타입에 존재하기 때문에, 타입이 Person 으로 좁혀진다.

하지만, 실제로 코드를 처음 본 상황이라면 저 분기의 value의 타입이 Person 임을 단번에 인지하기란 쉽지 않다.

in을 사용하면 직관성이 떨어지는데, 이를 해결할 방법으로 서로소 유니온 타입 과 사용자 정의 타입 가드 가 해결책이 될 수 있다.

서로소 유니온 타입

서로소 유니온 타입 이란, 교집합이 없는 타입들로만 만든 유니온 타입을 말한다.

앞서 살펴본 in 키워드를 통해 타입 좁히기를 진행한 예시를 보자.

type Admin = {
  name: string;
  kickCount: number;
};
type Member = {
  name: string;
  point: number;
};
type Guest = {
  name: string;
  visitCount: number;
};

type User = Admin | Member | Guest;

function login(user: User) {
  if ("kickCount" in user) {
    // user : Admin
  } else if ("point" in user) {
    // user : Member
  } else if ("visitCount" in user) {
    // user : Guest
  }
}

login 기능을 Admin Member Guest 타입에 따라 설정할 수 있도록 만들어두었다. 하지만, 직관성이 떨어져 user 의 타입을 추론하는데 시간이 걸린다.

다음은 서로소 유니온 타입을 사용한 예시이다.

type Admin = {
  tag: "ADMIN";
  name: string;
  kickCount: number;
};

type Member = {
  tag: "MEMBER";
  name: string;
  point: number;
};

type Guest = {
  tag: "GUEST";
  name: string;
  visitCount: number;
};

type User = Admin | Member | Guest;

function login(user: User) {
  switch (user.tag) {
    case "ADMIN": {
      // user : Admin
    }
    case "MEMBER": {
      // user : Member
    }
    case "GUEST": {
      // user : Guest
    }
  }
}

tag 라는 속성이 각 타입에 추가되었는데, 추가된 tag의 타입은 "ADMIN" "MEMBER" "GUEST" 로, 문자열 리터럴 타입이다.

세 타입에 각기 다른 타입이 추가되어, User 는 서로소 유니온 타입이 되었고 이를 이용해 swtich 문으로 직관성을 향상시키면서 타입 좁히기를 할 수 있게 되었다.

그런데 만약, 서로소 유니온 타입을 만들 수 없는 상황에서 타입 좁히기를 해야한다면, 사용자 정의 타입 가드 를 사용할 수 있다.

사용자 정의 타입 가드

type Dog =  {
  name: string;
  isBark: boolean;
}

type Cat = {
  name: string;
  isScratch: boolean;
}

type Animal = Dog | Cat;

function isDog(animal: Animal) : animal is Dog { // 함수가 참이면, 매개변수가 해당 타입임을 명시한다.
  return (animal as Dog).isBark !== undefined;
}

function warning(animal: Animal) {
  if(isDog(animal)) {
    // animal : Dog
  }
}

isDog 함수는 Animal 타입의 매개변수를 인자로 받는다. animal is Dog 부분은, 함수가 true를 반환하는 경우, animal이 Dog 타입임을 타입스크립트에게 알려주는 사용자 정의 타입 가드 시그니처 이다. return 문은 특정 객체에만 존재하는 프로퍼티를 검사하여, true 또는 false 값을 반환하도록 한다. 즉, 타입 단언을 통한 return 문은, 특정 타입에만 존재하는 프로퍼티 값을 확인하여 true 혹은 false 를 반환하는 역할을 하고, is 키워드는 해당 값이 true 라면 해당 변수가 Dog 임을 명시해준다.

프로젝트를 리팩토링하려고 하는데, 현재 스크린 리더만으로 서비스를 이용하는데 어려움이 있어, 이에 대한 내용부터 개선을 진행하려고 한다. 웹 접근성에 대한 개념과, 웹 접근성이 좋아야하는 이유, 개선 방법들을 알아보고 프로젝트에 적용해볼 것이다.

웹 접근성(Accessibility, a11y)

웹 접근성 이란 장애가 있는 사람들도 웹을 인지하고, 이해하고, 탐색하고, 상호작용할 수 있으며, 웹에 기여할 수 있도록 보장하는 것이다.

WCAG(Web Content Accessibility Guidelines) 는 이 웹 접근성을 달성하기 위해 4가지 핵심 원칙(P.O.U.R) 을 제시한다.

그렇다면 우리는 왜 웹 접근성을 고려해야할까?

웹 접근성이 중요한 이유

모두를 위한 사용성

웹의 창시자 팀 버너스 리 는 이렇게 말했다.

웹은 모두를 위한 것입니다. 누구든, 어떤 기기든, 어떤 능력이든 간에 접근할 수 있어야 합니다. — Tim Berners-Lee

애초에 웹은 모든 사람이 자유롭고 평등하게 정보에 접근할 수 있도록 설계되었다. 모든 이들이 동일한 수준으로 웹을 사용할 수는 없겠지만, 처음 설계된 목적에 맞게, 그 이상에 최대한 가까워지기 위해 우리는 웹 접근성을 고려해야 할 것이다.

검색 엔진 최적화(SEO) 개선 및 UX 향상

웹 접근성을 고려하는 것은 검색 엔진 최적화(SEO) 측면에서도 실질적인 이점을 가져다준다.

접근성을 고려하기 위해 적절한 시맨틱 태그를 활용하면, 이는 검색 엔진 크롤러가 페이지의 콘텐츠를 더 잘 이해할 수 있도록 돕는다.

뿐만 아니라, SEO를 개선하기 위한 명확한 콘텐츠 구조, 키보드 내비게이션, 텍스트 대체 설명 등은 장애 유무와 관계없이 모든 사용자에게 더 나은 경험을 제공하므로, 사용자 경험(UX)도 자연스럽게 향상된다.

결국, 이는 사람들의 유입과 더 많은 콘텐츠의 노출로 이어지며, 서비스의 접근성이 향상되어 비즈니스적으로 긍정적인 효과를 낳는다.

4가지 핵심 원칙(P.O.U.R)

WCAG 는 4가지 핵심 원칙으로 Perceivable(지각 가능) Operable(운용 가능) Understandable(이해 가능) Robust(견고함) 을 언급한다.

이 중 하나라도 충족되지 않으면, 장애가 있는 사용자는 웹을 사용할 수 없다고 판단한다.

지각 가능(Perceivable)

정보와 사용자 인터페이스 구성요소는 사용자가 지각할 수 있는 방식으로 제공되어야 합니다.

이 말은, 모든 사용자가 웹에서 제공되는 정보를 어떤 방식으로든 인식할 수 있어야 한다는 뜻이다. 이를 위해 다음과 같은 방식을 고려할 수 있다고 한다.

• 만약 사용자가 시각적으로 읽지 못한다면, 대체 텍스트나 스크린 리더와 같은 보조 기술을 통해 정보를 전달할 수 있어야 함.
• 만약 소리가 포함되는 컨텐츠가 있다면, 자막을 제공하거나 소리가 없는 대체 방법으로 정보를 제공해야 함.
• 정보를 제공하는 방법이 하나의 감각에 의존해서는 안됨. 시각, 청각, 촉각 등 여러 가지 감각을 통해 정보를 인식할 수 있어야 함. 예를 들어, 소리가 나는 버튼은 시각적 표시나 진동 등의 다른 방식으로도 사용자가 그 버튼을 인식할 수 있어야 함.

운용 가능(Operable)

사용자 인터페이스 구성요소와 내비게이션은 운용 가능해야 합니다.

이 말은, 웹에서의 모든 상호작용이 사용자가 실행할 수 있는 방식으로 제공되어야 함을 의미한다. 즉, 사용자가 실제로 상호작용할 수 없는 요소나 인터페이스는 없어야한다.

• 웹사이트나 애플리케이션의 내비게이션 및 상호작용 요소는 반드시 키보드로 조작할 수 있어야 함
• 사용자가 특정 작업을 완료할 수 있는 충분한 시간을 제공해야 함.
• 사용자가 인터페이스와 상호작용할 때, 인터페이스의 동작은 예상한 대로 작동해야 함.

이해 가능(Understandable)

정보와 사용자 인터페이스의 작동은 이해 가능해야 합니다.

이는 애플리케이션에서 제공되는 정보와 인터페이스가 사용자가 이해할 수 있는 방식으로 제공되어야 한다는 의미이다.

• 명확한 언어를 사용해야 함. (복합적이거나 전문적인 용어는 최대한 지양하고, 일상적인 언어를 사용해야 함.
• 인터페이스가 예측 가능해야 함. (사용자가 특정 기능과 상호작용할 때, 그 행동이 어떤 결과를 초래할지 미리알 수 있어야 함.)

견고함(Robust)

콘텐츠는 보조 기술을 포함한 다양한 사용자 에이전트에 의해 신뢰성 있게 해석될 수 있을 만큼 견고해야 합니다.

웹 콘텐츠가 다양한 기술 환경에서 잘 동작할 수 있도록 설계되어야 한다는 의미이다. 즉, 기술의 발전이나 새로운 장치나 브라우저가 등장하더라도 웹 콘텐츠는 항상 접근 가능하고, 사용자에게 문제없이 제공되어야 한다는 원칙이다.

• 웹 표준을 준수해야함. (웹 콘텐츠가 다양한 기술환경에서 제대로 작동하기 위해서는, HTML CSS JavaScript 와 같은 웹 기술이 W3C 의 표준을 따르도록 작성되어야 함.)
• 웹 콘텐츠는 보조 기술과도 호환되어야 함. (웹 콘텐츠가 스크린 리더, 음성 인식 소프트웨어, 키보드 내비게이션과 같은 보조기술에서 잘 동작해야 함.)

웹 접근성 개선 방법

웹 접근성이 중요한 이유, 4가지 핵심원칙에 대해 알아봤으니, 이제 실제로 어떻게 웹 접근성을 개선할 수 있는지에 대해 알아보자.

1. 시멘틱 태그 사용

시멘틱 태그 란 HTML에서 의미를 담고 있는 태그를 말한다. 비시맨틱한 역할을 하는 div 나 span 사용을 지양하고, header main 과 같은 시맨틱 태그를 사용해야한다.

시멘틱 태그를 사용하면 모든 사용자가 페이지의 구조를 명확하게 이해할 수 있으며, 콘텐츠를 구분하기 쉬워지고 혼란을 줄일 수 있다.

예를 들어, strong 태그는 스크린 리더에서 해당 문장을 더 강하게 읽어주며, 검색 엔진도 이 문장을 중요한 정보로 인식한다.

결국 시멘틱 태그는 보조 기술이 페이지의 구조와 핵심 내용을 더 쉽게 파악하게 도와주고, 접근성과 사용자 경험을 모두 향상시킨다.

2. 대체 텍스트 및 텍스트 콘텐츠 사용

이미지는 시각적 정보이므로 시각장애인은 내용을 인식할 수 없다. 따라서, alt 속성으로 대체 텍스트를 제공해야 한다.

<img src="coke.jpg" alt="코카콜라 사진"/>

하지만, 의미 없는 배경이나 아이콘 이미지의 경우 alt 를 빈 값으로 둬서 스크린 리더가 무시하도록 하는게 좋다.

만약에 비디오 콘텐츠가 있다면, 청각장애인을 위해 자막(track)이나 전체 스크립트를 함께 제공해야 한다.

3. 키보드 접근성 향상

키보드만으로 조작 가능해야 함

마우스를 사용할 수 없는 사용자도 있기 때문에, 페이지 내의 모든 상호작용은 Tab Enter Space 키로만 조작이 가능해야 한다.

tabindex 적절히 사용하기

Tab 키를 통해 HTML 구조를 따라 논리적인 순서로 이동할 수 있도록 마크업을 구성해야한다.

tabindex 속성은 수동으로 탭 순서를 지정할 수 있지만, 과도한 사용은 지양해야 한다.

과도하게 사용하면 안되는 이유

실제로 HTML 요소가 시멘틱 태그로 잘 구성되어 있다면, tabindex 를 자주 사용할 필요 없이 자연스러운 탭 순서가 자동으로 결정된다. 과도한 tabindex 은 오히려 비논리적으로 구성되어 사용자에게 혼란을 줄 수 있고, 보조 기술을 사용하는 사용자에게도 문제가 된다.

또한, tabindex 를 사용하는 기존 요소에 수정이 필요하거나, 다른 요소가 추가될 때마다 tabindex 값을 계속 수정해야 할 필요성이 생기기에, 유지보수에도 악영향을 초래한다.

tabindex 속성

tabindex = "0"

tabindex = "0" 을 사용하면, div 나 span 과 같은 기본적으로 포커스를 받을 수 없는 요소를 탭 순서에 포함시킬 수 있다. 일반적으로 포커스를 받을 수 없는 요소들이 반드시 탭 순서에 포함되어야 할 때, 사용하면 유용하겠다.

tabindex = "-1"

tabindex = "-1" 을 사용하면, 해당 요소가 탭 순서에서 제외되며, 해당 요소에 포커스가 이동하지 않는다. 해당 속성을 사용하면 모달 창이 띄워졌을 때, 배경은 탭 순서에서 제외되어 사용자는 모달 내부 요소만 탐색할 수 있게된다. 이는포커스 트랩 을 구현하는 데 유용하다.

4. 적절한 색상 대비

텍스트와 배경 간의 적절한 대비가 모든 사용자가 환경에 구애받지 않고 웹을 쉽게 읽을 수 있도록 돕는다.

WCAG 에 따르면, 일반 텍스트는 배경과의 대비가 최소 4.5:1 이상이어야 한다. 이는 텍스트가 배경과 충분히 구분되어 가독성을 높이고, 시각적 편안함을 제공하는 최소 수치라고 한다.

그리고, 색상만을 중요한 정보를 전달하지 않는 것도 중요하다고 한다. 버튼이나 경고 메시지에서 색상만으로 상태를 표현하지 말고, 아이콘이나 텍스트 등 여러 방법을 통해 함께 제공하는 것이 권장된다.

5. 적절한 폰트 크기

적절한 폰트 크기는 사용자가 웹을 쉽게 읽게 돕는다. 글자가 너무 작으면 여러 환경에서 읽기 어려울 수 있기 때문에, 최소 크기 기준을 정하는 것이 좋다.

px 단위로 폰트를 설정하면, 웹 페이지의 텍스트 크기가 고정되기 때문에 rem 단위를 사용해 폰트 크기가 상대적으로 조절 가능하게 하는 것이 좋다. 본문 텍스트는 최소 1rem(16px) 이상이 권장되고, 이는 모바일에서도 읽기 쉬운 크기를 보장한다.

6. 반응형 디자인

반응형 디자인은 다양한 화면 크기와 디바이스 환경에 맞게 웹 페이지를 최적화하는 디자인 방식 이다.

화면이 큰 디바이스와, 화면이 작은 디바이스는 아무래도 표현할 수 있는 콘텐츠의 양이 다르다. 이를 고려하여 웹사이트를 설계하는 것이 중요하다. 이를 통해, 사용자가 어떤 장치를 사용하더라도 콘텐츠가 잘 표시되고, 정보가 쉽게 탐색될 수 있도록 도울 수 있다.

이는 웹 접근성 향상에도 중요한 역할을 한다.

7. WAI-ARIA 속성 사용

WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) 은 시각적, 청각적 장애를 가진 사용자가 웹을 원활하게 사용할 수 있도록 도와주는 기술이다. 스크린 리더와 같은 보조 기술이 웹 콘텐츠를 더 정확하게 이해하고 사용자에게 제공하는 걸 돕는다.

자주 사용되고 중요한 속성들을 살펴보자!

aria-labelledby

aria-labelledby 는 어떤 요소의 이름 또는 설명을 다른 HTML 요소의 콘텐츠로부터 가져오고 싶을 때 사용한다.

<h2 id="formTitle">회원 가입</h2>
<form aria-labelledby="formTitle">
</form> 

이렇게 사용하면 form 요소가 자신을 설명할 이름을 formTitle 이라는 id를 가진 요소의 콘텐츠로부터 가져온다는 의미이다.

따라서 스크린 리더는 이 form 을 사용자에게 회원 가입 이라고 설명한다.

aria-label

aria-label 은 웹 요소에 대한 텍스트 레이블을 명시적으로 지정할 때 사용되는 속성이다. 화면에 보이는 텍스트가 없거나, 텍스트가 명확하지 않은 경우에 유용하다.

aria-labelledby 은 이미 페이지에 존재하는 다른 요소(제목, 설명 텍스트 등)의 id를 참조하여 해당 콘텐츠를 레이블로 사용하고, aria-label 은 특정 요소에 대한 텍스트 레이블을 직접 제공 한다는 차이가 있다.

<button aria-label="검색">🔍</button>

이렇게 시각적 텍스트가 없지만 보조 기술이 해당 요소를 올바르게 설명할 수 있도록 한다.

aria-describedby

aria-describedby 는 어떤 요소를 설명하는 다른 요소를 지정할 때 사용한다.

스크린 리더는 해당 속성으로 지정된 요소의 콘텐츠를, 기본 라벨 다음에추가 설명 으로 읽어준다.

<label for="email">이메일</label>
<input id="email" type="email" aria-describedby="emailHelp"/>
<div id="emailHelp">이메일은 example@domain.com 형식이어야 합니다.</div>

이렇게 사용하면 input 요소의 추가 설명을 emailHelp 라는 id를 가진 요소의 콘텐츠로부터 가져와 사용자에게 안내한다.

aria-live

aria-live 속성은 동적 콘텐츠가 업데이트 될 때 스크린 리더에게 해당 내용을 자동으로 읽도록 지시한다. 즉, 새로 생긴 콘텐츠나 변경된 콘텐츠를 자동으로 알리기 위해 사용된다.

off plite assertive 의 세 가지 주요 값이 있다.

aria-live="off"

aria-live="off"는 콘텐츠 업데이트를 스크린 리더가 읽지 않도록 설정한다. aria-live 속성을 사용하지 않는 것과 동일한 효과를 가진다.

의도적으로 해당 영역의 변경 사항을 스크린 리더에 알리지 말라는 의도를 나타내고 싶을 때 사용한다.

aria-live="polite"

aria-live="polite"는 콘텐츠가 업데이트 되면 스크린 리더가 현재 읽고 있는 내용을 마친 후 새로운 정보를 읽기 시작한다. 즉, 덜 긴급한 알림에 적합하다.

<div aria-live="polite">
  <p>현재 읽고 있는 내용을 읽고 이 메시지를 읽습니다.</p>
</div>

aria-live="assertive"

aria-live="assertive"는 콘텐츠가 업데이트 되면 현재 스크린 리더가 읽고 있는 내용을 중단하고 즉시 알리도록 합니다. 즉, 긴급하고 중요한 알림에 적합하다.

<div aria-live="assertive">
  <p>현재 읽고 있는 내용을 중단하고 이 메시지를 읽습니다.</p>
</div>

role

HTML 요소가 어떤 역할을 하는지를 보조 기술에 명시적으로 알려준다.

role에 들어갈 수 있는 값이 많지만, 몇 가지만 살펴보자.

role="alert"

role="alert" 는 긴급한 정보를 즉시 사용자에게 알리는 역할을 한다. 스크린 리더는 즉시 읽고, 사용자에게 중요한 알림을 빠르게 전달한다.

페이지 내에서 발생한 오류나 중요한 경고를 알리는데 유용하다.

<div role="alert">
  <p> 저장에 실패했습니다. 다시 시도하세요.</p>
</div>

role="dialog"

role="dialog" 은 웹 페이지의 특정 요소가 대화 상자(dialog) 임을 명시하는 역할을 한다. 주로 모달 창이나 팝업 창과 같은 사용자 인터페이스 요소에 사용된다.

이 속성을 통해 사람들에게 해당 요소가 중요한 대화 상자임을 알리기 위해 사용된다.

<div role="dialog" aria-labelledby="dialogTitle" aria-hidden="true">
  <h2 id="dialogTitle">삭제 확인</h2>
  <p>이 항목을 삭제하시겠습니까?</p>
  <button>삭제</button>
  <button>취소</button>
</div>

해당 예시는 사용자가 삭제 확인을 위한 대화 상자와 상호작용하는 상황이다. 이 대화 상자는 스크린 리더에 의해 대화 상자로 인식된다.

만약, role="dialog"가 없다면 해당 요소는 그냥 일반적인 div로 처리될 것이다.

role="alertdialog"

role="alertdialog" 는 role="alert와 role="dialog" 를 합친 것으로, 긴급한 알림이나 즉각적으로 사용자 반응을 요구하는 대화 상자에 사용된다. 즉, 중요한 알림을 전달하지만, 대화 상자의 역할을 할 때 사용한다.

예를 들어, 승인/취소를 요구하는 메시지가 있을 때가 있다.

<div role="alertdialog" aria-labelledby="alertTitle" aria-describedby="alertMessage" aria-live="assertive">
  <h2 id="alertTitle">경고!</h2>
  <p id="alertDesc">이 작업을 수행하면 복구할 수 없습니다. 계속하시겠습니까?</p>
  <button>확인</button>
  <button>취소</button>
</div>

하지만, role="dialog 와 role="dialog 와 달리 포커스를 강제로 가져온다.

aria-hidden

aria-hidden의 값을 true로 설정하면 해당 요소와 그 자식 요소들을 스크린 리더 등 보조 기술에서 감추도록 지시한다. 시각적으로는 보여도, 접근성 트리에는 포함되지 않는다.

시각적으로는 중요한 정보이지만, 보조 기술에게는 무의미하거나 혼란을 주는 정보거나, 이미지 배경 등을 숨길 때 사용한다.

<div aria-hidden="true">로딩 중...</div>

aria-checked

aria-checked는 선택 상태를 나타내는 요소(체크박스, 토글 버튼)에서, 현재 체크 여부 를 보조 기술에 전달하기 위해 사용하는 속성이다.

값이 true 면 체크되어 있음을, 값이 false 면 체크되어 있지 않음을, 값이 mixed 면 부분적으로 체크됨(일부만 선택)을 의미한다.

보통 UI의 상태에 따라 해당 설정을 동적으로 변경하면서 사용하며, 시각적인 변화와 스크린 리더가 인식하는 상태를 일치시키는 것이 중요하다.

aria-pressed

aria-pressed 는 주로 토글 버튼 또는 상태를 변경하는 버튼에서 사용된다.

값이 true 면 버튼이 눌린 상태를, 값이 false 면 버튼이 눌리지 않는 상태를, 값이 mixed 면 부분 눌림 상태(토글 스위치의 중간 상태)를 의미한다.

aria-required

aria-required 는 입력 필드가 필수 입력 항목임을 보조 기술에 알려주는 속성이다.

값이 true 면 해당 입력 필드가 필수 항목 임을, 값이 false 면 해당 입력 필드가 필수가 아님 을 의미한다.

<label for="email">이메일</label>
<input id="email" type="email" aria-required="true">            

이렇게 하면 스크린 리더는 이 입력 필드를 필수 항목으로 읽어준다. 보통 UI의 상태에 따라 해당 설정을 동적으로 변경하면서 사용하며, 시각적인 변화와 스크린 리더가 인식하는 상태를 일치시키는 것이 중요하다.

aria-disabled

aria-disabled 는 해당 요소가 비활성화 상태임을 보조 기술에 알리는 속성이다.

값이 true 면 해당 요소는 비활성화 상태임을, 값이 false 면 해당 요소는 활성화 상태임을 알린다.

시각적 상태를 명시하는 것이므로, 해당 요소 동작을 실제로 비활성화 하는 것은 아니다. 따라서, 시각적인 변화와 스크린 리더가 인식하는 상태를 일치시키는 것이 중요하다.

aria-selected

aria-selected 는 목록이나 항목 중에서 선택된 항목을 보조 기술에 알려주는 속성이다.

값이 true 면 항목이 선택됨을, 값이 false 면 항목이 선택되지 않음을 의미한다.

aria-modal

aria-modal 은 모달 대화 상자의 접근성을 향상시키는데 사용되는 속성이다.

값이 true 면, 현재 모달 창이 활성화 되어 다른 콘텐츠와 상호작용이 가능함을, 값이 false 면, 현재 모달 창이 닫히거나 모달이 아닌 상태임을 나타낸다.

aria-expanded

aria-expanded 는 접을 수 있거나 펼칠 수 있는 UI 요소에서, 현재 상태가 펼쳐져 있는지 접혀 있는지 를 보조 기술에 알려주는 속성이다.

값이 true 라면 요소가 펼쳐져 있음을, 값이 false 라면 요소가 접혀 있음을 의미힌다.

드롭다운이나 내비게이션 메뉴 토글 등에 사용하면 유용하다.

보통 UI의 상태에 따라 해당 설정을 동적으로 변경하면서 사용하며, 시각적인 변화와 스크린 리더가 인식하는 상태를 일치시키는 것이 중요하다.

aria-controls

aria-controls="targetID" 는 해당 요소가 targetID 를 가진 요소를 제어한다는 의미이다. 보통 aria-expanded 와 함께 사용한다.

<button aria-controls="dropdownMenu" aria-expanded="false">메뉴 열기</button>
<ul id="dropdownMenu" hidden>
  <li>항목 1</li>
  <li>항목 2</li>
</ul>

dropdownMenu 요소를 button 이 제어한다는 의미이다. 보조 기술이 이 속성을 참고해 연관성을 파악할 수 있도록 도와준다.

본 포스팅은 한 입 크기로 잘라먹는 타입스크립트 강의를 참고하여 작성했습니다.사용된 모든 이미지는 해당 강의에서 가져온 것입니다. 문제가 될 소지가 있다면 댓글로 알려주세요. 바로 수정하겠습니다.

타입들은 부모와 자식 간의 관계를 가지며, 모든 타입들의 관계를 늘어놓으면 결국 타입 계층도가 완성된다. 타입 스크립트의 타입 계층도는 아래와 같다.

타입 계층도를 이해하게 되면, 타입 호환성 에 대해 이해할 수 있는데, 타입 호환성 이란 어떤 타입을 다른 타입으로 취급해도 괜찮은지 판단하는 것을 말한다.

위 사진으로 이해해보자면 number 타입을 number literal 타입으로 취급하는 것은 안되지만, 반대는 가능하다. 모든 정사각형은 직사각형으로 취급해도 괜찮지만, 반대는 안되는 관계가 이와같다.

이는 number 타입이 number literal 타입의 슈퍼타입(부모타입) 이기 때문에 가능하다.

let num1 : number = 10;
let num2 : 10 = 10;

num1 = num2; // OK

------------------------

let num1 : number = 10;
let num2 : 10 = 10;

num2 = num1; // error!!

이렇게 서브 타입의 값을 슈퍼 타입으로 취급하는 업 캐스팅 은 모든 상황에 가능하다. 반면에, 슈퍼 타입의 값을 서브 타입으로 취급하는 다운 캐스팅은 대부분의 상황에 불가능하다.

특수한 타입과 함께 타입 계층도를 코드 예시와 함께 이해해보자.

코드와 함께 살펴보기

unknown

계층도를 보면, unknown 타입은 가장 최상단에 위치한다. 즉, 모든 타입의 슈퍼타입 이다.

따라서, 모든 타입의 변수들을 unknown 타입으로 취급할 수 있다.(업 캐스팅) 하지만, 다운캐스팅은 불가능하다.

  let a: unknown = 1;
  let b: unknown = "hello";
  let c: unknown = true;
  let d: unknown = null;
  let e: unknown = undefined; // OK. upcasting 


  let unknownVar : unknown;
  let num: number = unknownVar // error!! downcasting

never

never 타입은 타입 계층도 최하단에 위치한다. 즉, 모든 타입의 서브타입 이고, 모든 집합의 부분집합이다. 이는 곧 공집합을 의미한다.

  function neverFunc(): never {
    while (true) {}
  }

  let num: number = neverFunc();
  let str: string = neverFunc();
  let bool: boolean = neverFunc(); // OK. upcasting

  let never1: never = 10; // error!! downcasting

코드를 보다보면 혼동이 올 수 있지만, 결국 업 캐스팅 은 모든 상황에 가능하고,다운 캐스팅은 대부분의 상황에 불가능하다 라는 기준만 잡는다면, 해당 상황을 이해할 수 있다.

void

void 타입은 undefined의 슈퍼타입이고, 따라서 업캐스팅이 가능하다.

function voidFunc(): void {
  console.log("hi");
  return undefined;
}

let voidVar: void = undefined;

당연하게도 void 타입의 변수에 undefined를 할당할 수 있고, 이와 같은 맥락으로 void 타입의 함수가 undefined 를 반환 하도록 할 수 있다.

any

타입 계층도를 자세히 살펴보면, any 타입 머리 위에 치트키 라고 써있는 걸 볼 수 있다. 강의를 진행해주신 이정환 님이 이해하기 쉽도록 적어두신 용어이다. 이는 any 타입이 타입 계층도를 완벽하게 무시한다는 의미이다.

any 타입은 모든 타입의 슈퍼 타입 이면서, never 을 제외한 모든 타입의 서브 타입 이다.

타입 계층도로만 보면, unknown 타입의 변수를 any 타입의 변수에 넣는 것이 불가능해보이지만(다운 캐스팅), any 타입은 타입 계층도를 무시하기 때문에, 아래와 같이 다운 캐스팅이 가능하다.

let anyVar : any ;
let unknownVar : unknown;

anyVar = unknownVar;

타입 계층도를 볼 때 혼란이 올 수 있겠지만, any 타입에 한해서는 never 을 제외한 모든 관계가 무시된다고 생각하면 된다. 그래서 더더욱 위험한 타입이니, 사용을 지양하는게 좋겠다.

객체 타입의 호환성

다운 캐스팅과 업 캐스팅 개념을 가지고, 객체 타입 간의 호환성은 어떻게 되는지 알아보자. 객체 타입들도, 기본 타입처럼 슈퍼 타입 과 서브 타입 관계를 가진다.

아래 코드를 보자.

type Animal = {
  name: string;
  color: string;
};

type Dog = {
  name: string;
  color: string;
  breed: string;
};

let animal: Animal = {
  name: "기린",
  color: "yellow",
};

let dog: Dog = {
  name: "돌돌이",
  color: "brown",
  breed: "진도",
};

Animal 타입과 Dog 타입을 보면, Dog 타입의 속성이 더 많기 때문에, 슈퍼 타입(부모 타입) 이라고 헷갈릴 수도 있다. 하지만, 객체 타입 관계에서는 속성이 더 적은 쪽이 슈퍼 타입 이다.

이는 정사각형 과 직사각형 의 조건을 놓고 보면 이해하기 쉽다. 정사각형의 조건 : 직사각형의 조건 + 네 변의 길이가 모두 같다

정사각형 은 직사각형 보다 더 많은 조건을 만족해야 하므로, 더 구체적인 형태이다. 따라서 정사각형은 직사각형의 자식이다.

이해할 때는 이런 비유로 이해하면 좋고, 속성이 더 적은쪽(조건이 더 까다로움)이 슈퍼 타입 이라는걸 기억해두자.

큰 나무 가지(슈퍼 타입)에서, 프로퍼티가 추가되면서 곁가지들(서브 타입)이 뻗어나오는 모습을 상상하자.

타입 별칭

타입을 마치 변수처럼 선언해서 사용할 수 있도록 해준다.

만약 아래와 같은 코드가 있다고 해보자.

let user1: {
  id: number,
  name: string,
  nickname: string,
  age : number,
} = {
  id: 1,
  name: "leedo",
  nickname: "lee",
  age : 26,
};

let user2 ...
let user3 ...

타입이 중복될 뿐만 아니라, 속성이 추가되면 일일이 추가해야할 것이다. 이러한 번거로움을 타입 별칭 으로 해결할 수 있다.

type User = {
    id: number;
    name: string;
    nickname: string;
    age: number;
 }

let user1 : User = {
  id: number,
  name: string,
  nickname: string,
  age : number,
}

let user2 : User = ...
let user3 : User = ...

가독성이 좋아졌을 뿐만 아니라, 중복되는 코드도 압도적으로 줄어들 것이다. 또, User 타입을 따로 빼서 모듈화 하는 것도 가능하겠다.

주의해야할 점은, 타입 별칭은 변수처럼 작동하기 때문에, 같은 스코프 내에서 중복되면 안된다는 점이다.

인덱스 시그니처

인덱스 시그니처(index signature) 는 객체의 키와 값의 타입을 동적으로 정의할 수 있게 해준다.

다음 코드를 살펴보자.

type CountryCodes = {
  Korea : string,
  UnitedStates : string,
  UnitedKingdom : string,
}

let countryCodes : CountryCodes = {
  Korea : "ko",
  UnitedStates : "us",
  UnitedKingdom : "uk",
}

지금은 국가 코드를 세 개만 적어놨지만, 만약 그 수가 늘어나면, 늘어나는 만큼 타입에 추가해줘야 할 것이다. 이러한 번거로움을 인덱스 시그니처로 해결할 수 있다.

type CountryCodes {
    [key: string] : string;
}

let countryCodes : CountryCodes = {
  Korea : "ko",
  UnitedStates : "us",
  UnitedKingdom : "uk",
}

위와 같이 사용하면 key 는 string 타입으로, value 는 string 타입으로 정의해서 사용할 수 있다. 이렇듯 인덱스 시그니처 는 키와 값의 패턴이 일정할 때 사용하면 편리하다.

하지만, 인덱스 시그니처는 규칙을 위반하지만 않으면 상관이 없기 때문에, 다음과 같은 상황을 주의해야 한다.

    let contryCodes : CountryCodes = {}; // OK

규칙을 위반할 프로퍼티가 없기 때문에, 타입스크립트에서 에러로 간주하지 않는다.

만약, 반드시 존재해야 할 프로퍼티가 있다면, 아래와 같이 따로 지정해줄 수 있다.

type CountryCodes = {
  [key: string]: string;
  Korea: string;
};


let contryCodes : CountryCodes = {}; // error !!

-------------------

let contryCodes : CountryCodes = { // OK
  Korea: 'ko',
};

추가 프로퍼티로 지정해준 프로퍼티가 없다면, 에러를 발생시킨다.

하지만, 아래와 같이 추가 프로퍼티와 기존에 명시된 타입이 일치하지 않는다면, 에러를 발생시키니 주의해야 한다.

type CountryCodes = {
  [key: string]: string;
  Korea: number; // error !!
};

원시 타입(Primitive Type)

원시 타입은, 하나의 값만 저장 하는 타입으로, number string boolean null undefined 가 있다.

number

모든 숫자 값을 나타내는 타입이다. Infinity -Infinity NaN 도 number 타입에 포함된다.

let num1 : number = Infinity;
let num2 : number = -Infinity;
let num3 : number = NaN;

// 다른 타입에서만 사용할 수 있는 메서드는 사용하면 에러가 난다.

num1.toUpperCase() // error!

string

문자열을 의미하는 타입이다. 당연하게도, 백틱을 이용한 템플릿 리터럴도 포함한다.

let str1: string = `hi ${num1}`;

boolean

true와 false 만 저장할 수 있다.

null

null 값 이외에는 담을 수 없다.

undefined

undefined 값 이외에는 담을 수 없다.

리터럴 타입

리터럴 타입 이란, 고정된 값 만을 허용하는 타입이다.

let num: 10 = 10;  // 10만 허용할 것임.
num = 20;  // error!!

let strA: 'hello' = 'hello';
strA = 'hi'; // error!!

이게 대체 어디에 쓰이겠냐 싶겠지만, 이후에 복합적인 타입을 만들 때 유용하니까 알아두자.

배열 타입

같은 타입의 여러 값을 순서대로 저장하는 자료형이다.

let strArr: string[] = ["hi", "there"];
let boolArr: Array<boolean> = [true, true, true]; // 제네릭으로 나타낼 수 있다.

let multiArr1: (string | number)[] = [1, "hello"]; 
let multiArr2: Array<string | boolean> = [true, "hello"]; // 멀티 타입도 가능

let doubleArr: number[][] = [[1, 2],[3, 4]]; // 다차원도 가능

튜플 타입

길이와 타입이 고정된 배열이다. 자바스크립트에는 없고, 타입스크립트에서만 특별히 제공된다.

let tup1: [boolean, boolean] = [true, false]; // 선언

tup1 = [1, false] // error!! boolean 타입만 가능
tup1 = [false, false, false] // error!! 길이 초과

튜플은 타입스크립트에서만 특별히 제공된다고 했는데, 실제로 JS로 컴파일되어 변환될 때는 결국 배열로 컴파일된다. 그렇기 때문에, 실제 배열처럼 push() 나 pop() 메서드를 사용할 수 있다. 두 메서드는 배열의 길이에 영향을 주게 되는데, 그렇다면 에러가 날까?

tup1.push(false); // not error

놀랍게도, 타입스크립트가 감지하지 못한다. 따라서, 튜플 타입을 사용할 때는 push() 나 pop() 을 각별히 주의해서 사용해야 할 필요가 있겠다. 물론, 두 메서드를 사용할 때 내부 타입은 제대로 검사해주고, 길이 가 달라지는걸 캐치하지 못할 뿐이다.

튜플 예시

튜플은 어디에 사용할 수 있을까?

예를 들어, 유저 정보와 나이를 배열로 관리한다고 해보자.

const users = [
  ['Alice', 21],
  ['Bob', 22],
];

// 유저 정보를 추가할 것임.
users.push(22, 'leedo'); // error!! 인덱스 위치 불일치

위와 같이, 인덱스의 순서와 위치가 헷갈릴 수 있는 상황을 막아준다.

객체 타입

객체를 나타내는 object 타입과, 객체 리터럴 타입이 존재한다.

Object

let user: object = {
  id: 1,
  name: "leedo",
};

console.log(user.id) // error!!;

언뜻 보면 이 코드는 에러가 나지 않을 것 같지만, object 타입은 단순히 객체 라는 정보만을 주기 때문에, 타입스크립트가 user 안에 어떤 속성이 있는지 감지하지 못하고, 에러가 발생한다.

따라서, 아래와 같이 객체 리터럴 타입을 사용해야 한다.

객체 리터럴 타입

구체적인 객체의 구조와 속성을 정의하는 타입이다. 객체가 가져야 할 속성 과 속성의 타입 을 지정하는 방법이다.

let user: {
  readonly id: number;
  name: string;
  option?: string;
} = {
  id: 1,
  name: "leedo",
};

console.log(user.id) // leedo

user.id = '길동이'; // error!! readonly

선택적 프로퍼티(Optional property)를 사용해, 있어도 되고, 없어도 되는 속성으로 지정해줄 수도 있다.

readonly 키워드를 사용해, 읽기 전용 속성으로 만들어줄 수도 있다.

enum 타입

enum(Enumeration : 열거형) 타입은 관련된 상수 값들을 하나로 묶어서, 이름을 부여해 사용할 수 있게 해주는 타입이다.

만약, 특정 User가 존재하고, Role 이라는 속성 값을 가진다고 해보자.

const user1 = {
 role: 0, // ADMIN
}

const user2 = {
 role: 1, // USER 
}

const user1 = {
 role: 2, // GUEST 
}

이렇게 0은 어드민을, 1은 일반 유저를, 2는 게스트를 나타내기 위해 사용했다고 했다고 가정하자. 과연 몇 개월, 몇 년이 지난 후에 저 코드를 봤을 때, 저 숫자들이 무엇을 의미하는지 알 수 있을까? 이런 헷갈릴 수 있는 상황을 enum을 통해 방지할 수 있다.

enum Role {
  ADMIN = 0,
  USER = 1,
  GUEST = 2,
}

const user1 = {
 role: Role.ADMIN,
}

const user2 = {
 role: Role.USER,
}

const user1 = {
 role: Role.GUEST,
}

이런식으로 사용할 수 있다. 주석 없이도 이해할 수 있는 코드가 좋은 코드라고 배웠고, 이렇게하면 주석 없이도 해당 코드를 이해하는데 어려움이 들지 않을 것이다.

any 타입과 unknown 타입

any 타입과 Unknown 타입은 변수에 저장할 값이 확실하지 않을 때 활용할 수 있는 타입이다. 비슷해보이지만, 두 타입은 차이가 있다. any는 어떤 타입이던 상관 없음을, unknown은 어떤 타입인지 모름을 의미한다는 개념만 가지고 코드를 살펴보자.

변수 할당

let anyVar: any = 10;
anyVar = "hi";

let unknownVar: unknown = 10;
unknownVar = "hi";

두 타입 모두 저런 식으로 타입을 왔다갔다 하면서 사용할 수 있다.

메서드 사용

let anyVar: any = 10;

anyVar.toUpperCase();
anyVar.toFixed();

let unknownVar: unknown = 10;

unknownVar.toUpperCase(); // error!!
unknownVar.toFixed(); // error!!

any 타입은 어떤 타입이든 상관없기에, 타입 검사를 하지 않고, 따라서 어떤 메서드를 사용하던 간에 에러를 발생시키지 않는 모습이다. unknown 타입은 어떤 타입인지 모르기에, 특정 메서드 사용을 허용하지 않는다.

다른 변수에 할당

let anyVar: any = 10;
let num : number = 20;
num = anyVar;

let unknownVar: unknown = 10;
let num : number = 20;
num = unknownVar; // error!!

위와 같은 맥락으로, unknown 에는 뭐가 들어있을지 모르기 때문에 다른 변수에 할당하는 것을 금지한다.

그렇다면, unknown은 어떻게 사용해야 할까?

저렇게 아무 동작도 안된다면, unknown 타입은 어떻게 사용해야 할까? 나중에 글을 적겠지만, 타입 좁히기 를 통해 가능하다.

if(typeof unknownVar === "string") {
  unknownVar.toUpperCase(); // not error
}

이렇게 unknown 타입의 변수가 string 타입임을 명시해줘야 비로소 string 타입의 메서드를 사용할 수 있게 되는 것이다.

void 타입과 never 타입

아무것도 없음을 나타내기 위해 사용할 수 있는 타입으로 void와 never가 있다.

void

void는 단어 그 자체로, 존재하지 않음 공허 와 같은 의미를 지닌다. 따라서, 아무것도 없음을 나타낸다고 생각하면 된다.

function func1() : void {
  console.log('아무것도 없어요!!'):
}

이렇게 어떠한 return 값도 반환하지 않는 함수에서 주로 사용한다.

기존에 배운 undefined 와 null을 아무것도 없음을 나타내는데 사용하면 될 것 같지만, 두 타입은 함수의 반환 타입으로 지정하는 순간, 실제로 undefined와 null을 반환해줘야 하기 때문에 문제가 된다.

물론, void 타입은 변수에 타입으로 지정할 수 있다.

let var1 : void;

var1 = 1; // error!!
var1 = "hi" // error!!
var1 = undefined // OK
var1 = null // error!! 하지만, strictNullChecks": false 라면 OK

하지만, undefined 를 제외하고는 어떤 값을 할당해도 에러가 난다. tsconfig.json에서 "compilerOptions 의 옵션인 "strictNullChecks": false 즉, 엄격한 null 검사 옵션을 꺼주게 되면, null 까지도 할당 가능하다.

never

never 타입은 불가능한 존재하지 않는 이라는 의미를 갖는 타입이다.

정상적으로 종료가 되지 않기에, 예외를 던지거나, 무한 루프를 돌아서 종료에 도달할 수 없어 절대 반환이 불가능한 상황에 사용한다.

function func2(): never {
  while(true) {}
}

funciton func3(): never {
  throw new Error();
}

물론, never 타입도 변수의 타입으로 지정할 수 있다.

let neverVar: never;

neverVar = 1; // error!!
neverVar = 'hi'; // error!!
neverVar = undefined; // error!!
neverVar = null; // error!! strictNullChecks": false 여도 error.

그 어떤 값도 never 타입의 변수에 저장할 수 없다. 기존에 void 타입 변수에는 strictNullChecks": false 옵션을 꺼주면 null 을 할당할 수 있었는데, never 타입은 허용하지 않는다.

console 검사

그렇다면, 두 변수를 console.log()로 찍게되면 어떻게 될까? 라는 궁금증이 들어서 해보게 되었다.

기존 JS에서는 변수를 선언만 한다면, undefined 가 할당되고, 출력해도 동일하다.

따라서 undefined를 할당할 수 있는 void 타입은 undefined 가 출력될 것으로 예상하지만, never 타입은 어떻게 나올지가 궁금했다.

let voidVar : void;

console.log(voidVar); // undefined

내 예상대로,void 타입은 undefined 를 출력한다.

let neverVar : void;

console.log(neverVar); // error. "변수가 할당되기 전에 사용되었습니다." 

never 타입의 변수를 출력할 때는, 변수가 할당되기 전에 사용되었습니다. 라는 에러 문구를 띄워준다!!

OOP(Object Oriented Programming) 이란 무엇이고, JS에서 어떻게 객체지향을 구현할 수 있을까?

객체란?

객체란?

일단, 객체에 대해 알아보자. 객체 란 속성(데이터)과 기능(동작)을 가진 독립적인 단위를 말한다. 예를 들어, 강아지 라는 동물을 객체라고 했을 때, 이름 이라는 속성을 가지고, 짖기 라는 동작 을 한다는 걸 알 수 있다.

다시 말해서, 데이터와 그 데이터를 조작하는 기능까지 갖춘 구조체를 객체 라고 한다.

객체 지향이란?

객체 지향 이란, 프로그램 전체를 이런 객체들의 상호작용으로 구성하는 방식이다. 현실 세계처럼 여러 객체들이 소통하고 상호작용하여 문제를 해결하는 구조이다. 객체 지향은 누가 무엇을 할 것인가 에 초점을 맞추기 때문에, 각 객체가 자신의 역할과 책임을 가지고, 서로 메시지를 주고 받으면서 동작한다.

절차 지향이란?

객체 지향의 대조적인 개념인 절차 지향 이란 프로그램을 순서대로 실행되는 절차 중심으로 구성하는 방식이다. 절차 지향은 누가 무엇을 할 것인가 가 아닌, 어떻게 할 것인가 에 초점을 맞춘다.

아래는 객체 지향과 절차 지향의 차이를 간단한 예시로 나타낸 코드이다.

// 절차 지향
catBark(); 
dogBark();
wolfBark();

-------------
// 객체 지향
cat.bark();  
dog.bark(); 
wolf.bark();

그럼 절차 지향은 나쁜가?

당연하게도, 절차 지향만의 장점이 존재한다. 절차 지향은 단순하고 직관적인 흐름과 성능 최적화에 유리하기 때문에, 하드웨어와 밀접한 작업, 임베디드 시스템, 시스템 프로그래밍과 같은 분야에서 주로 사용된다. 절차 지향은 특히 성능이 중요한 환경에서 자주 사용된다. 결국 메모리 관리나 최적화가 중요한 상황에서는 절차 지향이 매우 효과적이다.

다시 말해, 절차 지향은 단순하고 성능 중심의 문제를 해결하는 데 적합하고, 객체 지향은 유지보수성, 확장성, 재사용성이 중요한 대규모 시스템에 적합한 것이다. 사용되는 분야와 목적이 다를 뿐이다.

왜 OOP를 써야하는가?

그렇다면, 왜 OOP를 써야할까?

코드로 이해해보자

객체 지향에서는 상속 이라는 개념이 존재한다. 상속은 공통된 기능은 재사용하고, 새로운 기능은 확장할 수 있게끔 하는 개념으로, 코드의 중복을 줄이고, 기존 코드는 절대 수정할 필요가 없이 새로운 객체를 추가할 수 있다.

// 절차지향

catBark() {
 console.log('고양이가 소리를 낸다. 야옹 야옹!'); 
}

dogBark() {
  console.log('강아지가 소리를 낸다. 멍멍!');
}

wolfBark() {
  console.log('나는 늑대야. 아우우~~');
}

wolfBite() {
    console.log('나는 무니까 조심해');
}
--------------------------------------------------
// 객체 지향

class Animal {
  constructor(name){
    this.name = name;
  }

  bark(val) {
    console.log(`${this.name}가 소리를 낸다. ${val}`);
  }
}

class Cat extends Animal {
}

class Dog extends Animal {
}

class Wolf extends Animal {
     bark() {
      console.log(`나는 ${this.name}야. 아우우~~`);
    }

      bite() {
      console.log('나는 무니까 조심해');
    }
}
const dog = new Dog('강아지');
const cat = new Cat('고양이');
const wolf = new Wolf('늑대');

dog.bark('멍멍!');
cat.bark('야옹 야옹!');
wolf.bark();
wolf.bite();

재사용성

객체 지향에서는 Cat Dog Wolf 클래스는 똑같이 bark() 라는 메서드를 가지고 있지만, 중복되는 부분은 재사용하고 있다. 반면에, 절차 지향에서는 같은 내용이지만 catBark() dogBark() wolfBark() 와 같이 다른 이름의 함수로 정의를 하고 있는 것을 알 수 있다.

이렇듯, 객체 지향을 통해 새로운 클래스를 추가할 때, 기존 코드를 변경하지 않고 새로운 클래스를 재사용하여 간편하게 추가할 수 있다.

유지보수성

만약, catBark() dogBark() 의 메서드에서, ~가 소리를 낸다 -> ~는 소리를 낸다 의 형식으로 바꿔야 하는 상황을 생각해보자. 그리고, 이 메서드는 1억개가 있다고 가정하자.

절차 지향으로 구현된 이 메서드들을 바꾸기 위해서는, 1억 번의 수정 작업이 필요할 것이다. 이 번거로운 과정 속에서, 오타가 발생할 수도 있고, 빠뜨린 메서드가 있을 수 있다.

하지만, 객체 지향으로 구현된 이 메서드들을 바꾸기 위해서는, 부모 클래스인 Animal 만 단 한번 수정하면 된다.

극단적인 예시이긴 하지만, 이렇게 비교하니 얼마나 객체 지향이 유지보수성 측면에서 뛰어난지 와닿는다.

확장성

만약 새로운 메서드를 추가하는 상황이라고 가정해보자. run() 이라는 메서드를 추가하려면, 절차 지향에서도 catRun() dogRun() 과 같이 추가할 수 있다.

하지만, 객체 지향에서는 상속과 오버라이드를 통해, 새로운 메서드를 추가하는 방식이 규칙적이고 일관성 있는 확장을 가능하게 만들어, 코드의 가독성과 유지보수성을 크게 향상시킨다.

객체 지향의 특성

객체 지향의 특성은 다음과 같다.

1. 캡슐화(Encapsulation)
2. 상속(Inheritance)
3. 다형성(Polymorphism)
4. 추상화(Abstraction)

1. 캡슐화(Encapsulation)

캡슐화는 객체의 데이터를 보호하고, 외부에서 직접 접근하지 못하게 한다.

예시 코드

class People {
  #age;

  constructor(age) {
    this.setAge(age);
  }

  setAge(age) {
    this.#age = age;
  }

  getAge(age) {
    return this.#age;
  }
}

캡슐화의 장점

위의 코드를 보면, setAge() 를 통해 나이를 설정할 수 있고, getAge() 를 통해 나이 정보를 얻을 수 있다.

이렇게 데이터를 보호하고, 외부에서 직접 접근하지 못하게 하면, 어떤 이점이 있을까?

데이터 무결성 보호

데이터의 무결성 이란 데이터가 정확하고 일관되며 신뢰할 수 있는 상태로 유지되는 것 을 의미한다. setAge() 함수를 살짝 변형해보겠다.

...
setAge(age) {
     if(typeof(age) !== 'number' || age < 0) throw new Error("나이는 0보다 작을 수 없습니다");
      this.#age = age;
}

만약, 이런식으로 유효성 검사를 추가한다면 나이 값에 0보다 작은 값이 들어가는 것을 방지해줄 수 있다.

캡슐화의 단점

모든 속성에 대해 getter와 setter을 작성하다보면, 당연하게도 코드의 길이가 비약적으로 늘어날 것이다. 또한, 테스트 코드에서 내부 상태를 확인하고 싶을 때, 직접 접근이 제한되어 우회하여 접근하는 것도 번거로울 수 있다.

2. 상속(Inheritance)

상속 이란 부모 클래스의 속성과 메서드를 자식 클래스가 물려받아 재사용하는 특성이다. 위에서 살펴봤으니 넘어가겠다.

3. 다형성(Polymorphism)

다형성은 같은 이름의 메서드가 서로 다른 동작을 수행할 수 있는 특성이다. 원래라면 다형성은 오버라이딩 과 오버로딩 을 통해 구현된다. 오버라이딩 은 상속 받은 메서드를 재정의하는 방식이고, 오버로딩 은 같은 메서드 이름으로 다른 매개변수를 받는 방식이다.

하지만 JS에서는 오버로딩 을 지원하지 않는다. 다른 언어에서는 인수의 개수에 따라 여러 메서드를 정의할 수 있지만, JS에서는 여러 메서드를 정의하면, 가장 나중에 정의한 메서드에 덮어 씌워지기 때문이다.

물론, 비슷하게 구현하는 방법은 존재한다.

다형성의 장점도 위에서 살펴보았으니 넘어가겠다.

4. 추상화(Abstraction)

추상화 란 복잡한 구현을 숨기고, 중요한 부분만을 드러내어 단순화하는 특성이다. 사용자는 클래스 내 메서드를 통해, 내부 로직을 알 필요 없이 동작을 수행할 수 있다.

혹은 아래와 같이 추상 클래스를 구현하도록 할 수도 있다.

class Car { // 추상 클래스
  startEngine() {
    throw new Error("startEngine() 메서드는 서브 클래스에서 구현해야 합니다.");
  }

  stopEngine() {
    throw new Error("stopEngine() 메서드는 서브 클래스에서 구현해야 합니다.");
  }
}

class ElectricCar extends Car {
  startEngine() {
    console.log("전기차 엔진을 시작합니다.");
  }

  stopEngine() {
    console.log("전기차 엔진을 멈춥니다.");
  }
}

OOP in JS

JS는 원래 프로토타입 기반(prototype-based) 언어로 설계되었다. 즉, 클래스 개념이 존재하지 않았고, 객체 간의 상속은 프로토타입을 이용하여 구현되었다. ES6 부터 클래스 개념이 도입되었고, 이를 통해 OOP를 더 직관적으로 구현할 수 있게 된 것이다.

상속

상속은 프로토타입을 통해 아래와 같이 구현될 수 있다.

function Animal(name) {
  this.name = name;

  this.bark = function() {
    console.log(`${this.name}는 짖는다`);
  }
}

function Dog(name) {
  Animal.apply(this, [name]); // 생성자 및 프로퍼티 상속
}

Dog.prototype = Object.create(Animal.prototype); // 메서드 상속
Dog.prototype.constructor = Dog; // 위 설정으로 인해, 생성자가 Animal. 따라서 생성자를 Dog로 변경해줘야 함 .

캡슐화

위에서 설명했듯이, 나이 라는 속성에, 잘못된 값이 들어가지 않도록 유효성 검사를 해줄 수 있다.

var person = {
  age : 20,
};

person.age = -20;

// 위와 같은 상황을 방지해야 함!!

var person = {
  age : 20,
  setAge : function(newAge) {
    if(typeof(newAge) !== "number" || newAge < 0) {
      throw new Age("Invalid Age");
    } else {
      this.age = newAge;
    }
  },
  getAge: function() {
    return this.age;
  }
};

다형성과 추상화는 사실상 상속과 캡슐화의 변형으로 만들어지는 것이기 때문에, 코드는 생략하도록 하겠다.

JS에서의 OOP

ES2015 이전에는 클래스 개념이 존재하지 않았다. 그렇다면 어떻게 객체를 정의하고 인스턴스를 만들었는가?

가장 처음에는 객체 리터럴 방식 이 존재했다.

Object Literal Pattern(객체 리터럴)

const healthObj = {
  name: "달리기",
  lastTime: "PM10:12",
  showHealth() {
    console.log(
      this.name + "님, 오늘은 " + this.lastTime + "에 운동을 하셨네요"
    );
  },
};

healthObj.showHealth();

여러 인스턴스를 생성할 필요가 없고, 단일 인스턴스(1회용 객체)로 사용하기 좋다.

하지만 만약 여러 개의 비슷한 객체를 만들어야 한다면, 객체 리터럴을 반복 선언할 경우 메서드가 각 객체에 중복 정의되어 메모리 비효율과 코드 관리의 어려움이 발생할 수 있다. 이때부터는 생성자 함수, 프로토타입 패턴, 혹은 ES6 클래스 같은 인스턴스 생성 방식이 필요하다.

ES6 Class Pattern(ES2015 이후 도입)

class Health {
  constructor(name, healthTime) {
    this.name = name;
    this.healthTime = healthTime;
  }

  showHealth() {
    console.log(
      this.name + "님, 오늘은 " + this.healthTime + "에 운동을 하셨네요"
    );
  }
}

const ho = new Health("crong", "12:12");
ho.showHealth();

내부적으로는 여전히 prototype 기반으로 작동하고, 가독성이 좋아 클래스 상속, 추상화 등 OOP 개념을 사용하기 편리하다는 장점이 있다.

Constructor Function Pattern

function Health(name, healthTime) {
  this.name = name;
  this.healthTime = healthTime;
  this.showHealth = function () {
    console.log(
      this.name + "님, 오늘은 " + this.healthTime + "에 운동을 하셨네요"
    );
  };
}

const ho = new Health("crong", "12:12");
ho.showHealth();

function을 생성자로 사용하는 방식이다.

new 키워드로 호출하면 this가 새로운 인스턴스를 가리키기 때문에 가능한 방식이다.

하지만 모든 인스턴스가 showHealth 메서드를 개별적으로 갖기 때문에 메모리 비효율적이다.

const ho1 = new Health("crong", "12:12");
const ho2 = new Health("babo", "10:00");

console.log(ho1.showHealth === ho2.showHealth); // false

ho1.showHealth 와 ho2.showHealth 는 다른 함수 객체이다.

즉, 인스턴스를 100개 만들면 showHealth 함수도 100개가 생긴다는 의미이다.

prototype 기반일 경우, 인스턴스를 1억개 만들어도 showHealth 함수는 1개이기 때문에, 메모리 효율성에서 차이가 난다.

Prototype Pattern

공통 메서드는 prototype에 보관하여 메모리를 절약하는 방식이다.

function Health(name, healthTime) {
  this.name = name;
  this.healthTime = healthTime;
}

Health.prototype.showHealth = function () {
  console.log(
    this.name + "님, 오늘은 " + this.healthTime + "에 운동을 하셨네요"
  );
};

const ho = new Health("crong", "12:12");
ho.showHealth();

모든 인스턴스가 prototype 의 메서드를 공유하기 때문에, 메모리를 절약할 수 있다.

Class Pattern vs Prototype Pattern

JavaScript의 ES6 클래스 패턴과 기존 프로토타입 패턴은 내부적으로 동일한 프로토타입 기반 상속을 사용한다.

하지만 문법과 사용성 측면에서 차이가 있다.

• 프로토타입 패턴은 생성자 함수와 prototype 객체를 직접 다루는 방식으로,
  복잡할 수 있지만 동작 원리를 명확히 이해하기에 좋다.

• 클래스 패턴은 문법적 설탕(Syntactic Sugar)으로,
  코드가 간결하고 가독성이 좋아 유지보수와 확장성이 뛰어나다.

두 패턴 모두 공통 메서드는 프로토타입에 한 번만 존재하여,
수많은 인스턴스를 생성해도 메모리 효율이 뛰어나다는 장점이 있다.

문법적 설탕(Syntatic Sugar)

문법적 설탕 이란 기존에 가능했던 기능을 더 보기 좋고, 쓰기 쉽게 만들어주는 문법적 편의 기능 이다.

즉, 똑같은 일을 하지만, 코드를 더 간결하고 직관적으로 쓸 수 있게 맛있게 만들어 놓은 문법이다.

그래서 설탕 이라는 표현이 들어갔다고 한다.

렌더링 엔진(Rendering Engine) 은 HTML, CSS, JS 등 웹 문서를 해석해서 사용자에게 시각적으로 보여주는 기능을 담당하는 소프트웨어이다.

대표적인 렌더링 엔진으로는 Blink Webkit Gecko 정도가 있다.

Blink

Chrome은 원래 Webkit을 사용했지만, 현재는 Blink를 사용중이다. Blink는 Webkit에서 파생되어 Google에 의해 만들어졌다.

기존의 Webkit은 모놀리식(Monolithic) 구조로, 렌더링 엔진의 내부 기능들이 하나의 프로세스 내에서 밀접하게 연결되어 작동하는 구조였다. 하지만, Chrome은 각각의 탭들을 독립된 프로세스로 실행하려는 지향했고, 이를 구현하기 위해 Webkit 내에서 크롬 전용 포크를 만들어서 관리했지만, 점점 관리가 복잡해졌다고 한다.

이러한 구조적 및 개발 방향성 차이로 인해, 구글은 Chrome에 적합한 독립된 렌더링 엔진을 개발하고자 했고, 이게 바로 Blink이다.

Rendering Process

렌더링 프로세스 란, 사용자가 웹사이트에 접근했을 때, HTML/CSS/JS를 받아 화면에 실제로 보이게 하기까지의 과정을 의미한다.

HTML/CSS/JS를 수신했다고 가정하고, 아래와 같은 순서로 렌더링 프로세스가 진행된다.

1. HTML 파싱 -> DOM 트리 생성
2. CSS 파싱 -> CSSOM 트리 생성
3. DOM + CSSOM -> 렌더 트리 생성
4. Layout
5. Paint
6. Composite
7. 화면 출력

1. HTML 파싱

2. CSS 파싱

CSS 파일이나 <style> 태그 안의 스타일은 CSS 파서가 해석해서 CSSOM(CSS Object Model) 트리를 만든다. 어떤 노드에 어떤 스타일이 적용될지 에 대한 정보를 가진다.

3. 렌더 트리 생성

4. Layout(혹은 Reflow)

렌더 트리를 기반으로 각 요소의 정확한 위치(x, y), 크기(width, height)를 계산하는 단계다. 폰트, 이미지 크기, 뷰포트 크기 등이 영향을 미친다. 레이아웃 계산은 문서의 크기나 요소가 바뀔 때마다 전체 페이지 혹은 일부 요소들의 레이아웃을 다시 계산하는 작업이 발생할 수도 있다.

5. Paint

Layout에서 계산된 위치 정보와 크기를 바탕으로 브라우저가 화면을실제 픽셀 단위로 그리는 작업 을 한다. 이 과정에서 CPU가 많이 사용된다.

6. Composite

웹 페이지는 여러 레이어 로 나뉘는데, 해당 레이어들을 GPU에 전달해서 화면에 조합하는 과정이다. 애니메이션, 3D, transform, opacity(투명도) 등은 각각 별도의 레이어로 만들어져서 성능 향상을 도모한다.

7. 화면 출력

최종적으로 GPU가 각 레이어를 조합해 하나의 완성된 프레임을 화면에 표시한다.

사용자가 폭증하면 서버가 불안정해지고 부하가 가증될 것이다. 이럴 때 어떤 기술을 사용해서 해결할까?

네트워크가 안정적이다 라고 말할 때의 안정성은 특정 기능을 언제든 균일한 성능으로 수행할 수 있는 특성 으로 정의될 수 있다. 그렇다면 안정성은 어떻게 수치화할 수 있을까? 안정성의 정도를 나타내는 용어로 가용성 과 고가용성 이라는 용어가 있다.

가용성

가용성 이란 컴퓨터 시스템이 특정 기능을 실제로 수행할 수 있는 시간의 비율이다. 다시 말해, 전체 사용 시간 중에서 정상적인 사용 시간을 의미한다. 이를 수식으로 나타내면 다음과 같다.

$가용성 = \frac{업타임}{다운 타임}$

업타임이란 정상적인 사용시간을, 다운 타임이란 정상적인 사용이 불가능한 시간을 의미한다. 해당 수식의 결괏값이 크다는 것은, 전체 사용 시간 중에서 대부분을 사용 가능하다는 의미이며, 이를 가용성이 높다 라고 말한다. 가용성이 높은 성질을 고가용성(HA; High Availability)

일반적으로 안정적이라고 평가받는 시스템은 99.999% 이상을 목표로 한다. 9가 다섯개 라는 의미에서 파이브 나인스 라고도 한다.

가용성을 높이려면 다운타임을 낮춰야 한다. 다운타임의 발생 원인을 모두 찾아 원천적으로 차단하기는 실질적으로 어려우므로, 문제가 발생하덜도 계속 가능할 수 있도록 설계하는 것이 중요하다. 문제가 발생하덜도 기능할 수 있는 능력을 결함 감내 라고 부른다.

이중화

이중화 란 결함을 감냏여 가용성을 높이기 위한 가장 기본적이고 대표적인 방법으로, 쉽게 말해서 예비(백업)을 마련하는 방법 이다.

이중화할 수 있는 대상은 다양하다. 서버 컴퓨터 네트워크 인터페이스(NIC) 스위치 와 같은 물리적 장비 뿐만 아니라, 데이터베이스 웹 서버 프로그램 등도 이중화할 수 있는 대상이다. 이중화할 수 있는 대상들은 대부분 문제가 발생할 경우 시스템 전체가 중단될 수 있는 대상 이라는 공통점이 있다. 문제가 발생할 경우 시스템 전체가 중단될 수 있는 대상 을 가리키는 용어가 있는데, 이것이 바로 단일 장애점(SPOF; Single Point Of Failure) 이다.

예를 들어, 다음 그림에서 라우터가 고장나면 제공받는 서비스 전체가 동작하지 않기 때문에 SPOF는 라우터이다.

가용성을 높이기 위해서는 SPOF를 이중화하는 것이 좋다.

이중화 구성 방식

이중화 구성에는 크게 두 가지 방식이 있다. 액티브/스탠바이(active-standby) 와 액티브/액티브(active-active) 이다.

액티브 란 가동 상태를 의미하며 스탠바이 는 액티브의 백업으로서 대기하는 상태를 의미한다.

액티브/스탠바이

한 시스템은 가동하고, 다른 시스템은 백업 용도로 대기 상태(스탠바이)로 두는 이중화 구성 방식이다. 시스템에 문제가 발생할 경우 스탠바이 시스템이 자동으로 액티브 시스템을 대신하여 동작한다. 이렇게 자동전환 되는 기능을 페일오버(failover) 라고 한다.

하지만, 두 장비가 동시에 가동되는 것은 아니기에 하나의 장비를 사용할 때에 비해 성능상의 큰 변화를 기대하기는 어렵다.

액티브/액티브

두 시스템 모두를 가동 상태로 두는 구성 방식이다. 이렇게 구성하면 부하를 분산시킬 수 있어 성능상의 이점을 가질 수 있다. 다만, 한 시스템에 문제가 발생하면 순간적으로 다른 시스템에 부하가 급증할 수 있으며, 이로 인해 추가적인 문제가 발생할 수 있다.

다중화

이중화가 무언가를 이중으로 두는 기술 이라면, 무언가를 여러 개 두는 기술 인 다중화도 있다. 다중화하면 이중화된 구성에 비해 더욱 안정적인 운영이 가능하다.

이중화/다중화의 사례로 윈도우에서 사용되는 티밍 과 리눅스에서 사용되는 본딩이 있다. 두 기술은 여러개의 네트워크 인터페이스(NIC)를 이중화/다중화하여 마치 더 뛰어나고 안정적인 성능을 보유한 하나의 인터페이스처럼 보이게 하는 기술이다. 예를 들어, 1Gbps 속도를 지원하는 인터페이스 세 개를 티밍하여 하나의 3Gbps 인터페이스를 사용하는 것과 같은 효과를 얻을 수 있다.

로드 밸런싱

고가용성을 요구하는 호스트는 일반적으로 서버이므로, 서버 중심으로 얘기해보자. 서버를 다중화했더라도 특정 서버에만 트래픽이 몰릴 경우, 가용성이 떨어질 수 있다. 트래픽의 사전적 정의는 주어진 시점에 네트워크를 경유한 데이터의 양 인데, 일반적으로 트래픽 측정은 노드에서 이루어지므로 주어진 시점에 특정 노드를 경유한 패킷의 양 이라고 이해하면 되겠다.

트래픽의 고른 분배를 위해 사용되는 기술이 로드 밸런싱(load balancing) 이다. 로드 밸런싱은 로드 밸런서 에 의해 수행된다. 로드 밸런서는 L4 스위치 L7 스위치 로 수행할 수도 있지만, 로드 밸런싱 기능을 제공하는 소프트웨어를 설치하면 일반 호스트로도 로드 밸런서를 사용할 수 있다.

로드 밸런서는 다음 그림처럼 이중화나 다중화된 서버와 클라이언트 사이에 존재한다.

클라이언트는 로드 밸런서에 요청을 보내고, 로드 밸런서는 해당 요청을 각 서버에 균형있게 분배한다.

다중화된 서버 환경에서 어떤 서버에 문제가 생긴다면 다른 서버들이 이를 빠르게 감지할 수 있어야 할텐데, 현재 상태를 주기적으로 체크하는 검사를 헬스 체크 라고 한다. 이 헬스 체크는 주로 로드 밸런서에 의해 수행된다.

로드 밸런싱 알고리즘

로드 밸런서가 요청을 전달할 수 있는 서버가 여러 개 있을 경우, 어떤 서버에 요청을 전달해야 할까? 부하가 균등하게 분산되도록 부하 대상을 선택하는 방법을 로드 밸런싱 알고리즘 이라고 한다.

대표적인 로드 밸런싱 알고리즘에는 단순히 서버를 돌아가며 부하를 전달하는 라운드 로빈 알고리즘(round robin) 과 연결이 적은 서버부터 우선적으로 부하를 전달하는 최소 연결 알고리즘(least connection) 이 있다.

두 알고리즘은 가중치 를 부여해서 알고리즘에 따라 동작하되 가중치가 높은 서버가 더 많이 선택되어 더 많은 부하를 받도록 동작할 수도 있는데, 이를 각각 가중치 라운드 로빈 알고리즘 과 가중치 최소 연결 알고리즘 이라 한다.

라운드 로빈 알고리즘이 아래 그림과 같이 단순히 서버를 돌아가며 부하를 전달한다면, 가중치 라운드 로빈 알고리즘은 두 번째 그림과 같이 가중치가 다섯 배인 서버 1에 다섯 배 많은 부하를 전달한다.

암호와 인증서

멀리 떨어진 컴퓨터와 민감한 메시지를 주고 받기 위해서는 암호화가 필요하다.

암호화 란 원문 데이터를 알아볼 수 없는 형태로 변경하는 것을, 복호화 란 암호화된 데이터를 원문 데이터로 되돌리는 것을 의미한다.

대칭 키 암호화 방식과 공개 키 암호화 방식

키와 원문 데이터 에 수학적 연산 과정을 거치면 암호문 이 생성된다. 이 수학적 연산 과정을 암호화 알고리즘 이라 한다.

주고 받는 데이터를 암호화하고 복호화하는 방법에는 대칭 키 암호화와 비대칭 키(공개 키) 암호화 방식이 있다.

대칭 키 암호화 방식

다음 그림과 같이 암호화와 복호화에 동일한 키를 사용하는 방식이다.

다만, 이 방식은 상대방에게 안전하게 키를 전달하기가 어렵다는 문제가 있다. 암호화 키와 복호화 키가 동일하기 때문에, 키가 유출된다면 큰 문제가 발생할 것이다.

키를 안전하게 상대방과 공유하는 방법 은 사실상 메시지를 안전하게 상대방과 공유하는 방법 과 다를 바가 없으므로, 그 방법으로 메시지를 주고받으면 되지, 굳이 암호화를 할 필요가 없을 것이다.

그래서 등장한 것이 공개 키 암호화(비대칭키 암호화) 방식이다.

공개 키 암호화(비대칭키 암호화) 방식

암호화를 위한 키와 복호화를 위한 키가 다른 방식이다. 이 한 쌍의 키를 각각 공개 키 와 개인 키 라 부른다. 암호화를 위해 사용된 공개 키 는 이름처럼 누구에게나 공개해도 무방하고, 암호화만을 위해 사용되었기 때문에 원문 메시지를 유추할 수 있지도 않다.

만약, A가 B에게 안녕, 나는 A야 라는 문자열을 안전하게 전송하고자 한다면, 어떤 일이 일어나는지 확인해보자.

1. A가 B의 공개 키를 요청하고, B는 A에게 공개 키를 전달한다. (공개 키는 그냥 전송해도 된다.)
2. A는 전달받은 공개 키로 메시지를 암호화하고, B에게 전송한다. (제 3자가 보아도 암호문을 이해할 수 없다.)
3. 개인 키를 가지고 있는 B가 암호를 복호화하여 안녕 나는 A야 라는 문자열을 확인할 수 있다.

공개 키 암호화 방식은 대칭 키 암호화 방식에 비해 암호화 및 복호화에 시간과 부하가 상대적으로 많이 들지만, 키를 안전하게 공유할 수 있다는 장점이 있다. 하지만, 대칭 키 암호화는 암호화 및 복호화를 빠르게 수행할 수 있기 때문에, 이 두 방식을 결합하여 사용하는 방식이 많다.

대칭 키 암호화 방식 + 공개 키 암호화 방식

공개 키 암호화 방식에서 복호하여 메시지 원문을 얻었다면, 이 방식에서는 대칭 키를 복호화한다고 생각하면 편하다.

대칭 키(세션 키)를 안전하게 공유하는 것이 문제 였기 때문에, 이 대칭 키를 공개 키 암호화 방식 으로 암호화 한 뒤, 전달 받는 쪽에서는 개인키로 복호화 하여 대칭 키를 얻고, 그 대칭 키로 메시지 본문을 얻는 방식이다. 이러한 방식으로 활용되는 대칭 키를 세션 키 라고한다.

인증서와 디지털 서명

인증서

인증서 라는 용어는 일반적으로 공개 키 인증서 를 일컫는다. 공개 키 인증서 란 공개 키와 공개 키의 유효성을 입증하기 위한 전자 문서이다.

내 컴퓨터가 웹 서버와 공개 키 암호화 방식으로 통신한다고 가정했을 때, 나는 웹 서버로부터 공개 키를 전달받게 될 것이다. 그런데, 과연 이 공개키를 신뢰할 수 있는가?

이에 대한 신뢰성을 위해 웹 서버는 아래와 같이 여러 내용을 포함한 인증서를 전송한다.

이러한 인증서는 인증 기관(CA; Certification Authority) 라는 제 3의 기관에서 발급한다. 인증 기관 은 인증서의 발급, 검증, 저장과 같은 역할을 수행할 수 있는 공인 기관이다.

인증서에는 이 공개 키 인증서는 진짜야. 내가 보증할게 라는 내용을 담은 서명(signature)이 있고, 이 값을 바탕으로 인증서를 검증할 수 있다.

서명 값은 인증서 내용에 대한 해시 값(fingerprint) 을 CA 의 개인 키로 암호화하는 방식 으로 만들어진다. CA는 이렇게 얻어낸 정보를 서명 값으로 삼아 클라이언트에게 인증서와 함께 전달한다.

디지털 서명

디지털 서명 이란 개인 키로 암호화 된 메시지를 공개 키로 복호화함으로써 신원을 증명하는 절차를 말한다.

CA가 보낸 서명 은 해시 값을 개인키로 암호화 한 것 이라고 했다. 그럼 우린 이 서명을 복호화하여 해시 값을 얻고, 우리가 직접 인증서 데이터에 대한 해시 값을 구한 뒤, 비교할 것이다. 값이 일치한다면 인증서는 확실히 CA의 개인 키로 만들어졌음을 보장한다.

HTTPS: SSL과 TLS

지금까지 배운 대칭 키 암호화와 공개 키 암호화 방식, 공개 키 인증서를 기반으로 동작하는 프로토콜로 SSL(Secure Socket Layer) 과 TLS(Transport Layer Security) 가 있다. SSL과 TLS는 인증과 암호화를 수행하는 프로토콜이며, TLS는 SSL을 계승한 프로토콜이다.

SSL/TLS를 사용하는 대표적인 프로토콜은 HTTPS(HTTP over TLS) 이다. HTTPS 는 HTTP 메시지의 안전한 송수신을 위해 개발된 프로토콜이다.

오늘날 주로 사용되는 TLS 1.3을 기반으로 HTTPS가 어떻게 동작하는지 간략하게 알아보자. HTTPS 메시지는 크게 다음과 같은 단계를 거쳐 송수신한다.

1. TCP 쓰리 웨이 핸드셰이크 (4장 학습)
2. TLS 핸드셰이크
3. 암호화된 메시지 송수신

1. TCP 쓰리 웨이 핸드셰이크

1번은 이전에 학습했다. TCP 연결을 수립하기 위해 두 호스트가 각각 SYN, SYN+ACK, ACK 플래그가 설정된 TCP 세그먼트를 주고받는 것이 쓰리 웨이 핸드셰이크였다.

2. TLS 핸드셰이크

꽤 복잡하지만, TLS는 암호학에 대한 기반 지식을 요하기 때문에 처음부터 모든 메시지와 의미를 외울 필요는 없다고 한다. TLS 핸드셰이크의 핵심은 두 가지이다. 1. 암호화 통신을 위한 키를 교환한다 2. 인증서 송수신과 검증이 이루어진다.

위 그림의 메시지를 살펴보자.

Client Hello

가장 먼저 클라이언트는 ClientHello 메시지를 보낸다. 해당 메시지는 암호화된 통신을 위해 서로 맞춰 봐야 할 정보들을 제시하는 메시지이다. 지원되는 TLS 버전 사용 가능한 암호화 방식과 해시 함수 키를 만들기 위해 사용할 클라이언트의 난수 등이 포함되어 있다. 이 때, 사용 가능한 암호화 방식과 해시 함수를 담은 정보를 암호 스위트(cipher suite) 라고 한다. 다음 그림처럼 생겼다.

Server Hello

서버는 Client Hello 에 대한 메시지 응답으로 ServerHello 메시지를 전송한다. Server Hello 메시지는 제시된 정보들을 선택하는 메시지이다. 따라서 이 메시지에는 선택된 TLS 버전 암호 스위트 등의 정보 키를 만들기 위해 사용할 서버의 난수 등이 포함되어 있다.

Client Hello 와 Server Hello 메시지를 주고 받으면 암호화된 통신을 위해 사전 협의해야 할 정보들이 결정된다. 이렇게 결정된 정보를 토대로 서버와 클라이언트는 암호화에 사용할 키를 만들 수 있다. 이것이 TLS 핸드셰이크에서의 키 교환이다.

이 단계 이후부터 클라이언트와 서버는 키로 암호화된 암호문을 주고받을 수 있게 된다.

Certificate , CertificateVerify

서버는 인증서 를 의미하는 Certificate 메시지와 검증을 위한 디지털 서명 을 의미하는 CertificateVerify 메시지를 전송한다.

클라이언트는 이 메시지를 토대로 서버의 공개 키를 검증하게 된다.

Finished

이어서 서버와 클라이언트는 TLS 핸드셰이크의 마지막을 의미하는 Finished 메시지를 주고 받는다.

이 후, TLS 핸드셰이크를 얻어낸 키를 기반으로 암호화된 데이터를 주고받는다. TLS 1.3 에서는 Finished 메시지와 함께 암호화된 메시지를 전송할 수 있다.

HTTPS에 대해서 설명해주세요. HTTPS는 HTTP와 달리 SSL/TLS 프로토콜을 통해 데이터를 암호화하여 전송하기 때문에 보안적인 측면에서 우수한 장점이 있습니다.

SSL/TLS이 뭔가요? SSL은 컴퓨터 네트워크에서 통신 보안을 제공하는 프로토콜입니다. SSL은 핸드셰이크 과정에서 인증 기관, 인증서, 공개키 암호화, 대칭키 암호화를 사용하여 클라이언트와 서버 간의 암호화된 통신을 가능하게 합니다. TLS는 SSL이 표준화되면서 변경된 이름입니다.

대칭키 암호화 방식에 대해 설명해주세요. 대칭키 암호화는 하나의 동일한 키를 사용하여 암호화와 복호화를 수행하는 방식입니다. 암호화 및 복호화 속도가 빠르다는 장점이 있지만, 안전하게 키를 공유하기 어렵다는 단점이 있습니다.

비대칭키(공개키) 암호화 방식에 대해서 설명해주세요. 비대칭키 암호화는 서로 다른 키를 사용하여 암호화와 복호화를 수행하는 방식입니다. 암호화에 사용하는 공개키와 복호화에 사용하는 개인키 한 쌍으로 이루어져 있으며, 공개키는 누구나 알 수 있지만 개인키는 비밀로 유지됩니다. 이 방식은 키를 안전하게 공유할 수 있다는 장점이 있지만, 대칭키 암호화보다 연산 속도가 느리다는 단점이 있습니다.

전자 서명에 대해서 설명해주세요. 전자 서명은 비대칭키 암호화 방식을 사용하여, 개인키로 데이터를 암호화하고 공개키로 이를 검증하는 기술입니다. 전자 서명이 공개키로 검증 가능하다는 점을 이용해, 특정 개인이 서명했음을 신뢰할 수 있습니다.

HTTPS 암호화 과정에 대해 설명해주세요. (SSL Handshake의 동작 과정을 설명해 주세요.) SSL HandShake는 크게 4단계로 이루어집니다. 첫 번째로, 클라이언트는 ClientHello 메시지를 보냅니다. 이 메시지에는 지원하는 TLS 버전, 암호 스위트, 키 생성을 위한 클라이언트 난수 등이 포함되어 있습니다. 두 번째로 서버는 Client Hello 에 대한 메시지 응답으로 ServerHello 메시지를 전송합니다. 이 메시지에는 선택된 TLS 버전 암호 스위트 키 생성을 위한 서버의 난수 등이 포함되어 있습니다. 세 번째로, 클라이언트는 서버의 공개키로 세션 키를 암호화하여 서버에 보내면, 서버는 자신의 개인 키로 복호화하여 세션 키를 얻게 됩니다. 이후 클라이언트와 서버는 이 세션 키를 이용해 대칭키 암호화 방식으로 데이터를 주고 받습니다. 마지막으로, 클라이언트와 서버는 대칭키 암호화를 사용해 본격적인 HTTPS 통신을 시작합니다.

1. 클라이언트가 메시지를 주고받고자 하는 대상을 식별해야 함
2. 송수신하고자 하는 정보를 식별해야 함

1번은 도메인 네임을 통해, 2번은 URL과 URN을 통해 식별할 수 있다.

각각에 대해 먼저 살펴보자.

DNS(Domain Name System)

DNS 란 계층적이고 분산된 도메인 네임에 대한 관리체계이자 이를 관리하는 애플리케이션 계층 프로토콜이다.

도메인 네임과 네임 서버

네트워크 상의 어떤 호스트를 특정하기 위해 IP 주소를 사용한다고 했는데, 오로지 IP만 사용하기에는 번거로울 수 있다. 이는 호스트의 IP 주소는 언제든지 바뀔 수 있고, 기억하기 어렵다는데서 기인한다.

그래서 사용자는 일반적으로 상대 호스트를 특정하기 위해 도메인 네임 을 많이 사용한다. 예를 들어, www.example.com 과 같은 문자열이 도메인 네임이다.

도메인 네임과 IP 주소는 묶어서 관리하는데, 이를 관리하는 서버를 네임 서버(혹은 DNS 서버) 라고 부른다. 네임 서버(DNS 서버)는 호스트의 도메인 네임과 IP 주소를 모아 관리하는 공용 전화번호부와 같은 역할을 한다.

도메인 네임을 네임 서버에 질의하면, 해당 도메인 네임에 대한 IP 주소를 알아낼 수 있다. 물론, 반대도 가능하다.

도메인 네임을 쓰는 이유

1. 도메인 네임은 IP에 비해 기억하기 쉽다.
2. IP 주소가 바뀌더라도, 바뀐 IP 주소에 도메인 네임을 대응하면 되어 IP 주소만으로 호스트를 특정하는 것보다 간편하다.

도메인 네임 관리

도메인 네임은 점(.)을 기준으로 계층적으로 분류된다. 최상단에 루트 도메인이 있고, 그 다음 단계인최상위 도메인이 있으며, 계속 그 다음 단계의 도메인이 존재한다. 다음 그림을 보자.

흔히 최상위 도메인을 도메인 네임의 마지막 부분이라고 생각하기 쉬운데, 사실 루트 도메인도 도메인 네임의 일부이다. 다만 일반적으로 루트 도메인을 생략해서 표기해서, 우리가 흔히 볼 수 있는 www.example.com 과 같은 주소의 마지막에는 점(.)이 생략되어 있다고 생각하면 된다.

www.example.com 에서 www 는 3단계 도메인이고, 도메인의 단계는 더 늘어날 수 있지만, 일반적으로는 3~5 단계 정도이다. 그리고 위 주소 처럼 도메인 네임을 모두 포함하는 도메인 네임을 전체 주소 도메인 네임(FQDN; Fully-Qualified Domain Name) 이라고 한다.

계층적 네임 서버

DNS가 계층적이고 분산된 도메인 네임에 대한 관리체계라고 했는데, 계층적인 도메인 네임을 효율적으로 관리하기 위해 네임 서버 또한 계층적인 형태를 이룬다.

IP 주소를 모르는 상태에서 도메인 네임에 대응되는 IP 주소를 알아내는 과정을 리졸빙(resolving) 한다라고 하고, 이 과정에서 아래와 같은 다양한 네임 서버들이 사용된다.

로컬 네임 서버, 루트 네임 서버, TLD(최상위 도메인) 네임 서버, 책임 네임 서버에 대해 알아보자.

로컬 네임 서버(local name server)

클라이언트와 맞닿아 있는 네임 서버로, 클라이언트가 도메인 네임을 통해 IP 주소를 알아내고자 할 때 가장 먼저 찾게되는 네임 서버이다. 로컬 네임 서버의 주소는 1. ISP에서 할당해주거나 2. 공개 DNS 서버를 이용하거나 로 결정된다. 일반적으로는 ISP에서 할당해 주는 경우가 많지만, 구글의 8.8.8.8 8.8.4.4 와 클라우드 플레어의 1.1.1.1 와 같은 공개 DNS 서버를 이용할 수도 있다.

만약 로컬 네임서버가 대응되는 IP 주소를 알고 있다면, 클라이언트에게 IP 주소를 알려준다. 만약 로컬 네임서버가 대응되는 IP 주소를 모를 경우에는 루트 네임 서버 에게 해당 도메인 네임을 질의하게 된다.

루트 네임 서버(root name server)

루트 네임 서버는 루트 도메인을 관장하는 네임 서버로, 질의에 대해 TLD 네임 서버의 IP 주소를 반환하는 역할을 한다. 단순히 다음 네임 서버의 위치(IP)를 반환하는 역할만 수행한다.

TLD(최상위 도메인) 네임 서버

TLD를 관리하는 네임 서버이다. TLD 네임 서버는 다음 그림과 같이 질의에 대해 TLD 하위 도메인 네임을 관리하는 네임 서버 주소를 반환한다. 단순히 다음 네임 서버의 위치(IP)를 반환하는 역할만 수행한다.

책임 네임 서버(authoritative name server)

자신이 관리하는 도메인 영역의 질의에 대해서는 다른 서버에게 떠넘기지 않고 곧바로 답할 수 있는 네임 서버이다. 일반적으로 로컬 네임 서버는 책임 네임 서버로부터 원하는 IP 주소를 얻어낸다.

결국 아래처럼 네임 서버들은 계층적인 구조를 띠고 있다.

재귀적 질의와 반복적 질의

재귀적 질의(recursive query)

재귀적 질의 는 클라이언트가 로컬 네임 서버에게 도메인 네임을 질의하면, 로컬 네임 서버는 루트 네임 서버에게, 루트 네임 서버는 TLD 네임 서버에게, TLD 네임 서버가 다음 단계에 질의하는 과정을 반복하며 최종 응답을 역순으로 전달받는, 즉 재귀적으로 질의가 이루어지는 방식이다.

반복적 질의(iterative query)

반복적 질의 는 로컬 네임 서버의 역할이 두드러진다. 반복적 질의란 클라이언트가 로컬 네임 서버에게 IP 주소를 알고 싶은 도메인 네임을 질의하면, 로컬 네임 서버는 루트 도메인에게 질의해서 다음으로 질의할 네임 서버의 주소를 응답 받고, 이렇게 다음으로 질의할 네임 서버의 주소를 응답받는 과정을 반복하다가 최종 응답 결과를 클라이언트에게 알려주는 방식이다.

DNS 캐시

위의 리졸빙 방식은 여러 단계를 거쳐야 해서 시간이 오래 걸리고 네트워크 상의 메시지 수가 지나치게 늘어날 수 있다는 단점이 있다. 이를 보완하기 위해, 네임 서버들이 기존에 응답받은 결과를 임시로 저장했다가 추후 같은 질의에 이를 활용할 수 있는데, 이를 DNS 캐시 라고 한다. 임시 저장된 값은 TTL(Time To Live) 라는 값이 만료되면 사라진다.

자원을 식별하는 URI

송수신하고자 하는 정보를 식별하기 위한 방식인 URI와, URI를 식별 정보 기준으로 분류한 개념인 URL, URN에 대해 살펴볼 것이다.

이 개념들을 이해하기 전, 자원(resource) 에 대한 이해가 필요하다.

자원 이란 네트워크상의 메시지를 통해 주고받는 대상을 의미한다. 이는 HTML 파일이 될 수도 있고, 이미지나 동영상, 혹은 텍스트 파일이 될 수도 있다.

네트워크 상에서 자원을 주고받으려면 자원을 식별할 수 있어야 한다. 자원을 식별할 수 있는 정보를 URI(Uniform Resource Identifier) 라고 부른다.

위치를 이용해 자원을 식별하는 방식을 URL(Uniform Resource Locator) 이라 하고, 이름을 이용해 자원을 식별하는 방식을 URN(Uniform Resource Name) 이라 한다.

URL(Uniform Resource Locator)

오늘날 더 많이 사용되는 방식은 URL 이다. 일반적인 URL 형식은 다음과 같다.

각각의 부분에 대해 살펴보자.

1. scheme

scheme 은 자원에 접근하는 방법을 의미한다. 일반적으로 사용할 프로토콜이 명시되는데, HTTP를 사용하여 자원에 접근할 때는 http:// 를 사용하고, HTTPS를 사용하여 자원에 접근할 때는 https:// 을 사용한다.

2. authority

authority 에는 호스트를 특정할 수 있는 정보, 이를 테면 IP 주소 혹은 도메인 네임이 명시된다. 콜론 뒤에 포트 번호를 덧붙일 수도 있다.

3. path

자원이 위치한 경로가 명시된다. 자원의 위치는 슬래시(/)를 기준으로 표현되고, 최상위 경로 또한 슬래시로 표현된다.

만약, 최상위 경로(/) 아래, home(/home) 아래, images(/home/images) 아래에 a.png 이라는 자원이 있다고 하면

a.png의 path는 /home/images/a.png 이 된다.

4. query

URL 구문만으로 자원의 위치를 식별할 수 있는 경우도 있지만, 더 많은 정보 가 필요할 때 사용할 수 있는 것이 쿼리 문자열(혹은 쿼리 파라미터) 이다. 쿼리 문자열은 물음표(?)로 시작되는 <키=값>의 형태로 앰퍼샌드(&)를 사용하여 여러 쿼리 문자열을 연결할 수 있다. 아래와 같이 말이다.

fragment

fragment는 자원의 한 조각을 가리키기 위한 정보 이다. 흔히 HTML 파일과 같은 자원에서 특정 부분을 가리키기 위해 사용된다. 만약 #section-1.1.2 라는 fragment가 있다면, HTML 파일의 특정부분으로 이동하여 보일 것이고, fragment가 없다면, HTML의 첫 부분이 보일 것이다.

URN(Uniform Resource Name)

만약, 자원의 위치가 변한다면 URL은 유효해지지 않을 수 있다. 이것은 URL의 고질적인 문제 중 하나인데, URN은 이를 보완할 수 있다.

URN은 자원에 고유한 이름을 붙이는 이름 기반 식별자다. 따라서, 자원의 위치와 무관하게 자원을 식별할 수 있다는 장점이 있다.

다음 URN은 ISBN이 0451450523인 도서를 나타내는 URN 예시이다.

urn:isbn:0451450523

이와 같은 URN을 이용하면 위치나 프로토콜과 무관하게 자원을 식별할 수 있다. 다만 URN은 아직 URL 만큼 널리 채택된 방식은 아니기에 자원을 식별할 URI로는 URL이 더 많이 사용된다.

HTTP(Hypertext Transfer Protocol)

HTTP는 응용 HTTP에는 중요한 네 가지 특성이 있다.

1. 요청과 응답을 기반으로 동작
2. 미디어 독립적
3. 상태를 유지하지 않음
4. 지속 연결을 지원

이 특성들에 대해 살펴보자.

HTTP의 특성

요청-응답 기반 프로토콜

HTTP는 클라이언트-서버 구조 기반의 요청-응답 프로토콜 이다. HTTP는 클라이언트와 서버가 서로 HTTP 요청 메시지와 HTTP 응답 메시지를 주고받는 구조로 동작한다. 같은 HTTP 메시지일지라도, HTTP 요청 메시지와 HTTP 응답 메시지는 형태가 다르다.

미디어 독립적 프로토콜

그렇다면 HTTP로는 어떤 자원을 주고받을 수 있을까? HTTP는 자원의 특성을 제한하지 않는다. 다시 말해서, HTTP는 주고받을 자원의 특성과 무관하게 그저 자원을 주고받을 수단(인터페이스) 역할을 수행한다.

HTTP에서 메시지로 주고받는 자원의 종류를 미디어 타입 혹은 MIME 타입(Multipurpose Internet Mail Extensions Type) 이라고 부른다.

미디어 타입은 기본적으로 슬래시를 기준으로하는 타입/서브타입 형식으로 구성된다. 타입 은 데이터의 유형을 나타내고, 서브타입 은 주어진 타입에 대한 세부 유형을 나타낸다. text/html text/plain image/png 가 그 예시다.

또한 미디어 탕비에는 부가적인 설명을 위해 선택적으로 매개변수가 포함될 수도 있다. 매개변수는 타입/서브타입;매개변수=값 의 형식으로 표현된다.

예를 들어 type/html;charset=UTF-8 은 미디어 타입이 HTML 문서 타입이며, HTML 문서 내에서 사용된 문자는 모두 UTF-8로 인코딩되었음을 의미한다.

스테이트리스 프로토콜

HTTP는 상태를 유지하지 않는 스테이트리스(stateless) 프로토콜이다. 이는 서버가 HTTP 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않는다는 의미이다. 이러한 특성 때문에 클라이언트의 모든 HTTP 요청은 기본적으로 독립적인 요청으로 간주된다.

만약 HTTP가 상태를 유지하는 프로토콜이었다면 어땠을까? 서버가 모든 클라이언트의 상태 정보를 유지해야 하기 때문에, 서버에 부담이 갈 것이다. 또한, 서버가 여러 대로 구성될 경우, 모든 서버가 모든 클라이언트의 상태 정보를 공유해야 하는데 이는 매우 번거롭고 어려운 작업이다. 그리고 클라이언트는 자신의 상태를 기억하는 특정 서버하고만 상호 작용할 수 있게 되어, 특정 클라이언트가 특정 서버에 종속될 수 있다.

HTTP가 처음 만들어졌을 때부터 오늘날까지 이어지는 중요한 설계 목표는 확장성(scalability) 과 견고성(robustness) 이다. 스테이트리스한 특성은 언제든 쉽게 서버를 추가할 수 있게 해주어 높은 확장성을, 서버 중 하나에 문제가 생겨도 쉽게 다른 서버로 대체가 가능하다는 점 때문에 높은 견고성을 보장할 수 있다.

지속 연결 프로토콜

기본적으로 HTTP는 TCP 상에서 동작하는데, HTTP는 비연결형 프로토콜이지만, TCP는 연결형 프로토콜이다. 따라서 초기의 HTTP 버전은 쓰리 웨이 핸드셰이크를 통해 TCP 연결을 수립한 후, 요청에 대한 응답을 받으면 연결을 종료하는 방식으로 동작했다. 만약, 이후 추가적인 요청-응답이 필요하다면 다시 TCP 연결을 수립해야했다. 이러한 방식을 비지속 연결 이라고 한다.

하지만, 최근 대중적으로 사용되는 HTTP 버전(HTTP 1.1 이상)은 지속 연결 이라는 기술을 제공한다. 이는 킵 얼라이브(keep-alive) 라고도 부른다. 이는 하나의 TCP 연결상에서 여러 개의 요청-응답을 주고받을 수 있는 기술이다. 아래 그림을 통해 비지속 연결과 지속 연결의 차이점을 볼 수 있다.

HTTP 버전

https://developer.mozilla.org/ko/docs/Web/HTTP/Guides/Evolution_of_HTTP

HTTP 메시지 구조

대중적으로 사용되는 HTTP 1.1 버전의 메시지를 위주로 학습하겠다. HTTP 메시지의 구조는 크게 다음과 같다.

HTTP 메시지는 시작 라인 필드 라인 메시지 본문 으로 이루어져 있다. 필드 라인 과 메시지 본문 사이에는 빈 줄바꿈이 있다.

시작 라인

HTTP 메시지가 HTTP 요청 메시지일 경우, 시작 라인 은 요청 라인이 된다. HTTP 메시지가 HTTP 응답 메시지일 경우, 시작 라인 은 상태 라인이 된다.

요청 라인(request-line)

요청 라인의 형식은 다음과 같다.

메서드(method)

메서드 란 클라이언트가 서버의 자원(요청 대상)에 대해 수행할 작업의 종류를 나타낸다. 대표적으로 GET POST PUT DELETE 등이 있다.

요청 대상(request-target)

요청 대상은 HTTP 요청을 보낼 서버의 자원을 의미한다. 보통 이곳에는 (쿼리가 포함된) URL의 경로가 명시된다. http://www.example.com/hello?q=world 로 요청을 보낼 경우, 요청 대상은 /hello?q=word가 된다.

HTTP 버전(HTTP-version)

이름 그대로 사용된 HTTP 버전을 의미한다. HTTP/<버전> 과 같이 표기되며, HTTP 버전 1.1은 HTTP/1.1 로 표기된다.

상태 라인(status-line)

상태 라인의 형식은 다음과 같다.

상태 코드(status code)

요청에 대한 결과를 나타내는 세 자리 정수이다. 클라이언트는 상태 코드를 통해 요청이 어떻게 처리되었는지 판단할 수 있다. 예를 들어, 200 은 요청이 성공적으로 받아들여지고 수행되었음 을, 404 는 요청한 자원이 존재하지 않음 을 의미한다.

HTTP/1.1 200 OK HTTP/1.1 404 Not Found 와 같이 표현된다.

필드 라인

필드 라인에는 0개 이상의 HTTP 헤더가 명시된다. 그래서 이를 헤더 라인 이라고도 부른다. 필드 라인에 명시되는 각 HTTP 헤더는 콜론(:)을 기준으로 헤더 이름 고 하나 이상의 헤더 값 으로 구성 된다.

다음 그림에서 첫 줄을 제외한 부분이 HTTP 헤더이다.

이 부분은 다룰 내용이 꽤 있으니, 아래서 따로 정리하겠다.

메시지 본문(message-body)

HTTP 요청 혹은 응답 메시지에서 본문이 필요할 경우 이는 메시지 본문 에 명시된다. 메시지 본문은 존재하지 않을 수도 있고, 다음과 같이 다양한 콘텐츠 타입이 사용될 수도 있다.

HTTP 메서드

HTTP 요청 메시지에서 사용될 수 있는 다양한 메서드를 학습해보자.

다음과 같은 종류가 있다.

GET - 가져다 주세요

GET 메서드는 특정 자원을 조회할 때 사용된다. 가장 흔히 사용되는 메서드 중 하나이며, 웹 브라우저에서도 빈번히 사용된다. GET 메서드에 요청 메시지 본문을 포함시키는 것은 바람직하지 않으며, 쿼리 문자열이 사용되는 경우가 많다.

HEAD - 헤더만 가져다 주세요

HEAD 메서드는 사실상 GET 메서드와 동일한 역할을 한다. 유일한 차이점은 응답 메시지에 메시지 본문이 포함되지 않는다는 것이다. 즉, 서버는 요청에 대한 응답으로 응답 메시지의 헤더만을 반환한다.

POST - 처리해 주세요

POST 메서드는 서버로 하여금 특정 작업을 처리하도록 요청하는 메서드이다. 처리할 대상은 흔히 메시지 본문으로 명시된다. 만약 성공적으로 POST 요청이 처리되어 새로운 자원이 생성되면, 서버는 응답 메시지의 Location 헤더를 통해 새로 생성된 자원의 위치를 클라이언트에게 알려줄 수 있다.

PUT - 덮어써 주세요

PUT 메서드는 쉽게 말해서 '덮어쓰기' 를 요청하는 메서드이다. 요청 자원이 없다면 메시지 본문으로 새롭게 생성하거나, 이미 자원이 존재한다면 메시지 본문으로 자원을 완전히 대체하는 메서드이다.

PATCH - 일부 수정해주세요

PATCH 메서드는 PUT 메서드와 비교하며 이해하는 것이 좋다. PUT 메서드가 덮어쓰기, 완전한 대체에 가깝다면, PATCH 메서드는 부분적 수정이다.

만약, 기존 데이터와 요청 데이터가 일치하는 정보가 있다면, 그 부분은 그대로 유지하고 일치하지 않는 부분만 덮어쓴다고 생각하면 된다.

DELETE - 삭제해 주세요

DELETE 메서드는 특정 자원을 삭제하고 싶을 때 사용하는 메서드다.

HTTP 상태 코드

상태 코드는 요청에 대한 결과를 나타내는 세 자리 정수이다. 상태 코드는 굉장히 다양하지만, 백의 자리 수를 기준으로 유형을 구분할 수 있다.

자주 사용되는 200번대 상태 코드부터 500 번대 상태 코드까지 자세히 알아보자.

200번대 : 성공 상태 코드

200번대 상태 코드는 요청이 성공했음 을 의미한다. 주로 사용되는 상태 코드는 200(OK) 201(Created) 202(Accepted), 204(No Content) 이다.

201(Created)

POST 요청을 통해 서버에 새로운 자원을 성공한 경우, 상태 코드 201로 요청이 성공했으며 새로운 자원이 만들어졌음을 알린다.

202(Accepted)

요청을 잘 받았으나, 아직 요청한 작업을 끝내지 않았음을 의미한다. 작업 시간이 긴 대용량 파일 업로드 작업이나 배치 작업과 같이 요청 결과를 곧바로 응답하기 어려운 상황에 사용된다.

204(No Content)

요청 메시지에 대해 성공적으로 작업을 완료했더라도 마땅히 메시지 본문으로 표기할 것이 없을 경우 상태코드 204로 응답할 수 있다. 200은 응답 본문이 있지만 204는 그렇지 않음을 기억하자.

300번대 : 리다이렉션 코드

리다이렉트 란 클라이언트가 요청한 자원이 다른 곳에 있을 때, 클라이언트의 요청을 다른 곳으로 이동시키는 것을 의미한다.

클라이언트가 요청한 자원이 다른 URL에 있을 경우, 서버는 응답 메시지의 Location 헤더를 통해 요청한 자원이 위치한 URL을 안내해줄 수 있다. 이를 수신한 클라이언트는 Location 헤더에 명시된 URL로 즉시 재요청을 보내어 새로운 URL에 대한 응답을 받게 된다.

리다이렉션의 유형은 크게 영구적인 리다이렉션 과 일시적인 리다이렉션 으로 구분된다.

영구적인 리다이렉션(permanent redirection)

영구적인 리다이렉션(permanent redirection) 은 자원이 완전히 새로운 곳으로 이동하여 경로가 영구적으로 재지정되는 것을 의미한다. 서버가 도메인을 이전하는 등 웹 사이트의 큰 개편이 있을 때 이런 영구적인 리다이렉션을 접할 수 있다.

영구적인 리다이렉션과 관련한 상태 코드로는 301과 308이 있다.

상태 코드 301과 308의 차이점은 클라이언트의 재요청 메서드 변경 여부 에 있다.

클라이언트가 처음에 POST 메서드로 요청을 보낸 뒤, Location 헤더에 명시된 경로로 재요청을 보내야 한다는 상황에서, 두 번째 요청 메서드는 다음 그림처럼 GET 요청으로 바뀔 수도 있다.

만약 클라이언트가 첫 번째 요청으로 POST 메서드를 보내고 상태 코드 308을 받았다면, 두 번째 요청에서도 POST 메서드를 유지하게 된다.

일시적인 리다이렉션(temporary redirection)

자원의 위치가 임시로 변경되었거나 임시로 사용할 URL이 필요한 경우에 주로 사용된다.

일시적인 리다이렉션과 관련한 상태 코드는 302, 303, 307이 있다.

302와 307은 앞에서 살펴본 것과 똑같이 동작한다.

303(See Other) 은, 첫 번째 요청의 메서드가 무엇이든지 간에, 두 번째 요청 메서드를 GET으로 하도록 강제한다.

400번대: 클라이언트 상태 에러 코드

400 번대 상태 코드는 클라이언트에 의한 에러가 있음 을 알려주는 상태 코드다. 서버가 처리할 수 없는 형태로 요청을 보냈거나, 존재하지 않는 자원에 대해 요청을 보내는 경우가 이에 해당한다.

400번대 상태 코드의 대표 유형은 다음과 같다.

400(Bad Request)

클라이언트의 요청이 잘못되었음을 알려주는 상태 코드다. 클라이언트의 요청 메시지의 내용이나 형식 자체에 문제가 있어, 서버가 요청 메시지를 올바르게 처리할 수 없는 경우가 이에 해당한다.

401(Unauthorized)

웹상에서 정보를 검색할 때, 모든 자원에 접근이 가능한 것은 아니다. 특정 자원에 접근하기 위해 인증이 필요할 때가 있는데, 요청에 대한 인증이 필요할 경우 서버는 401 상태 코드를 응답할 수 있다. 서버는 반드시 WWW-Authenticate 라는 헤더를 통해 인증 방법을 알려주어야 하는데, 이는 아래서 살펴보겠다.

403(Forbidden)

클라이언트의 권한이 충분하지 않다면 상태코드 403을 응답한다. 즉, 자원에 접근할 권한이 없음 을 의미한다.

404(Not Found)

접근하고자 하는 자원이 존재하지 않음을 알리는 상태 코드이다. 존재하더라도 공개하지 않는 자원에 대해 404를 응답하는 경우가 있다.

405(Method Not Allowed)

일부 메서드는 구현되어 있지 않을 수 있는데, 구현되지 않은 메서드로 요청을 보낸다면 405를 통해 해당 메서드의 미지원을 알린다.

500번대: 서버 에러 상태 코드

500번대 상태 코드 원인은 서버다. 클라이언트가 올바르게 요청을 보냈을 지라도 발생할 수 있는 서버 에러에 대한 상태 코드이다.

500(Internal Server Error)

서버의 예기치 못한 상황으로 인해 요청을 처리할 수 없음 이라는 의미이다. 다소 포괄적이기 때문에, 서버 내 에러를 통칭하기도 한다.

502(Bad Gateway)

클라이언트와 서버 사이에 위치한 중간 서버의 통신 오류를 나타내는 상태 코드다. 클라이언트와 서버 사이에 위치한 중간 서버가 유효하지 않거나 잘못된 응답을 받는다면 502를 응답한다.

503(Service Unavailable)

현재 서비스를 일시적으로 이용할 수 없음 을 의미한다. 서버가 과부하 상태에 있거나 일시적인 점검 상태일 때 볼 수 있다.

HTTP 헤더와 HTTP 기반 기술

HTTP 메시지의 두 번째 줄인 필드 라인에 대해 배워보자.

HTTP 헤더

HTTP 헤더는 필드 이름(헤더 이름):필드 값(헤더 값) 의 형식으로 이루어져 있다.

HTTP 요청시 자주 사용되는 헤더, HTTP 응답 시 주로 사용되는 헤더, HTTP 요청과 응답 모두에서 자주 활용되는 헤더 순으로 살펴보자.

요청 시 활용되는 HTTP 헤더

Host User-Agent Referer Authorization 에 대해 알아보자.

Host

Host는 요청을 보낼 대상 호스트를 나타내는 헤더이다. 주로 도메인 네임 으로 명시되며, 포트 번호가 포함될 수 있다.

User-Agent

유저 에이전트 란 웹 브라우저와 같이 HTTP 요청을 시작하는 클라이언트 측의 프로그램을 의미한다. 서버 입장에서는 이 헤더를 통해 클라이언트의 접속 환경을 유추할 수 있다.

Referer

클라이언트가 요청을 보낼 때 머무르고 있던 URL이 명시된다. 영문법적으로는 Referrer이 맞지만, 초기 개발 당시 오타로 인해 Referer 이라는 표기가 오늘날까지 사용되고 있다고 한다. 클라이언트의 유입 경로를 확인하는데 용이하다.

GET /page2.html HTTP/1.1
Host: www.example.com
Referer: https://www.google.com/search?q=example

위 예시에서 서버는 사용자가 구글에서 검색 후 들어왔다는 것을 알 수 있다.

Authorization

클라이언트의 인증 정보를 담는 헤더이다. 다음 처럼 인증 타입(type) 과 인증을 위한 정보(credentials) 가 차례로 명시된다.

Authorization : <type> <credentials>

인증 타입 종류는 다양하지만, 가장 기본적인 HTTP 인증 타입은 Basic이라는 타입이다. Basic 타입 인증은 username:password 와 같이 사용자 아이디와 비밀번호를 콜론을 이용해 합친 뒤, 이를 Base64 인코딩한 값을 인증 정보로 삼는 방식이다.

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

위 예시에서 Basic = 인증 타입 이고, dXNlcm5hbWU6cGFzc3dvcmQ= 은 username:password를 Base64 인코딩한 값이다.

응답 시 활용되는 HTTP 헤더

HTTP 응답 시 활용되는 대표적인 헤더인 Server Allow Retry-After Location WWW-Authenticate 헤더에 대해 알아보자.

Server

Server 헤더는 요청을 처리하는 서버 측의 소프트 웨어와 관련된 정보를 명시한다. 예를 들어 다음 예시 헤더는 Unix 운영체제에서 동작하는 아파치 HTTP 서버 를 의미한다.

Server : Apache/2.4.1 (Unix)

Allow

Allow 헤더는 클라이언트에게 허용된 HTTP 메서드 목록을 알려주기 위해 사용된다. 앞선 절에서 배웠던 405(Method Not Allowed) 상태 코드를 응답하는 메시지에서 Allow 헤더가 함께 사용된다. 다음 예시를 살펴보면 이해가 쉽다.

서버에서 GET 요청을 받았는데, POST 와 OPTIONS 메서드만 사용가능하다고 클라이언트에게 알려주는 사진이다.

Retry-After

앞선 절에서 배웠던 503(Service Unavailable) 상태 코드는 현재는 요청을 처리할 수 없으나 추후 가능할 수도 있음 을 의미했다. 이 응답과 함께 사용될 수 있는 헤더가 Retry-After 헤더이다. 다음 예시는 각각 2024년 8월 23일 금요일 09시 이후에 사용 가능하다 라는 사실 120 초 이후에 사용 가능하다 라는 사실을 나타내는 헤더이다.

각각 다른 예시이고, 동시에 여러 헤더를 사용한 예시가 아님에 유의하자.

Location

Location은 이전 절에 언급했던 대로, 클라이언트에게 자원의 위치를 알려주기 위해 사용되는 헤더이다. 주로 리다이렉션이 발생했거나 새로운 자원이 생성되었을 때 사용된다.

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page

위 예시를 살펴보자. 301(Moved Permanently) 를 통해 재요청 메서드가 변경될 수 있는 영구적인 리다이렉션을 명시하고 있다.

이 때, 브라우저는 Location 에 명시된 주소로 자동으로 이동하고 새로운 자원을 받아오게 된다.

그러니까 실제 사용자 경험 관점에서 대부분의 경우 리다이렉션이 발생한 줄 모른다고 한다.(알아서 Location 주소의 자원을 받아오므로)

HTTP/1.1 201 Created
Location: https://www.example.com/resources/123

다음처럼 새 리소스를 생성하고, 해당 리소스가 어느 URL로 접근 가능한지에 대해 명시할 때도 사용할 수 있다.

WWW-Authenticate

상태코드 401(Unauthorized)는 요청한 자원에 대한 유효한 인증이 없을 때 응답하는 코드다. 상태코드 401과 함께 사용되는 헤더가 WWW-Authenticate 이다. 이 헤더는 자원에 접근하기 위한 인증 방식을 설명하는 헤더이다. 이를테면 다음과같이 Basic 인증을 요구할 수 있다.

WWW-Authenticate: Basic

다만 실제로는 이보다 조금 더 많은 정보를 알려주는 경우가 많다. 예를 들어 다음과 같이 보안 영역(realm)을 함께 알려주건, 인증에 사용될 문자집합도 알려줄 수 있다.

WWW-Authenticate: Basic realm="Access to engineering site", charset="UTF-8"

realm 이란 보안이 적용될 영역을 의미한다. 같은 서버가 제공하는 자원일지라도, Engineering site 라는 영역에 속한 자원에 접근 가능한 사용자는 Financial site 라는 영역에 속한 자원에 접근이 불가할 수 있다.

요청과 응답 모두에서 활용되는 HTTP 헤더

Date

메시지가 생성된 날짜와 시각에 관련된 정보를 담은 헤더이다. Date: Tue, 15 Nov 1994 08:12:31 GMT

Connection

클라이언트의 요청과 응답 간의 연결 방식을 설정하는 헤더이다. Connection: keep-alive 헤더를 통해 상대방에게 지속 연결을 희망함을 알릴 수도, Connection: close 헤더를 통해 서버나 클라이언트가 연결을 종료하고 싶음을 알릴 수도 있다.

만약 요청1->요청2->요청3 이 연달아 발생하는 상황이라고 해보자.

그럼 요청1 과 요청2 에는 keep-alive 를 명시해서 TCP 연결을 재사용해 핸드셰이크 비용을 줄일 수 있음이 명확하다.

그렇다면 요청3 은 close 를 해야할까 keep-alive 를 해야할까?

요청3 이 끝난 이후, 사용자의 행동을 알 수 있다면 명확해지겠지만, 사용자가 어떤 행동을 취할지 모르는 상황이라고 가정했을 때, 결정하기가 쉽지 않을 것이다.

그래서 keep-alive 를 사용하되, timeout 을 짧게 설정해서 잠시동안 TCP 연결을 재사용할 수 있는 환경을 만들어주기도 한다고 한다.

Content-length

본문의 바이트 단위 크기(길이) 를 나타낸다. Content-length: 100

일반적으로 자동으로 본문 길이를 계산해서 보내주기 때문에 따로 명시할 필요는 없다. 서버가 요청 본문의 끝을 정확히 알 수 있도록 해서 내부적으로 서버가 언제 데이터 수신을 멈춰야 할지 알 수 있다고 한다.

그런데, 스트리밍 서비스나 압축된 데이터처럼 데이터가 동적으로 생성되거나 크기가 너무 클 경우에는 크기를 미리 알 수 없을 수 있다고 한다.

이럴 때는 Transfer-Encoding: chunked 를 사용해 데이터를 청크 단위로 나누어 보내고, 서버는 각 청크의 크기를 표시하되 마지막 청크를 보낼 때 0 으로 표시하여 데이터 전송이 끝났음을 알려준다고 한다.

Content-Type, Content-Language, Content-Encoding

이 헤더들은 전송하려는 메시지 본문의 표현 방식을 설정하는 헤더이다. 이런 점에서 이 헤더들은 표현 헤더 의 일종이라고도 부른다.

Content-Type 헤더는 메시지 본문에서 사용된 미디어 타입을 담고 있다. 예를 들어 다음 헤더는 메시지 본문이 HTML 문서 형식이며, 문자 인코딩으로 UTF-8을 사용한다는 정보를 알려준다. Content-Type: text/html; charset=UTF-8

Content-Language 헤더는 메시지 본문에 사용된 자연어를 명시한다. 해당 헤더 값은 언어 태그로 명시되며, 언어 태그는 하이픈(-)으로 구분된 다음과 같은 구조를 따른다.

일반적으로는 첫 번째 서브 태그(en, ko)나 두 번째 서브 태그(en-US, ko-KR)까지만 사용된다.

주로 사용되는 언어 코드와 국가 코드는 다음과 같다.

Content-Encoding 헤더에는 메시지 본문을 압축하거나 변환한 방식이 명시된다. HTTP를 통해 송수신되는 데이터는 전송 속도를 개선하기 위해 종종 압축이나 변환이 되고는 하는데, 이때 사용된 방식이 명시된다. 명시될 수 있는 대표적인 값은 gzip compress deflate br 등이 있다.

캐시

캐시란 불필요한 대역폭 낭비와 응답 지연을 방지하기 위해 정보의 사본을 임시로 저장하는 기술이다. 사본을 임시로 저장해두면 동일한 요청에 대해 캐시된 데이터를 활용할 수 있기에 불필요한 대역폭 낭비를 줄이고 빠르게 데이터에 접근할 수 있다.

만약, 클라이언트가 이미지를 조회하기 위해 서버를 향해 GET 요청을 보내고, 같은 이미지를 두 번 세 번 요청하는 상황에 캐시를 이용하면 좋다.

웹 브라우저에 저장된 캐시를 개인 전용 캐시(private cache), 클라이언트와 서버 사이에 저장된 캐시를 공용 캐시(public cache) 라고 부른다. 개인 전용 캐시에 초점을 맞춰 살펴볼 것이다.

캐시가 사본을 저장한다고 했는데, 그렇다면 캐시된 데이터가 최신 상태를 유지하고 있는지를 어떻게 알 수 있을까?

최신 원본 데이터와 얼마나 유사한지를 캐시 신선도(cache freshness)라고 표현하기도 하는데, 이 캐시 신선도를 유지하는 가장 기본적인 방법은 캐시된 데이터에 유효 기간을 설정하는 방법 이다. 캐시 데이터에 유효 기간을 설정하고, 기간이 만료되었다면 원본 데이터를 다시 요청하는 방식으로 캐시 신선도를 유지할 수 있다.

캐시할 데이터에 유효 기간을 부여하는 방법으로 응답 메시지의 Expires 헤더(날짜) 와 Cache-Control 헤더의 Max-Age 값 (초)을 사용할 수 있다.

아래 두 그림을 보면 이해가 쉽다.

캐시된 자원이 만료되었더라도, 캐시된 자원이 여전히 최신 정보라면 클라이언트는 굳이 서버로부터 같은 자원을 응답받을 필요가 없다. 따라서 캐시의 유효 기간이 만료되었다면 클라이언트는 캐시된 자원이 여전히 신선한지를 재검사해야 할 필요가 있다. 이 재검사 방법에는 날짜를 기반으로 서버에게 물어보는 방법 과 엔티티 태그를 기반으로 서버에게 물어보는 방법 이 있다.

날짜 기반 재검사 방법

클라이언트는 If-Modified-Since 헤더를 통해 서버에게 특정 시점 이후로 원본 데이터에 변경 이 있는지 물어볼 수 있다. 이 시점 이후로 원본에 변경이 있었다면, 그때만 새 자원으로 응답하도록 서버에게 요청하는 헤더이다.

다음 예시를 통해 이해해보자. 해당 요청 메시지는 2024년 8월 23일 금요일 09:00:00 이후에 www.example.com/index.html 의 자원이 변경되었니? 변경이 되었을 경우에만 새 자원으로 응답해 줘 라는 요청 메시지와 같다.

자, 이제 서버 입장에서 해당 헤더를 받았다고 가정하고 생각해보자. 서버의 자원은 크게 셋 중 하나의 상황을 따르게 된다.

1. 요청받은 자원이 변경되었음
2. 요청받은 자원이 변경되지 않았음
3. 요청받은 자원이 삭제되었음

요청받은 자원이 변경된 상황

서버는 상태 코드 200(OK)와 함께 새로운 자원을 반환한다.

요청받은 자원이 변경되지 않은 상황

서버는 상태 코드 304(Not Modified)를 통해 클라이언트에게 자원이 변경되지 않았음을 알린다. 서버는 자원의 변경 여부 뿐만 아니라, 마지막 변경 시점도 알려줄 수 있는데, 이를 위한 헤더로 Last Modified 가 있다. 이 헤더는 특정 자원이 마지막으로 수정된 시점을 나타낸다.

요청 받은 자원이 삭제된 상황

서버는 상태코드 404(Not Found)를 통해 요청한 자원이 존재하지 않음을 알린다.

엔티티 태그 기반 재검사 방법

엔티티 태그(Etag)는 자원의 버전 을 식별하기 위한 정보이다. 여기서 버전 이란 유의미한 변경 사항 을 의미한다. 즉, 자원이 변경될 때마다 자원의 버전을 식별하는 Etag 값이 변경된다.

클라이언트는 캐시 신선도를 검사하기 위해 이 Etag 값과 일치하는 값이 있니? 와 같이 물어볼 수 있다. 이를 위해 사용하는 헤더가 바로 If-None-Match 이다. 예를 들어, 다음의 요청 메시지는 혹시 Etag 값이 abc인 www.example.com/index.html 이라는 자원이 있니? 해당 자원이 변경되었다면(Etag 값이 변경되었다면) 그때만 새 자원으로 응답해줘 라는 요청 메시지와 같다.

이 때도 서버의 자원은 다음과 같은 상황 중 하나를 따른다.

1. 요청받은 자원이 변경되었음
2. 요청받은 자원이 변경되지 않았음
3. 요청받은 자원이 삭제되었음

이에 대한 동작은 날짜 기반 재검사와 동일하다.

쿠키

HTTP는 기본적으로 상태를 유지하지 않는 스테이트리스 프로토콜이다. 만약 그렇다면, 다음과 같은 기능은 어떻게 구현되는 것일까?

위 기능은 클라이언트의 상태를 알고 있어야만 구현할 수 있는 기능일텐데 말이다.

HTTP 쿠키(이하 쿠키)를 통해 이러한 기능을 구현할 수 있다. 쿠키(cookie)란 서버에서 생성되어 클라이언트 측에 저장되는 데이터로, 상태를 유지하지 않는 HTTP의 특성을 보완하기 위한 수단이다. 서버가 클라이언트의 상태를 알 수 있게끔 하는 특별한 데이터이다.

쿠키는 개발자도구 -> 애플리케이션 -> 저장 용량 -> 쿠키 에서 확인할 수 있다.

쿠키를 이루는 정보는 기본적으로 <이름, 값> 쌍의 형태를 띠고 있고, 추가로 적용 범위와 만료 기간 등 다양한 속성을 가질 수 있다.

서버는 쿠키를 생성하여 클라이언트에게 전송하고, 클라이언트는 전달받은 쿠키를 저장해 두었다가 추후 동일한 서버에 보내는 요청 메시지에 쿠키를 포함하여 전송한다. 서버는 쿠키 정보를 참고해 두 개의 요청이 같은 클라이언트에서 왔는지, 로그인 상태를 유지하고 있는지 등을 알 수 있다.

서버가 생성하는 쿠키는 응답 메시지의 Set-Cookie 헤더를, 클라이언트가 서버로부터 전달받은 쿠키를 활용할 때는 요청 메시지의 Cookie 헤더를 통해 전달된다.

응답 메시지

응답 메시지의 Set-Cookie 헤더를 통해 쿠키의 이름, 값과 더불어 세미콜론(;) 으로 구분되는 속성들을 전달할 수 있다.

쿠키 관련 정보로 이름 값 뿐만 아니라, 도메인 과 경로가 있다.

domain

www.naver.com 에서 받은 쿠키를 전혀 다른 웹사이트인 www.google.com 에 전송하면 안되기에, 쿠키는 사용 가능한 도메인이 정해져 있다. 이는 응답 메시지 속 Set-Cookie 헤더의 domain 속성으로 정해진다.

path

또한 같은 도메인이라도 경로별로 쿠키를 구분하여 사용하고 싶을 때가 있다. 특정 도메인의 특정 하위 경로에서만 사용하고자 하는 쿠키가 있을 수 있기에, 이 때는 Set-Cookie 헤더의 path 속성으로 지정할 수 있다. 그러면, path로 지정된 경로와 그 앞부분이 일치하는 경로(하위 경로) 에서 해당 쿠키 정보를 활용할 수 있게 된다.

Expires / Max-Age

Expires 속성에는 [요일, DD-MM-YY HH:MM:SS GMT] 형식으로 표기되는 쿠키 만료 시점이, Max-Age 속성에는 초 단위 유효 기간이 전달 될 수 있다. 해당 유효기간이 지나면, 해당 쿠키는 삭제되어 전달되지 않는다.

요청 메시지

요청 메시지의 Cookie 헤더 값은 서버에 전달할 쿠키의 이름과 값을 나타내는 헤더이다. 여러 개의 쿠키 값을 전달해야 한다면, 세미 콜론을 이용한다.

쿠키의 한계

쿠키의 대표적인 한계는 바로 보안 이다. 쿠키에 개인 정보를 비롯해 보안에 민감한 정보를 담아 송수신하고 저장하는 것은 바람직하지 못하다. 쿠키 정보가 쉽게 노출되거나 조작될 수 있기 때문이다.

이를 보완하기 위한 속성으로 Secure 와 HttpOnly 라는 속성이 있다.

Secure

나중에 학습하겠지만, 간단하게 알아보겠다. HTTPS 프로토콜이 사용되는 경우에만 쿠키를 전송하도록 하는 속성이다. HTTPS 프로토콜은 HTTP를 더 안전한 방식으로 전송할 수 있는 프로토콜이다.

HttpOnly

HTTP 송수신을 통해서만 쿠키를 이용하도록 제한하는 속성이다. 쿠키는 JS를 통해서도 접근이 가능한데, 악의적 의도를 가진 해커는 (정상적인 HTTP 송수신을 통해서가 아닌) JS로 쿠키를 중간에 가로채거나 위변조할 수 있다. HttpOnly는 이런 상황을 방지하기 위해 자바스크립트에서 쿠키에 접근하지 못하도록 하는 속성이다.

콘텐츠 협상과 표현

한국에서 접속하거나 한국어 계정으로 특정 URL에 접속하면 한국어로 된 웹 페이지를 볼 수 있고, 해외로 나가서 웹 페이지를 접속하면 해당 국가의 웹 페이지를 볼 수 있는 상황을 경험해 본 적 있을 것이다.

분명 같은 자원을 요청했는데, 어떻게 다른 결과를 얻는걸까? 이는 HTTP의 콘텐츠 협상(content negotiation)을 통해 이루어진다. 콘텐츠 협상 이라나 같은 URI에 대해 가장 적합한 자원의 형태를 제공하는 메커니즘을 의미한다. 이 때, 송수신 가능한 자원의 형태 를 자원의 표현(representation) 이라고 한다.

클라이언트가 선호하는 표현을 반영하고자 콘텐츠 관련 협상 HTTP 헤더들이 사용된다.

선호하는 미디어 타입을 나타내기 위한 Accept, 선호하는 언어를 나타내기 위한Accept-Language, 선호하는 문자 인코딩과 압축 방식을 나타내기 위한 Accept-Charset Accept-Encoding 이 있다.

클라이언트가 선호하는 언어가 한국어일 경우, Accept-Language: ko 를 헤더에 추가하여 서버에 요청하면, 서버는 클라이언트가 선호하는 언어를 인식하여 한국어로 표현된 자원을 보내주게 되는 것이다.

콘텐츠 협상의 우선 순위

콘텐츠 협상에서 중요한 점은 선호도에 우선 순위 를 반영할 수 있다는 점이다. 예를 들어, 한국어를 가장 선호하지만, 영어도 받을 용의가 있다 와 같이 표현이 가능하다.

이러한 우선 순위는 콘텐츠 협상 관련 헤더의 q 값으로 표현된다. q는 Quality Value 의 약자로, 특정 표현을 얼마나 선호하는지를 나타낸다. 생략 되었을 경우에는 1을 의미하고, 범위는 0부터 1까지이며, 값이 클수록 우선순위가 높다.

다음 예시를 보면, 한국어, 영어 순으로 선호하고, HTML, XML, 일반 텍스트순으로 선호한다는 것을 알 수 있다.

DNS가 뭔가요? DNS는 도메인 네임을 IP 주소로 변환해주는 애플리케이션 계층 프로토콜이자, 계층적이고 분산된 도메인 네임에 대한 관리체계입니다.

DNS 작동 방식에 대해 설명해주세요. 사용자가 웹 브라우저에 도메인 이름을 입력하면, 브라우저는 먼저 로컬 캐시에서 해당 도메인의 IP 주소를 확인하려 시도합니다. 만약 로컬 캐시에 없으면, 브라우저는 DNS 서버에 요청을 보냅니다. DNS 서버는 해당 도메인 이름에 대한 IP 주소를 찾아서 브라우저에 반환합니다. 이 과정에서 DNS 서버는 루트 네임 서버, TLD 네임 서버, 책임 네임 서버로 나뉜 여러 계층을 거쳐 IP 주소를 찾을 수 있습니다. 이후 브라우저는 받은 IP 주소를 사용하여 실제 웹 서버에 HTTP 요청을 보냅니다. 이로써 웹 페이지가 로드됩니다.

DNS 질의 종류에 대해 설명해주세요. DNS 질의에는 재귀적 질의와 반복적 질의가 있습니다. 재귀적 질의는 클라이언트가 로컬 네임서버에게 도메인 네임을 질의하면, 로컬 네임 서버는 루트 네임 서버에게, 루트 네임 서버는 TLD 네임 서버에게, TLD 네임 서버는 다음 단계에 질의하는 과정을 반복하며, 최종 응답을 역순으로 전달받는, 즉 재귀적으로 질의가 이루어지는 방식입니다. 반복적 질의는 클라이언트가 로컬 네임서버에게 도메인 네임을 질의하면, 로컬 네임 서버는 루트 도메인에게 질의해서 다음으로 질의할 네임 서버의 주소를 응답 받고, 이렇게 다음으로 질의할 네임 서버의 주소를 응답받는 과정을 반복하다가 최종 응답 결과를 클라이언트에게 알려주는 방식입니다.

DNS 서버에게 IP 주소를 요청할 때, 왜 UDP를 사용하나요? DNS는 신뢰성보다 속도가 더 중요한 서비스이기 때문에 연결 설정 비용이 없는 UDP를 사용합니다. 따라서 연결 지향적인 TCP보다 빠르고 효율적인 UDP를 사용하는 것이 유리합니다.

DNS 레코드가 무엇인가요? DNS 서버는 데이터베이스 서버의 한 유형이며, 클라이언트로부터 질의를 받았을 때 그에 맞는 데이터를 응답해야 합니다. 데이터베이스의 한 항목(row)을 DNS 서버에서는 리소스 레코드라고 부릅니다. 예를들어 A 레코드는 도메인 이름을 IPv4 주소로 매핑하는 데 사용됩니다.

HTTP 프로토콜에 대해서 설명해주세요. HTTP는 웹에서 클라이언트와 서버 간에 정보를 주고받기 위한 프로토콜입니다. 클라이언트는 HTTP 메서드를 사용해 요청을 보내고, 서버는 HTTP 상태 코드로 응답합니다. HTTP는 비연결성 프로토콜로, 요청과 응답 간에 상태를 유지하지 않으며, GET, POST, PUT, DELETE 등의 메서드를 사용하여 데이터를 처리합니다.

HTTP의 요청/응답 모델에 대해 설명해주세요. HTTP의 요청/응답 모델은 클라이언트가 서버에 요청을 보내면, 서버가 이에 대한 응답을 반환하는 방식입니다. 클라이언트는 GET, POST 등의 HTTP 메서드와 함께 요청을 보내고, 서버는 요청에 대한 처리 결과를 HTTP 상태 코드와 함께 응답합니다. 이 모델은 비연결성이므로, 요청과 응답 간에 상태를 유지하지 않습니다.

HTTP 메서드중 GET과 POST의 차이점에 대해 설명해주세요. GET 메서드는 클라이언트가 서버에게 데이터를 요청할 때 사용합니다. 이때 요청은 URL에 포함된 쿼리 파라미터를 통해 데이터를 전달합니다. 서버는 요청에 대한 응답으로 데이터를 클라이언트에게 전달합니다. POST 메서드는 클라이언트가 서버에 데이터를 보낼 때 사용합니다. 주로 폼 데이터를 전송할 때 사용하며, 서버는 데이터를 받아 처리하고, 보통 저장하거나 처리한 결과를 응답합니다.

HTTP 메서드중 PUT과 PATCH의 차이점에 대해 설명해주세요. PUT 메서드는 리소스를 덮어쓰거나 새로 생성할 때 사용합니다. 주로 요청 본문에 포함된 데이터로 해당 리소스를 덮어쓰는 방식으로 작동합니다. 만약 리소스가 없으면 새로 생성하기도 합니다. PATCH 메서드는 리소스의 일부만 수정할 때 사용합니다. 전체 리소스를 덮어쓰지 않고, 요청 본문에 포함된 일부 데이터만 수정합니다.

HTTP 상태 코드가 뭔가요? 알고 있는 상태 코드 몇가지 설명해주세요 HTTP 상태 코드는 서버가 클라이언트의 요청을 처리한 후 그 결과를 나타내는 코드입니다. 상태 코드는 3자리 숫자로 이루어져 있으며, 첫 번째 숫자는 응답의 범주를 나타냅니다. 예를 들어, 상태 코드 200은 요청이 성공적으로 처리되었음을 의미하고, 상태 코드 404는 요청한 자원을 찾을 수 없음을 의미하고, 상태코드 500은 서버의 예기치 못한 상황으로 요청을 처리할 수 없음을 의미합니다.

HTTP 헤더가 뭘까요? 알고 있는 헤더 몇 가지 설명해주세요. HTTP 헤더는 클라이언트와 서버 간에 전송되는 추가적인 메타데이터입니다. 예를 들어, Content-Type 헤더는 요청이나 응답 본문의 데이터 형식을 명시합니다. Authorization 헤더는 클라이언트의 인증 정보를 포함합니다. User-Agent 헤더는 클라이언트의 브라우저나 운영체제에 대한 정보를 포함합니다.

HTTP의 무상태성(Stateless)에 대해서 설명해주세요. HTTP의 무상태성이란, 서버가 HTTP 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않는다는 의미입니다. 즉, 각 요청은 기본적으로 독립적인 요청으로 간주됩니다. 무상태성 덕분에 언제든 쉽게 서버를 추가할 수 있어 확장성이 높아지고 서버 장애시 쉽게 다른 서버로 대체가 가능해 견고성이 높아집니다.

HTTP Keep-Alive에 대해서 설명해주세요. HTTP Keep-Alive는 HTTP 요청과 응답 간에 TCP 연결을 유지하는 기능입니다. 이를 통해 여러 요청과 응답을 하나의 연결로 처리할 수 있어, 매번 새로운 연결을 설정할 필요가 없고, 그로 인해 웹 응답 속도가 빨라집니다.

HTTP 파이프라이닝에 대해서 설명해주세요. HTTP 파이프라이닝은 요청에 대한 응답을 기다리지 않고 여러 개의 요청을 한 번에 보내는 기법입니다. 응답을 기다리지 않기 때문에 서버와 클라이언트 간의 대기 시간을 줄여서 성능을 향상시킬 수 있습니다.

HTTP/1.1, HTTP/2, HTTP/3 각각의 특징에 대해 설명해주세요. HTTP/1.1은 전통적인 HTTP 프로토콜로, 각 요청마다 독립적인 TCP 연결을 사용합니다. 이로 인해 여러 요청을 처리할 때 대기 시간이 발생할 수 있습니다. HTTP/2는 성능 향상을 위해 여러 요청을 하나의 연결로 처리할 수 있는 다중화 기능을 제공합니다. 이로 인해 여러 요청을 병렬로 처리할 수 있어 대기 시간이 줄어듭니다. HTTP/3는 QUIC(Quick UDP Internet Connections) 프로토콜을 기반으로 한 HTTP 버전으로, TCP 대신 UDP를 사용합니다. 이로 인해 연결 설정 시간이 단축되고, 패킷 손실에 대한 회복력이 향상되어 더 빠르고 안정적인 통신을 제공합니다.

쿠키와 세션에 대해서 설명해주세요. 쿠키는 HTTP 서버가 클라이언트를 식별할 수 있도록 하기 위해서 사용됩니다. 클라이언트가 웹 서버에 처음 접속하면, 서버는 쿠키를 생성해 클라이언트에게 전달합니다. 이후 클라이언트는 서버에 요청을 보낼 때 쿠키를 함께 전송하며, 서버는 이를 통해 클라이언트를 식별합니다. 쿠키는 클라이언트 측에 저장되기 때문에, 유출될 위험이 있을 수 있습니다. 그리고 세션은 쿠키와 유사하지만 서버 측에서 클라이언트의 정보를 저장한다는 점에서 차이가 있습니다.

저번에 학습한 네트워크 계층의 IP는 한계점이 있다. 그것은 바로 신뢰할 수 없는 통신 과 비연결형 통신을 한다는 점이다.

신뢰할 수 없는 통신 은 IP 프로토콜이 패킷이 수신지까지 제대로 전송되었다는 보장을 하지않는 특징이다. 패킷의 데이터가 손상되거나 중복된 패킷이 전송되어도 확인하지 않고, 재전송하지 않으며, 순서대로 패킷이 도착할 것이라는 보장도 해주지 않는다. 이러한 전송 특성을 다른 말로 최선형 전달 이라고도 한다. 이는 최선을 다해 보겠지만, 전송 결과에 대해서는 어떠한 보장도 하지 않습니다 를 의미한다.

비연결형 통신은 송수신 호스트 간에 사전 연결 수립 작업을 거치지 않는 특징을 의미한다. 그저 수신지를 향해 패킷을 내보내기만 할 뿐이다.

그렇지만 이런 특징은 모든 패킷이 제대로 전송되었는지 일일이 확인하고, 호스트 간의 연결을 수립하는 작업이 없기 때문에 패킷의 빠른 송수신이 가능하다.

금융 서비스처럼 반드시 신뢰성 있는 전송을 보장해야 하는 경우가 있는 반면, 동영상 스트리밍 서비스나 실시간 영상 통화처럼 빠른 전송이 우선시 되는 경우도 있다.

이처럼 신뢰성 있는 전송이 모든 경우에 필요하지는 않다.

아무튼, 이러한 두 특징을 보완할 수 있는 연결형 통신을 지원하는 대표적인 프로토콜로 TCP가 있는데, 아래서 차차 살펴볼 것이다.

ICMP(Internet Control Message Protocol)

IP의 신뢰할 수 없는 전송 특성과 비연결형 전송 특성을 보완하기 위한 네트워크 계층의 프로토콜로 ICMP가 있다. ICMP는 IP 패킷의 전송 과정에 대한 피드백 메시지를 얻기 위해 사용하는 프로토콜이다. 유의해야할 점은, ICMP가 IP의 신뢰성을 보장하지 않는다는 것이다. 데이터 전송을 보장해주는게 아닌, 네트워크 문제 진단 및 오류 보고를 위한 프로토콜인 것이다.

ICMP 메시지 종류

ICMP 메시지 종류로는 크게 두 가지가 있다.

1. 오류 메시지

• 패킷 전송 중 발생한 문제를 알림 (예: 목적지 도달 불가, 시간 초과 등)

2. 진단 메시지

• 네트워크 상태를 확인하고 문제를 분석 (예: ping 명령어)

응용 계층과의 연결 다리, 포트

만약, 네트워크 외부에서 내가 전송받으려는 사진 파일을 구성하는 패킷들이 라우팅되어 컴퓨터로 도착했다고 가정해보자. 그리고 나는 컴퓨터로 웹 브라우저, 게임, 메신저 프로그램을 실행하고 있다.

패킷이 컴퓨터에 도달했으니까, 전송이 끝난 것일까? 아니다. 이 패킷들은 실행 중인 특정 애플리케이션 프로세스까지 전달되어야 한다. 즉, 패킷의 최종 수신 대상은 특정 애플리케이션 프로세스라는 것이다.

패킷이 실행 중인 특정 애플리케이션 까지 전달되려면, 패킷에 특정 애플리케이션을 식별할 수 있는 정보 가 포함되어야 한다. 이러한 정보를 포트 라고 한다.

포트의 번호

전송 계층에서는 포트 번호 를 통해 특정 애플리케이션을 식별한다. 정확히는 수신지 포트와 송신지 포트를 통해 송수신지 호스트의 애플리케이션을 식별한다.

포트 번호는 16비트로 표현 가능하고, 번호의 범위에 따라 세 종류로 나뉜다. 각각 잘 알려진 포트, 등록된 포트, 동적 포트 이다.

잘 알려진 포트(well known port)

• 0번 ~ 1023 번 포트

• 시스템 포트라고도 불림

• 범용적으로 사용되는 애플리케이션 프르토콜이 일반적으로 사용하는 포트 번호를 의미

  

등록된 포트(registered port)

• 1024 ~ 49151 번 포트
• 잘 알려진 포트에 비해 덜 범용적이지만, 흔히 사용되는 애플리케이션 프로토콜에 할당하기 위해 사용됨

동적 포트(dynamic port)

• 49152 ~ 65535 번 포트
• 사설 포트, 임시 포트 라고도 불림

보통, 서버 는 잘 알려진 포트 혹은 등록된 포트 로 동작하는 경우가 많고, 클라이언트 는 동적 포트 번호 중 임의의 번호가 할당되는 경우가 많다.

IP 주소와 포트 번호에 대한 정보가 함께 주어지면, 특정 호스트에서 실행 중인 특정 애플리케이션 프로세스 를 식별할 수 있는데, 그래서 포트 번호는 IP 주소:포트 번호 형식으로 IP와 함께 표기되는 경우가 많다. 192.168.0.15:8000 처럼 말이다.

전송 계층 역할 정리

전송 계층은 신뢰할 수 있는 연결형 통신이 가능한 프로토콜을 제공하기에, 네트워크 계층의 한계를 보완할 수 있고, 포트를 통해 응용 계층의 애플리케이션을 식별함으로써 응용 계층과의 연결 다리 역할을 수행한다.

포트 기반 NAT

NAT이란 IP 주소를 변호나하는 기술이며 사설 IP 주소와 공인 IP 주소를 변환하는데 사용된다고 했다. 이러한 변환을 위해 주로 사용되는 것이 NAT 변환 테이블 이다.

NAT 변환 테이블

NAT 변환 테이블은 다음 그림처럼 변환의 대상이 되는 IP 주소 쌍이 명시되어 있다.

그런데, 이런 방식에는 한 가지 문제점이 있다. 테이블을 자세히 살펴보면 사설 IP 주소 하나 당 공인 IP 주소가 대응되는데, 이는 결국 사설 IP 주소의 수만큼 공인 IP 주소가 필요하다는 말이다.

이런 이유로 오늘날 대중적으로 활용되는 NAT은 다수의 사설 IP 주소를 그보다 적은 공인 IP 주소로 변환하는 방식을 채택한다. 여기서 바로 포트가 활용된다.

NAPT(Network Address Port Translation)

NAPT는 포트를 활용해 하나의 공인 IP 주소를 여러 사설 IP 주소가 공유할 수 있도록 하는 NAT의 일종이다. NAPT는 다음 그림처럼, NAT 테이블에 변환할 IP 주소 쌍과 더불어 포트 번호도 함께 기록하고 변환한다.

같은 공인 IP 주소로 변환되더라도 포트 번호가 다르기 때문에 내부 IP 주소를 구분할 수 있게 되는 것이다. 이 방식 덕분에, 사설 IP 주소와 공인 IP 주소를 N : 1로 관리할 수 있다.

포트 포워딩

NAT 변환 테이블이 백지 상태일 때, 외부에서 내부 네트워크로의 연결을 시도한다고 가정하자. 하지만 NAT은 외부에서 오는 "새로운 연결"을 기본적으로 차단하기 때문에, 그냥은 통신이 불가능하다.

그러나 포트 포워딩(port forwarding)을 사용하면 가능하다!

포트 포워딩이란, 네트워크 내 특정 장치(호스트)에 미리 IP 주소와 포트 번호를 할당하고, 외부에서 해당 "IP주소:포트번호"로 들어오는 트래픽을 해당 장치로 전달하는 기능이다. 쉽게 말해, 외부에서 오는 트래픽을 내가 원하는 내부 장치로 안내하는 길잡이 역할을 한다.

즉, 특정 외부 포트로 들어오는 요청이 있으면, 미리 지정한 내부 IP와 내부 포트로 트래픽을 유도하는 방식이다. 이를 통해 내부 네트워크 정보(IP 주소 등)는 외부에 노출되지 않은 채로 통신이 가능해진다.

TCP와 UDP

네트워크 계층에서 가장 중요한 프로토콜이 IP라면, 전송 계층에서 가장 중요한 프로토콜은 TCP와 UDP 이다. TCP(Transmission Control Protocol 는 신뢰할 수 있는 통신을 위한 연결형 프로토콜이고, UDP(User Datagram Protocol) 는 TCP보다 신뢰성은 떨어지지만 비교적 빠른 통신이 가능한 비연결형 프로토콜이다.

TCP 통신 단계와 세그먼트 구조

TCP 통신을 세 단계로 나누면 다음과 같다.

1. 연결 수립
2. 데이터 송수신
3. 연결 종료

TCP 세그먼트 구조

MSS(Maximum Segment Size)

MTU는 헤더의 크기까지 포함했던 반면, MSS는 TCP 헤더 크기는 제외한다.

TCP 세그먼트 헤더 구조

이 중에서, TCP의 기본 동작을 이해하기 위한 기본적인 필드를 살펴보자.

송신지 포트와 수신지 포트

• 이름 그대로 송신지 또는 수신지 애플리케이션을 식별하는 포트 번호가 명시됨

순서 번호(sequence number)

• 순서 번호가 명시됨
• 순서 번호 란 송수신되는 세그먼트의 올바른 순서를 보장하기 위해 세그먼트 데이터의 첫 바이트에 부여되는 번호

확인 응답 번호(acknowledgment number)

• 상대 호스트가 보낸 세그먼트에 대한 응답으로, 다음으로 수신하기를 기대하는 순서 번호가 명시됨

제어 비트(control bits)

• 현재 세그먼트에 대한 부가 정보를 나타냄
• 플래그 비트 라고도 부름

윈도우(window)

• 수신 윈도우의 크기가 명시됨
• 수신 윈도우 란 한 번에 수신하고자 하는 데이터의 양을 나타냄

제어 비트

제어 비트는 기본적으로 8비트로 구성된다. TCP의 기본 동작을 논할 때 가장 자주 언급되는 세 개의 제어비트는 아래와 같다.

• ACK : 세그먼트의 승인을 나타내기 위한 비트
• SYN : 연결을 수립하기 위한 비트
• FIN : 연결을 종료하기 위한 비트

해당 비트가 1로 설정되어 있다는걸 편의상 SYN 세그먼트 와 같이 지칭하겠다

순서 번호와 확인 응답 번호

TCP의 신뢰성을 보장하기 위한 필드로, 한 쌍으로 묶어서 기억하는게 편하다. 순서 번호 가 세그먼트의 올바른 송수신 순서를 보장하기 위한 번호로, 세그먼트 데이터의 첫 바이트에 부여되는 번호라고 했는데 이것이 무슨 의미인지 알아보자.

만약, 내가 응용 계층을 전송해야 하는 데이터가 1900바이트 크기의 데이터고, 이는 MSS 단위로 전송될 수 있다. MSS가 500 바이트라고 가정했을 때, 다음 그림처럼 네 개의 세그먼트로 쪼갤 수 있을 것이다.

위 사진과 같이, SYN 플래그가 1로 설정된 첫 번째 세그먼트의 경우, 무작위의 순서 번호 가 지정이 되는데, 이를 초기 순서 번호(ISN; Initial Sequence Number) 라고 한다. 그 이후의 순서 번호는 초기 순서 번호 + 송신한 바이트 수 (떨어진 바이트 수) 가 된다.

SYN 플래그가 1이라는 것은 해당 패킷이 연결 수립용 이라는 것을 의미한다.

예를 들어, 세그먼트 B는 500바이트 이므로 순서번호가 100 + 500 = 600 이 되고, 세그먼트 C는 600 + 500 = 1100 이 된다.

확인 응답 번호 는 순서 번호에 대한 응답이다. 다음으로 제가 받을 순서 번호는 이것입니다 를 의미하고,수신한 순서 번호 + 1(ACK + 1) 로 설정된다.

다음 그림처럼 호스트 순서 번호가 8000인 세그먼트를 잘 수신한 뒤, 8001 번 세그먼트를 받기를 원한다면, 확인 응답 번호로 8001를 명시한 세그먼트를 전송한다.

TCP 연결 수립과 종료

TCP 연결 수립 : 쓰리 웨이 핸드셰이크(three - way handshake)

쓰리 웨이 핸드 셰이크 란 세 단계로 이루어진 TCP의 연결 수립 과정을 의미한다.

아래 사진처럼 세 단계를 거친 후, 본격적인 송수신이 시작된다.

사진에 보이는 액티브 오픈 이란, 처음 연결을 시작하는 호스트의 연결 수립 과정을 말하며 여기서는 클라이언트가 TCP 연결을 시작하는 과정 이다. 패시브 오픈 이란 서버가 연결 요청을 기다리는 과정 이다.

서로의 초기 시퀀스 번호를 알아야 이후 데이터 전송 시 순서와 무결성을 보장할 수 있기 때문에, 서로를 소개하는 과정이라고 생각하면 되겠다.

TCP 연결 종료 : 포 웨이 핸드셰이크(four - way handshake)

사진처럼 송수신 호스트가 각자 한 번씩 FIN과 ACK를 주고받으며 이루어진다.

액티브 클로즈 는 먼저 연결을 종료하려는 호스트에 의해 수행되는 과정 (주로 클라이언트) 이고, 패시브 클로즈 는 연결 종료 요청을 받아들이는 호스트에 의해 수행 (주로 서버) 되는 과정이다.

TCP 상태

TCP는 연결형 통신과 신뢰할 수 있는 통신을 위해 다양한 상태 를 유지한다. 상태 란 현재 어떤 통신 과정에 있는지를 나타내는 정보이다. 이러한 이유 때문에스테이트풀(stateful) 프로토콜의 일종이라고도 한다.

주요 상태는 아래와 같다.

1번 : 연결이 수립되지 않은 상태 2번 : 연결 수립 과정에서 주로 볼 수 있는 상태 3번 : 연결 종료 과정에서 주로 볼 수 있는 상태

로 생각하면 쉽다.

연결이 수립되지 않은 상태

• CLOSED : 아무런 연결이 없는 상태
• LISTEN : 일종의 연결 대기 상태. 패시브 오픈 호스트가 LISTEN 상태를 유지하고, 액티브 오픈 호스트가 SYN 세그먼트를 보내면 쓰리 웨이 핸드 셰이크가 시작됨.

연결 수립 상태

• SYN-SENT : 액티브 오픈 호스트가 SYN 세그먼트를 보낸 뒤, SYN + ACK 세그먼트를 기다리는 상태 즉, 연결 요청을 보낸 뒤, 대기하는 상태
• SYN-RECEIVED : 패시브 오픈 호스트가 SYN + ACK 세그먼트를 보낸 뒤 그에 대한 ACK 세그먼트를 기다리는 상태
• ESTABLISHED : 연결이 확립되었음을 나타내는 상태 -> 데이터 송수신 가능 상태

연결 종료 상태

• FIN-WAIT-1 : 액티브 클로즈 호스트가 FIN 세그먼트를 보낸 직후의 상태
• CLOSED-WAIT : FIN 세그먼트를 받은 패시브 클로즈 호스트가 응답으로 ACK 세그먼트를 보낸 후 대기하는 상태
• FIN-WAIT-2 : FIN-WAIT-1 상태에서 ACK 세그먼트를 받은 뒤, 상대 호스트의 FIN 세그먼트를 기다리는 상태
• LAST-ACK : CLOSE-WAIT 상태에서 FIN 세그먼트를 전송한 뒤 이에 대한 ACK 세그먼트를 기다리는 상태
• TIME-WAIT : 액티브 클로즈 호스트가 FIN 세그먼트를 수신한 뒤, 이에 대한 ACK 세그먼트를 전송한 뒤의 상태. 패시브 클로즈 호스트는 ACK 세그먼트를 수신하면 CLOSED 상태로 전이하지만, TIME-WAIT 상태에 접어든 액티브 클로즈 호스트는 일정 시간을 기다린 뒤 CLOSED 상태로 전이함.

• 세그먼트가 올바르게 전송되지 않았을 때 일정 시간 대기하지 않고 연결을 종료할 경우, 상대 호스트는 마지막 ACK 세그먼트를 전송받을 수 없기 때문에 대기 시간이 필요.

• CLOSING : 동시에 연결을 종료하려 할 때 전이되는 상태. 서로가 FIN 세그먼트를 보내고 받은 뒤 그에 대한 ACK 세그먼트를 보냈지만 자신의 FIN 세그먼트에 대한 ACK 세그먼트를 받지 못했을 때 접어드는 상태. (아래 사진 참고)

UDP 데이터그램 구조

UDP 는 TCP와 달리 비연결형 통신을 수행하는 신뢰할 수 없는 프로토콜이다. 따라서 연결 수립 및 해제 재전송을 통한 오류제어 혼잡 제어 흐름 제어 를 수행하지 않는다. TCP처럼 상태를 유지하지도 않기 때문에 스테이트리스(stateless) 프로토콜의 일종이라고도 한다. 적은 오버헤드로 패킷을 빠르게 처리 가능하기 때문에, 실시간성이 강조되는 상황에서 TCP 보다 많이 쓰인다.

송신지 포트와 수신지 포트

• 송수신지의 포트 번호

길이

• 헤더를 포함한 UDP 데이터그램의 바이트

체크섬

• 데이터 전송 과정에서 오류가 발생했는지 검사하기 위한 필드
• 데이터그램이 훼손되었는지를 나타내는 정보
• 수신지까지 잘 도착했는지 를 나타내는 신뢰성/비신뢰성과 관련이 없음

UDP 송수신 과정

TCP가 하나씩 확실히 전달한다면, UDP는 사진처럼 빠르게 마구 던지는 것과 같다. 그 과정에서 패킷이 손실되거나 순서가 바뀔 수 있다.

TCP의 오류, 흐름, 혼잡 제어

오류 제어, 흐름 제어, 혼잡 제어 는 모두 TCP의 신뢰성을 보장하기 위한 기능이다. TCP는 재전송을 기반으로 다양한 오류를 제어하고, 흐름 제어를 통해 처리할 수 있을 만큼의 데이터만을 주고받으며, 혼잡 제어를 통해 네트워크가 혼잡한 정도에 따라 전송량을 조절한다.

오류 제어(error control)

오류를 제어하기 위해 TCP는 잘못된 세그먼트를 재전송하는 방법을 사용한다. 그렇다면, 송신 호스트가 세그먼트 전송 과정에 문제가 있음을 인지해야 할텐데, 체크섬 은 세그먼트의 훼손 여부만 나타낼 뿐이다. 이 체크섬 값이 잘못되었다면 수신 호스트는 해당 패킷을 폐기할 뿐, 송신 호스트가 이를 알아차릴 수 없다.

따라서, TCP가 신뢰성을 보장하려면 1. 송신 호스트가 송신한 세그먼트에 문제가 있음 을 인지해야 하고, 2. 오류를 감지하면, 해당 세그먼트를 재전송 할 수 있어야 한다.

그렇다면, TCP가 어떤 상황에서 송신한 세그먼트에 문제가 있음을 감지하는가를 알아야 한다. 이 상황에는 크게 두 가지가 있다. 하나는 중복된 ACK 세그먼트를 수신했을 때이고, 하나는 타임아웃이 발생했을 때이다.

재전송 기법

1. 중복된 ACK 세그먼트를 수신했을 때

수신 호스트 측이 받은 세그먼트의 순서 번호 중에서 일부가 누락되었다면, 특정 세그먼트를 보내달라는 요청을 반복해서 전송할 것이다. 이 상황이 이에 해당한다. 이 때 빠른 재전송이 발생한다.

빠른 재전송(fast retransmit)

빠른 재전송 은 재전송 타이머가 만료되기 전이라도 세 번의 중복 ACK 세그먼트가 수신되었다면 해당 세그먼트를 곧바로 재전송하는 기능이다.

세그먼트의 일부가 유실되어, 수신 호스트가 동일한 ACK 세그먼트를 전송해 송신 호스트가 세 번의 동일한 ACK 세그먼트를 수신하면, 곧바로 재전송을 하기에 타이머가 끝날 때까지 기다리는 시간을 줄일 수 있다.

2. 타임아웃이 발생했을 때

TCP는 타임아웃이 발생하면 문제가 생겼음을 인지한다. TCP 세그먼트를 송신하는 호스트는 모두 재전송 타이머 라는 값을 유지한다. 호스트가 세그먼트를 전송할 때마다 재전송 타이머를 시작하게 되는데, 이 타이머의 카운트다운이 끝난 상황을 타임 아웃 이라고 한다. 타임아웃이 발생할 까지 ACK 세그먼트를 받지 못하면, 세그먼트가 상대 호스트에게 정상적으로 도착하지 않았다고 간주 하여 세그먼트를 재전송한다.

ARQ : 재전송 기법

수신 호스트의 답변(ACK)과 타임아웃 발생을 토대로 문제를 진단하고, 문제가 생긴 메시지를 재전송함으로써 신뢰성을 확보하는 방식을 ARQ (Automatic Repeat Request)라고 한다. ARQ의 종류는 다양한데, 가장 대표적인 세 가지 방식인 Stop-and-Wait ARQ와 GO-Back-N ARQ 그리고 Selective Repeat ARQ 에 대해 알아보겠다.

참고로, 전송 계층의 TCP는 ARQ를 사용하는 대표적인 프로토콜이지만, ARQ 자체는 전송 계층만의 기술은 아니다.

Stop-and-Wait ARQ

Stop-and-Wait ARQ 는 제대로 전달했음을 확인하기 전까지는 새로운 메시지를 보내지 않는 방식이다. 단순하지만 높은 신뢰성을 자랑한다. 하지만, 송신 호스트 입장에서 확인 응답을 받기 전까지는 다음 전송을 할 수 있어도 하지 못하기 때문에 네트워크 이용 효율이 낮다 는 단점이 있다. 이는 결국 성능의 저하로 이어진다. 따라서 오늘날의 인터넷 환경의 TCP에서는 특별한 경우가 아닌 이상 이 방식을 사용하지 않는다.

위 방식을 해결하려면, 아래 그림처럼 각 세그먼트에 대한 ACK 세그먼트가 도착하기 전이더라도 여러 세그먼트를 보낼 수 있어야 한다. 이렇게 연속해서 메시지를 전송할 수 있는 기술을 파이프라이닝(pipelining) 이라고 한다. 오늘날의 TCP는 파이프라이닝 기술이 사용되는 나머지 두 방식을 기반으로 동작한다.

Go-Back-N ARQ

Go-Back-N ARQ 는 여러 세그먼트를 전송하고, 도중에 잘못 전송된 세그먼트가 발생할 경우 해당 세그먼트부터 전부 다시 전송하는 방식이다.

위 사진처럼, n+2번 세그먼트를 전송했지만 손실이 났을 경우, 이에 대한 ACK 세그먼트를 받지 못지 못했기에 타임아웃이 발생한다. 이 때, 송신 호스트는 잘못된 송신이 있음을 인지하고, ACK 세그먼트를 수신받지 못한 n+2 번 세그먼트부터 다시 전송하게 된다.

여기서 순서 번호 n번에 대한 ACK 세그먼트는 'n번까지의' 확인 응답이라고 할 수 있으므로, Go-Back-N ARQ의 ACK 세그먼트를 누적 확인 응답 이라고 한다.

Selective Repeat ARQ

Selective Repeat ARQ는 이름 그대로 선택적으로 재전송하는 방법이다. Go-Back-N ARQ 송신 과정은 모든 세그먼트를 다시 재전송해야한다는 단점이 있지만, 이 방식은 수신 호스트 측에서 제대로 전송받은 각각의 패킷들에 대해 ACK 세그먼트를 전송하는 방식이다. 이 때문에 해당 방식의 ACK 세그먼트를 개별 확인 응답 이라고 부른다.

흐름 제어(flow control)

호스특 한 번에 받아서 처리할 수 있는 세그먼트의 양에는 한계가 있기 때문에, 파이프라이닝 기반의 ARQ 재전송 기법이 동작하려면 반드시 흐름 제어를 고려해야 한다.

만약 수신 호스트가 한 번에 n개의 바이트를 받아서 처리할 수 있다면, 송신 호스트는 이 점을 인지하여 n개 바이트를 넘지 않는 선에서 송신해야한다. 더 많은 양을 전송할 경우 일부 세그먼트가 처리되지 못할 수도 있기 때문이다.

TCP의 흐름제어란 이런 문제 상황을 방지하고자 송신 호스트가 수신 호스트의 처리 속도를 고려하며 송수신 속도를 균일하게 유지하는 것을 의미한다.

참고로, Stop-and-Wait ARQ를 사용하면 확인 응답이 오기 전까지는 추가적인 세그먼트를 전송하지 않기에 별도의 흐름 제어가 필요하지 않다.

파이프라이닝이 연속해서 세그먼트를 전송할 수 있는 기술이긴 하지만, 무작정 무한한 데이터를 연속해서 보낼 수는 없기에 슬라이딩 윈도우 라는 방식이 필요하다.

슬라이딩 윈도우(sliding window)

슬라이딩 윈도우를 이해하기 전, 먼저 윈도우(window) 에 대한 이해가 필요하다.

윈도우 란 송신 호스트가 파이프라이닝할 수 있는 최대량을 의미한다. 윈도우의 크기만큼 확인 응답을 받지 않고도 한 번에 전송가능하다는 의미이다.

윈도우의 크기가 크면 한 번에 전송할 수 있는 데이터가 많을 것이고, 윈도우의 크기가 작으면 한 번에 전송할 수 있는 데이터가 적을 것이다. 윈도우 크기에서 벗어난 숫자에 해당하는 세그먼트는 전송할 수 없다.

첫 번째, 두 번째, 세 번째, 네 번째 세그먼트를 전송했고, 수신 호스트로부터 첫 번째 세그먼트에 대한 ACK를 받았다고 가정해보자. 그렇다면 윈도우는 아래처럼 오른쪽으로 한 칸 이동하게 된다.

윈도우가 점차 오른쪽으로 미끄러지듯 움직이는데, 이러한 흐름 제어를 슬라이딩 윈도우 라고 부른다.

송신 호스트만 윈도우를 고려하는 것은 아니고, 수신 호스트도 윈도우를 고려한다. 사실, 송신측 윈도우(송신 윈도우) 는 수신 호스트가 알려주는 수신 측 윈도우(수신 윈도우)를 토대로 알 수 있는 정보이다.

TCP 세그먼트 구조에서, 윈도우 필드에 명시되는 값이 바로 이 수신 윈도우 의 크기다.

혼잡 제어(congestion control)

혼잡 이란 많은 트래픽으로 인해 패킷의 처리 속도가 늦어지거나 유실될 우려가 있는 네트워크 상황을 의미한다. 혼잡 제어 란 이와 같은 혼잡을 제어하기 위한 기능이다. 혼잡 제어를 수행하는 송신 호스트는 네트워크 혼잡도를 판단하고 혼잡한 정도에 맞춰 유동적으로 전송량을 조절하며 전송한다.

혼잡 윈도우 는 혼잡 없이 전송할 수 있을 법한 데이터 양을 의미하는데, 혼잡 윈도우가 작다면 네트워크가 혼잡한 상황이기에 한 번에 전송할 수 있는 세그먼트 수가 작음을 의미한다.

이 혼잡 윈도우 크기가 어느 정도가 적당한지는 혼잡 제어 알고리즘을 통해 결정할 수 있다.

혼잡 제어 알고리즘

RTT(Round Trip Time)

• 메시지를 전송한 뒤 그에 대한 답변을 받는데까지 걸리는 시간

AIMD(Addtive Increase/Multiplicative Decrease)

의미를 직역하면 합으로 증가, 곱으로 감소 라는 의미이다. 혼잡이 감지되지 않는다면 혼잡 윈도우를 RTT마다 1씩 선형적으로 증가시키고, 혼잡이 감지되면 혼잡 윈도우를 절반으로 떨어뜨리는 동작을 반복하는 알고리즘이다.

AIMD 알고리즘은 혼잡을 제어할 수 있는 가장 기본적인 아이디어이지만, 이것만으로 혼잡 제어가 가능하지는 않다. 이를 조금 더 정교하게 만들 혼잡 제어 알고리즘은 다음과 같다.

1. 느린 시작(slow start) 2. 혼잡 회피(congestion avoidance) 3. 빠른 회복(fast recovery)

느린 시작(slow start) 알고리즘

혼잡 윈도우를 1부터 시작해 수신된 ACK 세그먼트 하나당 1씩 증가시키는 방버이다. 결과적으로 다음 그림처럼 2배씩 지수적으로 증가하게 된다.

AIMD 방식은 처음 연결이 수립된 뒤, 혼잡 윈도우 크기가 증가되는 속도가 느리기 때문에, 이 알고리즘을 활용하면 초기 전송 속도를 어느 정도 빠르게 확보할 수 있다는 장점이 있다.

하지만, 혼잡 윈도우를 언제까지나 지수적으로 증가시킬 수는 없다. 그렇게되면 언젠가 혼잡 상황을 마주할 확률이 높아지기 때문이다. 그렇다면 언제까지 증가해야 할까?

느린 시작 알고리즘을 사용할 때 함께 사용하는 값으로 느린 시작 임계치(slow start threshold) 라는 값이 정해져 있다. 혼잡 윈도우 값이 계속 증가하다가 느린 임계치 이상 이 되거나 타임 아웃이 발생 하거나, 세 번의 중복된 ACK 세그먼트가 발생 하여 혼잡이 감지되면 다음 세 가지 방법 중 하나를 선택하게 된다.

혼잡 회피(congestion avoidance) 알고리즘

혼잡 회피 알고리즘은 RTT 마다 혼잡 윈도우를 1MSS(Maximum Segment Size)씩 증가시키는 알고리즘이다. 혼잡 윈도우를 지수적으로 증가시키는 느린 시작과는 달리, 혼잡 윈도우 크기를 선형적으로 증가시키는 것을 볼 수 있다.

느린 시작 임계치를 넘어선 시점부터는 혼잡이 발생할 우려가 있으니, 조심해서 혼잡 윈도우를 증가시키는 방식이다.

혼잡 회피 도중에도 혼잡이 발생하면 위 세 가지 상황을 나타낸 표의 절차대로 수행한다.

빠른 회복(fast recovery) 알고리즘

세 번의 중복된 ACK 세그먼트를 수신하면 빠른 재전송과 더불어 빠른 회복 알고리즘이 수행된다. 빠른 회복 알고리즘은 세 번의 중복 ACK 세그먼트를 수신했을 때, 느린 시작은 건너뛰고 혼잡 회피를 수행하는 알고리즘으로, 빠르게 전송률을 회복하기 위한 알고리즘이다.

다만, 빠른 회복 도중이라도 타임아웃이 발생하면 혼잡 윈도우 크기는 1로, 느린 시작 임계치는 혼잡이 감지된 시점의 절반으로 떨어뜨린 후 다시 느린 시작을 수행한다.

지금까지 학습한 혼잡 제어 알고리즘을 그림으로 정리하면 다음과 같다.

TCP에 대해 설명해주세요. TCP는 신뢰성이 보장되는 연결형 프로토콜입니다. 3-way handshake로 연결을 설정하고, 4-way handshake로 해제합니다. 시퀀스 넘버와 ACK 넘버를 활용해 패킷이 순서대로 도착하도록 보장하며, 오류 제어와 흐름 제어를 통해 패킷 손실 시 재전송하여 신뢰성을 유지합니다. 또한, 혼잡 제어를 통해 네트워크 상태에 따라 전송 속도를 조절하여 효율적인 데이터 전송을 보장합니다.

3 way handshake에 대해 설명해주세요. 3 way handshake는 세 단계로 이루어진 TCP의 연결 수립 과정을 의미합니다. 먼저, 클라이언트가 서버에게 연결 요청을 보내면서 SYN(Synchronizaion) 패킷을 전송합니다. 그러면 서버는 이 요청을 받고, 응답으로 SYN 패킷과 ACK(Acknowledgement) 패킷을 전송합니다. 마지막으로, 클라이언트가 이를 확인했다는 의미로 ACK 패킷을 보내면 연결이 완료됩니다.

4 way handshake에 대해 설명해주세요. 4 way handshake는 네 단계로 이루어진 TCP의 연결 해제 과정을 의미합니다. 먼저, 클라이언트가 서버에게 연결을 해제하겠다는 의미의 FIN(Finish) 패킷을 전송합니다. 그러면 서버는 이 요청을 받고, 응답으로 ACK 패킷을 전송합니다. 그리고 서버도 연결을 종료하기 위해 클라이언트에게 FIN 패킷을 전송합니다. 마지막으로, 클라이언트가 이를 확인했다는 의미로 ACK 패킷을 보내면 연결이 완전히 종료됩니다.

TCP 빠른 재전송에 대해서 설명해주세요. 빠른 재전송이란 패킷 손실을 감지하고 재전송 타이머 만료를 기다리지 않고 즉시 재전송하는 TCP 메커니즘입니다. 만약, 세 번의 중복 ACK 세그먼트가 수신되었다면 패킷이 손실되었다고 간주하고 해당 세그먼트를 곧바로 재전송합니다.

Flow control에 대해 설명해주세요. 흐름 제어(Flow Control)는 송신자가 수신자의 처리 속도를 초과하지 않도록 데이터 전송을 조절하는 메커니즘입니다. TCP에서 대표적인 흐름 제어 방식으로는 슬라이딩 윈도우(Sliding Window) 가 있으며, 수신자는 자신의 버퍼 상태에 따라 윈도우 크기를 송신자에게 알려줍니다. 송신자는 이 정보를 기반으로 데이터 전송 속도를 조절하여 수신 버퍼 오버플로우를 방지하고, 안정적인 데이터 흐름을 유지합니다.

Congestion control에 대해 설명해주세요. 혼잡 제어(Congestion Control)는 네트워크에서 트래픽이 과도하게 증가하여 패킷 손실이나 지연이 발생하는 것을 방지하는 메커니즘입니다. TCP에서는 AIMD(Additive Increase, Multiplicative Decrease), 느린 시작, 혼잡 회피, 빠른 회복 알고리즘 등의 기법을 활용하여 네트워크 상태에 따라 전송 속도를 동적으로 조절합니다. 이를 통해 네트워크 자원을 효율적으로 사용하고, 패킷 손실을 최소화하며 안정적인 데이터 전송을 보장합니다.

전송후 대기 프로토콜이 뭘까요? 전송후 대기(Stop-and-Wait) 프로토콜은 송신자가 하나의 패킷을 전송한 후, 수신자로부터 응답(ACK)을 받을 때까지 대기하는 방식의 흐름 제어 프로토콜입니다. 단순하고 높은 신뢰성을 보장하지만, 응답이 오기 전까지는 전송이 중단되므로 네트워크 이용 효율이 낮다는 단점이 있습니다.

파이프라이닝 프로토콜이 뭘까요? 파이프라이닝(Pipelining) 프로토콜은 여러 개의 패킷을 연속으로 전송하여 전송 효율을 높이는 프로토콜입니다. 이는 전송후 대기(Stop-and-Wait) 프로토콜의 비효율성을 보완하기 위해 사용되며, 송신자는 수신자의 응답(ACK)을 기다리지 않고 일정한 윈도우 크기만큼 연속적으로 패킷을 전송할 수 있습니다. 대표적인 파이프라이닝 프로토콜로는 오류가 발생하면 해당 오류 패킷 이후의 모든 패킷을 다시 전송하는 Go-Back-N 과 오류가 발생한 패킷만 재전송하는 Selective Repeat이 있습니다.

UDP에 대해 설명해주세요. UDP는 TCP와 달리 비연결형 통신을 수행하는 신뢰할 수 없는 프로토콜로, 데이터를 빠르게 전송하는 데 초점을 맞춘 프로토콜입니다. 실시간 스트리밍과 온라인 게임같은 데이터의 정확성보다 빠른 전송이 중요한 경우 사용됩니다.

UDP의 장단점을 설명해 주세요. UDP는 비연결형 프로토콜로, 빠른 전송이 가능하다는 장점이 있습니다. 또한, 헤더 크기가 작아 오버헤드가 적고, 연결 설정 과정 없이 바로 데이터를 전송할 수 있어 지연 시간이 짧다는 장점도 있습니다. 하지만, 흐름 제어 및 혼잡 제어가 없어서 패킷 손실 및 순서 오류가 발생하더라도 재전송하지 않기에, 신뢰할 수 없다는 단점이 있습니다.

UDP 체크섬에 대해 설명해주세요. UDP 체크섬은 데이터그램이 전송 중 오류가 발생했는지 검사하기 위한 필드입니다. 송신자가 데이터의 체크섬 값을 계산하여 UDP 헤더에 포함하면, 수신자는 이를 다시 계산하여 일치 여부를 확인합니다. 만약 값이 다르면 데이터가 손상된 것으로 판단하고 폐기합니다. 다만, 체크섬은 오류 감지만 할 뿐, 재전송을 수행하지 않기 때문에 UDP의 신뢰성과는 무관합니다.

ICMP가 뭘까요? ICMP는 IP 패킷의 전송 과정에 대한 피드백 메시지를 얻기 위해 사용하는 프로토콜이다. IP 프로토콜과 함께 동작하며, 데이터 전송 중 발생하는 문제를 감지하고 알리는 역할을 합니다. 대표적인 ICMP 메시지로는 ping 요청 및 응답(Echo Request/Reply), TTL 초과(Time Exceeded) 메시지가 있습니다. ping 명령어를 통해 ICMP 패킷을 송신하여 네트워크를 진단할 수 있습니다. 네트워크 연결 상태를 확인하는 데 활용되지만, 신뢰성 있는 전송을 보장하지는 않음에 유의해야 합니다.

이전에 배운 물리 계층과 데이터 링크 계층만으로는 LAN을 넘어서 통신하는데 어려움이 있다.

그 이유로는 첫째, 서로 다른 LAN에 속한 호스트가 통신할 때, 수 많은 네트워크 장비를 거치며 다양한 경로를 통해 이동해야 하기 때문이다. 패킷이 이동할 최적의 경로를 결정하는 것을 라우팅 이라고 하며, 물리 계층과 데이터 링크 계층의 장비로는 라우팅을 수행할 수 없지만, 네트워크 계층의 장비로는 가능하다.

둘째, MAC 주소만으로는 모든 네트워크에 속한 호스트의 위치를 특정하기 어렵기 때문이다. 모든 호스트가 모든 네트워크에 속한 모든 호스트의 MAC 주소를 서로 알고 있기는 사실상 어렵다. 택배를 예시로, MAC 주소가 수신인 역할을 한다면 수신지 역할을 하는 정보가 필요한데, 이 정보가 바로 네트워크 계층의 IP 이다. IP 주소는 논리 주소 라고도 부르는데, MAC 주소가 일반적으로 NIC마다 할당되는 고정된 주소라면 IP 주소는 호스트에 직접 할당이 가능하기 때문이다. DHCP(Dynamic Host Configuration Protocol) 이라는 특정 프로토콜을 통해 자동으로 IP 주소를 자동으로 할당받거나 사용자가 직접 할당할 수도 있고, 한 호스트가 여러 IP 주소를 가질 수도 있다.

인터넷 프로토콜

네트워크 계층의 가장 핵심적인 프로토콜 하나를 꼽자면 단연 인터넷 프로토콜(IP; Internet Protocol) 이다. IP에는 IPv4 와 IPv6 버전 두 가지가 존재한다.

IP의 주요 기능

IP의 기능은 다양하지만 대표적으로 크게 두 가지가 있다. IP주소 지정 과 IP 단편화 가 이에 해당한다.

IP주소 지정

• IP 주소를 바탕으로 송수신 대상을 지정하는 것을 의미

  IP 단편화

• 전송하고자 하는 패킷의 크기 > MTU(최대 전송 단위; Maximum Transmission Unit) 일 경우, MTU 크기 이하의 복수의 패킷으로 나누는 것을 의미
• MTU : 한 번에 전송 가능한 IP 패킷의 최대 크기. 일반적으로 1500바이트이고, MTU 크기 이하로 나누어진 패킷은 수신지에 도착하면 다시 재조합됨

IPv4

IP 주소의 형태

• 4바이트(32비트) 표현 가능
• 192.168.1.1 처럼 표현됨
• 옥텟 으로 표현됨
• 옥텟 : 점으로 구분된 8비트(0 ~ 255 범위의 10진수)를 의미함
• 192 168 1 1 은 전부 옥텟

IPv4 패킷

• 프레임의 페이로드로 데이터 필드에 명시됨

이 중에서, 특히 중요한 식별자 플래그 단편화 오프셋 TTL 프로토콜 송신지 IP 주소 수신지 IP 주소 에 대해 살펴보자.

식별자

• 패킷에 할당된 번호
• IPv4 패킷이 여러 조각으로 쪼개졌다면, 어떤 메시지에서부터 쪼개졌는지 인식하기 위해 사용

플래그

• 총 세 개의 비트로 구성된 필드
• 첫 번째 비트 : 항상 0으로 예약된 비트. 사용 X
• 두 번째 비트 : DF(Don't Fragment) 라는 이름을 가짐. 0이라면 IP단편화가 가능하고, 1이라면 IP 단편화를 수행하지 말라는 의미
• 세 번째 비트 : MF(More Fragment) 라는 이름을 가짐. 0이라면 이 패킷이 마지막 패킷임을 의미하고, 1이라면 쪼개진 패킷이 더 있음을 의미함.

단편화 오프셋

• 단편화되기 전에 패킷의 초기 데이터에서 몇 번째로 떨어진 패킷인지를 나타냄
• 단편화되어 전송되는 패킷들이 수신지에 순서대로 도착하지 않을 수도 있기 때문에, 자신이 몇 번째 데이터에 속하는지 알아야하기 때문에 사용

TTL(Time to Live)

• 패킷의 수명을 의미
• 홉 : 패킷이 호스트 또는 라우터에 한 번 전달되는 것
• TTL은 홉 마다 1씩 감소하고, 0으로 떨어진 패킷은 폐기함
• 무의미한 패킷이 네트워크 상에 지속적으로 남아있는 것을 방지

프로토콜

• 상위 계층의 프로토콜이 무엇인지를 나타냄
• 예시로 TCP는 6번, UDP는 17번

송신지 IP 주소와 수신지 IP 주소

• 송수신지의 IPv4 주소를 나타냄

IPv6

• 16바이트(128비트)로 표현 가능
• 2001:0230:abcd:ffff:0000:0000:ffff:1111 처럼 표현됨.
• IPv4 주소는 약 43억개로, 주소의 총량이 쉽게 고갈될 수 있기 때문에 등장함

IPv6 패킷

• 기본 헤더가 IPv4에 비해 간소화 된 형태

이 중에서 다음 헤더 홉 제한 송신지 IP 주소 수신지 IP 주소에 대해 살펴보자.

다음 헤더(next header)

• 상위 계층의 프로토콜 혹은 확장 헤더를 가리킴
• 확장 헤더 : 추가적인 헤더 정보가 필요할 경우에 추가 헤더를 가질 수 있는데, 이를 의미 기본 헤더와 페이로드 데이터 사이에 위치함

  

홉 제한(hot limit)

• IPv4의 TTL 필드와 비슷하게 패킷의 수명을 나타냄

송신지 IP주소와 수신지 IP 주소

• IPv6 주소 지정을 가능하게 해줌

IPv6의 단편화

• IPv6는 단편화 관련 필드가 없어서, 확장 헤더에 포함된 단편화 확장 헤더 를 통해 단편화가 이루어짐(위 사진 참고)
• 단편화 오프셋 : IPv4의 단편화 오프셋과 같은 역할
• M 플래그 : IPv4의 MF 플래그와 같은 역할
• 식별자 : IPv4의 식별자 필드와 같은 역할

ARP(Address Resolution Protocol)

• IP 주소를 통해 MAC 주소를 알아내는 프로토콜
• 동일 네트워크 내에 있는 송수신 대상의 IP 주소를 통해 MAC 주소를 알아낼 수 있음

ARP의 동작 과정

1. ARP 요청
2. ARP 응답
3. ARP 테이블 갱신

1. ARP 요청

A가 B에게 패킷을 보내고 싶다고 가정하자. A는 네트워크 내의 모든 호스트에게 브로드캐스트 메시지를 보낸다. 이 메시지는 ARP 요청 이라는 ARP 패킷이다.

2. ARP 응답

네트워크 내의 모든 호스트가 ARP 요청 메시지를 수신하지만, B를 제외한 나머지 호스트는 자신의 IP 주소가 아니므로 이를 무시한다. 그리고 B는 자신의 MAC 주소를 담은 메시지를 A에게 전송한다. 이 유니캐스트 메시지는 ARP 응답이라는 ARP 패킷이다. B의 MAC 주소가 포함된 메시지를 수신한 A는 B의 MAC 주소를 알게 된다.

3. ARP 테이블 갱신

ARP를 활용할 수 있는 모든 호스트는 ARP 테이블 이라는 정보를 유지하는데, 이는 IP 주소와 그에 맞는 MAC 주소 테이블을 대응하는 표이다. ARP 테이블은 일정 시간이 지나면 삭제되고, 임의로 삭제할 수도 있다. 앞으로 A는 B와 통신할 때 굳이 브로드캐스트로 ARP 요청을 보낼 필요가 없어진다.

IP 단편화를 피하는 방법

데이터가 여러 패킷으로 쪼개지면 전송해야할 패킷의 헤더가 늘어나 불필요한 트래픽 증가와 대역폭 낭비로 이어진다. 또한, 쪼개진 IP 패킷을 합치는 과정에서 발생하는 부하도 성능 저하를 야기함 이와 같은 이유로 IP 단편화는 되도록 하지 않는 것이 좋다.

IP 단편화를 피하기 위해서는 IP 단편화 없이 주고 받을 수 있는 최대 크기 만큼만 전송해야 한다. 이 크기를 경로 MTU 라고 한다. 경로 MTU를 구하고 해당 크기만큼만 송수신하여 IP 단편화를 회피하는 기술을 경로 MTU 발견 이라고 한다.

만약, 어떤 호스트로부터 처리 가능한 MTU 크기를 넘어선 IP 패킷을 전달 받았고, DF 플래그가 1로 설정(단편화를 수행하지 말라) 어 있다고 가정해보자. 이 때는 IP 패킷을 전달한 호스트에게 DF 플래그가 설정되어 있는데, 이걸 단편화 없이 처리할 수 없습니다 라는 특정 오류 메시지를 전달한다.

이걸 이용해 이 오류 메시지를 받지 않을 때까지 전달하는 데이터 크기를 점차 줄여나가면서, 서로의 경로 MTU를 알아갈 수 있다.

IP 주소

하나의 IP 주소는 네트워크 주소 와 호스트 주소로 이루어진다. 네트워크 주소 는 호스트가 속한 특정 네트워크를 식별하는 역할 을 하며 호스트 주소 는 네트워크 내에서 특정 호스트를 식별하는 역할 을 한다.

IP 주소에서 네트워크 주수와 호스트 주소를 구분하는 범위는 유동적일 수 있다. 만약, 호스트 주소 공간을 크게 할당했는데, 가정 내에서만 사용한다면 낭비되는 IP 주소가 많을 것이고, 호스트 주소 공간을 작게 할당했는데, 대규모 인원이 사용하는 회사에서 사용한다면 IP주소가 부족할 것이다. 이런 고민을 해결하기 위해 생겨난 개념이 바로 IP 주소의 클래스 이다.

클래스풀 주소 체계(Classful addressing)

클래스 는 네트워크 크기에 따라 IP 주소를 분류하는 기준이다. 클래스를 이용하면 필요한 호스트 IP 개수에 따라 네트워크 크기를 가변적으로 조정해 네트워크 주소와 호스트 주소를 구획할 수 있게된다. 클래스를 기반으로 IP 주소를 관리하는 주소 체계를 클래스풀 주소 체계라고 한다.

클래스의 종류는 A, B, C, D, E 가 있고, D는 멀티캐스트를 위한 클래스, E는 특수한 목적을 위한 클래스로, 예약된 클래스이다. 따라서 네트워크 크기를 나누는데 실질적으로 사용되는 클래스는 A, B, C 이다.

호스트 주소가 전부 0인 IP 주소는 해당 네트워크 주소를 의미하는 네트워크 주소, 호스트 주소가 전부 1인 IP 주소는 브로드캐스트를 위한 주소 로, 실제 호스트에게 할당 가능한 주소는 이론상의 주소보다 2개가 적음을 인지하자.

A 클래스

• 비트 '0' 으로 시작함
• 네트워크 주소는 1옥텟, 호스트 주소는 3옥텟으로 구성
• 이론상 $$2^7$$ 개의 네트워크, $$2²⁴$$ 개의 호스트 주소를 가짐
• 고정된 비트('0')를 제외하고 나머지 7자리가 네트워크 주소를 구성한다고 이해하면 됨

B 클래스

• 비트 '10' 으로 시작함
• 네트워크 주소는 2옥텟, 호스트 주소는 2옥텟으로 구성
• 이론상 $$2¹⁴$$ 개의 네트워크, $$2¹⁶$$ 개의 호스트 주소를 가짐
• 고정된 비트('10')를 제외하고 나머지 14자리가 네트워크 주소를 구성한다고 이해하면 됨

C 클래스

• 비트 '110' 으로 시작함
• 네트워크 주소는 3옥텟, 호스트 주소는 1옥텟으로 구성
• 이론상 $$2²¹$$ 개의 네트워크, $$2^8$$ 개의 호스트 주소를 가짐
• 고정된 비트('110')를 제외하고 나머지 21자리가 네트워크 주소를 구성한다고 이해하면 됨

클래스리스 주소 체계(Classless addressing)

클래스풀 주소 체계를 이용하면 할당 가능한 호스트의 주소 공간을 유동적으로 관리할 수 있지만, 결국 고정된 크기기 때문에, IP 주소의 낭비가 생기는 상황이 존재한다. 만약, 300명의 직원이 사용할 컴퓨터를 동일 네트워크로 구성할 때, C 클래스는 호스트에게 할당할 수 있는 IP 주소가 254개 뿐이기 때문에, B 클래스를 이용해야 하고, 이는 결국 IP 주소의 낭비로 이어진다.

그래서 클래스풀 주소 체계보다 더 유동적이고, 정교하게 네트워크를 구획할 수 있는 클래스리스 주소 체계가 등장했다. 이름 그대로, 클래스에 구애받지 않고 네트워크의 영역을 나누어 호스트에게 IP 주소를 할당하는 방식이다.

서브넷 마스크

클래스풀 주소 체계는 클래스를 통해 네트워크 주소와 호스트 주소를 구분했다. 그렇다면 클래스리스 주소 체계는 뭘로 두 주소를 구분할까? 그것은 바로 서브넷 마스크 이다. 서브넷 마스크는 IP 주소에서 네트워크 부분을 1, 호스트 부분은 0으로 표기한 비트열 이다. 서브넷 마스크를 이용해 클래스를 원하는 크기로 더 잘게 쪼개어 사용하는 것을 서브네팅 이라고 한다.

서브넷 마스크와 IP 주소를 AND 연산하는 방식 을 통해 네트워크 주소와 호스트 주소를 구분짓는다.

만약, 서브넷 마스크가 255.255.255.0 이라면, 서브넷 마스크의 0이 8개라는 의미고, 호스트 주소는 8비트로 표현이 가능하다는 의미이다. 네트워크 주소를 구한 뒤, 그 주소를 기점으로 $$2^8$$ 개의 호스트를 할당할 수 있다.

아래 예시를 보자.

1. IP 주소와 서브넷 마스크를 AND 연산해서 네트워크 주소 를 구할 수 있다. (192.1658.219.0)
2. 서브넷 마스크에서 0이 8개이므로, 호스트 주소를 8비트로 표현이 가능하고, 이를 통해 실제로 할당 가능한 호스트 IP 주소의 범위를 구할 수 있다. (네트워크 주소, 브로트 캐스트를 제외하면 192.168.219.1 ~ 192.168.219.254)

CIDR 표기법

서브넷 마스크를 표기하는 방법은 두 가지가 있다.

• 255.255.255.0 과 같이 10진수로 직접 표기 (앞의 예시가 이에 해당)
• IP 주소/서브넷 마스크 상의 1의 개수 형식 으로 표기

두 번째 방식을 CIDR 표기법(Classless Inter-Domain Routing notation) 이라고 부르고, 자주 활용된다.

IP 주소 192.168.219.103 과 서브넷 마스크 255.255.255.0 -> 192.168.219.103/24 (CIDR 표기 방식)

공인 IP 주소와 사설 IP 주소

IP는 고유한 IP 주소를 의미하는 공인 IP 주소 와 고유하지 않은 IP 주소인 사설 IP 주소 로 나뉠 수 있다.

공인 IP 주소(public IP address)

• 전 세계에서 고유한 IP 주소
• ISP나 공인 IP 주소 할당 기관을 통해 할당받을 수 있음

사설 IP 주소(private IP address)

사설 IP 주소란 사설 네트워크에서 사용하기 위한 IP 주소이다. 사설 네트워크란 인터넷, 외부 네트워크에 공개되지 않은 네트워크를 의미한다. 실제로 우리가 사용하는 네트워크 기기의 IP 주소를 별도로 신청해서 할당받지는 않았을 텐데, 그 이유가 바로 LAN 내의 호스트는 사설 IP 주소를 사용하기 때문이다.

IP 주소 공간 중에서 사설 IP 주소로 사용하도록 특별히 예약된 IP 주소 공간이 있고, 이는 다음과 같다.

• 10.0.0.0/8 (10.0.0.0 - 10.255.255.255)
• 172.16.0.0/12 (172.16.0.0 - 172.31.255.255)
• 192.168.0.0/16 (192.168.0.0 - 192.168.255.255)

사설 IP 주소의 할당 주체는 일반적으로 라우터 이고, 할당받은 사설 IP 주소는 해당 호스트가 속한 사설 네트워크에서만 유효하므로, 다른 네트워크 상의 사설 IP 주소와 중복될 수 있음을 인지하자.

사설 IP가 사설 네트워크에서만 유효하다면, 사설 IP 주소를 사용하는 호스트가 외부 네트워크와 통신하려면 어떻게 해야할까? NAT 이라는 기술을 사용하면 된다.

NAT(Network Address Translation)

NAT 이란, 네트워크 내부에서 사용되는 사설 IP 주소와 네트워크 외부에서 사용되는 공인 IP 주소를 변환하는데 사용된다.

대부분의 라우터와 공유기는 NAT 기능을 내장하고 있기 때문에, 사설 IP 주소가 공유기를 거쳐 공인 IP로 변경되고, 외부 네트워크로 전송되거나 반대로 외부 네트워크로부터 받은 패킷 속 공인 IP 주소가 공유기를 거쳐 사설 IP 주소로 변경되어 사설 네트워크 속 호스트에 이르게 된다.

NAT의 정확한 동작 방식은 다음 장에서 살펴보겠다.

정적 IP 주소와 동적 IP 주소

호스트에 IP 주소를 할당하는 방식은 정적 할당 과 동적 할당 이 있다. 정적 할당 은 수작업을 통해 이루어지고, 동적 할당 은 DHCP라는 프로토콜을 통해 이루어진다.

정적 할당

호스트에 직접 수작업으로 IP 주소를 부여하는 방식이다. 이렇게 할당된 주소를 정적 IP 주소 라고 부른다.

동적 할당

IP 주소를 정적으로만 할당하다 보면, 의도치 않게 잘못된 IP 주소를 입력할 수도 있고, 중복된 IP 주소를 입력할 수도 있다.

이럴 때 사용 가능한 방식이 바로 동적 할당 이다. IP 동적 할당 사용되는 대표적인 프로토콜이 바로 DHCP(Dynamic Host Configuration Protocol 이다. DHCP는 응용 계층에 속하지만, 네트워크 계층의 개념을 이해하기 위해 살펴보자.

DHCP

DHCP를 통한 IP 주소 할당은 IP 주소를 할당받고자 하는 호스트(클라이언트)와 해당 호스트에게 IP 주소를 제공하는 DHCP 서버 간에 메시지를 주고받음으로써 이루어진다.

DHCP 서버는 클라이언트에게 할당 가능한 IP 주소 목록을 관리하고, 클라이언트가 요청할 때 IP 주소를 할당한다.

DCHP로 할당받은 IP 주소는 사용할 기간(임대 기간)이 정해져 있는데, 일반적으로 수 시간에서 수일로 설정한다. 윈도우 사용자는 ipconfig /all 명령어를 통해 임대 시작 날짜 와 임대 만료 날짜 를 확인할 수 있다.

DHCP 메시지 전달 과정

IP 주소를 할당 받는 과정에서 클라이언트와 DHCP 서버 간에 주고받는 메시지의 종류는 크게 네가지가 있다.

1. DHCP Discover 2. DHCP Offer 3. DHCP Request 4. DHCP Acknowledgment(이하 DHCP ACK)

1. DHCP Discover(클라이언트 -> DHCP 서버)

• Discover : 발견하다
• 클라이언트가 브로드캐스트 전송을 통해 DHCP Discover 메시지를 전송해 DHCP 서버를 찾는 과정
• 전송시점에 클라이언트는 IP 주소를 할당받지 못했으므로, 송신지 IP 주소는 0.0.0.0
• 브로드 캐스트 전송이므로 목적지 IP 주소는 255.255.255.255

2. DHCP Offer(DHCP 서버 -> 클라이언트)

• Offer : 제안하다
• DHCP 서버가 DHCP Discover 메시지를 받은 뒤, 클라이언트에게 DHCP Offer 메시지를 보냄
• DHCP Offer 메시지는 클라이언트에게 할당해 줄 IP 주소를 제안하는 메시지로, 서브넷 마스크, 임대 기간 등의 정보가 포함됨

3. DHCP Request(클라이언트 -> DHCP 서버)

• DHCP Offer 메시지에 대한 응답. 브로드 캐스트로 전송됨
• DHCP Offer 메시지 잘 받았고, 네가 전송해준 IP 주소를 써도 되지? 라고 묻는 재확인 절차

3. DHCP ACK(DHCP 서버 -> 클라이언트)

• DHCP 서버가 클라이언트에게 DHCP ACK 메시지를 보내 최종 승인
• 클라이언트가 DHCP ACK 메시지를 받으면 네트워크 설정을 완료한 후, 임대 기간 동안 IP 주소를 사용
• 임대 기간이 끝나기 전에 임대 기간을 연장할 수 있는데, 이를 임대 갱신 이라 함.
• IP 주소의 임대 기간이 끝나기 전에 기본적으로 두 차례 자동 수행되고, 임대 갱신 과정이 모두 실패하면 IP 주소가 DHCP 서버로 반납됨.
  • 1차 갱신(T1) : 임대 기간의 50% 시점에 갱신 요청
  • 2차 갱신(T2) : 임대 기간의 87.5% 시점에 다시 갱신 요청

라우팅

라우터의 핵심 기능은 패킷이 이동할 최적의 경로를 설정한 뒤 해당 경로로 패킷을 이동시키는 것 이다. 이를 라우팅 이라 한다.

라우팅 테이블 이 만들어지는 방법과 프로토콜에 따라 라우팅을 분류하면 다음 그림과 같이 표현할 수 있다.

라우터

멀리 떨어진 호스트 간의 통신 과정에서 패킷은 서로에게 도달하기 까지 여러 라우터를 거쳐서 다양한 경로로 이동할 수 있다. 이처럼 라우팅 도중 패킷이 호스트와 라우터 간에, 혹은 라우터와 라우터 간에 이동하는 하나의 과정을 홉 이라고 부른다. 즉, 패킷은 여러 홉을 거쳐 라우팅될 수 있다.

그렇다면 라우터는 패킷을 전달할 다음 홉이 어디인지 어떻게 알까? 그것은 라우팅 테이블 덕분이다.

라우팅 테이블

라우팅 테이블 은 특정 수신지까지 도달하기 위한 정보를 명시한 일종의 표와 같은 정보다. 라우터는 라우팅 테이블을 참고하여 수신지까지의 도달 경로를 판단한다. 라우팅 테이블에 포함된 정보는 라우팅 방식에 따라, 호스트의 환경에 따라 달라지지만, 공통적인 정보이자 핵심적인 정보로는 수신지 IP 주소와 서브넷 마스크, 다음 홉, 네트워크 인터페이스 메트릭 이 있다.

수신지 IP 주소와 서브넷 마스크

• 최정적으로 패킷을 전달할 대상을 의미함

다음 홉(next hop)

• 최종 수신지까지 가기 위해 다음으로 거쳐야 할 호스트의 IP 주소나 인터페이스를 의미
• 게이트웨이 라고 명시되기도 함

네트워크 인터페이스

• 패킷을 내보낼 통로

메트릭(metric)

• 해당 경로로 이동하는 데에 드는 비용을 의미
• 라우터는 메트릭이 낮은 경로를 선호함

디폴트 라우트

패킷 내의 수신지 IP 주소가 라우팅 테이블에 있는 수신지 IP 주소, 서브넷 마스크 항목과 완벽하게 합치되는 경우가 있지만, 그렇지 않은 경우가 있다. 즉, 라우팅 테이블에 없는 경로로 패킷을 전송해야 할 때가 있는데, 이 경우에는 기본적으로 패킷을 내보낼 경로 를 설정하여 해당 경로로 패킷을 내보낸다. 이를 디폴트 라우트 라 한다.

정적 라우팅과 동적 라우팅

라우팅 테이블이 만들어지는 방식은 크게 두 가지로, 정적 라우팅 과 동적 라우팅 이 있다.

정적 라우팅

• 사용자가 수동으로 직접 채워 넣은 라우팅 테이블의 항목을 토대로 라우팅되는 방식
• 네트워크의 규모가 커지고 관리해야 할 라우터가 늘어날 경우, 이 방식에는 한계가 있음
• 입력 실수가 발생할 가능성이 존재
• 해당 경로 상에 문제가 발생했을 경우, 경로를 우회하지 못하고 문제가 발생한 경로로 패킷을 전송할 수 밖에 없다는 한계점이 존재

동적 라우팅

• 정적 라우팅의 단점을 보완할 수 있는 라우팅 방식
• 자동으로 라우팅 테이블 항목을 만들고, 이를 이용하여 라우팅 하는 방식
• 라우팅 테이블 항목이 수시로 변할 수 있음
• 네트워크 경로상에 문제가 발생했을 때, 이를 우회할 수 있게 경로를 자동으로 갱신
• (동적) 라우팅 프로토콜 을 사용해 자동으로 라우팅 테이블 항목을 생성

AS(Autonomous System)

• 동일한 라우팅 정책으로 운영되는 라우터들의 집단 네트워크
• 한 회사나 단체에서 관리하는 라우터 집단이 그 예시
• 한 AS 내에는 다수의 라우터가 있고, 라우터들은 AS 내부에서 통신하거나 AS 외부와 통신할 수 있음
• AS 경계에서 AS 내외로 통신을 주고 받는 라우터를 AS 경계 라우터(ASBR; Autonomous System Boundary Router) 라고 함

(동적) 라우팅 프로토콜

모든 라우터는 특정 수신지까지 도달하기 위한 최적의 경로를 찾아 라우팅 테이블에 추가하려 노력한다. 이를 위해 라우터끼리 서로 자신의 정보를 교환하게 되는데, 이 과정에서 사용되는 프로토콜이 바로 (동적) 라우팅 프로토콜 이다. 라우팅 프로토콜 이란 라우터끼리 정보를 교환하며 패킷이 이동할 최적의 경로를 찾기 위한 프로토콜 이다.

라우팅 프로토콜은 크게 AS 내부에서 수행되느냐, AS 외부에서 수행되느냐에 따라 종류를 나눌 수 있다. AS 내부에서 수행되는 라우팅 프로토콜을 IGP (Interior Gateway Protocol) 이라 한다. AS 외부에서 수행되는 라우팅 프로토콜은 EGP (Exterior Gateway Protocol) 이라 한다.

대표적인 IGP로는 RIP와 OSPF가 있고, 대표적인 EGP로는 BGP가 있다.

IGP: RIP와 OSPF

RIP(Routing Information Protocol)

RIP는 최적의 경로를 선정하는 과정에서 거리 벡터 기반의 라우팅 프로토콜이다. 이는 이름 그대로 거리를 기반으로 최적의 경로를 찾는 라우팅 프로토콜을 의미한다. 이 때의 거리 는 홉의 수 (패킷이 경유한 라우터의 수) 를 의미한다.

RIP는 인접한 라우터끼리 경로 정보를 주기적으로 교환하며 라우팅 테이블을 갱신하고, 이를 통해 라우터는 특정 수신지에 도달하기까지의 홉 수를 알 수 있다. 그리고 홉 수가 가장 적은 경로 를 최적의 경로라고 판단한다. 따라서, 홉 수가 적을수록 라우팅 테이블상의 메트릭 값도 작아진다.

OSPF(Open Shortest Path First)

OSPF는 링크 상태 라우팅 프로토콜이다.

OSPF는 노드와 간선의 이루어진 링크 정보를 비롯한 현재 네트워크의 상태를 그래프의 형태로 링크 상태 데이터베이스 에 저장한다.

링크 상태 데이터베이스에는 라우터들의 연결 관계, 연결 비용 등 현재 네트워크의 상태를 그래프로 표현하기 위한 데이터가 저장되어 있다.

라우터는 링크 상태 데이터베이스를 기반으로 현재 네트워크 구성을 마치 지도처럼 그린 뒤 최적의 경로를 선택한다.

OSPF에서는 최적의 경로를 결정하기 위해 대역폭 을 기반을 메트릭을 계산한다. 대역폭이 높은 링크일 수록 메트릭이 낮은 경로로 인식한다.

라우터 간에 경로 정보를 주기적으로 교환하며 라우팅 테이블을 갱신하는 RIP와 달리, OSPF는 네트워크 구성이 변경되었을 때 라우팅 테이블이 갱신된다.

그런데 만약, 네트워크 구성이 변경될 때마다 라우팅 테이블이 변경된다면, 네트워크의 규모가 매우 커졌을 때 링크 상태 데이터베이스에 모든 정보를 저장하기 어려울 것이다.

이에 OSPF에서는 AS를 에어리어 라는 단위로 나누고, 구분된 에어리어 내에서만 링크 상태를 공유한다.

에어리어에는 다음 그림 처럼 번호가 부여되어 있으며, 에어리어 경계에 있는 ABR (Area Border Router) 이라는 라우터가 에어리어의 연결을 담당한다.

EGP : BGP

대표적인 EGP로는 BGP(Border Gateway Protocol)이 있다.

AS 간의 통신에서 사용되는 대표적인 프로토콜이지만, 사실 BGP로 AS 내 라우터 간 통신도 가능하다.

AS 간 통신을 위한 BGP는 eBGP, AS 내의 통신을 위한 BGP는 iBGP 라고 정의한다.

BGP

AS 간에 정보를 주고받기 위해서는 AS 내에서 두 개 이상의 eBGP를 사용하는 라우터가 서로 간에 연결되어야 한다.

이 연결은 BGP 라우터 간에 BGP 메시지를 주고받음으로써 이루어지는데, BGP 메시지를 주고받을 수 있도록 연결된 BGP 라우터를 피어 라고 정의한다.

즉, 다른 AS와 BGP 연결을 유지하기 위해서 BGP 라우터끼리 연결되어 피어가 되어야 하고, 이렇게 피어 관계가 되도록 연결하는 과정을 피어링 이라 한다.

BGP는 RIP와 OSPF에 비해 최적의 경로를 결정하는 과정이 복잡하고, 일정하지 않은 경우가 많다. 경로 결정 과정에서 수신지 주소 뿐만 아니라, 속성 과 정책 이 고려되기 때문이다.

1. AS-PATH 속성

메시지가 수신지에 이르는 과정에서 통과하는 AS의 목록을 의미한다. 만약, AS1 -> AS2로 곧장 간다면 PATH는 AS2, AS1 -> AS3 -> AS2 로 간다면 PATH는 AS3 AS2 가 된다.

이를 통해 BGP의 특징을 알 수 있다.

• BGP는 AS 간 라우팅을 할 때, 거치게 될 라우터 의 수가 아닌 AS 의 수를 고려한다.
  • 따라서, AS-PATH 길이가 더 짧은 경로라 할지라도, 거치게 될 라우터의 홉 수가 더 많을 수 있음
• 둘 째, BGP는 거리가 아닌 경로를 고려한다.
  • 메시지가 같은 경로를 무한히 반복하며 이동하는 순환을 방지하기 위해 경로를 고려함 만약, 자신의 AS가 AS-PATH에 포함되어 있을 경우, 순환 으로 간주해 해당 메시지를 폐기함.

2. NEXT_HOP 속성

다음으로 거칠 라우터의 IP 주소를 나타낸다. AS1 -> AS3 -> AS2에 도달하는 경로의 NEXT-HOP은 AS1과 연결된 라우터 의 IP 주소이다.

3. LOCAL_PREF 속성

LOCAL PREFerence의 약자이다. 이는 AS 외부 경로에 있어 AS 내부에서 어떤 경로를 선호할지에 대한 척도를 나타내는 속성이다. AS-PATH나 NEXT-HOP 속성보다 우선시 되며, 이 값이 클수록 우선으로 선택된다. 정책적인 이유로 이 경로를 우선시 하겠다, 설령 이 경로가 다른 경로에 비해 비교적 비효율적일지라도 이 경로를 우선시하겠다 라는 의미와도 같다.

IPV4와 IPV6는 어떤 차이점이 있을까요? IPv4에서는 주소를 4바이트로 표현하고, IPv6에서는 주소를 16바이트로 표현합니다. IPv4에서 제공되는 주소 개수의 한계 때문에 IPv6가 등장했습니다. IPv6는 보편화 단계에 있으며 IPv4와 혼용해서 사용하기 위해 터널링 기법을 사용합니다.

서브넷과 서브넷 마스크에 대해 설명해주세요. 서브넷은 하나의 큰 네트워크를 더 작은 네트워크로 나눈 부분을 의미합니다. 서브넷 마스크는 IP 주소상에서 네트워크 부분을 1, 호스트 부분은 0으로 표기한 비트열입니다.

라우팅이 뭘까요? 라우팅이란 패킷이 이동할 최적의 경로를 설정한 뒤 해당 경로로 패킷을 이동시키는 것입니다.

라우터에 대해서 설명해주세요. 라우터는 네트워크 계층에서 동작하는 네트워크 장비로, 수신한 데이터 패킷의 목적지까지의 최적 경로를 판단하여 데이터를 전송합니다. 이를 위해 라우터는 라우팅 테이블을 참고하여 도달 경로를 결정합니다. 여러 라우터를 거쳐 데이터가 전달되기 때문에, 서로 멀리 떨어져 있는 호스트 간에도 원활하게 통신할 수 있습니다.

Public IP와 Private IP 차이는 뭘까요? 공인 IP 주소는 전 세계에서 고유한 IP 주소로, ISP나 공인 IP 주소 할당 기관을 통해 할당받을 수 있습니다. 사설 IP 주소란 사설 네트워크에서 사용하기 위한 IP 주소로, 고유하지 않을 수 있으며, 특정 범위 내에서 자유롭게 할당 가능합니다.

라우팅 프로토콜에 대해서 설명해주세요. 라우팅 프로토콜이란 라우터끼리 정보를 교환하며 패킷이 이동할 최적의 경로를 찾기 위한 프로토콜 입니다. AS 내부에서 수행되는 IGP와 AS 외부에서 수행되는 EGP로 나눌 수 있습니다. IGP의 RIP는 거리 벡터 라우팅 프로토콜로, 경로의 "거리"를 기준으로 최적의 경로를 찾습니다. 거리 벡터 프로토콜은 각 라우터가 인접 라우터와의 거리를 교환하여 경로를 계산합니다. IGP의 OSPF는 링크 상태 라우팅 프로토콜로, 각 라우터가 네트워크의 전체 링크 상태 정보를 교환하여 최적의 경로를 계산합니다. OSPF는 경로의 "비용"을 기준으로 경로를 선택합니다. EGP의 BGP는 AS 간 경로 교환을 담당하는 프로토콜로, AS-PATH, NEXT-HOP, LOCAL-PREF 등 다양한 속성을 고려하여 최적의 경로를 찾습니다.

*IP는 어떻게 할당될까요? * IP를 할당하는 방식에는 정적할당과 동적할당이 있습니다. 정적 할당은 호스트에 직접 수작업으로 IP 주소를 부여하는 방식입니다. 동적 할당은 DHCP와 같은 프로토콜을 통해 자동으로 호스트에 IP주소를 할당해주는 방식입니다.

NAT가 뭘까요?. NAT은 네트워크 내부에서 사용되는 사설 IP 주소와 네트워크 외부에서 사용되는 공인 IP 주소를 변환하는데 사용되는 기술입니다. 사설 IP 주소가 공유기를 거쳐 공인 IP로 변경되고 외부 네트워크로 전송되거나 반대로 외부 네트워크로부터 받은 패킷 속 공인 IP 주소가 공유기를 거쳐 사설 IP 주소로 변경되어 사설 네트워크 속 호스트에 이르게 됩니다.