트랜스포머로 코드 이해하기 완벽 가이드

ChatGPT와 Copilot이 코드를 어떻게 이해하고 생성하는지 궁금하신가요? 트랜스포머 모델이 코드를 토큰으로 분해하고, Self-Attention으로 문맥을 파악하며, 온도 파라미터로 창의성을 조절하는 원리를 실무 예제와 함께 배워봅니다.

1. 트랜스포머가 코드를 토큰화하는 방식

어느 날 김개발 씨가 ChatGPT에게 코드 설명을 요청했습니다. 그런데 문득 이런 생각이 들었습니다.

"이 AI는 내 코드를 어떻게 읽고 이해하는 걸까?" 코드를 줄줄이 읽는 사람처럼 읽는 걸까요, 아니면 다른 방식이 있을까요?

트랜스포머는 코드를 그대로 읽지 않고 토큰이라는 작은 조각으로 분해합니다. 마치 문장을 단어로 나누듯이, 코드도 의미 있는 단위로 쪼갭니다.

이 과정을 토큰화라고 하며, AI가 코드를 이해하는 첫 번째 단계입니다. 함수명, 변수명, 괄호, 들여쓰기까지 모두 별도의 토큰으로 처리됩니다.

다음 코드를 살펴봅시다.

import tiktoken

# OpenAI GPT-3.5/4 토크나이저 로드
encoding = tiktoken.encoding_for_model("gpt-4")

# 샘플 코드
code = """
def calculate_sum(numbers):
    return sum(numbers)
"""

# 토큰화 실행
tokens = encoding.encode(code)
print(f"토큰 개수: {len(tokens)}")
print(f"토큰 목록: {tokens}")

# 각 토큰을 문자열로 복원
for token in tokens:
    print(f"토큰 {token}: '{encoding.decode([token])}'")

김개발 씨는 입사 6개월 차 주니어 개발자입니다. 요즘 회사에서 GitHub Copilot을 도입했는데, 신기하게도 자신이 작성하던 코드의 다음 줄을 척척 예측해줍니다.

점심시간에 선배 박시니어 씨에게 물었습니다. "이게 어떻게 제 의도를 알고 코드를 만들어주는 거예요?" 박시니어 씨가 웃으며 답했습니다.

"Copilot은 트랜스포머라는 AI 모델을 사용하는데, 먼저 네 코드를 토큰으로 쪼개서 이해한다네." 그렇다면 토큰화란 정확히 무엇일까요? 쉽게 비유하자면, 토큰화는 마치 레고 블록을 분해하는 것과 같습니다.

완성된 레고 작품을 보고 바로 이해하기보다는, 먼저 블록 하나하나로 분해해서 어떤 조각들로 이루어져 있는지 파악하는 것입니다. 코드도 마찬가지로 의미 있는 최소 단위로 쪼개야 AI가 처리할 수 있습니다.

토큰화가 없던 시절에는 어땠을까요? 초기 자연어 처리 모델들은 단어 단위로만 분석했습니다.

하지만 프로그래밍 언어에는 calculateSum처럼 camelCase로 작성된 복합 단어나 ==, != 같은 연산자가 많습니다. 단순히 공백으로 나누면 이런 의미 있는 단위들을 놓치게 됩니다.

더 큰 문제는 새로운 단어를 만날 때마다 처리하지 못한다는 것이었습니다. 개발자들은 매일 새로운 변수명과 함수명을 만들어냅니다.

기존 방식으로는 이런 창의적인 이름들을 전혀 이해할 수 없었습니다. 바로 이런 문제를 해결하기 위해 서브워드 토큰화가 등장했습니다.

서브워드 토큰화를 사용하면 모든 단어를 미리 알 필요가 없습니다. calculateSum을 calculate와 Sum으로 나누거나, 심지어 calc, ulate, Sum처럼 더 작은 조각으로 분해할 수 있습니다.

이렇게 하면 처음 보는 함수명이라도 기존에 학습한 조각들의 조합으로 이해할 수 있습니다. 무엇보다 효율적인 처리가 가능해집니다.

AI 모델은 고정된 크기의 어휘 사전을 가지고 있는데, 토큰화를 통해 무한대에 가까운 코드 패턴을 제한된 어휘로 표현할 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 tiktoken 라이브러리를 임포트합니다. 이것은 OpenAI에서 공개한 토크나이저로, GPT 모델이 실제로 사용하는 방식 그대로 토큰화를 수행합니다.

다음으로 encoding_for_model로 GPT-4의 토크나이저를 불러옵니다. 그리고 샘플 코드를 문자열로 준비한 뒤, encode 메서드로 토큰 ID 리스트를 얻습니다.

흥미로운 부분은 마지막 반복문입니다. 각 토큰 ID를 다시 문자열로 복원해보면 어떤 단위로 분해되었는지 눈으로 확인할 수 있습니다.

예를 들어 def는 하나의 토큰이지만, 함수명은 여러 토큰으로 나뉠 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 사내 코드 검색 시스템을 만든다고 가정해봅시다. 개발자가 "사용자 인증"이라고 검색하면, 시스템은 이를 토큰화해서 authenticate, User, Auth 같은 조각들을 찾습니다.

토큰 단위로 매칭하면 정확한 함수명을 몰라도 관련 코드를 찾아낼 수 있습니다. 많은 AI 코딩 도구들이 이런 방식으로 코드베이스를 색인하고 있습니다.

GitHub Copilot도 여러분이 작성 중인 코드를 실시간으로 토큰화해서 다음에 올 토큰을 예측합니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 토큰 수를 고려하지 않고 긴 프롬프트를 작성하는 것입니다. GPT-4는 입력과 출력을 합쳐 최대 8,192개 또는 32,768개 토큰을 처리할 수 있습니다.

토큰 수를 초과하면 요청이 실패하거나 응답이 잘립니다. 따라서 API를 호출하기 전에 토큰 수를 먼저 확인하는 습관을 들여야 합니다.

위 코드처럼 len(tokens)로 개수를 체크하면 예상치 못한 오류를 방지할 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 긴 코드를 복사했을 때 가끔 응답이 이상하게 나오는 거였군요!" 토큰화를 제대로 이해하면 AI 코딩 도구를 더 효과적으로 사용할 수 있습니다.

여러분도 오늘 배운 내용을 실제로 테스트해 보세요.

실전 팁

💡 - tiktoken 라이브러리로 실제 GPT 토큰 수를 정확히 측정하세요

긴 코드 파일은 청크로 나눠서 처리하면 토큰 제한을 피할 수 있습니다

2. 코드 문법과 Self-Attention

코드 리뷰 시간입니다. 김개발 씨가 작성한 함수를 보던 박시니어 씨가 물었습니다.

"이 변수는 어디서 정의된 거죠?" 사람은 코드 전체를 훑어보며 변수의 출처를 찾지만, AI는 어떻게 이런 문맥을 파악할까요?

Self-Attention은 트랜스포머가 코드의 각 토큰이 다른 토큰들과 어떤 관계인지 파악하는 메커니즘입니다. 마치 사람이 문장을 읽을 때 주어와 동사를 연결하듯이, AI도 변수명과 그 정의를 연결합니다.

이를 통해 코드의 문맥과 의존성을 이해할 수 있습니다.

다음 코드를 살펴봅시다.

import torch
import torch.nn.functional as F

# 간단한 Self-Attention 예제 (의사 코드)
def simple_self_attention(tokens):
    # 토큰들을 벡터로 변환 (실제로는 임베딩 레이어 사용)
    Q = tokens  # Query
    K = tokens  # Key
    V = tokens  # Value

    # Attention Score 계산
    scores = torch.matmul(Q, K.transpose(-2, -1))
    scores = scores / (K.size(-1) ** 0.5)  # 스케일링

    # Softmax로 확률 분포 변환
    attention_weights = F.softmax(scores, dim=-1)

    # Value에 가중치 적용
    output = torch.matmul(attention_weights, V)
    return output, attention_weights

김개발 씨는 오늘 복잡한 레거시 코드를 분석하고 있습니다. 500줄이 넘는 파일에서 특정 변수가 어디서 처음 선언되었는지 찾느라 눈이 빠질 지경입니다.

이때 GitHub Copilot이 변수에 마우스를 올리자 정의 위치를 정확히 알려줍니다. "이건 어떻게 아는 거지?" 김개발 씨가 신기해하자, 옆자리 박시니어 씨가 설명합니다.

"그게 바로 Self-Attention의 마법이야." 그렇다면 Self-Attention이란 정확히 무엇일까요? 쉽게 비유하자면, Self-Attention은 마치 독서할 때 형광펜으로 중요한 부분을 표시하는 것과 같습니다.

문장을 읽으면서 "이 단어는 앞에 나온 저 단어와 관련이 있구나"라고 연결 짓는 과정입니다. 코드에서도 마찬가지로 각 토큰이 다른 모든 토큰과 얼마나 관련 있는지 계산합니다.

Self-Attention이 없던 초기 모델들은 어땠을까요? RNN이나 LSTM 같은 순환 신경망은 코드를 순차적으로 처리했습니다.

왼쪽부터 오른쪽으로 한 줄씩 읽어가며 정보를 축적했습니다. 하지만 이 방식은 치명적인 단점이 있었습니다.

파일의 첫 줄에 정의된 변수를 500줄 아래에서 참조하면, 그 먼 거리 때문에 관계를 잊어버리기 쉬웠습니다. 더 큰 문제는 병렬 처리가 불가능하다는 것이었습니다.

이전 토큰을 처리해야 다음 토큰을 처리할 수 있어서, 긴 코드 파일은 분석 시간이 엄청나게 오래 걸렸습니다. 바로 이런 문제를 해결하기 위해 Self-Attention 메커니즘이 등장했습니다.

Self-Attention을 사용하면 모든 토큰이 동시에 서로를 바라봅니다. 첫 줄의 변수 정의와 500줄 아래의 변수 사용이 직접 연결됩니다.

거리가 아무리 멀어도 관계의 강도는 동일하게 계산됩니다. 또한 병렬 처리가 가능해집니다.

GPU의 수천 개 코어가 동시에 여러 토큰을 처리할 수 있어서, 긴 코드도 빠르게 분석할 수 있습니다. 무엇보다 다중 헤드 Attention을 사용하면 여러 종류의 관계를 동시에 파악합니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 토큰을 Query, Key, Value라는 세 가지 역할로 복사합니다.

이것은 데이터베이스 검색과 비슷한 개념입니다. Query는 "내가 찾고자 하는 것", Key는 "검색 대상", Value는 "실제 가져올 값"입니다.

다음으로 Query와 Key를 곱해서 Attention Score를 계산합니다. 이 점수가 높을수록 두 토큰의 관련성이 큽니다.

