Jeongsk

생성형 AI 애플리케이션 구축 시 흔한 함정 - Chip Huyen

24 min read

원문: Common pitfalls when building generative AI applications

작성자: Chip Huyen

파운데이션 모델(foundation model)을 활용한 애플리케이션 개발이 아직 초기 단계이기 때문에, 실수를 하는 것은 자연스러운 일입니다. 이 글은 공개된 사례 연구와 개인적인 경험을 바탕으로 가장 흔하게 발생하는 실수들을 예시와 함께 정리한 짧은 노트입니다.

이러한 실수들은 매우 흔하기 때문에, AI 제품 개발 경험이 있다면 아마 한 번쯤은 마주쳤을 것입니다.

1. 생성형 AI가 필요하지 않은 곳에 생성형 AI를 사용하기

새로운 기술이 등장할 때마다, 전 세계 시니어 엔지니어들의 집단적인 한숨이 들리는 것 같습니다. “모든 것이 못은 아니다”라는 말입니다. 생성형 AI도 예외가 아닙니다. 오히려 무한해 보이는 그 능력이 모든 곳에 생성형 AI를 사용하려는 경향을 더욱 악화시킵니다.

한 팀이 에너지 소비를 최적화하는 데 생성형 AI를 사용하겠다는 아이디어를 제안했습니다. 그들은 가정의 에너지 집약적 활동 목록과 시간대별 전기 요금을 LLM에 입력한 다음, 에너지 비용을 최소화하는 스케줄을 만들도록 요청했습니다. 실험 결과 이를 통해 가정의 전기 요금을 30% 절감할 수 있다고 했습니다. 공짜 돈인 셈이죠. 누가 그런 앱을 사용하지 않겠습니까?

저는 이렇게 물었습니다. “전기가 가장 저렴할 때 가장 에너지를 많이 소비하는 활동을 스케줄링하는 단순한 방법과 비교하면 어떤가요? 예를 들어, 밤 10시 이후에 세탁과 자동차 충전을 하는 것처럼요?”

그들은 나중에 시도해보고 알려주겠다고 했습니다. 하지만 연락은 오지 않았고, 곧 이 앱을 포기했습니다. 제 생각에는 이러한 탐욕적 스케줄링(greedy scheduling)이 꽤 효과적일 수 있을 것 같습니다. 설령 그렇지 않더라도, 선형 프로그래밍(linear programming)과 같이 생성형 AI보다 훨씬 저렴하고 신뢰할 수 있는 최적화 솔루션이 많이 있습니다.

저는 이런 시나리오를 계속해서 목격했습니다. 한 대기업은 네트워크 트래픽의 이상 징후를 탐지하는 데 생성형 AI를 사용하고 싶어 했습니다. 다른 회사는 향후 고객 상담 전화량을 예측하고 싶어 했습니다. 한 병원은 환자가 영양실조 상태인지 탐지하고 싶어 했습니다(정말 권장하지 않습니다).

무엇이 가능한지 감을 잡기 위해 새로운 접근법을 탐색하는 것은 종종 유익할 수 있습니다. 다만 여러분의 목표가 문제를 해결하는 것이 아니라 솔루션을 테스트하는 것이라는 점을 인지하고 있어야 합니다. “우리는 문제를 해결합니다”와 “우리는 생성형 AI를 사용합니다”는 매우 다른 헤드라인이지만, 안타깝게도 많은 사람들이 후자를 더 선호합니다.

2. ‘나쁜 제품’과 ‘나쁜 AI’를 혼동하기

스펙트럼의 반대편에는, 많은 팀들이 생성형 AI를 시도해봤지만 사용자들이 싫어했다는 이유로 문제에 대한 유효한 솔루션으로 생성형 AI를 기각하는 경우가 있습니다. 그러나 다른 팀들은 유사한 사용 사례에 생성형 AI를 성공적으로 활용했습니다. 저는 이러한 팀 중 두 곳을 조사할 수 있었는데, 두 경우 모두 문제는 AI가 아니라 제품에 있었습니다.

많은 사람들이 AI 애플리케이션의 기술적 측면은 간단하다고 말했습니다. 어려운 부분은 사용자 경험(UX)입니다. 제품 인터페이스는 어떻게 생겨야 할까요? 제품을 사용자의 워크플로우에 어떻게 매끄럽게 통합할까요? 휴먼 인 더 루프(human-in-the-loop)를 어떻게 통합할까요?

