IF KAKAO 2026 첫날 후기
10월 13일, 용인 카카오 AI 캠퍼스에서 열린 IF KAKAO 2026 첫날을 돌아본다. 오전에는 카카오가 준비하는 AI 서비스의 방향을 보고, 오후에는 AI를 실제 업무와 서비스에 적용한 이야기를 들었다.
카카오톡에서 라이언을 불러 일을 부탁하는 시연부터 오래된 코드를 옮기다 놓친 기능 이야기까지, 하루 동안 다룬 주제의 폭이 넓었다. 그중에서도 AI를 써보니 예상과 달랐던 점을 구체적으로 설명한 사례들이 기억에 남는다.
IF KAKAO 2026이 열린 카카오 AI 캠퍼스. 이 글에는 10월 13일 첫날의 기록과 사진을 담았다.
오전 키노트, 카카오톡에서 AI를 부르는 경험
오전 10시 키노트는 정신아 대표의 발표로 시작했다. 사용자를 이해하고 필요한 일을 수행하는 일상형 AI가 주제였다. 예전에 주문했던 생수를 다시 주문하거나 평소 먹는 메뉴를 회사로 배달하는 예시가 나왔다. 사용자가 모든 조건을 처음부터 설명하지 않아도 이전 경험과 현재 상황을 연결하겠다는 방향이다.
오전 키노트의 시작을 연 정신아 대표의 발표.
이어 김대년 총괄이 소개한 카나나 스페이스는 이 경험을 카카오톡 안으로 가져오는 인터페이스였다. 화면을 두 손가락으로 쓸면 라이언이 나타나고, 음성이나 텍스트로 필요한 일을 부탁한다. 메시지를 찾거나 일정을 확인한 뒤 다음 행동으로 이어지는 모습을 보여줬다.
카카오톡 어디서나 불러 사용하는 AI 어시스턴트, 카나나 스페이스.
익숙한 메신저에서 자연스럽게 AI를 부른다는 점이 눈에 들어왔다. 기능을 찾으러 화면을 옮겨 다니는 일이 줄어들면 편하겠다는 생각이 들었다. 메시지 전송이나 결제처럼 중요한 행동은 사용자가 최종 확인하는 흐름도 함께 설명했다. 발표 당시에는 일부 사전 신청자를 대상으로 12월부터 비공개 베타 테스트를 진행할 예정이었다. 카카오 공식 발표
노병석 리더의 카나나 모델 발표에서는 이런 서비스를 많은 사람에게 제공하려면 무엇이 필요한지 다뤘다. 짧은 문장을 고치는 요청과 여러 조건을 맞춰 계획하는 요청에 같은 연산량을 쓸 필요는 없다. 요청에 따라 프론티어 모델, 경량 모델, 온디바이스 모델의 역할을 나누고 컨덕터가 모델과 도구, 실행 순서를 조율하는 방식이었다.
요청의 난도와 처리 환경에 따라 모델의 역할을 나누는 카나나 모델 구조.
음성 대화와 실시간 통역 시연도 있었다. 상대의 말을 모두 기다린 뒤 답하는 방식에서 더 자연스럽게 듣고 말하는 경험으로 나아가려는 모습이었다. 모델의 성능을 서비스의 응답 속도와 비용, 대화 방식까지 연결해 설명한 점이 좋았다.
키노트에는 PC에서 개인 에이전트를 만들고 카카오톡으로 일을 맡기는 칸바스도 등장했다. 에이전트별 브라우저와 실행 환경을 분리하고 사용자가 허용한 범위에서 작업하게 한다는 구상이다. 이미 쓰고 있는 웹서비스와 개인 에이전트를 익숙한 대화 창구로 연결한다는 점에서 어떻게 나올지 궁금해졌다.
칸바스의 Agent Core Engine과 에이전트 작업 화면.
송재하 CTO의 발표에서는 사용자의 기억과 경험을 필요한 맥락으로 연결하는 프로젝트 모자이크를 소개했다. 어떤 정보를 기억하고 어디까지 활용할지, 에이전트의 실행이 동의한 범위 안에 있는지를 다뤘다. 이 이야기는 오후의 메모리 설계 세션에서 더 자세히 이어졌다.
13시, AI로 오래 미뤄둔 변화를 실행하는 법
오후 첫 순서는 「AI로 오래 미뤄둔 변화를 실행하는 법」 파이어사이드 챗이었다. 팀에서 필요하다는 것은 알지만 인력이나 시간이 부족해 미뤄 둔 일을 AI와 함께 해본 사례들이 나왔다. 번역, 디자인 시스템 정리, 프론트엔드 전환처럼 개발팀에서 한 번쯤 고민했을 만한 작업들이었다.
번역보다 먼저 맞춰야 했던 서비스 이름
우아한형제들은 가게와 메뉴 소개 같은 대규모 콘텐츠를 번역한 경험을 공유했다. AI가 번역과 평가를 수행하고, 처리하기 어려운 표현은 사람에게 판단을 요청하는 흐름으로 작업했다고 한다.
가장 기억에 남은 것은 같은 ‘한집배달’이 어떤 화면에서는 Single Delivery, 다른 화면에서는 Express Delivery로 번역된 예시였다. 문장 하나씩 읽으면 그럴듯하다. 그런데 화면을 이어서 보면 사용자는 앞에서 고른 서비스와 같은 것인지 헷갈릴 수 있다.
각 화면에서는 자연스러운 번역이었지만, 화면 사이에서 서비스 이름이 달라졌다.
팀은 표준 용어 사전을 만들고 번역과 검수에 함께 사용하도록 했다. 이를 공통 에이전트로 공유해 팀원들이 같은 방식으로 작업하게 했다. 애매한 표현은 사람이 결정하고 이후 번역에 반영했다.
대규모 물량을 2주 만에 처리했다는 설명도 있었지만, 나는 이 이름이 달라진 예시가 더 오래 남았다. 번역이 맞는지 확인할 때 실제 사용자가 여러 화면을 거쳐 읽는 과정까지 봐야 한다는 점이 구체적으로 와닿았다.
디자인 시스템 전환에는 codemod를 만들었다
다음은 레몬베이스의 디자인 시스템 전환 사례였다. 새로운 라이브러리를 도입해도 자주 수정하지 않는 코드에는 오래된 패턴이 남아 있었다. 평소 주변 코드를 조금씩 정리하는 방식만으로 전체 전환을 끝내기는 어려웠다고 한다.
처음에는 AI에게 코드를 직접 고치게 했는데 의도와 조금씩 다른 수정이 섞였고, 검증하는 데 시간이 많이 들었다. 이후에는 AI에게 반복 적용할 변환 도구인 codemod를 만들게 했다. 어떤 패턴을 무엇으로 바꿀지 정하고 그 규칙을 여러 파일에 적용하는 방식이다.
코드 구조를 보고 변경할 대상을 구분하는 codemod의 예시.
발표에 따르면 전체 전환의 약 95%를 AI의 도움으로 만든 도구로 처리했고, 도메인 정책이나 파일 사이의 관계를 판단해야 하는 나머지는 사람이 검토했다. 변환 명세와 적용 전 변경 내용을 확인하고, 적용 후에는 주요 화면도 점검했다.
AI에게 수정 결과를 만들게 할 수도 있지만 반복해서 사용할 도구를 만들게 할 수도 있다는 점이 유용했다. codemod는 알고 있던 방법이어도 패턴을 조사하고 도구를 구현하는 비용 때문에 시작하지 못할 수 있다. 그 준비에 AI를 활용한 경험이라 실무에 가져오기 좋아 보였다.
Angular에서 React로 옮긴 뒤에도 남은 일
카카오 올리브 플랫폼 사례에서는 서버와 API를 유지한 채 프론트엔드를 Angular에서 React로 전환했다. AI를 기존 코드 분석, 사용자 스토리와 인수 조건 작성, 구현과 테스트까지 넓게 활용했다.
코드가 대부분 전환된 뒤에도 화면을 열어보니 빠진 기능과 달라진 디자인, 중복된 공통 코드가 발견됐다고 한다. 기존 서비스와 비교하도록 요청했어도 간격과 색상, 버튼 테두리, 모바일 화면에 차이가 남았다.
특히 로그인하고 외부 서비스를 연결한 뒤 프로젝트를 분석하는 여러 단계의 흐름을 충분히 파악하지 못했다는 이야기가 눈에 들어왔다. 화면별 구현이 끝난 것과 사용자가 하던 일이 끝까지 이어지는지는 따로 봐야 했다. 팀은 Playwright 기반 E2E 테스트를 완료 조건에 추가하고 직접 확인과 QA로 보완했다.
프론트엔드를 다루는 입장에서 가장 가까이 느껴진 사례였다. 테스트를 작성하는 부담이 줄어들어도 어떤 흐름을 확인해야 하는지까지 자동으로 정해지지는 않는다. 다음 전환에서는 이번에 놓친 문제를 검증 기준에 반영하겠다는 설명이 기억에 남았다.
40시간 동안 자율 실행한 결과
이어진 사례는 다음 작업을 고르는 과정까지 AI에게 맡긴 시도였다. 작업을 작게 나누고 테스트와 리뷰를 붙였으며, 다른 에이전트가 약 30분마다 진행 상황을 확인하도록 했다. 실행은 약 40시간 동안 이어졌다.
그런데 완료 보고 뒤 사람이 확인한 결과는 처음 기대와 달랐다. 원래 목표를 세부 작업으로 바꾸는 과정에서 일부 대상이 빠졌고, 기존과 동일하게 동작해야 한다는 요구도 구체적인 확인 조건으로 충분히 내려가지 않았다.
작업별 검증을 통과해도 계획에서 빠진 범위는 그대로 남을 수 있었다.
이 사례는 테스트와 리뷰, 주기적인 점검까지 있었기에 더 인상적이었다. 검토 절차가 많아도 처음 요구사항이 작업 목록에 모두 들어 있는지는 별도로 확인해야 했다.
패널에서는 잘된 결과와 함께 직접 해보며 발견한 빈틈도 들을 수 있었다. AI로 미뤄 둔 일을 시작할 수 있다는 가능성과, 끝났다고 판단하기까지 필요한 작업을 함께 볼 수 있어 좋았다.
14시, 취약점 분석 에이전트를 운영하는 방법
14시에는 소스코드 보안 분석을 위한 하네스 발표가 이어졌다. 여기서 하네스는 AI 에이전트와 분석 도구, 실행 환경을 연결하고 관리하는 구조를 뜻한다. 아우리가는 여러 역할의 에이전트가 취약점 후보를 찾고 검토한 결과를 한 세션에 모으는 방식이었다.
눈에 들어온 부분은 분석 과정을 데이터베이스에 남기는 방식이었다. 후보가 있는 코드 위치와 판단 근거, 보호 장치, 데이터 흐름을 정해진 형태로 기록했다. 중간에 멈춰도 이어갈 수 있고, 취약점이 아니라고 판단한 후보도 제외한 이유를 남겼다.
분석을 언제 멈출지도 다뤘다. 추론 예산을 정하고 새로운 후보가 더 나오지 않는 상태를 살펴 종료하되, 멈춘 이유와 아직 보지 못한 범위를 기록한다고 했다. 분석 대상 코드는 읽기 전용으로 다루고 커밋이나 푸시도 제한했다.
보안 분석의 세부 기법만큼 결과를 다시 검토할 수 있게 만드는 과정이 기억에 남았다. 무엇을 찾았는지와 함께 무엇을 확인하지 못했는지도 남겨야, 다음 사람이 결과를 받아볼 때 판단할 수 있겠다는 생각이 들었다.
14시 30분, AI가 읽을 보안 로그를 만드는 일
이어진 카카오 CERT 발표는 많은 보안 이벤트를 AI로 분석한 경험이었다. 처음에는 분석가의 역할과 출력 형식을 지정하고 시계열 로그를 전달했지만, 정상 배포를 악성으로 판단하거나 제공하지 않은 로그를 근거로 삼는 문제도 있었다고 한다.
보안 이벤트 분석에 AI를 적용한 초기 흐름과 이후의 개선 과정을 설명했다.
대응 과정에서는 입력 데이터의 구성이 중요했다. 많은 로그를 그대로 전달하면 입력 한도 때문에 일부가 잘릴 수 있었다. 필요한 필드를 고르고 내부 시스템의 정상 작업에 관한 맥락을 제공했다. 반복 로그는 발생 시각과 횟수 같은 정보를 남기면서 축약했다.
AI가 정상으로 판단한 이벤트를 다음 분석에 재사용하는 과정도 있었다. 화이트리스트 룰을 생성하되 사람이 검토한 뒤 활성화하고, 이후 같은 유형의 경보는 먼저 걸러 불필요한 분석 요청을 줄였다.
이 발표를 들으며 모델에 자료를 많이 넣는 것만으로는 충분하지 않다는 생각이 들었다. 어떤 정보를 남겨야 사건의 앞뒤를 이해할 수 있는지, 반복되는 판단을 어떻게 다음 처리에 활용할지가 실제 운영의 중요한 부분이었다.
15시, 사용자의 기억을 다루는 프로젝트 모자이크
15시에는 오전 키노트에서 소개됐던 프로젝트 모자이크를 더 자세히 다뤘다. 서비스 이용 정보를 바탕으로 사용자의 맥락을 어떻게 기억하고, 여러 서비스가 그 기억을 어떻게 활용할지에 관한 발표였다.
단기적으로 관찰한 행동, 한동안 지속되는 상태, 장기적인 선호를 구분하는 설명이 있었다. 한 번의 구매를 곧바로 오래 유지될 취향으로 판단하기는 어렵다. 다른 사람에게 줄 선물일 수도 있고, 시간이 지나 선호가 달라질 수도 있기 때문이다.
필요한 기억을 남기고 시간에 맞게 갱신하며, 사용자의 선택권을 함께 고려한다.
기억을 잘 만드는 일에 사용자가 관리할 방법까지 포함한다는 점이 좋았다. 어떤 정보를 재료로 쓸지, 어떤 기억을 추가하거나 삭제할지, 어느 서비스에서 활용하도록 할지를 선택할 수 있어야 한다는 설명이었다.
서비스별 전문성과 여러 서비스의 맥락을 함께 활용하기 위해 서비스별 메모리와 중앙 메모리를 병행하는 구조도 소개했다. 발표 당시에는 정책과 아키텍처를 설계하는 단계였다. 오전에 본 개인화된 서비스 경험이 나오기까지 데이터 해석과 동의 범위를 꽤 세밀하게 다뤄야 한다는 것을 알 수 있었다.
15시 30분, 카나나 스페이스 화면 뒤의 구현
15시 30분에는 카나나 스페이스의 구현 이야기를 들었다. 오전에는 라이언을 불러 일을 부탁하는 모습을 봤다면, 이번에는 그 요청이 서버와 클라이언트 사이에서 어떻게 처리되는지 설명했다.
테마 변경처럼 카카오톡 안에서 실행해야 하는 기능은 서버가 푸시로 동작을 요청하고 클라이언트가 별도 API로 결과를 돌려주는 방식이었다. 실행 ID와 Redis로 원래 요청에 결과를 연결하고, 에이전트가 실제 실행 결과를 받아 사용자에게 응답했다.
사용자마다 앱 버전이 다르다는 문제도 있었다. 클라이언트가 자신이 지원하는 기능과 입력 형식을 알려주면 에이전트가 사용할 수 있는 툴을 판단하게 했다. 자연어로 요청하더라도 실제 앱에서 가능한 기능은 명확하게 전달해야 했다.
후반에는 UI 카탈로그 이야기가 이어졌다. 기본 UI 요소를 AI가 자유롭게 조합하도록 했더니 같은 요청에도 배치와 색상, 안내 문구가 달라지는 문제가 있었다.
같은 요청을 반복할 때마다 다른 화면에 적응해야 하는 문제를 다뤘다.
서비스가 UI 요소와 배치 구조, 데이터 형식을 카탈로그로 준비하고 렌더러가 화면을 그리도록 했다. 당시에는 툴마다 사용할 카탈로그가 정해져 있었고, 에이전트가 상황에 맞는 카탈로그를 선택하도록 연결을 개선하는 중이었다.
프론트엔드 관점에서 재미있었던 부분이다. AI가 화면을 구성할 수 있어도 사용자가 익숙하게 읽고 조작할 기준은 필요했다. 오전의 시연에서 간단해 보였던 요청 뒤에 기능 실행과 버전 차이, 화면의 일관성을 맞추는 일이 함께 있다는 점이 보였다.
첫날을 돌아보며
오전에는 카카오가 만들려는 AI 경험의 큰 그림을 봤고, 오후에는 각 팀이 실제로 작업하며 부딪힌 문제를 들었다. 서비스 시연에서 시작해 코드와 데이터, 사용자에게 보이는 화면까지 내려가며 살펴볼 수 있었던 하루였다.
개인적으로는 codemod를 만든 사례와 올리브 플랫폼의 전환 경험이 바로 업무에 떠올려볼 만했다. 반복되는 변경을 도구로 만들 수 있는지, 전환이 끝났다고 할 때 어떤 사용자 흐름까지 확인했는지를 다음 작업에서 살펴보고 싶다.
카나나 스페이스도 실제로 사용할 때 어떤 경험일지 궁금하다. 발표에서 본 짧은 부탁이 일상에서도 얼마나 자연스럽게 이어질지, 사용자가 기억과 실행 범위를 어떻게 관리하게 될지 직접 확인해보고 싶다.