Ch.7 왜 이렇게 되는가 - AI 코딩 도구의 작동 원리¶
< 사례: 같은 문제, 다른 프롬프트 | CS 키워드로 AI를 제어하는 법 >
앞에서 세 가지 사례를 봤다. 같은 문제인데 키워드 하나 차이로 AI의 응답이 완전히 달라졌다. "왜 AI는 알아서 좋은 답을 못 주는가?" 이 질문에 답하려면, AI 코딩 도구가 어떻게 작동하는지를 대략이라도 이해해야 한다.
(참고: 이 섹션은 LLM을 깊이 다루는 게 목적이 아니다. "왜 키워드가 중요한지"를 이해하는 데 필요한 최소한의 원리만 설명한다.)
AI가 왜 그런 답을 뱉나: 정체는 LLM¶
Cursor, Copilot, Claude Code, ChatGPT. 전부 내부에 LLM이라는 엔진을 쓴다.
LLM (Large Language Model, 대규모 언어 모델)
대량의 텍스트 데이터로 훈련된 AI 모델이다. "다음에 올 가장 적절한 단어(토큰)를 예측"하는 방식으로 동작한다. GPT, Claude, Gemini 등이 여기에 해당한다. 코드도 텍스트의 일종이니까 코드 생성도 가능하다.
LLM의 핵심 동작 원리를 한 문장으로 요약하면 이거다:
"입력 텍스트(프롬프트)를 받아서, 그 다음에 올 텍스트를 확률적으로 생성한다."
여기서 핵심은 "확률적"이라는 단어다. LLM은 정답을 계산하는 게 아니라, 훈련 데이터에서 학습한 패턴을 기반으로 "가장 그럴듯한 다음 단어"를 고른다. 이게 무슨 뜻인지, 사례 B(성능 최적화)를 다시 보자.
"성능 최적화" vs "Full Table Scan + 인덱스"¶
프롬프트가 "성능 최적화 해줘"이면, LLM은 프롬프트 전체의 맥락을 종합해서 "성능 최적화"에 이어질 가장 그럴듯한 텍스트를 생성한다. "성능 최적화"라는 맥락에 연결되는 개념은 Redis, CDN, 캐싱, 비동기, 로드밸런서... 온갖 것이 다 있다. 맥락이 넓으니 답도 넓다.
프롬프트가 "EXPLAIN 결과가 Full Table Scan이다. B-Tree 인덱스를 걸어줘"이면? LLM이 참고하는 맥락이 명확하다. "Full Table Scan"과 "B-Tree 인덱스"가 맥락을 좁혀서 인덱스 관련 내용만 생성하게 된다.
이걸 비유하면 이렇다. AI한테 "맛집 추천해줘"라고 물으면 서울 전체에서 아무 식당이나 추천한다. "강남역 근처 혼밥 가능한 라멘집"이라고 물으면 범위가 좁아져서 쓸만한 답이 나온다.
CS 키워드가 하는 역할이 이거다. 프롬프트의 "검색 범위"를 좁혀준다.
Token: LLM이 텍스트를 읽는 단위¶
Token (토큰)
LLM이 텍스트를 처리하는 기본 단위다. 단어보다 작거나 같은 크기의 조각이다. 영어는 단어 하나가 대략 1~2 토큰, 한국어는 같은 내용을 쓸 때 토큰을 더 많이 소모한다. 정확한 토큰 수는 모델마다 다르다 (토크나이저가 다르기 때문). 프롬프트도 토큰으로 변환되고, 응답도 토큰 단위로 생성된다.
LLM은 글자 단위가 아니라 토큰 단위로 텍스트를 처리한다. 이게 왜 중요한가?
CS 키워드 하나가 여러 일반 단어보다 "정보 밀도"가 높기 때문이다. "데이터베이스 검색이 느린 문제를 해결하고 싶습니다"는 상황 설명이다. "Full Table Scan → B-Tree Index"는 원인과 해법이다. 토큰 수는 후자가 더 적은데, 전달하는 정보는 훨씬 정확하다.
적은 토큰으로 더 정확한 지시를 내릴 수 있다. 이게 키워드를 아는 사람의 효율이다. 이 토큰의 총 개수에 상한이 있는데, 그게 바로 Context Window다.
Context Window: AI의 기억 한계¶
Context Window (컨텍스트 윈도우)
LLM이 한 번에 처리할 수 있는 토큰 수의 상한이다. 모델마다 다르고, 세대가 바뀌면 늘어나는 추세다 (2025년 기준 수십만~수백만 토큰까지 지원되는 모델도 있다). 프롬프트 + 응답이 이 범위 안에 들어가야 한다. 범위를 넘으면 앞부분을 잘라내거나 요약한다.
Context Window가 아무리 커도, 프롬프트에 넣을 수 있는 정보는 한정돼 있다. 프로젝트의 모든 코드를 통째로 넣을 수는 없다. 그래서 "어떤 정보를 넣느냐"가 중요하다.
"이 API가 느려요, 코드 전체 보내드릴게요, 최적화 좀 해주세요"라고 수천 줄을 보내는 것보다, "EXPLAIN 결과 Full Table Scan. email 컬럼에 인덱스가 없다"라고 2줄 보내는 게 AI 입장에서 훨씬 처리하기 쉽다.
CS 키워드는 정보를 압축하는 도구다. Ch.2에서 "print가 느린 이유"를 모르는 사람은 "프로그램이 느려요"라고 설명하지만, 아는 사람은 "System Call 횟수가 너무 많다"라고 한 줄로 설명한다. 같은 원리가 AI 프롬프트에도 적용된다.
Hallucination: AI가 틀리는 이유¶
Hallucination (환각, 할루시네이션)
LLM이 사실이 아닌 정보를 마치 사실인 것처럼 생성하는 현상이다. 존재하지 않는 라이브러리, 잘못된 API 사용법, 틀린 코드를 자신 있게 내놓는다. LLM은 "그럴듯한 다음 토큰을 예측"하는 구조이지, 사실 여부를 검증하는 메커니즘이 없다. 학습 데이터가 충분해도 발생하는 구조적 한계다.
키워드로 범위를 좁혀줘도 AI가 틀린 답을 내놓을 때가 있다. AI는 자신 있게 틀린다. 이걸 잡으려면 "AI가 내놓은 답이 맞는지" 판단할 수 있어야 한다. 판단하려면? CS 키워드를 알아야 한다.
사례 B에서 AI가 "Redis를 붙이세요"라고 했을 때, CS를 모르는 사람은 "AI가 추천했으니까 맞겠지"라고 생각한다. CS를 아는 사람은 "잠깐, EXPLAIN부터 돌려보자. 인덱스 문제일 수도 있잖아"라고 판단한다.
AI가 코드를 짜주는 시대에 CS가 더 중요해진 이유가 여기에 있다. AI의 답을 검증할 수 있느냐 없느냐가 CS 키워드로 갈린다.
(이 주제는 Ch.9 "AI가 만든 코드 리뷰하기"에서 본격적으로 다룬다.)
정리: AI 코딩 도구의 한계¶
LLM 기반 AI 코딩 도구의 특성을 정리하면:
- 확률적 생성이다. 정답을 계산하지 않는다.
- 프롬프트가 방향을 결정한다. "넓은 질문 → 넓은 답", "좁은 질문 → 좁은 답".
- Context Window가 유한하다. 적은 토큰으로 많은 정보를 전달하는 게 유리하다.
- 틀릴 수 있다. 검증은 사람의 몫이다.
1~3번에서 CS 키워드가 필요하고, 4번에서는 CS 지식 자체가 필요하다.
그러면 구체적으로 어떻게 CS 키워드를 프롬프트에 활용하면 되는가? 다음에서 실전 패턴을 본다.