문제는 그 다음부터다. EC2 배포를 한 번이라도 해봤다면, 아래 상황 중 하나 쯤은 겪어봤을 가능성이 높다 🤯

• 로컬에서는 잘 되던 앱이 서버에서는 에러 남;
• 분명 어제까지 되던 코드가 오늘 서버에서는 안된다;;
• 같은 레포를 다른 EC2에 올렸는데 결과가 다름;;; 나같경 다 겪어봄;;;;;;;;;;;;

이때 우리가 흔하게 하는 말이 있다 "아마 서버 환경이 달라서 그런 거 같아요.." 이 말인 즉슨, 문제의 원인이 코드가 아니라 환경일 수도 있다는 사실이다 💦

지금부터 알아보려는 Docker는 위와 같은 상황에 대하여 코드 뿐만 아니라 실행 환경 자체를 함께 관리할 수는 없을까? 라는 질문에 대한 답으로 등장했다.

Docker란?

Docker를 한 문장으로 정의하자면 이렇게 말할 수 있다👇👇👇

애플리케이션과 그 실행 환경을 하나로 묶어서 어디서든 같은 조건으로 실행되게 만드는 기술

VM vs Docker - 뭐가 다른가?!

우선 VM(VirtualMachine)부터 보자! VM은 하나의 서버 위에 또 다른 완전한 서버를 통째로 올리는 방식이라 볼 수 있다. 즉, 애플리케이션을 실행하기 위해 필요한 것뿐만 아니라 운영체제(OS)까지 함께 포함해서 하나의 가상 머신으로 만든다.

🙋‍♀️ 그 결과, 각 VM은 독립적인 OS를 가지게 되는데 .. 그만큼 부팅이 느리고, 자원 사용량이 커지게 된다. 환경이 완전히 분리된다는 안정성은 있지만,, 무거워지는 건 어쩔 수 없다;

❗️반면에❕ Docker는 접근 방식이 다르다. VM과 달리 OS를 새로 만들지 않고, *호스트 OS를 여러 *컨테이너가 공유한다. 즉, OS는 공유하고, 실행 환경만 분리함!

그래서 OS를 포함하지 않기 때문에 가볍고, 바로 실행할 수 있어서 빠르며, 같은 환경을 여러 곳에 쉽게 복제할 수도 있다.

*호스트 OS: Docker나 VM을 실행하고 있는 찐또배기 운영체제 *컨테이너는 아래에서 설명

컨테이너? 이미지?

Docker 이야기를 어렵게 만드는 단어가 바로 이미지와 컨테이너이다. 이게 뭐인고 싶어서 공식 정의부터 보면 오히려 더 헷갈린다;

지피티왈,

• 이미지: 애플리테이션이 실행되기 위한 환경의 설계도
• 컨테이너: 그 설계도로부터 실제로 실행 중인 결과물

로 이해하면 된단다.

조금 더 이해하기 쉽게는, 이미지는 "이 앱은 이런 환경에서 실행돼야 해" 라고 적어둔 묶음 설명서고, 컨테이너는 그 설명서를 기반으로 실제로 떠 있는 실행 상태의 앱이다.

EC2 배포의 경험이랑은 어떻게 이어볼 수 있으까

EC2에 직접 배포할 때를 떠올려보면 우리는 보통 아래와 같은 과정을 거친다👇

서버에 접속 -> Node버전 맞추기 -> 패키지 설치 -> 환경 변수 설정 -> "이 서버에서는 이렇게 돌아가게 하자"는 결정(?)

이 모든 과정이 사실상 이미지를 손으로 만들고 있던 셈이다..🤯 다만 그 이미지가 코드로 남아 있지 않고 서버 안에서만 흩어져 있었을 뿐..

docker는 이 과정을 뒤집어서 "이 서버에서 뭘 설치하지?"가 아니라 "이 앱이 실행되기 위해서 필요한 환경은 뭐지?" 를 먼저 정의한다!

그 정의가 이미지가 되고, 그 이미지를 실행한 결과가 컨테이너다!

기존(EC2)에는 "이 EC2에서 이 코드가 잘 돌게 만들자" 였다면, Docker 이후에는 "어디서든 이 이미지를 실행하면 같은 결과가 나오게 만들자"가 된다

그래서 Docker를 쓰는 배포는 서버에 의존하는 작업이 아니라 실행 환경을 전달하는 작업에 가깝다❕

Docker는 실제로 어디에서 쓰일까?

여기까지 읽었다면, Docker가 단순히 로컬 개발용 도구가 아니라 배포와 실행 환경을 다루는 방식 자체를 바꾸는 기술 라는 건 감이 왔을 것이다!

그래서 Docker는 주로 아래와 같은 상황에서 쓰인다 👇

• 개발자마다 다른 환경에서 작업하던 문제를 줄이고 싶을 때

• 서버가 여러 대로 늘어나면서 환경 재현이 어려워질 때
• 배포 과정을 사람의 손이 아니라 규칙으로 관리하고 싶을 때

이때 docker는 "서버마다 설정을 맞추자"가 아니라 "이 이미지를 어디서나 실행하자"라는 선택지를 만든다! . . 그 이후부터는 또 다른 도구들이 자연스럽게 쓰이는데 그건 기회가 되면 다른 글에서 다뤄보겠다.

Docker를 공부하며 모 유튜버의 영상을 참고했는데 요즘앤 코딩 처음 시작할 때 Docker 설치부터 배운다고 하던데.. 수동 배포를 겪어봐야 하는데 도커부터 배우는 점이 안타깝다고 하던데 그 부분엔 나도 약간 동의. 수동배포하면서 참교육을 당하고 나면 도커가 더더더 고트하게 느껴질 것 같다 끝

오늘 공부해 볼 부분은 ⌜왜 HttpOnly / SameSite / Secure 같은 옵션이 필요한가?⌟ 이다.

이 공부를 통해서 쿠키 옵션 3개가 각각 어떤 공격을 막는지 한 번에 이해하고, 우리 서비스에서 쿠키를 쓴다면 어떤 조합으로 설정해야 하는 지 판단을 명확하게 할 수 있었으면 좋겠다!

왜 쿠키 옵션 이야기를 해야 할까?

요즘 인증 구조를 보면 OAuth 로그인, 서버에서 AccessToken, RefreshToken 발급 -> 토큰을 쿠키에 저장 -> 브라우저는 요청마다 쿠키를 자동으로 전송...

문제는 여기서 끝이 아니다.

쿠키는 기본적으로 브라우저에 저장되고, 요청 시 자동으로 전송되며 설정을 잘못하면 보안 공격의 타깃이 될 수도 있다;;

그래서 등장한 게 바로 HttpOnly, SameSite, Secure 옵션이다.

쉽게 말해서 이 옵션들은 "쿠키를 쓸 순 있는데, 아무렇게 쓰지는 말자~"를 구현한 안전 장치 같은 거라고 볼 수 있다.

HttpOnly란? - "JS는 쿠키 건드리지말거라"

HttpOnly는 말 그대로 JavaScript에서 쿠키에 접근하지 못하게 하는 옵션 이다.

HTTPOnly 옵션이 왜 필요할까?

<XSS에서 토큰이 털리는 과정..> 토큰이 JS에서 읽히는 위치에 있으면 *XSS 발생 시 토큰이 복제되어 탈취될 가능성이 매우 높다..! 즉, 토큰이 쿠키에 있어도 JS에서 읽을 수 있으면 XSS가 한방에 끝이다ㅜㅜ😭

*XSS: 공격자가 웹사이트에 악성 JavaScript를 주입해, 해당 사이트 사용자 권한으로 스크립트를 실행하게 만드는 취약점

그래서 인증 토큰을 쿠키에 넣는다면 HttpOnly는 거의 필수라고 볼 수 있다!

HttpOnly는 JS 접근 차단하고, XSS로부터 토큰 직접 탈취를 방어한다. 프론트에서 토큰을 읽을 수 없게 만드는 대신, 인증 판단은 서버나 응답 결과 기반으로 처리해야 한다!

Secure란? - "HTTPS"에서만 보내라

Secure옵션이 있으면 쿠키는 HTTP 요청에서는 포함되지 않고, HTTPS 요청에서만 전송된다.

Secure 옵션이 왜 필요할까?

이를 이해하기 위해선 HTTP와 HTTPS의 특징을 파악해야 한다. 지난 HTTPS 공부를 참고하자~~

