pxd는 구글 캘린더와 슬랙을 연동해 업무 일정을 등록하고 공유해요. 특히 회의가 잦은데요. 대부분 슬랙으로 소통하며 회의 일시를 합의하고 그중 누군가가 구글 캘린더에 등록하면서 빈 회의실 중 하나를 지정하는 방식이죠. 그런데 pxd 내부에서 이러한 과정이 번거롭고 불편하다는 목소리가 들려왔어요. 모바일 경험이 개선됐으면 좋겠다는 의견도 많았고요. 이럴 땐 뚝딱뚝딱 유용한 도구를 만들어 문제를 풀어내는 XE(eXperience Engineering) 팀이 나설 차례에요. 

왜 사용자는 불편해할까?

먼저 불편함의 이유를 파악해야 해요. pxd 구성원, 즉 사용자는 왜 기존 회의실 예약 방식을 불편하다고 느꼈을까요? 업무 호흡이 빠른 조직 특성상 회의가 잦고 즉각적으로 회의를 해야 하는 일도 빈번하지만, 회의실이 상대적으로 부족하기 때문이에요. 일정을 정해두고 그에 맞는 회의실을 찾으면 빈 곳이 없을 때가 많죠. 

회의실 선점이 중요한 상황이에요. 그래서 사용자는 정해진 회의 시각을 앞뒤로 여러 번 변경해 가며 빈 회의실을 찾기보다, 처음부터 모든 회의실의 예약 상황을 살피고 공실이 있는 시간에 맞춰 회의 일정을 잡는 경향이 있죠. 구글 캘린더는 ‘일정’을 기록하고 장소, 회의 자료 등과 함께 공유하는 서비스인 만큼, ‘공간’을 중심으로 하는 사용자의 업무 양상에 맞아떨어지지 않았던 거예요. 

어떻게 사용자를 만족시킬까?

사용자는 최대한 빠르게 어떤 회의실이 언제 비는지 파악, 예약하기를 원해요. 사용자의 불편을 해소하기 위해서는 전체 회의실이 한 화면에 보이지 않는 캘린더에서 예약 상태를 번거로이 확인하는 기존 방식에서 벗어나야 했죠. 이미 여러 업무 도구를 사용하고 있기 때문에 회의실 예약만을 위한 새로운 도구를 추가해 사용자의 부담을 더할 수는 없었어요. 고민 끝에 구글 캘린더와 연동해 기존 슬랙에서 쓸 수 있는 ‘봇(Bot)’을 만들기로 했어요.

사용자가 원하는 일정을 메시지로 보내면 바로 그에 맞는 회의실을 예약할 수 있게 하자. 일차적인 목표는 단순했어요. 사용자와 메시지로 상호작용하는 봇을 만들기 위해 노드제이에스(Node.js)와 슬랙 API 기반 프레임워크 볼트(Bolt), 그리고 텍스트 메시지가 갖는 한계를 보완하기 위해 버튼, 이미지 등 여러 UI를 접목할 수 있는 슬랙 블록키트(Block Kit)를 활용했죠. 봇의 이름은 이전 회의실 예약 시스템 ‘더제로(The zero)’에 더 간편하다는 의미의 ‘라이트(Light)’를 더한 ‘더제로라이트’로 정했어요.

어디서 UX가 본래 의도에서 벗어났을까?

UX는 언제나 예측하지 못한 변수가 생기죠. 더 편한 경험을 위해 설계한 부분이 오히려 사용자에게 불편함을 가져다주는 상황이 발생하기도 했어요. 기획 초기에는 사용자가 “2시간 잡아줘”와 같은 메시지를 보냈을 때 봇이 추가 정보를 요청하도록 설정했는데요. 예약과 조회 중 뭘 하고 싶은 건지, 회의 시작 시각은 언제가 좋을지 등 부족한 정보를 보완해 봇이 더 정확하게 명령을 수행할 수 있도록요. 

