뭐가 더 급한지 고민하다, 귀한 시간을 다 흘려보냈습니다. (ft. DX Request)

Photo by ostudio

솔루션을 개선한다는 이유로 고객님들을 불편하게 해드릴 때마다 늘 마음에 부채감을 안고 지내고 있습니다.

MIRA의 솔루션은 아직도 갈 길이 멉니다. 오늘도 GP와 LP로부터 새로운 개선 요청이 들어오고, 예상하지 못한 오류를 발견하기도 하며, 더 좋은 서비스를 위한 아이디어도 끊임없이 제안받습니다.

MIRA의 DX본부는 그 요청들을 하나씩 정리하고, 우선순위를 고민하며, 매일 조금씩 더 나은 서비스로 만들어가고 있습니다.

그 과정에서 VC본부 매니저분들로부터 하루에도 여러 번 이런 메시지를 받았습니다.

“바쁘신데 죄송합니다, 급한 건인데 확인해봐주실 수 있으실까요?” 데이터 추출도 급했고, 데이터 오류도 급했고, 새로운 기능도 급했습니다.

세상에 급하지 않은 일은 없는데, 어떤 일이 더 급한 일일까요?

미안함만 남고 보람은 없는 업무 처리 구조

DX본부에는 하루에도 수십 건의 요청이 슬랙을 통해 들어왔습니다.

누가, 언제 처리할지, 무엇을 먼저 해야 할지, 늘 허둥댔습니다.

그러다 보니 때로는 업무를 놓치는 일도 생겼고, 같은 요청을 여러 사람이 동시에 처리하기도 했으며, 처리를 끝내고도 요청자에게 회신하지 못함으로 인해 요청자는 내내 처리를 기다리는 경우도 발생하곤 했습니다.

그 중 가장 마음이 쓰이던건 늘 미안해하며 업무를 요청하던 동료들의 첫마디였습니다. “바쁘신데 죄송한데요…”

업무를 요청하는 사람은 미안했고, 업무를 받는 사람은 지금과 같은 상황이 더 미안했습니다.

업무가 많아서 힘들다기 보다, 무엇부터 해야 하는지 몰라서 힘들었습니다.

슬랙에는 새로운 요청이 계속 올라오고, 이미 진행 중인 업무도 있었고, 개발 중인 기능도 있었습니다.

그 안에서 담당자는 하루에도 수십 번 같은 고민을 반복했습니다.

지금 이걸 먼저 해야 하나? 아니면 저 요청이 더 급한가? 혹시 내가 놓친 요청은 없을까?

결국 문제를 해결하는 데 집중하기보다, 무엇부터 해야 할지를 결정하는 데 더 많은 에너지를 쓰고 있었습니다.

급하다고 여러번 재촉하는 건이 우선순위가 되다보니 정말 중요한 일이 뒤로 밀리는 일도 반복되었습니다.

뭐가 문제인지 알아도 할 수 없던 일

사실 프로세스는 오래 전부터 만들고 싶었습니다.

하지만 늘 같은 벽에 부딪혔습니다. 결국 프로세스를 잡더라도 지켜야하는 것은 사람이였으니깐요.

슬랙을 보며 업무를 등록하고, 담당자를 지정하고, 진행 상태를 업데이트하고, 요청자에게 결과를 공유하는 일까지 모두 사람이 직접 해야 했기 때문입니다. 바쁠수록 가장 먼저 생략되는 일은 기록과 공유였습니다.

업무는 처리했지만 기록은 남지 않았고, 기록이 없으니 관리되지 않았으며, 처리했는데도 요청자는 진행 상황을 알 수 없었습니다.

그러던 중 Claude를 만나게 되었고 사람이 반복적으로 해야 했던 기록과 전달을 AI가 맡아준 덕분에 오랫동안 머릿속에만 있던 업무 처리 구조를 실제로 운영할 수 있게 되었습니다!

DX Request는 이렇게 동작합니다.

이제는 #dx본부-request 채널에 메시지가 올라오거나,어느 채널에서든 DX 이모지를 달면 요청이 자동으로 접수됩니다.

AGENT는 요청 내용을 읽고 노션의 DX Request DB에 업무를 등록합니다.

