프롬프트 엔지니어링의 시대가 끝났습니다

당신은 이미 그 패턴을 알고 있습니다. AI 에이전트에게 변수를 이름 바꾸기, 단위 테스트 작성, 또는 풀 리퀘스트 요약을 요청하면 훌륭하게 처리합니다. 하지만 수십 개의 파일, 여러 서비스 전반에 걸친 전체 기능 구현을 맡기고 일주일간 반복 작업을 요청하면, 조용히 중단된 브랜치, 깨진 테스트, 그리고 환상적인 API로 분해되어버립니다.

개발자들은 어쨌든 계속 도전하고 있습니다. 그들은 "자율" 코딩 에이전트를 구성하고, GitHub, Jira 및 테스트 러너를 연결한 다음, 시스템이 순환 리팩토링에서 멈추거나 20분 전에 본 요구 사항을 잊어버리는 것을 지켜봅니다. 벤치마크는 장난감 작업에서는 훌륭하게 보이지만, 실제 리포지토리에서는 에이전트들이 여전히 엣지 케이스를 놓치거나 성능이 저하되거나 보안 제약을 무시하는 경우가 있습니다.

그래서 Vibe Coding은 대부분 신화로 남아 있습니다. 판타지는 이렇습니다: 몇 문장으로 기능을 설명하고, 에이전트를 여러분의 모노레포에 연결한 다음, 깔끔한 PR, 통과된 CI, 그리고 성공적인 통합 테스트로 돌아오는 것입니다. 그러나 실제로는 모델이 규격에서 벗어나고, 장기적인 목표를 잃으며, 마지막에 제공했던 컨텍스트 윈도우에 과적합됩니다.

본질적으로, 원초적인 LLM의 성능은 2023년경부터 같은 속도로 급격히 증가하지 않았습니다. 더 넓은 컨텍스트 창과 더 나은 프롬프트가 도움이 되었지만, 핵심 신뢰성 문제인 부정확한 도구 사용, 컨텍스트 쇠화, 프로젝트 수준의 상태에 대한 진정한 개념 부족은 해결하지 못했습니다. 프롬프트 엔지니어링과 컨텍스트 엔지니어링은 한계를 밀어붙였지만, 구조를 변경하지는 않았습니다.

다른 차원이 조용히 등장하여 이를 해결하고 있습니다. 에이전트 하네스는 메모리, 도구 및 하위 에이전트에 대한 명시적인 제어 기능을 갖춘 모델을 감싸서, 자유롭게 대화하는 챗봇을 몇 시간 또는 며칠 동안 실제로 계획을 유지할 수 있는 시스템으로 바꿉니다. 앤트로픽의 오랫동안 운영된 하네스, 랑체인의 딥에이전트, 콜 메딘의 리니어 에이전트 하네스와 같은 프로젝트는 모두 같은 방향을 가리키고 있습니다.

이 시리즈는 그러한 변화의 내부를 조명합니다: 어떻게 Harness 기반 아키텍처가 드디어 에이전트를 신뢰할 수 있는 진지한 작업에 적합하게 만드는지, 여전히 문제가 발생하는 지점은 어디인지, 그리고 진정한 바이브 코딩이 단순한 데모에서 벗어나 기본으로 자리 잡기 위해 무엇이 필요한지를 다룹니다.

프롬프트 엔지니어링은 GPT-3와 대화하는 민속 과학으로 시작되었습니다. 개발자들은 단일 프롬프트에 집착하며 단어, 예시 및 출력 형식을 조정하여 단일 2,048 토큰 상호작용에서 더 나은 응답을 끌어내기 위해 노력했습니다. 작업의 단위는 하나의 요청, 하나의 응답, 기억 없이, 계획 없이 이루어졌습니다.

GPT-3.5와 GPT-4가 채팅과 더 큰 컨텍스트 창을 도입하면서 그 사고방식은 무너졌습니다. 컨텍스트 엔지니어링이 주도하기 시작했죠. 문제는 더 이상 "완벽한 프롬프트는 무엇인가?"가 아니라 "모델이 지금 100개 이상의 이전 메시지와 메가바이트의 문서 중에서 무엇을 봐야 하는가?"가 되었습니다. 팀들은 세션을 일관되게 유지하기 위해 시스템 프롬프트, 요약 및 검색 파이프라인을 조정하며 컨텍스트 소실과 싸웠습니다.

