📌 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

📌 LLM 어플리케이션 6편: RAG - LLM에게 참고서를 주기

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

지난 편에서 AI의 기억을 구조화된 검색 시스템으로 관리한다고 했는데요, 이제 더 근본적인 문제가 남습니다.

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

"우리 회사 내부 문서는 AI가 어떻게 알지?"

🤔 똑똑한 GPT-4도 모르는 것들

아무리 똑똑한 AI도 이런 건 모릅니다:

사용자: "우리 회사 휴가 규정이 어떻게 돼?"
AI: "죄송합니다. 특정 회사의 내부 규정은 알 수 없습니다."

사용자: "어제 발표된 신제품 스펙 알려줘"
AI: "최신 정보는 제가 알지 못합니다."

왜일까요? GPT-4가 덜 똑똑해서가 아닙니다. 애초에 학습하지 않은 정보는 알 수가 없거든요.


⚡ RAG가 뭐길래 모두가 쓸까?

RAG는 Retrieval-Augmented Generation의 약자입니다.

쉽게 말하면 LLM이 답변하기 전에 관련 문서를 먼저 찾아서 참고하는 방식입니다.

마치 시험 볼 때 오픈북으로 보는 것과 같아요. 모든 걸 외울 필요 없이, 필요한 순간에 책을 찾아보면 되는 거죠.


🧠 단순해 보이지만 혁명적인 아이디어

RAG의 작동 방식은 간단합니다:

1. 사용자가 질문을 합니다
2. 질문과 관련된 문서를 검색합니다
3. 찾은 문서를 LLM에게 같이 전달합니다
4. LLM이 문서를 참고해서 답변합니다

"그냥 검색 아니야?"라고 생각할 수 있지만, 핵심은 검색과 생성의 결합입니다.

전통적인 검색은 문서를 그대로 보여주지만, RAG는 찾은 정보를 바탕으로 새로운 답변을 생성합니다.
여러 문서의 정보를 종합하고, 질문에 맞게 재구성해서 답변하는 거죠.


🎯 키워드 검색을 넘어서는 의미적 검색

RAG의 진짜 마법은 의미적 검색에 있습니다.

예를 들어 "휴가 정책"을 검색할 때:
- 키워드 검색: "휴가", "정책"이라는 단어가 있는 문서만 찾음
- 의미적 검색: "연차", "휴가", "time off", "연가" 등 관련 개념 모두 찾음

사용자가 "쉬는 날 규정"이라고 물어도 "휴가 정책" 문서를 찾을 수 있는 거예요. 단어가 달라도 의미가 같으면 찾아냅니다.

이게 가능한 이유는 임베딩이라는 기술 때문입니다. 텍스트를 의미를 담은 숫자 벡터로 변환해서, 의미적 유사도를 계산할 수 있거든요.


🚀 회사 지식을 AI에 주입하는 방법

RAG를 통해 이런 게 가능해집니다:

- 항상 최신 정보: 문서만 업데이트하면 AI도 자동으로 최신 정보 제공
- 회사별 맞춤형: 각 회사의 고유한 정보와 규정 반영
- 보안 유지: 민감한 정보는 내부에 보관하면서도 AI 활용 가능

전체 LLM을 재학습시킬 필요 없이, 필요한 문서만 검색 가능하게 만들면 됩니다. 비용도 절약되고 유연성도 높아지죠.

RAG는 LLM이 "모르는 것을 아는 것처럼" 만드는 게 아니라, "필요한 정보를 찾아서 활용하도록" 하는 시스템입니다.

하지만 여기서 새로운 질문이 생깁니다. "의미적 검색이 어떻게 가능한 거지?"

다음 편에서는 "임베딩 - 의미를 숫자로 바꾸는 기술"에 대해 다뤄보겠습니다.

---

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

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

📌 LLM 어플리케이션 7편: 임베딩 - 의미를 숫자로 바꾸는 기술

BQ개발자입니다.

지난 편에서 RAG가 의미적 검색을 통해 작동한다고 했는데요, 컴퓨터가 어떻게 의미를 이해할 수 있을까요?

📱LLM 어플리케이션 6편: RAG - LLM에게 참고서를 주기

"'휴가'와 '연차'가 비슷하다는 걸 컴퓨터가 어떻게 알지?"

🤔 컴퓨터는 숫자만 이해한다

먼저 근본적인 사실부터 짚고 가겠습니다.

컴퓨터는 텍스트를 직접 이해할 수 없습니다. 오직 숫자만 처리할 수 있어요.
그래서 텍스트를 어떻게든 숫자로 바꿔야 합니다.

전통적인 방법은 단순했습니다:
- "휴가" = 1번
- "연차" = 2번
- "프로젝트" = 3번

