Perfluorodecalin

2025 레블업 AI Tech Conference

19 min read

컨퍼런스 소개


AI 기술의 조합성과 확장성에 초점을 맞춘 컨퍼런스였다. AI를 활용한 사업에 먼저 뛰어든 사람들의 프로덕션에서 부딪힌 문제와 해결책들, 노하우들을 공유하는 세션들이 준비되어있었다.
레블업 AI 컨퍼런스

개요

모각작 회원분께서 한달전 쯤 공유해 주신 링크로 컨퍼런스의 존재를 알게 되었다. 장소가 회사 근처라 가깝기도 하고, 세션들 중에 RAG 관련 내용들은 요새 내가 하고있는 사내 RAG 서버 구축 프로토타이핑에 도움이 될 것 같기에 신청했다.
참여 목표가 RAG 관련 정보를 얻고, AI 기술 동향 파악쪽에 있던 만큼 컨퍼런스 내용은 내 본래의 참여 목적도 완벽하게 달성했고 예상보다 넘칠정도로 알찬 정보들이 많았다.

참여 세션 후기

고객님, 폐쇄망에서 챗 GPT 돌릴 수 있다면 사시겠어요?(유저스틴, Microsoft)

[세션 소개]
실무에서는 다양한 LLM을 활용해서 지능형 앱을 만들고 있습니다. 하지만 외부 인터넷 망을 활용할 수 없거나 비용, 보안 등에 대한 고민을 하다보면 로컬에서 동작하는 LLM을 연동할 필요를 느끼게 됩니다.
현재 Ollama를 활용하면 이 문제를 극복할 수 있습니다. 하지만, Ollama 말고도 다른 도구가 더 있다는 것 알고 계신가요? 서로 비슷하지만 다른 목적을 가지고 있어서 더욱 매력적인 Docker Model Runner, Foundry Local 등의 로컬 LLM 호스팅 도구를 통해 지능형 앱을 구성할 수 있는 방법에 대해 알아보기로 합니다. 또한, 이를 모두 오케스트레이션 할 수 있는 Microsoft.Extensions.AI 라이브러리를 이용하면 기존의 코드를 변경하지 않고도 손쉽게 LLM을 갈아끼울 수 있는데요, 이를 Ollama, Docker Model Runner, Foundry Local 서비스에 활용할 수 있는 방법에 대해 알아봅니다.

이번 컨퍼런스에서 가장 어그로를 잘 끈 세션 이름이지 않을까 싶다ㅎㅎ
세션 연사님께서 말도 굉장히 이해하기 쉽게, 쉬운 말로 재미있게 풀어주셔서 재미있게 볼 수 있었다.
주 내용은, 회사는 보안/비용/API 호출 횟수 제약 등의 이유로 로컬 LLM을 돌려야 할 때가 있을 수 있는데, 이를 쉽게 달성할 수 있는 방법을 소개하고 시연을 통해 얼마나 간편한지에 대한 것이었다.

단순히 로컬 LLM을 실행할 수 있는 방법을 몇가지 소개받았다.

  • Ollama(허깅페이스 모델 공유됨, 단 GGUF 변환된 모델만)
  • Docker Model Runner(컨테이너 최강자, 도커 허브 모델을 그대로 실행가능해 간편)
  • Foundry Local(Azure Ai Foundry와 개발 경험 공유됨, Alias 제공함)

