[AI-Agent] LLM 에이전트 설계, 더 똑똑하게 일하게 만드는 6가지 핵심 설계 요소

들어가기 전에

지난주 단톡방에 설계 관련해서 얘기를 나누자고 했는데, 내가 또 설명을 또 어중간하게 했는지

나연이가 다음과 같은 내용이 맞나고 확인을 요청했다.

오늘 스터디에서 설계 관련해 얘기하겠다고 했는데 이런 얘기를 다루자는게 맞아요?

 

 나는 이 메시지가 꽤 반가웠는데

AI에게 질문해서 받은 답변이라고는 했지만, 설계 관점에 대해 고민해서 질문을 해준것이 기특하기도 하고 내가 생각하지 못했던 관점을 다시 한번 돌아볼 수 있었기 때문이다.

 

 보내준 내용을 보니 단톡에 올렸을 당시 내가 생각했던 방향과는 달랐으나, 설계라는 관점에서는 꼭 짚고 넘어가야 할 내용들이 담겨 있었다.

나는 요구사항 분석을 먼저 이야기하려고 했는데, '설계'라는 큰 단어만 던지다 보니 서로 생각하는 범위가 달랐던 것 같다.

 

 질문 자체는 짧았지만, 내용을 보면서 느낀 것은

'사용자가 무엇을 원하는가'도 중요하지만 'AI Agent는 그 문제를 어떻게 해결하도록 설계할 것인가'라는 한 단계 더 높은 관점까지 논의가 필요하겠구나 였다.

 

 AI 서비스를 공부하다 보면 기능 구현에만 집중하기 쉽다.

하지만 이렇게 한 번 뱡향을 확인하는 질문 덕분에 공부해야 할 범위가 더 선명해질 때가 있다.

 

 결론적으로 나연이가 공유해 준 내용을 계기로 "우리가 Agent를 구현하려면 먼저 어떤 관점으로 설계해야 하는가"를 함께 공부하는 것이 좋겠다는 생각이 들었고, 이번 주 스터디 주제도 그 방향으로 정하게 되었다.

---

참고사항

---

참고1 : 

 

GPT에게 AI Agent의 설계 과정을 물어보니 다음과 같은 흐름으로 정리해 주었다.

"무엇을 만들 것인가?" → "업무를 어떻게 분해할 것인가?" → "Agent가 필요한가?" → "어떤 아키텍처를 선택할 것인가?" →
"도구는 무엇을 붙일 것인가?" → "어떻게 평가할 것인가?"

 

OpenAI, Anthropic, LangGraph 등 여러 AI Agent 관련 가이드를 살펴보면 문제 정의 → Task 분해 → Agent 구조 선택 → Tool 연동 → Evaluation의 흐름을 공통적으로 다루고 있다. 위 순서는 이러한 공통된 내용을 바탕으로 이해하기 쉽게 정리한 설계 흐름으로 이해하면 된다.

---

참고2 : 이전 시간 건희님이 공유해주신 자료

 

 하지만 실제 프로젝트에서는 이 과정을 한 번만 수행하고 끝나는 경우는 거의 없다.

아래 그림처럼 계획을 세운 뒤 생성과 검증을 반복하고, 실행 과정에서 문제가 발생하면 다시 계획 단계로 돌아가 설계를 수정한다.

건희님의 발표자료

 

 즉, 설계는 일직선으로 진행되는 작업이 아니라 반복(Iteration)을 통해 점점 완성도를 높여 가는 과정이다.

따라서 AI Agent를 설계할 때도 처음부터 완벽한 구조를 만드는 것보다 작게 설계하고, 검증하고, 다시 개선하는 과정이 훨씬 중요하다.

이번 글에서는 이러한 반복적인 설계 과정 중에서도 가장 첫 번째 단계인 '무엇을 만들 것인가'와 '업무를 어떻게 분해할 것인가'를 넘어, AI Agent를 어떤 관점에서 설계해야 하는지를 중심으로 살펴보려고 한다.

---

 

패스하시오 : 해당 부분은 요구사항 분석과 관련 된 내용이어서 접은글로 정리하려 한다.

AI 회의록 Agent를 만든다면 무엇부터 설계해야 할까?

 

회의록 Agent를 만든다고 하면 많은 사람들이

• ReAct
• Memory
• MCP
• Multi Agent

같은 기술부터 공부하려고 한다.

하지만 현업에서는 순서가 완전히 다르다.