하지만 이 방식으로는 단어들 사이의 관계를 표현할 수 없어요. 1번과 2번이 비슷한지, 다른지 알 수 없으니까요.


⚡ 임베딩: 의미를 담은 숫자 표현

임베딩은 이 문제를 해결하는 똑똑한 방법입니다.

단순히 번호를 매기는 대신, 여러 개의 숫자를 조합해서 의미를 표현합니다.

예를 들어:
- "휴가": [0.2, -0.5, 0.8, 0.3, ...]
- "연차": [0.3, -0.4, 0.7, 0.2, ...]
- "프로젝트": [-0.6, 0.9, -0.2, 0.5, ...]

🧠 이 숫자들은 어떻게 만들어질까?

핵심은 예측 과제를 통한 자동 조정입니다.

시작: 모든 단어에 랜덤 숫자 부여
- "휴가": [0.1, 0.1, 0.1, 0.1, ...]
- "연차": [-0.2, 0.3, -0.1, 0.2, ...]
- "프로젝트": [0.2, -0.1, 0.3, -0.3, ...]

과제: 빈칸 채우기
"오늘은 휴가를 ___했다"에서 다음 단어 예측하기

알고리즘은 각 단어의 숫자들을 사용해서 계산합니다.
정답이 "신청"인데 "먹"이라고 예측했다면? 오차가 발생합니다.

자동 조정 메커니즘
오차를 줄이기 위해 숫자들이 자동으로 조정됩니다:
- "휴가"의 숫자들을 조금씩 바꿔서 "신청"과 잘 맞도록
- "먹다"의 숫자들을 조금씩 바꿔서 "휴가"와 멀어지도록

참고:
엄밀히는 "휴가를 신청했다"에서 주변 단어 예측이 더 정확하지만,
함께 나타나는 단어들이 비슷한 벡터를 갖게된다는 의미를 단순화한거고,
어차피 저도 잘 모르니 감만 잡으시죠!!

이 과정을 수백만 번 반복하면...

🎯 패턴이 숫자에 새겨진다

"휴가를 신청했다"
"연차를 신청했다"
"휴가를 즐겼다"
"연차를 사용했다"

이런 문장들을 계속 학습하면서:
- "휴가"와 "연차"는 비슷한 위치에 나타남 → 비슷한 조정을 받음 → 비슷한 숫자가 됨
- "프로젝트"는 다른 위치에 나타남 → 다른 조정을 받음 → 다른 숫자가 됨

결과적으로:
- "휴가": [0.2, -0.5, 0.8, ...]
- "연차": [0.3, -0.4, 0.7, ...] ← 비슷한 패턴
- "프로젝트": [-0.6, 0.9, -0.2, ...] ← 전혀 다른 패턴

각 숫자가 무엇을 의미하는지는 알 수 없습니다. 하지만 비슷한 곳에 나타나는 단어들이 비슷한 숫자를 갖게 되는 자연스러운 결과가 나타납니다.

🚀 거리로 의미를 측정하는 이유

이제 단어 간 거리를 계산하면:
- "휴가" - "연차": 작은 차이
- "휴가" - "프로젝트": 큰 차이

이 거리가 곧 의미의 차이를 나타내게 됩니다.
비슷한 문맥에서 쓰이는 단어들이 자연스럽게 가까운 숫자를 갖게 되었으니까요.

💡 요약:

임베딩은 "단어의 사용 패턴이 자동으로 숫자에 인코딩된 결과"입니다.
마법이 아니라 수학적 최적화의 결과예요.

하지만 여기서 새로운 문제가 생깁니다. "책 한 권 분량의 긴 문서는 어떻게 처리하지?"

다음 편에서는 "청킹 - 긴 글을 어떻게 나눌 것인가"에 대해 다뤄보겠습니다.

---

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

#BQ개발자 #LLM애플리케이션 #임베딩 #AIEngineering

📌 LLM 어플리케이션 8편: 청킹 - 긴 글을 어떻게 나눌 것인가

BQ개발자입니다.

지난 편에서 임베딩으로 텍스트의 의미를 벡터로 변환할 수 있다고 배웠습니다.
이제 RAG 시스템을 만들어볼까요?

📱LLM 어플리케이션 7편: 임베딩 - 의미를 숫자로 바꾸는 기술


🔍 RAG의 데이터 흐름

먼저 RAG가 어떻게 작동하는지 봅시다.

1. 문서 저장: "인사규정.pdf" → 임베딩 → 벡터 DB에 저장
2. 질문 처리: "연차 몇 개야?" → 임베딩 → 질문 벡터 생성
3. 검색: 질문 벡터와 가장 유사한 문서 벡터 찾기
4. 답변: 찾은 문서를 LLM에 전달 → 답변 생성

