앤드류 응 편지와 강연 노트

대회에서 쓰는 순서로 놓았다.

1. 편지 2024-12-11: 만들 것을 예시로 정하는 법. 고른 까닭: 인터뷰에서 들은 일을 입력과 좋은 답의 예시로 바꾸는 데 바로 쓴다.
2. 편지 2026-07-10: 사양(spec)을 짧게 쓰고 고쳐 가는 법. 고른 까닭: 짧은 시간 안에 첫 판을 만들고 고치는 순서가 그대로 나온다.
3. 강연 2026-03-01 (8분 43초~18분 10초, 26분 56초~28분 24초): 다 맡길지, 단계를 정해 줄지. 고른 까닭: 에이전트를 믿을 만하게 움직이게 하는 설계 선택과, 도구 수를 줄이는 까닭이 실제 예와 함께 나온다.
4. 편지 2025-10-15: 평가(evals)를 만드는 순서. 고른 까닭: 송장에서 자료를 뽑는 에이전트가 틀리는 방식이 나온다. 조합 자료를 다루는 에이전트와 비슷한 일이다.
5. 편지 2025-10-22: 단계별 기록(trace)으로 틀린 단계 찾기. 고른 까닭: 첫 판이 틀렸을 때 어디부터 고칠지 정하는 법이 짧게 나온다.

2024-03-20 Agentic Design Patterns Part 1

• 주소: https://www.deeplearning.ai/the-batch/how-agents-can-improve-llm-performance/
• 에이전트 방식(agentic workflow)이 올해 AI 발전을 크게 이끌 것이라고 했다. 다음 세대 기초 모델(foundation model)보다 더 클 수도 있다고 봤다.
• 지금은 AI 모델(LLM)에게 대개 한 번에 끝까지 쓰게 한다. 에이전트 방식은 개요 짜기, 필요한 검색 정하기, 초안 쓰기, 초안 다시 읽기, 고쳐 쓰기를 거친다.
• 그의 팀이 여러 연구팀의 결과를 분석했다. 코딩 시험(HumanEval)에서 한 번에 쓰게 하면 GPT-3.5는 48.1%, GPT-4는 67.0%를 맞혔다. GPT-3.5를 에이전트 고리에 넣으면 최대 95.1%였다.
• 만드는 방식을 넷으로 나눴다. 다시 보기(Reflection), 도구 쓰기(Tool Use), 계획 세우기(Planning), 나눠 맡기(Multi-agent collaboration).
• 대회에서 쓸 점: 에이전트가 한 번에 답을 내게 두지 않는다. 초안, 다시 읽기, 고치기 단계를 넣는다.
• 원문: "With AI, such an iterative workflow yields much better results than writing in a single pass." [편지 2024-03-20]

2024-06-12 Welcoming Diverse Approaches Keeps Machine Learning Strong

• 주소: https://www.deeplearning.ai/the-batch/welcoming-diverse-approaches-keeps-machine-learning-strong/
• 머신러닝은 여러 갈래의 연구를 받아들여 컸다. 에이전트도 같은 태도로 넓게 보자는 편지다.
• "에이전트냐 아니냐"를 둘 중 하나로 가르지 않는다. 형용사 "에이전틱(agentic)"을 써서, 시스템마다 에이전트다운 정도가 다르다고 본다.
• 모델을 한 번 부르는 것은 분명히 에이전트가 아니다. 큰 지시를 받아 계획하고, 도구를 쓰고, 여러 단계를 되풀이하는 자율 에이전트는 분명히 에이전트다. 그 사이는 어느 쪽이라고 하기 애매하다.
• 처음 하는 사람은 단순한 에이전트 방식부터 만들고 차츰 정교하게 키우면 된다고 했다.
• 대회에서 쓸 점: 처음부터 다 맡기는 에이전트를 노리지 않는다. 단순한 흐름으로 첫 판을 만들고 하나씩 키운다.
• 원문: "We can also encourage newcomers to start by building simple agentic workflows and iteratively make their systems more sophisticated." [편지 2024-06-12]

2024-12-11 Best Practices for AI Product Management

• 주소: https://www.deeplearning.ai/the-batch/best-practices-for-ai-product-management/
• 만들 것을 구체적인 예시로 정한다. "계좌 질문에 답하는 은행 챗봇"은 흐리다. 기획자(PM)가 바라는 대화 예시를 10~50개쯤 적으면 범위가 또렷해진다.
• 입력과 바라는 출력의 예시가 곧 요구 사항 문서(PRD)라고 했다. 처음 예시는 기획자가 직접 사진을 찍어 표시하는 식으로 엉성하게 모아도 된다. 나중에는 실제 운영에서 모인 자료로 바뀐다.
• 될지 안 될지는 지시문(prompt)을 넣어 보며 가늠한다. 예: 고객 메일을 알맞은 부서로 보내는 도구라면, 모델이 부서를 맞게 고르는지 정확도를 본다. 안 되면 기획자가 스스로 아이디어를 접거나 고친다.
• 엔지니어 없이 시제품을 만들어 사용자 반응을 받는다. 코딩 기초를 아는 사람이 이런 도구를 훨씬 잘 쓴다고 했다.
• 대회에서 쓸 점: 인터뷰에서 들은 일을 "입력과 좋은 답" 예시로 적는다. 그 예시를 에이전트의 설계서로 쓴다.
• 원문: "In other words, the data is your PRD (product requirements document)!" [편지 2024-12-11]

2025-03-26 When to Fine-Tune, and When Not To

• 주소: https://www.deeplearning.ai/the-batch/when-to-fine-tune-and-when-not-to/
• 미세 조정(fine-tuning)은 이미 학습된 모델을 내 자료로 더 학습시키는 것이다. 자료 모으기, 학습, 배포가 번거롭다. 그는 대개 지시문과 단순한 에이전트 방식으로 안 될 때에야 쓴다.
• 미세 조정이 맞았던 곳은 셋이다. 꼭 맞아야 하는 일의 정확도를 올릴 때(예: 상담 챗봇이 맞는 API를 부르는 비율을 95%에서 99%로), 특정 말투를 낼 때, 사용량이 늘어 작은 모델로 바꾸며 속도와 비용을 줄일 때.
• 사람에게 주는 표준 작업 절차(SOP)는 모델의 지시문에 넣을 수 있다. 규칙을 말로 정하기 어려워 사람도 예시를 많이 봐야 배우는 일이면 미세 조정이 맞을 수 있다.
• 모델이 모르는 지식을 넣을 때는 대개 검색 증강 생성(RAG, 자료를 찾아 모델에게 함께 주는 방법)이 더 쉽다. 미세 조정을 쓰는 팀 가운데 75%쯤은 더 쉬운 방법(지시문, 에이전트 방식)으로도 될 것이라고 봤다. 나머지 25%는 그도 더 나은 길을 모른다.
• 대회에서 쓸 점: 조합의 업무 규칙은 먼저 지시문에 글로 적어 넣는다.
• 원문: "Teams often write Standard Operating Procedures (SOPs) for human workers to follow, and these SOPs can go into the prompts of models." [편지 2025-03-26]

