‘데브렐’ 직무를 맡은 뒤 내게는 사소한 습관이 생겼다. 사소한 것 하나하나에까지 이유를 붙이는 습관이다. ‘그냥’이라는 것은 납득하기 어려웠다. 이유와 근거가 있어야 했다. 2023년 끝자락을 마무리한 사내 해커톤 ‘9oormthon RAID WINTER’도 예외는 아니었다. “생성형 AI로 업무 효율성을 높이자”라는 주제는, 조직 방향성만을 고려한 건 아니었다. 평소 소홀했던, 조치하지 못하고 미뤄만 뒀던 우리 곳곳의 비효율성을 개선하고, 이를 계기로 ‘비효율성’에 관심을 갖고 지속적으로 개선하는 ‘변화’의 시작이 되었으면 하는 바람이 컸다.
3개월이 지난 지금, 문득 그 뒷이야기가 궁금했다. 의도대로 우리 주위의 비효율성에 더 관심을 갖게 되었을지, 구성원 개개인에게 어떤 변화가 생겼는지, 성장에는 어떤 도움이 됐을지 궁금했다. 그래서 해커톤 참가팀의 하나인 ‘러시안 룰렛Russian Roulette’의 3인에게 기고를 부탁했다. 해커톤의 결과물과 이후의 변화에 대한 이야기를 부탁했다.
by snow, jade, jhin, philip
편집자 주_ 기고를 인터뷰 형식으로 재편집해 전하는 점을 알립니다.
러시안 룰렛은 GEN AI SQD의 AI 엔지니어 진Jhin, EDU 풀스택 엔지니어 제이드Jade와 EXP 풀스택 엔지니어 필립Philip으로 구성된 팀이다. 진이 기획과 프롬프트 엔지니어링을, 제이드와 필립이 백엔드 개발을 맡았다. 7개 참가팀 중 유일하게 고객 서비스Customer Service, CS 문제를 들고 나서 유독 내 기억에 남았었다.
구름의 대표 서비스는 다섯 종에 이른다. CS 채널도 유선, 이메일, 채널톡 등 다양하다. 기업 고객에서 일반 고객까지 고객의 폭까지 넓다. CXCustomer eXperience 매니저가 이 모두를 담당하긴 쉽지 않다. 그래서 조직별로 매일 또는 주 단위로 구성원 중 CS 담당자를 정해 운영하고 있다. CX 매니저가 아닌, 제품 개발자가 CS 대응을 맡는 식이다. 소수의 CX 매니저가 CS를 다 맡기 어렵다는 현실적인 이유도 있지만, 그보다는 개발자가 고객의 불편과 요구를 직접 듣고 이런 의견을 제품 개발에 반영하는 ‘제품 중심’의 서비스로 발돋음하기 위해서였다.
의도와 달리 문제가 없진 않았다. 전담 담당자가 없다 보니 오늘 CS 당번이 누구인지 찾아야 했다. 제품과 비즈니스가 복잡하게 연결되어 있어 어느 팀에 CS를 전달해야 하는지 알기 어려운 경우도 종종 있다. 각 SQD마다 CS 운영 제도, 방식이 달라 해당 문의가 처리됐는지 알기 어렵고, 과거 히스토리는 어떻게 확인해야 하는지도 달랐다. 문제임을 알지만 애써 외면하며 지나쳤던 그 문제를 ‘러시안 룰렛’ 팀이 해결하겠다고 나섰다.
러시안 룰렛 팀 3인
Gen AI SQDsquad 1에서 AI Engineer로 근무하고 있어요. 기획자로서 이번 해커톤에 참여했고, 프로젝트의 전체적인 기획과 ChatGPT를 사용하기 위한 프롬프트 제작을 맡았습니다. 여태까지는 DEVEL SQD 분들과 주로 협업했는데요. 이번 기회에 다른 SQD 동료와도 일해보고 싶어서 해커톤에 참가했습니다. AI 서비스는 보통 긴 호흡으로 진행되는데, 해커톤처럼 제한된 시간 안에 결과물을 만들어내는 경험도 해보고 싶었어요.
‘업무를 게임처럼 관리하는 구름EXP’를 개발하는 EXP SQD에서 풀스택 엔지니어로 일하고 있어요. 아는 것을 모두와 나누는 것과 효율화에 관심이 많아요. 구름에 입사한지 아직 1년이 안 됐는데, 저도 다른 구르미와 함께 일하며 친해지고 싶어 해커톤에 참가했어요.
EDU SQD에서 풀스택 개발자로 일하고 있어요. EDU SQD는 비즈니스 특성상 CS 유입이 많아요. 평소 CS를 일원화할 봇이 있으면 좋겠다고 생각했는데, 이를 구현할 절호의 기회라 해커톤에 참여했어요. SQD 내 기획자, PM 등과 CS에 대해 이야기하며 어떤 어려움이 있는지 조사하며 해커톤을 준비했어요.
Q. 이름이 섬뜩해요. 왜 러시안 룰렛인가요?
진_ 러시안 룰렛은 장탄수가 6개인 리볼버 권총에 총알 한 발을 넣고 참가자가 서로 돌아가며 자기 머리에 총구를 대고 방아쇠를 당기는 게임입니다. 군인이나 범죄자들이 자신의 용기를 보여주기 위해 행했다고 하죠. 이 무서운 게임이 끝나려면, 누군가는 총알에 맞아야만 합니다. 즉, 죽어야 끝나는 게임인 거죠.
구름의 ‘CS가 이대로 가면 언젠가 리볼버의 총알이 발사되는 것’과 같은 일이 벌어질지도 모른다는 생각에서 팀 이름을 러시안 룰렛으로 지었습니다. 구름이라는 하나 안에 있지만 서로 다른 제품, 서비스라는 이유로 모두가 무관심했고, 해결을 미뤄왔던 CS의 처리, 관리 프로세스를 개선하는 게 저희의 목표였습니다.
Q. CS 아이디어는 누가 처음 꺼냈나요?
제이드_ 사실 저희 EDU SQD는 외부에서 유입되는 CS가 많은 편이에요. 해커톤 참가 전부터 CS가 제 고민의 하나였어요. 평소 같은 SQD의 기획자, PM과 CS 문제에 대해 이야기를 나누곤 했어요. 제가 해커톤에 참여하기로 결심한 이유도 CS를 개선해 보고 싶어서였죠. 아이디어는 제가 꺼냈지만, 우리 모두 함께 아이디어를 고민하고 개발했어요. 다른 팀은 기획을 마치고 구현하고 있던 밤 10시 무렵까지 우리는 여전히 기획을 했을 만큼 기획에 심사숙고했었죠.
Q. CS 대응에 어떤 어려움이 있던가요?
제이드_ 한쪽의 입장만 반영해서는 안 됐어요. 우리 모두의 의견을 듣는 게 먼저였어요. 그래서 설문조사를 진행했죠. CS 처리에 어떤 어려움이 있는지, 어떻게 개선되면 좋겠는지, CS 담당자뿐 아니라 CS를 체험한 구성원의 의견을 들었어요.
가장 큰 문제는 CS를 담당하는 CX 매니저가 VoCVoice of Customer 리포트를 쓰는 데 어려움이 많다는 점이었어요. CS 기록이 어디로 유입됐고, 어떻게 처리됐는지 등의 정보를 수집하는 데 상당한 시간이 걸렸어요. 반면, CS를 처리하는 개발자는 슬랙에서 이전 히스토리를 찾아 대응하는 데 어려움을 컸어요. 결국, CS 유입 경로, 문의 내용, 대응 방법, 처리 여부 등의 히스토리를 DB에 잘 쌓는 게 관건이었어요.
진_ 정리하면요. SQD, 팀 등 관리 주체마다 CS 프로세스가 제각각이었어요. 다 다른 CS 처리 관리, 기록 방법을 가지고 있었죠.
그렇다 보니 개발자는 개발자대로,
- CS 히스토리를 찾기 어려워요.
- 다른 스쿼드 CS 담당자가 누군지 모르겠어요.
- 급한 일인데 업무시간이 아닐 때는 CS 처리를 요청하기 부담스러워요.
- 급한 일이 있어서 잠시 미루다가 까먹었어요.
- 어느 스쿼드에 전달해야 할 지 모르겠어요.
CX 매니저는 CX 매니저대로,
- 담당 제품/사업이 아닌 경우 담당자 찾기 어려워요.
- 히스토리 관리, 공유의 필요성이 점점 늘어나는 걸 느껴요.
- CS 데이터를 가공하는 시간이 많이 걸려 VoC 리포트 발행이 지체되곤 해요.
이러한 어려움을 토로했어요.
Q. CS 프로세스를 어떻게 바꿨나요?
제이드_ 크게 세 가지 측면에서 CS 프로세스를 개선했어요. CS 분배, 처리, 히스토리에요.
CS 분배와 관련해서는 외부 채널에서 CS가 유입되면 CX 매니저는 CS 채널에서 슬랙봇을 멘션하고 문의를 남겨요. ❶슬랙봇은 키워드를 자동으로 분류해 담당 SQD를 찾고 배정하죠. 그러면 해당 SQD의 CS 담당자에게 멘션이 가요. ❷CS 담당자는 슬랙봇에서 [CS 대응 시작하기] 버튼을 누르고 CS에 대응하는 식이에요. ❸대응 과정에서 이전 히스토리를 보고 싶으면 [히스토리 분석하기]를 눌러 유사한 CS 대응 방법을 볼 수 있죠. CS 대응이 끝난 뒤에는 [대응 완료]를 눌러 CS 처리를 마무리하도록 만들었어요.
물론 CS 유형에 따라서는 CX 매니저가 직접 처리할 수도 있고요. CSV 파일로 저장하는 기능도 넣었어요. 이건 주간, 스프린트 단위로 CX 매니저가 발행하는 VoC 리포트 작성의 어려움을 해소해주기 위해서였어요.
Q. 어려운 점은 없었나요?
필립_ 슬랙봇 개발이 처음이라 조금 어려웠어요. 슬랙 볼트 SDK에 적응하는 데 시간이 좀 걸렸죠. 이점이 아쉬웠어요. 조금 더 빨리, 잘 했다면 더 좋은 결과물을 만들 수 있었을 거에요. 슬랙봇 개발에서는 특히 유저 플로우를 많이 고민했어요. CS 슬랙봇이 어떻게 CS를 분배하고, 담당자에게 배정할지를 정하는 데 많은 시간이 걸렸죠.
진_ 원래 전공(?)은 자연어 처리 분야에요. 구름에서 ‘비전’도 다뤘지만, 자연어 처리가 본업(?)이라고 할 수 있죠. 챗GPT API는 이번에 처음 사용해봤어요. 똑똑하지만, 원하는 답을 주진 않더라고요. 원하는 답과 유사한, 근사치만 줄뿐 정확히 원하는 답은 아니었어요. 서비스를 운영하려면 정확한 답이 필요해요. 대답의 일관성을 확보하는 게 어려웠어요.
Q. 저도 몇몇 LLM을 써봤는데 그 부분이 어렵더군요. 혹시 어떻게 해결했나요?
진_ ChatGPT를 써본 분은 알겠지만, 같은 요청에도 같은 결과를 주진 않아요. 이게 장점일 때도 있지만 슬랙봇처럼 정해진 답변의 틀이 필요한 경우는 문제가 돼요. 결과의 일관성을 위해 다음 두 가지 방식을 고안했어요.
결과 형식 정해주기
먼저 input과 output 예시를 미리 정해주는 few shot learning 방법을 사용했어요. 그 덕분에 정해진 input 값이 입력되면 정해진 형식으로 output 값이 나와요.
{
role: 'user',
content: `판별해야할 입력은 다음과 같아. 입력: ${targetMessage}category: `,
},
{
role: 'user',
content: `요약할 입력은 다음과 같아. 질문: ${question} \n 답변: ${sampleAnswer} \n 참고자료: ${additionalData} \n요약문: `
}
temperature 값 낮추기
temperature 값을 낮춰 답변의 일관성을 높였어요. temperature 파라미터은 얼마나 창의성을 부여할지와 관련이 있어요. 값이 높으면 더 창의적이고 다양한 답변을 내놓고, 반대로 낮으면 일관되고 예상 가능한 답변을 하죠.
그밖에도 프롬프트 작성 시 몇 가지를 더 고려했어요.
키워드
구름은 여러 서비스를 운영 중이기 때문에 CS가 다양해요. 서로 관련이 없어 보이는 CS도 같은 담당자가 처리해야 하는 경우도, 반대로 유사한 CS 문의지만, 각각 다른 담당자가 처리해야 할 때도 있어요. 그래서 단순한 few-shot learning 방식으로는 충분한 품질의 결과를 얻기 힘들었어요. (물론 few-shot learning용 데이터를 더 많이 구축하면 품질을 높일 수 있지만, 해커톤이란 한정된 시간에 하기는 어려웠어요.)
그래서 각 서비스별 주요 키워드를 미리 추출하고, 서비스별 키워드와 CS 문의에서 추출된 키워드를 비교하는 사고 과정을 프롬프트에 추가했어요.
{
role: 'system',
content: `
Task: 너는 주어지는 입력이 어떤 category에 속하는 지 분류해줘.
범위는 총 6개야. 각각에 대한 설명과 주로 관련된 키워드를 알려줄게.
주어진 입력에 관련된 키워드가 있는지를 중심으로 생각해.
category: EXP
설명: 학생-사원을 평가, 관리하거나 게이미피케이션을 통해 구성원의 역량을 증진하는 플랫폼이며 입력에 exp 키워드가 포함된 경우 대부분 exp관련 category
키워드:상점, exp, 기프티콘, 학습계획, 구름조각, 캠페인, 퀘스트, 피니싱, 포커, 조직도, 스탠드업, 출석체크, 칭찬하기, AI구르미, 피드백, 배움일기
category: IDE
설명: 클라우드 IDE 서비스 운영을 하며 세세한 코드 보다는 컨테이너 서비스 운영에 중심을 둔 플랫폼
키워드: container, IDE, ide, gpu, 컨테이너, 도메인, 환불, 할인, 항상, 켜두기, 동면해제, 로딩, 팀플러스
category: EDU
설명: 학생 강의-강좌 플랫폼
키워드: edu, 채점기준, 재채점, 채점, 군장병, 수업, 강의, 채널, 강좌, 수료증, 학교, 학생, 강의자, 강사, 교사, 초대
category: DEVEL
설명: 학생이나 취업자, 사내 실력 점검을 위한 테스트와 시험을 진행하고 프로그래밍을 연습 할 수 있는 플랫폼
키워드: devel, 뎁스, devth, 레벨, 데벨, 코딩테스트, 테스트, level, 옵져뷰, 채용, 문제, 시험, 퀴즈, 코드프로, codepro, 응시자, 감독, 시험실, obserview, 코딩, 프로그래밍
category: SRE
설명: 사내 개발, 서비스 서버 유지 보수
키워드:git, sre, 로그, proxy, 이미지 삭제, apm, 배포, 파이프라인, Nginx, aws, gcp, 도메인 삭제, 리전, 메모리, 롤백, block, ssh
category: NONE
설명: 위 5가지 category에 속하지 않는 경우
각 category의 설명과 키워드를 바탕으로 생각해서 차근차근 생각해서 분류해줘.
답변은 위의 6가지 category로만 답해야하고 어떤 category인지 대답 해줘. 설명은 필요없어. category name만 대답해줘.`,
}
빠르게, 더 빠르게
슬랙봇 개발에서 중요하게 생각한 것의 하나는 ‘속도’였어요. 슬랙봇의 답변을 듣기까지 오래 걸리면, “차라리 다른 쓰는 게 낫지 않을까?”라고 생각할 테니까요. 그래서 GPT 4 대신 GPT 3.5를 썼어요. 성능은 상대적으로 낮지만 최적화가 잘되어 있고 응답도 빠르거든요.
임베딩
키워드를 추출하는 등의 모든 처리를 ChatGPT가 하는 건 아니에요. 과거의 모든 CS 히스토리와 현재 CS 문의 내용을 ChatGPT에게 주고 처리하기에는 토큰이 너무 많이 비싸요. CS가 점점 늘어난다면 결국, ChatGPT가 허용하는 최대 입력 토큰 수를 넘어설 가능성도 있고요.
그래서 CS를 처리할 때마다 DB에 CS의 임베딩 값을 저장하도록 설계했어요. 유사한 CS 히스토리를 검색할 때 임베딩의 유사도로 검색하는 방식을 이용했어요. ChatGPT를 이용했을 때보다 더 빠르고 정확한 답을 얻을 수 있었죠.
from sentence_transformers import SentenceTransformer
model = SentenceTransformer("jhgan/ko-sroberta-multitask")
def return_embedding(sentence):
return model.encode(sentence)
@app.post("/return_embedding/")
async def return_embedding_api(sentence: str):
processed_sentence = return_embedding(sentence)
return {"processed_sentence": processed_sentence.tolist()}편집자 주_ 사용한 임베딩 모델은 SentenceTransformer의 jhgan/ko-sroberta-multitask입니다.
Q. 파인튜닝은 하지 않았나요?
진_ ChatGPT를 사용는 방법에는 여러 가지예요. 데이터로 ChatGPT의 모델을 파인튜닝하고 개선한 모델을 사용하는 방법, 혹은 프롬프트만 사용한 Zero-shot, few-shot learning 방법 등이 있어요. 평소였다면 이런 여러 방법을 두고 고민하고 테스트하며 가장 효과적인 방법을 찾았을 거예요. 다만 이번엔 그러지 않았죠.
파인튜닝을 하면 더 높은 성능을 얻을 수 있지만, 시간이 한정된 해커톤에는 적합하지 않다고 판단했어요. 파인튜닝을 위해서는 반복적인 테스트가 필요하기 때문이에요.
Q. CS 슬랙봇을 지금도 쓰고 있나요?
제이드_ 가장 아쉬운 점이 그점이에요. CS 슬랙봇은 저희가 짧은 해커톤 기간에 아이디어를 내 만든 결과물이에요. CS 관련 분들의 모든 의견을 반영하거나 동의를 얻고 만든 건 아니에요. 이걸 사용하기 위해서는 관련 분들을 설득하고, 테스트하는 노력과 시간이 필요하죠. 또 CS 채널에서 테스트하기에는 CS 문의가 많고 관련 사람들도 많아 혼란스러울지도 몰라 아직 적용하지 못 했어요. 올해 안에는 전사는 아니더라도 EDU SQD만이라도 CS 슬랙봇을 꼭 적용해 보고 싶어요.
Q. 해커톤 참가 이후의 이야기가 궁금해요. 어떤 변화가 있었나요?
진_ 더 넓게, 더 크게 생각하게 된 것 같아요. 생각이 넓어졌다고 할까요? 해커톤 이후 다양한 아이디어가 많이 떠올랐어요. 아무래도 직접 써보고 경험해본 것이 도움이 됐어요. 예를 들면 어떤 데이터를 ChatGPT로 처리할 때 전에는 먼저 데이터를 보관하고 빠르게 꺼내오는 식의 임베딩을 생각해보지 않았는데, 이런 처리 방식에 대해 한번 더 생각하게 됐어요.
필립_ 전 낯을 많이 가리는 내향적인 성격인데, 해커톤 이후 사람에게 다가가는 게 조금은 편해진 것 같아요. 진과는 처음 일해봤는데, AI 엔지니어는 다르다는 걸 많이 느꼈어요. 제가 프롬프트를 작성할 때는 원하는 답을 잘 얻지 못했는데, 진이 쓰는 걸 보니 LLMLarge Language Model도 쓰기 나름인 것 같아요. 해커톤 이후 구름과는 관련이 없지만, 개인 프로젝트에 ChatGPT를 사용해봤어요. 자기 소개서를 기반으로 면접 질문을 뽑아주는 서비스인데, 진의 프롬프트가 많은 도움이 됐어요.
제이드_ 평소 만나 이야기하기 힘든 타 조직 분들과 협업한 게 가장 좋았어요. 슬랙봇을 만들어본 경험이 없고, 관련 코드를 본 적도 없어 조금 헤맸는데, 필립이 잘해줘서 도움을 많이 받았어요. 슬랙 볼트처럼 평소 써보지 않은 새로운 것을 써보며 배웠다는 점도 좋았어요. 무엇보다 평소 불편하게 느끼던 것을 이번 기회에 깊이 생각해보고 해결책을 만들어볼 수 있었다는 점이 좋았어요.
편집자 주_ 성장은 수치화하기도, 스스로 느끼기도 어렵다. 사람은 일정한 기울기로 성장하는 게 아니라 계단식으로 성장하기 때문이다. 그래서 한 계단을 올라서기 전에는 성장을 깨닫기 어렵다. 그렇기에 주위에서 ‘나’를 지켜봐주고, 나의 성장을 이야기해줄 동료가 필요하다. 우리가 꾸준히 성장하기 위해서는, 지식을 함께 나누고 서로 다른 의견으로 충돌하기도 하고 서로 부대끼며 ‘함께’해야 한다.
사내 해커톤은 그러한 구성원의 ‘성장’을, 그리고 ‘개발 문화’를 더 나은 쪽으로 변화시키기 위해 시작됐다. 비즈니스적 새로운 아이디어를 얻는 장이 되어 주기도 한다. 물론, 가시적인 성과가 바로 드러나는 일은 아니다. 비용도 적지 않게 든다. 하지만 서로 협업한 적 없는 다양한 직무의 사람들이 모여 ‘함께’ 머리를 맞대고 문제를 풀어가는 과정과 경험 속에서 우리는 성장하고, 우리의 성장이 곧 회사의 성장으로 이어질 것을 알기에 사내 해커톤을 연 2회 개최하고 있다.
2023년 처음 사내 해커톤을 시작한 이후 구름에도 작은 변화가 생겼다. 2회에 걸쳐 주제로 다뤘던 ChatGPT 사용 경험이 조직으로 확산되며 최근 다양한 분야에서 생성형 AI 사용이 부쩍 늘었다. ‘해커톤 또 언제 하냐’고 묻는 구성원도 생겼다.
러시안 룰렛 3인의 CS 슬랙봇이 아직 내부 CS에 적용되진 못 했지만, 적어도 이번 해커톤이 우리가 가진 CS상의 문제에 대해 다 함께 생각해보는 계기가 됐다. 이러한 비효율성을 개선하고자 하는 의지를 가진 구성원이 있는 한, CS의 여러 문제는 점차 개선될 것이다. 사내 해커톤이 가져온 변화는 지금도 계속되고 있다. ☁️
편집자 주_ 기술 블로그에 CS 뱅을 소개한지 며칠이 지나지 않아 반가운 소식이 들려왔다. CS 뱅 슬랙봇을 정식 도입하기 위한 논의가 시작됐다는 소식이었다. CS 뱅 슬랙봇이 CS 프로세스로 정착되고, 어떤 변화를 일으켰을지 차후 그 뒷이야기를 다시 다뤄보겠다.
- SQD는 조직의 한 형태로, 대표적인 목적 조직입니다. SQD는 특정 목적을 달성하기 위해 관련 인력이 한 팀으로 구성된 형태입니다. 개발자, 디자이너, 마케터, PM 등이 한 SQD로 팀을 이룹니다. 반면 대표적인 기능 조직인 팀은 디자이너면 디자이너끼리, 개발자면 개발자끼리 조직이 구성되죠. 구름은 기능과 목적 조직의 장점을 취한 하이브리드 조직 체계를 갖고 있습니다. ↩︎
