# **LLM 이란?**

LLM은 *Large Language Model*의 약자로, 우리말로 풀어 쓰면 "대규모 언어 모델"입니다. 이름 그대로 인터넷의 방대한 문서, 책, 코드, 대화 기록 등 어마어마한 양의 텍스트 데이터를 학습하여, 사람이 사용하는 언어를 이해하고 새로운 문장을 만들어낼 수 있도록 훈련된 인공지능 모델입니다.

LLM이 잘하는 일을 한마디로 정리하면 **"사람의 언어로 묻고, 사람의 언어로 답하는 것"** 입니다. 더 구체적으로는 질문에 답을 하거나, 긴 글을 짧게 요약하거나, 한국어를 영어로 번역하거나, 코드를 작성하고 설명하거나, 머릿속에 흩어진 아이디어를 정돈된 문서로 만들어주는 일을 잘합니다. 예를 들어 "지난 회의록을 한 페이지로 정리해줘", "이 영어 메일을 정중한 한국어로 바꿔줘", "이 함수가 무엇을 하는지 초보자도 이해할 수 있게 설명해줘"와 같은 요청들은 모두 LLM이 능숙하게 처리할 수 있는 대표적인 작업입니다.

그렇다면 이미지 생성 모델, 음성 인식 모델 등 다양한 AI 모델이 있음에도 불구하고 왜 유독 **언어 모델**이 이렇게까지 주목을 받고 있을까요? 그 이유는 언어가 사람이 생각을 표현하고 다른 사람과 소통하는 **가장 기본적인 도구**이기 때문입니다. 우리는 그림을 그리거나 음악을 만들 때조차도 머릿속에서는 언어로 사고합니다. 따라서 AI가 사람과 자연스럽게 협업하기 위해 가장 먼저 익혀야 할 능력이 바로 언어이며, 언어를 다룰 줄 아는 AI는 곧 사람의 의도를 가장 빠르게 파악하고, 가장 폭넓은 작업에 활용될 수 있는 AI가 됩니다. 즉, 언어 모델은 **사람과 인공지능이 만나는 첫 번째 접점**이라고 할 수 있습니다.

# **다양한 LLM 모델과 서비스들**

우리는 다양한 LLM 모델과 LLM 서비스를 사용합니다. 여기에서 모델과 서비스를 혼동할 수 있으니 다시 한 번 짚고 넘어가겠습니다. 언어 모델로도 불리는 AI 모델이 생각을 하고 결과를 만들어내는 **뇌**에 비유된다면, 서비스는 카카오톡과 같이 우리가 모델과 더욱 편리하게 대화할 수 있도록 도와주는 **도구**입니다. 이 서비스는 모델에게 내가 전달하고 싶은 말을 더욱 쉽게 할 수 있도록 도와주고, 명확하지 않은 문장을 명확하게 다듬어주고, 모델이 생성한 데이터를 사람이 읽기 쉬운 형태로 시각화해주는 등 다양한 역할을 수행합니다.

![[Screenshot 2026-06-07 at 7.13.11 pm.png]]

AI 모델 또한 사람처럼 서로 잘하는 일이 다릅니다. 여기에서는 가장 대표적인 AI 모델인 GPT, Claude, Gemini, Grok, Qwen에 대해 살펴보겠습니다.

## **LLM 모델: 모두 다른 특성을 가져요**

같은 LLM이라고 해도 누가 만들었느냐, 어떤 목적으로 학습시켰느냐에 따라 성격이 꽤 다릅니다. 사람으로 비유하자면 같은 학교를 졸업한 친구들이라도 누구는 글쓰기를 잘하고, 누구는 수학을 잘하고, 누구는 농담을 잘하는 것과 비슷합니다. 대표적인 다섯 가지 모델을 하나씩 살펴보겠습니다.

![[Screenshot 2026-06-07 at 7.13.25 pm.png]]

### **GPT**

