AI의 발달로 많은 기업에서 어떻게 AI를 활용하고 있는지 이야기를 나눠보고 싶었습니다. 그러던 중 이번 ifkakao26 참여에 선정되어 AI 활용에 대한 다양한 케이스들을 엿볼 수 있었습니다. 개발자부터 QA 담당자, 운영자, 디자이너 모두 AX 에 동참하고 있던 카카오의 문화를 엿볼 수 있던 기회였어요.

DAY2 의 발표 세션은 크게 '안정성과 인프라', '거버넌스', 'AI-DLC', 'Model & Agent' 였습니다. 저에겐 조금 거리감이 있는 주제들일 수도 있지만, 안전하고 신뢰있는 서비스를 만들고 싶다. 라는 저의 가치관과 가까운 것 같아 DAY2를 신청하였습니다.

웰컴 스피치에서도 DAY1 의 세션이 "AI 를 어떻게 쓰느냐" 라는 주제였다면, DAY2 는 "AI 를 믿고 쓸 수 있게" 라는 주제였다고 소개합니다.

입장!

셔틀버스를 타고, AI 캠퍼스로 이동했어요. 판교역이랑 생각보다 많이 떨어져있었고, 살짝 납치(?)를 당하는 기분이었습니다 ㅎㅎ 셔틀 버스에 내리고 발표 장소에 도착하니 "어서오세요~ 이프카카오 입니다~" 라는 환대를 받으며 입장을 할 수 있었습니다. (재밌당)

---

어떤 세션들을 들었나?

아래와 같은 세션들을 들었어요. 총 5개! 모두 다 유익하고 정성껏 발표 준비해주신 발표자 분들로 부터 인사이트를 얻어왔습니다. (저는 사내에서도 발표하면 염소처럼 떠는데, 발표자 분들의 발표를 보니 반성되네요...)

• 좋은 AI를 모으면, 모두의 AI가 될까요? : 카카오가 "모두의 AI"를 만드는 방법
• AI 산출물을 믿어도 되게 만드는 법: QA가 담금질한 하네스와 품질 게이트
• Viking: 개발 지식은 아무것도 몰라도 되는 카카오의 바이브코딩 플랫폼 탄생기
• Kakao Playground: AI로 바꾼 디자이너의 일하는 방식
• 에이전트 하네스로 수백개의 멜론 JSP 포장이사하기

5개의 세션을 관통하는 키워드가 있었는데요, 바로 "AI 가 다 했다고 말해도, 그대로 믿지 않는다" 였습니다.

들어가기 전에, 새롭게 알게 된 개념

• AX (AI Transformation) : 업무에 AI 도구를 하나씩 얹어 쓰는 수준을 넘어, 기업의 운영 방식과 비즈니스 모델 전체를 AI 중심으로 재설계하는 과정이에요.
• AI-DLC (AI-Driven Development Lifecycle) : 소프트웨어 개발 전 과정에 AI 를 핵심 협력자로 도입하는 개발 라이프사이클 방법론이에요. 발표에서는 All night iteration Desperate Labor Chaos 라고도 재밌게 표현했답니다 ㅎ

---

좋은 AI를 모으면, 모두의 AI가 될까요?

모두의AI는 카카오가 주관해 국내 대표 AI 기술, 전문 에이전트, 실행 도구를 하나의 서비스로 연결하는 프로젝트입니다.

• 카카오가 웹서비스와 에이전트 시스템을 구축하고, LG그룹을 비롯한 34개 기업, 기관이 각 분야의 기술과 전문성을 더하는 구조예요.
• 특화 에이전트와 PlayMCP에 등록된 500개의 도구를 바탕으로 서비스를 구성합니다.
• 차별화 포인트는 "모델 성능"이 아니라, 국민이 자주 찾고 실제로 일을 처리해주는 경험에 있다고 해요.
• 앞으로는 더 많은 에이전트가 참여하는 개방형 생태계, '1인 1에이전트', 그리고 업무, 산업 영역으로의 확장을 그리고 있습니다.

