오늘은 우아콘 2026에 다녀왔습니다. 우아한형제들이 목표로 하는 심리스 시티에 대한 키노트(Keynote: 기조연설)를 시작으로 AI, 백엔드, 프론트엔드, CS, 마케팅 등 다양한 분야에 걸친 트랙이 준비되어 있어서 최대한 다양하게 들어봤습니다.
들으면서 적어 둔 메모를 바탕으로 세션별 내용과 그때 든 생각을 정리해 보겠습니다. 아래 세션 제목은 공식 제목이 아니라 제가 내용을 보고 붙인 것입니다.
키노트: AI로 배달 경험 개선하기
키노트의 주제는 사람이 직접 입력하거나 손으로 관리하던 값을 AI 예측으로 바꾸는 일이었습니다. AI로 예측하고, 결과를 확인하고, 다시 AI를 개선하는 과정을 계속 반복하겠다는 것이 큰 방향이었습니다.
대표적인 예가 조리시간입니다. 지금까지는 조리시간을 직접 입력받았지만, 이제는 기존 데이터를 활용해 더 정확하게 추정해서 부정확하게 입력된 정보도 바로잡을 수 있다고 합니다. 비가 올 때 배달 가능 범위를 조정하는 일도 예전에는 관리자가 수동으로 고쳐야 했지만, 지금은 AI로 빠르게 처리하고 있다고 합니다.
결국 목표는 고객이 기다리는 시간을 줄이는 일입니다. 이전 데이터를 학습해 조리시간과 도착시간 같은 값을 더 빠르고 정확하게 예측하면, 그만큼 기다리는 시간도 줄어든다고 설명했습니다.
D트랙: AI로 기술 블로그 글 검수하기
배민에는 기술 블로그 글의 검수와 발행을 맡는 ’테크니컬 라이팅 코치’가 따로 있는 것으로 보였습니다. 이 세션은 코치가 글을 읽고 고칠 부분을 짚어 주던 일을 AI로 처리하는 것이 목표였습니다.
발표자는 Claude 스킬로 글을 수정하니 글쓴이가 일부러 넣어 둔 비유법 같은 개성이 그대로 남았다고 설명했습니다. 그래서 모델 성능에만 기대기보다 스킬로 정확한 지침을 주는 편이 낫다는 이야기였습니다.
다만 처음에는 스킬에 규칙만 넣었더니 AI가 잘 지키지 않아서, ’규칙 적용’과 ’규칙 위반 탐지’를 별도의 스킬로 만들어 따로 돌렸다고 합니다. 저는 이 부분에서 생각이 조금 다릅니다. 굳이 스킬을 두 개로 나누지 않아도, 한 스킬 안에 “먼저 이것을 하고, 마지막에 이것을 점검하라”처럼 순서를 적어 주면 해결되지 않을까 싶습니다.
AI에게 명확한 성공 기준을 주는 것도 중요하다고 생각합니다. Anthropic 공식 문서에도 나오는 내용으로, 단순히 “좋은 문장 써 줘”라고 맡기기보다 “이 기준으로 높은 점수가 나오게 써 줘”처럼 일을 맡길 수 있어야 합니다.
이 밖에 Nemotron-Personas-Korea로 한국인 페르소나 100명을 만들어본 이야기도 있었습니다. 발표에서 소개한 테크니컬 라이팅 스킬은 우아한형제들 기술 블로그에 공개할 예정이라고 합니다.
A트랙: Temporal로 서버 간 흐름 한곳에서 관리하기
발표한 팀은 예전에 장애가 나면 로그를 뒤져 가며 원인을 분석했는데, 이 과정이 너무 힘들었다고 합니다. 게다가 여러 서버가 각자 자신만의 큐나 리스너 구조로 동작해서 전체 흐름이 복잡했고, 그래서 서버마다 제각각이던 구조를 Temporal 워크플로우 엔진으로 모았다고 설명했습니다. Temporal은 여러 서버가 통신할 때 거쳐 가는 중앙 관제소 같은 역할을 합니다.
Temporal의 가장 큰 장점은 Replay 기능입니다. 워커1이 죽어도 그 전까지의 실행 기록이 모두 남아 있어서, 워커2가 이 기록을 넘겨받아 처음부터 따라가며 상태를 되살린 뒤 죽은 시점부터 일을 이어서 합니다. 외부 API 장애에 대비한 재시도나 타임아웃 설정을 엔진이 제공한다는 점도 장점으로 꼽았습니다.
물론 겪은 문제도 있었습니다. DB I/O 부하는 클러스터를 늘려서 해결했다고 하는데, 결국 DB 자체를 증설한 것으로 보입니다. 또 Temporal로 들어오는 시그널을 처리하는 핸들러를 한 메서드에 모으고, 주문부터 배달 완료까지의 과정을 순서대로 나열해 흐름이 한눈에 보이게 정리했습니다.
E트랙: 시계열 파운데이션 모델로 CS 인입량 예측하기
CS 상담사는 서버처럼 자동으로 늘릴 수가 없습니다. 이 세션은 문의가 언제 몰릴지를 미리 예측한 이야기였고, 예측 결과는 상담사 수를 조정하는 데 쓰는 것으로 보였습니다.
처음에는 LightGBM을 썼지만 결과가 만족스럽지 않아서 파운데이션 모델로 바꿨다고 합니다. 파운데이션 모델은 ChatGPT처럼 대량의 데이터로 미리 학습을 마친 범용 모델인데, 여기에 회사 데이터로 추가 학습만 해도 더 높은 정확도로 예측할 수 있었다고 설명했습니다.
다만 과거 인입량 같은 시계열 데이터만으로는 예측이 되지 않아서, 강수량이나 휴일처럼 중요하다고 본 정보를 함께 넣었습니다. 결국 시계열 파운데이션 모델로 특정 시간대에 몰릴 문의와 문제를 미리 알아내는 것이 이 세션의 핵심이었습니다.
D트랙: 사내 바이브코딩 툴, 만들기 전에 따져 볼 것
이 세션은 사내 툴을 만드는 것보다 동료들이 믿고 계속 쓰게 만드는 일이 더 어렵다는 이야기였습니다. 발표자는 사내 툴을 만들 때 생기는 문제를 여섯 가지로 짚었습니다.
- 나만 쓰기 쉬우면 끝이라고 생각하고, 다른 사람이 쓰기 어려운지는 고려조차 하지 않습니다.
- 웹앱이 꼭 필요하지 않은 경우가 많습니다. Claude 스킬 정도만 공유해도 끝날 문제라면 굳이 웹앱으로 배포할 이유가 없습니다.
- AI로 만든 툴은 한 번 문제가 생기면 팀원들이 잘 믿어 주지 않습니다. 그래서 전사에 공유하기 전에 5명 정도로 베타 테스트를 해서 오류를 줄이길 권했습니다.
- 계속 알려야 합니다. 발표자는 점심시간에 공유하는 식으로 꾸준히 알렸다고 합니다.
- 이미 있는 도구가 있다면 만들지 말고 가져다 써야 합니다.
- 유지보수할 각오가 있을 때 만들어야 합니다. 만들면 끝이 아닙니다.
3번의 베타 테스트는 좋은 방법이라고 생각하지만, 회사 규모가 작으면 그대로 적용하기는 어렵지 않을까 싶습니다. 그 밖에 ’모킹버드’에서는 보안에 특히 신경 써서 사내 계정으로 로그인하도록 했다고 합니다.
D트랙: AI로 전사 코드를 분석해 장애 원인 찾기
AI가 전사 코드를 직접 분석할 수 있게 되면서, 이제는 다른 팀의 도움 없이도 장애 원인을 찾아 해결할 수 있게 됐다고 합니다. 발표자가 소개한 지금의 흐름은 이렇습니다.
- 슬랙 메시지 하나로 장애 조사를 시작합니다.
- 레이어마다 미리 만들어 둔 분석 코드로 조사를 실행합니다.
- LLM이 각 조사 결과를 읽고 판단합니다.
- 결과를 하나로 합쳐 최종 원인을 분석합니다.
이 흐름의 원칙은 ’실행은 코드가, 판단은 LLM이’입니다. LLM에게 “트레이스 분석해”라고 그냥 맡기지 않고, 실행 순서와 방식, 작업 시간을 정형화하기 위해 트레이스 분석에 쓸 코드를 미리 만들어 둔 뒤 그 코드만 쓰게 한다고 설명했습니다. 그리고 검증된 것만 추가 스킬로 반영하고, 나머지는 반영하지 않습니다.
운영하면서 겪은 문제도 소개했습니다. A 버그로 장애가 났는데 AI가 B 버그를 고쳐 준 일이 있었는데, B도 논리적으로 문제가 있는 코드였지만 이번 장애와는 관련이 없었습니다. 그래서 이번 장애와 관련된 코드인지 검증하는 단계를 추가하고, 경보에 우선순위를 미리 부여해서 더 중요한 부분부터 확인하게 했다고 설명했습니다.
배민은 팀이 크다 보니 팀마다 조회할 수 있는 범위가 달라서 전체 그림을 한 번에 보기 어렵다는 문제도 있었습니다. 다만 이건 배민처럼 큰 조직의 이야기라, 저희 회사 규모에서는 문제가 되지 않을 것 같습니다.
E트랙: B마트와 배민스토어, 퀵커머스 하나로 합치기
퀵커머스는 재고를 고객 가까이에 두고 빠르게 배달하는 커머스를 말합니다. 고객에게는 하나인 장보기 서비스가 회사 안에서는 공급자가 다른 두 서비스, B마트와 배민스토어였고, 이 세션은 둘을 하나로 합치면서 푼 문제들을 다뤘습니다.
먼저 용량처럼 빠져 있던 카탈로그 정보를 추가해 통합했습니다. 가격도 문제였습니다. 같은 상품이라도 지점마다 가격이 달라서, 예를 들어 송파에서는 1,000원이고 강남에서는 500원일 수 있습니다. 셀러와 지점이 늘면서 상품이 100개면 100건을 각각 고쳐야 하는 상황이 됐다고 합니다.
이렇게 여러 건을 고치다 보니 트랜잭션 문제가 생겼습니다. N건을 고치는 동안 커넥션을 끝까지 잡고 있으면 안 되고, 그렇다고 차례대로 반영하면 반영하는 동안 잠깐 값이 다르게 보일 수 있습니다. 그래서 지점별 가격은 희소 오버라이드 방식으로 관리한다고 설명했습니다. 지점 값이 본사 값과 같으면 지점 데이터를 따로 저장하지 않고, 본사와 지점이 같은 값을 고치면 우선순위로 어느 값을 볼지 정하는 방식입니다.
재고 쪽에서는 바이너리 RPC 통신과 인메모리 DB로 조회용 재고 서비스를 만들어 가볍고 빠르게 했습니다. 또 두 서비스는 재고를 관리하는 기준이 달라서, 예를 들어 배민스토어는 용량별 재고를 따로 관리하지 않습니다. 이 차이를 맞추려고 전시 재고 매칭 서비스를 만들었다고 합니다.
마지막으로 상품 조회와 주문에 쓰는 DB를 나눴습니다. 조회는 완벽하지 않아도 되니 느슨하게 처리하고, 주문과 결제는 정확해야 하니 원장을 조회하게 했다고 설명했습니다.
마치며
AI를 다룬 세션들에는 공통점이 하나 있었습니다. AI에게 그냥 맡기지 않고, 성공 기준을 주거나 관련성을 검증하거나 소수 인원으로 먼저 테스트하는 식으로 결과를 믿을 수 있게 만드는 장치를 두고 있었습니다.
배민 같은 큰 조직이라서 나온 고민도 있었지만, 규모와 상관없이 바로 해 볼 수 있는 것도 있었습니다. 우선 스킬을 쓸 때 “잘 써 줘” 대신 무엇을 먼저 하고 마지막에 무엇을 점검할지, 어떤 기준을 넘겨야 하는지를 적어 보려고 합니다. 분석처럼 자주 하는 작업은 코드로 만들어 두고 LLM에게는 판단만 맡기는 방식도 시도해 보려고 합니다. 그리고 사내 툴을 만들고 싶어질 때는 이미 있는 도구는 없는지, 스킬 공유로 충분하지 않은지, 유지보수할 수 있는지부터 따져 보려고 합니다.