🔭[2024 우아콘 후기 특집] 프롬프트 엔지니어링으로 메뉴 이미지 검수 사례 및 사내 클라우드 리소스 정책 관리 사례

안녕하세요 구독자님, DevOps 소식과 기술 지식을 정리해서 공유해드리는 DevOps 여행을 위한 소식지입니다.

지난 2024 우아콘 참여 후기 글에 이어서, 제가 참석한 컨퍼런스 세션 내용을 이번 글에서 마저 공유드리겠습니다.

💻Fine-tuning 없이, 프롬프트 엔지니어링으로 메뉴 이미지 검수하기

해당 세션은 메뉴 이미지 검수 작업을 ChatGPT 프롬프트 엔지니어링으로 수행하기 위해 어떤 시행착오를 거쳤는지 공유해주신 자리였습니다.

우아한형제들 자체 리서치에서 '배달의민족'에서 메뉴 선택에 큰 영향을 주는 요소로 메뉴 이미지가 꼽혔지만, 이런 메뉴 이미지를 업로드할 때 반려되는 정책이 너무 다양하여 모든 이미지를 사람이 직접 검수하기 위해서는 많은 시간이 필요했다고 합니다. 그래서 이 문제를 해결하기 위해 ChatGPT의 프롬프트를 활용했다고 하는데요.

ChatGPT를 메뉴 이미지 검수 작업에 활용하기 위해, 먼저 아래와 같은 프롬프트 엔지니어링 과정을 거쳤다고 합니다.

v1: 프롬프트 엔지니어링 없이 테스트

v2: 프롬프트 엔지니어링 도입 시작

v3: 프롬프트가 참고할 메뉴 이미지 검수 정책 구체화

v4: 메뉴 이미지 검수 정책에 맹점이 없도록 세분화

발표자분은 이런 과정을 거치면서 프롬프트 엔지니어링이란 단어 하나까지 신경써야 하는 세심하고 섬세한 작업이며, 문제 상황에 맞게 Task를 최적화해가고, ChatGPT와 상호작용하며 생각을 이해시켜가는 과정임을 느꼈다고 하셨습니다.

또한 위 과정에서 멈추지 않고, 아래와 같이 프롬프트 엔지니어링을 이어나갔다고 하는데요.

v6: 프롬프트 응답 출력 구조화

응답 결과를 Json 포맷으로 요구

v7: 일관된 답변을 위한 고도화

CoT(Chain of Thought): ChatGPT 스스로 제출된 이미지를 설명하도록 한 다음 결과 반환
Ensemble 기법: 여러 모델의 응답에서 다수결 기반으로 결정
제한된 예산 내에서 효과적인 방법을 구현했지만, 좀 더 비용 절약이 필요

v8: 허리띠 졸라매기

한국어 쿼리를 영문으로 번역 후 제출하여 토큰 절약 -> 응답 시간 감소 효과도 얻음
ChatGPT 호출 수를 줄이기 위해, ChatGPT를 사용하지 않아도 되는 이미지는 사내 보유 중인 모델을 바로 활용하는 방식을 사용
다만, 한국어 쿼리와 영문 쿼리의 토큰 사용량 차이는 GPT-4o 출시 이후로 많이 줄었다고 합니다.

결국 이렇게 수많은 과정을 거친 결과,

프롬프트의 기반이 되는 Instruction에서는 입력데이터에 대한 암시와 이중부정 표현 삭제, 정확한 행동 지침을 사용하게 되었고,

프롬프트의 Parameter에서는 해당 서비스에 맞는 값을 찾아 조정하면서 JSON 포맷으로 응답 결과 출력 안정성을 보장했으며,

프롬프트에서는 요구사항을 분리해서 입력하고, 결과를 한 문장으로 출력하라는 지시를 사용하여 응답을 더욱 빠르게 출력하며, 구체적이고 세분화된 정책항목과 함께 프롬프트의 응답 예시를 제공하여 더욱 정확한 응답을 이끌어냈다고 합니다.

이렇게 여러 시행착오를 거쳐 서비스에 적합하도록 프롬프트를 최적화했지만, 여전히 프롬프트의 응답에서 과도한 확대가 발견되거나, 저작권 문제도 존재한다고 하는데요.

이를 해결하기 위해 중간에 분기점을 두어, 특정 결과에 대해서는 사람이 검수하는 단계를 추가했다고 합니다.

