▲

LLM을 활용한 코딩 (2025년 여름)

 (antirez.com)
28P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • Redis 개발자 antirez의 LLM 활용기 업데이트
  • Gemini 2.5 PRO와 Claude Opus 4 같은 최첨단 LLM은 개발자의 능력을 강화함
  • LLM을 활용하면 버그 제거, 아이디어 테스트, 지식 확장 등 여러 방식으로 업무 효율 향상 가능함
  • 비전문 분야나 새로운 기술을 LLM의 도움으로 쉽게 다루는 경험이 가능함
  • 그러나 코드의 전반적 품질과 관리를 위해 '인간 + LLM' 협업이 핵심임
  • LLM을 최적으로 활용하려면 충분한 맥락 제공과 명확한 커뮤니케이션 능력이 중요함

LLM을 활용한 개발의 변화와 핵심 포인트

최첨단 LLM(Gemini 2.5 PRO, Claude Opus 4 등)은 방대한 이해력과 대용량 코드 처리 능력을 바탕으로 프로그램 개발자의 능력을 확장하는 역할을 함

  • 명확하게 문제를 기술하고, 반복적인 소통에 익숙하다면
    • 버그를 출시 전 미리 제거하는 경험 가능함(예: Redis의 Vector Sets 구현 사례에서 Gemini/Claude의 코드 리뷰로 즉각적 버그 제거)
    • 아이디어의 작동 여부를 빠르게 테스트하면서 실험적 코드 작성 및 성능 평가 가능함
    • 경험과 본능에 기반한 페어 디자인(pair-design) 이 가능하며, LLM의 풍부한 전문 지식과 인간의 직관이 융합함
    • 명확한 지침을 LLM에 제공하면 일부 코드 구현을 신속하게 완료 가능함
    • 낮선 분야(예: Amiga용 68000 어셈블리 코드)에서도 빠른 기술 적응이 가능함

예전 ‘LLMs와 2024년 초 프로그래밍’ 글에선 LLM의 유용성을 언급했으나, 최근 1.5년간 LLM이 비약적으로 발전함
최상의 LLM 활용을 위해서는 인간과 LLM 모두 특정 역량과 습관이 필요하며, 이에 대한 원칙이 중요함

Vibe Coding의 자제와 인간+LLM 협업 원칙

현재 LLM은 개발자 능력 증폭기로 뛰어나지만, 자율적으로 혼자 모든 업무를 처리하는 수준까지는 도달하지 못한 상태임

  • 테스트, 소규모 유틸리티 등 단발성 소규모 프로젝트에는 LLM 단독 설계가 가능함
  • 하지만 대규모, 비평범한 프로젝트에 LLM 단독 사용 시 복잡함, 불필요한 코드, 구조적 취약성 등 문제 발생 가능성 큼
  • LLM+사람의 협업이 가장 큰 생산성 향상을 보이지만, 전제는 효과적인 커뮤니케이션 및 LLM 관리 경험 보유임
  • 복잡한 작업을 LLM에게만 맡기지 말고, 항상 인간이 과정에 적극적으로 개입하는 전략이 필요함

LLM에 충분한 맥락 제공의 중요성

LLM에게 개발 또는 문제 수정 방향을 제대로 이해시키려면 광범위한 맥락 정보 제공이 필수임

  • 논문, 대상 코드베이스(최대한 전체), 작업 의도 등을 제공하는 게 바람직함
  • 구현 목적, 불필요하거나 허약한 방안, 실현 가능한 핵심 아이디어, 목표, 불변 조건, 코드 스타일 등 핵심 정보를 포함함
  • 예를 들어, LLM이 모르는 신기술(예: Redis vector sets) 다룰 때 README 문서를 맥락에 포함시키면 전문가 수준의 답변 즉시 가능함

LLM 선택과 사용 방법

가장 잘 알려진 LLM이 실제로 최고의 결과를 내지는 않음

  • 코딩에는 Gemini 2.5 PRO, Claude Opus 4가 특히 효율적임
    • Gemini 2.5 PRO는 복잡한 버그 탐지와 문제 해결력이 탁월함
    • Claude Opus 4는 새 코드 작성에 능하며, 사용자 경험도 우수함
    • 두 모델을 번갈아가며 사용하면 복잡한 설계 시 이해도가 커짐
    • 단 하나를 선택한다면 Gemini 2.5 PRO를 추천함
  • LLM 사용 시 준수해야 할 조건
    • 코드 에이전트나 IDE 내 통합 에이전트 사용 지양함
    • LLM이 전체 맥락(코드, 문서 등)을 직접 볼 수 있게 하여 최상의 답변을 유도함
    • RAG(지식 추출 기반) 등 일부 맥락만 보여주는 기능 사용 시 성능 저하 발생함
    • 과정마다 사람이 수작업으로 코드를 복사/붙여넣으며 직접 흐름을 추적해야 함

