Acanel Blog

AI Guidance

LLM이란?
쉽게 이야기하면, 사용자의 prompt를 input으로 주면 답변해 주어야 하는 가장 알맞은 토큰(단어)을 하나씩 내뱉는 모델.

위 그림처럼, 사용자가 "대한민국의 수도는 어디야?" 라고 Input을 주면 LLM은 확률 상 가장 올바른 응답을 하기 위한 단어들로 "서울" -> "입니다" -> "." 단어들을 순차적으로 출력한 뒤 더 이상 출력할 단어가 없으면 대화 종료를 리턴하여 대화를 마친다.

즉, 문장을 만들어내는 모델이며, 사람처럼 대화하는 그 자체로는 매우 혁신적인 모델이지만 이 모델 자체만으로는 사용자에 대한 정보 기억이나 외부 실시간 데이터를 활용한다던지 복잡한 작업 등을 처리할 수는 없다.

LLM 발전에는 다양한 히스토리가 있지만 아래 2가지 개선방향이 많은 영향을 주었다.

컨텍스트 윈도우의 증가
- 컨텍스트 윈도우 : 쉽게 말해 사용자의 Input 크기. 예를 들어 컨텍스트가 100이면 단어 100개만 Input으로 줄 수 있고, 컨텍스트가 10만이면 단어 10만개를 Input으로 줄 수 있음.
- 초창기 LLM은 Input Size가 작아서 사용자 Prompt가 길어지면 앞단의 문장들이 잘리고 결과적으로 요청 맥락을 잃어버리는 경우가 많았는데, 최근 모델들은 Input Size가 비약적으로 커지면서 이전 대화 히스토리도 한번에 같이 주고 시스템 프롬프트도 같이 주고 해도 한번에 다 이해하고 처리할 수 있게 발전했음.
추론 모델 등장
- LLM이 단어를 뱉기 전에 Input에 대해 모델 내부적으로 "분석", "단계 나누기", "플래닝" 등 전처리를 진행 후 결과를 출력하게 하여 좀 더 작은 모델로도 고품질의 응답을 출력할 수 있게 됨.
- 즉, 기존에 CoT(Chain of Thought, 연쇄적 사고)를 모델 자체에 내재화를 시켰다고 보면 됨.
- 이를 통해 수학/과학적 논리, 상식적 사고에 대한 응답을 더 잘하게 됨

AI 에이전트란?
개념적으로는..
"인간을 대신하여 스스로 목표를 설정하고, 계획을 세우며, 복잡한 작업을 자율적으로 수행하는 인공지능 소프트웨어 시스템"

기술적으로는..
LLM에 계획 모듈¹⁾, 기억 모듈²⁾, 검색 모듈³⁾, 도구 모듈⁴⁾ 등을 붙여서 사용자의 요청에 대해 계획을 세우고, 불러올 기억이 있으면 가져오거나 저장할 기억이 있으면 저장하고, 최신 정보를 검색해서 사용하고, 각종 툴들을 이용해 외부 세계와 통신할 수 있도록 만든 인공지능 소프트웨어 시스템 이라고 요약할 수 있다.

LLM 자체로는 단순히 주어진 Input에 대해 적절한 Text를 출력하는 것 밖에 못한다. 따라서 복잡한 계획에 대한 상세 계획을 세우게 하거나, 어떤 정보를 기억하게 하거나, 추가적인 새로운 정보를 검색하게 하거나, 외부 세계와 통신하게 하는 별도의 모듈을 추가하여 에이전트를 구현한다.

MCP, A2A란?
MCP(Model Context Protocol)
에이전트에서 "도구 모듈"을 쉽게 플러그인화 하고 LLM/에이전트에 붙일 수 있게 하는 프로토콜.

AS-IS : 에이전트, 또는 LLM 기반 서비스를 만드는 사람만이 도구 모듈을 개발해서 LLM/에이전트에게 제공할 수 있었음
TO-BE : MCP를 지원하도록 에이전트를 개발하면, 다른 사람들이 도구 모듈을 만들어서 LLM/에이전트에게 제공할 수 있음

MCP 예시

