65 lines
6.5 KiB
Markdown
65 lines
6.5 KiB
Markdown
# 🎙️ 특강 발표 대본 스크립트 — 1. Engineering
|
|
|
|
본 문서는 `1_engineering.md` 슬라이드에 대응하는 발표용 대본 스크립트입니다. 청중의 이해를 돕기 위해 친절한 구어체 존댓말로 작성되었습니다.
|
|
|
|
---
|
|
|
|
### 🎴 Slide 1: 1장 타이틀 및 개요
|
|
* **슬라이드 제목**: 1. AI 에이전트 구현을 위한 3대 핵심 엔지니어링 기법
|
|
* **대본**:
|
|
> "그럼 이제 본격적으로 1장, **AI 에이전트 구현을 위한 3대 핵심 엔지니어링 기법**을 살펴보겠습니다.
|
|
> 단순히 똑똑한 AI 모델을 가져온다고 해서 알아서 일하는 에이전트가 완성되지는 않습니다.
|
|
> 모델을 정밀하게 제어하고, 실시간 대화 정보를 관리하며, 실제 물리적 환경에 연결하기 위해 세 가지 엔지니어링 분야가 유기적으로 작동해야 합니다.
|
|
> 첫 번째는 머리를 세팅하는 **프롬프트 엔지니어링**, 두 번째는 기억을 구성하는 **컨텍스트 엔지니어링**, 세 번째는 실제 손발을 달아주는 **하네스 엔지니어링**입니다.
|
|
> 각 기법이 구체적으로 어떤 의미를 가졌는지 실제 사례와 함께 짚어보겠습니다."
|
|
|
|
---
|
|
|
|
### 🎴 Slide 2: 1️⃣ 프롬프트 엔지니어링 (Prompt Engineering)
|
|
* **슬라이드 제목**: 1️⃣ 프롬프트 엔지니어링 (Prompt Engineering)
|
|
* **대본**:
|
|
> "첫 번째 기둥인 **프롬프트 엔지니어링**입니다.
|
|
> 최근 AI 모델들이 비약적으로 발전하고 자체적인 추론 능력이 향상되면서, 예전만큼 단어나 기호 하나에 집착하는 미시적인 프롬프트 트릭의 가치는 줄어들고 있습니다.
|
|
> 하지만 프롬프트는 여전히 **AI 에이전트 활용의 시작점이자 가장 중요한 뼈대**입니다. 에이전트 시스템을 설계할 때 프롬프트에 반드시 반영해야 하는 세 가지 고려사항이 있습니다.
|
|
> 첫째는 **역할 및 페르소나 지시**입니다. 에이전트가 어떤 전문 지식 범위와 행동 규칙을 고수해야 하는지 경계를 지정해 주는 것입니다.
|
|
> 둘째는 **구체적인 작업 예시 제공, 즉 Few-shot**입니다. 에이전트가 내놓는 답변이 예외 없이 일관된 양식과 톤을 유지하도록 모범 예시를 제공하는 것입니다.
|
|
> 셋째는 **자가 검증 방법 제시**입니다. 에이전트 스스로 결과물을 검사하게 하거나, 외부 시스템이 실행 결과를 확인하고 안전하게 통제할 수 있도록 정형화된 출력 규격(예: 통과 시 `[VERDICT: PASS]` 명시 요구)을 심어두는 것입니다. 이 세 요소가 균형을 이루어야 비로소 신뢰할 수 있는 좋은 프롬프트가 완성됩니다."
|
|
|
|
---
|
|
|
|
### 🎴 Slide 2-1: 💡 실제 프롬프트 구조 예시 (ReAct 사고 방식)
|
|
* **슬라이드 제목**: 💡 실제 프롬프트 구조 예시 (ReAct 사고 방식)
|
|
* **대본**:
|
|
> "그렇다면 이 고려사항들이 반영된 실제 프롬프트 구조는 어떨까요?
|
|
> 대표적인 기법이 바로 화면에 보이는 **ReAct(Reason + Action) 사고 방식**을 강제하는 템플릿입니다.
|
|
> 우리는 에이전트에게 단순히 '문제를 풀어라' 하고 결과만 묻지 않습니다.
|
|
> 대신 'Thought(문제를 풀기 위한 계획을 먼저 세우고) ➡️ Action(네가 직접 실행할 도구의 인자값을 JSON으로 적고) ➡️ Observation(도구의 실제 실행 결과를 눈으로 보고 분석해라)'이라는 단계적 생각의 길을 열어줍니다.
|
|
> 이렇게 구조화된 사고 가이드를 프롬프트에 강제함으로써, AI가 섣불리 엉터리 답을 찍지 않고, 신중하게 도구를 실행하며 그 결과를 토대로 정답을 향해 차근차근 나아가게 제어할 수 있습니다."
|
|
|
|
---
|
|
|
|
### 🎴 Slide 3: 2️⃣ 컨텍스트 엔지니어링 (Context Engineering)
|
|
* **슬라이드 제목**: 2️⃣ 컨텍스트 엔지니어링 (Context Engineering)
|
|
* **대본**:
|
|
> "두 번째 기둥은 **컨텍스트 엔지니어링**입니다.
|
|
> AI 모델의 기억 공간인 '컨텍스트 윈도우'는 무한하지 않고 비용이 듭니다.
|
|
> 따라서 대화 흐름을 압축하여 유지하고, 수많은 소스코드나 문서 중에서 지금 당장 필요한 핵심 데이터만 적시에 필터링하여 꽂아주는 기술이 필수적입니다.
|
|
> 슬라이드 오른쪽의 에이전트 상태 보존 예시를 보겠습니다.
|
|
> 에이전트는 사용자와 주고받은 20번의 긴 대화 내용을 날것 그대로 모델에 던지지 않습니다.
|
|
> 대신 현재 작업 ID가 무엇인지, 지금 작업 디렉터리는 어디인지, 발생한 에러 로그는 무엇인지, 그리고 이미 끝낸 작업과 다음에 할 일은 무엇인지 등을 JSON 형태의 구조화된 데이터 상태로 압축하고 요약하여 보존합니다.
|
|
> 이렇게 상태를 효율적으로 캐싱하고 정제하여 모델에 알려줌으로써, 불필요한 비용을 줄이고 답변의 정확도를 극대화할 수 있습니다."
|
|
|
|
---
|
|
|
|
### 🎴 Slide 4: 3️⃣ 하네스 엔지니어링 (Harness Engineering)
|
|
* **슬라이드 제목**: 3️⃣ 하네스 엔지니어링 (Harness Engineering)
|
|
* **대본**:
|
|
> "마지막 세 번째는 에이전트에게 진짜 실행 능력을 부여하는 **하네스 엔지니어링**입니다.
|
|
> 아무리 모델이 훌륭한 수정 계획을 세워도, 실제 디스크에 저장하거나 코드를 컴파일할 수 없다면 에이전트라고 부를 수 없습니다.
|
|
> 하네스는 모델이 내린 판단을 감지해 실제 컴퓨터 명령어(ls, python3 run 등)로 변환해 실행하고, 그 실행 결과를 다시 모델에게 바인딩해 주는 인터페이스 인프라입니다.
|
|
> 슬라이드의 다이어그램을 보시면 흐름이 잘 보입니다.
|
|
> 모델이 'Action: 파일 목록을 보고 싶어'라고 텍스트로 내놓으면, 에이전트 하네스 시스템이 이를 가로채서(Intercept) 실제 격리된 컴퓨터 환경(Docker 샌드박스 등)에서 명령을 수행합니다.
|
|
> 그리고 그 실행 결과를 다시 'Observation: 결과는 다음과 같아'라고 정형화해 모델의 눈앞에 가져다줍니다.
|
|
> 또한, 모델이 혹시나 컴퓨터를 망가뜨릴 수 있는 명령을 내리지 못하도록 안전망(Sandboxing)을 씌워주는 것 역시 하네스 엔지니어링의 핵심 의무입니다.
|
|
> 이 3대 기술이 완벽히 맞물렸을 때, 비로소 자율형 에이전트가 단독으로 기동할 수 있게 됩니다."
|