Hacker News 의견들

• 에이전트가 지치지 않고 계속 시도하는 모습을 보는 게 흥미로움
  GPU와 NPU가 뜨겁게 돌아가며, 우리는 평소라면 공유하지 않을 데이터까지 넘기고 있음
  지금은 편리한 거래처럼 보이지만, 장기적으로 의존성과 사회적 문제가 커질 위험이 있음
  결국 이 거대한 게이트키퍼에 종속되는 구조가 될 수 있음

  • 끈기가 지난 20년간 테크 업계에서 성공의 핵심 요소였다고 생각함
    • 새로운 프로토콜이나 프레임워크를 만든 사람보다, 복잡한 시스템을 끝까지 붙잡고 해결한 사람이 훨씬 많았음
    • Claude 같은 모델이 바로 그 끈기를 보여줌
  • 하지만 이런 끈기가 항상 좋은 건 아님
    • 종종 망치로 나사를 박는 것처럼, 비효율적인 방식으로 문제를 해결하려는 모습 같음
    • 단기적으로는 결과를 내지만 장기적으로는 부작용을 남김
  • AI가 항상 올바른 길로 간다고 보기 어려움
    • 테스트가 없는 부분에서 새로운 버그를 만들거나, 인간이라면 당연히 지킬 암묵적 규칙을 깨기도 함
    • 결국 “코인 좀 더 넣으면 이번엔 진짜 고쳐줄게요” 같은 느낌을 줌
  • 비용 문제는 과장된 우려라고 생각함
    • 이미 Kimi K2.5나 GLM 4.7 같은 오픈 모델이 상용 수준에 근접했고, 운영비도 낮음
    • 진짜 돈이 드는 건 학습 단계이지, 추론 단계는 이윤이 남는 구조임
  • “AI는 점점 싸질 것이다”라는 말에 동의함
    • 인류 역사상 기술이 비싸진 채로 남은 적은 거의 없음
    • 실제로 작년 대비 절반 수준으로 비용이 줄었음

• AI와 함께 일하면서 두뇌 위축보다 더 큰 문제는 자기만족과 무기력으로 변하는 것 같음
  처음엔 빠른 결과에 도파민이 솟지만, 반복될수록 AI가 프로젝트 방향을 자기 멋대로 끌고 가는 느낌임
  결국 내가 원하던 창의적 실험은 사라지고, AI의 잠재공간 중력에 빨려 들어감
  이건 마치 둠스크롤링처럼, 계속 다음 출력을 보고 싶어지는 중독적 루프임

  • 나도 비슷한 경험을 함
    Rust와 Bevy로 멀티플레이 게임을 만들고 있는데, 코드가 잘 돌아가도 내가 이해하지 못하는 코드가 됨
    예전엔 도구를 완전히 이해해야 여기까지 왔을 텐데, 지금은 반쯤 작동하는 게임을 만들었지만 ECS가 뭔지도 모름
    유지보수나 긴급 대응을 생각하면 이건 진짜 위험한 상태임
  • 단순한 뇌 위축이 아니라, 학습 방향의 전환이 문제라고 봄
    우리는 이제 모델을 배우는 데 집중하고, 스스로 사고하는 법을 잊고 있음
    LLM 사용법은 계속 바뀌기 때문에, 결국 영원한 러닝 트레드밀 위에 서 있는 셈임
  • 반면 어떤 사람은 “코딩은 자전거 타기 같다”고 말함
    오랜 공백이 있어도 감각은 남아 있고, 다시 타면 금방 돌아옴
  • 또 다른 문제는 ‘읽기 위축’ 임
    LLM이 모르면 그냥 포기하고, 문서를 읽지 않으려는 개발자가 늘고 있음
    직접 문서를 읽어 스크린샷까지 보여줘도 “이게 맞을까?”라며 의심함
  • LLM 사용이 틱톡식 도파민 루프와 닮았다고 느낌
    짧은 쾌감 때문에 계속 프롬프트를 던지고, “이번엔 뭐가 나올까”를 기다리게 됨

• LLM 코딩은 ‘코딩을 좋아하는 사람’과 ‘빌딩을 좋아하는 사람’ 을 나누는 계기가 됨
  나는 결과를 만드는 걸 좋아하는 빌더형이라, 이 변화가 즐거움
  반면 코딩 자체를 즐기는 사람들은 이 흐름에 불편함을 느낌

  • 나도 그 중 하나임
    프로그래밍의 매력은 문제를 구조화하고 직접 실행하는 과정에 있었음
    지금은 “내가 코딩을 하는 게 아니라 시키는 느낌”이라 흥미가 줄어듦
  • 사실 이런 논쟁은 새롭지 않음
    과거에도 컴파일 vs 인터프리트, 타입 vs 무타입, 빠른 배포 vs 유지보수성 같은 대립이 있었음
    결국 성공한 소프트웨어는 혼란스러운 초기 단계에서 안정적 확장 단계로 넘어가는 과정을 거침
    AI가 이 과정을 돕는지, 오히려 복잡하게 만드는지는 아직 확신이 없음
  • 또 다른 시각으로는 ‘설계 자체를 즐기는 사람’ 도 있음
    단순히 결과물이 아니라, 시스템 구조를 짜는 과정에서 재미를 느낌
  • LLM 회의론은 탑다운 vs 보텀업 개발 스타일의 충돌로 볼 수도 있음
  • 하지만 “AI를 신뢰할 수 있느냐”는 여전히 문제임
    인간 팀원은 책임과 신뢰가 있지만, LLM은 그렇지 않음