간단해 보이죠?
그런데 1번 단계에서 중요한 결정을 해야 합니다.

"문서를 어떤 단위로 저장할 것인가?"

⚠️ 청킹 없이 그냥 저장하면?

100페이지짜리 인사규정을 통째로 하나의 벡터로 만들었다고 가정해봅시다.

사용자: "신입사원 연차 몇 개야?"

RAG 시스템:
1. 질문을 벡터로 변환
2. 가장 유사한 문서 검색 → "인사규정.pdf" (100페이지 전체)
3. LLM에게 전달: "이 100페이지에서 신입사원 연차를 찾아서 답해줘"

결과:
- LLM이 100페이지를 다 읽어야 함 (비용 폭발)
- 토큰 한계 초과로 처리 불가능
- 설령 처리해도 답변 정확도 떨어짐

이래서는 검색이 무의미합니다.


🤔 청킹(Chunking)이란?

청킹은 긴 문서를 검색 가능한 작은 단위로 나누는 과정입니다.

100페이지를 적절히 나누면:
- 3페이지: 근무시간 규정
- 4페이지: 연차 규정 ← 이것만 검색됨
- 5페이지: 병가 규정
...

이제 질문과 관련된 부분만 정확히 찾을 수 있습니다.


⚡ 정보의 원자성 vs 맥락성

청킹은 두 가지 상충하는 요구사항 사이의 균형입니다.

원자성 (Atomicity)
- 각 청크가 하나의 명확한 정보를 담아야 함
- 작을수록 검색 정확도 향상
- 하지만 맥락 없이는 의미가 불완전

맥락성 (Context)
- 정보를 이해하는 데 필요한 배경 포함
- 클수록 이해도 향상
- 하지만 불필요한 정보로 인한 노이즈 증가

최적의 청킹은 이 둘 사이의 균형점을 찾는 것입니다.


📏 청킹 방법론의 진화

1. 고정 크기 청킹
- 300자, 500자 등 일정 크기로 자르기
- 문제: 문장이나 단어가 중간에 잘림
- "...연차는 15일이며, 2년차부터는 매년 1일씩 추|"

2. 재귀적 청킹
- 우선순위: 문장 → 절 → 단어 경계
- 의미 단위를 최대한 보존
- 크기 제한도 지키면서 가독성 확보

3. 의미 기반 청킹
- 문서의 논리적 구조 활용 (제목, 단락, 섹션)
- 주제가 바뀌는 지점에서 분할
- 자연스러운 의미 단위 유지


🎯 고급 청킹 전략

부모-자식 청킹 (Parent-Child)

핵심 아이디어: 검색과 제공을 분리

자식 청크 (검색 최적화):
- "신입사원의 연차는 15일입니다."
- 작고 구체적, 정확한 매칭 가능

부모 청크 (답변 최적화):
- 자식 청크 + 주변 맥락
- "신입사원의 연차는 15일입니다. 2년차부터는..."
- 완전한 정보 제공

스몰-투-빅 (Small-to-Big)

검색된 청크의 앞뒤 문맥을 자동 포함:
- 핵심: "연차는 15일입니다."
- 제공: [이전 문장] + 핵심 + [다음 문장]
- 자연스러운 흐름 유지


💡 청킹이 RAG 성능을 좌우하는 이유

임베딩은 의미를 수치화하는 기술이지만,
청킹은 어떤 의미를 수치화할지 결정하는 요소입니다.

같은 정보도 청킹에 따라:
- "15일" → 의미 없는 숫자
- "신입사원 연차 15일" → 명확한 정보

RAG의 품질은 임베딩 모델보다 청킹 전략에 더 의존합니다.
검색의 정밀도와 답변의 완전성이 여기서 결정되기 때문입니다.

정보를 어떻게 구조화하고 보존할 것인가.
이것이 청킹의 본질입니다.


이렇게 오늘은 지식을 효과적으로 저장하고 검색하는 방법을 배웠습니다.
다음은 이 지식을 활용해 능동적으로 사고하는 시스템, 에이전트를 알아보겠습니다!

---

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

#BQ개발자 #LLM애플리케이션 #청킹 #AIEngineering

📌 LLM 어플리케이션 9편: 에이전트 - 생각하는 AI의 탄생

BQ개발자입니다.

지금까지의 LLM은 질문을 받으면 바로 답변했습니다.
하지만 모르는 걸 물어보면? 그냥 틀린 답을 하거나 "모르겠습니다"라고 할 뿐이었죠.

