# AI를 배우려는 사람을 위한 용어집

**부제: 코딩을 배우기 전에, 말을 배운다**

강국진 · 2026년 7월

---

## 서문 — 왜 코딩이 아니라 용어집인가

AI를 배우고 싶은 사람에게 흔히 "파이썬부터 배우라"고 한다. 이 조언은 2020년까지는 맞았고, 지금은 절반만 맞다.

나는 파이썬을 쓸 줄 모른다. 그런데 파이썬으로 개발한다. 어떻게 가능한가? **코드를 쓰는 일은 AI가 하고, 나는 무엇을 만들지 결정하고 그것을 말로 지시하기 때문이다.** 그러려면 파이썬 문법은 필요 없지만, "라이브러리를 설치한다", "이건 컴파일이 필요하다", "서버에 배포한다", "API 키를 환경변수에 넣는다" 같은 **컴퓨터 세계의 지형**은 알아야 한다.

용어를 모르면 두 가지가 동시에 막힌다.

1. **지시를 못 한다.** "그거 인터넷에 올려줘"라고 하면 AI는 무엇을 해야 할지 모른다. "정적 사이트로 빌드해서 Cloudflare Pages에 배포해줘"라고 하면 한 번에 끝난다.
2. **AI의 말을 못 알아듣는다.** AI가 "가상환경을 만들고 의존성을 설치한 뒤 로컬에서 띄워보겠습니다"라고 할 때, 이게 위험한 일인지 당연한 일인지 판단할 수 없다면 승인 버튼을 누를 자격이 없다.

즉 용어는 **지시 언어**이자 **감독 언어**다. 디테일(문법, 알고리즘)은 AI에게 위임할 수 있지만, 어휘는 위임할 수 없다. 어휘가 곧 내가 상상할 수 있는 일의 범위이기 때문이다.

**이 용어집의 사용법**
- 통독하지 말고, 필요할 때 찾아보는 사전으로 쓴다.
- 다만 **7부의 "먼저 알아야 할 30개"만은 통째로 외운다.** 그것만으로 대부분의 대화가 통한다.
- 각 항목의 정의는 짧게, "언제 만나는가"를 길게 썼다. 만나는 순간이 이해하는 순간이기 때문이다.
- 예시 중 일부는 내가 직접 만들어 쓰는 시스템(indiebizOS)에서 가져왔다. 홍보가 아니라, 내가 매일 만지는 실물이라 가장 정확하게 말할 수 있기 때문이다.

---

## 1부. 컴퓨터가 일하는 방식

> **왜 아는가**: AI에게 프로그램을 만들라고 시키면, AI는 이 부의 용어로 진행 상황을 보고한다. 여기를 모르면 AI가 무엇을 하고 있는지 전혀 볼 수 없다.

**1. 소스코드 (source code)**
사람이 읽을 수 있게 쓴 프로그램의 원문. 우리가 "코드"라 부르는 텍스트 파일이 이것이다. `.py`, `.js`, `.html` 같은 확장자가 붙는다.

**2. 프로그래밍 언어 (programming language)**
컴퓨터에게 일을 시키는 인공 언어. 파이썬·자바스크립트·C·러스트 등. **핵심은 "어느 언어냐"가 아니라 "언어마다 사는 동네가 다르다"는 사실이다.** 파이썬은 데이터·AI, 자바스크립트는 웹 화면, C·러스트는 성능이 중요한 밑바닥.

**3. 인터프리터 언어 vs 컴파일 언어**
- **인터프리터**(파이썬, 자바스크립트): 코드를 그때그때 한 줄씩 읽으며 실행. 고치면 바로 다시 돌려볼 수 있다. 느리지만 만들기 쉽다.
- **컴파일**(C, 러스트, Go): 실행 전에 기계어로 통째 번역하는 단계를 거친다. 그 번역 작업이 **컴파일**이고, 결과물이 **실행파일**(.exe 등)이다.
초보자가 이걸 알아야 하는 이유: "왜 이건 그냥 실행되는데 저건 빌드해야 하나요?"의 답이 여기 있다.

**4. 빌드 (build)**
소스코드를 실제로 돌아가는 형태로 만드는 과정 전체. 컴파일보다 넓은 말이다. 웹사이트도 "빌드"한다(여러 파일을 압축·정리해 배포용 덩어리로 만든다).

**5. 실행 / 런타임 (run / runtime)**
- **실행**: 프로그램을 돌리는 것.
- **런타임**: 그 프로그램이 돌기 위해 컴퓨터에 미리 깔려 있어야 하는 기반. 파이썬 코드는 **Python 3.12** 같은 런타임이, 자바스크립트 코드는 **Node.js**가 있어야 돈다.
"내 컴퓨터에선 되는데 저기선 안 돼요"의 원인 1순위가 런타임 버전 차이다.

**6. 라이브러리 / 패키지 / 모듈 (library / package / module)**
남이 미리 만들어 둔 코드 뭉치. 직접 안 짜고 가져다 쓴다. 사실상 같은 말로 섞여 쓰이지만 결이 다르다.
- **모듈**: 파일 하나 단위의 코드 묶음
- **패키지**: 설치·배포 단위로 포장된 것
- **라이브러리**: 기능 단위로 부르는 이름
**AI 시대에 이게 특히 중요한 이유**: AI가 만든 코드가 안 돌아가는 이유의 태반은 로직이 틀려서가 아니라 **필요한 라이브러리가 안 깔려서**다.

**7. 프레임워크 (framework)**
라이브러리보다 큰 것. 라이브러리는 내가 불러다 쓰지만, 프레임워크는 그 안에 내 코드를 넣는다. (주도권이 반대다.) 예: React, Next.js, FastAPI, Django.

