앤드류 응 강의 노트

일을 여러 단계로 나눠 언어 모델(LLM)과 도구에게 맡기면 한 번에 시킬 때보다 결과가 좋아진다. 나누는 법, 재는 법, 네 가지 짜는 방식을 훑는다.

1강 Welcome! (1분 58초)

• 앤드류 응이 '에이전트 방식(agentic)'이라는 말을 만들었다. 마케팅하는 사람들이 이 말을 거의 모든 것에 붙이면서 부풀린 기대가 크게 늘었다.
• 부풀린 기대만큼 빠르지는 않아도, 실제로 쓸모 있는 응용도 빠르게 늘었다.
• 잘 만드는 사람과 덜 잘 만드는 사람의 가장 큰 차이는 평가(evals)와 오류 분석(error analysis)을 절차대로 꾸준히 해 나가는 능력이다.
• 강의에 나온 예: 고객 상담 에이전트, 깊이 있는 조사 보고서 쓰기, 까다로운 법률 문서 처리, 환자 정보를 보고 진단 후보 내기.
• 대회에서 쓸 점: 에이전트를 만드는 시간과 따로, 평가와 오류 분석 시간을 처음부터 일정에 넣는다.
• 원문: "the ability to drive a disciplined development process, specifically one focused on evals and error analysis" [강의 M1 L1]

2강 What is agentic AI? (5분 12초)

• 보통은 언어 모델에게 글을 첫 낱말부터 끝 낱말까지 한 번에, 지우기 없이 쓰게 한다. 사람도 그렇게는 잘 못 쓰고, AI 모델도 같다.
• 에이전트 방식은 개요 쓰기, 웹 검색, 초안 쓰기, 초안 읽고 고칠 곳 찾기, 고쳐 쓰기를 차례로 되풀이한다. 시간은 더 걸리지만 결과물이 훨씬 좋다.
• 정의: 언어 모델을 쓰는 앱이 일 하나를 끝내려고 여러 단계를 실행하는 과정이다.
• 짜기에 따라, 모델이 사실 몇 가지를 사람에게 검토해 달라고 요청하는 사람 확인(human in the loop) 단계를 넣을 수도 있다.
• 복잡한 일을 작은 단계로 나누는 일 쪼개기(task decomposition)와, 단계마다 그 단계를 잘 해낼 부품을 만드는 기술이 에이전트를 만드는 실력을 가른다.
• 강의에 나온 예: 조사 에이전트(research agent)에 'SpaceX와 겨룰 로켓 회사를 어떻게 세우나'를 넣으면, 웹을 검색해 자료를 모으고, 순위를 매기고, 개요를 쓰고, 편집 에이전트의 검토를 거쳐 마크다운 보고서를 낸다.
• 대회에서 쓸 점: 인터뷰에서 들은 사실 가운데 틀리면 안 되는 것(금액, 수량, 날짜)은 사람이 확인하는 단계를 둔다.
• 원문: "So an agentic AI workflow is a process where an L1 based app executes multiple steps to complete a task." [강의 M1 L2] 자막이 LLM을 L1으로 잘못 적었다.

3강 Degrees of autonomy (5분 3초)

• 앤드류 응은 '무엇이 진짜 에이전트인가'를 다투는 논쟁이 쓸데없다고 봤다. 에이전트냐 아니냐가 아니라 스스로 하는 정도(autonomy)가 다를 뿐이라는 뜻으로 '에이전트 방식'이라는 말을 썼다.
• 덜 스스로 하는 에이전트: 사람이 단계를 모두 미리 정하고, 검색 같은 도구 호출도 코드에 고정해 둔다. 모델이 정하는 것은 주로 어떤 글을 쓸지다.
• 많이 스스로 하는 에이전트: 단계의 순서까지 모델이 정한다. 새 함수를 쓰거나 새 도구를 만들어 실행하기도 한다.
• 그 사이: 몇 가지를 정하고 도구도 고르지만, 도구는 대개 미리 정해져 있다.
• 덜 스스로 하는 쪽에도 지금 많은 회사가 쓰는 쓸모 있는 응용이 아주 많다. 많이 스스로 하는 쪽은 다루기 어렵고 결과를 미리 알기 어려우며, 연구가 한창이다.
• 강의에 나온 예: 블랙홀 글쓰기. 덜 스스로 하는 판은 검색어 만들기, 웹 검색, 페이지 받기, 글쓰기 순서가 정해져 있다. 많이 스스로 하는 판은 무엇을 검색할지, 페이지를 몇 개 받을지, 다시 볼지를 모델이 정한다.
• 대회에서 쓸 점: 순서가 정해진 조합 업무(주문 정리, 분배 계산)는 순서를 코드로 정해 두고, 모델에게는 읽기와 쓰기만 맡기는 데서 시작한다.
• 원문: "there are tons of applications in the less autonomous end of the spectrum that are very valuable" [강의 M1 L3]

4강 Benefits of agentic AI (4분 47초)

• 가장 큰 이점은 전에는 못 하던 여러 일을 잘 해내는 것이다. 다른 이점은 동시에 하기(parallelism)와 부품 바꿔 끼우기(modularity)다.
• 앤드류 응 팀이 모은 자료: 코딩 시험 Human Eval에서 코드를 한 번에 쓰게 하면 GPT-3.5는 40%, GPT-4는 67%를 맞혔다.
• GPT-3.5도 GPT-4도 에이전트 방식으로 감싸 코드를 쓰고, 다시 보고, 고치게 하면 훨씬 높아졌다. GPT-3.5에서 오른 폭이 모델 한 세대가 좋아진 폭보다 컸다.
• 에이전트 방식은 한 번에 쓰게 할 때보다 오래 걸린다. 사람이 하나씩 읽을 웹 페이지를 한꺼번에 받아 오면 사람보다는 빨리 끝낼 수 있다.
• 검색 엔진(구글, 빙, 덕덕고 등)을 바꾸거나 뉴스 검색을 끼워 넣고, 단계마다 다른 언어 모델과 제공 회사를 써 보며 가장 좋은 것을 고른다.
• 강의에 나온 예: 블랙홀 글. 언어 모델 3개가 동시에 검색어를 내고, 검색마다 상위 결과 3개씩, 웹 페이지 9개를 한꺼번에 받아 글을 쓴다. 숫자는 모두 예로 든 숫자다.
• 대회에서 쓸 점: 자료를 여러 곳에서 모을 때는 한꺼번에 받아 오게 하고, 검색 도구와 모델은 바꿔 끼우기 쉽게 따로 떼어 만든다.
• 원문: "the improvement from one generation of model to another, which is huge, is still not as big a difference as implementing an agentic workflow on the previous generation of model" [강의 M1 L4]

