비동기 코드와 동기 코드의 상호작용

1. 도입

C#의 비동기성은 강력한 도구야. 근데 가끔 비동기 코드를 동기 코드(또는 반대로)에서 호출해야 하는 상황이 생겨. 겉으로는 "마법처럼" 잘 돌아갈 것 같지만, 실제로는 이상한 정지(deadlock), 성능 저하, 심지어 UI가 깨지는 일이 일어날 수 있어. 특히 버그는 실제 데이터나 사용자 환경에서만 나타나는 경우가 많아. 원인은 대개 동기/비동기 코드의 잘못된 상호작용과 .NET의 Task Scheduler 동작의 사소한 디테일에 숨어 있어.

또한 현대 라이브러리와 프레임워크는 비동기 메서드를 적극적으로 사용해. 그래서 비동기 코드를 기존의 동기 호출 흐름에 '붙이는' 법이나, 반대로 비동기 메서드 안에서 동기 코드를 올바르게 호출하는 법을 이해해야 해.

간단 복습: await가 뭘 하는가

다음처럼 썼을 때:

await SomeAsyncMethod();

코드가 두 부분으로 "끊겨": await 전과 후. 첫 부분은 첫 번째 대기 가능한 비동기 작업(예: 네트워크 요청)까지 실행되고, 이후 코드는 그 작업이 끝난 뒤에 계속돼. 질문: 그 "이후의 코드"는 어디서 실행될까? 같은 스레드에서? 다른 스레드에서? 데스크톱 앱(WPF나 WinForms)이면 어떨까, 콘솔이면 어떨까? 답은 상황에 따라 달라. 여기서 예를 들어 ConfigureAwait가 개입해.

SynchronizationContext란?

SynchronizationContext는 .NET의 특별한 메커니즘으로, 비동기 작업의 continuation(계속되는 부분)이 어디서 어떻게 호출되어야 하는지를 "기억"하게 해.

• 전통적인 WinForms/WPF 앱에서는 SynchronizationContext가 await 이후 남은 코드가 UI 스레드에서 계속 실행되도록 보장해서, "다른 스레드에서 컨트롤에 접근" 같은 오류가 안 나게 해줘.
• ASP.NET(옛날, Core 아님)에서는 SynchronizationContext가 HttpContext를 복원하고 HTTP 요청과 계속 작업하도록 도와줘.
• 콘솔 앱이나 ASP.NET Core 앱에서는 보통 SynchronizationContext가 없거나(null) continuation이 스레드풀에서 실행돼.

TaskScheduler란?

TaskScheduler는 더 저수준의 메커니즘이야. 대부분의 경우 TaskScheduler.Default를 쓰는데, 이건 .NET의 스레드풀을 사용해. 언제 어떤 작업이 어디서 실행될지 결정하는 역할을 해.

2. await와 Result/.Wait()를 섞었을 때의 deadlock

가장 유명한 함정 중 하나:

// UI 코드 어딘가에서
var result = SomeAsyncMethod().Result;

또는

SomeAsyncMethod().Wait();

결과: 앱이 "멈춤". 왜 그런 걸까?

어떻게 그런 일이 생기나?

1. 비동기 메서드를 호출하고 바로 .Result나 .Wait()로 현재 스레드를 블록(대기)시킨다.
2. SomeAsyncMethod 내부에서 await를 하고, SynchronizationContext를 통해 같은 스레드에서 continuation을 실행하도록 예약하는데, 그 스레드는 이미 Result/.Wait()로 막혀 있다.
3. 스레드가 continuation을 실행할 수 없으니 작업은 끝나지 않고, 스레드는 자신이 끝나길 기다리고...
4. 결국 deadlock: 스레드가 자기 자신을 기다리는 상황.

이건 UI 앱에서 특히 쉽게 재현돼, UI 스레드에서 모든 코드가 돌아가고 continuation이 그 스레드를 기다릴 때. 콘솔 앱이나 ASP.NET Core(동기화 컨텍스트가 없을 때)에서는 이런 deadlock이 잘 안 생겨.