**8. 패키지 매니저 (package manager)**
라이브러리를 검색·설치·삭제해주는 도구. 언어마다 다르다.
- 파이썬 → `pip` (또는 `uv`, `conda`)
- 자바스크립트 → `npm` (또는 `pnpm`, `yarn`)
- macOS 프로그램 → `brew`
`pip install pandas` 같은 명령을 보면 "파이썬 라이브러리 pandas를 설치 중"이라 읽으면 된다.

**9. 의존성 (dependency)**
내 프로그램이 돌기 위해 필요한 다른 라이브러리들. 그 라이브러리가 또 다른 걸 필요로 하므로 나무처럼 뻗는다. 목록 파일이 `requirements.txt`(파이썬), `package.json`(JS).

**10. 의존성 지옥 / 버전 충돌 (dependency hell)**
A는 라이브러리 v1을 원하는데 B는 v2를 원하는 상황. AI가 "버전 충돌이 있어 다운그레이드하겠습니다"라고 하면 이 상황이다.

**11. 가상환경 (virtual environment)**
프로젝트마다 라이브러리 창고를 따로 두는 격리 공간. 파이썬은 `venv`/`conda`, 자바스크립트는 `node_modules` 폴더가 그 역할. **버전 충돌을 예방하는 기본 위생이다.**

**12. 터미널 / 셸 / 커맨드라인 (terminal / shell / CLI)**
검은 화면에 명령어를 쳐서 컴퓨터를 부리는 방식. GUI(마우스로 클릭하는 방식)의 반대. AI 에이전트 대부분은 여기서 산다. **"AI에게 컴퓨터를 준다"는 말의 실질은 대개 "터미널을 준다"는 뜻이다.**

**13. 명령어 (command)**
터미널에 치는 한 줄. `ls`(목록), `cd`(폴더 이동), `mkdir`(폴더 생성), `git clone`(코드 내려받기) 등. 외울 필요는 없다 — AI가 쓴다. 다만 **읽을 줄은 알아야 한다.** 특히 `rm -rf`(강제 삭제)는 눈에 익혀 두는 게 좋다.

**14. 경로 (path)**
파일의 주소. `/Users/이름/Desktop/파일.txt`처럼 뿌리부터 쓰면 **절대경로**, `./파일.txt`처럼 지금 위치 기준이면 **상대경로**. `~`는 홈 디렉토리. **AI에게 파일을 다루게 할 땐 항상 절대경로로 말하는 게 안전하다.**

**15. 환경변수 (environment variable)**
프로그램 밖에 따로 보관하는 설정값. 특히 **API 키**를 여기 넣는다. `.env` 파일이 흔한 보관처다.

**16. API 키 / 토큰 / 시크릿 (API key / secret)**
외부 서비스를 쓸 자격을 증명하는 비밀 문자열. **돈과 직결된다.** 절대 지켜야 할 규칙 하나: **API 키를 코드에 직접 쓰지 않는다. GitHub에 올리지 않는다.** (자동 수집 봇이 몇 분 안에 훔쳐 간다.)

**17. 로그 (log)**
프로그램이 남기는 진행 기록. 문제가 생기면 여기부터 본다.

**18. 에러 / 예외 / 스택트레이스 (error / exception / stack trace)**
프로그램이 멈추며 뱉는 오류 메시지. 스택트레이스는 "어디서부터 어디까지 거쳐 터졌는지"의 경로다. **초보자의 가장 강력한 무기: 에러 메시지를 통째로 복사해 AI에게 붙여 넣는 것.** 요약하지 말고 그대로 붙여야 한다.

**19. 디버깅 (debugging)**
오류의 원인을 찾아 고치는 일.

**20. 데이터 형식 — JSON / YAML / CSV / Markdown**
- **JSON**: 프로그램끼리 데이터를 주고받는 표준 형식. `{"이름": "값"}` 모양. AI API의 입출력이 대부분 이것.
- **YAML**: 사람이 읽기 편하게 만든 설정 파일 형식. 들여쓰기로 구조를 표현.
- **CSV**: 쉼표로 나눈 표. 엑셀과 호환.
- **Markdown(.md)**: `#`으로 제목, `**`로 굵게 쓰는 간단한 문서 형식. **AI와 사람이 공유하는 사실상의 표준 문서 언어다.**

**21. 인코딩 / UTF-8**
글자를 숫자로 저장하는 규칙. 한글이 `???`나 `ìëì`로 깨져 보이면 인코딩 문제다. UTF-8이 현대 표준, 옛 한글 파일은 CP949(EUC-KR)인 경우가 많다.

**22. 정규식 (regex)**
문자열의 패턴을 기술하는 작은 언어. `\d{3}-\d{4}` 같은 암호처럼 보이는 것. 직접 쓸 일은 없지만 **AI에게 "정규식으로 찾아줘"라고 말할 줄 알면 검색 능력이 확 는다.**

---

## 2부. 코드가 사는 곳 — 깃과 저장소

> **왜 아는가**: AI가 만든 코드를 안전하게 쌓고 되돌리는 유일한 방법이다. AI에게 마음껏 고치라고 시킬 수 있는 배짱은 "언제든 되돌릴 수 있다"는 확신에서 나온다.

**23. 버전 관리 (version control)**
파일의 변경 이력을 시간순으로 저장해 언제든 과거로 되돌릴 수 있게 하는 체계.

**24. Git (깃)**
그 버전 관리를 하는 프로그램. 세계 표준. **AI 시대의 안전벨트다.** AI가 코드를 망쳐도 `git checkout`으로 1초 만에 원상복구된다.

**25. 저장소 / 리포지토리 (repository, repo)**
Git으로 관리되는 프로젝트 폴더 하나.

**26. 커밋 (commit)**
"여기까지의 상태를 하나의 저장 지점으로 찍는다"는 행위. 게임의 세이브 포인트. 각 커밋에는 메시지가 붙는다.

