News

▲ 70 · 66 comments on source · Hacker News · adam_gyroscope · 10 months ago

Ask HN: 확립된 코드베이스에서 LLM으로 어떻게 코딩하고 계신가요?

스타트업에서 LLM을 활용하는 방식은 다음과 같습니다. 우리는 정기적인 Python 데이터 워크플로, 두 개의 Next.js 앱, 소규모 엔지니어링 팀으로 구성된 모노레포를 운영합니다. SCM과 CI/CD에는 GitHub를 사용하고, GCP와 Vercel에 배포하며, 자동화에 크게 의존합니다. 로컬 개발: 모든 엔지니어에게 Cursor Pro(플러스 Bugbot), Gemini Pro, OpenAI Pro, 선택적으로 Claude Pro를 지급합니다. 어떤 모델을 쓰는지는 크게 신경 쓰지 않습니다. 실제로 LLM은 엔지니어 1인당 뛰어난 주니어/미드레벨 엔지니어 약 1.5명분의 가치가 있으므로, 여러 모델에 비용을 지불하는 것은 충분히 이득입니다. 우리는 pre-commit 훅에 크게 의존합니다: ty, ruff, TypeScript 검사, 모든 언어의 테스트, 포매팅, 기타 가드. 모든 것이 자동 포매팅됩니다. LLM은 타입과 테스트를 훨씬 쉽게 작성하게 해주지만, 복잡한 타이핑에는 여전히 어느 정도 손이 필요합니다. GitHub + Copilot 워크플로: 우리가 GitHub Enterprise에 비용을 지불하는 주된 이유는 이슈를 Copilot에 할당하면 Copilot이 PR을 열어주기 때문입니다. 우리 규칙은 간단합니다: 이슈를 열면 Copilot에 할당한다. 모든 이슈에는 코드 시도가 첨부됩니다. PR이 많다는 것에 대한 부담은 없습니다. 사용하지 않는 PR은 자주 삭제합니다. 모노레포에는 Turborepo를 사용하고, Python 쪽은 완전히 uv를 씁니다. 모든 코딩 관행은 .cursor/rules 파일에 인코딩되어 있습니다. 예를 들어: "데이터베이스 작업을 한다면 Drizzle의 schema.ts만 편집하고 SQL을 직접 작성하지 마라." Cursor는 대체로 이를 따르지만, 다른 도구들은 agent.md 스타일 파일을 아무리 많이 추가해도 이 규칙을 일관되게 읽거나 따르는 데 어려움을 겪습니다. 나의 개인 개발 루프: 이동 중에 버그를 발견하거나 아이디어가 떠오르면, GitHub 이슈를 열고(Slack, 모바일, 웹을 통해) Copilot에 할당합니다. 이슈는 상세할 때도 있고 한 문장일 때도 있습니다. Copilot이 PR을 열고, 나는 나중에 리뷰합니다. 키보드 앞에 있다면, Git worktree에서 에이전트로 Cursor를 시작하고 가장 좋은 모델을 사용합니다. 만족할 때까지 반복하고, LLM에게 테스트 작성을 요청하고, 모든 것을 리뷰한 뒤 GitHub에 푸시합니다. 사람 리뷰 전에 Cursor Bugbot, Copilot, GitHub CodeQL이 코드를 리뷰하도록 하고, 지적된 사항은 Copilot에게 수정하도록 요청합니다. 여전히 고통스러운 점: 코드가 실제로 동작하는지 제대로 알려면 Temporal, 두 개의 Next.js 앱, 여러 Python 워커, Node 워커를 실행해야 합니다. 일부는 Docker화되어 있고 일부는 아닙니다. 그런 다음 수동 확인을 위해 브라우저가 필요합니다. 내가 아는 한, 프롬프트를 주고, 코드를 작성하고, 이 모든 인프라를 띄우고, Playwright를 실행하고, 데이터베이스 마이그레이션을 처리하고, 수동으로 시스템을 만져볼 수 있게 해주는 서비스는 없습니다. 우리는 이를 GitHub Actions로 근사하지만, 수동 검증이나 DB 작업에는 도움이 되지 않습니다. Copilot은 이슈를 할당할 때나 코드 리뷰 중에 모델을 선택할 수 없게 합니다. 사용하는 모델은 대체로 좋지 않습니다. Copilot 채팅에서는 모델을 고를 수 있지만, 이슈, PR, 리뷰에서는 안 됩니다. Cursor + worktree + 에이전트는 별로입니다. worktree는 소스 레포에서 unstaged 파일까지 포함해 클론하므로, 깨끗한 에이전트 환경을 원한다면 메인 레포가 깨끗해야 합니다. 때로는 worktree를 쓰는 것보다 레포를 새 디렉터리에 그냥 클론하는 게 더 단순하게 느껴집니다. 잘 되고 있는 점: 에이전트를 끊임없이 띄우기 때문에, 우리 모노레포 셋업 스크립트는 잘 테스트되어 있고 신뢰할 수 있습니다. 또한 CI/CD로 깔끔하게 전환됩니다. "이슈 열기 → Copilot PR" 결과의 약 25%는 그대로 머지 가능합니다. 놀라운 수치는 아니지만 0보다는 낫고, 코멘트 몇 개를 더하면 약 50%까지 올라갑니다. Copilot이 우리 셋업 지침을 더 안정적으로 따르거나 더 강력한 모델을 쓸 수 있게 해준다면 이 수치는 더 높아질 것입니다. 전체적으로 월 약 $1k로, 우리는 엔지니어 1인당 주니어/미드레벨 엔지니어 1.5명분을 추가로 얻고 있습니다. 그 "LLM 엔지니어"들은 항상 테스트를 작성하고, 표준을 따르고, 좋은 커밋 메시지를 만들고, 24/7 일합니다. 에이전트들을 리뷰하고 컨텍스트 스위칭하는 데 마찰이 있지만, 감당할 만합니다. 프로덕션 시스템에서 바이브 코딩은 어떻게 하고 계신가요?

원문 게시글에서 발췌한 번역본입니다. 전문과 원문 댓글은 아래 링크에서 확인하세요.

Comment on HNEnglish
Post on X

Discussion on runchr

Loading comments…

to comment.