2025-04-16 We Iterate on Models. We Can Iterate on Evals, Too

• 주소: https://www.deeplearning.ai/the-batch/we-iterate-on-models-we-can-iterate-on-evals-too/
• 많은 팀이 자동 평가를 너무 늦게 넣고, 사람이 출력을 눈으로 보는 기간을 너무 오래 끈다. 평가를 예시 100개나 1,000개를 만들고 기준을 설계해 검증하는 큰 투자로 여겨서다.
• 평가도 고쳐 가며 키우라고 했다. 예시 5개와 다듬지 않은 기준으로 시작해도 된다. 신경 쓰는 것의 일부만 재도 된다. 예: 상담 에이전트가 환불 API를 맞게 부르는지만 먼저 잰다.
• 고리가 둘이다. 평가와 사람 판단으로 시스템을 고치는 고리, 평가가 사람 판단과 더 맞도록 평가를 고치는 고리.
• 좋은 평가의 기준: 숙련된 사람이 보기에 A가 B보다 확실히 나으면 평가 점수도 A가 확실히 높아야 한다. 둘이 비슷하면 점수도 비슷해야 한다. 어긋나면 평가를 고친다.
• 대회에서 쓸 점: 예시 몇 개로 엉성한 평가를 먼저 만든다. 내 눈의 판단과 어긋나면 평가를 고친다.
• 원문: "It's okay to start with a quick-and-dirty implementation (say, 5 examples with unoptimized metrics) and then iterate and improve over time." [편지 2025-04-16]

2025-07-16 How to Get Through the Product Management Bottleneck

• 주소: https://www.deeplearning.ai/the-batch/how-to-get-through-the-product-management-bottleneck/
• 코딩 에이전트가 만드는 일을 빠르게 하자, 무엇을 만들지 정하는 일이 새 병목(bottleneck)이 됐다. 그는 이를 제품 관리(product management) 병목이라고 불렀다. 초기 프로젝트에서 더 그렇다.
• 사용자를 깊이 이해하는 기획자는 감으로 빨리 정하고 자주 맞힌다. 새 정보가 들어오면 사용자에 대한 이해를 고쳐 감을 다듬는다.
• 예: 기능 4개 중 무엇을 원하는지 사용자 약 1,000명에게 물었더니 그의 생각과 반대로 나왔다. 그는 결과를 그대로 따르기보다, 결과를 자세히 보고 사용자에 대한 이해를 고친 뒤 그 이해로 정하는 쪽이 대부분의 프로젝트에 낫다고 했다.
• 이 방식은 어떤 기능을 먼저 만들지처럼 큰 결정이 몇 개일 때 맞는다. 어떤 광고를 보일지처럼 결정이 아주 많으면 사람의 감은 따라가지 못하고 자동 실험이 맞는다.
• 대회에서 쓸 점: 인터뷰에서 들은 말을 그대로 옮기지 않는다. 그 말로 인물의 사정을 이해하고, 그 이해로 무엇을 만들지 정한다.
• 원문: "Examine the survey data in detail to see how it changes my beliefs about what users want." [편지 2025-07-16]

2025-10-01 How to Liberate Data From Large, Complex PDFs

• 주소: https://www.deeplearning.ai/the-batch/how-to-liberate-data-from-large-complex-pdfs/
• 쌓아 둔 PDF, 서식, 발표 자료에는 쓰이지 않은 정보가 많다. 정확히 뽑아낼 수 있으면 쓸 데가 많다. 예: 진료 서식, 재무제표, 선적 서류, 계약서.
• 정확히 뽑기는 쉽지 않다. 큰 숫자 표나 복잡한 서식에서 숫자를 잘못 뽑고도 그럴듯한 금액을 내놓는 실수가 있다. 사람들은 컴퓨터가 숫자에 강하다고 믿어서 이런 조용한 실패를 잘 못 잡는다.
• 사람은 문서를 한 번 훑고 결론 내지 않는다. 부분을 나눠 차례로 보며 하나씩 뽑는다. 에이전트 방식도 그렇게 할 수 있다.
• 자기 제품 소개가 섞여 있다. 편지는 LandingAI의 문서 추출 도구(ADE)를 알리는 글이기도 하다. 이 도구는 문서를 작은 부분으로 나눠 본다. 예: 표를 떼어 낸 뒤 줄, 칸, 합친 칸을 찾는다.
• 대회에서 쓸 점: 자료에서 숫자를 뽑으면 원본과 맞춰 보는 단계를 따로 둔다. 큰 표는 나눠서 뽑는다.
• 원문: "I've seen users find silent failures in the form of incorrect numerical outputs particularly hard to catch." [편지 2025-10-01]

2025-10-08 Check Out Our Course on How to Build AI Agents!

• 주소: https://www.deeplearning.ai/the-batch/check-out-our-course-on-how-to-build-ai-agents/
• 자기 강의(Agentic AI) 안내 글이다. 특정 프레임워크 없이 파이썬으로 네 가지 만드는 방식과, 복잡한 일을 작은 일의 차례로 쪼개는 법을 가르친다.
• 많은 팀과 에이전트를 만들어 보니, 누가 잘 만드는지 가장 잘 알려 주는 것은 평가와 오류 분석(error analysis)을 규율 있게 돌릴 줄 아느냐였다고 했다.
• 이를 모르는 팀이 지시문을 고치고 도구를 만들며 몇 달을 쓰고도 성능이 더 오르지 않는 데서 멈추는 것을 봤다고 했다.
• 평가를 넣고 에이전트가 한 일을 단계별 기록으로 보면, 흐름의 어느 부분이 망가지는지 보이고 고칠 부품을 짚어 낸다.
• 대회에서 쓸 점: 고칠 곳을 짐작으로 고르지 않는다. 단계마다 기록이 남게 만들고, 기록을 보고 고친다.
• 원문: "Instead of guessing what to work on, you'll let evals data guide you." [편지 2025-10-08]

