
핵심은 이것입니다.
일반 프로그램 = 개발자가 실행 순서와 판단 로직을 미리 결정
Agent = 목표를 주면 LLM이 상황을 판단하고, 필요한 Tool을 선택·호출하면서 목표를 달성
즉 자연어는 Agent의 인터페이스일 뿐이고, Agent의 본질은 'LLM이 판단하는 실행 루프'에 있습니다.
1. 날씨 예제로 보면 바로 이해됩니다
사용자님이 말씀하신 상황을 보겠습니다.
"서울의 오늘 날씨를 알려줘."
일반적인 코딩
개발자가 이미 모든 것을 결정합니다.
city = "Seoul"
weather = weather_api.get_weather(city)
print(weather)
실행 과정은 거의 고정입니다.
서울 입력
→ Weather API 호출
→ 결과 받기
→ 화면 출력
입니다.
개발자가
"서울이면 이 API를 호출하고, 결과의 temperature를 가져와서 출력한다."
라고 미리 프로그램을 만들어놓은 것입니다.
2. Agent는 무엇이 다른가?
Agent에게
"서울 오늘 날씨 알려줘."
라고 하면 LLM이 다음과 같이 판단할 수 있습니다.
사용자 요청 분석
↓
날씨 정보가 필요함
↓
Weather Tool이 필요함
↓
Weather Tool 선택
↓
서울의 날씨 조회
↓
결과 분석
↓
사용자에게 설명
여기서 중요한 것은 LLM이 중간의 의사결정을 한다는 것입니다.
예를 들어 사용자가
"내일 서울 날씨 보고 비 오면 우산 챙기라고 알려줘."
라고 하면 단순 API 호출 프로그램보다 차이가 커집니다.
Agent는
1. 내일 날짜 확인
2. 서울 날씨 조회
3. 강수 여부 확인
4. 비가 오는지 판단
5. 비가 오면 우산을 챙기라고 답변
이라는 작업을 스스로 구성할 수 있습니다.
3. 그런데 여기서 아주 중요한 사실이 있습니다
Agent도 결국 코딩되어 있습니다.
이게 Agent 공부를 시작할 때 가장 중요한 개념입니다.
Agent가 마법처럼 아무것도 없는 상태에서 프로그램을 만드는 것이 아닙니다.
개발자가 최소한 다음을 만들어줘야 합니다.
LLM
↓
Agent Runtime
↓
Tool
↓
Weather API
즉 개발자가
Weather API를 호출할 수 있는 Tool
을 만들어줘야 합니다.
예를 들어:
def get_weather(city):
return weather_api.get(city)
그리고 Agent에게
"날씨를 조회할 수 있는 get_weather라는 Tool이 있다."
라고 알려줍니다.
그러면 LLM이 필요할 때 이 Tool을 선택합니다.
4. 그래서 일반 코딩과 Agent 코딩의 차이는 이렇게 보는 것이 가장 정확합니다
| 핵심 | 정해진 로직 실행 | 목표 달성 |
| 판단 | 개발자가 미리 결정 | LLM이 일부 결정 |
| 실행순서 | 대부분 고정 | 상황에 따라 변경 |
| Tool 선택 | 코드가 결정 | LLM이 선택 가능 |
| 자연어 | 입력값일 수 있음 | 핵심 인터페이스 |
| API 호출 | 개발자가 직접 구현 | Tool로 제공 |
| 복잡한 업무 | 로직이 복잡해짐 | Agent가 분해 가능 |
| 예측 가능성 | 높음 | 상대적으로 낮음 |
| 통제 | 쉬움 | 추가적인 통제 필요 |
5. 아주 간단한 예로 비교해보겠습니다
일반 코딩
사용자가
"삼성전자 주가를 조회해줘."
라고 합니다.
프로그램:
stock = get_stock_price("005930")
return stock
끝입니다.
Agent
사용자가
"삼성전자 주가가 최근 많이 올랐는지 확인하고, 지금 투자하기 괜찮은지도 알려줘."
라고 합니다.
Agent가 사용할 수 있는 Tool이
StockPriceTool
NewsSearchTool
FinancialStatementTool
CalculatorTool
이라면 LLM이
① 삼성전자 종목 확인
↓
② 주가 조회
↓
③ 최근 주가 변화 계산
↓
④ 최근 뉴스 검색
↓
⑤ 실적 정보 조회
↓
⑥ 자료 종합
↓
⑦ 투자 판단에 필요한 정보 정리
를 수행할 수 있습니다.
여기서 어떤 Tool을 어떤 순서로 사용할 것인지가 고정되어 있지 않다는 것이 Agent의 중요한 특징입니다.
6. 그래서 Agent를 '자연어 코딩'이라고만 보면 안 됩니다
이렇게 생각하면 이해가 쉽습니다.
일반 프로그램
If → Then → Else
개발자가 작성
비가 오면
→ 우산이라고 출력
Agent
Goal → Reason → Act → Observe → Reason → Act
목표:
"비가 오면 알려줘"
↓
현재 날씨/예보가 필요한가?
↓
Weather Tool 사용
↓
결과 확인
↓
비가 오는가?
↓
Yes
↓
사용자에게 알림
즉 Agent는 판단-행동-관찰의 반복 구조를 가지고 있습니다.
7. 사용자님이 공부하시는 'Agent 코딩'에서는 이 부분이 가장 중요합니다
Agent를 공부할 때 단순히
"프롬프트를 잘 쓰면 Agent가 된다."
라고 생각하면 안 됩니다.
실제로는 다음 구조를 이해해야 합니다.
사용자
↓
자연어
↓
LLM
↓
┌──── Agent ────┐
│ │
판단/계획 기억
│ │
↓ ↓
Tool Memory/RAG
│
┌─────┼─────┐
↓ ↓ ↓
API DB 시스템
여기서 LLM은 두뇌,
Tool은 손발,
Memory/RAG는 기억,
Agent Runtime은 행동을 관리하는 실행환경이라고 생각하면 됩니다.
8. 특히 Tool과 API를 구분하셔야 합니다
이 부분이 금융 AI Agent를 설계할 때 굉장히 중요합니다.
예를 들어 은행의
고객잔액조회 API
가 있다고 하겠습니다.
일반 개발에서는
프로그램
↓
잔액조회 API
↓
결과
입니다.
Agent에서는
사용자
"내 계좌 잔액 알려줘"
↓
LLM
"잔액 조회가 필요하군."
↓
BalanceInquiry Tool
↓
은행 API
↓
결과
↓
LLM
"현재 잔액은 1,000만원입니다."
입니다.
즉,
API가 Tool이 되는 것이 아니라, API를 Agent가 사용할 수 있도록 감싼 것이 Tool
이라고 이해하면 좋습니다.
9. 그래서 Agent의 진짜 장점은 Tool 개수가 늘어날 때 나타납니다
날씨 하나만 조회한다면 솔직히 말씀하신 것처럼
일반 코딩이 더 간단합니다.
Agent를 쓸 이유가 별로 없습니다.
그런데 업무가 이렇게 되면 이야기가 달라집니다.
"이번 주 우리 회사에 영향을 줄 만한 경제뉴스를 찾아보고, 경쟁사 실적과 비교해서 다음 주 영업전략을 제안해줘."
이걸 일반 프로그램으로 만들면 개발자가
뉴스 API
↓
검색
↓
필터링
↓
기업정보 API
↓
재무제표
↓
계산
↓
비교
↓
보고서 생성
을 하나하나 연결해야 합니다.
Agent는 여러 Tool을 제공해주고
"영업전략을 만들어라"
라는 목표를 주면 LLM이 필요한 작업을 조합하도록 만들 수 있습니다.
10. 그렇다고 Agent가 일반 코딩을 대체하는 것은 아닙니다
이것도 매우 중요합니다.
실제 기업 시스템에서는 보통
일반 코딩 + AI Agent
를 같이 씁니다.
예를 들어 은행이라면:
AI Agent
↓
┌────────┼────────┐
↓ ↓ ↓
고객조회Tool 여신Tool 상품Tool
↓ ↓ ↓
└────────┼────────┘
↓
기존 은행 시스템
Tool 내부는 결국 일반 프로그램입니다.
즉,
Agent가 기존 코딩을 없애는 것이 아니라, 기존 시스템 위에서 LLM이 Tool을 선택하고 조합하도록 만드는 것입니다.
11. 사용자님이 기업여신 Agent를 공부하신다면 이 차이가 더 명확해집니다
예를 들어
"이 기업의 여신 가능성을 분석해줘."
라는 요청을 받았다고 해보겠습니다.
일반 프로그램이라면 개발자가 순서를 정합니다.
기업정보 조회
↓
재무제표 조회
↓
신용등급 조회
↓
부채비율 계산
↓
매출증가율 계산
↓
담보 조회
↓
결과 출력
반면 Agent는 여러 Tool을 가지고 있다면
기업분석 Tool
재무제표 Tool
뉴스검색 Tool
신용평가 Tool
부동산담보 Tool
RAG Tool
계산 Tool
등을 상황에 따라 선택할 수 있습니다.
그리고
"최근 부정적인 뉴스가 있네."
라고 판단하면 뉴스검색을 추가로 하고,
"재무상태가 의심스럽다."
라고 판단하면 재무제표를 더 분석하도록 만들 수도 있습니다.
이게 Agentic한 부분입니다.
12. 결국 Agent 코딩을 이렇게 이해하시면 됩니다
제가 사용자님께 가장 추천하는 개념은 다음입니다.
일반 코딩
"어떻게 할 것인가?"를 개발자가 결정
Agent 코딩
"무엇을 달성할 것인가?"를 개발자가 정의하고, 일부 실행방법을 LLM에게 맡김
그래서 Agent 개발자는 오히려
프로그래밍을 안 하는 사람이 아닙니다.
오히려 다음 능력이 필요합니다.
LLM + Prompt + Tool + API + RAG + Memory + Workflow + Guardrail + 일반 프로그램
을 조합하는 능력입니다.
13. 그리고 사용자님의 현재 공부 방향에서는 이렇게 공부하는 것을 추천합니다
지금 Agent 코딩을 공부하고 계시다면 처음부터 LangGraph나 복잡한 Agent Framework부터 공부하기보다 아래 순서가 좋습니다.
① 일반 Python
↓
② REST API 호출
↓
③ LLM API 호출
↓
④ Function Calling / Tool Calling
↓
⑤ 단일 Agent
↓
⑥ 여러 Tool을 사용하는 Agent
↓
⑦ RAG
↓
⑧ Agent + RAG
↓
⑨ 여러 Agent
↓
⑩ MCP
↓
⑪ 실제 업무 Agent
특히 ④ Tool Calling을 제대로 이해하면 사용자님이 지금 질문하신
"결국 API 호출 코딩과 Agent가 뭐가 다른 거지?"
라는 의문이 거의 해결됩니다.
한 문장으로 정리하면:
일반 코딩은 개발자가 API 호출과 업무 순서를 직접 연결하는 것이고, Agent 코딩은 개발자가 API·DB·시스템 등을 Tool로 만들어 제공하면 LLM이 사용자의 목표를 보고 어떤 Tool을 언제 사용할지 판단하도록 만드는 것입니다.
그리고 재미있는 점은 날씨 조회 하나만 놓고 보면 Agent가 오히려 과합니다. Agent의 진짜 가치는 Tool이 많고, 업무가 복잡하고, 상황에 따라 실행 경로가 달라지는 업무에서 나타납니다.