페르소나를 여러 개 만들다가 MoE를 만났다

처음 목표는 단순했다.

내가 평소에 쓰는 글과 메시지의 특징을 작은 모델에 넣어보고 싶었다. 답변을 똑똑하게 만드는 것보다, 내가 실제로 일하는 방식에 가까운 결과를 만들고 싶었다.

그래서 처음에는 페르소나를 여러 개 만들었다. 그런데 문서 채널별 페르소나만으로는 부족했다.

디자인 기획자          사용자가 무엇을 경험해야 하는가
아키텍처 리뷰어        경계와 의존성이 오래 버틸 수 있는가
CTO                   이 일을 지금 해야 하는가
오버엔지니어링 감시자  문제보다 해법이 커지고 있지 않은가
실행 담당자            다음 커밋과 검증 단계가 무엇인가

커밋, PR, Jira, Slack은 결과를 담는 형식에 가까웠고, 위 역할들은 판단하는 관점에 가까웠다. 같은 기능을 두고도 디자인 기획자는 사용자 흐름을 보고, CTO는 투자 대비 효과를 보고, 오버엔지니어링 감시자는 불필요한 복잡도를 봐야 했다.

처음에는 각각을 별도 prompt로 만들고 필요할 때 하나를 골라 쓰면 될 것 같았다. 하지만 실제 업무는 한 가지 역할로 끝나지 않았다.

기획 → 아키텍처 검토 → 과잉 설계 검사 → 실행 계획 → 문서화

페르소나 하나를 선택하는 문제가 아니라, 어떤 순서로 어떤 관점을 통과시킬지 정하는 문제가 됐다.

문제는 이것을 전부 하나의 “내 말투”로 뭉개면 중요한 차이가 사라진다는 것이었다.

내 히스토리를 학습 데이터로 생각하기 시작했다

내가 가진 자료는 꽤 여러 종류였다.

• 커밋 메시지와 변경의 맥락
• PR 제목, 목차, 설명 구조
• Jira 이슈의 문제 정의와 진행 상태
• Confluence 문서의 설명 방식
• Slack의 DM, 팀 채널, 전역 채널 대화
• 디자인 기획과 의사결정의 근거
• 아키텍처 리뷰와 과잉 설계가 지적된 흔적

하지만 원문을 모아서 넣는다고 학습 데이터가 되지는 않았다.

같은 사람이 쓴 글이라도 목적이 다르면 정답의 모양이 달랐다. 커밋은 짧은 동사와 변경 요약이 중요했고, PR은 읽는 사람이 빠르게 구조를 파악하도록 제목과 목차가 필요했다. Jira는 재현 가능한 템플릿이 유용했고, Slack은 관계와 공개 범위를 먼저 판단해야 했다.

그래서 데이터에 이런 라벨을 붙이기 시작했다.

source: commit | pr | jira | confluence | slack | design | review
audience: dm | team | global | customer | engineer
role: designer | architect | cto | reviewer | operator | writer
intent: report | ask | decide | explain | challenge | prioritize
format: title | outline | template | short-message | document | decision

이때부터 프로젝트는 말투 복제가 아니라 업무 문맥 분류와 생성의 문제가 됐다.

dense 모델을 여러 개 두면 해결될 줄 알았다

다음 선택은 모델을 여러 개 두는 것이었다.

커밋용, PR용, Jira용 모델에 더해 디자인 기획용, CTO 리뷰용, 오버엔지니어링 감시용 모델을 각각 LoRA로 만들면 서로 간섭하지 않고 더 잘 맞을 것 같았다. 실제로 초기 결과는 그럴듯했다. 각 adapter는 자기 형식과 관점에 집중했고, 한 가지 작업만 시키면 꽤 자연스러웠다.

하지만 운영하려고 하니 문제가 생겼다.

요청 분석
  → 적절한 페르소나 선택
  → adapter 선택
  → 모델 로드 상태 확인
  → 생성

페르소나 수가 늘어날수록 라우팅 규칙과 로딩 상태가 복잡해졌다. 서로 다른 dense 모델을 많이 두는 것은 전문성을 나누는 일이기도 하지만, 동시에 여러 실행 경로와 메모리 비용을 관리하는 일이기도 했다.

그리고 한 문서 안에 여러 관점이 섞이면 어느 모델로 보내야 하는지 애매해졌다. 디자인 기획을 CTO 관점에서 잘라보고, 아키텍처 제안을 오버엔지니어링 관점에서 다시 줄이고, 마지막에 PR 목차로 정리해야 하는 순간부터는 페르소나를 하나만 고르는 방식이 어색해졌다.

LoRA가 모든 것을 해결해주지는 않았다

LoRA는 base model을 바꾸지 않고 특정 작업의 표현과 패턴을 조정하는 데 유용했다.

하지만 LoRA가 알려주는 것은 주로 “어떻게 표현하는가”에 가깝다. 어떤 채널에서 누구에게 어느 정도까지 말해야 하는지, 문서의 어떤 필드를 채워야 하는지, 원문에 없는 사실을 만들면 안 되는지는 별도의 설계가 필요했다.

특히 Slack 데이터는 조심해야 했다. DM과 팀 채널과 전역 채널은 같은 문장이라도 공개 범위가 다르다. 직급이나 관계를 라벨링하는 것도 스타일을 흉내 내기 위한 장식이 아니라, 잘못된 수신자에게 과도한 정보를 보내지 않도록 하는 경계가 되어야 했다.

그래서 원문을 많이 넣는 것보다 다음을 먼저 고정했다.

무엇을 말할 수 있는가
누구에게 말할 수 있는가
어떤 형식으로 말해야 하는가
확신할 수 없는 내용은 어떻게 표시하는가

dense에서 MoE를 찾아보게 된 이유

이쯤 되니 MoE가 궁금해졌다.

Dense 모델은 한 번의 forward에서 전체 파라미터가 계산에 참여한다. 반면 MoE는 여러 expert 중 일부를 router가 선택해 계산에 참여시키는 구조다. 전체 파라미터 규모가 크더라도 한 토큰에서 활성화되는 경로는 일부일 수 있다.

물론 “MoE니까 여러 페르소나를 자동으로 알아서 처리한다”는 뜻은 아니다. 모델의 expert와 내가 정의한 업무 페르소나는 같은 개념이 아니다.

그래도 이 구조를 공부하면서 중요한 관점을 얻었다.

모든 일을 하나의 dense 경로에 넣는다
  vs
입력의 성격에 따라 일부 계산 경로가 활성화된다

내가 prompt 앞단에서 하던 분류와, 모델 내부 router가 하는 선택은 서로 다른 층의 문제다. 이 둘을 혼동하면 MoE를 단순한 “모델 여러 개 묶음”으로 오해하게 된다.

처음에는 모델에 내 페르소나를 넣으려고 시작했다.

지금은 조금 다르게 생각한다.

좋은 개인화 모델은 내 문장을 흉내 내는 모델이 아니라, 여러 역할의 검토를 거쳐 어떤 판단을 하고 어떤 형식으로 말하는지 보존하는 시스템에 더 가깝다.

그런데 역할을 늘리는 순간 모델을 여러 개 둘 것인지, 하나의 모델 안에서 계산 경로를 나눌 것인지가 문제가 됐다.

여기서부터는 말투보다 훨씬 현실적인 문제가 튀어나왔다.

아오, 대역폭. MoE는 뭐가 이렇게 다른가.