한때는 프롬프트 엔지니어링이면 다 되었습니다. 그러다 컨텍스트 엔지니어링이란 단어가 AI 엔지니어링 쪽에서 유행어로 알려진 때가 2025년 6월입니다. 그다음 유행인 하네스 엔지니어링은 2025년 11월에서 2026년 2월 사이, 다시 루프가 나온 게 2026년 6월입니다. 프롬프트에서 시작해 1년 사이 유행이 세 번이나 바뀐 겁니다. 너무 피곤하더라고요.

이렇게 유행이 빠르게 바뀌다 보니 따라가는 게 버겁습니다. 게다가 정의조차 아직 명확하지 않아서 누구는 이렇다, 누구는 저렇다, 하는 말이 조금씩 다 다릅니다. 그래서 직접 정리해봤습니다. 적당히 느낌으로만 알던 네 단어를 한번 제대로 정리하고, 정말 다 알고 따라가야 하는지까지 확인해봤습니다.

네 가지 AI 엔지니어링 트렌드

우선 각 엔지니어링의 뜻을 알아야 이걸 다 알고 따라가야 할지 말지도 판단할 수 있을 것 같습니다. 그래서 사전처럼 단어 뜻을 정리했습니다. 어떤 문제를 푸는지, 무엇을 하는지, 이해를 돕는 예시 순으로 찾았습니다.

1. 프롬프트 엔지니어링

모델이 아직 못 하는 일을 사람의 입력, 즉 '프롬프트'로 메우는 기법이자 그러한 방식을 연구하는 영역입니다. 'AI한테 말 잘 거는 법'으로 알려졌지만 실제 범위는 더 넓습니다.

푸는 문제:초기 모델의 약점인 지시를 잘 안 따르고, 추론이 약하고, 한 번에 보는 글이 짧고, 같은 질문에도 답이 들쭉날쭉한 것을 보완합니다.
하는 일: 약점을 프롬프트로 해소합니다. 예시를 몇 개 보여주거나(few-shot), 사고의 단계를 밟게 하거나(CoT), '차근차근 생각하자'라는 명령을 추가하거나(Zero-shot CoT), 생각과 행동을 번갈아 시킵니다(ReAct).
예시: 'Let's think step by step' 한 문장만 붙여도 한 수학 추론 벤치마크(MultiArith)에서 정답률이 17.7%에서 78.7%로 올랐습니다. 간단한 명령 구조만으로 매우 큰 성과를 얻을 수 있었죠.

요즘 프롬프트 엔지니어링이 끝났다는 말이 많았는데요. 사실 절반만 맞다고 봅니다. 여전히 프롬프트를 잘 입력하는 일은 중요합니다. 다만, 요즘 나오는 추론 모델이 스스로 단계를 밟아 나가며 사고를 한다거나, 알아서 그 구조를 설계할 수 있게 되었을 뿐이죠. 그래서 나머지 기법은 다음에 볼 컨텍스트 엔지니어링으로 옮겨갔습니다. 즉, 폐기된 게 아니라 이동한 것입니다.

2. 컨텍스트 엔지니어링

모델이 추론할 때마다 보는 '맥락' 전체를 관리하는 일입니다. 프롬프트가 입력할 문장을 다듬는 일이라면, 이쪽은 시스템 프롬프트·툴 설명·메모리·검색 자료·대화 기록을 한데 놓고 다룹니다.

푸는 문제: 컨텍스트 윈도우는 한정된 예산입니다. 꽤 커졌다지만 많이 채운다고 좋은 게 아니라, 오히려 성능이 떨어지기도 하거든요. 이렇게 입력이 길어질수록 정확도가 흐려지는 현상에는 context rot(컨텍스트 부패)이라는 이름까지 붙었습니다.
하는 일: 꼭 필요한 맥락만 효율적으로 받아가도록, 필요한 신호만 추리고(큐레이션), 길어지면 요약해 다시 시작하고(컴팩션), 필요할 때 그때그때 불러오고(적시 검색), 일을 나눠 맡기기도 합니다(서브에이전트).
예시: Claude Code의 CLAUDE.md 예시를 보면 컨텍스트 엔지니어링을 어떻게 수행하는지 확인할 수 있습니다. CLAUDE.md는 200줄 미만으로 짧게 쓰도록 권장하는데(길면 컨텍스트를 더 차지하고 지시 준수도가 떨어집니다), /compact 명령으로는 길어진 대화를 요약해 컨텍스트를 비우기도 합니다.

