AI Engineering/이론

LLM한테 페르소나를 적용하면 어떻게 이를 수행하는걸까?

마늘냄새폴폴 2026. 1. 24. 18:32

지금은 사람들에게 많이 알려진 프롬프트 엔지니어링 중에 가장 유명한 것이 바로 "페르소나"를 부여하는 것일건데요. LLM에게 페르소나를 부여하면 찰떡같이 잘 반응하게 되는데 내부적으로는 어떤 동작이 일어나길래 이 페르소나를 계속 유지할 수 있는걸까요? 

 

요즘은 프롬프트 엔지니어링이라고 부르는 것이 유형별로 잘 정립되어있어서 우리같은 일반인도 충분히 적용시킬 수 있는 범주 내로 들어와 사실 "엔지니어링"이라고 거창하게 부를만한가 싶긴합니다. 

 

다만, 이게 초반에 어째서 엔지니어링의 영역에 들어오게 되었는지 이번에 공부하면서 알게 되었는데, 이 프롬프트 엔지니어링이라는 것의 기반에는 Transformer 알고리즘의 이해가 필요했기 때문에 초기 단계에서는 이를 엔지니어링이라고 부를 정도의 무언가가 되었다고 생각합니다. 

 

이제 저랑 같이 Transformer 알고리즘을 복습하면서 페르소나를 프롬프트로 입력하면 어떤 동작방식을 거쳐서 페르소나가 입혀지는지 알아보도록 하겠습니다. 

 

이 포스팅에 들어가기 전에 제가 정리한 Transformer 알고리즘에 대한 기반지식이 필요합니다! 아래의 링크에 잘 정리되어있으니 한번 확인해보시고 이 포스팅을 읽으시는걸 추천드립니다. 

 

https://coding-review.tistory.com/614

 

Transformer 알고리즘은 과거와 다르게 어떻게 발전했을까?

안녕하세요. 요즘 AI 엔지니어링 업무를 하면서 관련된 것들을 공부를 하니 더 재밌는 것 같네요. 이번 포스팅에선 Transformer 알고리즘이 담긴 논문이 출판됐을 당시부터 있었던 근본 개념들을 알

coding-review.tistory.com

 

이번 포스팅에선 총 세가지 관점에서 페르소나를 분석해고 끝으로 성능 병목에 대해서 확인해 볼 예정입니다. 

 

  1. LLM에서 페르소나가 적용되는 과정
    - Attention 레이어와 페르소나
    - In-Context Learning과 페르소나
    - Masked Self-Attention과 페르소나
  2. 페르소나와 KV Cache, 그리고 성능 병목

Attention 레이어나, In-Context Learning이나, Masked Self-Attention 모두 LLM의 특성인데 이것이 페르소나와 만났을 때 어떤 시너지를 내는지에 대해서 서술합니다. 그리고 마지막으로는 페르소나가 KV Cache에 미치는 영향과 이것이 병목으로 어떻게 이어지는지 서술합니다. 

 

이제 본격적으로 들어가보시죠!

LLM에서 페르소나가 적용되는 과정

Attention 레이어와 페르소나

기본적으로 LLM들은 레이어라는 것이 존재합니다. 이 레이어는 모델이 얼마나 깊이있게 생각할 수 있는지에 대한 단계로 이해해도 무방한데요. 임베딩 모델로 유명한 BERT는 12개의 레이어가 존재하고 Llama-3-8b의 경우 32개의 레이어를 가지고 있습니다. 제가 개인적으로 뛰어나다고 생각하는 모델 중에는 Gemma-3-27b-it 모델이 있는데 이 모델의 경우 62개의 레이어가 존재합니다.

 

파라미터의 수가 늘어나면 이 레이어도 선형적으로 늘어난다고 보시면 됩니다. 즉,

 

"레이어가 많이 겹겹이 있으면 있을수록 모델이 더 깊이있는 생각을 할 수 있게 된다" 

 

이렇게 이해하셔도 무방합니다. 

 

이제 우리는 LLM에게 "너는 까칠한 개발자야" 이렇게 프롬프팅을 했다고 가정해봅시다. 그럼 모델은 이 프롬프트를 당연히 앞에서부터 읽겠죠? 이 토큰이 Attention 레이어의 첫 부분을 통과하면 모델은 다음과 같이 이해합니다. "아, 나는 개발자구나" 이제 N번째 레이어를 모두 통과하고 나면 모델은 "아, 나는 자바를 싫어하고 파이썬을 좋아하는 츤데레 말투를 써야하는 개발자구나" 이렇게 조금 더 복잡하고 구체적이면서 추상적인 특징으로 변하게 되는겁니다. 

 

이를 조금 더 공학적으로 풀어서 이야기해보겠습니다. 

 

"너는 까칠한 개발자야. 이 코드 분석해줘." 라는 프롬프팅을 넣으면 Positional Encoding이 이 토큰에 위치 정보 벡터를 부여합니다. 편의상 0번째라고 하겠습니다. 그리고 그 뒤에 요청은 1번째라고 가정하죠. 

 

이때 맨 처음 토큰이 Attention 레이어를 통과할 때 가장 첫 번째로 들어오면 가중치가 전파되고 맨 처음 토큰을 생성해서 답변할 때의 Attention Map에서 가장 강한 자극을 받게 됩니다. 

 

다음 토큰을 생성하는 데에 가장 큰 영향을 미치는 Attention Score의 경우 첫 번째 연산이 바로 쿼리와 키를 내적하는 것인데, 질문에 해당하는 쿼리와 인덱스에 해당하는 키가 서로 강하게 연결되어 있으니 모델은 이 페르소나로 대답하도록 강한 드라이브가 걸리는 것이죠. 

 

