🔄 파이썬의 비동기: 코루틴에서 시스템콜까지

본 글은 Python의 코루틴, Future, 이벤트 루프, system call 같은 비동기 프로그래밍의 개념과 구조를 이야기합니다. async, await, asyncio.run() 등을 한두 번 사용해 본 경험이 있는 독자를 대상으로 합니다.

비동기란?

"비동기는 어떤 작업을 요청하고 끝날 때까지 기다리지 않고 다른 일을 하는 방식"을 의미합니다. 이를 통해 동시성을 처리할 수 있으며 꼭 병렬성이 아니어도 됩니다. 보통 함수의 실행을 중단(suspend)하고 나중에 다시 재개(resume)할 수 있는 특수한 함수인 코루틴으로 이것을 구현하고는 합니다.

코루틴이란?

일반적으로 코루틴은 '함수의 실행을 중단(suspend)하고 나중에 다시 재개(resume)할 수 있는 특수한 함수'를 의미합니다. 즉 일반 함수는 return되면 끝이지만, 코루틴은 중간에 멈췄다가 나중에 다시 실행할 수 있습니다.

asyncio와 await이 도입되기 전 파이썬은 제너레이터로 코루틴을 구현 하고는 했습니다. 아래는 아주 간단한 예시 코드입니다.

def my_coroutine():
 print("Start")
 x = yield "Paused at yield"
 print(f"Resumed with x = {x}")

# 사용
coro = my_coroutine()
print(next(coro))        # "Start" → "Paused at yield"를 반환함... 다른 로직
print(coro.send(42))     # "Resumed with x = 42" send로 x에 42를 주입(?)

next(coro)는 실행을 시작하고 첫 yield에서 중단합니다. 이후 다른 로직을 실행하다 send(42)를 통해 코루틴에 값을 보내고 재개합니다.

위 예시처럼 yield 기반 코루틴은 중단과 재개가 가능하지만, 여러 개의 코루틴을 동시에 실행해야 한다면 문제가 복잡해집니다. 어떤 코루틴이 완료되었는지 확인하고, 중간에 예외가 발생했다면 이를 어떻게 처리할지 결정해야 하며, 각 코루틴을 어느 시점에 재개할지까지 모든 흐름을 개발자가 직접 제어해야 합니다.

이러한 로직을 수동으로 작성하려면 상태 관리, 에러 핸들링, 실행 순서 조정 등을 모두 고려해야 하며, 코루틴 개수가 많아질수록 유지보수도 어려워집니다. 생각만 해도 번거롭고 복잡하죠. 그래서 등장한 것이 바로 여러 코루틴의 실행과 중단, 완료 상태를 자동으로 관리해 주는 ‘이벤트 루프(event loop)’입니다.

파이썬에서는 이 개념을 표준 라이브러리 수준에서 제공하며, 그 구현체가 바로 asyncio입니다.

asyncio, Future, Task

asyncio는 어떻게 작업의 완료 여부, 중단 시점, 재개할 타이밍 등을 모두 관리할까요? 여기서 Future와 Task 객체가 등장합니다.

# https://github.com/python/cpython/blob/main/Lib/asyncio/futures.py
class Future:
 """
 Represents the result of an asynchronous computation.
 This class is *almost* compatible with concurrent.futures.Future.
 """

Future 객체는 완료되었을 수도 있고 아닐 수도 있는 지연된 계산을 표현하는 데 사용되는 객체입니다. Future는 주로 asyncio가 내부적으로 사용하는 객체로, 우리가 직접 생성하거나 관리할 필요는 없습니다. 이는 asyncio가 어떤 작업이 언제 완료될지를 알고 있고, 그 흐름을 스스로 관리하기 때문입니다. Future 객체는 .result() 나 .add_done_callback() 같은 메서드를 통해 작업의 완료 여부를 확인하고 결과나 예외를 받아올 수 있도록 도와줍니다. 즉 지연된 작업을 캡슐화하는 객체라고 할 수 있습니다.

그렇다면 Future를 여러 개 생성해서 큐에 담아 관리하면 코루틴들을 관리할 수 있지 않을까요?

실제로 asyncio는 그런 방식으로 코루틴을 관리합니다. 예를 들어 asyncio.as_completed()는 내부적으로 큐와 Future 객체(정확히는 코루틴 실행에 특화된 Future을 상속받은 Task 객체)를 사용하여 코루틴을 관리하는 것을 확인할 수 있습니다.

