[데보션] OpenLab 성장 스토리 후기!

안녕하세요!

 

8월에 있었던 세미나 후기 뒤늦게 블로그에 업로드합니다!

오랜만에 T타워에 방문하여 “OpenLab 성장 스토리” 행사에 다녀왔습니다! 😄


‘주제 중 잘 모르는 주제들이 있었는데 잘 이해할 수 있으려나?’ 라는 고민이 있었지만 발표자님들의 명쾌한 설명 덕분에 해당 내용에 대한 이해도를 높일 수 있었습니다! 👍  약 3개월정도 공부하신 내용들을 압축적으로 살펴볼 수 있어서 스터디를 참여하지 않았어도 해당 내용에 대한 스터디의 효과를 간접적으로 경험할 수 있었습니다.

또한, 프로젝트 데모 부스에서 프로젝트를 직접 체험하며, 설명자분들의 열정적인 설명에 감탄했습니다. '데모는 이렇게 해야 하는구나'라는 것을 새삼 깨달았습니다.

아래의 내용은 9개의 주제에 대한 간략한 내용과 느낀점입니다!

💙1) 개발자가 알아야 할 NAT, DNS
✔️ DNS 도메인 위임
    - 상위 도메인에서 하위 도메인의 네임서버를 지정하여 관리 권한을 넘겨주는 것을 의미
✔️AWS에서의 NAT
    - Source NAT : 출발지 IP를 변환하는 NAT 프라이빗 서브넷 EC2 → NAT GW
    - Destination NAT : 목적지 IP를 변환하는 NAT 로드밸런서 → EC2
✔️NAT과 방화벽
    - 개발 업무 중 외부 연동사와 연동을 위해 NAT IP에 대한 방화벽 요청이 필요할 수 있는데 하나의 NAT IP만 사용하면 연결이 불안정할 수 있으므로 여러 대의 NAT 사용하기

💬 근본적인 내용을 잘 설명해주셔서 감사합니다! 키워드를 외우는 방법으로 네트워크를 공부했었는데 이렇게 설명할 정도로 깊이있게 공부해야겠다고 느끼는 계기가 되었습니다!

💙2) GraphRAG로 여행 100% 준비하고 떠나기 

- 해외 여행 시 로밍 혜택을 제대로 활용하지 않는 이유는 복잡한 절차와 많은 고민 거리 때문→ 모든 고민 사항들은 사실 연관된 데이터들로, 이를 효율적으로 연결하는 최적의 도구는 그래프(Graph)
- GraphRAG의 역할 : GraphRAG은 LLM 기반의 오픈북으로, 질문에 대한 답변을 생성할 때 그래프에서 관련 데이터를 조회하고 연관된 데이터를 가져온다. → 이를 통해 유기적인 연결을 통해 의사결정을 돕는다. 
    

💬 여러 복잡한 고민들을 GraphRAG로 해결할 수 있다는 점이 흥미로웠습니다! 요즘 핫한 고객 개인화 LLM을 위한 기술을 어떻게 활용할 수 있는지 살펴볼 수 있어서 좋았습니다!

💙3) AI Travel Agent, Travel Go

- 과잉된 정보인해 의사결정 어려움 -> agent가 할 수 있다.
- Agent 주변 환경을 인지하고 상호작용하며 목표를 달성하기 위해 자율적으로 실행한다.
    - Planning
    - Tools -> 계획된 내용을 바탕으로 api를 호출한다.
    - Feedback -> 스스로 내릴 수 있다.
- 각각 agent들을 각각의 tool들을 활용하여 일을 수행한다.
    - 팀장 agent - 부탁을 받음 , 어떤 agent가 하면 좋은지 생각하고 일을 시킨다.
    - 장소 추천 agent -> DB에 저장된 것을 출천
    - 질문 답변 agent -> 신뢰할 수 있는 정보를 바탕으로
    - 일정표 생성 agent -> 동선 고려하여 최적화된 일정을 생성함

❓서비스 목적과 맞지 않는 질문이 있을 경우에는 어떻게 하나?
     agent는 이 부분에 대해서 도움을 줄 수 없다고 프롬프트 엔지니어링을 하여 해결할 수 있다. DB에서 질문 내용을 검색하여 없거나, classification을 활용하여 엉뚱한 질문에 대해 “답변할 수 없다”고 응답할 수 있다.

💬 개인적으로 공부했을 때 agent 개념이 이해가 잘 되지 않았지만 오늘 발표를 통해 명쾌하게 이해할 수 있었던 계기였습니다! 특히, 의도에 맞지 않는 질문을 구별하는 방법에 대해 궁금했었는데 이에 대해 답변을 받을 수 있어서 좋았습니다!

