한 줄 정의

단어나 문장의 뜻을 숫자 여러 개로 바꿔 놓은 것

1. 비유로 이해하기

지도 위의 좌표를 떠올리면 된다.

서울과 인천은 좌표가 가깝고, 부산은 멀다. 두 도시를 가 본 적이 없어도 좌표 숫자만 비교하면 어디가 가까운지 알 수 있다. 지도가 하는 일이 그것이다. 장소를 숫자 두 개로 바꿔 놓아서, 거리를 계산으로 구할 수 있게 만든다.

임베딩은 뜻에 좌표를 붙이는 일이다.

사과   → [0.8, 0.2, 0.9, ...]  ┐
배     → [0.7, 0.3, 0.9, ...]  ┘ 좌표가 가깝다
자동차 → [0.1, 0.9, 0.1, ...]    멀리 떨어져 있다

실제 임베딩은 좌표가 두 개가 아니라 768개, 1536개, 3072개쯤 된다. 지도가 2차원이라면, 뜻의 지도는 수백 차원인 셈이다.

그리고 이 좌표계에서는 신기한 일이 벌어진다. 좌표끼리 더하고 빼면 뜻도 더해지고 빠진다.

왕 − 남자 + 여자 ≈ 여왕
서울 − 한국 + 일본 ≈ 도쿄

숫자 안에 뜻이 담겨 있다는 증거다.

2. 왜 필요한가

컴퓨터는 “사과”라는 글자를 봐도 그게 “배”와 비슷하고 “자동차”와 다르다는 걸 모른다. 글자는 그냥 부호이기 때문이다. 숫자로 바꿔 놓아야 계산으로 비교할 수 있게 된다.

의미로 검색한다

데이터베이스에서 하는 검색은 글자가 정확히 같아야 찾아진다. “고양이”로 검색하면 “냥이”도 “반려묘”도 안 나온다.

임베딩 검색은 뜻으로 찾는다.

질문: "우리 회사 휴가 며칠이야?"
   ↓ 임베딩으로 변환
   ↓ 좌표가 가까운 문서 찾기
찾은 문서: "연차 규정: 입사 1년 후 15일 부여"
           ← "휴가"라는 단어가 한 번도 안 나오는데 찾아냈다

이 방식을 의미 검색(semantic search)이라고 하고, 이걸로 문서를 찾아 답하는 구조를 RAG(검색 증강 생성)라고 부른다.

에이전트에서 쓰이는 곳

코드로 보면

# 미리: 문서들을 임베딩으로 바꿔 저장 (한 번만)
for doc in documents:
    vec = embed(doc)              # 문장 → 숫자 1536개
    vector_db.save(doc, vec)

# 질문이 올 때마다
q_vec = embed("휴가 며칠?")        # 질문도 같은 방식으로 숫자화
results = vector_db.search(q_vec, top_k=3)   # 가까운 문서 3개

# 찾은 문서를 모델에게 같이 건네준다
answer = call_model(f"참고자료: {results}\n\n질문: 휴가 며칠?")

“가깝다”를 계산하는 방법은 코사인 유사도를 주로 쓴다. 두 좌표가 같은 방향을 가리키는지 재는 방법이고, 결과는 -1(정반대)에서 1(똑같음) 사이로 나온다.

임베딩을 저장하는 전용 창고를 벡터 데이터베이스라고 한다. Pinecone, Chroma, Qdrant 같은 것들이다. SQLite에도 확장 기능을 붙이면 벡터 검색이 되기 때문에, 처음 만들 때는 SQLite 하나로 충분한 경우가 많다.

3. 어디서 만났나

이 용어는 수업에서 정식으로 다루기 전에 따로 정리한 것이다.

다만 6회차에 임베딩이 왜 필요한지를 정확히 보여 주는 자리가 있었다. 데이터베이스에서 WHERE user = '민수' 같은 검색은 글자가 딱 맞아야 찾아진다. 이 한계가 곧 임베딩이 필요한 이유다.

6회차 — 데이터베이스, 서비스의 기억을 어디에 어떤 모양으로 둘까

4. 헷갈리는 개념

5. 많이들 오해하는 지점

ㄱ. “임베딩이랑 벡터가 같은 말 아닌가”

거의 같이 쓰이지만 층이 다르다.

• 벡터 — 숫자를 한 줄로 늘어놓은 그릇의 모양
• 임베딩 — 그 그릇에 뜻을 담아 놓은 것

모든 임베딩은 벡터다. 하지만 모든 벡터가 임베딩은 아니다. 키·몸무게·나이를 늘어놓은 [172, 65, 30]도 벡터지만 임베딩은 아니다. 학습을 통해 뜻이 좌표로 배치된 것만 임베딩이다.

ㄴ. “숫자 칸마다 무슨 뜻인지 정해져 있겠지”

3번째 숫자가 ‘단맛’, 7번째가 ‘크기’ 같은 식으로 정해져 있다고 생각하기 쉽다. 그렇지 않다. 각 숫자가 무슨 뜻인지는 아무도 모른다. 사람이 정한 게 아니라 AI가 학습으로 알아낸 배치라서, 열어 봐도 읽히지 않는다.

우리가 아는 건 결과뿐이다. 뜻이 비슷하면 좌표가 가깝게 배치된다는 것.

ㄷ. “임베딩을 쓰면 검색이 정확해진다”

가장 값비싼 오해다. 임베딩 검색은 뜻이 비슷한 걸 찾아 주지, 정확한 걸 찾아 주지 않는다.

주문번호 A-20260913, 날짜, 사람 이름, 상품 코드처럼 딱 맞아야 하는 것은 오히려 기존 방식이 낫다. “A-20260913” 근처에 “A-20260914”가 있으면 임베딩 검색은 그것도 비슷하다고 가져온다.

그래서 실무에서는 둘을 섞어 쓴다. 정확히 일치해야 하는 건 데이터베이스에, 뜻으로 찾아야 하는 건 임베딩에 맡기는 식이다.

6. 관련 용어

벡터 · 토큰 · SQLite · 데이터베이스 · Q/K/V · 텐서

한 줄 정의

통과시켜도 되는지 검사하는 문. 에이전트의 브레이크

1. 비유로 이해하기

놀이공원 롤러코스터 입구를 떠올리면 된다.

• 키 재는 막대 — 130cm가 안 되면 못 탄다
• 표 검사 — 표가 없으면 못 들어간다
• 직원 — “안전벨트 확인하셨나요?”

이 문들의 공통점은 통과시킬지 말지를 판단한다는 것이다. 그리고 더 중요한 공통점이 하나 있다. 문은 문제가 커지기 전에 앞에서 막는다. 롤러코스터가 출발한 다음에 “키가 작으시네요”라고 하면 이미 늦었다.

2. 왜 필요한가

에이전트는 스스로 판단해서 행동한다. 그래서 “이 판단을 그대로 실행해도 되는가?”를 검사하는 문이 반드시 필요하다. 게이트가 없는 에이전트는 브레이크 없는 자동차다.

판단 기준은 딱 하나

