Blog

왜 지금 “AI-Ready 데이터 파이프라인"인가 최근 커뮤니티 밋업에서 발표된 아키텍처는 운영 데이터베이스(PostgreSQL)에서 발생하는 변경 사항을 실시간으로 캡처해 Apache Iceberg 기반 lakehouse로 옮기고, 그 위에서 자연어로 질의하는 AI 에이전트를 붙이는 구조였다. 이는 단발성 실험이 아니라 업계 전반의 흐름과 일치한다. Linux Foundation의 2025 CNCF Annual Cloud Native Survey에 따르면 컨테이너 사용자의 82%가 Kubernetes를 프로덕션에서 운영 중이며, AI 도입 기업의 66%가 추론 워크로드 확장에 Kubernetes를 사용한다. CNCF는 이를 두고 “모든 AI 플랫폼이 Kubernetes로 수렴하고 있다”고 진단한다. 즉 발표자가 구축한 파이프라인은 개별 사례가 아니라 업계 표준 궤적 위에 있다. ...

왜 스트리밍 플랫폼은 Kubernetes로 향하는가 데이터 플랫폼 팀들은 이제 Flink 잡을 전용 클러스터가 아니라 Kubernetes 위에서 운영하는 방향으로 이동하고 있다. 조직 안에 이미 표준 오케스트레이션 계층이 존재하는데, 팀마다 별도 인프라를 두는 대신 배치·스트리밍 워크로드를 하나의 플랫폼에서 함께 관리하려는 요구가 커졌기 때문이다. Apache Flink 공식 문서는 Flink Kubernetes Operator가 “Kubernetes API를 커스텀 리소스로 확장해 Flink 애플리케이션의 생명주기(배포, 무중단 업그레이드, 오토스케일링)를 관리한다"고 설명한다(Operator Overview). CNCF도 오퍼레이터 패턴 자체를 “커스텀 리소스를 도메인 지식을 가진 컨트롤러가 지속적으로 조정(reconcile)하는 확장 모델"로 정의하며, 선언적 상태와 실제 상태를 계속 수렴시키는 피드백 루프가 핵심이라고 설명한다(Kubernetes Operators 101). 스트리밍 잡을 하나의 CR로 선언하고 컨트롤 루프가 알아서 원하는 상태로 맞춰준다는 것이, 이 흐름의 핵심 아이디어다. ...

AI 에이전트, “말은 잘하는데 왜 기억을 못할까” 최근 밋업에서 다뤄진 핵심 주제는 AI 에이전트가 프로덕션 단계로 넘어가면서 부딪히는 실질적 병목, 즉 state와 memory 설계 문제였다. LangChain의 State of Agent Engineering 리포트에 따르면 이미 조직의 상당수가 에이전트를 실제 운영 환경에 투입했지만, 응답 품질(정확성·일관성·환각)이 가장 큰 배포 장벽으로 꼽힌다. 발표자가 강조했듯 LLM 자체는 무상태(stateless)다. 매 요청마다 새로 답하기 때문에, “기억"은 애플리케이션이 별도로 설계해야 하는 인프라 문제가 된다. State와 Memory는 다른 문제다 발표의 첫 번째 원칙은 state와 memory를 혼동하지 말라는 것이다. LangGraph 공식 문서는 이를 명확히 구분한다. State는 그래프 실행의 매 super-step마다 저장되는 체크포인트로, 에이전트가 중단된 지점에서 재개하거나 human-in-the-loop, time-travel 디버깅을 가능케 하는 “실행 이력"이다. 반면 memory는 세션을 넘어 남아야 하는 지식이다. MongoDB는 이를 단기·장기 메모리 가이드에서 working memory(현재 처리 중인 맥락), episodic memory(과거 사건), semantic memory(일반 지식), procedural memory(반복 작업 절차)로 세분화한다. MongoDB는 실제로 체크포인터로 단기 상태를, Store로 장기 기억을 분리 저장하는 통합을 LangGraph용으로 제공한다. ...