- **개발사**: 미국 **OpenAI**  
- **등장 시점**: 2022년 말 ChatGPT라는 서비스로 세상에 처음 공개되었으며, LLM이라는 단어를 대중에게 각인시킨 주인공  
- **사용자층**: 가장 먼저 시장에 등장한 만큼 사용자층이 넓음  
- **성능 특성**: 글쓰기, 요약, 번역, 코딩 등 어느 한쪽에 치우치지 않는 **범용적인 성능**을 보임  
- **모달리티 생태계**:  
  - 이미지 생성 모델인 DALL·E  
  - 음성 모델  
  - 영상 생성 모델 Sora  
- **종합적인 특징**: 텍스트로 시작해서 이미지·음성까지 한 번에 처리하는 통합적인 경험을 가장 빠르게 누릴 수 있는 모델

### **Claude**

- **개발사**: 미국 **Anthropic** (OpenAI 출신 연구자들이 설립)  
- **핵심 가치**: "안전한 인공지능"  
- **강점**:  
  - **긴 문서를 차분히 읽고 분석하는 능력**  
  - **신중한 추론 능력**  
  - **자연스러운 글쓰기**  
- **예시 활용**: 수십 페이지짜리 PDF 보고서를 통째로 던져주고 핵심 정리를 요청했을 때, 다른 모델에 비해 길이가 긴 맥락도 끝까지 놓치지 않고 따라가는 편  
- **개발자 도구**: 코드 작업을 위한 **Claude Code**라는 터미널 기반 에이전트를 함께 제공하여 개발자들 사이에서 큰 호응을 얻고 있음

### **Gemini**

- **개발사**: **Google DeepMind**  
- **회사 차원의 강점**:  
  - 전 세계 검색 데이터  
  - YouTube, Google Drive, Gmail 등 거대한 자체 서비스 생태계  
- **모델 특징**:  
  - 텍스트뿐만 아니라 **이미지·동영상·음성을 한꺼번에 다루는 멀티모달 능력**이 뛰어남  
  - 한 번에 받아들일 수 있는 정보의 양(컨텍스트 윈도우)이 매우 큼  
  - Google 검색과 결합되어 **최신 정보 검색**에 강함  
- **예시 활용**: 1시간짜리 회의 영상을 통째로 업로드해 "회의에서 결정된 사항만 표로 정리해줘"라고 요청 가능

### **Grok**

- **개발사**: 일론 머스크가 설립한 **xAI**  
- **응답 톤**:  
  - 다른 모델들이 비교적 조심스럽고 정제된 답변을 추구함  
  - Grok은 상대적으로 **유머러스하고 솔직한 톤**의 답변을 지향함  
- **데이터 연결성**:  
  - X(구 Twitter)와 같은 플랫폼과 직접 연결됨  
  - **실시간 트렌드·뉴스 정보**를 모델 응답에 빠르게 반영 가능  
- **강점 분야**: 시의성이 매우 강한 질문  
- **예시 활용**: "오늘 X에서 가장 화제가 되고 있는 주제는?"과 같은 질문에서 강점을 보임

### **Qwen**

- **개발사**: 중국 **알리바바(Alibaba)**  
- **언어 성능**: 중국어를 비롯한 **아시아권 언어**에서 특히 강한 성능  
- **오픈소스 공개**:  
  - 모델 가중치를 **오픈소스로 공개**  
  - 누구나 자신의 컴퓨터·서버에 모델을 내려받아 실행 가능  
  - 자신의 데이터로 추가 학습(파인튜닝) 가능  
- **유용한 활용 상황**:  
  - 회사 내부 데이터처럼 외부로 보내기 어려운 정보를 다뤄야 할 때  
  - 직접 모델을 커스터마이즈해야 할 때

## **LLM 서비스: 같은 모델도 서비스에 따라 다르게 동작해요**

앞에서 모델과 서비스는 다르다고 설명했습니다. 같은 GPT 모델을 쓰더라도 어떤 서비스에 얹어 사용하느냐에 따라 우리가 받는 결과물의 모습은 완전히 달라집니다. 이번 절에서는 대표적인 네 가지 형태의 LLM 서비스를 살펴보겠습니다.

![[Screenshot 2026-06-07 at 7.13.55 pm.png]]

### **가장 단순한 Chat Bot**

