AWS Summit Seoul 2025 Review - 1일차 여러 기업의 AI 고민들

여러가지 세션들을 들었는데 이번에는 가볍게 정리를 해보려고합니다.

거의 대부분 생성형 AI와 관련된 세션을 들었고 거기서 나오는 질문과 인사이트를 정리하려고 합니다.

 

1. 쿠팡의 생성형 AI 활용을 통한 광고 세션

생성형 AI 관리를 위한 내용을 먼저 언급했습니다.

프롬프트 관리하는 flow를 정리를 했습니다.

프롬프트 엔지니어링 라이프 사이클이 위와 같은데 프롬프트 관리 및 배포하는 툴은 어떤게 있는지 궁금했습니다.
프롬프트를 저장하는 위치가 Git인지 아니면 새로운 플랫폼이 나온게 있는지 확인이 필요했습니다.

 

쿠팡 광고의 High-level architecture는 아래와 같습니다.

쿠팡 Ads의 주요 고객은 중소 상공인이라고합니다.

그래서 아래와 같은 문제를 가지고 있는데요.

1인 기업의 광고주들이 가진 어려움

1. 데이터가 어떤 의미를 가지는지 파악이 어려움
2. 데이터를 가지고 분석을 어떻게 해야할지 어려움
3. 어떻게 광고를 쓸수있을지 잘 모름

 

원래는 중소 상공인이 광고 마케터들이 제안하는 캠페인 세팅값을 직접 설정하고 광고를 집행했어야했는데

아래와 같이 AI를 이용해서 자동 입찰 기능을 제안하고 있었습니다.

다양한 데이터를 통해서 목표로 하는 광고 성과를 낼 수 있게 도와주겠다는 것이죠

 

그 다음은 자동 상품 선택입니다.

기존의 수동 입찰의 경우 어떤 제품을 광고할지도 결정을 해야하는데, 쿠팡의 자동 상품선택은 이 고민을 줄여준다고 합니다.

제품의 예상 성과에 따라서 상품 목록을 우선순위로 비딩해서 성과를 올려주도록 추천해주는게 핵심이라고 하네요.

기존의 경우 사람의 판단이 필요하기에 결정이 늦어지는 반면, 자동 입찰 및 자동 상품 선택은 이 갭을 줄여줍니다.

 

그리고 추가로 효과적인 프롬프트 엔지니어링 전략에 대해서 언급이 있었습니다.

1. 모델에 역할 부여하기
2. 명확하고 구체적으로 지시하기
3. XML 태그 사용하기 (생성된 데이터가 아닌 가지고 있는 데이터(용어, 수치등)을 명시 및 설명추가하는 방법)
4. 예시 사용하기 (Few-Shot)
5. 단계별로 생각하게하기 (CoT)
6. 복잡한 프롬프트 연결하기 (Prompt Chaining)
7. 긴 프롬프트를 효과적으로 다루기 위한 방법
8. 환각 현상에 대처하기 위한 기술
   1. 프롬프트 레벨에서 막기
      • 데이터 태그의 값만 사용
      • 수학적 계산을 하지 않도록 막기
   2. 코드레벨에서 막기
      1. 평가 방법
         1. 여러 agent를 만들어서 평가함 : 평가 agent가 false를 리턴하면 재학습시킴
         2. 직접 테스트 : 영업팀이 직접 평가함, 수정 요청시 개발자가 프롬프트 수정, 이를 자동화하려고 했음 -> bedrock flows 사용
9. 프롬프트 인젝션 및 적대적 프롬프팅

등에 대한 고려가 필요하다는 언급을 했습니다.

 

또한, 비용을 줄이기 위한 프롬프트 캐싱을 했다고 합니다.

 

2. LLM 할루시네이션 줄이기 - Datadog

처음에는 LLM 서비스 모니터링의 어려움으로 복잡성을 언급했습니다.

나머지 내용은 사실 광고에 가까워서 추가로 적을 부분은 많지 않았던것 같습니다.

 

3. JW중외제약 - 신약 개발 연구 혁신

개인적으로는 가장 궁금했던 세션이긴한데 실제 내용 자체는 다른 의미로 신선했습니다.

요약을 하자면 결국은 AWS HealthOmics라는 플랫폼으로 클라우드 전환을 하자! 

이게 다였거든요.

기존에 많은 스타트업/대기업들이 클라우드 마이그레이션 하던것과 거의 동일하다고 보면 되기 때문입니다.

다만, 의문이었던것은 국내 의약 업체중에서도 빠른 편에 속한다고 했다는 점입니다.

엄청 늦다고 생각했거든요.

 

다만, 다시 생각해보면 이 업체들의 경우

1. 데이터 및 보안이 생명이기에 이렇게 늦게 옮길 수 밖에 없었다는 생각이 들기도하고

2. 클라우드 상에서 바이오를 위한 프로그램을 쉽게 설치할 수 있느냐 라는 생각을 해봤을때 아직 그런게 없었을 수 있겠다.

이런 생각이 들었습니다.

 

그래서 이 분야로도 서서히 클라우드가 영향을 미치고 있다 이정도로 이해를 했습니다.

아래는 이미 클라우드를 대규모로 활용하고 있는 해외 업체들입니다.

 

4. 트웰브 랩스 AI 인프라 고도화

이 세션에서는 AWS에서 AI 인프라를 얼마나 잘 사용할것인가 이것이 핵심이었습니다.

AWS 서비스들의 특징을 조화롭게 사용했다 이렇게 느껴집니다.

 

그중 가장 먼저 언급된 서비스가 SageMaker HyperPod입니다.

이 서비스의 특징은 다른 서비스들은 GPU를 점유하고 있을 수 없습니다.