간단하게 살펴보자면, HTTP는 암호화가 없어서 네트워크 구간에서 트래픽이 노출될 수 있다. 이때 쿠키가 평문으로 오가면 중간자 공격/스니핑 같은 방식으로 쿠키가 그대로 탈취될 위험이 있다. 그래서 전송 중 데이터 암호화가 가능한 HTTPS를 사용하게 되는데, Secure은 그 암호화 된 통신에서만 쿠키를 쓰겠다 라는 선언과 같은 것이다.

🙋‍♀️ 그래서 운영 환경에서는 사실상 쿠키 인증이면 Secure는 기본이라고 생각해도 좋을 것 같다.

SameSite란? - "어디서 온 요청인지 살펴보자"

SameSite는 이 쿠키가 어떤 도메인에서만 사용할 수 있는지 설정할 수 있는 옵션으로, CSRF 공격 방어와 관련되어 있다.

왜 필요할까? (CSRF)

쿠키는 "출처를 가리지 않고" 자동 전송된다.

즉, 사용자가 로그인된 상태일때 다른 사이트에서 요청이 발생할 경우, 조건만 맞으면 브라우저에서 쿠키가 같이 전송될 수 있다.

SameSite 옵션 3종류 👀

1️⃣ SameSite = Strict 다른 사이트에서 온 요청은 수락하지 않고, 같은 사이트에서만 전송하는 옵션이다. (반드시 같은 도메인에서만 사용 가능) Strict를 보면 알 수 있듯이 가장 강력해서 외부 링크, OAuth 리다이렉트에도 쿠키가 안 붙는다. 인증 흐름에서는 불편할 수 있지만, 보안은 최고❗️ UX는 최악

2️⃣ SameSite = Lax (기본값) 같은 도메인에서만 사용 가능하지만, 유저가 링크를 클릭해서 접속하거나 하는 경우에는 다른 도메인에서도 사용 가능하다! 대부분의 CSRF 공격을 차단하고, 일반적인 로그인 유지에 적합해서 요즘 가장 많이 쓰이는 옵션이다.

3️⃣ SameSite = None 다른 도메인에서도 사용 가능하며, 모든 요청에 쿠키를 전송한다. 그래서 OAuth, 서브도메인, 외부 인증에서 사용 가능하다. ex) auth.google.com -> wayout.kr(리다이렉트) 와 같은 경우에 사용할 수 있다!

반드시‼️

Secure = True와 함께 써야 한다. (Secure가 없으면 브라우저가 쿠키를 아예 거부한다.) SameSite = None은 사실상 CSRF 방어를 포기하는 선택이라서 브라우저가 암호화된 HTTPS 환경에서만 허용하도록 강제한다..!

쿠키 기반 인증은 편하지만, 옵션 없이 쓰는 쿠키 인증은 위험하다. HttpOnly/Secure/SameSite는 쿠키를 제대로 쓰기 위한 최소한의 안전장치 같은 거라서 꼭 활용하도록 해야겟슨.

마무리는 어젯밤에 먹은 초코칩쿠키사진이다

HTTP란 무엇인가?

HTTP(HyperText Transfer Protocol)는 클라이언트(브라우저)와 서버가 데이터를 주고 받기 위한 규칙(프로토콜)이다.

HTTP는 데이터를 ✌️암호화하지 않고✌️ 평문 그대로 전송하기 때문에 네트워크 중간에서 데이터가 그대로 노출될 수 있다. 그 때문에 로그인 정보, 개인정보가 탈취될 위험이 존재한다.

공용 와이파이 환경에서 HTTP 사이트에 로그인하면 아이디와 비밀번호가 그대로 노출💦 될 수 있음

그래서 HTTP는 보안에 취약하다.

HTTPS란 무엇인가?

HTTPS의 s는 secure로, HTTP에 *보안 계층(SSL/TLS) *을 추가한 프로토콜이다.

HTTPS는 데이터가 암호화되어 전송되고, 그로 인해 중간에서 가로채도 내용을 해독할 수 없다는 특징이 있다. 또한 SSL/TLS 인증서와 CA를 통해 서버의 신뢰성 검증이 가능하다는 장점이 있다. 닉값하는 프로토콜

SSL/TLS 인증서란?

SSL/TLS 인증서는 쉽게 말해 "이 서버는 신뢰할 수 있는 서버" 라는 것을 증명하는 전자 신분증 같은 거라고 볼 수 있다.

🔐 SSL

• SSL (Secure Sockets Layer) → 보안 소켓 계층
• 클라이언트와 서버 사이의 통신을 암호화하기 위해 만들어진 보안 프로토콜
• HTTPS의 초기 보안 기술
• 현재는 보안 취약점 때문에 더 이상 사용되지 않음

🔐 TLS

• TLS (Transport Layer Security) → 전송 계층 보안
• SSL을 개선한 최신 보안 프로토콜
• 현재 HTTPS에서 실제로 사용되는 표준
• 더 강력한 암호화 방식과 보안 구조 제공

HTTPS 통신에서 이 인증서를 통해 서버의 신원 인증, 데이터의 암호화, 데이터의 무결설 보장 이 세 가지가 가능해진다.

인증서는 왜 필요한가?

만약 인증서가 없다면 어떻게 될까? -> 사용자는 접속한 서버가 진짜인지 알 수 없다.

예를 들어, 브라우저에서 https://www.naver.com에 접속하면, 네이버 서버는 SSL/TLS 인증서를 브라우저에 보내준다.

이 인증서에는 “이 서버는 www.naver.com의 서버다”라는 정보와 이를 신뢰할 수 있는 인증기관(CA)이 확인했다는 서명이 들어 있다.

브라우저는 이 인증서를 검증한 뒤에야 통신을 시작한다. 그래서 사용자는 진짜 네이버 서버와 통신 중이라는 것을 보장받을 수 있다❕

CA (Certificate Authority)란?

인증서를 발급하고 관리하는 신뢰 기관으로,

• 서버가 해당 도메인의 실제 소유자인지 확인
• 확인이 끝나면 인증서를 발급
• 인증서에 전자 서명 추가 👆 같은 역할을 한다.

그래서 CA가 서명한 인증서라면 브라우저는 자동으로 서버를 신뢰하게 된다!

HTTPS는 어떻게 동작할까?

앞서 말했다시피 HTTPS는 SSL/TLS라는 보안 프로토콜을 사용하는데, SSL란 초기 암호화 프로토콜로 설명할 수 있다. 현재는 거의 사용하지 않는 프로토콜이다. TLS는 SSL을 개선한 ⌜최신 표준 보안 프로토콜⌟로, 실제로 우리가 쓰는 HTTPS는 TLS기반이다!

브라우저가 서버에 접속 -> 서버가 SSL/TLS 인증서 전달 -> 브라우저가 인증서 신뢰 여부 확인 -> 암호화된 통신 시작 🔐

HTTP vs HTTPS 한눈에 비교

지피티가 말아주는

결론적으로, HTTP보다는 보안 + 사용자 신뢰 + 브라우저 정책까지 모두 고려하는 HTTPS를 사용하는 것이 좋다!

마무리.ㅋ

쿠키 vs 토큰? 애초에 비교부터 잘못되었음..!

인증을 공부하다 보면 "쿠키 vs 토큰" 이라는 표현을 자주 보게 된다. 하지만 이 둘은 서로 대체 관계가 아니라, 역할이 완전히 다르다❗️

쿠키(Cookie)는 저장 방식이고, 토큰은 저장되는 데이터의 한 종류다. 그래서 쿠키 자체를 토큰과 비교하는 것부터가 개념적으로 맞지 않는다. 맙소사

쿠키(Cookie)란?

쿠키는 서버가 브라우저에 저장하도록 지시할 수 있는 작은 데이터다. 쿠키의 목적은 간단하다.

서버가 사용자를 기억하기 위함🧘

쿠키는 어떻게 동작할까?

웹사이트에 처음 방문하면, 브라우저는 서버에 요청(Request)을 보낸다. 서버는 이에 대한 응답(Response)을 보내는데, 이 응답에는 다음과 같은 것들이 포함될 수 있다.

• HTML 페이지
• JSON 데이터
• 브라우저에 저장하라고 지시하는 쿠키(Set-Cookie) 브라우저는 이 쿠키를 저장해 두었다가, 이후 같은 웹사이트에 다시 요청할 때마가 쿠키를 자동으로 함께 전송한다.

즉, 서버는 매 요청마다 "아, 이 사용자는 예전에 이런 정보를 가지고 있었구나"라고 판단할 수 있게 된다!

쿠키는 도메인 기준으로 동작한다