“실수했을 때 되돌릴 수 있는가?”

게이트의 종류

승인 게이트 — 되돌릴 수 없는 행동 앞에서 사람에게 물어본다. HITL(Human-in-the-Loop)이라고도 부른다.

품질 게이트 — 다음 단계로 넘어가기 전에 자동으로 검사한다.

에이전트가 코드 작성
   ↓
[게이트 1] 문법 오류 없나? ──실패──▶ 다시 고쳐
   ↓ 통과
[게이트 2] 테스트 통과하나? ──실패──▶ 다시 고쳐
   ↓ 통과
[게이트 3] 사람 리뷰 ──────────────▶ 승인 후 반영

안전 게이트 — 들어오는 질문이 위험한 요청은 아닌지(입력), 나가는 답변에 개인정보나 API 키가 섞이지 않았는지(출력) 확인한다.

코드로 보면

앞서 본 하네스 루프에 게이트를 넣으면 이렇게 된다.

DANGEROUS_TOOLS = {"send_email", "delete_file", "make_payment"}

for call in response.tool_calls:
    # ▼▼▼ 여기가 게이트 ▼▼▼
    if call.name in DANGEROUS_TOOLS:
        print(f"[확인] {call.name} 을(를) 실행할까요?")
        print(f"       내용: {call.input}")
        if input("y/n > ") != "y":
            result = "사용자가 거절했습니다."
            messages.append(to_message(result))
            continue                  # 실행하지 않고 넘어간다
    # ▲▲▲ 게이트 끝 ▲▲▲

    result = run_tool(call.name, call.input)
    messages.append(to_message(result))

설계할 때 지킬 것

3. 어디서 만났나

이 용어 자체는 수업에서 정식으로 다루기 전에 따로 정리한 것이다. 다만 게이트가 필요한 이유는 이미 두 번 만났다.

7회차에서 에이전트가 파일을 고치고 명령어를 직접 실행하는 구조를 봤다. 스스로 실행한다는 건 곧 스스로 사고도 칠 수 있다는 뜻이었다.

7회차 — 에이전트, MCP, 스킬 — 범용 AI를 내 전용 조수로

8회차에서는 막혔을 때 되돌아올 자리를 남겨 두는 규율을 배웠다. 게이트는 그 “되돌아올 자리”를 사고가 나기 전에 만들어 두는 쪽의 장치다.

8회차 — MVP, 다 만들려 하지 말고 한 흐름이 끝까지 굴러가게

4. 헷갈리는 개념

5. 많이들 오해하는 지점

ㄱ. “문을 많이 세울수록 안전하다”

정반대다. 매번 확인을 요구하면 사람은 내용을 읽지 않고 y를 누르게 된다. 이걸 경고 피로(alert fatigue)라고 하는데, 이 상태가 되면 문이 백 개여도 실질적으로는 하나도 없는 것과 같다. 되돌릴 수 없는 것에만 문을 세워야 문이 의미를 갖는다.

ㄴ. “거절했으면 조용히 넘어가면 된다”

거절당했다는 사실을 모델에게 알려줘야 한다. 안 알려주고 그냥 건너뛰면 모델은 그 작업이 성공한 줄 알고 다음 단계로 넘어간다. “메일을 보냈으니 이제 답장을 기다리자”는 식으로 엉뚱한 길을 계속 간다. 거절 사실을 알려주면 모델은 “이건 하면 안 되는구나” 하고 다른 방법을 찾는다.

ㄷ. “게이트 = 차단”

문의 결과는 세 갈래다. 통과 / 차단 / 우회. 셋째가 특히 중요하다. 확신이 낮으면 더 검색하게 하고, 위험하면 사람에게 보내는 식으로 다른 길로 돌리는 것도 게이트의 일이다.

6. 관련 용어

하네스 · AI 에이전트 · 소프트맥스 · 루트 · MCP

한 줄 정의

숫자를 가로세로 표로 늘어놓은 것. 2차원

1. 비유로 이해하기

숫자를 담는 그릇을 아파트로 생각하면, 행렬은 한 동(棟)이다. 3층 건물에 각 층마다 방이 네 개 있는 식이다.

방을 찾아가려면 “몇 층, 몇 번째” 두 가지를 대야 한다. 필요한 정보가 둘이라서 2차원이다.

[[5, 3, 8, 1],     ← 0행
 [2, 7, 4, 9],     ← 1행
 [6, 1, 0, 3]]     ← 2행
  ↑
  0열

2. 왜 필요한가

벡터를 여러 개 쌓으면 행렬이다

벡터 하나로는 하나만 다룰 수 있다. 여러 개를 한꺼번에 다루려면 쌓아야 한다.

문장 “안녕 세상”을 처리한다면 이렇게 된다.

토큰 2개  →  각 토큰마다 숫자 768개  →  (2, 768) 행렬

딥러닝 계산의 거의 전부가 행렬 곱이다

모델 안에서 벌어지는 일을 아주 크게 줄이면 행렬을 곱하는 것의 반복이다. GPU가 AI 계산에 쓰이는 이유도 이것이다. GPU는 행렬 곱을 아주 많이, 동시에 하도록 만들어진 칩이다.

그래서 행렬의 모양(shape)이 계속 문제가 된다. 곱할 수 있는 모양과 없는 모양이 정해져 있기 때문인데, 이건 아래 5번에서 자세히 본다.

펴기(Flatten)

행렬을 벡터로 납작하게 펴는 일도 자주 한다. 손글씨 이미지를 다루는 코드에서 Flatten이 하는 일이 그것이다.

행렬 (28, 28)  ──Flatten──▶  벡터 (784,)
   사진 한 장                 숫자 784개 한 줄

층층이 쌓인 방들을 복도 하나에 쭉 늘어세우는 셈이다. 담긴 숫자는 그대로고 모양만 바뀐다.

3. 어디서 만났나

이 용어는 수업에서 정식으로 다루기 전에 따로 정리한 것이다.

다만 1회차에서 LLM이 무엇인지 배울 때, “대량의 텍스트를 학습해 패턴을 익힌다”는 그 학습과 계산이 전부 행렬 곱으로 이뤄진다. 겉으로 드러나지 않았을 뿐 바닥에 깔려 있던 개념이다.

1회차 — AI Agent 학습 기록을 시작합니다

4. 헷갈리는 개념

5. 많이들 오해하는 지점

ㄱ. “행렬 곱은 같은 자리끼리 곱하는 것”

가장 비싼 오해다. 같은 자리끼리 곱하는 연산도 따로 있지만(요소별 곱), 행렬 곱은 그게 아니다.

행렬 곱은 왼쪽의 가로줄과 오른쪽의 세로줄을 짝지어, 하나씩 곱해서 전부 더한다.

왼쪽의 한 행    [1, 2, 3]
오른쪽의 한 열   4
                5
                6
                → 1×4 + 2×5 + 3×6 = 32

여기서 중요한 결론이 나온다. 왼쪽의 가로줄 길이와 오른쪽의 세로줄 길이가 같아야 짝이 지어진다. 즉 왼쪽의 열 개수 = 오른쪽의 행 개수여야 곱할 수 있다.

