질문하는 인간, 애스커스
AI 활용 교육 · 학습교재
1일차 — 생성형 AI의 원리와 활용 모델은 바꿀 수 없다. 바꿀 수 있는 것은 입력과 순서다.
2일차 — 만드는 AI, 다루는 데이터 무엇을 주었는가가, 무엇이 나오는가를 정한다.
학습 목표
- 인공지능·머신러닝·딥러닝·생성형 AI의 관계를 포함 관계와 두 개의 축으로 설명할 수 있다.
- LLM이 답을 만드는 방식(토큰·컨텍스트·확률)을 이해하고 그로부터 환각과 결과 편차가 왜 생기는지 설명할 수 있다.
- RACE 구조로 업무용 프롬프트를 작성하고 재사용 가능한 템플릿으로 정리할 수 있다.
- 이미지·영상·리서치·문서 작업을 단발 요청이 아닌 산출물 사슬로 설계할 수 있다.
- RAG의 원리를 이해하고, Gems로 반복 업무용 도구를 직접 만들며, NotebookLM을 근거가 필요한 업무에 적용할 수 있다.
학습 목표
- 지도학습의 전 과정(클래스 정의 → 예시 수집 → 학습 → 검증 → 내보내기)을 직접 수행하고, 모델이 틀렸을 때 데이터로 되짚어 원인을 설명할 수 있다.
- 학습이 끝난 모델이 링크로 유통되고 다른 앱이 그것을 불러 쓰는 구조를 설명하고, AI Studio로 그 모델을 쓰는 웹 서비스를 만들 수 있다.
- 표기 불일치·단위 혼재·중복·논리 이상치가 섞인 원본 데이터를 기준을 세워 정제한 뒤, 시각화 등 데이터 분석을 할 수 있다.
- EDA와 CDA를 구분하고 대시보드를 차트 모음이 아니라 질문 목록으로 설계할 수 있다.
- 만든 것을 링크로 배포하고 반복 작업을 매크로에 넘기고, 문서를 지식 베이스로 삼는 챗봇을 만들 수 있다.
여는 장오늘 하루의 지도
오늘은 오전에 기계의 구조를 배우고, 오후에 그 구조를 손으로 확인합니다.
왜 이 순서로 배우는가
도구 사용법부터 배우면 빠르게 익히지만 도구가 바뀌면 처음부터 다시 배워야 합니다. 반대로 기계의 성질을 먼저 알면 오후에 배운 요령이 왜 통하는지가 보이고, 내년에 다른 도구가 나와도 같은 판단을 할 수 있습니다. 오늘 오후에 다루는 다섯 가지는 각각 오전의 어떤 성질에 대한 대응책입니다.
| 오전에 알게 되는 성질 | 남는 문제 | 오후의 대응 |
|---|---|---|
| 학습이 끝난 모델은 고정 | 모델을 내 업무에 맞출 수 없다 | 입력을 설계한다 — RACE |
| 생성은 확률적 | 같은 요청에 매번 다른 결과 | 참조 자산을 고정한다 — 캐릭터 시트 |
| 한 번에 처리할 양에 한계 | 긴 결과물이 한 번에 안 나온다 | 공정으로 나눈다 — 생산 라인 |
| 환각은 구조적 | 말은 그럴듯한데 믿을 수 없다 | 근거를 붙인다 — 딥리서치 · RAG |
| 모델은 내 회사를 모른다 | 일반론만 답한다 | 내 자료로 범위를 묶는다 — NotebookLM |
이 표가 오늘 교재 전체의 목차이자 요약이다. 10장에서 다시 만난다.
1 부
원리 — 이 기계는 어떻게 생겼는가
오전 강의. 용어를 외우는 시간이 아니라, 오후의 판단 근거를 쌓는 시간입니다.
1장인공지능이라는 분야
1.1 정의 — 복제가 아니라 재현
인공지능(Artificial Intelligence)은 인간의 지능적 행동을 기계로 재현하려는 분야입니다. "재현"이라는 단어를 가볍게 넘기지 않는 편이 좋습니다. 인간의 사고 과정을 그대로 복제한다는 말이 아니라, 겉으로 드러나는 결과가 지능적으로 보이도록 만든다는 뜻에 가깝습니다.
비행기가 새를 흉내 내지 않고도 날듯이, AI도 사람이 생각하는 방식과 전혀 다른 경로로 사람과 비슷한 결과를 냅니다. 이 차이를 알고 있으면 오후에 결과가 이상하게 나올 때 "왜 사람이라면 하지 않을 실수를 할까"가 이해됩니다. 애초에 사람의 방식으로 하고 있지 않기 때문입니다.
1.2 인공지능을 굴리는 세 가지 재료
AI가 작동하려면 세 가지가 동시에 있어야 합니다. 하나라도 빠지면 나머지가 아무리 좋아도 결과가 나오지 않습니다.
| 재료 | 하는 일 | 빠지면 | 현실의 예 |
|---|---|---|---|
| 데이터DATA | 학습할 경험. 무엇을 보고 배울 것인가 | 배울 대상 자체가 없다 | 인터넷 텍스트, 사내 문서, 센서 로그 |
| 알고리즘MODEL | 경험을 어떤 방식으로 압축·일반화할 것인가 | 데이터가 쌓이기만 하고 규칙이 생기지 않는다 | 신경망 구조, 트랜스포머 |
| 컴퓨팅 파워COMPUTE | 그 압축을 현실적인 시간 안에 끝내는 힘 | 이론상 가능하지만 끝나지 않는다 | GPU 클러스터 |
한 걸음 더 · "왜 하필 지금인가"
신경망 이론은 1950년대부터 있었습니다. AI가 갑자기 실용화된 이유는 새 이론이 나와서가 아니라, 세 재료가 처음으로 동시에 충족됐기 때문입니다. 인터넷이 데이터를 쌓았고(2000년대), 그래픽카드가 병렬 연산을 값싸게 만들었고(2010년대), 트랜스포머라는 구조가 등장했습니다(2017년). 이 셋이 만난 지점에서 오늘 우리가 쓰는 도구가 나왔습니다.
실무에 남는 것은 하나입니다 — 세 재료 중 우리가 손댈 수 있는 것은 데이터뿐입니다. 2일차는 그 데이터를 다룹니다.
1.3 AI의 진화 — 무엇이 무엇을 품고 있는가
용어들이 헷갈리는 이유는 서로 대등한 관계가 아니기 때문입니다. 포함 관계로 그리면 한 번에 정리됩니다.
그리고 이 그림은 두 가지로 동시에 읽힙니다. 안쪽으로 갈수록 범위가 좁아지고, 동시에 더 나중에 나온 것이기도 합니다. 규칙을 사람이 짜 넣던 초기 인공지능에서, 규칙을 데이터에서 배우는 머신러닝으로, 특징까지 스스로 찾는 딥러닝으로, 그리고 새로운 것을 만들어내는 생성형 AI로 — 안쪽 고리가 하나씩 생겨난 순서가 곧 이 분야가 걸어온 길입니다.
2장기계가 배운다는 것 — 파라미터와 학습
학습이란 숫자를 고치는 일이고 학습이 끝나면 그 숫자는 얼어붙습니다. 오후의 모든 기법이 이 한 문장 위에 서 있습니다.
2.1 파라미터 — 지능이 저장되는 그릇
파라미터(parameter)는 학습한 결과가 담기는 숫자들입니다. 신경망에서는 구체적으로 가중치(weight)와 편향(bias)을 가리킵니다. 사람의 지식이 문장으로 저장되지 않고 연결의 세기로 저장된다고 생각하면 가깝습니다.
- 학습이란 — 예측과 정답 사이의 오차를 재고, 그 오차가 줄어드는 방향으로 파라미터를 조금씩 반복해서 고치는 일입니다.
- 모델의 크기란 — 파라미터의 개수입니다. "70억 파라미터", "수천억 파라미터"는 그릇의 크기를 말합니다. 크면 더 많은 패턴을 담지만 크다고 항상 좋지는 않습니다. 용도에 비해 크면 느리고 비쌉니다.
- 가중치 파일이란 — 학습이 끝난 뒤 남는 것은 이 숫자들의 묶음뿐입니다. 모델을 "내려받는다"는 말은 이 숫자 묶음을 받는다는 뜻입니다.
2.2 학습이 끝난다는 것의 의미
학습이 끝나면 파라미터는 고정됩니다. 이후 모델은 사용되는 동안 아무것도 배우지 않습니다. 실무에 곧바로 걸리는 결과가 셋입니다.
| 사실 | 그래서 |
|---|---|
| 대화는 학습이 아니다 | 내가 오늘 알려준 사내 규정을 모델이 기억해 두지 않는다. 다음 대화에서 다시 알려줘야 한다. |
| 지식에 마감일이 있다 | 학습 데이터가 모인 시점 이후의 일은 모른다. 최신 정보가 필요하면 검색이나 자료 첨부로 넣어줘야 한다. |
| 모델은 우리 회사를 모른다 | 사내 문서·용어·이력은 학습에 없었다. 이것이 4장 RAG의 존재 이유다. |
이 교재에서 가장 자주 되돌아올 문장
프롬프트는 파라미터를 단 하나도 바꾸지 않습니다. 우리가 하는 일은 고정된 기계에 어떤 재료를 어떤 순서로 넣을지를 설계하는 일입니다. 오후에 배울 다섯 가지가 전부 이 설계에 관한 이야기입니다.
2.3 기계가 배우는 세 가지 방법
"어떻게 배우는가"를 기준으로 나눈 분류입니다. 각각 적합한 문제가 다릅니다.
| 방법 | 배우는 방식 | 정답(라벨) | 업무에서의 예 |
|---|---|---|---|
| 지도학습SUPERVISED | 입력과 정답을 짝지어 주고 맞히게 한다 | 사람이 붙인다 | 불량/정상 판정, 문의 유형 분류, 수요 예측 |
| 비지도학습UNSUPERVISED | 정답 없이 데이터의 구조와 무리를 스스로 찾는다 | 없다 | 고객 세분화, 이상치 탐지, 문서 군집화 |
| 강화학습REINFORCEMENT | 행동하고 보상·벌점을 받으며 전략을 다듬는다 | 없다 (보상 신호) | 알파고, 로봇 제어, 공정 조건 최적화 |
지도학습이 실제로 받는 두 가지 — 클래스와 라벨
지도학습을 시키려면 먼저 두 가지를 정해야 합니다. 클래스(class)는 모델이 고를 수 있는 답의 목록이고 라벨(label)은 예시 하나하나에 붙인 정답입니다. "정상 / 불량" 두 클래스를 정하고 사진 한 장씩에 둘 중 하나를 붙이는 작업, 그것이 라벨링입니다.
목록을 정하는 순간 한계도 함께 정해진다
목록에 없는 답은 모델이 낼 수 없습니다. "정상 / 불량"으로 배운 모델은 처음 보는 이물질 사진에도 둘 중 하나를 고릅니다. 그것도 확률까지 붙여 자신 있게 고릅니다. 모델에게는 "목록에 없다"고 말할 방법이 없기 때문입니다.
그래서 현장에서 쓸 분류 모델에는 "판정 불가" 같은 칸을 하나 더 두고 그 칸에 떨어진 것을 사람에게 넘깁니다. 클래스 목록을 짜는 일은 기술 작업이 아니라 업무 설계입니다.
이 성질을 기억해 두면 3.1이 훨씬 빨리 이해됩니다. 확률로 답하는 기계에는 "모른다"는 자리가 없다 — 분류 모델이든 LLM이든 마찬가지입니다.
한 가지 더 — 자기지도학습
위 세 가지에 더해, 오늘 우리가 쓰는 LLM을 가능하게 한 방식이 있습니다. 자기지도학습(Self-supervised Learning)입니다.
원리는 뜻밖에 단순합니다. 문장에서 일부를 가리고 그것을 맞히게 합니다. "오늘 회의는 3시에 ____" 에서 가려진 단어를 맞히는 훈련을 수천억 번 반복합니다. 그런데 정답을 사람이 붙이지 않았는데도 지도학습처럼 훈련이 됩니다. 정답이 원래 문장 안에 있었기 때문입니다.
이것이 LLM이 갑자기 커진 이유다
지도학습은 사람이 라벨을 붙여야 해서 데이터 양에 한계가 있습니다. 자기지도학습은 라벨링 비용이 0이므로 인터넷 전체를 교재로 쓸 수 있습니다. 학습 데이터의 규모가 수천 배로 뛰었고, 그 규모에서 문법·상식·추론 비슷한 능력이 함께 따라 나왔습니다. LLM의 폭발적 성능은 새 알고리즘보다 이 규모의 변화에 크게 빚지고 있습니다.
2.4 두 개의 축 — 딥러닝이 놓이는 자리
딥러닝은 위의 세 가지와 나란히 놓고 비교할 수 있는 항목이 아닙니다. 질문 자체가 다르기 때문입니다.
- 지도·비지도·강화학습은 "어떻게 배우는가"에 대한 답이다 → 학습 방법 축
- 딥러닝은 "무엇으로 배우는가"에 대한 답이다 → 모델 구조 축
자주 혼동하는 지점
"머신러닝에는 지도·비지도·강화학습 그리고 딥러닝이 있다"는 식으로 한 줄에 놓으면, 나중에 "딥러닝 기반 지도학습" 같은 표현을 만났을 때 설명이 막힙니다. 두 축으로 나눠 기억하면 이런 조합이 자연스럽게 읽힙니다.
또 하나 — LLM의 사전학습이 자기지도학습이라는 사실은 딥러닝이 무엇인지에 대한 설명이 아니라, LLM이 학습 방법 축에서 어디에 놓이는지에 대한 설명입니다. 두 문장은 서로 다른 층위에 있습니다.
2.5 "특징을 스스로 찾는다"가 실제로 뜻하는 것
딥러닝 이전에는 사람이 특징(feature)을 설계해서 넣어줘야 했습니다. 고양이를 판별하려면 "귀의 뾰족한 정도", "수염의 개수" 같은 항목을 사람이 정의하고 수치로 뽑아내야 했습니다. 이 작업을 특징 공학(feature engineering)이라 부르며, 성능의 대부분이 여기서 갈렸습니다.
딥러닝은 이 과정을 모델 안으로 흡수했습니다. 원본 픽셀을 그대로 넣으면, 앞쪽 층은 선과 모서리를 잡고, 중간 층은 눈·귀 같은 부분을 잡고, 뒤쪽 층은 얼굴 전체를 잡습니다. 사람이 정의한 적 없는 특징을 스스로 만들어냅니다.
오후로 이어지는 지점
이 성질은 양날입니다.
- 얻는 것 — 정의할 수 없는 것을 지시할 수 있습니다. "빈티지한 느낌으로", "차분한 톤으로" — 사람이 그 특징을 수치로 정의한 적이 없는데도 모델은 알아듣습니다.
- 잃는 것 — 모델이 무엇을 특징으로 잡았는지 알 수 없습니다. 그래서 통제가 어렵습니다. 6장에서 만날 '같은 캐릭터가 매번 다르게 나온다'는 문제의 뿌리가 이 성질이고, 말로 통제할 수 없으니 그림을 근거로 주게 됩니다.
한 걸음 더 · 그래서 남이 만든 모델을 이어받을 수 있다
앞쪽 층이 잡는 선·모서리·질감은 고양이 사진이든 나사 사진이든 크게 다르지 않습니다. 그러니 매번 밑바닥부터 배울 이유가 없습니다. 이미 학습된 모델의 앞부분은 그대로 두고 마지막 판단 층만 새로 학습시키는 방법이 널리 쓰이며 이것을 전이학습(transfer learning)이라 부릅니다.
실무에 주는 의미가 큽니다. 밑바닥부터 학습하려면 이미지 수백만 장과 GPU가 필요하지만 전이학습은 예시 수십 장으로 몇 분 안에 끝납니다. "우리 회사 데이터로 AI를 학습시킨다"는 말이 현실적으로 가능한 이유가 대부분 여기에 있습니다.
3장LLM — 언어를 다루는 기계
생성형 AI는 분류하거나 예측하는 대신 새로운 콘텐츠를 만들어내는 AI다. 그중 언어를 다루는 것이 LLM(Large Language Model, 거대 언어 모델)입니다. LLM이 답을 만드는 방식을 들여다봅니다. 오후에 겪을 거의 모든 현상의 뿌리가 여기 있습니다.
3.1 하는 일은 단 하나 — 다음 토큰 예측
LLM이 하는 일은 놀랄 만큼 단순합니다. 지금까지의 글을 보고, 다음에 올 토큰의 확률을 계산해서, 그중 하나를 고릅니다. 그리고 고른 것을 뒤에 붙이고 다시 같은 일을 반복합니다. 문장이 끝날 때까지.
"오늘 회의는 3시에" 다음에 올 말로 시작합니다(62%), 있습니다(21%), 예정되어(9%) … 같은 확률표가 만들어지고, 거기서 하나가 뽑힙니다. 의미를 이해하고 답을 조립하는 것이 아니라, 그럴듯한 다음 조각을 이어 붙이는 것입니다.
여기서 세 가지가 한꺼번에 설명된다
- 왜 자신 있게 틀리는가 — 모델에게는 "모른다"는 상태가 없습니다. 확률이 낮아도 가장 그럴듯한 것을 고를 뿐입니다. 자신감은 정확도와 무관합니다.
- 왜 같은 질문에 다른 답이 나오는가 — 매번 확률표에서 뽑기를 하기 때문입니다. 이 무작위성이 있어야 창의적인 문장이 나오고, 동시에 재현성이 사라집니다.
- 왜 앞부분이 중요한가 — 다음 토큰은 앞의 모든 것에 영향을 받습니다. 첫 문단이 어긋나면 그 뒤 전체가 어긋난 방향으로 이어집니다.
- 왜 계산을 못하는가 — 덧셈을 하는 것이 아니라 덧셈의 결과로 그럴듯한 숫자를 이어 씁니다. 자릿수는 대체로 맞고 값은 가끔 틀리는데, 무엇보다 과정이 남지 않아 검산할 수 없습니다. 숫자를 다루는 순간 가장 먼저 걸리는 성질입니다.
한 걸음 더 · 매번 다른 답을 잠재울 수 있는가
확률표에서 얼마나 과감하게 뽑을지를 조절하는 값이 있습니다. 도구마다 이름이 다르지만 흔히 온도(temperature)라 부릅니다. 낮추면 확률이 가장 높은 것만 고르게 되어 답이 안정되는 대신 밋밋해지고, 높이면 낮은 확률의 후보도 뽑혀 다양해지는 대신 엉뚱해집니다.
일반 채팅 화면에는 이 손잡이가 드러나 있지 않은 경우가 많습니다. 그래도 알아둘 것은 있습니다. 결과가 매번 달라지는 것은 고장이 아니라 설정이라는 것, 그리고 분류·추출처럼 같은 답이 나와야 하는 일과 초안·발상처럼 다양해야 하는 일은 애초에 성격이 다르다는 것입니다.
3.2 토큰 — 모델이 글을 자르는 단위
토큰(token)은 모델이 텍스트를 처리하기 위해 자르는 조각입니다. 단어와 일치하지 않습니다. 자주 쓰는 단어는 통째로 한 토큰이고 드문 단어는 여러 조각으로 쪼개집니다.
| 알아둘 점 | 실무에서 체감되는 지점 |
|---|---|
| 한국어는 토큰을 더 먹는다 | 영어 대비 같은 내용이 더 많은 토큰이 된다. 길이 제한에 더 빨리 걸리고, 유료 API라면 비용도 더 든다. |
| 표·코드·숫자는 무겁다 | 엑셀 표를 통째로 붙이면 생각보다 많은 자리를 차지한다. 필요한 열만 잘라 넣는 것이 실질적인 요령이다. |
| 출력도 토큰이다 | "길게 써줘"는 곧 "토큰을 많이 쓰라"는 뜻이다. 한도가 있는 자원이라는 감각을 갖는 편이 좋다. |
3.3 컨텍스트 윈도우 — 기억력이 아니라 책상 크기
컨텍스트 윈도우(context window)는 모델이 한 번에 올려놓고 처리할 수 있는 토큰의 총량입니다. 여기에는 시스템 지시, 지금까지의 대화, 첨부한 자료, 그리고 앞으로 생성할 답변까지 전부 포함됩니다.
흔히 "AI의 기억력"이라고 부르지만 실제 작동은 기억보다 책상에 가깝습니다. 모델은 매 요청마다 책상 위의 모든 것을 처음부터 다시 읽습니다. 기억하고 있는 것이 아니라, 매번 다시 읽는 것입니다. 그래서 책상이 꽉 차면 오래된 것부터 밀려 떨어집니다.
한 걸음 더 · 컨텍스트가 커도 생기는 문제
최근 모델들은 책상이 매우 커졌습니다. 그런데 책상이 크다고 모든 곳을 똑같이 잘 보는 것은 아닙니다. 아주 긴 자료를 넣으면 앞과 끝은 잘 반영되고 가운데는 덜 반영되는 경향이 관찰됩니다. 그래서 실무에서는 이렇게 합니다.
- 가장 중요한 지시는 맨 앞이나 맨 끝에 둡니다.
- 자료가 길면 통째로 넣기보다 관련된 부분만 잘라 넣습니다. — 이 발상을 자동화한 것이 바로 4장의 RAG입니다.
3.4 환각 — 없앨 수 없고, 줄여야 하는 것
환각(hallucination)은 사실이 아닌 내용을 사실처럼 자연스럽게 생성하는 현상입니다. 그런데 이것은 고장이 아니라 구조적 성질입니다. 확률로 다음 조각을 이어 붙이는 기계에게, 존재하지 않는 논문 제목이나 조항 번호는 매우 그럴듯한 조합이기 때문입니다.
그러니 목표는 "환각을 없앤다"가 아니라 "환각이 생겨도 걸러지는 작업 방식을 만든다"가 되어야 합니다.
| 대응 | 구체적으로 | 왜 통하는가 |
|---|---|---|
| 범위를 묶는다 | "아래 자료에 있는 내용만으로 답하고 없으면 없다고 말하라" | 확률표의 후보를 좁혀 준다 |
| 근거를 요구한다 | "각 항목마다 근거가 된 문장을 함께 인용하라" | 지어내면 인용이 비어 티가 난다 |
| 사실과 추론을 분리시킨다 | "자료에 있는 사실 / 네 추론을 나눠서 표기하라" | 검증할 지점이 드러난다 |
| 검증 가능한 형태로 받는다 | 수치·날짜·출처는 표로, 원문 표기 그대로 | 대조 확인이 빨라진다 |
| 사람이 마지막에 본다 | 대외 문서·수치·법규는 반드시 확인 | 확률 기계의 한계는 사라지지 않는다 |
자주 혼동하는 지점
"검색 기능이 붙었으니 환각이 없어진 것 아닌가"라는 생각은 절반만 맞습니다. 검색은 책상 위에 근거를 올려주는 것이지, 글을 만들어내는 방식 자체를 바꾸지는 않습니다. 검색된 문서를 잘못 요약하거나, 출처와 다르게 연결하는 일은 여전히 생깁니다. 그래서 8장에서는 출처를 직접 눌러 확인하는 단계를 따로 둡니다.
현장 판단 · 맡길 일과 맡기지 않을 일
환각이 없앨 수 없는 성질이라면 남는 질문은 하나입니다. 어디까지 맡길 것인가. 기준을 도구의 성능에 두면 계속 흔들리지만, 틀렸을 때 누가 어떻게 알아채는가에 두면 선이 분명해집니다.
| 맡겨도 되는 일 | 사람이 반드시 확인할 일 |
|---|---|
| 틀리면 내가 바로 안다 — 초안 · 요약 · 발상 | 틀려도 티가 안 난다 — 수치 · 날짜 · 법규 · 인용 |
| 결과를 내가 다시 손본다 | 결과가 그대로 나간다 — 대외 문서 · 공지 |
| 틀려도 되돌릴 수 있다 | 되돌릴 수 없다 — 발송 · 공시 · 계약 |
| 내가 답을 이미 아는 영역 | 내가 검증할 능력이 없는 영역 |
오른쪽 칸이라고 해서 AI를 안 쓴다는 말은 아닙니다. 쓰되 사람의 확인을 공정에 넣습니다. 13.1에서 "맡기지 않을 일을 적어보라"고 하는 근거가 이 표입니다.
3.5 자연어가 인터페이스가 되었다는 것
과거에는 기계에게 일을 시키려면 기계의 언어를 배워야 했습니다. 이제는 사람의 말이 그대로 명령어가 되었습니다. 진입 장벽이 사라진 대신, 새로운 문제가 생겼습니다 — 사람의 말은 원래 모호합니다.
"보고서 잘 정리해줘"는 사람 사이에서는 통합니다. 상대가 맥락을 알기 때문입니다. 모델은 그 맥락을 모릅니다. 그래서 모호한 지시는 모호한 결과로 돌아옵니다. 5장의 RACE는 이 모호함을 걷어내기 위한 구조입니다.
4장모델 바깥을 붙이기 — RAG · MCP · Gems
2장에서 본 대로 모델에는 세 가지 결핍이 있습니다. 최신 정보를 모르고, 우리 회사를 모르며, 무언가를 실행할 손이 없습니다. 이 결핍을 재학습 없이 메우는 두 가지 방식이 RAG와 MCP입니다.
4.1 RAG — 시험 전에 참고자료를 책상에 올려주는 것
RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 이름 그대로입니다. 질문이 들어오면 먼저 관련 문서를 찾아서(Retrieval), 그것을 프롬프트에 끼워 넣은 뒤(Augmented), 답을 쓰게 한다(Generation).
여기서 모델을 재학습하지는 않습니다. 파라미터는 그대로고, 달라지는 것은 책상 위에 무엇이 올라가 있는가뿐입니다. 3.3의 컨텍스트 윈도우 이야기가 그대로 이어집니다.
한 가지 더 짚어둘 것이 있습니다. RAG는 문서를 통째로 넣지 않습니다. 자료를 미리 조각(chunk)으로 잘라 두었다가, 질문이 들어오면 그중 관련 있는 몇 조각만 골라 프롬프트에 끼웁니다. 이유는 3.3에 있습니다 — 책상이 좁아서 문서 전체를 올릴 자리가 없습니다.
그래서 RAG의 성능은 검색 기술보다 자료 정리에서 갈린다
조각이 어디서 잘리는가가 답변 품질을 좌우합니다. 제목 구조가 또렷하고 한 문단이 한 가지만 말하는 문서는 깔끔하게 잘리지만, 소제목 없이 길게 이어진 글은 엉뚱한 자리에서 잘려 문맥이 끊긴 조각이 됩니다.
수치가 특히 위험합니다. "431억 원"만 들어 있는 조각이 검색되면 그것이 무엇의 431억인지 알 수 없는 채로 답변에 실립니다. 그래서 RAG에 넣을 문서는 수치와 기준을 한 문장 안에 두는 편이 좋습니다. 9장 NotebookLM에서 소스를 고를 때 이 감각이 바로 쓰입니다.
4.2 MCP — 도구를 잇는 표준 규격
MCP(Model Context Protocol, 모델 컨텍스트 프로토콜)는 AI를 외부 도구·데이터에 연결하기 위한 개방형 표준 규격입니다. 기기마다 제각각이던 충전 단자가 USB-C로 통일된 것과 같은 성격의 일입니다.
규격이 없던 시절에는 AI를 캘린더에 붙이려면 캘린더용 연결을, 사내 DB에 붙이려면 DB용 연결을 각각 따로 만들어야 했습니다. MCP는 그 연결 방식을 하나로 정해 둔 것입니다. 도구를 만드는 쪽도, 쓰는 쪽도 한 번만 맞추면 됩니다.
| RAG | MCP | |
|---|---|---|
| 해결하는 결핍 | 모델이 우리 자료를 모른다 / 최신이 아니다 | 모델에게 실행할 손이 없다 |
| 동작 | 관련 문서를 찾아 프롬프트에 넣는다 | 도구를 표준 방식으로 연결한다 |
| 성격 | 주로 읽기 — 근거를 대게 한다 | 읽기 + 행동 — 조회하고 쓰고 실행한다 |
| 비유 | 참고자료 반입이 허용된 시험 | 충전 단자를 USB-C로 통일한 것 |
| 오늘 만나는 곳 | 9장 NotebookLM, 8장 딥리서치 | 오늘은 사람이 손으로 도구를 잇는다 — 그 이음새를 자동화하는 방향 |
4.3 Gems — RAG를 손으로 만들어 보기
지금까지는 개념이었습니다. Gems는 그 개념을 몇 분 만에 손에 쥐게 해주는 기능입니다. Gemini 안에서 만드는 나만의 맞춤 어시스턴트이고 만들 때 채우는 칸이 딱 두 갭니다.
- 지시문 — 이 Gem이 누구로서, 무엇을, 어떤 형식으로 답할지. 매 대화마다 자동으로 앞에 붙습니다
- 참고 파일 — 답의 근거로 삼을 자료. 사내 규격서, 양식, 용어집 같은 것들
두 칸이 곧 오늘 배운 두 가지다
지시문 칸은 프롬프트를 고정해 두는 자리이고(5장에서 배울 RACE가 여기 들어간다), 참고 파일 칸은 4.1의 RAG 그 자체입니다. 질문이 들어오면 올려둔 파일에서 관련 조각을 찾아 프롬프트에 끼운 뒤 답을 만듭니다.
그래서 Gem을 한 번 만들어 보면 4장 전체를 개념이 아니라 실질적인 결과물로 확인할 수 있습니다. 파일을 넣고 빼면서 답이 어떻게 달라지는지 보는 것이 이 실습의 목적입니다.
무엇을 Gem으로 만들 가치가 있는가
| 만들 가치가 있다 | 그냥 대화로 충분하다 |
|---|---|
| 반복되는 일 — 주간 보고, 회의록 정리, 문의 분류 | 한 번 하고 끝나는 일 |
| 매번 같은 자료를 근거로 삼는 일 | 그때그때 자료가 달라지는 일 |
| 형식이 정해져 있는 산출물 | 형식을 매번 새로 잡는 일 |
| 여러 사람이 같은 기준으로 해야 하는 일 | 나 혼자 판단하면 되는 일 |
네 번째 줄이 조직에서 가장 값을 합니다. 담당자마다 다른 프롬프트로 다른 형식의 결과를 만들던 일이, Gem 하나를 공유하는 것만으로 기준이 통일됩니다. 프롬프트를 잘 쓰는 사람의 실력이 파일 하나로 옮겨지는 셈입니다.
[역할] 너는 [부서]에서 [업무]를 담당하는 실무자다. [하는 일] 사용자가 [입력물]을 주면 [산출물]로 정리한다. [반드시 지킬 것] - 첨부한 [자료 이름]에 있는 내용만 근거로 쓴다 - 자료에 없으면 "자료에 없음"이라고 표기하고 지어내지 않는다 - 수치·날짜·고유명사는 원문 표기 그대로 옮긴다 [출력 형식] - [표 / 목록 / 문단], [분량] - 마지막에 "확인 필요" 항목을 따로 붙인다 [말투] [간결한 존댓말 / 보고체 …]
자주 혼동하는 지점 — Gem은 학습하지 않는다
"Gem을 만들었으니 이제 우리 회사를 아는 AI가 생겼다"는 말은 절반만 맞습니다. 2.2에서 본 대로 파라미터는 조금도 바뀌지 않았습니다. 달라진 것은 매 대화마다 같은 재료가 자동으로 책상에 올라간다는 것뿐입니다.
실무에서 걸리는 차이가 둘 있습니다. 대화 내용은 Gem에 쌓이지 않는다 — 어제 대화에서 알려준 새 규정은 오늘 사라집니다. 반영하려면 파일을 고쳐 다시 올려야 합니다. 반대로 좋은 점도 여기서 나옵니다 — 파일만 바꾸면 즉시 반영됩니다. 재학습이 필요 없다는 4.1의 성질이 그대로 살아 있습니다.
9장 NotebookLM과 무엇이 다른가
둘 다 RAG 완제품이지만 무게중심이 다릅니다. Gem은 지시문 쪽이 본체입니다 — 정해진 일을 정해진 형식으로 반복시키는 도구이고 자료는 그 일을 돕는 재료입니다. NotebookLM은 자료 쪽이 본체입니다 — 자료 안에 무엇이 있는지 찾고 확인하는 도구이고, 인용 표시가 답변마다 붙습니다.
그래서 "이 형식으로 만들어 줘"는 Gem, "이 문서에 뭐라고 쓰여 있지"는 NotebookLM이 낫습니다. 같은 자료를 양쪽에 넣어 보면 차이가 바로 느껴집니다.
실습 카드
내가 한 달에 세 번 이상 반복하는 일 하나를 골라 Gem을 만듭니다. 지시문은 위 템플릿의 대괄호만 채우고, 참고 파일은 두세 개만 넣습니다. 그리고 두 번 시험합니다.
- 답을 아는 질문을 던져 자료를 제대로 읽는지 확인합니다
- 자료에 없는 질문을 던져 "자료에 없음"이라고 답하는지 확인합니다 — 여기서 지어내면 지시문의 제약을 더 강하게 씁니다
4.4 프롬프트 · RAG · 파인튜닝 — 무엇을 언제 쓰는가
"AI를 우리 회사에 맞춘다"는 말에는 서로 다른 세 가지 방법이 섞여 있습니다. 비용과 효과가 크게 다르므로 구분해 두는 편이 좋습니다.
| 방법 | 무엇을 바꾸나 | 잘하는 것 | 못하는 것 / 비용 |
|---|---|---|---|
| 프롬프트 설계 | 입력만 | 즉시 적용, 비용 0. 대부분의 업무는 여기서 해결된다 | 매번 다시 써야 한다 → 템플릿으로 보완 |
| RAG | 입력에 근거를 추가 | 최신·내부 자료 반영, 출처 제시, 자료가 바뀌면 즉시 반영 | 자료를 정리·관리해야 한다 |
| 파인튜닝 | 파라미터 자체 | 고유한 말투·형식을 몸에 배게 하는 일 | 비용·시간이 크고, 지식을 넣는 용도로는 부적합. 자료가 바뀌면 다시 학습 |
실무 판단 기준
먼저 프롬프트로 시도하고, 자료 근거가 필요하면 RAG로 갑니다. 파인튜닝은 "지식이 부족해서"가 아니라 "형식·말투가 반복적으로 필요해서" 쓰는 방법입니다. 이 순서를 뒤집으면 비용만 크고 효과는 작습니다.
2 부
실천 — 그래서 이렇게 시킨다
오후 실습. 각 장은 오전에 배운 어떤 성질에 대한 대응인지를 먼저 밝히고 시작합니다.
5장프롬프트 설계 — RACE
이 장이 대응하는 성질
2.2 — 모델의 파라미터는 고정되어 있습니다. 우리가 조절할 수 있는 변수는 입력뿐입니다. 그래서 프롬프트는 "요령"이 아니라 유일하게 남은 설계 지점입니다.
5.1 프롬프트란 무엇인가
프롬프트(prompt)는 흔히 "질문"으로 이해되지만 실제로는 모델에게 넘기는 입력 전체입니다. 지시문뿐 아니라 배경 설명, 첨부 자료, 원하는 형식, 제약 조건이 모두 포함됩니다. 질문을 잘 던지는 문제가 아니라 재료를 잘 챙겨 넣는 문제에 가깝습니다.
5.2 RACE — 빠뜨리지 않기 위한 네 칸
RACE는 특정 서비스의 기능이 아니라, 어떤 모델에도 적용되는 범용 구조입니다. Gemini·ChatGPT·Claude 어디서든 같은 방식으로 씁니다. 도구마다 부르는 이름이 조금씩 다를 뿐 — Google의 프롬프트 가이드는 같은 내용을 페르소나 · 과업 · 맥락 · 형식이라 부릅니다 — 채우는 칸은 동일합니다.
| 칸 | 채우는 것 | 빠지면 생기는 일 |
|---|---|---|
| R — Role역할 | 누구로서 답할 것인가. 전문성·입장·시야를 지정 | 일반론이 나온다. 깊이가 얕다 |
| A — Action과업 | 무엇을 하라는 것인가. 동사로 명확히 | 요청을 넓게 해석해 엉뚱한 것을 준다 |
| C — Context맥락 | 배경 · 대상 · 기간 · 제약 · 참고 자료 | 내 상황과 무관한 답이 나온다 |
| E — Expectation기대 결과 | 형식 · 분량 · 톤 · 읽는 사람 | 가장 흔한 형식으로 답한다 — 늘 비슷한 글이 나오는 원인 |
각 칸이 오전의 어떤 내용과 이어지는가
- C(맥락)를 길게 쓰라는 조언의 근거는 3.3 컨텍스트 윈도우입니다. 모델은 내 머릿속을 볼 수 없고, 책상 위에 올려준 것만 봅니다.
- "자료 안에서만 답하라"는 제약의 근거는 3.4 환각입니다. 확률표의 후보 범위를 좁히는 장치입니다.
- E(형식)를 반드시 지정하라는 이유는 3.1 다음 토큰 예측입니다. 형식을 안 주면 모델은 학습 데이터에서 가장 흔했던 형식으로 이어 씁니다 — AI가 쓴 글이 서로 비슷한 까닭입니다.
5.3 같은 요청, 네 칸을 채우기 전과 후
지난달 품질 데이터 분석해줘
[R] 너는 제조 품질기술팀에서 15년간 불량 원인 분석을 해온 엔지니어다.
[A] 아래 생산일보에서 반복되는 결함 유형 3가지를 뽑고,
각각에 대해 가능한 원인을 우선순위 순으로 제시하라.
[C] - 대상: 3라인 도금 공정
- 기간: 2026년 5월 ~ 7월
- 제약: 아래 표에 있는 내용만 근거로 사용할 것.
표에 없는 사실은 추정하지 말고 "자료에 없음"이라 표기할 것.
- 참고: 4월에 라인 속도를 상향 조정한 이력이 있음
[여기에 표 붙여넣기]
[E] - 형식: 결함 유형별 표 1개(유형 / 발생 건수 / 추정 원인 / 근거 행)
+ 3문장 요약
- 읽는 사람: 품질기술팀장. 전문용어는 쓰되 과도한 축약어는 피할 것
- 마지막에 "추가로 확인이 필요한 데이터" 항목을 붙일 것
차이는 문장 실력이 아닙니다. 넣은 재료의 양과 종류입니다. 오전에 배운 대로, 모델은 고정되어 있고 달라진 것은 입력뿐입니다.
5.4 복사해서 쓰는 템플릿
매번 처음부터 쓰지 않습니다. 자주 하는 일 서너 개를 템플릿으로 만들어 두고 대괄호만 바꿔 쓰는 방식이 실제로 시간을 아낍니다.
너는 [직무]의 실무자다. 아래 [문서 종류]를 읽고, [읽는 사람]이 [상황]에서 판단하는 데 필요한 내용만 뽑아 정리하라. [자료 붙여넣기] 형식: 1) 핵심 결론 3줄 2) 결정이 필요한 사항 (있다면) 3) 숫자·날짜는 원문 그대로 표기 4) 자료에 없는 내용은 쓰지 말고, 판단에 필요한데 빠진 정보가 있으면 마지막에 "확인 필요" 목록으로 별도 표기
너는 [조직/직무]에서 [수신자]에게 글을 쓰는 담당자다. 목적은 [무엇을 얻어내는 것]이다. 배경: [알아야 할 상황 3~5줄] 반드시 포함: [항목들] 피할 것: [단정적 표현 / 특정 표현 / 길이] 형식: [분량], [문체 — 예: 간결한 존댓말, 두괄식] 먼저 초안을 쓰고, 그 아래에 "다르게 쓸 수 있는 첫 문장" 2개를 덧붙여라.
아래 글은 내가 [목적]으로 쓴 것이다. [읽는 사람]의 입장에서 읽고, 반박하거나 되물을 만한 지점을 지적하라. 칭찬은 생략하고 다음만 답하라: 1) 근거가 약한 주장 — 어느 문장인지 인용하며 2) 읽는 사람이 던질 법한 질문 3개 3) 빠져 있는 관점 1가지 [글 붙여넣기]
5.5 한 번에 끝내지 않는다
좋은 프롬프트는 처음부터 완성되지 않습니다. 첫 결과는 재료를 확인하는 용도로 쓰고, 어긋난 지점을 프롬프트에 반영해 다시 돌립니다. 실무에서 효율이 좋은 순서는 대체로 이렇습니다.
- 짧게 던져 본다 — 모델이 이 주제를 어느 정도 다루는지 확인
- 어긋난 지점을 특정한다 — "길다", "일반론이다", "내 상황이 아니다" 중 무엇인가
- 그에 해당하는 칸을 보강한다 — 길면 E, 일반론이면 R과 C, 상황이 다르면 C
- 잘 나온 프롬프트는 저장한다 — 이것이 5.4의 템플릿이 됩니다
실습 카드
내 업무에서 한 달에 세 번 이상 반복하는 일 하나를 고릅니다. 그 일을 RACE 네 칸으로 적어 템플릿을 만들고, 실제로 한 번 돌려 결과를 확인합니다. 대괄호는 남겨둔 채로 저장합니다.
6장이미지 — 일관성을 자산으로 만들기
이 장이 대응하는 성질
3.1 — 생성은 확률적입니다. 같은 프롬프트를 두 번 넣으면 두 개의 다른 결과가 나옵니다. 그리고 2.5 — 모델이 어떤 특징을 잡았는지 알 수 없습니다. 이 둘이 합쳐지면 말로는 일관성을 만들 수 없다는 결론이 나옵니다.
6.1 왜 같은 인물이 매번 다르게 나오는가
"단발머리 20대 여성, 남색 작업복"이라고 아무리 자세히 써도, 두 번째 이미지의 인물은 첫 번째와 다른 사람이 됩니다. 프롬프트를 더 길게 쓴다고 해결되지 않습니다. 원인이 문장의 부족함이 아니기 때문입니다.
모델은 매번 확률표에서 새로 뽑습니다. 그리고 "이 사람"이라는 개념을 파라미터에 저장하지 않습니다(2.2). 그러니 해법은 말을 더 잘 쓰는 것이 아니라, 말이 아닌 것을 근거로 주는 것입니다.
6.2 캐릭터 시트
캐릭터 시트(character sheet)는 애니메이션·게임 제작 현장에서 쓰이던 개념입니다. 한 인물을 여러 각도·표정·의상으로 한 장에 모아 둔 참조판으로, 여러 사람이 같은 캐릭터를 그려도 같아 보이게 하려고 만듭니다. 실습에서 만든 판이 이것입니다.
사람 여럿이 그리든 모델이 여러 번 그리든 문제의 구조는 같습니다. 기준이 되는 판이 있으면 결과가 수렴합니다.
시트에 반드시 들어가야 할 것
- 불변 요소 — 나이대·머리 모양과 색·눈 색·체형·의상·소지품. 여기서 애매하게 두면 뒤에서 전부 흔들립니다.
- 각도 — 정면 / 측면 / 후면. 영상에서 인물이 돌아설 때 필요합니다.
- 표정 — 최소 3종. 장면마다 감정이 다르기 때문입니다.
- 스타일 — 실사 / 일러스트 / 3D 등. 시트 단계에서 한 번에 못 박습니다. 이후 모든 장면이 이 판을 따라갑니다.
- 배경 없음 — 흰 배경 또는 단색. 배경이 있으면 나중에 재사용할 때 방해가 됩니다.
하나의 캐릭터 시트를 만들어라. 동일 인물이 반복 등장해야 한다. [인물] - 20대 후반 한국인 여성, 검정 단발, 갈색 눈, 보통 체형 - 남색 작업복, 오른쪽 가슴에 노란 명찰, 안전화 - 표정 기본값: 차분함 [구성] - 상단: 전신 3방향 (정면 / 측면 / 후면), 동일 인물, 동일 비율 - 하단: 상반신 표정 3종 (무표정 / 옅은 미소 / 놀람) [스타일] - 반실사 일러스트, 부드러운 명암, 과장 없는 비율 - 흰 배경, 그림자 없음, 균등 간격 배치 - 텍스트·워터마크 넣지 말 것
한 걸음 더 · 시트를 만든 뒤에 하는 일
시트가 나왔다고 끝이 아닙니다. 이후 장면을 만들 때 그 이미지를 참조로 함께 넣어야 효과가 납니다. 이미지 생성·편집 기능(Gemini의 이미지 모델 등)은 참조 이미지를 받아 같은 인물을 유지한 채 상황만 바꾸는 방식을 지원합니다. 시트는 보관용 그림이 아니라 매 장면에 다시 물리는 재료입니다.
시트를 검수하는 기준
다음 세 가지가 어긋나 있으면 시트 단계로 돌아가는 편이 결국 빠릅니다. 어긋난 시트로 장면을 만들면 뒤에서 전부 다시 해야 하기 때문입니다.
- 세 각도의 인물이 같은 사람으로 보이는가 — 특히 얼굴형과 머리 길이
- 의상의 색과 디테일이 일치하는가 — 명찰 위치, 단추 개수 같은 것이 잘 흔들립니다
- 배경·조명이 중립적인가 — 특정 조명이 박혀 있으면 다른 장면에 붙이기 어렵습니다
7장영상 — 재사용 자산을 태우는 생산 라인
이 장이 대응하는 성질
3.1 확률적 생성과 3.3 한 번에 처리할 양의 한계가 동시에 걸리는 영역입니다. 긴 영상은 한 번에 나오지 않고, 나온 것끼리도 서로 다릅니다.
7.1 관점을 바꾸는 한 문장
재사용 자산을 태우는 생산 라인을 만드는 것이 요점이다.
AI로 영상을 만드는 일은 "한 번 잘 물어보기"가 아닙니다. 앞 공정의 산출물이 뒤 공정의 입력이 되는 라인을 짜는 일입니다.
차이는 실패했을 때 드러납니다. 단발 요청으로 생각하면 결과가 나쁠 때 프롬프트를 고쳐 다시 던집니다. 라인으로 생각하면 어느 공정에서 어긋났는지를 먼저 찾습니다. 후자가 훨씬 빠르게 수렴합니다.
7.2 장면 프롬프트의 구성 요소
②단계에서 쓰는 장면 프롬프트는 문장력보다 빠뜨리지 않는 것이 중요합니다. 여섯 칸으로 나눠 생각하면 놓치지 않습니다.
| 칸 | 지정할 것 | 예 |
|---|---|---|
| 피사체 | 누가 / 무엇이 — 시트를 참조로 첨부 | 첨부한 시트의 인물 |
| 동작 | 하나의 동작만. 여러 개를 넣으면 뭉개진다 | 천천히 고개를 들어 정면을 본다 |
| 카메라 | 거리 · 각도 · 움직임 | 미디엄 샷, 눈높이, 아주 천천히 밀어 들어감 |
| 공간 | 장소 · 시간대 | 야간 공장 내부, 설비 사이 통로 |
| 조명 · 톤 | 광원 · 색감 · 분위기 | 천장 형광등, 차가운 색, 낮은 대비 |
| 길이 · 마무리 | 몇 초, 어떤 상태로 끝나는지 | 5초, 마지막에 인물이 멈춘 상태 |
한 걸음 더 · Flow라는 작업대
Flow는 Google의 AI 영상 제작 도구로, 위 ②③④를 한 화면에서 다루도록 만든 작업대입니다. 참조 이미지(재료)를 넣어 장면을 만들고, 카메라 움직임을 지정하고, 만든 클립을 이어서 다음 장면으로 확장하는 흐름을 지원합니다.
눈여겨볼 것은 버튼 위치가 아니라, 도구 자체가 "장면 단위 관리"를 전제로 설계돼 있다는 사실입니다. 라인으로 일하는 것은 예외적인 요령이 아니라 표준 작업 방식입니다.
7.3 잘 안 될 때의 진단표
영상 작업에서 시간을 가장 많이 잡아먹는 것은 생성 시간이 아니라 어디를 고쳐야 할지 몰라 같은 자리를 맴도는 시간입니다. 증상별로 손댈 공정을 미리 정해 두면 이 낭비가 크게 줄어듭니다.
| 증상 | 원인 | 고칠 공정 |
|---|---|---|
| 컷마다 얼굴이 다르다 | 참조 자산이 안 물렸거나 시트 자체가 모호 | ① 시트 — 프롬프트를 고쳐도 해결되지 않는다 |
| 동작이 어색하다 | 한 컷에 동작을 여러 개 넣었다 | ② 장면 — 동작을 하나로 줄이고 컷을 나눈다 |
| 분위기가 안 맞는다 | 조명·색감을 지정하지 않았다 | ② 장면 — 조명·톤 칸을 채운다 |
| 컷은 좋은데 이어지지 않는다 | 카메라 방향·시선이 컷마다 다르다 | ② + ④ — 방향을 통일하거나 순서를 바꾼다 |
| 긴 장면이 안 나온다 | 한 번에 만들 수 있는 길이에 한계가 있다 | ③ — 짧게 나눠 뽑고 ④에서 잇는다 |
| 계속 비슷하게 실패한다 | 같은 프롬프트를 반복하고 있다 | ①로 돌아간다 — 재료를 바꾸지 않으면 결과도 안 바뀐다 |
기억할 것
여러 번 뽑아 고르는 것은 실패가 아니라 정상 공정입니다. 확률적으로 생성되는 이상 첫 결과가 최선일 이유가 없습니다. 전문가와 초보의 차이는 한 번에 뽑는 능력이 아니라, 몇 번 뽑고 언제 앞 공정으로 돌아갈지 아는 판단에 있습니다.
8장리서치를 산출물로 — 딥리서치에서 대시보드까지
이 장이 대응하는 성질
2.2 — 모델의 지식에는 마감일이 있다와 3.4 — 환각은 구조적입니다. 이 둘을 동시에 다루는 방법이 근거를 붙이는 것이고, 그것을 자동화한 것이 딥리서치입니다.
8.1 딥리서치의 정체
딥리서치(Deep Research)는 주제를 던지면 스스로 검색 계획을 세우고, 여러 출처를 찾아 읽고, 정리된 보고서를 만들어 주는 기능입니다. 몇 분이 걸리며, 그동안 수십 개의 페이지를 훑습니다.
구조적으로 보면 이것은 4장에서 배운 RAG를 자동화한 것입니다. 검색해서 근거를 모으고, 컨텍스트에 넣고, 그것을 바탕으로 글을 씁니다. 그래서 RAG의 성질을 그대로 물려받습니다.
딥리서치 결과를 대하는 올바른 자세
딥리서치의 결론은 "답"이 아니라 "근거 묶음"입니다. 찾아온 문서가 부실하면 결론도 부실합니다. 그리고 3.4에서 본 대로, 근거를 붙였다고 해서 글을 만들어내는 방식이 바뀐 것은 아닙니다 — 출처를 잘못 요약하거나 엉뚱하게 연결하는 일은 여전히 생깁니다.
8.2 리서치를 산출물로 바꾸는 3단계
1단계 — 주제를 좁혀 던진다
"AI 동향 조사해줘"는 백과사전이 돌아옵니다. 리서치는 질문이 좁을수록 쓸모 있어집니다. 리서치 계획이 제시되면 그대로 실행하지 말고 범위·기간·관점을 손보고 시작합니다.
[대상]에 대해 [기간] 동안의 [무엇]을 조사하라. - 목적: [이 조사 결과로 내가 내려야 할 판단] - 관점: [비용 / 도입 난이도 / 규제 / 경쟁사 등 축을 명시] - 범위에서 제외: [불필요한 영역] - 출처 조건: [공식 문서·통계 우선 / 블로그 제외 등] - 결과에 반드시 포함: 각 주장마다 출처 링크, 상충되는 견해가 있으면 함께
2단계 — 출처를 직접 눌러 본다
여기가 실무에서 가장 자주 생략되고 가장 비싸게 물리는 단계입니다. 이 단계를 건너뛰면 그 뒤에 만드는 인포그래픽·대시보드·보고서가 전부 같은 오류를 물려받습니다. 최소한 다음 세 가지는 확인합니다.
- 수치 — 인용된 숫자가 원문에 그대로 있는가. 단위와 기준연도가 맞는가
- 시점 — 오래된 자료를 현재형으로 쓰고 있지는 않은가
- 연결 — A라는 출처에서 나온 근거가 B라는 주장에 잘못 붙어 있지는 않은가
3단계 — 시각 산출물로 변환한다
검증을 마친 내용을 인포그래픽이나 대시보드 형태로 바꿉니다. Gemini의 Canvas 같은 작업 공간에서는 정리된 내용을 한 장 이미지나 웹 페이지 형태로 재구성할 수 있습니다.
자주 혼동하는 지점
시각화는 내용을 좋게 만들지 않습니다. 근거가 약한 결론을 예쁜 대시보드로 만들면, 약한 결론이 설득력만 얻은 채 조직에 퍼집니다. 시각화는 검증이 끝난 뒤에 하는 마지막 공정입니다.
무엇을 대시보드로 만들 가치가 있는가
| 만들 가치가 있다 | 문서로 충분하다 |
|---|---|
| 여러 사람이 반복해서 볼 것 | 한 번 읽고 끝나는 것 |
| 숫자가 주기적으로 갱신되는 것 | 고정된 사실 정리 |
| 항목 간 비교·추이가 핵심인 것 | 서술과 논리가 핵심인 것 |
| 회의에서 같이 보며 논의할 것 | 혼자 검토하는 것 |
9장NotebookLM — 내 자료 안에서만 답하는 AI
이 장이 대응하는 성질
2.2 — 모델은 우리 회사를 모릅니다. 4장에서 배운 RAG가 완제품 형태로 구현된 것이 NotebookLM입니다. 오전 이론이 그대로 도구가 된 사례라서, 개념과 사용법을 함께 익히기 좋습니다.
9.1 일반 챗봇과 갈리는 한 가지
NotebookLM은 내가 올린 소스(PDF·문서·링크·영상 등)에 근거해서만 답합니다. 답변마다 원문의 어느 부분에서 나왔는지 인용 표시가 붙습니다.
기능 목록이 아니라 이 제약이 본체입니다. 일반 챗봇은 세상 전체를 배경으로 답하기 때문에 그럴듯한 일반론이 섞여 들어옵니다. NotebookLM은 내가 정한 자료 밖으로 나가지 않습니다. 사내 규격서·회의록·계약서처럼 정확성이 중요한 자료를 다룰 때 씁니다.
| 일반 챗봇 (Gemini 등) | NotebookLM | |
|---|---|---|
| 근거 범위 | 학습된 지식 + 검색 | 내가 올린 소스만 |
| 출처 | 있을 때도, 없을 때도 | 답변마다 인용 표시 |
| 잘하는 일 | 발상 · 초안 · 폭넓은 조언 | 정확한 확인 · 요약 · 근거 찾기 |
| 이럴 때 쓴다 | "어떻게 접근하면 좋을까" | "이 문서에 뭐라고 쓰여 있지" |
9.2 소스 설계 — 무엇을 넣고 무엇을 빼는가
NotebookLM의 품질은 소스를 고르는 단계에서 거의 결정됩니다. 자료를 많이 넣을수록 좋은 것이 아닙니다.
- 하나의 주제로 묶는다 — 노트북 하나에 여러 프로젝트를 섞으면 답이 흐려집니다. 프로젝트당 노트북 하나가 기본입니다.
- 버전이 다른 문서를 함께 넣지 않는다 — 구버전과 신버전이 섞이면 모델이 어느 쪽을 근거로 삼을지 알 수 없습니다.
- 스캔 이미지는 주의한다 — 글자를 인식하지 못하면 그 자료는 사실상 비어 있는 것과 같습니다.
- 넣은 자료 목록을 스스로 기억한다 — "이 답이 어느 문서에서 왔는지"를 판단하려면 무엇을 넣었는지 알고 있어야 합니다.
9.3 출력 형태 — 같은 근거에서 나오는 여러 벌의 옷
NotebookLM은 정리된 내용을 여러 형태로 내보냅니다. 형태가 달라져도 근거는 같은 소스입니다.
| 형태 | 이럴 때 쓴다 |
|---|---|
| 요약 · 보고서 | 여러 문서를 한 편의 정리문으로. 회의 전 사전 브리핑 |
| 슬라이드 | 자료를 발표 구조로 재배열. 초안 잡기에 강하다 |
| 오디오 개요 | 대담 형식 음성. 이동 중에 자료를 훑을 때 |
| 인포그래픽 | 구조를 한 장으로 보여줘야 할 때 |
| 마인드맵 | 자료 전체의 구조를 파악할 때 |
| 질의응답 | "이 내용이 어느 문서에 있더라"를 찾을 때 — 가장 자주 쓰게 된다 |
실습 카드
내 업무 문서 3~5개를 하나의 주제로 묶어 노트북을 만듭니다. 그런 다음 내가 답을 이미 알고 있는 질문부터 던져 봅니다. 인용 표시를 눌러 원문과 대조하고 어긋나는 곳이 있는지 확인합니다. 도구를 신뢰할 수 있는 범위를 스스로 측정하는 과정이며 이 과정을 거친 사람만이 실제 업무에 안심하고 쓸 수 있습니다.
3 부
종합 — 오늘을 하나로
흩어진 아홉 개의 장을 하나의 구조로 묶고, 스스로 점검한 뒤, 내 업무로 가져갑니다.
10장이론과 실습의 연결
오늘 배운 것을 하나의 표로 압축하면 이렇게 됩니다. 왼쪽을 모르면 오른쪽은 그때그때 통하는 잔기술로 남습니다.
| 오전에 배운 성질 | 그래서 오후에 | 구체적 동작 |
|---|---|---|
| 파라미터는 고정 대화는 학습이 아니다 | 바꿀 수 있는 것은 입력뿐 | RACE 네 칸으로 입력을 설계하고 템플릿으로 저장 (5장) |
| 컨텍스트 윈도우 = 책상 크기 | 맥락을 충분히, 그러나 정리해서 올린다 | C를 길게 · 주제 바뀌면 새 대화 · 중요 지시는 끝에 다시 (5장) |
| 확률적 생성 같은 입력 ≠ 같은 출력 | 일관성은 말이 아니라 자산으로 확보 | 캐릭터 시트를 만들고 모든 장면에 다시 물린다 (6장) |
| 딥러닝은 특징을 스스로 찾는다 | 모호한 스타일 지시가 통하지만 통제는 어렵다 | 스타일을 시트 단계에서 못 박고, 여러 번 뽑아 고른다 (6·7장) |
| 한 번에 처리할 양에 한계가 있다 | 긴 결과물은 공정으로 나눈다 | 컷 단위로 짧게 생성하고 편집에서 잇는다 (7장) |
| 확률로 답하는 기계에는 "모른다"는 자리가 없다 | 목록에 없는 것도 목록 안에서 고른다 | 분류에는 "판정 불가" 칸을, 답변에는 범위 제한을 둔다 (2.3·3.1·3.4) |
| 환각은 구조적 성질 | 없애는 것이 아니라 걸러지는 방식을 만든다 | 범위 제한 · 근거 요구 · 출처 직접 확인 (8장) |
| RAG = 근거를 책상에 올려주는 것 | 내 자료 안에서만 답하게 한다 | Gems에 지시문과 파일을 고정하고 (4.3), NotebookLM에 소스를 묶어 인용을 대조 (9장) |
| MCP = 도구 연결 표준 | 오늘은 사람이 손으로 도구를 이었다 | 딥리서치 → Canvas → NotebookLM 수동 연결. 그 이음새를 자동화하는 것이 MCP의 방향 |
| 토큰 단위 처리 | 길이와 비용에 감각을 갖는다 | 긴 자료는 필요한 부분만 잘라 넣는다 (5·9장) |
10.1 오늘 만든 것들이 이어지는 방식
각 실습의 산출물은 그 자리에서 끝나지 않습니다. 서로 다음 공정의 재료가 됩니다 — 7장에서 배운 생산 라인의 사고방식이 하루 전체에도 그대로 적용됩니다.
11장용어 사전
2일차 이후에도 계속 나오는 말들. 한 줄 정의와 함께, 헷갈리기 쉬운 지점을 붙여 둡니다.
| 용어 | 한 줄 정의 | 붙잡아 둘 것 |
|---|---|---|
| 인공지능 (AI) | 인간의 지능적 행동을 기계로 재현하려는 분야 전체 | 가장 넓은 우산. 규칙 기반 시스템도 포함 |
| 머신러닝 | 규칙을 사람이 짜지 않고 데이터에서 배우게 하는 방법 | AI의 부분집합 |
| 딥러닝 | 층을 깊게 쌓아 특징까지 스스로 학습하는 모델 구조 | 학습 방법이 아니라 구조 축. 지도·강화학습과 조합된다 |
| 파라미터 | 학습 결과가 저장되는 숫자들 (가중치 · 편향) | 대화로는 바뀌지 않는다 |
| 지도학습 | 입력과 정답을 짝지어 학습 | 라벨링 비용이 든다 |
| 클래스 | 모델이 고를 수 있는 답의 목록 | 목록에 없는 답은 낼 수 없다. "판정 불가" 칸을 두는 이유 |
| 라벨 | 예시 하나하나에 붙인 정답 | 기준이 흔들리면 모델이 규칙을 못 찾는다 |
| 비지도학습 | 정답 없이 구조·군집을 찾는 학습 | 결과 해석은 사람 몫 |
| 강화학습 | 보상·벌점으로 전략을 익히는 학습 | 시뮬레이션 환경이 필요 |
| 자기지도학습 | 정답을 데이터 자체에서 만들어 학습 | LLM 사전학습의 원리. 라벨링 비용이 0 |
| 생성형 AI | 분류·예측이 아니라 새 콘텐츠를 만드는 AI | 이미지·음성·영상도 포함 |
| LLM | 다음 토큰을 확률로 예측하도록 훈련된 거대 언어 모델 | 지식 저장소가 아니라 패턴 예측기 |
| 토큰 | 모델이 텍스트를 자르는 단위 | 한국어가 더 많이 소모한다 |
| 컨텍스트 윈도우 | 한 번에 처리 가능한 토큰 총량 (입력+출력) | 기억력이 아니라 책상 크기 |
| 환각 | 사실 아닌 내용을 사실처럼 생성하는 현상 | 고장이 아니라 구조적 성질 |
| 온도 | 확률표에서 얼마나 과감하게 뽑을지 정하는 값 | 낮추면 안정되고 밋밋해진다. 결과 편차는 고장이 아니라 설정 |
| 프롬프트 | 모델에 넘기는 입력 전체 (지시 + 맥락 + 자료) | "질문"보다 넓은 개념 |
| RAG | 관련 문서를 찾아 프롬프트에 넣고 답하게 하는 기법 | 재학습이 아니다. 입력만 바뀐다 |
| Gem | 지시문과 참고 파일을 고정해 둔 맞춤 어시스턴트 | 학습이 아니라 책상을 미리 차려두는 것. 파일을 바꾸면 즉시 반영 |
| 청크 (조각) | 검색을 위해 문서를 잘라 둔 단위 | 모델은 문서 전체가 아니라 찾아온 몇 조각만 본다 |
| MCP | AI를 외부 도구·데이터에 잇는 개방형 표준 규격 | RAG가 읽기라면 MCP는 읽기 + 행동 |
| 파인튜닝 | 파라미터를 추가 학습으로 조정하는 것 | 형식·말투용. 지식 주입에는 부적합 |
| 전이학습 | 이미 학습된 모델의 앞부분을 두고 마지막 층만 새로 학습 | 적은 예시로 빠르게. "우리 데이터로 학습"이 가능한 이유 |
| 멀티모달 | 텍스트·이미지·음성·영상을 함께 다루는 능력 | 오후 실습 전체의 전제 |
| 캐릭터 시트 | 인물을 여러 각도·표정으로 정리한 참조 자산 | 일관성 확보 수단이자 재사용 재료 |
| 딥리서치 | 스스로 검색·정리해 보고서를 만드는 기능 | 자동화된 RAG. 결론이 아니라 근거 묶음 |
12장자가 점검
12.1 확인 문제
먼저 스스로 답해 본 뒤 펼쳐서 확인합니다. 답을 남에게 설명할 수 있는 수준이면 충분합니다.
딥러닝은 지도학습·비지도학습·강화학습과 나란히 놓을 수 있는가?
놓을 수 없다. 셋은 "어떻게 배우는가"에 답하는 학습 방법 축이고 딥러닝은 "무엇으로 배우는가"에 답하는 모델 구조 축이다. 두 축은 조합된다 — 딥러닝×지도학습(불량 판정), 딥러닝×강화학습(알파고), 딥러닝×자기지도학습(LLM 사전학습).
자기지도학습이 LLM을 가능하게 한 이유는?
정답을 사람이 붙이지 않고 데이터 자체에서 만들어내기 때문에 라벨링 비용이 사라진다. 그 결과 인터넷 전체를 교재로 쓸 수 있게 되었고, 학습 규모가 수천 배로 커졌다. LLM의 성능은 새 알고리즘보다 이 규모 변화에 크게 빚지고 있다.
어제 알려준 사내 규정을 모델이 오늘 기억하지 못하는 이유는?
학습이 끝난 모델의 파라미터는 고정되어 있고, 대화는 학습이 아니기 때문이다. 모델은 대화를 통해 배우지 않는다. 매번 컨텍스트에 다시 넣어주거나, RAG로 자료를 붙여줘야 한다.
긴 대화에서 초반 지시를 무시하는 현상을 어떻게 설명하겠는가?
컨텍스트 윈도우는 기억력이 아니라 한 번에 올려둘 수 있는 총량이다. 대화가 길어지면 초반 내용이 그 범위 밖으로 밀려나 더 이상 참조되지 않는다. 대응 — 주제가 바뀌면 새 대화를 열고, 중요한 지시는 지금 다시 쓰며, 긴 자료는 요약해 올린다.
"검색 기능이 붙었으니 환각은 해결된 것 아닌가?"에 어떻게 답하겠는가?
절반만 맞다. 검색은 근거를 컨텍스트에 올려주는 것이지, 확률로 다음 토큰을 이어 붙이는 생성 방식 자체를 바꾸지는 않는다. 찾아온 문서를 잘못 요약하거나, 출처와 다른 주장에 근거를 붙이는 일은 여전히 생긴다. 그래서 출처를 직접 확인하는 단계가 필요하다.
RAG와 파인튜닝 중, 사내 규정을 반영하려면 무엇을 써야 하는가?
RAG다. 파인튜닝은 말투·형식을 몸에 배게 하는 데 적합하고 지식을 주입하는 용도로는 부적합하다. 규정은 자주 바뀌는데 파인튜닝은 바뀔 때마다 다시 학습해야 하고 비용이 크다. RAG는 원본 문서를 갱신하면 즉시 반영된다.
같은 캐릭터가 매번 다르게 나온다. 프롬프트를 더 자세히 쓰면 해결되는가?
해결되지 않는다. 원인이 문장의 부족함이 아니라 생성이 확률적이고 모델이 "이 사람"을 저장하지 않기 때문이다. 해법은 말이 아닌 참조 자산(캐릭터 시트)을 매 장면에 다시 물리는 것이다.
영상의 컷마다 얼굴이 달라진다. 어디를 고쳐야 하는가?
①번 공정, 캐릭터 시트로 돌아간다. 장면 프롬프트(②)를 아무리 고쳐도 참조 자산이 흔들리면 결과는 계속 흔들린다. 라인으로 일한다는 것은 증상이 나타난 공정이 아니라 원인이 있는 공정을 고친다는 뜻이다.
딥리서치 결과를 바로 대시보드로 만들면 안 되는 이유는?
딥리서치의 결론은 답이 아니라 근거 묶음이고 출처를 잘못 요약했을 가능성이 남아 있다. 검증을 건너뛰면 오류가 그대로 시각 산출물에 실린다. 게다가 시각화된 오류는 설득력만 얻어 더 빠르게 퍼진다. 검증은 시각화 이전 공정이다.
NotebookLM을 일반 챗봇 대신 써야 하는 상황은?
답이 특정 자료 안에 있어야 하고 출처를 댈 수 있어야 하는 일. 사내 규격서 확인, 회의록 대조, 계약 조항 찾기 등이다. 반대로 발상·초안·폭넓은 조언이 필요할 때는 일반 챗봇이 낫다. 판단 기준은 "세상 전체를 배경으로 답해도 되는가"이다.
"정상 / 불량" 두 클래스로 배운 모델에 처음 보는 이물질 사진을 보여주면 어떻게 되는가?
둘 중 하나를 확률까지 붙여 자신 있게 고른다. 목록에 없는 답은 모델이 낼 수 없기 때문이다. 모델에게는 "목록에 없다"고 말할 방법이 자체가 없다. 그래서 현장용 분류 모델에는 "판정 불가" 칸을 하나 더 두고 그 칸에 떨어진 것을 사람에게 넘긴다. 클래스 목록을 짜는 일은 기술 작업이 아니라 업무 설계다.
표를 붙여 넣고 "합계를 구해줘"라고 하면 왜 위험한가?
모델은 덧셈을 하지 않고 덧셈의 결과로 그럴듯한 숫자를 이어 쓴다. 자릿수가 비슷해서 대체로 맞아 보이고 가끔 틀리는데, 무엇보다 과정이 남지 않아 검산할 수 없다. 숫자 계산은 수식에 맡기고, 모델에게는 어떤 수식을 쓰면 되는지를 묻는 편이 안전하다.
예시 수십 장으로 몇 분 만에 학습이 끝나는 일이 어떻게 가능한가?
전이학습 덕분이다. 앞쪽 층이 잡는 선·모서리·질감은 어떤 이미지에나 공통이라 다시 배울 이유가 없다. 이미 학습된 모델의 앞부분은 그대로 두고 마지막 판단 층만 새로 학습시킨다. "우리 회사 데이터로 AI를 학습시킨다"는 말이 현실적으로 가능한 이유가 대부분 여기에 있다.
RAG에 넣을 자료를 미리 정리해 두어야 하는 이유는?
RAG는 문서를 통째로 넣지 않고 조각으로 잘라 두었다가 관련 있는 몇 조각만 골라 쓰기 때문이다. 소제목 없이 길게 이어진 글은 엉뚱한 자리에서 잘려 문맥이 끊긴 조각이 된다. 특히 수치는 기준과 한 문장 안에 있어야 한다 — "431억 원"만 담긴 조각은 무엇의 431억인지 알 수 없는 채로 답변에 실린다.
AI에 맡길 일과 맡기지 않을 일을 가르는 기준은 무엇인가?
도구의 성능이 아니라 틀렸을 때 누가 어떻게 알아채는가로 가른다. 틀리면 내가 바로 알고, 결과를 내가 다시 손보고, 되돌릴 수 있는 일은 맡겨도 된다. 반대로 틀려도 티가 안 나고(수치·날짜·법규), 결과가 그대로 나가고(대외 문서), 되돌릴 수 없는(발송·계약) 일은 사람의 확인을 공정에 넣는다.
Gem을 만들었다면 이제 그 모델이 우리 회사를 알게 된 것인가?
아니다. 파라미터는 조금도 바뀌지 않았다. 달라진 것은 매 대화마다 같은 지시문과 같은 파일이 자동으로 컨텍스트에 올라간다는 것뿐이다. 그래서 어제 대화에서 알려준 새 규정은 오늘 사라지고, 반영하려면 파일을 고쳐 다시 올려야 한다. 대신 파일만 바꾸면 재학습 없이 즉시 반영된다 — RAG의 성질 그대로다.
12.2 이해 체크리스트
설명할 수 있으면 체크합니다. 체크 상태는 이 브라우저에 저장됩니다.
원리 (1부)
실천 (2부)
적용
13장업무 적용 과제 · 2일차로
13.1 오늘 안에 해두면 좋은 것
- 템플릿 하나를 완성한다 — 5.4의 형식으로, 내가 자주 하는 일 하나. 대괄호를 남긴 채 저장합니다. 매주 반복하는 일이라면 4.3의 Gem으로 굳혀 둡니다.
- 노트북 하나를 만든다 — 업무 문서 3~5개. 답을 아는 질문으로 신뢰 범위를 확인합니다.
- 산출물을 한 폴더에 모은다 — 시트·영상·리서치·노트북 링크. 7장에서 배운 대로, 오늘의 산출물이 내일의 재료입니다.
- 맡기지 않을 일을 적는다 — AI를 잘 쓰는 능력에는 쓰지 않을 곳을 정하는 판단이 포함됩니다.
13.2 2일차로 넘어가며
오늘 우리는 이미 만들어진 모델에 무엇을 넣을지 궁리했습니다. 내일은 서 있는 자리가 두 번 바뀝니다. 오전에는 모델을 만드는 쪽에 서서 직접 학습을 시켜 보고, 오후에는 재료가 문서와 이미지에서 숫자와 데이터로 바뀝니다. 둘 다 오늘의 요령이 그대로 통하지 않는 자리입니다.
미리 생각해두면 좋을 질문 네 가지를 남깁니다. 답을 지금 알아야 하는 것은 아니고, 내일 그 답을 만나는 순간을 알아차리기 위한 질문입니다.
2일차를 위한 질문
- 오늘 우리는 남이 만든 모델을 썼습니다. 그 모델은 애초에 어떻게 만들어지는가? — 2.2의 "학습이 끝나면 고정된다"를 거꾸로 읽어보면 실마리가 있습니다. 고정되기 전에는 무언가가 모델을 정하고 있었다는 뜻입니다. 그 무언가를 내일 직접 다뤄봅니다.
- LLM은 계산기가 아닙니다. 그런데 표를 주면 왜 그럴듯한 숫자를 말할까? — 3.1의 "확률로 이어 쓴다"를 숫자에 적용해보면 답이 보입니다. 이것이 데이터 작업에서 가장 조심할 지점입니다.
- 내 손에 있는 실제 업무 데이터에서, AI에게 줘도 되는 것과 주면 안 되는 것의 경계는 어디인가?
- 데이터가 이미 틀려 있다면, 아무리 좋은 모델도 무엇을 할 수 있을까?
여는 장오늘 하루의 지도
어제는 남이 만든 모델에 무엇을 넣을지 배웠습니다. 오늘은 넣을 것 자체를 만든다 — 학습 데이터, 정제된 표, 지식 베이스. 도구는 일곱 개로 흩어지지만 하는 일은 하나입니다.
오늘 하루를 관통하는 한 문장
오늘 만든 것을 순서대로 늘어놓으면 서로 상관없어 보입니다. 티처블머신으로 자세를 배우는 모델, 스프레드시트에서 정리한 출하 데이터, 회사 소개를 답해주는 챗봇. 도구도 다르고 결과물도 다릅니다. 그런데 세 번 다 같은 일을 했습니다.
어제 배운 것이 오늘의 질문이 된다
1일차의 "모델은 고정되어 있고, 우리가 바꿀 수 있는 것은 입력뿐"이라는 문장을 그대로 밀고 가면 오늘의 질문들이 나옵니다.
| 1일차에 배운 것 | 남는 질문 | 오늘의 실습 |
|---|---|---|
| 모델은 학습이 끝나면 고정된다1일차 2.2 | 그러면 그 모델은 애초에 어디서 오는가 | 직접 만들어 본다 — 예시를 주면 모델이 나온다 (1·2·3장) |
| 모델을 내려받는다 = 숫자 묶음을 받는다1일차 2.1 | 내가 만든 모델은 어떻게 남에게 건네는가 | 링크로 내보내고, 앱이 그것을 불러 쓴다 (4장) |
| LLM은 확률로 다음 조각을 이어 쓴다1일차 3.1 | 그런데 표를 주면 왜 그럴듯한 숫자를 말하는가 | 계산은 수식에게, 판단은 모델에게 (5장) |
| 환각은 고장이 아니라 구조적 성질1일차 3.4 | 데이터가 이미 틀려 있다면 무엇을 할 수 있는가 | 정제가 분석보다 먼저다 (6·10장) |
| 시각화는 검증이 끝난 뒤의 공정1일차 8장 | 대시보드는 무엇에 답하는 물건인가 | 차트 모음이 아니라 질문 목록으로 설계한다 (8·9장) |
| RAG = 근거를 책상에 올려주는 것1일차 4.1 | 내가 아니라 남이 묻게 하려면 무엇이 달라지는가 | 지식 베이스의 경계를 먼저 그린다 (14장) |
왼쪽 칸은 전부 어제 배운 것이다. 오늘 배우는 것은 오른쪽 칸이다. 15장에서 이 표를 다시 만난다.
왜 이 순서인가
오전에 모델을 직접 만드는 것부터 시작하는 데는 이유가 있습니다. 어제 하루 종일 "모델은 고정되어 있다"는 말을 들었지만 그 말은 남이 만든 모델을 쓰는 사람의 관점입니다. 직접 학습을 한 번 시켜 보면 그 문장의 반대편이 보입니다 — 고정되기 전에는, 내가 준 예시가 모델을 결정합니다. 이 감각이 있어야 오후의 데이터 작업이 "표 정리"가 아니라 "재료 준비"로 읽힙니다.
그리고 오후의 순서는 재료가 무거워지는 순서입니다. 사진 몇 장(오전) → 100행짜리 표(대시보드) → 60행 13열의 오염된 원본(최종 실습) → 문서 한 편(챗봇). 뒤로 갈수록 내가 판단해야 할 것이 늘어납니다. 사진은 찍으면 되지만, 표기가 열일곱 가지로 흩어진 열을 어떻게 묶을지는 사람이 정해야 합니다.
1일차 13.2가 남긴 세 가지 질문
어제 교재는 세 개의 질문을 남기고 끝났습니다. 오늘 그 셋에 각각 답합니다. 지금 읽어두고, 하루가 끝난 뒤 15.3에서 다시 확인합니다.
- LLM은 계산기가 아닌데 표를 주면 왜 숫자를 말할까 → 5장
- AI에게 줘도 되는 것과 주면 안 되는 것의 경계는 → 12장(공개 배포)·14장(지식 베이스)
- 데이터가 이미 틀려 있다면 좋은 모델도 무엇을 할 수 있을까 → 6장·10장
1 부
모델을 만든다 — 내가 준 예시가 모델이 된다
오전. 어제 이론으로 들은 "학습"을 손으로 한 번 돌려 보고, 그 결과물을 링크로 내보내 서비스에 붙입니다.
1장기계는 예시로 배운다 — 머신러닝 다시 보기
이 장이 이어받는 것
1일차 2장 — 파라미터와 학습. 어제는 "학습이란 숫자를 고치는 일이고, 끝나면 얼어붙는다"를 설명으로 들었습니다. 오늘은 그 과정을 몇 분 안에 직접 돌립니다. 어제 이론이 오늘 조작이 되는 자리입니다.
1.1 어제의 세 문장을 손으로 확인한다
1일차 2장은 세 문장으로 요약됩니다. 오늘 오전 실습은 이 세 문장을 순서대로 눈으로 보게 만듭니다.
| 어제 들은 문장 | 오늘 눈으로 보는 곳 |
|---|---|
| 파라미터는 학습 결과가 담기는 그릇이다 | 학습이 끝나면 파일 몇 개가 떨어진다. 그 안에 든 것이 파라미터다 |
| 학습이란 오차가 줄어드는 방향으로 숫자를 고치는 일이다 | Train 버튼을 누르면 진행 표시가 반복해서 돈다. 그 반복이 "조금씩 여러 번"이다 |
| 학습이 끝나면 파라미터는 고정된다 | 학습 후에는 아무리 새 사진을 보여줘도 모델이 달라지지 않는다. 바꾸려면 다시 학습시켜야 한다 |
어제와 달라지는 것은 서 있는 자리입니다. 어제는 완성된 모델을 쓰는 사람이었고, 오늘은 그 모델을 만드는 사람 쪽에 잠깐 서 봅니다. 이 경험이 왜 필요한가 하면, 실무에서 AI 도입을 논의할 때 가장 자주 어긋나는 지점이 여기이기 때문입니다. "우리 회사 데이터로 AI를 학습시키자"는 말이 실제로 무슨 작업을 뜻하는지, 한 번 해보면 감이 잡힙니다.
1.2 지도학습의 다섯 단계
어제 2.3에서 기계가 배우는 세 가지 방법을 봤습니다. 오늘 하는 것은 그중 지도학습(supervised learning)입니다 — 입력과 정답을 짝지어 주고 맞히게 하는 방식. 실제 절차는 다섯 단계입니다.
1.3 클래스 — 모델이 볼 수 있는 세계의 전부
클래스(class)는 모델이 구분할 수 있는 답의 목록입니다. "고양이 / 강아지" 두 클래스로 학습시킨 모델은 무엇을 보여줘도 고양이 아니면 강아지라고 답합니다. 자동차 사진을 보여줘도 마찬가지입니다. "모르겠다"는 선택지가 애초에 없기 때문입니다.
분류 모델의 가장 중요한 성질
클래스에 없는 것은 모델에게 존재하지 않습니다. 모델은 "이것은 목록에 없다"고 말하지 못하고, 목록 중에서 그나마 가장 비슷한 것을 고릅니다. 그리고 확률까지 붙여서 자신 있게 답합니다.
어제 3.1에서 본 LLM의 성질과 구조가 똑같습니다. LLM에게 "모른다"는 상태가 없어서 그럴듯한 다음 토큰을 고르듯이, 분류 모델에게도 "없음"이라는 상태가 없어서 그럴듯한 클래스를 고릅니다. 확률로 답하는 기계는 전부 이 성질을 공유합니다.
그래서 실무에서 분류 모델을 설계할 때는 "기타" 또는 "해당 없음" 클래스를 하나 더 두는 것이 거의 항상 옳습니다. 불량 판정 모델이라면 "정상 / 불량"이 아니라 "정상 / 불량 / 판정 불가"로 두고, 판정 불가는 사람에게 넘깁니다. 클래스 목록을 짜는 일은 기술이 아니라 업무 설계입니다.
1.4 좋은 학습 데이터의 네 가지 조건
②단계에서 무엇을 모으느냐가 모델의 성능을 거의 결정합니다. 네 가지 축으로 점검하면 빠뜨리지 않습니다.
| 조건 | 뜻 | 부족하면 생기는 일 |
|---|---|---|
| 양QUANTITY | 클래스마다 충분한 개수 | 몇 장으로도 동작은 하지만 조금만 달라지면 흔들린다 |
| 다양성VARIETY | 각도·거리·조명·배경이 서로 다른 예시 | 학습할 때의 상황에서만 맞는 모델이 된다 |
| 균형BALANCE | 클래스 간 개수 차이가 크지 않을 것 | 많은 쪽으로 쏠려 답한다. 정확도 숫자는 오히려 높게 나온다 |
| 정답의 일관성CONSISTENCY | 같은 것에 같은 라벨이 붙어 있을 것 | 모델이 기준을 찾지 못한다. 사람도 못 맞히는 문제가 된다 |
자주 혼동하는 지점 — "데이터를 많이 모으면 좋아진다"
절반만 맞습니다. 같은 각도로 찍은 100장보다 서로 다른 각도·조명으로 찍은 20장이 낫습니다. 양이 아니라 다양성이 일반화를 만듭니다. 100장이 전부 같은 상황이면, 모델 입장에서는 사실상 한 장을 100번 본 것과 크게 다르지 않습니다.
실무로 옮기면 이렇습니다. 사내 불량 이미지를 1만 장 모았는데 전부 A라인 조명에서 찍은 것이라면, 그 모델은 B라인에서 쓸 수 없습니다. 데이터 수집 계획은 개수가 아니라 상황의 목록으로 세웁니다.
한 걸음 더 · 과적합 — 외운 것과 배운 것
과적합(overfitting)은 모델이 학습 데이터를 일반화하지 않고 외워버린 상태입니다. 학습에 쓴 사진에는 100% 맞히는데 새 사진에는 형편없이 틀립니다. 시험 범위의 문제만 통째로 외운 학생과 같습니다.
그래서 ④ 검증 단계가 존재합니다. 학습에 쓰지 않은 예시로 확인해야 외운 것인지 배운 것인지 갈라집니다. 학습에 쓴 사진으로 테스트하면 항상 잘 나오고, 그 숫자는 아무 의미가 없습니다.
업무 데이터에서도 똑같습니다. 작년 데이터로 학습하고 작년 데이터로 검증한 예측 모델은 언제나 훌륭해 보입니다. 올해 써 보기 전까지는.
한 걸음 더 · 정확도라는 숫자의 함정
"정확도 97%"는 그 자체로는 아무 정보가 없습니다. 불량률이 3%인 라인에서 전부 정상이라고 답하는 모델의 정확도가 정확히 97%다. 아무 일도 하지 않는 모델이 훌륭한 점수를 받습니다.
그래서 현장에서는 정확도 대신 어느 쪽으로 틀리는지를 봅니다. 불량을 정상이라 한 것(놓친 것)과 정상을 불량이라 한 것(과잉 검출)은 비용이 전혀 다릅니다. 전자는 고객에게 나가고, 후자는 재검사로 끝납니다. 모델을 평가할 때 던질 질문은 "몇 % 맞히나"가 아니라 "어떤 실수를 얼마나 하나, 그 실수의 값은 얼마인가"입니다.
2장이미지로 분류 모델 만들기
티처블머신은 브라우저 안에서 몇 분 만에 학습을 끝냅니다. 설치도 코드도 없습니다. 그런데 이 편리함 뒤에 무엇이 있는지 알아두면, 모델이 이상하게 굴 때 어디를 봐야 하는지가 보입니다.
2.1 티처블머신이 실제로 하는 일
티처블머신(Teachable Machine)은 Google이 만든 브라우저 기반 학습 도구입니다. 이미지·소리·자세 세 종류의 프로젝트를 지원하고 웹캠이나 파일로 예시를 모아 버튼 한 번으로 학습시킵니다.
여기서 자연스럽게 드는 의문이 있습니다. 어제 배우기로 딥러닝 학습에는 GPU와 막대한 데이터가 필요하다고 했는데, 어떻게 노트북 브라우저에서 사진 스무 장으로 몇 초 만에 끝나는가.
한 걸음 더 · 전이학습 — 처음부터 배우지 않는다
답은 처음부터 학습하지 않기 때문입니다. 티처블머신은 이미 수백만 장의 이미지로 학습된 모델을 미리 확보해 두고, 그 앞부분은 손대지 않은 채 마지막 판단 층만 새로 학습시킵니다. 이것을 전이학습(transfer learning)이라 부릅니다.
왜 이게 통하는지는 어제 2.5에서 이미 배웠습니다. 딥러닝의 앞쪽 층은 선과 모서리를, 중간 층은 부분 형태를 잡습니다. 이 능력은 고양이든 나사든 어떤 이미지에나 공통입니다. 그러니 매번 다시 배울 이유가 없습니다. 새로 배워야 하는 것은 "이 특징 조합이면 A클래스"라는 마지막 연결뿐입니다.
실무적 함의가 하나 따라 나옵니다. 전이학습은 원본 모델이 잘 보던 종류의 이미지에서 잘 통합니다. 일상 사진으로 학습된 모델을 X선 판독이나 현미경 이미지에 쓰면 효과가 떨어집니다. 그런 영역은 전용 모델이 따로 있는 이유입니다.
2.2 실습 절차
이미지 프로젝트의 흐름은 1장의 다섯 단계를 그대로 따릅니다. 화면 순서와 겹쳐 두면 이렇습니다.
| 단계 | 화면에서 하는 일 | 여기서 실제로 결정되는 것 |
|---|---|---|
| ① 클래스 정의 | Class 1, Class 2 … 이름을 바꾼다 | 이 모델이 답할 수 있는 전부. 이름은 나중 코드에서 그대로 쓰이므로 짧고 명확하게 |
| ② 예시 수집 | 웹캠 녹화 또는 파일 업로드 | 모델의 성능. 각도·거리·조명을 바꿔가며 모은다 |
| ③ 학습 | Train Model 클릭 · 탭을 닫지 않는다 | 거의 없다. 기계가 하는 부분 |
| ④ 검증 | Preview 창에 새 것을 보여준다 | 이 모델을 써도 되는가 |
| ⑤ 내보내기 | Export Model | 4장으로 이어지는 지점 |
학습 설정을 건드려야 하나
고급 설정에 Epochs(반복 횟수), Batch Size, Learning Rate가 있습니다. 대부분의 경우 건드리지 않는 편이 낫습니다. 결과가 나쁠 때 이 숫자를 조정하려는 충동이 생기지만 원인이 여기인 경우는 드물습니다. 1장 도식의 점선 화살표가 가리키는 대로, ①②로 돌아가는 것이 거의 항상 빠릅니다.
| 설정 | 뜻 | 손대는 경우 |
|---|---|---|
| Epochs | 같은 데이터를 몇 번 반복해서 볼 것인가 | 예시가 아주 적을 때 조금 늘려볼 수 있다. 늘릴수록 과적합 위험도 커진다 |
| Batch Size | 한 번에 몇 개씩 묶어 처리할 것인가 | 거의 손대지 않는다 |
| Learning Rate | 한 번에 숫자를 얼마나 크게 고칠 것인가 | 거의 손대지 않는다. 크면 널뛰고, 작으면 안 움직인다 |
2.3 일부러 실패시켜 보기 — 모델은 무엇을 배웠는가
이 실습에서 가장 배울 것이 많은 순간은 모델이 잘 될 때가 아니라 이상하게 잘 될 때입니다.
한 클래스는 책상 위에 물건을 놓고 찍고, 다른 클래스는 손에 들고 찍었다고 하자. 모델은 아주 높은 정확도를 보입니다. 그런데 물건을 치우고 빈 책상만 비춰도 첫 번째 클래스라고 답합니다. 모델이 배운 것은 물건이 아니라 배경이었습니다.
지름길 학습 — 어제 2.5의 실물
어제 이런 문장을 읽었습니다. "딥러닝은 특징을 스스로 찾습니다. 그래서 모델이 무엇을 특징으로 잡았는지 알 수 없습니다." 지금 눈앞에서 벌어진 일이 그것입니다.
모델은 클래스를 가장 쉽게 가르는 신호를 찾습니다. 그것이 물건의 형태일 필요는 없습니다. 배경 색, 조명, 그림자, 손이 화면에 있는지 — 더 쉬운 단서가 있으면 그쪽을 씁니다. 이것을 지름길 학습(shortcut learning)이라 부릅니다. 게으른 것이 아니라, 오차를 줄이는 가장 빠른 길을 택했을 뿐입니다.
이 현상이 실무에서 무섭게 나타나는 이유는 검증에서도 안 걸리기 때문입니다. 검증용 사진도 같은 방식으로 찍었다면 배경 단서가 똑같이 들어 있습니다. 시험에서 100점을 받고 현장에서 무너집니다. 대표적인 사례가 이런 것들입니다.
- 불량품 사진만 다른 조명의 검사대에서 찍혀 있었다 → 모델은 조명을 배웠습니다
- 양품은 낮에, 불량은 야간에 촬영했다 → 모델은 시간대를 배웠습니다
- 특정 클래스 사진에만 자나 라벨이 함께 찍혀 있었다 → 모델은 그 물체를 배웠습니다
실습 카드 · 일부러 무너뜨리기
학습이 끝난 모델에 다음 세 가지를 해봅니다. 하나라도 무너지면 ②단계로 돌아갑니다.
- 배경을 바꾼다 — 다른 장소, 다른 벽 앞에서 같은 대상을 보여줍니다
- 아무것도 안 보여준다 — 빈 화면일 때 어떤 클래스를 얼마의 확률로 답하는지 봅니다
- 학습에 없던 것을 보여준다 — 전혀 다른 물건을 보여줍니다. 90% 이상의 확신으로 답한다면 1.3에서 말한 성질을 눈으로 확인하게 됩니다
2.4 검증 — 무엇을 확인해야 끝난 것인가
Preview 창에서 몇 번 잘 맞았다고 검증이 끝난 것이 아닙니다. 최소한 다음 네 가지를 기록으로 남깁니다. 나중에 모델을 다시 만들 때 비교 기준이 됩니다.
| 확인 항목 | 구체적으로 |
|---|---|
| 새 예시로 맞히는가 | 학습에 쓰지 않은 것으로만 10회 이상. 여기가 유일하게 의미 있는 숫자다 |
| 애매한 것에 어떻게 답하는가 | 경계에 있는 상태를 보여줬을 때 확률이 반반으로 갈리는지, 아니면 한쪽으로 확신하는지 |
| 조건을 바꿔도 되는가 | 조명·배경·거리를 바꾼 뒤에도 유지되는가 |
| 틀릴 때 어느 쪽으로 틀리는가 | 1.4의 "정확도의 함정"에서 본 대로, 틀리는 방향이 실무에서는 더 중요하다 |
3장몸으로 만드는 모델 — 앉았다, 일어섰다
같은 티처블머신이지만 포즈 프로젝트는 이미지 프로젝트와 입력 자체가 다릅니다. 이 차이를 알고 시작하면, 왜 옷 색깔을 바꿔도 잘 맞는지가 설명됩니다.
3.1 픽셀을 보는 모델과 관절을 보는 모델
이미지 프로젝트는 화면의 픽셀을 그대로 입력으로 받습니다. 그래서 2.3에서 본 것처럼 배경이나 조명 같은 것까지 함께 배웁니다.
포즈 프로젝트는 한 단계를 먼저 거칩니다. 카메라 영상에서 사람의 관절 위치를 먼저 뽑아내고, 그 좌표 목록만 모델에 넘깁니다. 코·어깨·팔꿈치·손목·엉덩이·무릎·발목 같은 지점의 x, y 좌표와 신뢰도입니다. 화면이 아니라 막대 인간이 입력인 셈입니다.
어제 2.5와 맞물리는 지점
어제 "딥러닝 이전에는 사람이 특징(feature)을 설계해서 넣어줘야 했다"고 배웠습니다. 포즈 프로젝트는 그 옛 방식과 딥러닝을 섞어 놓은 구조입니다. "관절 좌표가 자세를 판단하는 데 중요한 특징이다"라는 사람의 설계가 앞에 들어가 있고, 그 뒤에 딥러닝이 붙습니다.
얻는 것과 잃는 것이 분명합니다. 얻는 것 — 배경·조명·옷 색에 강하고 훨씬 적은 예시로도 학습됩니다. 잃는 것 — 관절 좌표에 담기지 않는 정보는 전부 버려집니다. 표정, 손에 든 물건, 도구의 상태 같은 것은 이 모델이 절대 볼 수 없습니다. 무엇을 특징으로 삼을지 정하는 순간, 보지 못할 것도 함께 정해집니다.
3.2 문제를 어떻게 나눌 것인가 — 여기가 이 장의 핵심
"스쿼트 횟수를 세는 모델을 만든다"고 생각하면 설계가 처음부터 어긋납니다. 이유는 단순합니다.
모델이 보는 것은 지금 이 순간의 자세다.
티처블머신의 포즈 모델은 매 프레임마다 독립적으로 판단합니다. 앞 프레임에 무엇이 있었는지 모릅니다. 그러니 "스쿼트 1회"라는 개념을 모델이 알 방법이 없습니다. 모델에게 시킬 수 있는 것은 지금 서 있는가, 앉아 있는가까지입니다.
역할 분담 — 이 장에서 반드시 가져갈 것
모델은 판정하고 세는 것은 코드가 합니다.
- 모델의 일 — 지금 자세가 Up인가 Down인가, 각각 몇 %인가
- 코드의 일 — 그 판정이 Down → Up으로 바뀌는 순간을 잡아서 +1
이 분리를 못 하면 4장에서 AI Studio에게 무엇을 시켜야 할지 설명할 수 없게 됩니다. 반대로 이 분리가 되어 있으면, 요청이 아주 간단해집니다.
이 사고방식은 스쿼트에만 쓰이지 않습니다. 현장 문제로 옮기면 이렇게 대응됩니다.
| 하고 싶은 일 | 모델에게 시킬 것 (순간) | 코드가 할 일 (시간) |
|---|---|---|
| 스쿼트 카운트 | Up / Down 판정 | Down 뒤 Up이 오면 +1 |
| 안전모 미착용 적발 | 착용 / 미착용 판정 | 미착용이 3초 이상 지속되면 경보 |
| 설비 이상 감지 | 정상 / 이상 판정 | 이상 판정이 연속 5프레임이면 기록 |
| 작업 시간 측정 | 작업 중 / 대기 중 판정 | 상태가 바뀐 시각을 누적 |
오른쪽 칸은 전부 AI가 아니다. 조건문과 변수 몇 개다. AI로 풀 문제와 코드로 풀 문제를 가르는 것이 설계의 첫 단계다.
3.3 애매한 구간을 어떻게 다룰 것인가
Up과 Down 두 클래스로 학습시키면 곧바로 문제가 하나 생깁니다. 내려가는 중간 자세는 무엇인가. 1.3에서 배운 대로, 모델에게는 "중간"이라는 선택지가 없어서 억지로 둘 중 하나를 고릅니다. 그 결과 카운터가 오르내리며 한 번 앉았는데 세 번 세는 일이 생깁니다.
해법 ① — 클래스를 하나 더 둔다
Up / Down / Transition(중간) 세 클래스로 학습시킵니다. 중간 자세를 명시적으로 가르치는 방식입니다. 1.3에서 말한 "기타 클래스를 두라"는 원칙의 구체적인 적용입니다.
해법 ② — 임계값과 상태를 쓴다
모델은 항상 확률을 줍니다. Up 62% / Down 38% 같은 식입니다. 이 확률에 기준선을 긋는 것이 임계값(threshold)입니다.
한 걸음 더 · 왜 임계값이 하나가 아니라 둘이어야 하는가
임계값을 50%로 하나만 두면, 확률이 49%와 51% 사이를 오갈 때 판정이 초당 여러 번 뒤집힙니다. 카운터가 순식간에 수십으로 뜁니다.
그래서 들어가는 기준과 나오는 기준을 다르게 둡니다. 예를 들어 Down 확률이 0.9를 넘어야 "앉음" 상태로 들어가고, Up 확률이 0.9를 넘어야 "섬" 상태로 나옵니다. 그 사이 애매한 구간에서는 직전 상태를 유지합니다. 이렇게 하면 경계에서 떨리지 않습니다. 이 방식을 히스테리시스(hysteresis)라 부르고, 온도 조절기부터 공정 제어까지 어디에나 쓰입니다.
카운트는 여기서 딱 한 지점에만 올립니다 — "앉음" 상태에서 "섬" 상태로 바뀌는 순간. 그 외에는 무슨 일이 있어도 세지 않습니다.
실습 카드 · 포즈 모델 만들기
- 클래스를 Up / Down으로 만듭니다. 이름은 영문 소문자 없이 짧게 — 4장 코드에서 그대로 씁니다
- 각 클래스마다 자세를 유지한 채 몇 초씩 녹화합니다. 카메라와의 거리, 몸의 방향을 여러 번 바꿉니다
- 학습 후 Preview에서 천천히 앉았다 일어납니다. 확률 숫자가 어떻게 넘어가는지 눈으로 봅니다
- 중간 자세에서 확률이 어떻게 나오는지 확인하고 필요하면 Transition 클래스를 추가해 다시 학습합니다
- 다른 사람에게도 시켜봅니다. 나만 맞히는 모델인지 확인하는 가장 빠른 방법입니다
자주 혼동하는 지점
모델이 잘 안 맞을 때 예시를 더 녹화하는 것이 첫 반응이 되기 쉽습니다. 그러나 카운트가 튀는 문제는 대개 모델의 문제가 아니라 세는 규칙의 문제입니다. 모델은 매 순간 정직하게 확률을 주고 있는데, 그 확률을 어떻게 읽을지를 안 정했을 뿐입니다. 3.3의 두 임계값과 상태 개념이 그 규칙입니다.
4장모델을 서비스로 — 링크와 AI Studio
이 장이 이어받는 것
1일차 2.1 — "모델을 내려받는다는 말은 이 숫자 묶음을 받는다는 뜻입니다." 어제는 비유로 들었던 문장입니다. 오늘 그 숫자 묶음이 실제 파일과 URL로 눈앞에 나옵니다.
4.1 학습이 끝나면 무엇이 남는가
티처블머신에서 Export Model을 누르면 선택지가 나옵니다. 클라우드에 업로드해 공유 가능한 링크를 받거나, 파일로 내려받는 것입니다. 어느 쪽이든 실체는 같습니다 — 파일 세 종류입니다.
| 파일 | 담긴 것 | 1일차 용어로 말하면 |
|---|---|---|
| model.json | 모델의 구조 — 층이 어떻게 쌓여 있는지 | 그릇의 모양 |
| weights.bin | 학습으로 정해진 숫자들 | 파라미터. 어제 2.1에서 말한 가중치와 편향이 바로 이것 |
| metadata.json | 클래스 이름 목록, 만든 시각 등 | 답의 목록 — 1.3의 클래스 |
여기서 어제의 문장이 완결된다
어제 배운 세 문장이 이 세 파일에 그대로 대응합니다. 학습이란 숫자를 고치는 일이고(weights.bin이 그 숫자다), 학습이 끝나면 얼어붙으며(파일로 떨어진 순간 더 이상 변하지 않는다), 남는 것은 숫자 묶음뿐입니다.
그리고 이 파일들이 인터넷 주소 아래 놓이는 순간, 모델은 주고받을 수 있는 물건이 됩니다. 다른 사람의 앱이, 다른 회사의 서비스가 그 주소를 불러 쓸 수 있습니다. 모델은 소프트웨어라기보다 파일에 가깝습니다.
4.2 앱은 모델을 부른다 — 누가 무엇을 하는가
스쿼트 카운터가 화면에서 도는 동안 실제로는 네 가지 일이 나뉘어 벌어집니다. 이 분담을 그림으로 잡아두면, 4.3에서 무엇을 요청해야 할지가 저절로 정리됩니다.
4.3 AI Studio에게 무엇을 말해야 하는가
Google AI Studio는 모델을 시험하고 그 자리에서 돌아가는 앱을 만들어 볼 수 있는 작업대입니다. 여기서는 "코드를 짜 달라"가 아니라 어제 배운 RACE로 요청을 구성합니다. 특히 C(맥락)에 모델 URL과 클래스 이름이 들어가야 하고, E(기대 결과)에 판정 규칙이 들어가야 합니다.
[R] 너는 브라우저에서 도는 웹앱을 만드는 프론트엔드 개발자다.
[A] 웹캠으로 사람의 자세를 인식해 스쿼트 횟수를 세는
단일 HTML 파일을 만들어라. 외부 서버 없이 브라우저에서만 동작해야 한다.
[C] - 모델: 티처블머신 포즈 프로젝트로 학습한 모델
- 모델 주소: [https://teachablemachine.withgoogle.com/models/XXXXXXX/]
- 클래스 이름: [Up], [Down] ← metadata.json에 있는 이름과 정확히 같아야 함
- 사용 라이브러리: TensorFlow.js + Teachable Machine Pose 라이브러리
[E] 판정 규칙
- 매 프레임 각 클래스의 확률을 받는다
- [Down] 확률이 0.9 이상이면 상태를 '앉음'으로 바꾼다
- [Up] 확률이 0.9 이상이면 상태를 '섬'으로 바꾼다
- 그 사이 구간에서는 직전 상태를 유지한다
- '앉음' → '섬' 으로 바뀌는 순간에만 카운트를 1 올린다
화면 구성
- 카메라 영상과 인식된 관절선을 함께 표시
- 큰 숫자로 카운트, 그 아래 현재 상태와 두 클래스의 확률(소수 둘째 자리)
- 초기화 버튼 1개
그 밖에
- 전체를 index.html 한 파일로. 별도 빌드 도구 없이 열면 바로 동작할 것
- 카메라 권한이 거부되면 화면에 안내 문구를 표시할 것
- 주석은 한국어로
이 프롬프트에서 눈여겨볼 두 가지
- 판정 규칙을 내가 썼습니다. 3.2~3.3에서 정리한 내용이 그대로 [E] 칸에 들어갔습니다. 이 부분을 비워두고 "스쿼트를 세어줘"라고만 하면, 모델이 아니라 AI Studio가 임의로 규칙을 정합니다. 그러면 왜 잘못 세는지 설명할 수 없게 됩니다.
- 클래스 이름을 정확히 적었습니다. 코드는 이름을 문자 그대로 비교합니다. 티처블머신에서
Down으로 지었는데 프롬프트에down이라 쓰면 아무 일도 일어나지 않습니다 — 오류도 나지 않고 카운트만 영원히 0입니다.
4.4 안 될 때의 진단표
1일차 7.3에서 영상 작업의 진단표를 만들었던 것과 같은 방식입니다. 증상별로 어느 공정을 볼지 미리 정해두면 헤매는 시간이 크게 줍니다.
| 증상 | 흔한 원인 | 볼 곳 |
|---|---|---|
| 카메라가 안 켜진다 | 권한 거부, 또는 http로 열었다 | 브라우저 권한 설정. 카메라는 https 또는 localhost에서만 열린다 — 12장에서 배포하면 자동 해결된다 |
| 카운트가 계속 0 | 클래스 이름 불일치 | metadata.json의 이름과 코드의 문자열을 대소문자까지 대조 |
| 모델을 못 불러온다 | 모델 주소 끝의 / 누락, 또는 오타 | 주소를 브라우저에 직접 붙여 넣어 model.json이 보이는지 확인 |
| 카운트가 미친 듯이 오른다 | 임계값이 하나뿐이거나 상태 개념이 없다 | 3.3 — 두 개의 임계값과 상태 전이로 고친다. 모델을 다시 학습시킬 일이 아니다 |
| 천천히 하면 맞는데 빨리 하면 놓친다 | 중간 구간을 너무 빨리 통과한다 | 임계값을 0.9에서 0.75 정도로 낮춰본다. 낮출수록 민감해지고 잘못 셀 위험도 커진다 |
| 나만 잘 맞고 남은 안 맞는다 | 학습 예시가 나 한 사람뿐 | 1.4 다양성 — 모델 문제다. ②단계로 돌아간다 |
한 걸음 더 · 이 앱은 영상을 어디로도 보내지 않는다
이 구조에서 카메라 영상은 브라우저 밖으로 나가지 않습니다. 모델 파일이 내 컴퓨터로 내려와서, 판정도 내 컴퓨터에서 일어납니다. 이런 방식을 온디바이스(on-device) 추론이라 부릅니다.
실무에서 이 성질은 값이 꽤 큽니다. 작업자 영상이나 설비 화면처럼 밖으로 내보내기 곤란한 데이터를 다룰 때, 판정을 기기 안에서 끝낼 수 있다면 협의해야 할 것이 훨씬 줄어듭니다.
그리고 이 성질이 14장의 챗봇과 정반대라는 점을 기억해두면 좋습니다. 챗봇은 문서를 서비스 쪽에 올려두고 씁니다. 같은 "AI를 쓴다"는 말이지만 내 데이터가 어디에 있는가는 완전히 다릅니다. 도입을 검토할 때 가장 먼저 물어야 할 질문이 이것입니다.
2 부
데이터를 만든다 — 정제된 표가 옳은 답을 만든다
재료가 무거워집니다. 사진 몇 장에서 100행짜리 표로, 다시 60행 13열의 오염된 원본으로. 뒤로 갈수록 기계가 아니라 사람이 판단해야 할 것이 늘어납니다.
5장스프레드시트에 AI를 앉히다
이 장이 대응하는 성질
1일차 3.1 — LLM은 확률로 다음 조각을 이어 붙입니다. 어제 교재가 남긴 첫 번째 질문이 이것이었습니다. "LLM은 계산기가 아닙니다. 그런데 표를 주면 왜 그럴듯한 숫자를 말할까?" 이 장이 그 답이고 2부 전체의 전제입니다.
5.1 왜 표를 주면 숫자를 틀리는가
어제 배운 대로 LLM이 하는 일은 하나입니다 — 지금까지의 글을 보고 다음에 올 토큰의 확률을 계산해서 하나를 고릅니다. 여기에 표를 붙여 넣고 "합계를 구해줘"라고 하면 무슨 일이 벌어지는지 생각해 보면 됩니다.
모델은 덧셈을 하지 않습니다. "합계는" 다음에 올 법한 토큰을 고릅니다. 표에 적힌 숫자들의 자릿수와 크기를 보고 그럴듯한 숫자를 이어 씁니다. 그래서 결과가 자주 근사값이고, 자릿수는 대체로 맞고, 가끔 틀립니다. 그리고 틀렸을 때도 확신에 찬 문장으로 나옵니다 — 어제 3.1에서 본 "왜 자신 있게 틀리는가"가 숫자 영역에서 재현된 것뿐입니다.
2부 전체를 관통하는 분업
계산은 수식에게, 판단은 모델에게.
이 한 줄이 스프레드시트에서 AI를 쓰는 방법의 전부입니다. 시트는 계산을 정확히 그리고 재현 가능하게 하고 모델은 사람이 읽어야만 알 수 있던 것을 대신 읽습니다. 서로의 약점이 정확히 반대라서 잘 붙습니다.
| 모델에게 시켜도 되는 것 | 왜 되는가 | 모델에게 시키면 안 되는 것 | 왜 안 되는가 |
|---|---|---|---|
| 문장 분류 · 감정 판단 | 정답이 하나로 딱 떨어지지 않는 판단이다 | 합계 · 평균 · 비율 | 확률로 생성한다. 검산이 불가능하다 |
| 표기 통일 (광양 제철소 → 광양제철소) | 규칙을 다 적기 어려운 변형을 다룬다 | 정렬 · 순위 매기기 | 전체를 동시에 보지 않는다. 중간이 뒤섞인다 |
| 자유 텍스트에서 항목 뽑기 | 형식이 제각각인 글을 읽는다 | 중복 찾기 · 개수 세기 | 세는 것이 아니라 짐작한다 |
| 요약 · 재작성 · 초안 | 1일차에서 내내 한 일이다 | 날짜 계산 · 기간 산출 | 같은 이유. DATEDIF가 있다 |
5.2 시트 안에서 AI를 쓰는 두 가지 방식
스프레드시트에서 Gemini를 쓰는 방법은 크게 둘이고 성격이 아주 다릅니다. 이 둘을 구분하지 않으면 왜 어떤 작업은 순식간에 끝나고 어떤 작업은 위험한지가 설명되지 않습니다.
| ① 옆에서 돕는 방식 | ② 셀 안에서 도는 방식 | |
|---|---|---|
| 모습 | 사이드 패널에서 대화한다 | 셀에 =AI("지시", 범위) 같은 함수를 쓴다 |
| 한 번에 다루는 것 | 시트 전체 또는 선택 범위 | 한 행 — 그리고 아래로 채우기 |
| 강점 | 탐색 · 상담 · 수식 만들어 달라기 | 3천 행을 한 번에 같은 기준으로 처리 |
| 위험 | 결과가 대화창에만 남는다 | 3천 번의 독립된 확률 뽑기가 일어난다 |
| 쓰는 자리 | "이 데이터로 뭘 볼 수 있지?" | "이 열을 전부 분류해줘" |
자주 혼동하는 지점 — 셀 함수는 빠른 만큼 조용히 틀린다
=AI(...)를 3,297행에 채우면 3,297번의 서로 독립된 판단이 일어납니다. 어제 3.1에서 본 대로 매번 확률표에서 뽑기 때문에, 거의 같은 문장인데 다른 라벨이 붙는 일이 생깁니다. 그리고 3,297행을 눈으로 다 보는 사람은 없습니다.
그래서 이 방식을 쓸 때는 항상 두 가지를 붙입니다. 라벨 목록을 프롬프트에 고정하고(7.1), 끝난 뒤 고유값 목록으로 검산합니다(6.4). 이 두 가지가 없으면 편리한 만큼 위험합니다.
5.3 시트 0 · 복리 — 계산은 수식에게
첫 실습이 복리 계산인 데는 이유가 있습니다. 복리는 사람이 암산으로 못 하고 LLM도 못 하고 수식은 정확히 하는 대표적인 작업입니다. 5.1의 분업을 몸으로 확인하는 자리입니다.
원금 P를 연이율 r로 n년 굴리면 P×(1+r)^n입니다. 셀에 =B2*(1+B3)^B4라고 쓰면 끝이고, B4를 20으로 바꾸면 즉시 다시 계산됩니다. 같은 질문을 모델에게 던지면 매번 답을 새로 생성하고, 20년으로 바꾸면 처음부터 다시 물어야 합니다.
한 걸음 더 · 그러면 AI는 여기서 무엇을 하나
수식을 내가 아니라 AI가 만들게 합니다. "월 적립식으로 매달 50만원씩 10년, 연 5%일 때 만기 금액을 구하는 수식을 써줘"라고 하면 =FV(5%/12, 120, -500000) 같은 것을 줍니다.
이 구조가 오늘 하루 반복됩니다 — AI는 도구를 만들고, 계산은 도구가 합니다. 13장의 VBA도 같은 구조입니다. AI가 매크로를 쓰고, 실행은 엑셀이 합니다. AI에게 결과를 묻는 것과 결과를 내는 장치를 만들어 달라고 하는 것은 전혀 다른 요청입니다.
5.4 시트 1 · 문장 — 판단은 모델에게
반대편 실습입니다. 시트 1에는 여섯 개의 문장이 들어 있습니다. 이런 것은 수식으로 할 수 없습니다. LEN으로 길이는 재도, "이 문장이 무슨 말을 하는가"는 함수의 영역 밖입니다.
문장 열을 놓고 시켜볼 만한 작업은 이런 것들입니다. 각각이 나중에 7장에서 본격적으로 다뤄집니다.
- 요약 — 각 문장을 한 구절로 (열 하나 추가)
- 주제 분류 — 심리 / 태도 / 방법론 중 하나로
- 키워드 추출 — 핵심어 2개씩
- 어조 변환 — 존댓말로, 또는 사내 공지 문체로
주의할 점은 하나입니다. 같은 문장에 두 번 시키면 결과가 조금 다를 수 있습니다. 어제 3.1의 성질이 그대로 나타납니다. 그래서 문장 작업의 결과는 값으로 붙여넣어 고정하는 습관이 필요합니다. 수식으로 남겨두면 시트를 열 때마다 미묘하게 달라질 수 있습니다.
5.5 시트 4 · 데이터 가져오기
스프레드시트는 웹 페이지의 표를 그대로 끌어올 수 있습니다. IMPORTHTML은 페이지 안의 표나 목록을, IMPORTXML은 지정한 위치의 값을, IMPORTRANGE는 다른 시트 파일의 범위를 가져옵니다.
| 함수 | 가져오는 것 | 주의 |
|---|---|---|
| IMPORTHTML | 웹 페이지의 표(table) 또는 목록(list). 몇 번째 표인지 번호로 지정 | 페이지 구조가 바뀌면 말없이 다른 표를 가져온다 |
| IMPORTXML | 페이지 안의 특정 위치 값 | 경로 지정이 까다롭고 더 잘 깨진다 |
| IMPORTRANGE | 다른 스프레드시트 파일의 범위 | 첫 사용 시 접근 허용이 필요하다 |
자주 혼동하는 지점 — 가져온 숫자는 대개 숫자가 아니다
웹에서 끌어온 값은 73,000, 2.1%, 1,234원처럼 기호가 붙은 문자열인 경우가 많습니다. 화면에는 숫자로 보이지만 SUM이 0을 냅니다. 6장 전체가 이 문제를 다룹니다.
그리고 하나 더 — 가져오기는 원본이 살아 있는 동안만 유효합니다. 페이지가 개편되면 시트가 조용히 빈칸이 되거나 엉뚱한 표로 채워집니다. 보고서에 쓸 숫자라면 가져온 시점에 값으로 고정하고 언제 가져왔는지 기록해 두는 편이 안전합니다.
실습 카드
시트 0·1·4를 한 번씩 돌려 본 뒤, 내 업무에서 이 셋에 해당하는 것을 하나씩 적어봅니다. ① 지금 손으로 계산하고 있는 것(→수식), ② 지금 눈으로 읽고 분류하고 있는 것(→모델), ③ 매번 어딘가에서 복사해 오는 것(→가져오기). 이 목록이 곧 자동화 후보 목록입니다.
6장더러운 데이터를 치우다 — 전처리
1일차가 남긴 세 번째 질문
"데이터가 이미 틀려 있다면, 아무리 좋은 모델도 무엇을 할 수 있을까?" 답은 짧습니다 — 틀린 답을 더 빨리, 더 그럴듯하게 만듭니다. 그래서 오늘 오후의 절반이 이 장과 10장에 배정되어 있습니다.
6.1 더러움의 여섯 가지 얼굴
"데이터가 더럽다"는 말은 막연합니다. 실제로는 여섯 가지 정도로 유형이 갈리고, 유형마다 처치가 다릅니다. 실습 파일의 어느 시트에서 만나는지까지 붙여 두면 지도가 됩니다.
| 유형 | 실물 | 사람 눈에는 | 함수 눈에는 | 처치 |
|---|---|---|---|---|
| 앞뒤 공백시트 2 | " 김철수 " | 김철수 | 다른 값 | TRIM |
| 표기 불일치시트 9 | 포항제철소 / 포항 제철소 / POHANG / Pohang Works | 같은 공장 | 서로 다른 4개 | 매핑표 + XLOOKUP 또는 AI |
| 텍스트가 된 숫자시트 3 · 9 | "73,000" · "822592 t" · "₩577771" | 숫자 | 글자 | 기호 제거 후 VALUE |
| 날짜 형식 혼재시트 9 | 45684 · 2025.2.14 · 2025년 4월 10일 | 다 날짜 | 숫자 하나, 글자 둘 | DATEVALUE · 분해 후 DATE |
| 중복시트 9 | 완전히 같은 행이 두 번 | 안 보인다 | 두 번 센다 | 중복 제거 (개수를 기록) |
| 결측시트 9 | 빈 셀 | 비어 있음 | AVERAGE는 건너뛰고 COUNT는 안 센다 | 방침을 정한다 — 6.5 |
6.2 공백 — 시트 2가 가르치는 것
시트 2의 직원 데이터를 보면 " 김철수", "이영희 ", " 경영지원팀"처럼 앞뒤에 공백이 섞여 있습니다. 화면에서는 살짝 밀려 보일 뿐이라 눈치채기 어렵습니다.
| 함수 | 하는 일 | 언제 |
|---|---|---|
| TRIM | 앞뒤 공백을 없애고, 중간의 연속 공백은 하나로 | 거의 모든 텍스트 열에 기본으로 |
| CLEAN | 줄바꿈 같은 보이지 않는 제어문자 제거 | 다른 시스템에서 내려받은 데이터 |
| SUBSTITUTE | 지정한 문자를 바꾸거나 없앤다 | 중간 공백까지 전부 없앨 때 — SUBSTITUTE(A2," ","") |
주의할 점 하나 — TRIM과 SUBSTITUTE는 다릅니다. "부산 특수강"의 중간 공백은 TRIM으로 사라지지 않습니다. 10장의 표준화에서 이 차이가 실제로 문제가 됩니다.
가장 자주 겪게 될 증상
VLOOKUP이 #N/A를 냅니다. 아홉 번 중 여덟 번은 함수를 잘못 쓴 것이 아니라 양쪽 값이 글자로 다르기 때문입니다. 수식을 고치기 전에 =EXACT(A2, B2)로 두 값이 정말 같은지 먼저 확인합니다. FALSE가 나오면 공백이나 보이지 않는 문자가 범인입니다.
6.3 텍스트가 된 숫자 — 시트 3이 가르치는 것
시트 3의 주식 데이터는 현재가가 73,000, 배당수익률이 2.1%로 들어 있습니다. 사람에게는 완벽히 읽히지만 쉼표와 퍼센트 기호가 붙는 순간 많은 경우 문자열이 됩니다.
진단 — 세는 것보다 먼저 확인한다
| 방법 | 구체적으로 |
|---|---|
| 정렬을 본다 | 서식을 건드리지 않은 셀에서 숫자는 오른쪽, 글자는 왼쪽에 붙는다. 가장 빠른 눈검사 |
| ISNUMBER | =ISNUMBER(C2) — FALSE면 문자열. 열 전체는 =COUNTIF(범위,TRUE)로 개수 확인 |
| 합계를 내본다 | SUM이 0이거나 터무니없이 작으면 거의 확실하다 |
처치
- 쉼표만 있는 경우 —
=VALUE(SUBSTITUTE(C2,",","")) - 단위가 붙은 경우 —
"822592 t","744643톤"처럼 뒤에 글자가 있으면 그 글자를 지우고VALUE. 10장에서 실제로 합니다 - 퍼센트 —
"2.1%"를 숫자로 바꾸면 0.021이 되어야 합니다.2.1로 두면 뒤의 모든 계산이 100배 틀립니다 - 통화 기호 —
"₩577771"은 기호를 제거하고VALUE
자주 혼동하는 지점 — 서식과 값은 다르다
셀 서식을 "숫자"로 바꿔도 이미 문자열로 들어 있는 값은 숫자가 되지 않습니다. 서식은 보여주는 방법이고, 값이 무엇인지는 별개입니다. 반대로 값이 0.021인데 백분율 서식이면 화면에 2.1%로 보입니다 — 보이는 것으로 판단하면 안 됩니다.
10장의 목표 스펙에 "숫자 열은 ISNUMBER가 전부 TRUE"라는 항목이 들어 있는 이유가 이것입니다. 눈이 아니라 함수로 확인합니다.
6.4 표기 통일 — 여기서 AI가 이긴다
지금까지의 문제는 전부 함수로 풀립니다. 그런데 같은 대상을 여러 이름으로 부른 열은 다릅니다. 10장에서 만날 사업장 열 하나에 이런 표기가 들어 있습니다.
포항제철소 포항 제철소 POHANG Pohang Works 포항제철소 광양제철소 광양 제철소 GWANGYANG gwangyang works 당진전기로 당진 전기로 DANGJIN 부산특수강 부산 특수강 BUSAN busan specialty
이런 열은 세 가지 방법으로 정리할 수 있고, 어느 것을 쓸지는 규칙의 성격이 정합니다.
| 방법 | 적합한 경우 | 장점 | 한계 |
|---|---|---|---|
| 함수로 규칙화UPPER · TRIM · SUBSTITUTE | 규칙이 완전히 명확할 때 (대소문자, 공백) | 빠르고 재현되고 검산이 쉽다 | "POHANG = 포항제철소"는 규칙으로 못 쓴다 |
| 매핑표 + XLOOKUP | 나올 수 있는 경우가 유한하고 이미 아는 경우 | 가장 확실하다. 결과가 항상 같다 | 표를 만들어야 하고 새 표기가 나오면 놓친다 |
| AI에게 시키기 | 표기가 자유롭고 예측 불가할 때 | 표에 없는 변형도 잡아낸다 | 매번 같다는 보장이 없다. 반드시 검산 |
실습 파일이 매핑표를 따로 제공하는 것(시트 9_1)은 우연이 아닙니다. 사업장·공정·제품처럼 회사가 이미 알고 있는 목록은 AI에게 맡길 일이 아니라 표로 관리할 일입니다. AI는 그 표에 없는 표기가 들어왔을 때 비로소 필요해집니다.
AI로 통일했으면 반드시 이것을 한다
고유값 목록을 뽑아 눈으로 셉니다. =UNIQUE(정리된범위) 또는 =COUNTA(UNIQUE(...)). 사업장이 4개여야 하는데 6개가 나오면, 어딘가에 "포항제철소 "처럼 공백이 남은 값이나 "포항" 같은 다른 축약이 섞였습니다.
이 검산은 30초면 끝나고, 이것을 건너뛴 대시보드는 같은 공장을 두 줄로 그립니다. 그리고 그 대시보드는 틀렸다는 사실조차 티가 나지 않습니다.
6.5 처치의 네 가지 원칙
어떤 데이터를 다루든 지켜지는 규칙입니다. 10장 실습에서 그대로 적용됩니다.
| 원칙 | 구체적으로 | 지키지 않으면 |
|---|---|---|
| ① 원본은 건드리지 않는다 | Raw 시트는 그대로 두고 복사해서 작업한다 | 잘못 고쳤을 때 돌아갈 곳이 없다 |
| ② 새 열에 만든다 | 원래 열 옆에 사업장_표준 같은 열을 추가 | 무엇이 원본이고 무엇이 가공인지 사라진다 |
| ③ 판단은 기록한다 | "이상치 3건은 제거가 아니라 제외 표시", "결측 단가는 월평균으로" — 시트 한 칸에 적어둔다 | 한 달 뒤 내가 왜 이렇게 했는지 모른다 |
| ④ 지운 것은 세어둔다 | "60행 → 중복 3건 제거 → 57행" | 숫자가 안 맞을 때 어디서 샜는지 못 찾는다 |
한 걸음 더 · 전처리는 왜 기록이 남아야 하는가
분석 결과에 이의가 제기되는 상황을 떠올려 보면 이유가 분명해집니다. "이 숫자 왜 이래요?"라는 질문에 답하려면 원본에서 여기까지 온 경로가 있어야 합니다. 이상치 8건을 뺐다면 왜 뺐는지, 결측을 어떻게 채웠는지가 설명되어야 합니다.
그리고 실무에서 더 자주 겪는 상황은 이것입니다 — 다음 달에 같은 작업을 또 합니다. 기록이 없으면 매달 조금씩 다른 기준으로 정제하게 되고, 그러면 월별 추이 자체가 가짜가 됩니다. 전처리 기록은 남을 위한 것이기 전에 다음 달의 나를 위한 것입니다.
7장말을 표로 바꾸다 — 분류 · 감정 · 구조화
6장은 이미 표인 것을 고쳤습니다. 이 장은 표가 아닌 것을 표로 만듭니다. 고객 문의, 리뷰, 평가 코멘트처럼 그동안 사람이 읽고 손으로 옮기던 것들입니다.
7.1 분류 — 라벨 목록이 전부다
시트 5에는 고객 문의 원문이 들어 있고, 옆에 분류 결과를 넣을 열이 있습니다. 그리고 조금 떨어진 곳에 분류 라벨 목록이 따로 적혀 있습니다 — 주문/납기, 견적/단가, 품질/클레임 같은 것들입니다.
이 라벨 목록이 따로 있다는 사실이 이 실습의 핵심입니다. 목록 없이 "이 문의를 분류해줘"라고 하면 어떤 일이 벌어지는지 그림으로 보면 분명합니다.
분류 프롬프트의 세 가지 필수 요소
- 라벨 목록을 명시한다 — "다음 중 하나로만 답하라"
- 기타를 둔다 — 억지로 배정하지 않게. 1.3의 "판정 불가 클래스"와 같은 장치입니다
- 라벨만 출력하게 한다 — 설명이 섞이면 집계할 수 없습니다. 이유가 필요하면 별도 열로
아래 고객 문의를 다음 네 가지 중 하나로만 분류하라. 주문/납기 · 견적/단가 · 품질/클레임 · 기타 - 라벨 이름만 출력한다. 설명·따옴표·문장부호를 붙이지 않는다. - 둘 이상에 걸치면 더 비중이 큰 쪽 하나만 고른다. - 판단이 서지 않으면 기타로 한다. 억지로 배정하지 않는다. 문의: [셀 참조]
7.2 감정 — 두 칸으로는 부족하다
시트 6은 고객 리뷰와 감정 열입니다. 긍정/부정 두 가지로 나누는 것이 가장 흔한 설계인데, 실제 리뷰를 읽어보면 곧 막힙니다.
이 문장은 긍정인가 부정인가. 가격에는 부정이고 납기에는 긍정입니다. 하나의 라벨로 누르면 정보가 사라지고, 무엇보다 이 리뷰로 개선할 지점을 못 찾습니다. 감정 분석의 목적이 "우리 평판이 좋은가"가 아니라 "무엇을 고쳐야 하는가"라면, 축을 나눠야 합니다.
| 설계 | 결과 형태 | 알 수 있는 것 |
|---|---|---|
| 2분류 | 긍정 / 부정 | 전체 분위기. 그 이상은 없다 |
| 3분류 | 긍정 / 중립 / 부정 | 애매한 것을 억지로 밀어넣지 않는다 |
| 축 × 감정 (권장) | 품질·납기·가격·응대 각각을 긍정/부정/언급없음으로 | 어느 항목이 문제인지. 바로 개선 과제가 된다 |
세 번째 방식은 열이 늘어나지만 실제로 쓸 수 있는 것은 이것뿐입니다. 리뷰 100건을 처리하고 나면 "납기 부정 32건, 가격 부정 28건, 품질 긍정 71건" 같은 표가 나오고, 이건 그대로 보고서에 들어갑니다.
자주 혼동하는 지점 — 감정 라벨에는 정답이 없다
같은 리뷰를 사람 셋에게 분류시켜도 완전히 일치하지 않습니다. 그러니 AI의 결과가 내 판단과 다르다고 해서 곧바로 "틀렸다"고 할 수 없습니다. 중요한 것은 정확성보다 일관성입니다 — 같은 기준으로 100건이 처리되었다면, 기준이 내 취향과 조금 달라도 비교와 추이는 성립합니다.
그래서 실무에서는 기준을 프롬프트에 문장으로 못 박습니다. "칭찬과 불만이 함께 있으면 불만 쪽으로 본다" 같은 식입니다. 기준이 적혀 있으면 나중에 왜 이렇게 나왔는지 설명할 수 있습니다.
7.3 자유 텍스트를 열로 — 시트 7
시트 7은 성명과 핵심역량 평가 결과가 한 칸에 뭉쳐 있습니다.
박준영 | 소통역량(80) 글로벌역량(90) 논리분석(85) 전문지식(95) 이지은 | 팀워크(95) 글로벌역량(82) 대인관계(85) 소통역량(78) 최지우 | 전문지식(88) 소통역량(65) 팀워크(100) 대인관계(80)
이대로는 평균도 못 내고 정렬도 못 합니다. 역량별로 열을 만들어 점수를 흩어야 비로소 데이터가 됩니다. 그런데 여기서 판단이 하나 필요합니다 — 이 작업을 AI에게 시킬 것인가.
AI를 먼저 꺼내지 않는다
이 데이터는 규칙이 뚜렷합니다. "이름(숫자)" 형태가 공백으로 구분되어 반복됩니다. 규칙이 보이면 함수가 이깁니다. REGEXEXTRACT로 특정 역량의 점수를 뽑거나, SPLIT으로 쪼갠 뒤 처리하면 됩니다.
함수가 이기는 이유는 셋입니다 — 비용이 0이고, 결과가 항상 같고, 왜 그렇게 나왔는지 셀을 눌러 볼 수 있습니다. 다음 달에 같은 파일이 와도 수식만 끌어내리면 끝납니다.
AI가 필요해지는 것은 형식이 무너질 때입니다. "소통역량 80점, 글로벌 역량은 90"처럼 사람마다 다르게 적혀 있으면 정규식이 감당하지 못합니다. 그때가 AI의 자리입니다.
| 상황 | 도구 | 이유 |
|---|---|---|
| 형식이 일정하다 | SPLIT · REGEXEXTRACT | 재현되고 검산 가능하고 무료 |
| 형식이 몇 가지로 갈린다 | 함수 + 예외만 AI | 대부분을 싸게 처리하고 나머지만 맡긴다 |
| 형식이 자유롭다 | AI (출력 형식 지정 필수) | 규칙을 쓸 수 없다 |
7.4 검산 — 결과를 믿기 전에
7.1~7.3의 작업이 끝나면 수백 개의 라벨이 생겼습니다. 이것을 그대로 집계에 넘기기 전에 세 가지를 합니다. 5분이면 끝나고, 이걸 건너뛰면 9장의 대시보드가 조용히 틀립니다.
| 점검 | 방법 | 무엇이 걸리나 |
|---|---|---|
| ① 고유값 확인 | =UNIQUE(라벨범위) | 지정한 라벨 외의 값. 오타·조사·따옴표가 섞인 것 |
| ② 분포 확인 | =COUNTIF로 라벨별 개수 | 한 라벨에 90%가 몰려 있으면 기준이 잘못 잡힌 것 |
| ③ 표본 눈검사 | 무작위 20건을 직접 읽고 대조 | 체계적인 오해. 예 — 문의가 전부 '기타'로 갔다면 라벨 설계 문제 |
실습 카드
시트 5를 라벨 목록 없이 한 번, 있게 한 번 처리해 봅니다. 그리고 두 결과의 UNIQUE 개수를 비교합니다. 차이를 눈으로 보면 이 장의 내용이 한 줄로 남습니다 — 분류의 품질은 라벨 설계에서 결정됩니다.
8장EDA와 CDA — 무엇을 보고 무엇을 검증하는가
데이터가 정리되면 보기 시작합니다. 그런데 "본다"에는 성격이 다른 두 가지가 섞여 있고, 이 둘을 구분하지 않으면 보고 싶은 것을 보게 됩니다.
8.1 두 단어
| EDA Exploratory Data Analysis | CDA Confirmatory Data Analysis | |
|---|---|---|
| 우리말 | 탐색적 자료분석 | 확증적 자료분석 |
| 목적 | 가설을 만들기 위해 본다 | 가설을 검증하기 위해 본다 |
| 태도 | 열려 있다 — 뭐가 나오나 보자 | 닫혀 있다 — 이 문장이 맞나 보자 |
| 순서 | 먼저 | 나중. 가설을 글로 쓴 뒤에 |
| 전형적 행동 | 분포를 그린다, 결측을 센다, 여러 축으로 잘라 본다 | 기준을 정하고 두 집단을 비교한다 |
| 나오는 것 | "뭔가 있다" — 질문 | "맞다 / 아니다" — 답 |
이름은 통계학자 존 튜키(John Tukey)가 1970년대에 붙였습니다. 당시 통계는 가설을 검정하는 일과 거의 동의어였는데, 튜키는 그 앞에 "데이터를 먼저 들여다보는 단계"가 따로 있어야 한다고 주장했습니다. 지금 우리가 "일단 데이터부터 보자"고 말할 때 하는 일이 그것입니다.
8.2 순서를 지켜야 하는 이유
이 장에서 하나만 가져간다면
같은 데이터로 가설을 만들고 그 데이터로 검증하면 안 됩니다. 데이터를 충분히 오래 들여다보면 무엇이든 나옵니다. 100개의 조합을 보면 그중 몇 개는 우연히 크게 차이 납니다. 그것을 발견해 놓고 같은 데이터에 "확인"을 시키면 당연히 맞다고 나옵니다.
현실적인 대응은 셋입니다. ① 다른 기간·다른 라인의 데이터로 확인합니다. ② 데이터 밖의 근거와 대조한다 — 현장 기록, 담당자 인터뷰, 설비 이력. ③ 최소한 "이건 가설이다"라고 표시해서 보고합니다. 세 번째만 해도 사고는 크게 줍니다.
8.3 EDA에서 실제로 하는 일
거창한 기법이 아닙니다. 시트에서 할 수 있는 것들이고 순서도 대체로 정해져 있습니다.
| 단계 | 보는 것 | 시트에서 | 알게 되는 것 |
|---|---|---|---|
| ① 크기와 형태 | 몇 행 몇 열, 각 열이 무엇인지 | COUNTA, 열 제목 훑기 | 이 데이터로 답할 수 있는 질문의 범위 |
| ② 결측 | 어느 열에 얼마나 비어 있나 | COUNTBLANK ÷ 전체 | 그 열을 쓸 수 있는지. 결측이 몰려 있으면 원인이 있다 |
| ③ 고유값 | 범주형 열의 값 종류와 개수 | UNIQUE · COUNTIF | 표기 오염(6장) · 쏠림 |
| ④ 분포 | 숫자 열의 최소·최대·평균·중앙값 | MIN MAX AVERAGE MEDIAN, 히스토그램 | 이상치의 존재. 평균과 중앙값이 크게 다르면 한쪽으로 긴 꼬리가 있다 |
| ⑤ 관계 | 두 열을 교차해서 본다 | 피벗 테이블 · 교차표 | 가설의 씨앗. 여기가 EDA의 핵심 |
한 걸음 더 · 평균만 보면 놓치는 것
EDA에서 가장 자주 저지르는 실수는 평균 하나로 판단하는 것입니다. 거래처 만족도 평균이 7.2점이라는 말은, 전원이 7점대라는 뜻일 수도 있고 9점 절반과 5점 절반이라는 뜻일 수도 있습니다. 두 상황에서 해야 할 일은 완전히 다릅니다.
그래서 평균 옆에 중앙값과 분포를 항상 함께 봅니다. 그리고 축을 하나 더 넣어 잘라 본다 — 거래처 구분별로, 지역별로, 계약 형태별로. 전체 평균에서 안 보이던 것이 잘라 보면 나옵니다. 9장 대시보드에 슬라이서가 있는 이유가 이것입니다.
8.4 CDA는 무엇이 다른가
CDA의 첫 단계는 데이터를 보는 것이 아니라 문장을 쓰는 것입니다.
가설 : 대형 거래처는 중소 거래처보다 이탈위험도가 낮다. 비교 대상 : 거래처구분 = 대형 vs 중소 판단 기준 : 두 집단의 평균 이탈위험도 차이가 10 이상이면 "그렇다"로 본다. 반증 조건 : 차이가 5 미만이거나 방향이 반대면 가설을 버린다.
반증 조건을 미리 적는 것이 CDA의 핵심입니다. 이것을 미리 쓰지 않으면, 결과를 본 뒤에 기준을 조정하게 됩니다. "8이면 좀 애매한데… 그래도 경향은 보이니까"가 되는 순간 검증이 아니라 설득이 됩니다.
8.5 AI에게 EDA를 시킬 때
AI는 EDA의 ①~④를 아주 빠르게 해줍니다. 그리고 ⑤에서 조심해야 합니다.
[R] 너는 데이터를 처음 받아 든 분석가다.
[A] 아래 표를 탐색적으로 살펴보고, 결론이 아니라 확인해볼 만한 질문을 뽑아라.
[C] - 데이터: [붙여넣기 또는 열 설명]
- 각 열의 의미: [간단히]
- 알아두어야 할 배경: [예 — 이탈위험도는 0~100, 높을수록 위험]
[E] 다음 순서로 답하라.
1) 열별 요약 — 결측 비율, 고유값 수, 숫자 열은 최소·최대·평균·중앙값
2) 눈에 띄는 점 5가지 — 각각 어느 열의 어떤 수치를 근거로 했는지 함께
3) 확인해볼 가설 3개 — "~일 것이다"의 형태로, 검증 방법을 한 줄씩 붙여서
금지 사항
- "따라서 ~이다"라는 결론 문장을 쓰지 말 것
- 표에 없는 배경지식으로 원인을 추정하지 말 것
- 수치는 계산하지 말고, 어느 수식으로 확인하면 되는지를 알려줄 것
자주 혼동하는 지점 — 두 가지
① AI가 말한 수치를 그대로 쓰지 않습니다. 5.1에서 본 대로 모델은 계산하지 않습니다. 위 프롬프트의 마지막 줄이 "계산하지 말고 수식을 알려달라"인 이유입니다. 수치는 시트가 내고, 모델은 어디를 볼지만 정합니다.
② 상관은 인과가 아닙니다. AI는 "A가 높을수록 B가 높다"를 아주 잘 찾아내고, 그것을 원인처럼 말하는 경향도 있습니다. 그런데 세 번째 요인이 둘 다를 움직이는 경우가 흔합니다. 업력이 긴 거래처가 만족도가 높다면, 업력 때문일 수도 있고 만족한 곳만 오래 남았기 때문일 수도 있습니다.
1일차 8장과 같은 구조
어제 딥리서치를 배우며 "결론은 답이 아니라 근거 묶음이고 출처를 직접 눌러 확인해야 한다"고 했습니다. AI의 EDA 결과도 다르지 않습니다 — 결론이 아니라 볼 곳의 목록이고 수치는 시트에서 직접 확인합니다. 도구가 바뀌어도 다루는 법이 같은 이유는, 둘 다 확률로 문장을 만드는 같은 기계이기 때문입니다.
9장대시보드 — 숫자를 한 화면에
이 장이 이어받는 것
1일차 8장 — "시각화는 내용을 좋게 만들지 않습니다. 검증이 끝난 뒤에 하는 마지막 공정입니다." 그 원칙 위에, 오늘은 어떻게 만드는가를 더합니다.
9.1 대시보드는 질문 목록이다
대시보드를 만들라고 하면 대개 차트부터 그립니다. 그리고 완성되면 아무도 열어보지 않는 화면이 하나 늘어납니다. 이유는 단순합니다 — 그 화면이 누구의 어떤 질문에 답하는지가 정해지지 않았기 때문입니다.
만들기 전에 종이에 쓰는 것
이 화면을 열 사람이, 열자마자 알고 싶은 것 다섯 가지. 문장으로 씁니다.
- 지금 거래처가 몇 곳이고 그중 위험한 곳은 몇 곳인가
- 이탈위험이 높은 곳은 어느 지역·어느 계약형태에 몰려 있는가
- 클레임이 많은 거래처가 만족도도 낮은가
- 계약 만료가 6개월 안에 오는 곳은 몇 곳인가
- 대형과 중소 중 어느 쪽을 먼저 봐야 하는가
이 다섯 문장이 차트 다섯 개의 명세서가 됩니다. 반대로 이 문장이 없으면, 만들 수 있는 차트를 다 만들게 되고 결국 아무 질문에도 답하지 못합니다.
9.2 3층 구조 — 실습 파일이 이렇게 생긴 이유
실습 파일에는 거래처 데이터가 담긴 시트(100건 × 20열)와 _DB_Data라는 시트가 따로 있습니다. 화면이 원자료를 직접 계산하지 않고 집계 시트를 한 겹 거치도록 만들어져 있습니다.
9.3 집계의 두 함수와 슬라이서의 원리
집계 시트에서 반복해 쓰이는 함수는 사실상 두 갭니다. 조건에 맞는 것을 세거나(COUNTIFS), 조건에 맞는 것의 평균을 내거나(AVERAGEIFS).
· 품목별 거래처 수
=COUNTIFS( 원자료!품목열, "열연강판",
원자료!지역열, [지역 선택값],
원자료!구분열, [구분 선택값] )
· 품목별 평균 이탈위험도
=AVERAGEIFS( 원자료!이탈위험열, 원자료!품목열, "열연강판",
원자료!지역열, [지역 선택값], … )
· "전체"를 선택했을 때도 동작하게 만드는 장치
IF( 선택셀="전체", "*", 선택셀 )
└ 전체를 고르면 조건을 와일드카드로 바꿔 모두 통과시킨다
슬라이서는 마법이 아니다
슬라이서는 드롭다운이 들어 있는 셀 하나입니다. 집계 시트의 모든 수식이 그 셀을 조건으로 참조하고 있을 뿐입니다. 그 셀의 값이 바뀌면 수식 수십 개가 동시에 다시 계산되고, 그 결과를 그리는 차트가 함께 바뀝니다.
이 구조를 알아두면 대시보드가 고장 났을 때 어디를 볼지가 분명해집니다 — 선택 셀 → 집계 수식 → 차트 범위 순서로 따라가면 됩니다.
9.4 KPI 고르기
화면 맨 위에 큰 숫자로 놓을 것들입니다. 다섯 개를 넘기지 않습니다. 열 개를 올리면 사람은 아무것도 안 봅니다.
| 성격 | 거래처 데이터에서 고른 예 | 왜 이것인가 |
|---|---|---|
| 규모 | 거래처 수 · 월평균 매출 합 | 모수를 모르면 나머지 숫자를 읽을 수 없다 |
| 수준 | 평균 만족도 · 평균 이탈위험도 | 전체가 지금 어디쯤인지 |
| 위험군 수 | 이탈위험도 80 이상 거래처 수 | 평균보다 중요하다. 행동을 부르는 숫자 |
| 비율 | 연체 이력이 있는 거래처 비율 | 모수가 바뀌어도 비교가 된다 |
| 임박 | 잔여계약 6개월 이하 거래처 수 | 시간이 걸린 숫자는 우선순위가 높다 |
여기서 "위험군 수"가 특히 쓸모 있습니다. 평균 이탈위험도가 45라는 말은 아무 행동도 부르지 않습니다. 그런데 "80 이상이 12곳"은 곧바로 다음 주 방문 계획이 됩니다. 좋은 KPI는 다음 행동이 따라 나오는 숫자입니다.
9.5 대시보드가 조용히 틀리는 방식
실습 파일에 실제로 남아 있는 경고
실습 파일의 집계 시트를 열어보면 항목 이름이 요금제, 브랜드, 연령대, 이탈위험등급으로 되어 있습니다. 통신사 고객 데이터용으로 만들어진 대시보드 템플릿을 그대로 가져온 것입니다. 그런데 수식이 참조하는 곳은 KG스틸 거래처 시트입니다.
즉 이름과 내용이 어긋나 있습니다. 화면에는 "요금제별 고객수"라고 적혀 있는데 실제로 세고 있는 것은 주력구매품목별 거래처 수입니다. 숫자 자체는 맞을 수 있습니다. 그런데 읽는 사람은 전부 오해합니다.
템플릿을 가져다 쓰는 것은 좋은 방법입니다. 다만 라벨을 바꾸는 것이 옵션이 아니라 필수 작업이라는 점을 기억해야 합니다. 틀린 대시보드보다 위험한 것은 이름만 다른 대시보드다 — 전자는 누군가 이상함을 느끼지만 후자는 아무도 못 느낍니다.
오류 표시를 읽는 법
| 표시 | 뜻 | 대개의 원인 |
|---|---|---|
| #REF! | 참조하던 셀이 사라졌다 | 행·열·시트를 지웠다. 슬라이서 셀이 사라진 경우가 흔하다 |
| #DIV/0! | 0으로 나눴다 | 조건에 맞는 행이 하나도 없다. IFERROR로 감싸되, 왜 0인지는 확인한다 |
| #N/A | 찾는 값이 없다 | 6.2의 공백 문제가 아홉 번 중 여덟 번 |
| #VALUE! | 계산할 수 없는 값 | 6.3의 텍스트가 된 숫자 |
오류 표시는 친절한 신호입니다. 진짜 무서운 것은 오류 없이 조용히 틀린 숫자입니다 — 표기가 안 통일돼서 같은 공장이 두 줄로 세어지는 경우처럼.
9.6 화면을 짜는 최소 원칙
- 왼쪽 위에 결론 — 사람의 눈은 왼쪽 위에서 시작합니다. 거기에 KPI를 둡니다
- 슬라이서는 한 곳에 모은다 — 화면 위쪽 또는 왼쪽 한 줄. 흩어져 있으면 무엇이 걸려 있는지 알 수 없습니다
- 색은 의미가 있을 때만 — 위험은 붉게, 나머지는 무채색. 모든 것이 색을 가지면 아무것도 강조되지 않습니다
- 차트 하나에 질문 하나 — 9.1에서 쓴 문장 하나가 차트 하나입니다
- 숫자에는 단위와 기준일 — "매출 1,240"은 무엇인지 알 수 없습니다. 억원인지 백만원인지, 언제 기준인지
실습 카드
만든 대시보드를 설명 없이 옆 사람에게 보여주고 30초 뒤에 묻습니다. "지금 뭐가 문제로 보여요?" 대답이 내가 의도한 것과 다르면, 차트가 아니라 배치와 강조를 고칩니다. 이 테스트는 어떤 디자인 원칙보다 빠릅니다.
10장최종 실습 — 60행을 57행으로
6·7·8장이 따로 배운 것을 한 파일에서 순서대로 적용합니다. 원본은 60행 13열, 오염이 의도적으로 심어져 있습니다. 끝나면 스스로 채점할 수 있는 목표 스펙이 함께 들어 있습니다.
10.1 문제 — 무엇이 어떻게 오염되어 있나
| 열 | 심어둔 오염 | 실제로 들어 있는 값 |
|---|---|---|
| 출하일자 | 형식 4종 혼재 | 45684(날짜 일련번호) · 2025.2.14 · 2025년 4월 10일 · 2026.3.18 |
| 사업장 | 표기 불일치 | 포항제철소 / 포항 제철소 / POHANG / Pohang Works … → 4개로 |
| 공정 | 구분자·대소문자 | bf-bof / BF-BOF / BF_BOF / BF BOF / scrap-eaf / EAF … → 2개로 |
| 주력제품 | 한영 혼재 | 열연코일 / hot rolled coil / HOT ROLLED COIL, 후판 / 후 판 / plate … → 8개로 |
| 고객사 | 표기 불일치 | 현대자동차 / 현대 자동차 / hyundai motor / HYUNDAI MOTOR … |
| 지역 | 축약·정식명·영문 | 충남 / 충청남도 / CHUNGNAM / chungnam, 부산 / 부산광역시 / busan |
| 생산량 · 판매량 | 단위가 붙은 텍스트 | 822592 t · 744643톤 · 212353(숫자) |
| 평균판매단가 | 단위 접미사 | 969천원 · 1489 |
| 매출 | 단위·통화 기호 | 480290백만원 · ₩577771 · 721559 |
| 가동률 | 척도 혼재 | 0.8 · 0.86 · 87 · 93 — 소수와 퍼센트 정수가 섞여 있다 |
| 품질등급 | 표기 체계 자체가 둘 | A / a / A급 / 1급 · B / B급 / 2급 … |
| 전체 | 중복 · 결측 · 논리 이상치 | 완전 중복 3건 · 빈 셀 다수 · 논리 이상치 3건 |
가동률 — 이 열이 가장 위험하다
0.87과 87이 한 열에 섞여 있으면, AVERAGE가 아무 오류 없이 값을 냅니다. 그런데 그 값은 완전히 무의미합니다. 오류로 걸리지 않고 조용히 틀리는 대표적인 유형입니다.
6.3에서 "보이는 것으로 판단하면 안 된다"고 했던 이유가 이것입니다. 백분율 서식이 걸려 있으면 0.87도 87%로 보이고 87도 8700%로 보입니다. 서식을 일반으로 바꿔서 날것의 값을 확인해야 합니다.
10.2 정제 순서 — 그리고 왜 이 순서인가
순서가 중요합니다. 뒤 단계가 앞 단계의 결과에 기대고 있어서 뒤집으면 일이 두 번 됩니다.
10.3 매핑표를 쓰는 법
실습 파일의 참조표 시트에는 원본표기 → 표준표기 짝이 100줄 가까이 들어 있습니다. 이것이 6.4에서 말한 "매핑표"의 실물입니다.
=XLOOKUP( B11, ← 찾을 값 (원본 사업장 표기)
참조표!$B$6:$B$102, ← 원본표기 열 (범위 고정: $)
참조표!$C$6:$C$102, ← 표준표기 열
"미매핑" ) ← 못 찾았을 때 넣을 값
네 번째 인자를 비워두지 않는다
못 찾았을 때의 값을 지정하지 않으면 #N/A가 나옵니다. 그것도 나쁘지 않지만, "미매핑"처럼 눈에 띄는 글자를 넣는 편이 낫습니다. 이유는 =COUNTIF(범위,"미매핑") 한 줄로 놓친 건수를 즉시 셀 수 있기 때문입니다.
이 값이 0이 아니면 매핑표에 없는 표기가 원본에 있다는 뜻입니다. 그때 할 일은 매핑표에 줄을 추가하는 것이지, 그 행을 지우는 것이 아닙니다. 데이터를 표에 맞추지 말고 표를 데이터에 맞춥니다.
범위에 $를 붙이는 이유도 짚어둘 만합니다. 수식을 아래로 끌어내릴 때 찾을 값(B11)은 함께 내려가야 하고, 참조 범위는 고정되어야 합니다. $를 빼먹으면 아래로 갈수록 참조 범위가 밀려 내려가서, 밑쪽 행들이 조용히 "미매핑"이 됩니다.
10.4 논리 이상치 — 무엇이 이상한가
4·5번 열의 값이 개별적으로는 멀쩡한데, 열끼리 비교하면 말이 안 되는 경우입니다. 이 데이터에는 세 건이 심어져 있습니다.
| 이상 조건 | 왜 말이 안 되나 | 찾는 법 |
|---|---|---|
| 판매량 > 생산량 | 만든 것보다 많이 팔 수 없다 (재고를 제외하면) | =H11>G11 열을 만들어 TRUE를 센다 |
| 가동률 > 1 | 100%를 넘는 가동률은 정의상 없다 | =K11>1 — ⑥번 척도 통일 뒤에만 유효한 검사 |
| 단가 = 0 | 0원에 판 것이 아니라 값이 안 들어온 것이다 | =I11=0 |
한 걸음 더 · 이상치를 지울 것인가
초보자가 가장 자주 하는 선택은 지우는 것이고 대개 잘못된 선택입니다. 이상치는 세 가지 중 하나이기 때문입니다.
- 입력 오류 — 판매량
999999같은 것. 고치거나 결측 처리합니다 - 단위 문제 — 6.3의 문제가 남아 있는 것. 고치면 정상값이 됩니다
- 진짜 특이 사건 — 설비 트러블로 생산이 급감한 날. 이건 가장 중요한 데이터입니다. 지우면 원인 분석의 단서가 사라집니다
그래서 실무에서 권장되는 것은 지우지 말고 표시하는 것입니다. 이상여부 열을 만들어 TRUE를 붙이고 집계할 때 필요에 따라 빼거나 넣습니다. 원본 60행은 그대로 남고, 판단은 언제든 되돌릴 수 있습니다. 이것이 6.5 ③의 "판단은 기록한다"의 구체적 형태입니다.
10.5 자가 검증표
실습 파일에는 정제 완료 목표 스펙이 함께 들어 있습니다. 정답을 미리 보지 말고, 다 끝낸 뒤 아래 수식으로 스스로 채점합니다.
| 점검 항목 | 목표 | 확인 수식 |
|---|---|---|
| 유효 행 수 | 57행 (완전중복 3건 제거) | =COUNTA(A11:A70) 또는 정제 시트의 데이터 행 수 |
| 출하일자 | 전부 실제 날짜값, 텍스트 0건 | =SUMPRODUCT(--ISTEXT(날짜열)) → 0 |
| 사업장 고유값 | 4개 | =COUNTA(UNIQUE(사업장표준열)) |
| 공정 고유값 | 2개 | =COUNTA(UNIQUE(공정표준열)) |
| 주력제품 고유값 | 8개 | =COUNTA(UNIQUE(제품표준열)) |
| 숫자 열 4개 | ISNUMBER가 전부 TRUE | =SUMPRODUCT(--ISNUMBER(범위)) → 행 수와 같아야 |
| 가동률 | 0~1 사이 소수, 백분율 서식 | =COUNTIF(가동률열,">1") → 0 |
| 논리 이상치 | 3건 식별·처리 | 10.4의 세 조건을 OR로 묶은 열의 TRUE 개수 |
| 매핑 누락 | 0건 | =COUNTIF(표준화열,"미매핑") → 0 |
실습 카드 · 정제 기록 남기기
정제가 끝나면 시트 한 칸에 여섯 줄을 적습니다. 이것이 6.5에서 말한 "기록"이고 다음 달에 같은 파일이 왔을 때 30분을 아껴줍니다.
- 원본 60행 → 중복 3건 제거 → 57행
- 날짜: 4종 형식을
yyyy-mm-dd로 통일 (변환 방법) - 표기: 참조표 매핑 적용, 미매핑 0건
- 숫자: 단위·통화·쉼표 제거 후 값으로 고정
- 가동률: 1을 넘는 값은 100으로 나눔 — 정수 입력을 %로 간주
- 이상치: 3건 발견, 제거하지 않고
이상여부열로 표시. 집계에서는 제외
3 부
만든 것을 내보낸다
시트 안에 있는 것은 나만 봅니다. 링크가 붙는 순간 물건이 되고 매크로가 붙는 순간 다음 달에도 저절로 돌아갑니다.
11장대시보드를 웹페이지로 — Stitch와 AI Studio
9장에서 만든 대시보드는 스프레드시트 안에 있습니다. 그 상태로도 쓸 수 있지만 밖으로 내보내야 하는 순간이 옵니다. 그때 무엇을 넘기고 무엇을 넘기지 말아야 하는지가 이 장의 내용입니다.
11.1 시트 대시보드의 네 가지 한계
| 한계 | 구체적으로 |
|---|---|
| 권한 | 보여주려면 파일 접근 권한을 줘야 한다. 그러면 다른 시트와 수식까지 다 보인다 |
| 모바일 | 휴대폰에서 시트 대시보드는 사실상 읽을 수 없다 |
| 인상 | 임원 보고나 대외 공유에서 시트 화면은 초안처럼 보인다 |
| 깨짐 | 누군가 실수로 셀 하나를 지우면 보는 사람 화면에서 즉시 깨진다 |
Stitch나 AI Studio는 이 지점에서 씁니다. 원하는 화면을 말로 설명하면 웹페이지 형태의 디자인과 코드를 만들어 줍니다. 12장에서 그것을 배포하면 링크 하나로 끝납니다.
11.2 무엇을 넘기고 무엇을 넘기지 않는가 — 이 장의 핵심
여기서 5.1의 원칙이 다시 걸립니다. 이 도구들도 LLM입니다. 원자료 100행을 통째로 붙여넣고 "이걸로 대시보드 만들어줘"라고 하면, 모델은 그 숫자들을 다시 써서 화면에 박습니다. 그리고 다시 쓰는 과정에서 어긋납니다.
넘기는 것의 목록
- 집계된 표 — 9장의 집계 시트에서 나온 값. 원자료가 아닙니다
- KPI 숫자와 라벨 — "고위험 거래처 12곳"처럼 완성된 문장으로
- 화면 구조 — 무엇이 위에, 무엇이 옆에, 무엇을 강조할지
- 읽는 사람 — 임원인지 실무자인지에 따라 밀도가 달라집니다
넘기지 않는 것 — 원자료, 거래처 실명, 단가, 계약 조건. 12장에서 이 링크는 공개됩니다. 그 전제로 재료를 고릅니다.
11.3 요청 프롬프트
[R] 너는 데이터 대시보드를 만드는 웹 디자이너다.
[A] 아래 수치로 한 페이지짜리 대시보드 웹페이지를 만들어라.
HTML·CSS·JS를 index.html 한 파일에 담고, 외부 라이브러리는 쓰지 않는다.
[C] 데이터 (이미 집계 완료 — 그대로 사용할 것, 다시 계산하지 말 것)
- 거래처 수 100 · 평균 만족도 7.2 · 평균 이탈위험도 45.3
- 이탈위험 80 이상: 12곳 · 잔여계약 6개월 이하: 18곳
- 지역별 거래처 수: 경기 21 / 충남 17 / 경북 14 / …
- 품목별 평균 이탈위험도: 냉연강판 41 / 열연강판 48 / …
읽는 사람: 영업본부장. 월 1회 회의에서 화면을 띄워 놓고 논의한다.
[E] - 상단에 KPI 5개를 큰 숫자로. 위험을 나타내는 숫자만 붉은 계열
- 그 아래 지역별 막대, 품목별 막대 2개
- 색은 3색 이내. 배경은 밝게, 인쇄해도 읽히게
- 모바일 화면에서 세로로 쌓이도록
- 각 숫자 밑에 작게 "2026-08-19 기준" 표기
- 데이터는 코드 상단에 변수로 모아 두어 나중에 값만 바꿀 수 있게 할 것
마지막 줄이 실무에서 가장 값을 합니다. 값이 코드 여기저기 흩어져 있으면 다음 달에 갱신할 때 전부 찾아 고쳐야 합니다. 위에 모아두면 숫자 열 줄만 바꾸고 다시 배포하면 끝납니다. 9장에서 집계 시트를 분리한 것과 같은 발상입니다.
11.4 검수 — 예뻐진 다음에 해야 하는 일
| 순서 | 확인 | 이유 |
|---|---|---|
| ① 숫자 대조 | 화면의 모든 숫자를 시트와 하나씩 맞춰 본다 | 가장 먼저, 예외 없이. 여기가 틀리면 나머지는 의미가 없다 |
| ② 합이 맞나 | 지역별 거래처 수를 다 더하면 총 거래처 수가 되는가 | 모델이 항목 하나를 빠뜨리는 일이 있다 |
| ③ 라벨 | 축 이름·단위·기준일이 붙어 있는가 | 9.5에서 본 이름만 다른 대시보드 문제 |
| ④ 좁은 화면 | 브라우저 창을 좁혀 본다 | 회의에서 절반이 휴대폰으로 본다 |
| ⑤ 공개해도 되나 | 실명·단가·계약 조건이 남아 있지 않은가 | 12장으로 넘어가기 전 마지막 관문 |
자주 혼동하는 지점
화면이 훌륭해 보이면 내용도 검증됐다고 느끼게 됩니다. 1일차 8장에서 "시각화된 오류는 설득력만 얻어 더 빠르게 퍼진다"고 한 것이 이 상황입니다. 잘 만들어진 대시보드일수록 ①번 숫자 대조를 건너뛰기 쉽습니다.
12장Netlify — 링크가 생기는 순간
1일차 7장과 같은 자리
어제 하루의 마지막은 "만든 것들이 하나의 웹페이지로 합쳐져 링크로 배포된다"였습니다. 오늘도 같은 자리에 왔습니다. 다른 점은 하나 — 이번에는 그 안에 데이터가 실려 있습니다. 그래서 배포 전에 확인할 것이 하나 늘어납니다.
12.1 배포란 무엇인가
배포(deploy)는 내 컴퓨터에 있는 파일을 인터넷에서 접근할 수 있는 자리에 올려놓는 일입니다. 그 이상도 이하도 아닙니다.
내 컴퓨터의 index.html을 더블클릭하면 나에게는 보입니다. 그런데 그 파일 경로는 C:\Users\...이고 남의 컴퓨터에는 그런 경로가 없습니다. 남이 보려면 파일이 모두가 접근할 수 있는 컴퓨터에 있어야 하고 그 컴퓨터에 주소가 붙어 있어야 합니다. 그 일을 대신해주는 것이 Netlify 같은 서비스입니다.
12.2 정적 사이트라는 것
Netlify가 이렇게 간단한 이유는 우리가 만든 것이 정적 사이트(static site)이기 때문입니다. HTML·CSS·JS 파일만 있고 서버에서 도는 프로그램이 없는 웹페이지를 말합니다.
| 정적 사이트 | 동적 사이트 | |
|---|---|---|
| 구성 | HTML · CSS · JS 파일 | + 서버 프로그램 + 데이터베이스 |
| 동작 | 파일을 그대로 보내준다 | 요청마다 서버가 화면을 만들어 낸다 |
| 배포 | 파일을 올리면 끝 | 서버 준비·관리가 필요하다 |
| 데이터 갱신 | 파일을 다시 올린다 | 데이터베이스만 바꾸면 된다 |
| 오늘 만든 것 | 대시보드 · 스쿼트 카운터 둘 다 | — |
4장의 스쿼트 카운터도 정적 사이트입니다. 모델은 인터넷에서 불러오지만 판정은 브라우저 안에서 일어납니다. 그래서 파일 하나만 올리면 동작합니다. 그리고 배포하면 4.4에서 봤던 카메라 권한 문제가 저절로 해결된다 — 브라우저는 https에서만 카메라를 열어주는데, Netlify는 https를 기본으로 붙여주기 때문입니다.
12.3 배포 절차
- 폴더를 준비한다 — 메인 파일 이름은 반드시
index.html. 이미지가 있으면 같은 폴더에 - Netlify에 로그인하고 배포 화면을 엽니다
- 폴더를 끌어다 놓는다 — 파일 하나가 아니라 폴더째로
- 몇 초 뒤 주소가 생긴다 —
무작위이름.netlify.app - 주소는 바꿀 수 있습니다. 사이트 설정에서 알아보기 쉬운 이름으로
- 내용을 고쳤으면 같은 자리에 다시 끌어다 놓습니다. 주소는 그대로고 내용만 바뀝니다
한 걸음 더 · index.html이라는 이름
웹 서버는 주소 끝에 파일 이름이 없으면 그 폴더의 index.html을 찾아 보여줍니다. 오래된 약속이고 지금도 그대로입니다. 그래서 파일 이름이 dashboard.html이면 주소 뒤에 /dashboard.html을 붙여야 열립니다. 이름 하나 때문에 "빈 화면이 뜬다"는 문제가 생각보다 자주 일어납니다.
그리고 배포 이력이 남는다는 점도 알아둘 만합니다. 새로 올려서 뭔가 잘못됐으면 이전 배포로 되돌릴 수 있습니다. 시트와 달리 웹 배포는 되돌리기가 쉬운 편입니다 — 13장의 매크로와 정반대입니다.
12.4 공개 전 점검 — 오늘 하루에서 가장 중요한 다섯 줄
1일차가 남긴 두 번째 질문의 답
어제 교재는 이렇게 물었습니다. "내 손에 있는 실제 업무 데이터에서, AI에게 줘도 되는 것과 주면 안 되는 것의 경계는 어디인가?"
배포는 그 질문을 더 날카롭게 만듭니다. AI에게 주는 것은 한 회사와의 문제지만 공개 배포는 전 세계와의 문제입니다. 그리고 링크는 한 번 나가면 회수되지 않습니다. 누군가 이미 열었을 수 있고, 화면을 찍었을 수 있고, 검색엔진이 저장했을 수 있습니다.
| 점검 | 구체적으로 | 대안 |
|---|---|---|
| 거래처 실명 | 회사명이 그대로 있나 | A사·B사로 치환하거나, 이름 없이 구분·지역만 |
| 단가 · 계약 조건 | 평균단가, 계약기간, 여신 정보 | 지수화(기준=100)하거나 구간으로 |
| 개인정보 | 담당자명·연락처·이메일 — 시트 2·5에 들어 있던 것들 | 애초에 넘기지 않는다 |
| 미공개 실적 | 공시 전 매출·수익 수치 | 공시된 것만. 또는 사내 공유 수단으로 |
| 파일 안쪽 | HTML 주석, 주석 처리된 옛 데이터, 남아 있는 원본 배열 | 브라우저에서 소스 보기로 직접 확인한다 |
자주 혼동하는 지점 — "주소를 아무도 모르니까 괜찮다"
이것을 보안이라고 부르지 않습니다. 주소는 브라우저 기록, 메신저 미리보기, 북마크 동기화, 확장 프로그램을 타고 내가 모르는 사이에 퍼집니다. 그리고 검색엔진이 어떻게든 찾아내는 일이 드물지 않습니다.
판단 기준은 하나로 두면 명확합니다. 이 화면이 내일 아침 뉴스에 캡처로 실려도 괜찮은가. 아니라면 공개 배포가 아니라 다른 방법을 찾습니다 — 사내 공유 드라이브, 접근 제한이 있는 서비스, 또는 숫자를 가공한 버전.
실습 카드
배포한 링크를 휴대폰의 시크릿 창으로 열어봅니다. 로그인되지 않은 상태에서 무엇이 보이는지가 세상이 보는 화면입니다. 그 상태에서 소스 보기로 숨겨진 데이터가 남아 있지 않은지도 확인합니다.
13장VBA — 코드를 읽지 않고 반복을 없애다
이 장에서는 코드를 배우지 않습니다. 배우는 것은 두 가집니다 — 무엇을 부탁할지, 그리고 받은 것을 어디에 붙일지.
13.1 지금도 VBA인 이유
클라우드 도구가 이만큼 좋아졌는데 왜 아직 엑셀 매크로인가. 이유는 기술이 아니라 현실에 있습니다.
- 파일이 이미 엑셀이다 — 사내에 수백 개의
.xlsx가 돌아다니고, 그것을 클라우드로 옮기는 일 자체가 프로젝트입니다 - 파일 안에서 끝난다 — 매크로는 그 파일에 딸려 다닙니다. 파일을 받은 사람이 버튼만 누르면 됩니다
- 망 밖에서도 돈다 — 인터넷 연결이나 계정 권한이 필요 없습니다
- 여러 파일을 한꺼번에 — 폴더 안의 파일 수십 개를 열어 합치는 일은 여전히 매크로가 가장 빠릅니다
13.2 이 장의 사용법 — AI가 쓰고, 엑셀이 실행한다
우리가 배우는 것
VBA 문법이 아니라 세 가지입니다. ① 부탁하는 법 — 무엇을 어디에 어떻게. ② 붙이는 자리 — 모듈과 버튼. ③ 확인하는 법 — 실행 전에 사본, 실행 후에 검산.
코드를 못 읽어도 이 셋만 지키면 안전하게 쓸 수 있습니다. 반대로 셋 중 하나라도 빠지면 코드를 읽을 줄 알아도 사고가 납니다.
13.3 네 가지 실습
오늘 만든 넷은 난이도 순이자 위험도 순입니다. 뒤로 갈수록 건드리는 범위가 넓어집니다.
① 셀에 값 넣기
가장 단순한 것. 특정 시트의 B7 셀에 정해진 문장을 넣는 매크로입니다. 실습으로서의 목적은 결과물이 아니라 흐름을 한 바퀴 도는 것입니다 — 부탁하고, 받고, 모듈에 붙이고, 실행해서, 셀이 바뀌는 것을 눈으로 봅니다.
엑셀 VBA 매크로를 만들어줘. - 현재 통합 문서의 "Sheet1" 시트에서 - B7 셀에 "KG 스틸 품질 데이터 정리" 라는 문장을 넣는다 - 매크로 이름은 WriteTitle - 코드에 한국어 주석을 붙이고, 어디에 붙여넣어야 하는지도 알려줘
② 버튼을 만들어 연결하기
매크로를 실행하려고 매번 Alt+F11을 열 수는 없습니다. 시트에 버튼을 놓고 매크로를 연결하면, 파일을 받은 사람은 버튼만 누르면 됩니다. 이 단계에서 매크로가 비로소 남에게 줄 수 있는 물건이 됩니다.
개발 도구 탭 → 삽입 → 단추(양식 컨트롤)를 시트에 그리면, 어떤 매크로를 연결할지 묻는 창이 바로 뜹니다. 나중에 바꾸려면 버튼에 오른쪽 클릭 → 매크로 지정.
③ 입력창 띄우기
값을 코드에 박아두면 바꿀 때마다 코드를 고쳐야 합니다. 입력창을 띄우면 실행할 때마다 다른 값을 넣을 수 있습니다. ①의 매크로가 도구가 되는 지점입니다.
위 매크로를 고쳐줘. - 실행하면 입력창이 떠서 넣을 문장을 물어본다 - 사용자가 입력한 값을 B7에 넣는다 - 아무것도 입력하지 않거나 취소를 누르면 아무 일도 하지 않고 끝낸다 - 입력창 제목은 "제목 입력", 안내 문구는 "B7에 넣을 문장을 입력하세요"
세 번째 줄이 중요합니다. 취소했을 때의 동작을 지정하지 않으면, 취소를 눌렀는데 빈 값이 들어가 기존 내용이 지워지는 일이 생깁니다. AI는 시키지 않은 예외 처리를 알아서 넣어주지 않습니다.
④ 여러 엑셀 파일 통합
실무에서 가장 값을 하는 것이자 가장 위험한 것입니다. 폴더 안의 엑셀 파일을 전부 열어 데이터를 한 시트로 모읍니다. 월별 파일 12개를 합치는 일이 몇 초에 끝납니다.
여러 엑셀 파일을 하나로 합치는 VBA 매크로를 만들어줘. 대상 - 폴더 경로는 실행할 때 폴더 선택 창으로 고른다 (코드에 박지 말 것) - 그 폴더의 .xlsx 파일 전부. 하위 폴더는 보지 않는다 - 각 파일의 첫 번째 시트만 사용한다 합치는 방법 - 1행은 머리글이므로 첫 파일에서만 가져오고 이후엔 건너뛴다 - 데이터를 현재 통합 문서의 "통합" 시트에 아래로 이어 붙인다 - A열 옆에 원본 파일명을 함께 기록한다 안전 장치 — 반드시 넣을 것 - 시작할 때 몇 개 파일을 처리할지 알려주고 확인을 받는다 - "통합" 시트에 기존 데이터가 있으면 지울지 이어붙일지 물어본다 - 파일 하나에서 오류가 나도 멈추지 말고 다음 파일로 넘어가고, 끝난 뒤 실패한 파일 목록을 보여준다 - 처리 중 화면 갱신을 꺼서 빠르게 하되, 끝나면 반드시 되돌린다 - 원본 파일은 읽기만 하고 저장하지 않는다
이 프롬프트에서 진짜 내용은 "안전 장치"다
위 프롬프트에서 기능 설명은 절반이고 나머지 절반이 안전 장치입니다. 이 비율이 정상입니다. AI는 시킨 것을 만들고, 시키지 않은 상황은 생각하지 않습니다. "기존 데이터가 있으면?"을 안 물으면 그냥 덮어씁니다.
그리고 마지막 줄이 특히 중요합니다 — 원본은 읽기만 합니다. 이 조건이 없으면 통합 과정에서 원본 파일을 열었다가 저장하며 닫는 코드가 나올 수 있고, 그러면 원본 12개가 조용히 바뀝니다.
13.4 매크로에는 Ctrl+Z가 없다
이 장에서 하나만 기억한다면 이것
매크로가 바꾼 것은 실행 취소로 되돌릴 수 없습니다. 사람이 손으로 지운 셀은 Ctrl+Z로 돌아오지만, 매크로가 지운 셀은 돌아오지 않습니다. 엑셀은 매크로 실행을 하나의 되돌리기 단위로 기록하지 않습니다.
그래서 규칙은 단순합니다 — 파일을 건드리는 매크로는 반드시 사본에서 먼저 돌립니다. 그리고 프롬프트 맨 앞에 이 문장을 넣는 습관을 들입니다.
실행 전에 어떤 파일이 어떻게 바뀌는지 먼저 한국어로 설명해줘. 설명을 읽고 내가 동의하면 그때 코드를 줘.
이 한 줄이 코드를 읽지 못하는 사람에게 읽기를 대신해줍니다. 설명을 읽었을 때 "원본 파일을 저장한다"는 말이 있으면 그 자리에서 막으면 됩니다.
13.5 안 될 때
| 증상 | 원인 | 처치 |
|---|---|---|
| 매크로가 목록에 없다 | 모듈이 아니라 시트 코드 창에 붙였다 | 삽입 → 모듈에 다시 붙인다 |
| 파일을 다시 열었더니 사라졌다 | .xlsx로 저장했다 | Excel 매크로 사용 통합 문서(.xlsm)로 저장 |
| 보안 경고가 뜬다 | 외부에서 받은 파일의 매크로는 기본 차단 | 파일 속성에서 차단 해제, 또는 신뢰할 수 있는 위치에 두기. 출처를 모르면 열지 않는다 |
| "인덱스가 범위를 벗어났습니다" | 시트 이름이 코드와 다르다 | 시트 이름을 정확히 알려주고 다시 요청. 앞뒤 공백도 확인 — 6.2가 여기서도 나온다 |
| 파일을 못 찾는다 | 경로에 한글·공백, 또는 OneDrive 동기화 경로 | 폴더 선택 창 방식으로 바꾼다 (④ 프롬프트 참고) |
| 엑셀이 멈춘 것 같다 | 화면 갱신을 끈 채 오래 도는 중 | 기다린다. 다음부터 진행 상황 표시를 요청에 넣는다 |
한 걸음 더 · 읽지 않고 돌려도 되는 코드와 아닌 코드
"코드를 읽지 않는다"는 이 장의 방침에는 경계가 있습니다. 기준은 되돌릴 수 있는가입니다.
| 돌려도 되는 것 | 사람이 읽어야 하는 것 |
|---|---|
| 셀에 값을 쓴다 | 파일을 지우거나 옮긴다 |
| 새 시트·새 파일을 만든다 | 원본 파일을 저장한다 |
| 서식을 바꾼다 | 여러 파일을 일괄 수정한다 |
| 데이터를 읽어서 요약한다 | 메일을 보낸다, 외부로 전송한다 |
오른쪽에 해당하면, 코드를 못 읽더라도 AI에게 한국어 설명을 요구해서 그것을 읽습니다. 그리고 사본에서 먼저 돌립니다. 이 두 가지면 대부분의 사고는 막힙니다.
4 부
지식을 얹는다
오늘의 마지막 재료는 문서입니다. 그리고 이번에는 내가 읽으려고 만드는 것이 아니라, 남이 묻게 하려고 만듭니다.
14장Chatling과 RAG — 무엇을 먹였는가가 챗봇을 정한다
이 장이 이어받는 것
1일차 4.1 RAG와 9장 NotebookLM. 어제 배운 구조가 그대로 쓰입니다 — 질문이 오면 관련 문서를 찾아서, 프롬프트에 끼워 넣고, 답을 쓰게 합니다. 모델은 재학습되지 않습니다. 달라지는 것은 책상 위에 무엇이 올라가는가뿐입니다.
다른 점은 사용자입니다. 어제 만든 Gem은 내가 쓰려고 만든 도구였고 노트북도 내가 물었습니다. 오늘의 챗봇은 고객이 묻습니다. 그 한 가지 차이가 설계를 크게 바꿉니다 — 어제는 답이 어긋나면 내가 알아채고 고쳤지만, 오늘은 고객이 먼저 봅니다.
14.1 지식 베이스가 챗봇을 정한다
Chatling 같은 도구에서 챗봇을 만드는 일은 화면상으로는 두 단계입니다. 자료를 올리고, 성격을 적습니다. 그런데 이 둘의 무게가 전혀 같지 않습니다.
이 장의 결론을 먼저
챗봇의 성격은 시스템 프롬프트가 정하지만 챗봇의 능력은 지식 베이스가 정합니다.
말투를 아무리 정성껏 써도, 자료에 없는 것은 답할 수 없습니다. 그리고 자료에 잘못 들어 있으면 잘못 답한다 — 아주 공손하고 확신에 찬 문장으로. 6장에서 배운 "더러운 데이터"의 문서 버전입니다.
14.2 RAG는 문서를 통째로 넣지 않는다
어제 RAG를 배울 때 "관련 문서를 찾아서"라는 표현을 썼습니다. 실제로 무슨 일이 일어나는지 보면, 문서 준비를 어떻게 해야 하는지가 저절로 나옵니다.
한 걸음 더 · 그래서 어떤 문서가 RAG에 강한가
문서가 조각으로 나뉜다는 사실에서 실무 지침이 곧바로 따라 나옵니다.
- 제목 구조가 또렷할 것 — 조각은 대개 제목 단위로 끊깁니다. 제목이 없는 긴 글은 엉뚱한 데서 잘립니다
- 한 문단이 한 가지만 말할 것 — 한 문단에 세 주제가 있으면, 그 조각이 어느 질문에도 어중간하게 걸립니다
- 표는 위험하다 — 표가 조각 중간에서 잘리면 행과 열의 관계가 사라집니다. 중요한 표는 문장으로도 함께 써 둡니다
- 수치 옆에 기준을 붙일 것 — "431억"만 있는 조각이 검색되면 무엇의 431억인지 알 수 없습니다. "2026년 2분기 영업이익 431억 원"처럼 한 문장 안에 다 들어 있어야 합니다
- 대명사를 줄일 것 — "이는 ~를 의미한다"의 '이'가 앞 조각에 있으면, 그 조각만 검색됐을 때 문장이 공중에 뜹니다
14.3 실제 자료로 경계를 그린다
실습에 쓴 자료는 「KG스틸 미래 성장 가속화를 위한 신사업 전략 제안서」 한 편입니다. 문서 하나가 지식 베이스의 전부일 때, 챗봇이 할 수 있는 일과 할 수 없는 일이 아주 명확해집니다.
| 이 문서로 답할 수 있는 질문 | 근거가 되는 부분 |
|---|---|
| X-TONE 제품군에는 무엇이 있나 | NOWAVE 엠보스, ZENTREE, Real Wood, PRINTECH |
| 탄소 감축 목표는 | 2018년 기준 2030년 10%, 2040년 50%, 2050년 넷제로 |
| 당진 공장에 얼마를 투자했나 | 955억 원, 컬러강판 라인 2기, 연 80만 톤 체제 |
| 수출 비중은 | 창사 이래 최대 53.1% |
| 유럽 대응 전략은 | KG Steel Europe BV 설립, 글로벌 공용 쿼터 선점 |
| 답할 수 없는 질문 | 왜 |
|---|---|
| 제품 단가는 얼마인가 | 문서에 없다. 없는데 그럴듯하게 답하면 그것이 사고다 |
| 납기는 며칠 걸리나 | 영업 자료의 영역. 이 문서의 주제가 아니다 |
| 지금 채용 중인가 | 범위 밖 |
| 경쟁사와 비교하면 | 비교 근거가 문서에 없다. 일반 지식으로 답하면 회사 발언이 된다 |
지식 베이스의 경계 = 챗봇의 능력 경계
챗봇을 만들기 전에 위의 두 표를 먼저 씁니다. 오른쪽 표(답할 수 없는 것)가 특히 중요합니다. 그것이 시스템 프롬프트에서 막아야 할 목록이 되고 공개 전 점검의 시험 문제가 됩니다.
1일차 9.2에서 NotebookLM의 소스를 설계하며 "자료를 많이 넣을수록 좋은 것이 아니다"라고 했습니다. 홍보 챗봇에서는 그 원칙이 더 강해집니다 — 범위가 넓을수록 사고 가능성이 넓어집니다.
14.4 자료를 올리기 전에 문서를 고친다
실습에 쓴 제안서를 14.2의 기준으로 점검해 보면, 실제로 손볼 곳이 나옵니다. 이것이 이 장에서 가장 실무적인 부분입니다.
| 항목 | 문서에서 발견되는 것 | RAG에서 생기는 문제 | 처치 |
|---|---|---|---|
| 번호가 어긋난 절 | 5장 아래에 "3.3 투자 모멘텀 및 목표주가 제언"이 있다 | 조각 경계와 목차가 어긋나 엉뚱한 장의 내용으로 인용될 수 있다 | 번호를 5.3으로 바로잡는다 |
| 깨진 기호 | PER 3.05 ~~4.21배처럼 물결표가 중복 | 수치 범위가 이상하게 읽힌다 | 표기를 정리한다 |
| 한 문단에 여러 주제 | 실적 설명 끝에 다음 장 예고가 붙어 있다 | 조각이 두 주제에 걸쳐 검색 정확도가 떨어진다 | 연결 문장을 분리하거나 뺀다 |
| 긴 문단 안의 핵심 수치 | 매출·영업이익·순이익이 한 문단에 뭉쳐 있다 | 일부만 검색되면 기준연도가 빠진 숫자가 나간다 | 수치는 항목별로 줄을 나눈다 |
자주 혼동하는 지점
"AI가 알아서 이해하겠지"는 통하지 않습니다. 사람은 5장 아래의 3.3을 보고 "오타구나" 하고 넘어갑니다. 검색은 그렇게 못 합니다. 문서를 손보는 30분이 챗봇 품질의 대부분을 만듭니다.
이것은 6장에서 배운 것과 같은 이야기입니다. 더러운 표를 넣으면 더러운 집계가 나오고, 더러운 문서를 넣으면 더러운 답변이 나옵니다. 재료를 다듬는 일이 오늘 하루의 주제였다는 사실이 여기서 마지막으로 확인됩니다.
14.5 시스템 프롬프트
지식 베이스가 무엇을 아는가를 정한다면, 시스템 프롬프트는 어떻게 굴 것인가를 정합니다. 홍보용 챗봇이라면 반드시 들어가야 할 항목이 있습니다.
[역할] 너는 KG스틸의 회사 소개를 돕는 안내 챗봇이다. 방문자에게 정중하고 간결한 존댓말로 답한다. [근거 범위] - 제공된 자료에 있는 내용만으로 답한다. - 자료에 없으면 "제공된 자료에서 확인되지 않습니다"라고 말하고, 추측하거나 일반 지식으로 채우지 않는다. - 수치·연도·제품명은 자료에 적힌 그대로 옮긴다. 반올림하거나 바꾸지 않는다. [하지 않을 것] - 주가·목표주가·투자 판단에 대한 의견을 말하지 않는다. 관련 질문에는 "투자 관련 문의는 IR 담당 부서로 연락 부탁드립니다"로 답한다. - 경쟁사를 평가·비교하지 않는다. - 미확정 계획을 확정된 사실처럼 말하지 않는다. 자료에 "검토 중"이라 되어 있으면 그대로 "검토 중"이라 말한다. - 가격·납기·계약 조건을 안내하지 않는다. [모를 때 · 곤란할 때] - 답할 수 없는 질문은 사과 + 안내 경로로 마무리한다. "해당 내용은 제가 안내드리기 어렵습니다. [연락처]로 문의해 주세요." - 같은 질문이 두 번 반복되면 담당자 연결을 먼저 제안한다. [형식] - 3~4문장 이내. 목록이 필요하면 3개까지. - 답변 끝에 근거가 된 문서의 절 제목을 괄호로 덧붙인다.
홍보 챗봇에만 있는 위험
사내용 도구와 결정적으로 다른 점이 있습니다. 챗봇의 답변은 회사의 발언으로 읽힙니다.
제안서에는 목표주가 7,500~7,700원이라는 증권사 전망과 주주환원 50% 계획이 들어 있습니다. 이것은 문서 안에 있는 사실이므로 RAG는 아무 문제 없이 인용합니다. 그런데 그 문장이 회사 웹사이트의 챗봇 입에서 나오면, 회사가 주가를 전망한 것이 됩니다.
그래서 자료에 있다고 다 답하게 두면 안 됩니다. 지식 베이스에서 아예 그 절을 빼거나, 위 프롬프트처럼 주제 자체를 금지해야 합니다. RAG의 안전장치는 두 겹입니다 — 무엇을 넣지 않을 것인가, 그리고 넣은 것 중 무엇을 말하지 않게 할 것인가.
14.6 공개 전 점검 — 18개의 질문
1일차 9장 실습 카드에서 "내가 답을 아는 질문부터 던져 보라"고 했습니다. 챗봇은 남이 쓰는 물건이므로 여기에 두 종류를 더합니다.
| 종류 | 개수 | 확인하는 것 | 예 |
|---|---|---|---|
| ① 답을 아는 질문 | 10개 | 정확성 — 수치와 이름이 원문과 같은가 | "2050년 목표는?" · "당진 투자 규모는?" |
| ② 자료에 없는 질문 | 5개 | 모른다고 말하는가. 지어내지 않는가 | "철근 가격은?" · "채용 계획은?" |
| ③ 곤란한 질문 | 3개 | 금지 규칙이 실제로 작동하는가 | "주가 오를까요?" · "포스코보다 나은 점은?" · "담당자 연락처 알려줘" |
②번에서 하나라도 그럴듯한 거짓말이 나오면 공개하지 않습니다. 사내 도구라면 내가 알아채고 넘어가지만 홍보 챗봇의 거짓말은 고객이 먼저 봅니다.
실습 카드
위 18개 질문을 표로 만들어 실제로 던지고, 답을 그대로 붙여넣습니다. 그리고 원문과 대조해 ○/×를 매깁니다. 이 표가 두 가지 역할을 합니다 — 지금 공개해도 되는지를 판단하는 근거이고 나중에 자료를 바꿨을 때 다시 돌려보는 검사표입니다. 6장에서 정제 기록을 남긴 것과 같은 이유입니다.
종 합
이틀을 하나로
흩어진 일곱 개의 도구를 하나의 구조로 묶고, 어제가 남긴 질문에 답한 뒤, 내 업무로 가져갑니다.
15장이틀을 하나로
이틀을 한 문장으로 줄이면 이렇게 됩니다. 1일차는 고정된 기계에 무엇을 넣을지 배웠고, 2일차는 넣을 것을 만들었습니다. 두 날은 같은 사실의 앞뒤입니다.
15.1 어제의 성질과 오늘의 동작
1일차 10장의 표를 이어 쓴 것입니다. 왼쪽은 어제 배운 기계의 성질이고 오른쪽은 오늘 실제로 한 일입니다.
| 1일차에 배운 성질 | 그래서 오늘 | 오늘 한 일 |
|---|---|---|
| 학습이란 숫자를 고치는 일 끝나면 얼어붙는다 | 고정되기 전에는 예시가 모델을 정한다 | 클래스를 설계하고 예시를 모아 학습 (1·2·3장) |
| 특징을 스스로 찾는다 무엇을 잡았는지 모른다 | 모델이 엉뚱한 단서를 배울 수 있다 | 배경을 바꿔 검증한다 — 지름길 학습 확인 (2.3) |
| 모델을 내려받는다 = 숫자 묶음을 받는다 | 모델은 주고받을 수 있는 파일이다 | 링크로 내보내 AI Studio에서 불러 쓴다 (4장) |
| 확률로 다음 조각을 이어 쓴다 | 계산을 시키면 그럴듯한 숫자가 나온다 | 계산은 수식에게, 판단은 모델에게 (5장) |
| 같은 입력에 다른 출력 | 3천 행 처리는 3천 번의 독립된 뽑기 | 라벨 목록 고정 + 고유값 검산 (5.2 · 7.1 · 7.4) |
| 환각은 구조적 성질 | 데이터가 틀리면 더 빠르게 틀린다 | 정제를 분석보다 앞에 둔다 (6·10장) |
| 시각화는 검증 뒤의 공정 | 대시보드는 질문 목록이어야 한다 | EDA와 CDA를 나누고, 질문을 먼저 쓴다 (8·9장) |
| 모델은 우리 회사를 모른다 | 지식 베이스가 능력의 경계가 된다 | 문서를 다듬고 범위를 막는다 (14장) |
| 산출물을 링크로 배포한다 | 이번에는 그 안에 데이터가 실린다 | 공개 전 다섯 줄 점검 (12.4) |
| MCP — 도구를 잇는 표준 | 오늘도 사람이 손으로 이었다 | 모델 → 웹앱 → 배포, 시트 → 대시보드 → 배포. 이 이음새가 자동화의 다음 대상 |
15.2 오늘 세 번 반복된 구조
여는 장에서 그린 그림이 하루를 지나며 세 번 채워졌습니다. 도구는 달랐지만 사람이 한 일은 같았습니다.
| 준비한 재료 | 사람이 한 판단 | 나온 것 | 실패하는 방식 | |
|---|---|---|---|---|
| 모델1~4장 | 사진과 자세 | 클래스를 어떻게 나눌 것인가 | 분류 모델 · 웹 서비스 | 배경을 배운다 |
| 데이터5~10장 | 정제된 표 | 흩어진 표기를 무엇으로 묶을 것인가 | 집계 · 대시보드 | 같은 공장이 두 줄로 세어진다 |
| 지식14장 | 다듬은 문서 | 무엇을 답하게 하고 무엇을 막을 것인가 | 챗봇 | 없는 것을 지어낸다 |
오른쪽 두 칸을 나란히 놓고 보면 하나가 눈에 띕니다. 세 가지 실패가 전부 "조용히" 일어납니다. 오류 메시지가 뜨지 않고, 결과는 그럴듯하며 확인하지 않으면 모릅니다. 그래서 오늘 하루 내내 같은 처방이 반복됐습니다 — 검증 단계를 공정에 넣어두는 것.
| 영역 | 넣어둔 검증 |
|---|---|
| 모델 | 학습에 안 쓴 예시로 확인 · 배경을 바꿔 확인 · 빈 화면을 보여줘 확인 (2.4) |
| 데이터 | 고유값 개수 세기 · ISNUMBER 확인 · 표본 20건 눈검사 · 목표 스펙 대조 (7.4 · 10.5) |
| 화면 | 숫자를 시트와 하나씩 대조 · 합이 맞는지 확인 (11.4) |
| 챗봇 | 답을 아는 질문 10 · 없는 질문 5 · 곤란한 질문 3 (14.6) |
15.3 어제가 남긴 세 질문
1일차 13.2의 세 질문에 이제 답할 수 있습니다. 각각 한 문단으로 정리해 두면, 이틀이 한 줄로 닫힙니다.
Q1. LLM은 계산기가 아닌데, 표를 주면 왜 그럴듯한 숫자를 말할까
덧셈을 하지 않고 다음에 올 법한 숫자를 이어 쓰기 때문입니다. 자릿수와 크기가 비슷한 값이 확률적으로 뽑히므로 대체로 맞고 가끔 틀리며, 틀렸을 때도 문장은 확신에 차 있습니다. 그래서 계산은 수식에게 맡기고 모델에게는 판단만 시킵니다. 모델에게 답을 묻는 대신 답을 내는 장치를 만들게 하는 것이 오늘 하루 반복된 방식이었습니다 — 수식도, 대시보드 코드도, VBA 매크로도 전부 그렇게 만들었습니다. (5장)
Q2. AI에게 줘도 되는 것과 주면 안 되는 것의 경계는 어디인가
경계는 하나가 아니라 세 겹입니다. ① 어디서 처리되는가 — 스쿼트 카운터는 영상이 브라우저 밖으로 나가지 않지만(4장), 챗봇은 문서를 서비스에 올려둡니다(14장). ② 누가 보는가 — 사내 시트와 공개 배포는 완전히 다른 문제입니다(12.4). ③ 말하게 둘 것인가 — 자료에 들어 있어도 답하면 안 되는 것이 있습니다. 목표주가가 그 예입니다(14.5). 판단 기준은 "이 화면이 내일 아침 뉴스에 실려도 괜찮은가"로 두면 대체로 어긋나지 않습니다.
Q3. 데이터가 이미 틀려 있다면, 아무리 좋은 모델도 무엇을 할 수 있을까
틀린 답을 더 빠르게, 더 그럴듯하게 만듭니다. 그리고 그 답은 대시보드가 되어 조직에 퍼집니다. 오늘 오후의 절반을 정제에 쓴 이유가 이것입니다. 그런데 정제를 해보면 한 가지가 더 보입니다 — "판매량이 생산량보다 많다"를 발견한 순간, 그것이 이미 데이터가 말해준 첫 번째 사실입니다. 정제는 분석의 준비가 아니라 분석의 시작입니다. (6·10장)
15.4 이틀의 산출물이 이어지는 방식
1일차 10.1에서 "각 실습의 산출물은 다음 공정의 재료가 된다"고 했습니다. 이틀 전체로 보면 사슬이 한 번 더 길어집니다.
16장용어 사전
오늘 나온 말들. 1일차 11장의 사전에 이어지며, 헷갈리기 쉬운 지점을 함께 적었습니다.
16.1 모델을 만들 때
| 용어 | 한 줄 정의 | 붙잡아 둘 것 |
|---|---|---|
| 클래스 | 모델이 구분할 수 있는 답의 목록 | 목록에 없는 것은 모델에게 존재하지 않는다. "기타"를 두는 이유 |
| 라벨 | 각 예시에 붙인 정답 | 라벨이 흔들리면 모델이 기준을 못 찾는다 |
| 학습 데이터 검증 데이터 | 학습에 쓴 예시 / 확인에만 쓴 예시 | 겹치면 안 된다. 겹치면 점수가 의미를 잃는다 |
| 과적합 | 일반화하지 않고 외워버린 상태 | 학습 데이터에는 완벽, 새 데이터에는 형편없음 |
| 전이학습 | 기존 모델의 앞부분을 그대로 쓰고 마지막 층만 새로 학습 | 티처블머신이 몇 초 만에 끝나는 이유 |
| 지름길 학습 | 모델이 더 쉬운 단서(배경·조명)로 클래스를 가르는 현상 | 검증에서도 안 걸린다. 조건을 바꿔 확인해야 드러난다 |
| 자세 추정 | 영상에서 관절 좌표를 뽑아내는 처리 | 입력이 추상화되어 배경에 강하지만 좌표 밖 정보는 전부 버린다 |
| 임계값 | 확률을 판정으로 바꾸는 기준선 | 하나만 두면 경계에서 떤다 |
| 히스테리시스 | 들어가는 기준과 나오는 기준을 다르게 두는 방식 | 상태가 튀지 않게 한다. 카운트는 상태가 바뀌는 순간에만 |
| 추론 | 학습된 모델이 실제로 판정하는 동작 | 학습과 반대말. 여기서는 파라미터가 변하지 않는다 |
| 온디바이스 | 추론이 내 기기 안에서 일어나는 방식 | 데이터가 밖으로 나가지 않는다. 도입 검토의 첫 질문 |
| 모델 파일 | model.json(구조) · weights.bin(파라미터) · metadata.json(클래스 이름) | 1일차 2.1의 "가중치 파일"이 이것 |
16.2 데이터를 다룰 때
| 용어 | 한 줄 정의 | 붙잡아 둘 것 |
|---|---|---|
| 전처리 | 분석 전에 데이터를 믿을 수 있게 만드는 작업 | 분석의 준비가 아니라 분석의 일부 |
| 표기 표준화 | 같은 대상의 여러 표기를 하나로 묶는 일 | 규칙이 명확하면 함수, 경우가 유한하면 매핑표, 자유롭면 AI |
| 매핑표 | 원본표기 → 표준표기 짝을 모아둔 표 | 회사가 아는 목록은 AI가 아니라 표로 관리한다 |
| 결측치 | 비어 있는 값 | 채울지 비울지 제외할지는 사람이 정하고 기록한다 |
| 이상치 | 범위에서 크게 벗어난 값 | 지우지 말고 표시한다. 진짜 사건일 수 있다 |
| 논리 이상치 | 각각은 멀쩡한데 열끼리 비교하면 말이 안 되는 값 | 판매량>생산량, 가동률>1. 숫자 복구 뒤에야 보인다 |
| EDA탐색적 자료분석 | 가설을 만들기 위해 보는 것 | 결과는 결론이 아니라 질문이다 |
| CDA확증적 자료분석 | 가설을 검증하기 위해 보는 것 | 가설과 반증 조건을 먼저 글로 쓴다 |
| 상관과 인과 | 같이 움직인다 ≠ 하나가 다른 하나의 원인이다 | 세 번째 요인이 둘 다를 움직이는 경우가 흔하다 |
| 중앙값 | 줄 세웠을 때 한가운데 값 | 평균과 크게 다르면 한쪽으로 긴 꼬리가 있다는 신호 |
| KPI | 화면 맨 위에 두는 핵심 숫자 | 좋은 KPI는 다음 행동이 따라 나오는 숫자 |
| 슬라이서 | 대시보드의 조건 선택 장치 | 마법이 아니라 드롭다운이 든 셀 하나다 |
| 집계 시트 | 원자료와 화면 사이에 두는 층 | 숫자가 틀렸을 때 볼 곳이 한 군데가 된다 |
| COUNTIFS AVERAGEIFS | 여러 조건에 맞는 것을 세거나 평균 내는 함수 | 대시보드 집계의 거의 전부 |
| XLOOKUP | 표에서 값을 찾아 대응값을 가져오는 함수 | 네 번째 인자에 "미매핑"을 넣어 누락을 셀 수 있게 한다 |
| ISNUMBER | 그 셀이 진짜 숫자인지 확인 | 눈이 아니라 함수로 확인한다. 서식과 값은 다르다 |
16.3 내보내고 자동화할 때
| 용어 | 한 줄 정의 | 붙잡아 둘 것 |
|---|---|---|
| 정적 사이트 | 서버 프로그램 없이 HTML·CSS·JS 파일만으로 된 웹페이지 | 오늘 만든 것은 전부 이것. 그래서 배포가 간단하다 |
| 배포 · 호스팅 | 파일을 모두가 접근할 수 있는 자리에 올리는 일 | 기술적으로 쉽고, 판단으로는 되돌리기 어렵다 |
| index.html | 주소 끝에 파일명이 없을 때 서버가 찾는 기본 파일 | 이름이 다르면 "빈 화면"이 뜬다 |
| 매크로 · VBA | 엑셀 안에서 도는 자동화 코드 | Ctrl+Z가 없다. 사본에서 먼저 돌린다 |
| 모듈 | 매크로 코드를 붙여넣는 자리 | 시트 코드 창에 붙이면 목록에 안 뜬다 |
| .xlsm | 매크로를 담을 수 있는 엑셀 파일 형식 | .xlsx로 저장하면 코드가 조용히 사라진다 |
16.4 지식을 얹을 때
| 용어 | 한 줄 정의 | 붙잡아 둘 것 |
|---|---|---|
| 지식 베이스 | 챗봇이 근거로 삼는 자료 묶음 | 여기 없는 것은 답할 수 없다. 경계가 곧 능력 |
| 청크 (조각) | 검색을 위해 문서를 나눈 단위 | 모델은 문서 전체가 아니라 찾아온 몇 조각만 본다 |
| 시스템 프롬프트 | 챗봇의 역할·금지·형식을 정하는 지시문 | 성격을 정한다. 능력을 정하지는 못한다 |
| RAG | 관련 문서를 찾아 프롬프트에 넣고 답하게 하는 기법 | 재학습이 아니다. 1일차 4.1과 같은 것 |
17장자가 점검 · 업무 적용
17.1 확인 문제
먼저 스스로 답한 뒤 펼쳐서 확인합니다. 남에게 설명할 수 있는 수준이면 충분합니다.
"고양이 / 강아지" 두 클래스로 학습한 모델에 자동차 사진을 보여주면 어떻게 되는가?
둘 중 하나를 확률까지 붙여서 답한다. 모델에게는 "목록에 없다"는 선택지가 없기 때문이다. 1일차 3.1에서 본 LLM의 성질과 구조가 같다 — 확률로 답하는 기계에는 "모른다"는 상태가 없다. 그래서 실무 분류 모델에는 "기타 / 판정 불가" 클래스를 두고 사람에게 넘긴다.
티처블머신이 사진 스무 장으로 몇 초 만에 학습을 끝내는 이유는?
전이학습 때문이다. 처음부터 배우는 것이 아니라, 이미 수백만 장으로 학습된 모델의 앞쪽 층(선·모서리·질감·형태를 잡는 부분)을 그대로 쓰고 마지막 판단 층만 새로 학습한다. 선과 모서리를 보는 능력은 어떤 이미지에나 공통이라 다시 배울 필요가 없다.
모델의 정확도가 97%로 나왔다. 이 숫자만으로 무엇을 알 수 있는가?
거의 아무것도 알 수 없다. 불량률이 3%인 라인에서 전부 정상이라고 답하는 모델의 정확도가 정확히 97%입니다. 확인해야 할 것은 두 가지다 — 어느 쪽으로 틀리는가(불량을 놓친 것과 정상을 불량이라 한 것은 비용이 전혀 다르다), 그리고 학습에 쓰지 않은 예시로 잰 숫자인가.
모델이 잘 맞는데 빈 배경만 비춰도 특정 클래스로 답한다. 무슨 일인가?
지름길 학습이다. 모델이 물건이 아니라 배경·조명·구도처럼 더 쉽게 갈리는 단서를 배웠다. 1일차 2.5의 "모델이 무엇을 특징으로 잡았는지 알 수 없다"가 실물로 나타난 것이다. 검증 사진도 같은 방식으로 찍혔다면 시험에서는 드러나지 않는다. 조건을 바꿔서 확인해야 한다.
스쿼트 카운트를 세는 일에서 모델이 하는 일과 코드가 하는 일을 나눠보라.
모델은 지금 이 순간의 자세를 판정한다(Up인가 Down인가, 각각 몇 %인가). 코드는 시간을 본다 — 판정이 '앉음'에서 '섬'으로 바뀌는 순간에만 +1을 한다. 모델은 매 프레임을 독립적으로 보기 때문에 "스쿼트 1회"라는 개념을 가질 수 없다. 이 분리를 못 하면 무엇을 요청해야 할지 설명할 수 없게 된다.
카운터가 미친 듯이 올라간다. 모델을 다시 학습시켜야 하는가?
아니다. 세는 규칙의 문제다. 임계값이 하나뿐이면 확률이 그 선을 오갈 때 판정이 초당 여러 번 뒤집힌다. 해법은 들어가는 기준과 나오는 기준을 벌려 두는 것(예: 양쪽 다 0.9)과, 그 사이 구간에서는 직전 상태를 유지하는 것이다. 모델은 정직하게 확률을 주고 있었다.
표를 붙여 넣고 "합계를 구해줘"라고 하면 왜 위험한가?
모델은 덧셈을 하지 않고 다음에 올 법한 숫자를 이어 쓴다. 자릿수가 비슷해서 대체로 맞아 보이고 가끔 틀리는데, 과정이 남지 않아 검산할 수 없다. 계산은 수식에게 맡기고, 모델에게는 어느 수식을 쓰면 되는지를 물어야 한다.
VLOOKUP이 #N/A를 낸다. 가장 먼저 의심할 것은?
공백이나 보이지 않는 문자다. 사람 눈에는 같아 보여도 함수 눈에는 " 김철수"와 "김철수"가 다른 값이다. 수식을 고치기 전에 =EXACT(A2,B2)로 두 값이 정말 같은지 확인한다. 처치는 TRIM이고 중간 공백까지 없애려면 SUBSTITUTE다.
가동률 열에 0.87과 87이 섞여 있다. 왜 이것이 가장 위험한 오염인가?
오류 없이 조용히 틀리기 때문이다. AVERAGE가 아무 경고 없이 값을 내고, 그 값은 완전히 무의미하다. 게다가 백분율 서식이 걸려 있으면 화면상으로는 둘 다 그럴듯해 보인다. 서식을 일반으로 바꿔 날것의 값을 확인하고 =COUNTIF(범위,">1")이 0인지 검사한다.
AI로 표기를 통일한 뒤 반드시 해야 하는 검산은?
고유값 개수를 세는 것이다. =COUNTA(UNIQUE(범위)). 사업장이 4개여야 하는데 6개가 나오면 공백이 남았거나 다른 축약이 섞였다. 30초면 끝나고, 건너뛰면 대시보드가 같은 공장을 두 줄로 그린다 — 그리고 그 사실은 티가 나지 않는다.
EDA와 CDA를 한 번에 하면 무엇이 잘못되는가?
언제나 내가 옳다는 결론이 나온다. 데이터를 오래 들여다보면 무엇이든 눈에 띄고, 그것을 가설이라 부른 뒤 같은 데이터로 확인하면 당연히 맞다고 나온다. 답을 보고 문제를 고른 셈이다. 대응은 셋 — 다른 기간·다른 집단의 데이터로 확인하거나, 데이터 밖 근거(현장 기록·담당자)와 대조하거나, 최소한 "이건 가설이다"라고 표시해서 보고한다.
정제 순서에서 "논리 이상치 판정"이 왜 마지막인가?
비교하려면 먼저 같은 종류의 값이 되어야 하기 때문이다. "822592 t"와 744643이 섞여 있으면 "판매량 > 생산량"을 비교할 수 없고, 가동률이 0.87과 87로 섞여 있으면 "1보다 큰가"를 물을 수 없다. 그래서 표기 표준화(④)와 숫자 복구(⑤)가 이상치 판정(⑧)보다 앞에 온다.
대시보드를 만들기 전에 종이에 써야 하는 것은?
이 화면을 열 사람이 열자마자 알고 싶은 것 다섯 가지를 문장으로 쓴다. 그 다섯 문장이 차트 다섯 개의 명세서가 된다. 이 문장이 없으면 만들 수 있는 차트를 다 만들게 되고 결국 아무 질문에도 답하지 못하는 화면이 된다. 대시보드는 차트 모음이 아니라 질문 목록이다.
템플릿을 가져다 만든 대시보드에서 라벨을 안 바꾸면 왜 위험한가?
숫자는 맞는데 읽는 사람이 전부 오해하기 때문이다. 화면에 "요금제별 고객수"라고 적혀 있는데 실제로 세고 있는 것이 품목별 거래처 수라면, 아무도 이상함을 느끼지 못한 채 잘못 이해한다. 틀린 대시보드보다 위험한 것은 이름만 다른 대시보드다 — 전자는 누군가 발견하지만 후자는 발견되지 않는다.
Stitch나 AI Studio로 대시보드를 만들 때 원자료를 통째로 넘기면 안 되는 이유는?
그 도구들도 LLM이기 때문이다. 원자료를 주면 모델이 집계를 직접 계산해서 화면에 박고, 그 과정에서 시트의 숫자와 어긋난다. 집계를 시트에서 끝내고 결과만 넘기면 모델은 옮겨 적고 배치만 하면 되므로 대조가 눈으로 끝난다.
"주소를 아무도 모르니까 공개 배포해도 괜찮다"는 판단은 왜 위험한가?
주소는 브라우저 기록·메신저 미리보기·북마크 동기화·확장 프로그램을 타고 내가 모르는 사이에 퍼지고, 검색엔진이 찾아내는 일도 드물지 않다. 이것은 보안이 아니다. 판단 기준은 "이 화면이 내일 아침 뉴스에 캡처로 실려도 괜찮은가"로 두고, 아니라면 공개 배포가 아닌 다른 방법을 찾는다.
매크로를 실행하기 전에 반드시 하는 두 가지는?
① 사본에서 먼저 돌린다. 매크로가 바꾼 것은 Ctrl+Z로 되돌아오지 않는다. ② 무엇이 어떻게 바뀌는지 한국어 설명을 먼저 받아 읽는다. 코드를 못 읽어도 설명은 읽을 수 있고, "원본 파일을 저장한다"는 말이 있으면 그 자리에서 막을 수 있다.
파일 통합 매크로를 요청할 때 기능 설명만큼 안전 장치를 길게 쓰는 이유는?
AI는 시킨 것을 만들고, 시키지 않은 상황은 생각하지 않기 때문이다. "기존 데이터가 있으면 어떻게 할지"를 안 물으면 그냥 덮어쓴다. "원본은 읽기만 한다"를 안 쓰면 원본을 저장하며 닫는 코드가 나올 수 있다. 실무 프롬프트에서 기능 절반, 예외 처리 절반이 정상 비율이다.
챗봇의 성격은 시스템 프롬프트가 정한다. 그럼 능력은 무엇이 정하는가?
지식 베이스다. 말투를 아무리 정성껏 써도 자료에 없는 것은 답할 수 없고, 자료에 잘못 들어 있으면 공손하고 확신에 찬 문장으로 잘못 답한다. 그래서 챗봇을 만들기 전에 답할 수 있는 질문 목록과 답할 수 없는 질문 목록을 먼저 쓴다. 후자가 시스템 프롬프트의 금지 항목이 되고 공개 전 시험 문제가 된다.
제안서에 목표주가가 적혀 있다. 챗봇이 그것을 인용해도 되는가?
안 된다. 자료에 있으므로 RAG는 아무 문제 없이 인용하지만, 그 문장이 회사 챗봇의 입에서 나오면 회사가 주가를 전망한 것이 된다. RAG의 안전장치는 두 겹이다 — 무엇을 지식 베이스에 넣지 않을 것인가, 그리고 넣은 것 중 무엇을 말하지 않게 할 것인가. 자료에 있다고 다 답하게 두면 안 된다.
RAG에 넣을 문서에서 "431억 원"만 적힌 문단이 왜 문제인가?
모델은 문서 전체가 아니라 검색된 몇 조각만 본다. 그 조각에 "2026년 2분기 영업이익"이라는 기준이 없으면 무엇의 431억인지 알 수 없는 상태로 답변에 실린다. 그래서 RAG용 문서는 수치와 기준을 한 문장 안에 두고, 대명사를 줄이고 제목 구조를 또렷하게 만든다.
17.2 이해 체크리스트
설명할 수 있으면 체크합니다. 체크 상태는 이 브라우저에 저장됩니다.
모델을 만드는 일 (1부)
데이터를 다루는 일 (2부)
내보내고 얹는 일 (3·4부)
적용
17.3 업무 적용 과제
이틀이 끝난 뒤 일주일 안에 해두면 좋은 것 다섯 가집니다. 순서대로 할 필요는 없고, 하나만 해도 남습니다.
| 과제 | 구체적으로 | 왜 이것인가 |
|---|---|---|
| ① 더러운 열 하나를 고친다 | 내가 매달 만지는 파일에서 표기가 흩어진 열을 하나 골라 매핑표를 만든다 | 가장 값이 큰 자산이다. 한 번 만들면 계속 쓴다 |
| ② 정제 기록을 남긴다 | 10.5의 여섯 줄 형식으로 그 파일의 정제 기준을 적어 시트에 붙인다 | 다음 달의 나를 위한 것이다 |
| ③ 질문 다섯 개를 쓴다 | 지금 만들고 싶은 대시보드가 있다면, 차트 대신 질문 다섯 문장을 먼저 쓴다 | 이걸 쓰면 만들 것이 절반으로 준다 |
| ④ 반복 하나를 매크로로 | 매주 손으로 하는 엑셀 작업 하나. 사본에서 시험한다 | 시간이 즉시 돌아온다 |
| ⑤ 경계를 적는다 | 내 업무 데이터 중 AI에 줘도 되는 것 / 사내만 / 절대 안 되는 것을 세 칸으로 나눠 적는다 | 어제 남은 질문에 내가 내놓는 답이다 |
가장 먼저 할 것 하나를 고른다면
⑤번입니다. 나머지 넷은 도구를 쓰는 일이지만 ⑤번은 판단이고 판단은 도구보다 오래 갑니다. 그리고 이 표가 있어야 나머지 넷을 안심하고 할 수 있습니다.
17.4 이틀 이후
이틀 동안 일곱 개의 도구를 지나왔습니다. 그중 절반은 내년에 이름이 바뀌거나 없어질 것입니다. 그래도 남는 것이 있습니다.
| 바뀔 것 | 남을 것 |
|---|---|
| 티처블머신의 화면과 버튼 | 클래스를 어떻게 나눌지, 예시를 어떻게 모을지의 판단 |
| AI Studio · Stitch의 이름 | 계산은 도구에게 맡기고 결과만 넘긴다는 원칙 |
| 스프레드시트 AI 함수의 문법 | 라벨을 고정하고 고유값으로 검산하는 습관 |
| Netlify의 배포 방식 | 공개 전에 무엇이 실려 있는지 확인하는 절차 |
| Chatling의 설정 화면 | 지식 베이스의 경계를 먼저 그리는 설계 |