쿠키는 도메인 단위로 제한된다. 예를 들어, youtube.com이 발급한 쿠키는 youtube.com으로 요청할 때만 전송된다. 다른 사이트에서는 해당 쿠키에 접근하거나 전송할 수 없다.

쿠키는 유효기간이 있다

쿠키는 서버가 정한 유효기간(Expires/Max-Age)에 따라 유지된다.

• 유효기간이 지나면 자동으로 삭제됨
• 세션 쿠키의 경우 브라우저 종료 시 삭제되기도 함

쿠키는 인증 외에도 사용된다

쿠키는 인증 정보만 저장하는 용도가 아니다!

예를 들어 웹사이트 언어 설정, 다크 모드 여부, 사용자 UI 설정 등에도 사용이 되는데 그 중 웹사이트 언어 설정의 경우, 사용자가 웹사이트에서 언어를 변경하면 서버는 해당 언어 정보를 쿠키에 저장해 둘 수 있다. 이후 사용자가 다시 방문하면, 브라우저는 쿠키를 요청과 함께 보내고 서버는 쿠키에 저장된 언어 설정을 기반으로 해당 언어의 페이지를 제공한다👏

그런데 쿠키를 이해하다 보면 자연스럽게 이런 의문이 생긴다.(실제로 내가 궁금했던 점들이다..)

• 서버는 왜 사용자를 기억하지 못할까?
• 로그인 상태는 어떻게 유지되는 걸까?
• 세션과 토큰은 쿠키랑 뭐가 다른 걸까?

이 질문에 답하기 위해서는 HTTP의 특성부터 다시 짚고 가야 한다.

HTTP는 왜 사용자를 기억하지 못할까?

HTTP는 stateless(무상태) 프로토콜이다. 즉, 서버는 이전 요청을 기억하지 않고 모든 요청은 완전히 독립적으로 처리된다

서버 입장에서는 "이 요청을 보낸 사용자가 방금 로그인한 사람인지" 알 방법이 없다❗️

그래서 등장한 개념이 바로 _사용자를 어떻게 기억할 것인가_이고, 그 해답이 세션(Session)과 토큰(token)이다.

쿠키는 '기억을 전달하는 수단'이다

쿠키 자체가 인증 방식은 아니다.

이 포인트를 잘 기억해야 한다. 쿠키는 단지 서버가 브라우저에 데이터를 저장하게 하고, 이후 요청마다 그 데이터를 자동으로 전달해주는 수단이다.

이 쿠키를 이용해

• 서버가 직접 사용자를 기억하면 -> 세션(Session)
• 서버가 기억하지 않으면 -> 토큰(Token)

이렇게 방식이 나뉜다.

사용자를 기억하는 방법 ①세션(Session)

세션 방식은 서버가 사용자의 상태를 직접 기억하는 방식이다.

세션 로그인 흐름

1. 사용자가 아이디/비밀번호로 로그인 요청
2. 서버가 인증에 성공하면 Session ID 생성
3. 서버는
   • Session DB에 Session ID <-> 사용자 정보 저장
   • Session ID를 쿠키에 담아 브라우저로 전달
4. 이후 요청마다 브라우저는 쿠키(Session ID)를 자동 전송
5. 서버는 Session ID로 DB를 조회해 사용자 확인

즉, 중요한 정보는 전부 서버에 있고, 브라우저는 Session ID만 들고 다닌다

세션 방식의 특징

• 서버가 로그인한 사용자의 상태를 모두 관리
• 특정 사용자 세션을 삭제해 강제 로그아웃 가능
• 인증 상태를 서버가 즉시 제어 가능

🙋‍♀️ 그래서 계정 정지, 강제 로그아웃, 특정 사용자 차단 같은 기능이 중요한 서비스에 적합하다! 그냥 Session을 삭제해버리면 되기 때문이다...

세션 방식의 한계

• 로그인한 사용자 수만큼 서버 자원을 사용해야 함
• 트래픽 증가 시 Session DB 부하
• 서버 확장 시 세션 공유 문제 발생

그래서 실제 서비스에서는 세션 정보를 Redis 같은 *인메모리DB로 분리하여 관리하기도 한다.

* 인메모리 DB란 데이터를 디스크가 아닌 주기억장치(RAM)에 저장하는 데이터베이스임

쿠키가 없는 환경에서는?

세션 방식은 쿠키에 의존한다. 하지만 모바일 앱(IOS/Android) 같은 네이티브 환경에서는 쿠키 사용이 제한적이다.

이때 자연스럽게 등장하는 방식이 토큰(Token) 기반 인증이다.

사용자를 기억하는 방법 ②토큰(Token)

토큰은 서버가 발급한 임의의 String이다.

세션과 달리, 서버가 사용자 상태를 직접 저장하지 않고 토큰 자체를 인증 수단으로 사용한다.

토큰기반 인증 흐름

1. 사용자가 로그인
2. 서버가 토큰 발급
3. 클라이언트가 토큰 저장 (쿠키, localStorage 등)
4. 이후 요청마다 토큰을 함께 전송
5. 서버는 토큰을 검증하고 요청 처리

이 방식에서는 서버가 "이 사용자가 누구인지"를 기억하지 않는다.

JWT(JSON Web Token)는 왜 등장했을까?

JWT는 토큰의 한 종류로, 차이점은 토큰 안에 사용자 정보가 들어있다는 점이다. JWT에는 보통 사용자 ID, 만료 시간, 권한 정보와 같은 정보가 들어 있고, 서명을 통해 위변조 여부를 검증한다.

JWT의 특징

• 서버는 DB 조회 없이(!!) 토큰 검증만으로 인증 가능
• 서버가 사용자 상태를 저장하지 않아도 됨
• 완전히 stateless한 인증 구조

그래서 서버 확장이 쉽고, 대규모 트래픽 환경에 유리하다는 장점이 있다.

JWT의 한계

그렇다면 JWT가 좋기만 한가?? 그건 아니다. 다음과 같은 한계를 가진다.

• 토큰이 유출될 경우 만료전까지 탈취한 사람(?)이 사용 가능
• 특정 사용자를 즉시 로그아웃 시키는 등의 추가 기능 사용이 어려움
• 토큰 길이가 너무 김

그래서 실무에서는 짧은 만료시간의 AccessToken, 긴 만료시간의 RefreshToken을 함께 사용하는 구조가 많다. 내가 했던 모든 프로젝트에서도 대부분 이런 구조였음

다시 정리해보면

• 쿠키(Cookie): 데이터를 저장하고 자동으로 전송하는 수단, 매개체 정도
• 세션(Session): 쿠키(SessionID)를 이용해 서버가 사용자를 기억
• 토큰(Token): 서버가 발급한 인증용 문자열(String)
• JWT: 사용자 정보를 포함한 토큰(DB 조회 없이 인증 가능함)

  쿠키 -> "어떻게 전달할까" 세션/토큰 -> "무엇을 기억할까"

정도로 아~주 간단하게 정리할 수 있을 것 같다. 쿠키를 단순히 "브라우저 저장소"로만 이해하면 세션과 토큰 구조가 계속 헷갈린다 💦

공부하다보니 HttpOnly, Secure, SameSite 등등.. 더 공부해야 할 게 늘어났지만 정리하고 나니 현재 내가 진행하고 있는 서버의 흐름을 이해하기가 훨씬 명확해진 것 같다..

다음 글은 더 공부하고 또 정리해야것다

. . . . . Thanks to 노마드코더, chatGPT

웹소켓은 웹에서 클라이언트(브라우저)와 서버가 실시간으로 양방향 통신을 할 수 있게 해주는 프로토콜

일반 HTTP 통신과 다르게 한 번 연결되면 끊어지지 않고 계속 연결을 유지하면서 서로 자유롭게 데이터를 주고 받을 수 있다는 것이 가장 큰 특징.

✅ 왜 필요한가?

• 실시간 채팅
• 실시간 알림
• 주식 시세, 실시간 데이터 스트리밍
• 위치 추적 서비스

🔥 TypeScript에서 웹소켓 연결하는 기본 구조

// 웹소켓 인스턴스 생성
const socket = new WebSocket('ws://서버주소:포트');

// 연결 성공 시
socket.addEventListener('open', (event: Event) => {
  console.log('웹소켓 연결 성공');
  socket.send('클라이언트에서 보낸 메시지');
});

// 메시지 수신 시
socket.addEventListener('message', (event: MessageEvent) => {
  console.log('서버로부터 받은 메시지:', event.data);
});

// 에러 발생 시
socket.addEventListener('error', (event: Event) => {
  console.error('웹소켓 에러:', event);
});

