📌 LLM 애플리케이션이 단순 API 호출로 끝나지 않는 이유

안녕하세요, BQ개발자입니다.

ChatGPT가 나온 지 2년. 이제 누구나 API 키 하나로 AI 서비스를 만들 수 있는 시대가 됐습니다.
실제로 제 주변에서 개발자가 아닌데도 커서랑 뚝딱 앱 만드시는 분들도 계시구요.
그런데 왜 대부분의 LLM 프로젝트는 PoC에서 프로덕션으로 넘어가지 못할까요?

당분간 LLM 어플리케이션 만들때 고려해야 할 요소들에 대한 컨텐츠를 작성하려고 합니다!
이제 진짜 LLM 활용에 대해 본격적으로 대비해야하는 시대니까, 같이 공부하면서 알아보시죠
오늘은 서론 느낌으로 한번 톺아보겠습니다.

🤔 "그냥 API 호출하면 되는 거 아니야?"

처음 LLM을 접한 개발자들이 가장 많이 하는 착각입니다.
실제로 데모 만들기는 정말 쉽죠. API 키 받아서 프롬프트 넣고 응답 받으면 끝.
하지만 실제 서비스로 만들려는 순간, 예상치 못한 복잡성의 늪에 빠지게 됩니다.

1️⃣ 같은 질문, 다른 대답의 함정
가장 먼저 맞닥뜨리는 문제는 일관성입니다.
"우리 회사 휴가 정책 알려줘"라는 같은 질문에 LLM이 매번 다른 답변을 합니다.
어떤 날은 친절하게, 어떤 날은 간단하게, 심지어 어떤 날은 틀린 정보를 섞어서 답하기도 합니다.
이게 창의적 글쓰기라면 장점이겠지만, 기업 서비스에서는 치명적입니다.
고객이 같은 질문을 했는데 매번 다른 답변을 받는다면? 신뢰도는 바닥을 치게 됩니다.

2️⃣ 비용 폭탄과 속도 지옥
개발 환경에서는 문제없던 서비스가 실제 사용자 100명만 들어와도 무너지기 시작합니다.
GPT-4 한 번 호출에 수백 원, 복잡한 대화가 오가면 사용자당 수천 원의 비용이 발생합니다.
속도는 또 어떤가요? 사용자가 질문하고 10초를 기다려야 답변이 온다면?
아무리 정확한 답변이라도 사용자는 떠나갑니다. 하지만 빠른 모델을 쓰면 품질이 떨어지는 딜레마에 빠집니다.

3️⃣"어제 우리가 얘기한 거 기억 안 나?"
LLM은 본질적으로 건망증 환자입니다. 매 대화마다 백지 상태에서 시작합니다.
사용자가 "아까 말한 그 제품 가격이 얼마였지?"라고 물으면 뭐라고 답해야 할까요?
대화 히스토리를 매번 전부 보내면? 토큰 비용이 기하급수적으로 증가합니다.
중요한 것만 요약해서 보내면? 맥락을 놓쳐 엉뚱한 대답을 합니다.

4️⃣ 회사 문서는 어떻게 가르치지?
LLM이 아무리 똑똑해도 우리 회사의 내부 규정이나 제품 정보는 모릅니다.
학습 데이터에 없었으니까요. 그래서 RAG를 쓴다고 하죠
문서 100개를 벡터 DB에 넣었는데, "연차 사용 규정"을 물으면 "병가 규정"을 참조해서 답변합니다.
벡터 유사도만 믿었다가는 저는 분명 큰코 다칠거라고 생각해요. 게다가 PDF 표나 이미지 안의 정보는 제대로 추출조차 안 되는...

5️⃣ 위험한 답변의 법적 책임
"이 약 먹어도 되나요?"라는 질문에 LLM이 잘못된 의료 조언을 했다면?
"투자하기 좋은 주식 추천해줘"에 구체적인 종목을 추천했다면?
필터링 없는 LLM은 시한폭탄입니다.
하지만 너무 보수적으로 필터링하면 "죄송합니다, 답변할 수 없습니다"만 반복하는 쓸모없는 봇이 되버리죠

✍️ 단순함 뒤에 숨은 12개의 층
제가 경험한 바로는, 프로덕션 레벨 LLM 애플리케이션은 최소 12개 이상의 복잡한 레이어로 구성됩니다.
각 레이어는 서로 맞물려 있고, 하나를 최적화하면 다른 하나가 망가지는 트레이드오프의 연속입니다.

Safety → Consistency → Performance → Cost → Memory → Knowledge

이 모든 것이 조화롭게 작동해야 비로소 "그냥 작동하는" 서비스가 됩니다.

앞으로 연재할 시리즈에서는 이 각각의 레이어가 왜 필요한지, 어떻게 구현하는지,
무엇을 조심해야 하는지 하나씩 파헤쳐볼 예정입니다.
LLM API 호출은 시작일 뿐이라는거!!!

---