컨텍스트 엔지니어링은 AI 세션을 정교하게 조정된 대화처럼 다룹니다. 어떤 사양, 코드 조각, 결정이 컨텍스트 창에 남아 있고 어떤 것이 장기 저장소로 이동할지를 결정합니다. 벡터 검색, 계층적 요약, 역할 기반 시스템 메시지와 같은 도구들은 단일 긴 대화를 관리하기 위해 표준으로 자리잡았습니다.

에이전트는 프로그레션을 한 단계 끌어올리는 푸시를 활용합니다. 단일 호출이나 단일 세션을 최적화하는 대신, 하니스는 여러 세션을 조율하여 여러 에이전트를 통해 다수의 시간 또는 일수를 요하는 작업을 완료합니다. "이 기능을 처음부터 끝까지 배송하라"는 생각을 하세요, "이 기능을 리팩토링하라"는 것이 아닙니다.

현대의 에이전트는 여러 이동 부품을 동시에 조율합니다: - 다양한 역할을 가진 여러 LLM 세션 - 공유 및 에이전트별 메모리 저장소 - 코드 실행, 테스트 및 외부 API를 위한 도구 - 체크포인트, 롤백 및 인간 검토 게이트

Anthropic의 장기 실행 에이전트를 위한 효과적인 하네스, LangChain DeepAgents, 그리고 Cole Medin의 Linear Agent 하네스와 같은 프로젝트들은 모두 이 패턴을 따릅니다. 한 에이전트가 계획을 세우고, 다른 에이전트가 코드를 작성하며, 또 다른 에이전트가 테스트를 실행하고, 하네스는 수십 또는 수백 번의 호출에 걸쳐 상태를 추적합니다. 작업의 단위는 채팅 로그가 아닌 워크플로우 그래프가 됩니다.

중요하게도, 이것은 진화이지 망각이 아닙니다. 하네스는 여전히 각 호출 내에서 정교한 프롬프트 설계와 각 세션 내에서 규율 있는 컨텍스트 설계에 의존합니다. 이들은 단순히 이 기술들을 더 큰 프로그램의 저수준 원시 요소로 취급하며, 진짜 도전 과제는 여러 불완전한 에이전트를 하나의 신뢰할 수 있는 시스템으로 조정하는 것입니다.

원시 모델의 성능은 더 이상 2020년에 사람들이 상상했던 공상과학 그래프를 따르지 않습니다. GPT-3에서 GPT-4로의 발전은 "멋진 데모"에서 "이걸 직장에서 사용할 수 있을 것 같다"는 느낌으로 발전했지만, GPT-4.1, 4.1-mini, 그리고 Claude 3.5 Sonnet은 새로운 기계 지능의 IQ 클래스라기보다는 지연 시간, 비용, 신뢰성에서의 점진적인 상충을 나타냅니다.

벤치마크가 이를 뒷받침합니다. 학술 리더보드는 포화 상태에 이르렀고, 공급업체들은 조용히 MMLU 점수 자랑에서 "초당 토큰" 및 "달러당 요청"을 강조하는 방향으로 전환하고 있습니다. 여전히 더 나은 모델을 얻고 있지만, 그래프는 기하급수가 아닌 선형으로 보입니다.

AI 연구자들은 점점 더 조용한 부분을 소리 내어 말하고 있다: 확장 시대가 구조 시대에 접어들고 있다. 변환기에 10배 많은 GPU를 투입하는 것이 매년 얻는 이익이 줄어들고 있어, 실제로 중요한 것은 모델 주변의 시스템을 어떻게 구성하는지가 된다: 계획 루프, 메모리 레이어, 도구 라우터, 평가자, 그리고 인간 개입 체크포인트.

이 변화는 Anthropic이 장기 실행 에이전트에 대한 효과적인 하네스와 같은 깊이 있는 엔지니어링 문서를 작성하는 이유와 OpenAI, 구글, 메타가 단순히 더 큰 LLM(대형 언어 모델)이 아닌 “에이전트”를 밀어붙이는 이유를 설명해 줍니다. 최첨단 기술은 단일 불투명한 모델 호출에서 명시적인 상태와 제어를 갖춘 조정된 호출 네트워크로 이동하고 있습니다.

