Amazon Titan 모델 완벽 가이드

AWS의 자체 개발 AI 모델 Amazon Titan의 텍스트 생성과 임베딩 기능을 실무 중심으로 학습합니다. Claude와의 비교를 통해 프로젝트에 맞는 모델 선택 방법을 알아봅니다.

1. Titan Text 모델 소개

김개발 씨는 회사에서 챗봇 프로젝트를 맡게 되었습니다. "AWS Bedrock에 Claude도 있고 Titan도 있던데, 뭐가 다른 거죠?" 선배 박시니어 씨가 웃으며 말했습니다.

"Titan은 AWS가 직접 만든 모델이에요. 한번 알아볼까요?"

Amazon Titan은 AWS가 자체 개발한 대규모 언어 모델입니다. 마치 구글이 Gemini를, OpenAI가 GPT를 만든 것처럼 AWS도 자신만의 AI 모델을 보유하고 있습니다.

Titan은 텍스트 생성과 텍스트 임베딩 두 가지 주요 기능을 제공합니다. AWS 서비스와의 긴밀한 통합이 가장 큰 장점입니다.

다음 코드를 살펴봅시다.

import boto3
import json

# Bedrock Runtime 클라이언트 생성
bedrock = boto3.client(
    service_name='bedrock-runtime',
    region_name='us-east-1'
)

# Titan Text Express 모델 호출
response = bedrock.invoke_model(
    modelId='amazon.titan-text-express-v1',
    body=json.dumps({
        "inputText": "AWS Lambda의 장점을 설명해주세요",
        "textGenerationConfig": {
            "maxTokenCount": 512,
            "temperature": 0.7
        }
    })
)

# 응답 파싱
result = json.loads(response['body'].read())
print(result['results'][0]['outputText'])

김개발 씨는 AWS 콘솔에서 Bedrock 서비스를 열어보았습니다. 모델 목록에 Claude, Llama와 함께 Titan이라는 이름이 보였습니다.

"이것도 AI 모델인가요?" 박시니어 씨가 고개를 끄덕였습니다. "맞아요.

AWS가 직접 만든 모델이죠." Amazon Titan 모델의 탄생 그렇다면 AWS는 왜 자체 AI 모델을 만들었을까요? 쉽게 비유하자면, Titan은 마치 삼성이 자체 개발한 엑시노스 프로세서와 같습니다.

다른 회사의 칩도 사용할 수 있지만, 자사의 하드웨어와 완벽하게 최적화된 칩을 직접 만드는 것입니다. 이처럼 AWS도 자사의 클라우드 인프라와 완벽하게 통합되는 AI 모델을 직접 개발했습니다.

다양한 모델을 제공하는 이유 Bedrock에는 여러 AI 모델이 있습니다. Claude, Llama, Jurassic 그리고 Titan까지.

"왜 이렇게 많은 모델을 제공하는 거죠?" 박시니어 씨가 설명했습니다. "각 모델마다 특징이 다르거든요.

Claude는 대화와 추론에 강하고, Llama는 오픈소스 기반이며, Titan은 AWS와의 통합이 장점이죠." 이것은 마치 공구 상자와 같습니다. 망치, 드라이버, 렌치가 모두 필요하듯이 프로젝트의 특성에 따라 적합한 AI 모델도 다릅니다.

Titan의 두 가지 얼굴 Titan은 크게 두 가지 버전으로 나뉩니다. 첫 번째는 Titan Text 모델입니다.

일반적인 텍스트 생성 작업을 처리합니다. 질문에 답하고, 문서를 요약하고, 콘텐츠를 생성하는 작업이죠.

두 번째는 Titan Embeddings 모델입니다. 텍스트를 숫자 벡터로 변환하는 특수한 작업을 담당합니다.

"임베딩이 뭐예요?" 김개발 씨가 물었습니다. "그건 나중에 자세히 배워볼게요.

일단은 텍스트를 검색 가능한 형태로 바꾸는 기술이라고 생각하면 됩니다." AWS 생태계와의 완벽한 조화 Titan의 가장 큰 장점은 무엇일까요? 바로 AWS 서비스와의 긴밀한 통합입니다.

Lambda 함수에서 직접 호출하고, S3에 저장된 데이터를 즉시 처리하며, CloudWatch로 모니터링하는 모든 과정이 끊김없이 이어집니다. 같은 회사에서 만든 서비스들이기 때문에 호환성 문제가 거의 없습니다.

"그럼 무조건 Titan을 쓰는 게 좋은 건가요?" 김개발 씨가 물었습니다. 모델 선택의 기준 박시니어 씨가 웃으며 대답했습니다.

"꼭 그렇지는 않아요. 상황에 따라 다르죠." 예를 들어 복잡한 추론이 필요한 고객 상담 챗봇이라면 Claude가 더 적합할 수 있습니다.

하지만 간단한 텍스트 분류나 요약 작업이고 AWS 서비스와 긴밀하게 통합해야 한다면 Titan이 더 나은 선택입니다. 비용 측면에서도 Titan이 상대적으로 저렴한 경우가 많습니다.

실무에서의 활용 많은 기업들이 Titan을 어떻게 사용하고 있을까요? 한 이커머스 회사는 Titan Text를 사용하여 상품 설명을 자동으로 생성합니다.

상품의 기본 정보를 입력하면 매력적인 소개 문구가 만들어집니다. 또 다른 회사는 고객 리뷰를 분석하고 감정을 파악하는 데 Titan을 활용합니다.

코드 살펴보기 위의 코드를 자세히 들여다봅시다. 먼저 boto3 라이브러리를 사용하여 Bedrock 클라이언트를 생성합니다.

이것은 AWS 서비스와 대화하는 통로입니다. 다음으로 invoke_model 메서드를 호출할 때 modelId로 사용할 모델을 지정합니다.

body 파라미터에는 실제 요청 내용이 들어갑니다. textGenerationConfig 안의 maxTokenCount는 최대 생성 토큰 수를, temperature는 창의성 정도를 조절합니다.

temperature가 높을수록 더 창의적이지만 예측 불가능한 결과가 나옵니다. 시작이 반이다 김개발 씨는 첫 번째 Titan 호출에 성공했습니다.

"생각보다 간단하네요!" 맞습니다. Titan을 시작하는 것은 어렵지 않습니다.

중요한 것은 각 모델의 특성을 이해하고 프로젝트에 맞게 선택하는 것입니다. 다음 카드에서는 Titan Text 모델을 더 깊이 파헤쳐 보겠습니다.

실전 팁

💡 - boto3 버전 확인: Bedrock을 사용하려면 boto3 버전이 1.28.57 이상이어야 합니다

리전 선택: Titan은 모든 리전에서 제공되지 않으므로 사용 가능한 리전을 먼저 확인하세요
IAM 권한 설정: bedrock:InvokeModel 권한이 필요하니 미리 설정해두세요

2. Titan 텍스트 생성 API

김개발 씨는 이제 Titan으로 실제 텍스트를 생성해보려 합니다. "파라미터가 꽤 많던데, 어떻게 조절해야 하나요?" 박시니어 씨가 노트북을 열며 말했습니다.

"하나씩 실험해보면서 감을 잡아야 해요."

Titan Text API는 다양한 파라미터를 통해 텍스트 생성을 세밀하게 제어할 수 있습니다. 마치 카메라의 조리개, 셔터 속도, ISO를 조절하여 원하는 사진을 찍는 것처럼 temperature, topP, stopSequences 같은 설정으로 원하는 텍스트를 만들어냅니다.

각 파라미터의 역할을 이해하면 훨씬 정확한 결과를 얻을 수 있습니다.

다음 코드를 살펴봅시다.

import boto3
import json

bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')

# 상세한 파라미터 설정
request_body = {
    "inputText": "Python 데코레이터에 대해 초보자도 이해할 수 있게 설명해주세요",
    "textGenerationConfig": {
        "maxTokenCount": 800,      # 최대 생성 토큰 수
        "temperature": 0.5,         # 창의성 (0~1, 낮을수록 일관적)
        "topP": 0.9,               # 다양성 제어 (0~1)
        "stopSequences": ["###"]   # 생성 중단 시퀀스
    }
}

response = bedrock.invoke_model(
    modelId='amazon.titan-text-express-v1',
    body=json.dumps(request_body)
)

result = json.loads(response['body'].read())
generated_text = result['results'][0]['outputText']
token_count = result['results'][0]['tokenCount']

print(f"생성된 텍스트: {generated_text}")
print(f"사용된 토큰: {token_count}")

박시니어 씨가 화면에 코드를 띄웠습니다. "파라미터를 하나씩 바꿔가며 결과를 비교해볼게요." 파라미터의 세계 AI 모델에게 텍스트 생성을 요청할 때는 단순히 질문만 던지는 것이 아닙니다.

어떤 스타일로, 얼마나 길게, 얼마나 창의적으로 답변할지 세세하게 지시할 수 있습니다. 이것은 마치 레스토랑에서 스테이크를 주문하는 것과 같습니다.

"스테이크 하나요"라고만 하는 것이 아니라 "미디움 레어로, 소금은 적게, 마늘 버터 소스 추가해주세요"처럼 구체적으로 주문하는 것이죠. maxTokenCount: 길이의 제한 첫 번째 파라미터는 maxTokenCount입니다.

"토큰이 정확히 뭐예요?" 김개발 씨가 물었습니다. 박시니어 씨가 설명했습니다.

"토큰은 텍스트의 작은 조각이에요. 대략 한글 1.5~2글자 정도가 하나의 토큰이죠." maxTokenCount를 800으로 설정하면 대략 1200자에서 1600자 정도의 텍스트가 생성됩니다.

이 값을 너무 작게 하면 답변이 중간에 잘리고, 너무 크게 하면 불필요하게 긴 답변이 나올 수 있습니다. 또한 토큰 수가 많을수록 비용도 증가합니다.

temperature: 창의성의 온도계 두 번째 파라미터는 temperature입니다. 이름이 참 독특하죠?

temperature는 0에서 1 사이의 값을 가집니다. 0에 가까울수록 모델은 가장 확률이 높은 단어만 선택합니다.

결과가 일관되고 예측 가능하지만 재미없을 수 있습니다. 반대로 1에 가까울수록 다양한 단어를 시도합니다.

창의적이지만 때로는 이상한 결과가 나올 수 있습니다. "사실을 정확하게 설명해야 하는 기술 문서에는 0.3~0.5 정도가 좋아요." 박시니어 씨가 조언했습니다.

"하지만 창의적인 마케팅 문구를 만든다면 0.7~0.9도 괜찮죠." topP: 선택의 폭 세 번째는 topP 파라미터입니다. 이것은 temperature와 함께 작동합니다.

topP는 누적 확률을 의미합니다. 예를 들어 topP를 0.9로 설정하면 확률이 높은 단어들을 누적하여 90%에 도달할 때까지만 선택 후보로 고려합니다.

