이루오 — 기록

Google Play 권고대로 최적화를 켰다. 로그인도 녹음도 채점도 확인했고, 결제만 안 눌러봤다. 열흘 뒤 매출을 보고 알았다.

내가 운영하는 오픽 말하기 연습 앱은 결제의 대부분이 스토어 인앱결제에서 나온다. 전체 기간 결제 54건 중 40건, 74%가 앱이다. 웹에도 결제 수단이 있지만 주력은 앱이다. 9월 1일부터 10일까지 안드로이드 결제가 0건이었다. 나는 열흘째 되는 날 밤에 알았다. Play Console 이 DEX 코드 최적화를 요구했다. 권고가 아니라 요구사항 형태로 올라와 있었고, 기한이 붙어 있었다. 8월 31일에…

신규 사용자가 가입 3분 뒤 다섯 번 연속 실패했다. 컨테이너를 바꿨더니 같은 사람이 또 실패했다.

내가 운영하는 오픽 말하기 연습 앱은 사용자의 답변을 녹음해서 모델에 보내고 평가를 받아온다. 녹음이 안 되면 제품이 없다. 9월 8일, 신규 사용자 한 명이 가입 3분 뒤부터 다섯 번 연속으로 분석에 실패했다. 서버 로그에는 모델 API 가 400 INVALID_ARGUMENT 를 돌려준 기록만 남아 있었다. 로그에 남은 실패 두 건이 있었고, 둘 다 iOS 였다. 18.7 과 18.7.1. 그럴듯한 가설이 바로 섰다.…

서버는 UTC 로 돈다. 그런데 사용자의 하루는 KST 로 시작한다. 이 어긋남이 여섯 군데에서 각각 다른 얼굴로 나타났다.

일주일 사이에 고친 버그 여섯 개가 있다. 증상은 전부 달랐다. 주간 랭킹이 월요일 아침에 갱신되지 않았다. 복습 카드가 예정일에 안 떴다. 크레딧이 무한정 충전됐다. 관리자 대시보드 숫자와 목록 숫자가 안 맞았다. 공지가 등록한 날부터 안 보였다. 리퍼럴 월 상한이 달이 바뀌었는데 안 풀렸다. 원인은 하나였다. 그리고 그 원인은 "UTC 를 썼다"가 아니었다. 이 앱의 서버는 서버리스 함수다. 타임존은 UTC 다.…

다계정 파밍이 의심됐다. 규모를 쟀더니 피해액이 $0.27이었다. 대책 대신 기존 방어 하나를 걷어냈다.

내가 운영하는 앱은 가입하면 무료 크레딧을 준다. 크레딧으로 AI 분석을 받고, 분석 한 번에 실비가 나간다. 사용자가 급증하자 예상된 질문이 따라왔다. 계정을 여러 개 만들어서 무료 크레딧만 빼먹는 사람이 있지 않을까. 의심할 근거는 있었다. 이름이 비슷한 계정 묶음이 보였고, 구글은 계정을 무한정 만들 수 있다. 대책 후보도 금방 나왔다. 기기 증명, 스토어 무결성 검사, IP 제한, 본인인증. 하나도 적용하지 않았다.…

의존성으로 쓸 수도, 포크할 수도 없었다. 세 번째 선택지를 골랐고, 그 대가로 지켜야 할 규칙이 생겼다.

기억 서비스의 저장·검색 엔진은 직접 만들지 않았다. 오픈소스 라이브러리를 가져다 썼다. 그런데 첫 글에서 쓴 대로, 그 라이브러리의 추출 프롬프트를 우리가 고쳐야 했다. 한국어가 영어로 추출되던 문제 때문이다. 여기서 선택이 갈린다. 의존성으로 쓰면 프롬프트를 못 고친다. 포크하면 고칠 수는 있지만, 시간이 지나면 "이게 원래 저랬나 우리가 고친 건가"를 아무도 모르게 된다. 세 번째를 골랐다. 코드를 저장소 안으로 통째로…

관리 콘솔은 배포완료라고 했고, 생성 API 는 200 을 돌려줬고, 라우트는 실제로 등록돼 있었다. 그런데 그 라우트에는 요청이 닿을 수 없었다.

한 고객사에서 신규 에이전트의 API 호출이 항상 404 를 반환한다는 문의가 왔다. 확인할 수 있는 건 전부 정상이었다. 관리 콘솔의 상태는 배포완료였고, API 접근 토글은 켜져 있었고, 등록 API 의 응답은 200 이었다. 같은 사이트의 다른 에이전트는 멀쩡했다. 404 의 첫 번째 용의자는 언제나 앞단이다. 라우팅 규칙이 잘못됐거나, 인그레스가 경로를 못 찾거나. 두 가지가 그걸 부정했다. 첫째, 파드 로그에 요청이…

