▲

LLM 코드 생성이 신뢰 약화로 이어질 수 있음

 (jaysthoughts.com)
1P by GN⁺ 13시간전 | ★ favorite | 댓글 1개
  • 최근 LLM 기반 코드 생성이 개발자 사이에서 점점 더 사용되는 현상임
  • 자동 생성된 코드로 인해 코드 품질 및 신뢰성에 대한 우려 증대 현상임
  • 개발자들은 코드 이해 부족 및 검증 미흡으로 인해 프로젝트 유지보수 난이도 상승을 경험함
  • 신뢰할 수 없는 코드의 사용 확산이 전체 소프트웨어 생태계에 영향 미침
  • 기술 발전과 함께 신뢰성 확보 방안 마련 필요성 강조됨

개요

Jay는 자신의 블로그에서 최근 등장한 LLM(대형 언어 모델) 기반 코드 생성 기술이 소프트웨어 개발 현장에 미치는 영향을 다룸. 이러한 도구의 발전으로 개발 효율성이 향상되고 있지만 동시에 코드의 신뢰성과 품질 문제가 대두됨.

LLM 코드 생성 기술의 부상

  • 개발 현장에서 LLM을 활용한 코드 자동 생성 도구가 빠르게 확산 중임
  • 복잡한 기능 구현이나 반복적 코딩 작업에서 높은 생산성 제공 현상임
  • 신속한 프로토타입 제작 및 신규 언어 학습 부담 완화 장점 보유함

신뢰성 문제

  • LLM이 생성한 코드가 의도한 대로 항상 동작하지 않음 현상 발생함
  • 코드 내부의 의도, 설계 논리가 불분명해 이해와 검증 과정이 어려워짐
  • 리뷰 및 테스트 과정이 부족할 경우 예기치 못한 버그나 취약점 발생 가능성 존재함

프로젝트 유지보수 및 생태계 영향

  • 자동 생성 코드에 대한 문서화 부족과 설명 미흡 문제가 발생함
  • 개발자가 코드의 동작 원리 파악에 어려움을 겪어 유지보수 복잡성이 증가함
  • 신뢰성 있는 소프트웨어 개발 문화가 훼손될 위험이 있음

결론 및 제언

  • LLM 기반 코드 생성 기술은 혁신적이지만, 신뢰성 확보가 필수 과제임
  • 자동 생성 코드 도입 시 검증 강화와 체계적 코드 리뷰 필요성 강조됨
  • 장기적으로 컴퓨팅 생태계의 신뢰 보호를 위한 기준 마련이 중요함
