평가설계 프로토콜 v1

Coding Agent는 저장소를 탐색하고, 작업을 나누고, 코드를 작성한 뒤 테스트가 통과할 때까지 수정한다. 구현 속도가 빨라질수록 개발자가 모든 변경을 직접 따라가기는 어려워진다. Agent-Driven Development에서는 무엇을 올바른 결과로 볼지 명확히 정의하는 일이 중요해진다.

LLM은 자연어, 문서, 코드, 테스트처럼 서로 다른 표현을 연결하는 데 강하다. 사용자의 요구를 기능으로 정리하고, 도메인 언어를 데이터 모델로 옮기며, 큰 작업을 구현 단위로 분해할 수 있다. 기존 코드와 테스트에서 목적을 추론하는 역방향 작업에도 유용하다.

이러한 능력은 개발에서의 번역으로 볼 수 있다. 개발은 대체로 다음 전환의 연속이다.

• 어떤 변화가 필요한가
• 시스템에 무엇이 성립해야 하는가
• 그것을 어떻게 구현할 것인가

나는 이를 Why–What–How로 이해한다. Why는 원초적인 필요와 목적, What은 그 목적이 실현됐을 때 성립해야 하는 상태와 능력, How는 그것을 만드는 방법이다.

예를 들어 “사용자가 기다림 때문에 분석 흐름을 잃지 않아야 한다”가 Why라면, “동시 요청에서도 응답 지연이 급격히 증가하지 않는다”는 What이 될 수 있다. 캐시, 요청 병합, 분산 Lock은 가능한 How다.

LLM은 Why를 여러 What으로 펼치고, What에 적합한 How를 제안하는 데 유용하다. 동시에 모호한 부분을 일반적인 패턴으로 채우고, 여러 해석 중 하나를 자연스럽게 확정하기도 한다. 결과가 잘 정리되어 있을수록 원래 의도의 변화는 발견하기 어려워진다.

Coding Agent에서는 이 번역이 곧 실행으로 이어진다. 성공 조건이 모호하면 Agent가 구현과 함께 성공의 의미까지 조정할 수 있다. 어려운 요구를 단순화하거나, 구현 대신 테스트 기준을 바꾸어도 작업은 완료된 것처럼 보일 수 있다.

E-H-P와 E-H-T는 이 번역을 사람이 확인할 수 있도록 만든 평가 인터페이스다.

E-H-P, Evaluation Helix Protocol은 사용자와 Agent가 평가를 정의하고 실현하며 변경하는 절차다. E-H-T, Evaluation Helix Tree는 평가 의도를 기술적 평가 단위로 구체화하는 중간 표현이다.

WHY는 프로젝트 비전과 가까운 큰 목적이다. 여러 WHAT이 이를 평가 가능한 상태로 구체화하고, 각 WHAT 아래의 CASE가 특정 조건에서 명제를 판단하는 방법을 정의한다.

CASE라는 How는 다시 Why–What–How로 나뉜다.

• HOW_why: 이 방법으로 명제를 판단할 수 있는 이유
• HOW_what: 판단에 사용할 로그, 수치, 상태 변화 등의 증거
• HOW_how: 증거를 결론으로 바꾸는 판정 규칙

이 분해는 테스트 코드와 평가 의도를 연결한다. 어떤 assertion이 왜 존재하는지, 무엇을 관찰하며, 어디까지 보장하는지를 추적할 수 있다.

실제 워크플로우에서는 Agent가 사용자의 평가 요구를 먼저 E-H-T로 번역해 제안한다. 사용자는 평가의 의미를 확인하고, 승인된 CASE는 테스트나 증거사슬로 구현된다. 이후 평가가 계획대로 작동하는지 다시 검토한다.

평가가 완성되면 일상 개발에서는 TDD처럼 CASE를 실행하고 구현을 수정하면 된다. 새로운 평가가 필요하거나, 구현 방향이 바뀌거나, 평가와 목적 사이의 정합성을 확인해야 할 때 E-H-T로 돌아간다.

Agent-Driven Development에서 평가는 Agent가 어떤 방향으로 반복하고 어디까지 자율적으로 수정할 수 있는지를 정하는 제어 장치다. E-H-P와 E-H-T는 LLM의 번역과 분해 능력을 활용하면서, 목적과 평가와 구현을 같은 의미 구조 안에서 관리하기 위한 방식이다.