Written by n0fate
on 

2026 근황

안녕하세요. 최근 회사생활에 현생에 여러가지 일을 하다보니, 연구적 성과를 딱히 내지 못하는 삶을 살고 있습니다. 겸사겸사 생각도 정리할겸 최근에 했던 것들을 정리해볼까 합니다.

macOS 메모리 분석 관련

최근 macOS는 예전처럼 쉽게 메모리 덤프를 획득하기가 어려워졌습니다. Windows는 몰라도 이제 macOS는 조직 내 MDM 솔루션 등을 통해 미리 메모리 분석을 위한 커널 드라이버를 로드해두고 필요에 따라 덤프 또는 라이브로 메모리를 분석하는 형태로 진행하는 것이 바람직합니다. (예를 들어, 구글의 grr과 같은 접근법을 들 수 있겠네요.)

또한, macOS 버전업이 진행될수록 커널이 기본적으로 제공하던 심볼 정보도 사라지다보니, 커널 디버그 킷(Kernel Debug Kit)이 나오기 전까지는 제대로된 분석도 어려운 상황입니다. 내부적으로 macOS Sequioa에 대해서는 이러한 상황을 고려하여 메모리 분석이 가능하도록 수정은 해 두었지만, 아직 github에 업데이트하진 않았습니다. (문제 해결에 클로드 코드가 큰 도움이 되었습니다)

논문 관련

몇몇 분들은 알고 계시겠지만 수년 전에 냈던 아이디어를 몇년 동안 PoC까지 만들고 안쓰고 있던 논문을 다시금 정리하고 있습니다. 뭐 그래도 PoC에서 멈춘 것은 아니고 여러 샘플 대상 테스트에서 좋은 결과가 나옴을 볼 수 있었으며 최신 기법도 대응이 가능하도록 알고리즘을 구현하였습니다. 올해 내에는 정리해서 털어버려야하는데 뭔가를 진득하게 하기 힘들다(는 핑계로)보니 차일피일 미뤄지고 있습니다 ㅎㅎ. 이 건은 논문이 Publish되면 다시끔 글을 쓰게되지 않을까 싶습니다.

LLM 모델과 서빙

저의 경우 24년초부터 ChatGPT와 같은 LLM을 통해 코딩 지원(그 때는 채팅 중심)을 받아 수행했으나, 최근에는 로컬 LLM 모델의 성능이 좋아짐에 따라 다양한 모델과 이에 대한 서빙 방법을 살펴보게 되었습니다. 제가 쓰는 곳은 보통 코딩, 코드 분석 영역이기 때문에 이러한 기능에 초점을 맞추어 여러가지 것들을 해본 것 같습니다.

LLM 모델을 보안 목적으로 활용한 사례

현재 국내외 솔루션을 보면, 많은 솔루션이 기존의 루틴 중 특정 부분에 LLM을 붙여서 탐지 솔루션은 탐지율을 높이고, SOAR는 대응 프로세스 제작 가이드를 제공하거나 추천하는 식으로 진행되는 것 같습니다. 문제는 이러한 솔루션들이 SOTA 모델 활용을 기준으로 이루어지다보니 이로 인해 발생하는 토큰 비용 등의 문제가 지속적으로 이슈화되는 것 같습니다. 또한, 일부 솔루션은 LLM에게 “해줘”하는 형태의 구조 설계가 이루어지지 않았을까 싶은 생각도 들었습니다.

모델 후기

가용된 자원 내에서 테스트를 해야하다보니, 많은 모델을 테스트해보진 않았습니다. 모델의 경우 unsloth되어 있고 Q8이나 Q4로 Quantization된 모델로 활용했습니다. 일부 윤리적 방어를 무력화하도록 재학습된 모델도 써봤습니다만, 이러한 모델의 경우 Reasoning 성능 저하가 체감되어서 사용 안했습니다. 대략적으로 테스트해본 모델의 후기는 다음과 같습니다. (대부분 Q4, AWQ 기준)

기존 모델을 Opus 4.7 등으로 Distill처리한 모델의 경우 상대적으로 더 적은 Reasoning으로 좋은 답을 준다고 느꼈습니다. Gemma4 같은 경우에는 툴콜링 버그가 해결되었다고 하니 다시 한번 써볼까 하고 있습니다.

서빙(Serving)

LLM 모델 자체의 성능이 가장 중요하지만, 이를 서비스 형태로 제공해주는 서빙 프로그램도 매우 중요하였습니다. 보통 일반적으로는 로컬 LLM 서버로 ollama나 lm studio 등을 활용합니다. 혼자서 간단하게 여러 모델을 텥스트해보기에는 이러한 플랫폼도 괜찮습니다만, 여러 사람이 접근하거나 여러 에이전트가 동시 접근을 수행하는 경우에는 Queue 형태의 메시지로 인해 처리 속도가 급격하게 떨어진다는 느낌을 받았습니다. 또한 Attention 기법(Flash, Paged), Prediction(MTP, 또 최근에 뭐 있던데)도 서빙 프로그램에 따라 지원 여부가 달라졌습니다.

