코딩 에이전트의 다음 경쟁력은 프롬프트가 아니라 컨텍스트와 하네스 엔지니어링이다

먼저 답부터

AI 에이전트 개발은 “프롬프트를 어떻게 잘 쓰느냐”에서 “에이전트가 일할 수 있는 환경을 어떻게 설계하느냐”로 이동하고 있습니다. 예전에는 모델에게 좋은 지시문을 주는 것이 핵심처럼 보였습니다. 하지만 에이전트가 파일을 읽고, 도구를 호출하고, 코드를 고치고, 실행 결과를 확인하는 단계로 들어오면서 문제는 더 복잡해졌습니다.

이제 중요한 질문은 “어떤 문장으로 지시할까”만이 아닙니다. “지금 모델이 판단하는 데 필요한 정보가 들어 있는가”, “반복 작업을 매번 설명하지 않고 재사용할 수 있는가”, “에이전트가 만든 결과를 어떻게 검증할 것인가”가 더 중요해지고 있습니다.

그래서 Prompt Engineering 다음에는 Context Engineering이 등장했고, 그다음에는 Agent Skills와 Harness Engineering 같은 실행 구조의 중요성이 커지고 있습니다. 이 글에서 말하는 Harness Engineering은 에이전트가 실제 업무를 수행하도록 도구, 메모리, 테스트, 권한, 실패 복구를 묶어 설계하는 관점입니다.

사실 확인: 상용 제품처럼 단정하지 않기

이 글에서 다루는 Stitch Agent Skills는 공개 GitHub 저장소 기준으로 Stitch MCP 서버와 함께 동작하도록 설계된 Agent Skills 라이브러리입니다. 다만 공식 지원 Google 제품은 아니므로, 정식 상용 제품처럼 표현하기보다는 공개 자료 기준의 실험적 프로젝트로 이해하는 편이 안전합니다.

Agent Skills는 쉽게 말해 에이전트가 특정 작업을 더 잘 수행하도록 절차, 예시, 참고 자료, 스크립트, 검증 기준을 한 폴더에 묶어두는 방식입니다. 핵심은 에이전트가 모든 내용을 처음부터 다 읽는 것이 아니라, 필요한 순간에 관련 스킬을 불러와 사용한다는 점입니다.

GenericAgent 논문은 긴 컨텍스트 자체보다, 제한된 컨텍스트 안에 중요한 정보를 얼마나 잘 남기는지가 중요하다고 주장합니다. 다만 논문과 공개 저장소의 주장이라고 해서 모든 기업 환경에서 같은 효과가 그대로 재현된다고 단정해서는 안 됩니다.

Harness Engineering 역시 아직 업계 전체가 합의한 단일 표준 용어라고 보기는 어렵습니다. 이 글에서는 에이전트를 안정적으로 굴리기 위한 실행 환경, 검증 루프, 도구 연결, 실패 복구 설계를 설명하는 분석적 표현으로 사용합니다.

왜 프롬프트만으로는 부족해졌나

Prompt Engineering은 모델에게 어떤 지시를 줄지 다듬는 작업입니다. “표로 정리해줘”, “시니어 개발자처럼 검토해줘”, “예시를 포함해 설명해줘” 같은 요청을 명확히 만드는 일이 여기에 해당합니다. 단순 질의응답에서는 여전히 중요합니다.

하지만 에이전트는 한 번 답하고 끝나는 도구가 아닙니다. 파일을 읽고, 외부 도구를 호출하고, 코드를 수정하고, 테스트 결과를 보고, 다시 계획을 바꿀 수 있습니다. 이때는 프롬프트 문장보다 “모델이 지금 판단하는 데 필요한 정보가 있는가”가 더 중요해집니다.

이것이 Context Engineering의 출발점입니다. 컨텍스트는 모델이 답변을 만들 때 참고하는 정보 묶음입니다. 시스템 지시문, 도구 설명, 문서, 코드, 대화 기록, 실행 로그, 외부 데이터가 모두 컨텍스트가 될 수 있습니다. 좋은 컨텍스트 설계는 이 많은 정보 중 지금 필요한 것만 남기고 불필요한 것은 줄이는 일입니다.

