AI 엔지니어링

우리는 지금 AI라는 거대한 기술 발전의 과도기를 살아가는 세대라는 말을 자주 듣는다. 처음 AI를 접했던 경험은 많은 사람들과 크게 다르지 않았다. ChatGPT에 이것저것 질문을 던지고, 자연스럽게 답을 해주는 모습이 그저 신기하기만 했다.

한편으로는 사실이 아닌 내용을 마치 사실인 것처럼 자신 있게 이야기하는 할루시네이션(Hallucination)을 보며 재미있는 장난감처럼 느껴지기도 했다. 하지만 시간이 흐르면서 이러한 현상은 점차 줄어들었고, 이제는 AI가 없다면 업무와 일상 모두 불편하지 않을까 하는 생각이 들 정도로 자연스럽게 의지하게 되었다.

시간이 지날수록 AI의 발전 속도는 놀라울 만큼 빨라지고 있다. 처음 프론트엔드 개발을 시작했을 때 JavaScript를 배우고, 이후 React와 TypeScript, Next.js, 그리고 수많은 상태 관리 라이브러리가 빠르게 등장하며 생태계가 변화했던 몇 년의 시간이 떠오른다. 지금의 AI는 그 변화의 속도를 몇 배는 압축해 놓은 것처럼 느껴진다.

하지만 너무 빠른 발전 때문이었을까. 문득 나는 AI가 어떻게 발전해 왔고, 지금은 어떤 방향으로 나아가고 있는지 제대로 이해하지 못한 채 그저 사용하는 데만 집중하고 있는 것은 아닐까 하는 생각이 들었다.

최근에는 AI를 잘 활용하는 방법이나 AI 시스템을 구축하는 방법을 이야기할 때 "AI 엔지니어링"이라는 용어를 자주 접하게 된다. 프롬프트 엔지니어링에서 시작해 컨텍스트 엔지니어링, 하네스 엔지니어링, 그리고 최근에는 루프 엔지니어링까지 AI 엔지니어링의 개념도 빠르게 변화하고 있다.

이번 글에서는 지금까지 AI 엔지니어링이 어떤 과정을 거쳐 발전해 왔는지 간단히 돌아보고, 그 흐름 속에서 AI를 조금 더 잘 활용하기 위한 인사이트를 정리해 보고자 한다.

프롬프트 엔지니어링

처음 AI를 접했을 때는 이것저것 질문을 던지며 만능 척척박사라도 만난 것처럼 신기했다. 하지만 조금만 기대에 미치지 못하는 답변을 받으면 "아직은 멀었구나."라는 생각이 들곤 했다.

그러던 중 프롬프트 엔지니어링(Prompt Engineering)이라는 개념이 등장했다. 어떻게 질문하느냐에 따라 AI의 답변 품질이 크게 달라질 수 있다는 이야기를 접했고, 나 역시 같은 질문을 여러 방식으로 바꿔가며 AI를 사용하기 시작했다.

프롬프트 엔지니어링은 원하는 결과를 보다 안정적으로 얻기 위해 AI에게 전달하는 입력(프롬프트)을 설계하고 구조화하는 방법이다. 같은 AI 모델이라도 질문을 어떻게 작성하느냐에 따라 답변의 깊이와 정확도, 표현 방식이 크게 달라졌다.

이러한 모습은 사람과 대화하는 방식과도 닮아 있었다. 같은 내용을 묻더라도 질문을 어떻게 하느냐에 따라 상대방의 답변이 달라지듯, AI 역시 입력에 따라 전혀 다른 결과를 만들어냈다. 그래서 당시에는 AI 모델의 성능뿐 아니라 질문을 잘 만드는 능력 또한 중요한 경쟁력처럼 느껴졌고, 마치 사용자의 "질문하는 능력"을 시험하는 듯해 흥미롭게 다가왔다.