사실상 RAG(검색 증강 생성)처럼 크게 유행한 단어도 이 영역의 일부로 볼 수 있습니다. 모델이 알아야 하는 항목을 설계하는 일에 관한 용어로 잘 자리 잡았습니다.

3. 하네스 엔지니어링

한마디로 '모델에 고삐를 채우는 일(harness=말에 채우는 마구)'이라고 할 수 있습니다. 에이전트를 둘러싼 코드·설정·실행 로직 전체 영역을 다룹니다.

푸는 문제: 모델 혼자서는 긴 작업을 끝까지 못 이어갑니다. 프런티어 모델도 마찬가지라, 모델을 둘러싼 구조가 결과를 좌우합니다.
하는 일: 툴, 검증 루프, 샌드박스, 메모리, 컨텍스트 관리를 짜 맞춰 모델이 일할 환경을 짜줍니다.
예시: 작게는 마크다운 파일 (미첼 하시모토(Mitchell Hashimoto)가 자기 프로젝트 Ghostty에 둔 AGENTS.md), 크게는 모델을 그대로 두고 구조만 손봐 벤치마크 순위를 30위에서 5위로 끌어올린 실험(LangChain Terminal Bench)까지, 폭이 아주 넓습니다.

다만 다루는 범위가 넓은 만큼 정의도 다양합니다. 에이전트에게 규모가 크거나 오래 걸리는 작업을 시킬 발판으로 보는 쪽, 가드레일을 설계해 실수를 막는 일로 보는 쪽, 말 그대로 '모델 빼고 다'로 보는 쪽 등이 섞여 있어서, 말할 때 어느 쪽인지 밝혀야 혼란이 덜할 겁니다.

4. 루프 엔지니어링

프롬프트를 던지는 사람을, 아예 프롬프트를 던지는 시스템으로 대체하는 일입니다. 한 번 시키고 끝이 아니라, 목표만 정해두면 알아서 반복하게 만듭니다.

푸는 문제: 어떻게든 결국은 사람이 매번 붙어 프롬프트를 넣어야 하는 일을 병목으로 봅니다. 작업 단위를 통째로 위임하려는 시도입니다.
하는 일: 자동 재실행(Automations), 작업 충돌을 막는 워크트리(Worktrees), 설명을 반복하는 걸 막는 스킬(Skills), 외부 도구에 잇는 플러그인(Plugins), 작성자와 검증자를 나누는 서브에이전트(Sub-agents) 등으로 짭니다. 정해진 시간에 똑같이 실행되는 cron과 달리, 루프 안에서는 모델이 매번 다음 행동을 직접 고릅니다.
예시: 630줄짜리 스크립트가 밤새 50개 실험을 스스로 돌린 카파시(Karpathy)의 AutoResearch 정도가 있습니다. 카파시 스스로도 자기 코딩의 80%를 에이전트에 넘겼다고 합니다.

구글 크롬 엔지니어링 리드 애디 오스마니(Addy Osmani)가 쓴 글이나 오픈클로(OpenClaw)의 창시자인 피터 슈타인베르거(Peter Steinberger)의 트윗으로 유명해졌습니다. 이제 갓 나온 말이라 정의가 조금 달라질 가능성도 있습니다. 게다가 '루프'라는 표현 자체는 클로드 코드의 창시자 보리스 체르니(Boris Cherny)가 꾸준히 써왔기에, 어떤 작업 방식에 이름을 새로 붙인 쪽에 가깝습니다.

엔지니어링 트렌드는 왜 이렇게 빨리 바뀌었을까?