- **정의**: 사람들에게 가장 먼저 알려진 LLM 서비스 형태  
- **구조**: 화면에 채팅창 하나가 떠 있고, 거기에 질문을 입력하면 모델이 답을 돌려주는 단순한 구조  
- **개발 방향성**:  
  - 기능이 화려하지는 않음  
  - **사람이 묻는 것에 대답한다**는 가장 본질적인 작업에 최적화되어 발전  
- **웹 기반 대표 예시**: ChatGPT, Claude.ai, Gemini의 웹 인터페이스  
- **데스크톱 앱 형태로의 확장**:  
  - **Claude Desktop, Gemini Desktop, ChatGPT 데스크톱 앱** 등 PC 설치형 프로그램으로 발전  
  - 내 PC 안의 파일을 직접 읽거나 새 파일을 작성 가능  
  - 인터넷 브라우저를 열어 정보 검색 가능  
  - 컴퓨터와 한층 깊이 연동된 기능 제공

### **AI 기반 연구 서비스**

- **일반 챗봇의 답변 방식**: 모델이 이미 학습해둔 지식과 인터넷 크롤링을 통해 모은 정보들을 적당히 종합하여 답변 생성  
- **일반 챗봇의 한계**:  
  - **출처 추적의 어려움**: 모델이 어디서 어떤 정보를 가져왔는지 정확히 알기 어려움  
  - **환각(Hallucination)**: 실제로 존재하지 않는 정보를 사실처럼 만들어내는 현상이 발생함  
  - 학술 자료, 사내 문서처럼 정확성이 중요한 영역에서는 큰 약점이 됨  
- **AI 기반 연구 서비스의 등장 배경**: 위의 한계를 해결하기 위해 등장  
- **특징**:  
  - 사용자가 직접 업로드한 자료를 **꼼꼼히 분석**  
  - 모델의 일반 지식이 아닌 **제공된 정보를 근거**로 답변 생성  
- **대표 사례**: Google의 **NotebookLM**  
  - 사용자가 올린 논문, 보고서, 강의 자료를 분석해 핵심 정리  
  - 시각화 자료와 인사이트 제공  
  - 답변마다 어떤 자료의 어느 부분을 근거로 했는지 출처를 함께 표시  
  - 최근에는 주제만 던지면 관련 자료를 직접 수집해 주는 기능까지 추가됨

### **터미널 기반 AI 에이전트**

- **웹 챗봇의 한계**:  
  - 브라우저 안의 채팅창이라는 울타리에 갇혀 있음  
  - 내 컴퓨터의 파일을 직접 수정하거나 명령어를 실행하기 어려움  
  - 프로젝트 전체를 한꺼번에 들여다보는 일이 불가능  
- **터미널이란**:  
  - 마우스로 아이콘을 클릭하는 방식이 아니라, **명령어를 직접 입력해 컴퓨터를 조작**하는 검은 화면의 도구  
  - 개발자들이 코드를 작성하거나 서버를 다룰 때 주로 사용하는 환경  
- **터미널 기반 AI 에이전트의 정의**: 터미널 위에서 동작하며, **내 컴퓨터를 또 한 명의 동료처럼 직접 사용**할 수 있게 해 주는 AI 서비스  
- **수행 가능한 작업**:  
  - 파일 읽기·쓰기  
  - 디렉터리 구조 확인  
  - 명령어 실행  
  - 인터넷 브라우저를 띄워 자료 검색  
  - 그 외 사람이 컴퓨터로 할 수 있는 거의 모든 작업  
- **대표 예시**: **Claude Code, Gemini CLI, Codex**  
- **참고 사항**: 앞서 챗봇 절에서 언급한 Claude Desktop, Gemini Desktop이 PC를 다룰 수 있는 이유도 내부적으로 이런 터미널 기반 에이전트 기술을 활용하기 때문임  
- **강점 분야**: 다양한 파일 접근과 명령어 제어가 가능하므로 **코드 작성·수정 작업**에서 가장 강력한 성능을 발휘함

### **자율형 AI Agent**

- **터미널 기반 에이전트와의 차이**:  
  - 터미널 기반 에이전트: 사람이 옆에서 지켜보며 한 단계씩 지시를 내려야 동작함  
  - 자율형 AI Agent: **목표만 알려주면 계획 수립부터 실행 완료까지 사람의 개입 없이 끝까지 수행**  
