AI로 만든 앱을 출시용으로 다듬는 개발 샵을 운영 중인데, 매번 똑같이 박살 나 있는 4가지 요소 (+ 무료 점수표)

보통 워크플로우를 사용해서 하이쿠(haikus) 스웜으로 나누면 처리 속도가 빨라질 텐데

.33배 x 4 vs 1 x 1

주요 변경 사항이 있을 때마다 모든 기능에 대해 e2e 테스트 프레임워크를 돌리고, /code-review ultra를 요청해서 모든 에러를 수정하고, 다시 테스트한 뒤 다른 취약점이 없는지 확인함. 이렇게 기능들이 제대로 작동하는지 확인하고 버그를 잡는 데 전체 시간의 80%를 씀. 나머지 10%는 제품 기능 구현, 10%는 사업 계획, 피치 덱, 그래픽 작업 등에 씀.

고마워. 통찰력 있는 글이네.

이런 문제들은 테스트가 제대로 안 돼서 생기는 것 같다는 생각이 들어.

이제 고객을 위한 제품을 만들려고 하는데, 처음부터 끝까지 항상 실행되는 탄탄한 테스트를 기반으로 구축할 생각이야. 새로운 기능을 만들 때마다 스택 전반에 걸쳐 테스트를 추가할 거고. UI뿐만 아니라 말이지. 네가 언급한 문제들을 항상 잡아내려고 노력해야 해.

'바이브 코딩'으로 만드는 사람들은 테스트를 아예 고려조차 안 하는 경우가 많은 것 같아...

제대로 만드는 것보다 일단 출시하는 걸 더 중요하게 생각하는 개발자들 때문이지.

앱 스토어 페이지 링크를 올리는 게 앱을 설명하는 것과 같은 효과가 있을까?

링크 공유해주면 내가 한번 봐줄게.

정말 일리 있는 말이야. 프로그래머가 이런 도구를 쓸 때랑 비개발자가 쓸 때 발견되는 문제점 차이가 엄청나더라고. 물론 세상에 내놓기 전에 솔루션을 강화하려면 도움이 필요한 건 후자 쪽이겠지만, 모델들은 계속 발전하고 있지. 우리 프로그래머들은 AI를 적극 활용해서 가치를 극대화하고 있고, 실제로 몇몇 고객들이 강화된 제품으로 시장에 진출하도록 도왔어. AI가 출시 기간을 엄청나게 단축시킨 건 확실해. 창업자들에겐 정말 흥미진진한 시대지.

로그인한 사용자가 다른 모든 사용자의 데이터를 가져올 수 있는 Supabase/Firebase의 고전적인 허점 말이야. 이게 진짜 무서운 거거든. - Supabase UI에서 이런 문제에 대해 대놓고 경고를 띄우는데 어떻게 이런 일이 가능한지 이해가 안 가. 수정: 웃긴 건 나도 Claude 쓰기 전까지는 RLS(Row Level Security)에 대해 몰랐다는 거야. 그냥 에러나 경고를 무시하지 않았을 뿐이지.

내 말은, AI를 잘 활용하는 방법 중 하나는 그냥 주변 도구들이 내는 경고를 설정하고 귀담아듣는 거라는 거야. Supabase 내장 에러나 coderabb …