2023 Sookmyung AWS Winter Camp 우승 회고

 작년 12월 말부터 진행되어 지난 2월 23일 최종 발표를 한 AWS Winter Camp에서 감사하게도 저희 '흰머리오목눈이' 팀이 우승을 차지하였습니다. 특히 이번 대회는 구현보다도 아이데이션 과정을 거치는 게 정말 힘들었는데, 우승까지 저희 팀이 어떤 과정을 거쳤는지 자세한 회고를 작성해 보도록 하겠습니다.

아이데이션

우리에게 필요한 서비스

저희의 아이데이션은 약 3주간 매주 회의를 통해 진행되었습니다.

특히 처음 각자 아이디어를 맡아 서로 회의를 통해 피드백을 거치고 디벨롭한 뒤, 아이디어 멘토링을 통해 최종 결정할 수 있었습니다.

 

제가 제시한 아이디어는 ES를 활용한 사내 이슈 검색 시스템이었습니다.

• 슬랙에서 나누는 질문들과 오류 해결 과정을 자동으로 저장하여 검색이 가능하게 만드는 웹페이지
• 자주 나오는 질문들의 오류를 확인할 수 있는 대시보드
• 오류 분석 결과로 나온 오류 담당자에게 슬랙 알림 전송

 

최종적으로 제 아이디어가 결정된 것에 가장 큰 이유는

1. '개발'이라는 도메인에 직결
2. 데이터 분석의 최소화 (데이터 분석이 가능한 팀원이 거의 없었기 때문입니다.),
3. 사내에서 사용 가능 → 사용 가능한 범위가 넓음

이지 않을까 싶습니다.

 

핵심적으로 현재 winter camp에서 사용되는 start-aws 슬랙 채널에 지난 streamlit 해커톤 이후로 쭉 들어와 있는데,

특히 질문 채널인 #999채널에 같은 질문이 올라올 때마다 슬랙 검색 기능의 한계를 많이 느꼈습니다.

 

모두 같은 슬랙 채널을 사용하고 있기 때문에 모두가 느끼는 어려운 점이라고 생각했고 특히 더 많은 공감을 얻을 수 있으리라 확신했던 것 같기도 합니다.

서비스 이름

참고로 저희 팀 '흰머리오목눈이'는 팀원 중 한 분이 탐조에 굉장히 진심인 분이 계셔서 귀여운 새 이름을 따서 정하게 되었습니다.

 

'이슈 트리'라는 서비스 이름 역시도 이슈 해결 + 새가 사는 나무를 합쳐 서비스 이름을 짓게 되었습니다.

 

로고도 귀엽게 제작 완료!

 

---

상세 기능

이슈 저장 기능

슬랙에서 보통 질의응답을 나눌 때, 질문을 던지면 스레드 안에서 답을 주고받습니다. 질문 내용과 해당 스레드 내용을 전부 저장하는 기능입니다.

 

먼저 문서화를 위해 버전, 스택을 따로 저장하고 싶었고 이를 그냥 채팅 속에서 파싱해 내는 것이 아닌, 슬랙의 워크플로를 사용하여 애초에 사용자가 따로 작성하도록 유도한다면 데이터 처리를 더 용이하게 할 수 있을 것 같은 생각을 하게 되었습니다.

 

실제 999채널에서 왼쪽 사진과 같이 워크플로를 사용하고 있는데, 실제 이 부분을 담당하신 팀원분께 워크플로 사용을 추천해 드렸더니 오른쪽 사진처럼 아주 센스 있게 제작해주셨습니다.

 

 

제가 실제로 감탄했던 부분은 바로 왼쪽 사진과 같은 해결 버튼입니다.

 

스레드에서 내용을 주고받은 뒤 아래 해결 버튼을 클릭하면 스레드 내용이 자동으로 문서화가 되는 것입니다.

 

