앤드류 응 교수의 LLM 앱 개발 강의 정리: 프롬프트를 넘어 추론 엔진·과업 분석·평가·에이전트까지 (NeurIPS 2023)

출처 안내 — 이 글은 X(옛 트위터) 사용자 @callanxai의 2026년 9월 24일 게시물에 첨부된 1시간 38분짜리 강의 영상을 처음부터 끝까지 보고(영어 자동 생성 자막 전문 대조) 앤드류 응(Andrew Ng) 교수의 강의 내용을 한국어로 정리한 것입니다. 강의 중 "뉴올리언스행 비행기", "NeurIPS가 끝나면 집에 가서 뭔가 만들어 보라"는 발언과 공식 자료를 대조하면, 이 영상은 2023년 12월 11일 NeurIPS 2023(뉴올리언스)에서 앤드류 응 교수가 OpenAI의 이사 풀포드(Isa Fulford)와 함께 진행한 튜토리얼 "Application Development using Large Language Models"입니다. 게시물 문구가 말하는 "프롬프팅은 6개월 안에 사라진다"는 발언은 영상에 나오지 않으며, 화면 하단의 'Stanford' 표기도 재업로드 편집으로 보입니다. 아래는 응 교수가 강단에서 실제로 말한 내용을 중심으로 정리했고, 원문 링크는 글 끝의 '출처'에 모아 두었습니다. 강의 내용의 저작권은 강연자와 NeurIPS에 있으며, 해석과 정리는 필자의 것입니다.

한 줄 요약

응 교수가 강의 내내 반복한 메시지는 하나입니다. "LLM은 지도학습처럼 범용 기술이다. 프롬프트 한 줄로 몇 시간 만에 프로토타입을 만들고, 도구와 검색을 붙이고, 실수 사례로 평가셋을 키우면서 애플리케이션으로 성장시켜라." 강의는 LLM의 작동 원리 → 네 가지 기본 연산 → 추론 엔진으로서의 LLM과 파인튜닝 → 과업 단위로 자동화 기회 찾기 → 테스트셋 없이 시작하는 개발·평가 워크플로 → 오픈소스와 클로즈드 모델 선택 → 에이전트와 페어 프로그래밍 순서로 흐릅니다. 2023년 말의 강의지만 원칙은 2026년에 봐도 그대로 통합니다.

1. LLM 기초: "학습시키라는 게 아니라, 판단할 수 있을 만큼만 이해하자"

응 교수는 "LLM을 직접 학습시키라는 게 아니라, 앱을 만들 때 올바른 결정을 내릴 수 있을 만큼의 작동 모델(mental model)을 갖자"며 기초부터 짚습니다. 먼저 LLM은 지도학습·강화학습처럼 범용 기술(general purpose technology)이라 문서 Q&A, 고객 서비스 봇, 메시지 요약·라우팅, 법률·의료 문서 처리, 교정, 새로운 게임과 온라인 동반자까지 수많은 응용에 쓰인다는 점을 강조합니다. AI 스택에서 관심은 늘 도구·인프라 계층(OpenAI, Google, AWS, Azure)에 쏠리지만, 그 계층이 성공하려면 그 위의 애플리케이션 계층이 더 큰 매출을 내야 한다는 것이 오늘 강의가 응용에 초점을 맞추는 이유입니다.

• 베이스 LLM: 인터넷에서 긁어 온 수천억~수조 단어로 "다음 단어 맞히기"를 지도학습한 모델. "프랑스의 수도는?"이라고 물으면 답 대신 "독일의 수도는?" 같은 퀴즈 문장을 이어 붙이기도 합니다.
• 지시 미세조정(instruction fine-tuning): 프롬프트와 사람이 쓴 모범 답안(거절 사례 포함) 데이터로 몇 주 더 학습시키면 "프랑스의 수도는 파리"처럼 지시를 따르게 됩니다.
• RLHF: 답변 후보에 사람이 점수(실제로는 쌍 비교 순위)를 매기고, 그 판단을 흉내 내는 보상 모델을 학습한 뒤, 보상이 높은 답을 내도록 LLM을 조정합니다. 목표는 정직하고(honest) 도움이 되며(helpful) 해롭지 않은(harmless) 모델입니다.
• 토큰: 모델은 단어가 아니라 토큰을 예측합니다. 'Andrew'는 토큰 하나, 'tonkotsu'는 토큰 넷. 토큰 1개 ≈ 0.75단어이므로 토큰 수는 단어 수보다 약 33% 많습니다.

