3P by GN⁺ 2일전 | ★ favorite | 댓글 2개
  • Claude를 활용해 최근 몇 주간 집중적으로 코딩한 경험에서 나온 간단한 메모 모음
  • 트위터 쓰레드 형식으로 개발 과정에서 느낀 점과 관찰을 공유
  • 구체적인 코드 예시나 기술적 세부 내용은 본문에 포함되지 않음
  • 게시물은 개인적 경험 기반의 짧은 노트 형태로 구성
  • 현재 제공된 자료에는 추가 설명이나 세부 내용이 없음

내용 불분명

  • 제공된 트위터 링크 외에 본문 내용이 포함되지 않아 세부 요약 불가
  • 제목과 게시 형식으로 보아 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 수준에는 미치지 못함