async/await는 언제 사용하나요?

I/O 대기가 많은 작업(네트워크, 파일)에서 효율적입니다.

Tokio는 무엇인가요?

Rust의 비동기 런타임으로, async/await를 실행합니다.

Future란 무엇인가요?

아직 완료되지 않은 비동기 작업을 나타내는 타입입니다.

Rust 비동기 프로그래밍 | async/await, Tokio

2026년 3월 29일 · 32분 읽기 · 수정 2026년 4월 7일 고급 튜토리얼

이 글의 핵심

Rust 비동기 프로그래밍: async/await, Tokio. async/await 기초·Tokio 런타임.

시리즈 안내

#08 | 📋 전체 목차 | 이전: #07 동시성 · 다음: #09 웹 개발

들어가며

`async`/`await`는 Future를 조합해 I/O 대기를 스레드 한 개로 효율적으로 처리하는 쪽에 가깝습니다. 실행기(Tokio 등)가 준비된 작업만 깨우므로, 블로킹 호출과 섞이지 않게 구성하는 것이 중요합니다. Node.js 이벤트 루프·JavaScript Promise와 같이 “한 스레드에서 많은 I/O를 겹친다”는 인상은 비슷하지만, Tokio는 워커 스레드 풀을 쓰는 경우가 많습니다. Kotlin 코루틴의 `suspend`와도 자주 비교되고, 스레드에 바로 태우는 C++ `std::async`와는 역할이 다릅니다.

1. async/await 기초

기본 사용

async fn fetch_data() -> String {
    String::from("데이터")
}
#[tokio::main]
async fn main() {
    let data = fetch_data().await;
    println!("{}", data);
}

여러 비동기 함수

async fn fetch_user(id: u32) -> String {
    format!("사용자 {}", id)
}
async fn fetch_posts(user_id: u32) -> Vec<String> {
    vec![format!("포스트 1"), format!("포스트 2")]
}
#[tokio::main]
async fn main() {
    let user = fetch_user(1).await;
    println!("{}", user);
    
    let posts = fetch_posts(1).await;
    println!("{:?}", posts);
}

2. Tokio 런타임

프로젝트 설정

[dependencies]
tokio = { version = "1", features = [full] }

태스크 생성

use tokio::time::{sleep, Duration};
#[tokio::main]
async fn main() {
    let task1 = tokio::spawn(async {
        sleep(Duration::from_secs(1)).await;
        println!("Task 1 완료");
        1
    });
    
    let task2 = tokio::spawn(async {
        sleep(Duration::from_secs(2)).await;
        println!("Task 2 완료");
        2
    });
    
    let (result1, result2) = tokio::join!(task1, task2);
    println!("결과: {:?}, {:?}", result1, result2);
}

병렬 실행

use tokio::time::{sleep, Duration};
async fn task(id: u32, duration: u64) -> u32 {
    sleep(Duration::from_secs(duration)).await;
    println!("Task {} 완료", id);
    id
}
#[tokio::main]
async fn main() {
    let (r1, r2, r3) = tokio::join!(
        task(1, 1),
        task(2, 2),
        task(3, 1),
    );
    
    println!("결과: {}, {}, {}", r1, r2, r3);
}

3. 비동기 I/O

파일 읽기

use tokio::fs::File;
use tokio::io::{AsyncReadExt, AsyncWriteExt};
#[tokio::main]
async fn main() -> std::io::Result<()> {
    let mut file = File::open("test.txt").await?;
    let mut contents = String::new();
    file.read_to_string(&mut contents).await?;
    
    println!("{}", contents);
    Ok(())
}

HTTP 요청

use tokio::net::TcpStream;
#[tokio::main]
async fn main() -> std::io::Result<()> {
    let stream = TcpStream::connect("127.0.0.1:8080").await?;
    println!("연결됨");
    Ok(())
}

4. 실전 예제

예제: 병렬 HTTP 요청

use tokio::time::{sleep, Duration};
async fn fetch_url(url: &str) -> Result<String, String> {
    sleep(Duration::from_secs(1)).await;
    Ok(format!("{}의 데이터", url))
}
#[tokio::main]
async fn main() {
    let urls = vec![
        "https://api.example.com/users",
        "https://api.example.com/posts",
        "https://api.example.com/comments",
    ];
    
    let mut tasks = vec![];
    
    for url in urls {
        let task = tokio::spawn(async move {
            fetch_url(url).await
        });
        tasks.push(task);
    }
    
    for task in tasks {
        match task.await {
            Ok(Ok(data)) => println!("받음: {}", data),
            Ok(Err(e)) => println!("에러: {}", e),
            Err(e) => println!("태스크 에러: {}", e),
        }
    }
}

실전 심화 보강

실전 예제: 타임아웃·재시도가 있는 HTTP GET (reqwest)