"전문성은 에이전트로, 실행은 PlayMCP 도구로" 라는 문장으로 구조를 설명해 주셨어요. 사용자가 체감하는 경쟁력을 위해 운영 측면에서도 신경 쓰는 부분이 많았습니다.

• 라우팅 : 요청에 맞게, 검증된 경로로 모델을 전환
• 비용 효율 : 응답 캐시 활용, 문맥 압축
• 데이터 관리 : 데이터는 국내에 보관하고, 개인 민감정보는 외산 모델에 전달하지 않음

출시를 판단하는 지표와 품질 관리 방식도 인상적이었어요.

• 출시 체크 지표 : 재방문율, 맥락 인계 성공률(다음 단계에서도 맥락과 조건이 이어지는지), 종단 간 과업 완료율
• 품질 관리 : 출시 전 검증(골든셋, 레드팀, 장애 복구, 베타), 단계적 공개, 운영과 개선(사용자 평가, 실패 항목 반영), 재평가 순서로 진행

마지막으로 소개된 대화로 만드는 1인 1에이전트는, 역할과 일하는 방식을 정하고 허용된 정보(허용된 기억)만으로 나만의 에이전트를 구성하는 방식이에요. 예를 들면 "나의 일정, 선호에 맞춰 건강관리 계획을 세우고, 예약을 돕는 에이전트 만들어줘" 처럼요.

느낀 점

솔직히 처음에 "GPT 와의 차별점은 사용자가 일상에서 쓸 수 있는 AI" 라는 설명에는 크게 공감이 되지 않았어요. 지금도 GPT 로 일상적인 일들을 충분히 하고 있으니까요. 그런데 이야기를 듣다 보니, 질문에 대한 답을 "알려주는" 데서 끝나는 게 아니라 카카오톡의 기능과 PlayMCP 도구로 런타임에 실제로 일을 처리해준다는 점이 진짜 차별점이라는 생각이 들었습니다.

그리고 정답률이 아니라 맥락 인계 성공률, 종단 간 과업 완료율 같은 지표로 출시를 판단한다는 점이 기억에 남아요. 여러 에이전트가 이어서 일을 처리하는 구조에서는 "중간에 맥락이 끊기지 않는가" 가 곧 사용자 경험이라는 걸 다시 생각해보게 되었습니다. 골든셋, 레드팀, 단계적 공개로 이어지는 품질 관리 흐름을 보며, 이 세션이 왜 '거버넌스' 트랙에 있었는지도 이해가 되었어요.

---

AI 산출물을 믿어도 되게 만드는 법

"AI가 코드도 테스트도 한 번에 짜줬어요!"... 그런데 그 테스트가 진짜 잡는다는 증거는요?

개발과 배포는 AI 로 빨라졌는데, 검증은 여전히 사람이 손수 따라가고 있고, 그 간격은 앞으로 더 벌어질 거라는 문제 의식에서 출발한 세션이었어요. 그래서 AI 산출물이 지나가는 길목에 품질 게이트를 세웠고, 이를 위한 세 가지 방법론을 소개해 주셨습니다.

1. 적대적 검토 : AI 가 만든 결과물을 "맞는지 확인" 하는 게 아니라 "깨뜨려 보려고" 검토하기
2. 격리하기 : 만든 쪽과 검증하는 쪽의 맥락을 분리하기
3. 다양성 부여 : 하나의 관점이 아니라 여러 관점에서 검증하기

그 결과 결함 검출이 5/8 에서 8/8 로 올라간 실측 결과까지 보여주셨어요. 핵심은 "고치기 전에 재현 테스트부터 돌려서 깨뜨려 본다" 라는 QA 의 기본기를 AI 시대에 다시 살려낸 것이었습니다.

느낀 점

