AI Coding Agent Architecture

AI 코딩 에이전트는 생성형 AI 에이전트가 개발팀의 최소한의 지시를 받아 자율적으로 SW 개발 작업의 계획/실행/검증을 반복점증적으로 수행하는 SW 개발 플랫폼이다. AI 코딩 에이전트는 생성형 AI 에이전트 중 가장 많이 쓰이는 종류이다. (https://www.anthropic.com/research/measuring-agent-autonomy)

생성형 AI 에이전트의 용도별 활용 실적

AI 코딩 에이전트의 아키텍처(AI Coding Agent Architecture)는 기업 경영을 위해 활용하는 생성형 AI 에이전트의 아키텍처(아래 그림)와 비교해 공통점도 있지만 한결 간단하다. (https://www.kosta-online.com/post/ai-%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8%EC%9D%98-%ED%97%88%ED%97%88-%EC%8B%A4%EC%8B%A4)

기업 경영을 위한 생성형 AI 에이전트의 SOA 아키텍처

AI 코딩 에이전트는 기업 경영을 위한 AI 에이전트와 달리 RAG(Retrieval-Augmented Generation)를 사용하지 않는다. RAG 형태로 별도의 상황 정보 DB를 만드는 대신, 각 세션에서 상황 공학(Context Engineering)을 강화하여 상황 인지 서비스(Context Service)가 SW 애플리케이션 개발에 필요한 요구 스펙, 테스트 기준, 기술 스택, 산출물 스펙 등 상황 정보를 충분히 갖추도록 한다. 개발팀의 개발 노하우를 스킬(Skill.md)로 장기 메모리(Long-Term Memory: LTM)에 저장했다가 세션 중 필요할 때 활용할 수도 있다. 또한 전사 차원에서 AI 코딩 에이전트를 위한 중앙집중식 Knowledge Base를 구축하여 회사의 Best Practice, Know-how, Policy 등을 저장하고, 에이전트들이 MCP를 통해 접근할 수 있도록 할 수도 있다.

기업 경영을 위한 AI 에이전트와 달리 AI 코딩 에이전트는 평가 서비스(Evaluation Service)와 학습 서비스(Learning Service)를 이용한 자율적 학습 및 개선을 실시하지 않는다. 위에서 언급한 개발팀의 개발 노하우를 담은 스킬(Skill.md)이나 전사 차원의 Knowledge Base를 업데이트하면서 여러 세션에서 공유하는 것이 에이전트 코딩에서 실제로 학습과 개선이 일어나는 방법의 하나이다. Claude Opus와 Sonnet 같은 AI 추론 서비스(즉, 개발 계획 서비스: Planning Service)가 추론 결과 중 재사용할 만한 것을 장기 메모리에 저장할 수 있고, 이 정보를 다음 세션에서 상황 인지 서비스가 조회하여 프롬프트 조립 서비스(Prompt Assembly Service)에서 활용하도록 전달하는 것도 학습/개선 방법의 하나이다.

AI 코딩 에이전트는 A2A 프로토콜을 통해 다른 에이전트들을 활용하지는 않고, 서브에이전트(Sub-Agent)를 시켜 일정 작업을 할당한다. AI 코딩 에이전트를 구성하는 대부분의 서비스들은 오케스트레이션을 통해 호출되지만, Observability를 위한 모니터링 서비스와 서브에이전트 간의 협력은 코레오그래피를 통해 호출된다.

AI 코딩 에이전트는 툴을 이용한 개발 계획의 실행 전에 정책 서비스(Permissions Service)를 호출하여 개발 계획이 에이전트의 정책을 위반하지 않는지 검증하지만, 툴의 실행 후에 다시 정책 위반 여부를 검증하지는 않는다. 또한 AI 코딩 에이전트에는 별도의 종료 서비스가 없고, AI 추론 서비스의 추론 결과 중 하나가 에이전트 실행을 종료하고 최종 산출물을 클라이언트에 회답하는 것이다.

AI 코딩 에이전트의 아키텍처는 아래와 같다. 위의 기업 경영을 위한 AI 에이전트의 아키텍처 다이어그램과 비교해 보면 공통점과 차이점을 쉽게 확인할 수 있다.

AI 코딩 에이전트의 SOA 아키텍처

AI 코딩 에이전트를 이용한 애플리케이션 개발의 워크플로우는 다음과 같다.

Step 1. 분석자가 CLI, Web UI, API Gateway, IDE Plug-in 등의 클라이언트에서 상황공학(Context Engineering)을 통해 요구 스펙, 테스트 기준, 최종 산출물 형태, 기술 스택 등을 시스템 프롬프트(System Prompt)로 제출한다. 이때 에이전트가 장기 메모리에 저장한 프로젝트 가이드(Claude.md)도 시스템 프롬프트에 반영한다.

Step 2. 에이전트의 오케스트레이터(Ralph Loop)가 상황 인지 서비스를 호출하여 각종 상황 정보(대화 히스토리, 관련 파일, 시스템 지시사항, 프로젝트 가이드(Claude.md), 정책, 저장된 Skills 등)와 분석자 제출 프롬프트를 기반으로 현재의 상황을 정립한다. 다음에 프롬프트 조립 서비스를 호출하여 AI 추론에 제출할 프롬프트를 조립한다.

Step 3. 개발 계획 서비스가 Claude Opus 또는 Claude Sonnet 모델을 선택/호출하여 프롬프트에 대한 AI 추론을 수행한다. 모델 추론 결과는 개발 계획, 툴 실행 또는 최종 산출물이다. 개발 계획에는 여러 유형이 있다: Sequential, Hierarchical, Conditional, Iterative, Delegation, Dependency Graph, Tool-Mapped, State Machine 등. Sequential 개발 계획의 예: (1) 테스트 실시, (2) 오류 식별, (3) 코드 편집, (4) 테스트 재실시.

Step 4. 추론 결과가 최종 산출물이면 이를 클라이언트에게 회답하고 세션을 종료한다.

Step 5. 추론 결과가 개발 계획인 경우 상황 인지 서비스를 호출하여 그 계획을 상황 윈도우(Context Window)에 반영하고 Step 2로 돌아가 다음 Ralph 루프를 시작한다.

Step 6. 추론 결과가 툴 실행인 경우, 툴 가동 전에 먼저 툴 실행이 에이전트 정책에 부합하는지 검증한 후, MCP를 통해 적합한 툴을 가동시키고 툴 결과(조회된 데이터, 상태 변화, 컴파일/분석/계산 결과, 실행/테스트/빌드 결과 등)를 확보한다. 모니터링 서비스가 코레오그래피를 통해 개발 실행 툴 서비스의 실행 결과를 포착한 후, 오케스트레이터가 상황 인지 서비스를 호출하여 실행 결과를 상황 윈도우(Context Window)에 반영한다. Step 2로 돌아가 다음 Ralph 루프를 시작한다.

Step 6에서 자동 메모리(Auto Memory) 기능을 이용해 실행 결과 중 재사용할 만한 정보를 추려 장기 메모리에 저장하여 후속 세션이 시작할 때 공유할 수 있다. 실행 결과 전체를 장기 메모리에 저장하여 후속 세션에서 공유하려면 Skill 또는 Hook로 저장하거나 Claude-Mem 같은 MCP 플러그인 툴을 이용하면 된다.