김마늘의 테크 레시피

 지난 포스팅에서는 로딩/Prefill/Decode 구간을 나누어 각 구간의 성능을 측정하고 튜닝한 결과를 정리했습니다. 성능 측정에 사용한 스크립트는 매번 프롬프트 앞에 무작위 단어(nonce)를 붙였고, 그 이유에 대한 자세한 설명을 다음 포스팅으로 미루었습니다. 이번 포스팅에서는 그 이유와 함께 kagent 세션에서는 질문 간에 캐시가 왜 하나도 맞지 않았는지에 대한 원인을 추적하고, 원인이 된 버그 발견과 이를 수정한 PR이 merge 되기까지의 과정에 대해 적어 보겠습니다.

1. kagent 세션에서 비정상적으로 긴 Prefill 시간 발견

 kagent는 CNCF 샌드박스 프로젝트로, 쿠버네티스 환경에서 발생하는 장애와 이벤트를 감지하고, AI를 활용해 자율적으로 원인을 진단 및 복구하는 클라우드 네이티브 오픈소스 AI 에이전트 프레임워크로 여러 LLM을 백앤드로 하여 사용할 수 있습니다. 기존에 테스트 용도로 Google gemini 3.1 flash lite API를 붙여서 사용하다가 이번에 구축한 로컬 LLM을 붙여보기로 했습니다.

1.1 39,000 tokens/s가 어떻게 나왔나?

 3부의 측정 스크립트는 Ollama 응답에 담긴 입력 토큰 수(prompt_eval_count)를 Prefill 시간(prompt_eval_duration)으로 나눠 Prefill 속도를 구했습니다. 여기서 입력 토큰 수는 캐시에서 재사용한 토큰까지 센 입력 전체의 크기를 의미하지만, Prefill 시간은 캐시에 없어서 새로 계산 한 부분의 시간만을 측정합니다. 같은 프롬프트를 두 번 보내면 두 번째 요청은 대부분을 캐시에서 가져오므로, Prefill 시간이 거의 없게 되고, 이를 입력 전체로 나누게 되니 비약적으로 빠른 속도(39,000 tokens/s)로 계산이 되는 것입니다.

 그래서, 설정에 따른 Prefill 속도를 측정할 때에 그 값이 캐시 히트 효과로 인해 결과가 왜곡 될 수 있어 매번 nonce를 붙여 프롬프트의 앞부분을 다르게 만들었습니다. 그럼 프롬프트의 앞부분만을 다르게 하고 그 뒤가 같으면 어떻게 되는지 의문을 가질 수 있는데, 이는 뒤에 나오는 lcp 개념과 함께 설명하겠습니다.

1.2 질문 하나에 모델을 여러번 호출하는 kagent의 작동 방식

 kagent를 통해 사용자가 질문을 하나 하면, kagent 안에서는 대략 아래와 같은 일이 반복됩니다.

질문 입력
  → [모델 호출 1] 모델이 답 대신 "k8s_get_resources 도구를 이 인자로 실행해 달라"고 응답
  → kagent가 도구를 실행하고, 그 결과를 대화에 덧붙임
  → [모델 호출 2] 모델이 도구 결과를 읽고 다른 도구를 요청하거나 최종 답변을 생성
  → ... 최종 답변이 나올 때까지 반복

 kagent에서 이 반복(모델 호출과 도구 실행)을 수행하는 부분을 에이전트 런타임이라고 부릅니다. kagent에서는 에이전트 런타임을 파이썬과 Go로 구현해 두었고 이 둘중 하나를 선택해서 사용할 수 있습니다.(최신 v1.0 업데이트부터는 Go 런타임 에이전트만을 사용하는 것으로 선회한 것으로 파악)

 어쨌든, 위의 내용을 보면 질문이 하나여도 모델은 도구를 쓰는 횟수만큼 더 호출됩니다. 그리고 2부에서 언급했듯, 모델 서버는 이전 호출을 기억하지 않습니다. 그래서 kagent는 모델을 부를 때마다 시스템 프롬프트, 사용할 수 있는 도구의 목록과 사용법(도구 정의), 지금까지의 대화와 도구 실행 결과를 모두 한 요청에 담아 보냅니다. 그래서 호출할 때마다의 입력은 직전 입력 뒤에 새로운 내용을 조금 더 붙이는 형태가 됩니다. 앞부분이 매번 같다면, 2부에서 이야기한 Prefix Caching이 가장 큰 효과를 낼 수 있는 형태로, 캐시가 적중한 앞부분을 제외한 새로 붙은 도구 결과만을 계산(Prefill) 하면 됩니다.

[모델 호출 1]  [시스템 프롬프트][도구 정의][질문]
[모델 호출 2]  [시스템 프롬프트][도구 정의][질문][도구 호출 1][도구 결과 1]
[모델 호출 3]  [시스템 프롬프트][도구 정의][질문][도구 호출 1][도구 결과 1][도구 호출 2][도구 결과 2]

1.3 질문 6개를 처리하는데 38분이 걸린 세션

 그런데, 실제로 kagent에서 Go 에이전트 런타임을 사용하여 테스트 세션을 하나 돌려보니 질문 6개에 약 38분이나 걸렸습니다. 처음에는 성능이 낮은 하드웨어를 기반으로한 모델이라 느린 게 당연하다 생각했습니다. 그러면서 로그를 분석해 보았는데 질문 마지막 호출에 토큰이 28,315개 인 것을 확인했습니다. 아무리 느리다 해도 이건 너무 비정상적이라는 생각이 들었습니다. 그래서 Ollama 로그를 전체 분석해 보기로 합니다.

 도구 결과가 붙을 때 마다 입력이 수천 토큰씩 늘어났습니다. 세 번째 질문에서는 도구 호출이 인자 형식 오류로 여러 번 실패하면서, 모델이 오류를 읽고 다시 도구를 호출하는 일이 반복되면서 모델 호출이 여섯 번이나 되었습니다. 그래서 6번의 질문 동안 모델은 총 19번이 호출되었으며, 총 처리 시간 38분에서 Prefill이 1,453초(전체 시간 대비 약 64%), 답변 생성이 809초(약 36%)를 차지했습니다. 앞선 테스트에서는 Prefill 속도가 답변 생성 속도보다 약 9~10배 정도 빨랐기 때문에, 대부분 답변 생성이 시간을 오래 잡아먹었을 것이라 예상하였는데 오히려 Prefill 시간이 더 걸리는 반대의 결과가 나왔습니다.

1.4 캐시가 동작했다면 걸렸을 시간

 2부에서 정리한 것처럼 Prefix Caching이 동작했다면 이전 대화는 캐시에서 재사용하고, 새로 붙은 부분만을 계산해야 했습니다. 새로 붙은 부분을 모두 더한 것이 마지막 입력 토큰의 길이가 되므로, 이 세션의 Prefill은 모두 합해도 마지막 입력 토큰 전체를 한번 읽는 시간 정도가 되어야 한다고 생각했습니다.

 그러나 결과는 캐시가 전혀 적중하지 않은 경우에 대한 결과로 해석할 수 밖에 없었습니다. 앞선 표의 총 19번 호출에 대해서 입력 토큰 수를 모두 더하면 338,379 토큰이고, 이것을 앞선 3부에서 측정한 긴 프롬프트 토큰 Prefill 속도인 대략 230 tokens/s 정도로 나누면 약 1,470초 정도가 나옵니다.

 실제 Prefill 시간은 캐시가 동작할 때 예상의 12배 수준이었으며, 캐시가 전혀 적중하지 않을 때의 예상과 거의 일치했습니다.

  1.3의 표를 그래프로 그려보면 위와 같습니다. 캐시가 적중했다면 Prefill 시간에는 새로 붙은 부분을 계산하는 시간만 들어가므로, Prefill 속도는 일반적인 Prefill 속도보다 한참 높은 수천 ~ 수만 tokens/s가 나와야 합니다. 그런데 이번 세션에서는 206 ~ 309 tokens/s였고 이는 3부에서 입력 토큰 4.8k에 351 tokens/s, 28k에 235 tokens/s와 비슷한 수준이었습니다. 즉, 호출할 때마다 입력 전체를 처음부터 다시 읽고(Prefill) 있었다는 뜻으로 해석할 수 있습니다.

1.5 로그를 더 들여다 보기

 kagent에서는 모델이 응답에 사용한 토큰 수에 대한 로그가 남지 않습니다. 그래서 해석이 정말 맞는지 알아보기 위해 Ollama 로그를 더 살펴 보았습니다. 캐시의 적중 정도를 보기 위해서는 아래 3가지 항목을 확인하면 됩니다.

# 이번 요청에서 캐시에서 재사용한 토큰 수
cached n_tokens = 0

# 재사용할 수 있는 것이 없어 처음부터 다시 계산
forcing full prompt re-processing due to lack of cache data

# 저장해 둔 이전 요청과 앞에서부터 같은 토큰 수
prompt with length 5562, lcp = 206

 특히 세번째 줄의 lcp(longest common prefix)는 이전 캐시의 토큰 배열과 현재 입력된 토큰의 배열을 앞에서부터 비교해 처음으로 달라지기 직전까지의 같은 토큰의 수를 나타내는 값입니다. 예를 들어 토큰의 배열이 [A B C D]가 있고 [A B D C]가 있다면 lcp는 2가 됩니다. 그래서 이 lcp 값이 Prefix Caching이 재사용할 수 있는 최대 길이가 되는 값이며, 위 로그에서는 서버에 저장해 둔 이전 요청(5,562 토큰)과 이번 요청이 앞 206 토큰까지 그 길이가 같다는 뜻입니다.

 찾아본 19번 모두 cached n_tokens=0(이번 요청에서 캐시에서 재사용한 토큰 수)이었고, forcing full prompt re-processing(재사용 할 수 있는 것이 없어 처음부터 다시 계산을 의미)이 19번 모두 찍혀 있었습니다. 앞선 해석이 맞는 순간입니다.

 여기서 한 가지 이상한 점이 있습니다. 앞에서부터 206 토큰은 같았는데 왜 재사용 토큰 수가 0일까요? 이는 qwen 3.6 모델의 독특한 구조(Gated DeltaNet과 Gated Attention이 섞인 하이브리드 구조)로 나타나는 현상으로 Gated DeltaNet 레이어는 KV Cache를 쌓는 대신 고정된 크기의 상태를 계속 덮어쓰도록 작동하는데, 이 때문에 계산을 특정 토큰 위치로 되돌릴 수 없습니다. 그래서 서버는 Prefill 중간중간 상태를 저장해 둔 체크포인트라는 것을 남기게 되고 이 체크포인트로만 되돌아갈 수 있습니다.

 위 그림에서 볼 수 있듯 첫 체크포인트가 lcp 206보다 한참 멀리 떨어져있고, 이번 요청이 이전 요청과 토큰의 배열이 같은 구간은 206까지 이니 되돌아갈 체크포인트가 206 이전에는 없어서 19번의 요청 모두에서 처음부터 다시 계산되었던 것입니다. 일반적인 모델이어다면 206 토큰을 재사용했겠지만, 입력 전체에 비하면 작은 양이라 Prefill 시간에 큰 차이는 없었을 것입니다.

2. 요청의 앞부분은 어디서 달라지는가?

2.1 요청마다 다른 lcp 값

 이번에는 매 요청에 대해서 앞부분이 어디서부터 달라지는지를 살펴 보았습니다. Ollama 로그의 lcp 값은 아래와 같았습니다.

prompt with length 5562, lcp =  206
prompt with length 8046, lcp =  206
prompt with length 5562, lcp = 1400
prompt with length 8337, lcp = 1400

 앞에서 206 토큰까지만 같을 때도 있고, 1400 토큰까지 같을 때도 있었습니다. 만약 요청 시각처럼 매번 바뀌는 값이 시스템 프롬프트에 들어가 있었다면 항상 같은 위치에서 달라졌을 텐데, lcp가 206과 1,400 두 가지로 나온다는 것은 요청마다 토큰 배열이 어긋나는 위치가 변한다는 것을 어떻게 해석해야 할지 도무지 감이 잡히지 않았습니다.

2.2 무엇이 이런 문제를 일으키나?

 Ollama 로그를 거슬러 올라가 보니, 캐시가 적중했던 기록도 있었습니다. 재사용 토큰이 5,530 → 29,420 → 43,578 → 73,211로 대화가 진행됨에 따라 늘어나는것을 확인했습니다. 재사용 토큰이 늘어나던 때는 파이썬 런타임을 쓰고 있을 때였고, Go 런타임을 쓸때는 재사용 토큰이 0이 된다는 것을 발견하게 됩니다. 도대체 Go 런타임에 무슨 문제가 있는 걸까요?

2.3 후보 좁히기

 요청 앞부분에 들어가는 것 중 요청마다 바뀔 수 있는 것의 후보를 추리고 하나씩 확인했습니다.

 위 후보 중 요청마다 순서가 바뀔 수 있는 것은 맵에 담긴 도구별 파라미터가 유일했습니다. 아무래도 여기가 의심스러워집니다.

3. Go 맵은 순서를 보장하지 않는다!

3.1 언어의 기본 동작

 Go 언어의 명세에는 맵의 순회 순서에 대해서 이렇게 적혀 있습니다.

The iteration order over maps is not specified and is not guaranteed to be the same from one iteration to the next.
(맵의 순회 순서는 정해져 있지 않으며, 한 번의 순회와 다음 순회의 순서가 같다는 보장도 없다.)

Go는 1.0부터 맵에 순서를 사용하지 못하도록, 같은 맵을 같은 코드로 순회해도 순서를 예측할 수 없도록 했습니다. 파라미터가 5개짜리 맵을 다섯 번 순회해 본 예시입니다.

props := map[string]string{
    "project": "project slug",
    "family":  "change family",
    "bucket":  "severity bucket",
    "since":   "lower bound",
    "limit":   "max rows",
}
for i := 1; i <= 5; i++ {
    fmt.Print(i, ": ")
    for name := range props {
        fmt.Print(name, " ")
    }
    fmt.Println()
}

# go 1.25로 실행한 결과
1: project family bucket since limit
2: project family bucket since limit
3: since limit project family bucket
4: project family bucket since limit
5: since limit project family bucket

# 한 번 더 실행
1: project family bucket since limit
2: project family bucket since limit
3: project family bucket since limit
4: project family bucket since limit
5: family bucket since limit project

 결과를 보면 원래 순서에서 시작 위치만 달라지고, 그 뒤는 원래 순서대로 이어지는 것을 확인할 수 있습니다. 즉, 맵의 순회 시작 위치를 무작위 정하는 것입니다.

 반면 파이썬의 dict는 3.7부터 넣은 순서를 그대로 유지하는 것이 언어 명세로 보장됩니다.

3.2 kagent의 변환 코드

 MCP 서버가 주는 도구 정의는 JSON 텍스트입니다. 그래서 파라미터가 적힌 순서가 정해져 있습니다. 그런데 kagent의 Go 런타임 코드를 보면, 이 파라미터를 맵에 담아 다루기 때문에 이 단계에서 그 순서가 사라져 버립니다! kagent는 도구 정의를 Ollama 형식(JSON)으로 바꿔서 요청을 넣는데 그 요청 변환 Go 런타임의 변환 코드는 아래와 같습니다.

// kagent Go 런타임: 도구 정의를 Ollama 형식으로 바꾸는 부분
for name, propAny := range props {        // Go 맵을 순회: 순서가 매번 다르다
    ...
    params.Properties.Set(name, prop)     // 넣은 순서를 그대로 유지하는 구조에 저장
}

 for문 안의 params.Properties.Set(name, prop)은 Ollama 형식으로 만드는 도구 파라미터(params)의 Properties에 파라미터 하나를 추가하는 메서드 호출입니다. Properties의 타입은 kagent가 가져다 쓰는 Ollama Go 패키지의 ToolPropertiesMap으로, 파이썬의 dict처럼 넣은 순서를 유지하는 맵입니다. Go 언어 표준 라이브러리에는 순서를 유지하는 key-valude 타입의 자료형이 없어서 Ollama는 외부 라이브러리(go-ordered-map)를 이용해 이 타입을 정의해 두었습니다.

 즉, 이 코드는 순서가 없는 Go 맵(props)에서 파라미터를 하나씩 꺼내, 순서를 유지하는 맵에 넣고 있었습니다. 꺼낼 때마다 순서가 달라지니 ToolPropertiesMap에 들어간 순서도 요청마다 달라졌고, Ollama로 보내는 요청에도 달라진 순서 그대로 전달되었습니다. 오히려 받는 쪽이 Go의 보통 맵이었다면 encoding/json이 JSON으로 바꿀 때 맵의 키를 이름순으로 정렬하므로 매번 같은 결과가 나왔을 것입니다.

3.3 파라미터 순서와 Prefix Caching

 파라미터 순서만 바뀐 두 도구 정의가 요청에 실리는 형식을 단순화한 예시를 보면 아래와 같습니다.

요청 1: {"name":"list_changes","parameters":{"properties":{"project":…,"family":…,"bucket":…,"since":…,"limit":…}}}
요청 2: {"name":"list_changes","parameters":{"properties":{"since":…,"limit":…,"project":…,"family":…,"bucket":…}}}

 JSON 명세(RFC 8259)에서 객체는 순서가 없는 이름/값 쌍의 모음이기 때문에, 데이터로 보면 위의 두 요청에서의 도구 정의는 서로 같은 것으로 볼 수 있습니다. 하지만 Ollama는 요청을 텍스트로 받기 때문에 이 JSON 형식으로 되어 있어도 그 순서가 다르면 토큰의 배열도 달라 서로 다른 요청이 되어 버립니다. 2부에서는 이 부분을 아래와 같이 정리했습니다.

다만 동일하다는 기준은 "뜻이 비슷하다"가 아닙니다. 일반적인 Prefix Caching은 앞에서부터 이어지는 실제 토큰 배열이 일치하는 구간을 재사용합니다.

 그런데 하필이면 순서가 바뀔 수 있는 도구 정의가 LLM에게 요청하는 텍스트의 거의 맨 앞에 들어갑니다. 그래서 첫 호출에 Go 맵에서 추출되어 순서가 고정되어 버린 도구 정의를 텍스트로 입력받은 LLM 서버가 첫 번째 프리필에서 Prefix Cache를 생성해 두었지만, 그 다음 호출에서는 Go 맵의 추출 과정에서 도구 정의의 순서가 변하면서 이를 텍스트로 입력받은 LLM 서버 입장에서는 토큰 배열이 변했다고 판단하고, 그 앞에 위치한 체크포인트부터 다시 Prefill 계산을 하는 현상이 발생했던 것입니다.(그런데 lcp의 위치가 너무 초반이라 첫번째 체크포인트를 지나지 못했기 때문에 Prefill을 다시 모두 처음부터 진행할 수밖에 없었던 것입니다.)

3.4 테스트 조건에서 Prefix Caching이 성공할 확률

 당시 에이전트에 연결된 도구는 9개였고, 그중 8개가 파라미터를 두 개 이상 가지고 있었습니다.(파라미터 2개인 도구 3개, 3개인 도구 3개, 5개인 도구 2개) 앞서 보았든 Go 맵은 그 구성 요소가 n개이면 n가지 순서가 나오므로 각 도구의 파라미터 수를 모두 곱하면 2×2×2×3×3×3×5×5 = 5,400가지가 나올 수 있었습니다. 따라서 19번 중에 한 번도 적중하지 않은 것이 너무나도 당연한 결과였습니다.

4. 해결

4.1 다시 파이썬 런타임으로 교체

 원인을 파악한 뒤 에이전트를 다시 파이썬 런타임으로 변경하고, 같은 질문 6개로 세션을 다시 돌려 보았습니다.

 위 표에서 알 수 있듯 처음부터 다시 계산하는 경우는 완전히 사라졌습니다. Prefill 시간 합계도 확연히 감축되었고, Go 런타임에서 세 번째 질문에서 발생하던 인자 형식 오류도 사라져서 14번의 모델 호출만 하게 되었습니다. 하지만, 문제의 Go 에이전트의 원인을 이미 파악해서 PR을 올리기로 했습니다.

4.2 PR - 이름을 정렬해서 Go map 생성할 수 있도록 수정

 Go 런타임을 고치는 방법은 간단했습니다. 파라미터 이름을 정렬한 뒤 그 순서대로 넣어 주도록 했습니다.