여러분의 좋아요와 공유는 사랑입니다 🥰

#BQ개발자 #LLM애플리케이션 #AIEngineering #프로덕션레벨

📌 LLM 어플리케이션 1편: 세이프티 필터

안녕하세요, BQ개발자입니다.

앞서 말씀드린 LLM 애플리케이션 핵심 개념 시리즈, 오늘부터 시작합니다. 첫 번째는 세이프티 필터입니다.

📱LLM 애플리케이션이 단순 API 호출로 끝나지 않는 이유

--

🤔 "API 호출하고 필터 추가하면 끝 아닌가?"

많은 개발자들이 LLM 앱을 이렇게 생각합니다:

사용자 입력 → LLM API 호출 → 나쁜 내용 필터링 → 결과 출력

실제로 데모 만들기는 정말 쉽죠. ChatGPT API 키 받아서 "폭탄", "마약" 같은 키워드만 차단하면 된다고 생각하거든요.

하지만 실제 서비스로 만드는 순간, 이게 첫 번째이자 가장 복잡한 벽이 될 수 있습니다.


⚖️ 제로섬 게임의 잔혹한 현실 (안전 vs 유용성)

세이프티 필터의 진짜 문제는 안전과 유용성이 정반대로 움직인다는 점입니다.

그거에 더해서 더 큰 문제는 "무엇이 나쁜가"를 정의하는 게 기술적 문제가 아니라는 점입니다.

"칼 사용법"을 물어봤다고 가정해보세요. 요리에도 쓰이지만 위험하기도 하죠. 차단해야 할까요, 허용해야 할까요? "약품 정보"는? "정치적 견해"는?

더 복잡한 건, 같은 질문이라도 상황에 따라 달라진다는 점입니다. 의대생이 묻는 "해부학 정보"와 일반인이 묻는 건 다르게 처리해야 할까요? 어떻게 구분할 건가요?

실제로 AI 챗봇 서비스들이 망하는 가장 흔한 패턴이 이겁니다:

너무 엄격하게 → 사용자들이 "대화가 계속 끊어진다"며 떠남
너무 느슨하게 → 몇 시간 만에 혐오 발언 쏟아내며 서비스 중단

⚔️ 공격은 쉽고 방어는 불가능하다

더 근본적인 문제는 구조적 불리함입니다.

악의적 사용자는 "폭탄" 대신 "시끄러운 장치", "요란한 물건" 같은 우회 표현을 씁니다. 아니면 "소설 쓰기"라는 명목으로 위험한 정보를 요청하죠.

문제는 공격자는 하나의 허점만 찾으면 되지만, 개발자는 모든 가능한 우회 방법을 다 막아야 한다는 점입니다. 마치 집에 100개의 문이 있는데, 도둑은 하나만 열면 되지만 집주인은 100개를 다 잠가야 하는 것과 같아요.

💸 비즈니스 리스크의 현실

이게 단순한 기술적 도전이 아닌 이유는 실제 비즈니스 리스크 때문입니다.

최근 몇 년간 AI 관련 벌금만 봐도:
- 개인정보 보호 위반으로 수십억 원 벌금
- 혐오 발언 생성으로 브랜드 이미지 파괴
- 안전장치 부족으로 법적 책임 추궁

반대로 너무 보수적으로 가면 사용자들이 "이게 뭐 하는 거냐"며 경쟁 서비스로 떠나버립니다.

✍️ 첫 번째 벽이지만 가장 어려운 문제

개인적으로 여러 LLM 프로젝트를 보면서 느낀 건, 세이프티 필터가 전체 시스템에서 가장 정답이 없는 영역이라는 점입니다.

다른 기술적 문제들은 "더 좋은 알고리즘"이나 "더 많은 데이터"로 해결되지만, 세이프티는 "어느 정도 위험을 감수할 것인가"의 비즈니스 선택 문제거든요.

모든 AI 회사가 매일 이런 딜레마를 겪을 것 같아요. 완벽한 해답이 없다는 걸 인정하고, 지속적으로 균형점을 찾아가는 거죠.

하지만 안전한 기반이 마련되었다고 가정하면, 이제 다음 문제가 기다립니다. 바로 일관된 품질의 결과를 얻는 방법이죠.

다음 편에서는 "같은 LLM인데 왜 매번 다른 품질의 답변이 나오는가"와 이를 해결하는 프롬프트 템플릿에 대해 다뤄보겠습니다.

----

여러분의 좋아요와 공유는 사랑입니다 🥰

#BQ개발자 #LLM애플리케이션 #세이프티필터 #AIEngineering

📌 LLM 어플리케이션 2-1편: 똑같은 LLM, 다른 결과

안녕하세요, BQ개발자입니다.

지난 편에서 세이프티 필터의 딜레마를 다뤘는데요, 이제 안전한 기반이 마련되었다고 가정하면 다음 문제가 기다립니다.

