엘엘님, 다시 오셨네요! 😊 질문을 이렇게 구조까지 갖춰서 주시니까 답하는 저도 신나요.
결론부터 말씀드릴게요. 판단 구조는 맞아요. "하드웨어보다 데이터 반출 정책이 결론을 결정한다" — 이 질문 전체에서 제일 값진 문장이 이거예요. 다만 그 전제를 두 갈래(보낼 수 있다/없다)가 아니라 몇 단계로 쪼개 보시면 결론이 훨씬 선명해질 거예요.
1. 판단 구조 — 맞아요. 다만 스위치가 아니라 다이얼이에요
실제 사내 정책은 "전부 허용 / 전부 금지"로 딱 떨어지지 않는 경우가 많더라고요. 이런 단계로 확인해 보시면 좋아요.
- 원문 PDF를 통째로 보내도 되는지
- 검색된 청크 몇 개만 보내도 되는지 (RAG는 어차피 질문마다 관련 조각 몇 개만 모델에 넣거든요)
- 마스킹·요약한 텍스트만 되는지
- 회사가 계약한 특정 엔드포인트(데이터를 보관하지 않는 기업용 계약 등)만 되는지
- 전면 금지인지
두 번째나 네 번째 단계에서 멈추는 경우가 꽤 많은데, 그러면 "로컬은 파싱·임베딩·검색, 생성은 클라우드"라는 하이브리드가 되니까 PC안 쪽이에요. 로컬 모델 품질이 핵심이 되는 건 정말 마지막 단계일 때뿐이에요.
그리고 꼭 같이 물어보셨으면 하는 게 하나 있어요. "문서를 클라우드로 못 보낸다"는 회사가, 그 문서를 인터넷에 연결된 단독 장비에 두는 건 허용할까요? 보안팀 입장에선 반출 경로가 API든 인터넷 연결 PC든 비슷하게 보일 수 있거든요. 이 질문 하나로 장비 구성 자체가 바뀔 수 있어서, 사양보다 먼저 확인하시길 권해요.
2. Mac의 prefill 약점 — 체감돼요. 다만 설계로 줄일 수 있어요
추정하신 방향이 맞아요. 출력(decode)은 대역폭 싸움이지만, 입력 처리(prefill)는 연산량 싸움이라 여기선 NVIDIA 텐서 코어가 확실히 유리해요. M5 세대에서 GPU 코어마다 신경망 가속기가 들어가면서 격차가 이전 세대보다 많이 줄었지만, 같은 모델 기준으로 뒤집히지는 않아요.
체감 여부는 결국 "한 번에 몇 토큰을 넣느냐"로 정해져요. 산수로만 보면, 2만 토큰짜리 프롬프트를 초당 500토큰으로 처리하면 첫 글자까지 40초, 초당 4,000토큰이면 5초예요. (감을 잡기 위한 예시일 뿐, 해당 장비 실측값은 아니에요.) 그런데 RAG는 설계로 이 입력을 줄일 수 있어요. 리랭커로 상위 5~8개 청크만 넣으면 수천 토큰 선이라 Mac에서도 충분히 쓸 만해요. 문서를 통째로 밀어 넣는 설계라면 확실히 체감되고요.
실측 근거를 못 찾으셨다고 하셨는데, 그게 정상이에요. 공개 벤치마크 대부분이 빈 컨텍스트에서 첫 턴 속도만 재거든요. 가능하면 매장이나 지인 장비에서 실제로 쓰실 길이의 프롬프트로 llama.cpp의 llama-bench나 mlx-lm으로 직접 재 보시는 게 제일 정확해요.
작은 보정도 두 가지 드릴게요.
- 70B는 64GB Mac에서 빠듯해요. 4bit 웨이트만 40GB 안팎이고, RAG처럼 컨텍스트가 길면 KV 캐시가 그 위에 쌓이거든요. 편하게 쓰는 선은 30B급으로 보시는 게 안전해요.
- MoE 모델이 계산을 바꿔요. 요즘 오픈 모델은 전체 파라미터는 크고 실제로 움직이는 파라미터는 작은 MoE 구조가 많아요. 이런 모델은 용량만 크면 속도도 잘 나와서 Mac의 장점이 살아나요. 동시에 PC도 64GB 시스템 RAM에 전문가(expert) 레이어를 내려놓고 돌리는 방식으로 16GB VRAM 한계를 어느 정도 넘을 수 있어요. 그래서 "PC는 14B가 상한"은 dense 모델 기준으로만 맞는 말이에요.
3. "용량 보험"으로서의 Mac — 저는 과투자 쪽이라고 봐요
이유는 세 가지예요.
- 기계는 멈추고 클라우드는 움직여요. 지금 산 장비는 올해 성능으로 3년을 버텨야 해요. 클라우드가 막히는 날이 2년 뒤라면, 그때 사는 장비와 그때 나온 오픈 모델이 지금 것보다 훨씬 좋을 거예요. 미래의 사고에 대한 보험료를 오늘 가격으로 내는 셈이에요.
- 보험은 사고가 났을 때 보상이 돼야 보험이에요. 클라우드가 막힌 날, 금융 전략·리서치 품질을 로컬 30B가 감당할 수 있을까요? 못 한다면 Mac은 "덜 나쁜 대안"일 뿐 보험금이 아니에요. 격차를 줄여 줄 뿐 메워 주지는 못하거든요.
- 통계 분석이나 API 수집은 GPU를 거의 안 써요. 임베딩 모델(bge-m3 같은 것)이나 리랭커는 세 후보 어디서든 잘 돌아요. 로컬 생성이 부차적이라면 5070 Ti가 아니라 5060 Ti로도 충분할 수 있어요. 두 PC는 VRAM이 같으니 올릴 수 있는 모델 크기는 똑같고, 속도만 달라요.
단, 현실 변수 하나는 인정할게요. 회사 장비는 "나중에 다시 요청"이 어려운 경우가 많죠. 두 번째 결재가 사실상 불가능한 환경이라면 여유분을 한 번에 확보하는 게 합리적일 수 있어요. 그건 하드웨어가 아니라 조직의 문제라서, 엘엘님이 제일 잘 아실 거예요.
정리
- 판단 구조: 맞아요. 다만 정책을 "허용/금지"가 아니라 "어떤 단위의 텍스트가 나갈 수 있나"로 쪼개서 확인하세요.
- 제일 먼저 할 일: 보안팀에 (1) 청크 단위 전송이 되는지, (2) 내부 문서를 인터넷에 연결된 단독 장비에 두는 것 자체가 되는지 물어보기.
- Mac prefill: 체감돼요. 하지만 RAG 설계(넣는 청크 수 제한)로 상당 부분 관리할 수 있어요.
- 용량 보험: 보험금이 안 나오는 보험일 가능성이 커서 과투자 쪽이에요. 단, 재결재가 불가능한 조직이라면 예외예요.
용량·대역폭·생태계를 나눠 보시다가, 거기서 한 발 더 나가 "결론은 결국 정책이 쥐고 있다"까지 가신 게 정말 멋져요. 도구를 들여다보다가 전제를 발견하신 거잖아요. 보안팀 답이 나오면 또 들려주세요! 🙂
~ 피파
1.맥락
금융사에서 전략·리서치 업무를 하고 있어. 회사 PC 한 대에 다음 시스템을 구축하려고 해.
사내 문서(PDF) 기반 RAG
외부기관 API 데이터 수집
클라우드 AI를 함께 쓰는 통계분석과 전략 도출 보조 시스템
장비는 사내망에 연결하지 않는 단독 장비이고, 인터넷은 연결돼.
2.후보 3안
PC: RTX 5060 Ti 16GB + RAM 64GB
PC: RTX 5070 Ti 16GB + RAM 64GB
Mac Studio M5 Max (40코어 GPU, 통합메모리 64GB, 1TB) — 약 660만 원
3.미리 생각해본 것
16GB VRAM에서 로컬 LLM은 14B급(4bit, 약 8.5GB)이 편하게 쓸 수 있는 한계라고 봤어. Mac은 GPU 가용 약 48GB라 30B~70B급까지 올릴 수 있어.
출력 속도는 대역폭 ÷ 웨이트 크기로 봤어. 448 / 614 / 896 GB/s라서 Mac은 두 PC의 중간이야.
RAG는 입력이 길어서 prefill 비중이 커. 이 구간에서 Mac이 약할 수 있다고 추정했는데 실측 근거는 못 찾았어.
결론이 한 가지 전제에 걸려 있어.
내부 문서를 클라우드로 보낼 수 있으면: 로컬은 임베딩과 파싱만 하면 되니 PC안이 맞다고 봐.
못 보내면: 로컬 모형의 품질 상한이 핵심이 되니 Mac이 맞다고 봐.
4.묻고 싶은 것
클라우드 허용 여부에 따라 결론이 뒤집힌다는 이 판단 구조 자체가 맞아?
RAG 중심 워크로드에서 Mac의 prefill 약점은 실제로 체감할 수준이야?
클라우드 전송이 나중에 막힐 리스크에 대비해 Mac을 "용량 보험"으로 사는 게 합리적이야, 아니면 과투자야?
5.이 질문이 나온 배경
피파의 "모형을 상주시켜 놓고 돌려쓴다" 영상을 보고, 메모리 용량과 대역폭과 실행 생태계를 구분해서 보게 됐어. 그 틀로 회사 장비 요청안을 다시 짜다 보니, 하드웨어보다 데이터 반출 정책이 결론을 결정한다는 걸 깨달았어. 그 판단이 맞는지 확인받고 싶어.