CSRF 공격 완전정복 | 원리부터 방어 전략까지 웹 애플리케이션 보안 필수 가이드

- 10월 29, 2025

CSRF 공격 방어 가이드 - 웹 애플리케이션 보안을 위한 CSRF 토큰과 SameSite 쿠키 설정 방법 설명 썸네일

CSRF 공격(크로스사이트 요청 위조)은 사용자의 의도와 무관하게 악의적인 상태변경 요청을 실행하는 웹 보안 취약점으로, CSRF 토큰과 SameSite 쿠키 설정을 통해 효과적으로 방어할 수 있습니다.

CSRF 공격이란 무엇인가

CSRF 공격의 이해를 돕는 해커 예시 모습

웹 애플리케이션 보안에서 가장 위협적인 공격 중 하나인 CSRF(Cross-Site Request Forgery)는 크로스사이트 요청 위조 또는 사이트 간 요청 위조로 불립니다.

이 공격은 사용자가 자신의 의지와 무관하게 공격자가 의도한 행위를 특정 웹사이트에 요청하게 만드는 웹 애플리케이션 취약점입니다.

CSRF 공격의 가장 큰 특징은 세션 탈취가 아닌 정상적인 세션을 악용한다는 점입니다.

공격자는 사용자의 비밀번호나 세션 ID를 직접 훔치지 않습니다.

대신 이미 인증된 사용자의 브라우저를 통해 악의적인 요청을 보내는 방식으로 작동합니다.

CSRF 공격의 역사와 현재

CSRF 공격의 역사와 현재 owasp 년도별 정리

2008년 국내 유명 경매 사이트 옥션에서 발생한 대규모 개인정보 유출 사건의 주요 공격 방식이 바로 CSRF였습니다.

당시 관리자 계정을 탈취하는 데 이 취약점이 활용되었습니다.

CSRF는 2007년 OWASP Top 10에서 5위에 랭크되며 주요 웹 보안 취약점으로 인정받았습니다.

2013년에는 8위로 순위가 하락했고, 2017년부터는 Top 10 목록에서 제외되었습니다.

하지만 이는 위협이 사라졌다는 의미가 아닙니다.

최신 웹 프레임워크들이 기본적인 방어 메커니즘을 제공하면서 발생 빈도가 낮아진 것일 뿐, 여전히 치명적인 보안 위협으로 남아있습니다.

CSRF 공격의 작동 원리와 정의

CSRF 취약점을 정확히 이해하려면 먼저 쿠키와 세션의 작동 방식을 알아야 합니다.

쿠키 기반 인증의 작동 메커니즘

사용자가 웹사이트에 로그인하면 다음과 같은 프로세스가 진행됩니다.

서버는 인증된 사용자 정보를 세션에 저장하고 세션 ID를 생성합니다
생성된 세션 ID를 Set-Cookie 헤더에 담아 클라이언트에게 전달합니다
브라우저는 받은 세션 ID를 쿠키에 저장합니다
이후 해당 도메인으로의 모든 요청에 쿠키가 자동으로 포함됩니다

여기서 핵심은 브라우저가 쿠키를 자동으로 전송한다는 점입니다.

이러한 브라우저의 기본 동작이 바로 CSRF 공격의 근본 원인이 됩니다.

CSRF 공격이 성립되는 조건

CSRF 공격이 성공하기 위해서는 세 가지 조건이 충족되어야 합니다.

조건	설명	중요도
권한이 필요한 기능	비밀번호 변경, 송금, 회원 정보 수정 등 민감한 작업	필수
쿠키 기반 세션 관리	HTTP 쿠키만으로 사용자 세션을 추적	필수
예측 가능한 요청 매개변수	공격자가 모든 요청 파라미터를 알고 있어야 함	필수

이 세 가지 조건이 모두 만족될 때, 공격자는 효과적인 CSRF 공격을 수행할 수 있습니다.

CSRF vs XSS 차이점

많은 개발자들이 CSRF와 XSS(Cross-Site Scripting)를 혼동합니다.

두 공격 방식의 근본적인 차이를 이해하는 것이 중요합니다.

XSS 공격은 사용자가 웹사이트를 신뢰하는 점을 악용하여 악성 스크립트를 클라이언트 측에서 실행합니다.