// 수정 전: 맵에서 이름과 값을 함께 꺼낸다 (꺼내는 순서가 매번 다르다)
for name, propAny := range props {
    if propMap, ok := propAny.(map[string]any); ok {
        ...

// 수정 후: 이름만 뽑아 정렬한 뒤, 그 순서대로 값을 찾는다
for _, name := range slices.Sorted(maps.Keys(props)) {
    if propMap, ok := props[name].(map[string]any); ok {
        ...

 수정의 주요 내용은 먼저 maps.Keys(props)로 props에서 Key, 즉 파리미터 이름만을 꺼내어가 slices.Sorted를 통해 이름순으로 정렬하여 슬라이스로 돌려주도록 한 것입니다. 이렇게 하면 이름순으로 순서가 고정되어 Ollama에 입력되는 요청 텍스트의 초반 부분 변화가 없게 되어 Prefix Caching을 노릴 수 있게 됩니다.

 이를 PR로 올려 kagent-dev/kagent#2693으로 등록되어 9월 8일 머지되었으며, kagent v1.0.0-alpha1 릴리스에 포함되었습니다.

4.3 v1.0에서 다시 돌려보고 확인한 두 번째 버그 - 도구 호출 인자에서 동일한 문제 발견

 PR이 머지된 후, kagent v1.0.0 alpha 버전을 Go 런타임으로 같은 질문 6개를 다시 돌려 보았습니다. 도구 정의 부분은 고쳐졌습니다. 실제로 시스템 프롬프트와 도구 정의를 합친 약 5.5천 토큰은 14번의 호출에서 모두 같았습니다. 그런데 질문을 처리하는 중간 호출들이 여전히 8,145 ~ 8,254 토큰 부근에서 달라지는 것을 발견하게 됩니다. 대화에서 처음으로 도구 호출(k8s_get_resources)이 들어간 지점이었습니다.

 원인도 도구 정의 때와 같았습니다. kagent는 모델이 요청한 도구 호출도 대화 이력에 넣어서 보내는데, 이때 호출 인자를 또다시 Go 맵에서 꺼내어서 Ollama 요청 텍스트로 사용하고 있었습니다.

// kagent Go 런타임: 대화 이력 속 도구 호출을 Ollama 형식으로 바꾸는 부분
for k, v := range part.FunctionCall.Args {    // Args: 호출 인자를 담은 Go 맵. 꺼내는 순서가 매번 다르다
    toolCall.Function.Arguments.Set(k, v)     // 꺼낸 순서대로 ToolCallFunctionArguments에 추가
}

 part.FuctionCall.Args는 모델이 이전에 요청했던 도구 호출의 인자(인자 이름과 값)를 담는 Go 맵입니다. 코드는 이것을 Ollama로 보낼 도구 호출에서 인자 필드(toolCall.Fuction.Arguments)에 옮겨 담는데, 이 필드의 타입이 ToolCallFunctionArguments로 ToolPropertiesMap처럼 Ollama 패키지에 들어있는 입력한 순서를 유지하는 맵(ordered map)입니다.

 이번에는 첫 번째 체크포인트를 지난 이후에 나타난 현상이라 첫번째 체크포인트인 5,502 토큰부터 다시 Prefill을 계산하는 모습을 보였습니다.

 고치는 방법도 앞과 같아서, 인자 이름을 뽑아 정렬하고 그 순서대로 값을 찾아 넣게 하였습니다. 이는 PR kagent-dev/kagent#2988로 요청하여 9월 28일 머지되었습니다.

 이후 같은 질문 6개를 세 가지 조건으로 돌려 보았습니다. 모델의 답이 매번 달라서 조건마다 모델 호출 횟수와 대화의 크기가 다르기 때문에 세션 전체 시간 대신 질문 처리 중 호출만 모아 요청을 단위별로 비교해 보았고 그 결과는 아래와 같습니다.

 캐시가 제대로 작동하면 이전 질문 대비 새로 붙은 내용에 대해서만 토큰을 처리하면 되므로 B ÷ A는 1에 가까워져야 합니다. 수정 없음 조건에서는 호출 20번을 모두 처음부터 다시 계산했고, 앞부부니 달라지는 위치도 요청마다 재각각이었습니다. #2693을 적용하고 나서는 처음부터 다시 계산하는 호출은 1번으로 줄었습니다. 단 #2693도 캐시가 깨지면 체크포인트부터 다시 읽으면서 질문 처리에 읽은 토큰 양이 새로 붙은 양 대비 약 4.4배였습니다. 두 버그가 모두 해결되고 난 후(#2693 + #2988)에는 Cache가 거의 적중하여 질문 처리 중 토큰을 다시 읽은 양과 새로 붙은 양이 거의 같아졌습니다.

5. 마치며

 이번 포스팅에서는 kagent의 요청에서 캐시가 한 번도 적중하지 않았던 원인을 추적한 과정을 정리해 보았습니다. 원인은 kagent Go 런타임이 도구 정의를 만들 때 Go 맵을 순회한 순서대로 파라미터를 넣은 데 있었고, 파라미터 이름을 정렬하도록 몇 줄을 고쳐 해결했습니다. 고친 뒤 1.0에서 다시 돌려 보니 대화 이력 속 도구 호출 인자에서도 순서가 바뀌는 버그를 하나 더 발견했고, 똑같이 이름을 정렬하는 방법(#2988)으로 고쳤습니다.

 정리하면서 가장 크게 느낀 것은, 이 버그에 관련된 동작이 각각은 모두 정상이었다는 점입니다. Go의 맵이 순서를 보장하지 않는 것은 언어 명세대로의 동작이고, 넣은 순서를 지키는 Ollama의 구조나 토큰 배열이 같은 구간만 재사용하는 Prefix Caching도 설계대로 동작했습니다. 그런데 이 동작들이 교묘하게 상호작용 하면서 캐시를 무효화하고 있었습니다.

 Ollama 로그로는 요청의 앞부분이 매번 다른 곳에서 달라진다는 것까지만 확인할 수 있었고, 그 이유는 Go 맵의 순회 순서를 알고 나서야 설명할 수 있었습니다. Go 코드만 봤다면 순서가 바뀌는 것이 왜 문제인지 알기 어려웠을 것이라, 언어의 기본 동작과 LLM이 입력을 처리하는 방식을 함께 보아야 찾을 수 있는 문제였다고 생각합니다.

 이번 시리즈 포스팅을 통해 LLM의 기본 동작과 개념들 정리할 수 있었습니다. 또한 하드웨어 제약 속에서 로컬 LLM을 구동 및 성능을 위한 여러 가지 튜닝, 그럼에도 불구하고 넘을 수 없었던 물리적인 한계까지 많은 것을 얻어갈 수 있는 시간이었습니다.

 지금까지, 긴 글 읽어주셔서 감사합니다.

 지난 포스팅에서는 요청 하나가 답변이 되기까지의 과정을 자세하게 따라가며 여러 가지 개념과 정의를 이해하는 시간을 가져보았습니다. 이를 통해 "느리게" 답변이 생성되는 현상도 "미니 PC의 성능이 낮아서 그렇다"라고 단순하게만 볼 것이 아니라, 어느 구간에서 병목이 생기는지(모델을 로딩하는 구간, 입력을 처리하는 Prefill 구간, 답변을 생성하는 Decode 구간을 분리해서 분석)를 가늠해볼 수 있는 이론적인 토대를 닦았습니다.

 또한, 실제로 모델은 처리해야 하는 토큰의 길이에 따라 성능 거동 양상이 다르게 나타납니다. 1부 말미에 짧은 질문은 겨우 24 토큰이었지만, kagent가 보내는 요청은 시스템 프롬프트와 도구 정의, 이전 대화와 도구 실행 결과가 모두 합쳐져 4.4만 ~ 4.8만 토큰에 달했습니다. 이를 처리하는데에만 6분 가까이 걸린 구간도 있었고, 대화가 길어지면서 GPU가 멈춰버리는 현상도 발생했습니다. 어느 구간에서 시간을 많이 소비했는지, 어디가 GPU를 멈추게 했는지 등을 추적하기 위해서는 로딩/Prefill/Decode 구간을 분리해서 병목을 찾아내야 합니다.

 이번 포스팅에서는 모델이 처리해야하는 토큰의 크기에 따라 각 구간의 성능이 어떻게 변화하는지를 살펴보고, 제가 구성한 로컬 환경에 맞는 최적의 값을 찾기 위해 마지막 한방울까지 쥐어짜는 극한의 튜닝을 위한 테스트와 그 결과를 다뤄보고자 합니다.

1. 신뢰할 수 있는 수치를 위한 측정 방법과 원칙

 튜닝에 대해서 이야기하기 전에 측정 방법부터 살펴보겠습니다. 설정을 바꾸고 "성능이 향상되었다"라고 결론을 내기 위해서는 측정 결과를 믿을 수 있어야 합니다. 처음 로컬 LLM을 다뤄보다 보니 측정 결과를 몇 번 잘못 해석하는 실수가 있었어서 이 부분부터 잡고 가겠습니다.

1.1 운영 로그 비교의 함정

 처음에는 kagent가 보낸 요청들의 로그를 보고 설정 간 성능을 비교했습니다. 뒤에 다룰 num_batch라는 설정을 2048에서 512로 변경하고, 입력 길이가 비슷한 두 요청을 보냈더니 아래와 같은 결과를 얻었습니다.

# num_batch == 2048, 입력 길이 약 2만 8천 토큰
2,048토큰 처리에 24.0초 소요  →  약 85 tokens/s

# num_batch == 512, 입력 길이 약 2만 9천 토큰
512토큰 처리에 2.16초 소요  →  약 237 tokens/s

 입력 길이가 비슷한데 설정을 하나 바꾼것이 약 2.8배 정도 빨라진 것처럼 보였습니다. 그러나 num_batch를 조절하면서 같은 프롬프트(32,703 토큰)로 모델을 매번 새로 돌려가면서 Prefill 속도를 측정하니 아래와 같은 결과를 얻을 수 있었습니다.

 로그와 실제 측정이 이렇게 차이가 많이 나는 이유는 앞의 두 로그의 경우, 세션에서의 캐시 상태나 주변 요소가 모두 다른 상황에서 나온 값이기 때문으로, 이후에는 운영 로그를 기준으로 하는 것이 아닌, 측정 방법에 원칙을 정하고 그에 맞추어 측정하였습니다.

 1.2 측정의 원칙

 위의 원칙을 코드로 옮긴 측정 스크립트의 대략적인 골자는 아래와 같습니다. Ollama API를 직접 호출하고, 응답에 포함되어 있는 prompt_eval_count, prompt_eval_duration, eval_count, eval_duration으로 속도를 계산했습니다.

# Prefill: 약 4,760토큰짜리 프롬프트 앞에 매번 다른 무작위 단어 12개(nonce)를 붙여 캐시를 무효화
x = call(prompt=nonce + " " + body, options={"temperature": 0, "num_predict": 1, "seed": 42})
prefill = x["prompt_eval_count"] / (x["prompt_eval_duration"] / 1e9)

# Decode: 짧은 고정 프롬프트로 171토큰 생성 (temperature 0이라 매번 같은 답)
x = call(prompt="Count slowly from one to sixty, one number per line.",
         options={"temperature": 0, "num_predict": 200, "seed": 42})
decode = x["eval_count"] / (x["eval_duration"] / 1e9)

# 로드: 모델을 내렸다가(keep_alive=0) 다시 올리며 load_duration을 잰다
call(prompt="", keep_alive=0)
x = call(prompt="hi", options={"num_predict": 1}, keep_alive=-1)
load = x["load_duration"] / 1e9

 측정 전에는 GPU가 유휴 상태인지도 확인합니다. 현재 설정에서 슬롯이 하나라, 측정 중에 다른 요청이 들어오면 측정에 영향을 주기 때문입니다.

# GPU 사용률이 0인지 확인
cat /sys/class/drm/card*/device/gpu_busy_percent
0

1.3 nonce를 붙이는 이유

 같은 프롬프트를 nonce 없이 두 번 보내면 두 번째 Prefill이 약 39,000 tokens/s로 측정됩니다. 이는 2부에서 설명한 Prefix Caching의 결과입니다. 캐시가 맞으면 Prefill을 거의 하지 않는 것과 같습니다. 자세한 내용은 다음 포스팅에서 다루겠습니다.

2. 로딩 - 첫 요청에 모델을 메모리로 불러오는 시간 6초 ~ 7초

 세 가지(로딩/Prefill/Decode)중 가장 간단한 것부터 보겠습니다. 모델을 GPU 메모리에(우리의 경우에는 시스템 메모리 중 GTT) 올리는 시간은 약 6초 ~ 7초 정도였습니다. 1부에서 OLLAMA_KEEP_ALIVE=-1로 한번 올린 모델을 내리지 않도록 설정해서 모델을 최초 로딩하는 경우가 아니면 그 비용이 거의 0인 구간입니다.

 이번 포스팅의 경우에는 단일 모델을 가지고 하는 테스트이고, 모델의 크기도 크지 않아 그 시간이 크게 의미가 없으나, 만약 큰 모델 여러가지를 서빙하는 환경이라면 이 부분도 고려해 볼 가치가 있겠습니다. 다만, 우리의 경우에는 로딩 구간보다 Prefill 구간이 문제였습니다.

3. Prefill - 입력을 처리하는 시간

3.1 GPU 담당 구간

 2부에서 Prefill은 이미 주어진 입력 토큰들을 한꺼번에 모델에 통과시는 단계라고 정리했습니다. 수백 개의 토큰을 묶어서 계산하기 때문에, 메모리에서 가중치를 한 번 읽어 와 여러 토큰에 재사용할 수 있습니다. 그래서 이 구간에서는 메모리 대역폭보다 연산 장치(GPU 또는 CPU)의 계산 능력이 속도를 좌우하게 됩니다. 테스트 환경에서 GPU를 사용하는 경우와 CPU를 사용하는 경우(num_gpu: 0)을 비교해 보면 아래와 같은 결과를 확인할 수 있습니다.

# 요청 옵션으로 GPU에 올릴 레이어 수를 0으로 주면 CPU만 쓰는 러너가 다시 뜬다
curl -s localhost:11434/api/generate -d '{
  "model": "qwen3.6:35b-a3b", "prompt": "hi", "stream": false,
  "options": {"num_gpu": 0}
}'

# 러너 인자에 -ngl 0이 들어갔는지 확인 (나머지 인자는 GPU일 때와 같다)
$ tr '\0' ' ' < /proc/$(pgrep -x llama-server)/cmdline
... --flash-attn auto -b 512 -ub 512 -ngl 0 --context-shift --keep 4

 Prefill은 입력 토큰의 크기와 관계없이 GPU가 CPU 대비 3배 넘게 빨랐습니다. 단, 절대적인 속도는 입력 토큰의 크기가 클수록 느려지는 모습을 보입니다. 입력 크기에 따른 상관관계는 바로 다음 챕터에서 더 자세하게 확인할 수 있습니다.

3.2 입력 토큰이 클수록 느려지는 속도

 1부의 마지막 질문처럼 입력 토큰이 작을때는 Prefill이 금방 끝나게 됩니다. 하지만 kagent의 요청처럼 입력 토큰이 크면 그 양상이 완전히 달라집니다. Attention은 새로 들어온 토큰마다 앞의 모든 토큰을 참조해야 하기 때문에, 입력이 길수록 토큰 하나를 처리하는 비용이 커집니다. 아래는 같은 조건에서 입력의 길이만 바꿔 가며 측정한 결과입니다.(이번 측정에도 매번 앞에 무작위 단어를 붙여 캐시를 무효화하였습니다.)

 표의 Prefill 속도는 입력 전체를 처음부터 처리했을 때의 평균입니다. 입력이 2.8만 토큰에서 6.6만 토큰으로 두 배 조금 넘게 늘자 속도는 235 tokens/s에서 139 tokens/s로 약 0.6배가 되었고, 4.3만 토큰에서 9.5만 토큰으로 늘 때는 약 0.55배가 되었습니다. 입력 토큰 크기가 2배가 되면 Prefill 속도는 대략 1/2가 되는 양상을 보였습니다. 약 11.9만 토큰을 캐시 없이 처음부터 처리하면 현재 제가 가진 미니 PC로는 23분이나 걸리게 됩니다.

3.3 num_batch란 무엇인가?

 1부에 ollama show로 모델 정보를 확인했을 때 Paramaters 목록에 num_batch 512가 있었습니다. 이것은 Prefill 때 입력을 몇 토큰씩 묶어 GPU에 넣을지를 나타내는 값을 의미합니다. 배치 숫자가 클수록 GPU의 연산 유닛을 동시에 더 많이 쓰게 되고 따라서 GPU가 한 번에 처리해야 하는 계산량도 커집니다.

# Modelfile
FROM qwen3.6:35b-a3b
PARAMETER num_batch 512

# 같은 이름으로 다시 만들면 기존 태그에 파라미터가 더해진다
docker exec -i ollama ollama create qwen3.6:35b-a3b -f - < Modelfile

 Ollama에서는 이 값을 서버 전체에 적용하는 환경 변수가 없어서, 위 예시처럼 모델 태그에 직접 넣어주어야 합니다. 다만 이렇게 넣은 값은 ollama pull로 모델을 다시 받으면 사라지므로 주의가 필요합니다.

 num_batch의 값을 통해 배치 크기를 바꿔 가며 작은 토큰 입력과 큰 토큰 입력에 대해 각각 Prefill 속도를 측정해 보았습니다. 결과는 아래 표와 같습니다.

 여기가 정말 특이한 구간인데, 입력 토큰이 작은 경우(짧은 입력)에는 배치가 클수록 Prefill 속도가 빨랐고, 입력 토큰이 큰 경우(긴 입력)에는 512가 가장 빨랐고, 2048은 오히려 10% 정도 느려졌습니다. 왜 이런 현상이 일어나는지는 아직 특정하지 못했습니다.

 어쨌든, 로컬 LLM 모델을 어떤 작업에 쓰느냐에 따라 배치 크기를 적절히 조절해서 사용하는 것이 유리해 보였습니다. kagent와 같이 대부분의 요청이 수만 토큰 단위인 경우에는 배치 크기를 512로 하는 것이 유리할 것이고, 요청의 크기가 작은 다른 용도로 사용한다면 배치 크기를 키우는 것이 성능상 더 유리해 보였습니다.

3.4 GPU 워치독 - 커널 드라이버의 안전장치

 kagent로 테스트를 진행하면서, 한 세션에서 대화가 길어지면 GPU가 멈추고 요청이 실패하는 일이 반복되었습니다. 원인은 amdgpu 커널 드라이버의 워치독(watchdog)이었습니다. 워치독은 GPU에 보낸 작업 하나가 정해진 시간(기본값 2초) 안에 끝나지 않으면, GPU가 멈췄다고 판단하고 리셋합니다. GPU는 앞 작업이 끝나야 다음 작업을 처리하기 때문에, 작업 하나가 끝나지 않으면 그 GPU를 쓰는 모든 작업이 멈추게 됩니다. 그런데 드라이버는 오래 걸리는 작업과 멈춘 작업을 구별할 수 없어서, 시간만 보고 판단합니다.

 여기서 재미있는 점은 앞에서 본 num_batch와 입력 길이의 관계가 다시 등장한다는 것입니다. kagent 요청이 실패한 것은 입력이 약 4만 6천 토큰이고 num_batch가 2048일 때였습니다. 이때 GPU에서는 Prefill의 Attention 계산 하나가 2초 넘게 걸리고 있었고, 워치독은 이를 GPU가 멈춘 것으로 판단해 리셋했습니다.

 Prefill에서는 입력을 num_batch 만큼씩 조각으로 나누어 처리합니다. 조각 하나가 레이어를 하나씩 통과할 때마다 여러 개의 GPU 커널(GPU에서 실행되는 작은 계산 프로그램)이 GPU에 들어갑니다. 이 중 Attention 커널은 조각의 토큰마다 앞에 쌓인 토큰 전부를 참조하기 때문에, 걸리는 시간이 배치 크기와 입력 길이에 모두 비례합니다. 

 배치 2048로는 입력 길이 4만 토큰 부근이 한계였는데, 당시 kagent의 요청은 4만 4천 ~ 4만 8천 토큰이었습니다. 그래서 배치를 512로 줄였습니다. 전체 계산량은 같지만 한 번에 넣는 양이 1/4이 되니, 커널 시간도 1/4로 줄어듭니다.

배치 2048, 입력 길이 46,000  →  약 2.3초		← 기본 한도 2초 초과
배치  512, 입력 길이 46,000  →  약 0.58초		← 커널 처리 시간 약 1/4로 감소

 그런데 컨텍스트 상한을 131,072에서 262,144로 올리면서 문제가 다시 생겼습니다. 배치 512에 한도 2초로는 입력 16만 토큰까지만 버틸 수 있고, 상한 인 26만 토큰까지 차면 커널 하나의 처리 시간이 약 3.3초 걸립니다. 대응책은 두 가지로, 배치를 256으로 더 줄이거나 워치독의 한도를 늘리는 것입니다. 앞선 num_batch의 테스트 결과에 따라 큰 입력 토큰에서 가장 효율이 좋은 512를 유지하기 위해서 한도를 10초로 늘리는 선택을 했습니다.

# /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="amd_iommu=off ttm.pages_limit=12582912 amdgpu.lockup_timeout=10000"

# 재부팅 후 확인
$ cat /sys/module/amdgpu/parameters/lockup_timeout
10000

 이를 통해 배치 512로 컨텍스트 상한(262,144)의 세배 이상까지 버틸 수 있게 되었습니다. 대신 GPU가 정말로 멈춘 경우 복구까지 10초가 걸린다는 문제가 있으나, 헤드리스 서버이므로 감수할만한 리스크라 판단하였습니다.

3.5 IOMMU off의 실제 효과

 1부에서 BIOS에서 IOMMU를 끄는 세팅을 했기 때문에 실제로 이 설정이 켜졌을 때와 꺼졌을 때 어떤 차이가 나는지도 궁금했습니다. 그래서 BIOS 설정에서 IOMMU를 켜고, 커널 파라미터를 바꿔가면서 IOMMU on / off 설정에 대한 측정을 하였습니다. 부팅의 효과를 고려하여 각 설정을 교차로 하여 IOMMU off 3회, on 2회 측정한 결과는 아래와 같습니다.

 IOMMU off는 확실히 효과가 있었습니다. 특히 Prefill에서 약 4% 정도 유의미한 차이를 보였고, Decode도 약 1.8% 정도의 차이를 보였습니다. 단, 관련해서 외국 자료에서는 IOMMU on / off가 약 10% 정도 성능 차이가 난다는 실험 결과가 있었는데, 저의 환경에서는 그에는 미치지 못하는 이유로는 MoE 모델의 특징 때문이라 추정하고 있습니다. Dense 모델은 거대한 메모리 블록을 일직선으로 연속해서 긁어오기 때문에 DRAM 내부의 행 버퍼(Row Buffer) 적중률이 극대화되어 순수 메모리 지연이 매우 적습니다. 반면 MoE 모델은 라우터가 선정한 특정 전문가 가중치 블록으로 매번 물리 주소를 건너뛰어가며 읽어옵니다. 이 과정에서 DRAM 내부의 행을 닫고 새로 여는 물리적 전환 지연(Row Buffer Miss)이 누적되어 전체 소요 시간의 상당 부분을 차지하게 되는게 아닌가 합니다.

 즉, MoE 구조에서는 DRAM 자체의 물리적 분산 접근 지연이 전체 병목의 주요 원인으로 작용하여, IOMMU를 비활성화하여 주소 변환 시간을 단축했음에도 전체 작업 시간 대비 향상 폭은 Dense 모델(약 10%)보다 완화된 4.2% 수준으로 관측된 것으로 해석할 수 있습니다.(단, 이것은 어디까지나 추측입니다.) 어쨌든, 저는 성능 향상을 위해 IOMMU off로 설정하였습니다.

3.6 ROCm vs Vulkan

 2부에서 AMD에는 ROCm이라는 GPU 연산 스택이 있지만 GPU 모델에 따라 지원 범위가 다르다고 짧게 언급했었습니다. 실제로 780M은 ROCm의 공식 지원 목록에 없기 때문에 Vulkan을 사용하는 것이 정석이나, 외국 자료를 통해 780M을 비슷한 세대의 지원 GPU로 속여 ROCm으로도 돌릴 수 있다는 것을 알아냈습니다. 이 둘을 비교해 보니 ROCm 쪽이 조금 더 좋은 결과를 보이기는 했습니다.

# ROCm으로 돌릴 때 docker-compose.yml에서 달라지는 부분
    image: ollama/ollama:rocm           # 실제 운영에서는 버전과 다이제스트로 고정
    devices:
      - /dev/dri:/dev/dri
      - /dev/kfd:/dev/kfd               # ROCm 연산 장치
    environment:
      - HSA_OVERRIDE_GFX_VERSION=11.0.0 # gfx1103을 gfx1100으로 속인다
      # OLLAMA_VULKAN=1은 뺀다

 위 표에서 알 수 있듯 긴 입력의 Prefill에서 ROCm이 훨씬 더 빨랐습니다. Vulkan은 입력 컨텍스트가 클수록 속도가 더 빠르게 떨어지는 반면, ROCm은 그 감소량이 덜한 것을 확인할 수 있습니다. 다만 여기에서는 Vulkan을 사용하기로 했습니다. 안정성 면에서 특정 ROCm 버전은 제대로 작동하지 않는 것을 확인했기 때문입니다.

4. Decode - 여전한 메모리 대역폭의 한계

4.1 메모리 대역폭 실측

# 배열 2억 개(× 8바이트 × 3개 = 약 4.8GB)로 캐시의 영향을 없애고, 20회 중 최고값을 본다
gcc -O3 -march=native -fopenmp -DSTREAM_ARRAY_SIZE=200000000 -DNTIMES=20 -mcmodel=medium stream.c -o stream
OMP_NUM_THREADS=4 ./stream

 STREAM으로 잰 대역폭은 약 62GB/s로, 이론값의 70% 정도이며 1부에서 예측한 값보다 낮은 수치입니다. STREAM 측정값으로 Decode 속도의 상한을 계산해 보면 다음과 같습니다.

토큰 하나를 만들 때 읽는 양 ≈ 활성 파라미터 3.6B × 약 0.6바이트(Q4_K_M) ≈ 2.1 ~ 2.2GB
실측 대역폭 약 62GB/s ÷ 2.2GB ≈ 초당 약 28회 읽기

하지만 측정 스크립트로 잰 Decode는 약 39.4 tokens/s로, 계산한 상한보다 높았습니다.

4.2 추측 디코딩(MTP)을 통한 물리적 한계 극복

 1부의 ollama show 출력에는 draft_num_predict 2라는 파라미터도 있었습니다. 이는 모델이 MTP(Multi-Token Prediction)라는 추측 디코딩을 지원한다는 의미입니다. Ollama 문서에 따르면 draft_num_predict를 0으로 두면 추측 디코딩이 꺼집니다. 켰을 때와 껐을 때를 비교한 결과는 아래 표와 같습니다.

# 요청 옵션으로 초안 개수를 0으로 주면, 러너가 추측 디코딩 없이 다시 뜬다
curl -s localhost:11434/api/generate -d '{
  "model": "qwen3.6:35b-a3b", "prompt": "hi", "stream": false,
  "options": {"draft_num_predict": 0}
}'

# 러너 인자에서 --spec-* 옵션이 빠졌는지 확인
$ tr '\0' ' ' < /proc/$(pgrep -x llama-server)/cmdline
... --mmproj /root/.ollama/models/blobs/sha256-… --flash-attn auto -b 512 -ub 512 --context-shift --keep 4

 MTP를 끄자 짧은 입력의 Decode는 28.4 tokens/s로 떨어져 앞서 STREAM 측정값으로 계산한 초당 약 28 tokens/s와 거의 같은 값을 나타냅니다. 이를 상회하는 약 11 tokens/s는 MTP 덕분이라는 것을 알 수 있었습니다.

4.3 입력 토큰이 크면 Decode도 느려진다

 입력이 클수록 Decode도 느려지는 양상을 보였습니다. 토큰 하나를 만들 때마다 모델 가중치와 함께 그동안 쌓인 KV Cache도 읽어야 하기 때문으로, 약 11.9만 토큰일 때 KV Cache가 약 2.4GB로 토큰 하나에 읽는 모델 가중치(약 2.2GB)와 비슷한 양이됩니다. 그래서 대략 2.8만 토큰에 비해 절반 정도 속도가 나오는 것을 확인할 수 있습니다.

5. 정리

5.1 같은 스크립트로 측정한 결과

5.2 설정별 효과

5.3 최종 구성

# BIOS
UMA Frame Buffer Size = 1G, IOMMU = Disabled, SVM = Disabled, EXPO 5600, 전력 모드 Performance

# 커널 (/etc/default/grub)
GRUB_CMDLINE_LINUX_DEFAULT="amd_iommu=off ttm.pages_limit=12582912 amdgpu.lockup_timeout=10000"

# docker-compose.yml (ollama 서비스)
image: ollama/ollama:0.34.1@sha256:...   # 버전과 다이제스트로 고정
environment:
  - OLLAMA_VULKAN=1
  - OLLAMA_IGPU_ENABLE=1
  - OLLAMA_CONTEXT_LENGTH=262144
  - OLLAMA_KEEP_ALIVE=-1

# 모델 태그 (Modelfile)
PARAMETER num_batch 512

# 부팅 시 모델 프리로드: systemd oneshot 유닛

6. 마치며

 이번 포스팅에서는 "느리다"를 로딩/Prefill/Decode의 세 가지로 구간으로 나누어, 각각 무엇을 측정하고 튜닝했는지를 정리해 보았습니다. Prefill에서는 GPU 사용, 배치 크기, IOMMU, 백앤드 선택에 따라 몇 %에서 수십 % 까지 차이가 났습니다. Decode는 메모리 대역폭의 한계가 절대적이라는 것을 확인할 수 있었습니다. 또한, 직접 적지는 않았으나 테스트 간에 캐시 적중에 의한 Prefill 속도의 극적인 향상도 한번 더 확인할 수 있었습니다.

 다음 시간에는 그럼에도 불구하고 kagent가 로컬 LLM으로 보낸 요청에서 캐시가 한 번도 맞지 않았던 것에 대한 원인을 추적한 과정과, 그 끝에 오픈소스 PR까지 가게 된 이야기를 정리해 보도록 하겠습니다.

 긴 글 읽어주셔서 감사합니다.

이어서 4부 읽기

 지난 포스팅에서는 외장 GPU가 없는 미니 PC에 로컬 LLM을 구축하고, 간단한 질문에 모델이 응답하는 것까지 확인해 보았습니다. 약 33 tokens/s라는 숫자를 보고 이 정도면 제법 쓸 만하겠다는 생각도 했습니다. 하지만 실제로 활용하려고 보니, 모델이 실행되는 것과 그 동작을 이해하는 것은 전혀 다른 문제였습니다.
 Ollama는 정확히 무엇을 하는 프로그램인지, Vulkan은 왜 필요했는지, 모델은 이전 대화를 어떻게 기억하는지. 하나씩 알아보다 보니 Prefill, Decode, KV Cache라는 낯선 용어들도 계속 등장했습니다. 각각의 설명을 읽을 때는 이해한 것 같았는데, 막상 전체 과정을 연결하려니 생각보다 쉽지 않았습니다.

 이번 포스팅에서는 이러한 개념들을 연결하여 사용자의 요청 하나가 실제 답변이 되기까지 어떤 과정을 거치는지 살펴보도록 하겠습니다. 스터디를 하면서 정리한 내용이며, 모델과 구현에 따라 달라지는 세부 사항은 기본 원리를 이해하는 데 필요한 수준으로 단순화하였습니다.

1. Ollama란 무엇인가?

 개발자나 엔지니어들에게 컨테이너는 아마 제법 익숙한 개념일 것입니다. 컨테이너 이미지를 내려받고 실행하기 위해 Docker를 사용해 보셨다면, Ollama의 역할도 어렵지 않게 이해할 수 있습니다. Ollama는 모델을 내려받고, 실행하고, 다른 애플리케이션에서 호출할 수 있도록 도와주는 오픈소스 도구입니다. 간단한 CLI와 HTTP API를 제공하기 때문에 모델의 실행 환경을 처음부터 직접 구성하지 않고도 LLM을 사용할 수 있습니다.

 다만 Docker와 비슷하다는 것은 사용 방식에 대한 비유입니다. 모델을 하나 실행할 때마다 새로운 Docker 컨테이너가 만들어지는 것은 아닙니다. 1부에서 Docker로 실행한 것은 Ollama 서비스이고, 내려받은 모델은 그 서비스가 사용하는 데이터입니다.

 여기서 모델과 실행 프로그램도 구분할 필요가 있습니다. 우리가 내려받은 모델에는 학습된 가중치와 설정 등이 들어 있습니다. 이 데이터를 읽고 실제 계산을 수행하는 프로그램이 별도로 필요한데, 이번 환경에서는 llama.cpp 기반의 추론 엔진이 그 역할을 수행합니다. llama.cpp는 모델 추론을 수행하는 프로젝트이고, llama-server는 이 프로젝트에서 제공하는 서버 실행 파일입니다.

 제가 실행한 환경에서도 pstree를 통해 Ollama의 자식 프로세스로 llama-server가 실행되고 있는 것을 확인할 수 있었습니다. 관계만 간략히 표시하면 다음과 같습니다.

containerd-shim
└─ ollama
   └─ llama-server

 즉, 사용자 입장에서는 Ollama에 질문을 보내지만, 내부에서는 모델을 실행하는 추론 엔진이 실제 계산을 수행하고 있는 것입니다. 다만 실행 파일의 이름이나 내부 구성은 Ollama의 버전과 사용하는 백엔드에 따라 달라질 수 있음을 미리 알립니다.

2. Vulkan과 Mesa RADV

 그렇다면 추론 엔진은 GPU를 어떻게 사용할까요? 1부에서는 Vulkan 관련 패키지를 설치하고, Ollama가 Vulkan을 사용하도록 설정했습니다. 이때 등장한 Vulkan은 AMD GPU 전용 드라이버가 아닙니다. GPU를 사용하여 그래픽이나 범용 연산을 수행할 수 있도록 정의한 표준 API입니다. 특정 제조사에 종속되지 않는 인터페이스를 제공하지만, 실제 하드웨어에서 사용하려면 이를 구현한 드라이버가 필요합니다.

 리눅스에서 AMD GPU를 대상으로 이 Vulkan API를 구현하는 드라이버 중 하나가 Mesa 프로젝트의 RADV입니다. 여기서도 드라이버가 한 종류만 있는 것은 아닙니다. RADV는 사용자 공간에서 동작하는 드라이버이고, 리눅스 커널에는 amdgpu라는 커널 드라이버가 있습니다. RADV가 GPU에서 실행할 명령을 준비하고 커널에 제출하면, amdgpu가 메모리 관리와 명령 제출 등 하드웨어와 가까운 작업을 담당합니다. 이번 환경의 GPU 연산 경로를 단순화하면 다음과 같습니다.

Ollama
   ↓
llama-server의 Vulkan 백엔드
   ↓
Vulkan API 호출
   ↓
Mesa RADV
   ↓
Linux amdgpu 커널 드라이버
   ↓
AMD Radeon 780M 내장 GPU

 중간의 Vulkan API는 별도의 서버 프로세스라기보다는 프로그램과 드라이버 사이에서 사용하는 약속에 가깝습니다. 그리고 RADV는 그 약속을 AMD GPU에서 동작하도록 구현한 것입니다.

 AMD에는 ROCm이라는 GPU 연산용 소프트웨어 스택도 있습니다. 다만 ROCm을 통한 지원 범위는 GPU 모델과 소프트웨어 버전에 따라 달라지며, 모든 AMD GPU를 동일하게 지원하는 것은 아닙니다. Ollama는 Vulkan을 통해 추가적인 GPU 지원 경로도 제공합니다. 따라서 이번 포스팅에 사용된 구성은 ROCm이 아닌 Vulkan과 RADV를 통해 내장 GPU를 활용한 경우라고 이해하면 됩니다.

3. Stateless, 대화는 누가 기억하는가?

 이제 실제 대화를 살펴보겠습니다. 아래처럼 첫 번째 명령에서 특정 날짜를 알려주고, 두 번째 명령에서 그 날짜를 다시 물어보았습니다.

# 첫 번째 대화. 2026년 9월 3일이 최초로 대화를 나눈 날이라고 설명.
docker compose exec ollama ollama run qwen3.6:35b-a3b "2026년 9월 3일은 우리가 최초로 대화를 나누었던 날입니다."

정말 특별한 날로 기억해 주셔서 감사합니다. 다만 저는 AI 어시스턴트라 매 세션이 독립적으로 처
리되며, 과거의 대화나 개인적인 시간을 기억하거나 누적하지 않습니다. 또한 2026 년 9 월 3 일은
 아직 미래의 날짜이기도 합니다 😊		# 심지어 미래의 날이라고 이야기함

하지만 지금 이 순간부터는 언제든 편하게 질문하거나 이야기해 주세요. 이전과는 달리 각 대화마다
 최선을 다해 도와드리며, 앞으로 함께 나누게 될 시간들이 벌써 기대됩니다.
 
 # 두 번째 대화. 처음 대화를 나눈 날이 언제인지 질문.
 docker compose exec ollama ollama run qwen3.6:35b-a3b "우리가 처음 대화를 나누었던 날은 언제이죠?"

저는 이전 대화 내용을 기억하지 못합니다. 각 세션은 독립적으로 처리되며, 저는 과거의 상호작용
이나 날짜를 저장하거나 접근할 수 있는 기능이 없습니다. 

하지만 지금 이렇게 새로운 대화를 시작하게 되어 기쁩니다! 😊 궁금한 점이 있거나 도움이 필요하
신 부분이 있다면 언제든 말씀해 주세요. 최선을 다해 도와드리겠습니다.

 두 번째 실행에서는 이전 대화를 기억하지 못한다는 답변이 돌아왔습니다. Ollama 서버도 계속 실행 중이고, 같은 모델을 사용했는데 왜 방금 알려준 내용을 모르는 것일까요? 핵심은 두 번째 실행의 입력에 첫 번째 대화가 포함되어 있지 않기 때문입니다. 명령을 별도로 실행했다고 해서 앞선 실행의 대화 내용이 자동으로 다음 요청에 이어지는 것은 아닙니다. 반면 Ollama의 대화형 CLI는 같은 세션에서 사용자 메시지와 모델의 답변을 누적하여 다음 요청에 전달합니다.

3.1 이전 대화도 결국 다음 요청의 입력입니다

 대화를 이어 가는 가장 기본적인 방법은 간단합니다. 이전 대화를 보관했다가 새 질문과 함께 보내는 것입니다. Ollama의 Chat API도 messages라는 배열을 통해 대화 이력을 전달받습니다.

 예를 들어 첫 번째 답변이 “알겠습니다.”였다고 가정하면, 두 번째 요청은 다음과 같이 구성할 수 있습니다. 아래의 이전 답변은 요청 구조를 보여 주기 위해 단순화한 예시입니다.

curl --fail-with-body --silent --show-error \
  http://localhost:11434/api/chat \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.6:35b-a3b",
    "messages": [
      {
        "role": "user",
        "content": "2026년 9월 3일은 우리가 최초로 대화를 나누었던 날입니다."
      },
      {
        "role": "assistant",
        "content": "알겠습니다."
      },
      {
        "role": "user",
        "content": "우리가 처음 대화를 나누었던 날은 언제이죠?"
      }
    ],
    "stream": false
  }'

 이제 모델이 받는 입력에는 날짜를 알려준 내용도 포함되어 있습니다. 사용자는 마지막 질문 한 문장만 입력했지만, 애플리케이션이 보내는 요청에는 그 앞의 대화도 들어가는 것입니다. 대화 내용을 관리하는 것과, 전달받은 내용을 바탕으로 답변을 생성하는 것은 서로 다른 역할입니다.

3.2 Stateless는 서버 메모리가 비어 있다는 뜻이 아닙니다

 여기서 Stateless라는 표현을 조금 조심해서 사용해야 합니다. 이 글에서 다루는 Stateless 한 요청 방식은 서버가 이전 대화 세션을 기억하고 있을 것이라고 전제하지 않고, 이번 요청을 처리하는 데 필요한 문맥을 요청 자체에 포함하는 방식입니다. 채팅 애플리케이션이 대화 이력을 저장할 수 없다는 뜻도 아니고, 추론 서버의 메모리에 어떤 상태도 남아 있지 않다는 뜻도 아닙니다.

 실제로 추론 서버는 모델을 메모리에 유지하거나, 앞서 수행한 계산 결과를 캐시로 보관할 수 있습니다. llama-server에도 이전 요청과 공통된 프롬프트 구간의 KV Cache를 재사용하는 기능이 있습니다. 따라서 “요청에 필요한 대화 이력을 전달하는 것”과 “서버 내부에 계산 캐시가 남아 있는 것”은 동시에 성립할 수 있습니다. 여기까지는 모델에 어떤 내용을 보여 줄 것인가에 대한 이야기였습니다. 이제 그렇게 전달한 내용을 실제로 어떻게 계산하는지 살펴보겠습니다.

4. Prefill &  Decode

 학습된 모델을 사용하여 입력에 대한 결과를 계산하는 과정을 추론(Inference)이라고 합니다. 여기서는 그중에서도 앞선 문맥을 바탕으로 다음 토큰을 생성하는, 일반적인 자기회귀 언어 모델의 추론을 기준으로 설명하겠습니다.

 먼저 모델은 우리가 입력한 문장을 그대로 읽는 것이 아닙니다. 대화 메시지는 모델이 사용하는 채팅 템플릿에 따라 하나의 입력 시퀀스로 구성됩니다. 이 과정에는 사용자와 모델의 역할을 구분하는 특수 토큰 등도 포함됩니다. 따라서 화면에 보이는 문장만이 실제 입력의 전부는 아닙니다.

 이렇게 구성한 입력은 토큰화되어 숫자 ID의 배열로 변환됩니다. 모델은 이 입력을 계산하여 다음 위치에 어떤 토큰이 올 수 있는지에 대한 점수인 Logits를 내놓고, 추론 프로그램이 그 점수를 이용해 다음 토큰을 선택합니다. 선택한 토큰을 다시 문맥에 추가하는 과정을 반복하면 답변이 만들어집니다. 이 반복 과정에서 입력을 처리하는 단계와 이후 출력을 이어 가는 단계를 구분한 것이 Prefill과 Decode입니다.

4.1 Prefill - 입력된 문맥을 처리하는 단계

 Prefill에서는 이미 주어진 입력 토큰들을 모델에 통과시켜 계산합니다. 입력에는 현재 질문뿐 아니라 시스템 프롬프트, 이전 대화, 검색해서 가져온 문서 등이 포함될 수 있습니다. 따라서 사용자가 짧은 질문 하나만 입력해도 실제로 처리할 토큰은 상당히 많을 수 있습니다. 이 단계에서는 입력 토큰이 처음부터 주어져 있으므로 여러 위치의 계산을 묶어서 수행할 수 있습니다. 입력을 한 토큰씩 새로 만들어 가야 하는 상황이 아니기 때문입니다. 이 계산을 통해 이후 생성에 사용할 중간 결과를 준비하고, 마지막 입력 위치의 결과를 바탕으로 첫 번째 출력 토큰을 선택합니다. Prefill도 이미 모델을 실행하는 추론 단계이지, 단순히 파일을 읽거나 실행 준비만 하는 단계는 아닙니다.

 많은 토큰을 묶어 처리하면 같은 가중치를 여러 토큰의 계산에 재사용하기 좋습니다. 충분한 크기의 행렬 연산에서는 메모리에서 가져오는 데이터에 비해 수행하는 계산이 많아지므로, 프로세서의 연산 성능이 중요해집니다. 다만 입력이 매우 짧거나 실행 환경이 달라지면 병목도 달라지므로, Prefill은 무조건 연산 성능으로만 결정된다는 뜻은 아닙니다.

4.2 Decode - 다음 토큰을 이어서 생성하는 단계

 Prefill의 결과에서 첫 번째 출력 토큰을 선택했다면, 이제 그 토큰을 입력하여 두 번째 출력 토큰을 계산합니다. 두 번째 토큰을 선택하면 다시 그것을 입력하여 세 번째 토큰을 계산합니다. 이러한 후속 생성 과정을 Decode라고 합니다.  논리적인 흐름은 다음과 같습니다.

[입력 문맥]			→ 첫 번째 출력 토큰
[입력 문맥 + 첫 번째 토큰]		→ 두 번째 출력 토큰
[입력 문맥 + 첫 번째 + 두 번째]	→ 세 번째 출력 토큰

 여기서 출력은 입력과 상황이 다릅니다. 두 번째 출력 토큰을 계산하려면 먼저 첫 번째 출력 토큰이 무엇인지 결정되어야 합니다. 그래서 일반적인 한 토큰씩 생성하는 방식에서는 생성 단계 사이에 순차적인 의존성이 생깁니다. 물론 이것은 토큰 하나를 계산하는 내부 연산까지 모두 직렬로 수행한다는 뜻은 아닙니다. 또한 요청 하나의 Decode에서는 적은 수의 새 토큰을 처리하기 위해 많은 가중치와 문맥 정보를 읽어야 합니다. Prefill처럼 같은 가중치를 많은 입력 토큰에 한꺼번에 활용하기 어려우므로, 작은 배치에서는 프로세서 자체의 속도보다 필요한 데이터를 얼마나 빠르게 공급할 수 있는가, 즉 메모리 대역폭이 병목이 되기 쉽습니다.

 1부에서 메모리 대역폭을 중요하게 보았던 이유도 여기에 있습니다. 다만 MoE 모델에서는 토큰마다 선택된 전문가를 사용하므로, 모든 전문가의 가중치를 항상 전부 계산하는 것은 아닙니다. 1부에서 사용한 Qwen3.6-35B-A3B도 전체 파라미터 중 일부를 활성화하는 구조입니다. 따라서 모델 파일의 전체 크기만으로 매 단계의 데이터 읽기 비용을 판단해서는 안 됩니다.

 그런데 위의 생성 흐름을 보면 한 가지 의문이 생깁니다. 다음 토큰을 생성할 때마다 앞의 문맥을 전부 다시 계산해야 하는 것인가?

5. KV Cache - 이미 수행한 계산의 재사용

 모델은 일종의 계산기라고 볼 수 있습니다. 입력과 가중치를 바탕으로 복잡한 계산을 수행하고 결과를 내놓습니다. 다음 계산에서도 이전에 처리한 문맥이 필요하다면, 그에 필요한 계산 결과를 보존하여 재사용하거나 다시 계산해야 합니다. 여기서 등장하는 것이 KV Cache입니다.

5.1 KV Cache가 없다면?

 KV Cache를 사용하지 않는 일반적인 생성 방식을 생각해 보겠습니다. 먼저 프롬프트 전체를 처리하여 첫 번째 출력 토큰을 선택합니다. 그다음에는 기존 프롬프트에 생성한 토큰을 붙여 다시 계산합니다. 이후에도 같은 작업을 반복합니다. 입력 토큰을 A B C, 생성할 토큰을 y1 y2 y3라고 하면 다음과 같습니다.

A B C 전체 계산
  → y1 선택

A B C y1 전체 계산
  → y2 선택

A B C y1 y2 전체 계산
  → y3 선택

 답변이 길어질수록 다시 처리할 문맥도 길어지고, 이미 수행한 계산을 계속 반복하게 됩니다. 캐시 없는 전체 시퀀스 재계산 방식이 비효율적인 이유입니다.

5.2 중간 계산 결과의 저장

 Transformer의 Attention에서는 토큰의 표현으로부터 Query, Key, Value, 줄여서 Q·K·V라는 벡터를 계산합니다. 간략하게 설명하자면 '현재 위치의 Q가 다른 위치의 K와 관련도를 비교하고, 그 결과를 이용해 V의 정보를 조합한다' 정도가 됩니다. 새로운 토큰을 처리할 때도 과거 토큰의 K와 V가 필요합니다. 그래서 이미 처리한 토큰들의 K·V를 레이어별로 저장해 두고 재사용하는 것이 KV Cache입니다. 여기서 KV Cache에 대해서 오해를 하면 안되는 것이, KV Cache는 완성된 답변을 저장하는 응답 캐시도 아니고, 마지막 토큰 하나의 상태만 보관하는 것도 아닙니다. 캐시를 사용하면 앞의 흐름은 다음과 같이 바뀝니다.

Prefill
  A B C를 처리하고 KV 저장
    → y1 선택

Decode
  y1을 새로 처리하고 기존 KV 참조
  y1의 KV도 추가
    → y2 선택

Decode
  y2를 새로 처리하고 기존 KV 참조
  y2의 KV도 추가
    → y3 선택

 이때 중요한 점은 과거 토큰을 다시 처리하는 비용을 줄이는 것이지, 과거 문맥을 더 이상 참고하지 않는 것은 아니라는 점입니다. 새 토큰의 Attention 계산에서는 기존 KV를 여전히 읽고 사용합니다.  따라서 KV Cache는 다음과 같이 이해하는 것이 좋습니다.

대화 이력은 모델에 보여 줄 내용을 보관하는 것이고, KV Cache는 그 내용을 처리하며 만들어 둔 중간 계산 결과를 보관하는 것입니다.

캐시가 없다고 애플리케이션이 보관한 프롬프트가 사라지는 것은 아닙니다. 필요한 입력이 남아 있다면 다시 계산하면 됩니다. 캐시의 목적은 그 재계산을 줄이는 데 있습니다. 

5.3 캐시도 메모리를 사용한다

물론 계산 결과를 저장하려면 메모리가 필요합니다. 일반적인 Full Attention의 KV Cache는 보관할 토큰이 많아질수록 필요한 공간도 커집니다. 캐시를 동적으로 늘리는 구현도 있고, 정해진 크기를 미리 확보하는 구현도 있습니다. 따라서 모델 가중치를 메모리에 올릴 수 있다는 것과, 긴 문맥을 원하는 동시 요청 수로 처리할 수 있다는 것은 다른 문제입니다. 모델뿐 아니라 캐시와 실행 중 사용하는 다른 메모리까지 고려해야 합니다.

 참고로 실제 모델의 모든 레이어가 같은 방식으로 동작하는 것은 아닙니다. 1부에서 사용한 Qwen3.6-35B-A3B는 Gated DeltaNet과 Gated Attention을 섞은 하이브리드 구조입니다. 따라서 앞선 설명은 일반적인 Attention의 KV Cache 원리를 이해하기 위한 것이며, 이 모델의 모든 레이어에 동일한 형태의 KV가 누적된다는 의미는 아닙니다.

6. 다음 질문이 들어오면 어떻게 될까?

 지금까지는 하나의 답변을 생성하는 동안의 이야기 였습니다. 그렇다면 답변이 끝난 뒤 사용자가 다음 질문을 입력하면 어떻게 될까요? 앞에서 설명했듯 애플리케이션은 필요한 이전 대화와 새 질문을 함께 전달합니다. 그런데 이전 대화는 조금 전까지 모델이 처리하던 내용입니다. 이 구간의 계산 결과가 서버에 남아 있다면 다시 사용할 수 있지 않을까요? 그렇게 요청 사이에서 공통된 앞부분의 계산 결과를 재사용하는 것이 Prefix Caching입니다. 긴 문서를 두고 질문을 반복하거나 여러 차례 대화를 이어 가는 경우가 대표적인 활용 사례입니다.

6.1 Prefix Caching을 사용한 계산의 효율성 향상

 Prefix Caching은 KV Cache와는 다른 개념으로, 모델이 사용자와 상호 작용함에 있어 동일한 앞부분은 재사용하고, 나머지는 새로 계산할 수 있도록 돕는 역할을 합니다. 첫 번째 대화를 마친 후 두 번째 질문을 보낸다면, 논리적인 입력은 다음과 같습니다.

[시스템 프롬프트]
[첫 번째 질문]
[첫 번째 답변]
[두 번째 질문]

 이 중 앞부분에 해당하는 캐시가 남아 있고 재사용 조건이 맞는다면 다음과 같이 처리할 수 있습니다.

[시스템 프롬프트] ┐
[첫 번째 질문]   ├─ 일치하는 구간의 캐시 재사용
[첫 번째 답변]   ┘

[두 번째 질문]    ── 새로 Prefill
                         ↓
                    새 답변 생성

 물론 실제로는 캐시 경계나 입력 구성에 따라 이전 대화의 끝부분 일부를 다시 계산할 수도 있습니다. 핵심은 이번 입력 전체를 무조건 처음부터 다시 계산하지 않고, 재사용 가능한 앞부분 이후부터 계산할 수 있다는 것입니다. llama-server 역시 공통된 프롬프트 앞부분을 재사용하고 달라진 뒷부분을 처리하는 기능을 제공합니다. 이때 새로운 질문을 Prefill하면서도 이전 문맥의 캐시는 참고합니다. 새 질문만 독립적으로 처리하는 것이 아니라, 기존 문맥을 반영하여 새로운 부분을 계산하는 것입니다.

 다만 동일하다는 기준은 “뜻이 비슷하다”가 아닙니다. 일반적인 Prefix Caching은 앞에서부터 이어지는 실제 토큰 배열이 일치하는 구간을 재사용합니다. 같은 모델 등 계산 조건도 맞아야 하며, 앞부분의 내용이 바뀌었다면 그 뒤에 같은 문장이 다시 등장하더라도 기존 계산 결과를 그대로 사용할 수 있다고 보장할 수 없습니다. (그리고 이 부분에서 Kagent Go 런타임의 버그를 발견했습니다.)

6.2 캐시가 남아 있어도, 빠진 대화를 알아서 붙여 주지는 않습니다

 여기서 [3. Stateless, 대화는 누가 기억하는가?]와 다시 연결됩니다. Prefix Caching은 이번 요청에 포함된 문맥의 계산을 줄이는 기능이지, 요청에서 빠진 대화를 찾아서 보충하는 기능이 아닙니다. 3의 예시에서도 보았듯, 첫 요청에 모델과 처음 대화를 나눈 날짜를 알려주더라도, 그다음 요청에서 “우리가 처음 대화를 나눈 날은 언제이죠?”만 보내니 첫 요청의 답변 내용은 전혀 기억하지 못하고 엉뚱한 답변을 하는 것이 그 예시입니다. 즉, 일반적인 프롬프트 캐시 재사용 기능이 앞선 대화 내용을 임의로 붙여 주지는 않는다는 뜻입니다.

 반대로 이전 대화를 요청에 포함했다면, 캐시가 없어도 대화를 이어 갈 수 있습니다. 동일한 문맥을 다시 계산해야 할 뿐입니다. 즉, 대화를 이어 갈 수 있느냐와, 그 대화를 얼마나 효율적으로 계산하느냐는 구분해서 보아야 합니다. (추가로, 1부에서 설정한 OLLAMA_KEEP_ALIVE=-1도 이와 구분해야 합니다. 이 설정은 모델을 메모리에 계속 유지하도록 하는 설정입니다. 사용자별 대화 이력을 영구적으로 저장하라는 설정도 아니고, 모든 요청의 계산 캐시를 무제한 보관하라는 설정도 아닙니다.)

6.3 전체 응답 과정의 연결 - 대화 연속성의 비밀

 이제 사용자의 질문이 답변이 되기까지의 전체 흐름을 연결해 보면 아래와 같습니다. 실제 구현에서는 일부 작업의 순서가 달라지거나 겹칠 수 있지만, 개념적으로는 이와 매우 흡사합니다.

사용자가 새 질문 입력
    ↓
애플리케이션이 필요한 이전 대화와 새 질문으로 요청 구성
    ↓
Ollama가 요청을 받고 모델 실행 준비
    ↓
채팅 템플릿 적용 및 토큰화
    ↓
재사용할 수 있는 공통 앞부분의 캐시 확인
    ↓
새로 계산해야 하는 입력을 Prefill
    ↓
첫 번째 출력 토큰 선택
    ↓
Decode를 반복하며 다음 토큰 생성
    ├─ 기존 캐시 참조 및 갱신
    └─ 생성한 내용을 텍스트로 변환하여 클라이언트에 전달
    ↓
종료 조건에 도달하면 생성 완료
    ↓
애플리케이션이 답변을 대화 이력에 추가

우리가 화면에서 글자가 조금씩 나타나는 것을 보는 방식은 Streaming입니다. 전체 답변이 완성될 때까지 기다리는 대신, 생성된 내용을 조각으로 전달합니다. Ollama API에서도 이를 지원하며, 앞의 예시처럼 stream: false로 설정하면 전체 결과를 모아서 받게 됩니다. 또한, 네트워크로 전달되는 조각과 모델의 토큰 하나가 항상 일대일로 대응하는 것은 아닙니다.

7. 다시 1부의 결과를 되돌아 보면

 개념을 알아보았으니 1부에서 확인했던 결과를 다시 보겠습니다. 당시에는 마지막의 eval rate를 보고 약 33 tokens/s가 나온다는 점에 주로 관심을 두었습니다. 하지만 출력에는 그 외에도 중요한 정보가 들어 있었습니다.

total duration:       18.661490367s
load duration:        401.678µs
prompt eval count:    24 token(s)
prompt eval cached:   20 token(s)
prompt eval duration: 127.582ms
prompt eval rate:     31.35 tokens/s
eval count:           607 token(s)
eval duration:        18.463421s
eval rate:            32.88 tokens/s

 위 출력의 형식에서 주요 항목을 해석하여 아래 표로 정리해 보았습니다.

7.1 입력 24 토큰 중 일부만을 계산

 위 결과에서는 입력 토큰이 24개였지만, 그중 20개가 캐시에서 재사용되었습니다. 따라서 새로 계산한 입력 토큰은 4개입니다. 이 출력 형식의 prompt eval rate도 캐시를 제외한 토큰 수를 기준으로 계산합니다.

새로 계산한 입력 토큰
= 24 - 20
= 4토큰

입력 처리 속도
= 4 / 0.127582
≈ 31.35 tokens/s

 그러나 이 숫자만 보고 우리가 선택한 모델이 긴 입력도 초당 31 토큰 정도로 처리하겠다고 결론 내리기는 어렵습니다. 이미 대부분이 캐시 된 아주 짧은 입력을 처리한 결과이기 때문입니다. 장문 입력의 Prefill 성능을 알아보려면 입력 길이와 캐시 재사용 여부를 함께 보아야 합니다.

 출력 생산 속도는 아래와 같이 계산됩니다.

출력 생성 속도
= 607 / 18.463421
≈ 32.88 tokens/s

 이 값은 해당 실행에서 기록한 출력 생성 구간의 평균 속도입니다. 요청 전체가 끝나기까지의 시간이나 첫 번째 응답이 나타나기까지의 시간과는 다른 지표임을 유의해야 합니다.

7.2 답변이 나오기 전의 대기 시간 ≠ Prefill 시간

 사용자 입장에서는 질문을 입력한 뒤 아무것도 나오지 않는 시간이 있고, 이후 글자가 나타나기 시작하는 시간이 있습니다. 그러다 보니 앞의 대기 시간을 모두 Prefill이라고 생각하기 쉽습니다. 하지만 첫 토큰을 받기까지의 시간인 TTFT(Time To First Token)에는 Prefill뿐 아니라 요청 대기와 네트워크 지연 등도 포함될 수 있습니다. 모델을 새로 올려야 하는 상황이라면 준비 시간도 영향을 줄 수 있습니다. 따라서 첫 응답이 늦다고 곧바로 Prefill 계산이 느리다고 단정할 수는 없습니다.

 여기에 Thinking 모델은 한 가지를 더 구분해야 합니다. 1부에서도 최종 답변 전에 Thinking... 아래로 내용이 출력되었습니다. 이 Thinking 출력 역시 모델이 생성한 토큰입니다. Ollama는 이를 최종 답변과 별도의 필드로 제공할 수 있으며, 인터페이스에서 표시하거나 숨길 수도 있습니다. 따라서 화면에 최종 답변이 아직 나오지 않았더라도, 내부에서는 이미 Prefill을 마치고 Thinking 토큰을 생성하는 Decode가 진행 중일 수 있습니다. 그래서, “답변이 나오기 전까지 오래 걸렸다”는 현상을 분석할 때는 입력 처리에 오래 걸린 것인지, 생성 자체가 오래 걸린 것인지를 구분해야 하는 것입니다.

 이제 같은 “느리다”라는 표현도 조금 다르게 볼 수 있습니다. 모델 로딩이 오래 걸리는지, 입력을 처리하는 데 시간이 걸리는지, 출력이 시작된 뒤 생성 속도가 느린지에 따라 확인해야 할 부분이 달라집니다.

8. 마치며

 이번 포스팅에서는 Ollama와 GPU 사이의 실행 경로부터, 대화 이력 관리, Prefill과 Decode, 그리고 KV Cache까지 살펴보았습니다.

정리하면서 가장 중요하게 느낀 부분은 대화 내용을 보관하는 것과, 그 대화를 처리한 계산 결과를 보관하는 것이 서로 다른 문제라는 점입니다. 애플리케이션은 모델에 보여 줄 문맥을 구성하고, 추론 엔진은 그 문맥을 실제로 계산합니다. 캐시는 이 과정에서 이미 했던 계산을 다시 하지 않도록 돕는 역할입니다.

 1부에서는 “이 미니 PC로 모델을 실행할 수 있는가?”를 확인했다면, 이번에는 “실행된 모델이 어떤 과정을 거쳐 답변을 만드는가?”를 알아본 셈입니다. 아직 알아야 할 내용은 많지만, 이제 실행 결과에 표시되는 숫자들이 조금은 다르게 보입니다. 하지만 짧은 질문 하나에 제법 빠르게 답한다고 해서 실제 활용에서도 만족스러울지는 또 다른 문제였습니다. 1부의 마지막에 언급했던 것처럼, 실제로 kagent의 LLM 백엔드로 연결했을 때는 단발성 대화와 다른 양상이 나타났습니다. 다음 포스팅에서는 이 과정에서 겪었던 문제와 원인을 추적한 내용을 이어서 정리해 보도록 하겠습니다. 긴 글 읽어주셔서 감사합니다.

이어서 3부 읽기

 이번 포스팅은 로컬 LLM 구축기의 첫 번째 시리즈입니다. 용도가 애매했던 미니 PC를 중고로 내놓으려다가 로컬 LLM 구동 가능성을 확인한 후 구축 → 테스트 → 버그 발견 → 오픈소스 기여까지의 내용을 연재를 통해 소개하고자 합니다. 마이너 한 하드웨어 조합의 한계 때문에 오히려 배울 수 있었던 점이 많았기에 이를 공유하고자 합니다.

1. 신샤드, 그는 뭄 인가?

 출근길 지하철에서 알고리즘에 뜬 동영상 중 하나가 눈길을 끌었습니다. Kubernetes를 공부해 본 분이라면 한 번쯤은 보셨을 그분... 바로 뭄샤드 센세입니다. 게다가 자동 더빙(좀 멍청한 말투이긴 하지만)이 들어가 있어, 라디오 처럼 틀어놓고 들을 수 있어 바로 시청을 시작했습니다. 혹시 AI 인프라에 관심이 있는 분들이라면 꼭 한번 보시면 좋겠습니다. 강력 추천하는 영상입니다.

 사실 AI 인프라에는 개념이 거의 없었기 때문에 왜 GPU가 필요한지, 왜 고 대역폭 메모리가 필요한지 잘 모르고 있었습니다. 그냥 막연하게 '모델의 추론이라는 게 단순한 행렬 곱셈이고 이 행렬의 차원이 어마어마하게 커서 CPU보다는 더 많은 프로세서를 가지고 있는 GPU가 유리하다.' 정도로만 알고 있었습니다. 하지만 위 영상을 보고 그 내용을 쉽게 알 수 있었는데, 요지는 토큰 하나를 생성할 때마다 모델 전체를 프로세서(그게 CPU 던 GPU 던 간에)가 읽어야 하는데 이를 읽는 속도는 메모리와 프로세서 사이의 대역폭이 결정한다는 것입니다. 그 외에도 여러 가지 개념을 쉽게 설명해 놓았으니 관심 있으시면 한번 꼭 보시면 좋을 것 같습니다.

1.1 통합 메모리 아키텍처

 집에 그 용도가 애매한 미니 PC가 하나 놀고 있었습니다. GMKtec K8 Plus라는 모델로 AMD Ryzen 7 8845HS 프로세서를 탑재하고 있고 AMD Radeon 780M 내장 GPU를 내장하고 있습니다. 메모리는 64GB에 2TB SSD를 장착하고 있어서 저장공간도 매우 넉넉한 편으로 구매 당시에 75만 원 정도 주었던 것 같습니다. 메모리 가격이 폭등기 전 의도하지 않게 막차를 탄 셈입니다.

 어쨌든, '이 녀석으로 어떻게 AI를 돌린다는거냐?' 라고 질문할 수 있습니다. 그 답은 통합 메모리 아키텍처에 있습니다. 시스템 메모리 64GB 중 일부를 GPU가 점유할 수 있도록 설정이 가능해지면서 수십 기가 수준의 모델을 올릴 수가 있는 것입니다. 일반 소비자용 GPU의 VRAM이 24GB면 높은 수준인 것을 감안하면 매우 넉넉한 용량입니다.

 그러나, 한계도 명확합니다. DDR5 듀얼 채널의 시스템 메모리 대역폭은 이론상 약 89.6GB/s 수준이고, 실 사용 수준은 70GB/s - 80GB/s 정도가 됩니다. 그럼 이론상 20GB 모델을 사용한다 가정 시 초당 3.5 tok/s - 4 tok/s로 사실상 사용이 불가능한 수준이 됩니다. 하지만 아직 실망하기에는 이릅니다.

1.2 MoE 아키텍처

 여기서 또 사람들은 새로운 발상을 합니다. '토큰 하나를 생성하는데 모델 전체 파라미터를 사용하는 것이 아닌 그중 일부만을 사용하면 더 효율적이지 않을까?' 바로, MoE(Mixture of Experts)의 등장입니다. 이 부분에서 저의 이해는, 매 토큰 생성마다 라우터가 전체 파라미터 중 적합한 파라미터만을 선정하여 활성화시킨다입니다. 그러면 실제 프로세서가 읽어야 할 정보는 수 GB 수준으로 낮아지기 때문에 제법 쓸만한 토큰 생성 속도가 나오게 됩니다. 드디어 로컬 LLM 구현 가능성이 열렸습니다.

2. 기반 준비

 이제 가능성이 열렸으니 본격적으로 구축을 시작해 봅시다. 홈랩을 하다보면 하드웨어 최적화가 중요하다는 것을 항상 느낍니다. 제한된 환경에서 최대한의 성능을 끌어내어 마지막 한 방울까지 쥐어짜야 합니다.

2.1 BIOS 세팅

2.2 OS 선택

 OS는 취향 차리가 생각합니다. 저는 Linux 배포판 중 Ubuntu를 선호하는 편이고, 이번에 실험적으로 Ubuntu 26.04 LTS를 사용하기로 했습니다. Linux 커널 버전 7을 사용하며 최신 RDNA3을 통해 780M 내장 GPU를 지원이 보장됩니다.

2.3 커널 파라미터 설정

 OS 설치가 끝나고 나면 텍스트 편집기를 활용해 /etc/default/grub 파일을 열고 아래 값을 입력합니다. GTT 확장과 IOMMU 비활성화입니다.

GRUB_CMDLINE_LINUX_DEFAULT="amd_iommu=off ttm.pages_limit=12582912"

 일력 후 이를 활성화하기 위해서는 grup 업데이트와 재부팅이 필요합니다. 그 후 검증까지 아래 명령어를 통해 수행합니다.

# grup 업데이트 및 재부팅
sudo update-grub
sudo reboot

# 재부팅 후 검증
sudo dmesg | grep amdgpu, sudo dmesg | grep -i iommu, sudo dmesg | grep -i amd-vi

# 출력 확인
amdgpu 0000:c6:00.0:  1024M of VRAM memory ready		# UMA Frame Buffer Size 1GB로 설정
amdgpu 0000:c6:00.0:  49152M of GTT memory ready.		# GTT용 48GB 확인
Command line: ... amd_iommu=off ttm.pages_limit=12582912 ...	# IOMMU Off 확인

GTT와 IOMMU에 대한 설정은 아래 더 보기를 참고해 주세요.

2.4 Vulkan 드라이버 및 Docker 설치

 Ollama를 사용하여 LLM을 돌리기 위해서는 GPU와 통신할 수 있도록 드라이버가 필요합니다. 이때 Vulkan 드라이버가 아주 중요한 역할을 합니다. 정확히는 Vulkan은 일종의 표준 명세일 뿐이고 이 표준을 AMD GPU용으로 구현한 것이 RADV인데, 자세한 내용은 다음 포스팅에 다뤄보도록 하겠습니다.

# Vulkan 드라이버 설치

sudo apt update
sudo apt install -y mesa-vulkan-drivers vulkan-tools
sudo usermod -aG render <사용자 명>
sudo usermod -aG video <사용자 명>		# 로그아웃 후 재접속 필요 (그룹 변경은 새 세션부터 적용)

# Docker 설치
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker <사용자 명>		# 로그아웃 후 재접속 필요
docker run hello-world		# sudo 없이 정상 동작 확인

2.5 설정 최종 상태 확인

vendorID = 0x1002
deviceID = 0x1900
deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
deviceName = AMD Radeon 780M Graphics (RADV PHOENIX)
driverName = radv

3. Ollama 컨테이너 실행

 Ollama 및 모델은 모두 컨테이너 기반으로 구동합니다. 이번 포스팅에서는 Docker Compose를 사용하였습니다.

#docker-compose.yml
services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    devices:
      - /dev/dri:/dev/dri
    volumes:
      - ollama:/root/.ollama
    ports:
      - "11434:11434"
    environment:
      - OLLAMA_VULKAN=1			# Vulkan 드라이버 사용
      - OLLAMA_IGPU_ENABLE=1		# 내장 GPU 오프로딩 활성화
      - OLLAMA_KEEP_ALIVE=-1		# 모델이 메모리에 상주
      - OLLAMA_NO_CLOUD=true

volumes:
  ollama:

# Docker compose 실행
docker compose up -d
docker compose logs -f ollama

# 최종 검증
msg="inference compute" id=0 library=Vulkan name=Vulkan0 description="AMD Radeon 780M Graphics (RADV PHOENIX)" type=iGPU total="59.0 GiB" available="48.9 GiB"

4. 모델 선택

 모델을 선택하는 데 있어 중요하게 보았던 점은 아래 두 가지였습니다.

1. 64GB 메모리에 올라갈 수 있는 크기인가?
2. 70GB/s - 80GB/s 대역폭에 사용할 수 있는 수준이 되는가?

 이러한 하드웨어 제약 사항에서 가장 적합한 모델의 형태는 MoE라는 판단은 앞에서도 한번 언급했습니다. 그래서 qwen3.6 35B-a3b을 최종 모델로 선정했습니다. 모델에 대한 자세한 설명도 다음에 해 보도록 하겠습니다.

# Ollama를 사용해 모델을 다운로드
docker compose exec ollama ollama pull qwen3.6:35b-a3b

# 모델 정보 확인
docker exec ollama ollama show qwen3.6:35b-a3b
  Model
    architecture        qwen35moe	# 모델 명    
    parameters          35.5B		# 파라미터 수        
    context length      262144		# 컨텍스트 사이즈       
    embedding length    2048         
    quantization        Q4_K_M		# 4비트 양자화 모델       
    requires            0.30.0       

  Capabilities
    completion    
    vision        
    tools         
    thinking      

  Projector
    architecture        clip       
    parameters          446.57M    
    embedding length    1152       
    dimensions          2048       

  Parameters
    draft_num_predict    2       
    min_p                0       
    num_batch            512     
    presence_penalty     1.5     
    repeat_penalty       1       
    temperature          1       
    top_k                20      
    top_p                0.95    

  License
    Apache License               
    Version 2.0, January 2004    
    ...

 그리고 대망의 첫 대화입니다.

docker compose exec ollama ollama run --verbose qwen3.6:35b-a3b "안녕, 너는 누구니? 자기소개를 부탁해."

Thinking...
Thinking Process:

1.  **Analyze the user's input**: The user says "안녕, 너는 누구니? 자기소개를 부탁해
." (Hello, who are you? Please introduce yourself.). This is a direct question about 
my identity and origins in Korean.

2.  **Check instructions and capabilities**:
    *   I am Qwen, developed by Alibaba Group's Tongyi Lab.
    *   Tone: Empathetic, insightful, transparent, honest, helpful, clear, concise, 
balancing warmth and intellectual honesty.
    *   Adapt language to match user (Korean).

3.  **Drafting the response**:
    *   Greeting/Introduction: "안녕하세요! 저는 알리바바 그룹의 통이 연구소(Tongyi 
Lab)에서 독자적으로 개발한 대형 언어 모델인 **Qwen**(통이치엔원)입니다." (Hello! I am 
Qwen, a large language model independently developed by Alibaba Group's Tongyi Lab.)
    *   Elaborate on capabilities/identity: Keep it concise and helpful. "사용자의 질문
과 작업 요청을 다각도로 분석하고 심층적인 추론 및 문제 해결 능력을 바탕으로 명확하고 유
용한 답변을 드리는 것을 목표로 하고 있습니다." (I aim to provide clear and helpful 
answers by analyzing user questions from various angles and providing in-depth 
reasoning.)
    *   Offer help: "궁금한 점이 있거나 도움이 필요하신 부분이 있다면 언제든 편하게 말
