# [[Agentic Software Engineering]]

## 📌 Brief Summary
에이전틱 소프트웨어 엔지니어링(Agentic Software Engineering)은 개발자가 직접 코드를 작성하는 역할에서 코드를 자율적으로 작성하는 AI 에이전트를 오케스트레이션하고 방향을 설정하는 역할로 진화하는 소프트웨어 개발 패러다임입니다 [1-3]. 이 환경에서 대형 언어 모델(LLM)은 단일 응답을 생성하는 것을 넘어 자율적으로 계획을 세우고 코드를 디버깅하며 소프트웨어 시스템을 구축하는 에이전트로 작동합니다 [4, 5]. 이러한 에이전트가 환각이나 탈선 없이 신뢰성 있게 작업을 수행할 수 있도록 실행 환경, 도구 제어, 메모리, 안전장치 등을 제공하는 '에이전트 하네스 엔지니어링(Agent Harness Engineering)'이 이 패러다임의 핵심 인프라 기반을 형성합니다 [6-8].

## 📖 Core Content

*   **개발자 역할의 변화 (From Implementer to Orchestrator)**: 2026년 이후 소프트웨어 개발의 핵심은 코드를 작성하는 것(syntax)에서 AI 에이전트가 안전하게 코드를 작성할 수 있도록 아키텍처와 제어 시스템을 설계하는 것으로 변화했습니다 [1-3]. 인간은 고차원적인 시스템 아키텍처 설계와 결과물 검증 및 전략적 방향 지시에 집중하고, 에이전트는 반복적이고 전술적인 구현을 담당합니다 [1, 2].
*   **에이전트 하네스의 필수성 (The Necessity of Agent Harnesses)**: LLM 자체는 상태(State)를 유지하거나 코드를 실행하거나 외부 API를 호출할 수 없는 단순한 확률적 추론 엔진에 불과합니다 [6, 9, 10]. 이를 자율적인 코딩 에이전트로 변환하려면 실행 루프(E), 도구 레지스트리(T), 컨텍스트 관리자(C), 상태 저장소(S), 수명주기 훅(L), 평가 인터페이스(V) 등 6가지 거버넌스 구성 요소를 제공하는 '하네스(Harness)' 인프라가 필수적입니다 [7, 8, 11, 12].
*   **다중 에이전트 및 PEV 루프 (Multi-agent & PEV Loop)**: 복잡한 코드 작성 작업은 계획(Plan), 실행(Execute), 검증(Verify)으로 역할을 분리하는 PEV 루프나 다중 에이전트 오케스트레이션(Orchestrator-worker 패턴 등)을 통해 관리됩니다 [13-15]. 이를 통해 에이전트는 환각이나 작업 이탈 없이 명시적인 계획과 린터(Linter), CI 검사와 같은 기계적인 승인 절차 내에서만 작업을 수행합니다 [13, 14, 16].
*   **실행 환경 및 샌드박스 (Execution Environments & Sandboxing)**: 코딩 에이전트는 컨테이너나 마이크로 VM과 같은 격리된 샌드박스 환경에서 파일 읽기/쓰기, 셸 명령어 실행, LSP(Language Server Protocol)를 통한 시맨틱 코드 분석 등의 도구를 사용합니다 [17-19]. 또한, 리소스 소모가 큰 물리적 Docker 환경 대신, LLM을 활용하여 코드 실행 결과를 시뮬레이션하고 검증하는 'SWE-World'와 같은 도커 프리(Docker-Free) 가상 하네스 환경도 에이전트 훈련 및 평가에 적극 활용되고 있습니다 [20-22].

## ⚖️ Trade-offs & Caveats