안 맞으면 바로 에러다. 딥러닝을 하면 지겹도록 보게 되는 메시지가 이것이다.

RuntimeError: mat1 and mat2 shapes cannot be multiplied (32x768 and 512x10)
                                                           └─ 768 ≠ 512

읽는 법은 간단하다. 앞 숫자쌍의 뒤 숫자와 뒤 숫자쌍의 앞 숫자가 같은지 보면 된다.

ㄴ. 행과 열을 반대로 읽는다

행(行)은 가로줄, 열(列)은 세로줄이다. shape (3, 4)는 3행 4열, 즉 가로줄이 3개이고 각 줄에 4칸이 있다.

한자로 기억하면 덜 헷갈린다. 열(列)은 줄지어 서 있는 모양이라 세로다. 사람이 줄 서 있는 걸 떠올리면 된다.

ㄷ. “행렬은 표니까 행과 열을 바꿔도 같은 것”

다르다. 행과 열을 바꾸는 것을 전치(transpose)라고 하는데, 모양 자체가 달라진다. (3, 4)를 전치하면 (4, 3)이다.

그리고 위에서 봤듯 곱할 수 있느냐가 모양으로 정해지므로, 전치는 계산 결과를 완전히 바꾼다. 실제로 딥러닝 코드에서 모양이 안 맞을 때 전치로 맞추는 일이 자주 있는데, 이건 “형식만 맞추는 것”이 아니라 무엇과 무엇을 짝지을지를 바꾸는 일이다.

6. 관련 용어

벡터 · 스칼라 · 텐서 · 임베딩 · MNIST

한 줄 정의

손으로 쓴 숫자 사진 7만 장. 머신러닝의 첫 연습곡

1. 비유로 이해하기

피아노를 배우면 누구나 「나비야」부터 친다. 프로그래밍을 배우면 누구나 Hello, World!를 출력한다.

MNIST는 머신러닝의 「나비야」다. 작고, 깨끗하고, 금방 돌아가고, 남들 점수와 비교하기도 쉽다.

한 장은 이렇게 생겼다.

┌────────────────┐
│  28 × 28 픽셀   │   각 칸에 0(흰색)~255(검정) 숫자
│  회색조 (흑백)   │   → 총 784개 숫자
└────────────────┘
       ↓
   정답 라벨: "7"

2. 왜 필요한가

시험용을 따로 떼어 놓는 이유가 중요하다. 문제집 답만 외운 학생은 시험을 못 본다. 모델도 학습 데이터만 잘 맞히는 상태가 될 수 있고, 이걸 과적합(overfitting)이라고 한다.

솔직히 말하면 MNIST는 에이전트를 만들 때 직접 쓰는 물건이 아니다. 그런데도 알아야 할 이유가 세 가지 있다.

① 벤치마크라는 개념의 원형

MNIST는 “모두가 같은 시험지로 겨루면 누가 나은지 알 수 있다”는 문화를 만든 데이터다. 그 문화가 그대로 에이전트 시대로 넘어왔다.

평가 하네스(evaluation harness)의 조상이 MNIST 평가 방식이다. 문제를 꺼내고, 답을 받고, 자동으로 채점하고, 점수를 모으는 그 구조 말이다.

② 작게 먼저 돌려 보는 감각

노트북에서 몇 분이면 돌아간다. 그래서 코드가 잘못됐는지 바로 알 수 있다. 에이전트를 만들 때도 작은 데이터로 흐름이 도는지 먼저 확인하는 습관은 그대로 유효하다. MVP의 감각과 같다.

③ 벤치마크의 한계도 함께 알려준다

MNIST는 이제 너무 쉬워서 은퇴한 시험지다. 웬만한 모델이 99% 넘게 맞히니 비교가 무의미해졌다. 이걸 벤치마크 포화(saturation)라고 하는데, 지금의 에이전트 벤치마크들도 똑같은 일을 겪고 있다.

소프트맥스와 만나는 지점

MNIST를 풀면 마지막에 반드시 소프트맥스가 나온다.

model = nn.Sequential(
    nn.Flatten(),           # 28×28 그림 → 784개 숫자 한 줄로
    nn.Linear(784, 128),    # 특징 추출
    nn.ReLU(),
    nn.Linear(128, 10),     # 10개 점수 = 로짓
    # ↓ 여기서 소프트맥스
)

왜 하필 10개일까. 정답이 0~9, 열 가지라서다.

그림 "7"을 넣으면
    ↓
로짓 (원점수)            소프트맥스 통과
  0: -1.2                  0:  0.2%
  7:  8.9        ──▶       7: 94.1%   ← "7이라고 94% 확신한다"
  9:  2.1                  9:  5.4%
                          ─────────
                          합계 100%

소프트맥스가 있어야 “확신의 정도”를 말할 수 있다. 로짓 8.9는 그냥 숫자지만 94%는 의미가 있다. 그리고 이게 게이트로 이어진다.

probs = softmax(logits)
if probs.max() < 0.7:
    return "사람에게 확인 요청"    # 확신 게이트

확신을 숫자로 만들 수 없으면 이런 게이트를 세울 수 없다.

3. 어디서 만났나

이 용어는 수업에서 정식으로 다루기 전에 따로 정리한 것이다.

다만 7회차에서 에이전트 도구를 고르는 기준을 배울 때, 여러 도구를 같은 조건에서 비교한 수치들이 나왔다. 그런 비교가 가능하려면 모두가 같은 시험지를 써야 하는데, 그 문화의 출발점이 MNIST다.

7회차 — 에이전트, MCP, 스킬 — 범용 AI를 내 전용 조수로

8회차의 “작게 만들어 먼저 돌려 본다”와도 이어진다. MNIST가 지금까지 쓰이는 이유 중 하나가 몇 분이면 한 바퀴가 돈다는 것이다.

8회차 — MVP, 다 만들려 하지 말고 한 흐름이 끝까지 굴러가게

4. 헷갈리는 개념

5. 많이들 오해하는 지점

ㄱ. “옛날 데이터니까 몰라도 된다”

데이터 자체는 은퇴한 게 맞다. 하지만 MNIST가 만든 건 데이터가 아니라 문화다. “표준 시험지를 정하고, 자동으로 채점하고, 점수로 비교한다”는 방식 전체 말이다.

지금 “SWE-bench 70%”라는 문장을 읽을 때 그게 무슨 뜻이고 어디까지 믿어야 하는지 판단하는 눈이 여기서 나온다.

ㄴ. “벤치마크 점수가 높으면 실전에서도 잘한다”

가장 값비싼 오해다. MNIST를 99% 맞히는 모델이 실제 우편번호는 못 읽는 일이 있었다. 배경이 다르고, 글씨가 기울어져 있고, 얼룩이 있으니까.

SWE-bench 점수와 내 회사 코드베이스에서의 실력은 다른 문제다. 시험지는 깨끗하게 정리된 문제이고, 현실은 그렇지 않다. 점수는 고를 때의 참고치이지 보증서가 아니다.