// 연결 종료 시
socket.addEventListener('close', (event: CloseEvent) => {
  console.log('웹소켓 연결 종료:', event.code, event.reason);
});

✅ 웹소켓 상태 확인

if (socket.readyState === WebSocket.OPEN) {
  socket.send('이미 연결되어 있음');
}

✅ 사용자 정의 타입으로 메시지 다루기

// 예: 서버로부터 오는 JSON 데이터를 파싱할 경우
socket.addEventListener('message', (event: MessageEvent) => {
  const data: { type: string; payload: any } = JSON.parse(event.data);

  switch (data.type) {
    case 'chat':
      console.log('채팅 메시지:', data.payload);
      break;
    case 'notification':
      console.log('알림:', data.payload);
      break;
    default:
      console.warn('알 수 없는 메시지 유형');
  }
});

🙋 정리

• open : 연결 성공 시
• message : 서버로부터 메시지 수신 시
• error : 에러 발생 시
• close : 연결 종료 시

✅ React + TypeScript에서 웹소켓 사용하는 경우

1️⃣ 웹소켓을 어디서 생성할까?

보통 useEffect 훅 안에서 생성하고, 컴포넌트가 언마운트될 때 닫아주는 패턴 사용

import React, { useEffect, useRef } from 'react';

const ChatComponent: React.FC = () => {
  const socketRef = useRef<WebSocket | null>(null);

  useEffect(() => {
    // 웹소켓 연결
    socketRef.current = new WebSocket('ws://서버주소:포트');

    socketRef.current.onopen = (event: Event) => {
      console.log('웹소켓 연결됨');
      socketRef.current?.send('안녕 서버야!');
    };

    socketRef.current.onmessage = (event: MessageEvent) => {
      console.log('받은 메시지:', event.data);
    };

    socketRef.current.onerror = (event: Event) => {
      console.error('에러 발생:', event);
    };

    socketRef.current.onclose = (event: CloseEvent) => {
      console.log('연결 종료:', event.code, event.reason);
    };

    // 클린업
    return () => {
      socketRef.current?.close();
    };
  }, []);

  return <div>채팅 중입니다...</div>;
};

2️⃣ 메시지 데이터 타입 처리

서버가 JSON으로 데이터를 보낼 경우, 타입을 명시해서 파싱하면 좋음

type ServerMessage = {
  type: 'chat' | 'notification';
  payload: any;
};

socketRef.current.onmessage = (event: MessageEvent) => {
  const data: ServerMessage = JSON.parse(event.data);
  if (data.type === 'chat') {
    console.log('채팅 메시지:', data.payload);
  }
};

➕ Tip

• useRef로 socket 인스턴스를 관리하면 다시 렌더링될 때도 인스턴스를 유지할 수 있음.

Q. Prettier 를 쓰면 어떤 점이 좋나요?

A. 코드 포맷을 자동 정리해주고, 일관된 코드 스타일을 유지시켜 줍니다. 그래서 팀 프로젝트나 협업 시 코딩 스타일을 통일할 수 있어요@^^@

1️⃣ Vscode의 Extension 'Prettier'를 설치해줍니다

2️⃣ VScode 설정(settings)에 들어간다.

2️⃣-1. 검색창에 'editor.format'을 친다. 2️⃣-2. "Editor: Format On Save"을 체크 ✔️

3️⃣-1. 검색창에 'default formatter' 을 친다. 3️⃣-2. Default Formatter 에서 'Prettier'를 선택!

4️⃣ 이제부터는 저장하면 prettier가 적용된다! (코드가 이쁘게.. 🫶)

React에서 useEffect는 컴포넌트의 생명주기를 다룰 때 사용하는 Hook임 예를 들어, 컴포넌트가 렌더링 될 때 데이터 가져오기, DOM 업데이트 같은 부수효과(side effect)를 실행할 때 사용됨

useEffect는 언제 쓰나요?

1️⃣ 컴포넌트가 처음 렌더링될 때 실행 (exAPI에서 데이터 가져오기) 2️⃣ 특정 값이 변경될 때 실행 (ex state나 props가 변경될 때 반응) 3️⃣ 컴포넌트가 사라질 때 정리(clean-up) 작업 수행 (ex 이벤트 리스너 제거, 타이머 제거)

useEffect 기본 문법

import { useEffect } from "react";

useEffect(() => {
  // 여기에 실행할 코드 작성
});

✔️ 이렇게만 작성하면? => 렌더링될 때마다 실행됨 (원하지 않는 불필요한 실행이 생길 수도 있음!)

useEffect 실행 시점 컨트롤하기

1️⃣ 마운트(처음 렌더링) 시 한 번만 실행

useEffect(() => {
  console.log("컴포넌트가 처음 렌더링됨!");
}, []);

✔️ [](의존성 배열)이 비어 있으면 한 번만 실행됨 ✔️ 컴포넌트가 처음 나타날 때만 실행하고, 이 후에는 실행되지 않음

2️⃣ 특정 값이 변경될 때 실행

useEffect(()=>{
    console.log(`count 값이 변경됨:', ${count}`);
}, [count]);

✔️ count 값이 변경될 때마다 useEffect가 실행됨 ✔️ count 가 변경되지 않으면 실행되지 않음

3️⃣ 언마운트 시(컴포넌트가 사라질 때) 정리(clean-up)

import { useEffect } from "react";

useEffect(() => {
  const interval = setInterval(() => {
    console.log("1초마다 실행 중...");
  }, 1000);

  return () => {
    clearInterval(interval);
    console.log("타이머가 제거됨!");
  };
}, []);

✔️ return 안에 있는 함수는 컴포넌트가 사라질 때 실행됨 ✔️ 주로 이벤트 리스너 제거, 타이머 정리, 웹소켓 연결 종료 등에 사용됨

실전 예제!

1️⃣ API 데이터 가져오기 (처음 렌더링 시 한 번만 실행)

import { useEffect, useState } from "react";

const App = () => {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetch("https://jsonplaceholder.typicode.com/todos/1")
      .then((response) => response.json())
      .then((json) => setData(json));
  }, []);

  return <div>{data ? JSON.stringify(data) : "로딩 중..."}</div>;
};

2️⃣ 윈도우 크기 변경 감지 (특정 값 변경 시 실행)

import { useEffect, useState } from "react";

const App = () => {
  const [width, setWidth] = useState(window.innerWidth);

  useEffect(() => {
    const handleResize = () => setWidth(window.innerWidth);

    window.addEventListener("resize", handleResize);

    return () => {
      window.removeEventListener("resize", handleResize);
    };
  }, []);

  return <div>현재 창 너비: {width}px</div>;
};

✔️ window.addEventListener 추가 ✔️ 컴포넌트가 사라질 때 removeEventListener로 정리(clean-up)

✅ 정리

• useEffect(() => {...}) : 매 렌더링마다 실행
• useEffect(() => {...}, []) : 처음 한 번만 실행 (마운트 시)
• useEffect(() => {...}, [변수]) : 특정 겂아 변경될 때 실행
• useEffect(() => { return () => {...}}, []) : 언마운트 시 정리 작업 수행

‼️useEffect 사용 시 주의할 점

1. 의존성 배열을 정확하게 설정해야 함

• 의존성 배열을 실수로 빠뜨리면 원치 않는 반복 실행이 발생할 수 있음

2. 클린업 함수(return)를 잘 활용해야 함

• 이벤트 리스너, 타이머 등을 정리하지 않으면 메모리 누수 발생 가능

3. 불필요한 렌더링을 방지해야 함

• useEffect 내에서 상태(state)를 변경하면 무한 루프가 발생할 수 있음

useState는 React의 상태(state) 관리 함수로, 컴포넌트의 상태를 저장하고 변경할 수 있도록 도와주는 React Hook임.

📌 useState 의 기본 사용법

import { useState } from "react";

const Counter = () => {
  // count 상태를 선언하고, 초기값을 0으로 설정
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>현재 카운트: {count}</p>
      <button onClick={() => setCount(count + 1)}>+1 증가</button>
    </div>
  );
};

export default Counter;

1. useState(0) 을 이용해서 count 상태 변수를 만들고, 초기값을 0으로 설정함
2. setCount 함수를 이용해 count 값을 변경할 수 있음
3. 버튼을 클릭하면 setCount(count+1) 이 실행되어 숫자가 1씩 증가함

📌 useState 상세 설명

1️⃣ useState 의 기본 형태

const [state, setState] = useState(intialValue);

• state: 현재 상태 값을 저장하는 변수
• setState: 상태를 변경하는 함수
• initialValue: 상태의 초기값

