에이전틱 엔지니어링과 과도기적 기술들

TL;DR

• 나는 에이전틱 엔지니어링이 사람의 반복 개입을 제거하는 방향으로 갈 것이라고 생각한다.
• 사람의 검토를 필수로 유지하는 설계는 장기적으로 바뀔 가능성이 크다.

시작하며

소프트웨어 개발이라는 일은 그 자체가 목적이라고 생각하지 않는다. 비즈니스 요구사항을 컴퓨터로 처리하기 위한 부산물에 가깝다. 조금 더 거칠게 말하면, 개발은 비즈니스 요구사항을 코드로 전환하는 컴파일러다.

이 컴파일 과정을 위해 지금까지는 기획자, 디자이너, 프론트엔드 개발자, 백엔드 개발자, QA 등 수많은 전문가가 필요했다. 그런데 에이전트가 이 중간과정을 자동화하기 시작하면서 중간 레이어가 빠르게 얇아지고 있다.

오늘은 이 흐름의 방향성에 대해, 그리고 그 방향성 위에서 현재의 도구들이 어디쯤 서 있는지에 대해 최근 생각을 정리해보려고 한다.

1. 최종 목표는 human in the loop의 제거

개발 과정 자체는 이전 글들¹²에서 충분히 다뤘으니 넘어가고, 에이전틱 엔지니어링(agentic engineering)이라는 이름으로 불리는 이 흐름의 방향성을 한 문장으로 정리하면 이렇다.

나는 human in the loop, 즉 실행 과정에 반복적으로 개입하는 사람을 제거하는 것이 장기적인 목표라고 생각한다.

비즈니스 요구사항을 코드로 전환하는 과정에서 사람이 매번 구현하고 확인해야 하는 이유를 줄여나가자는 뜻이다. 완전히 제거할 수 있는지는 별개지만, 관련 회사들이 자원을 투입하며 이 방향으로 계속 시도할 것이라고 예상한다.

2. 사람이 남아 있는 이유와, 그 이유의 유한함

현실에서는 아직 파이프라인 곳곳에 사람이 남아 있다. 지금 가장 가까운 병목은 리뷰다. 현재 에이전트의 출력이 비즈니스 요구사항과 기술 요구사항을 100% 반영하지 못한다고 여겨지기 때문에, 결국 사람이 마지막에 한 번 더 들여다봐야 한다는 전제가 파이프라인 안에 남아 있다. 생성 속도는 이미 사람의 리뷰 역량을 앞질렀고, “딸깍해서 나온 코드를 리뷰하기가 어렵다”라는 말도 이 전제에서 나온다.

하지만 이 문제는 모델이 좋아진다고 저절로 사라지지는 않는다. 생성하는 쪽이 검증까지 책임지는 구조로 움직이고 있지만, 반복되는 리뷰 판단을 계약·테스트·가드레일로 옮기고 새 계약·모순·고위험 예외만 사람에게 올리는 하네스가 함께 필요하다.³

모델의 발전은 에이전트가 스스로 닫을 수 있는 범위를 넓혀주지만, 실제 병목을 줄이는 일은 별도의 엔지니어링 문제에 가깝다.

리뷰 다음에는 배포가 병목이 될 수 있다. 패키징과 이미지 빌드, 환경 설정은 이미 자동화할 수 있지만, 실제 서비스에 반영할지와 실패 시 이전 버전으로 되돌릴지를 매번 사람이 결정하는 팀에서는 그 판단이 남는다.

이 지점은 개발 단계에도 영향을 미친다. 모든 변경이 사람의 승인을 기다려야 한다면, 앞 단계가 빨라져도 전체 처리량은 승인 속도에 묶일 수 있다. 이때는 사람이 판단할 변경과 자동으로 확인할 변경을 구분하고, 판단에 필요한 근거를 개발 중에 함께 준비해야 한다.

두 병목 모두 지금은 실재하지만, 모델과 하네스, 배포·운영 자동화가 발전하면서 범위가 줄어들 수 있다는 점에서 유한한 병목이다. 중요한 것은 이 병목이 사라지기 시작할 때 어떤 도구들이 그 흐름에 올라탈 수 있는가이다.

3. 공존을 전제로 한 설계와, 사람 제거를 전제로 한 설계

현재 에이전틱 개발 도구들은 크게 두 가지 설계 전제로 갈라지고 있다고 본다. 사람과의 공존을 전제로 설계된 것과, 사람 제거를 전제로 설계된 것이다.

내가 Cursor를 IDE 안에서 사용하며 익숙해진 방식은 에이전트의 변경을 사람이 확인하며 진행하는 것이다. 지금의 작업에는 유용하지만, 매 변경마다 사람의 검토를 필수로 유지하는 동안에는 처리량이 검토 속도에 묶일 수 있다.

이는 특정 제품이 앞으로도 바뀌지 못한다는 뜻은 아니다. 여기서는 제품 이름보다 사람의 검토를 어느 단계에서 필수로 두는지에 따라 설계를 나눠보려 한다.

내가 관심을 두는 쪽은 대화형 화면 없이 실행하는 헤드리스 코딩 에이전트나 Anthropic의 Managed Agents 같은 장기 실행 환경이다. Managed Agents는 에이전트의 도구 실행과 작업 환경을 관리해주지만, 우리 서비스의 검증 기준이나 배포 승인까지 대신 정해주는 것은 아니다.⁴

이런 환경 위에 테스트와 배포·복구 절차를 연결해, 사람이 다음 지시를 줄 때까지 기다리지 않고 작업을 이어가게 하고 싶다. 어떤 제품을 쓰느냐보다 그 구성을 실제로 만들 수 있느냐를 보려 한다.

모델이 더 좋아져도 모든 변경을 사람이 확인하는 절차가 그대로라면 검토 대기는 남는다. 그중 반복 가능한 판단을 테스트와 하네스로 옮겨야 모델이 넓힌 작업 범위를 활용할 수 있다.

4. 공존 지향 기술은 과도기적이다

이 관점에서 사람의 반복 검토를 필수로 유지하는 설계는 과도기적이라고 생각한다.

현재의 리뷰와 배포 병목 때문에 공존 지향 도구는 지금 가장 실용적인 선택지다. 그러나 이 병목들이 하나씩 사라지는 순간, 같은 도구들의 존재 이유도 함께 줄어든다. 공존 자체가 가치를 주던 이유는 “사람이 꼭 개입해야 한다”는 전제 때문이었는데, 그 전제가 먼저 흔들리기 때문이다.

그래서 도구를 볼 때는 지금의 완성도와 함께, 모델이 더 많은 일을 맡게 되었을 때 사람의 반복 검토를 얼마나 줄일 수 있는지도 보려 한다.

마치며

지금 어떤 도구를 쓸지는 현재 작업에서 잘 동작하는지를 보고 정하면 된다. 다만 장기적으로 투자할 방향은 구분해서 생각하고 싶다.

나는 정상 경로의 반복 판단을 사람에게서 하네스로 옮길 수 있는 도구와 설계에 더 시간을 쓰려 한다. 남아 있는 리뷰와 배포의 병목을 실제로 줄이는지가 그 선택을 확인할 기준이다.

• #ai
• #agent
• #harness-engineering
• #agentic-development
• #claude-code
• #headless