💙4) 나는 왜 코프링 컨트롤러를 더이상 만들지 않게 되었나?

✔️Spring + 코틀린 + openAPI 로 프로젝트를 진행

✔️코프링 컨트롤러가 필요하지 않는 이유
1. Stub 서버 코드 생성으로 직접적인 컨트롤러 개발이 필요가 없음
2. 생성된 컨트롤러 부분의 코드를 override받아 작성 → 비즈니스 로직에 집중할 수 있다.
3. 실제 소스코드에 swagger 코드 부분이 없어도 되기 때문에 깔끔해진다.

💬 데보션 영 3기 “대학생”분께서 발표를 진행하시다니 정말 대단하십니다!! 저도 API  명세서를 postman을 공유하는 형식으로 작성하다가 변경사항을 수동으로 적용해야한다는 단점을 느끼고 swagger를 써볼까 고민했었는데 더 좋은 방법인 OpenAPI generate를 이용해봐야겠다고 생각했습니다! ㅎㅎ 

💙5) SQL로 프로일잘러가 되는 길, LENS

생성 AI 를 통해 비전문가도 빠르게 회사 DB에 대한 SQL을 작성할 수 있다. 

✔️프롬프트 엔지니어링한 부분 

- 페르소나 : 데이터 분석가, 유능한 어시스턴트
- Constraints : 실제 데이터를 포함하면 안된다는 제약 (설명과 쿼리를 실행하는 부분으로 나눠져있기 때문에)
- Few shot : 효율성을 분석해서 출력하라고 입력

✔️프롬프트만으로는 function call이 되지 않는다.
- Pair rule을 즉, 아래의 메시지 순서를 지켜야 한다.
    - Human message
    - Ai message
    - Tool message
- 하지만 LLM을 불러오고 나서 히스토리 매핑 시 문제가 생김
    - 이전 메시지 10개씩 끊어왔었다. 이렇게 되면 pair rule이 지켜지지 않았다.
- 이를 해결하기 위해 스케줄링을 사용하였다.
    - 항상 마지막은 AIMessage이거나 Tool message가 나오면 거의 끝나기 때문에 이를 만나면 바로 자른다. -> 이러면 pair rule이 맞아진다.

💬 정말 상용화되면 좋을 서비스 같았습니다! 특히 pair rule을 지키기 위해 어떻게 하셨는지 자세하게 공유해주셔서 비슷한 상황에 적용해보아야겠습니다!

💙6) Kuberflow 알아보기 

- Kubeflow는 ML과 Ops의 각 단계를 지원하는 다양한 기능을 제공하여, MLOps 사이클을 전체적으로 관리하고 최적화할 수 있게 한다. 이를 통해 ML 모델의 개발, 배포, 모니터링, 테스트 등을 효율적으로 수행할 수 있으며, 이는 Kubeflow가 MLOps에 적합
- Kuberflow Components
    - Pipeline - Kubeflow Pipeline → ML 워크플로우를 정의하고 자동화하여 실행
    - Notebooks - Kubeflow Notebooks →데이터 분석 및 모델 개발 환경 제공
    - Dashboard - Kubeflow Central Dashboard → Kubeflow의 전체 상태와 구성 요소를 관리할 수 있는 중앙 대시보드
    - AutoML - Katib → AutoML 실험을 수행
    - Model Training - Kubeflow Training Operator
    - Model Serving - KServe

💬 발표자님의 여러 경험을 하신 부분이 매우 인상깊었습니다 ㅎㅎ 스터디로 해당 내용을 공부하셨다고 하셨는데 잘 정리하여 공유해주셔서 감사합니다! 

💙7) 대규모 시스템 첫걸음

✔️Server
- 2가지 방법
    - 스케일 업: 기존 서버의 성능 향상.
    - 스케일 아웃: 서버 대수를 늘려 고가용성 확보.
- 무상태 유지: 사용자 세션을 특정 서버에 저장하지 않아야 함.

✔️Database
- Replication 구성: 데이터 복제를 통해 읽기 성능 향상.
- 읽기와 쓰기(create, update, delete) 작업을 분리하여 처리.
- 샤딩: 데이터를 분할하여 성능 향상.

✔️Key-Value Store: 서버와 DB 사이에 Redis 등의 캐시 레이어를 두어 읽기 성능 최적화.
- CAP 이론: 일관성, 가용성, 파티션 감내 중 두 가지를 선택해야 함.
- Quorum consensus 프로토콜: 최소 N개의 서버 응답으로 일관성 유지.
- 파티션 감내: 멀티캐스트 채널, 하트비트 프로토콜 사용.