에이전트 하네스는 이 새로운 아키텍처 스택의 중심에 위치해 있습니다. 이들은 기능 요청을 단계로 나누고, 서브 에이전트를 조정하며, 메모리를 관리하고, 잘못된 결정을 피하기 위해 언제 인간에게 질문할지를 결정하는 중요한 작업을 수행합니다.

GPT-5가 마법처럼 완벽한 풀 리퀘스트를 보내주기를 기도하기보다는, 팀은 다음과 같은 하네스를 설계할 수 있습니다:

• 1코딩 표준과 테스트 게이트를 시행하다
• 2프로젝트 규모의 컨텍스트를 지속적으로 저장하고 검색하다.
• 3작업을 기획자, 개발자, 검토자 에이전트 간에 라우팅합니다.
• 4루프, 회귀, 및 스펙 드리프트 감지

그 제어 인터페이스는 개발자들이 다시 힘을 얻는 곳입니다. OpenAI의 훈련 과정을 변경할 수는 없지만, 얼마나 많은 에이전트를 생성할 것인지, 그들이 어떻게 대화할 것인지, 어떤 도구를 사용할 것인지, 그리고 언제 중단하고 스스로를 정당화해야 하는지를 결정할 수 있습니다.

에이전트 하네스, 즉 원시 모델 가중치가 아닌, 혁신을 위한 주요 캔버스가 됩니다. 다음 “10배” 성능 향상은 새로운 모델 카드처럼 보이지 않고, 더 견고하고 디버깅이 가능하며 생산 수준의 에이전트 아키텍처처럼 보일 것입니다.

원시 LLM 호출은 데모에서 인상적으로 보이지만, 의존할 수 있는 동료보다는 강력하지만 불안한 동물처럼 행동합니다. 에이전트 하네스는 그 모델에 감싸인 제어 시스템으로, 무작위 텍스트 예측을 신뢰할 수 있는 소프트웨어와 비슷한 것으로 변환합니다. 이는 에이전트가 기억하는 방식, 사용하는 도구, 다른 에이전트와 협업하는 방식, 그리고 단일 대화 차원이 아닌 몇 시간 또는 며칠 동안 목표에 맞게 유지하는 방식을 정의합니다.

LLM을 경주마로 생각해 보세요: 빠르고 강력하며 당신의 스프린트 백로그에는 전혀 관심이 없습니다. 제어 장치는 그 힘을 예측 가능한 움직임으로 제한하는 고삐, 굴레, 안장을 의미합니다. 이것이 없으면 무작위로 코딩된 전사와 허구의 API가 나타나고, 이것이 있으면 실제로 기능을 배포하고, 테스트를 실행하며, 팬 픽션으로 탈선하지 않고 문서를 업데이트할 수 있는 코딩 에이전트를 얻을 수 있습니다.

하네스의 첫 번째 작업: 메모리 관리. LLM은 여전히 제한된 컨텍스트 창에서 작동합니다—최대 128K 토큰, 필요할 경우 200K까지—그래서 하네스는 어떤 것을 유지하고, 어떤 것을 요약하며, 어떤 것을 잊을지 결정합니다. Manus와 Anthropic의 자체 하네스와 같은 시스템은 “컨텍스트 부패”와 치열하게 싸우며, 오래된 지침을 정리하고 현재 중요하지 않은 정보를 제외하고, 지금 당장 중요한 저장소 조각, 티켓 및 이전 결정을 가져오기 위해 검색을 활용합니다.

두 번째 작업: 도구 제어. 현대 에이전트는 파일 시스템에서 CI 파이프라인까지 모든 것을 호출합니다. 원시 모델은 프롬프트가 자극을 주면 기꺼이 `rm -rf` 명령으로 당신의 리포를 삭제할 것입니다. 허브는 이러한 기능을 제어합니다: 도구를 호출할 시점, 출력의 유효성을 검증하고 “커밋 전에 테스트를 통과해야 한다”거나 “인간의 승인 없이 프로덕션에 손대지 않아야 한다”는 정책을 시행합니다.

셋째, 이 시스템은 전문 하위 에이전트를 조정합니다. 전체 기능을 “완전히 수행”하려고 하는 하나의 거대한 프롬프트 대신, 다음과 같은 패턴을 볼 수 있습니다: - 사양을 작업으로 변환하는 기획자 에이전트 - 파일을 수정하는 코더 에이전트 - 테스트를 실행하고 해석하는 테스터 에이전트 - 스타일과 아키텍처를 준수하도록 강제하는 리뷰어 에이전트

