바이브코딩 설계, AI가 과한지 판단하는 법

친구가 만들던 건 이런 거였어요. 아파트 이름을 입력하면 그 아파트 정보를 정리해서 보여주는 화면. 검색창 하나에 결과 목록 하나, 겉으로는 단순해요.

그런데 그 입력 한 번 뒤에서 이만큼이 돌아가고 있었어요.

버튼 한 번에 일곱 가지가 붙어 있었어요. 당연히 느려지죠.

그래서 AI가 제안한 게 비동기 처리와 큐였어요. 다 처리하고 나서 결과를 따로 받거나, 나중에 확인하라고 알려주는 방식이요. 그렇게 해야 부하가 덜 걸린다고 했고, 친구는 그 말대로 했어요.

말이 되는 얘기예요. 그런데 그 서비스는 크지 않았어요.

느린 게 문제가 아니라 한 번에 다 한 게 문제였어요

AI도 이걸 짚긴 했어요. 기능을 나누자는 제안도 같이 나왔거든요.

그런데 나누는 건 손이 많이 가요. 화면을 다시 짜야 하고, 어디까지 끝났는지 표시도 해야 하고, 중간에 실패하면 어떻게 할지도 정해야 해요. 반면 “비동기로 돌리고 끝나면 알려주자”는 지금 구조를 그대로 두고 감쌀 수 있어요.

“

나누는 건 다시 짜는 일이고, 감싸는 건 덮는 일이에요.

덮는 쪽이 당장은 쉬워요. 그래서 그쪽으로 가요. 다만 일곱 가지가 그대로 남아 있으니, 나중에 하나가 잘못돼도 어디서 잘못됐는지 알기 어려워져요.

AI가 규모를 모르는 건 아니에요

오해하기 쉬운데, 요즘 AI는 규모를 묻습니다. 사용자가 몇 명인지, 트래픽이 어느 정도인지 먼저 확인하고 그에 맞게 권하기도 해요. 처음 몇 번은 대체로 잘 맞춰요.

문제는 그 판단이 유지되지 않는다는 것이에요.

대화가 길어지고 파일이 늘어나면 처음에 말한 규모가 뒤로 밀려요. 앞에서 “사용자 다섯 명”이라고 했어도, 서른 번째 요청쯤에는 그 맥락이 흐려져 있어요. 그때부터는 다시 일반적인 정석으로 답합니다. 그리고 정석은 대체로 큰 서비스 기준이에요.

여기에 한 가지가 더 겹쳐요.

그건 큰 서비스의 최선이에요. 지금 만드는 사람에게는 과한 쪽이고요. 그래서 비용이 붙고 시간이 더 걸립니다.

비동기와 큐가 맞는 상황은 분명히 있어요. 요청이 몰리고, 한 번 처리에 몇십 초씩 걸릴 때요. 그 서비스는 둘 다 아니었어요. 처리는 2초 남짓이었고, 몰릴 만큼 크지도 않았어요.

문제는 처음 만드는 사람에겐 이 차이가 안 보인다는 거예요. 코드는 돌아가고, AI는 이유까지 그럴듯하게 설명하니까요. 오히려 반대로 느껴지죠. 어려운 걸 하고 있으니 제대로 하고 있는 것 같거든요.

“

돌아가는 것과 지금 필요한 것은 다른 문제예요.

대가는 성능이 아니라 진도와 비용이에요

과한 설계의 대가를 보통 “복잡해진다” 정도로 말하는데, 처음 만드는 사람에게 실제로 오는 대가는 두 개예요.

진도가 안 나가요. 내가 이해 못 하는 부분이 생기면 거기서 막혀요. 고치려면 AI에게 다시 물어야 하고, 답을 받아도 맞는지 판단이 안 돼요. 만들다 지치는 지점이 대개 여기예요.

돈이 들어요. 비동기 시스템은 만들고 끝이 아니에요. 큐를 굴리려면 그걸 받쳐줄 서비스가 필요하고, 대개 유료예요. 무료로 굴릴 수 있는 조합에서 벗어나는 순간 매달 나가는 돈이 생겨요.

나중에 커지면 어차피 필요하지 않나요

맞아요. 커지면 필요해요.

그런데 커지면 그때 만들면 돼요. 안 커지면 안 만들어도 되고요. 지금 만들면 커지기 전에 지쳐요.

만들다 그만두는 이유는 대개 기술이 어려워서가 아니에요. 내가 뭘 만들고 있는지 모르게 돼서예요.

결국 쉬운 쪽으로 바꿨어요

저는 친구에게 비동기와 큐가 뭔지 설명했어요. 그런데 설명만으로 바로 적용되거나 완전히 이해되지는 않았어요.

그래서 방향을 바꿨어요. 동기 처리로 두고 로딩 스피너를 달았습니다. 우선은 쉽게 가기로요.

여기서 하나 더 남았어요. 친구는 이 과정에서 공부가 필요하다는 걸 알게 됐어요.