- **동작 흐름**: 목표 전달 → 계획 수립 → 필요한 도구 선택 → 단계별 실행  
- **예시 시나리오**: "다음 주 부산 출장을 위한 항공권과 숙소를 예약하고, 일정표를 만들어 캘린더에 넣어줘"라고 한 번 지시하면 자율형 에이전트는 다음 흐름을 스스로 분해해 실행함  
  - 검색 → 비교 → 결제 → 일정 등록  
- **대표 사례**: Claude의 *Computer Use*, OpenAI의 *Operator*, 다양한 *Deep Research* 기능  
- **주의 사항**:  
  - 자율성이 높아질수록 잘못된 판단의 영향도 함께 커짐  
  - 어디까지 권한을 위임할지, 어떤 단계에서 사람의 확인을 받게 할지를 신중하게 설계해야 함

# **LLM이 잘하는 것과 못하는 것**

원래 LLM은 이름 그대로 **언어 모델**이었기 때문에, 초창기에는 이미지나 동영상을 분석·생성하는 일을 잘하지 못했습니다. 하지만 최근의 언어 모델은 텍스트뿐만 아니라 이미지, 음성, 동영상 등 다양한 형태의 정보를 함께 다룰 수 있도록 발전했으며, 이렇게 여러 종류의 데이터를 동시에 처리할 수 있는 능력을 **멀티모달(Multimodal)** 이라고 부릅니다. 예를 들어 사진 한 장을 올리고 "이 사진에 적힌 손글씨를 한국어로 옮겨줘"라고 하거나, 짧은 영상을 보여주며 "이 장면에서 무슨 일이 벌어지고 있어?"라고 묻는 일이 이제는 자연스럽게 가능합니다.

이처럼 다재다능해진 LLM이지만, 사람과 마찬가지로 잘하는 일과 잘하지 못하는 일이 명확하게 구분됩니다.

먼저 **LLM이 잘하는 일**의 대표는 **정보 검색**과 **정보 분석**입니다. 어딘가에 흩어져 있는 정보를 모아 한눈에 보기 좋게 정리하고, 긴 문서에서 핵심을 뽑아내며, 여러 자료를 비교해 차이를 짚어주는 일을 매우 잘합니다. "최근 1년 동안 발표된 OO 관련 연구 동향을 요약해줘"라거나 "이 두 계약서의 차이점을 표로 정리해줘" 같은 요청이 여기에 해당합니다.

반대로 **LLM이 잘 못하는 일**도 분명히 있습니다.

첫 번째는 **이미지에서 특징을 정밀하게 검출하는 작업**입니다. 멀티모달 능력 덕분에 이미지를 보고 설명하는 정도는 잘 해내지만, "공장 컨베이어 위에서 흘러가는 제품 중 미세하게 흠집 난 것만 찾아내라"처럼 산업 현장에서 요구되는 수준의 정밀한 시각 검출 작업은 여전히 어려워합니다. 이런 작업에는 정답이 명확히 라벨링된 데이터를 학습시키는 **지도학습 기반의 전용 컴퓨터 비전 모델**을 사용하는 것이 훨씬 효과적이며, LLM과 이런 모델을 함께 조합해 약점을 보완하는 방식이 자주 활용됩니다.

두 번째는 **정보의 특징을 추출해 묶거나 압축하는 작업**입니다. 예를 들어 사용자 취향에 맞춘 맞춤형 광고를 만들기 위해서는, 비슷한 성향의 사용자끼리 그룹으로 묶는 **군집화(Clustering)** 기술과 수많은 속성 중 불필요한 것을 제거하고 핵심만 남기는 **차원 축소(Dimensionality Reduction)** 기술이 필요합니다. LLM은 주어진 정보를 있는 그대로 읽고 해석하는 일은 잘하지만, 이렇게 데이터 전체를 통계적으로 묶거나 차원을 줄이는 작업에는 특화되어 있지 않습니다. 이런 영역은 **비지도 학습 기반의 머신러닝 모델**을 함께 사용함으로써 효과적으로 보완할 수 있습니다.