UX는 항상 어려웠지만, 생성형 AI에서는 더욱 그렇습니다. 생성형 AI가 읽기, 쓰기, 학습, 교육, 업무, 오락 등의 방식을 바꾸고 있다는 것은 알지만, 아직 정확히 어떻게 바꾸는지는 잘 모릅니다. 읽기/학습/일하기의 미래는 어떤 모습일까요?

사용자가 원하는 것이 얼마나 직관과 반대될 수 있는지, 그리고 엄격한 사용자 연구가 필요한지를 보여주는 몇 가지 간단한 예시가 있습니다.

  1. 제 친구는 회의록을 요약하는 애플리케이션을 개발하고 있습니다. 처음에 그녀의 팀은 적절한 요약 길이를 찾는 데 집중했습니다. 사용자들이 3문장 요약을 선호할까요, 아니면 5문장 요약을 선호할까요?

    하지만 알고 보니 사용자들은 실제 요약에는 관심이 없었습니다. 그들이 원한 것은 각 회의에서 자신과 관련된 액션 아이템(action item)뿐이었습니다.

  2. LinkedIn이 직무 적합성 평가를 위한 챗봇을 개발했을 때, 사용자들이 정확한 응답을 원하지 않는다는 것을 발견했습니다. 사용자들은 도움이 되는 응답을 원했습니다.

    예를 들어, 사용자가 봇에게 자신이 어떤 직무에 적합한지 물었을 때 봇이 “당신은 전혀 맞지 않습니다”라고 답한다면, 이 응답은 정확할 수 있지만 사용자에게는 별로 도움이 되지 않습니다. 사용자들은 어떤 격차가 있는지, 그 격차를 줄이기 위해 무엇을 할 수 있는지에 대한 팁을 원합니다.

  3. Intuit는 사용자가 세금 관련 질문에 답할 수 있도록 챗봇을 만들었습니다. 처음에는 미지근한 피드백을 받았습니다. 사용자들이 봇을 유용하게 생각하지 않았습니다. 조사 결과, 사용자들이 실제로 타이핑을 싫어한다는 것을 발견했습니다. 빈 챗봇 화면을 마주하면, 사용자들은 봇이 무엇을 할 수 있는지, 무엇을 입력해야 하는지 몰랐습니다.

    그래서 Intuit는 각 상호작용마다 사용자가 클릭할 수 있는 몇 가지 제안 질문을 추가했습니다. 이를 통해 사용자가 봇을 사용하는 데 있어 마찰이 줄어들었고 점차 사용자의 신뢰가 구축되었습니다. 그 후 사용자들의 피드백은 훨씬 더 긍정적이었습니다. (Intuit의 VP of AI인 Nhung Ho가 Grace Hopper에서 열린 우리 패널에서 공유한 내용)

요즘 모두가 동일한 모델을 사용하기 때문에, AI 제품의 AI 구성 요소는 비슷하고, 차별화는 제품에서 이루어집니다.

3. 너무 복잡하게 시작하기

이 함정의 예시들:

  1. 직접적인 API 호출로 작동하는데도 에이전트 프레임워크(agentic framework)를 사용하기
  2. 간단한 용어 기반 검색 솔루션(벡터 데이터베이스가 필요 없는)으로 작동하는데도 어떤 벡터 데이터베이스를 사용할지 고민하기
  3. 프롬프팅(prompting)으로 작동하는데도 파인튜닝(finetuning)을 고집하기
  4. 시맨틱 캐싱(semantic caching)을 사용하기

너무나 많은 반짝이는 새로운 기술들이 있다 보니, 바로 사용하고 싶은 유혹이 있습니다. 하지만 외부 도구를 너무 일찍 도입하면 두 가지 문제가 발생할 수 있습니다:

  1. 중요한 세부 사항을 추상화하여 시스템을 이해하고 디버깅하기 어렵게 만듭니다.
  2. 불필요한 버그를 도입합니다.

도구 개발자들도 실수를 할 수 있습니다. 예를 들어, 프레임워크의 코드베이스를 검토할 때 기본 프롬프트에서 오타를 자주 발견합니다. 사용하는 프레임워크가 알려주지 않고 프롬프트를 업데이트하면, 애플리케이션의 동작이 변경될 수 있고 그 이유를 모를 수 있습니다.

