🌐 [i18n-KO] Translated intro_agents.md to Korean

[Jwaminju]

What does this PR do?

Translated the intro_agents.md file of the documentation to Korean.

Thank you in advance for your review.

Before reviewing

• Check for missing / redundant translations (번역 누락/중복 검사)
• Grammar Check (맞춤법 검사)
• Review or Add new terms to glossary (용어 확인 및 추가)
• Check Inline TOC (e.g. [[lowercased-header]])
• Check live-preview for gotchas (live-preview로 정상작동 확인)

Who can review

• @Hugging-Face-KREW
• Anyone who knows Korean or translations

[hyeonseo2]

번역문에 일부 누락된 내용과 불완전한 문장이 있습니다. 특히 '언제 에이전트를 사용해야 하는지 / 피해야 하는지' 섹션과 'Why smolagents?' 부분이 원문에 비해 부족하게 번역되어 있어 명확성을 위해 보완이 필요합니다.

[hyeonseo2]

'언제 에이전트를 사용해야 하는지 / 피해야 하는지' 섹션 내용이 번역문에 빠져 있어 중요 정보가 누락되었습니다.

Suggested change

	## ✅ 에이전트를 사용해야 할 때 / ⛔ 피해야 할 때
	에이전트는 LLM이 앱의 워크플로우를 결정해야 할 때 유용합니다. 하지만 종종 과도합니다. 질문은 다음과 같습니다: 현재 작업을 효율적으로 해결하기 위해 정말로 워크플로우의 유연성이 필요한가요? 만약 정해진 워크플로우가 너무 자주 부족하다면, 더 많은 유연성이 필요하다는 의미입니다. 예를 들어, 서핑 여행 웹사이트에서 고객 요청을 처리하는 앱을 만든다고 가정해보겠습니다.
	사전에 요청이 두 가지 범주 중 하나에 속한다는 것을 알고 각 경우에 대해 미리 정해진 워크플로우를 가지고 있을 수 있습니다.
	1. 여행에 대한 지식을 원함? ⇒ 지식 베이스를 검색할 수 있는 검색창을 제공합니다.
	2. 영업팀과 이야기하고 싶음? ⇒ 연락 양식을 입력할 수 있게 합니다.
	만약 이러한 결정론적 워크플로우가 모든 문의에 적합하다면, 모든 것을 코딩하세요! 이는 예측 불가능한 LLM이 워크플로우에 관여하여 오류가 발생할 위험 없이 100% 신뢰할 수 있는 시스템을 제공합니다. 단순성과 견고함을 위해, 에이전트 행동을 사용하지 않는 방향으로 정규화하는 것이 권장됩니다.
	하지만 워크플로우를 미리 잘 정할 수 없다면 어떨까요?
	예를 들어, 사용자가 "월요일에 올 수 있지만 여권을 잊어 수요일로 지연될 위험이 있습니다. 취소 보험과 함께 화요일 아침에 저와 제 짐을 서핑하러 데려다 줄 수 있나요?"라고 질문할 수 있습니다. 이 질문은 많은 요인에 달려 있으며, 위에서 정해진 기준으로는 처리하기 어렵습니다.
	만약 정해진 워크플로우가 자주 부족하다면, 더 많은 유연성이 필요하다는 의미입니다.
	바로 이럴 때 에이전트 설정이 도움이 됩니다.
	예를 들어, 위 예제에서는 날씨 예보를 위한 날씨 API, 이동 거리를 계산하는 구글 지도 API, 직원 근무 가능 대시보드, 지식 베이스에 대한 RAG 시스템에 접근하는 다중 단계 에이전을트 만들 수 있습니다.

[hyeonseo2]

원문의 'Why smolagents?' 섹션 내용이 번역문에서는 소제목만 있고 설명 내용이 누락되었습니다.

Current text: 사전에 요청이 두 가지 범주 중 하나에 속한다는 것을 알고 각 경우에 대해 미리 정해진 워크플로우를 가지고 있을 수 있습니다.

Suggested change

	## Why `smolagents`?
	## 왜 `smolagents`인가요?
	체인이나 라우터 같은 저수준 에이전트 사용 사례는 모든 코드를 직접 작성할 수 있습니다. 그렇게 하는 것이 시스템을 더 잘 이해하고 제어하는 데 도움이 됩니다.
	하지만 LLM이 함수를 호출하게 하거나(도구 호출), LLM이 while 루프를 실행하게 하는(다중 단계 에이전트) 등 더 복잡한 동작이 필요한 경우는 추상화가 필요합니다.
	- 도구 호출의 경우, 에이전트 출력을 파싱해야 하며, 이 출력은 "Thought: 도구 'get_weather'을 호출해야 한다. Action: get_weather(Paris)."와 같은 정해진 형식을 따릅니다. 이 형식은 LLM에 시스템 프롬프트로 알려줍니다.
	- 다중 단계 에이전트에서는, 지난 루프 반복에서 일어난 일에 기반해 다른 프롬프트를 LLM에 제공해야 하므로 메모리가 필요합니다.
	위 두 가지 예에서 다음과 같은 요소가 필요함을 알 수 있습니다:
	- 시스템을 구동하는 엔진 역할을 하는 LLM
	- 에이전트가 접근할 수 있는 도구 목록
	- 에이전트 로직을 안내하는 시스템 프롬프트: Reflection -> Action -> Observation의 ReAct 루프, 사용 가능한 도구, 도구 호출 형식 등
	- LLM 출력에서 도구 호출을 추출하는 파서
	- 메모리
	하지만 LLM에 결정권을 주면 실수를 할 수 있으므로, 오류 기록과 재시도 메커니즘도 필요합니다.
	이 모든 요소들이 긴밀하게 결합되어야 잘 작동하는 시스템이 만들어집니다. 그래서 이러한 기본 빌딩 블록을 만들기로 했습니다.