저는 이번 주 샌프란시스코에서 열리는 AI Engineer 컨퍼런스에 와 있습니다. 이 행사에는 예상할 수 있는 모든 주요 브랜드 스폰서들이 참여하고 있으며, 무대 위에는 인터넷에서 유명한 프로젝트 유지 관리자들이 라인업을 구성하고 있고, 거의 모두를 위한 무언가가 포함된 방대한 일정이 준비되어 있습니다. 소음 속에서 길을 잃기 쉽습니다. 저는 무엇이 실제로 실재하는 테마인지 파악하기 위해 시간을 보냈습니다.

수십 개의 트랙과 수천 명의 빌더들이 있어 생태계가 믿기지 않을 정도로 파편화되어 보입니다. 하지만 엔지니어들이 실제로 무엇을 프로덕션(production)에 적용하고 있는지를 살펴보면, 그 혼돈은 명확한 패턴으로 수렴됩니다. 업계는 단순한 채팅 인터페이스를 넘어 대규모 언어 모델(Large Language Models, LLM)을 더 크고 고도로 구조화된 소프트웨어 아키텍처 내부의 중앙 처리 장치(Central Processing Units, CPU)처럼 취급하고 있습니다. 본질적으로 LLM 운영체제(LLM Operating System)라고 할 수 있습니다.

저는 제가 보고 있는 모든 것을 목록화하고 기술 트랙을 깊이 파고들었으며, 다음과 같은 6가지 테마를 도출해 냈습니다. 이것은 저의 보증이 아니며, 저는 과장된 광고(hype)와 실재를 구분하지 않았습니다. 이 짧은 요약들을 여러분의 호기심을 자극하는 아이디어가 있다면 더 깊이 파고들기 위한 출발점으로 삼으시기 바랍니다.

1. 리포지토리 규모의 "소프트웨어 팩토리(Software Factories)"로의 전환

지난 몇 년 동안 개발에서의 AI는 기본적으로 탭 완성(tab-complete) 수준이었습니다. 코드 한 줄을 쓰면 어시스턴트가 다음 몇 개의 토큰(tokens)을 제안하고, 사용자는 다음 단계로 넘어가는 방식이었습니다.

그러한 단일 파일 접근 방식은 빠르게 구식이 되어가고 있습니다. 초점은 리포지토리(repository) 규모의 멀티 에이전트 시스템(multi-agent systems), 즉 사람들이 **소프트웨어 팩토리(Software Factories)**라고 부르는 것으로 이동했습니다.

개발자들은 AI 어시스턴트와 함께 코드 한 줄을 작성하는 대신, 전체 코드베이스에 걸쳐 작동하는 에이전트 함대(fleets of agents)를 관리하고 있습니다. 예를 들어, Uber는 내부 코드 리뷰 엔진인 uReview에 대한 세부 정보를 공유했습니다. 이는 에이전트를 사용하여 풀 리퀘스트(pull requests)를 자율적으로 리뷰하고, 로컬 테스트 스위트(localized test suites)를 실행하며, 엣지 케이스(edge cases)를 포착하고, 사람이 확인하기도 전에 브랜치에 수정 사항을 커밋(commit)합니다.

이를 신뢰할 수 있게 만들기 위해, 엔지니어들은 컴파일러(compilers)와 린터(linters)를 에이전트의 피드백 루프(feedback loop)에 직접 연결하고 있습니다. 만약 생성된 코드가 컴파일에 실패하면, 가공되지 않은 에러 출력(raw error output)이 시스템 프롬프트(system prompt)로 즉시 다시 전달됩니다. 모델은 자신의 에러를 읽고, 버그를 수정하며, 자율적으로 체크를 다시 실행합니다.

2. "하네스 엔지니어링(Harness Engineering)"을 통한 시스템 강화

현재 컨퍼런스 현장에서는 공통적으로 깨닫고 있는 사실이 하나 있습니다: "모두가 에이전트 하네스(agent harness)를 구축하고 있지만, 아무도 그것을 그렇게 부르지 않는다."

LLM(대규모 언어 모델)은 본질적으로 확률적(probabilistic)이고 비결정론적(non-deterministic)입니다. 반면, 소프트웨어 인프라는 예측 가능한 입출력을 필요로 합니다. 이를 해결하기 위해 팀들은 핵심적인 시스템 규율인 **하네스 엔지니어링(Harness Engineering)**을 공식화하고 있습니다.

