01 · PROBLEM

조율과 예약 사이에서 끊기는 워크플로우

님블뉴런은 NAVER Works Calendar를 통해 회의실을 예약합니다. 하지만 실제 회의 조율은 대부분 Slack 채널에서 이루어집니다. 특히 개발리뷰 시즌에 많은 회의로 일정이 바쁜 개발 리더들이 포함된 회의의 경우, [리더들의 빈 시간 확인 → 회의실 가용 상태 대조 → 참석자 전원 일정 확인] 과정을 수동으로 반복해야 했습니다. 슬랙 쓰레드에서 논의하다가 예약을 위해 외부 툴로 이동하는 과정 자체가 맥락을 끊는 업무 비용이자 병목이었습니다.

02 · APPROACH

Slack 안에서 업무가 종결되는 Agent 구조

단순히 질문에 답하는 챗봇을 넘어, 논의가 일어나는 Slack 안에서 즉시 업무가 종결되는 Agent 구조를 설계했습니다.

사용자 중심의 인터페이스 — 새로운 툴에 적응할 필요 없이, 사용자가 가장 익숙한 Slack에서 평소 대화하듯 자연어로 요청하는 방식을 채택했습니다. “이번 주 금요일 오후에 아트디렉터, 프로그래머1, 기획자1님 모두 가능한 시간에 회의실 어디야?”라는 한 문장이면 충분합니다.

지능형 교차 분석 — AI가 요청을 해석해 특정 참석자들의 개인 캘린더와 회의실 현황을 실시간으로 교차 분석하고, 모두가 만족하는 최적의 옵션을 도출합니다.

시스템 자동화의 완결 — 슬랙에서의 대화로만 끝나지 않고, 최종 확정 시 NAVER Works Calendar에 실제 일정 등록까지 자동으로 수행합니다. 이를 통해 ‘커뮤니케이션’과 ‘행정 입력’ 사이의 간극을 완전히 제거하는 것을 목표로 했습니다.

03 · BUILD

실제 문제를 해결하는 핵심 기능

• 자연어 기반 컨텍스트 파싱 — 슬랙 쓰레드 내 날짜, 시간, 참석자 정보 추출
• 교차 일정 최적화 — 특정 참석자(개발 리더 등)의 빈 시간과 회의실 가용 상태를 실시간 대조
• 인터랙티브 UI 제공 — 분석된 가용 시간대 중 사용자가 선택할 수 있는 슬랙 UI 버튼 제공
• API 통합 및 정합성 유지 — NAVER Works API를 통한 일정 등록 및 외부 수정 사항 실시간 반영
• 연속성 있는 대화 처리 — 슬랙 쓰레드 문맥을 유지하여 “그때 말고 한 시간 뒤로 변경해줘” 같은 후속 요청 처리

04 · IMPACT

조율 단계가 사라지고 실행만 남다

여러 명의 캘린더를 일일이 대조하며 회의실을 찾던 번거로움을 없앴습니다. 사용자는 슬랙을 벗어나지 않고도 ‘가장 합리적인 예약 가능 시간’을 추천받음으로써, 의사결정에서 실행(예약)까지의 리드타임을 획기적으로 줄였습니다. AI를 단순한 정보 제공자가 아닌, 복잡한 운영 예외(충돌/수정)를 처리하는 효율적인 운영 보조 인력으로 포지셔닝한 사례입니다.

05 · LEARNINGS

AI의 품질은 ‘모델’보다 ‘문제 정의와 예외 설계’에서 온다

이번 프로젝트를 통해 생성형 AI의 가치는 화려한 모델 성능보다, 실제 업무 현장의 복잡한 예외 처리(데이터 정합성, 일정 충돌 로직 등)를 얼마나 꼼꼼하게 설계하느냐에 달려 있다는 것을 체감했습니다. 이후 자동화 도구를 기획할 때도 ‘어떤 모델을 쓸까’보다 ‘사용자의 흐름 속에서 어떤 예외가 발생할까’를 먼저 고민하는 습관을 얻게 되었습니다.

01 · PROBLEM

대화 속에 흘러가 버리는 일정과 행정 부채

성우 녹음 일정은 외부 스튜디오와 가안 조율 후 Slack에서 사내 실무자들의 최종 확인을 받아 확정됩니다. 문제는 확정 이후, 제가 직접 Google Calendar를 켜서 수동으로 입력해야 외주 스튜디오 PM과 싱크가 맞는다는 점이었습니다. 여기에 대본 전달 같은 내용도 일정에 따라 직접 챙겨야 했기에, 이러한 행정 업무의 연쇄는 늘 심리적 부채이자 업무 흐름을 끊는 병목이었습니다.

02 · APPROACH

이모지 반응만으로 등록되는 마찰 없는 흐름