예를 들어 변수명 토큰의 Query와 그 정의부의 Key를 곱하면 높은 점수가 나옵니다. 스케일링 단계에서는 벡터 차원의 제곱근으로 나눠줍니다.

이렇게 하지 않으면 Softmax 함수에서 값이 포화되어 학습이 어려워집니다. 마지막으로 Softmax로 점수를 확률 분포로 변환하고, Value에 가중치를 적용해서 최종 출력을 만듭니다.

실제 현업에서는 어떻게 활용될까요? 예를 들어 코드 자동 완성 기능을 생각해봅시다.

여러분이 user.까지 타이핑하면, AI는 Self-Attention을 통해 user 변수의 정의부를 찾아갑니다. 그리고 해당 클래스의 메서드 목록을 파악해서 .getName(), .getEmail() 같은 제안을 보여줍니다.

실제로 Microsoft의 IntelliCode나 TabNine 같은 도구들이 이런 방식으로 작동합니다. 코드 전체의 문맥을 파악해서 정확한 제안을 제공합니다.

하지만 주의할 점도 있습니다. Self-Attention의 **계산 복잡도는 O(n²)**입니다.

토큰 개수가 두 배가 되면 계산량은 네 배가 됩니다. 따라서 아주 긴 코드 파일은 처리 시간이 급격히 증가합니다.

또한 Attention Weight를 시각화해보면 때로는 이상한 부분에 주목하는 경우도 있습니다. AI가 사람처럼 완벽하게 코드를 이해하는 것은 아니라는 점을 기억해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 듣고 나니 김개발 씨도 이해가 됐습니다.

"그래서 Copilot이 제가 사용하려는 함수의 파라미터를 정확히 아는 거였군요!" Self-Attention을 제대로 이해하면 AI가 왜 특정 제안을 하는지, 왜 때로는 잘못된 제안을 하는지 알 수 있습니다. 여러분도 오늘 배운 내용을 실제 코딩 도구를 사용하며 체험해 보세요.

실전 팁

💡 - Multi-Head Attention은 여러 관점에서 코드를 분석합니다. 하나는 변수 관계, 다른 하나는 함수 호출 관계를 추적합니다

Attention Weight를 시각화하면 AI가 코드의 어느 부분에 집중하는지 볼 수 있습니다

3. 코드 컨텍스트 이해 능력

김개발 씨가 Copilot에게 함수 하나만 보여줬는데, 신기하게도 프로젝트 전체 구조를 고려한 코드를 제안받았습니다. "어떻게 내 프로젝트 스타일을 아는 거지?" 궁금증이 생겼습니다.

AI는 단순히 함수만 보는 게 아니라 주변 맥락까지 파악합니다.

트랜스포머는 단순히 한 줄의 코드만 보지 않고 앞뒤 문맥을 종합적으로 이해합니다. 파일의 import 문, 클래스 정의, 주석까지 모두 참고해서 적절한 코드를 생성합니다.

이를 컨텍스트 윈도우라고 하며, 모델마다 처리할 수 있는 토큰 길이가 다릅니다. GPT-4는 최대 32,768개 토큰까지 컨텍스트로 활용합니다.

다음 코드를 살펴봅시다.

from openai import OpenAI

client = OpenAI()

# 컨텍스트를 포함한 코드 생성 요청
messages = [
    {"role": "system", "content": "당신은 Python 전문 개발자입니다."},
    {"role": "user", "content": """
다음은 우리 프로젝트의 User 클래스입니다:

class User:
    def __init__(self, name, email):
        self.name = name
        self.email = email

이제 User 객체 리스트를 이메일 도메인별로 그룹핑하는 함수를 작성해주세요.
"""}
]

response = client.chat.completions.create(
    model="gpt-4",
    messages=messages,
    temperature=0.3  # 일관성 높은 코드 생성
)

print(response.choices[0].message.content)

김개발 씨는 신규 프로젝트에 투입되었습니다. 기존 코드베이스가 방대해서 스타일 가이드를 익히는 데만 일주일이 걸렸습니다.

그런데 Copilot을 사용하니 자동으로 프로젝트의 네이밍 규칙과 코드 패턴을 따라줍니다. 점심시간에 김개발 씨가 박시니어 씨에게 물었습니다.

"제가 아무 설정도 안 했는데 어떻게 우리 프로젝트 스타일을 아나요?" 박시니어 씨가 답했습니다. "AI가 네 코드 주변을 다 읽고 있기 때문이야.

그게 바로 컨텍스트 이해 능력이지." 그렇다면 컨텍스트 이해란 정확히 무엇일까요? 쉽게 비유하자면, 컨텍스트 이해는 마치 책을 읽을 때 앞부분의 내용을 기억하는 것과 같습니다.

소설의 100페이지를 읽을 때, 10페이지에서 나온 복선을 기억하고 있어야 스토리가 이해됩니다. 코드도 마찬가지로 파일 상단의 import 문이나 전역 변수 정의를 알아야 아래쪽 함수를 제대로 해석할 수 있습니다.

컨텍스트 개념이 없던 초기 코드 생성 모델은 어땠을까요? 예전 모델들은 한 줄 단위로만 코드를 예측했습니다.

이전 줄 몇 개만 보고 다음 줄을 추측했습니다. 하지만 실제 프로그래밍은 그렇게 단순하지 않습니다.

함수 정의는 파일 상단에 있고, 실제 호출은 수백 줄 아래에 있습니다. 더 큰 문제는 프로젝트 전반의 규칙을 파악할 수 없다는 것이었습니다.

어떤 프로젝트는 camelCase를 쓰고, 다른 프로젝트는 snake_case를 씁니다. 컨텍스트 없이는 이런 일관성을 유지할 수 없습니다.

바로 이런 문제를 해결하기 위해 긴 컨텍스트 윈도우가 도입되었습니다. 긴 컨텍스트를 사용하면 파일 전체를 한 번에 이해할 수 있습니다.

GPT-4 Turbo는 128,000개 토큰을 처리할 수 있어서, 대략 300페이지 분량의 코드를 동시에 참고합니다. 이렇게 하면 파일 곳곳에 흩어진 정보를 모두 종합할 수 있습니다.

또한 Few-Shot Learning이 가능해집니다. 프롬프트에 예제 코드 몇 개를 포함시키면, AI가 그 패턴을 학습해서 동일한 스타일로 코드를 생성합니다.

별도의 학습 없이도 프로젝트 맞춤형 코드를 얻을 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 OpenAI 클라이언트를 생성합니다. 그리고 messages 리스트에 대화 이력을 담습니다.

첫 번째 메시지는 system 역할로, AI의 페르소나를 설정합니다. "Python 전문 개발자"라고 지정하면 더 정확한 코드를 생성합니다.

두 번째 메시지는 user 역할로, 실제 요청 내용입니다. 여기서 중요한 점은 기존 클래스 정의를 포함했다는 것입니다.

이 정보가 컨텍스트가 되어 AI는 User 클래스의 구조를 정확히 이해합니다. 마지막으로 chat.completions.create를 호출합니다.

temperature를 0.3으로 낮춰서 일관성 있고 예측 가능한 코드를 얻습니다. 응답에서 생성된 코드를 추출하면, User 클래스와 완벽히 호환되는 함수를 받을 수 있습니다.

실제 현업에서는 어떻게 활용될까요? 예를 들어 대규모 리팩토링 작업을 한다고 가정해봅시다.

기존 함수 10개의 시그니처를 보여주고, 같은 패턴으로 새 함수를 생성해달라고 요청합니다. AI는 파라미터 네이밍, 반환 타입, 에러 핸들링 방식까지 기존 패턴을 따라 일관된 코드를 만들어줍니다.

실제로 Stripe, Shopify 같은 기업들은 사내 코딩 가이드라인을 컨텍스트로 제공해서 팀 전체의 코드 품질을 높이고 있습니다. 하지만 주의할 점도 있습니다.

컨텍스트가 길수록 API 비용이 증가합니다. GPT-4는 입력 토큰당 요금을 부과하므로, 불필요하게 긴 컨텍스트는 비용 낭비입니다.

따라서 정말 필요한 정보만 선별해서 포함시켜야 합니다. 또한 너무 많은 정보를 주면 오히려 중요한 부분을 놓칠 수 있습니다.

이를 "Lost in the Middle" 현상이라고 하는데, 컨텍스트 중간에 있는 정보는 앞뒤보다 덜 활용되는 경향이 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 조언대로 김개발 씨는 중요한 클래스 정의와 타입 힌트를 컨텍스트로 제공하기 시작했습니다. 그러자 Copilot의 제안 품질이 확연히 좋아졌습니다.

컨텍스트를 제대로 활용하면 AI를 더 강력한 협업 도구로 만들 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에서 시도해 보세요.

실전 팁

💡 - 중요한 타입 정의나 인터페이스는 컨텍스트 앞부분에 배치하세요

컨텍스트가 너무 길면 요약본을 만들어 핵심만 제공하는 것이 효과적입니다

4. 온도 파라미터로 창의성 조절하기

김개발 씨가 ChatGPT에게 같은 질문을 두 번 했는데 완전히 다른 답변을 받았습니다. "왜 매번 다른 코드를 주는 거지?" 궁금해진 김개발 씨가 박시니어 씨에게 물었습니다.

"그건 온도 설정 때문이야. 낮추면 항상 비슷한 답을, 높이면 창의적인 답을 얻을 수 있어."

온도 파라미터는 AI가 다음 토큰을 선택할 때 얼마나 무작위성을 허용할지 결정합니다. 0에 가까우면 가장 확률 높은 토큰만 선택해서 일관되고 예측 가능한 코드를 생성합니다.

반대로 1 이상으로 높이면 확률이 낮은 토큰도 선택해서 창의적이고 다양한 결과를 만듭니다. 코드 생성에는 보통 0.2~0.5가 적합합니다.

다음 코드를 살펴봅시다.

from openai import OpenAI

client = OpenAI()

prompt = "Python으로 피보나치 수열을 계산하는 함수를 작성해주세요."

# 온도 0.0 - 가장 확정적인 답변
response_cold = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}],
    temperature=0.0
)

# 온도 1.0 - 창의적인 답변
response_warm = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}],
    temperature=1.0
)

print("=== 온도 0.0 결과 ===")
print(response_cold.choices[0].message.content)

print("\n=== 온도 1.0 결과 ===")
print(response_warm.choices[0].message.content)

김개발 씨는 요즘 알고리즘 문제를 풀 때 ChatGPT의 도움을 받습니다. 그런데 이상한 점을 발견했습니다.

어제는 재귀로 풀이를 제시했는데, 오늘은 똑같은 문제를 물어봤더니 반복문으로 답하는 겁니다. "뭔가 일관성이 없는 것 같은데요?" 김개발 씨가 박시니어 씨에게 투덜거렸습니다.

