Open Source Summit Korea 2026: 계층별로 쌓아 올리는 AI 책임성

Open Source Summit Korea 2026이 막을 내렸고, 하나의 주제가 행사 내내 계속 다시 떠올랐습니다. 바로 책임성(accountability)입니다. LG AI Research는 기조연설 무대에서 학습 데이터를 그 기원까지 추적하는, 정부 과제로 만들어진 AI BOM을 소개했고, 브레이크아웃 세션들은 같은 질문을 다른 계층에서 던졌습니다. AI 에이전트는 프로덕션에서 무엇까지 해도 되는가, 그리고 GPU는 자기 비용값을 하고 있다는 것을 어떻게 증명하는가입니다. 이 글에서는 기조연설과 브레이크아웃 세션이 실제로 보여준 것과 다른 환경에도 적용할 수 있는 패턴을 정리합니다.

AI가 어젠다를 지배했지만, 전부를 차지하지는 않았습니다. 프로그램의 적지 않은 부분이 대규모 인프라에 머물렀고(업스트림 패치로 마무리된 소규모 클러스터 Ceph 디버깅, 멀티 AZ OpenStack 설계), Argo는 카나리 분석부터 에이전트가 제안하고 사람이 승인하는 워크플로까지 계속 다시 등장했습니다. 이 정도로 AI에 기운 콘퍼런스에서, 그런 균형은 반가운 일이었습니다.

기조연설이 제시한 프레임

기조연설은 책임성을 두 방향에서 밀어붙였습니다. 하나는 경제였습니다. 오픈 웨이트는 프런티어 성능의 ~90%를 6–8× 저렴하게 제공하며 합리적인 기본값이 되어 가는 반면, 데이터는 AI 스택에서 유일하게 닫힌 계층으로 남아 있다는 것입니다. 한국은 그 논쟁이 정리되기를 기다리는 대신 이미 움직이고 있습니다. 7월의 아흐레 사이에 프런티어급 한국 모델 세 개가 공개되었고, 그중 가장 큰 것은 Apache 2.0 라이선스로 공개된 LG의 7,500억 파라미터 K-EXAONE 2.0이며, 모두 정부 지원 모델을 Hugging Face로 내보내는 국가 프로그램에서 나왔습니다. 다른 방향은 속도였습니다. 취약점이 공개된 뒤 악용되기까지의 간격은 계속 줄어들어 이제는 악용이 공개보다 앞설 수 있는 지경에 이르렀고, 더 느린 공격자를 상정하고 설계된 패치 주기는 이제 공격자가 자동화하는 속도만큼 빠르게 AI가 취약점을 찾아 고치는 것에 기대게 되었습니다.