그런데 만약 LLM이 스스로 정보를 찾아볼 수 있다면 어떨까요?

📱LLM 어플리케이션 8편: 청킹 - 긴 글을 어떻게 나눌 것인가


🤖 에이전트가 뭔가요?

에이전트는 "스스로 생각하고 행동하는 LLM"을 의미합니다.

일반 LLM 사용자: "2023년 PGA 챔피언의 고향은?"
LLM: "죄송합니다. 그 정보는 모릅니다."

에이전트 사용자: "2023년 PGA 챔피언의 고향은?"
에이전트: (스스로 검색해서 답을 찾아옴) "2023년 PGA 챔피언은 브룩스 켑카이며, 플로리다주 웨스트팜비치 출신입니다."

어떻게 이게 가능할까요?


🧠 ReAct 패턴: 생각하고, 행동하고, 관찰하라

ReAct는 Reasoning(추론) + Acting(행동)의 줄임말입니다.

핵심은 세 단계의 반복입니다:

1. Thought (생각): 무엇을 해야 할지 추론
2. Action (행동): 실제로 도구를 사용해 행동
3. Observation (관찰): 행동의 결과를 확인

이 세 단계가 계속 순환하면서 문제를 해결합니다.


📝 실제로 어떻게 작동하는지 봅시다

"2023년 PGA 챔피언의 고향을 알려줘"라는 질문을 받았을 때:

Thought: "2023년 PGA 챔피언이 누구인지 먼저 알아야겠다."
Action: 구글 검색("2023 PGA 챔피언")
Observation: "브룩스 켑카가 우승자라는 것을 확인했다."

Thought: "이제 브룩스 켑카의 고향을 알아야겠다."
Action: 구글 검색("브룩스 켑카 고향")
Observation: "플로리다주 웨스트팜비치 출신이라는 정보를 얻었다."

Final Answer: "2023년 PGA 챔피언은 브룩스 켑카이며, 그의 고향은 플로리다주 웨스트팜비치입니다."


⚡ 왜 이게 중요한가?

일반 프로그램은 미리 정해진 순서대로만 실행합니다.
하지만 ReAct는 각 단계의 결과를 보고 다음을 결정합니다.

예를 들어:
- 첫 검색에서 "대회 취소"가 나왔다면? → 다른 방향으로 사고 전환
- 검색 결과가 애매하다면? → 다른 검색어로 재시도
- 잘못된 정보를 찾았다면? → 검증을 위한 추가 검색

상황에 따라 적응하는 것, 이게 핵심입니다.


🔄 Think → Act → Observe의 순환

이 패턴이 없다면:
- LLM은 자신의 지식 범위 안에서만 답변
- 틀려도 확인할 방법이 없음
- 추가 정보가 필요해도 얻을 수 없음

ReAct 패턴이 있으면:
- 모르는 건 찾아볼 수 있음
- 틀렸으면 수정할 수 있음
- 필요한 만큼 반복해서 정보를 수집할 수 있음

각 사고가 행동을 만들고, 각 행동의 결과가 다음 사고를 만듭니다.
이 순환이 "지능적 행동"을 가능하게 합니다.


💡 정리: 수동적 대답에서 능동적 문제 해결로

에이전트의 본질은 ReAct 패턴을 통한 자율성입니다.

생각 → 행동 → 관찰 → 다시 생각...

이 순환을 통해 LLM은:
- 단순 질문-답변 기계에서
- 스스로 문제를 해결하는 시스템으로 진화합니다.

인간이 문제를 해결하는 과정과 같은 구조죠. 그래서 우리는 이걸 "에이전트"라고 부릅니다.

하지만 복잡한 작업에는 여러 전문가가 필요합니다. 다음 편에서는 "멀티 에이전트 - AI들의 협업"을 알아보겠습니다.

---

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

#BQ개발자 #LLM애플리케이션 #에이전트 #AIEngineering

📌 LLM 어플리케이션 10편: 멀티 에이전트 - AI들의 협업

BQ개발자입니다.

지난 편에서 에이전트가 스스로 생각하고 행동하는 방법을 배웠습니다.
그런데 실무에서는 더 복잡한 상황에 직면합니다.

📱LLM 어플리케이션 9편: 에이전트 - 생각하는 AI의 탄생


🤔 컨텍스트 희석 문제

"우리 회사 고객 중 최근 3개월간 구매가 줄어든 VIP 고객들에게 맞춤형 마케팅 전략을 수립해줘"

이 요청을 처리하려면 CRM 데이터 조회, 구매 패턴 분석, 마케팅 전략 수립, 개인화 메시지 작성이 모두 필요합니다.

