Developer Summit 2026 Summer(데브사미 2026 여름)은 Shoei-sha(翔泳社)가 주최하는 개발자 대상 컨퍼런스입니다. 2026년 7월 16일 개최된 1일차에 참가하여 6개의 세션을 청강했습니다. 올해의 분위기를 한마디로 요약하자면, "AI로 개발이 빨라졌다. 그 너머에서 인간과 프로세스를 어떻게 재구성할 것인가"에 각 기업의 관심이 집중되어 있었다는 인상입니다.

이 기사에서는 청강한 6개 세션의 내용을 강연의 흐름에 따라 가능한 한 상세하게 정리합니다. 다루는 테마는 AI 주도 개발(AI-driven development)의 부작용, LLM(Large Language Model) 임베딩 프랙티스, AI가 사용하는 데이터 기반, toB 프로덕트의 이중 루프 개발, 로우코드(Low-code) × AI, 그리고 엔지니어링 조직론입니다. 분야는 제각각이지만, 마치고 보니 여러 발표자가 독립적으로 동일한 결론에 도달해 있었는데, 그 점이 이날의 가장 큰 관전 포인트였습니다. 긴 글이지만, 마지막의 "공통 테마"까지 읽어주신다면 2026년 여름 시점의 AI × 개발의 현주소를 입체적으로 파악하실 수 있을 것입니다.

💡 본 기사는 필자 개인의 청강 메모에 기반한 리포트입니다. 강연의 모든 내용을 망라하거나 정확하게 재현하는 것이 아니며, 강연 중의 수치는 슬라이드 메모를 바탕으로 하였기에 독자적인 검증은 하지 않았습니다. 모든 책임은 필자에게 있습니다.

청강한 세션의 타임테이블입니다.

먼저 스포일러를 좀 하자면, 이 6개의 세션은 "① 생성은 확률적이어도 괜찮다, 수용은 결정론적으로", "② 인간에게 판단을 남긴다", "③ 컨텍스트(Context)가 성패를 가른다"라는 3가지 테마로 깔끔하게 연결되어 있었습니다. 각각의 세션을 살펴보겠습니다.

(다테 타쿠로 씨 / NEC Solution Innovators)

AI가 설계·구현·검증을 담당하는 개발 파이프라인을 실제 프로젝트에서 구축·운용한 경험을 바탕으로, "편리함의 이면에서 인간이 생각하지 않게 되는 구조"를 마주한 세션입니다. 다테 씨는 2004년 입사 후 애플리케이션 개발·서비스 기획을 거쳐, 현재는 AI 네이티브한 개발 프로세스의 검증 및 적용 추진을 담당하고 있습니다. 도입부는 "AI로 업무가 편해졌다고 느끼는 분", "AI에 의해 놓아버린 일(작업)이 있지 않습니까?"라는 회장(청중)을 향한 질문으로 시작되었습니다. AI의 진화가 가속화되는 가운데 느끼는 막연한 불안에 대해, 자신의 경험으로부터 "깨달음과 해결의 계기"를 이야기하는 구성이었습니다.

먼저 전제가 되는 파이프라인입니다. RFP(제안요청서)·요구사항 목록을 입력하면, SE(System Engineer)가 GitHub에 Pull Request를 보낼 때, GitHub Actions와 Claude Code가 Skills 단위로 "요구사항 분석 → 설계 → 구현 → 단체 테스트 → E2E 테스트"를 자동 실행하며, 요구사항 정의서·설계서·소스 코드·테스트 결과를 출력하여 배포까지 진행합니다.

구현 플로우의 내용도 구체적이었습니다. 테스트 주도(RED→GREEN) 방식으로 작성하고, lint·test·build의 전 과정 PASS를 확인하며, 코드 리뷰를 거쳐 commit→push까지 Claude Code의 스킬 그룹으로 구성되어 있습니다. CI(Continuous Integration)에서는 Lint·빌드·테스트에 더해 취약점 감사까지 실시하며, E2E 테스트는 Playwright를 사용합니다. 개발 품질과 속도의 동시 향상을 실현하여 일상적인 개발은 확실히 돌아가고 있었다고 합니다. 그런데 그 편리함의 이면에서 현장으로부터 3가지 위화감이 나타나기 시작합니다.

• 고객으로부터의 "무엇부터 확인해야 하죠? 읽는 법을 알려주세요" ——
  전달의 위화감