**27. 브랜치 / 머지 (branch / merge)**
- **브랜치**: 본줄기(main)에서 갈라져 나온 작업 가지. 실험을 본체와 격리한다.
- **머지**: 그 가지를 본줄기에 합치는 것.
**AI에게 큰 작업을 시킬 땐 새 브랜치에서 시키는 게 정석이다.**

**28. GitHub (깃허브)**
Git 저장소를 인터넷에 올려두는 서비스. 세계 최대의 소스코드 창고이자 개발자 SNS. Microsoft 소유. 유사 서비스로 GitLab, Bitbucket.
**초보자가 GitHub을 알아야 하는 실질적 이유**: 세상의 거의 모든 AI 도구·라이브러리가 여기 있고, 설치 안내도 여기 있다.

**29. 클론 / 풀 / 푸시 (clone / pull / push)**
- **클론**: 남의 저장소를 내 컴퓨터로 통째 복사해 오기
- **풀**: 원격의 최신 변경을 내 것에 당겨오기
- **푸시**: 내 변경을 원격에 밀어 올리기

**30. 풀 리퀘스트 (Pull Request, PR)**
"내가 이렇게 고쳤는데 본체에 반영해 주시겠습니까"라는 공식 제안. 오픈소스 협업의 기본 단위이자, 요즘은 **AI 에이전트가 작업 결과를 사람에게 제출하는 창구**이기도 하다.

**31. 이슈 (issue)**
버그 신고나 기능 제안을 적어 두는 게시판.

**32. README**
저장소 첫 화면에 보이는 설명서. **낯선 도구를 만나면 무조건 여기부터 읽는다.**

**33. 오픈소스 (open source)**
소스코드가 공개되어 누구나 보고 고칠 수 있는 소프트웨어.

**34. 라이선스 (license)**
그 코드를 어디까지 써도 되는지 정한 법적 조건. **MIT**(거의 자유), **Apache 2.0**(자유+특허 조항), **GPL**(내 것도 공개해야 함), **비상업용 제한** 등. 상업적으로 쓸 계획이라면 반드시 확인해야 한다.

**35. 오픈웨이트 (open weight)**
AI 모델 세계의 "오픈소스 비슷한 것". 모델의 **가중치 파일은 공개**하지만 학습 데이터나 과정은 비공개인 경우가 많아, 엄밀한 오픈소스와는 구별해서 부른다.

---

## 3부. 프로그램이 도는 곳 — 서버·호스팅·클라우드

> **왜 아는가**: "만든 것을 남이 쓰게 하는 일"의 전부가 이 부에 있다. 그리고 AI 서비스 요금이 왜 나오는지도 여기서 이해된다.

**36. 로컬 vs 원격/클라우드 (local vs remote/cloud)**
- **로컬**: 내 컴퓨터 안. 공짜, 빠름, 나만 씀, 내 컴퓨터가 꺼지면 끝.
- **클라우드**: 남의 컴퓨터(데이터센터). 돈이 들고, 24시간 돌고, 누구나 접속 가능.

**37. 클라이언트 / 서버 (client / server)**
- **서버**: 요청을 기다렸다가 답을 주는 쪽 (식당 주방)
- **클라이언트**: 요청을 보내는 쪽 (손님). 브라우저, 앱, 그리고 **AI 에이전트도 클라이언트다.**

**38. 요청 / 응답 (request / response)**
클라이언트가 보내고 서버가 돌려주는 한 쌍. 인터넷의 모든 일이 이 왕복으로 되어 있다.

**39. HTTP / HTTPS**
그 왕복의 규칙(프로토콜). HTTPS는 암호화된 버전. **GET**(가져와), **POST**(보낸다) 같은 동사가 붙는다.

**40. 상태 코드 (status code)**
서버의 답변 번호. **200**=성공, **404**=그런 거 없음, **401/403**=권한 없음, **429**=너무 많이 요청함(요금제 한도), **500**=서버가 터짐. **AI를 쓰다 429를 보면 "쿼터 초과, 잠시 기다려야 한다"는 뜻이다.**

**41. API (Application Programming Interface)**
프로그램끼리 대화하는 창구. 사람용 화면(UI)의 대응물. **"AI를 API로 쓴다"** = 채팅창이 아니라 내 프로그램 안에서 AI를 부른다는 뜻.

**42. SDK (Software Development Kit)**
그 API를 쉽게 부를 수 있게 포장한 라이브러리. API가 콘센트라면 SDK는 어댑터.

**43. 엔드포인트 (endpoint)**
API의 개별 주소. `https://api.example.com/v1/messages` 같은 것.

**44. REST / JSON API**
가장 흔한 API 설계 방식. 주소 + 동사(GET/POST) + JSON 데이터의 조합.

**45. 웹훅 (webhook)**
API의 반대 방향. 내가 물어보는 게 아니라, **사건이 생기면 상대가 나에게 먼저 알려주는** 구조. 자동화의 핵심 부품.

**46. 프론트엔드 / 백엔드 (frontend / backend)**
- **프론트엔드**: 사용자가 보는 화면 (HTML/CSS/JavaScript, React)
- **백엔드**: 뒤에서 데이터를 처리하는 부분 (Python/FastAPI, Node.js)

**47. 데이터베이스 (DB)**
데이터를 구조적으로 저장·검색하는 시스템. **SQLite**(파일 하나로 되는 가벼운 DB — 개인용 도구에 압도적으로 흔하다), **PostgreSQL/MySQL**(본격 서버형), **SQL**(그것들에게 묻는 질의 언어).

**48. 호스팅 (hosting)**
내 프로그램을 남의 서버에 올려 24시간 돌게 하는 서비스.

**49. 배포 (deploy)**
만든 것을 실제 서비스 환경에 올리는 행위. `git push` 한 번에 자동 배포되게 만드는 게 요즘 방식이다.