반면 CSRF 공격은 웹사이트가 사용자의 브라우저를 신뢰하는 점을 악용하여 서버 측에서 원치 않는 작업을 수행하게 만듭니다.

XSS는 정보 탈취가 주목적이지만, CSRF는 상태변경 요청(계정 정보 수정, 송금 등)을 주요 타겟으로 합니다.

CSRF 공격 시나리오 실전 분석

실제 CSRF 공격이 어떻게 이루어지는지 구체적인 시나리오를 통해 살펴보겠습니다.

GET 방식을 이용한 CSRF 공격

GET 방식을 이용한 CSRF 공격 이해를 돕는 예시 이메일 이미지

가장 기본적인 형태의 CSRF 공격은 GET 메서드를 활용합니다.

은행 웹사이트에서 계좌 이체 기능이 다음과 같이 구현되어 있다고 가정해봅시다.

GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

공격자는 이 URL 패턴을 분석한 후, 수취인과 금액을 조작한 악의적인 URL을 만들 수 있습니다.

<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="0" height="0">

이 이미지 태그를 이메일이나 게시판에 삽입하면, 사용자가 해당 페이지를 열 때 브라우저가 자동으로 요청을 보냅니다.

사용자는 아무것도 보이지 않지만, 백그라운드에서 이체 트랜잭션이 실행됩니다.

POST 방식을 이용한 CSRF 공격

POST 방식을 이용한 CSRF 공격 단계 정리

많은 개발자들이 POST 메서드를 사용하면 CSRF로부터 안전하다고 오해합니다.

하지만 이는 잘못된 믿음입니다.

POST 요청도 HTML 폼을 통해 쉽게 위조할 수 있습니다.

<form action="http://bank.com/transfer.do" method="POST">
  <input type="hidden" name="acct" value="MARIA"/>
  <input type="hidden" name="amount" value="100000"/>
  <input type="submit" value="귀여운 고양이 사진 보기"/>
</form>

사용자가 버튼을 클릭하거나, JavaScript를 통해 자동으로 폼을 제출할 수 있습니다.

<body onload="document.forms[0].submit()">

더 자세한 CSRF 공격 메커니즘은 OWASP CSRF 공격 가이드에서 확인할 수 있습니다.

현대적 API와 CSRF

RESTful API가 보편화되면서 PUT, DELETE 같은 HTTP 메서드도 CSRF 공격의 표적이 되고 있습니다.

function put() {
  var x = new XMLHttpRequest();
  x.open("PUT", "http://bank.com/transfer.do", true);
  x.setRequestHeader("Content-Type", "application/json");
  x.send(JSON.stringify({"acct":"MARIA", "amount":100000}));
}

다행히 현대 브라우저들은 동일 출처 정책(Same-Origin Policy)을 통해 이런 요청들을 기본적으로 차단합니다.

하지만 서버에서 CORS(Cross-Origin Resource Sharing)를 잘못 설정하면 여전히 취약점이 발생할 수 있습니다.

CSRF 공격의 영향과 피해 범위

CSRF 공격의 심각성은 피해자의 권한 수준에 따라 달라집니다.

일반 사용자 계정 대상 공격

CSRF 일반 사용자 계정 대상 공격 예시 이미지

일반 사용자가 피해자인 경우, 다음과 같은 피해가 발생할 수 있습니다.

이메일 주소 변경을 통한 계정 탈취
비밀번호 초기화 요청
은행 계좌에서 무단 송금
개인정보 유출
SNS 계정을 통한 스팸 메시지 발송
전자상거래 사이트에서 원치 않는 물품 구매

피해는 해당 사용자의 계정과 데이터에 국한됩니다.

관리자 계정 대상 공격

CSRF 관리자 계정 대상 공격 예시 이미지

관리자 권한을 가진 사용자가 피해자인 경우, 웹 애플리케이션 전체가 위험에 처할 수 있습니다.

공격자는 관리자 권한으로 다음을 수행할 수 있습니다.

전체 사용자 데이터베이스 삭제
새로운 관리자 계정 생성
서버 설정 변경
악성 코드 업로드
백도어 설치

2008년 옥션 사건이 대표적인 사례입니다.

관리자 계정이 CSRF 공격으로 탈취되면서 1천만 명 이상의 개인정보가 유출되었습니다.

효과적이지 않은 CSRF 방어 방법