• 부하 직원으로부터의 "AI로부터 안 된다는 답변이 왔습니다" ——
  판단의 위화감
• 동료로부터의 "이 '확인만 하는' 작업, 누가 즐겁겠어?" ——
  보람의 위화감

모두 처음에는 작은 위화감이었으며, 이 3가지에 하나씩 마주하기로 했다는 진행 방식입니다.

AI 주도 개발에서는 "고객과의 대화 감소"와 "결과물의 격차"가 동시에 발생합니다. 기존에는 요구사항 정의부터 제조·테스트까지 각 공정에서의 대화를 통한 공통 창조(Co-creation)가 있었고, 이를 통해 납득감·안심감, 프로세스에 대한 이해, 고객 관점의 설계서가 만들어졌습니다. 일괄 자동화에서는 AI가 출력하는 정보(클래스명·메서드명·소스 근거·정합성)와 고객이 보고 싶어 하는 정보(업무 요약·업무 플로우·화면 이미지)가 어긋납니다.

기술적으로는 완벽합니다. 클래스명도 메서드명도 소스 근거도 갖추어 자신 있게 전달한 사양서에 대해, 고객의 반응은 "어디를 보면 좋을지 모르겠다"였습니다. 전달되지 않는 이유는 3가지로 분류되었습니다.

즉, 정확성의 문제가 아니라 '읽는 사람'이 달랐던 것이다. 같은 사양서라도 SE는 구현의 정확성을 보고, 고객은 업무가 올바르게 반영되었는지를 본다. 독자가 바뀌면 필요한 정보도 달라진다 —— "정확함이 전달됨을 보장하지는 않는다"라는 말이 가슴에 와닿았다. 대책은 심플하다. 사람이 "누구를 향해 쓸 것인가"를 결정하고, AI가 독자별로 나누어 쓰는 것. 사람이라면 너무 번거로워 할 수 없는 작업도 AI라면 한 번에 끝낼 수 있다.

AI가 "×(불가능)"라고 답하면, 거기서 손이 멈추고 그 이상 생각하지 않게 된다 ——라는 자기 관찰이 두 번째다. 예로 든 것은 소스 코드에서의 리버스(Reverse)인데, AI가 "무리"라고 판정하는 순간 탐색이 끝나버려, 궁리할 여지조차 사라지고 있었다. "깊게 생각하는" 습관이 빠져 있었던 것이다.

그래서 AI의 "×"를 기점으로 변화를 만드는 3가지 관점이 제시되었다.

전제를 의심하기: "정말로 무리인가?"라며 제약, 전제, 프롬프트(Prompt)를 바꿔본다 -
다른 관점을 찾기: 한 번의 답변에 만족하지 않고, 다른 각도에서 다시 질문한다 -
탐색과 판단은 사람이 담당하기: 최종 결정의 핸들을 AI에게 완전히 넘겨주지 않는다

실제로 "할 수 없다"는 것의 상당수는 사람의 질문과 정보로 돌파할 수 있었다고 한다. "소스만으로는 업무 분석 및 사용자 설계가 어렵다" $\rightarrow$ 업무 및 사용자 관점의 정보를 사람이 보완하여 다시 질문한다. "Skills에서도 기대하는 아웃풋(Output)이 나오지 않는다" $\rightarrow$ 무엇이 부족한지를 사람이 질문을 세워 보완한다. "같은 프롬프트라도 출력에 편차가 생긴다" $\rightarrow$ 개별적인 관점이나 전제를 사람이 더해 범위를 좁힌다. AI는 결과는 내놓지만 "왜・어떻게"는 보이지 않는다. 그렇기에 사람이 골(Goal)과 배경을 쥐고 다음 지시를 내린다. 결과에 대해 생각하는 것을 놓아서는 안 된다는 정리다.

역할 분담으로는 AI가 고속으로 아웃풋(설계서, 소스 코드, 테스트류)을 내고, 사람은 요건 히어링(Hearing), 업무 사양 확정(FIX), 테스트 결과 및 커버리지(Coverage) 확인 등의 리뷰와 수락 테스트를 담당하는 형태였다. 여기서 가슴을 찌른 것은 AI 주도 개발(AI-driven development) 검토회에서의 동료의 한마디였다. "AI의 아웃풋을 '확인만 하는' 작업은 누가 즐겁겠어?"

