AI 용어는 왜 자꾸 바뀔까요 — 프롬프트에서 루프까지, 따라갈 것과 흘려보낼 것

또 새 단어가 나왔습니다 — ‘루프 엔지니어링’이 막 태어나는 현장

어느 평범한 아침, 업계 소식을 훑다가 처음 보는 말과 마주쳤다고 해 볼게요. ‘루프 엔지니어링(loop engineering)’. 한동안은 ‘프롬프트 엔지니어링’이 화제였고, 작년엔 ‘컨텍스트 엔지니어링’이 새로 떴는데, 어느새 또 다른 이름이 올라와 있는 거지요. 마음 한구석이 살짝 무거워져요. “이걸 또 따라가야 하나. 안 따라가면 뒤처지는 건가.” 혹시 지금 그런 기분이셨다면, 정확히 그 마음을 덜어 드리려고 이 글을 준비했답니다.

먼저 솔직하게 말씀드릴게요. ‘루프 엔지니어링’이라는 말은 이 글을 쓰는 2026년 6월 현재, 세상에 나온 지 겨우 몇 주밖에 안 된 갓난 단어예요. 한 개발자가 올린 짧은 글이 크게 퍼지고, 그걸 다른 개발자가 ‘루프 엔지니어링’이라 이름 붙여 정리하면서 며칠 만에 번진 말이거든요. 아직 정해진 뜻도, 자격증도, 직함도 없어요. 말 그대로 단어가 태어나는 중이지요.

바로 그래서 이 단어가 좋은 출발점이에요. 우리는 지금 ‘AI를 잘 쓰는 법’에 새 이름이 붙는 순간을 실시간으로 들여다볼 수 있거든요. 이 장면을 같이 천천히 보고 나면, 왜 이런 단어가 자꾸 바뀌는지, 그리고 그중 무엇이 진짜 내 일과 상관있는지 자연스럽게 눈에 들어오실 거예요. 그럼 단어들이 걸어온 길부터 짧게 짚어 볼게요.

짧은 족보 — 프롬프트에서 루프까지, 한눈에

지난 3년 남짓 ‘AI에게 일을 시키는 법’에 붙은 이름들을 시간 순서로 늘어놓으면 이렇게 돼요. 깊은 기술 설명은 잠시 접어 두고, 큰 줄기만 선명하게 보겠습니다.

• 프롬프트 엔지니어링 (prompt engineering) — AI에게 줄 말(프롬프트 — AI에게 건네는 질문이나 지시문이에요)을 잘 다듬어 원하는 답을 끌어내는 기술이에요. 2022년 말 챗GPT가 나오면서 폭발적으로 퍼졌지요. 재미있는 건, 이 말을 누가 처음 만들었는지가 분명하지 않다는 점이에요. 어느 한 사람의 발명이 아니라, AI를 만지던 사람들 사이에서 자연스럽게 생긴 말이거든요.
• (중간 단계) RAG·파인튜닝·평가(evals) — “AI가 내 자료를 보고 답하게 만들고(RAG·파인튜닝), 그 답이 맞는지 측정하자(평가)”는 흐름이에요. 2020년부터 2024년 사이 논문으로 차곡차곡 쌓인, 가장 단단한 학술적 토대랍니다.
• 컨텍스트 엔지니어링 (context engineering) — 말 한 줄이 아니라 AI가 보는 맥락 전체(지시·참고자료·이전 대화·도구)를 잘 차려 주는 일이에요. 2025년 여름 무렵 여러 사람이 잇따라 같은 말을 띄우면서 퍼졌지요.
• 하네스 엔지니어링 (harness engineering) — AI 모델을 둘러싼 나머지 장치 전부(도구·기억·점검 절차)를 설계하는 일이에요. 2026년 2월 무렵 이름이 붙기 시작했답니다.
• 루프 엔지니어링 (loop engineering) — 사람이 매번 말을 거는 대신, AI가 스스로 돌아가는 흐름(루프)을 짜 두는 일이에요. 방금 본 것처럼, 2026년 6월 막 등장한 가장 새 이름이지요.

