[서비스] AI 요리 블로거 챗종원 개발기 -完

개발에 8시간이 걸렸는데, 포스팅에 일주일이 걸렸습니다..

처음에 전체 내용을 마치는 글 포함해서 7 부분으로 나누고, 하루에 2개씩 쓰려고 했는데 중간중간 내용을 조금씩 더하고, 빼고, 수정하다 보니 길어졌군요

 

이번 포스팅에서는 시리즈의 기획 의도와 개발 도중 겪었던 난항 및 현재의 문제점과 개선 방안에 대해 알아보겠습니다.

 

기획 의도

최근 블로그 도메인을 바꾸고 구글 서치콘솔에 등록된 이전 글의 색인들이 전부 무효가 되면서, 구글 검색을 통한 유입이 되지 않고 광고 수익이 0이 되었습니다.

 장기적으로 유입이 될만한 컨텐츠가 필요하다고 생각하던 찰나에, JIRA Automation과 GPT를 활용한 서버리스 환경의 챗봇을 기획, 개발하게 되었고 GPT API를 직접 써보면서 "이거로 블로그 하나 더 파도 되겠는데?"싶어서 바로 이거 끝내고 GPT를 활용한 포스팅 자동화 서비스를 만들어야겠다고 생각했습니다.

 

 처음부터 요리 블로거를 해야겠다라고 생각한 건 아니었습니다. 평소 금융 분야에도 관심이 있어 GPT와 한국 투자 증권의 REST API를 활용해

1. 재무재표를 GPT 모델에 학습
2. 커스텀 GPT 모델로 현재 기업 가치와 재무제표를 통한 기업가치 비교
3. 저평가된 기업을 찾아 자동으로 포스팅

하는 서비스를 생각하던 중..

뉴스에서 백종원 님과 인삼축제에 대해 보게 되었고,

백종원? 백종원 + 챗 GPT = 챗종원? 메뉴 추천 AI 요리블로거? ChefGPT?????

 

팬입니다

이름에 꽂혀서 저질러버렸습니다.

---

주제 자체가 남녀노소 다양한 사람들이 유용하게 이용할 수 있어서 좋았고, 스스로도 매일 오늘 뭐 먹지? 하며 메뉴 선정에 귀찮음을 느꼈기 때문에 개발 동기도 솟구쳤습니다.

이왕 만드는 김에 백종원 레시피처럼 직접 요리에 필요한 재료와 조리 방법을 알려주었으면 좋겠다고 생각해

 

매 끼니마다 메뉴를 추천하고, 필요한 재료와 조리 방법을 알려주는 AI 요리 전문 블로거

 

챗종원이 탄생했습니다.

 

 

발생했던 문제들과 개선점

여러 솔루션, Dall-E API를 처음 사용하다 보니 이해가 부족해 공식 문서를 읽었음에도 실제 사용 전까지 인지하지 못한 문제가 몇 가지 있었습니다.

 

수동 로그인

Access Token 발급을 위해 현재 직접 로그인을 해야 합니다.

앞선 포스팅에서 언급했던 것처럼 셀레니움 등의 프레임워크를 통해 직접 인증을 하는 부분도 자동화가 가능하다고 생각됩니다.

 

Http 요청에 대한 비동기 처리

개발 언어로 파이썬을 사용한 이유는 크게 세 가지입니다.

1. 모든 주요 로직이 I/O로 이루어졌기 때문에 인터프리터의 한계인 GIL 등의 성능 이슈로부터 자유로움
2. 다양한 라이브러리로 빠른 개발이 가능
3. 코드가 간결해 다른 사람이 해당 서비스를 따라 구현할 때 처음 개발을 접하는 사람도 쉽게 따라 할 수 있음

문제는 1번의 I/O 작업시간과 관련되어 문제가 발생했습니다.

재사용성을 위해 각 마이크로 서비스들을 파이프-필터 구조로 설계했는데, 이러한 과정에서 중간에 위치하는 서비스들은 마지막 서비스가 끝날 때까지 기다리게 되고 이로 인한 오버헤드가 상당했습니다.

Cloud Functions에서는 함수의 실행 시간과 실행 횟수를 통해 비용이 측정되기 때문에 실행 시간을 줄여야 했습니다.

 

