Hacker News 의견들

• 기본적으로 LLM은 문제가 생기면 코드를 더 파는 방향으로 해결하려는 경향이 있음
  비효율적인 접근으로 구현하면, 이후 제약을 만날 때마다 우회 코드나 중복 코드를 계속 추가함
  성능이 느리다고 하면 빠른 경로 최적화, 특수 루틴, 커스텀 자료구조를 덧붙임으로써 코드가 기하급수적으로 늘어남
  버그가 많다고 하면 버그마다 테스트를 10개씩 만들고, 기존 모킹 프레임워크가 맞지 않으면 새로 만듦
  중복을 통합하자고 하면 “좋아요, 모든 기능을 포함한 metamock abstract adapter framework를 새로 만들게요!”라며 또 다른 복잡한 구조를 추가함

  • 그래서 사람들이 “아직 프로그래머를 대체할 준비가 안 됐다”고 말할 때 혼란스러움
  • 게다가 이런 통합 작업을 하더라도 실제로는 중복된 코드의 절반만 옮기고, 죽은 코드는 그대로 남겨둠
  • 코드 생성 속도는 빠르지만, 그 결과물이 적절하고 검증된 구현인지 확인하는 데 몇 시간을 써야 함
    잘못된 가정이나 기술 부채를 만들지 않도록 검토하는 과정이 필수임
  • 그래서 나는 top-down 접근을 추천함
    먼저 합리적인 아키텍처를 설계하게 하고, 모듈이 꼬이면 깨끗한 컨텍스트에서 다시 시작하게 함
    LLM은 같은 코드를 반복 수정하는 데는 약하지만, “Groundhog Day”식으로 처음부터 다시 구현하는 데는 강함
  • 핵심은 언제 기존 솔루션(sqlite 등) 을 쓰고 언제 새로 만들어야 하는지 아는 것임
    LLM은 이런 판단의 결과를 경고하거나 상기시키지 않음
    그래서 나는 Codex보다 Claude Code를 선호함

• 법률 문서 작성에서도 LLM의 “그럴듯한” 결과가 문제임
  처음 보면 타당해 보이지만 실제로는 논리적으로 부적절하거나 위험한 주장일 때가 많음
  판사들이 세세히 검토할 시간이나 의지가 부족해 이런 문서가 그대로 통과되기도 함
  이는 Brandolini의 법칙처럼, 생성은 쉽지만 반박은 어렵다는 비대칭 구조를 만듦
  결국 미래의 개발자들이 LLM이 만든 인지적·기술적 부채를 풀어야 하는 상황과 유사함

  • 나도 비슷한 경험이 있음
    규정 기반 문서를 LLM이 작성하면 그럴듯하지만 근거 없는 암시가 포함됨
    그래서 다시 LLM에게 자기 글을 검토하게 해 이런 부분을 표시하게 하지만, 결국 인간 검토가 필요함
  • 코딩도 마찬가지임
    동료들이 LLM으로 수천 줄짜리 PR을 몇 분 만에 생성함
    테스트도 포함되어 있지만 실제로는 엉망인 경우가 많음
    결국 리뷰어가 하루 종일 검토해야 하고, 잘못된 구조를 이해하고 수정 방향을 설명해야 함
    그래서 AI로 만든 PR은 리뷰어에게 스토리 포인트를 줘야 한다고 제안하고 싶음
  • 변호사로서 이런 현상을 보여주는 구체적 사례가 궁금함
  • 결국 추론(reasoning) 자체를 다시 설계해야 함
    합리적 판단을 형식 논리로 계산하고, 그 결과를 자연어로 번역하는 구조가 필요함
    LLM은 사고가 아니라 해석과 표현 단계에 머물러야 함
  • 물론 정의가 훼손되는 이유 중 하나는, 많은 사람이 애초에 적절한 법률 대리를 감당하지 못하기 때문임

• LLM이 만든 코드는 테스트는 통과하지만 요구사항을 충족하지 못하는 경우가 많음
  예를 들어 fsync를 매 쿼리마다 호출하거나, 기본 키를 잘못 식별함
  이런 대규모 프로젝트는 코드가 너무 많아 사람이 전부 읽기 어려움
  그래서 LLM은 자동완성 수준으로 쓸 때 가장 효율적임
  작은 코드 조각을 즉시 검토할 수 있고, Claude는 대체로 정확함
  하지만 전체 코드를 맡기면 계획과 관리에 더 많은 시간이 들고, 유지보수도 어려워짐
  결국 훈련 데이터에 이미 존재하는 코드를 재생산할 때만 속도 이점이 있음

