LLM 코드 생성 원리: 2026 Codex는 코드를 어떻게 수정할까?

생각하는 ai? 예측하는 ai! LLM은 어떻게 코드를 수정할까?
LLM 코드 생성 원리 — 생각하는 ai? 예측하는 ai! LLM은 어떻게 코드를 수정할까?

AI에게 질문하면 자연스러운 답이 빠르게 돌아옵니다. 대화가 워낙 매끄럽다 보니 AI가 사람처럼 내용을 이해하고 생각한다고 느껴질 때도 있죠. AI는 정말 사람과 같은 방식으로 생각하는 걸까요?

우리가 사용하는 AI는 사람처럼 생각해서 정답을 꺼낸다기보다, 학습한 정보와 사용자가 제공한 내용을 바탕으로 다음에 이어질 가능성이 높은 결과를 예측하는 모델에 가깝습니다. 이번 글에서는 LLM 코드 생성 원리와 Codex가 코드를 수정하는 과정을 쉽게 풀어보겠습니다.

바이브 코딩을 하며 겪은 어려움부터 보고 싶다면 이전 글인 비개발자 바이브 코딩 후기: Codex로 해보니 어려웠던 이유 5가지를 먼저 읽어보셔도 좋습니다.

LLM이란 무엇일까?

LLM은 거대 언어 모델

LLM은 Large Language Model의 약자로, 한국어로는 대규모 언어 모델 또는 거대 언어 모델이라고 부릅니다. 많은 문서와 코드를 학습한 뒤 사용자가 입력한 내용에 이어질 가능성이 높은 문장이나 코드를 생성하는 언어 모델이죠.

Google의 머신러닝 공식 교육 자료에서도 LLM을 토큰이나 토큰의 연속을 예측하는 언어 모델로 소개합니다. 토큰은 단어 하나뿐 아니라 단어의 일부나 문자 하나가 될 수도 있습니다. Google for Developers

ChatGPT, Claude, Gemini 같은 대화형 AI의 핵심에도 LLM이 사용됩니다. 코딩을 도와주는 Codex 역시 LLM을 기반으로 사용자의 요청과 기존 코드를 분석합니다.

LLM은 학습된 패턴으로 대화한다

LLM은 사람처럼 생각한 뒤 답하는 방식이 아닙니다. 학습 과정에서 수많은 내부 숫자를 조정하는데, 이를 가중치 또는 매개변수라고 부릅니다. 사용자의 질문이 들어오면 학습된 가중치와 전달받은 문맥을 이용해 다음에 이어질 가능성이 높은 단어를 계산합니다.

OpenAI의 언어 모델 연구에 따르면 모델 성능은 모델 규모, 학습 데이터의 양, 학습에 사용된 연산량과 밀접한 관계가 있습니다. 모델은 이러한 학습 과정을 거치며 언어와 코드에서 반복되는 복잡한 패턴을 익힙니다. OpenAI

LLM은 생각한다기보다 다음 내용을 예측한다

다음 토큰을 차례대로 예측하는 AI

다음과 같은 문장이 있다고 해보겠습니다.

오늘 점심에는 김치찌개를 먹고 밥을 한 공기 더…

이 문장 뒤에는 ‘먹었습니다’ 같은 표현이 등장할 가능성이 높습니다. 정확히 말하면 다음 단어 전체를 한 번에 고르는 것이 아니라 다음 토큰을 예측하고 이어서 그다음 토큰을 다시 예측하는 과정을 반복합니다.

코드를 만들 때도 기본 원리는 같습니다. 사용자의 요구사항과 기존 코드를 바탕으로 현재 상황에 적절해 보이는 코드 토큰을 차례대로 생성합니다.

다만 최근의 추론 모델과 코딩 에이전트는 답변을 한 번 생성하고 끝내지 않습니다. 문제를 여러 단계로 나누고 필요한 도구를 선택한 다음, 실행 결과를 다시 분석하는 과정을 반복합니다.

자연스럽지만 틀릴 수 있는 AI의 환각

LLM은 사실을 확인한 뒤 답을 만드는 구조가 아닙니다. 문맥에서 자연스럽고 가능성이 높아 보이는 내용을 생성하기 때문에 존재하지 않는 함수나 라이브러리를 제안할 때도 있습니다. 이렇게 사실과 다른 내용을 그럴듯하게 생성하는 현상을 흔히 환각이라고 부릅니다.