실전 농담: .Result로 deadlock을 만들었다면 축하해 — Senior로 가는 길에 한 발짝 더 가까워졌어 :D

3. 동기 코드에 비동기 코드를 제대로 섞는 방법

권장 #1: 비동기성은 위에서 아래로 전파하라

비동기 메서드가 생기면 가능한 한 async/await를 호출 스택 위로 올려서 UI나 진입점까지 전파해. 비동기성을 중간에 멈추지 마.

나쁜 예 (스레드 차단):

// 동기 메서드가 .Result로 비동기 메서드를 호출함
public void DoStuff()
{
    var data = GetDataAsync().Result;
    // ...
}

좋은 예 (비동기 전파):

public async Task DoStuffAsync()
{
    var data = await GetDataAsync();
    // ...
}

가능하면 항상 await를 쓰고 .Result / .Wait()는 피하는 게 좋아.

4. 그래도 가끔은: async를 sync에서 호출해야 할 때

위 계층 전체를 async로 바꿔라 (가능하면 이게 최선이야).

특수한 패턴을 써라: 예를 들어 Task.Run으로 별도 스레드에서 작업을 돌리고 그 안에서 async 메서드를 호출한다.

public void DoStuff()
{
    var result = Task.Run(() => SomeAsyncMethod()).Result;
}

단: UI 앱에서는 이 방법도 동기화 이슈가 있으니 꼭 필요한 경우가 아니라면 피하는 게 좋아.

5. ConfigureAwait(false)는 뭘 하나?

어떤 경우에는 await 이후 코드를 같은 스레드에서 계속 실행할 필요가 없어 (예: 서버 앱이나 UI에 접근하지 않는 라이브러리 코드). 오히려 .NET이 특정 스레드에 묶이지 않게 하는 편이 성능에 좋아!

문법과 동작 원리

await SomeAsyncMethod().ConfigureAwait(false);

• ConfigureAwait(false)는 "원래의 SynchronizationContext가 필요 없다, 아무 데서나 계속해도 돼"라고 말하는 거야.
• ConfigureAwait(true) (기본값) — "가능하면 await를 호출한 그 위치(같은 SynchronizationContext)에서 계속 실행해".

시각적 도식

        ┌─────────────────────────────────────────────────────┐
        │                     SynchronizationContext          │
        └─────────────────────────────────────────────────────┘
                      ↑                             ↑
       (UI 스레드)   await SomeAsyncMethod()        Continuation (await 이후)
                  ──────────────────────────────>  (같은 스레드 — ConfigureAwait(true)일 경우)
                      ↓
                    (아무 스레드 — ConfigureAwait(false)일 경우)

ConfigureAwait(false) 사용 예 — "라이브러리" 코드

라이브러리를 만든다고 해보자. WinForms, WPF, ASP.NET, 콘솔 등 어디서든 사용될 수 있어.

라이브러리는 호출자의 스레드 모델에 의존하면 안 돼. 그래서 라이브러리의 비동기 메서드 내부에서는 보통 ConfigureAwait(false)를 사용해:

public async Task<string> LoadDataFromUrlAsync(string url)
{
    using var client = new HttpClient();
    string content = await client.GetStringAsync(url).ConfigureAwait(false);
    return content;
}

이제 이 메서드는 특정 SynchronizationContext에서 실행될 것을 "요구"하지 않아. 더 안전하고 성능상 유리해(스레드 전환이 적어짐).

예: await에 ConfigureAwait를 안 썼을 때

WPF 앱을 예로 들자:

private async void Button_Click(object sender, RoutedEventArgs e)
{
    Button1.Content = "로딩...";
    await Task.Delay(2000);  // 긴 작업 흉내
    Button1.Content = "완료!";
}

Task.Delay는 내부적으로 "await"를 한다. 기본적으로 await 이후 제어는 UI 스레드로 돌아와서 UI를 계속 업데이트할 수 있게 해줘.

만약 긴 작업 내부에서 ConfigureAwait(false)를 사용하면:

await Task.Delay(2000).ConfigureAwait(false);
Button1.Content = "완료!";  // 오류!

