에이전틱 엔지니어링 (Agentic Engineering)

AI 에이전트를 「Orchestrate」 하는 기술

이 시리즈는 「AI 개발 규율의 진화」를 순서대로 해설합니다.

본 기사는 제3회: Agentic Engineering입니다.

제1회 「Prompt Engineering」, 제2회 「Context Engineering」은 이쪽으로 → (링크)

Karpathy가 느낀 「처음으로 느낀 초조함」

Andrej Karpathy——OpenAI 공동 창립자이자 Tesla의 AI 책임자를 역임한 인물——이 2025년 Sequoia AI Ascent에서 이렇게 말했다.

"나는 프로그래머로서, 처음으로 자신이 시대에 뒤처지고 있다고 느꼈다"

세계 최고 수준의 AI 연구자가 AI 개발 도구를 따라잡지 못하고 있다고 느꼈다. 왜일까.

2025년 말부터 AI 에이전트가 한 번에 담당할 수 있는 작업의 입도(granularity)가 급격히 커졌다. 「1줄 완성」에서 「기능 통째로 구현」으로. 「함수를 작성」하는 것에서 「서비스를 설계하고 구현하여 테스트」하는 것으로.

그때 깨달은 것이다. 자신이 세세하게 프롬프트를 입력하는 것보다, 에이전트에게 통째로 맡기고 감독하는 것이 훨씬 생산적이다라고.

그리고 그는 Vibe Coding의 다음 규율에 이름을 붙였다. Agentic Engineering (에이전틱 엔지니어링) 이다.

Vibe Coding과 Agentic Engineering의 차이

먼저 전제로 「Vibe Coding」을 정리한다.

Vibe Coding이란, Karpathy가 2025년 2월에 제창한 용어다. 「AI에게 분위기(vibe)로 지시하고, 나온 코드를 그대로 사용하는」 스타일. 프로토타입이나 개인의 실험에는 최적이지만, 실제 프로덕션(production) 제품에는 적합하지 않다.

Karpathy는 이렇게 말했다.

"Vibe coding은 바닥(floor)을 높인다. 하지만 천장(ceiling)을 끌어올리는 것은 소프트웨어 엔지니어링 (Software Engineering, 규율)이다"

Vibe Coding으로 「누구나 움직이는 것을 만들 수 있는 밑바닥」은 올라갔다. 하지만 프로덕션 품질·보안성·유지보수성이라는 「천장」을 끌어올리는 것은 여전히 엔지니어링 규율의 몫이다.

그 엔지니어링 규율을 에이전트 시대에 구체화한 것——그것이 본 기사에서 다루는 「Agentic Engineering」이다.

현실 세계의 비유

건설 현장의 「현장 감독」

대규모 건축 프로젝트를 상상해 보길 바란다.

Vibe Coding 스타일의 현장 감독:

"느낌 좋은 빌딩을 지어주세요"라고 기술자에게 말하고, 완성된 것을 보고 "왠지 좀 다르네"라고 다시 말한다. 설계도 없음, 공정 관리 없음, 품질 검사 없음. 오두막이라면 통하겠지만, 고층 빌딩은 불가능하다.

Agentic Engineering 스타일의 현장 감독:

먼저 설계도(사양)를 작성한다. 공정을 분할하고, 미장·전기·배관 기술자(전문 에이전트)에게 역할을 할당한다. 각 공정에 품질 검사(테스트)를 둔다. 완성된 부분을 확인하고, 다음 공정에 GO 사인을 보낸다.

현장 감독이 하는 일은 「벽돌을 쌓는」 것이 아니다. **「벽돌을 쌓는 기술자들을 올바르게 움직이는 시스템을 설계·감독하는 것」**이다.

Agentic Engineering에서의 엔지니어란, 바로 이 「현장 감독」이다.

Agentic Engineering이란 무엇인가

IBM과 Karpathy의 정의를 조합하면 가장 이해하기 쉽다.

"Agentic Engineering이란, 하나 이상의 AI 에이전트를 orchestrate (지휘)하고, 사양·품질 기준·보안·아키텍처 판단에 책임을 지면서, 프로덕션 등급(production-grade)의 소프트웨어를 만들어내는 전문적인 규율이다"