다만 여기까지는 예상했기 때문에, 새로운 스레드를 생성해 다음 서비스에 요청하고 중간 서비스에서는 202 Accepted를 응답해 요청을 보낸 서비스가 기다리지 않게 하려고 했지만?

Cloud Functions의 원리를 완벽히 이해하지 못한 상태로 진행해 다른 문제가 생겼습니다.

서버리스 컨테이너 배포 솔루션인 Cloud Run 기반으로 동작하는 Cloud Functions는 요청이 들어올 때 컨테이너가 실행되고, 응답이 이루어짐과 동시에 컨테이너가 종료되어 버리기 때문에 위와 같이 백그라운드에서 task를 실행시킬 수가 없었습니다.

지금 생각해 보면 당연한 거긴 한데, 왜 그땐 미처 생각을 못했을까요..

 

현재 이를 개선하기 위한 방안으로 생각 중인 것은

1. Google Cloud Pub/sub
2. Google Cloud Tasks

입니다.

두 솔루션 모두 Http 요청의 비동기 처리를 위해 사용되는데, 이는 추후에 따로 포스팅을 하도록 하겠습니다.

선택을 위해 비용과 여러 고려 사항이 있겠지만, 비용 측면에서는 이보다 급하게 처리해야 할 문제가 있습니다.

---

닭 잡는 데에 소 잡는 칼, Cloud SQL

정확히 30배

참고로 티스토리 Access Token 하나 가지고 있고, 티스토리 포스팅할 때 한 번 Read가 발생합니다.

트랜잭션이 필요한 데이터도 아니기 때문에 Access Token을 시크릿이나 환경변수로 옮기거나, Cloud Storage에 저장하는 것이 바람직하다고 생각됩니다.

가장 먼저 처리해야 합니다..

---

한글을 학습하지 못한 Dall-E

현재 가지고 있는 문제점은 아니고, 개발 도중에 바로 처리한 문제입니다.

Dall-E 3.0이 9월 중순 경에 공개되었으나, 현재 API로 접근할 수 없고 Chat GPT::GPT-4에서 사용 가능합니다.

Dall-E 2.0은 한글을 모르기에 프롬프트를 영어로 번역하는 과정을 추가했습니다.

참고로 Dall-E 3.0이 생성한 팬케이크 사진의 퀄리티는 상상을 초월하는데요..

예시 이미지 1

예시 이미지 2

감탄밖에 나오지 않습니다..

Dall-E 3.0 API가 공개되면 블로그 컨텐츠의 퀄리티가 아주 많이 올라갈 것 같아 기대가 됩니다.

 

마치며

본격적으로 개발을 배우기 전, 파이썬 장고를 통해 인스타그램 클론코딩 영상을 보고 무작정 따라 했던 경험이 있습니다.

당시 프레임워크 버전도 다르고, UI도 달라서 IDE부터 따라 깔고 설정에서도 애를 많이 먹었던 기억이 있는데, 개발을 처음 배우면서 맨 땅에 헤딩하는 게 힘들었던 것 같습니다.

모르는 사람도 쉽게 접근할 수 있는 주제이고, 서버리스 솔루션을 사용해 처음 개발을 접하는 사람도 설정이나 IDE 등의 이슈없이 흥미를 느끼고 따라 하기 쉬웠으면 좋겠다는 생각으로 기획했습니다.

 

올 초에 개인적으로 알고리즘 과외를 한 적이 있는데, dfs, bfs 탑재시켜서 어느 정도 궤도에 올려놓으니 스스로 흥미가 생겨서 곧잘 하는 모습을 보고 재미를 느꼈습니다.

마찬가지로 약간의 설명과 과정을 적어서, 코드만 따라친다는 느낌이 들지 않고 흥미가 생기기를 바랐는데 막상 어땠을지는 모르겠습니다.

나도

피드백은 언제나 환영이고, 틀린 내용이나 궁금하신 내용이 있으시다면 댓글로 알려주셨으면 감사하겠습니다.

광고도 좀 눌러주시면 좋구요 ㅎ..

 

아래는 챗종원 블로그입니다.

 

챗종원