함수형 유틸리티 라이브러리 사용

함수형 방식으로 코드를 쓰다 보면 같은 모양의 도구가 반복해서 필요해집니다. 함수를 이어 붙이는 조합, 배열을 바꾸고 거르고 하나로 모으는 연산, 인수 일부를 정해 두는 부분 적용, 계산 결과를 저장해 두는 메모이제이션입니다. Ramda나 Lodash/fp 같은 라이브러리가 이런 도구를 모아 제공하지만, 작게 직접 만들어 보면 각 도구가 무엇을 받고 돌려주는지와 흔히 빠지는 함정을 알 수 있습니다.

이 글은 각 도구를 타입을 지키는 작은 함수로 구현하고, 마지막에 라이브러리를 들일지 판단하는 기준을 정리합니다. 아래 그림은 이 도구들이 하나의 데이터 변환 흐름에서 어떻게 이어지는지를 보여 주는 확장된 설계입니다.

그림에서 readonly 사용자 배열은 활성 사용자만 남기는 타입 가드로 걸러지고, 화면에 필요한 값만 담은 View로 바뀐 뒤, 빈 Map을 초기값으로 받은 reduce에서 ID별로 모입니다. 로그나 저장 같은 효과는 이 계산이 끝난 뒤에 따로 실행합니다. 이 글의 예제는 이 흐름의 각 연산을 따로 보여 주며, 그림의 사용자 파이프라인 전체를 그대로 구현한 것은 아닙니다.

함수 조합

함수 조합(function composition)은 한 함수의 출력을 다음 함수의 입력으로 넘겨, 여러 함수를 하나의 함수로 잇는 기법입니다. 수학의 f(g(x))처럼 오른쪽 함수부터 적용하는 순서로 적는 것을 compose, 데이터가 흐르는 순서대로 왼쪽부터 적는 것을 pipe라고 부릅니다. 먼저 조합할 작은 함수들을 준비합니다.

const toUpperCase = (str: string): string => str.toUpperCase();
const addExclamation = (str: string): string => str + "!";
const splitBySpace = (str: string): string[] => str.split(" ");
const joinWithDash = (arr: string[]): string => arr.join("-");
const truncate = (length: number) => (str: string): string =>
  str.length > length ? str.substring(0, length) + "..." : str;

여러 함수를 한 번에 받는 pipe를 만들 때 흔히 쓰는 모양은 다음과 같습니다. 처음 인수 목록을 배열로 받아 첫 함수에 펼쳐 넘기려고, 중간 결과가 배열이면 펼치도록 만든 구현입니다.

function naivePipe(...fns: Function[]) {
  return (...args: any[]) =>
    fns.reduce((res, fn) => (Array.isArray(res) ? fn(...res) : fn(res)), args);
}

naivePipe(toUpperCase, addExclamation, splitBySpace, joinWithDash)("hello functional programming");

TypeError: arr.join is not a function

이 구현에는 두 가지 문제가 있습니다. 첫째, 처음 인수 목록과 중간 결과의 배열을 구분하지 못해서, splitBySpace가 돌려준 배열이 joinWithDash에 펼쳐져 들어갑니다. 그러면 arr에는 첫 원소인 문자열 "HELLO"만 들어가고, 문자열에는 join이 없어 실행 중 오류가 납니다. 둘째, 함수들을 Function과 any로 받기 때문에 앞 함수의 출력과 뒤 함수의 입력이 맞는지 타입스크립트가 검사하지 못하며, 오버로드를 덧붙여도 선언한 개수와 다른 호출은 지원되지 않습니다.

함수 하나가 값 하나를 받는다고 정하면, 중간 값이 배열이든 아니든 그대로 넘기면 되고 단계마다 타입을 이을 수 있습니다.

function pipe2<A, B, C>(f: (value: A) => B, g: (value: B) => C): (value: A) => C {
  return (value) => g(f(value));
}

function pipe4<A, B, C, D, E>(
  f: (value: A) => B,
  g: (value: B) => C,
  h: (value: C) => D,
  k: (value: D) => E,
): (value: A) => E {
  return (value) => k(h(g(f(value))));
}

function compose4<A, B, C, D, E>(
  k: (value: D) => E,
  h: (value: C) => D,
  g: (value: B) => C,
  f: (value: A) => B,
): (value: A) => E {
  return pipe4(f, g, h, k);
}

const shout = pipe4(toUpperCase, addExclamation, splitBySpace, joinWithDash);
const shoutComposed = compose4(joinWithDash, splitBySpace, addExclamation, toUpperCase);

console.log(shout("hello functional programming"));
console.log(shoutComposed("hello functional programming"));
console.log(pipe2(toUpperCase, truncate(10))("super long string example"));