마지막으로, 하네스는 오랜 실행 작업을 원활하게 유지합니다. 이들은 글로벌 상태를 추적하고, 루프를 감지하며, 체크포인트를 설정하고, 인간을 위한 의사 결정 지점을 도출합니다. 원시 LLM 호출은 상태가 없고 기억력이 없지만, 하네스가 적용된 에이전트는 수백 번의 호출을 통해 작업을 수행할 수 있으며, 하룻밤 동안 일시 중지하고 내일 다시 시작해도 이전 테스트 실행에서 어떤 엣지 케이스가 실패했는지를 정확히 알고 있습니다.

현대의 하니스는 일반적으로 초기화 에이전트로 열리며, 이는 챗봇보다는 프로젝트 관리자와 더 유사한 방식으로 작동합니다. 초기화 에이전트는 사용자 사양을 읽고, 저장소나 환경을 검사한 후, 구체적인 계획을 수립합니다: 이정표, 사용할 도구, 수정할 파일, 그리고 명시적인 성공 기준을 포함합니다. Anthropic의 하니스는 이를 “초기화자–코더” 분할로 설명하며, 초기화자는 어떤 코드 변경이 이루어지기 전에 범위를 확정합니다.

초기화가 완료되면, 실제 작업을 수행하는 작업 에이전트로 제어가 넘어갑니다. 이 에이전트는 루프에서 실행되며, 단일 스텝을 수행하고 도구를 실행한 다음 대다수의 컨텍스트 창을 제거합니다. 각 루프 반복에서는 모델이 200개의 메시지 채팅 로그에 잠기지 않도록 메모리에서 상태를 충분히 재구성합니다.

그 루프는 일반적으로 자유 형식의 대화라기보다는 엄격한 제어 시스템처럼 보입니다. 작업 에이전트는: - 현재의 계획 조각과 관련 파일을 메모리에서 불러옵니다. - 변경 사항이나 작업을 제안합니다. - 도구를 실행합니다 (테스트, 린터, 컴파일러, HTTP 호출). - 결과와 차이를 다시 기록한 후 반복합니다.

가드레일은 모든 반복 주위를 감쌉니다. 사전 실행 검사는 에이전트의 다음 작동이 계획 및 허용된 도구와 일치하는지 확인하며, 사후 실행 검사는 “테스트는 통과해야 한다” 또는 “로그에 비밀 정보가 없어야 한다.”와 같은 제약 조건에 따라 출력을 검증합니다. LangChain DeepAgent 및 OutSystems Agent Workbench와 같은 시스템은 이러한 검사를 정책으로 내장하여 하드 실패를 유발하거나 인간 검토를 요청할 수 있습니다.

체크포인트는 하니스에 척추를 제공합니다. 의미 있는 진행 후—예를 들어, 통과된 테스트 스위트나 완료된 API 통합—하니스는 상태를 스냅샷으로 기록합니다: 계획 위치, 파일 해시, 도구 출력 및 주요 결정들. 만약 에이전트가 나중에 오류를 일으키거나 파일을 손상시키면, 하니스는 무엇이 잘못되었는지 추측하는 대신 마지막으로 성공한 체크포인트로 롤백할 수 있습니다.

전달은 전문화된 에이전트 간에 문맥을 이동시킵니다. 계획 에이전트는 구조화된 작업 그래프를 코딩 에이전트에게 전달할 수 있고, 코딩 에이전트는 패치와 테스트 계획을 검토자 에이전트에게 전달할 수 있습니다. 각 전달은 엄격한 스키마를 사용하여 에이전트가 모호한 문장을 주고받는 것이 아니라 기계에서 검증 가능한 상태를 전달하도록 합니다.

이 모든 것은 심각한 메모리 레이어 없이는 작동하지 않습니다. 현대의 하네스는 코드와 문서에 대해 RAG에 의존하고, 결정을 위한 장기 저장소와 맥락 부식을 방지하기 위한 요약 또는 임베딩을 통한 메모리 압축을 사용합니다. 사람의 개입이 필요한 중단점이 이러한 스택 위에 자리 잡고, 위험한 행동에 대한 승인을 위해 루프를 일시 중지합니다—스키마 마이그레이션, 결제 흐름, 또는 보안 민감한 리팩토링—따라서 뱃지 코딩이 조용히 재앙을 발생시키지 않도록 합니다.