ㄷ. “학습에 쓴 데이터로 시험 보면 되지 않나”

그게 바로 문제집 답만 외운 학생이다. 시험지를 미리 보여 주면 점수는 올라가지만 그 점수가 아무 의미도 없어진다.

이 감각은 에이전트에도 그대로 적용된다. 내가 만든 에이전트를 내가 개발하면서 써 본 질문들로만 평가하면, 그건 이미 답을 본 시험이다.

6. 관련 용어

소프트맥스 · 행렬 · 하네스 · MVP · 게이트 · 텐서

한 줄 정의

어텐션의 세 벡터 — 찾는 것(Q), 이름표(K), 내용물(V)

1. 비유로 이해하기

도서관에서 책을 찾는 장면이다.

Q (Query, 검색어)   : "공룡에 대해 알고 싶어"      ← 내가 원하는 것
K (Key, 책등 제목)  : 각 책 옆면에 붙은 제목        ← 훑어보는 이름표
V (Value, 내용)     : 책을 펼쳤을 때 나오는 글      ← 실제로 얻는 것

순서는 이렇다.

1. 내 검색어(Q)를 들고 서가를 훑는다
2. 책들의 제목(K)과 하나하나 맞춰 본다 → 얼마나 맞는지 점수를 매긴다
3. 점수를 비율로 바꾼다 → 『공룡백과』 70%, 『파충류』 20%, 『요리책』 1%
4. 그 비율만큼 각 책의 내용(V)을 섞어서 가져온다

3번이 바로 소프트맥스다.

그리고 여기서 중요한 게 하나 있다. 한 권만 고르는 게 아니라 여러 권을 비율대로 섞는다. 공룡백과를 70%, 파충류 책을 20%만큼 겹쳐 읽는 셈이다.

K와 V를 왜 나눠 놨을까? 책등 제목과 책 내용은 다르기 때문이다. 제목은 찾기 좋게 짧게 적혀 있고, 내용은 실제로 쓸모 있는 정보다. 찾는 용도(K)와 쓰는 용도(V)를 분리한 것이 이 구조의 핵심 아이디어다.

2. 왜 필요한가

무슨 문제를 푸는가

"민수가 사과를 떨어뜨렸는데, 그것이 굴러갔다."

“그것”이 무엇인지 우리는 안다. 사과다. 민수가 굴러간 게 아니다.

그런데 컴퓨터에게 “그것”이라는 토큰은 그냥 숫자 뭉치다. 앞의 어떤 단어를 가리키는지 알 방법이 없다. 어텐션이 이 문제를 이렇게 푼다.

"그것"의 Q: "나는 앞의 명사 중 무언가를 가리키는 대명사야.
             굴러갈 수 있는 물체를 찾아."
                        ↓ 각 단어의 K와 비교
민수의 K:    "사람, 주어"             → 점수 낮음  (0.05)
사과의 K:    "물체, 둥글고 작음"       → 점수 높음  (0.85)
떨어뜨의 K:  "동사, 행위"             → 점수 낮음  (0.10)
                        ↓ 소프트맥스
"그것"의 새 임베딩 = 0.85×사과V + 0.10×떨어뜨V + 0.05×민수V

“그것”의 벡터 안에 사과의 의미가 85% 섞여 들어간다. 문맥을 이해한다는 게 바로 이것이다.

임베딩은 문맥 없는 기본 뜻이다. 어텐션을 거치면 그 숫자들이 문맥에 맞게 갱신된다. 그리고 이 과정이 수십 층 반복된다.

셋 다 같은 곳에서 나온다

각 토큰의 임베딩 하나에 행렬 세 개를 곱해서 Q, K, V를 만든다.

Q = embedding @ W_q    # (768,) × (768, 64) → (64,)
K = embedding @ W_k
V = embedding @ W_v

같은 단어에서 출발했는데 곱하는 행렬이 달라서 셋이 서로 다른 벡터가 된다. 하나의 단어가 세 가지 역할을 동시에 맡는 것이다.

계산은 네 줄이다

                    ┌   Q · Kᵀ   ┐
Attention = softmax │ ───────── │ · V
                    └    √d_k    ┘

def attention(Q, K, V):
    d_k = K.shape[-1]
    scores = Q @ K.T / np.sqrt(d_k)   # 점수 + 크기 조절
    weights = softmax(scores)          # 확률로
    return weights @ V                 # 비율대로 섞기

÷√d_k가 왜 있을까 — 스케일러의 원리

임베딩 차원이 768이면 Q·K 값이 아주 커진다. 그 상태로 소프트맥스에 넣으면 이렇게 된다.

점수가 작을 때  [2, 1, 0.5]    → softmax → [0.6, 0.2, 0.1]   부드럽다
점수가 클 때    [20, 10, 5]    → softmax → [1.0, 0.0, 0.0]   한 곳만 본다

한 단어만 100% 보고 나머지를 완전히 무시하면 학습이 안 된다. 그래서 √d_k로 나눠 적당한 크기로 되돌린다.

숫자들의 크기를 맞춰 주는 이 작업이 스케일러가 하는 일과 같은 원리다. 이 방식의 정식 이름이 Scaled Dot-Product Attention인 이유가 여기 있다.

KV 캐시 — 에이전트 비용의 핵심

하네스 루프를 돌 때마다 대화 전체를 처음부터 다시 보낸다. 그런데 이미 계산한 K와 V는 바뀌지 않는다. 그래서 저장해 두고 재사용한다. 이게 KV 캐시다.

1번째 턴:  [시스템 프롬프트 + 도구 설명]  → K,V 계산 (비싸다)
2번째 턴:  [같은 앞부분] + 새 질문
           └─ 캐시에서 꺼내 쓴다 ─┘   └ 이것만 계산

API의 프롬프트 캐싱 기능이 바로 이것이다. 여기서 실무 요령이 하나 나온다.

프롬프트를 짤 때 안 바뀌는 것을 앞에, 바뀌는 것을 뒤에 둔다. 앞부분이 고정돼야 캐시가 먹힌다.

컨텍스트가 길수록 왜 비싼가 — n² 문제

Q · Kᵀ는 모든 단어가 모든 단어와 짝지어 비교하는 계산이다.

토큰 1,000개  →  100만 번 비교
토큰 2,000개  →  400만 번 비교   (2배가 아니라 4배)
토큰 10,000개 →  1억 번 비교

컨텍스트를 2배 늘리면 계산은 4배가 된다. 긴 컨텍스트가 비싸고 느린 근본 이유이고, 컨텍스트 관리가 에이전트 개발의 핵심 과제인 이유다.

멀티헤드 어텐션

Q/K/V를 한 세트만 쓰지 않고 여러 세트를 동시에 돌린다. 보통 12~96개다.

헤드 1: 문법 관계에 주목 (주어-동사)
헤드 2: 대명사가 가리키는 대상에 주목
헤드 3: 멀리 떨어진 단어 관계에 주목
  ...