이러한 문제를 해결하기 위해 vLLM 플랫폼을 docker로 운영해보니 멀티 에이전트 처리 속도 향상 및 MTP 지원을 통한 tgs 향상 효과를 보았습니다. 또한 가끔씩 서빙 프로그램이 터져서 물리 메모리로 모델을 올리는 문제도 해결되었습니다.

최근에 보니 국내에서도 이러한 서빙 플랫폼을 제공하는 업체도 늘어나고 있으며, 각 HW에 맞게 최적화도 시켜주는 것을 보면 이러한 부분도 플랫폼 구축에 매우 중요한 요소가 되지 않을까 생각합니다.

LLM 모델을 활용하는 SW의 개발

LLM 은 문맥을 파악하는 능력과 설명하는 능력이 뛰어납니다만, Context Length의 제한이 있으며 LLM에게 데이터를 입력할 때 어떤 것이 중요한지 알려주지 않으면 전혀 이상한 방향으로 분석이 진행되는 경우가 발생합니다. 일반적인 소스코드 분석의 경우에는 크게 문제가 발생하지 않으나, 로그 분석이나 툴콜링 결과를 종합해서 전달하는 경우에 많이 발생합니다. 그래서 대부분 LLM 모델 활용 SW는 자체적인 자료형을 통해 중요한 데이터만 별도의 파일 포맷(보통 JSON)으로 정의하여 LLM에게 전달하여 분석하도록 합니다.

기본적으로 Context Length가 길면 많은 정보를 기억하기에 분석 성능의 향상되지만, 대부분의 Local LLM 모델은 256KB가 한계이며, 일부 1M length를 가지는 모델(GLM-5.2)이 있긴 하지만 모델의 크기가 커서 개인이 집에서 돌리기에는 한계가 있습니다. 즉, 우리는 LLM에게 작업을 전달할 때 제한된 Context Length 내에서 하나의 Task를 처리하도록 구성하는 것이 가장 낫다는 결론에 도달하게 됩니다. 데이터를 잘 쪼개서 LLM에게 처리를 시키고 그 결과를 잘 요약하여 저장한 후, 관련 데이터 처리 시 저장된 데이터를 전달하는 식으로 처리하는 것이 좋았습니다.

즉, 단순히 LLM에게 정보를 전달하고 처리하는 것보다는 분석가의 통찰력을 SW에 잘 녹여서 각 에이전트를 전문(Speacialist)화 시킬 수 있는 스킬 데이터를 만들고 오케스트레이터는 필요에 따라 이러한 전문화된 에이전트를 통해 분석하는 구조를 가져가야 합니다. (사실 대부분의 Multi Agent는 이러한 구성을 따라가고 있습니다.)

또한, 툴콜링을 통해 외부 도구에서 처리할 부분과 LLM의 강점을 이용하여 처리할 부분을 잘 분리해야 합니다. 예를 들어 웹 취약점 분석인 SQL Injection의 경우에는 인젝션을 위한 값 입력은 외부 도구를 활용할 수 있지만, Syntax Error나 DB 에러가 발생했을 떄의 메시지. 즉, Response 값에 대해서는 LLM에게 제공하여 Injection 공격을 위한 쿼리 구문을 최적화해볼 수 있습니다. Fuzzing의 경우에도 Fuzzing 과정에서 나타나는 대상 프로그램의 상태 정보를 토대로 Seed 값을 조정하는데도 활용할 수 있습니다.

SOTA 모델을 사용하는 것이 맞는지도 고민이 필요합니다. 당장에 LLM 모델의 성능이 좋으면 개떡같이 물어봐도 찰떡같이 반응할 확률이 높고 속도도 빨라서 많이 사용하고 있습니다만 최근 Fable 사태도 그렇고 각국에서 전략 자산으로 LLM 모델을 다룰 것 같은 예감이 들기도 하고 비용 문제도 존재하기에 솔루션은 기본적으로 로컬 LLM을 사용해야하고, 필요 시 옵셔널하게 SOTA 모델을 붙일 수 있도록 해야하는 것이 아닌가 싶습니다. (내일 Fable이 풀린다곤 하네요 ㅎㅎ)

그 외

드디어 16인치 맥북프로를 샀습니다. 인텔 맥북 때 15인치 쓰다가 그 이후에는 에어13→프로14+맥스튜디오→프로16+에어13(잠깐)→프로14 생활을 했는데, 결국 16인치로 돌아왔네요. 좀 더 무겁긴한데 화면이 시원시원하고 화면이 1000nits가 되어서 카페에서도 화면 빛반사가 확연히 줄어들어서 만족감이 큽니다. 어제 애플 아이폰 제외한 전제품 가격이 2-30%씩 올랐던데 그전에 사서 다행입니다. 14인치 모델이 MAX 칩셋의 64GB 램이라 가끔 LLM모델 테스트 용도로 쓰기 좋긴한데, 그 이유로 냅두기도 아까워서 어떻게 할지 고민 중입니다. ㅎㅎ

결론

주절주절 최근에 있던 일을 글로 썼습니다. 사실 블로그에는 항상 다른 곳에 없는 새로운 글을 써야한다는 생각이 있다보니 더 어려웠습니다. 앞으로는 저런 생각을 내려놓고 근황이나 조금이라도 도움이 될만한 내용(기술 정리)도 글을 써볼까 합니다.

Contents