여기서 한 가지만 기억해 두세요. 뒤로 갈수록 사람이 하는 일이 한 칸씩 위로 올라간다는 점이에요. 처음엔 ‘말을 잘 거는 일’이었다가, ‘참고자료를 잘 챙겨 주는 일’이 됐다가, 이제는 ‘AI가 알아서 돌게 판을 짜 주는 일’로요. 이름이 바뀐 게 아니라, 맡기는 단위가 점점 커진 셈이랍니다. 이 흐름을 머리 한쪽에 두고, 가장 친숙한 단어 하나를 자세히 들여다볼게요.

바이브 코딩 — 당신이 이미 들어본 그 단어

위 단어들이 좀 낯설었다면, 이건 아마 한 번쯤 들어 보셨을 거예요. 바이브 코딩(vibe coding). 비개발자도 말로만 앱을 만든다는 그 이야기의 주인공이지요. 이 한 단어를 자세히 보면, 사실 AI 용어가 어떻게 태어나고 퍼지고 변하는지가 통째로 보인답니다.

이 말은 비교적 출처가 또렷해요. 2025년 2월 초, AI 분야의 유명한 연구자 안드레이 카파시(Andrej Karpathy)가 가볍게 올린 글에서 시작됐거든요. 그가 말한 원래 뜻은 생각보다 좁아요. “코드를 한 줄도 들여다보지 않고, 그냥 원하는 느낌(vibe)을 말로 설명해 AI에게 통째로 맡기는 것” — 본인 표현으로는 “코드가 존재한다는 사실조차 잊는” 방식이에요. 즉 결과물을 꼼꼼히 검토하지 않고 흐름에 몸을 맡기는, 가벼운 실험에 가까운 모드였지요.

그런데 재미있는 일이 벌어졌어요. 말이 퍼지면서 뜻이 슬그머니 넓어진 거예요. 지금 한국에서도, 또 전 세계에서도 많은 분이 ‘AI로 코딩하는 모든 것’을 뭉뚱그려 바이브 코딩이라 부르거든요. 원래는 ‘코드를 안 본다’는 좁은 뜻이었는데 말이지요. 이런 걸 ‘의미가 번진다(semantic drift)’고 해요. 이 대목에서 개발자 사이먼 윌리슨(Simon Willison) 씨가 정리한 기준이 도움이 된답니다. “결과물을 검토하고, 시험해 보고, 이해하면서 쓴다면 그건 그냥 평범한 AI 보조 개발이지 바이브 코딩이 아니다”라는 거예요. 바이브 코딩은 어디까지나 ‘안 보고 맡기는’ 좁은 모드라는 거지요.

한국에서 이 단어가 얼마나 친숙해졌는지는 어렵지 않게 확인돼요. 삼성SDS는 기업용 인사이트 글에서 바이브 코딩을 정식으로 다뤘고, 카카오의 기술 블로그에도 관련 글이 올라와 있어요. 강의·커뮤니티까지 생겼을 만큼, AI 용어 중에서는 가장 대중적으로 퍼진 외래어 축에 든답니다. (회사들이 실제 업무에 어떻게 적용했는지는 뒤에서 따로 짚을게요.)

정리하면, 바이브 코딩은 탄생 → 빠른 확산 → 의미 번짐까지 한 단어 안에서 다 보여 주는 좋은 표본이에요. 그리고 이 이야기에는 마지막 장면이 하나 더 남아 있답니다 — ‘시대가 끝났다’는 역풍이지요. 그 대목은 잠시 뒤, 단어들이 왜 이렇게 빨리 도는지 이야기할 때 함께 보겠습니다. 그 전에, 이름값을 빼고 보면 무엇이 진짜 달라졌는지부터 짚어 볼게요.

그래서 뭐가 진짜 바뀌었나 — ‘한 줄’에서 ‘판 짜기’로

이름이 자꾸 바뀐다고 해서 안에 든 게 다 똑같은 건 아니에요. 분명히 진짜 달라진 한 가지가 있는데, 그건 ‘일의 무게중심이 옮겨 간 것’이에요.

처음 챗GPT가 나왔을 땐, 잘 쓰는 사람과 못 쓰는 사람의 차이가 주로 ‘질문 한 줄을 얼마나 잘 짜느냐’에 있었어요. 같은 일을 시켜도 말을 어떻게 거느냐에 따라 결과가 크게 갈렸거든요. 그래서 “이렇게 물어보세요” 식의 프롬프트 요령이 한창 인기였지요.

