RicoCheesethe studio log · v2.0
Live · KRRead posts
목록으로
뉴스PUBLISHED · 2026년 7월 1일·15 MIN READ

하네스 엔지니어링부터 평가(Evals)까지: AI Engineer 컨퍼런스가 보여준 6가지 흐름

샌프란시스코 AI Engineer 컨퍼런스에서 실제 프로덕션에 쓰이는 기술만 추려낸 여섯 가지 주제. LLM을 하나의 운영체제처럼 다루는 소프트웨어 아키텍처로의 전환을 정리한다.

#ai#llm#tech#news#programming
From Harness Engineering to Evals: What's Trending at AI Engineer

개요 #

이번 주 샌프란시스코에서 열린 AI Engineer 컨퍼런스는 주요 브랜드 스폰서와 유명 오픈소스 메인테이너, 방대한 세션으로 가득했다. 트랙만 수십 개, 참가한 빌더는 수천 명. 겉보기엔 생태계가 산산조각 난 듯 어수선하다.

그런데 엔지니어들이 실제로 프로덕션에 올리는 것만 추려보면 그림이 선명해진다. 업계는 단순한 챗 인터페이스를 벗어나, 대규모 언어 모델을 더 크고 구조화된 소프트웨어 아키텍처 안의 중앙처리장치처럼 다루기 시작했다. 일종의 LLM 운영체제(LLM Operating System) 인 셈이다.

원문 저자는 현장에서 본 것들을 정리해 여섯 가지 주제로 압축했다. 이 글은 그 여섯 가지를 한국 독자를 위해 다시 풀어 쓴 것이다. 특정 기술을 추천하거나 과대광고와 실체를 구분해 판정하려는 글은 아니다. 관심이 가는 주제가 있다면 더 깊이 파고드는 출발점으로 삼으면 된다.

1. 저장소 단위 "소프트웨어 팩토리"로의 이동 #

지난 몇 년간 개발에서의 AI는 사실상 탭 자동완성이었다. 코드 한 줄을 쓰면 어시스턴트가 다음 토큰 몇 개를 제안하고, 그걸 받아 넘어가는 방식이었다.

이 단일 파일 중심 방식은 빠르게 낡은 것이 되고 있다. 초점은 저장소 전체를 다루는 멀티 에이전트 시스템, 이른바 소프트웨어 팩토리(Software Factory) 로 옮겨갔다.

이제 개발자는 AI 어시스턴트 옆에서 코드를 한 줄씩 쓰는 대신, 코드베이스 전체를 넘나드는 에이전트 무리를 관리한다. 우버가 공개한 내부 코드 리뷰 엔진 uReview가 좋은 예다. 이 시스템은 에이전트가 자율적으로 풀 리퀘스트를 검토하고, 국소적인 테스트 스위트를 띄우고, 엣지 케이스를 잡아내고, 수정 사항을 브랜치에 커밋한다. 사람이 들여다보기 전에 이 모든 게 끝난다.

신뢰성을 확보하기 위해 엔지니어들은 컴파일러와 린터를 에이전트의 피드백 루프에 직접 물린다. 생성된 코드가 컴파일에 실패하면 원본 에러 출력이 곧바로 시스템 프롬프트로 되돌아간다. 모델은 자신이 낸 에러를 읽고 버그를 고친 뒤, 검사를 다시 돌린다. 사람 개입 없이.

2. "하네스 엔지니어링"으로 시스템 단단하게 만들기 #

컨퍼런스 현장에서 반복되는 깨달음이 하나 있었다. "다들 에이전트 하네스를 만들고 있는데, 아무도 그걸 하네스라고 부르지 않는다."

LLM은 본질적으로 확률적이고 비결정적이다. 반면 소프트웨어 인프라는 예측 가능한 입력과 출력을 요구한다. 이 간극을 메우기 위해 팀들은 하나의 핵심 시스템 규율을 정립하고 있다. 바로 하네스 엔지니어링(Harness Engineering) 이다.

전선 위에서 작업하는 인부들 Photo by Phát Trương on Pexels