나머지 10%의 확률을 가진 단어들은 아예 선택되지 않습니다. 이것은 마치 식당에서 인기 메뉴 상위 90%만 보여주는 것과 같습니다.

너무 마이너한 메뉴는 추천하지 않는 것이죠. stopSequences: 멈춤 신호 네 번째는 stopSequences입니다.

이것은 특정 문자열이 나타나면 생성을 즉시 중단하라는 신호입니다. 예를 들어 ["###"]로 설정하면 모델이 ###를 생성하는 순간 멈춥니다.

여러 개의 예시를 생성할 때 각 예시를 구분하는 용도로 유용합니다. "질의응답 챗봇을 만들 때 ["\n사용자:", "\nUser:"] 같은 것을 넣으면 좋아요." 박시니어 씨가 팁을 알려주었습니다.

"모델이 다음 사용자 발화까지 생성하는 것을 막을 수 있거든요." 실전 시나리오 실무에서는 어떻게 활용할까요? 한 온라인 교육 플랫폼에서는 Titan을 사용하여 강의 요약을 자동 생성합니다.

긴 강의 스크립트를 입력하면 핵심 내용만 추출합니다. 이때 temperature를 0.3으로 낮게 설정하여 일관되고 정확한 요약을 만듭니다.

maxTokenCount는 300으로 제한하여 간결하게 유지합니다. 또 다른 마케팅 회사에서는 SNS 게시글을 생성할 때 temperature를 0.8로 높게 설정합니다.

다양하고 창의적인 문구가 나오도록 유도하는 것이죠. 코드 분석 위의 코드를 다시 살펴봅시다.

request_body 딕셔너리에 모든 설정이 담겨 있습니다. inputText는 우리의 질문이고, textGenerationConfig 안에 세부 파라미터들이 들어갑니다.

응답에서는 outputText뿐만 아니라 tokenCount도 함께 반환됩니다. 이것으로 실제 사용한 토큰 수를 확인할 수 있습니다.

실험의 중요성 김개발 씨가 여러 파라미터 조합을 시도해보았습니다. "temperature를 0.2로 했더니 너무 딱딱하고, 0.9로 했더니 이상한 내용이 나오네요." 박시니어 씨가 고개를 끄덕였습니다.

"맞아요. 정답은 없어요.

프로젝트마다 최적의 값이 다르니까 직접 실험해봐야 합니다." 비용 고려 마지막으로 중요한 점이 있습니다. 생성된 토큰 수만큼 비용이 청구됩니다.

maxTokenCount를 지나치게 높게 설정하면 불필요한 비용이 발생할 수 있습니다. 실제로 필요한 만큼만 설정하는 것이 중요합니다.

실전 팁

💡 - A/B 테스트: temperature 값을 여러 개 시도해보고 결과를 비교하세요. 0.3, 0.5, 0.7을 테스트해보는 것이 좋습니다

토큰 계산기: Titan Express는 입력 토큰 $0.0008/1K, 출력 토큰 $0.0016/1K입니다. 비용 예측에 참고하세요
응답 파싱: result['results']는 리스트이므로 여러 개의 결과를 한 번에 생성할 수도 있습니다

3. Titan Embeddings 소개

점심시간에 김개발 씨가 물었습니다. "임베딩이 뭔지 아직도 잘 모르겠어요.

텍스트 생성이랑 뭐가 다른 거죠?" 박시니어 씨가 검색창을 열며 말했습니다. "구글에서 검색할 때 정확한 단어가 없어도 비슷한 결과가 나오잖아요?

그게 임베딩의 마법이에요."

임베딩은 텍스트를 숫자 벡터로 변환하는 기술입니다. 마치 지도에서 각 장소를 위도와 경도로 표현하듯이 단어와 문장을 수백 개의 숫자로 나타냅니다.

이렇게 변환하면 텍스트 간의 유사도를 계산할 수 있어 검색, 추천, 분류 작업이 가능해집니다. Titan Embeddings는 이러한 변환 작업을 전문적으로 수행하는 모델입니다.

다음 코드를 살펴봅시다.

import boto3
import json
import numpy as np

bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')

def get_embedding(text):
    """텍스트를 임베딩 벡터로 변환"""
    response = bedrock.invoke_model(
        modelId='amazon.titan-embed-text-v1',
        body=json.dumps({"inputText": text})
    )

    result = json.loads(response['body'].read())
    # 1536차원의 벡터가 반환됨
    return result['embedding']

# 두 문장의 임베딩 생성
text1 = "Python은 인기있는 프로그래밍 언어입니다"
text2 = "파이썬은 많은 개발자가 사용하는 언어입니다"

embedding1 = get_embedding(text1)
embedding2 = get_embedding(text2)

# 코사인 유사도 계산
similarity = np.dot(embedding1, embedding2) / (np.linalg.norm(embedding1) * np.linalg.norm(embedding2))
print(f"유사도: {similarity:.4f}")  # 0.95 이상의 높은 유사도

박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다. "임베딩을 이해하려면 좌표계를 생각하면 돼요." 좌표계로 이해하기 우리는 지도에서 위치를 위도와 경도 두 개의 숫자로 표현합니다.

서울은 (37.5665, 126.9780)이고 부산은 (35.1796, 129.0756)입니다. 이 숫자들로 두 도시가 얼마나 떨어져 있는지 계산할 수 있습니다.

임베딩도 정확히 같은 원리입니다. 다만 2차원이 아니라 1536차원 공간을 사용합니다.

"1536차원이요?" 김개발 씨가 놀랐습니다. "상상이 안 가는데요." 박시니어 씨가 웃었습니다.

"눈으로 볼 수는 없지만 컴퓨터는 이해할 수 있어요. 중요한 건 의미가 비슷한 텍스트는 이 공간에서 가까운 곳에 위치한다는 거예요." 의미의 거리 예를 들어봅시다.

"강아지"와 "개"라는 단어를 임베딩으로 변환하면 두 벡터는 매우 가까운 곳에 위치합니다. 의미가 거의 같으니까요.

하지만 "강아지"와 "우주선"을 변환하면 아주 먼 곳에 위치합니다. 관련이 없으니까요.

"그럼 '강아지'와 '고양이'는요?" 김개발 씨가 물었습니다. "둘 다 애완동물이니까 적당히 가까운 거리에 있겠죠.

'개'보다는 멀지만 '우주선'보다는 훨씬 가깝게요." 왜 임베딩이 필요한가 전통적인 검색 시스템은 어땠을까요? 단순히 키워드 매칭만 사용했습니다.

사용자가 "Python 배우기"를 검색하면 문서에 정확히 "Python"과 "배우기"가 포함된 것만 찾았습니다. "파이썬 학습"이라고 쓰인 문서는 찾지 못했죠.

같은 의미인데도 말입니다. 임베딩을 사용하면 이 문제가 해결됩니다.

"Python 배우기"와 "파이썬 학습"의 임베딩 벡터는 매우 가까운 위치에 있으므로 의미적으로 유사하다고 판단할 수 있습니다. Titan Embeddings의 특징 AWS의 Titan Embeddings 모델은 텍스트를 1536개의 실수로 이루어진 벡터로 변환합니다.

이 숫자들은 인간이 직접 해석할 수 없습니다. 123번째 차원이 무엇을 의미하는지 알 수 없습니다.

하지만 전체적으로는 텍스트의 의미를 정확하게 포착합니다. 이것은 딥러닝 모델이 수십억 개의 문장을 학습하면서 스스로 터득한 표현 방식입니다.

코사인 유사도 두 벡터가 얼마나 비슷한지 측정하는 방법이 코사인 유사도입니다. 이것은 두 벡터 사이의 각도를 계산합니다.

0도면 완전히 같은 방향이고 180도면 정반대 방향입니다. -1에서 1 사이의 값으로 표현되며, 1에 가까울수록 유사하다는 의미입니다.

위의 코드에서 "Python은 인기있는 프로그래밍 언어입니다"와 "파이썬은 많은 개발자가 사용하는 언어입니다"의 유사도를 계산하면 0.95 이상이 나옵니다. 거의 같은 의미라는 뜻이죠.

실무 활용 사례 한 고객 지원 시스템에서 임베딩을 활용합니다. 고객이 "비밀번호를 잊어버렸어요"라고 문의하면 시스템은 이 문장의 임베딩을 생성합니다.

그리고 FAQ 데이터베이스에 저장된 모든 질문의 임베딩과 비교합니다. "로그인 정보를 분실했습니다", "패스워드가 기억나지 않아요" 같은 유사한 질문을 찾아내 관련 답변을 제공합니다.

코드 살펴보기 코드는 매우 간단합니다. titan-embed-text-v1 모델을 호출하고 inputText를 전달하면 됩니다.

응답에서 embedding 필드에 1536개의 숫자가 담긴 리스트가 반환됩니다. numpy를 사용하여 두 벡터의 코사인 유사도를 계산할 수 있습니다.

벡터 데이터베이스 실전에서는 수천 수만 개의 문서를 임베딩으로 변환합니다. 이렇게 많은 벡터를 효율적으로 검색하려면 벡터 데이터베이스가 필요합니다.

Pinecone, Weaviate, OpenSearch 같은 도구들이 있습니다. 이들은 벡터 간 유사도 검색에 최적화되어 있어 밀리초 단위로 가장 유사한 문서를 찾아냅니다.

"임베딩이 이렇게 중요한 거였군요." 김개발 씨가 감탄했습니다. "현대 AI 시스템의 핵심이에요." 박시니어 씨가 답했습니다.

실전 팁

💡 - 배치 처리: 여러 텍스트를 한 번에 임베딩하려면 반복문보다 병렬 처리를 고려하세요

캐싱: 같은 텍스트는 항상 같은 임베딩을 생성하므로 결과를 캐싱하면 비용을 절감할 수 있습니다
정규화: 코사인 유사도 계산 전에 벡터를 정규화하면 더 정확한 결과를 얻을 수 있습니다

4. 임베딩 벡터 생성하기

김개발 씨는 회사의 내부 문서 검색 시스템을 만들기로 했습니다. "1000개가 넘는 기술 문서가 있는데 어떻게 시작해야 하나요?" 박시니어 씨가 터미널을 열며 말했습니다.

"먼저 모든 문서를 임베딩으로 변환하고 저장해야 해요. 그게 첫 단계죠."

실무에서 임베딩을 활용하려면 대량의 텍스트를 효율적으로 벡터로 변환하고 저장해야 합니다. 마치 도서관에서 모든 책에 색인을 만드는 것처럼 모든 문서에 임베딩을 생성합니다.

이후 사용자 질문이 들어오면 질문의 임베딩을 만들어 저장된 벡터들과 비교하여 가장 관련성 높은 문서를 찾습니다. 이것이 의미 기반 검색의 핵심입니다.

다음 코드를 살펴봅시다.

import boto3
import json
from typing import List

bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')

