비개발자로 회의봇 만들기는 처음이라

안녕하세요, 피플팀에서 GA 인턴으로 일한 지 3개월이 된 Mike예요.

저는 원래 작은 불편을 그냥 지나치지 못하는 편이에요. 예전에 한 매장에서 아르바이트하던 시절, 신규 직원 만족도 조사 결과를 보다가 의외의 사실을 발견했어요. "새로 맡은 업무가 어렵다"는 응답보다, "주변에 뭐가 있는지 몰라 점심시간에 식당 고르기가 힘들다"는 응답이 더 많았거든요. 첫 출근에서 가장 어려운 건 일이 아니라, 주변의 낯선 동네였던 거죠.

곰곰이 생각해보니 식당만의 문제는 아니었어요. 처음 온 동네라면 카페도, 약국도, 출근길도 모두 낯설 테니까요. 그래서 출근 루트 지도, 주변 맛집 리스트, 편의시설 안내를 담은 신규 직원용 키트를 직접 만들었어요. 누가 시킨 일은 아니었지만, 그 불편을 본 이상 그냥 지나칠 수 없겠더라고요. 며칠 뒤 한 신입 분이 "이거 없었으면 첫 주 내내 헤맸을 거예요"라고 말해주셨고, 그 키트는 정식 온보딩 프로세스에 포함됐어요.

이번에 사내 회의봇을 만든 일도 돌이켜보면 그 연장선이었던 것 같아요. 구성원분의 작은 불편을 그냥 두지 못하는 습관에서 시작된 일이거든요. 그 이야기를 지금부터 들려드릴게요.

좋아요, 일단 해보죠!

당근에 처음 와서 며칠은 오피스를 돌아다니며 구성원분들의 불편 사항을 점검하는 시간이 많았어요. 그러다보니 회의실 앞에서 자주 마주치는 장면이 있었는데요.

• 앞 회의가 길어져 문밖에 서 계신 분들
• 시간이 됐는데 예약자가 오지 않아 빈 채로 방치된 회의실
• 이름만으로는 회의실 위치를 몰라 복도를 헤매는 분들

며칠간 이 모습을 지켜보다가 '이걸 해결할 시스템을 직접 만들어볼 수 있지 않을까?' 하는 생각이 들었어요. 사실 처음엔 '인턴인 내가 혼자 시도해봐도 될까' 싶어 잠시 망설였는데요. 일단 팀 미팅에서 아이디어를 던져봤더니 "좋아요, 일단 해보죠"라는 경쾌한 답이 돌아왔어요. 그 한마디에 곧바로 회의봇 개발을 시작했죠.

본격적으로 만들기 전에 우선 레퍼런스부터 살폈어요. 다른 회사들이 만든 사내 회의봇 사례를 보면서 '우리도 당근만의 회의봇을 만들 수 있겠다'는 확신이 들었어요. 다만 그런 봇들이 공개될 당시에는 개발자의 손이 필수였더라고요. 몇 년 전이었다면 저도 혼자선 엄두를 못 냈을 거예요.

나는 코딩이랑 안 맞는 사람

저는 개발을 해본 적이 없어요. 고등학교 때 관련 전공을 잠깐 공부하긴 했지만 재미를 느끼지 못했거든요. 컴퓨터 앞에 혼자 앉아서 코드를 한 줄 한 줄 짜야 하는 방식이 저랑 안 맞았어요. 그때는 '나는 코딩이랑 안 맞는 사람이구나' 싶었죠.

그런데 당근에 와서 그 생각이 완전히 바뀌었어요. 옆자리에 앉은 같은 GA 팀 동료 Joy는 사내 자산 판매 시스템을 AI 툴로 직접 만들었고, Logan은 장비신청이 들어오면 직군이랑 보유 장비, 지급 가능 여부까지 자동으로 정리해주는 봇을 만들었더라고요. 저랑 같은 GA 직군의 동료들이 이미 클로드와 함께 일하는 게 일상이었죠.

피플팀 위클리 미팅 때도 비슷한 분위기였어요. 매주 팀원분들이 각자 클로드를 어떻게 쓰고 있는지, 어떤 걸 만들어봤는지 공유하고 인사이트를 나누거든요. 당근 올핸즈 미팅에는 'AI Show and Tell'이라는 세션도 있어요. 다양한 직군의 구성원분들이 각자의 AI 활용 사례를 공유하는 자리인데요. 사내에는 구성원들이 만든 자동화 도구를 한곳에 모아둔 위키도 있죠.

흔히 개발이라고 하면 검은 화면에 실시간으로 코드가 쌓이는 장면을 떠올리시잖아요. 저는 그런 '멋진 코딩'은 못 해봤고, 클로드와 메신저로 대화하듯 코딩했어요. 친구한테 말 거는 것처럼요. 시작은 이런 아주 기초적인 대화였어요.

