AI 개발 하네스(Harness)는 개발팀이 인공지능(Artificial Intelligence, AI) 에이전트에게 실제 개발 업무를 맡기기 위해 사용하는 실행 환경으로, 모델·컨텍스트·도구·규칙·권한·피드백 루프를 하나로 묶은 계층입니다. 같은 기반 모델을 쓰는 코딩 에이전트(Coding Agent)들이 서로 다른 결과를 내는 이유는 모델 성능 차이가 아니라 이 하네스의 설계 차이입니다.
이 차이는 정량적으로도 확인됩니다. 아마존 웹 서비스(Amazon Web Services, AWS)가 공개한 AI 주도 개발 생애주기 워크플로 2.0(AI-Driven Development Life Cycle Workflows 2.0)은 5개 Phase, 33개 Stage, 14개 Agent, 11개 Adaptive Scope로 구성되며, 이 중 경로 결정과 상태 관리는 대형 언어모델(Large Language Model, LLM)의 자연어 판단에서 분리해 결정론적 코드로 처리합니다.1) 모델을 바꾸지 않고 실행 환경만 바꿔도 결과의 일관성이 달라진다는 뜻입니다. LG CNS는 다양한 시스템 통합(System Integration, SI) 및 시스템 운영(System Management, SM) 프로젝트에 AI-DLC를 적용하면서, 방법론을 그대로 쓰는 것보다 프로젝트가 일하는 방식을 하네스에 반영하는 작업이 성과를 좌우한다는 점을 반복적으로 확인했습니다.
불과 몇 년 전까지만 해도 AI 코딩이라고 하면 코드 자동완성을 먼저 떠올렸습니다. 개발자가 코드를 작성하면 AI가 다음 몇 줄을 예측하고, 반복적인 코드를 대신 작성해 주는 방식입니다. 이후 AI는 대화 형태로 통합 개발 환경(Integrated Development Environment, IDE) 안에 들어왔습니다. 개발자는 코드에 대해 질문하고, 리팩터링을 요청하고, 테스트 코드를 생성하기 시작했습니다.
그리고 이제 코딩 에이전트는 저장소를 탐색하고 파일을 수정하며, 셸 명령을 실행하고 테스트까지 수행합니다. 모델 컨텍스트 프로토콜(Model Context Protocol, MCP)을 통해 외부 시스템과 상호작용하기도 합니다. 달라진 것은 AI가 만들어 내는 코드의 양이 아닙니다. AI에게 맡기는 일의 단위가 코드에서 작업(Task)으로 커졌습니다.
[그림 1] AI 코딩의 발전 단계. 코드 자동완성에서 대화형 코딩, 코딩 에이전트, Agentic Development로 이어지며 AI에게 위임하는 단위가 커진다
위임 단위가 커지면서 두 가지 문제가 함께 커졌습니다.
첫째, 에이전트의 실제 성능을 LLM의 벤치마크 점수만으로 설명하기 어려워졌습니다. 같은 모델을 쓰더라도 에이전트가 어떤 컨텍스트를 받는지, 어떤 도구에 접근할 수 있는지, 저장소를 어떻게 탐색하는지, 실패했을 때 어떤 피드백 루프를 도는지에 따라 결과가 크게 달라집니다.
[그림 2] 코딩 에이전트의 실행 구조. 사용자 의도를 받아 저장소 탐색, 파일 수정, 셸 명령, 빌드와 테스트, Git, MCP 도구를 거쳐 결과를 만든다
둘째, 기업 환경에서는 에이전트를 어떤 정책 안에서 일하게 할지도 정해야 합니다. 에이전트에게 "결제 기능을 개발해줘"라고 요청하면 다음 항목들이 여전히 정해지지 않은 상태로 남습니다.
- 요구사항을 확정하는 주체
- 아키텍처를 검토하는 시점
- 보안 요구사항을 확인하는 시점
- 테스트 전략을 결정하는 시점
- AI가 만든 설계를 승인하는 주체
- 그 결정의 근거를 남길 위치
즉 하네스 거버넌스와 개발 프로세스 거버넌스는 서로 다른 문제입니다. 도구를 잘 고르는 것만으로는 두 번째 문제가 해결되지 않습니다.
모델보다 하네스가 중요한 이유
LLM을 자동차의 엔진이라고 생각해 보겠습니다. 좋은 엔진이 중요하다는 것은 분명하지만, 엔진 하나만으로 자동차가 움직일 수는 없습니다. AI 에이전트도 마찬가지입니다. 실제 개발 업무를 수행하려면 모델 주변에 여러 요소가 필요합니다.
[그림 3] Coding Harness의 구성 요소. 모델, 컨텍스트, 도구, 메모리, 규칙, 권한, 계획과 검증과 피드백이 하나의 실행 환경을 이룬다
이런 관점에서 보면 최근 AI 엔지니어링의 관심사가 어떻게 변화해 왔는지도 확인할 수 있습니다.
[그림 4] Prompt Engineering에서 Context Engineering, Harness Engineering으로 관심사가 확장되는 흐름
프롬프트 엔지니어링(Prompt Engineering)이 AI에게 전달할 지시문을 다듬는 일이라면, 컨텍스트 엔지니어링(Context Engineering)은 AI가 무엇을 알고 일할지를 정하는 일입니다. 하네스 엔지니어링(Harness Engineering)은 한 단계 더 나아가 AI가 어떤 컨텍스트와 도구, 규칙, 권한, 피드백 루프 안에서 일하게 할 것인가를 설계합니다. 에이전트가 더 많은 권한과 자율성을 가질수록, 모델 자체만큼이나 그 모델을 둘러싼 실행 환경도 중요해집니다.
Kiro를 Harness 관점으로 바라보기
AWS는 Kiro를 Agentic IDE로 소개하고 있습니다. Specs, Steering, Hooks, Agentic Chat, MCP 등이 주요 기능입니다.2) 각각을 독립된 편의 기능으로 볼 수도 있지만, Harness Engineering 관점으로 보면 전체적으로 보다 선명하게 확인할 수 있습니다.
1. Specs: Vibe Coding에서 Spec 기반 개발로
에이전트에게 "이 기능을 만들어줘"라고 요청하면 빠르게 결과를 얻을 수 있습니다. 하지만 기능이 복잡해질수록 요구사항 해석 차이나 빠뜨린 인수 조건(Acceptance Criteria), 아키텍처 방향의 불일치가 결국 재작업으로 돌아옵니다.
[그림 5] Kiro Specs의 진행 흐름. Idea, Requirements, Design, Tasks를 거친 뒤 Implementation으로 넘어간다
Kiro Specs는 구현부터 시작하는 대신 무엇을 만들지, 어떻게 만들지를 먼저 구조화하고 이를 기반으로 에이전트가 구현하게 합니다. 이 지점부터 AI 코딩은 단순한 코드 생성을 넘어섭니다. AI와 사람이 개발 의도와 컨텍스트를 먼저 공유하는 것이 중요합니다.
2. Steering: 반복 설명을 프로젝트 컨텍스트로
코딩 에이전트를 사용하다 보면 비슷한 내용을 반복해서 입력하게 됩니다. 자바(Java)와 스프링(Spring) 기반 프로젝트라는 사실, 아키텍처 원칙, 네이밍 규칙, 보안 기준, 도메인 용어, 개발팀이 지켜야 하는 패턴 등입니다.
Kiro의 Steering은 이러한 정보를 지속적인 컨텍스트로 제공합니다.2) 매번 프롬프트로 설명하던 프로젝트의 규칙을 하네스의 컨텍스트 계층으로 옮기는 것입니다.
3.Hooks: 요청과 강제의 차이
에이전트에게 "코드를 수정하면 반드시 테스트를 수행해줘"라고 요청할 수 있습니다. 하지만 LLM에게 전달되는 지시와 시스템이 실제로 강제하는 메커니즘은 다릅니다.
[그림 6] 프롬프트로 검사를 요청한 경우와 Hook으로 검사를 구조화한 경우의 차이
Kiro의 Hooks는 반복적인 작업을 이벤트 기반으로 자동화합니다.2) Harness Engineering 관점에서 이 차이는 중요합니다. AI에게 "꼭 검사해"라고 요청하는 것과, 시스템이 실제 검사를 수행하도록 설계하는 것은 신뢰성 측면에서 다른 문제입니다.
4. MCP: Agent의 도구 계층
MCP는 흔히 AI용 플러그인처럼 설명되지만, 하네스 관점에서는 에이전트가 외부 시스템과 상호작용하기 위한 도구 계층입니다.
[그림 7] MCP를 통해 Kiro Agent가 문서, 데이터베이스, API, 개발 도구로 활동 범위를 넓히는 구조
이를 통해 AI 에이전트는 저장소 안의 코드만 읽는 것이 아니라 문서, 데이터베이스, 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API), 개발 도구 등으로 활동 범위를 확장합니다. Kiro IDE뿐 아니라 Kiro 명령줄 인터페이스(Command Line Interface, CLI)도 Custom Agent, MCP 연동, Hooks, Steering을 제공하며, CLI에서는 Headless 자동화까지 지원해 IDE 밖의 워크플로로 에이전트를 확장할 수 있습니다.2)
개인의 Harness에서 조직의 Harness로
개인 개발자가 코딩 에이전트를 선택할 때는 주로 생산성을 봅니다. 기업은 여기에 기준을 더합니다.
[그림 8] 개발자는 생산성을 보고, 기업은 모델과 MCP, 웹 접근, 입력 정보, 감사 가능성을 함께 본다
Kiro Enterprise는 이 지점을 네 가지 축으로 다룹니다.3) 4)
첫째, 모델 거버넌스입니다. 관리자는 조직 구성원이 쓸 수 있는 모델의 허용 목록(Allow-list)을 관리하고 기본 모델을 설정할 수 있습니다. 허용 목록을 운영하면 Kiro에 새 모델이 추가되더라도 관리자가 명시적으로 추가하기 전에는 사용자에게 제공되지 않습니다. 즉 모델 선택은 개인의 취향이 아니라 조직 정책의 영역이 됩니다. 다만 Kiro의 Auto는 거버넌스에서 별도 선택 항목이며, Auto 내부의 라우팅이 관리자가 승인한 개별 모델 목록으로 제한되는 것은 아닙니다. 3) 5) 승인된 모델만 사용해야 하는 조직이라면 Auto를 허용할지도 정책적으로 판단해야 합니다. 모델 라우팅과 모델 거버넌스가 서로 다른 문제라는 점을 보여주는 대목입니다.
둘째, MCP 거버넌스입니다. MCP는 에이전트의 능력을 확장하는 동시에, 에이전트가 어떤 시스템에 접근할 수 있는지를 결정하는 보안 경계입니다. Kiro Enterprise에서는 MCP를 전체 비활성화하거나, 검증된 MCP 서버만 허용 목록 방식으로 열어 두거나, MCP Registry를 통해 중앙에서 관리할 수 있습니다. 조직 수준 정책을 설정하고 계정 단위에서 별도 정책을 적용하는 것도 가능합니다.
셋째, 웹 접근도 하나의 권한입니다. 코딩 에이전트가 웹 검색이나 URL 조회를 수행할 수 있다는 것은 편리하지만, 기업 개발환경에서는 외부 웹 접근 자체가 권한입니다. Kiro Enterprise에서는 web_search, web_fetch 같은 웹 도구 사용을 조직 차원에서 비활성화할 수 있습니다.
넷째, 프롬프트와 응답도 감사 대상이 됩니다. 관리자가 Prompt Logging을 활성화하면 Kiro IDE의 프롬프트와 응답을 조직이 보유한 AWS 계정의 아마존 S3(Amazon Simple Storage Service, S3) 버킷에 저장할 수 있습니다. AWS는 이를 감사, 디버깅, 분석, 컴플라이언스 용도로 설명하며, 필요하면 키 관리 서비스(Key Management Service, KMS)를 활용한 암호화도 구성할 수 있습니다. 사용자별 활동 리포트 기능도 제공합니다.
개인 환경에서 가장 중요한 기준이 생산성이라면, 기업 환경에서는 누가 어떤 AI와 무엇을 주고받았고 그것을 관리하고 추적할 수 있는지가 함께 기준이 됩니다.
다음 시리즈에서는 개발 절차에 대해 AWS가 내놓은 접근방식인 AI주도 개발 생애주기(AI-Driven Development Life Cycle, AI-DLC)에 대해 다뤄볼 예정입니다.
요약
- 같은 기반 모델을 쓰는 코딩 에이전트가 서로 다른 결과를 내는 이유는 모델 성능이 아니라 하네스(Harness) 설계 차이입니다. 하네스는 모델· 컨텍스트· 도구 ·메모리 ·규칙 ·권한 ·피드백 루프로 구성된 실행 환경이며, AI 엔지니어링의 관심사는 Prompt Engineering에서 Context Engineering, Harness Engineering으로 확장되고 있습니다.
- 기업이 AI 코딩을 도입할 때는 서로 다른 두 개의 거버넌스가 필요합니다. 하네스 거버넌스는 에이전트가 어떤 모델·도구·권한으로 일할지를 통제하고, 개발 프로세스 거버넌스는 어떤 단계와 승인 절차로 소프트웨어를 만들지를 정의합니다. 도구 선택만으로는 두 번째 문제가 해결되지 않습니다.
- AWS Kiro Enterprise는 런타임 통제를 네 가지로 제공합니다. 모델 허용 목록(Allow-list) 기반 거버넌스, MCP 서버 허용 목록과 Registry 중앙 관리, web_search·web_fetch 등 웹 도구의 조직 단위 비활성화, 프롬프트와 응답을 조직 소유 AWS 계정의 S3 버킷에 저장하는 Prompt Logging입니다. 다만 Auto 라우팅은 별도 선택 항목이며 승인된 모델 목록으로 제한되지 않습니다.
FAQ
Q1. 같은 AI 모델을 쓰는데 코딩 에이전트마다 결과가 다른 이유는 무엇인가요?
에이전트를 둘러싼 실행 환경이 다르기 때문입니다. 에이전트가 어떤 컨텍스트를 받는지, 어떤 도구에 접근할 수 있는지, 저장소를 어떻게 탐색하는지, 실패했을 때 어떤 피드백 루프를 도는지에 따라 결과가 달라집니다. 이 실행 환경 전체를 하네스(Harness)라고 부르며, 위임하는 작업의 단위가 코드에서 작업(Task)으로 커질수록 모델 성능보다 하네스 설계가 결과를 좌우합니다.
Q2. 하네스 엔지니어링은 프롬프트 엔지니어링, 컨텍스트 엔지니어링과 어떻게 다른가요?
다루는 범위가 다릅니다. Prompt Engineering은 AI에게 전달할 지시문을 다듬는 일이고, Context Engineering은 AI가 무엇을 알고 일할지를 정하는 일입니다. Harness Engineering은 AI가 어떤 컨텍스트와 도구, 규칙, 권한, 피드백 루프 안에서 일할지를 설계합니다. 예를 들어 "코드를 수정하면 테스트를 실행해줘"라고 프롬프트로 요청하는 것과, 시스템이 이벤트 기반으로 테스트를 실제 실행하도록 구성하는 것은 신뢰성 측면에서 다른 문제입니다.
Q3. 기업이 AI 코딩 도구를 도입할 때 개인 개발자와 다르게 확인해야 할 것은 무엇인가요?
개인은 주로 생산성을 기준으로 도구를 고릅니다. 기업은 여기에 네 가지를 더 확인해야 합니다. 조직 구성원이 사용할 수 있는 모델의 범위, 에이전트가 연결할 수 있는 외부 시스템(MCP)의 범위, 외부 웹 접근의 허용 여부, 그리고 누가 어떤 AI와 무엇을 주고받았는지 추적할 수 있는지 여부입니다. 특히 모델 자동 선택 기능은 편리하지만 승인된 모델 목록으로 제한되지 않을 수 있어, 규제 산업에서는 별도 정책 판단이 필요합니다.
참고자료
1) AWS Labs, <aidlc-workflows: AI-DLC Workflows 2.0>
2) Kiro Documentation, <Specs / Steering / Hooks / MCP>
3) Kiro Enterprise Documentation, <Model / MCP / Web Governance>
4) Kiro Enterprise Documentation, <Prompt Logging>
5) Kiro Documentation, <Models and Auto Routing>
본 콘텐츠는 저작권법에 의해 보호받는 저작물로 LG CNS에 저작권이 있습니다.
사전 동의 없이 2차 가공 및 영리적인 이용을 금합니다.
관련 문의 사항은 LG CNS 공식 홈페이지로 문의주시기 바랍니다.
