2024. 6. 23. 20:20ㆍ개발로그/학식봇 만들기
2개월 간 교내 학식 메뉴를 카카오톡을 통해 제공하는 서비스를 운영했습니다. (지금은 서비스 개선 등의 이유로 서비스 중단 상태입니다.)
2개월 간 카카오 챗봇을 운영하면서 느꼈던 점들을 한 번 적어보고자 합니다.
[ 학식봇 만들기 ]
학식봇을 만든 계기는 아침, 저녁 메뉴를 빠르게 알고 싶었기 때문입니다. 진짜 그 이유 하나였습니다. 학교 다니면서 행복한 점이 밥 밖에 없던 시절...✨
학식 메뉴 하나 보자고 학교 홈페이지 들어가는 것도 귀찮고, 현재 학교에서는 카카오워크를 통해 점심 메뉴를 알려주는 서비스에서는 아침, 저녁은 안 알려줘서 학식봇 제작을 결정했습니다.
엥? 에브리타임으로 학식 메뉴 확인 가능하지 않나요?
→ 사실 에브리타임에서 해당 기능 제공하는 줄 몰랐습니다!ㅋㅋㅋ...ㅠㅠㅠ 딱 아침/점심/저녁 시간에만 알려주는 줄 알았어요.
→ 학기초에는 스마트 폴더폰을 사용할 때라 카카오워크는 커녕 에브리타임도 설치하지도 않았습니다! 그래서 카톡 하나만으로 학식 메뉴를 확인하고 싶었어요.
→ 에브리타임 분위기가 익명 커뮤니티라 그런지 가끔씩 싸우고 그래서... 자주 들어가고 싶진 않더라구요. 한 번 들어가면 시간 가는 줄 모르고 계속 에타 구경하기도 해서, 에타 없이 학식 메뉴를 보고 싶다는 바람도 있었습니다.
사실 학식봇 만들기 자체는 오랜 시간이 걸리지 않았습니다. 4월 19일 저녁에 개발을 시작해서 20일 새벽에 배포했습니다.
인터넷에 검색하면 수많은 좋은 자료들이 많이 나오는데, 나중에 학식봇 개발을 어떻게 했는지 정리해 글을 올려보도록 하겠습니다.
모든 코드는 파이썬으로 작성했습니다. BeautifulSoup을 이용해 교내 학식 메뉴를 스크래핑하고, 서버는 플라스크를 이용해 만들었습니다. 배포는 구름 IDE라는 곳에서 진행했습니다.
[ 시범 운영 시작 ]
카카오톡 메시지로 학교 건물 이름을 입력하면 메뉴가 나오는 식으로 제작을 했습니다.
예를들어 이진수 건물의 메뉴를 알고 싶다면, 'ㅇㅈㅅ'라고 검색하면 메뉴가 나오는 식입니다.
배포 초반에는 아마존 EC2를 이용해 배포하는 데에 어려움을 겪어 구름 IDE를 사용했는데, 매주 6,000원 정도가 서버 비용으로 발생했습니다. 서버 비용을 아끼기 위해 오전 7시 30분에서 오후 7시 30분까지 하루 딱 12시간 동안만 시범적으로 서비스를 제공했습니다.
서버에 대한 이해가 부족해서 서버 컴퓨터를 끄면 서비스 제공도 불가하다는 것을 이때 배웠습니다. 하하.
4월 20일 서비스 배포 후 문제가 없는 것을 확인하고 23일 에브리타임에 학식봇에 대한 홍보글을 올렸습니다. HOT 게시글로 선정되어 친구수가 엄청 올랐습니다.
22일에는 홍보게시판에, 23일에는 자유게시판에 홍보글을 올렸는데, 홍보글을 올리고 3일째 되는 날 친구 수가 100명을 넘어섰습니다.
홍보게시판에 올린 글은 좋아요 10개를 넘겨도 HOT 게시글이 되지 않더라구요..? 그걸 글 올리고 알았습니다. 자유게시판에 한 번 더 글을 올렸고, 핫게에 올라간 뒤로 친구 수가 기하급수적으로 올랐습니다.
[교내 부서와의 연락] - 학식봇 운영 방향에 대한 생각
홍보글을 올린 뒤 교내 데이터를 함부로 쓰면 처벌받을 수 있다는 댓글이 달렸습니다. 학식봇과 관련한 문제 발생 가능성을 알아보기 위해 교내 부서와 연락을 진행했습니다.
1. 홍보 관련 부서
당시 챗봇의 프로필 사진을 학교 공식 마스코트 캐릭터를 사용하려고 했어서, 캐릭터 사용 가능 여부에 대해 알아보기 위해 교내 홍보 관련 부서에 연락을 했습니다.
- 교내외 공모전 등에 캐릭터 사용 불가
- 장기적으로 진행하는 프로젝트의 경우 사용 불가
- 교내 수업 과제 등에는 사용 가능
등의 답변을 받았고, 학식봇 서비스의 경우에는 장기적으로 진행 할 프로젝트이기 때문에 학교 로고 또한 사용이 불가하다는 답변을 받았습니다.
그래서 챗봇의 프로필 사진은 직접 그리기로 결정했고, 학식 요정 캐릭터가 탄생했습니다!
귀엽지 않나요? ㅋㅋㅋㅋㅋ 학식 요정입니다. 똥파리 아니에요...
2. 디지털 관련 부서
이제 교내의 디지털 관련 업무를 수행하는 부서에 연락을 해 학식 데이터를 사용해도 되냐는 것에 대해 여쭤보았습니다.
- 이미 공개된 자료이기 때문에 데이터 사용에 대해 뭐라 말 할 수 있는 부분은 없다
- 그러나 교내 데이터를 사용해 프로젝트를 진행하는 것은 최대한 지양해줬으면 좋겠다
- 이미 점심 메뉴는 안내해주는 서비스 존재, 수익 발생 가능성, 학교 사이트 방문자 감소 등의 문제가 발생할 수 있기 때문
등의 답변을 받았습니다.
디지털 관련 부서와의 통화 이후 학식봇 운영 방향에 대한 생각을 했습니다.
1. 학교 데이터를 이용한 수익화는 절대 금지
지금도 학식봇과 관련해서는 매우 소극적인 자세로 임하고 있습니다. 아무래도 교내 데이터를 사용하고 있다보니, 좋은 취지에서 시작한 활동이라도 '학교 이용해서 스펙 쌓는다'는 말을 들을 가능성이 있다고도 생각했고, 서비스의 규모가 커지면 커질 수록 결국 제가 이득(서버 비용 생각하면 과연 이득인가 싶긴 합니다만)을 보는 구조라고 생각했기 때문입니다. 취지가 어떻든 평가는 상대적인 거니까요.
그래서 이 글을 올리는 지금도 마음이 조마조마합니다만... 문제가 발생한다면 지워야죠!
실제로 학식봇 홍보 글도 홍보게시판에 1회(4월 22일), HOT게시글 승급(?)을 위해 자유게시판에 1회(4월 23일) 올리고, 이후로는 올리지 않았습니다.
2. 이미 학교가 기존에 제공하고 있는 서비스(학식 메뉴 알림) 외의 다른 서비스도 추가할 것
학식봇 서비스는 학교가 제공하는 학식 알림봇이 아침, 저녁까지 알려주는 순간 서비스 이용 가치가 급감할 것이라 생각했습니다. 그래도 열심히 만들었는데, 이왕 만든 것 오래오래 유지하면 좋을 것 같아서ㅎㅎ 학식 알림이 아니더라도 사람들이 찾을 수 있는 매력 포인트를 많이 많이 만들어 놓으면 좋을 것 같다는 생각을 했습니다.
[ 아마존 EC2로의 이동 ]
구름 IDE의 서버 유지 비용이 너무 부담되어 아마존 EC2 서비스를 이용하기로 했습니다. 이후 서버 유지 비용은 안 나가서 참 좋았습니다.
아마존 EC2를 사용할 당시 플라스크의 http 때문에 고생을 조금 했습니다. 구름 IDE의 경우에는 GUI를 통해 https 설정을 손쉽게 할 수 있었는데, 아무래도 EC2는 그럴 수 없다보니... 알 수 없는 에러들을 보며 스트레스를 조금 받았습니다.
결국 플라스크로 https를 사용하는 것은 실패했습니다만, 웹이나 앱 형태가 아닌 카카오챗봇을 통해 서비스를 제공하니 http를 사용해도 문제가 없을 것이라는 생각을 했습니다.
그래도 https 한 번 해보려고 가비아에서 도매인도 사고, 깃허브 페이지 호스팅도 하고, 다시 아마존으로 돌아가서 도메인 연동도 하고... 이것저것 할 수 있는 것은 다 해보려고 했던 것 같습니다.
[ 웹 스크래핑에서 그냥 스크래핑으로... ] - 내가 하지 말았어야 할 실수 1
교내 학식 메뉴를 제공하는 과정에서, 메뉴가 제대로 스크래핑되지 않는 문제가 발생했습니다.
우리 학교는 테이블 태그를 이용해 메뉴를 보여주는데, 간혹 테이블이 두 개 이상 겹쳐있거나 아예 테이블이 없는 경우도 있었습니다.
저는 테이블에 있는 값들을 모두 읽어 온 다음 리스트에 저장하고, 리스트의 값들을 슬라이싱 해 메뉴를 알려주는 방식으로 진행했는데요, 한 번 데이터 순서가 꼬이기 시작하니 보여지는 메뉴들이 줄줄이 꼬이는 문제가 발생했습니다.
지금 생각해보면 슬라이싱 한 뒤에 데이터들을 변수에 저장하고, 그 변수의 값들을 수정하는 방식을 쓰면 좋았겠다 싶지만... 그때는 그러지 않았습니다. 수동으로 메뉴를 하나하나 입력하는 악수를 두게 됩니다...!!
아아악... 이후 학교 생활이 바빠지면서 코드 수정은 뒤로 밀리게 되고, 결국 서비스를 종료할 때까지 학식 메뉴를 수동으로 입력하게 됩니다. 🤦♀️ 그러질 말았어야 했는데,,,
[ 모니터링의 중요성을 깨닫다 ]
사실 직접 만든 서비스를 배포까지 해본 것은 이번 챗봇이 처음이었습니다. 옛날에 서버 개발자들은 크리스마스 연휴에도 항상 노트북을 들고 다닌다는 말을 들었는데, 우스개소리가 아니었습니다. 배포를 시작한 이후로 24시간 내내 문제가 발생할까봐 걱정해서 스트레스의 연속이었던 것 같아요.
이때 모니터링의 중요성을 알게 되었습니다. 요청이 들어오거나 에러가 발생했을 때 카톡이나 디스코드 등에 자동으로 메시지가 오면 좋겠다는 생각을 했습니다.
그리고 사용자가 어떤 값을 요청했는지도 알고 싶다는 생각을 했습니다. 당시 사용하던 방식은 요청이 들어와도 어떤 요청을 했는지 추적을 할 수가 없어서, 어느 식당의 메뉴가 가장 수요가 높은지 알 수 없었습니다. 물론 이 문제는 이후 제가 하게 둔 두 번째 최악의 수를 통해 자동으로 해결되게 됩니다(나 울고 있니...?😂)
열심히 썼는데도 아직 하고 싶은 말이 많네요..!
다음 편으로 돌아오겠습니다.