박시니어 씨가 웃으며 답했습니다. "그게 바로 온도 때문이야.

온도를 조절하면 AI가 얼마나 모험적으로 답할지 정할 수 있어." 그렇다면 온도 파라미터란 정확히 무엇일까요? 쉽게 비유하자면, 온도는 마치 요리할 때 불의 세기를 조절하는 것과 같습니다.

약한 불로 요리하면 매번 비슷한 맛이 나지만, 강한 불로 하면 때로는 태우기도 하고 때로는 놀라운 맛을 만들기도 합니다. AI도 온도가 낮으면 안전하고 예측 가능한 답을, 높으면 예상 밖의 창의적인 답을 내놓습니다.

기술적으로 설명하면, AI는 다음 토큰을 선택할 때 확률 분포를 사용합니다. 예를 들어 "def calculate"라는 입력 뒤에 올 토큰이 _sum일 확률 40%, _total일 확률 30%, _result일 확률 20% 이런 식입니다.

온도 개념이 없던 초기에는 어땠을까요? 초기 언어 모델들은 항상 가장 확률 높은 토큰만 선택했습니다.

이를 Greedy Decoding이라고 합니다. 안정적이지만 너무 뻔한 답만 나왔습니다.

창의적인 글쓰기나 브레인스토밍에는 전혀 쓸모가 없었습니다. 반대로 완전히 무작위로 선택하면 어떻게 될까요?

문법도 맞지 않고 의미도 없는 엉터리 코드가 나옵니다. 적절한 균형이 필요했습니다.

바로 이런 문제를 해결하기 위해 온도 파라미터가 도입되었습니다. 온도를 사용하면 확률 분포를 부드럽게 또는 날카롭게 조정할 수 있습니다.

온도가 0에 가까우면 확률 분포가 날카로워져서 1등 후보가 압도적 우위를 갖습니다. 매번 같은 토큰을 선택하게 되어 결정론적인 출력이 나옵니다.

반대로 온도를 높이면 확률 분포가 평평해집니다. 2등, 3등 후보도 선택될 가능성이 커집니다.

이렇게 하면 다양한 접근법을 시도할 수 있습니다. 실무에서는 어떻게 활용할까요?

용도에 따라 온도를 달리 설정합니다. 버그 수정이나 리팩토링처럼 정확성이 중요한 작업에는 온도를 0.1~0.3으로 낮춥니다.

매번 비슷한 안전한 코드를 생성해서 예상치 못한 오류를 방지합니다. 프로토타입 개발이나 아이디어 탐색에는 온도를 0.7~1.0으로 높입니다.

여러 가지 구현 방법을 제시받아서 최적의 접근법을 선택할 수 있습니다. 때로는 생각지도 못한 영리한 솔루션을 발견하기도 합니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 동일한 프롬프트를 준비합니다.

피보나치 수열 계산 함수를 요청하는 내용입니다. 그리고 같은 프롬프트로 두 번 API를 호출하는데, 온도만 다르게 설정합니다.

첫 번째 호출에서는 temperature=0.0을 지정합니다. 이렇게 하면 가장 표준적이고 검증된 방식으로 코드를 생성합니다.

아마도 재귀 함수나 반복문 중 더 보편적인 방법을 선택할 것입니다. 두 번째 호출에서는 temperature=1.0을 지정합니다.

이번에는 메모이제이션, 제너레이터, 행렬 거듭제곱 등 다양한 방법 중 하나를 시도할 수 있습니다. 실행해보면 두 결과가 얼마나 다른지 직접 확인할 수 있습니다.

실제 현업에서는 어떻게 활용될까요? 한 스타트업에서는 UI 컴포넌트를 자동 생성할 때 온도를 높게 설정합니다.

여러 디자인 변형을 빠르게 만들어 A/B 테스트에 사용합니다. 반면 결제 로직 같은 핵심 기능은 온도를 0에 가깝게 설정해서 검증된 패턴만 사용합니다.

대형 기업들은 코드 리뷰 자동화에 온도 0.2를 사용합니다. 일관된 기준으로 코드를 검토해서 리뷰어마다 다른 의견을 내는 문제를 줄입니다.

하지만 주의할 점도 있습니다. 온도를 너무 높이면 문법 오류가 발생할 수 있습니다.

확률이 낮은 토큰을 선택하다 보면 괄호를 닫지 않거나 변수명을 잘못 쓰는 경우가 생깁니다. 생성된 코드는 반드시 테스트해야 합니다.

또한 온도 외에도 top_p, top_k 같은 파라미터도 결과에 영향을 줍니다. 이들을 함께 조정해서 최적의 균형을 찾아야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 듣고 김개발 씨는 온도를 상황에 맞게 조절하기 시작했습니다.

중요한 로직은 낮은 온도로, 실험적인 기능은 높은 온도로 요청하니 훨씬 만족스러운 결과를 얻었습니다. 온도 파라미터를 제대로 이해하면 AI를 더 유연하게 활용할 수 있습니다.

여러분도 오늘 배운 내용을 다양한 상황에서 실험해 보세요.

실전 팁

💡 - 프로덕션 코드는 온도 0.2 이하, 브레인스토밍은 0.8 이상 추천

같은 요청을 여러 번 보내고 싶다면 온도를 높여서 다양한 답변을 받으세요

5. 실습: 다양한 온도값으로 코드 생성 실험

김개발 씨는 온도 파라미터에 대해 배웠지만 실제로 차이가 얼마나 나는지 궁금했습니다. "직접 실험해보면 더 확실히 알 수 있을 텐데." 박시니어 씨가 제안했습니다.

"그럼 온도를 바꿔가며 같은 요청을 해보고 결과를 비교해봐."

이번에는 실제로 온도를 0.0, 0.5, 1.0, 1.5로 변경하며 같은 문제에 대해 코드를 생성해봅니다. 각 온도에서 얼마나 다른 접근법이 나오는지, 코드 품질과 창의성이 어떻게 달라지는지 직접 확인합니다.

이를 통해 상황에 맞는 최적의 온도를 찾는 감각을 기를 수 있습니다.

다음 코드를 살펴봅시다.

from openai import OpenAI
import json

client = OpenAI()

prompt = """
Python으로 문자열에서 가장 많이 등장하는 단어를 찾는 함수를 작성해주세요.
대소문자 구분 없이, 구두점은 제거하고 계산합니다.
"""

temperatures = [0.0, 0.5, 1.0, 1.5]
results = {}

for temp in temperatures:
    response = client.chat.completions.create(
        model="gpt-4",
        messages=[{"role": "user", "content": prompt}],
        temperature=temp,
        max_tokens=500
    )

    results[f"temp_{temp}"] = response.choices[0].message.content
    print(f"\n{'='*50}")
    print(f"온도: {temp}")
    print(f"{'='*50}")
    print(results[f"temp_{temp}"])

# 결과를 파일로 저장
with open("temperature_experiment.json", "w", encoding="utf-8") as f:
    json.dump(results, f, ensure_ascii=False, indent=2)

김개발 씨는 이제 본격적으로 실험을 시작합니다. 노트북을 열고 코드를 작성하기 시작했습니다.

목표는 명확합니다. 동일한 문제를 네 가지 다른 온도로 요청하고, 결과가 어떻게 달라지는지 비교하는 것입니다.

박시니어 씨가 옆에서 조언합니다. "온도 0.0은 가장 안전한 답을 줄 거야.

아마 교과서에 나올 법한 코드가 나올 거고. 온도를 높일수록 점점 더 독특한 접근법이 나올 거야." 실험 설계는 간단합니다.

먼저 프롬프트를 고정합니다. 문자열에서 가장 많이 등장하는 단어를 찾는 함수를 요청합니다.

이 문제는 여러 가지 방법으로 풀 수 있어서 온도의 영향을 확인하기 좋습니다. 딕셔너리를 쓸 수도 있고, Counter를 쓸 수도 있고, 정규식으로 처리할 수도 있습니다.

다음으로 온도 배열을 준비합니다. 0.0, 0.5, 1.0, 1.5 네 가지 값을 시험합니다.

0.0은 완전히 결정론적, 0.5는 약간의 변형, 1.0은 상당히 창의적, 1.5는 매우 모험적인 수준입니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 temperatures 리스트를 순회하는 반복문을 만듭니다. 각 온도마다 동일한 API 호출을 수행합니다.

max_tokens=500으로 제한해서 너무 긴 설명은 받지 않습니다. 코드 자체에 집중하기 위함입니다.

응답을 받으면 results 딕셔너리에 온도별로 저장합니다. 키는 "temp_0.0" 같은 형식으로 만들어서 나중에 비교하기 쉽게 합니다.

그리고 즉시 화면에 출력해서 실시간으로 차이를 확인할 수 있게 합니다. 마지막으로 모든 결과를 JSON 파일로 저장합니다.

이렇게 하면 나중에 다시 분석하거나 팀원들과 공유할 때 편리합니다. 실험을 실행해보면 흥미로운 패턴이 나타납니다.

온도 0.0에서는 아마도 collections.Counter를 사용한 간결한 코드가 나올 것입니다. 파이썬 표준 라이브러리에서 가장 널리 알려진 방법입니다.

매번 실행해도 거의 동일한 코드가 나옵니다. 온도 0.5에서는 약간의 변형이 생깁니다.

어떨 때는 Counter를, 어떨 때는 딕셔너리를 직접 사용할 수 있습니다. 하지만 기본 구조는 비슷합니다.

온도 1.0에서는 더 다양한 접근법이 등장합니다. 정규식으로 단어를 추출하거나, defaultdict를 쓰거나, sorted와 lambda를 조합하는 등 여러 방법을 시도합니다.

온도 1.5에서는 예상치 못한 코드가 나올 수 있습니다. 함수형 프로그래밍 스타일이나 원라이너를 시도할 수도 있습니다.

때로는 지나치게 복잡하거나 비효율적인 코드가 나오기도 합니다. 김개발 씨가 실험 결과를 살펴봅니다.

"와, 정말 다르네요! 온도 0.0은 항상 Counter를 쓰는데, 1.0은 매번 다른 방법을 시도하네요." 박시니어 씨가 고개를 끄덕입니다.

"맞아. 그래서 용도에 맞게 온도를 선택하는 게 중요해.

회사 코드베이스에 통합할 거면 낮은 온도로, 새로운 아이디어를 얻고 싶으면 높은 온도로 설정하는 거지." 실무에서 이런 실험을 활용하는 방법은 다양합니다. 코드 리뷰 자동화를 도입할 때는 먼저 여러 온도로 테스트해봅니다.

어느 온도가 가장 일관되고 유용한 피드백을 주는지 확인한 뒤, 그 설정을 표준으로 정합니다. 문서 자동 생성에는 온도를 약간 높게 설정합니다.