PoC 지옥에서 벗어나기: 왜 지금 ‘프로덕션화’가 화두인가 Gartner는 2027년까지 에이전틱 AI 프로젝트의 40% 이상이 취소될 것이라 전망했다(Forbes). 실제로 2025년 생성형 AI 프로젝트의 절반이 PoC 이후 폐기됐고, 에이전트 파일럿의 88%가 프로덕션 전환에 실패했다는 데이터도 있다(THE DAILY BRIEF). 원인은 기술 자체보다 평가 체계 부재와 신뢰성 설계 부족이다. 데모는 ‘행복 경로 하나’만 통과하면 되지만, 프로덕션은 부하·멀티테넌시·장애 복구까지 감당해야 하는 전혀 다른 문제다. 오케스트레이션: 결정론과 에이전트의 하이브리드 AWS Prescriptive Guidance는 흐름이 고정적이고 반복 가능하면 AWS Step Functions로, 판단이 필요한 개방형 단계는 에이전트로 처리하라고 권한다. 성숙한 패턴은 결정론적 상태 머신이 판단이 필요한 한 단계만 에이전트를 호출하는 하이브리드다. 이벤트가 몰리는 구간에서는 Amazon EventBridge가 라우팅을, Amazon SQS가 버퍼 역할을 하며 AWS Lambda가 큐 적재량에 따라 자동 확장한다(AWS Prescriptive Guidance). 처리 실패는 SQS의 Dead Letter Queue로 격리해 손실 없이 재처리하며, 함수는 반드시 멱등성을 갖추도록 설계해야 한다(AWS Lambda 문서). ...

왜 지금 ‘에이전틱 AI’인가 2025년까지만 해도 기업 애플리케이션에 task-specific AI agent가 탑재된 비율은 5% 미만이었지만, Gartner는 2026년 말까지 이 수치가 40%까지 급증할 것이라고 전망했다. 단순히 하나의 LLM이 질문에 답하는 챗봇 시대를 지나, 여러 개의 전문화된 에이전트가 도구를 호출하고 서로 협업하며 실제 업무를 처리하는 ‘에이전틱(agentic)’ 시스템으로 무게중심이 옮겨가고 있다. 이번 글에서는 AWS 생태계를 중심으로 이 흐름을 구성하는 핵심 기술 — Amazon Bedrock의 멀티에이전트 오케스트레이션, Lambda 기반 서버리스 실행 계층, AgentCore Memory, 그리고 도구 연동 표준인 Model Context Protocol(MCP) — 을 짚어본다. ...

AI 지원자 폭증과 이력서의 신뢰 위기 최근 채용 시장을 취재한 자료들을 보면 공통된 신호가 하나 있다. 지원 절차 자체가 AI로 인해 완전히 달라졌다는 것이다. Ashby의 2026 Talent Trends Report에 인용된 분석에 따르면 1억 900만 건 이상의 지원서를 분석한 결과 채용 1건당 지원자 수가 2021~2024년 사이 3배로 늘었고, 2025년 내내 300건을 웃돌았다. ChatGPT 덕분에 예전에는 지원서 1개를 쓰던 시간에 수십 개를 낼 수 있게 되면서 채용담당자가 받는 지원서의 약 40%가 AI 생성 흔적을 보인다고 한다. 다만 핵심은 ‘AI를 썼는지’가 아니라 ‘내용이 일반적인지’다. 개인화되지 않은 AI 생성 이력서는 62%의 채용 담당자에 의해 곧바로 탈락한다는 통계도 함께 나온다. 이 흐름은 이번 밋업에서 발표자가 강조한 메시지, 즉 이력서는 스토리가 아니라 ‘증거’를 보여줘야 한다는 조언과 정확히 맞닿아 있다. ...

플랫폼 엔지니어링, 이제는 선택이 아니다 플랫폼 엔지니어링은 이미 산업 표준이 되었다. Broadcom(VMware)의 Pankaj Gupta와 Platform Engineering의 Sam Barlien이 공동 집필한 Platform Engineering 2.0 백서에 따르면 대부분의 조직이 이미 내부 개발 플랫폼(IDP)을 도입했고, 다수는 전담 플랫폼 팀까지 운영하고 있다. 문제는 ‘도입 여부’가 아니라 ‘무엇을 위한 플랫폼인가’로 바뀌었다는 점이다. 2022~2023년의 플랫폼 엔지니어링 1.0은 애플리케이션 개발자의 인지 부하(cognitive load)를 줄이고 golden path를 표준화하는 데 초점을 맞췄지만, platformengineering.org의 소개 글이 지적하듯 이 모델은 AI 워크로드, 자율 에이전트, 다중 페르소나 조직을 전혀 상정하지 않은 채 설계됐다. ...