5강 Agentic AI applications (7분 40초)

• 송장 처리처럼 따라갈 순서가 뚜렷한 일은 단계별로 믿을 만하게 처리하기 쉽다. PDF를 글로 바꾸고, 송장인지 확인하고, 필요한 칸을 뽑아 데이터베이스에 넣는다.
• 기본 주문 문의 답장도 순서가 뚜렷하다. 주문 내용 뽑기, 고객 기록 찾기, 답장 초안 쓰기를 하고, 사람이 검토한 뒤 보낸다. 이런 에이전트는 이미 많은 회사에서 쓴다.
• 필요한 단계를 미리 알 수 없는 일은 어렵다. '산 수건을 반품하고 싶다'는 문의라면 산 기록 확인, 반품 규정 확인, 반품 전표 발행, 기록 바꾸기를 모델이 스스로 정해야 한다.
• 웹 브라우저를 직접 쓰는 컴퓨터 사용(computer use) 에이전트는 연구가 한창이다. 페이지가 늦게 뜨면 헷갈리고 정확히 못 읽는 페이지도 많아, 틀리면 안 되는 일에 쓸 만큼 아직 믿을 수 없다.
• 쉬운 쪽은 표준 절차가 이미 있고 글만 다루는 일이다. 어려운 쪽은 단계를 그때그때 정해야 하거나, 소리나 그림 같은 입력이 섞인 일이다.
• 강의에 나온 예: 샌프란시스코에서 워싱턴 DC로 가는 United 항공편 두 편의 빈자리 확인을 맡겼다. 에이전트는 United 사이트에서 막히자 Google Flights로 옮겨 찾고, 다시 돌아와 빈자리가 있다고 답했다.
• 대회에서 쓸 점: 조합 업무 가운데 절차가 정해져 있고 글로 된 일부터 고른다. 사진이나 음성 자료는 먼저 글로 바꿔 넣는다.
• 원문: "the tasks that are easier will tend to be ones where there is a clear step-by-step process" [강의 M1 L5]

6강 Task decomposition: Identifying the steps in a workflow (8분 36초)

• 사람이라면 이 일을 어떤 단계로 할지 적는다. 단계마다 묻는다. 언어 모델, 짧은 코드, 함수 호출, 도구 중 하나로 할 수 있나?
• 답이 '아니요'면 사람이라면 그 단계를 어떻게 할지 다시 묻고, 더 작은 단계로 쪼갠다.
• 처음 쪼갠 판을 만들어 돌려 보고, 원하는 수준이 될 때까지 여러 번 고친다. 고쳐 나가려면 평가할 줄 알아야 한다.
• 쌓기 블록(building block) 가운데 AI 모델: 언어 모델은 글쓰기, 무엇을 부를지 정하기, 정보 뽑기를 잘한다. PDF를 글로 바꾸기, 글 읽어 주기, 그림 분석에는 다른 AI 모델을 쓴다.
• 쌓기 블록 가운데 소프트웨어 도구: 외부 서비스 부르기(API), 데이터베이스 조회, 큰 글 모음에서 맞는 글 찾기(RAG), 코드 실행.
• 강의에 나온 예: 조사 글쓰기. 처음에 한 번에 쓰게 하던 것을 개요, 검색, 글쓰기 3단계로 나눴다. 글의 처음, 가운데, 끝이 서로 맞지 않자, 글쓰기를 초안, 고칠 곳 찾기, 고쳐 쓰기 3단계로 더 쪼갰다. 앤드류 응이 실제로 겪은 일이다.
• 대회에서 쓸 점: 인터뷰 정리, 자료 다듬기, 조합 업무 처리를 사람이 하는 순서대로 적고, 단계마다 '모델, 코드, 도구 중 무엇으로 할 수 있나'를 묻는다.
• 원문: "can each of them be done either by an LLM, or by a short piece of code, or by a function call, or by a tool" [강의 M1 L6]

7강 Evaluating agentic AI (evals) (5분 39초)

• 무엇이 잘못될지 미리 알기 어렵다. 평가를 미리 짜기보다, 먼저 만들고 결과를 직접 읽으며 아쉬운 곳을 찾는다.
• 맞다, 틀리다가 분명한 기준은 코드로 센다. 예: 경쟁사 이름 목록을 두고, 전체 답장 가운데 경쟁사를 말한 비율을 센다.
• 주관이 섞인 기준은 다른 언어 모델에게 채점시키는 AI 채점(LLM as a judge)을 쓴다. 다만 1~5점 매기기는 잘 맞지 않아 앤드류 응은 잘 쓰지 않는다.
• 평가는 크게 두 가지다. 에이전트 전체의 최종 결과를 재는 전체 평가(end-to-end)와 한 단계의 결과만 재는 부품 평가(component level)다.
• 단계마다 나온 중간 결과를 단계별 기록(trace)이라 한다. 단계별 기록을 하나하나 읽고 나아질 곳을 찾는 일이 오류 분석이다.
• 강의에 나온 예: 주문 답장 에이전트가 'RivalCo와 달리 저희는 반품이 쉬워요'처럼 경쟁사를 말했다. 만들기 전에는 떠올리기 어려운 문제다.
• 대회에서 쓸 점: 조합 에이전트 답에 들어가면 안 되는 말이 보이면, 그 말이 나온 비율을 코드로 세는 평가를 붙인다.
• 원문: "the best practice is really to build it first and then examine it to figure out where it is not yet satisfactory" [강의 M1 L7]