비용에 관한 봉투 뒷면 계산도 인상적입니다. 분당 250단어 읽기 속도로 한 사람을 1시간 동안 붙잡아 둘 텍스트를 생성하는 비용은 약 7센트. 비싼 모델과 싼 모델은 100배까지 차이 나지만 "많은 팀이 너무 일찍 비용 최적화를 한다"는 게 그의 지적입니다. OpenAI·Google PaLM API 호출 몇 줄과 함께, M2 노트북에서 Ollama로 Llama 2를 돌리는 시연을 보여 주며 "와이파이가 끊긴 비행기 안에서도 LLM을 쓴다"고 덧붙입니다.

2. 네 가지 기본 연산: 요약·추론·변환·확장

예전엔 여섯 달 걸리던 텍스트 처리 앱을 이제 "몇십 분, 길어야 몇 시간"에 만들 수 있다며, 웹 UI에 프롬프트를 치는 소비자 사용과 달리 API로 소프트웨어를 만들 때 반복해서 등장하는 패턴 네 가지를 코드 시연과 함께 보여 줍니다.

• 요약(summarizing): 제품 리뷰를 짧게 줄이기. "배송에 초점을 맞춰라"처럼 프롬프트 한 줄로 관점을 바꿀 수 있습니다.
• 추론(inferring): 감성 분류처럼 예전엔 데이터 수집→지도학습→배포→디버깅이 필요했던 일을 "이 리뷰의 감성은?" 한 줄로 끝냅니다. 후속 소프트웨어가 처리하기 쉽도록 "positive 또는 negative 한 단어로만 답하라"고 출력 형식을 못 박는 것이 핵심 디자인 패턴입니다.
• 변환(transforming): 번역·포맷 변환. 고자원 언어는 전용 번역 사이트보다 낫다는 평가. 팀원들의 공통 언어가 영어뿐이라 "영어 해적 말투"로 번역 테스트를 한다는 농담이 나옵니다.
• 확장(expanding): 짧은 지시에서 긴 고객 응대 이메일 만들기. "스팸에 쓰지 말라"는 당부가 붙습니다.

이 위에 업계에서 가장 흔히 만드는 두 가지가 RAG(문서 검색 후 질의응답)와 고객 서비스 챗봇이라고 정리합니다.

3. LLM은 지식 저장소가 아니라 '추론 엔진'이다 — 그리고 파인튜닝의 자리

강의 중반, 응 교수는 LLM을 바라보는 관점 전환을 제안합니다. 사전학습으로 상식은 많이 알지만(중력 상수 같은 것은 잘 안다) 롱테일 사실은 환각하기 쉬우니, ChatGPT에 질문하듯 지식 저장소로만 쓰지 말고 관련 맥락을 프롬프트에 넣어 주고 그 정보를 처리하게 하는 추론 엔진(reasoning engine)으로 쓰라는 것입니다. 정보를 처리하면서 검색·날씨·길찾기 같은 도구를 스스로 호출하게 할 수도 있고, 이 관점이 에이전트 같은 훨씬 큰 응용의 문을 연다고 말합니다.