효율을 쫓다가 "생각할 여백"까지 빼앗고 있었다. 확인 작업만 남고 마음이 움직이지 않게 되었다 ——라는 반성으로부터 역할 설계의 전환이 이야기되었다. AI=작업 / 사람=확인에서, 사람에게 판단·탐색·의사결정을 남기는 설계로. 구체적으로는 "탐색하는 기쁨"을 설계하는 3가지 방침이다.

질문은 사람이 던진다: AI에게 뼈대를 만들게 하고 사람이 고치는 것을 역전시킨다. 사람이 "질문"을 세우고 AI가 뒷받침한다 -
탐색을 즐긴다: 효율 제일주의에서 탈피하여, 시행착오를 겪거나 아이디어를 다듬는 과정에 사람을 둔다. 창조성을 되찾는다 -
책임이 보람이 된다: 판단에는 책임이 따르며, 그것이 자기 효능감과 보람을 낳는다

효율을 위한 분담에서, "보람"을 위한 설계로. 판단하는 업무가 돌아오면 보람도 돌아온다는 메시지였다.

마무리에서, 3가지 위화감의 정체는 "나는 깊게 생각하는 것을 그만두지 않았는가"라는 하나의 질문으로 집약되었다. 고객에게는 전달되지 않게 되었고, 부하 직원 앞에서는 탐색하지 않게 되었으며, 동료가 보기에는 작업이 되어갔다. 세 가지는 별개의 문제가 아니라, 전부 "깊게 생각하는" 것을 그만둔 한 명의 자신이었다는 것이다. 그렇기에 전자동 흐름 속에 사람의 "게이트(Gate)"를 설계 후와 배포(Deploy) 전, 두 곳에 마련했다고 한다. 게이트의 정체는 "깊게 생각하는 장"이다.

이 그림의 포인트는 게이트가 단순한 품질 체크포인트가 아니라 "사람이 깊게 생각하기 위한 장"으로서 설계되어 있다는 점이다. AI가 담당하는 "정확성" + 사람이 담당하는 "깊게 생각하는 것" = AI 시대의 분업. 엔지니어는 코드를 쓰는 "작업자"에서, 기술과 데이터를 가치로 번역하고 의사결정하는 "아키텍트(Architect)"로. 인간만의 "깊은 검증력"과 "문제 설정력"이 요구된다는 결말로 끝을 맺었다.

기술 구현이 자동화될수록 "사람과 사람 사이에 있는 일" ——무엇을 만들 것인가에 대한 합의, 고객의 진의를 끌어내는 대화, 결과물에 고객이 납득하는 순간, 조직 간의 우선순위 조정——이 더욱 선명하게 보인다. AI에게 일을 빼앗기는 것이 아니라, 전달하고 결과를 생각하는 일은 계속 그 자리에 있었으며, 기술적인 작업에 가려져 보이지 않았을 뿐이다. 이 관점의 반전이 이번 세션의 가장 큰 수확이라고 생각한다.

(Shibui Yusuke 씨 / Snowflake)

Snowflake의 Senior AI/ML Architect / Field CTO이자 MLOps 커뮤니티를 운영하는 Shibui 씨의 세션입니다. 『머신러닝 시스템 디자인 패턴 (Machine Learning System Design Patterns)』 등의 저자이며, 신간 『LLM·AI 에이전트 시스템 베스트 프랙티스 (LLM/AI Agent System Best Practices)』 (Shoeisha 출판)를 2026년 8월 20일에 발매할 예정이라고 합니다. 핵심 메시지는 "현재의 변화에 대한 새로운 방법론 (Methodology)을 제창하는 것은 동시대인의 특권이다"였습니다. 30분 안에 엄청난 밀도가 담긴 세션이었습니다.

전반부의 주장은 방법론 = 공통 언어라는 이야기입니다. "DI 패턴으로 만들어줘"라는 한마디로 사람과 AI 모두에게 의도가 전달됩니다. 이것이 방법론의 가치입니다. LLM 시대의 SOLID 원칙을 재해석한 사례가 제시되었습니다.

문제는 새로운 기술에는 아직 이름과 공통 인식이 없다는 점입니다. 역할(Role)·Few-shot·하이브리드 검색(Hybrid Search)·Eval first……와 같이 매번 긴 문장으로 설명해야 하는 상황이 발생합니다. 더욱 심각한 것은, 코딩 에이전트 (Coding Agent) 덕분에 누구나 상당한 규모의 개발을 의뢰할 수 있게 된 결과, 공통 인식이 되는 구현 방침이나 아키텍처(Architecture)가 부재한 상태에서 멘탈 모델 (Mental Model)이 서로 다른 일관성 없는 코드가 "높은 품질로" 양산되고 있다는 점입니다. 공통 인식의 부재는 운영 부채 (Operational Debt)가 된다는 지적이었습니다.

