조용한 개발 노트

1편부터 8편까지의 이야기를 한 문장으로 줄이면 이렇다.LLM은 똑똑한 존재가 아니라, 잘 설계된 시스템 안에서만 쓸 수 있는 컴포넌트다.이 마지막 편에서는 지금까지 쌓아온 모든 논의를 “그래서 실무에서는 어떻게 배치해야 하는가”라는 질문으로 수렴시킨다.1. LLM이 맡아도 되는 역할LLM이 가장 잘하는 일은 명확하다.주어진 정보 안에서 텍스트를 재구성한다여러 후보를 빠르게 생성한다사람이 읽기 좋은 형태로 정리한다이 역할에는 공통점이 있다.틀려도 즉시 치명적이지 않다그래서 LLM은 이런 위치에 잘 어울린다.초안 생성기요약기후보 추천기인터페이스용 자연어 변환기이 영역에서는 완벽함보다 속도와 생산성이 중요하다.2. LLM에게 맡기면 안 되는 역할반대로, LLM이 절대 맡아서는 안 되는 역할도 명확하다.사실의..

6편까지의 결론은 명확하다.LLM은 언제든 틀릴 수 있고, RAG를 붙여도 그 가능성은 사라지지 않는다.이 지점에서 다음 질문이 나온다.“그럼 이걸 어떻게 운영에 넣을 수 있는가?”1. LLM 출력은 항상 실패할 수 있다는 전제부터 깔아야 한다LLM 기반 시스템에서 가장 위험한 가정은 이거다.“대부분은 맞을 것이다”운영 관점에서는 이 문장이 이렇게 번역된다.“언젠가는 반드시 사고가 난다”그래서 LLM 출력은 처음부터 이렇게 다뤄야 한다.항상 틀릴 수 있다틀렸을 때 감지할 수 있어야 한다감지했을 때 피해가 제한돼야 한다이게 가드레일의 출발점이다.2. 출력 검증은 “맞는지 확인”이 아니라 “위험한지 감지”다많은 팀이 출력 검증을 이렇게 접근한다.“정답인지 확인하자”대부분 실패한다. 정답 여부를 자동으로 판단..

보이지 않는 시스템은 운영할 수 없다Event-driven Architecture를 도입하면 시스템은 눈에 띄게 느슨해진다.호출 관계가 사라지고비동기 처리로 전환되며즉각적인 응답 경로가 끊어진다이 순간부터 새로운 문제가 등장한다.지금 이 이벤트는 어디까지 처리되었는가Event-driven 시스템에서 Observability는 선택이 아니라 운영의 전제다.왜 기존 모니터링은 충분하지 않은가동기 호출 기반 시스템에서는 다음 정보만으로도 운영이 가능했다.요청 성공 여부응답 시간에러율하지만 Event-driven 시스템에서는 이 정보들이 거의 의미를 잃는다.요청과 처리가 분리된다성공 시점이 명확하지 않다실패가 즉시 드러나지 않는다Observability의 관점이 바뀌어야 한다.Event-driven Observ..

보안 사고는 조용히 시작된다많은 보안 사고는 이렇게 발견된다.데이터가 이미 유출된 뒤권한이 오랫동안 오남용된 뒤외부 제보가 들어온 뒤이는 보안 장치가 없어서가 아니라, 보안 상태를 관측하지 못했기 때문이다.보안에서 가장 중요한 질문보안에서 가장 중요한 질문은 이것이다.지금 무슨 일이 벌어지고 있는가차단 규칙이나 암호화는 이 질문에 답하지 못한다.Observability는 보안 사고를 인지 가능하게 만드는 전제다.왜 보안 사고는 감지되지 않는가보안 사고가 감지되지 않는 이유는 단순하다.정상 트래픽과 구분되지 않는다부분적으로만 발생한다오랜 시간에 걸쳐 누적된다즉, 보안 사고는 시스템 장애처럼 보이지 않는다.보안 관점의 Observability는 무엇이 다른가일반적인 Observability는 성능과 안정성에..

잘 설계된 시스템과 운영 가능한 시스템은 다르다분산 시스템은 설계만으로 완성되지 않는다.아무리 이론적으로 완벽해 보여도, 운영 단계에서 다음 질문에 답하지 못하면 실패한다.문제가 생겼을 때, 우리는 무엇을 보고 어떻게 판단하는가이 글에서는 지금까지 다룬 모든 개념을 운영 가능성이라는 하나의 기준으로 정리한다.운영 가능성의 출발점은 실패 수용이다운영 가능한 시스템은 실패를 막으려 하지 않는다.Partial Failure는 항상 존재한다지연과 중복은 제거할 수 없다일부 요청 실패는 정상 상태다운영의 목표는 실패를 통제 가능한 상태로 유지하는 것이다.SLO는 왜 필요한가운영 가능한 시스템은 성공과 실패를 감정이 아니라 수치로 정의한다.이를 위해 등장한 개념이 SLO(Service Level Objective)..

