AI에게 설계부터 맡겨서 만들다 보면, 한 가지 주의할 점이 있습니다.
아무 말도 하지 않으면 종량제(従量課金) 비용은 고려되지 않을 때가 있다는 것입니다.
움직이는 결과물은 만들어 줍니다. 설명을 요구하면 기술적으로 논리적인 이유도 돌려받습니다.
다만, 그것을 클라우드에 올렸을 때 매달 얼마가 들지는 우리가 묻지 않으면 나오는 경우가 많습니다.
그리고 되돌아보면, 그것은 AI의 부족함이라기보다는, 지시를 내린 저에게 비용 의식이 없었던 것이 그대로 구현에 나타난 것이라고 생각합니다.
실례 하나를 적겠습니다.
알림을 실시간으로 만들고 싶었다
만드는 서비스에 알림 벨이 있습니다. 새로운 알림이 오면, 화면을 열어둔 상태여도 배지(badge)가 늘어나게 하고 싶었습니다.
'알림을 어느 정도 실시간으로 수신하려면'이라는 부분부터 상담을 시작하여, WebSocket을 사용할지 아니면 SSE(서버에서 한 방향으로 계속 보내는 구조)를 사용할지 두 가지 선택지로 좁혔습니다.
AI의 답변은 SSE였습니다. 기억하기로는요.
채팅처럼 양방향으로 주고받는 것이 아니기 때문에, 상호 전송이 필요 없는 SSE가 더 적합하다는 이유였습니다.
그래서 알림을 보내는 구조를 만들고 넣었습니다.
실제로 알림을 보내면 연결된 클라이언트에는 바로 도착합니다. 따로 로그인한 두 개의 브라우저에서 배지가 즉시 늘어나는 것도 확인했습니다.
동작 확인 3일 후에, 전부 지웠다
넣은 건 1월이었습니다. 6월에 발견된 불량(세션이 끊기면 재연결이 멈추는 등)을 고치고, 7월에 다시 동작 확인을 마쳤습니다.
그로부터 3일 뒤에, SSE 구현 전체를 지웠습니다.
작동하지 않았기 때문은 아닙니다. 이유는 코드 밖에 있었습니다.
서비스는 Google Cloud의 Cloud Run(요청이 왔을 때만 작동하는 서버 실행 환경)에서 구동하고 있었고, 요금은 주로 요청을 처리하는 동안에 발생하는 형태였습니다.
SSE 연결은 말하자면 끝나지 않는 요청입니다. 탭을 열어둔 사람이 단 한 명이라도 있는 한, 비용이 계속 발생하게 되는 상태가 됩니다.
원래라면 사용하지 않을 때는 서버 대수가 0까지 떨어져서 요금이 발생하지 않아야 하는 구조였습니다.
게다가 연결은 프로세스의 메모리 안에서 관리하고 있었습니다.
사용자가 아직 적어 1대로 충분해서 도착했지만, 대수는 0대부터 10대까지 증감하는 설정이었습니다. 대수가 늘어나면 알림을 보낸 서버와 상대방과 연결된 서버가 분리되어 도착하지 않게 되는 구조였습니다.
이것을 제대로 고치려면, 서버끼리 알림을 주고받는 구조가 필요합니다. Google Cloud의 관리형 Redis(Memorystore)를 사용하면 그것만으로도 월 5,000엔 정도부터 발생합니다.
그렇게까지 바랐던 것은 알림 배지뿐이었습니다.
배지는 다소 늦어도 곤란하지 않습니다. 결국, 일정한 간격으로 가져오는 방식(폴링)으로 되돌렸습니다.
참고로, WebSocket을 선택했더라도 같은 일이 발생했습니다. Cloud Run에서는 WebSocket 연결이 열려 있는 서버는 작동하고 있는 것으로 취급됩니다(Cloud Run 문서).
SSE라는 구조가 나빴던 것도 아닙니다. 같은 시기에 만들었던 다른 제품에서는 SSE를 계속 사용하고 있습니다. 맞지 않았던 것은, 항상 연결된 구조와 요청 단위로 과금되는 실행 환경의 조합이었습니다.
깨달은 계기는 청구서였습니다.
운영을 지속하는 동안 GCP의 과금 그래프를 보니, Cloud Run 요금이 명백히 서버가 계속 작동하고 있는 듯한 증가세를 보이고 있었습니다. 왜 그런지 AI와 함께 분석하여 SSE에 도달했습니다.
물어보니, AI는 제대로 원인까지 찾아줍니다. 다만, 물어보기 전까지는 나오지 않았습니다.
지시 속에 비용이 없었다
돌아보면, AI가 틀린 것은 없습니다.
WebSocket과 SSE 두 가지 선택지라면, SSE 쪽이 요구 사항에 더 적합합니다.
지시하는 방식이 나빴던 건 저였습니다.
저는 하고 싶은 것을 지시했을 뿐이고, AI는 그것을 막힘없이 구현했습니다.
어떤 방식으로 이 서비스의 과금 형태에서 가장 저렴하게 끝낼 수 있는지. 애초에 항상 연결된 구조가 필요한지 같은 질문은 제 지시 어디에도 들어있지 않았습니다.
저에게 비용 의식이 없었던 것이 그대로 구현에 반영된 것입니다.
게다가, 가능성을 스스로 좁히고 있었습니다.
굳이 자신이 아는 기술 두 가지로 한정하여 AI에게 선택하게 했습니다. 하지만 방식을 많이 알고 있는 쪽은 AI였습니다.
요구사항을 전달하고 방식에 따라 제안받는 형태로 하는 것이 좋았을 것 같습니다. 그렇게 했다면, “이 용도라면 폴링(polling)으로 충분하다”라는 답변도 나왔을지 모릅니다.
제 감각으로는 기본적으로 아무 지시를 내리지 않으면, 어떤 서비스의 어떤 기능이든 종량제(pay-as-you-go) 비용은 간과되는 이미지가 있습니다.
지금은 설계 단계에서 비용을 산출하게 한다
그래서 지금은 설계 및 계획 단계에서 비용이 나오도록 합니다.
AI에게 전달하는 규칙이나, 기억해 달라고 약속한 내용, 작업 절차서에 그 단계를 넣어두었습니다.
스스로 비용 의식이 빠져 있더라도, 시스템 측면에서 매번 질문하도록 만든 것입니다.
또 하나, 선택지를 우리가 좁히지 않고, 요구사항을 전달하여 제안을 받습니다. 이것은 지금도 AI와의 상호작용에서 계속 염두에 두고 있습니다.
동작 확인만으로는 요금이 보이지 않습니다. 그래서 문제가 드러나지 않습니다.
작동하는 것과 매달 비용을 지불할 수 있는 것은 별개이며, 후자는 지시하는 쪽이 가지고 있지 않으면 구현 단계에서도 나오지 않습니다.
지금도 AI가 요금을 간과하는지는 솔직히 모르겠습니다.
모델이 새로워져서 묻지 않아도 주의를 주는 것처럼 되었을지도 모릅니다. 제가 항상 신경 쓰고 있기 때문에, AI의 기억 어딘가에 그것이 남아 있어서 신경 써주는 것일 수도 있습니다.
하지만 완전히 백지 상태에서라면, 아마 아직 간과할 수 있을 거라고 생각합니다.
게이머들을 위한 플레이 기록 및 클립 공유 서비스를 혼자 만들고 있습니다. 이 연재는 그 개발 기록입니다.
Discussion
