이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 I/O 집약적인 외부 API 호출이 많은 서비스를 만들다가 비동기 서버 프레임워크를 처음 도입했습니다. 동기 방식일 때 요청마다 스레드가 블로킹되면서 동시 요청이 늘어나자 응답 시간이 크게 나빠졌습니다. FastAPI와 파이썬의 asyncio를 결합해 여러 외부 호출을 동시에 발사하고 모두 완료되면 응답을 조합하는 방식으로 바꿨더니, 외부 API 세 곳을 순차 호출하던 2.4초가 0.9초로 줄었습니다.
비동기 코드에서 가장 주의할 점은 CPU 바운드 작업을 async 함수 안에 넣으면 이벤트 루프 전체가 멈춘다는 것이었는데, 이 함정을 한 번 겪은 뒤 작업 성격을 I/O와 CPU 바운드로 먼저 분류하는 습관이 생겼습니다. 지금도 비동기 코드를 설계할 때 블로킹 경로를 먼저 찾는 것부터 시작합니다.
비동기 코드에서 에러가 어디서 왔는지 추적하기 어려웠던 경험이 있습니다. 동기 코드에서는 스택 트레이스가 명확했는데, async 함수에서 발생한 에러는 스택이 잘려 있어서 원인 파악이 어려웠습니다.
팀 선배에게 이 문제를 설명했더니 asyncio 디버그 모드를 활성화하면 더 자세한 정보가 나온다는 것과, 비동기 에러를 잡을 때 try/except 위치가 중요하다는 것을 알려줬습니다. 태스크가 수행 중 실패해도 메인 루프가 종료되지 않으면 에러가 묻힐 수 있다는 것도 그때 처음 알았습니다.
이 조언을 받고 나서 비동기 코드를 작성할 때 에러 처리 위치를 명시적으로 설계하는 습관이 생겼습니다. 비동기 프레임워크는 동기 코드와 에러 전파 방식이 다르기 때문에, 이 부분을 이해하는 데 경험 있는 사람의 도움이 큰 차이를 만들었습니다.
비동기 코드에서 CPU 바운드 작업을 async 함수 안에 넣었다가 이벤트 루프 전체가 멈추는 문제를 겪은 경험이 있습니다. 비동기 함수 안에 있어서 비동기로 실행되는 것이 아니라 이벤트 루프를 블로킹한다는 것을 이해하고 나서야 문제가 보였습니다.
이 경험 이후 비동기 코드 리뷰를 할 때 확인하는 체크리스트를 만들었습니다. CPU 바운드 작업이 async 함수 안에 들어가 있지 않은지, 에러 처리가 명시적으로 작성되어 있는지 두 가지를 기본으로 확인하는 방식입니다.
팀원이 같은 실수를 겪지 않도록 이 체크리스트를 공유하면서, 비동기 프레임워크 도입 시 확인할 것들을 문서화하는 단계가 생겼습니다. 기술적으로 해결한 것보다 그 과정에서 배운 것을 절차로 남겨서 다음에도 쓸 수 있게 하는 것이 더 오래가는 결이라는 생각이 남아 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.