지금 일어나고 있는 것은 사람 × 코딩 에이전트의 대량 병렬 개발입니다. 고속 개발이나 고도화된 분석이라는 즐거운 면의 이면에는 보안 홀 (Security Hole), 무제한적인 토큰 사용, 중복, 섀도 AI (Shadow AI), 저품질 코드가 발생하고 있습니다. 따라서 코딩 에이전트 시대 엔지니어의 중요한 업무 중 하나는 "누구나 신뢰할 수 있는 소프트웨어를 만드는 메커니즘을 엔지니어링하는 것"이라고 정의되었습니다.

정리하자면, 구현 = 기능 (요구사항·사양에 의해 결정) + 설계 (방법론에 의해 결정)입니다. 에이전틱 애플리케이션 (Agentic Application)에는 아직 방법론에 대한 공통 인식이 없습니다. 거기에는 "두 가지 불투명성"이 존재합니다. (1) LLM/AI 에이전트를 소프트웨어에 통합하는 방법론 그 자체, (2) 코딩 에이전트에 의해 만들어진 구체적인 구현과 설계. 기능은 Eval (평가)로 검증할 수 있어도, 비기능·설계·비용은 블랙박스 (Black Box)가 되기 쉬우며, "편리함 > 제어" 상태에서는 각자가 블랙박스를 계속 만들어내게 됩니다.

답은 "만드는 법을 만드는 것"입니다. Harness(하네스)·Eval·Loop를 설계하고, AGENT.md를 통해 코딩 에이전트가 방법론 (SOLID·TDD/CI/CD·Modular Monolith 등)을 신뢰하고 실행하게 합니다. 제어를 위해 편의성을 희생하는 것이 아니라, 편의성을 유지하면서 신뢰를 구축하는 것이 엔지니어링의 묘미라는 긍정적인 정리가 인상적이었습니다.

구체적인 설계 원칙으로서 다음 세 가지가 소개되었습니다.

확률의 봉쇄: LLM 이용은 지정된 모듈에만 허용하고, 규칙 기반 (Rule-based)으로 제약한다. 입출력은 스키마(Schema)·빌더(Builder)·게이트웨이(Gateway)로 관리한다 -
최소 에이전시 (Minimum Agency) 원칙: 과제 해결에 있어 LLM/에이전트의 역할은 최소화할수록 좋다 -
결정론 우선 (Deterministic First), LLM 롱테일 (Long-tail): 엔트리 포인트 (Entry Point)는 결정론적으로 해결하고, 남은 복잡성만을 LLM으로 처리한다

이 그림은 "최소 에이전시"의 계단입니다. 왼쪽으로 치우칠수록 좋으며, 오른쪽으로 가는 것은 필요할 때뿐입니다. 상품 추천 예시가 이해하기 쉬웠는데, 처음에는 희귀한 상품의 추천을 LLM으로 커버하고, 로그가 쌓임에 따라 규칙 기반·머신러닝으로 이행하며, 최종적으로 LLM 추천은 신규·엣지 케이스 (Edge Case)의 보조 역할로 철저히 제한했다고 합니다. 이를 "프로토타이핑의 역전"이라고 불렀습니다. LLM으로 처리한 기록을 바탕으로, 결정론적으로 풀 수 있는 영역을 나중에 넓혀가는 것입니다. LLM을 영구적인 주역이 아니라, 결정론화하기까지의 징검다리로 사용하는 발상입니다.

"각 작업이 후속 작업을 용이하게 하도록" 개발한다는 사상도 소개되었습니다. 팀 단위로 루프를 돌며 구현과 Eval을 통해 Harness (하네스)를 키워나가고, Master Harness를 팀 공통의 소프트웨어 자산으로 만드는 개념입니다.

이 루프의 목적 함수는 '신뢰 가능한 변경량'입니다. 인간의 리뷰가 가장 비용이 높고, 그다음이 LLM을 포함한 전수 테스트입니다. 릴리스의 빈도와 실패율을 최적화 대상으로 삼아, Harness (하네스)와 Eval (평가)을 루프로 개선해 나갑니다. 지표 예시로는 릴리스(빈도·리드 타임·변경 실패율), 테스트(실행 수 vs 가지치기 수·인간 리뷰 수·리뷰 지적 수), 결정론적 규칙(가역 vs 불가역 영역·의사결정 이양량·경제적 처리량) 등이 언급되었습니다. 하네스에 설계·개발 가능한 영역을 이양할수록 코딩 에이전트의 생산량이 늘어나고 처리량(Throughput)이 최대화됩니다. 즉, '편리함 > 제어'에서 '편리함 ← 제어'로의 전환입니다.