씀해 주세요! 무엇을 도와드릴까요?" (If you have any questions or need help, feel free 
to ask! How can I assist you today?)

4.  **Review against guidelines**:
    *   Did I use the correct name? Yes, Qwen (통이치엔원).
    *   Is the tone appropriate? Yes, polite, warm, and helpful in Korean.
    *   Is it concise? Yes.

5.  **Final Polish (Korean)**:
    안녕하세요! 저는 알리바바 그룹의 통이 연구소(Tongyi Lab)에서 독자적으로 개발한 대형
 언어 모델, **Qwen(통이치엔원)**입니다. 💙

    복잡한 문제를 논리적으로 분석하고 다국어와 코딩을 포함한 다양한 작업을 원활하게 처
리하는 것을 목표로 합니다. 궁금한 점이 있거나 도움이 필요하신 부분이 있다면 언제든 편하
게 말씀해 주세요! 오늘 어떤 도움이 필요하신가요?
...done thinking.

안녕하세요! 저는 알리바바 그룹의 통이 연구소(Tongyi Lab)에서 독자적으로 개발한 대형 언
어 모델, **Qwen(통이치엔원)**입니다. 

복잡한 문제를 논리적으로 분석하고 자연스러운 대화는 물론 코딩, 다국어 번역 등 다양한 작
업을 지원하기 위해 설계되었습니다. 