Figma MCP : 피그마에 접속해서 피그마에 있는 레이아웃을 LLM이 알 수 있게 하거나 LLM이 레이아웃을 추가/변경할 수 있게 하는 도구 모듈
Claude, Gemini CLI, Copilot Agent, 최근엔 ChatGPT도 MCP를 지원함. 이 서비스들에 Figma MCP 연동하도록 추가하면 그 에이전트들은 모두 내 피그마에 접속해서 대화를 통해 레이아웃을 확인하고 추가/수정할 수 있게 됨.

즉, 누군가가 Figma MCP(피그마 연동 도구 모듈..이미 만들어져 있음)를 만들어서 패키징화해서 올려두면, LLM을 쓰는 모든 사람들은 쉽게 자기 대화방이나 에이전트에 이 모듈만 붙이면 해당 LLM, 에이전트에서 Figma에 접근할 수 있게 됨.

A2A(Agent to Agent)
에이전트 간 통신 프로토콜.
에이전트를 만들다 보니, 1개의 에이전트에게 너무 많은 역할을 주거나 기능을 제공하면 오히려 혼란스러워 하고 제대로 응답하지 못하는 경우가 많이 생김.
그래서, 역할을 잘 나누어서 SubAgent로 나누고 에이전트간 통신을 통해서 사용자 요청에 대해 처리하게 하는 아키텍처가 나오게 됨.
이 때, 에이전트끼리 통신을 하게끔 하기 위한 공통 통신 규약을 구글이 만듬.
이 공통 통신 규약을 따르도록 에이전트를 개발하면, 이 통신 규약을 따르는 다른 에이전트들과 쉽게 통신하여 서로 협력하게 할 수 있음.

예시 : ChatGPT로 만든 날씨 에이전트 / Gemini로 만든 홈IoT 에이전트가 있고 서로 A2A로 통신한다고 가정하면, 날씨 에이전트가 홈IoT 에이전트에게 오늘 비가 오니 관련한 작업을 요청하면 홈IoT 에이전트는 알아서 건조기를 돌린다거나 에어컨을 미리 틀어둔다거나 할 수 있음.

AI 에이전트 추후 발전 방향
멀티 에이전트 협업
위에 A2A에서 설명한 것처럼, 다수의 에이전트가 상호작용하여 사용자 요청에 대해 협업하며 진행하고, 서로 토론 및 결과 검증도 하게 하는 방식으로 좀 더 좋은 결과물을 만들어내기 위한 방향으로 개선 중

자기 성찰 및 출력 검증
에이전트가 본인이 출력한 결과를 스스로 확인하고 오류를 수정하는 루프 구조가 도입되고 있음
환각과 오류를 줄이는 방향으로 기여 중임

자율 에이전트
사용자의 개입 없이도 동적으로 주변 환경의 변화를 끊임없이 인식하며 사용자의 요청을 자율적으로 수행하는 에이전트.
예 1 : 주식 상태와 뉴스를 계속 모니터링하면서 너가 알아서 잘 주식 매수/매도 해 -> 계속 루프 돌면서 주식/뉴스 조회 후 스스로 매수/매도 진행
예 2 : 개발자들이 코드를 반영하면 모니터링하면서 코드리뷰도 진행하고 보안 관련 리스크가 있는지 검토해. 필요하면 너가 수정사항도 반영해. -> 계속 루프 돌면서 개발자 코드 반영 확인하고 코드리뷰 및 수정 진행

실세계 물리 연동
에이전트와 카메라, 드론/로봇 팔 등을 서로 연동(일반적으로 도구 모듈 방식 활용)하여 에이전트가 카메라로 외부 상황을 인식하고, 스스로 물리적인 움직임을 진행할 수 있도록 개발되고 있음. (Robotic AI Agent)

AI/에이전트 활용 사례 및 서비스
코딩/개발 분야

Claude Code : CLI 기반 Coding용 AI Agent
Cursor AI : 개발 IDE + Coding용 AI Agent
Windsurf : 개발 IDE + Coding용 AI Agent
Github Copilot : IDE Plugin + Coding 툴 및 AI Agent
Lovable AI : No Coding 앱/서비스 개발 서비스
Bolt AI : No Coding 앱/서비스 개발 서비스
Bubble IO : No Coding 앱/서비스 개발 서비스