세 번째는 **진정으로 창의적인 무언가를 새롭게 만들어내는 일**입니다. LLM은 기본적으로 자신이 학습한 데이터를 토대로 가장 그럴듯한 다음 문장을 이어 붙이는 방식으로 동작합니다. 따라서 기존에 없던 완전히 새로운 제품 아이디어, 새로운 사업 모델, 새로운 예술 사조와 같은 **본질적인 창의성**을 발휘하는 데에는 한계가 있습니다. 이 영역은 여전히 **사람의 영역**입니다. 앞으로의 시대에 중요해지는 능력은 단순히 AI를 잘 다루는 것을 넘어, **무엇을 AI에게 시킬지, 그리고 어떤 절차로 그 일을 수행시킬지를 설계하는 능력**입니다.

# **프롬프트 엔지니어링: AI에게 나의 의사를 명확하게 전달하기**

**프롬프트(Prompt)** 란 우리가 AI에게 입력하는 **지시문**을 의미합니다. 가장 단순한 "안녕, 오늘 날씨 어때?"부터, 수십 줄에 걸쳐 작성된 정교한 작업 명세서까지 모두 프롬프트라고 부릅니다. **프롬프트 엔지니어링**은 이 프롬프트를 잘 설계하여 AI로부터 더 좋은 결과물을 끌어내기 위한 기술입니다.

프롬프트 엔지니어링은 LLM 서비스가 처음 출시된 초창기에 활발히 연구된 분야입니다. 모델이 곧장 답을 내놓게 하지 않고 먼저 작업 계획을 세우게 하는 **계획(Planning)** 기법, 모델이 만든 답을 다시 모델 스스로 검토하게 하는 **자기 검증(Self-Verification)** 기법, 사고 과정을 단계별로 풀어 적게 하는 **Chain-of-Thought** 기법 등 다양한 기법이 이때 개발되었습니다. 한때는 "프롬프트 엔지니어"라는 직군이 따로 채용될 정도로 매우 유망한 기술이었습니다.

세 가지 기법이 실제 프롬프트에서 어떻게 표현되는지 예시를 통해 살펴보겠습니다.

**계획(Planning) 기법 예시**: 

모델에게 곧바로 보고서를 쓰지 말고, 먼저 어떤 단계로 보고서를 구성할지를 정리하게 합니다.

```
지금부터 "빛의 색깔이 콩나물의 성장에 미치는 영향"이라는 주제로
중학교 2학년 수준의 과학 탐구 보고서를 작성할 거야.
바로 보고서 본문을 쓰지 말고, 먼저 아래 항목을 정리해서 보여줘.
  1) 보고서에 포함되어야 할 목차(예: 탐구 동기, 가설, 실험 방법, 결과, 결론 등)
  2) 각 목차에서 다뤄야 할 핵심 내용
  3) 실험 방법에서 통제 변인 / 조작 변인 / 종속 변인을 무엇으로 설정할지
  4) 결과를 시각화할 때 어떤 그래프(막대 그래프, 꺾은선 그래프 등)가 가장 적합한지
내가 위 계획을 검토하고 "진행"이라고 답하면, 그때부터 보고서 본문을 작성해줘.
```

**자기 검증(Self-Verification) 기법 예시**: 

앞서 계획한 콩나물 실험을 실제로 수행한 뒤, 측정 데이터를 계산하고 그 결과를 스스로 다시 점검하도록 지시합니다.