보이지 않으면 통제할 수 없다분산 시스템은 정상과 비정상의 경계가 흐리다.일부 요청만 실패한다특정 구간에서만 지연이 발생한다장애는 천천히 퍼진다이런 환경에서 단순한 모니터링만으로는 무엇이 일어나고 있는지 알 수 없다.그래서 분산 시스템에서는 Observability가 필수가 된다.Observability는 모니터링이 아니다모니터링은 보통 다음 질문에 답한다.CPU 사용률은 얼마인가에러율이 증가했는가서버는 살아 있는가하지만 분산 시스템에서 더 중요한 질문은 이것이다.왜 이 요청이 실패했는가Observability는 내부 상태를 추론할 수 있는 능력을 의미한다.왜 분산 시스템은 본질적으로 불투명한가분산 시스템은 다음 이유로 본질적으로 불투명하다.요청이 여러 서비스와 노드를 거친다부분 실패가 정상 동작처럼 보..

Kafka 시리즈의 마지막이다. 지금까지 우리는 Kafka의 설계 의도부터 Consumer Group, Offset, Exactly-once, 스토리지, OS, 관측, Kubernetes까지 한 바퀴를 돌았다.그럼에도 현장에서 가장 많이 듣는 말은 이것이다.“Kafka를 도입했는데, 오히려 장애가 더 늘어났다.”이 문장의 핵심은 Kafka가 아니다. 기대와 현실의 불일치다.이유 1. Kafka를 메시지 큐로 기대했다Kafka는 메시지를 전달하는 시스템이 아니라 이벤트를 기록하는 로그다.그럼에도 많은 설계는 다음을 전제로 한다.한 번만 처리될 것이다처리되면 사라질 것이다브로커가 상태를 관리해줄 것이다이 기대는 Kafka의 로그 모델과 충돌한다. 결과는 중복 처리, 오프셋 혼란, 리밸런스 폭증이다.이유 2...

9편에서 Kafka의 관측이 어려운 이유와 Consumer Lag이 왜 자주 오해되는지를 살펴봤다. 이제 많은 팀이 실제로 부딪히는 환경으로 들어가 보자.“Kafka를 Kubernetes에 올렸더니, 예전보다 장애가 더 잦아졌다.”이 문제는 Kafka나 Kubernetes 중 하나가 나빠서가 아니다. 상태를 가진 시스템(stateful system)을 무상태 플랫폼(stateless-first)에 올렸기 때문이다.Kubernetes는 본질적으로 무상태를 전제로 한다Kubernetes의 설계 전제는 명확하다.Pod는 언제든지 죽을 수 있다다시 뜨면 새 인스턴스다상태는 외부에 있어야 한다이 전제는 웹 서버나 API 서버에는 매우 잘 맞는다. 하지만 Kafka는 다르다.Kafka는 디스크에 상태를 가진 시스템..

8편에서 Kafka 성능 문제의 상당수가 JVM이 아니라 OS·운영 환경에서 발생한다는 이야기를 했다. 그런데 현장에서 가장 자주 마주치는 질문은 이거다.“Lag이 늘었는데, 어디가 문제지?”Kafka에서 관측이 어려운 이유는 도구가 부족해서가 아니다. 지표가 무엇을 의미하는지 오해하기 쉽기 때문이다.Consumer Lag은 무엇을 말해주는 지표인가Consumer Lag은 단순히 말하면 브로커에 쌓인 데이터와 소비자가 읽은 위치의 차이다.Lag = 아직 읽지 않은 메시지 수Lag = 처리 대기 중인 작업량여기까지는 맞다. 하지만 많은 오해는 여기서 시작된다.Lag이 크다고 반드시 장애는 아니다Kafka의 로그 모델을 떠올려보자.데이터는 삭제되지 않는다소비자는 자기 속도로 읽는다이 구조에서는 Lag이 일시..

Kafka를 처음 접하면 흔히 이렇게 부른다. “대용량 메시지 큐”.하지만 이 표현은 Kafka를 이해하는 데 가장 빠르게 길을 잃게 만드는 출발점이다.Kafka는 메시지 큐가 아니다. Kafka 공식 문서에서 반복해서 강조하는 모델은 분산 로그(distributed commit log)다.메시지 큐의 사고방식전통적인 메시지 큐는 다음 질문에 초점을 맞춘다.메시지를 누가 가져갈 것인가한 번만 전달되었는가처리되면 삭제되었는가큐의 핵심은 중간에서 메시지를 관리하는 것이다. 브로커는 “이 메시지는 누가 가져갔는지”를 기억한다.소비자는 수동적이다. 메시지는 밀려오고(push), 소비자는 받아서 처리한다.Kafka의 사고방식은 다르다Kafka는 처음부터 이 질문을 다르게 던진다.“데이터를 어떻게 오래, 많이, 안..