→ 전부 이어붙여서 사용

한 명이 책을 찾는 게 아니라 사서 여러 명이 각자 다른 기준으로 찾아와 합치는 것과 같다.

3. 어디서 만났나

이 용어는 수업에서 정식으로 다루기 전에 따로 정리한 것이다.

다만 7회차에서 “컨텍스트가 길면 왜 비싼가”라는 질문을 만났는데, 그 답이 위의 n² 문제다. 토큰을 줄이라는 조언의 바닥에 이 계산이 있었다.

7회차 — 에이전트, MCP, 스킬 — 범용 AI를 내 전용 조수로

6회차의 데이터베이스와도 이어진다. WHERE user = '민수'가 Q/K/V의 조상 격이기 때문인데, 아래 4번에서 이어서 본다.

6회차 — 데이터베이스, 서비스의 기억을 어디에 어떤 모양으로 둘까

4. 헷갈리는 개념

이름의 뿌리가 데이터베이스라는 게 재미있다. WHERE user = '민수'를 보면 검색 조건 '민수'가 Q, 열 user가 K, 열 fact가 V에 해당한다. 어텐션은 말랑말랑한 데이터베이스 조회인 셈이다. DB는 맞거나 안 맞거나 둘 중 하나지만, 어텐션은 “85% 맞음”이 가능하다.

5. 많이들 오해하는 지점

ㄱ. “어텐션이 가장 관련 있는 단어 하나를 골라낸다”

고르지 않는다. 전부를 비율대로 섞는다.

도서관 비유로 돌아가면, 한 권만 빌려 오는 게 아니라 공룡백과 70% + 파충류책 20% + 나머지를 겹쳐 읽는 것이다. “그것”의 경우도 사과만 가져온 게 아니라 0.85×사과 + 0.10×떨어뜨 + 0.05×민수를 섞었다.

이 차이가 중요한 이유는, 그래서 애매한 문맥도 처리할 수 있기 때문이다. 하나만 골랐다면 애매할 때 틀릴 수밖에 없다.

ㄴ. “어텐션이랑 RAG 검색이 결국 같은 것 아닌가”

둘 다 “관련 있는 걸 찾아온다”라서 헷갈리는데, 층이 완전히 다르다.

어텐션은 모델 안의 검색, RAG는 모델 밖의 검색이라고 보면 된다.

ㄷ. “Q, K, V가 각각 다른 데이터다”

세 글자로 나뉘어 있으니 서로 다른 데서 온 것처럼 보인다. 그렇지 않다. 셋 다 같은 단어의 임베딩 하나에서 나온다. 곱하는 행렬(W_q, W_k, W_v)만 다를 뿐이다.

한 사람이 상황에 따라 “찾는 사람 · 이름표 · 내용물” 세 역할을 동시에 맡는다고 생각하면 된다. 문장 안의 모든 단어가 각자 이 셋을 전부 갖고 있고, 서로를 훑는다.

6. 관련 용어

어텐션 · 트랜스포머 · 임베딩 · 소프트맥스 · 토큰 · 벡터 · 행렬 · SQLite

한 줄 정의

더 위로 올라갈 수 없는 가장 처음 자리

1. 비유로 이해하기

나무를 거꾸로 뒤집어 보면 된다. 컴퓨터의 폴더 구조가 딱 그 모양이다.

어느 파일에서 출발해도 계속 위로 올라가면 결국 루트에 도착하고, 거기서는 더 올라갈 곳이 없다. 뿌리니까.

2. 왜 필요한가

루트 디렉터리 — 경로의 기준점

파일 시스템의 최상단이다. 표기는 운영체제마다 다르다.

이게 중요한 이유는 경로를 읽는 기준이 되기 때문이다. /home/user/a.txt처럼 루트부터 전부 쓴 주소가 절대 경로이고, ./a.txt처럼 지금 서 있는 자리를 기준으로 쓴 주소가 상대 경로다.

에이전트에게 파일 도구를 줄 때도 기준선이 된다. “어디부터 어디까지 건드릴 수 있는가”가 루트로 정해진다.

# 위험: 컴퓨터 전체를 뒤질 수 있다
allowed_root = "/"

# 안전: 이 폴더 밖으로는 못 나간다
allowed_root = "/home/user/project"

MCP 파일 서버를 실행할 때 폴더를 인자로 넘기는 이유가 이것이다. 그 폴더가 그 서버의 루트가 된다.

npx @modelcontextprotocol/server-filesystem ~/docs
#                                            └─ 이 서버의 루트

설정 파일이 루트에 모이는 이유

에이전트 프로젝트의 전형적인 폴더 구조다.

my-agent/                 ← 프로젝트 루트
├── README.md             ← 설명 (대문 안내판)
├── .gitignore            ← 올리지 말 파일 목록
├── .env                  ← API 키 (절대 커밋 금지)
├── src/
│   ├── harness.py
│   └── tools.py
└── data/
    └── memory.db         ← SQLite 기억 파일

설정 파일이 전부 루트에 모여 있다. 우연이 아니다. 프로그램들이 “이 프로젝트의 설정은 루트에 있겠지” 하고 그 자리를 찾기 때문이다. .gitignore를 src/ 안에 넣으면 git이 못 찾는다.

저장소의 README.md를 루트에 두는 것도 같은 이유다. 누가 저장소에 처음 들어오면 무조건 거치는 자리라서, 대문에 붙인 안내판이 되는 것이다.

루트 사용자 — 뭐든 할 수 있는 계정

컴퓨터에서 최고 권한을 가진 계정을 루트 사용자라고 한다. 리눅스에서 명령 앞에 sudo를 붙이는 건 “잠깐 최고 권한으로 하겠습니다”라는 뜻이다.

에이전트에게 명령 실행 도구를 줄 때는 절대 루트 권한으로 돌리지 않는 게 원칙이다. 모델이 판단을 잘못하면 되돌릴 수 없는 일이 벌어질 수 있기 때문이다.

루트 원인 — 증상이 아니라 뿌리

문제의 진짜 원인을 뜻한다. 눈에 보이는 증상이 아니라, 계속 “왜?”를 타고 내려가면 나오는 자리다.

증상: 에이전트가 엉뚱한 답을 한다
  ↓ 왜?
검색 도구가 관련 없는 문서를 가져온다
  ↓ 왜?
모델이 검색어를 너무 짧게 만든다
  ↓ 왜?
도구 스키마의 설명이 부실하다        ← 루트 원인

3. 어디서 만났나

이 용어 자체는 수업에서 정식으로 다루기 전에 따로 정리한 것이다. 다만 루트가 무엇인지 알아야 넘어갈 수 있는 자리는 이미 두 번 있었다.

2회차에서 블로그 저장소를 만들고 그 폴더에서 작업을 시작했다. 그 폴더가 바로 프로젝트 루트였고, README.md와 설정 파일이 거기 놓였다.

2회차 — Git·GitHub 복습과 바이브 코딩 작업대 만들기