하지만 인터뷰 결과, 사용자는 봇과 추가적인 대화를 주고받는 상황을 달가워하지 않았어요. 사용자에게는 정확도보다 신속함이 더 중요했던 거예요. 회의실이 부족한 상황에서는 누구보다 빠르게 예약해야 하니까요. UX의 편안함을 만들어가는 과정에서 서비스의 본래 목적, 취지를 잊지 말아야 한다는 교훈을 되새겼죠.

누가 ‘사용자’로서 경험하고 있을까?

사용 기록(로그)을 되짚어 보며 사용자를 이해하는 과정도 필요했어요. 우리의 사용자는 ‘대충 말한다’라는 특성이 있었는데요. 이유는 크게 두 가지였어요. 먼저 고려할 사안은 주어, 목적어 등 문장 구조의 일부를 생략해도 맥락에 따라 의미를 파악할 수 있고 표현이 다채로운 한국어 사용자라는 점이었어요. 같은 시각을 ‘오후 3시’, ‘세시’, ‘15시’, ‘3시’ 등으로 다양하게 말해요. 

사용자가 AI에 메시지를 보낼 때 ‘사람과 대화하듯’ 정보를 전달한다는 점도 중요하게 작용했죠. 챗봇 형식을 띠고 있긴 하지만, AI는 사용자의 메시지를 ‘대화’가 아니라 작업 수행의 근거가 되는 ‘입력값(프롬프트)’으로 인식해요. “내일 오후 3시에 회의실 예약”과 같이 원하는 날짜, 시간, 행동 등의 정보를 AI에게 전달해야 하죠. 그런데 사용자는 “내일 3시”라고 메시지를 보내고 AI가 알아서 잘 이해하기를 기대했어요. 이를 반영해 사용자가 쓰는 시간과 노력을 최소화하는 방법을 고안해야 했어요. 

언제 AI가 관여해야 할까?

누구보다 빠르게, 대충 말해도 알아서 눈치 있게! 사용자에게 적합한 도구의 방향성이 명확해졌는데요. 빠른 정보 처리를 위해 키워드 기반 로직을 쓰자 사용자 메시지의 의도를 파악할 때 오류가 자주 생겼어요. 사용자가 ‘내일’이 포함된 메시지를 보내면 봇은 ‘나의 일’이라고 인식하는 식이었죠. 맥락을 추론할 수 있는 생성형 AI 제미나이(Gemini)에게 알아서 하라고 일을 맡기기엔 운영 비용과 사용자의 대기 시간이 늘어났고요. 

효율적으로 목표를 달성하기 위해서 사용자의 업무 환경에 꼭 맞는 규칙을 정해두고 필요한 때에만 AI를 호출하기로 했어요. 우선 프롬프트로 AI에게 다양한 예시 문장과 한국어의 고유한 표현과 특성을 학습시켰어요. 사용자가 보낸 메시지는 심화 한국어를 배운 AI가 눈치껏 추론 능력을 발휘해 맥락을 읽어내도록, 예외 사례 대응이나 추론 이후 동작으로 이어지는 일련의 과정은 우리가 설계한 로직을 따르게 했죠. 예를 들어, 사용자가 무엇을 원하는지 명확히 알기 어렵다면 ‘오늘’, ‘지금’에서 가장 가까운 시각을 기준으로 회의실을 ‘예약’하는 거예요. AI의 효율성에 사람의 세심한 손길을 더했죠.

/**
 * 앵커(시간/날짜/회의실) 감지 시 기본 예약 플로우로 디폴트 적용
 * - 어떤 의도도 잡히지 않았을 때만 적용 (정보/현황/추천/내회의 등 이미 분류된 경우는 보존)
 * - 시간 앵커만 있고 날짜가 없으면 오늘 날짜를 기본으로 설정
 */
