AI 과정

어떤 도구보다 중요한 습관이 두 가지 있어요. 첫째, 결과를 확인하세요. AI 의 답, 그림, 코드 변경은 내가 읽어 보고, 시험해 보고, 출처와 비교하기 전까지는 초안일 뿐이에요. 둘째, 비밀을 지키세요. 비밀번호, API 키, 다른 사람의 개인 정보를 채팅이나 프롬프트, 남과 나누는 파일에 절대 붙여 넣지 마세요. 키는 환경 변수나 Git 에 절대 커밋하지 않는 .env 파일에 두어야 해요.

환각은 자신 있게 말하지만 틀렸거나 지어낸 답이에요. 그래서 늘 확인해야 해요. API 는 내 프로그램이 프롬프트를 보내고 답을 돌려받게 해 주는 문이고, 보통 비밀 API 키가 필요해요. 챗봇은 답만 하지만, 에이전트는 행동도 할 수 있어요. 목표를 향해 한 단계씩 파일을 읽고, 명령을 실행하고, 도구를 써요. 오픈 소스나 오픈 웨이트 모델은 내려받아서 내 컴퓨터에서 실행할 수 있고, 닫힌 모델은 그 회사의 앱이나 API 로만 쓸 수 있어요.

• Google — Machine learning glossary

대규모 언어모델(LLM)은 AI의 한 종류예요. 글을 만드는 많은 LLM은 주어진 문맥에서 다음 토큰을 예측해요. 이미지 생성기·분류기·규칙 기반 시스템은 다른 방식으로 작동할 수 있어요. 유창한 말이 생명체라는 증거나 내용이 참이라는 증거는 아니에요.

• NIST — Generative AI profile

역할을 주면 말투를 유도할 수 있지만 전문성이나 지시 준수가 보장되지는 않아요. 필요하면 출처를 요청하고 실제로 주장을 뒷받침하는지 확인하세요. 같은 예제로 두 프롬프트를 비교해 보세요. 필요한 정보만 제공하고, 질문을 잘 써도 모델의 모든 한계가 없어지지는 않는다는 점을 기억해요.

• Transformers — LLM tutorial

프롬프트를 초안처럼 다루세요. 답을 읽고, 빠졌거나 틀린 것을 찾아서, 바로 그것을 프롬프트에 더하세요. "더 쉬운 말로 써 줘", "선택지 세 개를 줘", "출처를 밝혀 줘"처럼요. 어려운 일은 모델에게 먼저 계획을 세우고 그다음에 답하라고 하거나, 일을 더 작은 프롬프트들로 나누세요. 코딩 에이전트라면 프롬프트에서 오래 쓰는 부분, 즉 규칙, 명령, 스타일은 CLAUDE.md 나 AGENTS.md 같은 프로젝트 파일에 넣어서 매번 되풀이하지 않게 하세요.

• Anthropic — Prompt engineering overview
• OpenAI — Prompt engineering

실습실은 실제 LLM 토크나이저가 아닌 간단한 단어 분할기를 써요. ID는 이름표이므로 ID 8이 ID 4보다 뜻이 두 배인 것은 아니에요. 문맥 창에는 사용할 수 있는 토큰 수의 한계가 있어 앱이 자료를 선택·요약·제외할 수 있어요.

• Transformers — Tokenizers

현대 Transformer는 attention으로 주어진 문맥의 위치별 정보를 섞어서, 같은 토큰도 문장에 따라 표현이 달라져요. 유사도는 진실이나 같은 뜻을 보장하지 않아요. 유명한 왕 − 남자 + 여자 비유는 일부 단어 임베딩에서 관찰된 예이지 보편적인 등식이 아니에요. 검색에서는 질문과 문서 벡터를 호환되는 임베딩 공간에서 비교해요.

• Attention Is All You Need

파인튜닝은 모델 가중치를 바꿔요. LoRA는 기본 가중치를 고정하고 작은 어댑터 행렬을 학습할 수 있어요. RAG는 가중치 변경 없이도 자료를 찾아 문맥으로 제공해요. BM25는 단어 일치·빈도 포화·문서 길이 보정을, 임베딩 검색은 학습된 벡터 비교를 사용해요. 어느 방법도 증거 누락이나 잘못된 자료 검색을 완전히 막지 못해요. 채팅 한 번이 자동으로 모델 학습이 되는 것은 아니에요.