앤트로픽은 진지하고 장기적인 코드 에이전트를 위한 가장 명확한 청사진 중 하나를 조용히 발표했습니다: 클라우드를 수다스러운 자동 완성과는 다르게 주니어 엔지니어에 가까운 존재로 만드는 장치입니다. 그들의 장기 에이전트 하니스는 참신함을 쫓지 않고, 계획, 실행, 검증을 체계화하여 모델이 이야기를 잃지 않고 여러 시간에 걸친 코딩 작업을 수행할 수 있게 합니다.

핵심에는 기술 리더처럼 행동하는 초기화 에이전트가 있습니다. 이는 폭넓은 사양을 수집하고, 리포를 검사하며, 제약 조건을 나열하고, 구체적인 작업, 파일 수정 목록, 의존성 노트 및 수용 기준을 포함한 구조화된 계획을 생성합니다. 이 계획은 파일을 편집하고, 도구를 호출하며, 테스트를 실행하는 더 낮은 수준의 코더 에이전트와의 계약이 됩니다.

Anthropic의 하니스는 상태를 사후 고려가 아닌 일급 문제로 취급합니다. 모든 것을 거대한 컨텍스트 윈도우에 담는 대신, 다음을 유지합니다: - 표준 작업 그래프 및 체크리스트 - 파일 수준의 이력 및 차이 - 이전 도구 호출 및 테스트 실행의 요약

초기화 프로그램은 이 상태를 기록하고, 코더는 이 상태의 조각을 읽은 후 미래의 호출이 검색할 수 있는 새로운 아티팩트를 추가합니다. 이러한 패턴은 시스템이 여러 개의 작고 집중된 컨텍스트 창을 넘나들면서도 하나의 지속적인 세션처럼 작동할 수 있도록 해줍니다.

도구가 전체를 하나로 묶습니다. 코더 에이전트는 파일 수정을 망상하지 않으며, 명시적인 도구를 호출합니다: - 파일 읽기 및 쓰기 - 단위 및 통합 테스트 실행 - 린터 및 포맷터 실행

각 도구 호출은 구조화된 출력을 반환하며, 이를 하네스가 기록하고 요약하여 선택적으로 맥락에 다시 피드백합니다. 예를 들어, 실패한 테스트는 코더가 처리해야 하는 명확한 버그 보고서가 되며, 하네스가 작업을 완료로 표시하기 전에 해결해야 합니다.

자기 검증은 모든 곳에 존재합니다. 초기화기는 원래 사양에 대해 자신의 계획을 비판하고, 코더는 계획에 대한 차이점을 비판하며, 하니스는 테스트가 실패하거나 커버리지 격차가 나타날 때 진행을 차단하는 제어 루프를 시행합니다. 인간 체크포인트는 고위험 변경에 대해 동일한 루프에 삽입될 수 있습니다.

Anthropic의 디자인은 일반 하네스 청사진과 거의 일대일로 매핑됩니다: 내구성 있는 메모리, 명확한 도구, 특화된 하위 에이전트 및 밀접한 제어 루프. Linear-Coding-Agent-Harness와 같은 프로젝트는 같은 패턴을 반영하며, 이는 '바이브 코딩'을 단순한 파티 트릭 이상의 것으로 만들고자 하는 모든 이에게 사실상 표준 아키텍처로 자리 잡아가고 있습니다.

바이브 코딩은 항상 공상과학처럼 들렸습니다: "바이브"라는 기능을 설명하고, 커피를 마시러 갔다가 돌아오면 완료된 풀 리퀘스트를 만나는 것입니다. 에이전트 하네스 덕분에 그 판타지가 현실에 가까워졌지만, "어느 정도"만 그렇습니다. 이제 에이전트를 Git 리포지토리에 지시하면 계획을 세우고, 편집하고, 테스트를 실행하며, 몇 시간 동안 매번 키 입력을 확인하지 않고도 반복할 수 있습니다.

하네스는 원시 모델을 제어 시스템으로 감싸면서 이를 가능하게 합니다. 잘 설계된 하네스는 도구(git, 테스트 실행기, 린터)를 관리하고, 수십 또는 수백 번의 호출에 걸쳐 상태를 추적하며, 체크포인트를 강제합니다. 예를 들어, Anthropic의 장기 코딩 하네스는 초기화 에이전트를 사용하여 계획을 설정한 다음, 구현 및 검증을 다루기 위한 코더-테스터 루프를 사용합니다.