이제 이 모델들을 단지 로컬에 가져다 놓는 것 말고도, 이 것을 앱에 통합하기 위한 간편한 방법도 소개되었다.
원래는 OllamaSharp, IpenAI, Azure AI Foundry 등의 SDK(.NET/C# 기준)를 사용하는것이 표준이지만, SDK 마다 사용법이 다 다르고 매일매일 최고 성능의 모델은 달라진다는게 문제이다.
이를 해결하기 위해 손쉬운 통합 방법인 Microsoft Extension AI가 있다고 한다.
IChatClient 인터페이스만 구현하면 Factory 방식으로 모델 커넥터를 받아와 쓸 수 있었다.
배포를 하려면 컨테이너로 말아서 배포하면 된다고 한다. 간편해 보인다.
오히려 로컬에서 LLM을 굴리기에는 비용이 클 수 있다고 하는데 이 경우 MAS 클라우드 쓰는게 더 좋을 것 같다는 제안도 주셨다.

물론 닷넷, C# 기준의 설명들이었지만 이런 SDK는 매우 유용하고, 웹 쪽에서도 비슷한 방식으로 사용할 수 있는 라이브러리가 제공되고있거나, 곧 되지 않을까라는 기대가 들었다.

에이전틱 아키텍쳐 구성을 위한 개발 팁(이경록, 브레인 크루/테디노트)

[세션 소개]
1. [MCP] 에이전트가 지식정보를 잘 참조하기 위한 RAG Tools 전략
2. 주목 받고 있는 Ambient Agent
3. 장기메모리 관리 & HITL(Human in the Loop)을 활용한 피드백 루프
4. Agentic Workflow 에서의 평가 전략

이 세션을 가장 유용하게 들었는데, RAG 베이스 플렛폼 개발 중에 겪은 경험기를 공유하는 내용이었다. 이 내용 중에는 단순 RAG 구성이 어떻게 되어야 한다라는 아키텍쳐 적인 것 보다도 이 구성들에서 성능 향상을 위해 가장 중요한건 반복, Recursive한 구성 자체가 핵심이라는 인사이트를 얻을 수 있었다.
그리고 세션 연사님이 가지고 있던 목표 자체도 굉장히 인상 깊었는데 단순히 우리가 가장 높은 완성도로 최고가 되어 시장을 점유하자! 라는게 아닌, 가장 먼저 개발해보고, 가장 먼저 시행착오를 많이해보자. 라는 목표를 가지고 있다고 했다. 생각해보면 시장에서는 물론 기능좋고 안정적이고 니즈에 맞는 것이 좋은 제품이라고는 할 수 있지만, 가장 많은 유즈케이스와 트러블 슈팅을 경험해 문제 상황을 처리할 수 있다는 것이 좋은 기술력인게 아닌가 싶었다. 좋은 제품과 좋은 기술력은 다르니까. 나는 어떤 가치를 쫒는것이 좋을까 생각해 볼 수 있는 계기였다.

나는 RAG에 대한 개념 자체를 처음 접했을 때, 이 기술이 AI기술의 최대의 적인 할루시네이션을 완전히 방지할 수 있는 궁극의 기술이지 않을까라고 기대했었다. 물론 그 이후에 실질적으로 RAG 검색 성능이 한계가 있고, Vector DB를 팔아야하는 벤더들 때문에 이 기술이 과대평가 된 경향이 있다는 의견이 있다는 것을 알게되었지만ㅎㅎ 여전히 할루시네이션 방지를 위한, 인간이 툴로써 신뢰도를 해치지 않고 이용할 수 있는 AI 기술은 아직까지는 RAG가 적합하다고 생각한다. 그렇기 때문에 RAG 서버를 구축하려고 시도 중인건데, 아직 초기단계라 그런지 이 강연에서 얻을 수 있는 소중한 개발팁들이 아주 많았다. 유용하다고 생각한 팁 몇개를 정리해본다.

  • RAG의 핵심은 재시도이다.
  • RAG는 생각보다 검색 결과가 잘 안나온다. 현재 결과 정답률이 50 나올까 말까 하다고.. 성능 최적화 문제가 있을 수 있고, 선행 검색을 먼저 해야할 수도 있다고 한다.
  • list_collections, muiti_query, search_document_recursive 를 채택하고, Agent는 Supervisor 패턴이 현재까지 가장 적합해 보인다는 의견.
  • 질문 수준과 모델 성능에 따라 라우팅이 필요한데, 사실상 실제 서비스에서는 무조건 적으로 필요하다고 한다.
  • 툴을 고른다는 것 자체가 라우팅이다.
  • 장기 메모리가 중요하며, 피드백을 무조건 지원해야 시스템 신뢰도가 향상된다. 해외에서는 이를 HITL(Human in the Loop) 라고 한다.
  • MCP 생태계에서 도구를 만들 때는 다양한 호스트 들과 연계 가능하게 만들어야 한다. 이제는 클라이언트가 아니라 에이전트에게 간택받는 시대가 올 것.
  • 문서 변경된 것을 반복 임베드 하면 컨택스트량이 폭발하기 때문에, 모든 문서를 한번에 다 까는 것이 아니라 3개 까보고 찾는 데이터가 없으면 몇개 또 더까보고 이런방식으로 조정해 줘야 효율적이다.
  • 시퀀셜한 설계가 중요하다.(이 툴을 가지고 오고, 저 툴을 통해 다른걸 가지고 오고 이런 식)
  • 에이전트 평가는 답변 평가, 도구 선택 평가, 라우팅 평가가 있을 것이다.

추가로, 강연 내용중에 시간이 없어 자세히 설명해주지는 못하셨지만, 조회할 문서 권한에 대한 Permission을 다루는 쪽이 보여서 이게 바로 내가 원하던 정보다 싶어서 강연 끝나고 연사님께 질문을 시도했다. 강연중에는 단순 Read/Write 권한에 대한 내용이 보여서 내가 원하는 세분화된 권한 제어에 대한 내용과 함께 여쭤봤더니, 단순 Read/Write 권한은 토큰 자체에 대한 권한일 뿐이고 내가 원하는 권한 세부 제어는 RBAC 반영을 알아보라고 의견을 주셨다. 권한은 모델 자체랑은 상관없다는 내용까지도.. 요청 최초에 RBAC을 붙여보라는 코멘트를 들었는데 조만간 연구를 해 볼 예정이다.

AI Safety & Security: For the pursuit of trust worthy AI(박하언, 에임인텔리전스)

[세션 소개]
- AI 안전의 중요성 및 관련 연구 성과/동향 공유
- AIM Intelligence의 AI 공격과 방어 전략/프레임워크
- 금융, 의료, 국방 등 주요 산업에서 신뢰할 수 있고 안전한 AI 구축을 위한 계획
- AI 에이전트, 멀티모달 등 차세대 AI의 새로운 리스크에 맞서 선도적인 비전과 연구 방향

이 세션은 AI 보안 평가쪽의 새로운 사업 분야에 대한 소개여서 매우 흥미로웠다.
현재는 사람들이 AI를 더 잘 활용하기 위한 노력을 기울이고 있는데, 사실 AI 는 악용 되었을 때가 매우 치명적이라는 내용이었다. MCP 보안 사태도 MCP는 자동화, 효율을 위해 권한을 필요로 하게 되는데 권한을 가지게 되는 구조 자체에서 위험이 발생한 것이라고 했다. 예를들어, PDF를 요약하는데 PDF에 악성 프롬프트가 심어져 있거나, 음성 명령을 받는데 오디오에 노이즈를 껴서 모델이 원치않는 행동을 하게 만들 수 있고, 이것 자체가 리스크라는 것이다.
이를 방지하기 위해 모델의 input/output을 관측하기도 하고, 모델의 안정성 자체를 평가하기도 하는, AI 보안 분야를 엿볼 수 있었다.
급변하는 AI 생태계서 얼마나 방어가 가능할지는 모르겠지만.. 흥미롭다고는 생각했다.
(보안쪽은 공격/방어 아이디어 싸움이 아니던가..? 급변하는 기술들에 어떻게 대응이 가능할까..?)

우리 서비스의 Redis는 왜 매일 장애가 날까?(강대명, 래블업)

[세션 소개]
레디스에서 흔히 발생하는 장애 패턴들에 대해서 소개하고, 개선책도 소개합니다.

이 세션은 사실 AI 주제와는 관련이 없었지만, 백엔드쪽 관심이 많은 사람으로써 장애 경험에 대한 공유는 매우 소중하다고 생각해 듣게 되었다.
세부적인 경험 공유도 많았지만 중요한 주제를 꼽으면 아래와 같았다.

  • Redis 자체는 심플한 In-Memory NoSQL Cache Store이다.
  • 하나의 명령이 긴 시간동안 처리되게 하는 경우를 무조건 피해야 한다.(Redis는 본질적으로 싱글 스레디드이기 때문)
  • 적합한 자료구조를 사용하지 않을 경우에 문제가 생긴다.
  • 어떤 키를 가지고 처리하느냐가 중요하다.

가장 대표적으로 꼽히는 이슈들은 아래 내용이었다.

  • KEYS 커맨드 : 패턴에 일치하는 키를 돌려주는 명령어인데, Redis는 거대한 HashTable이기 때문에 Like Search는 매우 부적합하고 작업시간을 전부 점유해버린다.
  • 잘못된 Redis 자료구조 선택 이슈 : 레디스를 대기열로 사용하는 경우가 많은데, 대기열에 있는 자기 자신의 순서를 보여주려고 하는 순간 조회 시간 복잡도가 폭발해서 터지기도 한다. Sorted Set 자료구조를 선택해서 해결할 수 있다.
  • 너무 큰 데이터를 사용하는 경우 : Redis는 하나의 key에 512MB까지 들어갈 수 있고 텍스트로는 사실 문제의 소지가 많이 없다. 하지만 base64 이미지 인코딩이 올라오는 순간 이미지 용량의 33%정도 사이즈가 증가하고, 이 때문에 캐싱할 때 기본적인 사이즈를 꼭 체크해야한다.

사실 내 업무 환경에서는 Redis를 쓸 기회 자체가 없어서 정확히 어떤 케이스들인지, 어떻게 해결할 수있는지 체감이 되진 않았지만 매우 귀중한 트러블슈팅 실 사례라고 생각한다. 이런 내용들만 모아놓은 책이 나온다면 귀중한 보배처럼 쟁여두지 않을까 싶다. 캐싱이라는건 최대한 안쓰는게 좋다지만 대규모 트레픽을 견디려면 언젠가는 쓰게 될테니까..

마무리 하며

사실 세션들이 다 알차고 속도감있고 정보로 가득 차있어서 매우 알짜배기라는 느낌이 있었지만, 약 5시간 동안 짧은 15분 쉬는 시간을 버티면서 단시간 내에 고급 정보들을 머리에 때려넣는 기분이라 체력적으로 조금 힘들기도 했다.
그래도 근 몇년간의 컨퍼런스 참여 중 이렇게까지 얻어가는게 많은 느낌이 드는 컨퍼런스는 없었던 것 같아 하드하지만 매우 좋았다고 할 수 있었다ㅎㅎ
레블업 컨퍼런스가 5회까지 되는 동안 그동안 소식을 몰랐다는게 오히려 조금 아쉬워질 지경이다.
다음 컨퍼런스도 기회가 허락된다면 참여하고 싶다.

그래프 뷰