Broadcom의 VMware 인수 이후 라이선스 비용이 급격히 오르고, AIOps와 딥 옵저버빌리티는 개념으로는 익숙해졌지만 막상 어디서 시작해야 할지 막막한 상황이 이어지고 있습니다. 여기에 최근에는 생성형 AI를 어떻게 안전하게 운영할 것인지 문제까지 더해졌습니다. 지금 하이브리드 인프라 현장을 실질적으로 흔들고 있는 변화들을 순서대로 짚어봅니다. 최근 고객사 미팅에서 반복적으로 등장하는 주제가 있습니다. 하나는 VMware 갱신 시점이 다가올수록 예산 회의가 불편해진다는 이야기고, 다른 하나는 쏟아지는 알람을 처리하느라 정작 중요한 이상 신호를 놓쳤다는 경험담입니다. 그리고 요즘은 여기에 "챗GPT를 팀원들이 업무에 쓰고 있는데, 어디까지 허용해야 할지 모르겠다"는 고민이 하나 더 붙습니다. Red Hat의 2026년 조사에 따르면 응답 조직의 97%가 지난 한 해 동안 클라우드 네이티브 보안 인시던트를 겪었습니다. 그 78%는 정교한 외부 공격이 아닌 잘못된 인프라 구성에서 비롯됐습니다. 보안 우려로 배포를 지연시킨 조직이 74%, 개발자 생산성 저하나 고객 신뢰 손상을 경험한 곳이 92%입니다. 숫자만 나열하면 공포스러운데, 뒤집어 읽으면 대다수 조직이 비슷한 상황에 있다는 이야기이기도 합니다. 이 글에서는 현장을 실제로 움직이고 있는 몇 가지 변화 — 가상화 TCO 구조의 재편, 에이전틱 AIOps의 부상, eBPF 기반 옵저버빌리티, 제로 트러스트 아키텍처의 구체화, AI 거버넌스 체계 수립 — 를 순서대로 살펴보겠습니다. VMware 이후, TCO를 다시 계산해야 하는 이유 가상화 인프라를 운영하는 조직이라면 2024년 이후 라이선스 갱신 시점에서 숫자가 예상보다 많이 달라진 걸 경험했을 겁니다. Broadcom의 VMware 인수가 가져온 가장 큰 변화는 영구 라이선스에서 구독형으로의 전환이지만, 실제로 더 직접적인 타격은 최소 구매 단위의 변화입니다. 기존에는 16코어 단위로 구매하면 됐던 것이 이제는 72코어가 최소 단위입니다. 에지 환경이나 소규모 배포에서 8코어짜리 서버 한 대를 쓰고 있어도 72코어 비용을 내야 합니다. 계산해보면 비용이 350%에서 450% 수준으로 올라가고, 갱신 기한을 놓칠 경우 20% 페널티까지 붙습니다. 과금 기준도 CPU 소켓에서 코어 단위로 바뀌어, 고밀도 서버를 도입할수록 라이선스 비용이 비례해서 올라가는 구조입니다. 구분 기존 모델 (Pre-Broadcom) 현재 모델 (Post-Broadcom) 실질적 영향 라이선스 형태 영구 라이선스 구독형 (Subscription) CapEx → OpEx 전환 강제 최소 구매 단위 16 코어 72 코어 8~16코어 서버 운영 시 최대 350450% 비용 상승 과금 기준 CPU 소켓 단위 CPU 코어 단위 고밀도 서버 도입 시 라이선스 비용 비례 상승 갱신 페널티 해당 없음 갱신 지연 시 20% 할증 계약 주기 관리 실패 시 TCO 즉각 증가 표 1. VMware 인수 전후 라이선싱 모델 비교 이 상황에서 많은 조직이 검토하는 대안이 Nutanix Cloud Platform입니다. Starter, Pro, Ultimate 에디션으로 구성되어 실제 소요 자원에 맞게 비용을 조정할 수 있고, 벤더 종속 없이 운영 자율성을 유지할 수 있다는 점이 주된 이유입니다. IDC 분석에서는 Nutanix 도입 조직이 대규모 환경 기준 연평균 1,060만 달러의 비즈니스 가치를 창출하고 3년 ROI 391%, 비계획적 다운타임 77% 감소를 기록했습니다. 단순 비용 절감이 아니라 운영 안정성 확보가 실질적인 ROI의 상당 부분을 차지한다는 점이 눈에 띕니다. 하드웨어 도입 방식도 바뀌고 있습니다. 온프레미스 환경의 오랜 고민이 3~5년 뒤를 예측해 장비를 미리 사야 하는 과잉 프로비저닝 문제인데, HPE GreenLake Flex Solutions 같은 As-a-Service 모델은 이 문제를 실질적으로 다루고 있습니다. 컴퓨트, 스토리지, 네트워킹이 검증된 구성으로 묶여 제공되고, HPE Consumption Analytics를 통해 실사용량을 실시간으로 확인하면서 예산을 관리할 수 있습니다. 최신 VMware Cloud Foundation(VCF) 9.0 기반 환경을 즉시 배포해 가상 머신과 컨테이너를 동시에 실행하는 구성도 가능합니다. 멀티클라우드 환경에서 이기종 인프라를 단일 인터페이스로 관리하는 오케스트레이션 레이어의 필요성도 점점 커지고 있습니다. Morpheus Enterprise Software는 AWS, Azure, 온프레미스 자원을 클라우드 브랜드에 관계없이 일관된 방식으로 통제하는 접근을 취합니다. 자원이 어디에 있든 동일한 배포 자동화와 풀스택 일관성을 유지할 수 있다는 것이 하이브리드 환경 운영에서 갖는 현실적인 의미입니다. 정적 룰의 한계와 에이전틱 AIOps 수천 개의 컨테이너가 생성됐다 사라지는 환경에서 "CPU 80% 초과 시 알람" 같은 정적 임계값 기반 모니터링은 감당이 안 됩니다. 마이크로서비스 아키텍처가 확산되면서 클라우드 규모가 커질수록 수동으로 업데이트해야 할 룰도 함께 늘어납니다. 결과적으로 트래픽 피크 때마다 쏟아지는 수백 개의 오탐 알람을 처리하다 지쳐서, 정작 중요한 장애 신호를 놓치는 상황이 반복됩니다. 현장에서 흔히 말하는 경고 피로(Alert Fatigue) 문제입니다. AIOps는 이 문제에 대한 실질적인 답이 되고 있습니다. New Relic, OpenText, Dynatrace 같은 플랫폼들이 머신러닝으로 시스템의 정상 상태 베이스라인을 자동으로 정의하고, 여기서 벗어나는 패턴을 감지하는 방식입니다. 특히 Dynatrace의 인과형 AI는 수십억 개의 텔레메트리 상관관계를 밀리초 단위로 평가해 원인-결과 맥락을 파악합니다. 미리 정의되지 않은 제로데이 공격이나 장애 패턴도 식별할 수 있고, 파편화된 알람들이 이벤트 엔트로피 분석을 거쳐 단일 근본 원인으로 통합되면 노이즈를 90%까지 줄일 수 있습니다. * 에이전틱 AIOps vs. 기존 AIOps * 기존 AIOps가 "문제가 여기에 있고, 원인은 이것입니다"라고 진단해주는 역할이었다면, 에이전틱 AIOps는 원인을 찾아서 사용자에게 영향이 가기 전에 포드를 재시작하고 트래픽을 우회시키는 조치까지 스스로 수행합니다. 관찰하는 시스템에서 행동하는 시스템으로의 전환입니다. LogicMonitor의 Edwin AI를 도입한 한 복합 조직이 313%의 ROI를 기록했다는 사례는 수치가 구체적이라 설득력이 있습니다. 시간당 다운타임 비용이 10만 달러인 환경에서 4시간 장애를 30%만 단축해도 인시던트 한 건에서 12만 달러를 아낄 수 있습니다. 중복 알람 억제로 엔지니어 8명이 매주 낭비하던 6시간을 확보했다는 수치도 — 연간 2,400시간, 풀타임 1인 이상의 공수 — AI 도입 비용 대비 논거로 경영진 설득에 쓸 수 있는 프레임입니다. 코드 한 줄 안 건드리고 가시성 확보하기 — eBPF와 딥 옵저버빌리티 AIOps가 제대로 작동하려면 좋은 데이터가 전제되어야 합니다. 보안 리더의 88%가 복잡성 통제를 위해 딥 옵저버빌리티가 필수라고 답했고, 80%는 네트워크 파생 원격 측정 데이터가 반드시 필요하다고 강조했습니다. 문제는 마이크로서비스 환경에서 애플리케이션 가시성을 확보하는 작업이 생각보다 번거롭다는 점입니다. 수백 개의 파일에 트레이싱 SDK를 삽입해야 하고, 라이브러리 버전 충돌이나 CI/CD 파이프라인 오류가 생기면 처음부터 다시 해야 합니다. 사이드카 프록시 방식은 리소스 소모와 네트워크 지연 문제가 따라옵니다. eBPF가 바꾼 것 eBPF(Extended Berkeley Packet Filter)는 이 골칫거리를 커널 수준에서 다르게 접근합니다. 리눅스 커널을 수정하거나 재부팅하지 않고, 커널 내부의 안전한 샌드박스 환경에서 미니 프로그램을 실행하는 방식입니다. 실무에서 가장 의미 있는 부분은 애플리케이션 코드를 전혀 건드리지 않아도 된다는 것입니다. kprobes로 파일 입출력이나 DNS 쿼리를 감시하고, uprobes로 HTTP 메서드와 상태 코드를 인터셉트합니다. CPU 오버헤드는 1~2% 미만으로, 성능 저하 걱정 없이 시스템 콜, 네트워크 패킷, 프로세스 활동을 실시간으로 추적할 수 있습니다. 단, 실무에서는 데이터 폭증을 막기 위해 샘플링 비율을 20% 이하로 제한하거나 특정 라우트만 필터링하는 최적화 작업이 병행돼야 합니다. Grafana Beyla 같은 eBPF 에이전트가 수집한 데이터는 벤더 중립적 표준인 OpenTelemetry 포맷으로 가공되어 OTel Collector를 통해 다양한 백엔드로 전달됩니다. 특정 플랫폼에 묶이지 않는다는 점이 장기 운영에서 중요한 의미를 갖습니다. 데이터를 어디에 어떻게 쌓을 것인가 이렇게 추출된 텔레메트리 데이터를 모든 로그를 중앙 SIEM 하나로 모으는 방식은 스토리지 비용과 데이터 복사 지연이 만만치 않습니다. 가트너는 2030년까지 새 보안 정보 솔루션 구매의 90%가 연합 데이터(Federated Data) 아키텍처를 채택할 것으로 전망합니다. Denodo 플랫폼의 DeepQuery 기능처럼 분산된 데이터 소스에 자연어로 질의하면 최적화된 SQL로 변환해 실시간 분석을 제공하는 방식이 그 대표적인 구현 사례입니다. ETL 과정 없이 비정형 원천 데이터를 직접 저장하고 AI 모델을 학습시킬 수 있는 데이터 레이크하우스 구조도 보안 위협 분석의 기반으로 자리 잡고 있습니다. 측면 이동을 막아라 — CNAPP과 제로 트러스트 하이브리드 인프라에서 가장 불안한 영역을 꼽으라면 퍼블릭 클라우드입니다. 리더들의 70%가 퍼블릭 클라우드를 보안상 가장 취약한 고리로 지목했고, 거의 절반이 퍼블릭 클라우드 내 측면 이동(Lateral East-West Traffic) 가시화에 실패했다고 답했습니다. 2025년 침해를 경험한 조직의 50%는 기존 보안 도구가 위협을 전혀 탐지하지 못했습니다. 공격 양상도 달라지고 있습니다. 사이버 침해의 83%, 피싱의 86%가 이제 AI 주도형입니다. 2025년 6월에 식별된 Akira 랜섬웨어 변종은 SonicWall 취약점(CVE-2024-40766)을 통해 내부망에 진입한 뒤, Rust 기반의 Megazord와 Akira_v2를 교차 사용하며 Nutanix AHV와 ESXi 가상화 환경의 VM 디스크 파일을 직접 암호화했습니다. 추정 범죄 수익이 2억 4,400만 달러 규모입니다. 측면 이동을 통제하지 못하는 환경에서는 초기 진입 하나로 인프라 전체가 무력화될 수 있다는 것을 보여주는 사례입니다. CNAPP과 제로 트러스트의 연결 클라우드 보안 솔루션은 이 문제를 풀기 위해 인프라 설정 오류를 탐지하는 CSPM과 런타임 위협을 차단하는 CWPP를 통합한 CNAPP으로 진화했습니다. 설정 오류(컨트롤 플레인)와 워크로드 취약점(데이터 플레인)을 따로 보면 연관된 독성 리스크(Toxic Risks)를 놓치기 때문입니다. CNAPP의 기반 철학이 제로 트러스트 아키텍처(ZTA)입니다. "Never Trust, Always Verify" 원칙 아래 eBPF로 확보한 텔레메트리 데이터를 바탕으로 네트워크 마이크로세그멘테이션을 구현합니다. Nutanix는 CNCF 프로젝트인 KubeArmor 및 AccuKnox와 협업해 커널 레벨 가시성을 확보하고, 파일 시스템 접근과 실행 권한을 런타임에 동적으로 제어합니다. 여기에 별도 복호화 장비 없이 암호화된 트래픽 내부의 위협을 식별하는 프리크립션(Precryption) 기술을 결합하면 방어 레이어가 한 겹 더 추가됩니다. 보안을 강화하면 성능 트레이드오프가 생기는 건 사실입니다. ORAM 기반 검색 엔진 Epsolute는 100만 레코드 기준 840ms 응답 시간으로, 일반 RDBMS보다 4~8배 느립니다. 다만 전체 데이터를 순차적으로 읽는 선형 스캔보다는 18배 빠르며, 데이터 민감도와 네트워크 지연 사이의 최적점을 찾는 파라미터 조정이 실무에서 중요해집니다. 생성형 AI를 조직에서 안전하게 운영하려면 기업의 69%가 생성형 AI가 경쟁 구도를 바꿀 것으로 예측하지만, AI를 조직에 도입하는 것과 안전하게 운영하는 것은 다른 문제입니다. CIO들이 가장 골머리를 앓는 것 중 하나가 직원들이 승인되지 않은 AI 모델을 가져다 쓰는 섀도우 AI 문제입니다. Nutanix Enterprise AI(NAI)는 NVIDIA NIM 및 NeMo 프레임워크와 통합해 AI 모델 배포와 추론 성능 최적화를 지원하고, 중앙 집중식 LLM 모델 저장소와 토큰 사용량 대시보드로 조직 내 AI 요청 활동을 가시화합니다. FIPS 140-3 규격을 준수하는 Ubuntu Pro 지원은 규제가 강한 산업 환경에서 중요한 요소입니다. OVHcloud처럼 데이터 주권이 중요한 환경에서는 소버린 클라우드 내에서 AI를 운영하는 전략이 실질적인 의미를 갖습니다. 환각 문제 다루기 AI 운영의 기술적 난제 중 하나인 환각 문제는 다층적으로 대응해야 합니다. 훈련 단계에서는 RLHF(인간 피드백 기반 강화학습)로 모델을 파인튜닝하고, 아키텍처 단계에서는 RAG(검색 증강 생성)로 외부 데이터베이스를 참조하게 만듭니다. 사용자 프롬프트 단에서 체인 오브 소트(CoT)를 유도해 논리적 오류를 줄이고, 생성 단계에서 DoLa 같은 디코딩 전략을 파이프라인에 복합적으로 적용하는 구조입니다. 에이전틱 AI 거버넌스: Human-in-the-Loop 설계 가트너가 2026년의 핵심 테마로 지목한 에이전틱 AI는 챗봇 수준을 넘어 스스로 목표를 설정하고 판단하는 방향으로 발전하고 있습니다. 2027년까지 다중 에이전트 시스템의 70%가 고도의 전문 역할을 수행할 것으로 전망되지만, 에이전트 간 공유 메모리 충돌이나 환각 증폭, 오작동으로 인한 재무적 손실 리스크는 현실적인 위험입니다. 에이전틱 AI의 거버넌스는 하루아침에 완전 자율로 갈 수 없고, 점진적으로 설계해야 합니다. Human-in-the-Loop (직접 지원) — AI가 초안을 잡고 인간이 최종 결정하는 구조. 현재 대부분의 조직이 있는 단계입니다. Human-on-the-Loop (감독) — AI가 결정하되 인간이 감독자로서 예외 상황에 개입합니다. Humans-out-of-the-Loop (완전 자율) — AI가 유동적이고 연속적인 결정을 내리고, 인간은 거시적 파라미터만 조정합니다. 어느 단계에 있든 중요한 것은, 신뢰도가 임계값(통상 80~90%) 이하이거나 인프라 설정 변경 같은 고위험 작업에서는 반드시 사람의 승인을 거치는 구조를 만드는 것입니다. EU AI Act 같은 고위험 AI 규제 대응에도 이 구조가 전제가 됩니다. HITL 프레임워크 요소 실행 방안 기대 효과 인시던트 대응 플레이북 환각 또는 정확도 저하 탐지 시 모델 롤백, 백업 전환, 이해관계자 소통 등 사전 정의된 매뉴얼 가동 신속하고 일관된 복구로 비즈니스 임팩트 최소화 에스컬레이션 워크플로우 리스크 수준에 따라 하위 문제는 자동 처리, 고위험·규제 위반 문제는 법무·데이터 사이언티스트 티어로 자동 이관 치명적 오작동 방지 및 전문가 리소스 최적화 피드백 기반 지속 개선 인간 오버라이드 비율, 만족도 데이터, 에스컬레이션 비율(권장 10~15%) 수집 후 엣지 케이스 재학습에 반영 시간이 지남에 따라 모델 정확도와 안전성 향상 효율적 AI 훈련 (MBTL) 무작위 데이터가 아닌 시스템 전반 성능을 극대화할 핵심 태스크만 선별해 집중 학습 (MIT MBTL 알고리즘 활용) 기존 대비 5~50배 학습 효율성 및 자원 절감 ** 표 2. 에이전틱 AI 인간 참여형(HITL) 거버넌스 프레임워크** 맹목적인 자동화보다 적재적소에 개입할 수 있는 구조를 유지하는 것이 조직의 AI 신뢰도를 결정합니다. MIT의 MBTL 알고리즘은 불필요한 데이터 소모를 줄여 컴퓨팅 비용을 낮추는 동시에 학습 효율을 높여줍니다. 무조건 사람을 빼는 것이 혁신이 아니라, 언제 어디서 사람이 개입할 수 있어야 하는지를 설계하는 것이 관건입니다. 탄소와 예측 — 지속 가능성과 디지털 트윈 인프라 운영의 책임 범위가 시스템 가용성을 넘어 탄소 배출 영역으로 확장되고 있습니다. HPE Sustainability Insight Center는 AI를 활용해 에너지 사용 패턴을 분석하고 향후 탄소 배출량을 예측하며, 소비 전력의 출처(태양광, 풍력 등)를 추적해 지속 가능성 목표 달성을 데이터로 입증할 수 있도록 지원합니다. ESG 보고 요건이 강화되는 환경에서는 이 데이터를 어떻게 확보하느냐가 실질적인 문제가 됩니다. 변경 사항이 라이브 서비스에 미치는 영향을 사전에 검증하는 디지털 트윈도 실용적인 도구로 자리 잡고 있습니다. 실제 네트워크 상태를 가상 공간에 복제하고 정책 변경을 시뮬레이션하면, 설정 오류가 퍼질 범위(Blast Radius)를 배포 전에 확인할 수 있습니다. 다운타임 없이 배포를 검증하고 싶은 현장 수요와 정확히 맞닿아 있는 기술입니다. 마치며 2026년 하이브리드 인프라의 화두는 결국 복잡성을 어떻게 다스릴 것인가로 모입니다. 벤더 라이선싱에 끌려다니지 않도록 TCO 자율성을 확보하고, 경고 알람의 소음 속에서 에이전틱 AIOps로 운영을 자동화하고, eBPF와 딥 옵저버빌리티로 인프라 내부를 투명하게 보이게 만들고, 제로 트러스트를 내재화해 측면 이동 경로를 차단하고, AI 거버넌스 체계를 갖춰 에이전틱 AI의 폭주를 막는 것 — 이 다섯 가지가 지금 시점의 실무 과제입니다. 기술 트렌드를 따라가다 보면 어느 것부터 시작해야 할지 막막할 때가 있습니다. 여러분의 현장에서 가장 시급하게 느끼는 부분이 어디인지, 댓글로 남겨주시면 그 주제를 좀 더 깊이 다루겠습니다. 참고 자료 2026 하이브리드 클라우드 보안 트렌드 분석 State of Cloud Native Security 2026: Maturity Gaps and Automation Mandate — Red Hat 하이브리드 멀티클라우드 전환을 통한 비즈니스 가치 극대화 및 ROI 분석 전략 가이드 하이브리드 클라우드 마스터하기: HPE GreenLake와 Morpheus로 여는 현대적 IT의 미래 Autonomous Security and Human-in-the-Loop Oversight Systems AIOps란? — New Relic AIOps란? IT 운영을 위한 인공지능 — Everpure엔터프라이즈를 위한 AIOps 플랫폼 — OpenText AIOps (AI for IT Operations) — Dynatrace 클라우드 보안 및 LLM 보안 연구 가이드 하이브리드 멀티클라우드 시대의 혁신 가속화: Nutanix 통합 플랫폼 전략
개요 폰을 케이블로 데스크탑에 꽂아두고 Claude Code 에게 "앱이 왜 죽는지 봐줘" 라고 하면, 알아서 기기 모델과 OS 버전을 확인하고 로그를 뒤져서 크래시 원인을 찾아온다. 처음 보면 Claude Code 가 폰과 직접 통신하는 특별한 기능이 있는 것처럼 느껴진다. 실제로는 그런 기능이 없다. Claude Code 가 하는 일은 터미널에서 adb 나 xcrun devicectl 같은 명령을 실행하고 그 출력을 읽는 것뿐이다. 폰과 통신하는 일은 원래 있던 개발 도구들이 하고, Claude Code 는 그 도구를 사람 대신 두드린다. 이 글은 케이블을 꽂는 순간부터 Claude Code 가 폰의 값을 읽어내기까지 어떤 층이 쌓여 있는지를 아래에서부터 정리한다. Android 를 중심으로 보고, iOS 는 차이점만 짚는다. 전체 구조 먼저 그림 한 장으로 층을 나눠두면 이후 내용이 편하다. ┌──────────────────────────────────────────────┐ │ Claude Code (에이전트 루프) │ 어떤 명령을 칠지 판단 │ └─ Bash 도구 │ 명령 실행 → stdout 읽기 ├──────────────────────────────────────────────┤ │ adb client ──▶ adb server (localhost:5037) │ 데스크탑의 프로세스 ├──────────────────────────────────────────────┤ │ USB 프로토콜 (ADB 인터페이스) │ 케이블 ├──────────────────────────────────────────────┤ │ adbd (폰의 데몬) ──▶ shell, getprop, logcat │ 폰 안에서 실제 실행 └──────────────────────────────────────────────┘ 위 두 층과 아래 세 층은 완전히 독립적이다. Claude Code 가 없어도 아래 세 층은 그대로 동작하고, 개발자가 터미널에 adb logcat 을 치는 것과 Claude Code 가 치는 것은 폰 입장에서 구분되지 않는다. 케이블과 USB 인터페이스 데이터 선이 있는 케이블 USB-C 케이블이라고 다 같은 게 아니다. 충전 전용 케이블은 전원 선만 있고 데이터를 주고받는 D+/D− 선이 빠져 있다. 이런 케이블을 꽂으면 폰은 충전만 되고, 데스크탑의 USB 장치 목록에 아예 나타나지 않는다. adb devices 가 빈 목록을 돌려줄 때 설정보다 케이블을 먼저 의심해야 하는 이유가 이것이다. 폰에 딸려온 케이블이나 데이터 전송이 명시된 케이블을 쓰는 게 가장 빠른 해결책이다. 폰이 자신을 소개하는 과정 데이터 선이 연결되면 데스크탑의 USB 호스트가 폰에게 "너는 어떤 장치냐" 를 묻는다. 폰은 자신이 제공하는 인터페이스 목록으로 답한다. 파일 전송용 MTP, 사진 전송용 PTP, 그리고 개발자 옵션에서 USB 디버깅을 켜면 ADB 인터페이스 가 이 목록에 추가된다. ADB 인터페이스는 class 0xFF , subclass 0x42 , protocol 0x01 이라는 고유한 조합으로 식별된다. 데스크탑의 adb server 는 이 조합을 가진 USB 인터페이스를 찾아서 폰으로 인식한다. 폰의 USB 모드가 "충전만" 으로 되어 있어도 디버깅이 켜져 있으면 대부분 이 인터페이스는 살아 있다. ADB 의 세 구성 요소 ADB 는 하나의 프로그램이 아니라 세 조각으로 나뉘어 있다. client — 터미널에서 실행하는 adb 명령 그 자체다. 명령을 받아서 server 로 넘기고 결과를 출력한 뒤 종료된다. server — 데스크탑에서 백그라운드로 상주하며 localhost:5037 을 연다. USB 로 연결된 기기를 감시하고, 여러 client 의 요청을 적절한 기기로 보낸다. adbd — 폰 안에서 도는 데몬이다. server 가 보낸 요청을 받아 셸 명령을 실행하고 결과를 돌려준다. 처음 adb devices 를 치면 "daemon not running; starting now at tcp:5037" 이 찍히는 게 server 가 뜨는 순간이다. 그 다음부터는 같은 server 를 재사용한다. 이 구조 덕분에 Android Studio, React Native CLI, 터미널, Claude Code 가 동시에 같은 폰을 붙잡고 있어도 충돌하지 않는다. 전부 같은 server 에 요청하는 client 일 뿐이다. 반대로 Android Studio 가 들고 있는 adb 와 PATH 상의 adb 버전이 다르면 서로 server 를 죽이고 다시 띄우는 일이 반복되는데, 기기가 붙었다 끊겼다 하는 증상의 흔한 원인이다. RSA 키 인증 USB 디버깅은 폰의 셸을 통째로 여는 권한이라 아무 컴퓨터에나 허용되면 안 된다. 그래서 처음 연결할 때 RSA 키로 인증한다. 데스크탑의 adb 는 처음 실행될 때 ~/.android/adbkey 와 adbkey.pub 키 쌍을 만든다 폰에 연결하면 adbd 가 인증을 요구하고, server 는 공개키를 보낸다 폰 화면에 "USB 디버깅을 허용하시겠습니까?" 팝업과 키 지문이 뜬다 허용하면 공개키가 폰의 /data/misc/adb/adb_keys 에 저장된다 허용 전 상태에서 adb devices 를 치면 기기 옆에 unauthorized 가 찍힌다. Claude Code 가 이 출력을 받으면 "폰 화면에서 디버깅 허용을 눌러달라" 고 요청하는데, 이것도 특별한 지능이 아니라 이 상태 문자열의 의미를 알고 있어서다. unauthorized 가 계속 풀리지 않으면 폰의 개발자 옵션에서 "USB 디버깅 권한 승인 취소" 를 누르고 다시 연결하면 대부분 해결된다. Claude Code 가 값을 읽어내는 방식 여기까지가 폰과 데스크탑이 통신할 수 있는 기반이다. Claude Code 는 이 위에서 도구를 사용하는 에이전트로 동작한다. 에이전트 루프와 Bash 도구 Claude Code 의 동작은 단순한 반복이다. 모델이 다음에 할 행동을 고르고, 도구가 그걸 실행하고, 결과를 다시 모델이 읽는다. 폰과 관련된 작업에서 쓰이는 도구는 대부분 Bash 다. "연결된 폰 정보 알려줘" 라는 요청이 들어오면 흐름은 대략 이렇다. $ adb devices List of devices attached R3CT50ABCDE device $ adb shell getprop ro.product.model SM-S928N $ adb shell getprop ro.build.version.sdk 35 $ adb shell wm size Physical size: 1440x3120 모델은 학습 과정에서 adb 의 사용법과 출력 형식을 이미 알고 있다. 그래서 첫 명령의 결과를 보고 기기가 하나 붙어 있다는 걸 확인하고, 이어서 필요한 값을 읽는 명령을 스스로 고른다. 출력이 사람이 읽을 수 있는 텍스트라는 점도 중요하다. 별도의 파서 없이 모델이 그대로 해석할 수 있다. "알아서 파악한다" 는 느낌의 정체가 여기에 있다. 폰이 데이터를 밀어주는 게 아니라, 모델이 상황에 맞는 명령을 연달아 실행하며 끌어오는 것이다. 자주 읽는 값들 실무에서 Claude Code 가 주로 쓰는 명령은 정해져 있다. 목적 명령 기기 모델, OS 버전 adb shell getprop ro.product.model , ro.build.version.release 화면 크기와 밀도 adb shell wm size , adb shell wm density 설치된 앱 버전 adb shell dumpsys package <패키지명> | grep versionName 메모리 사용량 adb shell dumpsys meminfo <패키지명> 로그 adb logcat 스크린샷 adb exec-out screencap -p > screen.png 현재 화면의 뷰 계층 adb shell uiautomator dump 스크린샷은 특히 유용하다. 이미지 파일로 저장한 뒤 Claude Code 가 그 파일을 읽으면 화면을 직접 보고 레이아웃 문제를 판단할 수 있다. 텍스트 명령만으로는 알 수 없는 시각적 상태까지 확인 범위가 넓어진다. React Native 개발에서의 활용 RN CLI 개발자에게는 사실 익숙한 구조다. npx react-native run-android 도 내부적으로 adb 를 호출해서 APK 를 설치하고 앱을 실행한다. Metro 에 연결하는 것도 adb reverse tcp:8081 tcp:8081 로 폰의 8081 포트를 데스크탑으로 돌려두는 방식이다. Claude Code 는 같은 도구를 같은 방식으로 쓴다. 크래시 원인 추적 가장 효과가 큰 건 로그 분석이다. logcat 은 출력량이 많아서 사람이 눈으로 훑기 어려운데, Claude Code 는 필터링과 해석을 한 번에 한다. # RN 관련 로그만 adb logcat ReactNative:V ReactNativeJS:V *:S # 네이티브 크래시 adb logcat -b crash -d New Architecture 환경에서는 TurboModule 이나 Fabric 컴포넌트에서 네이티브 크래시가 나면 JS 쪽 에러 화면 없이 앱이 그냥 꺼지는 경우가 있다. 이때 -b crash 버퍼에 남은 스택 트레이스를 Claude Code 가 읽고, 프로젝트의 네이티브 코드에서 해당 지점을 찾아가는 흐름이 꽤 쓸 만하다. 반복 확인 자동화 화면을 고치고 결과를 확인하는 사이클도 맡길 수 있다. 코드를 수정하고, Fast Refresh 가 반영될 시간을 두고, 스크린샷을 찍어서 의도대로 바뀌었는지 확인하는 과정을 Claude Code 가 혼자 돌린다. 여러 기기를 붙여두면 adb -s <serial> 로 기기별로 같은 확인을 반복해 화면 크기별 차이도 비교할 수 있다. 권한 설정 Claude Code 는 Bash 명령을 실행하기 전에 매번 허락을 구한다. adb 명령을 자주 쓴다면 프로젝트의 .claude/settings.json 에 허용 목록을 넣어두는 편이 편하다. { "permissions": { "allow": [ "Bash(adb devices)", "Bash(adb logcat:*)", "Bash(adb shell getprop:*)", "Bash(adb exec-out screencap:*)" ] } } Bash(adb:*) 처럼 통째로 열어두는 건 권하지 않는다. adb uninstall 이나 adb shell pm clear 처럼 앱 데이터를 날리는 명령도 함께 허용되기 때문이다. 읽기 위주 명령만 열어두고, 상태를 바꾸는 명령은 확인을 거치게 두는 게 안전하다. 프로젝트에서 자주 쓰는 패키지명이나 로그 태그는 CLAUDE.md 에 적어두면 Claude Code 가 매번 추측하지 않고 바로 쓴다. iOS 의 경우 iOS 도 원리는 같다. 다만 층을 구성하는 도구가 다르다. usbmuxd — macOS 에 상주하는 데몬으로, USB 위에 여러 TCP 연결을 다중화한다. adb server 와 비슷한 위치다 페어링 — 폰 화면의 "이 컴퓨터를 신뢰하겠습니까?" 가 RSA 키 인증에 해당한다. 수락하면 페어링 레코드가 맥에 저장된다 명령 도구 — Xcode 15 이후로는 xcrun devicectl 이 기본이다. xcrun devicectl list devices 로 연결된 기기를, xcrun devicectl device info details --device <id> 로 상세 정보를 읽는다 실무에서 체감되는 차이는 로그다. Android 의 logcat 만큼 터미널에서 편하게 스트리밍할 수 있는 공식 도구가 마땅치 않아서, libimobiledevice 의 idevicesyslog 같은 서드파티 도구를 쓰거나 Xcode 콘솔에 의존하게 된다. 그래서 Claude Code 와 실기기를 함께 쓰는 흐름은 아직 Android 쪽이 훨씬 매끄럽다. 시뮬레이터라면 xcrun simctl 로 스크린샷과 로그를 다룰 수 있어서 사정이 낫다. 주의사항 USB 디버깅은 강한 권한이다. adb 로 연결된 상태에서는 앱 설치와 삭제, 앱 데이터 접근, 화면 입력 조작까지 가능하다. 개인 폰을 테스트 기기로 쓴다면 작업이 끝난 뒤 디버깅을 꺼두는 습관이 좋다. 여러 기기가 붙어 있으면 대상을 명시해야 한다. 기기가 둘 이상이면 adb shell 은 "more than one device" 에러를 낸다. Claude Code 는 보통 이 에러를 보고 -s 옵션을 붙여 다시 시도하지만, 어떤 기기를 대상으로 할지는 처음부터 알려주는 편이 낫다. 에뮬레이터가 켜져 있는 걸 잊고 있다가 엉뚱한 기기의 로그를 보는 일이 생각보다 흔하다. 무선 디버깅도 같은 구조다. Android 11 이상은 adb pair 로 Wi-Fi 연결을 맺을 수 있다. 이 경우 USB 층이 TCP 로 바뀔 뿐 adb server 위쪽은 그대로라서 Claude Code 입장에서는 차이가 없다. 정리 케이블을 꽂으면 Claude Code 가 폰을 알아서 파악하는 것처럼 보이지만, 실제로는 여러 층이 각자의 일을 하고 있다. 데이터 선이 있는 케이블이 USB 연결을 만들고, USB 디버깅이 ADB 인터페이스를 열고, RSA 키 인증이 이 컴퓨터를 믿을 수 있는지 확인한다. adb server 가 그 위에서 기기를 관리하고, 폰의 adbd 가 명령을 실제로 실행한다. 여기까지는 Claude Code 와 무관하게 원래 존재하던 구조다. Claude Code 는 그 맨 위에서 터미널을 쓰는 사람의 자리를 대신한다. adb 의 사용법과 출력 형식을 알고 있는 모델이 Bash 도구로 명령을 실행하고, 결과를 읽고, 다음 명령을 고른다. "알아서" 의 정체는 이 판단의 연쇄다. 이렇게 보면 문제가 생겼을 때 어디를 봐야 하는지도 분명해진다. adb devices 가 기기를 못 찾으면 케이블이나 디버깅 설정 문제이고, unauthorized 면 인증 문제이고, adb 는 잘 되는데 Claude Code 가 엉뚱한 일을 하면 그건 대상 기기나 패키지명 같은 맥락을 더 알려줘야 하는 문제다.
문제 링크 : https://school.programmers.co.kr/learn/courses/30/lessons/12941?language=java 난이도 : Lv.2 분류 : 구현 요약 : A 배열과 B 배열 안의 각 요소를 곱하고 더한 경우의 수 중 가장 낮은 값을 구하기 접근 방법 입력 크기 / 시간 제한으로 판단한 방향: 경우의 수 탐색하기 사용한 알고리즘 / 자료구조와 선택 이유: 순열 => 정렬 후 계산 풀이 코드 기존 풀이 코드 class Solution { int [] A, B; boolean [] v; int answer = Integer.MAX_VALUE; void combination(int depth, int sum) { if (depth == A.length) { answer = Math.min(answer, sum); return ; } for (int i=0;i<v.length;i++) { if (!v[i]) { v[i] = true; combination(depth + 1, sum + A[depth] * B[i]); v[i] = false; } } } public int solution(int []A, int []B) { this.A = A; this.B = B; v = new boolean [A.length]; combination(0, 0); return answer; } } 개선 코드 import java.util.Arrays; class Solution { public int solution(int []A, int []B) { int answer = 0, len = A.length; Arrays.sort(A); Arrays.sort(B); for (int i=0;i<len;i++) { answer += A[i] * B[len-1-i]; } return answer; } } 복잡도 시간: O(n!) => O(nlogn); 공간: O(nlogn)
2회차 | 구체적인 흐름과 설계 0. 이번 글에서 정하는 것 1회차에서 이음의 방향을 정했다. AI 상담이 해결하지 못해 상담원에게 넘어갈 때, 고객이 처음부터 다시 설명하지 않도록 맥락을 넘겨주는 금융 상담 백엔드다. 이번 글에서는 문의 하나를 처음부터 끝까지 따라가면서, 설계 전에 정해야 할 것들을 결정한다. 대상 시나리오: 카드 이중 결제 문의 결과물 1: 정상 흐름과 단계별로 남길 기록 결과물 2: 이관 패키지에 담을 것과 담지 않을 것 결과물 3: 네 가지 결정 (이관 기준, 인증 승계, 배정 방식, 챗봇 처리 범위) 결과물 4: 예외 흐름 네 가지 1. 등장인물과 시스템 이 흐름에는 사람 셋과 시스템 둘이 나온다. 구분 이름 역할 사람 고객 Telegram 챗봇으로 문의 사람 상담원 웹 상담원 화면에서 이관된 상담 처리 사람 센터·준법 담당 이관 사유와 고객 정보 조회 기록 확인 시스템 이음 (채널계) 챗봇 상담, 이관 판단, 이관 패키지 생성, 배정, 기록 시스템 가상 은행 (계정계) 고객, 카드, 승인 내역 등 금융 데이터 보유 2. 왜 카드 이중 결제부터인가 카드 이중 결제는 챗봇이 혼자 끝내기 어렵고, 상담원이 판단할 근거가 필요한 문의다. 이번 주 금테크 스터디에서 카드 결제 흐름을 조사하면서 확인한 내용이 그 이유다. 카드 결제는 승인 과 매입 이 나뉘어 있다 승인: 카드사가 결제를 허가하는 단계. 신용카드는 이 시점에 한도만 차감되고, 체크카드는 바로 출금된다 매입: 승인된 결제를 카드사에 청구해 정산받는 단계 취소도 시점에 따라 다르다 매입 전 취소는 승인 취소로 즉시 처리된다 매입 후 취소는 환불까지 2~3영업일이 걸린다 그래서 고객 눈에는 똑같이 두 번 결제로 보여도, 상담원이 확인해야 할 상황은 여러 가지다. 실제로 같은 결제가 두 번 승인된 경우 응답을 받지 못해 다시 요청하면서 두 건이 승인된 경우 한 건은 이미 취소됐지만 환불이 아직 반영되지 않은 경우 결론: 상담원 화면에는 승인 금액만이 아니라 승인 건별 상태와 시각이 함께 있어야 한다. 이 결정이 이후 이관 패키지 설계로 이어진다. 3. 정상 흐름 카드 이중 결제 문의는 아래 순서로 흘러간다. 오른쪽은 각 단계에서 이음이 남기는 기록이다. [고객] [이음 · 챗봇] [가상 은행] [상담원] │ 카드 결제가 두 번 됐어요 ├──────────────▶│ MESSAGE_RECEIVED │ │ 본인 확인 요청 (PIN) │◀──────────────┤ ├──────────────▶│ AUTH_VERIFIED │ │ 문의 분류: 카드 이중 결제 INTENT_CLASSIFIED │ │ 최근 승인 내역 조회 │ ├──────────────────────▶│ │ │◀──────────────────────┤ CORE_QUERIED │ │ 같은 가맹점·같은 금액 2건 발견 │ 승인 내역 안내 │ │◀──────────────┤ BOT_REPLIED │ 상담원 연결해 주세요 ├──────────────▶│ HANDOFF_DECIDED │ │ 이관 패키지 생성 HANDOFF_PACKAGED │ │ 대기열 등록 QUEUED │ │ 상담원이 가져감 │ │◀───────────────────────────────────────┤ ASSIGNED │ │ 이관 패키지 전달 ─────────────────────────▶│ │◀──────────────┼──────────── 상담원 채팅 ──────────────────┤ AGENT_MESSAGE │ │ 승인 취소 요청 │ │ ├──────────────────────▶│◀────────────────┤ FOLLOWUP_REQUESTED │ │◀──────────────────────┤ FOLLOWUP_CONFIRMED │ │ 상담 종료 │ │ │ 요약·분류 초안 생성 SUMMARY_DRAFTED │ │ 초안 확정 │ CLOSED 이 흐름에서 정한 원칙은 세 가지다. 모든 단계는 상담 이벤트 로 남고, 수정하지 않고 추가만 한다 이관 패키지는 이관 시점까지 쌓인 이벤트를 묶은 결과다 가상 은행을 조회할 때마다 조회 기록을 함께 남긴다 4. 이관 패키지에 무엇을 담나 이관 패키지는 상담원이 고객에게 다시 묻지 않고 바로 용건부터 확인할 수 있는 만큼만 담는다. 구분 항목 이유 필수 상담 ID, 내부 고객 식별자 상담과 고객을 잇는 기준 필수 본인 확인 결과, 방식, 시각 인증 승계 판단 근거 필수 문의 분류 결과 상담원의 첫 질문을 정하는 기준 필수 이관 사유 통계와 상담원 대응 방식 결정 필수 챗봇 대화 원문 요약이 틀렸을 때 원문으로 확인 필수 챗봇이 조회한 내역과 조회 시각 같은 조회를 반복하지 않기 위해 필수 챗봇이 이미 처리한 것 같은 처리를 두 번 하지 않기 위해 선택 불만 신호 (감지된 키워드) 상담원 첫 응대 방식 참고 선택 최근 상담 이력 반복 문의 여부 확인 담지 않음 카드번호 전체 끝 4자리만 표시 담지 않음 PIN 등 인증 정보 원문 인증 결과만 넘긴다 담지 않음 용건과 무관한 금융 정보 (전체 계좌 잔액 등) 필요한 경우 상담원이 사유를 남기고 추가 조회 카드 이중 결제의 경우 승인 내역은 건별로 이렇게 담는다. 항목 예시 가맹점 강남 OO카페 금액 4,500원 승인 시각 2026-10-04 12:31:05 상태 승인 / 매입 / 취소 승인번호 끝 4자리 조회 시각 2026-10-04 12:33:40 조회 시각을 함께 담는 이유는, 상담원이 보는 정보가 실시간 값이 아니라 챗봇이 조회한 시점의 값 이라는 걸 분명히 하기 위해서다. 상담원이 최신 상태가 필요하면 다시 조회한다. 5. 네 가지 결정 5-1. 언제 상담원에게 넘기나 (이관 기준) 결정: 아래 네 가지 중 하나라도 해당하면 넘긴다. 판단은 모두 규칙으로 한다. 이관 사유 판단 방법 고객이 상담원 연결을 요청 상담원, 사람, 연결 등 키워드 같은 용건 해석 실패 2회 문의 분류 실패 횟수 챗봇 권한 밖 업무 승인 취소 요청, 이의 제기, 카드 정지 해제 불만 신호 감지 불만 키워드 선택지로 AI가 이관 여부를 판단하는 방식도 있었지만 제외했다 이유: 같은 상황에서 항상 같은 결과가 나와야 이관 사유 통계를 믿을 수 있다 2회라는 기준은 가정값이다. 정책 데이터로 분리해서 나중에 바꿀 수 있게 한다 5-2. 챗봇의 본인 확인을 상담원이 이어받나 (인증 승계) 결정: 챗봇에서 본인 확인을 마친 뒤 10분 이내이고 조회성 상담이면 이어받는다. 위험을 늘리는 처리는 다시 확인한다. 상황 처리 본인 확인 후 10분 이내, 조회·안내 상담 승계, 상담원은 다시 묻지 않음 본인 확인 후 10분 초과 상담원이 다시 확인 카드 정지 해제 등 위험을 늘리는 처리 시간과 관계없이 다시 확인 항상 다시 확인하면 1회차에서 정한 재설명 문제가 그대로 남는다 항상 승계하면 오래된 인증으로 위험한 처리가 될 수 있다 10분은 가정값이다. 실제 금융사의 인증 유효시간 기준은 따로 확인이 필요하다 5-3. 누구에게 넘기나 (배정 방식) 결정: 상담원이 대기열에서 직접 가져가는 방식으로 한다. 여러 상담원이 동시에 가져가도 한 명만 성공한다. 선택지 장점 단점 상담원이 가져가기 (선택) 상담원 상태를 시스템이 몰라도 됨, 구현 단순 동시에 여러 명이 같은 건을 누를 수 있음 시스템이 배정하기 대기 시간 관리가 쉬움 상담원 상태 추적, 배정 알고리즘 필요 동시 수락 문제는 조건부 UPDATE로 막는다 블로그 스터디 1주차에 회의실 예약 중복을 실험하면서, 조건부 UPDATE가 충돌한 요청만 정확히 막는 것을 확인했다 같은 방식을 상담 배정에 적용하고, 구현 회차에서 동시 수락 테스트로 검증한다 5-4. 챗봇은 어디까지 처리하나 (챗봇 처리 범위) 결정: 위험을 줄이는 처리와 조회는 챗봇이 끝낸다. 위험을 늘리거나 판단이 필요한 처리는 상담원이 한다. 챗봇이 처리 상담원이 처리 승인 내역 조회 승인 취소 요청 이체 상태 조회 이의 제기 접수 이자 조회 카드 정지 해제 카드 분실 정지 카드 분실 정지는 위험을 줄이는 처리라서 챗봇이 바로 한다 정지 해제는 같은 카드에 대한 처리지만 위험을 늘리는 처리라서 상담원에게 넘긴다 1회차에서 정한 원칙과 같다: 위험을 줄이는 요청은 빠르게, 늘리는 요청은 신중하게 6. 예외 흐름 정상 흐름 외에 반드시 정해둬야 할 예외는 네 가지다. 구현은 이후 회차에서 한다. 예외 어떻게 처리하나 대기 중 고객 이탈 상담을 이탈 상태로 바꾸고 이관 패키지는 보존. 30분 이내 재접속하면 이어서 처리 배정 후 상담원 무응답 가져간 뒤 60초 안에 첫 응답이 없으면 대기열로 되돌림 가상 은행 일부 장애 카드 정보 조회가 실패해도 이관 패키지는 생성. 해당 항목은 조회 불가로 표시하고 상담원이 다시 조회 후속 처리 결과 불명 승인 취소 요청의 응답이 끊기면 다시 요청하지 않고 처리 상태를 조회해서 확정. 확정 전에는 고객에게 처리 확인 중이라고 안내 마지막 예외는 카카오페이 기술블로그에서 소개한 방식을 따른다. 결과를 성공, 실패, 알 수 없음 세 가지로 나누고, 알 수 없음은 조회로 확정한다 30분, 60초는 가정값이다 7. 나머지 시나리오는 무엇이 다른가 카드 이중 결제와 같은 흐름을 쓰되, 아래 부분만 다르다. 시나리오 챗봇 단계 이관 패키지의 핵심 항목 송금했는데 상대가 못 받음 이체 상태 조회. 처리 중이면 안내로 종료 가능 거래번호, 이체 상태, 요청 시각 이자가 왜 이것밖에 안 되나 이자 조회. 대부분 챗봇에서 종료 일별 잔액, 적용 금리 등 산출 근거 카드 분실 챗봇이 정지까지 처리. 재발급 문의만 이관 정지 처리 결과와 시각 상담원 연결 요청, 해석 실패 용건 파악 전에 이관 챗봇 대화 원문, 이관 사유 8. 정리 정한 것 모든 상담 단계는 상담 이벤트로 남기고, 이관 패키지는 이벤트를 묶어서 만든다 이관 패키지의 필수, 선택, 담지 않는 항목 이관 기준 네 가지, 모두 규칙으로 판단 인증 승계는 시간과 처리 위험도로 판단 배정은 상담원이 가져가는 방식, 조건부 UPDATE로 한 명만 성공 챗봇은 조회와 위험을 줄이는 처리까지 가정으로 남긴 것 해석 실패 2회, 인증 유효시간 10분, 이탈 후 재접속 30분, 상담원 무응답 60초 모두 정책 데이터로 분리해서 바꿀 수 있게 한다 다음에 정할 것 가상 은행의 카드 승인 내역에 어떤 상태를 둘지 (승인, 매입, 취소) 응답을 받지 못한 결제 승인을 실제 결제 시스템에서는 어떻게 정리하는지 (금테크에서 추가 조사) 상담 이벤트와 이관 패키지의 데이터 구조 9. 다음 글 다음 글에서는 가상 은행을 설계한다. 상담원이 보게 될 근거 데이터인 고객, 계좌, 원장, 카드, 승인 내역을 어떻게 저장할지 정한다. 이번 글에서 정한 승인 건별 상태와 시각이 그 출발점이 된다. 참고 토스페이먼츠 개발자센터 — 카드 결제 총정리 토스페이먼츠 블로그 — 신용카드 승인과 매입, 어떤 개념인가요? 카카오페이 기술블로그 — MSA 환경에서 네트워크 예외를 잘 다루는 방법 이데일리 — KT, 우리은행 AICC 에이전틱 전환
솔직히 말하면, 저도 얼마 전까지는 "우리 회사는 괜찮다"는 막연한 믿음이 있었습니다. 보안 솔루션도 갖춰져 있고, 담당 팀도 있고, 나름의 정책도 있으니까요. 그런데 올해 하반기 들어 들려오는 소식들을 보면서 그 믿음이 흔들리기 시작했습니다. 침해를 당한 기업들 중 절반이 "우리가 가진 보안 도구가 아무것도 탐지하지 못했다"고 했다는 조사 결과를 접했을 때였습니다. 그 비율이 10~20%도 아니고, 절반이라는 게 충격이었습니다. 이 글은 그 충격에서 시작된 공부와 고민의 결과물입니다. 2026년을 앞두고 하이브리드 클라우드 보안 환경이 어떻게 바뀌고 있는지, 그리고 실무자로서 무엇을 준비해야 할지 제가 이해한 방식대로 풀어보려 합니다. 방어선이 무너지고 있다는 증거들 숫자부터 보겠습니다. 2025년에 진행된 하이브리드 클라우드 보안 설문조사 결과는 꽤 불편합니다. 조사 대상 기업의 55%가 최근 1년 안에 보안 침해를 경험했고, 이 비율은 전년 대비 17% 증가했습니다. 그리고 앞서 언급한 것처럼, 침해를 당한 기업 중 절반은 기존 도구로 탐지조차 하지 못했습니다. 왜 이런 일이 벌어질까요? 저는 이게 AI 때문이라고 생각합니다. 공격자 쪽에서 AI를 먼저, 그리고 더 공격적으로 쓰고 있기 때문입니다. 현재 사이버 침해의 83%, 피싱 공격의 86%가 AI와 연결되어 있다는 분석이 나옵니다. 예전에는 어설픈 맞춤법 오류나 어색한 문체로 피싱 메일을 걸러낼 수 있었지만, 이제는 그게 안 됩니다. AI가 완벽한 한국어로, 내부 직원 말투까지 흉내 내며 이메일을 쓰는 시대입니다. 설문에 응한 조직의 58%는 AI 기반 랜섬웨어 같은 새로운 공격이 실제로 증가하고 있다고 답했고, 절반에 가까운 기업은 자신들이 직접 학습시킨 LLM이 공격자의 타겟이 되었다고 했습니다. 더 이상 "우리는 공격받을 만큼 중요한 기업이 아니다"라는 말이 통하지 않는 시대입니다. 인프라 구성을 보면 상황은 더 복잡합니다. 전 세계 기업의 82%가 하이브리드 인프라를 유지하고, 63%는 멀티 클라우드를 씁니다. 그런데 동시에 70%는 하이브리드 환경 중 가장 위험한 곳으로 퍼블릭 클라우드를 꼽습니다. 퍼블릭 클라우드 내부에서 일어나는 측면 이동(east-west 트래픽)을 절반 가까운 기업이 제대로 보지 못하고 있다는 고백도 있습니다. 보안 리더와 IT 책임자의 91%가 매일 어떤 식으로든 타협을 한다고 답한 것도 이해가 됩니다. 민첩성이냐, 가시성이냐를 놓고 매번 선택해야 하는 구조 자체가 문제인 거죠. 가트너가 말하는 2026년: 세 가지 키워드 가트너가 올해 CISO들에게 제시한 핵심 테마는 세 가지입니다. 새로운 영역 보호하기, 거버넌스 혁신하기, AI 도입 일상화하기. 처음 봤을 때는 "또 거창한 말이네" 싶었는데, 들여다볼수록 실제로 해결해야 할 문제들이 그 안에 담겨 있었습니다. 가트너가 가장 크게 우려하는 것은 지정학적 불안정성, 규제 변동성, 인프라 탈중앙화, AI 확산 속도입니다. 이 네 가지가 동시에 진행되면서 기업 보안 담당자들이 감당해야 할 범위가 폭발적으로 넓어지고 있습니다. 특히 에이전틱 AI(Agentic AI)의 확산이 눈에 띕니다. 챗봇 수준이 아니라, 스스로 목표를 세우고 다른 시스템과 상호작용하는 자율형 AI 에이전트를 말합니다. 개발팀이나 현업에서 생산성 향상을 위해 앞다퉈 도입하고 있는데, 그게 새로운 공격 표면을 만들어냅니다. 가트너가 "에이전틱 AI는 사이버보안 감독을 강하게 요구한다"고 한 것은 단순한 경고가 아니라, 지금 당장 준비해야 한다는 신호입니다. 포스트 양자 암호화 이야기도 나옵니다. 양자 컴퓨팅이 현실화되면, 지금 암호화된 데이터를 미래에 해독하려는 "수확 먼저, 해독은 나중에(Harvest Now, Decrypt Later)" 공격이 문제가 됩니다. 먼 미래 얘기 같지만, 가트너는 이미 지금 데이터 전송 계층의 암호화 체계를 점검해야 한다고 합니다. 그리고 생성형 AI가 기존 보안 교육을 무력화하고 있다는 점. 저도 조직에서 "의심스러운 이메일 주의하세요" 교육을 여러 번 봤는데, 이제 그게 얼마나 유효할지 모르겠습니다. 완벽한 현지어로, 사내 문체까지 흉내 낸 이메일 앞에서 직원이 의심할 수 있을까요? 가트너는 생성형 AI 도입이 가속화될수록 보안 인식 교육의 효과는 계속 떨어질 것이라고 단언합니다. 결국 시스템이 사람의 판단에 의존하지 않고 자체적으로 차단하는 구조로 가야 합니다. 다중 에이전트 시스템, 효율의 이면에 숨겨진 위협 다중 에이전트 시스템(MAS)은 이번 트렌드에서 제가 가장 흥미롭게 봤던 부분입니다. 여러 특화된 AI 에이전트들이 서로 소통하고 협력하면서 복잡한 작업을 처리하는 구조인데, 효율성은 분명히 대단합니다. 그런데 보안 입장에서는 상당히 골치 아픈 문제를 만들어냅니다. 에이전트들이 어떻게 소통하는지 구체적인 예로 이해하면 쉽습니다. 사용자가 "근처 초밥집 찾아줘"라고 하면 오케스트레이터가 내비게이션 에이전트로 연결합니다. 그런데 바로 이어서 "뉴욕 센트럴 파크 넓이가 얼마야?"라고 물으면 오케스트레이터가 맥락을 오해해서 또 내비게이션 에이전트에게 보낼 수 있습니다. 이때 내비게이션 에이전트가 스스로 "이건 내 영역이 아니다"라고 판단해서 일반 지식 에이전트로 넘기는 게 피어 투 피어(P2P) 방식입니다. 꽤 합리적으로 작동합니다. 협력 패턴은 더 흥미롭습니다. "수막현상 어떻게 대처해?"라는 질문에 차량 매뉴얼 에이전트, 운전 팁 에이전트, 일반 지식 에이전트가 동시에 작동해서 각자의 관점을 내놓고, 응답 믹서 에이전트가 이를 종합해 답변을 만들어냅니다. 단일 에이전트보다 훨씬 풍부하고 정확한 답을 줄 수 있죠. 그런데 여기서 문제가 생깁니다. 만약 어느 한 에이전트가 오염된 데이터에 노출되거나 프롬프트 인젝션 공격을 받아서 악성 코드가 담긴 답변을 만들어낸다면? 응답 믹서가 그걸 다른 정상적인 정보들과 합쳐서 반환하면, 그 악성 페이로드가 내부 시스템 전체로 퍼질 수 있습니다. 랜섬웨어가 되거나 데이터 유출로 이어질 수 있고요. 중앙 통제 없이 자율적으로 소통하는 에이전트 환경에서는, AI와 AI 사이에 오가는 모든 API 호출과 데이터 교환을 검증하고 통제하는 권한 관리 메커니즘이 반드시 필요합니다. 이게 2026년 하이브리드 클라우드 보안의 가장 중요한 전선이라고 생각합니다. 제로 트러스트: 선언에서 실행으로 제로 트러스트라는 말은 이미 꽤 오래된 개념입니다. "아무도 믿지 않고 지속적으로 검증한다"는 철학인데, 알고는 있지만 막상 실제 인프라에 어떻게 적용하는지 막막한 경우가 많습니다. 가트너에 따르면 현재 1% 미만의 대기업만이 성숙한 제로 트러스트 프로그램을 갖추고 있고, 2026년까지 10%로 늘어날 전망입니다. 아직 갈 길이 멉니다. 그 철학을 실제로 구현하는 핵심 기술 중 하나가 마이크로세그멘테이션(Microsegmentation)입니다. 클라우드 내 워크로드를 잘게 나누어 각각에 엄격한 접근 통제 정책을 부여하는 기술입니다. 경계 방어가 뚫리더라도, 공격자나 악성코드가 내부를 수평적으로 이동하는 것을 막아줍니다. "전략만으로는 침해를 막을 수 없다, 마이크로세그멘테이션이 제로 트러스트에 비로소 이빨을 달아준다"는 현장 표현이 실무적으로 딱 맞는 말 같습니다. 아이덴티티 관리도 완전히 달라져야 합니다. CSA 2025년 보고서에서 조직의 59%가 가장 큰 클라우드 위협으로 "안전하지 않은 아이덴티티와 과도한 권한 부여"를 꼽았습니다. 문제는 이를 인지하면서도 대규모로 해결할 내부 워크플로우를 갖춘 조직이 많지 않다는 겁니다. MFA 도입률 같은 표면적 지표에만 매달리고, 실질적인 예방 관리는 소홀한 경우가 많습니다. 이제 IAM은 사람만 위한 것이 아닙니다. 수백만 개의 자동화된 워크로드, 시스템 프로세스, AI 에이전트 하나하나에도 적절한 아이덴티티를 부여하고 거버넌스를 만들어야 합니다. 가트너 애널리스트는 "기업의 AI 투자가 오랫동안 미뤄왔던 IAM 프로그램 재검토를 강제하고 있다"고 했는데, 공감이 됩니다. 기계 대 기계 상호작용이 폭발적으로 늘어나는 지금, 사람 기준으로 설계된 IAM은 한계가 있습니다. 데이터 주권: 퍼블릭 클라우드만 믿다가는 곤란합니다 글로벌 퍼블릭 클라우드에 핵심 데이터를 전적으로 맡기는 게 어떤 리스크를 갖는지, 각국 정부와 기업들이 하나둘 실감하고 있습니다. 그 결과로 나온 개념이 '지리적 이전(Geopatriation)'입니다. 데이터를 자국 내 인프라나 지역 기반 시스템으로 다시 가져오는 전략인데, 2030년까지 유럽과 중동 기업의 75% 이상이 소버린 클라우드 전략을 채택할 것으로 전망됩니다. 한국도 움직이고 있습니다. 7,350억 달러 규모의 소버린 AI 이니셔티브를 추진 중인데, 외산 기술 의존도를 낮추고 한국의 언어와 문화적 맥락을 이해하는 로컬 모델을 구축하는 것이 목표입니다. 이 흐름에서 범용 LLM 대신 도메인 특화 언어 모델(DSLM)을 쓰는 기업이 늘고 있습니다. 특정 산업 데이터로 파인튜닝된 소형 모델인데, 정확도가 높고 컴퓨팅 자원을 덜 씁니다. 규제 준수도 훨씬 수월하고요. 디지털 출처 증명(Digital Provenance)도 중요해졌습니다. AI가 생성한 코드나 콘텐츠가 넘쳐나는 시대에, 그게 어디서 왔고 어디를 거쳤는지 추적하지 못하면 공급망 보안이 흔들립니다. 소프트웨어 자재 명세서(SBoM)나 디지털 워터마킹으로 공급망에 스며든 악성 코드를 사전에 잡아낼 수 있습니다. 가트너는 2028년까지 조직의 50%가 제로 트러스트 데이터 거버넌스를 채택할 것으로 예측합니다. 식재료 원산지를 추적해야 식중독을 막듯, AI 코드의 출처 추적도 이제는 선택이 아닙니다. Epsolute: 데이터 접근 패턴까지 숨기는 쿼리 엔진 이 부분은 다소 기술적인 이야기인데, 공부하면서 "이런 게 있구나" 하고 놀랐던 부분이라 공유합니다. 인프라를 아무리 잘 통제해도, 공격자가 이미 시스템 내부 깊숙이 잠입해서 오랫동안 몰래 지켜보는 '지속적 공격자(Persistent Adversary)' 상황을 막기는 어렵습니다. 이들은 데이터를 직접 훔치지 않더라도, 어떤 데이터가 얼마나 자주 조회되는지 패턴만 봐도 중요 정보를 유추할 수 있습니다. 이를 막기 위한 게 Epsolute 아키텍처입니다. 차분 프라이버시(Differential Privacy)와 오블리비어스 램(ORAM)을 결합한 쿼리 엔진인데, 데이터 위치를 계속 섞어서 어떤 데이터에 접근했는지 알 수 없게 만들고, 결과값에 정교한 노이즈를 추가해 개별 데이터의 프라이버시를 수학적으로 보장합니다. 성능 트레이드오프가 있습니다. 100만 레코드 기준으로 840ms의 응답 시간인데, 일반 RDBMS 대비 4~8배 느립니다. 하지만 패턴을 숨기기 위해 모든 데이터를 전체 탐색하는 방식보다는 18배 빠릅니다. 데이터 규모가 커질수록 처리 시간이 O(log N)으로 효율화되기 때문에, 데이터가 많을수록 일반 탐색 방식 대비 이점이 커집니다. 이게 앞으로 컨피덴셜 컴퓨팅(Confidential Computing)과 결합되면 더 강력해집니다. 하드웨어 기반 신뢰 실행 환경(TEE, Intel SGX 같은 것) 안에서 연산을 수행해, '사용 중인 데이터(Data in Use)'까지 보호하는 구조입니다. 가시성 없이는 아무것도 안 됩니다 보안 리더의 88%가 하이브리드 클라우드 환경 통제를 위해 딥 옵저버빌리티(Deep Observability), 즉 심층 가시성이 필수라고 답했습니다. 80%는 AI 워크로드 방어에 네트워크 파생 원격 측정 데이터가 중요하다고 했고요. 단순한 엔드포인트 로그로는 한계가 있다는 공감대가 형성된 겁니다. 데이터 아키텍처 차원에서도 변화가 일어나고 있습니다. 데이터 레이크하우스는 이미지나 영상 같은 비정형 원천 데이터를 ETL 과정 없이 바로 저장하고 AI 모델을 학습시킬 수 있어서, 실시간 위협 탐지에 유리합니다. 데이터 패브릭은 AI와 메타데이터를 활용해 물리적으로 흩어진 이기종 데이터 소스를 가상으로 통합합니다. 가트너는 2030년까지 새로운 SIEM 구매의 90%가 연합 데이터(Federated Data) 아키텍처를 강제할 것이라고 예측합니다. 폭증하는 로그를 하나의 중앙 저장소에 몰아넣는 건 비용적으로도 현실적이지 않습니다. 데이터를 분산 저장하되, 조사 시에는 단일 화면에서 실시간으로 쿼리할 수 있는 구조가 미래 방향입니다. 이 모든 것이 보안 영역에서는 CNAPP(클라우드 네이티브 애플리케이션 보호 플랫폼)으로 구체화되고 있습니다. SIEM, 엔드포인트 보안, 딥 옵저버빌리티를 하나의 스택으로 통합해서, 위협 헌팅과 실시간 상관관계 분석을 한 곳에서 할 수 있게 됩니다. 파편화된 도구들이 만들어내는 사각지대를 없애는 게 핵심입니다. 결국은 회복 탄력성입니다 글을 마무리하면서 한 가지를 분명히 하고 싶습니다. 100% 예방은 불가능합니다. 이 전제를 받아들이지 않으면 아무리 좋은 도구를 써도 계속 같은 실패를 반복하게 됩니다. 가트너 서밋에서 전문가들이 강조한 것처럼, CISO들은 성공 기준을 '예방'에서 '회복 탄력성(Resilience)'으로 바꿔야 합니다. 뚫리더라도 빠르게 감지하고, 피해를 최소화하고, 정상으로 돌아오는 능력이 진짜 보안 경쟁력입니다. 구체적으로 지금 당장 할 수 있는 것들을 정리해보면: MFA 도입률 같은 표면 지표에서 벗어나서, 실질적인 위험 평가와 보안 도구 통합 전략을 세우는 것부터 시작해야 합니다. 통합 전략을 실제로 추진 중인 조직이 13%밖에 안 된다는 통계가 의미심장합니다. 그 다음은 마이크로세그멘테이션을 집행 계층으로 배포해서 제로 트러스트를 실제 통제력으로 만드는 것. IAM은 AI 에이전트까지 포함해 전면 현대화해야 합니다. 데이터 보호 측면에서는 컨피덴셜 컴퓨팅, 차분 프라이버시가 적용된 차세대 아키텍처에 선제 투자가 필요하고, 궁극적으로는 딥 옵저버빌리티와 결합된 통합 플랫폼(CNAPP)으로 인프라 전반의 가시성을 확보해야 합니다. AI가 공격자의 손에서 무기화되는 속도는 이미 우리가 방어를 구축하는 속도를 앞질렀습니다. 그 격차를 좁히려면, 방어 쪽에서도 AI를 동일한 규모로 활용하고, 끊임없이 개선하는 순환 구조를 만드는 것 외에는 답이 없습니다. 여러분 조직에서 가장 먼저 손을 대야 할 곳은 어디라고 생각하시나요? 현장마다 다를 수 있고, 제가 못 본 시각도 있을 것 같습니다. 이 글이 대화의 출발점이 된다면 충분합니다. 참고: 본 글은 Gigamon 하이브리드 클라우드 보안 설문조사(2025), Gartner 사이버보안 트렌드 보고서(2026), CSA 클라우드 보안 보고서(2025), Gartner 전략 기술 트렌드(2026) 등의 자료를 기반으로 작성했습니다.
서버나 스위치 사이를 링크 하나로만 연결하면 그 링크가 끊기는 순간 통신도 끊기고, 대역폭도 링크 하나만큼밖에 못 씁니다. 이럴 때 쓰는 게 LAG(Link Aggregation Group)입니다. 여러 개의 물리 포트를 하나의 논리 포트로 묶어서 쓰는 기술이에요. LACP는 이 LAG를 동적으로 관리해주는 프로토콜입니다. 회선을 다중화하면 두 가지 효과가 있습니다. 링크 하나에 Fail이 나도 나머지 링크로 서비스를 계속할 수 있습니다. Load-Balance로 여러 링크를 함께 쓸 수 있습니다. 설정 EOS에서는 멤버 인터페이스에 channel-group 을 설정합니다. interface Ethernet1 channel-group 1 mode active interface Ethernet2 channel-group 1 mode active mode는 세 가지입니다. active : LACPDU를 먼저 보내면서 협상을 시작합니다. passive : 상대가 보낸 LACPDU에 응답만 합니다. on : LACP 없이 고정으로 묶습니다(static). active끼리, 또는 active와 passive는 묶이지만 passive끼리는 서로 기다리기만 해서 묶이지 않습니다. 가능하면 양쪽 모두 active로 두는 게 좋아요. 실습: Eth1을 shutdown / no shutdown 해보기 Eth1, Eth2로 묶은 Port-channel에서 Eth1을 shutdown했다가 no shutdown하고, 로그와 Wireshark를 확인했습니다. LACPDU를 주고받으며 재협상하는 과정과, Eth1이 LAG 멤버에서 빠졌다가 다시 추가되는 것을 볼 수 있어요. localhost(config-if-Et1)#shutdown Aug 6 00:13:02 localhost Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1, changed state to down Aug 6 00:13:02 localhost Lag: %LAG-5-MEMBER_REMOVED: Interface Ethernet1 has left Port-Channel1 localhost(config-if-Et1)#no shutdown Aug 6 00:14:10 localhost Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1, changed state to up Aug 6 00:14:10 localhost Lag: %LAG-5-MEMBER_ADDED: Interface Ethernet1 has joined Port-Channel1 shutdown 직후 MEMBER_REMOVED 로 Eth1이 Port-Channel1에서 빠지고, no shutdown 후에는 MEMBER_ADDED 로 다시 합류합니다. 위 슬라이드 아래쪽의 Wireshark 캡처를 보면, Slow-Protocols로 분류된 LACP 프레임이 계속 오갑니다. LACPDU에는 보내는 쪽(Actor)과 상대 쪽(Partner)의 System ID(MAC), Key(K), 상태 플래그가 들어 있어요. 시간 순서로 보면 플래그 끝부분이 SG*A → CSG*A → DCSG*A 로 채워집니다. 동기화(S) 다음에 수신(C, Collecting)이 열리고 마지막으로 송신(D, Distributing)이 열리면서 포트가 번들에 합류하는 과정이에요. 중간의 17번 프레임은 STP(MST) BPDU입니다. 앞 글에서 본 BPDU가 같은 링크에서 함께 오가는 것도 보이네요. 알아두면 좋은 점 링크를 묶는다고 한 세션의 속도가 빨라지지는 않습니다. 트래픽은 헤더 값(MAC, IP, 포트 등)을 해시해서 flow 단위로 링크에 나뉘어서, 같은 flow는 한 링크만 탑니다. 세션이 여러 개일 때 분산 효과가 커요. 확인 명령어 는 show port-channel summary , show lacp neighbor 입니다. 정상적으로 묶인 포트는 상태 표기에 ALGs+CD (Active, Long timeout, Aggregable, InSync, Collecting, Distributing)가 켜져 있습니다. 정리 LAG는 여러 물리 포트를 하나의 논리 포트로 묶어 이중화와 부하 분산을 얻는 기술이고, LACP는 LACPDU로 이를 동적으로 협상하고 관리합니다. 다만 일반적인 LAG는 한 장비 안의 포트끼리만 묶을 수 있어서, 장비 자체가 죽으면 소용이 없어요. 이걸 서로 다른 두 장비로 확장한 게 MLAG입니다.