**50. 도메인 / DNS (domain / DNS)**
- **도메인**: `example.com` 같은 사람이 읽는 주소. 매년 돈 내고 빌린다.
- **DNS**: 그 이름을 실제 서버 번호(IP)로 바꿔주는 전화번호부.

**51. IP 주소 / 포트 / localhost**
- **IP**: 컴퓨터의 번호 주소
- **포트**: 그 컴퓨터 안의 문 번호. `:8000`, `:3000` 같은 것
- **localhost / 127.0.0.1**: "이 컴퓨터 자신". **`http://localhost:3000`은 "내 컴퓨터에서 지금 돌고 있는 프로그램"이라는 뜻이다.** AI가 만든 걸 처음 확인하는 자리가 늘 여기다.

**52. 정적 사이트 vs 동적 사이트 (static vs dynamic)**
- **정적**: 미리 만들어 둔 HTML을 그냥 보여줌. 싸고 빠르고 안 터진다.
- **동적**: 접속할 때마다 서버가 내용을 만들어 냄. 로그인·게시판이 필요하면 이쪽.
**개인이 만드는 것 대부분은 정적으로 충분하고, 정적이면 사실상 무료다.**

**53. 서버리스 (serverless)**
서버를 빌려 두지 않고, 요청이 올 때만 코드가 잠깐 깨어나 실행되는 방식. 안 쓰면 0원. Cloudflare Workers, AWS Lambda, Vercel Functions.

**54. 엣지 (edge)**
사용자와 가까운 전 세계 각지의 서버에서 실행하는 방식. 빠르다.

**55. 컨테이너 / 도커 (container / Docker)**
프로그램과 그 실행 환경을 통째로 포장해 어디서든 똑같이 돌게 만드는 기술. "내 컴퓨터에선 됐는데" 문제의 근본 해결책.

**56. CDN (Content Delivery Network)**
이미지·파일을 전 세계에 복제해 두고 가까운 곳에서 내려주는 망.

**57. 터널 (tunnel)**
내 컴퓨터를 인터넷에 잠깐 노출시키는 통로. 공인 IP 없이도 집 컴퓨터를 외부에서 접속 가능하게 만든다. **Cloudflare Tunnel**, ngrok. *(나는 집 컴퓨터를 외부 브라우저에 여는 데 정확히 이걸 쓴다.)*

**58. 캐시 (cache)**
한 번 가져온 걸 임시로 저장해 두고 재사용하는 것. "고쳤는데 화면이 그대로예요"의 범인 1순위.

**59. 회사 이름 지도 — 무엇을 파는 회사인가**

| 이름 | 파는 것 | 초보자 관점 한 줄 |
|---|---|---|
| **Vercel** | 웹사이트 호스팅·배포 | Next.js 만든 회사. 프론트 배포의 기본값 |
| **Cloudflare** | CDN·보안·서버리스·터널·저장소 | 인터넷의 인프라 잡화점. 무료 티어가 관대함 |
| **Netlify** | 정적 사이트 호스팅 | Vercel의 경쟁자 |
| **AWS / Azure / GCP** | 클라우드 전부 | 대기업용. 개인이 첫날 만질 필요 없음 |
| **Supabase / Firebase** | 데이터베이스+로그인+저장소 묶음 | 백엔드를 안 짜고 앱 만들 때 |
| **Railway / Render / Fly.io** | 백엔드 앱 호스팅 | 파이썬 서버 하나 띄우고 싶을 때 |
| **Hugging Face** | AI 모델·데이터셋 창고 | AI 세계의 GitHub |
| **OpenAI / Anthropic / Google** | AI 모델 API | 지능 자체를 파는 회사 |
| **Ollama / LM Studio** | 내 컴퓨터에서 모델 돌리기 | 공짜·비공개, 대신 성능은 낮음 |

> **초보자용 결론**: 이 회사 이름들은 외울 대상이 아니라 **"이런 종류의 서비스가 존재한다"는 목록**으로 알아 두면 된다. 필요한 순간 AI에게 "이건 어디에 올리는 게 맞아?"라고 물으면 된다. 물을 수 있으려면 존재를 알아야 한다.

---

## 4부. AI 모델 자체의 어휘

> **왜 아는가**: 성능이 안 나올 때 "모델이 나쁜 건지, 내가 잘못 시킨 건지, 정보를 안 준 건지"를 가르는 언어다. 이 구분을 못 하면 영원히 프롬프트만 만지작거리게 된다.

**60. AI / 머신러닝 / 딥러닝**
포함 관계다. AI ⊃ 머신러닝(데이터로 규칙을 스스로 찾는 것) ⊃ 딥러닝(신경망을 깊게 쌓은 것).

**61. 신경망 / 파라미터 / 가중치 (neural network / parameter / weight)**
모델의 내부는 거대한 숫자 표다. 그 숫자 하나하나가 **파라미터(가중치)**이고, 개수가 모델 크기(7B=70억 개)다. **학습 = 이 숫자들을 조정하는 일.**

**62. LLM (Large Language Model, 거대언어모델)**
방대한 텍스트로 학습해 "다음에 올 말"을 예측하는 모델. GPT, Claude, Gemini, Llama가 모두 이것. **AI 시대 대부분 용어의 중심.**

**63. 트랜스포머 (Transformer)**
현대 LLM이 공통으로 쓰는 신경망 구조. 2017년 논문에서 나왔다. 이름만 알면 된다.

**64. 토큰 (token)**
모델이 글을 다루는 최소 단위. 단어보다 작고 글자보다 크다. 영어는 대략 4글자=1토큰, **한국어는 글자당 1~2토큰으로 훨씬 비싸다.** 요금과 길이 제한이 전부 토큰으로 계산된다.