AI Agent는 기술을 먼저 선택하는 것이 아니라 문제를 먼저 분석한다.

이번 글에서는 실제 AI Architect가 회의록 Agent를 설계하는 사고 과정을 따라가 보자.

---

1. 가장 먼저 하는 일은 "문제 정의"

 

AI는 기술이 아니라 문제 해결 도구다.

따라서 가장 먼저 결정하는 것은

"우리는 정확히 무엇을 자동화하려는가?"

이다.

예를 들어 "회의록 작성"이라고 해도 종류가 매우 많다.

• 회의 내용을 그대로 기록하는 것인가?
• 요약본을 만드는 것인가?
• Action Item을 추출하는 것인가?
• 일정까지 등록하는 것인가?
• 이전 회의와 연결하는 것인가?

이것에 따라 Agent 구조가 완전히 달라진다.

예시)

회의 음성
↓
텍스트 변환
↓
회의록 작성

 

와

회의 음성
↓
텍스트 변환
↓
회의 요약
↓
담당자 추출
↓
Action Item 생성
↓
Google Calendar 등록
↓
Notion 저장

 

은 난이도가 완전히 다르다.

---

2. 정말 Agent가 필요한 문제인가?

 

이 질문을 의외로 많은 사람들이 하지 않는다.

요즘은 뭐든 Agent를 붙이려고 하지만 사실 대부분은 Agent가 필요 없다.

예를 들어

회의 음성
↓
Whisper
↓
GPT
↓
회의록 출력

 

이면 끝나는 서비스도 많다.

이건 Agent가 아니라 Pipeline이다.

반대로

회의 내용 분석
↓
회의 일정 확인
↓
캘린더 조회
↓
담당자 검색
↓
메일 발송
↓
문서 저장

 

처럼 상황에 따라 어떤 Tool을 사용할지 AI가 스스로 판단해야 한다면 그때 Agent가 필요하다.

즉 Agent는 "도구를 선택하는 AI"이다.

---

1. 회의록 에이전트 자체의 업무(Task) 분해

: 업무(Task)를 어떻게 분해할 것인가?

 이 단계가 AI 설계에서 가장 중요하다.

복잡한 작업을 작은 단위로 쪼개는 '분해(Decomposition)' 과정은 성능 향상의 핵심이기 때문이다.

회의록 작성은 하나의 작업처럼 보이지만 실제로는 여러 개의 Task로 나눌 수 있다.

---

회의 음성 → STT → 화자 분리 → 오탈자 보정 → 문맥 보완 → 요약 → 의사결정 추출 → Action Item 추출
→ 회의록 생성 → 문서 저장

---

여기서 중요한 것은 각 단계를 하나의 LLM 호출로 처리할지, 여러 단계로 나눌지를 결정하는 것이다. 

예를 들어

STT → GPT → 끝

 

처럼 한 번에 처리하면 구현은 쉽다. 이는 Agent라 부르기도 민망할 뿐더러

---

1) 수정이 어렵고

    : LLM이 한 번에 너무 많은 역할을 하면 문제가 생겼을 때 어디가 잘못됏는지 찾기 어려워진다.

 

예를 들어, 회의 음성이 있다고 하자.

회의 음성 GPT 회의록

 

그리고 Prompt는 하나이다.

너는 회의록 AI야.

1. STT도 하고
2. 화자도 구분하고
3. 오탈자도 수정하고
4. 요약도 하고
5. Action Item도 추출하고
6. JSON으로 만들어.

 

끝. 엄청 간단하다. 그런데 결과가 이렇게 나왔다.

회의 참석자
김철수
이영희
회의 내용 ...
Action Item
없음

 

근데 실제 회의에서는

김철수 "내일까지 API 수정해주세요."

 

라고 말했음에도 Action Item이 사라진 것을 볼 수 있다.

 

그럼 문제는 어디일까?

가능성이 너무 많다.

 

① STT가 잘못 인식했다.

API 수정해주세요 → AP 수정해주세요

 

② 화자분리가 틀렸다.

김철수 → 이영희

 

③ GPT가 요약하면서 삭제했다.

중요하지 않다고 판단

 

④ Prompt가 애매했다.

Action Item은 중요한 것만 추출해.

 

GPT가

"이건 중요하지 않네."

라고 판단했다.

 

도대체 어디가 문제인지 알 수가 없다.

그런데 Task를 분리하면?

회의 음성 → STT → 텍스트 → 화자분리 → 텍스트 → 요약 → Action Item → 회의록

 

