<div id="readability-page-1" class="page"><div>
  <h2>에이전틱 엔지니어링과 과도기적 기술들</h2>
  
  <p><span>2026년 05월 11일 작성</span></p><h2 id="tldr">TL;DR</h2>

<ul>
  <li>에이전틱 엔지니어링의 최종 방향은 <strong>human in the loop의 제거</strong>이며, 이 흐름 속에서 사람을 파이프라인 안에 유지하기 위해 설계된 도구들은 <strong>과도기적 기술</strong>로 남을 가능성이 크다.</li>
</ul>

<h2 id="시작하며">시작하며</h2>

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

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

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

<h2 id="1-최종-목표는-human-in-the-loop의-제거">1. 최종 목표는 human in the loop의 제거</h2>

<p>개발 과정 자체는 이전 글들<sup id="fnref:1" role="doc-noteref"><a href="#fn:1" rel="footnote">1</a></sup><sup id="fnref:2" role="doc-noteref"><a href="#fn:2" rel="footnote">2</a></sup>에서 충분히 다뤘으니 넘어가고, <strong>에이전틱 엔지니어링(agentic engineering)</strong>이라는 이름으로 불리는 이 흐름의 방향성을 한 문장으로 정리하면 이렇다.</p>

<p><strong>최종 목표는 human in the loop의 제거다.</strong></p>

<p>비즈니스 요구사항을 코드로 전환하는 컴파일 과정에서 사람 요소를 완전히 제거하는 것이 목표다. 이것이 실제로 가능한지 불가능한지는 이 방향성을 설명하는 데 있어서는 크게 중요하지 않다. <strong>누군가 “불가능하다”를 엄밀하게 증명하지 않는 이상, 관련 회사들은 자원이 공급되는 한 이 방향으로 계속 시도할 것이기 때문이다.</strong> 자율주행과 클라우드 마이그레이션이 그랬듯이, 업계 전체가 한 방향으로 움직이기 시작하면 개별적인 회의론은 흐름을 바꾸지 못한다.</p>

<h2 id="2-사람이-남아-있는-이유와-그-이유의-유한함">2. 사람이 남아 있는 이유와, 그 이유의 유한함</h2>

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

<p>하지만 이 문제는 코딩 에이전트와 개발 방법론이 발전하면서 자연스럽게 해결될 가능성이 크다고 본다. 생성하는 쪽이 검증까지 책임지는 구조로 이미 조금씩 움직이고 있고, 이 흐름은 모델의 기본 능력에 업혀서 해결되는 쪽이라 따로 새로운 엔지니어링 문제를 세우지 않아도 시간이 풀어주는 문제에 가깝다.</p>

<p>리뷰 다음에 남는 병목은 <strong>배포</strong>다. 로컬에서 만든 것을 프로덕션에 올리는 핸드오프에는 여전히 사람이 붙어야 한다. 코드를 패키징하고, 이미지를 빌드하고, 환경변수를 맞추고, 권한을 설정하고, 실패 시 롤백을 결정하는 일이 그렇다.</p>

<p>그리고 이 지점이 개발 단계까지 역으로 영향을 미친다. <strong>파이프라인의 끝에 사람의 개입 지점이 하나라도 남아 있으면, 그 앞 단계들은 결국 그 사람에게 맞춰져 설계된다.</strong> 배포 시점에 누군가 코드를 들여다보고 판단해야 한다면, 개발 단계에서도 “사람이 이해하고 검토할 수 있는 형태”를 유지해야 한다. 배포의 사람 의존성이 개발의 자동화 한계를 정해버리는 셈이다.</p>

<p>두 병목 모두 지금은 실재하지만, 시간이 풀어줄 문제라는 점에서 <strong>유한한 병목</strong>이다. 중요한 것은 이 병목이 사라지기 시작할 때 어떤 도구들이 그 흐름에 올라탈 수 있는가이다.</p>

<h2 id="3-공존을-전제로-한-설계와-사람-제거를-전제로-한-설계">3. 공존을 전제로 한 설계와, 사람 제거를 전제로 한 설계</h2>

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