단일 에이전트에게 이 모든 것을 시키면 프롬프트가 이렇게 됩니다:
"너는 CRM 전문가이면서 데이터 분석가이고 마케팅 전략가이며 카피라이터다. CRM 도구는 이렇게 쓰고, 분석은 이렇게 하고, 마케팅은..."

프롬프트가 길어질수록 각 역할의 지시사항이 희석됩니다.
LLM은 모든 역할을 동시에 수행하려다 어느 것도 제대로 못하게 되는거죠.


🤝 컨텍스트 분리를 통한 전문화

멀티 에이전트는 이 문제를 컨텍스트 분리로 해결하려는 방법론입니다.

CRM 전담 에이전트
- 프롬프트: "너는 Salesforce CRM 전문가다. API를 통해 고객 데이터를 조회하고..."
- 오직 CRM 관련 지시사항만 포함

분석 전담 에이전트
- 프롬프트: "너는 고객 행동 분석 전문가다. 구매 패턴을 분석하고..."
- 오직 분석 관련 지시사항만 포함

각 에이전트가 자신의 역할에만 집중하니 훨씬 정확한 결과가 나오는 것을 유도하는거죠.


📊 커맨더 패턴의 작동

중앙 조율 에이전트가 작업을 분배하는 구조를 살펴보겠습니다.

사용자 요청이 들어오면 커맨더 에이전트가 먼저 작업을 분해합니다.
"VIP 고객 데이터가 필요하다" → CRM 에이전트에게 전달
"구매 패턴 분석이 필요하다" → 분석 에이전트에게 전달

CRM 에이전트가 데이터를 추출하면, 그 결과를 분석 에이전트가 받아서 처리합니다.
분석 결과를 바탕으로 마케팅 에이전트가 전략을 수립하게 되구요.

커맨더는 이 모든 과정을 조율하고 최종 결과를 통합합니다.
작업의 순서와 의존성을 관리하는 것이 커맨더의 핵심 역할입니다.


📡 브로드캐스트 패턴의 병렬성

때로는 순차 처리보다 동시 처리가 효율적일때도 있습니다.

"신제품 출시 준비 상황을 점검해줘"

이 요청은 여러 부서의 독립적인 확인이 필요합니다.
모든 에이전트가 동시에 요청을 받고 각자의 영역을 점검합니다.

시장조사 에이전트는 타겟 시장을 분석하고,
가격 에이전트는 가격 전략을 검토하며,
운영 에이전트는 재고와 물류를 확인합니다.

각 에이전트의 답변이 모이면 통합 에이전트가 전체 그림을 그립니다.
순차적으로 처리했다면 30분 걸릴 작업이 5분 만에 완료됩니다.


💬 컨버세이셔널 패턴의 집단 지성

에이전트들이 서로 대화하면서 답을 찾아가는 과정도 있습니다.

코드 리뷰 상황을 생각해보죠.

코드분석 에이전트가 "23번 줄에 null 참조 가능성"을 지적합니다.
보안 에이전트가 "45번 줄의 SQL 인젝션이 더 심각한 문제"라고 반박합니다.
성능 에이전트가 "67번 줄의 루프 구조도 확인 필요"라고 추가합니다.

이때 코드분석 에이전트가 67번 줄을 재검토하고 "종료 조건이 있으니 문제없다"고 정정합니다.
최종 결정 에이전트가 우선순위를 정해 "SQL 인젝션부터 수정"이라고 결론 내립니다.

서로 다른 관점이 충돌하고 조정되면서 더 정확한 답에 도달하는 것이죠.


🎯 프롬프트 충돌이 사라진 이유

단일 에이전트에서 "너는 보안 전문가이면서 성능 전문가"라고 하면,
보안을 위해 검증을 강화하라는 지시와 성능을 위해 검증을 줄이라는 지시가 충돌합니다.

멀티 에이전트에서는 보안 에이전트가 "모든 입력을 검증하라"고 하고,
성능 에이전트가 "캐싱으로 속도를 높여라"고 각자 제안합니다.
조율 에이전트가 "중요 데이터만 검증하고 나머지는 캐싱"이라는 균형점을 찾습니다.

역할이 분리되니 지시사항도 명확해지고, 충돌도 명시적으로 해결됩니다.


🔄 실제 성능 차이

동일한 작업을 수행했을 때의 차이를 보겠습니다.

"우리 회사 내년 사업 계획 수립" 요청에 대해:

단일 에이전트
- 프롬프트 길이: 5,000 토큰 (모든 지시사항 포함)
- 처리 시간: 45초
- 결과: 일반적이고 추상적인 계획

멀티 에이전트
- 각 프롬프트: 500-800 토큰 (역할별 특화)
- 병렬 처리 시간: 15초
- 결과: 부서별 구체적 실행 계획 포함

