Claude로 지난 몇 주간 코딩하며 얻은 몇 가지 단상

Hacker News 의견들

• 어떤 에이전트가 지치지 않고 계속 시도하는 모습을 보는 게 흥미로움
  사람이라면 포기했을 상황에서도 30분 뒤엔 결국 성공함
  하지만 그 과정에서 GPU와 NPU가 뜨겁게 돌아가고, 우리는 엄청난 데이터를 제공하며 실제 비용은 거의 지불하지 않음
  이런 의존이 장기적으로 사회적·정치적 문제로 이어질 수 있음

  • 나도 그 인용문이 인상 깊었음
    지난 20년간 기술 업계에서 성공을 가른 핵심은 끈기(tenacity) 였다고 생각함
    새로운 프로토콜이나 프레임워크를 만든 사람보다, 복잡한 시스템을 끝까지 붙잡고 완성한 사람이 훨씬 많았음
    Claude 같은 AI가 바로 그 끈기를 갖고 있음
  • 하지만 이런 경우 절반은 지름길을 택한 결과임
    테스트가 없는 부분에 새 버그를 만들거나, 인간이라면 당연히 지켰을 암묵적 규칙을 깨버림
    그리고 잡아내면 “코인 몇 개만 더 넣으면 이번엔 진짜 고치겠다”고 말하는 느낌임
  • “비용이 싸지 않을 수도 있다”는 말에 동의하지 않음
    인류 역사상 값이 안 내려간 기술은 없었음, 이미 작년 대비 절반 수준임
  • 인간도 결국 뜨겁게 돌아감
    우리가 먹고, 운전하고, 살아가는 데 드는 공급망 에너지를 생각하면 GPU 전력보다 훨씬 큼
  • “실제 비용을 지불하지 않는다”는 비판은 약함
    이미 Kimi K2.5, GLM 4.7 같은 오픈 모델이 있고, 상업적으로도 충분히 수익이 남음
    진짜 돈이 드는 건 학습 과정이지 추론이 아님
    OpenAI나 Anthropic은 실제 비용보다 훨씬 높은 가격으로 API를 팔고 있음

• AI를 쓰면서 두뇌 위축(brain atrophy) 을 느끼고 있음
  처음엔 빠른 생산성에 도취되지만, 반복될수록 AI가 내 의도와 다른 방향으로 프로젝트를 끌고 감
  결국 내가 원하는 디자인보다 AI의 방식에 순응하게 됨
  새로운 접근을 시도할수록 AI의 훈련 데이터 편향이 벽처럼 느껴짐

  • 단순한 두뇌 위축이 아니라, 모델 사용법을 배우는 데 뇌를 쓰는 구조적 전환임
    하지만 이 메타 스킬도 금방 낡음
    모델이 바뀔 때마다 새로 배워야 하고, 결국 영원한 러닝 트레드밀 위에 서게 됨
    나는 이런 의존을 원치 않음
  • 나도 비슷한 경험을 함
    최근 Claude Code로 Rust 기반 멀티플레이어 게임을 만들고 있는데, 코드가 잘 돌아가도 내가 진짜 이해하고 있지 않음
    과거엔 도구를 완전히 이해해야 여기까지 왔을 텐데, 지금은 반쯤 기능하는 게임만 있음
    유지보수나 버그 대응을 생각하면 이건 위험한 상태임
  • LLM 사용이 틱톡·릴스 중독과 비슷하다고 느낌
    가끔 “와, 이런 결과가?” 하는 순간이 도파민을 자극하고, 그 짧은 쾌감을 다시 얻기 위해 계속 프롬프트를 돌림
  • “AI가 하자는 대로 두는 게 더 편하다”는 말에 공감함
    하지만 이건 곧 기술 부채를 미덕처럼 여기는 산업 문화로 이어질 수 있음
    AI 발전 속도가 그 부채 누적 속도를 따라잡지 못하면 큰 대가를 치를 것임
  • 오늘은 새로운 문제를 겪음 — ‘읽기 위축(reading atrophy)’
    LLM이 모르면 개발자들이 문서를 읽지 않음
    내가 직접 스크린샷과 하이라이트로 문서를 보여줘도 “이게 될지 모르겠다”는 반응을 들음

• LLM 코딩은 ‘코드를 좋아하는 사람’과 ‘무언가를 만드는 걸 좋아하는 사람’ 을 갈라놓음
  나는 결과를 만드는 빌더(builder) 쪽이라 이 변화가 반가움

  • 나도 그 구분에 공감함
    예전엔 문제를 데이터 구조와 명령으로 정의하고, 그게 실행될 때의 쾌감이 좋았음
    그런데 지금은 “이걸 대신 해주는 존재에게 지시하는 일”이 되어버림
    그게 즐겁다면 차라리 매니저가 되었을 것임
  • 사실 이런 논쟁은 새롭지 않음
    과거에도 컴파일 vs 인터프리트, 타입 vs 무타입, 빠른 배포 vs 유지보수성 같은 논쟁이 있었음
    결국 성공한 소프트웨어는 모두 혼란스러운 초기 단계에서 안정적 확장 단계로의 전환을 거침
    AI가 이 과정을 도와줄지, 오히려 복잡하게 만들지는 아직 확신이 없음
  • 하지만 빌더라면 LLM을 신뢰할 수 있어야 함
    인간 팀원은 책임과 신뢰가 있지만, AI는 책임이 없는 존재라 완전히 동일선상에 둘 수 없음
  • 두 관점 모두 필요하다고 생각함
    대규모 서비스에는 엄격함이 필요하지만, 내부 도구나 실험적 프로젝트에서는 AI가 프로세스를 75% 단축시켜줌
    실제로 사내에서 이런 식으로 에디터들의 업무 효율을 크게 높였음
  • 아마 중간 지점도 있을 것임
    코딩보다 시스템 설계 자체를 즐기는 사람들처럼