무지개와 데이지는 그곳에서 멈춥니다. 완전 자율적 vibe 코딩은 혼란스러운 모노리스, 누락된 테스트 또는 모호한 제품 요구 사항을 만났을 때 여전히 충격을 줍니다. 하네스는 이미 갖고 있는 어떤 엔지니어링 규율도 증폭시키지만, 이를 대체하지는 않습니다.

성공은 잘 구조화된 코드베이스와 풍부한 도구와 강한 상관관계를 가지고 있습니다. 실제로 기능을 안정적으로 배포하는 에이전트는 다음과 같은 환경에서 활동하는 경향이 있습니다: - 높은 테스트 커버리지와 빠른 피드백 (초 단위, 분 단위가 아님) - 엄격한 린터와 포매터 (ESLint, Prettier, Ruff) - 명확한 모듈 경계와 타입이 지정된 API (TypeScript, mypy)

인간이 참여하는 과정은 중요한 모든 것에 대해 협상 불가능합니다. 가장 효과적인 바이브 코딩 설정은 중요한 체크포인트에서 인간을 삽입합니다: 초기 계획 검증, 아키텍처 변경 승인, 위험한 이전 검토, 그리고 풀 리퀘스트 병합. 콜 메딘의 자체 하네스 예제들은 맹목적인 자동 병합 파이프라인보다 명확한 검토 단계를 중시합니다.

그래서 분위기 코딩이 "다시 돌아왔지만", 마법이 아닌 워크플로우로 돌아왔습니다. 당신은 그루밍 작업—파일 수정, 고정 템플릿, 리팩토링—을 맡기면서 의도, 아키텍처, 그리고 대안들에 대한 흐름을 유지합니다. 설정하고 잊어버리는 에이전트의 환상은 기다릴 수 있습니다; 실제 버전은 오늘 출고되며, 당신이 그에 맞는 하니스와 코드베이스를 설계하기만 하면 됩니다.

하네스에 감싸인 에이전트들은 여전히 어려운 문제에 부딪힙니다: 시간에 따른 정렬. 짧은 프롬프트는 기준을 유지할 수 있지만, 500단계에 걸친 코딩 마라톤은 그럴 수 없습니다. Anthropic의 초기화자-코더 루프나 LangChain의 DeepAgent를 사용하더라도, 모델은 조용히 요구 사항을 재해석하고, 데이터 모델을 재창조하거나, 원래 지침에서 비협상적인 제약 조건을 "최적화"해 버립니다.

정렬 드리프트는 미묘한 방식으로 나타납니다. 코딩 에이전트는 리팩토링 중간에 REST를 GraphQL로 교체할 수 있거나, 테스트가 통과한 후 성능 예산을 무시할 수 있습니다. 헬멧은 보호 장치를 추가합니다—체크포인트, 자기 비판, 회귀 테스트—그러나 버그 없는 방법은 없습니다, 대규모의 확률적 모델이 툴 사용의 여러 시간이나 며칠 동안 아키텍처와 제품 사양에 충실하도록 유지하는 방법은 없습니다.

더욱 어려운 것은: 정렬이 변화하는 맥락 속에서도 견뎌야 한다는 것이다. 요구 사항은 실행 중에 변화하고, 인간은 부분적인 피드백을 제공하며, 외부 시스템은 실패한다. 오늘날의 시스템은 휴리스틱을 사용하여 의도를 근사화한다—“인증을 건드리지 마세요,” “이 디렉토리는 절대 수정하지 마세요,” “매 N 스텝마다 테스트를 실행하세요”—그러나 여전히 “사용자 경험의 일관성 유지”나 “이 코드베이스를 관용적인 상태로 유지”와 같은 더 높은 수준의 목표는 놓치고 있다.

그렇다면 진지한 하네스를 구축하는 비용이 있습니다. 생산 수준의 시스템은 다음이 필요합니다: - 지속적인 상태 및 메모리 저장소 - 도구 오케스트레이션 (편집기, 테스트 실행기, CI, 티켓팅, 관찰성) - 안전 검사, 롤백 경로 및 사람 개입 검토 - 도메인 특화 평가자 및 메트릭

