모두가 생성형 AI (Generative AI)에 열광하고 있지만, Microsoft의 Semantic Kernel과 Azure AI를 사용하여 .NET 애플리케이션에 AI 기능을 구축해 본 결과, 진짜 도전 과제는 LLM (Large Language Model)을 호출하는 것이 아니라 모델에 전달하는 컨텍스트 (Context)를 제어하는 것이라는 점을 배웠습니다.

큰 차이를 만들어낸 몇 가지 교훈은 다음과 같습니다:

🔹 모델에 모든 것을 보내지 마세요

객체 그래프 (Object graph) 전체나 데이터베이스 응답을 프롬프트 (Prompt)에 통째로 쏟아붓고 싶은 유혹이 생길 수 있습니다. 하지만 이를 참아야 합니다.

Semantic Kernel을 사용할 때는 사용자의 질문과 관련된 데이터만 추출하는 전용 컨텍스트 빌더 (Context builder)를 만드세요. 불필요한 토큰 (Token)이 늘어날 때마다 비용, 지연 시간 (Latency), 그리고 모델이 주의력을 잃을 확률이 증가합니다.

가장 좋은 프롬프트는 필요한 컨텍스트를 포함하면서도 가장 짧은 프롬프트인 경우가 많습니다.

🔹 모델 선택보다 토큰 최적화가 더 중요합니다

많은 팀이 매 요청마다 수천 개의 불필요한 토큰을 보내면서, GPT 버전을 두고 며칠씩 토론하며 시간을 보냅니다.

모델을 업그레이드하기 전에 다음을 수행하세요:

✅ 중복 필드 제거
✅ 주입 전 대규모 데이터셋 요약
✅ 지능적인 문서 청킹 (Chunking)
✅ 재사용 가능한 컨텍스트 캐싱 (Caching)

토큰을 30% 줄이는 것이 모델을 교체하는 것보다 더 큰 ROI (투자 대비 효율)를 제공하는 경우가 많습니다.

🔹 온도 (Temperature)는 단순한 숫자가 아닙니다

사용 사례에 따라 서로 다른 설정이 필요합니다.

📊 제품 정보, 분석, 순위, 보고서:

• Temperature: 0 - 0.2

💡 브레인스토밍 및 아이디어 구상:

• Temperature: 0.7+

만약 사용자가 AI가 "지어낸 이야기를 한다"라고 불평한다면, 제가 가장 먼저 확인하는 곳은 바로 온도 설정입니다.

🔹 모호한 프롬프트는 모호한 답변을 생성합니다

만약 사용자가 다음과 같이 질문한다면:

"이것에 대해 알려줘."

모델은 사용자가 무엇을 원하는지 알 수 없습니다:

• 요약
• 역사
• 속성

응답의 품질은 요청의 구체성에 정비례합니다.

자유 형식의 질문에 의존하기보다는 제안된 프롬프트로 사용자를 안내하세요.

하지만 잘 설계된 시스템 프롬프트 (System Prompt)는 이 문제를 크게 줄일 수 있습니다. 사용자에게 완벽한 질문을 하도록 강요하는 대신, 시스템 프롬프트는 모델에게 다음과 같이 지시할 수 있습니다:

• 대화 문맥 (Context)으로부터 의도 (Intent)를 추론할 것
• 모호성이 높을 경우 명확하게 하기 위한 질문을 던질 것
• 미리 정의된 응답 구조를 기본값으로 사용할 것
• 애플리케이션 도메인에 따라 가장 관련성 높은 정보를 우선시할 것

목표는 사용자가 더 나은 프롬프트를 작성하도록 교육하는 것이 아닙니다. 불완전한 프롬프트에서도 유용한 결과가 나오도록 AI 경험을 설계하는 것입니다.

강력한 시스템 프롬프트는 추가적인 문맥을 더하거나 모델 크기를 키우는 것보다 응답 품질에 더 많이 기여하는 경우가 많습니다.
이러한 추가 사항은 중요한 엔지니어링 원칙을 도입합니다. 즉, 좋은 AI 제품은 사용자가 프롬프트 엔지니어 (Prompt Engineer)가 되기를 기대하기보다, 불완전한 사용자 입력을 보완해야 한다는 것입니다.

🔹 피드백 루프 (Feedback loops)는 매우 중요합니다

가장 가치 있는 AI 텔레메트리 (Telemetry)는 토큰 사용량이 아닙니다.

그것은 바로 다음과 같습니다:

👍 도움이 됨 (Helpful)
👎 도움이 되지 않음 (Not Helpful)

모든 '좋아요'와 '싫어요'는 프롬프트 엔지니어링을 위한 학습 데이터가 됩니다.
AI 어시스턴트를 개선하는 가장 빠른 방법은 사용자가 AI의 의견에 동의하지 않는 지점이 어디인지 배우는 것입니다.

🔹 대화 상태 (Conversation state)를 신중하게 유지하세요

메모리가 없는 챗봇은 고장 난 것처럼 느껴집니다.
메모리가 너무 많은 챗봇은 비용이 많이 들고 혼란스러워집니다.
세션 히스토리 (Session history)를 유지하되, 오래된 대화는 주기적으로 요약하고 전체 채팅 히스토리 대신 요약본을 주입 (Inject)하세요.

Semantic Kernel을 사용하면 이 패턴을 비교적 간단하게 구현할 수 있습니다.

🔹 디버그 모드 (Debug Mode)를 켜세요

AI 솔루션을 개발할 때 가장 과소평가되는 기능 중 하나입니다.

다음 항목들을 추적하세요:

• 프롬프트 토큰 (Prompt tokens)
• 완료 토큰 (Completion tokens)
• 총 비용 (Total cost)
• 지연 시간 (Latency)
• 검색된 문맥 (Retrieved context)
• 함수 호출 (Function calls)
• 모델 선택 (Model selection)

응답이 잘못된 것처럼 보일 때, 정답은 대개 프롬프트나 검색된 문맥 속에 숨어 있습니다.

🔹 RAG가 항상 필요한 것은 아닙니다

많은 AI 프로젝트가 즉시 벡터 데이터베이스 (Vector databases)와 검색 증강 생성 (RAG, Retrieval-Augmented Generation)으로 뛰어듭니다.

먼저 스스로에게 물어보세요:

필요한 데이터를 이미 API, 데이터베이스(Database) 또는 도메인 객체(Domain Object)로부터 불러올 수 있습니까?

만약 그렇다면, 단순히 관련 데이터를 프롬프트(Prompt)에 주입하기만 하면 됩니다.

RAG가 가치 있어지는 경우는 다음과 같습니다:

✅ 지식의 규모가 클 때
✅ 데이터가 비정형(Unstructured)일 때
✅ 문서가 빈번하게 변경될 때
✅ 사용자가 수천 개의 레코드에 대해 의미론적 검색 (Semantic Search)을 수행해야 할 때

모든 챗봇에 벡터 데이터베이스(Vector Database)가 필요한 것은 아닙니다.

때로는 SQL에 대해 잘 설계된 쿼리(Query) 하나만으로도 충분할 수 있습니다.

제가 얻은 가장 큰 교훈은 다음과 같습니다:

AI 기능을 구축하는 것은 점점 더 쉬워지고 있습니다.

빠르고, 신뢰할 수 있으며, 비용 효율적이고, 믿을 수 있는 AI 기능을 구축하는 것이야말로 진정한 엔지니어링이 시작되는 지점입니다.

dotnet #SemanticKernel #OpenAI #AzureOpenAI #GenerativeAI #LLM #SoftwareArchitecture #RAG #AIEngineering #CSharp