2023 ~ 2026년 AI 사용법의 진화

#1 개요

#1-1 What

2022년 말 ChatGPT 출시 이후 LLM은 빠르게 대중화되었다. 개발자들은 2026년 지금까지도 현재진행형으로, LLM이 더 잘 응답하거나 행동하도록 설계하는 기법을 연구하고 있다. 가장 대표적인 기법 3가지를 시간순으로 나열해본다.

#1-2 주의할 점

본 게시글의 제목에 '진화'라는 단어를 썼다. 그래서 "(비교적) 오래된 기법은 혹시 도태된 것인가?"라고 생각할 수도 있지만, 그렇지 않다. 모든 기법은 전부 중요하다. '진화'는 '개발자 관심사의 이동 경로'일 뿐, 모든 기법은 충실히 지켜야 한다 (세대교체가 아니라 동시 병행).

#2 프롬프트 엔지니어링

#2-1 WhatㆍWhy

"어떻게 질문해야 잘 대답하는가?" (입력 최적화)

입력 → 출력의 구조에서 입력을 조작해 좋은 출력을 기대한다. "가는 말이 고와야 오는 말도 곱다"라는 속담은 LLM에도 적용되기 때문이다.

 

#2-2 How

역할 부여 (Role Prompting)

"너는 초등학교 교사야. 초등학생이 이해하기 쉬운 방식으로 설명해."

어떤 존재로서 답해야 하는지를 지정해ㆍ관점ㆍ태도ㆍ전문성 프레임을 변경한다.

 

Chain-of-Thought Prompting (CoT)

"A, B, C의 단계별로 생각해."

모델이 사고하는 순서(= 추론 전개 방식)를 정한다

 

ReAct (Reason + Act)

"생각하고, 행동하고, 관찰하고, 다시 생각해."

모델이 추론과 외부 행동을 번갈아 수행하는 패턴을 설계한다. '행동 후 피드백 기반 수정' 기법이라는 점에서 현대 AI 에이전트의 원형이 되는 기법이기도 하다

 

#3 컨텍스트 엔지니어링

#3-1 WhatㆍWhy

"어떤 정보를 떠먹여 줘야 잘 대답하는가?" (정보 공급)

컨텍스트 윈도우(Context window)는 LLM 모델이 가진 일종의 램(RAM)이다. 컴퓨터의 RAM과 마찬가지로 무한한 크기가 아니기 때문에, 적당한 크기의 정확한 정보를 적재적소에 제공하는 것이 필요하다.

 

이는 프롬프트 엔지니어링의 한계로 이어진다. 양질의 질문만으로는, LLM 모델의 물리적 한계(컨텍스트 윈도우 크기)를 극복할 수 없는 것이다.

 

또 다른 이유: 비용 절감

질문(요청)에 담긴 정보(컨텍스트)가 커질수록 LLM의 컴퓨팅 비용과 응답이 시간 급증한다. 반면, 같은 정보를 '반복 전달'(= 2번 이상 전달)하는 경우에는 (정보가) 캐시 처리되어 비용이 거의 10분의 1로 줄어든다. AI 사용료를 아끼기 위해서라도 컨텍스트 엔지니어링은 필요하다.

 

#3-2 종류

• System Context: 에이전트가 항상 참조하는 기본 설정
• Conversation Context: 대화 과정에서 누적되는 정보
• Tool & Environment Context: 도구 실행으로 얻는 실시간 정보

 

#3-3 '다다익램'은 LLM에서도 통할까?

'다다익램'은 컴퓨터의 RAM 크기는 클수록 좋다는 의미다. LLM의 RAM인 컨텍스트 윈도우에게도 일반적으로는 통하는 말이다. 컨텍스트 윈도우가 커질수록 긴 대화를 잘 기억하고, 연속적인 작업도 잘 수행한다. 하지만 아래의 2가지 주의 사항을 고려해야 한다.

 

1. Lost in the Middle: LLM이 전체 컨텍스트의 첫 부분과 끝부분은 잘 지키지만, 중간(Middle) 부분에 있는 컨텍스트일수록 무시할 확률이 높은 현상을 의미한다. 컨텍스트 윈도우의 크기가 커질수록 많은 정보(컨텍스트)를 넣을 수 있지만, 그에 비례해서 Lost in the Middle 현상 제어의 필요성도 커진다.
2. 작업대(컨텍스트 윈도우)에 관련 없는 (쓰레기) 정보가 넘치면 모델의 판단이 '오염'되어 결과의 질이 저해된다. 무작정 많이 넣는 것만이 능사는 아니다.

 

