AI를 써먹기 위한 최소 지식 3편: 토큰과 컨텍스트 윈도우
토큰, 컨텍스트 윈도우, 입력 정보 선별, 긴 코드베이스를 AI와 다룰 때 필요한 요약 전략을 정리합니다.
목차
지난 글에서는 프롬프트보다 컨텍스트가 중요하다고 정리했습니다.
그럼 자연스럽게 다음 질문이 나옵니다.
"컨텍스트를 많이 주면 좋은 거 아닌가?"
절반은 맞고, 절반은 조심해야 합니다.
AI에게는 한 번에 볼 수 있는 정보량의 한계가 있습니다. 이때 자주 나오는 개념이 토큰과 컨텍스트 윈도우입니다.
토큰은 AI가 읽는 작은 조각이다
토큰은 AI가 텍스트를 처리하는 기본 단위입니다.
한글로는 단어 하나와 딱 맞지 않을 수 있고, 영어도 단어/기호/공백이 섞여 나뉠 수 있습니다. 처음에는 너무 정확히 외울 필요는 없습니다.
실무 감각으로는 이렇게 보면 충분합니다.
문장
-> AI가 처리하기 쉬운 작은 조각들
-> 그 조각 단위로 입력을 읽고 출력을 만든다토큰이 중요한 이유는 두 가지입니다.
1. 입력할 수 있는 양에 한계가 있다. 2. 많이 넣을수록 비용과 처리 시간이 늘 수 있다.
즉 토큰은 단순한 내부 구현 용어가 아니라, AI를 실제 작업에 붙일 때 비용/속도/품질에 영향을 주는 단위입니다.
컨텍스트 윈도우는 한 번에 펼쳐놓는 작업대다
컨텍스트 윈도우는 모델이 한 번에 참고할 수 있는 입력과 출력의 범위입니다.
비유하면 작업대입니다.
작업대가 작으면 필요한 파일을 다 못 펼칩니다. 작업대가 크면 더 많은 자료를 올릴 수 있습니다. 하지만 작업대가 크다고 자동으로 정리가 잘 되는 건 아닙니다.
개발 작업에서는 이런 정보가 컨텍스트에 들어갑니다.
| 정보 | 예시 |
|---|---|
| 사용자 요청 | "댓글 삭제 기능 추가해줘" |
| 기존 대화 | 이전에 정한 설계 방향 |
| 파일 내용 | API 핸들러, 프론트 스크립트, CSS |
| 로그 | 빌드 실패, API 응답 |
| 명령 결과 | 테스트 통과/실패 |
| 작성 중인 답변 | AI가 현재 생성하는 설명 |
여기서 중요한 건 출력도 컨텍스트를 사용한다는 점입니다.
입력을 너무 꽉 채우면, 답변을 만들 공간도 줄어듭니다.
많이 넣으면 왜 문제가 될까
긴 코드베이스를 그대로 다 넣으면 좋아 보입니다.
하지만 실제로는 문제가 생길 수 있습니다.
1. 중요한 파일이 덜 중요한 파일에 묻힌다.
2. AI가 오래된 정보와 최신 정보를 섞을 수 있다.
3. 비용과 시간이 늘어난다.
4. 답변이 길어지고 초점이 흐려질 수 있다.예를 들어 블로그 댓글 기능을 고치는데, 전체 CSS와 모든 글 문서, 무관한 DB 변경 파일까지 같이 넣으면 AI는 읽을 수는 있어도 우선순위를 잡기 어려워집니다.
사람도 마찬가지입니다.
"이 폴더 전부 봐줘"보다 "댓글 API와 글 상세 페이지 렌더링만 봐줘"가 훨씬 낫습니다.
넣을 것과 뺄 것을 나누는 기준
저는 컨텍스트를 넣을 때 이렇게 나눕니다.
| 분류 | 넣을까? | 기준 |
|---|---|---|
| 직접 수정 대상 | 넣음 | AI가 바꿔야 하는 파일 |
| 호출 관계 | 넣음 | 수정 대상이 의존하는 함수/타입 |
| 에러 로그 | 넣음 | 실패 원인을 좁히는 증거 |
| 설정 파일 | 상황에 따라 | 빌드/배포/권한과 관련 있으면 포함 |
| 오래된 대화 | 요약해서 | 결정 사항만 남김 |
| 무관한 파일 | 제외 | 읽어도 판단이 안 바뀌면 제외 |
핵심은 이 질문입니다.
이 정보가 AI의 판단을 바꿀 가능성이 있는가?
가능성이 낮으면 빼는 편이 좋습니다.
토큰 예산을 실제로 나누는 법
컨텍스트 윈도우가 크다고 해도, 저는 대략 이런 순서로 공간을 배분합니다.
| 우선순위 | 넣는 정보 | 이유 |
|---|---|---|
| 1 | 작업 목표와 완료 기준 | 답변 방향과 끝나는 지점을 정합니다 |
| 2 | 직접 수정 대상과 호출 흐름 | 실제 변경 판단에 가장 큰 영향을 줍니다 |
| 3 | 에러 로그와 재현 방법 | 원인을 좁히는 증거입니다 |
| 4 | 제약과 금지 조건 | 비용, 보안, 운영 실수를 줄입니다 |
| 5 | 이전 대화 요약 | 결정된 내용만 짧게 남깁니다 |
반대로 아래 정보는 처음부터 많이 넣지 않는 편이 낫습니다.
- 같은 로그의 반복 복사
- 이미 폐기한 예전 설계
- 수정 대상과 무관한 전체 파일 목록
- "아마 그랬던 것 같음" 수준의 기억
- 결과 확인에 필요 없는 장식성 설명AI가 긴 입력을 읽을 수 있다는 것과, 그 긴 입력에서 정확히 중요한 것을 고른다는 것은 다른 문제입니다.
긴 내용은 요약해서 넣는다
컨텍스트가 부족할 때는 원문 전체 대신 요약을 넣을 수 있습니다.
예를 들어 긴 설계 문서가 있다면 이렇게 줄일 수 있습니다.
설계 요약:
- 글 원본은 문서 파일로 관리한다.
- 공개 글은 published 상태만 노출한다.
- draft는 비공개 검토 화면에서만 확인한다.
- 댓글/좋아요/조회수는 별도 API로 처리한다.
- 홈 화면에는 아직 블로그 진입 링크를 만들지 않는다.이 정도면 AI가 작업 방향을 잡는 데 충분할 수 있습니다.
단, 요약은 위험도 있습니다.
요약하는 사람이 중요한 조건을 빼먹으면 AI도 놓칩니다. 그래서 보안, 결제, 배포, 데이터 삭제처럼 민감한 작업은 원문 또는 실제 설정 파일을 같이 확인하는 편이 안전합니다.
코드 작업에서는 파일 단위보다 흐름 단위가 좋다
AI에게 파일을 줄 때는 단순히 "이 파일 봐"보다 흐름으로 묶는 편이 좋습니다.
예를 들어 댓글 삭제 기능이면:
1. 글 상세 페이지에서 댓글 목록 렌더링
2. 삭제 버튼 클릭
3. API 요청
4. DB 업데이트
5. UI 새로고침이 흐름에 필요한 파일을 고르면 됩니다.
반대로 파일 이름만 보고 고르면 빠지는 게 생길 수 있습니다.
public/assets/article.js
src/api/comments.js
migrations/comment-schema.sql
scripts/build-posts.mjs이런 식으로 UI, API, DB, 정적 생성 흐름을 같이 봐야 하는 작업도 있습니다.
토큰을 아끼는 좋은 습관
토큰을 아끼자는 말은 무조건 짧게 쓰자는 뜻이 아닙니다.
필요한 정보는 충분히 주되, 중복과 노이즈를 줄이자는 뜻입니다.
좋은 습관:
- 같은 로그를 여러 번 붙이지 않는다.
- 이미 결정된 내용은 짧게 요약한다.
- 관련 파일과 무관한 파일을 섞지 않는다.
- 긴 문서는 "결정 사항"과 "열린 질문"으로 줄인다.
- AI에게 먼저 필요한 파일을 찾게 한 뒤 추가로 읽힌다.특히 큰 코드베이스에서는 한 번에 다 넣으려고 하기보다, AI가 필요한 부분을 찾아가게 하는 방식이 낫습니다.
검색 -> 파일 읽기 -> 수정 -> 검증 순서로 진행하면 컨텍스트를 더 효율적으로 쓸 수 있습니다.
컨텍스트가 부족할 때와 과할 때의 신호
작업 중에 이런 답변이 나오면 컨텍스트가 부족하다는 신호일 수 있습니다.
- "일반적으로는..."으로만 답한다.
- 수정해야 할 파일을 특정하지 못한다.
- 제약 조건을 다시 질문한다.
- 실제 로그와 맞지 않는 원인을 말한다.반대로 이런 답변은 컨텍스트가 과하거나 정리가 안 된 상태일 수 있습니다.
- 핵심과 무관한 파일을 계속 언급한다.
- 오래된 조건과 최신 조건을 섞는다.
- 답변이 길지만 실행 순서가 흐릿하다.
- 검증 기준보다 설명이 먼저 길어진다.이때는 모델을 탓하기 전에 입력을 다시 잘라내는 게 빠릅니다. 필요한 파일을 더 넣는 것보다, 불필요한 정보를 빼는 쪽이 효과가 클 때도 많습니다.
정리하면
토큰과 컨텍스트 윈도우는 단순한 모델 스펙이 아닙니다.
AI에게 일을 맡길 때 "무엇을 보여줄 것인가"를 결정하는 기준입니다.
1. 토큰은 AI가 읽고 쓰는 작은 텍스트 단위다.
2. 컨텍스트 윈도우는 한 번에 참고할 수 있는 작업대 크기다.
3. 많이 넣는 것보다 관련 있는 정보를 넣는 게 중요하다.
4. 긴 문서는 요약하되, 민감한 조건은 원문을 확인한다.
5. 코드 작업은 파일 단위보다 흐름 단위로 컨텍스트를 묶는다.다음 글에서는 이 내용을 바탕으로, AI에게 코딩 작업을 맡길 때 어떤 정보를 하나의 입력 묶음으로 만들어야 하는지 정리해보겠습니다.
댓글
0