프롬프트가 짧아지니 각 에이전트가 자신의 역할을 더 잘 이해할 수 있겠죠?.
병렬 처리로 시간도 단축되고, 결과물의 구체성도 높아집니다.


💡 컨텍스트 분리가 만드는 전문성

멀티 에이전트의 본질은 "여러 AI를 쓰는 것"이 아니라고 생각합니다

각 에이전트의 컨텍스트를 분리해서,
하나의 역할에 완전히 집중하게 만드는 거죠.

이렇게 하면 프롬프트 충돌이 사라지고,
각 전문 영역에서 최고의 성능을 발휘한다고해요

결과적으로 전체 시스템의 정확도와 효율성이 모두 향상되구요

인간 조직도 전문가들이 협업할 때 최고의 성과를 내는 것처럼,
AI도 전문화와 협업을 통해 한 단계 높은 지능을 구현하고 있다고 하는데요

그런데 이런 복잡한 협업 과정을 어떻게 체계적으로 관리할 수 있을까요?
다음 편에서는 "오케스트레이션 - 복잡한 워크플로우 관리"를 알아보겠습니다.

---

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

#BQ개발자 #LLM애플리케이션 #멀티에이전트 #AIEngineering

📌 Claude Code가 조용히 느려지는 이유 2편: MCP를 많이 설치할수록 Claude가 할 수 있는 일이 줄어든다

BQ개발자입니다.

지난 편에서 context window가 70%를 넘으면 결과물이 나빠지기 시작한다는 점을 다뤘습니다.
이번에는 작업을 시작하기도 전에 이미 context가 채워져 버리는 원인, MCP에 대해 이야기해보려 합니다.

📱 Claude Code가 조용히 말을 안 듣기 시작할 때 — context 70%의 의미



🤔 도구가 많을수록 똑똑해질까?

파일 시스템, 웹 검색, DB 연결 등 MCP 서버를 많이 등록할수록 Claude의 능력이 확장된다고 생각하기 쉽습니다.
하지만 실제로는 MCP가 늘어날수록 Claude가 오히려 부정확해지는 현상이 발생합니다.


⚡ 도구 정의가 context를 점유하는 '고정 비용'

이유는 Claude Code의 작동 방식에 있습니다.

1. 초기 로딩: Claude Code가 실행되면 등록된 모든 MCP 서버의 '도구 정의(이름, 설명, 파라미터 등)'를 가져와 context에 올립니다.
2. 상시 점유: 도구를 실제로 사용하지 않아도 등록되어 있다는 이유만으로 context를 차지합니다.
3. 비용 누적: MCP 10개를 등록해 도구가 30~50개가 되면, 아무 작업도 안 했는데 이미 context의 30% 정도가 소모됩니다.

결국 지난 편에서 말한 '성능 저하 지점(70%)'까지 남은 여유 공간이 시작부터 줄어드는 구조입니다.


🎯 선택 기준: "무엇을 하는가"보다 "얼마나 가벼운가"

이제 MCP를 고를 때는 기능뿐만 아니라 context 효율성을 따져야 합니다.

예를 들어 exa.ai가 고평가받는 이유는 응답 데이터의 양 때문입니다. 일반 크롤러는 불필요한 HTML 태그까지 다 가져와 context를 낭비하지만, exa.ai는 AI가 읽기 좋은 핵심 텍스트만 추출해서 돌려줍니다. 도구 정의 비용은 같아도, 실행 시 발생하는 데이터 비용이 훨씬 적은 것이죠.


🚀 실전 MCP 관리 팁

1. 현재 작업과 무관한 MCP는 꺼두기
• 코딩 중이라면 부동산이나 날씨 MCP는 비활성화하는 게 좋습니다. 켜져 있는 것만으로도 비용입니다.

2. 응답이 간결한 도구를 선택하기
• 같은 기능을 제공한다면 응답 데이터가 더 정제되어 돌아오는 MCP가 장기 세션에 유리합니다.

MCP는 강력한 확장이지만, 결국 '유한한 context'를 나눠 쓰는 자원입니다. "항상 켜져 있는 비용"이라는 관점에서 관리해 보시는거 추천!!

다음 편에서는 "Agent Teams를 켰는데 왜 더 느려졌을까"에 대해 다뤄보겠습니다.

---

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

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

📌 LLM 어플리케이션 3편: Agent Teams — 더 많은 에이전트가 더 빠른 게 아니다

BQ개발자입니다

지난 편에서 MCP를 많이 등록할수록 context를 소비해 Claude의 성능이 떨어지는 역설을 다뤘습니다.