• “10X 엔지니어” 개념이 AI 시대에 더 벌어질 수 있음
  DevOps가 팀 단위의 10배 성과를 만든 것처럼, AI 활용 능력도 새로운 생산성 격차를 만들 것임
  하지만 이를 위해선 문화적 변화와 교육이 필요함
  DevOps가 그랬듯, 배우기 싫어하는 조직은 이 변화를 놓칠 것임

• 큰 코드베이스에서는 LLM이 쓸모없다고 느꼈음
  ChatGPT로는 제대로 작동하지 않음

  • Codex를 쓰고 있는지 묻고 싶음
    나는 수천 개 파일이 있는 리포지토리에서도 꽤 효율적으로 작업함
    다만 리팩터링 주기와 정적 분석·테스트·문서화가 필수임
    모델별로도 차이가 커서, Opus는 일상용으로, Codex는 테스트 작성에 강함
    Gemini는 빠른 프로토타입용으로 좋음
  • 나는 3개월 동안 Bluesky용 앱 Skyscraper를 만들었는데, 코드의 98%가 Claude가 작성한 것임
    App Store 링크
  • 우리 팀은 대형 CRUD 대시보드에 LLM을 쓰고 있음
    프런트엔드는 엉망이라 AI도 고생하지만, 백엔드(Typescript + Node)는 거의 원샷 구현 가능함
    Cursor를 통해 Opus 4.5와 GPT-5.2-Codex를 병행 사용 중이며, 유료 모델이 확실히 품질이 좋음
  • 나도 Swift를 처음 배웠을 때 AI 덕분에 한 달 만에 꽤 복잡한 앱을 완성했음
    Salam Prayer 앱 링크
    AI가 막히면 직접 Swift와 Xcode 프로파일러를 공부하며 성능을 개선했음
  • “ChatGPT” 웹 인터페이스로 대형 코드베이스를 다루는 건 논점이 아님
    Claude나 Codex CLI를 써야 제대로 된 맥락을 제공할 수 있음

• 최근 몇 달간 AI 성능이 오히려 퇴보한 느낌임
  규칙을 잊고, 과도한 계획을 세우며, 불필요하게 복잡한 코드를 생성함
  그래도 프런트엔드(HTML + Tailwind) 에서는 여전히 유용함

  • 프런트엔드를 그렇게 가볍게 보는 건 아쉬움
    이미 접근성 문제로 가득한 영역이라 LLM이 그 문제를 더 확대할 위험이 있음
  • 그 말투는 마치 FrontPage나 Dreamweaver 시절로 돌아간 것 같음
  • 혹시 Opus 4.5 대신 Sonnet을 쓰는 건 아닌지 묻고 싶음

• 끈기(grit) 가 지능보다 성공과 더 상관 있다는 연구가 많음
  AI는 예산이 허락하는 한 무한한 끈기를 가짐
  결국 인간의 생산성 병목이었던 지속력(stamina) 이 LLM으로 크게 확장된 셈임

• AI가 끝없이 시도하는 모습은 인상적이지만, 잘못된 방향으로 파고드는 경우도 많음
  특히 Sonnet은 타입 에러 하나 해결하려고 코드베이스 전체를 수정하기도 함
  “지금 엉뚱한 길로 가는 거 아니야?”라고 물으면 바로 수정하지만, Opus가 훨씬 안정적임
  그래도 최근엔 전반적으로 많이 개선됨

• 지금의 AI 코딩은 세세한 작업 지시와 주니어 개발자 코드 리뷰의 결합처럼 느껴짐
  이런 일이 내 주된 업무가 되지 않기를 바람

• Copilot + VS Code 조합에 만족 중임
  Claude에게 변경 요청을 하고, diff 뷰에서 수락·거절하며 직접 수정도 가능함
  Karpathy가 말한 “IDE는 여전히 필요하다”는 주장과 일맥상통함

  • 나도 Copilot Chat만으로 충분히 작업함
    Claude 플러그인은 불편했고, Copilot의 변경 이력 되돌리기 기능이 훨씬 직관적임
    내 사고방식과 잘 맞음
  • Copilot이 직접 테스트를 실행하거나 코드 스니펫을 돌려보게 하면 훨씬 흥미로워짐
    단순한 diff 제안보다 훨씬 강력한 방식임
  • 나는 GitHub 이슈를 Copilot에 할당해 풀리퀘스트를 자동 생성하게 함
    모든 맥락이 PR에 담겨 리뷰하기 편하고, 병렬 세션도 가능함
  • 하지만 Copilot은 아직 cc나 Cursor 수준에는 미치지 못함