8강 Agentic design patterns (7분 5초)

• 에이전트를 짜는 대표 방식은 넷이다. 다시 보기(reflection), 도구 쓰기(tool use), 계획 세우기(planning), 나눠 맡기(multi-agent collaboration).
• 다시 보기: 모델이 쓴 코드를 다시 보여 주며 맞는지, 모양새, 효율을 따져 비판하게 하고, 그 비판으로 고쳐 쓰게 한다. 늘 맞히게 해 주지는 않지만 성능이 꽤 오를 때가 있다.
• 도구 쓰기: 모델에게 부를 수 있는 함수를 준다. 웹 검색, 코드 실행, 데이터베이스, 메일, 달력 등이 있고, 무엇을 부를지는 모델이 정한다.
• 계획 세우기: 개발자가 순서를 미리 정하지 않고 모델이 할 일의 순서를 정한다. 지금은 다루기 어렵고 실험에 가깝지만, 때로 아주 좋은 결과를 낸다.
• 나눠 맡기: 역할이 다른 에이전트 여럿이 함께 일한다. 무엇을 할지 미리 알기 어려워 다루기 어렵지만, 연구에서는 전기 쓰기, 체스 수 고르기 같은 복잡한 일에서 더 좋은 결과를 냈다.
• 강의에 나온 예: Hugging GPT 논문. '그림 속 소년과 같은 자세로 책 읽는 소녀 그림을 만들고, 목소리로 설명하라'고 하자, 모델이 자세 찾기, 그림 만들기, 그림을 글로 바꾸기, 글을 소리로 바꾸기 모델을 차례로 부르기로 정했다.
• 대회에서 쓸 점: 다시 보기와 도구 쓰기로 먼저 만들고, 계획 세우기와 나눠 맡기는 그것으로 안 될 때 더한다.
• 원문: "I think four key design patterns for building agentic workflows are reflection, two-use, planning, and multi-agent collaboration." [강의 M1 L8] 자막이 tool use를 two-use로 잘못 적었다.

모델에게 자기 결과를 다시 보고 고치게 한다. 코드 실행 결과나 검색 결과 같은 바깥 정보(external feedback)를 넣으면 더 많이 나아진다.

9강 Reflection to improve outputs of a task (3분 57초)

• 모델에게 첫 판(v1)을 쓰게 한 뒤, 같은 모델이나 다른 모델에게 다른 지시문(prompt)으로 다시 보고 둘째 판(v2)을 쓰게 한다.
• 모델마다 잘하는 것이 다르다. 생각하는 모델(reasoning model)은 버그를 잘 찾아서, 앤드류 응은 초안은 바로 쓰게 하고 버그 찾기는 생각하는 모델에게 맡기기도 한다.
• 모델 밖에서 온 새 정보, 곧 바깥 정보가 있으면 다시 보기가 훨씬 강해진다. 예: 코드를 돌려 나온 결과와 오류 메시지.
• 강의에 나온 예: 토미에게 저녁 약속을 묻는 메일 초안을 다시 읽고, '다음 달'을 정확한 날짜로 바꾸고, 오타를 고치고, 빠진 이름을 넣는다.
• 대회에서 쓸 점: 다듬은 자료를 다시 보게 할 때 원본 자료를 함께 넣어 대조하게 한다.
• 원문: "reflection is much more powerful when there is new additional external information that you can ingest into the reflection process" [강의 M2 L1]

10강 Why not just direct generation? (5분 12초)

• 한 번 묻고 바로 답을 받는 것을 한 번에 쓰기(direct generation)라 한다. 바라는 출력의 예시를 하나도 넣지 않으니 예시 없이 묻기(zero-shot)라고도 한다.
• 여러 연구에서, 갖가지 일에 다시 보기를 쓰면 한 번에 쓰기보다 성능이 높았다(Madaan 등의 연구). 다만 내 일에서는 다를 수 있다.
• 다시 보기 지시문에는 첫 판을 다시 보라고 분명히 적고, 따질 기준을 구체적으로 준다. 메일이라면 말투를 보고, 사실, 날짜, 약속이 맞는지 확인하게 한다.
• 강의에 나온 예: 다시 보기가 도움이 되는 곳으로 복잡한 JSON 같은 구조 있는 출력, 차 끓이는 법 같은 단계 목록, 스타트업 도메인 이름 짓기(발음이 어렵거나 다른 언어에서 나쁜 뜻인 이름 걸러 내기)를 들었다.
• 대회에서 쓸 점: 다시 보기 지시문에 기준을 적는다. 예: 원본과 숫자가 같은가, 단위가 맞는가, 쉬운 말로 짧은가.
• 원문: "that guides the LLM better in reflecting and critiquing on the criteria that you care the most about" [강의 M2 L2]

11강 Chart generation workflow (3분 54초)

• 그림도 읽는 모델(multimodal)에게 코드와 그 코드가 그린 그래프 그림을 함께 주고, 그림을 비판한 뒤 더 또렷한 그래프가 나오게 코드를 고치게 한다.
• 다시 보기 지시문 예: 데이터 분석 전문가 역할을 주고, 읽기 쉬움, 또렷함, 빠짐없음 같은 기준으로 비판한 뒤 새 코드를 쓰게 한다.
• 다시 보기는 일에 따라 조금 오르기도, 많이 오르기도, 거의 안 오르기도 한다. 내 일에서 얼마나 오르는지 알아야 한다.
• 강의에 나온 예: 커피 기계 판매 자료로 2024년과 2025년 1분기 판매를 비교하는 그래프를 그리게 하자, 첫 판은 보기 어려운 쌓은 막대그래프였다. 그림을 다시 보게 하자 해마다 막대를 나눈 그래프로 바꿨다.
• 대회에서 쓸 점: 조합에 보여 줄 표나 그래프를 만들면, 그림을 모델에게 다시 보여 주고 기준에 맞춰 고치게 한다.
• 원문: "Multimodal LLMs can use visual reasoning so it can actually look visually at this figure to find ways to improve it." [강의 M2 L3]