2025-10-15 Improve Agentic Performance with Evals and Error Analysis, Part 1

• 주소: https://www.deeplearning.ai/the-batch/improve-agentic-performance-with-evals-and-error-analysis-part-1/
• 틀린 곳을 서둘러 고치기보다, 평가와 오류 분석으로 근본 원인을 찾는 쪽이 더 빨리 나아간다고 했다.
• 오류를 분석하려면 먼저 무엇이 오류인지 정해야 한다. 그래서 평가를 먼저 넣는다.
• 생성형 AI는 출력의 폭이 넓어 틀리는 방식도 많다. 예: 받은 송장으로 장부를 채우는 에이전트는 납기일, 최종 금액, 지급인과 청구인 주소, 통화를 잘못 뽑거나, API를 잘못 불러 확인 단계가 실패할 수 있다.
• 그래서 오류 기준을 미리 정하기보다, 시제품을 빨리 만들고 출력 몇 개를 직접 보며 어디서 걸리는지 본 뒤 기준을 만드는 편이 대개 낫다. 기준은 코드로 재는 객관 기준과 AI 채점(LLM-as-judge)으로 재는 주관 기준이 있고, 에이전트에서는 더 자주 고친다.
• 대회에서 쓸 점: 첫 판의 출력을 보고 날짜, 금액, 이름처럼 틀린 칸을 하나씩 평가 항목으로 만든다.
• 원문: "Before analyzing errors, we first have to decide what is an error." [편지 2025-10-15]

2025-10-22 Improve Agentic Performance with Evals and Error Analysis, Part 2

• 주소: https://www.deeplearning.ai/the-batch/improve-agentic-performance-with-evals-and-error-analysis-part-2/
• 예: 웹을 찾아 보고서를 쓰는 조사 에이전트는 (1) 검색어 만들기 (2) 검색하기 (3) 가져올 자료 고르기 (4) 보고서 쓰기를 거친다.
• 보고서가 사람 조사원보다 못하면, 못한 사례를 모아 단계별 기록을 읽는다. 같은 단계를 사람이 했을 때보다 눈에 띄게 못한 단계가 어디인지 센다. 기준은 사람 수준 성과(human level performance, HLP)다.
• 처음에는 기록 하나나 몇 개를 가볍게 읽어도 된다. 예: 검색어가 자주 엉뚱하면 그 단계부터 손본다. 시스템이 자라면 성능이 나쁜 사례 수천 개로 단계마다 문제를 낸 비율을 재는 데까지 간다.
• 단계를 나누는 방식도 바꿀 수 있다. 모델이 좋아지면 이끄는 코드(scaffolding)를 걷어내고 모델에게 더 맡기는 일이 흔하다. 단계 하나하나는 괜찮은데 이어 놓으면 사람보다 못할 때, 단계가 너무 딱딱하다는 뜻일 수 있다.
• 대회에서 쓸 점: 틀린 답이 나오면 단계별 중간 결과를 읽고, 사람이라면 더 잘했을 단계부터 고친다.
• 원문: "The key principle is to look at the steps of the workflow and see which steps did a bad job on a given input, often by benchmarking to human level performance (HLP)." [편지 2025-10-22]

2025-11-05 Tear Down Data Silos!

• 주소: https://www.deeplearning.ai/the-batch/tear-down-data-silos/
• 에이전트가 여러 자료를 함께 보며 패턴을 찾는 능력이 좋아졌다. 그래서 자료가 시스템마다 따로 떨어져 있으면 손해가 커진다. 예: 메일 클릭은 한 업체 시스템에, 뒤이은 구매는 다른 업체 시스템에 있으면 둘을 함께 보는 에이전트를 만들기 어렵다.
• 일부 소프트웨어 업체는 고객이 자기 자료를 꺼내기 어렵게 만든다. 그의 팀이 고객 자료를 맡겨 둔 한 업체는 자료를 꺼낼 API 키 값으로 2만 달러 넘게 불렀다.
• 그는 자기 자료를 직접 다룰 수 있는 소프트웨어를 고른다. 예: 메모를 자기 컴퓨터에 마크다운 파일로 두고, 그 파일을 읽고 쓰는 에이전트를 만들었다.
• AI가 표로 정리되지 않은 자료(PDF 등)도 잘 다루게 되어, 그런 자료를 정리하는 값이 커졌다. 회사와 개인은 자료를 AI가 쓸 수 있게 정리해야 한다고 했다.
• 대회에서 쓸 점: 조합 자료가 여러 곳에 흩어져 있으면 에이전트가 읽을 수 있는 한 곳으로 먼저 모은다.
• 원문: "In the era of generative AI, businesses and individuals have important work ahead to organize their data to be AI-ready." [편지 2025-11-05]

2025-12-10 Build an Autonomous Agent Using This Simple Recipe!

• 주소: https://www.deeplearning.ai/the-batch/build-an-autonomous-agent-using-this-simple-recipe/
• 몇 줄의 코드로 에이전트를 만들 수 있다. 모델에게 도구(디스크 접근이나 웹 검색)를 주고, 큰 일을 지시하고, 알아서 하게 둔다. 그러면 매우 자율적이고, 능력은 중간이고, 매우 믿기 어려운 에이전트가 된다고 했다.
• 지금 상업적으로 쓰이는 에이전트 방식 가운데 이렇게 만든 것은 거의 없다. 지금 믿을 만한 에이전트를 만들려면 단계별 행동을 이끄는 코드가 훨씬 많이 필요하다.
• 모델이 좋아지면 이끄는 코드가 덜 든 에이전트가 늘 것이라고 봤다.
• 자기 제품 소개가 섞여 있다. 예제는 그가 만드는 오픈소스 aisuite로 짰다. 예: 모델에게 파일 쓰기 도구를 주고 뱀 게임 HTML 파일을 만들게 한다.
• 대회에서 쓸 점: 도구만 주고 다 맡기는 방식은 연습용으로 쓴다. 제출할 에이전트에는 단계를 정해 준다.
• 원문: "With a few lines of code, you can now build a highly autonomous, moderately capable, and highly unreliable agent." [편지 2025-12-10]