*   **자율성(Capability)과 격리/보안(Security/Isolation) 간의 트레이드오프**: 코딩 에이전트가 현실적인 엔지니어링 문제를 해결하려면 셸 명령어 실행이나 파일 시스템 접근과 같은 광범위한 도구 권한이 필요하지만, 이는 간접 프롬프트 인젝션(Indirect Prompt Injection)이나 샌드박스 탈출과 같은 심각한 시스템 보안 취약점을 발생시킵니다 [23, 24]. 반대로 강력한 보안 및 격리 조치(예: 엄격한 마이크로 VM 환경 적용)를 강제하면 에이전트의 지연 시간과 운영 비용이 크게 증가하여 완벽한 파레토 최적점(Pareto-optimal point)을 찾기 어렵습니다 [23, 24].
*   **컨텍스트 보존(Context Retention)과 컴퓨팅 경제성(Compute Economics)의 상충**: 장기 실행 에이전트(Long-running agents)가 과거의 코드 수정 내역과 도구 실행 결과를 모두 컨텍스트 윈도우에 보존하도록 하면 토큰 소비량이 기하급수적으로 늘어나 '컨텍스트 부패(Context rot)'가 발생하며 추론 능력이 희석됩니다 [25-27]. 반대로 토큰 최적화를 위해 컨텍스트를 너무 공격적으로 요약(Compaction)하거나 삭제하면 에이전트가 이전의 결정 맥락이나 중요한 코드 레퍼런스를 상실하는 정보 손실의 부작용이 발생합니다 [28, 29].
*   **하네스-모델 결합(Harness-Model Coupling) 편향성**: 에이전트 시스템의 실제 신뢰성이나 코드 벤치마크 평가 점수는 모델 단독의 지능이 아니라 모델과 하네스 간의 상호작용 품질에 의해 크게 좌우됩니다 [30, 31]. 동일한 성능의 모델이라도 하네스의 환경 설정, 에러 메시지 래핑 방식, 도구 제공 설계가 미흡할 경우 작업에 실패할 확률이 매우 높으며, 이는 평가 과정에서 모델 자체의 능력 부족으로 오인될 위험이 존재합니다 [32, 33].

## 🔗 Knowledge Connections

### Related Concepts

#### [관계 유형 A (아키텍처 및 인프라 기반 기술)]
- [[Agent Execution Harness]]
  - 연결 이유: 텍스트를 출력하는 언어 모델을 자율적으로 행동하는 에이전트로 변환하는 핵심 런타임 제어 인프라이기 때문입니다 [11, 12, 34].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태 보존, 실행 루프 관리, 컨텍스트 제어, 보안 강제 등 하네스의 6대 거버넌스가 모델 성능과 신뢰성을 어떻게 결정짓는지 파악할 수 있습니다 [11, 12, 35].
- [[Model Context Protocol (MCP)]]
  - 연결 이유: 에이전트 하네스가 외부 데이터베이스, 파일 시스템, 서드파티 애플리케이션 등 외부 도구와 통신하는 방식을 표준화하는 개방형 프로토콜이기 때문입니다 [36-38].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: AI가 외부 시스템과 툴을 호출하는 복잡한 권한 및 도구 레지스트리 관리 구조를 상호 운용 가능한 형태로 단순화하는 통합 원리를 이해할 수 있습니다 [39, 40].

#### [관계 유형 B (실행 제어 및 평가 아키텍처 패턴)]
- [[Plan-Execute-Verify (PEV) Loop]]
  - 연결 이유: 코딩 에이전트가 단일 프롬프트가 아닌 구조화된 계획 수립, 제한된 실행, 엄격한 코드 검증을 거치도록 강제하는 핵심 하네스 소프트웨어 패턴이기 때문입니다 [13, 14].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단순히 코드를 생성하고 확인하는(Generate-and-check) 방식의 한계를 극복하고, 자동화된 피드백 루프를 통해 에이전트의 실패를 복구하는 메커니즘을 배울 수 있습니다 [14].
- [[SWE-World]]
  - 연결 이유: 리소스가 많이 소모되는 무거운 물리적 Docker 실행 환경 대신, LLM 모델을 활용하여 코드 탐색 및 유닛 테스트 실행 결과를 시뮬레이션하는 도커 프리(Docker-Free) 에이전트 훈련 프레임워크이기 때문입니다 [20, 22].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비용과 인프라의 한계로 인해 대규모 에이전트 강화학습(RL)이나 평가가 어려웠던 문제를, 가상 피드백 시뮬레이션을 통해 확장성 있게 해결하는 방법을 이해할 수 있습니다 [22, 41].

### Deeper Research Questions