저도 AI 에게 테스트 코드를 작성하게 할 때, 테스트가 통과하면 그냥 안심했던 적이 많았던 것 같아요. 그런데 "통과하는 테스트" 와 "버그를 잡는 테스트" 는 다르다는 걸 다시 한번 생각하게 되었습니다. 특히 AI 가 작성한 코드를 같은 AI 가 같은 맥락에서 검증하면 같은 실수를 반복할 수 있다는 점에서, '격리하기' 를 설명해주신 파트가 가장 기억에 남았어요.

---

Viking (개발 지식 없어도 되는 바이브코딩 플랫폼)

Viking 은 카카오 커머스에서 AX 를 고민하던 사람들이 자발적으로 모여 만든 바이브코딩 플랫폼이에요. "AX 의 시작은 열의 있는 사람들이 스스로 모이는 것부터" 라는 말로 시작했습니다.

• git, argocd, k8s 를 아무것도 몰라도 AI Agent 만 있으면 바로 개발하고 배포할 수 있어요.
• 클릭 몇 번으로 워크스페이스와 앱을 만들고, 에이전트에게 지침만 전달하면 개발 준비가 끝납니다.
• 10~20분 만에 원하는 앱이 완성된다고 해요.
• 오픈 일주일 만에 전사 플랫폼으로 인정받았고, 한 달 만에 사내 회원 1,900명, 배포된 앱 700개를 달성했습니다.

시작은 한 CM 팀장님의 이야기였어요. 업무 노하우를 대시보드로 남기고 싶어 하셨는데, 퇴사 후에도 남아있을 팀원들을 위한 선물이었다고 해요. 그런데 AI 로 만든 대시보드는 로컬에서만 동작했고, 다른 사람이 쓰려면 별도의 서버와 실행 환경, 즉 배포가 필요했습니다.

개발자에게는 너무 익숙한 플로우지만, 비개발자에게는 새로 배워야 하는 영역이죠. 처음에는 한 분씩 배포를 도와드렸지만 서버, 주소, 인증, 접근 설정이 매번 반복되어서 그 방식으로는 따라갈 수가 없었다고 해요. 그래서 Viking 에서는 배포가 요청 한 번이면 끝나고, 즉시 서비스에 반영되도록 만들었습니다.

필요한 모듈(API)을 직접 하나하나 연결하는 대신, Viking 은 지침 인덱스, 서비스별 지침(예: 구글 캘린더), 모듈 문서를 에이전트에게 제공해서 한 번에 연결할 수 있게 해준다고 해요.

느낀 점

한 달 만에 앱 700개라는 숫자도 놀라웠지만, 그 시작이 "퇴사 후 남을 팀원들을 위한 선물" 이었다는 이야기가 가장 기억에 남아요. 기술보다 "이걸 왜 만들고 싶은가" 가 먼저였고, 플랫폼은 그 마음이 막히지 않게 길을 깔아준 것이라는 생각이 들었습니다.

그리고 개발자에게는 당연한 배포가 비개발자에게는 가장 큰 벽이라는 점, 그걸 한 분씩 도와드리다가 결국 플랫폼으로 풀어냈다는 흐름이 인상 깊었어요. 반복되는 도움 요청이 곧 플랫폼의 기회라는 걸 배웠습니다.

무엇보다 "AI 는 코드를 작성할 뿐, 책임은 사람이 진다" 는 말이 마음에 남았어요. 속도는 빨라졌지만 책임의 주체는 바뀌지 않는다는 점이, DAY2 의 주제인 "AI 를 믿고 쓸 수 있게" 와도 맞닿아 있다고 느꼈습니다.

---

Kakao Playground: AI로 바꾼 디자이너의 일하는 방식

디자이너가 직접 구현하고 배포해서 제품을 검증하는 시대 에 대한 이야기였어요.