• Attention Is All You Need
• Retrieval-Augmented Generation
• LoRA

직접 만들기에서 탐욕 선택과 샘플링을 여러 번 비교해 보세요. 샘플링도 같은 결과가 나올 수 있어요. 실제 시스템은 모델 버전·문맥·도구·수치 연산도 영향을 주므로 온도 0이 완전히 같은 출력을 보장하지 않아요. 이어서 모호한 질문과 목표·배경·검증 방법을 담은 질문을 비교하세요. 사실 주장은 원출처로 확인하고, 힌트를 활용해 결과를 자기 말로 설명해 보세요.

• Transformers — Generation strategies
• PyTorch — Reproducibility

언어 모델은 그럴듯한 글을 예측하기 때문에, 술술 읽히는 답도 틀릴 수 있어요. 출처를 물어보고 직접 열어 보세요. 숫자는 원래 자료와 비교하고, 모델에게 어떤 가정을 했는지 적어 달라고 하세요. 중요한 사실은 따로 떨어진 두 번째 출처로 확인하세요. 저장된 지침과 프로젝트 기능으로 ChatGPT 가 내 취향을 기억하게 할 수 있지만, 그것도 지시일 뿐 보장이 아니니 계속 확인하세요.

• OpenAI — Prompt engineering

만든 그림에는 작은 실수가 숨어 있을 때가 많아요. 틀린 글자, 남는 손가락, 말이 안 되는 그림자 같은 것들이에요. 꼭 확대해서 확인하세요. 만든 그림으로 실제로 일어난 일인 척하지 말고, 살아 있는 작가나 실제 사람을 허락 없이 흉내 내지 말고, 필요할 때는 AI 로 만든 그림이라고 밝히세요. 그림을 상업적으로 쓰기 전에는 도구의 이용 약관을 읽어 보세요.

• OpenAI — Image generation
• Google — Gemini image generation

AI 도구 안에서 슬래시로 시작하는 명령은 도구 자체를 다뤄요. /init 은 프로젝트 지시 파일을 쓰고, /help 는 명령 목록을 보여 주고, /clear 는 새 대화를 시작하고, /exit 는 도구에서 나가요. 쉘 강좌 11단원에서는 AI 코딩 도구를 설치하고 --version 으로 확인하는 방법을 보여 줘요. 설치 명령은 바뀌니 공식 페이지와 비교하세요. 아직 실행 중인 명령을 멈추려면 Ctrl+C 를 누르세요. AI 에이전트가 명령을 제안하면 허락하기 전에 읽어 보세요. rm -rf 는 휴지통도 거치지 않고 파일을 영영 지워 버려요.

• The Linux command line for beginners

GitHub 에서는 이슈로 할 일을 설명하고, 브랜치에서 메인 코드를 건드리지 않고 작업하고, 풀 리퀘스트로 검토해요. 개인적인 작업이 담긴 저장소는 비공개로 두고, .env 파일이나 키는 절대 커밋하지 마세요. 한 번 푸시했다면 이미 새어 나갔다고 보고 키를 바꾸세요. Codex 와 Claude Code 도 풀 리퀘스트를 열 수 있지만, 합치기 전에 사람이 diff 를 읽어야 해요.

• GitHub — Hello World

이 강좌의 나머지를 떠받치는 NumPy 개념은 세 가지예요. shape(행과 열이 몇 개인지), 브로드캐스팅(연산이 배열 전체로 자동으로 늘어나 적용되는 것), 벡터화 계산(Python 반복문을 쓰지 않고 배열 전체를 한 번에 계산하는 것)이에요. 이 강좌의 코드는 모두 브라우저에서 실행돼요. 내 컴퓨터에서 하려면 Python 3 를 설치하고, python -m venv .venv 로 가상 환경을 만들고, pip install numpy 로 NumPy 를 설치하세요.

• NumPy — the absolute basics for beginners