2026-01-23 From AI Experiments to AI Products

• 주소: https://www.deeplearning.ai/the-batch/from-ai-experiments-to-ai-products/
• 다보스 세계경제포럼에서 쓴 편지다. CEO들과 나눈 이야기에서 되풀이된 주제는, 아래에서 올라온 작은 AI 실험을 많이 벌이는 방식이 큰 성과로 이어지지 못했다는 것이다. 더 크게 얻으려면 업무 흐름을 처음부터 끝까지 다시 짜야 한다.
• 예: 은행 대출은 마케팅, 신청, 1차 승인, 최종 심사, 실행의 단계를 거친다. 1시간 걸리던 1차 승인을 AI가 10분에 해도, 나머지가 그대로면 조금 아낄 뿐이다.
• 신청자가 1주를 기다리지 않고 10분 만에 답을 받는 "10분 대출" 상품으로 바꾸면 달라진다. 그러려면 마케팅, 신청 접수, 최종 심사, 실행도 함께 바꿔야 한다.
• 문제에 가까운 현장 사람이 해법을 먼저 보는 일이 많다. 흐름 전체를 바꾸려면 위에서 넓게 보고 방향을 잡는 일도 함께 필요하다.
• 대회에서 쓸 점: 조합 업무에서 AI를 넣을 한 단계만 보지 않는다. 앞뒤 단계와 조합원이 받는 결과까지 함께 바꿀 수 있는지 본다.
• 원문: "Instead, bigger gains require workflow redesign: taking a broader, perhaps top-down view of the multiple steps in a process and changing how they work together from end to end." [편지 2026-01-23]

2026-05-29 Forward Deployed Engineers and the Future of AI Engineering

• 주소: https://www.deeplearning.ai/the-batch/forward-deployed-engineers-and-the-future-of-ai-engineering/
• 현장 배치 엔지니어(Forward Deployed Engineer, FDE)는 고객 조직 안에 들어가 그 회사에 맞는 에이전트 방식을 만들고 다듬는다. 기성 AI 모델을 회사 업무에 맞추는 일이 많아 다시 늘고 있다.
• 기술 말고도 소통과 사업 감각이 필요하다. 고객과 이야기해 필요를 알고, 할 일의 순서를 정하고, 어려운 기술을 설명하고, 무리한 요청은 정중히 거절한다.
• 그래도 회사 안에서 일하는 AI 엔지니어 자리가 훨씬 많아질 것이라고 봤다. FDE는 특정 업체의 제품을 회사 업무에 깊이 엮는다. 1년 뒤 어느 AI 서비스가 가장 나을지 알기 어려운 지금, 업체를 바꿀 여지가 줄어든다.
• 지금 수요가 큰 사람은 AI 부품(지시문, 에이전트 프레임워크, 평가)으로 소프트웨어를 만들고 코딩 에이전트를 잘 쓰는 AI 엔지니어다.
• 대회에서 쓸 점: 인물과 인터뷰할 때 네 가지를 한다. 필요를 듣고, 먼저 할 일을 고르고, 쉬운 말로 설명하고, 안 되는 요청은 까닭을 대고 거절한다.
• 원문: "they may need to speak with clients to understand their needs, formulate a strategy to prioritize projects, explain complex technology, and respectfully push back if a client asks for something unrealistic" [편지 2026-05-29]

2026-06-12 Agents on the Desktop

• 주소: https://www.deeplearning.ai/the-batch/agents-on-the-desktop/
• 데스크톱 에이전트는 대화만 하지 않는다. 내 컴퓨터의 파일을 읽고 고치고, 메시지를 주고받고, 정해진 때에 결과물(예: 매일 뉴스 요약)을 낸다.
• 만드는 법: 파일 접근, 웹 검색, 메신저 연결 같은 도구를 만들어 모델에게 주고, 권한과 안전 장치(guardrails)를 정한다. 언제 어떤 도구를 쓸지는 모델이 고른다. 모델을 감싸 이 고리를 돌리는 소프트웨어를 하네스(agent harness)라고 한다.
• 지금까지 실무 에이전트 방식은 코딩 에이전트를 빼면 대부분 개발자가 정한 흐름에 기대어 더 믿을 만하게 했다. 최근 몇 달 사이 모델이 좋아져, 하네스 방식이 아직 완전히 믿을 수는 없지만 쓸 만한 대안이 됐다.
• 기밀 일에는 상용 데스크톱 에이전트를 쓰지 않는다고 했다. 자료 보관 정책이 새 모델과 함께 바로 바뀔 수 있어서다. 자기 제품 소개가 섞여 있다(오픈소스 OpenCoworker).
• 대회에서 쓸 점: 순서가 정해진 조합 업무는 내가 단계를 정한다. 모델이 다음 행동을 고르게 둘 곳은 틀려도 피해가 작은 곳으로 좁힌다.
• 원문: "Instead, they have relied more on developer-specified workflows to deliver higher reliability." [편지 2026-06-12]

2026-06-26 Three Key Loops for Building Great Software

• 주소: https://www.deeplearning.ai/the-batch/three-key-loops-for-building-great-software/
• 처음 만드는 제품에 쓰는 고리 셋이다. 첫째, 에이전트 코딩 고리: 사양(평가 묶음은 있으면 함께)을 주면 코딩 에이전트가 코드를 쓰고, 시험하고, 사양에 맞을 때까지 되풀이한다. 몇 분마다 한 바퀴 돈다. 그의 에이전트는 딸의 타자 연습 앱을 만들며 약 1시간을 혼자 일했다.
• 둘째, 개발자 피드백 고리: 개발자가 결과를 보고 에이전트를 이끈다. 수십 분~몇 시간마다 돈다. 같은 문제가 되풀이되면 에이전트용 평가 묶음을 만든다.
• 셋째, 바깥 피드백 고리: 친구, 첫 시험 사용자, 실제 운영의 A/B 시험에서 반응을 받는다. 몇 시간~몇 주가 걸린다. 이 반응이 개발자의 구상을 바꾸고, 구상이 사양을, 사양이 코딩 에이전트를 움직인다.
• 그가 관여한 거의 모든 제품에서, 사람은 사용자와 제품이 쓰일 상황을 지금의 AI보다 훨씬 많이 안다. 그는 이를 "취향"이 아니라 "맥락(context) 우위"라고 불렀다. 사람이 아는 것을 AI가 모르는 동안은 사람이 고리 안에 있어야 한다(human-in-the-loop).
• 대회에서 쓸 점: 조합 사람들과 그 일의 사정은 인터뷰로 내가 안다. 그 앎을 사양과 평가 예시로 적어 에이전트에 넣는다.
• 원문: "So long as the human knows something the AI does not, human-in-the-loop is needed" [편지 2026-06-26]