궁금한 점이 있거나 도움이 필요하신 부분이 있다면 언제든 편하게 말씀해 주세요! 오늘 어떤
 도움을 드릴까요?

total duration:       18.661490367s
load duration:        401.678µs
prompt eval count:    24 token(s)
prompt eval cached:   20 token(s)
prompt eval duration: 127.582ms
prompt eval rate:     31.35 tokens/s
eval count:           607 token(s)
eval duration:        18.463421s
eval rate:            32.88 tokens/s

 약간의 생각과 함께 약 18초를 조금 넘는 시간에 응답을 하였습니다. 토큰 생성 속도도 약 33 tokens/s에 근접하여 나름 괜찮다고 느꼈습니다. 하지만, 이런 단발성 대화의 성능과 실제 Agent에서 사용할 때는 그 양상이 완전히 달라진다는 것을 이때는 몰랐습니다. 실제 Kagent에 LLM 백앤드로 붙여서 사용하면서 겪은 여러 문제점과 원인 추적, 그리고 그러면서 배운 LLM의 여러 개념들에 대해서 이어지는 시리즈 포스팅으로 계속 진행해 보도록 하겠습니다.

긴 글 일어주셔서 감사합니다.

이어서 2부 읽기

 이번 포스팅은 운영 중인 웹 서비스에서 처음 겪은 보안 사고의 기록입니다. 공격은 분산 스크래핑 봇넷이었습니다.

 사람과 멀티 AI 에이전트가 함께 공격을 감지하고, 진행 중인 공격의 패턴을 실시간으로 분석하고, 서비스가 받는 영향을 추적했습니다. 그리고 분석으로 확정한 방어 방법 하나를 단 한 번 적용해 공격을 무력화했습니다.

 마지막 장에서는 이 경험을 바탕으로 AI 에이전트를 통한 시스템 운영의 방향을 이야기해 보려 합니다.