같은 함수라도 다양한 표현으로 설명하면 개발자들이 이해하기 쉽습니다. 단위 테스트 생성에는 온도를 중간 정도로 설정합니다.

엣지 케이스를 다양하게 커버하되, 너무 비현실적인 테스트는 피합니다. 하지만 주의할 점도 있습니다.

온도 1.5 이상은 문법 오류 위험이 높습니다. 실험 결과를 맹신하지 말고 반드시 실행해서 검증해야 합니다.

특히 프로덕션 환경에서는 절대 높은 온도를 사용하지 마세요. 또한 결과를 비교할 때는 코드 품질도 함께 평가해야 합니다.

창의적이지만 비효율적인 코드보다는, 평범하지만 견고한 코드가 나을 때가 많습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

실험을 마친 김개발 씨는 이제 자신만의 온도 설정 가이드를 만들었습니다. 버그 수정은 0.2, 새 기능 개발은 0.5, 프로토타입은 0.8로 설정하기로 했습니다.

직접 실험해보면 온도 파라미터를 체감할 수 있습니다. 여러분도 오늘 배운 코드를 실행해보고 결과를 비교해 보세요.

실전 팁

💡 - 동일한 프롬프트로 온도만 바꿔 10번씩 실행해보면 패턴이 보입니다

JSON으로 저장한 결과를 diff 도구로 비교하면 차이를 명확히 볼 수 있습니다

6. 실습: 토큰 사용량 측정 도구 만들기

김개발 씨는 요즘 ChatGPT API를 자주 사용하는데, 어느 날 청구서를 보고 놀랐습니다. "이게 왜 이렇게 많이 나왔지?" 박시니어 씨가 물었습니다.

"프롬프트마다 토큰을 몇 개나 썼는지 확인해봤어?" 토큰 사용량을 모니터링하지 않으면 비용이 눈덩이처럼 불어날 수 있습니다.

실무에서 AI API를 사용할 때는 토큰 사용량을 추적하는 것이 필수입니다. 이번 실습에서는 코드 입력을 받아 토큰 수를 계산하고, 예상 비용까지 산출하는 도구를 만듭니다.

프롬프트 최적화의 기초이며, API 비용 관리에 직접적으로 도움이 됩니다.

다음 코드를 살펴봅시다.

import tiktoken
from dataclasses import dataclass

@dataclass
class TokenUsage:
    text: str
    token_count: int
    estimated_cost: float
    model: str

class TokenCalculator:
    # GPT-4 가격 (2024년 기준, 실제 가격은 공식 사이트 확인)
    PRICING = {
        "gpt-4": {"input": 0.03, "output": 0.06},  # per 1K tokens
        "gpt-3.5-turbo": {"input": 0.0015, "output": 0.002}
    }

    def __init__(self, model="gpt-4"):
        self.model = model
        self.encoding = tiktoken.encoding_for_model(model)

    def calculate(self, text: str, is_output=False) -> TokenUsage:
        tokens = self.encoding.encode(text)
        token_count = len(tokens)

        price_type = "output" if is_output else "input"
        cost_per_1k = self.PRICING[self.model][price_type]
        estimated_cost = (token_count / 1000) * cost_per_1k

        return TokenUsage(
            text=text[:100] + "..." if len(text) > 100 else text,
            token_count=token_count,
            estimated_cost=estimated_cost,
            model=self.model
        )

    def analyze_conversation(self, messages: list) -> dict:
        total_tokens = 0
        total_cost = 0.0
        details = []

        for msg in messages:
            usage = self.calculate(msg["content"])
            total_tokens += usage.token_count
            total_cost += usage.estimated_cost
            details.append(usage)

        return {
            "total_tokens": total_tokens,
            "total_cost": total_cost,
            "details": details
        }

# 사용 예제
if __name__ == "__main__":
    calc = TokenCalculator("gpt-4")

    sample_code = """
def binary_search(arr, target):
    left, right = 0, len(arr) - 1
    while left <= right:
        mid = (left + right) // 2
        if arr[mid] == target:
            return mid
        elif arr[mid] < target:
            left = mid + 1
        else:
            right = mid - 1
    return -1
"""

    result = calc.calculate(sample_code)
    print(f"모델: {result.model}")
    print(f"토큰 수: {result.token_count}")
    print(f"예상 비용: ${result.estimated_cost:.6f}")

김개발 씨는 지난달 API 비용이 예상보다 3배나 많이 나왔습니다. 원인을 파악하려고 했지만 어디서 토큰을 많이 썼는지 알 수가 없었습니다.

매번 호출할 때마다 로그를 남기지 않았기 때문입니다. 박시니어 씨가 조언했습니다.

"토큰 계산기를 만들어서 호출 전에 미리 확인하는 습관을 들여봐. 그러면 불필요한 비용을 줄일 수 있어." 토큰 사용량을 추적하는 것이 왜 중요할까요?

GPT-4는 입력 토큰당 약 0.03달러, 출력 토큰당 약 0.06달러를 청구합니다. 1,000 토큰이면 얼마 안 되는 것 같지만, 하루에 수백 번 호출하면 금액이 급격히 증가합니다.

특히 긴 컨텍스트를 계속 포함시키면 입력 토큰이 폭발적으로 늘어납니다. 실제로 어떤 스타트업은 토큰 관리를 소홀히 해서 한 달에 수천 달러를 낭비했습니다.

같은 문서를 매번 컨텍스트로 포함시켰는데, 캐싱을 사용했다면 비용을 80% 줄일 수 있었습니다. 바로 이런 문제를 예방하기 위해 토큰 계산 도구가 필요합니다.

토큰 계산 도구를 사용하면 API를 호출하기 전에 비용을 예측할 수 있습니다. 프롬프트가 너무 길면 요약하거나 불필요한 부분을 제거할 수 있습니다.

또한 여러 모델의 비용을 비교해서 최적의 선택을 할 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 TokenUsage라는 데이터 클래스를 정의합니다. 텍스트, 토큰 수, 예상 비용, 모델명을 담습니다.

이렇게 구조화하면 나중에 로그를 분석하기 쉽습니다. 다음으로 TokenCalculator 클래스를 만듭니다.

생성자에서 모델명을 받아 해당 모델의 토크나이저를 로드합니다. PRICING 딕셔너리에는 모델별 가격 정보를 저장합니다.

실제 사용 시에는 OpenAI 공식 사이트에서 최신 가격을 확인해야 합니다. calculate 메서드가 핵심입니다.

텍스트를 받아 토큰으로 인코딩하고 개수를 셉니다. 그리고 입력인지 출력인지에 따라 다른 가격을 적용해서 비용을 계산합니다.

결과를 TokenUsage 객체로 반환합니다. analyze_conversation 메서드는 대화 전체를 분석합니다.

메시지 리스트를 받아 각각의 토큰 수와 비용을 계산하고 합산합니다. 챗봇을 만들 때 유용합니다.

사용 예제를 보면 간단합니다. 이진 탐색 함수 코드를 샘플로 준비하고, calculate를 호출하면 토큰 수와 예상 비용이 나옵니다.

실행해보면 이 정도 길이의 코드가 몇 개의 토큰을 사용하는지 감이 옵니다. 실무에서는 어떻게 활용할까요?

API 래퍼 함수를 만들 때 토큰 계산을 포함시킵니다. OpenAI API를 호출하기 전에 자동으로 토큰을 계산하고 로그에 기록합니다.

월말에 로그를 분석하면 어느 기능이 비용을 많이 쓰는지 파악할 수 있습니다. 프롬프트 최적화에도 활용합니다.

동일한 결과를 내는 두 가지 프롬프트가 있다면, 토큰 수가 적은 쪽을 선택합니다. 예를 들어 "다음 코드를 설명해주세요"보다 "코드 설명:"이 더 짧고 토큰도 적게 씁니다.

예산 관리 시스템에 통합할 수도 있습니다. 팀별로 월간 토큰 할당량을 정하고, 실시간으로 사용량을 추적합니다.

할당량에 가까워지면 경고를 보내 초과 비용을 방지합니다. 김개발 씨는 이제 모든 API 호출에 토큰 계산을 추가했습니다.

대시보드를 만들어 일일 토큰 사용량을 모니터링합니다. 어느 날 확인해보니 불필요하게 긴 시스템 프롬프트가 원인이었습니다.

이를 짧게 수정하자 월 비용이 40% 감소했습니다. 박시니어 씨가 칭찬했습니다.

"잘했어. 토큰 관리를 제대로 하면 같은 예산으로 훨씬 많은 기능을 구현할 수 있어." 하지만 주의할 점도 있습니다.

토큰 가격은 자주 변경됩니다. OpenAI는 정기적으로 가격을 조정하므로, 코드에 하드코딩하지 말고 설정 파일로 분리하세요.

또한 프롬프트 캐싱이나 배치 API 같은 비용 절감 기능도 함께 고려해야 합니다. 토큰 수만 보지 말고 응답 품질도 함께 평가하세요.

프롬프트를 너무 짧게 만들면 토큰은 줄지만 품질이 떨어질 수 있습니다. 적절한 균형을 찾는 것이 중요합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 토큰 계산 도구를 만든 뒤, 김개발 씨는 API 비용을 완벽히 통제할 수 있게 되었습니다.

이제 예상치 못한 청구서를 받을 일이 없습니다. 토큰 사용량을 제대로 관리하면 AI를 비용 효율적으로 활용할 수 있습니다.

여러분도 오늘 배운 도구를 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - tiktoken을 프로젝트에 포함시켜 모든 API 호출 전에 토큰 수를 확인하세요

로그에 토큰 수와 비용을 함께 기록하면 나중에 최적화할 때 유용합니다
캐싱과 배치 API를 활용하면 동일한 작업을 더 저렴하게 처리할 수 있습니다

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#LLM#트랜스포머#토큰화#Self-Attention#온도파라미터#LLM,트랜스포머,토큰

트랜스포머로 코드 이해하기 완벽 가이드