2026-07-10 Make All Your Tokens (and Your Brainwork) Count

• 주소: https://www.deeplearning.ai/the-batch/make-all-your-tokens-and-your-brainwork-count/
• 에이전트 코딩 고리는 에이전트가 조건(예: 사양 충족)을 채울 때까지 일하게 하는 것이다. 사양, 평가, 시험 예시를 만드는 일은 가장 어려운 일 가운데 하나이고, 사람의 지식을 넣는 자리다.
• 그가 쓰는 원칙은 "AI의 토큰은 싸고, 사람의 토큰은 금이다"이다. 토큰(token)은 AI가 글을 읽고 쓰는 단위다. 사람의 토큰은 사람이 써 주는 지시와 피드백을 말한다.
• 큰 시스템은 구조를 미리 따져 정한다. 처음 만드는 시제품은 다르다. 에이전트가 20분이면 간단한 시제품을 만드니, 설계 사양에 사람 시간 1시간을 쓰기보다 10분 동안 엉성한 사양을 쓰고, 에이전트가 만든 것과 그 가정을 본 뒤 사양을 고친다. 이 단계에서는 코드를 통째로 버리고 다시 시작해도 된다.
• 정한 것은 SPEC.md 같은 파일에 적어 두게 한다. 에이전트가 사람이 한 말을 잊으면 같은 말을 다시 해야 한다. 마음에 안 드는 곳을 고칠 때는 사양과 시험 계획도 함께 고쳐, 그 문제가 다시 나오지 않는지 확인하게 한다.
• 대회에서 쓸 점: 첫 판의 사양을 오래 다듬지 않는다. 짧게 쓰고 돌려 본 뒤, 고친 내용을 사양 파일에 쌓는다.
• 원문: "I'd rather spend 10 minutes writing an inferior spec, see what the agent has built, examine its assumptions, and then refine the spec and repeat the process." [편지 2026-07-10]

2026-08-14 The AI Engineering Skills Map Part 1

• 주소: https://www.deeplearning.ai/the-batch/the-ai-engineering-skills-map/
• 채용 공고 1만 건 넘게 분석하고, AI 전문가와 채용 담당자 수십 명을 인터뷰하고, 설문을 모아 "AI 엔지니어링 역량 지도"를 만들었다. 큰 역량은 넷이다. AI 앱 만들고 운영하기, 소프트웨어 기초, 코딩 에이전트 쓰기, 만들 것을 함께 정하기.
• AI 앱과 일반 소프트웨어의 차이는 AI의 출력을 미리 알 수 없다는 점이다. 그래서 통계적 방법으로 재고, 이끌고, 관리해 더 예측할 수 있게 만든다. 그러려면 평가와 오류 분석 고리를 규율 있게 돌릴 줄 알아야 한다.
• 코딩 에이전트를 잘 쓰려면 맥락 관리, 계획과 실행에 각각 얼마나 쓸지 정하기, 확인 도구나 평가를 줘서 에이전트가 스스로 고리를 닫게 하기, 운영 데이터베이스를 망치지 않게 하기를 알아야 한다.
• 사양이 분명하면 코딩 에이전트가 빠르게 만든다. 그래서 엔지니어의 일은 사양에 무엇을 넣을지 정하는 쪽으로 옮겨 간다. 언제 빨리 시제품을 만들어 사용자에게 보이고, 언제 천천히 공들일지도 알아야 한다.
• 대회에서 쓸 점: 에이전트의 출력은 미리 알 수 없다고 보고, 제출 전에 예시로 재는 시간을 따로 잡는다.
• 원문: "The key difference between AI and non-AI applications is that the former has unpredictable outputs." [편지 2026-08-14]

2026-08-21 The AI Engineering Skills Map Part 2: AI Applications

• 주소: https://www.deeplearning.ai/the-batch/he-ai-engineering-skills-map-in-detail-building-and-deploying-ai-applications/
• AI 출력은 미리 알 수 없어서, 만들고, 보고, 다음에 할 일을 정하는 일을 되풀이한다. 다음 할 일을 잘 정하면 믿기 어려운 AI 부품으로 믿을 만한 시스템을 만든다.
• 자료로 모델 받치기: 문서(글, PDF, HTML, 그림)를 모델이 읽을 꼴로 바꾸고, 자료를 깨끗하고 새것으로 유지하는 흐름을 만든다. 지시문에 넣을 것과 도구로 그때그때 찾게 할 것을 나눈다.
• 에이전트 만들기: 정해진 순서로 모델을 부르는 흐름부터, 모델이 다음 단계를 스스로 고르는 하네스까지 있다. 무엇을 잇고 무엇을 나란히 돌릴지, 언제 코드를 쓰고 언제 모델을 쓸지 정하고, 실패할 때 대신할 길을 둔다.
• 평가로 이끄는 개발: 잘 만드는 사람을 가르는 첫째 특성이라고 했다. 코드로 잴지, AI 채점을 쓸지, 사람이 볼지 고르고, 평가 자체도 평가해 고친다.
• 대회에서 쓸 점: 단계마다 코드로 할지 모델로 할지 정한다. 계산과 형식 검사는 코드에 맡긴다.
• 원문: "Being able to skillfully decide what to do next allows you to create reliable software systems based on unreliable AI components." [편지 2026-08-21]

2026-08-28 The AI Engineering Skills Map Part 3: Fundamentals

