On Engineering AI Systems that Endure The Bitter Lesson - Omar Khattab, DSPy & Databricks

영상 링크: On Engineering AI Systems that Endure The Bitter Lesson - Omar Khattab, DSPy & Databricks
채널명: AI Engineer

AI 시스템은 ‘쓴 교훈’의 원칙을 따르되, 장기적으로 견디는 구조적 추상화와 분리 설계가 관건 핵심 요약

• “쓴 교훈”(The Bitter Lesson)은 도메인 지식 기반의 복잡한 방법론보다, 범용적이고 확장 가능한 학습·탐색 기법이 훨씬 더 강력하다는 Rich Sutton(2019)의 AI 연구 통찰에서 출발함
• 최근 AI 엔지니어링은 주당/월당 새 LLM이 쏟아져 나와 아키텍처와 모델 선택이 매우 빠르게 변동하는 양상을 띔
• LLM API 내 모델이 내부적으로 자주 바뀌고, 프롬프트 최적화나 새로운 학습 기법이 끊임없이 발표되어 엔지니어가 매주 전략을 재점검해야 하는 실정임
• ‘쓴 교훈’을 오독하여 엔지니어링의 도메인 지식 적용 자체가 불필요하다고 보면 안 되며, 본질은 ‘프리미처(조기) 최적화’와 ‘과도한 저수준 하드코딩’이 해로움을 경계하라는 데 있음
• 모든 엔지니어링은 결국 시스템이 안정적이고 예측 가능하며 통제 가능한 구조를 갖추도록 추상화와 책임 분리가 필수적임
• 프롬프트 설계는 구조 없는 문자열이 요구(스펙), 특수 전략, 포맷 지정, 퇴행적 편법 등이 혼재돼 실질적 유지보수성과 재사용성이 떨어지는 매우 나쁜 추상화 방식임
• 소프트웨어 공학의 고전 원칙인 ‘관심사의 분리(Separation of Concerns)’와 명확한 스펙(자연어, 코드, 평가 기준(Eval))의 통합 관리를 통해 AI 시스템을 설계해야 함
• 코드·스펙·평가 분리 없는 강한 결합(tight coupling)은 한 시대의 패러다임 변화 속에 재사용 불가능성을 초래함
• DSPI 프레임워크(3년간 개발)는 ‘시그니처(Signature)‘라는 고수준 추상화로 사용자(엔지니어)가 AI 소프트웨어 구조 설계에 집중하고, LLM·탐색·학습 등 하위 레벨은 최신 툴킷으로 자유 교체할 수 있게 설계됨
• 무엇보다도 프리미처 최적화, 하드코딩, 단기적 모델 결합을 피하고, 교체 가능한 밑단과 장기화 가능한 핵심 추상화 작성에 자원을 투자해야 함

세부 요약 - 주제별 정리

AI 시스템 엔지니어링은 주기적으로 변화하는 LLM 환경에서 끊임없이 적응해야 함

• 최근 AI 소프트웨어 엔지니어링 환경은 주마다, 심지어 그보다 빠르게 새로운 대형 언어모델이 출시됨
• 각 모델은 성능, 속도, 비용, 특정 작업 최적화 등에서 고유한 트레이드오프를 가짐
• 일반 소프트웨어 엔지니어링이 하드웨어를 2~3년 주기로 한 번 교체한다면, AI는 매주 ‘플랫폼’의 변화라는 전례 없는 상황임
• LLM 제공자가 변화(업데이트, 내부 구조 변경, 프롬프트 가이드라인 추가 등)를 빈번하게 일으킴—사용자는 이를 끊임없이 따라가야 함
• 최신 모델 등장 외에도 새로운 학습/강화학습 알고리즘, 프롬프트 테크닉, 추론 전략, 에이전트 프레임워크, 아키텍처 발표가 끊이지 않음
• 실제로 제대로 엔지니어링을 하고 있다면 ‘뒤처지지 않기 위해’ 주간 단위로 업계 흐름을 점검할 수밖에 없음
• LLM API 내부 모델도 이름은 같지만 실제 구현이 달라질 수 있어 계속 ‘뒤쫓는’ 구조가 됨

‘쓴 교훈’(The Bitter Lesson): 확장성 높은 일반적 학습·탐색이 도메인 특화 방식보다 우월함을 증명함