처음 아이데이션을 할 때는 이미 해결이 완료되어 문서화를 시키고자할 때 트리거를 어떻게 시켜야 할지에 대한 고민을 충분히 하지 못했는데, 담당해 주신 팀원분께서 버튼을 알아 오시곤 문서화까지 성공시키셨습니다.

 

 

 

 

 

이 문서화 및 저장하는 로직이 제일 복잡한 구현이 아니었을까 싶습니다.

 

실제로 복잡해 보이는 과정을 간단히 설명하기 위하여 발표 자료에서도 이 과정을 최대한 잘 녹여내고자 노력을 많이 했습니다. 이 부분을 설명하고 있는 부분이 바로 아래 자료입니다. 회원가입 로직을 설명할 때 보통 이러한 표현을 많이 사용한다는 점이 떠올라 의견을 처음 제시했는데, 많은 API 사이에서 어떻게 데이터를 처리하였는지 잘 정리된 것 같아 저 개인적으로도 가장 뿌듯한 부분입니다.

 

 

이슈 검색 기능

이슈 검색 기능은 Streamlit 페이지에 Elasticsearch에 검색 쿼리를 보내서 가져온 결과를 나타내주는 곳입니다.

쿼리 작성에 대한 도움만 드렸고, Streamlit은 UI 배치에 관련해서만 중간중간 피드백을 드렸는데 제가 슬랙봇을 개발하고 있던 사이 완성이 되어있었습니다..! 저는 던지기만 했는데 알아서 구현해 주는 팀원이 있다는 건 행복한 일입니다.

 

쿼리 작성 기준은 다음과 같습니다.

1. 동일한 스택을 가진 문서만 검색되기
2. 문서화된 내용과의 일치성 > 최신 날짜 > 버전 순으로 높은 가중치(점수)를 가짐.

특히 이 부분 담당자분들께서 마지막까지 쿼리, 배포 이슈 해결로 인해 쉬지도 못하고 최종 발표에 참석하셨습니다.😥

마지막까지 열심히 노력해 주신 덕분에 더 좋은 퀄리티의 발표 자료로 마무리할 수 있었던 것 같습니다.

 

대시보드 기능

대시보드 기능은 오류가 잦은 버전과 스택을 한눈에 파악할 수 있는 기능입니다.

1. 발생된 SOS 요청
2. 문서화된 질문의 수
3. 일 별 SOS 요청 추이
4. 질문이 가장 많은 스택
5. 질문이 가장 많은 버전

위와 같은 정보를 파악하여 특정 버전과 스택의 잠재적인 위험을 판단할 수 있습니다.

 

 전 특히나 엘라스틱까지 들어가서 대시보드를 확인하는 것이 아닌, Streamlit 페이지에서 실시간 대시보드를 확인하고 싶었기 때문에 가능하다면 검색 페이지와 함께 Streamlit에서 확인할 수 있도록 개발해달라는 요청을 드렸습니다. 특히나 이 실시간 연결에서 권한 수정과 라이브러리 등 많은 리서칭이 필요하였는데, 팀원분들의 엄청난 구글링 실력 덕에 (실제로 유료 과금을 피하고자 열심히 조사하셨습니다.) 무사히 대시보드를 연결할 수 있었습니다.

 

무엇보다도 정말 엘라스틱 대시보드를 그대로 옮겼기 때문에, 필터 기능도 동일하게 적용해서 볼 수 있었습니다.

• ex) 예를 들어 질문이 가장 많은 스택 중 스프링부트를 클릭하면 스프링부트에서 질문이 가장 많은 버전, SOS개수, 질문 수를 볼 수 있음

대시보드 기능도 제가 아이디어를 낼 때는 "오류가 유난히 심하게 나는 스택을 한 번에 볼 수 있으면 좋을 것 같은데 ^.^" 와 같은 심플한 아이디어로 생각했지만, 유능한 팀원 덕에 깔끔한 시각화 처리를 해낼 수 있었습니다. 

 