여기서 한 단계 더 나아가면 Agent Skills가 필요해집니다. 반복되는 작업을 매번 긴 프롬프트로 설명하는 대신, 작업 절차와 검증 기준을 스킬로 묶어두는 방식입니다. 예를 들어 “코드 리뷰 스킬”, “테스트 보강 스킬”, “MCP 서버 설계 스킬”처럼 자주 반복되는 일을 재사용 가능한 단위로 만들 수 있습니다.

GenericAgent가 말하는 핵심도 이 흐름과 맞닿아 있습니다. 컨텍스트 창이 길어지는 것만으로는 충분하지 않습니다. 중요한 것은 목표, 제약, 최근 실행 결과, 실패 원인, 검증 기준 같은 정보가 끝까지 살아남는 것입니다. 정보가 많아도 정작 중요한 것이 묻히면 에이전트는 쉽게 엉뚱한 방향으로 움직입니다.

그래서 Harness Engineering이라는 관점이 필요해집니다. 에이전트에게 도구만 붙여주는 것이 아니라, 어떤 권한으로 실행할지, 어떤 결과를 검증할지, 실패하면 어디서 멈출지, 누가 승인할지까지 설계해야 합니다. 에이전트의 품질은 모델 성능뿐 아니라 이 실행 구조에 크게 좌우됩니다.

프롬프트·컨텍스트·스킬·하네스 비교

개발팀은 무엇을 바꿔야 할까

개발팀 입장에서 이 변화는 단순한 유행어가 아닙니다. AI 에이전트를 도입한다는 것은 “좋은 모델을 고르는 일”에서 끝나지 않습니다. 어떤 정보를 줄지, 어떤 도구를 열어줄지, 어떤 결과를 검증할지, 실패했을 때 어떻게 멈출지를 함께 정해야 합니다.

예를 들어 사내 주문·결제·클레임 도메인에 에이전트를 붙인다고 가정해보겠습니다. “클레임 취소 로직을 개선해줘”라고만 말하면 프롬프트 수준의 요청입니다. 여기에 도메인 정책, 상태 전이, 외부 연동 제약, 테스트 기준, 장애 사례를 함께 제공하면 Context Engineering에 가까워집니다.

반복되는 작업은 스킬로 만들 수 있습니다. 예를 들어 “클레임 취소 설계 검토 스킬”, “트랜잭션 아웃박스 점검 스킬”, “Kafka 컨슈머 부하 제어 점검 스킬”처럼 자주 반복되는 검토 절차를 정리할 수 있습니다. 이때 스킬은 단순 프롬프트가 아니라 팀의 작업 방식과 품질 기준을 담은 실행 지식에 가깝습니다.

마지막으로 실행 하네스가 필요합니다. 에이전트가 어느 저장소를 읽을 수 있는지, 어떤 브랜치에 쓸 수 있는지, 테스트가 실패하면 중단할지, 민감한 로그는 어떻게 다룰지, 결과를 누가 승인할지 정해야 합니다. 이 구조가 없으면 에이전트는 빠르게 무언가를 만들 수는 있지만, 팀은 더 많은 리뷰 비용과 책임 추적 비용을 떠안을 수 있습니다.

결론: 에이전트 경쟁력은 실행 구조에서 나온다

AI 에이전트 개발의 중심은 점점 모델 바깥으로 이동하고 있습니다. 모델 성능은 여전히 중요하지만, 실무에서 안정적으로 쓰려면 프롬프트만으로는 부족하고 컨텍스트만으로도 부족합니다.

Prompt Engineering은 모델에게 무엇을 말할지 정리하는 기술입니다. Context Engineering은 모델이 판단에 필요한 정보를 잃지 않도록 관리하는 기술입니다. Agent Skills는 반복 작업의 절차와 검증 기준을 재사용하는 방식입니다. Harness Engineering은 이 모든 것을 실제 실행 환경 안에서 안전하게 굴리는 설계 관점입니다.

앞으로 AI 에이전트를 도입하는 팀은 프롬프트 템플릿만 만들 것이 아니라, 스킬 저장소, MCP 서버, 메모리 정책, 검증 루프, 권한 모델, 실패 복구 절차를 함께 설계해야 합니다. 에이전트 시대의 진짜 생산성은 코드를 더 많이 생성하는 데서 끝나지 않습니다. 생성된 작업이 조직의 품질 기준 안에서 반복 가능하게 실행되는 구조를 만드는 데서 나옵니다.

FAQ