프롬프트 엔지니어링에서 하네스 엔지니어링, 그리고 루프 엔지니어링으로. 1년 사이 엔지니어링 트렌드는 왜 이렇게 빨리 바뀌었을까요? ‘왜’를 묻기 전에 우선 ‘어떻게’ 이렇게 빨라졌는지 먼저 이야기해보겠습니다.

첫째, 모델이 빨리 좋아졌습니다. 추론 모델이 단계 밟기를 안에서 처리하면서, 프롬프트로 메우던 일 일부가 사라졌습니다. 모델이 좋아질수록 사람이 메우던 자리가 한 칸씩 위로 옮겨갑니다.

둘째, 코딩 에이전트 도구가 그 환경을 마련했습니다. Claude Code, Codex, Cursor 같은 제품이 크게 성장했고, 아예 이러한 엔지니어링 요소를 누구나 적용할 공간이 됐습니다. 그래서 요즘 등장하는 트렌드는 사실상 전에 없던 것을 발명한 게 아니라, 이미 사람들이 이 도구를 쓰는 방식에 이름을 붙여 알아보게 만든 것에 가깝습니다.

셋째, 모델을 다루는 노하우가 쌓였습니다. 토큰을 어떻게 쓰고 아끼고 나눌지 사람들이 함께 익혔습니다. 컨텍스트 윈도우를 예산으로 보는 시각이 퍼졌고, 컴팩션이나 적절한 검색 같은 절약 패턴이 표준이 됐습니다. 요즘은 루프를 돌릴 토큰이 있느냐가 새 제약으로 떠오르기도 했습니다. 모델과 도구가 좋아진 만큼, 같은 토큰으로 더 많은 일을 시키는 요령도 늘었습니다.

정리하자면, 이제 누구나 정말 좋은 모델을 자기 엔지니어링 업무에 쓴다는 겁니다. 그래서 더 좋은 방식, 더 나은 환경을 위한 요구와 이를 위한 실험의 속도가 급격히 치솟았죠.

트렌드 교체의 본질

그러니 이러한 트렌드는 세대교체가 아닙니다. 문제가 바뀐 게 아니라, 같은 문제를 점점 큰 단위에서 풀어나갔을 뿐이죠.

사람이 처리하는 단위가 프롬프트 한 줄에서 전체 맥락으로, 다시 맥락에서 모델을 둘러싼 구조로, 이 구조에서 도는 루프로 한 칸씩 올라갔을 뿐입니다. 사라진 것은 없고, ‘줌아웃’됐을 뿐입니다.

그래서 이 변화를 깔끔하게 계단식으로 정리하면 안 됩니다. 이 세 가지 엔지니어링은 폭도 성격도 제각각이라, 같은 높이로 한 칸씩 높아진 계단이 아니기 때문입니다.

결국 남는 건 ‘AI에게 일을 더 잘 시키는 법’

엔지니어링의 발전 방향을 하나로 모으면, 모두 '모델이 어디서 부족한가'에서 출발합니다. 컨텍스트 엔지니어링은 윈도우를 많이 채우면 성능이 떨어진다는 약점을, 하네스는 아무리 뛰어난 모델조차 단독 루프로는 부족하다는 한계에서 시작했습니다. 지금의 루프 엔지니어링은 '검증이 가장 큰 난제'라는 약점을 품고 있고요.

'모델 빼고 다'가 점점 중요해진다는 건, 모델이 좋아질수록 사람이 해야 하는 일이 더 높은 단위로 올라간다는 뜻입니다. 풀어야 할 문제니까 사람들이 관심을 가지는 거죠. 프롬프트가, 컨텍스트가, 하네스가, 루프가 나를 괴롭히니까 그 말에 관심을 기울인 것입니다. 이 괴로움을 걷어내면, 이것만 남습니다. ‘AI에게 일을 더 잘 시키는 법.’

