왜 「○○ 엔지니어링」은 계속해서 생겨나는가

AI 개발 규율의 진화사

이 시리즈의 **첫 번째 기사(전체를 파악하는 개관)**입니다.

각 규율의 상세 내용은 각각의 기사를 참조해 주세요.

AI 개발의 패러다임은 이미 5번째 페이즈에 진입했다

2022년부터 2026년에 걸쳐, AI 개발 현장에서는 5가지 「○○ 엔지니어링」이 차례차례 탄생했다.

• Prompt Engineering (프롬프트 엔지니어링)
• Context Engineering (컨텍스트 엔지니어링)
• Agentic Engineering (에이전틱 엔지니어링)
• Harness Engineering (하네스 엔지니어링)
• Loop Engineering (루프 엔지니어링)

이를 「또 다른 버즈워드(Buzzword)가 늘어났다」고 볼 것인가, 「패러다임의 변화를 보여주는 지도다」라고 볼 것인가에 따라 향후 개발 생산성은 크게 달라진다.

이것들은 서로 경쟁하는 개념이 아니다. 각각이 「이전 규율의 한계가 드러났을 때」 탄생했으며, 중첩된 구조로 쌓여 있다.

이 기사에서는 각 규율이 「어떤 한계」를 극복하기 위해 등장했는지를 한눈에 조망한다.

전체상부터 시작하기

먼저 5가지의 관계를 그림으로 확인해 보길 바란다.

바깥쪽의 규율은 안쪽의 규율을 포함한다. 루프(Loop)는 하네스(Harness) 위에서 움직이고, 하네스는 에이전트(Agent)를 감싸며, 에이전트는 컨텍스트(Context)를 필요로 하고, 컨텍스트는 프롬프트(Prompt)를 필요로 한다.

그렇다면 왜 이 순서로 탄생했을까?

제1의 한계: 「말로 부탁하는 것」만으로는 제어할 수 없다