Cargo.toml:

[dependencies]
tokio = { version = "1", features = ["macros", "rt-multi-thread", "time"] }
reqwest = { version = "0.12", features = ["json", "rustls-tls"] }
serde = { version = "1", features = [derive] }
anyhow = "1"

use reqwest::StatusCode;
use serde::Deserialize;
use std::time::Duration;
use tokio::time::sleep;
#[derive(Debug, Deserialize)]
struct Repo {
    name: String,
    stargazers_count: u64,
}
async fn fetch_with_retry(url: &str, max: u32) -> reqwest::Result<Repo> {
    let client = reqwest::Client::builder()
        .timeout(Duration::from_secs(5))
        .build()?;
    for attempt in 0..max {
        let resp = client.get(url).send().await?;
        let status = resp.status();
        if status == StatusCode::OK {
            return resp.json::<Repo>().await;
        }
        if status.is_server_error() && attempt + 1 < max {
            sleep(Duration::from_millis(200 * (attempt as u64 + 1))).await;
            continue;
        }
        return Err(resp.error_for_status().unwrap_err());
    }
    unreachable!()
}
#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let url = "https://api.github.com/repos/rust-lang/rust";
    let repo = fetch_with_retry(url, 3).await?;
    println!("{} ★ {}", repo.name, repo.stargazers_count);
    Ok(())
}

자주 하는 실수

async fn 안에서 std::thread::sleep을 써서 런타임 워커를 막는 경우.
spawn한 JoinHandle을 await하지 않고 태스크가 드랍되며 취소되는 줄 아는 경우(스레드 풀과 다름).
Mutex를 await 사이에 들고 있는 데드락·지연을 유발하는 경우.

주의사항

블로킹 I/O(일부 파일 API, DNS)는 spawn_blocking으로 격리하는 편이 안전합니다.
Tokio 런타임 스레드 수와 CPU 바운드 작업 분리는 rayon 등과 역할을 나눕니다.

실무에서는 이렇게

tokio::select!로 취소·타임아웃을 한 곳에서 표현합니다.
연결 풀·타임아웃은 reqwest::Client 빌더에서 앱 전역으로 재사용합니다.
로그는 tracing으로 스팬을 남겨 비동기 호출 경로를 추적합니다.

비교 및 대안

런타임/스타일	특징
Tokio	생태계 최대, 네트워크·서버와 궁합
async-std	API가 표준 라이브러리 느낌
스레드 + 채널	CPU 바운드·간단 파이프라인에 여전히 유효

추가 리소스

비동기 심화: 동작 원리, `Future`, 런타임 비교, 에러·동시성

일상 비유로 이해하기: 동시성은 주방에서 여러 요리를 동시에 하는 것과 비슷합니다. 한 명의 요리사(싱글 스레드)가 국을 끓이다가 불을 줄이고, 그 사이에 야채를 썰고, 다시 국을 확인하는 식이죠. 반면 병렬성은 요리사 여러 명(멀티 스레드)이 각자 다른 요리를 동시에 만드는 겁니다.

async/await 동작 원리

async fn은 즉시 완료되지 않는 연산을 나타내는 타입(구현체는 컴파일러가 생성한 상태 머신)을 반환합니다.
.await는 “이 Future가 완료될 때까지 실행기(executor)에게 양보한다”는 의미입니다. 스레드가 막히는 것이 아니라, 다른 태스크로 CPU를 넘깁니다.
런타임(Tokio 등)은 poll을 반복해 Pending이면 나중에 깨우고, Ready면 다음 단계로 진행합니다. 요약하면: async/await는 문법 설탕이고, 실제로는 Future + 실행기 + I/O 드라이버의 조합입니다.

`Future` 트레이트

std::future::Future는 “나중에 값이 나올 수 있는 것”을 모델합니다.

use std::future::Future;
use std::pin::Pin;
use std::task::{Context, Poll};
// Future는 poll로 진행 상황을 묻는다 (실제 코드는 보통 async로 작성)
// type Output = T;  // 완료 시 타입
// fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>;

Poll::Pending: 아직 준비 안 됨 → 런타임이 waker로 다시 스케줄링.
Poll::Ready(val): 완료. async 블록은 이 poll 상태 머신으로 변환되므로, .await 지점이 자연스러운 양보 지점이 됩니다.

Tokio vs async-std

항목	Tokio	async-std
생태계	사실상 표준에 가깝게 넓음 (`hyper`, `tonic`, `axum` 등)	경량·std 스타일 API 지향
API 스타일	`tokio::fs`, `tokio::net` 등 자체 모듈	`async_std::`가 `std`와 비슷한 이름 공간
선택 가이드	새 프로젝트·서버·네트워크는 Tokio가 의존성 정합성이 좋음	기존 코드·특정 크레이트가 async-std를 요구할 때
둘 다 비동기 실행 모델은 비슷하지만, 라이브러리 호환을 위해 한쪽으로 통일하는 것이 일반적입니다.