Agentic Application (에이전틱 애플리케이션)의 구성 요소를 Interface (인터페이스) / Tool·Gateway (툴·게이트웨이) / Context·Memory (컨텍스트·메모리) / Eval (평가)의 4가지로 나누고, 각 프랙티스를 '프랙티스 본체 → 코딩 에이전트가 실천하도록 만드는 방법 → 제어하는 하네스'라는 3종 세트로 정비한다는 프레임워크 아래, 수많은 구체적인 사례가 제시되었습니다. 특히 인상 깊었던 내용을 분야별로 발췌합니다.

구조화된 출력과 스키마 주도 I/O (Structured Output and Schema-driven I/O). LLM 출력을 Pydantic / JSON Schema의 타입으로 강제하고, 검증 실패 시 재생성합니다. 이것이 파이프라인·툴 연계·평가·로그 모든 것의 토대가 됩니다. 다만 스키마가 너무 복잡하면 생성 실패율이 높아지므로, 재시도와 폴백 (Fallback) 설계가 필수적입니다. 하네스 사례가 매우 실천적이었습니다. — 구조화된 출력은 확률적 세계에서 결정론으로 가는 경계이므로 Eval 필수 / Schema × Prompt × Model × Eval의 '4종 계약'으로 관리 / 스키마의 첫 번째 독자는 인간이 아닌 LLM / LLM 스키마와 도메인 모델을 분리하여 변환 계층을 가짐 / Enum·Literal로 제약 / 추출 계열 필드는 Optional + 근거를 원문에서 취득 / Reasoning (추론) 필드를 먼저, 결론은 마지막에 / 중첩(Nest)은 상한 3단계 / 에러 메시지는 What(무엇이), Why(왜), How to fix(어떻게 수정할지)를 포함.

컨텍스트와 메모리 설계 (Context and Memory Design). 문맥의 축적 → 오염·드리프트 (Drift) 감지 → 건전한 지점으로 복귀 (체크포인트 저장, 롤백, 유효한 입력만 재전송)라는 흐름을 통해, 에이전트를 장시간 안정적으로 구동하고 폭주나 붕괴로부터 회복시키는 핵심입니다. 데이터의 형태와 용도에 따른 저장·관리·검색 방법을 문서화하는 '데이터 디자인 카탈로그' (사실·설정값은 구조화 데이터, 사건은 이벤트 로그, 지식은 청크 + 하이브리드 검색, 절차는 검색과 Git)도 소개되었습니다. 하네스 사례로는 메모리 쓰기는 심사제 (Eval을 통해 승인·승격) / 관측과 추론의 분리 / Immutable (불변성, 이벤트 소싱) / 원본 데이터의 파괴적 압축 금지 (요약은 Materialized View (구체화된 뷰)로 보유) / 모든 레코드에 TTL과 감쇠율 적용 / 망각은 기능 (정기적인 GC (Garbage Collection)) 등이 있었습니다. '망각은 기능이다'라는 단정적인 표현이 좋았습니다.

툴체인과 게이트웨이 (Toolchain and Gateway). LLM은 호출할 함수의 연쇄와 순서만 지정하고, 시스템이 내부에서 일괄 실행하여 최종 결과만을 반환합니다. 이는 순차적인 툴 왕복이 중간 결과로 문맥을 오염시키고, 토큰과 레이턴시 (Latency)를 낭비하기 때문입니다. 모든 툴 호출은 게이트웨이 (MCP)를 제어점으로 삼아 권한 부여·스키마 검증·최소 권한·감사를 일원화합니다. 하네스 사례 — 플레인 분리 (중간 생성물은 LLM을 거치지 않음) / 툴 세트 × 체인 사양 × 프롬프트 × 모델 × Eval의 '5종 계약' / 플랜은 사전 컴파일을 통해 타입 검사 및 권한 정밀 조사 / 각 툴에 Read · Write-reversible (쓰기-가역) · Write-irreversible (쓰기-불가역) · External-send (외부 전송)의 부작용(Side-effect) 클래스를 필수 선언 / 읽기는 대화 허용, 쓰기는 선언적 플랜 강제 / 툴 직접 호출은 Lint로 금지 (Single Tool Gateway) / 실행 장부로 관리 기록. 부작용 클래스의 필수 선언은 당장 내일부터라도 자신의 툴 정의에 넣고 싶어질 정도였습니다.

