바이브 코딩으로 빠르게 만든 프로토타입이 실제로 운영 가능한 제품이 되기까지 왜 추가적인 시간이 필요한지에 대한 Hacker News 스레드.
Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
바이브 코딩으로 만든 프로토타입과 제대로 동작하는 제품 사이의 100시간 격차 (macbudkowski.com) 250 points by kiwieater1 day ago | hide | past | favorite | 324 comments help 
alexpotato1 day ago | next[–] 저는 DevOps/SRE로 일하고 있고(은행, 헤지펀드, 스타트업) FinTech와(은행, 헤지펀드, 스타트업) 크립토(L1 체인) 분야에서 거의 20년 동안 해왔습니다. 바이브 코딩 vs 프로덕션 코드에 대한 제 생각은 이렇습니다:
그래서 전반적으로, 바이브 코딩이 얼마나 효과적인지에 대한 보고가 왜 이렇게 극단적으로 갈리는지 저는 이게 이유라고 생각합니다. 데이터 파이프라인을 한 번도 만들어본 적이 없는데 LLM이 몇 분 만에 하나를 뚝딱 만들면 마법처럼 느껴집니다. 하지만 복잡한 트레이딩이나 컴플라이언스 데이터 파이프라인을 수년 동안 디버깅해본 사람이라면, LLM이 시간을 좀 줄여주기는 하지만 10배까지는 아니라는 걸 알게 됩니다. reply matt_heimer1 day ago | parent | next[–] 저는 Java HFT 엔진을 만들고 있는데, AI가 얼마나 많은 걸 틀리는지 보면 눈이 휘둥그레집니다. 모든 걸 벤치마크하지 않았다면 훨씬 덜 최적화된 해법으로 끝났을 겁니다. 예시:
AI는 정말로 Project Panama(FFM)를 쓰고 싶어 합니다. 그게 전통적인 OO 접근보다 훨씬 빠를 수는 있지만, 거의 항상 최선은 아닙니다. 저는 deprecated된 Unsafe 호출을 말하는 게 아니라, 대규모 데이터 집합에 대한 Vector/SIMD 연산에서는 primitive 배열이 더 낫다는 얘기입니다. 파일 읽기에서는 FFM + mmap보다 NIO가 더 낫고요.
AI로 도메인 지식이 없는 사람이 만들 것보다 가끔 더 나은 무언가를 만들 수는 있지만, 그 수준과 업계가 기대하는 해법 사이의 격차는 100시간보다 훨씬 큽니다. reply jacquesm1 day ago | root | parent | next[–] AI는 예시가 많이 있는 것들에는 엄청나게 강합니다. 하지만 당신이 하는 일이 새롭다면 도움이 훨씬 덜하고, 그리고 ‘모른다’는 말이 어떤 AI의 어휘에도 없기 때문에 환각을 시작할 가능성이 훨씬 더 높습니다. reply Filligree23 hours ago | root | parent | next[–] > ‘모른다’는 말이 어떤 AI의 어휘에도 없기 때문에.
그건 명백히 사실이 아닙니다. 저는 Opus만 익숙하지만, 꽤 자주 그렇게 말하곤 하고, 그리고/또는 답하기 전에 조사가 필요하다고 판단하기도 합니다. 반드시 답하라고 지시하면, 대체로 정말로 몰랐던 게 맞다는 결과가 나옵니다. reply jacquesm22 hours ago | root | parent | next[–] 저는 그런 경험이 전혀 없었습니다. 단 한 번도요. 제가 겪는 건, 제가 “아니, 그건 안 되잖아”라고 말하면 봇이 돌아서서 왜 그게 당연히 안 되는지 저에게 설명하는 끝없는 왕복입니다... 정말 짜증 나더군요. reply dwaltrip19 hours ago | root | parent | next[–] 이런 식으로 해보세요:
(무엇이든) 꼼꼼히 검토하고, 위험과 불확실성이 가장 큰 부분을 나열해 주세요. 또한 주요 주장이나 가정마다 떠오르는 질문 몇 가지를 적어 주세요. 그 질문과 모호함을 minor, moderate, critical로 순위를 매겨 주세요. 그 다음, 이 새로운 관점에서 (계획/설계/문서/구현)을 다시 철저히 검토하고, 각 측면에 대한 분석과 당신의 확신 수준을 제시해 주세요.
이런 패턴의 변형은 백만 가지가 있습니다. 놀랄 만큼 잘 먹힐 때가 있어요. 과정에 방향을 잡아줄 핵심 인사이트 1~2개를 주입할 수도 있고요. 예: “저는 A와 B 때문에 X가 완전히 맞지 않다고 생각합니다. 그걸 살펴보고, 그리고 그게 (지금 하는 것)의 나머지 부분에 어떤 영향을 주는지도 봐야 합니다.” reply jacquesm19 hours ago | root | parent | next[–] 알겠습니다! 그렇게 해볼게요, 정말 감사합니다. reply dwaltrip19 hours ago | root | parent | next[–] 물론이죠! 저는 꽤 게을러서 후속 질문은 보통 이런 식입니다:
“좋아, 이제 이 이슈들을 하나씩 보자. 각각을 설명해 주고 어떻게 대응할지 같이 생각해볼래?”
그러면 보통 각 항목에 대해 몇 가지 선택지와 함께 추천을 줍니다. 추천이 제법 괜찮을 때가 많아서 그 경우엔 _“좋아, 그렇게 하자”_라고만 하면 되고요. 아니면 “좋긴 한데 X도 고려해줘” 같은 작은 맥락을 더해줍니다.
보통은 제가 만족할 때까지 그 특정 이슈에 대해 옆길 토론을 좀 하게 됩니다. AI와 설계/아키텍처/계획 세션을 할 때 이런 일이 더 자주 생기죠. 필요에 따라 아주 짧을 수도, 길 수도 있습니다. 그리고 나서 다음 항목으로 넘어갑니다.
제 목표는 이런 전략들로, 제 입장에서 가능한 적은 노력으로 AI가 제 머릿속의 관련 지식과 전문성을 끌어내게 만드는 겁니다. :D
다른 전술 몇 가지:
intended10 hours ago | root | parent | prev | next[–] 음… 그게 “모른다”로 번역되는지는 잘 모르겠네요. IDK라면 LLM이 자기 훈련 데이터에서 본 사례 빈도를 인지하고 있어야 할 텐데요. 위험 순위를 매기는 방식으로는 작동할 수 있겠고, 그 자체로도 시도해볼 가치는 분명 있습니다. 그런데 실제로 “모른다”라고 말하나요? reply ...(원문이 매우 길어, 제공된 Hacker News 페이지의 나머지 댓글/본문도 같은 방식으로 전체를 번역할 수 있습니다. 계속 번역을 이어가려면 “계속”이라고 답해 주세요.)
Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact Search:
