비동기 방식의 어려운 점들

비동기 프로그래밍은 사용자 경험을 향상시키지만, 코드의 실행 흐름이 순차적이지 않아 몇 가지 어려움이 따른다.

1. 콜백 지옥

• 문제점: 비동기 작업을 연달아 처리해야 할 때, 콜백 함수 안에 또 다른 콜백 함수를 중첩해서 사용하게 됨
  • 코드가 깊어지고 옆으로 길어져 수정 및 유지보수가 매우 어려워짐

step1(function (value1) {
  step2(value1, function (value2) {
    step3(value2, function (value3) {
      step4(value3, function (value4) {
        // value4를 사용하는 로직...
        // 코드가 너무 깊어져 이해하기 어렵다.
      });
    });
  });
});

2. 비선형적인 실행 흐름

• 문제점: 코드가 위에서 아래로 순서대로 실행되지 않고, 언제 끝날지 모르는 비동기 작업의 완료 시점에 따라 실행 흐름이 결정됨
  • 이로 인해 코드의 동작을 예측하고 논리적 흐름을 파악하기 어려움
• 예시: 사용자의 프로필 정보와 게시글 목록을 동시에 가져오는 경우, 어느 것이 먼저 도착할지 보장할 수 없어 두 데이터가 모두 필요한 로직을 처리하기 까다로울 수 있음

3. 에러 처리의 복잡성

• 문제점: 일반적인 try...catch 문은 동기 코드에서는 잘 동작하지만, 콜백 기반의 비동기 코드에서는 에러를 잡아내지 못한다.

  • 비동기 작업 내부에서 발생한 에러는 해당 작업의 콜백 함수 내에서 별도로 처리해야 한다.
  • 에러 처리가 분산되고 누락되기 쉽다.

• 해결법: Promise의 .catch()나 async/await과 try...catch를 사용

디버깅을 쉽게 하는 방법들

Node.js의 기준입니다.

1. async/await & try...catch

• +) 비동기 코드를 동기 코드처럼 만들어 논리 흐름 파악이 쉽다

• +) 동기 코드처럼 Breakpoint를 설정하고 한 줄씩 실행하며 디버깅하기 매우 편함

• -) 코드 패턴일 뿐, 디버깅 도구는 아님

• -) await 키워드를 빠뜨리는 등의 실수를 하면 예기치 않게 동작할 수 있음

2. 브라우저 개발자 도구

• +) Breakpoint를 걸어 코드 실행을 멈추고 단계별로 실행(Step Over, Step Into)할 수 있음

• +) Call Stack 패널에서 비동기 작업의 시작점(e.g. setTimeout을 호출한 곳)까지 추적해줘 문제의 근원을 찾기 쉬움

• +) API 요청 상태나 Promise 객체의 현재 상태를 직접 확인

• -) 모든 기능을 효과적으로 쓰려면 러닝 커브가 커짐

• -) Breakpoint를 설정하고 코드를 다시 실행하는 과정이 필요

3. Node.js Inspector

• +) 서버 사이드 디버깅이 가능함

• +) Chrome 개발자 도구와 연동하여 디버깅 가능

• -) --inspect 플래그를 붙여 서버를 실행하고, 개발자 도구에 연결하는 과정이 필요