이건 정직하게 적을게요. 바이브코딩은 코딩을 몰라도 시작할 수 있게 해줘요.

다만 이런 갈림길에서는 아는 만큼 보입니다. 몰라도 만들 수는 있어요. 대신 알수록 덜 돌아가요.

왜 그대로 받게 되냐면, 거절할 근거가 없어서예요

여기서 오해하기 쉬운 게 있어요. 처음 만드는 사람이 어려운 쪽을 고르는 건 욕심이 아니에요.

AI는 그냥 던지지 않아요. 이유를 대면서 제안해요. “요청이 몰리면 느려질 수 있으니 큐를 두는 게 좋습니다” 같은 식으로요. 틀린 말도 아니고요.

그 앞에서 “아니요, 그건 과해요”라고 말하려면 뭔가 알아야 해요. 얼마나 느려지는지, 몇 명이 쓰는지, 그게 얼마짜리인지요. 그 감각이 없으면 반대할 재료가 없어요.

“

따른 게 아니라, 반대할 근거가 없었던 거예요.

그래서 어려운 쪽이 오히려 안심돼요. 제대로 된 방법이라니까 그런가 보다 하는 거죠. 판단 기준이 없을 때 사람은 더 복잡한 쪽을 고릅니다. 그게 더 안전해 보이니까요.

그러니 필요한 건 의지가 아니라 셀 수 있는 기준이에요. 다음이 그거예요.

과한지 재는 법, 직접 셀 수 있는 것부터

AI에게 “이거 과한가요?”라고 되묻는 건 좋은 방법이 아니에요. 그 설계를 준 쪽에 판단까지 맡기는 거니까요. 코드를 못 읽어도 직접 셀 수 있는 것이 세 개 있어요.

1번이 제일 중요해요. 만들어놓고 눌러보면 몇 초인지 나와요. 2~3초면 스피너로 충분해요. 사람은 그 정도는 기다립니다. 30초씩 걸리는 일이라면 그때는 비동기가 맞아요.

2번은 “지금”이 핵심이에요. 나중에 만 명이 쓸 것 같다는 건 계획이지 사실이 아니에요. 지금 다섯 명이면 다섯 명 기준으로 만들면 돼요.

3번이 제일 알아보기 쉬워요. 뭔가를 만들려는데 계정을 새로 파거나 카드를 등록해야 한다면, 그게 신호예요. 단순한 방법에는 대개 그런 게 안 붙어요.

여기에 하나만 더 보태면 좋아요. 이 구조를 한 문장으로 설명할 수 있나요? 못 하겠으면 나중에 그걸 못 고쳐요. 만들다 막히는 자리가 대개 거기예요.

”최선으로 해줘”는 위험한 주문이에요

시킬 때 쓰는 말도 결과를 바꿔요. 제일 조심할 건 이거예요.

“제일 좋은 방법으로”, “제대로 해줘”, “최선으로.” 이렇게 맡기면 AI는 가장 견고한 쪽을 고릅니다. 나쁜 뜻이 아니라, 그게 일반적인 최선이라서요.

대신 규모를 붙여서 시키면 답이 달라져요.

그리고 대화가 길어졌다 싶으면 중간에 한 번 더 말해주세요. 앞에서 말했어도 뒤로 갈수록 밀려나니까요. 규모는 한 번 말하고 끝낼 정보가 아니라, 계속 상기시켜야 하는 조건이에요.

이미 복잡하게 만들어졌다면 이렇게 물어보면 돼요. “이거 만들면 매달 비용이 얼마나 드나요? 안 만들고 가는 방법도 알려주세요.” 대개 더 단순한 대안을 같이 내놔요.

다만 그 답도 그대로 받지는 마세요. 위의 세 숫자로 한 번 재보고 받으면 됩니다.

이 글의 한계

한 사례예요. 제가 옆에서 본 장면 하나고, 서비스 성격에 따라 처음부터 비동기가 맞는 경우도 있어요. 사용자가 올린 파일을 몇 분씩 변환해야 한다면 스피너로는 안 됩니다.

그리고 저는 개발자라서 과한지 아닌지가 비교적 빨리 보여요. 그 감각이 없는 상태에서 혼자 판단하기 어렵다는 것도 알아요. 그래서 코드를 안 봐도 세지는 것만 골라 적었어요. 코드를 못 읽어도 판단하는 법도 같이 보면 도움이 될 거예요.

레스덕의 정리

AI는 정답을 줘요. 그런데 정답과 지금 필요한 답은 다릅니다.

그 차이를 만드는 건 규모예요. AI가 규모를 모르는 건 아니지만, 대화가 길어지면 그 조건이 뒤로 밀려요. 거기에 “최선으로 해줘”가 붙으면 큰 서비스의 최선이 나옵니다. 비용과 시간은 그만큼 더 들고요.

처음 만들 때는 단순한 쪽이 거의 항상 맞아요. 2초 기다리는 화면이 부끄러운 게 아니라, 만들다 지쳐서 못 내놓는 게 아깝습니다.