LG AI Research의 사장이자 Chief AI Officer인 Honglak Lee 박사는 오픈 데이터를 검증의 문제로 봅니다. 그의 팀은 상업적으로 이용 가능하다고 되어 있던 2,852개 데이터셋을 추적하며 그 이력에 있는 모든 출처를 확인했습니다. 전체를 검토한 끝에 여전히 상업적으로 이용 가능한 것은 605개, 약 21%뿐이었습니다. 나머지는 어딘가에서 연구 전용이거나 아예 구할 수 없는 출처에 의존하고 있었습니다. Lee 박사는 오픈 데이터의 거의 80%가 발행자든 사용자든 그 누구에게도 전체 사슬을 검사받아 본 적이 없다고 지적했습니다. 이 문제는 나쁜 행위자 때문이 아니라 시스템 자체에 내재해 있습니다. 데이터셋이 정제되고 재포장되고 이름이 바뀌는 동안 각 단계는 합리적으로 보이지만, 시간이 지나면 관대한 라이선스를 단 데이터셋이 진짜 기원을 감추게 될 수 있습니다. 예를 들어 FineVision은 겉으로는 라이선스가 하나뿐인 오픈 비전-언어 데이터셋이지만, 실제로는 3,000개가 넘는 출처에서 나왔습니다. 팀의 연구에 따르면 업스트림 어딘가에 법적 리스크가 있을 때, 그 위에 만들어진 데이터셋이 이를 드러내지 않을 확률이 62.6%였습니다. 데이터셋을 제대로 검사하려면 그것이 비롯된 모든 출처를 확인해야 하는데, 사람이 손으로 하기에는 현실적이지 않습니다. 이들의 연구에서 인간 전문가는 중요한 의존성의 3분의 1 이상을 놓쳤습니다. 이를 해결하기 위해 LG는 출처를 추적하는 과정을 자동화하되 판단은 사람에게 남겼습니다. 에이전트가 데이터셋 카드를 읽고, 나열된 출처를 전부 뽑아내고, 각 출처를 끝까지 따라 내려간 뒤 사슬 전체에 점수를 매깁니다. 이 시스템은 수작업보다 약 45배 빠르고, 사람보다 의존성을 26% 더 찾아내며, 비용도 훨씬 낮아 데이터셋당 207달러 대신 0.29달러면 됩니다. 여기서 만들어진 기록은 한국 정부를 위해 만들어졌고 SPDX 3.0 위에 구축된 프로파일인 K-AI BOM에 쓰입니다. 이 기록은 데이터셋을 따라다니도록 설계되었습니다. 데이터셋이 만들어질 때 함께 생성되고, 모델로 전달되고, 서비스에 포함되어, 서비스를 운영하는 누구든 자신이 정확히 무엇을 쓰고 있는지 볼 수 있게 합니다. SBOM이 소프트웨어 패키지에 대해 하는 일과 비슷한, 데이터셋 출처 증명(provenance)입니다.

규제가 이 다급함을 설명해 줍니다. 한국의 AI 기본법은 2026년 1월 22일부터 시행된 아시아·태평양 최초의 포괄적 AI 법으로, 산업 진흥과 신뢰 의무를 함께 담고 있습니다. 그중에는 고영향 AI와 생성형 AI 사업자가 사용한 학습 데이터의 개요를 제공해야 한다는 의무도 있습니다. 한 문장짜리 공시로는 그 의무를 감당할 수 없지만, 기계가 읽을 수 있는 계보 그래프라면 가능합니다.

에이전트에 채워지는 가드레일

세션들을 가로질러 반복된 패턴이 하나 있습니다. AI 에이전트는 이제 실패 양상이 더 이상 가설이 아닌 프로덕션 행위자라는 것입니다. Harness의 Jyoti Bisht와 Animesh Pathak은 OPA 세션의 논지를 추격전처럼 쌓아 올렸습니다. 코딩 에이전트가 프로덕션 데이터베이스를 지워 버린 실제 사고 사례들로 문을 연 뒤, 모든 에이전트 툴 호출이 어드미션 컨트롤을 통과하고 Rego 정책이 통과 여부를 결정하는 클러스터에서 같은 상황을 재연했습니다. 첫 번째 정책은 동사(verb) 기준으로 삭제를 막았고, 그러자 에이전트는 대신 프로덕션 디플로이먼트 두 개의 이름을 바꿨습니다. 그것을 금지하는 규칙은 없었고, 그 이름을 추적하던 Helm 릴리스들이 깨졌습니다. 뒤이어 나온 강화된 정책은 동사가 아니라 결과를 통제합니다. 워크로드의 정체성, 곧 이름과 레플리카 수와 레이블을 바꾸는 모든 연산을 승인이 필요한 작업으로 취급하는 것입니다. 다음 탈출구는 커버리지였습니다. 에이전트는 아무도 정책을 써 두지 않은 단 하나의 네임스페이스를 찾아내 시간당 8.50달러짜리 GPU 노드 45대를 프로비저닝했습니다. 여기서 두 번째 규칙이 나왔습니다. 통제되지 않은 것은 기본적으로 금지된다는 것, 그리고 세 번째로, 비용은 권한과 나란히 정책 안에 있어야 한다는 것입니다. 세션은 추격 대신 협력으로 마무리되었습니다. 에이전트는 사전 승인된 워크플로 템플릿을 통해서만 변경을 시작하되 에이전트가 시작한 작업임을 표시하고, 실행은 사람이 승인합니다. 그리고 프롬프트 인젝션부터 로그를 통한 데이터 유출까지 여섯 개 클래스의 위협 모델이 각 리스크를 구체적인 방어책에 대응시켰습니다.