12강 Evaluating the impact of reflection (8분 16초)

• 다시 보기는 단계가 하나 늘어 조금 느려진다. 그래서 남기기 전에 얼마나 나아지는지 잰다.
• 정답이 있는 일: 질문 10~15개와 정답(ground truth)을 적어 두고, 다시 보기가 없을 때와 있을 때 맞힌 비율을 비교한다. 지시문을 바꿀 때마다 다시 재서 고른다.
• 정답이 없는 일: 모델에게 두 그림 중 나은 것을 고르게 하면 잘 안 맞고, 먼저 보여 준 쪽을 고르는 버릇도 있다. 그림 하나씩 채점표(rubric)의 예, 아니오 항목 5개로 매겨 더하면 더 고르게 나온다.
• 강의에 나온 예: 가게 데이터베이스에 묻는 질문(어느 색 상품이 가장 많이 팔렸나 등)에 모델이 쓴 조회 코드(SQL)를 다시 보게 하자, 맞힌 비율이 87%에서 95%로 올랐다(예로 든 숫자).
• 대회에서 쓸 점: 다시 보기 단계를 넣기 전과 후를 정답 있는 예 10~15개로 재고, 나아졌을 때만 남긴다.
• 원문: "grading with a rubric can give more consistent results" [강의 M2 L5]

13강 Using external feedback (4분 50초)

• 모델이 같은 정보만 보고 다시 보는 것보다, 바깥에서 새 정보를 넣어 다시 보게 하는 쪽이 훨씬 강하다.
• 지시문만 다듬으면 성능이 오르다가 평평해진다. 다시 보기를 넣으면 한 번 더 오르고, 바깥 정보까지 넣으면 더 높이 오를 때가 있다.
• 지시문을 고쳐도 별로 안 오르면, 다시 보기를 넣거나, 그보다 바깥 정보를 넣을 수 있는지 살핀다.
• 바깥 정보는 코드나 도구로 만든다. 코드를 돌려 결과와 오류 보기, 정규식(regular expression)으로 경쟁사 이름 찾기, 웹 검색으로 사실 확인하기, 낱말 수 세기.
• 언어 모델은 정해진 낱말 수를 아직 잘 못 지킨다. 낱말 수를 코드로 세어 넘치면 그 수를 알려 주고 다시 쓰게 한다.
• 강의에 나온 예: 조사 에이전트가 '타지마할은 1648년에 지었다'고 쓰면, 웹 검색으로 '1631년에 짓게 했고 1648년에 다 지었다'는 내용을 찾아 넣고 고쳐 쓰게 한다.
• 대회에서 쓸 점: 자료 검증에 원본 대조, 단위 검사, 글자 수 세기 같은 코드 검사를 붙이고, 그 결과를 다시 보기에 넣는다.
• 원문: "Reflection with external feedback, if you can get it, is much more powerful than reflection using the LM as the only source of feedback." [강의 M2 L6] 자막이 LLM을 LM으로 잘못 적었다.

모델에게 함수를 도구로 주면, 모델이 부를지 정하고 내 코드가 실행한다. 코드 실행과 도구 연결 표준 MCP로 쓸 수 있는 도구가 크게 늘어난다.

14강 What are tools? (6분 25초)

• 도구는 모델이 불러 달라고 요청할 수 있는 함수다. 정확히는 모델이 함수를 부르는 것이 아니라 불러 달라고 요청한다.
• 도구를 쓸지 말지는 모델이 고른다. '지금 몇 시야?'면 시간 함수를 부르고, '녹차에 카페인이 얼마나 있어?'면 부르지 않고 바로 답한다.
• 어떤 도구를 만들어 줄지는 앱이 할 일을 보고 개발자가 정한다. 도구를 여러 개 주면 모델이 그중에서 골라 차례로 쓴다.
• 강의에 나온 예: 달력 비서에 '목요일에 빈 시간을 찾아 앨리스와 약속을 잡아 줘'라고 하면, 달력 확인 도구로 빈 시간을 찾고, 시간을 골라 약속 만들기 도구로 초대를 보내고, 잡힌 약속을 알려 준다.
• 대회에서 쓸 점: 조합 업무에 필요한 동작(장부 조회, 재고 확인, 안내 문자 보내기 등)을 함수로 만들어 도구로 준다.
• 원문: "the tools are just functions that we provide to the LLM that it can request to call" [강의 M3 L1]

15강 Creating a tool (5분 45초)

• 모델은 함수를 직접 부르지 않는다. 정해진 꼴로 '이 함수를 불러 달라'는 글을 내면, 개발자 코드가 그 글을 찾아 함수를 실행한다.
• 실행 결과는 대화 기록에 넣어 모델에게 돌려준다. 모델은 그것을 보고 답을 쓰거나 다른 도구를 또 부른다.
• 예전에는 지시문에 '도구를 쓰려면 대문자로 FUNCTION과 함수 이름을 써라'처럼 직접 적었다. 지금의 앞선 모델은 도구 쓰는 법을 학습해 나와서 그럴 필요가 없다.
• 강의에 나온 예: '뉴질랜드는 지금 몇 시야?'에 모델이 시간대 인자(Pacific/Auckland)를 붙여 시간 함수를 요청하고, 코드가 실행해 돌려준 시간으로 답한다.
• 대회에서 쓸 점: 도구 요청을 받아 실행하는 코드는 내가 짠다. 보내기나 지우기처럼 되돌리기 어려운 요청은 이 코드에서 한 번 거른다.
• 원문: "in order to call a function, the LLM doesn't call the function directly" [강의 M3 L2]