def create_embeddings_batch(texts: List[str]) -> List[List[float]]:
    """여러 텍스트를 임베딩으로 변환"""
    embeddings = []

    for text in texts:
        response = bedrock.invoke_model(
            modelId='amazon.titan-embed-text-v1',
            body=json.dumps({"inputText": text})
        )
        result = json.loads(response['body'].read())
        embeddings.append(result['embedding'])

    return embeddings

# 기술 문서 예시
documents = [
    "AWS Lambda는 서버리스 컴퓨팅 서비스입니다",
    "Docker는 컨테이너 기반 가상화 플랫폼입니다",
    "Kubernetes는 컨테이너 오케스트레이션 도구입니다",
    "API Gateway는 RESTful API를 관리하는 서비스입니다"
]

# 모든 문서의 임베딩 생성
doc_embeddings = create_embeddings_batch(documents)
print(f"생성된 임베딩 개수: {len(doc_embeddings)}")
print(f"각 임베딩 차원: {len(doc_embeddings[0])}")

# 사용자 질문 임베딩
query = "서버 없이 코드를 실행하는 방법"
query_embedding = create_embeddings_batch([query])[0]

박시니어 씨가 아키텍처를 그리기 시작했습니다. "의미 기반 검색은 크게 두 단계로 나뉘어요." 인덱싱 단계: 준비 작업 첫 번째 단계는 인덱싱입니다.

이것은 마치 책을 출판하기 전에 색인을 만드는 작업과 같습니다. 모든 문서를 한 번씩 읽으면서 임베딩 벡터를 생성하고 데이터베이스에 저장합니다.

이 작업은 시간이 걸리지만 한 번만 하면 됩니다. "1000개 문서면 얼마나 걸릴까요?" 김개발 씨가 물었습니다.

"문서 길이에 따라 다르지만 보통 몇 분 정도요. 병렬 처리하면 더 빠르겠죠." 검색 단계: 실시간 처리 두 번째 단계는 검색입니다.

사용자가 질문을 입력하면 그 질문의 임베딩을 실시간으로 생성합니다. 그리고 저장해둔 모든 문서 임베딩과 유사도를 계산하여 가장 높은 점수를 받은 문서를 반환합니다.

이 과정은 매우 빠릅니다. 밀리초 단위로 완료됩니다.

문서 청킹 실무에서는 문서가 매우 길 수 있습니다. "100페이지짜리 기술 문서를 통째로 임베딩하면 안 되나요?" 김개발 씨가 물었습니다.

박시니어 씨가 고개를 저었습니다. "안 좋아요.

너무 많은 정보가 하나의 벡터에 뭉개지면 정확도가 떨어져요." 대신 문서를 작은 조각으로 나눕니다. 이것을 청킹이라고 합니다.

보통 200~500 단어 정도의 단락으로 자릅니다. 각 청크마다 독립적인 임베딩을 생성합니다.

그러면 검색 시 문서 전체가 아니라 가장 관련성 높은 특정 단락을 정확히 찾아낼 수 있습니다. 코드 흐름 이해하기 위의 코드를 살펴봅시다.

create_embeddings_batch 함수는 여러 텍스트를 순회하며 각각의 임베딩을 생성합니다. 실전에서는 동시성을 고려하여 asyncio나 멀티스레딩을 사용할 수도 있습니다.

documents 리스트는 실제로는 데이터베이스나 파일에서 읽어올 것입니다. 각 문서의 임베딩을 생성한 후에는 이를 벡터 데이터베이스에 저장해야 합니다.

문서 ID와 임베딩 벡터를 함께 저장하여 나중에 검색 결과로 문서를 찾을 수 있게 합니다. 유사도 계산 사용자 질문 "서버 없이 코드를 실행하는 방법"의 임베딩을 생성했습니다.

이제 이것을 각 문서 임베딩과 비교합니다. "AWS Lambda는 서버리스 컴퓨팅 서비스입니다"라는 문서가 가장 높은 유사도를 기록할 것입니다.

Lambda와 서버리스라는 키워드가 직접 매칭되기 때문만이 아니라 의미적으로도 정확히 일치하기 때문입니다. 실전 시스템 아키텍처 한 스타트업의 실제 시스템을 살펴봅시다.

그들은 고객 지원 문서 5000개를 보유하고 있습니다. 매일 밤 자정에 Lambda 함수가 실행되어 새로 추가되거나 수정된 문서의 임베딩을 생성합니다.

이 임베딩들은 Amazon OpenSearch의 k-NN 인덱스에 저장됩니다. 낮에 고객이 검색하면 API Gateway를 통해 요청이 들어옵니다.

또 다른 Lambda 함수가 질문의 임베딩을 생성하고 OpenSearch에서 유사도 검색을 수행합니다. 상위 5개 문서를 반환하는 전체 과정이 200ms 이내에 완료됩니다.

비용 최적화 임베딩 생성에도 비용이 듭니다. Titan Embeddings는 입력 토큰당 $0.0001/1K입니다.

1000개 문서를 각각 500토큰씩 임베딩하면 500,000 토큰이므로 약 $0.05입니다. 저렴하지만 수백만 개 문서라면 고려해야 할 비용입니다.

중요한 것은 같은 텍스트는 항상 같은 임베딩을 생성한다는 점입니다. 따라서 한 번 생성한 임베딩은 문서가 수정되기 전까지 재사용할 수 있습니다.

정확도 향상 기법 단순히 임베딩 유사도만 사용하는 것보다 더 나은 방법이 있습니다. 하이브리드 검색을 사용하면 임베딩 기반 의미 검색과 전통적인 키워드 검색을 결합합니다.

두 방식의 점수를 가중 평균하여 최종 순위를 정합니다. 이렇게 하면 의미적 유사성과 정확한 키워드 매칭의 장점을 모두 취할 수 있습니다.

메타데이터 필터링도 유용합니다. 날짜, 카테고리, 작성자 같은 메타데이터로 먼저 필터링한 후 임베딩 검색을 수행하면 더 정확한 결과를 얻습니다.

김개발 씨가 직접 코드를 실행해보았습니다. "정말 잘 작동하네요!" 박시니어 씨가 미소지었습니다.

"이제 여러분의 프로젝트에도 의미 기반 검색을 추가할 수 있을 거예요."

실전 팁

💡 - 배치 크기: 한 번에 너무 많은 임베딩을 생성하면 메모리 문제가 발생할 수 있습니다. 100~500개씩 나눠서 처리하세요

오류 처리: 네트워크 오류에 대비해 재시도 로직을 추가하세요. boto3의 기본 재시도도 있지만 커스텀 로직이 더 안전합니다
진행 상황 표시: tqdm 라이브러리로 진행률을 보여주면 사용자 경험이 좋아집니다

5. Titan vs Claude 비교

회의 시간에 팀장님이 물었습니다. "Bedrock에 Claude도 있고 Titan도 있는데 뭘 써야 하죠?" 김개발 씨도 궁금했던 부분입니다.

박시니어 씨가 비교표를 띄우며 설명을 시작했습니다.

Titan과 Claude는 각각 장단점이 뚜렷합니다. Titan은 AWS와의 긴밀한 통합, 저렴한 비용, 빠른 응답 속도가 장점입니다.

Claude는 복잡한 추론, 긴 컨텍스트 처리, 높은 언어 이해력이 강점입니다. 프로젝트의 특성에 따라 적합한 모델을 선택하는 것이 중요합니다.

다음 코드를 살펴봅시다.

import boto3
import json
import time

bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')

def test_model(model_id, prompt):
    """모델 성능 테스트"""
    start_time = time.time()

    # Titan용 요청 형식
    if 'titan' in model_id:
        body = json.dumps({
            "inputText": prompt,
            "textGenerationConfig": {"maxTokenCount": 512}
        })
    # Claude용 요청 형식
    else:
        body = json.dumps({
            "anthropic_version": "bedrock-2023-05-31",
            "max_tokens": 512,
            "messages": [{"role": "user", "content": prompt}]
        })

    response = bedrock.invoke_model(modelId=model_id, body=body)
    elapsed = time.time() - start_time

    return elapsed

prompt = "Python 데코레이터를 초보자에게 설명해주세요"

titan_time = test_model('amazon.titan-text-express-v1', prompt)
claude_time = test_model('anthropic.claude-3-haiku-20240307-v1:0', prompt)

print(f"Titan 응답 시간: {titan_time:.2f}초")
print(f"Claude Haiku 응답 시간: {claude_time:.2f}초")

박시니어 씨가 두 모델의 특징을 하나씩 비교하기 시작했습니다. 응답 속도와 레이턴시 첫 번째 차이점은 속도입니다.

Titan Text Express는 이름에서 알 수 있듯이 빠른 응답에 최적화되어 있습니다. 간단한 질문에 대해 0.5~1초 내에 답변합니다.

Claude Haiku도 빠르지만 Titan이 약간 더 빠른 경우가 많습니다. Claude Sonnet이나 Opus는 더 느립니다.

"실시간 채팅처럼 응답이 빨라야 하는 서비스라면 Titan이 유리하겠네요." 김개발 씨가 말했습니다. 추론 능력과 복잡도 두 번째는 추론 능력입니다.

Claude는 복잡한 문제 해결에 강합니다. 여러 단계의 논리적 사고가 필요하거나 미묘한 뉘앙스를 파악해야 하는 작업에서 뛰어난 성능을 보입니다.

예를 들어 법률 문서 분석, 복잡한 코드 리뷰, 전략적 조언 같은 작업입니다. 반면 Titan은 상대적으로 단순한 작업에 적합합니다.

요약, 분류, 간단한 질의응답, 키워드 추출 같은 작업에서는 Titan으로도 충분히 좋은 결과를 얻을 수 있습니다. 컨텍스트 윈도우 크기 세 번째는 컨텍스트 크기입니다.

Claude 3 Sonnet과 Opus는 200K 토큰의 컨텍스트를 처리할 수 있습니다. 책 한 권 분량의 텍스트를 한 번에 입력할 수 있다는 뜻입니다.

Titan Text Express는 8K 토큰으로 제한됩니다. "긴 문서를 분석해야 한다면 Claude가 필수겠군요." 팀장님이 고개를 끄덕였습니다.

비용 구조 네 번째는 비용입니다. 이것은 매우 중요한 요소입니다.

Titan Text Express는 입력 토큰 $0.0008/1K, 출력 토큰 $0.0016/1K입니다. Claude 3 Haiku는 입력 $0.00025/1K, 출력 $0.00125/1K로 더 저렴합니다.

하지만 Claude Sonnet은 입력 $0.003/1K, 출력 $0.015/1K로 Titan보다 비쌉니다. "대량의 간단한 작업이라면 비용 차이가 크게 벌어지겠네요." 김개발 씨가 계산기를 두드렸습니다.

AWS 서비스 통합 다섯 번째는 AWS 통합입니다. Titan은 AWS의 자체 모델이므로 다른 AWS 서비스와의 통합이 매우 자연스럽습니다.

CloudWatch, Lambda, S3, DynamoDB와 함께 사용할 때 설정이 간단하고 레이턴시도 낮습니다. Claude도 Bedrock을 통해 통합되지만 Titan만큼 최적화되어 있지는 않습니다.

