LLM 서비스의 신뢰성

안녕하세요 도현님. 좋은 질문 남겨주셔서 감사합니다!강의에서 신뢰성과 관련된 키워드로 정확성과 일관성을 언급했었는데요, 간단하게 정확성은 “응답 내용이 사실이나 서비스의 요구사항과 일치하는가”의 의미로, 일관성은 “같은 조건에서 서비스가 모순되지 않는 응답을 주는가”의 의미로 언급한 것이었습니다. 예를 들어 같은 대화 내에서 일관되지 않은 응답을 주거나 같은 질문을 물어봤을때 매번 핵심 내용이 다른 대답을 하면 서비스 신뢰성이 떨어질 수밖에 없으니까요.일관성을 높이기 위한 방법은 먼저 강의의 모델 선택 & 서빙 챕터에서도 설명했듯이 Temperature와 같은 샘플링 파라미터를 조절하여 같은 입력에 대해 LLM 출력의 랜덤성을 줄이는 방법이 있습니다. 그런데 사실 이것보다 더 중요한건 시스템을 설계할 때 일관되어야 하는 부분과 LLM의 확률성을 허용할 수 있는 부분을 나누는 것이라고 생각합니다. 예를 들어 정책과 같이 항상 동일해야하는 정보는 DB나 API 같이 명확한 Source of Truth에서 가져오도록 결정론적으로 설계할 수 있습니다. 마찬가지로 주문 가능 여부를 확인하거나 가격을 계산하는 것처럼 명확한 비즈니스 로직이 정해져있는 작업도 LLM이 직접 판단하기보다는 API나 Tool을 호출하여 일관되게 처리하도록 설계할 수 있습니다. LLM의 응답은 단위 테스트로 검증하기 어렵지만 이렇게 결정론적으로 구현할 수 있는 부분을 나눠서 단위 테스트를 통해 검증하면 변경으로 인한 회귀도 방지할 수 있다는 장점이 있습니다. 일관성의 측정은 정확성과는 조금 다르게 미묘한 부분이 있습니다. 실제 LLM 서비스를 평가할때 일관성 자체를 단일 지표로 측정하기보다는, 먼저 해당 서비스가 의도한 대로 올바른 응답을 하고 있는지 정확성 지표들을 평가하고, 필요한 경우 일관성을 추가적으로 측정하는 방식​으로 접근하는 경우가 많습니다. 예를 들어 소설이나 광고 문구를 생성하는 서비스라면 매번 다른 표현을 생성하는 것이 자연스럽기 때문에 일관성 측정의 필요성이 낮을 수 있지만, 이력서 평가 서비스나 데이터의 이상 징후를 분석하는 서비스처럼, 동일한 입력에 대해 일정한 판단 기준과 논리를 유지해야 하는 서비스라면 반복 실행에 따른 결과의 변동성을 별도로 평가할 필요가 있을 것입니다.일관성 측정 지표는 정확성과 같이 몇 가지 지표로 표준화되어 있는 것은 아니어서 서비스에서 어떤 부분의 일관성이 중요한지를 먼저 정의하고 거기에 맞는 평가 지표를 만들어야합니다.분류나 점수처럼 결과가 정형화되어 있다면 동일한 입력을 여러 번 실행하여 동일한 결과가 나온 비율을 측정할 수 있고, 자연어 응답이라면 응답 간 의미적 유사도를 비교하거나 서로 모순되는 내용이 있는지(Contradiction Rate) 측정할 수도 있습니다. 평가에는 NLI(Natural Language Inference) 모델이나 LLM-as-a-Judge 등을 활용할 수 있습니다. 그리고 대화형 서비스라면 이전 대화에서 언급한 정보나 판단이 이후 답변에서도 일관되게 유지되는지(Cross-turn Consistency)를 평가 지표로 사용할 수도 있습니다.LLM 의 정확성, 일관성을 보장하고 측정하는 방법은 추후 ​섹션 6 부분에서도 좀 더 다룰 예정이니 참고해주시면 좋을 것 같습니다! 감사합니다.

캐시전략 - Write-behind