예제 살펴보기

1. 문자열 상태

const  [name, setName] = useState("Wonbin");

setName("Park"); // 상태 변경 -> 화면 다시 렌더링 됨

2. boolean 값 상태(true/false)

   const [isVisible, setIsVisible] = useState(false);
   

setIsVisible(true); // 상태 변경

**2️⃣ `useState` 에서 객체 사용하기**
```javascript
const [user, setUser] = useState({ name: "Wonbin", age: 24});

const updateAge = () => {
    setUser({...user, age:user.age + 1}); // 기존 객체 복사 후 age만 변경
}

주의할 점

setUser(user.age = 23); 과 같은 형식으로는 해선 안됨! React는 상태가 직접 변경되면 변경을 감지하지 못하므로 반드시 setState를 사용해주어야 함!

3️⃣ useState에서 배열 사용하기

const [items, setItems] = useState(["사과", "바나나"]);

const addItem = () => {
    setItems([...items, "포도"]); // 기존 배열을 복사힌 후 새로운 값 추가
}

=> 배열을 업데이트할 때는 기존 배열을 복사하고 새 값을 추가해야 함. (React는 기존 상태와 새로운 상태를 비교하여 변경된 부분만 렌더링하기 때문임)

useState에서 상태 변경하는 방법

기본적인 상태 변경

setCount(5); // count 값을 5로 변경

이전 상태를 기반으로 변경 (함수형 업데이트)

setCount(prevCount => prevCount + 1);

• 이렇게 하면 최신 상태 값을 기반으로 안전하게 업데이트 할 수 있음.
• 여러 번 setCount(count+1)을 호출하면 한 번만 업데이트 될 수 있으므로, 함수형 업데이트를 사용하면 좋음!

setCount(prev => prev + 1);
setCount(prev => prev + 1);
setCount(prev => prev + 1);

=> 이렇게 하면 count값이 3씩 증가하게 됨

useState 사용 시 주의할 점

1. 상태를 직접 변경해서는 안됨!

   const [user, setUser] = useState({ name: "Wonbin", age: 24 });
   

user.age = 24; // 다음과 같은 방식 ❌

=> 이렇게 하면 React가 변경을 하지 못해서 화면이 업데이트 되지 않음.
✅ 올바른 방법:
```javascript
setUser({...user, age: 23 });

2. 상태 변경은 비동기적으로 처리됨

   console.log(count);
   setCount(count + 1);
   console.log(count); // 여전히 이전 값이 출력됨

   => 상태가 바로 업데이트 되는 것이 아니라 비동기적으로 처리되므로 setCount 후 바로 console.log(count)를 하면 이전 값이 출력될 수 있음.

✅ 올바른 방법:

useEffect(() => {
  console.log("count 값이 변경됨:", count);
}, [count]); // count 값이 변경될 때 실행됨

=> 상태 변경 후 실행되는 효과를 보고 싶다면 useEffect 사용

useState 실전 예제

1️⃣ 입력값을 관리하는 상태

const InputBox = () => {
  const [text, setText] = useState("");

  return (
    <div>
      <input
        type="text"
        value={text}
        onChange={(e) => setText(e.target.value)}
      />
      <p>입력한 값: {text}</p>
    </div>
  );
};

=> 사용자가 입력한 값을 text 상태에 저장하고 화면에 반영

2️⃣ 배열에서 데이터 추가하기

import { useState } from "react";

const TodoList = () => {
  const [todos, setTodos] = useState(["공부하기", "운동하기"]);

  const addTodo = () => {
    setTodos([...todos, "새로운 할 일"]); // 기존 배열 복사 후 새로운 값 추가
  };

  return (
    <div>
      <ul>
        {todos.map((todo, index) => (
          <li key={index}>{todo}</li>
        ))}
      </ul>
      <button onClick={addTodo}>할 일 추가</button>
    </div>
  );
};

=> setTodos([...todos, "새로운 할 일"])을 사용하여 기존 배열을 유지하면서 새로운 항목을 추가

‼️ useState 정리

• useState : React의 상태 관리 Hook
• 사용 방법: const [state, setState] = useState(초기값)
• 상태 변경: setState(새로운 값)
• 이전 값 기반 업데이트: setState(prev => prev + 1)
• 객체 업데이트: setState({...state, 변경할 값})
• 배열 업데이트: setState([...state, 새로운 값])

✔️ useState는 React에서 가장 기본적이면서 중요한 Hook! ✔️ 상태를 직접 변경하지 말고 항상 setState를 사용해야 함 ✔️ 상태 변경은 비동기적으로 처리됨을 항상 기억!

API(Application Programming Interface) 란, 쉽게 말해서 컴퓨터들이 서로 대화할 수 있도록 도와주는 방법 이라고 볼 수 있음.

예를 들어, 피자 가게에서 피자를 주문할 때, 우리는 메뉴판을 보고 원하는 피자를 선택하고, 그 피자의 이름과 사이즈 등을 직원에게 말함. 그러면 직원은 우리가 말한 주문대로 피자를 만들어 줌. 여기서 API는 우리와 피자 가게 사이에서 서로 대화를 돕는 메뉴판과 직원 같은 역할을 함.

• 피자가게: 우리가 주문하고 싶은 정보나 서비스를 제공하는 곳 (ex 인터넷의 어떤 서비스나 웹)
• 주문서: 우리가 피자를 어떻게 만들지 알려주는 정보 (API를 통해 우리가 요청하는 것)
• 피자 완성: 주문서대로 만든 피자를 우리에게 전달하는 것 (API가 우리에게 결과를 보내주는 것)

REST API란?

REST(Representational State Transfer) API는 클라이언트와 서버 간에 데이터를 주고 받기 위한 URL 규칙임. 하이퍼 미디어(링크)를 기반으로 특정 리소스나 데이터를 접근하기 위한 방식으로써 URL에 명시적으로 어떤 데이터를 담고 있는지 나타내야 함.

예를 들어, 사용자의 목록을 받아오는 URL은 다음과 같음

http://domain.com/api/users

여기서 첫 번째 사용자 데이터는 다음과 같이 접근할 수 있음.

http://domain.com/api/users/1

API 함수 예시

https://jsonplaceholder.typicode.com/todos

const apiUrl: string = 'https://jsonplaceholder.typicode.com/todos';

interface Todo { // API에서 반환하는 Todo 객체의 구조 정의. 해당 인터페이스는 각 할 일 항목이 다음 속성들을 가지고 있음을 명시함.
  userId: number;
  id: number;
  title: string;
  completed: boolean;
}  

//TODO: 아래 API 함수의 타입을 정의해 보세요
async function fetchTodos(): Promise<Todo[]> { 
  const response = await fetch(apiUrl);
  const data = await response.json();
  return data;
}  

fetchTodo().then(todos => todos[0].id);

이 코드에서는

• async 키워드를 사용하여 함수가 비동기로 동작함을 나타내며, await로 비동기 작업을 처리함.

• fetch(apiUrl)을 사용하여 apiUrl에 GET 요청을 보내고, 응답을 받아서 response 변수에 저장함.

• response.json()은 응답 데이터를 JSON 형식으로 변환하여, 그 결과를 data 변수에 저장함.

• 함수는 Promise<Todo[]> 타입을 반환함. 즉, 이 함수는 할 일 목록(Todo)의 배열을 포함하는 프로미스를 반환하고, 반환되는 데이터는 Todo 인터페이스와 일치하는 구조로 되어 있음.

• fetchTodos().then() 함수가 비동기적으로 데이터를 가져오면 .then() 블록에서 할 일 목록을 처리할 수 있음. 여기서는 첫 번째 할 일 항목의 id 값을 가져옴.

타입스크립트에서의 타입 단언이란 개발자가 변수의 타입을 명시적으로 지정할 수 있는 방법.

Q. 타입단언은 주로 어떨 때 사용될까요? A. 컴파일러가 타입을 정확하게 추론하지 못하거나, 개발자가 특정 상황에서 타입을 더 명확하게 전달할 때 사용됨.

const a = 'hi' as any;

as를 통해 타입단언을 사용할 수 있음.

EX)

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

const b = {} as Person;
b.name = 'Thor';

위 코드에서 Person은 { name: string; age: number; } 형태의 객체를 요구하고 있음. const b = {} as Person;이 부분에서 실제로는 빈 객체 {}지만 as Person로 이 객체가 Person 타입임을 단언하는 과정임.

이와같은 타입 단언은

타입스크립트 컴파일러에게

