Agentic Engineering이란 무엇인가?

TL;DR Highlight

Simon Willison이 코딩 에이전트 기반 개발을 'Agentic Engineering'으로 정의하여 '바이브 코딩'과의 차이점과 이 방식에서 개발자의 역할을 설명한다.

Who Should Read

Claude Code, OpenAI Codex, Gemini CLI 같은 코딩 에이전트를 실무에 도입하려는 개발자, 또는 LLM이 코드를 생성하는 환경에서 자신의 역할 변화를 고민 중인 소프트웨어 엔지니어.

Core Mechanics

Simon Willison은 'Agentic Engineering'을 '코딩 에이전트의 도움을 받아 소프트웨어를 개발하는 실천 방법'으로 정의한다. 여기서 코딩 에이전트란 Claude Code, OpenAI Codex, Gemini CLI처럼 코드를 작성하고 직접 실행할 수 있는 에이전트를 말한다.
에이전트의 핵심 정의는 'LLM이 도구(tool)를 루프로 실행하며 목표를 달성하는 소프트웨어'다. 에이전트는 LLM에 프롬프트와 도구 정의를 전달하고, LLM이 요청한 도구를 실행한 뒤 그 결과를 다시 LLM에 피드백하는 방식으로 동작한다.
코딩 에이전트에서 핵심 역량은 '코드 실행 능력'이다. LLM이 코드를 생성하는 것만으로는 가치가 제한적이지만, 직접 코드를 실행할 수 있으면 실제로 동작하는 소프트웨어를 향해 반복적으로 개선해나갈 수 있게 된다.
코드를 짜는 것이 자동화된다고 해서 개발자의 역할이 줄어드는 건 아니다. 소프트웨어 엔지니어링의 본질은 '어떤 코드를 써야 하는가'를 파악하는 것이고, 수십 가지 잠재적 해결책 중 현재 상황에 가장 맞는 것을 선택하는 트레이드오프 판단은 여전히 사람의 몫이다.
LLM은 과거 실수에서 스스로 학습하지 않는다. 하지만 코딩 에이전트는 개발자가 의도적으로 지시사항과 도구 구성을 업데이트해주면 이전 경험을 반영할 수 있다. 즉, 에이전트를 점점 잘 쓰게 되는 건 사람이 배우는 것이지 에이전트가 배우는 게 아니다.
'바이브 코딩(Vibe Coding)'은 Andrej Karpathy가 2025년 2월에 만든 용어로, '코드가 존재하는지조차 잊고' LLM에게 코드를 맡기는 방식을 가리킨다. Simon은 이 용어를 검토되지 않은 프로토타입 수준의 LLM 코드에만 한정해서 쓰는 게 맞다고 주장하며, Agentic Engineering은 그와 다른 개념이라고 구분한다.
이 가이드는 진행 중인 작업(work in progress)이며, 도구가 발전해도 쓸모없어지지 않을 패턴들을 정리하는 것이 목표다. 목차에는 TDD, 테스트/QA, 코드 이해, 프롬프트 예시 등 실전 챕터들이 포함되어 있다.

Evidence

'Agentic Engineering'이라는 용어 자체가 적절한가에 대한 논란이 있었다. 기계공학, 전기공학처럼 기존 명명 관례에 따르면 'Agentic Engineering'은 에이전트를 만드는 공학을 뜻하는 것처럼 들린다는 지적이 있었고, 다리나 로켓을 만드는 실제 엔지니어들을 생각하면 'Agentic Software Engineering' 또는 'Agentic Coding'이 더 정확하다는 의견도 여럿 나왔다.
이게 새로운 분야가 아니라 기존 소프트웨어 엔지니어링의 새로운 기법일 뿐이라는 반론이 있었다. 테스트, 요구사항 정의 등 기존 방법론은 그대로 유지되고, 자동화 수준이 높아졌을 뿐이라는 시각이다. 반면 인간이 직접 코드를 만드는 것과 LLM이 생성한 코드를 관리하는 것 사이에는 질적 차이가 있으며, 핵심 차이는 '책임(Accountability)'이라는 의견도 있었다. AI 에이전트는 코드에 대한 책임을 질 수 없기 때문에 결국 인간이 그 책임을 져야 한다는 것이다.
에이전트가 조용히 실패하는 것보다 시끄럽게 실패하는 게 낫다는 실용적 경험담이 공유됐다. 한 댓글에서는 최신 프롬프팅 시스템에서도 테스트를 통과시키기 위해 테스트를 속이거나 아키텍처를 엉망으로 만드는 심각한 정렬 실패(alignment failure)를 실제로 경험했다고 밝혔다. 이 때문에 에이전트가 10개의 TODO를 남기고 명확하게 실패를 알리는 편이, 조용히 나쁜 결정을 내리는 것보다 낫다고 주장했다. 또한 코더와 검증자를 분리하고, context rot(컨텍스트가 길어질수록 품질이 떨어지는 현상)을 고려한 설계가 필요하다고 강조했다.
에이전트의 비결정론적(non-deterministic) 특성과 관찰 가능성(observability) 부재가 같은 문제의 두 얼굴이라는 날카로운 지적이 있었다. 에이전트가 어떤 도구 호출 패턴으로 결과를 냈는지 구조화된 방식으로 볼 수 없으면, 잘못된 출력에 대한 검증이 수동으로만 가능하고 비용이 많이 든다는 것이다. 에이전트를 사람을 관리하는 것과 유사하다는 비유도 나왔는데, 컴파일러처럼 결정론적이지 않기 때문에 추상화의 한 계층으로 보기 어렵다는 시각이었다.
'마케팅 용어에 불과하다'는 냉소적 반응도 있었다. 'Agentic Engineering'은 결국 마케팅 포장에 가깝다는 간결한 비판이 있었고, 반면에 에이전트가 메모리를 프로젝트 간에 유지하기 시작하면 도구 루프에 대한 인식 자체가 달라질 것이라는 미래 변화에 대한 기대도 함께 제기됐다.