프롬프트 엔지니어링에는 몇 가지 핵심 원칙이 있다. 흥미로운 점은 이러한 원칙들이 이후 등장한 AI 엔지니어링 개념에도 공통적으로 적용된다는 것이다. 결국 프롬프트 엔지니어링은 AI 엔지니어링 전반을 관통하는 가장 기본적인 토대가 되었다고 생각한다.

• 구체적·긍정적으로 지시하라 — "하지 마"보다 "이렇게 하라", 모호어 대신 측정 가능한 조건을 준다.
• 단계로 쪼개라 — 추론은 결론 전에 단계별로 펼치게 하고, 큰 작업은 초안 → 검토 → 수정처럼 프롬프트를 나눈다.
• 예시와 역할로 틀을 잡아라 — 정답 예시와 페르소나로 형식·톤·관점을 한 번에 정렬한다.
• 구조와 형식을 지정하라 — 입력은 구분자로 나누고, 출력은 형식을 강제하며 응답 첫 글자를 채워 군더더기를 막는다.
• 모르면 모른다고 하게 하라 — 탈출구를 열어 그럴듯한 거짓(환각)을 줄인다.
• 측정하며 개선하라 — 감이 아니라 평가셋 점수로 반복 개선한다.

컨텍스트 엔지니어링

프롬프트 엔지니어링이 "어떻게 질문할 것인가"에 초점을 맞췄다면, 컨텍스트 엔지니어링(Context Engineering)은 "AI가 어떤 정보를 바탕으로 답변을 생성할 것인가"에 초점을 맞추기 시작했다. 단순히 질문을 잘 작성하는 것을 넘어, 모델이 참고해야 할 정보를 어떻게 제공하고 관리할 것인지가 중요한 문제로 떠오른 것이다.

물론 AI 모델 자체의 성능이 크게 향상된 것도 답변의 품질이 높아진 이유 중 하나다. 하지만 그에 못지않게 모델이 참고하는 정보를 적절하게 제공하고 관리하는 전략이 발전하면서, 이전보다 훨씬 신뢰도 높은 답변을 만들어낼 수 있게 되었다.

대표적으로 외부 데이터를 활용하기 위한 다양한 방법들이 등장했다. RAG(Retrieval-Augmented Generation)를 통해 검색 결과를 모델에게 제공하거나, MCP(Model Context Protocol)를 이용해 데이터베이스, 파일 시스템, API와 같은 외부 시스템에 접근하여 필요한 정보를 가져오는 방식이 활용되기 시작했다. AI는 더 이상 학습된 지식만으로 답변하는 것이 아니라, 필요한 정보를 실시간으로 참고하며 응답을 생성하게 된 것이다.

하지만 컨텍스트를 무한정 늘린다고 해서 항상 좋은 결과가 나오는 것은 아니었다. 입력되는 정보가 많아질수록 중요한 정보를 놓치거나, 긴 문맥에서 필요한 내용을 정확하게 회상하고 추론하는 능력이 떨어지는 문제도 함께 나타났다. 이러한 한계를 해결하기 위해 필요한 정보만 선별하여 제공하거나, 긴 문서를 요약 압축하고, 작업을 여러 개의 컨텍스트로 나누어 처리하는 등 다양한 컨텍스트 관리 전략이 함께 발전하게 되었다.

• 꼭 필요한 것만, 필요할 때 넣어라 — 신호 강한 정보만 최소로, 미리 채우지 말고 그 시점에 검색·주입한다(just-in-time).
• 반복되는 정보는 위치를 정해 재사용하라 — 자주 안 쓰는 것은 외부 저장소로 빼 필요할 때만 검색·주입하고, 매번 같은 고정분(시스템 프롬프트·도구 정의)은 앞쪽에 고정해 프롬프트 캐싱으로 재연산을 아낀다.
• 길어지면 압축하라 — 오래된 이력·도구 결과를 요약본으로 갈아끼워 토큰을 회수한다(compaction).
• 구조와 위치로 배치하라 — 지침·데이터·이력을 구분자로 나누고, 중요한 지침은 모델이 가장 잘 보는 처음과 끝에 둔다.
• 도구를 절제하라 — 필요한 도구만 노출하고, 결과도 원본 대신 필요한 부분만 남긴다.
• 컨텍스트를 격리하라 — 큰 작업은 서브 에이전트로 나눠 각자 깨끗한 창에서 처리한다.
• 측정하며 줄여라 — 무엇을 넣고 뺄지 감이 아니라 평가셋 점수로 반복 검증한다.

