Multi Agent System을 만들기 위해서GPT를 시작으로 다양한 LLM 모델들이 나오면서 IT 분야 업무 프로세스에 변화가 많이 일어났습니다. LLM 분야도 단순히 Generative AI (ChatGPT, Gemini 등)를 시작으로 Agentic AI (Cursor, ClaudeCode, Opencode 등)으로 발전해 오면서 기존에 요구되었던 능력의 범위가 많이 축소 된 것으로 느껴집니다. 기존에는 취약점 분석을 하기 위해서 필요한 '타겟 언어 숙지, 취약점 분석 도구 사용 방법, 리버싱, 리포팅' 능력들이 많이 중요했지만 지금 현재 LLM 시대에서는 예전 처럼 해당 능력에 대해서 Deep하게 알아야 한다기 보다는 개념과 방법론 그리고 스스로 AI가 내뱉어주는 결과물을 보고 오탐을 판단할 수 있는지 정도로 범위가 바뀐 것 같습니다. 이렇게 특정 부분 부분들이 AI로 대체가 가능해진 시대에서 제가 가장 중요하게 생각하는 능력은 나의 업무를 AI에게 "Delegation(위임)"하는 능력이 중요하다고 생각합니다. 제가 느끼는 Delegation의 능력은 '내가 해야하는 업무를 수행할 수 있는 복제 인력'을 만드는 시스템을 구축 할 수 있는가 없는가에 대한 능력인 것 같습니다. 결국 복제 인력을 만들기 위해서는 현시점에서 가장 활발하게 운용되고있는 AI Agent를 스스로 구축할 수 있는가 없는가가 큰 분별점이 될 것 같습니다. 그래서 이번 포스트에서는 'AI Agent를 만든다는 것은 무엇인가, 필요한 요소, Multi Agent System에 대해서, 결론'등에 대한 이야기를 해보겠습니다. # AI Agent란? AI Agent를 Generative AI와 비교해서 간단하게 설명을 해보겠습니다. Generative AI는 우리가 흔히 구독해서 사용하고 있는 ChatGPT, Claude, Gemini 등의 채팅 형식의 AI를 Generative AI라고 보면 됩니다. Generative AI는 우리가 요청하는 입력에 맞게 생성물을 만들어 주는 기본적인 역할만 합니다. 우리가 결과물의 수정이 필요할 때 마다 다시 채팅에 입력을 하고 결과를 받고 결과를 직접 봐야하는 즉 AI가 작업을 하는 것이 아닌 사람지 직접 작업하게 되는 형태가 됩니다. 반대로 Agentic AI는 시스템만 구축되면 요청된 업무에 대해서 스스로 작업하고 코드에 문제가 생기면 스스로 디버깅하여 수정하고 적용해 Generative AI와는 다르게 사람의 개입이 없어진다는 점에서 Generative AI와 Agentic AI와의 큰 차이가 발생합니다. 그럼 이렇게 요청된 작업을 사람의 개입이 최소화 되도록 하는 이 Agent System을 만들기 위해서 어떠한 내용들을 봐야하는지 이어서 이야기 해보겠습니다. # 1. Domain 좁히기 우리가 사용하는 GPT, Claude, Gemini는 '범용 LLM'이라고 생각하시면 됩니다. 어느 한 특정 분야에 특화되어 만들어진 모델이 아닌 어느 분야 어떤 상황에도 사용할 수 있도록 만들어진 범용성이 높은 LLM 입니다. '범용성이 높다' 라는 키워드만 본다면 '범용성이 높으면 좋은거 아닌가?' 하고 보통 생각합니다. 나쁜 것은 아니지만 우리가 평소에 LLM을 사용했을 때의 불편 상황을 생각해 봅시다. 가장 대표적인 것은 '똑같은 질문을 했는데 매번 다른 답변이 나오는 상황' 입니다. 이런 상황이 나오는 이유는 범용성이 높은 LLM의 경우 해당 질문에 특화된 추론 가이드가 정해져 있지 않아 기본 세팅대로 추론 및 결론 도출이 이루어지기 때문에 매 질문, 매 세션마다 추론하는 시작점이 달라지는 경우가 존재해 동일한 질문을 해도 다른 답변을 할 가능성이 높아집니다. 결국 우리가 원하는 작업에 특화되도록 하기 위해서는 기존에 적용 도메인이 넓었던 LLM에서 내가 원하는 작업 특화 도메인으로 좁히는 스킬이 필요합니다. ## 1-1. Fine Tuning과 System Prompt에 대해서 Fine Tuning을 간단하게 설명하자면 다음과 같습니다. 우리가 GPT, Claude, Gemini를 사용할 때 특정 채팅 세션에서 동일한 주제로 대화를 이어가다 보면 갑자기 다른 주제로 넘어가도 기존에 해왔던 주제를 연관지어 답변을 받아본 경험이 있을 겁니다. 이렇게 LLM에게 특정 대화 주제에 대한 세션을 만드는 방법론을 Fine Tuning이라고 생각하시면 편합니다. 지금도 필요에 따라 Fine Tuning 기법이 필요한 경우에 Fine Tuning을 사용하기도 하지만 이 방법론을 사용하기 위해서는 '채팅 - 결과'에 대한 데이터셋 수집이 필요하고 이 데이터 셋을 적용하는데에 따른 API 비용이 추가로 들어가게 됩니다. System Prompt는 다음과 같습니다. 우리가 사용하는 ChatGPT, Gemini, Grok, Claude 등의 챗봇 서비스에 '나만의 \~\~만들기'와 같은 기능을 본 적이 있으실 겁니다. 이 기능은 간단하게 이해하자면 '내 입맛에 맞게 혹은 내 목적에 맞게 답변'을 해주도록 설정하는 기능입니다. 여기서 이 기능에 입력하는 우리의 요구사항들이 'System Prompt'라고 이해하시면 편합니다. System Prompt는 Fine Tuning과 다르게 별다른 데이터셋, API 비용이 들지 않고 단순히 가이드 라인에 대한 Prompt 내용만 있으면 됩니다. 예전 GPT3 시절의 Pre Trained LLM Model의 기본 성능이 부족해 System Prompting의 능력 발휘가 제대로 되지 않았지만 현재 나오는 GPT5시대의 모델들의 기본 성능이 충분해져 System Prompt의 성능이 발휘되기 시작했고 이로인해 Agent의 개념이 제대로 쓰이기 시작했습니다. ## 1-2. Agent 위 Document에 있는 내용과 같이 특정 작업을 수행하는 Agent를 만드는 방법론이 나와있습니다. Claude Code 기준으로는 `Agent.md` 파일정의가 Agent가 되게 됩니다. 실사용에서 가장 많이 마주하는 Agent는 'Explore, Plan' Agent일 겁니다. Claude Code 혹은 이전에 Cursor나 Gitgub Copilot을 시용해본 분들이라면 Agent 설정 중에 Plan, Build와 같은 설정을 보셨을 겁니다. 여기의 이 설정들이 각각의 지정된 Agent라고 보시면 됩니다. 예를 들어 우리가 Plan 모드의 Agent를 사용한다면 다른 작업 말고 딱 Planning을 해주는 역할만 진행하게 됩니다. 이렇게 특정 행동만 할 수 있도록 만들어 준 것이 System Prompt라고 생각하시면 됩니다. ``` --- description: Reviews code for quality and best practices mode: subagent model: anthropic/claude-sonnet-4-20250514 temperature: 0.1 tools: write: false edit: false bash: false --- You are in code review mode. Focus on: - Code quality and best practices - Potential bugs and edge cases - Performance implications - Security considerations Provide constructive feedback without making direct changes. ``` opencode Document에 나와있는 Agent 정의 방법 처럼 하단 섹션에 내가 만들 Agent가 수행해야할 Task에 대한 가이드라인을 설계하면 Agent 개발이 완료가 됩니다. # 2. Multi Agent System 현재는 앞에서 언급한 Agent를 요청받은 작업에 대해서 특정 세부 사항에 필요한 업무에 대한 Agent를 선택해서 단일 Agent를 사용해서 작업을 하는 것이 아닌 요청받은 작업이 있다면 그대로 시스템에 입력을 하고 해당 작업에 존재하는 세부 작업 사항에 맞는 Agent를 필요에 맞게 호출해 Multi Agent System이 운용되도록 합니다. 쉽게말해 Multi Agent System 운용은 'Front, Back, Design'등 각 작업에 맞는 Agent가 만들어 진 상태에서 요청된 작업에 대해서 각 에이전트의 작업이 서로 공유가 되며 하나의 팀처럼 작업하도록 운용하는 체계입니다. 이 Multi Agent System을 위해서는 orchestration이 중요합니다. ## 2-1. Orchestration Orchestration Agent는 쉽게 말해 각 부서에 업무를 배정하는 리드의 역할을 만드는 것이라고 생각하시면 됩니다. Claude Code Teams가 나오기 이전에는 opencode의 `oh-my-opencode`플러그인의 등장으로 opencode가 claude code보다 성능이 좋다는 평이 많았습니다. 이랬던 이유는 oh my opencode의 Sysiphus Orchestration Agent 였습니다. 이 oh my opencode의 Sysiphus는 대략 아래와 같이 작업합니다. ``` 입력받은 요청을 파악 | Plan Agent인 Prometheus에게 Plan 받기 | 받은 Plan을 기반으로 각 단계에 필요한 Agent 설계 및 호출 ``` 단일 Agent로 작업을 처리하는 것이 아니라 각 단계에서 만약 FrontEnd 개발자가 필요하다면 FronEnd Agent를 설계해서 호출하고 BackEnd가 필요하면 BackEnd Agent를 설계 호출, 코드 리뷰가 필요하면 Code Review Agent를 설계해서 호출하는 등 본인이 맡은 작업에 특화해서 Agent가 설계되고 호출하여 작업해 맡은 작업의 혼동이 줄어들게 됩니다. 이 구조는 마치 한 회사의 개발'팀'처럼 움직이는 것으로 보여지게 됩니다. 결국 앞에서 언급한 특정 작업에 대한 Agent를 만드는 것도 중요했지만 이렇게 요청 작업을 파악하고 업무를 분배하는 Orchestration Agent를 잘 만드는 것도 AI를 통해 좋은 결과물을 만드는 능력중에 하나입니다. 만약 Orchestration의 설계에 대한 아이디어를 얻고싶다면 위의 oh my opencode git에 정의되어있는 Sisyphus Agent의 System Prompt 정의를 보시면 될 것 같습니다. # 3. 퀄리티를 높이는 몇 가지 방법론 우리가 Agent를 만들 때 이 Agent가 좀 더 정확하고 퀄리티있는 답변을 내놓도록 하기 위한 간단한 방법론에 대해서 이야기 해보겠습니다. ## 3-1. XML tags 좀 더 퀄리티 있는 Agent를 만들기 위한 방법론 중 하나는 XML Tag를 이용해 System Prompt를 구성하는 것 입니다. 우리가 System Prompt를 작성할 때 아무리 대제목 소제목 등을 이용해 섹션을 나눈다 하더라도 AI가 해당 섹션 구분 자체를 못하게 되는 경우가 발생할 수도 있습니다. 이런 가이드라인의 섹션 구분이 제대로 이루어 지지 않으면 혼동이 발생할 수도 있습니다. 이렇게 작업에 대한 섹션 구분을 제대로 하기 위한 방법 중 하나가 XML tag를 이용하는 것 입니다. ``` When writing reports, documents, technical explanations, analyses, or any long-form content, write in clear, flowing prose using complete paragraphs and sentences. Use standard paragraph breaks for organization and reserve markdown primarily for `inline code`, code blocks (```...```), and simple headings (###, and ###). Avoid using **bold** and *italics*. DO NOT use ordered lists (1. ...) or unordered lists (*) unless : a) you're presenting truly discrete items where a list format is the best option, or b) the user explicitly requests a list or ranking Instead of listing items with bullets or numbers, incorporate them naturally into sentences. This guidance applies especially to technical writing. Using prose instead of excessive formatting will improve user satisfaction. NEVER output a series of overly short bullet points. Your goal is readable, flowing text that guides the reader naturally through ideas rather than fragmenting information into isolated points. ``` 위의 예제와 같이 ``의 태그를 이용하므로써 `avoid_excessive_markdown_and_bullet_points`이 작업을 위한 가이드라인 섹션을 완전히 구분하고 가이드를 잡을 수 있도록 합니다. 이 XML Tag가 Agent에게 가이드를 잡아주기 위한 하나의 언어라고 보시면 됩니다. 만약 Code Review 프롬프팅이 필요하다 라고 하면 ``태그와 같은 것으로 구분해서 가이드를 잡아주시면 됩니다. ## 3-2. Output Format 정의하기 Output Format을 정의하는 것은 'AI를 똑똑하게 사용하기'와 같은 포스트에서 많이 나오는 이야기 중 하나입니다. 이게 중요한 이유는 글 초반에 이야기 했던 '동일한 질문에 다르게 답변하는 상황' 때문입니다. 우리가 어느정도 AI가 뽑아주는 코드의 형태가 정해져 있으면 만약 사람이 직접 디버깅을 해야하는 상황이 생기면 어떤 상황에서 코드를 뽑아주더라도 디버깅을 하기 용이해 지기 때문입니다. 그리고 이런 포멧이 정해져 있으면 특정 에이전트가 분석한 결과를 다른 에이전트로 결과를 공유하는 작업을 할 때도 어느정도 용이해지게 됩니다. AI는 매번 자기 마음대로 생각해 작업을 하는 친구이기 때문에 추론 과정 가이드라인 뿐만 아니라 이런 최종 결과물에 대한 포멧을 정해주는 것도 중요합니다. ## 3-3. ETC. 이 방법 외에도 시스템 구성적으로 RAG, MCP, Skills의 개념도 있습니다. 이 모든 방법론을 적용한다해서 좋은 Agent System이 만들어지는 것이 아니고 이 개념들 중에 내 작업 시스템에 필요한 개념들만 System에 적용해야 합니다. 안그러면 Agent가 어느걸 사용해야할지 혼동이 오게되어 작업이 오히려 비효율적이게 되고 API 비용도 많이 부과되게 됩니다. # 4. 그러면 우리 공부 안해도 됨? 이렇게 앞의 내용을 봤을 때는 '이제 우리 막 열심히 공부할 필요 없겠네?'라는 생각이 들 수 있습니다. 하지만... 더 열심히 공부해야만 합니다. ## 4-1. Hallucination Hallucination은 LLM의 가장 큰 문제점입니다. Hallucination은 틀린 내용을 마치 맞는 내용인것 마냥 답변을 내놓은 현상이라고 생각하시면 됩니다. 우리가 이런 현상을 발견하기 위해서는 이 결과물이 실제로 참인 결과물인지 판단하는 능력이 필요하기에 오히려 해당 작업 도메인에 대한 전문지식을 잘 쌓아야 합니다. 이렇게 Hallucination 결과물을 파악하기위해서 뿐만 아니라 앞으로 내가 구축한 Agent가 Hallucination 결과물을 내놓지 않도록 하기위한 가이드라인을 구축하는 것 또한 해당 도메인에 대한 전문지식이 있고 해결 방법을 알고 있는 사람만이 Hallucination을 최소화 할 수 있기 때문에 기존처럼 열심히 공부하되 공부의 방향성이 바뀐 분위기인 것 같습니다. ## 4-2. 경험담 최근에 저는 제가 Vulnerbility Research를 할 때 작업하는 Process를 그대로 Multi Agent System에 접목시켜 11개의 Agent가 어느정도 유기적으로 돌아가는 시스템을 간단하게 만들고 테스트해봤습니다. 이 시스템의 적용 분야는 Web3 Smart Contract Audit 분야였습니다. 그냥 단일 Agent로 '취약점을 찾아줘' 처럼 '해줘' 형식으로 사용했을 때는 Hallucination 결과물이 대부분이었습니다. 앞의 내용을 토대로 구축을 하니 Hallucination 결과물이 많이 줄어들고 Valid한 취약점이 나오기 시작했었습니다. 하지만 한계는 금방 마주하게 되었습니다. 저는 Web3 Smart Contract Audit 분야에 지식의 깊이가 많이 깊은 편이 아닙니다. 이런 제가 시스템을 구축을 하니 이 Agent System도 제 수준의 사람이 발견할만한 취약점만 발견하는 것을 포착하게 되었습니다. 장점이라고 하면 제가 해당 Audit을 진행하기 위해 Documnet를 이해하고 Code Base를 파악하고 분석하는데에 2주가 걸린다고 하면 이 시스템은 몇 시간 이내로 작업이 완료 된다는 장점이 있었습니다. 결국에는 제 이 경험에서는 능력있는 Agent System을 만들기 위해서는 만드는 사람 자체가 해당 분야에 능력이 있어야만 한다는 것을 느끼게 되었습니다. 그러니 여전히 공부를 더 해야 하는 것 같습니다... # 마무리 이번에는 최대한 비전문가도 읽을 수 있을 정도의 내용만 담았습니다. 이 글을 통해서 Agent 개발에 관심을 갖거나 입문에 용이해졌으면 좋겠습니다. 향 후 경험담에 있는 Agent System 개발 과정 및 결과에 대해서 공유하는 포스트로 돌아오겠습니다.