안녕하세요 gunsung53님.말씀하신 상황은 일반적인 좋아요/싫어요 기능보다는 사용자가 좋아요를 연속해서 누를 수 있는 리액션 기능에 가까운 것으로 이해했습니다. 이런 경우에는 짧은 시간 동안 많은 쓰기 요청이 발생할 수 있고, 사용자는 현재 수치를 준실시간으로 확인하길 원하기 때문에 말씀해주신 것처럼 Write-behind 전략이 잘 어울리는 사례로 보입니다.“DB에는 언제 저장하는 게 좋을까?”에 대한 기준은 결국 서비스가 어느 정도 데이터 유실을 감당할 수 있느냐에 따라 달라질 것 같습니다. 예를 들어 말씀해주신 인스타 라이브 같은 케이스는 정확한 숫자 자체보다는 “실시간으로 좋아요 수가 올라가는 느낌”이 더 중요할 수 있습니다.그래서 장애가 발생하더라도 “1~2초 정도의 유실은 감당 가능하다” 혹은 “몇백 건 정도의 좋아요 수 차이는 감안한다” 정도로 기준을 정하고 운영할 수 있습니다. (어디까지 허용할지는 비즈니스적으로 결정해야 하는 부분인 것 같습니다. 만약 인프라적인 제약이 있다면 Kafka 지연이나 DB 부하 상황을 보면서 정책을 조정하기도 합니다.)Kafka에 어떤 메시지를 보내는지에 따라 DB에 flush 하는 전략은 달라질 수 있겠지만, 이벤트가 1000건 이상 쌓이거나최대 2초가 지나면좋아요 증가량(delta)이 일정 수준 이상 차이나면flush 하는 전략을 사용할 수 있습니다. (보통은 batch size 조건과 flush timeout 조건을 OR로 조합해서 많이 사용합니다)좋은 질문 감사합니다 😊

유저 별 포인트

안녕하세요 KMC님,정합성이 중요한 데이터를 어떻게 신뢰성 있게 관리할 수 있을지, 그리고 그 고민을 어떻게 프로젝트 설명에 녹여낼 수 있을지를 질문주신 것으로 이해했습니다. 포인트나 금액같이 민감한 데이터의 경우, 정합성을 어떻게 지킬지나 정합성이 틀어졌을 때 어떻게 감지하고 복구할 수 있을지에 대한 고민이 매우 중요합니다.스프링 배치를 사용한다고 하셨는데, 배치 실행 정보는 스프링 배치의 Job/Step 관련 테이블들로 관리되어서 이를 활용하면 자동 재시도 등을 통해 어느 정도 정합성을 보장할 수 있겠죠.하지만 배치 로직 자체에 문제가 있어 정합성이 깨진 경우 (예를 들어 특정 유저에게 포인트가 누락된 경우)를 파악하기는 어렵기 때문에 이런 경우에는 말씀해주신 대로 로그 테이블을 만들어 포인트 지급 이력을 남기는 방식을 고려할 수 있습니다.다만 지속적으로 대량의 로그를 테이블에 쌓는것이 좋은 방식일지 한 번 고민해보면 좋습니다. 데이터 관리 측면에서 부담이 될 수 있기 때문에 파일로 관리하거나 ELK와 같은 로그 수집 시스템과 통합하는 방식, 로그 데이터를 일정 기간만 보관하는 방식 등을 함께 고려해볼 수 있습니다.(배치가 이벤트 기반으로 동작하고, 이벤트 자체로 집계를 재수행할 수 있는 구조라면 굳이 지급 이력 로그를 별도로 남기지 않아도 될 수 있습니다.)결국 중요한 것은 정합성이 틀어진 경우에 어떻게 보정할 수 있을지 대비책이 마련되어 있는지입니다. 정리하자면, 왜 로그 테이블이 필요했는지, 그리고 실제로 어떤 문제가 발생했고 로그 테이블을 활용해 어떻게 정합성을 복구했는지를 설명한다면, 신뢰성을 확보하려는 고민이 드러나는 좋은 자소서 소재가 될 수 있을 것 같습니다.

인프라 관련 질문

