2025년 6월 04일·6분
함수형 프로그래밍 개념이 현대 코드로 되돌아오는 이유
불변성, 순수 함수, map/filter 같은 함수형 아이디어가 인기 언어들에 계속 등장하는 이유와 이들이 어떻게 도움이 되는지, 언제 사용하는지 알아보세요.
불변성, 순수 함수, map/filter 같은 함수형 아이디어가 인기 언어들에 계속 등장하는 이유와 이들이 어떻게 도움이 되는지, 언제 사용하는지 알아보세요.
“함수형 프로그래밍 개념”은 계산을 끊임없이 변하는 것으로 다루기보다 값으로 다루는 습관과 언어 기능입니다.
“이걸 해라, 저걸 바꿔라”라고 명령형으로 쓰는 대신, 함수형 스타일 코드는 “입력을 받아 출력을 반환하라”에 가깝습니다. 함수가 신뢰할 수 있는 변환처럼 동작할수록 프로그램이 무엇을 할지 예측하기 쉬워집니다.
사람들이 Java, Python, JavaScript, C#, Kotlin이 “더 함수형적이 되고 있다”고 할 때, 그 말은 이 언어들이 완전히 순수 함수형 언어로 바뀌고 있다는 뜻이 아닙니다.
주류 언어 설계는 람다와 고차 함수 같은 유용한 아이디어를 차용해, 필요할 때 함수형 스타일로 일부 코드를 작성할 수 있게 하고, 더 명확할 때는 익숙한 명령형이나 객체지향 방식을 그대로 쓰게 해줍니다.
함수형 아이디어는 숨겨진 상태를 줄이고 동작을 추론하기 쉽게 만들어 소프트웨어 유지보수성을 향상시키는 경우가 많습니다. 또한 공유 변경 가능한 상태는 경쟁 조건의 주된 원인이라서 동시성 측면에서도 도움이 됩니다.
하지만 단점도 있습니다: 과도한 추상화는 낯설게 느껴질 수 있고, 불변성은 특정 경우 오버헤드를 추가할 수 있으며, ‘영리한’ 조합은 과하면 가독성을 해칠 수 있습니다.
이 글에서 "함수형 개념"은 다음을 의미합니다:
이들은 교리가 아니라 실용 도구입니다—목표는 코드를 더 단순하고 안전하게 만드는 곳에서 사용하는 것입니다.
함수형 프로그래밍은 새로운 유행이 아닙니다. 시스템 규모가 커지고 팀이 커지며 하드웨어 환경이 바뀔 때마다 반복해서 떠오르는 아이디어 집합입니다.
1950–60년대에는 Lisp 같은 언어가 함수를 값으로 취급하며 고차 함수의 기초를 마련했고, 람다 표기법의 뿌리도 이 시기에 생겼습니다.
1970–80년대에는 ML, 이후 Haskell 같은 함수형 언어들이 불변성과 강한 타입 기반 설계를 밀어붙였지만 주로 학계나 일부 산업에서 사용됐습니다. 반면 주류 언어들은 필요한 부분을 조용히 빌려가며 발전했습니다.
2000–2010년대에 접어들면서 함수형 아이디어는 무시할 수 없게 되었습니다:
최근에는 Kotlin, Swift, Rust 같은 언어들이 함수 기반 컬렉션 도구와 안전한 기본값을 강조하고, 다양한 프레임워크가 파이프라인과 선언적 변환을 장려합니다.
문맥이 바뀌기 때문입니다. 프로그램이 작고 단일 스레드였을 때는 "그냥 변수를 변경하자"가 괜찮았지만, 시스템이 분산되고 동시성이 필요하며 여러 사람이 유지보수할 때 숨겨진 결합의 비용이 커졌습니다.
람다, 컬렉션 파이프라인, 명시적 비동기 흐름 같은 함수형 패턴은 의존성을 명확히 하고 동작을 예측 가능하게 만듭니다. 언어 설계자들이 이들을 계속 도입하는 건 이론적 유물 때문이 아니라 현대 복잡성에 실용적인 도구이기 때문입니다.
예측 가능한 코드는 같은 상황에서 항상 같은 방식으로 동작합니다. 함수가 숨겨진 상태나 현재 시간, 전역 설정, 이전의 어떤 일에 의존하면 이 예측 가능성이 사라집니다.
예측 가능성이 있으면 디버깅은 탐정 놀이가 아니라 검사에 가깝습니다: 문제를 작은 부분으로 좁히고 재현해 수정할 수 있습니다.
대부분의 디버깅 시간은 코드를 고치는 데 쓰이는 것이 아니라 "코드가 실제로 무엇을 했나"를 알아내는 데 쓰입니다. 함수형 아이디어는 국소적으로 추론할 수 있는 동작으로 밀어줍니다:
그 결과 "화요일에만 깨진다" 같은 버그가 줄고, 여기저기 흩어진 출력문도 줄며, 고친 것이 다른 화면의 새 버그를 만들 가능성도 적어집니다.
순수 함수는 단위 테스트 친화적입니다. 복잡한 환경을 세팅하거나 애플리케이션의 절반을 목(mock)으로 대체할 필요가 없습니다. 리팩터링 중에도 호출 위치에 대한 가정이 적어 재사용하기 좋습니다.
실무적 이점:
이전: calculateTotal()이 전역 discountRate를 읽고 전역 "holiday mode" 플래그를 확인하며 전역 lastTotal을 업데이트한다. 총계가 "가끔 틀리다"는 버그 리포트가 온다—이제 상태를 쫓아야 합니다.
이후: calculateTotal(items, discountRate, isHoliday)는 숫자를 반환하고 아무 것도 변경하지 않는다. 총계가 틀리면 입력을 기록하고 즉시 재현할 수 있습니다.
예측 가능성은 함수형 기능이 주류 언어에 계속 추가되는 주요 이유 중 하나입니다: 일상적인 유지보수를 덜 놀랍게 만들어 소프트웨어 비용을 낮춥니다.
부수 효과는 값 계산과 반환 이외의 모든 행위입니다. 함수가 입력 외부의 무언가(파일, DB, 현재 시간, 전역 변수, 네트워크)를 읽거나 변경하면 부수 효과가 발생합니다.
일상적 예시: 로그 출력, 주문 저장, 이메일 전송, 캐시 갱신, 환경 변수 읽기, 난수 생성 등. 이들 자체가 나쁜 건 아니지만 프로그램 주변 세계를 바꾸므로 놀라움이 시작됩니다.
효과가 일반 로직에 섞이면 동작은 더 이상 "데이터 in → 데이터 out"이 아닙니다. 같은 입력이더라도 숨겨진 상태(이미 DB에 있는 것, 어떤 사용자가 로그인했는지, 기능 플래그 여부, 네트워크 실패 등)에 따라 다른 결과를 낼 수 있습니다. 그 결과 버그 재현이 어렵고 수정 신뢰도가 떨어집니다.
디버깅도 복잡해집니다. 함수가 할인 계산을 하면서 DB에 쓰기까지 한다면 조사 중에 그 함수를 두 번 호출할 수 없습니다—두 번 호출하면 레코드가 두 개 만들어질 수 있습니다.
함수형은 단순한 분리를 권합니다:
이 분리로 대부분의 코드를 DB 없이 테스트할 수 있고, 세상의 절반을 목(mock)으로 대체할 필요도, 간단한 계산이 쓰기를 트리거할까 걱정할 필요도 없습니다.
가장 흔한 실패 모드는 “effect creep(효과 확산)”입니다: 한 함수가 "조금 로그만" 찍다가 설정을 읽고 메트릭을 쓰고 서비스도 호출하게 되는 식으로 점점 많은 것에 의존하게 됩니다. 곧 코드베이스의 많은 부분이 숨겨진 동작에 의존하게 됩니다.
좋은 규칙: 핵심 함수는 지루하게 유지하라—입력을 받고 출력을 반환하라—그리고 부수 효과는 명시적이고 찾기 쉬운 위치에 두어라.
불변성은 간단한 규칙이지만 큰 결과를 낳습니다: 값을 변경하지 말고 새 버전을 만들어라.
객체를 제자리에서 수정하는 대신 업데이트를 반영한 새 복사본을 만듭니다. 이전 버전은 그대로 남아 있기 때문에 그 값은 나중에 예기치 않게 바뀌지 않습니다.
많은 버그는 공유 상태에서 옵니다—같은 데이터가 여러 곳에서 참조될 때 한 부분이 변경하면 다른 곳이 반영되지 않은 중간 상태를 보거나 예상치 않게 변합니다.
불변성에서는:
특히 데이터가 널리 전달되거나 동시에 사용될 때 유용합니다.
불변성은 공짜가 아닙니다. 잘못 구현하면 메모리, 성능, 불필요한 복사의 비용을 지불할 수 있습니다—예: 빈번히 큰 배열을 클론하는 경우.
현대 언어와 라이브러리는 구조 공유(structural sharing) 같은 기법으로 비용을 줄이지만 신중하게 선택할 필요가 있습니다.
불변성을 선호하라:
제어된 변경을 고려할 때:
유용한 절충안은: 경계(컴포넌트 간)에서 데이터를 불변으로 다루고 구현 세부에서는 선택적으로 변경을 허용하는 것입니다.
큰 변화는 함수를 값으로 취급하는 것입니다. 즉 함수를 변수에 저장하고, 다른 함수에 전달하고, 함수에서 반환할 수 있다는 뜻입니다—데이터처럼 다룹니다.
이 유연성이 고차 함수를 실용적으로 만듭니다: 반복문 로직을 여러 번 쓰지 않고 루프를 한 번만 작성한 뒤, 원하는 동작은 콜백으로 주입하면 됩니다.
동작을 전달할 수 있으면 코드는 더 모듈화됩니다. 하나의 요소에 대해 무엇을 할지 설명하는 작은 함수를 정의하고, 그 함수를 모든 요소에 적용하는 방법을 아는 도구에 전달합니다.
const addTax = (price) => price * 1.2;
const pricesWithTax = prices.map(addTax);
여기서 addTax는 루프 안에서 직접 호출되지 않습니다. map에 전달되어 반복을 처리합니다.
[a, b, c] → [f(a), f(b), f(c)]predicate(item)이 참인 항목 유지const total = orders
.filter(o => o.status === "paid")
.map(o => o.amount)
.reduce((sum, amount) => sum + amount, 0);
이것은 파이프라인처럼 읽힙니다: 결제된 주문 선택 → 금액 추출 → 합산.
전통적 루프는 종종 반복, 분기, 비즈니스 규칙을 한곳에 섞습니다. 고차 함수는 이러한 관심사를 분리합니다. 반복과 누적은 표준화되고, 당신의 코드는 전달할 작은 함수들(규칙)에 집중합니다. 결과적으로 복사-붙여넣기한 루프와 변형이 줄어듭니다.
파이프라인은 좋지만 지나치게 중첩되거나 너무 영리해지면 읽기 어려워집니다. 이런 경우 고려하세요:
함수형 빌딩 블록은 의도가 분명할 때 가장 도움이 됩니다—단순한 논리를 퍼즐로 바꾸지 않을 때에만요.
현대 소프트웨어는 드물게 단일 스레드에서 조용히 실행되지 않습니다. 폰은 UI 렌더링, 네트워크, 백그라운드 작업을 동시에 관리하고, 서버는 수천 개의 요청을 처리하며, 심지어 개인용 기기와 클라우드 머신도 다중 코어를 기본으로 탑재합니다.
여러 스레드/태스크가 같은 데이터를 변경할 수 있으면 작은 타이밍 차이가 큰 문제를 만들어냅니다:
이 문제는 "나쁜 개발자" 때문이 아니라 공유 변경 가능한 상태의 자연스러운 결과입니다. 락은 도움되지만 복잡성을 추가하고 교착 상태(deadlock)를 만들며 성능 병목이 될 수 있습니다.
함수형 아이디어는 병렬 작업을 추론하기 쉽게 만듭니다.
데이터가 불변하면 여러 작업이 안전하게 공유할 수 있습니다. 함수가 순수하면(입력→출력, 숨겨진 부작용 없음) 병렬 실행, 결과 캐싱, 단위 테스트가 더 자신 있게 가능해집니다.
이 접근은 현대 앱의 일반적 패턴에 잘 맞습니다:
FP 기반 동시성 도구가 모든 워크로드에서 속도 향상을 보장하진 않습니다. 어떤 작업은 본질적으로 순차적이며, 추가 복사나 조정이 오버헤드를 낳을 수 있습니다.
주요 이점은 정확성입니다: 경쟁 조건이 줄고, 효과 경계가 명확해지며, 다중 코어나 실제 서버 부하에서 일관되게 동작하는 프로그램을 얻을 가능성이 커집니다.
많은 코드는 작은, 이름 붙은 단계들이 이어질 때 이해하기 쉽습니다. 이것이 조합(composition) 과 파이프라인의 핵심입니다: 각 함수가 한 가지 일만 하고, 그들을 연결해 데이터가 단계별로 흐르게 합니다.
파이프라인을 조립 라인처럼 생각하세요:
각 단계는 독립적으로 테스트하고 변경할 수 있으며, 전체 프로그램은 "이걸 가져오고, 저걸 하고, 저걸 한다"는 읽기 쉬운 이야기처럼 됩니다.
파이프라인은 명확한 입력과 출력을 가진 함수를 만들게 합니다. 그 결과:
조합은 단순히 "함수는 다른 함수로부터 만들어질 수 있다"는 생각입니다. 일부 언어는 compose 같은 헬퍼를 제공하고, 다른 언어는 체이닝이나 연산자를 사용합니다.
작은 파이프라인 스타일 예제: 주문 중 결제된 것만 골라 합계를 계산합니다.
const paid = o => o.status === 'paid';
const withTotal = o => ({ ...o, total: o.items.reduce((s, i) => s + i.price * i.qty, 0) });
const isLarge = o => o.total >= 100;
const revenue = orders
.filter(paid)
.map(withTotal)
.filter(isLarge)
.reduce((sum, o) => sum + o.total, 0);
자바스크립트를 잘 모른다 해도 이것은 보통 "결제된 주문 → 총액 추가 → 큰 것만 남김 → 합산"으로 읽을 수 있습니다. 큰 장점은 단계 배치가 코드의 의도를 설명한다는 점입니다.
많은 "미스터리 버그"는 영리한 알고리즘 문제가 아니라 잘못된 데이터를 다루는 방식에서 옵니다. 함수형 아이디어는 잘못된 값을 만들기 어렵게 데이터 모델을 설계하도록 밀어, API를 더 안전하고 동작을 더 예측 가능하게 만듭니다.
느슨한 구조(문자열, 딕셔너리, nullable 필드)를 전달하는 대신, 함수형식 모델링은 명확한 의미를 가진 타입을 권장합니다. 예: "EmailAddress"와 "UserId"를 구분하면 섞어 쓸 위험이 줄어듭니다. 검증은 시스템 경계에서 수행해 내부에선 이미 검증된 값을 받게 하세요.
결과적으로 함수는 호출자가 검사를 "잊어버릴" 수 없도록 하고, 방어적 코드를 줄이며 실패 모드를 명확히 합니다.
함수형 언어에서는 대수적 데이터 타입(ADTs) 를 사용해 값이 몇 가지 경우 중 하나임을 정의할 수 있습니다. 예: 결제 수단은 Card, BankTransfer, Cash 중 하나이며 각각 필요한 필드만 가집니다. 패턴 매칭은 각 경우를 구조적으로 처리하는 방식입니다.
여기서 원칙은: 잘못된 상태를 표현할 수 없게 하라. "Guest 사용자는 비밀번호가 없다"라면 password: string | null 대신 "Guest"라는 별도 케이스로 모델링하세요. 불가능한 상태는 표현할 수 없으므로 많은 엣지 케이스가 사라집니다.
완전한 ADT가 없어도 다음 도구를 사용해 비슷한 효과를 얻을 수 있습니다:
패턴 매칭과 결합하면 모든 경우를 처리했는지 보장하는 데 도움이 됩니다.
주류 언어가 함수형 기능을 채택하는 이유는 이념 때문이 아니라 개발자들이 실제로 같은 기법을 계속 찾고 있기 때문입니다—그리고 생태계가 그런 기법을 보상하기 때문입니다.
팀은 읽기 쉽고 테스트하기 쉬우며 예기치 않은 파급 효과 없이 변경 가능한 코드를 원합니다. 컬렉션 변환이나 연산 조합과 같은 작업이 우아하게 느껴지면 그 경험을 다른 생태계도 요구하게 됩니다.
언어 커뮤니티끼리도 경쟁이 있어서 한 쪽이 일상적 작업을 우아하게 만든다면 다른 쪽도 마찰을 줄이려 기능을 도입합니다.
많은 함수형 스타일 변화는 교과서보다는 라이브러리에서 시작됩니다:
인기 라이브러리가 보편화되면 개발자는 언어 차원에서 간결한 람다, 타입 추론, 패턴 매칭, 표준 헬퍼(map/filter/reduce)를 원하게 됩니다.
언어 기능은 보통 커뮤니티의 실험 후 등장합니다. 특정 패턴이 널리 쓰이면(예: 작은 함수를 주고받는 패턴) 언어는 그 패턴을 덜 시끄럽게 만드는 방향으로 진화합니다.
그래서 종종 한 번에 "모든 걸 함수형으로" 바꾸기보다 점진적 업그레이드가 보입니다: 먼저 람다, 그런 다음 더 나은 제네릭, 불변성 도구, 구성 유틸리티가 따라옵니다.
대부분 언어 설계자는 현실적인 코드베이스가 하이브리드일 것이라 가정합니다. 목표는 모든 것을 순수 함수형으로 강제하는 것이 아니라 팀이 도움되는 곳에 함수형 아이디어를 쓸 수 있게 하는 것입니다:
이 중도적 길이 함수형 기능이 계속 재등장하는 이유입니다: 많은 문제를 해결하면서도 기존 개발 방식 전체를 바꾸라고 요구하지 않습니다.
함수형 아이디어는 혼란을 줄일 때 가장 유용합니다. 이를 위해 전체 코드베이스를 새로 쓰거나 "모든 것을 순수하게" 강요할 필요는 없습니다.
즉각적인 이익이 큰 낮은 위험 영역부터 시작하세요:
AI 보조 워크플로우로 빠르게 개발할 때는 이러한 경계가 더 중요합니다. 예를 들어, 일부 플랫폼에서는 비즈니스 로직을 순수 함수/모듈에 두고 I/O를 얇은 에지 레이어에 격리하도록 요청할 수 있습니다. 이렇게 하면 불변성 도입이나 스트림 파이프라인 추가 같은 리팩터링을 전체 코드베이스를 건다는 위험 없이 단계적으로 시도할 수 있습니다.
함수형 기법이 잘못된 도구인 경우도 있습니다:
부수 효과 허용 위치, 순수 헬퍼 네이밍, "충분히 불변적"이라는 기준 같은 규약을 합의하세요. 코드 리뷰에서 명확성을 우선시하고, 밀도 높은 조합보다 설명적 이름과 직관적 파이프라인을 권장하세요.
배포 전에 물어보세요:
이렇게 사용하면 함수형 아이디어는 철학 수업이 아니라 가드레일처럼 작동해 차분하고 유지보수하기 쉬운 코드를 만드는 데 도움을 줍니다.
함수형 개념은 코드가 “입력 → 출력” 변환처럼 동작하도록 돕는 실용적인 습관과 기능들입니다.
일상적으로 말하면, 이 개념들은 다음을 강조합니다:
map, filter, reduce 같은 도구로 데이터를 명확히 변환하기아닙니다. 핵심은 실용적 채택이지 이념적 전환이 아닙니다.
주류 언어들은 람다, 스트림/시퀀스, 패턴 매칭, 불변성 도우미 같은 기능을 빌려와서, 필요할 때 함수형 스타일로 일부 코드를 작성할 수 있게 해줄 뿐입니다. 명령형이나 객체지향 방식이 더 명확하면 그대로 쓸 수 있습니다.
왜냐하면 함수형 아이디어는 놀라움(surprises) 을 줄여주기 때문입니다.
함수가 숨겨진 상태(전역 변수, 시간, 변경 가능한 객체 등)에 의존하지 않으면 동작을 재현하고 추론하기 쉬워집니다. 보통 그 결과는 다음과 같습니다:
순수 함수는 같은 입력에 대해 항상 같은 출력을 반환하고 부수 효과를 피하는 함수입니다.
이런 함수를 테스트할 때는 데이터만 주고 반환값만 확인하면 됩니다. 데이터베이스, 시간, 전역 설정 같은 환경을 준비하거나 목(mock)을 복잡하게 구성할 필요가 없어 테스트가 단순하고 빠릅니다. 또한 순수 함수는 호출 위치에 대한 가정이 적어 리팩터링 시 재사용하기 쉽습니다.
부수 효과는 함수가 값을 계산해 반환하는 것 외에 주변 상태를 읽거나 변경하는 모든 동작입니다—파일 읽기/쓰기, API 호출, 로그 작성, 캐시 업데이트, 전역 변수 접근, 현재 시간 사용, 난수 생성 등이 포함됩니다.
부수 효과는 동작을 재현하기 어렵게 만듭니다. 실용적인 접근법은 다음과 같습니다:
불변성은 값을 제자리에서 변경하지 않고 새 버전을 만든다는 단순한 규칙입니다.
이전 버전은 그대로 남아 있기 때문에 예상치 못한 변경으로 인한 버그가 줄어듭니다. 불변성의 장점:
이는 특히 구성(config), 사용자 상태, 애플리케이션 전역 설정처럼 널리 전달되는 데이터나 동시성 환경에서 유용합니다.
때로는 성능에 영향을 줄 수 있습니다.
큰 구조를 반복해서 복사하는 상황에서는 메모리와 성능 비용이 커질 수 있습니다. 실용적인 타협 방법:
이들 연산은 반복적인 루프 boilerplate를 재사용 가능한, 읽기 쉬운 변환으로 대체합니다.
map: 각 요소 변환filter: 규칙에 맞는 요소 선택reduce: 여러 값을 하나로 축약적절히 쓰면 파이프라인이 의도를 명확히 드러내고, 중복된 루프 변형을 줄여줍니다.
동시성 문제의 원인은 대부분 공유된 변경 가능한 상태입니다.
데이터가 불변이고 변환이 순수하면 여러 작업이 병렬로 실행돼도 안전해집니다. 항상 속도 향상이 보장되진 않지만, 부작용과 경쟁 조건(race condition)이 줄어들어 정합성이 좋아집니다.
작은 실천부터 시작하세요:
코드가 지나치게 복잡해지면 중간 단계를 이름 붙이거나 함수를 분리해 가독성을 우선하세요.