그 스택은 프롬프트라기보다는 새로운 제품처럼 보입니다. Anthropic의 오랜 하네스는 여러 에이전트, 계획 단계 및 검증 레이어를 아우르며, Cole Medin의 Linear 에이전트 하네스는 Git, 이슈 트래커 및 코드 실행을 연결합니다. 이러한 것들은 SDK에서 "무료로" 제공되지 않습니다.

보편적이고 모든 사람에게 맞는 하네스 표준은 아직 존재하지 않습니다. 핀테크 백엔드, 리액트 디자인 시스템, 데이터 과학 노트북 파이프라인은 각각 다른 도구, 다른 안전 점검, 그리고 "완료"의 다른 정의를 원합니다. LangChain DeepAgent와 OutSystems Agent Workbench와 같은 프레임워크는 통합의 가능성을 암시하지만, 여전히 각 팀과 도메인에 따라 많은 커스터마이징을 필요로 합니다.

거부의 원인보다는, 이 두 가지 장애물이 다음 경계를 나타냅니다. 이제 경쟁은 약간 더 똑똑한 모델이 아니라, 진동 코딩을 가끔씩 신비롭게 만드는 것 대신 지루할 정도로 신뢰할 수 있는 정렬 인식형 재사용 가능한 하네스를 만드는 것입니다.

먼저 당신의 에이전트를 상태 유지 워크플로우로 설계하세요, 마법 같은 프롬프트가 아니라. 구체적인 단계들을 적어보세요: 사양 입력, 계획, 구현, 테스트, 리팩토링, 배포, 그리고 검토. 당신의 하네스는 이러한 단계들 간에 상태를 이동시키고, LLM을 호출할 시점과 인간을 참여시킬 시점을 결정하는 계층이 됩니다.

실제 예시로 LangChain의 DeepAgents가 가장 접근하기 쉬운 곳입니다. DeepAgents는 플래너, 실행자, 비평가를 어떻게 연결하는지를 보여주며, 도구 사용과 메모리를 단일 호출이 아닌 루프에 결합하여 구성합니다. 이를 통해 리포 전체 리팩토링이나 다중 서비스 API 통합과 같은 다단계 작업을 어떻게 관리하는지 추적할 수 있습니다.

Cole Medin의 자체 Linear Coding Agent Harness는 GitHub에서 더욱 강력한 청사진입니다. 이는 Linear 문제를 감싸는 코딩 에이전트를 제공하여 티켓 읽기, 변경 계획, 파일 편집, Linear에 업데이트를 다시 게시하는 구체적인 흐름을 제시합니다. 체크포인트, 오류 처리, 모델이 사양에서 벗어날 때 복구하는 방법과 같은 실제 패턴을 제공합니다.

기업 스택에서 작업한다면, OutSystems Agent Workbench는 추상화 수준을 더욱 높여줍니다. 이 도구는 안전장치, 관찰 가능성, 사람의 승인 과정을 통합하여 “검토 없이 운영환경을 건드리지 않는다” 또는 “병합 전에 테스트 통과가 필요하다”와 같은 정책을 정의할 수 있게 합니다. Cisco의 Outshift 팀은 기업이 AI 에이전트를 활용하여 더 스마트한 자동화를 구현할 수 있는 방법에서 생산 시스템에 대한 유사한 패턴을 매핑합니다.

하네스 디자인을 프로그래밍 아키텍처 문제로 간주하고, 단순한 프롬프트 조정으로 생각하지 마세요. 에이전트의 장기 상태(작업 그래프, 파일, 티켓)를 식별하고, 도구(레포 접근, CI, 문서 검색) 및 안전 장치(테스트, 린터, 인간 검토)를 확인하세요. 그런 다음, 모델이 “기억”하기를 바라지 말고, 이를 명시적인 상태와 전환으로 정형화하세요.

실용적인 시작 레시피는 다음과 같습니다: - 사양을 작업 목록으로 변환하는 계획자 에이전트 - 코드를 수정하고 도구를 실행하는 실행자 에이전트 - 차이점과 테스트 결과를 비평하는 리뷰어 에이전트 - 재계획 또는 에스컬레이션 시점을 결정하는 제어 루프

이러한 방식으로 생각하게 되면, 프롬프트 엔지니어링은 실제로 신뢰성을 소유하는 하네스 내부의 구현 세부사항이 됩니다.

