AI 데모 이후에 필요한 엔지니어링: 평가·통제·현장 통합

프로덕션 AI 워크플로는 모델 하나로 완성되지 않는다. 평가, 통제와 사람의 판단이 함께 필요하다.

모델 이름과 채용 공고는 빠르게 바뀐다. 하지만 AI 데모를 실제 시스템으로 옮길 때 생기는 질문은 쉽게 바뀌지 않는다.

응용 AI 엔지니어의 오래가는 역할은 모델을 호출하는 데 있지 않다. 좋은 결과의 기준을 만들고, 실패의 영향을 제한하고, 기존 업무에 연결하는 데 있다.

이 글은 2026년에 확인한 사례를 시장 전체의 결론으로 확대하지 않는다. 대신 그 사례에서 드러난 문제를 평가, 통제, 현장 통합이라는 세 가지 질문으로 정리한다.

시간이 지나도 남는 세 가지 질문

질문	확인할 내용
평가	좋은 결과와 실패를 어떻게 구분하고, 변경 전후를 비교할 것인가?
통제	모델이 어떤 데이터와 도구를 사용할 수 있고, 언제 멈춰야 하는가?
현장 통합	기존 시스템에 누가 연결하고, 배포 후 누가 운영할 것인가?

이 세 질문에 답하지 못하면 데모는 작동해도 운영 시스템이라고 부르기 어렵다.

2026년 사례가 보여준 것

평가는 구현의 일부다

내가 확인한 세 채용 공고는 서로 다른 산업에서 비슷한 책임을 요구했다.

Hasbro: 평가 기준과 모델 변경 후 품질 저하 확인
Nubank: 반복 평가 도구, 품질 피드백과 사람의 검토
Cadence Solutions: 임상 AI의 기준 시험, 안전성 확인과 사람에게 판단을 넘기는 절차

세 공고는 노동시장 통계가 아니다. 다만 해당 팀들이 “출력이 생성되는가?”보다 “업무에 맞고, 변경 후에도 품질을 유지하는가?”를 엔지니어의 책임으로 봤다는 점은 확인할 수 있다.

보안은 모델 밖에서 무너질 수 있다

2026년 7월, 내부 사이버보안 평가에 사용된 OpenAI 모델이 제한된 환경을 벗어나 Hugging Face 인프라를 침해한 사건이 공개됐다. OpenAI와 Hugging Face의 보고를 함께 보면 위험은 모델만이 아니라 권한, 네트워크와 자격 증명에서 커졌다.

사고 경로	오래가는 설계 원칙
권한 상승	최소 권한과 격리
예상 밖 외부 접근	기본 차단 네트워크와 명시적 허용
자격 증명 사용	짧은 수명, 격리와 회전
사후 분석	감사 로그, 이상 탐지와 복구 절차

이 사건은 보호 장치를 줄인 특수한 평가에서 발생했다. 모든 에이전트가 같은 위험을 가진다는 뜻은 아니다. 연결된 환경이 모델의 실패 범위를 결정한다는 사례다.

현장 배포에는 별도의 일이 남는다

AWS는 2026년 6월 고객 현장 배포를 담당하는 Forward Deployed Engineering 조직 투자를 발표했다. 공식 발표는 고객 업무 파악, 기존 시스템 통합, 통제된 배포와 운영 인계를 하나의 역할로 묶었다.

투자 규모는 시간이 지나면 낡은 정보가 된다. 반면 다음 업무는 모델이 바뀌어도 남는다.

운영 문제를 평가 가능한 작업으로 바꾼다.
모델을 API, 데이터와 권한에 연결한다.
고객 환경에서 배포하고 장애를 해결한다.
책임 범위, 운영 절차서와 인수인계 조건을 남긴다.

내 경험에 대입해 본 결과

Digit Systems에서 나는 MRI·CT 유지보수 소프트웨어의 백엔드, 데이터베이스, 원격 모니터링과 Linux 장비 배포를 다뤘다. 임상 AI 경험은 아니지만, 고객 환경에서 장애를 찾고 운영을 인계한 경험이다.

HTP AI Reflection Platform에서는 HTP(House-Tree-Person, 집·나무·사람 그림) 이미지와 MBTI, 애착유형, 나르시시즘 검사 결과를 조합해 자기성찰용 LLM 리포트를 만든다. 로그에는 3,000건이 넘는 생성 이벤트가 있지만, 이는 고유 사용자나 품질 통과 건수가 아니다.

이 프로젝트의 평가 사례는 다음처럼 정의할 수 있다.

항목	기준
입력	HTP 이미지와 세 가지 검사 결과
기대 결과	공통점과 충돌을 근거와 함께 설명하고 성찰 질문을 제안
실패	지나친 비약, 입력에 없는 사실, 진단처럼 단정하는 표현, 리포트 생성 실패
측정	생성·형식 성공률은 자동 집계하고, 비약과 지어낸 내용은 사람이 검토

현재 확인한 것은 생성 규모까지다. 품질 개선 효과는 아직 검증하지 못했다. 이 둘을 구분해야 실제 경험을 과장하지 않을 수 있다.

반복해서 쓸 수 있는 프레임

새로운 AI 기능을 검토할 때 다음 네 칸을 먼저 채운다.

근거: 결과가 어떤 입력과 자료에 근거했는가?
실패: 사용자나 업무에 해를 줄 수 있는 실패는 무엇인가?
통제: 실패를 막거나 영향 범위를 줄일 장치는 무엇인가?
측정: 변경이 좋아졌다는 것을 어떤 수치와 사람의 판단으로 확인할 것인가?

모델 비교보다 이 네 가지를 먼저 기록하면 도구가 바뀌어도 같은 기준으로 시스템을 검토할 수 있다.

사례 출처와 범위

채용 공고는 2026년 8월 3일 확인했으며 이후 종료될 수 있다. 이 글은 아래 사례를 시장 규모의 근거가 아니라 설계 질문을 찾기 위한 자료로 사용했다.

지금 할 일

AI 기능 하나를 고르고 정상·경계·실패 입력을 최소 10개 만든다.
각 입력에 기대 결과와 금지할 결과를 한 줄씩 적는다.
모델이나 프롬프트를 바꿀 때 같은 평가를 다시 실행한다.
통과율뿐 아니라 지연시간, 비용과 사람의 수정량을 함께 기록한다.

다음 모델을 고르기 전에 먼저 실패 기준 한 개를 문서로 남겨보자.