Threads Beat Async/Await
[요즘 IT] 비동기/대기보다 스레드가 유리한 이유

이 글은 async/await를 활용한 비동기 프로그래밍의 한계를 논하며, 스레드 기반 접근이 더 유리한 경우를 강조한다. async/await의 추상화가 역압(backpressure) 처리와 시스템 설계에서 복잡성을 증가시킨다는 점을 지적한다. Bob Nystrom, Ron Pressler, Nathaniel Smith 등의 논의를 바탕으로 구조적 동시성의 중요성을 강조하고, 암묵적 가정이 프로그램 흐름을 방해할 수 있음을 사례로 설명한다. 스레드는
더 직관적이고 신뢰성 있는 대안을 제공할 수 있음을 주장한다.

첫 번째로, 비동기 프로그래밍은 단순해 보이지만, 복잡한 시스템에서는 역압(backpressure) 처리와 같은 문제가 발생하며, 이는 관리하기 어렵다.

두 번째로, 구조적 동시성(structured concurrency)의 중요성을 고려했을 때, 프로그램의 흐름이 암묵적인 가정들로 인해 깨질 수 있다.

세 번째로, 스레드 기반 접근이 비동기보다 더 직관적이며, 개발자가 설계한 논리를 보존하기 쉽다.

What I've Learned:

명령형 프로그래밍과 함수형 프로그래밍의 특징 및 차이점

1. 명령형 프로그래밍

   • 특징: 코드가 실행되는 순서와 상태 변화를 중점으로 다룸. 변수, 반복문, 조건문 등으로 명확하게 프로세스를 제어.
   • 예: C, Java 등.
   • 장점: 직관적이고 명령 흐름을 쉽게 이해 가능.
   • 단점: 상태 관리가 복잡하며, 병렬 처리에 취약.

2. 함수형 프로그래밍

   • 특징: 상태와 부작용을 최소화하고, 함수를 중심으로 불변성과 데이터 변환 강조.
   • 예: Haskell, Scala 등.
   • 장점: 코드의 가독성과 재사용성, 병렬 처리에 유리.
   • 단점: 명령형에 익숙한 개발자에게 진입 장벽이 높음.

글과의 연관성

비동기 프로그래밍은 함수형의 특성을 일부 포함하며, 명령형 흐름과는 설계 철학이 다르다. async/await는 명령형처럼 보이지만 상태와 흐름 관리가 암묵적으로 작동해 복잡성을 유발한다.

백프레셔

백프레셔(Backpressure)는 프로듀서-컨슈머 패턴에서 프로듀서가 데이터를 너무 빨리 생성할 때, 컨슈머가 이를 처리하지 못해 생기는 문제를 말한다. 이는 데이터 처리의 병목현상을 유발하고, 시스템 성능 저하나 메모리 부족으로 이어질 수 있다.

주로 비동기 프로그래밍이나 스트리밍 시스템에서 발생하며, 이를 해결하기 위해 컨슈머가 처리 속도를 조절하거나 데이터를 일시적으로 저장하는 메커니즘이 필요하다. 예를 들어, async/await와 같은 비동기 환경에서는 백프레셔 처리 메커니즘이 없으면 시스템 안정성을 저해할 수 있다.

비교: async/await vs GCD

1. async/await

• 장점:
  • 코드 가독성이 높음: 비동기 작업이 동기 코드처럼 읽힘.
  • 에러 처리 통합: try, catch와 자연스럽게 연동.
  • 유지보수가 용이: 복잡한 작업도 간단히 표현 가능.
• 단점:
  • 낮은 유연성: 세부적인 작업 스케줄링 조정이 어렵다.
  • 특정 상황에서 적합하지 않음(예: 동시성 제어가 중요한 경우).

2. GCD

• 장점:
  • 더 세부적인 제어 가능: 작업 우선순위와 동시성 수준 조정 가능.
  • 성능 최적화: 특정 큐를 사용하여 CPU 활용 극대화.
• 단점:
  • 코드가 복잡해질 수 있음: 중첩 클로저와 콜백 지옥 가능성.
  • 디버깅이 어렵고 가독성 저하.