📱LLM 애플리케이션이 단순 API 호출로 끝나지 않는 이유
📱LLM 어플리케이션 1편: 세이프티 필터

바로 "같은 LLM인데 왜 매번 다른 품질의 답변이 나오는가"입니다.

🤔 "그냥 질문만 잘 쓰면 되는 거 아닌가?"

많은 개발자들이 프롬프트를 단순한 질문 기법 정도로 생각합니다. 실제로는 완전히 다른 이야기예요.

같은 GPT-4에게 "마케팅 카피 써줘"라고 똑같이 물어봐도:
- 어떤 날은 전문가급 카피가 나오고
- 어떤 날은 어색하고 어설픈 결과가 나옵니다

심지어 "써줘"를 "써주세요"로만 바꿔도 완전히 다른 톤이 나올 수 있다고 해요.

핵심은 동일한 GPT-4를 사용해도 프롬프트 품질에 따라 전문가급과 초보자급 결과가 나온다는 점입니다.

⚡ 왜 이런 일이 벌어질까

LLM은 본질적으로 "확률 기반 단어 예측 시스템"입니다.
같은 입력이라도 매번 확률 계산을 새로 하면서 다른 경로로 답변을 생성하거든요.

더 중요한 건 프롬프트 민감성입니다. 연구에 따르면 문구 하나, 심지어 구두점 하나만 바껴도 결과가 극적으로 달라질 수 있다고 해요.

그래서 비즈니스에서는 큰 문제가 됩니다.

고객서비스 챗봇이 같은 질문에 대해:
- 월요일에는 친절하고 상세한 답변
- 화요일에는 기계적이고 간단한 답변

이런 식으로 일관성 없이 응답한다면 브랜드 신뢰도가 떨어질 수 있는거죠.

🎯 프롬프트 템플릿이라는 해결책

이 문제의 해결책으로 제안된게 바로 "프롬프트 템플릿 시스템"입니다.
템플릿은 단순한 질문이 아니라 상황별로 최적화된 "지시사항 패키지"예요.

예를 들어:
VIP 고객용 템플릿: "정중하고 개인화된 톤으로..."
일반 고객용 템플릿: "친근하고 효율적인 톤으로..."
클레임 처리용 템플릿: "공감적이고 해결 중심적으로..."

각각 완전히 다른 접근이 필요하거든요.

요즘 많이 쓰이는 접근법 중 하나가 "프롬프트 셀렉터"입니다.
"9세 여아를 위한 동화"와 "15세 남학생을 위한 소설"은 완전히 다른 템플릿이 필요한데, 이를 자동으로 판단해서 적절한 템플릿을 선택하는 시스템이죠.

하지만 이런 템플릿 시스템이 만들어내는 변화는 생각보다 큽니다.

다음 편에서는 프롬프트 템플릿이 어떻게 새로운 비즈니스 자산이 되고 있는지, 그리고 이를 관리하는 복잡성에 대해 다뤄보겠습니다.

---

여러분의 좋아요와 공유는 사랑입니다 🥰

#BQ개발자 #LLM애플리케이션 #프롬프트문제 #AIEngineering

📌 LLM 어플리케이션 2-2편: 프롬프트 템플릿 - 코드보다 중요한 새로운 자산

안녕하세요, BQ개발자입니다.

지난 편에서 프롬프트 템플릿 시스템을 소개했는데요, 이제 이것이 만들어내는 놀라운 변화에 대해 알아보겠습니다.

📱LLM 애플리케이션이 단순 API 호출로 끝나지 않는 이유
📱LLM 어플리케이션 1편: 세이프티 필터
📱LLM 어플리케이션 2-1편: 똑같은 LLM, 다른 결과


💰 코드보다 중요해진 프롬프트

프롬프트의 중요성을 한번 사례로 들어서 말해보겠습니다.
- Shopify는 같은 GitHub Copilot을 쓰면서도 프롬프트 최적화만으로 커밋 시간을 15% 단
- Airbnb는 여행 추천 프롬프트 개선으로 이메일 클릭률을 30% 올림

더 충격적인 건 프롬프트 엔지니어의 연봉입니다. 현재 최대 33만 5천 달러(약 4억 5천만 원)까지 책정되고 있어요. 일반 개발자보다 높은 수준이죠

ㄷㄷ... 부럽다. 이직할까..

프롬프트 엔지니어링 시장 자체도 2024년 3억 8천만 달러에서 2034년 70억 달러로 18배 성장이 예상됩니다. 연평균 성장률이 33.9%예요.

왜 이런 일이 벌어질까요? 많은 기업이 동일한 기본 LLM(OpenAI, Anthropic, Google)을 사용하기 때문입니다.
차별화와 경쟁 우위는 모델 자체가 아니라 "어떻게 지시하느냐", 즉 프롬프트에서 나오는 거죠.


🔧 새로운 자산 클래스의 등장

프롬프트가 단순한 입력값을 넘어 지식재산권으로 취급되기 시작했습니다.