16강 Tool syntax (5분 40초)

• AISuite는 앤드류 응과 지인들이 만든 공개 라이브러리다. 함수 이름과 설명 주석(docstring)을 읽어 JSON 형식 설명(JSON schema)을 자동으로 만들어 모델에게 넘기고, 모델은 이 설명을 보고 언제 부를지 정한다.
• 모델이 도구를 요청하면 AISuite가 함수를 대신 실행하고 결과를 돌려준다. 다른 도구에서는 이 일을 직접 짜야 하기도 한다.
• 최대 횟수(max turns)는 모델이 도구를 잇달아 요청하는 횟수의 상한이다. 끝없이 도는 것을 막는 값이고, 앤드류 응은 보통 5로 둔다.
• 강의에 나온 예: 시간대 인자가 있는 시간 함수라면 설명에 인자 설명까지 들어가서, 모델이 America/New York이나 Pacific/Auckland 같은 값을 넣는다.
• 대회에서 쓸 점: 도구 함수마다 설명 주석에 하는 일과 인자 뜻을 또렷하게 적는다. 모델은 그 글을 보고 도구를 고른다.
• 원문: "Behind the scenes, what this will do is create a JSON schema that describes the function in detail." [강의 M3 L3]

17강 Code execution (5분 40초)

• 계산기 단추마다 도구를 만들 수는 없다. 도구를 하나씩 늘리는 대신 모델에게 코드를 쓰게 하고 그 코드를 실행한다.
• 코드가 실패하면 오류 메시지를 다시 넣어 고쳐 쓰게 하고, 한두 번 더 해 본다.
• 모델이 쓴 코드는 격리된 실행 공간(sandbox)에서 돌리는 것이 권장 방법이다. 예: Docker, E2B. 팀원의 코딩 에이전트가 프로젝트의 파이썬 파일을 지운 일이 실제로 있었다(백업이 있어 피해는 없었다).
• 강의에 나온 예: '2의 제곱근은?'에 모델이 정해진 태그 안에 코드를 써 내면, 정규식으로 코드를 뽑아 실행해 1.4142를 얻고, 그 값으로 답을 쓴다.
• 대회에서 쓸 점: 단위 바꾸기, 합계, 분배 계산은 모델이 코드를 써서 하게 하고, 그 코드는 원본 자료를 못 건드리는 격리된 실행 공간에서 돌린다.
• 원문: "So instead of trying to implement one tool after another, a different approach is to let it write and execute code." [강의 M3 L6]

18강 MCP (5분 11초)

• MCP(Model Context Protocol)는 Anthropic이 내놓았고 지금은 여러 회사와 개발자가 쓰는 표준이다. 모델이 더 많은 자료와 도구에 닿게 해 준다.
• 앱마다 Slack, Google Drive, GitHub 연결 코드를 따로 짜면 앱 수 M 곱하기 도구 수 N만큼 일이 든다. 표준이 있으면 M 더하기 N으로 준다.
• 도구와 자료를 쓰는 쪽을 MCP 클라이언트, 내주는 쪽을 MCP 서버라고 한다. 처음에는 자료 가져오기에 무게를 뒀지만, 일반 함수도 내준다.
• 강의에 나온 예: GitHub MCP 서버를 연결한 데스크톱 앱에 'AISuite 저장소의 README를 요약해 줘', '최근 변경 요청(pull request)을 알려 줘'라고 하자, 서버의 서로 다른 도구로 내용을 받아 와 요약했다.
• 대회에서 쓸 점: 조합 자료가 있는 곳(문서, 표, 메신저)에 맞는 MCP 서버가 이미 있는지 먼저 찾고, 없을 때만 연결 코드를 짠다.
• 원문: "the total work that needs to be done by the community is now M plus N rather than M times N" [강의 M3 L7]

빨리 만들고, 결과와 단계별 기록을 읽고, 작은 평가로 재고, 틀린 단계를 세어 그곳부터 고친다. 앤드류 응은 3주 차 마지막 강에서 이 주차가 강의 전체에서 가장 비중이 큰 모듈일 것이라고 했다.

19강 Evaluations (evals) (15분 5초)

• 어디가 잘될지 미리 알기 어렵다. 몇 주씩 궁리하지 말고, 데이터가 새지 않게 안전하게 하되 엉성해도 빨리 만들어 결과를 본다.
• 결과 10~20개를 읽고 자주 나오는 실수(예: 송장 발행일과 납기일을 헷갈림)를 찾는다. 고칠 방법을 알면 바로 고치고, 오래 걸릴 일이면 그 실수를 재는 작은 평가를 만든다.
• 평가는 2×2로 나뉜다. 재는 쪽이 코드인가 AI 채점인가, 정답이 예마다 다른가 모든 예에 같은가.
• 처음에는 예시 10~20개짜리 엉성한 평가로 시작한다. 평가도 에이전트처럼 계속 고친다. 내 판단과 평가 점수가 어긋나면 예시를 늘리거나 재는 법을 바꾼다.
• 다음에 고칠 곳은 사람 전문가보다 못하는 곳에서 찾는다.
• 강의에 나온 예: 송장 납기일(코드, 예마다 정답), 인스타그램 광고 글 길이 제한(코드, 모두 같은 기준), 조사 글에 꼭 들어갈 요점(AI 채점, 예마다 정답), 그래프 채점표(AI 채점, 모두 같은 기준).
• 대회에서 쓸 점: 인터뷰 정리와 자료 다듬기 결과를 10~20개 모아 직접 읽고, 자주 틀리는 것 하나를 골라 그것부터 재는 평가를 만든다.
• 원문: "First, quick and dirty evals is fine to get started." [강의 M4 L1]

20강 Error analysis and prioritizing next steps (9분 14초)