CSRF 취약점을 방어하기 위해 많은 방법들이 제시되어 왔지만, 일부는 실제로 효과가 없거나 부족합니다.

POST만 사용하기 (실패하는 방법)

GET 대신 POST 메서드만 사용하면 안전하다는 것은 일반적인 오해입니다.

앞서 살펴본 것처럼, 공격자는 HTML 폼을 통해 POST 요청을 쉽게 위조할 수 있습니다.

JavaScript를 사용하면 사용자 개입 없이도 자동으로 폼을 제출할 수 있습니다.

HTTPS만 사용하기 (불충분한 방법)

HTTPS는 데이터 암호화와 무결성을 보장하지만, CSRF 자체를 방어하지는 못합니다.

HTTPS는 전송 계층의 보안을 제공할 뿐, 요청의 출처가 정당한지는 검증하지 않습니다.

물론 HTTPS는 다른 CSRF 방어 기법의 전제 조건으로서 반드시 필요합니다.

비밀 쿠키 사용하기 (무의미한 방법)

"비밀" 쿠키를 추가로 만들어도 CSRF를 방어할 수 없습니다.

브라우저는 해당 도메인의 모든 쿠키를 자동으로 전송하기 때문입니다.

공격자가 만든 악의적인 요청에도 모든 쿠키가 포함됩니다.

Referer 헤더 검증 (한계가 있는 방법)

HTTP Referer 헤더를 확인하는 방법은 일부 효과가 있지만 완벽하지 않습니다.

프라이버시 설정으로 Referer가 전송되지 않을 수 있습니다
일부 프록시나 방화벽이 Referer를 제거할 수 있습니다
북마크에서 접속하는 경우 Referer가 null일 수 있습니다
Paros, Burp Suite 같은 도구로 Referer를 조작할 수 있습니다

Referer 검증은 보조적인 방어 수단으로만 활용해야 합니다.

CSRF 토큰 방어 기법

CSRF 토큰(Anti-CSRF Token)은 가장 효과적이고 널리 사용되는 CSRF 방어 기법입니다.

CSRF 토큰의 작동 원리

CSRF 토큰 방식은 Synchronizer Token Pattern이라고도 불립니다.

작동 메커니즘은 다음과 같습니다.

서버가 페이지를 생성할 때 예측 불가능한 랜덤 토큰을 생성합니다
이 토큰을 서버 세션에 저장하고 동시에 HTML 폼에 숨겨진 필드로 포함시킵니다
사용자가 폼을 제출하면 토큰도 함께 전송됩니다
서버는 받은 토큰과 세션에 저장된 토큰을 비교 검증합니다
토큰이 일치하면 정상 요청으로 처리하고, 불일치하면 거부합니다

공격자는 사용자 세션의 토큰 값을 알 수 없기 때문에, 유효한 요청을 만들 수 없습니다.

CSRF 토큰 구현 방법

토큰은 충분히 강력하고 예측 불가능해야 합니다.

최소 32바이트 이상의 암호학적으로 안전한 난수를 Base64로 인코딩하거나 UUID를 사용하는 것이 권장됩니다.

// Java 예시
SecureRandom random = new SecureRandom();
byte[] token = new byte[32];
random.nextBytes(token);
String csrfToken = Base64.getEncoder().encodeToString(token);

# Python 예시
import secrets
csrf_token = secrets.token_urlsafe(32)

HTML 폼에는 숨겨진 필드로 토큰을 포함시킵니다.

<form method="POST" action="/transfer">
  <input type="hidden" name="csrf_token" value="랜덤토큰값">
  <input type="text" name="amount">
  <button type="submit">전송</button>
</form>

프레임워크별 구현 방법은 OWASP CSRF Prevention Cheat Sheet에서 확인할 수 있습니다.

세션을 사용할 수 없는 환경에서는 Double Submit Cookie 방식을 활용할 수 있습니다.

이 패턴은 다음과 같이 작동합니다.

서버가 랜덤 토큰을 생성하여 쿠키에 설정합니다
동일한 토큰을 폼의 숨겨진 필드나 커스텀 헤더에 포함시킵니다
요청 시 쿠키의 토큰과 파라미터/헤더의 토큰을 비교합니다
두 값이 일치하면 정상 요청으로 처리합니다