여기서 하네스란 모델을 감싸는 엄격한 소프트웨어 래퍼다. 제약을 강제하고, 상태를 관리하고, 무한 실행 루프를 막는다. 대략 이런 계층으로 구성된다.

untitled
+--------------------------------------------------------+
|                   THE AGENT HARNESS                    |
+--------------------------------------------------------+
| 1. 지속 실행 (상태 보존 & 재시도)                       |
+--------------------------------------------------------+
| 2. 구조화된 출력 (스키마 강제 / Pydantic)               |
+--------------------------------------------------------+
| 3. 동적 가드레일 (입출력 살균)                          |
+--------------------------------------------------------+

에이전트를 감시 없이 방치하는 대신, 개발자들은 Temporal이나 Inngest 같은 툴체인으로 지속 실행(durable execution) 을 구현한다. 몇 시간짜리 복잡한 워크플로를 돌리던 에이전트가 네트워크 타임아웃에 걸려도, 하네스가 메모리와 상태를 보존한다. 덕분에 프로세스는 실패한 바로 그 지점부터 다시 시작한다. 비싼 API 호출을 처음부터 반복하지 않는다. 여기에 Pydantic이나 Instructor 같은 라이브러리로 엄격한 JSON 스키마를 강제하면, 하네스는 변덕스러운 모델을 안정적인 인프라처럼 굴러가게 만든다.

3. 컴퓨터 유즈 vs 커스텀 API #

수십 년간 통합이라 하면 커스텀 API 커넥터를 짜거나 엔드포인트를 스크래핑하는 일이었다. 올해의 큰 주제 하나는 컴퓨터 유즈(Computer Use) 다. 사람 조작자와 똑같이, 화면을 보고 마우스를 움직이고 명령을 입력하며 소프트웨어를 다루는 에이전트를 만드는 것이다.

성능 좋은 비전-언어 모델(VLM) 덕분에 이런 시스템은 구조화된 백엔드 API를 필요로 하지 않는다. 그래픽 인터페이스를 연속으로 스크린샷 찍고, 화면 레이아웃을 파싱해 입력 필드와 버튼을 찾은 뒤, 정확한 픽셀 좌표를 클릭한다.

이 흐름은 로컬 개발 환경도 바꿔놓았다. 엔지니어들은 격리된 샌드박스 터미널과 오픈소스 데스크톱 컴패니언(OpenClaw 같은)을 구축해, 백그라운드 에이전트에게 별도의 가상 환경을 내준다. 에이전트가 로컬 서버를 띄우고 파일을 디버깅하는 동안에도 개발자의 실제 화면과 키보드를 점령하지 않는다.

4. 컨텍스트 엔지니어링과 "토큰맥싱" #

컨텍스트 윈도는 수백만 토큰까지 커졌다. 그렇다고 코드베이스 전체를 프롬프트에 쏟아붓는 건 비싸고 느린 안티패턴이다.

지금의 진짜 병목은 첫 토큰까지 걸리는 시간(time-to-first-token)과 API 비용이다. 그래서 개발자들은 컨텍스트 엔지니어링(Context Engineering) 에 힘을 쏟는다. 컨텍스트 윈도를 정적인 텍스트 덤프가 아니라, 고도로 최적화된 동적 메모리 캐시로 다루는 것이다.

최적화 전략은 대체로 세 층위로 나뉜다.

  • 프리픽스 캐싱(Prefix Caching): vLLM 같은 추론 엔진이 정적인 시스템 지시문이나 문서 헤더의 키-밸류(KV) 상태를 캐싱한다. 이후 요청은 이 캐시를 재사용해 지연과 비용을 크게 줄인다.

  • 컨텍스트 압축(Context Compression): 미들웨어 계층이 의미 기반 압축 알고리즘을 돌려, 데이터를 프로바이더에 보내기 전에 무관한 토큰을 쳐내고 지저분한 대화 로그를 요약한다.

  • 그래프 RAG & 하이브리드 검색: 원시 텍스트 블록을 무차별로 끌어오는 대신, 구조화된 지식 그래프로 신호가 높은 데이터만 활성 컨텍스트 윈도에 넘긴다.