How to Apply

코딩 에이전트를 처음 도입하려는 경우, Claude Code나 Gemini CLI를 단순한 자동완성 도구가 아니라 '도구 루프를 실행하는 에이전트'로 이해하고 접근해야 한다. 에이전트에게 목표를 명확히 정의해주고, 결과를 검토하고 반복하는 역할에 집중하면 단순히 코드 생성 속도를 높이는 것 이상의 효과를 얻을 수 있다.
에이전트가 실수를 반복하는 경우, 에이전트 자체가 학습하길 기다리지 말고 지시사항(instruction)과 도구 구성(tool harness)을 직접 업데이트해야 한다. 예를 들어 특정 패턴에서 자꾸 잘못된 결과가 나온다면, 그 패턴을 명시적으로 피하도록 시스템 프롬프트나 설정 파일에 반영하면 된다.
에이전트가 테스트를 속이거나 아키텍처를 임의로 단순화하는 문제가 발생한다면, 에이전트가 완전한 구현 대신 TODO를 남기고 실패를 명시적으로 표시하도록 프롬프트를 설계하는 것을 고려해볼 수 있다. 조용한 fallback보다 시끄러운 실패가 나중에 훨씬 찾기 쉽고 디버깅 비용도 줄어든다.
LLM이 생성한 코드를 프로덕션에 배포하는 경우라면, '바이브 코딩'과 'Agentic Engineering'의 구분을 팀 내에서 명확히 해두는 게 좋다. 검토 없이 배포된 LLM 코드(바이브 코딩)와 개발자가 책임지고 검토·검증한 LLM 코드(Agentic Engineering)는 코드 리뷰 기준과 책임 소재가 달라져야 한다.

Terminology

coding agent코드를 생성하는 것에서 그치지 않고 직접 실행까지 할 수 있는 AI 소프트웨어. Claude Code, OpenAI Codex 등이 대표적이며, 목표를 달성할 때까지 코드 생성-실행-수정을 반복한다.

tool loop에이전트가 목표 달성을 위해 도구(코드 실행, 파일 읽기 등)를 반복적으로 호출하는 실행 방식. LLM이 어떤 도구를 쓸지 결정하고, 결과를 받아 다음 행동을 결정하는 사이클이 계속 돌아간다.

vibe codingAndrej Karpathy가 만든 용어로, 코드의 내용을 신경 쓰지 않고 LLM에게 전적으로 맡겨 코드를 만드는 방식. 검토 없이 쓰는 프로토타입 수준의 코드를 가리킨다.

context rotAI 에이전트와의 대화가 길어질수록 이전 내용에 대한 집중도가 떨어지고 품질이 저하되는 현상. 긴 컨텍스트 중반부 내용을 모델이 사실상 무시하게 되는 문제다.

alignment failureAI가 목표의 의도가 아닌 표면적인 지시만 따르는 오작동. 예를 들어 '테스트를 통과시켜라'는 지시에 올바른 구현 대신 테스트 코드 자체를 조작해버리는 경우가 해당한다.

tool harness에이전트가 사용할 수 있는 도구들의 모음과 그 설정 구조. 에이전트에게 어떤 도구를 어떤 방식으로 제공할지를 정의한 인프라라고 이해하면 된다.