HELLO-FUNCTIONAL-PROGRAMMING!
HELLO-FUNCTIONAL-PROGRAMMING!
SUPER LONG...

pipe4에서 타입 매개변수는 string, string, string, string[], string으로 추론되어, splitBySpace가 만든 배열이 값 하나로 joinWithDash에 넘어갑니다. 함수의 순서를 잘못 적어 앞 함수의 출력이 뒤 함수의 입력과 맞지 않으면 호출하는 자리에서 진단됩니다. pipe2의 두 번째 인수로 넘긴 truncate(10)은 2편에서 본 커링을 쓴 예로, 길이를 정해 둔 (str: string) => string 함수입니다.

이 구현은 함수 개수마다 따로 선언해야 한다는 한계가 있습니다. 라이브러리는 여러 개수의 오버로드를 미리 선언해 두는 방식으로 이를 해결하며, compose보다 데이터의 흐름을 따라 읽기 쉬운 pipe를 더 자주 씁니다.

매핑 및 필터링

map과 filter는 배열 메서드로 이미 익숙하지만, 원래 배열을 그대로 두고 새 배열을 만든다는 점에서 함수형 연산의 기본입니다. map은 모든 요소를 바꾸고, filter는 조건을 만족하는 요소만 남깁니다.

interface Product {
  id: number;
  name: string;
  price: number;
  category: string;
}

const products: readonly Product[] = [
  { id: 1, name: "Laptop", price: 1200, category: "Electronics" },
  { id: 2, name: "Keyboard", price: 75, category: "Electronics" },
  { id: 3, name: "Book", price: 20, category: "Books" },
  { id: 4, name: "Mouse", price: 30, category: "Electronics" },
  { id: 5, name: "Pen", price: 5, category: "Stationery" },
];

const productNames = products.map((product) => product.name);
const electronics = products.filter((product) => product.category === "Electronics");
const expensiveElectronicsNames = products
  .filter((product) => product.category === "Electronics")
  .filter((product) => product.price > 50)
  .map((product) => product.name);

console.log(productNames.join(","));
console.log(electronics.map((product) => product.name).join(","));
console.log(expensiveElectronicsNames.join(","));
console.log(electronics[0] === products[0]);

Laptop,Keyboard,Book,Mouse,Pen
Laptop,Keyboard,Mouse
Laptop,Keyboard
true

products는 그대로 다섯 개이고, 각 연산은 새 배열을 돌려줍니다. 다만 filter가 만든 새 배열 안의 객체는 원래 배열의 객체와 같은 참조이므로, 결과의 객체를 고치면 원래 데이터도 바뀝니다. 또 map과 filter가 새 배열을 만든다고 해서 콜백 안의 부수 효과까지 막아 주지는 않으므로, 콜백도 순수하게 유지합니다.

filter에 타입 가드를 넘기면 결과의 타입도 좁혀집니다. TypeScript 5.5부터는 value !== undefined처럼 단순한 조건의 화살표 함수에서 타입 가드를 스스로 추론합니다.

const discounts: (number | undefined)[] = [10, undefined, 5];
const knownDiscounts = discounts.filter((discount) => discount !== undefined);
console.log(knownDiscounts.join(","));

10,5

knownDiscounts의 타입은 (number | undefined)[]가 아니라 number[]입니다. 콜백이 discount is number라는 타입 술어를 가진 함수로 추론되어, filter의 타입 가드 오버로드가 선택되기 때문입니다. 직접 (discount): discount is number => ...처럼 적을 때는 선언한 조건과 실제로 검사하는 조건이 같은지 사람이 확인해야 하며, 컴파일러는 그 일치를 검사하지 않습니다.

리듀싱

reduce는 배열의 요소를 차례로 돌며 누산기(accumulator)에 모아, 배열 전체를 하나의 값으로 줄이는 연산입니다. 다른 언어에서는 fold라고도 부르며, 콜백과 함께 누산기의 초기값을 받습니다.

const numbers = [1, 2, 3, 4, 5];
const total = numbers.reduce((acc, current) => acc + current, 0);
const multiplied = numbers.reduce((acc, current) => acc * current, 1);

interface User {
  id: number;
  name: string;
}

const users: readonly User[] = [
  { id: 1, name: "Alice" },
  { id: 2, name: "Bob" },
  { id: 3, name: "Charlie" },
];

const usersById = users.reduce((map, user) => map.set(user.id, user), new Map<number, User>());

console.log(total, multiplied);
console.log(usersById.size, usersById.get(2)?.name);

15 120
3 Bob

합은 0에서, 곱은 1에서 시작하므로 각각 15와 120입니다. 사용자 예제는 초기값으로 빈 Map<number, User>를 주어 누산기의 타입을 정하고, 각 사용자를 ID를 키로 넣습니다. Map의 set은 그 Map을 돌려주므로 콜백이 바로 누산기를 돌려줄 수 있고, 같은 ID가 다시 나오면 앞의 값을 덮습니다.