이 시각화에 특화된 팀원은 발표 자료 제작에도 진심이라 아주-아주-아주 지대한 공을 세우셨습니다! 유능 조아!

 

✨도움 요청 기능

드디어 제가 제작한 부분입니다.

도움 요청 기능은 해결하지 못한 문제, 즉 검색해도 해결하지 못한 문제를 담당자에게 요청하는 기능입니다. 실제로 마감날 2일 전까지도 계속 디벨롭된 기능입니다.

 

먼저, 도움 요청 기능을 위해 저는 유저의 깃허브 아이디를 등록하는 명령어와 각 팀 채널의 역할을 지정할 수 있는 슬랙봇을 개발하였습니다.

1. /깃허브등록 [깃허브 아이디] 명령어를 사용하면 명령어를 입력한 유저의 슬랙 아이디와 깃허브 아이디가 Elasticsearch에 저장됩니다.
2. /역할지정 [#팀 채널] [패키지 ...] 명령어를 사용하면 각 팀 채널의 역할을 패키지 단위로 지정할 수 있습니다.
3. /역할삭제 [#팀 채널] [패키지 ...] 명령어를 사용하면 해당 팀 채널의 역할 패키지를 제거할 수 있습니다.
4. /역할확인 [#팀 채널] 명령어를 사용하면 해당 팀 채널의 역할을 확인할 수 있습니다.

여기서 왜 하필 패키지 단위였냐면, 저희는 먼저 오류 메세지 파싱을 위해 가장 익숙한 스프링부트를 메인 스택으로 설정하여 사용하였습니다. 팀에서 각각 담당한 패키지가 있다고 가정하여, 해당 패키지 경로에서 에러가 발생하면 알려주는 역할입니다.

 

여기서 "팀 채널" 이라는 아이디어는 제일 처음, 디스코드의 역할이라는 기능에서 차용해왔습니다. 담당한 역할을 태그하고자 하였지만, 슬랙에는 동일한 기능이 없어서 팀 채널에 채팅을 보내자는 아이디어로 변경하였습니다.

 

도움 요청 기능의 대략적인 플로우는 다음과 같습니다.

1. Streamlit에서 오류 해결 문서를 찾지 못하면 검색된 에러 메세지를 파싱하여 에러 경로(패키지)와 에러 위치(라인 넘버)를 파악합니다.
2. GraphQL API를 사용하여 해당 위치 마지막 수정자의 깃허브 아이디를 가져옵니다.
3. 담당자의 깃허브 아이디, 피키지, 설명, 스택, 버전 등을 슬랙 서버에 전송하면
4. 슬랙 서버에서 담당자의 깃허브 아이디와 패키지를 통하여 담당자의 슬랙 아이디와 해당 패키지를 담당한 팀 채널 아이디를 가져옵니다.
5. 최종적으로 담당자의 DM과 팀 채널에 슬랙으로 알림을 전송합니다.

 

 

따로 발표에서 언급하진 않았으나, 이 외에도 만약 담당자나 팀을 찾지 못한 에러는 따로 메인 채널에 전송되어 모두가 확인할 수 있도록 하였습니다.

 

원래 최종 발표 2일 전까지만 해도, 패키지만 파싱하여 담당 팀 채널에 알림을 보내주는 기능까지만 있었는데 갑자기 불현듯이 깃허브 최종 수정자가 떠올라서 오류 메세지엔 에러 위치 (특히 라인 넘버)까지 나온다는 특성을 토대로 따로 담당자에게 DM을 보내주는 기능을 급하게 추가하였습니다.

 

이 기능 추가 때문에 결국 최종 발표 전날에 밤을 새우게 된 것 같기도 한데.. ㅎ 급한 의견 추가해도 결국 구현해 주신 팀원분과 함께 밤을 새우신 팀원분들 모두 감사합니다..😂

 

---

최종 발표

발표 준비

사실 전날에 밤을 새우며 거의 발표 자료 제작에 엄청난 공을 들였던 것 같습니다. 아무리 개발을 잘해도, 이게 잘 전달되지 않으면 모조리 도루묵이 되어버리기 때문에, 무려 세 명이 달라붙어 발표 자료 제작에 열을 올렸습니다.

 

발표 자료를 굉장히 중요히 생각하는 편이라 오랜 시간을 투자하는 것을 좋아하는데, 또 다른 발표 자료에 진심인 팀원분이 계셨기 때문에.. (canva 고수) 많은 도움을 받을 수 있었습니다. 무엇보다도 팀원들이 이미 아는 사이인 경우가 대부분이었기 때문에 디자인에 과감히 피드백을 주고받으며 무사히 완성할 수 있었습니다.

 

저희의 엄청난 발표 자료는 밑에 함께 첨부합니다.

https://www.canva.com/design/DAF9b2cPXdE/vEudRA3amrKXhOn44qUF9Q/view?utm_content=DA[%E2%80%A6]XdE&utm_campaign=designshare&utm_medium=link&utm_source=editor

 

드디어 발표

 전 어쩌다가 여기서도 발표를 맡게 되었습니다. 팀장이고, 아이디어 제공자였기 때문에 당연한 결과였습니다. 무엇보다도 프로젝트를 제가 잘 이해하고 있었기 때문에 질의응답을 대비하기 위해서이기도 했습니다.

 

(전날 밤을 새운 여파로 속도 굉장히 좋지 않았는데, 위장약을 도핑하고 발표를 진행하였습니다.)

 

다행히..(?) 질의응답은 진행되지 않았고, 발표 중에 심사위원분들의 표정을 계속 보았는데 생각보다 좋은 반응 덕분에 점점 긴장이 풀리면서 발표를 할 수 있었습니다.

 

따로 발표 후 심사평을 듣는 시간을 가졌는데, 이.. 이게 심사평의 전부였습니다. 심사평을 들을 당시엔 너무 칭찬만 가득하게 들어서 너무 감동을 받아 벅찬 마음으로 자리에 돌아갔던 것 같습니다.

 

하지만 자리로 돌아가 다른 팀들과의 심사평과 비교해 보며 딱히 피드백을 받지 못한 것 자체가 아이디어에 관심이 없으신 것 같다고 생각하게 되었고, 겸허히 끝..을 받아들일 준비를 하고 있었던 것 같습니다. (사실 반대였지만요.)

 

우승은 우리의 것!

ELASTIC에 S가 빠져있는 것은 안비밀

 

발표 전, 1등은 모든 심사위원에게 만점을 받았다는 이야기를 듣고 3등, 2등에서 이름이 불리지 않자 완전히 마음을 놓고 있었습니다. 사실 기술적인 부분에서 다른 팀원들에 비해 데이터 분석과정도 전무했고, 클라우드 활용도도 낮다고 생각하여 낮은 점수를 받을 것이라고 예상하였기 때문이었습니다.

 

하지만 예상과 달리 1등을 발표할 때 팀 이름이 불렸고, 전 날 피로가 싹-날아가는 것과 같은 기분으로 즐겁게 사진을 찍었습니다. 전 날 팀원들 중 3명이 이번에 상을 받으면 첫 상을 받는다고 해서 굉장한 부담을 안고 있었는데 전부 잊을 수 있었던 순간이었습니다.

 

결국 눈물바다

 

 너무 많은 칭찬들을 들어서 사실 녹음해뒀다가 힘들 때 다시 듣고 싶을 정도였는데, 앞으로 더 열심히 살아갈 수 있는 원동력이 될 수 있을 것 같습니다.

 

우리 팀 '흰머리오목눈이' 너무 수고했어요! 결과까지 완벽하게 행복합니다 수고하셨어요😍