"다음의 값은 이런 타입을 가진거야 그러니까 에러를 띄우지마!"

라고 말하는 것임.

타입 단언 사용을 할 경우엔 오류가 난 코드를 컴파일 단계에서 발견하지 못하고 런타임 단계까지 가야 발견할 수가 있는데 이는 타입스크립트를 사용하는 장점을 무시한 셈이다... (any 타입과 마찬가지로 타입단언 또한 남용해선 안됨)

그럼에도 불구하고 타입단언을 사용하는 이유는 무엇인가?

타입 단언의 효용성이 높은 시점은 언제인가?

1. HTML요소에 접근할 때

const Modal: React.FC = () => {
  return (
    <>
      {createPortal(
        <Backdrop />,
        document.getElementById("backdrop") as HTMLDivElement
      )}
      {createPortal(
        <ModalWrapper />,
        document.getElementById("overlay") as HTMLDivElement
      )}
    </>
  );
};

위의 코드는 react의 createPortal을 이용해서 Modal 컴포넌트를 만든 예시임.

index.html에 미리 <div id=backdrop>과 <div id=overlay/>를 만들어 두고 위와 같이 사용한다면 타입 단언을 사용해야 함.

2. 외부 데이터 소스와의 상호작용 시

let data: any = fetchDataFromAPI();
let user = data as User;  // 데이터가 User 타입임을 단언

API 호출이나 외부 라이브러리에서 데이터를 받아올 때 데이터의 타입이 any로 처리되는 경우가 많음. 이때 타입 단언을 사용해서 해당 데이터의 타입을 명확히 지정할 수 있음.

위의 코드에서는 as User를 사용하여 데이터가 User 타입임을 단언하였음

타입 단언으로 특정 타입을 강제할 수 없는 상황은?

타입스크립트의 타입 단언은 컴파일 타임에만 유효하며 런타임에서 실제로 타입이 맞는지 검사하지 않음.

1. 호환되지 않는 타입을 강제하는 경우

let value: any = 42;
let str = value as string;  // 런타임 오류 가능

위의 코드와 같이 숫자를 문자열로 단언하면 컴파일러는 통과시키지만 런타임에서 오류가 발생할 수 있음.

2. null이나 defined에 대한 잘못된 단언

null 인 값을 특정 객체 타입으로 단언하면, 런타임에서 속성에 접근할 때 오류가 발생할 수 있음.

let someValue: any = null;
let obj = someValue as { name: string };  // null을 객체로 단언

3. DOM 요소가 존재하지 않을 때

DOM 요소가 없는 경우에도 타입 단언을 하면, 속성 접근 시 오류가 발생할 수 있음.

let inputElement = document.getElementById("nonExistent") as HTMLInputElement;
inputElement.value = "Hello";  // 런타임 오류

위 코드에서는 nonExistent라는 id를 가진 HTML 요소가 없을 때, null을 입력 필드처럼 사용하려고 해서 오류가 발생할 수 있음.

4. 타입 변환과 혼동

타입단언은 값 자체를 변환하진 않음. 문자열을 숫자로 단언해도 실제 값은 변하지 않기 때문에 런타임 오류가 발생할 수 있음.

let str: any = "123";
let num = str as number;  // 변환되지 않음, 오류 가능

타입스크립트에서 함수 파라미터에 타입을 지정하는 것은 함수의 인자에 대해 명확한 타입을 정의하고 타입 안정성을 보장함. 또한 파라미터에 타입 지정을 통해 함수가 호출될 때 잘못된 타입의 인자가 전달되는 것을 컴파일 단계에서 방지할 수 있음.

1️⃣ 기본적인 함수 파라미터 타입 지정

: 각 함수의 파라미터에 명시적으로 타입을 지정하여 함수 호출 시 타입 오류를 방지함.

function greet(name: string): void {
  console.log("Hello, " + name);
}

greet("Alice");  // 정상 작동
greet(42);       // 오류 발생: Argument of type 'number' is not assignable to parameter of type 'string'.

이 코드에서 greet 함수는 name이라는 문자열(string) 타입의 파라미터를 받음. 만약 string이 아닌 number나 다른 타입의 값을 전달하면 타입스크립트는 컴파일 시점에서 오류를 발생시킴.

2️⃣ 여러 파라미터에 타입 지정

: 여러 개의 파라미터가 있는 함수에서도 각각의 파라미터에 타입을 지정할 수 있음. 각 파라미터는 함수 정의에서 각자의 타입을 가져야 함.

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

add(5, 3);     // 정상 작동
add(5, "3");   // 오류 발생: Argument of type 'string' is not assignable to parameter of type 'number'.

이 함수는 두 개의 숫자 number 파라미터를 받고 그 합을 반환함. 만약 파라미터 중 하나라도 숫자가 아니면 컴파일 에러가 발생함.

3️⃣ 선택적 파라미터

: 타입스크립트에서는 특정 파라미터가 필수가 아니도록 할 수 있음. 이를 선택적 파라미터(optional parameter)라고 하며, 파라미터 뒤에 물음표(?)를 붙여서 선언할 수 있음. 선택적 파라미터는 전달되지 않을 경우 undefined 값을 가짐.

function greet(name: string, age?: number): void {
  if (age) {
    console.log(`Hello, ${name}. You are ${age} years old.`);
  } else {
    console.log(`Hello, ${name}.`);
  }
}

greet("Alice");        // "Hello, Alice."
greet("Bob", 25);      // "Hello, Bob. You are 25 years old."

4️⃣ 기본값이 있는 파라미터(Default Parameter)

: 파라미터에 기본값을 설정할 수 있음. 설정한 기본값이 있는 파라미터는 함수가 호출될 때 해당 인자를 전달하지 않으면 기본값 이 사용됨.

function greet(name: string, greeting: string = "Hello"): void {
  console.log(greeting + ", " + name);
}

greet("Alice");         // "Hello, Alice"
greet("Bob", "Hi");     // "Hi, Bob"

greeting 파라미터는 기본값으로 "hello"를 가지며, 값이 전달되지 않으면 기본값이 사용됨.

5️⃣ Rest 파라미터(Rest Parameter)

: Rest 파라미터를 사용하면 함수가 가변 인자를 받을 수 있음. Rest 파라미터는 배열로 수집되며, 타입 또한 배열 타입으로 지정할 수 있음.

function sum(...numbers: number[]): number {
  return numbers.reduce((acc, num) => acc + num, 0);
}

console.log(sum(1, 2, 3));      // 6
console.log(sum(10, 20, 30));   // 60

위 코드에서 sum 함수는 가변 인자(...number)를 받아서 배열로 처리하며, 각 요소는 number 타입임. 여러 개의 숫자를 전달하면 그 합을 구하는 함수임.

<>function sum(num1, num2, ...numbers)

6️⃣ 유니온 타입

: 하나 이상의 타입을 허용함

7️⃣ 인터페이스를 통한 타입 지정

: 복잡한 객체 형태의 파라미터에 인터페이스 사용할 수 있음.

구조적 타이핑 = 구조적 타입 시스템(Structural Type System)

객체나 데이터 타입을 정의할 때, 그 구조(멤버, 필드, 메서드 등)에 기반하여 타입을 결정하는 개념으로, 객체가 특정 타입을 따르기 위해서 명시적으로 그 타입을 선언할 필요가 없음. 대신 해당 객체가 그 타입의 구조를 충족하면 해당 타입으로 간주함.

≠ 명목적 타입 시스템(Nominal Type System)

구조적 타이핑에서는 객체의 이름보다는 객체가 갖고 있는 속성과 메서드가 중요함

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

let person = { name: "Alice", age: 25 };
let anotherPerson: Person = person;  // 구조만 같으면 할당 가능

위의 예제에서는 anotherPerson 변수가 Person 타입으로 선언되었지만, Person 변수는 명시적으로 Person 타입으로 선언되지 않았음. 그러나 person 객체가 Person 타입의 구조를 만족하기 때문에 타입 추론에 의해 anotherPerson 변수에 할당될 수 있음.

즉, 객체의 구조만 맞으면 해당 타입으로 간주됨

Q.구조적 타이핑의 장점은? A. 객체가 특정 클래스를 명시적으로 상속받거나 구현하지 않더라도 구조만 맞으면 그 타입으로 사용할 수 있어서 유연하게 코드를 작성할 수 있다. 또한 간결한 코드 작성이 가능하다.

특정 타입에 대해 새로운 이름을 붙여주는 기능

복잡한 타입을 더 간결하고 직관적인 이름으로 재사용할 수 있음.

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