그런데 AI가 똑똑해지면서, 질문 한 줄을 다듬어서 얻는 이득은 점점 줄었어요. 대신 ‘AI 앞에 무엇을 차려 주느냐’가 훨씬 중요해졌지요. 회사 규정 문서를 같이 넣어 줬는지, 지난 대화 내용을 기억하게 했는지, 필요한 도구(검색·계산·파일 열기)를 손에 쥐여 줬는지요. 비유하자면 이래요. 예전엔 시험 문제를 잘 내는 일이었다면, 지금은 책상 위에 참고서·계산기·검증 도구를 알맞게 배치해 주는 일로 무게가 옮겨 간 거예요. 컨텍스트·하네스·루프 같은 새 이름들은, 결국 이 ‘판 짜기’의 범위가 점점 넓어지는 걸 가리키는 말이랍니다.

그러니 “전부 이름만 바꾼 마케팅 아니냐”고만 보기엔 아까운 변화도 분명히 있어요. 실제로 같은 AI 모델이라도 둘레를 어떻게 설계해 주느냐에 따라 성적이 크게 달라진다는 사실이 여러 실험에서 확인되고 있거든요. 똑똑한 모델을 쓰고도 판을 엉성하게 깔면 결과가 시원찮고, 평범한 모델이라도 판을 잘 깔아 주면 훨씬 나은 답을 낸다는 거네요. 그러니 우리가 가릴 건 ‘이름이 진짜냐 가짜냐’가 아니라, 그 이름이 가리키는 일 중에 내가 챙길 알맹이가 무엇이냐예요. 그 가림질을 위해, 이제 솔직한 회의(懷疑) 한 장을 펴 볼게요.

솔직한 회의 — ‘그냥 이름만 바꾼 거 아닌가요?’

여기까지 읽고 “그래도 좀 수상한데” 싶으셨다면, 그 직감은 절반쯤 맞아요. 이 단어들 상당수가 같은 일에 새 간판을 다는 쪽에 가깝거든요. 업계에선 이걸 두고 ‘용어 트레드밀(쳇바퀴)’이라고 꼬집기도 한답니다. 근거가 약하지 않네요.

• 컨텍스트 엔지니어링은 논문이나 표준이 먼저 나온 게 아니라, 유명 인사들의 짧은 글에서 퍼졌어요. 한 회사 대표가 “프롬프트 엔지니어링보다 이 말이 더 낫다”고 띄우자, 카파시가 “내가 만든 말은 아니지만 동의한다(+1)”며 거든 식이지요. 게다가 이 말을 옹호하는 쪽에서도, 사실은 이미 하던 일에 이름만 새로 붙인 것이라고 인정하는 분위기예요. 원조 RAG 논문을 함께 쓴 연구자 중 한 분도 “RAG를 다시 포장한 셈”이라는 취지로 말한 것으로 전해졌을 정도고요.
• 하네스·루프 엔지니어링도 마찬가지예요. ‘AI가 행동하고 → 결과를 점검하고 → 다시 시도하는’ 흐름은 사실 수년 전부터 있던 개념이거든요. 한 회사는 이미 2024년 말에 이 ‘점검-재시도’ 흐름을 문서로 정리해 뒀고, 더 거슬러 올라가면 제어 이론이나 군사 분야의 의사결정 모델(OODA 루프)까지 닿아요. 한 비판자는 “마법을 파는 게 엔지니어링을 파는 것보다 늘 쉽다”고 따끔하게 적기도 했지요.
• “X는 죽었다, 이제 Y다” 형식의 기사들도 6~12개월마다 도는 패턴이에요. 앞서 미뤄 둔 바이브 코딩의 마지막 장면이 딱 그래요. 이 말을 처음 띄운 카파시조차 2026년 들어선 ‘agentic engineering(에이전틱 엔지니어링)’이라는 더 엄밀한 표현을 앞세웠고, 여러 매체는 이를 ‘바이브 코딩 시대 이후’로 풀이했어요. 한 단어가 1년여 만에 이렇게 다음 이름에 자리를 내준다는 건, 그만큼 이름이 빨리 도는 동네라는 뜻이네요.