def as_completed(fs, *, timeout=None):
 """Return an iterator whose values are coroutines.

 When waiting for the yielded coroutines you'll get the results (or
 exceptions!) of the original Futures (or coroutines), in the order
 in which and as soon as they complete.

 This differs from PEP 3148; the proper way to use this is:

 for f in as_completed(fs):
 result = await f  # The 'await' may raise.
 # Use result.

 If a timeout is specified, the 'await' will raise
 TimeoutError when the timeout occurs before all Futures are done.

 Note: The futures 'f' are not necessarily members of fs.
 """
 if futures.isfuture(fs) or coroutines.iscoroutine(fs):
 raise TypeError(f"expect an iterable of futures, not {type(fs).__name__}")

 from .queues import Queue  # Import here to avoid circular import problem.
 done = Queue()

 loop = events._get_event_loop()
 todo = {ensure_future(f, loop=loop) for f in set(fs)}
 timeout_handle = None

 def _on_timeout():
 for f in todo:
 f.remove_done_callback(_on_completion)
 done.put_nowait(None)  # Queue a dummy value for _wait_for_one().
 todo.clear()  # Can't do todo.remove(f) in the loop.

 def _on_completion(f):
 if not todo:
 return  # _on_timeout() was here first.
 todo.remove(f)
 done.put_nowait(f)
 if not todo and timeout_handle is not None:
 timeout_handle.cancel()

 async def _wait_for_one():
 f = await done.get()
 if f is None:
 # Dummy value from _on_timeout().
 raise exceptions.TimeoutError
 return f.result()  # May raise f.exception().

 for f in todo:
 f.add_done_callback(_on_completion)
 if todo and timeout is not None:
 timeout_handle = loop.call_later(timeout, _on_timeout)
 for _ in range(len(todo)):
 yield _wait_for_one()

asyncio는 내부적으로 Future와 Task를 기반으로 코루틴을 스케줄링하고 결과를 추적하는 기능을 제공하므로, 별도의 구현 없이도 편하게 사용할 수 있습니다 :)

비동기 네트워크 I/O

그런데 함수를 중단하고 다시 실행하는 게 뭐가 좋을까요?

네트워크 I/O를 예로 들어봅시다. CPU는 일반적으로 1ns~10ns 단위로 연산을 수행하지만, 네트워크 왕복 시간은 보통 수 ms 단위로, 무려 수십만 배나 느립니다.
예를 들어 http.get() 같은 blocking 호출은 응답이 도착할 때까지 해당 쓰레드가 아무 일도 하지 못한 채 대기 상태로 머무르게 되며, 그 시간 동안 CPU 자원은 사실상 낭비됩니다.

이 작업을 비동기 방식으로 처리하면 어떨까요?
I/O 요청 이후 코루틴의 실행을 일시 중단(suspend)하고, 그사이에 다른 작업을 먼저 수행한 뒤, 응답이 도착하면 재개(resume)하도록 구성하면, CPU는 대기 시간 동안에도 유용한 작업을 계속 수행할 수 있게 됩니다.

시스템콜과 DMA

그렇다면 이런 중단과 재개가 어떻게 가능할까요?

운영체제 수업에서 배운 내용을 떠올려 보면, 바로 DMA 개념이 생각납니다.
네트워크 데이터를 송수신할 때는 일반적으로 NIC가 DMA를 통해 직접 메모리에 접근합니다. 이 과정에는 CPU의 개입이 거의 필요 없습니다.
NIC는 전송이 끝나면 인터럽트(interrupt)를 통해 CPU에 알리고, 이후 CPU는 해당 데이터를 처리하면 됩니다.
즉, CPU는 네트워크 I/O가 완료될 때까지 기다릴 필요 없이 다른 작업을 수행할 수 있게 됩니다.

epoll과 시스템 콜의 역할

그렇다면 CPU는 어떻게 "데이터가 도착했다"는 사실을 알게 될까요?
이때 등장하는 것이 바로 OS의 시스템 콜입니다.
운영체제는 select, poll, epoll 같은 시스템 콜을 통해 열어둔 소켓이나 파일 디스크립터에 데이터가 도착했는지를 감시할 수 있게 해줍니다. 이 시스템 콜들을 통해 "읽을 준비가 된 소켓"을 알 수 있습니다.

select, poll, epoll 등이 어떻게 작동하는지 궁금하다면, 각 시스템 콜에 대한 man 페이지나 관련 문서를 참고해 보는 것을 추천합니다.

asyncio와 Selector

Python의 asyncio도 해당 시스템 콜을 사용하고 있습니다. 물론 이 시스템 콜을 직접 호출하지 않고, 내부적으로 Selector 객체를 통해 추상화하여 사용합니다.

# https://github.com/python/cpython/blob/2d037fb406fd8662862c5da40a23033690235f1d/Lib/asyncio/unix_events.py#L57
class _UnixSelectorEventLoop(selector_events.BaseSelectorEventLoop):
 """Unix event loop.

 Adds signal handling and UNIX Domain Socket support to SelectorEventLoop.
 """

CPython/Lib/selectors.py를 보면 다음과 같이 현재 플랫폼에서 가장 효율적인 시스템 콜을 선택합니다.

# https://github.com/python/cpython/blob/2d037fb406fd8662862c5da40a23033690235f1d/Lib/selectors.py#L609
# Choose the best implementation, roughly:#    epoll|kqueue|devpoll > poll > select.
# select() also can't accept a FD > FD_SETSIZE (usually around 1024)
if _can_use('kqueue'):
 DefaultSelector = KqueueSelector