const user: User = {
  name: "Alice",
  age: 30
};

type User는 객체의 타입을 정의한 타입 별칭임. 이후 User를 타입으로 사용해 user라는 변수에 그 구조를 따르는 값을 할당함.

타입 확장(&)

기존 타입에 새로운 속성을 추가하거나 변형할 수 있음. 주로 인터섹션 타입을 사용해 타입을 확장함.

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

type Student = Person & { // 확장(상속)
  school: string
}

const jieun: Student = {
  name: 'jieun',
  age: 27,
  school: 'HY'
}

❗️❗️ 그러나 type은 인터페이스와 달리 선언적 확장이 불가능함

타입 별칭은 그 자체로 완전한 정의이기 때문에 새로운 선언을 통해 확장하거나 병합할 수 없음.

type User = {
  name: string;
};

// 새로운 속성을 추가하려고 시도해도 오류 발생
type User = {
  age: number;
}; // Error: Duplicate identifier 'User'.

이처럼 타입 별칭은 한 번 정의되면 같은 이름으로 다시 선언해 확장할 수 없음.

객체 모양의 타입을 정의할 때 유용한 문법

프레임워크(리액트, 뷰 ... 등등)에서는 주로 API 응답, 프롭스, 변수, 함수를 정의할 때 자주 사용함.

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

const vision: Person= {
  name: '비전',
  age: 3
};

인터페이스 확장(extends)

js 클래스에서 상속을 할 때 *extends *키워드를 사용하는데 인터페이스에서도 사용해주면 됨.

interface Person {
   name: string;
}

interface Developer extends Person {
   skill: string;
}

let fe: Developer = { name: 'josh', skill: 'TypeScript' };

➕ 인터페이스 확장은 여러 개 _extends_가 가능함.

(참고로 클래스는 반드시 하나만 extends 할 수 있음)

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

interface Programmer {
   favoriteProgrammingLanguage: string;
}

interface Korean extends Person, Programmer { // 두개의 인터페이스를 받아 확장
   isLiveInSeoul: boolean;
}

const person: Korean = {
   name: '홍길동',
   age: 33,
   favoriteProgrammingLanguage: 'kor',
   isLiveInSeoul: true,
};

인터페이스 선언 병합 (interface Declararion Merging)

동일한 이름을 가진 인터페이스를 여러 번 선언하면, TypeScript가 이를 자동으로 병합하여 하나의 인터페이스로 처리하는 기능

같은 이름을 가진 인터페이스를 여러 번 선언할 수 있으며, 이 인터페이스들은 병합되어 하나의 확장된 형태로 동작.

interface User {
  name: string;
}

interface User {
  age: number;
}

const user: User = {
  name: "Alice",
  age: 30
};

위 코드에서 User라는 인터페이스를 두 번 선언했지만, TypeScript는 이를 병합하여 name과 age 속성을 모두 가지는 하나의 User 인터페이스로 처리함.

컴포넌트가 전달받는 데이터가 객체 형태일 때의 프롭스를 의미

Q. 객체 타입 프롭스를 사용하는 이유는? A. 여러 속성을 한 번에 전달하고 그 속성들을 개별적으로 사용할 수 있다는 장점이 있음. 특히 복잡한 데이터를 처리할 때 객체를 사용하여 여러 값을 하나의 프롭스로 전달하는 방식이 유용함.

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

function UserInfo(props: UserProps) {
  return (
    <div>
      <p>Name: {props.name}</p>
      <p>Age: {props.age}</p>
    </div>
  );
}

• UserProps는 name과 age라는 두 가지 속성을 포함하는 객체 타입의 프롭스.
• UserInfo 컴포넌트는name과 age객체를 전달받아 내부에서 props.name과props.age 로 해당 값을 사용할 수 있음.

➕ 구조 분해 할당 가능

function UserInfo({ name, age }: UserProps) {
  return (
    <div>
      <p>Name: {name}</p>
      <p>Age: {age}</p>
    </div>
  );
}

• 구조 분해 할당을 사용하면 props 객체에서 name과 age라는 속성을 바로 꺼내서 사용할 수 있음. (원래는 props.name, props.age와 같이 사용)

타입간의 호환 여부, 변수에 특정 값을 할당할 수 있는지의 관점

let a: number = 10;
let b: string = 'hi';
b=a; //에러 발생. 호환되지 않음

Q. 이 코드에서 에러가 발생하는데 그 이유는? A.a는 number 타입으로 선언되어 숫자 값인 10을 가지고 있는데, b는 string 타입으로 선언되어 문자값인 'hi'를 가지고 있다. 즉,a변수와 b변수의 타입이 다르기 때문에 발생하는 에러이다.

유니온(Union) 타입

자바스크립트의 OR 연산자(||)와 같이 'A' 이거나 'B'이다 라는 의미의 하나 이상의 타입이 될 수 있는 값을 표현함.

타입호환성 관점에서보면, 유니온 타입은 가각가의 타입 중 하나라도 맞으면 호환될 수 있음.

function logText(text: string | number) {
  // ...
}

Q. 유니온 타입을 사용해야 하는 이유는? A. 유니온 타입을 사용하면 하나의 변수나 함수가 여러 타입을 받을 수 있음. 예를 들어, number와 string 타입을 모두 처리해야 할 때 유니온 타입이 유용함.

  function getAge(age: number | string) {
   if(typeof age == ‘number’) {
    return age.toFixed(); // 정상 동작, age의 타입이 ‘number’로 추론되기 때문에 number 관련된 API를 쉽게 자동완성 할 수 있음
   }

   if(typeof age == 'string') {
     return age; // 문자열 그대로 반환
   }

   return new TypeError('age must be number of string'); // 타입에러 코드

이처럼 유니온 타입을 사용하면 타입스크립트의 장점을 살릴 수 있음.

➕ 타입에러 코드란? JavaScript와 TypeScript에서 발생하는 오류 중 하나로, 값이나 연산이 올바른 데이터 타입이 아닐 때 발생하는 오류임.TypeScript에서는 주로 타입 안정성을 보장하기 위해 사용되기도 함.

주로 다음과 같은 경우에 사용됨

• 함수에 잘못된 타입의 인자가 전달되었을 때.

• 객체에서 존재하지 않는 속성이나 메서드를 호출하려고 할 때.
• null 또는 undefined에 대해 프로퍼티에 접근하려고 할 때.

  // number나 string이 아닌 타입이 들어온 경우
  return new TypeError('age must be number or string');
}

age가 number또는 string일 때는 문제가 없지만, boolean, object, undefined 등의 타입이 잘못 들어왔을 때는 TypeError가 발생함.

Q. 타입에러 코드를 사용하였을때의 장점은? A. 함수가 올바른 타입의 값을 받지 못했을 경우에 경고할 수 있음. 명시적 오류 메시지를 통해 문제를 쉽게 추적하고 해결할 수 있게 도와줌.

인터섹션(intersection) 타입

인터섹션 타입(Intersection Type)은 여러 타입을 모두 만족하는 하나의 타입을 의미함. 즉, 인터섹션 타입은 여러 타입의 모든 속성을 합친 타입임.

타입 호환성 관점에서 보면, 인터섹션 타입은 두 타입의 공통 부분을 만족해야만 호환 가능함.

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

  interface Developer {
      name: string;
      skill: number;
  }

  type Capt = Person & Developer;

위의 예시 코드에서는 Person 인터페이스의 타입 정의와 Developer 인터페이스의 타입 정의를 & 연산자를 이용하여 합친 후 Capt 라는 타입에 할당하였음.

결과적으로 Capt의 타입은 아래와 같음.

{
  name: string;
  age: number;
  skill: string;
}

이처럼 & 연산자를 이용해 여러 개의 타입 정의를 하나로 합치는 방식을 인터섹션 타입을 정의할 수 있음.

• 유니온 타입은 여러 타입 중 하나를 허용하는 방식으로 타입 호환이 유연함.
• 인터섹션 타입은 여러 타입의 속성을 모두 가져야 하므로 더 엄격함.

: 재사용성이 높은 컴포넌트를 만들 때 자주 활용되는 특징이 있음. 특히, 한 가지 타입보다 여러 가지 타입에서 동작하는 컴포넌트를 생성하는 데 사용됨. 타입을 마치 함수의 파라미터처럼 사용하는 것, 타입을 넘겨 타입을 받겠다. (원하는 타입을 넘겨서 그대로 받겠다)

function getText(text) {
  return text;
}

위 함수는 text 라는 파라미터에 값을 넘겨 받아 text를 반환해 줌.