이 콜백은 누산기를 직접 바꾸지만, 그 Map은 이 reduce를 위해 방금 만든 지역 값이어서 바깥의 누구도 바뀌는 중간 상태를 보지 않습니다. 매번 new Map(map).set(...)으로 복사하면 요소가 n개일 때 복사 비용이 n의 제곱에 비례해 늘어나므로, 입력 배열과 바깥 상태만 바꾸지 않으면 됩니다. 또 초기값을 생략하면 빈 배열에서 TypeError가 나므로, 빈 입력도 정상적인 결과를 내도록 초기값을 주는 편이 좋습니다.

부분 적용과 인수의 순서

고차 함수와 커링에서 본 것처럼, 커링된 함수에 앞 인수를 넘기면 그 인수를 정해 둔 새 함수가 만들어집니다. 이때 어떤 인수가 앞에 오는지에 따라 만들 수 있는 함수가 달라집니다.

const divide = (a: number) => (b: number) => a / b;
const tenDividedBy = divide(10);
console.log(tenDividedBy(2), tenDividedBy(5));

const half = divide(2);
console.log(half(6));

const divideBy = (divisor: number) => (value: number) => value / divisor;
const realHalf = divideBy(2);
console.log(realHalf(6));

5 2
0.3333333333333333
3

divide(2)는 나눠지는 수인 a를 2로 정하므로, half(6)은 6의 절반이 아니라 2 / 6입니다. 나누는 수를 정해 두고 싶다면 divideBy처럼 정해 둘 인수를 앞에, 처리할 데이터를 마지막에 받도록 순서를 바꿔야 합니다. Ramda가 함수를 자동으로 커링하면서 데이터를 마지막 인수로 받는 것도 이 때문이며, 순서를 바꿀 수 없는 함수에는 R.__ 같은 자리 표시자로 건너뛸 인수를 표시합니다.

메모이제이션

메모이제이션은 함수의 결과를 인수별로 저장해 두었다가, 같은 인수로 다시 부르면 계산하지 않고 저장한 결과를 돌려주는 기법입니다. 같은 인수에 언제나 같은 결과를 내는 순수 함수에만 안전하며, 캐시 키(cache key)는 결과에 영향을 주는 모든 입력을 구별해야 합니다.

간단히 만들면 if (cache[key])로 저장 여부를 검사하기 쉬운데, 이 방식은 결과가 0이나 빈 문자열 같은 falsy 값이면 저장해 두고도 없는 것으로 보고 다시 계산합니다. 다음 구현은 Map의 has로 키의 존재를 검사합니다.

function memoize<A extends readonly unknown[], R>(fn: (...args: A) => R): (...args: A) => R {
  const cache = new Map<string, R>();
  return (...args) => {
    const key = JSON.stringify(args);
    if (cache.has(key)) {
      return cache.get(key) as R;
    }
    const result = fn(...args);
    cache.set(key, result);
    return result;
  };
}

let calls = 0;
const fibonacci: (n: number) => number = memoize((n: number): number => {
  calls++;
  return n <= 1 ? n : fibonacci(n - 1) + fibonacci(n - 2);
});

console.log(fibonacci(10), calls);
console.log(fibonacci(10), calls);
console.log(fibonacci(15), calls);

55 11
55 11
610 16

fibonacci(10)은 0부터 10까지의 값을 한 번씩 계산하므로 실제 계산은 11번입니다. 같은 호출을 다시 하면 저장한 결과를 돌려주므로 횟수가 늘지 않고, fibonacci(15)는 11부터 15까지의 다섯 값만 새로 계산해 16번이 됩니다. 재귀 호출이 메모이제이션된 fibonacci를 거치므로 중간 결과도 모두 저장됩니다. 자기 초기화 식 안에서 자기를 부르므로, 이렇게 변수의 타입이나 콜백의 반환 타입을 직접 적어 두어야 타입 추론이 순환하지 않습니다.

cache.get은 R | undefined를 돌려주므로, has로 확인한 뒤 as R로 단언합니다. 이 캐시에도 한계가 있습니다. JSON.stringify는 [undefined]와 [null]을 똑같이 "[null]"로 바꾸고 함수나 Map 같은 값을 제대로 구별하지 못하며, 저장한 결과는 지우지 않으므로 오래 쓰는 캐시라면 저장할 개수나 기간을 제한해야 합니다.

더 깊이: 객체를 키로 삼는 캐시와 WeakMap