1. 사건 요약

2. 사건 전개

2.1 배경

 바이브 코딩을 통해 만든 작은 웹 서비스를 하나 운영하고 있습니다. CNCF에 등재된 Graduated/Incubating 등급의 프로젝트의 새로운 릴리스 노트를 수집하여 분석해 주는 서비스입니다. 대중적인 주제는 아니어서 개설한 지 반년이 넘어가고 있는 시점이지만 사용자가 그렇게 많지는 않습니다.

 단, 최근에 Amazon Bot이나 GPT나 Google Gemini 같은 AI 크롤러들이 제 사이트를 발견하고 정보를 얻어가고 있어서 사람 사용자보다는 봇 사용자들이 조금씩 늘고있는 추세였습니다. 이에 조금 더 잘 발견되게 하기 위해 DNS for AI Discovery(DNS-AID) 설정을 하였습니다. 그리고 얼마 지나지 않아 Umami 대시보드에 방문자가 급증하는 것을 포착하게 됩니다.

2.2 인지

 그런데 이게 곧 정상적이지 않은 요청이라는 것을 알게 되었습니다. 미국, 브라질, 프랑스, 아르헨티나, 싱가폴, 파키스탄, 인도 등등... 세계 각지의 수십 개국으로부터 동일한 경로로 요청이 들어오고 있었습니다. 처음에는 앞서 설정한 DNS-AID가 작동하면서 나타난 현상이 아닌가 했는데 모든 요청들의 Visit duration이 1초인 것이 봇이라 하기에도 너무 짧았습니다.

2.3 관찰 및 분석

  공격이 시작된 시간은 2026년 8월 19일 20시부터 약 4시간 정도는 동시 접속 사용자가 약 20명 내외로 집계 되었으며 그 요청량도 그렇게 크지 않았습니다. 공격을 인지한 시점에 AI 에이전트를 통해 평소보다 많은 사용자 수에 대한 분석을 요청했습니다.

현재 Ratatosk에 비정상적으로 보이는 요청이 증가하고 있다.
모두 /release 페이지를 겨냥하고 있고 Visit duration도 모두 0초로 일반적인 패턴이 아니다.

공격으로 의심되는데 접속 로그를 분석해서 보고해 달라.

 AI 에이전트는 이에 지금 이 요청이 비정상적인 것은 맞다고 판단해 주었습니다. 그 근거로 동일 경로에 대한 동시 다발적인 접근, 그리고 비정상 적인 사이트 상주 시간을 근거로 들었습니다. 다만, 요청이 동시에 들어왔다가 다소 소강상태를 보이고 또 들어오는 파도와 같은 형식이고, 3~6 req/s 정도의 요청은 시스템에 부하를 일으키지 않는 수준이고 대부분은 웹 요청 처리 P95에도 이상이 없어 지켜보자는 입장이었습니다.

 저 역시도 이 판단에 동의해습니다. 기본적인 서버의 리소스 지표인 CPU나 메모리 사용률도 평소와 같았고 웹 서비스 품질도 문제가 없다 판단했기 때문입니다. 그렇게 약 5시간 정도를 지켜보다가 자정을 넘겨서 잠이 들었습니다. 물론 잠을 자지 않는 AI 에이전트에게 감시를 맡겨둔 상태로 말입니다.

 하지만, 아침에 일어나보니 밤새 이 미적지근한 공격이 계속 이어지고 있었습니다. 공교롭게도 잠을 청하고 얼마 지나지 않아 트래픽양이 두배로 늘어났고 또 얼마 지나지 않아 두배로 늘어나 있는 상태였습니다. 감시를 하고 있었던 AI 에이전트에게 보고를 요청했고 그 답변은 잠들기 전과는 심각도가 달라져 있었습니다. 밤 사이 계속된 공격으로 리소스 사용량은 확실히 올라가 있었으며 웹 요청 처리 P95도 영향을 받고 있었습니다. 10~21 req/s의 요청이 지속되면서 미리 설정해 둔 웹 서버의 초당 요청량 임계값도 넘어서고 있어 메신저를 통해 알람도 오고 있었습니다. 공격이 멈출 기세가 없었기 때문에 빠르게 AI 에이전트를 통해 분석을 요청하였습니다. AI 에이전트는 수많은 로그를 신속하게 검색하여 패턴을 찾아내고 아래와 같이 보고했습니다.

 분석이 있고 얼마 후 프록시 메모리가 임계치를 초과했다는 알람이 디스코드로 왔고 급하게 메모리 한도를 올려서 프록시가 OOM Killed 되는 것을 막았습니다. 바로 옵저버빌리티를 담당하는 에이전트에게 분석 내용을 파일로 전달하였고, 이를 기반으로 본격적인 메트릭과 로그 분석을 시작하였습니다. 옵저버빌리티 쪽 에이전트 역시 동일한 결론에 도달하였으며 Cloudflare의 보안 규칙을 통해 이를 해결할 수 있다고 하며 방법을 제시하였습니다.

2.4 대응과 조치

 그러는 와중에도 상황은 더욱 악화일로를 걸었습니다. 사건 경과 약 13시간 만인 2026년 8월 20일 오전 9시경 요청이 38 req/s에서 57 req/s로 점프합니다. 바로 이때 P95가 92ms에서 970ms로 올라가면서 순간 영향을 받았다가 일시 소강상태를 겪습니다. 이후 재급증하면서 P95가 2.2초로 급격히 나빠졌고 9시 30분이 조금 못된 시점에 서비스 품질이 최악으로 치닫기 시작합니다.

 웹 요청이 100 req/s를 넘어가면서 P95가 8.9초까지 올라갔으며 P99는 116초, 5xx 응답은 10분간 약 3600건이 발생하게 됩니다. 웹의 메트릭 앤드포인트가 무응답으로 프로브가 실패하여 옵저버빌리티 측에서 타겟 다운 크리티컬 알람이 울리기 시작합니다. 웹서버의 CPU 코어를 응급 증설 하였으나 부분적으로 효과가 있었을 뿐 즉시 재포화가 되어 효과가 없었습니다. 요청수는 140req/s를 넘어가고 있었으며 Umami의 방문자 통계는 이전 시간대와는 비교가 안될 정도로 무섭게 치솟고 있었습니다. 아마 이때 Umami에 집계된 동시 접속자 수가 300명이 넘었던 것으로 기억합니다.

 이는 도저히 하나의 인스턴스로 버틸 수 없다고 판단, 앞서 옵저버빌리티 측 AI 에이전트가 추천한 Cloudflare의 보안 규칙을 사용하기로 합니다. Managed Challenge를 공격 대상이 되는 경로에 설정하였습니다. 단, 앞서 이야기한 정상적인 AI 크롤링 봇(GPT, Amazon 봇 등)은 예외로 허용하였습니다. 규칙을 적용하자마자 약 4.3만 개의 요청이 이 규칙에 의해 무력하 되었으며 3분 만에 서비스 품질 완전 회복, 6분 내 공격 전면 차단 및 안정 상태에 돌입할 수 있었습니다. 이로서 약 14시간 동안 이어진 공격을 완전히 차단할 수 있게 되었습니다.