• 주소: https://www.deeplearning.ai/the-batch/the-ai-engineering-skills-map-in-detail-software-engineering-fundamentals/
• 코딩 에이전트가 코드를 다 써도 소프트웨어 기초를 알아야 한다. 그래야 응답 시간, 가용성, 일관성, 믿음성, 유지 보수, 단순함, 비용 사이의 맞바꿈(tradeoff)을 알고 에이전트를 이끈다. 기초 없이 바이브 코딩(vibe coding, 코드를 거의 보지 않고 AI에게 짜게 하는 것)을 하면 에이전트가 나쁜 맞바꿈을 하기 쉽다.
• 기초는 다섯이다. 전체 스택 만들기, 자료 관리, 시스템 구조 설계, 보안과 믿음성, 운영과 규모 키우기.
• 자료는 소프트웨어의 바탕이고 바꾸기 어렵다. AI는 자료에서 맥락을 얻으므로, 자료 구조를 잘못 고르면 AI는 자기가 무엇을 모르는지도 모른다. 그래서 맥락을 아는 사람이 바로잡아야 한다.
• 맞는 구조는 프로젝트 단계마다 바뀐다. 빠른 시제품의 단순한 구조가 첫 운영판에는 맞지 않을 수 있다. 시험 전략, 실패 대비(예: API 호출 한도), 보안을 일찍 챙기는 흐름도 다뤘다.
• 대회에서 쓸 점: 에이전트가 읽을 자료의 꼴(표의 칸, 이름, 단위)을 내가 먼저 정한다.
• 원문: "Your AI systems will get their own input context from your data source, so if data architecture is chosen poorly, the AI doesn't know what it doesn't know." [편지 2026-08-28]

2026-09-04 The AI Engineering Skills Map Part 4: Coding Agents

• 주소: https://www.deeplearning.ai/the-batch/the-ai-engineering-skills-map-in-detail-using-coding-agents/
• 코딩 에이전트로 만드는 흐름은 셋이다. 계획(아이디어 내기, 사양 쓰기, 실행 계획), 실행(만들고, 시험하고, 확인하기), 배포와 감시. 이제 코드보다 무엇을 만들지, 구조, 사양, 출력 확인에 힘을 쓴다.
• 단계마다 들이는 품은 프로젝트마다 다르다. 처음부터 새로 만드는 시제품은 빨리 쓴 지시문 하나가 사양을 대신할 수 있다. 사용자가 많은 기존 프로젝트는 사양을 훨씬 공들여 쓰고 확인한다.
• 역량은 다섯이다. 흐름 이끌기, 자율 수준 정하기, 결과 검토하기, 에이전트와 그 환경 맞추기(AGENTS.md 같은 상시 맥락 파일, 스킬, 플러그인, MCP 서버), 코딩 에이전트의 작동 원리 알기. MCP 서버는 도구와 자료를 AI에 잇는 방식을 표준으로 맞춘 것이다. 권한을 정하고 행동마다 확인 단계를 둬서, 개발은 빨리 하되 유출과 자료 손실 위험을 줄인다.
• 몇 시간씩 혼자 돌며 토큰을 수백만~수천만 개 쓰게 하는 것이 쓸모 있을 때도 있다. 그래도 아주 긴 작업의 쓸모는 비용에 비해 실제보다 부풀려졌다고 했다. 잘 쓰는 방식은 되풀이가 많고, 숙련된 판단으로 끼어들 때 결과가 훨씬 낫다.
• 대회에서 쓸 점: 코딩 에이전트에게 길게 맡겨 두지 않는다. 짧게 돌리고, 결과를 확인하고, 다시 지시한다.
• 원문: "Instead, most effective coding agent use is a complex, highly iterative process, and being able to intervene with high-skill judgement gives much better results." [편지 2026-09-04]

2026-09-11 The AI Engineering Skills Map Part 5: Shaping the Build

• 주소: https://www.deeplearning.ai/the-batch/the-ai-engineering-skills-map-in-detail-shaping-the-build/
• AI 엔지니어링을 잘하는 사람은 남이 쓴 사양대로 만들기만 하지 않는다. 무엇을 만들지 함께 정한다. 기획자, 디자이너, 개발자 역할의 경계가 흐려지고 있다.
• 역량은 넷이다. 만들기 고리 이끌기, 제품 결정 내리기, 소통하고 이끌기, 스스로 나서서 끝까지 책임지기.
• 만들기 고리: 코드를 조금 쓰고, 피드백을 받고, 다음 할 일을 정한다. 빠른 시제품, 사용자에게 보일 최소 기능 제품(MVP), 기능 추가 가운데 고르고, 작게 자주 내보낸다.
• 제품 결정: 사양에 없는 결정도 내리고, 사양이 없으면 만든다. 사용자 2~3명과의 짧은 대화부터 수백 명 설문, 큰 A/B 시험까지 써서 사용자 이해를 키운다.
• 대회에서 쓸 점: 인물이 정해 주지 않은 부분은 인물에게 다시 묻거나, 내가 정하고 그 까닭을 사양에 적는다.
• 원문: "If you are asked to build without a spec, you know how to develop one." [편지 2026-09-11]

2026-09-25 What Stage Is Your Project? Takeaways For AI Engineering

• 주소: https://www.deeplearning.ai/the-batch/what-stage-is-your-project-takeaways-for-ai-engineering/
• 역량 지도 다섯 편에 되풀이된 주제를 묶었다. 평가, 소프트웨어 구조, 제품 피드백의 알맞은 방법은 프로젝트 단계에 따라 다르다.
• 평가 예(자동 고객 응대 메일): 초기에는 예시 십여 개를 직접 보고 말이 되는지 본다. 다음 단계는 시험 예시 수백 개와 글로 쓴 채점표다. 다 자란 제품은 수만 개 이상과 더 자세한 채점표로, 메일이 낳은 결과(고객이 다시 오는지)까지 잰다.
• 초기에 너무 공들이지도, 다 자란 제품을 너무 가볍게 만들지도 말라고 했다. 피드백도 2~3명을 따로 불러 묻기부터 큰 사용자 연구, A/B 시험, 사용 자료 분석까지 있다.
• 큰 회사에서 스타트업으로 온 엔지니어가 너무 느리고 엄격한 방법을 요구하는 것을 봤다. 스타트업에서 큰 회사로 간 엔지니어는 빠르지만 덜 정확한 평가에 머물러 성능이 더 오르지 않을 수 있다. 모든 일에 같은 시험을 요구하는 회사 규칙은 오히려 해가 될 수 있다.
• 대회에서 쓸 점: 대회 에이전트는 초기 프로젝트에 가깝다. 예시 십여 개를 직접 보는 데서 시작하고, 시간이 남으면 채점표를 쓴다.
• 원문: "In an early-stage project, you might manually examine a dozen examples and check how sensible they are." [편지 2026-09-25]

