Post

sLM 네트워크 구축하기

로컬 sLM 네트워크 구축하기

금요일 오후에 급 업무가 하나 잡혔다. 그런데 월요일 오전까지 구상해야 하는 내용이라 글을 끼적끼적 해보고 있다. 약간 시간이 빠듯한 것 같기도 한데, 재밌어 보이기도 하고 네트워크 쪽은 나도 의견을 낼 일이 잘 없다보니 이참에 공부도 해볼겸 실실 해보고 있다.

회사에 맥 스튜디오가 하나 있는데, 이사님이 개발하고 계신 소규모 언어 모델을 해당 기기에서 구동, 프리뷰 느낌으로 조금씩 트래픽을 받을 예정이라고 한다. 지금은 ngrok 끼고 개발중이라고 하셨는데, 아무리 소규모 프리뷰라도 그대로 상용에 내놓기는 약간의 우려되는 점들이 있다고 판단하셔서 자료 조사를 요청해 주셨다.

아마 회사 로컬 머신에서 모델을 구동시키고, 사내 망이라고 표현하기엔 좀 과하지만 어쨌든 공유기 타고 클라우드에 있는 우리 서버랑 통신이 되어야 한다. 그 외에도 주요 쟁점들은 다음과 같다.

  • 네트워크, 망 구성
    • 여러 보안적 요소들
    • 유저, 서버 인증 방식
  • 벡터화된 문서 캐싱
    • 같은 고객사의 동일 문서 RAG 요청 처리
    • 유효기간 30일, 한 번이라도 재접근 시 연장, 아니면 문서 제거
    • 반복적인 문서 임베딩, 벡터화를 막기 위한 작업
  • 그 외 고민
    • 맥 스튜디오 사양을 몰라서 작업을 얼마나 빨리 쳐낼지 모르겠다
    • 예상 수요도 정확히 몰라서 어느 정도까지 대비를 해야 하지?
    • 건물 정기 점검으로 인한 정전(은 답이 없을 것 같긴 하다…)

적다보니 약간 아리송한 안건들도 있긴 한데, 일단 하나씩 정리해보자.

네트워크 구성

현재는 ngrok을 사용중이고, 그냥 보안이나 여러 이슈들 때문에 조금 더 좋은 방안에 대해 고민해보자고 하셨는데 나도 잘 모르겠다.

하루 사용자 어림잡은 정도는 대충 들었는데 이 정도면 그냥 ngrok 써도 되지 않나 싶기도 하고…? 굉장히 적은 숫자라 솔직히 그냥 써도 될 것 같긴한데 점차 늘어날 수는 있으니까 일단 조사해봤다.

찾다보니 리버스 프록시 터널링 방식을 쓰는 클라우드플레어 터널이 요금이나 현재 상황 고려해서 가장 낫지 않을까 해서 테스트해봤다. ngrok도 유사한 방식이지만 무료와 유료 요금제의 갭이 크다고 들었고, 클라우드플레어는 무료 요금제만으로도 ngrok 대비 많은 이점(커스텀 도메인, 더 많은 트래픽 할당…)을 가지고 있다고 하길래 일단 이걸로 말씀드려볼까 생각중이다.

zrok이라는 오픈소스도 있다고 하는데 그래도 내가 구축하는 것 보다는 거인의 어깨에 올라타는 것이 여러모로 낫지 않을까 싶어서 크게 고려하지 않았고, 회의전에 그래도 혼자 뭐라도 끼적여봐야 신뢰도가 오를 것 같아 이것저것 혼자 해봤다.

image

터널 설정은 굉장히 간편하다. 각자의 운영체제에 맞게 프로그램을 설치 후 하라는 대로 잘 따라해주면 바로 연결된다.

image

이렇게 설정이 완료되고, 다음과 같은 커맨드를 입력해주면

1
cloudflared.exe service install eyJhIj.................

연결되었다고 초록불이 뜰 것이다.

그리고 별도의 서비스 인증 토큰을 만들 수 있다. 응용 프로그램을 먼저 등록해주자.

image

image

image