5. "감(感) 기반" 평가와의 결별 #

운영 측면에서 가장 뚜렷한 변화 하나를 꼽으라면, 감으로 하는 엔지니어링이 끝났다는 점이다. 출력 몇 개를 훑어보고 그럴듯하다 싶으면 프로덕션에 올리는 관행은 더 이상 통하지 않는다.

평가(Evals) 커뮤니티의 핵심은 자동화된 다단계 시뮬레이션 벤치마크다. 이제 에이전트를 평가하려면 격리된 가상 환경, 즉 모의 데이터베이스와 네트워크 접근을 갖춘 임시 샌드박스를 띄운 뒤 복잡한 과제를 시켜본다. 평가 프레임워크는 응답의 스타일을 채점하지 않는다. 과제를 실제로 완수했는지, 몇 단계가 걸렸는지, 보안 규약을 어기지 않았는지를 확인한다.

엔지니어들은 "페르소나 함정(Persona Trap)"에서도 벗어나고 있다. 모델에게 "당신은 시니어 스태프 엔지니어입니다" 같은 프롬프트를 주는 방식 말이다. 현장에서 공유된 연구들은 이 접근이 엄밀한 기술 역량이 아니라 문체상의 감을 평가하며, 성능을 떨어뜨리는 조용한 편향을 끼워 넣는 경우가 많다고 지적했다. 이제 기준은 엄격하고 과제 지향적인 테스트다.

6. 런타임 안전을 위한 보안 마이크로 샌드박스 #

에이전트에게 코드를 쓰고 파일을 고치고 터미널 명령을 실행할 권한을 주면 심각한 보안 위험이 따른다.

플랫폼 엔지니어들은 실행 계층 자체에 집중해 이 문제를 다룬다. 업계 표준은 마이크로 샌드박스(Micro-Sandbox) 로 수렴했다. 에이전트가 생성한 코드는 밀리초 단위로 뜨는 가볍고 일회성인 마이크로 VM(E2B나 Docker 계열) 안에서 실행된다. 특정 연산을 처리하고 나면 곧바로 파기되어, 컨테이너 탈출이나 파일 시스템 변조를 막는다.

자격 증명 마스킹(credential masking)을 향한 움직임도 크다. 에이전트가 기업 데이터베이스나 서드파티 도구에 접근해야 할 때, 엔지니어들은 AAuth 프로토콜 같은 새 위임 계층을 쓴다. 이렇게 하면 에이전트에게 도구를 호출할 임무 한정 권한만 부여하고, 원시 API 키는 절대 보지도 만지지도 못하게 막아 프롬프트 인젝션으로 인한 유출을 무력화한다.

결론 #

이런 주제들을 대충 훑다 보면 FOMO가 밀려온다. 마이크로 샌드박스 무리나 자율 소프트웨어 팩토리를 돌리고 있지 않다면 벌써 뒤처진 것 아닌가 싶어진다.

과대광고에 휩쓸리지 말자. 다음 주 월요일까지 스택 전체를 갈아엎을 필요는 없다.

모스코니 센터의 온갖 소음에서 건질 진짜 교훈은 오히려 마음을 놓게 한다. AI는 그저 평범한 소프트웨어 인프라가 되어가는 중이다. 앞으로 몇 년간 쓸모 있는 것을 만들어낼 개발자는 새 모델이 나올 때마다 좇거나 복잡한 멀티 에이전트 프레임워크에 매달리는 사람이 아니다. 기본적이고 지루한 엔지니어링 원칙을 지키는 사람이다. 입력을 예측 가능하게 만들고, 코드를 엄격히 테스트하고, 환경을 안전하게 유지하는 것 말이다.

시작할 곳을 찾고 있다면 복잡하게 생각하지 말자. 일상 업무에서 반복되는 워크플로 하나를 고르자. 그 주위에 깔끔하고 방어적인 코드 하네스를 두르고, 결과를 검증할 간단한 평가 스크립트를 짜서 무슨 일이 벌어지는지 지켜보자. 영감도 좋지만, 실제로 무언가를 배포하는 힘은 실용주의에서 나온다.


이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.