아래 예제는 사람이 쓴 규칙을 적용해요. 점수나 기준을 바꾸고 실행 전에 출력을 예상해 보세요. 함수의 return은 값을 돌려주고 print는 화면에 표시해요. 기준과 정확히 같은 점수처럼 경계값도 시험하세요. 이 규칙 프로그램에는 데이터를 통한 학습 단계가 없어요.

• Python tutorial

개발자는 여전히 나예요. 변경을 받아들이기 전에 하나하나 읽고, 작동하는 단계마다 Git 에 커밋해서 되돌아갈 수 있게 하고, 실제 휴대폰 너비에서 시험해 보세요. 에이전트가 페이지에 비밀번호나 API 키를 넣지 않게 하세요. 홈페이지는 공개되어 있어서 그 안의 모든 것을 누구나 읽을 수 있어요. 페이지가 잘 작동하면 공개할 준비가 된 거예요. 다음 챕터에서 Cloudflare 로 인터넷에 올려요.

• MDN — Your first website

공개하는 것은 모두 누구나 볼 수 있으니, 폴더에 키, 개인 메모, .env 파일이 없는지 확인하세요. 배포할 때마다 그 배포만의 미리보기 주소가 생기고, 실제 주소는 가장 최근 배포를 보여 줘요. 그래서 공유하기 전에 시험해 볼 수 있어요. myname.com 같은 나만의 도메인은 나중에 대시보드에서 더할 수 있어요. 코딩 에이전트에게 배포 명령을 실행하게 해도 되지만, 먼저 명령을 읽고, Cloudflare API 토큰은 절대 채팅에 붙여 넣지 마세요.

• Cloudflare Pages — Direct Upload
• Cloudflare Pages — Git integration

출시는 트랙을 거쳐요. 내부 테스트, 비공개 테스트, 공개 테스트, 프로덕션이에요. 새 개인 개발자 계정은 프로덕션 출시를 신청하기 전에, 먼저 테스터 12명 이상이 14일 연속으로 참여를 유지하는 비공개 테스트를 해야 해요. 그러니 테스터를 일찍 계획하세요. 모든 출시는 Google 이 심사하고, 업데이트할 때마다 버전 코드를 더 높여야 해요. 규칙과 화면은 바뀌니, 이 챕터와 함께 공식 Play Console 도움말을 따라가세요.

• Play Console Help — Testing requirements for new personal developer accounts
• Flutter — Build and release an Android app

업로드한 빌드는 모두 먼저 TestFlight 로 보낼 수 있어서, 일반 사용자보다 테스터가 먼저 설치해 볼 수 있어요. 출시를 위해 제출하면 Apple 의 앱 심사가 앱을 가이드라인에 비추어 확인해요. 흔한 거절 이유는 이래요. 앱이 멈추거나 임시 내용이 들어 있을 때, 개인정보 내용이 빠졌을 때, 로그인이 있는데 심사자용 테스트 계정이 없을 때, 다른 회사 로그인이 있는데 Sign in with Apple 처럼 그에 맞먹는 개인정보 보호형 선택지가 없을 때, 앱이 웹사이트를 앱으로 감싸기만 했을 뿐 할 수 있는 일이 거의 없을 때(최소 기능 규칙, 가이드라인 4.2)예요. 거절 메시지를 읽고, 바로 그것을 고쳐서 다시 제출하세요.

• App Store Connect — Workflow
• App Review Guidelines — 4.2 Minimum functionality
• Flutter — Build and release an iOS app

서브 에이전트는 메인 에이전트가 일의 한 부분을 맡기려고 시작하는 도우미예요. 서브 에이전트는 자기만의 새 컨텍스트 창을 가져서, 파일을 많이 읽거나 넓게 검색한 뒤 결론만 보고할 수 있어요. 그래서 메인 대화가 짧게 유지돼요. 서로 관계없는 부분이라면 서브 에이전트 여러 개가 동시에 일할 수도 있어요. Claude Code 에서 서브 에이전트는 이름, 설명, 허용된 도구, 지시가 담긴 Markdown 파일이고, .claude/agents/(프로젝트용)나 ~/.claude/agents/(나 전용)에 있어요. 서브 에이전트에게는 좁은 일과 꼭 필요한 도구만 주고, 그 보고도 내가 확인해야 할 초안이라는 것을 기억하세요.