<p>공존을 전제로 한 대표적인 예는 Cursor다. 사람이 IDE 안에서 에이전트와 나란히 앉아 한 줄씩 확인하며 움직이는 경험을 최적화한 도구다. 좋은 경험이고, 지금 시점의 생산성 관점에서는 매우 강력하다. 다만 설계의 출발점에 사람이 남아 있다는 것은, <strong>아무리 자동화를 더해도 “사람이 보는 속도”가 파이프라인의 상한이 된다</strong>는 뜻이기도 하다. 지금까지의 클라우드 인프라 흐름(VM, 컨테이너, 서버리스, 각종 PaaS와 GitOps 도구)도 큰 틀에서는 이 축에 가깝다. “사람이 이 일을 더 쉽게 할 수 있게” 돕는 방향이었지, 사람을 빼는 방향이 아니었다.</p>

<p>반대 축에는 헤드리스 코딩 에이전트 구성이나 Anthropic의 Managed Agents 같은 접근이 있다. 이쪽은 출발점부터 사람을 빼고 시작한다. 에이전트가 스스로 루프를 돌리고, 스스로 검증하고, 스스로 배포하는 것을 기본 모드로 본다. 당장의 사용성은 공존형 도구보다 거칠 수 있지만, LLM과 에이전트가 더 발전할수록 그 상한선이 같이 올라간다.</p>

<p>이 둘 사이의 간극이 중요한 이유는 이것이 단순한 UX 차이가 아니라 <strong>설계 전제의 차이</strong>이기 때문이다. 공존을 전제로 만든 도구는 LLM이 더 똑똑해져도 그 능력을 “사람이 확인할 수 있는 범위” 안에서만 풀어낼 수 있다. 반면 사람 제거를 전제로 만든 도구는 모델이 좋아지는 만큼 그대로 상향된다.</p>

<h2 id="4-공존-지향-기술은-과도기적이다">4. 공존 지향 기술은 과도기적이다</h2>

<p>이 구분을 1장에서 정리한 방향성 위에 얹으면 결론은 꽤 명확해진다. <strong>사람을 파이프라인 안에 보존하기 위해 설계된 기술들은 과도기적이다.</strong></p>

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

<p>이 관점에서 보면, 과도기적 기술과 지속적 기술의 차이는 현재의 완성도가 아니라 <strong>설계 전제가 어느 방향을 향하고 있는가</strong>에 달려 있다. 공존을 전제로 만들어진 좋은 도구는 <strong>지금</strong> 강력하고, 사람 제거를 전제로 만들어진 도구는 <strong>나중</strong>에 강력해진다. 전자는 모델 발전의 혜택을 “사람이 볼 수 있는 속도”에 묶어두고, 후자는 그 흐름을 그대로 흡수한다.</p>

<h2 id="마치며">마치며</h2>

<p>에이전틱 엔지니어링의 방향은 분명하다. human in the loop의 제거다. 지금은 리뷰와 배포 같은 병목이 남아 있어 사람이 파이프라인 안에 자리를 차지하고 있지만, 이 병목들은 모델과 에이전트가 발전하면서 점진적으로 해체될 것이다.</p>

<p>그 과정에서 <strong>공존을 전제로 설계된 도구들은 과도기를 밝혀주는 조명</strong>에 가깝다. 지금의 생산성을 올려주는 매우 유용한 수단이지만, 방향성 위에서 보면 결국 에이전틱 엔지니어링 자체의 발전에 의해 대체되거나 조용히 잊히는 자리로 밀려날 가능성이 크다.</p>

<p>지금 어떤 도구를 쓸지는 실용의 문제이고, 어느 방향을 베팅할지는 별개의 문제다. 개인적으로 후자에서는 <strong>사람 제거를 전제로 설계된 도구들</strong> 쪽에 서는 편이 장기적으로 더 나은 선택지라고 본다.</p>

<hr>



</div></div>

Haandol