공격자는 타 도메인에서 피해자의 쿠키 값을 읽을 수 없으므로, 일치하는 토큰을 생성할 수 없습니다.

CSRF 토큰 관리 전략

효과적인 토큰 관리를 위해 다음 원칙들을 따라야 합니다.

토큰 갱신 주기: 세션당 한 번 생성하거나, 요청마다 새로 생성할 수 있습니다
토큰 무효화: 사용된 토큰은 즉시 무효화하는 것이 더 안전합니다
토큰 저장 위치: 서버 세션, 데이터베이스, 또는 암호화된 쿠키에 저장합니다
타임아웃 설정: 토큰에 유효 시간을 설정하여 오래된 토큰은 거부합니다

주요 웹 프레임워크들은 CSRF 토큰을 자동으로 처리하는 기능을 제공합니다.

SameSite 쿠키 속성을 활용한 CSRF 방어

SameSite는 비교적 최근에 도입된 쿠키 속성으로, 브라우저 수준에서 CSRF를 방어합니다.

SameSite 속성의 세 가지 값

SameSite 속성은 크로스사이트 요청 시 쿠키 전송을 제어합니다.

Strict (가장 엄격)

Set-Cookie: sessionid=abc123; SameSite=Strict; Secure; HttpOnly

Strict로 설정하면 모든 크로스사이트 요청에서 쿠키가 전송되지 않습니다.

외부 사이트에서 링크를 클릭해도 쿠키가 포함되지 않아, 사용자가 로그아웃된 것처럼 보입니다.

보안성은 최고이지만 사용자 경험이 저하될 수 있습니다.

Lax (균형잡힌 선택)

Set-Cookie: sessionid=abc123; SameSite=Lax; Secure; HttpOnly

Lax는 안전한 메서드(GET)를 통한 최상위 레벨 탐색에서만 쿠키를 전송합니다.

외부 링크 클릭은 허용하지만, 폼 제출이나 AJAX 요청에는 쿠키가 포함되지 않습니다.

대부분의 CSRF 공격을 방어하면서도 합리적인 사용자 경험을 제공합니다.

None (제한 없음)

Set-Cookie: sessionid=abc123; SameSite=None; Secure

None으로 설정하면 모든 크로스사이트 요청에 쿠키가 포함됩니다.

이 경우 반드시 Secure 속성과 함께 사용해야 합니다.

iframe에 포함되는 애플리케이션처럼 특별한 경우에만 사용합니다.

브라우저 기본 동작 변화

2020년부터 Chrome, Firefox 등 주요 브라우저들은 SameSite의 기본값을 Lax로 변경했습니다.

즉, 개발자가 명시적으로 설정하지 않아도 기본적인 CSRF 방어가 적용됩니다.

하지만 완전한 보호를 위해서는 명시적으로 SameSite 속성을 설정하는 것이 권장됩니다.

MDN SameSite 문서에서 브라우저별 지원 현황을 확인할 수 있습니다.

SameSite의 한계와 우회 가능성

SameSite는 강력한 방어 수단이지만 완벽하지 않습니다.

다음과 같은 경우 우회될 수 있습니다.

GET 요청으로 상태 변경: Lax 모드에서는 GET 요청에 쿠키가 포함되므로, GET으로 중요한 작업을 수행하면 위험합니다
같은 사이트 내 XSS: 같은 등록된 도메인(예: example.com) 내의 다른 서브도메인에 XSS 취약점이 있으면 우회 가능합니다
2분 규칙: Chrome은 SameSite=Lax로 설정된 쿠키도 생성 후 2분 이내에는 POST 요청에 포함시킵니다
구형 브라우저: 모든 브라우저가 SameSite를 지원하는 것은 아닙니다

따라서 SameSite는 심층 방어(Defense in Depth) 전략의 일부로 사용해야 하며, CSRF 토큰과 병행하는 것이 가장 안전합니다.

프레임워크별 CSRF 방어 구현

현대 웹 프레임워크들은 대부분 내장된 CSRF 방어 메커니즘을 제공합니다.

Django (Python)

Django는 기본적으로 CSRF 보호가 활성화되어 있습니다.

from django.shortcuts import render
from django.views.decorators.csrf import csrf_protect

@csrf_protect
def transfer_money(request):
    if request.method == 'POST':
        # 자동으로 CSRF 토큰 검증
        amount = request.POST.get('amount')
        # 송금 로직
    return render(request, 'transfer.html')