#3-4 How

Retrieval-Augmented Generation (RAG)

"모르는 건 알아서 검색해."

필요한 정보를 외부 저장소에서 알아서 찾게 풀어준다. 웹(구글 등), DB의 특정 레코드, Notion 문서, 구글 드라이브 등 검색(접근)할 수 있는 매개체를 활용하게 만든다.

 

Context Packing

"(LLM이 RAG 등을 활용해 가져온) 정보들을 알아서 최적화해"

컨텍스트 윈도우 안에 정보 조각들을 어떤 우선순위와 압축도로 넣을지 결정한다. 이른바 선택과 집중이다.

 

Chunking

검색ㆍ저장ㆍ삽입을 용이하게 하려고 정보(문서 파일 등)를 적절하게 작은 크기의 조각(Chunk) 단위로 잘라두는 것.

 

• Chunking은 RAG이나 Context Packing처럼 LLM이 동작 중(런타임)에 하는 일이 아니라 사람이 하는 일이다. 요즈음엔 런타임 Chunking도 많아졌다고 한다.
• 혹은, 사람이 LLM에게 (본격적인 핵심 질문을 하기 전에) 미리 시켜둘 일이다.

 

#4 하네스 엔지니어링

#4-1 Why

"원하는 대답을 강요하려면 어떻게 해야 하는가?" (실행 통제)

하네스 엔지니어링 전까지 LLM에게 질문(요청)한다는 것은, 곧 부탁하는 것과 같았다. 왜냐하면 LLM은 그 원리상, 뜬금없는 대답을 할 수도 있기 때문이다. 그럴 때의 시간 낭비를 막기 위해서, LLM이 반드시 내가 원하는 답을 내놓도록 강제할 필요성이 생겼다. Structured Output 등 (지엽적인) 실행 통제 기법은 이미 존재했으나, 이를 좀 더 체계화하고 (전체적으로) 확장할 필요를 느낀 것이다.

 

주의할 점

사실 '강제'라는 표현은 직관적인 설명을 위해 과장한 감이 없지 않다. 여기서 말하는 '강제'란,

1. "특정 파일 속 소스 코드 실행"같이 거의 100%의 일관성을 지닌 요청
2. 여전히 '부탁'처럼 보일 순 있으나, 프롬프트 엔지니어링 및 컨텍스트 엔지니어링의 패러다임 때와 비교하면 훨씬 더 명령적(↔ 선언적)인 요청
3. (똑똑하지만 동시에) 불안정한 LLM을 안정적으로 일하게 만드는 기술

(1)부터 (3)까지의 모두를 포함한다.

 

#4-2 What

LLM을 말(Horse)로 비유하자면, 하네스 엔지니어링은 말에 마구(Harness)를 씌워 내가 원하는 행동을 하도록 조종(강제)하는 것이다. 구체적으로는 아래와 같은 절차를 설계하는 걸 하네스 엔지니어링이라 부른다.

 

Agent가 Context를 바탕으로 Plan을 세우고,
Tool / MCP를 사용해 실행하고,
Hook과 Skill로 품질을 제어하고,
Human이 감독한다. (출처)

AI Agent는 알아서 판단하고 계획해서 결과를 내는 AI를 의미한다. 즉, AI Agent 구축엔 하네스 엔지니어링이 반드시 들어가야 한다. 실무적으로는 둘을 같다고 봐도 된다. 그 때문에 바로 아래에서 이어지는 #4-3에서, 하네스 엔지니어링의 기법과 AI Agent 구축 기법을 구분하지 않고 서술했다.

 

#4-3 How

Planning
사용자의 요청(질문) 즉 복잡한 과제를 나눠서, 실행할 수 있는 Workflow로 바꾸는 것. 일반적으로 AI는 Workflow를 세운 뒤 사용자에게 보여주고 이대로 진행할지를 먼저 확인받는다. 저위험 과제의 경우엔 승인 없이 그냥 즉시 실행하기도 한다.