실전 에러 처리

비동기에서도 Result는 그대로입니다. 다만 ?가 여러 .await를 거치므로 에러 타입을 앱 전역으로 통일하면 편합니다.

async fn load() -> anyhow::Result<String> {
    let s = tokio::fs::read_to_string("config.toml").await?;
    Ok(s)
}

anyhow::Result: 애플리케이션 코드에서 빠르게 에러를 전파할 때.
thiserror: 라이브러리에서 도메인 에러 타입을 정의할 때 (#[derive(Error)]). JoinHandle은 task.await 시 Result<T, JoinError>를 돌려주므로, 스폰 실패·패닉과 본문 Result를 이중으로 매칭하는 패턴이 흔합니다.

match handle.await {
    Ok(Ok(value)) => { /* 성공 */ }
    Ok(Err(e)) => { /* async 블록 내부 Err */ }
    Err(join_err) => { /* 태스크 자체 실패 */ }
}

동시성 제어: `Mutex`, `RwLock`, 채널 (Tokio)

비동기 컨텍스트에서는 가능하면 tokio::sync를 사용합니다. std::sync::Mutex를 잡은 채 .await를 호출하면 같은 런타임 워커가 막혀 데드락·처리량 저하가 날 수 있습니다.

// 실행 예제
use tokio::sync::{Mutex, RwLock, mpsc};
// 공유 상태
let counter = std::sync::Arc::new(Mutex::new(0u64));
let c = counter.clone();
tokio::spawn(async move {
    let mut g = c.lock().await;
    *g += 1;
});
// 읽기 많은 경우 RwLock
let cache = std::sync::Arc::new(RwLock::new(Vec::<String>::new()));
// 태스크 간 메시지 전달
let (tx, mut rx) = mpsc::channel(32);
tokio::spawn(async move {
    while let Some(msg) = rx.recv().await {
        println!("{msg}");
    }
});
tx.send("hello".into()).await.unwrap();

Mutex::lock().await: 비동기 친화적 락.
RwLock: 읽기/쓰기 비율에 따라 선택.
mpsc::channel: 생산자–소비자, 백프레셔(버퍼 크기) 조절. std::sync의 뮤텍스는 blocking 구간이 짧고 await가 없을 때만 고려합니다.

정리

핵심 요약

async/await: 비동기 함수 정의 및 대기
Future: 비동기 작업 표현
Tokio: 비동기 런타임
tokio::spawn: 비동기 태스크 생성
tokio::join!: 병렬 실행 및 결과 대기
동작 원리: 상태 머신 + poll / waker, 실행기가 스케줄링
Tokio vs async-std: 생태계·호환성은 보통 Tokio 우선
에러: anyhow/thiserror, JoinHandle과 내부 Result 구분
동시성: tokio::sync::{Mutex, RwLock, mpsc}로 await와 함께 사용

다음 단계

심화 부록: 구현·운영 관점

이 부록은 앞선 본문에서 다룬 주제(「Rust 비동기 프로그래밍 | async/await, Tokio」)를 구현·런타임·운영 관점에서 다시 압축합니다. 도메인별 세부 구현은 글마다 다르지만, 입력 검증 → 핵심 연산 → 부작용(I/O·네트워크·동시성) → 관측의 흐름으로 장애를 나누면 원인 추적이 빨라집니다.

내부 동작과 핵심 메커니즘

flowchart TD
  A[입력·요청·이벤트] --> B[파싱·검증·디코딩]
  B --> C[핵심 연산·상태 전이]
  C --> D[부작용: I/O·네트워크·동시성]
  D --> E[결과·관측·저장]

sequenceDiagram
  participant C as 클라이언트/호출자
  participant B as 경계(런타임·게이트웨이·프로세스)
  participant D as 의존성(API·DB·큐·파일)
  C->>B: 요청/이벤트
  B->>D: 조회·쓰기·RPC
  D-->>B: 지연·부분 실패·재시도 가능
  B-->>C: 응답 또는 오류(코드·상관 ID)

불변 조건(Invariant): 버퍼 경계, 프로토콜 상태, 트랜잭션 격리, FD 상한 등 단계별로 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
결정성: 순수 층과 시간·네트워크·스케줄에 의존하는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
경계 비용: 직렬화, 인코딩, syscall 횟수, 락 경합, 할당·GC, 캐시 미스를 의심 목록에 둡니다.
백프레셔: 생산자가 소비자보다 빠를 때 버퍼·큐·스트림에서 속도를 줄이는 신호를 어디에 둘지 정의합니다.

프로덕션 운영 패턴

영역	운영 관점 질문
관측성	요청 단위 상관 ID, 에러율·지연 p95/p99, 의존성 타임아웃·재시도가 대시보드에 보이는가
안전성	입력 검증·권한·비밀·감사 로그가 코드 경로마다 일관적인가
신뢰성	재시도는 멱등 연산에만 적용되는가, 서킷 브레이커·백오프·DLQ가 있는가
성능	캐시·배치 크기·커넥션 풀·인덱스·백프레셔가 데이터 규모에 맞는가
배포	롤백 룬북, 카나리/블루그린, 마이그레이션·피처 플래그가 문서화되어 있는가
용량	피크 트래픽·디스크·FD·스레드 풀 상한을 주기적으로 검증하는가

스테이징은 데이터 양·네트워크 RTT·동시성을 프로덕션에 가깝게 맞출수록 재현율이 올라갑니다.

확장 예시: 엔드투엔드 미니 시나리오

앞선 본문 주제(「Rust 비동기 프로그래밍 | async/await, Tokio」)를 배포·운영 흐름에 맞춰 옮긴 체크리스트입니다. 도메인에 맞게 단계 이름만 바꿔 적용할 수 있습니다.

입력 계약 고정: 스키마·버전·최대 페이로드·타임아웃·에러 코드를 경계에 둔다.
핵심 경로 계측: 요청 ID, 단계별 지연, 외부 호출 결과 코드를 로그·메트릭·트레이스에서 한 흐름으로 본다.
실패 주입: 의존성 타임아웃·5xx·부분 데이터·락 대기를 스테이징에서 재현한다.
호환·롤백: 설정/마이그레이션/클라이언트 버전을 되돌릴 수 있는지 확인한다.
부하 후 검증: 피크 대비 p95/p99, 에러율, 리소스 상한, 알림 임계값을 점검한다.

handle(request):
  ctx = newCorrelationId()
  validated = validateSchema(request)
  authorize(validated, ctx)
  result = domainCore(validated)
  persistOrEmit(result, idempotentKey)
  recordMetrics(ctx, latency, outcome)
  return result

문제 해결(Troubleshooting)

증상	가능 원인	조치
간헐적 실패	레이스, 타임아웃, 외부 의존성, DNS	최소 재현 스크립트, 분산 트레이스·로그 상관관계, 재시도·서킷 설정 점검
성능 저하	N+1, 동기 I/O, 락 경합, 과도한 직렬화, 캐시 미스	프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거
메모리 증가	캐시 무제한, 구독/리스너 누수, 대용량 버퍼, 커넥션 미반납	상한·TTL·힙/FD 스냅샷 비교
빌드·배포만 실패	환경 변수, 권한, 플랫폼 차이, lockfile	CI 로그와 로컬 diff, 런타임·이미지 버전 핀
설정 불일치	프로필·시크릿·기본값, 리전	스키마 검증된 설정 단일 소스와 배포 매트릭스 표준화
데이터 불일치	비멱등 재시도, 부분 쓰기, 캐시 무효화 누락	멱등 키·아웃박스·트랜잭션 경계 재검토

권장 순서: (1) 최소 재현 (2) 최근 변경 범위 축소 (3) 환경·의존성 차이 (4) 관측으로 가설 검증 (5) 수정 후 회귀·부하 테스트.

배포 전에는 git add → git commit → git push 후 npm run deploy 순서를 권장합니다.

자주 묻는 질문 (FAQ)

Q. 이 내용을 실무에서 언제 쓰나요?

A. Rust 비동기 프로그래밍: async/await, Tokio. async/await 기초·Tokio 런타임로 흐름을 잡고 원리·코드·실무 적용을 한글로 정리합니다. Rust·비동기·async 중심으로 설명합니다. … 실무에서는 위 본문의 예제와 선택 가이드를 참고해 적용하면 됩니다.

Q. 선행으로 읽으면 좋은 글은?

A. 각 글 하단의 이전 글 또는 관련 글 링크를 따라가면 순서대로 배울 수 있습니다. C++ 시리즈 목차에서 전체 흐름을 확인할 수 있습니다.

Q. 더 깊이 공부하려면?

A. cppreference와 해당 라이브러리 공식 문서를 참고하세요. 글 말미의 참고 자료 링크도 활용하면 좋습니다.

같이 보면 좋은 글 (내부 링크)

이 주제와 연결되는 다른 글입니다.

이 글에서 다루는 키워드 (관련 검색어)

Rust, 비동기, async, Tokio 등으로 검색하시면 이 글이 도움이 됩니다.

이 글이 도움이 되셨나요?

여러분의 피드백은 더 나은 콘텐츠를 만드는 데 도움이 됩니다

문제가 있거나 개선 제안이 있으시면 연락처로 알려주세요.