이제 확인할 수 있다.

 

STT 결과

내일까지 API 수정해주세요.

 

정상

Action Item

없음

 

여기서 문제 발견.

Action Item Prompt만 수정하면 된다.

그래서 수정이 쉽다는 것이다.

---

2) 디버깅이 어렵고

    : 개발하면서 로그를 찍는다고 생각해보자.

 

Pipeline이면

STT 결과 → 화자분리 결과 → 요약 결과→ Action Item 결과

 

전부 로그를 볼 수 있다.

하지만

One-shot이면

입력 → GPT → 출력

 

끝이다.

중간이 없는 것이다.

개발자는 중간 겨로가가 없으면 디버깅이 어렵다.

---

3) 비용이 커질 수 있다.

 

이 부분은 상황에 따라 다르지만

예를 들어

회의가 100페이지라고 가정해 보자.

 

One-shot이면 매번

100페이지 + Prompt → GPT

 

를 보내는데 이는 엄청 길다.

하지만 Task를 나누면 

예를 들어 요약은 100페이지를 10페이지로 줄일 수 있게 되고 그 다음 Action Item은 10페이지에서만 추출하면 된다.

회의록 작성도 10페이지만 보게되고 뒤로 갈 수록 Token이 줄어들 수 있다.

 

하지만 반대로 Task를 너무 많이 쪼개면 LLM 호출이 쪼개진만큼 늘어나게 되므로 API 비용이 증가할 수 있다.

 

* Task를 작게 나누면 각 단계를 독립적으로 개선할 수 있다.

---

그렇기 때문에 좀더 Task를 세부적으로 나누면 다음과 같이 정리할 수 있다.

 

회의록 태스크 분해 및 Chaining 전략

 

: 회의록 생성 과정은 단순히 텍스트를 요약하는 단계를 넘어, 데이터의 원천(Raw Data)을 가치 있는 정보(Actionable Insight)로 전환하는

연속적인 과정이다.

 

모든 과정을 하나의 프롬프트로 처리하면 환각 현상이 발생하거나 컨텍스트 창이 오염된다.

각 단계를 다음과 같이 세분화 한다.

 

1. 전처리 (STT, Speech-to-Text): 오디오 데이터를 텍스트로 변환하는 기초 단계이다.

    단순히 음성을 텍스트로 옮기는 것을 넘어, 회의 상황의 소음 제거나 오디오 샘플링 레이트 조정을 포함한다.

 

2. 화자 구분 (Diarization): "누가, 언제, 무엇을 말했는가"를 정의합니다. 단순 발화자 매핑을 넘어, 발화 순서와 빈도를 분석하여 회의 참여도를

     파악하는 기초 자료로 활용될 수 있다.

 

3. 정제 (Cleaning): 구어체로 작성된 텍스트를 문어체로 다듬는다.

     AI가 이해하기 쉬운 문장 구조로 변환하여 이후 단계인 요약의 정확도를 높이는 작업이다.

 

4. 발언 정리 (Normalization): 비언어적 표현인 필러(음, 어, 그 등)를 제거하고 문맥을 보정한다.

    이는 텍스트의 토큰 효율성을 극대화하여 LLM이 핵심 의미에 더 집중할 수 있게한다.

 

5. 요약 및 구조화 (Summarization & Structuring): 회의의 주요 안건별로 논의 내용을 분류하고 핵심을 요약한다.

    전체 컨텍스트를 유지하면서 불필요한 정보는 버리는 '정보 압축'이 핵심이다.

 

6. 액션 아이템 추출 (Action Item Extraction): 회의에서 결정된 '할 일'을 누락 없이 추출하고 목록화한다.

     이는 회의록의 생산성을 결정짓는 가장 중요한 출력물이다.

 

7. 포맷팅 (Formatting): Markdown 혹은 JSON 구조로 변환하여 2차 활용성을 확보한다.

    특히 JSON 모드로 출력하면 API 연동을 통해 사내 캘린더나 프로젝트 관리 툴(노션, 지라 등)로 즉시 자동 전송이 가능해진다.

 

Tip: 각 단계마다 다른 프롬프트를 사용하는 Chaining(연쇄) 방식을 통해 개별 단계의 품질을 검증(Validation)하기 쉽게 설계하도록 한다.

---

정리필요한 부분

 

■ 입력 : 음성/텍스트, 화자 분리 필요 여부