3회차에서 PATH를 배우며 “경로”라는 개념을 처음 다뤘다. 운영체제가 실행 파일을 찾아 다니는 그 주소들이 전부 루트에서 출발한다.

3회차 — PATH, 프로세스와 스레드, 그리고 동기·비동기

4. 헷갈리는 개념

5. 많이들 오해하는 지점

ㄱ. “루트 = C 드라이브”

윈도우를 쓰면 이렇게 굳기 쉽다. 하지만 루트에는 늘 “무엇의”가 붙는다. 프로젝트 루트도 루트고, MCP 파일 서버에 넘겨준 ~/docs도 그 서버의 루트다. C:\는 파일 시스템 전체의 루트일 뿐이다.

그래서 누가 “루트에 두세요”라고 하면 무엇의 루트인지 먼저 물어봐야 한다. 대개는 프로젝트 폴더 맨 위를 말하는 것이지, C:\에 파일을 놓으라는 뜻이 아니다.

ㄴ. “루트 = 내 문서 같은 홈 폴더”

홈(~)은 루트가 아니다. 윈도우에서 C:\Users\내이름, 맥에서 /Users/내이름처럼 루트 한참 아래에 있는 내 개인 폴더다. 컴퓨터를 켜면 보통 여기서 시작하니까 여기가 꼭대기처럼 느껴지는 것뿐이다.

ㄷ. 한국어 “루트”가 사실 세 단어다

그래서 “루트 경로”라는 말은 그 자체로 모호하다. 개발 문맥에서 그냥 “루트”라고 하면 대개 root(최상단)이고, 경로를 뜻할 때는 보통 “라우트 / 라우팅”이라고 구분해서 쓴다.

6. 관련 용어

PATH · CLI · 저장소 · 게이트 · MCP · 절대 경로

한 줄 정의

숫자 하나. 차원이 없는 값

1. 비유로 이해하기

숫자를 담는 그릇을 아파트로 생각하면 맞아떨어진다. 스칼라는 방 하나다.

몇 동 몇 층 몇 호인지 댈 필요가 없다. 그냥 그거 하나다. 주소를 대는 데 필요한 정보가 0개라서 스칼라를 0차원이라고 부른다.

온도가 23, 확률이 0.95. 이런 값들이 스칼라다.

2. 왜 필요한가

숫자 하나에 왜 이름까지 붙였을까

“숫자 하나”라는 말이면 충분할 것 같은데 굳이 이름이 붙은 이유가 있다. 값이 하나인지 여러 개인지에 따라 계산의 모양이 완전히 달라지기 때문이다.

숫자 하나를 벡터에 곱하는 것과 벡터를 벡터에 곱하는 것은 전혀 다른 연산이다. 그래서 “이 값은 하나짜리”라는 걸 분명히 해 두어야 한다. 스칼라는 0차원이라는 자리를 차지하는 이름이다.

실제로 만나는 스칼라들

LLM이 내놓는 마지막 값이 스칼라다

이게 스칼라를 기억해야 하는 가장 좋은 이유다.

LLM은 다음에 올 단어를 고를 때, 사전에 있는 모든 단어(10만 개쯤)에 점수를 매긴다. 그 점수 뭉치는 숫자 10만 개짜리 벡터다. 그걸 확률로 바꿔도 여전히 10만 개짜리 벡터다.

그런데 최종 출력은 거기서 하나를 고른 값이다. 숫자 하나. 스칼라.

숫자 10만 개 (벡터)  ──하나 고르기──▶  14523 (스칼라)
                                        └─ "좋은" 이라는 토큰

그 스칼라 하나가 글자로 바뀌어 화면에 찍힌다. 우리가 읽는 AI의 답변은 스칼라를 하나씩 이어붙인 것이다.

3. 어디서 만났나

이 용어는 수업에서 정식으로 다루기 전에 따로 정리한 것이다.

다만 7회차에서 토큰과 컨텍스트를 배울 때 이미 마주친 개념이었다. 토큰 하나는 결국 번호 하나이고, 그 번호가 스칼라다. “토큰 수”를 세는 일도 값 하나를 다루는 일이다.

7회차 — 에이전트, MCP, 스킬 — 범용 AI를 내 전용 조수로

4. 헷갈리는 개념

5. 많이들 오해하는 지점

ㄱ. “스칼라랑 스케일러는 같은 말 아닌가”

한국어로 쓰면 거의 같게 들려서 정말 자주 섞인다. 전혀 다른 물건이다.

스케일러가 하는 일은 이렇다. 데이터에 나이(0~100)와 연봉(0~1억)이 섞여 있으면, 연봉 숫자가 너무 커서 모델이 나이를 거의 무시해 버린다. 그래서 둘을 비슷한 범위로 줄여 주는 게 스케일러다. 이걸 정규화(normalization)라고 한다.

from sklearn.preprocessing import StandardScaler
scaler = StandardScaler()
X = scaler.fit_transform(X)   # 모든 열을 평균 0, 표준편차 1로

손글씨 이미지의 픽셀 값 0~255를 0~1로 나누는 것도 같은 작업이다.

ㄴ. “숫자 하나에 이름까지 붙일 필요가 있나”

필요하다. 코드에서 “이건 값 하나야”를 명시하지 않으면 모양이 안 맞아서 에러가 난다. 딥러닝 에러의 상당수가 이런 모양 문제다. 스칼라는 그 체계의 맨 아래 칸이다.

ㄷ. “스칼라는 정수를 말하는 것”

23도 0.95도 -1.7도 전부 스칼라다. 정수냐 실수냐가 아니라 몇 개냐의 문제다. 숫자가 하나면 종류가 뭐든 스칼라다.

6. 관련 용어

벡터 · 행렬 · 텐서 · 소프트맥스 · 토큰

한 줄 정의

숫자 여러 개를 다 더하면 1이 되는 확률로 바꾸는 계산

1. 비유로 이해하기

반장 선거를 생각해 보자. 개표하니 이렇게 나왔다.

민수 20표,  영희 8표,  철수 2표

여기서 “민수가 뽑힐 확률”을 말하려면 백분율로 바꿔야 한다. 전체 30표로 나누면 67% · 27% · 7%다. 개수를 비율로 바꾸는 이 작업이 소프트맥스가 하는 일이다.

2. 왜 필요한가

그냥 나누기와 뭐가 다른가

두 가지가 다르다.

① 음수도 처리한다. AI가 내놓는 점수는 -3.2처럼 음수일 수 있다. 득표수로는 -3표가 말이 안 된다. 그래서 나누기 전에 모든 숫자를 exp(지수 함수)에 넣어 무조건 양수로 만든다.

② 1등을 더 밀어준다. 이게 이름의 soft-max다. 그냥 나누기만 하면 격차가 그대로지만, exp를 거치면 격차가 더 벌어진다.

하드맥스:   [100%,  0%,  0%]   ← 1등만 살린다 (너무 딱딱하다)
소프트맥스: [ 66%, 24%, 10%]   ← 1등을 밀어주되 나머지도 살린다
그냥 비율:  [ 65%, 32%,  3%]   ← 격차 반영이 약하다