템플릿에서는 {% csrf_token %} 태그를 사용합니다.

<form method="post">
  {% csrf_token %}
  <input type="text" name="amount">
  <button type="submit">전송</button>
</form>

Spring Framework (Java)

Spring Security는 자동으로 CSRF 보호를 활성화합니다.

@Configuration
@EnableWebSecurity
public class SecurityConfig {
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .csrf()
                .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
            .and()
            // 기타 설정
        return http.build();
    }
}

Thymeleaf 템플릿에서는 자동으로 토큰이 포함됩니다.

<form th:action="@{/transfer}" method="post">
  <input type="text" name="amount">
  <button type="submit">전송</button>
</form>

Express.js (Node.js)

Express에서는 csurf 미들웨어를 사용합니다.

const csrf = require('csurf');
const cookieParser = require('cookie-parser');

const csrfProtection = csrf({ cookie: true });

app.use(cookieParser());
app.use(csrfProtection);

app.get('/transfer', (req, res) => {
  res.render('transfer', { csrfToken: req.csrfToken() });
});

app.post('/transfer', (req, res) => {
  // 자동으로 토큰 검증
  res.send('송금 완료');
});

Ruby on Rails

Rails는 기본적으로 모든 폼에 authenticity_token을 포함시킵니다.

class ApplicationController < ActionController::Base
  protect_from_forgery with: :exception
end

뷰에서는 form_with 헬퍼를 사용하면 자동으로 토큰이 포함됩니다.

<%= form_with url: "/transfer", method: :post do |form| %>
  <%= form.text_field :amount %>
  <%= form.submit "전송" %>
<% end %>

CSRF 방어 체크리스트와 입력 검증

효과적인 CSRF 방어를 위한 실전 체크리스트를 제시합니다.

개발 단계 체크리스트

[ ] 모든 상태변경 요청에 CSRF 토큰 적용
[ ] SameSite 쿠키 속성을 Lax 이상으로 설정
[ ] HTTPS 필수 적용 (Secure 플래그 포함)
[ ] 세션 쿠키에 HttpOnly 플래그 설정
[ ] GET 메서드로 중요한 작업 수행 금지
[ ] Referer 헤더 검증 추가 (보조 방어)
[ ] 민감한 작업에는 재인증 요구
[ ] 프레임워크의 내장 CSRF 보호 기능 활용

입력 검증과 출력 인코딩

CSRF 방어와 함께 입력 검증도 중요합니다.

사용자 입력은 항상 서버 측에서 검증해야 합니다.

# Python 예시 - 입력 검증
def validate_amount(amount):
    if not isinstance(amount, (int, float)):
        raise ValueError("금액은 숫자여야 합니다")
    if amount <= 0:
        raise ValueError("금액은 양수여야 합니다")
    if amount > 1000000:
        raise ValueError("1회 송금 한도 초과")
    return amount

XSS 방어를 위한 출력 인코딩도 필수입니다.