여기서 "하네스(harness)"

수십 년 동안 통합(integration)은 커스텀 API 커넥터를 작성하거나 엔드포인트를 스크래핑하는 것을 의미했습니다. 올해의 주요 테마는 **컴퓨터 사용(Computer Use)**입니다. 이는 화면을 보고, 마우스를 움직이며, 명령어를 입력하는 방식으로 인간 운영자와 똑같이 소프트웨어를 탐색하는 에이전트를 구축하는 것입니다.

더 나은 시각-언어 모델(VLMs)을 통해 가능해진 이러한 시스템들은 구조화된 백엔드 API를 필요로 하지 않습니다. 이들은 그래픽 사용자 인터페이스(GUI)의 연속적인 스크린샷을 찍고, 시각적 레이아웃을 파싱하여 필드와 버튼의 위치를 찾아내며, 정밀한 픽셀 좌표를 실행합니다.

이로 인해 로컬 개발자 환경의 변화가 강제되었습니다. 엔지니어들은 격리된 샌드박스 터미널(sandboxed terminals)과 오픈 소스 데스크톱 컴패니언(OpenClaw와 같은)을 구축하여 백그라운드 에이전트에게 고유한 가상 환경을 제공하고 있습니다. 이를 통해 에이전트는 엔지니어의 활성 화면과 키보드를 점유하지 않고도 격리된 상태에서 로컬 서버를 실행하고 파일을 디버깅할 수 있습니다.

4. 컨텍스트 엔지니어링(Context Engineering) 및 “토큰맥싱(Tokenmaxxing)”

컨텍스트 윈도우(Context windows)는 수백만 토큰 규모로 확장되었지만, 전체 코드베이스를 프롬프트에 쏟아붓는 것은 비용이 많이 들고 지연 시간(latency)이 높은 안티 패턴(anti-pattern)입니다.

오늘날 실제 병목 현상은 첫 번째 토큰 생성 시간(Time-to-first-token)과 API 비용입니다. 이 때문에 개발자들은 **컨텍스트 엔지니어링(Context Engineering)**에 집중하고 있습니다. 즉, 컨텍스트 윈도우를 정적인 텍스트 덤프가 아닌, 고도로 최적화된 동적 메모리 캐시(memory cache)로 취급하는 것입니다.

최적화 전략은 일반적으로 다음과 같은 3계층 접근 방식을 따릅니다:

• Prefix Caching (접두사 캐싱): vLLM과 같은 추론 엔진(Inference engines)은 정적인 시스템 지침(system instructions)이나 문서 헤더의 Key-Value (KV) 상태를 캐싱합니다. 후속 요청은 이 캐시를 재사용하여 지연 시간(latency)과 비용을 크게 절감합니다.

• Context Compression (컨텍스트 압축): 미들웨어 계층(Middleware layers)을 도입하여 의미론적 압축(semantic compression) 알고리즘을 실행함으로써, 데이터를 제공자(provider)에게 보내기 전에 불필요한 토큰을 제거하고 지저분한 채팅 로그를 요약합니다.

• Graph RAG & Hybrid Retrieval (그래프 RAG 및 하이브리드 검색): 원문 텍스트 블록을 무분별하게 가져오는 대신, 시스템은 구조화된 지식 그래프(knowledge graphs)를 사용하여 고신호(high-signal) 데이터만을 활성 컨텍스트 창(active context window)에 전달합니다.
  링크 link.dev.to/aie39에서 읽기를 마칩니다.

5. “Vibe-Based(감각 기반)” 평가를 넘어서

명확한 운영상의 변화가 하나 있다면, 그것은 바로 'vibe-based' 엔지니어링의 종말입니다. 몇 개의 출력물을 검토하고, 그것이 합리적으로 보인다고 판단하여 프로덕션에 배포하는 방식은 더 이상 용납되는 관행이 아닙니다.

Evals (평가) 커뮤니티의 핵심 초점은 자동화된 다단계 시뮬레이션 벤치마크(simulation benchmarks)에 있습니다. 이제 에이전트를 평가하려면 격리된 가상 환경(isolated virtual environment)—모의 데이터베이스(mock databases)와 네트워크 액세스 권한을 갖춘 임시 샌드박스(sandbox)—를 구축하고 에이전트가 복잡한 작업을 시도하도록 해야 합니다. 평가 프레임워크(evaluation framework)는 응답의 스타일을 채점하지 않습니다. 대신 작업이 성공적으로 완료되었는지 확인하고, 몇 단계가 소요되었는지 기록하며, 보안 프로토콜이 위반되지 않았는지 검증합니다.