✔️ Consistent Hashing: 하나의 캐시에 모든 데이터를 저장하기 어려움 → 여러 캐시에 키를 균등하게 분산하여 캐시 미스 문제 해결.

✔️ GUID: 중복 키 방지 방법.
 Auto increment, UUID, ticket server, GUID 사용.

💬개인적으로 “대규모 시스템 설계” 책을 스터디 하고 있었고 딱 이번 주에 책 완독을 끝냈는데 현업 개발자님의 전문적인 시선으로 책 내용을 잘 정리하여 설명해주셔서 완벽하게 책 내용을 이해할 수 있었습니다!

💙8) C++ 개발자가 바라보는 Rust

✔️C++과 Rust의 공통점
- 배우기 어려움 (CS 지식이 필요)
- OS를 만들 수 있는 언어 -> 메모리에 직접 접근이 가능
    - 커널을 만들 수 있는 언어 => 하드웨어 제어를 위해서는 메모리 직접접근이 가능해야함
- 컴파일 언어 -> GC 없음, 빠른 성능
- 멀티패러다임 언어 -> 객체 지향에 더 가까운 편, 함수형 패러다임 다수 지원 , 함수형 언어에 더 가까운편임, 상속을 지원하지 않지만 다형성을 제공한다.
- 메모리 관리에 대한 제어 -> 소유권이나 빌림 개념(기본 기능이 복사가 아니라 이동이 된다), 멀티 스레딩 지원
- 제로 비용 추상화 -> 컴파일 타임에 최적화한다.

✔️발표자님께서 느낀 rust의 좋은점
- 패키지 매니저 cargo
- 컴파일 타임에 에러를 잡아준다.
- 빠른 성능
- 간결한 코드
- FFI(Foreign Function Interface) -> 다른 언어에 있는 것들을 가져다 쓸 수 있다.

✔️Rust의 단점
- 빌드 시간이 오래 걸린다.
- 진입장벽이 높다. -> 헷갈리는 개념이 많다.
- Unsafe -> 핵심 기능으로 소개하고 있지만 unsafe는 c++과 다르지 않음
- rust는 C++의 대안이 될 수 있는가?

✔️Rust의 미래
- AI 생태계 -> 파이썬의 성능 이슈가 조금씩 부각되고 있는데 대안이 될 수 있음
- WebAssembly
- Embedded system

💬Rust에 대해서 들어만봤는데 정말 장점이 많은 언어인 것 같습니다! lifetimes를 직접 개발자가 선언해야한다는 게 흥미로웠습니다! 정말 안전한 언어라는 걸 몸소 느낄 수 있었고 어렵더라도 한 번 배워보고 싶은 생각이 들었습니다! (커뮤니티에서만 보던 데보션 영감님을 볼 수 있어서 좋았습니다 ㅎㅎ)

💙9) OpenLLM / RAG 업무 필요 사례 

✔️Advanced RAG

- RAG의 한계(정확도가 떨어짐, 할루시네이션) 극복
- Retrieval 질을 향상시키기 위한 방법
- 정확한 정보를 전달하기 위함
    - Pre-Retrieval
        - Multi-Query -> LLM을 통해 쿼리를 추가로 생성하여 답
        - HyDE -> LLM을 통해 가상의 답변을 생성하고 이를 이용
    - Post- Retrieval
        - Rerank -> Context 유사도 계산을 통해 재정렬하여 전달

✔️요소

- Embedding - BAAI/be-m3 사용
- Kiwi 적용
- Chunk- 특징에 맞게 overlap 변수 지정 필요
- Hybrid search -> 2개의 리트리버를 조합하여 최적의 결과를 도출한다. , (sparse + dense) 리트리버 조합 이용
- Rerank -> 다시 유사도 검사를 하여 배치하고 최종 Context 결과를 뽑는다.
- Prompt -> 명확하게 표시를 해야한다.
- 모델 -> Llama 3.1 사용

✔️결과

- Naive RAG가 가지고 있는 문제점 해결 가능
- 보안적인 이슈 해결
- LLM을 베이스로 하는 다양한 기능 제작 가능
- 여러 분야에 응용 가능
    - Q&A, 요약, 코딩 어시스턴트 등..

💬 gpt를 사용하지 않고 직접 챗봇을 만드셨다는 점이 놀라웠습니다! 한 번 개발해서 끝내는 것이 아니라 회사에 적용하려고 하시는 것을 보며 커뮤니티에서 시작된 물결이 실제 회사 업무로 이어지는 모습을 볼 수 있어서 신기했습니다! 

준비해주신 데보션과 스터디 내용을 공유하고 프로젝트 데모를 진행해주신 스터디 팀원분들, 정말 감사합니다! 고생많으셨습니다! 🙇‍♀️