AI 기능을 프로덕트에 붙이는 일은 생각보다 훨씬 빨리 가능해졌다. API 키 하나면 GPT-4 요약이 돌아가고, RAG 파이프라인도 오픈소스 라이브러리로 반나절이면 프로토타입이 나온다. 문제는 그다음이다. '붙이는 것'과 '설계하는 것' 사이의 간격이 바로 기술 부채가 쌓이는 지점이다.
최근 세 가지 사례가 이 간격을 선명하게 보여준다. 국내 주식 정보 조회 웹 서비스의 UI 반복 개선 기록(velog SlateKR #059), AI 요약 API 비용이 월 $1,200을 넘어선 뒤 파이프라인을 재설계한 경험(dev.to), 그리고 RAG·MCP·에이전트 아키텍처를 실제 앱에 통합하는 구조 해설(dev.to)이다. 세 사례는 각기 다른 레이어를 다루지만, 공통적으로 같은 질문을 가리킨다. "AI 기능을 UI에 붙이기 전에 무엇을 먼저 설계해야 하는가?"
1. 빈 상태를 먼저 설계하라
주식 정보 서비스 개선 사례에서 가장 인상적인 대목은 AI나 데이터 파이프라인이 아니라, return null 한 줄이었다. 관심종목 데이터가 없을 때 섹션 전체를 그리지 않던 코드를 빈 상태 CTA 패널로 바꾼 것이다. 처음 방문한 사용자의 홈 화면은 hero와 안내카드만 남아 가운데가 휑했고, 이건 기능이 없어서가 아니라 빈 상태를 설계하지 않아서 생긴 문제였다.
AI 기능도 정확히 같은 함정에 빠진다. 요약 결과가 로딩 중일 때, API가 실패했을 때, 입력이 너무 짧아 요약이 의미 없을 때—이 세 가지 빈 상태를 미리 설계하지 않으면 UI는 조용히 망가진다. "AI가 답을 못 줄 때 사용자는 무엇을 보는가"를 기능 명세보다 먼저 써야 한다. 빈 상태는 예외 처리가 아니라 UX의 첫 번째 레이어다.
사례에서 또 한 가지 눈에 띄는 디테일이 있다. hydration 가드(!mounted)는 그대로 두고, 그 안에서 빈/채움 분기를 나눈 코드 구조다. 기술적 제약(Zustand persist의 hydration mismatch)을 인정한 채로 UX를 개선하는 방식이다. AI 기능을 붙일 때도 마찬가지다. 스트리밍 응답, 캐시 미스, 모델 폴백—각각의 기술적 경계를 먼저 파악하고, 그 안에서 사용자에게 보여줄 상태를 설계해야 한다.
2. 비용 레이어를 기능과 함께 설계하라
GPT-4로 TL;DR 생성기를 만든 개발자는 첫 달 API 비용으로 $1,200을 받아들고 나서야 파이프라인을 다시 설계했다. 결론은 단순하다. 추출형(extractive) 요약으로 입력 토큰을 90% 줄인 뒤, 줄어든 텍스트만 소형 생성 모델에 넘기는 2단계 하이브리드 구조다. 비용은 80% 감소했고 품질은 GPT-4에 근접했다.
이 사례의 핵심은 기술 선택이 아니라 순서다. "GPT-4를 쓸 것인가, GPT-3.5를 쓸 것인가"가 아니라 "어느 단계에서 어떤 모델이 필요한가"를 먼저 물어야 한다. TextRank 같은 로컬 추출기는 무료고 빠르다. 그 결과를 작은 모델에 넘기면 API 호출 크기가 극적으로 줄어든다. 복잡한 논증 구조를 가진 글에만 GPT-4 폴백을 남겨두면 비용과 품질을 동시에 잡을 수 있다.
프론트엔드 개발자 입장에서 이 구조는 컴포넌트 전략과 닮아 있다. 모든 UI를 하나의 복잡한 컴포넌트로 만들지 않고, 역할에 따라 레이어를 나누는 것처럼—AI 파이프라인도 "싸고 빠른 레이어"와 "비싸고 정확한 레이어"를 분리해서 설계해야 한다. 캐싱은 그 위에 올라오는 세 번째 레이어다. 같은 아티클을 수천 명이 읽는 프로덕션 환경에서 캐시 히트율은 비용 구조를 통째로 바꾼다.
3. 컴포넌트 시그니처를 깨뜨리지 않고 확장하라
주식 서비스 개선 사례에서 SearchInput 컴포넌트에 size prop을 추가하는 방식이 인상적이었다. 홈 화면에서만 검색창을 크게 키우고 싶었는데, 자식 강제([&_input]:h-12)로 밀면 결합도가 나빠진다. 그래서 optional size prop을 추가하고 기본값을 기존 크기로 뒀다. 기존 호출부는 prop을 안 넘기니 회귀가 없다. "시그니처를 넓힌 거지 깨뜨린 건 아니다"라는 표현이 핵심을 정확히 찌른다.
AI 기능을 UI에 붙일 때 가장 많이 저지르는 실수가 바로 이 지점에서 발생한다. AI 요약 버튼을 특정 카드 컴포넌트 내부에 하드코딩하거나, 스트리밍 상태를 특정 페이지 로직에 직접 묶어버리는 식이다. 나중에 같은 AI 기능을 다른 맥락에서 써야 할 때 컴포넌트를 통째로 다시 만들게 된다. AI 기능을 붙이기 전에 "이 기능이 어떤 컴포넌트 경계 안에 들어가야 하는가"를 먼저 물어야 한다.
RAG와 MCP 아키텍처 해설(dev.to)에서도 같은 원칙이 등장한다. MCP 서버가 LLM과 실제 데이터 소스 사이에 명확한 경계를 만드는 이유는 보안만이 아니다. AI 레이어와 데이터 레이어를 분리해야 각각을 독립적으로 교체하고 확장할 수 있기 때문이다. 이건 컴포넌트 설계에서 관심사 분리(separation of concerns)와 정확히 같은 맥락이다.
설계가 먼저, 기능은 그다음
주식 서비스 개선 기록에는 솔직한 고백이 하나 있다. 네 블록을 다 다듬고 전체를 봤는데 "한눈에 잘 만들었다"는 인상까지는 안 왔다는 것. 블록 하나하나는 정돈됐어도 화면 전체가 그만큼 올라오질 않았다. 이건 AI 기능 통합에서도 자주 겪는 상황이다. 요약은 나오고, 검색은 되고, 추천도 뜨는데—사용자가 "이 서비스 진짜 좋다"고 느끼지 않는다.
그 간격을 채우는 것이 바로 설계다. 빈 상태가 어떻게 보이는지, 비용이 어느 레이어에서 발생하는지, 컴포넌트 경계가 어디서 끊기는지—이 세 가지를 기능 구현 전에 명시적으로 정해두지 않으면, AI는 UI에 얹히는 순간 기술 부채가 된다. 빠른 프로토타이핑의 가치는 빠르게 검증하는 데 있지, 설계를 생략하는 데 있지 않다.
앞으로 AI 기능이 프론트엔드에 더 깊이 통합될수록—온디바이스 모델, 스트리밍 UI, 에이전트 기반 인터랙션—이 세 가지 설계 질문은 더 자주, 더 일찍 등장할 것이다. 기능을 켜기 전에 빈 상태를, 모델을 고르기 전에 비용 레이어를, 코드를 짜기 전에 컴포넌트 시그니처를 먼저 설계하는 습관이 AI 시대의 프론트엔드 설계 기본기가 된다.