키워드는 두 가지.

「Agentic」 = 코드를 작성하는 것은 99% 에이전트. 인간은 에이전트를 감독·검증하는 측으로 돌아간다.

「Engineering」 = 분위기가 아니라, 설계·측정·개선의 반복이 요구되는 전문 기술.

PEV 루프: 에이전틱 엔지니어링의 핵심

Agentic Engineering의 중심에 있는 실행 사이클이 PEV 루프다.

Plan (계획)
↓
Execute (실행)
...

Plan (계획)

태스크를 에이전트에게 넘기기 전에, 사양을 명확히 하는 단계.

Vibe Coding과의 가장 큰 차이점은 바로 이 지점이다. "구현해 주세요"가 아니라, "무엇을 만들 것인가", "완료 조건은 무엇인가", "무엇을 해서는 안 되는가"를 사전에 정의한다.

# 태스크 사양서(Task Specification) 예시
## 목적
사용자 인증 API 구현
...

"사양서를 쓰는 시간이 아깝다"고 느낄지도 모른다. 하지만 이것이 없으면 에이전트는 "그럴싸한 코드"를 생성할 뿐, 의도한 대로의 구현에는 도달하지 못한다.

Plan(계획) 단계를 뒷받침하는 「리포지토리의 컨텍스트 설계」

실무에서 에이전트를 자율 구동시키다 보면, 사양서만으로는 부족하다는 것을 깨닫게 된다. 에이전트가 코드베이스에서 길을 잃기(Lost in codebase) 때문이다.

"이 프로젝트의 아키텍처(Architecture)는 어떻게 되어 있는가", "어느 디렉토리에 무엇이 놓여 있는가", "기존의 패턴은 어떤 것을 참고해야 하는가" —— 이 정보들이 에이전트에게 전달되지 않으면 사양서대로의 구현이 이루어지지 않는다.

여기서 지난번 컨텍스트 엔지니어링(Context Engineering)의 지견이 직접적으로 활용된다.

# 에이전트용 README (LLM-First 구성)
## 이 리포지토리의 전체 구조
/src
...

에이전트가 망설임 없이 움직일 수 있을지는 이 컨텍스트 설계의 질에 의해 9할이 결정된다. Plan 단계의 성패는 코드베이스가 LLM이 읽기 쉽도록 정비되어 있는지에 달려 있다.

Execute (실행)

사양을 전달받은 에이전트가 코드를 생성하는 단계. 여기는 기본적으로 에이전트에게 맡긴다.

다만 매크로 액션(Macro Action)으로 위임하는 것이 포인트다.

❌ 세세하게 일일이 지시하기 (Vibe Coding의 함정)
"먼저 파일을 만들어줘"
"다음으로 함수를 정의해줘"
...

인간이 한 단계씩 지시하고 있는 동안에는 에이전트 본연의 힘을 끌어낼 수 없다.

Verify (검증)

에이전트의 출력을 기계적·인간적 양면에서 검증하는 단계.

