우아콘 2026 현장

우아콘 2025때 도 재밌고 신기한 세션이 많고 실무에 접목시킬만한 주제들이 많았기에, 기술적으로 많은 생각을 했던 좋은 기억이 있어서 이번 우아콘 2026도 고민없이 신청하게 되었다.

장소는 2026년 10월 28일, 장소는 그랜드 인터컨티넨탈 서울 파르나스 호텔, 작년 2025 우아콘과 동일한 장소였다. 작년에도 운 좋게 양도 받아 다녀왔었는데, 이번에도 누군가의 추천인 코드를 운 좋게 받게 되어 다녀올 수 있었다.


내가 들은 세션

올해 주제는 멈추지 않는 도시를 만드는 기술이었다. 트랙은 A부터 F까지 6개, 거기에 멘토링 트랙 G까지 총 41개 세션이었다.

나는 첫 시간에 트랙 C, 두 번째 시간에 트랙 E, 그 뒤로는 트랙 C에 앉아 있었다. 가장 기억에 남았던 세션 2개와 내 생각을 정리해보려고한다.

시간트랙세션
10:50C세 번 그리던 화면을 한 번에: ClayDesign 개발기
11:50E흩어져 있던 배민주문접수: 크로스 플랫폼으로 다시 쓰기
13:50C헤드리스 어드민: UI에서 AI로 환승한 어드민 이야기
15:50C개발이 편해지는 데는 이유가 있습니다

세 번 그리던 화면을 한 번에: ClayDesign 개발기

ClayDesign에 필요한 화면을 문장 한 줄로 프롬프트하면, 해당 프롬프트에 대해 AI가 질의하고, 응답 결과에 따라 기존 배민 화면 템플릿에서 출발해 화면을 만들어 준다. 결과는 Figma, 코드, 베타 앱으로 내보낼 수 있다.

7월 24일에 첫 작업을 시작해서 9월 21일 사내 베타, 10월 13일 전사 오픈까지 갔다고 한다. 세 달 동안 만든 기능이 140개를 넘는다.

속도도 놀라웠지만, 내가 가장 오래 생각한 건 설계 방식이었다.

AI는 코드를 짜지 않는다. 디자인 시스템 카탈로그에 등록된 컴포넌트와 토큰 이름만 써서 화면을 JSON으로 적는다. 실제로 그리는 건 플랫폼별 렌더러가 한다. 그래서 JSON 하나가 웹, iOS, Android, Figma에서 똑같이 그려진다. 세 번 그리던 화면이 한 번이 되는 이유다.

틀린 결과는 저장 전에 걸러낸다. AI가 없는 아이콘 이름을 지어낸 적이 있었는데, 저장 전 검증이 막고 틀린 곳을 문장으로 돌려줘서 AI가 스스로 고치게 했다. 프롬프트를 바꿀 때마다 정해 둔 질문 묶음인 골든셋 으로 다시 시험하는 것도 인상적이었다.

내 생각

사내 디자인 시스템을 직접 만들어봤던 경험에서, 나는 그 당시에 컴포넌트를 잘 만들어 두면 쓰는 사람이 조합하겠지에서 멈췄는데, 배민은 그 조합 자체를 AI에게 맡기되 조합할 수 있는 재료의 목록을 먼저 닫아 뒀다.

처음 들었을 때는 Vercel의 v0나 클로드의 디자인 아티팩트처럼 프롬프트로 화면을 뽑아주는 툴 정도인가 싶었다. 그런데 듣다 보니 핵심은 화면 생성이 아니라 그 앞단에 있었다. UI 규칙을 AI가 이해할 수 있는 JSON 형식으로 먼저 정해두고, 그 JSON 하나로 웹, iOS, Android, Figma 소스를 한 번에 만들어낸다는 점이 달랐다. 디자인 시스템 자체를 AI와 사람이 같이 읽을 수 있는 프로토콜로 만든 셈이고, 그래서 세 번 그리던 화면이 한 번이 되는 거였다.


헤드리스 어드민: UI에서 AI로 환승한 어드민 이야기

오래되고 복잡해서 아무도 손대고 싶지 않은 사내 어드민 툴은 다들 하나쯤 있다. 발표자는 그런 어드민을 못 바꾸는 이유를 세 가지로 꼽았다.

  • 성과로 인정받기 어렵다
  • 입력 폼이 거대하고 복잡하다
  • 개편하는 중에도 요구사항이 계속 들어온다

배민의 경우 쿠폰이었다. 쿠폰 규칙이 폭증해서 웹 화면으로 표현하는 데 한계가 왔다. 그래서 선택한 방법이 웹 UI만 AI 대화로 바꾸고, 그 아래 스키마, 폼 규칙, 검증 API는 그대로 두는 것이었다. 비즈니스 로직만으로 돌아가는 어드민이라서 헤드리스 어드민이라고 부른다.

여기서 포인트는 어드민에 AI 채팅창을 붙인 게 아니라는 점이다. 반대로 사내 AI 서비스에 어드민 기능을 스킬로 넣었다. 어드민에 필요했던 것들은 이렇게 대응됐다.

  • 로그인 권한 → OAuth
  • 안전장치 → 가드레일
  • 배포·업데이트 → 사내 스킬 스토어

그리고 판정은 스크립트(결정론)가, 대화는 AI(확률론)가 맡는다. 규칙 검증처럼 틀리면 안 되는 일은 스크립트가 하고 AI는 대화만 맡는다. 검증이 못 잡은 걸 AI가 잡아준 경우도 있었다고 한다.

다만 웹 UI는 남는다. 간단한 작업, 여러 쿠폰 비교, 실수하면 안 되는 동작은 여전히 화면이 낫다고 했다.

내 생각

Headless 컴포넌트를 만들어 본 적이 있는데 (기록 보기) 그때의 헤드리스는 UI 없는 로직이었다. 이 세션의 헤드리스도 결국 같은 말이다. 로직과 화면을 떼어 놓으면 화면을 AI 대화로 바꿔 끼울 수도 있다는 걸 보여준 사례였다. 좀 더 발전해서 사내 인사 관련 요청을 이번 세션의 헤드리스 어드민 처럼 인사팀 차원에서 도입해준다면 휴가 요청도 단순히 프롬프트로 올릴 수 있는데 얼마나 편했을까? 라는 생각도 잠시 해보았다.


집에 돌아가며

결국 모든 세션은 거창하게 시작하지만 중반부부터 나타나는 키워드는 항상 AI 였다. 무슨 세션에서 나왔던 문장인지는 잘 기억은 나지 않지만 예전에는 구현이 병목이였다면, 지금은 설계와 검증이 병목이다 라는 문장을 들었었는데, 많이 공감이 되었었고, 앞으로 개발하는데 있어서 반복되는 구현을 AI에게 맡기는 건 이미 당연한 일이 되었다는 걸 다시 느꼈다. 그렇다면 내가 시간을 써야 할 곳은 구현이 아니라 그 앞과 뒤다. 무엇을 만들지 정확하게 정의하는 설계, 그리고 만들어진 것이 의도대로 동작하는지 확인하는 검증이다. 이날 들은 세션들도 결국 이 두 가지를 어떻게 시스템으로 만들었는지에 대한 이야기였다.


참고