이번에는 Agent Teams를 살펴봅니다. "AI가 여러 명이면 당연히 빠를 것"이라는 기대와 달리, 왜 때로는 더 느려지는지 이유를 짚어보겠습니다.


🤔 Agent Teams를 켰는데 왜 더 느려졌을까?

단일 에이전트가 복잡한 작업을 순차 처리하면 코드 리뷰,
보안 감사 등 모든 과정이 하나의 context에 쌓입니다.
결과적으로 정보가 너무 많아져 1편에서 언급한 'attention 희석'이 발생하죠.

이를 해결하기 위해 에이전트를 나누는 Agent Teams를 도입하지만, 구조를 이해하지 못하면 오히려 성능이 저하됩니다.


⚡ Agent Teams의 실제 메커니즘

Agent Teams의 핵심은 단순 협업이 아니라 context window를 분할하는 것입니다.

팀원이 3명이면 각자 독립된 context를 갖습니다. 코드 리뷰 에이전트는 리뷰 데이터만,
문서 작성 에이전트는 깨끗한 context에서 시작하는 식이죠. 이 구조가 효율적으로 작동하려면 반드시 지켜야 할 순서가 있습니다.


🧠 순서를 틀리면 생기는 함정

역할 분리(Specialized Agents) 없이 병렬화만 하면 문제가 생깁니다.
역할이 모호하면 에이전트들이 같은 작업을 중복 수행하게 되고, 오케스트레이터는 이를 조율하는 메시지로 메인 context를 빠르게 소진합니다.
작업 효율은 낮은데 관리 비용만 치솟는 '이중 오버헤드' 상태가 되는 거죠.

따라서 Specialized Agents 설계가 우선되어야 합니다. 누가 어떤 역할을 맡고, 어떤 파일을 다룰지 경계가 명확해야 병렬화의 이득을 볼 수 있습니다.


🎯 3~4명 권고가 자의적 숫자가 아닌 이유

Claude Code 공식 문서에서 권장하는 팀 규모 3~4명은 '비용과 조율의 균형점'입니다.

팀원이 늘면 context 비용도 배로 늘고, 오케스트레이터의 조율 부담도 커집니다.
4명을 초과하면 병렬화로 얻는 이득보다 조율 오버헤드가 더 커지기 시작한다고 보는 것이 합리적입니다.

💡 팁: Agent Teams를 켜기 전, 에이전트별 역할부터 명확히 나누세요.
역할 경계가 분명해야 병렬화가 실제 속도로 이어집니다.

에이전트 역할을 잘 나눴다면, 이제 각 에이전트가 도구를 얼마나 잘 쓰는지도 중요합니다. 다음 편에서는 제가 자주 사용하는 플러그인들에 대해서 좀 다뤄볼게요!!
---

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

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

📌 Claude Code 1편: Claude Code에 앱 스토어가 생겼다

BQ개발자입니다.

같은 Claude Code를 쓰는데 어떤 팀은 코드를 바로 짜고,
어떤 팀은 "엣지 케이스는 어떻게 할까요?"라고 먼저 묻게 되는데요,
이런 방식의 차이는 보통 모델 차이가 아니라 Plugins 때문입니다.

🤔 "플러그인 = 기능 추가"라는 착각

예를 들어서 Clarify 스킬을 설치하면 Claude가 코드 짜기 전에 요구사항을 먼저 묻기 시작합니다.
단순히 꼼꼼해진 게 아니라, Claude의 동작 방식 자체가 바뀐 거거든요.

⚡ SKILL.md: 판단 기준의 주입

이런게 왜그런지를 설명해보면, 플러그인을 설치했을때 컨텍스트에 SKILL.md 파일이 추가되기 때문입니다.
여기에는 "코딩 전 요구사항을 먼저 확인해라" 같은 방법론이 적혀 있고, Claude는 이걸 읽고 이후 모든 요청에 알아서 적용합니다.
기본 상태에선 수단까지 지정해줘야 하는 도구인데, SKILL.md가 들어오면 목표만 줘도 수단을 스스로 선택하는 에이전트가 됩니다.

🎯 /plugins로 시작하는 에이전틱 코딩
Claude Code에서 /plugins를 입력하면 팀어텐션(TeamAttention)이 구축한 생태계에 연결됩니다.
여기서는 팀만의 SKILL.md를 직접 정의할 수 있어서, 설계 검토 기준이나 PR 체크리스트 같은 팀 컨벤션을 Claude의 판단 기준으로 만들 수 있구요

💡 팀이 Claude에게 매번 반복하는 규칙이 있다면, 그게 SKILL.md 후보입니다.

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

#BQ개발자 #ClaudeCode #LLM애플리케이션 #AgenticCoding #AIEngineering

