데이터연구소

이전 글인 [에이전트를 도입하기 전에 고려사항]에서 말했듯, 코드, 워크플로우, RAG & 챗봇을 고려해도 고객의 문제를 해결하지 못했을 때, 이제 에이전트를 선택해야 한다. 그렇다면, 에이전트 시스템을 설계하려면 어떤 걸 고려해야 할까?

사람이 하는 일을 모사한 에이전트가 있다고 하면, 모델, 도구, 메모리, 지식 베이스인 4가지를 오케스트레이션 하여 사용자에게 답변해 준다. 즉 이 4가지 요소를 잘 설계해야 에이전트 시스템이 된다.

[API와 로컬 모델]

첫 번째인 모델은 크게 API와 로컬로 나눌 수 있다. 로컬에서 오픈소스 모델이나 개발을 하여 Agent를 구성할 수 있다. 하지만, 대부분의 경우는 비용과 시간문제로 자체 모델을 개발하기 어렵다. 그렇기에 클로드나 OpenAI API, Google API로 최신모델을 사용하여 에이전트를 만들게 된다. 하지만 실제 설계는 어떤 모델을 어떤 영역에 잘 배치하고 사용하냐에 따라 비용과 효율성이 결정된다. 쉽게 말해, 단순 인사말을 대답하는데 GPT5.2 모델(작성일 기준 최신) 대신 gpt-4.1-mini나 gpt-4o-mini도 충분하다.

[Reasoning 모델 선택 기준]

그렇다면 어떤 기준으로 모델을 선택할까? 제일 먼저 “생각할 문제”인지 따져봐야 한다. 생각할 문제는 Reasoning 모델이 필요한가를 결정하는 기준을 말한다. 고민해보지 않아도 되는 문제를 굳이 reasoning 모델을 쓸 필요 있는가? gpt-5 계열이 reasoning 모델인데, 단순 텍스트 정리를 이 reasoning 모델로 할 필요 없다. 오히려 하면, 응답지연만 길어지고 비용만 올라간다. 물론 reasoning을 해서 글을 쓴다면 고려해볼 만하다. reasoning 모델 여부를 선택했다면 이제 작은 모델(저비용 모델)부터 적용해서 내가 원하는 결과가 만들어지는지 보고 선택한다. 만약 gpt-5-nano 결과가 마음에 들지 않으면 gpt-5-mini로 교체한다. 또 마음에 들지 않으면 gpt-5, gpt-5.2 다 고려한다. 같은 퀄리티의 답변이라면 저비용이 유리하기에 이렇게 선택한다.

[동일한 모델일 필요는 없어]

여기서 흔히 착각하는 경우가, 모든 컴포넌트(혹은 노드)에 동일한 모델일 필요없다. 여기서 이야기하는 컴포넌트는 한 가지 역할이 부여된 부분이라고 생각하면 편하다. 예를 들어, 오타를 수정한 글을 보고 다시 글을 작성한다고 한다면, 오타를 잡는 노드와 수정한 글을 보고 글을 작성하는 노드는 다른 모델을 선택하면 된다. 다시 말하지만, 정답은 없다. 하지만 같은 결과인데 저비용이면 좋다.

[모델 사용 벨런스]

마지막으로 모델을 선택할 때는 모델 사용 간에 벨런스를 잘 분배해야 한다. OpenAI 기준으로는 각 모델에 limit token과 request rate이 존재한다. 만약 내가 gpt-5만 사용한다면 limit에 걸려 오류가 나게 된다. 물론 token 관리를 통해 지연 응답으로 처리할 수 있지만, gpt-5와 gpt-5.2, gpt-4.1을 고루 분배한다면 3배의 토큰 limit를 사용할 수 있다.

에이전트을 도입하기 전에 생각할 것들

머신러닝과 딥러닝이 등장 이후, 어떤 데이터든 최신모델을 돌리면 다된다는 생각을 많이들 한다. 실상은 데이터 중심에서 모델을 결정해야 한정된 리소스에서 최고의 성능을 내기 마련이다. 심지어 어떤 경우에는 rule base로 구현하는 게 훨씬 더 명확한 경우가 있다.

왜 이런 말을 하냐면, LLM Agent도 똑같다. 데이터 혹은 도메인의 프로세스를 이해하지 않고 Agent에 모든 자율성을 주는 것은 리소스 낭비 이며 성능도 뛰어나지 않다. 

그러므로 에이전트를 도입하기 전에, 프로젝트 초기에 도메인을 이해하고, 어떤 솔루션이 적절한가를 먼저 고민해야 한다. 구체적으로 말하자면, 이 프로젝트는 코드(code), 워크플로(workflow), RAG과 챗봇, 에이전트 이 4가지 중 어떤 것이 적절한지 고민해 봐라.