**65. 컨텍스트 윈도우 (context window)**
모델이 한 번에 볼 수 있는 총 분량(입력+출력). "20만 토큰"처럼 표시된다. 이걸 넘으면 오류가 나거나, 도구가 오래된 내용을 잘라내고 요약해서 넣는다.
**주의할 것**: 긴 대화에서 AI가 앞의 지시를 잊는 현상은 창을 넘어서만 생기는 게 아니다. **창 안에 있어도 맥락이 길어지면 주의가 흐려진다.** 그래서 "대화가 길어지면 새 창을 연다"는 창 크기와 무관하게 유효한 습관이다.

**66. 컨텍스트 (context)**
그 순간 모델에게 실제로 주어진 정보 전부 — 시스템 프롬프트 + 대화 이력 + 붙여넣은 문서 + 도구 결과. **모델의 능력보다 컨텍스트의 질이 결과를 좌우하는 일이 훨씬 많다.**

**67. 프롬프트 (prompt)**
모델에게 주는 입력·지시문.

**68. 시스템 프롬프트 (system prompt)**
대화 전체에 걸리는 역할·규칙 설정. "너는 강의 보조다" 같은 것. 사용자 메시지보다 우선한다.

**69. 프롬프트 엔지니어링 (prompt engineering)**
지시문을 잘 쓰는 기술. **2023년의 왕좌였고, 지금은 필요조건이지 충분조건이 아니다.** (→ 5부 컨텍스트/하네스 엔지니어링)

**70. 온도 (temperature)**
답변의 무작위성 조절값. 0에 가까우면 딱딱하고 일관되게, 높으면 창의적이고 산만하게. 사실 확인용은 낮게, 아이디어 발상은 높게.

**71. 추론 모델 / 사고 (reasoning model / thinking)**
답하기 전에 속으로 길게 생각하는 모델. 생각의 양을 조절하는 값(reasoning effort, thinking budget)이 있다. **어려운 문제엔 크게, 단순 작업엔 작게** — 생각도 토큰이라 돈이다.

**72. 멀티모달 (multimodal)**
글뿐 아니라 이미지·음성·영상까지 함께 다루는 능력. "스크린샷을 붙여 넣고 물어보는" 것이 실전에서 가장 강력한 사용법 중 하나다.

**73. 사전학습 / 파인튜닝 (pre-training / fine-tuning)**
- **사전학습**: 대량 데이터로 기본 능력을 만드는 단계 (수백억 원 규모, 대기업만 함)
- **파인튜닝**: 그 위에 내 데이터로 덧칠해 특정 용도에 맞추는 것 (개인도 가능)

**74. 증류 (distillation)**
큰 모델의 능력을 작은 모델에 옮겨 담는 기법. 값싼 모델이 갑자기 똑똑해지는 이유.

**75. 양자화 (quantization)**
모델의 숫자 정밀도를 낮춰 용량과 메모리를 줄이는 것. 노트북에서 모델을 돌릴 수 있게 해주는 기술.

**76. GPU / VRAM**
- **GPU**: 모델의 거대한 숫자 계산을 병렬로 해치우는 칩. AI 학습·실행의 실질적 엔진이고, "AI 인프라 전쟁"의 대상이 바로 이것이다.
- **VRAM**: GPU에 붙은 전용 메모리. **로컬에서 모델을 돌리려면 모델 전체가 VRAM에 올라가야 한다.** "왜 내 노트북에서 7B는 되고 70B는 안 되나요?"의 답이 여기 있다 — 자리가 모자라서다. 양자화(75번)가 이 자리를 줄여주는 기술이고, 애플 실리콘 맥은 일반 메모리를 GPU와 공유해서 메모리 큰 맥이 로컬 모델에 의외로 유리하다.

**77. 임베딩 (embedding)**
글이나 이미지를 의미를 담은 숫자 배열(벡터)로 바꾼 것. **의미가 비슷하면 숫자도 가깝다.** 이게 "의미로 검색하는" 모든 기능의 밑바탕.

**78. 벡터 데이터베이스 (vector DB)**
그 임베딩을 저장하고 "가장 가까운 것"을 빠르게 찾아주는 저장소.

**79. 시맨틱 검색 (semantic search)**
키워드가 아니라 의미로 찾는 검색. "강아지 밥"으로 검색해도 "반려견 사료" 문서가 잡힌다.

**80. RAG (Retrieval-Augmented Generation, 검색 증강 생성)**
질문이 들어오면 **먼저 내 문서에서 관련 부분을 찾아 컨텍스트에 넣고, 그다음 모델이 답하게** 하는 방식. 모델을 재학습시키지 않고 최신·사내 지식을 쓰게 만드는 가장 현실적인 방법.
> **초보자가 가장 자주 오해하는 지점**: "내 자료를 AI에게 학습시키고 싶다"의 90%는 파인튜닝이 아니라 RAG로 해결된다. 훨씬 싸고 빠르고 수정도 쉽다.

**81. 그라운딩 (grounding)**
답변을 실제 출처에 붙들어 매는 것. 근거 링크가 붙는 답이 그라운딩된 답이다.

**82. 환각 (hallucination)**
모델이 그럴듯한 거짓을 자신 있게 지어내는 현상. **없애는 게 아니라 관리하는 대상이다.** 관리법: 출처 요구, 도구로 실제 확인, 교차 검증.

**83. 벤치마크 (benchmark)**
모델 성능을 재는 표준 시험. 코딩·수학·에이전트 능력별로 따로 있다. 참고는 하되, **내 실제 작업에서의 성능과는 자주 어긋난다.**

**84. 모델 티어 / 라우팅 (model tier / routing)**
같은 회사가 크기별로 모델을 여러 개 낸다(대형·중형·소형). **쉬운 일은 싼 모델, 어려운 일은 비싼 모델로 자동 배분하는 것이 실전 비용 관리의 핵심.** *(나는 내 시스템에서 이걸 자동차 변속기처럼 만들어 "모델 기어"라 부른다.)*