다음 예외가 날 수 있어: InvalidOperationException: "The calling thread cannot access this object because a different thread owns it."
계속되는 부분이 다른(스레드풀) 스레드에서 실행되기 때문에 UI에 접근하면 안 되거든.

요약: UI나 컨텍스트에 접근해야 한다면 ConfigureAwait(false)를 남용하지 마.

6. 유용한 팁들

ConfigureAwait를 어디서 언제 써야 할까

SynchronizationContext가 있는지 어떻게 확인하나?

코드에서 바로 확인할 수 있어:

Console.WriteLine(SynchronizationContext.Current == null
    ? "컨텍스트 없음"
    : "컨텍스트 존재");

• 콘솔 앱과 ASP.NET Core에서는 "컨텍스트 없음"이 찍힐 거야.
• WinForms/WPF에서는 "컨텍스트 존재"가 찍혀.

스레드 전환 시각화

sequenceDiagram
    participant MainThread as 메인 스레드 (UI/콘솔)
    participant ThreadPool as 스레드풀에서 온 스레드

    MainThread->>SomeAsyncMethod: 메서드 호출
    SomeAsyncMethod->>MainThread: await 없이 복귀(resume) 시 같은 스레드로
    Note right of MainThread: await 후 같은 스레드로 돌아감
    SomeAsyncMethod->>ThreadPool: await + ConfigureAwait(false)
    Note right of ThreadPool: await 후 아무 스레드에서나 동작 가능

간단한 사용 규칙

• UI 코드에서 비동기 메서드를 동기로 기다리려고 .Result나 .Wait()를 쓰지 마.
• 라이브러리 코드에서는 모든 await에 대해 ConfigureAwait(false)를 엄격히 사용해라.
• UI 앱에서는 UI를 건드리지 않는 내부 메서드에서만 ConfigureAwait(false)를 써라.
• 가능하면 동기와 비동기를 섞지 마.
• async를 sync에서 호출해야 할 때는 다시 생각해봐: 전체 체인을 async로 만드는 게 안 되나?

7. 비동기 작업을 시작하는 초보자들이 흔히 하는 실수

실수 #1: 곳곳에 .Result나 .Wait()를 남발한다.
많은 개발자가 비동기 관련 글을 읽고 나서, 비동기 호출을 동기적으로 맞추려 .Result나 .Wait()를 여기저기 붙여버려. 처음에는 편해 보이지만, 실제로는 UI에서 deadlock을 보장하는 지름길이야. 특히 비동기 내부에서 ConfigureAwait(false)를 안 쓰면 UI 스레드가 막혀서 continuation을 실행할 수 없게 돼.

실수 #2: ConfigureAwait(false)를 잘못/과하게 쓴다.
초보들은 UI와 상호작용하는 코드에서도 ConfigureAwait(false)를 남발하곤 해. 그럼 UI 컨트롤 접근 시 InvalidOperationException 같은 오류가 나, 왜냐하면 continuation이 UI 스레드가 아닌 다른 스레드에서 실행되기 때문이지.

실수 #3: ConfigureAwait가 awaitable에만 동작한다는 걸 잊는다.
많은 사람이 ConfigureAwait(false)를 아무 메서드에나 쓸 수 있다고 생각하는데, 실제로는 Task, Task<T>, ValueTask 같은 awaitable 타입에만 동작해. 동기 메서드에는 아무 효과가 없고, 동기 호출이 비동기로 바뀌지 않아.

실수 #4: 불필요하게 동기/비동기를 섞는다.
동기 코드에서 비동기 메서드를 아무 전략 없이 호출(.Result, .Wait(), Task.Run 등)하면 미묘한 버그, 성능 저하, 진단하기 어려운 deadlock으로 이어져. 메서드가 짧아 보여도 체인 어딘가에서 문제가 될 수 있어.

실수 #5: SynchronizationContext의 영향을 과소평가한다.
초보들은 await 이후 continuation이 같은 스레드(UI)에서 실행될 수 있다는 사실을 잊곤 해. ConfigureAwait(false)를 적절히 쓰지 않으면 UI와 라이브러리 코드가 얽히면서 예측 불가능한 동작이 발생할 수 있어.