AI 에이전트의 테스트와 평가. 품질을 감이 아닌 수치로 관리합니다. 골든 데이터셋(Golden Dataset)에 루브릭(Rubric) 및 LLM 자동 채점을 적용하여 오프라인 평가를 자동화하고, 합격/불합격 임계치를 CI의 품질 게이트(Quality Gate)에 설정합니다. 운영 환경에서는 카나리(Canary) 및 A/B 테스트로 실제 동작을 측정하고, 트레이스(Trace)를 데이터셋으로 환원하는 Eval 주도 개발(Eval-driven development)을 수행합니다. 주의점도 구체적입니다. 출력은 값이 아닌 '분포'이기 때문에 단일 테스트 케이스의 합격만으로는 품질을 보장할 수 없다는 점, LLM-as-Judge 자체의 편향(Bias)과 불안정성, 데이터셋의 노후화 및 리크(Leak), 평가 비용의 증가 등이 있습니다. 테스트 선정에는 Predictive Test Selection의 응용(변경 사항에 대해 확률적으로 실패할 가능성이 높은 테스트를 우선 실행하고, 운영 릴리스 전에는 전수 실행)이 소개되었습니다. 하네스(Harness) 예시로는, '변경 없음 ≠ 리스크 없음'(CRON으로 정기 관측하여 드리프트(Drift) 탐지) / 판정 함수의 타입 선언(결정론적, 임계값 포함 통계, LLM Judge 중 하나를 선언) / LLM Judge는 면허제로 운영하여 락(Lock)을 걸고 Judge Drift를 방지하는 것 등이 제시되었습니다.

안티 패턴은 두 가지가 소개되었습니다.

비기능적 측면의 함정은 "숙련된 반사 신경이 새로운 전제와 충돌한다"는 관점에서 두 가지가 제시되었습니다. 결정론적 편향 (Deterministic Bias) (품질·테스트 축)은 "테스트를 통과했다 = 옳다"라는 논리가 LLM에는 통하지 않는다는 이야기입니다. 출력은 분포이며, 단 한 번의 합격은 아무것도 보장하지 않습니다. 초록색 CI 신호가 잘못된 안도감을 줍니다. 처방은 예시가 아닌 분포를 검증하고, N회 샘플링과 기준을 갖춘 자동 판정을 수행하는 것입니다. 신뢰 경계의 오인 (Misunderstanding Trust Boundaries) (보안 축)은 사용자 입력은 경계하지만, LLM 출력(생성된 SQL, 코드, 툴 인자)이나 RAG의 내용은 자신의 코드처럼 신뢰해 버리는 문제입니다. 처방은 신뢰 경계를 LLM의 외부로 다시 설정하고, 비신뢰 대상으로 간주하여 검증, 샌드박스(Sandbox), 최소 권한, 인간 승인을 거치도록 하는 것입니다. 공통적인 구조로서, 새로운 패턴을 습득하는 것(덧셈)뿐만 아니라 기존의 반사 신경을 폐기하고 재교정하는 것(뺄셈)이 필요하다는 결론이 매우 공감이 갔습니다.

마지막으로 서두의 핵심 메시지로 돌아갑니다. 프랙티스(Practice) 모음집을 Harness 및 Eval로 정비하여, 코딩 에이전트가 이를 검색해 설계 지침과 선정 기준을 얻고 AGENT.md에 반영하는 "코딩 에이전트를 위한 방법론"으로 나아가는 것입니다. 신기술이 '당연함'을 파괴하고, 실패가 집중되며, 이를 국소화하여 평가하는 과정에서 방법론(Methodology)이 탄생하고, 다음 변화가 새로운 전선을 여는 것—이 사이클의 한복판에 있는 우리에게는 새로운 방법론을 제창할 특권이 있다는 마무리였습니다. 책이 나오면 읽어보려 합니다.

(마츠모토 미키 씨 / ClickHouse)