**85. 토큰 요금 / 캐싱 (pricing / prompt caching)**
API 요금은 **입력 토큰**과 **출력 토큰**을 따로 계산하고, 출력이 훨씬 비싸다. 같은 앞부분을 반복해 보낼 땐 **프롬프트 캐싱**으로 크게 할인받는다. 비용이 예상보다 폭증하면 대개 "긴 문서를 매번 다시 보내고 있어서"다.

**86. 레이트 리밋 / 쿼터 (rate limit / quota)**
분당·일당 사용 상한. 초과하면 429 오류.

**87. 로컬 모델 vs API 모델**
- **로컬**: 내 컴퓨터에서 실행. 무료·완전 비공개, 대신 성능 제한. Ollama, LM Studio.
- **API**: 회사 서버의 최고 성능 모델. 돈이 들고 데이터가 밖으로 나간다.
**민감 정보를 다루면 로컬, 성능이 필요하면 API** — 이 판단이 실무의 첫 갈림길이다.

---

## 5부. AI가 일하는 법 — 에이전트와 하네스 ★

> **왜 아는가**: **이 부가 이 용어집의 심장이다.** 2023년의 AI는 "대답하는 것"이었고, 지금의 AI는 "일하는 것"이다. 일하는 AI를 이해하는 어휘가 여기 있다.

**88. 챗봇 vs 에이전트 (chatbot vs agent)**
- **챗봇**: 묻고 답한다. 행동은 사람이 한다.
- **에이전트**: 목표를 받고 **스스로 여러 단계를 거쳐 실제로 행동한다.** 검색하고, 파일을 고치고, 명령을 실행하고, 결과를 보고 다시 판단한다.

**89. 도구 사용 / 함수 호출 (tool use / function calling)**
모델이 글 대신 "이 도구를 이런 값으로 불러 달라"는 구조화된 요청을 내보내는 능력. **에이전트의 근본 메커니즘이 이것 하나다.** 모델 자체는 아무것도 못 하고, 도구가 손발이다.

**90. 에이전트 루프 (agent loop)**
생각 → 도구 호출 → 결과 관찰 → 다시 생각. 목표를 이룰 때까지 반복하는 순환. 사람 없이 여러 바퀴 도는 것이 에이전트의 정의다.

**91. MCP (Model Context Protocol)**
AI와 외부 도구·데이터를 연결하는 **표준 규격**. Anthropic이 공개했고 2026년 현재 사실상의 업계 표준으로 자리 잡았다(Claude Code, Cursor 등 주요 도구가 모두 MCP 클라이언트다).
비유하자면 **AI 세계의 USB-C**. 예전엔 도구마다 전용 연결을 짜야 했지만, 이제 MCP 서버 하나를 만들면 어느 AI든 꽂아 쓴다.
- **MCP 서버**: 능력을 제공하는 쪽 (내 파일, 내 DB, 내 회사 시스템)
- **MCP 클라이언트**: 그걸 꽂아 쓰는 AI 쪽

**92. 하네스 (harness)** ★
**모델에게 몸을 주는 껍데기 전체.** 모델(지능)만으로는 아무 일도 못 한다. 도구·기억·권한·규칙·실행 순서를 갖춰 실제로 일하게 만드는 장치 일체가 하네스다.
> 같은 모델이라도 하네스가 다르면 결과가 완전히 달라진다. 2026년 현재 성능 차이의 상당 부분은 모델이 아니라 **하네스 차이**에서 나온다.
> 원래 하네스는 말에게 씌우는 마구(馬具)를 뜻한다. 말의 힘을 죽이지 않으면서 방향을 주는 물건 — 정확히 그 역할이다.

**93. 하네스 엔지니어링 / 컨텍스트 엔지니어링**
- **프롬프트 엔지니어링**: 무엇을 말할까 (문장 단위)
- **컨텍스트 엔지니어링**: 무엇을 보여줄까 (그 순간 모델의 시야에 무엇을 넣고 뺄까)
- **하네스 엔지니어링**: 어떤 몸을 줄까 (도구·기억·권한·루프 구조 설계)
셋 중 앞의 둘은 이미 굳은 말이고, 셋째는 자리 잡아가는 중이다 — 이 글에서는 이 층위를 하네스 엔지니어링이라 부르겠다. **초보자가 잡아야 할 발전 경로가 정확히 이 순서다.**

**94. 컨텍스트 오염 / 컨텍스트 관리**
대화가 길어지면 쓸데없는 정보가 시야를 채워 판단이 나빠진다. 요약·압축·초기화가 대응책. "대화가 길어지면 새 창을 여는" 습관에는 이런 근거가 있다.

**95. 서브에이전트 / 멀티에이전트 (subagent / multi-agent)**
큰 일을 쪼개 여러 AI에게 나눠 맡기는 방식. 각자 깨끗한 시야에서 자기 일만 하고 결과만 보고한다. **컨텍스트 한계를 우회하는 가장 실용적인 방법.**

**96. 오케스트레이션 (orchestration)**
그 여러 에이전트·단계의 진행 순서를 지휘하는 일.

**97. 워크플로우 vs 에이전트**
- **워크플로우**: 순서가 사람에 의해 미리 정해져 있다. 예측 가능, 저렴, 유연성 낮음.
- **에이전트**: 순서를 AI가 정한다. 유연, 비쌈, 예측 어려움.
> **실무 원칙**: 할 수 있으면 워크플로우로 하고, 안 되는 것만 에이전트로 한다. 이 판단이 비용과 안정성을 가른다.

