[3편] 평가, 프롬프트, 인터페이스

AI Engineering Stack

by 오유나
이 글은 Pragmatic Engineer 뉴스레터 내 The AI Engineering Stack을 바탕으로 작성되었습니다.
Chip Huyen의 저서 《AI Engineering》의 발췌 내용을 중심으로, AI 애플리케이션의 핵심 구성요소인 평가, 프롬프트, 인터페이스를 실무자의 시선에서 짚어봅니다. 기술 자체보다 그것을 사용하는 방식과 맥락에 집중합니다.


왜 ‘평가’가 핵심 기술이 되었을까?

ML에서의 평가는 비교적 명확했습니다. 예측값과 실제값의 일치 여부로 모델 성능을 판단했으니까요. 하지만 Foundation Model을 활용한 AI 시스템에서는 ‘평가’가 곧 ‘철학’이 됩니다.

기대하는 답이 수십, 수백 가지가 될 수 있고

사람마다 답변의 품질에 대한 기준이 다르고

하나의 지표로는 설명되지 않는 애매한 상황이 많기 때문입니다


예를 들어, 챗봇이 사용자 질문에 답할 때, 어느 정도의 정보성을 담아야 ‘좋은 응답’일까요?
감정을 얼마나 표현해야 좋을까요?

이 모든 것은 정량적 평가로는 포착이 어렵고, 정성적 기준도 일관성이 떨어질 수밖에 없습니다.

Chip은 이런 문제를 해결하기 위해 다양한 기법을 조합할 것을 제안합니다.

A/B 테스트

사용자 피드백 수집 및 분석

실제 사용 환경에서의 로그 기반 자동 평가


그리고 그중에서도 가장 중요한 태도는, '무조건 정답을 정해두지 않는 유연성'이라고 강조합니다.

저는 이 부분에서 큰 공감을 했습니다. 현업에서도 종종 “정답 데이터셋을 만들자”는 시도가 반복되곤 합니다. 하지만 지금 시대의 AI는 ‘정답’보다 ‘수용 가능한 다양성’을 어떻게 다룰 것인가가 핵심입니다.


프롬프트, 이제는 UX의 일부다

프롬프트 엔지니어링은 모델을 다루는 기술이기도 하지만, 이제는 제품 경험(UX)의 일부로 자리잡고 있습니다.

사용자 질문을 어떻게 재구성할 것인가?

맥락을 어떻게 구성해 기억하게 할 것인가?

시스템의 역할을 명확하게 인식시키기 위해 어떻게 말을 걸 것인가?


이런 질문들이 바로 프롬프트 UX의 핵심입니다. 단순히 “이렇게 하면 더 잘 나옴”이라는 트릭이 아니라, 사용자와 모델 사이의 인터페이스 설계라는 점에서 큰 변화가 생긴 것이죠.

예를 들어, 같은 질문을 하더라도

“이 글을 요약해줘.” vs “학생이 읽기 쉽게, 3문장으로 핵심을 정리해줘.”
이 둘은 전혀 다른 결과를 냅니다.


그 차이는 모델의 성능이 아니라, 맥락 구성 능력의 차이입니다.

프롬프트 UX는 아직 명확한 규칙이 정립되지 않은 영역입니다.

그래서 지금 이 분야는, 기획자, 디자이너, 엔지니어가 함께 설계하는 협업의 장이 되어야 한다고 생각합니다.


인터페이스는 이제 ‘대화’ 그 이상이다

Foundation Model 시대의 인터페이스는 단순한 버튼과 입력창을 넘어서고 있습니다.

ChatGPT처럼 대화형 인터페이스

Perplexity처럼 검색형 인터페이스

Midjourney처럼 Discord 기반 명령어 인터페이스

VSCode에서 동작하는 Copilot, Shopify의 AI 플러그인, 그리고 Grammarly의 브라우저 확장기능까지


이 모든 것은 AI와 사용자의 ‘만남의 방식’을 다르게 만듭니다.


특히 중요한 점은, 이제는 누구나 AI를 앱으로, 확장기능으로, 플러그인으로 구현할 수 있다는 점입니다.

모델 개발자가 아니더라도, 인터페이스 설계만 잘하면 충분히 강력한 AI 제품을 만들 수 있습니다.


개발자 입장에서 저는 이 흐름이 매우 반갑습니다.

웹 풀스택 개발 경험이 있는 사람이라면 이제 AI 인터페이스 개발은 서비스 기획의 연장선에서 접근할 수 있습니다.

LangChain.js, Vercel AI SDK처럼 자바스크립트 기반 도구들도 빠르게 발전 중이라 더더욱 그렇습니다.


인터페이스, 프롬프트, 평가... 결국은 연결된 문제다

이 세 가지 요소는 사실 분리되어 있지 않습니다.

좋은 프롬프트 없이 좋은 인터페이스는 어렵고

평가 지표 없이는 프롬프트 실험도 불가능하며

인터페이스는 평가 수단이기도 합니다 (피드백을 쉽게 받을 수 있도록 설계되어야 하니까요)


그래서 AI Engineering은 팀 단위의 협업, 반복 실험,

그리고 사용자 관찰이 중심이 되어야 한다고 느낍니다.

이제 AI 시스템은 더 이상 엔지니어만의 것이 아닙니다.


4편 예고
"AI 엔지니어링과 풀스택 개발의 만남: 빠른 프로토타이핑 시대의 도구들"
– 왜 AI 엔지니어의 절반은 웹 개발자 출신인가?
– Python 중심에서 JS 기반 생태계로 확장되는 이유
– 기획부터 배포까지 한 사람이 다 할 수 있는 시대

keyword
화, 목, 토 연재
이전 27화[2편] 경계 위의 기술, AI vs ML 엔지니어링