TL;DR
에이전틱 엔지니어링의 최종 방향은 human in the loop의 제거이며, 이 흐름 속에서 사람을 파이프라인 안에 유지하기 위해 설계된 도구들은 과도기적 기술로 남을 가능성이 크다.
시작하며
소프트웨어 개발이라는 일은 그 자체가 목적이라고 생각하지 않는다. 비즈니스 요구사항을 컴퓨터로 처리하기 위한 부산물에 가깝다. 조금 더 거칠게 말하면, 개발은 비즈니스 요구사항을 코드로 전환하는 컴파일러다.
이 컴파일 과정을 위해 지금까지는 기획자, 디자이너, 프론트엔드 개발자, 백엔드 개발자, QA 등 수많은 전문가가 필요했다. 그런데 에이전트가 이 중간과정을 자동화하기 시작하면서 중간 레이어가 빠르게 얇아지고 있다.
오늘은 이 흐름의 방향성에 대해, 그리고 그 방향성 위에서 현재의 도구들이 어디쯤 서 있는지에 대해 최근 생각을 정리해보려고 한다.
1. 최종 목표는 human in the loop의 제거
개발 과정 자체는 이전 글들12에서 충분히 다뤘으니 넘어가고, 에이전틱 엔지니어링(agentic engineering)이라는 이름으로 불리는 이 흐름의 방향성을 한 문장으로 정리하면 이렇다.
최종 목표는 human in the loop의 제거다.
비즈니스 요구사항을 코드로 전환하는 컴파일 과정에서 사람 요소를 완전히 제거하는 것이 목표다. 이것이 실제로 가능한지 불가능한지는 이 방향성을 설명하는 데 있어서는 크게 중요하지 않다. 누군가 “불가능하다”를 엄밀하게 증명하지 않는 이상, 관련 회사들은 자원이 공급되는 한 이 방향으로 계속 시도할 것이기 때문이다. 자율주행과 클라우드 마이그레이션이 그랬듯이, 업계 전체가 한 방향으로 움직이기 시작하면 개별적인 회의론은 흐름을 바꾸지 못한다.
2. 사람이 남아 있는 이유와, 그 이유의 유한함
현실에서는 아직 파이프라인 곳곳에 사람이 남아 있다. 지금 가장 가까운 병목은 리뷰다. 현재 에이전트의 출력이 비즈니스 요구사항과 기술 요구사항을 100% 반영하지 못한다고 여겨지기 때문에, 결국 사람이 마지막에 한 번 더 들여다봐야 한다는 전제가 파이프라인 안에 박혀 있다. 생성 속도는 이미 사람의 리뷰 역량을 앞질렀고, “딸깍해서 나온 코드를 리뷰하기가 어렵다”라는 말도 이 전제에서 나온다.
하지만 이 문제는 코딩 에이전트와 개발 방법론이 발전하면서 자연스럽게 해결될 가능성이 크다고 본다. 생성하는 쪽이 검증까지 책임지는 구조로 이미 조금씩 움직이고 있고, 이 흐름은 모델의 기본 능력에 업혀서 해결되는 쪽이라 따로 새로운 엔지니어링 문제를 세우지 않아도 시간이 풀어주는 문제에 가깝다.
리뷰 다음에 남는 병목은 배포다. 로컬에서 만든 것을 프로덕션에 올리는 핸드오프에는 여전히 사람이 붙어야 한다. 코드를 패키징하고, 이미지를 빌드하고, 환경변수를 맞추고, 권한을 설정하고, 실패 시 롤백을 결정하는 일이 그렇다.
그리고 이 지점이 개발 단계까지 역으로 영향을 미친다. 파이프라인의 끝에 사람의 개입 지점이 하나라도 남아 있으면, 그 앞 단계들은 결국 그 사람에게 맞춰져 설계된다. 배포 시점에 누군가 코드를 들여다보고 판단해야 한다면, 개발 단계에서도 “사람이 이해하고 검토할 수 있는 형태”를 유지해야 한다. 배포의 사람 의존성이 개발의 자동화 한계를 정해버리는 셈이다.
두 병목 모두 지금은 실재하지만, 시간이 풀어줄 문제라는 점에서 유한한 병목이다. 중요한 것은 이 병목이 사라지기 시작할 때 어떤 도구들이 그 흐름에 올라탈 수 있는가이다.
3. 공존을 전제로 한 설계와, 사람 제거를 전제로 한 설계
현재 에이전틱 개발 도구들은 크게 두 가지 설계 전제로 갈라지고 있다고 본다. 사람과의 공존을 전제로 설계된 것과, 사람 제거를 전제로 설계된 것이다.
공존을 전제로 한 대표적인 예는 Cursor다. 사람이 IDE 안에서 에이전트와 나란히 앉아 한 줄씩 확인하며 움직이는 경험을 최적화한 도구다. 좋은 경험이고, 지금 시점의 생산성 관점에서는 매우 강력하다. 다만 설계의 출발점에 사람이 남아 있다는 것은, 아무리 자동화를 더해도 “사람이 보는 속도”가 파이프라인의 상한이 된다는 뜻이기도 하다. 지금까지의 클라우드 인프라 흐름(VM, 컨테이너, 서버리스, 각종 PaaS와 GitOps 도구)도 큰 틀에서는 이 축에 가깝다. “사람이 이 일을 더 쉽게 할 수 있게” 돕는 방향이었지, 사람을 빼는 방향이 아니었다.
반대 축에는 헤드리스 코딩 에이전트 구성이나 Anthropic의 Managed Agents 같은 접근이 있다. 이쪽은 출발점부터 사람을 빼고 시작한다. 에이전트가 스스로 루프를 돌리고, 스스로 검증하고, 스스로 배포하는 것을 기본 모드로 본다. 당장의 사용성은 공존형 도구보다 거칠 수 있지만, LLM과 에이전트가 더 발전할수록 그 상한선이 같이 올라간다.
이 둘 사이의 간극이 중요한 이유는 이것이 단순한 UX 차이가 아니라 설계 전제의 차이이기 때문이다. 공존을 전제로 만든 도구는 LLM이 더 똑똑해져도 그 능력을 “사람이 확인할 수 있는 범위” 안에서만 풀어낼 수 있다. 반면 사람 제거를 전제로 만든 도구는 모델이 좋아지는 만큼 그대로 상향된다.
4. 공존 지향 기술은 과도기적이다
이 구분을 1장에서 정리한 방향성 위에 얹으면 결론은 꽤 명확해진다. 사람을 파이프라인 안에 보존하기 위해 설계된 기술들은 과도기적이다.
현재의 리뷰와 배포 병목 때문에 공존 지향 도구는 지금 가장 실용적인 선택지다. 그러나 이 병목들이 하나씩 사라지는 순간, 같은 도구들의 존재 이유도 함께 줄어든다. 공존 자체가 가치를 주던 이유는 “사람이 꼭 개입해야 한다”는 전제 때문이었는데, 그 전제가 먼저 흔들리기 때문이다.
이 관점에서 보면, 과도기적 기술과 지속적 기술의 차이는 현재의 완성도가 아니라 설계 전제가 어느 방향을 향하고 있는가에 달려 있다. 공존을 전제로 만들어진 좋은 도구는 지금 강력하고, 사람 제거를 전제로 만들어진 도구는 나중에 강력해진다. 전자는 모델 발전의 혜택을 “사람이 볼 수 있는 속도”에 묶어두고, 후자는 그 흐름을 그대로 흡수한다.
마치며
에이전틱 엔지니어링의 방향은 분명하다. human in the loop의 제거다. 지금은 리뷰와 배포 같은 병목이 남아 있어 사람이 파이프라인 안에 자리를 차지하고 있지만, 이 병목들은 모델과 에이전트가 발전하면서 점진적으로 해체될 것이다.
그 과정에서 공존을 전제로 설계된 도구들은 과도기를 밝혀주는 조명에 가깝다. 지금의 생산성을 올려주는 매우 유용한 수단이지만, 방향성 위에서 보면 결국 에이전틱 엔지니어링 자체의 발전에 의해 대체되거나 조용히 잊히는 자리로 밀려날 가능성이 크다.
지금 어떤 도구를 쓸지는 실용의 문제이고, 어느 방향을 베팅할지는 별개의 문제다. 개인적으로 후자에서는 사람 제거를 전제로 설계된 도구들 쪽에 서는 편이 장기적으로 더 나은 선택지라고 본다.
쉽게 설명한 하네스 엔지니어링 ↩
하네스 없는 멀티 에이전트는 그냥 컨텍스트 엔지니어링이다 ↩

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

댓글