"그 기능, 개발하면 안 됩니다."
회의실에서 제가 가장 자주 하는 말입니다.
데이터 없이 '사용자가 좋아할 것 같다'는 감(Feel)으로 기획을 가져오면 반려합니다.
개발도 마찬가지입니다.
'그냥 익숙해서' 모나드(Monad)를 남발하거나, 무지성으로 if-else를 떡칠하는 코드를 보면 화가 납니다.
그건 리소스 낭비입니다.
비즈니스 로직은 복잡한데, 코드는 그걸 감당하지 못해 스파게티가 됩니다.
오늘 공개할 내용은 2019년 논문에서 시작됐지만, 대부분의 개발자가 '어렵다'며 덮어버린 Selective Applicative Functors에 대한 이야기입니다.
단순히 "코드를 예쁘게 짜는 법"이 아닙니다.
이건 '예측 가능한 시스템'을 만드는 생존 기술입니다.
대부분의 주니어 개발자는 두 가지 도구만 압니다.
1. Applicative Functor: 멍청하지만 안전한 로봇입니다. 시키는 대로 다 실행합니다. 하지만 '선택'을 못 합니다. A 아니면 B를 실행해야 하는데, 둘 다 실행해버리죠.
2. Monad: 전지전능한 신입니다. >>= 하나로 뭐든 합니다. 앞의 결과에 따라 뒤의 행동을 결정합니다.
문제는 여기서 발생합니다.
모나드는 너무 강력해서 '정적 분석(Static Analysis)'이 불가능합니다.
코드를 돌려보기 전엔 무슨 짓을 할지 모릅니다. "시간의 화살(Arrow of Time)"이 강제되어, 병렬 처리가 어렵고 분석 도구가 무용지물이 됩니다.
핀테크 도메인에서 '예측 불가능성'은 죄악입니다.
그래서 우리에겐 '제3의 길'이 필요했습니다.
그게 바로 Selective Applicative Functors입니다.
이름이 어렵다고요? 핵심은 Exclusive Determined Choice (배타적 결정 선택)입니다.
쉽게 말해, 실행 흐름을 미리 정해진 유한한 가지수 안에서 선택하게 만드는 겁니다.
모나드처럼 동적으로 무한히 뻗어나가는 게 아니라, "내가 갈 길은 이 3가지 중 하나다"라고 컴파일 타임에 선언하는 셈입니다.
보통 하스켈(Haskell) 좀 한다는 친구들도 select 함수 하나 보고 "아, 그냥 if 문 같은 거네" 하고 넘어갑니다.
틀렸습니다.
최근 이론적 논의에서는 select 함수를 넘어 Arrows(화살표) 개념을 도입해야 한다고 말합니다.
단순히 펑터(Functor) 레벨에서 노는 게 아니라, 프로펑터(Profunctor)와 카테고리 이론을 빌려와야 비로소 이 개념이 완성됩니다.
왜 이렇게까지 해야 할까요?
정적 분석이 가능해지기 때문입니다.
우리가 작성한 코드가 실행되기도 전에, 이 비즈니스 로직이 어떤 경로를 탈 수 있는지 완벽하게 파악할 수 있다는 뜻입니다.
상수 펑터(Constant Functor)와 Near-semirings(준반환) 대수 구조를 활용하면, 코드를 실행하지 않고도 효과(Effect)를 수집할 수 있습니다.
이걸 구현하려면 ControlFlow라는 데이터 타입을 이해해야 합니다.
복잡해 보이지만, 뜯어보면 우리가 매일 짜는 비즈니스 로직의 AST(추상 구문 트리)와 똑같이 생겼습니다.
Action: 실제 수행할 작업Pure: 순수 값Sequencing: 순차 실행CaseBranch: 분기 처리
이 구조를 Free Arrow 형태로 잡으면, 비로소 우리는 '제어 흐름'을 데이터처럼 다룰 수 있게 됩니다.
select :: f (Either u v) -> f (u -> v) -> f v
보통 쓰는 이 공식은 반쪽짜리입니다.
진짜 힘은 자유 화살표(Free Arrow) 구조 안에서 나옵니다.
결론을 말씀드립니다.
여러분이 만드는 서비스가 트래픽이 적고, 장애가 나도 상관없는 토이 프로젝트라면 그냥 쓰던 대로 모나드 쓰세요.
하지만 수천만 원이 오가는 결제 시스템이나, 수많은 분기 처리가 필요한 대출 심사 로직을 짠다면?
Selective Applicative를 공부하십시오.
무조건적인 >>=(Bind) 사용을 멈추고, 로직을 유한한 선택지 안에 가두세요.
그래야 시스템이 개발자의 통제 하에 들어옵니다.
'감'으로 코딩하지 마십시오.
증명된 구조로, 예측 가능한 코드를 짜십시오.
그게 프로입니다.
