메서드 체이닝의 득과실

처음 .filter().map().reduce()로 이어지는 코드를 봤을 때, 이렇게 쓸 수 있다는 게 신기했습니다. 중간 변수도 없이 데이터가 한 줄로 흘러가는 모습이 직관적으로 느껴졌기 때문입니다.

메서드 체이닝이란 무엇인가요?링크를 제목에 복사

객체지향 프로그래밍(OOP)에서 메서드의 반환값을 다시 메서드 호출의 대상으로 삼아 여러 메서드를 연속으로 이어 쓰는 패턴을 메서드 체이닝(Method Chaining)이라고 합니다.

// jQuery 메서드 체이닝 예시
$("#p1").css("color", "red").slideUp(2000).slideDown(2000);

jQuery로 DOM을 조작해본 분이라면 위와 같은 코드가 익숙하실 겁니다. 그 외에도 Promise, Array.prototype 메서드, 빌더 패턴 등에서 메서드 체이닝을 찾아볼 수 있습니다.

메서드 체이닝의 어떤 점이 좋은가요?링크를 제목에 복사

체이닝을 쓰면 임시 변수 없이 작업의 흐름을 선형으로 읽을 수 있습니다.

// 체이닝 없이 중간 변수가 쌓입니다
const filtered = numbers.filter((n) => n > 2);
const doubled = filtered.map((n) => n * 2);
const result = doubled.reduce((acc, n) => acc + n, 0);
 
// 체이닝 흐름이 한눈에 읽힙니다
const result = numbers
  .filter((n) => n > 2)
  .map((n) => n * 2)
  .reduce((acc, n) => acc + n, 0);

작업의 논리적 순서가 코드의 위 → 아래 순서와 일치하기 때문에 읽는 부담이 줄어듭니다. 중간 결과를 임시 변수에 담는 과정이 생략되어 코드가 간결해지는 효과도 있습니다.

그렇다면 어떤 문제가 생길 수 있나요?링크를 제목에 복사

디버깅이 어려워집니다

체인이 길어지면 어느 단계에서 문제가 생겼는지 특정하기 어렵습니다. 아래 코드에서 결과가 예상과 다를 때 어디가 문제인지 바로 알 수 있을까요?

const result = users
  .filter((u) => u.active)
  .map((u) => u.orders)
  .flat()
  .filter((o) => o.amount > 1000)
  .reduce((acc, o) => acc + o.amount, 0);

중간 단계를 변수로 분리하면 각 단계의 값을 콘솔로 찍어보거나 중단점을 걸기 쉬워집니다.

const activeUsers = users.filter((u) => u.active);
const allOrders = activeUsers.map((u) => u.orders).flat();
const largeOrders = allOrders.filter((o) => o.amount > 1000);
const total = largeOrders.reduce((acc, o) => acc + o.amount, 0);

에러 처리가 까다롭습니다

체인 중간에서 null이나 undefined가 반환되면 이후 메서드 호출이 줄줄이 터집니다.

// getUser()가 null을 반환하면 그 다음 줄에서 TypeError
getUser()
  .getOrders()
  .filter((o) => o.active)
  .map((o) => o.amount);

에러가 발생한 위치와 스택 트레이스가 가리키는 줄 번호가 달라 원인을 파악하기 어렵습니다.

유연한 변경이 어렵습니다

하나의 체인으로 묶인 코드는 응집도는 높지만, 중간에 조건을 추가하거나 순서를 바꾸는 변경이 까다롭습니다. 체인 중간에 if 분기 하나를 끼워 넣으려면 결국 체인을 분리해야 합니다.

정리하면링크를 제목에 복사

메서드 체이닝은 데이터를 순차적으로 필터링하고 변환하는 로직에서 강점을 발휘합니다. 그래서 Array.prototype 메서드나 Promise 체인처럼 단계가 명확하고 에러 가능성이 낮은 맥락에서는 적극적으로 활용할 수 있습니다.

다만, 체인이 길어지거나 중간에 에러 처리 혹은 조건 분기가 필요한 로직이 섞인다면 명시적인 변수 분리를 고려하는 것이 좋습니다. 결국 가독성과 디버깅 용이성 사이의 균형이 관건입니다.