과도하게 설계된 상태 관리 대신 순수 이벤트 기반 AI 자동화로 앱의 상태 관리를 선택한 이유 (그리고 여러분도 그렇게 해야 하는 이유!)

현대 웹 프로젝트를 작업할 때 개발자들이 잘못된 것에 너무 많은 시간을 쓰는 큰 문제가 있습니다 📦

우리는 실제 비즈니스 로직을 작성하기 전에 다층 아키텍처(multi layered architectures)를 구축하고 🏗️, 세 가지 다른 상태 관리 시스템(state management systems)을 연결하며 📚, 여러 캐싱 레이어(caching layers)를 구성하고 🗄️, 필요하지 않은 것까지 모든 것을 컨테이너화합니다 🐳💻

몇 주 전 저는 next.js 프론트엔드, n8n 웹훅, voiceflow 및 기타 다양한 상태 저장 요소(stateful elements)를 활용하는 자율 다중 에이전트 워크플로우 시스템을 작업하고 있었는데, 진행 속도가 너무 느린 것에 정말 좌절감을 느꼈습니다. 제 앱은 너무 많은 보일러플레이트 Redux 같은 코드와 Context hell로 인해 실제로 더 빠르게 구축하고 성능이 좋은 애플리케이션을 배포하는 것을 방해받고 있었습니다 🐢

그래서 모든 것을 처음부터 부수고 🔨

가볍고, 이벤트 기반이며, 디커플링된 자동화 파이프라인(event driven decoupled automation pipeline)을 구축하기로 결정했습니다 ⚡ 제가 그렇게 한 이유, 작동 방식, 그리고 이 복잡성을 제거하여 개발 속도를 10배 향상시킨 과정에 대한 정확한 아키텍처 분석입니다 📈

문제점: 과도하게 설계하는 함정 (The Over Engineering Trap)

우리 모두 이런 경험을 합니다. 좋은 의도로 프로젝트를 시작합니다 😇

Simple Idea ➔ Clean Frontend ➔ Minimal Backend ➔ Production

하지만 금방 혼란스러운 재앙으로 변해버립니다 🌀

Simple Idea ➔ Micro-frontend Setup ➔ 5 State Libraries ➔ Custom Event Emitters ➔ Redis Caching ➔ 12 Docker Containers ➔ Infinite Suffering 💀

AI/자동화 앱에서 복잡한 상태 관리가 우리 모두에게 실패하는 이유

LLM(대규모 언어 모델) 🧠을 활용하고, Make.com이나 n8n(웹훅)과 같은 외부 API 트리거를 사용하며, 프론트엔드로 응답을 스트리밍해야 하는 애플리케이션을 구축할 때, 자연스러운 UI 상태 관리 패턴이 완전히 무너집니다 💔

경쟁 조건 (Race Conditions) 🏃‍♂️💨: 앱의 상태가 실제 백엔드 웹훅 이벤트와 분리됩니다.
유지보수 오버헤드 (Maintenance Overhead) 🛠️: 데이터 모델을 업데이트하려면 다섯 개의 다른 파일을 건드려야 합니다.

인지 부하 (Cognitive Load) 🤯: 데이터가 실제로 무엇을 하는지 생각하는 시간보다, 그 데이터가 어디에 위치해 있는지 생각하는 데 시간을 더 많이 소비합니다.

해결책: 이벤트 기반 파이프라인

제 프론트엔드(frontend)가 이 모든 마이크로 상태(micro states)를 관리하도록 강요하는 대신, 가벼운 웹훅(webhook)과 직접적인 상태 동기화(direct state synchronization) 🔄를 사용하는 이벤트 기반, 발행-구독(pub sub) 모델로 전환했습니다.

핵심 아키텍처

브레인 (자동화 계층/Automation Layer) 🧠: n8n / Make.com이 모든 무거운 백엔드 작업, AI 프롬프트 오케스트레이션(prompt orchestration), 그리고 google AI studio를 통한 외부 API 트리거 라우팅을 처리합니다.

통신 계층 (Communication Layer) 📨: 추가적인 폴링(polling) 없이 웹훅을 통해 깔끔한 JSON 페이로드 통신을 수행합니다. 백엔드는 필요할 때만 프론트엔드와 통신합니다.

인터페이스 💻: 이벤트를 수신하고 필요한 경우에만 로컬 컴포넌트 상태를 업데이트하는, 매우 간결하고 깨끗한 React/TypeScript/Tailwind CSS 기반의 프론트엔드를 활용합니다.

코드: (분리된 웹훅 핸들러)

거대한 전역 스토어(global stores) 대신, 깔끔하고 모듈화되었으며 유지보수하기 쉽고 읽기 쉬운 웹훅 핸들러 함수를 얻었습니다 ⚡

interface AgentEventPayload {

...

결과: 중요한 지표들

아키텍처의 불필요한 복잡성을 제거함으로써, 즉각적으로 엄청난 개선을 확인할 수 있었습니다 🎉

번들 크기 (Bundle Size) 📦: 수많은 중복된 헬퍼 라이브러리(helper libraries)와 상태 래퍼(state wrappers)를 제거하여 번들 크기를 거의 45% 줄였습니다.

개발 속도 (Development Velocity) 🚀: 이제 컨텍스트 프로바이더(context providers) 리팩토링에 며칠이 아닌 몇 시간밖에 걸리지 않습니다.

신뢰성 (Reliability) 🛡️: 외부 LLM API 타임아웃이나 속도 제한(rate limiting) 문제 처리 시 잠재적인 장애 지점이 줄어듭니다.

우리가 배운 것들?

1. 단순함 자체가 기능이다 ✨: 무언가가 존재한다고 해서 그것이 필요하다는 의미는 아닙니다. 문제를 해결하기 위해 가능한 가장 단순한 도구부터 사용하세요.

2. 이벤트 기반 미래를 수용하라 🔄: UI 로직을 백엔드 프로세스에서 분리하면, AI 워크플로우를 확장하는 것이 무한히 쉬워집니다.

3. 아직 필요하지 않은 규모에 대비해 미래 지향적으로 코딩하는 것을 멈춰라. 영원히 지속될 코드가 아니라, 삭제되도록 작성된 코드를 작성하라. 🏗️

댓글에서 논쟁합시다! 👇

알아요, 알아요. 여러분 중 일부는 여전히 복잡한 상태 관리 시스템과 무거운 엔터프라이즈 보일러플레이트(boilerplates)의 열렬한 팬이시겠죠 🏢

지금까지 경험했던 가장 과도하게 설계된 아키텍처는 무엇인가요? 스택(stack)의 핵심 부분을 완전히 제거하고 즉각적인 안도감을 느낀 적이 있나요?

함께 이야기해 봅시다! 🗣️