• AI가 10배 생산성 향상을 가져올 수 있다는 생각이 흥미로움
  DevOps가 개발-운영 협업 방식을 바꿔서 고성능 팀을 만들었고, 이게 팀 버전의 10X에 가까운 효과로 이어짐
  AI 코딩을 잘 쓰려면 DevOps처럼 지속적 개선, 워크플로우 변경, 자동화/검증으로 신뢰를 쌓는 과정 필요
  DevOps도 새로운 개념 학습과 팀 문화 변화가 필요해서 널리 퍼지지 못했듯, AI 코딩도 학습/문화 변화가 없으면 10X 잠재력이 있어도 적응이 더딜 수 있음
  정착을 위해 교육과 엔지니어링 문화 변화 필요

• LLM이 대규모 코드베이스에서 쓸모없다고 느꼈음
  특히 복잡하고 상호작용이 많은 코드에서는 거의 도움이 안 됨

  • 하지만 나는 Claude 코드로 98% 작성된 iOS 앱을 3개월 만에 완성했음
  • “이런 사례는 대부분 그린필드 프로젝트”임
    기존 대형/복잡 코드베이스에 넣는 것은, 면밀한 리뷰가 붙는 제한적 변경이 아니면 위험함
    단순 구조에서 파일 목록을 주고 에이전트에게 구현을 맡기는 방식은 인상적이지만, 복잡도가 올라가면 프롬프트가 점점 더 세부 지시로 내려가야 성과가 남
  • “ChatGPT가 아니라 Codex나 Claude CLI 같은 로컬 컨텍스트 도구를 써야 함”
  • Opus 4.5 모델이 진짜 전환점이었음
    이전 모델과 달리, 이제는 복잡한 모노레포에서도 실질적 도움을 줌
  • “LLM이 쓸모없다”는 평가는 맥락 부족 때문일 수 있음
    새 팀원이 같은 정보로 일했을 때보다 나은지 비교해볼 것
  • LLM은 LLM이 만든 코드베이스에서 더 잘 동작하는 경향이 있음
    상용 사내 코드베이스는 고객 요구에 맞춘 반복 개발로 지저분해지고, 초기 가정과 요구가 점점 어긋나며 기술 부채가 생기게 됨
    LLM을 써서 헬퍼 분리/모듈화/리네이밍 같은 리팩터로 현재 요구에 맞게 정리하면, 이후 에이전트 동작이 더 예측 가능해짐
  • 좋은 문서화와 아키텍처 설명, 스타일 가이드 같은 프로젝트 문맥 정리가 중요
    요구사항/수용 기준/유저 스토리를 markdown으로 정리하고, 계획을 세부적으로 쓰게 한 뒤 구현으로 넘어가는 단계적 흐름이 필요

• AI의 끈기와 체력이 인간의 한계를 넘어서는 지점이 인상적임
  연구에서도 지능보다 끈기(grit) 가 성공과 더 밀접하다고 함
  LLM은 예산이 허락하는 한 무한한 끈기를 가짐

• 최근 몇 달간 AI 성능이 오히려 퇴보한 것처럼 느껴짐
  규칙을 잊고, 과도한 계획과 과설계 코드를 생성함
  다만 프론트엔드(HTML + Tailwind)에서는 여전히 유용함

  • 이에 “이건 마치 FrontPage 시절로 돌아간 느낌”
  • 다른 사람은 “그건 Sonnet 모델일 것, Opus 4.5를 써볼 것”

• IDE나 에이전트 스웜에 대한 과도한 기대는 시기상조라고 느낌

  • 10년째 쓰던 JetBrains를 버리고 Zed와 Claude Code만 쓰고 있음
  • 예전엔 몇 달 걸릴 작업을 몇 시간 만에 완성할 수 있게 됨

• iPhone 앱을 만들며 Claude의 영어 프롬프트 기반 코드 생성력에 감탄함

  • Swift 경험이 없어도 C++ 배경만으로 충분히 진행 가능했음
  • 큰 프롬프트보다 작은 단위로 기능을 추가하고 검토하는 방식이 훨씬 효율적임
  • 이 과정을 Prompt → Review → Test (PRET) 라는 새로운 워크플로우로 부르고 있음