• Kakao Playground 는 디자이너가 AI 를 활용해 높은 완성도의 프로토타입을 직접 구현하고 배포할 수 있는 AI 에이전트 기반 프로토타이핑 플랫폼입니다.
• Playground 를 만들게 된 배경부터, 실제 업무에 적용하면서 일하는 방식이 어떻게 바뀌었는지 소개해 주셨어요.
• 디자이너들이 Playground 를 실제로 어떻게 활용하고 있는지 사례와 함께 보여주셨습니다.

Playground 는 "개발자 없이 디자이너가 쉽고 빠르게 만들 수 있는 환경을 만들어보자" 에서 출발한 프로토타이핑 공간이에요. 세 가지 문제를 해결하고자 했다고 해요.

• 공유 : 각자의 작업에 모두가 접근할 수 있게
• 공개 : 공유된 작업을 재사용할 수 있게
• 러닝커브 최소화 : 많은 사람이 쓸 수 있게

모두의 프로토타입은 사내 GitHub 의 하나의 공통 폴더에서 관리되고 있었어요. AI 디자인팀은 Playground 를 이렇게 쓰고 있다고 합니다.

1. 워치, 폰, PC 등 다양한 환경에서의 테스트
2. 인터랙션 조정 ("느리게 해주세요", "통통 튀게 해주세요")
3. 개발자에게 CSS 핸드오프까지 직접 전달
4. 디자인 공유와 전략 선행, 리뷰
5. 모션 디자인, 영상 생성까지

그 결과 5개월 사이 AI 디자인팀의 모든 디자이너가 70여 개의 프로토타입을 만들었다고 해요. 처음부터 거창하게 시작하기보다, 작은 스펙으로 시작해서 탐색하고 다양한 의견을 받으며 성장시켰다는 점도 강조하셨습니다.

느낀 점

개인적으로 가장 재밌게 들은 세션이었어요! 디자이너가 "통통 튀게 해주세요" 하고 인터랙션을 직접 다듬고, 개발자에게 CSS 까지 핸드오프한다는 이야기를 들으며, 프론트엔드 개발자로서 협업 방식이 정말 많이 바뀌겠구나 싶었습니다. 정적인 시안이 아니라 동작하는 프로토타입으로 소통하면 "이거 이렇게 동작하는 거 맞죠?" 하고 오가던 비용이 확 줄어들 것 같아요.

사실 저희 회사에서도 비슷한 고민을 하고 있어요. 디자이너가 자연어로 우리 디자인 시스템을 활용해 화면을 그리고, 그 화면을 컨펌받은 뒤 코드로 개발자에게 공유해주는 프로그램을 만들고 있거든요. 그래서 더 반가웠는데, 카카오에서는 이런 환경을 디자이너가 직접 만들고 주도하고 있다는 점이 정말 놀라웠습니다. 저는 막연히 "개발자가 디자이너를 위해 만들어주는 도구" 라고 생각하고 있었는데, 도구를 쓰는 사람이 도구를 만드는 사람이 되면 훨씬 더 실제 업무에 맞닿은 결과물이 나올 수 있겠다는 생각이 들었어요.

그리고 발표 마지막에 나온 "그럼에도 불구하고 변하지 않는 것은 좋은 것을 알아보고 선택하는 능력" 이라는 말이 오래 남았어요. AI 로 누구나 빠르게 만들 수 있게 되어도, 무엇이 좋은지 판단하는 안목은 여전히 사람의 몫이라는 점이 개발자에게도 똑같이 적용된다고 느꼈습니다.

---

에이전트 하네스로 대규모 마이그레이션

"다 했어요!" AI의 이 말을 믿는 대신 검증하게 했습니다.

멜론의 JSP 웹뷰 200여 개를 Astro + Preact 기반의 모던 웹으로 전환한 경험을 공유해 주셨어요. 과제의 목표는 두 가지였습니다.

• 유지보수 : 공통 UI, 일관된 구현 규칙
• 독립성 : FE 단위의 개발, 검증, 배포가 가능하도록 FE 와 API 서버를 분리

