프롬프트 엔지니어링으로 아키텍처 문제를 해결하려 하지 마세요. '하네스'가 필요합니다.

요약: AI 에이전트가 격리된 환경에서는 완벽하게 작동하지만 프로덕션에서 무너진다면, 문제는 프롬프트가 아닙니다. LLM을 둘러싼 결정론적인 시스템 아키텍처, 즉 '하네스(Harness)'가 없는 것입니다. AI가 스스로 재시도 로직을 결정하게 두지 마세요.

'바이브 코딩(vibe coded)' 프로젝트가 잘못되는 과정에서 계속 보이는 패턴이 있습니다.

AI는 깔끔한 코드를 작성하고 개별 기능은 잘 작동합니다. 하지만 어느 순간, 아무도 설명할 수 없는 방식으로 전체 시스템이 오작동하기 시작합니다. 3주 전에 에이전트가 잘못 처리했던 엣지 케이스가 계속 반복되고, '완료'된 작업이 다시 시도됩니다.

시스템 프롬프트를 아무리 수정해도 해결되지 않습니다. 2026년 최근 데이터에 따르면, 엔터프라이즈 AI 에이전트 프로젝트의 88%가 바로 이 이유로 프로덕션 단계에 도달하지 못합니다.

현재 안정적인 AI 제품을 출시하는 개발자들은 마법 같은 프롬프트를 작성하는 것이 아닙니다. 그들은 Mitchell Hashimoto가 최근 명명한 '하네스 엔지니어링(Harness Engineering)'을 구축하고 있습니다.

풀스택 개발자에게 이것이 실제로 무엇을 의미하는지 설명하겠습니다.

🧠 핵심 개념: 뇌 vs 몸

"에이전트 = 모델 + 하네스"

LLM 네이티브 개발에는 원하는 것을 설명하기만 하면 AI가 오케스트레이션을 처리할 것이라는 위험한 가정이 있습니다. 그것은 아키텍처가 아니라 기도일 뿐입니다. 작업 라우팅, 장애 처리, 상태 관리는 고전적인 컴퓨터 과학 문제입니다. 이것들은 결정론적이어야 합니다.

뇌와 몸을 엄격하게 분리해야 합니다.

• 뇌 (LLM 레이어): 컨텍스트를 기반으로 다음에 어떤 작업을 수행할지 결정하고, 결과물이 품질 기준을 충족하는지 평가하며, 수정을 위한 피드백을 제공합니다.
• 몸 (하네스 레이어): 그 외의 모든 것을 결정론적으로 처리합니다.

LLM이 똑똑해질수록 하네스는 더욱 중요해집니다. 100배 더 유능한 모델은 복잡한 실수를 자신 있게 저지를 수 있는 능력도 100배 더 큽니다. LLM은 추론과 판단에는 뛰어나지만, 일관성과 상태 인식에는 끔찍할 정도로 취약합니다.

⚙️ 놓쳐서는 안 될 4가지 CS 필수 요소

에이전트가 자율적으로 하나 이상의 작업을 수행한다면, 다음과 같은 기본적인 백엔드 개념이 필요합니다.

1. 상태 머신 (척추): 모든 작업은 알려진 상태(pending, in_progress, done, failed)에 있어야 합니다. 이를 추적하지 않으면 에이전트는 재시작할 때마다 진행 중인 작업을 가져와 중복 실행할 것입니다.
2. 멱등성 가드 ("완료는 완료"): 모든 작업에는 멱등성 키가 필요합니다. 네트워크 타임아웃으로 재시도가 트리거되어도 에이전트가 사용자의 신용카드를 두 번 결제해서는 안 됩니다.
3. DAG (방향성 비순환 그래프): 간단한 의존성 맵입니다. 작업 A가 완료될 때까지 작업 B는 실행될 수 없습니다. 이것이 없으면 에이전트는 마이그레이션이 실행되기도 전에 데이터베이스 테이블에 쓰기를 시도할 것입니다.
4. 우선순위 및 데드 레터 큐: 에이전트가 아니라 하네스가 무엇을 먼저 처리할지 결정합니다. 작업이 3번 실패하면 데드 레터 큐로 보내서 디버깅할 수 있게 해야 합니다. 그냥 허공으로 사라지게 두지 마세요.

🛠️ 최소 기능 하네스 (솔로 풀스택 앱용)

Temporal이나 Prefect 같은 거대한 오케스트레이션 플랫폼은 필요 없습니다. 다음만 있으면 됩니다.