2025년 여름, LLM으로 코딩하기 — antirez의 업데이트
Coding with LLMs in the summer of 2025 – an update
TL;DR Highlight
Redis 창시자 antirez가 1.5년간 LLM과 코딩한 경험을 정리한 글로, 바이브 코딩을 지양하고 인간+LLM 협업이 최고 품질을 낸다는 실전 가이드.
Who Should Read
LLM을 일상 코딩에 활용하고 있거나 도입을 고민 중인 중급 이상 개발자. 특히 C/시스템 프로그래밍처럼 LLM 훈련 데이터가 풍부한 영역에서 생산성을 높이고 싶은 사람.
Core Mechanics
- antirez는 LLM을 '증폭기'로 쓰되 '원맨밴드'로 두면 안 된다고 강조한다. 바이브 코딩(LLM에게 전부 맡기기)은 소규모 throwaway 프로젝트에서만 괜찮고, 비자명한 작업에서는 필요 이상으로 크고 취약한 코드를 만든다.
- LLM에게 큰 컨텍스트를 주는 게 핵심이다. 코드베이스 전체, 관련 논문, 본인의 브레인덤프(나쁜 해법이 왜 나쁜지, 좋은 해법 힌트, 코드 스타일 요구사항 등)를 다 넣어야 제대로 된 결과가 나온다.
- Redis Vector Sets처럼 LLM이 아직 모르는 신기술을 다룰 때는 README나 문서를 컨텍스트에 추가하면 즉시 전문가 수준으로 활용할 수 있다. 간단한 트릭이지만 효과가 크다.
- 추천 모델은 Gemini 2.5 PRO와 Claude Opus 4. Gemini 2.5 PRO가 시맨틱 이해력이 더 높아 복잡한 버그를 잘 잡고, Opus 4는 코드 생성 품질이 좋다고 평가한다.
- LLM 활용의 5가지 핵심 시나리오: (1) 코드 리뷰로 버그 조기 제거, (2) throwaway 코드로 아이디어 빠르게 검증, (3) 페어 디자인으로 LLM의 지식과 인간의 직관을 결합, (4) 명확한 스펙 하에 코드 작성 가속, (5) 전문 외 기술(예: 68000 어셈블리) 영역으로 확장.
- LLM을 잘 쓰려면 '커뮤니케이션 능력'이 핵심이다. 문제를 명확히 기술하고, LLM과의 반복적 대화를 수용하는 자세가 필요하며, 이게 안 되면 LLM이 아무리 좋아도 효과가 떨어진다.
- LLM이 제안하는 경로 중 바보 같은 것도 있고 기발한 것도 있다. 인간의 역할은 로컬 미니마와 실수를 피하면서 좋은 아이디어를 취사선택하는 것이다.
- 항상 루프 안에 있어야 한다. 터미널에서 웹 인터페이스로 코드를 직접 옮기는 과정 자체가 모든 변경을 추적하게 만든다. 코더는 여전히 본인이되, 증강된 코더가 되는 것.
Evidence
- 유료 LLM에 대한 의존성 우려가 크게 제기됐다. 프로그래밍은 원래 무료/오픈 도구로 가능했는데, Gemini나 Claude 같은 유료 모델이 표준이 되면 월 $200 비용 문제가 아니라 서드파티 의존성 자체가 문제라는 의견이 많은 공감을 얻었다.
- Claude GitHub Action으로 10~20개 이슈를 구현해본 경험 공유가 있었다. 작고 독립적인 기능은 혼자 잘 처리하지만, 중간 규모 작업은 겉보기엔 동작하는데 실제로 안 되는 코드를 자주 만들어서, claude.md에 정보를 추가하거나 이슈를 잘 써도 해결이 안 되는 좌절감이 있었다고 한다.
- LLM에게 코드를 바로 쓰게 하지 말고, 먼저 '무엇을 할 건지 설명해봐'라고 하면 이후 생성 코드 품질이 훨씬 좋아진다는 팁이 공유됐다. 2~3번 피드백 후 구현하게 하는 방식.
- antirez와 달리 Gemini 2.5 PRO와 Opus 4는 아키텍처 수준에서 쓰고, 실제 코딩은 Sonnet에게 맡기는 게 더 효과적이었다는 반론이 있었다. Gemini는 코딩 시 자기 수정 루프에 빠지는 경우가 많았다고 한다.
- 에이전틱 코딩 시 대화당 하나의 브랜치를 만들고, 같은 작업을 2~3개 브랜치에서 병렬로 돌린 뒤 가장 좋은 결과를 고르는 전략이 공유됐다. 단일 버그픽스라도 브랜치를 따는 것이 좋다는 의견.
How to Apply
- 코드 리뷰에 LLM을 도입할 때, 코드베이스 전체 + 관련 문서를 컨텍스트로 넣고 '이 코드에서 버그를 찾아줘'라고 요청하면 사람이 놓치기 쉬운 off-by-one이나 null 처리 누락을 잡아낼 수 있다. Redis Vector Sets 사례처럼 실제로 배포 전 버그를 많이 제거할 수 있다.
- LLM에게 코드를 바로 생성시키지 말고, 먼저 '구현 계획을 설명해봐'라고 한 뒤 피드백을 2~3회 주고 나서 코드를 쓰게 하면 품질이 크게 올라간다. 특히 중간 규모 이상 작업에서 효과적.
- 자신의 전문 외 기술(예: 익숙하지 않은 언어나 플랫폼)로 작업해야 할 때, 해당 기술의 공식 문서나 README를 컨텍스트에 함께 넣으면 LLM이 즉시 전문가 수준으로 가이드해줄 수 있다.
- 에이전틱 코딩 시 같은 작업을 2~3개 브랜치에서 병렬 실행한 뒤 가장 좋은 결과를 선택하는 전략을 쓰면, 단일 시도의 불확실성을 줄일 수 있다.
Terminology
바이브 코딩LLM에게 전체 코드 작성을 맡기고 사람은 거의 개입하지 않는 코딩 방식. '분위기(vibe)대로 코딩한다'는 뜻에서 유래.
에이전틱 코딩LLM이 단순 코드 생성을 넘어 파일 수정, 테스트 실행, 디버깅까지 자율적으로 수행하는 코딩 방식. Claude Code나 Cursor 같은 도구가 대표적.
컨텍스트 윈도우LLM이 한 번에 읽을 수 있는 텍스트의 최대 길이. 이 안에 코드, 문서, 대화 내용이 모두 들어가야 해서 관리가 중요하다.
로컬 미니마최적이 아닌데 그럴듯해 보이는 해결책에 갇히는 것. 산을 내려가다 작은 웅덩이에 빠져서 더 깊은 골짜기를 못 찾는 상황과 비슷.
어댑터 패턴기존 인터페이스에 맞추기 위해 중간 변환 계층을 두는 디자인 패턴. LLM이 패턴이 명확한 코드를 잘 생성하는 대표적 사례로 언급됨.