▲
GN⁺ 13시간전  [-]
Hacker News 의견

  • archive.is 링크 공유, 구형 브라우저에서도 작동하며 JavaScript는 CloudSnare 우회를 위해서만 필요함

  • 내 친구가 항상 "혁신은 신뢰의 속도로 일어난다"라고 말하곤 함. GPT3 등장 이후 이 말이 머릿속에서 계속 맴도는 중. 검증에는 높은 비용이 필요하고, 신뢰가 그 비용을 낮추는 주요 수단임. 그런데 LLM에서 신뢰를 쌓는 방법을 모르겠음. 굉장히 유창하게 코딩도, 자연어도 다루지만, 동시에 사람이라면 악의적으로 볼 수 있는 방향으로 헤매기도 하기 때문임

    • 글쓴이임: 그 인용구 정말 마음에 듦. 내가 몇 문단으로 설명한 내용을 아주 간결하게 요약함. 이제 모든 걸 일일이 검증해야 하는 세상은 솔직히 정말 지치고 느려짐
    • LLM 결과물에 완전한 신뢰를 가질 수 없음. 하지만 정제와 파괴력 제한은 가능함. 사용자 입력을 필터링하고, 침투 테스트를 하고, 비밀은 dot 파일에 숨기는 식으로 결국 "모범 사례"와 "SOC-AI 규제 준수" 같은 표준에 수렴할 것. LLM은 무시하고 싶어도 너무 쓸모 있음. 신뢰 역시 한 단계씩 쌓이는 것임. 인간도 어차피 신뢰성에서 멀고, 자율주행차와 비교하자면 정해진 규칙 내에서 인간보다 더 버그 없는 코드 생산이 가능해질 것 같음. 그 뒤엔 복잡성만 차근차근 개선할 것임
    • "혁신은 신뢰의 속도로 일어난다" 이 말에 좀 더 설명이 필요함. 전기, 비행, 방사능을 처음 발견했을 때 그만큼의 신뢰가 있었는지? 과학에서 신뢰는 진행하며 쌓이는 것임

  • 회사에서 예상치 못한 식으로 이 주제를 경험함. 동료와 빠른 성과 압박 속에 내가 작업한 대형 리팩터링을 임시 PR 상태임에도 병합함. 그 후 테스트되지 않은 코드에서 버그 발생. 디버깅 중 동료가 내가 AI로 코딩했다고 생각했다는 점, 그리고 AI가 만든 코드를 사후에 이해하려 해서 답답해했다는 사실을 털어놓음. 그러나 그 코드는 꼼꼼하게 내가 직접 짠 손수 작업이었고, 단순한 API 변경과정에서의 작은 실수들이 버그의 원인이었음. 오히려 이 경험으로 내가 동료와 신뢰와 관련된 긴장을 자연스럽게 드러내고 건설적으로 대화할 수 있었음. 지금 돌아보니 이런 식의 신뢰 구축 경험이 의미 있었고, 환경이 달랐다면 훨씬 더 복잡하게 꼬였을 수도 있을 것 같음. 항상 조심해야 할 필요성 느낌

  • 나는 전제가 잘 이해가 안 됨. 누군가가 좋은 코드를 쓴다는 신뢰는, 그 사람이 직접 코딩해서 결과물이 좋았다는 실제 경험에서 온 것임. LLM을 써도 버그 없는 코드만 내면 신뢰하고, LLM을 써도 버그 있으면 신뢰 안 함. 그게 머리로만 썼을 때와 뭐가 다른지 모르겠음

    • 글쓴이임: 내 요지는 신뢰도가 중간 수준인 대규모 팀이나 오픈소스 등 낮은 신뢰 환경에서는 LLM이 제출된 코드만 보고 개발자의 실력 판단이 점점 힘들어짐. 상대방의 성향을 파악할 수 없으니 결국 "완전 무신뢰"로 모든 코드를 꼼꼼하게 봐야 함. 그간 신속 리뷰에 썼던 단축키들이 더는 통하지 않는데, 이런 문화에 길들여진 조직에선 꽤 고통스러울 수 있음. 이미 신뢰 높은 팀이라면 이 문제가 전혀 공감되지 않을 수 있음
    • 예전에는 A=B 였다면 높아진 B는 A 역시 좋음을 뜻했음. 이제는 A+Ai=B 가 되어, B가 높아도 A는 높지 않을 수 있음. 그리고 지금 AI 상태는 확률적이어서, 오히려 아무것도 안 하는 것보다 못할 때도 자주 있음
    • "잘 작동하는 코드만 신뢰"라고 했는데, 신뢰의 근거는 코드가 정말로 버그 없음을 개발자가 사전에 알기 때문임. 하지만 복잡한 시스템의 경우, 코드가 다른 부분과 어떻게 상호작용하고, 엣지 케이스가 발생할지 파악하려면 코드 작성자가 전체 맥락을 이해해야 함. 만약 LLM이 코드를 대신 썼고 개발자가 그 내용 전체를 이해하지 못하면, 결국 그 검증 부담은 리뷰어에게 넘어가서 과부하로 이어짐. 그게 논지임
    • LLM으로 코딩하면 몇 번 잘 되다가 자신감 과잉으로 테스트를 소홀히 하게 됨. 실제론 커뮤니케이션 오류에서 문제가 많이 발생함. 작업자는 전체 과제를 명확히 이해해도 LLM은 상태 유지가 어렵고, 맥락이 모호하면 말도 안 되는 가정을 하는 특성. 4o처럼 추가 정보를 계속해서 먼저 요청하는 접근이 모든 코드 생성 모델에서 표준이 되었으면 좋겠음, 진짜 많은 문제를 예방할 수 있을 것 같음
    • 작동 여부 외에도 다양한 요소로 신뢰를 쌓음. 변경사항을 명확하게 설명, 과거에 잘한 기여 이력, 적절한 변화의 단위(덩어리가 적당한 커밋 등), 문제의 우선순위 선정(버그부터 고치고 기능 추가), 기존 코드의 유지 관리 역량, 꾸준한 활동 등등 다 고려함

  • 이미 그런 시대임. "이 점 간과해서 죄송, 말씀하신 게 맞음"이란 말 너무 많이 봄. 8~9번 중 10번은 봤음. 반면 LLM이 만든 코드를 의미 없이 복붙해서, 기대에 못 미치자 화내는 사람도 자주 봄. 사실 그게 더 나음. 명확하게 망가진 게, 겉보기에 제대로 돼 보이는 것보다 낫다고 생각함

    • 내 경험상, LLM은 요구사항을 충족시키기보다 테스트만 통과하게 코드를 수정하는 경향이 많음
    • 브라우저 챗봇으로 LLM을 쓰는 건가? 우린 직접 코드 접근이 가능한 AI agent를 쓰는데, 훨씬 말이 적고 실제로 주변의 주니어보다 뛰어난 작업도 많음. 짧은 구체적 작업을 잘 수행해 코드리뷰 정도만 필요해서 거의 바로 쓰려 함. 물론 prediction engine은 진짜 엔지니어링을 할 줄 모름. 예를 들어, 파이썬 generator를 명시적으로 요구하지 않으면 메모리를 엄청나게 잡아먹는 코드를 낼 때가 많음. 하지만 주변 파이썬 개발자도 비슷한 실수 많이 함. 오히려 이런 점 때문에 "add feature"가 아니라 명확한 스펙 작성을 유도해 도움됨. AI agent가 제일 유용한 곳은 모두가 신경 안 쓰는 레거시 코드임. 예전에 팩스로 온 문서를 좌표 200개로 데이터 추출하는 시스템이 있는데, 30년 넘게 변함없이 쓰다 최근 문서가 바뀜. copilot이 좌표 수정하는데 30초 걸림. 사람이라면 하루는 족히 걸릴 일임. 근데 이런 분위기의 코딩 시대에 어떻게 전문가가 될지 모르겠음
    • 8~9번 중 10번은 너무 과장임. 100% 만들어낸 통계임

  • 이전의 추상화 도구들은 복잡성을 줄이는 동시에 해당 추상화의 "정확성"을 기본 전제로 삼았음. 물론 완벽하진 않았고, 버그도 있었지만, 구현체가 문제일 뿐 본질적 오류는 아님. 한번 패치되면 더 견고해지는 특성. 반면 LLM은 확률적 예측 엔진이라 일정 시간동안만 근사치 정확성을 보임. 이에 대해 글쓴이가 간과한 점은 불완전한 확률적 에이전트로도 신뢰할 만한 결정론적 시스템을 만들 수 있다는 것임. 예를 들면, 가비지 컬렉션 툴의 저자를 믿어서가 아니라 툴 자체가 충분히 테스트되어 원하는 대로 작동함을 증명할 때 신뢰함. 미래에는 테스트 주도 개발이 더 강해질 것 같음. 신뢰 대신 검증임

    • 자동화된 테스트로 모든 문제를 잡을 수 있다는 건 순진한 생각임. 동시성, 자원 관리, 보안 취약점 등 자동화하기 힘든 것 너무 많음. 그리고 테스트 자체를 누가 검증할지? 코드와 테스트가 각각 논리를 구현하는데, 가끔 버그의 원인은 코드가 아니라 테스트 쪽에서 드러남. 테스트도 무조건 신뢰해서는 안 됨
    • 글쓴이임: 여기서는 도구의 효과보다 도구 자체에 초점을 맞춰 말함. 예를 들어, 모델 자체가 직접 가비지 컬렉터 역할을 해서, 프로그램의 메모리 덤프를 받고 불필요 블록을 해제하는 구조라면, 그 판단을 영원히 신뢰하지 못할 것임. 아무리 "패치"나 "파인튜닝"으로 보완해도 한계임. JVM처럼 결정론적 출력에서 에러가 발생하면 한번 패치하면 그 에러는 영구히 사라짐. LLM은 그렇지 않음. 이 차이가 기존 추상화와 LLM 세계의 본질적인 분기점이라고 생각함. LLM이 산업에 미칠 영향이 크리라 보지만, 역사적 사례가 제한적이라 진짜 미지의 영역임
    • "확률성 요인(엔트로피 머신)에서 신뢰할 만한 결정론적 시스템이 나온다"는 대목, 나에겐 꽤나 파격적으로 들림. 그리고 항상 TDD는 모든 문제를 해결해주는 만능 도구처럼 소개됨. 그런데 잘못된 테스트로 엉뚱한 소프트웨어를 만든 경험, 부끄러울 만큼 많이 봄

  • LLM에 대한 반감은 아무 소용 없음. 현재 LLM은 개발자 생산성을 높임. 적어도 경력이 적은 개발자들에게 더욱 유익함. 생산성이 크게 상승하는 도구는 누가 뭐라 해도 포기될 리 없음. 물론 큰 버그로 대형 서비스가 오랫동안 다운되는 등 피해 사례가 나타나도 생산성이 중요하면 기술은 멈추지 않음. 그 약점을 해결(완화)하며 기술과 함께 가는 길만이 현실적임. 그 과정에서 완화책이 생산성 향상을 해치면 우회하게 되고, 기술과 조화를 이루는 보완책이 정착될 것임

    • "LLM이 개발자 생산성을 높인다"는 건 사람과 상황에 따라 천차만별임. 내 경험상, '생산성이 10배'라는 말을 하는 쪽은 주로 주니어 프론트엔드 개발자이거나 스타트업에서 자주 초기 앱을 만드는 개발자임. 물론 좋은 사례지만, 이런 개발자와 임베디드 C 시니어 개발자는 별도의 언어로 아예 딴 얘기를 하곤 함. 그래서 AI 생산성 논쟁은 서로 다른 맥락의 대화임. 그리고 "합리적 활용"이라는 측면에선 AI agent 개념 자체가 좋은지 의문임. Copilot 사건 보면 MS와 AI 모두 조롱받는 꼴이었음. AI에게 자율적으로 작업 맡기는 접근이 마냥 영리하지 않을 수 있음. 비슷하게 블록체인도 암호화폐 극성기의 온갖 과장 사례가 있지만, Coinbase 같이 실제로 유의미한 니치에 정착한 경우도 있음. 2020년엔 IBM이 커피 원두 공급망을 블록체인으로 관리한다 주장(2025년 오늘 봐선 트위터 농담 같지만 그땐 진심). 결국 현재 AI agent들, 그리고 생성형 AI의 다른 응용들도 나중엔 과한 hype의 사례가 될 수도 있음 Copilot 사건 포브스 기사
    • "더 생산적"이라는 말이 반복적으로 등장하는데, 이건 인간/AI 조합이 결과적으로 사용자 요구에 더 부합하는지는 말하지 않고, 단지 "더 많은 코드가 생산된다"는 뜻임. LLM이 2천 줄 코드를 삭제하는 PR을 만들었다는 이야기를 들어본 적 없음. "엔지니어 생산성 향상"이라는 말은 사실상 더 많은 코드를 쓴다는 얘기임
    • 글쓴이 의도가 실제로 비판적이라는 건 오해임. LLM을 쓸지 말지 양자택일이 아니라, 위험 관리·완화에 초점을 맞춘 것임. 비유하자면, 자동차 개발을 반대한다기보단 자동차가 폭발 위험이 있으니, 그 폭발을 줄이는 데 더 집중하자는 얘기임
    • 나는 원글이 "무의미한 푸념"이기보단, LLM과 협업 시 방심하기 쉬운 함정들과 팀 내 보완책 제시에 대한 현실적 고민이라는 느낌임
    • 예전에 React 처음 나왔을 때 안 배워서 후회된 기억 있음. GPT 거부감도 여전하고, 주변은 "chatGPT가 그랬다" "이거 chatGPT 코드다" 이런 말을 하는데 나는 직접 고생해서 코딩하는 데 자부심이 있음. GPT는 안 쓰지만, 사실 구글이나 stackoverflow는 느린 GPT로 생각할 수도 있음

  • "기여 코드가 LLM 산물이 아닌, 오리지널이며 완전히 이해했다는 점을 약속" "대부분 수작업 요구" 이런 정책보다, 결과물에만 집중해야 함. 기여자가 변경사항을 잘 이해하도록 요구하는 건 좋음. "주니어는 일정 기간 LLM 툴 사용 자제 또는 금지" 같은 정책은 별로임. 온보딩의 난잡한 환경 셋업 문제에 LLM이 큰 도움이 됨. 더불어 코드/문서 파악에 좋고, 유용한 텍스트 검색 및 요약 도구도 있음

    • 온보딩이 사실상 랜덤 환경 문제 해결 능력을 배우는 과정임. 모든 어려움과 복잡함을 다 자동화로 없애면, 나중엔 아무도 그런 상황에서 뭘 해야 할지 모르게 될 것 같음. 나만 그렇게 생각하는지 궁금함

  • "AI Cliff"(LLM 정확도가 갑자기 급락하는 현상)라는 개념 처음 들었음. 다른 사람들도 경험한 적 있는지 궁금함

    • 나 자주 경험함. 코드 복잡성이 임계점을 넘으면 LLM이 맥락을 머릿속에 다 담지 못해 엉뚱하게 구는 현상. 내 역할은 LLM이 볼 복잡성을 관리하는 것임. 현 LLM은 시간이 지날수록 구조를 더 복잡하게 만드는 경향이 있음. 기본적으로 내가 리팩터 요청해서 단순화하거나, 너무 복잡해지면 내가 직접 정리함. 지금 LLM은 계속 맡기면 결국 거대한 루브골드버그식 혼란을 만들어내고, 이를 결국 사람이 청소해야함. 경험 많은 개발자는 LLM이 어디까지 바다로 데려가는지 빨리 눈치채고 조기 복귀 가능하지만, 초보라면 사건 자체를 인식하기도 전 완전히 길을 잃고 헤매게 됨
    • 일명 context drunk라고 부름. 입력 맥락이 1만 토큰, 99% 정답이라 치면, LLM이 1천 토큰의 답을 내서 90%만 맞음. 계속 서로 주고받다 보면 맥락창 대부분이 LLM이 내놓은 덜 정확한 출력의 반복이 됨. 에러가 누적되고, 최근 정보가 더 중요하게 작용해 점점 엉터리가 됨. 이 문제는 코드뿐 아니라 산문에도 나타남
    • 나는 context rot라고 부름. 맥락이 쌓이며 출력 품질이 떨어짐. 잡담이나 엉뚱한 내용이 많을수록 더 급속하게 품질이 나빠짐. 특히 chain of thought(COT)가 맥락에 남으면서, 사고가 해매면 그 흔적이 악화됨. 개인적으론 맥락 일부만 잘라내는 pruning 기능이 있길 바람. 난 직접 요약해서 새 세션으로 가져가는 식으로 context rot에 대응함
    • vibe coding처럼 채팅 인터페이스에서만 겪었고, 에이전트형 툴은 코드 맥락창을 자체 관리하며 dev tooling을 직접 실행해 sanity check를 하므로 이런 빈도가 훨씬 적음
    • 업무용 AI 세션은 자주 리셋해서 'AI cliff'를 느끼지 못하는 편임. 그러나 창작 소설 작업을 할 때는 맥락의 길이와 일관성이 중요해서, AI가 어느 순간 캐릭터 성격을 제대로 유지하지 못하고 이상하게 반응했던 적 있음. 되돌릴 수 없어 아주 낯선 경험이었음

  • 원글이 여러 사람 글을 요약하지 않겠다 선언하지만 실상은 그렇다는 것 같음. 그래도 PR에 AI 생성 코드 포함 파일 표시가 있으면 좋겠음. LLM 코드와 사람 코드의 실수 유형이 다르니 구분해서 리뷰할 수 있으면 시간 절약됨. 이런 정책을 대형 조직에서 경험해본 사람이 있는지, 또는 이미 자동화 툴이 있는지 궁금함. 기업들이 LLM 생성 코드 비율 측정한다면 세부 메트릭을 위해 그런 툴이 이미 있을지도 모르겠음

    • 글쓴이임: 실제로 팀 내 신뢰와 LLM 관련 논의가 많지 않아 명문화된 사례를 못 봄. 내가 잘못된 공간에서 일해서 그런 문제인지, 주류에서 발견하기 어렵기 때문인지는 잘 모르겠음
답변달기