▲

코딩 LLM에서 가치를 얻는 데 어려움을 겪는 사람 있나요?

 (news.ycombinator.com)
2P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • 코딩 LLM을 활용해서 명확한 가치 창출에 어려움을 겪는 개발자들이 존재함
  • 일부 사용자는 LLM의 출력 품질에 만족하지 못함
  • 구체적인 요구 사항이나 복잡한 문제에서는 LLM이 기대에 미치지 못하는 경향 발생함
  • 반면 간단한 자동화나 반복 작업에는 일정 수준의 편리함 경험함
  • 개발자들은 프롬프트 엔지니어링이나 워크플로우 개선 방법을 모색하는 중임

코딩 LLM 사용의 어려움과 개선 방법 논의

LLM의 제한적인 가치

  • 최근 많은 개발자들이 ChatGPT, GitHub Copilot, Claude 등 코딩 LLM을 다양한 용도로 실험 중임
  • 하지만 상당수 사용자는 기대한 만큼 실질적인 생산성 향상을 체감하지 못하는 현상 경험함
  • 특히 복잡한 알고리듬 작성, 대규모 코드 구조화, 프로젝트 아키텍처 설계 등에서는 LLM 추천 코드가 종종 분절적이거나 비효율적임

출력 품질에 대한 불만

  • 일부 개발자들은 LLM이 제공하는 코드가 버그를 포함하거나, 문맥을 충분히 이해하지 못해 부정확한 결과물 제공함
  • 설명이나 분석이 부족하거나, 코드가 프로젝트의 복잡성과 맥락을 제대로 반영하지 못하는 경우가 잦음

간단한 활용 분야에서의 도움

  • 짧은 코드 스니펫 생성, 반복 작업, 단순한 문법 문제 해결 등 기본 수준의 자동화 측면에서는 분명한 편의성 확인 가능함
  • 단위 테스트, 리팩토링, 코드 스타일 수정 등 루틴한 작업에 대한 활용도는 높은 평가 받음

개선을 위한 시도

  • 일부 개발자는 더 나은 결과를 얻기 위해 프롬프트 엔지니어링 기법을 적극적으로 적용함
  • 자신의 워크플로우에 맞는 LLM 활용 방식, 그리고 여러 오픈소스 도구와의 조합을 실험 중임

