알고리즘 앱이 배포가 안 된다
이날은 며칠 전에 만든 배포 필터가 새 문제를 만든 걸 발견한 날이었다.
과도한 배포를 막으려고 허용 목록을 만들었다.
근데 목록에 없는 앱이 조용히 배포에서 제외되었다.
문제를 고치려다
더 큰 문제를 만든 거다.
교육 플랫폼의 알고리즘 문제 출제 앱을 수정하고 배포했다.
근데 변경 사항이 알파에 반영되지 않았다.
테스트를 돌리면 로그인 페이지로 리다이렉트됐다.
원인을 추적해보니, 배포 자체가 안 됐다.
코드는 변경되었고, 커밋도 들어갔다.
근데 배포 파이프라인이 이 앱을 건너뛰었다.
범인은 3일 전에 만든 필터
며칠 전에 배포 추론이 너무 많은 앱을 잡는 문제를 고쳤다.
공통 패키지 하나 바꿨더니 21개 앱이 배포 대상이 되는 문제. 이걸 해결하려고 허용 목록을 만들었다.
허용 목록에 있는 앱만 배포된다.
목록에는 교육 앱 5개만 넣었다.
이걸로 21개에서 5개로 줄었다.
의도한 대로 동작했다.
근데 알고리즘 앱은 교육 앱이 아니다.
비즈니스 평가 쪽에 있다.
허용 목록에 없다.
그래서 조용히 제외된 거다.
과도한 배포를 막으려다 배포 누락을 만들다
이건 고전적인 이차 효과다.
하나의 문제를 해결하면서 새로운 문제를 만든 거다.
원래 문제는 “너무 많은 앱이 배포된다”였다.
해결책은 “허용 목록에 있는 앱만 배포한다”였다.
이 해결책은 원래 문제를 잘 해결했다.
근데 부작용으로 “목록에 없는 앱이 배포 안 된다”는 새로운 문제를 만들었다.
허용 목록 방식의 위험은, 새로운 앱을 허용 목록에 추가하지 않으면 조용히 제외된다는 거다.
에러가 안 난다.
경고도 안 나온다.
그냥 배포가 안 될 뿐이다.
누군가 “왜 반영이 안 되지”라고 물어봐야 발견할 수 있다.
해결
즉시 해결은 이 앱만 별도로 배포하는 거였다.
별도 배포 워크플로우를 돌려서 이 앱만 배포했다.
근본 해결은 더 어렵다.
허용 목록에 모든 배포 대상 앱을 넣어야 한다.
근데 새로운 앱이 생기거나, 기존 앱이 허용 목록에 빠져 있으면 같은 문제가 반복된다.
이건 나중에 또 반복됐다.
4개 앱이 더 허용 목록에서 빠져 있었다.
50번의 프로덕션 배포 주기 동안 누락되어 있었다.
누구도 몰랐다.
허용 목록이 “명시적 제어”를 제공하지만 동시에 “조용한 누락”의 원천이 된다.
임베드 모드에서 헤더 숨기기
배포 문제 외에 기능 개발도 했다.
알고리즘 앱이 두 가지 모드로 돈다.
독립 모드랑 LMS 임베드 모드다.
독립 모드에서는 앱이 전체 화면을 차지한다.
헤더가 있다.
LMS 임베드 모드에서는 LMS 호스트 안에 들어간다.
근데 앱 헤더랑 LMS 헤더가 겹친다.
같은 화면에 헤더가 두 개 나오는 거다.
그래서 LMS 모드에서만 헤더를 숨겼다.
감지는 라우트 이름으로 한다.
LMS 라우트에는 접미사가 붙어 있다.
이 접미사가 있으면 임베드 모드로 판단해서 헤더를 숨긴다.
기존 모드에 영향을 주지 않는 게 핵심
이 패턴의 핵심은 기존 모드에 영향을 주지 않는 거다.
접미사가 없는 기존 라우트는 그대로 헤더가 보인다.
접미사가 있는 새 라우트만 헤더가 숨겨진다.
“특정 모드에서만 변경을 적용하되, 다른 모드에서는 무변화”라는 원칙이다.
이건 나중에 일반화되어서 LMS 전용 수정 시 비-임베딩 모드에서는 바이트 단위로 동일한 결과가 나와야 한다는 제약이 됐다.
소설 생성 4에이전트 설계 정리
틈틈이 소설 생성 프로젝트의 에이전트 구조도 정리했다.
며칠 전에 설계한 4에이전트 구조를 위키로 정리한 거다.
4개 에이전트가 협력한다.
계획하는 에이전트가 방향을 잡는다.
작성 에이전트가 길게 쓴다.
토큰 한도에 도달하면 이어서 쓰기를 반복해서 목표 길이까지 채운다.
요약 에이전트가 5회마다 아크 요약을 만든다.
검토 에이전트가 과거 텍스트를 검색해서 일관성을 확인한다.
핵심 설계 결정은, 캐릭터랑 장소 테이블을 없앤 거다.
모델이 원문에서 직접 추론하게 했다.
별도 테이블로 관리하면 동기화 비용이 든다.
근데 모델이 충분히 똑똑하면, 원문에서 직접 알아낸다.
마무리
이날의 교훈은 “문제를 고치려다
새 문제를 만들지 않도록 주의하라”는 거다.
허용 목록은 배포 정확도를 높였다.
근데 동시에 조용한 배포 누락을 만들었다.
허용 목록이 정확하지 않으면, 누락된 앱이 조용히 배포에서 제외된다.
이런 이차 효과를 막으려면, 변경 후에 부작용을 확인해야 한다.
“허용 목록에 없는 앱이 배포에서 제외되면 어떻게 되는가”를 생각해야 했다.
경고를 내거나, 누락된 앱을 알려주거나, 검토 단계를 넣어야 한다.
문제를 해결할 때는 그 해결책이 새로운 문제를 만들지 않는지 확인해야 한다.
고친 문제가 명확하면 좋아서 넘어가기 쉽다.
근데 부작용은 항상 있다.
부작용까지 생각하는 습관이 필요하다.