• LLM은 통계적으로 가장 흔한 코드 패턴을 생성함
  그래서 별다른 지시가 없으면 “엔터프라이즈스럽고, OOP 기반이며, 트렌디한 의존성을 잔뜩 설치한 코드”가 나옴

• “정확함”을 정의하고 측정해야 함
  자동화를 위해서는 의도(intent) 와 측정(measurement) 이 필요함
  위험 범위를 이해해야 사전에 얼마나 커버해야 하는지도 알 수 있음
  AI 평가 시스템인 AI evals나 eval-ception 같은 도구가
  역할 간의 공통 언어로 발전하면 협업이 훨씬 쉬워질 것임

• 가장 그럴듯한 코드를 생성하도록 설계된 것이 LLM의 본질임
  이는 cross entropy loss의 결과이며, RLVR 같은 후처리로 정확성을 높이려 하지만
  여전히 많은 잔재가 남아 있음
  앞으로 보상 설계(reward engineering) 가 발전하면 더 나은 결과를 낼 가능성이 있음

• “그게 인간과 뭐가 다르냐?”는 질문에

  • 인간은 목표 지향적 실행 기능을 가지고 있음
    수면 중에는 이 기능이 꺼져서 꿈처럼 비논리적인 사고가 나오는데, LLM의 사고도 이와 비슷한 꿈 논리 수준임
  • 지금 개발 환경에서 놀라운 점은 기술 부채의 가속화임
    예전엔 기술을 완전히 이해하지 못하는 불안이 있었지만, 지금은 도구가 그 불안을 덮어버림
    깊은 이해 없이도 결과를 내는 시대가 되었음
  • LLM은 결국 인터넷의 평균값을 내는 존재임
    하지만 사람들은 객관적이고 정답을 주는 AI를 기대함
    이런 괴리가 일반 사용자와 전문가의 인식 차이를 만듦
  • 품질이 낮은 직원을 해고하는 건 쉽지만, Claude를 해고하자고 설득하는 건 어렵음
  • 문제는 규모임
    하루에 수천 줄짜리 PR을 올리는 사람이 있음
    대부분 엉망이라 리뷰가 불가능함
    예전엔 이런 PR을 만드는 데 일주일은 걸렸을 텐데, 이제는 하루 만에 쏟아짐

• “LLM”이란 용어 자체에 대한 질문이 많음
  raw API로 직접 호출하는 모델이 LLM이고, Claude.ai나 ChatGPT 같은 건 그 위에 하네스(harness) 를 씌운 것임
  이런 하네스는 프롬프트 템플릿, 대화 상태 관리 등 여러 기능을 포함함
  결국 우리는 거의 항상 LLM 그 이상을 사용하고 있음

  • 나는 코드 실행이 가능한 하네스를 “coding agent”라 부름
    이런 에이전트는 코드를 실행하고 스스로 테스트하며 수정할 수 있음
    ChatGPT나 Claude도 이 기능을 갖고 있어 사실상 coding agent임
  • 정리하자면
    • LLM = 모델 자체 (상태 없음, 텍스트 입출력만)
    • LLM + 시스템 프롬프트 + 대화 이력 = chatbot
    • LLM + 도구 + 메모리 + 오케스트레이션 = agent
      그래서 “LLM은 기억이 없다”는 말은 모델 자체에만 해당함
      Claude Code나 Cursor는 상태를 유지하는 agentic system임

• 이 글의 제목은 흥미롭지만, LLM이 “그럴듯한 코드”를 쓴다는 건 틀림
  실제로는 훈련 데이터에서 본 코드 클러스터와 유사한 코드를 생성할 뿐임
  RLHF나 RLVR로 제한되지 않은 영역에서만 자유롭게 생성함

  • 훈련 데이터의 대부분은 Python이며, 그다음이 웹 기술임
    그래서 업계 전반이 같은 언어로 이야기하지만, 이게 오히려 오해의 원인이 됨
    모두가 같은 문제를 푼다고 착각하게 만듦
  • 분포 밖(out-of-distribution) 영역에 들어가면 모델이 환각(hallucination) 을 일으킴
    예를 들어 tree-sitter 쿼리를 요청하면 존재하지 않는 지시어를 만들어냄
  • 그래도 “plausible”이라는 단어는 적절한 표현임
    굳이 복잡한 내부 구조를 설명할 필요는 없음

• 최근 Codex에게 Datastar 기반 UI 요소를 만들게 했는데 완전히 실패했음
  간단한 작업이었지만, 재시도할수록 인라인 자바스크립트와 백엔드 코드가 계속 늘어남
  이전 코드는 정리하지도 않음
  복잡한 작업은 잘하지만, 오히려 기초적인 과제에서 비직관적인 실패를 보임