소프트웨어 개발자로서 깨달은 점. 누군가 앱 아이디어가 있다고 할 때의 그 오글거림.

아니면 차라리… 배관공이 됐어야 했다는 걸 깨달을 때까지, 싸게 빨리 실패하고 또 실패하는 거지.

내 얘기 같네

내가 바로 네가 말한 그 사람인데, 솔직히 바이브 코딩으로 뭔가를 만들다가 실패해 봐서 다행이라고 생각함. 덕분에 배우게 됐고, 내 주변에 성공적으로 만들어진 앱이나 소프트웨어들을 더 높게 평가하게 됐거든. 전에는 간단한 앱 하나 만드는 게 얼마나 어렵고 복잡한지 이해 못 했음. 직접 뭔가를 만들어 보려고 시도한 뒤로는, 여전히 정확하진 않겠지만 훨씬 더 잘 이해하게 됐어.

정말 좋은 말이야.

난 개발 강의를 하고 있는데, 다들 서비스를 만드는 게 생각보다 훨씬 어렵다는 걸 깨닫고 겁을 먹더라고.

그래서 너무 진실을 다 말하지 않으려고 노력 중이야. 내 팩트 폭격 때문에 그들의 흥미가 꺾이는 것 같아서.

몇 달 동안 매달렸던 아이디어가 있었어요. 업계 지인한테 보여줬더니 "이거 좋긴 한데 XYZ 때문에 절대 성공 못 해"라고 하더군요. 조사해보니 그 말이 맞았어요. 아프긴 했지만, 어차피 안 될 제품 개발에 시간과 돈을 훨씬 더 많이 낭비하지 않게 해줘서 고마웠죠. 헛수고를 피하게 해준다면 쓴소리도 좋은 법이죠.

중요한 건 사람들이 기꺼이 돈을 지불할 의사가 있는 무언가를, 제공 비용보다 높은 가격으로 전달할 수 있느냐뿐이야.

코딩이 쉽든 어렵든 상관없어. 솔직히 아무도 신경 안 써.

경험 많은 기술자들은 이 서브레딧에 죽치고 앉아서 코딩이 어렵다는 걸 상기시키고 싶어 하는 것 같은데, 정작 비즈니스 측면은 전혀 모르는 것 같아. 그냥 자기보다 못하다고 생각하는 사람들을 깎아내리면서 엉뚱한 데만 집중하고 있는 거지.

여기서 말하는 '숨겨진 작업'은 보통 생각하는 것보다 더 구체적인 형태를 띠고 있음. 단순히 '코딩이 어렵다'는 문제가 아님. 시장 적합성(market fit)은 별개의 문제거든.

데모는 사용자 한 명, 즉 본인만을 가정함. 격리 요구 사항도 없고, 순차적으로 사용하며, 에러가 나도 본인만 피해를 봄. 하지만 프로덕션은 데이터가 섞여서는 안 되는 N명의 사용자를 가정하고, 그게 모든 것의 기반이 되는 데이터 모델을 바꿔버림. 이건 나중에 덧붙일 수 있는 레이어가 아님. 기반 자체가 그걸 갖추고 있거나, 아니면 아예 없거나 둘 중 하나지.

난 AI로 만든 앱들의 구조 개선 작업을 주로 하는데, 내가 가장 자주 보는 실패 유형은...

내가 딱 네 글에 나오는 그 사람임. 간단한 앱 아이디어 하나 있어서 주말 동안 vibe-code로 프로토타입 만들고는 천하무적이 된 기분이었지. 근데 다른 사람들 몇 명 쓰기 시작하니까 바로 뻗어버리고 이상하게 작동하더라. 왜 그런지도 전혀 몰랐고. Claude랑 시간 엄청 쓰면서 아키텍처 설명 듣고 같이 디버깅하고 그랬음. 포기하지 않고 끝까지 밀고 나가는 게 맞는 거 같음.

'아이디어만 있는 사람들'에 대해 엄청 냉소적일 줄 알았는데 마지막 문단은 정말 훈훈하네요. 시도하고, 실패하고, 해결책을 찾아가는 정말 흥미진진한 시기죠. 그리고 사람들이 원하는 가치 있는 무언가를 만드는 게 쉽지 않다는 걸 깨닫게 되고요.