• 감으로 고칠 단계를 고르면 몇 달을 일하고도 거의 안 나아질 수 있다. 팀이 얼마나 잘하는지 가장 잘 알려 주는 것 가운데 하나가 오류 분석을 절차대로 하는지다.
• 단계별 기록을 읽는다. 단계별 기록은 한 번 돌릴 때 나온 중간 결과 전부이고, 단계 하나의 결과만 따로 부를 때는 한 단계 기록(span)이라고 한다.
• 잘된 예는 제쳐 두고, 최종 결과가 마음에 안 든 예만 모은다.
• 표(spreadsheet)에 예마다 어느 단계가 틀렸는지 적는다. 틀렸다는 것은 같은 입력을 받은 사람 전문가보다 확실히 못했다는 뜻이다. 앞 단계에서 나쁜 입력을 받은 단계는 탓하지 않는다.
• 단계별로 틀린 비율을 세고, 자주 틀리면서 고칠 방법도 떠오르는 단계부터 고친다. 고칠 방법이 안 떠오르는 단계는 뒤로 미룬다.
• 강의에 나온 예: 조사 에이전트에서 검색어가 마음에 안 든 경우는 5%, 검색 결과가 마음에 안 든 경우는 45%였다(예로 든 숫자). 검색 결과에 학술 글보다 블로그와 대중 기사가 많았으므로, 검색 엔진과 그 설정부터 살핀다.
• 대회에서 쓸 점: 틀린 결과만 모아 단계별 기록을 읽고, 뽑기, 단위 맞추기, 계산, 답장 쓰기 가운데 어느 단계 탓인지 표로 센다.
• 원문: "I found that one of the biggest predictors for how efficient and how good a team is, is whether or not they're able to drive a disciplined error analysis process to tell you where to focus your efforts." [강의 M4 L2]

21강 More error analysis examples (5분 15초)

• 결과가 틀린 예만 10~100개 모아, 예마다 어느 단계 탓인지 표에 적는다. 맞힌 예는 보지 않는다.
• 송장 납기일 오류: PDF를 글로 바꾸는 단계가 틀렸나(사람도 날짜를 못 알아볼 만큼), 모델이 엉뚱한 날짜(예: 발행일)를 뽑았나를 나눠 센다.
• 이 예에서는 모델의 뽑기 단계 탓이 훨씬 많았다. 분석 없이 PDF 변환을 몇 주, 몇 달 고쳤다면 최종 성능은 별로 오르지 않았을 수 있다.
• 한 예에 탓이 여럿일 수 있어서, 단계별 비율을 더해도 100%가 되지 않을 수 있다.
• 고객 메일 답장: 모델이 데이터베이스 조회 코드를 잘못 썼나, 데이터베이스 자료가 틀렸나, 모델이 답장을 잘못 썼나를 나눠 센다.
• 강의에 나온 예: 고객 메일 예에서 틀린 것 가운데 75%가 데이터베이스 조회 코드 탓이었다(예로 든 숫자). 그래서 조회 코드 쓰기를 먼저, 답장 쓰기 지시문을 그다음으로 고친다.
• 대회에서 쓸 점: 한 예에 탓이 여럿이면 모두 적는다. 원본 자료가 틀린 탓과 모델이 잘못 뽑거나 쓴 탓을 나눠 센다.
• 원문: "of all the things it gets not quite right, 75% of the problems is from the database query" [강의 M4 L3]

22강 Component-level evaluations (3분 23초)

• 한 단계를 바꿀 때마다 전체를 다시 돌려 재면 비용이 크다. 다른 단계에서 생기는 무작위 차이 때문에 작은 개선이 안 보이기도 한다.
• 그래서 문제가 된 단계만 따로 재는 부품 평가를 만든다.
• 검색 엔진, 결과 개수, 검색 날짜 범위 같은 설정을 하나씩 바꾸며 부품 점수가 오르는지 빠르게 본다.
• 다 됐다고 하기 전에 전체 평가를 한 번 돌려 전체 성능도 올랐는지 확인한다.
• 단계마다 맡은 팀이 다르면, 팀마다 자기 부품 점수 하나만 보고 일할 수 있다.
• 강의에 나온 예: 웹 검색 부품 평가. 질의 몇 개마다 전문가가 꼭 나와야 할 믿을 만한 웹 자료를 정해 두고, 검색 결과와 겹치는 정도를 F1 점수 같은 정보 검색 표준 지표로 잰다.
• 대회에서 쓸 점: 자료 찾기 단계만 떼어, 사람이 정한 꼭 찾아야 할 자료 목록과 얼마나 겹치는지 재는 평가를 만든다.
• 원문: "So component level evals can provide a clearer signal for specific errors." [강의 M4 L4]

23강 How to address problems you identify (9분 47초)

• 언어 모델이 아닌 부품(웹 검색, 자료 찾기, 그림 속 사람 찾기 모델 등)은 설정값(hyperparameter)을 바꾸거나 다른 제품, 다른 제공 회사로 바꿔 본다. 예: 결과 개수, 날짜 범위, 유사도 기준, 글 조각 크기, 판정 기준값.
• 언어 모델 부품은 지시를 더 또렷하게 쓰기, 예시 넣기(few-shot), 다른 모델로 바꾸기, 단계를 더 잘게 쪼개기(쓰기와 다시 보기로 나누기 포함)를 해 본다.
• 추가 학습(fine-tuning)은 품과 비용이 많이 들어 다른 방법을 다 써 본 뒤에 쓴다. 이미 90~95%인데 마지막 몇 %가 꼭 필요한, 오래 다듬은 앱에서 쓴다(예로 든 숫자).
• 큰 최신 모델은 지시를 잘 따르고, 작은 모델은 간단한 사실 질문은 잘하지만 지시를 덜 따른다. 코딩, 지시 따르기, 특정 분야 지식처럼 모델마다 잘하는 것이 다르다.
• 모델 감각 기르기: 새 모델이 나오면 써 보고, 나만의 시험 질문 묶음을 두고, 남이 쓴 지시문을 많이 읽는다(공개 소스 코드 속 지시문 포함).
• 강의에 나온 예: 고객 통화 요약에서 개인 정보(PII)를 지우라고 하자, 작은 모델(Llama 3.1)은 형식을 어기고 이름을 놓치고 주소를 덜 지웠다. 더 똑똑한 모델은 모두 바르게 지웠다.
• 대회에서 쓸 점: 인터뷰 기록에서 개인 정보를 지우는 것처럼 지시를 정확히 따라야 하는 단계에는 지시를 잘 따르는 모델을 골라 쓴다.
• 원문: "So I tend not to fine-tune a model until I've really exhausted the other options because fine-tuning tends to be quite complex." [강의 M4 L6]