결론부터 말하자면, 에이전트는 고비용, 높은 지연시간, 관리의 어려움이라는 큰 단점이 존재하는 설루션 중 하나이다. 그러므로 어떤 설루션이 적절한지 필히 고민해야 한다.

먼저 코드는 그 말대로 미리 작성해 놓는 방식이다. 예를 들어, 램프 색에 따라 주의사항을 사용자에게 다르게 알려줘야 한다는 목표라고 생각해 보자. "빨간색이면 위험 신호를, 노란색이면 주의 신호 ..."이런 식으로 프롬프트로 만들어서 사용자에게 메시지를 보낼 수 있지만, 정해진 주의사항이면 그냥 미리 짜놓으면 더 안정적이고 저 비용이다.

두 번째는 워크플로인데, 시나리오가 존재하는 경우이다. 사람이 하는 일은 의식이든 무의식이든 어떠한 순서가 있는 일을 하게 된다. 예를 들어, 회사 서류 전형을 검토를 자동화하고 싶다고 생각해보자. 먼저, 이력서에 학교, 나이, 경력 등 검토를 한 후 정량화하고, 자기소개서를 검토한 후 마지막에 종합적으로 판단한다라고 해보자. 그러면 이력서 검토, 자기소개서 검토, 종합 판단이라는 3단계의 워크플로우가 존재한다. 한마디로 flowchart를 그릴 수 있다면 에이전트보단 워크플로이다. 워크플로도 자율성이 없는 것이 아니다 어떤 부분(node)은 스스로 판단하기도 하고 병렬적으로 실행하기도 하고 다양하다. 단, 도구(tools) 개념으로 모든 자율성을 LLM에게 주지 않고 정해진 순서를 따라가게 만든다라는 게 다르다.

세 번째, RAG와 챗봇이다. 단순히 어떤 정보를 검색하고 알려주는 방식의 프로젝트라면, RAG와 챗봇을 이용해서 단순화하면 된다. 에이전트도 필요 없고 RAG를 통해 정보를 전달해주기만 하면 된다. 에이전트를 고민할게 아니라 RAG를 어떻게 더 효과적으로 성능을 개선시킬 수 있을지 고민하고 시간을 쏟아야 한다. 

마지막으로, 에이전트이다. 쉽게 설명하면, 인간을 모사한 설루션이다. 도구(tools)를 인간을 모사한 에이전트에게 쥐어주며 시키는 일에 계획도 스스로 작성하고 실제로 실행하고 확인까지 스스로 하는 솔루션이다. 여기서 중요한 게 '인간을 모사한'이라는 말이다. 반대로 이야기하면 인간을 모사할 정도의 일이 아니라면 다른 설루션을 고민하라는 것이다. 예를 들어, 기기 매뉴얼을 읽어 알려주는 기능을 만들고 싶다라고 가정하자. 기기 매뉴얼 읽어 알려줄 정도의 일은 인간을 모사할 정도의 일이냐?라는 질문을 스스로 던져보자. 당연히 너무 단순한 일이라 인간을 모사할 정도는 아니다. 그럼 다른 솔루션을 생각해 봐라. 신중하고 신중해라 모든 데이터에 딥러닝이 답이 아니듯 에이전트가 답은 아니다.

References

• Building Apllication with AI agents.

트랜스포머의 셀프 어텐션이 있다. 셀프 어텐션은 단어 간에 관계성을 학습하는 모델(아키텍처)로 LLM에 근간이 된다. 그러나 최신 모델들은 이러한 셀프 어텐션을 변형하거나 덧붙여서 모델을 만들고 있다. 그러므로 최신 LLM 모델을 이해하기 위해 아래와 같은 개념을 이해할 필요 있다.

MHA(Multi-head attention)는 attention 구조를 여러 개(multi head)를 이용한 구조이다. 단순히 여러 개를 이용하므로 파라미터 수와 계산량이 head 개수만큼 커진다.

이러한 단점을 group query attention을 이용해 해결한다. Group query attention은 Transformer의 계산인 Query, Key, Value로 이어지는 계산을 Query를 group으로 묶어 계산하는 방식이다. 그러므로 group의 크기에 따라 query 계산량이 줄어든다. 실험 결과 이렇게 group을 묶어도 크게 performance가 차이 나지 않아 활용되었었다. 파라미터 숫자가 줄어든다는 장점도 있지만, KV cache 계산(inference 시 recursive 하게 계산하므로 매번 계산하는 걸 한 번만 하는)에서 K 파라미터가 줄어들어 큰 장점이 있다.