**98. 메모리 (memory)**
대화가 끝나도 남는 기억. 종류를 나눠 부른다.
- **단기**: 지금 대화의 이력
- **장기**: 사용자 취향·과거 결정 등을 저장해 두고 필요할 때 꺼냄
- **작업 기억**: 지금 일을 위한 임시 메모(할 일 목록, 중간 파일)
*(나는 내 시스템에서 이걸 7종으로 쪼개 놓았다 — 과거 실행 사례를 기억하는 "해마", 탐색 요령을 축적하는 "포식 기억" 등.)*

**99. 커스텀 인스트럭션 파일 (CLAUDE.md / AGENTS.md / .cursorrules)**
프로젝트 폴더에 두면 AI가 매번 읽는 규칙 파일. **"이 프로젝트에서는 이렇게 일해라"를 문서로 못 박는 것.** 사실상 하네스 설정의 첫걸음이며, 2026년에는 사실상 표준 관행이 되었다.

**100. 스킬 / 슬래시 커맨드 (skill / slash command)**
자주 쓰는 절차를 이름 붙여 저장해 둔 것. `/배포`, `/리뷰`처럼 부르면 정해진 매뉴얼대로 일한다. **반복되는 일을 어휘로 결정화하는 장치.**

**101. 권한 / 승인 / 샌드박스 (permission / approval / sandbox)**
AI가 실제로 파일을 지우고 명령을 실행할 수 있으니, **무엇까지 허용할지**를 정하는 장치. 매번 물어보게 하거나, 안전한 것만 자동 허용하거나, 격리된 공간(샌드박스)에서만 놀게 한다.

**102. 휴먼 인 더 루프 (human in the loop)**
중요한 지점에서 사람의 확인을 받는 설계. **자율성을 높일수록 속도는 오르고 사고 위험도 오른다.** 어디에 사람을 세울지가 설계의 핵심 결정이다.

**103. 트리거 / 스케줄러 / 크론 (trigger / scheduler / cron)**
- **트리거**: 어떤 사건이 나면 자동 실행 (메일이 오면, 파일이 바뀌면)
- **스케줄러·크론**: 정해진 시각에 자동 실행 (매일 아침 7시)
**"내가 부를 때만 일하는 AI"에서 "알아서 돌아가는 AI"로 넘어가는 문턱이다.**

**104. 관측성 / 트레이싱 (observability / tracing)**
에이전트가 무엇을 왜 했는지 기록하고 되짚어 보는 것. 여러 단계를 도는 AI는 이게 없으면 디버깅이 불가능하다.

**105. 평가 (eval)**
AI 결과물이 기준을 만족했는지 채점하는 절차. **"잘 되는 것 같다"와 "측정했다"는 다르다.** 자동 채점을 붙이는 순간 개선이 공학이 된다.

**106. 프롬프트 인젝션 (prompt injection)**
웹페이지나 문서에 숨겨 둔 악의적 문장이 AI에게 명령으로 먹혀 버리는 공격. **AI에게 인터넷과 파일 권한을 줄 때 반드시 알아야 할 위험.** 대응은 권한 최소화와 사람 승인.

---

## 6부. 하네스 지도 — 실물들

> **왜 아는가**: 위의 개념들이 실제 제품에서 어떤 이름으로 나타나는지 대조해 두면, 새 도구를 만나도 30분이면 파악된다.

### 6-1. 성격별 분류

| 유형 | 대표 | 성격 | 어떤 사람에게 |
|---|---|---|---|
| **CLI 에이전트** | Claude Code, Codex CLI, OpenCode | 터미널에서 사는 자율 작업자. 파일·명령·git을 직접 만짐 | 컴퓨터를 통째로 맡기고 싶은 사람 |
| **IDE 통합형** | Cursor, GitHub Copilot | 코드 편집기 안에서 함께 작업 | 코드를 눈으로 보며 통제하고 싶은 사람 |
| **비주얼 워크플로우** | n8n, Zapier, Make, Langflow | 블록을 선으로 이어 자동화를 그림 | 코드를 안 쓰고 자동화하고 싶은 사람 |
| **LLM 앱 플랫폼** | Dify, Coze | RAG·프롬프트·배포를 묶은 제품 | 사내 챗봇·지식봇을 만들 사람 |
| **코드 프레임워크** | LangChain/LangGraph, CrewAI, OpenAI Agents SDK | 직접 코드로 에이전트를 짜는 부품 상자 | 개발자 |
| **개인용 통합 하네스** | indiebizOS (내가 만든 것) | 개인의 삶 전체(파일·일정·메시지·기기)를 한 어휘로 다룸 | 자기 시스템을 짓고 싶은 사람 |

*(2026년 시점의 지형이며, 이 바닥은 분기 단위로 바뀐다. 제품 이름보다 **유형**을 기억하는 게 오래 간다.)*

### 6-2. 같은 개념, 다른 이름 — 대조표로 읽는 법

하네스마다 부르는 말이 다를 뿐 뼈대는 같다. 이 대조표가 **하나를 배우면 나머지가 따라오게 만드는 열쇠**다. 셋째 열은 내 시스템을 예로 든 것인데, 남의 제품이 아니라 내가 만든 것이라 각 칸이 왜 그 자리에 있는지까지 말할 수 있어 골랐다. 독자는 자기가 쓰는 도구를 넷째 열로 세워 보면 된다.

| 보편 개념 | Claude Code 계열 | n8n 계열 | indiebizOS (예시) |
|---|---|---|---|
| 도구 | Tool / MCP 서버 | 노드(Node) | IBL 액션 (`[sense:weather]`) |
| 도구 목록 | 툴 스키마 | 노드 팔레트 | 6개 노드 어휘(sense/self/limbs/others/engines/table) |
| 규칙 파일 | CLAUDE.md / AGENTS.md | — | 프로젝트 에이전트 설정 |
| 절차 결정화 | 스킬 / 슬래시 커맨드 | 워크플로우 | 가이드 + 워크플로우 |
| 여러 단계 지휘 | 서브에이전트 | 캔버스 배선 | 의식→실행→평가 인지 파이프라인 |
| 장기 기억 | 메모리 파일 | DB 노드 | 해마·심층메모리·포식기억 |
| 자동 실행 | 훅 / 크론 | 트리거 노드 | 트리거·스케줄러·스위치 |
| 자율성 조절 | 권한 모드 | — | 3표면(자율주행 / 조종실 / 앱) |
| 비용 조절 | 모델 선택 | — | 모델 기어(절약/균형/최대) |