파인튜닝은 사전학습 모델을 자기 데이터로 조금 더 학습시키는 기법입니다. 프롬프트로 지정하기 어려운 어조·스타일(예: 고객 통화 요약을 더 기술적으로)을 맞추는 데 유용하고, "몇백 문서면 생각보다 적은 데이터로도 동작한다"고 합니다. 팀원 Tommy Nelson이 응 교수의 강의 녹취로 파인튜닝한 'DLS-Andrew' 모델이 노트북에서 "그래서(So)"로 문장을 시작하는 습관까지 흉내 내는 시연을 보여 주며 "이 모델에 일자리를 뺏기면 알려 드리겠다"고 웃습니다. 그러나 원칙은 분명합니다. "파인튜닝은 프롬프트 엔지니어링이나 RAG보다 10~100배 더 많은 일이다. 먼저 프롬프트를, 다음에 RAG를 시도하고, 정말 필요할 때만 파인튜닝하라. 필요 이상으로 파인튜닝을 쓰는 팀이 많다."

4. 실전 팁 ①: 직무가 아니라 '과업'을 분석하라

"AI가 직업을 자동화한다"보다 유용한 틀은 "AI는 과업(task)을 자동화한다"입니다. 대부분의 직무는 여러 과업의 묶음이므로, 응 교수의 팀이 직원 1만~10만 명 규모 기업에서 "매번 좋은 아이디어가 나왔다"는 레시피는 이렇습니다.

1. 각 역할이 실제로 하는 과업을 체계적으로 나열한다. 미국 정부 지원 O*NET 같은 사이트가 출발점이지만 "70%쯤만 맞으니" 현장에서 사람들이 실제로 하는 일을 직접 본다.
2. 과업마다 기술적 실현 가능성과 사업 가치를 기준으로 자동화·증강 잠재력을 평가한다.
3. 잠재력이 높은 과업을 직접 만들지(build) 살지(buy) 결정한다.

포인트는 "머릿속 첫 그림"이 최선의 기회가 아닌 경우가 많다는 것입니다. 프로그래머는 코드만 쓰지 않고 문서도 많이 쓰며, 방사선과 의사는 X선 판독 외에 환자 문진도 하고, 변호사는 법정 변론보다 문서 작성·검토에 시간을 더 씁니다. 같은 분석을 직원이 아니라 고객의 과업(웹사이트 빌더라면 "웹페이지를 만드는 일")에 적용해도 아이디어가 나옵니다. 그리고 이 분석은 비용 절감에서 끝나지 않습니다. 외과의사의 수술 전 조사 시간이 줄어드는 것은 비용 절감이지만, 마케터의 웹 카피 작성이 10배 싸지면 절감액을 챙기는 대신 카피를 10배 더 써서 A/B 테스트를 돌리고 캠페인을 분석하는 새 워크플로가 생기고, 그것이 성장으로 이어진다는 것입니다. "내 일은 자동화하기 참 어렵더라"는 자조도 곁들입니다.

728x90

5. 실전 팁 ②: 테스트셋 없이 시작하는 개발 워크플로와 평가

지도학습 시절엔 데이터 라벨링→학습→클라우드 배포까지 "대기업 기준으로 6~12개월"이 걸렸지만, LLM 기반 개발은 프롬프트 작성 몇 분, 클라우드 API로 프로토타입까지 몇 시간~며칠입니다. 그래서 나온 디자인 패턴이 "프로토타입을 10개 던져 보고 뭐가 붙는지 보라"입니다. 응 교수 본인도 커피숍에서 15~20분 만에 여러 API에 같은 프롬프트를 보내는 Streamlit 앱을 만들었고, 그 코드 절반은 GPT-4가 썼다고 합니다. 단, 피해 위험이 있는 애플리케이션은 예외로, 테스트셋을 모으고 감사한 뒤에만 배포하라는 단서를 두 번 강조합니다.

평가에 대한 이야기는 그 스스로 "전통 ML 관점에서는 이단(sacrilege)처럼 들릴 것"이라고 인정합니다.

