지난 1월 24일, 오픈 프로젝트 시즌 2 팀원들이 오프라인에 모여 중간 점검을 진행했습니다. 각 팀이 지금까지 시도한 것(Tried), 실패한 것(Failed), 배운 것(Learned), 다음 스텝(Next)을 공유하고, 다른 팀과 기술검증단의 피드백을 받는 T/F/L/N 세션이었습니다.
발표 녹화는 @tiaz 님이 도와주셨습니다. 
① Dr.Kube | K8s 장애 자동 진단 및 복구 AI 에이전트
중간 로그 발표 영상: Dr.Kube T/F/L/N
Tried (시도)
Prometheus 메트릭을 기반으로 이상 탐지(Anomaly Detection) 파이프라인을 구축했습니다. 특정 임계값에 도달하면 자동으로 파드(Pod)를 재시작하거나 리소스를 재배치하는 커스텀 컨트롤러와 오토 스케일링 로직을 결합하는 제어 로직을 설계했습니다.
Failed (실패)
자동 복구 스크립트가 실행될 때, 리소스 부족으로 스크립트 자체가 타임아웃되는 데드락(Deadlock) 상황이 발생했습니다. 종속성이 있는 서비스들이 순차적으로 살아나지 않아 오히려 전체 시스템에 연쇄 장애(Cascading Failure) 를 일으켰습니다. 자동 복구를 만들었더니, 자동 복구가 장애의 원인이 되는 상황이었습니다.
Learned (배운 것)
"무엇을 자동화할 것인가"보다 “언제 자동화를 멈출 것인가” 가 가용성을 결정합니다. 복구 로직에 Graceful Shutdown과 Health Check 대기 시간을 세밀하게 반영해야 합니다. 자동화 도구의 예외 처리(안전장치)가 시스템 가용성의 핵심이라는 인사이트를 얻었습니다.
Next (다음 스텝)
최종 발표까지 오토 스케일링 과정에서의 급격한 리소스 회수로 인한 서비스 영향도를 최소화하는 완충 로직을 고도화하고, 장애 예측 모델을 도입해 사고 발생 전 미리 리소스를 확보하는 선제적 대응 기능까지 구현할 예정입니다.
② Gopedia | Enterprise Knowledge Graph
중간 로그 발표 영상: Gopedia T/F/L/N
Tried (시도)
Wiki, Slack, Jira 등에 흩어진 기술 문서를 Markdown으로 자동 변환하고, 벡터 데이터베이스에 색인한 뒤 LLM을 연동하는 RAG(Retrieval-Augmented Generation) 검색 시스템을 구축했습니다. 오픈소스 검색 엔진 Meilisearch를 활용해 고성능 검색 기능도 함께 구현했습니다.
Failed (실패)
기술 문서 특유의 코드 블록과 도표가 파싱 과정에서 텍스트로 잘리면서 검색 품질이 급격히 떨어졌습니다. 사용자가 입력하는 검색어가 기술 용어일 경우, 단순 텍스트 매칭으로는 원하는 결과를 찾을 수 없었습니다. “Kubernetes OOM” 이라고 검색해도 정작 관련 문서가 나오지 않는 상황이 반복됐습니다.
Learned (배운 것)
단순 임베딩만으로는 기술적 맥락(Context)을 파악할 수 없습니다. 계층적 정보 구조화(Chunking) 전략이 필수 이며, 단순 검색을 넘어 시맨틱 검색(의미 기반 검색)으로의 전환이 필요하다는 결론을 얻었습니다. 기술 문서에 특화된 파싱 전처리가 RAG 시스템의 품질을 결정합니다.
Next (다음 스텝)
검색 엔진 성능을 측정할 수 있는 지표(Retrieval Accuracy)를 정의하고, 커뮤니티 기능(댓글, 평점)을 추가해 신뢰도 높은 문서가 상단에 노출되는 랭킹 알고리즘을 개선할 예정입니다.
③ HoneyBeePF | eBPF 기반 선택적 관측성 플랫폼
중간 로그 발표 영상: HoneyBeePF T/F/L/N
Tried (시도)
개발자가 복잡한 K8s 설정을 몰라도 인프라를 배포할 수 있도록, Backstage 기반의 포털을 구축하고 ArgoCD를 통한 GitOps 파이프라인을 표준화했습니다. 추상화 레이어를 통해 개발자 경험(Developer Experience)을 극대화하는 방향으로 설계했습니다.
Failed (실패)
인프라를 너무 추상화하다 보니, 팀마다 다른 커스텀 설정 요구사항을 반영하지 못했습니다. 하나의 템플릿으로 모든 팀의 요구사항을 담으려다 설정 파일이 과도하게 복잡해지는 역설에 빠졌습니다. 추상화할수록 오히려 확장성이 막히는 상황이었습니다.
Learned (배운 것)
"만능 템플릿"은 불가능합니다. 완전 자동화보다 가드레일(Guardrail) 을 설정해 개발자가 자율적으로 설정할 수 있는 범위를 적절히 배분하는 것이 실무적이라는 합의를 만들었습니다. 최소한의 공통 규약만 강제하고 나머지는 자율성을 주는 방향이 답이었습니다.
Next (다음 스텝)
사용자 피드백을 기반으로 템플릿의 유연성을 확보하고, CLI 도구를 추가해 개발자가 더 쉽게 플랫폼을 활용할 수 있도록 개선할 예정입니다. 배포 대시보드의 시각화 완성도도 높입니다.
④ KubeAI | 자연어 기반 K8s 운영 AI 대시보드
중간 로그 발표 영상: KubeAI T/F/L/N
Tried (시도)
AI 모델 학습 및 서빙 시 발생하는 GPU 비용을 절감하기 위해, 멀티 테넌트 환경에서 GPU 리소스를 분할(Fractional GPU) 할당하는 기법을 적용했습니다. Karpenter와 NVIDIA Device Plugin을 활용해 필요한 순간에만 노드를 생성하고 삭제하는 Dynamic Scaling을 구현했습니다.
Failed (실패)
스케줄러가 노드를 내리는 타이밍과 모델의 체크포인트 저장 타이밍이 맞지 않아 학습 중인 데이터가 유실 되었습니다. 메모리 예측 모델이 최악의 시나리오(OOM)를 감지하지 못해 노드가 통째로 다운 되는 경험도 했습니다. GPU 리소스 할당 대기 시간이 길어지면서 전체 성능이 저하됐습니다.
Learned (배운 것)
AI 워크로드는 일반 서비스와 달리 스테이트풀(Stateful) 특성이 강합니다. 정적 메모리 할당 정책은 답이 아니며, 모델 서빙 중 부하(Load)에 따라 가변적으로 리소스를 조절하는 오토 스케일링 서빙 엔진 의 필요성을 체감했습니다. 스케줄링 시 작업의 상태 정보를 깊게 파악해야 합니다.
Next (다음 스텝)
추론(Inference) 단계의 지연 시간을 최소화하기 위해 vLLM 같은 서빙 엔진 최적화와 캐싱 엔진 최적화 단계를 추가하고, 벤치마킹 데이터를 확보할 예정입니다.
⑤ KubeRCA | AI 기반 K8s 인시던트 근본 원인 분석 자동화
중간 로그 발표 영상: KubeRCA T/F/L/N
Tried (시도)
K8s 이벤트 로그와 애플리케이션 로그를 수집한 뒤, LLM(GPT-4 등)에 전달해 장애의 근본 원인을 자연어로 요약해주는 PoC를 진행했습니다. 벡터(Vector)를 사용한 로그 수집과 LLM 기반의 원인 분석 보고서 생성 시스템을 구축했습니다.
Failed (실패)
장애 발생 시 발생하는 수만 건의 로그를 그대로 던지니, LLM이 환각 현상(Hallucination) 을 일으켜 잘못된 해결책을 제시했습니다. 실제 원인(Root Cause)과 무관한 노이즈 데이터가 분석 결과의 신뢰도를 급격히 떨어뜨렸습니다. 정확도가 50% 미만으로 떨어지는 상황이 반복됐습니다.
Learned (배운 것)
로그의 "양"보다 "정제"가 핵심 입니다. RCA의 핵심은 알고리즘의 고도화보다, 불필요한 로그를 필터링하는 전처리 단계의 도메인 지식(비즈니스 로직) 이 훨씬 중요합니다. 오류 코드 위주로 로그를 사전 필터링하고, 벡터 데이터베이스(RAG)를 활용해 과거 해결 사례를 참조하게 하는 방식이 훨씬 효과적이라는 걸 확인했습니다.
Next (다음 스텝)
특정 에러 패턴을 미리 학습시켜, 유사 장애 발생 시 분석 결과의 정확도를 향상시키는 '장애 시나리오 베이스라인’을 구축하고, Slack 알림 봇과 연동해 운영자가 즉시 조치 버튼을 누를 수 있는 인터랙티브 기능을 추가할 계획입니다.
이런 시행착오를 거친 팀들이 3개월을 더 고도화한 결과물을, 4월 4일에 공개합니다!
행사 참여 바로 가기 : Ship to Production : 커뮤니티 오픈 프로젝트에서 시작하는 플랫폼 엔지니어링의 미래 - 이벤터스