이건 조금 다른 얘기이긴 하지만, 프롬프트 엔지니어링에서 페르소나는 맨 앞에, 가장 중요한 수행은 마지막에 넣으라고 하는 이유를 크게 두가지 관점에서 볼 수 있습니다. 

 

이미 논문으로 많이 밝혀진 LLM모델들의 고질적인 문제 중 하나는 "모델은 맨 앞과 맨 뒤의 내용은 잘 기억하지만 중간 내용은 잘 기억 못한다"입니다. 이러한 문제는 맨 앞에 페르소나, 맨 뒤에 가장 강한 제약, 이렇게 두가지를 잘 수행할 수 밖에 없는 것이죠. 

 

이것이 LLM의 고질적인 문제라는 관점에서 바라본 프롬프트 엔지니어링입니다. 

 

또한, 요즘 LLM 모델들은 RLHF라는 방법을 주로 사용합니다. 이 방법은 모델이 인터넷에 있는 데이터를 싹 학습한 뒤에 답변을 생성하고 나서 사람에게 "이 답변은 사람같군, 이 답변은 너무 기계같아"이렇게 검수받는 강화학습 과정입니다. 

 

이 강화학습은 사람이 문맥을 보고 답변을 정해주기 때문에 모델은 사람이 정답이라고 판단내린 값에 더 큰 가중치를 두게 됩니다. 보통 이때 정답이라고 책정되는 것들은 인간이 마지막에 핵심 로직을 배치한다는 통상적인 관념상 인간의 대화 습관이 모델에 이식됩니다. 

 

이 때문에, 모델은 마지막에 오는 내용이 중요하다! 라고 판단하게 되는 것이죠

 

이것은 RLHF의 관점에서 보는 프롬프트 엔지니어링입니다. 

 

In-Context Learning과 페르소나

LLM 모델들은 인터넷에 있는 수많은 텍스트를 학습하면서 특정 문맥 뒤에는 어떤 말투와 어떤 지식이 뒤따르는지에 대한 통계적인 패턴을 학습하게 됩니다. 

 

프롬프트에서 페르소나를 넣는 행위는 모델의 거대한 파라미터 공간 중에서 해당 파라미터와 일치하는 공간으로 확률 분포를 강제로 이동시키기 때문에 모델이 인터넷에서 학습한 모델을 그대로 잘 이행할 수 있는 것이죠. 

 

Masked Self-Attention과 페르소나

우리가 흔히 사용하는 LLM모델들은 Decoder-Only인 경우가 많은데 Decoder-Only 모델들의 특징은 앞에서 생성한 토큰을 다음 입력으로 집어넣는 자기 회귀 구조를 띄고 있기 때문에 앞에서 생성한 토큰들을 입력으로 받아서 페르소나가 그대로 유지되는 특징을 가집니다. 

 

페르소나와 KV Cache, 그리고 성능 병목

마지막으로 언급했듯이 Decoder-Only는 자기 회귀 구조를 가지고 있어 같은 연산을 계속 반복해야하는 문제가 있는데 이를 KV Cache라는 곳에 두어 연산을 빠르게 할 수 있도록 했습니다. 이것이 KV Cache라고 불리는 이유는 이미 행렬곱에서 연산했던 K와 V의 벡터는 변하지 않기 때문에 키와 값을 메모리에 저장해도 전혀 문제 없기 때문입니다. 

 

KV Cache가 점유하는 메모리를 구하는 공식은 다음과 같습니다. 

 

2 X Hidden Layer X Head Dimension X KV Head X n_ctx X B

 

여기서 다른건 볼 필요 없고 n_ctx만 보면 됩니다. n_ctx는 LLM에게 주어지는 입력 토큰이라고 이해해도 좋고, LLM모델이 기억하고 있는 토큰의 수라고 이해하셔도 좋습니다. 

 

즉, 프롬프트가 길어지면 길어질수록 n_ctx의 크기가 커지고 이는 KV Cache의 크기를 선형적으로 늘리는 원인이 됩니다. 이렇게 되면 추론을 시작하기도 전에 VRAM을 선점하는 것이기 때문에 맨 처음 토큰이 나오는 시간인 TTFT의 시간이 길어지죠. 

 

TTFT 뿐만 아니라, 개별 세션이 처리하는 KV Cache가 커지면, 하나의 GPU에서 동시에 처리할 수 있는 배치 사이즈가 줄어들고 처리량이 줄어드는 문제도 생깁니다. 

 

이 때문에, 프롬프트의 크기가 너무 비대해지지 않도록 주의를 기울여야 성능상 병목이 생기지 않는 것이죠. 

 

물론, 동적으로 변하지 않는 프롬프트는 미리 연산을 해놓음으로써 TTFT를 줄이는 방법이 있지만 이건 실전과 관련된 내용이므로 여기서는 더 언급하지 않겠습니다. 

 

마치며

이번 포스팅은 개인적으로 궁금했던 내용을 정리해보았는데 Transformer의 기본 동작 원리는 이해하고 공부하니 더 이해하기가 쉬웠습니다. 그래서 꼭 Transformer의 기본동작 원리를 보시고 보는 것을 추천드립니다. 

 

GPT가 등장한지는 만으로 3년정도 되었고 AI 엔지니어링이라는 것이 등장하기 시작한건 만으로 2년정도 되었기 때문에 Transformer의 기본 개념 안에서 돌고돌고 계속 돌리는 느낌이 들기는 합니다만, 그렇기에 Transformer의 이해가 그 어느때보다 중요해진 시점인 것 같습니다. 

 

다음 포스팅은 뉴럴 링크와 역전파에 대해서 공부해보고 정리해볼 것 같습니다. 이번 포스팅은 여기서 마치도록 하겠습니다. 긴 글 읽어주셔서 감사합니다. 오늘도 즐거운 하루 되세요!