• 프롬프트는 5분이면 쓰는데 테스트셋 100개를 모으는 건 고통스럽다. 그래서 테스트셋 없이 시작해 배포하고 모니터링한다.
• 실수한 사례를 발견할 때마다 손으로 고른 평가셋에 넣는다(IID가 아니어도 좋다). RAG는 조각 크기·검색 개수·프롬프트 등 하이퍼파라미터가 많으니, 바꿀 때마다 이 작은 셋을 눈으로 확인한다.
• 평가셋이 10~20개를 넘어 매번 읽기 귀찮아지면 오류 지표를 만든다. 정답이 명확한 과업은 정확도로, 정답이 여럿인 과업은 다른 LLM을 채점자로 쓴다(전문가 요약과 비교해 A~E 등급 등). GPT-4는 이 일을 꽤 잘 하지만, 1,000개 예시 × 100개 설정을 돌리면 API 요금이 훌쩍 오르니 주의.
• 정말 마지막 1%가 중요한 앱에서만 무작위 표본의 정식 테스트셋을 모은다. 응 교수의 팀도 수천 개 예시로 0.5% 개선을 쥐어짜는 앱이 있지만 "일부 앱에서만" 그렇게 한다.

RAG 디버깅에는 Jerry Liu(LlamaIndex)·Anupam Datta의 프레임을 추천합니다. 답변 관련성(answer relevance), 컨텍스트 관련성(context relevance), 근거성(groundedness) 세 점수를 LLM으로 매기면 "검색이 틀렸는지, 생성이 틀렸는지"가 갈라져 디버깅 가능성이 올라갑니다.

6. 오픈소스 vs 클로즈드: "클로즈드로 시작해서 얼마나 가는지 본다"

응 교수의 실제 습관은 클라우드 호스팅 클로즈드 모델로 프로토타입을 만들고, "이건 시간 낭비였네" 싶으면 프로젝트를 접고, 잘 되면 그대로 두는 것입니다. 오픈소스로 옮기는 경우는 세 가지입니다. 온프렘·PC·엣지 등 실행 환경 통제, 안전 튜닝 정도의 통제(클로즈드 모델은 "모든 차를 시속 35마일로 제한하면 사고는 줄겠지만 나는 65마일로 달리고 싶다"는 비유처럼 필요 이상 보수적일 때가 있다. 단, 무검열 모델은 책임 있게 쓰라는 당부), 그리고 데이터 프라이버시. 전자건강기록(EHR)을 클라우드 API로 보낼 수 없어 로컬 모델로 처리했다는 경험을 들면서도, 70B급 대형 오픈소스 모델의 배포 인프라는 "아직 성숙 중"이라며 청중 속 하이퍼스케일러와 스타트업에게 더 나은 인프라를 만들어 달라고 주문합니다.

7. 에이전트는 '와일드 웨스트', 그리고 페어 프로그래머로서의 LLM

응 교수는 계획을 세우고 일련의 행동을 수행하는 자율 에이전트를 "LLM 앱 개발의 와일드 웨스트"라고 부릅니다. 두 달 전까지는 "흥미롭지만 아무것도 동작하게 못 하겠다"고 말했는데, 최근 한두 달 사이 상용 배포가 늘어 "이제 막 동작하기 시작하는 지점"이라는 것입니다. 동시에 "디버깅이 정말 어렵다"는 문제도 남아 있다고 솔직하게 말합니다.

마무리 당부는 셋입니다. 첫째, LLM을 브레인스토밍 파트너이자 생산성 도구로 하루에도 여러 번 쓰라(기밀 작업은 로컬 모델로). 둘째, 개발자라면 LLM을 페어 프로그래머로 쓰라. 에러 메시지를 붙여 넣어 설명을 듣고, Streamlit 문법을 찾기 귀찮으면 스니펫을 생성시키고, 안 되면 디버깅을 시키는 식으로 "1년 전과 완전히 다른 방식으로 코딩하는" 개발자가 늘고 있으며, 이는 Copilot식 템플릿 생성보다 훨씬 넓은 실천이라고 말합니다. 셋째, 지금은 AI 애플리케이션 개발의 골든 에이지다. 유명 기업·대학 소속이 아닌 사람들이 Discord에서 캐릭터 에이전트들이 마을을 돌아다니며 대화하는 것 같은 "용도는 잘 모르겠지만 정말 멋진" 것들을 만들고 있고, "첫 프로젝트가 실패해도 남에게 해가 없었다면 괜찮다. 배워서 다음 프로젝트를 만들라"는 말로 강의를 맺습니다.