제가 수행하던 반복 업무를 시스템에 이관해, “확정 선언”이 곧 “데이터 등록”이 되는 직관적인 흐름을 설계했습니다. 슬랙 메시지에 이모지 반응 하나만 달면 날짜·캐릭터·시간 정보를 파싱해 Google Calendar에 자동 등록합니다. 또한, 일정에 맞춰 대본 등 필수 자료 전달을 개인 DM으로 재촉하는 리마인드 시스템을 구축하되, 버튼 토글식으로 보낸 자료는 다시 리마인드 오지 않게 하여 알림 피로도를 낮췄습니다.

03 · BUILD

실제 문제를 해결하는 핵심 기능

• Slack 메시지 이모지 반응 기반의 등록 트리거
• 자유형 텍스트에서 일정 데이터 파싱 — 성우·시간·캐릭터 등
• 외주 스튜디오 공유용 Google Calendar 등록·삭제 동기화
• D-Day 기반 리마인드 DM — 자료별 버튼 토글 체크리스트

04 · IMPACT

비정형 텍스트가 구조화 데이터로, 그 위에 후속 액션이 흐르다

슬랙에서의 “내부 확정”이 별도 작업 없이 “대외 공지”와 “사후 관리”로 직결되는 체계를 만들었습니다. 캘린더 복사-붙여넣기 같은 단순 반복 행정을 제거하고, 시스템이 마감 기한을 먼저 챙겨주어 에셋 누락 리스크를 차단했습니다. 도구 간 이동에 따르는 인지적 비용을 없애고, 본질적인 업무에 더 집중할 수 있는 환경을 스스로 구축했습니다.

05 · LEARNINGS

마찰 줄이기는 입력만이 아니라 후속 흐름까지의 문제

입력의 마찰만 줄여서는 사용자가 도구 안에 머물지 않는다는 걸 확인했습니다. 등록 이후의 리마인드와 체크리스트까지 같은 흐름 안에서 처리되어야 비로소 자동화의 가치가 완성됩니다. 서로 다른 도구를 사용하는 조직 간의 ‘브릿지 역할’을 자동화함으로써, 외부 조직과 제 개인의 리드타임을 함께 단축할 수 있었습니다.

01 · PROBLEM

버전이 생길 때마다 반복되던 보드 운영의 수작업 병목

라이브 서비스 운영에서는 새 버전이 생길 때마다 Jira Kanban 보드에 해당 버전용 스윔레인을 추가해야 했습니다. 이 작업은 단순해 보이지만, 여러 보드에 반복 적용해야 하고 누락 시 실무자들이 새 버전 기준으로 업무를 정렬하지 못하는 문제가 있었습니다. 특히 버전 추가는 주기적으로 발생하는데, 매번 Jira 보드 설정에 직접 들어가 이름을 만들고 JQL을 넣고 순서를 맞추는 과정은 운영 집중도를 떨어뜨리는 소모적 관리 업무였습니다.

02 · APPROACH

”새 버전 생성”이 곧 “보드 운영 반영”으로 이어지도록 설계

반복되는 보드 관리 작업을 사람의 기억이나 수동 대응에 맡기지 않고, 새 버전의 생성 자체를 트리거로 삼아 자동 반영되도록 만들었습니다. Jira의 버전 목록을 주기적으로 감시해 새 버전이 확인되면, 지정된 여러 Kanban 보드에 해당 버전용 스윔레인을 일괄 생성하는 흐름을 설계했습니다. 단순 생성에 그치지 않고, 이미 존재하는 스윔레인과 비교해 더 높은 버전만 추가되도록 하여 중복 생성이나 과거 버전 오염도 막았습니다.

03 · BUILD

실제 운영에 맞춘 핵심 기능 구현

• Jira 버전 목록 주기 감시 — 새 버전 자동 탐지
• 여러 보드 대상 스윔레인 일괄 생성
• 기존 스윔레인 조회 후 최신 버전보다 높은 경우에만 추가
• Puppeteer 기반 Jira UI 자동화 및 로그인 세션 유지
• 수동 실행 (node index.js 12.0.0) + 자동 감시 (npm run watch) 이중 지원

04 · IMPACT

버전 관리가 개인 작업이 아니라 시스템 반응이 되다

새 버전이 나올 때마다 사람이 Jira 보드 설정을 반복적으로 손보던 흐름을 제거했습니다. 그 결과 보드 운영 반영이 더 빨라지고, 여러 보드 간 적용 누락 가능성도 줄였습니다. 특히 업무툴의 관리성 문제를 사람의 꼼꼼함으로 해결하는 대신, 시스템이 먼저 반응하도록 바꾸면서 버전 단위 업무 정렬의 일관성을 확보했습니다. 작지만 자주 발생하는 관리 업무를 줄여 팀의 운영 리듬을 더 매끄럽게 만들었습니다.

05 · LEARNINGS

운영 자동화의 핵심은 기능 구현보다 ‘누락 가능성 제거’에 있다

이 작업을 통해 운영 자동화는 시간을 몇 분 아끼는 문제를 넘어서, 반복 업무에서 발생하는 누락과 편차를 구조적으로 제거하는 일이라는 점을 확인했습니다. 또한 Jira처럼 완전한 공개 API만으로 해결되지 않는 도구는 UI 자동화와 내부 API 활용을 함께 고려해야 실무적인 해법이 된다는 것도 배웠습니다. 결국 중요한 것은 거창한 시스템이 아니라, 팀이 반복적으로 겪는 작은 불편을 정확히 제거하는 자동화였습니다.