아침 첫 대화에서만 취향 기억이 0건이었다. 에러 로그는 없었다. 이런 결함을 여섯 개 찾았고, 공통점이 하나 있었다.

버그 리포트는 이렇게 왔다. 에러 로그는 없었다. 5xx도 없었다. 응답은 200이었고, 기억 목록이 빈 배열이었을 뿐이다. 재현하려고 낮에 아무리 호출해도 잘 나왔다. 원인을 찾고 나서, 같은 성질의 결함이 다섯 개 더 있다는 걸 알았다. 벡터 저장소 커넥션 풀에 대여 전 검사가 없었다. 몇 시간 유휴 상태로 두면 서버 쪽에서 커넥션이 끊기는데, 풀은 그걸 모른 채 죽은 커넥션을 내준다. 첫 요청이 그걸 물고 실패한다. 설계…

유사도 0.85. 이 숫자를 어디서 가져왔냐는 질문에 "그쯤이 적당해 보여서"라고 답하지 않으려고 한 일.

지난 글에서 에이전트에 붙인 기억 서비스 이야기를 했다. 이번엔 그 안에 박혀 있는 숫자 하나에 대한 이야기다. 사용자가 "나 12월에 이사 가"라고 말하면 모델이 그 사실을 기억으로 쓴다. 그런데 지난달에 이미 "11월에 이사 간다"는 기억이 저장돼 있었다면? 새로 쓸 것인가, 기존 것을 덮을 것인가, 아니면 둘 다 남길 것인가. 판단 기준은 두 문장이 같은 사실인가이다. 그리고 그건 임베딩 유사도로 잰다. 그러면 몇부터…

한국어 대화에서 뽑은 기억이 영어로 저장되고 있었다. 지시문을 어디에 넣어도 소용없었고, 원인은 다른 곳에 있었다.

에이전트에 장기 기억을 붙이는 일을 맡았다. 사용자가 대화 중에 흘린 사실을 추출해 저장해 두고, 다음 대화에서 꺼내 쓰는 구조다. 어느 날 저장된 기억을 열어 봤더니 이렇게 적혀 있었다. 대화는 처음부터 끝까지 한국어였다. 먼저 구조부터. 기억 서비스는 대화 원문을 소유하지 않는다. 원문은 대화로그 저장소 한 곳에만 있고, 이쪽은 요약과 커서와 기억만 가진다. 원문을 복제하지 않기로 한 것은 초기 결정 중 가장 잘한…

토큰 5개를 만들었는데 브라우저에는 195개가 도착했다. 스트리밍 코드는 멀쩡했고, 문제는 채널에 붙인 이름이었다.

에이전트 안에서 사용자가 쓴 코드가 돌아간다. 그 코드가 다른 에이전트를 부를 수 있다. 부르면 답이 토큰 단위로 돌아오고, 그 토큰들이 브라우저까지 흘러간다. print("Hello World") 한 줄을 실행시켰다. 모델이 만든 토큰은 다섯 개였다 — print, (", Hello, World, "). 브라우저가 받은 SSE 이벤트는 195개였다. 대화 서비스는 요청을 받으면 Redis 채널 하나를 구독한다. 채널 이름은…

하루에 같은 열 줄을 다섯 번 고쳤다. 아무것도 잃지 않은 버전은 17분 만에 지운 것이었다.

외부 모델 공급자를 붙일 때 우리가 한 약속이 하나 있다. 어느 공급자를 쓰든 클라이언트가 받는 응답 형태는 같아야 한다는 것. 공급자들의 SSE 페이로드는 제각각이다. 필드 이름이 다르고, 중첩 깊이가 다르고, 종료 신호도 다르다. 약속을 지키려면 스트림이 지나갈 때 각 이벤트를 열어서 우리 형식으로 바꿔야 한다. 그 순간부터 우리는 릴레이가 아니라 파서가 된다. 이 글은 그 대가에 관한 것이다. 2025년 8월 4일 오전…

사용자가 올린 파이썬을 런타임에 불러오려면 그 코드는 디스크의 진짜 파일이어야 한다. 그 하나의 제약에서 다섯 달치 버그가 나왔다.

이 엔진이 하는 일은 한 문장이다. 사용자가 작성한 파이썬 파일을 받아서, 서버를 재시작하지 않고, 지금 뜨는 API로 만든다. 그래서 상태를 어디에 둘지에 선택지가 없었다. 코드를 데이터베이스에 넣을 수 없다. importlib은 컬럼을 읽지 않는다. 디스크 위의 진짜 파일이 있어야 모듈이 된다. 문서에는 이렇게 한 줄로 남아 있다. 이 문장은 아키텍처 결정처럼 보이지만, 실제로는 청구서였다. 이후 다섯 달 동안 올라온…