3. 사건 타임라인 및 분석과 교훈

3.1 사건 타임라인

3.2 분석과 교훈

 이번 공격을 통해 의외의 수확을 하나 할 수 있었는데, 벤치마크 테스트가 되었다는 겁니다. 웹 서비스가 올라간 인프라가 어디까지 버틸 수 있는지 이번에 확실하게 알게 되었습니다. 한계선은 요청 50 req/s 이하이며 그 이상이 되면 P95 품질 저하, 110 req/s 부근이면 서비스 붕괴 수준이라는 점입니다.

 또한 각종 지표들의 거동도 확인할 수 있었습니다. cpu 사용량이나 메모리 사용량은 요청에 따라 비교적 선형적으로 증가하지만 P95는 특정 임계를 넘는 순간 급격히 나빠지는 것도 확인할 수 있었습니다. 이는 큐잉의 특성으로 대기열이 처리열을 넘어가는 순간 폭주하는 큐잉으로 인해 급격히 서비스 품질의 저하가 발생하게 됩니다. 따라서, P95가 여유가 있다 하더라도 이것을 '지금은 괜찮다'라고 판단하면 안 된다는 교훈을 얻을 수 있었습니다.

 그리고 수직 확장은 이런 류의 공격에는 아무런 효과가 없다는 것 역시도 웹 서버의 CPU 증설을 통해 확인할 수 있었습니다. 이번의 경우에는 공격이라 차단을 통해 막을 수 있었으나 향후 대규모 서비스를 운영할 때에는 수직 확장이 아닌 탄력적인 수평 확장과 부하분산이 중요할 것이라는 너무나도 보편적인 진리(?)를 몸으로 느낄 수 있었습니다.

4. AI 에이전트의 활약

4.1 특화된 에이전트

 이번 공격을 알아차리고 즉시 AI 에이전트와 대처할 수 있었던 이유는 바로 각 기능마다 특하된 에이전트가 있어서 가능했습니다. 거창하게 AI 에이전트를 개발한 것은 아닙니다. 다만 웹 서비스와 옵저버빌리티를 구현하면서 느낀 점은, 개발과 운영 과정에서의 여러 결정 사항들을 컨텍스트 한계가 있는 AI 에이전트가 언제든지 그 맥락을 이해하고 궤도에 오를 수 있도록 하는 것이 중요하다 것이었습니다. 그래서 프로젝트 초기에 문서를 쓰는 규칙을 설정하고 그것이 자산이 될 수 있게 계속 쌓아왔습니다.

 물론 문서를 쌓기만 해서는 안됩니다. 모델의 성능이 떨어졌다는 느낌을 받을 때면 대부분 문서에 쌓인 결정이나 지시사항이 서로 모순을 일으키거나 충돌하는 경우가 대다수라 이런 부분을 한 번씩 정리하는 시간이 필요했습니다. 이를 통해 문서는 고도화하고, 메모리는 중요한 것들만 남김으로써 AI 에이전트의 성능을 원하는 상태로 유지하면서 각 서비스에 특화시킬 수 있었습니다.

4.2 에이전트 간의 협업

 사람만 협업하는 것은 아닙니다. AI 에이전트 간에도 협업이 가능합니다. 저는 어느 순간엔가 두 서비스를 담당하는 에이전트끼리 서로를 인지하고 대화가 필요하다는 것을 느끼기 시작했습니다. 특히 옵저버빌리티 스택을 구성할 때가 그랬습니다. 웹에서 나오는 기본적인 자원 메트릭은 매우 표면적인 상태만을 알 수 있습니다. 각 컨테이너에서 나오는 그들만의 메트릭과 애플리케이션 자체에서도 메트릭을 생산할 수 있다면 이를 통해 좀 더 세밀한 관측이 가능할 것이라 생각했습니다.

 하지만, 두 에이전트는 서로를 모르고 개별적으로 작업을 진행하고 있었기 때문에 이를 연결할 필요가 있었습니다. 그래서 처음에는 사람이 두 에이전트 간의 매개자 역할을 하였습니다. 프롬프트를 입력하고 나온 출력을 다른 에이전트에게 전달해주고, 그 응답을 다시 되돌려 주는 방식으로 작업을 진행했는데 한계가 있었습니다. 그래서 생각한 것이 문서를 서로 교환하게 하면 어떨까 였습니다. 문서는 그 내용이 남으니 사람도 그것을 추적할 수 있고, 에이전트도 문서가 많아져도 검색을 통해 쉽게 맥락을 다시 끌어올 수 있을 것이라 생각했습니다.

 이 방식은 생각보다 효과가 좋았습니다. 그래서 두 에이전트가 서로를 인지하고 있던 상황에서 이번과 같은 사건이 생겼고, 서로의 특성을 알던 에이전트들이 매우 면밀하게 협업하여 문제 상황을 진단하고 합의된 해결책을 도출해 낼 수 있었습니다.

4.3 빅테크들의 움직임

 이미 이런 요구를 알고 있던 빅테크들은 이에 대해 더욱 세련된 방식을 제시하고 있습니다. 2025년에 발표된 Google의 A2A 프로토콜이 그것이며, 앤트로픽에서 최근에 발표한 Cross-session messaging도 하나의 방식입니다. 하지만 이것은 제가 사용하고 있는 파일 기반의 에이전트간 통신과는 조금 다릅니다.
 우선 A2A의 경우 운영자 경계를 넘는 에이전트간 통신을 그 범위로 하고 있습니다. A2A는 서로 모르는 에이전트끼리의 발견과 인증, 위임을 전제로 하고 있으며 제가 운영하는 범위에서는 이런 요소가 없습니다. Cross-session messaging은 같은 호스트 내 Unix 소켓을 통한 세션 간의 통신으로 메시지를 기반으로 하여 휘발성을 가지고 있습니다. 저의 경우에는 같은 호스트에서 돌아가는 서로 다른 세션은 아니라 이것을 사용할 수 없는 상태입니다.

 어쨌든, 큰 틀에서는 서로 다른 AI 에이전트들이 어떻게 서로를 알아차리고 협업해 나갈 수 있는지에 대해 고민하며 나름대로 이를 구현해가고 있다고 보입니다.

 이번 봇넷 공격 사건을 통해 운영적인 측면에서의 교훈도 얻을 수 있었지만, 그간 쌓아온 AI 에이전트 사용 방식이 문제 해결에 빛을 발하기도 하였습니다. 특히 마지막 부분에 저의 독특한 운영 방식과, 이를 발전시킬 수 있는 방향이 있는지도 한번 더 고민해 봐야겠습니다.

 VMware vSphere의 공유 데이터 스토어로는 VMware vSAN을 사용한 HCI 구성하거나 혹은 외부 스토리지를 제공하는 방식이 있습니다. 외부 스토리지는 대표적으로 SAN과 NAS가 있을 수 있는데, 이번 포스팅에서는 Synology NAS의 SAN Manager를 활용, iSCSI를 통해 제공된 VMware vSphere 공유 데이터 스토어에 대한 튜닝을 통해 얼마나 성능 향상을 이룰 수 있는지 확인해 보도록 하겠습니다.

테스트 환경

• 스토리지 네트워크 MTU 1500: 점보 프레임 설정 시 ESXi 호스트가 먹통되는 문제 발생으로 기본값 사용
• 동일한 L2 네트워크에 NAS와 ESXi 호스트를 두어, 스위치 레벨에서 트래픽을 처리하도록 설계
• Synology NAS iSCSI LUN과 VM의 디스크 모두 Thick Provisioning 구성
• 캐시 효과 배제를 위해 NAS 물리 메모리 용량의 1.5배인 24GB로 테스트 데이터 설정

테스트 시나리오

 Test VM의 블록 디스크의 위치와, ESXi의 설정을 변경해 가면서 IOPS 성능의 변화를 측정합니다.

• 테스트 도구: Fio
• 방식
  • 테스트 시작 전 24GB 전체 영역에 데이터를 기록하는 과정을 선행하여 Test VM의 시스템 레벨의 할당 오버헤드 제거
  • 테스트 시 실제 데이터를 읽어 오도록 강제하여 MPIO 네트워크 대역폭과 디스크 I/O 성능을 정확히 타격하도록 설계
  • 각 테스트간 60초의 휴지 기간을 가지고 실행
• 측정 결과 집계: 총 3회를 측정하여 평균값을 도출

테스트 데이터 생성 스크립트

fio --name=warmup_fill \
    --filename=fio_test_file.dat \
    --ioengine=libaio \
    --rw=write \
    --bs=1M \
    --direct=1 \
    --numjobs=1 \
    --size=24G \
    --group_reporting

• 앞서 언급한 NAS의 캐시 효과 배제를 위해 NAS 물리 메모리의 1.5배인 24GB 테스트 데이터를 준비

테스트 스크립트

COUNT=3				# Test 횟수
OUTPUT_PREFIX="test name"		#fio 테스트 결과 파일 이름 prefix

echo "==== FIO 벤치마크 시작 (총 ${COUNT}회) ===="

for i in $(seq 1 $COUNT); do
    echo ""
    echo "[$(date '+%H:%M:%S')] ${i}회차 진입: 60초 대기 후 테스트 시작..."
    sleep 60

    echo "[$(date '+%H:%M:%S')] ${i}회차 측정 시작 (5분)..."
    fio --name=benchmark_mpio_test \
        --filename=fio_test_file.dat \
        --ioengine=libaio \
        --rw=randrw \
        --rwmixread=70 \
        --bs=4k \
        --direct=1 \
        --numjobs=4 \
        --size=24G \
        --runtime=300 \
        --time_based \
        --iodepth=32 \
        --group_reporting \
        --output-format=json \
        --output="${OUTPUT_PREFIX}_${i}.json"

    echo "[$(date '+%H:%M:%S')] ${i}회차 완료 -> ${OUTPUT_PREFIX}_${i}.json 저장됨"
done

iSCSI 설정 - 테스트 전 기본 설정

공통 설정 - IOPS 대기열 맞춤

• ESXi에서 확인되는 iSCSI 타겟 LUN의 대기열 크기와 Synology NAS의 iSCSI 서비스의 I/O 대기열 수준을 동일하게 설정

[비교군 1] MPIO 기본 설정

• 소프트웨어 스토리지 어댑터를 생성하고 NAS의 iSCSI 서버 IP 중 하나를 동적 검색으로 등록하면 다중 경로 설정이 자동으로 생성
• 다중 경로 지정 정책의 기본 정책은 가장 최근에 사용됨(VMware)로 이는 NAS에서 제공하는 경로 중 가장 최근에 사용된 경로를 계속 사용하는 것으로, 해당 경로가 실패할 때 다른 경로로 변경됨(Active - Standby 설정)

[비교군 2] 라운드 로빈 기본 설정

• 라운드 로빈 정책을 통해 다중 경로를 돌아가면서 사용할 수 있도록 선택
• 라운드 로빈 기본 설정값은 1000 IOPS 마다 경로를 변경

# esxi 호스트에 shell로 접근 후 아래 명령어를 수행
# Storage device list 확인
esxcli storage nmp device list | grep -i "Device Display Name" -B 1

naa.6001405722e8deed16d2d4662d8c32df
   Device Display Name: SYNOLOGY iSCSI Disk (naa.6001405722e8deed16d2d4662d8c32df)
--
naa.60014056b78746cda247d45dbd8576de
   Device Display Name: SYNOLOGY iSCSI Disk (naa.60014056b78746cda247d45dbd8576de)
--
naa.6001405e5b0f035db767d4b26da2d1da		# 튜닝 대상 데이터 스토어
   Device Display Name: SYNOLOGY iSCSI Disk (naa.6001405e5b0f035db767d4b26da2d1da)
   
# 데이터 스토어 기본 IOPS 정책 확인
esxcli storage nmp psp roundrobin deviceconfig get -d naa.6001405e5b0f035db767d4b26da2d1da

   Byte Limit: 10485760
   Device: naa.6001405e5b0f035db767d4b26da2d1da
   IOOperation Limit: 1000			# 1000 IOPS 마다 경로 변경이 기본 설정
   Latency Evaluation Interval: 0 milliseconds
   Limit Type: Default				# 기본 라운드 로빈 정책
   Number Of Sampling IOs Per Path: 0
   Use Active Unoptimized Paths: false

[비교군 3] 라운드 로빈 IOPS 정책 수정

# 위에서 살펴본 튜닝 대상 디스크에 대해서 아래 명령어를 실행하여 IOPS 정책을 변경
esxcli storage nmp psp roundrobin deviceconfig set --type=iops --iops=1 --device=naa.6001405e5b0f035db767d4b
26da2d1da

# 정책 변경 확인
esxcli storage nmp psp roundrobin deviceconfig get -d naa.6001405e5b0f035db767d4b26da2d1da

   Byte Limit: 10485760
   Device: naa.6001405e5b0f035db767d4b26da2d1da
   IOOperation Limit: 1			# 1 IOPS 마다 경로 변경 정책 설정됨
   Latency Evaluation Interval: 0 milliseconds
   Limit Type: Iops			# IOPS 기준으로 경로 변경 정책 설정됨
   Number Of Sampling IOs Per Path: 0
   Use Active Unoptimized Paths: false

• 1 IOPS 마다 iSCSI 경로를 변경하도록 설정하여 극한의 성능 향상을 노리는 설정

[비교군 4] 라운드 로빈 IOPS 정책 수정 + Synology NAS I/O 정책 변경

• LUN에 대한 I/O 버퍼를 해제하고 직접 디스크에 읽고 쓰는 설정을 활성화
• 데이터가 물리 디스크에 안전하게 기록되었음을 확인할 때까지 완료 신호를 주지 않는 설정으로 안정성 향상의 목적

테스트 결과 및 심층 분석

 총 4가지 시나리오에 대한 FIO 벤치마크 결과, iSCSI MPIO 튜닝(라운드 로빈 IOPS=1)이 단일 물리 네트워크 환경에서 드라마틱한 성능 향상을 가져옴을 확인했습니다. 하지만 이면에는 운영 입장에서 반드시 알아야할 Trade-off가 숨겨져 있는것도 확인할 수 있었습니다.

테스트 결과

심층 분석

Insight 1. 기본값(Default)의 함정: 대역폭 낭비

 가장 먼저 눈에 띄는 것은 기본 설정인 [비교군 1] - MPIO 기본 설정과 [비교군 2] - 라운드 로빈 기본 설정의 비효율성 입니다.

• 현상: [비교군 1]과 [비교군 2]의 설정에서는 대역폭이 약 68 - 78 MB/s에 머물렀습니다. 이는 1 Gbps 네트워크의 최대 한계의 60 - 70% 수준 밖에 활용하지 못하는 수준입니다.
• 원인: TCP 단일 세션의 한계입니다. ESXi가 단일 경로를 고집하거나[비교군 1] 경로 변경 주기가 너무 길면[비교군 2], 4K 랜덤 I/O와 같은 작은 블록 전송 시 윈도우 사이즈와 응답 대기(RTT)로 인해 물리 대역폭을 가득 채우지 못합니다. 고속도로는 뚫려 있는데 톨게이트를 하나만 열어둔 셈입니다.

Insight 2. IOPS=1 튜닝: 물리적인 최대치에 도달

 라운드 로빈 정책의 경로 변경 임계값을 1 IOPS로 수정[비교군 3]한 후, 생각보다 놀라운 성능 향상이 관찰되었습니다. 구형 NAS임에도 불구하고 예상보다 고무적인 수치가 나와주었습니다.

• 성과: 대역폭이 107.58MB/s까지 치솟았습니다. 이는 이더넷 오버헤드를 제외하면 사실상 1Gbps 물리 회선을 95% 이상 포화 시킨 수치입니다.
• 핵심: 물리적인 업링크는 1개뿐이지만, '다중 세션(Multi-Session)' 효과를 톡톡히 봤습니다. 1 IOPS마다 경로를 바꿔가며 NAS의 여러 포트로 세션을 분산시켰고, 이를 통해 I/O 큐(Queue)를 병렬로 처리하여 단일 세션의 병목을 소프트웨어적으로 극복해냈습니다.

Insight 3. 속도와 안정성의 Trade-off (P99 Latency & Kubernetes)

 하지만 모든 지표가 긍정적인 것만은 아닙니다. 하위 1%의 느린 응답 속도를 나타내는 P99 Latency의 변화를 주목해야 합니다. 특히 Kubernetes 관점에서 말이죠.

• 현상: 평균 성능은 좋아졌지만, P99 Latency는 **14.99ms(MRU) → 21.8ms(Tuned)**로 오히려 악화되었습니다. 이는 대역폭 포화로 인한 네트워크 큐잉 지연(Queuing Delay) 때문입니다.
• Kubernetes 환경에서의 의미: 이 수치는 etcd와 같은 민감한 워크로드에 치명적일 수 있습니다. etcd는 쓰기 작업마다 fsync를 수행하는데, P99 지연시간이 지속적으로 20~30ms를 넘어가면 리더 선출(Leader Election) 실패나 API 서버 응답 저하로 이어질 수 있습니다. 즉, 처리량(Throughput)을 얻는 대신 응답의 균일성(Stability)을 일부 희생한 결과입니다.

Insight 4. 벤치마크와 현실의 차이: 단일 vs 다중 워크로드

 이번 테스트 결과는 단일 VM이 스토리지를 독점할 때의 최대 성능이라는 점을 기억해야 합니다.

• Noisy Neighbor: 실제 운영 환경에서 여러 VM이 동시에 부하를 준다면(Multi-Workload), NAS의 대기열이 가득 차면서 Latency는 이보다 훨씬 더 튀게 될 것입니다.
• 의의: 따라서 이 결과값(27k IOPS)은 항상 보장되는 성능이 아니라, 이 인프라가 견딜 수 있는 물리적 한계점(Baseline)으로 해석하는 것이 타당합니다.

번외 분석: NAS 쓰기 캐시(Bufferd I/O)는 필수인가?

 마지막으로 데이터 무결성을 위해 직접 I/O를 활성화했을 때의 결과는 상당히 실망스러웠습니다.

• 성능 붕괴: 쓰기 지연시간(Avg)이 47.69ms로 튜닝 전보다도 6배 이상 느려졌으며, 전체 대역폭은 31.92 MB/s로 곤두박질쳤습니다.
• 교훈: SATA SSD 기반의 RAID 5 환경에서는 '패리티 연산(Read-Modify-Write)' 오버헤드가 매우 큽니다. 이를 NAS의 RAM 캐시가 받아주지 못하면, 아무리 네트워크를 튜닝해도 디스크단에서 병목이 발생함을 알 수 있습니다. 따라서 홈랩 환경에서는 성능은 버퍼(Cache)로 챙기는 것이 현실적인 정석입니다.

결론 및 제언: 성능과 안정성의 균형 찾기

 이번 실험을 통해 단일 1Gbps 망에서도 iSCSI 튜닝은 선택이 아닌 필수라는 점을 증명했습니다. 하지만 단순히 설정을 바꿨다고 끝이 아닙니다. 다음의 운영 전략이 병행되어야 합니다.