실제로 프롬프트 유출이 "핵심 영업비밀 도용" 관련 소송으로 다뤄지기도 합니다.
잘 만들어진 시스템 프롬프트는 이제 소프트웨어 코드와 마찬가지로 기밀로 관리됩니다.
또 흥미로운 건 프롬프트 마켓플레이스가 생겨나고 있다는 점입니다.

PromptBase 같은 곳에서 검증된 프롬프트를 사고팔 수 있다고합니다. 말 그대로 프롬프트가 거래 가능한 자산이 된 거죠.
어떤 프롬프트가 사고 팔리는지 한번 구경은 해보세요!!


⚙️ 생각보다 복잡한 관리

그런데 프롬프트 관리가 생각보다 까다롭습니다.

하나 예로 들어보면 모델 호환성이에요. GPT-3.5에 최적화된 프롬프트가 GPT-4에서는 제대로 작동하지 않을 수 있거든요.
모델이 업데이트될 때마다 기존 프롬프트를 재검증하고 수정해야 합니다.

다국어 환경은 더 복잡합니다. LLM이 주로 영어 데이터로 학습되다 보니 번역된 프롬프트의 성능이 현저히 떨어집니다.
단순 번역이 아닌 문화적 현지화가 필요한데, 이는 각 지역별로 별도의 프롬프트 버전을 관리해야 한다는 뜻이죠.

보안도 신경 써야 합니다. 프롬프트 주입 공격으로 시스템 프롬프트가 유출될 수 있거든요. 가치 있는 자산인 동시에 공격 경로가 되는 이중적 특성이 있어요.


🚀 새로운 패러다임의 시작

개인적으로 제가 현업에서 느끼는 가장 흥미로운 변화는 프롬프트가 코드와 분리되어 관리되기 시작했다는 점입니다.

점점 그렇게 바뀌고 있어요..

예전에는 프롬프트를 코드 안에 하드코딩했지만, 이제는 별도 파일로 관리하고 버전 관리 시스템을 적용합니다.
마치 데이터베이스 스키마나 설정 파일처럼 취급하는 거죠.
A/B 테스팅도 도입되고 있어요. 서로 다른 프롬프트 버전의 성능을 측정하고 최적화하는 과정이 제품 개발의 핵심이 되었습니다.

이는 소프트웨어 개발 패러다임 자체가 바뀌고 있다는 신호라고 생각합니다. 코딩 실력만큼이나 "AI와 소통하는 능력"이 중요해진 시대가 온 거죠.

하지만 아무리 좋은 프롬프트 템플릿을 만들어도 여전히 한계가 있습니다. 바로 "더 나은 성능을 위해서는 어떻게 해야 하는가"라는 문제죠.

다음 편에서는 최소 비용으로 최대 성능 향상을 달성하는 N샷 프롬프팅의 마법에 대해 다뤄보겠습니다.

---

여러분의 좋아요와 공유는 사랑입니다 🥰
#BQ개발자 #LLM애플리케이션 #프롬프트템플릿 #AIEngineering

📌 LLM 어플리케이션 3편: N샷 프롬프팅 - 예시가 만드는 패턴 학습의 마법

안녕하세요, BQ개발자입니다.

지난 편에서 프롬프트 템플릿으로 일관성은 확보했다고 했는데요, 이제 다음 단계 고민이 생깁니다.

📱LLM 애플리케이션이 단순 API 호출로 끝나지 않는 이유
📱LLM 어플리케이션 1편: 세이프티 필터
📱LLM 어플리케이션 2-1편: 똑같은 LLM, 다른 결과
📱LLM 어플리케이션 2-2편: 프롬프트 템플릿 - 코드보다 중요한 새로운 자산

"같은 모델로 어떻게 더 좋은 성능을 낼 수 있을까?"

오늘은 이 내용에 대해 다뤄보겠습니다!

🤔 N샷 프롬프팅이 뭘까?

- Zero-shot: 예시 없이 그냥 질문만 던지기
- Few-shot (N-shot): 예시 몇 개 주고 질문하기

"샷(shot)"은 "한 번의 시도"를 의미해요. 머신러닝에서 "적은 데이터로 학습"을 표현할 때 사용됩니다.

--

⚡ 같은 GPT-4, 극명하게 갈리는 성능

A회사 (Zero-shot): "경제 뉴스를 3줄로 요약해줘"

→ 결과: 때로는 6줄, 때로는 1줄... 매번 다른 스타일

이렇게 하는 회사와

B회사 (Few-shot):

예시 1: "한국 GDP 성장률 발표" → "한국 경제가 3분기 전년비 2.1% 성장. 제조업과 서비스업이 주도했으며, 수출 증가도 기여."
예시 2: "중앙은행 금리 정책" → "기준금리 0.25%p 인하로 2.5% 조정. 경기 부양 목적이며, 대출금리 하락 예상."
실제 질문: "오늘 경제 뉴스를 3줄로 요약해줘"
→ 결과: 항상 "핵심 사실 + 주요 원인 + 예상 영향" 구조로 완벽하게 정리