본 세션의 마지막 순서로, 우아한형제들이 AI를 활용하는 방식을 소개하는 시간이었는데요.

우아한형제들에서는 먼저 생성형 AI를 안전하게 사용하기 위한 조건을 아래와 같이 정의했다고 합니다.

정보가 정확한가

공격적이거나 혐오를 담고있진 않은가

주어진 예산 내에서 소화 가능한가

서비스 요구사항에 수용 가능한 속도를 얻을 수 있는가

본 세션 주제와 같은 생성형 AI를 활용하는 과제를 수행하면서, 위 고려 사항 중 '정보가 정확한가'에 대해서는 아쉬움이 남았다고 하셨습니다.

그리고 우아한형제들에서는 생성형 AI에 대해 여전히 아래와 같은 고민이 있다고 하는데요.

사람이 하던 일을 생성형 AI가 대신해서 생산성을 개선할 수 있는가?

Fine tuning하지 않은 생성형 AI는 어디까지 활용 가능할까?

우아한형제들에서는 프롬프트 엔지니어링만으로 문제를 해결할 수 있을지 연구 중이며, 프롬프트 엔지니어링만으로 어렵다면 LLM 또는 LLM과 머신 러닝을 하이브리드로 적용하거나, 기존 머신러닝의 모델링도 문제 해결에 사용 중이라고 합니다. (이전 후기 글에서 공유드렸던 '배달의민족'의 추천 검색어 기능도 모델링을 적용됐었죠🙂)

프롬프트 엔지니어링은 저도 계속 관심을 가지고 있던 분야이다보니, 이번 세션은 프롬프트 엔지니어링 과정에서 마주친 문제와 개선 방식, 그 결과를 발표해주셔서 재밌었던 시간이었습니다.

☁️0원으로 클라우드 비용, 장애, 보안까지 한 번에 관리하는 비밀 공개

본 세션에서는 클라우드 리소스 정책 관리 툴 Cloud Custodian을 활용하여 사내 클라우드 리소스 정책을 체계적으로 표준화한 사례를 공유해주셨습니다.

우아한형제들에서는 10년간 AWS 어카운트 수가 50개 이상, EC2 인스턴스의 수가 10000대 이상으로 빠르게 확대되다보니 클라우드 활용 정책을 체계적으로 관리할 필요성이 생겼다고 하는데요.

기존에는 AWS Service Quotas로 클라우드 리소스 할당량을 관리했지만, 리소스에 대한 정책이 100여 개 이상으로 계속 추가되는 상황이었기 때문에 정책을 좀 더 체계적으로 관리하기 위해 별도의 툴을 도입하기로 했다고 합니다. 그 후보군은 아래와 같이 3가지였습니다.

Cloud Custodian: 비용 저렴 / 생산성 낮음 / 확장성 높음

AWS Config: 비용 높음 / 생산성 중간 / 확장성 중간

상용 솔루션: 비용은 솔루션마다 다름 / 생산성 높음 / 확장성 낮음

그리고 이 중 오픈소스인 Cloud Custodian을 도입하게 되었는데, Cloud Custodian은 CNCF의 인큐베이팅 프로젝트여서 이미 검증된 정책 관리 툴이라고 판단했다고 합니다. CNCF의 프로젝트에 대해선 지난 KubeEdge 소개 글에서도 잠깐 언급한 적이 있었습니다.

Cloud Custodian로 대부분의 요구사항을 충족할 수 있었지만, Kubernetes 리소스에 대해서는 확인하기가 어렵다는 제약도 있었다는데요. 이를 보완하기 위해 Kubernetes 전용 정책 엔진인 Kyverno를 사용해서 Kubernetes Pod와 Image 정보를 확인했다고 합니다.

클라우드를 운영하다보면 결국 리소스 사용에 대한 정책이 필요하게 될 텐데, 이런 정책을 어떻게 관리해야 하는가에 대해 고민해볼 수 있는 시간이었습니다.

해당 세션에서 Cloud Custodian의 활용 예시에 대해서도 자세히 공유해주셔서 저도 많이 배웠는데요. 이 글에서 Cloud Custodian의 기술적인 부분까지 상세하게 넣진 않았지만, 클라우드 리소스 정책 관리에 대해서는 추후 좀 더 자세히 정리한 다음 다뤄보려 합니다.