• Anthropic — Building effective agents
• Claude Code — Subagents

좋은 코딩 요청은 구체적이에요. 무엇을, 어느 파일에서 바꾸는지, 바꾼 뒤 어떻게 동작해야 하는지, 어떻게 확인하는지(테스트, 명령, 입력과 출력의 예)를 말해요. 큰 일이라면 먼저 계획을 달라고 하세요. Codex 가 일을 끝내면 diff 를 읽고, 테스트를 직접 실행하고, 내가 이해한 것만 커밋하세요. codex exec 는 대화 화면 없이 일을 실행해서 스크립트 안에서 쓰기 좋아요.

• OpenAI — Codex
• AGENTS.md

Claude Code 는 파일을 고치거나 명령을 실행하기 전에 물어보고, 나는 그 동작을 한 번만, 이번 세션 동안, 또는 항상 허락할지 정해요. 권한 규칙은 .claude/settings.json 에 있고, 계획 모드에서는 Claude Code 가 아무것도 바꾸지 않고 읽고 계획만 제안해요. 처음에는 엄격하게 시작해서 믿을 수 있는 것만 풀어 주고, 이해하지 못한 명령은 절대 허락하지 마세요.

• Claude Code — Overview
• Claude Code — Memory (CLAUDE.md)

에이전트가 스스로 확인할 방법을 주세요. 테스트, 꼭 성공해야 하는 명령, 올바른 출력의 예 같은 것이에요. 세션이 엉뚱한 방향으로 가면 Esc 를 눌러 멈추고 무엇이 틀렸는지 말하거나, Git 으로 되돌리고 새로 요청하세요. 세션이 길어지면 헷갈리는 맥락이 쌓이니 /clear 로 깨끗하게 다시 시작하세요. 자주 반복하는 일은 단계를 스킬로 저장하세요(Agent Skills 챕터를 보세요).

• Claude Code — Common workflows

모델마다 잘하는 것과 놓치는 것이 달라서, 에이전트 세 가지를 알아 두면 쓸모가 있어요. 좋은 습관은 교차 검증이에요. 한 에이전트에게 변경을 맡기고 다른 에이전트에게 검토를 맡기거나, 여러 에이전트에게 같은 문제를 따로 분석하게 해서 비교하세요. 의견이 갈리는 곳은 내가 직접 파일을 열어 보고 결정하세요. 모든 에이전트가 같은 지시를 따르도록, 많은 에이전트가 읽는 AGENTS.md 에 같은 프로젝트 규칙을 두세요.

• Antigravity — Getting started (CLI)

스킬이 언제 쓰일지는 설명이 정하니, 사람들이 실제로 하는 말로 쓰고 무엇에는 쓰지 않는지도 밝히세요. 지시는 짧고 구체적으로 쓰고, 긴 세부 내용은 따로 참고 파일로 옮기고, 써야 하는 요청과 쓰지 말아야 하는 요청으로 스킬을 시험하세요. 스킬은 스크립트를 실행할 수 있으니 믿을 수 있는 곳의 스킬만 설치하고, 먼저 읽어 보세요. SONUB 도 여러 스킬로 만들어졌어요. 그중 하나는 이 사이트에서 보는 용어의 초보자용 팝업을 써요.

• Agent Skills
• Claude Code — Skills

에이전트가 할 수 있는 일이 많을수록 내 지시가 더 중요해져요. 필요한 폴더만 열어 주고, 하면 안 되는 일(삭제, 보내기, 구매)을 말하고, 확실하지 않으면 멈추고 물어보라고 하고, 결과를 원본과 비교해 확인하세요. 소프트웨어 팀에서 배울 만한 습관이 교차 검증이에요. 같은 질문을 둘 이상의 AI 도구에 묻고, 답을 비교하고, 다수결이 아니라 근거로 결정하는 거예요. SONUB 개발자들도 이렇게 일해요. 질문 하나를 여러 AI 모델에 보내고, 모든 주장을 원본 파일에서 다시 확인해요.

• Claude — Get started with Cowork

