AI 쪽을 계속 보다 보면 재미있는 변화가 하나 있습니다.
불과 몇 년 사이 AI를 다루는 방법을 설명하는 용어가 계속 바뀌고 있습니다. 그리고 그 변화를 순서대로 놓고 보면 앞으로 어떤 엔지니어링이 중요해질지도 어느 정도 보이는 것 같습니다.
1. 처음에는 Prompt Engineering이었습니다
초기에는 결국 “AI에게 어떻게 말해야 좋은 답을 받을까?”가 가장 중요했습니다.
프롬프트를 구체적으로 작성하고, 역할을 부여하고, 예제를 넣고, 출력 형식을 지정했습니다.
Prompt Engineering이라는 말이 유행했고 한동안은 프롬프트를 잘 작성하는 것 자체가 하나의 능력으로 여겨졌습니다.
그런데 모델이 점점 좋아지면서 상황이 조금 달라졌습니다.
2. Prompt에서 Context로
AI에게 질문 하나를 잘하는 것보다 AI가 일을 하는 데 필요한 정보를 제대로 제공하는 것이 중요해졌습니다.
프로젝트 구조, 기존 코드, 문서, 사용자 정보, 이전 작업 기록, 규칙 등을 어떻게 필요한 순간에 넣어줄 것인가가 중요해졌습니다.
Prompt Engineering
→ Context Engineering
여기에 AGENTS.md 같은 룰 파일과 Memory 같은 개념도 자연스럽게 붙기 시작했습니다.
AI에게 매번 긴 설명을 반복하기보다 “이 프로젝트에서는 이렇게 일한다”라는 환경 자체를 만들어주는 방향으로 변한 것입니다.
3. Context에서 Agent로
그리고 AI가 답변만 하는 존재에서 직접 행동하는 존재로 바뀌기 시작했습니다.
파일을 읽고 수정합니다.
터미널을 실행합니다.
브라우저를 조작합니다.
API를 호출합니다.
필요한 도구를 찾아 사용합니다.
Skills와 MCP 같은 구조가 빠르게 확산된 것도 이 흐름과 연결되어 있다고 생각합니다.
Context Engineering
→ Agent Engineering
이제 중요한 것은 단순히 좋은 답을 생성하는 것이 아니라 AI가 실제 작업을 끝낼 수 있도록 만드는 것입니다.
4. 그리고 지금은 Harness, Loop, Graph
최근에는 Agent 하나를 잘 만드는 것에서 다시 한 단계 넘어가는 느낌입니다.
Agent가 계획을 세우고 실행하고 결과를 확인합니다. 실패하면 다시 시도하고, 필요하면 다른 Agent에게 작업을 넘깁니다.
이 과정에서 Harness, Loop, Graph, Orchestration 같은 개념들이 계속 등장하고 있습니다.
지금까지의 흐름을 아주 단순하게 정리하면 이런 모습입니다.
Prompt
→ Context
→ Rules / Memory
→ Skills
→ MCP / Tools
→ Agent
→ Harness
→ Loop
→ Graph / Orchestration
처음에는 “AI에게 뭐라고 말할까?”가 중요했다면 지금은 “AI가 어떻게 일하게 만들까?”로 관심사가 이동하고 있습니다.
그렇다면 그다음은 뭘까요?
현재 흐름을 보고 앞으로 더 중요해질 AI 엔지니어링을 세 가지 정도 예측해봤습니다.
예측 1. Workflow Engineering
개인적으로 가장 먼저 크게 부각될 가능성이 높다고 생각합니다.
지금은 Cursor, Claude Code, Codex 같은 Agent에게 각각 작업을 시키는 단계입니다. 하지만 실제 업무는 하나의 작업으로 끝나지 않습니다.
요구사항 → 조사 → 구현 → 테스트 → 리뷰 → 배포 → 모니터링 → 개선
결국 하나의 긴 Workflow입니다.
앞으로는 “AI에게 일을 잘 시키는 사람”보다 “AI와 인간, 기존 시스템을 하나의 업무 흐름으로 연결하는 사람”이 중요해질 가능성이 높습니다.
이건 개발에만 해당하지 않습니다.
마케팅이라면 콘텐츠 조사 → 작성 → 검수 → 게시 → 성과 수집 → 분석 → 다음 콘텐츠 생성으로 이어집니다.
회계라면 문서 수집 → 분류 → 데이터 입력 → 검증 → 승인 → 보고가 될 수 있습니다.
결국 Agent 하나의 능력보다 여러 Agent와 사람, 시스템을 실제 업무 프로세스에 어떻게 연결하느냐가 중요해집니다.
그래서 Agent Engineering 다음에는 Workflow Engineering이 훨씬 자주 등장하지 않을까 예상합니다.
예측 2. Runtime Engineering
Agent가 30초짜리 작업을 할 때는 크게 신경 쓸 것이 없습니다.
하지만 Agent가 몇 시간, 며칠 또는 계속 실행되기 시작하면 완전히 다른 문제가 생깁니다.
Agent는 어디에서 실행할 것인가?
중간 상태는 어디에 저장할 것인가?
죽으면 어디서 다시 시작할 것인가?
어떤 파일과 시스템에 접근할 수 있는가?
동시에 몇 개까지 실행할 것인가?
비용이 너무 커지면 어떻게 멈출 것인가?
결국 AI Agent도 하나의 실제 실행 시스템이 됩니다.
현재 이야기되는 Harness가 점점 커지고 표준화되면 결국 Agent Runtime 같은 형태로 발전할 가능성이 있다고 생각합니다.
그때는 “어떤 모델을 사용하나요?”만큼이나 “어떤 Runtime 위에서 Agent를 실행하나요?”가 중요한 기술 선택이 될 수도 있습니다.
예측 3. Reliability Engineering
개인적으로는 결국 이 영역이 가장 중요해질 가능성이 높다고 봅니다.
AI 데모를 보면 정말 놀랍습니다. 하지만 실제 회사 업무에 넣는 순간 질문이 완전히 달라집니다.
“그래서 이거 믿고 놔둬도 돼?”
100번 중 90번 성공하는 Agent는 데모에서는 훌륭합니다.
하지만 결제, 고객 응대, 배포, 데이터 처리 같은 실제 업무에서는 성공한 90번보다 실패한 10번을 어떻게 처리하는지가 훨씬 중요합니다.
실패 감지 → 자동 재시도 → 결과 검증 → 다른 방법으로 재실행 → 롤백 → 로그/관측 → 필요하면 인간 호출
이런 구조가 점점 중요해질 수밖에 없습니다.
결국 AI가 얼마나 똑똑한지를 평가하는 것에서 “AI가 얼마나 안정적으로 일을 끝낼 수 있는가?”를 평가하는 방향으로 이동하게 됩니다.
SRE가 서버와 서비스를 안정적으로 운영하기 위한 중요한 엔지니어링 영역이 된 것처럼 AI Reliability Engineering 역시 별도의 큰 영역으로 자리 잡을 가능성이 있다고 생각합니다.
앞으로의 흐름을 예상해보면
Prompt Engineering
→ Context Engineering
→ Agent Engineering
→ Workflow Engineering
→ Runtime Engineering
→ Reliability Engineering
정도가 되지 않을까 생각합니다.
물론 정확히 이런 이름으로 굳어질지는 아무도 모릅니다.
하지만 방향 자체는 꽤 명확해 보입니다.
AI가 점점 똑똑해질수록 인간이 해야 할 일은 AI를 더 똑똑하게 만드는 것에서 “똑똑한 AI에게 실제 일을 맡길 수 있는 시스템을 만드는 것”으로 이동하고 있습니다.
모델 성능은 OpenAI, Anthropic, Google 같은 회사들이 계속 올려줄 겁니다.
그 모델을 가지고 어떻게 일을 연결할 것인가.
어떻게 오랫동안 실행시킬 것인가.
실패했을 때 어떻게 복구할 것인가.
그리고 어떻게 믿고 실제 업무를 맡길 것인가.
저는 이 부분이 앞으로 몇 년간 AI 엔지니어링의 꽤 큰 주제가 되지 않을까 생각합니다.
몇 년 뒤 이 글을 다시 찾아서 얼마나 맞았는지 한번 확인해보고 싶네요 ㅎㅎ