프롬프트 엔지니어링은 좋은 시기를 보냈지만, 중심이 이동했습니다. 이제 힘은 오케스트레이션에 있습니다: 기억, 도구, 하위 에이전트, 그리고 인간 체크포인트를 관리하는 에이전트 하네스가 있어, 단일 LLM 호출이 영리한 자동완성 트릭이 아니라 일관된 장기 실행 시스템이 됩니다.

우리는 AI가 소프트웨어와 같은 경로를 따라가는 것을 목격하고 있습니다. 초기의 손으로 조정된 프롬프트 "스크립트"는 강력한 시스템 공학으로 바뀌고 있습니다: 기획자, 검증자, 회귀 테스트, 원격 측정, 롤백 등이 포함되어 있으며, 이 모든 것이 세대별로 10배가 아닌 10~20% 더 나은 모델 주위에 포장되고 있습니다.

두 가지 주요 장애물인 긴 시간 범위 정렬과 아키텍처 충실도를 해결하면, 에이전트는 더 이상 장난감이 아닌 전체 워크플로우를 주도하게 됩니다. 잘 설계된 시스템은 원칙적으로 전체 성장 루프, 끝에서 끝까지의 온보딩 퍼널, 또는 50만 줄의 코드베이스에 대한 다개월 리팩터링을 규격에 맞게 실행할 수 있습니다.

그때 "AI 코딩 도우미"는 "AI 엔지니어링 팀 멤버"로 변모합니다. 이와 같은 패턴은 과학적인 작업에도 이어집니다: 문헌 검색, 시뮬레이션 캠페인, 수천 개의 LLM 호출에 걸쳐 연결된 실험 계획이 제약을 강제하고, 결정을 기록하며, 인간에게는 중요한 분기만을 드러내는 방식으로 진행됩니다.

이 에이전트 시대에서 성공하는 개발자는 프롬프트 해킹을 암기하는 사람이 아니라 제어 시스템을 설계하는 사람입니다. 당신의 일은 모델과 대화하는 것에서 벗어나, 며칠 또는 몇 주 동안 자율적으로 운영될 수 있는 기획자, 비평가, 도구 라우터 및 검토 게이트를 구축하는 것으로 변화합니다.

작은 것부터 시작하되, 지금 시작하세요. Anthropic의 오랜 하네스, Cole Medin의 Linear 에이전트 하네스, LangChain의 DeepAgent, 또는 Manus의 컨텍스트 엔지니어링 패턴을 활용하여 오늘 자신이 소유하고 있는 고통스러운 워크플로우 하나에 대한 하네스를 연결해보세요.

그런 다음 그것을 측정하고, 분해하고, 강하게 하십시오. AI의 다음 레버리지 물결은 모델을 조율하는 사람들에게 속하며, 단순히 프롬프트를 전달하는 사람들에게는 해당하지 않습니다.

AI 에이전트 하니스란 무엇인가요?

에이전트 하니스는 메모리 관리, 도구 제어, 하위 에이전트 조정 및 상태 유지를 위한 AI 에이전트 주위에 구축된 시스템으로, 복잡하고 장기간 진행되는 작업을 신뢰할 수 있게 수행할 수 있도록 합니다.

에이전트 하네스와 프롬프트 엔지니어링은 어떤 점에서 다른가요?

프롬프트 엔지니어링은 LLM과의 단일 상호작용을 최적화합니다. 에이전트 하네스는 많은 상호작용과 컨텍스트 윈도우를 조율하여 더 큰 프로젝트를 완성하는 전체 아키텍처로, 그 구조 안에 프롬프트 및 컨텍스트 엔지니어링 기법을 통합합니다.

에이전트 하네스를 사용한 '바이브 코딩'이 가능할까요?

에이전트 하네스는 에이전트를 더 신뢰할 수 있게 만들어 '바이브 코딩'(손쉬운 기능 구현)에 더 가까이 다가가게 합니다. 그러나 완전히 해결된 것은 아닙니다; 복잡한 작업은 여전히 인간의 검증과 잘 설계된 가드레일을 필요로 합니다.

왜 에이전트 하네스가 지금 중요해지고 있나요?

LLM의 원초적인 힘이 정체기를迎 하면서 혁신은 그 주위에 구축된 시스템으로 이동하고 있습니다. 하네스는 기업 수준의 자율 에이전트를 위한 다음 단계의 능력을 열기 위해 필요한 구조를 제공합니다.