function applyAnchorReservationDefault(result: ParseResult, message: string): ParseResult {
  // 이미 의도 확정 시 보존
  if (
    result.isReservationRequest ||
    result.isAvailabilityCheck ||
    result.isRecommendationRequest ||
    result.isMyMeetingRequest ||
    result.isRoomInfoRequest
  ) return result;

  const lower = message.toLowerCase();

  // 1) 앵커 탐지
  const timeAnchor =
    /(오전|오후|아침|저녁|밤|새벽|점심)/.test(message) ||
    /(\d{1,2})시(\d{1,2})?분?/.test(message) ||
    /(\d{1,2}:\d{2})/.test(message) ||
    /(한|두|세|네|다섯|여섯|일곱|여덟|아홉|열|열한|열두)시/.test(message);

  const dateAnchor =
    /(오늘|내일|모레|이번주|다음주|차주|월요일|화요일|수요일|목요일|금요일|토요일|일요일)/.test(message) ||
    /\b\d{1,2}[/-]\d{1,2}\b/.test(lower) ||
    /\d{1,2}월\s*\d{1,2}일/.test(message);

  const roomFind = findRoomName(message);
  const roomAnchor = !!roomFind.roomName || !!roomFind.needsSelection || lower.includes("회의실");

  const hasAnyAnchor = timeAnchor || dateAnchor || roomAnchor;
  if (!hasAnyAnchor) return result;

  // :white_check_mark: 기본: 예약으로 스냅(단, 날짜만 있으면 추천으로 전환)
  let adjusted: ParseResult = { ...result, isReservationRequest: true };

  // 2) 날짜만 있는 케이스 → 추천으로 전환
  if (dateAnchor && !timeAnchor && !roomAnchor) {
    adjusted.isReservationRequest = false;
    (adjusted as any).isRecommendationRequest = true;
    adjusted.date ||= getTodayString();
  }

  // 3) 회의실만 있는 케이스 → 오늘/현재 기준 시간 보강
  if (roomAnchor && !timeAnchor && !adjusted.date) {
    adjusted.date = getTodayString();
    adjusted.time = getCurrentTimeBasedRecommendation();
  }

  // 4) 시간만 있고 날짜 없으면 오늘로 보강
  if (timeAnchor && !adjusted.date) adjusted.date = getTodayString();

  // 5) 파싱 누락 보강
  if (timeAnchor && !adjusted.time) adjusted.time = parseTimeFromMessageFallback(message) || adjusted.time;
  if (!adjusted.room && (roomFind.roomName || roomFind.needsSelection)) {
    adjusted.room = roomFind.roomName || null;
    adjusted.needsRoomSelection = roomFind.needsSelection;
    adjusted.possibleRooms = roomFind.possibleRooms;
  }

  return adjusted;
}

무엇이 ‘더 좋은 UX’일까?

이렇게 만들어진 더제로라이트는 사용자와 가깝게 소통하는 서비스를 지향해요. 회의실 예약 버튼을 누르면 예약 링크를 전달하는 기능이 대표적인 예인데요. 예약 중 수정하고 싶은 내용이 생기거나 오류가 발생했을 때, 사용자가 링크로 열린 구글 캘린더 예약 화면에서 즉각 수정할 수 있도록 설계했어요. 봇이 사용자에게 ‘이게 맞는지’ 재차 묻는 일, 구글 캘린더에 자동 등록된 일정을 사용자가 찾아서 수정 또는 삭제하는 일의 번거로움을 덜기 위해서예요. 

자동화가 반드시 편리함을 가져오지는 않아요. 더제로라이트는 필요한 순간에는 알아서 움직이되 사용자와 접점을 만들기 위해 노력했어요. 예약이 완료된 대화 내용은 자동 삭제해 사용자의 스크롤 부담을 줄이고 불가피한 대기 시간에는 사용자가 불안함을 느끼지 않도록 상태 메시지를 띄워요. 모바일에서는 팝업 알림도 제공하고요. 시킨 대로 잘하고 있으니 걱정하지 말라 사용자를 안심시키는 거죠.

UX에 정해진 답은 없어요. 다만, 우리 사용자의 특성에 따라 상대적으로 좋은 경험은 있을 거예요. 그러니 더욱 사용자와 사용자를 둘러싼 맥락에 관심을 기울여야 하죠. 더제로라이트가 pxd 구성원 어려움을 나서서 살폈던 것처럼요. 어디선가 누군가에 무슨 불편한 일이 생길 때, XE 팀은 틀림없이 다시 나타날게요!