# 기계적 검증 (자동화 가능)
def verify_implementation():
results = {
...

Karpathy가 강조하는 점은 인간적 검증을 생략해서는 안 된다는 것이다.

"당신은 Vibe Coding을 이유로 취약성을 도입해서는 안 된다. 이전과 마찬가지로, 당신은 자신의 소프트웨어에 책임을 진다."

테스트를 통과하더라도 설계로서 올바른지는 인간이 판단할 필요가 있다.

Agentic Engineering 시대, 엔지니어의 주전장은 「코드 리뷰」로 이동한다

이 점을 분명히 해두고 싶다.

기계적 검증(테스트 통과, Lint 통과)은 에이전트와 CI에 맡기면 된다. 하지만 Stripe의 이메일 사례가 보여주듯, 설계 사상의 버그는 테스트로 검출할 수 없다.

• "이 설계 판단은 비즈니스 로직(Business Logic)과 일치하는가"
• "미래의 확장을 고려했을 때, 이 아키텍처는 올바른가"
• "보안상의 의도하지 않은 부작용(Side Effect)이 없는가"

이것들은 코드가 동작하고 있더라도 보이지 않는 문제이며, 인간이 PR(Pull Request)을 읽어야 비로소 깨달을 수 있는 문제다.

Agentic Engineering 시대의 엔지니어의 주전장은 키보드를 두드리는 것이 아니라, 에이전트가 제출한 PR의 「코드 리뷰(인간적 검증)」로 이행한다.

코드를 빠르게 쓸 수 있느냐보다, 에이전트가 내놓은 코드의 품질을 꿰뚫어 볼 수 있느냐 —— 이것이 테크 리드(Tech Lead)에게 요구되는 핵심적인 스킬이 되어갈 것이다.

멀티 에이전트: 전문가 팀의 편성

Agentic Engineering의 발전 형태가 멀티 에이전트(Multi-Agent) 구성이다.

한 명의 만능 에이전트에게 전부 시키는 것이 아니라, 전문 에이전트를 역할별로 나누어 협조시킨다.

현실적인 비유를 들자면, 유능한 풀스택 엔지니어 1명에게 전부 맡기는 것보다 전문가 팀이 품질도 속도도 높다는 것과 같은 발상이다.

실제 수치로 보면, Stripe의 에이전트 시스템인 "Minions"는 주당 1,000건 이상의 PR을 머지(Merge)하고 있으며, TELUS는 13,000개의 AI 솔루션으로 50만 시간 이상의 공수를 절감하고 있다.

엔지니어의 역할 변화

Agentic Engineering이 보급되면 엔지니어의 업무는 변한다.

사라지는 업무:

• 보일러플레이트(Boilerplate) 코드 작성
• 단순한 CRUD 구현
• 테스트 케이스를 하나씩 작성하기

늘어나는 업무:

• 사양(Specification)을 명확하게 정의하기 (모호함 제거)
• 에이전트의 출력을 평가 및 검증하기
• 아키텍처(Architecture) 상의 판단 내리기
• 보안과 설계 품질에 대한 책임 갖기

Karpathy의 말이 가슴에 와닿는다.

"에이전트가 할 수 없는 것이 당신의 일이다. 그 외에는 에이전트의 것이다."

「Jagged Intelligence (기ザギザの知性, 들쭉날쭉한 지능)」를 주의하라

Agentic Engineering에서 가장 중요한 개념 중 하나가 「Jagged Intelligence」다.

AI 에이전트는 인간이 보기에 예측하기 어려운 부분에서 똑똑하고, 예측하기 어려운 부분에서 실수한다.

Karpathy가 실제로 경험한 사례가 상징적이다. 에이전트가 Stripe의 결제와 Google 계정을 이메일 주소로 연결하는 코드를 작성했다. 동작하는 코드다. 하지만 Stripe의 이메일과 Google의 로그인 이메일은 서로 다를 가능성이 있으며, 이는 설계로서 잘못된 것이었다. 테스트는 통과한다. 버그는 아니다. 하지만 실무(Production)에서는 사용할 수 없다.

이 들쭉날쭉한 부분을 파악하여, "어디는 맡기고 어디는 인간이 판단할 것인가"를 설계하는 것이 Agentic Engineering의 핵심이다.

요약

Agentic Engineering은 프롬프트 엔지니어링(Prompt Engineering)·컨텍스트 엔지니어링(Context Engineering) 위에 구축된다. 좋은 사양(Prompt)을 작성하고, 적절한 정보(Context)를 전달하며, 에이전트의 행동 사이클(Agentic)을 설계한다.

다음 기사에서는 이 에이전트가 움직이는 환경 그 자체를 설계하는 「하네스 엔지니어링(Harness Engineering)」을 다룬다. PEV 루프의 Verify를 기계적으로 강제하는 것이 하네스의 역할이다.

시리즈 목록

• 【첫 번째 기사】 왜 「○○ 엔지니어링」은 계속해서 생겨나는가 (공개 예정)
• 제1회: Prompt Engineering
• 제2회: Context Engineering
• [본 기사] 제3회: Agentic Engineering
• 제4회: Harness Engineering (공개 예정)
• 제5회: Loop Engineering (공개 예정)

Discussion