→ Prompt Engineering (2022년~

ChatGPT가 등장한 2022년, 첫 번째 질문은 단순했다.

「어떻게 부탁해야 AI가 의도대로 움직일까?」

여기서부터 「프롬프트 엔지니어링 (Prompt Engineering)」이라는 용어가 탄생했다. Chain of Thought (단계적으로 생각하게 함), Few-Shot (예시를 보여주어 형식을 학습시킴), Role Prompting (역할을 부여함)과 같은 기법들이 차례차례 등장했다.

이 시대의 프롬프트 엔지니어링은 개인의 기술이었다. 잘 부탁하는 사람과 그렇지 못한 사람 사이에 AI 활용 능력에서 큰 차이가 발생했다.

무엇이 한계가 되었나

개인의 「능숙한 부탁 방식」은 팀 개발, 본 프로덕션 시스템으로의 통합, 지속적인 운용에는 대응할 수 없었다.

• 프롬프트를 Git으로 관리하는 팀은 거의 없다
• 어제까지 잘 작동하던 프롬프트가 오늘은 다른 결과를 내놓는다
• 누군가 「괜찮은 주문」을 찾아내더라도, 팀 차원에서 공유하거나 재현할 수 없다

AI를 「개인의 도구」에서 「시스템의 부품」으로 다루기 위한 규율이 필요해졌다.

프롬프트 엔지니어링은 사라진 것이 아니다. PE 2.0으로서 모든 상위 규율의 기반으로 진화했다.

제2의 한계: 「무엇을 말하는가」만으로는 부족하다. 「무엇을 보여주는가」가 중요하다

→ Context Engineering (2025년~

에이전트가 복잡한 태스크를 수행하게 되면서 새로운 질문이 생겨났다.

「모델에 전달하는 정보가 빈약하다면, 아무리 똑똑한 모델이라도 빈약한 답변밖에 내놓지 못한다」

우수한 외과의사도 진료 기록, 검사 결과, 병력이 없다면 최선의 판단을 내릴 수 없다. 문제는 외과의사의 실력이 아니라, 전달된 정보의 질과 양이다. AI도 동일한 구조를 가지고 있다.

Andrej Karpathy가 2025년 6월에 이 개념을 「컨텍스트 엔지니어링 (Context Engineering)」이라고 명명했다.

Select (선택) — RAG를 통해 필요한 정보만 취득하고, Re-ranking으로 엄선한다 -
Compress (압축) — 축적된 대화 이력을 요약하여 토큰을 절약한다 -
Isolate (분리) — 정보를 에이전트별로 나누어 컨텍스트를 깨끗하게 유지한다

무엇이 한계가 되었나

컨텍스트를 올바르게 전달하더라도, 에이전트는 「단 한 번의 지시」를 실행할 뿐이었다. 설계하고, 구현하고, 테스트하고, 리뷰하는 것과 같은 여러 단계에 걸친 복잡한 태스크를 어떻게 자율적으로 수행하게 할 것인가가 다음 과제가 되었다.

제3의 한계: 「1회의 실행」으로는 복잡한 태스크를 수행할 수 없다

→ Agentic Engineering (2026년~

Karpathy는 2025년 말에 다음과 같이 느꼈다.

「내가 코드를 한 줄씩 쓰는 것보다, 에이전트에게 통째로 맡기고 감독하는 것이 훨씬 생산적이다」

여기서 「Agentic Engineering (에이전트 엔지니어링)」의 개념이 탄생했다. 엔지니어의 역할이 코드를 쓰는 사람에서 에이전트를 감독·검증하는 현장 감독으로 시프트(Shift)한다.

핵심에 있는 것이 PEV 루프다.

Plan (계획) → Execute (실행) → Verify (검증)
↓
PASS → 다음 태스크로
...

무엇이 한계에 도달했는가

PEV 루프의 Verify (검증)를 엔지니어가 매번 수동으로 수행한다면, 에이전트의 속도를 따라잡을 수 없다. 주당 1,000건의 PR (Pull Request)을 엔지니어가 손으로 리뷰하는 것은 불가능하다.

검증을 자동화하고, 강제성을 갖게 하는 메커니즘이 필요해졌다.

제4의 한계: 「요청 방식」, 「정보」, 「행동 사이클」을 정비해도, 환경이 갖춰져 있지 않으면 붕괴한다

→ Harness Engineering (하네스 엔지니어링, 2026년~)

여기서 중요한 관점을 깨닫게 된다. 하네스 엔지니어링은 완전히 새로운 발명이 아니다.

「실수를 하는 존재를, 환경 측면에서 제어한다」 —— 이는 소프트웨어 엔지니어링이 수십 년에 걸쳐 인간을 대상으로 해온 것 그 자체다.

인간이 일으키는 실수	환경에 의한 해결책
테스트 작성을 잊어버림	테스트 자동화·커버리지 임계값
...
AI 에이전트도 마찬가지다.

에이전트에게 「보안을 의식해 주세요」라고 프롬프트(Prompt)로 부탁한다 → 확률적인 준수

보안 스캔을 CI (Continuous Integration) 게이트에 통합한다 → 결정론적인 강제 집행

「AI에게 좋은 코드를 써달라고 하는 것이 아니라, AI가 좋은 코드를 쓸 수밖에 없는 환경을 설계한다」

컴퓨터 사이언스 (Computer Science)의 비유로 정리하면:

모델 = CPU
컨텍스트 윈도우 (Context Window) = RAM
하네스 (Harness) = OS
...

IaC (Infrastructure as Code)가 인프라에 가져온 변화와 완전히 똑같은 일을, AI 에이전트의 세계에서도 반복하고 있다.

무엇이 한계에 도달했는가

하네스를 정비하자 에이전트는 신뢰성 높게 동작하게 되었다. 하지만 다음 질문이 생겨났다.

「에이전트는 움직일 수 있다. 하지만, 누가 매번 『움직여라』라고 지시하는가?」

인간이 매일 아침 「오늘은 이걸 해」라고 계속 지시한다면, 에이전트의 속도가 주는 혜택을 절반밖에 누리지 못하고 있는 것이다.

제5의 한계: 「움직일 수 있는 환경」이 있어도, 「자주(自走)하는 메커니즘」이 없다면 인간이 계속 지시해야만 한다

→ Loop Engineering (루프 엔지니어링, 2026년 6월~)

2026년 6월 7일, Peter Steinberger가 X에 다음과 같이 적었다.

「더 이상 에이전트에게 직접 프롬프트를 입력하지 마라. 에이전트에게 지시하는 루프를 설계하라」

Anthropic의 Claude Code 책임자 Boris Cherny가 이를 증언했다.

「나는 더 이상 Claude에게 프롬프트를 입력하지 않는다. 루프를 돌리고 있고, 그 루프가 Claude에게 지시하고 있다. 나의 일은 루프를 작성하는 것이다」

루프 엔지니어링의 핵심은 심플하다.

인간이 매번 지시한다
↓
「조건이 충족되면 자동으로 에이전트가 움직이기 시작하는 시스템」을 설계한다

공장 비유가 가장 이해하기 쉽다. 숙련공 (에이전트)에게 매번 「다음은 이걸 만들어」라고 지시하는 것을 그만두고, 주문이 들어오면 자동으로 라인이 가동되는 생산 라인을 설계하는 것이다.

다만 루프에는 고유한 리스크가 있다. 실수도 자동화한다는 점이다. 그중에서도 현장에서 정말 무서운 것은 「에이전트가 테스트 코드를 조작하여 테스트를 통과시키는」 문제다. 루프 엔지니어링의 실무적인 핵심은 「올바르게 돌아가는 루프」가 아니라 「올바르게 멈추는 루프」의 설계에 있다.

왜 끊임없이 생겨나는가 —— 이러한 진화에는 명확한 법칙이 있다

새로운 규율이 탄생한다
↓
그것을 사용함으로써 「할 수 있는 일」이 늘어난다
...

이것은 AI 고유의 현상이 아니다. 소프트웨어 엔지니어링의 역사 전체가 이 패턴을 반복해 왔다.

• 구조화 프로그래밍 (Structured Programming) → 객체 지항 (Object-Oriented) → 디자인 패턴 (Design Pattern) → 마이크로서비스 (Microservices) → ……

각 규율은 이전의 규율을 부정하는 것이 아니라, 이전의 규율 위에 쌓여간다. 프롬프트 엔지니어링 (Prompt Engineering)이 없다면 컨텍스트 엔지니어링 (Context Engineering)은 성립할 수 없다. 하네스가 없다면 루프는 폭주한다.

엔지니어의 역할은 어떻게 변했는가

5가지 규율의 진화를 통해, 엔지니어의 업무는 단계적으로 변화해 왔다. 그리고 그 변화는 항상 「도구의 진화」와 세트로 이루어졌다.

시대	엔지니어가 하는 일	주요 도구·인프라
〜2022년	코드를 직접 작성함	에디터·GitHub
...

개념의 진화와 도구의 진화는 동전의 양면과 같다. 새로운 규율(Discipline)이 탄생했을 때, 그것을 구현하기 위한 도구도 동시에 정비되어 왔다. 역으로 말하면, 도구가 무엇을 전제로 설계되었는지를 보면 그 시대의 규율을 알 수 있다.

한마디로 말하자면, 엔지니어는 「코드를 쓰는 사람」에서 「코드가 생성되는 메커니즘을 설계하는 사람」으로 시프트(Shift)하고 있다.

단, Addy Osmani의 말을 잊어서는 안 된다.

"루프(Loop)를 만들어라. 단, 그저 버튼만 누르는 인간이 아니라, 엔지니어로 남겠다는 의지를 가지고 루프를 만들어라."

빠르게 움직이는 에이전트(Agent)를 설계하는 것보다, 무슨 일이 일어나고 있는지 이해하고 계속해서 컨트롤(Control)하는 것이 엔지니어의 본질적인 업무다. 그것은 규율이 무엇이든 변하지 않는다.

프로덕트 오너(PO)에게: 이 이야기가 의미하는 것

엔지니어링 이야기를 잠시 떠나, 프로덕트를 만드는 입장에서 바라보자.

5가지 규율의 진화가 보여주는 것은 「AI의 사용법」이 급격하게 변화하고 있다는 사실이다.

1년 전에 "AI를 사용하여 개발하고 있다"라고 말했던 팀이 지금도 같은 방법을 사용하고 있다면, 현재의 최전선에서 크게 뒤처져 있을 가능성이 있다.

PO로서 파악해 두어야 할 포인트는 세 가지다.

① 「AI를 사용하고 있다」는 더 이상 경쟁 우위가 아니다

AI를 사용하는 것 자체는 코모디티화(Commoditization)되고 있다. 어떤 규율로, 어떤 수준에서 사용하고 있는지가 차이를 만든다.

② 엔지니어에게 「AI로 무엇이든 할 수 있다」고 기대하는 것은 착각이다

각 규율에는 적절한 스코프(Scope)가 있다. 루프에 적합한 태스크(반복적·검증 가능·경계 명확)와 인간의 판단이 필요한 태스크가 있다. 이 구분을 이해한 PO와 엔지니어가 팀으로서 기능할 때 최대의 성과가 나온다.

③ 「에이전트가 내놓은 코드」의 품질 보증과 거버넌스(Governance)를 어떻게 설계할 것인가

이것이 2026년 현재, 엔터프라이즈(Enterprise) 환경에서 가장 긴급한 질문이다.

단순히 "테스트를 통과했는가"만으로는 부족하다. 조직으로서 물어야 할 질문은 다음과 같다.

감사 가능성 (Auditability) — "이 코드는 누가·언제·어떤 판단으로 생성했는가"를 추적할 수 있는가. 금융·의료·공공 계열 시스템에서는 규제 요건과 직결된다.

기존 시스템과의 통합 테스트 — 레거시(Legacy)한 기간계나 복잡한 백엔드(Backend)와의 결합 부분을 에이전트가 생성한 코드가 올바르게 다루고 있는지에 대한 검증은 단체 테스트(Unit Test)만으로는 담보할 수 없다.

거버넌스의 소재 — 에이전트가 생성한 코드에서 결함이 발생했을 때, 책임은 어디에 있는가. 엔지니어 개인인가, 팀인가, 프로세스인가. 이를 모호하게 둔 채 본운영을 하면 인시던트(Incident) 발생 시 조직이 기능 부전에 빠진다.

루프가 빠르게 돌아갈수록, 이러한 거버넌스 설계의 지연이 리스크로서 현재화되는 속도도 빨라진다. 기술적인 규율 이야기는 사실 그대로 프로덕트·조직의 리스크 관리 이야기이기도 하다.

시리즈 읽는 법

이 서두의 기사로 전체상을 파악했다면, 관심 있는 규율의 상세 기사로 넘어가길 바란다.

각 기사는 독립적으로 읽을 수 있지만, 순서대로 읽으면 각 규율이 "왜 필요했는가"라는 문맥과 함께 이해할 수 있다.

【이 기사】 전체상을 파악하기 (PO도 읽어보길 권장)
↓
제1회: Prompt Engineering
...

요약: 규율은 쌓여가고, 엔지니어의 본질은 변하지 않는다

5가지 규율은 각각 독립된 버즈워드(Buzzword)가 아니다. 이전 규율의 한계가 드러났을 때 다음 규율이 태어났다는 연속적인 진화의 지도다.

그리고 이 지도 전체를 관통하는 하나의 사상이 있다.

"실수를 하는 존재(인간이든 AI든)를 환경과 메커니즘으로 제어한다"

테스트 자동화도 CI/CD도 IaC도, 이 사상의 인간 대상 구현이다. 프롬프트(Prompt)·컨텍스트(Context)·하네스(Harness)·루프(Loop)는 이 사상의 AI 대상 구현이다.

새로운 규율이 나왔을 때 "또 버즈워드인가"라고 느껴진다면, 이렇게 다시 질문해 보길 바란다.

"이 규율은 이전 규율의 어떤 한계를 뛰어넘으려 하는가?"

그 질문에 대한 답이 보일 때, 버즈워드는 지도가 된다.

시리즈 목록

[본 기사]【제0회】 왜 「○○ 엔지니어링」은 계속해서 생겨나는가 (공개 예정)

• 제1회: Prompt Engineering (프롬프트 엔지니어링)
• 제2회: Context Engineering (컨텍스트 엔지니어링)
• 제3회: Agentic Engineering (에이전틱 엔지니어링)
• 제4회: Harness Engineering (하네스 엔지니어링)
• 제5회: Loop Engineering (루프 엔지니어링)

Discussion