74일차 자료 추가(답 제외), 73일차 정답 공개(LAB-A · VIBE-A · answers · tscan), 64 · 65 · 68~73일차 교안 · 실습 문서 수정 반영
This commit is contained in:
1 parent
4ef0464525
commit
bb719d81fa
191 files changed
+36875
-64
No files matched your search
@@ -8,7 +8,7 @@
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["1. 재기 전에<br/>고치지 않기"] --> B["2. 시간을 말하는 말<br/>p50 · p95 · max"] --> C["3. 첫 호출"] --> D["4. 어디서 재나"] --> E["5. 단계별 시간"]
|
||||
E --> F["6. 종류별로 재기"] --> G["7. 어림 계산"] --> H["8. 가장 느린 단계"] --> I["9. 시간 예산"] --> J["10. 요청문으로"]
|
||||
E --> F["6. 종류별로 재기"] --> G["7. 어림 계산"] --> H["8. 가장 느린 단계"] --> I["9. 시간 예산"] --> J["10. 요청문(프롬프트)으로"]
|
||||
```
|
||||
|
||||
## 0. 이 시간 (50분)
|
||||
@@ -354,10 +354,24 @@ flowchart LR
|
||||
- 기본 예산 3초에서 VPN이 3023ms로 **23ms 넘었습니다.** 지금 워크플로우는 3초 근처라 실행마다 `true` · `false`가 바뀝니다. 그래서 과제 2 테스트는 기본값일 때 `budget_ms: 3000`만 보고, 4교시 Lab 02에서 LLM을 줄이면 넉넉히 들어옵니다.
|
||||
- `llm_ms`가 `total_ms`의 98%: 넘은 까닭이 LLM이라는 것이 결과만 봐도 보입니다.
|
||||
|
||||
## 10. 요청문으로
|
||||
## 10. 요청문(프롬프트)으로
|
||||
|
||||
**요청문(프롬프트)이란.** 실습에서 CLI 코딩 에이전트(codex · claude · agy)에게 보내는 글입니다. 에이전트는 이 글만 보고 n8n 워크플로우 JSON을 만들거나 고칩니다. 이 절은 이 단계에서 배운 것을 **요청문(프롬프트)에 어떤 칸으로 적을지** 실습 전에 정리하는 자리입니다. 실습 문서의 `▶ 빈칸 채우기 · 요청문(프롬프트) 뼈대`가 이 칸을 실제 문장으로 만든 것이고, 빈칸 ①~④는 그 문장 속 정확한 값입니다.
|
||||
|
||||
| 칸 | 에이전트에게 알려 주는 것 | 빠지면 생기는 일 |
|
||||
| --- | --- | --- |
|
||||
| 무엇을 | 만들거나 바꿀 기능 | 에이전트가 짐작해서 다른 것을 만듦 |
|
||||
| 어디에 | 고칠 파일 · 노드 · 자리 | 엉뚱한 노드를 고치거나 새 파일을 만듦 |
|
||||
| 어떤 모양으로 | 결과 JSON의 칸 이름 · 값 · 응답 코드 | 테스트가 보는 칸 이름과 달라 실패 |
|
||||
| 그대로 · 하지 말 것 | 건드리면 안 되는 것 | 다른 곳까지 바뀌어 무엇 때문인지 모르게 됨 |
|
||||
| 확인 | 통과해야 할 테스트 파일 | "다 됐다"를 판단할 기준이 없음 |
|
||||
|
||||
67~71일차의 다섯 가지(① 파일 ② 입력 ③ 처리 ④ 결과 모양 ⑤ 기대 결과)와 같은 뜻입니다. 파일 · 입력이 "어디에", 처리가 "무엇을", 결과 모양이 "어떤 모양으로", 기대 결과가 "확인"입니다. 72일차부터는 **이미 있는 워크플로우를 고치는** 요청이 많아 "그대로"가 따로 한 칸이 됐습니다.
|
||||
|
||||
Lab과 다른 업무로 예를 듭니다 (주문 문의 워크플로우, **실습에는 없는 예**: `my-work/order.json`은 가상의 파일). Lab 01 예제 2 · 과제 1 · 과제 2의 요청문을 쓸 때 같은 칸을 채웁니다.
|
||||
|
||||
아래 표의 줄(넣을 것)은 위 다섯 칸을 이 단계 주제에 맞게 쪼갠 것이고, 실습 요청문(프롬프트)을 쓸 때도 같은 줄을 채웁니다.
|
||||
|
||||
| 넣을 것 | 예 |
|
||||
| --- | --- |
|
||||
| 바탕 · 바꿀 것 | "`my-work/order.json`은 그대로 두고 결과에 필드만 더한다" |
|
||||
@@ -367,6 +381,17 @@ Lab과 다른 업무로 예를 듭니다 (주문 문의 워크플로우, **실
|
||||
| 예산 | "본문 `budget_ms`(없으면 2000), `over_budget`, `llm_ms`는 `timings` 밖" |
|
||||
| 기대 결과 | 테스트 파일 |
|
||||
|
||||
표를 위에서부터 이어 읽으면 요청문(프롬프트)이 됩니다 (화살표 오른쪽은 다섯 칸 중 어디인지):
|
||||
|
||||
```text
|
||||
my-work/order.json 은 그대로 두고 결과에 필드만 더해 줘. ← 그대로 · 무엇을
|
||||
주문 조회 뒤와 답 LLM 뒤에 시각을 남겨, ← 어디에
|
||||
결과에 timings: {lookup_ms, answer_ms, total_ms}, steps, llm_calls 를 넣어 줘. ← 어떤 모양으로
|
||||
지나가지 않은 노드는 isExecuted 로 확인해 빼고,
|
||||
본문 budget_ms(없으면 2000)를 넘으면 over_budget: true (llm_ms 는 timings 밖).
|
||||
기대 결과 cases/<테스트 파일>.json. ← 확인
|
||||
```
|
||||
|
||||
> "빠르게 해 줘"로 시작하지 않습니다. **"재게 해 줘"** 가 먼저입니다.
|
||||
|
||||
## 11. 자주 하는 실수
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["1. 줄일 수 있는<br/>LLM 호출"] --> B["2. 규칙 먼저"] --> C["3. 캐시"] --> D["4. 적중률"] --> E["5. 캐시 키 설계"]
|
||||
E --> F["6. 검토를 검사로"] --> G["7. 잃은 것 적기"] --> H["8. 테스트도 바뀐다"] --> I["9. 요청문으로"]
|
||||
E --> F["6. 검토를 검사로"] --> G["7. 잃은 것 적기"] --> H["8. 테스트도 바뀐다"] --> I["9. 요청문(프롬프트)으로"]
|
||||
```
|
||||
|
||||
## 0. 이 시간 (50분)
|
||||
@@ -313,10 +313,24 @@ Lab 02 과제 1 · 과제 2를 마칠 때 `my-work/PERF.md` 3절에 바꾼 것
|
||||
|
||||
> 수업 준비 때 처음 쓴 품질 테스트에 `llm_calls: 3`, `steps`에 `review` 같은 **구조**가 들어 있어 정당하게 빨라진 워크플로우가 실패했습니다.
|
||||
|
||||
## 9. 요청문으로
|
||||
## 9. 요청문(프롬프트)으로
|
||||
|
||||
**요청문(프롬프트)이란.** 실습에서 CLI 코딩 에이전트(codex · claude · agy)에게 보내는 글입니다. 에이전트는 이 글만 보고 n8n 워크플로우 JSON을 만들거나 고칩니다. 이 절은 이 단계에서 배운 것을 **요청문(프롬프트)에 어떤 칸으로 적을지** 실습 전에 정리하는 자리입니다. 실습 문서의 `▶ 빈칸 채우기 · 요청문(프롬프트) 뼈대`가 이 칸을 실제 문장으로 만든 것이고, 빈칸 ①~④는 그 문장 속 정확한 값입니다.
|
||||
|
||||
| 칸 | 에이전트에게 알려 주는 것 | 빠지면 생기는 일 |
|
||||
| --- | --- | --- |
|
||||
| 무엇을 | 만들거나 바꿀 기능 | 에이전트가 짐작해서 다른 것을 만듦 |
|
||||
| 어디에 | 고칠 파일 · 노드 · 자리 | 엉뚱한 노드를 고치거나 새 파일을 만듦 |
|
||||
| 어떤 모양으로 | 결과 JSON의 칸 이름 · 값 · 응답 코드 | 테스트가 보는 칸 이름과 달라 실패 |
|
||||
| 그대로 · 하지 말 것 | 건드리면 안 되는 것 | 다른 곳까지 바뀌어 무엇 때문인지 모르게 됨 |
|
||||
| 확인 | 통과해야 할 테스트 파일 | "다 됐다"를 판단할 기준이 없음 |
|
||||
|
||||
67~71일차의 다섯 가지(① 파일 ② 입력 ③ 처리 ④ 결과 모양 ⑤ 기대 결과)와 같은 뜻입니다. 파일 · 입력이 "어디에", 처리가 "무엇을", 결과 모양이 "어떤 모양으로", 기대 결과가 "확인"입니다. 72일차부터는 **이미 있는 워크플로우를 고치는** 요청이 많아 "그대로"가 따로 한 칸이 됐습니다.
|
||||
|
||||
Lab과 다른 업무로 예를 듭니다 (사내 식당 메뉴 안내 워크플로우, **실습에는 없는 예**). Lab 02 예제 1 · 2 · 과제 1 · 2의 요청문을 쓸 때 같은 칸을 채웁니다.
|
||||
|
||||
아래 표의 줄(넣을 것)은 위 다섯 칸을 이 단계 주제에 맞게 쪼갠 것이고, 실습 요청문(프롬프트)을 쓸 때도 같은 줄을 채웁니다.
|
||||
|
||||
| 넣을 것 | 예 |
|
||||
| --- | --- |
|
||||
| 무엇을 줄이나 | "날짜가 있으면 규칙으로, 없을 때만 LLM이 날짜를 읽게" |
|
||||
@@ -325,6 +339,16 @@ Lab과 다른 업무로 예를 듭니다 (사내 식당 메뉴 안내 워크플
|
||||
| 결과에 남길 것 | `cached`, `cache_by`, `llm_calls` |
|
||||
| 품질 확인 | "빨라진 뒤에도 원래 테스트가 통과" |
|
||||
|
||||
표를 위에서부터 이어 읽으면 요청문(프롬프트)이 됩니다 (화살표 오른쪽은 다섯 칸 중 어디인지):
|
||||
|
||||
```text
|
||||
질문에 날짜가 있으면 규칙(Code)으로 날짜를 읽고, 없을 때만 LLM 이 읽게 해 줘. ← 무엇을 · 어디에
|
||||
메뉴 답은 날짜 + 식당 이름을 키로 캐시해 줘 (질문 글자가 아니라).
|
||||
오늘 남은 수량은 바뀌므로 캐시하지 마. ← 하지 말 것
|
||||
결과에 cached, cache_by, llm_calls 를 남겨 줘. ← 어떤 모양으로
|
||||
빨라진 뒤에도 원래 테스트 cases/<테스트 파일>.json 이 통과해야 해. ← 확인
|
||||
```
|
||||
|
||||
> "빠르게 해 줘"가 아니라 **"이 LLM 호출을 이 조건일 때 건너뛰어 줘"** 처럼 한 가지씩.
|
||||
|
||||
## 확인 질문
|
||||
|
||||
Reference in new issue
Block a user