사용 목적이 끝나면 GPU를 반납하도록 되어있었죠. (GPU는 비싸고 필요로 하는 기업이 많기 때문이죠)

 

1. 이 서비스는 사용 목적이 끝나더라도 GPU를 반납하지 않아도 됩니다.

2. 또한, 다른 특징으로 GPU 클러스터의 상태를 보고 알아서 Checkpoint 및 고장나면 자동 복구 기능을 지원합니다.

 

즉, Checkpoint를 처리해야하는 부담을 고객에서 본인들로 옮긴것이죠.

참 고객 친화적인 서비스를 빠르게 잘 만든다는 생각이 듭니다.

 

트웰브랩스의 경우 두가지 모델을 만든다고 합니다.

1. 영상 검색모델 - Marengo

2. 영상 언어 생성모델 - Pegasus

이 모델들을 학습 및 추론하기 위해서 어떤일을 했을지를 정리했습니다.

 

1. 학습 및 추론 인프라 구성

학습용의 경우 인프라는 아래와 같은 요구사항이 있다고합니다.

1. 고성능 스토리지

2. 고속네트워크

3. 강력한 GPU

 

운영적인 요구사항은 아래와 같습니다.

1. 시스템 안정성 (고장나면 대처가 쉬운가)

2. 사용자 인터페이스 (빠른 학습 및 Documentation이 잘 되어있는지, 직접 만들지 않고 잘 되어있는걸 쓰고싶은 요구사항)

3. 데이터 보안

 

추론용은 아래와 같은 요구사항이 있습니다.

1. 배포 시스템이 잘 되어있어야하고

2. 안정성이 높아야합니다. 즉, 고객이 모델을 쓰다가 끊기지 않는것이 중요합니다.

3. 서빙용 GPU가 다양한지 입니다. -> 학습용만큼 반드시 초 고성능일 필요는 없고 다양한 선택지가 있으면 좋습니다.

 

이러한 2가지의 요구사항을 모두 만족하는것이 AWS SageMaker HyperPod이라고 하네요.
이를 통해서 학습용 인프라와 추론용 인프라를 별도로 구성하지 않아도 되는 장점이 있다고 합니다.

기존에는 학습용과 추론용 인프라 구성을 별도로 해서 비용이 비효율적이었나봅니다.

 

2. 다음은 대규모 벡터 데이터 처리입니다.

트웰브랩스가 만드는 모델은 비디오 데이터이기때문에 다양한 modal 데이터를 가지고 있습니다.

1. audio

2. video

3. image

4. text

모두를 이해해야하는데 이를 위해서 각 종류마다 벡터를 유지하고 있다고합니다.

그래서 벡터를 위한 데이터베이스가 필요한데 기존에는 상용 데이터베이스 (e.g. Postgres) 등이 벡터 기능을 제공하지 않아서 어쩔수 없이 벡터만을 위한 전용 데이터베이스를 구성했다고 합니다. (Pinecone 등)

그러나 현재는 Redis나 PostgreSQL 같은 상용 데이터베이스 도 벡터연산을 지원해서 벡터전용 -> 상용 DB로 전환을 했다고 합니다.

그 이유는 아래와 같습니다.

 

Query를 벡터 + 일반 정보를 혼합할 수 있음

예전에는 벡터 정보 빼고는 별도의 DB를 사용했습니다.

그래서 분리된 DB를 조합해서 사용했기에 트러블슈팅과 관리가 힘들었다고 합니다.

하지만 이제는 하나의 DB가 이를 모두 처리할 수 있게되었고 하나의 쿼리로 비지니스 로직 + 벡터 쿼리를 짤 수 있게됩니다.

 

5. K-melloddy : 정부 주도 신약 개발 플랫폼

기존 바이오 업계의 문제를 해결하려고 노력하는 세션이었습니다.

기존 바이오 업계는 서로 데이터를 공유할 수 없어서 각 회사에서는 독립적이고 개별적인 데이터로 신약 개발을 했습니다.

AI의 경우 엄청나게 많은 데이터를 학습하면 성능이 좋아지는데, 바이오 업계의 경우 각자가 가지고 있는 데이터를 합치면 많지만 서로 공유하지 않기때문에 데이터의 양은 많지 않아서 문제였죠.

그래서 나온 개념이 연합 학습(Federated Learning) 이라는 개념입니다.

데이터를 외부로 옮기지 않고 AI 모델만 공유해서 모델을 만들자는 아이디어입니다.

 

연합학습의 특징은 아래와 같습니다.

1. 데이터 기반의 협력, 오픈 이노베이션 가능

 

2. 최적 AI 모델의 빠른 매칭을 할 수 있다.

 

3. 리소스 관리 비용을 절감 할 수 있다.

 

4. 데이터의 가치를 산정할 수 있다.

이 부분은 아직은 실제 가치를 부여하고있지는 못하지만 추후에 가능할것으로 기대한다 이정도로 얘기를 했습니다.

 

5. AI 모델 거래 플랫폼을 구현할 수 있다.

 

그래서 K-MELLODY가 뭐냐고 하면 아래와 같은 사업입니다.

기존 방식대로 동물 실험을 해도 90%는 잘 안되는게 대부분이었다고합니다.

그래서 최근 FDA 발표로 AI로 이 예측 모델을 대체하고자하는게 최근 흐름이라고하네요.

그래서 AWS를 이용해서 우리나라의 연합 학습 환경을 구축했다 이런내용입니다.

 

아래의 경우 K-MELLODDY의 유럽 버전인 MELLODDY가 잘되었기때문에 진행하는 것이고

유럽에서 진행했던 기업들은 아래와 같다고 합니다.