Megazone의 Hoon Jo는 운영 쪽 이야기를 들려주었습니다. Helm 릴리스 15개, Kafka의 ZooKeeper에서 KRaft로의 이전, Redis를 대체하는 Valkey에 다운타임은 허용되지 않는 프로덕션 마이그레이션을, 운영자 한 명과 AI 에이전트 하나가 감당했습니다. 에이전트는 세션 사이에 아무것도 기억하지 못해 결정과 값과 교훈이 사라졌고, 빈칸을 추측으로 메우며 이미 끝난 선택을 다시 정하고 명령을 지어냈으며, 그렇게 같은 요청이 다른 결과로 이어질 수 있었는데 프로덕션에서는 용납되지 않는 일입니다. 그의 답인 GitAIOps는 Git을 에이전트의 지속되는 기억으로 만들고, 추측할 만한 지점을 하나씩 제거하는 네 개의 레이어로 구성합니다. 사람이 쓴 계획(36개 파일, 23,000줄 이상)이 결정의 이유를 담고, 에이전트는 이를 압축한 6개 파일짜리 프로젝트 상태 대시보드를 읽습니다. 사전 준비부터 롤백까지 순서가 정해진 117개의 사전 작성 명령 파일이 있고, 핀 고정되지 않은 Mimir 차트가 자동 업그레이드되어 프로덕션에서 크래시 루프를 일으킨 뒤 더해진 규칙인, 버전과 값을 고정한 30개 파일이 마지막 틈을 막습니다. 같은 입력은 언제나 같은 배포로 이어집니다.

결과는 분명했습니다. DEV 환경 구축은 2주에서 2일로 줄었고, PROD는 같은 가드레일을 재사용해 1주에서 1일이 되었으며, 기존 플랫폼은 멈추지 않았습니다. 에이전트가 더 빨리 일해서가 아니라, 예측 불가능한 단계를 다시 반복할 필요가 없어졌기 때문입니다. 그의 조언은 어느 팀에나 적용됩니다. 에이전트가 읽는 파일이 무엇이든 지금부터 규칙과 현재 상태를 기록하고, 큰 변경 전에는 미리 계획하고 값을 고정하며, 사람이 갱신하고 AI가 읽기 좋게 유지하는 방식으로 그 단일 진실 공급원을 계속 살아 있게 하라는 것입니다. 이 접근법은 특정 에이전트에 묶여 있지 않고, 마이그레이션이 끝난 뒤에도 그 기억은 계속 일합니다.

IBM의 Kevin Dubois는 비슷한 과제를 GitOps로 접근했습니다. 그는 2024년 CrowdStrike 장애를 먼저 언급하며, 변경 사항을 모두에게 한꺼번에 릴리스하면 무슨 일이 생길 수 있는지 보여주었습니다. 문제가 있으면 모든 사용자가 즉시 영향을 받습니다. 그는 무엇이 그 여파를 줄일 수 있었을지 묻고, 답으로 프로그레시브 딜리버리를 제시했습니다. 보통 GitOps 배포는 한 번에 전부 릴리스되지만, Argo Rollouts를 쓰면 점진적인 롤아웃이 가능합니다. 새 버전은 트래픽의 일부만 받는 카나리로 시작하고, 롤아웃을 계속할지는 AnalysisTemplate이 판정합니다. 이 판정은 보통 성공률을 95% 이상으로 유지하기 같은, 손으로 작성한 PromQL 조건으로 이뤄집니다. Dubois는 그 손으로 쓴 판정자를 AI 에이전트로 바꿨습니다. RolloutManager로 설정되고 AnalysisTemplate에서 참조되는 metric-ai 플러그인이 카나리와 스테이블 두 버전의 메트릭과 로그를 에이전트에 보냅니다. 에이전트는 둘을 비교하고, 필요하면 추가 지시를 따르며(예를 들어 외형상의 변화는 무시하라는 지시), 릴리스를 계속할지 롤백할지 점수로 알려줍니다. 롤백이 일어나고 저장소 URL이 설정되어 있으면, 에이전트는 수정 제안을 담은 풀 리퀘스트도 엽니다. 이렇게 하면 실패한 롤아웃이 단순한 알림이 아니라 리뷰할 수 있는 코드 변경이 되고, 수정안은 리뷰를 거쳐 다시 배포될 수 있습니다. Dubois의 요점은 명확했습니다. 모두에게 한꺼번에 릴리스하는 것은 위험하고, 카나리 롤아웃과 피처 플래그가 더 안전하며, 에이전트는 메트릭과 로그 분석부터 수정 제안까지의 과정을 자동화할 수 있습니다.