안녕하세요, minseok5167님.많은 분들이 궁금해하실 부분인데 강의에서 언급을 안했었네요! 좋은 질문 남겨주셔서 감사합니다. 실무에서 성능 목표는 인프라 제약보다는 사용자나 비즈니스 요구사항에 맞추어서 설정하는 경우가 많습니다. 물론 인프라 제약도 고려하기는 하지만, 성능이 크게 떨어지는 수준이 아니라면 인프라는 추후 수평확장 등으로 대응할 수 있기 때문에 목표치 자체를 결정짓는 주요 기준은 아닌 경우가 많습니다. 개인적으로는 공부를 위한 프로젝트라면 성능 목표치의 숫자 자체보다는, 성능을 측정하고 병목을 찾아 개선하는 과정을 경험하는 것이 더 중요하다고 생각합니다.물론 프리티어를 사용해서 성능 테스트를 해볼 수는 있지만, 사실 CPU 1개, 메모리 1GB 정도로 리소스가 너무 제한적이다보니 부하를 주었을 때 CPU, 메모리, 디스크가 모두 바빠져서 어떤 자원이 병목인지 정확히 확인하기 어렵습니다. 이런 경우에는 성능 테스트를 해도 유의미한 결과를 얻기 어려울 수 있습니다.그래서 가능하다면 성능 테스트를 진행할 때만이라도 프리티어보다는 조금 더 성능이 좋은 (병목을 확인할 수 있을 정도의) 서버 환경에 배포해 테스트해보는 것을 추천드립니다. 병목을 발견하면, 해당 서버 스펙은 그대로 유지한 채 병목 지점을 개선한 후 다시 테스트해보는 방식이 좋을 것 같습니다. 그리고 덧붙이자면, 성능 테스트 결과는 수행한 방법이나 환경에 따라 수치가 크게 달라질 수 있기 때문에, 성능 테스트 결과를 작성할 때 이를 상세하게 함께 적어두면 보는 사람도 환경을 감안해서 성능 테스트 결과 수치를 더 잘 이해할 수 있을 것입니다.

MSA 전환 시점

안녕하세요 오늘님! 어려운 질문이네요 😄말씀해주신 것처럼 성능적인 이유나, 비즈니스 로직마다 적합한 기술 스택이 다른 경우 등 MSA를 도입할 이유는 다양합니다.하지만 개인적으로는 강의에서도 언급했듯이 도메인과 데이터가 가장 중요한 기준이라고 생각합니다. 조금 더 구체적으로 말하자면, 비즈니스가 성장하면서 데이터의 생명주기(데이터가 생성되고, 성장하고, 다른 데이터와 연결되는 흐름)가 명확히 구분되기 시작할 때가 MSA 전환을 고려(도입이 아닌!) 해볼 시점이라고 봅니다.이 시점이 오면 도메인별 데이터의 성장 속도나 방향이 달라지면서, 한 도메인의 변화가 다른 도메인에 영향을 주거나 개발/배포 과정에서 병목이 생기기 쉽습니다. 예를 들어 한 서비스의 작은 변경 때문에 전체 배포를 미루거나, 다른 개발자의 작업까지 영향을 받는 상황이 반복된다면 분리를 고려해볼 신호라고 생각합니다.그리고 개발 외적이지만 팀의 규모와 MSA 전환에 대한 구성원 간 합의 수준도 중요한 요소라고 생각합니다.MSA는 단순히 모듈 수만 늘어나는 것이 아니라, 각 서비스마다 별도의 설정, DB, 배포 파이프라인, 모니터링 체계 등이 필요해지고, 모듈 간 협업을 위한 개발자 간 커뮤니케이션 비용도 생깁니다.관리 포인트가 단순히 두 배가 아니라, 실제로는 세~다섯 배 이상 늘어나게 됩니다.그래서 팀 규모가 이런 복잡도를 감당할 수 있는지 (유지보수를 쉽게 하려고 분리했는데 정작 담당할 사람이 없는 상황이 생기지 않을지) 고민해봐야 합니다.그리고 어떻게 도메인을 분리할지에 대한 팀의 공감대가 형성된 시점에 전환을 고려해보는 것이 좋습니다. 아직 성숙하지 않은 서비스에서 각각의 도메인에 대한 정확한 이해 없이 성급히 분리하면 나중에 차라리 다시 합치는 게 낫겠다는 생각이 들 수도 있습니다.결론적으로는 분리로 인한 오버헤드를 감안하더라도 도메인과 데이터의 성장 관점에서 분리가 필수적이라는 확신이 팀 내에서 충분히 공유된 시점에점진적으로 정말 필요한 도메인부터 분리해 나가는 게 좋다고 생각합니다.