업무 분야

Microsoft Copilot : MS Office 전용 AI Agent
Notion AI : 노션 AI. 문서 생성 자동화, 요약 등
ClickUp Brain : AI 기반 협업 툴 (태스크 관리, 메신저, 문서 관리 등 All-in-one 솔루션)
Reclaim AI : AI 기반 일정 관리 툴 (업무/휴식/집중 근무 시간/태스크 조정 등 관리)
Otter AI : 미팅, 강의, 인터뷰 등 시 실시간 통역 및 회의 요약
기타 : https://www.angularminds.com/blog/best-ai-tools-for-productivity

영상/미디어 제작

Google Veo 3 : AI 기반 영상 제작
Sora : AI 기반 영상 제작
Midjourney : AI 기반 사진/영상 제작
Suno : AI 기반 음원 제작
AIVA : AI 기반 음원 제작

Foot Note
1) 계획 모듈 (Planning Module)
간단하게 보면 아래와 같이 구성된다.

사용자 Input에 대해 "사용자가 요청한 내용에 대해 세부적으로 분석하고 단계를 나누어서 플래닝해줘. 플래닝 결과는 내 코드가 이해할 수 있도록 json 포맷으로 리턴해. 포맷에 대한 스펙은 아래와 같아..(중략).." 라고 System Prompt로 LLM에게 요청함
LLM은 요청한 내용에 대해 플래닝을 세워서 응답을 리턴함.
계획 모듈은 받은 응답을 가지고 내부 로직을 동작시킴

즉, 사용자의 요청에 대해서 LLM에게 플래닝을 만들도록 요청하고, 그 응답을 가지고서 내부 로직을 통해서 하나하나 실행시키는 모듈이다.
사용자가 만약 "내일 날씨 확인해서 마곡 데이트 코스와 식당 추천해 줘" 라고 요청했을 때, LLM에게 플래닝을 요청하면 아래와 같이 응답이 올 것이다.

내일 날씨 확인하기
마곡 지역 데이트 코스 검색하기
마곡 지역 식당 검색하기
날씨에 맞는 데이트 코스 찾기
데이트 코스에 알맞는 식당 찾기
최종 결과 종합하여 응답하기

계획 모듈은 위 응답을 받고, 6개의 단계를 하나하나 세부적으로 실행할 것이다.

2) 기억 모듈 (Memory Module)
간단하게 보면 아래와 같이 구성된다.

기본적으로 기억 DB에 사용자의 개인정보를 저장 및 특정 키워드를 통해 검색도 가능하게 구현되어 있다.
사용자 Input에 대해 먼저 "사용자의 요청사항에 대해 개인 기억 저장소에서 검색해야 하는 키워드를 찾아줘" 라고 LLM에게 요청한다.
LLM이 키워드를 리턴해주면 해당 키워드로 기억 DB를 조회하고, 이를 System Prompt에 추가한다.
최종 결과 응답 이후에 "전체 대화 맥락에서 장기적으로 기억해야 하는 사항이 있으면 응답해 줘. 없으면 없다고 대답해 줘." 라고 LLM에게 요청한다.
응답이 있으면 기억 DB에 저장하고, 없으면 무시한다.

결론적으로 사용자 요청에 대해서 LLM에게 기억을 조회해서 System Prompt에 추가하게 하거나 저장하게 하는 모듈이다.

3) 검색 모듈 (Retrival Module)
RAG과 같은 벡터 DB 검색 기능.
최신 정보나 서비스 제공자가 LLM이 알았으면 하는 정보를 담은 벡터 DB가 있다면, 사용자 Input을 먼저 벡터 DB 조회 후 결과를 System Prompt에 같이 추가한다. 그러면 LLM은 자연스럽게 최신 정보를 미리 전달받은 상태로 사용자 요청사항에 대해 처리할 수 있게 된다.

4) 도구 모듈 (Tool Module)
LLM이 함수를 호출하고 결과를 이용할 수 있게 하는 기능.
예를 들어 read_excel_file()이라는 함수를 개발자가 구현했고 LLM에게 이 함수를 호출할 수 있게 제공한다면 LLM은 이제부터 엑셀파일에 접근할 수 있게 됨.