- 대규모 다중 에이전트(Multi-agent) 시스템 환경에서 에이전트 간의 공유 상태(Shared state) 일관성을 유지하고, 한 에이전트의 결함이나 오류가 다른 에이전트로 연쇄 전파(Cascading failures)되는 것을 방지하기 위한 하네스 계층의 격리 아키텍처는 어떻게 설계되어야 하는가? [42-44]
- 100만 토큰 이상의 초장기 문맥(Ultra-long-context) LLM이 등장했음에도 불구하고, 컨텍스트 압축(Compaction)과 정보의 현저성(Salience) 관리가 여전히 에이전트 하네스 설계에서 가장 중요한 제약 조건이자 필수 엔지니어링 영역으로 작용하는 실증적 원리는 무엇인가? [45, 46]
- 소프트웨어 엔지니어링 에이전트를 위한 코드 실행 샌드박스에서 성능(지연 시간 최소화 및 캐시 최적화)과 보안(마이크로VM 수준의 커널 접근 제어 등) 간의 극단적인 트레이드오프를 가장 효율적으로 해결할 수 있는 런타임 인프라 구성 방안은 무엇인가? [23, 24]
- SWE-bench와 같은 코드 해결 벤치마크 평가 시, 모델 자체의 지능적 추론 능력과 하네스의 물리적 환경(실행 환면 래핑, 도구 스키마 최적화 등)이 성능 결과에 미치는 영향을 정량적으로 완전히 분리하여 측정할 수 있는 표준화된 방법론은 무엇인가? [32, 33]
- 런타임에 동적으로 새로운 도구를 탐색하고 호출할 수 있는 MCP(Model Context Protocol) 환경에서, 예상치 못한 도구 권한의 조합(Capability escalation)으로 발생하는 간접 프롬프트 인젝션 등의 보안 취약점을 사전에 차단하기 위한 하네스 수준의 권한 제어 모델은 어떻게 구축해야 하는가? [47, 48]

### Practical Application Contexts

- **Implementation:** 개발자가 명령줄(CLI) 인터페이스나 IDE에 통합된 에이전트 환경(예: OpenDev)을 구축하여, 자율 코딩 에이전트가 격리된 샌드박스 내에서 파일 편집, 구조적 린팅, 테스트 실행을 안전하게 반복하도록 구현합니다 [49, 50].
- **System Design:** 소프트웨어 개발 시 기획을 담당하는 Planner 에이전트, 코드를 구현하는 Generator 에이전트, 통합 테스트 및 검증을 수행하는 Evaluator 에이전트로 역할을 철저히 분리한 다중 에이전트 오케스트레이션 파이프라인 아키텍처를 설계합니다 [51-53].
- **Operation / Maintenance:** LangSmith, AgentOps 등의 전문 옵저버빌리티(Observability) 및 평가 도구를 적용하여 런타임 환경에서 장기간 실행되는 에이전트의 컨텍스트 초과 상태, 도구 호출 실패율, 루프 중단 지점 등을 투명하게 모니터링하고 추적합니다 [54, 55].
- **Learning Path:** 단순한 일회성 프롬프트 튜닝(Prompt Engineering)에서 벗어나, 에이전트가 문맥을 유지하도록 돕는 컨텍스트 엔지니어링(Context Engineering)과, 최종적으로 린터 강제, 메모리 지속성 등을 통합해 에이전트를 통제하는 하네스 엔지니어링(Harness Engineering)으로 기술 스택과 학습 패러다임을 진화시킵니다 [56, 57].
- **My Project Relevance:** 소스에 관련 정보가 부족합니다. (개인의 특정 프로젝트나 사적 맥락에 연관된 내용은 제공된 소스 데이터 내에 기술되어 있지 않습니다).

### Adjacent Topics

- [[Retrieval-Augmented Generation (RAG)]]
  - 확장 방향: RAG는 단순히 정적인 문서에서 텍스트를 검색하여 모델에 지식을 주입하는 수동적인 방식이었다면, 이를 넘어 에이전트가 코드베이스 구조를 파악하고 여러 검색 도구를 거쳐 동적으로 정보를 직접 획득해나가는 'Agentic Search(에이전트적 탐색)' 및 연속적 지식 통합 아키텍처로 확장할 수 있습니다 [58-60].
- [[Agent-to-Agent (A2A) Protocol]]
  - 확장 방향: MCP가 개별 에이전트와 외부 도구/데이터 간의 연결을 돕는 표준이라면, A2A 프로토콜은 서로 다른 하네스에 속하거나 원격으로 분산된 다수의 에이전트 인스턴스 간에 작업을 위임하고 상태를 동기화하며 통신하기 위한 상호운용성 네트워크 표준 기술로 확장할 수 있습니다 [37, 61].

---
*Last updated: 2026-05-01*