로드밸런싱 관련 질문

안녕하세요 etdong님,고객이 존재하는 실제 서비스 환경에서는 로드밸런서를 보통 처음부터 두는 경우가 많습니다. 단순히 트래픽 분산을 위한 용도뿐만 아니라, 가용성을 위해 보통 서버를 최소 2대 이상 두기 때문에 자연스럽게 로드밸런서를 두게됩니다.로드밸런서를 사용하면 여러 장점이 있는데, 예를 들어 SSL 처리가 간편해집니다. HTTPS 연결을 위해 각 서버마다 인증서 설치/설정을 해야하는 불편함이 있는데, 로드밸런서에 인증서를 설정해두면 뒷단 서버는 로드밸런서와 HTTP로 통신할 수 있습니다. (개별서버에 일일이 인증서를 설치하고 관리할 필요가 없어서 편리합니다.) 또, 서버가 한 대뿐이더라도 로드밸런서를 앞단에 프록시로 두고 시작하면 나중에 서버를 여러 대로 확장할 때 구조 변경이 훨씬 유연하다는 장점도 있습니다.꼭 L7 로드밸런서가 아니더라도 DNS나 L4 수준의 로드밸런서도 실무에서는 상황에 맞게 조합해서 사용되기 때문에, 트래픽이 많지 않더라도 어떤 형태로든 로드밸런서가 초기 설계에 거의 필수로 들어가는 편입니다.

도움 되었어요!

강의가 도움이 되었다니 다행입니다!공부하시다가 궁금한 점이나 더 깊이 알고 싶은 부분이 생기면 언제든 질문 남겨주세요~감사합니다!

멱등성. '같은 요청'의 기준?

안녕하세요, akakakak님.말씀해주신 것처럼, 기존 필드의 조합만으로는 동일한 요청인지 정확히 판단하기 어려운 경우가 많습니다. 그래서 API를 설계할 때 멱등성을 보장하는 대표적인 방법은 클라이언트가 요청 시 고유한 키를 함께 보내도록 하는 것입니다.이 외에도 시스템의 상태를 기반으로 멱등성 여부를 판단하거나, HTTP 메서드의 특성을 활용해 별도 처리가 필요 없는 방식도 있습니다.클라이언트가 요청에 고유한 키를 함께 보냄 (멱등성 키)예를 들어, 결제가 중복되지 않도록 하고 싶은 경우 클라이언트가 요청을 보낼 때 고유한 키(예: UUID) 를 만들어 함께 전송할 수 있습니다.서버는 이 키를 기준으로 중복 요청 여부를 판단해, 이미 처리한 요청이라면 다시 처리하지 않습니다.보통 서버는 이 키를 Redis 같은 캐시에 저장하고, 일정 시간 동안 유효하도록 설정해두는 경우가 많습니다.(이 방식은 10강 '서버와 서버 간 통신' 마지막 부분에서도 언급되니 참고해주시면 좋습니다.) 상태 기반 처리현재 시스템이 가진 데이터의 상태를 DB에서 확인해서 이를 기준으로 중복 요청 여부를 판단할 수도 있습니다.예를 들어, 주문을 '배송중'으로 업데이트하는 API에서 주문 123번이 이미 '배송중' 상태라면, 같은 상태로 변경하는 요청이 들어왔을 때 중복 요청으로 간주해 처리하지 않을 수 있습니다. 서버의 동작이 HTTP 메서드의 멱등성 의도에 맞게 구현HTTP 명세에서 PUT, DELETE, GET 등의 메서드는 같은 요청을 여러 번 보내도 같은 결과가 나와야 한다는 멱등성을 가진 요청입니다. 이 의도가 서버 API에 정확히 구현되어 있다면, 별도 처리 없이도 자연스럽게 멱등성이 보장될 수 있습니다.예를 들어, S3 같은 오브젝트 스토리지에 파일을 업로드할 때 'PUT /file1'처럼 같은 경로로 파일을 여러 번 업로드하더라도 기존 파일을 덮어쓰기 때문에 결과는 항상 같습니다.모든 API가 멱등성을 반드시 보장해야 하는 것은 아니므로,API의 역할과 도메인 특성을 고려해 필요한 경우에는 위 방법들 중 적절한 방식을 선택해 적용해줄 수 있습니다.