날짜는 유튜브에 올라온 날이다. 행사 날짜는 주소 줄에 적었다. 유튜브 자동 자막이라 원문에 오타와 말버릇(uh, you know)이 섞여 있다. 앤드류 응이 말한 문단만 옮겼고, 화자 구분은 자료를 모을 때 사람이 판단한 것이다.

2025-05-28 LangChain Interrupt 2025

• 주소: https://www.youtube.com/watch?v=4pYzYmSdSH4 (26분 58초, Harrison Chase와 대담, 행사 2025-05)
• "에이전트냐 아니냐" 대신 자율성의 정도로 보자는 1년 반 전의 생각을 다시 말했다. 그 뒤 마케터들이 "에이전틱"이라는 말을 여기저기 붙였다고 했다.
• 그의 팀은 가장 어려운 문제에 복잡한 흐름(LangGraph)을 쓴다. 그래도 사업 기회의 다수는 거의 일직선이거나 가끔 곁가지가 있는 흐름이다. 예: 웹 양식을 보고, 웹을 검색하고, 데이터베이스에서 규정 위반을 확인하고, 다른 양식에 옮겨 적는 일.
• 아직 드문 능력: 사람이 하는 일을 보고 얼마나 잘게 쪼갤지 정하기, 첫 시제품이 부족할 때 어느 단계를 고칠지 정하기, 평가 넣기. 경험이 적은 팀은 한 부품을 고치느라 몇 달을 쓴다. 경험 많은 팀은 안 될 것 같으면 다른 길로 돌아간다.
• 평가는 20분 안에 엉성하게 만든다. 같은 문제가 되풀이되면 입력 예시 5개와 간단한 AI 채점으로 그 하나만 확인하는 평가를 짠다. 사람 눈 검사를 대신하지 않고 곁에 둔다. 그다음 평가를 조금씩 고친다.
• 시간의 많은 부분이 자료를 잇는 작업에 든다. MCP는 도구와 자료를 잇는 방식을 표준으로 맞추는 첫걸음이지만, 작동하지 않는 MCP 서버가 많고 인증이 서툴다고 했다. 다른 팀의 에이전트끼리 잇는 일은 아직 이르다고 봤다.
• 대회에서 쓸 점: 조합 업무를 일직선 단계로 먼저 쪼갠다. 같은 실수가 되풀이되면 그 실수만 잡는 작은 평가를 바로 만든다.
• 원문: "I think of evals as something I'm going to throw together really quickly, you know, in 20 minutes" [강연 2025-05-28]

2026-01-31 Imagination in Action

• 주소: https://www.youtube.com/watch?v=8Q9sJYk41sA (24분 52초, Andrew McAfee와 대담, 대화 내용으로 보아 2026-01 다보스 현장)
• 직업을 작업 단위로 쪼개 보면, 많은 직업에서 AI가 할 수 있는 몫은 30~40%쯤이고 나머지 60~70%는 사람이 한다. AI를 쓰는 사람이 쓰지 않는 사람을 대신한다. 번역가, 성우, 콜센터처럼 거의 100%를 AI가 할 수 있는 일은 사라진다고 했다.
• 그의 팀에서 엔지니어 대 기획자 비율이 8:1에서 4:1, 2:1로 바뀌었고, 1:1을 제안하는 데까지 왔다. AI가 만드는 일은 크게 빠르게 했지만, 무엇을 만들지 정하는 일은 그만큼 빠르게 하지 못했다.
• 바이브 코딩 시스템은 지금 기술로는 규모를 못 버틴다. 운영에 올리려면 깊은 소프트웨어 지식이 필요하다. 엔지니어가 아닌 사람도 AI와 함께 코딩하면 더 많이 해낸다. 예: 채용 담당자가 이력서를 거르는 코드를 짜고, 재무 책임자가 자기 업무 흐름에 맞는 소프트웨어를 짠다.
• 아래에서 올라온 작은 실험만으로는 효율이 조금 오를 뿐이다. AI 전환은 기술이 이끄는 사업 전환이라고 했다. 대출 예처럼 흐름 전체를 다시 짜야 한다. 모든 은행이나 병원에 같은 처방을 주는 보고서는 거의 쓸모가 없다고 했다. 속을 들여다보면 곳마다 다르다.
• 사람을 함께 데려가는 변화 관리가 CEO들과 두 번째로 많이 나누는 주제라고 했다.
• 대회에서 쓸 점: 마을 조합에 일반적인 AI 처방을 가져가지 않는다. 그 조합의 사정을 인터뷰로 자세히 알아내고 흐름을 짠다.
• 원문: "every bank every hospital every manufacturing plant, every transportation company, uh they're all so different once you look beneath the surface" [강연 2026-01-31]

2026-03-01 This Is The World

• 주소: https://www.youtube.com/watch?v=4vzmTKUFtxg (54분 6초, Matt Kawecki의 인터뷰 편집본, 녹화는 2026-01 무렵으로 보이나 확정 아님)
• 그의 팀은 코딩 말고도 서류 검토, 관세 규정 확인, 법률 문서 읽기, 의료 보조, 고객 응대에 에이전트 방식을 쓴다. 사람이 그 일을 할 때 거치는 생각의 과정을 에이전트 흐름으로 옮긴다.
• 똑똑한 모델이 잘 짠 흐름을 이길 수 있는가: 이론으로는 그렇지만 실제로는 훨씬 어렵다고 했다. 도구만 주고 맡기는 방식은 많은 업무에서 운영할 만큼 믿을 수 없다. 그래서 팀들은 흐름과 꼭 필요한 단계를 정해 하나씩 구현하고, 1만 번 돌려도 거의 매번 맞게 만든다.
• 모델이 좋아져, 6개월~1년 반 전에 만든 시스템에서 자세한 지시와 안전 장치를 걷어내는 일이 잦다. 조사 에이전트처럼 행동을 하지 않아 틀려도 피해가 작은 일이 그렇다. 위험이 큰 기업 업무에서는, AI를 그냥 풀어 두었을 때의 믿음 차이가 줄고는 있지만 생각보다 아직 크다고 봤다.
• 하네스의 세부(지시문 구조, 주는 도구)가 결과를 크게 바꾼다. 도구를 너무 많이 주면 맥락을 많이 차지하고 엉뚱한 도구를 부르기 쉽다. 도구 목록이 긴 MCP 서버도 그렇다.
• 정답이 있는 일을 재는 벤치마크는 잘 만든다. 보고서처럼 좋고 나쁨에 단계가 있는 일을 재는 벤치마크는 만들기 어렵다. 영상의 많은 부분은 AGI(사람이 하는 어떤 지적 일도 하는 AI)가 과장됐다는 이야기다.
• 대회에서 쓸 점: 에이전트에 줄 도구는 꼭 필요한 것만 고른다. 되돌리기 어려운 행동은 정해진 단계로 묶는다.
• 원문: "Having said that, for many workflows, it's just not reliable enough to be production ready." [강연 2026-03-01]

