숫자는 다 있었는데 답이 없었다
소셜 봇 대시보드가 있습니다. tailnet 안에서 :8892 포트로 띄워 두고, 계정별 상태와 API에서 받아온 수치를 보여줍니다. 그 수치들은 21초짜리 캐시를 거칩니다. 화면만 보면 꽤 그럴듯합니다.
그런데 인스타그램 콜드팔로우, 그러니까 모르는 계정을 먼저 팔로우하는 동작을 켜도 되는지에 대한 답은 그 화면 어디에도 없었습니다. 그 판정은 별도의 파이썬 스크립트가 맡고 있었습니다. 게이트 4개를 검사하고, --json 옵션을 주면 결과를 JSON으로 뱉는 녀석입니다. 터미널에서 직접 실행해야 볼 수 있었습니다.
당신의 대시보드는 지금 상태를 보여주나요, 아니면 다음 행동을 해도 되는지를 보여주나요?
저는 전자만 있었습니다. 숫자는 많은데 허가가 없는 화면이었습니다. 행동의 전제조건을 검사하는 코드는 이미 있었고, 단지 그 결과가 제가 평소에 보는 곳에 없었을 뿐입니다.
게이트가 CLI에만 있으면 생기는 일
게이트 스크립트는 로컬 파일을 grep하는 수준의 검사입니다. 외부 API를 부르지 않습니다. 그래서 싸고 빠릅니다. 문제는 비용이 아니라 위치였습니다. 판정을 보려면 별도 명령을 기억해서 쳐야 하고, 대시보드를 열어둔 채 봇을 켤지 말지 고민하는 순간에는 그 결과가 눈앞에 없습니다.
대시보드에 이미 21초 캐시로 API 수치를 당겨오는 구조가 있었기 때문에, 게이트 결과도 그 캐시 안에 넣는 게 자연스러워 보였습니다. 하지만 그렇게 하면 게이트 판정이 API 갱신 주기에 묶입니다. 로컬 파일을 고쳐서 게이트를 충족시켜도 최대 21초 동안은 화면이 잠긴 상태로 남을 수 있습니다. 게이트는 애초에 API와 무관한 로컬 검사인데, 굳이 API 캐시 수명을 공유할 이유가 없었습니다.
당신이라면 캐시에 같이 넣겠습니까, 아니면 렌더할 때마다 새로 계산하겠습니까?
렌더마다 subprocess로 다시 묻기
저는 후자를 골랐습니다. 대시보드가 페이지를 그릴 때마다 게이트 스크립트를 subprocess로 --json 옵션과 함께 부르고, 돌아온 JSON을 그대로 배너로 그립니다. 전부 통과면 초록 원 하나로 READY를 표시하고, 아니면 자물쇠와 함께 N/4 형식으로 몇 개가 통과했는지 보여주고 게이트별로 칩을 달아 어느 것이 막혔는지 드러냅니다.
캐시를 안 거치는 이유는 단순합니다. 게이트가 로컬 grep이라 렌더마다 돌려도 부담이 없고, 그 덕에 21초 캐시의 수명과 완전히 분리됩니다. API 수치는 느리게 갱신되고 게이트 판정은 즉시 반영되는, 두 개의 서로 다른 신선도가 한 화면에 공존하게 됐습니다.
수정은 대시보드 파일 하나, 31줄 추가에 1줄 삭제입니다. 판정 로직은 한 줄도 새로 쓰지 않았습니다. 이미 있던 스크립트를 부르는 접착 코드만 추가한 셈입니다.
라이브에서 확인한 것
tailnet에서 :8892로 열어 확인했을 때 게이트는 2/4 미충족 상태였고, 자물쇠 배너와 칩이 그대로 그려졌습니다. 즉 이 글을 쓰는 시점에 콜드팔로우는 켜면 안 되는 상태이고, 이제는 그 사실이 터미널이 아니라 대시보드에 보입니다.
자가진단 체크리스트
- 어떤 행동을 켜기 전에 검사해야 할 조건이 코드로 존재하는데, 그 결과를 보는 곳이 평소 모니터링하는 화면과 다른 곳은 아닌가?
- 싼 로컬 검사를 비싼 외부 API와 같은 캐시 주기에 묶어서, 즉시 반영돼야 할 판정이 캐시 수명만큼 늦게 보이는 구조는 아닌가?
- 대시보드가 상태 숫자만 나열하고 다음 행동의 허가 여부는 안 보여주는 것은 아닌가?
솔직한 부분
이 수정은 판정을 눈에 띄는 곳으로 옮긴 것뿐입니다. 게이트 4개가 콜드팔로우의 안전을 보장하기에 충분한 조건인지는 이 커밋으로 알 수 없습니다. 2/4 미충족이 어느 게이트 때문인지, 그걸 채우는 데 얼마나 걸릴지도 아직 모릅니다. 렌더마다 subprocess를 띄우는 방식은 지금 규모에서는 문제가 없지만, 대시보드를 자주 새로고침하는 사람이 늘거나 게이트 검사가 무거워지면 그때는 다시 캐시 이야기를 꺼내야 할 겁니다.