위 두회사의 차이 보이시나요? 같은 GPT-4, 같은 질문인데 완전히 다른 결과를 낳습니다. 왜그럴까요?


🧠 예시가 극적 변화를 만드는 진짜 이유

핵심은 LLM의 패턴 인식 메커니즘에 있습니다.

LLM은 본질적으로 "패턴 매칭 엔진"입니다. 문제는 하나의 질문이 수천 가지 패턴과 매칭될 수 있다는 점이에요.

"경제 뉴스 요약해줘"라는 요청에 가능한 패턴들:
- 학술 논문 스타일 vs 신문 헤드라인 스타일
- SNS 포스팅 스타일 vs 정부 보고서 스타일

모두 가능한 선택지라서 매번 다른 결과가 나오는 거죠.

하지만 예시가 주어지면?

LLM은 더 이상 수천 가지 패턴 중에서 고민하지 않습니다. 구체적인 타겟 패턴을 찾게 되거든요.

예시들이 "핵심 사실 + 주요 원인 + 예상 영향" 구조를 보여주면, LLM은 학습 데이터에서 정확히 이 패턴과 일치하는 사례들을 찾아냅니다. 검색 범위가 수천 개에서 수십 개로 좁혀지는 거예요.


🎯 일관성 있는 유연함의 비밀

N샷 프롬프팅의 진짜 마법은 LLM이 예시에서 공통점과 차이점을 동시에 학습한다는 점입니다.

- 공통점: 지켜야 할 규칙 (구조, 톤, 길이)
- 차이점: 유연하게 바뀔 부분 (구체적 내용, 용어)

이게 바로 "일관성 있는 유연함"을 만드는 핵심이죠.

💡 팁: 벡터 유사도를 활용해 과거 질문-답변 쌍에서 자동으로 최적 예시를 선택하는 시스템을 구축하면 더욱 효과적이라고

합니다.


🚀 최소 투자, 최대 성과

모델 파인튜닝도, 새로운 인프라도 필요 없이, 그냥 좋은 예시 몇 개만으로도 성능을 극적으로 개선할 수 있어요.

하지만 새로운 고민이 생깁니다. 예시 때문에 토큰 비용이 3-5배 증가했다면?

다음 편에서는 이 딜레마를 해결하는 "LLM 선택과 캐시 전략"에 대해 다뤄보겠습니다.

---

여러분의 좋아요와 공유는 사랑입니다 🥰

#BQ개발자 #LLM애플리케이션 #N샷프롬프팅 #AIEngineering

📌 LLM 어플리케이션 4-1편: LLM 선택 - 완벽한 모델은 없다

안녕하세요, BQ개발자입니다.

📱LLM 어플리케이션 3편: N샷 프롬프팅 - 예시가 만드는 패턴 학습의 마법

지난 편에서 N샷 프롬프팅으로 성능은 확보했다고 했는데요, 이제 새로운 고민이 생깁니다.

"성능은 좋아졌는데 비용이 너무 나온다면?"

🤔 GPT-4가 최고라면서 왜 모든 회사가 안 쓸까?

이상한 현상이 벌어지고 있습니다.

GPT-4가 가장 똑똑하다고 모두가 인정하는데, 실제 현장에서는 다른 모델들을 쓰는 회사가 더 많아요.
심지어 GPT-3.5나 클로드를 쓰는 곳도 많고, 파인튜닝된 작은 모델을 쓰는 곳도 있습니다.

왜일까요?

⚡ "최고 모델"이라는 착각

핵심은 "완벽한 모델은 없다"는 점입니다.

모든 LLM은 서로 다른 강점과 약점을 가지고 있어요.
GPT-4가 정확하지만 비싸고 느리다면, 간단한 FAQ 응답에는 과잉입니다.

실제 사례를 보겠습니다:

실시간 고객상담

: 빠른 응답이 중요 → 정확성보다 속도 우선

창의적 콘텐츠

: 최고 품질이 중요 → 비용보다 성능 우선

대량 데이터 처리

: 비용 효율성이 중요 → 성능보다 가격 우선

같은 "텍스트 생성"이라도 요구사항이 완전히 다른 거죠.


🧠 다차원 최적화의 현실

LLM 선택을 "성능 순위"로 접근하면 실패합니다. 실제로는 여러 축의 복잡한 균형을 맞춰야 해요.

정확성 vs 비용:
GPT-4는 정확하지만 비쌉니다. 단순한 작업에는 GPT-3.5로도 충분할 수 있어요.

속도의 두 얼굴:
첫 응답 시간(TTFT)과 전체 완료 시간(TPOT)은 다릅니다. 실시간 채팅에서는 첫 응답이 빨라야 하고, 긴 문서 작성에서는 전체 시간이 중요하죠.

