asyncio는 대기 시간이 긴 작업을 겹쳐서 처리할 때 강력하다. 특히 HTTP 호출, DB 드라이버, 메시지 큐처럼 CPU보다 I/O 대기가 많은 백엔드 작업에서 요청 처리량을 높이는 데 유용하다.
\n실무에서는 “빠른 코드”라기보다, 같은 시간에 더 많은 대기 작업을 처리하는 방식으로 이해하면 가장 정확하다.
asyncio의 핵심은 async def, await, 그리고 이벤트 루프다. await는 시간이 걸리는 작업이 끝날 때까지 스레드를 붙잡지 않고 다른 코루틴에 실행 기회를 넘긴다.
import asyncio\nimport time\n\nasync def fetch(name: str, delay: int) -> str:\n print(f\"{name} 시작\")\n await asyncio.sleep(delay)\n print(f\"{name} 완료\")\n return f\"{name} 결과\"\n\nasync def main():\n start = time.perf_counter()\n\n results = await asyncio.gather(\n fetch(\"A\", 2),\n fetch(\"B\", 1),\n fetch(\"C\", 3),\n )\n\n elapsed = time.perf_counter() - start\n print(\"결과:\", results)\n print(f\"총 소요 시간: {elapsed:.2f}초\")\n\nif __name__ == \"__main__\":\n asyncio.run(main())실행해보면 2초 + 1초 + 3초가 아니라, 가장 오래 걸린 3초 정도만 걸린다.
\n이게 asyncio의 가장 중요한 포인트다. 순차 처리 대신 동시 대기를 만든다.
gather()는 여러 코루틴을 한 번에 실행하고 결과를 순서대로 모아준다. 백엔드에서 외부 API 여러 개를 병렬 호출할 때 자주 쓴다.
실무에서 흔한 패턴은 “여러 API를 동시에 호출하되, 실패를 안전하게 처리”하는 형태다. 아래 예시는 외부 서비스 호출을 흉내 낸 코드다.
\nimport asyncio\nimport random\n\nasync def call_api(user_id: int) -> dict:\n await asyncio.sleep(random.uniform(0.5, 1.5))\n\n if user_id == 3:\n raise RuntimeError(\"외부 API 오류\")\n\n return {\"user_id\": user_id, \"status\": \"ok\"}\n\nasync def safe_call(user_id: int) -> dict:\n try:\n result = await call_api(user_id)\n return {\"success\": True, \"data\": result}\n except Exception as e:\n return {\"success\": False, \"user_id\": user_id, \"error\": str(e)}\n\nasync def main():\n user_ids = [1, 2, 3, 4, 5]\n\n tasks = [safe_call(user_id) for user_id in user_ids]\n results = await asyncio.gather(*tasks)\n\n success_count = sum(1 for r in results if r[\"success\"])\n fail_count = len(results) - success_count\n\n print(\"처리 결과\")\n for r in results:\n print(r)\n\n print(f\"성공: {success_count}, 실패: {fail_count}\")\n\nif __name__ == \"__main__\":\n asyncio.run(main())현업에서는 gather()에 코루틴을 바로 넘기기도 하지만, 예외 전파 전략을 먼저 정하는 것이 중요하다.
\n한 작업의 실패가 전체 실패여야 하는지, 아니면 부분 성공을 허용할지에 따라 구현이 달라진다. 개인적으로 외부 API 집계 서비스에서는 safe_call()처럼 실패를 결과 객체로 바꾸는 패턴을 자주 사용했다.
동시성 제한도 자주 필요하다. 외부 API나 DB 커넥션은 무한정 동시에 호출하면 오히려 장애를 만든다.
\nimport asyncio\n\nsemaphore = asyncio.Semaphore(2)\n\nasync def limited_task(name: str, delay: int):\n async with semaphore:\n print(f\"{name} 시작\")\n await asyncio.sleep(delay)\n print(f\"{name} 완료\")\n\nasync def main():\n await asyncio.gather(\n limited_task(\"task-1\", 2),\n limited_task(\"task-2\", 2),\n limited_task(\"task-3\", 2),\n limited_task(\"task-4\", 2),\n )\n\nif __name__ == \"__main__\":\n asyncio.run(main())위 코드는 한 번에 2개씩만 실행된다. 실서비스에서 트래픽이 튀는 순간, 이런 제한 하나가 장애 예방에 꽤 큰 차이를 만든다.
\nasyncio는 이미지 처리, 압축, 복잡한 계산처럼 CPU를 오래 쓰는 작업에는 적합하지 않다. 그런 경우는 멀티프로세싱이나 작업 큐를 고려하는 편이 낫다.
time.sleep()를 쓰면 이벤트 루프가 멈춘다비동기 함수 안에서 time.sleep()를 쓰면 전체가 막힌다. 반드시 await asyncio.sleep()를 사용해야 한다.
함수에 async만 붙인다고 빨라지지 않는다. HTTP 클라이언트, DB 드라이버도 비동기 지원 라이브러리여야 한다. 예: aiohttp, httpx.AsyncClient, async DB 드라이버.
수천, 수만 개 코루틴을 한 번에 만들면 메모리 사용량과 외부 시스템 부하가 커진다. Semaphore나 배치 처리로 상한을 두는 게 안전하다.
gather()는 기본적으로 하나의 예외가 전체 흐름에 영향을 줄 수 있다. 운영 환경에서는 로깅, 타임아웃, 재시도 정책까지 같이 설계해야 한다.
asyncio는 I/O 대기 시간이 많은 작업에서 효율적이다.async def, await, asyncio.run(), asyncio.gather()다.time.sleep() 같은 동기 코드를 섞으면 비동기의 장점이 사라진다.다음 단계로는 asyncio.create_task(), asyncio.wait_for()를 이용한 타임아웃 처리, 그리고 aiohttp나 httpx로 실제 HTTP 비동기 클라이언트를 다뤄보면 좋다.
👿백엔드 개발 면접에는 가장 일반적인 답변을 원하는 기본적인 질문과 우리가 함께할 수 있도록 도움을 줄 수 있는 기타 질문들이 있다.
\n이 중에서 Java가 가장 많이 사용됩니다. Java는 객체 지향 프로그래밍 언어이며, 안정성과 확장성이 높아 대규모 애플리케이션에 적합합니다. 하지만 Kotlin 많이 이관하는 추세입니다.
\nREST API는 HTTP 프로토콜을 사용하고, SOAP는 XML을 사용합니다. 또한 REST API는 간결하고 가벼우며, SOAP는 보안이 강화되고 표준화된 인터페이스를 제공합니다.
\nREST API는 간단하고 확장성이 뛰어나며, 사용이 쉽지만, 복잡한 트랜잭션을 처리하는데는 한계가 있습니다. 반면 SOAP는 보안성과 안정성이 높으며, 대규모 시스템에서 사용하기 좋습니다.
\n마이크로서비스 아키텍처는 작고 독립적인 서비스들이 모여서 하나의 애플리케이션을 구성하는 아키텍처입니다.
\n아키텍처는 각각의 서비스가 서로 다른 기술 스택을 사용할 수 있어 개발자의 자유도가 높고, 서비스 간의 결합도가 낮아 유연성이 높습니다. 또한, 서비스가 분리되어 있어 단일 서비스의 장애가 전체 시스템에 영향을 미치지 않습니다.
\nNoSQL은 스키마가 없거나 유연한 스키마를 가지며, 확장성과 가용성이 높습니다. RDBMS는 정확한 스키마를 가지며, 안정성과 일관성이 높습니다.
\nNoSQL은 데이터의 유형이나 형식을 바꾸는 경우에도 비교적 자유롭지만, RDBMS는 변경에 대한 엄격한 검증 절차가 필요합니다.
\n인증은 제품이나 서비스의 기능이나 특성을 검증하는 과정이고, 인가는 권한을 부여하는 과정입니다.
\n예를 들어, 제품이 CE 인증을 받는다는 것은 제품이 EU 기준을 충족한다는 것을 의미합니다. 반면에, 인가는 예를 들어 시스템 관리자가 특정 서버에 접근한 권한을 부여하는 것입니다.
\n세션은 서버 측에서 데이터를 저장하고, 쿠키는 클라이언트 측에서 데이터를 저장합니다.
\n세션은 클라이언트가 서버에 접속할 때 생성되며, 서버에 의해 유지됩니다.
\n쿠키는 브라우저에 저장되며, 만료 기간이 설정되면 삭제됩니다.
\n세션은 중요한 데이터를 저장하기에 적합하고, 쿠키는 세션 ID나 사용자 기본 설정과 같은 정보를 저장하기에 적합합니다.
\nHTTP는 암호화되지 않은 텍스트 기반 프로토콜이고, HTTPS는 암호화된 데이터 전송을 제공하는 HTTP의 보안 버전입니다.
\nHTTPS는 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 데이터를 암호화하고 보호합니다.
\n서버리스 아키텍처는 개발자가 서버의 관리나 운영에 대한 부담을 줄이기 위해 고안된 아키텍처입니다.
\n서버리스 아키텍처에서는 서버가 필요하지 않으며, 함수를 실행하는 서비스가 제공됩니다. 이를 통해 개발자는 코드를 작성하고 배포하는 것에 집중할 수 있습니다.
\nMVC는 Model-View-Controller의 약자로, 애플리케이션의 구성 요소를 모델, 뷰, 컨트롤러로 나누어서 설계하는 패턴입니다.
\n모델은 데이터와 비즈니스 로직을 처리하고, 뷰는 사용자에게 정보를 보여주는 역할을 하며, 컨트롤러는 모델과 뷰 사이에서 조율하는 역할을 합니다.
\nORM은 Object-Relational Mapping의 약자로, 객체와 관계형 데이터베이스 간의 매핑을 자동화하는 프레임워크입니다.
\nORM을 사용하면 SQL 쿼리를 직접 작성하지 않아도 객체를 데이터베이스에 저장하거나 조회할 수 있습니다.
\nex) JPA (Hibernate)…
\nSQL 인젝션은 악의적인 사용자가 입력한 데이터를 이용하여 데이터베이스에 액세스하는 공격입니다.
\nSQL 인젝션을 방지하기 위해, 입력 데이터를 검증하고 이스케이프 문자열 처리를 해야 합니다. 또한, 프리페어드 스테이트먼트를 사용하여 SQL 쿼리를 작성하고, 권한을 최소화하는 등의 방법을 사용할 수 있습니다.
\n예, 저는 AWS를 사용해본 경험이 있습니다.
\nAWS는 클라우드 컴퓨팅 서비스를 제공하는 아마존의 플랫폼입니다. AWS를 사용하면 서버, 데이터베이스, 스토리지 등을 쉽게 구축하고 관리할 수 있습니다.
\n대용량 데이터 처리를 위해 저는 하둡, 스파크 등의 기술을 주로 사용합니다.
\n하둡은 대용량 데이터를 분산 저장하고 처리하는 데 사용되는 오픈소스 소프트웨어 프레임워크입니다.
\n스파크는 하둡과 유사한 기능을 제공하지만, 인메모리 처리와 스트림 처리 등의 추가 기능을 제공합니다.
\n도커는 컨테이너 기반 가상화 플랫폼으로, 애플리케이션을 컨테이너에 패키징하여 독립적으로 실행할 수 있습니다.
\n쿠버네티스는 컨테이너 오케스트레이션 툴로, 도커와 같은 컨테이너 기술을 사용하는 애플리케이션을 자동으로 배포, 확장, 관리할 수 있습니다.
\n쿠버네티스는 여러 대의 서버에 컨테이너를 분산 배치하여 고가용성, 확장성 등의 이점을 제공합니다.
\nVM은 전체 시스템을 가상화하는 반면 Docker 컨테이너는 개별 애플리케이션을 가상화합니다.
\nVM은 서로 다른 운영 체제 간에 완전한 격리를 제공하는 반면 Docker 컨테이너는 호스트 시스템의 운영 체제 커널을 공유하여 효율성과 속도를 높입니다.
\n간단하게 적어서 혼돈되는 내용 댓글로 달아주시면 자세하게 설명하겠습니다.
\n끝!
\n