하네스 엔지니어링

AI는 점점 더 업무 전반으로 확장되기 시작했다. 단순히 질문에 답하는 도구를 넘어 개발 워크플로우에 자연스럽게 스며들었고, 코드 리뷰부터 QA, 테스트 자동화, 릴리즈 노트 작성, 문서화까지 다양한 작업을 수행하게 되었다. 마치 하나의 구성원처럼 시스템 곳곳에서 역할을 수행하기 시작한 것이다.

이처럼 AI가 시스템 전반에서 다양한 작업을 수행하게 되면서 단순히 좋은 프롬프트를 작성하거나 필요한 정보를 제공하는 것만으로는 부족해졌다. AI가 어떤 권한을 가지고, 어떤 도구를 사용할 수 있으며, 어떤 순서로 작업을 수행하고, 어떤 기준으로 결과를 검증할 것인지까지 함께 설계해야 하는 시대가 되었다. 이러한 흐름 속에서 등장한 개념이 바로 하네스 엔지니어링(Harness Engineering)이다.

처음 하네스라는 개념을 접했을 때는 쉽게 이해되지 않았다. AI의 스킬(Skill)을 정의하는 것과 크게 다르지 않은 것처럼 느껴졌기 때문이다. 스킬과 하네스를 정의하는 방식 모두 일종의 매뉴얼을 작성하는 형태를 띠고 있어 더욱 비슷하게 보였다.

하지만 둘은 역할이 분명히 달랐다. 스킬은 AI가 "무엇을 할 수 있는지"를 정의하는 기능 단위에 가깝다. 반면 하네스는 AI가 "언제, 어떻게, 어떤 환경에서 그 능력을 사용할 것인지"를 설계한다. 즉, 개별 기능을 정의하는 것이 아니라 AI가 신뢰성 있게 동작할 수 있도록 실행 환경과 제약, 워크플로우를 구성하는 설계에 더 가깝다.

하네스 엔지니어링에는 하나의 정답이 존재하지 않는다. 프롬프트나 컨텍스트를 다루는 것처럼 일정한 원칙은 있지만, 실제 하네스의 형태는 조직의 업무 방식과 시스템 구조에 따라 매우 다양하게 설계될 수 있다. 그렇기 때문에 최근 많은 기업들은 AI가 일관되고 신뢰성 있게 동작할 수 있도록 하네스를 구축하고, 이를 기반으로 안정적인 AI 인프라와 에이전트 시스템을 만들어 가고 있다.

• 루프를 단순하고 예측 가능하게 설계하라 — 관찰 → 판단 → 행동 → 관찰의 제어 흐름을 명료하게 유지한다.
• 도구를 최소 권한으로 안전하게 가둬라 — 샌드박스·권한·정책으로 필요한 만큼만 허용하고 위험 행동을 차단한다.
• 피드백으로 회복하라 — 도구 결과·에러를 즉시 컨텍스트에 반영하고, 재시도·폴백으로 멈추지 않는다.
• 사람이 감독·개입하게 하라 — 로깅·트레이싱으로 추적하고, 되돌리기 어려운 행동엔 확인을 거친다.
• 상태를 명시적으로 관리하라 — 메모리·진행 상태·세션을 하네스가 일관되게 보관·복원한다.

루프 엔지니어링