컨텍스트 윈도우:
긴 문서를 한 번에 처리할 수 있지만, 그만큼 비용도 증가합니다.

물리적 한계:
아무리 좋은 모델이라도 용량 제한이 있어요. 429 Rate Limit Error는 단순한 일시적 문제가 아니라 GPU 자원의 물리적 한계입니다.


🎯 상황별 최적화만 있을 뿐

결국 "어떤 모델이 최고인가?"는 잘못된 질문입니다. 올바른 질문은 "이 상황에서 무엇이 최적인가?"예요.

더 영리한 회사들은 하이브리드 전략을 씁니다:
- 간단한 질문: 빠르고 저렴한 모델
- 복잡한 요청: 고성능 모델로 라우팅
- 반복 작업: 캐시나 파인튜닝 활용


🚀 트레이드오프를 받아들이는 지혜

LLM 선택의 핵심은 무엇을 포기할 것인가를 명확히 하는 것입니다.

완벽함을 추구하면 비용이 폭발하고, 비용만 고려하면 품질이 떨어집니다. 중요한 건 의식적인 선택이에요.

무엇을 얻기 위해 무엇을 포기하는지 명확히 알고 결정하는 거죠.

💡

팁

: 용도별로 모델을 분리해서 사용하면 전체 비용 대비 성능을 크게 개선할 수 있습니다.

하지만 모델을 잘 선택해서 비용을 관리했는데, 같은 질문에 같은 답변을 계속 반복한다면?

다음 편에서는 "캐시"에 대해 다뤄보겠습니다.

---

여러분의 좋아요와 공유는 사랑입니다 🥰

#BQ개발자 #LLM애플리케이션 #LLM선택 #AIEngineering

📌 LLM 어플리케이션 4-2편: 캐시 - 똑똑하게 캐슁하는법

안녕하세요, BQ개발자입니다.

지난 편에서 상황별 최적 모델 선택으로 비용은 관리했다고 했는데요, 이제 또 다른 고민이 생깁니다.

📱LLM 어플리케이션 4-1편: LLM 선택 - 완벽한 모델은 없다

"같은 질문이 계속 들어온다면 매번 새로 계산할 필요가 있을까?"

🤔 당연해 보이는 최적화가 재앙이 되는 순간

개발자라면 누구나 생각하는게 바로 최적화입니다.

"한국 맛집 추천해줘"라는 질문이 하루에 100번 들어온다면, 첫 번째 답변을 캐시해두고 나머지 99번은 바로 반환하면 되지 않을까요?

비용도 1/100로 줄고, 응답 속도도 극적으로 빨라집니다. 완벽한 최적화처럼 보이죠.

하지만 실제로는 사용자 경험이 망가집니다.

⚡ 같은 답변이 오히려 위험한 이유

핵심 문제는 LLM의 본질적 특성과 사용자 기대의 불일치입니다.

문제 1: 미묘한 차이의 무시
- "한국 맛집 5개"와 "한국 맛집 10개"는 벡터 공간에서 거의 동일하게 처리됩니다. 문맥적 유사도가 매우 높거든요.
- 그래서 캐시 히트가 발생하고, 10개를 요청했는데 5개만 받게 되는 황당한 상황이 벌어져요.

문제 2: LLM의 비결정적 특성 파괴
- LLM은 같은 입력에도 매번 다른 답변을 만들어냅니다. 이건 버그가 아니라 **의도된 설계**예요.
- 확률적 샘플링을 통해 다양성과 창의성을 확보하는 거죠. 특히 창의적 글쓰기나 브레인스토밍에서는 이런 다양성이 핵심 가치입니다.

"마케팅 아이디어 10개"를 요청했을 때, 매번 같은 답변이 나온다면 AI를 쓸 이유가 없어요.

🧠 왜 이런 함정에 빠질까?

전통적인 소프트웨어에서는 같은 입력 = 같은 출력이 당연했습니다. 함수의 기본 원리니까요.

하지만 LLM은 다릅니다. 확률 기반 시스템이거든요. 매번 조금씩 다른 경로로 답변을 생성하면서, 그 다양성 자체가 가치인 경우가 많아요.

캐시는 이런 본질적 특성을 완전히 무시해버립니다. LLM을 일반적인 결정론적 함수처럼 취급하는 거죠.


🎯 더 영리한 접근: 컨텍스트 캐싱

그럼 캐시를 아예 포기해야 할까요? 그건 또 아닙니다. 무엇을 캐시할 것인가의 문제예요.

전체 질문-답변을 캐시하는 대신, 변하지 않는 공통 부분만 캐시하는 방법이 있습니다.

예시: 파이썬 프로그래밍 질문에 답하기 위해 매번 파이썬 매뉴얼 전체를 프롬프트에 포함한다고 가정해봅시다.

기존 방식

: 매뉴얼 + 질문 전체를 매번 새로 처리

컨텍스트 캐싱