결론 – 통제 유지가 핵심

코드를 혼자 작성하는 agent의 등장은 멀지 않았지만, 현 시점에서는 사람이 주도적으로 LLM과 협업하는 방식이 가장 날카로운 코드를 생산함

  • 인간이 ‘무엇을, 어떻게’ 할지 결정하는 역할이 여전히 핵심임
  • LLM을 활용하면 기존 지식 경계를 넘어 새로운 기술이나 개념을 배우며 성장 가능함
  • 직접 코드를 통제하면 설계·구현의 일관성을 지킬 수 있으며 LLM의 오류가 주는 불확실성도 최소화됨
  • 에이전트의 성능 발전 상황을 주기적으로 점검하는 것도 현명한 전략임
  • 이 단계에서 LLM 활용을 회피한다면 변화에 뒤처질 수 있으므로, 균형 잡힌 활용법이 중요한 시점임
▲
GN⁺ 4일전  [-]
Hacker News 의견

  • Gemini 2.5 PRO나 Claude Opus 4 같은 사설 LLM 모델이 표준이 되어가는 현실이 안타까움 느끼는 중임, LLM의 발전과 도구로써의 강력함은 매우 긍정적으로 보지만, 왜 개발자들이(유명 인사든 무명이든 상관없이) 계속 프로그래밍을 하려면 제3자 유료 서비스에 의존해도 괜찮다고 여기는지 이해하기 힘듦, 과거에는 오픈소스와 무료 도구만으로도 코딩이 가능했음, 앞으로 몇 년 뒤에는 유료 LLM에 의존하는 게 지금 IDE나 vim 없이 코딩하는 것만큼 불편해질까봐 걱정임, 월 $200이 별거 아니지 않냐는 식의 얘기는 근본적인 문제를 해결하지 못함

    • 지금 로컬에서 돌릴 수 있는 오픈 모델은 질적으로 부족하고, 무엇보다도 운영비가 훨씬 큼, Claude 4 급 모델을 개인 컴퓨터에서 경제적으로 돌릴 수 있게 되면 그때 많은 사람들이 시도할 것임, 현재로서는 Kimi K2 같은 모델이 512GB Mac Studio 두 대에서 돌아가지만, 장비값만 약 $20,000임

    • 구독 모델의 가치가 초기에는 아주 뛰어난 가격 대비 효율성을 제공하는 것처럼 느끼게 만듦, 하지만 점차 가격이 오르고 품질이 떨어지면서 결국은 서비스에 묶여버리는 상황이 됨, 마치 블랙미러의 "Common People" 에피소드처럼 됨

    • 개인적으로는 모든 개발자가 유료 LLM에 무조건 종속되는 미래는 일어나기 힘들다고 생각함, 장기적으로는 코드를 많이 양산하는 것 자체가 문제라는 현실을 사람들이 깨달을 것이라 봄, 코드는 부채이고 불안정하거나 느린 코드가 쌓이면 그 부채도 커짐, AI가 사라지지는 않겠지만 열기가 좀 식고 나면 어디에 어떻게 써야 하는지에 대한 이해가 늘어날 것임, 또 투자금이 마르면 어떻게 될지도 의문임, OpenAI, Anthropic은 수익성이 없고 계속 자본이 들어와야 지금 상태를 유지할 수 있음, 만약 LLM의 진화가 지금 정도가 끝이고 이게 한계라면 투자금도 빠질 테고, 그러면 사용 비용이 오르거나, 완전히 서비스에서 사라질 수도 있다고 봄

    • 현실적으로는 큰 문제 아니라고 생각함, 생산성 향상에 실질적인 이유가 없다면 비싸고 불친절한 서비스에 계속 종속될 이유가 없음, 오픈 모델들도 꾸준히 발전하고 있어서 오픈 모델과의 격차가 크지 않으면 계속 이용할 필요 없음, 만약 LLM 발전이 멈추지 않고 가파르게 발전한다면 우리도 기존 방식으로는 경쟁력이 없으니 다른 영역으로 전환해야 함, 결론적으로 크게 걱정할 필요는 없다고 생각함, 또한 대형 모델 기업들의 가치가 실제보다 매우 과대평가되어 있다고 느끼고 있음

    • 오픈소스와 무료 도구로 코딩할 수 있다는 말에 덧붙이고 싶음, JetBrains는 동료들보다 오래된 기업이고, MS의 Visual Basic/C++/Studio가 윈도우 개발을 쉽게 만들어주었지만, 모두 유료임

  • "PhD-level knowledge"라는 표현에 동의하지 않음, PhD 과정은 기존 지식 습득이 목적이 아니라 연구를 수행하는 방법을 배우는 것이 핵심임, AI 논의에서 흔히 오해되는 포인트인데, 박사학위 수준의 지식이라는 말이 의미가 불분명해짐

    • PhD라는 게 연구를 익히는 과정이라는 것 외에도, 질문을 던질 수 있느냐가 핵심임, LLM은 "풍부한 지식을 가진 게으른 노동자"에 가깝고 스스로 질문하면서 가설을 탐색하지 않음, 실제 경험을 예로 들자면, Claude Code(Max Pro)에게 테스트 어서션 수를 주석 처리하게 했더니 원래 계획에서 잘못된 가정을 바탕으로 버그가 생겼음, 내가 직접 계획을 다시 쓰라고 지시해야만 이유를 찾고 고칠 수 있었음, 예를 들어 ORM 객체가 null 값을 가진 이유는 커밋 후 refresh가 없었고, 다른 DB 세션에서 불러왔던 것이 세션 종료 후에도 그대로 남아서 생겨난 문제였음

    • 동의함, 전문가 수준의 지식은 있지만 인간이 잘하는 걸 LLM이 그만큼 하지 못함, 예를 들어 LLM은 단번에 비상한 프로그램을 처음부터 끝까지 써줄 수 있는데, 반복적으로 개선하는 건 어려움

    • PhD가 지식 그 이상이라는 점을 이해한다 해도, 그 지식에 쉽게 접근할 방법이 생겼다는 건 엄청난 가치임, 예전 회사에서 PhD만이 답할 수 있는 난해한 질문(거칠게 말해 "두 소재 경계에 일정 방향 전압 가하면 무슨 현상이 생기나요?" 같은 질문)에 LLM이 꽤 쓸만한 답을 내놓기도 함

    • PhD를 땄다고 해서 과목 자체는 더 신경쓰지 않음, 결국 중요한 건 연구 수행법을 배웠다는 것임

  • LLM 기반 코딩에 관한 논의는 다루는 도메인과 사용하는 프로그래밍 언어에 대해 반드시 언급해야 한다고 생각함, 이 두 변수가 LLM 활용 방식보다 훨씬 큰 영향력을 가짐, 누군가 LLM 코딩을 좋아하거나 싫어한다면 어느 영역의 문제를 풀었는지 먼저 묻고, 직접 AI로 그 문제를 해결해 보아야 각자의 입장을 잘 이해할 수 있음, 그렇지 않으면 언제나 "너가 잘못 써서 그래", "나는 시도했는데 별로더라" 같은 소모적인 얘기만 나온다고 봄

    • 사용자의 프롬프트와 원하는 결과를 얻기까지 얼마나 많은 노력이 들어갔는지 구체적으로 공유되어야 한다고 생각함, LLM 사용법을 설명한 글에서 인간이 얼만큼 세부 정보를 제공하고, 전체 맥락과 이해도를 '브레인 덤프'로 전달해야 함을 강조했음, 그렇게까지 해서 나온 코드라면, 차라리 직접 코드를 쓰는 편이 낫지 않나 하는 생각도 듦, 실제로 입력하는 시간은 별 문제가 아니고 문제를 명확히 설명하는 게 진짜 핵심임

  • 최근 agentic coding에 몇 달간 집중하며 일한 경험을 바탕으로, 게시물의 모든 말에 공감함, 최첨단 LLM이 그나마 제일 쉽게 쓸 수 있지만 오픈모델도 곧 따라올 거라 기대함, LLM에게 새로운 방법을 추천받거나 이미 알고 있는 접근법을 제시하도록 할 수도 있음, 가끔 LLM이 내용을 복잡하게 만드는 경향이 있으니 미리 감지하거나 리팩토링을 요청하면 됨, 다양한 모델이 나올 때마다 또 상황은 달라질 것임, 모든 작업에 최첨단 모델이 반드시 필요한 건 아님, 단순한 기능/버그 픽스에는 Copilot도 꽤 괜찮은 출발점임, 모두들 새로운 변화 속에서 다양한 시도를 해보고 배우는 과정을 즐겼으면 좋겠음

  • Claude의 GitHub action을 10~20개 정도 이슈 구현과 PR 리뷰에 써봤는데, 말 그대로 히트 앤 미스라 무분별한 자동화보단 증강 도구로 쓰는 게 맞다는 데 동의함, 변경사항이 작고 테스트가 잘 갖춰진 소규모 기능/리팩터링은 거의 자동으로 성공함, 액션으로 돌리면 내가 다른 할 일을 할 수 있어서 장점임(이슈도 Claude가 써주면 더 편함), 하지만 중간 규모 이상에서는 종종 코드가 그럴듯해 보이지만 실제론 동작하지 않는 결과가 나옴, 이건 테스트 커버리지 부족 내 책임일 수도 있지만 확실히 자주 발생함, 이슈를 더 상세하게 써주거나 promt를 다양하게 줘도 결과는 실망스러움, 대형 작업은 두말할 것도 없이 힘듦, PR 리뷰 기능은 소/중규모 일에선 쓸만하지만 쓸모없는 확인도 많음, 결론적으로 LLM이 스스로 코딩하는 데는 아직 멀었다고 생각함, 소규모 작업만 이슈 써주고 PR이 올 때까지 기다리는 식이 제일 효율적임, 대부분의 작업(중간 규모)에서 나는 주로 Claude에게 디렉션만 하면 코딩은 거의 안 해도 되어 생산성은 확실히 오름, Gemini도 사용해 봤는데 그냥 놔두면 예측 못할 수준으로 코드가 요동침, 사내에서 Copilot로 PR 리뷰도 하고 있지만 별 효과 없음, 대규모 코드베이스라면 Gemini 활용도가 더 높을 수도 있겠다 싶음

  • OP와 다르게 한 달간 집중적으로 이 분야를 파면서, Gemini 2.5 PRO와 Opus 4는 아키텍처 같은 추상적 논의에선 더 좋은 결과를 보여줌, 그리고 개별 코드 구현은 Sonnet에게 넘기는 방식이 효율적이었음, 2.5 PRO, Opus 는 정답 주위에서 맴돌다 스스로 수정을 반복하는 패턴이 많고, Sonnet은 답까지 직설적으로 가는데, 대신 충분히 세세한 지시가 필요했음

    • 충분히 가능한 얘기임, 실제로 Sonnet/Opus 4는 최고의 결과에선 더 강력하지만, 일부는 Sonnet 3.5v2(3.6이라고도 함)나 심지어 3.7보다 일관성이나 정렬이 뒤처지는 부분도 있음, 또한 모델도 복잡한 객체라서 도메인에 따라 "약해 보이는" 모델이 더 잘 작동하기도 함, 그리고 대화형(Interactive) 환경과 에이전트 지향 환경은 강화학습 기법 자체가 달라서 어떤 방식으로 쓰냐에 따라 모델의 퍼포먼스가 달라짐

    • 실제 내부 통계 데이터에서도 Opus와 Gemini 2.5 pro가 현실적인 환경에서 Sonnet 4보다 성능이 떨어진다는 결과가 확인됨 관련 통계 링크

    • 나 역시 비슷한 경험을 함, Gemini 2.5 Pro는 AI Studio에서 큰 설계 아이디어 검증/정제에 쓰고, Claude Code로 요건을 가져가면 대체로 깔끔하게 코딩해줌, 최근 Gemini CLI도 해봤는데 Claude Code에 비해 코딩 실력이 매우 뒤처짐, 구문 오류도 많고 루프에서 못 빠져나와서 결과물이 장황하고 빨라서 따라가기도 힘듦, 반면 Claude Code는 디버깅력도 탁월함, "큰 그림" 문제풀이에는 DeepSeek R1도 써볼 만한데, 매우 느리지만 정답률이 높음

  • AI/LLM이 때로는 엄청나게 비효율적인 코드를 작성하는 현실적인 사례를 공유함 관련 블로그 링크

    • 마찬가지로 AI는 Code Golf(코드 길이 최소화 게임)에 매우 약함, 비밀스런 단축 기법들을 다 알 것 같지만 실제론 장황하게 짜는 걸 더 좋아함

  • LLM에게 먼저 원하는 작업을 직접 설명만 해 달라고 요청하고, 내가 중간에 피드백을 주면서 몇번 반복을 거치고 나면, 그 다음 나온 코드의 품질이 훨씬 좋은 경험을 했음, 상세계획을 먼저 확인시키고 진행하면 효과적임

  • 내 경험상 프론트엔드에서 검증하기 쉬운 반복적이고 단순한 작업은 vibe coding으로 맡겨도 되지만, 평소엔 내 코드를 리뷰하고 각종 대안들을 평가하는 스파링 파트너로 LLM을 씀, 추천이 말도 안 되거나 논리적 결함이 있어도 내가 너무 당연한 걸 놓치지 않게 도와줘서 만족함, 복잡하게 꼬인 문제를 두고 오히려 과한 시도를 하려는 내 습관도 고쳐줌

  • OP가 말하는 방식이 정확히 뭔지 이해가 안 됨, 혹시 redis C 파일을 수작업으로 Gemini Pro 웹 챗창에 붙여넣으란 건가?

    • 나 역시 그 부분까지는 고개를 끄덕였는데, LLM을 쓸 때는 agent 혹은 에디터 통합형 코딩 도구를 피하라는 게 핵심 요구처럼 보임, 근데 진짜로 창에 코드를 복붙하라는 건가? Cursor 나오기 전엔 그렇게 했지만, 지금은 그렇게 할 필요 없고, 자세히 보면 Cursor나 Claude Code 언급은 아예 빠져있어서 정말 이런 도구를 써봤는지조차 의문임
답변달기