결국 추상화는 좋은 것입니다. 하지만 추상화는 베스트 프랙티스를 통합하고 시간이 지나면서 테스트되어야 합니다. AI 엔지니어링이 아직 초기 단계이고 베스트 프랙티스가 여전히 발전하고 있기 때문에, 우리는 어떤 추상화를 채택할 때 더욱 신중해야 합니다.

4. 초기 성공을 과대평가하기

  1. LinkedIn은 원하는 경험의 80%를 달성하는 데 1개월이 걸렸고, 95%를 넘는 데 추가로 4개월이 걸렸습니다. 초기 성공으로 인해 제품을 개선하는 것이, 특히 환각(hallucination)과 관련하여 얼마나 어려운지를 크게 과소평가했습니다. 그들은 후속 1%의 개선을 달성하는 것이 얼마나 어려운지 알고 낙담했습니다.

  2. 전자상거래를 위한 AI 영업 어시스턴트를 개발하는 한 스타트업은 0에서 80%로 가는 것이 80%에서 90%로 가는 것만큼 오래 걸렸다고 말했습니다. 그들이 직면한 과제들:

    • 정확도/지연시간 트레이드오프: 더 많은 계획/자기 수정 = 더 많은 노드 = 더 높은 지연시간
    • 도구 호출(tool calling): 에이전트가 유사한 도구를 구별하기 어려움
    • 시스템 프롬프트의 톤 요청(예: "럭셔리 브랜드 컨시어지처럼 말하기")이 완벽하게 지켜지기 어려움
    • 에이전트가 고객의 의도를 완전히 이해하기 어려움
    • 쿼리의 조합이 기본적으로 무한하기 때문에 특정 유닛 테스트 세트를 만들기 어려움 이 내용을 공유해준 Jason Tjahjono에게 감사드립니다.

  3. UltraChat 논문에서 Ding et al. (2023)은 “0에서 60으로 가는 여정은 쉽지만, 60에서 100으로 진행하는 것은 극도로 어려워진다”고 공유했습니다.

이것은 아마도 AI 제품을 구축해본 사람이라면 누구나 빠르게 배우는 첫 번째 고통스러운 교훈 중 하나일 것입니다. 데모를 만드는 것은 쉽지만, 제품을 만드는 것은 어렵습니다. 언급된 환각, 지연시간, 지연시간/정확도 트레이드오프, 도구 사용, 프롬프팅, 테스팅 등의 문제 외에도, 팀들은 다음과 같은 문제에 부딪힙니다:

  1. 신뢰성(reliability) - API 제공자로부터의 신뢰성. 한 팀은 API 호출의 10%가 타임아웃되었다고 말했습니다. 또는 기본 모델이 변경되어 제품의 동작이 변경되는 경우입니다.
  2. 컴플라이언스(compliance) - 예를 들어 AI 출력 저작권, 데이터 액세스/공유, 사용자 개인정보 보호, 검색/캐싱 시스템의 보안 위험, 그리고 학습 데이터 출처에 대한 모호함 등입니다.
  3. 안전성(safety) - 예를 들어 악의적인 행위자가 제품을 남용하거나, 제품이 무감각하거나 공격적인 응답을 생성하는 경우입니다.

제품의 마일스톤과 리소스를 계획할 때, 이러한 잠재적인 장애물을 반드시 고려해야 합니다. 한 친구는 이를 “조심스럽게 낙관적이기”라고 부릅니다. 하지만 많은 멋진 데모가 훌륭한 제품으로 이어지지 않는다는 것을 기억하세요.

5. 인간 평가를 포기하기

AI 애플리케이션을 자동으로 평가하기 위해, 많은 팀들이 AI-as-a-judge(LLM-as-a-judge라고도 함) 접근법을 선택합니다. 즉, AI 모델을 사용하여 AI 출력을 평가하는 것입니다. 흔한 함정은 인간 평가를 포기하고 전적으로 AI 심판에 의존하는 것입니다.

AI 심판은 매우 유용할 수 있지만, 결정론적이지 않습니다. 심판의 품질은 기본 심판 모델, 심판의 프롬프트, 그리고 사용 사례에 따라 달라집니다. AI 심판이 제대로 개발되지 않으면, 애플리케이션의 성능에 대해 오해를 불러일으키는 평가를 제공할 수 있습니다. AI 심판은 다른 모든 AI 애플리케이션과 마찬가지로 시간이 지남에 따라 평가되고 반복되어야 합니다.

assets/9bef0c3486ea0ff3a30587c0ec40a374_MD5.png]]