도입은 넘쳤지만 성과는 아직이다 2025년 이후 기업의 생성형 AI 도입률은 사실상 보편적인 수준에 도달했다. McKinsey의 State of AI 2025 보고서에 따르면 조직의 88%가 최소 한 개 기능에서 AI를 사용 중이며, 생성형 AI 사용률은 2023년 33%에서 2025년 79%로 급증했다. 그런데 같은 보고서는 상반된 사실도 함께 전한다. 조직의 3분의 2가 여전히 실험·파일럿 단계에 머물러 있고, 전사적으로 생성형 AI를 스케일업한 기업은 전체의 약 7%에 불과하다. 5% 이상의 EBIT 개선을 보고한 조직도 5.5%에 그친다. 이 간극은 MIT NANDA 이니셔티브가 2025년 발표한 연구에서 더 뚜렷하게 드러난다. 임원 52명 인터뷰와 300개 이상의 실제 배포 사례를 분석한 결과, 생성형 AI 파일럿의 95%가 측정 가능한 손익 효과를 만들어내지 못했다. 원인은 모델 성능이 아니라 조직의 ‘학습 격차(learning gap)’, 즉 AI를 기존 업무 프로세스와 조직 구조에 통합하지 못하는 데 있었다. 흥미롭게도 외부 벤더가 구축한 도구는 사내 자체 개발보다 성공률이 두 배 높았는데, 이는 기술 자체보다 실행과 운영 설계의 중요성을 시사한다. ...

왜 지금, ‘로그인’이 아니라 ‘행동’을 봐야 하는가 최근 몇 년 사이 AI는 질문에 답하는 도구에서 API를 호출하고 실제로 자금을 이동시키는 자율 에이전트로 진화했다. Gartner는 2026년까지 전체 엔터프라이즈 애플리케이션의 40%가 특정 업무를 수행하는 AI 에이전트를 탑재할 것으로 전망했는데, 이는 2025년 5% 미만에서 급격히 늘어난 수치다(Gartner Newsroom). 문제는 속도다. AI가 가세한 비즈니스 이메일 사기(BEC)는 자금 이동을 수 초 만에 승인해버리는 구조적 취약점을 파고들며 확산하고 있고, 공격자가 노리는 질문도 더 이상 ‘이 로그인이 정당한가’가 아니라 ‘이 행동이 허용되어야 하는가’로 바뀌었다(CIO). 전통 보안 도구 대부분은 여전히 전자만 검사하도록 설계돼 있다. ...

왜 지금 ‘현대화’가 FinOps의 화두인가 클라우드 지출과 AI 인프라 비용이 동시에 급증하면서, FinOps Foundation은 2026년 프레임워크에 ‘AI 기술 카테고리’와 ‘Executive Strategy Alignment’를 새로 추가했다. FinOps.org의 2026 프레임워크 개편 안내에 따르면, FinOps는 이제 단순 비용 최적화 기능을 넘어 경영진과 투자 결정을 연결하는 전략 파트너로 확장되고 있다. 그 안에서도 VM(가상머신) 현대화, 즉 오래된 인스턴스 패밀리를 최신 세대로 교체하는 작업은 여전히 가장 손쉽게 실현 가능한 절감 기회로 꼽힌다. 가격이 아니라 ‘단위 작업당 비용’으로 봐야 한다 신형 인스턴스는 시간당 요금이 더 비싸 보이는 경우가 많다. 하지만 SPEC CPU2017 같은 표준 벤치마크로 정규화하면 순위가 뒤집힌다. Google Cloud 팀이 실제로 SPEC CPU2017을 GCP 머신 패밀리 전반에 적용해 분석한 시리즈 벤치마크는, 가격/성능 비율이 세대와 아키텍처에 따라 크게 달라짐을 보여준다. 즉 ‘시간당 얼마’가 아니라 ‘요청당·작업 단위당 얼마’로 봐야 진짜 절감 폭이 드러난다. ...