루프는 끝나는 기준만큼만 좋아요. "더 좋게 만들어 줘"는 끝나지 않지만, "tests/ 의 모든 테스트가 통과하고 페이지가 오류 없이 열린다"는 확인할 수 있어요. 언제나 한도를 정하세요. 최대 바퀴 수, 사실일 때만 에이전트가 말할 수 있는 완료 문구, 또는 토큰 예산이에요. 그러지 않으면 루프가 밤새 돌면서 쓸데없이 돈을 쓸 수 있어요. 루프는 새 Git 브랜치에서 시작하고, 프로젝트 규칙은 CLAUDE.md 나 AGENTS.md 에 두고, 결과는 직접 확인하세요. 에이전트가 말하는 "다 했어요"는 주장일 뿐 증거가 아니에요.

• OpenAI Cookbook — Using goals in Codex
• Claude Code plugin — Ralph Loop

밤새 일하는 에이전트에게는 안전장치가 필요해요. 끝나는 기준과 한도가 있는 분명한 목표를 주고, 브랜치에서 실행하고, 커밋하게 해서 아침에 작업을 검토할 수 있게 하세요. API 키는 저장소가 아니라 환경 변수에 두고, AI 제공 회사에서 지출 한도를 정하세요. 서버도 지키세요. SSH 키로만 접속하고, 방화벽을 켜고, 정기적으로 업데이트하세요. tmux attach 로 들어가거나 Git 기록을 읽어서 세션을 확인하고, Ctrl+C 나 tmux kill-session -t agent 로 멈추세요.

• tmux — Getting started

뉴런은 입력을 z = w·x + b로 합치고 활성화 함수를 적용할 수 있어요. sigmoid는 유한한 실수를 0과 1 사이로 보내는 한 가지 함수이며 모든 뉴런의 정의는 아니에요. 다른 신경망은 ReLU·GELU도 써요. sigmoid 구현은 부품을 만드는 것이지 학습된 신경망을 완성하는 것이 아니에요. 이어지는 미션에서 데이터로 학습한 모델을 다루며, 예제 통과만으로 일반화를 증명할 수는 없어요.

• scikit-learn — Linear regression

이웃 수 k와 트리 깊이는 학습 밖에서 선택하는 하이퍼파라미터이고, 회귀 계수는 학습된 파라미터가 될 수 있어요. 설정은 검증 데이터나 교차검증으로 고르고 테스트 데이터는 최종 평가에 남겨두세요. 테스트 점수를 보며 계속 조정하면 평가가 낙관적으로 치우쳐요. 데이터 분할·기준 모델·점수·오류 사례를 기록하세요. 작은 붓꽃 실험은 첫 프로젝트이며 모든 집단과 문제에 대한 성능 증명은 아니에요.

• scikit-learn — Common pitfalls
• scikit-learn — Iris dataset

손실은 실제 다음 글자를 보고 모델이 얼마나 놀랐는지를 재요. 그 확률에 로그를 취하고 마이너스를 붙인 값의 평균이에요. 완벽한 모델이라면 손실이 0 이에요. 실제 LLM 은 여러 글자로 된 토큰을 쓰고 훨씬 긴 문맥을 보지만, 도는 순서는 같아요. 글 → ID → 다음 토큰의 확률 → 하나 고르기 → 되풀이.

• Andrej Karpathy — makemore

단계가 지날수록 손실이 줄어드는 것을 보세요. 신경망이 배우고 있다는 뜻이에요. 이제 더 많은 문맥을 보기 때문에 만들어 낸 글이 진짜 단어 모양을 갖춰요. temperature 는 생성이 얼마나 모험적일지를 정해요. 1 보다 낮으면 더 안전한 글자를 고르고, 1 보다 높으면 더 과감해져요. 큰 LLM 은 가중치가 수십억 개이고 GPU 로 엄청난 양의 글을 학습하지만, 학습 한 단계 한 단계는 이것과 똑같은 생각이에요.

• Bengio et al. — A Neural Probabilistic Language Model