• Rich Sutton(2019, 튜링상 수상자)이 발표한 짧은 에세이 ‘The Bitter Lesson’이 AI 연구의 핵심 교훈으로 자리매김
• Sutton의 주장은 “분야별(도메인) 지식에 기대어 튜닝한 복잡한 기법은 결국 확장되지 않아 한계에 봉착하고, 범용적이고 규모를 늘릴 수 있는 학습·탐색(search, learning)이 항상 이김”이라는 것
• 여기서 search는 Retrieval이 아니라, 보다 넓은 공간을 탐색하는 고차원적 의미임
• Sutton의 관점은 원칙적으로 ‘지능’ 극대화를 지향—새 환경에서 유연하고 신속하게 대처할 수 있는 시스템을 만드는 것이 중심
• 하지만 엔지니어의 과업은 ‘지능 자체’가 아니라, 신뢰성·통제성·확장성·이해 가능한 시스템 구축임

신뢰성·통제·추적성을 가진 소프트웨어는 도메인 지식 배제를 목표로 하지 않음

• 소프트웨어 엔지니어링에서 소프트웨어를 만드는 목적은 ‘AGI(범용 인공지능)가 없기 때문’이 아니라, 사람보다 더욱 신뢰할 수 있고 강인하며 통제 가능하며, 집단적으로 동작 가능한 시스템이 필요하기 때문임
• 이미 인류에 80억 개의 일반 지능이 있지만, 이들은 예측 불가능하고 신뢰성이 보장되지 않음
• 우리는 소프트웨어에 ‘agency(주체성)와 지능’을 필요한 만큼만, 그리고 신중하게 억제해 두는 checks & balances 구조를 설계함
• ‘지능 극대화’와 ‘시스템 안정성 확보’는 별개의 축에서 사고해야 하며, 엔지니어의 목표는 후자에 초점이 맞춰짐

프리미처(조기) 최적화와 과도한 저수준 하드코딩이 주요 위험 요소임

• Sutton의 ‘쓴 교훈’은 도메인 지식 자체의 배척이 아니라, ‘너무 일찍, 잘 알지도 못하는 상태에서 복잡성을 저수준에 하드코딩’하는 행태에 대한 경고임
• 이는 컴퓨터 공학 고전의 “프리미처 최적화는 모든 악의 근원(Premature optimization is the root of all evil)”(Donald Knuth, 1974)와 맥락이 같음
• 예제: 아키텍처나 환경 변화에 민감한 비트 조작 기반 수식 코드—미래 호환성과 유지보수성이 매우 낮음
• 좀 더 높은 추상화(예: square root 함수 직접 호출)를 선택해야, 하위 기반 구조가 바뀌어도 시스템이 견뎌낼 수 있음

추상화(abstraction)와 적정 레벨의 도메인 지식 적용이 시스템의 장기 생존력을 좌우함

• 프리미처 최적화란, ‘현재 수준보다 더 높고 일반적으로 표현 가능했던 부분까지 저수준에 하드코딩하는 것’을 의미
• 예: square root가 필요하다면, 굳이 하드코딩으로 직접 실수 연산 비트 조작 대신 함수나 라이브러리 레벨로 추상화할 것
• 자신이 진짜로 요구하는 수준의 문제(예: 진짜로 루트 값이 문제의 핵심인가?)에 집중하고, 좀 더 일반적이고 선언적인 방식으로 시스템을 표현할 것

머신러닝·프롬프트 엔지니어링 분야에는 ‘느슨한 결합’ 설계 원칙이 미흡하게 적용되고 있음

• 기존 소프트웨어 아키텍처(예: 2006년 논문 ‘A Modular Approach for Multilingual Question Answering’)에는 명확한 구조와 모듈화가 정착되어 있음
• 그러나 ML·LLM 시스템은 최신 논문 패러다임에 따라 코드 전체를 매번 뜯어고치는 경우가 많고, 추상화 수준이 낮아 재사용이 어렵게 됨
• 아키텍처 수준은 예전과 큰 차이가 없지만, 실제 코드·스펙·역할 할당 등은 시대 흐름에 따라 매번 완전히 달라지는 실정

프롬프트(문자열 기반)는 AI 시스템 공학에 매우 나쁜 추상화임