// JavaScript 예시 - 출력 인코딩
function escapeHtml(text) {
  const map = {
    '&': '&amp;',
    '<': '&lt;',
    '>': '&gt;',
    '"': '&quot;',
    "'": '&#039;'
  };
  return text.replace(/[&<>"']/g, m => map[m]);
}

테스트와 모니터링

정기적인 보안 테스트가 필요합니다.

OWASP ZAP: 자동화된 CSRF 취약점 스캔
Burp Suite: 수동 침투 테스트
CSRF Tester: OWASP의 CSRF 전용 테스트 도구

보안 로그를 모니터링하여 의심스러운 패턴을 조기에 발견합니다.

# 로깅 예시
import logging

def check_csrf_token(request):
    if not verify_csrf_token(request):
        logging.warning(
            f"CSRF 공격 시도 감지: IP={request.remote_addr}, "
            f"URL={request.url}, Time={datetime.now()}"
        )
        return False
    return True

CSRF 방어의 미래와 보안 모범 사례

웹 보안은 지속적으로 진화하고 있으며, CSRF 방어 전략도 발전하고 있습니다.

제로 트러스트 접근법

CSRF 방어 제로 트러스트 접근법 아키텍처 예시 이미지

현대 보안 아키텍처는 제로 트러스트(Zero Trust) 원칙을 따릅니다.

"신뢰하되 검증하라"가 아닌 "절대 신뢰하지 말고 항상 검증하라"는 철학입니다.

모든 요청을 의심하고, 다층 방어(Multi-Layer Defense) 전략을 구축해야 합니다.

SameSite 쿠키 (1차 방어선)
CSRF 토큰 (2차 방어선)
커스텀 헤더 검증 (3차 방어선)
재인증 요구 (최종 방어선)

보안 교육의 중요성

개발팀 전체가 웹 보안 취약점을 이해하는 것이 중요합니다.

정기적인 보안 교육과 코드 리뷰를 통해 보안 의식을 높여야 합니다.

CSRF뿐만 아니라 OWASP Top 10 전체를 학습하는 것이 권장됩니다.

자동화된 보안 파이프라인

DevSecOps 문화를 도입하여 보안을 개발 프로세스에 통합합니다.

CI/CD 파이프라인에 보안 스캔 도구 통합
코드 커밋 시 자동 정적 분석
배포 전 취약점 스캔 필수화
실시간 보안 모니터링 구축

마치며

CSRF 공격은 여전히 웹 애플리케이션에 심각한 위협입니다.

비록 OWASP Top 10 목록에서 제외되었지만, 이는 위협이 사라졌다는 의미가 아닙니다.

최신 프레임워크가 기본적인 방어 메커니즘을 제공하지만, 개발자의 올바른 이해와 적용이 필수적입니다.

CSRF 방어의 핵심 요약

CSRF 토큰을 모든 상태변경 요청에 적용하세요
SameSite 쿠키 속성을 Lax 이상으로 설정하세요
HTTPS를 필수로 사용하고 Secure 플래그를 설정하세요
GET 메서드로 중요한 작업을 수행하지 마세요
다층 방어 전략을 구축하여 심층 보안을 확보하세요

웹 보안은 한 번의 설정으로 끝나지 않습니다.

지속적인 모니터링, 업데이트, 교육을 통해 안전한 웹 애플리케이션을 구축하고 유지해야 합니다.

이 가이드가 여러분의 웹 애플리케이션 보안 강화에 도움이 되기를 바랍니다.

참고 자료

SQL Injection 완전 가이드 | 공격 원리부터 예방 전략까지 한눈에 보기

SQL Injection 공격 원리와 예방 전략을 완벽 정리. Prepared Statement, 입력 검증, WAF 등 실무 적용 가능한 보안 대책과 OWASP Top 10 기준 최신 사례 분석

🌐 tech-in-depth-hub.blogspot.com

XSS공격 완전정복 | 취약점부터 대응 전략까지 웹 보안의 핵심 가이드

XSS 공격의 모든 것을 다룬 완벽 가이드. Stored, Reflected, DOM-Based XSS 유형별 방어 전략과 CSP, SameSite 쿠키 설정법을 실전 예제와 함께 제공합니다

🌐 tech-in-depth-hub.blogspot.com

서버리스 아키텍처 최적화 베스트 프랙티스 | 비용, 성능, 신뢰성을 모두 잡는 전략 가이드

서버리스 아키텍처 최적화는 콜드스타트 최소화, 메모리 최적화, 함수 패키지 경량화를 통해 비용을 40% 이상 절감하고 성능을 2배 향상시킬 수 있는 필수 전략입니다

🌐 tech-in-depth-hub.blogspot.com

Kubernetes(쿠버네티스) 입문부터 실전 운영까지 | 클러스터 구성, 배포, 최적화 완전 가이드

Kubernetes 입문부터 실전까지! 클러스터 구성, Pod/Deployment 배포, Helm 차트, 자동 스케일링, 보안 설정을 실습 예제로 배우는 완벽 가이드. DevOps 엔지니어 필수 학습 자료.

🌐 tech-in-depth-hub.blogspot.com

동기와 비동기 완전 정복 | 블로킹 / 논블로킹 & 언어별 예제 포함

동기 비동기 차이부터 블로킹/논블로킹 개념, async/await 패턴까지 실전 예제와 함께 완벽하게 정리한 프로그래밍 필수 가이드입니다.

🌐 tech-in-depth-hub.blogspot.com

Tech in Depth tnals1569@gmail.com

피드백 보내기

빅데이터 자격증 취업과 연봉 영향 심층 분석