시스템 디자인 첫걸음 with LLM: 운영 가능한 AI 서비스(RAG·AI Agent) 아키텍처 설계하기
안녕하세요, 좋은 강의 잘 듣고 있습니다. LLM 서비스의 핵심 목표 중 신뢰성 의 핵심 키워드로 정확성, 일관성, 안정성 세 가지를 말씀해 주셨는데요, 이 중 정확성과 일관성이 각각 어떤 의미인지 좀 더 자세히 여쭤보고 싶습니다. 특히 앞에서 설명해 주신 것처럼 LLM은 확률에 기반을 두기 때문에 응답이 매번 바뀔 수밖에 없는데, 이런 전제 위에서 궁금한 점이 두 가지 있습니다. 일관성을 실제로 어떻게 구현할 수 있는지 궁금합니다. 실무에서 주로 쓰이는 방법이 있을까요? 일관성을 판단할 수 있는 지표나 기준, 기법이 있는지 궁금합니다. 신뢰성 지표로 Hallucination Rate, Faithfulness, Context Precision/Recall을 소개해 주셨는데, 이들은 주로 정확성 쪽에 가까워 보여서 일관성은 어떤 방식으로 측정하는지 궁금합니다. 감사합니다.
AI 시대에도 살아남는 엔지니어의 조건, 미국 빅테크 시스템 디자인, 알고리즘 사고, 오픈소스 실무 완성
안녕하세요 수업 내용중에 포함된 Slide와 설명이 맞지 않는 부분이 있는거 같아서 문의 드립니다. 영상에서는 단점으로 Vertical scaling만 가능하다고 언급하셨는데, 슬라이드에서는 수평적으로만 확장이 가능하다고 하셔서요. 제가 생각하기에도 하나의 코드 베이스에서 모든 기능이 작동해야하다 보니 Vertical scaling이 맞는거 같고 Slide내용이 잘못된거 같은데, 제가 잘못이해하고 있는것인지 확인부탁드리겠습니다. 이제 막 시작했지만 열심히 완주해보겠습니다. 감사합니다.
미국 빅테크 프론트엔드 시스템 디자인 실전: 단순 구현자로 남지 않기 위한 프론트엔드 개발자를 위해
먼저 좋은 강의 감사합니다. Monolith와 Modular 까지는 코드나 폴더구조들이 대충 상상이 가는데 MFE 1 강의를 들었을때 필요성이나 고려사항 등등 이론적으로 이해를 했으나 강의 2에서 remote나 shell 은 설명만으로 어떤식으로 프로젝트가 세팅되는지 이해가 잘안되네요. 정말 간단하게 코드 구현하는 강의 추가해주시면 안될까요
안녕하세요, 좋은 강의 감사드립니다. 현재 해외 취업을 목표로 시스템 디자인 인터뷰를 준비 중인 수강생입니다. 낯선 문제를 만났을 때 하이레벨 디자인에서 딥다이브로 넘어가는 과정에 어려움이 있어 조언을 구하고자 합니다. 강의 시퀀스인 [요구사항 정의 -> 하이레벨 디자인 -> 딥다이브(API, 모델링 등) -> 리뷰]를 준수하며 연습하고 있으나, 익숙하지 않은 도메인에서는 하이레벨 디자인 단계에서 예외 케이스나 컴포넌트를 제대로 커버하지 못하는 경우가 많습니다. 그러다 보니 딥다이브(c)를 진행하는 도중에 설계 오류를 발견하고 다시 하이레벨(b)을 번복하게 됩니다. 처음 보는 문제에서도 하이레벨 디자인을 탄탄하게 잡고 갈 수 있는 접근법이나, 이러한 번복 플로우를 줄일 수 있는 인터뷰 팁이 있을지 여쭤보고 싶습니다.
미국 빅테크 프론트엔드 시스템 디자인 실전: 단순 구현자로 남지 않기 위한 프론트엔드 개발자를 위해
안녕하세요, 강사님. 강의 잘 보고 있습니다. Design a Toast Notification System 미션을 진행하고 있는데요, 작성한 내용을 채점하고 리뷰하기 위한 프롬프트가 있으면 좋을 것 같습니다. 강사님의 미션 평가 기준이 담긴 프롬프트로 커리큘럼을 잘 따라가고 있는지 점검하는 기회, 강사님과 수강생의 시간을 모두 아낄 수 있지 않을까 생각이 들어서 의견 남깁니다. 남은 강의도 잘 보겠습니다. 좋은 강의 제공해주셔서 감사합니다!
AI 시대에도 살아남는 엔지니어의 조건, 미국 빅테크 시스템 디자인, 알고리즘 사고, 오픈소스 실무 완성
WhatsApp 채팅 아키텍처 설계에 대한 질문입니다. 영상에서는 참가자가 ws 서버에 메시지를 보내면 바로 Redis pub/sub으로 들어가고, 람다나 Stream을 통해 DB로 저장하는 방식을 설명하고 있습니다. 하지만 DB 저장에 앞서 채팅방 참가 여부 검증, 메시지 전송 차단/해제, 구독자만 전송 가능 등의 검증(validation)이 필요 한 경우가 있을 것 같습니다. 또한 이 경우 사용자에게 메시지 전송 실패/불가라는 즉각적인 피드백 도 제공해줘야 할 것입니다. ws 서버에서는 보통 검증 로직은 담당하지 않는 것으로 알고 있는데, 이 경우 어디에 검증 로직을 넣는 게 적당 할까요?
안녕하세요. 강사님 캐시전략 - Write-behind 전략을 설명해주셨는데, 인스타라이브나 유튜브라이브에서 좋아요를 한 사용자가 여러번 누를 수 있는데, 이때가 아마 Write-behind 전략을 적용할 수 있을 거 같습니다. 1. 좋아요를 레디스 캐시에 카운트 증가 2. 좋아요 누른 개수를 몇 초마다 flush로 카프카 큐에 발행 3. 카프카 consumer에서 db저장 이런 방식으로 설계가 가능할 거 같습니다. 강의에서는 Write-behind DB에 나중에 저장한다고 말씀하셨는데 그럼 이런 라이브 상황에서 DB에 좋아요를 언제 저장하는 것이 바람직할까요? 그 기준을 어떤 식으로 잡으면 좋을지도 선생님의 고견이 듣고 싶습니다. 좋은 강의 감사합니다.
안녕하세요, 선생님! 강의 들으면서 Service 및 Cache Handler 구성간 Create/Update <-> Delete 간의 Return Record 여부 차이에 대해 질문드리고자 합니다. 서비스도 그렇고, 핸들러도 그렇고, Return type이 Create/Update는 전달받은 Record를 Entity Context에 적용한 객체인데, delete의 경우 void로 운용하시는 것을 보고 어떤 차이점이 있는지 궁금하여 질문드리게 되었습니다. create, update 모두 반영 이후의 내역을 바로 반환하여 보여준다는 의미로 생각하였는데, delete를 보면 그런 것 같지는 않아서 따로 다른 의미가 있는지(실무에서 이렇게 많이 사용한다던가), 별 의미가 없는지 구체적으로 문의드리고자 합니다. 감사합니다.
안녕하세요, 선생님! 6강 해시태그 모델을 배운 후 데이터 분산 정도와 트랜잭션 일관성의 trade off에 대한 선택이 생각났고, 이에 대한 선생님의 고견은 어떠하실지 궁금하여 질문 올리게 되었습니다. 질문 내용은 아래와 같습니다. 데이터 편중도 크고 vs 트래픽이 많이 발생하여 트랜잭션까지 고려해야할때 샤딩키를 어떤 것으로, 어떤 부분을 tradeoff의 우선순위로 지정하는 것이 좋을지 저의 경우 트래픽을 선택할 것 같은데, 데이터 편중에 대해 추가적인 보완사항이 있다면 어떤 것이 있을지 일단 강의의 경우, 제가 이해한 내용으로는, 해시태그 모델과 같이, PK/FK의 분산 정도가 비슷하고, 부모 속성(FK)에 의한 쏠림 현상이 발생하여도 그 규모가 충분히 크지 않으므로 쓰기 경로를 중점적으로 고려하여(동일 게시글에 대한 해시태그를 동일 샤드에 저장) 설계한다. 이와 같습니다. 저는 해시태그 모델과 함께, 다른 예를 들어, 하루에 50,000건의 거래가 이루어지는 대규모 거래가 발생하는데, 이를 거래 게시판을 각 도메인 별(화장품/전자기기 등)로 별도로 만들어서 한 거래게시판 당 하루에 10,000건의 게시글, 1개의 1000~2000개의 찜이 발생한다고 하였을때의 상황에 대해 생각해보았습니다. 제가 만약 실무에서 찜 DB를 설계한다고 가정하고, 이에 대해 대응한다고 하였을때, 1) 게시글 ID와 찜(누가 찜했는지 구분해야 함, 찜ID로 구분한다고 가정하면)의 트래픽이 한 한 게시글 기준 찜 몇천여개, 게시글 총 만여개의 수준으로 발생하여 규모가 충분히 작다고 볼 수 없습니다. 2) 따라서 데이터 쏠림 현상에 대해 고민을 안할래야 안할 수가 없고, 그러면서도 데이터의 균등한 샤딩에 대해서도 고민이 들게 되었습니다. 3) 결국 데이터 분산을 균등하게 하느냐, 쏠림이 발생하더라도 쓰기 트래픽의 성능과 일관성, 조회 성능의 이점이 큰 것인가를 선택해야 하는데 4) 분산을 선택하지 않고, 트래픽 성능/일관성/조회 성능을 생각하였을때, 확실히 단일 데이터베이스에 있을때 성능적인 측면에서도 좋고, 일관성, 특히 조회 시 별도의 CQRS 전용 쿼리모델이나 DB를 따로 두지 않고 인덱스도 따로 설계하지 않는 등 훨씬 엄청난 이점이 될 것으로 판단이 됩니다. 따라서, 분산 정도 대신 성능 쪽으로 결론짓고 샤딩 키를 찜 ID 대신 게시글 ID로 지을 것 같습니다. 대신, 엄청난 트래픽으로 인해 데이터 편중이 너무 커진다면 게시글 생성일자를 샤드키로 추가하여 데이터를 좀 더 세부적으로 분리할 것 같습니다(아니면 더 좋은 방안이 있을지). 이에 대해 선생님의 생각이 궁금하여 질문드리게 되었습니다! 감사합니다.