처음부터 하네스였던 건 아니었어요.

1. 시도 1. 컨텍스트 엔지니어링 : 결국 개발자가 다시 테스트해야 해서 실패
2. 시도 2. extract, analyze, spec, impl, verify 파이프라인 : 적용할 페이지가 늘어날수록 파이프라인 자체를 계속 고쳐야 했고, 반복은 하지만 나아지지는 않음

그래서 스스로 점점 나아지는 에이전틱 루프, 즉 하네스를 설계하게 되었다고 해요.

• 계획자, 실행자, 평가자 가 협력하는 하네스와, 이를 굴리는 오케스트레이터
• 새로운 기능을 만나면 스킬 하나만 더하면 되는 플러거블 구조
• LLM 의 "완료" 선언을 믿는 대신, 세 개의 결정적(deterministic) 게이트와 적대적 검증으로 완료 여부를 판정
• 실패할 때마다 그 실패를 레슨런으로 남겨 스킬로 바꿔가며 하네스를 단단하게
• 토큰 효율화를 위해 Agent 와 스킬의 사용 규칙을 다듬었고, 이게 가장 효과적이었다고 해요
• 그리고 방향(directive)은 여전히 사람이 정합니다

느낀 점

React Query v4→v5, Next.js 대규모 마이그레이션 프로젝트를 진행하였던 저에게 인사이트가 되었던 세션이었어요. 제가 진행했던 플로우와 발표자 분의 과제 진행 플로우를 비교해보며 인사이트를 얻을 수 있었습니다.

특히 시도 2 의 "반복은 하지만 나아지지 않는다" 는 말에 크게 공감했어요. 파이프라인을 잘 짜두면 끝날 것 같지만, 대상이 늘어날수록 예외가 쌓이고 결국 사람이 파이프라인을 계속 고치게 되죠. 발표자 분은 이 지점을 "실패를 레슨런으로 남기고 스킬로 바꾸는" 구조로 풀어내셨다는 게 인상 깊었습니다.

마이그레이션을 하다 보면 같은 유형의 문제를 반복해서 만나게 되는데, 그걸 매번 사람이 고치는 게 아니라 다음 실행에 반영되는 자산으로 쌓아간다는 점이 가장 기억에 남아요. 그러면서도 방향은 사람이 정한다는 점에서, AI 에게 일을 맡기는 것과 책임을 넘기는 것은 다르다는 걸 다시 느꼈습니다. 다음 마이그레이션에서는 저도 "완료" 를 AI 의 말이 아니라 결정적인 게이트로 판정하는 구조부터 만들어보고 싶어요.

---

마무리하며

"AI 를 믿고 쓸 수 있게" 는 결국 AI 를 믿지 않는 장치를 잘 만드는 것 에서 시작한다는 것이었어요. QA 세션의 품질 게이트, 멜론 마이그레이션의 결정적 게이트와 적대적 검증 모두 "AI의 작업 완료!" 를 믿지 않는다" 는 같은 이야기를 하고 있었습니다.

한편으로 Viking 과 Playground 처럼 개발자가 아닌 분들도 서비스를 직접 만들고 배포하는 흐름을 보며, AX 는 개발자만의 일이 아니라 조직 전체의 변화라는 것이라는 걸 느꼈어요.

안전하고 신뢰있는 서비스를 만들고 싶다. 는 제 가치관과 맞닿은 이야기들을 많이 들을 수 있어서 DAY2 를 선택하길 잘했다는 생각이 듭니다. 이번에 얻은 인사이트를 팀에서도 작게나마 적용해보고, 그 과정도 기록으로 남겨볼게요! (요즘엔 팀에게 필요한 AX 프로젝트가 무엇인지 열심히 고민중이에요!)

그리고 엄청난 ifkakao 에서 주신 선물들 ... 🫰 내년에도 꼭 가고 싶다!