📌 LLM 어플리케이션 2편: 세션이 끝나도 Claude는 기억한다 — 단, 당신이 설계할때만

BQ개발자입니다.

지난 편에서 Skills와 Plugins가 Claude의 "기능"을 추가하는 게 아니라 Claude의 "판단 기준"을 바꾼다고 했는데요,
오늘은 그 판단이 세션이 끝나면 어떻게 되는가라는 질문을 다뤄보겠습니다.

"세션이 끝나면 Claude는 다 잊는 건데, 그걸 어떻게 기억하게 해?"

🤔 환각의 원인에 대한 오해

Claude가 틀린 답을 낼 때, 가장 흔한 설명은 이겁니다.

"LLM이 원래 그래요. 모델 한계예요."

근데 실제로 해보면 패턴이 있습니다. 세션 초반엔 정확한데, 세션이 길어질수록 틀리는 빈도가 늘어나거든요.
이미 결정한 설계를 재발명하거나, 없는 파일 경로를 있는 것처럼 응답하는 일이 생깁니다.

저는 이게 모델이 멍청해서가 아니라고 생각합니다.

Claude Code의 컨텍스트 윈도우가 일정 한도에 도달하면 자동 압축(compaction)이 트리거됩니다.
이 압축이 세션 초기의 정밀한 정보들 — 특정 변수명, 에러 메시지 원문, 설계 결정의 이유 — 을 요약으로 뭉개버리거든요.


⚡ 환각은 의존 구조의 문제다

Claude가 정보를 가져오는 경로는 두 가지입니다.

하나는 컨텍스트에 올라온 텍스트를 읽는 것이고, 다른 하나는 모델 내부의 추론으로 "그럴 것 같은" 것을 생성하는 거예요.

컨텍스트에 정확한 정보가 있으면 Claude는 그걸 읽습니다. 없으면 추론에 의존하고요. 압축이 바로 컨텍스트에서 정확한 정보를 지워버리는 과정이에요. 압축 이후 Claude가 초기 설계 결정을 재발명하는 건, "기억이 나빠서"가 아니라 정확한 정보 소스가 컨텍스트에서 사라졌기 때문에 추론이 그 자리를 채우는 상황인 것 같아요.

그러면 해결책이 보이죠. 모델을 교체하거나 파인튜닝하는 게 아니라, 다음 세션이 시작될 때 정확한 정보를 컨텍스트에 올려놓으면 됩니다. 이게 Session Wrap의 설계 원리예요.


🎯 Session Wrap이 하는 일

제가 개인적으로 많이 활용하는 스킬인데요,
/wrap 명령을 실행하면 멀티에이전트 파이프라인이 돌아갑니다.

Sonnet 모델 4개가 병렬로 세션에서 추출해야 할 것들을 각자 담당해요
문서 업데이트 내용, 자동화 가능한 반복 패턴, 오늘의 발견과 실수,
다음 세션 우선순위. 이 결과가 CLAUDE.md와 context.md 외부 파일에 저장됩니다.

다음 세션이 시작되면 Claude는 그 파일을 읽어요.
이전 세션의 결정 사항들이 "정확한 텍스트"로 컨텍스트에 올라오는 거죠. 모델이 내부 추론에 의존할 이유가 없어집니다.

핵심은 의존 구조를 교체했다는 거예요. 불확실한 내부 기억 의존 → 명확한 외부 파일 참조. 모델을 바꾸지 않았는데 환각이 줄어드는 이유가 여기 있는 것 같습니다.


🚀 작업 이력이 지식 자산이 되는 구조

Session Wrap에는 automation-scout라는 구성요소가 있습니다.
세션마다 반복 패턴을 발견해서 새 Skill 후보로 제안하는 역할이에요.

1회 세션에서 발견한 패턴이 Skill로 만들어지면, 2회 세션에서 그게 자동 트리거됩니다.
3회엔 이미 내재화된 방법론이 되고요. 작업할수록 Claude의 판단 기준이 업그레이드되는 복리 구조인 거죠.

1편에서 얘기한 "방법론의 코드화"가 Session Wrap으로 자동화되는 겁니다.

💡 팁: /wrap을 세션 종료 루틴으로 만들어두면 CLAUDE.md가 스스로 업데이트되는 시스템이 됩니다. 처음엔 빈 파일이지만 쌓일수록 달라져요.

하지만 이 구조를 팀 단위로 확장하려면 새로운 문제가 생깁니다.
한 팀원이 만든 Skill을 다른 팀원은 어떻게 공유하고, 권한은 어떻게 관리할까요? (다음편에서 다뤄볼게요)

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

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