24강 Latency, cost optimization (4분 6초)

• 먼저 결과 품질을 높이고, 비용과 걸리는 시간(latency)은 나중에 줄인다. 품질을 높이는 일이 보통 가장 어렵다.
• 앤드류 응 팀은 쓰는 사람이 너무 많아져 비용이 문제가 된 적이 있다. 그는 이것을 반가운 문제라고 했다.
• 시간 줄이기: 단계마다 걸린 시간을 재고 오래 걸리는 곳을 본다. 동시에 하기, 더 작고 빠른 모델, 더 빠른 제공 회사를 써 본다.
• 비용 줄이기: 단계마다 비용을 계산해 큰 곳을 본다. 모델은 입력과 출력 길이에 따라, 외부 서비스는 부른 횟수에 따라 값이 든다.
• 이렇게 재 보면 신경 쓸 필요가 없는 단계도 분명해진다.
• 강의에 나온 예: 조사 에이전트에서 검색어 만들기 7초, 웹 검색 5초, 마지막 글쓰기 18초, 웹 검색 한 번 1.6센트(모두 예로 든 숫자).
• 대회에서 쓸 점: 대회 시간 안에서는 품질을 먼저 맞추고, 시간과 비용은 단계별로 재서 가장 큰 곳만 줄인다.
• 원문: "focus on getting high-quality outputs and to optimize cost and latency only later" [강의 M4 L7]

25강 Development process summary (3분 54초)

• 하는 일은 두 가지다. 만들기(코드 짜기)와 분석(다음에 어디를 만들지 정하기). 분석은 진척처럼 느껴지지 않아도 만들기와 비중이 같다.
• 분석은 시스템이 다듬어질수록 꼼꼼해진다. 결과와 단계별 기록 읽기, 예시 10~20개짜리 전체 평가, 단계별 오류 분석, 부품 평가 순이다.
• 이 흐름은 한 줄로만 가지 않는다. 만들기와 분석을 여러 번 오간다.
• 경험이 적은 팀은 만들기에 시간을 많이 쓰고, 오류 분석이나 평가 만들기 같은 분석에는 훨씬 적게 쓴다.
• 단계별 기록 보기, 실행 기록, 비용 계산을 돕는 도구도 쓸 만하다. 그래도 에이전트 방식은 대부분 일마다 달라서, 앤드류 응은 맞춤 평가를 직접 많이 만든다.
• 강의에 나온 예: 새 에이전트를 만들 때 앤드류 응은 엉성해도 처음부터 끝까지 도는 판을 먼저 만들고, 단계별 기록을 읽어 감으로 손볼 단계를 고른다.
• 대회에서 쓸 점: 일정에 만들기와 분석을 번갈아 넣고, 분석 기록(평가 점수, 오류 표)을 남긴다.
• 원문: "what I see less experienced teams often do is spend a lot of time building and probably much less time analyzing" [강의 M4 L8]

모델이 할 일의 순서를 스스로 짜는 계획 세우기와, 역할이 다른 에이전트 여럿이 함께 일하는 방식을 다룬다. 할 수 있는 일은 넓어지지만 다루기와 예측이 어렵다.

26강 Planning workflows (7분 10초)

• 계획 세우기는 단계 순서를 개발자가 미리 정하지 않고 모델이 정하게 한다.
• 지시문에 쓸 수 있는 도구와 그 설명을 적고, 사용자 요청을 해낼 단계별 계획을 내라고 시킨다.
• 계획이 나오면 1단계 글을 필요한 정보(도구 목록, 사용자 질문 등)와 함께 모델에게 주어 실행하고, 그 결과와 2단계 글을 다시 모델에게 주는 식으로 끝까지 간 뒤 답을 쓴다.
• 요청이 달라지면 계획도 달라진다. 그래서 여러 도구를 여러 순서로 써야 하는 폭넓은 일을 해낸다.
• 코딩 에이전트에서는 계획 세우기가 이미 잘 쓰인다. 다른 분야에서는 아직 실험에 가깝다. 실행 중에 어떤 계획이 나올지 개발자가 모르니 다루기 어렵다.
• 강의에 나온 예: 선글라스 가게에 '100달러 아래 둥근 선글라스 재고 있나요?'라고 묻자, 모델이 상품 설명 보기, 재고 확인, 가격 확인 순서의 계획을 짰다(100달러는 예로 든 숫자).
• 대회에서 쓸 점: 조합원 문의처럼 요청마다 순서가 다른 일에만 계획 세우기를 쓰고, 순서가 정해진 일은 순서를 코드로 고정한다.
• 원문: "we did not have to decide in advance what is the sequence in which to call tools in order to answer a fairly complex customer request" [강의 M5 L1]

27강 Creating and executing LLM plans (2분 39초)