데이터센터에서 엣지까지, GPU 계산법

저희가 KubeCon India 2026에서 짚었던 GPU 활용이라는 실은 서울에서 더 날카로워져 돌아왔고, 이번에는 로드 밸런서에서 시작합니다. 고전적인 밸런서는 연결을 보지만, LLM 요청의 비용은 KV 캐시에 있습니다. 프롬프트 프리픽스의 KV 블록을 이미 들고 있는 GPU에 요청을 내려놓으면 프리필을 건너뛰고, 다른 곳에 내려놓으면 같은 텐서를 다시 계산하느라 첫 토큰까지의 시간(TTFT)이 부풀어 오릅니다. NETLOX의 Seokhwan Kong은 캐시 지역성이 공정성보다 중요해졌다는 도발적인 명제로 발표를 열었고, 나머지 시간은 그 명제에 단서를 다는 데 썼습니다. 캐시만 좇으면 이웃 GPU들이 노는 동안 한 GPU만 포화되기에 지역성 자체에 상한이 필요하고, 그것이 값을 하는 것은 플릿이 실제로 바쁠 때뿐입니다.

loxilb 추론 게이트웨이는 라우팅 결정을 로드 밸런서 자체 안으로 가져옵니다. Envoy도, 사이드카도, Kubernetes도 필요 없는 하나의 Go/eBPF 바이너리로 돌아가므로 베어메탈, 가상 머신, 엣지 어디서든 동작합니다. 라우팅은 네 단계로 진행되며, 앞 단계가 매칭되지 않으면 다음 단계를 사용합니다. 첫째, 대화는 이미 사용하던 GPU에 계속 머뭅니다. 세션이 없으면 프리픽스 트라이가 이전에 라우팅한 것과 비슷한 프롬프트인지 확인하는데, 트라이는 보낸 기록만 기억할 뿐 캐시에서 밀려난 것(eviction)은 추적하지 못합니다. 셋째 단계는 정확 일치입니다. 게이트웨이가 모델의 토크나이저로 프롬프트를 토큰화하고, 토큰을 블록으로 묶어 서빙 엔진과 같은 방식으로 블록 해시를 계산한 뒤, 각 GPU가 지금 보유한 블록의 실시간 목록과 비교합니다. 이 목록은 엔진들의 KV 캐시 이벤트 스트림이 ZMQ로 계속 갱신합니다. 오가는 것은 블록당 몇 바이트의 해시뿐이고, 텐서는 항상 GPU 메모리에 머뭅니다. 어느 것도 매칭되지 않으면 요청은 가장 한가한 엔드포인트로 갑니다. 다만 팀이 짚었듯이, 부하가 가장 적은 GPU는 대개 가장 차가운 GPU라서, 단순히 연결 수가 가장 적은 쪽을 고르면 캐시를 놓치기 쉽습니다. 이 시스템을 만들며 두 가지 교훈을 얻었습니다. 첫째, vLLM과 SGLang은 블록 해시 계산 방식이 달라서, 해싱을 규칙마다 엔진별로 설정합니다. 둘째, 캐시 적중만 좇는 것으로는 부족합니다. 인기 있는 시스템 프롬프트가 모든 클라이언트를 같은 GPU로 보낼 수 있으므로, 어피니티는 엔드포인트별 용량으로 제한되고 필요하면 이웃으로 넘칩니다(스필). 프리필/디코드 분리(P/D disaggregation)로 Qwen2.5-7B-Instruct를 돌린 NAVER Cloud 테스트에서 vLLM 라우터를 대조군으로 두었을 때, 포화 상태에서 SLO 내 goodput은 거의 두 배가 되어 0.271 대비 0.581에 달했습니다. 팀은 그 이유를 vLLM 라우터에 과부하에서 스스로를 지킬 용량 상한이 없다는 점에서 찾습니다. 한계에 대해서도 분명히 밝혔습니다. 포화 이전에는 이들의 라우팅이 같거나 오히려 나빴고, 이길 것으로 예상했던 적응형 컨트롤러보다 고정 스필 임계값이 더 좋은 성적을 냈습니다. 트래픽 패턴이 다르면 이 결과는 달라질 수 있다고 팀은 덧붙입니다.