언어 지원 여섯 번째는 다국어 지원입니다. Claude는 한국어를 포함한 다양한 언어에서 뛰어난 성능을 보입니다.

자연스러운 한국어 생성과 미묘한 어감 파악에 강합니다. Titan도 한국어를 지원하지만 영어에 비해 품질이 다소 떨어질 수 있습니다.

실전 선택 시나리오 실무에서는 어떻게 선택할까요? Titan을 선택하는 경우: - 간단한 텍스트 분류나 요약 - 대량의 반복적인 작업 - 응답 속도가 중요한 실시간 시스템 - AWS 서비스와 긴밀한 통합 필요 - 비용 최적화가 중요 Claude를 선택하는 경우: - 복잡한 추론이나 분석 - 긴 문서 처리 - 자연스러운 대화가 중요 - 높은 언어 품질 요구 - 창의적인 콘텐츠 생성 하이브리드 접근 많은 기업들이 두 모델을 함께 사용합니다.

예를 들어 한 고객 상담 시스템에서는 첫 단계에서 Titan Embeddings로 관련 문서를 검색합니다. 그리고 찾은 문서를 바탕으로 Claude가 최종 답변을 생성합니다.

Titan의 빠른 검색과 Claude의 자연스러운 답변 생성을 결합한 것이죠. 벤치마크 결과 위의 코드를 실행해보면 실제 응답 시간을 측정할 수 있습니다.

보통 Titan Express는 0.8~~1.2초, Claude Haiku는 1.0~~1.5초 정도가 나옵니다. 네트워크 상황과 요청 복잡도에 따라 달라집니다.

직접 여러분의 환경에서 테스트해보는 것이 가장 정확합니다. 미래의 발전 AWS는 지속적으로 Titan 모델을 개선하고 있습니다.

최근에는 Titan Text Lite와 Premier 버전도 출시되었습니다. Lite는 더 빠르고 저렴하며, Premier는 더 강력한 성능을 제공합니다.

Anthropic도 Claude를 계속 발전시키고 있습니다. 앞으로도 두 모델의 경쟁은 계속될 것이고 개발자들에게는 더 나은 선택지가 생길 것입니다.

김개발 씨가 정리했습니다. "용도에 맞게 골라 쓰면 되겠네요!" 박시니어 씨가 웃으며 답했습니다.

"정확합니다. 만능 모델은 없어요.

상황에 맞는 최적의 선택이 있을 뿐이죠."

실전 팁

💡 - 프로토타입 단계: 개발 초기에는 Claude로 시작하여 기능을 검증하고, 나중에 비용 최적화가 필요하면 일부를 Titan으로 전환하세요

A/B 테스트: 두 모델의 결과를 실제 사용자에게 보여주고 만족도를 측정하는 것이 가장 확실한 선택 방법입니다
모델 버전: Bedrock에서는 모델 버전을 명시할 수 있습니다. 프로덕션에서는 특정 버전을 고정하여 예기치 않은 변경을 방지하세요

6. 용도별 모델 선택 가이드

프로젝트 킥오프 미팅에서 김개발 씨는 고민에 빠졌습니다. "우리 서비스는 고객 리뷰 분석도 하고 챗봇도 만들어야 하는데, 모델을 어떻게 선택하죠?" 박시니어 씨가 체크리스트를 꺼내며 말했습니다.

"구체적인 사용 사례별로 살펴보죠."

AI 모델 선택은 단순히 성능 비교가 아니라 비즈니스 요구사항을 정확히 파악하는 것에서 시작됩니다. 응답 시간, 비용, 정확도, 확장성 중 무엇이 가장 중요한지 결정해야 합니다.

각 사용 사례마다 최적의 모델과 설정이 다릅니다. 실무에서 자주 등장하는 시나리오별로 구체적인 선택 기준을 알아봅시다.

다음 코드를 살펴봅시다.

# 용도별 모델 선택 헬퍼 함수
def select_model(use_case, priority='balanced'):
    """
    use_case: 'search', 'chatbot', 'summarization', 'classification', 'generation'
    priority: 'speed', 'cost', 'quality', 'balanced'
    """
    recommendations = {
        'search': {
            'embedding': 'amazon.titan-embed-text-v1',
            'reranking': 'anthropic.claude-3-haiku-20240307-v1:0'
        },
        'chatbot': {
            'simple': 'amazon.titan-text-express-v1',
            'complex': 'anthropic.claude-3-sonnet-20240229-v1:0'
        },
        'summarization': {
            'speed': 'amazon.titan-text-express-v1',
            'quality': 'anthropic.claude-3-sonnet-20240229-v1:0'
        },
        'classification': 'amazon.titan-text-express-v1',
        'generation': 'anthropic.claude-3-sonnet-20240229-v1:0'
    }

    # 우선순위에 따른 추천
    if use_case in recommendations:
        if isinstance(recommendations[use_case], dict):
            return recommendations[use_case].get(priority, recommendations[use_case]['balanced'])
        return recommendations[use_case]

    return 'amazon.titan-text-express-v1'  # 기본값

# 사용 예시
print(f"검색 시스템: {select_model('search')}")
print(f"간단한 챗봇: {select_model('chatbot', 'simple')}")
print(f"품질 우선 요약: {select_model('summarization', 'quality')}")

박시니어 씨가 실제 프로젝트 사례들을 보여주기 시작했습니다. 사용 사례 1: 문서 검색 시스템 가장 흔한 사용 사례는 문서 검색입니다.

사내 위키, 고객 지원 문서, 제품 매뉴얼 등 방대한 텍스트 자료에서 원하는 정보를 빠르게 찾아야 합니다. 이 경우 Titan Embeddings가 최선의 선택입니다.

모든 문서를 벡터로 변환하여 저장하고, 검색 시 의미 기반 매칭을 수행합니다. "만약 검색 결과를 더 정교하게 순위 매기고 싶다면요?" 김개발 씨가 물었습니다.

"그럴 땐 Titan으로 후보를 찾고, Claude Haiku로 재순위를 매기는 2단계 접근을 쓸 수 있어요." 사용 사례 2: 고객 상담 챗봇 두 번째는 챗봇입니다. 하지만 챗봇도 종류가 다양합니다.

FAQ 챗봇처럼 정해진 답변을 반환하는 단순한 경우라면 Titan Text Express로 충분합니다. 질문을 분류하고 해당 답변을 찾는 정도의 작업이니까요.

하지만 복잡한 상황을 이해하고 맥락을 기억하며 섬세하게 대응해야 한다면 Claude Sonnet이 필요합니다. 한 보험 회사의 예를 봅시다.

단순 문의는 Titan으로 처리하고, 보험금 청구 같은 복잡한 케이스는 Claude로 에스컬레이션합니다. 비용 효율과 품질을 동시에 잡는 전략입니다.

사용 사례 3: 콘텐츠 요약 세 번째는 텍스트 요약입니다. 뉴스 기사, 고객 리뷰, 회의록을 자동으로 요약하는 작업이죠.

여기서는 원본 길이가 중요한 변수입니다. 짧은 텍스트(2000자 이하)를 빠르게 요약한다면 Titan이 적합합니다.

하지만 긴 보고서나 논문을 요약하면서 핵심 논리를 정확히 파악해야 한다면 Claude가 낫습니다. "우리 서비스는 고객 리뷰를 요약하는데, 보통 100~200자 정도예요." 김개발 씨가 말했습니다.

"그럼 Titan이 완벽하네요. 빠르고 저렴하니까요." 사용 사례 4: 텍스트 분류 네 번째는 분류 작업입니다.

이메일을 긴급/일반/스팸으로 분류하거나, 고객 문의를 부서별로 라우팅하거나, 상품 리뷰의 감정을 분석하는 작업입니다. 이런 경우 Titan Text Express가 최적입니다.

빠르고 저렴하며 정확도도 충분합니다. 프롬프트에 명확한 카테고리와 예시를 제공하면 매우 정확한 분류 결과를 얻을 수 있습니다.

하나의 요청으로 수백 건을 처리할 수 있어 대량 작업에 유리합니다. 사용 사례 5: 창의적 콘텐츠 생성 다섯 번째는 콘텐츠 생성입니다.

블로그 포스트, 마케팅 카피, 소셜 미디어 게시글처럼 창의적이고 매력적인 텍스트를 만들어야 한다면 Claude가 강력합니다. 자연스러운 문체, 적절한 비유, 매끄러운 흐름을 만들어냅니다.

Titan도 콘텐츠를 생성할 수 있지만 상대적으로 기계적이고 평범한 느낌이 들 수 있습니다. "사람이 쓴 것 같은 느낌이 중요하다면 Claude를 써야겠네요." 김개발 씨가 메모했습니다.

사용 사례 6: 데이터 추출 여섯 번째는 구조화된 데이터 추출입니다. 이메일에서 날짜, 금액, 이름을 추출하거나 영수증에서 항목을 파싱하는 작업입니다.

패턴이 명확하다면 Titan으로도 충분합니다. 하지만 복잡하고 비정형적인 문서라면 Claude의 추론 능력이 필요합니다.

한 핀테크 스타트업은 계약서에서 핵심 조항을 자동 추출하는데 Claude를 사용합니다. 법률 용어와 복잡한 문장 구조를 정확히 이해해야 하기 때문입니다.

의사결정 프레임워크 어떻게 결정을 내릴까요? 다음 질문들을 자신에게 던져보세요.

5. 품질: 최고 수준의 자연스러움이 필요한가? → Yes면 Claude

실전 팁

💡 - 비용 알림 설정: AWS Budgets으로 Bedrock 사용 비용 알림을 설정하여 예상치 못한 요금 폭탄을 예방하세요

폴백 전략: 주 모델이 실패하면 대체 모델로 자동 전환하는 로직을 구현하면 안정성이 높아집니다
캐싱 활용: 같은 질문이 반복되는 경우 결과를 캐싱하여 API 호출을 줄이세요. ElastiCache나 DynamoDB를 활용할 수 있습니다

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

#AWS#Titan#Bedrock#Embeddings#LLM

Amazon Titan 모델 완벽 가이드