OpenAI에서는 환각을 모델이 사실이 아닌 답을 자신 있게 생성하는 현상으로 설명합니다. 불확실하다고 말하기보다 추측하도록 보상받는 학습과 평가 방식도 환각 발생에 영향을 줄 수 있다고 봅니다. OpenAI

AI가 일부러 ‘거짓말해야지’라고 생각해서 만든 결과는 아닙니다. 예측을 통해 답을 생성하는 과정에서 잘못된 정보가 만들어진 것입니다. AI가 계속 발전하더라도 모든 답변이 완벽하다고 생각해서는 안 됩니다.

특히 다음 내용은 사용자가 직접 확인해야 합니다.

실제로 존재하는 함수와 라이브러리인지
현재 설치된 버전에서 사용할 수 있는 기능인지
보안이나 인증에 문제가 없는지
수정 후 기존 기능이 정상적으로 작동하는지

토큰과 컨텍스트 윈도우는 무엇일까?

토큰은 문장과 코드를 처리하는 기본 단위

LLM은 입력된 글을 토큰이라는 작은 단위로 나눠 처리합니다. 하나의 토큰은 단어 하나일 수도 있고 단어의 일부, 문장 부호, 문자 하나일 수도 있습니다. Google for Developers

우리가 작성한 질문, AI의 답변, 전달한 코드와 파일 내용은 모두 토큰으로 변환됩니다. 쉽게 말해 토큰은 AI가 글과 코드를 읽고 생성할 때 사용하는 기본 단위입니다. 코드에서는 함수 이름, 변수 이름, 괄호, 연산자 같은 요소도 여러 토큰으로 나뉠 수 있습니다.

컨텍스트 윈도우는 AI가 한 번에 볼 수 있는 범위

LLM이 한 번에 처리할 수 있는 토큰의 범위를 컨텍스트 윈도우라고 합니다. AI가 현재 작업을 위해 책상 위에 펼쳐놓을 수 있는 자료의 양이라고 생각하면 이해하기 쉽습니다.

이 책상 위에는 다음 정보가 펼쳐집니다.

사용자가 작성한 요청
이전 대화 내용
AI의 기존 답변
읽어온 프로젝트 파일
터미널과 빌드 결과
시스템이 제공한 작업 규칙

대화가 길어지고 많은 파일을 읽으면 책상 위에 자료가 계속 쌓입니다. 한도를 넘어서면 오래된 대화나 파일 내용이 제외되거나 요약될 수 있습니다. 사용자가 처음 제시한 규칙이 다른 정보 사이에 묻힐 수도 있죠.

긴 대화에서 처음 알려준 조건이 빠지거나 앞에서 합의한 내용을 AI가 놓치는 이유 중 하나입니다.

Google의 LLM 교육 자료에서도 LLM 성능은 더 많은 문맥을 활용할 수 있다는 점과 관련이 있다고 설명합니다. 다만 문맥이 많다고 해서 모든 정보가 똑같이 중요하게 처리되는 것은 아닙니다. Google for Developers

프로젝트 전체를 무조건 많이 보여주기보다 현재 작업에 필요한 정보를 정확하게 제공하는 편이 좋습니다.

LLM과 Codex는 어떤 관계일까?

LLM이 판단하고 Codex가 도구를 사용한다

일반적인 AI 대화에서는 LLM이 사용자의 질문을 해석하고 텍스트 답변을 생성합니다. 하지만 Codex 같은 코딩 에이전트는 답변만 만들지 않습니다. 파일 검색, 코드 읽기, 파일 수정, 명령어 실행, 빌드와 테스트 같은 도구를 선택해 실제 작업까지 진행합니다.

LLM을 무엇을 해야 할지 판단하는 두뇌에 비유한다면 파일 검색과 코드 수정, 명령어 실행 기능은 눈과 손에 가깝습니다. 그렇다고 Codex를 단순한 손발이라고만 설명하기도 어렵습니다. Codex는 코딩 작업에 맞는 모델과 파일·터미널 도구, 작업을 반복하는 구조까지 포함한 코딩 에이전트에 가깝습니다.

OpenAI는 Codex를 코드를 읽고 수정하며 명령어와 테스트를 실행할 수 있는 코딩 에이전트로 설명합니다. Codex CLI 역시 로컬 저장소에서 코드를 확인하고 수정하고 실행하는 에이전트로 안내합니다. OpenAI