> **여기서 읽어야 할 것**: 어떤 하네스의 "액션"은 다른 하네스의 "도구(tool)"와 같은 것이고, "조종실"은 남들의 "권한 모드"와 같은 자리다. **낯선 하네스를 만나면 이 표의 왼쪽 열을 들고 가서 하나씩 대응시켜 보면 된다.** 대응이 안 되는 칸이 그 도구의 약점이거나 독창성이다.

---

## 7부. 먼저 알아야 할 30개

전부 외우려 하지 말고, **이 30개만 먼저** 몸에 붙인다. 이것만으로 AI와의 대화 대부분이 통한다.

**컴퓨터 지형 (10)**
터미널 · 라이브러리 · 패키지 매니저(pip/npm) · 의존성 · 가상환경 · 경로 · 환경변수 · API 키 · 에러/로그 · JSON

**코드 보관 (5)**
Git · 커밋 · 저장소(repo) · GitHub · 브랜치

**돌아가는 곳 (6)**
로컬 vs 클라우드 · 서버/클라이언트 · API · 배포 · localhost:포트 · 호스팅

**AI 자체 (5)**
LLM · 토큰 · 컨텍스트 윈도우 · RAG · 환각

**일하는 AI (4)**
에이전트 · 도구 사용(tool use) · MCP · 하네스

### 학습 순서 제안

1. **먼저 만든다.** AI에게 아주 작은 걸 하나 만들게 하고 `localhost`에서 열어 본다. 여기서 1~3부 용어의 절반을 몸으로 만난다.
2. **다음에 저장한다.** Git으로 커밋하고 GitHub에 올린다. 되돌릴 수 있게 되면 과감해진다.
3. **그다음 내보낸다.** 만든 것을 배포해서 남에게 링크를 보낸다. 3부가 완성된다.
4. **그리고 자동화한다.** 반복되는 일을 스킬·트리거로 굳힌다. 5부로 넘어간다.
5. **마지막에 조립한다.** 나만의 도구를 MCP나 액션으로 붙여 나만의 하네스를 만든다.

> **하나만 기억한다면**: 용어를 알게 되면 **AI에게 물어볼 수 있게 된다.** 이 용어집의 목적은 답을 주는 게 아니라, 질문할 수 있는 상태로 만드는 것이다. 모르는 단어를 만났을 때 "그게 뭔데?"라고 물을 수 있으면 이미 충분하다.

---

## 부록 A. 헷갈리는 짝

| A vs B | 핵심 차이 |
|---|---|
| 라이브러리 vs 프레임워크 | 내가 부르면 라이브러리, 나를 부르면 프레임워크 |
| API vs SDK | API는 창구, SDK는 그 창구를 편하게 쓰는 도구 세트 |
| 프론트엔드 vs 백엔드 | 보이는 화면 vs 뒤의 처리 |
| 컴파일 vs 인터프리트 | 미리 통째 번역 vs 그때그때 해석 |
| 로컬 vs 클라우드 | 내 컴퓨터 vs 남의 컴퓨터 |
| 정적 vs 동적 | 미리 만들어 둠 vs 그때 만들어 냄 |
| 워크플로우 vs 에이전트 | 순서를 사람이 정함 vs AI가 정함 |
| 챗봇 vs 에이전트 | 말만 함 vs 실제로 함 |
| 프롬프트 vs 컨텍스트 | 내가 쓴 문장 vs 모델이 보는 것 전부 |
| 파인튜닝 vs RAG | 모델을 바꿈 vs 자료를 찾아 넣어 줌 |
| MCP vs API | AI가 도구를 꽂는 표준 규격 vs 프로그램 일반의 창구 |
| 모델 vs 하네스 | 지능 vs 그 지능이 입은 몸 |
| 오픈소스 vs 오픈웨이트 | 코드 공개 vs 모델 숫자만 공개 |
| 토큰 vs 글자 | 요금과 한도의 단위 vs 사람이 세는 단위 |

## 부록 B. 자주 보는 약어

| 약어 | 원말 | 뜻 |
|---|---|---|
| LLM | Large Language Model | 거대언어모델 |
| API | Application Programming Interface | 프로그램 간 창구 |
| SDK | Software Development Kit | 개발 도구 모음 |
| CLI | Command Line Interface | 명령어 방식 |
| GUI | Graphical User Interface | 마우스 방식 |
| IDE | Integrated Development Environment | 코드 편집기 |
| GPU | Graphics Processing Unit | AI 계산용 병렬 칩 |
| VRAM | Video RAM | GPU 전용 메모리 |
| MCP | Model Context Protocol | AI-도구 연결 표준 |
| RAG | Retrieval-Augmented Generation | 검색 증강 생성 |
| PR | Pull Request | 변경 반영 제안 |
| DB | Database | 데이터베이스 |
| CDN | Content Delivery Network | 콘텐츠 배포망 |
| DNS | Domain Name System | 도메인 이름 체계 |
| HTTP | HyperText Transfer Protocol | 웹 통신 규약 |
| JSON | JavaScript Object Notation | 데이터 교환 형식 |
| SQL | Structured Query Language | DB 질의 언어 |
| CI/CD | Continuous Integration/Delivery | 자동 검증·자동 배포 |
| SaaS | Software as a Service | 구독형 소프트웨어 |
| OSS | Open Source Software | 오픈소스 |

---

*강국진 · 2026년 7월*