Sub Agent에 위임
#3-3에서 말했던 Lost in the Middle 등의 이유로, 단일 에이전트에게 많은 일을 시키면 컨텍스트를 까먹는 현상이 발생한다. 따라서, AI Agent를 여러 Sub Agent를 나누는 구조가 나오게 되었다. Sub Agent의 역할은 프론트엔드 전문, 백엔드 전문, DB 설계 전문, 테스트 전문 등으로 다양하게 나뉠 수 있다. 또, 여러 Sub Agent를 관리하는 Agent를 Orchestrator Agent라 부른다.

 

개략적인 동작 방식은 아래와 같다.

1. Orchestrator Agent가 각 Sub Agent에 '작업을 분배'(= Fan Out)
2. 각 Sub Agent는 병렬적으로 독립적인 컨텍스트와 도구를 가지고 작업 수행 후 반환
3. Orchestrator Agent가 반환된 결과를 통합(= Fan In)

 

Tool, Plugin, Model Context Protocol (MCP)

Tool: 개별 함수
Plugin: Tool 묶음
MCP: 모든 Tool과 Plugin을 어떤 AI 모델에서도 쓸 수 있게 하는 표준화된 인터페이스로 연결
(≈ 충전 케이블 타입을 USB-C로 통일했던 과거의 사례)

에이전트의 손과 발이 되어, 실제 세계와의 상호작용을 하는 기법들이다. 좀 더 엄밀하게 말하자면, Tool은 AI가 호출할 수 있는 기능의 단위, Plugin은 어떤 기능들을 하나의 패키지로 묶은 배포용 단위다.

 

Skill & Hook

Skill: 에이전트가 특정 작업을 수행할 때 참조하는 Best Practice 문서
Hook: 특정 조건 만족 시 어떤 일을 하라고 강제

에이전트의 행동을 제약하는 기법들이다. Hook에는 아래와 같은 4가지 종류가 있다.

• Pre-action: 에이전트가 행동하기 전 수행
• Post-action: 에이전트가 행동한 후 수행
• Validation: 에이전트 출력의 품질 검증
• Notification: 특정 조건 충족 시 인간에게 알림

 

Human In The Loop (HITL)

AI 동작의 중간 또는 최종 단계에서, 인간 판단이 결과에 영향을 주도록 설계하는 것. 앞서 설명한 Planning에서 설명했듯, Agent가 실행할 일련의 계획을 사람에게 먼저 확인받고 진행하는 것도 HITL의 일부다. HITL은 2종류로 나뉜다.

• Task-level HITL: 개별 작업 승인/수정
  • AI가 짠 Planning 검토
  • AI 산출물의 결과 검수
  • 민감하거나 애매한 동작 수행 전 확인받기
• System-level HITL: 전체 루프 성능 평가/개선
  • Prompt 수정
  • 제목 생성 Skill 교체
  • 검수 Rule 추가
  • 코드 생성 후 테스트 단계 추가

 

#4-4 실습

추가 예정 (다음 게시글로 이어짐).

 

#4-5 용어에 대한 논쟁

테스트/배포 자동화 (CI/CD), 성능 평가 파이프라인(흐름) 등의 개념은 LLM이 대중화되기 한참 전에 나왔다. 저 개념들을 LLM을 활용해 구현했을 뿐인데, 그걸 굳이 "하네스 엔지니어링"라는 신조어로 재포장하는 것에 대해 거부감이 있었다고 한다.

 

하지만 컨텍스트 엔지니어링의 한계 즉, 부탁의 한계를 극복한다는 점에서 기존 컨텍스트 엔지니어링과 명확하게 구분되는 신조어는 필요하다고 생각한다. 그리고 프로그래밍에 대한 비전공자들의 접근성이 좋아진 요즘, 더 시적(?)인 용어는 개념의 부드러운 인지를 돕는다.

 

물론 어느 쪽이든, 용어 속에 있는 본질은 알아야 할 테다.

 

#5 요약

ChatGPT 이후, 개발자들은 '챗봇'의 잠재력을 끌어내 '에이전트'로 만드는 기법들을 고안해 냈다.

 

#6 출처

• [YouTube] AI 엔지니어링이 4년간 이렇게 변화했습니다 | 개발동생 하네스 공개
• [YouTube] 메타 엔지니어가 알려주는 에이전틱 엔지니어링 핵심 개념 5가지 총정리
• [YouTube] 프롬프트 엔지니어링은 끝났습니다: 이제 '하네스'의 시대입니다