• "구성원들이 회의 시간을 더 편하게 인지했으면 좋겠어"
• "회의 시작 5분 전에 슬랙으로 알림을 보내주는 기능을 붙이면 어떨까?"
• "회의가 있다는 걸 까먹은 사람에게 리마인드도 보내면 좋을 것 같아"

제가 생각한 기능을 하나씩 입력하면 그에 맞는 코드를 받을 수 있었고, 그 코드로 전사 캘린더의 회의 정보를 가져와 메시지를 구성했어요. 이렇게만 적으면 매끄러워 보일 수 있지만, 실제로는 전혀 그렇지 않았죠. 매번 예상치 못한 에러가 났어요. 에러 메시지를 그대로 복사해서 다시 물어보고, 해결 방법을 적용하고, 또 에러가 나면 다시 물어보고. 끝없이 반복했어요.

그래도 이전에 혼자 코딩할 때 느꼈던 막막함과 지루함은 없었어요. 대화하듯 문제를 풀어나갈 수 있었거든요. 다시 생각해보면, 저는 코딩이 싫었던 게 아니었던 것 같아요. 혼자 하는 방식이 저랑 안 맞았던 거죠.

당근 회의 당번, 당번이를 소개합니다!

이렇게 개발 경험 없이 도전한 저는 클로드와 함께 코드 첫 줄을 쓰기 시작해, 2주 만에 알파 버전을 배포할 수 있었어요. 그렇게 당근 회의 당번 '당번이'가 만들어졌어요.

당번이는 슬랙 DM으로 회의 참석자에게 시작 전 리마인드를 보내요. 어떤 회의인지, 몇 시부터인지, 어떤 회의실인지 한눈에 보이고, 버튼 하나로 참석 여부를 응답할 수 있어요. 사내에 회의실이 100개 가까이 있어서 위치를 몰라 복도를 헤매는 일이 잦았는데, 메시지 안에서 회의실 위치를 사내 오피스 맵으로 바로 확인할 수 있게 했어요.

마음에 들었던 기능 중 하나는 '회의실 당근하기'예요. 회의가 취소됐을 때 이 버튼 하나로 회의실 예약을 풀 수 있어요. 이전에는 캘린더에 예약만 잡혀 있고 실제로는 빈 회의실인 경우가 많았는데, 이제는 다른 팀이 바로 그 회의실을 쓸 수 있어요. 당근 앱에서 안 쓰는 물건을 이웃에게 나누듯, 안 쓰는 회의실도 나누는 거예요.

또 하나 욕심을 낸 건 '회의 매너온도'예요. 당근 앱의 매너온도를 회의에 가져온 기능인데요. 기본 36.5도에서 시작해서, 리마인드에 "갈게요"로 응답하거나 정시에 참석하면 온도가 올라가요. 미리 불참을 알려주면 더 많이 올라가고, 지각 호출을 당하면 내려가죠.

당번이의 매너온도는 30일 단위로 리셋되기 때문에 꾸준히 응답해야 온도가 유지돼요. App Home에서 자기 매너온도를 언제든 확인할 수도 있고요. 서비스의 결을 사내 도구에도 녹여보는 일이 의외로 재미있더라고요. "아, 나 온도 좀 내려갔네" 하고 다음 회의부터 응답 버튼을 누르게 되는 거니까요.

이 외에도 매일 아침 회의 일정과 오늘의 운세를 보내주는 브리핑, 지각자 호출, 회의 종료 5분 전 자동 연장 제안 같은 기능들이 있어요. 한 구성원분은 연장 버튼이 노래방 시간 연장 버튼 같다고 재밌어 하시기도 했죠.

기능만큼이나 캐릭터의 성격도 고민했어요. "회의가 있습니다"라고 알려주는 봇은 기존 슬랙의 구글 캘린더 앱이랑 다를 게 없잖아요. 당번이가 구성원분들에게 다가가려면 하나의 캐릭터처럼 말을 걸어야 한다고 봤거든요.

처음 작성한 당번이의 메시지를 팀에 공유했더니 돌아온 피드백은 "이거 너무 AI 말투 같아요"였어요. AI로 봇을 만들었더니 말투까지 AI스러웠던 거죠. 그 뒤로 팀원들의 피드백을 받으며 한 문장씩 다듬었어요. 딱딱한 안내 대신, 옆자리 동료가 말 거는 듯한 톤을 찾으려고 했어요.

내가 만든 봇이 전사에 혼란을 주고 있다니

2주 뒤, 이렇게 만든 당번이를 전사에 오픈했어요. 사내 AI 도구 위키에도 등록됐고, 뭔가를 처음 세상에 내놓은 경험이라 꽤 뿌듯했어요. 그런데 얼마 못 가 예상하지 못한 일들이 터졌어요.