: 매뉴얼 부분은 캐시하고, 질문 부분만 새로 처리

매뉴얼은 질문이 바뀌어도 동일하니까, 이 부분만 재사용하는 거예요. 답변의 다양성은 유지하면서도 비용은 절약할 수 있습니다.


🚀 의식적 선택의 중요성

결국 캐시는 일관성과 창의성 사이의 트레이드오프입니다.

- FAQ 응답: 일관성이 중요 → 캐시 적용
- 창의적 콘텐츠: 다양성이 중요 → 캐시 지양

무엇을 얻기 위해 무엇을 포기할 것인지 의식적으로 선택하는 게 핵심이에요.

💡 팁: 캐시 적용 전에 해당 작업이 "일관성 vs 창의성" 중 어느 쪽이 더 중요한지 먼저 판단하는것

추천합니다!


하지만 여기까지 해도 또 다른 문제가 남습니다. "AI가 어제 우리가 얘기한 거 기억 안 나?"

다음 편에서는 "메모리 - AI는 어떻게 기억하는가"를 다뤄보겠습니다.

---

여러분의 좋아요와 공유는 사랑입니다 🥰

#BQ개발자 #LLM애플리케이션 #캐시전략 #AIEngineering

📌 LLM 어플리케이션 5-1편: 메모리 - LLM은 본질적으로 건망증 환자다

안녕하세요, BQ개발자입니다.

지난 편에서 캐시로 비용은 관리했다고 했는데요, 이제 더 근본적인 문제가 남습니다.

📱LLM 어플리케이션 4-2편: 캐시 - 똑똑함의 함정

"어제 우리가 얘기한 거 기억 안 나?"

🤔 똑똑한 AI가 기억 못 하는 황당한 상황

실제 사용자들이 가장 당황하는 순간입니다.

사용자: "어제 말한 그 프로젝트 일정 어떻게 됐지?"
AI: "죄송합니다. 어떤 프로젝트를 말씀하시는지 모르겠습니다."

사용자: "아까 추천해준 맛집 중에서 2번째 거 주소 알려줘"
AI: "어떤 맛집을 말씀하시는 건지 구체적으로 알려주세요."

GPT-4처럼 똑똑한 AI가 왜 이렇게 건망증에 걸린 것처럼 다 잊어버릴까요?



⚡ LLM은 본질적으로 상태가 없다

핵심은 LLM의 근본적 아키텍처에 있습니다.

LLM은 상태가 없는(stateless) 시스템입니다. 매번 완전히 백지상태에서 시작해요. 이전 대화가 있었다는 사실 자체를 모릅니다.

인간은 뇌에 기억이 축적되지만, LLM은 각 요청을 완전히 독립적으로 처리합니다. 마치 매번 처음 만나는 사람처럼 대화하는 거죠.

이건 버그가 아닙니다. 의도된 설계예요.



🧠 왜 이렇게 설계했을까?

1. 자원의 물리적 한계
상태를 유지하려면 모든 사용자의 모든 대화를 메모리에 계속 보관해야 합니다. 전 세계 수백만 명이 동시에 사용하는 상황에서 이는 불가능해요.

2. 동시 처리의 복잡성
상태가 있으면 한 사용자의 요청을 처리하는 동안 다른 요청을 처리하기 어려워집니다. 각 사용자별로 별도의 상태를 관리해야 하거든요.

3. 확장성의 한계
상태 없는 시스템은 수평 확장이 쉽습니다. 어떤 서버에서든 요청을 처리할 수 있거든요. 하지만 상태가 있으면 특정 서버에 묶이게 됩니다.


🎯 컨텍스트 윈도우라는 임시방편

"그럼 이전 대화를 계속 포함시키면 되잖아?"라고 생각할 수 있습니다.

실제로 ChatGPT 같은 서비스가 이 방법을 씁니다. 새로운 질문할 때마다 이전 대화 히스토리를 모두 포함시키는 거죠.

하지만 컨텍스트 윈도우의 물리적 한계에 부딪힙니다.

- GPT-4.1: 1M 토큰 (소설 1권 분량)
- Claude: 200K 토큰 (보고서 50페이지 분량)
- Gemini: 1M 토큰 (소설 1권 분량)

언뜻 많아 보이지만, 실제 대화는 금세 이 한계를 넘어버려요. 긴 대화를 나누거나, 문서를 포함한 대화를 하다 보면 토큰이 빠르게 소진됩니다.

더 심각한 건 비용입니다.

대화가 길어질수록 매번 포함시켜야 하는 토큰이 기하급수적으로 증가해요.

1번째 질문: "안녕"
2번째 질문: "안녕" + "오늘 뭐해?"
3번째 질문: "안녕" + "오늘 뭐해?" + "날씨는?"

10번 대화하면 수백 단어, 100번 대화하면 수만 단어를 매번 다시 읽어야 합니다. 비용 폭탄이죠!

💸

🚀 건망증을 받아들이는 지혜