Codex가 코드를 수정하는 과정

Codex가 코드를 수정하는 흐름을 단순하게 정리하면 다음과 같습니다.

사용자 요청
→ LLM이 요청을 분석하고 필요한 작업을 판단
→ Codex가 관련 파일을 검색
→ LLM이 검색된 파일과 코드를 분석
→ LLM이 수정할 내용을 결정
→ Codex가 실제 파일을 수정
→ Codex가 빌드나 테스트를 실행
→ LLM이 실행 결과와 오류를 분석
→ 문제가 있으면 다시 수정

LLM이 파일을 직접 잡고 수정하는 것은 아닙니다. LLM이 다음 행동을 결정하면 Codex의 에이전트 시스템이 도구를 통해 실제 작업을 수행합니다. 검색 결과와 빌드 결과는 다시 LLM에 전달되고 LLM은 이를 분석해 다음 행동을 결정합니다.

OpenAI는 이러한 구조를 사용자, 모델, 도구 사이의 상호작용을 조정하는 에이전트 루프라고 설명합니다. 모델이 도구를 호출하고 결과를 확인한 뒤 필요하면 다음 도구를 다시 호출하는 방식입니다. OpenAI

Codex는 수정할 부분을 어떻게 찾을까?

프로젝트 전체를 처음부터 읽는 것은 아니다

Codex를 프로젝트 폴더에서 실행했다고 해서 AI가 모든 파일을 읽고 완벽하게 이해하는 것은 아닙니다. 일반적으로 사용자의 요청과 관련 있어 보이는 파일부터 검색합니다.

관련 파일을 찾을 때는 다음과 같은 단서를 활용합니다.

파일 이름
폴더 구조
사용자가 열어놓거나 선택한 코드
특정 함수나 변수의 이름
import와 export 관계
오류 메시지에 표시된 파일 경로
비슷한 코드가 사용된 위치

OpenAI는 Codex IDE 확장이 사용자가 열어놓은 파일이나 선택한 코드를 문맥으로 활용할 수 있다고 설명합니다. OpenAI

예를 들어 달력 버튼의 색상을 변경해달라고 요청하면 Calendar라는 이름이 포함된 파일이나 버튼 스타일이 작성된 코드처럼 연관 있어 보이는 부분을 검색합니다.

AI도 찾기 쉬운 코드 구조가 필요하다

AI는 파일명, import 관계, 함수 호출과 코드 패턴을 단서로 관련 파일을 찾습니다. 그래서 AI가 수정할 위치를 쉽게 찾을 수 있도록 코드 구조를 정리해두는 것이 좋습니다.

다음과 같은 프로젝트에서는 AI가 수정 범위를 판단하기 어렵습니다.

비슷한 이름의 컴포넌트가 여러 개 있는 경우
하나의 파일이 여러 기능을 동시에 담당하는 구조
사용하지 않는 예전 코드가 남아 있는 상태
같은 기능이 여러 파일에 중복된 구성
데이터 처리와 화면 코드가 강하게 얽힌 코드

반대로 파일과 컴포넌트의 역할이 명확하면 AI도 수정 범위를 더 빠르게 좁힐 수 있습니다. AI가 이해하기 좋은 코드 구조와 사람이 이해하기 좋은 코드 구조는 크게 다르지 않습니다.

처음 코드를 작성할 때 구조를 어떻게 설계하느냐가 작업 속도와 유지보수, AI 코딩의 정확도에도 영향을 줍니다.

AI에게 코딩 작업을 정확하게 시키는 방법

수정할 대상과 작업 범위를 구체적으로 알려주기

“모바일 화면을 보기 좋게 수정해줘”라고 요청한다고 해보겠습니다. AI는 직전 대화와 프로젝트 코드를 바탕으로 어떤 화면을 수정해야 하는지 추측합니다. ‘보기 좋게’라는 기준까지 AI가 스스로 정해야 합니다.

수정할 페이지, 화면 크기, 변경할 요소와 유지할 요소를 명확하게 설명하는 편이 좋았습니다.

모바일 상세 패널의 높이만 수정해줘.
현재 높이를 결정하는 CSS 값을 먼저 찾아서 설명해줘.
기존 값과 변경할 값을 알려주고 높이는 지금의 절반 정도로 줄여줘.
데스크톱 레이아웃과 데이터 처리 코드는 수정하지 마.