결론 및 배움

  • 현재로서는 LLM이 모든 개발 요구에 만능 해결책이 될 수 없음을 인정함
  • 커뮤니티와 개발자들은 경험을 공유하면서 효율적인 활용 전략과 한계 극복 방안을 모색하고 있음
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 개발자에는 두 부류가 존재한다는 생각이 들어. 하나는 LLM이 코딩에 있어 완전한 슈퍼파워라고 떠들며 생산성이 100배로 뛰었다고 주장하는 그룹, 그리고 또 한 그룹은 정말 손이 많이 가고 애를 써서 그저 평범한 결과나 얻을 수 있는, 꽤 까다로운 도구로 보는 사람. 그런데 정말 LLM이 혁신적으로 생산성을 높여주는 첫 번째 부류가 그렇게 대단하다면, 그 사람들이 이미 시장을 다 압도하고 경쟁사들을 쓸어버리고 있어야 하지 않을까라는 궁금증이 생김

    • 그린필드 작업에서는 LLM 덕분에 생산성이 체감상 100배까지 올라가는 느낌을 받고 있음. 예를 들어 React 앱에 여러 페이지, Redux 스토어, 인증 등 기본 구조를 추가하는 걸 몇 분 만에 쭉쭉 만들어낼 수 있음. "이제 X를 추가해줘" 하면 대체로 좋은 결과를 내줌. 하지만 기존 시스템 유지보수나 복잡한 기능 추가, 도메인 지식이 중요한 상황에서는 LLM이 별로 쓸모없음. 코드 자동완성이나 함수 보완용으로는 좋지만, 전체 기능 구현 단계에서는 쉽게 한계에 부딪힘. 이런 경우 LLM을 시키는 시간이나 내가 직접 코딩하는 시간이나 비슷함. 그래서 보통 내가 원하는 구조로 스텁 코드를 먼저 짜두고 빈칸만 LLM이 채우게끔 함. LLM이 생산성 100배라고 말하는 사람들은 아직 쉬운 부분만 만나봤거나, 어려움에 아직 부딪히지 않은 것 같음. 실제로 일의 90%가 쉽고, 마지막 10%가 진짜 힘들며 LLM이 그 부분은 제대로 못 해내는 상황

    • 약간 비꼬는 말이지만, 100배 생산성이라고 하는 사람들은 사실 작은 숫자를 100배 하고 있는 셈임. LLM이 리서치 단계에서는 엄청나게 도움 됨. 예를 들어 최근에 명시적으로 일부 도메인에 특화된 선형대수 코드를 짜야 했는데, LAPACK 같은 라이브러리를 못 썼기에 직접 구현함. 이럴 때 LLM을 참고서 대신 써서 원하는 정보를 한 번에 정리해주니, 진짜 연구 시간은 100배로 단축할 수 있었음. 하지만 실제 코드 구현을 LLM에 맡겼더니, 전문가가 아니면 눈치채기 어려운 미묘한 실수가 들어감. 주니어라면 그냥 넘어갈 수도 있었을 일. 나는 코드 리뷰를 중요하게 생각하니, LLM이 아무리 좋아져도 코드 작성 속도 자체는 크게 빨라지지 않을 것 같음. 다만, 어떤 코드를 써야 할지 결정하는 탐구와 요약 단계에서는 LLM이 엄청나게 속도를 높여줌. 결국 혁신과 창의적 아이디어가 세상의 진짜 가치이며, 그건 여전히 인간의 몫이라 생각함. LLM은 중요한 도우미겠지만, 고부가가치 코드는 직접 써야 한다고 믿음

    • 실제로는 이 두 부류 어디에도 속하지 않는 경우가 있음. 100배 생산성은 아니지만, 아주 힘겹게 쓰는 것도 아님. 30년 넘게 전문적으로 코딩을 해오며, 항상 뭔가를 찾아봐야 했고, 구체적인 언어나 문법을 자주 까먹음. 여러 언어를 번갈아 써야 하는 직업도 많았으니까. 예전에는 레퍼런스 북이나 메뉴얼, 심지어 더 힘든 자료까지 계속 뒤져야 했음. 구글 같은 검색엔진 등장 후엔 조금 더 좋아졌고, Stack Overflow 같은 플랫폼은 그보다 더 효율적이었음. 지금은 LLM이 또 한 단계 앞으로 나아간 것임. 오토컴플리트 제안이 때로는 바로 내가 찾던 단서가 되기도 함. 물론 필요 없는 건 무시하지만, 채팅 인터페이스가 구글이나 SO 검색보다 훨씬 대화적으로 질문할 수 있다는 점에서 좋음

    • 수학 공부를 Math Academy, ChatGPT, 유튜브(특히 3Blue1Brown 등)로 하고 있음. 이 조합이 없었으면 고통이었을 텐데, 지금은 즐거움. 예전에 University of Amsterdam에서 비슷한 과정을 들었을 땐 ChatGPT가 지금만큼 똑똑하지 않아서 훨씬 힘들었음. ChatGPT는 선생님이 대답해주기 어려운 질문에도 답해줘서, 수학의 문화적 배경까지 이해해야 공감이 되고 창의적 해결이 가능한 나에게 딱임. 예컨대 왜 각도에서 m을 쓰는지 묻자, 역사적으로 measure에서 왔다고 알려줌. 그래서 이제 본질적인 수학에 다시 집중할 수 있게 됨. 빠른 분산 계산 공식 역시 ChatGPT가 쉽게 설명해줌. 세계를 지배하는 수단은 아니지만, 내가 원래 배우지 못했을 지식을 배우고 있음. 물론 YouTube와 Math Academy의 역할도 큼

  • LLM은 여러 분야를 넓게 다루고, 모든 부분에서 전문가가 아닌 사람에게는 슈퍼파워를 줌. 특정 한 분야만 깊이 파고들어 항상 거기서만 일하면 별로 쓸모없음. 예를 들어, 한 프로젝트마다 한 번 정도만 필요해서 배포 전문가가 따로 없는 상황에서 LLM으로 Dockerfile 작성하는 건 정말 훌륭함. 소소한 문법 오류나 자잘한 문제도 구글보다 빠르게 해결 가능. 아키텍처 트레이드오프에 대해 LLM에 분석을 시켜보되, 최종 결정은 직접 내리면 생산성 향상에 도움 됨. 다만, 프롬프트로 LLM이 멍청한 짓을 안 하게 범위를 잘 좁혀야 하고, 실제로 자주 존재하지 않는 API를 만들어내는 등 말도 안 되는 실수를 하므로 반복적으로 수정도 필요함. 그래도 반복해도 속도 이점이 있음

    • 예를 들어 Dockerfile의 예시를 보고, '겔-만 망각(Gell-Mann amnesia)' 효과가 생각남 https://en.m.wikipedia.org/wiki/Gell-Mann_amnesia_effect 본인이 잘 아는 도메인에서는 LLM이 엉터리 결과를 내는 걸 명확히 알고 절대 내 이름으로 못 올릴 정도. 하지만 모르는 분야에서는 평소 LLM이 엉터리라는 걸 까먹고, 그냥 느낌을 믿게 되는 현상

  • 나도 다양한 방식으로 LLM을 쓰고 있음. 작은 디버깅 문제, 셸 스크립트, 코딩, 질문 등 여러 상황에서 도움을 받음. 사적인 일에는 Claude, OpenAI 외에 Google이나 Perplexity 등 다양한 도구 중 결과가 가장 좋은 걸 골라 씀. 업무적으로는 VSCode에서 Copilot이나 사내 플랫폼을 통해 Claude, OpenAI, Google을 쓰고 있고, Copilot Studio도 약간 실험해봄. 1년 반 이상 이런 방식으로 일해왔고, 모든 도구를 계속 써온 건 아니지만 전체적인 인상은 이렇다. 확실히 LLM 덕분에 생산성은 올랐음. 여러 프로그래밍 언어로 실험도 해보고, 다양한 주제에 대해 더 잘 이해하게 되어 분명히 몇몇 일은 훨씬 수월해짐. 하지만 모델과 버전에 상관없이, 일이 복잡해지고 나만의 길을 걷거나 단순 조합 수준을 벗어나면 모두 실패하는 경향이 분명함. 심지어 LLM의 엉터리 결과를 고치는데 드는 시간이 처음에 LLM 페이스로 아꼈던 시간을 다 까먹는 경우도 있음. 지금 솔직한 결론이라면 LLM은 작은 코드 자동완성, 디버깅, 설명에는 유용하지만 그게 다임. 우리 일자리를 당장 위협하지는 못함

  • LLM로 새로운 라이브러리나 API, 언어를 배울 때 정말 많이 도움을 받음. 예를 들어 OpenGL에서 텍스트를 랜더링하는 법 같은 건 LLM에 바로 묻는 게 방대한 엉망진창 공식 문서를 읽는 것보다 훨씬 빠름. 또는 반복적이고 무료한 보일러플레이트 코드를 쓸 때 기존 코드에서 참고할 만한 게 없으면 LLM이 유용함. 하지만 진짜 '일'이라고 생각하는, 내 서비스 특유의 고유 코드 영역에서는 "코드를 대신 써준다"라는 의미에서 LLM 활용도가 높지 않음. 시니어 엔지니어로서 실제 코딩에 소모하는 시간은 거의 없고, 중요한 건 구조 설계, 레거시 리팩터, 성능 이슈, 희귀 버그 디버깅 등임. LLM은 반복적 코드 작성 속도만 높여주니, 매주 새로운 프로젝트를 처음부터 만드는 게 아니라면 쓸모가 크지 않음. 아직도 보일러플레이트를 많이 쓴다면, LLM만 의존하지 말고 다른 근본 솔루션도 고민해봐야 함

    • 엉망진창 공식문서 정독, 설명하는 데 있어서 LLM이 평범한 프로그래머보다 훨씬 뛰어남. 이 분야에서는 명확히 가치를 추가함. 보일러플레이트가 너무 많은 언어들도 있지 않나 생각

    • 은총알이라는 건 없고, 개념화가 진짜 어려운 부분임. Mythical man-month는 중요 텍스트이니 꼭 더 읽어봐야 함

  • 은총알은 없음. 프레드 브룩스의 간단한 조언을 우리가 계속 잊는 게 신기함. 기대를 너무 부풀리지 않고, 트레이닝 데이터에 버그 있는 코드가 많으니 LLM도 당연히 버그가 있을 거라 이해하고 활용하면 LLM이 훨씬 유용해짐. 설계를 떠넘기지 말고, 함수 분할 등 사전 작업을 나 스스로 하고 지루한 작업, 생소한 영역에서는 LLM으로 번거로움을 줄이는 데 써야 함. 하지만 LLM이 만들어주는 코드라 해도 책임을 지려면 꼭 내 지식과 검증이 전제되어야 함. LLM 코드가 완벽해 보이더라도 결함이 숨어있을 수 있으니, 내 공부와 스킬을 계속 키우며 의심을 품어야 함. 절대 맹신하지 않는 태도 필요

    • 설계 위임이라는 게 아키텍처까지 포함이라면, 그 부분은 LLM이 잘해준다고 느꼈음. 고수준 설계를 요청하고 그걸 여러 번 반복하면서 아이디어를 다듬은 후 구현 단계로 넘어가는데, 실제 현실에서 일하는 것과 유사함

  • 문제 규모가 커지면 LLM이 쓸모없어지는 게 확실함. 반복적 작업이나 복잡한 find & replace에는 탁월함. API 리소스에 CRUD 메소드 채워넣기 등 일상적이고 명확한 코드에서는 매우 유용함. 최근에는 Claude Opus 4로 내 패치 리뷰도 시켜보니, 종종 오류도 잡아주고, 본인이 해야 할 일을 상기시켜주는 데도 효과적임. 하지만 한 번 복잡성 임계점을 넘어서면 LLM 활용도가 급격히 떨어짐. 예를 들어 다수의 비교적 큰 파일에 걸쳐 변경이 필요하면, 이미 스스로 어떤 파일을 바꿔야 할지 자연스럽게 추론하게 됨. 그럼에도 LLM을 '러버덕'으로 쓰는 건 괜찮음. AI가 제대로 해주면 좋고, 아니면 바로 내가 직접 이어서 하면 됨. 결과적으로 LLM이 초반만 도와주고 대부분의 수정 작업은 어차피 내가 해야 할 일이었음. 프레임워크만 대충 맞춰주고 내가 원하는 대로 손을 보는 게 아예 맨바닥부터 짜는 것보다는 수월한 듯함. LLM이 명확히 힘들어하면 억지로 시키지 않음. 명세가 모호해서 잘못 추측했다면 지적하고, 그래도 못 해내면 그냥 내가 마무리

  • 내 경험도 비슷함. 다음과 같은 부분에서 LLM의 가치 발견함. 꽤 독립적인 React 컴포넌트나 페이지를, 인기 있는 UI 라이브러리와 함께라면 아주 잘 만들어냄. 잘 정의된 순수 함수는 꽤 신뢰도 있게 만들어줌, 검증도 쉬움. 유명 프레임워크의 보일러플레이트는 정말 쉽고 잘 만들어줌. 그런데 주변 사람들은 막강한 엔드투엔드 경험을 자랑하지만, 나는 실제로 그렇게 되지 않아서 약간 미치는 느낌임. 평상시 엄청 노력해도 완전한 기능 단위에서는 LLM이 완전 붕괴함. aider 등 툴로 Next.js에서 단순한 템플릿 이메일 기능도 못 만들길래, 기능을 세분화해서 하나씩 시켜보면 조금 나아지지만, 점점 기존 코드가 망가짐. 문제점 설명해줘도 프롬프트를 할수록 더 이상해짐. 결국 수작업으로 고치려 했지만 코드가 완전 엉망이었음

  • 친구 vibe coder들에게 "내 기준이 너무 높다"라고 들은 적이 있음. vibe coder는 기본적으로 코드를 제대로 검토하지 않으니 품질 기준이 없다고 생각함. 만약 vibe coding이 제대로 먹힌다면, 구글 AI 같은 곳은 막대한 GPU, TPU 예산과 최신 AI 모델로 사람보다 압도적으로 빠르게 제품을 개선하고 있을 것임. 만약 정말 그런 일이 일어난다면, 우리 일은 점점 쉬워지기보다 뉴스에서 예상치 못한 엄청난 일이 터지는 걸로 먼저 알게 될 것이고, 그 원인이 AI 때문임은 훨씬 뒤에 알게 될 것임

  • LLM은 일회성 코드에는 좋음. 개발, 유지보수, 디버깅, 고치기 모두 쉬운 건 아님. 대부분의 코드가 사실상 제품이 아닌 '소모용' 코드인 만큼, 여기엔 적합함. 패스트푸드, 조립공장, 자동화 생산 같은 개념이 적용된다 해도 엄청난 차이 있음. 공장에서 기계가 만든 물건은 99.99% 이상 정확히 만들어지니 믿을 수 있음. 하지만 LLM은 매 단계마다 내가 일일이 검증해야 하며, 검증하지 않으면 그냥 작동하지 않음. LLM이 24시간 무인 자동으로 성공적으로 해결하기는 불가능함. 그래서 당장 일자리를 빼앗기지 않는 것임

  • 나는 LLM에 복잡한 문제 전체를 아예 맡겨서 결과를 받아볼 생각은 절대로 하지 않음. 그건 LLM의 강점이 아님. LLM의 진짜 가치는 진행을 도와주는 '힌트'와 단순하지만 시간이 드는 부분을 스킵케 해주는 점임. 며칠 전에 로그 문자열을 만드는 일이 있었는데, LLM이 내가 생각하던 것보다 더 예쁘게 포맷된 코드를 바로 제안해줘서 15분 걸릴 일을 30초 만에 훌륭하게 마무리할 수 있었음. 이런 작은 성과들이 쌓이며 가치를 만듦

    • 복잡하고 장황한 언어는 오토컴플리트, 포매팅 등 툴의 도움이 절실함. 단순하고 표현력 좋은 언어는 notepad.exe만으로도 충분함. Lisp 같이 단순하면서도 강력한 언어는 괄호 하이라이트가 무조건 필요. 10~20년 전 돌아보면 언어마다 변화가 있음. Java, C#, C++이 함수형 언어에서 많이 베꼈고, JVM엔 Clojure, Go는 "if err != nil" 처럼 완강히 고집하는 구문이 있음. Rust는 "?" 추가, Zig도 비슷함. Python은 타입 주석 등으로 점점 길고 복잡해짐. 오토포매터는 정말 편하고, 들여쓰기를 신경 안 써도 되지만, Python은 공백 민감하니 완벽하지 못함. 도구는 장황한 언어에 도움이 되고, 표현력 좋은 언어는 간결한 코드에 도움이 됨. 코드는 쓰는 것보다 읽는 시간이 훨씬 많음. 결정론적 툴은 코드의 구조에 강점, LLM 같이 확률적 도구는 의도에 접근하는 데 강점. 언어모델은 자동화 도구의 진화형이고, 오토컴플리트처럼 점점 좋아지겠지만 코딩을 '완전히 해결'할 수는 없음. 정답이 있는 게 아니라, 결국 의견 차이뿐임
답변달기