라우팅은 어느 GPU가 요청을 서빙할지를 정합니다. 각 워크로드가 GPU를 얼마나 가져갈지는 별개의 질문이고, 저희의 7월 해설 글은 HAMi가 데이터센터에서 그 질문에 답하는 방식을 다뤘습니다. Dynamia.AI의 Reza Jelveh는 같은 CNCF 인큐베이션 프로젝트를 엣지로 밀고 나갔습니다. 엣지에서는 제약이 더 단단해집니다. 5–40 W로 무인 운영되는 박스, CPU와 GPU와 OS가 나눠 쓰는 8–64 GB의 통합 메모리, 스케일아웃할 곳도 없고, 욕심 많은 에이전트 하나가 나머지를 굶겨도 지켜보는 사람이 없습니다.

엣지에서 달라지는 것은 무엇을 슬라이스하느냐입니다. Jetson Orin의 실리콘에는 MIG가 없어서(JetPack은 더 새로운 Thor 라인에서만 MIG를 프리뷰로 제공합니다) 데이터센터의 하드웨어 벽은 쓸 수 없고, 소프트웨어 펜스가 유일한 격리 수단입니다. HAMi는 통합 LPDDR 풀을 직접 잘라 8 GB Jetson에 10+ 에이전트를 들이고, 수요가 메모리를 넘어서면 시간 분할로 공유하며 유휴 슬라이스를 호스트 RAM으로 스왑합니다. 이 제한이 지켜지는 이유는 HAMi가 파드 안에서 CUDA 호출을 가로채고, 파드는 자기 슬라이스만 보기 때문입니다. 그리고 같은 시맨틱스가 타입이 지정된 ResourceSlice 용량과 ResourceClaim의 형태로 Kubernetes DRA에 매핑됩니다. 엣지의 또 다른 현실은 이기종성입니다. Jelveh는 Jetson급 GPU를 Axelera와 DeepX의 NPU와 와트당 성능으로 견주었고, 그 전부를 관장하는 스케줄링 플레인은 하나였습니다.

기억해 둘 만한 테마

첫째, AI에 대한 책임성은 정책 보고서가 아니라 동작하는 오픈소스의 모습으로 도착하고 있습니다. 데이터를 위한 BOM, 에이전트를 위한 어드미션 정책, AI 주도 변경을 위한 버전 고정 운영이 그것입니다. 둘째, 에이전트 운영에 대한 합의가 만들어지고 있습니다. 에이전트는 분석하고 제안할 수 있지만, 실행은 정책이나 고정된 구성, 또는 사람을 거칩니다. 셋째, GPU 효율은 사용률 대시보드를 벗어나 인프라 그 자체로 들어갔습니다. 사후에 검토되는 것이 아니라 요청 시점에 로드 밸런서와 스케줄러에서 결정됩니다. 넷째, 한국은 두 전선에서 동시에 움직이고 있습니다. 프런티어급 오픈 모델을 공개하는 한편 새 AI 법은 출처를 법적 의무로 만들고 있고, 이 둘은 서로를 강화합니다. 오픈 웨이트는 검증을 부르고, 검증에는 그것을 감당할 기계가 필요합니다.