빅데이터 영역에서 15년 이상 활동하며 Elastic, Workato, ClickHouse 모두 일본 시장 런칭에 참여해 온, ClickHouse의 일본인 직원 1호라는 마츠모토 씨의 세션입니다. "사내 데이터 분석에 AI를 사용하는 케이스가 늘고 있지만, AI 답변의 질은 제공되는 데이터의 질과 양에 의해 결정된다. 데이터 기반의 역할은 '저장'에서 'AI를 똑똑하게 만드는 토대'로 진화했다"라는 도입부로 시작되었습니다.

AI는 데이터 기반에 대해 세 가지 측면에서 요구사항을 변화시킵니다.

• 분석 인터페이스의 대화화: Text-to-SQL을 통해 동적으로 쿼리가 생성되며, 액세스 패턴이 동적이고 예측 불가능해짐. 정적으로 최적화된 전용 DB로는 대응할 수 없음 -
• 앱의 에이전트화: AI 에이전트가 내부적으로 수십~수백 개의 쿼리를 병렬 실행. "누가, 언제, 얼마나 자주" 접속하는지가 예측 불가능해져 사전 설계의 전제가 무너짐 -
• 옵저버빌리티(Observability)의 AI 주도화: AI가 능동적으로 이상을 탐지, 수집, 요약하는 AI SRE로 진화. AI가 자율적으로 데이터를 탐색하기 때문에 정적 대시보드 중심의 기반으로는 기능하지 않음 -

이러한 변화는 「데이터 드리븐 (Data-driven)」에서 「워크플로 드리븐 (Workflow-driven)」으로의 이행으로 정리되었습니다.

이 도표의 핵심은 단순히 양이 늘어나는 것뿐만 아니라, 액세스의 주체 (사람 → 사람 + 에이전트 (Agent)), 경로 (개별 도구 → MCP 횡단), 패턴 (계획적 → 동적·병렬)이 모두 바뀐다는 점입니다. 그리고 기존 DB의 3가지 카테고리로는 이러한 요구사항을 따라잡을 수 없다는 과제가 제시되었습니다.

ClickHouse는 오픈 소스 컬럼형 OLAP (Online Analytical Processing) 데이터베이스로, PB 스케일에서도 밀리초(ms) 단위 응답과 수십 배의 데이터 압축률이 강점입니다. 역사는 2009년 프로토타입으로 시작하여, 2016년 오픈 소스화, 2021년 ClickHouse Inc. 설립, 2022년 ClickHouse Cloud, 2024년 AWS 도쿄 리전, 2025년 GCP 도쿄 리전으로 전개되어 왔습니다. DB-Engines의 분석 OSS 데이터베이스 랭킹 1위, GitHub 스타 48,400개 이상, Cloud 이용 기업 4,000개 이상(최근 3개월간 1,000개 증가. Anthropic, Netflix, Tesla, Meta, Shopify 등)이라는 규모감을 보여줍니다.

속도의 이유는 「리소스의 효율적 사용을 위한 철저한 튜닝 (Tuning)」으로 4가지 사항이 정리되었습니다.

컬럼형 스토리지 (Columnar Storage): 열 단위로 유지하여 초효율적으로 압축. 쿼리에 필요한 열만 읽어 I/O를 극적으로 감소. 오브젝트 스토리지 (Object Storage) 활용으로 비용 이점도 확보 -
INSERT와 SELECT가 경합하지 않는 설계: INSERT는 불변(Immutable)한 Part를 생성할 뿐이며, SELECT는 필요한 Part를 읽기만 하므로 락(Lock) 경합 없이 병렬 처리 가능. Part는 백그라운드 머지 프로세스 (MergeTree)를 통해 정기적으로 통합 및 최적화 -
멀티스레드 (Multi-thread) × 분산 병렬 스캔: 쿼리를 CPU 코어에 분산하여 모든 코어가 동시에 데이터를 처리. 공통 오브젝트 스토리지를 통해 모든 노드가 병렬로 동일 데이터를 참조 -
SIMD 벡터화 쿼리 (Vectorized Query) 및 JIT 컴파일: 1클럭에 여러 데이터를 동시에 처리하여 CPU를 최대한 활용하고, CPU 전용 네이티브 코드로 컴파일하여 고속화

ClickHouse Cloud는 컴퓨트(Compute)와 스토리지를 분리한 클라우드 네이티브 (Cloud-native) 구성으로, 워크로드에 따른 즉각적인 스케일링, 멀티 존(Multi-zone)의 고가용성, Scale-to-Zero 쿼리 엔진을 통한 비용 최적화 기능도 갖추고 있습니다. 강연 슬라이드의 벤치마크에서는 ClickHouse 대비 Databricks 23배, Snowflake 32배, Redshift 57배, BigQuery 101배라는 수치가 제시되었습니다 (벤더 발표 값이므로, 그대로 믿기보다는 경향성으로 받아들이는 것이 좋아 보입니다).