getText('hi'); // 'hi'
getText(10); // 10
getText(true); // true

hi, 10, true 등 어떤 값이 들어가더라도 그대로 반환함.

function getText<T>(text: T): T {
  return text;
}

⬆️ 위 함수는 제네릭 기본 문법이 적용된 형태로, 함수를 호출할 때 아래와 같이 함수 안에서 사용할 타입을 넘겨줄 수 있음.

getText<string>('hi');
getText<number>(10);
getText<boolean>(true);

EX)

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

interface Developer{
    name: string;
    age: string;
}

interface Admin{
    name: string;
    age: boolean;
}

const josh:Developer={
    name:'josh',
    age:'100'
}

age 의 타입이 변경될 때마다 계속 다른 타입을 정의 해 나가야 하는 번거로움이 발생함.

⬇️

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

// interface Developer{
//     name: string;
//     age: string;
// }

// interface Admin{
//     name: string;
//     age: boolean;
// }

interface Anyone<T> {
  name: string;
  age: T;
}

const josh: Anyone<boolean> = {
  name: "josh",
  age: false,
};

제네릭의 사용으로 더 효율적으로 코드를 사용할 수 있음.

리액트 인풋 이벤트 핸들러 코드

import {ChangeEvent, MouseEvent, useState} from 'react';


function ButtonHandler(){
   function showAlert(event:MouseEvent){ //onClick이벤트에 대한 핸들러 showAlert를 정의함.
    console.log(event); //event 객체를 콘솔에 출력함.
   }

return <button onClick={showAlert}>show</button>;
};

function InputHandler(){
    const [todo, setTodo]=useState<string>(''); //string은 굳이 안 넣어도 됨. 
    function updateTodo(event: ChangeEvent<HTMLInputElement>){
        setTodo(event.target.value);
    }
    return <input type='text' value={todo} onChange={updateTodo}/>; //ChangeEvent를 통해 onchange의 이벤트 핸들러의 파라미터를 정의할 수 있음.
}

export {ButtonHandler, InputHandler};

const [todo, setTodo]=useState(''); 에서 이 없어도 되는 이유는 타입스크립트의 타입추론 기능 때문임.

• 변수가 어떤 타입인지 명시적으로 지정하지 않아도, 할당된 값을 보고 타입을 자동으로 추론할 수 있음
• 이 코드에서 useState에 빈 문자열('')을 초기값으로 전달했기 때문에 todo의 타입은 자동으로 string으로 지정됨

함수의 타입 정의

function sum(a: number, b: number) : number{
    return a+b;
}

• 함수 선언: sum이라는 이름의 함수를 정의하고 있.
• 매개변수 타입:
• 이 함수는 숫자 두 개를 입력받는 코드로 a: number_와 _b: number: 두 개의 매개변수 a와 b는 모두 숫자(number) 타입으로 명시되어 있음.
• 반환 타입:
• : number 이 부분은 함수의 반환값이 숫자 타입이어야 한다는 것을 나타냄.
• return a + b: 두 매개변수 a와 b를 더한 값을 반환함. 이 연산 결과도 숫자이므로 함수의 반환 타입 조건을 만족함.

알아야 하는 타입스크립트 개념

• 함수의 타입 정의 방법
• 타입 추론
• 함수의 파라미터 타입 정의
• 함수의 반환 타입 정의 tip 타입표기 - 타입을 정의하는 방식: number:string

타입 스크립트 기본타입

• 문자열(String): 자바스크립트 변수의 타입이 문자열인 경우

  let str: string = 'hi';

  : 를 이용해서 자바스크립트 코드에 타입을 정의하는 방식을 타입 표기라고 함.

• 숫자(number)

  let num: number = 10;

• 진위(boolean)

  let isLoggedIn: boolean = false;

• 객체(object) : interface, class의 상위타입. 타입을 object로 정의하면, any 타입 처럼 모든 타입의 값을 정의할 수 있음

let obj: object = {name: 'NAME', age:29};
  obj={A: 'A', B: 'B'};

❗️객체를 object 타입으로 정의하는 경우 타입스크립트를 사용한 목적이 애매해질 수 있음. (타입스크립트는 타입 검사에 엄격한 편임)

• interface로 구현

          interface IUser {
            name: string,
            age : number
          }

          let obj: IUser = { name: 'NAME', age: 29 };

• type으로 구현

          type UserType = {
            name: string,
            age : number
          }

          let obj: UserType = { name: 'NAME', age: 29 };

• 배열 (array)

let arr: number[] = [1,2,3];

// 제네릭 사용
  let arr: Array<number> = [1,2,3];

• 튜플(tuple): 튜플은 배열의 길이가 고정되고 각 요소의 타입이 지정되어 있는 배열 형식

let arr: [string, number] = ['hi', 10];

만약에 정의하지 않은 타입, 인덱스로 접근할 경우 오류 남.

arr[1].concat('!'); // Error, 'number' does not have 'concat'
arr[5] = 'hello'; // Error, Property '5' does not exist on type '[string, number]'

• 이넘(enum): 흔하게 쓰이는 타입으로 특정 값(상수)들의 집합을 의미하며 열거형 타입을 정의하는 데 사용됨. 이넘은 특정 값들의 집합을 이름으로 관리하고, 이러한 값을 논리적으로 그룹화할 수 있게 해줌.

enum Avengers { 
  Capt, 
  IronMan, 
  Thor 
}

let hero: Avengers = Avengers.Capt;

❗️ enum은 인덱스 번호로도 접근가능함.

enum Avengers { 
  Capt, 
  IronMan, 
  Thor 
}

let hero: Avengers = Avengers[0];

• any: 특정 데이터의 타입을 잘 모르거나 자바스크립트 프로젝트에 타입스크립트를 점진적으로 적용할 때 사용하면 좋은 타입임. 단어 의미 그대로 모든 타입에 대해서 허용한다는 의미를 갖고 있음. 그러나 any 타입을 많이 사용하면 사용할수록 타입스크립트의 장점이 사라질 수 있음.

let str: any = 'hi';
let num: any = 10;
let arr: any = ['a', 2, true];

• void: 반환 값이 없는 함수의 반환타입. return이 없거나 return이 있더라도 반환하는 값이 없으면 함수의 반환 타입을 void로 지정함.

function printSomething(): void {
  console.log('sth');
}

function returnNothing(): void {
  return;
}

• never: 절대 발생하지 않는 값을 의미하는 타입임. 함수가 반복문이나 에러 핸들링으로 인해 함수의 끝에 절대 도달하지 않는 경우에 never 타입을 사용할 수 있음

// 이 함수는 절대 함수의 끝까지 실행되지 않는다는 의미
function loopForever(): never {
  while (true) {
    // ..
  }
}

function neverEnd(): never {
  throw new Error('unexpected');
}

// TypeScript
const message: string = 'hi';

function sum(a: number, b: number): number {
    return a+b;
}

a: number와 b: number: 두 개의 매개변수 a와 b는 모두 숫자(number) 타입으로 명시되어있음. 즉, 이 함수는 숫자 두 개를 입력받아야함. : number 부분은 함수의 반환값이 숫자 타입이어야 한다는 것을 나타냄. return a + b: 두 매개변수 a와 b를 더한 값을 반환함. 이 연산 결과도 숫자이므로 함수의 반환 타입 조건을 만족함.

타입스크립트를 사용하는 이유?

1. 사용자 경험: 실행 시점(컴파일 시점)의 에러를 어느정도 미리 잡아줌
2. 개발자 경험: 코드 자동 완성, 코드 역할에 대한 정보 제공 등

사용자 경험_ 에러의 사전 방지

// @ts-check
/**
@param {number} a
@param {number} b
@returns
*/

function sum (a,b){
    return a+b;
}
sum (10, '20') // '20' 문자열은 number에 해당하지 않음

이러한 이유로 코드레벨에서 에러 사전 방지가 가능하다는 장점이 있음 => 에러 해결 시 문제 없이 잘 작동함!

.js 파일을 .ts 파일로 변환한다면?

function sum (a: number, b: number){
    return a+b;
}
sum (10, '20') // 잘못된 부분을 바로 파악할 수 있음

개발자 경험: 코드 자동 완성, 코드 역할에 대한 정보 제공 등

• 코드를 작성할 때 개발 툴의 기능을 최대로 활용할 수 있음.

    - 타입이 지정되어 있기 때문에 Vscode에서 해당 타입에 대한 API를 미리보기로 띄워줄 수 있고, tab으로 빠르고 정확하게 작성할 수 있음.