APP DEVELOPMENT TERM
비동기 처리
기다리는 동안 할 수 있는 일과 결과 뒤에 할 일을 나누는 방식
비동기 처리는 시간이 걸리는 작업을 요청한 뒤, 그 결과가 필요한 처리는 완료 뒤로 이어가고 결과와 무관한 다른 일을 먼저 진행할 수 있게 하는 방식입니다.
30초 이해
사진을 보내는 동안에도 설명을 입력할 수 있다면
앱에서 사진을 첨부하고 전송을 시작했습니다. 사진이 서버로 전달되는 동안에도 설명을 입력할 수 있습니다. 전송이 끝날 때까지 화면의 모든 입력을 멈추지 않는 이런 흐름에서 비동기 처리를 볼 수 있습니다.
그렇다고 사진 전송을 시작하자마자 모든 작업을 끝내도 된다는 뜻은 아닙니다. 이 글의 글쓰기에서는 사진 저장 결과를 받은 뒤 글에 연결하므로, 설명은 먼저 입력해도 글 등록은 그 결과를 기다려야 합니다.
요청을 시작하는 시점, 작업이 끝나는 시점, 결과를 화면에 반영하는 시점을 나눠 보면 이해하기 쉽습니다. 기다리는 동안 가능한 행동과 완료 뒤에 이어갈 행동을 각각 정하는 것입니다.
한 장으로 이해
사진은 전송 중, 설명은 입력 중
기다리는 동안 가능한 일과 결과 뒤에 할 일을 나눕니다.
- 01
사진을 보내기 시작하면
전송 요청
사진 전송 작업서버로 보내기 시작앱 화면에서 하는 일설명 입력 시작설명오늘의 작업 공간을…
요청 시작은 완료가 아닙니다.
- 02
완료 응답을 기다리는 동안
다른 입력 계속
사진 전송 작업사진 전송 중앱 화면에서 하는 일설명 입력 가능설명오늘의 작업 공간을 소개합니다.
사진이 필요한 글 등록은 대기
- 03
사진 저장 결과를 받으면
다음 작업 연결
사진 전송 작업저장 완료 응답 확인앱 화면에서 하는 일사진 준비 완료작성한 설명 유지글 등록 가능사진 준비 뒤 글 등록을 이어갑니다.
완료와 실패를 나눠 보기
결과가 오면, 그다음 행동도 달라집니다
전송 중에는 기다림을 알리고, 결과에 맞춰 화면을 바꿉니다.
사진 저장 성공 응답
사진 준비 완료로 바꿉니다
작성한 설명은 그대로
글 등록 가능저장된 사진을 연결하는 작업을 이어갑니다.
전송 실패를 확인한 경우
입력을 남기고 다시 시도합니다
작성한 설명은 그대로
사진 다시 보내기그 사진을 사용하는 글 등록은 아직 보류합니다.
언제 사용하는 개념인가요?
사진·파일을 보내는 화면
전송 중 표시와 함께 제목·설명 입력을 이어가게 할 때 사용합니다. 전송한 파일이 필요한 등록은 결과 확인 뒤에 진행합니다.
서버에서 목록을 읽는 화면
조회 결과를 기다리는 동안 로딩 상태를 보여주고, 결과가 도착하면 목록이나 실패 안내를 반영할 때 사용합니다.
검색 조건을 바꾸는 화면
검색 응답을 기다리며 다른 조건을 입력할 수 있게 할 때 사용합니다. 늦게 온 이전 검색 결과를 최신 결과로 덮어쓰지 않도록 구분합니다.
왜 중요한가요?
요청 시작을 완료로 오해하지 않게 합니다
전송 버튼을 누른 상태와 서버가 확인한 완료 상태는 다릅니다. 진행 중·완료·실패 안내를 나누면 사용자가 지금 무엇을 할 수 있는지 알 수 있습니다.
결과가 필요한 순서는 지킵니다
사진 저장 결과가 있어야 글에 사진을 연결할 수 있습니다. 독립적인 입력은 계속 받더라도, 그 결과에 기대는 처리는 준비된 뒤 이어가야 합니다.
나중에 오는 결과도 현재 화면에 맞춥니다
응답이 올 때 사용자가 내용을 바꾸거나 다른 화면으로 이동했을 수 있습니다. 어떤 요청의 결과인지 확인하고, 현재 작업에 해당하는 결과만 반영합니다.
사진 첨부 글쓰기 예시
설명 입력은 계속하고, 글 등록은 사진 준비 뒤에 합니다
사진 한 장과 설명을 함께 올리는 글쓰기입니다. 사진 저장 결과를 글에 연결하는 방식이라면, 사진 전송과 글 등록은 같은 완료 상태가 아닙니다.
결과를 기다릴 일을 나누면
- 사진 전송을 시작하고 화면에는 전송 중이라고 표시합니다.
- 사용자는 전송 결과와 무관한 설명을 계속 입력합니다.
- 서버가 사진 저장을 확인하면 준비 완료로 바꾸고, 해당 사진을 사용하는 글 등록을 이어갑니다.
시작을 곧바로 완료로 처리하면
- 사진을 보내기 시작한 것만으로 사진 준비가 끝났다고 표시할 수 있습니다.
- 사진을 연결할 정보가 오기 전에 글 등록을 시도할 수 있습니다.
- 뒤늦게 전송이 실패하면 화면의 완료 안내와 실제 저장 상태가 맞지 않을 수 있습니다.
비동기 처리의 핵심은 무엇이든 동시에 끝내는 것이 아닙니다. 먼저 진행할 수 있는 일과 결과가 있어야 가능한 일을 나누고, 완료·실패 뒤의 행동을 연결하는 것입니다.
자주 묻는 질문
“동기 처리와는 무엇이 다른가요?”
동기 방식의 호출에서는 호출한 쪽이 그 처리가 끝나 값을 돌려줄 때까지 다음으로 넘어가지 않습니다. 비동기 방식은 결과를 나중에 받아 이어갈 수 있게 합니다. 두 방식 모두 먼저 나온 결과가 필요한 일은 순서를 지켜야 합니다.
“비동기이면 여러 작업이 실제로 동시에 실행되나요?”
항상 그렇지는 않습니다. 비동기는 결과를 기다리고 이어가는 방식을 말하고, 병렬 실행은 여러 작업을 실제로 동시에 수행하는 방식입니다. JavaScript에서 async를 붙이는 것만으로 무거운 계산이 다른 실행 공간으로 옮겨지지는 않습니다.
“await를 쓰면 앱 화면도 모두 멈추나요?”
JavaScript의 await는 해당 비동기 함수의 다음 처리를 결과가 준비될 때까지 기다리게 합니다. 기다리는 동안 다른 화면 이벤트를 처리할 수 있습니다. 다만 오래 걸리는 계산으로 화면을 담당하는 처리 흐름을 계속 차지하면 앱이 멈춘 것처럼 보일 수 있습니다.
“서버의 백그라운드 작업과 같은 말인가요?”
같은 뜻은 아닙니다. 앱이 서버 응답을 비동기로 기다리는 것과, 서버가 긴 작업을 별도 실행 흐름에 맡기는 것은 다른 구분입니다. 보고서 생성을 별도 작업으로 처리하는 방식은 비동기를 활용하는 한 사례이며, 모든 비동기 처리에 작업 큐가 필요한 것은 아닙니다.
“비동기로 요청했다면 성공으로 봐도 되나요?”
아닙니다. 완료·실패 결과와 서비스가 정한 성공 조건을 확인해야 합니다. 연결이 끊겨 응답을 받지 못했다면 서버 저장도 실패했다고 단정하지 않고, 결과를 다시 확인하는 기준을 정합니다.
우리 서비스에 적용할 때 확인하세요
- 1기다리는 동안 사용자가 계속할 수 있는 행동과 잠시 막아야 할 행동은 무엇인가요?
- 2어떤 결과가 있어야 다음 작업을 시작할 수 있나요?
- 3전송 중·완료·실패를 구분하고, 실패해도 작성한 내용을 유지하나요?
- 4응답이 늦거나 순서가 달라져도 현재 요청의 결과만 화면에 반영하나요?
공식 참고
서비스 기준은 공식 문서에서 다시 확인하세요
다음 자료
이해한 내용을 바로 적용해보세요
비동기 처리가 기다림을 나누는 개념이라면, 실제 앱 구현에서는 요청·저장·조회 결과를 연결해야 합니다. 사진 첨부와 보고서 처리 가이드에서 각각의 동작을 이어 볼 수 있습니다.
앱에서 기다림이 생기는 장면 하나를 골라보세요
사진 전송이나 검색처럼 결과가 늦게 오는 장면에서 계속할 행동·기다릴 행동·실패 뒤 행동을 적으면 개발팀과 화면의 동작 기준을 맞출 수 있습니다.