```
앞서 계획한 "빛의 색깔이 콩나물의 성장에 미치는 영향" 실험을 일주일 동안 수행하고,
각 조건마다 콩나물 5개씩을 골라 길이(cm)를 측정한 결과는 아래와 같아.

- 빨간 빛   : 6.2, 6.0, 5.8, 6.4, 6.1
- 파란 빛   : 4.5, 4.2, 4.8, 4.4, 4.6
- 초록 빛   : 3.1, 2.9, 3.0, 3.2, 2.8
- 흰  빛    : 7.0, 7.2, 6.8, 7.1, 6.9
- 어두운 곳 : 8.5, 8.7, 8.4, 8.6, 8.8  (대조군)

다음 절차에 따라 각 조건별 "평균 길이(cm)"를 계산하고 결과를 스스로 검증해줘.
1단계: 각 조건에서 5개 측정값의 합을 구한 뒤 5로 나누어 평균을 계산한다.
2단계: 같은 평균을 "(최솟값 + 최댓값) ÷ 2가 평균과 가까운지" 확인하는 방식으로 한 번 더 점검한다.
3단계: 두 방법의 결과가 크게 차이 난다면 어떤 측정값이 이상치(outlier)일 가능성이 있는지 짚는다.
4단계: 최종 평균 길이를 보고서에 넣을 표 형식(조건 / 평균 길이 / 비고)으로 정리한다. 
```

**Chain-of-Thought 기법 예시**:

 앞 단계에서 구한 평균 길이를 바탕으로, 모델이 결론에 이르는 사고 과정을 단계별로 풀어 적게 합니다.

```
앞 단계에서 정리한 콩나물 실험의 평균 길이 결과를 가지고 결론을 도출할 거야.
결론만 말하지 말고, 어떤 사고 과정을 거쳤는지 단계별로 적어줘.

처음 세운 가설: "콩나물은 빛이 강하고 밝을수록(흰 빛에서) 가장 잘 자랄 것이다."

형식:
  Step 1: 평균 길이 데이터에서 관찰할 수 있는 패턴을 정리한다.
          (어느 조건에서 가장 길었고, 어느 조건에서 가장 짧았는지)
  Step 2: "어두운 곳에서 가장 길게 자란" 현상을 과학적으로 어떻게 해석할 수 있는지 설명한다.
          (식물의 굴광성, 웃자람 현상 등 관련 개념을 활용)
  Step 3: 처음 세운 가설이 옳았는지 판단하고, 옳지 않았다면 어떻게 수정해야 하는지 제시한다.
  Step 4: 이 실험으로부터 얻을 수 있는 결론을 한 문장으로 정리한다. 
```

이러한 기법들은 단독으로 사용하기도 하지만, 실제로는 **계획 → 자기 검증 \<-\> 단계별 사고** 순서로 함께 묶어 사용했을 때 가장 큰 효과를 발휘합니다.

최근에는 LLM 모델과 서비스가 이러한 기법들을 **스스로 수행**하는 방향으로 발전하면서, 사용자가 굳이 손수 프롬프트를 정교하게 설계할 필요성은 예전보다 줄어들었습니다. 그러나 이는 프롬프트 엔지니어링이 무의미해졌다는 뜻은 아닙니다. AI가 내가 원하는 결과물을 만들도록 하기 위해 **나의 의사를 명확하게 전달하는 일**은 여전히 매우 중요한 능력이며, 좋은 프롬프트에는 공통적으로 다음 세 가지 **(작업의 목적, 검증 방식, 성공 기준)** 가 포함되어야 합니다.

가장 먼저 **작업의 목적**입니다. AI는 사람의 마음을 읽지 못하기 때문에 "왜 이 일을 시키는지"가 분명할 때 더 좋은 결과를 만들어냅니다. 이때 결과물을 전달할 대상을 명시하는 것이 매우 중요합니다. 예를 들어 단순히 "이 문서를 요약해줘"라고 하기보다는 "이 문서를 처음 보는 신입사원이 30초 만에 핵심을 파악할 수 있도록 요약해줘"라고 목적을 구체적으로 알려주는 식입니다.

다음으로 **검증 방식**입니다. AI가 만든 결과물이 옳은지 어떻게 확인할 것인지를 함께 알려주는 것입니다. 예를 들어 "코드를 작성한 뒤 반드시 테스트를 실행하여 통과 여부를 확인하고, 통과하지 못한 경우 그 원인을 함께 보고해줘"와 같은 방식으로 검증 절차를 미리 명시해 두면, AI는 단순히 결과만 던지지 않고 검증된 결과를 내놓도록 동작합니다.