2026-05-20 AI Dev 26

• 주소: https://www.youtube.com/watch?v=g8um2AEf5ZA (19분 21초, AI Dev 26 x SF 기조연설, 행사 2026-04-28~29)
• 소프트웨어를 여러 부품을 엮는 일로 본다. AI 부품(지시하는 모델, 검색 증강 생성, 에이전트 방식)과 일반 부품(화면 구성 요소, 데이터베이스, 로그인 관리)이 빠르게 늘고, 코딩 에이전트가 이를 빨리 엮는다.
• 그의 코딩은 거의 100%를 AI가 쓴다. 80%만 AI가 쓰면 사람이 맡은 나머지에 걸리는 시간이 훨씬 길다. 코드 검토도 같아서, 사람이 모든 줄을 검토하면 사람이 병목이 된다. 우주선 코드처럼 위험한 곳은 손으로 써도 된다고 했다.
• 만드는 일이 10~100배 빨라지자 제품 관리, 디자인, 법무, 마케팅, 영업이 병목이 됐다. 그래서 엔지니어 일과 기획 일을 함께 하는 작은 팀이 빠르다. 그는 법무 일도 AI로 첫 초안을 쓰고 실제 변호사에게 확인받는다.
• 코딩 에이전트는 학습 시점 뒤에 나온 API를 모르거나 낡은 API를 쓰는 일이 잦다. 최신 문서를 맥락으로 넣어 주면 새 API로 짠다. 자기 제품 소개가 섞여 있다(Context Hub, Codream).
• 대회에서 쓸 점: 에이전트가 모를 수 있는 조합만의 규칙과 최신 정보는 문서로 만들어 맥락에 넣는다.
• 원문: "if I got to review the code, then I become the bottleneck" [강연 2026-05-20]

2026-06-17 LangChain Interrupt 26

• 주소: https://www.youtube.com/watch?v=OaRhpwz_TGM (31분 39초, Harrison Chase와 대담, 행사 2026-05-13~14)
• 1년 전에 쓴 제품 관리 병목이 그 뒤 더 심해졌다고 했다. 만드는 일이 10~100배 빨라지자 마케팅, 법무, 디자인도 병목이 됐다. 그래서 그는 1~10명의 작은 팀을 꾸린다. 맥락을 많이 알고 권한이 큰 다재다능한 사람들이 넓은 테두리 안에서 빠르게 만들고 내보낸다.
• 기업은 아래에서 올라온 실험에 투자했지만 대개 작은 효율에 그쳤다. 대출 예(1시간 심사를 10분 대출 상품으로)처럼 권한이 넓은 사람이 흐름 전체를 다시 짜야 한다. 비용 절감보다 성장을 노리라고 권한다. 아낄 수 있는 돈에는 한계가 있지만 성장은 거의 그렇지 않다고 했다.
• 생성형 AI 흐름을 만드는 일은 어렵다. 사업을 이해하고, 고객을 상대하고, 관찰 장치(observability)와 평가를 넣고, 기술적으로 안 되는 요청은 거절하고, 어떤 흐름을 자동화할지 관계자와 정하고, 변화 관리를 돕는다.
• 기업 자료는 에이전트가 쓸 준비가 안 됐다. 흩어져 있고, 형식이 제각각이고, 일부는 개인 노트북에 있고, 권한이 사람 기준으로 짜여 있다. 그는 시제품 때 형식을 나중에 정해도 되는 NoSQL 데이터베이스로 빨리 고쳐 가고, 아주 큰 운영에는 관계형 데이터베이스를 쓴다.
• 자기 제품 소개가 섞여 있다(Context Hub, co-dream.ai).
• 대회에서 쓸 점: 조합 자료가 흩어져 있고 형식이 제각각이라고 보고, 에이전트가 읽기 전에 모으고 맞추는 단계를 둔다. 누가 어떤 자료를 볼 수 있는지도 정한다.
• 원문: "data's all over the place, no consistent schema, some of this sitting on someone's laptop, the permissions were designed for humans, not for agents" [강연 2026-06-17]

2026-07-08 Oracle Developers

• 주소: https://www.youtube.com/watch?v=YJ3XMwafk0U (2분 30초, Oracle Developers 짧은 인터뷰, 녹화일과 진행자 이름 미확인)
• 지금 처음 시작한다면 코딩 에이전트 쓰는 법, 지금 있는 부품들, 약간의 제품 감각을 배우라고 했다. 무엇을 만들지 생각이 있고 만들 기술도 있는 혼자 개발자가 예전보다 훨씬 많이 해낸다.
• 에이전트에게 기억은 필요하다. 그 기억을 어떻게 짤지는 아직 합의가 없다.
• 과장된 것: 에이전트가 알아서 다 하고 사람의 개입과 생각은 별로 필요 없다는 생각.
• 잘 되는 것: 크고 작은 업무 흐름을 신중하게 골라 에이전트로 구현하기. 덜 알려진 것: 오류 분석을 규율 있게 하는 팀이 훨씬 빨리 나아간다. 흐름을 만들고, 아직 안 되는 곳을 보고, 생긴 문제를 고친다.
• 대회에서 쓸 점: 첫 판을 돌린 뒤 안 되는 곳을 적고 하나씩 고치는 시간을 따로 남긴다.
• 원문: "teams that can drive a disciplined error analysis process make much faster progress" [강연 2026-07-08]

_research/B_letters/00_정리.md의 "바뀐 곳" 표를 바탕으로 하고, _research/C_talks/00_정리.md 3절의 강연 내용을 보탰다. 2절에 없는 편지도 날짜를 적었다. 그 원문도 _research/B_letters/letters에 있다.