오픈하고 며칠 지났을 때였어요. 한 구성원분이 당번이의 아침 브리핑에 제 개인 일정이 섞여 온다고 제보를 해주셨어요. "어…? 이게 왜 보이지?" 바로 확인해보니, 제 개인 캘린더 정보가 다른 구성원분의 회의 조회에 영향을 주고 있었어요. 순간 머리가 하얘졌죠. '내가 만든 봇이 전사에 혼란을 주고 있다'는 생각에 등에 식은땀이 흘렀어요.

원인을 파보니 서비스 계정 인증과 개인 계정 인증의 스코프가 분리되지 않은 게 문제였어요. 토큰을 분리하고 권한 범위를 제한해서 해결했고, 그 뒤로는 변경 사항이 생길 때마다 테스트 계정으로 먼저 검증하는 절차를 넣었어요. 서비스를 운영한다는 게 어떤 건지 그때 처음 감이 왔어요.

오픈하고 며칠 동안은 지표도 들여다봤는데요. 사용률이 영 올라오질 않더라고요. 당번이가 있다는 것 자체를 모르는 분들도 많았고, 알더라도 굳이 기존 습관을 바꿀 이유를 못 느끼는 분들도 있었어요. 처음엔 정공법을 택했어요. 슬랙 채널에 소개 글을 올리고, 당번이의 기능을 하나씩 보여주는 메시지를 썼죠. 그런데 생각만큼 사람들이 움직이진 않더라고요.

그래서 방식을 바꿔봤어요. 이미 당번이를 쓰고 있는 사람의 회의에 아직 연동하지 않은 분이 섞여 있으면, 그분에게도 리마인드를 보내면서 '당번이와 연동하기' 버튼을 함께 띄워주는 방식이었어요. 당번이가 이미 다른 회의에서 쓰이고 있다는 걸 자연스럽게 경험하게 한 거예요.

부담스러울 수 있으니 '알림 안 받기' 버튼도 같이 넣었고요. 이 방식이 생각보다 반응이 좋았어요. 지금 당번이는 당근 전체 구성원의 절반 이상인 251명이 연동해서 쓰고 있고, 매일 평균 400건의 리마인드가 나가요. 매너온도 최고 기록은 39.4도예요. 누군지는 비밀이지만요.

이 과정에서 배운 게 있어요. 기능을 만드는 것과 사람들이 실제로 쓰게 만드는 건 완전히 다른 일이라는 거였죠. GA 인턴인데 개발을 하고, 개발을 했더니 홍보를 하고, 홍보를 했더니 PM이 되어 있더라고요. 경계 없이 일한다는 게 이런 뜻일까 어렴풋이 알 것 같았어요.

피플팀의 일이란 뭘까요?

당번이를 만들고 나서 GA 업무 곳곳에서도 같은 방식으로 자동화를 시도해봤어요. 하나를 해보니 다른 것도 해보고 싶어지더라고요. 신규 입사자 장비 배정을 자동으로 연동했고, 지원자가 도착하면 채용운영 담당자에게 슬랙 알림이 가는 체크인 플로우를 혼자 만들어보기도 했어요. 퇴사나 복직 때 후속 업무를 자동으로 트래킹하는 봇도 제작했죠. 전부 ‘이거 좀 불편한데?’ 하는 사소한 순간에서 시작된 일들이에요.

가끔은 제가 인턴이라는 걸 잊을 때도 있어요. 스스로 문제를 발견하고, 해결 방법을 제안하고, 직접 만들어 운영까지 하다 보면요. ‘나는 코딩이랑 안 맞는 사람’이라고 선을 그어두었던 당근 합류 전의 저를 떠올려보면 그 선을 만든 건 코딩이 아니라 제 자신이었다는 생각도 들어요.

피플팀의 일이란 뭘까요? 어떤 곳에서는 구성원의 경험을 설계하는 일이라고 하고, 어떤 곳에서는 조직의 성장을 돕는 일이라고 해요. 그런데 저는 이번에 사내 회의봇을 만들면서 조금 다른 답을 찾게 됐어요. 회의실 앞에서 기다리는 분을 보고 봇을 만든 일도, 비어 있는 회의실을 다른 구성원에게 연결한 기능도, 결국 누군가의 불편을 그냥 지나치지 못하는 같은 마음에서 시작됐다는 걸요.

피플팀이 서비스를 직접 만드는 직무는 아니라고 생각할 수도 있어요. 하지만 저는 당근 구성원 한 분 한 분이 곧 사용자라고 생각해요. 회의실 앞에서 기다리던 분을 보고 회의봇을 만들기로 결정한 것도, 캘린더가 꼬여 식은땀 흘리던 것도, 사용률이 낮아 고민하던 시간도 모두 구성원이라는 사용자가 있었기에 생긴 일이니까요. 그래서 저는 이렇게 답해보고 싶어요.

피플팀의 일은, 구성원이 더 몰입해서 일할 수 있도록 불편을 발견하고 지나치지 않는 일이라고요.