“그땐 Ceph, 지금은 Longhorn?” AI 추천이 바뀔 때 흔들리지 않는 의사결정 프레임

Bro's Insights
1

도입부: 같은 질문을 했는데 AI 답이 달라지면, 내가 선택한 솔루션이 틀렸나 불안해집니다. 이 글에서는 AI 추천 변화가 왜 생기는지를 정리하고, 특히 K8s 스토리지(Ceph/Longhorn) 사례로 처음부터 흔들리지 않게 선택하는 기준(컷라인)과 질문법을 공유합니다.

AI 답변이 바뀌는 순간, 신뢰가 흔들리는 이유

제가 문제의식을 가진 지점은 단순히 “AI가 틀렸다/맞았다”가 아니라, 추천이 바뀌는 타이밍입니다. 처음에는 “Ceph가 적절하다”는 뉘앙스로 답이 오고, 구축과 테스트를 마친 뒤에야 “그건 네트워크 병목일 수 있다, Longhorn 같은 다른 솔루션을 고려하라”로 방향이 틀어지면 사용자는 이렇게 받아들이기 쉽습니다.

  • 그때는 왜 그 얘길 안 했지?
  • 내가 선택한 설계는 근본적으로 틀렸나?
  • 그럼 AI 추천은 무엇을 믿고 따라야 하지?

결국 핵심은 일관성(consistency) 그 자체보다, 추천의 근거와 가정이 충분히 드러나지 않아 생기는 투명성/책임의 공백입니다.

“옵션을 많이 주는 것”보다 중요한 것: 추천의 전제(가정)를 밝히기

대화에서 저는 “처음부터 복수 옵션을 제시하고 사용자가 선택할 수 있어야 한다”고 느꼈습니다. 다만 실제로 겪어보니, 옵션 나열만으로는 불안을 못 없앱니다. 왜냐하면 도메인 지식이 “어렴풋한 상태”에서는 옵션을 받아도 무엇이 내 상황의 핵심 제약조건인지를 놓치기 때문입니다.

그래서 결론적으로 더 중요했던 건 다음이었습니다.

  • 추천의 전제(가정)를 명시해 달라
  • 어떤 조건이면 Ceph를 배제/채택해야 하는지 컷라인을 달라
  • 선택보다 검증(테스트/측정) 절차를 먼저 제시해 달라

이 3가지만 초반에 깔렸어도 “나중에 답이 바뀌는 현상”이 곧바로 “내 선택이 틀렸나?”로 연결되지는 않았을 겁니다. 그건 ‘정답이 바뀐 것’이 아니라 ‘가정이 뒤늦게 공개된 것’이니까요.

사례: Ceph RBD 구축 후 성능이 기대에 못 미친 경험

제가 겪은 구체적 상황은 이렇습니다.

  • K8s에서 Pod에 PVC를 붙여 테스트
  • Ceph RBD 사용 (CephFS는 더 성능이 안 나왔음)
  • 측정 결과: 쓰기 30MB/s, 읽기 100MB/s
  • 그제서야 AI가 “네트워크 병목일 가능성”을 이야기하며 Longhorn 등 대안으로 변경을 권함

문제는 “Ceph가 느리다/빠르다” 이전에, 처음 추천 단계에서 성능 리스크를 가르는 핵심 질문이 빠졌다는 점입니다. 특히 DB 워크로드에선 MB/s보다도 다음 요소들이 병목을 좌우하는 경우가 많습니다.

  • 네트워크 대역폭과 지연(latency)
  • 복제(replication)로 인한 쓰기 증폭
  • 워크로드 특성(랜덤 4k, fsync 등)과 측정 지표(p95/p99 latency, IOPS)

저는 나중에 돌아보며 “10Gb 네트워크에서 안정적인 속도가 나올지” 같은 이야기를 초반에 더 강하게 확인했어야 했다고 느꼈고, 대화 끝에서 결국 “Ceph 후보 제외/채택을 가르는 최소 컷라인은 무엇인가?”로 수렴했습니다.

제 기준에선 네트워크 대역폭/지연, 예상 IOPS가 컷라인의 핵심이었습니다.

추천이 바뀌어도 흔들리지 않는 방법: “옵션”보다 “컷라인 + 측정”을 먼저 합의하기

AI에게 “Ceph vs Longhorn 중 뭐가 좋아?”라고 묻는 방식은 편하지만, 답변이 바뀔 때 흔들립니다. 반대로 아래 순서로 질문하면, 답이 달라져도 “내 선택이 틀렸나”가 아니라 “가정이 달라졌나”로 점검할 수 있습니다.

  1. 내 워크로드를 대표하는 테스트 프로파일 1개를 정한다
  2. 합격 기준(예: p95 latency, IOPS 등) 1개를 정한다
  3. 그 기준으로 Ceph/Longhorn의 컷라인을 제시하게 한다
  4. 마지막에 “그래서 내 상황에선 무엇을 우선 추천하나?”를 묻는다

즉, 추천을 받기 전에 “추천이 유효하려면 어떤 조건을 충족해야 하는지”를 먼저 고정하는 방식입니다.

예시 프롬프트(제가 다음엔 이렇게 물어볼 것 같습니다)

K8s에서 DB용 PVC를 검토 중입니다.
1) DB에 가까운 fio 테스트 프로파일 1개(블록사이즈/rw/iodepth/fsync 포함)를 제안하고,
2) 합격 기준 1개(예: p95 latency 또는 IOPS)를 함께 정의해 주세요.
3) 그 기준에서 Ceph RBD를 채택/배제하는 최소 컷라인(네트워크 대역폭/지연, 예상 IOPS)을 제시하고,
4) 같은 조건에서 Longhorn과의 트레이드오프를 2~3축으로 비교해 주세요.
전제/가정도 반드시 명시해 주세요.

이렇게 물으면 AI가 나중에 “사실 네트워크 병목일 수 있어요”라고 하더라도, 그건 뒤집기가 아니라 처음 합의한 컷라인/측정 프레임 안에서 자연스럽게 해석됩니다.

인사이트: “복수 옵션 제시”의 우선순위는 상황에 따라 달라집니다

대화를 정리하면서 느낀 현실적인 결론은 이렇습니다.

  • 시간이 촉박하지 않고, 도메인 지식이 어렴풋한 상태라면
    → 복수 옵션 제시 자체보다 ‘전제/컷라인/검증 절차’가 먼저입니다.
  • 장애 대응처럼 시간이 촉박한 상황이라면
    → 단일 권고 + 이유 + 대안 1개가 더 실용적일 수 있습니다.

즉 “항상 복수 옵션이 정답”이라기보다, 사용자가 무엇을 결정할 준비가 되어 있는지에 따라 AI의 답변 구조가 달라져야 신뢰가 유지됩니다.

마무리

AI 추천이 바뀌는 건 종종 “지식이 업데이트됐다”기보다, 처음엔 가정이 생략되었다가 나중에 드러나는 문제로 체감됩니다. 그래서 저는 다음부터는 “Ceph냐 Longhorn이냐”를 먼저 묻기보다, 네트워크 대역폭/지연과 예상 IOPS를 중심으로 컷라인과 측정 기준부터 합의하는 질문을 던지려고 합니다. 그렇게 하면 답이 바뀌어도 흔들리지 않습니다.

1 Like