에이전트 패턴(Agent pattern)

제가 본 최고의 제품을 가진 팀들은 모두 자동화된 평가를 보완하기 위해 인간 평가를 갖추고 있습니다. 매일 인간 전문가들이 애플리케이션 출력의 일부를 평가하는데, 이는 30개에서 1000개의 예시에 이를 수 있습니다.

일일 수동 평가는 세 가지 목적을 수행합니다:

  1. 인간의 판단과 AI의 판단을 상관시킵니다. 인간 평가자의 점수가 감소하는데 AI 심판의 점수가 증가한다면, AI 심판을 조사해보는 것이 좋습니다.
  2. 사용자가 애플리케이션을 어떻게 사용하는지 더 잘 이해하여, 애플리케이션을 개선할 아이디어를 얻을 수 있습니다.
  3. 자동화된 데이터 탐색이 놓칠 수 있는, 현재 이벤트에 대한 지식을 활용하여 사용자 행동의 패턴과 변화를 감지합니다.

인간 평가의 신뢰성도 잘 작성된 어노테이션 가이드라인(annotation guideline)에 달려 있습니다. 이러한 어노테이션 가이드라인은 모델의 지시사항을 개선하는 데 도움이 될 수 있습니다(인간이 지시사항을 따르기 어렵다면 모델도 마찬가지입니다). 또한 나중에 파인튜닝을 선택할 경우 파인튜닝 데이터를 생성하는 데 재사용할 수 있습니다.

제가 작업한 모든 프로젝트에서, 데이터를 단 15분만 응시해도 보통 몇 시간의 고생을 절약할 수 있는 통찰력을 얻습니다. Greg Brockman은 “데이터의 수동 검사는 아마도 머신러닝의 모든 활동 중에서 가치 대비 명성 비율이 가장 높을 것입니다”라고 트윗했습니다.

6. 사용 사례를 크라우드소싱하기

이것은 기업들이 생성형 AI를 채택하려고 열광하던 초기에 제가 본 실수입니다. 어떤 사용 사례에 집중할지에 대한 전략을 생각해내지 못한 많은 기술 임원들이 회사 전체에서 아이디어를 크라우드소싱했습니다. “우리는 똑똑한 사람들을 고용합니다. 그들이 우리에게 무엇을 해야 할지 말하게 합시다.” 그런 다음 이러한 아이디어를 하나씩 구현하려고 합니다.

그래서 우리는 백만 개의 text-to-SQL 모델, 백만 개의 Slack 봇, 그리고 수십억 개의 코드 플러그인을 갖게 되었습니다.

고용한 똑똑한 사람들의 의견을 듣는 것이 좋은 생각인 것은 사실이지만, 개인들은 투자 수익률이 가장 높은 문제보다는 일상 업무에 즉각적으로 영향을 미치는 문제에 편향될 수 있습니다. 큰 그림을 고려하는 전반적인 전략 없이는, 일련의 작고 영향력이 낮은 애플리케이션으로 옆길로 새기 쉽고, 생성형 AI에는 ROI가 없다는 잘못된 결론에 도달하게 됩니다.

요약

요약하자면, 다음은 흔한 AI 엔지니어링 함정들입니다:

  1. 생성형 AI가 필요하지 않은 곳에 생성형 AI를 사용하기 생성형 AI는 모든 문제에 대한 만능 솔루션이 아닙니다. 많은 문제는 AI조차 필요하지 않습니다.

  2. ‘나쁜 제품’과 ‘나쁜 AI’를 혼동하기 많은 AI 제품에서 AI는 쉬운 부분이고, 제품이 어려운 부분입니다.

  3. 너무 복잡하게 시작하기 멋진 새 프레임워크와 파인튜닝이 많은 프로젝트에 유용할 수 있지만, 첫 번째 행동 방침이 되어서는 안 됩니다.

  4. 초기 성공을 과대평가하기 초기 성공은 오해를 불러일으킬 수 있습니다. 데모 준비 단계에서 프로덕션 준비 단계로 가는 것은 첫 번째 데모에 도달하는 것보다 훨씬 더 오래 걸릴 수 있습니다.

  5. 인간 평가를 포기하기 AI 심판은 체계적인 인간 평가와 검증되고 상관되어야 합니다.

  6. 사용 사례를 크라우드소싱하기 투자 수익률을 극대화하기 위한 큰 그림의 전략을 세우세요.

그래프 뷰

백링크