(화자 분리 필요 여부는 화면에서 체크 박스로 처리 여부를 선택하는 것을 말한 걸까?

그렇다면 이것 말고도 추가될 수 있는 것들을 생각해보아야 할것이다.)

■ 처리 단계 예시 : STT(음성인식) 화자 구분 발언 정리 요약/구조화 액션 아이템 추출 포맷팅

(여기서 요약 구조화보다 액션 아이템 추출이 먼저가 아닌가 싶었다.)

■ 각 단계를 하나의 LLM 호출로 묶을지, 여러 단계로 쪼갤지(Chaninig)

---

2. 에이전트 아키텍처 패턴 결정

: 어떤 아키텍처를 선택하고 AI에게 어떻게 일을 시킬 것인가?에 대한 구조적 접근으로

회의록 에이전트의 복잡도에 따라 최적의 패턴을 선택해야 한다.

 

즉, Task가 정해졌다면 그 다음이 Architecture이다.

---

■ 2.1. One-shot(단일 프롬프트)

prompt → GPT → 회의록

 

 질문 하나에 답변 하나를 얻는 가장 단순한 형태로, 복잡한 추론이 필요 없는 간단한 요약이나 짧은 회의, 번역에 적합하다.

---

■ 2.2.1 Simple Pipeline (파이프라인형)

 

정형화된 입력(텍스트)에서 요약, 추출만 필요할 때 유리하다.

구조가 단순하여 지연 시간이 짧고 비용 효율적이다.

 

■ 2.2.2 (멀티스탭)Pipeline

STT→ 정제 → 요약 → Action Item → 회의록

 

 작업을 여러 단계로 나누어 각 단계를 순차적으로 처리한다. 각 단계의 출력이 다음 단계의 입력이 된다.

가장 많이 사용하는 구조라 한다.

---

■ 2.3. ReAct(Reasoning + Acting)

생각 → Tool 호출 → 결과 확인 → 다시 생각 → 다른 Tool 호출

 

 LLM이 '생각(Reasoning)'하고 그 결과를 바탕으로 '외부 도구(Action, 예: 검색, DB 조회)'를 사용한 뒤, 그 결과를 관찰하여 다음 추론을 이어가는 방식이다. 복잡하고 동적인 환경에서 문제를 해결할 때 필수적이다.

 

회의록을 기준으로 보면

회의록 작성 중 외부 정보(캘린더, 사내 위키 등)가 필요하거나, 화자 정보 확인을 위해 특정 API를 호출해야할 때 필수적이다.

추론과 행동을 반복하며 복합적인 태스크를 해결한다.

 

쉽게 설명하자면

 

회의 내용을 보고

"캘린더를 조회해야겠다."

"메일을 보내야겠다."

같은 판단이 필요한 경우 사용한다.

---

■ 2.4. Multi-Agent

Meeting Agent → Summary Agent → Action Agent → Calendar Agent → Document Agent

 

역할별 Agent가 협력한다,

복잡한 기업용 서비스에서 많이 사용한다.

---

■ 2.5. Orchestrator-Worker 패턴

Orchestrator → STT Worker → Summary Worker → Action Worker → Document Worker → Orchestrator
Orchestrator → Meeting Worker → Summary Worker → Action Worker → Calendar Worker → Orchestrator

 

 중앙 관리자(Orchestrator)가 큰 작업을 작은 단위로 쪼개어, 각 분야에 특화된 하위 에이전트(Worker)들에게 작업을 위임하는 구조이다.

'통제자(Orchestrator)'는 전체 흐름과 제어권을 갖고, '작업자(Worker)' 에이전트들은 각각 [STT 변환], [요약], [액션 아이템 추출] 등 특화된 작업만 수행하여 모듈성을 높일 수 있다. 더불어 대규모 시스템 구축 시 유지보수와 확장이 용이하다.

---

※ 용도에 따른 선택 : 회의록 작성처럼 정해진 문맥 안에서 구조화가 핵심이라면 단순 파이프라인형으로 충분할 수 있지만, 외부 문서 검색이나 특정 DB연동이 필요한 상황이라면 ReAct형 에이전트가 필수적이다.

---

3. 상태 관리와 메모리 설계

: 메모리는 어디까지 사용할 것인가?

회의록은 메모리가 중요한 서비스이고, 장기적인 컨텍스트를 유지하는 것이 에이전트의 지능을 결정한다고 볼 수 있다.

 

예를 들어

지난 회의에서 결정했던 내용 이어서 정리해줘.

 

라는 요청을 처리하려면 이전 회의를 기억해야하고 