인증 방식중 고정된 서비스 토큰을 미리 만들고 해당 값으로 터널링 된 로컬 서버와 통신할 수 있게 설정이 가능하다. 도메인 정보를 터널쪽이랑 맞게 입력해주고, 인증 규칙에 생성해놓은 서비스 인증 토큰을 연동해주면 해당 값 없이는 서버에 접근이 불가능하다.

1
2
3
4
headers = {
    "CF-Access-Client-Id": "xxxxxxx.access",
    "CF-Access-Client-Secret": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}

다음과 같이 토큰을 헤더에 실어보낼 수 있다.

스크린샷 2025-05-11 133624

인증 정책 설정 전에는 url 입력시 바로 접속이 가능했지만

스크린샷 2025-05-11 134812

정책 적용시 접속이 막힌 것을 볼 수 있다.

나도 리버스 프록시 터널링이라는 기술이 굉장히 친숙한 것은 아니지만, 한번 조사해보니 대략적으로 감은 왔다.

image

아마 이런 느낌이지 않을까 싶다. 클라이언트 프로그램과 프록시 서버로 의존성을 잘 컨트롤해줘서 가능한 것 같다. 터널이라는게 미리 설치한 프로그램이 클라우드플레어쪽 프록시 서버에 요청을 날려주면, 그 요청을 계속 살리면서 통신할 수 있는 길을 열어놓는 것 같았다. 인바운드 포트를 직접 열어주지 않고도 통신이 가능해진 셈이다.

image

그런데 계속 고민되는게 예전에도 맵샷 운영하면서 겪은 이슈인데 얘가 자꾸 ICN, 한국쪽 데이터 센터가 아니라 미국 여행 보낸다… 클라우드플레어 자체 도메인 사용중이라 자꾸 cdn 태워서 이런것 같은데 아마 외부 도메인 끌고와서 프록시 설정 꺼주면 서울로 보내주길 바라고 있다. 터널쪽 실제 배정받은 서버명도 나오는데 거기는 다행히 ICN으로 나오니께…

문서 캐싱

이건 어떤 의도로 말씀하신건지 모르겠는데 아마 기능 자체를 요청을 보낼때마다 문서를 벡터화하도록 설계하신 것 같다. 최대한 sLM 쪽으로 api 요청을 덜 보내달라는 말씀인가…?

그게 맞다면 우리가 사용중인 몽고DB에 TTL 같은거 설정해서 문서 탐색하고 널값 나오면 실제로 쏘게 하면 될 것 같다. 동일 문서 판별 여부가 문제긴 한데, 매번 뽑히는 텍스트 값이 일관되게 나온다면 해싱값 하나 떠놓을까 했더니 이러면 매번 텍스트를 추출해서 비교해야 하니까 말이 안되는 것 같고, 그냥 (회사명 + 문서 제목) 이 정도로만 나이브하게 해도 크게 상관없을 것 같다.

작성일 기준 11일 일요일 밤이니까 내일 아침에 회의하면서 조율하면 될 것 같다.

그 외 고민

아직 감이 안 오는 작업이다. 정책도 그렇고 운영 방식도 아무것도 들은게 없어서 내일 회의를 더 해야 명확해지지 않을까 싶다.

  • 맥 스튜디오가 동시에 몇 개 정도의 요청을 어느정도의 퍼포먼스로 처리가 가능한지
  • 어느정도로 유저를 돌릴건지
  • 만약 작업이 누적된다면 어떻게 관리할건지
    • 큐 기반 쟁여놓기
    • n개 작업만 동시에 처리하고 나머지는 묻지마 블로킹 등등…
  • 우리 가끔씩 건물 점검한다고 정전시키는데 이럴때 만약 작업이나 데이터가 유실된다면 어떻게 처리할건지(맥os에 전기가 껏다 켜지면 자동으로 전원이 켜지는 기능이 있으려나…?)

그냥 클라우드 인프라 쓰면 안되나…? ㅠㅜ….

This post is licensed under CC BY 4.0 by the author.

© . Some rights reserved.

Using the Jekyll theme Chirpy