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 언급은 아예 빠져있어서 정말 이런 도구를 써봤는지조차 의문임
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로 그 문제를 해결해 보아야 각자의 입장을 잘 이해할 수 있음, 그렇지 않으면 언제나 "너가 잘못 써서 그래", "나는 시도했는데 별로더라" 같은 소모적인 얘기만 나온다고 봄
최근 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이 때로는 엄청나게 비효율적인 코드를 작성하는 현실적인 사례를 공유함 관련 블로그 링크
LLM에게 먼저 원하는 작업을 직접 설명만 해 달라고 요청하고, 내가 중간에 피드백을 주면서 몇번 반복을 거치고 나면, 그 다음 나온 코드의 품질이 훨씬 좋은 경험을 했음, 상세계획을 먼저 확인시키고 진행하면 효과적임
내 경험상 프론트엔드에서 검증하기 쉬운 반복적이고 단순한 작업은 vibe coding으로 맡겨도 되지만, 평소엔 내 코드를 리뷰하고 각종 대안들을 평가하는 스파링 파트너로 LLM을 씀, 추천이 말도 안 되거나 논리적 결함이 있어도 내가 너무 당연한 걸 놓치지 않게 도와줘서 만족함, 복잡하게 꼬인 문제를 두고 오히려 과한 시도를 하려는 내 습관도 고쳐줌
OP가 말하는 방식이 정확히 뭔지 이해가 안 됨, 혹시 redis C 파일을 수작업으로 Gemini Pro 웹 챗창에 붙여넣으란 건가?