엔지니어들은 또한 “페르소나 함정(Persona Trap)”—모델에게 “당신은 시니어 스태프 엔지니어입니다”와 같은 프롬프트를 주는 것—에서도 벗어나고 있습니다. 행사에서 공유된 연구들에 따르면, 이러한 접근 방식은 엄격한 기술적 역량보다는 스타일적인 분위기(vibe)를 평가하며, 종종 성능을 저하시키는 잠재적인 편향(silent biases)을 유발합니다. 이제 표준은 엄격하고 작업 중심적인 테스트입니다.

6. 런타임 안전을 위한 보안 마이크로 샌드박스(Secure Micro-Sandboxes)

에이전트에게 코드를 작성하고, 파일을 수정하며, 터미널 명령을 실행할 수 있는 권한을 부여하는 것은 심각한 보안 리스크를 초래합니다.

플랫폼 엔지니어들은 근본적인 실행 계층(execution layer)에 집중함으로써 이 문제를 해결하고 있습니다. 업계 표준은 **마이크로 샌드박스 (Micro-Sandboxes)**를 중심으로 정착되었습니다. 에이전트가 생성한 코드는 E2B나 Docker와 같은 경량화된 휘발성 마이크로 VM (micro-VMs) 내부에서 실행됩니다. 이들은 밀리초 단위로 구동되어 특정 연산을 처리한 후, 컨테이너 탈출(container escape)이나 지속적인 파일 시스템 변조를 방지하기 위해 즉시 파괴됩니다.

또한 자격 증명 마스킹 (credential masking)에 대한 강력한 추진도 이루어지고 있습니다. 에이전트가 기업 데이터베이스나 제3자 도구에 접근해야 할 때, 엔지니어들은 AAuth 프로토콜과 같은 새로운 위임 계층 (delegation layers)을 사용합니다. 이는 에이전트에게 도구를 호출할 수 있는 임무 제한적 권한 (mission-bounded authority)을 부여하지만, 에이전트가 원본 API 키를 보거나 상호작용하는 것을 차단하여 프롬프트 인젝션 (prompt injection) 유출을 무력화합니다.

핵심 요약 (The Bottom Line)

이러한 주제들을 훑어보다 보면, 마이크로 샌드박스 군단을 운영하거나 자율 소프트웨어 공장 (autonomous software factory)을 구축하고 있지 않다면 소외되는 것 같은 공포(FOMO)를 느끼며 이미 뒤처지고 있다고 생각하기 쉽습니다.

과장된 광고에 현혹되지 마세요. 다음 주 월요일까지 스택 전체를 완전히 개편할 필요는 없습니다.

Moscone에서 들려오는 모든 소음으로부터 얻을 수 있는 진짜 교훈은 사실 꽤 안심이 되는 내용입니다. 즉, AI는 그저 일반적인 소프트웨어 인프라 (software infrastructure)가 되어가고 있다는 것입니다. 향후 몇 년 동안 유용한 것을 만들어낼 개발자들은 매번 번쩍이며 등장하는 새로운 모델이나 복잡한 멀티 에이전트 프레임워크 (multi-agent framework)를 쫓아다니는 사람들이 아닐 것입니다. 그들은 입력을 예측 가능하게 만들고, 코드를 엄격하게 테스트하며, 환경을 안전하게 유지하는 것과 같은 기본적이고 지루한 엔지니어링 원칙을 적용하는 사람들이 될 것입니다.

시작할 곳을 찾고 있다면, 너무 복잡하게 생각하지 마세요. 일상 업무 중 단 하나의 반복적인 워크플로우를 선택하세요. 그 주변에 깔끔하고 방어적인 코드 하네스 (code harness)를 구축하고, 작업 내용을 확인할 수 있는 간단한 평가 (evaluation) 스크립트를 만들어 무엇이 일어나는지 살펴보세요. 영감은 훌륭하지만, 실제로 제품을 출시(ship)하게 만드는 것은 실용주의입니다.