elif _can_use('epoll'):
 DefaultSelector = EpollSelector
elif _can_use('devpoll'):
 DefaultSelector = DevpollSelector
elif _can_use('poll'):
 DefaultSelector = PollSelector
else:
 DefaultSelector = SelectSelector

실제 비교해 보기

이제 동기와 비동기 방식의 네트워크 I/O의 속도 차이를 직접 비교해 봅시다.
아래는 간단한 HTTPS GET 요청의 예시입니다.

import asyncio, ssl
import socket


async def fetch_https_async(host: str):
 # 비동기 코드
 ssl_context = ssl.create_default_context()
 # 1. 비동기적으로 TCP 연결 + SSL 핸드셰이크까지 완료되기를 기다림
 reader, writer = await asyncio.open_connection(host, 443, ssl=ssl_context)
 request_header = (
 f"GET / HTTP/1.1\r\n" f"Host: {host}\r\n" f"Connection: close\r\n\r\n"
 )
 writer.write(request_header.encode("utf-8"))
 # 2. write 버퍼가 비워질 때까지 대기 (소켓이 writable 상태가 될 때까지)
 await writer.drain() # 어째서 함수 이름이 drain.. ㅠ 파이이썬 참..	# 3. 서버 응답이 도착할 때까지 대기 (readable 상태를 기다림)
 response_data = await reader.read()
 response_data.decode("utf-8", errors="ignore")
 writer.close()
 # 4. 연결이 완전히 종료되기를 기다림
 await writer.wait_closed()


def fetch_https_sync(host: str):
 # 동기 코드
 ssl_context = ssl.create_default_context()

 sock = socket.create_connection((host, 443))
 ssock = ssl_context.wrap_socket(sock, server_hostname=host)
 request = f"GET / HTTP/1.1\r\n" f"Host: {host}\r\n" f"Connection: close\r\n\r\n"
 ssock.sendall(request.encode("utf-8"))

 response = b""
 while True:
 chunk = ssock.recv(4096)
 if not chunk:
 break
 response += chunk
 response.decode("utf-8", errors="ignore")
 ssock.close()
 sock.close()


import time

urls = [
 "example.com",
 "www.python.org",
 "www.google.com",
 "www.wikipedia.org",
 "www.naver.com",
 "www.daum.net",
 "www.reddit.com",
]


def sync_get():
 print("=== SYNC 테스트 시작 ===")
 start = time.time()
 for host in urls:
 fetch_https_sync(host)
 elapsed = time.time() - start
 print(f"동기 총소요 시간: {elapsed:.2f}초\n")


async def async_get():
 print("=== ASYNC 테스트 시작 ===")
 start = time.time()
 tasks = [fetch_https_async(host) for host in urls]
 results = await asyncio.gather(*tasks)
 elapsed = time.time() - start
 print(f"비동기 총소요 시간: {elapsed:.2f}초\n")


if __name__ == "__main__":
 sync_get()
 asyncio.run(async_get())

''''
필자의 컴퓨터 환경

=== SYNC 테스트 시작 ===
동기 총소요 시간: 2.81초

=== ASYNC 테스트 시작 ===
비동기 총소요 시간: 0.88초
'''

확실히 비동기 방식이 더 빠릅니다.
동기 방식은 요청을 순차적으로 하나씩 처리해야 하므로, 각 요청이 완료될 때까지 무조건 기다려야 하죠.
반면 비동기 방식에서는 await 키워드를 만날 때마다 현재 실행을 일시 중단(suspend)하고, 제어권을 이벤트 루프에 넘깁니다.
이벤트 루프는 그동안 다른 준비된 코루틴을 실행하고, 이전 코루틴이 다시 실행 가능한 상태가 되면 재개(resume)시킵니다.
이런 구조 덕분에 I/O처럼 느린 작업을 기다리는 동안 CPU는 다른 유용한 작업을 처리할 수 있게 됩니다.

결론

왜 비동기 네트워크 처리처럼 보이는 open_connection()이 별도 네트워크 모듈로 빠지지 않고,
asyncio 안에 그대로 포함되어 있는지,
또 왜 익숙한 flush()가 아닌 drain()이라는 이름이 쓰였는지 정말 파이썬다운 알쏭달쏭한 의문과 함께, 비동기 프로그래밍의 개념과 동작 방식을 간단히 짚어보았습니다.

다음 글에서는 asyncio를 활용한 실전 비동기 패턴과 주의할 점들, 혹은 GIL이 존재하는 파이썬 환경에서 비동기와 멀티 프로세싱의 차이 또는 비동기를 정말 잘 쓸 수 있는 현실적인 사례 그리고 uvloop 톺아보기 중 하나를 살펴보려 합니다.

긴 글 읽어주셔서 감사합니다.

출처

전문가를 위한 파이썬 2판
외국 블로그
외국 블로그