TL;DR

  • 에이전트 루프와 컨텍스트 엔지니어링 다음 단계로, 도메인별 소프트웨어 생산·검증·개선을 지속하는 소프트웨어 팩토리가 부상하며, 그 기반은 하네스 엔지니어링임.
  • 컨텍스트 자동 압축·재구성·저장과 모델의 속도·비용 개선으로, 첫 시도보다 결과를 자동 검증하고 품질 보증(QA)을 통과할 때까지 반복하는 과정의 중요성이 커짐.
  • 도메인 지식, 규칙, 워크플로, 테스트를 공장에 표준화하면 규제나 보안 표준 변경의 영향을 파악하고 필요한 수정이나 작업 항목을 도출할 수 있음.
  • 공장 운영에는 장시간 작동하는 지속형 에이전트, 개인의 엔지니어링 취향을 반영하는 QA, 자동화된 검토가 필요하며 개인 역할도 작업물 검사에서 공정 설계로 이동함.
  • 더 많은 데이터와 접근 권한을 에이전트에 제공하게 될수록 셀프 호스팅과 보유 하드웨어의 추론 효율을 높이는 Magnitude 같은 기술의 중요성이 커짐.

하네스 엔지니어링의 부상

  • 에이전트 루프, 컨텍스트 엔지니어링, 스킬 다음에 올 흐름으로 하네스 엔지니어링과 도메인 내 소프트웨어 팩토리가 두드러지고 있음.
  • 전통적인 컨텍스트 엔지니어링의 이점은 점차 줄어들 수 있음. 이는 컨텍스트가 덜 중요해져서가 아니라, 추론 과정에서 컨텍스트를 자동으로 압축·재구성·저장하거나 동적으로 조정하려는 접근이 늘고 모델이 더 빠르고 저렴해지고 있기 때문임.
  • 따라서 처음부터 모든 것을 정확히 맞추는 일보다 결과가 올바른지 자동으로 확인하고 QA를 통과할 때까지 절차를 이어가는 역량이 중요해짐.
  • 컨텍스트 관리, 도구 선택, 실행, 저장, 라우팅, 평가, 복구, 피드백 루프가 모델을 둘러싼 명시적 시스템의 구성 요소가 되고 있음.
  • DeepSeek의 Desktop Harness는 이 방향으로 나아가는 사례이며, 플러그인 아키텍처를 갖춘 Cordis는 이러한 시스템을 모듈식으로 구성하는 방법을 보여줌.
  • 하네스 자체를 최적화하는 메타 하네스 접근도 등장하고 있으며, FrontierHarness는 하네스 품질을 평가하는 전용 평가 체계를 제공함.

도메인별 소프트웨어 팩토리

  • 다음 단계는 에이전트가 개별 작업을 완료하는 데 그치지 않고, 특정 도메인에서 소프트웨어를 지속적으로 생산·검증·개선하는 생산 공정을 구축하는 것임.
  • 매 프로젝트마다 라이브러리, 서비스, 문서, 규칙, 지식을 다시 찾아내는 대신 팩토리에 다음 요소를 담을 수 있음.
  • 재사용 가능한 도구와 서비스
  • 표준화된 에이전트 워크플로
  • 최신 도메인 문서
  • 아키텍처 규칙과 보안 요건
  • 규제 요건과 사용자 경험(UX) 표준
  • 자동화된 테스트, 평가, 검토 루프
  • 아래에 연결한 Game Factory는 이런 팩토리의 개념을 이해하기 쉽게 보여주는 사례임. 게임 자체가 핵심 적용 분야라는 뜻은 아님.
  • 기업 환경에서는 중앙 집중식 모바일 UX 지식 베이스, FINMA 지식 베이스, 보안 규칙 등 도메인별 목록이 마련될 수 있음. 각 제품은 적용되는 요건과 현재 충족하는 요건을 주로 명시하게 됨.
  • 규제 요건이나 보안 표준이 바뀌면 팩토리가 영향을 받는 제품을 자동으로 파악하고, 필요한 변경 사항이나 최소한 구체적인 작업 항목을 도출할 수 있음.
  • 실질적으로 유용한 팩토리 템플릿이 등장하는 지점에서 약속된 10배 생산성 향상을 처음 체감할 수 있다는 전망임.

개인의 역할과 지속형 에이전트

  • 개별 기여자(IC)의 역할은 점차 공장 현장의 QA 담당자이자 공정 설계자로 바뀜.
  • 모든 작업물을 직접 살펴보는 시간은 줄고, QA 실패의 원인, 생산 공정에서 잘못 작동하는 단계, 공정에서 바꿔야 할 부분을 파악하는 데 더 많은 시간을 쓰게 됨.
  • 한 계층의 신뢰성이 확보되면 한 단계 위로 올라가 다음 부분의 자동화를 시도할 수 있음. 이를 충분히 밀고 나가면 모두가 자기만의 작은 공장을 운영하는 CEO처럼 행동하게 되며, 그보다 더 높은 단계에서 벌어질 일은 아직 알 수 없음.
  • 다만 이러한 팩토리가 작동하려면 에이전트의 지속성이 크게 높아져야 함. 목표가 ‘이 작업을 완료하기’에서 ‘이 생산 공정을 계속 운영하기’로 바뀌면 몇 시간, 며칠, 또는 잠재적으로 무기한 작동하는 에이전트가 필요해짐.
  • 이 때문에 Pi Durable 같은 개발이 흥미로우며, OpenClaw를 사용하고 싶지 않은 경우에는 Dots, Grokbot과 유사한 접근도 선택지임.

엔지니어링 취향과 개인 QA

  • 에이전트가 더 많은 일을 자율적으로 생산할수록 기능적 정확성만으로는 충분하지 않음.
  • 에이전트는 받아들일 수 있는 코드의 유형, 선호하는 추상화, 일반적으로 선택하는 절충안, 기술적으로 작동하더라도 개인 QA에서 탈락할 지점을 이해할 필요가 있음.
  • 최근의 ‘Matter of Taste’와 ‘Taste Driven’ 논의도 이 문제와 맞닿아 있음.
  • 이상적으로는 단순한 비서가 아니라 개인의 엔지니어링 취향을 점점 더 반영해, 개입 없이 개인 QA를 통과하는 결과물을 더 많이 생산하는 비서를 구축하는 것임.

셀프 호스팅과 하드웨어 효율

  • 이런 시스템의 성능을 높이려면 더 많은 컨텍스트, 저장소, 내부 정보, 접근 자격 증명, 나아가 개인의 업무 패턴까지 제공해야 할 수 있음. 이 때문에 셀프 호스팅이 다시 흥미로운 선택지가 됨.
  • 하드웨어가 부족하고 비싸지는 동시에, 이미 보유한 하드웨어에서 얼마나 많은 성능을 끌어낼 수 있는지도 중요해짐.
  • Magnitude는 사용 가능한 하드웨어에 맞춰 로컬 추론을 최적화하며 기존 하네스 아래에서 작동할 수 있는 사례임.

현재의 논지와 참고 링크