• 프롬프트는 ‘스트링리 타입(stringly-typed) 캔버스’로, 비구조적 문자열에 요구사항, 전략, 포맷 강요, 임시 편법이 섞임
• 실제 문제 해결(예: 핵심 task 정의)과 모델별 특성에 맞춘 임시 조작(예: 특정 프레이즈, 예시, 포맷 지시 등)이 한데 뒤엉킴
• 구조 없는 프롬프트는 시스템 의도와 우연한 하드코딩의 구분이 불가해 ‘왜 이렇게 동작하는가’를 분석하기 어렵게 만듬
• 새 LLM이나 추론 전략(에이전트, Chain-of-Thought, Monte Carlo search 등)이 나오면, 프롬프트 전체와 시스템 연동을 모두 수정해야 함
• 포맷(예: “XML로 출력, JSON으로 입력”, “너는 아인슈타인 교수이다”) 등 본질과 거리가 먼 지시가 코드에 깊게 스며드는 수준

관점의 분리(separation of concerns)와 스펙·코드·평가의 구조적 분할이 AI 공학의 관건임

• 올바른 AI 시스템 엔지니어링은 “요구사항(스펙)·모듈 코드·평가 기준”을 각기 독립적으로 명시·조합할 수 있도록 설계되어야 함
• 자연어 스펙은 애매모호하고 기계화 불가능한 부분(명확한 코딩이 불가능한 의도, 규칙 등)에만 집중
• 평가(Eval)란, 모델이나 inference 전략이 바뀌더라도 시스템이 추구하는 목표(기준)가 일관적으로 남게 만드는 핵심 지침임
• 코드 영역은 정보 흐름(Privacy, Tool Composition, Function Composition 등) 스펙 작성 및 LLM이 잘못하기 쉬운 부분(함수 합성) 등 실제 구조적 작업 담당
• 각 요소(스펙, 코드, 평가)는 강하게 결합되지 않고, 새로운 학습 전략, 최적화, LLM이 등장해도 hot swap이 가능하여야 함

시스템 전반 수준에서 학습과 평가, 제어 흐름을 관리할 추상화(캔버스)가 필요함

• 좋은 추상화 캔버스란, (1) 명확한 스펙, (2) 코드(모듈화), (3) 평가(evals)를 모델과 결합하지 않고 분리 표현 가능해야 함
• LLM, inference 전략, agent/chain 구조, 최적화 알고리즘 등 하위 구성요소가 빠르게 교체될 시장에서, 핵심 추상화 구조는 장기 존속해야 함
• reinforcement learning, 프롬프트 최적화 등 다양한 학습이 시스템 전체 단위에서 구조적으로 적용 가능해야 함

DSPI 프레임워크는 시그니처(Signature) 추상화로 AI 시스템 구조와 하위 레벨을 완전히 분리시킴

• DSPI(3년간 개발)는 세계 최초로 AI 시스템 구조(시그니처)와 하위 AI 소프트웨어(LLM, 탐색, 학습, 어댑터 등)를 완전히 분리·모듈화해서 설계
• 사용자가 직접 만드는 부분은 ‘시그니처’(Signature) 선언—한 번 학습하면 DSPI 전체 구조 이해에 충분
• 학습·탐색 등 하위 툴킷(최신 LLM, 강화학습, 프롬프트 최적화, inference 전략 등)은 DSPI에서 hot swap으로 지원, 시스템 코드 변경 필요 없음
• DSPI 프레임워크 사이트(dspi.ai) 참조

앞으로의 AI 시스템 생존 전략은 저수준 하드엔지니어링 최소화와, 교체 가능한 하위 구성/핵심 추상화 제작에 집중하는 데 있음

• 미래 예측은 불가능하나, 확실히 실천해야 할 최소 기준: “지금 가능한 한 높은 수준의 추상화로만 하드코딩할 것”
• LLM 등 하위 요소는 빠르게 교체될 것이므로, 오로지 자신만이 통제·정의할 수 있는 핵심 스펙, 제어흐름, 평가(핸드메이드)를 투자 포인트로 삼을 것
• 하위 구성요소(모듈, LLM, optimizer 등)는 최신 트렌드 따라 교체(ride the wave)하는 전략이 장기적으로 가장 유효
• 전체적으로, AI 시스템을 오래 살아남도록 만드는 열쇠는 (1) 필수적이고 범용적인 추상화 구조, (2) 유지 보수 가능한 관심사 분리, (3) 평가/테스트 가능성 강화임