ReAct 및 Context Engineering의 재해석
기존 ReAct의 ‘Thought, Action, Observation’ 주기를 ‘Evaluation, Feedback, Optimization’으로 대체하여 시스템 프롬프트를 자동으로 재작성하여 후속 생성 품질을 향상시킵니다. 이는 TextGrad 논문의 TextLoss 메커니즘에서 영감을 받아 LLM이 텍스트로 작성된 평가 방법을 통해 출력과 목표 간의 격차를 이해하고, 이를 바탕으로 입력(시스템 프롬프트)을 재작성하도록 합니다. 이는 Meta Prompting 기법과 유사하며, Context Engineering의 핵심 아이디어인 ‘적절한 정보를 적절한 위치에 제공’하는 것과 연결됩니다.
코딩 에이전트 개발 흐름의 개선
인간 개발자의 일반적인 기능 구현 과정(요구사항 이해 → 기능 구현 → 코드 커밋)과 달리, 에이전트에게는 구현 후 ‘코드 검토’ 단계가 부족합니다. 이 문제를 해결하기 위해 Claude Code의 Hook 메커니즘(특히 PostToolUse 트리거)을 활용하여 다음 액션 이전에 새로운 시스템 프롬프트를 추가하고, 구현된 코드에 대한 강제적인 코드 검토를 수행하여 출력 품질을 향상시킵니다.
개선된 코딩 에이전트 개발 흐름은 다음과 같습니다:
-
요구사항 이해
-
기능 구현
-
Tool Response (Observation - 1)
-
Code Review (Observation - 2)
-
구현 수정
-
코드 커밋
효과적인 평가 방법 설계
Hook 추가 자체보다 중요한 것은 좋은 평가 방법을 설계하는 것입니다. 평가 접근 방식은 크게 두 가지입니다:
-
Linters 및 Formatters 활용: Rubocop, Prettier, Ruff와 같은 도구를 사용합니다. 이는 기본적인 품질을 보장하지만, 더 깊은 의미의 품질까지는 보장하기 어렵습니다.
-
Evaluation Prompts 작성: Prompt Engineering과 프로젝트 및 소프트웨어 공학에 대한 이해를 바탕으로 평가 프롬프트를 작성합니다. 저자는 G-Eval 접근 방식을 권장합니다. G-Eval은 LLM과 인간이 유사한 채점 방식을 가질 수 있도록 루브릭(rubric)을 생성하는 방식입니다. 예를 들어, Rails 컨트롤러에서
before_action사용 여부를 명확한 기준과 예시 코드로 제시하여, LLM이 모호한 텍스트 대신 구체적인 기준에 따라 평가하고 구현하도록 유도합니다. 이는 팀의 코드 리뷰 기준을 문서화하는 것과 유사하여, 에이전트에게 ‘알려진’ 기준을 제공하는 효과가 있습니다.
결론적으로, 시니어 개발자가 커밋 전에 ‘자신의 코드를 확인’하는 것처럼, 코딩 에이전트도 구현 후 자체 검증 단계를 거쳐야 안정적인 품질을 보장할 수 있습니다.