AI 도구의 진짜 한계는 '지능'이 아니라 '기억'이다
AI 코딩 어시스턴트를 쓰다 보면 어느 순간 이상한 데자뷔를 경험한다. 분명히 지난번에도 같은 실수를 했고, 같은 오류를 물어봤는데—AI는 마치 처음 만나는 사람처럼 똑같은 설명을 반복한다. 문제는 모델의 지능이 아니라 상태 없음(statelessness)이다. 오늘 dev.to에서 소개된 사례는 이 구조적 한계를 정면으로 건드린다.
한 개발자는 Hindsight라는 메모리 레이어를 AI 코딩 멘토에 연결해, 사용자가 반복하는 실수 유형을 구조화된 데이터로 저장하고 다음 응답에 반영하는 시스템을 만들었다. 핵심 흐름은 단순하다: retain → recall → adapt. 실수가 발생하면 언어, 오류 유형, 난이도를 구조화해 저장하고, 다음 질문 전에 과거 패턴을 조회해 응답 방식을 조정한다. 세 번째 같은 실수를 했을 때 "루프 동작 방식은 이렇습니다"가 아니라 "이 부분에서 세 번째 막히셨네요, 다른 방식으로 접근해봅시다"가 나오는 것이다.
이 사례에서 가장 인상적인 통찰은 이것이다: 모델을 바꾸는 것보다 메모리를 추가하는 것이 성능 향상에 더 효과적이었다. 같은 LLM이라도 맥락 있는 기억이 붙으면 반응의 질이 달라진다. 이는 AI 도구 선택 기준에서 '얼마나 똑똑한 모델인가'보다 '얼마나 잘 기억하고 적응하는가'를 함께 봐야 한다는 실용적 교훈을 준다.
Claude는 디자인을 잘 안다—단지 말해주지 않으면 숨길 뿐이다
"AI한테 랜딩 페이지 만들어달라고 했더니 또 Inter 폰트에 보라색 그라데이션이 나왔다." 이 경험은 이제 거의 밈이 됐다. Anthropic 블로그의 번역 글이 짚는 개념이 바로 분포 수렴(distributional convergence)이다. 모델은 학습 데이터에서 가장 '안전하게 통하는' 디자인 패턴으로 수렴한다. 지시가 없으면 평균값으로 향한다.
여기서 중요한 반전이 있다. Claude는 실제로 훨씬 더 풍부한 디자인 감각을 갖고 있다. "Inter와 Roboto는 피하라", "단색 배경 대신 레이어드 그라데이션을 써라" 같은 타깃형 지시만으로도 출력 품질이 즉각 달라진다. 문제는 이 지시를 매번 반복하거나 시스템 프롬프트에 전부 우겨넣으면 Python 디버깅, 데이터 분석 같은 무관한 작업에도 불필요한 토큰이 따라붙는다는 것이다.
이를 해결하기 위해 소개된 개념이 Skills다. 마크다운 문서 형태의 도메인 지식을 별도 파일로 관리하고, Claude가 프론트엔드 관련 요청을 받을 때만 동적으로 로드하는 방식이다. 약 400토큰 분량의 frontend_aesthetics 스킬 하나가 타이포그래피, 색상, 모션, 배경 처리 방식을 통합해 안내하고—Python 디버깅 요청에는 전혀 개입하지 않는다. 컨텍스트 윈도우를 불필요하게 오염시키지 않으면서도, 필요한 순간에 전문화된 가이드를 꺼내 쓰는 구조다.
특히 흥미로운 건 프롬프팅의 '고도' 개념이다. 정확한 hex 코드까지 지정하는 저고도 하드코딩도, "창의적으로 만들어"라는 고고도 모호함도 아닌—"극단적인 폰트 굵기 대비를 써라", "지배적인 색과 날카로운 포인트 컬러를 선택하라"처럼 방향은 주되 구현 자유도는 남기는 중간 고도가 가장 효과적이라는 것이다. 그리고 한 가지를 더 짚어야 한다: 특정 패턴을 명시적으로 금지해도 모델은 Space Grotesk 같은 또 다른 '평균적 선택'으로 회귀할 수 있다. "틀 밖에서 생각하라"는 메타 지시를 마지막에 넣는 것은 그 이유다.
React 데이터 페칭의 변천사: 왜 지금 RSC가 정답인가
메모리와 디자인 품질을 AI 도구 레벨에서 다뤘다면, 이번엔 React 자체의 패턴 판단력 이야기다. dev.to의 한 가이드는 React 데이터 페칭의 역사를 componentDidMount → useEffect → React Query/SWR → Server Components로 정리한다. 각 세대는 이전 세대가 만든 문제를 해결했다.
useEffect는 클래스 컴포넌트의 장황함을 해결했지만 경쟁 조건(race condition)과 클로저 스테일 버그를 낳았다. React Query는 서버 상태를 클라이언트 UI 상태와 분리해 캐싱·중복 제거·재시도를 자동화했다. 그리고 지금, React Server Components(RSC)는 많은 시나리오에서 클라이언트 상태 자체를 필요 없게 만든다. 서버에서 직접 async/await로 데이터를 가져오는 컴포넌트는 로딩 상태도, useEffect도, 캐싱 보일러플레이트도 없다.
그렇다고 React Query가 obsolete가 됐다는 뜻은 아니다. 이 가이드가 제시하는 판단 프레임은 명확하다: 정적이거나 서버에서 완결되는 데이터는 RSC로, 실시간 업데이트나 낙관적 UI가 필요한 데이터는 React Query로, 빠른 프로토타입이나 의존성을 최소화해야 하는 경우는 fetch + useEffect로. 도구를 고르는 기준이 '유행'이 아니라 '문제의 성격'이어야 한다는 것이다.
세 흐름이 가리키는 하나의 방향
기억하는 에이전트, 분포 수렴을 깨는 Skills, RSC까지의 데이터 페칭 변천사—얼핏 다른 주제처럼 보이지만 공통된 메시지가 있다. AI 도구는 방향을 잡아줄수록, 구조를 잡아줄수록 제 실력을 발휘한다.
메모리 레이어를 추가하면 에이전트는 '도구'에서 '멘토'로 전환된다. Skills로 맥락을 구조화하면 Claude는 '평균값 생성기'에서 '맥락 인식 디자이너'로 전환된다. 그리고 데이터 페칭 패턴의 판단력을 갖추면 AI가 제안하는 코드를 무비판적으로 수용하는 대신 '이 상황에 RSC가 맞는가, React Query가 맞는가'를 검토할 수 있게 된다.
결국 AI를 잘 부린다는 건 더 좋은 프롬프트를 쓴다는 것이 아니다. 도구가 작동하는 원리를 이해하고, 그 원리에 맞게 구조를 설계하고, 판단이 필요한 지점에서 인간의 기준을 정확히 개입시키는 것—그게 지금 프론트엔드 개발자에게 요구되는 실질적인 역량이다.