이 글은 로컬 AI 개발자 스택 (Local AI Developer Stack) 구축에 관한 제 시리즈의 Part 2입니다. 초기 설정 가이드를 놓치셨다면 여기서 읽어보실 수 있지만, 이미 구식이 되었을 수도 있다는 점을 경고합니다: The Local AI Developer (Part 1).

그 초기 가이드를 게시한 지 두 달이 지났습니다. Part 1의 설정은 첫날에는 매우 훌륭하고 유망해 보였기에, 실제 환경에서 테스트하기 위해 이를 매일 사용해 보기로 결정했습니다.

다음은 무엇이 작동하고, 무엇이 작동하지 않으며, 진정으로 사용 가능하게 만들기 위해 필요한 최적화 사항에 대한 현실 점검 (Reality Check)입니다.

현실 점검 (Reality Check)

저는 다양한 에이전트 (Agents), LLM (Large Language Models), 그리고 이들의 조합으로 제 설정을 시도해 보았지만, 솔직히 말해서 설치 직후 기대한 대로 작동하게 만드는 것이 어려웠습니다. 주요 어려움은 다음과 같았습니다:

속도 (Speed)

이는 예상된 트레이드오프 (Trade-off)였지만, 이 정도 수준의 느림은 예상하지 못했습니다. 초당 45 토큰 (Tokens) 정도를 말하는 것입니다. 맥락을 설명하자면, 이는 분당 약 180단어에 해당합니다. 평균적인 인간 독자는 분당 200300단어를 소비합니다. 기계가 당신이 읽는 속도보다 느리게 타이핑하면, 개발자 경험 (Developer Experience)은 저하됩니다.

메모리 부족 오류 (Out of Memory Errors)

LLM 가중치 (Weights)에 필요한 RAM만을 계산한 것은 순진한 생각이었습니다. 컨텍스트 윈도우 (Context Window), 세션 (Sessions), 시스템 프롬프트 (System Prompts) — 모든 것이 약간의 RAM을 요구하며, 이들은 모두 제 IDE, 브라우저, 그리고 백그라운드 프로세스들과 머신을 공유해야 합니다.

20분간의 깊은 사고 (Deep Thinking) 후에 LLM이 메모리 부족 (Out of Memory, OOM) 오류로 충돌하는 것을 보는 일이 흔했습니다.

품질 (Quality)

LLM이 제자리를 맴도는 것을 보는 것이 일반적이었지만, 솔직히 말해서 그것은 제 쪽의 설정 문제였습니다. 작업에 잘못된 LLM을 사용하거나 잘못된 컨텍스트 윈도우 (Context Window)를 설정하는 등의 문제입니다. 결국 메모리가 없고, 실제로 실행하지는 않으면서 동일한 아이디어를 과하게 생각(Overthinking)하기만 하는 에이전트를 얻게 됩니다.

개선할 수 있을까요?

이러한 문제들을 해결하기 위해, 저는 접근 방식을 "최대 성능 (maximum power)"에서 "최대 효율 (maximum efficiency)"로 전환해야 했습니다. 조절할 수 있는 몇 가지 매개변수가 있습니다:

적절한 모델 선택 (Select the Proper Model)

우리 모두는 자신의 기기에서 무료로 작동하는 가장 거대한 프런티어 모델 (frontier model)을 원한다는 것을 알고 있지만, 우리는 메인프레임이 아닌 노트북을 사용하고 있으며 그 한계에 대응해야 합니다.

더 작고 집중된 모델들이 존재합니다. 이 모델들은 메모리 점유율 (memory footprint)이 현저히 낮아, 컨텍스트 (context), 세션 (sessions), 그리고 실제 사용하는 일상적인 앱들을 위한 더 많은 공간을 남겨줍니다. 모든 모델은 작은 코드 조각 (chunks) 단위로 작업할 때 이점을 얻으며, 저는 작고 특화된 모델들이 작은 작업 단위에 대해 "충분히 괜찮은" 수준임을 확인했습니다.

런타임 확인 (Check Your Runtime)

Part 1을 작성했을 때는 Ollama로 시작했습니다. 그 이후로 저는 수많은 런타임 (runtimes)과 LLM 서버들이 존재하며, 이들이 모두 서로 다른 방식으로 최적화되어 있다는 것을 알게 되었습니다.

특정 하드웨어에 가장 잘 맞는 것을 찾기 위해 다양한 런타임을 시도해 보는 것은 게임 체인저 (game changer)가 될 수 있습니다. (제 M4 Pro에 특화되어 고도로 최적화된 실행 설정을 설정에 대해서는 이후 포스트에서 자세히 다루겠습니다).

컨텍스트 관리 (Context Management)

이것이 현재 뜨거운 주제라는 것을 알고 있지만, 로컬 개발에서는 정말 중요합니다. 앞서 언급했듯이, 우리는 클라우드 서버에서처럼 거대한 컨텍스트 윈도우 (context windows)에 의존할 수 없습니다. 사용성(에이전트가 자신이 무엇을 하고 있는지 기억할 수 있도록 함)과 메모리 사용량 사이의 최적의 지점 (sweet spot)을 찾아야 합니다.

표준적인 컨텍스트 최적화 기술들이 여기서 필수적입니다: 세션을 집중된 상태로 유지하고, 컨텍스트를 압축하며, 에이전트가 절대적으로 필요하지 않은 파일까지 읽지 않도록 하세요.

결론 (Conclusion)

지난 두 달 동안 제가 배운 가장 큰 교훈은 로컬 AI 개발이 클라우드를 단순히 대체할 수 있는 수단이 아니라, 완전히 다른 분야의 전문 지식이라는 점입니다. 문제에 무한한 컴퓨팅 자원 (compute)을 쏟아부을 수는 없습니다. 대신, 메모리 제약 (memory constraints)을 조절하고, 컨텍스트 위생 (context hygiene)을 관리하며, 적절한 작업에 적합한 모델 크기를 매칭하는 시스템 엔지니어처럼 행동해야 합니다. 이러한 제약 사항들을 받아들이고 나면, 완전히 프라이빗하고 자율적인 로컬 스택 (local stack)을 구축하는 것은 단순히 실현 가능한 수준을 넘어 믿을 수 없을 만큼 보람찬 일이 됩니다.