마지막으로 **성공 기준**입니다. 어떤 상태가 되어야 이 작업이 "끝났다"고 볼 수 있는지를 명확히 정의해 주는 것입니다. "보고서 분량은 A4 한 장 이내, 표는 두 개 이하, 전문 용어는 모두 각주로 풀어 설명"과 같은 식으로 구체적인 합격 조건을 적어주면 AI가 어디까지 작업해야 하는지를 정확히 판단할 수 있습니다.

물론 내가 원하는 결과물에 따라 프롬프트에 담아야 할 내용은 달라지며, 이 부분에 대한 정확한 지식이 없다면 **AI에게 프롬프트 작성을 직접 부탁하는 방법**도 있습니다. 이때 주의할 점은, AI에게 "프롬프트를 만들어줘"라고만 하면 AI는 부족한 정보를 자기 마음대로 채워 넣어버린다는 것입니다. 그렇기 때문에 **반드시 필요한 정보를 사용자에게 먼저 질문하도록 명령**해 주어야 합니다.

**예시 프롬프트:**

```
나는 지금부터 [작업 이름]을 수행하기 위한 프롬프트를 만들고 싶어.

너는 곧바로 프롬프트를 작성하지 말고, 좋은 프롬프트를 만들기 위해
나에게 반드시 알아야 하는 내용을 한 번에 한 가지씩 질문해줘.
내가 답하면 다음 질문으로 넘어가고, 더 이상 물어볼 것이 없다고
판단되면 그때 비로소 완성된 프롬프트를 한 번에 정리해서 보여줘.

질문할 때는 다음 항목을 반드시 포함해야 해.
  1) 이 작업의 최종 목적
  2) 결과물이 사용될 대상(독자, 상황)
  3) 결과물의 형식과 분량
  4) 반드시 지켜야 할 제약 조건
  5) 결과물이 "성공"이라고 판단되는 기준
  6) 결과물을 어떻게 검증할 것인지
```

이렇게 작성하면 AI가 부족한 정보를 임의로 채우는 대신, 내가 미처 생각하지 못한 항목까지 짚어가며 함께 프롬프트를 다듬어 줍니다.

뿐만 아니라 최근에는 다른 사람들이 이미 잘 만들어둔 다양한 **스킬(Skill) 또는 프롬프트 템플릿**이 인터넷과 커뮤니티를 통해 활발히 공유되고 있습니다. 코드 리뷰용 프롬프트, 회의록 정리용 프롬프트, 이메일 작성용 프롬프트처럼 작업 유형별로 잘 다듬어진 것들이 많으므로, 처음부터 혼자 모든 것을 작성하기보다는 이러한 자산을 적극적으로 활용하는 것도 좋은 전략이 됩니다.

# **컨텍스트 엔지니어링: AI가 보는 "화면"을 설계하기**

프롬프트 엔지니어링이 "AI에게 무엇을 시킬지를 잘 말하는 기술"이라면, **컨텍스트 엔지니어링(Context Engineering)** 은 "AI가 그 일을 하기 위해 필요한 정보를 어떻게 적절하게 보여줄지를 설계하는 기술"입니다.

![[Screenshot 2026-06-07 at 7.19.51 pm.png]]

LLM은 한 번에 받아들일 수 있는 정보의 양에 한계가 있습니다. 이 한계를 **컨텍스트 윈도우(Context Window)** 라고 부르며, 모델이 한 번에 "볼 수 있는 화면"이라고 이해하면 쉽습니다. 최근 모델들은 이 윈도우가 매우 커졌지만, 윈도우가 크다고 해서 정보를 무조건 많이 욱여넣는 것이 좋은 것은 아닙니다. 사람도 책상 위에 자료가 너무 많이 쌓이면 오히려 집중력이 떨어지듯, AI 역시 관련 없는 정보가 많으면 정작 중요한 내용을 놓치기 쉽습니다.