1. 최적의 튜닝 조합

 단일 1Gbps 링크의 물리적 한계를 극복하기 위해서는 라운드 로빈 (IOPS=1) 설정과 NAS의 쓰기 캐시(Buffered I/O 활성화가 가장 효과적인 해법임이 확인되었습니다. (대역폭 약 57% 향상)

2. 현실적인 운영 해법 (Hybrid Approach)

 하지만 앞서 분석했듯, 이 설정은 네트워크를 한계까지 밀어붙여 P99 Latency를 불안정하게 만들 수 있습니다. 따라서 Kubernetes와 같은 민감한 워크로드를 운영한다면 다음과 같은 전략을 추천합니다.

• 기반 설정: 스토리지 성능 극대화를 위해 RR IOPS=1을 유지합니다.
• 안정성 확보: ESXi 레벨에서 VM별 IOPS 제한(Limit)이나 SIOC(Storage I/O Control)를 적용합니다.
  • 일반 VM: IOPS를 적절히 제한하여 스토리지 큐를 독점하지 못하게 방지
  • 중요 VM (etcd/Control Plane): 제한을 풀거나 높은 우선순위(Shares)를 부여하여 Latency 보장

3. 마무리

 이번 테스트는 단순히 숫자를 높이는 튜닝이 아니라, 제한된 홈랩 자원 환경에서 성능·안정성·운영 복잡도 사이의 균형점을 어디에 두어야 하는지를 고민하는 과정이었습니다.

 스토리지 튜닝에 ‘무조건적인 정답’은 없습니다. 내 인프라의 한계를 명확히 알고, 워크로드의 성격에 맞춰 의도적으로 Trade-off를 선택하는 것이야말로 엔지니어링의 핵심임을 다시 한번 확인할 수 있었습니다.

[서론] 컨테이너가 죽지 않아!

 운영 중인 Kubernetes 노드에서 컨테이너 런타임(Containerd)을 업데이트하거나 재시작해야 할 때가 있습니다. 상식적으로 생각해 보면 부모 프로세스인 데몬이 종료되면, 그 자식 프로세스인 컨테이너들도 함께 종료되거나 고아(Orphan)가 되어 문제가 생겨야 할 것 같습니다. 하지만 실제로 그런일은 일어나지 않습니다. 서비스 중인 컨테이너(Pod)들은 아무런 영향 없이 계속 동작합니다. 어떻게 이것이 가능할까요? 도대체 리눅스 커널에서는 어떤 일이 벌어지고 있는 걸까요? 이 '죽지 않는 컨테이너'의 비밀을 풀기 위해 프로세스 트리의 족보를 파해져 보았습니다.

장비를 정지합니다. 정지하겠습니다. 어? 안 되잖아?

 이번 포스팅에는 잘 작동하고 있는 Kubernetes 클러스터의 Control plane 노드(Locky Linux 10, root 사용자 환경)에서 진행됩니다.

 위와 같이 잘 작동하고 있는 Kubernetes 클러스터가 있습니다. API 서버도 잘 작동중이고, Containerd 프로세스도 문제없이 작동 중입니다. 이제 Containerd 프로세스를 정지시켜 보겠습니다. 그리고 Kube-apiserver가 잘 응답하는지 확인해 보겠습니다.

# Conatinerd 프로세스 중지
systemctl stop containerd

# kube-apiserver Port 확인 및 kubectl 응답 확인
ss -nltp | grep 6443

kubectl get pods -n kube-system | grep api

 분명 Containerd 서비스는 중지 되었지만, 여전히 6443 포트는 LISTEN 상태이고, kubectl을 통해서도 문제없이 Kubernetes 클러스터와 통신이 가능합니다. 정말 컨테이너가 죽지 않습니다. 그런데 Containerd 프로세스의 상태를 자세히 살펴보면 Cgroup 필드에 특이한 점을 발견할 수 있습니다.

• 앞서 존재했던 1088523 containerd 프로세스(/usr/local/bin/containerd)가 보이지 않음
• 그러나 여전히 containerd-shim-runc-v2라는 프로세스들은 여러 개가 보임

 일반적으로 프로세스가 중지되고 나면 Cgroup 필드 자체가 표시되지 않는데 Containerd는 Cgroup 필드가 살아 있습니다. 도대체 왜 이런 현상이 일어나고 있을까요?

[관찰] 족보가 이상한데요...? feat. pstree

 Containerd 프로세스가 중지 되었는데도 컨테이너(Pod)가 문제없이 작동한다는 것은, 아무래도 containerd와 컨테이너(Pod)가 서로 부모-자식 관계가 아닌것일지도 모르겠다는 추측을 하게 합니다. (리눅스 프로세스의 부모-자식 관계에 대한 상세한 내용은 이전 포스팅을 참고해 주세요.) 다음 명령어를 통해서 프로세스 트리를 확인해 봅시다.

# Conatinerd process 재시작
systemctl start containerd

# 프로세스 트리 확인
pstree

 pstree를 통해 살펴보면 위에서 확인할 수 있듯, containerd와 containerd-shim은 부모-자식 관계가 아닌 형제 관계인것 처럼 보입니다. 예상했던 예상밖의(?) 결과입니다. 우선 여기서 확실하게 확인되는 것은 컨테이너(Pod)와 containerd 프로세스는 확실히 부모-자식 관계가 아니라는 점이고, 이 때문에 containerd 프로세스가 중지되거나 재시작되어도 컨테이너(Pod)는 아무 문제 없이 잘 작동할 수 있었던 것입니다. 그런데 containerd-shim은 도대체 무엇일까요? 왜 이 프로세스들이 컨테이너(Pod)들의 부모 프로세스의 위치를 가지고 있을까요?

[실험] 왜 컨테이너들이 containerd-shim의 자식이 되어 있을까?

커널에서는 무슨 일이 일어났던 것일까?

 strace 명령어를 사용하여 커널 레벨에서의 시스템 콜(System Call)을 추적, 컨테이너(Pod)가 생성될 때 실제로 어떤 일들이 벌어지고 있는지 확인해 봅시다. 현재 우리가 살펴보고 있는 컨트롤 플레인 노드에서 Pod를 고정적으로 생성하기 위해 Static Pod를 사용할 예정입니다. 다음과 같은 명령어를 통해 Static pod를 생성하고, 시스템 콜을 추적해 봅시다.

# containerd 프로세스의 시스템 콜을 추적
sudo strace -f -e trace=clone,execve,exit_group,prctl -p $(systemctl show containerd -p MainPID --value) 2>&1 | grep -v "SIGURG"
# 새로운 터미널 창을 열고 control plane에 접근
# nginx.yaml 파일 생성
kubectl run nginx --image=nginx --dry-run=client -o yaml > nginx.yaml

# static pod 생성
mv nginx.yaml /etc/kubernetes/manifests/

# 프로세스 트리 확인
pstree

 strace와 pstree 명령어를 통해 확인할 수 있는 로그 및 프로세스 트리는 위 Github 레포 링크에서 자세하게 살펴볼 수 있습니다. 우선 pstree.txt 파일을 살펴보면 containerd의 PID는 1108358이고 nginx static pod의 부모인 containerd-shim의 PID는 1224703이며 pause 컨테이너의 PID는 1224727, nginx 컨테이너의 PID는 1224754 임을 확인할 수 있습니다. 이 프로세스들이 언제 어떻게 탄생했는지는 strace.logs 파일을 통해 확인할 수 있습니다.

# nginx Pod의 부모 프로세스 PID 1224703 생성
165 [pid 1224700] clone(child_stack=NULL, flags=CLONE_VM|CLONE_PIDFD|CLONE_VFORK|SIGCHLDstrace: Process 1224703 attached
166  <unfinished ...>

# PID 1224703 프로세스의 containerd-shim 실행
167 [pid 1224703] execve("/usr/local/bin/containerd-shim-runc-v2", ["/usr/local/bin/containerd-shim-r"..., "-namespace", "k8s.i    o", "-id", "c8b394369634a6c6755d4e9094907a92"..., "-address", "/run/containerd/containerd.sock"], 0xc000170900 /* 14 vars *    / <unfinished ...>
168 [pid 1224700] <... clone resumed>, parent_tid=[12]) = 1224703

# containerd-shim의 부모 프로세스였던 PID 1224700 프로세스 그룹 종료
169 [pid 1224703] <... execve resumed>)     = 0
170 [pid 1224700] exit_group(0)             = ?
171 [pid 1224701] +++ exited with 0 +++
172 [pid 1224696] +++ exited with 0 +++
173 [pid 1224699] +++ exited with 0 +++
174 [pid 1224695] +++ exited with 0 +++
175 [pid 1224700] +++ exited with 0 +++
176 [pid 1224698] +++ exited with 0 +++
177 [pid 1224697] +++ exited with 0 +++
178 [pid 1224694] +++ exited with 0 +++

 먼저 containerd-shim(PID 1142827)이 생겨나는 과정을 뜯어봅시다. 위 내용은 containerd-shim이 독립하여 systemd(PID 1)에 입양되어 containerd와 형제 프로세스가 되는 부분의 로그입니다. 중간 과정이 약간 생략되었지만, 큰 틀은 아래 그림과 같습니다.

 contianerd로부터 생성된 프로세스 PID 1224700가 PID 1224703을 생성한 후 종료되면서, containerd-shim(PID 1224703)이 고아(Orphan) 상태가 되고 systemd(PID 1)이 이를 입양, containerd와 형제 프로세스가 되는 것입니다.

그럼 컨테이너(Pod)는 언제 생겼을까?

 다시 pstree를 상세하게 뜯어보겠습니다. containerd-shim(PID 1224703)의 자식 프로세스로 nginx(PID 1224754)과 pause(PID 1224727)이 보입니다. 그런데 그 어디를 살펴보아도 Pod는 보이지 않습니다. 그 이유는 Pod는 Kubernetes가 만든 논리적인 그룹일 뿐, 리눅스 커널에는 존재하지 않는 객체이기 때문입니다. 여기서 Kubernetes의 Infra 컨테이너(또는 sandbox 컨테이너)라는 개념이 등장합니다. Infra 컨테이너가 바로 pause(PID 1224727)이고 이것이 Pod의 구현체입니다. Kubernetes는 Pod라는 논리적 그룹을 구현하기 위해 리눅스 네임스페이스 기능을 사용하는데, 이 네임스페이스는 최소한 하나의 프로세스가 그 안에 살아 있어야만 유지됩니다. 이를 위해 아무 일도 하지 않지만 네임스페이스를 유지할 수 있는 프로세스인 pause를 생성하여 sandbox 환경(Pod)을 구현하게 됩니다. 그럼 이 pause 컨테이너가 어떤 과정을 통해 생성되고 있는지 strace 로그를 통해 추적해 보겠습니다.

# pause(PID 1224727) 프로세스 추적

# pause(PID 1224727)의 부모는 PID 1224726 확인
# PID 1224726의 부모는 PID 1224723 확인
# pause(PID 1224727) 프로세스 생성 후 부모 프로세스(PID 1224726), 조부모 프로세스(PID 1224723) 모두 종료
235 [pid 1224723] clone(child_stack=0x7ffec80fe4c0, flags=CLONE_PARENT|SIGCHLDstrace: Process 1224726 attached
236 ) = 1224726
237 [pid 1224726] prctl(PR_SET_NAME, "runc:[1:CHILD]") = 0
238 [pid 1224726] clone(child_stack=0x7ffec80fe4c0, flags=CLONE_PARENT|SIGCHLDstrace: Process 1224727 attached
239 ) = 1224727
240 [pid 1224727] prctl(PR_SET_NAME, "runc:[2:INIT]") = 0
241 [pid 1224726] exit_group(0)             = ?
242 [pid 1224726] +++ exited with 0 +++
243 [pid 1224714] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1224726, si_uid=0, si_status=0, si_utime=0, si_stim    e=0} ---
244 [pid 1224723] exit_group(0)             = ?
245 [pid 1224723] +++ exited with 0 +++

# PID 1224723 부모는 PID 1224714
226 [pid 1224714] clone(child_stack=NULL, flags=CLONE_VM|CLONE_PIDFD|CLONE_VFORK|SIGCHLDstrace: Process 1224723 attached

# PID 1224714의 부모는 PID 1224711
# PID 1224711은 정확히는 프로세스가 아니라 스레드
207 [pid 1224711] clone(child_stack=NULL, flags=CLONE_VM|CLONE_PIDFD|CLONE_VFORK|SIGCHLDstrace: Process 1224714 attached

# 스레드 PID 1224711의 부모는 스레드 PID 1224709
197 [pid 1224709] clone(child_stack=0xc00022c000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|    CLONE_SETTLS
strace: Process 1224711 attached

# 스레드 PID 1224709의 부모는 스레드 PID 1224706
# 191 라인의 로그 뒷 부분을 분리해서 보아야 함
190 [pid 1224706] clone(child_stack=0xc00021a000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|    CLONE_SETTLS
<unfinished ...>
191 strace: Process 1224709 attached
193 [pid 1224706] <... clone resumed>, tls=0xc00005b198) = 1224709

# 스레드 PID 1224706의 부모는 PID 1224703(containerd-shim 프로세스)
184 [pid 1224703] clone(child_stack=0xc000070000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|    CLONE_SETTLS
strace: Process 1224706 attached
185 , tls=0xc000058e98) = 1224706

# 주요 포인트! - containerd-shim(PID 1224703)으로 부터 생성되는 스레드 PID 1224710의 생성
182 [pid 1224703] clone(child_stack=0xc000074000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|    CLONE_SETTLSstrace: Process 1224705 attached
183 , tls=0xc000058798) = 1224705

# (PR_SET_CHILD_SUBREAPER, 1) 속성을 추가하는 스레드 PID 1224710
191 [pid 1224705] clone(child_stack=0xc000216000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|    CLONE_SETTLS
192  <unfinished ...>
195 [pid 1224705] <... clone resumed>, tls=0xc000100798) = 1224710
196 [pid 1224710] prctl(PR_SET_CHILD_SUBREAPER, 1) = 0

 Pause 컨테이너 하나를 생성하는데도 이렇게 많고 복잡한 과정을 거칩니다.(심지어 이것도 많은 단계들이 생략된 것입니다.)이 복잡한 과정의 주요 내용을 요약해 보면 다음과 같습니다.

하청의 하청... 저수준 컨테이너 런타임 runc의 역할

 Kubernetes에서 Pod 생성 요청이 들어오면 노드의 kubelet 데몬이 container runtime(containerd)에게 컨테이너 생성을 명령합니다. 그러면 그 명령을 받은 containerd는 containerd-shim을 통해 컨테이너 프로세스를 구동시킵니다. 그런데, 사실 containerd-shim 역시도 직접 컨테이너를 만드는 것이 아니라 runc라는 저수준 컨테이너 런타임을 통해 실제 컨테이너를 생성합니다. 정말 하청에 하청을 몇 번이나 내리는지...

 다시 한번 strace.logs 파일을 살펴봅시다. Pause 컨테이너와 Nginx 컨테이너가 생성되는 시점을 유심히 살펴보면서 runc가 어떤 역할을 하는지 알아봅시다. 이번에는 PID 1224714를 중심으로 살펴보겠습니다. 그 이유는 PID 1224714가 runc를 실행하기 때문입니다.

# containerd-shim의 스레드인 PID 1224711이 PID 1224714 프로세스를 생성
[pid 1224711] clone(child_stack=NULL, flags=CLONE_VM|CLONE_PIDFD|CLONE_VFORK|SIGCHLDstrace: Process 1224714 attached
[pid 1224714] prctl(PR_SET_PDEATHSIG, SIGKILL) = 0

# PID 1224814 프로세스가 runc 명령어를 실행하면서 runc로 변형됨 
# runc create 명령을 통해 컨테이너 격리공간(Namespace, Cgroups)만 만들고, 프로세스는 실행하지 않음
[pid 1224714] execve("/usr/local/bin/runc", ["/usr/local/bin/runc", "--root", "/run/containerd/runc/k8s.io", "--log", "/run/containerd/io.containerd.ru"..., "--log-format", "json", "--systemd-cgroup", "create", "--bundle", "/run/containerd/io.containerd.ru"..., "--pid-file", "/run/containerd/io.containerd.ru"..., "c8b394369634a6c6755d4e9094907a92"...], 0xc000283030 /* 13 vars */ <unfinished ...>
[pid 1224711] <... clone resumed>, parent_tid=[15]) = 1224714
[pid 1224714] <... execve resumed>)     = 0
[pid 1224714] prctl(PR_SET_CHILD_SUBREAPER, 1) = 0
[pid 1224714] clone(child_stack=NULL, flags=CLONE_VM|CLONE_PIDFD|CLONE_VFORKstrace: Process 1224722 attached
[pid 1224714] <... clone resumed>, parent_tid=[17]) = 1224722

# PID 1224714는 PID 1224723을 생셩
# PID 1224723이 runc init을 사용하여 컨테이너 초기화 작업을 진행
# 이후 PID 1224726 > Pause 컨테이너(PID 1224727)로 이어지는 과정
[pid 1224714] clone(child_stack=NULL, flags=CLONE_VM|CLONE_PIDFD|CLONE_VFORK|SIGCHLDstrace: Process 1224723 attached
[pid 1224723] execve("/proc/self/fd/6", ["/usr/local/bin/runc", "init"], 0xc0001ff7c0 /* 7 vars */ <unfinished ...>
[pid 1224714] <... clone resumed>, parent_tid=[18]) = 1224723
[pid 1224723] <... execve resumed>)     = 0
[pid 1224723] prctl(PR_SET_DUMPABLE, SUID_DUMP_DISABLE) = 0
[pid 1224723] prctl(PR_SET_NAME, "runc:[0:PARENT]"...) = 0
[pid 1224723] clone(child_stack=0x7ffec80fe4c0, flags=CLONE_PARENT|SIGCHLDstrace: Process 1224726 attached
[pid 1224723] exit_group(0)             = ?
[pid 1224723] +++ exited with 0 +++
[pid 1224714] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1224726, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
[pid 1224714] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1224723, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
[pid 1224714] exit_group(0)             = ?
[pid 1224714] +++ exited with 0 +++
[pid 1224711] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1224714, si_uid=0, si_status=0, si_utime=0, si_stime=1 /* 0.01 s */} ---

 위 내용을 해석해 보면 다음과 같습니다.

1. containerd-shim의 스레드인 PID 1224711이 프로세스 PID 1224714를 생성
2. 프로세스 PID 1224714는 'runc create'로 Namespace와 Cgroups만 만들고 일시 중지
3. PID 1224714가 PID 1224723을 생성하여 'runc init'으로 컨테이너 프로세스 초기화 진행
4. 이후 PID 1224726 생성 → Pause 컨테이너(PID 1224727) 생성으로 이어짐

 여기서 한 가지 짚고 넘어가야 할 것이 있습니다. 바로 PID 1224723과 PID 122476입니다. 다른 프로세스와 다르게 이들만 특별하게 CLONE_PARENT 설정을 사용하고 있는데, 이는 runc의 특별한 역할 때문입니다. runc의 역할은 오로지 컨테이너 생성과 실행에만 있으며, 이것이 끝나면 바로 종료됩니다. 따라서 CLONE_PARENT 옵션을 통해 미리 고아가 될 컨테이너 프로세스의 부모를 더 상위 프로세스로 지정해 주어 프로세스 상속 관계의 안정성을 확보합니다.

 참고로, runc는 OCI(Open Container Initiative) 표준을 준수하는 저수준 런타임으로 containerd가 이를 사용함으로 해서 역시 OCI 표준을 만족할 수 있게 되는 것입니다.

 추가로 Nginx 컨테이너(PID 1224754) 역시도 그 프로세스를 추적해 보면 우리가 지금까지 Pause 컨테이너를 추적했던 것과 거의 흡사한 내용을 확인할 수 있을 것입니다.

[분석] 왜 containerd는 containerd-shim을 입양 보냈을까?

 왜 이런 복잡한 과정을 거쳐서 컨테이너를 만들까요? 이것이 바로 Daemonless Architecture라는 설계 철학의 구현이기 때문입니다. 만약 containerd-shim이 containerd의 자식 프로세스라면 container runtime 업그레이드와 같은 상황에서 모든 서비스가 중지되는 문제가 발생할 것입니다. 하지만 containerd-shim을 의도적으로 고아(Orphan)로 만들고 systemd로 입양 보내면서 container runtime과 컨테이너 프로세스 간의 결합도를 분리하고 고가용성을 확보할 수 있게 된 것입니다.

 또한, runc의 경우에는 의도적으로 컨테이너 프로세스의 부모 프로세스로 존재하지 않게 하기 위해 CLONE_PARENT 옵션을 주어 실행, 미리 더 상위 프로세스로 입양되게 하여 프로세스 상속 관계의 안정성을 확보하는 것은 매우 영리한 설계라 할 수 있겠습니다.

[결론 및 예고] 리소스를 통제하는 보이지 않는 손: Cgroup

 지금까지 프로세스 트리가 어떻게 '생명 주기'의 안정성을 위해 분리되었는지 확인해 보았습니다. Daemonless Architecture와 영리한 결합도 분리를 통해 시스템 안정성을 확보하기 위해 이런 복잡한 과정을 거친다는 것이... 리눅스 시스템은 파고들수록 정교하면서도 또 이해하기에 어렵다고 느껴집니다. 그런데 여기서 한 가지 의문이 듭니다.

분명 containerd와 containerd-shim은 서로 남남이 되었는데 어째서 systemctl status containerd 명령어에서 Cgroup에 함께 보일까?

 다음 포스팅에서는 pstree 뒤에 숨겨진 리소스를 통제하는 보이지 않는 손 Cgroup과 Systemd Slice의 이중적인 구조에 대해서 파해쳐 보도록 하겠습니다.

 지난 포스팅에서 Oracle Cloud(이하 OCI)에서 무료로 제공하는 클라우드 리소스와, OCI CLI를 설치하고 세팅하는 방법에 대해서 알아보았습니다. 이번 포스팅에서는 IPsec VPN을 사용, BGP Site-to-Site VPN을 구현하여 OCI(Cloud)와 홉랩(On-premise)을 연결함으로써 하이브리드 클라우드 환경의 기본인 사이트 간 네트워크 연동을 구성하는 방법에 대해 알아보겠습니다.

1. 하이퍼바이저를 통한 인프라 가상화에서 Kubernetes Native로: Site-to-Site VPN 도입 배경

 지금까지 운영하던 홈랩은 On-premise 데이터센터를 모방한 모습이었습니다. 물론, 데이터 센터의 발끝도 따라가지 못했지만 그래도 하이퍼바이저를 통해 인프라를 가상화 하고, OPNsense를 통해 네트워크 Segmentation을 실현하여 용도에 맞게 네트워크를 격리하여 운영할 수 있었습니다.

 그러나 얼마전, 하이퍼바이저를 통한 인프라 가상화 환경을 버리고 Kubernetes Native 환경을 구축하기로 계획을 세웠습니다. 그러면서 자연스럽게, 지금까지 매뉴얼 한 인프라 조작 방식을 IaC(Infrastructure as Code)로 전환하기로 마음먹었습니다. 이를 구현하기 위해서 Cluster API를 도입이 필요하다 판단하였고, 이를 구현하기 위해 추가적인 인프라가 필요했습니다. Cluster API의 Management 클러스터 역할을 수행할 Kubernetes 클러스터가 필요했는데 이를 클라우드를 사용해서 구성해 보면 어떨까 하는 생각을 하게 되었습니다.

 가장 비용이 저렴하면서도 적당한 성능을 제공하는 클라우드 서비스를 찾던 중 눈에 띈것이 OCI였습니다. 그렇다면 OCI 내의 인프라와 홈랩을 구성하는 리소스들 간에 통신이 필요하게 됩니다.

 물론 퍼블릭 네트워크를 통해서도 충분히 구성이 가능하겠지만, Enterprise 환경을 모사하기 위해서 Site-to-Site VPN을 도입하기로 결정합니다. 이를 통해, 클라우드 인프라와 홈랩 리소스 간에 암호화된 통신을 제공하여 보안성과 기밀성을 향상할 수 있으며 두 Site 간의 네트워크를 L3 영역에서 통합할 수 있게 되어 더욱 유연한 인프라 구성이 가능할 것이라 판단하였습니다.

2. Site-to-Site VPN 구축을 위한 준비

1) 네트워크 준비

 Site-to-Site VPN을 구축하기 위해서는 우선적으로 두 Site간에 네트워크 CIDR 설계가 필요합니다. 두 Site가 VPN을 통해 거대한 L3 네트워크로 통합되기 때문에 네트워크 CIDR이 겹치게 되면 통신에 문제가 발생할 수 있습니다. 게다가 저의 경우 Cilium BGP Controlplane을 통해서 Service와 Pod CIDR을 투명하게 물리 네트워크 레벨로 광고할 계획까지 가지고 있기 때문에 네트워크 설계에 조금 더 주의가 필요했습니다. 아래 표는 네트워크 설계의 큰 틀로 이를 기반으로 상세한 네트워크를 설계하였습니다.

