제가 자문을 맡고 있는 한 스타트업이 Claude에게 서버에서 클라이언트로 라이브 업데이트를 푸시하는 방법을 물었고, Claude는 자신 있게 WebSockets를 추천했습니다. 아무도 그것에 의문을 제기하지 않았습니다. 그들에게는 실제로 양방향 연결이 필요하지 않았으며, 일반 HTTP를 통한 Server-Sent Events (SSE)가 더 간단하고 가벼웠을 것입니다. 하지만 WebSocket 구축 방식은 규모를 확장하려고 시도하기 전까지는 괜찮아 보였고, 결국 그와 함께 따라오는 모든 연결 상태(connection-state) 및 재연결(reconnection) 문제를 떠안게 되었습니다.

그것이 바로 Claude Code의 특징입니다. 성능은 뛰어나고 자신감이 넘치지만, 사각지대가 있는 자신감은 결국 필요하지도 않은 코드나 인프라를 떠안게 만듭니다. Claude는 더 무거운 옵션을 선택하거나, 이미 설치되어 있는 헬퍼(helper)를 다시 만들면서, 그 과정 내내 완전히 확신에 찬 태도를 보일 것입니다. 이는 게으른 것이 아니라, 그저 무언가를 만드는 데 너무 의욕적이기 때문입니다.

그래서 저는 세션이 시작될 때 하나의 규칙을 추가하는 작은 플러그인을 만들었습니다. 코드를 작성하기 전에 재사용 가능 여부를 먼저 확인하도록 하는 것입니다: 내장 기능, 플랫폼 기능, 이미 설치된 것, 오픈 소스, 유료 서비스 등을 먼저 확인한 다음, 그제서야 직접 구축하도록 합니다. 또한 결정 사항을 설명하는 짧은 노트를 남기게 했는데, 이 덕분에 Claude가 무언가를 새로 발명(reinvent)하러 떠나기 직전에 몇 번이나 잡아낼 수 있었습니다.

저는 이것을 몇 달 동안 개인적인 로컬 스킬(local skill)로 실행해 왔으며, 세션 방식이 충분히 변했기에 이를 공유하기로 했습니다. 리포지토리(repo)에 대략적인 벤치마크가 있습니다 (기준점 18/30, 규칙 적용 시 29/30). 하지만 주의할 점은, 이것은 실제 코드가 아닌 추천(recommendation) 점수를 매기는 것이므로, 증거가 아닌 하나의 신호로 취급하십시오.

플러그인으로 설치하거나 단순히 CLAUDE.md 파일을 프로젝트에 넣기만 하면 됩니다. MIT 라이선스입니다. 다른 분들도 같은 문제를 겪었는지 궁금하네요: https://github.com/stdin/buy-vs-build
submitted by /u/UrbanSoot
[link] [comments]