“1등만 100%”와 “그냥 비율”의 중간 지점이라서 소프트맥스라는 이름이 붙었다.

LLM이 글을 쓰는 원리가 이것이다

모델은 매 순간 모든 단어에 점수를 매긴다. 이 원점수를 로짓(logit)이라고 부른다.

"오늘 날씨가 정말" 다음에 올 단어의 로짓
  좋다 :  8.2
  덥다 :  6.1
  이상 :  3.4
  바나나: -4.7
   ... (10만 개 단어 전부)

이 점수들은 그냥 숫자라서 “얼마나 확실한지”를 말할 수 없다. 소프트맥스를 통과시키면 확률이 된다.

  좋다 : 84%
  덥다 : 11%
  이상 :  4%
  바나나: 0.0001%

그리고 이 확률에 따라 주사위를 굴려 하나를 뽑는다. 이걸 샘플링이라고 한다.

온도(temperature)의 정체

에이전트 설정에서 자주 보는 temperature는 소프트맥스에 들어가기 전에 로짓을 나누는 숫자다. 딱 그것뿐이다.

에이전트를 만들 때는 보통 온도를 낮게 쓴다. 도구 이름을 창의적으로 지어내면 안 되기 때문이다. 반대로 브레인스토밍용이라면 높게 둔다.

계산은 두 줄이다

import numpy as np

logits = np.array([2.0, 1.0, 0.1])      # 모델이 내놓은 원점수

exp_values = np.exp(logits)             # ① 전부 양수로, 격차를 벌린다
# → [7.389, 2.718, 1.105]

probs = exp_values / exp_values.sum()   # ② 전체 합으로 나눈다
# → [0.659, 0.242, 0.099]   ← 다 더하면 1.0

exp로 양수화 + 전체 합으로 나누기. 이게 전부다.

모델 곳곳에 들어 있다

• 다음 단어 고르기 — 위에서 본 것
• 어텐션 — Q와 K를 곱해 나온 관련도 점수를 확률로 바꿀 때
• 모델 안의 게이트 — 여러 전문가 중 누구에게 보낼지 고를 때
• 확신 게이트 — if 확률 < 0.7: 사람에게 확인 같은 판단을 만들 때

3. 어디서 만났나

이 용어는 수업에서 정식으로 다루기 전에 따로 정리한 것이다.

다만 1회차에서 LLM을 배울 때 이미 그 자리에 있었다. “문맥을 바탕으로 다음에 올 내용을 예측한다”는 그 예측이 정확히 이 계산이다. 예측이라는 말이 실제로는 “모든 단어에 점수를 매기고 확률로 바꿔 하나를 뽑는 일”이었던 것이다.

1회차 — AI Agent 학습 기록을 시작합니다

4. 헷갈리는 개념

5. 많이들 오해하는 지점

ㄱ. “온도는 창의성 다이얼이다”

설정 화면에서 보면 딱 그렇게 느껴진다. 하지만 실제로 하는 일은 로짓을 나누는 것 하나다.

온도를 올리면 모델이 창의적으로 생각하는 게 아니라, 덜 뻔한 선택지도 뽑힐 여지가 생기는 것이다. 그래서 온도를 올리면 재미있는 답이 나올 확률과 틀린 답이 나올 확률이 함께 올라간다. 창의성을 켜는 스위치가 아니라, 2등과 3등에게 기회를 더 주는 손잡이다.

ㄴ. “확률이 84%면 84% 맞다는 뜻”

아니다. 84%는 그 단어를 고를 가능성이지 정답일 확률이 아니다. 모델이 완전히 틀린 답에 95%를 줄 수도 있다. 모델은 “내가 얼마나 확신하는가”를 말한 것이지 “내가 얼마나 맞는가”를 말한 게 아니다.

이 구분이 중요한 이유가 있다. 확률이 낮으면 “잘 모르겠다”는 신호로 쓸 수 있지만, 확률이 높다고 해서 믿어도 된다는 보장은 없기 때문이다.

ㄷ. “소프트맥스가 답을 고른다”

고르지 않는다. 소프트맥스는 점수를 확률로 바꿔 놓기만 한다. 실제로 하나를 뽑는 건 그다음 단계인 샘플링이다.

이 둘이 나뉘어 있어서, 같은 확률표를 두고도 “가장 높은 것만 고른다”거나 “확률대로 주사위를 굴린다”거나 “상위 몇 개 중에서만 뽑는다” 같은 서로 다른 전략을 쓸 수 있다.

6. 관련 용어

벡터 · 토큰 · Q/K/V · 게이트 · MNIST · LLM

한 줄 정의

숫자를 담는 그릇 전체를 아우르는 말. 차원이 몇이든

1. 비유로 이해하기

숫자를 담는 그릇을 아파트로 생각해 보자. 방 하나, 한 층, 한 동, 여러 동. 텐서는 그중 하나가 아니라 단지 전체를 가리키는 말이다.

이게 텐서의 핵심이다. 텐서는 특정한 모양이 아니라, 모양 전체를 아우르는 이름이다.

그래서 딥러닝 코드에서는 전부 그냥 “텐서”라고 부른다. TensorFlow라는 이름도 여기서 왔다.

2. 왜 필요한가

shape가 곧 스키마다

스키마가 “이 정보는 이런 모양이어야 한다”는 약속이라면, 텐서에서 그 역할을 하는 게 shape다.

tensor.shape  # (32, 128, 768)
#               ↑    ↑    ↑
#            32문장 128토큰 각 768숫자

이 한 줄이 데이터의 구조를 전부 말해 준다. 그리고 딥러닝 에러의 절대다수가 모양이 안 맞아서 난다. 코드가 틀린 게 아니라 그릇이 안 맞는 것이다.

RuntimeError: mat1 and mat2 shapes cannot be multiplied (32x768 and 512x10)

그래서 딥러닝을 하다 막히면 가장 먼저 하는 일이 print(x.shape)다.

배치 — 텐서가 필요한 가장 흔한 이유

사진 한 장은 행렬(28, 28)이면 충분하다. 그런데 한 장씩 처리하면 너무 느리다. 그래서 32장을 겹쳐 쌓아 한꺼번에 넣는다.

사진 1장   (28, 28)        ← 행렬
사진 32장  (32, 28, 28)    ← 텐서

이렇게 여러 개를 묶는 걸 배치(batch)라고 한다. 3차원 이상의 텐서를 만나는 가장 흔한 이유가 배치다. 맨 앞 숫자가 “몇 개를 한꺼번에”인 경우가 많다.

그릇이 바뀌는 전 과정

“안녕 세상”이라는 입력이 글자가 되어 나오기까지, 같은 데이터가 여러 그릇을 갈아탄다.

벡터 → 행렬 → 텐서 → 벡터 → 스칼라. 그릇이 커졌다가 다시 작아진다. 마지막에 나온 스칼라 하나가 토큰 하나가 되어 화면에 글자로 찍힌다.

이게 LLM이 글을 쓰는 전 과정이다. 그리고 그 과정 내내 데이터는 계속 텐서였다.