ClickHouse를 중심으로 한 통합 솔루션이 「Agentic Data Stack」입니다. 구성하는 OSS 제품군 라인업이 구체적이었습니다——ClickHouse (고속 컬럼 지향 OLAP, ★48.4K), LibreChat (AI 채팅 플랫폼, ★40.1K), Langfuse (LLM 옵저버빌리티 (Observability), ★30.3K), HyperDX (옵저버빌리티, ★9.6K), PeerDB (데이터 동기화·CDC, ★3.1K), chDB (인메모리 ClickHouse, ★2.7K).

스택 구성은 UI 계층에 ClickHouse Agent (Agentic AI 분석)・ClickStack (옵저버빌리티)・Langfuse, DB 계층에 ClickHouse ⇄ CDC 실시간 동기화 ⇄ Postgres (기반 데이터·트랜잭션), 데이터 연동 계층에 ClickPipes와 데이터 레이크 (Data Lake)・오픈 테이블 포맷 (Open Table Format)의 직접 참조, 그리고 LLM (Anthropic, OpenAI 등)과는 직접 연동되는 형태입니다. 개별 컴포넌트도 소개되었습니다.

• ClickPipes: 관리형 데이터 통합 파이프라인 (Managed Data Integration Pipeline). UI에서 설정할 수 있으며, 데이터 양에 따라 지속적인 수집이 선형적으로 스케일링(Scale)됩니다. 스트리밍 (Kafka/Kinesis/PubSub 등), 오브젝트 스토리지 (S3/GCS 등), RDB와의 CDC (Aurora/RDS/PostgreSQL/MySQL/Supabase 등)를 지원합니다.
• Managed Postgres by ClickHouse: 로컬 NVMe 상의 엔터프라이즈급 Postgres (OLTP가 2~10배 더 빠름)와 ClickHouse의 네이티브 통합 (Native CDC를 통해 분석 쿼리를 오프로드(Offload)하며, 분석은 100배 더 빠름). 애플리케이션에서는 OLTP와 OLAP를 하나의 엔드포인트에서 투명하게 사용할 수 있습니다.
• ClickHouse Agent: 대화형 데이터 활용. 저장된 데이터를 자연어로 분석할 수 있으며, 그래픽 기반의 시각화뿐만 아니라 에이전트(Agent) 및 SKILL 생성도 지원합니다. 네이티브 통합을 통해 사용자의 열람 권한 범위 내에서만 데이터에 접근하며, DB에는 MCP를 통해 연결됩니다.
• Langfuse: LLM 옵저버빌리티 (LLM Observability). API 이용 비용, 응답 시간, 대화 이력의 일원 관리, 프롬프트(Prompt) 버전 관리 및 평가, 테스트 데이터셋을 통한 회귀 테스트를 통해 에이전트를 모니터링하고 가드레일(Guardrail)의 토대를 구축합니다.

ClickStack은 ClickHouse에 저장된 OpenTelemetry 데이터를 대시보드에서 시각화하고, 고압축 스토리지로 전체 로그를 저비용으로 장기 보관하는 구조입니다. 흥미로웠던 점은 AI Notebooks의 데모 이야기였는데, "VISA 결제 에러의 원인을 조사해줘"라고 요청하면, AI가 로그·트레이스(Trace) 스키마 확인 → 최근 24시간의 에러 로그 검색 → 서비스 콜 체인(Service Call Chain) 파악 → 발생 빈도의 시계열 확인 → 트레이스의 워터폴(Waterfall) 획득 순으로 자율적으로 조사를 진행하여, 근본 원인 분석 리포트(원인은 payment 서비스 내 VISA 전용 캐시의 용량 상한 도달, 발생 타임라인 포함)까지 출력한다고 합니다. 나아가 "이 문제를 모니터링하는 대시보드를 만들어줘"라고 하면, 대시보드 생성부터 재발 감지 알람 설정까지 대화만으로 완료됩니다. 옵저버빌리티가 '보는 곳'에서 'AI가 조사하는 곳'으로 변한다는 느낌을 받았습니다.

도입 사례의 수치도 강렬했습니다.