# 트랜스포머로 코드 이해하기 완벽 가이드 ChatGPT와 Copilot이 코드를 어떻게 이해하고 생성하는지 궁금하신가요? 트랜스포머 모델이 코드를 토큰으로 분해하고, Self-Attention으로 문맥을 파악하며, 온도 파라미터로 창의성을 조절하는 원리를 실무 예제와 함께 배워봅니다. --- ## 목차 1. [트랜스포머가 코드를 토큰화하는 방식](#트랜스포머가-코드를-토큰화하는-방식) 2. [코드 문법과 Self-Attention](#코드-문법과-self-attention) 3. [코드 컨텍스트 이해 능력](#코드-컨텍스트-이해-능력) 4. [온도 파라미터로 창의성 조절하기](#온도-파라미터로-창의성-조절하기) 5. [실습: 다양한 온도값으로 코드 생성 실험](#실습:-다양한-온도값으로-코드-생성-실험) 6. [실습: 토큰 사용량 측정 도구 만들기](#실습:-토큰-사용량-측정-도구-만들기) --- ## 1. 트랜스포머가 코드를 토큰화하는 방식 어느 날 김개발 씨가 ChatGPT에게 코드 설명을 요청했습니다. 그런데 문득 이런 생각이 들었습니다. "이 AI는 내 코드를 어떻게 읽고 이해하는 걸까?" 코드를 줄줄이 읽는 사람처럼 읽는 걸까요, 아니면 다른 방식이 있을까요? 트랜스포머는 코드를 그대로 읽지 않고 **토큰**이라는 작은 조각으로 분해합니다. 마치 문장을 단어로 나누듯이, 코드도 의미 있는 단위로 쪼갭니다. 이 과정을 **토큰화**라고 하며, AI가 코드를 이해하는 첫 번째 단계입니다. 함수명, 변수명, 괄호, 들여쓰기까지 모두 별도의 토큰으로 처리됩니다. 다음 코드를 살펴봅시다. ```python import tiktoken # OpenAI GPT-3.5/4 토크나이저 로드 encoding = tiktoken.encoding_for_model("gpt-4") # 샘플 코드 code = """ def calculate_sum(numbers): return sum(numbers) """ # 토큰화 실행 tokens = encoding.encode(code) print(f"토큰 개수: {len(tokens)}") print(f"토큰 목록: {tokens}") # 각 토큰을 문자열로 복원 for token in tokens: print(f"토큰 {token}: '{encoding.decode([token])}'") ``` 김개발 씨는 입사 6개월 차 주니어 개발자입니다. 요즘 회사에서 GitHub Copilot을 도입했는데, 신기하게도 자신이 작성하던 코드의 다음 줄을 척척 예측해줍니다. 점심시간에 선배 박시니어 씨에게 물었습니다. "이게 어떻게 제 의도를 알고 코드를 만들어주는 거예요?" 박시니어 씨가 웃으며 답했습니다. "Copilot은 트랜스포머라는 AI 모델을 사용하는데, 먼저 네 코드를 토큰으로 쪼개서 이해한다네." 그렇다면 토큰화란 정확히 무엇일까요? 쉽게 비유하자면, 토큰화는 마치 레고 블록을 분해하는 것과 같습니다. 완성된 레고 작품을 보고 바로 이해하기보다는, 먼저 블록 하나하나로 분해해서 어떤 조각들로 이루어져 있는지 파악하는 것입니다. 코드도 마찬가지로 의미 있는 최소 단위로 쪼개야 AI가 처리할 수 있습니다. 토큰화가 없던 시절에는 어땠을까요? 초기 자연어 처리 모델들은 단어 단위로만 분석했습니다. 하지만 프로그래밍 언어에는 `calculateSum`처럼 camelCase로 작성된 복합 단어나 `==`, `!=` 같은 연산자가 많습니다. 단순히 공백으로 나누면 이런 의미 있는 단위들을 놓치게 됩니다. 더 큰 문제는 새로운 단어를 만날 때마다 처리하지 못한다는 것이었습니다. 개발자들은 매일 새로운 변수명과 함수명을 만들어냅니다. 기존 방식으로는 이런 창의적인 이름들을 전혀 이해할 수 없었습니다. 바로 이런 문제를 해결하기 위해 **서브워드 토큰화**가 등장했습니다. 서브워드 토큰화를 사용하면 모든 단어를 미리 알 필요가 없습니다. `calculateSum`을 `calculate`와 `Sum`으로 나누거나, 심지어 `calc`, `ulate`, `Sum`처럼 더 작은 조각으로 분해할 수 있습니다. 이렇게 하면 처음 보는 함수명이라도 기존에 학습한 조각들의 조합으로 이해할 수 있습니다. 무엇보다 **효율적인 처리**가 가능해집니다. AI 모델은 고정된 크기의 어휘 사전을 가지고 있는데, 토큰화를 통해 무한대에 가까운 코드 패턴을 제한된 어휘로 표현할 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 `tiktoken` 라이브러리를 임포트합니다. 이것은 OpenAI에서 공개한 토크나이저로, GPT 모델이 실제로 사용하는 방식 그대로 토큰화를 수행합니다. 다음으로 `encoding_for_model`로 GPT-4의 토크나이저를 불러옵니다. 그리고 샘플 코드를 문자열로 준비한 뒤, `encode` 메서드로 토큰 ID 리스트를 얻습니다. 흥미로운 부분은 마지막 반복문입니다. 각 토큰 ID를 다시 문자열로 복원해보면 어떤 단위로 분해되었는지 눈으로 확인할 수 있습니다. 예를 들어 `def`는 하나의 토큰이지만, 함수명은 여러 토큰으로 나뉠 수 있습니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 사내 코드 검색 시스템을 만든다고 가정해봅시다. 개발자가 "사용자 인증"이라고 검색하면, 시스템은 이를 토큰화해서 `authenticate`, `User`, `Auth` 같은 조각들을 찾습니다. 토큰 단위로 매칭하면 정확한 함수명을 몰라도 관련 코드를 찾아낼 수 있습니다. 많은 AI 코딩 도구들이 이런 방식으로 코드베이스를 색인하고 있습니다. GitHub Copilot도 여러분이 작성 중인 코드를 실시간으로 토큰화해서 다음에 올 토큰을 예측합니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 토큰 수를 고려하지 않고 긴 프롬프트를 작성하는 것입니다. GPT-4는 입력과 출력을 합쳐 최대 8,192개 또는 32,768개 토큰을 처리할 수 있습니다. 토큰 수를 초과하면 요청이 실패하거나 응답이 잘립니다. 따라서 **API를 호출하기 전에 토큰 수를 먼저 확인**하는 습관을 들여야 합니다. 위 코드처럼 `len(tokens)`로 개수를 체크하면 예상치 못한 오류를 방지할 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 긴 코드를 복사했을 때 가끔 응답이 이상하게 나오는 거였군요!" 토큰화를 제대로 이해하면 AI 코딩 도구를 더 효과적으로 사용할 수 있습니다. 여러분도 오늘 배운 내용을 실제로 테스트해 보세요. **실전 팁** 💡 - tiktoken 라이브러리로 실제 GPT 토큰 수를 정확히 측정하세요 - 긴 코드 파일은 청크로 나눠서 처리하면 토큰 제한을 피할 수 있습니다 --- ## 2. 코드 문법과 Self-Attention 코드 리뷰 시간입니다. 김개발 씨가 작성한 함수를 보던 박시니어 씨가 물었습니다. "이 변수는 어디서 정의된 거죠?" 사람은 코드 전체를 훑어보며 변수의 출처를 찾지만, AI는 어떻게 이런 문맥을 파악할까요? **Self-Attention**은 트랜스포머가 코드의 각 토큰이 다른 토큰들과 어떤 관계인지 파악하는 메커니즘입니다. 마치 사람이 문장을 읽을 때 주어와 동사를 연결하듯이, AI도 변수명과 그 정의를 연결합니다. 이를 통해 코드의 **문맥**과 **의존성**을 이해할 수 있습니다. 다음 코드를 살펴봅시다. ```python import torch import torch.nn.functional as F # 간단한 Self-Attention 예제 (의사 코드) def simple_self_attention(tokens): # 토큰들을 벡터로 변환 (실제로는 임베딩 레이어 사용) Q = tokens # Query K = tokens # Key V = tokens # Value # Attention Score 계산 scores = torch.matmul(Q, K.transpose(-2, -1)) scores = scores / (K.size(-1) ** 0.5) # 스케일링 # Softmax로 확률 분포 변환 attention_weights = F.softmax(scores, dim=-1) # Value에 가중치 적용 output = torch.matmul(attention_weights, V) return output, attention_weights ``` 김개발 씨는 오늘 복잡한 레거시 코드를 분석하고 있습니다. 500줄이 넘는 파일에서 특정 변수가 어디서 처음 선언되었는지 찾느라 눈이 빠질 지경입니다. 이때 GitHub Copilot이 변수에 마우스를 올리자 정의 위치를 정확히 알려줍니다. "이건 어떻게 아는 거지?" 김개발 씨가 신기해하자, 옆자리 박시니어 씨가 설명합니다. "그게 바로 Self-Attention의 마법이야." 그렇다면 Self-Attention이란 정확히 무엇일까요? 쉽게 비유하자면, Self-Attention은 마치 독서할 때 형광펜으로 중요한 부분을 표시하는 것과 같습니다. 문장을 읽으면서 "이 단어는 앞에 나온 저 단어와 관련이 있구나"라고 연결 짓는 과정입니다. 코드에서도 마찬가지로 각 토큰이 다른 모든 토큰과 얼마나 관련 있는지 계산합니다. Self-Attention이 없던 초기 모델들은 어땠을까요? RNN이나 LSTM 같은 순환 신경망은 코드를 순차적으로 처리했습니다. 왼쪽부터 오른쪽으로 한 줄씩 읽어가며 정보를 축적했습니다. 하지만 이 방식은 치명적인 단점이 있었습니다. 파일의 첫 줄에 정의된 변수를 500줄 아래에서 참조하면, 그 먼 거리 때문에 관계를 잊어버리기 쉬웠습니다. 더 큰 문제는 **병렬 처리가 불가능**하다는 것이었습니다. 이전 토큰을 처리해야 다음 토큰을 처리할 수 있어서, 긴 코드 파일은 분석 시간이 엄청나게 오래 걸렸습니다. 바로 이런 문제를 해결하기 위해 **Self-Attention 메커니즘**이 등장했습니다. Self-Attention을 사용하면 모든 토큰이 동시에 서로를 바라봅니다. 첫 줄의 변수 정의와 500줄 아래의 변수 사용이 직접 연결됩니다. 거리가 아무리 멀어도 관계의 강도는 동일하게 계산됩니다. 또한 **병렬 처리가 가능**해집니다. GPU의 수천 개 코어가 동시에 여러 토큰을 처리할 수 있어서, 긴 코드도 빠르게 분석할 수 있습니다. 무엇보다 **다중 헤드 Attention**을 사용하면 여러 종류의 관계를 동시에 파악합니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 토큰을 Query, Key, Value라는 세 가지 역할로 복사합니다. 이것은 데이터베이스 검색과 비슷한 개념입니다. Query는 "내가 찾고자 하는 것", Key는 "검색 대상", Value는 "실제 가져올 값"입니다. 다음으로 Query와 Key를 곱해서 Attention Score를 계산합니다. 이 점수가 높을수록 두 토큰의 관련성이 큽니다. 예를 들어 변수명 토큰의 Query와 그 정의부의 Key를 곱하면 높은 점수가 나옵니다. 스케일링 단계에서는 벡터 차원의 제곱근으로 나눠줍니다. 이렇게 하지 않으면 Softmax 함수에서 값이 포화되어 학습이 어려워집니다. 마지막으로 Softmax로 점수를 확률 분포로 변환하고, Value에 가중치를 적용해서 최종 출력을 만듭니다. 실제 현업에서는 어떻게 활용될까요? 예를 들어 코드 자동 완성 기능을 생각해봅시다. 여러분이 `user.`까지 타이핑하면, AI는 Self-Attention을 통해 `user` 변수의 정의부를 찾아갑니다. 그리고 해당 클래스의 메서드 목록을 파악해서 `.getName()`, `.getEmail()` 같은 제안을 보여줍니다. 실제로 Microsoft의 IntelliCode나 TabNine 같은 도구들이 이런 방식으로 작동합니다. 코드 전체의 문맥을 파악해서 정확한 제안을 제공합니다. 하지만 주의할 점도 있습니다. Self-Attention의 **계산 복잡도는 O(n²)**입니다. 토큰 개수가 두 배가 되면 계산량은 네 배가 됩니다. 따라서 아주 긴 코드 파일은 처리 시간이 급격히 증가합니다. 또한 Attention Weight를 시각화해보면 때로는 이상한 부분에 주목하는 경우도 있습니다. AI가 사람처럼 완벽하게 코드를 이해하는 것은 아니라는 점을 기억해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 듣고 나니 김개발 씨도 이해가 됐습니다. "그래서 Copilot이 제가 사용하려는 함수의 파라미터를 정확히 아는 거였군요!" Self-Attention을 제대로 이해하면 AI가 왜 특정 제안을 하는지, 왜 때로는 잘못된 제안을 하는지 알 수 있습니다. 여러분도 오늘 배운 내용을 실제 코딩 도구를 사용하며 체험해 보세요. **실전 팁** 💡 - Multi-Head Attention은 여러 관점에서 코드를 분석합니다. 하나는 변수 관계, 다른 하나는 함수 호출 관계를 추적합니다 - Attention Weight를 시각화하면 AI가 코드의 어느 부분에 집중하는지 볼 수 있습니다 --- ## 3. 코드 컨텍스트 이해 능력 김개발 씨가 Copilot에게 함수 하나만 보여줬는데, 신기하게도 프로젝트 전체 구조를 고려한 코드를 제안받았습니다. "어떻게 내 프로젝트 스타일을 아는 거지?" 궁금증이 생겼습니다. AI는 단순히 함수만 보는 게 아니라 **주변 맥락**까지 파악합니다. 트랜스포머는 단순히 한 줄의 코드만 보지 않고 **앞뒤 문맥**을 종합적으로 이해합니다. 파일의 import 문, 클래스 정의, 주석까지 모두 참고해서 적절한 코드를 생성합니다. 이를 **컨텍스트 윈도우**라고 하며, 모델마다 처리할 수 있는 토큰 길이가 다릅니다. GPT-4는 최대 32,768개 토큰까지 컨텍스트로 활용합니다. 다음 코드를 살펴봅시다. ```python from openai import OpenAI client = OpenAI() # 컨텍스트를 포함한 코드 생성 요청 messages = [ {"role": "system", "content": "당신은 Python 전문 개발자입니다."}, {"role": "user", "content": """ 다음은 우리 프로젝트의 User 클래스입니다: class User: def __init__(self, name, email): self.name = name self.email = email 이제 User 객체 리스트를 이메일 도메인별로 그룹핑하는 함수를 작성해주세요. """} ] response = client.chat.completions.create( model="gpt-4", messages=messages, temperature=0.3 # 일관성 높은 코드 생성 ) print(response.choices[0].message.content) ``` 김개발 씨는 신규 프로젝트에 투입되었습니다. 기존 코드베이스가 방대해서 스타일 가이드를 익히는 데만 일주일이 걸렸습니다. 그런데 Copilot을 사용하니 자동으로 프로젝트의 네이밍 규칙과 코드 패턴을 따라줍니다. 점심시간에 김개발 씨가 박시니어 씨에게 물었습니다. "제가 아무 설정도 안 했는데 어떻게 우리 프로젝트 스타일을 아나요?" 박시니어 씨가 답했습니다. "AI가 네 코드 주변을 다 읽고 있기 때문이야. 그게 바로 컨텍스트 이해 능력이지." 그렇다면 컨텍스트 이해란 정확히 무엇일까요? 쉽게 비유하자면, 컨텍스트 이해는 마치 책을 읽을 때 앞부분의 내용을 기억하는 것과 같습니다. 소설의 100페이지를 읽을 때, 10페이지에서 나온 복선을 기억하고 있어야 스토리가 이해됩니다. 코드도 마찬가지로 파일 상단의 import 문이나 전역 변수 정의를 알아야 아래쪽 함수를 제대로 해석할 수 있습니다. 컨텍스트 개념이 없던 초기 코드 생성 모델은 어땠을까요? 예전 모델들은 한 줄 단위로만 코드를 예측했습니다. 이전 줄 몇 개만 보고 다음 줄을 추측했습니다. 하지만 실제 프로그래밍은 그렇게 단순하지 않습니다. 함수 정의는 파일 상단에 있고, 실제 호출은 수백 줄 아래에 있습니다. 더 큰 문제는 **프로젝트 전반의 규칙을 파악할 수 없다**는 것이었습니다. 어떤 프로젝트는 camelCase를 쓰고, 다른 프로젝트는 snake_case를 씁니다. 컨텍스트 없이는 이런 일관성을 유지할 수 없습니다. 바로 이런 문제를 해결하기 위해 **긴 컨텍스트 윈도우**가 도입되었습니다. 긴 컨텍스트를 사용하면 파일 전체를 한 번에 이해할 수 있습니다. GPT-4 Turbo는 128,000개 토큰을 처리할 수 있어서, 대략 300페이지 분량의 코드를 동시에 참고합니다. 이렇게 하면 파일 곳곳에 흩어진 정보를 모두 종합할 수 있습니다. 또한 **Few-Shot Learning**이 가능해집니다. 프롬프트에 예제 코드 몇 개를 포함시키면, AI가 그 패턴을 학습해서 동일한 스타일로 코드를 생성합니다. 별도의 학습 없이도 프로젝트 맞춤형 코드를 얻을 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 OpenAI 클라이언트를 생성합니다. 그리고 messages 리스트에 대화 이력을 담습니다. 첫 번째 메시지는 system 역할로, AI의 페르소나를 설정합니다. "Python 전문 개발자"라고 지정하면 더 정확한 코드를 생성합니다. 두 번째 메시지는 user 역할로, 실제 요청 내용입니다. 여기서 중요한 점은 **기존 클래스 정의를 포함**했다는 것입니다. 이 정보가 컨텍스트가 되어 AI는 User 클래스의 구조를 정확히 이해합니다. 마지막으로 `chat.completions.create`를 호출합니다. temperature를 0.3으로 낮춰서 일관성 있고 예측 가능한 코드를 얻습니다. 응답에서 생성된 코드를 추출하면, User 클래스와 완벽히 호환되는 함수를 받을 수 있습니다. 실제 현업에서는 어떻게 활용될까요? 예를 들어 대규모 리팩토링 작업을 한다고 가정해봅시다. 기존 함수 10개의 시그니처를 보여주고, 같은 패턴으로 새 함수를 생성해달라고 요청합니다. AI는 파라미터 네이밍, 반환 타입, 에러 핸들링 방식까지 기존 패턴을 따라 일관된 코드를 만들어줍니다. 실제로 Stripe, Shopify 같은 기업들은 사내 코딩 가이드라인을 컨텍스트로 제공해서 팀 전체의 코드 품질을 높이고 있습니다. 하지만 주의할 점도 있습니다. 컨텍스트가 길수록 **API 비용이 증가**합니다. GPT-4는 입력 토큰당 요금을 부과하므로, 불필요하게 긴 컨텍스트는 비용 낭비입니다. 따라서 정말 필요한 정보만 선별해서 포함시켜야 합니다. 또한 너무 많은 정보를 주면 오히려 **중요한 부분을 놓칠 수** 있습니다. 이를 "Lost in the Middle" 현상이라고 하는데, 컨텍스트 중간에 있는 정보는 앞뒤보다 덜 활용되는 경향이 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언대로 김개발 씨는 중요한 클래스 정의와 타입 힌트를 컨텍스트로 제공하기 시작했습니다. 그러자 Copilot의 제안 품질이 확연히 좋아졌습니다. 컨텍스트를 제대로 활용하면 AI를 더 강력한 협업 도구로 만들 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에서 시도해 보세요. **실전 팁** 💡 - 중요한 타입 정의나 인터페이스는 컨텍스트 앞부분에 배치하세요 - 컨텍스트가 너무 길면 요약본을 만들어 핵심만 제공하는 것이 효과적입니다 --- ## 4. 온도 파라미터로 창의성 조절하기 김개발 씨가 ChatGPT에게 같은 질문을 두 번 했는데 완전히 다른 답변을 받았습니다. "왜 매번 다른 코드를 주는 거지?" 궁금해진 김개발 씨가 박시니어 씨에게 물었습니다. "그건 온도 설정 때문이야. 낮추면 항상 비슷한 답을, 높이면 창의적인 답을 얻을 수 있어." **온도 파라미터**는 AI가 다음 토큰을 선택할 때 얼마나 무작위성을 허용할지 결정합니다. 0에 가까우면 가장 확률 높은 토큰만 선택해서 **일관되고 예측 가능한** 코드를 생성합니다. 반대로 1 이상으로 높이면 확률이 낮은 토큰도 선택해서 **창의적이고 다양한** 결과를 만듭니다. 코드 생성에는 보통 0.2~0.5가 적합합니다. 다음 코드를 살펴봅시다. ```python from openai import OpenAI client = OpenAI() prompt = "Python으로 피보나치 수열을 계산하는 함수를 작성해주세요." # 온도 0.0 - 가장 확정적인 답변 response_cold = client.chat.completions.create( model="gpt-4", messages=[{"role": "user", "content": prompt}], temperature=0.0 ) # 온도 1.0 - 창의적인 답변 response_warm = client.chat.completions.create( model="gpt-4", messages=[{"role": "user", "content": prompt}], temperature=1.0 ) print("=== 온도 0.0 결과 ===") print(response_cold.choices[0].message.content) print("\n=== 온도 1.0 결과 ===") print(response_warm.choices[0].message.content) ``` 김개발 씨는 요즘 알고리즘 문제를 풀 때 ChatGPT의 도움을 받습니다. 그런데 이상한 점을 발견했습니다. 어제는 재귀로 풀이를 제시했는데, 오늘은 똑같은 문제를 물어봤더니 반복문으로 답하는 겁니다. "뭔가 일관성이 없는 것 같은데요?" 김개발 씨가 박시니어 씨에게 투덜거렸습니다. 박시니어 씨가 웃으며 답했습니다. "그게 바로 온도 때문이야. 온도를 조절하면 AI가 얼마나 모험적으로 답할지 정할 수 있어." 그렇다면 온도 파라미터란 정확히 무엇일까요? 쉽게 비유하자면, 온도는 마치 요리할 때 불의 세기를 조절하는 것과 같습니다. 약한 불로 요리하면 매번 비슷한 맛이 나지만, 강한 불로 하면 때로는 태우기도 하고 때로는 놀라운 맛을 만들기도 합니다. AI도 온도가 낮으면 안전하고 예측 가능한 답을, 높으면 예상 밖의 창의적인 답을 내놓습니다. 기술적으로 설명하면, AI는 다음 토큰을 선택할 때 확률 분포를 사용합니다. 예를 들어 "def calculate"라는 입력 뒤에 올 토큰이 `_sum`일 확률 40%, `_total`일 확률 30%, `_result`일 확률 20% 이런 식입니다. 온도 개념이 없던 초기에는 어땠을까요? 초기 언어 모델들은 항상 가장 확률 높은 토큰만 선택했습니다. 이를 **Greedy Decoding**이라고 합니다. 안정적이지만 너무 뻔한 답만 나왔습니다. 창의적인 글쓰기나 브레인스토밍에는 전혀 쓸모가 없었습니다. 반대로 완전히 무작위로 선택하면 어떻게 될까요? 문법도 맞지 않고 의미도 없는 엉터리 코드가 나옵니다. 적절한 균형이 필요했습니다. 바로 이런 문제를 해결하기 위해 **온도 파라미터**가 도입되었습니다. 온도를 사용하면 확률 분포를 부드럽게 또는 날카롭게 조정할 수 있습니다. 온도가 0에 가까우면 확률 분포가 날카로워져서 1등 후보가 압도적 우위를 갖습니다. 매번 같은 토큰을 선택하게 되어 **결정론적**인 출력이 나옵니다. 반대로 온도를 높이면 확률 분포가 평평해집니다. 2등, 3등 후보도 선택될 가능성이 커집니다. 이렇게 하면 **다양한 접근법**을 시도할 수 있습니다. 실무에서는 어떻게 활용할까요? 용도에 따라 온도를 달리 설정합니다. **버그 수정이나 리팩토링**처럼 정확성이 중요한 작업에는 온도를 0.1~0.3으로 낮춥니다. 매번 비슷한 안전한 코드를 생성해서 예상치 못한 오류를 방지합니다. **프로토타입 개발이나 아이디어 탐색**에는 온도를 0.7~1.0으로 높입니다. 여러 가지 구현 방법을 제시받아서 최적의 접근법을 선택할 수 있습니다. 때로는 생각지도 못한 영리한 솔루션을 발견하기도 합니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 동일한 프롬프트를 준비합니다. 피보나치 수열 계산 함수를 요청하는 내용입니다. 그리고 같은 프롬프트로 두 번 API를 호출하는데, 온도만 다르게 설정합니다. 첫 번째 호출에서는 `temperature=0.0`을 지정합니다. 이렇게 하면 가장 표준적이고 검증된 방식으로 코드를 생성합니다. 아마도 재귀 함수나 반복문 중 더 보편적인 방법을 선택할 것입니다. 두 번째 호출에서는 `temperature=1.0`을 지정합니다. 이번에는 메모이제이션, 제너레이터, 행렬 거듭제곱 등 다양한 방법 중 하나를 시도할 수 있습니다. 실행해보면 두 결과가 얼마나 다른지 직접 확인할 수 있습니다. 실제 현업에서는 어떻게 활용될까요? 한 스타트업에서는 UI 컴포넌트를 자동 생성할 때 온도를 높게 설정합니다. 여러 디자인 변형을 빠르게 만들어 A/B 테스트에 사용합니다. 반면 결제 로직 같은 핵심 기능은 온도를 0에 가깝게 설정해서 검증된 패턴만 사용합니다. 대형 기업들은 코드 리뷰 자동화에 온도 0.2를 사용합니다. 일관된 기준으로 코드를 검토해서 리뷰어마다 다른 의견을 내는 문제를 줄입니다. 하지만 주의할 점도 있습니다. 온도를 너무 높이면 **문법 오류**가 발생할 수 있습니다. 확률이 낮은 토큰을 선택하다 보면 괄호를 닫지 않거나 변수명을 잘못 쓰는 경우가 생깁니다. 생성된 코드는 반드시 테스트해야 합니다. 또한 온도 외에도 **top_p**, **top_k** 같은 파라미터도 결과에 영향을 줍니다. 이들을 함께 조정해서 최적의 균형을 찾아야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 듣고 김개발 씨는 온도를 상황에 맞게 조절하기 시작했습니다. 중요한 로직은 낮은 온도로, 실험적인 기능은 높은 온도로 요청하니 훨씬 만족스러운 결과를 얻었습니다. 온도 파라미터를 제대로 이해하면 AI를 더 유연하게 활용할 수 있습니다. 여러분도 오늘 배운 내용을 다양한 상황에서 실험해 보세요. **실전 팁** 💡 - 프로덕션 코드는 온도 0.2 이하, 브레인스토밍은 0.8 이상 추천 - 같은 요청을 여러 번 보내고 싶다면 온도를 높여서 다양한 답변을 받으세요 --- ## 5. 실습: 다양한 온도값으로 코드 생성 실험 김개발 씨는 온도 파라미터에 대해 배웠지만 실제로 차이가 얼마나 나는지 궁금했습니다. "직접 실험해보면 더 확실히 알 수 있을 텐데." 박시니어 씨가 제안했습니다. "그럼 온도를 바꿔가며 같은 요청을 해보고 결과를 비교해봐." 이번에는 실제로 온도를 0.0, 0.5, 1.0, 1.5로 변경하며 같은 문제에 대해 코드를 생성해봅니다. 각 온도에서 얼마나 다른 접근법이 나오는지, 코드 품질과 창의성이 어떻게 달라지는지 직접 확인합니다. 이를 통해 **상황에 맞는 최적의 온도**를 찾는 감각을 기를 수 있습니다. 다음 코드를 살펴봅시다. ```python from openai import OpenAI import json client = OpenAI() prompt = """ Python으로 문자열에서 가장 많이 등장하는 단어를 찾는 함수를 작성해주세요. 대소문자 구분 없이, 구두점은 제거하고 계산합니다. """ temperatures = [0.0, 0.5, 1.0, 1.5] results = {} for temp in temperatures: response = client.chat.completions.create( model="gpt-4", messages=[{"role": "user", "content": prompt}], temperature=temp, max_tokens=500 ) results[f"temp_{temp}"] = response.choices[0].message.content print(f"\n{'='*50}") print(f"온도: {temp}") print(f"{'='*50}") print(results[f"temp_{temp}"]) # 결과를 파일로 저장 with open("temperature_experiment.json", "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2) ``` 김개발 씨는 이제 본격적으로 실험을 시작합니다. 노트북을 열고 코드를 작성하기 시작했습니다. 목표는 명확합니다. 동일한 문제를 네 가지 다른 온도로 요청하고, 결과가 어떻게 달라지는지 비교하는 것입니다. 박시니어 씨가 옆에서 조언합니다. "온도 0.0은 가장 안전한 답을 줄 거야. 아마 교과서에 나올 법한 코드가 나올 거고. 온도를 높일수록 점점 더 독특한 접근법이 나올 거야." 실험 설계는 간단합니다. 먼저 **프롬프트를 고정**합니다. 문자열에서 가장 많이 등장하는 단어를 찾는 함수를 요청합니다. 이 문제는 여러 가지 방법으로 풀 수 있어서 온도의 영향을 확인하기 좋습니다. 딕셔너리를 쓸 수도 있고, Counter를 쓸 수도 있고, 정규식으로 처리할 수도 있습니다. 다음으로 **온도 배열을 준비**합니다. 0.0, 0.5, 1.0, 1.5 네 가지 값을 시험합니다. 0.0은 완전히 결정론적, 0.5는 약간의 변형, 1.0은 상당히 창의적, 1.5는 매우 모험적인 수준입니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 temperatures 리스트를 순회하는 반복문을 만듭니다. 각 온도마다 동일한 API 호출을 수행합니다. `max_tokens=500`으로 제한해서 너무 긴 설명은 받지 않습니다. 코드 자체에 집중하기 위함입니다. 응답을 받으면 results 딕셔너리에 온도별로 저장합니다. 키는 "temp_0.0" 같은 형식으로 만들어서 나중에 비교하기 쉽게 합니다. 그리고 즉시 화면에 출력해서 실시간으로 차이를 확인할 수 있게 합니다. 마지막으로 모든 결과를 JSON 파일로 저장합니다. 이렇게 하면 나중에 다시 분석하거나 팀원들과 공유할 때 편리합니다. 실험을 실행해보면 흥미로운 패턴이 나타납니다. **온도 0.0**에서는 아마도 `collections.Counter`를 사용한 간결한 코드가 나올 것입니다. 파이썬 표준 라이브러리에서 가장 널리 알려진 방법입니다. 매번 실행해도 거의 동일한 코드가 나옵니다. **온도 0.5**에서는 약간의 변형이 생깁니다. 어떨 때는 Counter를, 어떨 때는 딕셔너리를 직접 사용할 수 있습니다. 하지만 기본 구조는 비슷합니다. **온도 1.0**에서는 더 다양한 접근법이 등장합니다. 정규식으로 단어를 추출하거나, defaultdict를 쓰거나, sorted와 lambda를 조합하는 등 여러 방법을 시도합니다. **온도 1.5**에서는 예상치 못한 코드가 나올 수 있습니다. 함수형 프로그래밍 스타일이나 원라이너를 시도할 수도 있습니다. 때로는 지나치게 복잡하거나 비효율적인 코드가 나오기도 합니다. 김개발 씨가 실험 결과를 살펴봅니다. "와, 정말 다르네요! 온도 0.0은 항상 Counter를 쓰는데, 1.0은 매번 다른 방법을 시도하네요." 박시니어 씨가 고개를 끄덕입니다. "맞아. 그래서 용도에 맞게 온도를 선택하는 게 중요해. 회사 코드베이스에 통합할 거면 낮은 온도로, 새로운 아이디어를 얻고 싶으면 높은 온도로 설정하는 거지." 실무에서 이런 실험을 활용하는 방법은 다양합니다. **코드 리뷰 자동화**를 도입할 때는 먼저 여러 온도로 테스트해봅니다. 어느 온도가 가장 일관되고 유용한 피드백을 주는지 확인한 뒤, 그 설정을 표준으로 정합니다. **문서 자동 생성**에는 온도를 약간 높게 설정합니다. 같은 함수라도 다양한 표현으로 설명하면 개발자들이 이해하기 쉽습니다. **단위 테스트 생성**에는 온도를 중간 정도로 설정합니다. 엣지 케이스를 다양하게 커버하되, 너무 비현실적인 테스트는 피합니다. 하지만 주의할 점도 있습니다. 온도 1.5 이상은 **문법 오류 위험**이 높습니다. 실험 결과를 맹신하지 말고 반드시 실행해서 검증해야 합니다. 특히 프로덕션 환경에서는 절대 높은 온도를 사용하지 마세요. 또한 결과를 비교할 때는 **코드 품질도 함께 평가**해야 합니다. 창의적이지만 비효율적인 코드보다는, 평범하지만 견고한 코드가 나을 때가 많습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 실험을 마친 김개발 씨는 이제 자신만의 온도 설정 가이드를 만들었습니다. 버그 수정은 0.2, 새 기능 개발은 0.5, 프로토타입은 0.8로 설정하기로 했습니다. 직접 실험해보면 온도 파라미터를 체감할 수 있습니다. 여러분도 오늘 배운 코드를 실행해보고 결과를 비교해 보세요. **실전 팁** 💡 - 동일한 프롬프트로 온도만 바꿔 10번씩 실행해보면 패턴이 보입니다 - JSON으로 저장한 결과를 diff 도구로 비교하면 차이를 명확히 볼 수 있습니다 --- ## 6. 실습: 토큰 사용량 측정 도구 만들기 김개발 씨는 요즘 ChatGPT API를 자주 사용하는데, 어느 날 청구서를 보고 놀랐습니다. "이게 왜 이렇게 많이 나왔지?" 박시니어 씨가 물었습니다. "프롬프트마다 토큰을 몇 개나 썼는지 확인해봤어?" 토큰 사용량을 모니터링하지 않으면 비용이 눈덩이처럼 불어날 수 있습니다. 실무에서 AI API를 사용할 때는 **토큰 사용량을 추적**하는 것이 필수입니다. 이번 실습에서는 코드 입력을 받아 토큰 수를 계산하고, 예상 비용까지 산출하는 도구를 만듭니다. 프롬프트 최적화의 기초이며, API 비용 관리에 직접적으로 도움이 됩니다. 다음 코드를 살펴봅시다. ```python import tiktoken from dataclasses import dataclass @dataclass class TokenUsage: text: str token_count: int estimated_cost: float model: str class TokenCalculator: # GPT-4 가격 (2024년 기준, 실제 가격은 공식 사이트 확인) PRICING = { "gpt-4": {"input": 0.03, "output": 0.06}, # per 1K tokens "gpt-3.5-turbo": {"input": 0.0015, "output": 0.002} } def __init__(self, model="gpt-4"): self.model = model self.encoding = tiktoken.encoding_for_model(model) def calculate(self, text: str, is_output=False) -> TokenUsage: tokens = self.encoding.encode(text) token_count = len(tokens) price_type = "output" if is_output else "input" cost_per_1k = self.PRICING[self.model][price_type] estimated_cost = (token_count / 1000) * cost_per_1k return TokenUsage( text=text[:100] + "..." if len(text) > 100 else text, token_count=token_count, estimated_cost=estimated_cost, model=self.model ) def analyze_conversation(self, messages: list) -> dict: total_tokens = 0 total_cost = 0.0 details = [] for msg in messages: usage = self.calculate(msg["content"]) total_tokens += usage.token_count total_cost += usage.estimated_cost details.append(usage) return { "total_tokens": total_tokens, "total_cost": total_cost, "details": details } # 사용 예제 if __name__ == "__main__": calc = TokenCalculator("gpt-4") sample_code = """ def binary_search(arr, target): left, right = 0, len(arr) - 1 while left <= right: mid = (left + right) // 2 if arr[mid] == target: return mid elif arr[mid] < target: left = mid + 1 else: right = mid - 1 return -1 """ result = calc.calculate(sample_code) print(f"모델: {result.model}") print(f"토큰 수: {result.token_count}") print(f"예상 비용: ${result.estimated_cost:.6f}") ``` 김개발 씨는 지난달 API 비용이 예상보다 3배나 많이 나왔습니다. 원인을 파악하려고 했지만 어디서 토큰을 많이 썼는지 알 수가 없었습니다. 매번 호출할 때마다 로그를 남기지 않았기 때문입니다. 박시니어 씨가 조언했습니다. "토큰 계산기를 만들어서 호출 전에 미리 확인하는 습관을 들여봐. 그러면 불필요한 비용을 줄일 수 있어." 토큰 사용량을 추적하는 것이 왜 중요할까요? GPT-4는 입력 토큰당 약 0.03달러, 출력 토큰당 약 0.06달러를 청구합니다. 1,000 토큰이면 얼마 안 되는 것 같지만, 하루에 수백 번 호출하면 금액이 급격히 증가합니다. 특히 긴 컨텍스트를 계속 포함시키면 입력 토큰이 폭발적으로 늘어납니다. 실제로 어떤 스타트업은 토큰 관리를 소홀히 해서 한 달에 수천 달러를 낭비했습니다. 같은 문서를 매번 컨텍스트로 포함시켰는데, 캐싱을 사용했다면 비용을 80% 줄일 수 있었습니다. 바로 이런 문제를 예방하기 위해 **토큰 계산 도구**가 필요합니다. 토큰 계산 도구를 사용하면 API를 호출하기 전에 비용을 예측할 수 있습니다. 프롬프트가 너무 길면 요약하거나 불필요한 부분을 제거할 수 있습니다. 또한 여러 모델의 비용을 비교해서 최적의 선택을 할 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 `TokenUsage`라는 데이터 클래스를 정의합니다. 텍스트, 토큰 수, 예상 비용, 모델명을 담습니다. 이렇게 구조화하면 나중에 로그를 분석하기 쉽습니다. 다음으로 `TokenCalculator` 클래스를 만듭니다. 생성자에서 모델명을 받아 해당 모델의 토크나이저를 로드합니다. `PRICING` 딕셔너리에는 모델별 가격 정보를 저장합니다. 실제 사용 시에는 OpenAI 공식 사이트에서 최신 가격을 확인해야 합니다. `calculate` 메서드가 핵심입니다. 텍스트를 받아 토큰으로 인코딩하고 개수를 셉니다. 그리고 입력인지 출력인지에 따라 다른 가격을 적용해서 비용을 계산합니다. 결과를 `TokenUsage` 객체로 반환합니다. `analyze_conversation` 메서드는 대화 전체를 분석합니다. 메시지 리스트를 받아 각각의 토큰 수와 비용을 계산하고 합산합니다. 챗봇을 만들 때 유용합니다. 사용 예제를 보면 간단합니다. 이진 탐색 함수 코드를 샘플로 준비하고, `calculate`를 호출하면 토큰 수와 예상 비용이 나옵니다. 실행해보면 이 정도 길이의 코드가 몇 개의 토큰을 사용하는지 감이 옵니다. 실무에서는 어떻게 활용할까요? **API 래퍼 함수**를 만들 때 토큰 계산을 포함시킵니다. OpenAI API를 호출하기 전에 자동으로 토큰을 계산하고 로그에 기록합니다. 월말에 로그를 분석하면 어느 기능이 비용을 많이 쓰는지 파악할 수 있습니다. **프롬프트 최적화**에도 활용합니다. 동일한 결과를 내는 두 가지 프롬프트가 있다면, 토큰 수가 적은 쪽을 선택합니다. 예를 들어 "다음 코드를 설명해주세요"보다 "코드 설명:"이 더 짧고 토큰도 적게 씁니다. **예산 관리 시스템**에 통합할 수도 있습니다. 팀별로 월간 토큰 할당량을 정하고, 실시간으로 사용량을 추적합니다. 할당량에 가까워지면 경고를 보내 초과 비용을 방지합니다. 김개발 씨는 이제 모든 API 호출에 토큰 계산을 추가했습니다. 대시보드를 만들어 일일 토큰 사용량을 모니터링합니다. 어느 날 확인해보니 불필요하게 긴 시스템 프롬프트가 원인이었습니다. 이를 짧게 수정하자 월 비용이 40% 감소했습니다. 박시니어 씨가 칭찬했습니다. "잘했어. 토큰 관리를 제대로 하면 같은 예산으로 훨씬 많은 기능을 구현할 수 있어." 하지만 주의할 점도 있습니다. 토큰 가격은 **자주 변경**됩니다. OpenAI는 정기적으로 가격을 조정하므로, 코드에 하드코딩하지 말고 설정 파일로 분리하세요. 또한 프롬프트 캐싱이나 배치 API 같은 비용 절감 기능도 함께 고려해야 합니다. 토큰 수만 보지 말고 **응답 품질**도 함께 평가하세요. 프롬프트를 너무 짧게 만들면 토큰은 줄지만 품질이 떨어질 수 있습니다. 적절한 균형을 찾는 것이 중요합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 토큰 계산 도구를 만든 뒤, 김개발 씨는 API 비용을 완벽히 통제할 수 있게 되었습니다. 이제 예상치 못한 청구서를 받을 일이 없습니다. 토큰 사용량을 제대로 관리하면 AI를 비용 효율적으로 활용할 수 있습니다. 여러분도 오늘 배운 도구를 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - tiktoken을 프로젝트에 포함시켜 모든 API 호출 전에 토큰 수를 확인하세요 - 로그에 토큰 수와 비용을 함께 기록하면 나중에 최적화할 때 유용합니다 - 캐싱과 배치 API를 활용하면 동일한 작업을 더 저렴하게 처리할 수 있습니다 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: LLM,트랜스포머,토큰

언어: Python

태그: LLM, 트랜스포머, 토큰화, Self-Attention, 온도파라미터, LLM,트랜스포머,토큰

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

트랜스포머로 코드 이해하기 완벽 가이드

목차

1. 트랜스포머가 코드를 토큰화하는 방식

2. 코드 문법과 Self-Attention

3. 코드 컨텍스트 이해 능력

4. 온도 파라미터로 창의성 조절하기

5. 실습: 다양한 온도값으로 코드 생성 실험

6. 실습: 토큰 사용량 측정 도구 만들기

댓글 (0)

함께 보면 좋은 카드 뉴스

ReAct 패턴 마스터 완벽 가이드

AI 에이전트의 모든 것 - 개념부터 실습까지

프로덕션 RAG 시스템 완벽 가이드

RAG 캐싱 전략 완벽 가이드

실시간으로 답변하는 RAG 시스템 만들기