무엇을 바꿀지뿐 아니라 무엇을 건드리면 안 되는지도 알려주면 AI가 추측할 범위를 줄일 수 있습니다.

화면을 캡처해 현재 상태 보여주기

화면 문제는 글로만 설명하면 정확하게 전달하기 어렵습니다. Windows에서는 Windows + Shift + S로 화면을 캡처해 원하는 위치를 보여줄 수 있습니다.

저는 현재 화면에서 어떤 부분이 문제인지 표시하고 원하는 결과를 구체적으로 설명했습니다. ‘여백을 줄여줘’라고만 말하기보다 다음과 같이 요청하는 편이 정확했습니다.

제목과 버튼 사이의 세로 여백만 현재의 절반으로 줄여줘. 다른 요소의 여백은 변경하지 마.

AI가 알아서 이해할 것이라고 생각하기보다 판단에 필요한 정보를 직접 제공하는 것이 좋았습니다.

한 번에 하나의 작업만 맡기기

여러 기능을 한꺼번에 수정하면 AI가 읽어야 할 파일과 판단해야 할 내용이 많아집니다. 수정 결과가 잘못됐을 때 어느 요청에서 문제가 생겼는지 찾기도 어렵습니다.

그래서 기능 하나를 수정하고 직접 확인한 뒤 다음 작업으로 넘어가기 시작했습니다. 작업을 작게 나누니 AI가 처리할 문맥이 단순해졌고 문제가 생겼을 때 되돌리기도 쉬웠습니다.

작업 전에 AI가 이해한 내용을 확인하기

간단한 수정은 바로 작업을 시켜도 됩니다. 하지만 요청이 길거나 여러 부분을 함께 수정해야 한다면 먼저 AI가 이해한 내용을 확인하는 편이 좋았습니다.

단순히 “이해했어?”라고 물으면 AI가 “이해했습니다”라고만 답할 수 있습니다. 그래서 다음처럼 요청했습니다.

아직 코드는 수정하지 마.
네가 이해한 목표, 수정할 파일, 변경할 내용, 유지할 기능을 먼저 설명해줘.

AI가 이해한 내용을 듣고 제가 의도한 것과 맞는지 다시 검토했습니다. 다르게 이해한 부분이 보이면 바로잡은 뒤 작업을 시작하게 했죠. 이 과정을 한두 번 거치면 길고 복잡한 요청도 훨씬 정확하게 전달할 수 있었습니다.

AI 코딩에서 사용자가 해야 할 가장 중요한 일

AI에게 좋은 결과를 얻는 핵심은 모든 자율성을 주고 마음껏 예측하게 두는 것이 아니었습니다.

먼저 사용자가 어떤 프로젝트를 만들고 싶은지, 이번 작업에서 무엇을 바꿔야 하는지 알고 있어야 합니다. AI가 올바른 방향을 예측하도록 필요한 자료를 제공하고 수정 범위를 제한한 다음, 작업 결과도 직접 검증해야 했습니다.

AI는 사용자의 생각을 언제나 정확한 결과로 바꿔주는 마법의 도구가 아닙니다. 설명과 방향이 명확할수록 원하는 결과에 가까워집니다.

LLM 코드 생성 원리를 알면 요청도 달라진다

LLM은 프로젝트 전체를 완벽하게 이해하고 사람처럼 정답을 꺼내 코드를 작성하지 않습니다. 학습된 패턴과 사용자가 제공한 문맥을 바탕으로 다음에 필요한 코드와 행동을 예측합니다.

AI 코딩의 정확도를 높이려면 사용자가 목표와 수정 범위를 명확히 설명하고 필요한 파일과 화면을 제공한 뒤 작업 결과를 검증해야 합니다.

다음 글에서는 Codex를 사용하면서 깨달은 코드보다 중요한 것, 그리고 프로젝트 구조와 규칙이 AI 작업 결과에 어떤 영향을 주는지 이야기해보겠습니다.

참고 자료

Google for Developers, Introduction to Large Language Models
Google for Developers, What’s a Large Language Model?
OpenAI, Scaling Laws for Neural Language Models
OpenAI, Why Language Models Hallucinate
OpenAI, Codex
OpenAI, Unrolling the Codex Agent Loop

\n\n