만약 3시간짜리 회의를 처리해야한다면 소화할수 있는 컨텍스트 길이를 넘어갈 수 있으므로

 회의 → chunking → 부분 요약 → 재요약 → 최종 회의록

 

같은 구조를 설계해야 한다.

---

 

구체적인 예시를 들자면

 

■ 컨텍스트 윈도우 관리: 긴 회의록은 청킹(Chunking)을 통해 나눈 뒤, 각 청크를 요약하고 최종적으로 이를 다시 요약하는

   '재요약(Recursive Summarization)' 기법을 적용한다.

 

■ 세션 관리: 과거 회의의 맥락이 현재 회의에 영향을 준다면, 벡터 데이터베이스(Vector DB)를 활용한 RAG를 통해 과거 기록을 참조하도록 설계한다.

---

4. 툴/외부 연동 설계

: 어떤 Tool을 연결할 것인가?

 Agent는 LLM만으로 일하지 않는다. 외부 시스템과 연결될 수 있으며, 특히나 회의록은 캘린더나 협업 툴과의 연동을 핵심으로 둘 수 있다.

---

예를 들어

Whisper → GPT→ Google Calendar → Notion → Slack → Google Drive

 

이처럼 다양한 Tool을 호출할 수 있다.

---

이때 설계해야하는 것은

 

■ 어떤 Tool을 사용할 것인가

■ 어떤 순서로 호출할 것인가

■ 실패하면 재시도할 것인가

■ Timeout은 얼마인가

 

등이다.

---

구체적인 예시를 들자면

 

 

■ 외부 도구 연동: 캘린더(회의 일정 확인), 사내 문서함(참조 자료 검색) 등을 호출할 수 있는 인터페이스를 정의한다.

 

■ 에러 핸들링: 툴 호출 실패 시 재시도 로직(Exponential Backoff 등)을 구현하여 에이전트의 중단을 방지한다.

---

5. 출력 형식과 프롬프트 구조 설계

: 프롬프트보다는 출력 형식을 먼저 설계해야 하며, 시스템 프롬프트는 에이전트의 페르소나와 제약사항을 강하게 규제해야 한다.

 

 먼저 출력형식에 대해 이야기 하자면

많은 사람들이 프롬프트를 먼저 작성한다.

하지만 현업에서는 JSON Schema를 먼저 만든다.

예를 들어

{
    "title" : ""
  , "summary" : ""
  , "participants" : []
  , "decisions" : []
  , "actionItems" : []
}

 

위와 같이 출력이 정해져야 프롬프트도 작성할 수 있다.

 

이 부분이 잘 이해가 가지 않아서 제미나이에게도 물어보았는데

제미나이 말로는

출력 형식(Output Schema)을 먼저 정의하는 것이 훨씬 효율적이고 안정적이기 때문이라고 했다.

더불어 그 이유와 근거를 실무적인 관점에서 정리해주었다.

---

5.1.1. 시스템 통합의 필수 조건(API)

 

AI Agent는 혼자 노는 것이 아니라, 보통 다른 시스템(데이터베이스, 외부 API, 프론트엔드 등)과 연결된다.

 

■ 근거 : 만약 AI가 프롬프트에 따라 제멋대로 문장을 생성하면, 이를 다시 파싱(Parsing)해서 코드로 처리하는 과정에서 에러가 폭발한다. 출력 형식을 JSON등으로 정해두면, 코드가 AI 응답을 예측할 수 있어 안정성이 비약적으로 상승한다.

■ 실무 팁 : Pydantic 같은 라이브러리를 사용하여 출력 데이터 구조를 먼저 선언해두면, AI가 그 구조를 벗어나지 못하도록 겅제할 수 있다. 

---

5.1.2. '생각의 흐름'과 '결과물'의 분리

 

프롬프트에만 의존하면 AI가 결과물 내에 불필요한 설명(Chatty response)을 포함할 확률이 매우 높다.

 

■ 근거 : 출력 형식을 먼저 설계하면, AI에게 "생각은 내부적으로 처리하되, 출력은 오직 내가 정한 JSON 포맷으로만 해라"라고 명확한 제약을 걸수 있다. 이렇게 하면 데이터를 후처리할 때 불필요한 텍스트를 걷어내는 비용이 사라진다.

---

5.1.3. 평가와 테스트(Evaluation)의 가능성

 

AI의 성능을 측정하려면 결과물이 일관된 형태여야 한다.

 