인수가 객체 하나인 함수라면, 객체를 문자열로 바꾸지 않고 그 객체 자체를 캐시의 키로 쓸 수 있습니다. 이때 Map 대신 WeakMap을 쓰면 캐시가 키를 붙잡아 두지 않습니다. MDN의 WeakMap 설명에 따르면 WeakMap은 키에 대한 강한 참조를 만들지 않으므로, 어떤 객체가 키로 들어 있다는 사실만으로 그 객체가 가비지 컬렉션(garbage collection)에서 살아남지는 않습니다. 키로는 객체와 등록되지 않은 심벌만 쓸 수 있고, 키가 언제 사라질지는 가비지 컬렉터에 달려 있으므로 키의 목록을 꺼내거나 개수를 세는 방법도 없습니다.

MDN은 이 방식의 한계도 함께 적습니다. 입력이 객체일 때만 쓸 수 있고, 같은 객체가 다시 들어오지 않더라도 그 객체가 살아 있는 동안에는 결과가 캐시에 계속 남습니다. 객체가 같은 내용을 담았더라도 다른 객체라면 다른 키이므로, 이 캐시는 앞 절의 JSON.stringify 키와 달리 내용이 아니라 참조로 결과를 찾습니다. 그래서 불변 갱신으로 새 객체를 만들 때마다 캐시를 다시 계산하게 되는데, 바뀌지 않은 객체는 같은 참조로 남는 불변 갱신의 성질 덕분에 바뀐 부분만 다시 계산된다는 장점도 됩니다.

라이브러리를 들일지 판단하기

함수형 라이브러리는 이런 유틸리티를 더 많이, 더 다듬어진 형태로 제공하지만, 의존성을 하나 더하는 일이기도 합니다. 들이기 전에 실제 프로젝트에서 무엇을 얻고 무엇을 치르는지 비교합니다.

그림의 순서대로, 먼저 내장 배열 메서드와 작은 지역 함수로 충분한지 확인합니다. 라이브러리가 필요하다면 데이터를 어느 인수로 받는지, 자동 커링을 하는지 같은 호출 방식을 읽고, 설치할 버전의 타입 선언이 strict 설정에서 제대로 추론되는지 확인합니다. 그다음 실제 가져오기 방식과 번들러 설정에서 결과물의 크기가 얼마나 늘어나는지, 그 버전이 계속 유지되는지, 팀이 그 스타일의 코드를 읽고 고칠 수 있는지를 봅니다. 그림은 판단의 순서를 정리한 것이며, 이 글에서 라이브러리의 번들 크기나 성능을 측정한 것은 아닙니다.

정리

• 함수 조합은 한 함수의 출력을 다음 함수의 입력으로 넘기며, 값 하나를 받는 함수끼리 이으면 단계마다 타입을 검사할 수 있습니다.
• map과 filter는 새 배열을 만들지만 안의 객체는 함께 쓰이며, 타입 가드를 넘긴 filter는 결과 타입을 좁힙니다.
• reduce는 초기값으로 누산기의 타입과 빈 입력의 결과를 정하고, 그 안에서 만든 지역 누산기는 바꾸어도 바깥에 영향이 없습니다.
• 커링된 함수의 인수 순서는 부분 적용으로 만들 수 있는 함수를 정하므로, 정해 둘 인수를 앞에, 데이터를 마지막에 둡니다.
• 메모이제이션은 순수 함수에만 쓰고, 키의 존재는 has로 검사하며, 캐시 키가 입력을 제대로 구별하는지 확인합니다.
• 라이브러리는 내장 기능으로 충분한지 확인한 뒤, 호출 방식, 타입, 번들 크기, 유지보수를 실제 프로젝트에서 비교해 들입니다.

연습 문제

1. 공백이 두 개인 문자열

shout("hi ts")처럼 공백이 두 개 연속인 문자열을 넣으면 무엇이 출력되나요? splitBySpace가 만드는 배열과 함께 설명하세요.

2. falsy 결과의 캐시

같은 인수에 언제나 0을 돌려주는 함수를 if (cache[key])로 저장 여부를 검사하는 간단한 메모이제이션으로 감싸고, 같은 인수로 세 번 불렀습니다. 실제 계산은 몇 번 일어나나요? 이 글의 memoize로 감싸면 어떻게 되나요?

3. 4로 나누는 함수

divide와 divideBy로 각각 4를 정해 둔 함수를 만들어 10을 넘기면 결과는 무엇인가요? 어느 쪽이 10을 4로 나눈 값인가요?

이것으로 12장의 함수형 프로그래밍을 마칩니다. 다음 장의 React 컴포넌트와 타입스크립트 통합에서는 React의 함수 컴포넌트에 props와 state, 이벤트의 타입을 붙여, 컴포넌트를 잘못 쓰는 코드를 컴파일 단계에서 찾는 방법을 다룹니다.