내부 API를 ClusterIP로만 배포한 이유

메일 발송 API를 여러 도구가 나눠 쓰게 만들면서 자연스럽게 따라온 질문이 있었다. "이 API를 외부에도 열어야 하나?" 답은 의외로 간단했다. 이 API를 실제로 부르는 쪽은 전부 같은 클러스터 안에서 돌아가는 다른 서비스들이었고, 클러스터 밖에서 이 API를 불러야 할 이유는 하나도 없었다. 그래서 외부로 통하는 경로 자체를 아예 만들지 않기로 했다.인증을 쌓은 뒤에도 남아 있던 질문이 메일 발송 API는 처음부터 "Bearer token만 검증하면 충분하다"고 생각하고 만든 게 아니었다. 메일 발송은 요청이 성공하는 순간 조직 바깥의 실제 수신함에 도달해 되돌릴 수 없는 효과를 만든다는 걸 운영하면서 체감했고, 그래서 토큰 검증 위에 호출자 allowlist, 수신자 수 상한, rate limi..

로그인 없이도 학습 이력을 분리해서 저장한 방법

학습 이력을 학생 계정과 연결하지 않고도, 서로 다른 학생의 기록이 섞이지 않게 만들어야 했다. 답은 로그인 시스템을 새로 붙이는 것이 아니라, 브라우저 단위의 익명 세션과 배포 경로별 저장소 분리였다.고등학생 대상 학습 앱을 만들면서 사용자마다 오답, 진도 같은 학습 이력을 구분해서 보여줘야 했다. 가장 먼저 떠오른 방법은 당연히 로그인이었다. 하지만 이 앱은 처음부터 독립 도메인에 배포되는 서비스가 아니라, 부모 서비스의 하위 경로에 그대로 얹혀 실행되는 포터블 데모 앱으로 설계돼 있었다. 회원가입, 비밀번호 찾기, 세션 관리까지 갖춘 완전한 계정 시스템이나 Central Auth 연동을 이 데모 앱 하나를 위해 새로 붙이는 일은, 얻는 것보다 짊어질 게 더 많아 보였다.그래서 요구 자체를 다시 나눠..

"공개 Ingress 없음"이라 적어놓고 실제로는 열려 있던 문서와 배포의 괴리

설계 문서에는 분명히 이렇게 적혀 있었다. "이 인증 서비스에는 공개 Ingress를 두지 않는다." 외부에서 곧바로 두드릴 수 있는 경로를 만들지 않고, 다른 서비스가 내부 통신으로만 신원을 확인하러 오게 하겠다는 원칙이었다. 그런데 요구사항과 설계 항목을 다시 검증하면서 실제 배포 상태를 하나씩 대조해 보니, 이미 떠 있는 Ingress가 하나 있었다. 관리자가 브라우저로 들어가 계정을 관리하는 화면으로 이어지는 통로였다.물론 아무나 들어올 수 있는 구조는 아니었다. 접근을 허용한 IP 대역이 화이트리스트로 걸려 있었고, 그 범위 밖에서 오는 요청은 그 앞에서 막혔다. 그래도 이 사실은 남는다. "공개 Ingress 없음"이라고 적어 둔 문서와, "화이트리스트로 제한된 공개 Ingress가 이미 존재..

자동 재시도를 일부러 만들지 않은 이유

AI가 작업을 처리하는 자동화 시스템을 만들다 보면 자연스럽게 떠오르는 질문이 하나 있다. "작업이 실패하면, 시스템이 알아서 한 번 더 시도하게 만들면 안 되나?" 나도 처음엔 당연히 그래야 한다고 생각했다. 하지만 결국 이 기능은 만들지 않기로 했다. 실패한 작업은 실패한 채로 남겨두고, 사람이 다시 해달라고 명시적으로 요청할 때만 재작업이 일어나게 했다. 이유는 하나다. 실패를 다시 처리할지 말지의 판단을 시스템이 아니라 사람이 쥐고 있어야 한다고 봤기 때문이다.자동 재시도가 당연해 보였던 이유이 판단을 하기 전에, 나는 이미 자동 재시도가 잘 동작하는 구조를 다뤄본 적이 있다. 배포 자동화에서 Deployment rollout이 실패하면, 완료 상태를 기록하지 않고 그대로 두는 것만으로 다음 폴링..

동기화 자동화를 만들 때 먼저 정해야 하는 건 "무엇을 하게 만들 것인가"가 아니라 "무엇을 못 하게 막을 것인가"였다. 처음엔 이 순서가 이상하게 느껴졌다. 자동화를 만드는 목적은 결국 뭔가를 하게 만드는 건데, 왜 못 하게 만드는 것부터 정하나 싶었다. 그런데 외부 저장소의 변경을 감지해서 클러스터 안 콘텐츠를 갱신하는 자동화를 실제로 붙여보고 나서, 이 순서가 뒤바뀌면 안 되는 이유를 몸으로 확인했다.이런 자동화는 대개 두 개의 경계를 넘나든다. 하나는 외부 저장소에서 소스를 가져오는 경계고, 다른 하나는 클러스터 내부 자원(ConfigMap, Deployment 등)을 갱신하는 경계다. 두 경계 모두 "이 자동화가 무엇을 할 수 있는가"를 결정하는 자격증명이 필요하고, 그 자격증명을 어떻게 발급하..

같은 챗봇 안에 교과서 기반 학습 질문에 답하는 기능을 붙이면서, 처음에는 "잘 답하기만 하면 된다"고 생각했다. 그런데 실제로 학생이 쓰는 모습을 지켜보다 보니, 잘 답하는 것과 믿을 수 있게 답하는 것은 다른 문제였다.수식 렌더링과 답변 복사 기능을 다듬으면서 이미 한 번 배운 게 있다. AI 답변은 생성 모델이 잘 만들어내는 것으로 끝나지 않고, 그걸 어떻게 보여주고 어떻게 옮겨 쓸 수 있게 하느냐까지가 답변 품질의 일부라는 것이다. 교과서 학습 기능에서도 같은 문제가 다른 얼굴로 나타났다. 이번에는 "얼마나 맞는 답인가"가 아니라 "이 답을 학생이 믿고 넘어가도 되는가"였다.그럴듯한 답과 확인 가능한 답은 다르다학생이 교과서 내용을 물어보면 챗봇은 대체로 그럴듯한 문장을 만들어낸다. 문제는 그 문..