■ 근거 : 매번 답변 형식이 달라지면 '답이 맞았는지 틀렸는지'를 자동으로 평가하는 로직을 짤 수가 없다. 출력 형식을 정의하면 정형화된 필드 값을

비교하여 AI의 응답 정확도를 수치화하기 쉬워진다.

---

5.1.4. 에이전트의 '도구 호출(Tool Calling)' 원리

 

현대적인 AI Agent 프레임워크(LangChain, LangGraph 등)의 핵심은 Function Calling이다.

 

■ 근거 : AI가 어떤 도구(함수)를 사용할지 결정할 때, 사실상 그 함수의 인자(Argument) 형식(즉, 출력 형식)을 먼저 설계해두는 것이 핵심입니다. 결국 에이전트 설계라는 것 자체가 "AI가 어떤 출력 형식을 내뱉으면, 시스템이 어떤 함수를 실행할지"를 짜는 과정이기 때문에 출력 형식 설계가 선행되어야 합니다.

---

5.2. 추천하는 출력 구조 (JSON 예시) - 이건 추후에 회의록 작성과 관련된 형식으로 수정해야겠다.

{
  "thought_process": "사용자가 Hapjeong-dong의 조용한 카페를 찾고 있으므로, 필터링 조건은 '조용한', '카페', 'Hapjeong-dong'으로 설정함.",
  "search_query": "Hapjeong-dong quiet cafe review ranking"
  , "recommendations": [
    {
        "name": "카페 이름"
      , "category": "문화/관광/맛집"
      , "location": "서울 마포구 합정동"
      , "relevance_score": 0.95
      ,"reason": "왜 이 장소를 추천하는지에 대한 짧은 문장"
    }
  ]
  , "suggested_next_action": "예약하기 또는 지도 보기"
}

---

5.3. 역할 정의

 

 "너는 10년 차 비서이며, 불필요한 감정 섞인 표현은 제외하고 핵심 결정 사항 위주로 기록한다"와 같이 명확한 역할과 제약 조건을 주입한다.

---

6. 품질 평가와 검증(Evaluation)

: 마지막은 평가이다.

 

 AI 서비스는 정답이 없는 시스템이다.

따라서 반드시 평가 기준이 있어야 한다.

또한 에이전트가 생성한 회의록이 정확한지 확인하는 루프를 만들어야 한다.

 

예를 들어 회의록이라면 

 

■ 정확도 평가 : 원문 텍스트의 핵심 키워드가 요약본에 포함되었는지, 할 일(Action Item) 이 누락되지 않았는지

   자동 검증(LLM-as-a-judge 기법 등 활용) 한다.

■ Action Item 누락 여부

■ 화자 구분 정확도

■ Hallucination 발생 여부

■ JSON  형식 준수

■ 처리 속도

■ 비용(Token)

■ 피드백 루프 : 사용자가 수정하거나 수정하사항을 반영할 수 있는 인터페이스를 제공하고, 이를 다시 시스템의 기억으로 저장하는 구조를 갖추어야

   한다.

---

결론

 지금까지 살펴본 내용을 종합해 보면 AI Agent 설계는 단순히 ReAct, Multi-Agent와 같은 기술을 선택하는 것에서 시작하지 않는다.

 

먼저 해결하려는 문제를 정의하고, 이를 작은 Task로 분해한 뒤, Agent가 필요한 문제인지 판단한다.

그 이후에야 적절한 Architecture와 Tool, Memory, Prompt 등을 설계하게 된다.

문제 정의
↓
Task 분석
↓
Agent가 필요한가?
↓
Architecture 선택
↓
Tool 설계
↓
Memory 설계
↓
Output Schema 설계
↓
Prompt 작성
↓
Evaluation 설계
↓
구현

 

이 순서를 잘 기억해두자.

 

 많은 개발자들이... 일단 나부터도 ReAct나 Multi-Agent 같은 기술부터 공부하려고 하지만, 실제 현업에서는 문제를 정의하고 Task를 분석한 뒤에야 아키텍처를 선택한다고 한다. 기술은 목적이 아니라 설계의 결과가 되어야 하는 것이다.

 

어떤 기술을 사용할지는 무엇을 만들고, 어떤 문제를 해결하려는지가 먼저 결정된 뒤에 자연스럽게 따라오는 선택이다.

 

앞으로는 각 단계를 하나씩 더 깊게 공부하며, 실제 회의록 AI Agent를설계하는 과정까지 이어서 정리해보려고 한다. 

---