LLM 자동화를 시작하면 대부분 이런 질문을 한다.
“어떤 모델이 좋을까?”
“프롬프트를 어떻게 짜야 정확도가 올라갈까?”
그런데 실제 운영을 해보면
문제는 프롬프트가 아니다.
문제는 아키텍처다.
1. LLM은 상태를 기억하지 않는다
LLM은 본질적으로 stateless하다.
매 요청은 독립적이다.
자동화 시스템에서 이 특성은 큰 문제가 된다.
예를 들어:
-
1시간 전에 어떤 뉴스가 감지되었는지
-
이전 분석 결과가 무엇이었는지
-
패턴이 누적되고 있는지
이건 모델이 아니라
시스템이 기억해야 한다.
LLM은 판단 도구지,
기억 장치가 아니다.
그래서 자동화 설계에서 가장 먼저 해야 할 일은:
“LLM 밖에 무엇을 저장할 것인가”를 정의하는 것이다.
2. 수집 → 저장 → 분석 → 판단은 분리되어야 한다
LLM을 중심에 두면 구조가 망가진다.
많은 구현이 이렇게 된다:
웹 수집 → LLM 요약 → 결과 저장
이 구조는 단순하지만 확장성이 없다.
더 안정적인 구조는:
-
데이터 수집 레이어
-
정제/전처리 레이어
-
LLM 분석 레이어
-
결과 저장 레이어
-
트리거/알림 레이어
각 레이어는 독립적으로 실패해야 한다.
특히 LLM 호출은
지연과 비용이 발생하기 때문에
항상 비동기 구조로 분리하는 게 안전하다.
3. 비용은 호출 횟수에서 터진다
LLM 자동화를 실제로 운영해보면
가장 먼저 체감되는 건 정확도가 아니라 비용이다.
-
기사 1건당 1회 호출
-
댓글 분석 1회
-
요약 1회
-
분류 1회
이렇게 쌓이면 호출 수가 기하급수적으로 늘어난다.
그래서 실전에서는:
-
배치 처리
-
토큰 절감 프롬프트
-
캐싱 전략
-
중요도 기반 필터링
이 필수다.
모든 데이터를 분석하는 건
기술적으로는 가능하지만
경제적으로는 불가능하다.
4. 자동화는 ‘정확성’보다 ‘일관성’이 중요하다
LLM 결과는 항상 변동성이 있다.
같은 기사라도
약간 다른 요약이 나올 수 있다.
이때 중요한 건
완벽한 답이 아니라
일관된 기준이다.
예를 들어:
-
감성 점수 범위를 고정한다
-
출력 포맷을 엄격히 제한한다
-
JSON 구조를 강제한다
이렇게 해야
시스템이 사람이 아니라
코드처럼 동작한다.
5. 자동화 시스템은 결국 “결정 흐름”이다
LLM 자동화의 본질은
텍스트 생성이 아니다.
입력 → 판단 → 행동
이 흐름을 설계하는 것이다.
LLM은 그 중
“판단” 부분만 담당한다.
나머지는:
-
데이터 파이프라인
-
상태 저장
-
조건 트리거
-
알림 시스템
이 전부가 결합되어야
하나의 자동화 시스템이 된다.
정리
LLM 자동화에서 중요한 건
모델 선택이 아니다.
-
어떤 데이터를 남길 것인가
-
어떤 단위로 분석할 것인가
-
언제 호출할 것인가
-
결과를 어떻게 고정할 것인가
이 질문에 답하지 않으면
자동화는 데모로 끝난다.
프롬프트는 10%다.
아키텍처가 90%다.