그렇다고 “다 거품이니 무시하라”는 이야기는 아니에요. 앞 장에서 봤듯 진짜 변화도 분명히 있으니까요. 일의 무게중심이 ‘한 줄’에서 ‘판 짜기’로 옮겨 간 것, 그리고 판을 어떻게 까느냐에 따라 결과가 크게 갈린다는 것 — 이 둘은 간판 갈이로 설명되지 않는 실체랍니다. 그러니 가장 정직한 결론은 이거예요. 간판(이름)은 빠르게 바뀌지만, 그 간판들이 가리키는 작은 핵심 묶음은 아주 천천히만 변한다. 우리가 챙겨야 할 건 늘 후자지요. 그런데 여기서 비개발 직장인이라면 한 가지 의문이 들 거예요. “이거… 결국 개발자들 얘기 아닌가요?”

이 용어들, 개발자만의 얘기일까요?

좋은 질문이에요. 그리고 정직하게 답하면 — 절반만 맞아요.

먼저 맞는 절반부터요. 뒤쪽 단어들, 그러니까 하네스 엔지니어링이나 루프 엔지니어링은 지금으로선 주로 개발자(코딩 도구를 다루는 사람들) 동네의 이야기예요. ‘AI에게 코드를 맡기고 자동으로 돌린다’는 맥락에서 나온 말들이라, 코딩을 직접 하지 않는 분이 이 단어들을 외울 필요는 사실 거의 없답니다.

그런데 틀린 절반이 더 중요해요. 그 단어들 밑에 깔린 ‘사고법’은 모든 직장인의 일에 그대로 적용되거든요. 이름만 개발자 옷을 입었을 뿐, 알맹이는 우리 업무 그대로예요. 예를 들어 볼게요.

• 컨텍스트(맥락)를 챙겨 주는 일 — 개발자가 AI에게 회사 코드를 읽혀 주듯, 기획자는 AI에게 지난 분기 보고서와 회의록을 같이 넣어 줘야 쓸 만한 초안이 나와요. 빈손으로 “기획안 써 줘” 하면 뻔한 답만 돌아오지요.
• 결과를 점검하는 루프 — 개발자가 AI가 짠 코드를 테스트로 거르듯, 마케터는 AI가 뽑은 카피를 “우리 브랜드 톤에 맞나, 사실관계는 맞나” 기준으로 거르고 다시 시켜요. CS(고객 응대) 담당자라면 AI 답변 초안을 회사 정책에 어긋나지 않는지 확인한 뒤 내보내고요.
• 무엇을 맡기고 무엇은 안 맡길지 가리는 판단 — 인사(HR) 담당자가 채용 평가 같은 민감한 일에는 AI를 신중히 쓰듯, 어디에 기대고 어디선 손을 뗄지 정하는 분별이지요.

보세요. 보고서, 기획, 마케팅, 고객 응대, 인사 — 어느 일에서든 ‘맥락을 잘 주고, 결과를 점검하고, 어디 쓸지 가린다’는 골격은 똑같아요. 개발자들이 그걸 ‘컨텍스트 엔지니어링’이니 ‘루프’니 하는 이름으로 부를 뿐이네요. 그러니 “개발자만의 얘기처럼 들렸다면 절반만 맞다”는 거예요. 그리고 이 점을, 한국 회사들이 이미 행동으로 보여 주고 있답니다.

한국 현장 — 회사들이 실제로 한 건 ‘신조어’가 아니었어요

우리 월요AI가 늘 주목하는 대목이에요. 화제의 단어를 좇기보다, 한국 회사들이 실제로 무엇을 했는지를 보면 배울 게 훨씬 많거든요. 흥미롭게도, 앞서 가려낸 ‘알맹이’가 한국 현장에 그대로 나타나요.

배달의민족(우아한형제들)은 사내 행사에서 개발 과정에 AI를 적극 들인 사례를 공유했어요. 배포한 뒤 생기는 오류·기록을 AI로 분석하고, 동료가 올린 코드 변경을 요약하는 식으로요. 회사는 이를 ‘AI를 일상적으로 쓰는 조직’으로 가려는 흐름으로 설명했답니다. 화려한 새 이름이 아니라 ‘반복되는 점검 작업을 AI에게 맡기는 습관’이 핵심이었네요. 복잡한 자동화부터 시작하지 않고 매번 되풀이되는 점검 일부터 AI에게 넘긴 셈이라, 우리도 따라 하기 좋은 출발점이고요.