결국 LLM의 건망증은 근본적 한계입니다. 이를 완전히 해결하는 건 불가능해요.

중요한 건 이 한계를 인정하고 설계에 반영하는 것입니다.
사용자에게 매번 컨텍스트를 제공하도록 유도하거나, 중요한 정보는 별도로 저장해서 필요할 때 제공하는 방식으로 우회해야 하죠.

💡 팁: 사용자가 "이전에 말한"을 언급하면서 구체적으로 다시 설명해달라고 요청하세요.

하지만 여기서 새로운 질문이 생깁니다. "그럼 AI는 어떻게 기억을 관리해야 할까?"

다음 편의 제목은 "AI의 기억은 검색 가능한 구조화된 정보다"입니다 ㅎㅎ 기대해주세요!

---

여러분의 좋아요와 공유는 사랑입니다 🥰

#BQ개발자 #LLM애플리케이션 #AI메모리 #AIEngineering

📌 LLM 어플리케이션 5-2편: 메모리 - AI의 기억은 검색 가능한 구조화된 정보다

안녕하세요, BQ개발자입니다.

지난 편에서 LLM이 본질적으로 건망증 환자라는 이야기를 했는데요, 그럼 이 문제를 어떻게 해결할까요?

📱LLM 어플리케이션 5-1편: 메모리 - LLM은 본질적으로 건망증 환자다

"AI는 어떻게 기억을 관리해야 할까?"

🤔 인간의 기억 vs AI의 기억

인간의 기억은 자연스럽게 떠오릅니다. "아, 그때 그랬지" 하면서 연관된 기억들이 줄줄이 따라오죠.

하지만 AI는 다릅니다. 기억이 자동으로 떠오르지 않아요.

AI에게 기억은 "필요할 때 찾아서 사용하는 정보"입니다.
인간처럼 자연스럽게 연상되는 게 아니라, 검색해서 가져와야 하는 데이터예요.


⚡ 계층적 메모리 시스템의 필요성

그래서 AI에는 계층적 메모리 시스템이 필요합니다.

단기 메모리 (현재 세션):
현재 대화의 최근 몇 번 교환만 유지합니다. "방금 전에 말한 것" 정도의 맥락은 유지하는 거죠.

장기 메모리 (압축된 과거):
과거 대화의 핵심 내용만 저장합니다. 하지만 여기서 중요한 게, 단순한 대화 로그가 아니라는 점이에요.


🧠 단순 요약이 아닌 구조화된 지식 추출

핵심은 "무엇을 어떻게 저장할 것인가"입니다.

대화 내용을 그대로 저장하면 검색이 어렵고, 단순히 요약하면 중요한 정보가 손실됩니다.

대신 구조화된 지식 추출이 필요해요:

사용자 선호사항:
- "매운 음식 싫어함"
- "오전 회의 선호"
- "간단명료한 답변 원함"

중요한 결정사항:
- "A안으로 진행하기로 함"
- "예산은 100만원으로 확정"
- "다음 주까지 완료 목표"

반복되는 패턴:
- "매주 월요일마다 일정 관련 질문"
- "특정 프로젝트에 대한 지속적 관심"


🔍 의미적 검색의 복잡성

저장하는 것도 어렵지만, 검색하는 것은 더 까다롭습니다.

"예전에 날씨에 대해 얘기했던 것" 같은 모호한 참조를 처리해야 하거든요.

단순한 키워드 검색으로는 해결되지 않습니다. "날씨 → 우산 → 비 → 외출 계획"처럼 연관된 개념들을 추적해야 해요.

여기서 벡터 유사도 검색이 중요해집니다. 키워드가 정확히 일치하지 않아도 의미적으로 관련된 정보를 찾을 수 있거든요.


🎯 검색 가능한 형태로 재구성

결국 AI의 "기억"은 검색 가능한 형태로 정보를 재구성하는 것입니다.

이는 전통적인 데이터베이스와도 다릅니다:
- 데이터베이스: 정확한 매칭
- AI 메모리: 의미적 연관성으로 검색

또 인간의 기억과도 다릅니다:
- 인간: 자연스러운 연상
- AI: 능동적 검색과 조합

🚀 기억의 재정의

정리하면 AI에게 기억은 과거 정보를 현재 맥락에 적절히 연결하는 능력입니다.

단순히 많이 저장하는 게 아니라, 필요한 순간에 적절한 정보를 찾아서 현재 상황에 맞게 제공하는 것이 핵심이죠.

하지만 내부 기억을 아무리 잘 관리해도, 또 다른 문제가 남습니다. "AI가 우리 회사 내부 문서는 어떻게 알지?"

다음 편에서는 "RAG - 똑똑한 AI도 회사 문서를 모르는 이유"를 다뤄보겠습니다.

---

여러분의 좋아요와 공유는 사랑입니다 🥰

#BQ개발자 #LLM애플리케이션 #AI메모리시스템 #AIEngineering