담당업무에 따라 TASK는 담당자에게 등록되며 담당자는 등록된 업무를 다음 네 가지 중 하나로 분류합니다.

오류 수정 : 고객 불편을 빠르게 해결해야 하는 업무
개선 백로그 : 필요하지만 다음 개선 주기에 반영할 기능
ISSUE : 여러 사람과 일정 관리가 필요한 프로젝트성 업무
DX 숙제 : 방향은 맞지만 지금 당장 시작하기에는 이른 아이디어

어떤 형태로 분류되더라도, 처리 결과는 다시 요청자의 슬랙 스레드에 자동으로 공유됩니다.

이제 요청자는 진행 상황을 따로 물어보지 않아도 되고, 담당자는 처리 결과를 잊지 않고 전달할 수 있게 되었습니다.

AI 덕분에 ‘신뢰’를 쌓을 수 있는 기반이 생겼습니다.

DX Request를 운영하며 얻게 된 가장 큰 장점은 “요청사항 놓치지 않고 책임지겠습니다.”라는 약속을 할 수 있다는 겁니다.

첫째,

더 이상 요청이 슬랙 대화 속으로 묻히지 않을꺼라는 믿음을 줄 수 있게 되었습니다. 모든 요청은 자동으로 기록되고, 변경된 상태는 등록자들에게 전달됩니다.

둘째,

우선순위가 명확해졌습니다. 오류는 바로 수정하고, 개선은 백로그에 쌓고, 프로젝트는 ISSUE로 관리하고, 아직 시기가 아닌 아이디어는 DX 숙제로 남겨두었습니다. 덕분에 담당자는 더 이상 “오늘은 무엇부터 해야 하지?” 를 고민하지 않게 되었습니다.

업무의 우선순위를 판단하는데 쓰던 에너지는 문제를 해결하는 데 사용할 수 있게 되었습니다.

셋째,

요청하는 사람도 받는 사람도 심리적 부담이 크게 줄었습니다. 요청이 오는대로 마음이 쓰여서 집중하지 못했던 시간들이 많이 줄었습니다. 요청하는 사람도 상대방이 느끼는 부담이 덜하기에 마음편히 요청할 수 있게 되었습니다.

63번의 커밋이 쌓이는 동안

DX Request의 GitHub 저장소에는 지난 석 달 동안 63번의 커밋이 쌓였습니다.

동료들의 피드백을 듣고, 수정하고, 다시 사용해 보고, 또 고쳤던 과정의 기록입니다.

2026년 4월 — 받아 적는 것부터 (5 commits)

첫 번째 커밋은 슬랙 메시지를 노션에 등록하는 기능이었습니다.

사흘 뒤에는 등록일과 완료일을 추가했고, “내일까지”, “다음 주” 같은 자연어 기한도 이해하기 시작했습니다.

2026년 5월 — 죽지 않는 AGENT 만들기 (2 commits)

스스로 다시 살아나는 Watchdog 기능을 추가했습니다.

2026년 6월 — 시행착오의 달 (21 commits)

사용자가 늘면서 예상하지 못했던 예외가 쏟아졌습니다. 기한 인식 방식을 다시 설계했고, DX 이모지 하나만으로 어느 채널에서든 요청을 접수할 수 있도록 개선했습니다.

2026년 7월 — 조금씩 생각하는 AGENT가 되다 (35 commits)

이제는 로컬 LLM이 요청 내용을 읽고, 제목을 추천하고, 업무 유형을 분류하며, 중복 요청을 찾아내고, ISSUE와 DX 숙제를 자동으로 등록하기 시작했습니다.

월별 커밋 수는 5 → 2 → 21 → 35로 점점 늘어나고 있습니다. 그만큼 DX Request도 동료들의 피드백을 통해 성장하고 있다는 사실을 실감하고 있습니다. 무엇보다 AI의 가장 큰 장점은 일단 만들어보고, 실제 사용자의 피드백을 바탕으로 빠르게 개선해 나갈 수 있다는 점이라고 생각합니다.

그리고 아마 64번째 커밋도, 누군가의 작은 불편에서 다시 시작될 것입니다.