이와 같이 메모리(파라미터 수) 관점에서 또 개선한게 MLA(Multi-head Latent Attention)이다.  이름에서 볼 수 있듯이 K, V 간의 연산을Latent(일종의 선형 변환)을 통해 하나의 weight로 계산하는 방식이다. GQA과 동일한 크기에서 더 좋은 성능을 보여 Deepseek에서도 이용되었다. deepseek 논문에서는 GQA 비교, MHA과의 inference 토큰 비교 등 다양한 비교 결과를 증명하였다.
(참고로 deepseek 논문이 모든 걸 공개해서 궁금하다면 deepseek 논문부터 읽기를 권장한다)

마지막으로 sliding window attention인데 gemma 3에서 memory를 절약하기 위한 technique이다. 기본 콘셉트는 sliding window로 단어 간에 관계성을 계산하자이다. self-attention에서 모든 단어 간에 관계성을 계산했다면, sliding window attention은 해당 단어 앞에 3개 싹만 하자 이런 식으로 계산을 해도 성능차이가 별로 없다는 가정하에 실험했다. 우려되는 점은 local(근처)의 단어만 계산하기에 global(문장 전체)에 대한 관계성을 학습할 수 있을까라는 의문이 든다. 그러므로 작은 모델에선 효과적일 수 있으나 큰 모델에서는 권장하지 않는다.

RAG Retrieval-Augmented Generation는 LLM 대규모 언어 모델에서 정보 검색과 생성 기능을 결합한 접근 방식을 말합니다. 이는 언어 모델의 제한된 지식을 보완하기 위해, 외부 데이터베이스나 문서에서 정보를 검색하고 이를 기반으로 응답을 생성하는 기술입니다.

1. Why? Motivation

현재 OpenAI에 GPT 4o를 보더라도 LLM은 답변을 훌륭하게 합니다. 하지만, 참고한 자료 및 정보의 정확한 수치와 용어를 사용하지 못합니다. 흔히 할루시네이션(hallucination)을 이르킨다고 말합니다.

그렇다면 참고한 자료와 정보를 프롬프트 입력에 직접 다시 넣어주면 되지 않을까?라는 질문에 대한 해답이 RAG입니다.

2. What? Key Components

말 그대로 RAG는 정보를 Retrieval 검색해서 프롬프트에 Augmentation 보강하여 최종적으로 LLM 답변을 Generation 생성하는 기술입니다.

- Retrieval은 검색하는 것인데 PDF가 될 수도 있고, CSV, URL 다양한 정보를 필요한 부분만 발최하는 과정입니다.

- Augmentation은 발최한 정보를 LLM이 잘 알아들을 수 있게 프롬프트에 녹이는 과정입니다.

- 마지막으로 Generation은 보강한 프롬프트를 넣어 최종적으로 LLM 답변을 생성합니다.

아래 보시는 그림은 프롬프트가 들어가서 어떤식으로 RAG과정이 이루어지는지 보여주는 그림(2024 RAG Survey 논문)입니다.

Retrieval과정에서도 전/후로 작업 별도로 이루어지고 Augment도 어떤 식으로 프롬프트를 만들 것인지 다양한 방법이 존재합니다.

다음 글 부터는 이러한 다양한 RAG 테크닉을 살펴볼 예정입니다.

3. How? Method Details

RAG의 기본적인 개념인 참조할 수 있는 Text 데이터를 임베딩(텍스트를 Vector로 만듦)을 통해 Vector DB(Vectorstore)을 만듭니다. (참고로 임베딩은 “I am a student”라는 문장을 [0.23, 0.42, 0.23, 0.38, 0.48, 0.94] 같은 벡터 형태로 만드는 과정임)

질문과 VectorDB에 저장된 Text 간에 Similarity score로 제일 가까운 Text를 발최합니다.

이 과정이 위에서 설명한 Retrieval 과정입니다.

그 외 과정은 다양한 RAG 방법을 설명하면서 보충하도록 하겠습니다.

4. Summary

• RAG는 정보를 검색해서 발최하여 프롬프트를 보강하여 답변을 생성하는 기술
• Retrival는 텍스트 정보를 벡터 형태로 저장하여 질문과 가까운 정보만 발최하는 과정.

References

• https://www.samsungsds.com/kr/insights/rag-customization.html
• Fan, Wenqi, et al. "A survey on rag meeting llms: Towards retrieval-augmented large language models." Proceedings of the 30th ACM SIGKDD Conference on Knowledge Discovery and Data Mining. 2024.