AI Agent
설계 및 분석
이 실습이 끝나면 비즈니스 요구사항을 4가지 질문으로 정리해 Agent 아키텍처로 바꾸는 방법이 손에 남는다. 뉴스 큐레이터 Agent를 직접 설계하고, Claude Code에 자연어로 지시해 동작하는 프로토타입까지 만들어 본다.
단순 LLM 호출 vs AI Agent
Agent는 한 번 답하고 끝나는 시스템이 아니다. 목표를 달성할 때까지 계획하고, 도구를 쓰고, 상태를 기억하며 반복하는 루프다.
한 번의 응답과 목표 달성 루프의 차이
ChatGPT에 질문 하나를 던지는 것은 단순 LLM 호출이다. Agent는 여기에 도구 사용과 상태 관리를 더해, 목표가 달성될 때까지 스스로 반복한다. 네 가지 축으로 비교하면 차이가 분명해진다.
| 구분 | 단순 LLM 호출 | AI Agent |
|---|---|---|
| 동작 방식 | 입력 → 출력 (1회성) | 목표 달성까지 반복 루프 |
| 도구 사용 | 없음 | 웹 검색, DB 조회, API 호출 |
| 상태 관리 | 없음 | 대화 기록, 작업 진행 상태 유지 |
| 적합한 용도 | Q&A, 텍스트 생성, 번역 | 다단계 업무 자동화, 리서치 |
표에서 결정적인 칸은 도구 사용이다. LLM 자체는 학습 시점 이후의 세상을 모르고, 파일을 만들 수도 API를 부를 수도 없다. 도구가 붙는 순간 "아는 것을 말하는 시스템"이 "일을 해내는 시스템"으로 바뀐다. 나머지 축(반복 루프, 상태 관리)은 도구 호출을 여러 번 이어 붙이기 위해 따라오는 장치다.
거꾸로 말하면, 한 번의 응답으로 끝나는 일에 Agent를 붙이는 것은 낭비다. 번역·요약·초안 작성은 단순 호출이 더 빠르고 싸고 안정적이다. Agent인지 아닌지는 기술의 문제가 아니라 업무의 형태 문제다.
Agent의 핵심 구성 요소 4가지
어떤 Agent 프레임워크를 쓰든 안을 열어 보면 같은 네 부품이 나온다. 계획을 세우는 Planner, 바깥세상과 연결하는 Tools, 상태를 기억하는 Memory, 계획을 실행에 옮기는 Executor다.
이 네 부품은 오늘 실습에서 전부 다시 만난다. 뉴스 큐레이터 Agent에서는 Claude Code가 Planner 역할을 맡아 검색 쿼리와 실행 순서를 정하고, DuckDuckGo 검색·크롤링이 Tools, 수집한 URL 목록과 진행 상태가 Memory, 도구를 차례로 돌리며 결과를 모으는 코드가 Executor에 해당한다. 설계 단계에서 "우리 Agent의 네 부품은 각각 무엇인가"를 먼저 적어 두면 구현이 흔들리지 않는다.
Agent가 필요한 순간, 그리고 설계로 가는 4가지 질문
모든 업무에 Agent가 필요한 것은 아니다. 다단계·실시간·반복이라는 신호가 보일 때, 4가지 질문으로 요구사항을 설계로 바꾼다.
Agent가 필요한 비즈니스 케이스
업무에서 다음 네 가지 신호가 보이면 단순 LLM 호출로는 부족하고 Agent가 필요하다는 뜻이다.
- 여러 단계를 거쳐야 하는 업무 자동화 — 리서치 → 분석 → 리포트
- 외부 데이터를 실시간으로 가져와야 하는 경우 — 뉴스, 공시, 시세
- 사람이 결정해야 할 분기점이 많은 프로세스
- 반복 일정 실행 — 매일 오전 9시에 브리핑 생성 등
네 신호의 공통점은 "한 번의 응답으로 끝나지 않는다"는 것이다. 첫째와 둘째는 도구(검색·크롤링·API)가 필요하다는 신호이고, 셋째는 루프 중간에 사람의 판단이 끼어드는 human-in-the-loop 설계가 필요하다는 신호이며, 넷째는 스케줄러와 결합해야 한다는 신호다. 오늘 만들 뉴스 큐레이터는 이 중 첫째(수집→요약→표시), 둘째(실시간 뉴스), 넷째(주기 실행)에 해당한다.
비즈니스 요구사항 → Agent 설계, 4가지 질문
막연한 요구("뉴스 좀 자동으로 정리해 줘")를 설계 가능한 스펙으로 바꾸는 표준 절차가 이 4가지 질문이다. 답이 다 나오면 아키텍처는 거의 그려진 것이다.
| 질문 | 예시 답 |
|---|---|
| 1. 최종 산출물이 무엇인가? | 반도체 뉴스 일일 브리핑 |
| 2. 어떤 데이터가 필요한가? | 뉴스 기사 URL, 본문 텍스트 |
| 3. 데이터를 어디서 가져오나? | DuckDuckGo 검색, RSS 피드 |
| 4. 언제, 얼마나 자주 실행하나? | 매일 오전 8시, APScheduler |
질문의 순서에 의미가 있다. 산출물부터 거꾸로 내려온다. 산출물이 정해져야 필요한 데이터가 정해지고, 데이터가 정해져야 수집 경로가 정해지고, 마지막에 실행 주기가 붙는다. 반대로 "일단 크롤러부터 만들자"로 시작하면 산출물과 맞지 않는 데이터를 모으게 되기 쉽다. 다음 파트의 Step 1 표가 바로 이 4가지 질문을 실습 시나리오에 적용하는 연습이다.
뉴스 큐레이터 Agent를 설계한다
요구사항 분석 → 아키텍처 스케치 → Claude Code 구현 지시 → 동작 확인. 4단계를 거치면 동작하는 프로토타입이 남는다.
기술 뉴스 큐레이터 Agent
반도체·AI 관련 뉴스를 자동 수집해서 요약·분류한 뒤 Gradio 대시보드에 표시하는 기술 뉴스 큐레이터 Agent를 구축한다. 이번 시간에는 설계와 프로토타입까지, 완성형 구현은 뒤 시간(8H)에서 다룬다.
요구사항 분석 — 빈칸을 직접 채운다
앞에서 배운 4가지 질문을 실습 시나리오에 적용한다. 아래 표의 오른쪽 칸을 직접 채워 본 뒤 다음 Step으로 넘어간다.
| 항목 | 내용 (직접 채우기) |
|---|---|
| 최종 산출물 | |
| 필요한 데이터 | |
| 데이터 수집 방법 | |
| LLM이 할 일 | |
| 출력 방식 | |
| 실행 주기 |
채운 답이 4가지 질문(산출물 → 데이터 → 수집 경로 → 실행 주기)과 하나씩 대응하는지 확인해 보자. "LLM이 할 일"과 "출력 방식"이 추가된 것은, 이 시나리오에서는 LLM 처리 단계와 사용자에게 보여주는 방식까지 설계 범위에 들어오기 때문이다. 여기서 정한 답이 그대로 Step 3의 구현 지시문이 된다.
Agent 아키텍처 스케치
Step 1의 답을 데이터 흐름 순서로 이어 붙이면 아키텍처가 된다. 사용자 입력에서 출발해 Planner → Tool Executor → LLM 처리 → 결과 출력으로 내려가는 한 줄기 흐름이다.
[뉴스 큐레이터 Agent 아키텍처] 사용자 키워드 입력 ↓ Planner (Claude Code) · 검색 쿼리 생성, 실행 순서 결정 ↓ Tool Executor · DuckDuckGo 뉴스 검색 → URL 목록 수집 · 기사 본문 크롤링 → 텍스트 추출 · 중복 URL 제거 → 정제된 목록 ↓ LLM 처리 (Qwen3-8B via HuggingFace) · 카테고리 분류 (기술/시장/인물) · 핵심 내용 3줄 요약 ↓ 결과 출력 · Gradio 대시보드 (웹) · 텔레그램 알림 (선택)
이 스케치에서 이론 파트의 네 부품을 찾아보자. Planner는 그대로 Planner, DuckDuckGo 검색·크롤링·중복 제거는 Tools, 수집한 URL 목록과 정제된 텍스트가 흘러가는 것이 Memory, 이 순서대로 도구를 돌리는 것이 Executor다. 스케치 단계에서는 코드가 한 줄도 필요 없다. 화살표의 순서와 각 단계의 입력·출력만 분명하면 된다.
Claude Code로 아키텍처 구현 지시 — 바이브코딩
스케치가 나왔으면 코드를 직접 짜는 대신 Claude Code에 자연어로 지시한다. 아키텍처의 각 단계가 지시문의 번호 항목과 1:1로 대응하는 것이 좋은 지시문의 조건이다.
news_curator 폴더를 만들고 아래 구조로 Agent를 구현해줘: 1. DuckDuckGo로 주어진 키워드의 최신 뉴스 10개를 검색 2. 각 기사 URL에서 본문 텍스트를 크롤링 3. HuggingFace Qwen3-8B로 각 기사를 카테고리 분류 + 3줄 요약 4. Gradio로 결과를 테이블 형태로 표시 HF_TOKEN은 환경변수에서 읽어와.
지시문을 아키텍처와 비교해 보자. 1번은 Tool Executor의 검색, 2번은 크롤링, 3번은 LLM 처리, 4번은 결과 출력이다. 즉 Step 2의 스케치가 그대로 프롬프트가 된다. 마지막 줄처럼 토큰·키 같은 비밀 값은 코드에 하드코딩하지 말고 환경변수에서 읽도록 지시하는 습관을 들이자. 이렇게 자연어로 개발을 지시하는 방식을 바이브코딩이라 부른다.
구현된 Agent 동작 확인
Claude Code가 만든 결과물을 실행해 설계대로 동작하는지 확인한다. 파일 구조 확인 → 실행 → 웹 화면에서 검증 순서다.
- 생성된 파일 구조를 확인한 뒤 앱을 실행한다.
- Gradio 앱에서 키워드를 입력하고 뉴스 수집이 도는 것을 지켜본다.
- 요약·분류 결과가 테이블에 표시되는지 확인한다.
python news_curator/app.py
확인 포인트
- news_curator 폴더와 파일 구조가 생성되었다
- 키워드 입력 → 뉴스 수집 → 요약 결과가 화면에 나온다
- 카테고리 분류와 3줄 요약이 각 기사에 붙어 있다
추가 기능(텔레그램 알림, 스케줄링)까지 붙인 완성된 구현 예시는 8H · 뉴스 큐레이터 에이전트 페이지에서 확인할 수 있다.
설계 체크리스트와 핵심 용어
산출물에서 거꾸로 내려오는 4가지 질문, 네 부품의 아키텍처, 그리고 자연어 구현 지시. 이 세 가지가 오늘의 전부다.
내 Agent 설계, 빠진 것이 없는가
- 최종 산출물을 정의했다
- 필요 데이터와 수집 방법을 결정했다
- 아키텍처를 스케치했다
- Claude Code로 프로토타입을 생성했다
- 스케줄링·알림 연동을 검토했다 (선택)
핵심 용어 정리
| 용어 | 뜻 |
|---|---|
| Agent | 목표 달성을 위해 스스로 계획·실행·반복하는 LLM 기반 시스템 |
| Tool | Agent가 호출할 수 있는 외부 기능 (검색, DB, API 등) |
| Planner | 목표를 하위 작업으로 분해하는 구성 요소 |
| Memory | 작업 진행 중 상태와 컨텍스트를 유지하는 저장소 |
| Orchestration | 여러 Agent나 Tool을 조율해 복잡한 작업을 수행하는 구조 |
| 바이브코딩 | 코드 없이 자연어로 AI에게 개발을 지시하는 방식 |
하나. Agent와 단순 LLM 호출을 가르는 것은 도구 사용·상태 관리·반복 루프다. 한 번의 응답으로 끝나는 일에는 Agent가 필요 없다.
둘. 요구사항은 4가지 질문(산출물 → 데이터 → 수집 경로 → 실행 주기)으로 설계가 된다. 산출물에서 거꾸로 내려온다.
셋. 아키텍처 스케치는 그대로 Claude Code 지시문이 된다. 스케치가 분명하면 바이브코딩 한 번으로 프로토타입이 나온다.
다음 시간(3H)에는 Few-shot, CoT 등 고성능 프롬프트 기법과 업무별 템플릿 제작을 다룬다.
원본 자료 삼성전자 GenAI Lv4 특강 노션 페이지 — 2H · AI Agent 설계 및 분석, notion.site/2H-AI-Agent
이 자료는 단일 HTML 파일로 배포되는 실습 가이드다. 프롬프트 블록의 "복사" 버튼으로 지시문을 그대로 복사해 쓸 수 있다.