앞서 깔끔한 계단이 아니라고 했는데, 카파시도 비슷한 말을 한 적이 있습니다. 발전은 계단처럼 한 칸씩 올라서는 게 아니라, 슬라이더를 왼쪽에서 오른쪽으로 천천히 미는 식으로 일어난다는 거죠. 단계를 탁탁 치고 올라온 게 아니라, 슬금슬금 '일을 AI에게 온전히 잘 맡기는 식'으로 진화해 왔다는 뜻입니다.

그럼, 제가 루프 엔지니어링까지 알아야 할까요?

트렌드는 어디까지 따라가야 할까

이제 이 글의 처음에서 던진 질문에 답해보겠습니다. 우리가 지금 루프 엔지니어링까지 알아야 하는 걸까요?

이 새로운 단어는 지금 사람들이 어려워하는 일을 가리킵니다. 그렇기 때문에 왜 이런 단어가 나왔는지는 알아두는 편이 좋다고 생각합니다. 용어를 모르면 대화나 도구 선택, 심지어 채용에서 밀리기 쉽습니다. 다만, 정의를 외우라는 말은 아닙니다. 왜 나왔는가, 즉 어떤 한계를 가리키려는 단어인지만 알아두면 됩니다.

그러려면 일단 써보는 것을 권합니다. 대부분 이러한 엔지니어링의 요소는 Claude Code와 Codex 안에 이미 다 있습니다. 자동 재실행은 hooks, 워크트리는 git worktree, 스킬은 SKILL.md, 플러그인(외부 도구 연결)은 MCP, 서브에이전트는 분리 호출 같은 걸로 들어가 있습니다.

실제로 굉장히 부정적인 사람들도 많습니다. 그런 회의론도 들어둘 만합니다. '몇 년 전부터 하던 일'이라는 개발자도 있고, 누군가는 '코딩 에이전트는 과대망상에 빠진 while 반복문일 뿐'이라고 합니다. 결국, 트렌드로 접할 게 아니라 직접 만져본 경험을 기준으로 삼는 편이 낫습니다.

어떤 능력을 길러야 할까: taste

이런 흐름속에서 요즘 사람들이 해야 할 ‘진짜 일’은 AI가 하지 못하는 나머지 일, 즉 검증하고 비용을 따지고 본질을 이해하는 쪽에 있습니다. 이걸 가리키는 유행어가 또 있습니다. (이제 그만!) taste입니다.

taste, 말 그대로 취향입니다. 안목, 판단력 같은 말로 번역해도 좋다고 생각합니다. 조금 두루뭉술한 단어지만, 결국 무엇이 더 좋은지 아는 능력이라고 볼 수 있습니다. 무엇이 좋은 코드인지, 무엇이 좋은 제품인지, 어떤 기능을 빼야 하는지, 어떤 결과물을 남겨야 하는지를 결정하는 능력이죠.

이런 유행에 휩쓸리지 않는 카파시도, 에이전트는 인턴 같은 존재이고 미감과 판단, taste, 감독은 사람 몫이라고 말했습니다. taste는 채점할 수 없으니 모델이 못 배우고, 그래서 사람이 하는 거죠.

결국 taste란 사람이 끝까지 넘기지 않는 '판단'의 역할을 대변하는 말입니다.

마치며

전환기에는 늘 어려운 단어로 흐름을 주도하려는 시도가 따라옵니다. 이름이 붙으면 시장이 정렬되고, 거기서 유행과 일자리가 생기니 놓칠 수 없죠.

부정적으로 볼 것만은 아니라고 생각합니다. 언어는 늘 현상을 정의하고, 그렇기에 빠르게 변하는 현실을 단어가 따라잡기 마련입니다.

그럴 때일수록 중심을 잡아야 합니다. 트렌드에 휩쓸리면 남는 게 없고, 반대로 눈을 돌려버리는 것도 답은 아닙니다. 그러니 결국 저는 스스로 필요한 것을 좇아야 하지 않을까 생각합니다. 외면하지 않고, 휘둘리지도 않고, 직접 써보며 나만의 'AI와 함께 더 나은 결과를 만드는 일'에 최선을 다하는 겁니다.