2) 인프라 준비

 OCI에는 VCN(Virtual Cloud Network, AWS의 VPC와 동일한 개념)와 Public Subnet이 필요합니다. 그리고 On-premise 환경(홈랩)에는 CPE(Customer-Premises Equipment)가 될 IPsec을 지원하는 장비가 필요합니다. 이번 포스팅에서는 공인 IP를 받는 OPNsense가 CPE 역할을 할 것입니다.

3. Site-to-Site VPN 네트워크 토폴로지

 다소 복잡한 Site-to-Site VPN의 토폴로지입니다. 각각의 요소들과 그 역할에 대해서 하나씩 정리해 보겠습니다. 각 요소들에 대해 잘 이해한다면, OCI와 OPNsense가 아닌 환경에서도 충분히 IPsec을 활용하여 Site-to-Site VPN 구축이 가능할 것입니다.

1) OCI 측 리소스

• DRG(Dynamic Routing Gateway) - 이름에서 알 수 있듯 VCN 내의 동적 라우팅 경로를 담당합니다. OCI VCN의 트래픽 중 인터넷을 향하는 트래픽이 아닌 Homelab을 향하는 트래픽에 대한 라우팅을 수행합니다. Site-to-Site VPN의 실제 구현을 담당하며, Oracle 측의 실제 라우터를 추상화한 요소라 보면 됩니다.
• Public Subnet - OCI 측 Subnet으로, 이곳에 인스턴스가 위치하고, 이 네트워크에 대한 정보를 BGP를 통해 라우팅 합니다.
• IGW(Internet Gateway) - OCI 측 인스턴스가 인터넷과 통신하기 위한 게이트웨이입니다. VPN 설정을 통해 홉랩으로 향하는 트래픽을 제외한 트래픽은 IGW를 향하게 됩니다.
• OCI IPsec Tunnel Interface(VTI, Vritual Tunnel Interface) - Site-to-Site VPN의 핵심 컴포넌트라 할 수 있겠습니다. OCI에서는 고가용성(HA)을 위해 2개의 터널 인터페이스를 제공하며, 이를 통해 CPE(Customer-Premisese Equipment)와 VPN 연결을 맺습니다. VTI는 Public IP와 Private IP 2개를 가지는데, Public IP는 OCI에서 랜덤 하게 제공해 주며, Private IP는 사용자가 직접 지정하게 됩니다.
• OCI BGP ASN - Homelab과 BGP 피어링을 맺을 때 사용할 AS Number입니다. BGP 피어링은 VTI의 Private IP를 통해서 이루어집니다.

2) Homelab 측 리소스

• CPE(Customer-premisees Equipment) - OCI와 Site-to-Site VPN을 맺기 위한 라우터로, 이번 포스팅에는 OPNsense를 기준으로 설명합니다. IPsec VPN 기능을 지원하여야 하며, BGP를 통한 동적 라우팅을 제공한다면 두 Site 간 네트워크 라우팅 정보 교환을 자동으로 할 수 있게 됩니다.
• Homlab IPsec Tunnel Interface - OCI 측의 VTI가 2개에 대응하는 Homelab 측 인터페이스로, Private IP를 가집니다. OCI 측 VTI와 쌍을 이루는 VTI는 같은 CIDR 블록(/31)에 속하게 됩니다. OCI 측과 다른 점은, OCI의 VTI의 경우 Public IP와 Private IP를 동시에 가지지만, Homelab의 VTI의 경우에는 OPNsense IPsec VPN 설정에서 생성하는 가상 인터페이스가 되며, Pirvate IP만을 가집니다. Public IP는 OPNsense가 ISP로부터 공급받는 IP 하나에 매핑됩니다.
• FRR Plug-in - BGP 피어링을 위해 플러그인으로, 간단히 설치가 가능합니다.

4. IPsec을 통한 Site-to-Site VPN 설정

 Site-to-Site VPN의 설정은 다음과 같은 절차를 거칩니다.

1. OCI Portal을 통한 IPsec 설정
2. CPE 설정을 통해 OCI가 Homelab을 인식하도록 설정
3. OPNsense(Homelab) 설정을 통해 CPE가 OCI를 인식하도록 설정
4. Homelab 측과 OCI 측의 BGP 피어링
5. Homelab 측 라우팅 경로 재분배 설정 및 방화벽 설정
6. OCI 측 라우팅 테이블 추가 및 Security List 설정
7. 두 Site 간 연결 테스트

 위 절차에 대해서 상세한 가이드는 다음과 같습니다. 처음 Site-to-Site VPN을 설정하는 분들도 그 개념을 이해하실 수 있도록 최대한 쉽게 설명해 보도록 하겠습니다.

1) OCI Portal을 통해 IPsec 설정

 먼저 OCI 측에 VCN(Virtual Cloud Network, AWS의 VPC와 동일한 개념)를 하나 생성해야 합니다. OCI 웹 콘솔에서 Networking > Virtual cloud networks > Actions > Start VCN Wizard을 선택합니다.

 VCN의 이름을 정해줍니다. CIDR값은 기본으로 입력된 값을 사용하도록 하겠습니다. 필요에 의해 변경할 수도 있습니다. 다음으로 다시 Start VCN Wizard 기능을 통해 Add Internet Connectivity and SIte-to-Site VPN to a VCN을 선택하여 Site-to-Site VPN을 구성합니다.

 Site-to-Site VPN을 설정한 VCN을 선택(방금 만든 VCN)하고, DRG를 생성합니다. 앞에서도 설명했지만 이 DRG를 통해 Site-to-Site VPN을 구성하고, On-Premise와 Cloud 간에 BGP를 통한 라우팅 정보 교환을 할 수 있게 됩니다.

 DRG와 연결되어 동적 라우팅 경로 광고 대상이 될 Subnet을 선택합니다. 여기에서는 Public Subnet을 선택하도록 하겠습니다.

 3단계에서는 라우팅 타입 선택 및 터널 인터페이스(VTI)에 대한 설정을 하게 됩니다. 우선 Routing type에 BGP dynamic routing을 선택합니다. 그리고 아래로 화면을 드래그하면 Tunnel 1 / Tunnel 2가 보이는데 이곳에서 VTI에 대해서 설정할 수 있습니다.

 Tunnel(VTI) 설정에 총 4가지 항목을 입력하게 됩니다. 각 항목에 대한 설정값은 아래와 같이 하였습니다. 이것은 절대적인 값은 아닙니다. 상황에 따라 변경해서 사용하면 됩니다.

• IKE version: Internet Key Exchange 버전으로 IKEv2가 최신 버전이고 효율성이 더 높음
• Your BGP ASN: Homelab 측 OPNsense Router의 BGP ASN 번호
• IPv4 inside tunnel interface - CPE: Homelab 측의 VTI의 사설 IP 주소
• IPv4 inside tunnel interface - Oralce: 오라클 측의 VTI의 사설 IP 주소

 위 다이어그램을 보면 각 인터페이스가 서로 어떤 역할을 하는지 좀 더 쉽게 이해할 수 있을 것입니다. VTI는 내부적으로는 /31의 CIDR을 사용하며, 외부적으로는 공인 IP를 통해 통신하게 됩니다. 그러면서 IKE를 통해 IPsec Tunnel을 생성하게 됩니다. 또한 BGP ASN 설정에서 눈치채셨겠지만 이 VTI 들을 통해 BGP 피어링을 맺고, 라우팅 정보도 교환합니다.

 마지막으로, CPE(Homelab) 측의 IPsec Tunnel을 구성할 장비의 Public IP 주소를 입력합니다. 저의 경우에는 OPNsense의 공인 IP 주소를 입력하였습니다. 이렇게 하면 OCI가 CPE(Homelab)을 인식할 수 있도록 하는 설정은 마무리되었습니다.

 이번 단계에서 생성한 것들을 정리해 보면 아래와 같습니다.

• OCI VCN, Subnet
• Site-to-Site VPN을 위한 DRG
• IPsec Tunnel을 위한 Tunnel Interface 2개, Shared secret, 공인 및 사설 IP 주소
• CPE(OPNsense) 측 정보

2) CPE(OPNsense)측 설정을 통해 OPNsense 측에서 OCI를 인식하도록 설정

 앞선 설정이 잘 마무리되었다면, OCI 측에 Tunnel에 각각 Public IP 주소가 할당되며, IKE Secret이 생성됩니다. OCI의 Site-to-Site VPN 메뉴에서 Tunnels 탭을 통해 이 값들을 확인할 수 있습니다. 이 값들을 OPNsense에 설정하여 CPE 측에서 OCI 측을 인식할 수 있도록 합니다.

 위 스크린샷에서 처럼 확인된 Tunnel Interface(VTI)의 Public IP 주소와 Shared secret 정보를 OPNsense 측에 입력해 줍니다. 해당 정보들은 Site-to-Site VPN 메뉴에서 터널 인터페이스의 detail 정보를 확인하면 볼 수 있습니다.

 OPNsense 설정은 위와 같습니다. OPNsense의 VPN 메뉴에서 IPsec을 선택, Pre-Shared Keys 메뉴를 통해 새로운 항목을 생성합니다. Tunnel 1과 Tunnel 2의 정보를 사용하여 2개의 항목을 생성합니다.

 이제 OPNsense 측에 VTI(Virtual Tunnel Interface)를 생성하여 OCI와 IPsec VPN 생성으로 할 수 있도록 합니다. Reqid 값이 중요한데 이 값을 통해서 VTI와 아래 Connection 설정에 나오는 Child가 서로 연결되게 됩니다. 즉 VTI와 Child의 내부 연결을 위한 고유한 식별자라고 보면 됩니다.

 다음은 IPsec Connectios를 설정하는 작업입니다. advanced mode를 활성화하고, Proposals를 aes256-sha1-modp2048 [DH14]로 설정합니다. 이 옵션은 256비트 AES로 데이터를 암호화하고, SHA-1로 무결성을 검증하며, 2024 비트 Diffie-Hellman 그룹 14를 사용하여 세션키를 교환하는 보안 정책입니다. Vesion은 IKEv2로 설정하고, Local address에는 OPNsense의 Public IP 주소를, Remote addresses에는 OCI 측 Tunnel interface 1의 Pubclic IP 주소를 설정합니다. 그리고 맨 아래 Description을 작성하고 Save를 클릭합니다.

 Save 후에 아래에 새로운 메뉴가 생깁니다. Local Authentication을 추가합니다. 특별히 설정할 것은 없고 기본 값이 채워진 상태로 Save를 누르면 됩니다. Remote Authentication 역시 마찬가지입니다.

 다음으로 Child를 생성합니다. 여기에서 한 가지 주의할 점이 있는데, 반드시 Policies를 체크 해제 해야 합니다. 만약 이를 체크하고 만들게 되면 모든 트래픽이 하이제킹 당해 OCI 쪽으로 흘러가게 되어 네트워크가 마비될 수 있습니다. Reqid는 Local과 Remote 옵션에 모두 0.0.0.0/0을 입력합니다. Policies 체크를 반드시 해제하는 것에 주의하며, 위 과정을 한번 더 반복하여 Tunnel 2에 대해서도 설정을 생성합니다.

 마지막으로 IPsec VPN 서비스를 실행하여 Site-to-Site VPN을 구현합니다. 연결이 잘 되면 다음과 같은 화면을 확인할 수 있습니다.

이번 단계에서 생성한 것들을 다시 정리해 보면 다음과 같습니다.

• Pre-Shared Keys: OCI Tunnel Interface 생성하면서 함께 발급된 Secret 값 2개를 통해 생성
• VTI 2개 생성: OPNsense 및 OCI 측 Tunnel Interface의 공인 IP 주소 및 사설 IP 주소를 설정값으로 하여 생성
• Connection 2개 생성: Local/Remote Authentication 2개 생성, Child 설정에서 Reqid 값을 통해 VTI와 연결 

3) Homelab 측과 OCI 측의 BGP 피어링

  위 스크린샷에서 볼 수 있듯, 두 사이트 간 VTI 연결은 문제 없이 되었는데, BGP 설정이 되어 있지 않은것을 확인할 수 있습니다. 즉, 두 사이트간 VPN 터널은 생성되었으나, BGP를 통한 동적 라우팅 경로 생성은 되지 않고 있는 상태입니다. 우선 OPNsense 측 설정부터 시작하겠습니다.

 먼저 OPNsense의 Routing > BGP의 첫 화면에서 Route Redistribution을 리스트를 생성합니다. 경로 재분배 옵션을 Connected routes로 선택하여, 현재 OPNsense와 연결되어 있는 라우팅 경로를 광고 후보로 둡니다.

 다음은 실제로 광고할 네트워크 주소 대역을 설정하는 Prefix Lists입니다. 가상머신의 네트워크 대역인 192.168.2.0/24를 목록에 추가합니다. Premit 옵션은 Network 옵션에 있는 네트워크를 광고하겠다는 의미입니다. Name은 이 Prefix Lists를 대표하는 그룹의 이름으로 같은 Namse을 사용하는 Prefix Lists들은 동시에 네트워크 광고 옵션에 적용됩니다. Sequence Number를 통해 여러 규칙을 하나의 Prefix Name 안에 그룹화할 수 있습니다. 저는 추가로 172.24.0.0/24도 추가해 보았습니다.

 다음 단계는 BGP neighbor를 설정하는 단계입니다. Peer-IP는 OCI 측 Tunnel Interface의 Private IP가 됩니다. Remote AS는 OCI 측의 BGP ASN인데 이것은 특별한 설정을 하지 않았으면 31898이 기본값입니다. Update-Source Interface는 OPNsense 쪽 VTI가 됩니다. 주의할 점은 Peer-IP와 VTI가 앞선 IPsec 설정에서 서로 터널을 맺은 쌍이어야 한다는 점입니다. Soft reconfiguration inbound 옵션을 활성화하여 세션을 재시작하지 않고도 정책을 변경할 수 있도록 합니다. 마지막으로 Prefix-List Out을 통해 광고할 네트워크 대역을 설정합니다. Tunnel 1과 같은 내용으로 Tunnel 2에 대한 BGP Neighbor를 설정합니다.

 이번 단계에서는 아래와 같은 요소들을 만들고 설정하였습니다.

• Route Redistribution 리스트
• Prefix List

 추가로 OPNsense에 vtysh를 통해 BGP 상태를 확인할 수 있습니다. BGP를 통해 Static 하게 설정하지 않아도 네트워크 대역을 자동으로 광고하고 또 받고 있는 것을 확인할 수 있습니다.

4) 방화벽 설정 

 방화벽은 2가지 룰을 추가합니다. 하나는 OPNsense의 Public IP가 부여되는 WAN 인터페이스, 하나는 IPsec이라는 이름을 가진 인터페이스입니다. 우선 방화벽에서 Aliase를 만들어 줍니다. OCI 측 Tunnel Interface의 Public IP 주소에 대해서 하나, 그리고 Port 번호 500과 4500에 대해서 Aliase를 만듭니다. 이를 가지고 WAN Interface에 방화벽 설정을 진행합니다.

• WAN Interface 방화벽 규칙

 다음은 IPsec 인터페이스입니다. 이 인터페이스는 특이하게도 Interfaces 목록에는 보이지 않고, 방화벽 Rules 목록에만 존재합니다. 이 인터페이스에 대한 방화벽 설정은 매우 특이한 모습을 보이는데, Homelab에서 OCI 측으로의 통신이 아닌, OCI에서 Homelab 측으로의 통신에 영향을 주는 방화벽 룰이라는 것입니다. 따라서 OCI 측에서 Homelab으로의 접근을 제어하고 싶다면 이 방화벽 설정이 중요한 역할을 합니다. 이번 포스팅에서는 모든 소스에 대해서 모든 프로토콜에 대해 Pass 룰을 적용하겠습니다.

• IPsec 인터페이스 방화벽 규칙

5) OCI 측 Routing Tables 추가 및 Security List 설정

 BGP를 통해서 네트워크 대역이 광고되고 있긴 하지만, OCI VCN에 Routing rule을 설정해 주어야 합니다. 아래와 같이 OCI에서 Homelab의 Subnet으로 통신할 수 있도록 라우팅 경로를 추가해 줍니다.  라우팅 경로의 Target은 반드시 DRG가 되어야 다른 사이트로의 통신이 가능하다는 점에 유의해야 합니다.

 다음은 Security List로 방화벽 규칙과 같은 것을 적용해 줍니다. 이 VCN에 기본적으로 존재하는 규칙인 22번 포트에 대한 TCP 연결(SSH) 허용과, ICMP 프로토콜에 대한 차단 규칙 이외에, Homelab의 특정 네트워크에서 발생하는 ICMP 규칙도 추가합니다. 이를 통해서 Homelab 측 VM에서 OCI 측 Instance에 Ping 테스트를 할 수 있게 합니다.

6) 두 Site 간 연결 테스트

 이제 정말 두 사이트 간 통신이 잘 작동하는지 확인할 차례입니다. 두 사이트에 테스트에 사용할 VM과 Intance를 생성합니다.

• Homelab VM(192.168.2.250)에서 OCI Instance(10.0.0.9)로 ping 테스트 및 ssh 접근 테스트 성공
• OCI Instance(10.0.0.9)에서 Homelab VM(192.168.2.250)으로 Ping 테스트 및 ssh 접근 테스트 성공

 OCI Home Region이 싱가포르이라 Ping이 약 100ms 정도에 달하긴 하지만, 통신 품질 자체는 아주 안정적인 것을 확인할 수 있습니다.

 이렇게 해서 두 Site 간 호스트들이 Private Network를 통해 통신할 수 있는 Site-to-Site VPN을 IPsec Tunnel을 사용하여 구현해 보았습니다. 구축하면서 방화벽 규칙 때문에 단방향으로만 통신이 된다던가, 혹은 BGP 피어링이 잘 맺어지지 않는 상황도 있었습니다. 대부분 저의 실수였고, 실수를 통해 많이 배울 수 있었습니다. 여담이지만, 엔지니어에게 이렇게 직접 핸들링할 수 있는 홈랩이 있다는 것은 여러 기술을 직접 채득 하기에 너무나도 좋은 환경인 것 같습니다.(망가지더라도 제가 고치면 되니까, 그 부분에 대한 부담도 적어서 좋구요...)

 어쨌든, 이번 구축을 통해 다음 단계로 나아갈 수 있게 되었습니다. 이제는 OCI Instance에 단일 노드 Kubernetes를 구성하고 Cluster API Managmenet Cluster를 구축할 차례입니다. 그리고 이를 통해 Homelab의 MiniPC 노드들을 프로비저닝 하는 것을 목표로 또 스터디해야겠습니다. 긴 포스팅 읽어주셔서 감사합니다.