3. 어디서 만났나

이 용어는 수업에서 정식으로 다루기 전에 따로 정리한 것이다.

다만 앞선 회차에서 배운 것들이 전부 이 그릇에 담겨 있었다. 1회차에서 LLM이 “패턴을 익혀 다음에 올 내용을 예측한다”고 배웠는데, 그 예측이 위 그림의 ④~⑥ 단계다.

1회차 — AI Agent 학습 기록을 시작합니다

7회차에서 배운 토큰과 컨텍스트도 마찬가지다. “컨텍스트가 길면 비싸다”는 말은, 위 그림에서 가운데 숫자(토큰 수)가 커진다는 뜻이다.

7회차 — 에이전트, MCP, 스킬 — 범용 AI를 내 전용 조수로

4. 헷갈리는 개념

5. 많이들 오해하는 지점

ㄱ. “텐서는 3차원 이상짜리를 부르는 말”

가장 흔한 오해다. 스칼라·벡터·행렬 다음에 텐서가 나오니 네 번째 단계처럼 읽히기 때문이다.

그렇지 않다. 0차원도 텐서다. 텐서는 넷 중 하나가 아니라 넷을 전부 포함하는 말이다. 숫자 하나도 torch.tensor(5)로 만들면 어엿한 텐서다.

ㄴ. “텐서는 어려운 특수 수학이라 따로 공부해야 한다”

이름 때문에 생기는 겁이다. 물리학에서 말하는 텐서는 정말 어려운 개념이 맞다. 하지만 딥러닝에서 텐서는 그냥 다차원 숫자 덩어리다. 이름만 빌려 왔다고 봐도 크게 틀리지 않다.

실제로 필요한 건 딱 하나다. “이 데이터의 모양이 뭐지?”를 늘 확인하는 습관.

ㄷ. “TensorFlow를 써야 텐서가 나오는 것”

이름이 겹쳐서 생기는 오해다. PyTorch도, JAX도 전부 텐서라고 부른다. 라이브러리 이름이 아니라 개념 이름이다. TensorFlow가 그 개념에서 이름을 따 온 것이지 그 반대가 아니다.

6. 관련 용어

스칼라 · 벡터 · 행렬 · 임베딩 · 소프트맥스 · MNIST · 스키마

한 줄 정의

숫자를 한 줄로 늘어놓은 것. 1차원

1. 비유로 이해하기

숫자를 담는 그릇을 아파트로 생각하면, 벡터는 한 층이다. 복도 하나에 방이 여러 개 있다.

방을 찾아가려면 “몇 번째” 하나만 대면 된다. 필요한 정보가 하나라서 1차원이다.

[5, 3, 8, 1]
 ↑
 0번째 방

2. 왜 필요한가

숫자를 한 줄로 묶으면 비교할 수 있다

친구들의 성격을 숫자로 적어 본다고 하자.

            활발함  차분함  운동  독서
민수         [ 9,     2,    8,    1 ]
영희         [ 8,     3,    7,    2 ]
철수         [ 2,     9,    1,    9 ]

민수와 영희의 숫자가 비슷하다. 두 사람은 실제로 성격이 비슷하다. 철수는 숫자가 완전히 다르다.

여기서 벌어진 일이 중요하다. 성격을 안 보고 숫자만 비교해도 누가 누구와 비슷한지 알 수 있게 됐다. 숫자 네 개를 한 줄로 묶어 놨기 때문이다.

컴퓨터는 “사과”라는 글자를 봐도 그게 “배”와 비슷하고 “자동차”와 다르다는 걸 모른다. 벡터로 바꿔 놓으면 계산으로 비교할 수 있게 된다.

사과   → [0.8, 0.2, 0.9, ...]  ┐
배     → [0.7, 0.3, 0.9, ...]  ┘ 가깝다
자동차 → [0.1, 0.9, 0.1, ...]    멀다

이게 의미 검색의 바닥이고, 그걸로 문서를 찾아 답하는 구조가 RAG다.

AI에서 만나는 벡터들

길이가 곧 정보의 세밀함이다

임베딩의 숫자가 768개인지 3072개인지는 뜻을 얼마나 잘게 나눠 담느냐의 차이다. 칸이 많을수록 미묘한 차이를 담을 수 있지만, 저장 공간도 계산량도 늘어난다.

그리고 각 숫자가 무슨 뜻인지는 사람이 정한 게 아니다. AI가 학습으로 알아낸 것이라 아무도 정확히 모른다. 다만 뜻이 담겨 있다는 증거는 있다.

왕 − 남자 + 여자 ≈ 여왕
서울 − 한국 + 일본 ≈ 도쿄

3. 어디서 만났나

이 용어는 수업에서 정식으로 다루기 전에 따로 정리한 것이다.

다만 6회차에 벡터가 왜 필요한지를 보여 주는 자리가 있었다. 데이터베이스에서 WHERE user = '민수' 같은 검색은 글자가 정확히 같아야 찾아진다. “고양이”로 검색하면 “냥이”도 “반려묘”도 안 나온다.

벡터로 바꿔 두면 뜻으로 찾을 수 있다. 6회차에서 배운 검색의 한계가, 곧 벡터가 필요한 이유였다.

6회차 — 데이터베이스, 서비스의 기억을 어디에 어떤 모양으로 둘까

4. 헷갈리는 개념

5. 많이들 오해하는 지점

ㄱ. “벡터니까 화살표와 방향을 떠올려야 한다”

학교에서 배운 벡터(크기 + 방향, 화살표) 때문에 생기는 부담이다. 딥러닝에서 벡터라고 하면 대개 “숫자를 한 줄로 늘어놓은 것”으로 읽으면 된다. 화살표를 그릴 필요도, 방향을 상상할 필요도 없다.

다만 완전히 버리지는 말자. “두 임베딩이 얼마나 가까운가”를 잴 때는 방향 개념이 돌아온다. 두 숫자 뭉치가 같은 방향을 가리키는지 재는 방법을 코사인 유사도라고 하고, 결과는 -1(정반대)에서 1(똑같음) 사이로 나온다. 의미 검색은 이걸로 굴러간다.

ㄴ. “벡터는 그냥 파이썬 리스트다”

비슷해 보이지만 약속이 더 많다. 리스트에는 숫자와 글자를 섞어 넣을 수 있고 길이도 마음대로 바뀐다. 벡터는 전부 같은 종류의 숫자이고 길이가 정해져 있으며, 통째로 더하고 곱하는 연산이 정의돼 있다. 이 약속 덕분에 빠르게 계산할 수 있다.

ㄷ. “벡터 DB에서 말하는 벡터는 다른 뜻인가”

같은 것이다. 임베딩 벡터를 모아 두고 비슷한 걸 빨리 찾아 주는 창고라서 벡터 데이터베이스다. Pinecone, Chroma, Qdrant 같은 것들이고, 확장 기능을 붙이면 SQLite로도 할 수 있다.

6. 관련 용어

스칼라 · 행렬 · 텐서 · 임베딩 · 소프트맥스