gwanhun1
AI 기능, 무조건 넣는 게 답일까 — '무료 무제한 AI'라는 함정
요즘 사이드 프로젝트를 만들면 누구나 한 번쯤 이 생각을 한다. "여기에 AI 하나 넣으면 좀 그럴싸해 보이지 않을까?"
나도 그랬다. 마크다운 블로그에 AI 요약(TL;DR)과 "이 글에게 물어보기" Q&A를 붙이려고 했다. 상세페이지 상단에 3줄 요약이 뜨고, 독자가 글에 대해 질문하면 답해주는 — 생각만 해도 멋졌다. 그런데 결국 접었다. 그리고 그 결정이 옳았다. 왜 그랬는지, 그 과정에서 배운 걸 공유한다.
1. "무료로 하고 싶다"는 순간 벽이 세 개 나타난다
내 조건은 하나였다. "무조건 무료." 개인 블로그에 매달 AI 비용을 내고 싶진 않았다. 그런데 막상 파보니, 무료 AI는 생각보다 함정이 많았다.
| 선택지 | 진짜 무료? | 함정 |
|---|---|---|
| Claude / GPT API | 유료 | 품질은 최고, 하지만 호출당 과금 |
| Gemini 무료 티어 | 일일 한도 | 하루 요청 수 제한 + 데이터가 학습에 쓰일 수 있음 |
| Dify 같은 오케스트레이션 | 그 자체론 무료 아님 | 모델을 감싸는 껍데기 — 뒤에 붙인 모델에서 비용이 남 |
| Ollama 자체 호스팅 | 진짜 무제한 | 서버 RAM·운영 부담 (개인 블로그엔 과함) |
정리하면 이렇다.
무료 · 무제한 · 좋은 품질 — 이 셋은 동시에 가질 수 없다. 잘해야 둘이다.
특히 헷갈리기 쉬운 게 "Dify 쓰면 무료 아냐?" 같은 오해다. Dify(혹은 유사 툴)는 LLM을 관리·연결해주는 레이어일 뿐, 실제 비용은 그 뒤에 꽂은 모델에서 나온다. "무료로 돌아간다"면 뒤에 무료 티어 모델을 꽂아둔 것이고, 결국 그 무료 티어의 한도를 그대로 물려받는다.
2. 진짜 물어야 할 질문: "이 기능에 LLM이 꼭 필요한가?"
여기서 한 발 물러나 근본적인 질문을 던졌다. 내가 붙이려던 두 기능을 보자.
- 글 요약 / Q&A → 임의의 글을 읽고 이해해야 한다. 이건 진짜 LLM이 필요하다.
- 반면 세상의 많은 "AI 기능"은 사실 규칙이나 기존 데이터로 충분히 된다.
실제로 내가 참고한 다른 프로젝트는 "AI 고민 상담" 기능을 LLM으로 만들었다가 비용 때문에, 페르소나 + 말투 + 템플릿을 조합하는 규칙 기반 생성기로 갈아탔다. 사용자는 차이를 거의 못 느꼈다. 감정적 위로는 패턴으로 흉내 낼 수 있었기 때문이다.
기능에 "AI"를 붙이기 전에, 그 기능이 정말 추론 능력을 요구하는지 먼저 따져라. 분류·추천·요약처럼 보이는 일 중 상당수는 기존 데이터와 규칙으로 더 싸고 빠르고 안정적으로 된다.
3. 비용을 0에 수렴시키는 진짜 레버는 '캐싱'이다
만약 요약처럼 진짜 LLM이 필요하다면, 비용을 죽이는 핵심은 모델 선택이 아니라 호출 횟수다.
블로그 글 요약은 내용이 바뀌기 전까지 변하지 않는다. 그러니 매 조회마다 부를 이유가 없다.
요약 생성: 글 출간 시 딱 1회 → DB에 저장(캐시)
요약 조회: DB에서 읽기 (AI 호출 0회)
이렇게 하면 평생 총 호출 수는 글 개수 정도다. 글이 수십 개인 블로그라면, 하루 수백~수천 요청을 주는 무료 티어 입장에서는 먼지 수준이다.
작은 서비스에서 "무료 티어의 명목상 한도"는 대부분 실질적으로 무제한이다. 문제는 한도 자체가 아니라, 캐싱 없이 매 요청마다 호출하는 설계다.
역설적이게도, 비용을 결정하는 건 "어떤 AI를 쓰냐"보다 "얼마나 자주 부르냐"였다.
4. 그래서 나는 AI 대신 이걸 넣었다
결국 AI 기능을 접고, 영구 무료 · 인프라 0 · 독자 경험에 직결되는 기능들로 방향을 틀었다.
- 목차(TOC) — 긴 기술글의 가독성
- 읽기 진행바 + 읽기 시간 — 읽기 전 부담 가늠
- RSS 피드 — 구독·재방문 채널
- 인기 글 / 시리즈(연재) — 내부 링크로 체류·회유를 늘려 검색 랭킹에도 유리
전부 순수 프론트엔드와 쿼리로 되는, 트렌드가 아니라 실사용 가치로 고른 것들이다. 자체 호스팅한 LLM으로 느린 요약을 보여주는 것보다, 이쪽이 방문자에게 훨씬 큰 값을 준다.
그리고 이 과정에서 예상치 못한 소득도 있었다. 목록의 날짜가 자꾸 "방금 전"으로 바뀌길래 파보니, 조회수를 올리는 쿼리가 수정시각(updated_at)을 함께 갱신하고 있었다. ORM이 update 시 수정시각을 자동으로 건드리는 흔한 함정이다. 이게 sitemap의 lastmod까지 흔들어 검색엔진에 "글이 매번 수정됐다"는 잘못된 신호를 보내고 있었다. AI를 포기하는 대신 진짜 SEO 버그 하나를 잡은 셈이다.
마치며: AI는 체크박스가 아니라 도구다
AI를 넣지 말라는 얘기가 아니다. AI가 그 문제의 가장 좋은 도구일 때 넣으라는 것이다.
- 유행이라서 → X
- 그럴싸해 보여서 → X
- 그 기능이 정말 추론을 필요로 하고, 비용·품질·유지보수를 감당할 수 있어서 → O
내 블로그엔 언젠가 AI 요약이 다시 들어올 수도 있다. 하지만 그건 "AI라서"가 아니라, 캐싱으로 비용이 0에 수렴하고 품질이 값을 할 때일 것이다. 그때까지는 화려한 기능보다 확실하게 값을 하는 기능이 이긴다.
도구는 목적을 위해 존재한다. AI를 위한 기능이 아니라, 문제를 위한 AI를 만들자.