[1편] AI 엔지니어링이라는 이름의 탄생
이 글은 Pragmatic Engineer 뉴스레터 내 The AI Engineering Stack을 바탕으로 작성되었습니다.
이 글은 Chip Huyen의 저서 《AI Engineering》의 발췌 내용을 중심으로, 빠르게 진화하는 AI 기술 환경 속에서 소프트웨어 개발자가 어떤 사고의 전환을 요구받고 있는지 살펴봅니다. 단순한 용어 정리가 아닌, 실무자의 관점에서 겪는 변화와 선택의 고민을 담았습니다.
AI Engineering book by Chip HuyenAI 엔지니어링이라는 용어는 어디서 왔을까
2년 전만 해도 존재하지 않던 직군. 지금은 Google, Meta, Amazon 같은 기업에서 기존 소프트웨어 엔지니어보다 더 높은 연봉을 받는 포지션. 그게 바로 “AI Engineer”입니다.
그림 1-12. 많은 기업들이 AI 엔지니어링과 ML 엔지니어링을 같은 범주로 묶고 있으며, 이는 2023년 12월 17일 기준 링크드인에 게시된 채용 공고 제목에서도 확인할 수
하지만 속을 들여다보면 이 직군의 많은 역할은 여전히 '소프트웨어 엔지니어링'에 기반해 있습니다.
단지 LLM을 다루고 통합할 수 있는 능력이 중요해졌다는 것이 달라졌을 뿐이죠.
Chip Huyen은 이렇게 말합니다.
“AI Engineering은 결국 ‘AI 모델이 끼어든 소프트웨어 엔지니어링’일 뿐이다.”
처음 이 말을 들었을 땐 고개가 갸우뚱해졌습니다.
정말 그럴까요? 학습, 파인튜닝, 인퍼런스, 프롬프트 엔지니어링, 평가 시스템, 거기에 앱 인터페이스까지... 이 모든 걸 감당해야 하는 우리가 여전히 그냥 '소프트웨어 엔지니어'라고 할 수 있을까요?
하지만 뒤집어 생각하면, 기존의 소프트웨어 엔지니어링 사고방식과 도구들이 AI 시대에도 유효하다는 뜻일 수 있습니다. 오히려 이 격변 속에서 가장 강력한 무기는 탄탄한 소프트웨어 공학 기반일지도 모르겠습니다.
AI 스택: 모델만 잘 만들면 끝나는 시대는 지났다
그림 1-14. AI 엔지니어링 스택의 세 가지 계층Chip은 AI 시스템을 구성하는 3가지 계층을 다음과 같이 정리합니다.
애플리케이션 개발 (Application Development)
모델 개발 (Model Development)
인프라스트럭처 (Infrastructure)
우리는 종종 2번에만 집중하곤 합니다.
새로운 모델, 더 높은 정확도, 더 적은 파라미터...
하지만 실제로 제품화된 AI 시스템은 1번과 3번이 무너지면 쓸모가 없습니다.
예를 들어, 좋은 모델을 학습했더라도,
제대로 된 평가 체계 없이 배포된다면 문제를 감지할 수 없고,
실시간 추론이 너무 느리다면 사용자 이탈을 막을 수 없으며,
애매한 프롬프트 인터페이스만 있다면 아무리 성능이 좋아도 활용되지 않습니다.
결국, 모델 그 자체가 아니라 모델을 둘러싼 구조가 AI 제품의 성패를 좌우합니다.
변하지 않는 것과 바뀐 것
AI 엔지니어링이 주는 새로운 감각은 분명 존재하지만, ML 엔지니어링이 수년간 쌓아온 원칙들 역시 여전히 유효합니다. 예컨대,
비즈니스 목표를 ML 목표로 번역하는 사고법
실험 설계와 반복 개선 루프
추론 비용을 줄이는 최적화 노력
이 모든 것이 여전히 필요합니다.
단지 이제는 여기에 모델 선택, 프롬프트 디자인, 맥락 구성 같은 새로운 요소들이 추가되었을 뿐입니다.
그렇다면 AI 엔지니어는 무엇을 더 알아야 할까요? 기존 ML 엔지니어와는 무엇이 다를까요?
다음 편에서는 AI Engineering과 ML Engineering의 경계선 위에서 어떤 역할 변화가 일어나고 있는지를 다뤄보겠습니다.
2편 예고
"AI 엔지니어링과 ML 엔지니어링의 경계에서: 평가와 적응의 기술"
– 모델을 만들던 시대에서 모델을 ‘잘 쓰는’ 시대로.
– 프롬프트 vs 파인튜닝, 언제 어떻게 선택해야 하는가.
– 왜 ‘평가’가 이제 가장 중요한 기술이 되었는가.