2026년 들어서는 루프 엔지니어링(Loop Engineering)이라는 표현이 사용되기 시작했다. 루프 엔지니어링은 에이전트가 프롬프트를 생성하고, 필요한 컨텍스트를 수집하며, 결과를 검증하고, 목표를 달성할 때까지 다시 실행하는 "반복적인 실행 시스템 자체를 설계하는 것"을 의미한다.

기존에는 하나의 프롬프트로 하나의 응답을 얻는 것이 일반적인 사용 방식이었다면, 루프 엔지니어링에서는 목표만 정의하면 AI가 스스로 계획을 세우고, 실행 결과를 평가한 뒤 부족한 부분을 보완하며 반복적으로 작업을 수행한다. 즉, AI를 단순한 질의응답 모델이 아닌 목표를 달성하는 에이전트로 바라보는 관점이라 할 수 있다.

아직 직접 루프 엔지니어링을 적용한 시스템을 설계해 본 경험은 없지만, 다양한 사례를 살펴보며 업무에 적용할 수 있는 방향을 고민하고 있다. 예를 들어 스케줄러가 주기적으로 시스템 로그와 운영 지표를 분석하여 장애나 이상 징후를 감지하고, 필요한 작업을 생성한 뒤 AI가 수정안을 작성하고 Pull Request를 생성하며, 리뷰 결과를 반영해 다시 개선하는 일련의 과정을 하나의 루프로 구성할 수 있을 것이다.

이처럼 루프 엔지니어링은 정해진 하나의 형태가 있는 것이 아니라, 하네스 엔지니어링과 마찬가지로 조직의 업무 방식과 시스템 구조에 맞춰 매우 다양한 형태로 설계될 수 있다. 앞으로 AI 에이전트가 더욱 발전할수록 이러한 반복 실행 구조는 AI 시스템을 설계하는 핵심 요소 중 하나가 될 것이라고 생각한다.

• 종료를 명확히 통제하라 — 성공 기준·최대 반복·토큰/시간 예산으로 언제 멈출지 미리 정한다.
• 한 번에 한 걸음, 검증하며 돌아라 — 작고 검증 가능한 단위로 행동 → 검증 → 반복한다.
• 정체를 감지해 빠져나와라 — 진척 없는 반복·무한 루프를 탐지해 전략을 바꾸거나 중단한다.
• 매 반복의 결과를 다음 계획에 반영하라 — 에러·피드백으로 자기 교정하며 수렴시킨다.
• 진행 상태를 이어가라 — 직전까지의 학습·계획을 다음 반복으로 넘겨 같은 일을 되풀이하지 않는다.

AI 엔지니어링

이후 AI 엔지니어링이 어떠한 방향으로 발전해 나갈지는 예측하기 어려울 것 같다. 하지만 지금까지 AI 엔지니어링은 이전의 엔지니어링을 점차 확장해 나가며 발전해 왔고, 이전 AI 엔지니어링에서 중요했던 요소들은 이후에도 기본 요소로서 계속 중요하게 챙겨야 하는 부분이라고 생각한다.

몇 년간 빠르게 발전해 온 프론트엔드 개발에서도 우리가 중요하게 여겼던 핵심 요소들은 새로운 기술이 등장하더라도 계속해서 중요한 부분으로 남아 있었던 것과 비슷하지 않을까 생각된다.

"역사를 잊은 민족에게 미래는 없다"는 말처럼, 이전의 AI 엔지니어링을 돌아보는 시간을 가지는 것도 예측할 수 없이 발전해 가는 AI의 미래를 대비하기 위해 우리가 할 수 있는 일이 아닐까 싶다. 이 글을 정리하며 이전의 중요 요소들을 잘 챙기고 있었는지 다시 한번 돌아보고, 곧 새롭게 나타날 AI의 모습에 대비해야겠다.

"The farther backward you can look, the farther forward you are likely to see." - Winston Churchill -