이 코드는 문맥이 여덟 글자인 어텐션 헤드 하나를 NumPy 만으로 학습시키고, 마지막 글자의 어텐션 가중치를 출력해요. 그래서 그 글자가 앞의 어느 글자에 기대는지 볼 수 있어요. 진짜 트랜스포머는 헤드가 여러 개인 층을 여러 겹 쌓고, 피드포워드 층과 정규화를 더하고, Adam 같은 옵티마이저로 훨씬 많은 글을 학습해요. 나머지 전부, 즉 토큰, 임베딩, softmax, 손실, 경사 하강법, 샘플링은 이제 여러분이 직접 만들어 봤어요.

• Attention Is All You Need

학습은 한 단계를 되풀이해요. 글 한 묶음(배치)을 가져와서, 각각의 다음 토큰을 예측하고, 오차(손실)를 재고, 손실이 작아지도록 모든 파라미터를 조금씩 옮겨요. 숫자 두 개를 지켜보세요. 학습 손실, 그리고 모델이 본 적 없는 글에 대한 검증 손실이에요. 학습 손실만 줄어든다면 모델이 외우고 있는 거예요. 학습이 끝나면 모든 파라미터가 담긴 체크포인트 파일이 생겨요. Mac 에서는 mps 장치를, NVIDIA 그래픽 카드에서는 cuda 를 쓰고, 그 밖에는 더 작은 모델로 cpu 를 쓰세요. 이 챕터 앞의 브라우저 챕터들에서는 같은 부품을 NumPy 로 손수 만들었어요. 여기서는 그 부품들을 실제 크기로 써요.

• Andrej Karpathy — nanoGPT
• Andrej Karpathy — nanochat
• OpenAI — Language Models are Unsupervised Multitask Learners (GPT-2)

러너마다 실행되는 곳과 읽는 파일 형식이 달라요. PyTorch 는 내 학습 체크포인트를 바로 실행하고, llama.cpp 와 Ollama 는 보통 컴퓨터와 휴대폰에서 GGUF 파일을 실행해요. 브라우저와 휴대폰은 ONNX 나 Apple 과 Google 의 자체 런타임을 쓸 수도 있어요. 많은 러너가 로컬 API 를 제공해서, 내 앱이 클라우드 API 와 이야기하는 것과 똑같이 내 컴퓨터의 모델과 이야기할 수 있어요. 키도 필요 없고 데이터가 컴퓨터 밖으로 나가지도 않아요. 내 nanoGPT 체크포인트는 변환 단계를 거치면 이런 엔진에서 실행할 수 있어요. 그 변환은 다음 챕터에서 해요.

• llama.cpp
• Ollama — API

휴대폰에서 쓰는 방법은 두 가지예요. 빠른 방법은 PocketPal AI 처럼 러너가 이미 들어 있는 앱에 GGUF 파일을 복사해서 인터넷 없이 대화하는 거예요. 만드는 사람의 방법은 내 앱에 러너를 넣는 거예요. 예를 들어 React Native 앱에는 llama.rn 을, Flutter 앱에는 llama.cpp 바인딩을 넣고, 모델 파일을 앱과 함께 내보내거나 내려받게 한 다음, 내 코드에서 불러요. 모든 것이 휴대폰 안에 있어서 인터넷 없이도 작동하고 데이터도 지켜지지만, 클라우드보다 느리고 배터리를 쓰니 프롬프트는 짧게, 모델은 작게 하세요. 또 다른 방법은 러너를 내 컴퓨터에 두고 같은 Wi-Fi 에서 휴대폰으로 그 로컬 API 를 부르는 거예요. 더 쉽지만 그 컴퓨터 가까이에서만 작동해요. 앱에 모델을 넣는 것(임베드)과 임베딩 챕터에 나온 벡터인 임베딩을 헷갈리지 마세요. 휴대폰 속 작은 임베딩 모델로 내 메모를 검색할 수도 있어요.

• llama.cpp — quantize
• PocketPal AI
• llama.rn

발표는 코드만큼 중요해요. 계획, AI 가 무언가를 틀렸던 순간과 내가 그것을 알아챈 방법, 내가 실행한 테스트나 확인, 다음에 하고 싶은 일을 보여 주세요. 정직하게 밝히세요. 어느 부분을 내가 썼고, 어느 부분을 AI 가 썼고, 그것을 어떻게 확인했는지 말해요.