8. 함께 진행한 이사 풀포드(OpenAI) 파트 요약

강의 중간 약 40분은 응 교수가 소개한 OpenAI의 이사 풀포드가 프롬프팅과 도구 활용을 맡았습니다. 응 교수의 강의를 이해하는 데 필요한 범위에서만 짧게 정리합니다.

• 채팅 포맷과 한계: 입력은 system·user·assistant·tool 역할을 가진 메시지 목록이며, system 메시지는 "조수의 귀에 속삭이는 고수준 지시"입니다. 현재 모델의 한계는 환각, 제한된 컨텍스트, 기억 없음, 지식 컷오프입니다.
• 세 가지 프롬프팅 전략: ① 명확하고 구체적인 지시(맥락·참고 텍스트·구분자·출력 형식·필요할 때만 예시), ② 모델에게 생각할 시간 주기(단계 명시, 채점 전에 직접 풀게 하기, 내부 독백 숨기기, 자기 검토, 복잡한 과업 쪼개기), ③ 외부 도구 사용(도구가 더 잘하는 일은 도구에).
• 도구: 임베딩 검색(RAG), 코드 실행(샌드박스 필수), 함수 호출. OpenAI Assistants API로 만든 "NeurIPS 2023 Helper" 시연에서 모델이 검색·병렬 함수 호출을 스스로 고르지만, 점심값 나누기 계산에서 본인을 빼고 8로 나누는 실수를 해 웃음을 삽니다.
• 안전: 모더레이션 API로 입력·출력 검사, 구분자와 분류 프롬프트로 프롬프트 인젝션 대응. "보안은 풀린 문제가 아니다."
• 미래: 추론 능력, 멀티모달, 도구 사용, 개인화, 에이전시(연속 행동)의 확대.

필자의 정리: 2023년 12월의 강의를 2026년에 보는 이유

이 영상을 공유한 게시물은 "에이전트 → 하네스 → 피드백 → 루프 → 그래프"라는 틀과 "프롬프팅의 종말"을 말하지만, 그것은 게시자의 해석이지 응 교수의 강의 내용이 아닙니다. 강의가 실제로 남기는 교훈은 더 소박하고 오래갑니다.

• LLM을 추론 엔진으로 쓰라. 맥락을 넣어 주고 처리하게 하며, 산수·검색·API 호출은 도구에 맡기는 배분이 2026년 에이전트 프레임워크의 뼈대 그대로입니다.
• 테스트셋보다 '실수 모음'을 먼저 만들라. 손으로 고른 평가셋 → 지표 → LLM 채점자라는 사다리는 지금의 eval 문화와 같습니다.
• 직무 말고 과업을 보라. 자동화 아이디어가 막힐 때 가장 빨리 통하는 틀입니다.
• 프롬프트 → RAG → 파인튜닝 순서는 비용 대비 효과의 순서이기도 합니다.

"에이전트는 와일드 웨스트, 디버깅이 안 된다"던 2023년의 진단이 3년 만에 어디까지 왔는지를 떠올리면, 강의 마지막의 "골든 에이지" 선언이 과장이 아니었음을 알 수 있습니다.

출처

• 영상을 접한 X 게시물: https://x.com/callanxai/status/2102840440051622044 (@callanxai, 2026년 9월 24일)
• 강의 공식 페이지: NeurIPS 2023 Tutorial — Application Development using Large Language Models (Andrew Ng, Isa Fulford / 패널 Antje Barth, Tatsunori Hashimoto, Meredith Ringel Morris, Graham Neubig, 2023년 12월 11일)
• 공식 녹화 영상(YouTube): https://www.youtube.com/watch?v=6CAryjpHPu4
• SlidesLive 녹화: https://slideslive.com/39013507/application-development-using-large-language-models
• 게시물이 인용한 글: Hanako(@hanakoxbt), "Loops and Graphs: how to stop babysitting agents and only approve the last step" (2026년 8월 23일, X 아티클)