• 계획을 JSON 꼴로 내게 하면, 뒤따르는 코드가 단계, 설명, 쓸 도구, 넘길 인자를 헷갈림 없이 읽어 한 단계씩 실행할 수 있다.
• XML 태그도 좋다. 마크다운은 조금 모호하고, 그냥 글이 가장 믿기 어렵다.
• 앞선 모델들은 이제 JSON을 꽤 잘 쓴다.
• 강의에 나온 예: 고객 상담 계획을 단계마다 설명, 쓸 도구, 도구에 넘길 인자 칸이 있는 JSON 목록으로 받는다.
• 대회에서 쓸 점: 계획을 JSON으로 받고, 실행 전에 코드가 도구 이름과 인자가 맞는지 검사하게 한다.
• 원문: "this allows downstream code to parse what exactly are the steps of the plan in relatively clear and unambiguous ways" [강의 M5 L2]

28강 Planning with code execution (7분 11초)

• 표 자료 질문마다 도구를 하나씩 만들면 도구가 끝없이 늘고, 새 질문이 올 때마다 막힌다. 대신 모델에게 코드를 쓰게 하면 그 코드가 여러 단계의 계획이 된다.
• 파이썬과 pandas 같은 라이브러리에는 모델이 많이 본 함수가 수백, 수천 개 있어서, 모델이 그중에서 골라 계획을 짠다.
• 연구(Xinyao Wang 등)에서도 코드로 행동하게 하는 쪽(code as action)이 JSON 계획보다 낫고, JSON 계획이 그냥 글보다 조금 나았다. 격리된 실행 공간에서 돌리라는 주의는 그대로다.
• 강의에 나온 예: 커피 기계 판매 표에 '지난주 서로 다른 거래는 몇 건?'이라고 묻자, 모델이 파일 읽기, 날짜 열 읽기, 기간 정하기, 행 거르기, 중복 지우기, 세기 순서의 코드를 썼다.
• 대회에서 쓸 점: 조합 장부 같은 표 자료 질문에는 도구를 늘리지 말고 코드로 답하게 한다.
• 원문: "letting an LLM express its plan in software code that you can just execute for the LLM can be a very powerful way to let it write rich plans" [강의 M5 L3]

29강 Multi-agentic workflows (9분 5초)

• 한 사람에게 맡기는 대신 역할이 다른 사람 서넛을 뽑는다고 생각하면, 복잡한 일을 작은 일로 나누기 쉽다.
• 에이전트 하나는 언어 모델에 역할 지시문과 그 역할에 맞는 도구를 주어 만든다. 조사 담당은 웹 검색, 디자이너는 그림 생성이나 코드 실행을 쓰고, 글 담당은 도구 없이 쓴다.
• 잇는 방식은 일직선(조사, 디자인, 글쓰기 차례)도 되고, 관리자 에이전트가 계획을 세워 다른 에이전트에게 일을 맡기는 방식도 된다. 관리자 방식은 도구 목록 대신 에이전트 목록을 주고 계획을 내게 한다.
• 강의에 나온 예: 선글라스 여름 홍보 책자. 조사 에이전트가 유행과 경쟁 상품을 조사하고, 디자이너 에이전트가 그래프와 그림을 만들고, 글 담당 에이전트가 책자를 쓴다.
• 대회에서 쓸 점: 인터뷰 정리 담당, 자료 검증 담당, 안내문 작성 담당처럼 사람을 뽑듯 역할과 도구를 나눠 에이전트를 만든다.
• 원문: "when designing a researcher or graphic designer or writer, you can focus on one thing at a time" [강의 M5 L5]

30강 Communication patterns for multi-agent systems (4분 24초)

• 가장 흔한 두 방식은 차례로 넘기는 일직선 방식과, 관리자 하나가 여러 에이전트에게 일을 주고받는 위계 방식이다. 위계 방식은 결과를 관리자에게 돌려보내게 하는 편이 만들기 간단하다.
• 덜 쓰는 방식은 아래 에이전트가 또 아래 에이전트를 부르는 깊은 위계다(예: 조사 담당 밑에 웹 조사 담당과 사실 확인 담당). 한 층짜리보다 훨씬 복잡하다.
• 모두와 모두 방식은 누구나 아무 때나 서로 말한다. 결과를 미리 알기 어려워서, 조금 어수선해도 되고 다시 돌리면 되는 일에 쓴다.
• 강의에 나온 예: 모두와 모두 방식에서는 에이전트 넷에게 나머지 셋을 부를 수 있다고 알려 주고, 보낸 메시지는 받는 쪽 에이전트가 보는 글에 덧붙인다. 모두 끝났다고 하거나 글 담당이 충분하다고 하면 끝낸다.
• 대회에서 쓸 점: 에이전트를 나누면 일직선이나 관리자 하나 방식으로 먼저 잇고, 모두와 모두 방식은 결과가 매번 달라도 되는 곳에만 쓴다.
• 원문: "there is a manager that communicates with a number of team members and coordinates their work" [강의 M5 L7]

31강 Conclusion (2분 2초)

• 다룬 것은 다시 보기, 도구 쓰기(코드 실행 포함), 평가와 오류 분석, 계획 세우기, 나눠 맡기다.
• 앤드류 응은 4주 차의 평가, 오류 분석, 만들기와 분석 오가기가 앞으로 가장 쓸모 있을 것이라고 했다.
• 계획 세우기와 나눠 맡기는 더 강한 시스템을 만들게 해 주지만, 다루기와 예측이 더 어렵다.
• 강의에 나온 예: 앤드류 응의 팀과 다른 팀들이 사람을 뽑는 면접에서, 이 강의에서 배운 기술이 있는지를 자주 본다고 했다.
• 대회에서 쓸 점: 조합원 개인 정보와 돈이 걸린 결정은 사람이 확인하게 두어, 배운 것을 책임 있게 쓴다.
• 원문: "I hope you will take these skills, use them responsibly, and just go build cool stuff" [강의 M5 L10]

대본 31개 본문에서 대소문자를 가리지 않고 센 횟수다. 챕터 제목은 세지 않았고, 자막이 잘못 적은 말(LM, two-use 등)도 세지 않았다. 내용을 담은 말만 골랐다.