컨텍스트 엔지니어링은 다음과 같은 질문에 답을 찾아가는 과정입니다. AI가 지금 이 작업을 잘 수행하려면 **어떤 정보**가, **어느 정도의 양**으로, **어떤 순서와 형식**으로 컨텍스트 윈도우 안에 들어가 있어야 할까요? 예를 들어 사내 문서에 기반해 답변하는 챗봇을 만든다고 해 봅시다. 회사의 모든 문서를 한꺼번에 모델에게 던져주는 것은 불가능하고 비효율적입니다. 대신 사용자의 질문과 가장 관련 있는 문서 일부만 골라 보여주는 **검색 증강 생성(RAG, Retrieval-Augmented Generation)**, 대화가 길어질 때 오래된 내용은 요약해 압축하는 **대화 요약·압축**, 사용자별로 기억해 둘 만한 내용을 별도로 저장해 두는 **메모리 시스템** 등이 모두 컨텍스트 엔지니어링의 구체적인 기법입니다.

요약하자면, 같은 모델·같은 질문이라도 **AI에게 어떤 정보를 어떻게 보여주느냐**에 따라 답변의 품질이 크게 달라집니다. 모델 성능을 한 단계 올리려는 노력보다, 모델에게 보여주는 컨텍스트를 정교하게 다듬는 일이 훨씬 더 큰 차이를 만드는 경우가 많기 때문에 컨텍스트 엔지니어링은 최근 가장 주목받는 분야 중 하나입니다.

# **하네스 엔지니어링: AI를 둘러싼 작업 환경을 설계하기**

마지막으로 살펴볼 개념은 **하네스 엔지니어링(Harness Engineering)** 입니다. "하네스(Harness)"라는 단어는 원래 말의 등에 짐을 싣거나 사람을 안전하게 묶어두는 **장구**를 뜻합니다. AI 분야에서 하네스는 **모델 그 자체를 둘러싸고 있는 실행 환경 전체**, 즉 모델이 사용할 수 있는 **도구(Tools)**, 모델에게 부여된 **권한과 정책**, 모델이 따르는 **시스템 프롬프트**, 모델이 실행되는 **반복 루프와 안전장치**를 모두 포함하는 개념입니다.

![[Screenshot 2026-06-07 at 7.20.18 pm.png]]

같은 모델이라도 어떤 하네스 위에서 동작하느냐에 따라 결과는 완전히 달라집니다. 예를 들어 동일한 Claude 모델을 사용하더라도, 단순한 웹 챗봇 위에서 동작할 때와 **Claude Code**처럼 터미널·파일 시스템·테스트 실행 도구가 모두 연결된 하네스 위에서 동작할 때는 할 수 있는 일의 범위와 깊이가 완전히 다릅니다. 챗봇 위의 모델은 "이 코드를 어떻게 고쳐야 할지 알려줘"라는 조언밖에 줄 수 없지만, 하네스가 잘 갖춰진 환경 위의 모델은 직접 코드를 수정하고, 테스트를 실행하고, 실패하면 원인을 분석해 다시 고치는 일을 **스스로 반복**해서 수행할 수 있습니다.

하네스 엔지니어링은 다음과 같은 질문들에 답을 찾는 작업입니다. 모델에게 **어떤 도구를 쥐여줄 것인지**(파일 읽기·쓰기, 웹 검색, 셸 명령 실행, 데이터베이스 조회 등), 그 도구들 중 **어디까지를 자동으로 허용하고 어디서부터 사람의 승인을 받게 할 것인지**, 작업이 실패하거나 오래 걸릴 때 **어떻게 멈추고 어떻게 다시 시작할 것인지**, 모델의 행동 기록을 **어떻게 남기고 검토할 것인지**와 같은 문제들입니다.

정리하자면, 우리가 AI를 잘 활용하기 위해 신경 써야 할 영역은 크게 세 층으로 나뉩니다. 가장 안쪽에는 **프롬프트 엔지니어링** — 무엇을 시킬지를 명확히 표현하는 기술, 그 바깥에는 **컨텍스트 엔지니어링** — AI에게 보여줄 정보를 잘 고르고 정돈하는 기술, 그리고 가장 바깥에는 **하네스 엔지니어링** — AI가 실제로 일할 수 있는 환경 자체를 설계하는 기술이 있습니다. 이 세 가지를 함께 이해하고 다룰 수 있을 때, 비로소 우리는 AI를 단순한 채팅 상대가 아닌 **유능한 동료**로 활용할 수 있게 됩니다.