# Amazon Titan 모델 완벽 가이드 AWS의 자체 개발 AI 모델 Amazon Titan의 텍스트 생성과 임베딩 기능을 실무 중심으로 학습합니다. Claude와의 비교를 통해 프로젝트에 맞는 모델 선택 방법을 알아봅니다. --- ## 목차 1. [Titan_Text_모델_소개](#titan-text-모델-소개) 2. [Titan_텍스트_생성_API](#titan-텍스트-생성-api) 3. [Titan_Embeddings_소개](#titan-embeddings-소개) 4. [임베딩_벡터_생성하기](#임베딩-벡터-생성하기) 5. [Titan_vs_Claude_비교](#titan-vs-claude-비교) 6. [용도별_모델_선택_가이드](#용도별-모델-선택-가이드) 5. [**품질**: 최고 수준의 자연스러움이 필요한가? → Yes면 Claude](#**품질**:-최고-수준의-자연스러움이-필요한가?-→-yes면-claude) --- ## 1. Titan_Text_모델_소개 김개발 씨는 회사에서 챗봇 프로젝트를 맡게 되었습니다. "AWS Bedrock에 Claude도 있고 Titan도 있던데, 뭐가 다른 거죠?" 선배 박시니어 씨가 웃으며 말했습니다. "Titan은 AWS가 직접 만든 모델이에요. 한번 알아볼까요?" **Amazon Titan**은 AWS가 자체 개발한 대규모 언어 모델입니다. 마치 구글이 Gemini를, OpenAI가 GPT를 만든 것처럼 AWS도 자신만의 AI 모델을 보유하고 있습니다. Titan은 텍스트 생성과 텍스트 임베딩 두 가지 주요 기능을 제공합니다. AWS 서비스와의 긴밀한 통합이 가장 큰 장점입니다. 다음 코드를 살펴봅시다. ```python import boto3 import json # Bedrock Runtime 클라이언트 생성 bedrock = boto3.client( service_name='bedrock-runtime', region_name='us-east-1' ) # Titan Text Express 모델 호출 response = bedrock.invoke_model( modelId='amazon.titan-text-express-v1', body=json.dumps({ "inputText": "AWS Lambda의 장점을 설명해주세요", "textGenerationConfig": { "maxTokenCount": 512, "temperature": 0.7 } }) ) # 응답 파싱 result = json.loads(response['body'].read()) print(result['results'][0]['outputText']) ``` 김개발 씨는 AWS 콘솔에서 Bedrock 서비스를 열어보았습니다. 모델 목록에 Claude, Llama와 함께 Titan이라는 이름이 보였습니다. "이것도 AI 모델인가요?" 박시니어 씨가 고개를 끄덕였습니다. "맞아요. AWS가 직접 만든 모델이죠." **Amazon Titan 모델의 탄생** 그렇다면 AWS는 왜 자체 AI 모델을 만들었을까요? 쉽게 비유하자면, Titan은 마치 삼성이 자체 개발한 엑시노스 프로세서와 같습니다. 다른 회사의 칩도 사용할 수 있지만, 자사의 하드웨어와 완벽하게 최적화된 칩을 직접 만드는 것입니다. 이처럼 AWS도 자사의 클라우드 인프라와 완벽하게 통합되는 AI 모델을 직접 개발했습니다. **다양한 모델을 제공하는 이유** Bedrock에는 여러 AI 모델이 있습니다. Claude, Llama, Jurassic 그리고 Titan까지. "왜 이렇게 많은 모델을 제공하는 거죠?" 박시니어 씨가 설명했습니다. "각 모델마다 특징이 다르거든요. Claude는 대화와 추론에 강하고, Llama는 오픈소스 기반이며, Titan은 AWS와의 통합이 장점이죠." 이것은 마치 공구 상자와 같습니다. 망치, 드라이버, 렌치가 모두 필요하듯이 프로젝트의 특성에 따라 적합한 AI 모델도 다릅니다. **Titan의 두 가지 얼굴** Titan은 크게 두 가지 버전으로 나뉩니다. 첫 번째는 **Titan Text** 모델입니다. 일반적인 텍스트 생성 작업을 처리합니다. 질문에 답하고, 문서를 요약하고, 콘텐츠를 생성하는 작업이죠. 두 번째는 **Titan Embeddings** 모델입니다. 텍스트를 숫자 벡터로 변환하는 특수한 작업을 담당합니다. "임베딩이 뭐예요?" 김개발 씨가 물었습니다. "그건 나중에 자세히 배워볼게요. 일단은 텍스트를 검색 가능한 형태로 바꾸는 기술이라고 생각하면 됩니다." **AWS 생태계와의 완벽한 조화** Titan의 가장 큰 장점은 무엇일까요? 바로 **AWS 서비스와의 긴밀한 통합**입니다. Lambda 함수에서 직접 호출하고, S3에 저장된 데이터를 즉시 처리하며, CloudWatch로 모니터링하는 모든 과정이 끊김없이 이어집니다. 같은 회사에서 만든 서비스들이기 때문에 호환성 문제가 거의 없습니다. "그럼 무조건 Titan을 쓰는 게 좋은 건가요?" 김개발 씨가 물었습니다. **모델 선택의 기준** 박시니어 씨가 웃으며 대답했습니다. "꼭 그렇지는 않아요. 상황에 따라 다르죠." 예를 들어 복잡한 추론이 필요한 고객 상담 챗봇이라면 Claude가 더 적합할 수 있습니다. 하지만 간단한 텍스트 분류나 요약 작업이고 AWS 서비스와 긴밀하게 통합해야 한다면 Titan이 더 나은 선택입니다. 비용 측면에서도 Titan이 상대적으로 저렴한 경우가 많습니다. **실무에서의 활용** 많은 기업들이 Titan을 어떻게 사용하고 있을까요? 한 이커머스 회사는 Titan Text를 사용하여 상품 설명을 자동으로 생성합니다. 상품의 기본 정보를 입력하면 매력적인 소개 문구가 만들어집니다. 또 다른 회사는 고객 리뷰를 분석하고 감정을 파악하는 데 Titan을 활용합니다. **코드 살펴보기** 위의 코드를 자세히 들여다봅시다. 먼저 boto3 라이브러리를 사용하여 Bedrock 클라이언트를 생성합니다. 이것은 AWS 서비스와 대화하는 통로입니다. 다음으로 invoke_model 메서드를 호출할 때 modelId로 사용할 모델을 지정합니다. body 파라미터에는 실제 요청 내용이 들어갑니다. textGenerationConfig 안의 maxTokenCount는 최대 생성 토큰 수를, temperature는 창의성 정도를 조절합니다. temperature가 높을수록 더 창의적이지만 예측 불가능한 결과가 나옵니다. **시작이 반이다** 김개발 씨는 첫 번째 Titan 호출에 성공했습니다. "생각보다 간단하네요!" 맞습니다. Titan을 시작하는 것은 어렵지 않습니다. 중요한 것은 각 모델의 특성을 이해하고 프로젝트에 맞게 선택하는 것입니다. 다음 카드에서는 Titan Text 모델을 더 깊이 파헤쳐 보겠습니다. **실전 팁** 💡 - **boto3 버전 확인**: Bedrock을 사용하려면 boto3 버전이 1.28.57 이상이어야 합니다 - **리전 선택**: Titan은 모든 리전에서 제공되지 않으므로 사용 가능한 리전을 먼저 확인하세요 - **IAM 권한 설정**: bedrock:InvokeModel 권한이 필요하니 미리 설정해두세요 --- ## 2. Titan_텍스트_생성_API 김개발 씨는 이제 Titan으로 실제 텍스트를 생성해보려 합니다. "파라미터가 꽤 많던데, 어떻게 조절해야 하나요?" 박시니어 씨가 노트북을 열며 말했습니다. "하나씩 실험해보면서 감을 잡아야 해요." **Titan Text API**는 다양한 파라미터를 통해 텍스트 생성을 세밀하게 제어할 수 있습니다. 마치 카메라의 조리개, 셔터 속도, ISO를 조절하여 원하는 사진을 찍는 것처럼 temperature, topP, stopSequences 같은 설정으로 원하는 텍스트를 만들어냅니다. 각 파라미터의 역할을 이해하면 훨씬 정확한 결과를 얻을 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 import json bedrock = boto3.client('bedrock-runtime', region_name='us-east-1') # 상세한 파라미터 설정 request_body = { "inputText": "Python 데코레이터에 대해 초보자도 이해할 수 있게 설명해주세요", "textGenerationConfig": { "maxTokenCount": 800, # 최대 생성 토큰 수 "temperature": 0.5, # 창의성 (0~1, 낮을수록 일관적) "topP": 0.9, # 다양성 제어 (0~1) "stopSequences": ["###"] # 생성 중단 시퀀스 } } response = bedrock.invoke_model( modelId='amazon.titan-text-express-v1', body=json.dumps(request_body) ) result = json.loads(response['body'].read()) generated_text = result['results'][0]['outputText'] token_count = result['results'][0]['tokenCount'] print(f"생성된 텍스트: {generated_text}") print(f"사용된 토큰: {token_count}") ``` 박시니어 씨가 화면에 코드를 띄웠습니다. "파라미터를 하나씩 바꿔가며 결과를 비교해볼게요." **파라미터의 세계** AI 모델에게 텍스트 생성을 요청할 때는 단순히 질문만 던지는 것이 아닙니다. 어떤 스타일로, 얼마나 길게, 얼마나 창의적으로 답변할지 세세하게 지시할 수 있습니다. 이것은 마치 레스토랑에서 스테이크를 주문하는 것과 같습니다. "스테이크 하나요"라고만 하는 것이 아니라 "미디움 레어로, 소금은 적게, 마늘 버터 소스 추가해주세요"처럼 구체적으로 주문하는 것이죠. **maxTokenCount: 길이의 제한** 첫 번째 파라미터는 **maxTokenCount**입니다. "토큰이 정확히 뭐예요?" 김개발 씨가 물었습니다. 박시니어 씨가 설명했습니다. "토큰은 텍스트의 작은 조각이에요. 대략 한글 1.5~2글자 정도가 하나의 토큰이죠." maxTokenCount를 800으로 설정하면 대략 1200자에서 1600자 정도의 텍스트가 생성됩니다. 이 값을 너무 작게 하면 답변이 중간에 잘리고, 너무 크게 하면 불필요하게 긴 답변이 나올 수 있습니다. 또한 토큰 수가 많을수록 비용도 증가합니다. **temperature: 창의성의 온도계** 두 번째 파라미터는 **temperature**입니다. 이름이 참 독특하죠? temperature는 0에서 1 사이의 값을 가집니다. 0에 가까울수록 모델은 가장 확률이 높은 단어만 선택합니다. 결과가 일관되고 예측 가능하지만 재미없을 수 있습니다. 반대로 1에 가까울수록 다양한 단어를 시도합니다. 창의적이지만 때로는 이상한 결과가 나올 수 있습니다. "사실을 정확하게 설명해야 하는 기술 문서에는 0.3~0.5 정도가 좋아요." 박시니어 씨가 조언했습니다. "하지만 창의적인 마케팅 문구를 만든다면 0.7~0.9도 괜찮죠." **topP: 선택의 폭** 세 번째는 **topP** 파라미터입니다. 이것은 temperature와 함께 작동합니다. topP는 누적 확률을 의미합니다. 예를 들어 topP를 0.9로 설정하면 확률이 높은 단어들을 누적하여 90%에 도달할 때까지만 선택 후보로 고려합니다. 나머지 10%의 확률을 가진 단어들은 아예 선택되지 않습니다. 이것은 마치 식당에서 인기 메뉴 상위 90%만 보여주는 것과 같습니다. 너무 마이너한 메뉴는 추천하지 않는 것이죠. **stopSequences: 멈춤 신호** 네 번째는 **stopSequences**입니다. 이것은 특정 문자열이 나타나면 생성을 즉시 중단하라는 신호입니다. 예를 들어 `["###"]`로 설정하면 모델이 ###를 생성하는 순간 멈춥니다. 여러 개의 예시를 생성할 때 각 예시를 구분하는 용도로 유용합니다. "질의응답 챗봇을 만들 때 `["\n사용자:", "\nUser:"]` 같은 것을 넣으면 좋아요." 박시니어 씨가 팁을 알려주었습니다. "모델이 다음 사용자 발화까지 생성하는 것을 막을 수 있거든요." **실전 시나리오** 실무에서는 어떻게 활용할까요? 한 온라인 교육 플랫폼에서는 Titan을 사용하여 강의 요약을 자동 생성합니다. 긴 강의 스크립트를 입력하면 핵심 내용만 추출합니다. 이때 temperature를 0.3으로 낮게 설정하여 일관되고 정확한 요약을 만듭니다. maxTokenCount는 300으로 제한하여 간결하게 유지합니다. 또 다른 마케팅 회사에서는 SNS 게시글을 생성할 때 temperature를 0.8로 높게 설정합니다. 다양하고 창의적인 문구가 나오도록 유도하는 것이죠. **코드 분석** 위의 코드를 다시 살펴봅시다. request_body 딕셔너리에 모든 설정이 담겨 있습니다. inputText는 우리의 질문이고, textGenerationConfig 안에 세부 파라미터들이 들어갑니다. 응답에서는 outputText뿐만 아니라 tokenCount도 함께 반환됩니다. 이것으로 실제 사용한 토큰 수를 확인할 수 있습니다. **실험의 중요성** 김개발 씨가 여러 파라미터 조합을 시도해보았습니다. "temperature를 0.2로 했더니 너무 딱딱하고, 0.9로 했더니 이상한 내용이 나오네요." 박시니어 씨가 고개를 끄덕였습니다. "맞아요. 정답은 없어요. 프로젝트마다 최적의 값이 다르니까 직접 실험해봐야 합니다." **비용 고려** 마지막으로 중요한 점이 있습니다. 생성된 토큰 수만큼 비용이 청구됩니다. maxTokenCount를 지나치게 높게 설정하면 불필요한 비용이 발생할 수 있습니다. 실제로 필요한 만큼만 설정하는 것이 중요합니다. **실전 팁** 💡 - **A/B 테스트**: temperature 값을 여러 개 시도해보고 결과를 비교하세요. 0.3, 0.5, 0.7을 테스트해보는 것이 좋습니다 - **토큰 계산기**: Titan Express는 입력 토큰 $0.0008/1K, 출력 토큰 $0.0016/1K입니다. 비용 예측에 참고하세요 - **응답 파싱**: result['results']는 리스트이므로 여러 개의 결과를 한 번에 생성할 수도 있습니다 --- ## 3. Titan_Embeddings_소개 점심시간에 김개발 씨가 물었습니다. "임베딩이 뭔지 아직도 잘 모르겠어요. 텍스트 생성이랑 뭐가 다른 거죠?" 박시니어 씨가 검색창을 열며 말했습니다. "구글에서 검색할 때 정확한 단어가 없어도 비슷한 결과가 나오잖아요? 그게 임베딩의 마법이에요." **임베딩**은 텍스트를 숫자 벡터로 변환하는 기술입니다. 마치 지도에서 각 장소를 위도와 경도로 표현하듯이 단어와 문장을 수백 개의 숫자로 나타냅니다. 이렇게 변환하면 텍스트 간의 유사도를 계산할 수 있어 검색, 추천, 분류 작업이 가능해집니다. **Titan Embeddings**는 이러한 변환 작업을 전문적으로 수행하는 모델입니다. 다음 코드를 살펴봅시다. ```python import boto3 import json import numpy as np bedrock = boto3.client('bedrock-runtime', region_name='us-east-1') def get_embedding(text): """텍스트를 임베딩 벡터로 변환""" response = bedrock.invoke_model( modelId='amazon.titan-embed-text-v1', body=json.dumps({"inputText": text}) ) result = json.loads(response['body'].read()) # 1536차원의 벡터가 반환됨 return result['embedding'] # 두 문장의 임베딩 생성 text1 = "Python은 인기있는 프로그래밍 언어입니다" text2 = "파이썬은 많은 개발자가 사용하는 언어입니다" embedding1 = get_embedding(text1) embedding2 = get_embedding(text2) # 코사인 유사도 계산 similarity = np.dot(embedding1, embedding2) / (np.linalg.norm(embedding1) * np.linalg.norm(embedding2)) print(f"유사도: {similarity:.4f}") # 0.95 이상의 높은 유사도 ``` 박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다. "임베딩을 이해하려면 좌표계를 생각하면 돼요." **좌표계로 이해하기** 우리는 지도에서 위치를 위도와 경도 두 개의 숫자로 표현합니다. 서울은 (37.5665, 126.9780)이고 부산은 (35.1796, 129.0756)입니다. 이 숫자들로 두 도시가 얼마나 떨어져 있는지 계산할 수 있습니다. 임베딩도 정확히 같은 원리입니다. 다만 2차원이 아니라 **1536차원** 공간을 사용합니다. "1536차원이요?" 김개발 씨가 놀랐습니다. "상상이 안 가는데요." 박시니어 씨가 웃었습니다. "눈으로 볼 수는 없지만 컴퓨터는 이해할 수 있어요. 중요한 건 의미가 비슷한 텍스트는 이 공간에서 가까운 곳에 위치한다는 거예요." **의미의 거리** 예를 들어봅시다. "강아지"와 "개"라는 단어를 임베딩으로 변환하면 두 벡터는 매우 가까운 곳에 위치합니다. 의미가 거의 같으니까요. 하지만 "강아지"와 "우주선"을 변환하면 아주 먼 곳에 위치합니다. 관련이 없으니까요. "그럼 '강아지'와 '고양이'는요?" 김개발 씨가 물었습니다. "둘 다 애완동물이니까 적당히 가까운 거리에 있겠죠. '개'보다는 멀지만 '우주선'보다는 훨씬 가깝게요." **왜 임베딩이 필요한가** 전통적인 검색 시스템은 어땠을까요? 단순히 키워드 매칭만 사용했습니다. 사용자가 "Python 배우기"를 검색하면 문서에 정확히 "Python"과 "배우기"가 포함된 것만 찾았습니다. "파이썬 학습"이라고 쓰인 문서는 찾지 못했죠. 같은 의미인데도 말입니다. 임베딩을 사용하면 이 문제가 해결됩니다. "Python 배우기"와 "파이썬 학습"의 임베딩 벡터는 매우 가까운 위치에 있으므로 의미적으로 유사하다고 판단할 수 있습니다. **Titan Embeddings의 특징** AWS의 Titan Embeddings 모델은 텍스트를 **1536개의 실수로 이루어진 벡터**로 변환합니다. 이 숫자들은 인간이 직접 해석할 수 없습니다. 123번째 차원이 무엇을 의미하는지 알 수 없습니다. 하지만 전체적으로는 텍스트의 의미를 정확하게 포착합니다. 이것은 딥러닝 모델이 수십억 개의 문장을 학습하면서 스스로 터득한 표현 방식입니다. **코사인 유사도** 두 벡터가 얼마나 비슷한지 측정하는 방법이 **코사인 유사도**입니다. 이것은 두 벡터 사이의 각도를 계산합니다. 0도면 완전히 같은 방향이고 180도면 정반대 방향입니다. -1에서 1 사이의 값으로 표현되며, 1에 가까울수록 유사하다는 의미입니다. 위의 코드에서 "Python은 인기있는 프로그래밍 언어입니다"와 "파이썬은 많은 개발자가 사용하는 언어입니다"의 유사도를 계산하면 0.95 이상이 나옵니다. 거의 같은 의미라는 뜻이죠. **실무 활용 사례** 한 고객 지원 시스템에서 임베딩을 활용합니다. 고객이 "비밀번호를 잊어버렸어요"라고 문의하면 시스템은 이 문장의 임베딩을 생성합니다. 그리고 FAQ 데이터베이스에 저장된 모든 질문의 임베딩과 비교합니다. "로그인 정보를 분실했습니다", "패스워드가 기억나지 않아요" 같은 유사한 질문을 찾아내 관련 답변을 제공합니다. **코드 살펴보기** 코드는 매우 간단합니다. titan-embed-text-v1 모델을 호출하고 inputText를 전달하면 됩니다. 응답에서 embedding 필드에 1536개의 숫자가 담긴 리스트가 반환됩니다. numpy를 사용하여 두 벡터의 코사인 유사도를 계산할 수 있습니다. **벡터 데이터베이스** 실전에서는 수천 수만 개의 문서를 임베딩으로 변환합니다. 이렇게 많은 벡터를 효율적으로 검색하려면 **벡터 데이터베이스**가 필요합니다. Pinecone, Weaviate, OpenSearch 같은 도구들이 있습니다. 이들은 벡터 간 유사도 검색에 최적화되어 있어 밀리초 단위로 가장 유사한 문서를 찾아냅니다. "임베딩이 이렇게 중요한 거였군요." 김개발 씨가 감탄했습니다. "현대 AI 시스템의 핵심이에요." 박시니어 씨가 답했습니다. **실전 팁** 💡 - **배치 처리**: 여러 텍스트를 한 번에 임베딩하려면 반복문보다 병렬 처리를 고려하세요 - **캐싱**: 같은 텍스트는 항상 같은 임베딩을 생성하므로 결과를 캐싱하면 비용을 절감할 수 있습니다 - **정규화**: 코사인 유사도 계산 전에 벡터를 정규화하면 더 정확한 결과를 얻을 수 있습니다 --- ## 4. 임베딩_벡터_생성하기 김개발 씨는 회사의 내부 문서 검색 시스템을 만들기로 했습니다. "1000개가 넘는 기술 문서가 있는데 어떻게 시작해야 하나요?" 박시니어 씨가 터미널을 열며 말했습니다. "먼저 모든 문서를 임베딩으로 변환하고 저장해야 해요. 그게 첫 단계죠." 실무에서 임베딩을 활용하려면 대량의 텍스트를 효율적으로 벡터로 변환하고 저장해야 합니다. 마치 도서관에서 모든 책에 색인을 만드는 것처럼 모든 문서에 임베딩을 생성합니다. 이후 사용자 질문이 들어오면 질문의 임베딩을 만들어 저장된 벡터들과 비교하여 가장 관련성 높은 문서를 찾습니다. 이것이 **의미 기반 검색**의 핵심입니다. 다음 코드를 살펴봅시다. ```python import boto3 import json from typing import List bedrock = boto3.client('bedrock-runtime', region_name='us-east-1') def create_embeddings_batch(texts: List[str]) -> List[List[float]]: """여러 텍스트를 임베딩으로 변환""" embeddings = [] for text in texts: response = bedrock.invoke_model( modelId='amazon.titan-embed-text-v1', body=json.dumps({"inputText": text}) ) result = json.loads(response['body'].read()) embeddings.append(result['embedding']) return embeddings # 기술 문서 예시 documents = [ "AWS Lambda는 서버리스 컴퓨팅 서비스입니다", "Docker는 컨테이너 기반 가상화 플랫폼입니다", "Kubernetes는 컨테이너 오케스트레이션 도구입니다", "API Gateway는 RESTful API를 관리하는 서비스입니다" ] # 모든 문서의 임베딩 생성 doc_embeddings = create_embeddings_batch(documents) print(f"생성된 임베딩 개수: {len(doc_embeddings)}") print(f"각 임베딩 차원: {len(doc_embeddings[0])}") # 사용자 질문 임베딩 query = "서버 없이 코드를 실행하는 방법" query_embedding = create_embeddings_batch([query])[0] ``` 박시니어 씨가 아키텍처를 그리기 시작했습니다. "의미 기반 검색은 크게 두 단계로 나뉘어요." **인덱싱 단계: 준비 작업** 첫 번째 단계는 **인덱싱**입니다. 이것은 마치 책을 출판하기 전에 색인을 만드는 작업과 같습니다. 모든 문서를 한 번씩 읽으면서 임베딩 벡터를 생성하고 데이터베이스에 저장합니다. 이 작업은 시간이 걸리지만 한 번만 하면 됩니다. "1000개 문서면 얼마나 걸릴까요?" 김개발 씨가 물었습니다. "문서 길이에 따라 다르지만 보통 몇 분 정도요. 병렬 처리하면 더 빠르겠죠." **검색 단계: 실시간 처리** 두 번째 단계는 **검색**입니다. 사용자가 질문을 입력하면 그 질문의 임베딩을 실시간으로 생성합니다. 그리고 저장해둔 모든 문서 임베딩과 유사도를 계산하여 가장 높은 점수를 받은 문서를 반환합니다. 이 과정은 매우 빠릅니다. 밀리초 단위로 완료됩니다. **문서 청킹** 실무에서는 문서가 매우 길 수 있습니다. "100페이지짜리 기술 문서를 통째로 임베딩하면 안 되나요?" 김개발 씨가 물었습니다. 박시니어 씨가 고개를 저었습니다. "안 좋아요. 너무 많은 정보가 하나의 벡터에 뭉개지면 정확도가 떨어져요." 대신 문서를 작은 조각으로 나눕니다. 이것을 **청킹**이라고 합니다. 보통 200~500 단어 정도의 단락으로 자릅니다. 각 청크마다 독립적인 임베딩을 생성합니다. 그러면 검색 시 문서 전체가 아니라 가장 관련성 높은 특정 단락을 정확히 찾아낼 수 있습니다. **코드 흐름 이해하기** 위의 코드를 살펴봅시다. create_embeddings_batch 함수는 여러 텍스트를 순회하며 각각의 임베딩을 생성합니다. 실전에서는 동시성을 고려하여 asyncio나 멀티스레딩을 사용할 수도 있습니다. documents 리스트는 실제로는 데이터베이스나 파일에서 읽어올 것입니다. 각 문서의 임베딩을 생성한 후에는 이를 벡터 데이터베이스에 저장해야 합니다. 문서 ID와 임베딩 벡터를 함께 저장하여 나중에 검색 결과로 문서를 찾을 수 있게 합니다. **유사도 계산** 사용자 질문 "서버 없이 코드를 실행하는 방법"의 임베딩을 생성했습니다. 이제 이것을 각 문서 임베딩과 비교합니다. "AWS Lambda는 서버리스 컴퓨팅 서비스입니다"라는 문서가 가장 높은 유사도를 기록할 것입니다. Lambda와 서버리스라는 키워드가 직접 매칭되기 때문만이 아니라 의미적으로도 정확히 일치하기 때문입니다. **실전 시스템 아키텍처** 한 스타트업의 실제 시스템을 살펴봅시다. 그들은 고객 지원 문서 5000개를 보유하고 있습니다. 매일 밤 자정에 Lambda 함수가 실행되어 새로 추가되거나 수정된 문서의 임베딩을 생성합니다. 이 임베딩들은 Amazon OpenSearch의 k-NN 인덱스에 저장됩니다. 낮에 고객이 검색하면 API Gateway를 통해 요청이 들어옵니다. 또 다른 Lambda 함수가 질문의 임베딩을 생성하고 OpenSearch에서 유사도 검색을 수행합니다. 상위 5개 문서를 반환하는 전체 과정이 200ms 이내에 완료됩니다. **비용 최적화** 임베딩 생성에도 비용이 듭니다. Titan Embeddings는 입력 토큰당 $0.0001/1K입니다. 1000개 문서를 각각 500토큰씩 임베딩하면 500,000 토큰이므로 약 $0.05입니다. 저렴하지만 수백만 개 문서라면 고려해야 할 비용입니다. 중요한 것은 같은 텍스트는 항상 같은 임베딩을 생성한다는 점입니다. 따라서 한 번 생성한 임베딩은 문서가 수정되기 전까지 재사용할 수 있습니다. **정확도 향상 기법** 단순히 임베딩 유사도만 사용하는 것보다 더 나은 방법이 있습니다. **하이브리드 검색**을 사용하면 임베딩 기반 의미 검색과 전통적인 키워드 검색을 결합합니다. 두 방식의 점수를 가중 평균하여 최종 순위를 정합니다. 이렇게 하면 의미적 유사성과 정확한 키워드 매칭의 장점을 모두 취할 수 있습니다. **메타데이터 필터링**도 유용합니다. 날짜, 카테고리, 작성자 같은 메타데이터로 먼저 필터링한 후 임베딩 검색을 수행하면 더 정확한 결과를 얻습니다. 김개발 씨가 직접 코드를 실행해보았습니다. "정말 잘 작동하네요!" 박시니어 씨가 미소지었습니다. "이제 여러분의 프로젝트에도 의미 기반 검색을 추가할 수 있을 거예요." **실전 팁** 💡 - **배치 크기**: 한 번에 너무 많은 임베딩을 생성하면 메모리 문제가 발생할 수 있습니다. 100~500개씩 나눠서 처리하세요 - **오류 처리**: 네트워크 오류에 대비해 재시도 로직을 추가하세요. boto3의 기본 재시도도 있지만 커스텀 로직이 더 안전합니다 - **진행 상황 표시**: tqdm 라이브러리로 진행률을 보여주면 사용자 경험이 좋아집니다 --- ## 5. Titan_vs_Claude_비교 회의 시간에 팀장님이 물었습니다. "Bedrock에 Claude도 있고 Titan도 있는데 뭘 써야 하죠?" 김개발 씨도 궁금했던 부분입니다. 박시니어 씨가 비교표를 띄우며 설명을 시작했습니다. **Titan**과 **Claude**는 각각 장단점이 뚜렷합니다. Titan은 AWS와의 긴밀한 통합, 저렴한 비용, 빠른 응답 속도가 장점입니다. Claude는 복잡한 추론, 긴 컨텍스트 처리, 높은 언어 이해력이 강점입니다. 프로젝트의 특성에 따라 적합한 모델을 선택하는 것이 중요합니다. 다음 코드를 살펴봅시다. ```python import boto3 import json import time bedrock = boto3.client('bedrock-runtime', region_name='us-east-1') def test_model(model_id, prompt): """모델 성능 테스트""" start_time = time.time() # Titan용 요청 형식 if 'titan' in model_id: body = json.dumps({ "inputText": prompt, "textGenerationConfig": {"maxTokenCount": 512} }) # Claude용 요청 형식 else: body = json.dumps({ "anthropic_version": "bedrock-2023-05-31", "max_tokens": 512, "messages": [{"role": "user", "content": prompt}] }) response = bedrock.invoke_model(modelId=model_id, body=body) elapsed = time.time() - start_time return elapsed prompt = "Python 데코레이터를 초보자에게 설명해주세요" titan_time = test_model('amazon.titan-text-express-v1', prompt) claude_time = test_model('anthropic.claude-3-haiku-20240307-v1:0', prompt) print(f"Titan 응답 시간: {titan_time:.2f}초") print(f"Claude Haiku 응답 시간: {claude_time:.2f}초") ``` 박시니어 씨가 두 모델의 특징을 하나씩 비교하기 시작했습니다. **응답 속도와 레이턴시** 첫 번째 차이점은 **속도**입니다. Titan Text Express는 이름에서 알 수 있듯이 빠른 응답에 최적화되어 있습니다. 간단한 질문에 대해 0.5~1초 내에 답변합니다. Claude Haiku도 빠르지만 Titan이 약간 더 빠른 경우가 많습니다. Claude Sonnet이나 Opus는 더 느립니다. "실시간 채팅처럼 응답이 빨라야 하는 서비스라면 Titan이 유리하겠네요." 김개발 씨가 말했습니다. **추론 능력과 복잡도** 두 번째는 **추론 능력**입니다. Claude는 복잡한 문제 해결에 강합니다. 여러 단계의 논리적 사고가 필요하거나 미묘한 뉘앙스를 파악해야 하는 작업에서 뛰어난 성능을 보입니다. 예를 들어 법률 문서 분석, 복잡한 코드 리뷰, 전략적 조언 같은 작업입니다. 반면 Titan은 상대적으로 단순한 작업에 적합합니다. 요약, 분류, 간단한 질의응답, 키워드 추출 같은 작업에서는 Titan으로도 충분히 좋은 결과를 얻을 수 있습니다. **컨텍스트 윈도우 크기** 세 번째는 **컨텍스트 크기**입니다. Claude 3 Sonnet과 Opus는 200K 토큰의 컨텍스트를 처리할 수 있습니다. 책 한 권 분량의 텍스트를 한 번에 입력할 수 있다는 뜻입니다. Titan Text Express는 8K 토큰으로 제한됩니다. "긴 문서를 분석해야 한다면 Claude가 필수겠군요." 팀장님이 고개를 끄덕였습니다. **비용 구조** 네 번째는 **비용**입니다. 이것은 매우 중요한 요소입니다. Titan Text Express는 입력 토큰 $0.0008/1K, 출력 토큰 $0.0016/1K입니다. Claude 3 Haiku는 입력 $0.00025/1K, 출력 $0.00125/1K로 더 저렴합니다. 하지만 Claude Sonnet은 입력 $0.003/1K, 출력 $0.015/1K로 Titan보다 비쌉니다. "대량의 간단한 작업이라면 비용 차이가 크게 벌어지겠네요." 김개발 씨가 계산기를 두드렸습니다. **AWS 서비스 통합** 다섯 번째는 **AWS 통합**입니다. Titan은 AWS의 자체 모델이므로 다른 AWS 서비스와의 통합이 매우 자연스럽습니다. CloudWatch, Lambda, S3, DynamoDB와 함께 사용할 때 설정이 간단하고 레이턴시도 낮습니다. Claude도 Bedrock을 통해 통합되지만 Titan만큼 최적화되어 있지는 않습니다. **언어 지원** 여섯 번째는 **다국어 지원**입니다. Claude는 한국어를 포함한 다양한 언어에서 뛰어난 성능을 보입니다. 자연스러운 한국어 생성과 미묘한 어감 파악에 강합니다. Titan도 한국어를 지원하지만 영어에 비해 품질이 다소 떨어질 수 있습니다. **실전 선택 시나리오** 실무에서는 어떻게 선택할까요? **Titan을 선택하는 경우:** - 간단한 텍스트 분류나 요약 - 대량의 반복적인 작업 - 응답 속도가 중요한 실시간 시스템 - AWS 서비스와 긴밀한 통합 필요 - 비용 최적화가 중요 **Claude를 선택하는 경우:** - 복잡한 추론이나 분석 - 긴 문서 처리 - 자연스러운 대화가 중요 - 높은 언어 품질 요구 - 창의적인 콘텐츠 생성 **하이브리드 접근** 많은 기업들이 두 모델을 함께 사용합니다. 예를 들어 한 고객 상담 시스템에서는 첫 단계에서 Titan Embeddings로 관련 문서를 검색합니다. 그리고 찾은 문서를 바탕으로 Claude가 최종 답변을 생성합니다. Titan의 빠른 검색과 Claude의 자연스러운 답변 생성을 결합한 것이죠. **벤치마크 결과** 위의 코드를 실행해보면 실제 응답 시간을 측정할 수 있습니다. 보통 Titan Express는 0.8~1.2초, Claude Haiku는 1.0~1.5초 정도가 나옵니다. 네트워크 상황과 요청 복잡도에 따라 달라집니다. 직접 여러분의 환경에서 테스트해보는 것이 가장 정확합니다. **미래의 발전** AWS는 지속적으로 Titan 모델을 개선하고 있습니다. 최근에는 Titan Text Lite와 Premier 버전도 출시되었습니다. Lite는 더 빠르고 저렴하며, Premier는 더 강력한 성능을 제공합니다. Anthropic도 Claude를 계속 발전시키고 있습니다. 앞으로도 두 모델의 경쟁은 계속될 것이고 개발자들에게는 더 나은 선택지가 생길 것입니다. 김개발 씨가 정리했습니다. "용도에 맞게 골라 쓰면 되겠네요!" 박시니어 씨가 웃으며 답했습니다. "정확합니다. 만능 모델은 없어요. 상황에 맞는 최적의 선택이 있을 뿐이죠." **실전 팁** 💡 - **프로토타입 단계**: 개발 초기에는 Claude로 시작하여 기능을 검증하고, 나중에 비용 최적화가 필요하면 일부를 Titan으로 전환하세요 - **A/B 테스트**: 두 모델의 결과를 실제 사용자에게 보여주고 만족도를 측정하는 것이 가장 확실한 선택 방법입니다 - **모델 버전**: Bedrock에서는 모델 버전을 명시할 수 있습니다. 프로덕션에서는 특정 버전을 고정하여 예기치 않은 변경을 방지하세요 --- ## 6. 용도별_모델_선택_가이드 프로젝트 킥오프 미팅에서 김개발 씨는 고민에 빠졌습니다. "우리 서비스는 고객 리뷰 분석도 하고 챗봇도 만들어야 하는데, 모델을 어떻게 선택하죠?" 박시니어 씨가 체크리스트를 꺼내며 말했습니다. "구체적인 사용 사례별로 살펴보죠." AI 모델 선택은 단순히 성능 비교가 아니라 **비즈니스 요구사항**을 정확히 파악하는 것에서 시작됩니다. 응답 시간, 비용, 정확도, 확장성 중 무엇이 가장 중요한지 결정해야 합니다. 각 사용 사례마다 최적의 모델과 설정이 다릅니다. 실무에서 자주 등장하는 시나리오별로 구체적인 선택 기준을 알아봅시다. 다음 코드를 살펴봅시다. ```python # 용도별 모델 선택 헬퍼 함수 def select_model(use_case, priority='balanced'): """ use_case: 'search', 'chatbot', 'summarization', 'classification', 'generation' priority: 'speed', 'cost', 'quality', 'balanced' """ recommendations = { 'search': { 'embedding': 'amazon.titan-embed-text-v1', 'reranking': 'anthropic.claude-3-haiku-20240307-v1:0' }, 'chatbot': { 'simple': 'amazon.titan-text-express-v1', 'complex': 'anthropic.claude-3-sonnet-20240229-v1:0' }, 'summarization': { 'speed': 'amazon.titan-text-express-v1', 'quality': 'anthropic.claude-3-sonnet-20240229-v1:0' }, 'classification': 'amazon.titan-text-express-v1', 'generation': 'anthropic.claude-3-sonnet-20240229-v1:0' } # 우선순위에 따른 추천 if use_case in recommendations: if isinstance(recommendations[use_case], dict): return recommendations[use_case].get(priority, recommendations[use_case]['balanced']) return recommendations[use_case] return 'amazon.titan-text-express-v1' # 기본값 # 사용 예시 print(f"검색 시스템: {select_model('search')}") print(f"간단한 챗봇: {select_model('chatbot', 'simple')}") print(f"품질 우선 요약: {select_model('summarization', 'quality')}") ``` 박시니어 씨가 실제 프로젝트 사례들을 보여주기 시작했습니다. **사용 사례 1: 문서 검색 시스템** 가장 흔한 사용 사례는 **문서 검색**입니다. 사내 위키, 고객 지원 문서, 제품 매뉴얼 등 방대한 텍스트 자료에서 원하는 정보를 빠르게 찾아야 합니다. 이 경우 **Titan Embeddings**가 최선의 선택입니다. 모든 문서를 벡터로 변환하여 저장하고, 검색 시 의미 기반 매칭을 수행합니다. "만약 검색 결과를 더 정교하게 순위 매기고 싶다면요?" 김개발 씨가 물었습니다. "그럴 땐 Titan으로 후보를 찾고, Claude Haiku로 재순위를 매기는 2단계 접근을 쓸 수 있어요." **사용 사례 2: 고객 상담 챗봇** 두 번째는 **챗봇**입니다. 하지만 챗봇도 종류가 다양합니다. FAQ 챗봇처럼 정해진 답변을 반환하는 단순한 경우라면 **Titan Text Express**로 충분합니다. 질문을 분류하고 해당 답변을 찾는 정도의 작업이니까요. 하지만 복잡한 상황을 이해하고 맥락을 기억하며 섬세하게 대응해야 한다면 **Claude Sonnet**이 필요합니다. 한 보험 회사의 예를 봅시다. 단순 문의는 Titan으로 처리하고, 보험금 청구 같은 복잡한 케이스는 Claude로 에스컬레이션합니다. 비용 효율과 품질을 동시에 잡는 전략입니다. **사용 사례 3: 콘텐츠 요약** 세 번째는 **텍스트 요약**입니다. 뉴스 기사, 고객 리뷰, 회의록을 자동으로 요약하는 작업이죠. 여기서는 원본 길이가 중요한 변수입니다. 짧은 텍스트(2000자 이하)를 빠르게 요약한다면 **Titan**이 적합합니다. 하지만 긴 보고서나 논문을 요약하면서 핵심 논리를 정확히 파악해야 한다면 **Claude**가 낫습니다. "우리 서비스는 고객 리뷰를 요약하는데, 보통 100~200자 정도예요." 김개발 씨가 말했습니다. "그럼 Titan이 완벽하네요. 빠르고 저렴하니까요." **사용 사례 4: 텍스트 분류** 네 번째는 **분류 작업**입니다. 이메일을 긴급/일반/스팸으로 분류하거나, 고객 문의를 부서별로 라우팅하거나, 상품 리뷰의 감정을 분석하는 작업입니다. 이런 경우 **Titan Text Express**가 최적입니다. 빠르고 저렴하며 정확도도 충분합니다. 프롬프트에 명확한 카테고리와 예시를 제공하면 매우 정확한 분류 결과를 얻을 수 있습니다. 하나의 요청으로 수백 건을 처리할 수 있어 대량 작업에 유리합니다. **사용 사례 5: 창의적 콘텐츠 생성** 다섯 번째는 **콘텐츠 생성**입니다. 블로그 포스트, 마케팅 카피, 소셜 미디어 게시글처럼 창의적이고 매력적인 텍스트를 만들어야 한다면 **Claude**가 강력합니다. 자연스러운 문체, 적절한 비유, 매끄러운 흐름을 만들어냅니다. Titan도 콘텐츠를 생성할 수 있지만 상대적으로 기계적이고 평범한 느낌이 들 수 있습니다. "사람이 쓴 것 같은 느낌이 중요하다면 Claude를 써야겠네요." 김개발 씨가 메모했습니다. **사용 사례 6: 데이터 추출** 여섯 번째는 **구조화된 데이터 추출**입니다. 이메일에서 날짜, 금액, 이름을 추출하거나 영수증에서 항목을 파싱하는 작업입니다. 패턴이 명확하다면 **Titan**으로도 충분합니다. 하지만 복잡하고 비정형적인 문서라면 **Claude**의 추론 능력이 필요합니다. 한 핀테크 스타트업은 계약서에서 핵심 조항을 자동 추출하는데 Claude를 사용합니다. 법률 용어와 복잡한 문장 구조를 정확히 이해해야 하기 때문입니다. **의사결정 프레임워크** 어떻게 결정을 내릴까요? 다음 질문들을 자신에게 던져보세요. --- ## 5. **품질**: 최고 수준의 자연스러움이 필요한가? → Yes면 Claude **실전 팁** 💡 - **비용 알림 설정**: AWS Budgets으로 Bedrock 사용 비용 알림을 설정하여 예상치 못한 요금 폭탄을 예방하세요 - **폴백 전략**: 주 모델이 실패하면 대체 모델로 자동 전환하는 로직을 구현하면 안정성이 높아집니다 - **캐싱 활용**: 같은 질문이 반복되는 경우 결과를 캐싱하여 API 호출을 줄이세요. ElastiCache나 DynamoDB를 활용할 수 있습니다 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: Python

태그: AWS, Titan, Bedrock, Embeddings, LLM

작성자: AI Generated

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

CodeDeck

Amazon Titan 모델 완벽 가이드

목차

1. Titan Text 모델 소개

2. Titan 텍스트 생성 API

3. Titan Embeddings 소개

4. 임베딩 벡터 생성하기

5. Titan vs Claude 비교

6. 용도별 모델 선택 가이드

5. 품질: 최고 수준의 자연스러움이 필요한가? → Yes면 Claude

댓글 (0)

함께 보면 좋은 카드 뉴스

Helm 마이크로서비스 패키징 완벽 가이드

보안 아키텍처 구성 완벽 가이드

AWS Organizations 완벽 가이드

AWS KMS 암호화 완벽 가이드

AWS Secrets Manager 완벽 가이드