'Verified'의 의미가 변했다: 에이전틱 엔지니어링 (Agentic Engineering)이 개발 팀에 요구하는 것

4월 29일자 Fragments에서 Martin Fowler는 동일한 결론에 도달하는 에이전틱 프로그래밍 (Agentic Programming)에 관한 세 편의 기사를 모았습니다. 중요한 투자는 코드 생성 속도가 아니라, 에이전트를 위한 코드의 검증 (Verification), 하네스 (Harness), 그리고 가독성 (Readability)에 있습니다.

Chris Parsons가 말하는 'verified'에 대하여

가장 직접적인 기여는 Chris Parsons가 'Coding with AI' 가이드의 세 번째 업데이트에서 제시한 내용입니다. 핵심 논점은 "verified"라는 개념이 AI 에이전트의 처리량 (Throughput)과 함께 진화해야 한다는 것입니다.

_"'Verified'는 과거에 '당신이 읽었다'는 것을 의미했습니다. 현대적인 에이전트의 처리량을 고려할 때, 이는 '테스트, 타입 체커 (Type checkers), 자동화된 게이트 (Automated gates), 또는 당신의 판단이 중요한 경우 당신에 의해 확인되었다'는 것을 의미해야 합니다. 확인 과정은 여전히 존재하지만, 그것이 항상 당신의 머릿속에서 일어나는 것은 아닙니다."

— Chris Parsons

다시 말해, 검증이 사라진 것이 아닙니다. 에이전트가 생성하는 양이 개인의 검토 능력을 넘어섰을 때, 검증은 인간의 독서에서 자동화된 도구로 이동한 것입니다. 이는 프로세스의 퇴보가 아니라 필요한 적응입니다.

Parsons는 또한 개발에서 AI를 사용하는 두 가지 모드를 구분합니다. 바이브 코딩 (Vibe coding)은 구조에 대한 책임 없이 코드를 생성하는 것을 의미합니다. 에이전틱 엔지니어링 (Agentic engineering)은 엔지니어가 품질에 대한 책임을 계속 유지하며, AI는 엔지니어의 대체제가 아닌 프로세스 내의 도구로 활용되는 것을 의미합니다.

_"해결책은 AI를 훈련시켜 디프 (Diffs)가 처음부터 올바르게 나오도록 하고, 당신 스스로가 팀 내에서 하네스 (Harness)를 형성하는 사람이 되며, 그 작업을 당신의 성과를 측정하는 가시적인 요소로 만드는 것입니다."

— Chris Parsons

검증 계층으로서의 하네스 엔지니어링 (Harness Engineering)

Birgitta Böckeler는 martinfowler.com에 게시된 Chris Ford와의 토론 기사에서 하네스 엔지니어링 (Harness Engineering)의 개념을 발전시켰습니다. 핵심 아이디어는 다음과 같습니다: 컴퓨팅 센서(테스트, 정적 분석, 타입 체커)가 인간의 검토보다 더 신뢰할 수 있는 방식으로 AI가 생성한 코드의 품질을 높인다는 것입니다.

"LLM은 탐색적이고 모호한 규칙(fuzzy rules)에는 훌륭하지만, 일단 객관적인 것이 생기면 이를 공식적이고(formal), 모호하지 않으며(unambiguous), 결정론적인(deterministic) 형식으로 변환하는 것이 더 많은 확신을 줄 수 있습니다."

— Birgitta Böckeler

즉, 품질 규칙이 객관적이고 결정론적이 되면, 이를 코드(테스트나 타입 등)로 공식화하는 것이 이를 포착하기 위해 인간의 검토에 의존하는 것보다 더 많은 보장을 제공한다는 의미입니다.

실무적인 핵심: 에이전트(Agent)를 위한 프롬프트(Prompt)를 최적화하기 전에, 검증 하네스(Verification harness)가 에이전트가 유발할 수 있는 문제를 감지할 수 있는지 먼저 확인하는 것이 가치가 있습니다. 취약한 하네스는 더 나은 프롬프트가 단지 더 정교한 버그를 만들어낼 뿐이라는 것을 의미합니다.

식별자(Identifiers)와 LLM의 성능

세 번째 기사는 LLM이 생성한 코드의 품질에 함수 크기가 미치는 영향에 관한 Adam Tornhill의 글입니다. 관련 핵심 사항은 다음과 같습니다: LLM은 의미를 추론하기 위해 이름, 구조 및 로컬 컨텍스트(Local context)에 크게 의존합니다. 의미 있는 식별자(Identifiers)가 임의의 이름으로 대체되면 모델의 성능은 현저히 떨어집니다.

이는 일관성 없는 명명 규칙을 가진 레거시 코드(Legacy code)에서 작업하기 위해 에이전트를 사용하는 팀들에게 직접적인 시사점을 줍니다. 에이전트 출력물의 품질은 부분적으로 입력 코드 내 식별자의 품질에 달려 있습니다.

세 기사의 공통점

세 기사는 모두 동일한 논제로 수렴합니다: 에이전틱 프로그래밍(Agentic programming)에서 차별점은 더 빠르게 생성하는 데 있지 않습니다. 확장 가능한 리뷰 표면(Review surfaces), 견고한 하네스(Harness), 그리고 에이전트가 정밀하게 추론할 수 있도록 구조화된 코드에 있습니다.

우리는 어디에 투자할지 결정하기 전에 우리 프로세스의 실제 병목 구간(Bottleneck)이 어디인지 분석해야 합니다: 병목 구간이 생성(Generation)이라면 프롬프트를 개선하는 것이 타당합니다. 만약 검증(Verification)이 병목이라면 하네스에 투자하는 것이 더 높은 수익을 가져다줄 것입니다.

출처: Fragments: April 29. Martin Fowler