01 · PROBLEM

정립된 프로세스와 실제 현장 사이의 깊은 괴리

이전 콜라보 운영 회고에서 가장 두드러진 부채는 기존 프로세스와 실제 업무 흐름 사이의 깊은 괴리였습니다. 명문화된 절차는 있었지만 실제 작업물은 개인 로컬에, 피드백은 슬랙에, 일감은 Jira에 파편화되어 있었습니다. “최신 버전이 어디인가”라는 단순한 질문에도 도구 4개를 횡단해야 했고, 그 사이 IP 홀더의 핵심 피드백은 빠른 대화 흐름 속으로 휘발되곤 했습니다. 프로세스가 실제 업무 속도를 따라가지 못해 정보가 겉도는 상황이었습니다.

02 · APPROACH

한 화면에서 모든 컨텍스트가 종합되도록

도구를 늘리는 대신 도구 간의 다리를 놓아 괴리를 좁히는 방향을 택했습니다. ‘한 콜라보 = 한 화면’이라는 원칙 아래, 마스터 폴더(드라이브), 일감 필터(Jira JQL), 추적 채널(슬랙)을 단일 뷰로 응집시켰습니다. 리소스 행 옆에는 피드백, 슬랙 대화, Jira 하위 티켓을 한 클릭으로 호출하는 사이드 패널을 두어 컨텍스트 스위칭을 최소화했습니다.

03 · BUILD

실제 문제를 해결하는 핵심 기능

• 콜라보별 통합 셋업 — 탭마다 드라이브 URL / 슬랙 채널 / Jira JQL이 프리셋으로 묶여 자동 트래킹
• 실시간 협업 동기화 — Supabase Realtime을 활용해 동료의 변경 사항을 새로고침 없이 즉시 반영
• Jira 양방향 지능형 동기화 — 5분 폴링으로 상태·담당자 등을 동기화하되, 사용자가 편집 중인 항목은 충돌 방지를 위해 자동 스킵
• Jira 계층형 다중 매칭 — Epic-Task-Subtask 구조를 인식해 하나의 리소스를 여러 담당자(그래픽·사운드 등)와 연결하고 진행률을 자동 종합
• 슬랙 AI 자동 분류 — CF Worker와 Gemini가 30분마다 대화를 분석해 관련 리소스에 매칭. 오분류는 휴지통-복원 흐름으로 간편하게 정정
• IP 홀더 피드백 패널 — 피드백 발생-반영-최종 확인 단계를 체크박스로 추적. 듀얼 모니터 워크플로우를 고려해 별도 창 분리 지원
• 통합 대시보드 — 진행률, QA 검수 현황, 마감 임박 건, 미해결 피드백을 한눈에 조망

04 · IMPACT

흩어진 정보가 하나의 흐름으로 묶이다

도구 이동에 따르는 인지 비용이 제거되어, 운영자가 화면을 벗어나지 않고도 콜라보의 전체 맥락을 파악할 수 있게 되었습니다. 슬랙에서 휘발되던 IP 홀더 피드백은 영구 기록되어 누락이 사라졌고, AI가 관련 대화를 자동으로 행 옆에 모아주어 검색 비용을 획기적으로 낮췄습니다. 포스트모텀이 지적한 4대 액션 아이템(마스터시트 / 드라이브 / 히스토리 / 피드백 트래킹)을 단일 도구로 해결하여, 차기 콜라보에서 동일한 부채가 반복되지 않는 기반을 마련했습니다.

05 · LEARNINGS

도구는 데이터가 아니라 사람의 흐름을 따라야 한다

이번 작업은 “새 도구를 만든다”보다 “사람이 이미 일하는 방식 위에 데이터를 흐르게 한다”가 훨씬 중요하다는 점을 다시 확인시켜 줬습니다. 운영자는 한 콜라보를 운영할 뿐, 슬랙·드라이브·Jira·시트로 나누어 사고하지 않습니다. 그래서 도구를 더 추가하기보다 도구 사이의 다리를 놓아, 한 화면에서 컨텍스트가 자연스럽게 종합되도록 만드는 방향이 옳았습니다.

또한 AI 자동화는 통제 가능성이 핵심이라는 점도 체감했습니다. 모든 걸 한 번에 끝내는 일괄 처리보다, “사용자 트리거 + 결과 캐시” 흐름이 운영 안정성 면에서 훨씬 오래 살아남습니다. 오분류가 발생하면 사용자가 휴지통-복원으로 즉시 정정할 수 있는 안전장치를 함께 둬야 자동화가 무너지지 않는다는 점도 함께 배웠습니다.

결국 자동화의 진정한 가치는 데이터를 한곳에 모으는 것이 아니라, 사람이 도구를 의식하지 않고 본연의 업무에 몰입하게 만드는 것에서 완성된다는 점을 깨달았습니다.