토스(비바리퍼블리카)는 기술 블로그에 ‘소프트웨어 3.0 시대를 맞이하며’라는 글을 올려, AI 도구를 어떻게 짜 맞춰 쓸지를 정리했어요. 이 글에서 토스는 AI 모델을 둘러싼 장치들을 ‘하네스(마구·말에 씌우는 장비)’에 빗대 설명했는데, 바로 우리가 앞에서 본 ‘판 짜기’를 한국 회사가 자기 말로 풀어낸 장면이랍니다. 거창한 새 도구를 들이기 전에 ‘있는 AI를 어떻게 엮어 쓰느냐’가 먼저라는 걸 보여 주는 셈이네요.

카카오뱅크는 한발 더 흥미로워요. 코드 점검을 돕는 사내 시스템을 만들면서, 맥락을 잘 넣어 주는 일(컨텍스트 엔지니어링)과 질문을 잘 다듬는 일(프롬프트 엔지니어링)을 실제로 적용했다고 기술 행사에서 공유했거든요. 은행은 규제가 엄격한 곳이라, 고객 정보나 민감한 자료를 함부로 넣지 않도록 울타리(가드레일 — AI가 넘지 말아야 할 선을 미리 정해 두는 안전장치예요)를 함께 두는 게 특히 중요했지요. 민감한 정보를 다루는 일일수록, 똑똑한 답을 먼저 좇기보다 ‘울타리부터 친다’가 앞선다는 걸 보여 주네요.

이 밖에도 여러 한국 회사가 회사 전반의 AI 전환을 내걸고 있어요. LG는 자체 AI를 업무에 붙이는 시도를 공개했고요. (회사들이 밝힌 생산성 수치 같은 건 대개 자체 발표 기준이라, 숫자 그대로보다는 ‘이런 방향으로 움직이고 있구나’ 정도로 읽으시는 게 안전해요.)

여기서 우리가 가져갈 결론은 분명해요. 이 회사들이 실제로 한 건 ‘최신 신조어를 외운 것’이 아니라, ‘맥락을 잘 챙기고, 결과를 점검하고, 위험한 데는 울타리를 친 것’이었어요. 다시 말해, 이름이 아니라 알맹이를 챙긴 거네요. 그렇다면 그 알맹이가 정확히 무엇인지, 한 번 더 또렷이 정리해 둘게요.

변하지 않는 것 — 간판 말고, 알맹이

이름이 프롬프트에서 컨텍스트로, 다시 하네스·루프로 바뀌는 동안에도 거의 변하지 않은 핵심 묶음이 있어요. 이 네 가지만 몸에 익혀 두시면, 다음에 또 새 단어가 떠도 당황하지 않으실 거예요.

• ① 의도를 또렷이 적기 — 무엇을 원하는지, 무엇이 ‘잘된 결과’인지를 분명한 말로 적는 능력이에요. 옛 ‘프롬프트 엔지니어링’의 알맹이가 바로 이거지요. 이름이 뭘로 바뀌든 이 기본기는 안 변해요.
• ② 필요한 맥락을 골라 주기 — 회사 문서, 지난 대화, 지켜야 할 규칙을 AI 앞에 알맞게 차려 주는 감각이에요. ‘컨텍스트 엔지니어링’의 알맹이고요.
• ③ 결과를 검증하기 — AI가 내놓은 답을 곧이곧대로 믿지 말고, 사실·수치를 직접 확인하는 습관이에요. 비개발 직장인에게 가장 실용적인 한 가지지요.
• ④ 어디에 쓸지 가리기 — AI가 어울리는 일과 안 어울리는 일을 구분하는 분별이에요. 민감한 판단·책임이 걸린 일은 사람이 쥐고 있어야 하니까요.

예전에 손글씨를 잘 쓰는 일이 중요했지만, 키보드가 들어온 뒤엔 그 기술이 사라진 게 아니라 ‘생각을 글로 또렷이 옮기는 능력’ 안으로 흡수됐잖아요. 프롬프트 엔지니어링도 비슷해요. 단독 기술로서의 유행은 지났지만, 그 알맹이는 위 네 가지 안에 고스란히 남아 있네요. 그러니 우리가 외워야 할 건 간판이 아니라 이 알맹이예요. 마지막으로, 그래서 얼마나 따라가면 되는지를 부담 없이 정리해 드릴게요.